─ NOW LOADING ─
─ NOW LOADING ─
Codex CLIを使い始めると、最初に迷いやすいのがスラッシュコマンドです。
スラッシュコマンドとは、Codex CLIの入力欄で/から始めて実行する操作コマンドです。通常の文章で依頼するのではなく、Codexの状態確認、モデル変更、作業計画、差分確認、レビュー、会話整理、作業再開などをすばやく行うために使います。
Codex CLIには複数のスラッシュコマンドがありますが、Web制作・WordPress修正・フロントエンド開発・小規模アプリ開発で最初に覚えるべきものは、まず次の7つです。
まず覚える7つ
/status、/model、/plan、/diff、/review、/compact、/resume
この7つを使えるようになると、Codex CLIの作業はかなり安定します。
特に重要なのは、作業前に状態を確認し、実装前に計画を立て、実装後に差分とレビューを確認することです。
人間の開発作業でも、いきなり本番コードを書き換えるのは危険です。Codex CLIでも同じです。AIに任せるほど、作業の入口と出口を人間側で管理する必要があります。
注意：Codex CLIのコマンド名や表示項目は、バージョンや利用環境によって変わる場合があります。
この記事では、実務で使いやすい基本操作として7つのコマンドを解説します。実際の画面で表示されるコマンド一覧は、Codex CLI上で/を入力して確認してください。
スラッシュコマンドとは、Codex CLIの入力欄で/から始めて実行する専用操作です。
通常のプロンプトは、例えば次のように入力します。
このWordPressテーマのトップページを修正してください。一方、スラッシュコマンドは次のように入力します。
/statusこれは「コードを修正してほしい」という依頼ではなく、Codex CLIの操作や状態変更を行う命令です。
| 種類 | 入力例 | 目的 |
|---|---|---|
| 通常の依頼 | このCSSを修正してください |
Codexに作業内容を伝える |
| スラッシュコマンド | /status |
Codex CLIの状態確認や操作を行う |
つまり、通常の文章は「作業依頼」、スラッシュコマンドは「操作ボタン」に近いものです。
| コマンド | 主な役割 | 使うタイミング |
|---|---|---|
/status |
現在のモデル、権限、作業状態を確認する | 作業開始前、挙動がおかしい時 |
/model |
使用モデルや推論強度を変更する | 作業内容に応じて精度や速度を調整する時 |
/plan |
実装前に作業計画を作らせる | 大きな修正、複雑な修正、事故を避けたい時 |
/diff |
変更差分を確認する | Codexがファイルを変更した後 |
/review |
変更内容をレビューさせる | 実装完了後、コミット前、納品前 |
/compact |
長くなった会話を要約する | 会話が長くなった時、精度低下を感じた時 |
/resume |
過去の作業セッションを再開する | 前回の続きを作業する時 |
実務での優先度
/status/plan/diff、/review/compact/resume/model/status現在のCodex CLIの状態を確認するコマンド
/statusは、Codex CLIで作業を始める前に確認しておきたい基本コマンドです。
Codex CLIでは、モデル、推論強度、作業ディレクトリ、権限設定、サンドボックス、MCP接続などによって、できることが変わります。
たとえば、同じ「修正してください」という依頼でも、現在の設定が読み取り専用に近い状態であれば、ファイル編集ができない場合があります。また、作業ディレクトリが想定と違っていれば、別のプロジェクトを見ている可能性があります。
その確認に使うのが/statusです。
| 確認項目 | 見る理由 |
|---|---|
| 使用中のモデル | 想定しているモデルで作業しているか確認するため |
| 推論強度 | 軽作業向けか、複雑な作業向けかを確認するため |
| 作業ディレクトリ | 正しいプロジェクトフォルダを見ているか確認するため |
| 権限設定 | ファイル編集やコマンド実行の許可範囲を確認するため |
| コンテキスト使用量 | 会話が長くなりすぎていないか確認するため |
| MCP接続 | Serenaなど外部ツールが有効か確認するため |
/status作業前に/statusを実行すると、今の環境が見えます。
特に初心者のうちは、何かがおかしいと感じた時に原因をコード側だけで探しがちです。しかし、実際にはモデル設定、作業フォルダ、権限設定が原因であることもあります。
実務上の使い方
Codex CLIで作業を始めたら、まず/statusを実行する。
これだけで、作業フォルダ違い、モデル違い、権限不足などの初歩的な事故を減らせます。
/model使用するモデルや推論強度を切り替えるコマンド
/modelは、Codexにどのモデルで考えさせるか、どの程度深く推論させるかを変更するためのコマンドです。
Codex CLIでは、作業内容によって必要な推論の深さが変わります。
たとえば、単純な文言修正やCSSの余白調整であれば、重い推論は不要です。一方、WordPressのテンプレート構造を読み解く作業、既存機能を壊さずに改修する作業、複数ファイルにまたがるバグ修正では、深い推論が必要になります。
| 推論強度 | 向いている作業 | 注意点 |
|---|---|---|
| Low | 軽い確認、単純な修正、短い質問 | 複雑な設計には向きにくい |
| Medium | 通常のコーディング、HTML/CSS修正 | 広範囲な仕様整理では不足する場合がある |
| High | WordPress、JavaScript、複数ファイル修正 | Lowより時間はかかる |
| Max / Ultra | 大規模修正、設計、難しいバグ解析 | 処理時間が長くなることがある |
/model/modelを実行すると、利用可能なモデルや推論強度を選択できます。
作業ごとの目安は次の通りです。
| 作業内容 | 推奨の考え方 |
|---|---|
| HTMLの文言修正 | 軽めでよい |
| CSSの見た目調整 | 通常程度でよい |
| WordPressテンプレート修正 | 高めが無難 |
| JavaScriptの不具合修正 | 高めが無難 |
| 要件定義・設計 | 高めまたは最大寄り |
| 原因不明の複雑なエラー | 最大寄り |
注意：推論強度を高くすれば必ず正解になるわけではありません。
重要なのは、推論強度だけで解決しようとせず、/plan、/diff、/reviewと組み合わせて、作業過程を確認することです。
/planいきなり実装せず、先に作業計画を作るコマンド
/planは、Codex CLIを安全に使ううえで最も重要なコマンドの一つです。
Codexに「修正してください」とだけ依頼すると、すぐにファイル編集へ進むことがあります。
しかし、実務ではそれが危険な場合があります。特に、既存サイト、WordPressテーマ、CMS、会員機能、予約機能、問い合わせフォームなどは、関係するファイルや処理が複数あります。
その状態でいきなり実装すると、見た目は直っても別の機能が壊れることがあります。
/planは、そうした事故を減らすために、まず計画だけを出させるコマンドです。
/plan
WordPressテーマのトップページで、H1とアイキャッチ画像のaltを修正する計画を作成してください。このように入力すると、Codexは実装ではなく、まず作業計画を提示します。
おすすめの流れ
/plan → 計画確認 → 必要なら修正指示 → 実装許可 → /diff → /review
| 良い計画 | 悪い計画 |
|---|---|
| 変更対象ファイルが明確 | どのファイルを触るか不明 |
| 既存機能への影響を確認している | 見た目だけを前提にしている |
| 実装前に確認事項を整理している | 不明点を推測で埋めている |
| テスト方法まで含まれている | 修正後の確認方法がない |
重要
Codex CLIでは、複雑な作業ほど先に/planを使うべきです。
AIに任せる範囲が大きいほど、実装前の計画確認が品質管理になります。
/diffCodexが変更したファイル差分を確認するコマンド
/diffは、Codexがどこをどう変更したのかを確認するためのコマンドです。
AIがコードを修正した場合、見た目だけを確認して終わるのは危険です。
表面上は問題がなくても、不要なコードが削除されていたり、関係のないファイルが変更されていたり、意図しない仕様変更が入っている場合があります。
そのため、Codexがファイルを編集した後は、必ず/diffで変更差分を確認します。
diffとは、変更前と変更後の差分です。
たとえば、次のように表示されます。
- <h1>旧タイトル</h1>
+ <h1>新タイトル</h1>-は削除された行、+は追加された行を表します。
/diff実装後に/diffを実行すると、変更内容を確認できます。
注意：/diffは、変更内容を確認するためのものです。
表示された差分を見て、問題がありそうならその場でCodexに修正を指示してください。確認せずに次へ進むと、意図しない変更を見落とす可能性があります。
/review変更内容に問題がないか確認させるコマンド
/reviewは、Codexに現在の変更内容をレビューさせるためのコマンドです。
/diffが「どこが変わったかを見る」コマンドだとすれば、/reviewは「その変更に問題がないかを考えさせる」コマンドです。
自分で差分を見ても、バグや仕様漏れを完全に見つけるのは難しい場合があります。そこで、Codexに別視点でレビューさせます。
| 観点 | 確認内容 |
|---|---|
| バグ | 動作不良につながるコードがないか |
| 仕様漏れ | 依頼内容に対して不足がないか |
| 影響範囲 | 他の画面や機能を壊していないか |
| セキュリティ | 入力値処理や出力処理に問題がないか |
| 保守性 | 後で修正しにくい構造になっていないか |
| テスト不足 | 確認すべき動作が残っていないか |
/review実装後に/reviewを実行すると、Codexが変更内容に対してレビューを行います。
実務での基本セット
実装完了 → /diff → /review → 指摘があれば修正 → 再度 /diff
重要なのは、/reviewを実行しただけで安全と判断しないことです。
AIによるレビューは有効ですが、最終判断は人間が行う必要があります。特に、顧客サイト、公開中サイト、決済、問い合わせ、会員機能に関わる変更では、実機確認やブラウザ確認も必要です。
注意：/reviewは万能ではありません。
レビュー結果に問題なしと出ても、ブラウザ表示、フォーム送信、管理画面、スマートフォン表示などの実動作確認は別途行ってください。
/compact会話を要約してコンテキストを整理するコマンド
/compactは、長くなった会話を要約して、作業を続けやすくするためのコマンドです。
Codex CLIで長時間作業していると、会話履歴が増えていきます。
会話履歴が増えると、Codexが参照する情報量も増えます。その結果、動作が重くなったり、古い情報と新しい情報が混ざったり、重要な指示が埋もれたりする場合があります。
そのような時に使うのが/compactです。
/compact/compactを実行すると、これまでの会話内容が要約されます。
ただし、要約されるということは、細かい会話の一部が圧縮されるということでもあります。そのため、実行前に重要な決定事項を明示しておくと安全です。
ここまでの重要事項を整理します。
・変更対象は page-home.php と style.css のみ
・header.php は変更しない
・H1は固定文言にする
・altは投稿タイトルではなく指定文言にする
・スマホ表示確認を必須にする
この前提を残したうえで compact してください。使い方のコツ
/compactは、会話が限界に近づいてから使うよりも、一区切りついた時点で使う方が安全です。
/resume保存された過去のセッションを再開するコマンド
/resumeは、以前のCodex CLI作業を再開するためのコマンドです。
Web制作やシステム開発では、1回の作業で完了しないことが多くあります。
たとえば、1日目に調査、2日目に実装、3日目にレビュー、4日目に修正という流れになることがあります。
そのような時に毎回最初から説明し直すのは非効率です。/resumeを使うと、過去のセッションを選んで再開できます。
/resume/resumeを実行すると、保存されたセッションを選択して再開できます。
特に、数日空いた作業では、前回の計画が古くなっている場合があります。
そのため、/resumeで再開した直後は、いきなり実装せず、まず現在の状態確認を行うのが安全です。
再開時のおすすめ手順
/resume → /status → 前回内容の確認 → 必要なら /plan → 実装再開
ここまで紹介した7つのコマンドは、単体で使うよりも、作業の流れとして使うと効果が高くなります。
おすすめの基本フローは次の通りです。
/statusで現在の状態を確認する/modelでモデルや推論強度を調整する/planで作業計画を作らせる/diffで変更内容を確認する/reviewで問題点を洗い出す/diffを確認する/compactで整理する/resumeで再開する最短で覚えるなら
最初は次の4つだけでも十分です。
/status → /plan → /diff → /review
この4つを使うだけでも、Codex CLIの作業事故はかなり減らせます。
Codex CLIは強力ですが、使い方を誤ると、不要な変更や意図しない修正が発生することがあります。
初心者が特にやりがちな失敗は次の通りです。
| 失敗例 | 問題点 | 防止策 |
|---|---|---|
| いきなり実装させる | 変更範囲が広がりやすい | 先に/planを使う |
| 差分を見ない | 意図しない変更に気づけない | 実装後に/diffを使う |
| レビューしない | バグや仕様漏れが残りやすい | /reviewを実行する |
| 作業フォルダを確認しない | 別プロジェクトを編集する危険がある | 開始時に/statusを使う |
| 長い会話を放置する | 前提が混ざりやすい | 区切りで/compactを使う |
| 前回作業を説明し直す | 時間がかかり、前提もずれやすい | /resumeで再開する |
たとえば、WordPressサイトのトップページを修正する場合、次のような流れが安全です。
/statusまず、正しいプロジェクトフォルダで作業しているか確認します。
/plan
トップページのH1、アイキャッチ画像のalt、記事一覧の表示件数を修正する計画を作成してください。
既存のヘッダー、フッター、投稿詳細ページには影響を出さない前提です。次に、実装前の計画を作らせます。
計画に問題がなければ、実装を許可します。
この計画で実装してください。
ただし、変更対象ファイル以外は触らないでください。実装後、差分を確認します。
/diff最後にレビューを依頼します。
/reviewこの流れにすることで、AI任せで勝手に変更されるリスクを抑えられます。
| 状況 | 使うコマンド | 理由 |
|---|---|---|
| 作業を始める | /status |
現在の設定と作業場所を確認するため |
| AIの考える深さを変えたい | /model |
作業内容に合わせてモデルや推論強度を調整するため |
| 大きな修正をしたい | /plan |
実装前に変更方針を確認するため |
| 何が変更されたか見たい | /diff |
変更差分を確認するため |
| 変更内容に問題がないか見たい | /review |
バグや仕様漏れを確認するため |
| 会話が長くなった | /compact |
重要事項を残して会話を整理するため |
| 前回の続きをしたい | /resume |
保存済みセッションを再開するため |
Codex CLIには多くの機能がありますが、最初からすべてを覚える必要はありません。
まず覚えるべきなのは、次の7つです。
最初に覚える7つ
/status：現在の状態を確認する/model：モデルや推論強度を変更する/plan：実装前に計画を立てる/diff：変更差分を確認する/review：変更内容をレビューする/compact：長い会話を整理する/resume：過去の作業を再開する特に重要なのは、/plan、/diff、/reviewです。
この3つを使うことで、Codexに任せきりにせず、作業前・作業中・作業後の確認ができます。
Codex CLIは、単にコードを書かせる道具ではありません。正しく使えば、設計、実装、確認、レビューまでを一つの流れで進められる開発支援ツールになります。
最初は難しく考えず、次の流れだけ覚えてください。
この流れを習慣にするだけで、Codex CLIの作業品質は大きく安定します。
※本記事は2026年7月時点のCodex CLIの利用を前提にした実務向け解説です。Codex CLIは更新により、コマンド名、表示内容、利用可能な機能が変更される場合があります。実際に使用する際は、Codex CLI上で/を入力して表示されるコマンド一覧も確認してください。