「良いプロンプトの書き方」を追いかける時期は、もう終わっている。海外の実践者たちが口を揃えて言い始めているのは、次の争点がコンテキスト管理に移ったということ。何を・どこまで読ませ、いつ捨てるか。その具体的な手の動かし方を整理する。
「プロンプト設計→コンテキストエンジニアリング」という争点移動の中身と、タスク分割・状態のファイル化・文脈の間引きという3つの実践。今日のセッションからすぐ試せる具体策。
AIコーディングの実践者コミュニティで、最近よく見かける言い回しがある。「もうプロンプトの言葉選びで悩む時代じゃない。本当のスキルはコンテキストエンジニアリングだ」というものだ。
これは大げさな話ではない。モデルの性能そのものより、モデルに何を読ませているかの設計が結果を左右する場面が増えている。同じ指示文でも、余計なファイルまで読み込ませた状態と、必要な情報だけに絞った状態とでは、出てくるコードの質が変わる。プロンプトを工夫する労力を、読ませる範囲を設計する労力に振り替える発想がFLOWの読者にも直結する。
抽象論で終わらせず、今日から手を動かせる形に落とす。
1回の依頼を、AIが文脈内で把握しきれる大きさまで小さくする。大きすぎる依頼は途中でモデルが道に迷う原因になりやすい。小さいコミット・小さい依頼のほうが、結果的にレビューもしやすい。
会話の中だけで状態を持ち回らず、進捗や決定事項をCLAUDE.mdのようなファイルに書き出しておく。セッションをまたいでも文脈が消えない状態を、会話の記憶力に頼らず作れる。
読ませるファイルやログは多いほど安心、ではない。関係のない情報が混ざるほど、モデルは本当に大事な部分を見失いやすくなる。「念のため全部渡す」をやめ、必要な範囲だけに絞る判断がそのままアウトプットの質になる。
この3つは独立した技ではなく、1つの判断軸から出てくる。「今このAIに、何を見えている状態にするか」を毎回意識するだけで、タスクの切り方も、ファイルの残し方も、渡す情報の絞り方も自然と揃ってくる。逆に言えば、プロンプトの言い回しだけをいくら磨いても、見えている範囲がずれていれば結果は安定しない。
このサイトで以前扱った「自作スキルは適切なトークン量に設計されていない」という話も、根っこは同じコンテキストエンジニアリングの話だった。常時読み込まれる部分を絞り、必要な時だけ深い情報を読みに行く設計にする——これはまさに「何を・どこまで読ませるか」の設計そのものだ。
争点は移った。「どう指示するか」で悩む時間を減らし、「何を読ませて、何を読ませないか」を設計する時間に振り替える。これが今の実践者たちの共通認識になりつつある。
参考: Addy Osmani — My LLM coding workflow going into 2026 ／ Real Python — AI Coding Agents Guide