Codexのおすすめ設定。承認、サンドボックス、ブランチ運用
合同会社Leadfive 山下です。
さて、 Leadfiveでは、AIを便利なツールで終わらせず、会社の実務に組み込むAIエージェント運用を発信・支援しています。Codexを触り始めた経営者が最初に迷うのは、何を頼めるかより、どこまで触らせてよいかです。
Codexは、チャットで相談するだけのAIではありません。ファイルを読み、修正し、テストを実行し、必要に応じてGitの作業まで進めます。だから最初の設定は、便利機能のON/OFFではなく、新人スタッフに渡す作業机、金庫の鍵、責任者確認を決める作業だと考えます。
Codexは、新人スタッフに渡す作業机から決めます
最初に決めるのは、Codexが触ってよい場所です。
新人スタッフに会社へ入ってもらう時、いきなり金庫、契約書、顧客名簿、公式SNSの投稿画面まで渡す会社はありません。まず机を用意し、この棚は見てよい、この棚は責任者確認、この鍵は渡さない、と分けます。Codexのサンドボックス設定も同じです。
実務では、最初は「読んでよい」「下書きしてよい」「ローカルで確認してよい」までにします。公開、投稿、本番反映、広告、DB、env、secret、顧客接触は止める。これを最初に決めるだけで、AIに頼める仕事の量は増えます。怖いから使わないのではなく、怖い場所を先に閉じるから使えるようになります。
Codexの始め方と最初に設定すべきポイントを読んだ後なら、この記事は次の実務設定として読む位置づけです。
サンドボックスは、作業範囲を区切る事務所の部屋です
サンドボックスは、Codexが作業できる範囲を区切る仕組みです。
会社でたとえるなら、来客スペース、作業部屋、金庫室を分けることです。Web記事の下書き、画像案、ローカル確認は作業部屋で進めてよい。一方で、本番サイトの公開、広告管理画面、請求情報、顧客データは金庫室です。AIが便利でも、金庫室の鍵は別管理にします。
最初のおすすめは、次の分け方です。
- read-only: 調査、レビュー、ファイル確認
- workspace-write: 下書き作成、ローカル修正、テスト実行
- approval required: 外部通信、Git push、本番反映、投稿、削除
- never: secret、
.env、APIキー、顧客データ、請求情報
この分類は技術者だけの話ではありません。経営者が「AIに任せてよい仕事」と「責任者が止める仕事」を社内で共有するための言葉です。
承認ゲートは、金庫の鍵を渡さないための責任者確認です
承認ゲートは、AIが次に進む前に人が確認する場所です。
Codexは作業が速いので、設定が緩いと、下書き、修正、公開準備まで一気に進みます。これは便利ですが、公開ボタン、SNS投稿、広告設定、顧客連絡まで同じ流れで進めると危険です。新人スタッフが請求書の下書きを作れることと、銀行振込を実行してよいことは別です。
Leadfiveでは、次の操作はAI単独で実行しない前提にしています。
- 記事公開、予約公開、本番反映
- X、Threads、Instagram、YouTubeなどの投稿や返信
- 広告配信、予算、タグ、GA4、GTM、リマーケティング設定
- DB、env、secret、Webhook、DNS、決済まわり
- 顧客接触、契約、価格提示
Codexに任せるなら、最初の指示にこの境界を書きます。「ここまでは進めてよい」「ここから先は下書きで止める」と明記します。Codex RemoteでスマホからAI作業を承認する方法も、同じ承認ゲートの考え方です。
AGENTS.mdは、Codexに渡す入社初日の業務マニュアルです
Codexを使うなら、AGENTS.mdを先に整えます。
AGENTS.mdは、AIに毎回口頭で説明しないための業務マニュアルです。会社の禁止事項、文体、保存先、検証方法、承認境界を書きます。AIに「いい感じにやって」と頼むのではなく、「この会社では、この作業はここで止める」と渡します。
最初のAGENTS.mdには、難しい技術ルールを大量に入れる必要はありません。経営者向けには、まず次の5つで十分です。
- どの言語とトーンで返すか
- 触ってよいフォルダと触らないフォルダ
- 公開、投稿、送信、削除、本番反映の承認ルール
- 秘密情報と顧客情報を表示しないルール
- 変更後に何で確認するか
詳しい考え方は、AGENTS.mdはAIに渡す会社の業務マニュアルで整理しています。
ブランチ運用は、店頭を変える前の裏方作業です
本番ユーザーがいるサイトやアプリでは、Codexの作業はブランチで分けます。
店舗でたとえるなら、営業中の店頭で棚を動かさず、裏で新しい陳列を組んでから責任者が確認する流れです。Gitのブランチも同じです。mainやmasterを直接触るのではなく、作業用ブランチで下書き、修正、テスト、レビューを行います。
中小企業のWebサイト更新でも、この考え方は役に立ちます。文章の差し替え、画像の追加、内部リンクの変更は小さく見えますが、公開サイトでは売上導線に影響します。Codexに任せるなら、次の順にします。
- 作業ブランチで変更する
- ローカルで表示確認する
- 差分をレビューする
- 公開前チェックを通す
- 人が承認してから本番へ反映する
GitHubの保護ブランチ設定も、同じ考え方です。店頭を勝手に変えないための責任者確認です。
最初の依頼文は、作業内容より停止条件を先に書きます
Codexへの最初のプロンプトでは、何をしてほしいかと同じくらい、何をしないかを書きます。
そのまま使える依頼文です。
あなたは当社のAI作業担当です。
目的:
指定したブログ記事またはWebページの改善案を作り、必要な下書きと確認リストを作成してください。
進めてよいこと:
- リポジトリ内の公開用ファイルを読む
- 下書きファイルを作る
- ローカルで確認できる範囲のチェックをする
- 変更案と検証結果を報告する
止めること:
- 本番公開、予約公開、SNS投稿、広告変更はしない
- git push、デプロイ、DB、env、secret、顧客データには触れない
- 未公開URLを本文リンクに入れない
完了条件:
1. 変更内容
2. 確認したこと
3. 未確認のこと
4. 人間が承認すれば次に進める操作
を報告してください。
この依頼文の狙いは、Codexの能力を制限することではありません。AIが迷わず進める範囲を先に作ることです。
今日の作業: Codexに渡す5つの初期設定を書き出します
Codexを導入する前に、ツールの使い方を覚えるより先に、会社側のルールを1枚にします。
書き出すのは次の5つです。
- AIに任せたい最初の仕事
- AIが読んでよいファイル
- AIが作ってよい下書き
- 人間承認で止める操作
- 変更後に確認する方法
この5つが決まると、Codexはただの便利なチャットではなく、会社の中で動ける新人スタッフになります。最初から大きな仕事を任せる必要はありません。まずはブログ下書き、公開前レビュー、議事録整理、Webページの誤字修正のように、止める場所が明確な仕事から始めるのが現実的です。
よくある質問
Codexに最初から本番サイトを触らせてもいいですか
最初は避けた方が安全です。作業ブランチ、ローカル確認、レビュー、承認の順に分けます。
AGENTS.mdがあれば承認は不要ですか
不要にはなりません。AGENTS.mdは業務マニュアルで、承認ゲートは責任者確認です。
小さい会社でもブランチ運用は必要ですか
公開サイト、広告導線、問い合わせ導線に関わるなら必要です。規模ではなく、失敗した時の影響で決めます。
出典
-
[Codex OpenAI Developers](https://developers.openai.com/codex/) -
[Codex changelog OpenAI Developers](https://developers.openai.com/codex/changelog/) -
[Managing a branch protection rule GitHub Docs](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches)
このシリーズの順番
Codexに触らせてよい範囲と人が止める操作を整理できる。次の作業は、承認、サンドボックス、ブランチ運用を1枚に書き出すことです。