Codex Automationsを業務に使うとき、最初に見るべきなのは便利な機能ではありません。
どこで作業させるか。どこまでファイルを触らせるか。いつ承認を求めるか。画面操作を許すか。失敗したときにどう戻すか。
ここを決めずに自動化すると、便利になる前に怖くなります。
逆に、作業場所と権限を絞れば、Codexは中小企業でも現実的な業務補助になります。
Codexの作業場所は1つではない
OpenAIのCodex app docsでは、スレッドのモードとしてLocal、Worktree、Cloudが説明されています。
Localは現在のプロジェクトで直接作業します。WorktreeはGit worktreeで変更を分離します。Cloudは設定されたクラウド環境で作業します。
中小企業の実務では、最初から広い範囲で動かす必要はありません。
まずは、作業対象が明確なディレクトリ、確認用のブランチ、または分離されたworktreeで始めます。
Local、Worktree、Cloudの使い分け
Localが向く作業
Localは、手元のプロジェクトを見ながら小さな修正や確認をするのに向いています。
- 文章の修正
- チェックコマンドの実行
- 既存ファイルの確認
- 小さな差分の作成
ただし、現在の作業ツリーに直接触るため、未コミット変更が多いと混ざりやすくなります。使う前に、何を触ってよいかを決めます。
Worktreeが向く作業
Worktreeは、変更を分けたいときに向いています。
- 新しい記事案を試す
- 大きめの修正を分離する
- 並行作業を混ぜたくない
- 失敗時に戻しやすくしたい
Codexに「試してよいが、既存作業と混ぜたくない」仕事を頼むなら、Worktreeの方が安全です。
Cloudが向く作業
Cloudは、ローカルPCに依存しない形で作業したい場合に候補になります。
ただし、環境変数、外部サービス接続、秘密情報、デプロイ権限の扱いは慎重に設計します。クラウドで動くから安全なのではなく、権限を絞って初めて安全になります。
サンドボックスは「信用しないため」ではなく「任せるため」にある
OpenAIのCodex sandboxing docsでは、一般的なサンドボックスモードとして、read-only、workspace-write、danger-full-accessが説明されています。
大事なのは、強い権限ほど便利で、同時にリスクも高いということです。
最初の自動化では、広い権限を与える必要はありません。
- 読むだけなら read-only
- 作業ディレクトリ内で確認・修正するなら workspace-write
- 制限なしの操作が必要なら danger-full-access
ただし、danger-full-accessは、ファイルシステムやネットワークの境界を外す設定です。定期実行や初期運用で使う前に、本当に必要かを確認します。
承認ポリシーは業務リスクに合わせる
Codexでは、どのタイミングで承認を求めるかも重要です。
中小企業の初期運用では、次の考え方が現実的です。
- 読み取り、検索、差分確認は自動でよい
- ファイル編集は対象ディレクトリを限定する
- 外部公開、削除、送信、pushは承認制にする
- ネットワーク利用や外部APIアクセスは必要時だけ許可する
- 秘密情報が絡む作業は自動化しない
承認が多すぎると自動化の意味が薄れます。
しかし、承認が少なすぎると、失敗したときの影響が大きくなります。だから、業務ごとに「自動でよい操作」と「人間が止める操作」を分けます。
Computer Useは便利だが、最初から常用しない
CodexのComputer Useは、GUIアプリやブラウザを見て、クリックや入力を行うための機能です。公式docsでも、コマンドラインや構造化された連携だけでは足りないときに使うものとして説明されています。
これは強力ですが、扱いには注意が必要です。
画面上の情報、ブラウザ、開いているアプリ、クリップボード、入力内容が作業対象になります。Windowsでは前面のデスクトップを操作するため、作業中に人間の操作と衝突する可能性もあります。
最初は、Computer Useを常用するより、ファイル、コマンド、構造化されたAPIやMCPで済む処理を優先します。
どうしても画面操作が必要な場合だけ、対象アプリを1つに絞り、認証や決済や顧客情報が絡む画面を避けます。
自動化前のチェックリスト
Codex Automationsを業務に入れる前に、次を確認します。
- 作業場所はLocal、Worktree、Cloudのどれか
- 変更を混ぜたくない場合はWorktreeにするか
- サンドボックスはread-onlyかworkspace-writeで足りるか
- danger-full-accessが本当に必要か
- 外部公開、削除、送信、pushは承認制になっているか
- 秘密情報や顧客情報を読ませない設計か
- Computer Useが必要な理由は明確か
- 失敗時に戻せるGit状態か
- 実行結果を誰がレビューするか
このチェックがない自動化は、速いだけで危険です。
このチェックがある自動化は、少人数の会社でも使える業務基盤になります。
最初の推奨構成
中小企業で始めるなら、最初は次の構成が扱いやすいです。
- 作業場所: Worktreeまたは対象を絞ったLocal
- サンドボックス: workspace-write
- 承認: 外部公開、削除、push、ネットワーク利用は確認
- Computer Use: 原則使わず、必要なときだけ対象アプリを限定
- 成果物: 実行結果レポート、修正案、差分
- 人間の役割: 採用判断、公開判断、顧客送信、最終責任
この形なら、Codexに任せる範囲を広げながら、事故の起きやすい操作は人間が持てます。
まとめ
Codex Automationsを安全に使うには、機能を覚える前に、作業場所と権限を決める必要があります。
Local、Worktree、Cloud。read-only、workspace-write、danger-full-access。承認ポリシー。Computer Useの扱い。
これらは細かい設定ではなく、業務自動化の境界線です。
AI活用をどこから始めるべきか迷っている場合は、まず AI活用診断 で、既存業務のどこがAIパッケージ化しやすいかをご確認ください。導入支援を具体的に検討する段階では、スポット相談チケットで対象業務と次の進め方を整理できます。
関連する有料note
Codexの権限・作業場所・承認ポリシーを実務で決める前に、noteの有料記事 Codexを業務で使う前に決める停止条件 に判断基準をまとめています。
read-only、workspace-write、danger-full-accessの違いを、社内運用の停止条件として整理したい方向けです。
関連記事
- Codexを業務で使う前に:中小企業が決めるべき5つのルール
- AIエージェントを安全に使うには:中小企業が先に決める5つの境界線
- AIコーディングの初手はコードではない:質問・用語・ADRで手戻りを減らす