6 レイヤモデル ─ Agent ＝モデル + ハーネス

2026/05/10

6 レイヤモデル ─ Agent ＝モデル + ハーネス

ch1 で「Demo は動くのに業務には乗らない」原因が モデルの周りに積み上がる 6 レイヤにあることを示した。この章では、その地図を確定させる。各レイヤが何を解決するための層なのか、どのレイヤの上に何が載るのか、そして読者がいま詰まっているレイヤを最短で見つける方法を提示する。

6 レイヤを並べる

このシリーズで採用する 6 レイヤは次の通り。観測層（Observability）はすべてのレイヤを横串に貫くため、6 + 1 と数える流派もあるが、本シリーズでは話を単純化するために「6 レイヤ + 観測横串」と整理する。

graph TB
    subgraph Observe["観測横串 (OTel / Eval / Guardrails)"]
        direction LR
        OBS[Layer 7: 観測・ガバナンス]
    end

    subgraph Stack["6 レイヤスタック"]
        direction TB
        L1[Layer 1: 推論・計画<br/>Reasoning / Planning]
        L2[Layer 2: ツール接続<br/>Tool Use / MCP / Computer Use]
        L3[Layer 3: メモリ・コンテキスト<br/>Memory / Context]
        L4[Layer 4: 実行環境<br/>Sandbox / Code Interpreter / Browser]
        L5[Layer 5: オーケストレーション<br/>Durable Execution]
        L6[Layer 6: 常時稼働の駆動<br/>Schedule × Event × Command]
        L1 --> L2 --> L3 --> L4 --> L5 --> L6
    end

    Observe -.- Stack

なお、この依存方向（Layer 1 が Layer 2 を呼び、Layer 5 が Layer 6 で起動される）は概念上の整理だ。実装上は Layer 5 や Layer 6 から Layer 1 が呼ばれることもある。**「下のレイヤが上のレイヤの下支えになる」**くらいに緩く読んでほしい。

各レイヤが何を解決するのか

各レイヤは、独立した「困りごと」に対する解だ。

Layer	解決する困りごと	代表的なソリューション
1. 推論・計画	長いタスクで計画が破綻する／ツール選択を間違える	Extended Thinking、Plan-and-Act、Orchestrator-Worker、Deep Research
2. ツール接続	20 個以上のツールで精度が落ちる／外部システム連携が脆い	MCP、Tool Search、Programmatic Tool Calling、Computer Use
3. メモリ・コンテキスト	長セッションで context が破綻／前回を覚えていない	Mem0、Letta、Zep、Anthropic Memory Tool、Compaction、Sleep-time
4. 実行環境	コード実行・ブラウザ操作の隔離が甘い／永続性がない	E2B、Daytona、Modal、Vercel/Cloudflare Sandbox、Firecracker microVM
5. オーケストレーション	クラッシュで最初からやり直し／HITL が組めない	LangGraph、Temporal、Restate、Vercel Workflow、Bedrock AgentCore
6. 常時稼働の駆動	cron だけ／event だけでは足りない／社内連携の経路がない	Claude Code Routines、ChatGPT Tasks、GitHub Agentic Workflows、NATS / Kafka
7. 観測・ガバナンス	失敗原因が特定できない／監査ログがない／コストが見えない	LangSmith、Langfuse、Arize Phoenix、OTel GenAI、NeMo Guardrails、OWASP Agentic Top 10

ここで重要なのは、6 レイヤすべてが揃ってはじめて「業務投入」の 4 条件（再現可能・耐故障・観測可能・管理可能）を満たせることだ。1 つでも欠けると、その欠けたところから業務側の現場で症状が噴き出す。

あなたが今、どのレイヤで詰まっているか

詰まりの症状からレイヤを逆引きする。読者が「自分はどこを読むべきか」を判断する地図にもなる。

症状	該当レイヤ	この記事のどこに書いてあるか
「LLM が間違ったツールを呼ぶ」「計画が途中で破綻する」	Layer 1	ch3 推論と計画
「MCP server を本番で使っていいか分からない」「Function Calling のトークン消費が大きすぎる」	Layer 2	ch4 ツール接続
「会話を続けると context window が破綻する」「以前の会話を覚えてくれない」	Layer 3	ch5 メモリとコンテキスト
「Code Interpreter が遅い／コストが破裂する」「Computer Use を本番に出せない」	Layer 4	ch6 実行環境
「LangGraph で組んだエージェントがクラッシュで全部やり直しになる」	Layer 5	ch7 オーケストレーションと durable execution
「Routines を使いたいが、cron では足りない／Slack イベントで起動したい」	Layer 6	ch8 常時稼働の駆動
「失敗原因が特定できない」「監査ログを出せない」「コストが見えない」	Layer 7	ch9 観測とガバナンス

6 レイヤと既存スタックの対応

この 6 レイヤは、世間で普及している既存の整理（LangChain Stack、AWS Agentic AI Reference Architecture、Anthropic の “Effective Agents” など）と矛盾しない。むしろそれらを **「フレームワーク中立」**に書き直したものだ。

たとえば LangChain 系の呼び方と本シリーズの呼び方は、おおむね次の対応がある。

本シリーズ	LangChain 系での呼び方
Layer 1: 推論・計画	LLM call / Reasoning
Layer 2: ツール接続	Tool / Tool Calling / MCP
Layer 3: メモリ・コンテキスト	Memory / RAG / Checkpointer
Layer 4: 実行環境	Code Interpreter / Sandbox
Layer 5: オーケストレーション	Graph / Workflow / Agent
Layer 6: 常時稼働の駆動	Trigger / Cron / Event
Layer 7: 観測・ガバナンス	Tracing / Eval / Guardrails

このスタックで「Devin」を覗いてみる

具体例として、Cognition の Devin を 6 レイヤで解剖するとこうなる。詳細は ch10 で扱うが、地図のサンプルとして先取りする。

Layer	Devin での実装
1. 推論・計画	LLM + RL でファインチューニングした計画器（詳細非公開）。長期タスク用の orchestrator
2. ツール接続	専用 IDE / shell / browser、MCP は限定的に対応
3. メモリ・コンテキスト	長期 state（codebase 知識を保持）、failed approaches の記録
4. 実行環境	専用クラウド sandbox、IDE / shell / browser を統合
5. オーケストレーション	journal-replay 風の long-running session 管理（中身は非公開）
6. 常時稼働の駆動	Linear / Jira / Slack の ticket 起点（イベント駆動）
7. 観測	内部観測あり、ユーザー側にも一定範囲の trace UI を提供

このように 6 レイヤでマッピングすると、**「Devin が他の coding agent と何が違うか」**を比較できる土台ができる。同じ手法で Manus、ChatGPT Agent、Claude Code Routines、Copilot Workspace を読み解くのが ch10 の仕事だ。

❌ 悪い構成 / ✅ 良い構成

業務に投入できないエージェント実装の典型を、6 レイヤで対比する。

❌ よくある「Demo」スタック
─────────────────────────
Layer 1: GPT-4 を直接呼ぶ
Layer 2: Function Calling を 20 個並べる
Layer 3: なし（context window 任せ）
Layer 4: subprocess で localhost のシェルを叩く
Layer 5: Python の for ループで多段呼び出し
Layer 6: なし（手動実行）
Layer 7: print デバッグ

→ 5 ステップ目で context あふれ、subprocess が暴走、再実行で全部やり直し

✅ 業務投入できるスタック（最小構成）
─────────────────────────
Layer 1: Claude Opus 4.7 + Adaptive Thinking
Layer 2: MCP server 経由（Tool Search 有効）
Layer 3: Anthropic Memory Tool + 外部 vector DB（4 レイヤ合成）
Layer 4: E2B Firecracker microVM（egress allowlist）
Layer 5: Temporal で journal+replay（HITL gate あり）
Layer 6: Schedule + GitHub event + slash command の 3 軸
Layer 7: OpenLLMetry → Langfuse、agentevals で trajectory eval

→ クラッシュしても続きから、20 ツールでも精度 90%、監査ログで誰が何をしたか追える

「✅」側に書いてある製品名は一例にすぎない。各レイヤで何を選ぶかは ch3〜ch9 で扱う。

このスタックの限界

この 6 レイヤモデルは万能ではない。次のような扱いには向いていない。

ローカル単発スクリプト：1 ファイルで完結する python script.py 級の使い方には、このスタックは過剰
エンドユーザー UI：チャット UI そのものや、Notion / Slack のような統合面は、6 レイヤの上にさらに載る層
学習・モデル本体：この記事はモデル外側を扱う。モデル fine-tuning や RL は別領域

逆に、業務に投入する自律エージェントを「1 人開発から 10 チーム使用へ」スケールさせる時、この 6 レイヤすべてを意識する瞬間が必ず来る。その時にこの地図に戻ってくれば、何を作り、何を買い、何を諦めるかの判断ができる。

次章への接続

ch3 では、6 レイヤの最上層にあたる Layer 1: 推論・計画 を扱う。Extended Thinking がなぜ「業務に投入する」エージェントに必須なのか、Plan-and-Act が WebVoyager で 81.36% を出した仕組み、Anthropic Multi-agent Research が +90.2% / 15× コストで何を学んだか、Deep Research 4 系統（OpenAI / Gemini / Perplexity / Anthropic）が同じ問題にどう違う解を出したかを、順に読み解く。

この章のまとめ

6 レイヤ + 観測横串の地図で AI エージェント技術を整理する：推論・計画 / ツール接続 / メモリ / 実行環境 / オーケストレ / 常時稼働 / 観測
業務投入の 4 条件（再現可能・耐故障・観測可能・管理可能）を満たすには 6 レイヤすべてが揃う必要がある
症状からレイヤを逆引きできる：「context window が破綻」→ Layer 3、「クラッシュで全部やり直し」→ Layer 5
既存スタック整理（LangChain・AWS・Anthropic）と矛盾しない：本シリーズはそれらをフレームワーク中立に書き直したもの
Devin / Manus / ChatGPT Agent を同じ 6 レイヤで読み解ける（ch10 で実演）

6 レイヤモデル ─ Agent ＝ モデル + ハーネス

6 レイヤを並べる

各レイヤが何を解決するのか

あなたが今、どのレイヤで詰まっているか

6 レイヤと既存スタックの対応

このスタックで「Devin」を覗いてみる

❌ 悪い構成 / ✅ 良い構成

このスタックの限界

次章への接続

この章のまとめ

6 レイヤモデル ─ Agent ＝モデル + ハーネス