「半年前に作ったエージェントの設計、もう古くなってない？」
この問いに「はい」と答える人が増えています。Claude のモデルは急速に進化していて、以前は必要だったハーネス（エージェントの制御構造）の多くが、今では足を引っ張る存在になっています。
Anthropic が2026年4月に公開したブログ記事「Harnessing Claude's Intelligence」は、この問題に正面から向き合っています。メッセージは明快で、「ハーネスに機能を足すのではなく、引き算せよ」ということ。
この記事では、ブログで紹介された3つのパターンを日本語で噛み砕き、Claude Code ユーザーが実践に活かせる形で解説します。
ハーネスの前提は「陳腐化」する
まず、この記事の根底にある考え方を理解しましょう。
エージェントのハーネスには、モデルの限界を補うための前提が組み込まれています。たとえば:
- 「Claude はコンテキストが長くなると焦って早く終わらせようとする」→ コンテキストリセットを入れる
- 「Claude はツールが多すぎると選択を誤る」→ ハーネス側でツールをフィルタリングする
- 「Claude は自分の出力を検証できない」→ 検証エージェントを別途用意する
問題は、これらの前提がモデルのアップデートで無効になることです。
具体例として、Anthropic のチームは Claude Sonnet 4.5 の「コンテキスト不安」対策としてコンテキストリセット機能をハーネスに組み込みました。ところが、同じハーネスを Claude Opus 4.5 で使ったところ、コンテキスト不安の挙動そのものが消えていた。リセット機能は「死んだ重り」になっていたのです。
このように、かつて必要だった構造が、今のモデルではパフォーマンスのボトルネックになりうる。だからこそ「何を足すか」ではなく「何をやめるか」を定期的に問い直す必要があります。
パターン1: Claude が既に知っていることを使う
専用ツールを作る前に立ち止まる
多くの開発者は、エージェントに特定のタスクをやらせるために専用ツールを設計します。「ファイルを検索するツール」「テストを実行するツール」「デプロイするツール」......。
しかし Anthropic のデータは、意外な事実を示しています。
Claude 3.5 Sonnet は、bash ツールとテキストエディタツールだけで SWE-bench Verified の 49% を達成した。これは当時の最先端スコアだった。
つまり、汎用的なツール（bash とファイル操作）を渡すだけで、Claude は多様なタスクを自力でこなせる。専用ツールを20個作るより、汎用ツールを1つ渡す方が効果的なことがあるわけです。
なぜ汎用ツールの方が強いのか
理由はシンプルです。
- bash はモデルのアップデートで自然に上手くなる。 Claude が賢くなれば、bash の使い方も上手くなる。専用ツールは再設計が必要
- 汎用ツールは組み合わせが効く。
grep | sort | headのようなパイプラインを Claude が自分で設計できる - 多様なユースケースに対応できる。 専用ツールは想定したケースにしか使えない
Claude Code 自体がこの設計思想で動いています。bash、ファイル操作、Web検索という汎用ツールの組み合わせで、コーディングからリサーチまで幅広いタスクをこなしている。
実践のコツ
専用ツールを作りたくなったら、まず「bash でできないか？」と自問してみてください。多くの場合、Claude に bash を渡して「○○を調べて」と言うだけで十分です。専用ツールは、セキュリティ・UX・監査の観点で本当に必要なときだけ作る。
パターン2: 「何をやめられるか？」と問い続ける
これが記事の核心です。Anthropic は3つの「やめるべきこと」を提案しています。
A. Claude に自分のアクションを制御させる
従来のハーネスは、ツールの呼び出し結果をすべて Claude のコンテキストウィンドウに流し込んでいました。巨大なテーブルデータを読み込んで1列だけ抽出する場合でも、テーブル全体が Claude のコンテキストに入る。無駄なトークン消費です。
解決策: Claude にコード実行ツール（bash や REPL）を与えて、自分で結果をフィルタリングさせる。
Anthropic のベンチマーク（BrowseComp）では、Opus 4.6 に「自分でツール出力をフィルタリングする能力」を与えたところ、精度が 45.3% → 61.6% に跳ね上がりました。ハーネスがやっていたことを Claude に委譲しただけで、16%以上の改善です。
これは「強いコーディングモデル = 強い汎用エージェント」という等式を意味します。コードはあらゆるロジックを表現できる汎用のオーケストレーション手段だからです。Claude がコードを書けるなら、何をフィルタリングし、何をパイプし、何をコンテキストに入れるかを自分で判断できる。
Claude Code でも同じです。たとえば大量のログファイルから特定のエラーを探す場合:
# ハーネスが全部読み込む（❌ トークン浪費）
cat server.log # → 10万行がコンテキストに入る
# Claude が自分でフィルタリング（✅ 効率的）
grep "ERROR" server.log | tail -20 # → 必要な20行だけ
コードは汎用的なオーケストレーション手段なので、コーディングが得意なモデルは、そのまま優秀なエージェントになります。
B. Claude に自分のコンテキストを管理させる
手作りのシステムプロンプトにすべての指示を詰め込むのは、もう古い設計です。
問題は「アテンションの予算」。システムプロンプトが長いほど、Claude はタスクの核心に集中する余地が減ります。めったに使わない指示がコンテキストの大部分を占めている状態は、お金の無駄でもあります。
Anthropic が推奨する代替アプローチ:
Skills の段階的開示（Progressive Disclosure）: YAML のフロントマターに短い概要だけ書いておき、Claude が必要なときだけ本文を読む。Claude Code の Skills 機能がまさにこれです。
コンテキスト編集: 古くなったツール結果や thinking ブロックを選択的に削除する。/compact や Esc + Esc で実行できます。