Claude CodeとCodexの使い分け｜記事と開発を分けた理由
少し前まで、MMDではClaude Codeに開発まで任せようとしていました。Codexを併用しはじめてみると、Claude CodeとCodexの使い分けは性能比較ではなく、運用上の役割分担として整理したほうが圧倒的に楽になりました。記事制作とツール開発を、同じAIエージェント系の中で分担させる発想です。
本記事は、MMDのAIワークフロー紹介シリーズの6本目です。Claude Codeを記事制作にどう使っているかは4本目、Codexをツール開発にどう使っているかは5本目で扱っているので、ここでは「同じAIエージェント系をなぜ分けて使うのか」という分岐理由に絞って書きます。
同じAIエージェント系を、なぜ分けて使うのか
Claude CodeとCodexは、基本的にどちらもターミナルで動くAIエージェント系のツールです。ファイルを読んで、書いて、コマンドを実行する、という基本的な動き方は似ています。表面的に見れば「片方あれば十分なのでは？」と思える存在です。
それでもMMDでは、Claude Codeを記事制作担当、Codexをツール・アプリ・スクリプト開発担当として、はっきり分けて運用しています。性能比較やランキングで優劣をつけたわけではなく、「どちらが何に向いているか」という単純な話でもありません。限られた使用枠をどこに割り当てるかという、運用上の判断です。
本記事の結論を先に書いておくと、こうなります。
- Claude Codeは記事作成＋αに専念させる
- Codexはツール・アプリ・スクリプトなど、記事を支える裏側の仕組みを担当させる
- 記事そのものに直接入る制作物はClaude Code、複数記事で使い回す仕組みはCodex
この線引きに至った理由を、以下で順に整理していきます。
MMDでのClaude Code（ちょこ）の担当範囲
Claude CodeはMMD内で「ちょこ」と呼んでいて、編集部・記事制作担当という位置づけです。名前の由来は、アークザラッドのキャラクター名からとっています。笑
担当範囲は、ざっくり「記事作成＋α」と表現しています。記事の完成形に直接入る制作物は、基本的にちょこに任せています。
構成・本文・HTML出力までを一気通貫で
具体的には、以下のような作業がちょこの担当です。
- 企画書と1次情報をもとにした構成案の作成
- 本文の執筆
- WordPress貼り付け用HTMLの出力
- Cocoon用の表や装飾（その記事専用のもの）
- meta description、X投稿文、アイキャッチ指示
- 記事のリライト
企画書を渡したら、構成→本文→HTML出力までを一気通貫で進められるのが大きな利点です。以前はChatGPTで企画整理、Claude Chatで本文、ChatGPTでチェック、と複数のAIをまたいでいたので、AI間の橋渡しに時間がかかっていました。Claude Code導入後は、その橋渡しが要らなくなりました。
MMD文体への寄せとセルフチェック
もうひとつ大きいのが、MMD文体への寄せです。MMDには文体ガイド・HTML出力フォーマット・SEOガイドラインなど、共通ルールがいくつも整備されています。Claude Codeはこれらを参照しながら制作するので、毎回手で指示を出さなくても、おおむねMMDの文体に乗ってきます。
セルフチェックも担当です。構成が出来た段階のチェックと、本文が出来た段階のチェックを、それぞれ別の観点書に沿って自分で実施します。最終判断はTKDが行うので「ちょこのセルフチェックを通った＝公開してよい」ではないですが、TKDが見る前段でひととおり整っている状態になるので、編集の負荷がかなり下がります。
これらの記事制作フローの詳細は、シリーズ4本目で扱っています。
MMDでのCodex（コデス）の担当範囲
Codexは「コデス」と呼んでいて、IT部門・開発担当という位置づけです。担当範囲は、ツール・アプリ・スクリプトなど、記事を支える裏側の仕組みです。
ツール・スクリプト・自動化を任せる
具体的には、以下のような作業がコデスの担当です。
- momen tools系のWebツール開発
- F1カレンダーJSONの生成・変換ツール
- 記事一覧CSVから内部リンク候補を抽出するツール
- WordPress投稿補助スクリプト
- X自動投稿まわり
- handoff.mdの整形補助
- 月次分析用のCSV処理
- テスト追加・バグ調査・リファクタリング
記事本文を書かせることはありません。MMDの文体に強く依存する文章作成や、WordPress貼り付け用HTMLの本制作も、コデスには任せていません。代わりに、記事制作や運営を支える「道具を作る」役割に徹してもらっています。
汎用化するCocoonパーツやチェックツール
少し境界が紛らわしいのが、Cocoon用のパーツやチェックツールです。
たとえば、ある記事の中で1回だけ使う比較表やボックス装飾は、ちょこの担当です。記事の文脈と一体になっていて、その記事専用の制作物だからです。一方で、複数の記事で使い回す前提の汎用Cocoonパーツや、Cocoon用HTMLの構造をチェックするツール、プラグイン化などは、コデスの担当になります。記事から切り離して、独立した道具として作るからです。
同じ「Cocoon用HTMLを作る」という作業でも、その制作物が記事の中に閉じるか、複数記事で使い回す仕組みになるかで、担当が変わるイメージです。
これらの開発フローの詳細は、シリーズ5本目で扱っています。
分けた決定打は「Claude Codeの5時間枠」
ここまで読むと、「役割分担の話なのは分かったが、なぜわざわざ分ける必要があるのか」と思われるかもしれません。Claude Codeでもツール開発はできるし、Codexでも文章はある程度書けます。性能だけ見れば、どちらも一定の汎用性があります。
それでもMMDで明確に分けることにした決定打は、Claude Codeの使用上限、特に5時間枠の存在でした。
性能比較ではなく、使用上限の割り当て
Claude Codeには、一定時間ごとにリセットされる使用枠があります。プランや時期によって細かい仕様は変わりますが、「無制限に使えるわけではない」という点が運用上の前提になります。記事制作と開発をどちらもClaude Codeに寄せると、この枠を両方で取り合うことになります。
このとき、例えば性能比較や自分との相性で「Claude Codeのほうが優れているからこちらに寄せる」と考えると判断を間違えます。実際には、性能の優劣ではなく、限られた使用量をどこに割り当てるかという運用上の問題に変わるからです。
MMDで一番優先度が高いのは、ブログ記事の制作です。だとすると、Claude Codeの枠は記事制作のために残しておくのが筋になります。Claudeの文章作成能力は私の記事には必須で、他のツールで代替するメリットが薄いため、ここをツール作成のトライ&エラーで使用量を消費してしまっては本末転倒です。
開発まで寄せると記事制作の余力が削られる
Codexを導入する前は、ちょっとしたスクリプトもClaude Codeに頼んでいました。CSVを整形したい、JSONを変換したい、軽いPythonを書きたい、という用途です。ひとつひとつは大した作業ではありませんが、積み上がると枠を確実に削っていきます。
また、ツール作成は一度のコーディングでは終わりません。実機確認をして、動かなければ解析・修正、動いたとしてもユーザビリティの微調整など、トライ&エラーが必ず必要で、かなりのトークンを消費します。
結果として、肝心の記事を書こうとした時間帯に、Claude Codeの枠がすでに開発作業で削られている、ということが起きました。記事制作の途中で枠を待つのは精神的にもよろしくないので、開発・自動化・雑多なスクリプト作業はCodexに逃がす、という運用に切り替えました。
これは「Claude CodeよりCodexのほうがツール開発に向いている」という性能の話ではありません。好みはあるかもしれませんが、双方とも優秀なコーディングツールです。ただ、記事作成はClaude Codeのほうが私の好みに合うので、Claude Codeの枠を記事制作のために空けておく、という運用上の割り当て判断です。Codex側の使用枠運用については、シリーズ3本目（AIツールスタック紹介）で別途扱っています。
「記事そのものか、記事を支える仕組みか」で分ける
使用上限という運用上の理由で分けると決めたあと、次に考えたのが「個別の作業をどちらに振るか」です。最初は迷うことも多かったのですが、最終的にはひとつの軸に整理できました。
その軸はシンプルで、「記事そのものに直接入る制作物か、それとも記事を支える裏側の仕組みか」です。前者ならちょこ、後者ならコデス、という分け方になります。
担当判断早見表
具体的な作業を、この軸で振り分けたのが以下の表です。
| 作業 | 担当 | 判断理由 |
|---|---|---|
| 企画書から記事本文を作る | ちょこ | 記事の完成形そのもの |
| WordPress貼り付け用HTMLの出力 | ちょこ | 記事の最終形に直接入る |
| その記事専用のCocoon装飾・表 | ちょこ寄り | 記事の文脈と一体化 |
| meta description、X投稿文、アイキャッチ指示 | ちょこ | 記事に紐づく成果物 |
| 記事一覧CSVから内部リンク候補を抽出するツール | コデス | 複数記事で使い回す道具 |
| F1カレンダーJSONの生成・変換 | コデス | 記事の外に独立した仕組み |
| Cocoon用HTMLのチェックツール | コデス寄り | 横断的に使える道具 |
| WordPress投稿補助スクリプト | コデス | 運営フローを支える自動化 |
| 記事本文のリライト | ちょこ | 記事の最終形を直接書き換える |
| handoff.mdの整形ツール | コデス | 運用フローの裏方 |
表を眺めると、判断基準のクセが見えてきます。「制作物が完成記事の一部として残るか」「制作物が記事の外側で道具として残るか」のどちらに寄っているかで、ほぼ機械的に振り分けられます。
境界が曖昧な作業はどう判断するか
もちろん、すべての作業がきれいに振り分けられるわけではありません。最初は迷うものも多くありました。
カレンダー機能の作成なんかは、最初はF1カレンダーに特化していたのもあり、ブログの一部としてちょこに任せていましたが、今では横断的な機能としてコデスに任せるようになっています。また、特定のシリーズに使う構成テンプレは、環境整備として最初はコデスに任せようと思いましたが、記事の一部ということで今ではちょこの仕事となっています。
「次の記事でも使い回すか」を基準にする
そういう曖昧なケースでは、「この制作物は次の記事でも使い回すか」を判断基準にするようにしています。
使い捨てで終わるならちょこ、汎用化して何度も呼び出すならコデス、という線引きです。たとえば、ある記事の比較表をその場で作るだけならちょこに頼む。同じパターンの比較表をシリーズで何度も使うことが見えてきたら、汎用Cocoonパーツとしてコデスに作り直してもらう、という流れになります。
「最初はちょこに作ってもらって、後でコデスに引き継ぐ」というパターンも普通にあります。最初から汎用化を狙うとオーバーエンジニアリングになりがちなので、まずは記事と一緒に手早く作って、必要になった段階で道具側に移すほうが、結果的に運用は軽くなります。
判断に迷ったら、もうひとつ補助的に使っている軸が「使用枠を消費すべき作業か」です。記事に直接効く作業なら、Claude Codeの枠を使う価値があります。記事を支える裏方の自動化なら、Claude Codeの枠を使ってまでやる必要はありません。
とはいえ、記事執筆以外は、使用制限があるがどうしてもすぐに仕上げたい場合などは、互いに引き継がせていたりもします。副産物的ではありますが、手戻りなどをなくして安定させるためのhandoff.mdがそれも可能にしています。
役割分担で選ぶ、最強AIを探さない
Claude CodeとCodexの使い分けは、結局のところ「どちらが上か」という話ではありませんでした。性能や機能を比べてランキングをつけても、MMDの運営はあまり楽になりません。
大事なのは、限られた使用枠と、自分が一番優先したい仕事を結びつけて考えることです。MMDの場合は、その優先順位の頂点に「ブログ記事を書く」があり、そのためにClaude Codeの枠を空けておく、という前提が先に来ます。それ以外の開発・自動化・雑多な処理は、Codexに逃がしてClaude Codeの枠を守る、という設計になっています。
逃がしてというと、少し後ろ向きに気kぽえるかもしれませんが、決してそんなことはありません。どちらツール作成は優秀に進めてくれますが、個人的にはCodexのほうが進め方などが私の業務スタイルと合っている気がしていて、とてもやりやすいです。その点は、たまたまですが分けたことによるメリットにもなっています。
MMDのAIワークフローは、最強AIを探す方向ではなく、役割と作業領域に合わせてAIを使い分ける方向に進んでいます。「最強AI」と銘打つ世の中のコンテンツを否定する意図は全くないですが、AIを増やせば自動的に楽になるわけではなく、どのAIに何を任せ、どこを人間が判断するかを決めることのほうが、ずっと効くと個人的には思っています。この設計思想そのものはシリーズ2本目で詳しく扱っています。
もちろん、この分け方で運用していても課題はあります。Claude Codeの枠が記事制作中に切れることもあれば、コデスに任せた自動化が予想外に手間取ることもあります。実際に運用して見えた課題は、シリーズ7本目でまとめて扱う予定です。
非プログラマーの個人ブログ運営者という前提で言うと、AIエージェントは「最強の1台」を選ぶ買い物ではなく、「役割を分けたチーム」を組む発想で扱うほうが、現実的に楽になります。Claude CodeとCodexの使い分けは、その発想を運用に落とし込んだひとつの実例です。
ブログ運営AIワークフローVer2.1（MMD-WF2.1）紹介（全７回+1）
第1回：2026/5/12(Tue) 21:00公開
第2回：2026/5/19(Tue) 21:00公開
第3回：2026/5/26(Tue) 21:00公開
第4回：2026/6/2(Tue) 21:00公開
第5回：2026/6/9(Tue) 21:00公開
第6回：2026/6/16(Tue) 21:00公開
本記事
第7回：2026/6/23(Tue) 21:00公開
Plus One：2026/6/30(Tue) 21:00公開
コメント