AI時代にシステムアーキテクトはどう変わるのか
従来型・AI組み込み型・スウォーム型の3層で整理する
はじめに
AIの進化で変わっているのは、単に「実装が速くなった」という話ではありません。
もっと大きい変化は、アーキテクトが設計すべき対象そのものが変わり始めたことです。
これまでのシステム設計は、基本的に「決めた構造を、人間が実装して、その通りに動かす」世界でした。
ところが今は、LLM がコードを書き、テストを走らせ、外部ツールを呼び、場合によっては自分で判断しながらワークフローを前に進めます。Anthropic は agentic systems を workflow と agent に分けて整理し、まずは augmented LLM から始めて必要に応じて複雑性を上げるべきだと述べています。
OpenAI も、エージェントは LLM がワークフロー実行を管理し、ツールを使い、必要なら人へ制御を返すシステムだと定義しています。
この変化を踏まえると、システムアーキテクトは少なくとも3つの型に分かれて見えるようになります。
ただし重要なのは、3つが完全に別職種になるということではありません。実際には、設計対象の重心がどこにあるかで役割がズレていく、と捉えたほうが正確です。
1. 従来型ITシステムアーキテクトは、実装者ではなく「実行可能仕様の設計者」へ変わる
最初の型は、従来の業務システムや基幹システム、Webシステム、クラウド基盤を扱うアーキテクトです。
ここで起きている変化は明快です。AI はすでに、コードを書くだけでなく、ファイルを編集し、コマンドを実行し、複数ファイルを横断しながら開発作業を進める水準に入っています。
Claude Code も、コードベースを読み、編集し、コマンドを実行し、開発ツールと統合する agentic coding tool として位置づけられています。
その結果、従来型アーキテクトの価値は「詳細実装を人力で引き回すこと」から離れます。
代わりに重要になるのは、障害境界、責務分離、認証・認可、監査性、可観測性、ロールバック、SLO、変更容易性、コスト上限です。
NIST の GenAI Profile も、生成AIは個別のユースケースごとに固有のリスクを持ち、それに応じたガバナンスとリスク管理行動を設計する必要があるとしています。
ここでひとつ誤解しやすい点があります。
それは「GUI自動操作はまだ遅れているから、今後もコード化が絶対優位だ」という見方です。
2026年3月23日に Anthropic は Claude Cowork / Claude Code 向けに computer use を research preview として公開し、Claude が画面を見て point-and-click で作業できるようにしました。
ただし同社は同時に、Claude はまず Slack や Google Calendar などの より正確なコネクタを優先 し、connector がないときに computer use へ降りること、さらに computer use は coding や text interaction に比べてまだ early で、直接統合より遅いと明言しています。
つまり現時点の現実はこうです。
UI操作型AIは立ち上がった。だが主戦場は依然として API・CLI・IaC・CI/CD 側にある。
だから従来型ITアーキテクトは消えません。むしろ、AIが大量に実装できるようになったぶん、上流の制約設計と下流の運用責任が重くなります。
2. AIシステムアーキテクトは、「AIを埋め込む人」ではなく「確率的部品を統治する人」になる
次に重要なのが、AIをシステムの中に組み込む設計です。
ただ、この役割を「AI API を呼ぶ構成を作る人」とだけ捉えると浅くなります。
Anthropic は agentic system の基本単位を augmented LLM と整理し、その中核に retrieval、tools、memory を置いています。
つまり、いま設計しているのは単なるAPI接続ではなく、文脈取得・外部作用・記憶保持を含んだ確率的コンポーネント です。
OpenAI の実践ガイドでも、エージェントは LLM による判断とツール利用を通じてワークフローを進める存在として定義され、従来の deterministic な自動化が苦手な曖昧で複雑な領域に向いていると説明されています。
一方で、単一エージェントから始め、必要なときだけ multi-agent に進むべきだとも書かれています。
ここでアーキテクトの仕事は変わります。
設計対象は「AIをどこで呼ぶか」ではなく、
どこまでAIに委ねるか
どこから deterministic に固定するか
出力を何で検証するか
を決めることです。
Databricks の LLMOps ドキュメントは、人間のフィードバックループがほとんどの LLM アプリケーションで essential だと明言しています。
つまり、AIシステムアーキテクトはモデルの賢さに賭ける人ではなく、モデルの不確実性を監視・補正・改善可能な形で運用へ載せる人 です。
この意味で、MLOps / LLMOps / AIOps の本質は一本につながっています。
学習済みモデルを置くことではなく、
確率的な判断部品を、本番運用に耐える回路へ変えること。
ここに、AIシステムアーキテクトの本当の価値があります。
3. スウォーム型アーキテクトは、「設計者」ではなく「制御則の設計者」になる
3つ目が、もっとも新しい層です。
複数のAIエージェントが分業し、相互に対話し、時に自己修正しながら進む構造です。
Anthropic が公開した multi-agent research system も、ユーザーの問いをもとに調査計画を立て、並列エージェントを立ち上げて探索させる構造を採っています。同社はその中で、multi-agent には coordination、evaluation、reliability に新しい課題が生じると明言しています。
研究側でも、LLM-based Multi-Agent Systems は「複雑タスクの解決」「特定シナリオのシミュレーション」「生成エージェントの評価」という3方向で広がっており、単一エージェントでは表現しにくい多主体相互作用を扱う枠組みとして位置づけられています。
ただし、ここで誤解してはいけません。
スウォーム型とは、AI同士を好き勝手に会話させることではありません。
むしろ必要なのは、
役割分担
通信位相
レビュー経路
停止条件
収束条件
の設計です。
ICML 2025 の研究では、faulty agents が混ざる条件下で、hierarchical structure が他構造より resilient で、さらに Challenger や Inspector のような相互批判・独立査読の仕組みを入れると性能低下を大きく回復できると報告されています。
ここから分かるのは、現時点で強いのは「自由な群れ」ではなく、監督と検査を持つ階層型の群れ だということです。
したがって、スウォーム型アーキテクトの仕事は、個々のエージェントに何を話させるかではありません。
本質は、どのエージェントが分解し、どのエージェントが実行し、どのエージェントが監査し、どこで人間が止めるか を設計することです。
4. これから本当に重要になるのは、「AIの行動原理」と「成果物」を分けて考えること
ここが、このテーマの核心です。
人が欲しいのは、AIが頑張っている様子ではありません。
欲しいのは納品物です。
コード、IaC、議事録、分析レポート、設計書、PR、ダッシュボード、運用改善結果。
つまり、AIの内部の試行錯誤 と 最終成果物の受け入れ可否 は分けて考える必要があります。
OpenAI は、guardrails を layered defense として設計し、人間の介入を critical safeguard と位置づけています。
特に high-risk actions や failure threshold 超過時には、人へ制御を戻すべきだとしています。
Databricks も human feedback loops を essential としています。
だから現時点の実務で強いのは、完全統合型の全自律最適化ではありません。
強いのは、
探索や局所判断はAIにやらせる
受け入れ条件、境界、停止権限、最終責任は人間側に寄せる
というハイブリッド構成です。
これは弱気な設計ではありません。
むしろ、現在の技術水準に対して最も歩留まりが高い設計です。
単一エージェントで済むところは単一で回し、必要な場所だけ manager-worker や inspector 付き multi-agent を入れる。
この「複雑性の段階投入」が、2026年時点の最適解にかなり近いと思います。
まとめ
これからのシステムアーキテクトは、次の3層で捉えると見通しがよくなります。
従来型ITシステムアーキテクト は、
実装を細かく管理する人から、
実行可能仕様と制約を設計する人 へ移る。
AIシステムアーキテクト は、
AIをAPIとして差し込む人から、
確率的コンポーネントを統治する人 へ移る。
スウォーム型アーキテクト は、
複数AIを動かす人から、
役割分化・監査・停止・収束を設計する制御則の設計者 へ移る。
そして現時点で最も現実的なのは、
すべてをスウォーム化することではなく、
全体最適は人間が握り、局所最適をAIに委譲する構成 です。
AIが奪うのは、アーキテクトという職能そのものではありません。
奪うのは、実装の細部に張り付き続ける働き方です。
その代わりに前面へ出てくるのは、制約、評価、監査、停止、収束、責任境界。
つまり、これからのアーキテクトは、図を描く人ではなく、動き続ける知能系に境界と責任を与える人 になっていきます。
#AI #生成AI #AIエージェント #システムアーキテクト #システム設計 #アーキテクチャ #ソフトウェア設計 #LLMOps #AgentOps #MLOps #ClaudeCode #AI活用 #業務改善 #テックブログ #note
