Codexを使う前に、まずCodexアプリの全体像を知っておこう

Codexを使ってみたい。
でも、いざ調べ始めると、出てくる言葉が多すぎます。
Codex app。
Codex CLI。
Local。
Worktree。
Cloud。
Review。
Plugins。
Skills。
MCP。
Automations。
Computer Use。
GitHub。
Pull Request。
Claude Codeとの違い。
便利そうなのは分かる。
でも、最初にどこを押せばいいのか分からない。
こう感じている人は多いと思います。
特に、ターミナルやGitに慣れていない人は、Codexの説明を読んでも途中で止まりやすいです。
「CLIって何?」
「Codex appとCodex CLIは違うの?」
「LocalとWorktreeは何が違うの?」
「プラグインは入れた方がいいの?」
「オートメーションって初心者が使っても大丈夫?」
「Computer Useって何をしてくれるの?」
「Claude Codeと同じように使えばいいの?」
このnoteは、そんな人のための前段階の入門です。
有料本編では、Codexへの具体的な依頼文、Claude Codeとの使い分け、7日間の練習課題、実装の進め方まで扱います。
ただ、その前にCodexアプリの画面の役割が分かっていないと、最初の一歩で迷います。
なので、このnoteでは、Codexアプリのタブや機能を「初心者が何をする場所か」という視点で整理します。
まず結論から言うと、Codexアプリはこう考えると分かりやすいです。
Codexアプリ = AIに作業を頼み、変更を分けて、結果をレビューする作業司令室
チャットだけの場所ではありません。
コードを書いてもらうだけの場所でもありません。
Codexアプリは、
- プロジェクトを選ぶ
- 作業スレッドを作る
- Local / Worktree / Cloudを選ぶ
- Codexに依頼する
- 変更内容をReviewする
- 必要ならGitHubへつなげる
- プラグインで機能を増やす
- オートメーションで繰り返し作業を任せる
ための場所です。
この全体像が分かるだけで、Codexはかなり怖くなくなります。
最初に注意しておきたいこと

Codexまわりの機能は、かなり速いペースで変わっています。
このnoteは、2026年5月8日時点の公式情報をもとに、初心者向けに整理しています。
今後、画面の名前、配置、利用できるプラン、上限、対応OS、プラグインの仕様、Automationの動き方が変わる可能性があります。
また、この記事では画面の入口やサイドバー項目をまとめて「タブ」と呼びます。実際のアプリ上では、タブ、サイドバー、パネル、設定画面など呼び方が分かれる場合があります。
大事なのは、名前を丸暗記することではありません。
大事なのは、
これは相談する場所なのか これは作業を任せる場所なのか これは変更を確認する場所なのか これは自動化する場所なのか
を判断できることです。
画面が少し変わっても、この考え方があれば迷いにくくなります。
Codexアプリで最初に見るべき場所

Codexアプリを開いたら、最初に全部を理解しようとしなくて大丈夫です。
最初に見るべき場所は、だいたい次の5つです。
1. Project / Workspace 2. Thread 3. Composer 4. Review 5. Settings
初心者は、まずこの5つだけ分かれば十分です。
Plugins、Automations、Computer Useは便利ですが、最初から触る必要はありません。
順番としては、こうです。
まずProjectを選ぶ 次にThreadを作る Composerに依頼を書く Codexが作業する Reviewで変更を見る 必要ならSettingsを確認する 慣れてからPluginsやAutomationsに進む
いきなりAutomationを作ったり、Computer Useに広い操作を任せたりしない方が安全です。
Codexは強い道具なので、最初は小さく使う方がうまくいきます。
Project / Workspace: 作業するフォルダを選ぶ場所

ProjectやWorkspaceは、Codexに見てもらう作業場所です。
初心者向けに言うと、
このフォルダの中身を見て、ここで作業してください
と指定する場所です。
Codexは、何もないところから急にあなたのパソコン全体を理解するわけではありません。
どのフォルダを対象にするかを決める必要があります。
たとえば、あなたがWebページを作っているなら、Webページのファイルが入っているフォルダを選びます。
note販売用の特典ページを作っているなら、その特典ページのプロジェクトフォルダを選びます。
この時、初心者がやりがちな失敗があります。
パソコン全体 ダウンロードフォルダ全体 デスクトップ全体 関係ないファイルが大量に入ったフォルダ
を選んでしまうことです。
Codexに見せる範囲が広すぎると、Codexも何を見ればいいか分かりにくくなります。
最初は、作業に必要なファイルだけが入ったフォルダを選ぶのがおすすめです。
Thread: 1つの相談や作業を進める場所

Threadは、Codexとの作業部屋です。
ChatGPTやClaudeで言うところの会話に近いですが、Codexの場合はコードやファイル変更と結びつきます。
初心者は、Threadを次のように使うと分かりやすいです。
1つの目的につき、1つのThread
たとえば、
- READMEを分かりやすくするThread
- ボタンの文言を変えるThread
- エラー原因を調べるThread
- トップページのデザインを整えるThread
- テストの失敗を調べるThread
というように分けます。
1つのThreadに、あれもこれも詰め込むと混乱します。
悪い例はこれです。
このアプリを全体的に良くして、デザインも直して、エラーも消して、売れるページにして、SEOも強くしてください
気持ちは分かります。
でも、Codexに頼むには大きすぎます。
最初は、こう分けた方がうまくいきます。
まず現状を確認してください。 まだファイルは変更しないでください。 このプロジェクトの目的、主要ファイル、次に改善できる小さな作業を3つ教えてください。
Threadは、作業を小さく分けるための場所です。
Composer: Codexに依頼を書く場所

Composerは、Codexに依頼文を書く場所です。
ここがいちばん大事です。
Codexが賢くても、依頼が大きすぎたり、目的が曖昧だったりすると、望んだ結果になりにくいです。
初心者は、Composerに次の5つを入れると安定します。
1. 自分の状況 2. 目的 3. やってほしいこと 4. やらないでほしいこと 5. 完了条件
たとえば、最初の依頼はこれで十分です。
私はCodex初心者です。 このプロジェクトの中身を確認してください。 目的: まず、何のファイルがあり、どこを触ればよいか知りたいです。 やってほしいこと: - プロジェクトの構成を説明する - 主要ファイルを教える - 初心者が最初に頼める小さな改善案を3つ出す やらないでほしいこと: - まだファイルは変更しない - 大きなリファクタリングは提案だけにする 完了条件: 初心者向けに、次に何を頼めばよいか分かる状態にしてください。
このように書くと、Codexは勝手に作業を広げにくくなります。
「まだ変更しないでください」は、最初のうちはかなり大事です。
Local / Worktree / Cloud: どこで作業させるか

Codexアプリで混乱しやすいのが、Local、Worktree、Cloudです。
ざっくり言うと、こうです。
Local: 今の作業場所でそのまま進める Worktree: 別の作業場所を作って、変更を分けて進める Cloud: ローカルPCから離して、クラウド側で作業を進める
初心者は、まずLocalからで大丈夫です。
ただし、Localで大きな変更をさせるのは怖いので、最初は「確認だけ」「小さな修正だけ」にします。
Localが向いている作業
Localは、今の作業場所でCodexに見てもらう方法です。
向いているのは、次のような作業です。
- 現状確認
- READMEの改善
- 文言修正
- 小さなUI修正
- 軽いエラー調査
- 変更範囲がはっきりしている作業
Localを使う時の依頼文は、こうです。
Localで作業してください。 変更範囲は最小限にしてください。 まず作業方針を説明してから進めてください。 変更後は、どのファイルをどう変えたか説明してください。
Worktreeが向いている作業
Worktreeは、変更を分けたい時に使います。
初心者向けに言うと、
今の作業を壊さず、別案を試すための作業場所
です。
たとえば、次のような時に向いています。
- デザイン案を別で試したい
- 大きめの修正を試したい
- 2つの改善案を比較したい
- 途中で戻せるようにしておきたい
- 本番に近いファイルを直接触るのが怖い
Worktreeを使う時の依頼文は、こうです。
Worktreeで別作業として進めてください。 今の作業状態を壊さずに試したいです。 目的: トップページの見た目を少し整えることです。 条件: - 変更範囲を説明してから進める - 大きな設計変更はしない - 取り込む前に、変更点とリスクを説明する
Worktreeは、初心者ほど早めに知っておくと安心です。
「失敗したら全部壊れるかも」という不安が減ります。
Cloudが向いている作業
Cloudは、クラウド側でCodexに作業を進めてもらうイメージです。
向いているのは、次のような作業です。
- 時間がかかる調査
- GitHub上の作業
- Pull Requestにつなげたい作業
- ローカルPCに強く依存しない作業
- 別環境で確認したい作業
ただし、初心者が最初からCloudに大きな作業を任せると、どこで何が起きたか分かりにくくなる場合があります。
最初はLocalで慣れる。
次にWorktreeで分ける。
慣れてからCloudを使う。
この順番がおすすめです。
Review: Codexが変えた内容を確認する場所

Reviewは、Codexが作った変更を見る場所です。
ここは絶対に飛ばさない方がいいです。
Codexを使う時の基本は、
頼む 作業してもらう Reviewで差分を見る 必要なら直してもらう 最後に取り込む
です。
Reviewでは、主に次を確認します。
- どのファイルが変わったか
- どの文章やコードが変わったか
- 依頼していない変更が入っていないか
- 削除されて困るものが消えていないか
- 見た目や動作に影響がありそうか
- Codexの説明と実際の変更が合っているか
初心者は、コードの全部を読めなくても大丈夫です。
まずは、次の3つだけ見てください。
知らないファイルが大量に変わっていないか 依頼していない大きな変更が入っていないか Codexの説明が理解できるか
理解できない変更があったら、そのまま取り込まずに聞きます。
この変更の意味が分かりません。 初心者向けに、どのファイルをなぜ変更したのか説明してください。 また、この変更を取り込むリスクがあれば教えてください。
Reviewは、Codexを安全に使うためのブレーキです。
Codexに任せるほど、Reviewが大事になります。
Settings: 最初に確認しておきたい設定

Settingsは、Codexアプリの設定を見る場所です。
初心者が最初に見るべきなのは、細かい全部ではありません。
まずは次のような項目を確認します。
- サインインしているアカウント
- 対象のプラン
- プロジェクトやフォルダへのアクセス
- GitHub連携
- Pluginsの状態
- Automationsの状態
- 権限が広すぎないか
設定で大事なのは、便利にすることよりも、どこまでCodexに触らせるかを把握することです。
特に、GitHub、プラグイン、Computer Use、Automationは、作業範囲が広がりやすいです。
最初は、必要な時に必要な分だけ有効にするくらいで大丈夫です。
Plugins: Codexアプリの機能を増やす仕組み

Pluginsは、Codexアプリに機能を追加するための仕組みです。
公式ドキュメントでは、Codex Pluginsは、Skills、MCP servers、Appsなどをまとめて扱うものとして案内されています。
初心者向けに言うと、
Codexに追加の道具や専門知識を持たせる仕組み
です。
たとえば、プラグインによっては、
- ブラウザ操作をしやすくする
- ドキュメント作成をしやすくする
- スプレッドシートを扱いやすくする
- 特定サービスと連携する
- 決まった作業手順をCodexに覚えさせる
ようなことができます。
ただし、初心者が最初からプラグインをたくさん入れる必要はありません。
プラグインは、困りごとが出てから入れる方が分かりやすいです。
Skills / MCP / Appsの違い

Pluginsの話で出てくる言葉に、Skills、MCP、Appsがあります。
最初は、ざっくりこう理解すれば大丈夫です。
Skill: Codexに作業手順や専門知識を渡すもの MCP: 外部ツールやデータにつなぐための仕組み App: Codex内で使えるアプリ的な機能や体験
もっと簡単に言うと、
Skill = 作業のコツ MCP = 外部との接続 App = 使いやすい画面や機能
です。
初心者が最初に覚えるべきことは1つだけです。
プラグインを入れるほど、Codexにできることは増える。 その分、何にアクセスできるかも確認する。
便利さと権限はセットで考えます。
プラグインを使う前のチェックリスト

プラグインを入れる前に、次を確認してください。
□ 何のために入れるプラグインか分かっている □ 使わなくてもできる作業ではないか確認した □ どのファイルやサービスにアクセスするか確認した □ 公式または信頼できる提供元か確認した □ 入れた後に、まず小さな作業で試す □ 不要になったら無効化または削除できるか確認した
最初のおすすめは、次の考え方です。
今困っている作業がある その作業を助けるプラグインだけ入れる 小さな依頼で試す うまくいったら次に進む
プラグインは、入れれば入れるほど良いものではありません。
「何のために使うか」が分かっている時に強いです。
Automations: 繰り返し作業をCodexに任せる機能

Automationsは、繰り返し行う作業をCodexに任せる機能です。
初心者向けに言うと、
毎回同じように確認する作業を、Codexに定期的にやってもらう仕組み
です。
たとえば、次のような使い方が考えられます。
- 毎朝、プロジェクトの変更状況を確認する
- 毎週、READMEの古い情報がないか見る
- 週1回、リンク切れがないか確認する
- 定期的にエラーやテスト結果をまとめる
- 投稿予定や記事改善のチェックリストを作る
- GitHubの未対応作業を整理する
Automationsは便利です。
でも、初心者が最初から「勝手に直して、勝手に公開して」と頼むのはおすすめしません。
最初は、読み取りと報告だけに寄せるのが安全です。
初心者向けAutomationの作り方

最初のAutomationは、こういう内容がおすすめです。
目的: 毎朝、このプロジェクトの状態を確認する。 やってほしいこと: - 前回から変わったファイルがあれば要約する - 未完了のTODOがあれば一覧にする - エラーや注意点がありそうなら報告する - 次に人間が確認すべきことを3つ出す やらないでほしいこと: - ファイルは変更しない - Git操作はしない - 外部公開はしない - 勝手に削除しない 出力: 短いレポート形式でまとめる
ポイントは、「直す」ではなく「確認する」にすることです。
最初から自動修正にすると、何が変わったか追いにくくなります。
慣れてから、少しずつ任せる範囲を広げます。
Automationに向いている作業、向いていない作業

Automationに向いているのは、同じ基準で何度も確認する作業です。
向いている作業:
- 変更状況の確認
- TODOの整理
- リンクや文章の確認
- 定期レポート
- 軽い品質チェック
- 投稿予定の棚卸し
- 期限が近い作業の整理
向いていない作業:
- 一発勝負の大きな判断
- 誤操作が怖い削除や公開
- 決済や個人情報に関わる操作
- 人間の判断が必要な契約や交渉
- 目的が曖昧なままの自動修正
Automationは、手を離すための機能ではあります。
ただし、最初から完全に手を離すためのものではありません。
初心者は、
Codexが確認する 人間が判断する 必要ならCodexに修正を頼む
の順番で使うと安全です。
Automation依頼文テンプレ
そのまま使える形で置いておきます。
このプロジェクトを定期的に確認するAutomationを作りたいです。 目的: 作業の抜け漏れを減らすことです。 頻度: 毎日1回 やってほしいこと: - 前回から変わったファイルを要約する - 未完了のTODOやFIXMEを探す - エラーや注意点がありそうな箇所を報告する - 次に確認すべき作業を3つ提案する やらないでほしいこと: - ファイル変更 - Git操作 - 外部公開 - 削除 - 大きな設計変更 出力形式: 1. 今日の状況 2. 気になる点 3. 次に確認すること 4. 人間に判断してほしいこと
このくらい狭く始めると、Automationが怖くなりにくいです。
Computer Use: 画面を見て操作してもらう機能

Computer Useは、Codexが画面を見て、アプリやブラウザを操作できる機能です。
便利ですが、扱いは慎重でいいです。
初心者向けに言うと、Computer Useは、
コードだけでは確認できない画面操作を、Codexに見てもらう機能
です。
たとえば、
- ボタンが見えているか確認する
- 画面崩れがないか見る
- ブラウザ上でページを開く
- ログイン不要の範囲で動作を確認する
- UIの見た目を確認する
ような作業に向いています。
ただし、次のような作業は慎重に扱います。
- 決済操作
- 個人情報が見える画面
- 重要アカウントの設定変更
- 削除操作
- 外部公開
- 取り消しにくい操作
Computer Useを使う時は、範囲を狭くします。
Computer Useで画面を確認してください。 対象: ローカルで開いているこのページだけです。 やってほしいこと: - 表示崩れがないか見る - ボタンが見えているか確認する - クリックは確認が必要な場合だけ提案する やらないでほしいこと: - ログイン - 決済 - 外部公開 - 削除 - 設定変更 - 個人情報が見える画面の操作 最後に、見つけた問題と修正案を説明してください。
Computer Useは、「広く任せる」より「狭く確認してもらう」方が安全です。
Codexアプリ初心者のおすすめ順番

ここまでいろいろ出てきました。
最初から全部使う必要はありません。
初心者は、この順番で十分です。
1. Projectを選ぶ 2. Threadを作る 3. 現状確認だけ頼む 4. 小さな修正だけ頼む 5. Reviewで差分を見る 6. Worktreeで別案を試す 7. Pluginsを必要な分だけ使う 8. Automationは読み取りと報告から使う 9. Computer Useは狭い画面確認だけに使う
いきなり高度な使い方に進まなくて大丈夫です。
Codexは、使い方を小さくするとかなり扱いやすくなります。
最初の1日目にやること
1日目は、作業をさせなくて大丈夫です。
まずは、Codexにプロジェクトを説明してもらいます。
私はCodex初心者です。 このプロジェクトを確認して、初心者向けに説明してください。 やってほしいこと: - 何のプロジェクトか推測する - 主要なファイルを説明する - 変更すると影響が大きそうな場所を教える - 初心者が最初に頼める小さな作業を3つ出す やらないでほしいこと: - ファイル変更 - Git操作 - 大きな設計変更 出力: 専門用語はなるべくかみ砕いて説明してください。
これだけで十分です。
Codexに慣れる最初の目的は、アプリを完成させることではありません。
まずは、Codexが何を見て、どう説明するかを知ることです。
2日目にやること
2日目は、小さな変更を1つだけ頼みます。
おすすめは、文章差し替えやREADME改善です。
このプロジェクトのREADMEを初心者にも分かりやすく整えてください。 条件: - 内容を大きく変えない - 事実が分からない部分は推測で書かない - 変更前に方針を説明する - 変更後に、どこをどう直したか説明する 完了条件: 初めて見る人が、何のプロジェクトか分かるREADMEにすること。
READMEや文章変更は、比較的リスクが低く、Reviewの練習にも向いています。
3日目にやること
3日目は、Reviewに慣れます。
Codexが変更した後に、こう聞きます。
今回の変更について、初心者向けに説明してください。 知りたいこと: - 変更したファイル - 変更した理由 - 動作への影響 - 取り込む前に確認すべきこと - 元に戻す場合の考え方
Reviewは、最初は面倒に感じます。
でも、Reviewに慣れるとCodexへの不安がかなり減ります。
「Codexが何か勝手にやったら怖い」ではなく、
Codexにやってもらう Reviewで見る 分からなければ説明させる 必要なら直させる
という流れに変わります。
よくある失敗

失敗1 いきなり大きく頼む
最初から、
このサービスを完成させてください
と頼むと、範囲が広すぎます。
最初は、
現状確認だけ READMEだけ ボタン文言だけ 1画面だけ エラー1つだけ
にします。
失敗2 Reviewを見ずに進める
Codexが作った変更を見ずに進めると、あとから困ります。
コードが読めなくても、変わったファイル数、変更された場所、Codexの説明は確認してください。
失敗3 プラグインを入れすぎる
プラグインは便利ですが、最初から大量に入れると何が効いているのか分かりにくくなります。
1つ入れる。
小さく試す。
必要なら次を入れる。
この順番で十分です。
失敗4 Automationに修正まで任せる
Automationは、最初は確認と報告だけで大丈夫です。
自動修正、自動公開、自動削除は、慣れてからでも遅くありません。
失敗5 Claude Codeと同じ使い方をする
Claude Codeは、対話しながら深く進める相棒のように使いやすいです。
Codexは、切り出した作業を任せ、差分をレビューする作業エージェントとして考えると使いやすいです。
同じAIコーディング系でも、向いている頼み方が少し違います。
Codexアプリで最初に使う依頼文まとめ

最後に、初心者がすぐ使える依頼文をまとめます。
現状確認
このプロジェクトを確認してください。 まだファイルは変更しないでください。 知りたいこと: - 何のプロジェクトか - 主要ファイル - 変更すると影響が大きそうな場所 - 初心者が最初に頼める小さな作業3つ
小さな修正
以下の小さな修正だけお願いします。 目的: 〇〇を分かりやすくすることです。 変更してよい範囲: 〇〇ファイルのみ やらないでほしいこと: - 大きな設計変更 - 関係ないファイルの変更 - 推測での機能追加 変更後: どこをどう変えたか説明してください。
Review説明
今回の変更内容を初心者向けに説明してください。 知りたいこと: - 変更したファイル - 変更した理由 - 依頼内容との対応 - 動作への影響 - 取り込む前に確認すべきこと
プラグイン相談
この作業にプラグインが必要か相談したいです。 やりたいこと: 〇〇 確認したいこと: - プラグインなしでできるか - 入れるならどんな種類が必要か - 権限面で注意すること - 最初に試す小さな依頼 まだインストールや設定変更はしないでください。
Automation相談
この作業をAutomationにできるか相談したいです。 やりたいこと: 〇〇を定期的に確認したいです。 条件: - 最初は読み取りと報告だけ - ファイル変更はしない - Git操作はしない - 外部公開はしない Automationに向いているか、向いていないかを判断してください。 向いている場合は、初心者向けの設定案を作ってください。
このnoteの次に読むとよい内容

ここまで分かると、Codexアプリの入口では迷いにくくなります。
ただ、実際に使っていくと、次の壁が出てきます。
- どんな作業をCodexに頼めばいいか
- Claude CodeとCodexをどう使い分けるか
- 実装を小さく切るにはどうすればいいか
- Codexに渡す依頼文をどう作るか
- エラーが出た時に何を渡せばいいか
- WorktreeやCloudを実案件でどう使うか
- Automationをどこまで任せるか
有料本編では、この部分をさらに具体化します。
特に、次のような内容を扱います。
- CodexとClaude Codeの対比
- Codexにそのまま貼れる依頼文テンプレ
- 初心者向け7日間ロードマップ
- Worktreeで別案を試す方法
- Reviewで見るべきポイント
- Automationの安全な設計
- Computer Use前チェック
- 失敗した時の戻り方
このnoteは、地図です。
有料本編は、その地図を持って実際に歩くための手順書です。
>Codex完全攻略|OpenAI Codexの使い方とClaude Codeとの違いを初心者向けに解説

最後に
Codexアプリは、最初だけ少し難しく見えます。
理由は、機能が多いからです。
でも、最初に全部を覚える必要はありません。
まずは、
Projectを選ぶ Threadで相談する Composerに小さく頼む Reviewで確認する Worktreeで分ける Pluginsは必要な時だけ Automationは読み取りから Computer Useは狭く安全に
この順番で十分です。
Codexは、全部を任せる道具ではありません。
小さく任せて、差分を見て、自分の判断を残しながら進める道具です。
そこが分かると、Codexはかなり頼れる存在になります。
ただ・・・
まだまだAIで収益化する方法についてお伝えしたいことがたくさんあります。
じゅんの公式LINEでは、
- インスタアフィで稼ぐロードマップ
- 収益化に向けた詳しいノウハウ
- 各種テンプレート
などを中心に、
今回お伝えできなかったインスタ収益化ノウハウも
余すことなくお伝えしています。
お手元のスマートフォンが副収入を生み出すようになったら・・・
最高じゃありませんか…?
まずは僕の公式LINEを追加していただき、
ぜひ期間限定のインスタ収益化ノウハウをお受け取りください!
無料特典なので、早期に配布を終了することがあります。
\無料!登録10秒/
公式LINEに登録するだけで
インスタ初心者でも月6桁目指せる
豪華17大特典配布中🎁
登録解除は、24時間いつでも出来ます