私のブログ（show-zeet.com）は、平日15時45分になると、誰も何もしなくても記事を1本書いて公開します。株価データの取得からClaude Codeによる本文生成、ファクトチェック、チャート画像の作成、WordPressへの投稿まで、すべて自宅のMac miniの上で完結する全自動です。
このブログは2026年4月30日に開設し、約2ヶ月半で64記事を公開しました。うち48本は、この仕組みが自動生成した相場記事です。そして先日、GoogleのAdSense審査で一発不合格になりました。理由は「有用性の低いコンテンツ」。
この記事は、その全記録です。仕組みの中身も、投稿が4回連続で止まった夜も、審査に落ちた話も、そこから何を変えたかも、そのまま書きます。「AIで自動化したら儲かった」という話ではありません。現時点の収益はゼロです。それでも、これから同じことを考える方には読む価値があるはずです。
そもそもなぜ自動化したか — 大引けの15時30分、私は会社にいる
出発点は、会社員として身も蓋もない制約でした。東京株式市場の大引けは15時30分。その日の相場を振り返る記事は鮮度が命なのに、その時間、私は会社にいます。夜に帰宅してから書くと、書き終わる頃には日付が変わりかけている。実際、手動で書いていた時期は「今日はもう疲れたから明日でいいか」が積み重なり、更新は止まりかけました。
継続できないなら、継続できる仕組みを作るしかない。幸い、私は普段からVS CodeとClaude Codeで開発をしていたので、「記事を書く作業そのものをコードにしてしまおう」と考えました。目指したのは、大引け直後の一番鮮度が高い時間帯に、私が会社にいても記事が出る状態です。
結論から言えば、それは実現しました。ただし「実現した」と「うまくいった」は別の話です。まず、実現した側の中身から説明します。
大引けの15分後に記事が生まれる — パイプラインの6工程
大引けの15分後の15時45分、自宅で24時間稼働しているMac mini（M4）の上でスケジューラーが起動し、6つの工程を順番に実行します。日次記事は平日15時45分、週のまとめ記事は金曜18時です。
工程は次の通りです。①外部APIから株価・ニュースデータを取得（J-Quants、Yahoo Finance、株探のニュース見出し）。②Claude CodeのHeadless Mode（コマンドラインからAIを呼び出す方式）で記事本文を生成。③生成された記事をプログラムでファクトチェック。④チェックNGならAI自身に修正させて再チェック。⑤チャート画像とサムネイルを生成。⑥WordPressのREST APIで投稿。
本文は8セクション構成で、その日の日経平均の動き、注目イベント、売買代金上位の話題銘柄、個別銘柄の深掘りなどを含みます。金曜だけは「明日の注目イベント」が「来週の展望」に自動で切り替わるよう、JPXの公式カレンダー（祝日対応）から翌営業日を計算しています。画像も、日経平均の分足・日足チャート、個別銘柄のチャート、売買代金上位50銘柄を前日比の色で敷き詰めたヒートマップ、1200×628ピクセルのSNS用サムネイルまで、全部Pythonで描いています。細かい話ですが、チャートの色は日本の株式慣習に合わせて「上昇=赤、下降=青」で統一しました。海外製の描画ライブラリのデフォルトは逆（上昇=緑）なので、日本の読者向けには直す必要があったのです。
生成ルールでひとつだけ譲らなかったのは、「ニュース見出しの裏付けが取れない銘柄については、値動きの理由を書かない」ことです。AIは「好決算で買われた」といった、もっともらしい理由を裏付けなく作文することがあるからです。理由が確認できないなら書かない。この割り切りが、後述するファクトチェックとあわせて、AI生成記事の信頼性を守る生命線でした。
作る過程でも、想定通りにいかないことは山ほどありました。たとえば決算発表スケジュール。当初使う予定だったデータAPIの該当機能が実質的に機能しておらず、結局、株探の決算カレンダーから取得する方式に切り替えました。ただしそこで取れるのは直近1営業日分のみ。仕様の制約に合わせて、記事側のラベルを「本日引け後発表」「翌営業日予定」と分ける形で吸収しました。外部データは「ドキュメント上できること」と「実際にできること」が違う。これは何度も経験しました。
地味な事故もありました。スケジューラーを改良していくうちに、OS側のジョブ登録とプログラム内のスケジューラーで同じ処理が二重に登録されていたり、過去のフォルダ構成時代の「もう存在しないパス」を指したままのジョブが残っていたり。動くには動く、あるいは静かに失敗するだけなので気づきにくく、後の総点検で重複していた4本のジョブを廃止して一本化しました。自動化は「作る」より「把握し続ける」方が難しい、というのが正直な実感です。
ここまで読んで「よくできた仕組みだ」と思っていただけたなら、嬉しいです。私もそう思っていました。ここから先が、その仕組みが本番で実際に転んだ記録です。
全角スペースの「Ｔ Ｄ Ｋ」が投稿を4回止めた夜
システムを本格稼働させた初日のことです。15時45分に生成された日次記事は3,138字。数値の整合性チェックも、文字数も、禁止語検出も、すべて合格していました。それなのに、記事は公開されませんでした。
止めたのは、記事中の企業名を取引所の銘柄マスタと照合するチェックでした。記事には「TDK」と書かれていた。ところがマスタ上の正式表記は、全角文字で空白まで入った「Ｔ Ｄ Ｋ」。プログラムはこの2つを別の会社と判定し、「事実と異なる可能性がある」として投稿を中止したのです。リトライも3回すべて同じ理由で止まり、その日の記事は計4回の投稿中止の末、公開されませんでした。
原因は、照合処理が全角・半角の表記ゆれを正規化していなかったこと。人間なら1秒で同じ会社だと分かる表記を、プログラムは律儀に「別物」と扱いました。しかも掘り下げると、このチェックは前日までデータの読み込み不備で銘柄マスタが空のまま照合をスキップしており、別の修正でマスタ4,451銘柄が正しくロードされた途端、潜んでいた表記ゆれ問題が一斉に表面化した——という経緯でした。バグを直すと、隠れていた次のバグが顔を出す。自動化システムではよくあることです。
修正自体は、文字列の全角・半角を正規化する処理を加える類のものです。あわせて、チェックNGのときにAI自身へ修正を指示し、再チェックする自己修復ループも整備しました（最大3サイクル。それでも通らなければ投稿しない）。
もうひとつ、この夜には恥ずかしい発見がありました。投稿が止まったことを知らせる通知を、仕込んでいなかったのです。記事が公開されていないことに、私は自分でサイトを見に行って気づきました。全自動を名乗りながら、失敗だけは手動で発見する仕組みだったわけです。以後、投稿中止やリトライ上限には必ず通知を飛ばすようにしました。
この一件は誤検知でしたが、私は「止める」設計自体は今も正しかったと思っています。「疑わしければ公開しない」が、初日から機能した証拠だからです。AIの誤りは機械が止める。機械の誤りは人間が直す。そして失敗は必ず人間に知らせる。この夜に学んだ分担は、その後もずっと効いています。
ただし、次の事故はこの品質ゲートの外側——公開された「後」で起きました。
7月3日のサムネイルが、7月6日の記事に現れた
ある日の夜、公開済みの日次記事をスマートフォンで開くと、サムネイルと本文中の画像が3日前の記事のものになっていました。奇妙なのは、パソコンで見ると正しい画像が表示されることです。サーバーの配信内容を直接確認しても正しい。つまり「サーバーは正しいのに、一部の端末だけ古い」という状態でした。
原因をたどると、画像のファイル名にありました。日次記事の画像は「thumbnail_daily.png」のような日付なしの固定名でアップロードしていたのです。事故の経路はこうです。7月3日にテスト生成した記事を削除した際、その画像も消えてファイル名が空席になった。7月6日の記事が同じ名前を再取得した結果、同じURLのまま中身だけが入れ替わった。そして画像には7日間のキャッシュ設定が付いていたため、7月3日にそのURLを一度読み込んだ端末は、古い画像を最大7日間表示し続けた——という流れです。
修正は、すべての画像ファイル名に日付を入れて一意にすることでした。新しいURLはどの端末のキャッシュにも汚染されていないため、即座に正常化しました。教訓として書き残したのは、「配信サーバーは正しいのに閲覧者だけ古いときは、URLの中身が過去に入れ替わった履歴を疑う」こと。コマンドラインでの検証はブラウザのキャッシュを再現しないので、「curlで確認したから大丈夫」は当てになりません。
表記ゆれもキャッシュも、突き詰めれば技術で潰せる問題でした。しかし3つ目は違いました。技術では返せない指摘が、Googleから届きます。
AdSense一発不合格 — 理由は「有用性の低いコンテンツ」
64記事まで積み上げたところでAdSenseに申請し、結果は不合格でした。理由はポリシー用語で「有用性の低いコンテンツ」。要するに、広告を載せる価値のあるサイトとは認められなかったということです。
正直にショックでした。データは正確で、ファクトチェックまで通し、毎日欠かさず更新している。それでも落ちた。しかし冷静に自分のサイトを見直すと、反論できませんでした。64記事のうち48本は、同じ型で自動生成された相場記事です。数値は正しくても、そこに「このサイトでしか読めないもの」はあったか。Googleの機械と人間の目には、機械的に量産されたページの集まりに見えたはずで、実際その通りだったのです。
思い当たる節は、実は審査の前からありました。パイプラインを作り込んでいる間、私の関心は「いかに正確に、いかに自動で記事を出すか」に集中していて、「この記事は誰の何を解決するのか」を突き詰めた記憶がほとんどないのです。ファクトチェックは嘘を止めてくれますが、「正確だが誰の役にも立たない記事」は止めてくれません。品質ゲートの設計思想そのものに、読者という視点が抜けていました。
皮肉な話だと思います。AIに記事を書かせる仕組みを磨き上げた結果、たどり着いたのは「量産されたコンテンツは評価されない」という、当たり前の壁でした。自動化の完成度と、読者にとっての有用性は、まったく別の軸だったのです。現在はサイトを改善して再挑戦の準備中ですが、この不合格は仕組みのバグではないので、コードを直しても解決しません。直すべきはコンテンツ戦略そのものでした。
48本量産して分かった「量は検索に勝てない」
相場の振り返り記事には、構造的な弱点があります。鮮度が命で、翌日には価値が薄れること。そして同じ情報は、証券会社や大手メディアがより速く、より厚い体制で発信していることです。個人ブログが自動化で本数を稼いでも、この土俵では勝負になりません。48本を並べてみて、ようやくそれを認めました。
では何なら書けるのか。考え抜いた末の答えは、拍子抜けするほど近くにありました。この2ヶ月半、私は「会社員がAIでブログ運営を自動化するとどうなるか」という実験を、お金と時間を実際に払って続けてきたのです。システムをどう作り、どこで転んだか。全角スペースに投稿を止められた夜も、キャッシュ事故の顛末も、審査に落ちた理由の五文字も、私しか書けない一次情報です。
そこで方針を転換しました。自動化パイプラインは「毎日更新を絶やさない土台」として維持しつつ、サイトの柱は、体験に基づく一次情報の記事に移す。実は、いまお読みいただいているこの記事こそ、その方針転換の第1弾です。48本の自動生成記事が検索で戦えなかった経験そのものを、49本目ならぬ「人間が書く側」の記事に変える。それが現時点の私の答えです。
誤解のないように書くと、自動化が無駄だったとは思っていません。データ取得もファクトチェックも画像生成も、質重視の記事作りを支える道具として毎日働いています。変わったのは、自動化を「主役」から「裏方」に配置し直したことです。
収益ゼロの帳簿 — かかった費用と時間の実感
お金の話も避けずに書きます。具体的な金額は契約プランで変わるため概要にとどめますが、支出は大きく3つです。24時間稼働の自宅サーバーとして買ったMac mini（M4）。これが一番大きな初期投資でした。次に、Claude Codeの定額上位プラン（Max Plan）。毎日自動でAIを呼び出すシステムでは、従量課金で青天井になる不安がない定額制が精神的に大きいです。最後に、株式データAPIの有料プラン。無料の範囲でも始められますが、データの質と安定性を優先しました。
月々の固定費は「趣味としては高め、事業の先行投資と考えれば許容範囲」というのが率直なところです。そして繰り返しになりますが、収益は現時点でゼロ。AdSenseには落ち、アフィリエイトで稼げているわけでもないので、完全に持ち出しです。ここをぼかして「自動化で不労所得」のように書くことはしたくありません。
時間はもっと注ぎ込んでいます。構想からひと通り動くまで、平日の夜と週末をかなり使いました。「自動化すれば楽になる」は事実ですが、正確には「構築と保守に大量の時間を前払いして、日々の執筆時間をゼロにする」取引です。前払いした分を回収できるかは、どれだけ長く続けるかにかかっています。
これから自動化する人へ — 実体験から言える3つのこと
同じことを考えている方へ、経験した範囲のことだけを書きます。
- 自動化はゴールではありません。 記事が自動で公開された日は感動します。しかしそれは配信の仕組みができただけで、読まれる理由はまだ1行も作れていません。私はここを取り違えて、64記事と一発不合格という授業料を払いました。
- 公開を自動化するなら、品質ゲートを先に作ってください。 AIは自信満々に間違えます。数値の整合性チェックと「裏付けのないことは書かせない」ルール、そして疑わしいときに投稿を止める仕組み。私のブログが誤情報を公開せずに済んでいるのは、4回投稿を止めたあの口うるさいチェックのおかげです。
- 審査は甘くありません。 自動生成コンテンツへのGoogleの目は厳しく、正確さだけでは「有用」と認められませんでした。収益化を前提に始めるなら、審査に落ちても続けられる動機がもうひとつ必要です。私の場合は「作ること自体が楽しい」「技術が身につく」でした。そう思えない人には、正直つらい投資だと思います。
なお、プログラミング経験がない方には、ここまでの道のりはかなり険しいことも付け加えておきます。Claude Codeはコードを書いてくれますが、エラーの切り分けやサーバー運用の判断は自分でやることになります。まずは「AIに下書きを作らせて自分が確認して投稿する」半自動から始めるのが現実的です。私も下書き保存までの自動化から段階的に進めました。
まとめ
- 平日15時45分の日次記事と金曜18時の週次記事を、データ取得→Claude Code生成→ファクトチェック→AI自己修復→画像生成→WordPress投稿の6工程で全自動化
- 開設約2ヶ月半で64記事、うち48本が自動生成。一方で、表記ゆれ誤検知による4回の投稿中止、画像キャッシュ事故、AdSense一発不合格（有用性の低いコンテンツ）を経験
- 学びは「量は検索に勝てない」。自動化は裏方に回し、体験に基づく一次情報の記事へ方針転換。この記事がその第1弾
AdSenseの再挑戦がどうなったかも、結果が出たら正直に書きます。うまくいってもいかなくても、それ自体がこのブログにしか書けない記事になるはずです。
※本記事は筆者の個人的な体験記であり、特定のツールやサービスの利用を勧誘するものではありません。株式投資に関する記述は情報提供を目的としたものであり、投資判断はご自身の責任でお願いします。
コメント