なぜ二段階にするか
AI に記事を生成させて即公開すると、E-E-A-T(経験 / 専門性 / 権威性 / 信頼性)の観点で Google に低品質判定されやすい。とくに 2025 年以降、Search の品質ガイドラインでは「AI が書いたか / 人間が書いたか」よりも「人間の責任主体が見えるか」が問われる。
そこで二段階に分ける:
Claude (Bot)
↓ POST /api/v1/bot/posts (status: draft)
Admin で人間
↓ 校正 + author を人間に変更 + 経験を追加 + status: published
読者
Bot は調査と起草、人間は責任と一次情報の追加。役割が明確 だと、E-E-A-T の信頼線も明確になる。
Bot API の側
POST /api/v1/bot/posts は API Key 認証で受ける。
class Api::V1::Bot::PostsController < Api::V1::Bot::BaseController
def create
require_scope!('posts:write')
payload = params.require(:post).to_unsafe_h
result = Bot::PostUpsertService.new(payload: payload, api_key: current_api_key).call
render json: { data: serialize(result[:post]) }, status: result[:created] ? :created : :ok
end
end
ポイント:
- slug が冪等キー: 同じ slug への upsert は再投稿可能
- API Key にスコープ:
posts:writemedia:write等で権限を分離 X-Idempotency-Keyヘッダで重複入稿防止- Rack::Attack で API Key 単位のレート制限
Bot 側の status は draft 強制が安全
Bot が status: published で投げてきても、サービス層で draft に強制する 運用も検討した。実装例:
class Bot::PostUpsertService
def call
payload = @payload.dup
payload[:status] = 'draft' # Bot 経由は強制 draft
Post::UpsertService.new(payload: payload, admin_user: @api_key.created_by).call
end
end
これだと「人間が確認するまで public にならない」が保証される。速度 vs 安全 のトレードオフだが、E-E-A-T を重視するなら強制 draft が正解。
人間の校正で何をやるか
私の場合は以下を必ず手で入れる:
- 個人的経験の段落(1〜2 段落)— 「実際に動かした」「半年前に詰まった」「家で試した」のような一次情報
- author の付け替え —
claude-botから実在の編集者へ - 数字の検証 — Bot が書いた「3 倍速くなった」が本当に 3 倍か確認
- 引用元の確認 — references の URL が生きているか
- トーンの調整 — Bot は説明的になりがち。1 文 1 つだけ口語に直す
これで「AI が起草、人間が公開」の責任ラインが完成する。
Skills との接続
Claude Skills (/post-outline /post-draft /post-image /post-publish) を組み込むと、上記が Slack か Claude Code 上のコマンド で完結する。
1. /post-outline "テーマ ..."
2. /post-draft ← payload を組み立てる
3. /post-image replace ← __IMAGE_N__ を実 URL に
4. /post-publish ← Bot API に POST
5. Admin で校正 → publish
私はこのパイプラインを 1 日で組んだ。Bot API + Skills の組み合わせは、個人雑誌の執筆速度を 5 倍 くらいに引き上げる体感がある。
まとめ
Bot 入稿 + 人間校正の二段階は、速度と信頼性を両立する 個人ブログの新しい型だと思う。
- AI 単独で公開: 速いが E-E-A-T が立たない
- 人間単独で執筆: 信頼性は高いが速度が出ない
- Bot 起草 + 人間公開: 速度 と 責任 が両立
「誰が書いたか」より「誰が責任を持つか」を仕組みに埋め込む。