2024年末にAnthropicが『Building Effective Agents』を公開した際、業界にとって稀な出来事が起こりました。それは、エンジニアに「共通の語彙」を与えたことです。人工汎用知能（AGI）に関する新たなマニフェストを提示するのではなく、このガイドはLLMシステムを構築するための6つの明確なパターンを提示しました。それから1年半が経過した2026年、その景色は劇的に変わっています。Model Context Protocol（MCP）は普遍的な標準となり、Claudeは新たな能力を獲得しました。ほとんどの組織において、少なくとも1つのエージェントが本番環境で稼働しています。こうした背景を踏まえると、それら6つのパターンが今なお重要なのか、それとも昨年のモデルの重み（weights）と共にアーカイブに眠るべきものなのか、疑問を呈するのは妥当でしょう。
私はその答えを見出すため、サイドリポジトリでローカルモデルを用いてこれら6つのパターンすべてをテストしました。結論は「イエス」です。それらは今でも有効です。しかし、それはそれらが不変の法則だからではありません。過去18ヶ月間の本番運用における経験が、このフレームワークの核心的なロジックを証明したからこそ、有効であり続けているのです。
このフレームワークが実際に私たちに与えたもの
覚えておく価値のある6つのパターンは、まさにこれらです：Prompt Chaining、Routing、Parallelization、Evaluator-Optimizer、Orchestrator-Workers、そしてAutonomous Agents。最後の一つは、本質的にはモデルが計画、実行、観察を行い、特定の条件が満たされるまでこれを繰り返すループです。
このガイドが登場する前から、多くのエンジニアがプロンプトの連鎖（chaining）を行ったり、ワーカー・スレッドにタスクを委譲したりしていました。Anthropicが提供したのは「タクソノミー（分類学）」でした。ある人が「エージェント」と呼ぶものが、別の人には「ワークフロー」であり、また別の人には「マルチステップのツール呼び出し」であったのです。ガイドは、その混沌とした概念を明確な境界線を持つバケツへと整理しました。これにより、互いに噛み合わない議論をすることなく、トレードオフについて議論することが可能になったのです。ハイプ（過剰な期待）に溺れるこの分野において、明快な言語は一種のインフラストラクチャと言えます。
業界はそれの周囲ではなく、その上に構築された
2026年までに、これらのカテゴリはチームのシステム設計における常識となりました。Anthropicは今でもAcademyのコースでこれらを教えています。研究論文やエンジニアリングブログでも、新しいアーキテクチャを説明する際に同じ6つのバケツが使われています。四半期ごとにスタックが刷新されるような分野において、これほどの持続性を持つことは珍しいことです。
理由は単純です。業界はこのフレームワークを置き換えたのではなく、その上に構築したのです。MCPや新しいAgent Skills標準のような新しいツールは、「配管（plumbing）」として機能します。それらは、モデルをデータベースに接続したり、ツールを公開したり、状態を管理したりすることを容易にします。しかし、オーケストレーターの代わりにルーターをいつ使うべきか、といったロジックを変えるものではありません。より優れた配管が、設計図を書き換えるわけではないのです。
2026年の本番データがこれを裏付けています。最も一般的なデプロイパターンは、依然として「単一のツール利用呼び出しと人間によるレビュー」の組み合わせです。2番目に多いのは、「人間への受け渡しがちょうど1回あるマルチステップ・ワークフロー」です。これらはいずれも、Prompt ChainingとRoutingの直接的な後継です。ライブシステムにおいて、完全な自律型ループはルールではなく、依然として例外的な存在です。
自制が市場を制した
元のガイドにおける最良のアドバイスは、同時に2024年に最も無視されたアドバイスでもありました。「機能する最もシンプルなパターンを使うこと」です。ハードコードされたパスで目的が達成できるのであれば、完全な自律型エージェントをデプロイしてはいけません。
市場はようやくこれを内面化しました。ほとんどのエージェントのパイロット運用は依然として失敗に終わりますが、その理由は常に予測可能なものです。チームは、誰も意思決定の境界線を追跡できなくなるまで、抽象化の上に抽象化を積み重ねてしまいます。システムがドリフト（乖離）すると、デバッグは考古学のような作業になってしまいます。本番環境で成功している企業は、自制心を持っていた企業です。彼らはデフォルトでシングルターンのツール利用を選択しました。単一のプロンプトで一貫性が欠けることが判明して初めて、ルーティング層を追加しました。彼らは自律性を、称賛すべき機能としてではなく、正当化されるべきリスク（負債）として扱ったのです。
これは野心に反対する議論ではありません。構成（composition）を支持する議論です。パターンは、メニューにある最も複雑な選択肢に反射的に手を出すのではなく、意図的にそれらを組み合わせたときに最も効果を発揮します。
継ぎ目から漏れ始める場所
このフレームワークは万能薬ではありません。プロトタイプ段階を抜けた瞬間に、いくつかの厳しい限界が露呈します。
高頻度かつ低コストなタスクにおいては、依然として決定論的なコードが勝ります。pandasを使えばハルシネーションを起こさず数ミリ秒で処理できるCSV列の正規化を、LLMに担当させてはいけません。明確な評価目標を定義できない場合は、自律的なループ（autonomous loops）を避けてください。明確な停止条件がなければ、モデルは停止する理由を捏造するまで反復を繰り返してしまいます。外部の根拠（external grounding）を必要とする重大な意思決定については、モデルの内部知識だけに頼らないでください。また、データ取得のボトルネックにも注意してください。ベクトル検索や外部APIに依存するパターンは、データベースの速度低下や、コンテキストウィンドウが関連性のないチャンクで埋め尽くされることによって、処理が停滞する可能性があります。
これらは仮説上のエッジケースではありません。動くデモと、実運用に耐えうるシステムを分ける境界線なのです。
硬直したチェックと誤った失敗
私はテスト用のリポジトリを構築する過程で、このフレームワークの実用的な価値を学びました。当時、私はEvaluator-Optimizerパターンを実装していました。私のエバリュエーターは、モデルの出力から特定のキーワードをスキャンする、ハードコードされた正規表現から始まりました。モデルは、私が探していた正確な単語ではなく、たまたま類義語を用いた、正しく論理的な回答を返しました。しかし、エバリュエーターはそれを失敗としてフラグを立てたのです。
モデルは正しかった。私のチェックが硬直的すぎたのです。
修正には、単に単語リストを増やす以上のことが必要でした。私はエバリュエーター自体をLLMベースの判断に切り替えました。それにより追加のトークンと数ミリ秒のコストがかかりましたが、評価を適切な抽象度に戻すことができました。パターン自体は健全でした。私は単に、そのタスクに対して誤った実装を選択しただけだったのです。これこそが、まさにこのフレームワークが防ごうとしている種類のミスです。コードが必要な評価もあれば、モデルが必要な評価もあります。どちらがどちらであるかを見極めることこそが、まさに肝要なのです。
今すぐ活用する方法
これらの6つのパターンは、絶対的な法則ではなく、出発点として扱ってください。まずは単一のプロンプトから始めます。入力タイプによって品質が不安定な場合は、ルーティング層を追加して、異なるリクエストを専門化されたプロンプトに送信します。判断を下す前に複数の独立した視点が必要な場合は、Parallelizationを使用してください。タスクが大きく分割可能な場合は、Orchestrator-Workersを試してください。問題の範囲が広すぎて事前にマッピングできず、かつ信頼できる