同じ AI コーディングツールでも、頼み方で返ってくるコードの質はまるで変わります。ふつうの会話プロンプトと違い、コーディングでは「どのファイルを見せるか」「何ができたら完了か」「破ってはいけない制約は何か」を先に渡すほど成功率が上がる。本稿は Cursor・Claude Code・GitHub Copilot のような 2026 年の主要ツールを念頭に、初めての人でも今日から使える具体的な書き方を整理します。
FIG.1 コーディングのプロンプトは「察してもらう」より「条件をそろえて渡す」
01まず押さえる 5 つの土台
個別のテクニックの前に、どのツールでも効く 5 つの基本があります。これを満たすだけで、やり直しの回数が目に見えて減ります。
文脈を十分に渡す
「直して」だけでは前提が伝わりません。「このプロジェクトは Next.js・TypeScript の strict モード・テストは Vitest。認証まわりの X を Y のように直して」のように、フレームワーク・言語設定・テスト基盤を添える。AI はリポジトリ全体を必ずしも読んでいないので、関係する前提を明示するほど精度が上がります。
「完了」の条件を言葉にする
「いい感じに」ではゴールが決まりません。「テストが全部通る／Lint エラーなし／既存 API と互換」のように、満たすべき状態を箇条書きで渡す。完了条件があると AI は自分の出力を自己点検しやすくなります。
守るべき制約を伝える
「新しいライブラリは足さず既存依存のみ」「外部 API は呼ばない」「計算量は O(N) 以下」など、やってほしくないことこそ明記する。制約がないと AI は手近な解（新規パッケージ追加など）を選びがちです。
見てほしいファイルを名指しする
関連コードを指し示すと、的外れな書き換えが激減します。ツールごとの指定方法は後述。曖昧な「このへん」ではなく、ファイル名・関数名で具体的に。
大きな作業は計画を先に出させる
いきなり書かせず、「まず実装計画を箇条書きで。OK を出したら実装。途中で迷ったら質問して」と頼む。計画を見て方向を直せば、書き直しのコストを払わずに済みます。
コーディングの成功率を決めるのは、賢い言い回しより渡す文脈の設計。2026 年はモデルが十分賢くなり、何を見せ・どこで区切るかの“段取り”が出力差を生みます。
02ファイル参照：ツールごとの「見せ方」
コーディングで最も効くのが「関係するコードを的確に見せる」こと。主要ツールはそれぞれ指定方法を持っています。読み込ませる量は多すぎても少なすぎても精度が落ちるので、必要な箇所に絞るのがコツです。
FIG.2 500 行のファイル全体より、対象の関数だけを渡すほうが文脈が締まる
| ツール | 関連コードの渡し方 |
|---|---|
| Cursor | @ファイル名 でファイルを、@Folders でフォルダを、@Code で特定の関数・クラスだけを指定。ファイル全体より関数だけ渡すほうが焦点が締まる。@Web や @Docs で外部情報も足せる。 |
| Claude Code | 会話の中で @auth.ts のようにパス参照でき、リポジトリ全体を読んだうえで作業する。プロジェクト共通の前提は CLAUDE.md に書いておくと毎回読み込まれる。 |
| GitHub Copilot | Copilot Chat はエディタで開いているファイルを文脈に取り込みやすい。# でファイルやシンボルを明示的に追加することもできる。 |
ファイル参照のコツは「少なく、的確に」。フォルダ全体を渡すと中身が多いと一部しか読まれず取りこぼすことがあるため、関係する数ファイル・対象の関数に絞るほうが結果が安定します。
03場面別のテンプレート
よく出くわす 4 場面は、型を覚えておくと毎回ゼロから考えずに済みます。いずれも「目的 → 要件 → 制約 → 進め方」の順で並べるのが共通の骨格です。
新機能の追加
「実現したいこと（例：プロフィール画像のアップロード）／形式・上限（JPG・PNG、5MB 以下）／保存先（ストレージ）／DB の変更点／既存の認証を再利用／テストも追加。まず計画を立て、OK 後に実装」。
バグ修正
「現象（ログイン後にトップが 404）／再現手順を番号付きで／期待する挙動／直近の変更（feat/auth-refactor の PR）。原因を調査し、修正案を先に提示して」。
リファクタ
「対象（auth 配下）／目的（セッションから JWT へ）／制約（既存 API 互換・既存テスト全通過・段階的に並行稼働）。影響範囲と計画を先に出して」。
テスト追加
「対象（日付パース関数）／狙うカバレッジ／フレームワーク（Vitest）／ケース（正常・異常・うるう年やタイムゾーンのエッジ）。実装後にカバレッジを報告して」。
ポイントは、再現手順や受け入れ条件を箇条書きで構造化すること。文章でだらだら書くより、AI が一つずつ確認しやすくなります。
04避けたい頼み方
逆効果になりやすい指示には共通点があります。いずれも「基準が AI に伝わっていない」型です。
- 「もっと良く」──何を改善すべきかが無いので、AI が勝手に解釈して的外れになりがち。「可読性を上げて」「重複を関数に切り出して」など、良さの定義を渡す。
- 「最新の書き方で」──“最新”の基準は曖昧。「TypeScript の strict で」「async/await で」など、具体的な書き方を名指しする。
- 「クールに／かっこよく」──主観的すぎて余計な装飾を招く。挙動と制約で語る。
- 巨大な「全部やって」──一度に詰め込むと品質が崩れる。機能・ファイル単位に分割して順に依頼する。
05言語別のひとこと制約
言語ごとに「これを守って」と一言添えるだけで、出てくるコードがその現場の作法に寄ります。下は 2026 年時点で広く使われる指定の例です（チームの規約に合わせて取捨選択を）。
| 言語 | 添えると効く指示の例 |
|---|---|
| TypeScript | 「any 禁止・strict モード」「入力の検証は Zod（または Valibot）で」「ジェネリクスで型を保つ」。 |
| Python | 「型ヒントを付け mypy strict で通す」「pyproject.toml と uv で依存管理」「Ruff で整形・Lint」「データ検証は Pydantic v2」。 |
| Rust | 「unsafe ブロックは使わない」「Clippy の警告をすべて解消」「ライフタイムは明示」。 |
こうした制約は毎回手で書くより、後述の設定ファイルに一度書いておくほうが楽で確実です。
06うまくいかないときの立て直し
一発で通らないのは普通のこと。リカバリの仕方を知っていれば、堂々巡りを避けられます。
- 失敗を具体的に伝える──「テスト X が落ちる」だけでなく、エラーメッセージを丸ごと貼る。「この出力を踏まえ、原因を分析して直して」と続ける。
- 方向性ごと変える──小手先の修正を重ねるより、「アプローチが違う。〜の方向で行きたい。今のコードは破棄して計画から立て直して」とリセットするほうが早いことが多い。
- 勝手な断定に注意──AI は事実を“それらしく”作る（ハルシネーション）ことがある。API 仕様やライブラリの引数は、公式ドキュメントや実際の型定義で裏取りしてから採用する。
Plan First & Guardrails
大きな変更ほど「計画モード」で先に合意する
影響が複数ファイルに及ぶ変更・スキーマ変更・認証まわりは、いきなり書かせると事故りやすい領域です。2026 年の Claude Code には、コードを触る前に変更予定のファイル・追加削除するロジック・副作用（マイグレーションや環境変数、新規依存）・想定リスクを平文で出してから着手する「計画モード」があります（Shift+Tab を続けて 2 回で切替）。人間がそれを読んで承認・修正してから実装に進む流れです。
FIG.3 計画 → レビュー → 承認 → 実装。書く前に止めて合意するガードレール
仕組みの呼び名はツールで違っても、考え方は共通です。3 ファイル以上に触れる・データを移行する・認証や決済に関わる変更は、必ず計画を先に出させて目を通す。これが初心者が事故を避ける一番効く習慣です。
07長いセッションを荒れさせない
会話が長引くほど、古い文脈が混ざって AI の判断がにぶります。次の運用で“きれいな状態”を保ちます。
- こまめに区切る──話題が変わったら新しいセッションへ。前の作業の残り香（文脈の汚染）を持ち込まない。
- 節目で commit──うまくいった成果はその都度コミット。AI が後で壊しても、戻れる地点を作っておく。
- 定期的に要約させる──「ここまでの決定事項を 5 行で」と頼み、認識のズレを早めに正す。
08繰り返す指示は設定ファイルに固定する
毎回同じ前提を打ち込むのは無駄です。プロジェクト共通のルールは、ツールが起動時に読む設定ファイルに書いておくと、以後は自動で守られます。
- Claude Code：
CLAUDE.md（リポジトリ直下。起動のたびに読み込まれる） - Cursor：
.cursor/rules（プロジェクトのルール） - GitHub Copilot：
.github/copilot-instructions.md
ただし書きすぎは逆効果。モデルが一度に確実に守れる指示は数百件が上限とされ、その一部はツール自身の内部指示で埋まっています。ルールファイルは要点を絞り、長くしすぎない（目安として 200 行以内）こと。コマンド・コードスタイル・ワークフローの“コードから読み取れない前提”だけを書くのが効きます。
09まとめと次の一歩
コーディングのプロンプトは、文脈・完了条件・制約をそろえ、見てほしいコードを的確に渡し、大きな変更は計画を先に合意する──この型を守るだけで、やり直しが大きく減ります。賢い言い回しを探すより、渡す情報の段取りに時間をかけるのが 2026 年の近道です。
次は、より実践的な「Claude Code でモバイルアプリ開発」や「Claude Code のエージェント機能」へ進むと、ここで身につけた頼み方がそのまま活きてきます。
