エージェントのアンチパターン五つ — Anthropic の認定試験が選んだ答えは、すべて「与えすぎない」側だった

Claude Certified Architect とは何か

まず試験そのものから。Claude Certified Architect は Anthropic が出した初の公式技術認定です。Foundations 等級のコードは CCAR-F で、Pearson VUE がオンライン監督または試験会場で実施します。問題は60問、時間は120分、点数スケールは100点から1,000点で合格ラインは720点。資格は12か月間有効です。

本もAIツールも使えないクローズドブック方式で、扱う領域はエージェントアーキテクチャ、MCP連携、Claude Code のワークフロー、プロンプトエンジニアリング、コンテキスト管理です。

ただしこの記事で話したいのは資格ではありません。試験を受けるつもりがなくても、問題のリストそのものが役に立つという話です。発表者の理由は単純です。Anthropic は人々が自社のシステムを実際にどう使い、どこで壊すかを最も多く見ている会社です。その会社が問題を作るなら、その問題リストはそのまま現場で起きる問題のリストです。

発表者自身が30年以上コンピュータサイエンスを教えてきた人で、学生に「コンピュータサイエンスの学位は就職を保証しない」と言わねばならない立場で何を手渡せるかを探していて、この試験に行き着いたと言います。

なぜ正解ではなく誤答から見るのか — アンチパターンのカタログ

この発表には方法論が一つ敷かれています。何をすべきかではなく、何をしてはいけないかから見る、というものです。

根拠として挙げたのが1990年代初頭のソフトウェア設計パターン運動です。オブジェクト指向プログラミングが定着するにつれ「こうすればよい」というパターンのカタログが現れ、ほぼ同時期に「こうしてはいけない」というアンチパターンのカタログも一緒に出ました。実務では、うまくやる方法より失敗する方法のリストのほうが速く効いたのです。

いま必要なのがそれだ、という話です。エージェント用のアンチパターン・カタログ。エージェントをうまく作る助言はあふれているのに、何をすると静かに壊れるかのリストは少ない。

発表者が引いたエジソンの一文が合っています。「私は失敗したのではない。うまくいかない方法を一万通り見つけただけだ。」以下の五つは、その一万通りのうちよく踏むほうの五つです。

配点が先に語る — 設計が最大の塊だ

試験ブループリントの五領域と比重です。以下の数字は発表スライドに記載された値です。

ループが埋まった時点 — 1966年の証明

アンチパターンに入る前に、発表は一度1966年へ戻ります。なぜ今になってエージェントが急に違って感じられるのかについての説明です。

コンピューティング初期にはプログラミング言語が爆発的に増え、「自分の言語のほうが多くのことができる」という争いがありました。1966年、コラド・ベームとジュゼッペ・ヤコピーニがこの論争を証明で片づけます。どんな計算も三つだけあればできる、という証明です。順に実行すること、条件で分岐すること、そして繰り返すこと。

ここに今のAIを当てはめると絵がはっきりします。プロンプトを一度投げて答えを受け取るのは順序です。条件で分岐させるところまでは多くの人がやってきました。しかしループがなかった。答えを受け取ってまた入れ、また受け取ってまた入れる構造のことです。

エージェントが違って感じられ始めたのはモデルが良くなった分もありますが、構造的にはこの三つ目が埋まった時点です。だから最初のアンチパターンはループについての話になります。

アンチパターン一 — 応答をそのまま使わず、なぜ止まったかから見る

最もよくある間違いから。モデルを呼び、答えが来たら、その答えをそのまま使うことです。

ここで先に解いておく誤解があります。LLM はツールを実行できません。確率的に次の単語を予測する以外は何もできません。ツールを渡しても実行はできず、代わりに「このツールをこの値で呼べばよい」と教えてくれるだけです。実際に呼ぶのは自分のコードです。

だから応答が来たら答えをすぐ使うのではなく、stop_reason、つまりモデルがなぜ止まったかを先に見ます。tool_use ならツールを実行して結果をもう一度入れ、もう一周します。end_turn ならループを抜けます。

もう一つあります。トークンが尽きて止まった場合にも応答は来ます。文章ももっともらしく来ます。しかしそれは途中で切れた答えです。stop_reason を見なければ、完成した答えだと思ってそのまま使ってしまう。静かに間違う場所がここです。

ループを抜けた後は、人が介入する場所でもあります。確信度を確認して、よければ採用し、だめなら人に回します。

while True:
    resp = client.messages.create(
        model="claude-opus-5",
        messages=messages,
        tools=tools,
    )

    # 答えを使う前に、なぜ止まったかを見る
    if resp.stop_reason == "tool_use":
        result = run_tool(resp)          # ツールを呼ぶのは自分のコード
        messages.append(result)          # 結果を入れ直してもう一周
        continue

    if resp.stop_reason == "max_tokens":
        raise RuntimeError("切れた答えだ — 完成した答えとして使わないこと")

    break                                # end_turn なら抜ける

アンチパターン二 — ルールを一つのファイルに寄せず、効く場所に置く

二つ目は Claude Code でコードを生成するときの話です。CLAUDE.md というマークダウンファイルに「知っておいてほしいこと」を書くのですが、ここでよくあるアンチパターンが、ルールを一つのファイルに全部寄せることです。

Anthropic が勧めるのは階層に分けるほうです。ホームディレクトリの CLAUDE.md はすべてのプロジェクトに適用され、プロジェクトルートのものはそのリポジトリだけに、ディレクトリごとのものはそのフォルダで作業するときだけ適用されます。三つとも読み込まれてマージされ、衝突すると最も具体的なファイルが勝ちます。

一つのファイルに全部入れると、特定のフォルダでしか必要ない指示が無関係な作業にまでついてきます。そして静かにぶつかります。失敗として現れるのではなく、結果が微妙にずれる形で出てきて、どこで衝突したのかも見えません。

この話は当サイトで一度扱った「Claude が実際に従う CLAUDE.md はどう書くか」とつながります。あちらがファイル一つをどう書くかだったとすれば、ここではファイルをどこに置くかです。

アンチパターン三 — ツールを全部つけず、エージェントを割る

三つ目はエージェントを複数使うときの話です。発表で出た比喩が正確です。家に大工を呼んだのに、配管工具、木工工具、電気工具を全部持って現れて「自分は何でもできる」と言う。その人は呼びたくないでしょう。まともな大工が欲しかったはずです。

基準線はスライドにツール四つか五つと書かれ、発表者は口頭で一つか二つと言いました。どちらで取っても方向は同じです。その線を越えると推論の質が落ち、ツール選択が不安定になります。だからツールベルトを大きくする代わりにエージェントを割る。一つが一つのことだけをするようにします。関数は一つのことだけをすべきだという関数型プログラミングの古い規則が、そのまま移ってきた形です。

これに付け加わるのが、サブエージェントのコンテキストをメインに漏らさないことです。コンテキストはトークンでトークンはお金ですが、それより重要なのは、コンテキストが多いほどモデルが混乱して答えが不正確になるという点です。

発表で最も印象的だったコードが critic エージェントでした。先行する作業を検証するために作ったエージェントなのに、渡すのは主張と根拠のちょうど二つだけ。その判断に至るまでの思考過程はわざと外します。

検証させるために作ったエージェントに情報を減らして渡すわけで、理由はグループシンクでした。複数のエージェントが集まって互いに話すと、一つの結論に収束してしまう。パーティーで全員がピザを食べたがっていて自分だけ違うとき、場を壊したくなくて合わせてしまうのと同じだ、という比喩でした。エージェントもそう動きます。だから各エージェントには自分の分の一切れだけを渡します。

アンチパターン四 — 長い出力は切り離し、大きくなったら圧縮する

四つ目はコンテキストを無制限に育てることです。

処方は二つ。一つはサブタスクの出力を隔離することです。ログを全部さらってエラーを探すような、出力の多い作業は別のコンテキストに切り離します。発表ではフォーク（fork）と呼んでいました。冗長な出力はその中だけに残り、メインの会話には要約だけが戻ります。

もう一つは長い会話を圧縮することです。トークン数を数えて基準線を超えたら圧縮をかけます。発表のコードに書かれていた基準線は15万トークンでした。

コンテキストを節約すべき理由は二つです。コンテキストはトークンでトークンはお金だというのが一つ。もう一つは、コンテキストが多いほどモデルが混乱して答えが不正確になることです。

100万トークンの窓が開いたのだから全部入れてもよさそうに思えますが、逆です。入れるものを制限してこそ正確になります。

アンチパターン五 — CI では対話モードで呼ばない

最後はパイプラインの中で回すときです。アンチパターンが少し可笑しい。エージェントを対話用に呼ぶと「これをしてもいいですか」と権限を尋ねる場所で止まり、誰も答えない答えを待ちます。人のいない場所で人を待つのです。

非対話モードで回し、出力を JSON で受け取ってこそパイプラインが読めます。

ここに一つ加わるのが Batch API です。プロンプトと作業をバッチにまとめて渡すとトークン費用が半分になり、結果は24時間以内に来ます。今すぐ答えが要らない仕事なら、そちらが正しい置き場所です。

今日やってみること一つ

五つを貫くものが一つです。すべて与えすぎない側です。ツールも、コンテキストも、情報も。

エージェントをうまく扱うことが、より多くをつける能力のように語られますが、この試験が答えとして選んだのは反対側でした。何を与えないかを知っている側です。

今日すぐ確認できるものを一つ選ぶなら三つ目です。いま使っているエージェントやカスタム GPT、MCP の設定を開いて、ついているツールの数を数えてみてください。四つか五つを超えていれば、そのうち半分は一度も使われていない可能性が高い。その半分を外して同じ仕事をさせると、答えが変わります。

その次が CLAUDE.md です。ファイル一つに二十行以上積み上がっているなら、そのうち特定のフォルダでしか必要ない行を選んで、そのフォルダの CLAUDE.md に移します。消すのではなく、置き場所を変えるのです。