Codex CLIは業務開発でどう使うか

はじめに

Codex CLIを入れると、調査、差分作成、テスト追加、PR説明までを同じ作業ログで追いやすくなる。

ターミナルで「この不具合を調べて」「テストを足して」「この仕様を読んで実装して」と頼める。起動した作業ディレクトリ配下を中心に読めるし、差分も作れる。OpenAIの公式ページでも、ローカルのターミナルで動くコーディングのエージェントとして説明されている。

ただ、業務で使うときの論点は「インストールできるか」ではない。

本当に詰まるのは、何を任せるか、どこで止めるか、どの仕様を正として読ませるかだ。ここを決めずに入れると、便利な個人ツールで終わる。チーム開発に効かせるなら、最初に実行境界を設計した方がいい。

Codex CLIで最初に見るべき論点

使い方を検索すると、セットアップ、コマンド、モデル、サンドボックス、AGENTS.md、MCPなどが並ぶ。どれも大事だ。だが、業務導入で最初に見るべきなのはコマンド一覧ではない。

先に見るのは、この3つだ。

• Codexに読ませる範囲
• Codexに変更させる範囲
• 人間の承認に戻す範囲

OpenAIのCodex CLI公式ページでは、選択したディレクトリ内のコードを読んだり、変更したり、コマンドを実行したりできると説明されている。つまり、ただのチャットではない。作業者だ。

作業者として扱うなら、権限の線引きが要る。

たとえば、初回導入では「読むのは起動した作業ディレクトリ配下、必要な追加ディレクトリは明示する、書くのは作業用の差分内、外部送信や本番反映は不可」くらいに切る。これだけで、任せられる仕事と任せてはいけない仕事が見える。

普通のAIコーディング記事だけでは足りない

個人開発ならすぐ試せる。`codex`を起動して、対象リポジトリで質問すればいい。OpenAIのCLIリファレンスにも、対話モード、`exec`、sandbox、approvalなどの選択肢が整理されている。

ところが、チーム開発では「使えた」で終わらない。

たとえば、次のような場面がある。

• 仕様が古いまま実装を頼んでしまう
• テストを通したが、業務条件の例外が抜ける
• 既存の設計方針と違う抽象化を入れる
• 外部APIや本番データに触る操作まで進みそうになる
• レビュー担当が、AIの判断理由を追えない

ここで必要なのは、プロンプトのうまさよりも作業設計だ。

業務で使うなら、タスクを「調査」「設計差分」「実装」「テスト」「レビュー」に分ける。いきなり「この機能を全部作って」ではなく、「既存仕様との差分を列挙して」「影響範囲を3ファイル単位で出して」「テストだけ先に提案して」と切る。

この粒度にすると、人間がレビューしやすい。Codexも迷いにくい。

AGENTS.mdはプロンプトではなく作業規約

チームに入れるなら、AGENTS.mdを後回しにしない方がいい。

OpenAIのAGENTS.mdガイドでは、Codexが作業前にAGENTS.mdを読み、プロジェクト固有の期待値や手順を参照すると説明されている。これは単なる便利メモではない。チームの作業規約をAIに渡す場所だ。

AGENTS.mdに入れるべきなのは、抽象的なスローガンではない。

• テストの実行コマンド
• 触ってよいディレクトリ
• 変更前に読むべき設計ファイル
• UIやAPIの既存パターン
• PR前に確認する項目
• やってはいけない操作

このあたりを短く書く。

特に効くのは「やってはいけない操作」だ。たとえば、認証情報を表示しない、本番データを書き換えない、既存のユーザー変更を勝手に戻さない、外部送信は承認を取る。こうした線を先に置くと、AIはチームの前提を読みやすくなる。

AIに毎回同じ注意を口頭で伝えるのは、人間側の運用が重い。AGENTS.mdに寄せると、注意が属人化しにくい。

sandboxとapprovalは開発速度の敵ではない

使い始めると、承認確認が面倒に見える瞬間がある。

でも、業務開発ではここを雑にしない方がいい。OpenAIのAgent approvals & securityでは、sandbox modeとapproval policyを分けて考える。sandboxは技術的に何を許すか、approvalはどの操作で人間確認を求めるかだ。

この分け方は、そのまま開発チームの運用に使える。

速度だけを見れば、全部許した方が速い。だが、後から差分の意味を追えなくなると、レビュー時間で負ける。

開発現場で大事なのは、AIを速く走らせることだけではない。安全に止まれる形で走らせることだ。

実務で使うなら5つの仕事に分ける

業務開発に入れるなら、最初から大きな自動化を狙わなくていい。むしろ、次の5つに分けた方が定着しやすい。

1. コード読解

既存コードの責務、呼び出し関係、設定値の流れを説明させる。新しく入ったメンバーのオンボーディングにも使える。

ここでは変更を入れない。読むだけにする。まずは「この機能の入口はどこか」「このAPIの認可はどこで見ているか」と聞く。

2. 影響範囲の洗い出し

仕様変更を渡し、触る可能性があるファイル、テスト、画面、APIを列挙させる。

ここで便利なのは、実装前に論点が出ることだ。要件定義や設計の抜けがあれば、コードに入る前に戻せる。

3. 小さな実装

影響範囲が見えたら、1つの関心ごとに絞って実装させる。UI、API、テストを一度に広げすぎない。

「この関数だけ」「このバリデーションだけ」「このテストケースだけ」と切る。小さい差分はレビューできる。大きすぎる差分は、AIでも人間でも危ない。

4. テストとレビュー

このツールには、実装だけでなくレビューやテスト観点の洗い出しを任せたい。

たとえば、差分を読ませて「境界値」「権限」「例外」「既存仕様との矛盾」を見る。人間レビューの前にAIレビューを挟むと、単純な抜けを減らせる。

ただし、最終レビューは人間が持つ。AIレビューは決裁者ではなく、レビュー前の検査役だ。

5. 作業ログの整理

最後に、何を変えたのか、なぜ変えたのか、未解決点は何かを整理させる。

このログがあると、PR説明や次のタスクに接続しやすい。特にAIが入る開発では、結果だけでなく判断の履歴を残すことが効く。

MCPや設定は「接続先を増やす前」に絞る

MCPで外部ツールやドキュメントに接続できる。OpenAIのMCPガイドでも、CodexがCLIやIDE拡張でMCPサーバーを扱えると説明されている。

ただ、接続先を増やすほど良いわけではない。

業務利用では、まず「読むための接続」と「実行するための接続」を分ける。ドキュメントを読むMCPと、外部サービスを書き換えるMCPはリスクが違う。読むだけなら許せる場面でも、書き込みは承認が必要になる。

ここを混ぜると、AIが便利になるほど怖くなる。

最初の設計では、接続先を3種類に分けると扱いやすい。

• 参照だけ: 公式ドキュメント、社内仕様、設計書
• 下書きまで: Issue案、PR説明、テスト案
• 実行あり: GitHub更新、外部API、デプロイ、送信

この分類があると、AIに何を渡してよいか判断しやすい。

導入前のチェックリスト

チームで使う前に、次の5点だけは確認しておきたい。

1. AGENTS.mdにテスト、設計、禁止操作が書かれているか
2. sandboxとapprovalの初期方針が決まっているか
3. 外部ネットワークや外部サービス書き込みの承認境界があるか
4. 1タスクの差分をレビューできる大きさに切っているか
5. 作業ログと未解決点をPRやタスクに残す流れがあるか

この5つがない状態で使うと、強い個人ツールにはなる。でも、チームの開発プロセスには乗りにくい。

逆にここが決まると、単なる「コードを書いてくれるAI」ではなくなる。仕様を読み、差分を作り、テストを出し、レビュー前の論点を整理する開発メンバーに近づく。

SIerや受託開発の現場では、ここにもう一段の前提が乗る。顧客合意済みの要件、基本設計書の版、レビュー証跡、変更履歴をどの順番で読ませるかだ。AIに任せる前に正本を決めておかないと、実装は速くても合意のない差分が増える。

Atsumellの視点

株式会社Atsumellが見ているのは、AIを入れた後の開発速度だけではない。AIが読む仕様、AIが触ってよい範囲、人間に戻す境界まで含めた開発プロセスだ。

Codex CLIを業務開発で使うなら、最初に整えるべきなのはプロンプト集ではない。仕様と実行境界だ。何を正として読ませるか。どの差分なら任せるか。どの操作で止めるか。この3つが決まると、AIコーディングはレビューできる仕事へ変わる。

Kakusillは、要件定義や設計ドキュメントをAIが理解できる構造に正規化するプロダクトだ。Codex CLIのようなAI開発ツールを活かすにも、手前にある仕様の粒度と判断履歴が効いてくる。

もし「AIコーディングを入れたが、レビューや仕様確認で結局詰まる」という状態なら、ツールの使い方だけでなく、AIに渡す仕様の形から見直した方がいい。Atsumellでは、AIに読ませる要件・設計・運用境界の整理から、開発現場への組み込みまで支援している。

関連記事

• 【第2部】サーバーにCLIを上げるAI実行基盤の設計
• 【第3部】CLI互換とワーカープールで並行実装を回す
• バイブコーディングをチームで使う前に決めるレビュー責任