AIを賢く動かすのは「指示力」ではなく「文脈設計力」

対象読者

• AIとやり取りしているうちに、気づいたら時間が溶けている方
• AIで効率化しているはずなのに、実感が持てない方
• 指示を出し直すループにハマって、同じところを行ったり来たりしている方

はじめに

AIコーディングをしていて、気づいたら時間が溶けていた。という話を聞くことがあります。

プロンプトをもっと詳しく書けばよくなるはずだと、指示を工夫してみる。でもなぜか状況は良くならない。それどころか、やり取りを続けるほど沼にハマっている気がする...

これはプロンプトの問題ではなく、LLMの制約によるものです。その制約を理解し、上手に付き合う方法が「コンテキストエンジニアリング」という考え方です。この記事では、なぜAIとの会話で時間が溶けてしまうのか、その仕組みと対処法を解説します。

プロンプトだけでは限界がある理由

LLMは確率で動いている

LLMは、次に来る単語を「確率的に予測する」システムです。

「今日の天気は...」という文章の後に「晴れ」「曇り」「雨」など、様々な言葉が続く可能性があります。LLMは無数の可能性の中から、最も適切そうな次の単語を確率的に選んでいます。

同じプロンプトでも微妙に違う結果が出るのは、この確率的な性質によるものです。

そして、その確率分布を大きく左右するのが「コンテキスト（文脈）」です。

会話が長くなると起きること

会話が長くなると、AIの応答品質が下がることがあります。「コンテキストの腐敗（Context Rot）」と呼ばれています。

人と同じように、AIも「すべてに同時に注意を向ける」ことはできません。会話の最初は重要な指示にAIの注意が100%向いています。しかし会話が進むにつれ、雑談、コード、エラー、修正と情報が増えていくと、注意が分散してしまいます。会話の中で喧嘩なんてしてると、強い思い出として注意を向けてしまっているかもしれませんね（笑）

さらにLLMには「真ん中の情報を忘れやすい」という特性（Lost in the Middle問題）があります。最初と最後の情報は覚えているのに、真ん中あたりの情報を忘れてしまうことがあります。人みたいですね。

必要のない情報が増えると、本当に重要な情報が埋もれてしまいます。理想的には重要な情報だけが並んでいることですが、不要な情報、エラーログ、デバッグ出力などが混在して、重要な情報を見つけにくくなります。

記憶力には限りがある

LLMには、コンテキストウィンドウという制約があります。情報量がこの限界を超えると、AIはコンテキストの一部を忘れてしまいます。ツールによっては残量をみて会話履歴を要約して圧縮したりしますが、その際にも一部を忘れてしまうことがあります。

モデル	コンテキストウィンドウ（トークン）
GPT-5 Codex	272K
Claude Sonnet 4.5	200K（1M版あり）
Gemini 2.5 Flash	1M
Gemini 2.5 Pro	1M
Composer 1	200K

プロジェクトルール（AGENTS.md,CLAUDE.md,copilot-instructions.mdなど）、MCPツール定義（使われなくても消費される）、指示・会話履歴...。これらがコンテキストウィンドウを圧迫していきます。

AIに「何を見せるか」を設計する

確率を味方につける

LLMは確率的に次の単語を予測しています。つまり、どれだけ賢いAIでも「当たりに向かうよう仕向けてあげる」ことが重要です。

その確率の精度を高める方法が、AIに見せる情報（＝コンテキスト）を設計することです。適切な情報を適切な配置で見せれば、より正確な予測ができます。

しかし、現代のLLMには大きな制約があります。コンテキストウィンドウのサイズが理想的な大きさに達しておらず、実用的に不足する場面がよくあります。

制約の中で、いかに精度を高めるか。それがコンテキストエンジニアリングの本質です。

「足し算」から「引き算」へ

ほとんどの人が最初に学ぶのは「プロンプトエンジニアリング」です。「細密な指示を書けば、AIは正しく動く」という考え方です。

しかし、詳しい指示を書くほど、限られたコンテキストウィンドウは圧迫されていきます。これは「足し算」のアプローチです。

コンテキストエンジニアリングは「引き算」のアプローチです。限られた領域を最適に使うため、本当に必要な情報だけを残し、不要な情報は削除します。

例えば、こんな対処法があります。

• 会話をこまめにリセット - タスクが変わったときや、会話を重ねても進捗が感じられないときは新しい会話へ
• プロジェクトルールの見直し - 使っていないルールや、細かすぎる指示を削除
• MCPツールを整理 - 直近のタスクで使うツールだけ有効化。迷ったら無効化し、必要になったら再度有効化
• 関係ないファイルを除外 - .gitignoreで、見せる必要のないファイルを減らす

「本当に必要な情報」を見極めるには、基礎力が必要になります。コードの構造、システムの仕組み、問題の本質、そしてゴールを理解していないと、何を残して何を削るべきか判断できません。コンテキストエンジニアリングは、基礎的な理解の上に成り立つスキルです。

コンテキストを減らすことには、応答品質の向上以外にもメリットがあります。入力トークンが減りますので、コストの削減 や レート制限の回避 にも繋がります。いいことだらけですね！

以下の記事で、いくつか具体的な方法を紹介しています。

https://zenn.dev/aun_phonogram/articles/05b4ca7afa3b55

Claude Code を例に説明していますが、コンテキストウィンドウの制約はLLM全般に共通する特性です。Codex CLI、Cursor、GitHub Copilot、その他のAIコーディングツールでも、同じ考え方が適用できます。

おわりに

この記事を書くきっかけは、AIとのチャットを延々と重ねた末、結局時間を浪費してしまっていると相談を受けたことでした。プロンプトを工夫しても、会話を続けるほどAIの応答が悪くなっていく... 原因は、LLMの制約を理解していなかったことにありました。

コンテキストエンジニアリングという言葉自体は新しいものではありませんが、意識して実践している人はまだ多くないのかもしれません。プロンプトをどれだけ工夫しても解決しなかった問題が、コンテキストを見直すだけで改善することもあります。

また、Cursor 2.0 のアップデートで並行開発がやりやすくなり、複数のエージェントを同時に動かすことが当たり前になる時代が来ようとしています。それぞれのエージェントに適切なコンテキストを渡す「文脈設計力」は、ますます重要になっていくと思います。

同じような課題を抱えている方の参考になれば幸いです！