この記事では、Codex アプリをはじめて使う人向けに、実際に画面を操作しながら基本設定を学ぶ手順を紹介するとともに、MCP、プラグイン、アプリ連携、ペットについて解説しています。
読み物として設定項目を眺めるのではなく、次の流れで小さな作業を進めます。
- Codex アプリを起動する
- 作業用フォルダを開く
- Codex にプロジェクトを読ませる
AGENTS.mdを作る- 小さな変更を依頼する
- 差分とテスト結果を確認する
- MCP、プラグイン、ペットを理解する
- 次回から使いやすい設定に整える
この記事は 2026 年 5 月 7 日時点の情報をもとにしています。Codex アプリの画面名やボタン名は、アップデートによって変わる場合があります。
このハンズオンで作るもの
このハンズオンでは、練習用フォルダに小さなメモファイルを作り、Codex に次の作業を依頼します。
- フォルダ構成を説明してもらう
- プロジェクト用の
AGENTS.mdを作る - README を改善する
- 変更内容を確認する
本番プロジェクトをいきなり触る必要はありません。まずは失敗しても困らない練習用フォルダで、Codex アプリの基本操作に慣れることを目的にします。
事前に準備するもの
| 必要なもの | 内容 |
|---|---|
| ChatGPT アカウント | Codex アプリにサインインするために使います。 （Codex アプリ は ChatGPT Plus、Pro、Business、Enterprise/Edu プランで使えます。） 注：期間限定で ChatGPT Free と Goプランで試用できます。（終了日未定） |
| Codex アプリ | Windows または macOS にインストールしておきます。 参考：Codexアプリインストール手順 |
| Git | 差分確認に使います。未インストールでも一部は試せますが、入れておくと理解しやすいです。 参考：はじめてのGit入門～手を動かしながら覚えるGitコマンド |
| 練習用フォルダ | デスクトップなどに新しく作ります。 |
Codex が利用できるプランや提供状況は変わる可能性があります。利用できない場合は、OpenAI の公式サイトで現在の対象プランを確認してください。
練習用フォルダを作る
まず、Codex に触ってもらうための小さな作業場所を作ります。
操作
- デスクトップに
codex-practiceというフォルダを作ります。 - フォルダの中に
README.mdを作ります。 README.mdに次の内容を書きます。
# Codex Practice
Codex アプリの操作を練習するためのフォルダです。
## やりたいこと
- Codex にフォルダの中身を説明してもらう
- README を読みやすくしてもらう
- 変更内容を確認するGit が使える場合は、このフォルダを Git 管理しておくと差分確認を体験できます。
git init
git add README.md
git commit -m "docs: add practice readme"確認ポイント
codex-practiceフォルダがある- その中に
README.mdがある README.mdを開くと文章が読める
Codex アプリを起動してサインインする
次に、Codex アプリを起動します。
操作
- Codex アプリを開きます。
- ChatGPT アカウントでサインインします。
- ワークスペースやプロジェクトを開く画面が表示されることを確認します。
つまずいたとき
サインインできない場合は、アカウントのプラン、会社や学校の管理者設定、ブラウザ認証の状態を確認します。管理されたワークスペースでは、管理者が Codex の利用を許可している必要がある場合があります。
作業フォルダを開く
Codex アプリで、先ほど作った codex-practice フォルダを開きます。
操作
- Codex アプリでファイル->Open folderと進みフォルダ選択画面を表示します。
codex-practiceフォルダを選びます。- Codex がフォルダ内のファイルを読める状態になっていることを確認します。
権限の考え方
最初は、作業対象のフォルダだけに読み書きを許可します。デスクトップ全体やホームフォルダ全体など、広い範囲を許可する必要はありません。
Codex アプリでは、権限は主に次の 3 か所で確認・変更できます。
- チャット画面下部の権限メニュー
ファイル→設定→権限設定→構成→config.toml
チャット画面では、入力欄の近くにある権限メニューから、現在の作業で使う権限を選べます。画面例では、次のような選択肢があります。
- デフォルト権限
- 自動レビュー
- フルアクセス
はじめて使う場合は、まず デフォルト権限 から始めます。作業内容に対して権限が足りない場合だけ、Codex が追加の許可を求める流れにすると確認しやすくなります。
より細かく確認したい場合は、ファイル → 設定 → 権限 を開きます。この画面では、次の 3 つを切り替えられます。
| 設定 | 内容 | 使う目安 |
|---|---|---|
| デフォルトの権限 | Codex がワークスペース内のファイルを読み取り・編集できます。必要に応じて追加アクセスを要求できます。 | 通常の作業で使います。 |
| 自動レビュー | Codex が追加アクセスのリクエストを自動でレビューします。 | 毎回の確認を減らしたい場合に使います。ただし判断ミスの可能性があります。 |
| フルアクセス | Codex が承認なしに広い範囲のファイル編集やネットワークを使うコマンドを実行できます。 | 信頼できる作業環境で、リスクを理解している場合だけ使います。 |
初心者向けには、デフォルトの権限 をオンにし、フルアクセス はオフにして始めるのが安全です。自動レビュー は便利ですが、権限昇格の判断を Codex に任せる部分が増えるため、最初は動きを理解してから使います。
さらに細かく制御したい場合は、設定 → 構成 → config.toml を開きます。画面例では、次の 2 つを設定できます。
| 設定 | 意味 | 初期学習でのおすすめ |
|---|---|---|
| 承認ポリシー | Codex がいつ承認を求めるかを決めます。 | On request |
| サンドボックスの設定 | コマンド実行時に Codex が操作できる範囲を決めます。 | Read only から始める |
たとえば、まず調査だけさせたい場合は、承認ポリシーを On request、サンドボックスを Read only にしておくと安全です。ファイル編集まで任せる段階になったら、作業対象フォルダに限定して書き込みを許可します。
権限は、次の順番で考えると安全です。
- 今回 Codex に頼む作業を 1 つに絞る
- その作業に必要なフォルダを確認する
- 読み取りだけで足りるか、書き込みも必要かを判断する
- コマンド実行が必要かを判断する
- ネットワークアクセスが必要かを判断する
- 危ない操作が含まれる場合は、実行前に確認を求める
- 作業後に、不要な権限を広げたままにしていないか見直す
| 権限 | 初心者向けの設定 |
|---|---|
| ファイル読み取り | codex-practice だけ許可する |
| ファイル書き込み | codex-practice だけ許可する |
| コマンド実行 | 必要になったら許可する |
| ネットワークアクセス | 今回は不要。必要なときだけ許可する |
判断に迷った場合は、許可せずに次のように聞きます。
今求めている権限が必要な理由を説明してください。
許可した場合に何が起きるか、許可しない場合に何ができないかを初心者向けに教えてください。
まだ実行はしないでください。確認ポイント
- Codex アプリ上で
README.mdが作業対象に含まれている - Codex が作業フォルダを認識している
- 不要に広いフォルダを開いていない
まずは「読むだけ」の依頼をする
最初の依頼では、コードやファイルを変更させません。Codex がフォルダを正しく読めているかを確認します。
入力する依頼文
このフォルダの内容を初心者向けに説明してください。
README.md の内容を確認し、この練習用フォルダで何を学べるかを短くまとめてください。
まだファイルは変更しないでください。見るポイント
Codex の回答で、次の内容が説明されていれば成功です。
README.mdがあること- Codex アプリの練習用フォルダであること
- まだ変更していないこと
もし Codex が関係ないファイルの話をしている場合は、開いているフォルダが間違っている可能性があります。
AGENTS.md を作ってルールを覚えさせる
次に、Codex に守ってほしい作業ルールを AGENTS.md にまとめます。
AGENTS.md は、Codex に対するプロジェクト固有の説明書です。毎回同じ注意点を入力しなくても、作業方針を伝えやすくなります。
入力する依頼文
この練習用フォルダに AGENTS.md を作成してください。
内容は初心者向けの Codex 練習用ルールにしてください。
含めてほしいルール:
- 回答は日本語で行う
- 実装前に既存ファイルを確認する
- 不要なファイルは作らない
- 変更後に何を変更したか説明する
- コミットはユーザーが行う確認ポイント
AGENTS.mdが作成されている- 日本語でルールが書かれている
- 「コミットはユーザーが行う」と書かれている
- 余計なファイルが増えていない
例
# Codex Practice Rules
- 回答は日本語で行う
- 実装前に既存ファイルを確認する
- 不要なファイルは作らない
- 変更後に変更内容を説明する
- コミットはユーザーが行うREADME を改善してもらう
ここで、はじめてファイル変更を依頼します。変更範囲を README.md だけに限定すると、初心者でも確認しやすくなります。
入力する依頼文
README.md を初心者が読みやすい形に改善してください。
条件:
- 変更するファイルは README.md だけにしてください
- 見出しを追加してください
- Codex アプリで何を練習するフォルダなのか分かるようにしてください
- 変更後に、どこを変えたか説明してください見るポイント
README.mdだけが変更されている- 内容が分かりやすくなっている
- 依頼していないファイルが作られていない
- Codex が変更内容を説明している
この段階で「少し違う」と感じたら、すぐに追加で依頼します。
README.md の説明が少し長いです。
初心者向けに、もっと短くしてください。
見出しは残してください。Codex への依頼は、一度で完璧に書く必要はありません。人に作業を頼むときと同じように、結果を見ながら調整していきます。
差分を確認する
Codex の変更は、必ず差分で確認します。
操作
Codex アプリに差分表示がある場合は、変更されたファイルを開いて差分を確認します。Git が使える場合は、ターミナルで次のように確認できます。
git diff確認ポイント
- 変更されたファイル名を見る
- 削除された行を見る
- 追加された行を見る
- 依頼と関係ない変更がないか見る
- 秘密情報や個人情報が入っていないか見る
初心者のうちは、差分が大きすぎる依頼を避けます。1 回の依頼で変更するファイルは 1 から 3 個程度にすると確認しやすくなります。
Codex に自己レビューさせる
変更ができたら、Codex にもう一度確認してもらいます。
入力する依頼文
今回の変更をレビューしてください。
初心者向けの記事として分かりにくい表現、不要な説明、直したほうがよい点があれば指摘してください。
問題がなければ、問題なしと教えてください。見るポイント
- 指摘が具体的か
- どのファイルのどこを直すべきか分かるか
- 不要に大きな修正を提案していないか
レビューで納得できる指摘が出たら、次のように修正を依頼します。
指摘された内容のうち、README.md の表現だけを修正してください。
AGENTS.md は変更しないでください。コミット前の確認をする
Git を使っている場合は、コミット前に状態を確認します。
操作
git status
git diff確認ポイント
- 変更対象が
README.mdとAGENTS.mdだけになっている - 内容を自分で読んで納得している
- Codex が勝手にコミットしていない
問題なければ、自分でコミットします。
git add README.md AGENTS.md
git commit -m "docs: add Codex practice guide"このハンズオンでは、「Codex が作業し、人間が確認してコミットする」という基本の流れを体験することが大切です。
本番プロジェクトで使う前の設定チェック
練習が終わったら、本番プロジェクトで使う前に次の項目を確認します。
| チェック項目 | 確認内容 |
|---|---|
| 作業フォルダ | 本当に対象プロジェクトだけを開いているか |
| 権限 | 不要に広い読み書き権限を与えていないか |
| Git | 作業用ブランチで作業しているか |
| 未コミット変更 | 自分の未保存作業が混ざっていないか |
| 秘密情報 | API キーやパスワードがファイルに入っていないか |
| テスト方法 | Codex に実行してほしいテストコマンドが分かっているか |
| AGENTS.md | プロジェクトのルールを書いているか |
本番プロジェクトでは、最初に次の依頼をすると安全です。
このプロジェクトの構成を確認してください。
主要なフォルダ、セットアップ方法、テスト方法、注意点を初心者向けにまとめてください。
まだファイルは変更しないでください。そのあと、小さな変更から始めます。
README のセットアップ手順だけを改善してください。
変更するファイルは README.md のみにしてください。
新しい依存関係は追加しないでください。MCP、プラグイン、アプリ連携、ペットを理解する
Codex アプリに慣れてくると、MCP、プラグイン、アプリ連携、コネクタ、スキルなどの単語が出てきます。どれも Codex にできることを増やす仕組みですが、役割が少しずつ違います。
まず、大きな関係は次のように考えると分かりやすいです。
Codex のプラグイン
├─ アプリ連携
│ └─ Gmail、Slack、Google Drive、カレンダーなど
├─ スキル
│ └─ 特定の作業手順を覚えさせるもの
└─ MCP
└─ 外部ツールにつなぐための仕組み厳密には、画面や環境によって「プラグイン」「コネクタ」「アプリ連携」の呼び方や表示位置が分かれることがあります。
ただ、初心者が全体像を理解するうえでは、プラグインは Codex に機能を追加する入れ物、アプリ連携は外部サービスにつなぐもの、スキルは作業手順を再利用するもの、MCP は外部ツールとつなぐための共通の仕組み と整理すると扱いやすくなります。
たとえば、Gmail を読む、Slack の内容を参照する、Google Drive の資料を探す、といったものはアプリ連携です。
記事作成、レビュー、資料作成の進め方を決めるものはスキルです。GitHub、社内検索、独自ツールなどを AI から呼び出せるようにする土台が MCP です。
| 用語 | ざっくりした意味 | 使う場面 |
|---|---|---|
| MCP | 外部ツールやデータを AI から使えるようにする共通の接続方式 | GitHub、社内ツール、ドキュメント検索などを Codex から扱いたいとき |
| プラグイン | Codex アプリに機能を追加するまとまった部品 | ブラウザ操作、資料作成、表計算、外部サービス連携などを使いたいとき |
| アプリ連携 | Gmail、Slack、Google Drive、カレンダーなどのアプリをCodexにつなぐ機能 | メール、予定、ファイル、チャット履歴など、自分のアプリ内情報をCodexに参照させたいとき。 アプリ連携はプラグインの中に含まれる機能のひとつです。 |
| コネクタ | Gmail、Slack、GitHub など特定サービスにつなぐための連携 | 自分のアカウントにある情報を Codex に参照させたいとき |
| スキル | 特定の作業手順を Codex に覚えさせる説明書 | 毎回同じ進め方でレビュー、記事作成、テストをしたいとき |
| ペット | Codex pets と呼ばれる機能で、Codexアプリ上に表示できるアニメーション付きの小さなコンパニオン機能です。 | 作業状況を分かりやすくするUI補助機能 |
OpenAI の開発者ページでは、ChatGPT アプリを MCP の上に構築できることや、Codex が外部連携を含むワークフローに使えることが紹介されています。
つまり MCP は、Codex や AI アプリが外部の道具を安全に呼び出すための土台として考えると理解しやすいです。
MCP を触る前に確認すること
MCP は便利ですが、外部の情報や操作権限につながることがあります。最初は、何につなぐのかをはっきりさせてから使います。
- 何のサービスにつなぐのか
- 読み取りだけか、書き込みもできるのか
- 個人情報や秘密情報を扱うのか
- 失敗したときに何が起きるのか
- 不要になったら無効化できるのか
初心者向けには、まず「公式ドキュメント検索」「ローカルの開発補助」「読み取り専用の連携」から試すのがおすすめです。
Codex アプリの MCP 画面で扱うのは、Codex から接続する MCP サーバー です。その中でも、ユーザーが自分で追加するものを カスタム MCP サーバー と考えると分かりやすいです。
カスタム MCP サーバー
└─ 自分で用意した外部ツールを Codex につなぐ設定つまり、「Codex の MCP = カスタム MCP サーバーだけ」というより、Codex は MCP サーバーに接続できる、その接続先を自分で追加する場合がカスタム MCP サーバー、という理解が正確です。
カスタム MCP サーバーの設定へは、ファイルー＞MCPサーバーから進めます。
MCP サーバー 画面では、接続中の MCP サーバーを確認し、サーバーを追加する から新しい接続を追加できます。
カスタム MCP に接続する 画面では、主に次の項目を設定します。
| 項目 | 内容 |
|---|---|
| 名前 | Codex 上で表示する MCP サーバー名です。例: context7、sqlite、playwright |
| STDIO | Codex がローカルコマンドを起動して MCP サーバーと通信する方式です。 |
| ストリーミング可能な HTTP | すでに起動している HTTP 型 MCP サーバーの URL に接続する方式です。 |
| 起動用コマンド | STDIO の場合に実行するコマンドです。例: npx、uvx、cmd |
| 引数 | 起動用コマンドに渡す値です。例: -y、@playwright/mcp@latest |
| 環境変数 | API キーや接続設定を渡します。秘密情報はここで扱います。 |
| 環境変数パススルー | 既存の環境変数を MCP サーバーに渡したい場合に使います。 |
| 作業ディレクトリ | MCP サーバーを起動する場所です。 |
Codexの設定ファイルでは、STDIOサーバーに command、args、env、env_vars、cwd などを指定できます。
参考：Model Context Protocol – Codex | OpenAI Developers
カスタム MCP サーバーの追加手順
設定を開くMCP サーバーを開くサーバーを追加するを選ぶ名前を入力する- 接続方式を
STDIOまたはストリーミング可能な HTTPから選ぶ - STDIO の場合は、
起動用コマンド、引数、必要な環境変数を入力する - HTTP の場合は、MCP サーバーの URL と必要なヘッダーを入力する
- 必要に応じて
作業ディレクトリを指定する - 保存する
- Codex のチャットで、その MCP が使えるか確認する
MCP の通信方式は、仕様上 STDIO と Streamable HTTP が標準的な方式として定義されています。STDIO は Codex がローカルの MCP サーバーコマンドを起動する方式、HTTP は起動済みの MCP サーバー URL に接続する方式です。
Context7 MCP の設定例
Context7 MCP は、ライブラリやフレームワークの最新ドキュメントを Codex から参照したいときに使います。
名前: context7
方式: STDIO
起動用コマンド: npx
引数:
-y
@upstash/context7-mcp
環境変数:
CONTEXT7_API_KEY=YOUR_API_KEYWindows で npx がうまく起動しない場合は、次のように cmd 経由にします。
名前: context7
方式: STDIO
起動用コマンド: cmd
引数:
/c
npx
-y
@upstash/context7-mcp
--api-key
YOUR_API_KEYHTTP 型で追加する場合の例です。
名前: context7
方式: ストリーミング可能な HTTP
URL: https://mcp.context7.com/mcp
ヘッダー:
Authorization: Bearer YOUR_API_KEYContext7 は API キーなしでも基本利用できる構成が案内される場合がありますが、制限や認証方式は変わる可能性があります。実際に使うときは Context7 の公式ドキュメントを確認してください。
使いどころ
Codexにこう頼めます。
Context7を使って、Next.js App Routerの最新仕様を確認しながら、
このpage.tsxを修正してください。SQLite MCP の設定例
SQLite MCP は、ローカルの SQLite データベースを Codex から確認・分析したいときに使います。
名前: sqlite
方式: STDIO
起動用コマンド: openai-dev-mcp
引数:
serve-sqlite
--db-path
C:\path\to\database.db
作業ディレクトリ:
C:\path\to\project別の SQLite MCP 実装を使う場合は、配布元の README に書かれている起動コマンドを 起動用コマンド と 引数 に分けて入力します。たとえば、公式リファレンス系の SQLite MCP では uv や Docker を使う例があります。
名前: sqlite
方式: STDIO
起動用コマンド: uv
引数:
--directory
C:\path\to\servers\src\sqlite
run
mcp-server-sqlite
--db-path
C:\path\to\database.dbSQLite MCP はデータベースの中身を扱うため、本番データベースを直接つなぐ前に、コピーした検証用 .db ファイルで試してください。
使いどころ
SQLite MCPを使って、記事データベースのテーブル構造を確認し、
投稿タイトルとカテゴリ一覧を整理してください。ただし、DBを扱うMCPは安全のため、最初は読み取り専用で使うのがおすすめです。
Playwright MCP の設定例
Playwright MCP は、Codex からブラウザを操作して画面確認や E2E 的な調査をしたいときに使います。
名前: playwright
方式: STDIO
起動用コマンド: npx
引数:
@playwright/mcp@latestブラウザを表示せずに動かしたい場合は、--headless を追加します。
名前: playwright
方式: STDIO
起動用コマンド: npx
引数:
@playwright/mcp@latest
--headlessHTTP 型で使う場合は、先に Playwright MCP サーバーを起動します。
npx @playwright/mcp@latest --port 8931そのうえで Codex 側では次のように設定します。
名前: playwright-http
方式: ストリーミング可能な HTTP
URL: http://localhost:8931/mcpローカルで HTTP 型 MCP を起動する場合は、基本的に localhost に限定します。外部からアクセスできる 0.0.0.0 で公開すると、意図しない接続リスクが増えます。
HTTP 型 MCP の設定例
HTTP 型 MCP は、MCP サーバーがすでに URL として起動している場合に使います。ローカルサーバーでも、クラウド上のサーバーでも構いません。
名前: my-http-mcp
方式: ストリーミング可能な HTTP
URL: http://localhost:3000/mcp
ヘッダー:
Authorization: Bearer YOUR_TOKENHTTP 型 MCP を使う前に、次の点を確認します。
- URL が正しいか
- 認証ヘッダーが必要か
- 外部に公開されていないか
- どのツールを Codex に使わせるのか
- 読み取り専用にできるか
MCP の仕様では、HTTP 型サーバーは Origin ヘッダーの検証、localhost へのバインド、適切な認証が重要とされています。特にローカル MCP サーバーを公開するときは、外部サイトから勝手に操作されないように注意してください。
プラグインを使う前に確認すること
プラグインは、Codex アプリに便利な機能を追加します。たとえば、ブラウザで画面を確認する、PowerPoint を作る、スプレッドシートを編集する、といった作業に使われます。
- そのプラグインが何をするものか
- どのファイルやサービスにアクセスするのか
- 作業対象のプロジェクトに本当に必要か
- 使わないときに無効化できるか
最初から多くのプラグインを入れる必要はありません。このハンズオンでは、まず Codex アプリ本体の基本操作に慣れ、そのあと必要になったものだけ追加します。
アプリ連携について
アプリ連携は、Gmail、Slack、Google Drive、カレンダーなど、外部サービスの情報を Codex から扱えるようにする機能です。
たとえば、次のような使い方があります。
- Gmail のメール内容を確認して要点をまとめる
- Slack のやり取りを読んでタスクを整理する
- Google Drive 上の資料を探して内容を要約する
- カレンダーの予定を確認して作業計画を立てる
アプリ連携を使う前には、次の点を確認します。
- どのアカウントにつなぐのか
- 読み取りだけか、書き込みも許可するのか
- 個人情報や社外秘の情報を扱うのか
- Codex にどの範囲まで参照させるのか
- 作業後に連携を外す必要があるか
アプリ連携は便利ですが、メール、チャット、ドライブ、予定表には機密情報が含まれやすいです。
最初は読み取り中心の作業から始め、送信、削除、共有、予定変更のような操作は、必ず内容を確認してから実行します。
ペットについて
Codex アプリには、ペット という設定があります。
これは、Codex の動作権限やモデル性能を変える設定ではなく、アプリ内で表示される相棒キャラクターを選ぶための設定です。
ペットを起こすと画面上に常に表示され、Codex アプリの動作を知ることができます。
画面例では、Codex、Dewey、Fireball、Rocky、Seedy、Stacky、BSOD、Null Signal などのペットを選べます。選んだペットは、Codex アプリ内の表示や雰囲気を変えるためのものです。
ペットを変更する手順は次のとおりです。
- 画面上部の
ファイルを開く 設定を開くペットを開く- 一覧から使いたいペットを選ぶ
選択を押す- 必要に応じて
更新を押す。 - ペットを起こす
12. スキルを使って作業手順を再利用する
Codexアプリのスキルは、簡単にいうと 「Codexに作業手順を覚えさせる仕組み」つまり「手順書」です。
たとえば、毎回同じように、
1. まず仕様を読む
2. 関連ファイルを確認する
3. 修正案を作る
4. テストを実行する
5. 変更点をまとめるという作業をしているなら、その手順をスキル化しておくと、Codexが次回から同じ流れで作業しやすくなります。
スキルは instructions、resources、optional scripts をまとめ、Codexが特定のワークフローを安定して実行できるようにするもので、Codex CLI、IDE拡張、Codexアプリで利用できます。
参考：Agent Skills – Codex | OpenAI Developers
ファイルとしてはどういう形か
スキルは一般的に、SKILL.md という説明ファイルを中心に作ります。
プラグインとして配布する場合は、公式ドキュメントでは次のような構成例が示されています。
my-plugin/
├─ .codex-plugin/
│ └─ plugin.json
└─ skills/
└─ my-skill/
└─ SKILL.mdSKILL.md に「この作業では、こういう順番で進めてください」と書くイメージです。
AGENTS.md とスキルの違い
AGENTS.md とスキルは似ていますが、使いどころが違います。
| 項目 | AGENTS.md | スキル |
|---|---|---|
| 主な目的 | プロジェクト全体のルールを伝える | 特定作業の進め方を再利用する |
| 置き場所 | プロジェクトの中 | Codex のスキル管理場所やプラグイン内 |
| 例 | 回答言語、テスト方針、コミット方針 | 記事作成手順、レビュー手順、資料作成手順 |
| 初心者向けの使い方 | まず作る | 慣れてから必要な作業だけ作る |
参考：Agent Skills – Codex | OpenAI Developers
初心者は、まず AGENTS.md でプロジェクトの基本ルールを書きます。
そのあと、同じ作業を何度も繰り返すようになったらスキル化を考えると自然です。
スキルに向いている作業
スキルに向いているのは、毎回ほぼ同じ流れで進める作業です。
- ブログ記事を作る
- コードレビューをする
- README を改善する
- テスト方針を確認する
- PowerPoint や Word 文書を作る
- リリースノートを書く
- 問い合わせ内容を整理する
一方で、1 回しか使わない作業や、毎回判断が大きく変わる作業は、無理にスキル化しなくても問題ありません。
初心者向けのスキル例
たとえば、ブログ記事を書く作業をスキル化するなら、次のような内容にします。
# ブログ記事作成スキル
このスキルは、初心者向けの技術記事を作成するときに使う。
## 進め方
1. 読者の前提知識を確認する
2. 記事のゴールを明確にする
3. 見出し案を作る
4. 手を動かせる手順を入れる
5. 注意点とトラブル対処を入れる
6. 最後に WordPress に貼れる形式に整える
## 文体
- 日本語で書く
- 短い文を使う
- 専門用語は最初に説明する
- 操作手順は番号付きリストにするこのようなスキルがあると、毎回「初心者向けに」「手順を入れて」「WordPress 形式で」と細かく伝えなくても、同じ品質で記事を作りやすくなります。
実際に Codex にスキル化を相談する
いきなりスキルを作るより、まず Codex に「この作業はスキル化に向いているか」を聞くと安全です。
今後も同じような初心者向け記事を何度も作ります。
この作業を Codex のスキルとして再利用するなら、どんな内容をスキルに書くべきか提案してください。
まだファイルは作成しないでください。内容に納得できたら、次のように依頼します。
提案内容をもとに、初心者向け記事作成スキルの下書きを作ってください。
目的、使う場面、進め方、文体ルール、確認ポイントを含めてください。スキルを使うときの注意点
スキルは便利ですが、万能ではありません。
- 古い手順が残ると、毎回古い方法で作業してしまう
- プロジェクト固有のルールは
AGENTS.mdに書いたほうがよい - 外部サービスやプラグインを使うスキルは、権限確認が必要
- スキルの内容が長すぎると、重要な指示が埋もれやすい
スキルは「よく使う作業の型」です。プロジェクトの基本ルールは AGENTS.md、外部サービスとの接続は MCP やコネクタ、機能追加はプラグイン、作業手順の再利用はスキル、と分けて考えると整理しやすくなります。
OpenAI公式のスキル
Codex公式ページで、Playwright / ImageGen / OpenAI Docsを使った「ブラウザゲーム作成」がSkills & Plugins として紹介されています。
参考：Create browser-based games | Codex use cases
よく使う依頼文テンプレート
調査だけしてほしい
原因を調査してください。
まだファイルは変更しないでください。
分かったこと、関係しそうなファイル、次に取るべき対応をまとめてください。変更範囲を限定したい
変更するファイルは次の 1 つだけにしてください。
- README.md
他のファイル変更が必要だと判断した場合は、変更せずに理由を教えてください。テストも確認してほしい
修正後に関連するテストを実行してください。
テストが実行できない場合は、理由と代わりに確認した内容を教えてください。差分を説明してほしい
今回の変更内容を初心者向けに説明してください。
変更したファイル、変更理由、確認したことを短くまとめてください。コミットメッセージを考えてほしい
今回の変更に合うコミットメッセージを 1 行で提案してください。
Conventional Commits の形式にしてください。よくあるトラブルと対処法
Codex が関係ないファイルを読んでいる
開いているフォルダが広すぎる可能性があります。作業対象のプロジェクトフォルダだけを開き直してください。
変更が大きすぎて確認できない
依頼を小さくします。「まず 1 ファイルだけ」「まず調査だけ」「UI は変更しない」のように制約を入れます。
期待と違う文体になった
文体の例を渡します。
次の文体に合わせて書き直してください。
- 短い文を使う
- 専門用語を避ける
- 手順は番号付きリストにするコマンドが失敗する
必要な開発環境がローカルに入っていない可能性があります。Node.js、Python、Docker など、プロジェクトに必要なツールを確認してください。Codex には、失敗した理由と次に確認することを説明してもらうと進めやすくなります。
コマンドが失敗した理由を初心者向けに説明してください。
次に確認すべきことを順番に教えてください。まとめ
Codex アプリの設定は、最初から細かい項目をすべて覚える必要はありません。
まずは練習用フォルダで、次の基本操作を体験することが大切です。
- 作業フォルダを開く
- 読むだけの依頼をする
AGENTS.mdでルールを伝える- 小さな変更を依頼する
- 差分を確認する
- 自分でコミットする
この流れに慣れると、本番プロジェクトでも Codex に安全に作業を任せやすくなります。大きな作業ほど、最初は調査だけ、小さな修正だけ、1 ファイルだけ、という形に分けて進めましょう。
参考リンク
- Using Codex with your ChatGPT plan – OpenAI Help Center
- Codex use cases – OpenAI Developers
- OpenAI Developers
関連記事
