AIと一緒にブログを書いてGitHubで自動公開——製造業のブログ量産の仕組みを作った

製造業の会社がブログを書く理由は、意外と多い。

• 現場の改善事例やDX取り組みを発信して取引先・顧客に実績をアピールする。
• 技術者・現場スタッフの採用に向けて「うちの現場はこんな仕事をしています」を伝える。
• 展示会出展後のフォローとして、製品の詳細情報や活用事例を発信する

——やりたいことはあるが、なかなか続かない。
理由は「書く手間」と「公開する手間」の2つが重なるからだ。

「じゃあAIに全部書かせればいい」——実はそこに落とし穴がある。
AIだけが書いた記事は、Googleに評価されにくくなっている。
「誰が書いたか」「実際に経験した人が書いたか」が問われる時代になっているからだ。

答えは「AIに全部任せる」でも「人間が全部書く」でもなく、AIと一緒に書くことだ。

この記事では、人間がやるべき部分とAIに任せる部分を整理した上で、公開までを自動化する仕組みを解説する。

---

結論：人間とAIの役割を分けて、「書く」と「公開する」のコストを両方下げる

まず全体像を示す。

• AIに任せていい部分：文章の構造化・文章化・Markdown整形・WPへの投稿
• 人間がやるべき部分：テーマの企画・実体験の提供・ファクトチェック・最終判断

graph TB
    A["【人間】企画・テーマ決め"]
    B["【人間】実体験・数字・現場の声を準備"]
    C["【AI】構成案を作成"]
    D["【人間】構成案を確認・補足"]
    E["【AI】本文ドラフトを執筆"]
    F["【人間】ファクトチェック・加筆"]
    G["【AI】Markdown整形・GitHubにコミット"]
    H["【自動化】GitHub Actions → WP下書き保存"]
    I["【人間】最終確認・公開"]
    A --> C
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    G --> H
    H --> I
    style A fill:#E8F4FD,color:#1a1a1a
    style B fill:#E8F4FD,color:#1a1a1a
    style D fill:#E8F4FD,color:#1a1a1a
    style F fill:#E8F4FD,color:#1a1a1a
    style I fill:#E8F4FD,color:#1a1a1a
    style C fill:#FFF3E0,color:#1a1a1a
    style E fill:#FFF3E0,color:#1a1a1a
    style G fill:#FFF3E0,color:#1a1a1a
    style H fill:#E8F5E9,color:#1a1a1a

この役割分担を守ることで、EEATを担保しながら公開コストを大幅に下げられる。

公開の自動化は、MarkdownをGitHubのmainにマージするだけで、GitHub ActionsがWordPressに自動で下書き保存する仕組みだ。

---

AIに全部書かせてはいけない理由 — EEATとは何か

Googleが評価する4つの要素

EEATとは、Googleが検索品質を評価するための指標だ。

要素	意味	ブログへの影響
Experience（経験）	実際にやってみた経験があるか	最重要。実体験のない記事は評価されにくい
Expertise（専門性）	その分野の専門知識があるか	業界特有の知見・技術的な正確さ
Authoritativeness（権威性）	信頼される情報源か	他サイトからの参照・著者の実績
Trustworthiness（信頼性）	情報が正確で誠実か	事実確認・出典明示

特に「Experience（経験）」がポイントだ。
改善事例なら「実際に何が変わったか」「現場で何が起きたか」、採用ブログなら「実際の職場の様子」——これはAIには書けない。

AIが生成したコンテンツは、経験の裏付けがない薄い内容になりやすい。
読んでいると「どこかで見たような話」になる。
Googleはそれを評価しないし、読者も読み続けない。

人間が提供しなければならない「素材」

AIは「文章を作る」ことはできるが、「経験を持つ」ことはできない。

ブログに必要な人間からの素材は次の4つだ。

1. テーマ・企画：何を・誰に・なぜ伝えるか
2. 実際の経験・数字・現場の声：「○○という問題が起きた」「導入後、作業時間が30%減った」
3. 専門知識の裏付け：業界特有の事情、自社ならではの知見
4. 最終確認：事実確認・自社スタンスとのズレチェック

この素材をAIに渡して文章化させる——これが「一緒に書く」の実態だ。

---

「AIと一緒に書く」の具体的な進め方

書くプロセスの役割分担

graph TB
    A["1. 人間：テーマ・実体験をメモ"]
    B["2. AI：構成案を作成"]
    C["3. 人間：構成案を確認・修正・補足"]
    D["4. AI：本文ドラフトを執筆"]
    E["5. 人間：ファクトチェック・加筆・調整"]
    F["6. AI：Markdown整形→GitHubにコミット"]
    A --> B --> C --> D --> E --> F
    style A fill:#E8F4FD,color:#1a1a1a
    style B fill:#FFF3E0,color:#1a1a1a
    style C fill:#E8F4FD,color:#1a1a1a
    style D fill:#FFF3E0,color:#1a1a1a
    style E fill:#E8F4FD,color:#1a1a1a
    style F fill:#FFF3E0,color:#1a1a1a

人間が「素材を出す」「判断する」ステップは省略できない。
ここを飛ばすと、経験の裏付けがないEEAT的に弱い記事になる。

CLAUDE.mdに「書き方のルール」を書いておく

Claude Codeを使う場合、CLAUDE.mdに記事のルールを書いておくと毎回指示しなくてよくなる。

# ブログ記事ルール

## 読者
製造業のDX推進担当者・現場改善を担う層

## 文体
です/ます調で統一

## 必須要素（全記事に含める）
- なぜやったか（目的）
- 何が起きたか（結果）
- 何が学びだったか（再現性）
- 業務にどう効くか（意味）

## 注意
自社の実体験・数字は必ず人間が確認・加筆する。
AIが生成した内容のまま公開しない。

AIはこのルールに従って文章を書くが、実体験の部分は人間が書き足す。
このひと手間がEEATの担保になる。

---

公開の自動化 — GitHub ActionsでWPに自動デプロイ

書いた記事を公開するコストを、自動化で下げる仕組みを解説する。

パイプラインの全体フロー

graph TB
    A["article.md を書く"]
    B["mainにマージ"]
    C["GitHub Actions 発火"]
    D["変更記事を検出"]
    E["deploy-blog.js を実行"]
    F["Markdown→HTML変換"]
    G["画像をWPにアップロード"]
    H["WP REST APIに投稿"]
    I["WPに下書き保存"]
    A --> B --> C --> D --> E --> F --> G --> H --> I
    style A fill:#FFF3E0,color:#1a1a1a
    style B fill:#FFF3E0,color:#1a1a1a
    style C fill:#E8F5E9,color:#1a1a1a
    style D fill:#E8F5E9,color:#1a1a1a
    style E fill:#E8F5E9,color:#1a1a1a
    style F fill:#E8F5E9,color:#1a1a1a
    style G fill:#E8F5E9,color:#1a1a1a
    style H fill:#E8F5E9,color:#1a1a1a
    style I fill:#E8F4FD,color:#1a1a1a

重要なポイントは投稿ステータスがdraftであることだ。
自動公開ではなく下書き保存——最終確認は人間が行う。

ファイル構成

リポジトリはこのように構成している。

content-blog/
├── .github/workflows/
│   └── deploy-to-wordpress.yml  # GitHub Actionsの定義
├── scripts/
│   └── deploy-blog.js           # デプロイスクリプト
├── config.yml                   # WP設定（投稿タイプ、ステータスなど）
└── monozukuri-ai/
    └── BM-122/
        └── article.md           # 記事本文（Markdown）

記事はカテゴリ/BM-番号/article.mdというパスで管理する。
h1がWPの記事タイトルになり、本文はMarkdownをHTMLに変換して投稿される。
slugはディレクトリ名の小文字で自動決定（例：bm-122）。
既存記事があればupsert（更新）する。

GitHub Actionsのworkflowファイル

.github/workflows/deploy-to-wordpress.ymlの実装例だ。

name: Deploy Blog to WordPress

on:
  push:
    branches:
      - main
    paths:
      - '*/BM-*/article.md'
      - '*/BM-*/images/**'

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 2  # 差分検出に必要

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Detect changed articles
        id: changes
        run: |
          changed=$(git diff --name-only HEAD~1 HEAD \
            | grep -E '^[^/]+/BM-[^/]+/' \
            | sed 's|^\([^/]*/BM-[^/]*\)/.*|\1|' \
            | sort -u | tr '\n' ' ')
          echo "articles=${changed}" >> $GITHUB_OUTPUT

      - name: Deploy to WordPress
        if: steps.changes.outputs.articles != ''
        run: node scripts/deploy-blog.js
        env:
          WP_URL: ${{ secrets.WP_URL }}
          WP_USER: ${{ secrets.WP_USER }}
          WP_APP_PASSWORD: ${{ secrets.WP_APP_PASSWORD }}
          CHANGED_ARTICLES: ${{ steps.changes.outputs.articles }}

pathsでarticle.mdが変更されたときだけ発火するよう限定している。
fetch-depth: 2は直前のコミットとの差分を取るために必要な設定だ。
変更されたBM-*ディレクトリだけを検出して処理するので、記事数が増えても無駄な処理が走らない。

Markdownの変換ルール

デプロイスクリプトはmarkedライブラリでMarkdown→HTML変換を行う。
主な変換ルールは以下のとおりだ。

Markdownの書き方	変換後
通常のMarkdown記法	HTML（markedライブラリで変換）
```mermaid コードブロック	<pre class="mermaid"> に変換（WPのMermaidプラグインと連携）
ローカル画像 	WPメディアライブラリにアップロードしてURLを置換
YouTube URLを単独行に記載	WPエンベッドブロックに変換

WordPress側の準備

必要な設定は2つだけだ。

1. アプリケーションパスワードを発行する
   • WordPress管理画面 → ユーザー → プロフィール → アプリケーションパスワード
   • 任意の名前（例：GitHub Actions）を入力して「新しいアプリケーションパスワードを追加」
2. GitHub Secretsに3つの値を登録する
   • WP_URL：WordPressサイトのURL（例：https://example.com）
   • WP_USER：WordPressのユーザー名
   • WP_APP_PASSWORD：発行したアプリケーションパスワード

WordPress REST APIはデフォルトで有効になっているので、追加設定は不要だ。

GitHub Actions以外でも同様の仕組みは作れる

このパイプラインの本質は「変更を検知 → Markdown→HTML変換 → WP REST APIに投稿」の3ステップだ。
WP REST APIとアプリケーションパスワードがあれば、どのツールからでもWordPressに投稿できる。

ツール	トリガー	特徴
GitHub Actions	gitのpush	コード管理と一体化、無料枠あり
n8n	Webhook、定期実行	ノーコードで設定可能
Zapier/Make	各種サービス連携	非エンジニアでも設定しやすい

Gitやコード管理に慣れていなければ、n8n＋Google Driveのような構成でも同じことを実現できる。
「自動化の仕組み」よりも「WP REST APIで投稿できる」という事実が重要だ。

---

まとめ：人間×AIの役割分担表と、今日から始める3ステップ

人間とAIの役割分担まとめ

作業	担当	理由
テーマ・企画	人間	誰に何を伝えるかは人間が判断する
実体験・数字・現場の声	人間	AIには経験がない。EEATの根拠になる
構成案・文章化	AI	素材さえあれば高品質なドラフトを作れる
ファクトチェック・加筆	人間	事実確認と自社スタンスの確認は人間の仕事
Markdown整形・コミット	AI	単純作業はAIに任せる
WPへの下書き保存	自動化	GitHub Actionsが担う
最終確認・公開	人間	最後の判断は人間が行う

今日から始める3ステップ

Step 1：WordPressのアプリケーションパスワードを発行する

管理画面のユーザー設定から発行するだけ。
これでWP REST API経由での投稿が可能になる。

Step 2：GitHubリポジトリを作り、workflowを設定する

.github/workflows/deploy-to-wordpress.ymlを配置して、GitHub Secretsに3つの環境変数を登録する。

Step 3：人間が「素材」を出して、AIと一緒に書く

CLAUDE.mdに記事ルールを書いておけば、テーマと実体験をメモするだけでAIが構成案と本文を作ってくれる。
mainにマージするだけでWPに下書き保存される。

「人間は企画と経験の提供に集中する」

AIと自動化が整うと、担当者の役割が変わる。

文章化・整形・公開準備——これらをAIと自動化に任せられる。
担当者は「何をテーマにするか」「実際に何が起きたか」の企画と経験の提供に集中できる。
EEATを担保しながら、改善事例・採用・DX実績の発信を継続的に積み上げることが現実的になる。

AIを活用したコンテンツ自動化の導入相談は、アディエムまでお気軽にどうぞ。

---

参照元

• WordPress REST API Handbook
• GitHub Actions ドキュメント
• Google 検索品質評価ガイドライン（EEAT）
• marked — Markdown parser

関連記事

• 

  2026-04-02

  Claude Code × browser-useで「止まらない自動開発ループ」を構築する

  Claude Codeで、こんなことができたら Claude Codeを使えば、製造業の現場でもこんなことができます。 工程管理画面のkintoneカスタマイズを、仕様を伝えるだけで一気に実装 検査データの入力フォームを、バリデーション込みで自動生成 生産実績…

• 

  2026-03-26

  Claude Codeを長時間自走させる方法——許可設計で「止まらないAI開発」を実現する

  Claude Codeで、こんなことができたら Claude Codeを使えば、製造業の現場でもこんなことができます。 受注・在庫・工程能力データから、週次の生産計画草案を自動生成するスクリプトを、仕様を伝えるだけで一気に実装 Excelで手作業していた負荷山…

• 

  2026-03-22

  n8nを使って自社のサイトに特化したSEOレポートを自動生成しよう

  毎月のSEOレポート、まだ手作業で作っていませんか？ GA4を開いて、Search Consoleを開いて、数字をスプレッドシートにコピペして、グラフを整えて—— 毎月この繰り返しをしていないでしょうか。 「数字を並べるだけなら何とかなる。でも、分析コメントを…