我々はCodexとどう向き合うべきなのか
この記事は、すでにCodexやClaudeCodeなどのAIコーディングツールを実際に使い始めているエンジニアに向けて書いている。「期待ほど効率が上がらない」と感じている人や、運用の型を模索している個人開発者を想定している。導入方法や基礎理論は扱わない。ひとりのエンジニアが数ヶ月間Codexと向き合って得た、実践的な運用知見を語る。
数ヶ月で変わったこと
まず、ここ数ヶ月でAIコーディングツールの使い方が大きく変わったという話からしたい。
数ヶ月前のClaudeCodeガードレール戦略全盛期と比べると、隔世の感がある。あの頃は、AIが暴走しないように制御する、余計なことをさせないようにガードレールを張り巡らせることに頭を悩ませていた。Kiroが登場したときも、その延長線上にあった。
しかしGPT-5-Codexの登場で、その流れが変わった。
コンテキスト詰め込み時代の終わり
何が変わったのか。一言で言えば、コンテキストの扱い方だ。
従来のAI駆動開発では、コンテキストをどう詰め込むかが重要だった。コードの前提、背景、制約条件、守るべきルール――これらを詳細にプロンプトに盛り込むことが王道とされていた。
しかしGPT-5-Codexは、この方向性とは違うアプローチを取る。コンテキストは詰め込まなくていい。仕様はAIがコードから読み取ってくれる。
公式のプロンプティングガイドには、こう記載されている。
このモデルは、大きく異なるプロンプトを必要とするため、GPT-5の代替品にはなりません。
OpenAIは"not a drop-in replacement for GPT-5"（同じプロンプト設計のまま置換は不可）と明記している。開発者メッセージもGPT-5比で約40%のトークン量、つまり約60%削減されている。ガイド自体もシンプルで、「長い前置きや余計な誘導は品質を下げうる」という方向性だ。
従来のツールでは、プロンプトの最初に長い前置き（背景説明や制約条件）を書くことが推奨されていた。しかしGPT-5-Codexは、この前置きを受け付けない。むしろ長々と説明すると途中で停止することさえある。なぜなら、Codexはコードそのものから文脈を読み取る設計になっているからだ。言葉で説明するより、コードを見せた方が正確に理解する。
より詳しく知りたい方は、公式のガイドをぜひ見てほしい。
アンチプロンプティング
では、具体的にどうプロンプトを書けばいいのか。ここで登場するのが「アンチプロンプティング」という新しい考え方だ。
公式ガイドにも記載があるが、Codexでは「アンチプロンプティング」という発想が重要になる。これは、前処理（仕様・設計）は外部化し、入力は極小にするという方針だ。
従来のプロンプティングは、いかに多くの情報を正確に伝えるかに焦点があった。しかしアンチプロンプティングは真逆だ。いかに情報を削ぎ落とすか。いかに最小限の指示で済ませるか。
Codexはピンポイントに最低限の情報を渡すだけで、良い仕事をしてくれる。むしろ情報を与えすぎると、無駄なコンテキストを消費して精度が下がる。プロジェクト概要、守ってほしいルール、機能の詳細仕様、修正内容、これさえドキュメントにまとめて渡せば、後は勝手に判断して実装してくれる。
Codexの機能自体もシンプルだ。ClaudeCodeに比べると、サブエージェントのような仕組みもない。でも、それでも十分な性能を発揮する。プロンプトも機能も少なくていい、それでいてパワフル。この「Less is More」の発想が、Codexの特徴だ。
入念な実装プロセス
アンチプロンプティングの思想は、プロンプトだけでなく、Codexの実装プロセスにも表れている。
Codexが優れているのは、その実装プロセスの丁寧さだ。
従来のツールも実装前に確認はしていた。しかしCodexは執拗なまでに確認する。実装前に入念にチェックし、影響範囲を洗い出し、既存の実装を確認し、どこをどう変更すべきかを慎重に判断する。そして実装完了後も、影響範囲を見ながら問題が起きていないかを確認してくれる。とにかく既存の実装を無闇に変更しないので、手戻りが少ない。
ここまで安心してAIにリファクタを任せられるようになったのは、Codexが初めてだ。別画面の似たようなUIコンポーネントを共通化するリファクタリングで、1000行程度をワンショットで書かせたことがあるが、リファクタによる新しい不具合も見られなかった。
実装内容によっては自律的にマイグレーション対応を提案してくることもある。システムのアップデートによって旧バージョンのユーザーへの影響を考え、その影響が最小限にとどまるように実装してくる。
レビューでの議論
実装だけではない。Codexはレビューでも際立った特徴を見せる。
公式ガイドにも「コードレビューが得意」と明記されている。GPT-5-Codexは従来のモデルと比べて強情で細かい。
CodexからのPRレビューで一見微妙そうな提案があったとき、私はツッコミを入れるようにしている。「その提案はよくないのでは？」と反論すると、Codexは論理的に反論してくる。そして、話せば話すほど、結局GPT-5-Codexが正しいケースが多い。
むしろ議論していると、何故それが正しいか見えてくるし、Codexがちゃんと実装を理解してるのが伝わってくる。人間だと思って接した方が、うまく行く。良い意味で、人間のレビュアーとして扱うのがコツだ。
/compactこそが重要
ここまで聞くと、Codexは完璧に思えるかもしれない。しかし、そうではない。Codexにも明確な弱点がある。
Codexの弱点は、コンテキスト管理だ。単一スレッドで履歴が肥大すると、性能が下がる。Codexが優秀な分、この劣化が目立つ。
だから、Codex CLIの/compactで履歴圧縮を適宜実施することが重要だ。最近は自動で走らないケースも報告されているため、手動での実行を意識する方が、Codexの能力を引き出せる。どうプロンプトを作り込むかよりも、いつ/compactを意識するかの方が重要と言ってもいい。
公式ガイドでは、タスク自体は長時間の自律実行に耐える設計とされているが、実際の使用においては会話履歴の管理が鍵になる。ちょっと使ってすぐ新しいセッションを始める使い方になりがちだ。
私が実践しているのは、計画・影響範囲の洗い出しまでを一つのセッションで行い、それをドキュメント化しておいて、新規スレッドからそれを元に実装させる手法だ。
タスクを小さく分割し、短時間で完結させる。定期的に/compactで圧縮する。新しいタスクは新しいセッションで。これが、Codex運用の基本だ。
ツール間の使い分け
Codexの弱点を補う方法として、他のツールとの併用も有効だ。
私は普段からClaudeCodeとCodexを併用している。フロントエンドのUI改修は基本ClaudeCodeに任せて、Codexでレビュー&レビュー対応という使い分けだ。UI改修までCodexだと開発速度が遅くなりがちだし、雑な指示によるデザイン改善だけは、ClaudeSonnet4.5が上だと感じている。
PRの本文作成もClaudeに任せた方が良い。CodexのPRは人間があとから読んでも、なんの実装なのかわかりにくい。Codexは機械目線でのコード管理には強いが、人間向けのドキュメント生成はClaudeの方が得意だ。
弱点と課題
運用面での工夫以外にも、Codex自体の課題はある。
推論努力（reasoning_effort）の設定がわかりづらい。Codexではminimal、low、medium、highから選択できるが、効果は課題依存で一概には言えない。以下は私の実装時における観測に基づくが、highを選んでおけば正解というわけでもないように思う。highよりmediumの方が実行時間が長いケースもあったりして、わかりづらい。
ここ最近はmediumの良さ安定して際立ってきていて、highと遜色ない性能で速いレスポンス速度を実現してきている。highからmediumに変えたら、かなりCodexが速くなった。
この辺りは、ClaudeSonnetやOpusモデルのように、用途が違うことがわかるモデル分けの方が良かったように思う。
Codexの未来への期待
最後に、Codexの未来について少し語りたい。
最近、個人開発が減っているという話をSNSでよく見かける。vibe coderが開発を諦めているという意見もある。そんな人たちにこそ、Codexはおすすめしたい。
誤解しないでほしいのは、Codexは魔法ではないということだ。すぐにシステムが出来上がるわけではない。しかし、以前のAI駆動開発に比べて着実に進歩している。1歩ずつ進めていけば、しっかりと完成を目指せるところまで来ている。
もちろん個人開発者だけではない。大規模システムを作っているチームでも、Codexは十分実用に耐えられると思っている。
今後、Codexがどう進化するかはわからない。機能が増えて、今のシンプルさが失われる可能性もある。それでも、このツールが示した方向性、アンチプロンプティング、コードからの文脈理解、入念な実装プロセスは、AI駆動開発の一つの答えだと思う。
Codexとどう向き合うべきか。結局のところ、試して、理解して、信頼することだ。完璧なツールではない。弱点もある。でも、ちゃんと向き合えば、確実に前に進める。
この時代にエンジニアでいられることに、改めて感謝している。
Discussion