プロンプト作成

プロンプト作成の概要

プロンプト作成とは、知りたいこと、作りたいもの、変更したいことを ChatGPT に伝える方法です。プロンプトは、質問、指示、目標のいずれでも構いません。技術的な構文や厳密な形式は必要ありません。自分の言葉で始め、応答を確認し、フォローアップメッセージを使って結果を調整してください。

短いプロンプトで十分なこともよくあります。規模が大きいタスクや重要なタスクでは、必要な要素を含めてください。

• 目標： ChatGPT に何をしてほしいですか？
• コンテキスト： どのような情報や情報源が役立ちますか？
• 出力： 必要な形式、長さ、詳細度はどの程度ですか？
• 制約： 何を変更せずに維持する必要がありますか？ChatGPT が避けるべきことや、実行前に確認すべきことは何ですか？

役立つ要素だけを使用してください。すべての項目を埋めたり、決まった形式に従ったりする必要はありません。

必要な結果を説明する

詳細な手順の一覧ではなく、求める結果から始めてください。対象読者や形式によって ChatGPT が作成すべきものが変わる場合は、それらも含めます。

Turn these meeting notes into a short update for the project team.
Put the decisions and next steps first.

このプロンプトでは、何を作成し、誰が読むのかを説明しています。プロセス自体が重要な場合は、そのプロセスも説明してください。それ以外の場合は、ChatGPT が情報を検索・比較し、アプローチを調整できる余地を残します。

役立つコンテキストを追加する

結果に影響し得る情報を共有してください。重要な情報源だけを追加し、それぞれから ChatGPT に何を読み取ってほしいかを説明します。

• ChatGPT に要約、比較、変換、またはレビュー用ファイルの作成を依頼する場合は、ドキュメント、スプレッドシート、プレゼンテーション、PDF ファイルを添付します。
• タスクが視覚的なコンテキストに依存する場合は、スクリーンショット、図、その他の画像入力を追加します。画像だけに頼らず、重要な領域を示してください。
• 回答が最新情報に依存する場合は、ChatGPT にウェブ検索の使用を依頼し、結果を確認する必要がある場合は情報源も求めます。
• 関連するチャットでファイル、情報源、ローカルフォルダーを共有する場合は、プロジェクトを使用します。

接続済みの情報源を使用する

ChatGPT が接続済みの情報源にアクセスできる場合は、どこを調べ、何を見つけるべきかを指定してください。実行すべき検索をすべて説明する必要はありません。

Use the latest project plan in Drive and relevant decisions and updates from
the project's Slack channel to prepare a status update.

接続済みの情報源には対応するプラグインが必要です。また、利用可否はプランやワークスペース設定によって異なる場合があります。

プラグインを使用する

プラグインは、再利用可能な指示と、Google Drive、Gmail、Slack、GitHub などのツールへの接続を ChatGPT に提供します。必要な結果を依頼し、利用可能なツールから ChatGPT に選択させてください。特定のプラグインを選択するには、コンポーザーで @ を入力します。

ChatGPT をパーソナライズする

チャット全体に適用する設定は、カスタム指示として Settings > Personalization に入力します。現在のチャットだけに関係する詳細は、プロンプトに含めてください。

スレッドと継続的なコンテキスト

スレッドには、プロンプト、モデルの応答、ツール呼び出しが含まれます。フォローアップメッセージにはそのスレッドのコンテキストが引き継がれるため、同じスレッド内で情報源を追加したり、方向性を修正したり、テストを追加したり、同じ結果の修正を依頼したりできます。

複数のスレッドを並行して実行できますが、2 つのスレッドで同じファイルを同時に編集しないでください。コーディング作業を並行して進める必要がある場合は、別々の worktrees を使用することをお勧めします。

すべてのコンテキストは、モデルのコンテキストウィンドウ内に収まる必要があります。長時間のタスクでは、ChatGPT または Codex が関連情報を要約し、重要度の低い詳細を除外することで、コンテキストを圧縮する場合があります。圧縮が自動で行われる場合でも、無関係なファイル、重複したログ、適用されなくなった要件は削除してください。

実際の問題を防ぐ制約を設定する

制約とは、余分な作業や意図しない操作を避けるために ChatGPT に与える少数の指示です。誤った部分が変更されると結果が使えなくなる場合や、他の人に影響が及ぶ前に内容を確認したい場合に追加してください。

• 承認済みの日付と予算額は変更しないでください。
• 提供された情報源のみを使用してください。推測せず、不足している情報を示してください。
• 提案は指定された予算の範囲内に収めてください。
• メッセージは下書きとして用意してください。送信しないでください。

最も重要な 1 つか 2 つの制約に絞ってください。ChatGPT が行うすべての手順を制御する必要はありません。

そのまま使える結果にする

結果をどのように使用する予定かを ChatGPT に伝えてください。これにより、適切な長さ、詳細度、構成を選びやすくなります。

• 会議前に部門責任者が目を通せる 1 ページの要約にしてください。意思決定事項と次のステップを最初に記載してください。
• このメモを、意思決定事項、担当者、期限を含むフォローアップメールにしてください。
• 計画支出と実績支出を分かりやすい表にまとめ、10% を超える差異を強調してください。

重要な作業では、すべてのアクション項目に担当者と期限が設定されているかの確認や、検証できなかった情報の明示など、最終確認を ChatGPT に依頼してください。その後、使用または共有する前に、自分でも結果を確認します。

フォローアップメッセージで結果を改善する

最初のプロンプトが完璧である必要はありません。結果を確認してから、必要な変更を具体的に依頼してください。

Make the opening more direct, keep the evidence, and move the recommendation
above the background section.

最初からやり直さなくても、不足している情報源の追加、方向性の修正、別案の依頼、詳細度の変更ができます。

Steer と Queue

Codex がすでに作業中でも、現在の実行が完了するのを待たずに別のメッセージを送信できます。

• Steer は、現在の実行にメッセージを追加します。方向性の変更、不足している詳細の追加、新しい情報の共有に使用します。
• Queue は、次の実行用にメッセージを保存します。現在の作業が完了するまで待つべきフォローアップに使用します。

ChatGPT デスクトップアプリでは、Settings > General > Follow-up behavior でデフォルトを選択します。キューに追加したメッセージはコンポーザーの上に表示され、編集、並べ替え、送信、削除ができます。この設定には、デフォルトを変更せずに 1 件のメッセージだけ別の動作を使用するためのショートカットも表示されます。

Codex CLI では、Codex の作業中に Enter を押すと現在のターンを Steer し、Tab を押すと次のターンにメッセージを Queue できます。詳細については、対話型ショートカットを参照してください。

各要素を組み合わせる

接続済みの情報源を使用するプロジェクト更新では、完全なプロンプトは次のようになります。

Prepare a one-page project status update for Monday's leadership meeting. Use
the latest project plan in Drive and relevant decisions and updates from the
project's Slack channel.

Lead with the decisions leadership needs to make and the next steps. Summarize
progress, risks, owners, and due dates. Keep approved dates and budget figures
unchanged. Flag any conflicting or missing information, and don't send or
publish anything.

Before you finish, check that every next step has an owner and due date.

このプロンプトは、目標、コンテキスト、出力、制約を網羅したうえで、すべての手順を細かく指定することなく最終確認を依頼しています。

音声入力を使用する

ChatGPT デスクトップアプリでコンポーザーが表示されているときに Ctrl+M を押したまま話し始めます。ChatGPT が音声を文字に起こしてコンポーザーに入力するため、プロンプトを送信する前に確認して編集できます。

Chat 向けのプロンプト例

質問、アイデア、下書き、日常的な意思決定には Chat を使用します。求める結果から始め、回答に影響する場合に限って詳細を追加してください。

トピックを理解する

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.

ChatGPT Work 向けのプロンプト作成

簡単な質問、短い書き直し、ブレインストーミング、軽量な下書きには Chat を使用します。異なる情報源やツールを利用するタスク、一連の手順を伴うタスク、変更を加えるタスク、より大きな成果物を作成するタスクには、ChatGPT Work を使用します。

ChatGPT Work では、必要な結果を説明し、資料を提供し、対象読者を指定して、作業をどのようにレビューするかを説明してください。ChatGPT に、計画を立て、必要な情報を収集し、ファイルを作成して、完了前に確認するよう依頼します。

ChatGPT Work を効率的に使用する

ChatGPT Work は、時間のかかるタスク、定期的なタスク、再利用できる完成済みファイルの作成に役立ちます。より多くのクレジットを使用するタスクでも、時間を節約し、品質を向上させ、重要な意思決定に役立つのであれば、実行する価値があります。

まず、レビュー可能な 1 つの結果から始めます。

• 関連する情報源だけを含め、必要に応じて期間を限定します。
• 対象読者、出力形式、希望する長さを定義します。
• 必須の作業と、任意の改善や仕上げを分けます。
• アプローチが重要な場合は、計画を依頼します。ChatGPT が、他の人が依存する情報を送信、公開、変更する前に、承認を必須とします。
• 不要になった作業を始めた場合は、タスクの範囲を狭めるか停止します。

最初の結果をレビューし、指示を調整して、うまく機能したらワークフローを再利用します。

資料を完成済みファイルに変換する

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.

定期的な作業では、まず通常のチャットでプロンプトを調整します。出力が安定したら、そのチャット内でタスクをスケジュールします。スケジュールされた各実行で新しいチャットを開始する必要がある場合は、代わりに独立したスケジュール済みタスクを作成してください。

Codex 向けのプロンプト作成

ChatGPT にコード、コードベース、開発者ツールを扱ってもらう場合は、Codex を使用します。効果的な Codex プロンプトでは、求める動作を示し、関連するコードや再現手順を指定し、重要な制約を維持して、変更の検証方法を伝えます。

Plan mode と Goal mode

複数の手順からなるタスクで、編集前に Codex に調査とアプローチの提案をしてほしい場合は、アプリのコンポーザーに /plan と入力します。Goal mode を使用できる場合は、計画の後に /goal を使用して永続的な目標を設定します。現在のコマンド一覧については、アプリのスラッシュコマンドを参照してください。

目標のテキストは、開始時のプロンプトと完了基準の両方として機能します。通常、適切な目標では、具体的な成果物、必要な制約、測定可能なテストまたはレビュー基準を明示します。

Migrate this codebase from JavaScript to TypeScript. Preserve existing behavior,
compile in strict mode without explicit `any` types, and make the full test suite pass.

目標の開始後も、ライブラリ、互換性、使用してはならないアプローチに関する制約を追加して、Codex の方向性を調整できます。メインタスクを中断せずに進捗の要約が必要な場合は、サイド会話を使用します。

例の読み方

各ワークフローには、次の内容が含まれます。

• 使用する場面と、最適な Codex の操作環境（IDE、CLI、クラウド）。
• プロンプト例を含む手順。
• コンテキストに関する注記：Codex が自動的に参照できる情報と、添付すべき情報。
• 検証：出力を確認する方法。

Codex は、ファイルやネットワークへのアクセスを制限するサンドボックス内でローカルコマンドを実行します。タスクがその境界を越える必要がある場合、Codex は続行前に承認ポリシーに従います。

コードベースを説明する

オンボーディング時、サービスを引き継いだとき、プロトコル、データモデル、リクエストフローを理解したいときに使用します。

IDE 拡張機能のワークフロー（ローカル調査に最適）

1. 最も関連性の高いファイルを開きます。

2. 確認したいコードを選択します（任意ですが推奨）。

3. 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.

CLI ワークフロー（記録とシェルコマンドが必要な場合に有効）

1. 対話型セッションを開始します。

   codex

2. ファイルを添付し（任意）、プロンプトを送信します。

   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.

コンテキストに関する注記：

• コンポーザーで @ を使用するとワークスペースのファイルパスを挿入でき、/mention を使用すると特定のファイルを添付できます。

バグを修正する

ローカルで再現できる不具合がある場合に使用します。

CLI ワークフロー（再現と検証を繰り返す場合）

1. リポジトリのルートで Codex を起動します。

   codex

2. 再現手順と、問題があると思われるファイルを 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.

コンテキストに関する注記：

• ユーザーが提供するもの：再現手順と制約（高レベルの説明よりも重要です）。
• Codex が提供するもの：コマンド出力、検出した呼び出し元、発生したスタックトレース。

検証：

• Codex は修正後に再現手順をもう一度実行する必要があります。
• 標準のチェックパイプラインがある場合は、その実行を依頼します。

After the fix, run lint + the smallest relevant test suite. Report the commands and results.

IDE 拡張機能のワークフロー

1. バグがあると思われるファイルと、その最も近い呼び出し元を開きます。

2. Codex にプロンプトを送信します。

   Find the bug causing "Saved" to show without persisting changes. After proposing the fix, tell me how to verify it in the UI.

テストを作成する

テストする正確な範囲を指定したい場合に使用します。

IDE 拡張機能のワークフロー（選択範囲ベース）

1. 関数が含まれるファイルを開きます。

2. 関数を定義している行を選択します。コマンドパレットで「Add to Codex Thread」を選択し、その行をコンテキストに追加します。

3. Codex にプロンプトを送信します。

   Write a unit test for this function. Follow conventions used in other tests.

コンテキストに関する注記：

• 「Add to Codex Thread」コマンドで提供されるもの：選択した行（「行番号」の範囲）と、開いているファイル。

CLI ワークフロー（プロンプトでパスと行範囲を指定）

1. Codex を起動します。

   codex

2. 関数名を含むプロンプトを送信します。

   Add a test for the invert_list function in @transform.ts. Cover the happy path plus edge cases.

スクリーンショットからプロトタイプを作成する

デザインモック、スクリーンショット、UI リファレンスを動作するプロトタイプに変換する場合に使用します。

CLI ワークフロー（画像とプロンプト）

1. スクリーンショットをローカルに保存します（例：./specs/ui.png）。

2. Codex を実行します。

   codex

3. 画像ファイルをターミナルにドラッグして、プロンプトに添付します。

4. 続けて、制約と構成を指定します。

   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

コンテキストに関する注記：

• 画像は視覚的な要件を提供しますが、実装上の制約（フレームワーク、ルーティング、コンポーネントのスタイル）は別途指定する必要があります。
• ホバー状態、検証ルール、キーボード操作など、画像に表れない動作はテキストで記載します。

検証：

• Codex に開発サーバーを起動するよう依頼し（許可されている場合）、プロトタイプを確認するローカル URL またはルートを正確に尋ねます。

Start the dev server and tell me the local URL/route to view the prototype.

IDE 拡張機能のワークフロー（画像と既存ファイル）

1. Codex チャットに画像を添付します（ドラッグ＆ドロップまたは貼り付け）。

2. Codex にプロンプトを送信します。

   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 にコードを編集させながら、「デザイン → 調整 → 更新 → 調整」という短いサイクルを繰り返す場合に使用します。

CLI ワークフロー（Vite を実行し、小さなプロンプトで反復）

1. Codex を起動します。

   codex

2. 別のターミナルウィンドウで開発サーバーを起動します。

   npm run dev

3. Codex に変更案を依頼します。

   Propose 2-3 styling improvements for the landing page.

4. 方針を選び、小さく具体的なプロンプトで反復します。

   Go with option 2.
   
   Change only the header:
   - make the typography more editorial
   - increase whitespace
   - ensure it still looks good on mobile

5. 焦点を絞った依頼を繰り返します。

   Next iteration: reduce visual noise.
   Keep the layout, but simplify colors and remove any redundant borders.

検証：

• Codex がコードを更新するたびに、ブラウザーで変更を確認します。
• 気に入った変更をコミットし、不要な変更は元に戻します。
• 編集を元に戻したり変更したりした場合は、次のプロンプトで Codex が上書きしないよう、その旨を伝えてください。

リファクタリングをクラウドに委任する

ローカルのコンテキストを使ってアプローチを設計し、その後、時間のかかる実装を並行実行できるクラウドチャットに委任する場合に使用します。

ローカルでの計画（IDE）

1. 変更を明確に比較できるよう、現在の作業がコミット済みか、少なくとも stash されていることを確認します。

2. Codex にリファクタリング計画の作成を依頼します。$plan スキルを使用できる場合は、明示的に呼び出します。

   $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

3. 計画をレビューし、変更点を調整します。

   Revise the plan to:
   - specify exactly which files move in each milestone
   - include a rollback strategy

コンテキストに関する注記：

• 計画作成は、Codex が現在のコードをローカルで調査できる場合に最も効果的です（エントリーポイント、モジュール境界、依存関係グラフの手がかりなど）。

クラウドへの委任（IDE → クラウド）

1. まだ設定していない場合は、Codex クラウド環境を設定します。

2. プロンプトコンポーザーの下にあるクラウドアイコンをクリックし、クラウド環境を選択します。

3. 次のプロンプトを入力すると、Codex は既存のチャットコンテキスト（計画とローカルでのソース変更を含む）を引き継いだ新しいチャットをクラウドに作成します。

   Implement Milestone 1 from the plan.

4. クラウドの差分を確認し、必要に応じて反復します。

5. クラウドから直接 PR を作成するか、変更をローカルに取り込んでテストと仕上げを行います。

6. 計画の追加マイルストーンに取り組みます。

クラウドに委任されたタスクは、分離された環境で実行されます。環境で有効にしない限り、エージェントフェーズ中のインターネットアクセスは無効です。詳細については、クラウドのインターネットアクセスを参照してください。

ローカルでコードレビューを行う

コミットまたは PR の作成前に、別の視点から確認してほしい場合に使用します。

CLI ワークフロー（作業ツリーをレビュー）

1. Codex を起動します。

   codex

2. レビューコマンドを実行します。

   /review

3. 任意：重点的に確認する項目を指定します。

   /review Focus on edge cases and security issues

検証：

• レビューのフィードバックに基づいて修正を適用し、/review を再実行して問題が解決されたことを確認します。

GitHub の pull request をレビューする

ブランチをローカルに取り込まずにレビューのフィードバックを得たい場合に使用します。

使用する前に、リポジトリで Codex の Code review を有効にしてください。Code review を参照してください。

GitHub ワークフロー（コメント駆動）

1. GitHub で pull request を開きます。

2. Codex をタグ付けし、確認してほしい領域を明示したコメントを残します。

   @codex review

3. 任意：より具体的な指示を追加します。

   @codex review for security vulnerabilities and security concerns

ドキュメントを更新する

正確で分かりやすいドキュメントの変更が必要な場合に使用します。

IDE または CLI のワークフロー（ローカル編集とローカル検証）

1. 変更するドキュメントファイルを特定し、IDE で開くか、IDE または CLI で @ を使用してメンションします。

2. 範囲と検証要件を含むプロンプトを Codex に送信します。

   Update the "advanced features" documentation to provide authentication troubleshooting guidance. Verify that all links are valid.

3. Codex が変更案を作成したら、ドキュメントをレビューし、必要に応じて調整します。

検証：

• レンダリングされたページを確認します。