Codexの使い方を実録レビュー｜ChatGPT Plusの枠内でどこまで実装を任せられるか

結論: 月20ドルの枠内で、「実装の手離れ」は買える

先に結論を書く。
Codexは、作るものの形がもう決まっていて、「このファイルのここを、こう書き換えておいて」と渡せる人に効く道具だ。
渡して別の作業をしていると、戻ってきたときには形になっている。
正直に書くと、私がCodexを開く頻度はそこまで高くない。
日々の窓口は別のAI（Claude Code）で、そこから実装の塊を切り出せたときにCodexへ渡す。
それでも、コードを書けない私の手元で、この4か月弱に任せた仕事は本文に並べられるだけの結果を返してきた。

費用の話を先に済ませておく。
私のPCでCodexが使っている認証情報を開くと、認証方式は「chatgpt」で、APIキーの欄は空のままだ。
従量課金は一円も発生していない。
つまり、すでにChatGPT Plusを払っている人にとって、Codexを試すときの追加負担はゼロだった。

そのうえで、任せられない範囲もはっきりしている。
私の環境では、書いたコードを動かして確かめる工程が権限エラーで通らない。
だからCodexは「編集と型チェックまで」、動作確認とコミットは私の側、という線引きになった。
この記事では、導入の手順から、実際に任せた仕事、壊れた出力を受け取った回、そして通りやすい依頼文の型までを、自分の作業記録だけで書いていく。

なお、Codexにはアフィリエイト制度が無い。この記事から私に紹介料の類は一円も入らないので、良いところも悪いところも遠慮なく書ける。

Codexとは何か？

Codexは、OpenAIが提供するコーディングエージェントだ。
私が日常で使っているのは、自分のPCのターミナルで動くCLI版になる。
作業フォルダの中で起動して日本語で頼むと、返事を書いて終わりではなく、ファイルを直接開いて書き換え、型チェックやテストのコマンドまで自分で走らせる。
ブラウザのChatGPTに「こういうコードを書いて」と頼んでコピペする作業との差は、ここに尽きる。
手元のリポジトリが、実際に書き換わる。

入り口は他にもある。ChatGPT側で動かすクラウド版の経路も存在するが、私はほとんど使っていない。この記事は自分のPCで動かすCLI版の話だと思って読んでほしい。

動き方にも癖がある。Codexは、こちらが1回頼むと、そこから何往復も自分で回す。
ファイルを開いて中身を読み、書き換え、コマンドを走らせ、結果を見て、駄目ならまた直す。
人間が1手ずつ承認しながら進めるタイプではない。
だから体感としては「相談相手」ではなく「仕事を受け取って持ち帰る職人」に近い。
この性格は、あとで書く良い点と悪い点の両方の根っこになっている。

私がCodexを使い始めたのは2026年5月ごろで、この記事を書いている8月末までおよそ4か月弱になる。

もうひとつ、私の使い方には少し変わった特徴がある。
Codexを単体のターミナルとして開くより、Claude Codeの会話の途中から仕事を投げる形が多い。
Claude Codeに公式のCodexプラグインを入れると、会話の流れのままCodexへ実装を委譲できる。
窓口を1つに保ったまま、実装だけ別のAIに出す形だ。
この分業をどう固めたかはClaude CodeとCodexの併用実録に詳しく書いたので、比較で迷っている人はそちらを先に読んでもらうほうが早い。
この記事は比較ではなく、Codexという道具そのものの話に絞る。

料金について、私が事実として言えるのはひとつだけだ。
ChatGPT Plusを契約している私のPCで、APIキーを設定しないままCodexが動いている。
執筆時点（2026年8月31日）で私が払っているのはPlusの月20ドルで、Codexのために追加で払っているものはない。
ただし各社の提供内容は変わりやすいので、契約前に公式ページを見てほしい。

Codexの使い方——導入から最初の依頼まで

入れて、ログインする

導入でやることは少ない。ターミナルで次の1行を打ち、Codexを自分のPCに入れる。

npm install -g @openai/codex

続けて codex login を実行すると、ブラウザが開いて認証が走る。
ここでChatGPTのアカウントでログインすれば終わりだ。APIキーの発行も、支払い方法の登録も要らなかった。
うまくいったかどうかは codex login status で確かめられる。
私の画面には「Logged in using ChatGPT」と表示された。
この一行が出れば、Plusの契約で動く状態になっている。

バージョンは動きが速い。
私が最初に入れたのは0.128.0で、この記事を書いている2026年8月31日に手元で確かめたら0.144.1になっていた。
4か月弱で細かい更新が積み上がっている道具なので、記事で読んだ画面と実物が違っても、あまり驚かないほうがいい。

最初の1回は「戻せる仕事」を渡す

導入が済んだら、作業フォルダでCodexを起動して日本語で頼む。
ここで最初に渡す仕事の選び方だけは、少し気をつけたほうがいい。
私のおすすめは、既存ファイルの小さな修正のような、失敗してもgitで元に戻せる範囲の仕事だ。

理由は、Codexがどこまで自分で動くタイプの道具なのかを、先に肌で知っておいたほうがいいからだ。
ファイルを開いて、書き換えて、コマンドを走らせて、結果を見てまた直す——この往復を勝手に回す。
頼み方が曖昧なままいきなり大きな塊を渡すと、後戻りが大きくなる。
逆に、往復の様子を一度見ておけば「この粒度で頼めばいいのか」が体感でつかめる。

頼んだあと、画面では何が起きるか

依頼を投げると、Codexは黙って読み始める。対象のファイルを開き、周辺の書き方を確認し、それから編集に入る。
編集が一区切りつくと、型チェックのようなコマンドを自分で走らせ、エラーが出れば直してもう一度走らせる。
この往復が終わるまで、こちらは基本的に見ているだけになる。

初めて見るとちょっと落ち着かない。
私も最初の数回は「本当に頼んだとおりに直しているのか」が気になって、画面をずっと眺めていた。
いまは投げたら別の作業に移る。戻ってきたときにファイルの差分を見れば、何をしたかは全部そこに書いてあるからだ。

もうひとつ、途中で止めたくなる場面もある。時間がかかりすぎているとき、明らかに違う方向に進んでいるとき。
そのときは中断してかまわないが、あとで書くとおり「止めた＝何も起きていない」ではない点だけ覚えておいてほしい。

設定ファイルでモデルと粘りを決める

Codexの設定は ~/.codex/config.toml というファイルに書く。私が入れているのは実質2行だけだ。
使うモデルの名前（私の設定は gpt-5.6-sol）と、推論にどれだけ粘るかの指定（model_reasoning_effort を high）。
この2つを書いておくと、Claude Codeのプラグイン経由で投げた仕事も同じ設定で動く。

非エンジニアの感覚で言うと、ここは「一度決めたら当分いじらない場所」だ。私も最初に設定して以降、ほとんど触っていない。
設定に凝るより、頼み方を磨くほうが結果に効く——というのが4か月使った実感になる。

Codexに実際に何をさせたか

レビューの中身に入る前に、証拠を並べる。どれも私の作業記録に残っている仕事だ。

いちばん分かりやすいのは、あなたがいま読んでいるこのサイトそのものになる。
「AI道具箱」の初期実装は、Codexが一気に書き上げた。
記事を読み込む仕組み、構造化データの出力、広告枠の出し分け、法務ページ——最初のコミットを私の側で数えたら、68ファイルあった。
ビルドが通るところまでCodexが持っていき、私は画面を開いて目で確かめる係だった。
そのときの様子はCodexでこのサイトを立ち上げた制作記録に残してある。

この回でおもしろかったのは、私が書いたのが仕様書だけだったことだ。
どういうサイトにしたいか、記事にどんな項目を必須にするか、広告はどういう条件で出すか。
それを文章で渡したら、フォルダ構成もファイル名も全部Codex側が決めて出てきた。
私は出来上がった画面を開いて、記事が表示されるか、構造化データが出ているか、広告の設定を入れていない状態でちゃんと広告枠が消えているかを、順番に確かめた。
中の技術はいまも分かっていないが、それでも検収はできる。

もうひとつ、地味だが効いているのが記事の公開作業だ。
別のブログでは、記事ファイルの追加、関連記事リンクの相互張り、記事一覧データの再生成、型チェック、コミットとプッシュまでを一連の作業としてCodexに渡している。
人間がやると手順を飛ばしがちなところを、律儀に最後まで踏んでくれる。

データ構造の変更にも強い。別のサイトで、1件につき1つしか持てなかった分類を、複数持てるように変えたことがある。
型の定義を直せば、絞り込みも、画面のバッジも、テストも連鎖して直さなければならない類の改修だ。
これをCodexに渡したら、既存のテスト298件が通る状態まで一息で持っていった。
ちなみにこの回は1度目の投入がエラーで即死していて、同じ依頼文をそのままもう一度投げたら完走した。

コードだけでもない。別のブログ用に、写真を並べて短い動画を書き出す小さなスクリプトを作らせたこともある。
Pythonのファイル4本を新設する仕事で、これも一晩の作業の中で片づいた。

並べてみて気づくのは、任せている仕事の性質がどれも似ていることだ。
作るものの形が決まっていて、触るファイルが特定できていて、終わったかどうかを機械が判定できる。
この3条件がそろったときが、私がCodexを呼ぶときだ。
逆に、「何を作るべきか」から考える仕事をCodexに渡したことは一度もない。

使ってよかった点は？

渡したあと、こちらの手が空く。 これが最大の価値だと思う。実装をひと塊で渡して、その間に私は別のことをしている。
戻ってきたら形になっている。対話しながら少しずつ詰めていく作りかたと比べると、性格がまるで違う。
要件が固まりきっていない段階では相談相手が要るが、固まったあとの「作業」は、この手離れの良さが素直に効く。

自分で検証まで回してくれる。 型チェック、テスト、生成物の作り直し。
私が細かく指定しなくても、Codexは自分の変更が通るかどうかを確かめてから返してくる。
前述の分類の改修でも、私が受け取った時点でテスト298件が通る状態になっていた。
非エンジニアにとって、この工程を自分でやるのは地味に難しいので、ここを肩代わりしてもらえる意味は大きい。

連鎖する編集に強いのも、渡していて楽なところだ。
1ファイルの修正なら私でも指示を出せるが、「型を変えたので影響が及ぶ場所を全部直す」といった仕事は、人間の側に全体像が見えていないと指示の書きようがない。
Codexは起点さえ渡せば、その連鎖を自分で辿っていく。私の側に必要なのは、どこが起点かを知っていることだけになる。

仕様書を書くと、結果が安定する。 私は大きめの仕事を渡すとき、依頼文をその場で書かず、別ファイルに仕様書として起こしてから渡すことがある。
このサイトの初期実装もそうだった。
手間はかかるが、書いた分だけ受け入れ条件がはっきりして、戻ってきたものを判定する基準もそのまま手に入る。
同じ文面でもう一度投げ直せるという副産物もついてくる。
実際、1度目が落ちた仕事を同じ依頼文で投げ直して完走させたことがある。

最後にもうひとつ。費用が読めるのは、個人でやっている身にはかなり効く。
月20ドルの中で動いている以上、重い仕事を投げたからといって請求が跳ねることはない。
使いすぎたときに困るのは請求ではなく、次に書く枠のほうだ。

つまずいた点は？

良いところだけ並べても信用されないだろうから、記録に残っている失敗を書く。ほとんどはCodexが悪いというより、私の頼み方や検収の甘さが原因だった。

サンドボックスの外には出られない

Codexはコマンドを隔離された環境で実行する。
安全のための仕組みだが、私が使っているNext.jsのプロジェクトでは、開発サーバーの起動が権限エラー（EPERM）で通らない。
2026年7月には、それまで通っていたビルドも同じエラーで落ちるようになった。型チェック単体なら通る。

厄介なのは、Codexが律儀なところだ。
ビルドで検証しようとして失敗し、また試して失敗し、と再試行を重ねて時間を溶かす。
だから私は依頼文に一行足すようになった。「ビルド検証は不要。
編集が終わったら終了してよい」。この一行があると、自分にできる範囲で仕事を畳んで返してくれる。
結果として、ビルドと実機確認とコミットは私の側の仕事になった。制約から生まれた分業だが、いまはこれで安定している。

壊れた出力が返ってくる回がある

2026年5月、自分専用のメモアプリに地図の機能を足そうとしてCodexに投げた回は、はっきり失敗だった。
返ってきたコードは画面の記述が壊れ、同じ読み込みが二重に書かれ、サーバー側では動かないはずの書き方が混ざり、存在しないプロパティを参照していた。
結局7ファイルを人の手で書き直すことになり、委譲した意味がほぼ消えた。

ここから学んだ検収の順番は単純だ。lintだけで安心しない。
型チェックとビルドまで自分で通してから信用する。
lintは型の不一致も、ページを組み立てる段階で落ちる不具合も拾ってくれない。
ちなみにこのアプリ自体は今も毎日使っていて、その顛末は自分専用メモアプリの制作記録に書いた。

日本語が化ける

2026年7月、Codexが書いたページの見出しが文字化けしていた。
「縺」「繧」「繝」——文字コードの事故で出てくる、あの見覚えのある文字だ。
日本語のプロジェクトでCodexを使うなら、成果物を受け取ったあとにこの3文字を検索する一手を、工程に入れておいたほうがいい。
私はそれ以来、毎回通している。

探索を頼むと、そこで止まる

2026年5月、「該当箇所を探し出してから置換して」と頼んだら、読み取りだけで10分以上進まず、こちらから中断した。
以来、探す仕事は渡していない。「この3ファイルの、ここをこう直して」と対象を先に列挙して渡す。
探索はこちらでやるか、別のAIに任せる。
この一点を変えただけで、Codexの実装が返ってくるまでの時間が目に見えて短くなった。

使いすぎると、枠のほうが先に尽きる

追加課金が発生しない代わりに、Plusの契約には使える量の上限がある。
これは「可能性」の話ではなく、私は実際に当たったことがある。重い仕事を続けて投げれば、枠は月の途中でも尽きる。

だから決めているのは、上限に当たったときの動き方だ。
時間を置くか、その仕事を別のAIに振り替えるか、そのどちらかにする。
上限を理由にAPIキーを設定して従量課金へ切り替えることは、いまのところしていない。
月20ドルで収まっているという予測可能性は、私にとって速度より価値があるからだ。

「失敗しました」を鵜呑みにしない

Codexが落ちることはある。
私の場合、「model at capacity」というメッセージで作業が終わる回が何度かあった。
混み合っているときに出るもののようで、こちらの操作ミスではない。

ここに罠がある。2026年8月31日、動画づくりのスクリプトを頼んだ回は、最後のやり取りが失敗表示で終わっていた。
ところが進捗の記録をさかのぼると、ファイルの適用は完了していた。
再投入せずに中身を確かめたら、4本のファイルはきちんと出来上がっていて、そのまま検収に回せた。
同じ日にもう1件、1度目が同じメッセージで即死した仕事があり、そちらは同じ依頼文を投げ直したら完走している。

つまり、失敗表示は「何も起きなかった」の意味ではない。
止まったあとにやることは、画面の表示を眺めることではなく、git statusでリポジトリの実際の差分を見ることだ。
表示より、ファイルの状態を信じる。

もうひとつ、失敗したときの動き方も決めてある。同じ相手に同じ仕事を投げ直すのは1回まで。
それでも通らなければ、自分で引き取るか、別のAIに振り直す。
リトライを繰り返して溶かした時間は、委譲で浮かせた時間をあっさり食いつぶす。

Codexへの依頼文はどう書くか？

4か月でいちばん結果が変わったのは、Codexの設定ではなく依頼文だった。私が使っている型はこうなっている。

• 対象ファイルを最初に列挙する——探させない。パスを並べて渡す
• 背景を1〜2行だけ書く——何のための変更か。これがあると、指示の穴をこちらの意図に沿って埋めてくれる
• 受け入れ条件を測れる形で書く——「型チェックが通る」「既存のテストが全部通る」のように、達成したかどうかを機械が判定できる言葉にする
• 触ってほしくない場所を明示する——別のフォルダ、別の案件、いま自分が編集中のファイル
• できない検証は先に免除する——「ビルド検証は不要」。これがないと、通らない検証で粘って詰まる
• 終わったあとにやることを書く——コミットまで進めるのか、編集で止めるのか

実際に渡している依頼文は、こんな骨格をしている。

対象ファイル
  src/lib/xxx.ts
  src/components/Yyy.tsx

背景
  1件につき1つしか分類を持てない作りになっているが、
  実際には複数当てはまるものがあるため、複数持てる形に変えたい。

受け入れ条件
  型チェックが通る
  既存のテストが全部通る
  絞り込みと画面表示の両方が新しい形に追従している

触らないでほしいこと
  他の案件のフォルダ
  記事本文のファイル

補足
  ビルド検証は不要。編集と型チェックまでで終了してよい。

書いてみると分かるが、AIへの依頼文というより、人に仕事を頼むときのメモに近い。凝った言い回しも、英語も要らない。
私が英語で依頼文を書いたことは一度もなく、仕様も受け入れ条件も禁止事項も全部日本語で渡している。

コツを1つだけ挙げるなら、「探して直して」と言わないことに尽きる。
これを「このファイルのここを直して」に変えるだけで、返ってくるまでの時間も、返ってきたものの質も変わる。
逆に言えば、どのファイルを触るべきかを決める作業は、私の側に残る。
ここを人間が引き受けるからCodexが速く走る、という関係になっている。

では、その「どのファイルを触るか」は誰が調べるのか。私はここをCodexの外でやっている。
相談しながら対象を洗い出す作業は別のAIの担当にして、洗い出しが終わってからCodexを呼ぶ。
コードを書けない私でも依頼文が書けるのは、この下ごしらえの工程が前に挟まっているからだ。
Codexに直接「全部よろしく」と言えるほど、私は自分のプロジェクトの中身を把握していない。

Codexはどんな人に向くか？

向いているのは、作るものの形がもう決まっていて、その作業を手放したい人だ。
すでにChatGPT Plusを払っているなら、試すときの追加費用はゼロだった。
動いているコードがあって、そこに機能を足したい・構造を変えたいという段階なら、渡す仕事としては理想的だと思う。

向いていないのは、「何を作るか」から一緒に考えてほしい人だ。
要件が固まっていない状態でCodexに投げると、こちらの曖昧さがそのまま出力の曖昧さになって返ってくる。
私はこの段取りの部分をClaude Code側で済ませてから、実装だけをCodexに渡す形にしている。

プログラミングの経験については、必須ではないと思う。私は書けないまま4か月使っている。
ただし、代わりに必要になるものはある。
どのファイルを触るかを決められる状態にしておくこと、戻ってきたものを判定する条件を先に言葉にしておくこと。
この2つを用意できないなら、Codexに渡しても評価ができない。

それから、作ったものを画面で確かめる工程が要る人は、そこが自分の仕事として残ることを織り込んでおいたほうがいい。
私の環境では、動かして目で見る作業をCodexに任せられない。
ここを知らずに「全部やってくれる」と期待すると、たぶんいちばんがっかりする。

まとめ: 使い方は「渡し方」と「受け取り方」で決まる

Codexの使い方を突き詰めると、導入手順は数行で終わり、設定ファイルも実質2行だった。
残りは全部、渡し方と受け取り方の話になる。
対象ファイルを列挙して渡すこと、できない検証を先に免除すること、返ってきたものを型チェックとビルドと文字化けの確認まで通してから信用すること。
この3つを決めた時点で、Codexは私の環境で安定して働く実装係になった。

このサイトの初期実装68ファイルも、記事の公開作業も、テスト298件が絡む構造変更も、月20ドルの枠の中で回っている。
壊れた出力を受け取った回も、失敗表示なのに成果物が残っていた回もあったが、それは検収の型を作る材料になった。

Codexが気になっているなら、ChatGPT Plusをすでに契約している人ほど試す価値がある。
追加費用なしで、実装の手離れがどんな感触なのかを自分の手で確かめられるからだ。
私がこの4か月で何を作ってきたかは、制作記録に全部残してある。
Claude Codeとの使い分けで迷っているなら、併用の実録が近道になるはずだ。