少し前まで、ブログを1記事仕上げるのに早くて2〜3時間、重い記事だと5〜6時間かかっていました。書く時間そのものより、ChatGPTで企画を考え、Claude Chatで本文を書き、またChatGPTでチェックする、というAI間の行き来に時間を取られていた感覚があります。
MMD（緑のもめんどうふ）の現在の記事制作は、Claude Codeを「ちょこ」と呼んで編集部の記事制作担当に据える形に落ち着きました。本記事では、なぜClaude Codeをブログ執筆担当として固定したのか、何を渡してどこまで任せているのか、逆に何を任せていないのかを、実運用ベースで整理します。
この記事は、MMDのAIワークフロー紹介シリーズの4本目です。シリーズ全体像や設計思想は前提記事に譲り、ここでは「記事制作ライン」だけに絞ります。筆者は本業で自動車開発のPMをしており、エンジニアリングの基礎知識はある一方、日常的にプログラムをゴリゴリ書く職種ではありません。「非プログラマーの個人ブログ運営者」の運用例として読んでください。
1記事5〜6時間からの脱出｜旧フローで詰まっていたところ
旧フローはざっくりこういう流れでした。
- ChatGPTで企画を考える
- Claudeに切り替えて構成を作る
- ChatGPTで構成をチェックし、フィードバックを出力
- Claudeにフィードバックを渡し、構成を修正。
- ChatGPTのGoが出るまで繰り返し（大体2～3往復）
- Claudeに切り替えて、完成した構成で本文を書く
- Claudeのたたき台にTKDが1次情報を反映して、ChatGPTに本文をセクションごとに送り、チェック
- チェック結果をTKDが反映
- ChatGPTのGoが出るまで繰り返し（大体2～3往復）
- 全セクション完了するまで繰り返し
- 書き終えた全体をChatGPTに戻して、文章をチェックしてもらう
- チェック結果をTKDが反映
- ChatGPTのGoが出るまで繰り返し（大体2～3往復）
- 本文を書き終えたあと、TKDが手作業で写真・画像を反映する
これでも記事は出来ます。実際に何十本もこのフローで公開してきました。ただ、書いていて一番手間だったのは本文そのものではなく、ChatGPTとClaudeのあいだを行き来して、企画意図や1次情報、文体の好みを毎回伝え直す作業でした。AIを乗り換えるたびに、前提を貼り直して、また同じ温度感に戻すための短いやり取りを挟みます。1回の作業は数分でも、1記事まるごとだと地味に積み上がっていきます。
もうひとつの問題は、参照ファイルの不在でした。文体ルールやHTMLフォーマットを、その都度プロンプトの指示欄に書いて渡していたので、ルールが揃っていても「どこまでAI側で守られたか」が記事ごとにばらつきました。質が上がる日もあれば、なんとなく抽象的にまとまる日もあって、ベースラインが安定しません。
本文を書いてもらうAIをClaude系に寄せていたのは、いろいろ試した中でClaudeの文章が一番自然だったからです。ChatGPTでも書けますが、MMDが目指している「個人ブログとして自然な語り口」とは少し肌触りが違いました。Claudeのほうが、書き手の温度をそのままなぞってくれる感覚があります。Claude側で本文を書く前提を崩さずにAI間の橋渡しコストだけを下げたい、と考えて行き着いたのが、Claude Codeを「記事制作担当」として常駐させる形でした。
ちょこに渡している材料｜企画書・1次情報・スタイルガイド
ちょこに記事を作ってもらうとき、毎回渡しているのはおおまかに4種類の材料です。
- 記事企画書（タイトル候補・想定読者・記事タイプ・SEO・構成方向性など）
- 調査結果（パープレ＝Perplexityで集めた一次資料、整理済みのもの）
- 1次情報（TKDの実体験・観察・撮影写真メモなど）
- スタイルガイド類（文体ルール・HTML出力ルール・SEOガイド・カテゴリタグ運用）
スタイルガイド類はディレクトリ内のMarkdownとして常設してあるので、毎回コピペして渡す必要はありません。記事ごとに新しく用意するのは、企画書と1次情報、それから必要に応じた調査結果メモだけです。出力が安定するかどうかは、本文の書き方そのものより、この4種類のインプットが揃っているかで決まる、というのが実感です。
企画書フォーマットが一番効いた
振り返ってみて一番効いたのは、企画書のフォーマットを決めたことでした。タイトル候補・対象メディア・記事タイプ・想定読者・SEO・構成方向性・参照ファイル・内部リンク候補・注意点、と項目を固定したテンプレートを用意し、ChatGPT（チャッピー）と一問一答で埋めてからちょこに渡しています。項目が決まっていると、TKD側で「何を決めれば制作に入れるか」が明確になり、ちょこ側も毎回同じ場所から情報を取り出せるので出力のばらつきが減りました。インプットを安定させたことが、結果的に出力品質のベースラインを押し上げたと感じています。
副産物として、文体ルールやHTMLルールをMarkdownに書き出したことで、ChatGPTやPerplexityに渡す指示の精度も上がりました。ちょこ用に整備したつもりが他のAIにも効いた、というのは運用してみるまで読めなかったところです。
1次情報はTKDが入れる前提
体験記事やレビュー記事の1次情報は、AIに創作させない、というのは最初から決めていました。現地で見た景色、触ったときの感触、その日の天候や混雑具合といった部分はAIが「それっぽく」書けてしまう領域でもあるからです。それっぽく書けるからこそ、線引きを甘くするとブログの信頼が一気に崩れます。
運用上は、企画書の「1次情報メモ」欄をTKDが事前に埋めておくか、本文中で必要な箇所にちょこ側から <!-- TKD補完: ◯◯ --> コメントを残してもらいます。後から人間が埋める前提で構成を組むので、AIが想像で穴を埋める事故が起きにくくなりました。また、企画書に入れ混んでしまう場合には、自分で書くこともありますが、チャッピーに一問一答形式のインタビューをお願いして、その回答をまとめて記載してもらうようにすることもあります。このやり方だとちょっとした合間に作業できるので、案外重宝しています。
スタイルガイド・HTML出力ルール・SEO・タグ運用
ちょこには、文体ルール・HTML出力フォーマット・SEOガイドライン・カテゴリとタグの運用方針を、それぞれMarkdownのルールファイルとして読ませています。記事ごとに毎回貼り直すのではなく、ディレクトリ内に常設しておいて、必要に応じて参照させる形です。具体的には、文体は「ですます調」「全角の？！」「導入文は体験から始める」、HTMLはWordPressクラシックエディタ＋Cocoonテーマ前提で標準タグ中心、SEOはタイトル30〜35字・メタディスクリプション80〜120字、タグは独自企画・固有名詞・テーマ・イベント時期の4分類で3〜8個、といった水準です。
ルールが文書化されていると、ちょこ自身がセルフチェックの拠り所として使えるのが大きな利点です。「ちょこのアウトプットが安定する」というより「ちょこがセルフチェックできることで手戻りの手間が減る」という言い方が近いと思います。
実際のブログ執筆ワークフロー｜MMDの担当分担
現在の記事制作フローを、上流から並べるとこんな順番になります。
- チャッピー（ChatGPT）と壁打ちして企画書（定型フォーマット）を作成する
- 必要に応じてパープレ（Perplexity）で外部情報を調査する
- チャッピーまたはTKDが1次情報（体験談・調査結果）をまとめて企画書に反映する
- ちょこ（Claude Code）に企画書・調査結果・1次情報・スタイルガイドを渡す
- ちょこが構成案を作り、構成セルフチェックする
- TKDが構成案を確認する
- ちょこが本文を書き、本文セルフチェックする
- ちょこがWordPress貼り付け用HTML・メタ情報・X投稿たたき台まで出力する
- チャッピーが第三者視点でレビューする（任意）
- TKDが最終チェックを兼ねてWordPressへ転記&画像添付して公開する
MMD3本柱の製作フロー。ツール開発は真ん中のフロー。
並べると工程は多く見えますが、ちょこ導入前はこれらのあいだにAI間の手動受け渡しが何度も挟まっていました。いまは構成・本文・HTML出力までがちょこのなかで一気通貫で進むので、TKDは前段（企画整理）と後段（最終判断と公開）に集中できる構造です。体感では、企画に10分~30分、記事作成に5分~10分、TKDの公開前作業に15分～50分くらいです。軽い記事なら30分、重い記事でも1.5時間程度で公開までが可能となりました。渡す情報を工夫さえすれば、ちょこが装飾確認・内部リンク追加もしてくれるので、TKDの作業としては、最終チェック・写真選び・WordPress貼り付け・アイキャッチ判断あたりに集約されるので、今までの1/3程度には時間が短縮されています。もちろん、手作業での修正が必要な場合もあるので、その場合はもう少しかかる場合もあります。
ちょこに任せている記事制作＋αの作業
本文だけでなく、記事1本まわりの「制作物一式」をちょこに任せています。
- 記事構成案の作成
- 構成セルフチェック（媒体共通の観点書を読ませて、ちょこ自身が点検）
- 本文執筆
- 本文セルフチェック（同じく観点書ベース）
- WordPress貼り付け用HTML出力（Cocoon前提）
- Cocoon用の表・装飾
- メタディスクリプション
- X投稿たたき台
- アイキャッチの方向性指示
- カテゴリ・タグの提案
- 必要に応じてリライト
「本文を書くAI」というより「記事1本ぶんの制作物を一式まとめる編集部担当」というイメージで、WordPressに貼り付ける直前までをちょこ側で揃えてもらう形になっています。セルフチェックもちょこ自身が観点書を使って自分の出力を点検してから渡してくれます。完璧ではないので最終確認は必要ですが、ゼロから細かく見直す負担はかなり減りました。
Claude Codeが記事制作で効く理由｜MMDで実感したポイント
運用してみて、Claude Codeが記事制作で効いていると感じる理由は4つに整理できます。
1つ目は、複数ファイルを前提にした制作ができることです。記事制作では、企画書・1次情報・スタイルガイド・HTML出力ルール・既存記事CSV・タグ一覧と参照したいファイルがどうしても多くなります。Claude Codeはローカルのディレクトリ全体を作業対象にできるので、毎回プロンプトに貼り直さなくても、必要なファイルを必要なタイミングで読みにいってくれます。AI間の橋渡しコストが減った最大の理由はここでした。
2つ目は、スタイルガイドを参照させて文体を安定させやすいことです。Markdownに書いた文体ルールやHTMLフォーマットを、ちょこ側がそのまま読み込んで本文制作とセルフチェックに使ってくれます。「品質の上限が上がる」というより「ベースラインが押し上がる」感覚に近く、記事ごとの当たり外れが減りました。
3つ目は、WordPress貼り付け用HTMLまで一気通貫で出せることです。本文をテキストで書いてからHTMLに整形し、表や装飾を別途追加して……という旧来の流れがいらなくなりました。Cocoon前提で、見出し・段落・リスト・表・内部リンクのプレースホルダーまで揃った形で出力してもらえるので、貼り付け側の手数が大きく減ります。
4つ目は、長文記事を一気通貫で書ききれることです。MMDの記事は4,000〜6,000字台の長文も多いですが、構成→本文→セルフチェック→HTML出力を1セッションで進められるので、途中で前提が抜けたり文体が揺らいだりしにくく、大きく直し戻す手戻りも減っています。
具体的には、モータースポーツの観戦レポート、AI運用のワークフロー解説、出張シリーズなど、参照ファイルや1次情報が多い長文ほど、ちょこの一気通貫制作が効いています。1次情報がほぼない短い速報記事はちょこに通すまでもない、という線引きです。
また、完全に副産物的な効果ではありますが、Claude Codeにしてインプットとアウトプットをファイル化したことで、企画・執筆・仕上げを独立したタイミングでやれるようになりました。仕事の休憩中や帰ってから寝るまでのちょっとした間に企画書を作っておき、使用量のある間に”ながら”でちょこに執筆、時間がある週末などにまとめて仕上げ、など時間を効率よく使えるようにもなりました。
ちょこに任せても残るTKDの仕事
ちょこを記事制作担当として置いた今でも、TKDに残っている仕事はそれなりにあります。むしろ、AIに任せられる範囲が増えたことで、人間側に残る仕事の輪郭がはっきりしてきた感覚です。
- 記事の方向性や企画そのものの判断
- 1次情報の提供（実体験・現場の感触・写真メモ）
- 本文と構成の最終チェック
- 写真選び・撮影
- アイキャッチの最終判断
- WordPressへの貼り付けと、Cocoon上の装飾確認
- 内部リンクの最終判断
- 公開判断
ちょこに任せたいのは「制作物の一式を揃える」ところまでで、最終的に公開していい記事かどうか、その記事を載せるブログとして辻褄が合っているかどうかは、編集長としてのTKDが判断します。AIに最終判断を委ねないのは、MMD全体のAIワークフローで一貫させている方針です。
任せ方を間違えるとうまくいかないこと｜運用上の注意点
任せられる範囲が広がった一方で、運用していて見えてきた注意点もいくつかあります。
材料が弱いと出力も弱くなります。企画書がふわっとしたまま渡せば構成案もふわっとした見出しになりますし、1次情報が空っぽのまま体験記事を頼むと、一般論で埋まったぼんやりした記事が返ってきます。「インプットを整える」ところがTKD側の本丸の作業になりつつある、というのは旧フローと変わらない部分です。
実体験はAIに創作させません。これは何度書いても書きすぎではないと思っています。それっぽい体験文をAIに書かせてしまうと、長期資産として記事を積み上げていくときに、ブログ全体の信頼の足場が崩れます。1次情報が足りない箇所には <!-- TKD補完: ◯◯ --> コメントを残してもらって、後からTKDが埋める前提で構成を組むようにしています。
最終判断はTKDが必ず行います。投稿までを一気通貫も可能かもしれませんが、そこは目指しません。ちょこのセルフチェックも、チャッピーの第三者レビューも、あくまで補助的なチェックです。記事として公開していいかどうか、ブログ全体の文脈に合っているかどうかは、人間側で見るしかありません。AIを増やすほど「最終判断する人間がしっかり見る」必要性が逆に上がってくる、というのが今のところの実感です。
記事制作以外の作業はちょこには振りません。ツールやスクリプト、自動化、CSV処理、JSON生成といった開発系の作業は、別に「コデス」と呼んでいるCodexの担当にしています。同じAIエージェント系をなぜ分けて使うのか、という話は次回以降の記事で詳しく扱う予定です。
まとめ｜ちょこは「自動化」ではなく「部下に仕事を振る」感覚
MMDでClaude Code（ちょこ）を編集部の記事制作担当に据えているのは、AI1つで記事制作が自動化という感覚ではありません。「自然な文章作成能力」「ローカルファイルを参照した一気通貫制作」「スタイルガイドを土台にしたセルフチェック」という3つ能力を持った優秀な部下に仕事を任せるという感覚です。
裏を返せば、企画整理はチャッピー、調査はパープレ、開発はコデス、画像生成はこんこん、と他のAIにも担当領域を割り振っているのも同じ思想です。万能AIを探すのではなく、役割分担を決めてそれぞれに必要な材料を渡し、最終判断は編集長が行う。MMDのAIワークフローは、人間世界の組織運営にも通ずるような立て付けで、ちょこはその中の「記事制作担当」として常駐しています。
次回は、同じAIエージェント系である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公開
コメント