進化するモデルの上に構築する

モデルの能力向上に対抗するのではなく、それに乗じたアプリケーションを設計するためのフレームワークです。ソース記事の3パターンフレームワークから抽出したもので、目標は現在の回避策に閉じ込められるのではなく、モデルが向上するにつれてアプリケーションも良くなるというものです。

手順

これら3つのパターンを順番に適用してください。モデルが大幅に改善されるたびに、それらを再評価してください。モデルができないことについての仮定は再テストが必要です。

パターン1 — モデルが既に知っていることを活用する

モデルが広く見てきた一般的なツールの上に構築してください。以下を優先してください：

• シェルアクションに対するbashツール。
• ファイルの閲覧、作成、編集に対するテキストエディタツール。
• これらの上に構築された合成パターン：エージェントスキル、プログラマティックなツール呼び出し、メモリツール。

モデルが既にbash + エディタで処理できる動作に対して、カスタムツールを発明することは避けてください。

パターン2 — 「何をやめられるか？」と問う

スキャフォルディングの各層で、モデルが今それ自身でできるかどうかを確認してください。3つのサブパターンがあります：

1. モデルに自分の操作をオーケストレートさせる。 コード実行ツール（bashまたは言語REPL）を与えて、コンテキストウィンドウを通してすべてをパイプするのではなく、ツール呼び出しを表現するコードを書き、出力をフィルタリング/パイプするようにします。
2. モデルに自分のコンテキストを管理させる。
   • スキル（簡潔な説明のためのYAML frontmatterであり、必要に応じてファイル読み取りツール経由で読み込まれる完全なスキル本体）を使用します。
   • コンテキスト編集を使用して、古い、または無関係なターンを削除します。
   • サブタスクがメイン履歴を必要としない場合、サブエージェントを生成して新しいコンテキストウィンドウをフォークします。
3. モデルに独自のコンテキストを永続化させる。
   • コンパクション化を使用して、過去のコンテキストを短い形式に要約します。
   • ターン全体で書き込み・読み取りできるメモリフォルダを提供します。

オーケストレーション、コンテキスト管理、または永続化の一部が以前はあなたの仕事だったが、モデルがそれを処理するようになったら、コードを削除してモデルにそれをさせてください。

パターン3 — 慎重に境界を設定する

3つのいずれかが必要な場合にのみ構造を追加してください：UX、可観測性、またはセキュリティです。

• キャッシュヒット原則を参照して、コンテキストをキャッシュヒットを最大化するように設計します（下記のキャッシュヒット原則を参照）。キャッシュされたトークンは基本入力トークンの約10%のコストがかかります。
• 以下が必要な場合、bashアクションを専用の宣言的なツールに昇格させます：
  • ゲート制御のための型付き引数（セキュリティチェック、外部API呼び出しなど変更不可能なアクションの確認）；
  • レンダリングアフォーダンス（例：適用前に差分を表示するモーダル）；
  • 可観測性（構造化ログとトレーシング）。
• 専用ツールはbashが実装できない不変条件を持つことができます。例えば、editツールは陳腐化チェックを持つため、モデルは最後に読み取られた後に変更されたファイルを上書きしません。

キャッシュヒット原則（クイックリファレンス）

原則	説明
静的を優先、動的を後に	リクエストを順序付けして、安定したコンテンツ（システムプロンプト、ツール）を最初にします。
メッセージで更新	プロンプトを編集する代わりに、メッセージに<system-reminder>を追加します。
モデルを変更しない	キャッシュはモデル固有です。切り替えるとそれが破裂します。サブタスクにより安価なモデルが必要な場合、サブエージェントを使用してください。
ツールを慎重に管理	ツールはキャッシュされたプリフィックスに位置します。1つを追加または削除するとそれが無効になります。動的ディスカバリーの場合、ツール検索を使用してください。これはキャッシュを破裂させずに追加します。
更新ブレークポイント	マルチターンアプリケーションの場合、ブレークポイントを最新のメッセージに移動してキャッシュを最新の状態に保ちます。自動キャッシングを使用してください。

例

パターンを示すソース内で引用されたベンチマーク（作成されたものではありません）：

• 一般的なツールを使用する：Claude 3.5 Sonnetは、bashツールとテキストエディタツールのみで、SWE-bench Verifiedで49%に達しました。Claude Codeはこれら同じツールに基づいています。
• モデルにオーケストレートさせる：BrowseCompで、Opus 4.6に独自のツール出力をフィルタリングする能力を与えると、精度は45.3%から61.6%に上昇しました。
• サブエージェント経由でモデルにコンテキストを管理させる：Opus 4.6では、サブエージェントを生成すると、最高のシングルエージェント実行よりもBrowseCompが2.8%改善しました。
• コンパクション化スケーリング：BrowseCompで、Sonnet 4.5は43%で横ばいでしたが、Opus 4.5は68%にスケーリングし、Opus 4.6は84%に到達しました。
• メモリフォルダ：BrowseComp-Plusで、Sonnet 4.5にメモリフォルダを提供すると、精度は60.4%から67.2%に上昇しました。ポケモンゲーム例では、Opus 4.6は/gameplay/learnings.md: - Bellsprout Sleep+Wrap combo: KO FAST with BITE before Sleep Powder lands.のような戦術メモを含む約10個の整理されたメモリファイルを保管していました。
• 安全性の境界：Claude Codeの自動モードは、実行前にbashコマンドの安全性を判断するために、2番目のClaudeコールを使用します。

アンチパターン

• モデルが既にbash + エディタで処理できる動作に対してカスタムツールを構築する。
• モデルが十分に能力を持つようになった後も、オーケストレーション/フィルタリング/要約スキャフォルディングを保持する。
• 具体的なUX、可観測性、またはセキュリティの理由なしに構造を追加する。
• コストの理由でセッション中盤でモデルを切り替える（キャッシュを破裂させる）のではなく、サブエージェントに委任する。
• セッション内のツールリストを変更することでキャッシュされたプリフィックスを無効化する。
• 昨日の制限がまだ成立していると仮定する。各モデルステップ変化でテストし直してください。

関連リソース

同じブログ記事からの追加資料は、ポストフォルダ内のこのスキルの隣に位置します：

ソース

Harnessing Claude's Intelligence — 3 Key Patterns for Building Apps（公開日：2026-04-02）から抽出しました。権威ある指示は元のドキュメントを参照してください。