Quotidia は 2026 年 5 月 17 日から 6 月 12 日までの 27 日間、AI ニュースメディア「AI Quotidia」を生成 AI 主体のほぼ全自動体制で毎日運用し、サイト 942 PV・読者 345 人・SNS 転載を含む総リーチ 13,166・現金コスト月額実費 約 2,400 円という実測値を得ました。PV (ページビュー) とは、ページが表示された回数のこと。総リーチは、本体サイトと SNS・転載先を合わせた「見られた回数」の合計です。この記事は、その全データを公開する実験レポートです。うまくいった部分だけを切り取らず、「うまくいかなかったこと」も原因までそのまま載せています。

先に正直にお伝えすると、検索からの流入は 27 日間で 23 セッションでした。セッションとは、読者がサイトを訪れてから離れるまでの「ひとまとまりの訪問」のこと。しかも直近 7 日間に限れば 0 です。「AI で月◯万円」という話を期待して開いた方には、がっかりさせてしまう数字かもしれません。でも、これから AI でブログやメディアを始めたい人に本当に必要なのは、景気のいい話よりも「実際にやってみたら何が起きるのか」の正直な記録ではないでしょうか。Quotidia はそう考えて、この記事を書いています。

この実験で確かめたかったこと

確かめたかった問いは、次の 3 つです。

  1. 生成 AI 主体の編集部は、人の作業をどこまでゼロに近づけられるか — 記事を書く・公開する・SNS に流す・数字を測る。これを全部 AI と自動化に任せたとき、人に残る仕事は何でしょうか
  2. ゼロから始めた個人メディアは、最初の 1 か月でどこから読まれるか — 検索なのか、SNS なのか、それとも記事の転載先なのか
  3. 全自動運用の本当のコストはいくらか — 毎月のお金と、数字には出てこない手間 (とくに、事故が起きたときの対応) の実態

なお、Quotidia の編集部では役割の異なる複数の AI エージェントが、執筆・レビュー・実装・分析を分担しています。この体制そのものの失敗談は Zenn の連載「Claude Code 実践記 — 失敗だらけのAI組織運営」で個別に掘り下げているので、この記事ではメディア運用の実測データに集中します。

どんな条件でやったのか — 実験の方法

まず、実験の条件から。この先に出てくる数字はすべて、ここに書いた条件のもとでの実測値です。「自分の場合はどうなりそうか」を考えるときの照らし合わせにお使いください。

毎日なにを、どこへ届けていたのか

項目 内容
期間 2026-05-17 〜 2026-06-12 (27 日間・本稿のデータ取得は 2026-06-12 15:20 JST)
本体サイト WordPress (独自ドメイン ai.quotidia.jp)・新規取得ドメイン
更新頻度 開設日に 14 本を一括公開、翌 5 月 18 日以降は毎朝 6 時に 1 本ずつ自動公開 (26 日間無休)
記事形式 海外 AI ニュースの日本語解説。同一記事を「解説・速報・文豪」の 3 文体で提供する読者選択型
転載先 X・Threads・Qiita・Zenn・note の 5 媒体に自動配信
通算公開本数 40 本 (うち開設日の一括 14 本は、のちに品質基準を満たさないと判断し 6 月 10 日に非公開化。現在公開中は 26 本)

「独自ドメイン」とは、サイト専用に取得したインターネット上の住所のことです。あとで詳しくお話ししますが、この「新規取得」(= 検索エンジンからまだ信頼されていない、まっさらな状態) という条件が、結果に大きく影響しました。

記事が毎朝ひとりでに出ていくまで — 自動化のしくみ

しくみの全体は「収集 → 生成 → 公開 → 転載 → 計測」の 5 段です。

  1. 収集: 海外の AI ニュースを RSS (サイトの更新情報を自動で受け取るしくみ) で巡回し、記事候補を毎日リストアップします
  2. 生成: 生成 AI が候補から 1 本を選び、解説・速報・文豪の 3 文体で原稿を起案します。タイトル・要約・タグなどの付随情報もまとめて生成します
  3. 公開: ワークフロー自動化ツールが毎朝 6 時に WordPress の API (プログラム同士がやり取りするための窓口) を呼び、本体サイトに公開します
  4. 転載: X・Threads・Qiita・note へは各媒体の公式 API で投稿します。Zenn だけは方式が違い、GitHub (ファイルの保管・共有サービス) にファイルを送ると自動で記事として公開される連携方式です
  5. 計測: GA4 (Google の無料アクセス解析ツール) と各媒体の API から毎日数値を取得し、ダッシュボードに集約します

設計でこだわった点がひとつあります。生成 AI の原稿をそのまま公開せず、起案した AI とは別の AI エージェントが事実関係・数値・トーンを確かめるレビュー工程を挟んでいることです。それから、配信経路が「API 直接投稿」と「リポジトリ連携」のふた通りある点は、あとで効いてきます。失敗の出方が、媒体ごとに違ったのです (後述の失敗 4・5)。

どこまで自動化できて、なにが人に残ったのか

自動化できたのは、ニュース候補の収集・記事生成・毎朝 6 時の本体公開・5 媒体への転載・アクセス集計のダッシュボード化まで。つまり「書いて、出して、測る」は、ほぼ全部です。それでも、人 (運営) に残った作業が次の 4 つありました。

  • 記事の公開前レビュー — 起案した AI とは別の AI エージェントによる検証を経て、最後は運営 (人) が承認します
  • アイキャッチ画像の生成と確認
  • 配信結果の毎朝の確認 (ちゃんと公開されたか・壊れていないか)
  • 事故対応 — あとで詳しく書きますが、これが想定よりはるかに大きい仕事でした

作業時間の定量記録は取っていないため、本稿では時間数を示さず、作業項目のみを挙げています (時間計測は次回レポートの課題です)。

毎月いくらかかっているのか

毎月の現金支出は、実費ベースで約 2,400 円です。内訳は次のとおり。

  • レンタルサーバー: 3 か月パック 3,993 円 (税込) の月割で 1,331 円
  • X の API 利用料: 約 1,000 円
  • ほかにドメイン代

広告収益は 0 円なので、毎月この金額がそのまま持ち出しになります。なお、記事を生成する AI の利用料はこの金額に含めていません。定額契約の AI 環境をほかの用途と共用していて、この実験だけで増えた分を切り出せないためです。

どれくらい読まれたのか — 実測データ

お待たせしました。ここからが実測データです。

まず全体の数字から (2026-06-12 15:20 JST 取得時点・GA4 ほか各媒体公式 API)

指標 実測値
本体サイト PV (27 日間累計) 942
ユーザー数 345 人
セッション数 506
平均エンゲージメント時間 191.9 秒
SNS・転載先を含む総リーチ 13,166 (本体 942 + 転載先 12,224)
自然検索からの流入 23 セッション (全体の約 4.5%)
現金コスト 月額実費 約 2,400 円
収益 0 円

表の見方をひとことだけ。「平均エンゲージメント時間」は、読者が実際にページを見ていた時間の平均です。来てくれた読者は、それなりにじっくり読んでくれている——そう読める数字です。

ここで、計測についての正直な注記を 2 点。第一に、計測タグの設定ミスで運用前半に PV の二重計上 (同じ閲覧を重ねて数えてしまうこと) があり、6 月上旬に是正しました。そのため期間前半の PV は、実態よりやや多く出ている可能性があります。第二に、流入の 64% を占める「Direct」(どこから来たか分からない訪問) には、運営自身の確認アクセスや RSS リーダー経由が混ざっていると Quotidia は判断しています。つまり、純粋な読者数は表の数字より少ないとみるのが誠実です。

PV はどう動いたか — 初速、踊り場、失速

この表で見てほしいのはひとつだけ。「右肩上がりではない」ということです。

局面 期間 1 日あたり PV
開設直後 5/17〜5/18 71 → 111 (ピーク)
踊り場 5/24〜6/2 16〜62 (反応のある日は 40〜60 台)
失速 6/10〜6/12 6 (3 日連続。6/12 は取得時点 15:20 までの値)

GA4 の日次実測では、開設翌日の 5 月 18 日に 111 PV を記録したのが全期間のピークでした。その後は、SNS 告知に反応がある日だけ 40〜60 台の PV に届く踊り場が続きます。そして 6 月 10 日以降は、3 日連続で 1 日 6 PV まで落ちました。開設日にまとめて公開し、その後 26 日間毎朝 1 本の公開を休まず続けても、右肩上がりにはならない——これが新規ドメインの 1 か月目の現実でした。毎日続ければきっと伸びるはず、と思っていた方にはつらい推移かもしれません。Quotidia にとっても、正直こたえる数字でした。

読者はどこから来たのか — 流入チャネル

次は、読者の入り口です。この表で見てほしいのは、最大の入り口が「どこから来たか分からない訪問」だという点です。

参照元 セッション 補足
Direct (参照元不明) 324 自己アクセス・RSS 含む可能性が高い
X 関連 47 x 37 + 短縮 URL (t.co) 10
Google 29 自然検索 20 + 「cpc」分類 9 (下記の注記参照)
Qiita 29 転載記事からの誘導
Threads 12
Bing (自然検索) 3
Zenn 2
note 1

1 点、正直に注記します。Google の内訳には、GA4 上「cpc (クリック課金広告)」と分類された 9 セッションが含まれていますが、Quotidia は広告をいっさい出稿していません。9 セッションすべてが直帰率 100% (直帰率 = 最初のページだけ見てすぐ帰った訪問の割合) である点も不自然で、計測上の誤分類とみています。本連載は計測の限界も含めて開示する方針なので、数字から除外せず、注記つきで残します。

数より面白いのは、「質」のほうです。GA4 の参照元別直帰率を媒体単位で合算すると、Qiita 経由は 20.7% (n=29)、Threads 経由は 66.7% (n=12)。最大セグメントである Direct の 59.6% (n=324) と比べても、Qiita の低さが際立ちます (n は対象セッション数)。Qiita で記事を読み終えて、それでもわざわざ本体まで来てくれる読者は、最初から関心が深いからです。流入チャネルは「量」と「質」、別々の軸で見る必要がある——これは実測してはじめて腑に落ちたことでした。

5 媒体の累計リーチ — 本体の 11 倍が転載先で読まれた

この表で見てほしいのは、Qiita の行です。

媒体 累計 (2026-06-12 15:20 取得時点) 反応
Qiita (転載 27 本) 10,651 PV いいね 4
note 419 ビュー スキ 57
X (記事の自動投稿 28 本) 356 インプレッション いいね 2
Zenn (記事) 482 PV + 連載本 47 PV いいね計 17
Threads 316 ビュー いいね 28・フォロワー 5

※ 冒頭サマリーの総リーチ 13,166 には、Zenn の連載本 (47 PV) を含めていません (記事の転載ではない Zenn 独自コンテンツのため)。この表の合算 + 本体 942 = 13,213 との差 47 はこの分です。

本体サイトの 942 PV に対し、Qiita 転載版だけで 10,651 PV。自前のサイトの 11 倍以上が、他社プラットフォーム上で読まれたことになります。ただ、これは素直に喜べる数字ではありません。あとで詳しく書きますが、検索エンジンまで本体ではなく Qiita 版を拾うようになり、「本体サイトを育てる」という当初の目的とは逆の構造ができてしまったからです。

一方で、媒体ごとの「反応の質」もくっきり分かれました。Qiita は 1 万 PV を超えても「いいね」は 4 にとどまる。note は 419 ビューに対しスキ 57。読み流される媒体と、少数でも反応が返ってくる媒体。この性格の差も、実測してはじめて分かったことです。

どんなふうに読まれたのか — 文体・端末・AI クローラー

  • 文体モード: 3 文体の閲覧イベント計測 (n=39 と小さな標本ですが) では、村上春樹的な文体で書く「文豪」が 24 回、標準の「解説」が 14 回、「速報」が 1 回でした。ニュースサイトなのに、いちばん読まれた文体が、いちばんニュースらしくない文体だったのです。
  • 端末: セッションの約 74% がデスクトップ (377) で、モバイルは 123。技術系の読者層を反映しているとみています。
  • AI クローラー: クローラーとは、検索エンジンなどがサイトの情報を集めるために巡回させているプログラムのこと。サーバーログの実測では、直近 7 日間に AI 系ボットが 31 回来訪しました。うち純粋な AI クローラー (GPTBot 8・ClaudeBot 1・OAI-SearchBot 1) は 10 回で、残る bingbot 21 回は Bing 検索と AI の兼用クローラーです。人間の検索流入より先に、AI がコンテンツを取りに来ている——いまの Web のリアルです。AI 検索経由で引用されるかどうかは、今後の観測課題にします。

うまくいかなかったこと

ここからが、この記事の核です。運用記録 (インシデント台帳 = 事故やトラブルの記録簿) には、27 日間で 10 件を超える事故・不具合が残っています。ここでは、構造的な失敗 2 つと、代表的な事故 3 つを、原因まで開いてお見せします。

失敗 1: 検索流入は 27 日間でほぼゼロ。しかも検索に出るのは転載先だった

自然検索からの流入は、27 日間の累計で 23 セッション (Google 20・Bing 3)。直近 7 日間に限れば 0 セッションです。毎日更新を 1 か月近く続けても、新規ドメインは検索からほぼ見えませんでした。

さらに困ったことがあります。検索結果に出るのは、本体サイトではなく Qiita の転載版だったのです。検索エンジンは「同じ内容なら、より信頼しているサイトのほう」を選びます。生まれたての独自ドメインと、長年の実績がある Qiita。同一コンテンツが並べば、本実験では一貫して本体が負けました。「SNS で初速を稼ぎつつ、転載で露出を増やし、検索が育つのを待つ」という設計は、転載が本体の検索評価を食うという副作用を見落としていたのです。

失敗 2: X の自動投稿は、人の投稿の 17 分の 1 しか届かなかった

X アカウント全体では 103 投稿で 16,538 インプレッション (インプレッション = 投稿が表示された回数) でした。一見、悪くなさそうに見えますよね。ところが内訳を分けると、見え方が一変します。

投稿の種類 本数 インプレッション 1 本あたり平均
記事告知 (自動投稿) 28 356 約 13
手動の投稿・返信 75 16,182 約 216

記事 URL つきの自動投稿は 1 本平均 13 インプレッション。一方、人がほかのアカウントの話題に返信した投稿は平均 216 で、約 17 倍の差がつきました。X 上のリーチの 98% は、自動化していない部分が稼いでいたことになります。配信は自動化できても、会話と関係は自動化できない——これが実測の示した結論です。

失敗 3: 信頼性のための再実行が、同じ記事を 3 回投稿した

6 月 1 日、同じ記事が 3 回投稿される事故が起きました。引き起こしたのは、公開処理の信頼性を上げるために入れていた監視・バックアップ系のしくみです。「失敗していたら、もう一度実行する」という再実行のしくみに、「すでに投稿済みなら何もしない」という重複排除の保証 (これを冪等性といいます) が入っていませんでした。失敗に備えたはずの冗長化 (念のためのしくみを重ねておくこと) は、冪等性を欠いたまま動くと、それ自体が事故装置になります。対応として、重複判定が機械的に保証できるまで自動再実行を止め、「判定できないときは投稿しない」側に倒しました。

失敗 4: 引用符 1 組が、Zenn の全記事公開を 1 日半サイレントに止めた

Zenn への転載は、GitHub リポジトリ連携で自動公開しています。ある日、記事のタイトルに含まれていた二重引用符 1 組が、記事のメタデータ (タイトルや日付などを機械が読める書式 = YAML で書いた部分) の構文エラーを起こしました。その結果、1 ファイルの破損で全ファイルの公開が停止。しかもエラー通知を監視していなかったため、約 1.5 日間、誰も気づきませんでした。

教訓は 2 つです。生成 AI が書くタイトルは引用符や記号をふつうに含むので、機械生成するメタデータには必ずエスケープ処理 (記号を安全な形に変換する処理) を通すこと。そして、「失敗したら気づくだろう」は成立しないこと。サイレント失敗 (誰にも知られないまま静かに起きる失敗) は、検知を設計しない限り日単位で発見が遅れます。

失敗 5: 「2 日に 1 回」に間引いたのに、投稿制限を踏んだ

Zenn の投稿制限を避けるため、記事を 2 日に 1 回へ間引いていました。それでも、公開が止まりました。ちゃんと減らしたのに、なぜ? ——git のログ (作業履歴) を時刻つきで検証して、ようやく分かりました。原因は記事の本数ではなく、push の回数だったのです。push とは、ファイルの変更をリポジトリ (ファイル置き場) へ送り込む操作のこと。復旧用の空コミット、修正のやり直し、別コンテンツの更新が同じリポジトリで短時間に重なり、ある日は 1 日 4 push。プラットフォーム側からは、スパム的な連投に見えていたわけです。

プラットフォームの制限は、自分が意図する単位 (記事数) ではなく、相手が数える単位 (操作回数) で測られます。対策として「直近 push から 20 時間以内は公開見送り」の機械ガードを入れ、空コミットでの再実行を禁止しました。

うまくいったこと (公平のために)

失敗ばかり並べましたが、公平のために、うまくいったことも書いておきます。

  • 毎朝 6 時の自動公開を 26 日間、無休で続けられた。継続そのものは、人の意志力に頼らなくても、しくみで達成できます。これは自動化の確かな成果です。
  • Qiita 転載は 27 本で 10,651 PV。プラットフォームの集客力を借りる戦術は、露出という意味では機能しました (先ほど書いた副作用つきで、ですが)。
  • 文体という差別化には反応があった。小さな標本ながら「文豪」モードがいちばん選ばれ、note では少数でも濃い反応 (スキ 57) が返ってきました。
  • 品質基準で 14 本を自主的に非公開化する判断ができた。公開数を減らしてでも質を取る。その判定を、台帳とレビュー体制によって機械的に下せました。

27 日間から抽出した 7 つの法則

ここまでの個別の話を、読者のみなさんが自分の環境に持ち帰れる形にまとめます。

  1. 新規ドメインの検索流入は、1 か月では立ち上がらない。初月の集客は「SEO 以外」で設計しておくこと (実測: 27 日で自然検索 23 セッション・直近 7 日 0)。
  2. 転載は露出と引き換えに、本体の検索評価を食う。権威の低いドメインと高いプラットフォームに同一コンテンツを置けば、検索に出るのは後者になる。
  3. 全自動化しても工数はゼロにならず、種類が変わる。執筆の工数が消えた分、事故対応と検証が人の仕事になる (27 日間で記録された事故・不具合は 10 件超)。
  4. 冗長化は冪等性とセットでなければ事故装置になる。再実行・バックアップ系には「実行済みなら何もしない」保証を先に入れる。
  5. サイレント失敗は、検知を設計しない限り日単位で発見が遅れる。「公開した」ではなく「公開されたことを機械が確認した」を毎日の完了条件にする。
  6. プラットフォームの制限は、相手が数える単位で測られる。記事数を間引いても、操作回数 (push・API 呼び出し) がバーストすれば制限を踏む。
  7. 配信は自動化できても、関係は自動化できない。SNS のリーチの大半は自動投稿ではなく、人の対話が生む (実測: X の平均インプレッションで 17 倍差)。

ただし、これらは 1 メディア (n=1)・27 日間の観測から抽出した法則で、適用には条件があります。前提は「新規取得ドメイン」「AI ニュースという技術系ジャンル」「日本語圏」「Qiita・Zenn 等の権威性が高いプラットフォームへの全文転載あり」。法則 1〜2 は、既存ドメインでの運用や、転載を要約 + リンクにとどめる設計なら、結果が変わりえます。一方、法則 4〜6 (冪等性・サイレント失敗・操作回数) は自動化システム一般の性質なので、メディア運用以外にもそのまま当てはまると考えています。

これから AI でメディアを自動運用する人へのチェックリスト

最後に、これから始める方が同じ穴に落ちないためのチェックリストです。

  • 初月の流入は SNS とプラットフォーム転載で設計する (検索は当てにしない) — 本実験の実測は 27 日で自然検索 23 セッション。集客の計算に入れられる量ではありませんでした
  • 転載するなら「本体と転載先のどちらを検索に出したいか」を先に決める — 全文転載は本体の検索評価と競合します。本体を育てたいなら、転載を要約 + 本体リンクにとどめる設計も選択肢でした
  • 自動公開には重複排除 (冪等性) を最初から組み込む — 「再実行しても結果が変わらない」保証のない再実行は、信頼性ではなく事故を増やします
  • 「公開の成否を機械が毎日確認する」しくみを公開フローと同時に作る — サイレント失敗の発見が人の注意頼みだと、日単位で遅れます
  • 機械生成するメタデータ (タイトル等) は必ずエスケープ処理を通す — 生成 AI は引用符や記号をふつうに出力します
  • 外部サービスの制限は記事数でなく操作回数で計測する — 制限を数えるのは相手側で、単位は API 呼び出しや push の回数です
  • アクセス計測は二重計上とページング欠落を疑い、合計を元データと突合する — 本実験では両方が実際に起き、是正前の数字は過大でした
  • 月の固定費と「やめる基準」を始める前に文章化しておく — 月 2,400 円でも収益 0 なら、基準がないと「なんとなく継続」が続きます

まとめ（FAQ）

Q. AI でブログを全自動運用すると、初月はどのくらい読まれますか?
A. Quotidia の実測 (2026 年 5〜6 月・27 日間) では、本体サイト 942 PV・読者 345 人、転載先を含む総リーチ 13,166 でした。ピークは開設翌日の 111 PV/日で、最終 3 日間は 6 PV/日まで落ちています (最終日はデータ取得時点 15:20 までの値)。

Q. 検索流入はどのくらいで発生しますか?
A. 本実験では 27 日間で自然検索 23 セッション、直近 7 日間は 0 でした。新規ドメインの初月に検索流入は実質的に期待できず、しかも検索に出たのは本体ではなく Qiita 転載版でした。

Q. 費用は月いくらかかりますか?
A. 実費ベースで月約 2,400 円 (サーバー 1,331 円 + X API 約 1,000 円 + ドメイン) でした。収益は 0 円のため、全額が持ち出しです。記事を生成する AI の利用環境は別途必要です。

Q. 全自動運用でいちばん大変なことは何ですか?
A. 執筆ではなく、事故対応です。27 日間で 3 重投稿・1.5 日のサイレント公開停止・投稿制限など 10 件超の事故が記録されました。自動化は工数をゼロにするのではなく、人の仕事を「書く」から「検証して直す」に変えます。

データの出典と計測方法

本稿の数値は、いずれも 2026-06-12 15:20 JST 時点の取得値です。

  • 本体サイト: GA4 実測 (計測タグの二重計上は 6 月上旬に是正済み。前半の PV はやや過大の可能性あり)
  • 各媒体: Qiita API・note 統計 API・Zenn 統計・X API・Threads Graph API による全件取得 (集計のページング欠落は検出のつど修正済み)
  • 公開本数・体制: Quotidia の記事管理台帳
  • 事故記録: Quotidia のインシデント台帳および git 履歴 (時刻つきコミットログ)

数値は今後も変動します。本稿は「2026 年 5 月 17 日〜6 月 12 日の 27 日間」のケーススタディとして固定し、運用を継続した場合は 3 か月版として続報を出す予定です。