少し前まで、ブログの読者を増やす王道はGoogle検索で上位を取ることでした。ところが最近は、検索結果の上にAIが要約を出すようになり、わざわざ記事をクリックしなくても答えが分かる場面が増えてきました。
検索からの流入だけに頼っていると、これからは少しずつ苦しくなるかもしれません。そこで以前、検索に頼らない経路としてXへの自動投稿を仕組み化しました(その土台は前回の記事 で解説しています)。
ただ、土台ができると、今度は別の悩みが出てきました。その悩みは、次のような点です。
- 投稿する記事の順番を決め打ちにすると、世の中の話題とズレた発信になってしまう
- かといって毎朝ニュースを見て手で選ぶのは、手間が大きくて続かない
そこでたどり着いたのが、「何を投稿するか」を選ぶ役割をAI(Claude)に任せるという形です。毎朝その日のニュースを読ませ、話題に合った自分の記事を1本選ばせて、投稿文まで作らせています。
この仕組みは一度作り直しています。最初はパソコンでClaude Codeを開いている朝しか動かない作りでしたが、いまはパソコンの起動と関係なく、毎朝サーバー側で自動的に動きます。本記事では現在の形を説明したうえで、なぜ・どう変えたのかも書きます。
なぜこの部分をAIに任せたのか。投稿の「タイミングを守る」のは機械が得意で、「いまの話題に合わせて選ぶ」のは判断が要る作業だからです。判断が要る部分だけをAIに任せれば、人は毎朝ゼロから考えずに済みます。本記事では、その仕組みを実際の例も交えて確認していきます。
なお、この記事はコードを書けない方でも全体像が掴めるよう、「誰が・いつ・何をするか」に絞って解説します。特定のツールやサービスを「これを使えば稼げる」とおすすめする趣旨ではありません。
この記事でわかること
- 検索流入が減りSNSが重要になってきた、という時代背景
- なぜ「投稿内容を選ぶ」作業だけをAIに任せたのか
- 毎朝AIがやっている4つのステップ(ニュース収集→話題選定→記事選び→投稿文づくり)と、何を材料に選ばせているか
- 「パソコンを開いた朝しか動かない」という当初の弱点を、どう作り替えて外したか
- AIがうまく選べなかった朝でも投稿が途切れない「二段構え」の設計
- ニュースに連動して記事が選ばれた、実際の一例
背景:検索流入が減り、SNSが重要になった
まず前提として、ブログの読者をどこから連れてくるか、という地図が少しずつ変わってきています。これまで主役だったGoogle検索の比重を下げ、SNS(X)からの流入を意識する必要が出てきました。
理由は、検索結果の見え方が変わってきたことと、検索以外の経路を持っておく方が安全だからです。順に見ていきます。
検索結果がAIの回答に変わり、クリックが減ってきた
近ごろの検索では、検索結果の一番上にAIが要約した回答が表示される場面が増えてきました。利用者は、その要約を読んだだけで満足し、個別の記事までクリックしないことも多くなったとされます。
書き手の側から見ると、これは「検索で上位に出ても、以前ほどクリックされない」可能性があるということです。検索順位だけを追いかける戦い方は、同じ順位を取っても見返りが小さくなった、と捉えておくのが無難です。
もちろん、検索が無価値になったわけではありません。ただ、検索"だけ"に依存していると、検索の仕組みが変わったときに流入が一気に減ってしまうリスクがあります。だからこそ、別の経路を用意しておく意味があります。
代わりに伸びているのがSNS(X)からの流入
検索に依存しない経路として、現実的なのがX(旧Twitter)です。投資・資産形成の話題はXでも活発にやり取りされており、記事の要点を発信すれば、検索を経由しない人にも記事を届けられます。
ここで大事な気づきがあります。ブログ運営は「書く」工程だけでは完結しない、ということです。良い記事を書いても、それを「届ける」工程がなければ読まれません。Xへの発信は、この「届ける」工程にあたります。
つまり、これからのブログ運営は「書く」と「届ける」の二つの工程で考える必要があります。前回作った自動投稿の土台は「届ける」工程の自動化でした。今回の話は、その届ける中身を賢くする工程です。

なぜ「投稿内容を選ぶ」をAIに任せたのか
毎日の投稿を続けるうえで一番の負担になるのは、「何を投稿するか決めること」です。しかもそれは"いまの話題"に合わせる判断が要るため、この部分こそAIに任せたいと考えました。
理由は二つあります。手作業の負担と、決め打ちの限界です。
人が毎日投稿するのは手間
土台となる自動投稿の仕組みは前回作りました。ですが、その仕組みに「何を流すか」を供給するのは、結局のところ人の作業です。
具体的には、1日に複数回投稿するとなると、毎回これだけの作業が発生します。
- どの記事を紹介するか選ぶ
- 短い投稿文を考える
- 記事へのリンクを貼る
1回なら大した手間ではありません。ですが、これを毎日、しかも複数回となると話が変わります。地味ではあるものの、続けるうちに確実に重荷になる作業です。最初の数日は頑張れても、忙しい日が続くと止まってしまう——これは多くの人が経験する挫折ポイントだと思います。
投稿順を決め打ちすると「今の話題」から取り残される
「では手間を消すために、投稿する記事の順番をあらかじめ決めておけばいい」と考えるかもしれません。これは半分正解で、半分は問題が残ります。
Xの自動投稿の仕組みだけだと、用意した記事を決めた順番(ローテーション)で機械的に出すことになります。これは手間が消える代わりに、世の中の話題と無関係に投稿が流れる、という弱点があります。
世の中の関心は日々動きます。金利のニュースが出た日もあれば、新NISAの話で持ちきりの日もあります。そんな日に、たまたまローテーションで全く関係ない記事が出てしまうと、せっかくの注目を取りこぼします。
逆に、その日の話題に合った記事を出せれば、いま関心を持っている人に届きやすくなります。この「その日の話題に合わせて選ぶ」という判断こそ、人ではなくAIに任せたい部分でした。

仕組みの全体像:誰が・いつ・何をするか
ここが本記事の核です。先に結論を言うと、毎朝の投稿1回の中で、ニュースを集めるところから投稿文を作るところまでが一気に走ります。人は何もしません。

具体的な流れは次の通りです。登場するのは私のパソコンではなく、すべてインターネット上のサービスです。
- 朝7:30(時計係):前回作った仕組みのタイマーが、投稿処理を起動します。
- 起動直後(選ぶ係=AI):その場でニュースを集め、話題を1つ選び、関連する自分の記事を1本選び、投稿文を作ります。
- その流れのまま(届ける係):できあがった投稿文が、そのままXへ送り出されます。
ここで誤解しやすいのが、「AIがXに投稿しているのでは?」という点です。厳密にはそうではありません。AIは話題と記事を選んで文章を書くところまでを担当し、実際にXへ送り出すのは前回作った定時投稿の仕組みです。ただし両者は同じ処理の中で連続して動くので、外から見れば一本の流れに見えます。
大事なのは、この一連の処理がすべてインターネット上(GitHub Actions)で動くことです。私がパソコンを開いていようが寝ていようが、毎朝同じように実行されます。X自動投稿の仕組みそのものの作り方は前回の記事 で解説しているので、ここでは深入りしません。
AIが毎朝やっている4ステップ
AIが担当する「選ぶ」作業は、4つのステップに分かれています。順番に見ると、人が頭の中でやっている作業をそのまま分担しているだけだと分かります。
① ニュース収集
まず、その時点の経済・金融まわりのニュースを集めます。いま世の中で何が注目されているかを把握する、最初の情報インプットの工程です。
材料にしているのは、次の3つです。いずれも「誰かが選んだおすすめ」ではなく、実際に読まれた順位や検索された回数という客観的な数字が付いてくるものを選んでいます。
- Yahoo!ニュース 経済のアクセスランキング(実際に読まれた順位つきの見出し)
- Google ニュースの当日ヘッドライン
- Google トレンドの急上昇ワード
ここでは「どれがホットか」の判断はしません。順位という生のデータだけを集めて、次のステップに渡します。
② 話題選定(主軸+重複回避)
集めたニュースの中から、投稿の軸にする話題を一つ選びます。選び方には二つのルールを持たせています。
- 主軸(AIの判断):いま注目が高まっている話題を優先する
- 重複回避(機械的なルール):直近7日以内に投稿した記事は、そもそも候補から外す
重複回避は、AIに「なるべく避けてね」とお願いしているのではありません。AIに候補一覧を渡す前の段階で、直近7日に出した記事を機械的に取り除いています。お願いベースだと守られないことがあるので、守らせたいルールは仕組み側で担保する、という考え方です。このさじ加減は次の章でもう少し説明します。
③ 記事マッチング
選んだ話題に最も関連する自分の記事を、1本だけ選びます。たとえば金利の話題なら住宅ローン関連、税制の話題なら制度解説の記事、という具合に、話題と記事をつなぎます。
ここで紹介する記事はあくまで自分が過去に書いた記事です。話題に合う記事が手元にないこともあり、その場合は無理にこじつけません。
④ 投稿文生成
最後に、選んだ話題と記事をつなぐ投稿文を作ります。投稿文には、話題への一言・記事へのリンク・サムネイル(記事のアイキャッチ画像)が含まれます。
この4ステップが終わると、できあがった投稿文がそのままXへ送られます。ここまでが、朝7:30に起動してから数十秒のあいだに起きていることです。
話題の選び方:「主軸」と「重複回避」のさじ加減
話題選定で二段ルールにした理由を、もう少しだけ掘り下げます。目的はひとつ、鮮度(いまの話題に乗る)と多様性(同じ話ばかりにしない)のバランスを取ることです。
なぜ片方だけではダメなのか。理由はこうです。
「いま注目の話題を選ぶ」だけにすると、話題が1〜2日では大きく変わらない性質上、同じ記事が何日も続いてしまうことがあります。読み手からすると「また同じ話か」となり、飽きられやすくなります。
かといって「毎回違うテーマにする」を最優先にすると、無理に話題を変えることになり、いま注目されている話を外してしまいます。これでは鮮度が落ちます。
そこで、話題選びはAIの判断に任せ、同じ記事の連投だけは仕組みで止めるという二段構えにしました。AIには「いま注目の話題に合う記事を選んで」とだけ頼み、直近7日に出した記事は最初から候補に入れない。判断が要ることはAIに、機械的に守れることは仕組みに——という切り分けです。
なぜ7日かというと、1週間あれば同じ記事が再登場しても「また同じ話か」とは感じにくいこと、そして紹介したい記事のストックがそれだけ回る本数あることの2つが理由です。記事数が少ないうちは、この日数を短くしないと出すものが無くなります。

最初はこう作った——そして、こう変えた
ここまで「毎朝サーバー側で自動的に動く」と書いてきましたが、最初からこの形だったわけではありません。作り直した経緯を書いておきます。同じことをやろうとする方には、この失敗と修正のほうが役に立つかもしれません。
当初の形:パソコンを開いた朝しか動かなかった
最初は、私のパソコンで動かしているClaude Codeに選ばせていました。前夜22:00と翌朝6:30にClaude Codeが起動して、ニュースを読み、記事を選び、投稿文を「準備メモ」に書き出す。翌朝7:30に投稿の仕組みがそのメモを拾って投稿する——というバトンリレー方式です。
この形にした理由は単純で、すでに手元にあるものだけで作れたからです。追加の契約も課金も要りません。
ただ、大きな弱点がありました。Claude Codeはパソコンでアプリを開いている間しか動きません。私は夜や早朝にパソコンを開いていないことも多く、投稿の時刻になっても準備メモが空のまま、という朝がそれなりにありました。その朝は代打の定番記事が出るので投稿自体は途切れないのですが、「ニュースに連動させる」という肝心の部分が、動く日と動かない日でまだらになる。これでは何のために作ったのか分かりません。
変えたこと:選ぶ処理をサーバー側へ移した
そこで、選ぶ処理そのものを、投稿の仕組みの中に取り込みました。準備メモを介したバトンリレーをやめ、朝7:30の投稿処理が起動したその場で、ニュース収集から投稿文づくりまでを実行する形です。
パソコンで動くClaude Codeの代わりに、使った分だけ料金がかかる仕組み(API)経由でClaudeを呼び出しています。これならインターネット上のサーバーだけで完結するので、私のパソコンが開いていようが閉じていようが関係ありません。
この変更で、次のように変わりました。
| 当初 | 現在 | |
|---|---|---|
| 選ぶ担当 | パソコンのClaude Code | サーバーから呼び出すClaude(API) |
| 動くタイミング | 前夜22:00と朝6:30(パソコンを開いていれば) | 朝7:30の投稿処理の中で毎回 |
| 受け渡し | 準備メモ(中間ファイル) | なし(同じ処理の中で完結) |
| 動かない日 | パソコンを開かなかった朝 | 原則なし |
判断の分かれ目:「やらなければ」を減らしたかった
移行にあたって迷ったのは費用です。パソコンのClaude Codeなら追加料金はかかりませんが、API経由だと使った分だけ課金されます。
それでも移した一番の理由は、「やらなければならないこと」を一つ減らしたかったからです。
正直に言うと、朝か夜にパソコンを開くこと自体は、そこまでの負担ではありませんでした。数分の話です。負担だったのは、「今日は開いたかな」と頭の片隅に置いておくことと、開けなかった日に感じる小さな後ろめたさのほうでした。自動化したはずなのに、自分がやるべきことが増えている。この逆転が、続けるほど引っかかるようになりました。
サーバー側に移してからは、そもそも私が思い出す必要がなくなりました。1日1回・数十秒の処理にかかる費用は小さく、それで気にかけることが一つ減るなら安い、と考えました。
何かの仕組みを作るときは、ついできるだけお金をかけない範囲で組みたくなります。ブログの収益がまだ小さいうちは、なおさらです。
ただ、その範囲に収めるために自分が動く前提を残すと、それは「自動化」ではなく「新しいタスク」です。私は本業を持ちながらこのブログを運営しているので、増やしたくないのは支出よりもこの抱えるタスクのほうでした。金銭的な効果がまだ出ていなくても、やらなければいけないことが一つ減るなら、少額の課金は悪くない投資だと考えています。
この「できるだけ安く」から「必要なら少し払う」への切り替えは、最近になって身についたものです。若い頃はお金がかかることを極端に避けていました。その反省は「NISA満額入金は正解?「NISA貧乏」にならない入金額の決め方 」に書いています。
手間の量ではなく、覚えておかなければいけないことが増えていないか——そこを見たほうがよさそうです。
うまく選べなかった朝はどうなる?(フォールバック設計)
ここは正直にお伝えしておくべき、大事な前提です。AIがうまく選べなかった朝でも、投稿は途切れません。そのための代打を用意しています。
AIに任せている以上、うまくいかない朝は必ずあります。実際に起こりうるのは、こういう場面です。
- ニュースの取得に失敗した(参照先のサイトが一時的に応答しないなど)
- ニュースは集まったが、その日の話題に合う記事が自分の手元に1本も無かった
- AIの返事が想定した形式にならなかった
そこで、こういう仕組みにしました。
- AIが記事を選べたら:それを投稿する(=その日の話題に合った投稿)
- 選べなかったら:通常のおすすめローテーションが代打で投稿する(=あらかじめ用意した定番記事)
この設計のおかげで、AIがうまく動かなかった朝でも投稿に穴があきません。「AIに丸投げ」ではなく、「選べたら優先・ダメなら堅実な定番」の二段構えにしているのがポイントです。
自動化というと「全部AI任せ」を思い浮かべがちですが、現実にはAIが答えを出せない日もあります。そこを正直に見込んで、出せなかったときの代打を用意しておく——この保険があるかどうかで、仕組みの安定感は大きく変わります。
実際にニュース連動で投稿された例
抽象的な話が続いたので、実際に起きた一例を紹介します。話題から記事が選ばれる流れが、具体的にイメージできるはずです。なお、これは前章で書いた当初の形(パソコンのClaude Codeが選ぶ方式)で動いていた頃の出来事です。選び方の考え方はいまも同じです。
ある日、日本銀行が金融政策決定会合で政策金利の引き上げを決めた、というニュースが大きく報じられました(金利水準などの具体的な数値は、報道や日銀の公表資料でご確認ください)。
金利が動くと、変動金利型の住宅ローンや借り換えへの関心が高まります。実際、この話題が出たことで関連する検索や話題が増えた、と感じました。
そこでAIは、この話題に最も関連する自分の記事として「住宅ローン借り換えシミュレーション」の記事を選び、翌朝のおすすめに設定しました。実際に投稿された文章は手元に残っていないため、雰囲気を再現すると次のような内容です。
日銀の利上げで変動金利が気になる方へ。借り換えで返済がどう変わるか、シミュレーションで試せる記事をまとめました。
ニュース(金利上昇)→読者の関心(住宅ローン・借り換え)→自分の記事(借り換えシミュレーション)という順で、自然につながっているのが分かると思います。これが「話題に連動して記事を選ぶ」ということです。

やってみて感じたこと・注意点
最後に、実際に運用してみての率直な感想と注意点をまとめます。結論としては、やる価値はあったが「丸投げ」では成り立たない、というのが実感です。
良かった点は次の二つです。
- 毎朝「今日は何を出そう」と悩むストレスが消えた
- 投稿が、その日の話題に乗りやすくなった
一方で、注意しておくべき点もあります。
- AIの選定は完璧ではなく、たまに話題と記事のマッチが的外れなこともある
- そもそも、ぴったり合う話題が無い日もある
- 記事のストックが少ないうちは、同じ記事を除外する日数を長くすると出すものが無くなる
これらを踏まえて感じたコツは、「丸投げ」ではなく「判断の枠(ルール)を人が決めて、その枠の中でAIに回させる」という関わり方です。今回でいえば、「いまの話題に合う記事を選ぶ」という判断はAIに任せ、「直近7日に出した記事は使わない」という守らせたいルールは仕組み側で担保しています。
AIに任せる、というと全部おまかせのイメージがありますが、実際にうまくいったのは、人が決めたルールの上でAIに動いてもらう形でした。判断の枠を人が設計するからこそ、AIの出力が安定し、的外れも減らせます。
まとめ
- 役割分担:「何を投稿するか選ぶ」のはAI(Claude)、「実際に投稿する」のは前回作った仕組み。いまは同じ処理の中で連続して動く
- AIの4ステップ:ニュース収集→話題選定→記事選び→投稿文づくり。ニュースは順位や検索数という客観データから拾う
- 二段構え:話題選びはAIの判断に任せ、同じ記事の連投は仕組みで止める。判断が要ることはAIに、機械的に守れることは仕組みに
- 作り直した:当初はパソコンのClaude Code頼みで「開いた朝しか動かない」状態だった。選ぶ処理をサーバー側へ移して、毎朝必ず動くようにした
- フォールバック:AIが選べなければ定番のローテーションが代打。だから投稿が途切れない
- コツ:丸投げではなく、判断の枠を人が決めてAIに回させる
検索だけに頼る時代から、SNSでも「届ける」工程を持つ時代へ。その中身を賢くする一例として、今回の仕組みと、その作り直しを紹介しました。
まずは土台から始めるのがおすすめです。定時にXへ自動投稿する仕組みそのものの作り方は、前回の記事 で解説しています。そちらができていれば、今回の「中身を賢くする」工程は後から足せます。
何かの参考になれば幸いです。
関連記事
- X自動投稿の作り方|GitHub Actionsのcronズレを解決 — この記事の土台にあたる「定時にXへ自動投稿する仕組み」の作り方
- Claude Codeで資産記録を自動化した|出力フォーマットを渡すだけの月次管理フロー — 同じく「判断の枠を渡してAIに回させる」考え方を資産管理に応用した例
- NISA満額入金は正解?「NISA貧乏」にならない入金額の決め方 — 「できるだけ安く」から「必要なら少し払う」へ。本記事で書いた判断の、家計側から見た話
- Cloudflare Pagesのブログ公開フロー|Draft確認と予約投稿の仕組み — 本記事で触れた「朝の自動ビルドで記事が公開される」仕組みの解説
参考文献・出典
- X API(公式ドキュメント) — Xへの投稿を外部から行うための公式仕様
- Claude Code(Anthropic 公式) — 当初「選ぶ役割」を任せていた、パソコン上で動かすAIツールの公式ドキュメント
- Claude Developer Platform(Anthropic 公式) — 現在の方式で使っている、サーバーからClaudeを呼び出す仕組み(API)の公式ドキュメント
- 日本銀行 金融政策(公式サイト) — 本記事で触れた政策金利・金融政策決定会合に関する一次情報