AIワークフローでブログ運営を回していると、いつのまにか「あと何時間でClaude Codeの枠が切れるか」を気にしながら原稿を進めている、ということが普通になってきます。一気に書き上げたい記事ほど枠の残量がプレッシャーになりやすく、MMDでもこの「使用量を気にしながら作業する感覚」はずっと残り続けていました。
本記事は、AIワークフロー紹介シリーズの最終記事として書いた「AIワークフローの課題と対策」の後日譚です。あの記事で「最大のボトルネックはClaude Codeの5時間枠」と書きましたが、そこから運用設定を見直したことで、使用量の悩みがかなり軽くなりました。シリーズ正式8本目というよりは、challengesに対するアンサーの一つ・WF2.1内の運用改善メモという位置づけになります。
ちょこ＝記事制作、コデス＝開発に分けても、使用量の不安は残っていた
MMDでは、Claude Codeを「ちょこ」、Codexを「コデス」と呼んで、ちょこに記事制作、コデスにツール・スクリプト・アプリ開発を割り当てています。同じAIエージェント系を2系統に分けるのは一見冗長ですが、ちょこの使用枠を記事制作に温存するための割り切りです。なぜこの分け方にしたかの詳細は、シリーズ6本目で別途扱っています。
この分担で、ちょこ側の使用量はある程度温存できるようになりました。記事1本ごとの作業スループットも上がり、軽い記事なら30分前後で形になる感覚があります。
ただ、これだけだとシリーズもの・リライト・複数記事をまとめて進めたい場面で、結局ちょこ側の枠が頭打ちになる場面が残りました。「分けたから安心」というほど余裕は生まれていない、というのが正直なところでした。
シリーズ最終記事で挙げた「Claude Codeの5時間枠」のその後
シリーズ最終記事のchallengesでも書いたとおり、現行ワークフローで一番のストレス源を挙げるなら、迷わずClaude Codeの5時間枠です。「あと一本仕上げてしまいたい」というタイミングで枠の残量を意識する、というのは小さくない負担でした。
challengesでは、対策としてちょこに「記事制作とその周辺だけ」を担当させ、開発・自動化系はコデスへ全部振る、という方針を紹介しました。これはこれで効きましたが、運用ルールとしての分担に留まっていて、AIそのものの動かし方には踏み込んでいませんでした。
そこで、その次の打ち手として、ちょことコデスそれぞれの「モデルとインテリジェンス設定」の使い方を見直しました。これが、本記事の主題です。
答えは「AIを増やす」より「設定の強弱を変える」ことだった
最初に検討したのは、ちょこの上位プランへの切り替えや、Claude Code以外のAIをもう一つ増やす方向でした。ただ、これらは「使える枠を増やす」発想で、課題の本質には届きません。MMDのワークフローでは、ちょこに任せたい仕事はかなりはっきりしていて、増設で枠を広げるよりも、いまの枠で何にどれだけ使うかを設計し直したほうが筋がよさそうでした。
きっかけは、ちょこの中にもOpus・Sonnet・Haikuという複数の世代があり、さらにそれぞれにインテリジェンス設定（思考の強さ）が用意されている、というシンプルな事実を改めて意識したことです。コデス側も、GPT5.5・GPT5.3 Codex・GPT5.4・GPT5.4 Miniといった役割の異なるモデルが揃っていて、強度設定も選べるようになっています。
ところが運用としては、重い記事も軽い整形も、設計判断も雑務も、ほぼ全部を高めの設定で回していました。これでは、いくら枠があっても足りないのは当然です。「使用量を軽くする」イコール「AIを我慢する」だと思い込んでいたのを、「作業ごとに強さを変える」に置き換えた、というのが今回の発想転換でした。
Ckaude Codeのモデル設定。作業の重さでモデルと強度を切り替える。
重い作業に強い設定、軽い作業に軽い設定という基準
強弱の付け方を考えるとき、MMDでは2つの基本思想を軸にしています。
ちょこ側は、「Opusで考え、Opusで書き、Sonnet／Haikuで整える」。記事の構成や本文制作のような、文脈理解と判断が重い作業はOpus4.7に任せ、HTML整形やCocoon装飾のような形を整える作業はSonnet4.6、誤字脱字や表記ゆれの確認はHaiku4.5に降ろします。
コデス側は、「高性能モデルに考えさせ、コード特化モデルに実装させる」。要求整理・仕様化・設計判断はGPT5.5、不具合調査と実装はコード特化のGPT5.3 Codex、ログ整理やREADME更新のような雑務はGPT5.4 Miniに任せます。
両者で言葉は違いますが、共通しているのは「考えるところ」と「整える／動かすところ」を切り分ける、というシンプルな発想です。全部を最高設定で回すと、消費が重いだけでなく、単純作業に高級な脳を使うことになるのでコスパも悪い。一方で、すべてを軽量設定に落としてしまうと、ちょこ側では文脈理解が弱まって体験の温度感が削れますし、コデス側では目的ズレや過剰実装が起きやすくなります。
「重いところを強く、軽いところを軽く」というのは、聞けば当たり前ですが、実際にこれをワークフローに落としてみると、使用量の使い方が大きく変わります。
ちょことコデスの実際のモデル・インテリジェンス設定
MMDで現在運用している使い分けを、ちょこ側とコデス側それぞれで表に整理します。料金プラン・モデル構成・使用上限の仕様はサービス側で頻繁に更新されるので、あくまで公開時点（2026年）のMMDの運用としてご覧ください。
ちょこ（Claude Code）側の使い分け
| 用途 | 推奨設定 |
|---|---|
| 通常の記事構成・本文制作・現地レポ | Opus4.7 × 高 |
| AI活用・ワークフロー系・思想系記事 | Opus4.7 × 超高 |
| ガイド・比較レビュー・ハブ・収益軸・長期資産記事 | Opus4.7 × Max |
| HTML整形・表調整・Cocoon装飾 | Sonnet4.6 × 中〜高 |
| 誤字脱字・表記ゆれの確認 | Haiku4.5 |
| Opus4.7が使いにくい場合の避難先 | Opus4.6 |
コデス（Codex）側の使い分け
| 用途 | 推奨設定 |
|---|---|
| 要求整理・仕様化・設計判断・レビュー | GPT5.5 × 高 |
| 通常実装・単一ファイル修正・テスト追加 | GPT5.3 Codex × 中 |
| 不具合調査・複数ファイル調査・原因特定 | GPT5.3 Codex × 高 |
| コード探索をもう一段深めたい時の短時間利用 | GPT5.3 Codex × 非常に高い |
| 何度も詰まる・設計起因が疑われる難所 | GPT5.5 × 非常に高い |
| ログ整理・README更新・CSV変換などの雑務 | GPT5.4 Mini × 低〜中 |
| 中規模レビュー（GPT5.5節約用の中間枠） | GPT5.4 × 高 |
ポイントは、どちらも「常用帯は中庸」「最高設定は判断と難所のみ」という配分にしていることです。ちょこならOpus4.7×高〜超高が標準、コデスならGPT5.3 Codex×中〜高が標準。MaxやGPT5.5×非常に高いは、長期資産記事や本当に詰まった難所のための最終兵器として残してあります。
ちなみに本記事は、ガイド上は「AI活用・ワークフロー系・思想整理」に該当するので、ちょこ的にはOpus4.7×超高あたりで書いています。書きながら自分のワークフローを自己言及するのは少し変な気分ですが、判断軸の決め方そのものが、設定にもそのまま反映されている、ということでもあります。
設定を見直してから変わったこと
設定の使い分けを意識しはじめてから、運用面で変わったことがいくつかあります。
一つ目は、シンプルに使用量の余裕が出たことです。ちょこ側でOpusを温存してSonnetに整形を任せるだけでも体感はかなり違いますし、コデス側でも雑務をGPT5.4 Miniに降ろすことで、GPT5.5の出番を「上流判断と本当に詰まったとき」に絞れるようになりました。5時間枠を意識する頻度が、明らかに下がりました。
二つ目は、作業中に「いまどのフェーズか」を意識する習慣がついたことです。記事制作なら、構成・本文ならOpus×超高、HTML化・装飾ならSonnet×中、最終チェックならHaikuと、フェーズごとに切り替える前提でフローが回るようになりました。コデス側も、要求整理にだけGPT5.5を呼んで、実装に入ったらGPT5.3 Codexに任せる、という切り替えが自然になりました。
三つ目は、ちょこを記事制作に専念させやすくなったことです。雑務や軽い整形に高い設定を使わずに済むようになった結果、本当に集中したい記事制作の場面でOpus4.7を遠慮なく使えるようになりました。これは数字には現れにくい変化ですが、運用心理としては大きい違いです。
結果として、WF2.1のワークフロー自体は変えていないのに、運用としては相当落ち着いてきた、というのが率直な感触です。
使用量節約のためだけに設定を下げない、という線引き
ここで誤解されたくないのは、本記事は「使用量を節約するために設定を下げよう」という話ではない、という点です。むしろMMDでは「節約のためだけに重要な作業を軽量モデルに落とさない」を運用ルールとしてはっきり持っています。
ちょこ側だと、本文制作・構成判断・公開前の重要レビューはOpus4.7（場合によってはMax帯）から動かしません。記事の中核を軽量モデルに任せると、文脈理解が弱まったり、AIっぽい一般論に寄ったり、体験の温度感が削れたりして、結局リライトの工数が増えます。
コデス側でも、要求整理・仕様化・設計判断はGPT5.5を使い続けます。実装が早いからといって、いきなりGPT5.3 Codexに要求定義から全部投げると、目的ズレや過剰実装が起きやすいことが、運用上はっきり見えてきました。
つまり、設定の見直しは「節約」と「品質維持」のどちらか一方を選ぶ話ではなく、線をどこに引くかという話です。重い作業には強い設定を残し、軽い作業だけ軽い設定に振り分ける。この線をTKD側で握っていれば、使用量が軽くなっても記事や開発の品質は守れる、というのがMMDで実感している結論です。
なお、料金プラン・モデル構成・使用上限の仕様は、サービス側で頻繁に更新されます。本記事の設定は公開時点のものなので、実際に運用に取り入れる場合は、公式のプラン仕様と現行モデル構成を必ず確認してください。
AIエージェント運用は「何を使うか」より「どの強さで使うか」
ここまでの話を一行でまとめると、「何を使うか」だけでなく「どの強さで使うか」を決めると、AIエージェントの継続運用がかなり楽になる、ということです。
最初は「Claude vs Codex」「ちょこ vs コデス」というAI同士の分担に意識が向いていました。これはこれで必要なステップでしたが、それだけでは現行プランの使用量と折り合いがつかない場面が残りました。次の一歩として「どの作業にどのモデル・どの強度で当たるか」まで踏み込んで、ようやくWF2.1の運用がいまの形に落ち着いた感覚があります。
おもしろいのは、ここまでの改善でWF3.0への大幅刷新を一切していない、ということです。AIの構成も、役割分担も、入力資料の形式も、challenges時点のWF2.1のままです。それでも、設定の強弱を変えるだけで運用はここまで楽になりました。AIワークフローのアップデートは、必ずしも構造の刷新ではなく、運用の解像度を上げる方向でも進められる、という発見でもありました。
最後に、これだけ書いておくとAIに丸投げできる印象を与えるかもしれませんが、設定の最終判断はAIではなくTKDがしています。記事の事業価値でMaxを使うかどうかを決めるのも、要求整理にGPT5.5を呼ぶかどうかを決めるのも、最終的には人間の判断です。AIは、判断と体験を支える補助役のままです。
本記事はAIワークフロー紹介シリーズの後日譚として書いた一本ですが、シリーズ全体の流れや個別ワークフローは、それぞれ別記事で扱っています。あわせて読んでもらえれば、運用改善の前提が分かりやすいと思います。
ブログ運営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公開
本記事
コメント