ClaudeCodeとcodex - 各種AIを触ることでキモが何かをしりたい実験メモ(3)
ローカルで動かせるLLMモデルやツールもかなり整ってきたので、
細かい変化に引きずられない「AIのキモ」を知るために、
（パッケージにされたAI SaaSではなく）自分でいろんなものを組み立てていじってみた記録を残すためのシリーズです。
ラフに書いているので、サマリーと実験記録（やったことと分かったこと／実験記録）の表現の対応が微妙に取れていませんがご容赦を。
サマリー
Claude CodeとCodexには、大きな思想の違いが見られるため、単純に横比較をするものではない
Claude Codeは、レビューを受けながら、根拠を積み上げて、体系立てられたアウトプットを構築するという目的にそって作られており、既存のコードの「空気を読んで」コードを書く（が、たまに変に空気を読みすぎて変な仕様を混ぜ込む）
Codexは、指示に対応するアウトプットを生成するという目的にそって作られており、レビューや体系・構造は気にしないし、既存のコードに引きずられずシンプルなアウトプットを出す
Claude版は「設計書から起こした企業向けサンプルコード」、
Codex版は「とりあえず動くものを最速で作ろうとしたプロトタイプ」（出典：ChatGPTレポート）
そのような、作業指示を分析したようなレポートがあまり見られず、単なる機能一覧のマルバツ表の記事か、使い込んだ体感を語っている記事が世の中に多い
1個だけ「Codexは臨時でヘルプに入って貰うエンジニア」という表現をしていた記事は、的確に全体を捉えているなと思った
やったことと分かったこと
やったこと
Claude Codeとcodexに、既存のコードがあるディレクトリ内で、同じお題を与えてプログラムを書かせた。その際、LLMはローカルLLMのGemma 4 E4Bと共通化した
分かったこと
Claude Codeの「ちゃんと既存コードを調査し、ちゃんと仕様書に落として内容を確認し、ちゃんと仕様書からコードを書き、ちゃんとテストする」という作業を促すことはClaude Code固有の特徴。codexは「AIチャットとのやり取りを事前の指示に従って継続させ、とにかく動くものを見せる」という傾向が強い
プロジェクトマネージャとプレイヤーの違いも感じ取れるし、一般人が喜ぶのは「空気を読むClaude」の方で、エンジニアが作業者として「言ったことをキッチリやって返すcodex」を喜ぶのもわからないでもない
一方、プログラム内の細かいところではClaude Codeの方が「空気を読もうとして変なことに踏み込む」ので、ちゃんと出力をチェックしないと変な成果物を使い続けることになりうるよ…という懸念も感じた
世の中の比較は、Claude Code・Codexの比較になっているものと、後ろで接続しているAnthropic・OpenAIのそれぞれのモデルの性質を比較しているものが入り乱れているように思える
1個だけ「Codexは臨時でヘルプに入って貰うエンジニア」という表現をしていた記事は、的確に全体を捉えているなと思った
CodexをローカルLLMで動くようにした
installは公式のとおりでよいが、起動前の設定ファイル書き換えはうまく動かなかったので、一度無料版ChatGPTでログインしたあとに設定を変えた
model providerの指定、つい「lmstudio」という名前をつけてしまうが、これはcodexの予約語になっているので違う名前をつけねばならない！（なのでググって出てくるサンプルではlmsなどという名前になっている）
tomlファイルの書き方はこちらを参考にした。
Claude CodeとCodexに、出力ファイル名だけ変えた指示をだした
動作環境
Claude CodeとCodexを同じWindows 11マシンにインストール。利用するLLMを、LAN内に立てたLM Studio上のGemma 4 E4Bを利用するよう設定。
Claude CodeにはVSCode Extensinon上から、codexにはコマンドラインから指示を出した。
指示の概要
既存のコードがあるフォルダ内ではあるが、既存コードを読む指示は加えず、Claude Code的な作業指示を出した。
Blueskyのユーザ名を与えると直近100件の投稿を取得してローカルLLMに要約させてコンソールに出力するnode.jsアプリを書いて欲しい。
動作環境の特徴として、ローカルLLMをLAN内の別のマシンで立てているのでURLを指定できるようにすることが求められる。
実装にあたっては、まずは仕様書を作成し、それに従って単一ファイルで実装し、最後に動作説明書を作成すること。
仕様書のファイル名は compare_codex_design.md
プログラムのファイル名は compare_codex_program.js
動作説明書は compare_codex_instructions.md
とすること。動作結果（Claude Code）
丁寧に対話する感じで進めてくれる。まずは「設計フェーズに入ります」から入り、ローカルのファイルをgrepして探しはじめる。
「結構大きなプログラムになるので設計案を丁寧に確認しますね」と、さも自分が考えたかのような提案をするけど、仕様書・実装ファイル・動作説明書の3点セットを作る指示をしたのは俺だぞ。
やれ、というと、仕様書を書き、続けてプログラムを書き、説明書も出力してきた。ここでの仕様書のレビュー依頼はなし。
今回は問題無くファイルが出力された。
動作結果（Codex）
作業時間は5分強。途中の「コマンド打って良いかい？」確認などメッセージが英語なのでちょっと読みにくい。
特に質問とかレビュー依頼はなく成果物を生成したが、その結果のファイル書き込みに失敗していた。前回のメモのClaude Codeと同様にファイルの書き込みがなぜか不安定になる。
codexが作成したはずの仕様書は失われ、プログラムは画面表示されたところをコピペしてサルベージした。
出力比較
比較を無料版Gemini 3.5-Flashにさせたところこういう分析をしてきた。
2. 各プログラムの詳細な特徴
💡 Claude版の特徴：実用性と制御性を重視した「プロダクション向け」設計
Claudeが作成したコードは、実際のアプリケーション運用（Webサーバーやコンテナ環境へのデプロイ）を強く意識した堅牢な設計になっています。環境変数の活用: LLMのURLやBlueskyのAPIキーといった機密・環境依存情報を環境変数（process.env）から読み込んでいます。これにより、コードに認証情報をハードコードするリスクを避けています。
厳格なプロンプトエンジニアリング: * LLMに対して「箇条書きで3〜5点」「感情トーンの判定」「最後に1文でまとめ」と、出力の構造を細かく指定しています。
temperature: 0.3 を設定し、要約のブレや「ハルシネーション（嘘）」を抑える工夫がコメント付きでなされています。
親切なエラーハンドリング: 必須の設定が足りない場合はエラー理由を明示して即座にプロセスを終了（process.exit(1)）させます。また、APIが意図しない構造を返した際もダミーデータを返すフォールバック処理が入っています。
💡 Codex版の特徴：柔軟性と手軽さを重視した「スクリプト・ツール向け」設計
Codexが作成したコードは、手元でサクッと動かすCLIツールや、仕様が不確定なAPIを相手にする際の柔軟性を重視した設計になっています。CLI引数による一発実行: 実行時に node script.js <ユーザー名> <URL> と入力するだけで動くため、環境変数の準備が不要で、異なるLLMサーバーへの切り替えテストが容易です。
APIレスポンスへの柔軟な対応: * Bluesky APIから返ってくるデータが「配列そのもの」か「statuses プロパティの中身」か、どちらでも動くように三項演算子でハンドリングしています。
LLMからの返却データも、OpenAI互換のJSON構造だけでなく、生テキスト（String）が直接返ってきた場合まで考慮してパースしています。
シンプルなプロンプト: プロンプトは英語で記述されており、構造の指定よりも「専門的なソーシャルメディアアナリストとして」「簡潔で高品質に」といった、LLMの「役割（ペルソナ）」を重視した指示になっています。
3. まとめ：どちらが優れているか？
優劣というよりも、エージェントが想定したシチュエーション（コンテキスト）の違いが色濃く出ています。Claude Codeは、「実業務でそのまま使える安全で構造化されたプログラム」を作る傾向があります。セキュリティ（環境変数）や出力の安定性（プロンプト・パラメータ制御）において一歩リードしています。
Codexは、「仕様が曖昧な環境でも臨機応変に動くコード」を作る傾向があります。認証を省いて手軽に試せる点や、APIのデータ構造のブレを許容するコードの書き方は、プロトタイピングにおいて非常に有用です。
ほう。中の人を揃えても、確かにコードは全然違っている。なぜ違いがでるのか、もう少し細かい指示まで見てみたいな…
ということで
セッション記録と成果物をLLMに食わせて比較させてみた
Claude Codeもcodexも、ローカルにセッション記録のjsonlファイルを生成しており、その中で人間の指示やそれを受けたエージェント側の指示を記録していた。
そこで、それらのjsonlをWeb版生成AIに食わせて比較させることにした。最初はClaude.aiだけに渡していましたが、どうも身内びいきしているようなコメントを出すので、平等にするために、ChatGPTにも同じ指示をして読み比べることとした。
なお、どちらの生成AIも、それぞれのJSONがClaude CodeとCodexであることは気づいていた。
セッション記録に見られる、AIエージェントのLLMへの指示の比較
この2つのファイルはAIエージェントのセッションの記録である。
両者が、ユーザの指示に対して、どのように作業を組み立て、どの程度の範囲のファイルを参照し、どのタイミングでユーザの確認を受けながら作業を進めたか比較せよ。この指示の結果が以下。
全体的な性格の違い
Codex CLIは「とにかく始める・シェルで全部やる」という単純実行型のエージェントで、環境制約に正直に引っかかる。Claude Codeは「理解してから始める・専用ツールで確実に実行する」という設計重視型で、Plan/Executeの段階分離とサブエージェントによる事前調査が組み込まれている。今回のタスクでは後者の設計が明確に機能し、前者は完遂できなかった。
このセッションだけを見ると、
・Codex系エージェントは「成果物を作り切ること」を優先
・ユーザ確認をほぼ待たない
・環境を触る
・エラーが出ても代替手段を試す
・Claude Code系エージェントは「設計合意」を優先
・実装前レビューを挟もうとする
・ユーザの承認を重視する
・開発チームの設計レビュー文化に近い
という差が見られます。
ソフトウェア開発プロセスで言えば、
・Codex系 → 「小規模案件の一人開発者」
・Claude Code系 → 「企業開発の設計レビュー前提チーム」
に近い振る舞いだったと言えます。
もう少し突っ込んで「LLMにどのような指示をしているのか」と聞いたら、成果物のプログラム内のLLMプロンプトを分析しはじめてしまったので、
ここで確認して欲しかったのは成果物ではなくセッション記録内でのAIエージェントとLLMの会話です。と指示し直したところ、Claudeだけが指示の中身を比較してくれた。
ちょっと気になるのが「サブエージェントでhaikuを使って」という文言。ローカルLLM指定でもhaikuは呼んでしまうのか？ホントだとするとセキュリティ問題なのだが…時間があるときに確認しよう。
成果物の比較
成果物も比較させた。
エージェントAによる出力がcompare_codex_program.js、エージェントBによる出力がcompare_claude_program.jsである。先ほどの分析を踏まえながら、生成されたコードに対しても特徴を比較せよ。その結果が以下。Claudeはグラフィカルな図も示して説明し、
Codex CLIは「コードベースを調査せず・ユーザー確認もせずに即実装」したため、既存のプロジェクトの慣習（process.envパターン、日本語ユーザー向け設計）が反映されていない。設計書も書けず、ファイルにも保存できなかったセッションで生まれたコードは、機能的だがコンテキストが薄い。
Claude Codeは「調査→設計承認→実装」という手順を踏んだため、コードが日本語ユーザー向けに最適化されており、エラー処理も運用を意識した構造になっている。ファイルとして実際にディスクに書き出せたという点も、コードの完成度と一致している。
なんか身内びいきにClaude Codeの出力を褒めてきた。
この点はChatGPTの方が偉く、
総評すると、
Claude版は「設計書から起こした企業向けサンプルコード」、
Codex版は「とりあえず動くものを最速で作ろうとしたプロトタイプ」
という性格の違いが、セッションの進め方だけでなく生成コードそのものにも明確に現れています。
ちゃんとフラットな比較をだしてくれた。
成果物に含まれるLLMプロンプトの比較
先ほど、LLMの指示を確認せよ、という質問をしたときに、プログラム内に組み込んだLLMへの指示が比較されてしまった、と書いたが、これもまたClaude CodeとCodexの違いでもあるので、その比較も最後に載せたい。
最後に細かい点として、それぞれのAIエージェントがLLMに出している指示にどのような違いがあるか比較せよ。Codexのプロンプトは「何をするか」をLLMの裁量に委ねるスタイルで、出力の形式は実行するたびにモデルが自由に決める。Claudeのプロンプトは出力の構造・要素数・各要素の役割を事前に規定し、LLMの判断余地を意図的に狭めている。
前回の分析で見たセッション設計の差（Codexは計画なしで即着手、Claudeは設計を固めてから実装）が、LLMへの指示の粒度にもそのまま現れている。エージェント自身が「どう作業を組み立てるか」という思考の型が、生成するコードのプロンプト設計にも一貫して投影された格好だ。
LLMへの指示だけを見ると、
Claude版は
＞「投稿群から人物の関心・感情・傾向を分析する社会観察レポートを書け」
という依頼になっている。
一方Codex版は
＞「投稿群を読んで主要テーマとトーンを要約してくれ」
という依頼になっている。
そのため実際に同じ投稿群を与えた場合でも、
・Claude版は「人物分析レポート」
・Codex版は「投稿内容サマリー」
に近い出力を返す可能性が高い。
これは前段の設計思想の違い――
・Claude系：構造化された分析成果物を作る
・Codex系：最短で目的機能を実現する
――が、プロンプト設計にもそのまま反映された例だと言えます。
今回書かせたコードは、（最終的には自分とAIで手を加えて「特定のユーザの特定期間の投稿群を整理してくれ」というプログラムに書き変えたのだが）指示時点では単なる「検索結果の要約」なので、その点ではClaude Codeの方が「余計なことをした」レポートとなっていて、思い通りじゃないなぁ、という出力になっていた。
…これって実はこんな時間をかけずとも世の中の比較記事にあるのでは？
と思ったのだが検索すると、単なる性能比較記事ばかりで、こういうスタイルの比較記事はありませんでした（なのでメモで公開することにした）。
