Codexのおすすめプロンプト【用途別に厳選&指示出しのコツ】

Codexを使い始めたものの、思ったような出力が得られず試行錯誤している人は多いですよね。

Codexの出力品質は、プロンプトの書き方ひとつで大きく変わります。「プロンプトは重要」そんな情報を見聞きはするものの、実際にどう指示を出せばいいのかわからない人もいるはず。

そこでこの記事ではOK・NG例も交え、用途別にCodexのおすすめプロンプトを解説します。プロンプトの活用法も紹介するので、ぜひ参考にしてください。

Codexの特徴を詳しく知りたい人は、次の記事を参考にしてください。

プロンプトはCodex出力品質を左右する

Codexを使いこなすうえで、プロンプトの書き方が出力品質の8割を決めるといっても過言ではありません。同じ作業を依頼しても、指示の出し方次第で結果は異なります。

たとえば「ログイン機能を作って」とだけ入力した場合、Codexは認証方式もバリデーションルールもわからないまま、汎用的なコードを返すだけです。一方「メールアドレスとパスワードでJWT認証するログインAPIをNode.jsで作って。パスワードは8文字以上必須」と指示すれば、要件に沿った具体的なコードが得られます。

この差を生む原因は、Codexが「書かれていないことは判断できない」仕組みだからです。人間なら文脈を察してくれますが、Codexは指示文だけを頼りにコードを生成します。

つまり「何を・どう・どこまで」やるかを明示するほど、手戻りの少ない高品質な出力が可能です。

ここからは、用途別のプロンプト例と書き方のコツを順番に見ていきましょう。

【用途別】Codexのおすすめプロンプト

ここからは実務でそのまま使えるCodexのプロンプトを、5つの用途別にまとめて解説します。

業務効率化

日常の定型業務を自動化したいときに使えるプロンプト例は、以下のとおりです。

“`
@data/sales_2025.csv を読み込み、以下の処理を行うPythonスクリプトを作成してください。
「売上日」列をYYYY-MM-DD形式に統一
「金額」列の空欄を0で埋める
部署ごとの月別売上合計を集計し、結果をoutput/summary.csvに出力
処理件数をターミナルに表示
“`

ポイントは、入力ファイルと出力先を具体的に指定している点です。「CSVを整形して」だけでは、どのファイルをどう処理するか伝わりません。

ほかにも、メール文面の自動生成やSlack通知スクリプトの作成など、定型業務の自動化全般に応用できます。まずは毎日30分以上かけている作業から試してください。

アプリ開発

アプリ開発では、機能単位で指示を出すのが効果的です。1つのプロンプトで1機能に絞ると、Codexが正確に意図をくみ取れます。

たとえば、タスク管理アプリのCRUD機能を作りたい場合は次のように指示します。

“`
@src/api/tasks.ts にタスク管理のREST APIを作成してください。
フレームワーク：Express + TypeScript
エンドポイント：GET /tasks, POST /tasks, PUT /tasks/:id, DELETE /tasks/:id
バリデーション：titleは必須・100文字以内、statusは”todo”,”doing”,”done”のいずれか
エラーレスポンス：400（バリデーションエラー）、404（タスク未存在）
テスト：@tests/tasks.test.ts にJestのユニットテストも作成
“`

「アプリを作って」のような丸投げ指示ではなく、使用技術・エンドポイント・バリデーションルールを明記するのがポイントです。ゲーム開発やUnityプロジェクトでも同じ考え方が有効です。機能を細かく分解し、1回のプロンプトで1つの機能に集中させましょう。

個別に指示を出すことで、出力結果のズレを減らせます。

Codexでアプリ開発方法を詳しく知りたい人は、次の記事を参考にしてください。

Webサイト/LP制作

デザイン要件と構成をセットで指示すると、実用的なコードが一度で得られます。

LP制作の場合、次のようなプロンプトが効果的です。

“`
以下の要件でLPのHTMLとCSSを作成してください。
構成：ヒーロー → 特徴3カラム → 料金表 → FAQ → CTA → フッター
デザイン：メインカラー#2563EB、フォントNoto Sans JP、余白は8pxの倍数
レスポンシブ：SP幅375px / PC幅1280pxに対応
CTA：「無料で始める」ボタン、色はメインカラーの補色
画像：プレースホルダーで配置（altテキストは日本語で記載）
出力先：@public/lp/index.html と @public/lp/style.css
“`

色コードやブレークポイントまで指定すると、修正回数が減ります。「おしゃれなLPを作って」では、Codexはデザインの方向性を判断できません。コーポレートサイトやポートフォリオサイトでも、構成・配色・レイアウトの3点を明示する書き方を意識してください。

Webサイトのカラーやデザインは、発信するサービスや企業内容などの印象に関わります。自分が表現したい内容に合わせて、プロンプトで指示を出しましょう。

資料/レポート作成

Codexは、コードだけでなく文書生成やレポート作成にも活用できます。データ分析の結果をMarkdownレポートとして出力させると、報告業務の効率が上がります。

たとえば、月次の売上レポートを自動生成したい場合は次のように書きます。

“`
@data/sales_june.csv を読み込み、以下の内容でMarkdownレポートを作成してください。
タイトル：2025年6月 月次売上レポート
構成：概要 → 部署別売上（表形式） → 前月比較（増減率付き） → 所見
グラフ：部署別売上の棒グラフをmatplotlibで生成し、画像としてreport/images/に保存
所見：売上が前月比10%以上変動した部署について原因仮説を1行ずつ記載
出力先：@report/june_report.md
“`

「レポートを作って」だけでは、何のデータをどんな形式でまとめるか不明です。構成・出力形式・分析の切り口を具体的に示しましょう。社内プレゼン資料のアウトライン作成や議事録の整形にも、同じパターンで応用できます。

また、資料・レポート作成を頻繁に行う場合、資料のひな形をCodexに作成してもらうのもおすすめです。あらかじめひな形を作成しておけば、以降に少ない指示で作業を指示できます。

情報収集/要約

リポジトリ内のコードや大量のドキュメントを素早く把握したいときにも、Codexは役立ちます。対象ファイルを指定して要約を依頼すると、読解時間を短縮可能です。

たとえば、既存プロジェクトの全体像を把握したい場合は次のように指示します。

“`
このリポジトリの構成を調査し、以下の形式でMarkdownにまとめてください。
ディレクトリ構成ツリー（深さ3階層まで）
主要ファイルごとの役割を1行で説明
使用している外部ライブラリの一覧（名称・用途・バージョン）
API エンドポイントの一覧（メソッド・パス・概要）
出力先：@docs/project_overview.md
“`

あらかじめ情報をまとめることで、新しいプロジェクトへ参加した際の立ち上がり時間を短縮できます。技術記事やREADMEの要約にも使えるため、情報のインプット効率を高めたい場面で試してください。

誤解/失敗しやすいCodexプロンプトのNG例

プロンプトの書き方を間違えると、Codexは期待どおりに動きません。初心者がやりがちなNG例を知っておくと、無駄な試行錯誤を避けられます。

ここからは、よくある失敗パターンを3つ紹介します。

曖昧な丸投げ指示

1つ目は「曖昧な丸投げ指示」です。

以下のような曖昧なプロンプトを入力すると、出力時に意図を反映できません。

“`
いい感じのWebアプリを作って。
“`

何の機能を持つアプリなのか、使用言語は何か、UIの要件はあるかなどすべて不明なまま生成が始まります。結果として、的外れなコードが返ってくるケースがほとんどです。

新しいデザインアイデアを得たい場合や、Codexの使い勝手を知るためにお試しで利用するなら曖昧なプロンプトでも問題ありません。ただし、作業効率をアップさせたいなら、具体的かつわかりやすい指示を出しましょう。

1回のプロンプトに複数の作業を詰め込む

2つ目は「1回のプロンプトに複数の作業を詰め込む」パターンです。

“`
ログイン機能とダッシュボードとCSVエクスポートと通知機能を全部作って。テストも書いて。
“`

指示が多すぎると、Codexは優先順位を判断できません。各機能の関連性も曖昧になり、コードの整合性が崩れます。加えて出力結果に満足できず修正を指示する際、複数作業にまたがると指示が複雑になりがちです。結果的に修正がうまくいかず、かえって手間がかかる可能性もあります。

出力精度と作業効率を両立するためにも、1プロンプト1機能までにしましょう。

否定形だけの指示

3つ目は「否定形だけの指示」です。

「何をしないか」だけでは、「何をすべきか」が伝わりません。「レスポンスは200ms以内に返す」「入力値のバリデーションを追加する」など、肯定形で具体的な要件を書いてください。

“`
遅くならないようにして。エラーが出ないようにして。
“`

3つのNG例に共通するのは「Codexが判断材料を持てない」点です。迷ったときは「自分がこの指示だけ読んで作業できるか」を基準にチェックしましょう。

Codexの出力品質を高めるプロンプトの書き方

ここからはCodexの出力品質を高めるプロンプトの書き方を、7つにまとめて解説します。

目的や意図を明確に伝える

プロンプトの冒頭で「なぜこの作業が必要なのか」を書くと、Codexの出力精度が上がります。目的を書くことで、Codexが最適な実装方法を選択しやすいです。

たとえば「CSVを読み込む関数を作って」だけでは、Codexは用途を推測できません。「経理部が月末に使う売上集計レポートを自動生成するため、CSVを読み込む関数を作って」と書けば、エラーハンドリングや出力形式の判断材料が増えます。

目的が書かれたプロンプトと書かれていないプロンプトでは、手戻りの回数に2〜3倍の差が出ることも珍しくありません。冒頭の1行に「〜のために」を入れる習慣をつけましょう。

対象ファイルを@で指定する

Codexには、対象ファイルを`@`記号で直接指定する機能があります。`@`で指定すると、Codexが正確にファイルの中身を読み取って作業に反映してくれます。

ファイルを指定する書き方は、次のとおりです。

“`
@src/utils/auth.ts の認証ロジックを修正してください。
“`

`@`を使わずに「authファイルを修正して」と書くと、Codexがどのファイルを指しているか迷う場合があります。リポジトリ内に似た名前のファイルが複数あると、誤ったファイルを編集するリスクも生じます。

複数ファイルを対象にする場合は、`@src/api/tasks.ts` と `@src/models/task.ts` のように、それぞれ明示してください。

制約・守るべきルールを書く

プロンプトに制約条件を加えると、意図しないコードの生成を防げます。コーディング規約や使用禁止のライブラリを明記すると、後から修正する手間が減ります。

Codexでの制約やルールは、次のような書き方が効果的です。

“`
制約：
変数名はキャメルケース
any型の使用禁止
console.logはデバッグ用にのみ使用し、本番コードには残さない
外部ライブラリの追加は不可（既存のpackage.json内のみ使用）
“`

制約を書かないと、Codexはプロジェクトの規約を知らないまま自由にコードを生成します。チームのコーディングルールと合わないコードが出力され、レビューで大量の指摘を受ける結果になりがちです。

ルールが3つ以上ある場合は箇条書きで整理すると、Codexが見落としにくくなります。

完了条件を明示する

「何をもって完了とするか」を書くと、Codexが過不足のない出力を返してくれます。完了条件があると、不要なコードの追加や必要な処理の漏れを防げます。

たとえば、次のように書きます。

“`
完了条件：
すべてのエンドポイントが正常に動作すること
Jestテストが全件パスすること
TypeScriptのコンパイルエラーが0件であること
READMEにAPIの使い方を記載すること
“`

完了条件がないと、Codexはどこまで作業すべきか判断できません。テストの作成を省いたり、逆に依頼していないリファクタリングまで行ったりする場合があります。

「ここまでやれば終わり」というゴールを明確にしておくと、出力のブレが小さくなります。

指示を分割する

複雑な作業は、小さなステップに分割してから依頼しましょう。1プロンプト1タスクを守ると、各ステップの出力精度が上がります。

悪い例と良い例を比較します。

悪い例：

“`
ECサイトのバックエンド全部を作って。
“`

良い例（ステップ分割）：

“`
ステップ1：@src/models/product.ts に商品データのスキーマを定義してください。
ステップ2：@src/api/products.ts に商品一覧取得APIを作成してください。
ステップ3：@src/api/cart.ts にカート機能のAPIを作成してください。
“`

分割して指示すると、各ステップの出力を確認してから次に進めます。途中でミスがあっても、該当ステップだけを修正すれば済むため楽です。

目安として、1つのプロンプトで扱うファイルは2〜3個以内にとどめてください。

検証手順まで指示する

コード生成だけでなく、動作確認の方法までプロンプトに含めると安心です。テストコマンドや検証手順を指示すると、Codex自身が出力を検証してから返します。

テストコマンドや検証手順は、次のように書くと効果的です。

“`
検証手順：
1.npm run test で全テストがパスすること
2.npm run lint でエラーが0件であること
3.curl http://localhost:3000/api/tasks でレスポンスが返ること
“`

検証手順を書かないと、生成されたコードが動くか自分で一から確認する必要があります。Codexに検証まで任せることで、確認作業の時間を減らせます。

とくにCI/CDパイプラインに組み込むスクリプトを生成する場合は、検証手順の指示が不可欠です。

AGENTS.mdにルールを移す

毎回のプロンプトに同じルールを書く手間を省くには、AGENTS.mdファイルの活用が有効です。AGENTS.mdにプロジェクト共通のルールを記載しておくと、プロンプトごとに制約を繰り返し書く必要がなくなります。

AGENTS.mdとは、Codexがタスク実行時に自動で読み込む設定ファイルです。リポジトリのルートに配置すると、すべてのプロンプトに対して記載内容が適用されます。

記載例は、次のとおりです。

“`
# AGENTS.md

コーディング規約
言語：TypeScript（strict mode）
変数名：キャメルケース
any型の使用禁止
関数には必ずJSDocコメントを付ける

テスト
テストフレームワーク：Jest
カバレッジ80%以上を維持

禁止事項
console.logを本番コードに残さない
外部ライブラリの無断追加禁止
“`

AGENTS.mdを用意すると、プロンプトは「何をやるか」だけに集中できます。チーム全員が同じルールで作業できるため、出力品質のばらつきも抑えられます。

プロジェクトのルールが増えてきたら、まずAGENTS.mdに移すことを検討してください。

まとめ

今回は、Codexで成果を出すためのプロンプト作成方法を解説しました。

まずは「目的・ファイル指定・完了条件」の3点を意識したプロンプトから試してみましょう。繰り返し使うルールはAGENTS.mdに集約することで、毎回の指示を省略しながら出力品質を安定させられます。

プロンプトを少しずつ工夫しながら、作業効率を高めてください。