はじめに
本記事は「Context Engineering 完全入門」シリーズの補章 C(最終回)です。
本編シリーズでは Manus、Anthropic、LangChain 等の業界研究を数多く参照しましたが、それらは コーディング Agent を前提とした設計 に基づいており、業務系にそのまま適用すると問題が生じる場合があります。
本補章の目的は、「業界研究を業務系エージェント開発に安全に適用するための翻訳ガイドを、シリーズとして体系化すること」 です。補章 A(VS Code Copilot Chat)、補章 B(Claude Code V2)で紹介した業界標準ツールの背景にある理論的知見を、業務系エージェント設計に活かすための実務指針を提示します。本記事では、業界研究の系譜、Manus の正体、業務系との不整合、6 原則の翻訳マトリクス、10 項目チェックリストを通じて、業界研究を批判的に読み解く力を養うことを目指します。
前回：補章 B Claude Code Task Tools V2 移行の教訓
次回：なし📌 補章 C:業界標準として確立した Context Engineering 論文の知見を、業務系で適用可能な形に翻訳します。本編記事 1〜8 の知見を「学術的根拠」と「業界研究」の両面から補強する内容です。
📝 本記事は、生成 AI で作成した草案をベースに、筆者が加筆・修正し、技術的な正確性を確認した上で公開しています。
📝 本記事の要点
- 問題: Manus 論文や Anthropic 公式の原則を 業務系にそのまま適用すると、PII・監査・マルチテナントで破綻する
- 解決: Manus 6 原則を「そのまま使える / 要翻訳 / 危険」の 3 カテゴリに分類した翻訳マトリクス + 10 項目チェックリスト
- 業務系への示唆: 「File System as Context」→ Resource Store パターン、「ファイル自由作成」→ 監査ログ + PII マスキング層の置き換え
業務系で AI エージェントを構築する全エンジニアの必読。Manus の原則を盲目的に適用する前に本章のチェックリストをご利用ください。
🎯 本記事の対象者
- 業界研究の系譜(Manus、Anthropic、LangChain 等)を体系的に知りたい
- Manus 論文を読んだが、業務系で適用する判断に迷っている
- 「Manus はコーディング Agent 前提」を踏まえて業務系で安全に適用したい
- 本書の 7 つの設計観点が業界共通語彙とどう対応するか整理したい
- シリーズ全体を業界研究の地図の中に位置付けたい
1. 業界研究の系譜(2023〜2026)
本節の位置付け
本節では、Context Engineering という分野が どのような理論的発見と実務的知見の積み重ねで形成されてきたか を時系列で整理します。特に 2025 年は「業界研究の集中発表年」であり、Manus・Anthropic・LangChain の 3 者が実務知見を体系化した重要な時期です。この系譜を理解することで、業界研究を批判的に読み解く土台ができます。
主要マイルストーン
| 時期 | 出来事 | 影響 |
|---|---|---|
| 2023/7 | Liu et al.「Lost in the Middle」論文 | Lost-in-the-Middle 問題 の理論的基盤 |
| 2025/7 | Manus 社「Context Engineering for AI Agents: Lessons from Building Manus」(Part 1) | 6 原則 が業界標準化 |
| 2025/7 | Chroma Research「Context Rot」 | 18 モデル全てで性能劣化を実証 |
| 2025/9 | Anthropic 公式「Effective context engineering for AI agents」 | 用語の 公式定義 |
| 2025/10 | Manus + LangChain(Lance Martin)共同ウェビナー | 3 戦略への整理(Reduce / Offload / Isolate) |
| 2025/12 | Philipp Schmid「Context Engineering for AI Agents: Part 2」 | Context Rot、Compaction vs Summarization、Agent Harness |
| 2026/2 | Claude Opus 4.6 リリース(MRCR v2 で 76%) | 長文脈性能が 309% 改善 |
| 2026/4 | GPT-5.5 リリース(MRCR v2 で 74%) | GPT-5.4 比で 約 2 倍改善 |
| 2026/5 | arXiv「Classifier Context Rot」 | 安全モニター失敗率 2〜30 倍 を実証 |
| 2026/6 | arXiv「Plan Persistence in LLM Agents」 | Recitation Pattern の理論的根拠 |
この系譜から読み取れる 3 つの傾向
上記のタイムラインを俯瞰すると、業界研究の進化には以下の 3 つの明確な傾向が見られます:
- 2023 年の理論的発見:「Lost in the Middle」論文で、LLM が長文脈の中盤情報を見落とす問題が学術的に実証されました。これが Context Engineering という分野の出発点です。
- 2025 年の実務知見の体系化:Manus・Anthropic・LangChain の 3 者が、本番運用で得た知見を体系的に公開した年です。この 3 者の視点の違い(Manus はコーディング Agent、Anthropic は API プロバイダ、LangChain はフレームワーク開発者)を理解することが、業界研究を批判的に読み解く鍵となります。
- 2026 年の理論的裏付け:2026 年に入って学術論文が実務知見を裏付ける形で公開されました。特に arXiv 2606.22953(Plan Persistence、本編第 7 回で扱った)は、Manus が提唱した Recitation Pattern の理論的根拠となる重要な論文です。
業界研究を読む際は、「いつ、誰が、どのような文脈で発表したか」を意識する ことが重要です。Manus は自社製品の知見、Anthropic は API 利用者への公式ガイドライン、LangChain はフレームワークのユーザー向け整理、と発表者の立場が異なります。同じ用語でも文脈が違えば意味が変わるため、業務系への適用時は必ず原典を確認しましょう。
2. Manus とは何か(重要な前提)
本節の位置付け
本節では、業界研究の中でも特に影響力の大きい Manus の概要を正確に理解すること を目的とします。Manus 6 原則を業務系に適用する判断で最も重要なのは、「Manus がどのような環境で動作するエージェントか」を知ることです。この前提を理解しないまま業務系に適用すると、後述の §3 で解説する不整合に直面します。
Manus の概要
| 項目 | 内容 |
|---|---|
| 正式名称 | 「general-purpose AI agent」(汎用 AI エージェント) |
| アーキテクチャ | Planner / Executor / Verifier の multi-agent |
| 基盤モデル | Claude 3.5/3.7 Sonnet |
| 実行環境 | Linux サンドボックス(Docker コンテナ、フルブラウザ + Python + Shell) |
| 平均ツール呼び出し回数 | 50 回/タスク |
| 平均入出力比 | 100:1 |
Manus が扱うタスクの実態
Manus はコード生成・実行、ブラウザ操作、ドキュメント生成、データ分析などを得意とする コーディング Agent 寄りの世界観 で設計されています。第 6 回でも触れましたが、Manus は クラウド上に用意された Linux 仮想環境 をエージェントに提供する設計です。エージェントごとに独立した Docker コンテナが起動し、ファイル作成・削除、Python 実行、ブラウザ操作を自由に行える設計となっています。
なぜこの前提が業務系適用で重要か
Manus の設計思想は「エージェントに専用の隔離環境を与える」という前提に基づいています。しかし業務系では:
- 業務データは 顧客テナントの既存インフラ(DB、Blob Storage、SharePoint など)にあり、エージェント専用の隔離環境を用意することが非現実的
- 顧客テナント内での 監査ログ保持義務・PII マスキング・アクセス制御 が必須
- セッション終了後もデータが残る(顧客所有データのため、勝手に削除できない)
この前提の違いを認識せずに Manus 6 原則をそのまま適用すると、次節で解説する不整合に直面します。Manus は 「コーディング Agent として最適化されている」 ため、業務系に適用する際は「翻訳作業」が必須です。
3. 業務系との不整合
本節の位置付け
本節では、Manus の前提と業務系へ適用する際の6 つの課題 を整理します。これらの課題を理解することで、次節の翻訳マトリクスの意義が明確になります。
衝突の本質
| Manus の前提 | 業務系適用時の課題 | 種別 |
|---|---|---|
| 仮想 Linux サンドボックスが提供される | 顧客テナント内に sandbox を作るのは非現実的 | 実行環境 |
| ファイルは作り放題 | ストレージは課金対象、容量制限あり | コスト |
| ファイルは消し放題 | 監査ログ保持義務 | コンプライアンス |
| エージェントがファイル所有 | データは顧客所有 | 権限 |
| ファイル = セッション一時 | データ = 永続資産 | データガバナンス |
| データ消去要求への即応 | GDPR、個人情報保護法 | 法令 |
上記は、Manus が コーディング Agent として最適化 されており、その環境では最適な設計です。問題は「異なる環境用に最適化された設計を、そのまま業務系に持ち込むこと」にあります。
業界研究の原則を業務系に適用する際は、「この原則の背景にある前提は何か」「業務系ではその前提が成立するか」 を必ず確認する必要があります。特に上記 6 つの課題は、業務系エージェント設計で頻繁に直面する問題であり、いずれも PoC 段階で気づかず本番運用直前に発覚するリスク があります。本節のチェック観点(実行環境、コスト、コンプライアンス、権限、データガバナンス、法令)を、業務系エージェントの設計初期段階で必ず確認することが推奨されます。
4. Manus 6 原則の業務系翻訳マトリクス
本節の位置付け
本節では、Manus 6 原則を業務系エージェントへの適用可能性で 3 カテゴリに分類 します。この分類は、業務系での実装判断において最も重要な指針となります。以下の 3 カテゴリで判断してください:
- そのまま使える:Manus 流の実装がそのまま業務系でも有効な原則
- 要翻訳:Manus 流の思想は有効だが、業務系ではストレージ・監査・テナント分離などの拡張が必要な原則
- 危険な適用:業務系ではそのまま実装すると PII・監査・コンプライアンスで破綻する原則
そのまま使える原則
これらの原則は、Manus のコーディング Agent 前提であっても、業務系エージェントでもそのまま適用できます。
| 原則 | 業務系での適用 | 本書の対応記事 |
|---|---|---|
| 1. KV-Cache 中心設計 | プロンプトキャッシュは API ベースで効くので業務系でも有効 | 第 2 回 |
| 2. Mask, Don't Remove | ツールセットを動的変更しないのは業務系でも正解 | 第 2 回、第 5 回 |
| 6. Don't Get Few-Shotted | 少数例の過剰模倣を避けるのは業務系でも有効 | 第 8 回 |
これら 3 原則は 業務系エージェントの基礎として最初から組み込む べき原則です。特に KV-Cache 中心設計(第 2 回の固定プレフィックス)は、業務系での コスト削減効果が最も大きい 施策の一つです。プロンプトキャッシュヒット時に 90% 割引が適用されるため、本番運用でのコスト差は非常に大きくなります。
要翻訳の原則
これらの原則は、Manus 流の思想は業務系でも有効ですが、業務系必須要件(監査・PII・テナント分離) に対応するための翻訳作業が必要です。
| 原則 | Manus 流 | 業務系への翻訳 | 本書の対応記事 |
|---|---|---|---|
| 3. File System as Context | サンドボックスのファイル | 構造化ストレージ + Resource URI(Resource Store パターン) | 第 3 回、第 6 回 |
| 4. Recitation Pattern | エージェントが todo.md を書く |
TODO ツール経由で構造化された永続ストレージへ | 第 7 回 |
| 5. Keep Wrong Stuff In | エラー履歴を context に残す | エラーは要約形式で残す、PII を含む生エラーは退避ストアへ | 第 3 回、第 6 回 |
これらの原則を業務系に適用する際は、「思想を残しつつ、実装を業務系用に置き換える」 ことが重要です。例えば「File System as Context」の思想は「大きなデータを Context から退避する」ことですが、業務系ではこの退避先を 監査ログ付きの Cosmos DB / Blob Storage に置き換えます。本編第 3 回の ResourceStore や第 6 回の AuditedOffloadStore は、まさにこの翻訳を実装したものです。
業務系では「危険」な適用
これらは Manus 流をそのまま実装すると、PII 漏洩・監査違反・データ損失 につながる可能性がある適用パターンです。業務系では必ず代替策を用意してください。
-
ファイルシステムへの自由書き込み → 必ず構造化されたストレージ抽象を挟む(第 6 回の
AuditedOffloadStore参照) - エージェント主体のファイル生成 → 承認ワークフロー or サンドボックスを噛ます
- 大量のセッション内ファイル → TTL とクォータを必ず設定
- エラーの生情報保持 → PII マスキング層を必ず通す
これらの「危険な適用」は、PoC 段階では動作するものの、本番運用開始後に法令違反やデータ漏洩として顕在化する ため、事後修正コストが非常に高くなります。特にマルチテナント SaaS では、1 件の PII 漏洩が全顧客の信頼失墜につながるため、業務系エージェント設計の初期段階で必ず代替策を組み込んでください。
5. Manus Part 2 の追加概念(2025/12)
本節の位置付け
本節では、2025 年 12 月に公開された Manus Part 2 で追加された 4 つの重要概念を解説します。これらは本編シリーズで扱った設計原則の 理論的裏付け となる知見であり、業務系エージェント設計の判断根拠として活用できます。
Context Rot
Chroma Research (2025/7) と Philipp Schmid (2025/12) が体系化した概念です:
"(訳) LLM のパフォーマンスが、技術的な context ウィンドウ上限には十分収まっているにもかかわらず、context ウィンドウが埋まっていくにつれて劣化する現象"
多くのモデルで実効 context window < 256K トークンで、1M トークン時代でも問題は解決していません。詳細は本編第 1 回で扱っています。
この現象は業務系での長時間タスクや大量データ処理で 予期せぬ品質劣化 の原因となります。context window の技術的な上限だけを見て「まだ余裕がある」と判断すると、実際には性能が劣化しているケースがあります。業務系では、実効的な性能維持のために、Compaction や Offload で context を積極的に管理する ことが本番運用の鍵となります。
Compaction vs Summarization の区別
この区別は本編第 3 回・第 4 回の中核概念であり、業務系エージェント設計で最も重要な理論的知見の一つです。
| 手法 | 性質 | 例 |
|---|---|---|
| Compaction | Reversible(可逆) | 500 行のコードを「Output saved to /src/main.py」に置換。必要時に read_file で復元可能 |
| Summarization | Irreversible(不可逆) | 会話履歴を要約。元の詳細は失われる |
Compaction を Summarization より優先せよという原則は、本編第 3 回、第 4 回に深く反映されています。
業務系では、Summarization(不可逆な要約)は監査要件や再現性の観点で採用しにくいケースが多い ため、Compaction を優先することが特に重要です。例えば金融・医療・法律などの規制業界では、「エージェントがなぜその判断をしたか」を後から追跡できることが必須要件となり、元データを失う Summarization は原則採用できません。第 3 回で扱った ResourceStore によるトリミング後の全文保存は、業務系でのこの要件に対応する典型的な実装パターンです。
Agent Harness 概念
Manus Part 2 で明確化された重要な概念です:
"(訳) Agent Harness とは、モデルをラップし、ツール呼び出しの実行、メッセージ履歴ループの管理、そして Context Engineering ロジックを扱うソフトウェアのことです"
Agent Harness という概念は、業務系エージェント設計における 「LLM とアプリケーションの間の抽象化レイヤ」の重要性 を明示した重要な概念です。第 8 回で扱った「ベンダー中立設計戦略」の理論的根拠でもあります。業務系エージェント開発では、この Agent Harness 層を独自実装するのではなく、Microsoft Agent Framework (MAF) のような既存フレームワークを活用することで、長期的な保守性とベンダー中立性を担保できます。
3 戦略(Reduce / Offload / Isolate)
Manus + LangChain 共同ウェビナー (2025/10) で整理された 3 戦略は、本書の 7 つの設計観点と綺麗に対応します。
| Manus の 3 戦略 | 内容 | 本書の対応する設計観点 |
|---|---|---|
| Reduce Context | tool result の full / compact 二段階表現 |
設計観点 2, 3 |
| Offload Context | ファイルシステムに退避(業務系翻訳版は ResourceStore) | 設計観点 5 |
| Isolate Context | サブエージェントによる分離 | 設計観点 4 |
この 3 戦略は、業務系エージェントの Context 管理を どの層で行うか を整理するフレームワークとして活用できます。例えば「大量データを扱うタスク」では 3 戦略すべてを組み合わせる(Reduce で結果を圧縮 + Offload で退避 + Isolate でサブエージェントに委譲)ことで、context の破綻を防ぐ設計が可能になります。
📌 RAG との関係:Manus 3 戦略のうち Reduce Context および Offload Context は、業務系エージェントでは RAG(Retrieval Augmented Generation) の実装として具体化されるケースが多いです。RAG は Knowledge Context の主要実装手段であり、業務系では Cosmos DB Vector Search / Azure AI Search / Elasticsearch 等が推奨バックエンドとなります。
6. 本書の 7 つの設計観点と業界研究のマッピング
本節の位置付け
本節では、本書の 7 つの設計観点が、業界研究の主要な語彙とどう対応するかを整理します。この対応表は、本書と他の業界資料(Manus、Anthropic、LangChain、Anthropic 公式)を 横断的に読み解くためのマッピング を意図しています。
マッピング表
| 本書の設計観点 | Manus 6 原則 | Manus 3 戦略 | LangChain W/S/C/I | Anthropic 公式 |
|---|---|---|---|---|
| 設計観点 1: ツール設計 | 原則 1 (KV-Cache), 原則 2 (Mask) | - | Select の前提 | Curating tools |
| 設計観点 2: 結果ハンドリング | - | Reduce Context | Compress | Tool result truncation |
| 設計観点 3: 履歴圧縮 | - | Reduce Context | Compress | Compaction edits |
| 設計観点 4: サブエージェント | 原則 2 (Mask の文脈) | Isolate Context | Isolate | Multi-agent |
| 設計観点 5: Memory | 原則 3 (File System) ※業務系翻訳 | Offload Context ※業務系翻訳 | Write | Memory |
| 設計観点 6: TODO / Recitation | 原則 4 (Recitation) | - | Write | Plan tracking |
設計観点 7: Skills / AGENTS.md
|
原則 6 (Don't Get Few-Shotted) | - | Select + Write | Skill packaging |
この対応表の意義
上記の対応表は、以下 3 つの実務的な意義があります:
- 業界資料の横断的な読解: 本書のどの記事が、他の業界資料のどの部分に対応するかが一目で分かります。例えば「Anthropic 公式の Curating tools」を読む際は、本書の第 2 回(ツール設計)と並行して読むことで理解が深まります。
- 業界共通語彙の習得: 「Compress」「Isolate」「Write」など、業界共通で使われる語彙が、本書のどの設計観点に対応するかを把握できます。これにより、業界他資料を読む際の学習コストが大幅に削減されます。
- 設計判断の裏付け強化: 業務系エージェントの設計判断を上司や顧客に説明する際、「本書 X 記事の設計は、Manus 原則 Y、Anthropic 公式 Z にも対応している」と業界的な裏付けを示せます。
このマッピング表を 社内の設計レビューや技術ドキュメントの参照資料として活用 することも可能です。特にエンタープライズ企業では、「なぜこの設計を採用したか」の根拠として業界標準を示すことで、承認プロセスを円滑にする重要な要素となります。
7. 採用前チェックリスト 10 項目
本節の位置付け
本節では、業務系エージェントに Manus 由来のパターンを実装する前に、必ず確認すべき 10 項目のチェックリスト を提供します。このチェックリストは、業務系エージェント開発の PoC → 本番移行の判断基準として、そのまま活用できる実務ツールです。
データガバナンス関連(3 項目)
- エージェントが書き込むデータに PII が含まれる可能性はあるか?
- データ消去要求(GDPR 等)への対応は実装済か?
- 監査ログの保持義務に対応した append-only 設計か?
データガバナンス関連の 3 項目は、法令違反リスクに直結する最重要項目 です。特に PII を含む可能性がある場合、第 6 回で扱った AuditedOffloadStore のような PII マスキング + 監査ログの仕組みを最初から組み込むことが必須です。事後対応は原則的に不可能(既に漏洩している可能性がある)ため、設計段階で必ず確認してください。
マルチテナント関連(2 項目)
- テナント分離は実装済か?(Skills / Memory / Storage 全て)
- 1 テナントの暴走が他テナントに影響しない設計か?
マルチテナント SaaS では、1 テナントの問題が他テナントに波及する設計は契約違反リスク となります。第 5 回の SubAgentCatalog、第 6 回の AuditedOffloadStore、第 8 回の MultiTenantSkillsProvider はいずれもテナント分離を実装レベルで強制する設計であり、これらを組み合わせることで業務系必須要件を満たせます。
実行環境関連(3 項目)
- エージェントの実行環境は適切に隔離されているか?
- ストレージ容量の上限は設定されているか?
- TTL は設定されているか?
実行環境関連は、リソース枯渇による全体障害の防止 に直結します。特にエージェントが自由にファイルを作成できる設計では、TTL 設定なしでは容量が無限に膨張します。第 6 回で扱った代替策(Repository Memory + ファイル制限、Resource Store + Reference、Audit-log 駆動の Append-only)は、これらのリスクに対応する典型的な設計パターンです。
コスト関連(2 項目)
- トークン消費の上限は設定されているか?
- KV-Cache 最適化(第 2 回)は実装済か?
コスト関連は、本番運用でのランニングコスト削減の観点で最も費用対効果が高い 項目です。第 3 回で扱った Token Budgeting による予算配分と、第 2 回のプロンプトキャッシング最適化を組み合わせることで、業務系での月額コストを大幅に削減できます。特にプロンプトキャッシュヒット時の 90% 割引は、大規模運用では月数百万円規模のコスト差につながります。
すべて Yes になってから採用する
上記の 10 項目 すべてが Yes になってから、Manus 由来のパターンを段階的に導入すること を強く推奨します。1 項目でも No がある状態で本番運用を開始すると、法令違反、コスト暴走、データ漏洩のいずれかのリスクが顕在化する可能性があります。
8. 業務系での優先順位ランキング
本節の位置付け
本節では、業務系エージェント開発で Manus 6 原則をどの順序で実装すべきか の優先順位を示します。すべてを同時に実装するのは非現実的なため、費用対効果と業務系適性の観点で優先順位を明確化 することが重要です。
優先順位ランキング
| 順位 | 原則 | 業務系での優先度 | 理由 |
|---|---|---|---|
| 1 | KV-Cache 最適化(原則 1) | 必須 | コスト直結、業務系でも 100% 適用可 |
| 2 | Mask, Don't Remove(原則 2) | 必須 | ツールセット安定化はキャッシュとガバナンス両面で有効 |
| 3 | Don't Get Few-Shotted(原則 6) | 重要 | 業務系の few-shot 設計に直結 |
| 4 | Recitation Pattern(原則 4) | 重要 | TODO ツール(第 7 回)と統合可能 |
| 5 | Wrong Stuff In(原則 5) | 条件付き | PII 制約下で「要約形式」に変換すれば適用可能 |
| 6 | File System as Context(原則 3) | 避ける or 厳格な代替 | 業務系では Resource Store パターンに置き換え |
優先順位の判断根拠
このランキングは、以下 3 つの観点で判断しています:
- 業務系適性: そのまま業務系で使えるか、翻訳が必要か、危険か
- 費用対効果: 実装工数に対する運用効果の大きさ
- PoC からの実装難易度: 既存の PoC からどれだけ改修が必要か
順位 1・2 は 業務系の基礎として最初から組み込む べき原則で、費用対効果も最大です。順位 3・4 は 業務系での中期的な差別化要因 となり、順位 5・6 は 業務系での慎重な取り扱いが必要 な原則です。
業務系エージェントの PoC から本番移行の際は、まず順位 1・2 を確実に実装 し、次に順位 3・4 を段階的に追加、最後に順位 5・6 を業務要件に応じて選択的に導入することを推奨します。この段階的アプローチにより、リスクを最小化しつつ、業務系必須要件を漏れなく満たすエージェントを構築できます。
9. 業界研究を学ぶ正しい姿勢
本節の位置付け
本節では、業界研究を 業務系エージェント開発者として批判的に読み解く姿勢 を整理します。業界研究は日々更新されるため、個別の内容を暗記するのではなく、「どう読むか」の姿勢を身に付けること が長期的な設計判断力の向上につながります。
✅ 正しい姿勢
- 論文の文脈(Manus は何の前提か)を理解 する
- 業務系との不整合を明示的に整理 する
- そのまま適用せず、翻訳する
- チェックリストで段階的に導入 する
正しい姿勢の 4 つのポイントは、「原典を読む → 前提を確認する → 翻訳する → 段階的に検証する」 という業務系エージェント開発の標準ワークフローとして活用できます。特に「そのまま適用せず、翻訳する」という姿勢は、業界研究が急速に進化する中でも普遍的に有効な設計哲学です。
❌ 危険な姿勢
- 「業界標準だから」とそのまま実装 する
- コーディング Agent と業務系 Agentの違いを無視 する
- PII・監査・マルチテナントを後付けで対応 しようとする
危険な姿勢の 3 つは、業務系エージェント開発で最もよく見られる失敗パターン です。特に「後付けで対応しようとする」姿勢は、業務系での品質・コスト・スケジュールすべてに大きな悪影響を与えます。設計初期段階から「業務系必須要件は最初から組み込む」という姿勢を徹底することが、業務系エージェント開発の成功の鍵となります。
10. 🎉 シリーズ完結
全 8 本編 + 補章 3 本を通じて、Microsoft Agent Framework (MAF) での Context Engineering の体系を整理してきました。本節では、シリーズを通じて伝えたかった 7 つのメッセージを、業務系エージェント開発者への実務指針として最後にまとめます。
1. Context Engineering は本番運用に必須
PoC 止まりにしないため、Context Engineering は本番運用の必須要件です。第 1 回で示した 7 つの設計観点は、いずれも本番運用で欠かすことのできない要素です。
2. 7 つの設計観点はどれも欠けると破綻する
第 2 回のツール設計、第 3 回の結果ハンドリング、第 4 回の履歴圧縮、第 5 回のサブエージェント、第 6 回の Memory、第 7 回の TODO、第 8 回の Skills & AGENTS.md は、それぞれ独立した観点ではなく、相互に補完し合う総合的な設計体系 です。1 つでも欠けると本番運用で必ず問題が発生します。
3. ベンダー中立設計戦略が現代の正解
第 8 回で扱った「ベンダー中立設計戦略」は、単一ベンダー依存のリスクを回避しつつ、複数ツールから設計パターンを抽出・統合するアプローチです。5 年後の技術的負債を防ぐため、業務系エージェント開発では最初からこの戦略を採用することを推奨します。
4. 本番テレメトリで設計判断する
補章 A の VS Code Copilot Chat の grep_search 最適化(-55% トークン削減)、補章 B の Claude Code V1 → V2 移行事例が示すように、本番ユーザーの行動データに基づく設計判断 が、開発者の思い込みで作った機能よりも大きな成果を生みます。
5. 破壊的変更は段階的に
補章 B の Claude Code V1 → V2 移行から学んだ普遍的な教訓です。業務系 SaaS でも、破壊的変更は最低でも 3 フェーズ(V2 追加 → デフォルト切替 → V1 削除)を数ヶ月かけて段階的に実施することが、顧客への混乱を最小化する鍵となります。
6. 永続化を最初から前提に
補章 B の教訓 4 でも扱いましたが、インメモリ → 永続化への進化は不可避 です。業務系エージェント設計では、PoC 段階から IStateStorage などの抽象インターフェースを用意し、ローカルファイル実装 → Cosmos DB 実装 → Redis 実装への差し替えを容易にする設計が推奨されます。
7. 業界研究を「業務系翻訳」する
本補章の中心的なメッセージです。業界研究はコーディング Agent 前提の設計が多いため、そのまま適用ではなく、業務系の制約(監査・PII・マルチテナント)に合わせて調整する ことが重要です。§4 の翻訳マトリクスと §7 のチェックリストが、この翻訳作業の実務ツールとして機能します。
おわりに
長いシリーズにお付き合いいただき、ありがとうございました。
本シリーズは、Microsoft Agent Framework での Context Engineering を、業務系エージェント開発の視点で体系化しました。全 8 本編で 7 つの設計観点を、補章 3 本で業界標準ツールと業界研究の翻訳を扱いました。シリーズを通じて一貫してお伝えしてきたのは、「業界研究や業界標準ツールの知見を批判的に読み解き、業務系の制約に翻訳して適用する」 という姿勢です。
AI エージェント領域は変化が激しいため、本書の内容も将来は古くなる部分が出てきます。しかし「業界研究を批判的に読み、業務系の制約に翻訳する」という姿勢は普遍的に有効です。本書で整理したフレームワーク(3 軸評価、7 つの設計観点、Manus 翻訳マトリクス、10 項目チェックリスト)が、新しい論文や記事を読む際の「地図」として役立てば幸いです。
業務系 AI エージェントの本番運用が当たり前になる時代に向けて、本書が少しでもお役に立てれば幸いです。
参考文献
一次資料(必読)
Manus 論文・解説
- Manus AI / Yichao "Peak" Ji (2025/7/18). "Context Engineering for AI Agents: Lessons from Building Manus" (Part 1)
- Philipp Schmid (2025/12/4). "Context Engineering for AI Agents: Part 2"
- Lance Martin (2025/10/15). "Context Engineering in Manus" — LangChain × Manus Webinar 解説
- 0h-n0 TechBlog (2026/4/17).「Manus Engineering 解説: AIエージェントのための Context Engineering — 本番環境で得た実践的教訓」(日本語)
Anthropic 公式
- Anthropic Engineering (2025/9/29). "Effective context engineering for AI agents."
-
Anthropic Research (2023/9/23). "Prompt engineering for Claude's long context window."
- 補足: 最新モデル向けのガイダンスは Claude Platform Docs「Prompting best practices」 も参照。
学術論文
- Liu, N. F., et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts." Transactions of the Association for Computational Linguistics. arXiv:2307.03172
- Hong, K., Troynikov, A., & Huber, J. (2025/7/14). "Context Rot: How Increasing Input Tokens Impacts LLM Performance." Chroma Technical Report
- Mehta, A., & Datta, A. (Snowflake AI Research, 2026). "Plans Don't Persist: Why Context Management Is Load Bearing for LLM Agents." arXiv:2606.22953
業界共通語彙
- Drew Breunig (2025/6/22). "How Long Contexts Fail" — Four Failure Modes of Context (Poisoning / Distraction / Confusion / Clash)
- SurePrompts (2026/4/19, updated 2026/4/22).「Context Engineering Best Practices (2026): A 12-Point Checklist」
- AGENTS.md (Linux Foundation Agentic AI Foundation) — "A simple, open format for guiding coding agents"
LangChain / 4 戦略
-
LangChain Blog「Context Engineering for Agents」(2025/7/2) — Write/Select/Compress/Isolate framework
- 補足: 実装サンプルは
langchain-ai/context_engineering(4 つの Jupyter notebook)を参照。
- 補足: 実装サンプルは
- Lance Martin (2025/6/23).「Context Engineering for Agents」(個人ブログ版・LangChain Blog 記事の原案)
業務系適用のためのガバナンス資料
- GDPR Article 5「Principles relating to processing of personal data」(公式英訳、GDPR-info.eu)
-
個人情報保護委員会 (PPC)「法令・ガイドライン等」
- 補足: 法律本体の条文は https://laws.e-gov.go.jp/law/415AC0000000057 を参照。
-
Microsoft Learn「Tenancy models for a multitenant solution」(Azure Architecture Center)
- 補足: SaaS 全体像は 「SaaS and multitenant solution architecture」 も参照。
Microsoft Learn / Microsoft Agent Framework 公式
- Microsoft Learn「Microsoft Agent Framework — Overview」
-
Microsoft Learn「Microsoft Agent Framework — Context Providers」
- 補足: Python API リファレンスは
agent_framework.ContextProviderclass を参照。
- 補足: Python API リファレンスは
- microsoft/agent-framework — GitHub repository