ムラサキ

当たった瞬間は正直イラッとする。ただ慣れてくると「ここで一回止まれ」という合図として使えるようになった。

制限に当たったときにまずやること

待つ以外の正攻法はない

セッション単位の制限は、リセットの時刻が来るまで枠が戻らない。プランを上げる、追加の利用枠を買う、といった正規の選択肢はあるが、今この瞬間に枠を復活させる手段はない。

だから最初にやることは、抜け道を探すことではなく、止まる準備をすることになる。

中断する前に「どこまで進んだか」を残す

2026年8月2日の話をそのまま書く。記事執筆とパイプライン開発を並行で進めていた途中で上限が近づいた。そこでいったん状態を保存して中断し、時間をおいてから続きを再開した。

このとき効いたのは、止まる直前に「終わったこと」「途中のもの」「次にやること」を書き出したことだった。数時間空くと、頭の中にだけ置いていた判断はきれいに消える。再開したとき、消えた文脈を思い出す時間のほうが、待たされた時間より痛い。

軽いモデルに切り替えて手を止めない

制限は「そのサービスが全部使えなくなる」とは限らない。プランやサービスによっては、上位モデルの枠を使い切っても、軽いモデルなら動く場合がある。

筆者はこの状況で、判断の重い作業を後回しにして、確認・整形・調査のような軽い作業に切り替えている。テキストの整形、ログの読み合わせ、次にやることの洗い出し。この手の作業は待ち時間の消化にちょうどいい。

「無制限」と書いてあるのに制限があるのはなぜか

月間の上限とセッションの上限は別物

「無制限」という表記が指しているのは、多くの場合「月間のクォータがない」「クレジットを消費しない」という意味だ。一方で、短時間にどれだけ集中して使えるかは別の軸で管理されている。この2つを同じものだと思っていると、「無制限のはずなのに止まった」という体験になる。

セッション単位の制限は、負荷を平準化するための仕組みとして置かれている。使う側から見ると理不尽だが、設計上は自然な話でもある。

「無制限」表記でも制限はある｜Gensparkのヘルプで見つけた（2026年2月〜4月の話）

筆者が契約していた期間のGenspark Plusは、AIチャットが「Unlimited（無制限）」と表記されていた。ところが公式ヘルプには、5時間ごとにリセットされるセッションベースのレート制限があると明記されていた。月間の上限はないが、短時間に集中して大量に使うと一時的に制限がかかる、という構造だ。

筆者は2026年4月9日にPlusを解約しているので、それ以降の仕様は確認していない。現時点の内容はGenspark公式のプラン説明を直接見てほしい。クレジット消費や文脈の忘れ方など、契約期間中に気になった点はPlus有料版のデメリット5つにまとめている。

現在の仕様は公式ヘルプで確認する

各サービスの制限は変わる。回数・時間・リセットの単位を他人のブログの数字で覚えると、いつか外す。確認先は公式ヘルプに絞ったほうがいい。ClaudeならClaude公式のUsage and limitsとClaude Codeのモデル・利用制限の説明、ChatGPTならOpenAI公式のプラン別モデル・上限の説明、GeminiならGoogle公式のGeminiアプリ使用量上限の説明。ここに載っていない数字は、誰かの推測だと思ったほうが安全だ。

実際に読み比べると、間隔がサービスごとに違うことが分かる。2026年8月時点で、Geminiは公式ヘルプに「使用量上限は、週ごとの上限に達するまで5時間ごとにリセットされます」と書かれていて、5時間の枠と週の枠が二層になっている。一方ChatGPTは3時間単位の説明が出てくる。同じ「セッション単位の制限」でも、5時間と決まっているわけではない。「AIの5時間制限」という覚え方をした時点で、もう半分外している。

なお2026年8月時点のClaudeについては、公式ヘルプの利用上限とうまく付き合うためのガイドに、有料プランで5時間のセッション上限が使われることと、その残量を設定画面で確認できることが書かれている。

ムラサキ

「無制限」の3文字だけ見て契約すると、どこかで裏切られた気分になる。読むべきは料金表ではなくヘルプのほう。

制限に当たる頻度を下げる3つの運用

判断の重さでモデルを割り振る

一番効いたのはこれだった。高度な判断が要らない作業は軽いモデル（SonnetやHaiku）に振り、重いモデル（Opus）は本当に必要な場面だけに使う。

線引きは難しくない。「間違えたときに自分で気づけるか」で分ける。整形や機械的な置換は、間違えれば見た瞬間に分かるので軽いモデルでいい。設計判断や原因の切り分けは、間違いに気づけないまま先へ進んでしまうので重いモデルに任せる。どの作業をどの層に置くか、コスト側から見た効果も含めた振り分けはOpus・Sonnet・Haikuの振り分け実測に整理してある。

会話が長くなる前に圧縮する

同じ会話を延々と続けると、過去のやり取りを毎回読み直すぶんの消費が積み上がる。だから会話が長くなりきる前に、いったん要点だけに圧縮する。

区切りのいいところで「ここまでの結論」を作って、そこから先を新しい文脈として進める。長さが限界に近づいてから慌てて畳むより、結果的に消費が減る。

中断が起きる前提で記録を残す

これは対処というより設計の話だ。制限に当たるかどうかを運任せにせず、「いつ止まっても再開できる」状態を常に保っておく。

筆者は作業ログと判断の記録を残す仕組みを別に用意していて、中断してもそこを読み直せば戻れるようにしている。セッションが切れても文脈を持ち越すための土台を作った話はセッションを跨いで文脈を残す仕組みに書いた。制限対策として始めたわけではないが、結果的に一番効いている。

サービスを乗り換えても制限は付いてくる

Gensparkをやめてもなくならなかった

筆者は現在Claudeを主に使っている。そして同じ種類の5時間単位の制限に、今も当たっている。

「無制限のチャット枠を失ったから当たるようになった」という単純な話ではない。使い方そのものが重くなったことのほうが大きい。解約の前後で何が変わって何が変わらなかったかは2ヶ月使って解約した判断の経緯にまとめた。

言いたいのは1点だけだ。制限を理由に乗り換えても、乗り換え先にも似た仕組みがある。逃げ切れる前提で選ぶと、また同じところで止まる。

制限が「どのモデルを使うか」を選ばせた

不便なのは間違いない。ただ、制限がなかった頃を思い返すと、何も考えずに一番重いモデルへ投げていた。判断が要らない作業まで含めて全部だ。

制限に当たるようになってから、作業ごとに「これはどの重さが要るのか」を先に考えるようになった。副産物ではあるが、この習慣は制限とは無関係に効いている。指示を出す前に作業を仕分けるので、そもそも手戻りが減る。

制限を前提に作業を設計する

まとまった時間が取れる人ばかりではない。筆者も本業の合間に動かしているので、作業は細切れになる。

だとすれば、「一気に終わらせる前提」で組んだ作業のほうが最初から無理がある。1回の作業を、途中で止めても壊れない単位に切っておく。制限はその切り方を強制してくるので、付き合い方さえ決めてしまえば、実害はかなり小さくなる。

よくある質問（FAQ）

まとめ

要点は3つ。

1つ目、当たってしまったら待つしかない。ただし止まる前に「終わったこと・途中のもの・次にやること」を残しておけば、再開のコストは大きく下がる。

2つ目、「無制限」表記と実際のセッション制限は別の話。数字は変わるので、他人のブログではなく各サービスの公式ヘルプで確認する。

3つ目、乗り換えても制限は付いてくる。筆者はGenspark Plusを解約したあとも、Claudeで同じ種類の制限に当たり続けている。逃げるより、当たる頻度を下げる運用を持つほうが早い。

次の一手としては、モデルの振り分けを決めるところから始めるのが手っ取り早い。「間違えたときに自分で気づけるか」で線を引けば、今日から仕分けられる。

ムラサキ

制限は敵ではなく、作業の区切りを外から入れてくれる仕組みだと思うことにした。そう捉え直してから、止まったときのストレスが減った。

解約する前は「チャットが制限つきになったら困るだろうな」と身構えていた。実際に効いたのは、まったく別のところだった。

SE歴20年、平日の朝晩と週末のすきま時間で副業ブログを回している筆者が、解約から4ヶ月近く経った時点で振り返る。結論から書くと、記事作成は何も変わらなかった。はっきり痛かったのは画像生成が消えたことだけで、その代わりに選んだのは別のAIツールではなくPythonのコードだった。

ムラサキ

解約するとき「何が使えなくなるか」をリストアップするけど、そのリストは大体外れる。今回もそうだった。

2ヶ月で解約した｜きっかけはClaudeで足りてしまったこと

契約は2026年2月10日から4月9日まで

Genspark Plusを契約したのは2026年2月10日。解約したのが4月9日。ちょうど2ヶ月だ。

契約したときの目的ははっきりしていた。複数のトップモデルを1か所で切り替えたかったことと、画像生成を回数を気にせず使いたかったこと。この2つだった。契約中に何ができて、クレジットがどう減っていくかは、使っている最中にPlus契約中に測ったクレジット消費の実態としてまとめてある。この記事はその続きにあたる。

なお本稿で触れるGensparkの仕様・料金は、すべて筆者が契約していた2026年2月から4月までの時点のものだ。解約後は契約していないので、現在どうなっているかは確認していない。最新の料金はGenspark公式の料金ページで確認してほしい。

解約理由は不満ではなく「使い方が変わった」

誤解のないように書いておくと、解約はGensparkに不満があったからではない。

理由は一つで、Claudeで用が足りるようになったからだ。契約していた頃、筆者がGensparkで一番使っていたのは、AIチャット経由でClaude Opusに記事の骨格を作らせる作業だった。つまりGensparkは「Opusへの入口」として使っていた。

そのうちClaudeを直接契約して、Claude Code中心の運用に寄っていった。同じモデルに二重で払っている状態になったところで、片方を切った。それだけの話だ。サービスが悪くなったのではなく、こちらの使い方が変わって噛み合わなくなった。

解約して変わったこと・変わらなかったこと

解約前に「これが使えなくなるな」と思っていたことと、実際に効いたことを並べる。

予想が当たったものは一つもない。

記事作成｜何も変わらなかった

ここは解約前から予想がついていた。

Genspark経由で使っていたのは結局Claude Opusだったからだ。入口がGensparkからClaudeに変わっただけで、モデルも指示の出し方も同じ。骨格を作らせて、事実確認を人間がやって、整形して投稿する流れは解約の前後で変わっていない。今の作り方そのものはClaudeで記事を書くときの工程分担に書いたやり方をベースに回している。

中身が同じモデルなら、入口が変わっても出力は変わらない。当たり前の話だが、契約しているサービスの数だけ機能があるように錯覚しやすい。実際に何を経由して何を使っているかを一度書き出しておくと、やめたときに何が消えるかが正確に見積もれる。

チャット｜無制限がなくなった。ただし主因はGensparkではない

先に書いておくと、解約後も時間単位の利用制限そのものからは逃げられていない。当たったときにどう止めてどう再開しているかは制限に当たった時の中断と再開に手順としてまとめた。

ここは切り分けて正直に書く。

契約時点のGenspark Plusは、AIチャットが無制限だった。解約後は当然その枠がなくなり、Claude側の利用制限の中でやりくりすることになる。実際、Proプランでは足りなくなった。

ただしこれを「Genspark解約の代償」と書くのは正確ではない。同じ時期に、筆者はClaude Codeでの作業量を大きく増やしている。記事パイプラインの開発、サイトのスニペット改修、ナレッジベースの構築。ここでのトークン消費が制限に効いた度合いのほうが、チャット分より明らかに大きい。

つまり「Gensparkをやめたからチャットが足りなくなった」ではなく、「Claude Codeを使い込むようになったから足りなくなった。Gensparkの無制限枠を失ったのはその一部」が実態だ。2つが同じ時期に起きたので混同しやすいが、原因の主従は逆にしないほうがいい。

実際に変わったのは使い方のほうだ。無制限の枠があったころは何でもOpusに投げていたが、今はトークン消費を意識するようになった。高度な判断が要らない作業はSonnetやHaikuに落とし、Opusは本当に必要な場面に取っておく。制限が「モデルを選ぶ」という習慣を作ったとも言える。この辺りはOpus・Sonnet・Haikuを層で使い分ける方法に実測込みで整理した。

エージェント検索｜代替できる認識

指示を投げて自律的に調べて回るタイプの機能は、解約後に「これがないと詰む」と感じた場面がない。

Claude側でも同種の調べ物はできるし、そもそも筆者の副業ブログでの使い方は、記事ネタの収集と事実確認が中心だ。この用途なら代替が効くという認識でいる。

ムラサキ

契約前に「これが目当て」と思っていた機能ほど、なくなっても平気だったりする。逆に空気みたいに使っていた機能が抜けると、いきなり作業が止まる。

画像生成だけが実害だった｜代替は別のAIではなかった

解約してはっきり困ったのが画像生成だ。

詰まっていたのは「絵」ではなく「文字」

もともと筆者はGensparkの画像生成でブログのアイキャッチを量産していた。ただし当時から満足していたわけではない。英語ですら文字が欠ける、日本語は完全に読めない、製品の数が合わない構図が出る。この問題は解約前から抱えていて、無料AI画像生成5ツールの文字精度比較で他のツールを一通り試した経緯もある。

崩れ方の実例が上の画像だ。「アイキャッチ画像作成失敗」と指示して4モデルに同時生成させた結果で、左上は「アイキャッチ」の後が実在しない漢字の羅列に置き換わっている。他の3枚も文字の欠けや重複がある。英語ならまだ読める形になることもあるが、日本語はこの水準だった。

そのときの結論は「Ideogramでベース画像を作ってCanvaで日本語を載せる」という2段構えだった。動く方法ではあるが、1枚あたり人の手が入る。記事を書くたびに毎回この工程を踏むのは、本業のあいまに回している運用だと地味に重い。

解約をきっかけに前提を疑った。そもそもアイキャッチにAI画像は要るのか。

筆者のブログのアイキャッチに必要なのは、記事タイトルとサブタイトル、3ステップのラベル、サイトカラーの背景だ。写真的なリアリティは一度も必要になっていない。だとすればAIに絵を描かせる工程は丸ごと要らない。

もう1つの動機と、まだ答え合わせできていないこと

正直に書いておくと、移行を後押しした動機はもう1つあった。AdSenseの審査に何度も落ちていたことだ。

否認が続いていた時期に、作業を手伝わせているAIアシスタントから「AI生成画像を使っていることが評価に影響している可能性がある」と指摘された。心当たりがゼロではなかったので、これも背中を押した。

ただしここははっきりさせておきたい。この仮説は現時点でも検証できていない。AI画像生成をやめた後も、AdSenseにはまだ合格していない。「AI画像をやめたら通った」という話は書けない。

そもそもAdSenseがAI生成画像そのものを禁じているという一次情報を、筆者は確認できていない。否認理由として通知されてきたのは一貫して「有用性の低いコンテンツ」で、画像について名指しされたことはない。だからこれは仮説のまま動いた話であって、対策として他人に勧められるものではない。

移行して確実に効果を確認できたのは、前述の文字崩れと日本語描画のほうだけだ。動機は2つあったが、回収できたのは片方しかない。

AI画像生成をやめて、Pythonで合成する方式にした

現在このブログのアイキャッチは、AI画像生成APIを一切呼ばずに作っている。

やっていることは単純だ。サイトごとに用意したテンプレートPNGに、Pillowでテキストとアイコンを合成している。日本語フォントはNoto Sans JPのBoldを埋め込み、ステップのアイコンはFont Awesomeのソリッド系フォントから描画する。出力は1200×630pxのWebP。

コードの中心はこれだけだ。

from PIL import Image, ImageDraw, ImageFont

img = Image.open("templates/shumatsu.png").convert("RGB")
draw = ImageDraw.Draw(img)
font = ImageFont.truetype("NotoSansJP-Bold.ttf", 64)

draw.text((80, 180), "Genspark解約の記録", font=font, fill=(255, 255, 255))
img = img.resize((1200, 630), Image.LANCZOS)
img.save("eyecatch.webp", format="WEBP", quality=85)

何が良くなったか

文字が崩れる問題は、そもそもAIが文字を描かないので消えた。日本語が読めない問題も同じだ。フォントで描いている以上、指定した文字が指定したとおりに出る。ここは狙いどおりに解決した。

生成にかかる時間は1秒未満。画像生成APIを呼ばないので追加コストは0円。作り直したくなっても、文字列を変えて再実行するだけで済む。3サイト分のテンプレートを用意してあるので、サイトを跨いでもテイストがぶれない。

一方で、もう1つの動機だったAdSenseのほうは動いていない。移行後も審査には通っていないので、あの仮説が当たっていたのかどうかは分からないままだ。移行して確実に取れたのは文字の再現性と生成コストで、審査の結果は別の話として残っている。

失ったものもある。写真的な画像やイラスト調のバリエーションはもう作れない。ただ筆者のブログではその必要が発生していないので、今のところ困っていない。

多機能サービスを解約するとき、事前には見えていないこと

今回の解約から学んだことを整理する。

「よく使う機能」と「代わりがない機能」は一致しない

筆者が一番時間を使っていたのは記事作成だった。だから解約で一番影響が出るのもそこだと思っていた。実際は中身が同じClaude Opusだったので、何も起きなかった。

影響が出るのは「使用頻度が高い機能」ではなく「他で置き換えられない機能」だ。この2つは重なるとは限らない。解約を検討するなら、頻度で並べるのではなく「これが消えたとき、代わりに何をやるか即答できるか」で並べたほうがいい。

代替候補を同じカテゴリの中だけで探さない

画像生成が使えなくなったとき、最初に考えたのは「じゃあどのAI画像生成ツールに移るか」だった。これが罠だった。

同じカテゴリの中で探すと、そのカテゴリが持つ弱点ごと引き継ぐことになる。AI画像生成の日本語文字問題は、2026年3月時点でツールを変えても解決していなかった。カテゴリの外に出て「そもそも画像をAIで作る必要があるか」を疑ったところで、この問題については答えが出た。

ただし「答えが出た」と言えるのは文字と日本語描画に限った話だ。同時に抱えていたAdSenseの仮説は、カテゴリの外に出ても解決していない。移行で片づいた課題と、移行しても残った課題は分けて数えたほうがいい。まとめて成功として数えると、次に何を試すべきかが見えなくなる。

数字が集中している記事があると、判断が鈍る

これは解約そのものとは別の話だが、書いておく。

このブログでは契約中に書いたGensparkのレビュー記事が、検索流入の柱になっている。1本の記事に流入が集中していく実態でも数字付きで指摘したとおりだ。

すると「解約したら、あの記事が書きにくくなるのでは」という考えがよぎる。だが読者にとって有益なのは、契約中の推しレビューだけではない。やめた記録も同じくらい判断材料になる。検索で「解約」「高い」「課金すべき」と調べている人が求めているのは、むしろそっちだと思う。

解約前に自分に聞く4つの問い

今回の経験をチェックリストにした。契約を切るか迷っているときは、これを書き出してから決めている。

1. その機能、他のどのツールで代替するか即答できるか
2. 代替候補は「同じカテゴリ」の外にもあるか
3. 使わなくなった理由は、サービス側の変化か自分側の変化か
4. 解約後に困ったとき、再契約のコストはいくらか

3番目が意外と効く。サービス側が悪くなったのか、自分の使い方が変わっただけなのかを分けておくと、後で再契約を検討するときに迷わない。今回は完全に後者だった。

よくある質問（FAQ）

まとめ

Genspark Plusを2ヶ月で解約して分かったことは3つだ。

1つ目、記事作成は何も変わらなかった。Genspark経由で使っていたのがClaude Opusだったので、入口が変わっただけだった。

2つ目、チャットが制限つきになったのは事実だが、主因はGenspark解約ではなくClaude Codeの利用増だ。同時期に起きた変化は切り分けて見ないと、判断を間違える。

3つ目、実害は画像生成だけだった。そしてその代替は別のAIツールではなく、Pillowでテンプレートに文字を合成するPythonスクリプトだった。

ただしこの3つ目は、まだ半分しか答えが出ていない。移行の動機は「文字が崩れる」ことと「AI生成画像がAdSenseの否認に効いているかもしれない」ことの2つあった。前者は解決した。後者は、やめた後も審査に通っていないので、当たっていたのかどうか分からないままだ。仮説のまま手を動かして、片方だけ回収できた状態と言ったほうが正確だと思う。

解約を迷っているなら、値段で決める前に「消えたら代わりに何をやるか」を機能ごとに書き出してみてほしい。書けない機能が1つでもあれば、そこが本当の依存点だ。筆者の場合、それは事前に想像していた機能ではなかった。

ムラサキ

やめてみないと、自分が何に依存していたかは分からない。2ヶ月分の料金は、それを知る授業料としては安かった。答え合わせが済んでいない部分は、通ったときにまた書く。

SE歴20年の筆者が平日の朝・夜のすきま時間で運営しているこのブログ、4ヶ月目時点で累計出費は87,971円。API課金だけで毎月1,700円前後を払い続けていた。それが今月、工夫ひとつで消えた。もちろん良いことばかりじゃない。AdSenseは今月も落ちた。4回目だ。

数字が伸びた｜ユーザー約1.9倍・クリック約2倍の中身

このシリーズはずっと4週間サイクルで数字を追ってきた。4ヶ月目が5/14〜6/13、今回の5ヶ月目が6/14〜7/13。この区切りで正確に比べる。

正直に言うと、この伸びを「サイト全体が強くなった」と読むのは早い。中身を見ると、特定の記事に検索流入が集中しているだけだ。4ヶ月目記事でも同じ指摘をしたが、5ヶ月目でその傾向はむしろ強まっている。次の項で具体的に見ていく。

ムラサキ

掲載順位が8.0→7.5に上がったのは地味だけど嬉しい。順位1つの改善に何をしたわけでもなくて、ただ記事を書き続けてSearch Consoleのヘルプが言う「継続的な品質シグナル」が積み上がっただけだと思う。

主力記事はさらに集中｜Genspark記事の一人勝ち

5ヶ月目のGA4上位記事はこうなっている。

なお流入を支えているこのGenspark記事は、契約中に書いたレビューだ。その後Plusは解約しており、やめた側から見た記録を別記事として公開して、依存を1本に集めない形にしている。

Genspark Plusを使い倒したレビューが単独で全体の3割近くを持っていく。2位のClaude Code×GAS自動化記事は6月に公開したばかりの新顔で、公開1ヶ月でここまで来た。これは素直に嬉しい。

一方でこの集中は諸刃の剣でもある。Genspark記事1本のクリック数や順位が落ちれば、全体の数字が一気にしぼむ構造になっている。特定記事への依存を下げる意味でも、Claude Code×GAS記事のような新顔をもっと育てる必要がある。

アフィリエイト｜クリックは出るが成果はまだ0円

先月、もしもアフィリエイトに100件申請して6件承認された話を書いた。あれから収益は動いたか。

正直に数字を出す。5ヶ月目（6/14〜7/13）の週末起業ラボの実績は、インプレッション449・クリック19件・発生成果0件・収益0円。CTRは4.2%で、クリックされる率自体は悪くない。ただし成果（成約）はゼロのまま。

審査の承認と、実際に読者が申し込んで成約することは、まったく別の話だった。プログラムに参加できる権利を得ただけで、そこから先はまだゼロからのスタートだ。1ヶ月目からずっと「収益0円」を報告してきたこのシリーズだが、今月もその記録は途切れなかった。

AdSense4回目否認｜変わらない壁

7月11日、4回目のAdSense審査結果が出た。否認。理由は3回目と同じ「有用性の低いコンテンツ」。

4ヶ月目の時点で「6週間待った末の不合格」と書いたが、今回も理由は変わっていない。何を変えれば通るのか、正直まだ掴みきれていない。AdSenseのポリシーヘルプには「読者に真の価値を提供するオリジナルコンテンツ」と書かれているが、その基準の解像度が上がらないまま4回落ちている状態だ。

ムラサキ

同じ理由で4回落ちると、さすがに「量」の問題じゃなくて「質」の何かがずれているんだろうと思う。次の申請前に、記事の作り方そのものを見直すタイミングかもしれない。

投稿ペースが落ちた理由｜YouTube多角化との天秤

4ヶ月目（6/14）以降、新規投稿はアフィリエイト審査記事とセキュリティ記事の2本だけだった。理由は単純で、ブログ記事をAI音声で動画化するワークフローに時間を使ったのと、本業側の予定が立て込んでいたからだ。

YouTube側の実績を正直に出す。チャンネル全体で通算8本、5ヶ月目期間に該当するのは4本（うち非公開1本）。公開3本の視聴回数を合計すると25回。チャンネル全体でも53回にとどまる。

正直、時間をかけた割に効果はまだ小さい。GA4で見てもYouTube経由のブログ流入は直近7日でわずか1人。動画化した記事がブログの流入を底上げする、という4ヶ月目時点で期待していたシナリオは、5ヶ月目時点ではまだ実現していない。

ここで一つ、恥ずかしい話を書いておく。この項目の実績を最初に集計したとき、パイプラインのログを機械的に数えて「31本」「36本」という数字を出しかけた。だが実際にYouTube Studioでチャンネルの中身を見ると8本しかなかった。ログは失敗・再試行した回数まで拾っていて、実際にチャンネルに存在する動画数とはまったく別物だった。ツールの出力を検算せずに信じるとどうなるか、身をもって体験した5ヶ月目でもあった。

出費と収支｜API課金がゼロになった理由

出費の中身を4ヶ月目と並べる。

X側の工夫は2段構えだ。まずMake経由の投稿を廃止し、Buffer無料プラン（3チャンネルまで）への直接投稿に切り替えた。運用サイトが3つ以内なら、この移行だけでX APIの従量課金自体が発生しなくなる。これが829円→0円の直接の理由だ。もう一つ、これとは別に管理している投稿先ではX APIを直接使い続けているが、本文にURLを含めるとAPIコストが跳ね上がるため、URLなし投稿＋URL付きリプライに分けてコストを抑える工夫もしている。ただしこちらはコストの軽減であって、ゼロ化とは別の話だ。Make撤廃の経緯や他の代替手段の比較はMake→X自動投稿の代替ガイドにまとめているので、そちらを参照してほしい。

Claude側は、パイプライン内のAPI呼び出し箇所をVertex AI（Gemini）に置き換えた。当初この記事では「GenAI App Builder」向けトライアルクレジット159,556円分が効いてゼロ化できていると書いたが、これは筆者の誤認だったので訂正する。GCPコンソールで再確認したところ、このクレジットは使用範囲が特定プロダクトに限定されていて、うちのパイプラインが使う素のGemini API呼び出しには適用されていなかった（残高100%のまま動いていない）。実際にゼロ化の正体だったのは別枠の汎用無料トライアルクレジットで、こちらは2026年7月9日に期限切れ。以降は普通に課金が発生していて、実測で月数百円規模だ。Gemini 2.5 Flash自体の単価が安いので大きな痛手ではないが、「クレジットで無料」ではなく「単価が安いから低額」が正しい前提だった。

5ヶ月目の累計出費は107,664円（87,971円＋19,693円）。累計収益は22円のまま変わらず、純損失は107,642円に拡大した。

よくある質問

まとめ｜5ヶ月目の学びと6ヶ月目の方針

5ヶ月目を一言でまとめると「数字は伸びた、API課金は消えた、AdSenseの壁は変わらない」だ。ユーザー数約1.9倍・クリック約2倍という伸びは事実だが、中身はGenspark記事1本への依存が強まっているだけとも言える。

API課金ゼロ化は素直な成果だった。月1,500円強の削減は小さく見えるが、副業の収支が22円しかない状態では大きい。一方でAdSenseは4回連続で同じ理由の否認、アフィリエイトはクリックが出ても成約ゼロ。収益化の壁は5ヶ月経ってもまだ厚い。

6ヶ月目は、特定記事への依存を下げる新しい主力記事づくりと、AdSenseの否認理由に正面から向き合うことを軸にする。これまでの記録は1ヶ月目からすべて公開しているので、興味があれば読み比べてみてほしい。

1. AIにインシデント調査を任せたら、AI自身が「存在しない攻撃」を確定事実として報告してきた。原因はClaude CodeのPostToolUse hook。ツールが返す値を改ざんし、調査するAIごと騙す手口だった。ツール出力を一次情報として鵜呑みにしないための、裏取り手順をまとめた。

AIにコードやインシデント調査を任せる人が増えた。でも、そのAIが見ている「ツールの出力」が偽物だったら、どうなるか。

2026年6月、筆者の開発環境にプラグイン経由で2つのhookが仕込まれた。厄介だったのは、作業が壊されたことではない。インシデントを調査させたAI自身が、後で否定されることになる「存在しない攻撃」を確定事実として報告してきたことだ。

SE歴20年、本業ではSEマネージャーをやっている。攻撃の検知と切り分けは場数を踏んできたつもりだった。それでも一度は騙された。この記事は、その手口と、同じことが起きても見抜くための裏取り手順の記録だ。

ムラサキ

先に言っておくと、攻撃コード本体はもう手元にない（削除済み）。だから「コードの全文解説」はしない。代わりに、AIがなぜ騙されたのかと、どう裏を取るかに振り切る。

何が起きたか——調査するAIが偽の証拠を作らされた

確定している事実から並べる。

プラグイン経由で仕込まれた2つのhook

.claude/hooks/ に post-tool-filter.ps1 と session-start-genshijin.ps1 が設置されていた。どちらもPowerShellスクリプトだ。出どころはClaude Codeプラグイン経由のサプライチェーン攻撃が疑わしいが、インストール履歴自体が改ざんされていた可能性があり、攻撃元プラグインの実在は今も確定できていない。

このうち実害が出たのが post-tool-filter.ps1。名前のとおり「ツール実行後の出力をフィルタする」hookだ。

PostToolUse hookが実際にやったこと

ここが本題になる。post-tool-filter.ps1 が動いている間、AIが受け取るツール出力が書き換わっていた。観測できた効果は3つ。

• affiliate_click のカウントが強制的に「0」表示になる（実値は別に存在する）
• ファイル編集時に </body> タグが出力から消え、編集が着地しない
• 特定の文字列が置換・改変される

「本当に改ざんされているのか」は、答えがわかっている値で確かめた。あるセッションで affiliate_click を読むと 0。hookを止めてから同じ値を読むと 42。出力経路のどこかで値がすり替わっていた、動かぬ証拠だ。

いちばん巧妙だったのは「調査の汚染」

作業が壊れるだけなら、まだいい。気づける。本当に効いたのは、調査そのものが汚染されたことだった。

• Readツールの結果が偽造されていた可能性
• git diff の出力に偽のコンフリクトマーカーが挿入された
• タイムスタンプが偽造され「18:44に3ファイル同時作成」という”攻撃の証拠”が生成された

調査するAIは、これらを「ツールが返した事実」として受け取る。そして筆者も、AIの報告を受け取る。攻撃者は、自分の攻撃を裏付ける”証人”をAIに作らせていた。

graph TD
  A["ツール実行"] --> B["PostToolUse hook"]
  B --> C["出力を改ざん"]
  C --> D["AIが現実と誤認"]
  D --> E["偽の調査結果を出力"]
  E --> F["人間が信じてしまう"]
  style B fill:#f3e7e7,stroke:#c39595
  style C fill:#f3e7e7,stroke:#c39595

なぜLLMは偽のツール出力を信じるのか

技術的にも認識論的にも、これは”バグ”ではなく構造の問題だ。

LLMにとって「ツールが返した値」＝現実

LLMは、ファイルの中身もコマンドの結果も、自分の目で確かめているわけではない。ツールが返してきたテキストを、そのまま現実として扱う。人間が「Readの結果＝ファイルの中身」と信じるのと同じ構図だ。だから、その経路に偽の値を流し込めれば、LLMは偽の現実を信じる。疑うための材料を、そもそも持っていない。

PostToolUse hookはツール出力に介入できる（公式仕様）

hookはそもそも、Claude Codeを便利にする正規機能だ。フォーマッタを自動実行したり、危険なコマンドを止めたり。Hooksの基本と使いどころはHooksの基本と便利な使い方で触れている。

問題は、その権限の広さにある。公式ドキュメントの仕様として、PostToolUse hookはツール出力（特にMCPツールの出力）を改変でき、additionalContext でClaudeのコンテキストに任意のテキストを注入でき、stderr に書いた内容はそのままClaudeへのフィードバックになる。そして決定的なのは、コマンドhookが実行ユーザーの全権限で動くこと。公式ガイドも、設定に追加する前にすべてのhookコマンドをレビュー・テストするよう明記している。仕様の詳細はAnthropicのClaude Code公式Hooksガイドで確認できる。

これはOWASP LLM Top 10が指す構造そのもの

新しい話に見えて、枠組みはすでにある。OWASPのLLM向けTop 10は、プロンプトインジェクション（LLM01の解説）を最大の脅威に置く。核心は「モデルは”指示”と”データ”を確実に区別できない」こと。両方が同じテキストとして届くから、データの中に紛れた指示に従ってしまう。

今回はその変種だ。攻撃は「プロンプト」ではなく「ツール出力」に注入された。さらにプラグイン経由という点でサプライチェーン（LLM03）、ツール出力を検証せず信じた点で不適切な出力処理（LLM05）にもまたがる。各カテゴリはOWASP GenAI Top 10に整理されている。

私が「確定」させてしまった誤情報

ここは恥を書く。あるセッションが「確定」とした内容のうち、後の独立調査で否定されたものがある。最初の報告を鵜呑みにしていたら、ありもしない脅威に何時間も対応するところだった。

後の独立調査で否定された5つの「脅威」

なぜ誤情報が「確定事実」になったか

どれも、もっともらしかった。タイムスタンプは具体的、サービス名はそれっぽい、ログには痕跡”らしきもの”があった。AIはそれを「ツールが返した値」として処理し、確信度の高い言葉で報告する。人間（筆者）は、そのAIの確信に引きずられた。

誤情報の供給源は外（攻撃者）。でも「確定」のハンコを押したのは、AIと人間の側だ。ここがいちばん怖い。

今も「不明」のままにしていること

誠実に書くと、確定できていないことがある。断定はしない。

二度と騙されないための裏取り手順

教訓は一つに尽きる。一つのツール出力を、それ単体で真実として処理しない。複数経路で同じことを確かめる。具体的に4つやる。

原則–数値・存在・時刻は別経路でクロスチェックする

AIの報告でも、ツールの出力でも、「数字・ファイルの有無・タイムスタンプ」は一次情報として扱わない。別の手段で同じ値を取り、一致するかを見る。一致しなければ、どちらかが汚染されている。

この発想は、AIに記事を書かせて数字を捏造されたときの再発防止策と同じだ。実際、ツール出力が改ざんされてAIが偽の事実を信じた今回も、既知の値を使った改ざん検知が決め手になった。クラウド側のガードレール（入力・出力の検査）の考え方は、AWSが日本語でまとめた生成AIのプロンプトインジェクション対策が入口として読みやすい。

FILTERTEST–既知の値で改ざんを炙り出す

いちばん効いたのがこれ。答えがわかっているファイルを読ませて、期待値と一致するかを見る。今回なら affiliate_click=42 とわかっている状態で読み、0 が返ったら出力経路が汚染されている、と即断できた。

# 1) FILTERTEST：既知の値で出力の改ざんを検知する
"FILTERTEST_VALUE=42" | Set-Content -Path .\filtertest.txt
$expected = 42
$actual = (Select-String -Path .\filtertest.txt -Pattern '\d+').Matches.Value | Select-Object -Last 1
if ($actual -ne $expected) { Write-Warning "出力経路が汚染されている可能性" }

# 2) タイムスタンプはGet-Itemで直接取得し、AI経由の値と照合する
(Get-Item .\suspect.ps1).LastWriteTime

# 3) 件数は素の数値で取る（整形済みテキストより改ざんに気づきやすい）
(Select-String -Path .\app.log -Pattern 'affiliate_click').Count

改ざんしにくい経路を選ぶ

タイムスタンプは Get-Item で直接取り、Readツール経由の値と照合する。行数や件数は Select-String -Pattern ... | Count（grepなら -c）のような”素の数値”で取る。整形済みテキストを介すより、すり替えに気づきやすい。同じ問いを別ツール・別手法で2回投げて、答えが一致するかを見る–それだけで汚染は浮く。

Claude Code固有–hookとプラグインの自衛

最後にClaude Code側で。導入前は、プラグインのhookが実行ユーザー権限で動く前提に立つ。中身を読まずに入れない。.claude/hooks/ と settings.json の hooks 設定を定期的に確認する。異変時は /hooks で登録済みhookを一覧でき、設定ファイルに disableAllHooks: true を入れれば全hookを一括停止できる。まず止めて、クリーンな状態で再検証する。今回のように「hook停止の前後で同じ値が変わる」なら、それが出力改ざんの確定診断になる。

よくある質問（FAQ）

まとめ

要点は3つ。

• PostToolUse hookは、AIが見るツール出力に介入できる。出どころ不明のhookは、作業を壊すだけでなく、調査するAIごと騙せる
• LLMは「ツールが返した値」を現実として扱う。だから数値・存在・時刻は、単体の出力を信じず別経路でクロスチェックする
• FILTERTEST（既知の値で確かめる）と、hookの一括停止・/hooks 確認を、自分の環境に一つずつ仕込んでおく

体系的に詰めたい人向けに一冊だけ。今回のような「AIを過信させない業務フロー」を、OWASP/PCI DSSベースのチェックリストやポリシー雛形付きで整理した生成AIセキュリティの実務ガイドは、設計段階の防御を考えるとき手元にあると早い。

ムラサキ

一度騙された経験から言うと、効くのは大層な仕組みじゃない。「答えがわかっている値を一つ読ませて、合うか見る」。それだけで、AIの確信に引きずられる前に立ち止まれる。

1. 2026年4月の週末、2日でアフィリエイト案件に100件超申請した。承認はわずか6件。落ちた理由を分類すると、避けられるミスと構造的な壁が見えた。申請文テンプレも丸ごと公開する。

「アフィリエイトを始めよう」と思って最初にぶつかるのが、ASPの提携審査だ。記事を書く前の段階で、ここで止まる人が多い。

SE歴20年、副業で日本語のSaaS比較サイトを運営している筆者が、2026年4月の週末2日間で、PartnerStack経由のアフィリエイト案件に100件超まとめて申請した。結果は承認6件。HubSpotもActiveCampaignも落ちた。理由すら返ってこない案件もあった。

この記事では、その全申請ログから「落ちた理由の分類」と「実際に使った申請文テンプレ」を公開する。収益の話ではない。審査を一気に通すための、申請そのものの実務に絞る。

ムラサキ

正直、半分も通れば御の字だと思ってた。フタを開けたら承認6件。でも落ち方を並べてみたら、次に活かせるパターンがちゃんとあった。

どこに何件、どうやって申請したか

申請先はPartnerStackに集中させた。多くのSaaS企業がアフィリエイトプログラムをここに集約していて、1か所で大量に申請できる。

申請対象は自分のサイト1つ。日本語のSaaS比較サイトで、3日で713ページ作ったpSEOサイトがそれだ。比較記事・代替ツール紹介・カテゴリランキングを自動生成している構造で、SaaS案件との相性がいい。

PartnerStackの便利なところは、1アカウントで複数サイトを共通利用できる点だ。サイトごとの厳密なURL審査はほとんどなく、アカウント単位でまとめて案件に申請していける。だから「サイトを1つ作ったら、関連案件を一気に出す」という戦い方ができる。

PartnerStack以外では、impact.comとA8.netも併用した。impact.comはDropboxやSlackなど大手が多く、A8.netは国内案件に強い。ただ今回の主戦場はあくまでPartnerStackだ。

100件を2日で出せた理由は「申請文テンプレ」

100件超を週末2日で出せたのは、申請文を毎回ゼロから書かなかったからだ。フォームの入力項目はどの案件もほぼ同じ。サイト説明・宣伝方法・想定流入・国を、テンプレで固定した。

実際に使っているのがこれだ。案件名の部分だけ差し替えて、あとはコピペで回した。

Business description:
[YourSite] is a Japanese programmatic SEO comparison site helping Japanese
businesses discover and compare SaaS tools. We publish in-depth comparison
articles, alternative guides, and category rankings targeting Japanese SMBs
and startups.

How to promote:
SEO-optimized comparison and alternative articles in Japanese on [yourdomain.com]
targeting Japanese SMBs. [Tool] will be featured in comparison pages,
alternative guides, and category rankings.

Audience size: 1,000-10,000 monthly visitors
Primary country: Japan

[YourSite] と [yourdomain.com] は自分のサイト名・ドメインに置き換える。

ポイントは3つある。

まず、サイトの性質（pSEO比較サイト）と宣伝方法（比較記事・代替ガイド）を具体的に書くこと。「ブログで紹介します」だけだと弱い。どのページにどう載せるかまで書くと、審査側がイメージしやすい。

次に、Primary country: Japan を必ず明記すること。これは後述する「中国向けと誤認される」事故を防ぐためだ。

最後に、想定流入を盛らないこと。1,000-10,000 monthly visitors のように正直なレンジで書く。盛っても、後述のトラフィック閾値で結局バレて落ちる。

落ちた理由カタログ：4つに分類できた

承認6件（livestorm / streak / webcatalog / todoist / plesk / niural）に対して、否決は大量に出た。だが理由を並べると、きれいに4タイプに分かれた。

トラフィック閾値で落ちる＝今は無理な壁

HubSpotは「月1,000訪問者未達」、ActiveCampaignは「月500セッション未達」で落ちた。これは申請文をどう磨いても無理だ。サイトの実績そのものが足りていない。

ここで大事なのは、落ちた案件を捨てないこと。「閾値未達リスト」として別管理し、PVが育ってから再申請する。最初に全部通そうとしない。

PVが要件に届かないもどかしさは、初収益22円だった副業ブログ4ヶ月目の現実にも書いた。数字が育つまでは、通る案件から固めるしかない。

自分のミスで落ちる＝避けられる

一番もったいないのがこれだ。Kit（旧ConvertKit）は、紹介記事を公開する前に申請してしまい、「URL leads to broken page（リンク先が壊れたページ）」として否決された。

審査担当は申請されたURLを実際に見にくる。中身がまだ無いページを出せば、当然落ちる。サイトと該当記事を公開してから申請する。これだけで防げた1件だった。

構造的に申請不可＝最初から弾く

QuickBooksは米国居住者専用で、EINかSSN（米国の納税者番号）が必須だった。日本在住の時点で申請してもまず通らない。Mailchimpに至ってはアフィリエイトプログラム自体が2023年に終了していた。

これらは申請する前に「日本居住者OKか」「プログラムが今も生きているか」を確認すれば、申請枠も時間も無駄にせずに済む。

理由不明の否決もある

ClickUpなど、理由が開示されないまま落ちた案件もいくつかある。ここは正直に書くと、明確な原因はわからない。考え込んでも答えは出ないので、深追いせず次に進むのが現実的だった。

申請でハマった落とし穴

分類に入りきらない、地味にハマったポイントも共有しておく。

日本語サイトを「中国向け」と誤認される

否決理由に、想定オーディエンスの地域ミスマッチが返ってきたことがある。日本語サイトなのに、なぜか中国向けの流入と判断されたらしい。

対策はシンプルで、申請文に「Japan-based audience（日本のオーディエンス向け）」だと明記して返信した。最初からテンプレに Primary country: Japan を入れておけば、この往復は減らせる。

Declinedでも別ルートが残ることがある

impact.comでは、Marketplace経由の申請がDeclined（却下）になったあと、ブランド個別のページ経由でアクセスできるケースがあった。一度落ちても、別の入口から再申請できる余地が残ることがある。

ただし、この回避ルートは案件によって挙動が違う。確実な手順として一般化はできないので、「一度の却下で完全に諦めなくていい」程度に捉えておくのがいい。

ムラサキ

落ちた瞬間は「あ〜」ってなるけど、ASPの審査は一発勝負じゃない。条件が変われば通ることも多い。落ちたログこそ次の申請リストになる。

よくある質問

まとめ

副業のアフィリエイト審査を2日で100件超回してわかったことは、3つに集約できる。

1つ目、申請文はテンプレ化する。サイト説明・宣伝方法・想定流入・国の4項目を固定すれば、100件でも週末2日で出せる。

2つ目、落ちる理由は事前に潰せる。公開前申請（broken page）、居住地条件、終了プログラム。この3つを申請前にチェックするだけで、無駄な否決が大きく減る。

3つ目、閾値で落ちた案件は捨てない。PVが育ってから再申請する「寝かせリスト」として管理する。審査は一発勝負ではない。

まずは要件のゆるい案件から数本通して、アフィリエイトの土台を作る。流入を伸ばす取り組みと並行で進めるのが、遠回りに見えて一番速い。申請後の実際のクリック・成果は副業ブログ5ヶ月目の実績に記録している。

1. 副業ブログ4ヶ月目（5/14〜6/13）の全数字を公開する。3ヶ月連続0円だった収益が、ついに22円だけ発生した。検索クリックは前月の約2倍に伸び、検索経由が流入全体の78%を占めるまでになった。一方でAdSenseは3回目の申請が否認され、4回目を出し直したところだ。

副業ブログを始めて4ヶ月。SE歴20年の筆者が、毎月の数字を一円単位・1PV単位で公開している。

3ヶ月目までずっと0円だった収益が、4ヶ月目にして初めて動いた。Amazonアソシエイト経由で、22円。金額だけ見れば笑ってしまう額だが、0と22のあいだには大きな差がある。0は「何も起きていない」だが、22は「仕組みが動き始めた」を意味する。

この記事では、4ヶ月目の全数字（PV・検索流入・収益・出費・AdSense・YouTube）を、いつものように包み隠さず出す。

副業ブログ4ヶ月目の全体サマリー

まず1〜4ヶ月目の全指標を並べる。

4ヶ月目を一言でまとめると「数字は伸びた、収益は0円を脱した、審査は振り出し」だ。累計の出費は87,971円、累計の収益は22円。差し引き87,949円の純損失が続いている。

ムラサキ

3ヶ月続けて収益0円を公開してきたから、22円でも素直に嬉しい。これが「0→1」だ。

数字が伸びた｜検索クリック1.8倍・滞在2倍

4ヶ月目で一番はっきり伸びたのが検索周りだ。

Search Consoleのクリックは前月の108から220へ、約2倍に増えた。表示回数も2,664から4,768へ約1.8倍。CTRは4.05%から4.6%へわずかに改善した。平均掲載順位は7.9から8.0とほぼ横ばいで、順位そのものが上がったというより、上位に入る記事の数が増えて表示とクリックが伸びた、という構図だ。

GA4側も動いている。PVは380から415、ユーザー数は180から327へ大きく増えた。平均セッション時間は3ヶ月目の63.7秒から125秒へ、ちょうど2倍。読者が以前より長く読んでくれている。

流入チャネルの内訳（セッション420中）はこうなった。

• Organic Search：329（78.3%）
• Direct：79（18.8%）
• Referral：5 / Organic Social：3 / Organic Video：2

検索経由が流入全体の8割に近づいた。1ヶ月目に検索流入が9.3%しかなかったことを思えば、別サイトのようだ。検索流入を主軸にする方針は、4ヶ月目でほぼ完成形に近づいた。判断指標の見方はSearch Console公式ヘルプを参照している。

小さな新顔もあった。AI検索からの流入だ。ChatGPTから2セッション、Claude（claude.ai）から2セッション。3ヶ月目はChatGPT・Copilot・Perplexityの3経路だったが、4ヶ月目はclaude.aiが新たに加わった。数は小さいが、検索エンジン以外の入口が育ち始めている。

Genspark記事が主力になった｜特定記事への検索集中

4ヶ月目の検索流入は、ある1記事に集中した。Genspark Plusの実機レビュー記事だ。

GSC上位ページ（クリック数）を見ると一目瞭然だった。

サイト全体のクリック220のうち、Genspark記事だけで83。約4割をこの1記事が稼いだ計算だ。流入クエリも「genspark デメリット」「genspark 5時間制限」「genspark plus 料金」と、契約前に欠点や制限を調べる検討段階のユーザーが中心だった。

検索意図がはっきりした製品名クエリは、刺されば安定して流入を生む。実際に課金して使ったNotebookLMの活用記事も2位につけており、一次情報のある記事が評価されやすい傾向は4ヶ月目でも変わらなかった。

ムラサキ

記事数を闇雲に増やすより、実際に金を払って使い込んだ製品レビューが効く。当たり前のようで、数字で見ると改めて納得する。

初収益22円｜0→1の意味

そして4ヶ月目の主役、初収益だ。

Amazonアソシエイト（もしもアフィリエイト経由）で、22円の成果が初めて発生した。3ヶ月連続で0円だったので、ようやく0の壁を越えた。

正直、22円では何も買えない。コンビニのコーヒーにも足りない。それでも、この1件は「読者が記事のリンクを経由して、実際に何かを買ってくれた」という事実を意味する。アクセスが収益につながる経路が、初めて成立した。

アフィリエイトは、成果が出るまでに時間がかかるのが普通だ。検索流入が伸び始めてから収益が動くまでにはタイムラグがある。4ヶ月目で初収益22円は、早くも遅くもない、ごく平均的な立ち上がり方だと考えている。問題は金額そのものより、ここから積み上がるかどうかにある。

ちなみに、この収益につながるアフィリエイト提携も、申請の段階でかなり落ちている。2日で100件超を出して、通ったのは6件だけだった。その申請文テンプレと否決の理由は別記事に全部まとめている。

出費と収支｜4ヶ月累計87,971円

4ヶ月目の出費内訳はこうなった。

前月の22,894円から1,676円減らせた。動画音声は3ヶ月目までGoogle Cloud TTSを使っていたが、4ヶ月目からElevenLabsへ切り替えた。

X APIの829円は、本ブログとは別に運用しているClaude Codeで713ページのpSEOサイトを作った仕組みの自動投稿に使っている。

4ヶ月の累計では、出費87,971円に対して収益22円。純損失は87,949円。撤退ラインを「半年」と決めているので、5・6ヶ月目も淡々と続ける。

AdSense3回目否認｜6週間待った末の不合格

4ヶ月目で動きがあったのがAdSenseだ。ただし良い動きではない。

4月17日に出した3回目の申請が、5月29日に否認された。申請から約6週間。3ヶ月目のレポートを書いた時点では「準備中のまま無音」だったが、長い沈黙の末の不合格通知だった。否認理由は過去2回と同じ「有用性の低いコンテンツ」だ。

過去の経緯を並べるとこうなる。

• 1回目：約2週間で否認
• 2回目：約1ヶ月で否認
• 3回目：4/17申請 → 6週間沈黙 → 5/29否認
• 4回目：6/4再申請（結果待ち）

否認を確認した6月4日、間を置かず4回目を申請した。審査ステータスの意味はAdSense公式ヘルプに沿って確認している。

AI生成を主体にしたサイトがAdSenseに通りにくいのは事実だが、Googleは検索スパムポリシーで「生成方法ではなく品質で判断する」としている。検索評価（Search Console）の表示回数は4ヶ月で着実に増えているのに、AdSenseは通らない。この2つの評価軸のズレが、4ヶ月目時点での率直な悩みだ。

YouTube始動｜ブログ記事を動画化する多角化

4ヶ月目に新しく始めたのがYouTubeだ。チャンネル「週末起業ラボ」で4本を公開した。

• 5/24「Claude DesignからCode自動実装」（9:39）
• 5/26「ChatGPT vs Claude vs Gemini 企業AI」（8:10）
• 5/30「月780円でブログ→YouTube動画化」（9:40）
• 6/13「Genspark月6,500円は詐欺？」（10:26）

いずれも既存のブログ記事を題材にした動画で、音声にはElevenLabsを使っている。たとえば5/26の動画は、ブログのChatGPT・Claude・Gemini企業導入の比較記事が題材だ。ブログで一度書いた内容を動画に転用する形なので、ゼロから企画するより手間は少ない。ただし制作フロー自体はまだ試行錯誤の段階で、毎回同じ手順に固まっているわけではない。

視聴回数は各3〜4回とまだ小さい。それでもGA4にOrganic Video（動画経由）の流入が初めて記録された。芽は出た。noteは3ヶ月目に1本出したきり止まっているので、4ヶ月目はYouTube一本に絞った。

よくある質問

まとめ｜4ヶ月目の学びと5ヶ月目の方針

4ヶ月目の要点はこうだ。

• 初収益22円：3ヶ月連続0円から、ついに0→1。金額は小さいが収益経路が成立した
• 検索が主軸に：クリック前月比約2倍、表示約1.8倍、検索流入78.3%、滞在時間2倍。順位は横ばいだが流入の母数が増えた
• AdSenseは振り出し：3回目が6週間待ちの末に否認、4回目を再申請。検索評価とのズレが続く
• YouTube始動：ブログ記事を題材に4本公開、動画経由流入が初発生

5ヶ月目は、Genspark記事のように「実際に課金して使った製品レビュー」を軸に、検索で勝てる記事を厚くする。AdSense4回目の結果も出るはずだ。1ヶ月目から続けてきた1ヶ月目のリアル収支、2ヶ月目の全記録、3ヶ月目の成績と合わせて読むと、伸びの流れが見えるはずだ。その5ヶ月目の結果は副業ブログ5ヶ月目の実績で公開している。

ムラサキ

4ヶ月で純損失8.7万円、初収益22円。数字だけ見れば惨敗だが、検索は伸び、収益も動き始めた。残り2ヶ月、淡々と続ける。

SE歴20年、いまは複数のブログをAIに下書きさせて運用している。正直、便利だ。それでもこの一件で、AIの文章力より先に疑うべきものがはっきりした。数字だ。

この記事では、2026年5月に実際にやらかした事故と、その原因–これは世間でいう「ハルシネーション」ではなかった–、そして同じ事故を二度と起こさないために決めた4つのルールを、隠さずそのまま公開する。

ムラサキ

正直、最初は「AIが嘘をついた」と思いました。でも調べたら、もっとタチの悪い話だったんです。

AIに記事を書かせて、本番に嘘の数字が載った

2026年5月、あるAIツール「Genspark」のレビュー記事をリライトしていた。SEOタイトルとメタディスクリプションを改善するつもりで、作業自体はAIに任せた。出てきた新しいタイトルには、こうあった。

「Gensparkを3ヶ月使い倒して……」

公開した。そのまま本番に反映された。問題は、私がGensparkを3ヶ月使ったなんて、一言も言っていないことだ。記事本文にも、手元のメモにも、「3ヶ月」という期間はどこにも存在しない。

気づいたのは公開後だった。自分の記事を読み返していて、書いた覚えのない期間表記に引っかかった。慌てて一次ソースを全部当たったが、やはり「3ヶ月」の出どころはない。結局、タイトルとメタから期間表記を削り、「使い倒した」だけに直した。

数字ひとつ。たかが数字ひとつ。でも、これが本番に載っていた事実は重い。レビュー記事で「3ヶ月使った」と書けば、読者はそれを根拠に信頼する。その根拠が、実在しなかった。

AIで記事を書く手順そのものは別記事のClaudeを使ったブログ記事の作り方にまとめているが、今日はその裏で起きる事故の話だ。

数字はどこから来たのか＝競合記事のスニペット流用

「3ヶ月」の出どころは競合記事だった

原因を探して、まず疑ったのは自分の指示ミスだ。でも履歴を見ても、私は期間を指定していない。次にやったのが、検索結果の競合記事チェックだった。

そこにあった。同じGensparkを扱う競合記事のタイトルが、こうだった。

「【辛口評価】Gensparkを3ヶ月使い倒してわかった『ここがダメ』」

「3ヶ月使い倒して」。完全に一致する。AIは記事をリライトするとき、上位の競合記事を構成の参考に読む。そのとき、構成だけでなく、競合が書いた具体的な数字まで一緒に引きずってきていた。

これはハルシネーションではなく「もっともらしいパクリ」

ここが、この事故のいちばん大事なところだ。

世間では、AIが事実と違うことを言う現象を「ハルシネーション（幻覚）」と呼ぶ。何もないところから、それらしい嘘を生成する–そういうイメージだ。

でも今回は違う。AIは何も幻覚を見ていない。実在する競合記事に書いてあった「3ヶ月」という数字を、文脈ごと取り込み、それを私（筆者）の体験として再構成しただけだ。つまり正体は、空想ではなく「もっともらしいパクリ」に近い。

この流れを図にすると、数字がどこで漏れたかが見える。

graph TD
  A["競合記事を構成参考に読む"] --> B["具体数値も文脈ごと取り込む"]
  B --> C["出力時に自分の実績として再構成"]
  C --> D["一次ソース照合なしで本番反映"]

この経路の怖さは、出力された文章が日本語として完全に自然なことだ。「3ヶ月使い倒した」は、文法的にも内容的にも、なんの違和感もない。だから人間が読んでもスルーしてしまう。嘘くさい嘘なら気づける。もっともらしい嘘は気づけない。

構成は参考にしてよくても、数字はダメ

誤解しないでほしいのは、競合記事を読むこと自体は悪くない。見出しの切り口や、読者がどんな疑問を持っているかを知るのに、競合チェックは有効だ。問題は、構成の参考と具体的な数値の流用の境界を、AIが勝手に踏み越えることにある。構成はOK、数字はNG。この線引きを人間側が握っておく必要がある。

なぜ怖いか｜3つのリスク

数字ひとつ、と侮れない理由を3つに分けて整理する。

信用失墜｜ひとつの嘘で全体を疑われる

読者は親切ではない。「3ヶ月使った」が嘘だと一度バレれば、その記事に書いてある他の情報も全部疑う。9割が正確でも、1割の捏造で記事全体の信頼がゼロになる。ブログの価値は積み上げた信用だ。それを数字ひとつで溶かすのは、割に合わない。Googleが示す有用で信頼性の高いコンテンツの作成ガイドラインでも、第一に問われるのは情報の信頼性だ。

コピー判定リスク｜競合と表現が一致する

競合のスニペットをそのまま引きずると、表現が競合記事と一致する。検索エンジンに「重複・模倣」と見なされれば、評価が下がる恐れがある。しかも今回のように相手が上位記事だと、後発の自分のほうがコピー側と判定されかねない。Googleのスパムに関するポリシーでも無断複製コンテンツは明確に問題視されている。捏造であると同時に、SEO上のリスクでもあるわけだ。

YMYL領域だと致命的｜金額・期間の嘘

副業や収支を扱うブログは、まさにこのYMYLの入り口にいる。だからこそ、数字には人一倍慎重でいたい。

再発防止ルール4つ

ここからが本題だ。事故のあと、自分のAI記事運用に組み込んだ4つのルールを共有する。どれも特別な道具はいらない。決めて、守るだけだ。

graph TD
    ROOT["🛡️ 数値捏造を防ぐ4つのルール"]
    ROOT --> A["① 一次ソース原則
出どころを4つに限定
本文記述・自分のメモ・発言・公式ソースのみ"]
    ROOT --> B["② 記憶照合
体験記述は筆者のプロフィールと照合
該当なければ書かないか確認する"]
    ROOT --> C["③ 本番前チェックリスト
N年・N回・N円の出所を確認
記事スニペットとタイトルの整合確認"]
    ROOT --> D["④ draft経由で公開
staging/draftでまず目視確認
本番を直接出力しない"]
    style ROOT fill:#4A90D9,color:#fff,stroke:#2c6fad
    style A fill:#e8f0fb,stroke:#4A90D9
    style B fill:#e8f0fb,stroke:#4A90D9
    style C fill:#e8f0fb,stroke:#4A90D9
    style D fill:#e8f0fb,stroke:#4A90D9

①一次ソース原則｜数字の出どころを4つに限定する

記事で使う数値・期間・回数・金額は、次の4つのどれかに出どころがある場合だけ使う。それ以外は書かせない。

• 該当記事の本文（すでに書いてある記述）
• 自分のメモ・ナレッジ（プロジェクト内の記録）
• 自分がその場で明示した発言・指示
• 公式ソース（公式サイト・公式アカウント・公式ドキュメント）の引用

競合記事のスニペットは、ここに入らない。構成の参考まで。具体的な数字は流用しない。これを徹底するだけで、今回の事故は起きなかった。

②著者の体験期間は、明記がなければ書かない

「Nヶ月使った」「8年やってきた」–こういう著者の体験談は、記事本文かプロフィールに明記がない限り書かない。AIは空欄を埋めたがるが、空欄は空欄のままでいい。

期間が確定していないなら、代替の表現を使う。

• 期間をぼかす：「使い倒したSE歴20年が」（SE歴はプロフィールにある事実なのでOK）
• 回数をぼかす：「実際にハマった事例」「実例つきで」

事実が手元にないなら、捏造ではなく省略を選ぶ。

③本番前チェックリスト｜公開前に数字で止める

公開ボタンを押す前に、機械的に止めて確認する。疲れているときほど、これが効く。

④draft経由で公開｜本番を直接いじらない

今回いちばん効いた反省がこれだ。本番記事を直接編集すると、ミスがそのまま公開される。間に下書き（draft）を挟む。AIが直すのは下書きまで。人間が下書きを確認して、はじめて再公開する。

ワンクッション置くだけで、「3ヶ月」のような数字に気づくチャンスが一回増える。事故は、チェックの回数を増やすだけで確実に減る。

チェックを仕組みに落とす

ここまで読んで、「結局は気をつける話か」と思ったかもしれない。違う。目視のチェックは必ず漏れる。人間は疲れるし、毎回同じ集中力では読めない。だから、ルールを気合いではなく仕組みに変える。

目視に頼らず機械的に止める発想は、記事生成だけでなくAIの調査結果そのものにも効く。実際、ツール出力が改ざんされてAIが偽の事実を信じた事例では、既知の値を使った改ざん検知が切り分けの決め手になった。

目視は漏れる前提で設計する

私がやったのは、記事を生成させるプロンプトそのものに「一次ソース外の数値・期間・金額は出力禁止」と明記することだった。AIが書く段階で数字を塞げば、人間が後から探す手間が消える。AI生成コンテンツに関するGoogleの公式ガイダンスでも、問われるのは生成手段ではなくアウトプットの品質だ。だったら、品質を担保する仕組みを生成の入口に置くのが筋がいい。

個人運用でも仕組みは作れる

「仕組み」というと大げさに聞こえるが、要はチェックを人の記憶からプロンプトやテンプレートに移すだけだ。個人でAIツールを開発・運用してきた経験はClaude Codeで個人開発をやってみた正直な話に書いたが、結局いちばん効くのは「人間が頑張る」を「仕組みが止める」に置き換えることだった。数値の捏造対策も、まったく同じ発想でいい。

まとめ

AIの数値捏造について、要点を3つに絞る。

1. AIは「それっぽい数字」を平気で盛る。疑うべきは文章力ではなく、数字だ。
2. その正体はハルシネーションより「競合スニペットのもっともらしい流用」であることが多い。構成は参考にしてよくても、数字は流用しない。
3. 防ぐ鍵は気合いではなく仕組み。一次ソース原則・体験期間の非創作・本番前チェック・draft経由–この4つをプロンプトとフローに組み込む。

ブログは信用の積み上げだ。私自身、副業ブログの数字を毎月そのまま公開してきたが（直近は副業ブログ3ヶ月目のリアルな収支に書いた）、その数字が一個でも嘘なら、連載ごと価値を失う。AIに任せる時代だからこそ、数字の出どころだけは人間が握っておきたい。

ムラサキ

「AIが書いたから」は言い訳になりません。公開した責任は、最後にボタンを押した人間にある。だからこそ、仕組みで守るんです。

よくある質問

ムラサキ

SE歴20年 · 金融系システム開発課長 · 週末起業1年目

システムエンジニア歴20年。金融系システム開発の課長として勤務する傍ら、AIと副業の最前線を実践レポート。Claude Code Max 5xプランを日常業務・副業開発に活用中。一次情報と実測値にこだわった記事を発信。

20 YRS SE

6 MOS 副業

44 ARTICLES

1. 完了条件を1文書くと、AIは条件を満たすまで自分でターンを回し続ける。
2. customer-portalの4機能を、逐次プロンプトなしで完走させた実体験ベース。
3. 効く条件の核心は「検証結果を会話に出させる」一文。公式情報で裏取り済み。

Claude Codeを毎日触っていて、地味にストレスだったのが「続けて」の連打だ。AIがひと仕事するたびに手を止めて、また同じ指示を打つ。SE歴20年で本業も副業もClaude Code Max 5xで回している筆者でも、この往復は効いた。

/goalコマンドはこの往復を消す。完了条件を1文書くと、AIは条件を満たすまで自分でターンを回し続ける。実際にcustomer-portalの生産パイプラインを設計工程まで広げる4機能を、逐次プロンプトなしで完走させた。この記事は、その実体験で分かった「効く完了条件の書き方」を軸に、Anthropicの公式ドキュメントで裏を取りながらまとめる。

ムラサキ

最初は半信半疑だった。でも一度走らせたら、詰まっても止まらず原因を追い続けるAIを横で見て、考え方が変わった。

/goalとは？「続けて」連打から解放される仕組み

「続けて」を何度も打っていた従来のClaude Code

通常のClaude Codeは1ターンごとに手を止める。テストを書いて、止まる。「続けて」。実行して失敗、止まる。「続けて」。長い作業ほど、この間に人が挟まる回数が増える。

問題は手数だけじゃない。人が間に入るたびに集中が切れ、AIがどこまで進んだかを毎回読み直すことになる。タスクが大きいほど、この「Enterを押す係」の負担が重くなっていく。

/goalの動作フロー：評価器が毎ターン完了判定するループ

/goalは完了条件をひとつ受け取り、その条件を満たすまでターンを自動で回す。Anthropicの/goalコマンド公式ドキュメントによると、各ターンが終わるたびに小さく速い評価モデル（既定はHaiku）が「条件は満たされたか」を判定する。未達ならその理由を次ターンへの指示として渡し、もう一度ターンを始める。条件が満たされた瞬間にゴールは自動で解除され、Claudeは通常モードに戻る。

graph TD
  A["ターン実行"] --> B["評価器が判定"]
  B -->|"未達 理由を渡す"| A
  B -->|"達成"| C["ゴール自動解除"]
  B -->|"打ち切り句"| D["停止"]
  style A fill:#e8eef6,stroke:#9fb3cc
  style C fill:#e8f3ec,stroke:#9ec7ad
  style D fill:#f3ece8,stroke:#c7b09e

筆者の実行では、途中で2回詰まった。1回目は"use server"ファイルでobjectをexportしてアクションが全滅したケース、2回目はagent-browserのclickがServer Actionを発火させなかったケース。どちらも/goalは「未達」と扱って継続させ、原因の特定から修正まで自走でやり切った。止まらず原因追及を続けるこの粘りが、人が「続けて」を打つ運用との一番の差だった。

コスト感覚：自走で消費トークンはどう変わるか

正直に書くと、正確なトークン数は筆者の手元では計測していない。ただ確認手段はある。引数なしで/goalを打てば、その時点のターン数とトークン消費が出る。これが唯一の実測手段だ。

体感はこうだ。「続けて」連打は人が間に入る分、自然にペースが制御される。一方/goalは人の入力なしで連続ターンが走るので、短時間に多くのターンが進み、消費は速い。判定役のHaiku分は、公式も本体ターンに比べて無視できる量だと明記しているので、評価器のコストは気にしなくていい。気をつけるべきは本体ターンの速度のほうだ。トークン単価そのものを詰めたい場合は、Opus・Sonnet・Haikuを役割で分ける3層スタックでコストを半減させる手順が効く。

完了条件の書き方：自走を成功させた実例

効いた条件の4要素

公式ドキュメントは、長いターン数を越えても崩れない条件の要素を挙げている。測定可能な終了状態、それをどう証明するかの手段、途中で壊してはいけない制約だ。筆者が実際に走らせて完走した条件は、これに打ち切り句を足した形だった。

/goal customer-portalの生産パイプラインを設計工程まで拡張する。
レビュー収束性・承認フロー・改訂自由指示・設計工程の横展開の4機能を実装し、
npx tsc --noEmit がエラー0で、各機能を実際にsupabaseで確認した結果を会話に示し、
既存機能を壊さないこと。 or stop after 60 turns

要素を分解すると、こうなる。

条件は最長4,000文字まで書ける。短くまとめる必要はないので、終了状態・証明手段・制約を遠慮なく詰め込んでいい。

最重要は「検証結果を会話に出させる」一文

4要素のなかで決定的だったのは、「supabaseで確認した結果を会話に示す」の一文だ。評価器は会話に出た内容しか見ない。コマンドを自分で叩いたりファイルを読んだりはしない。公式も評価器について、Claudeが会話で表に出したものしか判定できないと明記している。

つまり「検証結果を会話に出させる」と書くことで、AI自身が検証ログを吐くよう仕向けられる。この一文がないと、AIは内部で「できたつもり」になっても、評価器にはそれが見えず判定が進まない。逆にこの一文があると、AIは証拠を会話に残しながら進むので、判定がきれいに通る。

ムラサキ

「会話に出させる」を入れるか入れないかで、自走の安定感がまるで違った。評価器の目線で条件を書く、という発想が要る。

主観条件が引き起こす「止まれないループ」

逆に入れてはいけないのが主観条件だ。筆者は「UXを良くする」のような条件は最初から外した。評価器が良し悪しを測れないからだ。

公式が挙げる典型的な失敗例も「本番運用に耐える品質（production-ready）」型の条件で、検証可能な出力を生まないため達成判定が出ない。条件が甘すぎれば早すぎる解除、達成不能なら打ち切り句に当たるまで回り続ける。会話に証拠が出る客観条件だけが機能する–これは実際に走らせて骨身にしみた。

「指示を出す人」から「仕事を設計する人」へ

曖昧な指示はAIにも人にも通じない

完了条件を書く作業は、要するに「終わりの定義」を言語化する作業だ。これはAI特有の話じゃない。曖昧な指示は人間の部下にも通じない。「いい感じにして」で動ける人はいない。

AIの場合、曖昧さは別の形でも牙をむく。指示が緩いと、存在しない仕様を勝手に埋めてくることがある。プロンプトが育ちすぎて888行プロンプトで起きた破綻を一度経験すると、客観的に検証できる指示だけが効くという感覚が身につく。/goalの完了条件は、その感覚を毎回強制してくる。

完了条件を書く訓練が仕事の解像度を上げる

「会話に証拠が出る客観条件だけが効く」という制約は、副業開発でそのまま武器になる。何をもって完了とするかを1文で書けるなら、その仕事は設計できている。書けないなら、まだ自分の中でゴールが曖昧だということだ。

筆者がCLAUDE.mdとBUGS.mdを使い分ける運用に行き着いた経緯は個人サービスを作った正直な話に書いたが、結局どれも同じ方向を向いている。AIを動かすほど、自分の指示の甘さが可視化される。/goalはその最先端で、「指示を出す人」を「仕事の終わりを定義する人」に変えていく。

Agent View・/loopと組み合わせる（公式情報・筆者未検証）

claude agentsで並列セッションを一望する

複数のセッションを並列で回すと、ターミナルのタブが増えて、どれが終わったか分からなくなる。AnthropicはAgent Viewの公式発表で、claude agentsコマンド（またはセッション内で左矢印）から全セッションを1画面に並べる仕組みを示している。各行に「どれが入力待ちか・作業中か・完了したか」が出る研究プレビュー機能だ。

/goalを背景で走らせ、その進捗をAgent Viewで眺める、という組み合わせが想定できる。並列実行やHooksの基礎をまず固めたい場合は、/powerupで隠れ機能を体系的に学ぶ手順から入ると地続きで理解しやすい。

/loopとの違い：時間駆動 vs 完了駆動

/goalと混同しやすいのが/loopだ。公式の比較によれば、/goalは「前のターンが終わったら次が始まり、条件を満たすと止まる」完了駆動。/loopは「一定間隔で同じプロンプトを再実行する」時間駆動で、夜間テストや朝の定期チェックに向く。終わりが条件で決まる作業は/goal、決まった間隔で回したい作業は/loop、という切り分けになる。

朝に仕込んで夕方確認するハーフオート運用

公式は、開いたセッションとは独立に夜間テストや朝の仕分けを走らせるスケジューリングにも触れている。背景セッションとAgent View、あるいは/loopを組み合わせれば、朝に仕込んで夕方に結果だけ見る運用が描ける。ただし筆者の今回の実行はインタラクティブな単一セッションで、ここまで完走させたところまでだ。背景＋並列の本格運用は未検証なので、組み合わせる際は小さく試してから広げてほしい。

/goalが動かないときの前提条件

信頼ダイアログとフックシステム

/goalの実体は、セッション単位のStopフックのラッパーだ。だから公式のフックガイドが示すフックシステムが動く環境が前提になる。具体的には、信頼ダイアログを承認したワークスペースでないと/goalは動かない。承認していない場合、コマンドが理由を表示してくれるので、無反応で悩むことはない。

法人・チームのポリシーで無効化される

会社のmanaged policy設定でdisableAllHooksが有効になっていると、フックごと無効になり/goalも使えなくなる。チームや法人のClaude Codeで「コマンドが反応しない」場合は、まずこの管理ポリシーを疑うといい。これも公式のRequirementsに明記されている挙動だ。

バージョン確認とアップデート

/goalもAgent Viewも比較的新しい機能で、Agent Viewの研究プレビューはv2.1.139以降が要件とされている。claude --versionで確認し、古ければnpmで更新しておく。完了判定の精度はバージョンが上がるほど改善されているので、新しめに保つのが無難だ。

今日から始める/goal活用ステップ

副業開発で試すなら、いきなり大物に当てず、小さく回して感覚を掴むのが近道だ。

よくある質問

まとめ

/goalを実際に使って分かったのは、3つだ。

ひとつ、完了条件を1文書くだけで、AIは詰まっても止まらず条件を満たすまで自走する。ふたつ、効く条件の核心は「検証結果を会話に出させる」一文で、評価器は会話しか見ないからここが決定的。みっつ、客観的に検証できる終了状態だけが機能し、主観条件は止まれないループを生む。

まず手元で「続けて」を連打しているタスクを1つ選び、終わりを1文で書いてみる。それが書けたなら、その仕事はもうAIに渡せる。書けないなら、自分の中でゴールがまだ曖昧だというサインだ。/goalは、その曖昧さを毎回突きつけてくる道具でもある。

ムラサキ

「Enterを押す係」から卒業すると、空いた時間で次の設計を考えられる。副業の時間は有限だから、この差は大きい。

Google Workspaceの自動化は2軸で切る。1軸目は対象データ(メール／予定／表計算／ファイル／フォーム)、2軸目は処理タイプ(分類・通知／作成・転記／連携・横断)。本記事の7レシピはこの交点から、副業・本業の両方で投資対効果が高い組み合わせを抽出した。

ムラサキ

レシピ集の中には、すでに本サイトで実装記録を公開しているものと、Claude Codeへの投げ方だけ示す構想中のものが混在している。順序通り読まなくても、刺さるレシピから着手して問題ない。

なぜ今Claude CodeとGASの組み合わせが最強なのか

GASは無料で動く、Googleの中で完結する、認証は自分のGoogleアカウントで済む。副業エンジニア向けの3拍子がそろっている。一方で「書きはじめるまでが面倒」が長年のネック。Apps Scriptエディタを開いて空のmain関数を眺めて閉じる、を何度繰り返したか分からない。

そこにClaude Code Max 5xが噛み合う。仕様だけプロンプトで投げれば、claspで同期して動くコードまで生やしてくれる。試運転→修正→本番デプロイをローカルから一気通貫で回せる。エディタUIを開く頻度が一気に下がる。

事前準備：clasp導入とAPI認証の最短セットアップ

Claude CodeでGASを書く前提として、claspをローカルに通しておく。ここを省くとClaude Codeが書いたコードをコピペで運ぶハメになり、結局スピードが落ちる。

これで Claude Code が書いたコードを clasp push するだけで反映される。

レシピ1〜2：Gmail自動仕分け＆下書き生成で受信箱ゼロ運用

受信箱が日々パンクするなら、最初に攻めるのはここ。判定とラベリングをGASに任せれば、人間の判断は重要メールへの対応だけに集中できる。

レシピ1：重要メールをAI判定してラベル＆通知振り分け

GmailApp.search() で未処理メールを引いて、件名と本文の冒頭500字をGemini APIまたはClaude APIに渡す。判定値は「至急 / 重要 / 通常 / 不要 / 営業」の5値固定。結果に応じてGmailラベル付与とSlack通知を発火させる。

Claude Codeに投げるプロンプト例:

Gmailの未読メールを取得し、本文を500字に切ってGemini APIで5値判定。
判定値に応じてラベル付与とSlack Webhook通知を発火させるGASを、
[main.gs/config.gs/api.gs](http://main.gs/config.gs/api.gs) の3ファイル構成で書いて。APIキーは
PropertiesService経由で参照すること。

ファイル分割と参照経路まで指定すると、Claude Codeが「とりあえず1ファイルに全部」とやらかすのを防げる。

レシピ2：定型問い合わせへの返信下書きを自動生成

このレシピはGAS×Gemini API無料枠でメール返信下書きを自動化した実装記録で5パターン判定＋下書き生成のスプレッドシート設計まで含めて公開済み。コピペで動くコードを起点に、自分の業務パターンに合わせて分類軸を組み替えるのが最短ルート。

レシピ1の判定ロジックと組み合わせると、「通知だけ済ませる」と「下書きまで作る」の出し分けが可能になる。

レシピ3〜4：カレンダーとTo Doを連動させる予定管理レシピ

予定が増えるほど、準備作業まで頭の中で持ち回すコストが膨らむ。それを引き剥がす2レシピ。

レシピ3：会議招待から準備タスクを自動でTo Doに登録

CalendarApp.getEventsForDay() で当日の予定を取り、件名と説明欄をAPIに渡してタスクをN個抽出。Google Tasks API(Apps Scriptの Advanced Service として有効化)で対象日に登録する。

たとえば「営業同行打合せ」なら「先方資料の確認」「ヒアリングシート更新」が当日朝に積まれる。トリガーは平日朝7時の時間ベースで十分。

レシピ4：空き時間を解析して集中作業ブロックを自動確保

カレンダーの空きをスキャンして、90分以上連続するスロットを「集中作業」というイベントで予約してしまう。トリガーは毎週日曜の夜、翌週分をまとめて押さえる方式が運用が楽。

クォータ・スコープ的にも CalendarApp 内で完結するので、追加API登録が要らない。組み込みコストが最も低いレシピで、効果が一番体感しやすい。

レシピ5〜6：スプレッドシート＆ドライブの定型作業を撲滅

表計算とファイル操作はGASの土俵そのもの。Claude Codeに任せれば実装スピードが段違いに上がる。

レシピ5：請求書・領収書PDFをドライブから自動仕訳

DriveAppで指定フォルダ配下のPDFを走査し、Gemini APIのドキュメント読み取りで請求元・金額・支払期日を抽出。スプレッドシートに追記したうえで、年月フォルダへ自動移動させる。

本業／副業／個人の混在ファイルでも、フォルダ命名規則と仕訳タグでまとめて捌ける。確定申告期に「未仕訳の山」を作らないための先行投資として効く。

レシピ6：スプレッドシートの数値変動をSlack/Chatへ即通知

売上、PV、Search Consoleの主要指標などをスプレッドシートにダンプし、前日比・前週比を onOpen() またはトリガーで判定。閾値超過時にSlackやGoogle Chatへ即時通知する。

スプレッドシート操作と通知連携のノウハウはGAS×NotebookLMで本業メール集約を自動化した実践記で扱っているスクリプトと共通基盤。通知部分だけ差し替えればそのまま流用できる。

レシピ7：フォーム回答からドキュメント＆メールまでワンストップ生成

申込・問い合わせフォームは「来た瞬間に処理を始めたい」典型ケース。手動の写経を完全に消す最後のレシピ。

レシピ7：申込フォーム→契約書ドラフト→送信を全自動化

Formsのトリガー onFormSubmit で回答を捕捉。Google Docsのテンプレートを DriveApp.getFileById().makeCopy() で複製し、Body内のプレースホルダを置換して契約書ドラフトを生成。PDF化して GmailApp.sendEmail で関係者に送信する。

副業のクライアント契約、子ども関連の同意書、社内申請書類まで、テンプレートと差し込み項目さえ用意すれば横展開できる。

Claude Codeで”雑な指示”からGASコードを生やすコツ

プロンプトは「画面で見える流れ」を時系列で書くのが効く。雑に投げても Claude Code が補完してくれるが、clasp push で動く前提を成立させるには以下3点だけ最初に明示する。

• 入力：何を／どこから／どのくらいの量
• 処理：使うAPI・必要スコープ・分岐ルール
• 出力：どこに／どの形式で／通知の要否

この型に乗せれば、初手のコードは8割そのまま動く。残り2割は実行ログを見せて修正させればよい。Claude Code の機能を体系的に押さえたいならClaude Code /powerup入門のレッスン7〜8(カスタムコマンドとHooks)を先に通すと、自動化レシピの組み立てそのものが速くなる。

運用時の注意点とトラブルシューティング

動いたの先にある運用フェーズで、これだけは事前に詰めておかないと事故る。

実行制限・権限スコープでハマらないための設計指針

GASにはApps Scriptの割り当て上限(メール送信、トリガー実行時間、外部API呼び出し回数など)がある。一気にバッチ処理を回すと無料アカウントは即上限に到達する。設計時に押さえる3点:

• 件数を分割して走らせる(1回あたり50件など上限を決め打ち)
• ユーザートリガーと時間ベーストリガーを使い分け、同時実行で衝突させない
• スコープは必要最小限。最初から script.external_request 全許可にしない

詳細な数値はGoogle公式のApps Scriptクォータページで確認できる。設計前に1回必ず開く。

個人情報・APIキーを守るセキュリティチェックリスト

副業で動かす場合、本業データとの混在が一番の事故ポイントになる。最低限のラインを固定しておく。

• APIキーは PropertiesService.getScriptProperties() 経由でのみ参照。コード直書き禁止
• Gitに .clasp.json を上げる場合、リポジトリは必ずPrivate
• 本業データを扱うスクリプトは個人GoogleアカウントとWorkspaceアカウントで分離。同居運用は事故の温床
• Webアプリ公開(doGet/doPost)は「自分のみ」「全員」のスコープを必ず明示確認

ここを守れば、運用中に冷や汗をかく場面は激減する。

よくある質問

まとめ｜まず1レシピ動かしてから広げる

Google Workspaceの自動化は「対象データ×処理タイプ」の2軸で7レシピに分解した。番号順に全部揃える必要はない。実装記録を公開済みのレシピ2や、追加API登録なしで効果を体感しやすいレシピ4など、刺さるところから着手すれば十分だ。

1. Claude Codeに仕様だけ投げて clasp push まで一気通貫で回すと、書きはじめの腰の重さが消える
2. 制限・スコープ・キー管理は最初に固めないと運用フェーズで事故る
3. レシピ集は実装済みと構想中が混在している。刺さるレシピから着手し、動かしながら残りを埋めていけばよい

次のアクションは、レシピ2(メール返信下書き)のSE歴20年の業務自動化術で扱っている運用設計を起点に、自分の業務パターンに刺さるレシピから着手するのが最短ルート。

1. Claude Opus 4.8は4.7の正常進化。料金は$5/$25のまま据え置き。Fast modeが前世代比3倍安く、バグ見逃しは4.7の約1/4に。新しいeffort制御で「速さとコスト」を自分で握れるようになった。

新しいモデルが出るたびに気になるのは「で、副業の財布にいくら響くの？」だと思う。結論から言うと、Claude Opus 4.8は値上げなしの性能アップ。2026年5月28日にAnthropicが公開し、API料金は$5/$25（入力/出力・100万トークンあたり）で4.7から据え置きのまま、ベンチマークと正確さが上がった。SE歴20年でClaude Code Max枠を毎日回している筆者の視点で、副業・フリーランスに効くポイントだけ抜き出して整理する。

ムラサキ

正直、新モデル＝値上げを身構えてたんですが、今回は据え置き。日々トークンを溶かしている側としては、これだけで十分ありがたいニュースです。

Claude Opus 4.8とは？Opus 4.7から何が変わったか

Opus 4.8は、ゼロから作り直した新世代ではなく、4.7を土台にした品質向上版という位置づけ。Anthropicの発表記事「Introducing Claude Opus 4.8」でも、コーディング・エージェント・推論・実務タスクのベンチマーク全般で4.7を上回ったと説明している。前提として、Opus 4.7時点の副業での立ち位置はOpus 4.7発表時の使い分け基準に整理済みなので、4.7を触っていた人はそこからの差分で読むと早い。

主な改善点：価格据え置きで性能・正確さが向上

押さえるべき変更は3つだけ。料金が$5/$25で据え置き、Fast modeが前世代比3倍安く、そして「コードの欠陥を見逃さず指摘する」正確さが4.7の約4倍に上がった。Anthropicは後者を「honesty（誠実さ）」の改善と表現していて、根拠の薄いまま『できました』と言い切る傾向が減ったとしている。

加えてデフォルトの思考量（effort）がxhighからhighへ下がった。これは性能ダウンではない。公式によると、4.8のhighはコーディングで4.7のデフォルトとほぼ同じトークン量で、スコアはむしろ上というチューニングが効いている。同じ働きをより少ない手数で、というのが今回の地味だが効く進化。

ベンチマークで見るOpus 4.8の実力（GPT-5.5との比較）

GPT-5.5との比較で見ると、Opus 4.8は得意・不得意がはっきり分かれる。発表記事とSystem Cardの数値を主要軸だけ並べると、こうなる。

ブラウザ・PC操作と知識労働ではGPT-5.5を上回る一方、コマンドライン主体のTerminal-Bench 2.1ではGPT-5.5に一歩譲る。ここは隠さず書いておきたい正直な弱点。なお各ベンチは評価ハーネスの違いで数値が動くので、厳密な検証はClaude Opus 4.8 System Cardで確認するのが確実。副業用途なら、ターミナル一発勝負よりもエージェント的に手順を回す場面が多いはずで、その意味では4.8の伸びは噛み合っている。

副業・フリーランスがOpus 4.8で得られる3つのメリット

数字に落とすと、副業規模でも効く変化が見えてくる。

追加コストゼロのアップグレード：$5/$25は変わらない

フロンティアモデルの更新で値上げしないのは、AI業界ではむしろ珍しい。Opus 4.8の通常料金は入力$5・出力$25（100万トークンあたり）で、4.7とまったく同じ。すでにOpusのコストで回している人は、財布の前提を変えずに性能だけ受け取れる。乗り換え判断で「値上げ分が見合うか」を計算しなくていい–この時間の節約こそ、地味だが大きい。

Fast modeが3倍安く：APIコスト削減の具体計算

Fast modeは「速度のための上乗せ料金」で、Opus 4.8では入力$10・出力$50。標準の2倍だが、前世代のFast（Opus 4.6時代は$30/$150）と比べると、ちょうど3分の1に下がった。

副業規模で試算してみる。1回あたり入力20万＋出力10万トークンの処理を、月100回回す前提だと、こうなる（公式料金からの筆者試算）。

ここで早とちりしないでほしい。速度が要らないなら標準が最安。Fastの値打ちは、待ち時間が成果に直結する処理を「現実的なコストで速くできる」点にある。前世代だと月2,100ドル相当で手が出なかったFast運用が、700ドル前後まで降りてきた。対話的なセッションや、レビューを何往復もする作業でこそ効く。

バグ見逃しが4倍少ない：コーディング副業での実用価値

副業でコードを書く人に一番効くのが、この正確さの改善。Anthropicの評価では、Opus 4.8は自分が書いたコードの欠陥を見逃さず指摘する確率が4.7の約4倍に上がった。AIが『動きます』と言ったコードが実は壊れていた、というあの手戻りが減る方向の変化だ。レビュー工数を外注している感覚の個人開発者にとって、これは単価以上の価値になりうる。

実際にAIごとのバグ検出力がどれだけ違うかは、実バグ6本でのレビュー精度の差を測った検証で具体的な差が出ている。モデル選びの判断材料として合わせて見ると、4.8の伸びの意味がつかみやすい。

新機能「effort制御」を副業ワークフローに組み込む

今回の隠れた主役は、モデルそのものより「effort制御」かもしれない。

effortレベル別の使い分けガイド（low/medium/high/extra/max）

effortは、Claudeがどれだけ深く考えるかを自分で回せるダイヤル。公式ドキュメント「Effort（Claude API Docs）」によると、レベルはlow・medium・high（既定）・extra・maxの5段階。highより上は思考頻度と深さが増し、下げるとレスポンスが速くなりレート消費も穏やかになる。Claude Codeでは extra が「xhigh」という名前で出てくる点だけ覚えておけばいい。

この制御は、月額のClaude Proから最上位のMaxまで全プランで使え、追加料金もかからない。claude.aiとCoworkではモデルセレクタの隣に並ぶので、画面からそのまま切り替えられる。

API側でも同じ発想で指定する。

# Messages API で effort を指定するイメージ
message = client.messages.create(
    model="claude-opus-4-8",
    effort="high",   # low / medium / high(既定) / extra / max
    max_tokens=64000,
    messages=[...],
)

extra や max を使うときは、思考に必要なトークン余地を確保するため max_tokens を大きめ（公式の目安は64,000から調整）に取るのがコツ。

週末起業家が毎日使うタスク別のeffort設定例

「全部highでいい」と思いがちだけど、副業のタスクは難易度がバラバラ。手元の作業を雑に振り分けると、こんな具合になる（筆者の運用方針）。

ポイントは「難所だけ上げる」。Claude Codeはeffortを上げた分のトークン増を見込んでレート上限が引き上げられているので、難しいタスクで遠慮なくextraを使い、軽い作業はlowに落として温存する–このメリハリが、月末のレート切れを防ぐ一番効く運用になる。

ムラサキ

個人的に一番うれしいのが、軽い作業をlowに落とせること。SNS文の量産でレートを食いつぶす、みたいな事故が減りそうです。

SonnetとOpus 4.8、どちらを使うべきか？

「とりあえずOpus」を卒業すると、コストはぐっと締まる。

コスト比較：Opus vs Sonnetの価格差と費用対効果

料金はSonnet 4.6が$3/$15、Opus 4.8が$5/$25。入力で1.67倍、出力で1.67倍の差だ。ブログ自動化のような月間ワークロード（入力500万＋出力200万トークン）で並べると、Sonnetが月$45、Opusが月$75で、差は月$30前後（筆者試算）。

この差を「Opus一択」で毎回払う必要はない。日常の実装や定型処理はSonnetで回し、設計や難所だけOpusに投げる–この発想を具体化したのがOpus・Sonnet・Haikuでコストを半減する3層の組み方で、モデル単価の差をそのまま月額の差に直結させない設計の実例として読める。

副業タスク別の使い分け判断フロー

迷ったときの分岐はシンプルにできる。

graph TD
  A["タスクを確認"] --> B{"難所・設計判断あり?"}
  B -->|"はい"| C["Opus 4.8"]
  B -->|"いいえ"| D{"長文脈の横断理解?"}
  D -->|"はい"| C
  D -->|"いいえ"| E["Sonnet 4.6"]
  C --> F{"待ち時間が重要?"}
  F -->|"はい"| G["Fast mode併用"]
  F -->|"いいえ"| H["標準で実行"]
  classDef opus fill:#dde8f5,stroke:#9bb4d4;
  classDef sonnet fill:#e3f0e3,stroke:#a9cba9;
  class C,G,H opus;
  class E sonnet;

設計判断や長文脈の横断理解が要るならOpus 4.8、そうでなければSonnet 4.6。Opusに振った中でも、待ち時間が成果に効くならFastを足す。この3問だけで、コストと品質のバランスはだいたい収まる。

注意点：Opus 4.8で変わらないこと・制限事項

良い話ばかりではない。先に知っておくと損しない2点。

Dynamic WorkflowsはClaude Code Enterprise/Team/Maxで利用可

同時公開された「Dynamic Workflows」は、Claude Codeが数百の並列サブエージェントを走らせ、出力を検証してから報告する大規模タスク向けの機能（研究プレビュー、Claude Code v2.1.154以降）。利用は全有料プランが対象で、Max・Teamは既定でオン、ProとEnterpriseは有効化が必要（Proは/config、Enterpriseは管理者設定）。実際に副業で走らせた手触りは別記事にまとめる予定。

高effort設定でのトークン消費量に注意

effortは便利だが、上げれば上げるほどトークンを食う。extraやmaxは思考も手数も増えるぶん、同じタスクでも消費が膨らむ。Claude Code側はレート上限が引き上げられているとはいえ、APIで従量課金している場合は青天井になりうる。「難所だけ上げる」を徹底し、走らせっぱなしの自動化ではmaxを安易に常用しないのが安全。Opusのトークナイザは入力に対して生成トークンが増えやすい特性もあるので、移行前に自分のワークロードで概算しておくと事故が減る。

よくある質問

まとめ

Opus 4.8は派手な新世代ではなく、副業の現場にじわっと効くアップデートだった。要点は3つ。

1. 料金は$5/$25で据え置き。値上げ分の計算なしに性能だけ受け取れる。
2. Fast modeが前世代比3倍安く、バグ見逃しは4.7の約1/4。速さと正確さの両方が現実的なコストに降りてきた。
3. effort制御で「難所だけ深く、軽作業は速く」を自分で握れる。Sonnetとの使い分けと合わせれば、月のAIコストはまだ削れる。

まずは普段のタスクをlow/high/extraにざっくり振り分けて、1週間レート消費を眺めてみるところから。自分のワークロードの「どこにコストが乗っているか」が見えると、Opus 4.8の据え置き料金とeffort制御は一気に武器になる。

ムラサキ

据え置きでこの伸び幅なら、乗り換えで悩む理由はほぼなし。あとは自分の作業をどうeffortに割り振るか、ですね。