AIは、縛るほど弱くなる

Anthropicが2026年4月2日に公開したブログ記事が、AIエージェント開発の常識を問い直す内容として注目されています。AIの動作を制御する枠組み「ハーネス」は、これまで「Claudeにはこれができない」という前提のもとに設計されてきました。しかし、Claudeが急速に賢くなるにつれて、その前提はどんどん古くなっていきます。

Anthropicが示す答えは「制約を足すのではなく、むしろ削ること」です。ポケモンゲームを使った実験では、旧モデルが14,000ステップ後も2番目の街でうろうろしていたのに対し、最新モデルはジムバッジを3個取得していたという対比が、この違いを象徴しています。

【出典元】Harnessing Claude’s Intelligence

ハーネスが「足かせ」になる理由

記事の冒頭では、AnthropicのCo-founderであるChris Olahの言葉が紹介されています。

「Claudeのような生成AIは、設計されるというより育てられるものだ」

研究者たちが成長の方向性を設定できても、実際にどんな能力が出てくるかは予測しきれない——そういう性質のモデルだということです。

この性質がエージェント開発における根本的な問題につながっています。記事はこう指摘しています。

“agent harnesses encode assumptions about what Claude can’t do on its own, but those assumptions grow stale as Claude gets more capable”
（訳：ハーネスにはClaudeが単独ではできないことに関する前提が組み込まれているが、Claudeが賢くなるにつれてその前提は古くなっていく）

という意味です。過去に必要だった制限が、今のClaudeには不要どころか邪魔になっているケースが生まれているわけです。

問題はその古い前提に気づきにくいことにあります。コードに埋め込まれた制約は、一度機能してしまうと「当然あるもの」として扱われ続けます。Claudeのバージョンが上がるたびに「この制約はまだ必要か？」と問い直す習慣がなければ、性能の足を引っ張り続けることになります。

ポケモンで見えたAIの実力差

この問題を直感的に示す事例として、記事ではポケモンゲームを使った実験が紹介されています。

旧モデルのClaude 3.5 Sonnetはゲームをプレイしながら、NPCが言ったセリフをそのままメモリに書き留めていました。14,000ステップが経過した後も、ゲーム内の2番目の街に留まっており、同じポケモン（コクーン）に関する重複ファイルを2つ作成していたとのことです。

一方、最新モデルのOpus 4.6は同じ14,000ステップで、ジムバッジを3個取得し、10個のファイルをディレクトリに整理し、自分の失敗から学んだ教訓をまとめた「レッスン」ファイルまで作成していました。
何を覚え、何を整理するか——その判断をClaudeに委ねたとき、旧来の制約のある設計との差が歴然と現れた事例です。

この実験は、「メモリシステムには外部の検索インフラが必要」という前提を疑ったことから生まれています。ファイルにコンテキストを書き出し後から読み込む「メモリフォルダ」だけを渡したところ、BrowseComp-Plusというベンチマークでの精度が60.4%から67.2%に向上しています。

「何をやめられるか」が鍵になる

Anthropicが提案する3つのパターンのうち、最も核心に近いのが「何をやめられるか？」を問うことです。

よくある前提として「すべてのツール実行結果はClaudeのコンテキストウィンドウを通さなければならない」というものがあります。しかしこれは処理を遅くし、コストも増やします。解決策はコード実行ツール（bashやREPL）をClaudeに渡すことです。そうすることで、Claudeは何をコンテキストに通すか、何をフィルタリングするか、何を次のツールにパイプするかを自分で判断できるようになります。

この変更だけで、BrowseComp（Webブラウズエージェントのベンチマーク）でOpus 4.6の精度が45.3%から61.6%に向上しました。さらに長期タスクに対応する「コンパクション」（過去のコンテキストをClaudeが自分で要約する機能）を組み合わせると、84%に到達しています（記事本文・パターン2「コンテキスト管理」「長期記憶」各サブセクション）。

コンテキスト管理でも同様の見直しが有効です。「システムプロンプトに手作業でタスク固有の指示をすべて詰め込む」という前提を捨て、短い説明だけを載せてClaudeが必要に応じて詳細を取得する「スキル」という方式を採ると、多くのタスクにスケールしやすくなります。

そしてパターン1として紹介されているのが「Claudeがすでによく知っているツールを使う」という考え方です。Claude 3.5 SonnetはSWE-benchというソフトウェアエンジニアリングの評価テストで49%のスコアを達成しましたが、使ったのはbashツールとテキストエディタツールの2つだけです（記事本文・パターン1セクション）。専用ツールを追加するより、Claudeが使い慣れた汎用ツールを渡す方が効果的なケースが多いことを示しています。

キャッシュと境界線で性能を最大化する

パターン3では、コスト削減と安全性に直結する境界線の設計が紹介されています。

Messages APIはステートレスで、毎ターン全情報をClaudeに渡す必要があります。ここでキャッシュを有効活用すると、キャッシュ済みのトークンは通常の入力トークンの10%のコストで利用できます。

キャッシュヒットを最大化するため、記事は次のような原則を挙げています。

• 静的なコンテンツを先に、動的なものを後に配置する
• プロンプト本体を編集するのではなく、<system-reminder>タグをメッセージに追加する
• モデルをセッションの途中で切り替えない（キャッシュはモデル固有のため）
• ツールの追加・削除に注意する（キャッシュのプレフィックスが無効化されるため）

セキュリティ面では「重要なアクションを専用ツールに格上げする」という考え方が紹介されています。外部APIコールなど元に戻しにくい操作はユーザー確認をはさめるようにし、ログやトレースの取得にも専用ツールを使うことで、システム全体の観測性が上がります。ただしどのアクションを格上げするかも、Claudeの進化に合わせて継続的に見直す必要があります。

まとめ

今回のAnthropicのブログ記事が伝えるメッセージは、一言でいえば「過去に追加した制約を、今も本当に必要か問い続けること」です。

記事の締めくくりでは印象的な実例が紹介されています。ある長期タスク向けエージェントで、Sonnet 4.5がコンテキストの上限を感じると早めにタスクを打ち切る「コンテキスト不安」という挙動が見られたため、リセット機構が追加されました。しかしOpus 4.5になるとその挙動がなくなり、リセット機構は「死重」になったということです（記事末尾・締めくくりセクション）。

Claudeは常に進化しています。「Claudeにはまだこれはできない」という仮定が、今も本当に正しいのか——それを問い続けることが、AIを最大限に活かす上で欠かせない姿勢といえます。