開発者のためのAI：コーディングエージェント、コスト、安全な任せ方

やり方

1. 1渡す前に、チェックを書くか指定します。失敗中のテスト、またはコマンドとその期待される出力です。
2. 2このページのプロンプトでタスクを渡します。変更してよいファイルと、変更してはいけないファイルも含めます。
3. 3チェックはエージェント自身に実行させ、最終的な出力を貼り付けさせます。
4. 4差分は同僚のプルリクエストと同じようにレビューします。チェックが通ったらレビューが始まるのであって、終わるのではありません。

組み込み機能

• ChatGPT · Codex
• Claude · Claude Code

コピーできるプロンプト

タスク：[変更内容]。
完了の条件：[テストまたはコマンド]が通り、[期待される出力]を表示すること。終える前に実行し、結果を貼り付けてください。
変更してよいもの：[パス]。変更してはいけないもの：[パス]、依存関係、テスト。
通せない場合は、チェックを回避せずに作業を止め、理由を説明してください。

失敗しやすい点

• エージェントは、テストを弱めることでテストを通してしまうことがあります。テストの変更を禁止し、差分でもそうなっていないか確認しましょう。
• 1つのチェックに収まらないほど大きなタスクは、一度に任せるには大きすぎます。分割しましょう。

やり方

1. 1コードの置き場所に近いものを選びます。Codex Cloud、GitHubのCopilot cloud agent、またはClaude Code on the webです。
2. 2その環境で依存関係をインストールし、テストを実行できることを確認しましょう。それができなければ、エージェントは推測で動くことになります。
3. 3上の作業のように、それぞれ専用のチェックを付けた、小さく独立したタスクを送ります。
4. 4各プルリクエストは、まず自動レビューアーに読ませ、それから自分でレビューします。

組み込み機能

• Codex · Codex Cloud
• GitHub Copilot · Copilot cloud agent
• Claude Code · Claude Code on the web (cloud sessions)

コピーできるプロンプト

このリポジトリで：[タスク]。
背景：[コードの該当箇所、関連するissue]。
完了の条件：あなたの環境で[テストまたはコマンド]が通ること。その出力をプルリクエストの説明に記載してください。
プルリクエストの変更行数は[行数]行未満にしてください。それ以上必要な場合は、作業を止めて分割の方法を提案してください。

失敗しやすい点

• 設定していないシークレットやサービスが必要なテストは、スキップされるか失敗します。それなしで通っても、ほとんど何も証明されません。
• 関連するコードに複数のエージェントを当てると、競合するプルリクエストができます。並行するタスクは別々の領域に分けましょう。

やり方

1. 1ビルド、テスト、リントのコマンドを、エージェントが毎回のセッション開始時に読む指示ファイルに書きます。ファイル名は各エージェントのドキュメントに載っています。
2. 2Claude Codeでは、編集のたびにフォーマッターとテストを実行するフックを追加します。そうすればエージェントが失敗を見て直します。
3. 3すべてのプルリクエストをボットにレビューさせます。Codexで「Automatic review」をオンにするか、Copilotをレビューアーに指定します。
4. 4エージェントが同じ間違いを2回したら、それをテストか指示ファイルのルールにします。

組み込み機能

• Claude Code · Hooks
• Codex · Codex code review
• GitHub Copilot · Copilot code review

コピーできるプロンプト

このリポジトリを読んで、コーディングエージェント向けの指示ファイルを書いてください：
1. インストール、ビルド、テスト、リント、フォーマットの正確なコマンド。
2. プロジェクトの構成を10行以内で。
3. ここで新しく来た人が間違えやすい規約を、それぞれ例を1つ付けて。
4. エージェントがここで決してしてはいけないこと。たとえばマイグレーションの変更や生成ファイルの編集。
実際に実行して成功したコマンドだけを載せ、それ以外には「未検証」と付けてください。

失敗しやすい点

• もう動かないコマンドが書かれた指示ファイルは、エージェントにそのファイルを無視するよう教えるだけです。セットアップが変わったら、コマンドを実行し直しましょう。
• レビューボットも自信たっぷりに間違えます。コメントは提案として扱いましょう。

やり方

1. 1チャットに最もよく貼り付けているものを書き出します。たとえばissue、エラーログ、ドキュメント、スキーマです。まずそれらを接続します。
2. 2それぞれについて公式のMCPサーバーを、読み取りしかできないトークンで追加します。Gemini CLIでは、拡張機能にMCPサーバーとその設定をまとめられます。
3. 3それらが必要なタスクを渡し、正しいものが呼び出されたか確認します。
4. 4数週間ごとに、使わなくなったサーバーを削除します。

組み込み機能

• Gemini CLI · Extensions

コピーできるプロンプト

何かを変更する前に：トラッカーでissue [ID]を読み、ログでエラーを見つけ、[ライブラリ名]のドキュメントを確認してください。
それぞれから何がわかったか、どのファイルに原因があると思うかを教えてください。
接続しているツールには何も書き込まないでください。

失敗しやすい点

• ウェブページ、issue、文書には、エージェントを操るために書かれたテキストが含まれていることがあります。外部のコンテンツを読み込むツールには、書き込み権限を与えないでください。
• 設定ファイルに書いたトークンは漏れます。クライアントのシークレット保存機能か環境変数を使い、リポジトリには決して置かないでください。

やり方

1. 1すでに払っているものを確認しましょう。ChatGPTのプランにはCodexが、Claudeの有料プランにはClaude Codeが含まれています。
2. 2エージェントがトークン使用量を表示する場合は、典型的なセッションをいくつか選んでその使用量を記録します。
3. 3その使用量を、このサイトのAPI料金ページで計算し、サブスクリプションと比べます。
4. 4自動化やCIには、利用額の上限を設定したAPIキーを使いましょう。ループで請求額が膨らむのを防げます。

組み込み機能

• ChatGPT · Codex
• Claude · Claude Code

コピーできるプロンプト

典型的なセッション[回数]回分の使用量です：[入力と出力のトークン数]。仕事をするのは週に約[日数]日です。
この価格でトークン単位の月額料金を見積もってください：[API料金ページから貼り付け]。
月額[価格]のサブスクリプションと比べてください。私が確認できるように計算過程を示してください。

失敗しやすい点

• サブスクリプションにも利用上限があります。作業の途中で上限に達すると時間を失います。価格だけでなく上限も確認しましょう。
• 請求額を何よりも大きく左右するのはモデルです。実際に使うモデルで比べましょう。

やり方

1. 1リポジトリで/initを実行します。コードベースを分析して最初のCLAUDE.mdを書くか、既存のものへの改善案を出します。
2. 2ビルドやテストのコマンド、コーディング規約といったチームのルールは./CLAUDE.mdに書いてコミットします。自分の好みは、すべてのプロジェクト用なら~/.claude/CLAUDE.mdに、このプロジェクト用ならCLAUDE.local.mdに書きます。
3. 3長い文書は貼り付けずに参照させましょう。@path/to/fileと書くと、起動時に別のファイルが読み込まれます。
4. 4Claudeが同じことを2回間違えるたびに、それを防げたはずの1行を追加します。

コピーできるプロンプト

このリポジトリを読んで、CLAUDE.mdを改善してください。60行未満に収めてください：
1. ビルド、テスト、リントの正確なコマンド。
2. 構成を数行で。
3. ここで新しく来た人が間違えやすい規約。
4. 決して編集してはいけないファイルとフォルダ。
もう正しくない内容は削除してください。実行していないコマンドには「未検証」と付けてください。

失敗しやすい点

• CLAUDE.mdの内容はすべて毎回のセッションで読み込まれ、コンテキストを消費します。詳細は、CLAUDE.mdから読み込むファイルに移しましょう。
• もう正しくない指示は、指示がないより悪い結果を招きます。セットアップが変わったら、コマンドをもう一度確認しましょう。

公式ドキュメントより： Claude Code docs: How Claude remembers your project

やり方

1. 1ステータスバーにプランモードがオンと表示されるまでShift+Tabを押すか、プロンプトを/planで始めます。
2. 2変更内容と、変えてはいけないことを説明します。計画中もClaudeは調査のためにコマンドを実行することはありますが、ファイルは編集しません。
3. 3計画は設計メモのように読みます。間違ったファイル、抜けているケース、大きすぎる変更がないかを見ます。正しくなるまで修正を頼み、それから承認します。
4. 4次の無関係なタスクの前に、/clearで新しく始めます。

コピーできるプロンプト

/plan [目標]のために[変更対象]を変更してください。制約：[変えてはいけないこと]。
触れるファイル、変更の順序、各ステップを証明するテスト、確信が持てない点を一覧にしてください。私が承認するまで何も編集しないでください。

失敗しやすい点

• 想定より多くのファイルに触れる計画は、警告のサインです。承認する前に理由を尋ねましょう。
• プランモードでも、調査のためにコマンドは実行されます。見慣れないリポジトリを安全に実行できるようになるわけではありません。

公式ドキュメントより： Claude Code docs: Choose a permission mode · Claude Code docs: Commands · Claude Code docs: Best practices

やり方

1. 1/permissionsを開くと、すべてのルールと、それぞれがどの設定ファイルから来ているかがわかります。
2. 2チームのルールは.claude/settings.jsonに書いてコミットします。個人のルールは~/.claude/settings.jsonか.claude/settings.local.jsonに書きます。
3. 3ルールは拒否（deny）、確認（ask）、許可（allow）の順に確認されるので、拒否ルールが1つあれば、どの許可ルールよりも優先されます。
4. 4Shift+Tabでモードを切り替えます。acceptEditsは作業ディレクトリ内のファイル編集を自動で承認します。bypassPermissionsは確認と安全チェックをオフにします。ドキュメントでは、インターネットに接続していない隔離されたコンテナやVMでのみ使うよう書かれています。

コピーできるプロンプト

このセッションで実行したコマンドを見てください。.claude/settings.jsonの権限ルールを提案してください。毎日使う読み取り専用のコマンドとテストのコマンドは許可し、シークレットを読むものやプロジェクト外を削除するものは拒否し、それ以外はすべて確認を求めるようにしてください。各ルールを1行で説明してください。

失敗しやすい点

• どんなコマンドにも一致する許可ルールは、確認がないのと同じです。コマンドは正確に指定して許可しましょう。
• .claude/settings.jsonのルールは、コミットするとチーム全体に適用されます。コードと同じようにレビューしましょう。

公式ドキュメントより： Claude Code docs: Configure permissions · Claude Code docs: Settings files and precedence · Claude Code docs: Choose a permission mode

やり方

1. 1無関係なタスクの合間には、/clearで空のコンテキストから新しい会話を始めます。
2. 2長いタスクでは、焦点を指定した/compact（たとえば「/compact プランと失敗しているテストを残す」）で、それまでの内容を要約します。
3. 3広い範囲の検索はサブエージェントに任せます。サブエージェントはそれぞれ専用のコンテキストウィンドウで動くので、あなたのセッションに戻ってくるのはその答えだけです。
4. 4Claude Codeは上限が近づくと自動でも圧縮します。よいタイミングで自分で圧縮すれば、残すものを自分で選べます。

組み込み機能

• Claude Code · Subagents

コピーできるプロンプト

/compact 残すもの：目標、計画、ここまでに変更したファイル、まだ失敗しているテスト。調査の過程は捨ててください。

失敗しやすい点

• /clearは会話を忘れます。また必要になるものは、先にCLAUDE.mdに書いておきましょう。
• 戻ってくるのはサブエージェントの答えだけです。結論だけでなく、ファイルパスと行番号も求めましょう。

公式ドキュメントより： Claude Code docs: Commands · Claude Code docs: Best practices · Claude Code docs: Create custom subagents

やり方

1. 1各セッションをclaude --worktree <name>（または-w）で始めます。ブランチworktree-<name>上に、.claude/worktrees/<name>/の下にgit worktreeが作られます。
2. 2ドキュメントの推奨どおり、.claude/worktrees/を.gitignoreに追加します。
3. 3各セッションには専用のチェックを付けたタスクを1つずつ渡し、1つずつレビューできるようにします。
4. 4各ブランチは、ほかのプルリクエストと同じようにレビューしてマージします。

コピーできるプロンプト

あなたはブランチworktree-[名前]のworktreeで作業しています。タスク：[1つの変更]。完了の条件：[テストまたはコマンド]が通ること。このブランチにだけコミットし、ほかのブランチをマージやリベースしないでください。

失敗しやすい点

• worktreeはそれぞれ別のフォルダなので、依存関係やビルドの出力は共有されません。それぞれでインストールしましょう。
• 同じファイルに触れる2つのタスクは、worktreeを使っても使わなくても、マージのときに競合します。

公式ドキュメントより： Claude Code docs: Run parallel sessions with worktrees

やり方

1. 1空のプロンプトでEscを2回押すか、/rewindと入力します（/checkpointと/undoも使えます）。
2. 2おかしくなる前の時点を選び、会話、コード、またはその両方を元に戻します。
3. 3限界を知っておきましょう。rm、mv、cpなどのシェルコマンドで変更されたファイルは元に戻りません。Claude Codeの外や別のセッションで行った編集も同様です。
4. 4危険なステップの前にはコミットします。チェックポイントはセッション内ですばやく立て直すためのもので、gitの代わりにはなりません。

コピーできるプロンプト

始める前に、現在の状態を「[タスク]の前のチェックポイント」というメッセージでコミットしてください。それから[タスク]を行ってください。ファイルを削除または移動するコマンドの前には、私に確認してください。

失敗しやすい点

• コマンドが削除したファイルは、rewindでは戻りません。戻せるのはgitだけです。
• その間に手で行った編集も記録されていません。巻き戻す前にコミットしましょう。

公式ドキュメントより： Claude Code docs: Checkpointing · Claude Code docs: Commands

やり方

1. 1claude -p "..."は非対話モードで実行します。--output-format jsonまたはstream-jsonを付けると、スクリプトで解析できる出力になります。
2. 2成功すると0、失敗すると0以外で終了するので、CIでその結果に応じて処理を分けられます。
3. 3ローカルのセットアップに依存しない実行には、CIで--bareを付けます。
4. 4プルリクエストには、/install-github-appでClaude Code GitHub Actionsを設定します（github.comのリポジトリのみ）。その後、プルリクエストやissueのコメントで@claudeにメンションします。

コピーできるプロンプト

claude -p "mainとの差分を読んでください。依存関係を追加する変更、認証に触れる変更、データベースのマイグレーションを変更する変更をすべて、次のJSONで一覧にしてください：{\"files\": [], \"reason\": \"\"}。該当がなければ空のリストを返してください。" --output-format json

失敗しやすい点

• スクリプトは、あなたが与えた権限で動きます。CIには必要最小限の権限だけを与えましょう。
• /install-github-appは、github.com上のリポジトリでしか使えません。

公式ドキュメントより： Claude Code docs: Run Claude Code programmatically · Claude Code docs: GitHub Actions

やり方

1. 1CLIで/initを実行すると、現在のフォルダに最初のAGENTS.mdが書かれます。
2. 2個人的な指針は~/.codex/AGENTS.mdに、プロジェクトのルールはリポジトリに置きます。サブフォルダには専用のファイルを置けます。Codexが作業する場所に近いファイルが優先されます。
3. 3ファイルは短く保ちましょう。合計サイズには上限があり、初期設定では32 KiBです。
4. 4「## Code Review Rules」セクションを追加します。GitHubでのCodexのレビューは、このセクションに従います。

コピーできるプロンプト

このリポジトリを読んで、AGENTS.mdを書いてください：
1. インストール、ビルド、テスト、リントの正確なコマンド。
2. 構成を数行で。
3. ここで新しく来た人が間違えやすい規約。
4. レビューアーが必ず指摘すべきことを書いた「## Code Review Rules」セクション。
実際に実行して成功したコマンドだけを載せ、それ以外には「未検証」と付けてください。

失敗しやすい点

• 長いファイルは逆効果です。合計サイズの上限は、初期設定で32 KiBです。
• ルートのファイルと矛盾しているのにそう書いていないサブフォルダのファイルは、Codexだけでなく人も混乱させます。何を上書きするのかを書きましょう。

公式ドキュメントより： Codex docs: AGENTS.md · Codex docs: CLI commands · Codex docs: GitHub integration

やり方

1. 1CLIでは、/permissionsでモードを切り替え、/statusで現在の承認ポリシーと書き込み可能なフォルダを確認できます。
2. 2推奨の初期設定である「Ask for approval」は、ワークスペース内でファイルを編集しコマンドを実行し、その外に出る前に一時停止します。
3. 3「Approve for me」は同じサンドボックスのまま、承認の依頼をあなたではなく自動レビューに送ります。
4. 4「Full access」はファイルシステムとネットワークの制限をなくします。ドキュメントにも注意書きがあります。使い捨てにできる環境だけで使いましょう。

コピーできるプロンプト

始める前に/statusを実行し、承認ポリシーと書き込み可能なフォルダを教えてください。それから[タスク]を行ってください。ネットワークが必要なコマンドや、このリポジトリの外に書き込むコマンドの前には確認してください。

失敗しやすい点

• 「Approve for me」では、個々の依頼を人が読むことはありません。間違った操作を簡単に取り消せる場面で使いましょう。
• 「Full access」はリポジトリだけでなく、マシン全体に適用されます。

公式ドキュメントより： Codex docs: Permission modes · Codex docs: Sandboxing · Codex docs: Approvals and security · Codex docs: CLI commands

やり方

1. 1codex exec "..."は非対話モードで実行し、初期設定では読み取り専用のサンドボックスを使います。
2. 2ファイルを編集する必要がある場合は--sandbox workspace-writeを付けます。--full-autoは非推奨です。
3. 3--jsonを付けると、すべてのステップが必要なスクリプト向けに、イベントをJSON Lines形式のストリームで出力します。
4. 4GitHub Actionsでは、openai/codex-action@v1がcodex execを実行してくれます。

コピーできるプロンプト

codex exec "タグ[v1.2.0]以降の変更を読んでください。Added、Changed、Fixedに分けてリリースノートを書いてください。変更1つにつき1行、ユーザーにわかる言葉で書き、コミットハッシュは入れないでください。"

失敗しやすい点

• 古いガイドではまだ--full-autoが使われています。これは非推奨なので、--sandbox workspace-writeを使いましょう。
• 読み取りだけのジョブは、CIでも読み取り専用のままにしましょう。

公式ドキュメントより： Codex docs: Non-interactive mode · Codex docs: GitHub Action

やり方

1. 1CLIの/reviewは作業ツリーをレビューします。codex reviewはチャットなしで同じことを行い、ベースブランチ、コミット、未コミットの変更を対象にできます。
2. 2GitHubでは、プルリクエストに@codex reviewとコメントします。
3. 3Codexの設定の「Personal preferences」で自動レビューをオンにすれば、コメントは不要になります。
4. 4チームのルールは、AGENTS.mdの「## Code Review Rules」セクションに書きます。

組み込み機能

• Codex · Codex code review

コピーできるプロンプト

## Code Review Rules
- 認証や権限への変更はすべて指摘する。
- 元に戻す手段のないデータベースのマイグレーションを指摘する。
- 新しい依存関係を指摘し、それが必要かどうかを述べる。
- フォーマットは無視する。リンターが処理する。

失敗しやすい点

• GitHubでのレビューが指摘するのはP0とP1の問題だけです。コメントがないからといって、設計が正しいわけではありません。
• レビューはセカンドオピニオンであって、テストの実行ではありません。テストは残しておきましょう。

公式ドキュメントより： Codex docs: CLI commands · Codex docs: GitHub integration

やり方

1. 1タスクに必要なリポジトリ、依存関係、ツール、アクセス設定を含む環境を作ります。新しい環境には、インストールスクリプトと起動用のスキルが記録されます。
2. 2インターネットへのアクセスは環境ごとに設定します。パッケージマネージャーのみ、選んだドメインのみ、またはすべてです。
3. 3タスクはChatGPTから、長いジョブならIDE拡張機能から、またはターミナルからcodex cloud execで始めます。--attempts 1-4を付けると、比較するための複数回の試行を頼めます。
4. 4Code Review、GitHubとLinearの連携は、まだ旧版のCodex Cloud（Legacy）で動いています。OpenAIはこれを廃止する予定です。

組み込み機能

• Codex · Codex Cloud

コピーできるプロンプト

codex cloud exec --attempts 3 "タスク：[変更内容]。背景：[ファイル]。この環境で[テスト]が通れば完了です。差分は[行数]行未満にしてください。"

失敗しやすい点

• インターネットへのアクセスを制限しないと、タスクはどのサイトにも届きます。タスクを操るために書かれたページも含めてです。ジョブに必要なものだけを許可しましょう。
• インストールスクリプトがなければ、テストが実行されていないかもしれません。タスクが実際にテストを実行したか確認しましょう。

公式ドキュメントより： Codex docs: Cloud environments · Codex docs: CLI commands · Codex docs: IDE extension

やり方

1. 1初期設定のモデルと推論の度合いは、~/.codex/config.tomlで設定します（modelとmodel_reasoning_effort）。CLIとIDE拡張機能で共有されます。
2. 2プロファイルは専用のファイル~/.codex/<name>.config.tomlとして作り、--profile <name>で起動します。
3. 3MCPサーバーはcodex mcp add <name> -- <command>で追加します。それぞれが[mcp_servers.<name>]テーブルになり、/mcpで有効なサーバーの一覧が表示されます。
4. 4/statusで現在有効な設定を確認でき、codex resume --lastでこのフォルダの最新のセッションを再開できます。

コピーできるプロンプト

~/.codex/config.tomlと、このプロジェクトの.codex/config.tomlを読んでください。有効になっているモデル、推論の度合い、サンドボックス、MCPサーバーと、それぞれがどのファイルから来ているか、そして矛盾している点を教えてください。

失敗しやすい点

• プロジェクトの設定は、信頼済みのプロジェクトでしか読み込まれません。設定が無視されているようなら、まずそこを確認しましょう。
• 現在、プロファイルは別々のファイルです。config.tomlの中に[profiles.name]を書くガイドは古くなっています。

公式ドキュメントより： Codex docs: MCP · Codex docs: Config basics · Codex docs: Advanced config · Codex docs: CLI commands