プロンプトを磨くだけでは、本番で動くAIエージェントは作れません。2026年6月、Rakib Hossen氏がXで示したロードマップは、「LLMを選ぶ」ことより「モデル周辺のシステム」を設計することが要点だと説いています。投稿では、本番投入可能なエージェントに8つのコアレイヤーが必要だと整理されています（元投稿）。
この記事では、同趣旨で業界に広がっている8層アーキテクチャを、開発者が設計レビューに使える形で整理します。各層の役割、代表ツール、よくある抜け漏れまでを一通り押さえられます。
この記事でわかること
- なぜ「LLM＋ツール呼び出し」だけでは本番で破綻しやすいのか
- 8層それぞれが担う責務と、隣接レイヤーとの境界
- レイヤーごとの代表的な実装例（買う／作るの判断材料）
- プロトタイプから本番へ移すときに起きやすい3つの失敗パターン
LLM単体では足りない理由
PoC段階のエージェントは、チャットUIにツール呼び出しを足しただけでも動いて見えます。しかし本番では、入力のばらつき、セッションをまたぐ文脈、外部APIの失敗、コストの暴走、監査要件が同時に襲ってきます。Mediumのプロダクト向け解説では、成功するチームと高額なデモに留まるチームの差は、特定のモデル性能より8層のうちどこを設計したかに現れると指摘されています（参考）。
Hossen氏の投稿が強調するのも同じ構造です。推論エンジン（LLM）は中心に置きつつ、周辺にオーケストレーション、メモリ、ツール、プロトコル、計画、ドメイン実装、運用監視を重ねる。これを層として切り分けると、障害の切り分けと段階的な拡張がしやすくなります。
8層アーキテクチャの全体像
文献や実装例を横断すると、名称は多少異なりますが、次の8層に収束します。ここでは実装者向けに、下から上へ積み上げる順で説明します。
| 層 | 主な責務 | 代表例 |
|---|---|---|
| 1. 基盤モデル | 推論・生成の中核 | GPT-4o、Claude、Gemini、Llama |
| 2. オーケストレーション | 状態管理、分岐、再試行 | LangGraph、OpenAI Agents SDK、CrewAI |
| 3. メモリ | 短期・長期の文脈保持 | Mem0、Zep、Redis、Pinecone |
| 4. ツール連携 | 外部への行動 | Tavily、E2B、Composio、Browser Use |
| 5. エージェント間プロトコル | ツール／エージェント間の標準接続 | MCP、A2A |
| 6. 計画・反省 | 目標分解と自己評価 | Plan-and-Execute、Reflexion、CoT |
| 7. アプリケーション | ドメイン固有の体験 | コーディング、調査、カスタマーサポート |
| 8. 可観測性・ガバナンス | トレース、評価、安全制御 | LangSmith、Langfuse、Arize Phoenix |
学術的な整理でも、Foundation ModelsからObservability & Safetyまで同様の8層分解が示されています（engrXivプレプリント）。
第1層：基盤モデル
基盤モデルは、エージェントの「思考エンジン」です。ここで決まるのは、推論の質だけではありません。コンテキスト長、ツール呼び出しの安定性、推論コスト、レイテンシも同時に固定されます。
実務では、タスクごとにモデルを使い分ける設計が一般的です。分類や要約は軽量モデル、複雑な計画やコード生成は上位モデル、という二段構えにすると、月次コストを抑えつつ品質を維持できます。モデルは差し替え可能にし、アーキテクチャは固定する、という考え方が2026年の標準です。
第2層：オーケストレーション
オーケストレーション層は、エージェントの実行グラフを動かすランタイムです。単発のAPI呼び出しではなく、状態遷移、条件分岐、並列実行、人間承認待ち、チェックポイントからの再開を扱います。
LangGraphのようなグラフベースのフレームワークは、サイクル（再計画ループ）を第一級で表現できます。Airflow型の直線DAGだけでは、ツール失敗後の再試行や方針変更を表現しづらい、というのが本番でオーケストレーション専用層が要る理由です。ここを省略すると、プロンプト内に暗黙の状態機械を書くことになり、デバッグ不能になります。
第3層：メモリ
メモリ層は、会話履歴や学習した事実を、セッションをまたいで再利用する仕組みです。RAG（検索拡張生成）はこの層の一部で、ベクトル検索だけでは不十分です。
実運用では、短期メモリ（直近のターンと作業状態）と長期メモリ（過去の対話、ユーザ設定、組織ナレッジ）を分けます。加えて、要約による圧縮、TTLによる忘却、個人情報の削除要求への対応が必要です。メモリを設計しないエージェントは、毎回コンテキストを再投入するためコストが膨らみ、ユーザーには「前に言ったことを忘れる」体験になります。
第4層：ツール連携
ツール層は、エージェントが外界に作用する接点です。Web検索、コード実行、CRM更新、ファイル操作など、LLM単体ではできない操作をここに集約します。
失敗しやすいのは、スキーマ未定義のまま関数呼び出しを増やすパターンです。各ツールには入出力、副作用、冪等性、タイムアウト時の挙動を契約として書きます。サンドボックス実行や高リスク操作の承認ゲートも、この層か直上のガバナンス層で実装します。Aakash Gupta氏の解説では、多くのプロジェクトが「話すだけのエージェント」と「動くエージェント」の境界で躓くとされています（参考）。
第5層：エージェント間プロトコル
プロトコル層は、ツール接続とエージェント間連携の標準規格です。Model Context Protocol（MCP）は、LLMと外部ツールの接続を共通化する枠組みとして急速に普及しています。Agent-to-Agent（A2A）など、エージェント同士の委譲やタスク割当を標準化する仕様も並行して整備されています。
独自プロトコルを作るより、既存規格に乗る方が、ツールの再利用とベンダーロックイン回避に有利です。チーム内でエージェントが増えるほど、この層の設計判断が効いてきます。
第6層：計画・反省
計画層は、ゴールから手順を分解し、実行結果を見て軌道修正する頭脳です。Chain-of-Thought（CoT）は単一推論の可視化、Plan-and-Executeは計画と実行の分離、Reflexionは失敗からの学習、といった技法が該当します。
長期タスクでは、フラットな「次に何をするか」だけでは破綻します。階層的タスク分解（HTNに近い考え方）と、計画失敗時の再計画ループをオーケストレーション層と組み合わせる必要があります。推論の透明性をログに残すことで、なぜその行動を選んだかを後から説明できます。
第7層：アプリケーション
アプリケーション層は、ユーザーが触る体験とドメインロジックです。汎用チャットをそのまま出すのではなく、調査エージェント、コーディングエージェント、社内FAQエージェントのように、一つのワークフローを深く実装する段階です。
ここで陥りやすいのは、下位層が未整備のままUIだけ作ることです。見た目はエージェントでも、裏側が不安定だと、ユーザー信頼は一度で失われます。成功例は、単一ユースケースで成功率とレイテンシを測り、隣接ワークフローへ広げる順序を取ります。
第8層：可観測性・ガバナンス
最上層は、本番を維持するための運用基盤です。分散トレース、トークンコストの帰属、評価データセットによる回帰テスト、入力出力のガードレール、監査ログが含まれます。
エージェントは非決定的なため、再現性のある評価と、本番トレースの相関が必須です。LangSmithやLangfuseのようなツールは、どのステップで幻覚やツール失敗が起きたかを特定するために使われます。EU AI Actや社内セキュリティポリシーへの対応も、この層で「後付け」にすると手戻りが大きくなります。
レイヤー設計で避けたい3つの失敗
8層をチェックリストとして使うと、典型的な失敗が見えやすくなります。
全部自作する。 インフラやプロトコルまで自前実装すると、差別化すべき認知・メモリ・アプリ層に工数が回りません。基盤と標準プロトコルは既製品を使い、ドメイン固有の計画と評価に集中するのが合理的です。
アプリ層から入る。 UI先行で下位層を後回しにすると、負荷や障害で全面的な作り直しが発生します。PoCでもオーケストレーションとログの最小構成は最初から入れておくべきです。
特定層を忘れる。 メモリ欠如はUX悪化、プロトコル欠如はマルチエージェント連携の破綻、ガバナンス欠如はエンタープライズ導入の停止、につながります。
実装を始めるときの進め方
新規プロジェクトでは、次の順が現実的です。まずユースケースを1つに絞り、必要なツール契約を定義する。次にオーケストレーションで状態機械を書き、トレースを有効化する。メモリは短期のみから始め、価値が確認できたら長期とRAGを追加する。モデルは最後に差し替え可能な前提で選ぶ。
Hossen氏の投稿が示す「2026年のロードマップ」は、流行のモデル名を追う話ではありません。エージェントを分散システムとして層に分け、本番要件を最初から組み込む設計思想です。LLMの選定は重要ですが、勝敗を分けるのはその周辺8層の完成度にあります。