Codexの使い方を完全解説｜導入から実践・つまずき対策まで

Codexは、OpenAIが提供するAIコーディングエージェントです。コードの読解、修正、テスト実行までを自然言語の指示で任せられます。この記事では、必要なアカウントや料金の考え方、セットアップの流れ、最初の依頼の出し方、具体的な活用例、つまずき対処、上級者向けの工夫までを順番に解説します。読み終えるころには、自分のプロジェクトでCodexを安全に動かす道筋が描けるはずです。

Codexとは？使い方の前に押さえる全体像

Codexは、ソフトウェア開発のタスクを自律的に進めてくれるAIエージェントです。チャットで質問に答えるだけのAIと違い、プロジェクトのファイルを読み、変更案を作り、コマンドを実行して結果を確かめる、という一連の作業を担当します。

※コーディングエージェントとは: 指示を受けるとファイルの閲覧・編集やコマンド実行を自分で組み合わせ、目標の達成まで作業を進めるAIのこと。1回の質問に1回答える形式のチャットAIとは区別されます。

Codexの主な利用形態

Codexにはいくつかの入口があります。提供形態や名称は更新されることがあるため、最新の一覧はOpenAI公式のCodexページと開発者向けドキュメントで確認してください。

利用形態	概要	向いている人
CLI（ターミナル）	手元のターミナルからプロジェクトに対して作業を依頼する	コマンドラインに慣れた開発者
IDE拡張	エディタ上で選択範囲やファイルを見せながら依頼する	エディタ中心で作業したい人
クラウド版	ChatGPT側の環境でリポジトリに対しタスクを実行する	ローカル環境を汚したくない人、並行して任せたい人

※CLIとは: Command Line Interfaceの略で、文字入力でソフトウェアを操作する方式のこと。ターミナル（黒い画面）から使います。

CLI本体のソースコードはGitHubのopenai/codexリポジトリで公開されています。導入方法や更新情報はここと公式ドキュメントが一次情報になります。

得意なこと・苦手なこと

Codexが力を発揮しやすい作業は次のとおりです。

既存コードベースの構造説明、処理の流れの把握
バグ原因の調査と修正案の作成
テストコードの追加
小〜中規模のリファクタリング（※コードの外から見た動作を変えずに内部構造を整理すること）
ドキュメントやコメントの整備

一方で、要件があいまいな大規模な新規設計や、本番環境の機密データに直接触れる作業は、人間が主導して範囲を区切るべき領域です。AIの出力は必ず人がレビューする前提で使いましょう。

利用前の前提条件（環境・アカウント・料金）

必要な環境

最低限、次のものを用意します。対応OSや必要なランタイムのバージョンは更新されるため、公式ドキュメントのインストール手順で最新の要件を確認してください。

ターミナルが使えるPC（CLIを使う場合）
作業対象のプロジェクトフォルダ
Gitが使える状態（変更の確認や巻き戻しのため、強く推奨）
インターネット接続（モデルはクラウド側で動くため）

※Gitとは: ソースコードの変更履歴を管理するツール。Codexが加えた変更を差分で確認したり、気に入らなければ元に戻したりする安全網になります。

アカウントと料金の考え方

CodexのCLI本体は無料で入手できますが、実際に動かすにはモデルを利用する権利が必要です。基本は次のどちらかになります。

認証方法	課金の考え方	特徴
ChatGPTアカウントでサインイン	ChatGPTのプランに含まれる利用枠を使う	契約済みなら追加の設定が少ない
OpenAI APIキーを使う	使った分だけAPI従量課金	利用量に応じたコスト管理が必要

どのプランでどこまで使えるか、無料枠が実用的かどうかといった詳細は、プラン改定で変わりやすい部分です。整理した内容はCodexは無料で使える？料金プランと無料枠の範囲を徹底解説にまとめています。契約前には、必ず公式サイトで最新の料金と利用上限を確認してください。

※APIキーとは: プログラムからOpenAIのサービスを呼び出すための合言葉のような文字列。他人に知られると不正利用され課金される恐れがあるため、コードや公開リポジトリに書いてはいけません。

基本的な使い方：セットアップから最初の依頼まで

ここでは、CLIを例に、導入から最初の依頼を実行するまでの流れを説明します。インストール用の具体的なコマンドはOSや時期によって変わる可能性があるため、本記事では記載せず、公式の手順に従う形で進めます。

ステップ1：インストールと起動

公式ドキュメントまたはGitHubのREADMEを開き、自分のOS向けのインストール手順を確認する
手順どおりにCodex CLIをインストールする
作業したいプロジェクトのフォルダにターミナルで移動する
公式手順に記載された方法でCodex CLIを起動する

起動は、必ず作業対象のプロジェクトフォルダの中で行ってください。Codexは起動した場所を作業の基準にするため、ホームディレクトリなど広い場所で起動すると、意図しないファイルまで操作対象に含まれるおそれがあります。

ステップ2：サインインする

初回起動時に表示される認証方法の選択画面を確認する
ChatGPTアカウントを使うか、APIキーを使うかを選ぶ
ChatGPTアカウントの場合は、ブラウザの案内に従ってログインを完了する
APIキーの場合は、公式ドキュメントに記載された方法でキーを設定する

APIキーを使う場合は、環境変数など安全な方法で管理し、プロジェクトのファイルに直接書き込まないようにします。

※環境変数とは: OSやシェルに設定する名前付きの値。秘密情報をコードの外に置くために広く使われます。

ステップ3：承認とサンドボックスの設定を理解する

Codexには、ファイル編集やコマンド実行をどこまで自動で行ってよいかを決める仕組みがあります。名称や選択肢はバージョンによって変わるため、起動後の画面表示と公式ドキュメントで確認してください。考え方は次の3段階で整理できます。

考え方	動作のイメージ	向いている場面
厳しめ	編集やコマンド実行のたびに人間へ確認する	初めて使うとき、重要なリポジトリ
中間	作業フォルダ内の編集は進め、外部への影響が大きい操作は確認する	日常的な開発
緩め	確認なしで広く実行する	使い捨ての検証環境のみ

※サンドボックスとは: プログラムの動作範囲を制限した安全な実験場のこと。Codexではファイルアクセスやネットワーク通信の範囲を制限し、誤操作の被害を小さくする目的で使われます。

最初は厳しめの設定で始め、挙動に慣れてから緩めるのが安全です。

ステップ4：最初の依頼は「読むだけ」にする

最初の依頼では、ファイルを変更させない読み取り中心の質問が適しています。Codexがプロジェクトをどう理解したかを確認でき、ズレがあれば早めに補正できます。

このプロジェクトの全体構成を教えてください。
主要なディレクトリの役割、エントリーポイント、
テストの実行方法をファイルを変更せずに説明してください。

回答の内容が実際のプロジェクトと合っているかを確認します。誤りがあれば「testsディレクトリは見ましたか？」のように、見るべき場所を具体的に指示します。

ステップ5：小さな変更を依頼して差分を確認する

影響範囲の小さなタスク（例：関数1つへのコメント追加、小さなバグ修正）を依頼する
Codexが提示する変更案や実行しようとするコマンドを読む
問題なければ承認する
作業完了後、Gitで変更内容を確認する

git status
git diff

これはGitの標準コマンドで、どのファイルがどう変わったかを確認できます。意図しない変更があれば、元に戻したうえで指示を修正して再依頼します。

良い依頼文の型

依頼の品質は、結果に直結します。次の4要素を入れると安定しやすくなります。

要素	内容	例
目的	何を達成したいか	ログイン失敗時のエラー表示を直したい
対象	どのファイルや機能か	auth関連のモジュール
制約	やってはいけないこと	既存のAPI仕様は変えない
完了条件	何をもって終わりとするか	既存テストが通り、新規テストを1件追加

実践的な活用例

以下は操作の流れとプロンプトの例です。実際の出力はプロジェクトや時期によって変わるため、あくまで進め方の参考にしてください。

活用例1：初めてのコードベースを理解する

新しく参加したプロジェクトや、久しぶりに触るリポジトリの把握に使います。

プロジェクトフォルダでCodexを起動する（厳しめの設定のまま）
全体像を質問する
気になる機能について深掘りする
理解した内容を文書にまとめさせる（この段階で初めてファイル作成を許可）

注文確定の処理がどのファイルのどの関数を通って実行されるか、
呼び出し順に説明してください。ファイルは変更しないでください。

ここまでの説明をもとに、新メンバー向けのアーキテクチャ概要を
docs/overview.md にMarkdownでまとめてください。
推測の部分は「推測」と明記してください。

「推測は明記する」という指示を入れると、確認が必要な箇所を見分けやすくなります。

活用例2：バグを調査して修正する

エラーメッセージや再現手順がある場合の流れです。

症状・再現手順・期待する挙動を整理する
まず原因調査だけを依頼し、修正はまだ許可しない
原因の説明に納得できたら、修正を依頼する
既存テストの実行と、再発防止テストの追加を求める
差分をレビューして確定する

【症状】ユーザー名に全角スペースが含まれると検索結果が0件になる
【再現】検索欄に「山田　太郎」と入力して検索
【期待】「山田」「太郎」のAND検索になる
まず原因となっているコードを特定し、修正方針を説明してください。
この段階ではファイルを変更しないでください。

提案の方針で修正してください。
制約: 公開している関数のシグネチャは変えない。
完了条件: 既存テストが通り、全角スペースのテストを1件追加する。

調査と修正を分けると、誤った原因に基づく修正を防ぎやすくなります。

活用例3：テストを追加してリファクタリングする

動作を変えずに内部を整理したい場合は、先にテストで現状の挙動を固定するのが定石です。

対象の関数やモジュールに対する既存テストの有無を確認させる
不足しているテストを先に追加させる
テストが通る状態を確認する
リファクタリングを依頼する
再度テストを実行して、動作が変わっていないことを確認する

utils/price.js の計算ロジックについて、既存テストでカバーされていない
分岐を洗い出し、挙動を変えずにテストを追加してください。
プロダクションコードは変更しないでください。

テストが通ることを確認したうえで、utils/price.js の重複した
条件分岐を整理してください。外部から見た挙動は変えず、
変更後にテストを再実行して結果を報告してください。

なお、どのテストコマンドを使うかはプロジェクトごとに異なります。後述のAGENTS.mdに書いておくと、毎回説明する手間が省けます。

よくあるつまずきポイントと対処法

認証・課金まわり

症状	考えられる原因	対処
サインインできない	ブラウザ認証の中断、アカウント権限の不一致	公式ドキュメントの認証手順を再確認し、使うアカウントを揃える
利用上限に達したと表示される	プランの利用枠を使い切った	枠のリセットを待つか、プランやAPI利用への切り替えを検討する
想定外の課金が発生した	APIキー利用で長い作業を繰り返した	利用状況の確認と上限設定を行い、依頼の範囲を小さくする

利用枠や料金体系は変更されることがあります。判断に迷う場合は料金プランと無料枠の解説記事と公式サイトの最新情報を合わせて確認してください。

指示と結果がズレる

範囲が広すぎる: 「アプリ全体を改善して」のような依頼は、解釈の幅が広く失敗しやすい。1回の依頼を1つの目的に絞る
完了条件がない: 「直して」だけでは終わりの基準が曖昧。テストが通る、特定の出力になる、などを明記する
前提が伝わっていない: 使用言語やフレームワークのバージョン、命名規則などはAGENTS.mdにまとめる
会話が長くなり文脈が散らかる: 作業の区切りで新しい会話に切り替え、必要な情報だけを改めて伝える

意図しない変更が入る

依頼前にGitで作業ツリーをきれいな状態（未コミットの変更がない状態）にしておく
作業ごとに専用のブランチを切る
作業後は必ず差分を読む
気に入らない変更は、Gitで破棄してから指示を改善して再実行する

※ブランチとは: Gitで変更の流れを分岐させる仕組み。メインの履歴を汚さずに試行錯誤できます。

コマンドが実行されない・失敗する

サンドボックスの制限により、ネットワーク通信や作業フォルダ外への書き込みが拒否されている場合があります。エラーの内容を読み、必要な操作だけを個別に承認するのが基本です。設定を一気に緩める前に、なぜ制限されたのかをCodexに説明させ、本当に必要な権限か判断しましょう。

出力をそのまま信じてしまう

AIは、もっともらしいが誤ったコードや説明を出すことがあります。次の習慣が有効です。

テストを実行して、結果を自分の目で確認する
セキュリティに関わる箇所（認証、権限、入力検証）は特に丁寧にレビューする
存在しないライブラリ関数を使っていないか確認する
依存パッケージの追加は、必要性と信頼性を確認してから承認する

上級者向けのテクニック

AGENTS.mdでプロジェクトのルールを伝える

Codexは、リポジトリ内のAGENTS.mdというファイルを、作業時の指針として参照する仕組みを持っています。読み込まれる範囲や優先順位の詳細は、公式ドキュメントで確認してください。

記載しておくと効果的な内容の例です。

# AGENTS.md

## プロジェクト概要
- 社内向け在庫管理ツール（Webアプリ）

## 開発ルール
- 変更後は必ずテストを実行して結果を報告する
- 公開APIの仕様は事前相談なしに変更しない
- 新しい依存パッケージを追加する場合は理由を説明する

## コーディング規約
- 関数名はキャメルケース
- コメントは日本語で書く

これにより、毎回同じ前提を入力する必要がなくなり、チーム内でAIの振る舞いを揃えやすくなります。書く内容は「人間の新メンバーに最初に伝えること」と同じ発想で構いません。

依頼を分割して段階的に進める

大きなタスクは、次のように分割します。

調査：現状と影響範囲の把握（変更なし）
計画：変更方針と作業手順の提案（変更なし）
実装：計画の一部だけを実装
検証：テスト実行と差分レビュー
仕上げ：ドキュメント更新、コミットメッセージの作成

この機能追加の実装計画を、変更するファイルと手順の一覧で提示してください。
実装はまだ始めないでください。

計画を人間が確認してから実装に進めることで、手戻りが減ります。

クラウド版とローカルを使い分ける

ローカルのCLIやIDE拡張は、手元のコードを見ながら対話的に進める作業に向きます。クラウド版は、独立したタスクを環境ごと任せ、完了後に結果を確認する使い方に向きます。性質の違いは次のとおりです。

観点	ローカル（CLI・IDE）	クラウド版
作業環境	自分のPC	提供される実行環境
対話のしやすさ	途中で細かく指示を修正しやすい	依頼してから結果を待つ形が中心
向いたタスク	調査と修正を行き来する作業	範囲が明確で独立したタスク

利用できる機能やプランの条件は変わることがあるため、公式の最新情報を確認してください。

レビュー役としても使う

コードを書かせるだけでなく、自分や他のメンバーが書いた変更のレビュー補助にも使えます。

現在の作業ツリーの変更をレビューしてください。
バグの可能性、例外処理の漏れ、テスト不足、
セキュリティ上の懸念を重要度順に挙げてください。
ファイルは変更しないでください。

指摘がすべて正しいとは限らないため、採用するかどうかは人間が判断します。

安全に運用するためのチェックリスト

作業前にGitでコミットまたは退避し、いつでも戻せる状態にする
最初は承認を厳しめにし、信頼できる操作から段階的に緩める
機密情報（APIキー、個人情報、顧客データ）が入ったファイルを作業対象に含めない
変更はレビューしてからコミットする
会社や組織で使う場合は、AIツールの利用ルールとデータの取り扱い方針を確認する

コスト面では、依頼の範囲を絞り、不要に長い会話を続けないことが、利用枠やAPI費用の節約につながります。最新の仕様やオプションは、公式ドキュメントで随時確認してください。

まとめ

Codexは、コードの読解・修正・テスト実行までを任せられるAIコーディングエージェントで、CLI・IDE拡張・クラウド版などの入口がある
CLI本体は無料で入手できるが、利用にはChatGPTのプランまたはAPIキー（従量課金）が必要。最新の料金は公式サイトで確認する
最初は厳しめの承認設定で、読み取り中心の依頼から始め、Gitの差分で必ず変更内容を確認する
依頼文は「目的・対象・制約・完了条件」を入れ、調査と修正を分けると失敗しにくい
AGENTS.mdにルールを書き、依頼を段階的に分割すると、安定して使いこなせる

よくある質問

Codexは無料で使えますか？

CLI本体は無料で入手できますが、モデルの利用にはChatGPTのプランまたはOpenAI APIの従量課金が基本です。無料枠の有無や上限は変更されることがあるため、最新の条件は公式サイトで確認してください。

Codexを使うのにプログラミング経験は必要ですか？

自然言語で指示できますが、出力されたコードの妥当性を判断するには基礎知識があると安心です。特にGitでの差分確認とテスト実行は欠かせないため、最低限の開発経験があると安全に使えます。

Codexが勝手にファイルを書き換えるのが心配です。どうすればよいですか？

最初は承認を厳しめに設定し、作業前にGitで変更を保存しておきましょう。作業後は差分を確認し、不要な変更は破棄できます。重要なリポジトリでは専用ブランチを切って試すのがおすすめです。

AGENTS.mdとは何で、必ず必要ですか？

プロジェクトのルールやテスト方法などをCodexに伝えるためのファイルです。必須ではありませんが、毎回同じ前提を説明せずに済み、出力の品質も安定しやすくなります。読み込みの詳細は公式ドキュメントで確認してください。

依頼が思い通りに実行されないときはどうすればよいですか？

依頼の範囲を1つの目的に絞り、対象ファイル・制約・完了条件を明記して再依頼します。調査と修正を分ける、会話が長くなったら新しい会話に切り替える、といった工夫も効果的です。