Codexの使い方ガイド: 始め方、5つのTips、Best Practicesまで
Codex は、コード補完ツールというより「コードを読んで、変更して、コマンドを実行し、結果を review できる AI coding agent」です。日本語でいう codex 使い方 の本質は、インストール手順を覚えることではなく、Codex に何を任せ、どこで人間が review するかを理解することにあります。
最初に結論を言うと、Codex は 小さく明確なタスクから始める と最も使いやすいです。いきなり「この repo を全部直して」と投げるより、対象ファイル、目的、制約、完了条件を渡したほうが、精度も review のしやすさも上がります。
もし AI coding 全体の立ち位置から見たいなら、まず AI Coding トピックページ と 2026年のベストVibe Codingツール比較 を見ると全体像がつかみやすいです。Codex と Claude Code の違いが気になるなら、Codex vs Claude Code Skills もあわせて読むと整理しやすくなります。
まず結論: Codex はどう使うのが正解か
| あなたの状況 | 最初に使う面 | 理由 |
|---|---|---|
| ターミナル中心で repo を触る | CLI | 最もストレートに Codex を使える。指示、編集、テスト、review の流れが自然 |
| 複数タスクを見ながら diff を確認したい | App | review pane、worktree、handoff、automations が強い |
| いまのエディタを大きく変えたくない | IDE extension | 既存の IDE の中で Codex を呼び出しやすい |
おすすめの入り方は単純です。
- まず CLI か App のどちらか一つで始める
- 小さなタスクを 3 回くらい繰り返す
AGENTS.mdと review の使い方を覚える- その後で skills や subagents に進む
最初に迷いやすいのは「どこから使い始めるか」です。CLI は最短で試しやすく、App は review と worktree が強く、IDE extension は既存の開発フローを崩しにくいという違いがあります。
Codex とは何か
Codex は OpenAI の coding agent です。CLI ではローカルのディレクトリでコードを読み、編集し、コマンドを実行できます。App では diff の review、worktree を使った並列作業、background task の管理まで含めて扱えます。IDE extension はその体験をエディタ側に近づける位置づけです。
重要なのは、Codex を「コードを書いてくれるチャット」としてだけ見ると、価値の半分しか使えないことです。実際には次のような仕事に向いています。
- 見慣れないコードベースの読み解き
- 小から中規模の機能追加や修正
- バグ調査と再現手順の整理
- テスト、lint、build を含む変更の検証
- code review と差分の整理
- 定型作業の skill 化、automation 化
その意味では、Codex は単体の生成モデルというより、実務フローに入るエージェント と考えたほうが使い方を理解しやすいです。
Codex の始め方
1. CLI を入れて最初のセッションを始める
OpenAI の公式ドキュメントでは、Codex CLI の最短セットアップは次の流れです。
npm i -g @openai/codex
codex初回起動時には ChatGPT アカウントまたは API key で認証します。ここで大事なのは、インストール直後に大きな仕事を投げないことです。最初の 1 回目は、環境の確認を兼ねた小さな依頼にします。
例えばこうです。
このリポジトリの構成を要約して、重要なディレクトリと開発フローを教えてください。
まだ編集はせず、調査だけしてください。この一手で、Codex が repo をどう理解するか、どの程度の粒度で説明するかが見えます。
2. 2 回目の依頼で小さな変更をさせる
次は小さくて review しやすい変更を依頼します。
このコンポーネントの文言だけを修正してください。
変更対象は 1 ファイルに限定し、変更後は差分を要約してください。この段階で意識したいのは、タスクを広げないことです。Codex は広い依頼にも反応できますが、最初は「対象」「目的」「制約」を狭くしたほうが安定します。
3. 3 回目で検証まで含める
Codex は編集だけでなく、変更後の確認までやらせたほうが価値が上がります。
このテスト失敗を直してください。
修正後は関連テストだけを実行し、何を直したかを 3 行でまとめてください。この「編集だけで終わらせない」感覚が、Codex の使い方でかなり重要です。
Codex を「生成」で止めず、read -> plan -> edit -> test -> review のループで使うと精度と信頼度が上がります。中央の human check は、差分をそのまま受け取らず、説明できる変更だけを採用するという原則を表しています。
Codex の基本的な使い方
まず読ませてから直させる
Codex にいきなり変更を依頼するより、先に説明させたほうが成功率は上がります。特に既存 repo では有効です。
このモジュールの責務と依存関係を要約してください。
その後、最小の変更案を 2 パターン出してください。
まだ編集はしないでください。これで Codex の理解を先に確認できます。理解が浅いまま編集を始めるより、1 ターン余分に使ってでも安全です。
変更の完了条件を必ず書く
Codex は「何をすれば完了か」が分かるほど安定します。
悪い例:
このページを改善して良い例:
このページの導入を短くしてください。
最初の画面で「これは何か」と「なぜ重要か」が分かるようにしてください。
既存の H2 構造は維持し、コードブロックは増やさないでください。review を前提に差分を扱う
App の review pane では、Codex が編集した差分だけでなく、repo 上の未コミット変更全体を見ながら staged / unstaged を切り替えられます。Inline comment を使うと特定行に対してフィードバックできるので、単なる「直して」より精度の高い戻し方ができます。
もし App を中心に使うなら、Parallel Code Agents の解説 も早めに読む価値があります。Codex の worktree と review の考え方がつながります。
5つの Tips
Tip 1: いきなり実装させず、先に計画を出させる
最初の一言を「実装して」ではなく、「まず計画を出して」に変えるだけで、無駄な往復がかなり減ります。
例えばこうです。
まず修正方針を 3 ステップで示してください。
その後で実装に進んでください。これはバグ修正、リファクタ、記事更新のどれでも効きます。
Tip 2: 毎回、範囲と禁止事項を書く
Codex は優秀ですが、曖昧な依頼には曖昧に広がります。だから次の 3 点を毎回入れるのが実務的です。
- どこを触るか
- 何を達成するか
- 何を触らないか
短い依頼でも十分です。
`components/header.tsx` だけを修正してください。
ナビゲーションの余白を狭くするのが目的です。
ロジック変更と依存追加はしないでください。Tip 3: repo のルールは AGENTS.md に逃がす
毎回同じ説明を prompt に貼るのは非効率です。Codex の公式 best practices でも、持続的なルールは AGENTS.md に移すことが推奨されています。
AGENTS.md には少なくとも次を書いておくと便利です。
- repo 構成
- build / test / lint コマンド
- コーディング規約
- PR 期待値
- done の定義
CLI の /init は AGENTS.md の雛形を作るクイックスタートとして便利ですが、そのまま放置せず、チームの実際の build / test / review フローに合わせて編集したほうが良いです。
毎ターンの依頼は prompt に書き、repo 全体の持続ルールは AGENTS.md、繰り返し手順は skills、定期実行は automations に置くと、指示の役割が混ざりにくくなります。
Tip 4: subagents で並列化すると、探索と review がかなり速くなる
ここは 2026 年 3 月 16 日時点の Codex で特に注目すべき点です。現在の Codex では subagent workflows がデフォルトで有効 で、App と CLI で可視化されています。Codex は、あなたが明示的に依頼したときだけ専門化された subagent を複数起動し、結果を集約して返せます。
向いているのは次のようなタスクです。
- 大きい repo の探索
- PR の多観点 review
- 複数候補の比較
- マルチステップの実装計画
例えば PR review なら、観点ごとに agent を分けるのが分かりやすいです。
このブランチを main と比較して review してください。
Security、bugs、test flakiness、maintainability をそれぞれ別の subagent に担当させ、
全員の結果が揃ってから要約してください。この使い方の利点は、1 本の長い思考に全部を押し込まないことです。探索、検証、要約を分担させると、主 agent の文脈が汚れにくく、複雑なタスクをさばきやすくなります。
subagents は、main agent が security、bugs、tests、maintainability のような観点を並列に振り分け、最後に 1 本の review summary にまとめるイメージで使うと理解しやすいです。
ただし、subagents には注意点もあります。
- 明示的に頼まない限り起動しない
- 各 subagent が独自に model / tool を使うため token 消費は増える
- 高度に依存した単一作業を無理に分割すると、逆に統合コストが増える
つまり、並列化は万能ではなく、分割可能な仕事にだけ使う のがコツです。
Tip 5: 変更後は必ず review か test までやらせる
Codex の価値は「書く」より「直して確かめる」まで回せるところにあります。変更後に次のどちらかを必ずやらせるだけで、信頼度はかなり変わります。
- 関連テストを実行する
/reviewで別視点の review を走らせる
特に App の review pane は、inline comment で差分に直接フィードバックできるので、修正ループが短くなります。
Best Practices
1. 小さいタスクから始める
Codex の best practice はシンプルです。最初から大きすぎるタスクを投げないことです。
おすすめは次の順序です。
- 調査だけ
- 1 ファイル変更
- 小さなバグ修正
- テスト込みの修正
- 複数ファイルの変更
- subagents や automation
この順序で上げていくと、repo ごとの相性やルール不足も見えます。
2. approval と sandbox は最初は厳しめにする
OpenAI の best practices でも、初心者は default permissions から始めて、必要が見えてから緩めることが推奨されています。最初から広い権限を渡すより、安全側から入ったほうが失敗コストが低いです。
特に共有 repo や本番に近い環境では、いきなり自由に動かすより、review と approval をはさむべきです。
3. 持続的なルールは prompt ではなく設定に置く
毎回の prompt に長いルールを書き続けると、逆に本題がぼやけます。持続的なルールは AGENTS.md、反復的な作業は skills、安定して回る定型タスクは automations に寄せたほうがよいです。
Codex の skill は SKILL.md を中心に instructions、references、optional scripts をまとめる形なので、レビュー手順や記事チェックのような再利用性の高い作業に向いています。
4. 同時進行の thread を同じファイル群で並走させるなら worktree を使う
同じ repo で複数の thread を同時に進めるなら、worktree の考え方を早めに入れたほうが安全です。Codex App の worktree は、同じ project 内で並列に作業しつつ、現在のローカル環境を壊しにくくするための仕組みです。
とくに次のケースで有効です。
- 片方で bugfix、片方で docs 更新を進めたい
- background task を走らせながら手元の作業を続けたい
- main の作業環境を残したまま別 task を試したい
worktree を使わずに同じファイルを live thread で並走させると、review と統合が急に難しくなります。
5. 変更を「受け取る」のではなく「選別する」
Codex が出した差分をそのまま受け入れるのではなく、stage、revert、inline comment を使って絞るほうが結果は安定します。良い運用は、Codex をオートパイロットとして扱うことではなく、速い下書き役兼検証役 として使うことです。
Codex をどう使うべきか: 人別のおすすめ
初学者
最初はコード生成より、説明と修正から入るのがおすすめです。
- 「この関数は何をしているか」
- 「このエラーの原因は何か」
- 「最小の修正案を出して」
この使い方なら、学習と実務を両立しやすいです。
一人開発
Codex は一人開発とかなり相性が良いです。仕様整理、コード修正、テスト、review の往復が 1 つの流れで済みやすいからです。subagents は、探索と review を分ける場面で特に効きます。
チーム開発
チームでは、個人の prompt 力より AGENTS.md、review、worktree、skills の整備が重要です。Codex を使う人ごとに output がぶれないよう、repo の working agreement を先に固めたほうが効果が大きいです。
どんな人に向かないか
Codex は便利ですが、曖昧な依頼を丸投げして完全自動で任せたい人には向きません。むしろ「指示を明確にし、差分を review し、必要なら rules を育てる」人ほど恩恵が大きいです。
FAQ
Codex は初心者でも使えますか？
はい。ただし、最初から大規模実装に使うより、コード説明、バグ原因の整理、小さな修正から始めたほうが成功しやすいです。
Codex は CLI と App のどちらから始めるべきですか？
ターミナルに抵抗がなければ CLI、差分 review や並列タスクの見通しを重視するなら App が向いています。迷うなら CLI で基本を覚え、その後 App に広げるのが無難です。
subagents はいつ使うべきですか？
探索、review、比較のように、観点を分けて並列化できる仕事に向いています。逆に、1 つの密結合な変更を無理に分割するのは逆効果です。
AGENTS.md と skill はどう使い分けますか？
AGENTS.md は repo 全体のルールや期待値、skill は繰り返し使う手順や専門作業向けです。前者は working agreement、後者は reusable workflow と考えると分かりやすいです。
Codex の変更はそのまま信用してよいですか？
いいえ。test と review を通す前提で使うべきです。Codex は速いですが、最終判断は diff と検証結果を見て行うのが基本です。
Related Guides
- AI Coding トピックページ
- Parallel Code Agents 入門
- Claude Agent SDK で Claude Code 風 agent を作る
- 2026年のベストVibe Codingツール比較
- Codex vs Claude Code Skills