一行要約
エージェント的システムは「workflow（あらかじめ決めたコードパスで LLM を組み合わせる）」と「agent（LLM が自分で手順とツール使用を決める）」に分けられ、最も単純な解から始めて、複雑さが成果を実証的に改善するときだけ足すべきである。
要点
workflow と agent の区別
Workflows are systems where LLMs and tools are orchestrated through predefined code paths. workflow とは、LLM とツールが、あらかじめ定義されたコードパスを通じてオーケストレーションされるシステムである。
Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks. 一方 agent とは、LLM が自分自身のプロセスとツール使用を動的に方向づけ、タスクをどう達成するかの制御を保持するシステムである。
Agentic systems is the umbrella term. agentic systems が総称である。
基礎ブロック: Augmented LLM
すべての agentic system の土台。LLM に retrieval・tools・memory を付与したもの。モデル自身が検索クエリを生成し、ツールを選択し、何を保持するかを決める。
Workflow パターン 5種
| パターン | 内容 | 使うべきとき |
|---|---|---|
| Prompt chaining | タスクを逐次的なステップに分解し、各 LLM 呼び出しが前の出力を処理する。途中にプログラム的なゲート（検証）を挟める | タスクが固定のサブタスクに「容易かつ綺麗に」分解できるとき。latency を犠牲に accuracy を得る |
| Routing | 入力を分類し、専門化された下流タスクに振り分ける | 明確に分かれたカテゴリがあり、分類の精度が確保できるとき。小さいモデルへ回してコスト最適化する用途も |
| Parallelization | Sectioning（独立したサブタスクを並列実行）と Voting（同じタスクを複数回実行して多様な出力を得る）の2形態 | 並列化で速度が上がるとき、または複数視点で確信度を上げたいとき |
| Orchestrator-workers | 中央の LLM がタスクを動的に分解し worker に委譲、結果を統合する | 必要なサブタスクが事前に予測できない複雑なタスク。複数ファイルにまたがるコード変更など |
| Evaluator-optimizer | 一方の LLM が生成し、もう一方が評価フィードバックを返すループ | 明確な評価基準があり、反復的な改善が測定可能な向上を生み、人間が有用なフィードバックを言語化できるとき |
注: Orchestrator-workers と Parallelization/Sectioning の違いは、サブタスクを事前に決めているか実行時に決めているか。
Autonomous agents
LLM が環境からのフィードバックを見ながらループでツールを使い、独立して動く。人間のチェックポイントを挟むことがある。
- 使うべきとき: 必要なステップ数が予測困難または不可能な open-ended な問題で、固定パスをハードコードできないとき。
- 前提条件: 「その意思決定にある程度の信頼を置けること」。自律性が高い分、コストが上がり、エラーが複合的に蓄積するリスクがある。
- 例: SWE-bench のコーディングタスク、computer use。
エージェントを使うべきでないとき
中核原則:
When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. LLM でアプリケーションを作るときは、可能な限り単純な解を見つけ、必要になったときにだけ複雑さを増すことを勧める。
Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense. agentic system は、より良いタスク性能と引き換えにレイテンシとコストを差し出すことが多い。このトレードオフが見合うのはどんなときかを検討すべきである。
For many applications, however, optimizing single LLM calls with retrieval and in-context examples is usually enough. ただし多くのアプリケーションでは、retrieval と in-context example を伴う単一の LLM 呼び出しを最適化すれば、たいてい事足りる。
複雑さを足すのは「それが成果を実証的に改善するときだけ (only when it demonstrably improves outcomes)」。
ツール設計 (Agent-Computer Interface, ACI)
3つの中核原則:
Maintain simplicity in your agent’s design. Prioritize transparency by explicitly showing the agent’s planning steps. Carefully craft your agent-computer interface (ACI) through thorough tool documentation and testing. エージェントの設計は単純さを保て。エージェントの計画のステップを明示的に見せることで透明性を優先せよ。徹底したツールのドキュメントとテストを通じて、agent-computer interface（ACI）を丁寧に作り込め。
フォーマット選択の指針:
- モデルが「行き詰まる前に考える」ための十分なトークンを与える
- インターネット上のテキストで自然に現れる形式に近づける
- 不要な行数カウントや string-escaping などのフォーマット上のオーバーヘッドを排除する
ドキュメント:
- モデルの視点で使われる前提で設計し、使用例・エッジケース・フォーマット要件・境界を含める
- パラメータ名と説明を、ジュニア開発者向けに書くつもりで明確にする
- モデルのツール使用を広範にテストし、観察された誤りをもとに反復する
- ツールを poka-yoke（ポカヨケ）する: 引数の形を変えて、そもそも間違えにくくする
Poka-yoke your tools. Change the arguments so that it is harder to make mistakes. ツールをポカヨケせよ。引数の形を変えて、そもそも間違えにくくする。
While building our agent for SWE-bench, we actually spent more time optimizing our tools than the overall prompt. SWE-bench 向けのエージェントを作る際、我々は実際のところ、全体のプロンプトよりもツールの最適化に多くの時間を費やした。
相対パスのナビゲーションエラーを排除するため絶対パスに切り替えた、という具体例が挙げられている。
フレームワークについて
Claude Agent SDK / Strands Agents SDK / Rivet / Vellum などがある。ただしフレームワークは背後のプロンプトとレスポンスを隠蔽し、デバッグを難しくしうる。まず LLM API を直接呼ぶところから始めることを推奨。
We suggest that developers start by using LLM APIs directly: many patterns can be implemented in a few lines of code. 開発者はまず LLM API を直接使うところから始めることを勧める。多くのパターンは数行のコードで実装できる。
原典の結語
Success in the LLM space isn’t about building the most sophisticated system. It’s about building the right system for your needs. LLM の領域における成功とは、最も洗練されたシステムを作ることではない。自分のニーズに合ったシステムを作ることである。
そのまま使える具体例
原典で挙げられているパターン別のユースケース。
- Prompt chaining: マーケティングコピー生成 → 翻訳 / 文書アウトライン作成 → 検証 → 本文執筆
- Routing: カスタマーサポートの問い合わせ分類（一般質問 / 返金 / テクニカルサポート）
- Parallelization (Sectioning): ガードレールと本応答を分離して同時実行
- Parallelization (Voting): コードの脆弱性レビューを複数回実行し閾値で判定
- Orchestrator-workers: 複数ファイルにまたがるコード変更、複数情報源からの情報収集
- Evaluator-optimizer: ニュアンスを要する文芸翻訳、複数ラウンドの分析が必要な検索
原典で言及されている関連文書
- writing-tools-for-agents — 本記事の ACI 節を大幅に掘り下げたもの
- effective-context-engineering-for-ai-agents — sub-agent architecture の議論が orchestrator-workers と接続する
未取得の派生リンク
- https://www.anthropic.com/engineering/multi-agent-research-system — orchestrator-workers の実運用事例
- https://www.anthropic.com/engineering/claude-think-tool — 「考えるためのトークン」を明示的なツールにした話