受託事業者が自社ブログを続けられない理由は、書く時間よりむしろ、書いたあとの往復にあります。画像を作って、CMSに貼って、見出しを整えて、公開して、サイトマップを確認して——この30分が毎日だと思うと、手が止まります。
この記事は、その往復をなくすために自分たちが組んだ構成の記録です。結論を先に書くと、人がやるのは「何を書くか」の判断と公開前の確認だけにして、生成・入稿・公開・通知はコマンドとMCPに寄せました。 MCP（Model Context Protocol）とは、AIが外部のツールを共通の作法で呼び出すための規格です。CMS側がMCPに対応していると、管理画面を開かなくても下書きを作れます。
自社の運用の話なので、他社の事例や一般的な効果の話はしません。構成と、つまずいたところをそのまま書きます。
この記事の要点
- 自動化するのは生成・入稿・公開・通知。テーマ選びと事実確認は人が残す
- CMSのMCPだけでは完結しない。表の変換と検索エンジンへの通知は後処理が要る
- 編集方針をリポジトリのMarkdownに置くことが、実質的にいちばん効いた
何を自動化し、何を手で残したか
全部を自動にすると、読めるけれど中身のない記事が量産されます。境目は「判断が要るかどうか」で引いています。
| 工程 | 扱い | 理由 |
|---|---|---|
| テーマ選び | 手（ネタ帳から選ぶ） | 既存記事との重複判定が要る |
| 本文の執筆 | 自動（編集方針に従う） | 型が決まっている |
| 事実の確認 | 手 | 出典のない数字を出さないため |
| ヒーロー画像・図解 | 自動（SVG→PNG） | デザイン言語を固定してある |
| メディアへのアップロード | 自動 | 単なるAPI呼び出し |
| 下書き作成 | 自動（MCP） | 管理画面を開く必要がない |
| 公開前の目視確認 | 手 | 最後の安全弁 |
| 公開と検索通知 | 自動 | 手順が完全に固定 |
手で残したのは3つだけです。この割り振りにしてから、1本あたりの作業は「ネタを選んで、出来たものを読む」だけになりました。間接業務の時間をどこまで削るかの考え方は受託の稼働管理のやり方と同じで、総量を減らすのではなく、請求できない作業を後回しにしない仕組みにすることが目的です。
サイト側の構成
サイトは Astro で作って Cloudflare Workers で配信しています。CMSは Astro に統合する型のものを使い、データは D1（SQLite）、画像は R2、キャッシュは KV という分担です。
ページの配信方法は2つに分けています。
- マーケティングページ（トップ、機能紹介、法務ページ）はビルド時に静的化
- ブログとお知らせはSSR。公開した瞬間に一覧・RSS・サイトマップに反映させるため
この分け方にしたのは、記事を公開するたびにデプロイしたくなかったからです。静的生成だけで組むと、記事1本の公開がビルドとデプロイを伴い、失敗したときの影響範囲がサイト全体になります。
ブログ用のサイトマップはSSRのエンドポイントとして別に用意し、静的ページのサイトマップと両方を robots.txt から参照しています。
記事1本が公開されるまでの流れ
実際の手順は次の7ステップです。
- 編集方針を読む。記事の型、トーン、使ってよい製品ファクトを書いたMarkdownをリポジトリに置いてある
- 既存記事の一覧を取る。タイトルとslug、公開日だけをAPIから引いて重複を避ける
- 本文をMarkdownで書く。見出し構成・FAQ・内部リンクの本数は方針で決まっている
- ヒーロー画像と図解を生成する。設定をJSONで渡すと、SVGを組み立ててPNGにするスクリプトが2本ある
- 画像をメディアAPIへ送る。返ってくるIDとストレージキーを、次のステップで記事に紐づける
- MCPで下書きを作る。Markdownを渡すとCMS側で構造化テキストに変換される
- 公開して、検索エンジンに通知する。公開APIを叩いたあと、IndexNowにURLを送る
6番目がこの構成の肝です。REST API に直接POSTするとMarkdown文字列を受け付けてくれませんが、MCPのツール経由だと変換をCMS側が引き受けます。「AIが直接叩ける窓口」を用意するとは、つまりこういうことだと思います。同じ考え方を営業データに適用した話はSFAをAIにつなぐMCP連携とはに書いています。
つまずいた3つ
素直に書くと、最初からすんなりとは回りませんでした。
| つまずいた点 | 何が起きたか | どう直したか | |||
|---|---|---|---|---|---|
| 表が変換されない | Markdownの表が構造化テキストにならず、「 | 」の生テキストのまま公開された | 公開前にHTMLブロックへ変換する後処理スクリプトを足した | ||
| 新記事が通知されない | 記事公開はデプロイを伴わないため、デプロイ時の検索通知に乗らない | 公開直後にURLを渡すモードを通知スクリプトに追加した | |||
| トーンがぶれる | 書くたびに見出しの粒度や自社紹介の位置が変わる | 編集方針をリポジトリのMarkdownにし、毎回最初に読む手順にした |
3つ目が一番効きました。方針を文章で書いてリポジトリに置くと、「この見出しは方針のどの規則に反しているか」を後から検証できます。仕組みが定着しない理由としてSFAが定着しない理由に書いたのと同じで、基準が文書になっていないと運用は必ずぶれます。
公開日の扱いで注意したこと
地味ながら重要だったのが、日付をどこで持つかです。
記事の一覧・RSS・サイトマップの並び順と表示日は、すべて記事自身が持つ公開日のフィールドを基準にしています。CMSのシステム上の公開時刻とは別物です。両方を揃えないと、一覧では9月25日なのにRSSでは別の日付、というずれが起きます。今は公開日を指定し、時刻を朝7時に揃える手順に固定しています。
この手の「揃えるだけのルール」は、人間が覚えておくと必ず忘れます。手順書に書いて、毎回同じコマンドで叩く形にしておくのが結局一番安いです。
受託事業者が同じことをやるなら
この構成をそのまま真似る必要はありませんが、再現性があるのは次の3点だと思います。
- 編集方針をドキュメントにする。AIに書かせるかどうかに関係なく、複数人で書くなら必要になります
- やらないことを書く。出典のない統計を作らない、という禁止事項は、書いていないと必ず破られます
- 入稿と公開をコマンドにする。手順が固定している作業を手でやる限り、忙しい月に必ず止まります
ブログを新規開拓のチャネルとして見る場合の位置づけは受託の新規開拓の方法に整理しています。即効性はないチャネルなので、維持コストを下げられるかどうかが続くかどうかを決めます。
なお、私たちが作っている Pipelia 自体も同じ考え方でMCPに対応しており、営業・案件・粗利のデータを自然文で問い合わせられます。
よくある質問
AIに記事を書かせると品質は下がりませんか？
何も決めずに書かせれば下がります。我々の場合は、記事の型・見出しの切り方・使ってよい製品ファクト・出典のない数字を作らないという禁止事項を先にドキュメント化しています。その上で、事実関係と公開前の確認は人が残しています。自動化しているのは判断ではなく、手順が固定している作業のほうです。
MCP対応のCMSでないとこの構成は組めませんか？
REST APIがあれば同じことはできます。ただし、本文の形式変換を自分で書く必要が出ます。多くのヘッドレスCMSは本文を独自の構造化形式で持っていて、APIにはMarkdownをそのまま渡せません。MCP対応の利点は、その変換をCMS側が引き受けてくれることです。
この仕組みを作るのにどのくらいかかりましたか？
画像生成と後処理のスクリプトは、どれも数百行程度の小さなファイルです。時間がかかったのはコードではなく、編集方針を文章にする作業と、つまずいたところを手順書に戻す作業でした。逆に言えば、この2つをやらないと、スクリプトだけを揃えても運用は安定しません。