Anthropicに学ぶエージェント「設計」と「評価」——複雑なフレームワークより、シンプルなパターン

はじめに

AIエージェントの本番化には、検証フェーズでは見えにくい落とし穴がある。
利用者や対象業務を広げた途端に品質が落ちる——そんな事象に直面したチームは少なくないはずだ。

原因を探ろうとすると、つい社内の過去事例や他社事例に手が伸びる。
しかし個別の事例は、その組織やシステムに固有の構成・前提に強く依存している。
参考にしたつもりでも自分たちのケースには当てはまらず、問題の本質を見落としたまま実装してしまうことが多い。

そこで本記事では、Anthropic が公開している2本のエンジニアリングブログを題材に、「何が起きているのか」「どう設計すれば防げるのか」を整理する。
これらは個別事例の紹介ではなく、多数の事例から抽象化された設計原則をまとめたものだ。一次情報にあたることで、特定のケースの文脈に引きずられず、自分たちの設計判断へ応用しやすくなる。題材は以下の2本である。

• Building effective agents（2024年12月公開）
• Demystifying evals for AI agents（2026年1月公開）

どちらも Anthropic のエンジニアリングチームが、社内開発と顧客との協働の経験をもとに書いた公開記事だ。本記事はこれらを読んだ筆者の整理であり、出典に基づく解説として書いている。

記事1: Building effective agents

この記事が言いたいこと

核となるメッセージは、冒頭ではっきり示されている。

Consistently, the most successful implementations use simple, composable patterns rather than complex frameworks.

[1]

意訳すると「もっとも成功した実装は、決まって、複雑なフレームワークではなくシンプルで組み合わせ可能なパターンを使っていた」。記事全体が、この一文を裏づける内容になっている。

ワークフローとエージェントは別物

記事は「agentic systems（エージェント的システム）」を、性質の異なる2種類に分けて扱う ^[1:1]。

• ワークフロー（Workflows）: LLM とツールを、あらかじめ決められたコードパスに沿って組み合わせるシステム。
• エージェント（Agents）: LLM 自身が、自分の処理の進め方やツールの使い方を動的に決めるシステム。

両者は用途が異なり、選択も変わる。記事の立場は明快で、「まずシンプルなものから始め、必要になったときだけ複雑度を上げる」ことを勧めている。場合によっては、そもそもエージェント的システムを作らないという選択もありうる、と踏み込んで述べている点が重要だ ^[1:2]。

これは本番化を考えるうえで効いてくる原則である。検証段階で「エージェントを作ること」自体が目的化すると、もっと単純な実装で済む課題に、不要な複雑さを持ち込んでしまう。

5つのワークフローパターン

記事は、具体的なパターンを5つ挙げている ^[1:3]。

• 直列につなぐ（Prompt chaining）: 大きな処理を順番のステップに割り、前のステップの出力を次の入力にして数珠つなぎにする。1ステップずつが単純になるぶん、精度が上がる。例: 「下書き → 体裁チェック → 清書」のように工程を分ける。
• 振り分ける（Routing）: まず入力が「どの種類か」を判定し、種類ごとに用意した別々の処理へ送る。例: 問い合わせを「一般質問・返金・技術サポート」に仕分けて、それぞれ専用の対応をする。簡単な質問は安いモデルへ、難しい質問は高性能モデルへ、という振り分けもこれにあたる。
• 並列で走らせる（Parallelization）: 複数を同時に処理する。2通りある。(a) 分担: 独立した部分作業を同時並行でこなし、最後に合体する（例: 本文の生成と、不適切表現のチェックを別々の LLM に同時にやらせる）。(b) 多数決: 同じ作業を何度も実行し、結果を集約する（例: コードの脆弱性を複数の視点で点検する）。
• 指揮役と作業役（Orchestrator-workers）: 中央の LLM が「今回はどう分けるか」をその場で考えて部分タスクに割り、作業役の LLM に振って、結果をまとめる。並列処理との違いは、分け方が事前に決まっておらず、入力に応じて動的に変わる点。例: コード修正で「どのファイルを何カ所いじるか」がタスク次第で変わる場合。
• 評価と改善のループ（Evaluator-optimizer）: 生成役の LLM が答えを作り、評価役の LLM が「ここが弱い」とフィードバックを返す。これを納得いくまで繰り返して品質を上げる。例: 翻訳のたたき台に対し、評価役が「このニュアンスが違う」と指摘 → 直す、を反復する。

いずれも「いつ使うか」「いつ使わないか」がセットで示されている。推奨パターンとして押しつけるのではなく、選択肢として並べている点が読みどころだ。

ツール設計（ACI）への投資

記事の付録（Appendix）では、ツール定義のプロンプトエンジニアリングに丸ごと1章が割かれている。中心となる主張は、人間向けの操作画面（Human-Computer Interface, HCI）に注ぐのと同じだけの労力を、エージェント向けのインターフェース（Agent-Computer Interface, ACI）にも注ぐべきだ、というものだ ^[1:4]。

具体的な助言としては、次のような点が挙げられている。

• モデルが「考える」ための十分なトークンの余地を与える。
• モデルが書き慣れた形式を選び、書式上の余計な負担をかけない。たとえばコードは、JSON 文字列に詰め込ませる（改行や引用符のエスケープが必要で崩れやすい）より、マークダウンのコードブロックで書かせる。差分（diff）形式も、変更行数を事前に数える必要があり崩れやすいので注意する。
• 引数名や説明は、新人開発者向けに丁寧な docstring を書くつもりで設計する。
• ワークベンチで多くのサンプル入力を実際に試し、モデルが起こすミスを観察して改善を重ねる。
• ポカヨケ（poka-yoke）の発想で、そもそも誤用しにくい引数設計にする。

特に印象的なのは、Anthropic 自身が SWE-bench 向けのエージェントを作った際に、エージェント全体のプロンプトよりもツールの最適化に多くの時間を費やしたと明かしている点だ ^[1:5]。

結論として示される3原則

記事は、エージェント実装の指針を3つの原則にまとめている ^[1:6]。

• Simplicity（シンプルさ）: 設計をできるだけシンプルに保つ。
• Transparency（透明性）: エージェントの計画ステップを明示的に見せる。
• ACI（丁寧さ）: ツールのドキュメントとテストを入念に作り込む。

記事2: Demystifying evals for AI agents

この記事が言いたいこと

この記事のテーマは、エージェントの評価（evals）がなぜ必要で、どう作るか、である。冒頭はこう始まる。

Good evaluations help teams ship AI agents more confidently.

[2]

「良い評価があれば、チームは自信を持ってエージェントを出荷できる」。逆に評価がないと、本番でしか問題に気づけず、ひとつ直すと別の不具合が顔を出す——そんな後手に回るループに陥りやすい、と続く ^[2:1]。

どの局面で破綻するのか

記事は、エージェント開発を「初期のプロトタイピング」「本番投入」「スケーリング」という連続した流れで捉えている。手動テストやドッグフーディング、勘である程度進められるのは初期段階だけで、本番に出てスケールし始めると、評価なしの開発は立ち行かなくなる、と観察を述べている ^[2:2]。

そして、破綻が表面化する典型的な瞬間を、はっきり書いている ^[2:3]。

ユーザーから「変更後にエージェントが悪くなった気がする」という声が上がったとき。

このとき評価がないと、検証手段は「推測して、試して確かめる」しか残らない。チームは“手探り（flying blind）”の状態に置かれる。これは、検証段階のうちから評価を組み込んでおくべき理由を、公式に裏づける記述だと言える。

評価を支える3種類のグレーダー

記事は、採点を担うグレーダー（grader）を3種類に整理している ^[2:4]。

• コードベース（Code-based）: 文字列一致、合否テスト、静的解析、ツール呼び出しの検証など。高速・安価で再現性が高い一方、想定パターンを外れた“正解”には弱い。
• モデルベース（Model-based）: ルーブリック採点、自然言語によるアサーション、ペア比較など。柔軟でオープンエンドなタスクに対応できるが、非決定的でコストが高く、人間との校正が要る。
• 人間（Human）: 専門家レビュー、クラウドソースでの判断、A/B テストなど。品質の基準（ゴールドスタンダード）になるが、高コストで遅い。

どれか1つに絞るのではなく、組み合わせて使うのが前提だ。

Capability eval と Regression eval

評価には、目的の異なる2種類がある ^[2:5]。

• Capability eval（品質eval）: 「このエージェントは何をうまくできるか」を測る。最初は低い合格率から始め、改善の余地（登るべき山）を示す。
• Regression eval: 「以前できていたことを、今もできるか」を測る。合格率をほぼ100%で運用し、後退（デグレ）を検知する。

時間が経って Capability eval の合格率が上がりきると、それは Regression eval へ「卒業」する。役割が「できるか？」から「今もできているか？」へと移っていく、という整理だ。

ハーネス——「モデル」ではなく「モデル＋仕組み」を評価している

Components of evaluations for agents.

評価を語るうえで欠かせないのが「ハーネス（harness）」だ。記事は2種類を区別している ^[2:6]。

• エージェントハーネス（agent harness／scaffold）: モデルを「エージェントとして動かす」ための土台。入力を受け取り、ツール呼び出しを束ね、結果を返す。たとえば Claude Code は柔軟なエージェントハーネスで、Anthropic はその基本要素を Agent SDK 経由で使い、長時間稼働のエージェントを組み立てている。
• 評価ハーネス（evaluation harness）: 評価を端から端まで回すインフラ。エージェントに指示とツールを渡し、多数のタスクを並行実行し、各ステップを記録し、採点し、結果を集計する。

ここで重要な観点がある。「エージェントを評価する」と言うとき、私たちはモデル単体ではなく、ハーネスとモデルの組み合わせを評価している ^[2:7]。同じモデルでも、スキャフォールド（足場）の出来次第でスコアは大きく動く。記事の例では、ある評価で Opus 4.5 が当初42%だったが、採点の不備を直し、制約の緩いスキャフォールドに替えたところ95%まで跳ね上がった

^{。差の多くが、モデルの能力ではなく仕組みの側にあったわけだ。}

この観点は本番化に直接効く。

• 本番と評価のハーネスがずれると、評価が当てにならない。評価で使うエージェントは、本番のエージェントとほぼ同じ挙動でなければならない（Step 4）。ここがずれると、「評価では good だったのに本番で崩れる」という、まさに本記事冒頭の事象が起きる。
• 環境はノイズ源になる。各トライアルはクリーンな状態から始め、状態を持ち越さないことが肝心だ。残ったファイルやキャッシュは相関した失敗を生み、逆に性能を不当に水増しすることもある（記事は、過去トライアルの git 履歴を覗いて有利になってしまった例を挙げている）。[2:9]
• スコアが悪いとき、原因の切り分けが要る。モデルの能力不足か、ハーネスの制約か、環境のノイズか——混同すると改善の方向を誤る。記事がトランスクリプトを読めと繰り返すのは、このためでもある。

要するに、評価結果は「モデルの実力」そのものではなく「モデル＋ハーネス＋環境」の合成値だ。本番化では、この三者をできるだけ本番に近づけて測ることが、数字を信頼する前提になる。

評価作成のロードマップ（Step 0 〜 Step 8）

記事は「ゼロから1へ」のロードマップとして、9段階の手順を示している ^[2:10]。

• Step 0— 早く始める（完璧を待たない。実際の失敗から拾った20〜50タスクで十分）。
• Step 1— すでに手動でやっているチェックから始める。
• Step 2— あいまいさのないタスクを、参照解とともに書く（専門家2人が独立に同じ合否判定に至るレベル）。
• Step 3— バランスの取れた問題セットを作る（やるべきケースと、やるべきでないケースの両方）。
• Step 4— 安定した環境で、堅牢な評価ハーネスを構築する。
• Step 5— グレーダーを慎重に設計する。
• Step 6— トランスクリプト（試行の記録）を読む。
• Step 7— Capability eval のサチュレーション（飽和）を監視する。
• Step 8— オープンな貢献とメンテナンスで、評価スイートを長期的に健全に保つ。

なかでも強調されているのが Step 6 の「トランスクリプトを読む」だ。グレーダーが正しく機能しているかどうかは、実際の試行記録を読まないと分からない、という主張である ^[2:11]。

評価だけに頼らない — 複数手法を重ねる

記事は、評価が品質保証のすべてではないと明言し、複数の手法を組み合わせる重要性を説く ^[2:12]。

これを「スイスチーズモデル」になぞらえている。1枚のチーズ（1つの層）には穴が空いているが、何枚も重ねれば穴は塞がる——つまり、複数の手法を重ねることで取りこぼしを減らせる、という説明だ ^[2:13]。

2記事から読み取れる、本番化の心得

ここまで2記事の内容を整理してきた。両者を重ね合わせると、「本番化フェーズで押さえるべき考え方」がいくつか浮かび上がる。以下は両記事を読んだ筆者の整理である。

心得1: エージェント化を目的にしない

「Building effective agents」が冒頭から繰り返すのは、シンプルな解で済むならエージェント的システムを作らない選択もある、という姿勢だ ^[1:7]。本番化を見据えるなら、検証段階で「これは本当にエージェントが必要なタスクか」を問い直す価値がある。決まったコードパス（ワークフロー）で済むなら、そのほうが予測可能で安く済む。

心得2: 評価は最初に作る

「Demystifying evals」が一貫して述べているのは、評価作成を後回しにしたときの代償の大きさである ^[2:14]。検証段階で20〜50タスク程度の小さな評価セットを持っておくだけで、その後の改善・モデル更新・デグレ検知が一気に加速する。逆に評価なしで本番に出すと、「悪くなった気がする」を検証する手立てがなくなる。

心得3: ツール設計に時間を投資する

「Building effective agents」は、Anthropic 自身がエージェント全体のプロンプトよりツールの最適化に多くの時間を使った、と明かしている ^[1:8]。本番化フェーズで「エージェントの判断がどうもおかしい」と感じたとき、プロンプトをいじる前に、まずツール定義（説明文・引数名・エラー時の振る舞い）を見直す価値が高いことを示唆している。

心得4: 透明性を設計に織り込む

「Building effective agents」の3原則の1つが透明性（transparency）だ ^[1:9]。エージェントの計画ステップを明示的に見せる設計を最初から仕込んでおくと、後の問題分析が圧倒的に楽になる。「Demystifying evals」がトランスクリプトを読む重要性を強調するのも、同じ系譜の主張といえる

^。

心得5: シンプルさとは「複雑さの否定」ではなく「複雑度を上げる基準を持つこと」

両記事に共通するのは、「複雑にするな」ではなく、「複雑にする前に、それが本当に必要かを問え」という構えだ。「Building effective agents」は、効果が実証できるときにだけ複雑さを加えるべきだ、と明言している ^[1:10]。本番化の意思決定でも、新しい層やパターンを足すたびに「評価上、改善が確認できるか」をチェックする習慣が効いてくる。

まとめ

検証から本番展開へ進むときの落とし穴は、語り方が難しい。自分一人の経験だけで語ろうとすれば守秘の問題に触れ、根拠の薄い一般論で語ろうとすれば説得力を欠く。その点、Anthropic が公開している2記事は、エージェント設計と評価について整理された原則を提示しており、本番化の議論を始める足場として参照しやすい。

本記事はあくまで両記事を読んだ筆者の整理である。ぜひ一次情報を直接読んでほしい。記事はいずれも無料で公開されており、英語ではあるが分量も読みやすい。

参考文献

関連する公式リソース

• Anthropic Claude Cookbooks（Building effective agents の参照実装）: https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents
• Anthropic Engineering ブログ一覧: https://www.anthropic.com/engineering

• Anthropic Engineering, "Building effective agents"（2024年12月19日公開）. Erik Schluntz, Barry Zhang 著.

  https://www.anthropic.com/engineering/building-effective-agents↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎

• Anthropic Engineering, "Demystifying evals for AI agents"（2026年1月9日公開）. Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares, Jiri De Jonghe 著.

  https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎↩︎