Codexを使ってみたいのに、最初の設定画面で手が止まる人はかなり多いです。GitHub連携、リポジトリ選択、実行環境、権限、テストコマンド、秘密情報の扱い。どれも少し間違えるだけで、「動かない」「勝手に直されそうで怖い」「どこまで任せていいのかわからない」という状態になります。最初に見るべき場所と、触ってよい設定、触らないほうがよい設定を切り分ければ、Codexは怖いツールではありません。コードを書かせる前に、作業範囲と確認手順を決めておくことが、失敗しない近道です。
Codexで最初に理解すべきこと
AIのイメージ
Codexは普通のチャット回答とは違う
ChatGPTに「このコードを直して」と聞く使い方と、Codexに作業を任せる使い方は別物です。通常のチャットでは、表示された回答を見て自分でコピーし、必要な場所へ貼り付けます。一方でCodexは、対象のリポジトリを読み、必要なファイルを探し、修正し、テストやリンターを動かし、変更差分を見せるところまで進められます。
この違いを知らずに始めると、「勝手に全部書き換えられるのでは？」と不安になります。実際には、最初から本番環境に直接反映する使い方をしなければ、変更内容は確認できます。大切なのは、Codexに触らせる場所を限定し、変更差分を見てから取り込むことです。
初心者が最初に狙うべき作業
最初から大きな新機能を丸ごと任せると、どこを見ればよいかわからなくなります。最初の練習には、文言修正、軽いバグ修正、テスト追加、READMEの更新、型エラーの修正が向いています。
たとえば、ボタンの表示名を変える、フォーム送信時のエラーメッセージをわかりやすくする、既存関数にテストを足す、といった作業です。変更箇所が少ないため、Codexの動きが追いやすく、失敗しても戻しやすくなります。
始める前に必要な準備
ChatGPTのプランと表示を確認する
ChatGPTの画面でCodexが表示されるかを最初に確認します。左側のメニューや作業用の画面にCodex関連の項目が出ていれば、そこから始められます。表示されない場合は、利用中のプラン、ワークスペースの管理者設定、地域や段階的提供の状況によって使えないことがあります。
個人利用なら、まずChatGPTのアカウントでログインし、画面内にCodexがあるかを確認します。会社アカウントなら、管理者がCodex利用を許可しているかが重要です。会社のコードを扱う場合、個人アカウントで勝手に接続するのは避けてください。会社のリポジトリは、会社が許可したアカウントと管理された環境で扱うのが安全です。
GitHub側で確認すること
Codexにリポジトリを読ませるには、GitHubとの連携が必要になる場面があります。連携画面で求められる権限を見たら、対象を全リポジトリにする前に、必要なリポジトリだけを選べるか確認します。
初心者がやりがちな失敗は、「面倒だから全部許可する」ことです。学習用や個人開発ならまだ戻しやすいですが、業務リポジトリでは危険です。まずは練習用リポジトリ、または影響の少ないリポジトリだけを接続します。設定後にCodex画面で対象プロジェクトが見えれば、次に進めます。
ChatGPTからCodexを設定する基本手順
次の順番で進めると、途中で迷いにくくなります。画面名は環境によって少し変わることがありますが、確認する考え方は同じです。
- ChatGPTにログインし、左側のメニューまたは作業画面からCodexを開きます。
- GitHub連携の案内が表示されたら、対象アカウントを選び、最初は必要なリポジトリだけを許可します。
- Codexで使いたいリポジトリを選び、作業対象のブランチやプロジェクトが正しいかを確認します。
- 環境設定画面で、依存関係のインストール方法、ビルド方法、テスト方法を登録します。
- 秘密情報が必要な場合は、画面上の安全な入力欄にだけ登録し、チャット本文には直接書きません。
- 最初の依頼は、「このリポジトリの構成を説明して」「テストの実行方法を確認して」のような読み取り作業にします。
- 修正依頼を出した後は、変更差分、実行ログ、テスト結果を確認し、問題がなければプルリクエスト作成へ進みます。
この順番にすると、いきなりコードを書き換える前に、Codexがリポジトリを正しく理解できているかを確認できます。特に初回は、修正依頼よりも先に「構成を説明して」と頼むのが安全です。説明の中で存在しないファイル名が出てきたり、テストコマンドを勘違いしていたりする場合は、環境設定や指示が足りていません。
環境設定でつまずきやすいポイント
テストコマンドは最初に登録する
Codexは、ただコードを書くだけでなく、テスト、型チェック、リンターを実行して結果を確認できます。ただし、どのコマンドを使えばよいかが曖昧だと、間違った確認で「完了」と判断されることがあります。
画面上で実行環境を設定できる場合は、プロジェクトで普段使っている確認方法を入れます。たとえば、フロントエンドならテスト、型チェック、ビルド確認。バックエンドなら単体テスト、静的解析、起動確認です。コマンド名そのものを覚えていない場合は、リポジトリ内のREADME、package設定、CI設定を見て、普段チームが使っているものに合わせます。
Codex用に特別な確認手順を作るより、普段人間が使っている確認手順をそのまま渡すほうが失敗しにくくなります。
AGENTS.mdで作業ルールを渡す
リポジトリ内にAGENTS.mdというファイルを置くと、Codexに作業ルールを伝えやすくなります。これは人間向けのREADMEに近い役割ですが、Codexが作業するときに読みやすい指示を書く場所です。
書く内容は難しくありません。「このプロジェクトでは変更前にテストを実行する」「UI文言は日本語で統一する」「新しいライブラリを追加する前に理由を書く」「データベース変更は勝手に行わない」といった、開発者なら当たり前に守っているルールを短く書きます。
初心者ほど、Codexへの依頼文だけで全部を伝えようとします。しかし毎回同じルールをチャットに書くと抜け漏れが出ます。AGENTS.mdに共通ルールを書いておけば、依頼文では今回の作業だけに集中できます。
秘密情報はチャットに貼らない
APIキー、アクセストークン、データベース接続情報、顧客情報は、チャット本文に貼らないでください。Codexの環境で必要な値がある場合は、専用の秘密情報管理欄や環境変数設定欄を使います。
「一度だけだから」と本文に貼ると、後でどこに残ったか追いにくくなります。ログ、履歴、共有画面、スクリーンショットに残る可能性もあります。特に会社の開発環境では、秘密情報は本文ではなく設定画面で扱うというルールを徹底してください。
デスクトップアプリとCLIはどう使い分ける？
ChatGPT画面だけで始める場合
最初はChatGPT内のCodexから始めるのがわかりやすいです。リポジトリを選び、作業を依頼し、差分を確認する流れが画面内で完結します。コードに慣れていない人でも、ファイル一覧や変更内容を見ながら判断できます。
特に「このコードが何をしているか知りたい」「バグの原因を探したい」「小さな修正を依頼したい」という段階では、ChatGPT内のCodexで十分です。
Codexアプリを使う場合
Codexアプリは、複数の作業を並行して進めたい人に向いています。作業ごとに分かれた環境で進められるため、Aの修正を試しながら、Bの調査も同時に走らせるような使い方ができます。WindowsとmacOSの両方で使える環境が広がっており、デスクトップ上で差分確認や進行状況の把握がしやすくなっています。
ただし、初心者が最初から複数作業を走らせると混乱します。最初の一週間は、同時に走らせる作業を一つに限定してください。差分を確認し、戻し方を覚え、テスト結果を見る流れが身についてから並行作業に進むほうが安全です。
CLIを使う場合
ターミナル操作に慣れている人は、CodexCLIを使うとローカル環境に近い感覚で作業できます。エディタや既存の開発フローと組み合わせやすく、細かい確認もしやすくなります。
一方で、ターミナルに慣れていない初心者がCLIから始めると、エラー文の意味がわからず止まりやすくなります。まずChatGPT画面やCodexアプリで流れをつかみ、あとからCLIに進む順番がおすすめです。
| 使い方 | 向いている人 | 最初の注意点 |
|---|---|---|
| ChatGPT内のCodex | 初めて設定する人、小さな修正から試したい人 | 対象リポジトリを絞り、差分確認を必ず行う |
| Codexアプリ | 複数プロジェクトを扱う人、作業進行を画面で見たい人 | 最初は同時作業を一つに絞る |
| CodexCLI | ターミナルやローカル開発に慣れている人 | 認証方法と実行権限を理解してから使う |
最初の依頼文はここまで具体的に書く
悪い依頼は範囲が広すぎる
「このアプリを改善して」「バグを直して」「きれいにして」といった依頼は、初心者ほど書きがちです。しかしCodexから見ると、何を変えてよいのか、何を変えてはいけないのかが曖昧です。結果として、思ったより広い範囲に手が入ることがあります。
最初は、「ログイン画面のエラーメッセージだけを修正してください。認証処理は変更しないでください。変更後に関連テストを実行してください。」のように、対象、禁止事項、確認方法を一文に入れます。
よい依頼は画面と結果がわかる
Codexへの依頼では、読者ではなく作業者に伝えるつもりで書きます。「どの画面で」「何をすると」「今どうなり」「どうなってほしいか」を入れると、原因調査がしやすくなります。
たとえば、「問い合わせフォームでメールアドレスを空欄にして送信すると、英語のエラーが表示されます。日本語で『メールアドレスを入力してください』と表示されるようにしてください。フォームの送信処理とAPI仕様は変更しないでください。」という依頼なら、作業範囲がかなり明確です。
安全に使うための確認ポイント
Codexは便利ですが、確認なしで取り込むと危険です。特に、ログイン、決済、権限、個人情報、データ削除に関わる修正は慎重に扱います。以下の確認を習慣にすると、大きな失敗を避けやすくなります。
- 変更差分で、依頼していないファイルが書き換わっていないかを確認します。
- テスト結果だけで安心せず、画面表示や主要な操作を自分でも確認します。
- 公式に見えない類似アプリ、類似パッケージ、非公式ログイン画面にはChatGPTの認証情報を入力しません。
最近は、Codexに似た名前を使う非公式ツールやパッケージも目立ちます。便利そうに見えても、ログイン情報やトークンを抜き取る目的のものが混ざる可能性があります。導入時は、ChatGPTの画面、公式の配布元、信頼できるストア、管理者が許可した経路だけを使ってください。
ChatGPTとCodexの設定に関する疑問解決
Codexが表示されないときはどこを見る？
まずChatGPTにログインしているアカウントを確認します。個人用と会社用を使い分けている場合、Codexが使えるのは別のアカウントかもしれません。次に、利用中のプランとワークスペース設定を見ます。会社アカウントなら、管理者がCodexを無効にしている可能性があります。
ブラウザで見えない場合は、アプリ側でも確認します。反対に、アプリで見えない場合はブラウザで確認します。段階的に提供される機能では、同じ日に全員へ同じ表示が出るとは限りません。表示されないときに無理に非公式ツールを探すのではなく、アカウント、プラン、管理者設定、アプリ更新の順に確認してください。
GitHub連携で全部許可しても大丈夫？
最初から全部許可する必要はありません。むしろ、必要なリポジトリだけを選ぶほうが安全です。個人開発でも、古い実験リポジトリや秘密情報を含むリポジトリまで一括で許可する意味はありません。
仕事で使う場合は、権限範囲をチームで決めてから接続します。読み取りだけでよいのか、プルリクエスト作成まで許可するのか、書き込み権限が必要なのかを分けて考えます。権限は広げるより、必要になったときに追加するほうが管理しやすいです。
環境設定をしないまま使うとどうなる？
簡単な質問なら動きますが、修正作業では精度が落ちます。依存関係の入れ方、ビルド方法、テスト方法がわからないため、Codexが推測で進めることがあります。推測が当たれば問題ありませんが、外れると「テストできなかったが修正は完了した」という中途半端な状態になります。
本格的に使うなら、最初に実行環境を整えます。READMEに手順があるなら、その内容をCodexが読める状態にします。CI設定があるなら、それに近い確認をCodexにもさせます。環境設定は面倒に見えますが、後の手戻りをかなり減らします。
よくある質問
プログラミング初心者でもCodexは使えますか？
使えます。ただし、最初から大きな実装を任せるのは避けたほうが安全です。初心者は、コードを書かせる前に「このファイルの役割を説明して」「このエラーの原因候補を教えて」「変更前に見るべきファイルを挙げて」のような質問から始めると理解が進みます。内容がわかってから小さな修正を依頼すれば、差分確認もしやすくなります。
Codexに任せた変更はそのまま反映してよいですか？
そのまま反映しないでください。変更差分、テスト結果、画面上の動作を確認してから取り込みます。特に、認証、決済、権限、データ削除、外部API連携に関わる変更は、人間の確認が必須です。Codexが「完了」と表示しても、実際のサービス仕様に合っているかは別問題です。
会社のコードを扱うときに一番注意すべきことは何ですか？
機密情報と権限管理です。会社のコード、顧客情報、APIキー、未公開仕様を個人アカウントや許可されていない環境に入れないでください。会社で使う場合は、管理者が許可したワークスペース、リポジトリ、権限範囲で使います。判断に迷う情報は入力しない、という運用が安全です。
CodexアプリとChatGPTアプリは別物ですか？
役割が違います。ChatGPTアプリは会話や確認に使いやすく、Codexアプリは開発作業を進める作業場として使いやすいです。スマートフォンからCodexを操作できる環境では、接続先のパソコンが起動し、オンラインで、Codexが動いている必要があります。外出先で確認できるのは便利ですが、重い判断はデスクトップで差分を見てから行うほうが安全です。
エラーが出たら何を見ればよいですか？
最初に見るのは、実行ログ、失敗したコマンド、変更されたファイルです。エラー文をそのままCodexに渡し、「この失敗の原因を、設定不足、依存関係、コード変更の三つに分けて説明してください」と聞くと整理しやすくなります。いきなり再修正を頼むより、原因を分解してから直すほうが失敗しにくいです。
まとめ
Codexの設定で大切なのは、難しい機能を全部覚えることではありません。最初に、使うアカウント、接続するリポジトリ、実行環境、テスト方法、秘密情報の扱い、変更確認の流れを決めることです。
初心者は、まずChatGPTの画面でCodexを開き、GitHub連携を必要最小限に絞り、練習用リポジトリで構成確認から始めてください。次に、小さな文言修正やテスト追加を依頼し、差分とログを確認します。この流れを一度経験すると、Codexが何をしているのかが見えるようになります。
便利さだけで進めると危険ですが、作業範囲を区切り、確認手順を固定すれば、Codexは開発の強力な相棒になります。今日やることは一つで十分です。まずは影響の小さいリポジトリを選び、Codexに「このプロジェクトの構成とテスト方法を説明してください」と頼むところから始めてください。そこまでできれば、次の一歩は自然に見えてきます。
