2026年の今日、私たちは「大規模言語モデル（LLM）はチャットをするもの」というフェーズをすでに通り過ぎました。
企業が真に求めているのは、「AIがテストで何点取れるか」ではなく、より切実な問いです。
「このツールで、実際の業務プロセスを一つ完結させられるか？」
しかし、いざ実装フェーズに入ると、問題は具体的になり——そして、混乱し始めます。 単純なRAG（検索拡張生成）による問答システムですべてのシナリオをカバーしようとするチームもあれば、最初からマルチエージェント（Multi-agent）を導入し、「AIチーム」のような複雑なシステムを構築しようとするチームもあります。あるいは、その中間で「ちょうどいい塩梅」が見つからず、試行錯誤を繰り返すことも少なくありません。
その結果は、往々にして予想通りです。
- 単なるFAQ対応に複雑なオーケストレーションを導入し、運用コストが跳ね上がる。
- 「賢さ」を求めて反復（Reflection）やループを追加した結果、レスポンスが数秒から数十秒に遅延する。
- ツールチェーンは完璧だが、一つのAPIが不安定になっただけでプロセス全体が停止する。
Gartnerのデータもこの傾向を裏付けています。生成AIプロジェクトの少なくとも30%は、PoC（概念実証）の段階で放棄されています。 その主な理由はモデルの能力不足ではなく、コストの制御不能と、ビジネス価値を明確に示せないことにあります1。さらにAgentプロジェクトに関しては、Agentic AIプロジェクトの40%以上が2027年末までに中止されるとも予測されています2。
問題の本質は、もっと手前の段階にあります。
「システムの『境界（Boundary）』を定義しないまま、『能力』だけを積み上げている」
なぜ「能力」よりも「境界」が重要なのか
AIシステム設計には、一つの大きな罠があります。「LLM（ChatGPTやClaudeなどの核となる技術）の推論能力が強ければ強いほど、システムは問題を解決できる」という思い込みです。しかし、実務的なエンジニアリングの観点から言えば、アーキテクチャの成否を分けるのは「境界（Boundary）」の設定です。
ここで言う「境界」には、3つの次元があります。
- タスクの境界：そのタスクに明確な正解があるか？「確定的な出力」を求めるのか、それとも「探索的な提案」を求めるのか。
- 遅延（レイテンシ）の境界：ビジネス上、どの程度の待ち時間を許容できるか。1秒（リアルタイム）、30秒（非同期）、あるいは数分か。
- 実行権限の境界：システムは「答える」だけでいいのか、それとも「動く（API実行、DB更新、物流トリガーなど）」必要があるのか。
RAGだけで解決できるFAQタスクに、自律性の高いAgentを投入するのは、高価なトークンの無駄遣いであるだけでなく、本来確定しているはずのプロセスに、不必要な「不確実性」を持ち込むことになります。 ** Anthropicのエンジニアリングチームは、多くの顧客事例を分析した結果、非常に明快なアドバイスをしています。「問題を解決できる最小限の構成を見つけ、本当に必要な時だけ複雑さを加えるべきだ」** と3。
レゴブロック：Agentシステムを構成する4つの要素
具体的なアーキテクチャを議論する前に、まず「部品」の認識を合わせましょう。どんなに複雑なシステムも、本質的には以下の4つのコンポーネントで構成されています：
- 推論エンジン (LLM Brain)：コンテキストに基づいて意思決定を行う「脳」。
- プランニング (Planning)：目標をステップに分解する能力。低レイヤーではハードコードされ、高レイヤーではモデルによって動的に生成されます。
- メモリー (Memory)：短期的な文脈（会話履歴）と、長期的な知識（RAG等のベクトルデータ）。
- アクション（Action Space）：システムが呼び出せる外部機能（API、コード実行、基幹システムとの連携など）。
これらは一般的なAI Agentの定義に含まれる要素ですが、実際の業務では必ずしもこれらすべてを揃える必要はありません。一部のコンポーネントだけで目的を達成できる場合も多いのです。
また、以前はLLMの「脳としての能力」ばかりが注目されていましたが、現在の焦点は、いかにその能力を制御し、効率よく引き出すかという点にあります。Prompt Engineeringから始まり、Context Engineering、そして現在のHarness Engineeringへの変遷は、まさに既存のLLMをいかに使いこなすかの探求と言えます。
本シリーズで議論したいのは、モデルの能力差ではなく、 「LLMに『事を行う』能力を持たせたとき、いかにその範囲（境界）を制限し、制御するか」 というアーキテクチャの選択についてです。
LLMアプリからAIエージェントへ：アーキテクチャ進化の全体像
システムにおけるLLMの「自律性」の度合いによって、アーキテクチャをL1からL5までの5段階に分類しました。これが、本シリーズを通じた評価基準になります。
| レベル | 名称 | LLMの役割 | 代表的なパターン |
|---|---|---|---|
| L1 | 基礎的なレスポンダー | 受動的な生成：与えられた情報で答える | Prompt + RAG |
| L2 | ルーター・ディスパッチャー | 分類器：意図を判断し、ルールへ振り分ける | Intent Classification / Router |
| L3 | ツール実行者 | 能動的な計画：どのツールを、どの順で使うか決める | Function Calling / Tool Use |
| L4 | 協調型オーケストレーター | 能動的な調整：タスクを分解し、複数の子Agentへ配分 | Multi-agent / Orchestrator |
| L5 | 自律的探索者 | 自律的な反復：自己修正し、動的に解決パスを生成 | Goal-oriented（実験的） |
いくつかの補足：
- L1/L2は、プロセスが外部コードによって制御される「LLM駆動のワークフロー」です。L3からLLM自身が実行パスを主導し始める、ここが真の意味での「Agent」の起点です3。
- このL1–L5の分類は、私の実務経験と学習に基づく分析ツールであり、業界の統一規格ではありません。
- L4の内部にはL1–L3が含まれることがあります。このレベルはシステム全体の複雑さを表すもので、個別のコンポーネントの能力ではありません。
L1-L5 具体例：ECのカスタマーサポートの場合
L1：基礎的なレスポンダー（受動的生成）
- 役割：ナレッジベースの翻訳・要約。
- 例：「返品ポリシーは？」という質問に、ドキュメントから該当箇所を探して回答する。
- 特徴：プロセスは高度に制御可能。
L2：ルーター・ディスパッチャー（分類・トリガー）
- 役割：受付・仕分け。
- 例：ユーザーの意図を「クレーム」か「配送確認」か判断し、それぞれ固定の処理フローへ飛ばす。
- 特徴：判断にはLLMを使うが、その後のルートはあらかじめ決まっている。
L3：ツール実行者（能動的計画） —— Agentの起点
- 役割：熟練のオペレーター。
- 例：「荷物の場所を教えて」と言われ、システムが自ら
get_shipping_statusAPIを叩く必要があると判断し、追跡番号を抽出して実行する。 - 特徴：LLMが実行経路を決定する。 いつツールを使い、いつ発話すべきかを知っている。
L4：協調型オーケストレーター（能動的調整）
- 役割：プロジェクトマネージャー / 専門家チーム。
- 例：「返品したいが領収書を失くした」という依頼に対し、財務Agentが履歴を追い、物流Agentが集荷を手配し、マネージャーAgentが最終的な結論をまとめてユーザーに伝える。
- 特徴：タスクの並行処理や分解が可能。
L5：自律的探索者（自己進化）
- 役割：ジュニア・エキスパート。
- 例：前例のないイレギュラーなトラブルに対し、自律的にログを分析し、類似ケースを調べ、必要なら解決のためにスクリプトを書いて実行する。
- 特徴：現在は実験段階。実務への投入はリスクが高い。
2つの視点：自律性とアーキテクチャを切り離す
実際に設計を行う際は、以下の2つを独立した要素として区別する必要があります。
- 自律性レベル (Autonomy Level)：システムにどこまで「任せる」か（L1-L5）。
- システムアーキテクチャ (System Architecture)：システムを「どう動かすか」（シングルAgentか、マルチAgentか）。
これらは必ずしもセットではありません。 L4レベルの複雑なマルチエージェント構成であっても、「一歩ごとに人間が承認する」という低自律モードで運用することは可能です。
まずシーン（レベル）を選び、次にアーキテクチャ（作り方）を選ぶ。 多くのプロジェクトが失敗するのは、マルチエージェントという流行の言葉を使いたいがために、L2レベルで済むタスクを無理やり複雑にしてしまうからです。
最適な「着地点」を見極めるための3つの質問
ビジネスの境界を具体化するために、以下の3つの質問を投げかけてみてください。
Q1：タスクに明確な「正解/不正解」があるか？
- 明確な基準がある（DBクエリ、要約、ルール判定）：L1/L2で十分
- 主観的な判断や外部のリアルタイム情報が必要：L3以上
- ゴールが曖昧で、探索的なアプローチが必要：L4から
Q2：どの程度のレスポンス遅延を許容できるか？
- 3秒以内（リアルタイム）：L1/L2を優先。 L3は厳密な評価が必要。
- 10–30秒（非同期）：L3/L4が選択肢に入る。
- 分単位以上：L4以上を検討可能。
Q3：システムに「実務（アクション）」をさせる必要があるか？
- 情報の出力のみ：L1/L2
- API連携、DB書き込み等が必要：L3から
- システムや役割を跨いだ連携が必要：L4
クイック判定のフレームワーク：
出力の正解が明確 ＋ 情報提示のみ ＋ 低遅延
複数プロセス間の判断・ルーティングが必要
外部システムとの連携が必要 ＋ 明確な「境界」の定義済み
複数ロールの協調 ＋ 並列的なタスク分解が可能
オープンな探索が必要 ＋ 明確な終了条件がない
今後のシリーズで展開すること
これからの記事では、各レベルを一つずつ解体していきます。
- そのレベルの典型的なシステム構成
- 「ちょうどいい塩梅」となるビジネスシーン
- 陥りやすい設計の落とし穴
- 能力を闇雲に高めるのではなく、適切な「境界」を築く方法
これらを通じて、いま動いているプロジェクトが「オーバーエンジニアリング」になっていないか、そして最も根本的な問いに答えを出せるようにします。
「その要件、本当にAgentにする必要がありますか？」
AIシステムの開発は、プロンプトを調整する段階から、システム工学としての設計へと進化しました。現場で安定して稼働するソリューションは、最も「賢い」ものではなく、境界線の中で制御され、メンテナンスが可能で、長く走り続けられるシステムです。
目指すべきは、全知全能のシステムではなく、業務の中で確実に「着地」し、動き続けるシステムなのです。