AIワークフローの課題と対策｜複数AI運用で見えた現実的な落とし穴

AIワークフローを組めば、ブログ運営の作業も自動的に減るはず ── 数ヶ月前まで、わりと素朴にそう思っていました。実際にChatGPT・Perplexity・Claude Code・Codex・ComfyUIで役割を分けて運用してみると、記事制作の時間は確かに大きく縮みました。ただ、そのぶんAIワークフロー特有の課題が増えてきた、というのが正直な感覚です。

本記事は、MMDのAIワークフロー紹介シリーズの7本目です。1〜6本目で全体像・設計思想・使用ツール・記事制作フロー・ツール開発フロー・使い分け理由を扱ってきましたが、ここでは振り返り・課題編として、それらをすべて運用してみてはじめて見えた現実的な課題のほうに焦点を当てます。

完成形のワークフロー紹介ではなく、「AIを増やすと、どういう種類の負荷が新しく発生するのか」を実例ベースで残しておくのが本記事の役割です。AIをブログ運営に取り入れる前の判断材料として読んでもらえる内容を目指しています。

Contents

時間は確実に減った。でも「楽になった」かは別の話
最大のボトルネックはClaude Codeの5時間枠
AI出力の事実確認は、作業負荷を減らしても消えない
写真・アイキャッチとWordPress上の見た目確認は人間に残る
AIごとの「出力思想」は、放っておくと混ざる
ツールの仕様変更で、書いた企画書が一晩で古くなる
便利になるほど、管理対象は確実に増える
課題が見えてわかった、人間側の設計力と判断力
シリーズの他記事へ
ブログ運営AIワークフローVer2.1（MMD-WF2.1）紹介（全７回+1）

時間は確実に減った。でも「楽になった」かは別の話

誤解されないように先に書いておくと、AIを役割分担で運用するメリット自体は確実にあります。MMDの場合、刷新前のフローでは1記事を仕上げるのに早い記事でも2〜3時間、調査や構成が重い記事だと5〜6時間かかっていました。それが現行フローでは、軽めの記事なら30分前後、しっかり書く記事でも1.5時間くらいで形になる感覚があります。

これは数字としてはかなり大きな変化です。ただ、ここから先が今回の本題で、「短縮された時間」と引き換えに、別の種類の作業負荷が発生したのも事実です。具体的には、複数AIに渡すための入力整備、AI同士の役割整理、出力の事実確認、画像とWordPress上の最終確認、ツール仕様変更への追従などです。

AIを増やせばそのまま楽になる、という単純な話ではないことが、運用してはじめて分かりました。ここから先では、この「新しく増えた作業負荷」をテーマごとに整理していきます。

最大のボトルネックはClaude Codeの5時間枠

現行ワークフローで一番のストレス源を挙げるなら、迷わずClaude Codeの使用上限です。MMDではClaude Codeを「ちょこ」と呼んでいて、構成・本文・HTML出力までを一気通貫で任せる、記事制作の中核です。ただ、Claude Codeには5時間ごとの使用枠があり、長めの記事や複数記事をまとめて進めたいタイミングで、途中で残量を意識せざるを得ない場面が必ず出てきます。

「あと一気に2記事まで仕上げてしまいたい」というタイミングで、ちょこ側の枠が残り少なくなって作業を区切る、という判断はそれなりの頻度で発生します。現実的にはちょこの使用制限がかかってもチャッピーと企画書の作成や記事の仕上げは進められるので、現時点で致命的な障壁にはなっていませんが、記事制作は集中力が乗っているときに最後まで走り切れたほうが質も上がるので、ここで止めなければならないのは小さくないストレスです。

対策として、MMDではちょこに「記事制作とその周辺だけ」を担当させ、ツール開発・自動化・スクリプト系はCodex（コデス）にすべて振り分ける運用にしています。同じAIエージェント系を2系統に分けるのは一見冗長ですが、ちょこの使用枠を記事制作に集中させるための割り切りです。詳しい使い分けの理由はシリーズ6本目で扱っています。

Claude CodeとCodexの使い分け｜執筆と開発を分けた理由

Claude CodeとCodexの使い分けに迷う人向けに、MMDで記事制作と開発を分けて運用している理由を整理しました。性能比較ではなく、5時間枠を記事に集中させるための運用判断として説明します。

それでも、使用上限そのものが消えるわけではありません。「AIワークフロー運用は、使用枠というハードな制約と一緒に組み立てる必要がある」というのが、運用してはじめて骨身に染みた点でした。プラン仕様自体は今後変わる可能性もありますが、なんらかの上限と付き合う前提でフローを組む、という考え方は当面変わらないと思っています。

AI出力の事実確認は、作業負荷を減らしても消えない

2つ目に大きい課題は、AIが出した内容の事実確認が、運用で工夫しても減りきらないことです。MMDでは外部情報の一次収集をPerplexity（パープレ）に任せ、整理をChatGPT、本文化をちょこ、というふうに役割を分けていますが、それでも数字・日付・料金・公式発表・固有名詞などはAIの出力をそのまま記事化していません。

体感としては、AIが流暢にまとめてくれる文章ほど、「もっともらしさ」と「正確さ」がイコールではないことを忘れがちになります。特に、過去のレース日程や制度変更、料金プランのような変動するデータは、AIだけで確定させずに公式情報を直接見る、という運用にしています。

事実確認は、現状こういう形でフローに組み込んでいます。

パープレの出力はChatGPT側でいったん整理し、出典の有無を都度確認する
ちょこが本文に取り込んだ数値・日付・固有名詞は、TKDが公開前に1件ずつ目で見直す
仕様や料金は、公式サイト・公式SNS・公式PDFのいずれかで裏取りしてから書く

結果として、事実確認は工程としては残りますが、AIに任せられる範囲とTKDが必ず見る範囲を明確に分けたことで、「どこを疑えばいいか」がはっきりしただけでも体感負荷はかなり下がりました。最終判断がTKDに残るというのは、AIワークフロー全体の前提でもあります。

写真・アイキャッチとWordPress上の見た目確認は人間に残る

文章はAIで一気通貫になっても、ビジュアル系と最終UI確認は今もTKDの仕事のままです。具体的には、撮影写真の選別、アイキャッチの選定、WordPressに貼り付けたあとの実画面チェックといった工程です。

撮影写真は、その記事で何を伝えたいかを踏まえて選ぶ作業なので、AIに丸ごと任せるのは現実的ではありません。「この記事ならこのカット」という判断は、現場で何を撮ったか、どういう体験だったかを覚えている人間にしか付けられない部分が多いと感じています。

写真で賄えないアイキャッチは、ローカル運用しているComfyUI（こんこん）に頼ることがあります。ただ、ここはまだ課題が多い領域です。生成画像の品質、公式キャラを使う場合の一貫性、生成条件の管理など、文章ほど運用が固まっていません。アイキャッチ1枚のために再生成を繰り返して時間を溶かす、ということが今も普通に起きます。ComfyUIまわりの詳細は、別記事として切り出す予定です。

そして、最後に必ずやるのがWordPress上での見た目チェックです。ちょこが出力するHTMLはCocoonテーマでの貼り付けを前提にしていますが、ブロック区切り・表のレイアウト・ブログカードの展開・スマホ表示など、最終的な見え方は実画面でしか確認できません。プレビューを開いて指で触ってみる、という工程は、いまのところ自動化できる気がしていない部分です。

AIごとの「出力思想」は、放っておくと混ざる

複数AIで運用していて、地味に効いてくるのが、AIごとの出力傾向の差です。同じ「AIエージェント」と呼ばれるClaude CodeとCodexでも、書き出してくる文体・構造・粒度はけっこう違います。ChatGPTとClaudeで返答の「キャラ」が違うのは知られていますが、これはAIエージェント側でも同じことが起きます。

たとえば、ちょこに小さなスクリプトを書かせると、記事文体寄りの説明コメントを丁寧に入れてくれる代わりに、開発面の合理性ではコデスに劣る印象です。逆に、コデスにブログ記事のドラフトを書かせると、構造はきれいに揃うものの、文体としては固くなりがちです。それぞれが得意領域でいる限りは強いのですが、領域を踏み越えさせると、出力の毛色がそろわなくなります。

これらが混ざると、最終アウトプットに「微妙な違和感」が残ります。読者から見ると一貫性のない文章に映りやすく、結果としてAIっぽさが目立ちます。MMDではこれを避けるため、「記事に直接入る制作物はちょこ、汎用的に使い回す仕組みはコデス、画像はこんこん」という線引きを明示し、必要ならhandoff.mdで受け渡しの前提を文章化するルールにしています。

ツールが増えるほど、この役割固定の徹底度合いが品質に効いてきます。「どのAIにも、得意分野以外を頼まない」というシンプルな決めごとですが、慣れないうちは「便利だからつい別のAIにも振りたくなる」ので、運用ルールとして明文化しておく価値はあります。

ツールの仕様変更で、書いた企画書が一晩で古くなる

AIワークフロー系の記事を書こうとすると、必ずぶつかるのが「公開する頃には書いた内容が古くなっている」リスクです。MMDでもこのシリーズの最初の構想では、扱うAIは4つ程度で、ChatGPT・Perplexity・Claude Codeあたりを軸にしていました。

ところが、シリーズの構成を詰めている最中にCodex・ComfyUIの導入を決め、さらにComfyUIをローカルで本格運用しはじめたタイミングで、当初の企画書では足りない要素が一気に増えました。「何を書く記事か」自体は変わりませんが、扱う登場人物が増えるだけで、目次も、内部リンク導線も、各記事の射程も組み直す必要が出てきました。

この種の前提変動は、AIツールを使っている限り今後も繰り返し起きる可能性が高いです。新しいモデルが出る、料金プランが変わる、機能が増える、使用上限が変わる ── どれもワークフロー記事にとっては「企画書が古くなる」要因になります。

対策として、MMDでは以下を運用しています。

各記事の冒頭または本文中に「公開時点のMMD運用」と明記し、後日変動する前提を読者と共有する
シリーズの親企画書を別ファイルで持ち、構成・登場人物・重複回避ルールを更新できるようにしておく
ハブ的な役割を持つ記事（全体像・ツールスタック・使い分け）を、優先的にリライト対象にする

「書いた瞬間から古くなりはじめるテーマを、どう公開し続けるか」という問題への回答は、まだMMDの中でも進行中です。少なくとも、書いた当時の運用を残しておくこと自体には、後から振り返ったときに価値が出ると考えてあえて出しています。

便利になるほど、管理対象は確実に増える

ここまでに挙げた課題と対策は、それぞれ単体で見ればもっともらしい運用ルールに見えるはずです。ただ、これら全部を抱え込むということは、それだけ「管理しなければならない対象」が増えている、ということでもあります。

MMDで現時点で常時メンテナンスしているものを並べると、こうなります。

媒体ごとの記事企画書フォーマット
担当AIごとの参照ルール（文体ガイド・HTML出力フォーマット・SEOガイドラインなど）
記事一覧CSV・タグCSV
handoffテンプレートと、案件ごとのhandoff.md
AI役割表（誰に何を任せ、何を任せないか）
ComfyUIのworkflowと生成条件メモ

これらは、AIを使い分けるためのコストとして必要なものです。一方で、AIを1つだけにしていた頃にはそもそも存在しなかったタスクでもあります。「AIで楽になる」と「ブログ運営として楽になる」は、必ずしも同義ではないということです。

シリーズで一番伝えたかった論点も、ここにあります。AI活用の話題は時短や効率化の文脈で語られがちですが、運用設計まで含めて見たときには、人間が「整える側」に回る作業が確実に増えます。便利になった工程と、新しく発生した工程の両方を見たうえで、自分の運営に組み込むかを判断するのが現実的です。

課題が見えてわかった、人間側の設計力と判断力

振り返ってみると、ここまで挙げた課題はどれも、AI側の性能では解決しきれない種類のものでした。使用上限はサービス側のプランの話、事実確認は情報源の話、写真・WP確認は最終UIの話、AIごとの出力思想は役割設計の話、仕様変更追従と管理コストはワークフロー設計の話です。

共通しているのは、「人間側がどう設計し、どこで判断するか」を決めないと、AIをいくら増やしても根本的には楽にならない、という構図です。

逆に言えば、これらに自覚的なほど、AIワークフローは「個人ブログ運営者でも回せる仕組み」として成立しやすくなります。MMDの筆者は、本業で自動車開発のPMをしていることもあって、目的・要件・判断材料を整理して人や仕組みに渡す、という作業自体には慣れていました。AIに対しても同じやり方を持ち込めばだいたい動く、というのが、ここまで運用してみての実感です。

本シリーズの結論はかなりシンプルです。AIは判断と体験を支える補助役であって、人間の代替ではない。AIを増やすほど、人間側の設計力と判断力が問われる、ということです。それを引き受けたうえで取り入れれば、個人ブログ運営はかなり楽になります。引き受けないままAIを増やすと、便利になったはずなのに作業が減らない、という違和感だけが残るはずです。