Claude Code と Codex、どっちを使う？

Claude Code と OpenAI Codex を、同じリポジトリで17日間、毎日自動で動かしました。2026年8月16日から9月1日までの27ラン分の実行ログが残っています。

先に結論を書きます。この記事は「どちらが優秀か」には答えません。当メディアの2体は担当している工程が違い、同じ仕事をさせた比較ではないからです。完走率77%対57%、所要時間の中央値32.3分対11.3分という差は出ましたが、工程数が違うので優劣の根拠にはなりません。

答えられるのはこちらです。併用は成立します。そして工程で分けたほうが、両方の弱点が消えます。落ちて困る工程を完走率の高いほうへ、数を当てにいく工程を速いほうへ寄せる、という分け方です。

そして併用で実際に壊れたのは、事前に警戒していた「同じファイルを2体が同時に書く」ではありません。一度も起きませんでした。問題になったのは生成処理ではなく公開処理という共有工程の奪い合いで、17日間で1回でした。

この記事は、その1回が何だったのか、なぜ生成処理では衝突しなかったのか、そして併用を始める人が最初に何をすべきかを、実行ログと実装コードを添えて書いたものです。うまくいった話だけではありません。Codexの原稿は4割を没にしていますし、Claudeは3日連続で落ちた週があります。

クイック比較：17日間の実測でどう違ったか

同じ仕事をさせた比較ではありません。Claude Code は公開まで通す工程、Codex は生成と検証までを担当しているので、工程数が違います。「どちらが優秀か」ではなく「どちらにどの工程を任せるか」の材料として見てください。

片方に寄せるなら Claude Code、速さが要るなら Codex、両方あるなら工程で分ける。 その分け方を以下で書きます。

結論：衝突するのは公開処理だけ。だから分ける順番が決まる

分ける順番は 「書いてよいディレクトリ → 実行時間 → ロック」 です。この順でなければいけない理由があります。

1番目を飛ばして時間だけずらしても、ジョブが長引いた日に重なれば壊れます。1番目を飛ばしてロックだけ掛けても、生成処理までロックの対象になり、遅いほうが速いほうを止めます。領域を分けてしまえば、生成処理は互いを見なくて済む。 そのうえで残る共有部分だけにロックを掛けるので、ロックの範囲が最小になります。

当メディアの分け方はこうです。

Codex には公開・FTP・外部送信の権限を与えていません。検証に通った原稿を content_queue/codex/review_required/ に置くところまでが担当で、そこから先は翌朝の Claude が一次ソースを再確認したうえで採否を決めます。権限を絞ったのは安全のためだけではなく、共有部分を減らせばロックの範囲が小さくなるからです。

17日間、実際に何が起きたか

automation/runs/ に残った27ラン分を集計しました。

17日間の実測結果の図解

17日間の実測（2026-08-16 〜 09-01・全27ラン）

ジョブ成功率

1ランの所要時間（中央値）

速いのは Codex、完走するのは Claude という結果になりました。中央値で3倍近い差があります。ただしこれは同じ仕事をさせた比較ではありません。Claude は公開まで通す工程、Codex は生成と検証までなので、そもそも工程数が違います。「どちらが速いか」ではなく「どちらにどの工程を任せるか」の材料として見てください。

Codex がレビューへ送った原稿は8本、却下は6本で、採用率は57%でした。却下の理由で最も多かったのは品質ではなく「その語を誰も検索していない」です。実際の却下記録から1件引きます。

target_kw: Dify クラウド セルフホスト 費用 ／ サジェスト0件 ／ 却下理由「需要ゼロ。本文のTCO計算自体は品質基準を満たしている」

本文の質は問題なく、狙った語に需要が無かったので落としています。この失敗が続いたので、途中から需要ゲートを Codex 側の必須条件に入れました。

最初に壊れたのは「同じファイルの同時編集」ではなかった

併用を始める前に警戒していたのは、2体が同じ記事ファイルを同時に書き換えて内容が混ざることでした。17日間で一度も起きませんでした。 領域を分けた時点で、生成処理は互いのファイルを見に行かないからです。

実際に起きたのは8月24日の1回だけで、公開処理の取り合いでした。

ロックが取れなかった回に何が起きたかの図解

ロックが取れなかった回に何が起きたか（2026-08-24）

なぜ「待つ」ではなく「落とす」なのか

ロックの実装は Windows の msvcrt を使っています。運用中のものをそのまま載せます。

@contextmanager
def named_lock(name: str) -> Iterator[None]:
    import msvcrt

    if not re_fullmatch_lock_name(name):
        raise ValueError("lock name is invalid")
    lock_path = AUTOMATION / "locks" / name
    lock_path.parent.mkdir(parents=True, exist_ok=True)
    handle = lock_path.open("a+b")
    try:
        handle.seek(0, os.SEEK_END)
        if handle.tell() == 0:
            handle.write(b"0")
            handle.flush()
        handle.seek(0)
        try:
            msvcrt.locking(handle.fileno(), msvcrt.LK_NBLCK, 1)
        except OSError as exc:
            raise RuntimeError("別のAIディア編集ジョブが実行中です") from exc
        yield
    finally:
        try:
            handle.seek(0)
            msvcrt.locking(handle.fileno(), msvcrt.LK_UNLCK, 1)
        except OSError:
            pass
        handle.close()

要点は LK_NBLCK です。ブロッキングしないロックを使い、取れなければ即座に例外を投げます。 待ちません。呼び出し側はこれを終了コード75に変換して、その回のジョブを終わらせます。

待たせない理由は図解にも書きましたが、待つ設計にすると公開処理が長引いた日に2体が同時に生き残ります。そうなると生成の途中で相手の成果物が入れ替わる可能性が出てきます。1日1回の定期実行であれば、1回落としても翌日には戻ります。取りこぼし1回と、壊れた記事を公開するリスクを比べたら、前者のほうが安いという判断です。

17日間でこの発動は1回でした。これが頻発するなら、問題はロックではなくジョブ時間の設計です。 当メディアは07:03と12:03で5時間空けており、所要時間の中央値の合計は約44分なので、通常はまったく重なりません。

どちらに何をやらせるか

17日間の実測から、工程の割り当てをこう決めました。

どちらに何をやらせるかの判断フローの図解

どちらに何をやらせるか（17日間の実測から）

速さと完走率が逆。片方に寄せるより、工程で分けたほうが両方の弱点が消える。

分ける順番は「領域 → 時間 → ロック」

3. 共有する処理だけロックを取る（公開とキュー移送だけ。生成処理は取らない）

自分の環境に当てはめるときは、次の数字を置き換えて考えてください。

• 完走率：落ちて困る工程を、完走率の高いほうへ寄せます。当メディアは77%と57%でした。この差が小さいなら、工程で分ける必要はありません
• 所要時間の中央値：2体の合計が、ジョブ間隔より十分に短いかを見ます。当メディアは合計約44分に対して間隔5時間なので、9%程度の占有率です。ここが50%を超えるなら、ロックの発動が常態化します
• 採用率：生成側の原稿がどれだけ採用に至るかです。当メディアは57%でした。ここが低いままなら、生成の速さは意味を持ちません

これから併用する人が最初にやること

順番どおりにやってください。1番目を飛ばすと、あとの2つは効きません。

1. 書いてよいディレクトリを分ける。 紙に書くだけでなく、片方の権限を実際に外します。当メディアは Codex から公開・FTP・外部送信の権限そのものを外しました
2. 実行時間をずらす。 所要時間の中央値を測ってから決めます。測らずに決めると、たいてい足りません
3. 共有する処理だけにロックを掛ける。 生成処理には掛けません
4. 落ちた回をログに残す。 終了コードで区別できるようにしておくと、あとから「ロックの取り合いが何回起きたか」が数えられます。今回の記事はこのログだけで書けています

なお、当メディアは Windows で運用しています。この記事のロック実装が msvcrt なのはそのためで、Linux や macOS では fcntl に置き換えてください。Windows 環境ではほかにも踏んだ罠がいくつかありますが、それは別記事にします。

17日間ぶんの実測なので、これが3ヶ月、半年と続いたときに同じ結論になるかはまだ分かりません。とくに採用率57%は改善余地しかない数字で、需要ゲートを入れた効果はこれから測ります。続きは運営ログで随時公開します。

どちらを使うかの前に、そもそも操作の何割が何に使われているかはClaude Code の使い方で数えました。