自動化を30日続けた記録｜増えたもの、減ったもの、まだゼロのもの

先に一番大事な数字を書きます。AIによる自動化を30日続けて、売上はまだゼロです。 増えたのは記事の本数、減ったのは手を動かす時間でした。

つまり自動化は、収益そのものではなく「試す回数を増やす道具」でした。盛らずにそのまま書きます。この記事では、30日で増えたもの・減ったもの・まだゼロのものを、公式の一次情報と照らしながら整理します。同じように「AIに仕事をさせてみたいが、何が起きるか知りたい」人の判断材料になれば十分です。

まず固定した、30日間のやり方と測り方

「自動化した」と一言で言っても、中身は人によってバラバラです。そこでこの30日は、記事づくりを工程(=作業の段階)に分けて、それぞれ誰が担当するかを先に決めました。

工程の分け方は、GitHub Actionsの考え方を参考にしました。GitHub Actionsでは、自動処理をworkflow(=処理のまとまり)として書き、その中をjob(=仕事)とstep(=手順)に分けます(Understanding GitHub Actions)。1つの巨大な「全自動」を作るのではなく、小さな工程の列にする。こうすると、失敗したときに「どの工程で止まったか」が分かります。

もう1つ決めたのは、「AIに判断させる部分」と「決まった条件で必ず動く部分」を分けることです。たとえばClaude Codeのhooks(=ファイルを保存した後などの決まった時点で、自動でコマンドを動かす仕組み)を使うと、形式のチェックをAIの判断に任せず、毎回同じように実行できます(Automate actions with hooks)。文章の中身はAI、形式の検査は機械、事実の確認は人。この線引きが30日の土台でした。

工程	担当	中身
題名案・見出し・下書き	AI	「誰の、どんな困りごとに答えるか」を1文で渡して作らせる
形式チェック(文字数・書式・リンク)	決まった自動処理	保存やビルドのたびに、毎回同じ検査を機械が行う
事実確認・出典の照合	人	出典のページを実際に開いて、書いてあるか確かめる
重複チェック	人+AI	過去記事と同じ結論になっていないかを見る
公開の最終判断	人	読者の役に立つかを最後に通しで読む

ここで正直に、反省を1つ書きます。開始日・終了日・工程ごとにかかった時間を、同じ定義で記録していませんでした。だから「何本増えた」「何時間減った」を、この記事に実数で書くことができません。体感では確かに減ったのですが、体感は証拠になりません。記録の仕方を決めていなかったこと自体が、この30日の一番の失敗でした。次の30日は、まずここを直します。

増えたもの、減ったもの、減らなかったもの

増えたのは、公開候補の記事本数です。 記事の題名を考え、見出しを作り、下書きを書くところまでAIに任せました。人が毎回まっ白な画面から書くより、公開候補になる下書きは増えました。コツは、先に「誰の、どんな困りごとに答えるか」を一文にすることでした。「AIについて書いて」だけでは、似た説明ばかりが返ってきます。

ただし注意があります。「AIが作った下書きの数」と「検品を通って公開した数」は別物です。下書きが10本できても、人の確認を通らなければ公開はゼロです。この2つを混ぜて「たくさん書けた」と言うと、自分をだますことになります。

減ったのは、書き始めるまでの時間です。 一番減ったのは、最初の一文で止まる時間でした。題名と見出しが先に出るため、人は何もない状態から考えなくて済みます。書式をそろえる作業も、決まった自動処理に渡せました。

減らなかったのは、確認の時間です。 AIは同じ指示でも毎回違う文章を返します。これは不具合ではなく、生成AIの性質です。OpenAIの公式ガイドも、同じ入力から違う出力が出る前提で、出来の判定(評価)を早く何度も行い、記録を残し、できる判定は自動化するよう勧めています(Evaluation best practices)。

Claude Codeの公式も同じ方向です。「終わりました」という主張だけを信じず、テストの結果や処理の終了コードなど、機械が読める合否判定を渡すことを勧めています(Best practices for Claude Code)。裏返すと、機械で判定できない項目は残ります。出典が本当にそう言っているか。体験談が事実か。読者に分かりやすいか。これらは人が読むしかありません。だから下書きが速くなっても、確認の時間はゼロになりませんでした。自動化した後ほど、人が読む工程は必要でした。

売上ゼロの中身を、途中の数字で分ける

「売上ゼロ」という結果だけでは、何がだめだったのか分かりません。読者がサイトに来る前と、来た後を分けて見る必要があります。

来る前の数字は、Search Console(=Google検索での見え方を測る無料ツール)で分かります。自分のページが検索結果に何回表示されたか、何回クリックされたか、どんな言葉で検索されたかを確認できます(Get started with Search Console)。Googleは毎日見る必要はなく、月に1回ほど、または内容を変えた時に確認すればよいと案内しています。

来た後の数字は、Google Analyticsの担当です。訪問した人がどのページを見て、どんな行動をしたかを測ります。注意点として、Search ConsoleとGoogle Analyticsは集計の仕組みが違うので、クリック数とセッション数は完全には一致しません(Using Search Console and Google Analytics data for SEO)。差が出ても計測ミスと決めつけず、同じ期間・同じページで傾向を比べるのが公式の整理です。

この物差しで見ると、「売上ゼロ」は1つの数字ではなく、階段のどこで止まったかの問題に変わります。そもそも表示されていないのか。表示されたのにクリックされないのか。読まれたのに、次の行動につながらないのか。止まった段が分かれば、直す場所を1つに絞れます。逆に、ここを測らずに「30日で稼げないなら自動化は無駄」と一般化するのは早すぎます。売上には、題材の選び方や商品への導線など、自動化とは別の条件も効いているからです。

次の30日は、記事の決め方だけを変える

30日で一番大きな学びはこれです。自動化が直接増やすのは「作る回数」であって、「読者の役に立つこと」は自動では増えません。

Googleは、人向けコンテンツの確認項目として、独自の情報・調査・分析・実体験があるか、読み終えた人が目的を達成できるかを挙げています。逆に、検索からの流入を主な目的に多くの話題を大量に自動生成することは、見直すべき例として警告しています(Creating helpful, reliable, people-first content)。AIを使うこと自体が悪いのではありません。読者ではなく検索エンジンの方を向いた大量生成が問題なのです。ちなみに同じ資料で、Googleは検索順位のための推奨文字数は存在しないとも明記しています。長く書けば評価される、は誤解です。

だから次の30日は、自動化する範囲を増やしません。変えるのは「記事の決め方」の一点だけです。手順はこうします。

1. Search Consoleで、いまの表示回数とクリック数を書き留める(これが比較の基準値になります)。
2. 検索で使われている言葉と、読者が作業で止まりそうな場面から、答える疑問を1つだけ選ぶ。
3. その疑問だけに答える記事を作る。自動化の工程と検品の基準は変えずに固定する。
4. 開始日と終了日を決めて記録し、工程ごとの時間も同じ定義でメモする。
5. 30日後、同じ定義で基準値と比べる。数字が動かなければ、本数を増やす前に題材の選び方を疑う。

条件を1つだけ変えて、他を固定する。これは実験の基本ですが、前回の30日はそれができていませんでした。今回は先に合格と失敗の判定を決めてから走ります。

よくある質問

AIで自動化すると、作業時間は本当に減りますか？

下書きを作るまでの時間は減らせる可能性が高いです。ただし、確認や修正を含めた「全作業時間」で測らないと、正味でどれだけ減ったかは分かりません。私は工程別の時間を記録していなかったので、実数を示せませんでした。これから始める人は、最初に測り方を決めることをおすすめします。

30日続けて売上ゼロなら、自動化は失敗ですか？

売上だけでは判断できません。検索結果に表示されていないのか、クリックされないのか、読まれたのに申し込みに進まないのか。止まった場所によって直す手が変わります。Search Consoleで訪問前、Google Analyticsで訪問後を分けて見てから判断してください。

自動化の効果は、何を記録すれば比べられますか？

期間、作った候補の数、検品を通った数、公開した数、工程ごとの時間、失敗の件数と直した理由です。ポイントは「同じ定義で測り続ける」ことです。検索からの表示・クリックと、訪問後の行動は仕組みが別なので、別々の数字として記録します。

AIに任せたのに、なぜ人の確認が必要なのですか？

生成AIの出力は毎回同じではなく、見た目が完成していても中身が条件を満たさないことがあるからです。テストや形式チェックのように機械で判定できるものは自動化し、出典との一致や読者への分かりやすさは人が確認する。この分担が現実的でした。

まとめ

この30日の記録を、読者が使える形にすると次の3つです。

• 測り方を先に決めてから自動化を始める。 開始日、工程の分担、時間の測り方を最初に固定する。記録がないと、効果があったかどうかを後から言えません。
• 機械で判定できる検査と、人が読む確認を分ける。 形式チェックは自動処理に渡し、事実と分かりやすさの確認は人に残す。確認をゼロにしようとしないことが、結果的に近道でした。
• 売上の前に、途中の数字を見る。 Search ConsoleとGoogle Analyticsで「どの段で止まったか」を確かめてから、直す一点を選ぶ。数字の意味や画面は変わることがあるので、使うときは公開時点の公式案内で確認してください。

公式一次情報

確認日: 2026-07-26

• Automate actions with hooks: Claude Codeのhooksが、編集後やタスク終了時などの決まった時点でコマンドを自動実行し、整形・通知・規則の強制に使えることの説明。
• Best practices for Claude Code: テストや終了コードなど機械が読める合否判定をAIに渡し、完了の主張でなく実行した確認と結果を証拠として示すことを勧める公式ガイド。
• Understanding GitHub Actions: 自動処理をworkflowとして定義し、jobとstepに分けて順番にも並列にも実行できる仕組みの公式説明。
• Evaluation best practices: 生成AIは同じ入力でも出力が変わるため、評価を早く繰り返し、ログを残し、可能な評価は自動化して人の判断で調整することを勧める公式ガイド。
• Creating helpful, reliable, people-first content: 独自情報・実体験のある人向けコンテンツの自己評価項目と、検索流入目的の大量自動生成への警告、推奨文字数が存在しないことの明記。
• Get started with Search Console: 検索語・ページごとの表示回数やクリック数の見方と、確認は月に1回ほどでよいという公式の案内。
• Using Search Console and Google Analytics data for SEO: Search Consoleは訪問前、Google Analyticsは訪問後を測り、集計方法が違うため数値は完全には一致しないという公式の整理。