MENU
3DCG・ゲーム開発の知見をゆるく深く
  1. ホーム
  2. AIエージェント解説
  3. Codex
  4. Codexの使い方｜最初に試すプロンプトと安全な進め方

Codexの使い方｜最初に試すプロンプトと安全な進め方

Codex
Codexの使い方｜最初に試すプロンプトと安全な進め方

Codex の導入が終わったら、次は実際にタスクを頼んでみます。ただし、最初から大きな機能追加や本番コードの修正を任せる必要はありません。むしろ初回は、変更しない調査タスクから始め、作業ログや差分の見方に慣れることが大切です。

本記事では、Codex に最初に試すプロンプト、作業前チェック、ログの見方、差分確認、採用・修正依頼・却下の判断までを、初心者向けに順番に整理します。

夕宮たいだ

ふぁ……みんな〜、今日は Codex に最初のお願いをしてみるよぉ。いきなり大改造じゃなくて、小さく安全に試していこ〜。

目次

1. 最初のタスクは何を選ぶべきか

ひとことで：最初は「壊しにくく、確認しやすく、戻しやすい」タスクを選びます。

Codex はコードを読み、必要に応じて編集し、コマンドやテストを実行できるAIエージェントです。便利な一方で、最初から大きな変更を任せると、どこを確認すればよいか分からなくなります。

初回に向いているタスクは、次のようなものです。

タスク変更の有無初心者向け度理由
プロジェクト構造の説明なし高いファイル変更なしでCodexの読み方を見られる
READMEの確認小さい高い変更範囲が狭く、差分を読みやすい
コメントや文言の改善小さい高い実装ロジックを壊しにくい
エラー原因の調査なし〜小さい中くらいまず調査だけ依頼すれば安全
テスト追加あり中くらい既存テストの型に合わせれば確認しやすい
Codexの初回タスクに向く作業と避けたい作業の比較図
図1：最初は壊しにくく確認しやすいタスクを選ぶ

逆に、初回から避けたいのは、認証、課金、本番DB、デプロイ設定、広範囲リファクタのようなタスクです。失敗時の影響が大きく、初心者が差分を判断しにくいためです。

夕宮たいだ

最初は「読むだけ」でいいんだよぉ。Codex がどう調べるのかを見るだけでも、かなり勉強になるんだぁ。

2. 作業前チェックをする

ひとことで：作業前にGit状態、対象フォルダ、秘密情報の3点を確認します。

Codex に依頼する前に、必ず作業前チェックを行います。ここを省くと、後から「どこがAIの変更か分からない」「戻したいのに戻せない」という状態になりやすいです。

最低限のチェックは次の3つです。

  1. 作業対象のフォルダが正しいか確認する
  2. git status で未保存の変更を確認する
  3. APIキー、SSH鍵、.env、個人情報をプロンプトに貼らない

既に未コミットの変更がある場合は、Codex に作業を頼む前に内容を把握してください。自分の変更とCodexの変更が混ざると、レビューが難しくなります。

git status

Git管理されていない練習フォルダで試す場合は、作業前にフォルダごとコピーしておくのも有効です。慣れてきたら、Gitで差分確認する運用に寄せていきます。

夕宮たいだ

ぁぅ……自分の変更とCodexの変更が混ざると、あとで見分けるのが大変なんだぁ。作業前の状態、ちゃんと見ておこうねぇ。

3. 最初のプロンプトの型

ひとことで：目的、対象、制約、完了条件を短く入れると安定します。

OpenAI公式の Best practices では、Codex に渡す情報として Goal、Context、Constraints、Done when を含める考え方が紹介されています。この記事では初心者向けに、次の4項目として覚えます。

項目書くこと例
目的何をしてほしいかプロジェクト構成を説明してほしい
対象どこを見てほしいかこのリポジトリ全体、または src/
制約やってほしくないことまだファイルは変更しない
完了条件どうなれば完了か重要フォルダ3つと最初に読むファイルを出す

最初のうちは、長いプロンプトを書く必要はありません。大切なのは「何をしてほしいか」と「何をしてほしくないか」を明確にすることです。

基本テンプレートは次のとおりです。

目的:
（何をしたいか）

対象:
（見てほしいファイルやフォルダ）

制約:
（変更しない、最小限にする、先に方針を出す、など）

完了条件:
（最後に何を報告してほしいか）
Codexへの最初のプロンプトを目的、対象、制約、完了条件に分ける図
図2：最初のプロンプトは4要素で組み立てる

この型は、CX-04「Codexプロンプト設計」で詳しく扱います。本記事では、初回実践に必要な範囲だけ使います。

4. タスク1：プロジェクト構造を説明してもらう

ひとことで：まずはファイルを変更しない調査タスクで、Codexの読み方を確認します。

最初におすすめなのは、プロジェクト構造の説明です。変更を伴わないため安全で、Codex がどこを見て、どのように理解するかを観察できます。

依頼文は次のようにします。

このプロジェクトの構成を初心者向けに説明してください。

対象:
このリポジトリ全体

制約:
まだファイルは変更しないでください。
推測で断定せず、読んだファイル名を示してください。

完了条件:
1. プロジェクトの目的
2. 重要なフォルダ3つ
3. 最初に読むべきファイル3つ
4. 初心者が注意すべき点
を箇条書きでまとめてください。

Codex の回答を読んだら、実際のフォルダと照らし合わせます。説明に出てきたファイルを自分でも開き、内容が合っているか確認してください。

ここで大切なのは、Codex の説明をそのまま信じ切らないことです。説明が正しそうか、どのファイルを根拠にしているか、自分の目でも見ます。

夕宮たいだ

ていねいに見ていこうねぇ。Codex が読んだファイル名を出してくれると、確認しやすいんだぁ。

5. タスク2：READMEを最小限だけ更新する

ひとことで：初めての編集は、READMEのような低リスクなファイルから始めます。

構造説明に慣れたら、次は小さな編集タスクに進みます。おすすめは README の更新です。README は差分が読みやすく、実装ロジックを壊す可能性が低いため、初回編集に向いています。

依頼文は次のようにします。

READMEの内容が現在のプロジェクト構成と合っているか確認してください。

対象:
README.md と、セットアップに関係する設定ファイル

制約:
変更は最小限にしてください。
大きく書き換える前に、まず変更方針を提示してください。
実装コードは変更しないでください。

完了条件:
1. 古い説明があるか
2. 変更する場合の方針
3. 実際に変更した箇所
4. 確認したファイル
をまとめてください。

この依頼では、「まず変更方針を提示してください」と入れている点が重要です。いきなり編集させるのではなく、どこを直す予定かを先に確認します。

方針に問題がなければ、続けて次のように依頼します。

その方針でREADMEだけ更新してください。
変更後、差分の要点を3行以内で説明してください。

作業後は必ず差分を確認します。README の差分であっても、不要な説明が増えていないか、事実と違う内容が入っていないかを見ます。

6. タスク3：小さなバグを調査する

ひとことで：バグ修正は、まず再現手順と原因候補の整理から始めます。

バグ修正を頼む場合、いきなり「直して」だけでは情報が足りません。公式の Workflows でも、再現手順、制約、検証方法を渡す重要性が示されています。

初心者向けには、次の型がおすすめです。

次の不具合の原因を調べてください。

不具合:
（何が起きているか）

再現手順:
1. （手順1）
2. （手順2）
3. （期待結果）
4. （実際の結果）

制約:
まず原因候補を2〜3個に絞って説明してください。
いきなり修正せず、変更方針を出してください。

完了条件:
原因候補、確認したファイル、推奨する修正方針、検証方法をまとめてください。

原因候補に納得できたら、次の段階で修正を依頼します。

提案された方針で、最小限の修正をしてください。
修正後、関連するテストまたは確認手順を実行し、結果を報告してください。

ここでも大切なのは、調査と修正を分けることです。バグ修正は影響範囲が広がりやすいため、まず原因候補を確認し、納得してから変更に進みます。

7. 作業ログと差分を見る

ひとことで：Codexが何を読んだか、何を変更したか、どの確認をしたかを見ます。

Codexの作業ログと差分で確認する4つのポイント
図3：作業ログと差分を見てから採用を判断する

Codex の作業中は、ログや進行状況を確認します。見るべきポイントは次の3つです。

  • 読んだファイル：依頼に関係するファイルを見ているか
  • 実行したコマンド：テスト、ビルド、検索などが妥当か
  • 変更したファイル：想定外のファイルに触っていないか

特に差分確認は重要です。差分を見るときは、次の順番で確認します。

  1. 変更ファイル数が多すぎないか
  2. 依頼していないファイルが変更されていないか
  3. 変更理由が説明されているか
  4. テストや確認手順が実行されているか
  5. 自分が読んで理解できる変更か

「なんとなく良さそう」で採用しないでください。読めない差分、説明できない差分、意図していない差分は、採用前に止めます。

夕宮たいだ

差分を読まずに採用するのは、ほんとダメだよ。Codex が便利でも、最後に見るのは人間のお仕事なんだぁ。

8. 採用・修正依頼・却下の判断

ひとことで：結果は必ず「採用」「修正依頼」「却下」の3択で判断します。

Codex の結果を見たら、次の3つのどれかに分けます。

判断状態次の行動
採用変更が小さく、意図どおりで、確認も通っているそのまま残す。必要ならコミットする
修正依頼方向性は良いが、表現や範囲に調整が必要追加指示を出して直してもらう
却下目的と違う、変更が大きすぎる、理解できない採用せず戻す

修正依頼を出すときは、曖昧に「いい感じに直して」ではなく、具体的に伝えます。

READMEの変更方針は良いですが、説明が長すぎます。
セットアップ手順の変更だけ残し、背景説明の追加は削ってください。
変更対象はREADME.mdだけにしてください。

却下する場合も、理由を明確にします。

今回の変更は対象ファイルが多すぎるため採用しません。
いったん変更前に戻し、README.mdだけを対象にした最小変更案を出してください。

この判断を習慣化すると、Codex を「勝手に進むもの」ではなく、「レビューしながら一緒に進めるもの」として扱えるようになります。

9. 次に読む記事

ひとことで：次は、依頼文の品質を安定させるプロンプト設計へ進みます。

本記事では、Codex の最初の使い方を、調査、README更新、バグ調査の3パターンで整理しました。

次に読む記事は、CX-04「Codexプロンプト設計｜Goal・Context・Done whenの書き方」です。この記事では、今回使った「目的、対象、制約、完了条件」をさらに深掘りし、失敗しにくい依頼文の作り方を整理します。

安全面を先に固めたい方は、CX-05「Codexの権限と安全設定」へ進んでも構いません。承認、サンドボックス、Git管理、秘密情報の扱いを理解すると、Codexに任せられる範囲を判断しやすくなります。

公式情報としては、Codex Prompting、Codex Best practices、Codex Workflows を確認しておくと、今回の流れをさらに実務寄りに理解できます。

夕宮たいだ

ふぁ……最初の一歩はこれでOKだよぉ。小さく頼んで、差分を見て、納得してから採用していこ〜。

この記事とあわせて読みたいCodex記事

ひとことで：この記事の理解を深めるための関連回です。

Codexシリーズ記事一覧

ひとことで：Codex編は、導入から専門機能まで順番に読めるシリーズです。

Codex
AIエージェントワークフロー CLI型エージェント 初心者向け 導入・設定
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！

この記事を書いた人

怠惰のアバター 怠惰

関連記事

目次