目次を表示する

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

8 つの基本パターン ─ Anthropic 5+1 + Harness+Sandbox

8 つの基本パターン ─ Anthropic 5+1 + Harness+Sandbox

エージェントパターンの語彙が氾濫している現状を整理するには、最小限の 共通語彙 から始めるのがよい。本章では業界横断の調査から 8 つの基本パターンを抽出し、それぞれ「いつ使うべきか / 使ってはいけないか」のセットで定義する。

出発点:Anthropic「Building Effective Agents」の 5+1

業界の事実上の標準分類は、Anthropic が 2024 年 12 月に公開した Building Effective Agents だ。この記事の核となる主張は重要で、本シリーズ全体に影響する:

最も成功しているシステムは、複雑なフレームワークではなく、シンプルで構成可能なパターンの組み合わせを使っている。

そしてこの記事は Workflow vs Agent という対立軸を導入した。

  • Workflow:コードで制御フローを敷く。LLM はステップ内で使われるが、フローそのものは事前に決まっている
  • Agent:LLM がフローそのものを動的に決定する。ツールの選択も、終了タイミングも、LLM が判断

この区別が決定的だ。動的判断が要らないものを Agent で書くと、無駄な不確定性とコストを抱える。逆に、事前にフローが決められないものを Workflow で書くと、現実のタスクをカバーできない

5+1 の構成:

graph TB
    A[Augmented LLM<br/>全パターンの基盤]
    A --> W1[Prompt Chaining]
    A --> W2[Routing]
    A --> W3[Parallelization]
    A --> W4[Orchestrator-Workers]
    A --> W5[Evaluator-Optimizer]
    A --> AG[Autonomous Agent]

    W1 -.workflow.-> Static[静的フロー]
    W2 -.workflow.-> Static
    W3 -.workflow.-> Static
    W4 -.動的だが構造化.-> Mid[中間]
    W5 -.動的だが構造化.-> Mid
    AG -.純粋な動的.-> Dynamic[完全動的]

8 パターンを「8 つの問い」として定義する

本作では、Anthropic 5+1 に Autonomous Agent Loop(5+1 の右端を独立扱い)と Harness+Sandbox(OpenAI 2026-04 が確立)を加えて、合計 8 パターン を語彙とする。

各パターンは「どんな問いに答えるパターンか」として定義できる。

1. Augmented LLM ── 「LLM はそのままで使えるか?」

定義:retrieval(RAG)/ tools / memory を持つ拡張 LLM。すべてのエージェントの最小単位。

使うべき:すべての基盤として(単独評価不可) 使ってはいけない:(構成要素なので適用外)

LLM 単体では「最新情報が分からない」「外部システムを操作できない」「会話を覚えていない」。これを補うのが Augmented LLM。他の 7 パターンはすべてこの上に乗る

2. Prompt Chaining ── 「タスクは固定の連続ステップに分解できるか?」

定義:タスクを固定の連続ステップに分解。各ステップ間にプログラム的なゲート(バリデーション、条件分岐、フォーマット変換)を置く。

使うべき

  • サブタスクに割れる
  • 精度のためにレイテンシを犠牲にできる
  • 各ステップの境界が明確

使ってはいけない

  • ルーティングが動的
  • ステップが予測不能

:「翻訳 → 校閲 → 要約」「議事録抽出 → 構造化 → 要約」のような、順序が固定のワークフロー。

3. Routing ── 「入力をカテゴリ分けすると別の処理が要るか?」

定義:入力を分類して、それぞれ専用の後続タスクへ振り分ける。

使うべき

  • 入力カテゴリが明確
  • 専用処理が効果を出す(一般処理では不十分)

使ってはいけない

  • カテゴリが均質、専用化のメリットが小さい
  • 分類器の精度が低い(→ 全体の天井になる)

:「サポートチケットを billing / technical / sales に振り分け、それぞれ専用エージェントへ」。

4. Parallelization ── 「並列で速度・信頼性が出るか?」

定義:sectioning(独立な部分タスクに分割して並列)/ voting(同じタスクを複数回実行して多数決)の 2 形態。

使うべき

  • 並列化で速度が出る
  • 複数視点・多数決で信頼性が上がる

使ってはいけない

  • 順序依存
  • 中央集権的判断が必要

:sectioning は「ドキュメントを章ごとに分割して並列要約」、voting は「LLM を 5 回呼んで多数決で答えを決める」。

5. Orchestrator-Workers ── 「サブタスクが事前に決められないか?」

定義:中央 LLM(Orchestrator)が動的にサブタスクを分解しワーカーへ委譲。各ワーカーの結果を Orchestrator が統合する。

使うべき

  • サブタスクが事前に決められない
  • Orchestrator がリアルタイムで分解・再計画する必要

使ってはいけない

  • サブタスクが予め決まっている(→ Prompt Chaining でよい)

:Anthropic Multi-agent Research(Lead Opus + Sub Sonnet 3-5 個)。シングル比 +90.2% の性能だが約 15× トークン消費。

6. Evaluator-Optimizer ── 「反復で改善できるか?」

定義:生成役と評価役を分離してループ。生成 → 評価 → フィードバック → 再生成。

使うべき

  • 評価基準が明確
  • 反復で改善が見込める

使ってはいけない

  • 評価基準が曖昧
  • 一発回答で十分

:コード生成(生成 → テスト実行 → エラーを次プロンプトに → 再生成)。Reflexion 論文の影響を受けたパターン。

7. Autonomous Agent Loop ── 「オープンエンドな環境を任せられるか?」

定義:ツールと環境フィードバックで自律ループ。ReAct loop の本質。終了条件は完了 / 上限ステップ / 人間介入。

使うべき

  • オープンエンド、信頼できる環境、明確な成功基準あり
  • 動的にツール選択する必要

使ってはいけない

  • パスが予測可能(→ workflow へ)
  • ガードレール無し(→ 暴走)

:Devin / ChatGPT Agent / Claude Code の単一エージェントモードはこのパターン。

8. Harness + Sandbox ── 「長時間 / 常時稼働させたいか?」(2026 新パターン)

定義:エージェントの実行を Harness(モデル外側の枠組み)Sandbox(隔離実行環境) に分離するパターン。OpenAI Agents SDK 2026-04 update で正式に名前付きパターンとして確立。

Harness が担当する要素

  • instructions(CLAUDE.md / AGENTS.md)
  • tools(MCP / Function Calling)
  • approvals(HITL)
  • tracing(観測)
  • handoffs(エージェント間転送)
  • state management(journal)
  • sandbox 統合

使うべき

  • 長時間(24h 以上)動かしたい
  • 常時稼働させたい
  • セッション間で state を引き継ぎたい

使ってはいけない

  • 1 ショット・短命タスク(過剰な仕掛け)

:OpenAI Agents SDK 2026-04、Anthropic Effective Harnesses、Addy Osmani の Brain–Hands–Session 3 分割。第1部 ch3 で扱った Effective Harness と同じ概念。

8 パターンの関係性

これらは独立ではなく、包含・相補・直交の関係を持つ。

graph TB
    AL[Augmented LLM<br/>基盤]
    AL --> PC[Prompt Chaining]
    AL --> R[Routing]
    AL --> Pa[Parallelization]
    AL --> OW[Orchestrator-Workers]
    AL --> EO[Evaluator-Optimizer]
    AL --> AA[Autonomous Agent]

    HS[Harness + Sandbox] -.被せる.-> PC
    HS -.被せる.-> R
    HS -.被せる.-> Pa
    HS -.被せる.-> OW
    HS -.被せる.-> EO
    HS -.被せる.-> AA

    OW -.特殊形.-> PnA[Plan-and-Act]
    EO -.特殊形.-> Refl[Reflexion]
    AA -.基盤.-> ReAct[ReAct]

主な関係:

  • 包含:Autonomous Agent ⊃ ReAct ⊃ Augmented LLM
  • 相補:Routing × Orchestrator-Workers(静的 vs 動的)。Plan-and-Act は Orchestrator-Workers を時間軸で長く伸ばしたもの
  • 直交:Harness + Sandbox はどのパターンにも被せられる「実行基盤」レイヤ
  • 組み合わせ:実本番系(Anthropic Research, Magentic-One, CrewAI Crews)はほぼ全て Orchestrator-Workers + Evaluator-Optimizer + Parallelization のトリオ

各社のパターン体系の対応

冒頭で示した「業界がパターンに収束」しつつある事実を、対応表で確認する。

本作の 8 パターンLangGraph での呼び方OpenAI Agents SDKMicrosoft Agent FrameworkCrewAI
Augmented LLMtools + checkpointerAgent baseAgentAgent
Prompt Chainingsequential graphsequentialSequential workflowCrews (sequential)
Routingconditional edgehandoffsHandoff(該当パターン薄め)
Parallelizationparallel branchesparallelConcurrent workflowparallel tasks
Orchestrator-WorkersSupervisor patternsub-agents via handoffsGroup Chat / Magentic-OneCrews (hierarchical)
Evaluator-Optimizerreflection example(パターン名なし)RequestInfoExecutorCrews (consensual)
Autonomous Agent LoopReAct agentAgent loopAgent loopAgent loop
Harness + SandboxLangGraph itselfHarness (2026-04)Workflow + sandboxFlows

つまり どのフレームワークも 8 パターンに収まる。フレームワーク選択の議論を、パターンの議論に分離するのが本作の姿勢だ。

❌ 悪い使い方 / ✅ 良い使い方

❌ 悪い:Routing パターンで分類器が低精度
─────────
症状:分類が外れて間違ったエージェントに行き、回答品質が低い
原因:分類器の精度が全体の天井になる
脱出:分類器を強化するか、Orchestrator-Workers に切り替えて動的判断にする
❌ 悪い:1 エージェントで足りるところに Orchestrator-Workers を入れる
─────────
症状:トークンコスト 15× で性能向上 +5%
原因:タスクが Orchestrator-Workers の使うべき条件(重並列)を満たしていない
脱出:Single Agent + Augmented LLM に戻す。Truefoundry の "Add tools before adding agents"
✅ 良い:パターンを組み合わせて使う
─────────
例:「PR レビューエージェント」
- Routing:PR を 「semantic」 / 「test」 / 「performance」 に分類
- Orchestrator-Workers:分類後、Lead が 3 つの専門 Sub に並列レビューを委譲
- Evaluator-Optimizer:各 Sub が自己レビュー → 改善
- Harness + Sandbox:Sandbox 内で git checkout、テスト実行

業務投入の観点で重要な 3 点

  1. 「Workflow か Agent か」を最初に決める:動的判断が要らないなら workflow(Prompt Chaining / Routing / Parallelization)、要るなら agent(Orchestrator-Workers / Evaluator-Optimizer / Autonomous Agent Loop)。両者を混ぜたグラフは Microsoft Agent Framework が最も整理している
  2. Multi-agent は約 15× トークン:ROI が出るのは重並列・大量情報・多ツールの 3 条件が揃うときだけ。それ以外では Single Agent + Augmented LLM が最適解。Truefoundry / Augment Code「Add tools before adding agents」
  3. Harness + Sandbox は「常時稼働の前提条件」:第1部 ch3 / ch6 / ch7 を踏まえると、長時間動くエージェントには必ず必要。OpenAI が 2026-04 で正式パターン化した

次章への接続

8 つのパターンは「どんな処理をするか」の語彙だった。次章 ch3 では、これらのパターンを どう並べるか ── つまりトポロジーを扱う。Single / Supervisor-Worker / Swarm / Router / Hierarchical / Pipeline の 6 種を、**「常時稼働させたとき何が壊れるか」**の観点で比較する。さらに、エージェント間通信の標準である A2A プロトコルの現状も整理する。


この章のまとめ

  • 業界の標準分類は Anthropic「Building Effective Agents」の 5+1
  • 本作はこれに Autonomous Agent Loop と Harness+Sandbox を加えた 8 パターンを語彙とする
  • 各パターンは「どんな問いに答えるか」で定義できる:「LLM はそのままで使えるか」「タスクは固定ステップに分解できるか」など
  • 8 パターンの関係:包含・相補・直交・組み合わせ
  • どのフレームワーク(LangGraph / Agents SDK / Microsoft / CrewAI)も 8 パターンに収まる:フレームワーク選択は二次の問題