【初心者向け】OpenAI Codexとは？AIコーディングエージェントの始め方と使い方

Index

Codexとは何か
「コード補完」と「AIエージェント」は何が違うのか
Codexでできること
Codexを使う場所: App・CLI・IDE
Codexが作業する仕組み
初心者が最初に試すべき使い方
Codexにうまく依頼するコツ
AGENTS.mdでプロジェクトのルールを伝える
開発ライフサイクルでの活用例
安全に使うための注意点
まずやる3つのステップ

はじめに

AIでコードを書く、というと「自動補完で少し楽になる」くらいのイメージを持つ方も多いかもしれません。

しかし、OpenAI Codexは単なるコード補完ツールではありません。リポジトリを読み、必要なファイルを探し、変更し、テストを実行し、結果を見ながら次の作業を進める「AIコーディングエージェント」です。

この記事では、Codexをまだ使ったことがない方向けに、Codexの基本概念、最初の使い方、依頼のコツ、AGENTS.mdの考え方までを整理します。

1. Codexとは何か

Codexは、OpenAIが提供するコーディング支援エージェントです。

従来のAIコーディング支援は、エディター上で次のコードを補完したり、関数の一部を生成したりする使い方が中心でした。一方でCodexは、もう少し広い単位で作業できます。

たとえば、次のような依頼ができます。

このバグの原因を調べて修正して
この画面に検索機能を追加して
READMEを現在の実装に合わせて更新して
テストが落ちている原因を調べて直して
このPRをレビューして、リスクがある箇所を教えて

ポイントは、Codexが「コードを書く」だけでなく、「調べる」「計画する」「変更する」「確認する」までを一連の流れとして扱えることです。

2. 「コード補完」と「AIエージェント」は何が違うのか

AIによる開発支援は、大きく分けると次の3段階で考えると理解しやすいです。

使い方	主な役割	例
コード補完	今書いているコードの続きを提案する	関数の続きを補完する
ペアプログラミング	会話しながら設計や実装を進める	実装方針を相談する
エージェント委任	まとまった作業を任せる	バグ修正、テスト追加、ドキュメント更新

Codexの強みは、3つ目の「エージェント委任」にあります。

もちろん、人間の確認は必要です。ですが、細かい調査や実装のたたき台、テストの追加、ドキュメント整理などを任せることで、人間は設計判断やレビュー、優先順位づけに集中しやすくなります。

3. Codexでできること

Codexは、開発のさまざまな場面で使えます。

計画する

新機能を作る前に、既存コードを読ませて実装計画を作らせることができます。

例:

このリポジトリの認証まわりを読んで、OAuthログインを追加する場合の実装計画を作ってください。
まだコードは変更しないでください。

実装する

小さな機能追加やUI修正、バグ修正を任せられます。

例:

検索フォームに入力した文字で記事一覧を絞り込めるようにしてください。
既存のデザインに合わせて、必要ならテストも追加してください。

テストする

テストの追加や、失敗しているテストの原因調査にも使えます。

例:

npm test が失敗しています。
原因を調べて、最小限の修正でテストが通るようにしてください。

レビューする

変更差分を見てもらい、バグやリスクを指摘してもらえます。

例:

この差分をレビューしてください。
特に本番障害につながりそうなバグ、テスト不足、仕様の抜けを優先して見てください。

ドキュメントを書く

実装に合わせてREADMEや設計メモを更新する作業も得意です。

例:

現在の実装に合わせてREADMEのセットアップ手順を更新してください。
古い情報は削除せず、必要なら補足として残してください。

4. Codexを使う場所: App・CLI・IDE

Codexは、使う環境によって入り口が分かれます。

使う場所	向いている人	特徴
Codex App	複数の作業を並行して進めたい人	タスク管理しやすい
CLI	ターミナル中心で作業する人	軽量で自動化しやすい
IDE拡張	エディター内で自然に使いたい人	普段の開発フローに馴染みやすい

初心者におすすめなのは、まずCodex AppまたはIDE拡張から始めることです。画面上で差分や作業内容を確認しやすいため、Codexが何をしているかを追いやすくなります。

5. Codexが作業する仕組み

Codexの動きは、ざっくりいうと次のループです。

ユーザーが依頼する
Codexが必要なファイルや情報を読む
方針を立てる
ファイルを変更する
テストやビルドなどで確認する
結果を見て必要なら修正する
完了内容を報告する

この流れを理解しておくと、Codexへの頼み方がかなり変わります。

「これを作って」とだけ言うよりも、「どのファイルを見てほしいか」「何を変えてよくて、何を変えてはいけないか」「どうなったら完了か」を伝えると、結果が安定します。

6. 初心者が最初に試すべき使い方

いきなり大きな機能を任せるより、最初は小さく始めるのがおすすめです。

ステップ1: 読み取り専用で説明してもらう

まずはコードを変更させず、リポジトリの構造を説明してもらいます。

このリポジトリの構成を初心者向けに説明してください。
主要なディレクトリ、起動方法、変更時に注意すべき点をまとめてください。
まだファイルは変更しないでください。

ステップ2: 小さな修正を任せる

次に、影響範囲の小さい修正を依頼します。

トップページの見出し文言を少し自然な日本語に直してください。
デザインやレイアウトは変更しないでください。
変更後にビルドが通るか確認してください。

ステップ3: テストやドキュメントを任せる

実装だけでなく、確認作業も任せます。

今回の変更内容をREADMEに1段落だけ追記してください。
既存の説明はできるだけ残してください。

このように、小さく任せて、結果を確認しながら徐々に範囲を広げると安心です。

7. Codexにうまく依頼するコツ

Codexへの依頼は、長ければ良いわけではありません。大切なのは、必要な情報がそろっていることです。

おすすめは、次の4点を入れることです。

項目	書くこと
Goal	何を達成したいか
Context	背景や目的
Pointers	見てほしいファイルや参考情報
Constraints	守ってほしいルール
Done When	完了条件

例: よい依頼

Goal:
記事一覧ページにカテゴリ絞り込みを追加してください。

Context:
読者がネットワーク系の記事だけを探しやすくしたいです。

Pointers:
frontend/src/App.tsx と frontend/src/components を見てください。

Constraints:
既存のデザインに合わせてください。
大きなリファクタリングはしないでください。

Done When:
npm run build が通ること。
変更内容を簡単に説明すること。

この形式にすると、Codexが「どこまでやれば完了か」を判断しやすくなります。

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

Codexを継続的に使うなら、AGENTS.mdを用意すると便利です。

AGENTS.mdは、Codexに読ませるプロジェクト用の作業ルールです。

たとえば、次のような内容を書きます。

# AGENTS.md

## Project Overview
- React + TypeScript のブログ管理ツールです。
- UI変更は既存コンポーネントのスタイルに合わせてください。

## Commands
- Install: npm install
- Build: npm run build
- Test: npm test

## Rules
- 大きなリファクタリングは事前に相談してください。
- 既存の日本語文言は勝手に削除しないでください。
- 変更後は可能な範囲でビルドを実行してください。

毎回プロンプトにルールを書く代わりに、AGENTS.mdへまとめておくイメージです。

特にチーム開発では、以下のような情報が役に立ちます。

主要ディレクトリの説明
ビルド、テスト、Lintのコマンド
コーディング規約
触ってはいけないファイル
レビュー時に重視する観点
完了条件

9. 開発ライフサイクルでの活用例

Codexは、実装だけでなく開発全体で使えます。

フェーズ	Codexに任せやすいこと	人間が見るべきこと
Plan	調査、実装計画、影響範囲の整理	優先順位、仕様判断
Design	画面構成案、設計案のたたき台	体験、制約、トレードオフ
Build	実装、バグ修正、リファクタリング	重要な設計判断
Test	テスト追加、失敗原因の調査	テスト方針、品質基準
Review	差分レビュー、リスク指摘	最終判断、責任ある承認
Document	README、仕様メモ、変更履歴	公開表現、正確性
Maintain	ログ調査、依存関係更新、軽微な修正	本番影響、運用判断

Codexにすべてを丸投げするというより、「調査と下準備を任せて、人間は判断に集中する」と考えると使いやすくなります。

10. 安全に使うための注意点

Codexは便利ですが、使い方には注意が必要です。

変更前に範囲を決める

「このファイルだけ」「この機能だけ」「デザインは変えない」など、範囲を明確にすると安全です。

テストやビルドを完了条件に入れる

可能なら、完了条件にコマンドを入れます。

Done When:
npm run build と npm test が通ること。
実行できない場合は理由を説明すること。

大きな変更は計画から始める

いきなり実装させるのではなく、まず計画を出してもらいます。

まず実装計画だけ作ってください。
まだファイルは変更しないでください。

最終レビューは人間が行う

Codexは強力ですが、仕様判断や本番影響の責任は人間が持つべきです。特に認証、課金、個人情報、セキュリティに関わる変更は慎重に確認しましょう。

11. まずやる3つのステップ

Codexをこれから使うなら、最初の一歩はシンプルで大丈夫です。

実際のリポジトリでCodexを開く
読み取り専用で「このプロジェクトを説明して」と頼む
小さな修正を1つ任せて、差分と確認結果を見る

慣れてきたら、AGENTS.mdを作り、よく使う依頼パターンを整えていきましょう。

Codexは、単にコードを書くツールではなく、開発作業を一緒に進めるエージェントです。うまく使うコツは、完璧なプロンプトを書くことではなく、Codexが判断できるだけの文脈と完了条件を渡すことです。

最初は小さく任せる。結果を見て、依頼の仕方を調整する。その繰り返しで、Codexはかなり頼れる開発パートナーになります。