Claude の次の飛躍は、より優れたプロンプトの詩ではありません。それは、よりクリーンなコンテキストの配管です。
プロンプトはもはや製品ではない
Claude 5 のコンテキストエンジニアリングに関するレポートから得られる有用な知見は、ほぼ退屈なものです。Claude にメッセージを送信するとき、プロンプトはモデルが受け取るもののごく一部に過ぎません。残りは、システムプロンプト、Skills、CLAUDE.md ファイル、メモリ、その他のソースから組み立てられます。
これが重要なポイントです。インターフェースは依然としてチャットボックスのように見えます。しかし、実際の仕組みはコンテキストアセンブリシステムです。Claude Code や独自のエージェントで構築している場合、実際に提供しているものは巧妙な指示ではありません。それは ランタイムコンテキストアーキテクチャ です。
プロンプトの天才的なひらめきは、優れたスクリーンショットになります。しかし、コンテキストの規律は、システムが多数のリクエストにわたって一貫して動作するようにします。華やかさは減りますが、より有用です。当然、バイラルにはなりにくいでしょう。
汎用的なコンテキストは、特定のプロンプトよりも難しい
プロンプトは狭く設定できます。ユーザーが一つのことを求め、あなたはモデルをそのことへと導き、皆がデモを製品だと見なします。コンテキストは異なります。CodeBun の記事はこれを明確に示しています。コンテキストは多くのリクエストにわたって汎用的に使用されるため、特定の内容にすることはできません。
ここが、ほとんどのエージェント構築がおかしくなる点です。チームは、失敗があるたびに足りない一文があるように感じられるため、指示を追加し続けます。もう一つのルール。もう一つのポリシー。もう一つの例。やがてモデルは、今日の質問に答える前に、昨日の傷跡の中を泳ぐことになります。
難しいスキルは、完璧なパラグラフを書くことではありません。デフォルトで存在する価値があるものを決断することです。コンテキストエンジニアリングは、不確実性の下でのキュレーションです。次のユーザープロンプトはわかりません。それでも、モデルがそのプロンプトに何を持ち込むべきかを決断しなければなりません。
Claude 5 が圧縮の計算を変えた
研究の中で最も鋭いデータポイント：Anthropic のエンジニアは、Claude Opus 5 や Claude Fable 5 などの新しい Claude モデル向けに、Claude Code のシステムプロンプトの 80% 以上を削除したと報告されており、コード評価において測定可能な損失はありませんでした。
これは、すべての長いプロンプトが悪いことを証明するものではありません。また、すべてのワークフローが金曜日までに指示の 80% を削除すべきだということを証明するものでもありません。どうか、一つの評価結果を宗教にしないでください。私たちはすでに十分な数のそれを持っています。
しかし、これは重要なことを示しています。モデルの能力が向上するにつれて、古い足場は無駄な重荷になり得るということです。昨日のモデルを助けた指示が、今日のモデルを混乱させる可能性があります。モデルが向上するにつれて、コンテキストは小さくする必要があるかもしれません。
新しいオペレータースキルは引き算である
ほとんどの人は「コンテキストエンジニアリング」と聞いて、拡張を連想します。より多くのファイル、より多くのメモリ、より多くの背景、より多くのツール、より多くのルール。Claude 5 の教訓は別の方向を指しています。Claude Code のシステムプロンプトの大部分が、コーディング評価に悪影響を与えずに消え去ることができるのであれば、デフォルトの質問は 他に何を追加すべきか？ から 安全に削除できるものは何か？ に変わるべきです。
これは、ランタイム版のセンスのようなものです。多くのリクエストにわたって一貫して結果を改善するコンテキストを維持してください。誰かが一度失敗を見て、システムプロンプトをパニック修正したために存在するコンテキストは削除してください。
最高の AI オペレーターは、プロンプトの詩人のように見えるのではなく、編集者、図書館員、インフラエンジニアのように見えるでしょう。彼らは、CLAUDE.md ファイル、Skills、システム指示、メモリを生きたコンテキストレイヤーとして維持します。それらを剪定します。テストします。誰も理解せず、誰も触れるのを恐れている、神聖な 4,000 語の指示ブロックに抵抗します。
エージェントはコンテキストの負債を高くする
これは、一回限りのチャットよりもエージェントにとって重要です。研究は、コンテキストエンジニアリングを Claude Code と独自のエージェントの構築 に明確に関連付けています。エージェントにおいて、コンテキストは単一のメッセージではありません。それは運用環境の一部です。
悪いコンテキストは複合的に悪化します。曖昧なシステムルールがツールの使用を歪める可能性があります。古くなったメモリが意思決定を誤らせる可能性があります。過剰に詰め込まれたプロジェクトファイルが、重要だった唯一の指示を埋もれさせる可能性があります。ユーザーは不安定なエージェントを目にします。実際のバグはコンテキストスタックにあるかもしれません。
これが、「プロンプティング」という言葉が小さすぎる理由です。エージェントには、コンテキスト予算、コンテキストソース、コンテキスト衛生が必要です。何がグローバルで、何がタスクローカルで、何がメモリに属し、何がファイルに属し、何をまったくロードすべきでないかについての決定が必要です。
ガバナンスも同じ方向へ押し進めるだろう
コンプライアンスの背景も動いています。Gunderson の 2026 年 AI 法アップデートは、変化するガバナンスの状況を説明しており、連邦政府による AI 監視統合の取り組み、コロラド州とカリフォルニア州の新しい枠組み、EU AI 法に基づく進化する国際的要件などが含まれます。欧州委員会は、EU AI 法を AI リスクに対処する法的枠組みとして説明しています。
これは、すべての Claude コンテキストファイルが突然規制上のアーティファクトになることを意味するわけではありません。しかし、AI チームが、自社のシステムに何が指示されているか、そのコンテキストがどこから来ているか、そしてそれがどのように変化するかを知る理由が増えることを意味します。
言い換えれば、コンテキストエンジニアリングはパフォーマンスチューニングだけではありません。それは運用管理です。勝利するチームは、最も精巧なプロンプトを持つチームではありません。製品を壊さずに、コンテキストを説明、テスト、削除できるチームです。
執筆者について
私は Harley Foote です。実際の仕事を行う AI エージェントを構築しており、重要な変化にはいち早く対応しようと努めています。
私が全力で取り組んでいる二つのこと： heyfriday.app — あなたの好みを学習するパーソナル AI ショッピングエージェント。そして hermesshield.ai — AI エージェントのためのセキュリティ。エージェントがあなたに代わって行動できる瞬間、攻撃される可能性があるからです。
エージェント分野で構築しているなら、ぜひご連絡ください。
heyfriday.app · hermesshield.ai · linkedin.com/in/harley-lewis-foote-850177109
