言葉選びより、何を読ませるかで差がつく

01 — 何が起きているか

「賢い言葉」より「正しい範囲」

AIコーディングの実践者コミュニティで、最近よく見かける言い回しがある。「もうプロンプトの言葉選びで悩む時代じゃない。本当のスキルはコンテキストエンジニアリングだ」というものだ。

これは大げさな話ではない。モデルの性能そのものより、モデルに何を読ませているかの設計が結果を左右する場面が増えている。同じ指示文でも、余計なファイルまで読み込ませた状態と、必要な情報だけに絞った状態とでは、出てくるコードの質が変わる。プロンプトを工夫する労力を、読ませる範囲を設計する労力に振り替える発想がFLOWの読者にも直結する。

02 — 具体的に何をするか

3つの実践

抽象論で終わらせず、今日から手を動かせる形に落とす。

この3つは独立した技ではなく、1つの判断軸から出てくる。「今このAIに、何を見えている状態にするか」を毎回意識するだけで、タスクの切り方も、ファイルの残し方も、渡す情報の絞り方も自然と揃ってくる。逆に言えば、プロンプトの言い回しだけをいくら磨いても、見えている範囲がずれていれば結果は安定しない。

03 — 自分の運用に当てはめる

「スキルのトークン設計」も、同じ話だった

このサイトで以前扱った「自作スキルは適切なトークン量に設計されていない」という話も、根っこは同じコンテキストエンジニアリングの話だった。常時読み込まれる部分を絞り、必要な時だけ深い情報を読みに行く設計にする——これはまさに「何を・どこまで読ませるか」の設計そのものだ。

04 — 実際に比べてみた

「全部見せる」「必要な分だけ」「先に答えを渡す」を比べた

読ませる範囲を絞る話は、これまで理屈の説明にとどまっていた。実際にどれくらい差が出るのかを確かめるため、同じ問い（「あるフォルダ群の中から条件に合う1件を特定し、その中身の一部を報告する」）を、入力範囲だけ変えた3条件で軽量モデルのサブエージェントに投げ、かかった時間を比べた。

検証の限界: 今回は1回の呼び出しで完結するタスクで比較しており、「間違えて→指摘されて→直す」という複数ターンの修正回数までは測れていない（サブエージェントは1回の呼び出しで完結する設計のため）。ここは対話的なセッションでの再現実験が必要な残課題として明記しておく。また今回はごく小さな検索タスクでの実測であり、実装を伴う大きなタスクでは差がさらに広がる可能性がある。この「文脈をどこまで渡すか」という設計は、Anthropic公式が定義するコンテキストエンジニアリングとも直結する。

05 — 今日から試せること

チェックリスト

参考: Addy Osmani — My LLM coding workflow going into 2026 ／ Real Python — AI Coding Agents Guide