Codexとは？できること・使い方・注意点

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

Codexを見かけて、「ChatGPTと何が違うのか」「プログラミングをしない人にも使えるのか」「自分のファイルを勝手に壊さないか」と迷っていませんか。SNSでは、複数の仕事を同時に進めたり、定期作業を自動化したりする例が目立ちます。しかし、最初から高度な機能だけをまねると、どこが変わったのか分からないまま作業範囲だけが広がります。

Codexとは、質問に文章で答えるだけでなく、接続したprojectを調べ、fileを変更し、commandやtestを実行し、結果を報告できる作業型のAI agentです。価値の中心はcode生成の速さではありません。「調査→変更→検証→報告」を一つのtaskとして進め、利用者が差分を確認できることにあります。

この記事はosuke本人の利用体験としては書かず、2026年9月3日時点のOpenAI公式資料とXで公開された利用例を照合しました。X投稿は各投稿者の環境に限られるため、機能、権限、提供条件は公式資料を優先します。読了後には、Codexが自分の仕事に向くかを判断し、安全な最初のtaskを作れる状態を目指します。

記事のポイント

• Codexは回答だけでなくfile変更やtestまで進める
• ChatGPTとの違いは「会話かcodeか」より作業範囲にある
• 安全性はsandbox、承認、作業範囲、reviewで高める
• 最初は30分以内に人が確認できるtaskから始める

Codexとは何か

Codexを単なる「codeを書いてくれるChatGPT」と理解すると、できることも注意点も狭く見積もってしまいます。重要なのは、答えを受け取るだけでなく、作業対象へ接続し、途中の操作と成果を確認できる点です。

ChatGPTとの違いは回答より作業にある

一般的なChatGPTの会話では、質問、要約、文章案、比較、アイデアを画面上で受け取る使い方が中心です。Codexはprojectのfolderやrepositoryを作業場所として扱い、fileを読み、必要な箇所を探し、変更案を実際のfileへ反映し、commandを実行できます。答えをコピーして別のeditorへ貼る工程を減らせます。

たとえば「問い合わせformの送信後に二重送信を防ぎたい」と依頼した場合、会話型AIなら一般的な実装例を返します。Codexなら既存codeからform、API、testを探し、現在の設計に合わせて必要最小限の変更を作り、test結果と変更fileをまとめて報告できます。ただし、依頼者が意図した仕様かどうかの最終判断は人に残ります。

OpenAIのCodexドキュメントでは、desktop app、CLI、IDE extension、cloudに加え、project、review、scheduled task、long-running work、browser、Skills、Plugins、MCPなどが別の機能領域として整理されています。つまりCodexは一つのcode生成画面ではなく、仕事を進める複数の入口と制御を持つ環境です。

Codexが進められる4つの工程

Codexのtaskは大きく、調査、変更、実行、検証の4工程に分けられます。調査ではrepository全体から関係fileや設定を探し、既存の書き方と制約を把握します。変更では目的に必要なfileだけを編集します。実行ではbuild、lint、test、previewなどを動かし、検証では差分と失敗を読んで完成条件を確認します。

4工程を一度に任せられることは便利ですが、すべての依頼で変更まで許可する必要はありません。「原因だけ調べて、変更はしない」「候補を3つ示して止まる」「testだけ実行し、失敗fileを報告する」と範囲を分けられます。診断と修正を別taskにすると、初心者でも意図しない変更を減らせます。

XではMichael Schade氏が、目的とcontextを置いたうえでSkills、automation、worktreeなどを使い分ける流れを紹介しています。これは個人の利用例ですが、機能を先に選ぶのではなく、taskの目的と必要な工程を先に決めるという考え方は再利用できます。

4工程は必ず連続させるものでもありません。初日は調査だけ、翌日に変更、最後に別chatでreviewという分け方もできます。原因が複数考えられる障害では、調査結果と仮説を表にして止め、修正対象が決まってから書き込みを許可します。工程を分けるほど時間は増えますが、誤った仮説のまま広範囲を変更するriskを下げられます。

コード以外の仕事にも使える

Codexは開発者向け機能が強い一方、対象が必ずprogram codeとは限りません。folder内のMarkdownを整理する、複数のCSVを照合する、記事一覧を監査する、画像やPDFから情報をまとめる、定期reportを作るなど、fileと明確な完成条件がある仕事にも使えます。実際に重要なのは職種より、作業を確認可能な手順へ分けられるかです。

一方、価値判断そのものを丸ごと任せる仕事は向きません。採用の合否、医療や法律の最終判断、送金、公開前の対外発信、復元できない削除は、人の確認点を途中に置く必要があります。Codexがtoolを操作できることと、その判断を任せてよいことは別です。

非engineerが使う場合も、「良いcodeを書いて」ではなく「このfolderの公開記事一覧を読み、重複themeを表にし、fileは変更しない」のように依頼できます。入力、処理、出力、禁止事項が明確なら、専門用語を多く知らなくても確認しやすくなります。

Codexに向くのは、対象が見え、終わりを確認でき、途中の操作を記録できる仕事です。曖昧な大目標も扱えますが、最初は一つのtaskを小さく完了させ、どこまで正確に進められるかを確かめます。

小さなtaskでは、誤字修正、設定値の確認、test追加、error原因の調査、README更新が向きます。変更fileが1〜3個、確認commandが1〜2個なら、人が差分を追いやすく、Codexの進め方も評価しやすくなります。初回からrepository全体の再設計を任せるより、成功と失敗の境界が見えます。

大きなtaskでは、古いframeworkの移行、複数moduleのrefactor、大量文書の整備、security scan、調査reportの作成などが候補です。ただし大きさに比例して、計画、途中報告、checkpoint、test、reviewが重要になります。長時間動いたことは、正しい方向へ進んだ証拠ではありません。

OpenAIの長時間作業ガイドが独立していることからも、長いtaskは単なる長いpromptではなく、目標、状態、再開、通知を管理する別のworkflowと考えるべきです。最初のtaskで確認した型を、大きな仕事へ段階的に広げます。

ローカル・worktree・cloudを使い分ける

Localは現在の作業folderへ直接つながるため、既存のdependencyや未commit変更を使いやすい一方、利用者の作業と同じ場所を編集します。小さな確認や、その場で一緒に進めるtaskに向きます。変更前に現在の差分を確認し、他の作業と混ざらないようにします。

Codexのworktreeは、同じGit repositoryから別の作業copyを作り、chatごとの変更を分離します。2件以上を並行する場合や、現在のLocalを触らせたくない場合に有効です。Xでも陈成氏がworktreeによる複数作業の分離を紹介していますが、並列化後には変更の依存関係と統合reviewが残ります。

Cloudは手元のcomputerを占有せずにtaskを進める選択肢ですが、repository、Secret、network、実行環境がLocalと同じとは限りません。Localでしか存在しないfileやcredentialに依存するtaskは、環境差を先に確認します。環境の選択は性能比較ではなく、「どのdataへ、どの権限で、どこから接続するか」で決めます。

レビューとテストで確認可能にする

AIが「完了しました」と報告しても、完成条件を満たしたとは限りません。変更したfile、差分の要点、実行したtest、失敗したtest、未確認の項目を分けて報告させます。結果だけでなく、どう確認したかが残れば、人は重要な箇所へreview時間を集中できます。

Codexのcode reviewは、未commit変更や基準branchとの差分を読み、作業treeを変えずに優先度付きの指摘を出せます。実装した同じchatに自己確認させるだけでなく、別reviewとして差分を読む工程を設けると、思い込みを減らせます。ただしreview結果にも誤検知と見逃しはあります。

OpenAI公式Communityでは、Codexのreviewで重要な問題を見つけたという利用者コメントも紹介されています。これは有望な使い方の発見にはなりますが、単独の成功談から検出率を一般化できません。自動test、型check、lint、実機確認、人のreviewを重ね、どれか一つを万能な保証にしないことが重要です。

確認結果は成功・失敗の二択にしないことも大切です。たとえばunit testは通ったがbrowser確認は未実施、buildは成功したが外部APIのtest credentialがなく通信は未確認、と検証範囲を分けます。未確認を明記すれば、次の担当者は同じ調査を繰り返さず、残ったriskへ直接進めます。

Codexを安全に使う条件

Codexはcomputer上で操作できるため、回答の正しさだけでなく、アクセス範囲と操作の可逆性を考えます。安全性は「AIを信じるか」という気持ちではなく、技術的な境界、承認、backup、reviewで作ります。

サンドボックスと承認を理解する

OpenAIのsandbox説明では、Local commandは既定で制限された環境内で動き、読めるfile、書ける場所、network accessなどに境界が設けられます。Sandboxは「何へアクセスできるか」を決め、承認は「境界を越える前にいつ止まるか」を決めます。この二つは似ていますが役割が違います。

最初からfull accessを与えると確認回数は減りますが、誤ったcommandが広い範囲へ影響します。通常はproject内の読み書きから始め、package取得や外部serviceへの接続など、必要な操作だけ一時的に承認します。承認画面ではcommand名だけでなく、対象path、送信先、変更内容を見ます。

特に注意したいのは、削除、database更新、本番deploy、公開投稿、送金、account設定変更です。これらは作業が技術的に可能でも、最終実行前に人が対象と件数を確認します。復元できる下書き、preview、別branch、test dataを先に使い、本番操作を最後の一段に分けます。

承認が多すぎて作業が進まない時も、いきなり全権限へ変えないでください。何度も止まる安全なread commandや特定domainだけを規則として許可し、対象を限定します。承認回数を減らす目的と、project外への書き込みや任意network接続を許すことは同じではありません。

AGENTS.mdで守るルールを固定する

毎回同じ注意を書いているなら、projectのAGENTS.mdへ固定できます。OpenAI公式によると、Codexはtask開始前にAGENTS.mdを読み、global、repository、作業directoryに近いfileを階層的に組み合わせます。下位の具体的な指示ほど、近い範囲へ適用できます。

良いAGENTS.mdには、重要なdirectory、build・test command、code規約、触ってはいけないfile、完成条件を短く書きます。「高品質にする」のような抽象語より、「JavaScript変更後はこのtestを実行」「schema変更は行わず提案で止める」と確認可能な規則にします。長すぎるfileは重要な規則を埋もれさせます。

XではKAWAI氏がCodexとClaude CodeでSkillsを再利用する例を紹介しています。繰り返す手順はAGENTS.mdで方針を固定し、複数段階の作業はSkillへまとめると、長いpromptの貼り直しを減らせます。Claude Codeの基本とMCPについては、既存のClaudeCodeの使い方ガイドも比較材料になります。

最初のAGENTS.mdは10〜20行程度で十分です。規則を増やすのは、同じ誤りが繰り返された時や、reviewで毎回同じ指摘が出た時にします。toolで強制できる規則はlintやtestへ移し、文章でしか伝えられないproject固有の判断だけを残すと、指示と自動検査の役割が分かれます。

任せない仕事と人が確認する境界を決める

Codexに向かないのは、正解が一つでなく、間違いの損失が大きく、実行後に戻せない仕事です。人事評価、契約の最終判断、医療判断、財務承認、公開accountからの発言などは、資料整理や候補作成までに留めます。判断補助と意思決定を分離してください。

開発でも、migrationや認証の変更を禁止する必要はありません。ただし「backup作成→dry run→test環境→件数照合→本番承認」のように、人が止められる境界を作ります。AI agentの価値は人を消すことではなく、確認点までの調査と作業を速くすることです。

入力dataにも境界が必要です。password、API key、顧客情報、未公開の契約、医療情報をpromptへ直接貼らず、必要なら匿名化、test data、限定権限のcredentialを使います。外部tool、MCP、browserを追加するとaccess先が増えるため、接続ごとに読み取り・書き込み・外部送信を確認します。

法律、契約、医療、税務の資料を整理させる場合は、出典、適用地域、基準日、不明点を残し、最終判断を各分野の有資格者や担当部署へ確認します。Codexには論点抽出と質問案の作成までを任せ、「専門家へ何を確認すべきか」を明確にすると、安全性と作業短縮を両立できます。

最初の目標は、Codexの全機能を使うことではありません。小さなtaskを一つ完了し、依頼、作業、確認の流れを理解することです。成功後に作業範囲を少しずつ広げます。

最初のタスクは30分で確認できる大きさにする

最初は、説明文の誤字を直す、使われていないlinkを一覧化する、一つのerror原因を調べる、既存testを実行して失敗を要約するなど、変更と確認が小さいtaskを選びます。人が30分以内に全差分を読める量なら、Codexの判断がずれても戻しやすくなります。

変更が怖い場合は読み取りだけから始めます。「このfolderの構成を説明し、起動方法とtest方法を特定してください。fileは変更しないでください」と依頼すれば、project理解の精度を確認できます。次にtest追加、その次に小修正と、権限と難度を一段ずつ上げます。

OpenAIのProjects and chatsでは、接続したfolderを作業場所にし、主folderをGit操作やAGENTS.md探索の起点として扱います。無関係な複数repositoryを一つのprojectへ詰め込まず、taskに必要なfolderだけを接続するとcontextと権限を絞れます。

作業前後の比較も簡単にします。Git repositoryなら開始前の状態を確認し、変更後は差分を表示します。Gitを使わない文書folderなら対象fileをcopyしてから始め、出力先を別folderへ分けます。元に戻す手段が用意できないtaskは、初回の練習には選びません。

終了後は、依頼にかかった時間よりreviewにかかった時間を記録します。作業が10分でも確認に2時間かかるなら、次回は対象fileをさらに減らします。反対に30分以内で確認できたら、似たtaskをもう一件だけ追加します。

良い依頼は対象・完成条件・禁止・検証を書く

「このsiteを良くして」だけでは、調査範囲も完成も決まりません。依頼には、対象、目的、完成条件、禁止事項、検証方法を入れます。たとえば「記事一覧pageの表示を速くする。対象は一覧取得処理だけ。DB schemaは変えない。既存testを通し、変更fileと速度差を報告する」と書きます。

分からないことを推測で埋めてほしくない場合は、「不明点が結果を変える場合は変更前に質問する」と加えます。逆に細かな選択を任せたい場合は、「既存の設計と命名に合わせ、追加dependencyなしで最小変更を選ぶ」と判断基準を渡します。手段を一行ずつ指定するより、守る条件を明確にした方が既存projectへ合わせやすくなります。

終了時には、変更file、test、未確認事項を報告させます。「動きました」だけではなく、どのcommandで何を確認したかを残します。UI変更ならdesktopとmobile、data処理なら入力件数と出力件数、link監査なら対象URL数とerror数のように、完成条件を数字へ変えるとreviewできます。

依頼文は最初から完璧でなくて構いません。Codexが想定外のfileまで読んだ、説明だけで変更しなかった、testが重すぎたなど、実際のずれを次の条件へ反映します。良いpromptは一度で思いつく呪文ではなく、失敗をproject規則と検証項目へ変える改善記録です。

高度機能は失敗が見えてから追加する

Skills、Plugins、MCP、subagent、automation、scheduled task、browser操作は、繰り返し作業を大きく減らせます。しかし最初から全部を接続すると、誤りの原因がprompt、Skill、外部tool、権限、環境のどこにあるか分かりません。まず一つのchatと一つのprojectで手順を完成させます。

XではAakash Gupta氏がautomation、worktree、cloudを組み合わせた活用を紹介しています。このようなworkflowは到達点の参考になりますが、初回の出発点ではありません。同じ手順を2〜3回繰り返し、人の確認箇所が安定した時にSkillやautomationへ昇格させます。

自動化後も、変更される外部仕様、料金、account権限、公開先の状態は変わります。定期taskには「変化がない時は何もしない」「公開や削除は行わない」「失敗時だけ通知する」などの停止条件を入れます。自動化は確認をなくす機能ではなく、確認すべき変化を絞る機能として使います。

Codexとは、codeを自動生成するだけのAIではなく、接続した仕事の中で調査、変更、実行、検証を進めるAI agentです。向いているのは、対象と完成条件が見え、差分や結果を人が確認できる仕事です。向かないのは、戻せない操作や、法務・医療・人事・財務の最終判断を無確認で任せる使い方です。

今日の1stepは、小さなprojectを一つ選び、「構成を調べ、起動方法とtest方法を説明してください。fileは変更しないでください」と依頼することです。結果が正しければ、次に1〜3fileの小変更とtestへ進みます。Codexを完全自動化としてではなく、確認可能な委任として始めると、便利さと安全性を両立できます。