数十チームの実装から見えた結論はシンプルだった——うまくいくのは複雑なフレームワークではなく、単純で組み合わせ可能なパターン。その7つの型を図で読み解きます。
Anthropicはこれら全体を agentic systems（エージェント的システム）と呼び、そのうえで設計上の重要な線を1本引きます。
決められた経路を通る。LLMとツールが、開発者が書いたコードのフローに沿って動く。分岐も順序も人間が設計する。
→ 予測可能性と一貫性が武器。定義済みのタスク向き。
経路を自分で決める。LLMが自らプロセスとツール使用を動的に指揮し、タスクの進め方を握り続ける。
→ 柔軟性とモデル主導の判断が武器。規模のある不定形タスク向き。
推奨は一貫して「最も単純な解から始め、必要になったときだけ複雑さを足す」。エージェント的システムは、性能と引き換えにレイテンシとコストを払う取引だと意識する。
多くの用途では、単一のLLM呼び出しを検索（retrieval）と文脈内の例（in-context examples）で最適化するだけで十分。
タスクが明確に定義できるなら、予測可能で一貫したワークフローが向く。
入力に応じてサブタスクが変わる場合はオーケストレーター型などへ。
手数を事前に固定できないオープンな問題で、モデルの判断に一定の信頼が置けるとき。自律ゆえコスト増・エラーの連鎖に注意し、サンドボックスでの十分な検証とガードレールを。
Claude Agent SDK、Strands（AWS）、Rivet、Vellum など。着手は速くなるが、抽象の層がプロンプトと応答を覆い隠し、デバッグを難しくすることがある。
土台となる拡張LLMから始め、単純な合成ワークフロー → 自律エージェントへと、少しずつ複雑さを上げていく7つの型。図の凡例は 青＝決定論的な経路／琥珀＝動的・自律・フィードバック。
The augmented LLM — 検索・ツール・メモリで強化された1つのLLM呼び出し
すべてのエージェント的システムの基本部品。LLMが自分で検索クエリを生成し、適切なツールを選び、何を記憶に残すかを判断する。以降の全パターンは「各LLM呼び出しがこの拡張機能を持つ」前提で組む。
①自分のユースケースに合わせて機能を仕立てる ②LLMにとって使いやすく文書化されたインターフェイスにする。実装手段の一つが MCP（Model Context Protocol）。
各ステップが前の出力を受け取る直列。途中に「ゲート」で軌道チェックを挟める
タスクを固定のサブタスクに綺麗に分解できるとき。1回あたりを易しくして精度を上げる代わりに、レイテンシを払う取引。
入力を分類し、専門化した後続タスクへ振り分ける（関心の分離）
別々に扱ったほうがよい明確なカテゴリがあり、分類を（LLMでも従来の分類器でも）正確にできるとき。1種類の入力向けの最適化が他を悪化させる問題を避けられる。
複数LLMが同時に働き、出力をプログラム的に集約する
中央LLMが動的にタスクを分解 → ワーカーへ委任 → 結果を統合
形は似ているが決定的に違うのは柔軟性。サブタスクは事前定義されず、入力に応じてオーケストレーターがその場で決める（破線）。手数を予測できないタスク向き。
一方が生成、もう一方が評価とフィードバック——人の推敲プロセスに似たループ
明確な評価基準があり、反復的な改善が測定可能な価値を生むとき。適合のサインは①人が言語化したフィードバックで応答が確かに良くなる ②LLMがそのフィードバックを出せる。
人の指示で開始 → LLMが環境からの「ground truth」を頼りにループで自律実行 → 停止条件で終了
必要な手数を予測できず、経路をハードコードできないオープンな問題。多ターン動くため、モデルの判断に一定の信頼が要る。実体は「環境からのフィードバックを頼りにツールを使うLLMのループ」と、しばしばシンプル。
SWE-bench のコード課題、computer use の実装など。自律ゆえ高コスト・エラー連鎖のリスクがあり、サンドボックス検証とガードレール、ツール設計が決定的に重要。
これらは処方箋ではなく共通パターン。用途に合わせて形を変え、組み合わせてよい。成功の鍵は他のLLM機能と同じ——性能を測り、実装を反復すること。そして結果が明確に改善するときだけ複雑さを足す。
エージェントの設計はできるだけ単純に保つ。
エージェントの計画ステップを明示し、可視化する。
ツールの文書化とテストで、エージェント–コンピュータ接面(ACI)を作り込む。
価値が最も出るのは、会話と行動の両方を要し、成功基準が明確で、フィードバックループがあり、人の監督を組み込めるタスク。代表例が2つ。
どのシステムでもツールは重要部品。ツール定義にも、全体プロンプトと同じだけの設計努力を。人間向けUI(HCI)に注ぐ労力と同じだけ、エージェント向け接面(ACI)に投資する。
書き始めて詰む前に、モデルに十分なトークン(思考の余地)を残すフォーマットにする。
ネット上のテキストに自然に現れる形式に寄せる。差分(diff)より全文書き換えが楽なことも。
数千行の行数を数え続ける・JSON内でエスケープするような余計な負荷を課さない。
使用例・エッジケース・入力形式・他ツールとの境界を書く。ワークベンチで試して反復。
絶対パス必須に変えたら、モデルは完璧に使いこなした。