OpenAI公式ガイド：バグ修正からスクショのプロトタイプ化、クラウドリファクタリングまで、そのまま使えるCodexプロンプト9ワークフロー
- ChatGPT公式がプロンプトガイドを発表。Chat、Work、Codexの3つのインターフェースをカバー。
- 核心は4要素フレームワーク——目標・背景・出力・境界線。必要なものだけ書けばよく、全部埋める必要はない。
- Codex向けには9つの具体的なワークフローを提示——コードベースを読む、バグを直す、テストを書く、スクリーンショットをプロトタイプに変える、確認しながら進めるUI反復、クラウドへのリファクタリング委任、2通りのコードレビュー、ドキュメント更新。それぞれにそのままコピペできるプロンプトが付いている。
- Codex実行中に追加メッセージを送れる——steerはその場でタスクの方向を変え、queueは次のターンに回す。
- ローカルIDEで固めたリファクタリング計画は、コンテキストごとそのままクラウド環境に持ち込んで続きを実行できる。
テンプレートを暗記しなくていい：4つの要素、必要な分だけ埋める
OpenAIチームはlearn.chatgpt.comで公式プロンプトガイドを発表し、Chat、Work、Codexの3つのインターフェースでどうプロンプトを書けばいいかを明確にした。
一つの原則がChat、Work、Codexの3インターフェースの書き方を統一し、Codex向けにはコマンドレベルまで落とし込んだ9つのコピペ可能なワークフローを用意している。短いタスクなら一言で十分、大きなタスクだけ要素を補えばいい。
まず「どんな結果が欲しいか」をはっきりさせる、手順を並べるのは後
欲しい結果から話し始め、想定読者とフォーマットを併せて伝える。どうやるかの部分はChatGPTに検索・比較・調整させる余地を残す。手順そのものが重要なときだけ手順を説明する。
Turn these meeting notes into a short update for the project team. Put the decisions and next steps first.
結果を何に使うかを伝えれば、長さと詳細度は自分で判断してくれる
「出力」の要素のコツは、その結果を何に使うつもりかをChatGPTに伝えることだ。そうすれば適切な長さ、詳細度、構成を自分で選んでくれる。重要な作業では、最後に一度最終チェックを求めることもできる——たとえば各アクション項目に担当者と締め切りがあるか確認させる、あるいは裏取りできなかった情報にフラグを立てさせて、自分で最終確認する、といった具合だ。
Make this a one-page summary a director can scan before the meeting. Put the decision and next steps first. Turn these notes into a follow-up email with the decisions, owners, and due dates. Create a clear table of planned versus actual spending and highlight any difference over 10%.
そして4要素の中で一番見落とされがちな一つ——境界線。
境界線とは、ChatGPTが余計なことをしたり勝手に行動したりしないよう防ぐための指示だ。判断基準はシンプル——「細部を一つ間違えるだけで結果が使い物にならなくなる」場合、あるいは「その動作が他人に影響し、先に自分で確認したい」場合には、一言加える。最も重要な1、2点だけ押さえればよく、すべてのステップを管理する必要はない。
Keep the approved dates and budget figures unchanged. Use only the supplied sources. Flag missing information instead of guessing. Keep recommendations within the stated budget. Prepare the message as a draft. Don't send it.
適切な背景を渡す：ファイル、スクリーンショット、Web検索、連携ソフト
「背景」とは結果を左右する情報のことだ。原則は関連するソースだけを渡し、各ソースから何を取り出してほしいかを明確に伝えること。渡し方にはいくつか種類がある。
| 渡し方 | 使うタイミング |
|---|---|
| 文書／表計算／スライド／PDFのアップロード | 要約・比較・書き直し、あるいはレビュー可能なファイルを出力させたいとき |
| スクリーンショット／図解／画像 | タスクが視覚情報に依存するとき。画像のどの部分を見てほしいか一言添える。画像だけ渡さない |
| Web検索 | 答えが最新情報に左右されるとき。結果を確認したいなら出典も併せて出させる |
| 連携データソース(Drive／Slackなど) | どこで何を探すか名指しすればよく、毎回の検索方法まで説明しなくていい |
Use the latest project plan in Drive and relevant decisions and updates from the project's Slack channel to prepare a status update.
連携データソースには対応するプラグインの導入が必要で、使えるかどうかはプランとワークスペース設定次第だ。特定のプラグインを指定したいときは、入力欄で@を打って選べばいい。もう一つ区別しておくべき点がある——毎回適用したい好み(デフォルトのトーン、習慣)は「設定＞パーソナライズ」のカスタム指示に入れ、今回のタスクだけに関わる詳細はそのプロンプトに書く。
結果が気に入らなくても書き直し不要——フォローアップメッセージ + 割り込みか順番待ちか
最初のプロンプトで一発完璧にする必要はない。結果を見て、直したい箇所をそのまま伝えるだけでいい——出典を補う、方向を直す、別バージョンにする、詳細度を調整する、どれも最初からやり直さなくてすむ。
Make the opening more direct, keep the evidence, and move the recommendation above the background section.
Codexにはもう一層ある——実行中にもメッセージを追加送信でき、どのターンで反映されるかは送り方次第だ。
料理人がすでに炒め始めている状況を思い浮かべてほしい。「steer」と言うのは今すぐ具材を変えるよう伝えることで、その一皿はその場で新しい要求通りに作り直される。「queue」と言うのは、その一皿が炒め終わってから、追加で頼んだ料理を出してもらうことだ。
デスクトップアプリでは、デフォルトの挙動は「設定＞General＞Follow-up behavior」で設定できる。順番待ちのメッセージは入力欄の上に表示され、編集・並べ替え・送信・削除ができる。Codex CLIでは、実行中にEnterを押すと現在のターンにsteerし、Tabを押すと次のターンにqueueする。ちなみに、デスクトップアプリは音声入力にも対応している——Ctrl+Mを長押しして話すと、内容がテキストに変換されて入力欄に入り、送信前に確認・修正できる。
完全な例で見る：4要素を実際のプロンプトで対応させる
4要素は固定の枠ではない。以下は実際の完全なプロンプトで、4色でどの部分が目標・背景・出力・境界線かをマークしてある。一度見れば、それらが一つの文章にどう織り込まれるか分かる。
日本語訳：［目標］月曜の経営陣会議向けに、1ページのプロジェクトステータスアップデートを作成する。［背景］Driveにある最新のプロジェクト計画と、プロジェクトのSlackチャンネルにある関連する決定事項・進捗を使う。［出力］冒頭で経営陣が判断すべき決定事項と次のステップを示し、その後に進捗・リスク・担当者・締め切りをまとめる。［境界線］承認済みの日付と予算の数字は変更しない。矛盾や欠落がある情報はフラグを立てる。何も送信・公開しない。［境界線・最終チェック］完了前に、すべての次のステップに担当者と締め切りがあるか確認する。
これは目標・背景・出力・境界線をすべてカバーし、末尾に最終チェックを一言加えているが、すべての手順を細かく指定してはいない。これが4要素を「必要に応じて組み立てる」姿だ。
日常的な質問はChat、成果物はWork
Chatは質問・アイデア出し・下書き・日常の意思決定に向いている——欲しい結果から話し始め、必要なときだけ詳細を補う。Workは複数のソースやツールを使う必要がある、複数ステップにわたる、比較的大きな成果物ファイルを作る、といった作業に向いている。以下は公式が示した例で、どれもそのままコピペして使える。
Chat：日常的な質問の4つの例
Explain how compound interest works for someone who has never invested. Use one concrete example and define any financial terms you introduce.
Draft a friendly email declining this invitation because I will be traveling. Keep it under 120 words and leave the door open for a future event.
Compare these two phone plans for one person who travels internationally twice a year. Show the important differences in a table, then recommend one and explain the tradeoff.
Plan five weekday dinners that take less than 30 minutes. Avoid peanuts, reuse ingredients across meals, and finish with one consolidated shopping list.
Work：成果物を作る3つの例
Use the attached quarterly reports to create a leadership brief and a six-slide presentation. The audience is the executive team. Lead with the three decisions they need to make, distinguish reported facts from your analysis, cite each number to its source file, and check that the brief and slides agree before you finish.
Research three customer-support platforms for a 50-person company. Compare pricing, security, integrations, and migration effort using current sources. Deliver a recommendation memo with links, assumptions, and the questions we should answer before signing a contract.
Create a launch plan for the attached product brief. Include the timeline, owners, dependencies, risks, announcement draft, customer FAQ, and a checklist for launch day. Flag any missing decisions before producing the final files.
Workを使うコツ：まずは自分でレビューできる小さな結果から始め、ソースの範囲を絞り、日付を限定し、必須の作業と任意の仕上げを分けること。手順そのものが重要な作業なら、先に計画を出させる。送信・公開・他人が依存する情報の変更をする前には、自分の承認を必須にする。うまくいったら、その流れを使い回せばいい。繰り返しの作業は、そのタスクからそのまま定期自動実行に設定することもできる。
Codex基本の3点セット：コードを読む、バグを直す、テストを書く
ChatGPTにコード、コードベース、開発者ツールを扱わせたいときはCodexを使う。良いCodexプロンプトは、欲しい振る舞いを明示し、関連コードや再現手順を指し示し、重要な制約を守り、検証方法をはっきりさせる。以下の3つはすべてそのままコピペできる。
まず背景を2つ。IDE拡張機能は開いているファイルを自動的にコンテキストとして扱う。CLIではパスを明示するか、@補完や/mentionでファイルを添付する必要がある。もう一つ、Codexがローカルでコマンドを実行するときはサンドボックスに閉じ込められ、ファイルとネットワークの権限が制限される——外部ネットワークへのアクセスやサンドボックス外のファイル変更など、境界を越える必要がある場合は、設定した承認ポリシーを通さないと実行されない。
コードベースを理解する
見知らぬサービスを引き継いだとき、特定のプロトコルやリクエストの流れを整理したいときに使う。
Explain how the request flows through the selected code. Include: - a short summary of the responsibilities of each module involved - what data is validated and where - one or two "gotchas" to watch for when changing this (検証の追加質問) Summarize the request flow as a numbered list of steps. Then list the files involved.
codex I need to understand the protocol used by this service. Read @foo.ts @schema.ts and explain the schema and request/response flow. Focus on required vs optional fields and backward compatibility rules.
バグを直す
手元に再現可能な不具合があるときに使う。再現レシピと、疑わしいファイルを添えたほうが、高レベルな説明一言よりはるかに役に立つ。
codex Bug: Clicking "Save" on the settings screen sometimes shows "Saved" but doesn't persist the change. Repro: 1) Start the app: npm run dev 2) Go to /settings 3) Toggle "Enable alerts" 4) Click Save 5) Refresh the page: the toggle resets Constraints: - Do not change the API shape. - Keep the fix minimal and add a regression test if feasible. Start by reproducing the bug locally, then propose a patch and run checks. (検証の追加質問) After the fix, run lint + the smallest relevant test suite. Report the commands and results.
Find the bug causing "Saved" to show without persisting changes. After proposing the fix, tell me how to verify it in the UI.
単体テストを書く
テスト対象を正確に絞りたいときに使う。IDEでは関数コードを選択してから尋ね、CLIでは関数名を直接指定する。
(IDE，选中函数代码后) Write a unit test for this function. Follow conventions used in other tests. (CLI，直接点名函数) Add a test for the invert_list function in @transform.ts. Cover the happy path plus edge cases.
Codex応用の3点セット：スクリーンショットをプロトタイプに変える、確認しながらUIを直す、クラウドに委任する
より応用的な3つのワークフロー——デザインのスクリーンショットをそのまま動くプロトタイプに変える、コードを直しながらブラウザで確認する、時間のかかるリファクタリングをローカルで方針を固めてからクラウドに任せる。
スクリーンショットをプロトタイプに変える
デザイン案、スクリーンショット、UI参考画像を動くプロトタイプに変えたいときに使う。画像が示すのは見た目の要求であって、フレームワーク・ルーティング・コンポーネントのスタイルといった実装上の制約は自分で書く必要がある。画像だけでは分からない振る舞い(ホバー状態、バリデーションルール、キーボード操作)もテキストで補う。
デザインのスクリーンショット／UI参考画像に、実装上の制約(使うフレームワーク、ルーティング、コンポーネントのスタイル)と、画像だけでは分からない振る舞いの説明を添える。
動くプロトタイプ——新しいルート／ページ+必要な小さなコンポーネント+READMEファイル。Codexに開発サーバーを起動させ、どのローカルアドレスで確認できるか教えてもらう。
codex (拖入截图后) Create a new dashboard based on this image. Constraints: - Use react, vite, and tailwind. Write the code in typescript. - Match spacing, typography, and layout as closely as possible. Outputs: - A new route/page that renders the UI - Any small components needed - README.md with instructions to run it locally (验证追问) Start the dev server and tell me the local URL/route to view the prototype. (IDE版，贴截图) Create a new settings page. Use the attached screenshot as the target UI. Follow design and visual patterns from other files in this project.
確認しながら進めるUI反復
「デザイン→微調整→更新→また調整」を小刻みに繰り返したいときに使う。開発サーバーを動かしながら、小さく具体的な指示を何ラウンドも重ねて収束させる。
codex npm run dev 第一轮:Propose 2-3 styling improvements for the landing page. 第二轮(选定方向后细化到具体元素):Go with option 2. Change only the header: - make the typography more editorial - increase whitespace - ensure it still looks good on mobile 第三轮(继续收敛):Next iteration: reduce visual noise. Keep the layout, but simplify colors and remove any redundant borders.
各ラウンドで修正が終わったらブラウザで確認し、気に入ればコミット、気に入らなければリバートする。手動で修正やリバートをした箇所があれば、Codexに伝えておくこと——次のラウンドでその変更を上書きされないように。
リファクタリングをクラウドに委任する
まずローカルのコンテキストで方針を設計し、時間のかかる実装はクラウドに任せて並行実行させたいときに使う。ポイントは、ローカルで固めた方針が完全なコンテキストごとクラウドに引き継がれること。
まずローカルIDEで$planを使い、Codexにコードを調査させて方針を出させ、満足するまで何度も修正する。クラウド環境に切り替えると、Codexは新しいクラウドタスクを作成し、既存のコンテキスト(方針とローカルでの変更を含む)を一緒に持っていく。クラウドは隔離された環境で実行を終え、そのままdiffを出す。レビュー後、直接PRを作ることも、ローカルに戻してテストすることもできる。方針が決まったら/goalでGoal modeを開始し、継続的に追跡する長期目標を設定して、複数のステップを自律的に進めさせることもできる。
本地规划: $plan We need to refactor the auth subsystem to: - split responsibilities (token parsing vs session loading vs permissions) - reduce circular imports - improve testability Constraints: - No user-visible behavior changes - Keep public APIs stable - Include a step-by-step migration plan 修订计划: Revise the plan to: - specify exactly which files move in each milestone - include a rollback strategy 切到云端环境后: Implement Milestone 1 from the plan.
クラウドに委任したタスクは隔離環境で動作し、agentフェーズはデフォルトでネットワークが無効——その環境でネットワークを有効にしない限り。マイルストーン1が通ったら、残りのマイルストーンを一つずつ進める。
Codexはコードレビューも手伝える:ローカルでコマンド一発、あるいはGitHubで@する
コミットやPR作成の前にもう一組の目が欲しいときは、2通りの方法がある——ローカルでスラッシュコマンドを使うか、GitHubのコメント欄で@する。どちらも「セキュリティ問題だけ見て」といった絞り込み指示が出せる。
| ローカル /review | GitHub @codex review | |
|---|---|---|
| 使うタイミング | コミット／PR作成前に、自分のワークスペースを先に確認したいとき | ブランチをローカルに持ってこず、PR上で直接フィードバックが欲しいとき |
| 起動方法 | Codexで/reviewを入力 | PRのコメント欄に@codex reviewと書く |
| 絞り込み指示 | /review Focus on... | @codex review for... |
| 前提条件 | なし、Codexでそのまま使える | 先にリポジトリでCodexのCode reviewを有効にしておく |
/review (定向聚焦) /review Focus on edge cases and security issues
@codex review (定向聚焦) @codex review for security vulnerabilities and security concerns
ローカルでレビューが終わったら、フィードバックに沿って修正し、もう一度/reviewを実行して問題が解決したか確認する。
おまけ:ドキュメントを更新する
正確で分かりやすいドキュメント修正が必要なときは、直したいファイルを絞り込み、範囲を説明し、検証を求める。
Update the "advanced features" documentation to provide authentication troubleshooting guidance. Verify that all links are valid.
始め方:まずは一番シンプルなワークフロー(コードベースを読むなど)を試して動かしてみて、その書き方を他のタスクにも使い回せばいい。
プロンプトを書くのに技術的な文法や決まった公式は要らない。自分の言葉で話し始めて、その反応を見て、フォローアップメッセージで結果を少しずつ望む形に整えていけばいい。ChatGPT Learn・Prompting
ChatGPT公式に学ぶプロンプトの書き方:「話を半分だけ言ってAIに推測させる」から「4つのことをはっきり言えば、脱線しない」へ
OpenAI公式ガイド:1つの4要素フレームワークでChat・Work・Codexの3インターフェースを統一、さらにそのままコピペできる9つのプログラミング用ワークフロー付き。図解1枚で読み切る。
↓ 1枚で読み切る・動く図が1つあります
OpenAIが公式サイトでプロンプト(AIへの指示)ガイドを発表し、各所に散らばっていたコツを1つにまとめた。対象はChatGPTの3つのインターフェース——Chat(チャット)、Work(成果物ファイル生成)、Codex(コーディングモード)。これが解決しようとしているのは、普通の人がAIに指示を出すときのありがちなクセだ。
公式の答えは4つ——目標(欲しい結果)、背景(渡す材料)、出力(欲しい形式)、境界線(絶対に触ってはいけないもの)。必要に応じて選べばよく、毎回全部埋める必要はない。その中でも「境界線」は一番見落とされがちだが、脱線と誤操作を防ぐのに一番効く。同じ作業でも、半分だけ言うのとはっきり言うのとでは、こんな差が出る。
「この会議メモをちょっとまとめて」
誰に見せるか、どのくらいの長さか、何を変えてはいけないか——何も言っていないのでAIは推測するしかなく、結果はたいてい手直しが必要になる。
一つの文章に4つのブロックがすべて揃っている:何をするか・どの材料を使うか・何を最初に置くか・何を変えてはいけないか。一発で使える。
この4つのブロックがどう1つの文章に織り込まれ、どう渡せば結果が出るのか、シャオフーの実際の作業で見ていこう。
シャオフーの手元にはある会議の記録があり、チーム向けのアップデートにまとめたい。彼がやるべきことは、上の4つの情報ブロックを1つの完全な指示にまとめて、AIに渡すことだけだ。
同じ原則が3つの場面に落とし込まれる:日常的な質問はChat、成果物ファイルが欲しいならWork、コードに関わるならCodex。結果が気に入らなくても書き直す必要はなく、直したい箇所をそのまま伝えればいい。Codexが実行中でもメッセージを追加でき、その場で方向を変える(steer、実行中のターンに割り込む)か、次のターンに回す(queue、順番待ちにする)かを選べる。
特にCodex向けには、コマンドレベルまで落とし込んだ9つのワークフローが提示されている——コードを理解する、バグを直す、テストを書く、スクリーンショットをプロトタイプに変える、確認しながらUIを調整する、リファクタリングをクラウドに任せる、コードをレビューする、ドキュメントを更新する。本文ではそれぞれにそのままコピペできるプロンプトが付いている。
4、3、9のこの3つの数字はすべてOpenAI公式ドキュメントに由来する。本文中の英語プロンプト例は原文のまま保持されており、第三者による評価は含まれていない。
アップデートにまとめて、よろしく
- × 誰に見せるか言っていない
- × どのくらいの長さか言っていない
- × 何を変えてはいけないか言っていない
後……
予算もついでに変えました
言えば脱線しない
全部埋めるの?
送らない
すぐ使えるワークフロー
Codexすべてに通じる
まず下書きにして、送らないで
言うべきことを言えば、
AIは脱線しない