エピローグ ─ 三部作統合と参考文献

2026/05/10

エピローグ ─ 三部作統合と参考文献

これで三部作が完結した。

✅ 第1部 [完結] 技術スタック編          ──「何があるか」 (10 章)
✅ 第2部 [完結] アーキテクチャパターン編   ──「どう組み合わせるか」 (8 章)
✅ 第3部 [本作] 運用工学編              ──「壊れずに動き続けさせる」 (10 章)

合計 28 章で、自律 AI エージェントを業務に投入する全工程を地図化した。本章では、三部作を1 枚の総合チェックリストにまとめ、姉妹シリーズとの接続を整理し、次のステップを示す。

三部作の 1 枚地図

graph TB
    subgraph T1["第1部: 技術スタック (部品)"]
        L1[Layer 1-7]
        L1_1[L1: 推論・計画]
        L1_2[L2: ツール接続]
        L1_3[L3: メモリ]
        L1_4[L4: 実行環境]
        L1_5[L5: オーケストレ]
        L1_6[L6: 常時稼働]
        L1_7[L7: 観測]
    end

    subgraph T2["第2部: パターン (形)"]
        P1[8 基本パターン]
        P2[6 トポロジー]
        P3[5 古典]
        P4[HITL 設計]
        P5[アンチパターン]
    end

    subgraph T3["第3部: 運用工学 (生かし方)"]
        O1[SRE / SLO]
        O2[Drift]
        O3[Cost runaway]
        O4[Memory poisoning]
        O5[Tool failure]
        O6[HITL SLA]
        O7[Continuous eval]
        O8[Incident response]
    end

    T1 --> T2 --> T3 --> Done[業務に投入<br/>動き続ける<br/>エージェント]

総合チェックリスト

三部作の知見を**「自社のエージェントを業務投入する前のチェックリスト」**として 1 枚に集約する。

第1部：技術スタック（部品の点検）

✅ Layer 1: 推論・計画
□ Extended Thinking のブロックを次ターンに保持
□ Plan-and-Act パターンで Planner / Executor を分離
□ 5 ステップ以上は Orchestrator-Workers
□ 失敗履歴を CHANGELOG.md / journal に永続化

✅ Layer 2: ツール接続
□ MCP server は OAuth 2.1 + RFC 8707 を満たす
□ Tool Search Tool でツール定義を動的ロード
□ Programmatic Tool Calling で context 肥大を回避
□ Computer Use は VM + 公式 reference image + MCP gateway 経由

✅ Layer 3: メモリ
□ 4 レイヤ合成（Checkpointer + Memory Tool + Mem0/Zep + 永続 DB）
□ Compaction + 外部ファイル + Just-in-time の 3 戦略
□ Sleep-time / Dreaming で idle 時に再編成
□ 衝突解決を書き込み前に挟む

✅ Layer 4: 実行環境
□ 隔離は Firecracker microVM（or V8 isolate）
□ 短命 sandbox + 外部 state の二段構え
□ Egress は default-deny + allowlist
□ secret は credential broker から短命トークン

✅ Layer 5: オーケストレーション
□ Durable execution（journal + replay）
□ HITL は durable な step として書く
□ クラッシュ復旧テストが CI に組み込まれている

✅ Layer 6: 常時稼働
□ Schedule × Event × Command の 3 軸
□ Event-driven の経路（NATS / Kafka / Webhook）

✅ Layer 7: 観測
□ OTel 互換の計装（OpenLLMetry など）
□ 3 層 eval（outcome / trajectory / meta）
□ 監査ログ 8 要素
□ 「tokens per feature」と 85/10/5 split

第2部：パターン（形の点検）

✅ パターン選択
□ Workflow か Agent か明確
□ Augmented LLM の最小単位が組めている
□ Routing / Parallelization / Orchestrator-Workers のどれを使うか根拠
□ Multi-agent の 15× tokens の ROI 条件を満たしている
□ Harness + Sandbox を被せている

✅ トポロジー選択
□ タスクの性質（前提共有度・並列性）に合った選択
□ Premature multi-agent を避けている
□ Swarm を選んでいない（実本番限定的）
□ A2A / MCP / AGENTS.md / Skill spec の 4 軸で接続

✅ 古典パターン
□ ReAct で Thought / Action / Observation を 3 列分解可能
□ Reflexion 風 CHANGELOG.md
□ Plan-and-Act で Planner と Executor を分離
□ Voyager 風 Skills で再利用可能なスキル蓄積

✅ HITL 設計
□ 差し込み 6 箇所のうちどれを採用するか明確
□ 実装 6 パターンを組み合わせ
□ 4 リスク（承認疲れ / Rubber-stamp / ボトルネック / 自動化バイアス）への対処
□ 「1 セッション 10 件以下」維持
□ HITL を「責任」のために残す
□ audit trail に WHO + WHY

✅ アンチパターン回避
□ 4 根因（複雑性信仰 / 終了条件不在 / モニタリング不在 / リスクティア不在）を意識
□ 「Add tools before adding agents」原則

第3部：運用工学（生かし方の点検）

✅ SRE for AI agents (ch2)
□ agentic SLI 4 種（TCR / TIE / DQR / CpT）を測定
□ SLO をリスクティアで分ける
□ Hard cap from Day 1（per-task cost / step counter / token budget / round-trip）
□ Error budget を週次で見て、足りなければ deploy 凍結

✅ Drift (ch3)
□ Pinned snapshot を本番で必ず使う
□ Promptops（registry + PR + canary + golden dataset）
□ Cache TTL を明示指定（1h なら ttl: "1h"）
□ Daily Drift Dashboard（モデル + プロンプト + データ）

✅ Cost runaway (ch4)
□ Hard cap 5 種（per-task / step / token / round-trip / wall-clock）
□ 85/10/5 split のモデルルーティング
□ Prompt cache を最大限活用、cache hit 率を測定
□ Batch API で夜間 50% off
□ 長コンテキスト課金の罠（GPT-5.4 272K, Gemini 200K）を避ける

✅ Memory poisoning (ch5)
□ 3 戦略を必ず混合（温存 / 浄化 / 隔離）
□ Origin tag を memory entry に必須付与
□ AgentDojo 風 attack eval を週次で実施

✅ Tool failure (ch6)
□ Circuit Breaker（fail fast）
□ Bulkhead（pool 分離）
□ Idempotency key（副作用 1 回）
□ Saga / Compensation pattern
□ Token budget enforcer を全層に被せる
□ MCP server を gateway 経由で集約

✅ HITL SLA (ch7)
□ 4 軸（応答時間 / エスカレーション / フォールバック / 監査ログ）
□ リスクティア別の SLA（Critical 1h、High 4h、Medium 8h、Low 24h）
□ 承認疲れの SLI（per-session 件数 / 承認時間 / reason 文字数）

✅ Continuous evaluation (ch8)
□ CI eval と Production eval の二層
□ Tail-based sampling
□ Judge を月次 calibration（human 一致率 ≥ 90%）
□ Capability-based canary

✅ Incident response (ch9)
□ 6 種の Runbook が言語化されている
□ 5 分以内のトリアージ
□ Kill switch の発動権限を on-call に
□ Audit log の WHO / WHEN / WHAT / WHY
□ Postmortem は blameless で Runbook フィードバック

このチェックリスト全部に ✅ が付いた時、自律エージェントを業務に投入し、動かし続ける状態だ。

三部作で扱った主要な数字

各部で扱った重要な数字を 1 枚で振り返る。

数字	意味	出典
+90.2% / 15× tokens	Anthropic Multi-agent Research のシングル比	Part 1 ch3, Part 2 ch3
OSWorld 79.6%（人間 72.36%）	Computer Use の人間越え	Part 1 ch4
トークン -84% / 精度 +39%	Memory Tool + Compaction の効果	Part 1 ch5
MT-Bench で 85% 削減	85/10/5 split routing のベンチ値	Part 3 ch4
30-60% 削減	同 routing の production 現実値	Part 3 ch4
$47,000 / $437	暴走事故のトークン焼失	Part 3 ch1, ch4
25.9% / $1,581	2026-03 cache TTL silent regression のコスト増	Part 3 ch3
50 件 / 31 社 14 業界	Microsoft 観測の memory poisoning 60 日	Part 3 ch5
3,600× speed gap	AI 50ms vs 人間 180s	Part 3 ch7
~99% auto-approve / 200×	OpenAI Codex Auto-Review	Part 3 ch7

姉妹シリーズとの統合

三部作は次のシリーズと地続きだ。

Claude Code 自走の作法（claude-code-autonomy-2026）

「個別実装側から見た自律性」L1〜L5 を、三部作の語彙で読み直すと：

L	第1部	第2部	第3部
L1: Skill	L2 ツール接続	Voyager + Augmented LLM	Skills の drift / poisoning 監視
L2: Hooks	L7 観測	Evaluator-Optimizer	SLO / Hooks の SLA
L3: GitHub Actions	L6 常時稼働	Pipeline + Event trigger	CI eval + canary
L4: Routines	L6 常時稼働	Pipeline + Schedule	Cost monitoring + budget
L5: Multi-agent	L5 オーケストレ	Orchestrator-Workers + Hierarchical	Tool failure + Memory poisoning

ハーネスエンジニアリング（harness-engineering-2026）

第1部 ch3 / 第2部 ch2 で扱った Harness + Sandbox パターンの理論的・歴史的背景。

プラットフォームエンジニアリング実践（platform-engineering-practices-2026）

エージェント基盤を「社内プラットフォーム」として組み立てる視点。第3部の運用工学を、プラットフォーム化の文脈で深掘り。

次のステップ

三部作を読み終えたあなたが次にやるべきことを 5 つ提示する。

1. 自社のエージェントを 28 項目チェックリストで点検

1 つでも ✅ が付いていない項目があれば、そこが「業務投入の壁」だ。

2. 6 種の Runbook を言語化

インシデントが起きてからではなく、起きる前に書く。1 Runbook を書くのに 1 時間。6 時間で全社の運用品質が上がる。

3. Daily Drift Dashboard を 1 ページで作る

最低限：モデル退役通知 + プロンプト eval delta + 入力分布 PSI + コスト推移。Grafana / Datadog で 1 ページ。

4. Kill switch を実装

Token budget / step counter / wall-clock の hard cap をコードレベルで実装。alert ではなく enforcement。

5. AgentDojo 風 attack eval を週次で回す

Memory poisoning を事前に検知する仕組み。週 1 回 30 分の自動 eval で、数千ドルの事故を防げる。

三部作で諦めたこと

三部作も何かを諦めていることを正直に書く：

個別フレームワーク（LangGraph / Temporal / Datadog）の SDK チュートリアル：パターン語彙と運用思想に絞った
特定言語（Python / TypeScript / Rust）でのコード例：擬似コード中心
個別ベンダ製品の比較：ベンダ中立に書いた
エンタープライズ規制（SOC2 / GDPR / HIPAA）の詳細：触れたが深掘りはしていない
特定業界（金融 / 医療）の運用パターン：一般論に絞った

これらは別記事や姉妹シリーズに譲る。

おわりに

「Demo は派手なのに、業務に乗らない」── 第1部の冒頭で投げかけた問いに、三部作で答えた。

業務に乗せるためには、部品（第1部）+ 形（第2部）+ 生かし方（第3部）の 3 段階が必要だ。地図はこれで揃った。

ただし、地図は現実の業務には触れていない。あなたのチーム、あなたのユーザー、あなたの規制環境には、地図に書ききれない無数の事情がある。三部作のチェックリストを当てて、自社で何を諦めるかを決めるのは、最終的にはあなた自身の判断だ。

それでも、地図を持ってから決めるか、地図なしで決めるか、の差は大きい。あなたが地図を持ってから決められるよう、この三部作を書いた。

「動き続けるエージェント」は、業務の景色を確実に変える。それを安全に・経済的に・責任を持って動かすのが、これからの数年で求められる engineering の核心だ。

良き運用を。それでは。

参考文献

Anthropic

MCP / Tool Use

OpenAI

Microsoft

LangChain / LangGraph

Memory 専用基盤

Sandbox / Execution

Durable Execution / Orchestration

Observability / Eval / Guardrails

コスト・FinOps

HITL / Production

アカデミック古典

SRE 古典（AI 文脈に翻訳元）

三部作・姉妹シリーズ

この章のまとめ

三部作の総合チェックリスト：第1部 6 レイヤ + 第2部 8 パターン + 第3部 10 運用領域 = 28 項目
業務に投入できるエージェントは「部品 + 形 + 生かし方」の 3 段階：地図はこれで揃った
次にやるべき 5 つ：チェックリスト点検 / Runbook 言語化 / Daily Drift Dashboard / Kill switch / AgentDojo eval
三部作も諦めたことを正直に明示：個別 SDK チュートリアル / 特定言語コード / 個別ベンダ比較 / 規制詳細 / 業界特化
「動き続けるエージェント」は業務の景色を確実に変える：地図を持ってから決めるか否かが engineering の核心