698960

HOME | DIARY | PROFILE

【フォローする】【ログイン】

hiroblue’s LIFE LOG

< 新しい記事

新着記事一覧(全1677件)

過去の記事 >

2026.09.18

ChatGPTに考えてもらった Codex学習ステップ STEP 2 — Codexへの指示の書き方

カテゴリ： AI　人工知能

STEP 2では、STEP 1で体験した「Codexに頼む」を、 再現性のある仕事の依頼方法に変えていきます。

STEP 2 — Codexへの指示の書き方

学習期間：2日

テーマ：目的・現状・制約・完成条件・確認方法

実習：同じ課題を複数の指示方法で実行する

到達目標：Codexに正確な仕事を依頼できる

2-1. このSTEPのゴール

STEP 1では、

 調査させる
↓
変更させる
↓
diffを見る
↓
実行させる

という基本操作を学びました。

STEP 2では、そのときCodexへ渡す 指示の質を高めます。

最終的には、次の5項目を意識して依頼できれば合格です。

 ┌─────────────────────┐
│ ① 目的              │ 何を実現したい？
│ ② 現状              │ 今どうなっている？
│ ③ 制約              │ 何を守る？
│ ④ 完成条件          │ 何なら完成？
│ ⑤ 確認方法          │ どう検証する？
└─────────────────────┘
↓
Codex

この型は、今後のCodex学習全体で使います。

2-2. 「プロンプトが長いほど良い」わけではない

まず大事なのはこれです。

Codexへの良い指示とは、

長い指示

ではありません。

判断に必要な情報が明確な指示

です。

例えば、

 CSVツールを改善してください。

でもCodexは何かしてくれるでしょう。

しかし「改善」には、

 文字コード対応？
速度改善？
GUI改善？
エラー処理？
コード整理？
ログ追加？

など、多くの解釈があります。

Codexが勝手に判断する部分が大きくなります。

2-3. 曖昧な指示と明確な指示

指示A

 CSVプログラムをいい感じに直してください。

これはかなり曖昧です。

指示B

 csv_utils.pyを改善してください。

CSVファイルが存在しない場合に、
利用者に分かりやすいエラーを表示してください。

それ以外の機能は変更しないでください。

かなり良くなりました。

さらに、

指示C

 【目的】
CSVファイルが存在しない場合でも
プログラムが異常終了しないようにする。

【現状】
csv_utils.py の read_csv() で
CSVファイルを読み込んでいる。

【制約】
・既存の正常系の動作を変えない
・GUIは追加しない
・外部ライブラリを追加しない
・変更は必要最小限とする

【完成条件】
存在しないCSVを指定した場合、
利用者にファイルが存在しないことが分かる。

【確認方法】
正常なsample.csvと
存在しないnot_found.csvの両方で実行し、
結果を報告する。

こうするとCodexが判断しなければならない曖昧な部分がかなり減ります。

2-4. ①「目的」を書く

最初は、

なぜ、この変更をするのか？

です。

例えば、

 【目的】
CSV読み込み時のエラーを
利用者に分かりやすくする。

目的と作業内容は違います。

例えば、

 try-exceptを追加してください。

は手段です。

一方、

 存在しないCSVを指定しても、
利用者が原因を理解できるようにしたい。

は目的です。

この違いは重要です。

人間が実装方法まで決めつけると、Codexがもっと適切な方法を見つけられる余地を消すことがあります。

基本的には、

 人間
↓
目的を伝える

Codex
↓
実装方法を検討

という役割分担を意識します。

2-5. ②「現状」を書く

次は、

今どうなっているか？

です。

例えば、

 【現状】

main.pyから
csv_utils.pyのread_csv()を呼び出しています。

read_csv()ではUTF-8固定で
CSVを読み込んでいます。

ただし、ここには重要な注意があります。

Codexがコードから調査できることを、人間が全部説明する必要はありません。

例えば、

 【現状】

このプロジェクトのCSV読み込み処理を調査してください。
現在の実装を確認したうえで変更してください。

でも構いません。

むしろ大きな既存プロジェクトでは、この方が便利です。

 あなたが知っている現状
+
Codex自身のコード調査
↓
より正確な現状把握

という使い方です。

2-6. ③「制約」を書く

ここはCodex利用で非常に重要です。

制約とは、

何をしてはいけないか／何を守る必要があるか

です。

例えば、

 【制約】

・main.pyの動作は変更しない
・GUIは変更しない
・外部ライブラリを追加しない
・Python 3.12で動作させる
・変更範囲は必要最小限

です。

実際の開発では、

 新機能を追加した
↓
でも既存機能が壊れた

の方が困ります。

そのため、

「何を変えてほしいか」

だけでなく、

「何を変えてほしくないか」

もCodexに伝えます。

2-7. 「変更禁止」は強力

例えばGUI付きPythonプログラムを変更するとします。

 CSV文字コード判定を追加してください。

だけだと、Codexが周辺コードも整理する可能性があります。

そこで、

 【変更禁止】

Tkinterの画面レイアウト、
ボタン配置、
ウィンドウサイズ、
既存メッセージについては変更しないでください。

と書きます。

これは後で扱う AGENTS.mdにもつながる考え方です。

毎回必要な制約はプロンプトに書く。

プロジェクト全体で常に守る制約は、後でAGENTS.mdへ移していきます。

2-8. ④「完成条件」を書く

ここは非常に重要です。

Codexが、

「できました」

と言ったとしても、

何をもって「できた」とするのでしょう？

それを人間側で定義します。

例えば、

 【完成条件】

次のCSVを読み込めること。

・UTF-8
・UTF-8 BOM付き
・CP932

読み込んだデータは
すべて同じ形式で処理できること。

これなら完成かどうか判断できます。

逆に、

 文字コードに強くしてください。

では完成基準がありません。

2-9. 完成条件は「YES / NO」で確認できるようにする

良い完成条件は、

 できた？
↓
YES / NO

で判断できます。

例えば、

 □ UTF-8を読み込める
□ CP932を読み込める
□ ファイル不存在で異常終了しない
□ 既存GUIが変わっていない
□ 外部ライブラリを追加していない

です。

一方、

 □ コードをきれいにする
□ 使いやすくする
□ 高品質にする

は、人によって判断が変わります。

できるだけ 観測可能な条件にします。

2-10. ⑤「確認方法」を書く

完成条件と似ていますが、少し違います。

完成条件：

何なら完成か？

確認方法：

それをどうやって確かめるか？

例えば、

 【完成条件】

CP932のCSVを正常に読み込めること。

【確認方法】

input/test_cp932.csvを使って
main.pyを実行する。

読み込み結果と件数を確認する。

という関係です。

 目的
↓
実装
↓
完成条件
↓
確認方法
↓
結果

ここまで指示できると、Codexに単に「コードを書かせる」のではなく、 仕事を完了させる指示になります。

2-11. 基本テンプレート

今後使う基本形を決めてしまいましょう。

 【目的】


【現状】


【変更内容】


【制約】


【完成条件】


【確認方法】

学習計画では5要素でしたが、実際にはその間に 変更内容を加えた6項目型が使いやすいです。

2-12. 実際に書いてみる

CSVツールなら例えば、

 【目的】

CSVファイルの文字コードの違いによる
読み込みエラーを減らしたい。


【現状】

現在のCSV読み込み処理を調査してください。

UTF-8固定になっている箇所と、
その処理を利用している箇所を確認してください。


【変更内容】

UTF-8とCP932のCSVを
読み込めるようにしてください。


【制約】

・既存の正常系の動作を維持する
・GUIは変更しない
・変更範囲は必要最小限
・不要なリファクタリングは行わない


【完成条件】

UTF-8とCP932のCSVの両方を
正常に読み込めること。


【確認方法】

UTF-8のテストCSVと
CP932のテストCSVを用意して実行してください。

実行したテストと結果を報告してください。

かなり「仕事の依頼書」らしくなってきました。

2-13. ただし、毎回この形式で書く必要はない

ここも重要です。

小さな変更に、

 【目的】
【現状】
【変更内容】
【制約】
【完成条件】
【確認方法】

を毎回全部書いたら面倒です。

例えば、

 main.pyの表示を
「3 rows」から「3件」に変更してください。

それ以外は変更しないでください。
変更後に実行してください。

で十分な場合もあります。

考え方としては、

 小さい仕事
↓
短い指示

大きい仕事
↓
構造化した指示

です。

2-14. 「調査」と「実装」を分ける

既存コードを変更するときには、かなり有効です。

第1段階

 CSV文字コード処理を調査してください。

まだコードは変更しないでください。

関係するファイル、
現在の処理、
問題点、
変更候補を報告してください。

第2段階

Codexの回答を見る。

第3段階

 では、その調査結果をもとに
変更計画を作ってください。

まだ実装しないでください。

第4段階

計画を見る。

第5段階

 その計画で実装してください。

変更後にテストを実行し、
変更内容とテスト結果を報告してください。

つまり、

 Explore
↓
Plan
↓
Implement
↓
Test
↓
Review

です。

大きな変更ほど、この方法を使います。

2-15. 「まだ変更しないでください」が重要な理由

Codexは仕事を進めるAgentなので、

問題を見つけた → 直す

まで進めることがあります。

しかし、人間としては、

まず原因だけ知りたい

場合があります。

そのため、

 まず調査だけしてください。
まだファイルを変更しないでください。

という指示は非常に便利です。

これは今後何度も使います。

2-16. Codexに質問させる

仕様が曖昧なとき、人間が全部予測する必要はありません。

例えば、

 実装に必要な情報が不足している場合は、
推測して実装せず、
先に質問してください。

と書けます。

すると、

 不明点
↓
Codexが質問
↓
人間が回答
↓
実装

という流れを作れます。

特に業務プログラムでは有効です。

2-17. 「推測しない」という制約

例えば、

 会社名が存在しない場合は
適当に補完してください。

では困る場合があります。

その場合、

 データ仕様が不明な場合は推測しないでください。

不明点を列挙し、
実装前に確認してください。

とします。

Codexの賢さを活用することと、 勝手な仮定を許すことは別です。

2-18. 変更範囲を指定する

例えば、

 変更対象：
csv_utils.py

必要な場合のみ：
main.py

変更禁止：
GUI関連ファイル

のように書けます。

これは既存プロジェクトが大きくなるほど有効です。

 project/
├─ main.py          ← 必要なら変更
├─ csv_utils.py     ← 変更OK
├─ gui.py           ← 変更禁止
├─ config.py
└─ ...

Codexに 作業範囲の境界を与えるわけです。

2-19. 出力形式も指定できる

Codexからの報告方法も指定できます。

例えば、

 作業完了後、次の形式で報告してください。

1. 原因
2. 変更したファイル
3. 変更内容
4. 実行したコマンド
5. テスト結果
6. 残っている問題

これだけでも、結果がかなり確認しやすくなります。

2-20. 1日目の実習 — 同じ仕事を3種類の指示で試す

今回のSTEPで一番大事な実習です。

同じ課題をCodexに3回頼みます。

課題は、

CSVファイル不存在時の処理を改善する

とします。

実験A：曖昧な指示

 CSV処理を改善してください。

結果を記録します。

実験B：少し具体的

 CSVファイルが存在しない場合の
エラー処理を追加してください。

既存機能は変更しないでください。

結果を記録します。

実験C：構造化

 【目的】
CSVファイル不存在時の
エラーを分かりやすくする。

【現状】
現在のCSV読み込み処理を
最初に調査してください。

【変更内容】
存在しないCSVが指定された場合の
処理を追加する。

【制約】
既存の正常系を変更しない。
外部ライブラリを追加しない。
必要最小限の変更とする。

【完成条件】
存在しないCSVを指定しても、
原因が分かること。

【確認方法】
正常なCSVと存在しないCSVの
両方で実行する。

変更内容と実行結果を報告する。

結果を比較します。

2-21. 3つの結果を比較する

次の観点で比較します。

観点	A	B	C
意図通りの変更か	?	?	?
不要な変更があったか	?	?	?
Codexの判断が分かりやすいか	?	?	?
完成を確認できるか	?	?	?
テストされたか	?	?	?

ここで、

プロンプトの違いによってCodexの行動がどう変わるか

を体験するのが目的です。

2-22. 2日目 — 実際の仕様変更

2日目は少し複雑にします。

課題：

UTF-8とCP932のCSVを読み込めるようにする

まずCodexへ、

 この要件を実装する前に、
現在のCSV読み込み処理を調査してください。

まだ変更しないでください。

関係するファイルと、
現在の文字コード処理を説明してください。

と依頼します。

次に、

 UTF-8とCP932のCSVに対応する場合の
実装方法を考えてください。

まだ変更しないでください。

複数の方法がある場合は、
それぞれのメリット・デメリットを説明してください。

とします。

そして人間が方法を選びます。

最後に、

 では、その方法で実装してください。

【制約】
・既存の正常系を維持
・GUI変更禁止
・不要な外部ライブラリを追加しない
・変更は必要最小限

【完成条件】
UTF-8とCP932のCSVを読み込める。

【確認方法】
両方の文字コードのテストCSVで実行し、
結果を報告してください。

と実装させます。

2-23. ここで人間の役割が変わる

従来なら、

 人間
↓
どう実装する？
↓
コードを書く
↓
デバッグ

でした。

Codexでは、

 人間
↓
何を実現する？
↓
何を守る？
↓
何なら完成？
↓
Codex
↓
どう実装する？
↓
コード変更
↓
検証
↓
人間
↓
結果を判断

になります。

つまりCodexを使うほど、人間には、

「コードを書く能力」だけでなく、「仕様を明確にする能力」

が重要になります。

2-24. 指示を書くときのチェックリスト

Codexへ送信する前に、5秒だけ確認します。

 □ 何を実現したいか明確？

□ Codexは現状を把握できる？

□ 変更してはいけないものは明確？

□ 何をもって完成とする？

□ どう確認する？

□ 不明な仕様を勝手に推測させていない？

□ 変更範囲が大きすぎない？

全部書く必要はありません。

必要なものだけ入れるのがポイントです。

2-25. Codex指示テンプレート

今後使える基本形です。

 【目的】
何を実現したいのか


【現状】
現在どうなっているのか
必要ならCodex自身に調査させる


【変更内容】
今回何を変更するのか


【制約】
変更禁止事項
使用環境
互換性
変更範囲など


【完成条件】
何ができれば完成なのか


【確認方法】
どのようにテストするのか


【作業手順】
必要なら、

1. 調査
2. 計画
3. 実装
4. テスト
5. 結果報告

の順に実施する。

ただし、これは 万能呪文ではありません。

重要なのはテンプレートそのものではなく、

Codexが仕事を完了するために必要な情報は何か？

を考えることです。

2-26. STEP 2で覚える用語

用語	意味
Goal / 目的	最終的に実現したいこと
Context / 現状	判断材料となる現在の状態
Constraint / 制約	守るべき条件
Scope / 範囲	今回扱う対象
Acceptance Criteria / 完成条件	完成と判断する基準
Verification / 確認	完成条件を検証する方法
Explore	現状を調査する
Plan	実装方法を計画する
Implement	実装する
Review	変更結果を確認する

このあたりは今後頻繁に出てきます。

2-27. STEP 2確認問題

Q1.「CSVツールを改善して」が良くないのはなぜでしょう？

Q2.「目的」と「実装方法」は何が違いますか？

Q3.なぜ「変更してほしいこと」だけでなく「変更してはいけないこと」も伝えるのでしょう？

Q4.完成条件と確認方法の違いは何でしょう？

Q5.「まず調査してください。まだ変更しないでください」は、どんな場面で有効でしょう？

Q6.仕様が不足している場合、Codexにどう指示すれば勝手な推測を減らせるでしょう？

2-28. STEP 2 合格実習

最後に、次の要求だけを見て、自分でCodexへの指示を書いてみます。

CSV変換ツールをUTF-8、CP932に対応させたい。現在動いている機能は壊したくない。

自分で、

 【目的】

【現状】

【変更内容】

【制約】

【完成条件】

【確認方法】

を埋めてCodexへ渡します。

さらに、

 調査
↓
計画
↓
人間が確認
↓
実装
↓
テスト
↓
diff確認

まで自分で進められれば、 STEP 2合格です。

ここまででSTEP 0～2が一本につながります。

 STEP 0
Codexとは何か
↓
Agentを理解

STEP 1
VS Code + Codex
↓
Read / Write / Executeを体験

STEP 2
指示の書き方
↓
Codexの仕事をコントロール

そして次の STEP 3「既存コード解析」から、Codexの強みがかなり見えてきます。単一の main.py を質問する段階から進んで、複数ファイルからなる既存プロジェクトをCodexに調査させ、「どこから実行され、どのモジュールが何を担当し、データがどう流れているのか」を把握する方法を学習します。