ブログを半自動化した話 — AIに書かせて、公開ボタンは人間が押す

**この記事の結論：**このブログの記事はAIが下書きしています。この記事自体もそうです。ただし、事実の供給と公開判断は必ず人間が握る設計です。

ただし、AIが勝手に記事を公開することはできない設計になっています。僕のサイトのブログには「AIが書く → 機械が検査する → 人間が公開を判断する」というパイプラインが組まれていて、この記事ではその仕組みと、あえて全自動にしていない理由を公開します。

この記事で分かること：

• AIブログ自動化の全体フロー（何をAIに任せ、何を人間が握るか）
• 「AIに数字を作らせない」ための設計
• 品質チェックをAI採点ではなく機械検査にした理由

1. 全体フロー — 6つの工程

うちのパイプラインは次の流れで動きます。

① テーマと事実データ（FACTS）を人間が渡す
   ↓
② AIが記事の「型」に沿って下書きを書く
   ↓
③ 機械検査ゲート（文字数・禁止表現・リンク検査）
   ↓
④ ビルド確認（サイトが壊れないか）
   ↓
⑤ プルリクエスト作成（公開はされない）
   ↓
⑥ 人間がレビューして、OKなら公開

ポイントは、③〜⑤がすべて自動なのに対し、①（事実の供給）と⑥（公開判断）は必ず人間という分担です。

③〜⑤は自動、①と⑥は必ず人間が担当する分担です。

2. 設計原則① AIに数字を作らせない

**注意：**AIに記事を書かせるときの最大のリスクは、それらしい嘘（存在しない数字・事例）を書くことです。

そこでうちのパイプラインでは、記事生成時に「使ってよい事実データ（FACTS）」を人間が明示的に渡し、FACTSにない数字・実績・固有名詞は書いてはいけないというルールをAIへの指示に組み込んでいます。料金・実測値・日付はすべて人間が供給し、AIの仕事は「渡された事実を、読みやすい構成に組み立てること」に限定されます。

事実が足りなければ記事は薄くなりますが、薄い記事は直せても、嘘の混ざった記事は信頼ごと壊します。この非対称性が設計の出発点です。

3. 設計原則② 品質チェックはAI採点ではなく機械検査

「AIが書いた記事をAIに採点させればいい」と考えがちですが、うちはこれを採用しませんでした。AIの採点は基準がぶれやすく、「なぜ合格なのか」を後から検証できないためです。

代わりに、判定基準が固定された機械検査をゲートにしています。

機械検査は融通が利きませんが、同じ基準で必ず同じ判定を返すという信頼性があります。実際、初期に書いた記事がこのゲートに文字数不足で弾かれたことがあり、そのときはゲートを緩めるのではなく記事を厚くする方を選びました。ゲートを守るためのゲートです。

品質チェックをAI採点ではなく機械検査にした理由の比較です。

4. カニバリ防止 — キーワード台帳

記事を量産する体制で起きがちなのが、同じ検索キーワードを狙う記事が複数できてしまい、互いに順位を食い合う問題（カニバリゼーション）です。

対策として「1記事＝1主キーワード」の台帳を用意し、新しい記事を書く前に必ず照合するルールにしています。既存記事とキーワードが被る場合は、焦点をずらすか、新記事を書かずに既存記事を強化します。台帳は仕組みというより運用ルールですが、量産の前に用意しておかないと後から手がつけられなくなる類のものです。

5. なぜ全自動にしないのか

技術的には、スケジュール実行を有効にすれば「毎朝AIが記事を書いて自動公開する」ところまで作れます。実際、うちのパイプラインにもその設定は書いてあり、今は意図的に無効化してあります。

理由は単純で、ブログの価値は記事の本数ではなく信頼の蓄積であり、盛った記事が1本混ざるだけでサイト全体の信用が壊れるからです。得られるもの（公開の手間削減）と失いうるもの（信頼）が釣り合いません。

進め方は段階的に考えています：

1. 現在：AIが下書き → 人間が全件レビューして公開
2. 品質が安定したら：自動で下書きが毎日届く → 人間はレビューだけ
3. さらに先：一部カテゴリのみ自動公開を検討（それでも全記事は自動化しない想定）

「自動化できること」と「自動化してよいこと」は別物——これは僕がAI導入の相談を受けるときにもそのまま当てはまる話です。

あわせて読みたいAIで業務を効率化する。どの仕事から渡すかの決め方と、うちの実例

よくある質問

AIが書いたと公表して、読者の信頼は落ちませんか？

うちは逆の立場をとっています。隠して後から分かる方がダメージは大きく、「AIが下書きし、事実の供給と公開判断は人間が行う」と工程を明示する方が誠実だと考えています。この記事がまさにその実例です。

使っているAIは何ですか？

Claude（Anthropic社）のAPIを使っています。記事の「型」（構成テンプレート）と禁止事項を指示に埋め込み、テーマと事実データを渡して生成する方式です。

同じ仕組みは他社のブログにも作れますか？

作れます。必要なのは「記事の型の定義」「事実データの供給ルール」「機械検査の基準」「公開フローの設計」の4点で、ブログの技術構成（WordPressか静的サイトか等)に合わせて実装は変わります。うちでは自社サイトで運用しているものと同じ考え方での構築を支援しています。

まとめ

• AIブログ運用の肝は「何を任せるか」ではなく**「何を人間が握り続けるか」**
• 僕の答えは2つ：事実の供給と公開判断は人間から手放さない
• 品質ゲートはAI採点より基準固定の機械検査が検証可能で信頼できる
• 全自動化は技術の問題ではなく信頼リスクの問題。段階的に昇格させる

ブログ・SNS運用の自動化設計のご相談はお問い合わせから。この仕組みを作る過程のサイト改善実録はLCP改善の記事でも公開しています。