Codex CLIを実務で使うなら押さえておきたい、変更管理系スラッシュコマンド5選

はじめに

Codex CLIを使うと、ターミナル上でAIにコード修正や調査を依頼できます。

ただ、実務で使っていると、単に「コードを書いてもらえる」だけでは不十分だと感じる場面があります。

例えば、以下のような場面です。

• 今どのモデルで動いているのか分からない
• 利用上限にどれくらい近づいているのか分からない
• AIがどのファイルを変更したのか把握しきれていない
• レビュー前に確認すべき論点が整理できていない
• プロジェクト固有のルールがAIに伝わっていない

AIに作業を任せるほど、最終的には「その変更を自分が説明できるか」が重要になります。

この記事では、Codex CLIのスラッシュコマンドの中でも、実務で使う上で特に変更管理に効くと感じたものを5つ整理します。

対象読者

この記事は、以下のような方を想定しています。

• Codex CLIを使い始めた方
• AI駆動開発を実務に取り入れたい方
• AIが生成した差分をどう確認するか悩んでいる方
• チーム開発でCodex CLIを使う前提を整理したい方

スラッシュコマンドとは

Codex CLIでは、入力欄で / を入力するとスラッシュコマンドを実行できます。

通常のプロンプトでAIに依頼するのとは別に、モデルの切り替え、状態確認、差分確認、レビュー依頼などをコマンドとして呼び出せます。

今回は、以下の5つを扱います。

コマンド	主な用途
/status	実行前提と利用上限を確認する
/model	品質・速度・使用量のトレードオフを切り替える
/diff	生成された変更を採用できる粒度まで分解する
/review	人間のレビュー前に論点を洗い出す
/init	プロジェクト固有の制約をAIに渡せる形にする

/status：実行前提と利用上限を確認する

/status は、現在のCodex CLIの状態を確認するためのコマンドです。

実務で使う場合は、単に「今の状態を見る」だけではなく、作業前に実行前提を揃えるために使います。

特にチーム契約で利用している場合は、5h limit や 1week limit もここで確認できます。

重めの設計相談やレビューを依頼する前に利用状況を見ておくと、途中で上限に近づいてモデル選択を変える、作業を分割する、といった判断がしやすくなります。

確認したい観点は以下です。

• 現在使用しているモデル
• 承認モード
• 作業ディレクトリ
• セッション情報
• 5h limit
• 1week limit

AI駆動開発では、どの前提で生成・修正が行われているかを把握しておくことが重要です。

例えば、同じ依頼内容でも、使用しているモデルや承認モードによって、修正の粒度や実行範囲が変わる可能性があります。

そのため、実装に入る前や大きめの変更を依頼する前に、まず /status で現在の状態を確認しておくと、後から差分を追いやすくなります。

/model：品質・速度・使用量のトレードオフを切り替える

/model は、Codex CLIで使用するモデルを切り替えるためのコマンドです。

実務では、モデル選択を単なる好みではなく、品質・応答速度・トークン使用量のバランスを決める判断として扱った方がよさそうです。

基本的には、最新・高性能なモデルに近づくほど、1回のラリーで消費するトークン量が増えやすくなります。

一方で、mini系のモデルは軽く、応答も速く、使用量も抑えやすいです。

ただし、複雑な設計判断や既存コードの文脈理解では、出力の品質が落ちる可能性があります。

そのため、すべての作業を同じモデルで行うのではなく、作業内容に応じて切り替えるのが現実的です。

例えば、軽微な文言修正や単純な置換であればmini系でも十分な場合があります。

一方で、以下のような作業では、品質を優先したモデルを選ぶ方が安全です。

• 既存設計への影響確認
• 責務分離の判断
• DBアクセスまわりの変更
• 認可・権限まわりの変更
• 例外設計
• PR前のレビュー

モデル選択は、性能比較というより「間違えたときの影響範囲」に応じたリスク管理だと感じました。

個人的には、以下のように使い分けると考えやすいです。

作業内容	モデル選択の考え方
文言修正	軽いモデルで十分な場合がある
単純な置換	速度と使用量を優先しやすい
既存コードの調査	文脈理解を重視したい
設計相談	品質を優先したい
レビュー	観点漏れを減らすため品質を重視したい

もちろん、mini系のモデルが悪いという話ではありません。

軽い、早い、使用量が少ないというメリットは大きいです。

ただし、複雑な判断を任せる場合は、出力の妥当性を人間側でより慎重に確認する必要があります。

/diff：生成された変更を採用できる粒度まで分解する

/diff は、Codexが変更した差分を確認するためのコマンドです。

AI駆動開発で怖いのは、コードが動かないことだけではありません。

目的の修正に見えて、実際には意図していない整形、命名変更、責務の移動、例外処理の変更が混ざることがあります。

そのため、/diff は単なる差分確認ではなく、変更を採用できる粒度まで分解するために使います。

見たい観点は以下です。

• 依頼した変更以外が混ざっていないか
• 整形差分とロジック差分が分かれているか
• 既存の責務分離を崩していないか
• エラー処理や戻り値の意味が変わっていないか
• レビューで説明できない変更が残っていないか

特にAIに修正を任せると、良かれと思って周辺コードまで触ることがあります。

その変更が本当に必要であれば残します。

ただ、説明できない差分であれば、戻した方がレビューしやすくなります。

例えば、バグ修正を依頼しただけなのに、同時に関数名の変更やファイル分割まで入っていると、レビュー時に本質的な変更が見えにくくなります。

その場合は、以下のように分けて考えます。

• 今回の修正に必要な差分
• 今回の修正には不要だが、別PRで検討できる差分
• 意図していないため戻す差分

/diff は、AIの作業結果を人間が引き取るための境界線として使うイメージです。

AIに修正を依頼すること自体は便利ですが、最終的にマージされるのは「AIが作ったコード」ではなく「自分が採用した差分」です。

/review：人間のレビュー前に論点を洗い出す

/review は、現在の変更内容をレビューしてもらうためのコマンドです。

ただし、実務では「AIにレビューしてもらえば安心」とは考えない方がよさそうです。

AIが生成したコードをAIにレビューさせる場合、同じ前提や見落としを引きずる可能性があります。

そのため、/review は正解を出してもらうためではなく、人間が確認すべき論点を増やすために使います。

例えば、以下のような観点です。

• 境界値の考慮が漏れていないか
• 異常系が握りつぶされていないか
• 不要な抽象化が増えていないか
• 既存設計と責務がズレていないか
• テスト観点が実装に寄りすぎていないか
• 影響範囲に対して修正が大きすぎないか
• ログやエラーメッセージに不要な情報が出ていないか

最終判断は開発者が持つ前提で、PRを出す前のセルフレビュー補助として使うのが現実的です。

AIレビューの結果をそのまま採用するのではなく、「自分が見るべき観点が増えたか」を基準にすると使いやすいです。

個人的には、/review を実行した後に、指摘を以下のように分類すると整理しやすいと感じました。

分類	判断
修正する	明らかに不具合や設計上の問題がある
保留する	今回のスコープ外だが、別途検討したい
採用しない	前提が違う、または既存方針と合わない

AIのレビュー結果も、最終的にはレビュー対象のひとつです。

指摘されたから直すのではなく、なぜ直すのか、なぜ直さないのかを説明できる状態にしておくことが重要だと思います。

/init：プロジェクト固有の制約をAIに渡せる形にする

/init は、Codex向けの指示ファイルである AGENTS.md を作成するためのコマンドです。

Codexに「既存実装に合わせて」と伝えても、プロジェクト固有の判断基準までは安定して伝わらない場合があります。

例えば、以下のような情報です。

• 命名規則
• 責務分離の方針
• エラーハンドリングの方針
• テスト実行方法
• 使ってよいライブラリ
• 避けたい実装パターン
• レビュー前に確認してほしい観点

こうした暗黙知を AGENTS.md に寄せておくと、Codexの出力をプロジェクトの制約に近づけやすくなります。

重要なのは、AIに良いコードを書かせることだけではありません。

プロジェクトの前提から外れたコードを出しにくくすることも、実務でAIを使う上では重要です。

例えば、以下のような内容を書いておくと、毎回プロンプトで説明する手間を減らせます。

# Coding Rules

- 変数名は意味が分かる名前にする
- 三項演算子は使わない
- 既存の責務分離を崩さない
- 不要なリファクタリングを同時に行わない
- 修正後は差分を確認する
- テストが必要な変更では、確認観点も合わせて説明する

もちろん、AGENTS.md に書いたからといって、必ずその通りに出力されるとは限りません。

ただ、プロジェクトの前提や判断基準を明文化しておくことで、少なくともAIに渡す情報のブレは減らせます。

/init は、AIへの指示を毎回プロンプトに書くのではなく、チームやプロジェクトの判断基準として残すための入口だと考えると使いやすいです。

5つのコマンドをどう使うか

今回紹介した5つは、単体で覚えるよりも、作業の流れとして考えると使いやすいです。

例えば、以下のような流れです。

/status で現在のモデルと利用状況を確認する
↓
/model で作業内容に合うモデルを選ぶ
↓
Codexに調査や修正を依頼する
↓
/diff で意図しない差分がないか確認する
↓
/review でレビュー前の論点を洗い出す
↓
必要に応じて AGENTS.md を見直す

AI駆動開発では、コード生成そのものよりも、生成された結果をどう扱うかが重要になります。

特にチーム開発では、AIが出した変更であっても、レビューに出す時点では自分の変更として説明する必要があります。

そのため、以下の観点を持っておくと安心です。

• どの前提でAIが動いているか
• どのモデルで生成されたか
• どの差分を採用するか
• どの指摘を修正するか
• どのプロジェクトルールに従わせるか

このあたりを曖昧にしたまま進めると、後から差分の意図を説明しづらくなります。

まとめ

Codex CLIのスラッシュコマンドは、便利機能として覚えるよりも、AIに任せた作業を開発者が管理するための道具として見ると使いやすいです。

今回紹介した5つは、以下の役割で整理できます。

コマンド	役割
/status	実行前提と利用上限を確認する
/model	品質・速度・使用量を切り替える
/diff	採用する差分を見極める
/review	レビュー前に論点を増やす
/init	プロジェクトの制約を明文化する

AI駆動開発では、コードを書く速度だけでなく、どの前提で生成され、どの差分を採用し、どの判断を人間が持つのかを明確にすることが重要だと感じました。

特に /status、/model、/diff は、日常的に使うだけでも作業の見通しがかなり変わります。

AIに任せる範囲が広がるほど、開発者側には「出てきたものを採用する責任」が残ります。

Codex CLIのコマンドは、その責任を持つための確認手段として使うのがよさそうです。

この記事は個人の経験や調査内容をまとめたものであり、内容の正確性を保証するものではありません。