このブログはAIが毎朝書いています
この記事は、いつもと少し毛色が違います。「AI で業務を改善する方法」の解説ではなく、このブログ自体がどのように作られているかを丸ごと公開する番外編です。
「AI でコンテンツを量産する」という言葉は以前から耳にしますが、実際にどのようなアーキテクチャで動いていて、コストはいくらかかって、どこでつまずいたのか——その一次情報は意外と出回っていません。SEO 的な観点でも、「誰が・どのように作ったか」という経験の開示は検索エンジンが評価する E-E-A-T(経験・専門性・権威性・信頼性)の中心に位置します。筆者自身の実装記録として、数値も課題も隠さずに書きます。
ブログ全体のアーキテクチャ
このブログは以下の 4 層で構成されています。
- フロントエンド: Astro 4 + Tailwind CSS + Vercel Adapter(
output: hybrid) - 記事生成: Claude API(
claude-sonnet-4-6)を GitHub Actions cron で呼び出し - 立ち絵(画像): OpenAI の
gpt-image-1edit endpoint で事前生成した 24 枚を全記事で使い回し - 永続化・分析: Vercel Blob(ウェイトリスト JSONL 追記)、Vercel Web Analytics + Speed Insights、GSC API 週次レポート
記事ファイルは Markdown 形式で管理し、Astro がビルド時に HTML へ変換します。Vercel Hobby プランの範囲内で完結しており、追加の課金は発生していません。
毎朝の cron フロー
毎朝 07:17 JST に GitHub Actions の cron ジョブが起動します。処理の流れは以下の通りです。
topics.yamlから未公開のテーマを 1 件取り出す- Claude API に記事本文(frontmatter + Markdown)を生成させる
- 生成された Markdown ファイルを新しいブランチに commit し、自動で PR を作成する
- 筆者(米田)が PR の内容を確認し、問題なければ
mainブランチへマージ - Vercel が自動でビルドを開始し、数分後に公開される
レビューを挟んでいるのは品質保証のためです。「自動=無審査」にするとファクトエラーや構造の破綻が通り抜けるリスクがあります。現在は「生成はゼロ秒、判断は人間」という役割分担で運用しています。
実コスト内訳
「AI を使うと費用が膨らむのでは」という懸念をよく耳にします。実測値を示します。
| 項目 | 単価・条件 | 月次換算(目安) |
|---|---|---|
| Claude API(記事生成) | 1記事 $0.05〜$0.10 | 30記事で $1.50〜$3.00 |
| 画像生成(立ち絵 24 枚) | バッチ計 $1.20 | 初回のみ・全記事使い回し |
| Vercel ホスティング | Hobby プラン | $0(無料枠内) |
| GitHub Actions | 月 2,000 分無料枠 | $0(無料枠内) |
Claude API のコストが低い理由の一つに、prompt caching の活用があります。システムプロンプト(書き方ルール・SVG 仕様・禁止事項など)は毎回同じ内容のため、キャッシュ済みトークンとして扱われ、入力コストが大幅に削減されます。
SEO 実装の詳細
自動生成コンテンツが検索エンジンに正しく評価されるには、技術的な SEO の基盤が不可欠です。現在実装している項目を列挙します。
- JSON-LD 構造化データ: 各記事に
BlogPosting、FAQ がある記事にはFAQPageを自動付与 - canonical タグ:
wwwドメインに統一(後述のトラブル参照)、Vercel 側で 301 permanent リダイレクトも設定 - 著者ブロック:
authorフィールドに筆者情報(名前・URL)を固定し、E-E-A-T シグナルとして機能させる - alt テキスト自動付与: Claude への指示に「各画像に説明的な alt を必ず書く」を組み込み
- 内部リンク URL 固定: Claude が存在しない slug を推測で生成しないよう、user prompt に「使ってよい URL 一覧」を明示
筆者の運用例
ここまでの内容は、筆者(米田 圭・Coral Connect Service 代表)が 2026-07-13 時点で実際に稼働させているシステムの実測値です。
テスト・品質保証については TDD(テスト駆動開発) を採用しており、Red コミット → Green コミットの順で Git 履歴に残す運用をしています。現在 74 テストが全 pass の状態で、各 PR の本文には Acceptance Criteria をチェックリスト形式で記載し、確認漏れを防いでいます。
分析については、Vercel Web Analytics と Speed Insights でリアルタイムの閲覧データを取得し、Google Search Console API による週次順位レポートを毎週月曜 09:30 JST に自動生成しています。同じく月曜 09:00 JST にはウェイトリスト登録の集計が Discord へ Embed 形式で投稿される仕組みになっており、週次の状況把握が自動化されています。
運用でハマった 3 つのトラブル
実装の過程で以下の 3 点が問題になりました。同様の構成を検討している方への参考として記録します。
1. Claude 出力の parse エラー
当初、Claude が生成する Markdown の先頭に「以下が記事です:」のような前置き文や、frontmatter を ```yaml のコードフェンスで囲んだ出力が混入し、パーサーが壊れました。対処として、parser 側を CRLF・コードフェンス・前置き文に耐える形に強化するとともに、system prompt に「応答の最初の 3 文字は必ず --- にする」という制約を明示しました。
2. canonical が非 www ドメインを指していた
siteUrl の設定が example.com(非 www)になっており、実サイトの www.example.com と不一致でした。結果として同一ページに 2 つの URL が存在する状態になり、検索エンジンの評価が分散するリスクがありました。siteUrl を www に統一し、Vercel の Domains 設定で非 www → www への 301 permanent リダイレクトを設定して解消しました。
3. Claude が架空の slug を生成して 404 が発生
Claude が内部リンクを書く際、存在しない /blog/xxx/ を推測で生成することがありました。例えばシリーズの前後回を参照するリンクが実際には存在しないパスを指し、公開後に 404 が発生しました。user prompt に「使ってよい URL 一覧」を明示し、system prompt でも「一覧にない URL を書かない」と明記することで再発を防いでいます。
一次情報が差別化になる理由
AI によるコンテンツ生成が一般化するにつれ、「誰でも書けそうな解説記事」は検索上位に残りにくくなります。逆に言えば、実際に動かしたシステムの数値・失敗・対処は他者が再現できない一次情報であり、E-E-A-T の「経験(Experience)」に直接対応します。
この記事自体が、その考え方の実践です。アーキテクチャの解説も、コストの数値も、トラブルの記録も、すべて筆者が実際に経験した内容です。「AI が書いた」という事実を隠さず、むしろ「どのように作ったか」を開示することが信頼性の根拠になると考えています。
同じような