現在このブログの記事の下書きはAIが作っています。
ニュースを調べるのも、本文を書くのも、SEOのメタ情報を入れるのも、note版に作り替えるのも、公開1週間後に数字を見て振り返るのも、だいたいAIがやっています。僕がやっているのは、画像を用意することと、最後に「公開」ボタンを押すことくらいです。
ただ、ここに来るまで1年かかりました。しかもきれいに積み上がったわけではなくて、任せるたびに事故って、そのたびに「ここから先はAIにやらせない」という線を引き直してきた1年でした。
アフィリエイトのリンクが10か月間死んでいたのに気づかなかった話とか、AIが説明用に書いた「例」のコードをそのまま本番の記事に貼ってしまった話とか、noteのリンクが全部ただの文字列になっていた話とか、わりと恥ずかしい失敗が続きます。
同じことをやろうとしている人が、僕と同じ穴に落ちなくて済むように、起きたことをそのまま並べておきます。
結論：いま何が自動で、何が手動なのか
2026年8月時点で、ブログとnoteの更新はこうなっています。
| 工程 | 誰がやるか |
|---|---|
| ネタ探し・ニュース調査 | AI（週1回、自動で走る） |
| 一次情報での裏取り | AI |
| 本文の執筆 | AI |
| WordPressへの下書き保存 | AI |
| タイトル・スラッグ・カテゴリ・タグ・メタ説明 | AI |
| アイキャッチ・挿絵の生成 | 人間（私） |
| 画像の配置とalt設定 | AI |
| ブログの公開ボタン | 人間（私） |
| note版への変換と下書き保存 | AI |
| note本文への画像挿入 | AI |
| noteの公開ボタン | 人間（私） |
| 公開1週間後の数字チェックと振り返り | AI（週1回、自動で走る） |
| 公開済み記事の健全性チェック | AI（週1回、自動で走る） |
太字にした2つ、つまり「公開ボタン」だけが人間の仕事です。
なぜここに線を引いたのか。答えを先に言うと、公開前と公開後で、失敗したときの取り返しやすさが全然違うからです。下書きは何を書いても読者には見えません。でも一度公開したら、間違いはそのまま読者の目に入りますし、検索エンジンにも拾われます。
この「取り返しがつくかどうか」で切る、という考え方にたどり着くまでが、この記事の中身です。
2025年9月：全部自分で書いていた頃
このブログを始めたのは2025年の9月です。
携帯ショップで10年以上働いていて、店頭で毎日のように「結局どのプランが安いんですか」と聞かれていました。そういうやり取りは日常にありましたが、ブログを始めた一番の理由はそこではなく、ブログを通して発信をしたかったからです。
最初の半年は、当然ながら全部自分で書いていました。
そして、月に2〜3本が限界でした。
記事を1本書くのに、料金を各社の公式サイトで確認して、割引の併用条件を整理して、表を作って、見出しを組み直して……とやっていくと、平気で1週間くらいかかります。仕事から帰ってきて1時間書いて、翌日読み返したら構成が気に入らなくて全部消す、みたいなこともよくありました。
書きたいネタはメモに溜まっていくのに、記事は増えない。この状態が半年続きました。
2026年5月：AIに「会社」を作った
転機は2026年の5月です。
Claude Code（AIにパソコンの中の作業をやらせるツール）を触り始めて、「これ、記事を書かせるだけじゃなくて運営そのものを任せられるんじゃないか」と思ったのがきっかけでした。
やったことは、ざっくり言うとAIに会社組織のふりをさせることです。
- 全体の統括役（記事の進行管理・判断）
- アプリ開発担当（自作ツール系）
- 品質チェック担当
みたいに役割を分けて、それぞれに「あなたはこういう担当です」という指示書を用意しました。そして全員が共通で読む知識ベースを作りました。文体のルール、想定読者、過去の失敗、うまくいったプロンプト、投資や通信の知識。こういうものを1か所にまとめて、AIが作業を始めるときに必ずそこを読むようにしたわけです。
なぜこんな面倒なことをしたかというと、毎回ゼロから説明するのが一番のコストだったからです。
AIに記事を書かせると、そこそこのものは出てきます。でも「文体が違う」「そのフレーズは使わない」「その肩書きは間違い」と毎回言い直すことになる。1本目で直したことを、2本目でまた直す。これをやっていると、自分で書いたほうが早いという結論にしかなりません。
だから、直した内容をその場で書き残して、次から全員がそれを読む形にしました。この「言い直しを資産に変える」仕組みが、いまも運営の背骨になっています。
そして1か月目で事故る
体制を作った直後、いきなりやらかしました。
AIに携帯キャリアの割引記事を書かせたところ、割引の名称と併用条件を間違えて書いてきたんです。しかも、もっともらしい文章で。
原因ははっきりしていて、事前調査をさせずに書かせたからです。AIは学習した知識の範囲で、それらしい割引名を作ってしまう。通信業界は割引の名前が半年で変わる世界なので、これは相性が最悪でした。
ここで最初のルールができました。
記事を書く前に、必ず各社の公式ページで裏を取る。裏が取れない数字は本文に書かない。
裏が取れなかった項目は「【要確認】」として別のメモに逃がして、僕が確認する。本文には入れない。この運用は今も続いています。
いま思うと、この時点で「AIは間違える」ではなく「AIには調べさせてから書かせる」に発想を切り替えられたのが良かったです。間違いを直す仕事を人間が引き受け続ける形にしていたら、たぶん途中で止めていました。
2026年6月：AdSenseに2回落ちて、方向が変わった
AI体制ができて記事のペースは上がりました。が、Google AdSenseの審査には2回連続で落ちました。
理由はどちらも「有用性の低いコンテンツ」です。
1回目に落ちたあと、テーマを変えたりアイキャッチを統一したり、薄い記事を非公開にしたりしました。見た目はかなり良くなったと思います。それでまた落ちました。
このとき分かったのは、Googleが見ているのは体裁ではないということです。他のサイトに書いていないことが、どれだけ書いてあるかを見られている。
スマホの節約記事は、どこにでもあります。料金表を並べて比較する記事なんて何千本もある。そこに1本足しても「独自性がある」とは判断されません。記事を絞り込んだのも逆効果で、サイト全体のコンテンツ量が薄いと見られた可能性が高いです。
じゃあ僕にしか書けないものは何かというと、2つでした。
- 携帯ショップの店頭で実際に起きていること（10年以上やっているので、これはさすがに一次情報）
- プログラミング未経験の人間が、AIで実際にツールを作った記録
特に2つ目です。当時ちょうど、高配当株の利回りを毎朝チェックして通知してくれるツールをAIと一緒に作っていました。コードは1行も書いていません。それでも動くものができた。この過程を全部書いたら、他にない記事になります。
Claude Codeで「自分専用の高配当株スクリーナー」を作った話
AdSenseは結局まだ通っていませんが、この方向転換自体は正解でした。開発記録シリーズは、いまこのブログで一番読まれているジャンルの一つです。
AdSenseに落ちたおかげで、書くべきものが決まったというのが、いま振り返っての結論です。
2026年8月：下書きをAIに全部任せることにした
ここからが本題です。
5月〜7月の運用は、AIが原稿を書いて、僕がそれをWordPressにコピペする、という形でした。悪くはないんですが、コピペの過程で必ず崩れます。表がずれる、装飾が消える、見出しの階層が変わる。結局そこで30分くらい溶けていました。
そこで8月に、AIがWordPressに直接下書きを保存する形に切り替えました。
切り替えを決める前に、1つだけ確認したことがあります。
下書きは、ログアウトした状態で本当に見えないのか。
これ、思い込みで進めるのが一番怖いところです。実際にブラウザのログアウト状態で下書きのURLを叩いて、404が返ってくることを確認しました。noteの下書きでも同じことをやりました。どちらも404でした。
これが確認できたので、線が引けました。
下書きの中身はAIが自由に書いてよい。ただし公開ステータスには絶対に触らせない。
具体的には、記事の状態を「下書き」から「公開」や「予約投稿」に変える操作だけを禁止しました。本文もタイトルもカテゴリもタグもスラッグもSEOのメタ情報も、全部AIが書いていい。読者に見えない場所なら、間違っていても直せばいいだけなので。
同じタイミングで、定期実行の仕組みも入れました。いま動いているのは5本です。
| いつ | 何をするか |
|---|---|
| 毎朝 | 進行中のタスクを読んでサマリーを通知 |
| 毎週月曜 | 通信キャリアの直近1週間のニュースを調べて、記事にする価値があれば下書きを作る |
| 毎日21時 | 公開済みの記事とnote転載の台帳を突き合わせて、転載漏れがあればnote下書きを作る |
| 毎週水曜 | 公開済み記事の健全性をスキャンして、直せるものは直す |
| 毎週金曜 | 公開1週間が経った記事の数字を取って、振り返りを記録する |
月曜のタスクには「記事にする価値があるものが無ければ何も作らない」という条件を入れてあります。毎週1本ノルマにすると、薄い記事が量産されるだけなので。実際、何も作らない週もあります。
任せた瞬間、事故が4つ出た
ここまで読むと順調に見えますが、下書きを任せた8月の1週間で、事故が4つ出ました。
しかもそのうち2つは、AIに任せる前からずっと壊れていたのに、誰も気づいていなかったものです。
事故1：意味不明の記号が公開ページに出ていた
AIに原稿を書かせるとき、内部リンクを入れたい場所には 「リンク：◯◯の記事」 という目印を置くルールにしていました。あとで実際のURLに差し替える前提のマーカーです。
これが差し替えられないまま3か所、公開ページに出ていました。
読者から見たら、記事の途中に意味の分からない記号が挟まっているだけです。信頼を落とすには十分でした。
原因は単純で、「マーカーを実リンクに置き換える」という工程が、公開前のチェックリストに入っていなかったからです。SEOプラグインの読みやすさスコアは普通に通ってしまいます。ただの文字列なので検知されません。
対策は2つ入れました。
- 公開前に、本文から特定の記号（角カッコ・亀甲カッコ・TODO・※要）を全文検索してゼロにする
- 公開した直後に、実際の公開ページを機械的に読み直して同じ検索をかける
目視だけに頼らない、というのがポイントです。人間の目は、自分が書いた文章の記号を平気で読み飛ばします。
事故2：アフィリエイトのバナーが10か月死んでいた
これが一番きつかったやつです。
公開済みの記事のアフィリエイトバナーを機械的に調べたところ、バナー画像は表示されているのに、リンクと成果計測用のタグだけが消えている箇所が大量に見つかりました。
| 記事 | 壊れていた枚数 | 放置されていた期間 |
|---|---|---|
| 乗り換え記事「スマホ乗り換えはいつがいい？」（/sumako-norikae/・サイト流入の53.66%） | 1枚 | 約10か月 |
| 携帯ショップで聞くべきこと記事 | 3枚 | 約2.5か月 |
| 楽天モバイル通話コスパ記事 | 4枚 | 約2.5か月 |
| ワイモバイル手数料記事 | 1枚 | 数時間 |
クリックしても広告主のサイトに飛ばず、成果も1件も計上されない状態です。合計9枚。
原因は、ASP（アフィリエイトの仲介サービス）からコピーしたコードを、WordPressの本文にそのまま貼っていたことでした。いまのWordPressのエディタは、貼られたHTMLを解釈して「画像ブロック」に自動変換します。その過程で、リンクのタグと1×1ピクセルの計測タグを丸ごと削除するんです。
厄介なのは、画像はちゃんと表示されることです。見た目は完全に正常なので、目視では絶対に気づけません。
正しい貼り方は、「カスタムHTML」というブロックを選んでから貼ることでした。これを知らずに10か月やっていました。
一番読まれている記事のバナーが10か月死んでいた、というのは考えたくない損失なんですが、見つけたのは自動化した健全性スキャンです。手作業で運営していたら、たぶん今も気づいていません。皮肉な話ですが、AIに任せるために作った検査の仕組みが、AI以前の自分のミスを掘り出しました。
事故3：AIが説明用に見せただけのコードを、そのまま本番に貼った
これは完全に僕のミスです。
事故2の報告をAIから受けたとき、AIが説明用に「こういう形のコードです」というサンプルを書いてくれました。URLの一部を伏せ字にした、あくまで説明用のものです。
それを僕が、そのまま記事に貼りました。
当然、画像も出ないしリンクも死んでいる状態で公開されました。
ここから追加したルールが、これです。
AIは、貼れてしまう形のASPコードを絶対に書かない。
壊れている箇所を指すときは「◯行目のバナー」と位置で指す。正しいコードが必要なときは、僕がASPの管理画面からコピーする。AIにコードを書かせない。
AIが親切のつもりで出したものを、人間が確認せずに使うというのは、これから相当あちこちで起きると思います。コードブロックで出てきたものって、「そのまま貼るもの」に見えるんですよね。
事故4：noteのリンクが全部ただの文字列だった
これは今週（2026年8月22日）の話です。
ブログの記事をnoteにも転載しているんですが、note版の記事に貼ったブログへのリンクが、全部クリックできないただの文字列になっていました。3記事分、合計11本。
noteは、本文の中に書いたURLを自動でリンクにしてくれません。ブログサービスによっては勝手にリンク化してくれるので、その感覚のままURLをベタ書きしていたわけです。
結果として、note→ブログという導線が丸ごと死んでいました。noteを主軸にして、収益はブログ側で、という設計にしていたので、これは設計そのものが成立していなかったことになります。
原因を追いかけたら、AIのミスではありませんでした。note用の手順書に「使っていいタグ」のリストを作っていて、そこにリンクのタグを入れ忘れていたんです。AIは指示通りにやっていた。指示が間違っていた。
修正はすぐできました。noteでもリンクのタグは普通に使えることを検証して、3記事とも直しました（一度公開を取り下げて、直して、また公開しています）。
この事故から得た教訓が、個人的には一番でかかったです。
仕様に「これは使わない」と書くときは、なぜ使わないのかを必ず一緒に書く。試して駄目だったのか、そもそも試していないのか。
「使わない」とだけ書いてあると、誰も（AIも自分も）二度と疑いません。実際このリストは、作ってから一度も見直されずに運用されていました。
事故のたびに、線を引き直した
4つの事故を経て、いまの線引きはこうなっています。
| AIがやってよい | 人間だけがやる | |
|---|---|---|
| WordPress | 下書きの新規作成と編集全般／公開済み記事の意味が変わらない修正（誤字・画像のalt・メタ説明・内部リンクの追加） | 公開ステータスの変更／公開済み記事の本文の書き換え／価格や数値の変更／金融・法律に関わる表現 |
| note | 数値の読み取り／下書きの作成と保存／本文への画像挿入 | 公開・更新・削除（例外なし） |
| アクセス解析 | 数字を読んで記録すること | 設定の変更／インデックス登録のリクエスト |
| ファイル | 新規作成・追記 | 既存ファイルの削除・重要ファイルの上書き |
最初からこの表があったわけではありません。1行ずつ、事故のあとに足されています。
そして、線を引く基準は結局これに集約されました。
- 読者に見えるか、見えないか
- 間違えたとき、取り返せるか
下書きは読者に見えないし、間違えても直せる。だから全部任せる。公開は読者に見えるし、消しても検索結果には残る。だから人間が押す。
シンプルですが、この2軸で切ると迷わなくなりました。
これから同じことをやる人へ、3つだけ
AIにブログ運営を任せようとしている人に、先に言っておきたいことが3つあります。
1. 「AIには無理」は、一度も試していないだけかもしれない
僕は長いこと「AIはnoteの本文に画像を入れられない」と思い込んでいました。手順書にもそう書いていました。
実際に検証したら、普通にできました。入れ方を1つ変えるだけでした。
同じことがリンクのタグでも起きました。「使わない」と書いてあったから使っていなかっただけで、試したら使えた。
「できない」と書くときは、いつ・何を試して駄目だったのかを一緒に書いておく。そうしないと、その制限は永遠に見直されません。
2. 目で見て確認するのをやめる
事故2と事故4は、どちらも目視では絶対に気づけないタイプでした。バナーは表示されているし、URLは文字として見えている。
代わりにやるべきなのは、公開したページを機械的に読み直して、条件で検査することです。
- 変な記号が残っていないか
- 画像のaltが全部入っているか
- バナーにリンクが付いているか
- 本文の中にクリックできないURLが残っていないか
こういうものは、リストにして自動で回したほうが確実です。人間が毎回見るのは無理でした（僕は10か月見逃しています）。
3. 直したことを、その場で書き残す
これが一番効きます。
AIに何かを直させたら、なぜ直したのかを知識ベースに書き残す。次からAIはそれを読んでから作業する。同じ指摘を二度しなくて済みます。
逆に言うと、これをやらないと永遠に同じ指摘を続けることになります。そうなると自分で書いたほうが早い、という結論になって、たぶん止めます。
AIに任せる作業で一番価値があるのは、記事を書かせることではなくて、「言い直したこと」を資産に変えることのほうかなと思っています。
いまの課題
きれいに終わらせるつもりはないので、まだ解けていないことも書いておきます。
アイキャッチと挿絵は、まだ全部手作業です。画像生成のプロンプトはAIが用意してくれるんですが、生成して、選んで、サイズを整えるのは僕がやっています。ここが今の一番のボトルネックで、記事の下書きができてから公開までの時間は、だいたいこの工程で決まっています。
そして、AIが書いた記事が本当に読まれているのかは、まだ判断がつきません。自動化の仕組みが動き出したのが8月なので、数字が溜まっていません。公開1週間後の振り返りを自動で回す仕組みは作ったので、あと1〜2か月すれば「AIが書いた記事は人が書いた記事より読まれるのか」が見えてくるはずです。
そこが分かったら、また書きます。しばらくは、この形で回してみます。
コメント