判断能力が向上したClaudeモデルを効果的に使用するには、プロンプトの一文を整えるだけでは不十分だ。モデルが一度の推論で目にするシステム指示、プロジェクトファイル、ツール、メモリ、対話履歴、実行結果を、一つの情報環境として設計する必要がある。

中核となる原則はシンプルだ。

あらゆる行動を事前に規定するのではなく、明確な目的、安全上の境界、表現力の高いインターフェース、信頼できる参照資料を提供し、細かな判断はモデルに委ねる。

この記事でのClaude 5は、提供された資料が指す次世代の高性能Claudeモデル環境を意味する。具体的な製品仕様やリリース状況ではなく、判断能力が向上したモデルに適用できるコンテキスト設計の原則に焦点を当てる。

プロンプトエンジニアリングとコンテキストエンジニアリング

プロンプトエンジニアリング

プロンプトエンジニアリングとは、現在のリクエストをどのように表現するかを設計する作業だ。一般的には次の項目を扱う。

  • 作業目標
  • 実施範囲
  • 制約条件
  • 出力形式
  • 成功基準
  • 必要な例

たとえば、次のようになる。

Next.js API Routeに決済キャンセル機能を実装する。
既存のサービス層を再利用し、テストを追加する。
公開API契約は変更せず、変更理由を説明する。

コンテキストエンジニアリング

コンテキストエンジニアリングとは、モデルの推論に入力される情報全体を選別し、維持する作業だ。Claude Codeのようなコーディングエージェントでは、おおむね次の要素がコンテキストを構成する。

ユーザーの現在のリクエスト
+ システム指示
+ CLAUDE.mdとプロジェクト指示
+ Skills
+ 自動メモリ
+ コード・仕様・テスト・文書
+ ツール定義とMCPリソース
+ 対話履歴
+ ツール実行結果とエラーログ

したがって、優れたプロンプトでも、古いメモリ、重複したプロジェクトルール、または膨大なログと一緒に提供されると効果が弱まる可能性がある。反対に、短いリクエストでも、関連するコードとテスト、明確なツールが併せて与えられれば、十分正確に実行できる。

区分 プロンプトエンジニアリング コンテキストエンジニアリング
設計対象 現在のリクエストの表現 推論に入力される情報環境全体
主な問い 何をどのように依頼するか モデルに何をいつ見せるか
代表的な要素 目標、形式、制約、例 システム指示、ファイル、ツール、メモリ、履歴
主な失敗 曖昧なリクエスト、不明確な成功基準 衝突、重複、古い情報、過剰なログ
改善方法 リクエストを具体化し、検証基準を提示 シグナルの高い情報の選別、適時検索、ライフサイクル管理

コンテキストは多いほど常によいわけではない理由

LLMのコンテキストウィンドウが大きくなっても、作業に使える注意力は無制限ではない。関連性の低いトークンが増えると、次の問題が生じる可能性がある。

  1. 重要な要件が冗長な説明の中に埋もれる。
  2. 異なる場所にある類似の指示が微妙に衝突する。
  3. 古い決定や失敗した試みが現在の作業に影響する。
  4. 例が正解のように機能し、別の解決経路を制限する。
  5. ログやツール出力が、コード、仕様、テストに必要な領域を占有する。
  6. モデルが実際の作業よりも、指示の優先順位を解釈することに推論を費やす。

Anthropicは、長いコンテキストで情報の活用効率が低下する現象を説明し、エージェントが必要な情報を適時に検索し、古い履歴を圧縮するよう設計することを推奨している。重要なのは最大トークン数を埋めることではなく、結果に影響するシグナルの高いトークンの割合を高めることだ。

システムプロンプト削減事例が意味すること

提供されたAnthropicの事例では、Claude Codeの内部指示を見直した後、システムプロンプトを80%以上削減したと説明している。この数値は、すべてのアプリケーションのプロンプトを同じ割合で減らすべきだというルールではない。特定のシステムで重複し、過度に詳細だった行動指示を整理した事例として理解すべきだ。

たとえば、次の指示が一つのリクエストに同時に含まれることがある。

システム指示：状況に合った文書を残す。
Skill指示：コメントを追加しない。
ユーザーのリクエスト：既存バージョンと同じように動作させる。

それぞれの文は個別には妥当でも、組み合わせると複数の解釈上の問題が生じる。

  • 文書とコードコメントは同じカテゴリーなのか？
  • コメント禁止は例外のないルールなのか？
  • 既存バージョンの動作には、コメントや文書構造も含まれるのか？
  • 現在のリクエストと再利用可能なSkillのどちらが優先されるのか？

この場合、失敗の原因はモデルのコーディング能力だけではない。人間が構成した情報環境に不要な矛盾が含まれていることも原因だ。

6つの新しいコンテキスト設計ルール

従来の方式 推奨される方式
詳細な行動を禁止事項の一覧で規定 目標と判断基準を示し、コンテキストを活用
ツール呼び出しの例を多数提供 スキーマ自体が使い方を説明するよう設計
すべての情報を作業開始時に注入 必要な時点で段階的に公開
同じ指示を複数の場所で反復 指示ごとに一つの権威ある保存場所を指定
CLAUDE.mdに一時的な記憶まで保存 永続的なポリシーと自動メモリの役割を分離
長いMarkdownの説明に依存 コード、テスト、HTML、評価表など実行可能な資料を提供

1. 詳細な禁止事項の一覧をコンテキストベースの原則に変える

従来のモデルで繰り返されるミスを防ぐため、次のようなルールを長々と列挙することがあった。

  • コメントを書かない。
  • 複数段落のdocstringを作成しない。
  • 要求されていない計画文書を生成しない。
  • 中間分析ファイルを保存しない。

このようなルールは特定の失敗を防ぐが、あらゆる状況に適用できる絶対的な原則ではない。複雑なセキュリティ検証や並行処理コードには説明が必要な場合があり、自明なCRUDコードではコメントがかえってノイズになる場合がある。

次のように判断基準を示すほうがよい。

周辺のコードと同じように読めるコードを書く。
既存ファイルの命名規則、慣用表現、コメント密度に従う。
説明がなければ安全性や意図が不明確なロジックにのみ、必要な文書を追加する。

ただし、すべてのルールを弱めてはならない。次の項目は、明示的な制約またはツールレベルの制御として維持すべきだ。

  • 本番環境へのデプロイとデータ削除の承認
  • 個人情報と機密情報の処理制限
  • 認証・認可の検証
  • 金銭取引の冪等性と監査記録
  • データベースマイグレーションのポリシー
  • 法律、ライセンス、規制の遵守
  • 変更できない公開API契約
ルールの種類 適切な処理方法
セキュリティ・法律・権限 明示的で強い制約を維持
データ損失の可能性がある作業 承認手順とツール権限で制御
公開契約・互換性 テストとスキーマで検証
コードスタイル・コメント 周辺コードに基づく判断原則を使用
一時的な作業順序 現在の計画やタスクリストで管理

2. 多数の例よりも表現力の高いツールを設計する

ツールの説明に正常・異常な呼び出し事例を追加し続けると、コンテキストが大きくなり、モデルが例の表面的な形式を模倣する可能性がある。よりよい方法は、ツール名、入力フィールド、状態遷移から使い方が明らかになるようにすることだ。

TodoWrite
目的：現在のセッションのタスクリストを作成・更新

status:
- pending
- in_progress
- completed

制約：
- 同時にin_progressにできるタスクは一つのみ

優れたエージェントツールには、次の特性がある。

  • 名前だけで行動と対象が分かる。
  • 必須フィールドと任意フィールドが区別されている。
  • 列挙型で許可される値を制限する。
  • 読み取りと書き込み、プレビューと実行を分離する。
  • エラーが原因と復旧方法を構造化して返す。
  • 危険な作業では確認トークンや承認手順を要求する。
  • 結果が長すぎる場合は、要約とページ移動機能を提供する。

例は、インターフェースで表現しにくい例外や曖昧な入力を説明する場合にのみ追加するのがよい。

3. すべての情報を最初から入れず、段階的に公開する

エージェントの作業に必要になる可能性があるという理由だけで、リポジトリ全体、すべてのポリシー、長いログを最初から注入してはならない。まず探索に必要な最小限の情報を与え、作業が具体化した時点で関連資料を読ませる。

推奨される流れは次のとおりだ。

  1. 目標、成功基準、安全上の境界を提供する。
  2. リポジトリ構造や検索ツールを通じて関連箇所を見つける。
  3. 必要なファイルと仕様だけを読む。
  4. 実装後、関連するテストと静的解析を実行する。
  5. 失敗した場合は、該当するエラーと周辺コードだけを追加で取得する。
  6. 完了後、古いログと中間推論を圧縮または削除する。

段階的な公開は、情報を隠すことではない。必要な情報をモデルが発見できるよう、検索経路と明確なファイル構造を提供する方式だ。

4. 重複する指示を削除し、権威ある場所を定める

同じルールをシステムプロンプト、CLAUDE.md、Skill、ツール説明に複製すると、時間の経過とともに文言が異なってくる可能性がある。指示の種類ごとに、一つの権威ある保存場所を定める必要がある。

情報 推奨される場所
組織全体の安全ポリシー システム指示または権限階層
リポジトリのビルド・テストコマンド プロジェクトのCLAUDE.md
特定作業の手順 該当するSkill
ツールの入力と制約 ツールのスキーマと説明
公開APIの動作 コードスキーマ、仕様、契約テスト
現在のセッションの進捗状況 タスクリストまたはセッション状態

重複が避けられない場合は、内容をコピーせず、権威ある場所を参照するか、自動生成するほうが安全だ。

5. CLAUDE.mdと自動メモリの役割を分離する

CLAUDE.mdは、プロジェクトメンバーがレビューし、バージョン管理できる継続的な指示に適している。

  • 標準的なビルド・テストコマンド
  • リポジトリ構造の主要な説明
  • チームで合意した変更禁止領域
  • プロジェクト固有の検証手順
  • 一般的なツールでは推論しにくいルール

一方、次の情報は自動メモリやセッション状態により適している。

  • 反復作業で見つけた個人向けの設定や好み
  • 最近の作業で有用だった探索経路
  • 一時的な開発環境の特性
  • 現在のセッションの進捗状況

自動メモリが常に正確または永続的だと想定してはならない。古い項目を修正または削除できる必要があり、セキュリティポリシーや公開契約の唯一の保存場所として使用してはならない。

6. 説明文書より実行可能な参照資料を優先する

自然言語の仕様は意図の説明に役立つが、実際の動作を完全には表現できない場合がある。可能であれば、次の資料も併せて提供する。

  • 現在のコードに類似する既存実装
  • 単体テストと統合テスト
  • APIスキーマと型定義
  • 実際のHTMLまたはデザイン成果物
  • データベースマイグレーションファイル
  • 入出力のサンプルデータ
  • 評価表と自動採点基準

参照資料同士で衝突が生じる可能性もあるため、優先順位を明示する必要がある。たとえば、契約テストを公開APIの権威ある基準とし、READMEを説明資料と定めることができる。

実務向けコンテキスト構成テンプレート

次の構造は、コーディング作業に必要な情報を簡潔に整理する例だ。

目標
- 決済キャンセルAPIを追加する。

成功基準
- 既存の決済サービス層を再利用する。
- 重複リクエストでも一度だけキャンセルされる。
- 関連する契約テストに合格する。

強い制約
- 公開レスポンススキーマを変更しない。
- 本番データにアクセスしない。

参照資料
- src/payments/capture.ts
- tests/contracts/payment-cancel.test.ts
- openapi/payments.yaml

判断原則
- 周辺の決済コードにおけるエラー処理と命名規則に従う。
- 安全ではない仮定がある場合は、実装前に質問する。

検証
- 対象の単体テスト
- 契約テスト
- 型チェック

この形式は、あらゆる状況を事前に列挙するものではない。代わりに、目標、成功条件、変わらない境界、権威ある資料、検証方法を分離する。

既存のコンテキストを整理する手順

ステップ1：すべての指示の出所を一覧化する

システムプロンプト、CLAUDE.md、Skills、自動メモリ、ツール説明、CI設定をまとめて確認する。一つの文書だけを見ても、実際の衝突を発見するのは難しい。

ステップ2：各指示に分類ラベルを付ける

  • 安全または法律上必須
  • 製品契約上必須
  • チームの継続的な慣例
  • 特定のツールにのみ必要な説明
  • 過去のモデルのミスを防ぐための一時的なルール
  • 現在は根拠が不明確なルール

ステップ3：重複と衝突を見つける

同じ行動を異なる形で表現した文をまとめる。特に常に、絶対に、必ず、してはならないといった表現を優先的に検討する。

ステップ4：ルールをテストや権限に移す

自然言語による警告より自動検証のほうが確実な項目は、次の階層へ移す。

  • テストとリンター
  • 型システムとスキーマ
  • 最小権限のツール
  • 承認手順
  • サンドボックス
  • CIポリシー

ステップ5：実際の作業で評価する

プロンプトの長さだけを測ってはならない。代表的な作業セットで、次の指標を比較する必要がある。

  • 成功率とテスト合格率
  • 不要なファイル変更数
  • ユーザーによる修正回数
  • ツール呼び出しの失敗率
  • 完了までにかかった時間とトークン
  • 安全ポリシー違反の有無

ステップ6：失敗原因だけを最小限に補う

失敗が発生したからといって、すぐに新しい禁止ルールを追加してはならない。原因が曖昧な目標なのか、不足している参照資料なのか、誤ったツールスキーマなのかを、まず区別する。

削除してはならない指示

簡潔化は無条件の削除ではない。次の質問の一つにでもはいと答えられるなら、指示を維持するか、より強い制御へ移す必要がある。

  • 違反した場合、データ損失や金銭的被害が発生するか？
  • 法律、個人情報、またはライセンス上の義務に関係するか？
  • モデルがコードだけを見ても分からない組織ポリシーか？
  • 公開APIやデータ形式の互換性を決定するか？
  • 作業の実行前に人間の承認が必要か？
  • 自動テストだけでは違反を完全に検出するのが難しいか？

よくある失敗パターン

あらゆる失敗の後に新しいルールを追加する

一度のエラーを一般化して永続的なルールにすると、例外と衝突が蓄積する。まず評価事例を追加し、繰り返される失敗かどうかを確認する必要がある。

長い例を事実上のテンプレートとして使用する

例が具体的すぎると、モデルが現在のコードベースよりも例を優先する可能性がある。例は原則を説明するための最小限のサイズに制限する。

ログ全体をそのまま保存する

ツール出力とビルドログは、すぐにコンテキストを占有する。失敗原因、関連スタック、変更された状態だけを構造化して残すのがよい。

自動メモリをポリシーの保存場所として使用する

自動メモリは便利だが、レビュー・デプロイ・監査体制が弱い場合がある。組織の強制ポリシーは、バージョン管理される指示や権限階層に保存すべきだ。

コンテキスト削減を単なるトークン節約として評価する

短いコンテキストが常によいわけではない。必要なテスト、安全ルール、または仕様を削除すると結果が悪化する。目標は最小トークンではなく、必要最小限のシグナルの高いトークンだ。

最終チェックリスト

  • 現在のリクエストの目標と成功基準が分離されているか？
  • 安全ルールとスタイル上の好みが区別されているか？
  • 同じ指示が複数の場所に複製されていないか？
  • ツールスキーマが長い例なしでも使い方を説明しているか？
  • 関連ファイルを必要なときに検索できるか？
  • 古いメモリと実行ログを削除する方法があるか？
  • 自然言語のルールをテストや権限で強制できるか？
  • 参照資料間の優先順位が明確か？
  • 指示の変更前後を比較する評価作業があるか？

結論

高性能Claudeモデルのためのコンテキストエンジニアリングは、指示を無条件に減らす技術ではない。モデルが現在の作業を判断するために必要な目的、安全上の境界、根拠を明確にし、関連性のない情報や衝突するルールを取り除く情報設計だ。

最も実用的な原則は、次のように要約できる。

セキュリティと契約は強く強制し、スタイルはコンテキストに委ね、情報は必要な時点で提供し、結果は実行可能なテストで検証する。