LLMアプリからAI Agentへ業務の境界線から、最適な「着地点」を見出す

2026年の今日、私たちは「大規模言語モデル（LLM）はチャットをするもの」というフェーズをすでに通り過ぎました。

企業が真に求めているのは、「AIがテストで何点取れるか」ではなく、より切実な問いです。

「このツールで、実際の業務プロセスを一つ完結させられるか？」

しかし、いざ実装フェーズに入ると、問題は具体的になり——そして、混乱し始めます。 単純なRAG（検索拡張生成）による問答システムですべてのシナリオをカバーしようとするチームもあれば、最初からマルチエージェント（Multi-agent）を導入し、「AIチーム」のような複雑なシステムを構築しようとするチームもあります。あるいは、その中間で「ちょうどいい塩梅」が見つからず、試行錯誤を繰り返すことも少なくありません。

その結果は、往々にして予想通りです。

• 単なるFAQ対応に複雑なオーケストレーションを導入し、運用コストが跳ね上がる。
• 「賢さ」を求めて反復（Reflection）やループを追加した結果、レスポンスが数秒から数十秒に遅延する。
• ツールチェーンは完璧だが、一つのAPIが不安定になっただけでプロセス全体が停止する。

Gartnerは2024年、2025年末までに生成AIプロジェクトの少なくとも30%がPoC（概念実証）の後に放棄されると予測しました。理由として挙げられたのは、データ品質の低さ、不十分なリスク管理、コストの増大、あるいは不明確なビジネス価値です¹。さらにAgentプロジェクトに関しては、Agentic AIプロジェクトの40%以上が2027年末までに中止されるとも予測されています²。

問題の本質は、もっと手前の段階にあります。

「システムの『境界（Boundary）』を定義しないまま、『能力』だけを積み上げている」

なぜ「能力」よりも「境界」が重要なのか

AIシステム設計には、一つの大きな罠があります。「LLM（ChatGPTやClaudeなどの核となる技術）の推論能力が強ければ強いほど、システムは問題を解決できる」という思い込みです。しかし、実務的なエンジニアリングの観点から言えば、アーキテクチャの成否を分けるのは「境界（Boundary）」の設定です。

ここで言う「境界」には、3つの次元があります。

1. タスクの境界：そのタスクに明確な正解があるか？「確定的な出力」を求めるのか、それとも「探索的な提案」を求めるのか。
2. 遅延（レイテンシ）の境界：ビジネス上、どの程度の待ち時間を許容できるか。1秒（リアルタイム）、30秒（非同期）、あるいは数分か。
3. 実行権限の境界：システムは「答える」だけでいいのか、それとも「動く（API実行、DB更新、物流トリガーなど）」必要があるのか。

RAGだけで解決できるFAQタスクに、自律性の高いAgentを投入するのは、高価なトークンの無駄遣いであるだけでなく、本来確定しているはずのプロセスに、不必要な「不確実性」を持ち込むことになります。 ** Anthropicのエンジニアリングチームは、多くの顧客事例を分析した結果、非常に明快なアドバイスをしています。「問題を解決できる最小限の構成を見つけ、本当に必要な時だけ複雑さを加えるべきだ」** と³。

レゴブロック：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段階に分類しました。これが、本シリーズを通じた評価基準になります。

いくつかの補足：

• L1/L2は、プロセスが外部コードによって制御される「LLM駆動のワークフロー」です。L3からLLM自身が実行パスを主導し始める、ここが真の意味での「Agent」の起点です³。厳密に言えば、ツールを一度呼ぶだけのL3は、Anthropicの言う「拡張されたLLM（augmented LLM）」に近く、結果を見ながらループの中でツールを呼び続けるものが、彼らの定義するAgentです。
• このL1–L5の分類は、私の実務経験と学習に基づく分析ツールであり、業界の統一規格ではありません。
• L4の内部にはL1–L3が含まれることがあります。このレベルはシステム全体の複雑さを表すもので、個別のコンポーネントの能力ではありません。

L1-L5 具体例：ECのカスタマーサポートの場合

L1：基礎的なレスポンダー（受動的生成）

• 役割：ナレッジベースの翻訳・要約。
• 例：「返品ポリシーは？」という質問に、ドキュメントから該当箇所を探して回答する。
• 特徴：プロセスは高度に制御可能。

L2：ルーター・ディスパッチャー（分類・トリガー）

• 役割：受付・仕分け。
• 例：ユーザーの意図を「クレーム」か「配送確認」か判断し、それぞれ固定の処理フローへ飛ばす。
• 特徴：判断にはLLMを使うが、その後のルートはあらかじめ決まっている。

L3：ツール実行者（能動的計画） —— Agentの起点

• 役割：熟練のオペレーター。
• 例：「荷物の場所を教えて」と言われ、システムが自らget_shipping_status APIを叩く必要があると判断し、追跡番号を抽出して実行する。
• 特徴：LLMが実行経路を決定する。 いつツールを使い、いつ発話すべきかを知っている。

L4：協調型オーケストレーター（能動的調整）

• 役割：審査会。
• 例：長年の顧客が、返品期限は過ぎたものの品質に問題のある商品を返品したいと言っている。ただ、このアカウントはこの1か月で何度も返品している。「顧客体験」の視点はすぐに返金すべきだと言い、「リスク」の視点は返品制度の悪用を心配し、「コスト」の視点は送料と損失を計算する。L4は各視点にそれぞれの理由を述べさせ、最後はルールか人が裁定する。取引履歴の確認や集荷の手配だけなら、L3で足りる。
• 特徴：Agentは部署ではなく関心事で分ける。ひとつのタスクに互いに衝突する複数の目標があり、異なる視点で牽制し合い、最後に誰かが裁定する必要があるときだけ、L4が必要になる。並列呼び出しや複数システムをまたぐだけなら、L3でもできる。

L5：自律的探索者（自己進化）

• 役割：ジュニア・エキスパート。
• 例：前例のないイレギュラーなトラブルに対し、自律的にログを分析し、類似ケースを調べ、必要なら解決のためにスクリプトを書いて実行する。
• 特徴：現在は実験段階。実務への投入はリスクが高い。

2つの視点：自律性とアーキテクチャを切り離す

実際に設計を行う際は、以下の2つを独立した要素として区別する必要があります。

1. 自律性レベル (Autonomy Level)：システムにどこまで「任せる」か（L1-L5）。
2. システムアーキテクチャ (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から
• 複数のシステムをまたいで取得・操作する：L3でも可能。目標が衝突するときにL4

クイック判定のフレームワーク：

今後のシリーズで展開すること

これからの記事では、各レベルを一つずつ解体していきます。

• そのレベルの典型的なシステム構成
• 「ちょうどいい塩梅」となるビジネスシーン
• 陥りやすい設計の落とし穴
• 能力を闇雲に高めるのではなく、適切な「境界」を築く方法

これらを通じて、いま動いているプロジェクトが「オーバーエンジニアリング」になっていないか、そして最も根本的な問いに答えを出せるようにします。

「その要件、本当にAgentにする必要がありますか？」

AIシステムの開発は、プロンプトを調整する段階から、システム工学としての設計へと進化しました。現場で安定して稼働するソリューションは、最も「賢い」ものではなく、境界線の中で制御され、メンテナンスが可能で、長く走り続けられるシステムです。

目指すべきは、全知全能のシステムではなく、業務の中で確実に「着地」し、動き続けるシステムなのです。