目次を表示する

AI エージェントを業務に組む ─ アーキテクチャパターンの地図

エピローグと第3部への伏線 ─ 運用工学編へ

エピローグと第3部への伏線 ─ 運用工学編へ

第2部 ch1 で「部品があってもパターンが間違うと業務に乗らない」と問題提起した。ここまでで、その問題に対する地図を渡した。

  • 8 つの基本パターン（Augmented LLM / Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer / Autonomous Agent Loop / Harness+Sandbox）
  • 6 つのトポロジー（Single / Supervisor-Worker / Swarm / Router / Hierarchical / Pipeline）
  • 5 つの古典パターン（ReAct / Reflexion / Plan-and-Act / Tree of Thoughts / Voyager）
  • HITL 設計の 3 軸（6 箇所 × 6 実装 + 4 リスク）
  • 8 つのアンチパターンと 4 つの根因
  • 7 製品の解剖マトリクス

これらを使って、自社のエージェントがどんな形で組まれているか、何を諦めるべきかを言語化できるようになっているはずだ。

パターン × トポロジー × HITL の統合チェックリスト

第2部で挙げた語彙を「自社のエージェントを組む前のチェックリスト」として 1 枚に集約する。

✅ パターン選択 (ch2)
□ Workflow か Agent かを最初に決めた
□ Augmented LLM の最小単位（tools + memory + RAG）が組めている
□ Routing / Parallelization / Orchestrator-Workers のどれを使うか根拠を持って選んだ
□ Multi-agent を入れるなら 15× tokens の ROI 条件（重並列・大量情報・多ツール）が満たされている
□ Harness + Sandbox（OpenAI 2026-04 パターン）を被せている

✅ トポロジー選択 (ch3)
□ タスクの性質（前提共有度・並列性）に合ったトポロジーを選んだ
□ Premature multi-agent を避けている（Single で済むなら Single）
□ Swarm を選んでいない（実本番で採用は限定的）
□ ネスト構造の場合、外側→内側で徐々に動的にしている
□ A2A プロトコル / MCP / AGENTS.md / Skill spec の 4 軸で接続を考えている

✅ 古典パターン (ch4)
□ ReAct（Thought / Action / Observation）でログを 3 列分解できる
□ Reflexion 風 CHANGELOG.md で失敗履歴を残している
□ Plan-and-Act で Planner / Executor を分離（Lead に高価モデル、Sub に安価モデル）
□ Voyager 風 Skills で再利用可能なスキルを蓄積

✅ HITL 設計 (ch5)
□ 差し込み 6 箇所のうち、どれを採用するか明確
□ 実装 6 パターン（Sync / Async / Watch / Spot / Tier / Retroactive）を組み合わせている
□ 4 リスク（承認疲れ / Rubber-stamp / ボトルネック / 自動化バイアス）への対処がある
□ 「1 セッション 10 件以下」の承認数を維持できている
□ HITL を「速度」でなく「責任」のために残している
□ audit trail に WHO + WHY を記録

✅ アンチパターン回避 (ch6)
□ 4 根因（複雑性信仰 / 終了条件不在 / モニタリング不在 / リスクティア不在）を意識
□ Pipeline には retry / 各 step 検証 gate がある
□ Reflection / Swarm / Pipeline には終了条件（上限ターン、閾値、改善検知）がある
□ Router は online eval で精度を常時監視
□ Lead 飽和に備えて Sub 並列度を 3〜5 に制限、Compaction を組み込み

✅ 製品比較 (ch7)
□ 自社タスクを 3 軸（前提共有度・範囲・リスク）で分類した
□ 似たタスクの本番製品が「何を諦めたか」を参考にしている
□ 「実行 → 検証 → 訂正」の 3 役を必ず入れている

このチェックリスト全部に ✅ が付いた時、本作の語彙でエージェントを組めている状態だ。

第1部・第2部のシナジー

第1部 ch10 のチェックリスト（6 レイヤ × 業務投入）と本作のチェックリストは重ねて使うことを想定している。

第1部 (技術スタック)        第2部 (パターン)
─────────                  ─────────
L1 推論・計画         ←→   ch4 古典パターン (ReAct, Plan-and-Act)
L2 ツール接続         ←→   ch3 トポロジー (A2A, MCP)
L3 メモリ            ←→   ch4 (Reflexion, Voyager)
L4 実行環境          ←→   ch2 (Harness + Sandbox)
L5 オーケストレ       ←→   ch3 (6 トポロジー)
L6 常時稼働          ←→   ch3 (常時稼働適性)
L7 観測             ←→   ch5 (HITL retroactive review, spot check)

つまり第1部の部品をそのまま第2部のパターンで並べるだけで、「業務投入できるエージェント」が組み上がる、という設計の流れになっている。

第3部（運用工学編）への伏線

本作の地図に従って組んだエージェントは、運用フェーズで新しい問題に直面する。第3部では次を扱う：

第3部の章立て予定（暫定）

ch1 プロローグ ─ 動くものから動き続けるものへ
ch2 Drift（ドリフト）── モデル更新で挙動が変わる
ch3 Cost runaway ── 予算の破裂と 85/10/5 split の運用テクニック
ch4 Memory poisoning ── メモリ汚染の温存・浄化・隔離戦略
ch5 Tool failure ── MCP server / API のダウンで連鎖する失敗の遮断
ch6 HITL の SLA 設計 ── 承認遅延でのフォールバック
ch7 Observability の運用パターン ── 何をいつ見るか
ch8 Recovery ── 障害復旧の runbook 化
ch9 エピローグ ─ 三部作の統合

第3部で繰り返し出てくる「運用の壁」

第2部のアンチパターン（ch6）と、第3部で扱う運用の壁は 同じ根因の表裏だ。

第2部のアンチパターン第3部で扱う運用の壁
Premature multi-agentデバッグ困難・コスト膨張
HITL 過多 / 放棄承認 SLA、監査ログ、規制対応
Pipeline SPOF障害復旧、retry/idempotency
Lead 飽和Compaction 戦略、メモリ汚染対処
Router silent driftonline eval、入力分布監視

つまり本作で扱った**「設計時の罠」が、運用フェーズでは「日常の症状」に変わる**。第3部はその症状にどう対処するかを扱う。

姉妹シリーズとの接続

最後に、本作と既存シリーズの接続を整理する。

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

姉妹シリーズの L1〜L5 自律性レベルを、本作のパターン語彙で読み直すと次のようになる。

自律性レベル第2部のパターン語彙
L1: Skill / Slash CommandVoyager + Augmented LLM（Skills を再利用可能な tool として呼ぶ）
L2: HooksEvaluator-Optimizer（自分の挙動を監視して再起動）+ Retroactive review
L3: GitHub ActionsPipeline + Event-driven trigger
L4: Scheduled / RoutinesPipeline + Schedule-based trigger + Harness + Sandbox
L5: Sub-agent / MCPOrchestrator-Workers + Hierarchical（A2A プロトコル経由）

つまり Claude Code の自律性レベルは、8 パターン + 6 トポロジー + HITL 設計の段階的な積み上げとして読み解ける。

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

本作 ch2 で扱った Harness + Sandbox パターンの理論的・歴史的背景は、姉妹シリーズの「ハーネスエンジニアリング」が深掘りしている。OpenAI が 2026-04 で正式名前付きパターンとして確立する以前から、Anthropic / 学術界で議論されていた経緯を辿りたい人はそちらを参照。

第2部で諦めたこと

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

  • 個別フレームワーク（LangGraph / CrewAI / Microsoft Agent Framework）の SDK チュートリアル：本作はパターン語彙に集中し、実装詳細は外した。各フレームワークの公式ドキュメントを参照
  • エンタープライズ統合（SOC2 / GDPR / HIPAA）の詳細：必要に応じて第3部で扱う
  • 特定言語（Python / TypeScript / Rust）でのコード例の網羅：擬似コード中心にした。実装は読者の言語環境に合わせてほしい
  • 個別 LLM プロバイダ（Anthropic / OpenAI / Google）の比較：本作はベンダ中立に書いた

参考文献

公式パターン

LangChain / LangGraph

OpenAI Agents SDK

Microsoft Agent Framework

CrewAI

A2A Protocol / Linux Foundation AAIF

アカデミック古典

HITL / Production

HITL リスク・運用

横断的整理

姉妹・関連シリーズ

おわりに

「Demo は走るのに、パターンが崩れると業務に乗らない」── 第2部の冒頭で投げかけた問いに、ここまでで一定の答えを出した。業務に乗せるためには、部品（第1部）+ パターン（第2部）の 2 段階の設計が必要だ。

ただし、設計が完成したからといって、運用が始まるとまた新しい問題が起きる。Drift / コスト破裂 / メモリ汚染 / Tool failure / 監視疲れ ── これらは設計の良し悪しと別に、「動かし続けると必ず起きる」現象だ。これを扱うのが次の第3部、運用工学編だ。

それまでに、本作のチェックリストを 1 つ手元のプロジェクトに当てて、自社のエージェントを「8 パターン × 6 トポロジー × HITL」で点検してみてほしい。多くの場合、パターン名で言語化した瞬間に、自分が何を諦めるべきかが見える。

3 部作の最終章でまた会いましょう。

この章のまとめ

  • 第2部で渡した地図：8 パターン × 6 トポロジー × 5 古典 × HITL 設計 × 8 アンチパターン × 7 製品解剖
  • 第1部 × 第2部のシナジー：部品 × パターンで業務投入できるエージェントが組み上がる
  • 第3部は「壊れずに動き続けさせる」：Drift / コスト / メモリ汚染 / Tool failure / SLA / Recovery
  • 本作のチェックリストを使って自社エージェントを点検：パターン名で言語化すると、何を諦めるべきかが見える