Codexの始め方｜失敗を防ぐ初回タスク6手順

こんにちは。Osukeラーニング、運営者の「osuke」です。

Codexを使い始めたいものの、「アプリ・CLI・IDEのどれを選ぶのか」「最初に何を頼めばよいのか」「自分のファイルを壊さないか」で止まっていませんか。SNSでは大規模な開発や自動化が目立ちますが、初回から同じことをする必要はありません。入口を一つ選び、戻せる小さなタスクを一つ完了する方が、使い方と注意点を同時に理解できます。

Codexの始め方で大切なのは、インストールの速さより「作業前の状態が分かる」「変更範囲を絞る」「結果を人が確認する」の3条件です。この記事では、読み取りだけの調査から1〜3ファイルの小変更、テスト、差分確認、必要なときの戻し方までを一つの流れにします。

内容は2026年9月7日時点のOpenAI公式資料と、複数のX公開投稿を照合して作成しました。Xは利用者の成功例やつまずきを知る材料にし、対応環境、権限、機能などの製品仕様は公式資料を優先します。osuke本人の利用体験としては記述していません。

記事のポイント

• 入口は性能差より、普段作業する場所で選ぶ
• 最初は読み取りだけ、次に1〜3ファイルの小変更へ進む
• 指示は目的・対象・境界・完了の4点で書く
• テスト通過だけで終えず、差分と未確認事項まで見る

Codexの始め方と準備

準備では、すべての設定を覚える必要はありません。ゴール、入口、作業フォルダ、開始前の状態、最初のタスク、依頼文の6つを順番に決めれば、初回の失敗原因を切り分けやすくなります。機能を増やすより先に、確認できる一本道を作ります。

最初にゴールを1つ決める

初回のゴールは、Codexの全機能を使うことではなく、確認できるタスクを1つ完了することです。「このフォルダの構成とテスト方法を説明する」「READMEの古いリンクを1か所直す」など、終わったかを自分で判断できるものを選びます。作業時間ではなく、結果を確認できたかを成功基準にしてください。

最初から「このサービスを良くして」と頼むと、調査範囲、完成条件、変更量が決まりません。100行の変更ができても、目的に合うか分からなければ完了とは呼べません。最初は目的を1つ、差分を読む時間を30分以内にすると、ずれた場合にも「対象」「指示」「検証」のどこが原因かを振り返れます。

変更が不安なら、1回目は読み取りだけにします。構成、起動方法、関係ファイル、テスト方法を説明させ、ファイルは変更させません。説明が実際のプロジェクトと合っていれば、2回目に1ファイルの小変更へ進みます。「何も変更しない仕事」も、Codexが作業場所を正しく理解したかを測る立派な初回タスクです。

OpenAIのCodex quickstartも、入口を選び、作業場所を指定し、最初のメッセージを送る順番で案内しています。ただしフォルダを選ぶと、その中のファイルが読み書きの対象になり得ます。インストール後に考えるのではなく、どのフォルダで何を一つ終えるかを先に決める方が安全です。

小さいタスクではCodexの力を活かせない、と思うかもしれません。しかし、小さくするのは永続的な制限ではなく、委任と確認の型を作るためです。Codexの全体像や向く仕事を知りたい場合は、先にCodexとは何かをまとめたピラー記事を確認し、本記事で最初の1件を完了してください。

アプリ・CLI・IDEを選ぶ

Codexの入口は、最も高性能なものを探すより、普段の作業場所に合わせて選びます。初めてでフォルダと会話を画面上で確認したい人はdesktop app、terminal中心の人はCLI、editorを開いたまま差分を見たい人はIDEが候補です。入口が違っても、対象を伝え、作業を依頼し、結果を確認する基本は共通します。

OpenAIのdesktop appガイドでは、install、sign in、chat・project・folderなど作業場所の選択、最初のmessageという導入順が示されています。macOS、Windows、Linux向けの案内があり、複数projectやlocal fileを画面から扱いたい人の標準的な入口です。迷った初心者は、まずappで一つのfolderを開くと流れを把握しやすくなります。

Codex CLIの公式ガイドでは、project directoryでcodexを起動し、terminal内で調査、編集、command実行を進めます。現在のdirectoryを日常的に確認でき、buildやtestをterminalで使っている人に向きます。反対に、directoryやGit状態にまだ慣れていない場合は、対象を画面で見やすいappから始める方が迷いを減らせます。

Codex IDE extensionの公式ガイドでは、開いているファイルや選択範囲をcontextにし、editor内で変更を確認できる流れが案内されています。すでにVS Code系のeditorで対象コードを見ている人には自然です。ただし、選択中の数行だけで問題全体が決まるとは限らないため、関係fileを調べる範囲は別に伝えます。

同じタスクを3つの入口で試す必要はありません。初回は一つを選び、依頼、承認、差分、テストの流れを覚えます。入口を変えるのは、普段の開発環境へ寄せたい、長い作業を別環境へ分けたいなど、困りごとが見えてからで十分です。「どれが一番強いか」ではなく、「今どこで対象を確認できるか」で選びましょう。

正しい作業フォルダを開く

Codexは、選んだ作業場所を手掛かりにファイルを探します。別のrepositoryや一つ上の大きなfolderを開くと、無関係なファイルまで候補になり、説明も変更範囲も広がります。タスクに必要な最小のfolderを一つ選びます。似た名前のbackup、古いcopy、別顧客のprojectを取り違えないことが最初の防波堤です。

開始前に、folder名、目的のfile、起動command、test command、変更禁止範囲の5点を確認します。CLIなら現在directoryを表示し、desktop appなら画面に表示されたprojectまたはfolder名を見ます。開いた直後にCodexへも現在位置と主要fileを列挙させ、人の認識と一致するか比べると二重に確認できます。

OpenAIのCodex best practicesでは、wrong working directory、access不足、必要toolの不足など、setupが失敗原因になる点を挙げています。promptを何度書き直しても、対象folderが違えば改善しません。動かないときはmodelの能力を疑う前に、現在位置、dependency、利用できるcommandを確認します。

API keyやpasswordを使うprojectでも、値をpromptへ貼り付けません。秘密情報は既存の安全な保管方法に置き、Codexには「秘密情報を表示せず、必要な設定が存在するかだけ確認する」と伝えます。顧客情報、個人情報、未公開の社内資料を含むfolderも、匿名化や権限設計が済むまでは初回の練習対象から外します。

「大きな親folderを開けばcontextが増えて賢くなる」とは限りません。無関係な情報が増えるほど、読む時間、権限範囲、変更候補も増えます。必要なrepositoryだけを開き、別repositoryが必要だと分かった時点で追加する方が、なぜそのアクセスが必要かを判断できます。

最初の依頼には、「作業前に現在のfolderと関係fileを報告し、想定と違えば変更せず止まる」と加えます。この1文は、wrong folderだけでなく、対象componentの取り違えにも効きます。編集を始めてから気づくより、最初の30秒で止める方が安全です。

Gitで開始前の状態を残す

変更前の状態が分からなければ、終了後の差分がCodexによるものか、以前から残っていたものかを判定できません。Git repositoryでは、現在のbranch、未commit file、既存差分を確認し、必要なら人が意味の分かるcheckpointを作ります。Codexを起動する前の記録が、終了後の比較基準です。

たとえば既存の未commit変更が3ファイルある状態でCodexが2ファイルを変えると、review画面には5ファイルが並ぶ場合があります。「Codexが触ったのは2ファイル」と報告されても、一覧全体を見ないと元からの変更を誤ってcommitしたり、戻したりする可能性があります。開始前と終了後のfile一覧を比較してください。

Codex CLIの公式ガイドでも、作業前後にGit checkpointを置き、変更を戻せる状態にする考え方が示されています。checkpointは失敗時の保険だけではありません。「どの時点から、何が、なぜ変わったか」を説明する境目です。タスクを追加する前に一度区切ると、増分差分を追いやすくなります。

Gitを使っていない文書folderなら、元fileのcopyを取り、出力先を別folderに分けます。画像10枚の名前変更なら、最初はcopyした2枚だけで試します。大切なのはGitという道具そのものではなく、開始前と終了後を比較でき、必要な変更だけを戻せることです。

初回の練習では、他の人が同時に変更しているbranchや、本番公開へ直結するfolderを避けます。どうしても未commit作業があるなら、Codexに「既存差分は変更せず、開始前に一覧を報告する」と明示します。広い一括操作で戻すのではなく、自分の作業と今回の変更を区別できる準備が必要です。

初回タスクを小さく決める

初回に向くのは、正解と確認方法が見えるタスクです。READMEのリンク修正、失敗しているテスト1件の原因調査、既存componentの文言変更、設定項目の説明などが候補です。最初は目的1つ、変更1〜3ファイル、確認command 1〜2個、人のreview 30分以内を目安にします。

反対に、認証方式の変更、決済、本番database migration、repository全体のrefactor、本番deployは初回に向きません。間違えた時の影響が大きく、正しさを確認するために広い知識と複数環境が必要だからです。技術的に実行可能でも、初回に安全に評価できるとは限りません。

XではRishabh Srivastava氏が、Codexを範囲が明確で細部の多いtaskに使うという個人の使い分けを紹介しています。これは全員に当てはまる性能比較ではありませんが、初回をscopeの明確な仕事にする判断材料にはなります。公開例は「何を任せるか」の発見に使い、再現性は自分のprojectで確かめます。

小さくすることは、Codexの判断力を封じることでもありません。手段は既存設計に合わせて選ばせつつ、変えてよい範囲と完成条件を人が決めます。「追加dependencyなし」「database schemaは変えない」のように境界を示せば、その内側では調査と提案の余地を残せます。

同じ型で2〜3回成功した後なら、複数fileや長いtaskへ広げても、途中で止める基準が分かります。反対に、最初の1件で確認に2時間かかったなら、次回はfile数や目的を半分にします。作業が速かったかではなく、人が結果を検証できたかでtaskの大きさを調整してください。

指示を4点で書く

初回の指示は、特別な呪文ではなく、目的、対象、境界、完了の4点で書けます。目的は何を解決するか、対象はどのfolder・fileか、境界は何を変えないか、完了は何を確認すれば終わりかです。長さよりも、結果を見た人が「終わった」「まだ」と判定できることが重要です。

OpenAIのpromptingガイドでも、固定された特殊な構文を必須とせず、重要なtaskではGoal、Context、Output、Boundariesを明確にする考え方が示されています。日本語では「目的・対象・境界・完了」と覚えると、初めてでも依頼へ変換しやすくなります。

最初の読み取り依頼は、次のように書けます。この段階では、説明の正しさを確かめることが成果です。Codexが不明点を推測して編集へ進まないように、「変更しない」「想定と違えば止まる」を明記します。

目的：このprojectの構成を理解する。
対象：現在開いているfolder。
境界：fileを変更しない。秘密情報を表示しない。想定と違えば止まる。
完了：関係file、起動方法、test command、不明点を報告する。

説明が合っていたら、2回目は「READMEの古いlinkを1件直す。README以外を変えず、dependencyを追加せず、commit・pushしない。変更前後のURL、変更file、確認結果を報告する」のようにします。変更の手順を1行ずつ縛らなくても、目的と境界の内側で既存の書き方に合わせて判断させられます。

「詳しく書きすぎるとAIの意味がない」という反論もあります。しかし、人が指定するのは実装方法のすべてではなく、守るべき結果とriskです。不明点が結果を変える場合だけ質問する、変更前に候補fileを示す、終了時に未確認事項を報告する、と加えると、止まりすぎと勝手な推測の両方を減らせます。

Codexの始め方と安全確認

準備ができたら、作業前のplan、必要最小限の権限、テストと差分、戻し方を確認します。「Codexが完了と言った」ことと「依頼者が完成を確認した」ことを分けるのが、安全な始め方の中心です。

Planモードで作業前に確認する

影響範囲が読めないタスクでは、すぐ編集させず、先にplanだけを作らせます。関係file、変更方針、想定risk、検証方法、確認が必要な質問の5点を出させ、方向が合ってから実装へ進みます。planはきれいな文章を作るためではなく、誤った前提を変更前に見つけるための停止地点です。

たとえば「login後に元のpageへ戻れない」という問題でも、原因はfrontend、session、redirect設定、test環境に分かれます。最初に候補と調査順を示させれば、認証全体を不用意に変える前に範囲を絞れます。「調査してplanを出し、まだfileは変更しない」と書けば、原因調査と実装を二つの段階にできます。

OpenAIのbest practicesも、難しいtaskや曖昧なtaskでは先にplanを作る考え方を案内しています。planを読んだ時点で、対象fileが違う、不要なdependency追加がある、本番dataを触る想定になっているなら止めます。編集後に数百行を戻すより、作業前の5項目を直す方が小さなコストで方向を変えられます。

XでもSintone氏がPlan modeを使う個人workflowを紹介しています。これは現行UIや品質を保証する資料ではありませんが、すぐcodeを書かせる以外の進め方が実務で使われている例です。Xの画面や名称が変わっている場合は公式資料を優先してください。

一方、誤字1件の修正に長いplanを必須にすると、確認コストが作業を上回ります。変更が1ファイルで、結果がすぐ見え、戻し方が明確なら、「対象と変更案を1文で報告してから進む」程度で構いません。planの長さは、file数ではなく、誤った場合の影響と不確実性に合わせます。

権限と承認を最小限にする

初回は既定または厳しい権限から始め、必要な操作だけ許可します。読み取りだけの調査なら書き込みは不要です。project内の小変更でも、外部network、本番service、project外のfolderへ自動で広い権限を与える理由はありません。権限は「Codexを信じるか」ではなく、今回どこまで影響してよいかで決めます。

OpenAIのpermissionsガイドでは、filesystemとnetworkを最小権限で扱う考え方と、read-only、workspace、danger-full-accessなどのprofileが案内されています。permission profileはbetaとして更新中のため、名称や画面は利用時の公式表示を確認してください。初心者は既定または厳しい設定から始めるのが基本です。

承認画面では、command、対象path、networkの送信先、外部状態の変更という4点を見ます。package取得のような普通の操作でも、どのprojectで何を追加するかを確認します。公開、message送信、削除、database更新、deployは、技術的に実行できることと任せてよいことを分け、最終実行を別の承認点にします。

承認が多いからといって、すぐfull accessにする必要はありません。何度も現れる安全なcommandや限定したdomainだけを規則として許可できる場合があります。「毎回止まらないこと」と「どこへでも書き込み・送信できること」は同じではありません。反復する範囲が判明してから、許可を狭く再利用します。

sandboxも万能な保証ではありません。許可されたworkspace内なら、意図と違うfileを変更する可能性は残ります。反対に、承認が出たこと自体が危険の証拠でもなく、境界を越える理由を人が確認する機会です。taskの境界、checkpoint、権限、test、diff reviewの5層を重ねて安全性を高めます。

初回は「project内の読み取りと、指定した1ファイルの変更」「外部networkなし」「commit・push・公開なし」と区切ると判断しやすくなります。作業に本当に必要な操作が止まった場合だけ、表示された対象を確認して一段緩めてください。最初から将来の全作業を想定した権限を与える必要はありません。

変更差分とテストを確認する

「テストが通りました」という報告だけでは、何を検証したか分かりません。意図した動作、testの中身、file差分、想定外のfile、未確認事項の5点を見ます。testが対象の条件をassertしていなければ、greenでも完成の証拠になりません。成功・失敗だけでなく、検証範囲を言葉にさせます。

XではKaxil Naik氏が、agentに開発環境やE2Eまで進めさせる個人workflowを紹介する一方、誤った修正が静かに入り、testが通っても実質的に何も検証していない場合があるというreview上の摩擦を挙げています。個人例ですが、「passed」の一語を品質保証にしない理由を具体的に示します。

差分では、変更行だけでなく、削除された条件、error処理、設定値、dependency、秘密情報の混入を確認します。1〜3fileに絞った初回taskなら、すべての差分を読み切れます。目的と関係のない整形、rename、生成fileが入っていれば、必要性を聞くか、対象だけ戻します。

OpenAIのcode reviewガイドでは、appのreview paneで変更を確認し、/reviewで選んだ差分を作業treeへ変更を加えずに検査する流れが案内されています。review paneにはCodexの変更だけでなくrepository全体の未commit状態が見えるため、開始前にあった自分の差分も含まれる前提で読みます。

増分差分を追う重要性は、Johnny Dallas氏が2025年の個人利用で挙げた「新しい依頼による変更分を追いにくい」という摩擦からも分かります。現在のUI仕様を示す投稿ではありませんが、taskを3件連続で追加してからreviewするより、1件ごとにdiffとtest結果を確定する方が目的との対応を追いやすくなります。

自動reviewにも見逃しと誤検知があります。UI変更なら実際の画面、data処理なら入力件数と出力件数、error修正なら失敗を再現するtestというように、対象に合う確認を1つ加えます。最後に「何を確認できずに残したか」を報告させれば、次の担当者は未確認riskから再開できます。

失敗したときに安全に戻す

結果が違うと分かったら、追加promptで何度も上書きする前に止めます。現在の差分、失敗したcheck、想定と違う点を保存し、戻す対象を決めます。原因を記録せずに修正を重ねると、最初の問題と修正による問題が混ざり、どこまで戻せばよいか分からなくなります。

appのreview画面やGit checkpointがあれば、不要な変更をfile単位・差分単位で戻せます。repository全体を一括で戻す強いcommandは、自分が以前から作業していた未commit変更まで消す可能性があります。初回ほど「全部消す」ではなく、今回のtaskに対応する差分だけを選択します。

開始前に未commit fileが3件、今回の変更が2件あったなら、戻す前に5件をもう一度照合します。名前が同じfileを自分とCodexの両方が編集した場合は、file単位ではなく差分単位で判断が必要です。判断できなければ自動で戻さず、人が内容を確認してから操作します。

戻した後は、失敗を「Codexは使えない」で終えず、依頼のどの条件が足りなかったかを一つ記録します。対象fileが広すぎた、完成条件がなかった、testが不十分だった、作業folderが違った、既存差分を伝えなかった、のように次の依頼で変えられる原因へ分解します。一度に10個の規則を増やす必要はありません。

削除、本番data更新、外部公開のように戻しにくい操作は、初回taskから外すのが最も安全です。必要になった時はpreview、dry run、test環境、対象件数の照合、人の最終承認を別の段階にします。戻し方を準備できない操作は、「実行せず手順と影響だけ報告する」taskへ変えてください。

失敗記録には、期待した結果、実際の結果、変更file、実行したcheck、戻した範囲の5点を残します。同じ失敗が2回起きたら、次回だけのpromptではなく、projectの継続的な指示や自動testへ移す候補です。失敗を再発防止の材料に変えると、任せられる範囲を少しずつ広げられます。

最初の完了から次へ進む

初回taskは、変更が作られた時点ではなく、目的を満たし、必要なcheckが通り、全差分を読み、未確認事項が分かった時点で完了です。commit、push、deploy、外部公開は別の操作として扱い、依頼していなければ実行させません。「完成」と「外部へ反映」を分けると、最後の判断を人に残せます。

最初の型が成功したら、同じ種類のtaskを2〜3回繰り返します。毎回同じ注意を書くならprojectの指示へ固定し、並行作業が必要なら作業環境を分け、反復手順が安定してから自動化を検討します。いきなり高度機能を足すより、どの工程を再利用するかが見えてから追加する方が原因を追えます。

XではMichael Schade氏が、狭く指定したtaskだけでなく、より高いlevelの目的とcontextを渡す価値を論じています。これは個人の見解ですが、小taskを最終形にしない考え方の参考になります。最初の確認型を作った後なら、「なぜこの変更が必要か」という上位目的も安全に加えられます。

ただし、範囲を広げるたびに確認も一段増やします。1fileから5fileへ広げるなら途中checkを置く、30分から数時間へ延ばすならcheckpointを追加する、外部serviceへ接続するなら送信先と書き込み範囲を確認する、という対応です。能力への期待だけを増やし、境界を同じままにしないでください。

Codexの始め方を最短でまとめると、入口を1つ選ぶ、正しいfolderを開く、開始前を記録する、読み取りだけで確認する、1〜3fileを小さく変える、testとdiffを読む、の6段階です。安全性はCodexを無条件に信じることではなく、範囲、戻し方、承認点、完成条件を人が設計することで高められます。

今日の1stepは、「現在のfolderの構成、関係file、起動方法、test方法を説明してください。fileは変更せず、秘密情報は表示せず、不明点を報告してください」と送ることです。説明が正しければ、次にREADMEなど1fileの小変更へ進みましょう。最初の1件を最後まで確認できれば、Codexは怖い自動化ではなく、範囲を決めて任せられる作業相手になります。