Codex最初のプロンプト集。新人スタッフに頼む5つの仕事
合同会社Leadfive 山下です。
さて、 Leadfiveでは、AIを便利なツールで終わらせず、会社の実務に組み込むAIエージェント運用を発信・支援しています。Codexを入れた直後に止まりやすいのは、設定ではなく、最初の仕事の頼み方です。
Codexは、相談相手というより新人スタッフに近いAIエージェントです。だから最初のプロンプトは、仕事を丸投げする文章ではなく、目的、触ってよい場所、止める場所、報告してほしいことを書いた指示書にします。
最初のプロンプトは、新人スタッフへの初日指示です
Codexへの最初の依頼では、成果物より先に仕事の範囲を決めます。
新人スタッフに「会社のWebまわりをいい感じにして」と頼んでも、何を見てよいか、どこまで直してよいか、誰の確認がいるか分かりません。Codexも同じです。作業が速いぶん、曖昧な指示ほど危険になります。
最初の型はこれで十分です。
目的:
何を良くしたいかを1文で書く。
進めてよいこと:
読んでよいファイル、作ってよい下書き、ローカル確認の範囲を書く。
止めること:
公開、投稿、送信、本番反映、DB、env、secret、顧客データには触れないと書く。
完了条件:
作ったもの、確認したこと、未確認のこと、次に人間が判断することを報告してもらう。
この型は、Codexの始め方と最初に設定すべきポイントの次に使う実務編です。設定が済んだら、次は依頼文を整えます。
ブログ下書きは、レジ締めを1つ任せる感覚で頼みます
最初に頼みやすい仕事は、公開前で止められる下書き作成です。
記事、SNS文、メール案、FAQ案は、下書きで止めればリスクを小さくできます。新人スタッフにいきなり店頭POPを掲示させるのではなく、まず案を作ってもらい、責任者が確認する流れです。
目的:
当社サイト向けのブログ下書きを1本作ってください。
前提:
読者は中小企業経営者です。専門用語を出したら、会社の仕事に置き換えて説明してください。
進めてよいこと:
- 既存の公開済み記事を読む
- 下書きMarkdownを作る
- 画像配置案、alt、内部リンク候補を出す
止めること:
- 公開、予約公開、SNS投稿はしない
- 未公開ページへの本文リンクは入れない
- env、secret、顧客情報は見ない
完了条件:
下書きパス、要点、公開前に人間が確認する項目を報告してください。
AGENTS.mdはAIに渡す会社の業務マニュアルを用意しておくと、毎回この禁止事項を長く説明しなくて済みます。
公開前レビューは、責任者確認のチェック表として頼みます
Codexは、作る仕事だけでなく、確認する仕事にも向いています。
経営者が全部を自分で読む前に、誤字、リンク、画像、出典、禁止表現、公開前に止める操作を一覧化してもらう。これは新人スタッフにレジ締め前のチェック表を作ってもらう感覚です。
目的:
公開前の記事をレビューし、公開してよいかではなく、確認すべき点を整理してください。
見る観点:
- タイトルと本文のズレ
- 出典リンクの不足
- 未公開URLや仮リンクの混入
- 誇張表現や断定しすぎた表現
- 画像altと画像パス
- 内部リンクの自然さ
止めること:
記事公開、投稿、approved化、push、deployはしない。
出力:
1. 修正すべき点
2. 公開前に人間が見る点
3. そのまま進めてよい点
4. 未確認の点
に分けてください。
公開前レビューでは、AIに承認者を任せません。AIは見落としを減らす担当、人間は公開判断の責任者です。
Web修正案は、店頭を変える前の裏方作業として頼みます
Webサイトの更新は、下書き、ローカル確認、差分報告までに区切ると頼みやすくなります。
営業中の店頭を勝手に変えず、裏で新しい陳列案を作って責任者に見せる。CodexにWeb修正を頼む時も、この順番にします。
目的:
指定ページの文言と内部リンクを改善する修正案を作ってください。
進めてよいこと:
- 対象ページと関連ファイルを読む
- 作業ブランチ前提の修正案を作る
- ローカルで確認できる範囲のチェック項目を出す
止めること:
- mainまたはmasterへの直接反映はしない
- git push、deploy、本番反映はしない
- 広告タグ、GA4、GTM、DB、envは触らない
報告:
変更したい箇所、理由、確認方法、公開時の注意点を短くまとめてください。
承認、サンドボックス、ブランチ運用を先に決める考え方は、Codexのおすすめ設定記事が公開されたら接続したいテーマです。現時点では未公開のため、本文リンクには入れず候補として残します。
調査依頼は、一次情報だけを持ってくる係として頼みます
最新ツールの話題は、Xだけで判断しない形にします。
Xは発見の入口として使えます。しかし、記事や社内判断に使うなら、公式ドキュメント、公式ブログ、GitHub公式リリース、企業発表で確認します。Codexには、噂をまとめる係ではなく、一次情報を探す係として頼みます。
目的:
指定したAIツールの最新情報について、記事化できる候補を調べてください。
調査範囲:
- 公式ドキュメント
- 公式ブログ
- 公式リリースノート
- GitHub公式リリース
- 企業公式発表
扱い:
- Xやブログ記事は発見入口として扱う
- 公式確認できない内容は unverified と書く
- 公式確認できない情報を事実として断定しない
出力:
候補、公式確認URL、読者の実務に関係する点、記事化しない理由を分けてください。
この頼み方にすると、AIニュースを追う時間を減らしながら、記事で間違った断定をしにくくなります。
最後は、人間が判断することを1行で返してもらいます
Codexの報告は、作業ログではなく、次に人間が判断することへ圧縮してもらいます。
AIが長い報告を返してくると、経営者は読むだけで疲れます。新人スタッフにも、作業日報ではなく「今、社長に決めてほしいこと」を最後に出してもらう方が動きやすい。
最後の1行を指定します。
最後に、CEOが次に判断することを1つだけ書いてください。
形式:
次に判断すること: Aを進める / Bで止める / Cを後日に回す
Codexに最初から大きな仕事を任せる必要はありません。ブログ下書き、公開前レビュー、Web修正案、一次情報調査、判断事項の整理。この5つから始めると、AIは便利なチャットではなく、会社の中で仕事を進める新人スタッフになります。
よくある質問
Codexに最初から自由に任せた方が早くないですか
早く見えて、確認コストが増えます。最初は下書き、レビュー、調査のように止める場所が明確な仕事から始めます。
プロンプトは毎回長く書く必要がありますか
毎回ではありません。よく使う停止条件や文体はAGENTS.mdに寄せ、個別プロンプトでは目的と完了条件を中心に書きます。
Xで見た新機能をすぐ記事にしてよいですか
公式確認できる場合だけ記事化します。Xは発見入口で、事実確認の一次情報にはしません。
出典
-
[Codex prompting OpenAI Developers](https://developers.openai.com/codex/prompting) -
[Codex CLI OpenAI Developers](https://developers.openai.com/codex/cli) -
[AGENTS.md OpenAI Developers](https://developers.openai.com/codex/agents)
このシリーズの順番
下書き、レビュー、調査など最初に頼む依頼文を作れる。次の作業は、記事内プロンプトから1つ選んで試すことです。