2ターン設計で精度を上げる：VSCode×Codexのやりとり術

はじめに

「VSCodeからCodexにお願いしたけど、意図とズレた」――そんな経験はありませんか。私自身、短く書くと精度が落ち、長く書くと伝える内容が散らばることがありました。

そこで効果があったのが2ターン設計です。1回目で前提を確認し、2回目で実行に移す。たったそれだけで、精度と納得感が上がりました。この記事では、VSCode×Codexで使える「2ターンの型」を整理します。

1. なぜ1回でうまくいかないのか

LLMは文脈が不足していると、良い推測はしても本当に欲しい答えに辿り着けないことがあります。公式のプロンプト指針でも「目的・制約・期待する出力」を明確に伝えることが推奨されています¹²。

つまり、1回目の指示で「必要な前提が足りているか」を確かめるだけで、2回目の成功率が大きく上がります。

2. 2ターン設計の全体像

2ターン設計は、**確認（Turn 1）→実行（Turn 2）**の流れです。会話の段階を明確にするだけで、やりとりが安定します。

flowchart LR
  A[Turn 1: 調査・前提確認] --> B[Turn 2: 実装・反映]

Turn 1: 調査・前提確認

このターンでは、**「何を、どこまで、どういう形で」**を固めます。足りない情報があれば質問してもらい、必要な前提を揃えるのが目的です。質問してから進めるスタイルは公式例でも推奨されています³。

Turn 2: 実装・反映

Turn 1で前提が揃ったら、実装・修正・整理などを依頼します。ここでは作業のゴールと受け入れ条件が明確になっていることが大事です。

3. Turn 1のテンプレ（そのまま使える）

短くてもよいので、次の項目を伝えると迷いが減ります。

• 目的
• 変更範囲
• 期待する出力
• 制約（触らない場所、守るルール）
• 参照してほしいファイル

実際のテンプレはこんな感じです。

1
2
3
4
5
6
7

目的: 画面の表示崩れを直したい
変更範囲: @src/pages/order-detail/ だけ
期待出力: レイアウトが崩れずに表示されること
制約: UIの文言は変更しない
参照: @src/pages/order-detail/index.tsx

まず原因を調査して、必要なら質問してください。

ポイントは「まず調査して」と先にフェーズを指定することです。これだけで、いきなり修正を始めるリスクが減ります。

4. Turn 2のテンプレ（承認してから実行）

Turn 2では「OK、やってください」を明示します。明確な実行依頼が推奨されることは公式のベストプラクティスでも触れられています¹²。

1
2
3
4
5

ありがとうございます。修正案で進めてください。

- 変更は最小限で
- テストは不要
- 差分を最後にまとめてください

この形式だと、実装範囲が安定し、仕上がりの確認も楽になります。

5. VSCode×Codexの具体例（実践編）

5.1 実践例で理解する

例A: ドキュメント反映 → 追加情報 → 再調査

1
2
3
4
5

Turn 1:
[仕様ドキュメント] に関連情報として残したいので、
[オブジェクトA/B/C/D] を「新規作成している箇所」を
ソースから洗い出して一覧にしてください。
不足があれば質問してください。

1
2
3
4
5

Turn 2:
追加情報です。
事業者ユーザーはコミュニティ系で作成されます。
[取引先/取引先責任者] 経由の作成があるはずなので、
その前提で再調査してください。

ポイント: Turn 1で一覧化、Turn 2で前提を更新して再調査。

例B: 仕様フロー照合 → 追加条件 → 再調査

1
2
3

Turn 1:
[仕様フロー図] に対して、実装済みの画面/処理と
未実装の箇所を一覧化してください。

1
2
3
4
5
6

Turn 2:
追加条件です。
一部の紐づけ処理は既存実装で対応済みです。
移行データの制約があるので、
「取得条件」を [ユーティリティX] で変更する前提で
再調査してください。

ポイント: 仕様照合→追加条件→再調査の流れを固定化。

5.2 まず使うテンプレ

1
2
3
4
5
6
7
8

Turn 1:
目的:
変更範囲:
期待出力:
制約:
参照:

まず調査して、足りない情報があれば質問してください。

1
2
3
4

Turn 2:
追加情報:
承認: 方針OK、最小変更で進めてください
注意点:

5.3 追加で効くひとこと

• 「不足があれば質問してください」
• 「最小変更でお願いします」
• 「未実装は未実装と明示してください」
• 「影響範囲が広い場合は先に相談してください」

6. よくある失敗と回避策

6.1 「短すぎる」問題

「直して」「いい感じに」だけだと、前提が曖昧になりがちです。公式ガイドでも指示は明確にとされています¹²。

6.2 「長すぎる」問題

情報が多すぎると要点が埋もれます。Turn 1は要点だけにして、必要な詳細は質問で補う方が安定します³。

6.3 「前提が途中で変わる」問題

途中で条件が変わるのはよくあります。そのときはTurn 1に戻って前提の更新を伝えると混乱が減ります。

まとめ

• 2ターン設計は「確認→実行」の流れを作るだけ
• Turn 1は前提を揃えるフェーズ
• Turn 2は承認して実行するフェーズ
• VSCode×Codexでもテンプレ化すると安定する

まずは次の1タスクで、Turn 1だけ丁寧に書いてみてください。驚くほど結果が変わります。

参考文献