AIを増やせばブログ運営が楽になるはず、と思っていた時期があります。MMDで実際にAIワークフロー設計をやり直してみると、楽になるかどうかは「どのAIを使うか」よりも「役割をどう先に決めるか」で決まる、というのが見えてきました。
本記事は、MMDのAIワークフロー紹介シリーズの2本目です。1本目では現行AIワークフローの全体像を紹介しました。本記事は、そのフローの裏にある設計思想を扱います。
全体像を知りたい方はまずこちらの記事を確認してみてください。
MMD運営体制イメージ図。人間を中心にAIが支える構造。
AIを増やしても、運用は自動的に楽にならなかった
最初に試したのは、便利そうなAIを思いついた順に使い分けるやり方でした。企画はChatGPT、本文はClaudeのチャット版、最後にChatGPTでもう一度チェック、調査はPerplexity、コードを書きたくなったらまたChatGPTかClaudeに戻る——そんな具合に、AIごとに窓を開けて、必要なときに切り替える前提で動いていました。
結果として、便利になった部分はたしかにあります。ただ、運用そのものはむしろ重くなりました。
一番大変だったのは、役割を細分化しすぎて、AIやプロジェクト間の行き来を自分で何度もさせなくてはならないことでした。また、自分の体験などの1次情報の反映も、AIが作成したたたき台に自分で織り込んでいったので、AIを使っているといえどとても時間がかかっていました。軽い記事でも2～3時間、重たい記事では合計6～7時間かかることもざらでした。おそらく、最大の原因はすべてチャットベースでやっていただと思います。
振り返ってみると、AIを増やすこと自体に問題があったのではなく、「AIをツールとして考え、作業をさせるために数を増やしていた」のが問題でした。会社で言えば、すべての部門の職位（部長・課長・係長・主任）をTKDが一人でやっている状態です。作業はAIにさせているものの、その中継役はすべてTKDだったため、AIやプロジェクトが増えるほどチャット内容の橋渡し回数・判断回数も増え、結果としてTKDの負担が膨らんでいたわけです。
“作業”に対して「優秀なAIを足す」のではなく、”業務”に対して「任せるAIを決める」という考えに舵を切ったのが、いまのMMDのAIワークフロー設計のスタートでした。
MMDのAIワークフロー設計、3つの基本思想
役割を決め直すにあたって、土台に置いた基本思想が3つあります。これはツール選定よりも前に固定する部分で、ここがブレるとその後の役割分担も成立しません。
MMD運営基本方針。これを徹底することで、低コストで品質維持を目指す
AIは判断の代行者ではなく補助役
1つ目は、AIに「判断」を肩代わりさせない、という線引きです。
AIは草稿づくりや整理、提案にはとても強い反面、「最終的にどれを採用するか」という判断にはどうしても文脈が足りません。MMDでは、AIに任せるのは選択肢の整理と草稿のところまで、と決めています。記事の方向性、構成の最終形、公開可否といった「判断」は、AIに丸投げできない領域として人間側に残し、AIには「提案」をさせるようにしています。
この線を引いたことで、AIの提案に対して「採用するか、しないか」を毎回はっきり決められるようになりました。AIを補助役として置くと、出力の良し悪しを最終的に評価する人間の役割もはっきりします。
最終判断はTKDが握る
2つ目は、最終判断は必ずTKD側に残す、という運用ルールです。
具体的には、記事の公開可否、シリーズ全体の方向性、新しいAIを業務に入れるかどうか、課金プランの変更、こうした「あとから戻しにくい判断」はすべて自分の手元で決めると決めています。AIに「これで公開して大丈夫か」と聞いて、その回答だけで決めることはしません。
AIにもっともらしく言い切られると、つい判断を任せたくなりますが、判断を任せた瞬間に運用の責任もぼやけます。最終判断を自分のところに固定しておくと、AIにどこまで任せて、どこから自分でやるかの境界線が安定します。
実体験・1次情報・信頼できる情報源を重視する
3つ目は、「重要な事実はAI出力だけで確定させない」という決まりです。
AIの出力には、それらしく見えて事実と違う情報が混じります。MMDの記事は実体験ベースの長期資産型コンテンツが中心なので、ここで誤情報を混ぜると、あとから自分の首を絞めることになります。
そのため、記事内で扱う重要な事実は、TKD自身の体験、現地で撮った写真、メーカーや主催者の公式情報、信頼できる一次情報源で裏取りしてから書く、という運用にしています。AIには整理と表現の補助を任せ、事実の確定は人間側で責任を持つ、という形です。
担当業務でAIを分ける、作業単位では考えない
3つの思想を土台に、次に決めたのが「担当業務でAIを分ける、作業単位では考えない」という運用方針です。
5つの役割と担当AI
MMDのワークフローでは、AIに任せる仕事を大きく5つの役割に分けて、それぞれの役割に「担当AI」を一人ずつ固定で割り当てています。
- 企画・壁打ち・整理（チャッピー / ChatGPT）：記事企画の壁打ち、構成案の検討、情報の整理など、編集長補佐的な動き方をする領域
- 調査（パープレ / Perplexity）：参考情報の検索と一次情報源の特定。事実の裏取りはTKDが行う前提で、調査の入り口を担う
- 記事制作（ちょこ / Claude Code）：構成案からHTML出力までの一気通貫フローを担う、記事制作の編集部
- 開発・自動化（コデス / Codex）：ツール・スクリプト・自動化処理など、ブログ本文には直接入らない開発系の仕事
- 画像・素材制作（こんこん / ComfyUI）：画像生成や公式キャラの素材制作などCreative系の領域
「チャッピー」「パープレ」「ちょこ」「コデス」「こんこん」というのはMMD内部での呼び名です。AI本体はそれぞれChatGPT、Perplexity、Claude Code、Codex、ComfyUIですが、役割を担う「担当者」として呼び分けています。
MMDメンバー構成と役割。得意分野をもとに主担当を決めている
作業より業務を任せるメリット
作業ではなく業務ブロックとして内容を整理し、そこに担当AIを割り当てる構造にしておくと、運用の安定性が変わります。
まず、ツールが入れ替わっても運用が崩れません。役割が「記事制作」「開発」「素材制作」のように業務軸で定義されていれば、担当AIをいつか別のサービスに差し替えることになっても、ワークフロー全体の構造は維持できます。AIサービスは仕様や料金が変わるものなので、特定ツールに依存しきった設計はそもそも長持ちしません。
もうひとつは、判断軸がブレなくなったことです。「これはちょこの仕事か、コデスの仕事か」と迷ったときに、ツールのスペックを比較するのではなく、「これは記事に直接入るものか、それとも開発寄りの作業か」で振り分けられます。担当業務が明確だと、どのAIに渡すかで毎回悩む時間がほとんどなくなりました。
実際にどのくらい変わったのか、具体的な例を一部紹介します。まず、ツールの切り替えが圧倒的に減りました。企画書から記事を書く・リライトするなど記事関連時はちょこ、ツールやアプリ作成時はコデス、それ以外はチャッピーと、やることに対して基本1ツールで事足りるので、ツールの切り替えは作業の切り替えになるためです。結果として、橋渡しをする回数もほぼなくなり、記事執筆時間は旧フローより大体1/3程度になっています。
非プログラマーでも、PM的に要件を整理すれば回せる
ここまで読みながら「自分にできるのか」と不安になる方もいるかもしれませんが、TKD自身は本職のプログラマーではありません。
本業は自動車開発のPMで、エンジニアリングの基礎知識はあるものの、日常的にコードをゴリゴリ書く職種ではないという立場です。（「非プログラマー」は、コードが触れたことがないという意味ではなく、コーディングやコードそのもの日常業務として扱う立場ではないという意味で使っています。）
その立場からAIワークフローを組んでみて感じたのは、「PM的に要件を整理する力」がそのままAIワークフローの設計力になる、ということでした。
AIに何かを任せるとき、結局やっているのは「目的は何か」「ゴールはどの状態か」「どんなインプットを渡すか」「どこを判断ポイントにするか」を切り出してAIに渡す、という作業です。これは新しい開発案件をエンジニアに依頼するときの段取りとほぼ同じで、エンジニアの席にAIが座っているだけ、という感覚に近いものでした。
つまり、非プログラマーでも、PM的に目的・要件・判断材料を整理する習慣があれば、AIで記事制作や運営支援を進めることはできます。技術力で殴る必要はなく、要件を切り出す力で十分に成立します。
チャットベースでのAI利用でもそうですし、Claude CodeやCodexといったいわゆるAIエージェントの利用をする場合はよりいっそう実感できると思います。
AIの性能ではなく、インプットの安定が効いた
運用が落ち着いてきてから一番効いていると実感したのは、AI本体の性能ではなく、「AIに渡すインプットを安定させたこと」でした。
MMDではブログ運営に関するルールやフォーマットを .md ファイルで整備していて、企画書フォーマット、文章スタイル、HTML出力フォーマット、セルフチェック観点、カテゴリ・タグ運用などを文書化してあります。これを参照させながらAIに作業を依頼するスタイルです。
このフォーマット整備は、もともとちょこ向けやコデスといういわゆるAIエージェント向けに整えたものでした。ところが運用してみると、ちょこたちだけでなくチャッピーなどチャット型のAIにも同じフォーマットが効きました。同じ目的・同じ前提・同じ参照ルールを渡しさえすれば、AIが違っても出力の方向性が揃いやすくなった、という感触です。
特に効果が大きかったのは企画書フォーマットでした。「タイトル」「対象メディア」「記事タイプ」「想定読者」「メインキーワード」「記事構成の方向性」「1次情報メモ」といった項目を毎回同じ形で書いておくと、AIが受け取る情報の粒度が揃います。AI側に「察してもらう」必要がなくなり、出力が安定する、という単純な話でした。
考えてみると、当たり前っちゃ当たり前で、推論能力の高さ故忘れがちですが、そもそもAIはプログラムです。プログラムというものは、同じInputをすれば必ず同じ動きをする、そういうものです。プログラムである以上Inputが安定すればOutputが安定する。それは至極当然のことでした。
つまり、AIの出力品質をブレさせていたのは、AIの賢さよりも自分が渡しているインプットのバラつきのほうが大きかった。ここを文書化と整備で固めたことが、いまの運用の地盤になっています。
AIを使うほど、人間側のマネジメント力と判断力が問われる
ここまでをまとめると、MMDのAIワークフロー設計で人間側に残しているのは大きく2つです。
ひとつは「設計力」。ここでいう設計とは実装設計等ではなく、業務設計です。「マネジメント力」と言い換えてもいいかもしれません。どのような業務フローにして、どこにどのAIを配置するか、そしてどのようなルールを設定すればうまく回るのか、など運営を設計する力です。もうひとつは「判断力」。AI出力を最終的に採用するかどうかを決めて、責任を引き受ける力です。
AIを増やせば自動的に楽になるなら、人間側の仕事は減っていくはずですが、実際には逆でした。AIに任せられる範囲が広がるほど、「何をどう任せるか」「どこで判断するか」を決めるコストが前面に出てきます。AIを使うほど、人間側の設計力（マネジメント力）と判断力の比重がむしろ上がる、というのが運用してみての実感です。
裏を返せば、設計と判断を人間側で握れていれば、AIをうまく使うほどブログ運営は確かに楽になります。MMDの運用が成立しているのは、便利なAIを並べたからではなく、役割と判断の境界線を先に決めたからだと思っています。
シリーズの次に読む記事
本記事はAIワークフロー記事シリーズの2本目として、設計思想を扱いました。シリーズの他の記事はそれぞれ別の角度からこのテーマを掘り下げていきます。
シリーズ全体の入口として、現行ワークフローの全体像を紹介した1本目はこちらです。
本記事の次は、シリーズに登場する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公開
コメント