Claude CodeとCodexの使い分け｜査読論文7本と企業3事例

この記事の結論（先に3行）

・同じAI支援でも、効果はタスクによって符号ごと反転します。慣れないコードを一から書く実験では完了時間が55.8%短縮、自分が熟知した成熟リポジトリを熟練者が触る実験では逆に19%遅くなりました。ただしこの両端はどちらも未査読です（査読済みで最大規模の試験が測ったのは別の指標で、週次プルリクエスト数 +26.08%）。
・「使い分け」の判断軸は製品名ではなく、タスクの帯と膨らんだレビュー負荷をどこに置くかの2つです。製品としての Claude Code と Codex を直接比較した査読研究は、今回探した範囲では見つかりませんでした。
・企業の公開事例で「両方を役割分担して併用している」と一次で確認できたのは3件だけ。しかも3件とも分担の向きが同じでした。「企業では併用が主流」と書ける根拠は、今回の調査範囲にはありません。

この記事は、AIコーディング支援の査読論文7本（＋未査読2本・業界調査3本）と、企業が自社で公開している一次情報をもとに、「どっちが優秀か」ではなく「どこで効果が入れ替わるか」を整理したものです。全文無料です。

「賢い方に全部任せる」で組んで、詰まった話

先に、自分の失敗から書きます。

ぼくはこのnoteの制作を、Claude Code と Codex に分担させて回しています。執筆と実行が Claude Code、敵対的レビューと画像生成が Codex。今はそういう形に落ち着いています。

でも最初はそう組んでいませんでした。「賢いほうに全部任せればいい」と思っていたんです。書かせるのも、その原稿を採点させるのも、同じ系統に投げていた。

詰まったのはそこでした。自分が書いたものを自分で採点させると、返ってくる指摘がどうにも甘い。明確に間違っているわけではない。ただ、他人の原稿に向けるときの厳しさが出てこない。「よく書けています、細部を整えるとさらに良くなります」みたいな講評が返ってくる。

当時のぼくは、これをモデルの性能の問題だと思っていました。もっと賢いモデルを評価者にすれば解決する、と。今は違う見立てを持っています。これは性能の話ではなく、書き手と評価者が同一であることの構造の話だった。

その見立てが正しいのかを、査読論文と企業の公開事例で答え合わせします。

効果が反転する境界は、製品ではなくタスクの側にある

まず、いちばん大きな発見から。

AIコーディング支援の効果を測った介入研究を、タスクの新規性とコードベースへの精通度の順に並べてみます。すると効果量がだんだん小さくなり、端では符号が反転して見えます。

・一から書く定型タスク × そのコードに不慣れ: フリーランス開発者95名（完走70名）のランダム化比較試験で、完了時間が 55.8%短縮（95%CI 21%–89%、p=0.0017）。実測は71.17分 vs 160.89分でした（Peng et al. 2023、未査読。著者4名のうち3名は Microsoft Research と GitHub の所属＝Copilot の提供元側です）。
・正社員の日常業務をまるごと集計: Microsoft・Accenture・匿名のFortune100企業の3社で行われたN=4,867のフィールド試験で、週次プルリクエスト +26.08%（標準誤差10.3%、有意）（Cui et al. 2026、査読／Management Science。著者6名のうち2名は Copilot 提供元の Microsoft 所属で、実験先にも Microsoft が含まれます）。
・既存コードへの統合が重い企業タスク: Google の正社員96名を対象に、474行・10ファイルへの機能追加で測った試験。単純比較ではAI群96分に対し非AI群114分で、対数時間の検定は p=0.038 で有意でした。ところが著者らが最良適合とするモデルでは、AI条件の係数が約21%短縮に相当するものの、対数時間の係数の95%CIは[-0.51, 0.03]、p=0.086で非有意になります。別の統制モデルでは有意になっており、著者らはそのうえで非有意のほうを結論に採っています（Paradis et al. 2025、査読／ICSE-SEIP）。
・自分が熟知した成熟リポジトリ × 熟練者: 平均5年関わっている自分のOSSを扱う熟練メンテナ16名では、完了時間が 19%増加。つまり遅くなった（METR 2025、未査読。対象は2025年2〜6月時点のモデル環境です）。

55.8%短縮と19%増加は、正面から矛盾します。でも並べてみると、矛盾ではなく同じ勾配の両端のように見えてきます。手持ちの知識が少ない場面ほど得られる情報が多く、自分がすでに全部知っている場面では、AIの提案を読んで検証するコストのほうが上回る。

ただし、ここは慎重に書きます。これは勾配そのものが検証された話ではありません。 指標も母集団も設計も違う4つの研究を、こちらが並べ替えて眺めた解釈です。同じ条件でタスクの新規性だけを動かした実験があるわけではありません。

そのうえ、両端の派手な数字はどちらも未査読です。真ん中の査読済み2本は、効果が小さいか、頑健性を確かめると非有意になる。「55.8%速くなる」を期待値として持つのは、たぶん間違いです。

「初心者ほど得をする」は、まだ決着していない

ここで多くの記事が「だからAIは若手に効く」と書きます。ぼくもそう書きかけました。でも3本を並べると、そう単純ではありませんでした。

・Peng et al. 2023: 経験の浅い開発者ほど恩恵が大きい（p=0.0629＝境界的で、有意とは言い切れない）
・Cui et al. 2026: 在籍の短い人が+27〜39%、長い人が+8〜13%。職位でも下位が+21〜40%、上位が+7〜16%。方向は一致するものの、交互作用は p=0.21 と p=0.13 で非有意
・Paradis et al. 2025: シニアのほうが速い方向の示唆。しかも著者自身が「先行研究とは逆」と明記している

方向が食い違い、どれも統計的に確定していない。この論点の誠実な答えは、今のところ「わからない」です。 自分の直感（不慣れな領域ほど効く）に合う結果が2本あっても、それを結論にはできませんでした。

速くなった分は、どこへ移動したのか

活動量が増えるのは、査読済みの試験でも確認されています。問題はその後です。

開発ツールの実テレメトリを、開発者1万人超・1,255チーム分にわたって分析した業界レポートがあります。自己申告アンケートではなく、バージョン管理やCI/CDのログです。

それによると、AIをよく使うチームはタスク完了+21%・プルリクエスト統合+98%でした。ところが同時に、プルリクエストのレビュー時間が+91%、プルリクエストのサイズが+154%、バグが+9%。

順位相関であって因果ではありませんが、方向ははっきりしています（Faros AI 2025、ベンダーの自社レポート）。

これは単独なら割り引いて読む種類の情報です。販売しているのが開発生産性の計測基盤なので、「単純な指標では測れない」という結論は自社の訴求と利害が一致します。

ただ、査読済みのCui et al. 2026 が、同じ向きの数字を独立に出しています。ビルド回数は+38.38%（有意）に増えたのに、ビルド成功率は-5.53ポイント（非有意）。著者らはこれを「AIの提案を採用しては都度コンパイルして確かめる試行錯誤が増えた可能性」と留保つきで解釈しています。

つまり、増えているのは必ずしも「進んだ量」ではなく「試した量」かもしれない。そして増えた分の検証は、誰かがやることになります。プルリクエストの数だけを見て導入の可否を決めると、この移動が見えません。

単一の活動指標だけで開発生産性を測る危険は、Forsgren らが2021年に SPACE という枠組みで整理していました（ACM Queue・実務誌であって査読論文ではありません）。当時は実証データのない提案でしたが、上の2つがそれを別々の方法で裏づけた形になっています。

組織レベルでも似た向きの観測があります。回答者約5,000人の横断調査では、AI導入はスループットとは正の関連だった一方、配信の安定性とは負の関連でした（DORA 2025・業界調査。発行元の Google Cloud はAIコーディング支援を売る側です。レポート本体は今回入手できておらず、Google公式の告知記事経由の数値。相関であって因果ではありません）。

AIレビューは「直す」のは得意で、「見つける」のが苦手

では検証をAIに任せればいいのか。ここに、いちばん実務に効く査読データがありました。

コードレビュー自動化の実力を測ったIEEE TSEの論文（Tufano et al. 2024）は、専門特化した3手法と汎用LLMを比べています。結果は、タスクによってきれいに分かれました。

・与えられた指摘に従ってコードを直す: 55%
・自分でレビューコメントを書く、つまり問題そのものを見つける: 13%（大きく劣る）

ここで比較対象の「専門特化手法は50%」という数字を見かけますが、これは性能の測定値ではありません。比較用のサンプルが、既存手法の成功例と失敗例をわざと半々に選んで作られているので、既存手法側は設計上ちょうど50%になります。読むべきは、同じサンプルで汎用モデルが55%と13%に割れたという内訳のほうです。

同じ相手なのに、「直せ」と言えば戦力になり、「問題を探せ」と言うと大きく落ちる。レビュー工程は一枚岩ではなく、発見と修正に分けて割り当てるべきだという話になります。

ただしこの評価は2023年当時の ChatGPT を Web UI で手動操作したもので、リポジトリの文脈は与えられていません。正解判定も自動一致ではなく、著者2名がそれぞれ独立に目視で確認しています。著者ら自身が、評価データセットに25%のノイズがあることと、学習データ汚染の可能性を報告しています。2026年のエージェント運用にそのまま当てはまるとは限りません。

指示の粒度でも結果は動きます。GitHub上の実コード733件を静的解析した論文（Fu et al. 2025、ACM TOSEM）では、27.3%（200件）に脆弱性が見つかり、その修正成功率は指示の詳細さで19.3%から55.5%まで変わりました。静的解析のみで偽陰性がありうること、対象が低人気・新規のリポジトリに偏ることは、著者らが限界として挙げています。

曖昧な「レビューして」は、いちばん成功率の低い投げ方だということです。

検証を省くかどうかは、ツールでなく人のモードで決まっている

もうひとつ、行動の側から支える査読論文があります。

開発者20名がAIと対話する様子を質的に分析した研究（Barke et al. 2023、OOPSLA・Distinguished Paper）は、開発者が2つのモードを行き来していることを記述しました。

ひとつは加速モード。次に書くことが自分の中で決まっている状態で、AIの提案をパターンマッチのように一瞬で受理し、検証をほぼ省略します。もうひとつは探索モード。何を書くか自体を探っている状態で、提案を吟味しながら進む。

大事なのは、これが課題の種類ではなく、同じ課題の中を行き来する状態だという点です。参加者20名分を合計した対話時間は、探索モードで248.6分、加速モードで104.7分。探索側が2倍以上で、1回の判断に時間がかかっていました。

同じ人が、同じツールで、そのときのモードによって検証の厚みを変えている。これは効果量のない記述研究で、参加者もアカデミア寄り（20名中15名）です。それでも、使い分けの単位はツールではなくタスクだという主張を、行動のレベルから支えてくれます。

自分の書いたものを自分で採点すると、甘くなるのか

冒頭の失敗に戻ります。

いちばん近い査読証拠は、NeurIPS 2024にOral採択された研究でした（Panickssery et al. 2024）。GPT-4は自分の生成物を 73.5% の精度で他の生成物と見分けられ、しかも自己認識の強いモデルほど、自分の出力を高く評価する傾向があった。順序バイアスもLlama2で89%と大きい。

ただし、ここは限界をはっきり書く必要があります。この研究のタスクは要約2種類に限定されていて、コード生成やコードレビューでは検証されていません。 ぼくの体験に符合するからといって、これを証明として扱うことはできない。示唆どまりです。

面白いのは、同じ懸念に企業が独立にたどり着いていたことでした。ZOZOの基幹システム本部が公開している開発フローの記事に、こう書かれています。

（ZOZO TECH BLOG、2026-06-08）

「観点の独立性は強くありません」。ぼくが言葉にできずに詰まっていたものが、ここに書いてありました。分ける理由は片方が優秀だからではなく、評価者を書き手から独立させたいからだった。

企業は実際どう分けているのか（一次で取れた範囲だけ）

ここからは、企業が自社で公開している一次情報だけを見ます。ベンダーの発表や報道は、後で別枠にします。

ZOZO（基幹システム本部、2026-06-08）が最も具体的でした。Claude Code をオーケストレーター（設計書生成・実装・指摘の採否判断）、Codex を独自調査にもとづく批判的レビュアーとして分担し、2つのコマンドとして組織標準化しています。

手続きも公開されていて、最小3ラウンドです。Codexが独自に調べて批判し、Claude Codeが採用か却下かを理由つきで記録し、Codexが却下判断と残存リスクを再批判する。

ガードレールも具体的です。Codexへ送る差分に秘密情報が含まれていないかを確認する制約、最大3サイクルで同一指摘が2サイクル連続で残れば対話型に切り替える設計、収束しなければ人間の判断に戻すという線引き。人とAIの分け方も「同一レベル変換はAIに任せる／具体から抽象はAIに任せる／抽象から具体は人が主導する」と原理で書かれています。

そして重要なのは、併用が既定ではないことです。同社はトレードオフ表で、Claude Code単独を「通常モード」、併用を品質重視モードとして位置づけています。常時2系統に流してはいない。

併用の一次事例はほかに2件（アドバンテッジリスクマネジメント、クラスメソッド）見つかりましたが、いずれも組織標準ではなく個人の開発フローとして書かれたものでした。そして3件とも分担の向きが同じで、Codexが実装しClaude Codeがレビューするという逆向きの一次事例は、今回探した範囲では見つかりませんでした。

数値まで一次で取れた例は、さらに少ないです。カカクコム（食べログ）が、jQuery→React移植でレビューを自動化した前後を比較しています。

（食べログ テックブログ、2026-07-29）

同じ記事に、著者自身がこう注記しています。「Skillの使用を全員に義務付けているわけではなく、厳密な効果測定ではない参考値です」。対照群がなく、標本も10件と23件です。この注記ごと引かないと、数字が一人歩きします。

公式ドキュメントで確認できる、運用上のいちばん硬い差

ベンチマークのスコアより、公式ドキュメントに書かれた既定値のほうが、日々の使い勝手を左右します。今回いちばんはっきり確認できたのは、権限の初期値が逆を向いていることでした。

Codex の公式ドキュメントは「By default, the agent runs with network access turned off」と書いています。権限モードの案内でも「For most work, start with Ask for approval」と、承認を求めるところから始めるよう勧めています。

より自律的なモードは、ChatGPT デスクトップアプリの設定で明示的にオンにしないとメニューにすら出てこない、とも書かれています。ただしこれはデスクトップアプリについての記述で、CLI 利用者に同じ挙動が当てはまるかは確認していません。

Claude Code は逆向きです。「On Pro, Max, and Team plans, the built-in starting permission mode is auto mode」。分類器モデルが人の代わりに大半のアクションを審査するのが、初期状態になっています。

手動承認モードについては、公式自身がこう書いています。「That's safe but tedious. After the tenth approval you're clicking through rather than reviewing」。10回目の承認では、レビューではなくクリックになっている、と。

指示ファイルの扱いも非対称でした。公式が「Claude Code reads CLAUDE.md, not AGENTS.md」と明記していて、共存させるには import か symlink が要ります。量の制御も形式が違い、Codex は project_doc_max_bytes（既定32 KiB）で機械的に打ち切る一方、Claude Code 側は200行未満という目安です。

ここで正直に書いておくべきことが2つあります。ひとつ、相手製品との使い分けを示した記述は、両社のドキュメント索引を今回ひととおり探した範囲では見つかりませんでした。この記事の分担はぼくと各社の判断であって、公式見解ではありません。なお Codex 側の索引には、Claude Code 向けのプラグインに触れた項目はありました。

もうひとつ、使用量の直接比較は成立しませんでした。片方はメッセージ数のレンジを公表している一方、もう片方は今回確認した公式ページの範囲では倍率の表記しか見つけられず、揃えて並べられる形になっていないからです。

SWE-Benchのスコア差で製品を選べない理由

比較記事でいちばんよく見るのがベンチマークのスコアです。ここに、査読論文からの冷や水があります。

10種類のモデルを複数のベンチマークで評価した研究があります（Liang et al. 2026、ICSE-SEIP）。測っているのは「不具合の説明文だけを渡して、どのファイルが原因かを当てさせる」という診断タスクの精度です。SWE-Bench-Verified の中では最大76%だったのに、ベンチマーク外のリポジトリでは最大でも53%に落ちました。

Verified 60〜76% → Full 57〜71% → 同じリポジトリに後から立った新しいissue 50〜68% → ベンチマーク外のリポジトリ 53%以下、と段階的に下がります。著者らは学習データへの混入、つまり記憶が高スコアの一因ではないかと示唆しています。

この研究自体はモデルの評価研究で、現場の生産性を直接測ったものではありません。それでも、ベンチマークのスコア差をそのまま現場の生産性差に読み替える橋が、まだ架かっていないことは示しています。

派手な数字ほど、測り方が書かれていない

最後に、数字の受け取り方を1つだけ。今回いちばん印象に残ったのは、この非対称でした。

派手な数値は、ほぼすべてベンダー側の発表で、測定方法が書かれていません。 一方、企業が自社ブログに書いた数値は地味で、しかも限界の注記がついている。食べログの15.10→8.04がまさにそれでした。この差は偶然ではないと思います。

たとえば OpenAI が自社ブログで公表した「Codexを使うエンジニアはマージされたプルリクエストが約70%多い」という社内数値。これは使う人と使わない人の比較です。

同じ人の前後比較でもランダム化でもないので、もともと生産性の高い層が先に使い始める自己選択を統制できていません。因果ではない。参考までに、熟練OSSメンテナ16名を対象にしたランダム化比較試験である METR（未査読・2025年2〜6月時点のモデル環境）は、逆に19%の減速を報告しています。

そして、いちばん効く限界がこれです。撤退や中止の公開報告は、一次で1件も見つかりませんでした。 企業の技術ブログは採用広報を兼ねていて、「導入したけどやめた」は書かれにくい。だから「企業はこう使っている」という文は、正確には「うまくいった企業がこう書いている」以上の意味を持ちません。生存者バイアスそのものです。

今日からできること

研究と事例から、実際に手を動かせる形に落とすと4つでした。

1．ツールを選ぶ前に、タスクの帯を判定する。 「このコードにどれくらい精通しているか」「書く内容は自明か、探索か」の2問だけ。自分が熟知した成熟コードを触るときは、委譲しない判断も合理的でありえます。
2．レビューは発見と修正に分ける。 「指摘に沿って直す」はAIに任せ、「そもそも何が問題か」と「指摘を採るか捨てるか」は人が握る。曖昧な「レビューして」は避けて、観点を具体的に渡す。
3．プルリクエスト数だけで判断しない。 同時にレビュー時間とプルリクエストのサイズを記録する。これを見ないと、増えたのが「進んだ量」なのか「試した量」なのか区別できません。
4．併用を既定にしない。 ZOZOも通常は単独運用で、併用は品質重視モードのときだけです。分けるなら、収束しない場合の打ち切り規則を先に決めておく。

ぼく自身の運用も、ここに合わせて言い直せるようになりました。Codexに敵対的レビューを任せているのは、Codexが優秀だからではありません。書き手と評価者を別の系統にしておきたいからです。理由が言語化できると、モデルが世代交代しても判断がぶれません。

おわりに — この記事も、同じ手順を通しました

「どっちが優秀か」を調べるつもりで始めて、出てきた答えは「その問いは立て方が違う」でした。効果が反転する境界はタスクの側にあり、分担の理由は優劣ではなく独立性にある。

正直に書いておくと、この記事自体も2つのレビューを並列にかけました。ひとつは Codex 側。もうひとつは Claude 側です。書き手も Claude Code なので、後者は「同じ系統で、役割と文脈だけを分けた別のエージェント」ということになります。

まず、両方が独立に同じ誤りを指摘してきました。ぼくが本文で「唯一のランダム化比較試験」と書いた研究について、同じ記事の前半で別の2本もランダム化比較試験として紹介している、という自己矛盾です。

そのうえで、それぞれにしか見えなかった指摘もありました。書き手と同じ系統のレビューは、ある論文の数字をぼくが「1つの課題にかかった時間」と読んでいた誤り（原典は参加者全員の合計時間）を拾いました。別系統のレビューは、断定が強すぎる箇所やCTAの位置といった、構成側の穴を拾いました。

独立性は、モデルの系統だけで決まるわけではなさそうです。 役割と文脈を分けることでも生まれる。少なくとも今回わかったのはそこでした。どの指摘も、書いた本人には最後まで見えていませんでした。

もし今、片方のツールだけを使っていて手応えが薄いなら、乗り換える前にタスクの帯を疑ってみるのが早いかもしれません。

ベンダーの発表する数字を、査読論文と企業の一次情報で検算する記事を書いています。機能比較表ではなく、導入判断の根拠のほうを追いたい方は、note（designing_edges）のフォローが役に立つと思います。X（@SB040）でも要点を配布しています。

2つを併用している方は、コメントで次の3点を教えてもらえると嬉しいです。ぼくが次に調べる一次情報になります。

1．実装役はどちらか
2．レビュー役はどちらか
3．併用を打ち切る条件を決めているか

特に、今回一次では見つけられなかった「Codexが実装、Claude Codeがレビュー」という逆向きの分担をしている方の話は、ぜひ聞いてみたいです。

関連記事:
・「AIっぽい文章」チェック、89記事の前後比較
・効くSkillは説明文で決まらない
・AIエージェントが選ぶツールを元データで検算した

この記事の限界

・製品としての Claude Code と Codex を直接比較した査読研究は、今回探した範囲では見つかりませんでした。 引用した研究はすべて「AIコーディング支援一般」または Copilot についてのものです。製品名レベルの優劣を研究から導くことはできません。
・効果の勾配の両端（55.8%短縮と19%増加）は、どちらも未査読の研究に依存しています。
・「若手が得か、シニアが得か」は3研究で方向が食い違い、いずれも検出力が足りていません。
・自己選好バイアスの研究は要約タスク限定で、コード領域では未検証です。
・併用の一次事例は3件のみ、うち2件は個人の運用です。「企業では併用が主流」とは言えません。
・事例が日本のWeb系企業に偏っています。正しくは「世界の企業はこうしている」ではなく「詳細を公開している企業はこうしている」です。
・なお、モデルを役割ごとに使い分けている事例としてCloudflareがよく挙がりますが、同社のエージェント本体はOSSのOpenCodeで、製品としてのClaude Code / Codexの使い分けではありません。混同しないよう、ここでは事例に含めていません。
・すべて 2026-09-09時点の観測です。ZOZO自身も「AIの性能向上や学習技術の変化により、境界は動きます」と書いているとおり、モデル世代が変われば最適な分担も変わります。

参考文献

査読論文（7本）

・Cui, K. Z., Demirer, M., Jaffe, S., Musolff, L., Peng, S., & Salz, T. (2026). The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers. Management Science. DOI: 10.1287/mnsc.2025.00535 
・Paradis, E., et al. (2025). How Much Does AI Impact Development Speed? An Enterprise-Based Randomized Controlled Trial. ICSE-SEIP 2025, pp.618–629. arXiv: https://arxiv.org/abs/2410.12944 
・Tufano, R., Dabić, O., Mastropaolo, A., Ciniselli, M., & Bavota, G. (2024). Code Review Automation: Strengths and Weaknesses of the State of the Art. IEEE Transactions on Software Engineering, 50(2), 338–353. DOI: 10.1109/TSE.2023.3348172 
・Barke, S., James, M. B., & Polikarpova, N. (2023). Grounded Copilot: How Programmers Interact with Code-Generating Models. PACMPL, 7(OOPSLA1), Article 78. DOI: 10.1145/3586030 
・Fu, Y., et al. (2025). Security Weaknesses of Copilot-Generated Code in GitHub Projects: An Empirical Study. ACM TOSEM. DOI: 10.1145/3716848 
・Panickssery, A., Bowman, S. R., & Feng, S. (2024). LLM Evaluators Recognize and Favor Their Own Generations. NeurIPS 2024. arXiv: https://arxiv.org/abs/2404.13076 
・Liang, S., Garg, S., & Zilouchian Moghaddam, R. (2026). The SWE-Bench Illusion: When State-of-the-Art LLMs Remember Instead of Reason. ICSE-SEIP 2026, pp.395–405. DOI: 10.1145/3786583.3786882 

未査読プレプリント（2本・査読を経ていません）

・Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv: https://arxiv.org/abs/2302.06590 
・METR (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv: https://arxiv.org/abs/2507.09089 

業界調査・実務誌（3本・査読論文と同格には扱えません）

・Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., & Butler, J. (2021). The SPACE of Developer Productivity. ACM Queue, 19(1). DOI: 10.1145/3454122.3454124 
・DORA (2025). State of AI-assisted Software Development Report. https://dora.dev/dora-report-2025/ 
・Faros AI (2025). The AI Productivity Paradox Report. https://www.faros.ai/blog/ai-software-engineering 

企業の一次公開情報

・ZOZO TECH BLOG（2026-06-08）https://techblog.zozo.com/entry/ai-development-two-commands 
・食べログ テックブログ（2026-07-29）https://tech-blog.tabelog.com/entry/react-pipeline-review-digest-claude-code-quality-automation 
・アドバンテッジリスクマネジメント（2026-06-16）https://zenn.dev/arm_techblog/articles/7712cde19988c8 
・ZOZO 公式リリース（2025-07-29）https://corp.zozo.com/news/20250729-007217/ 
・クラスメソッド DevelopersIO（2026-05-28）https://dev.classmethod.jp/articles/claude-code-codex-cross-review/ 
・OpenAI 公式ブログ（社内でのCodex利用・「約70%多い」の出所）https://forum.openai.com/public/blogs/how-openai-engineers-use-codex-to-tackle-big-projects-with-rigor-2025-12-04 

公式ドキュメント（いずれも2026-09-09時点。本文の英文はこれらの原文からの引用です）

・Claude Code 権限モード https://code.claude.com/docs/en/permission-modes 
・Claude Code メモリ・CLAUDE.md https://code.claude.com/docs/en/memory 
・Codex 承認とセキュリティ https://learn.chatgpt.com/docs/agent-approvals-security 
・Codex AGENTS.md の扱い https://learn.chatgpt.com/docs/agent-configuration/agents-md 
・Claude Code ベストプラクティス（「tenth approval」の出所）https://code.claude.com/docs/en/best-practices 
・Codex 権限モード（「For most work, start with Ask for approval」の出所）https://learn.chatgpt.com/docs/permission-modes