「AI臭いサイト」は、もう誰にも読まれない
正直に言う。
MakeとClaudeを組み合わせた「自動まとめサイト」は、2024年を境にその賞味期限が急速に切れ始めている。
理由は単純だ。読者も、Googleも、賢くなったから。
「Claude先生が要約しました」感が漂う無機質な文章。どこを見ても同じ構造の商品羅列。読んでいて一切ワクワクしない、コンセプトゼロの量産型アフィリエイト記事。そういったサイトのクリック率は下がり続け、収益は雀の涙になっている。
では、生き残るサイトは何が違うのか。
答えは「感情とコンセプト」だ。
「ズボラちゃんが妄想しながら商品を選ぶ」というコンセプトで設計した「ズボラちゃんの妄想通販」がその実験台だ。キャラクターが商品を「妄想レビュー」する体裁を取ることで、同じAI生成でも読者が「なんか好き」と感じる温度が生まれる。
ただ、そのコンセプトを形にするための自動化構築が、想像を絶する地獄だった。
その地獄の全記録を、今から書く。
【地獄編】楽天市場APIが「401エラー」で轟沈する、本当の理由
Makeから楽天市場のAPIを直接叩こうとした瞬間、こんなエラーが返ってきた。
Service is not reachable
400 DataError「URLのスペルが違うんじゃないか」「アプリIDが古いんじゃないか」──あらゆる可能性を潰した。大文字のIと小文字のlの見分けがつかないフォント問題にも気づいて修正した。新しいアプリIDを発行し直した。
それでもダメだった。
次に判明したのが、IPアドレス問題だ。
Makeは海外サーバーから動作している。楽天のAPIサーバーから見ると、「どこの馬の骨かわからない海外のIPが、商品データを根こそぎ持っていこうとしている」という状況に映る。楽天側のセキュリティロジックが、それを自動で弾く。
解決策として、MakeのサーバーIPを楽天の許可リストに登録する方法がある。Makeのドキュメントを調べると、使用しているIPアドレスが16個記載されていた。
16個、全部、手動で、一個一個、登録した。
テストした。
Service is not reachable変わらなかった。
ここで気づいた本質的な問題がある。楽天APIは、海外からの自動アクセスに対して根本的に防御的な設計になっている。 IPを登録しても、リクエストのヘッダーやアクセスパターンがボット的と判定されれば弾かれる。個人開発者が「正面突破」で勝てる相手ではなかった。
【絶望編】「もしもアフィリエイト」リンクが壊れる、Makeの恐ろしい罠
APIエラーと並行して、もう一つの地獄が待っていた。
アフィリエイトリンクの破損問題だ。
「もしもアフィリエイト」の楽天リンクは、ベースURLに商品URLをパラメータとして連結する構造になっている。Makeのシナリオの中でこのURLを組み立てようとすると、こんな壊れ方をする。
moshimo.comhttps://item.rakuten.co.jp/...原因はMakeの文字列連結処理にある。URLを扱う一部の関数が、プロトコル部分（https://）を重複させたり、前後のドメイン文字列と誤って結合させたりするバグ的な挙動を起こす。
これに気づかず投稿し続けたとしたら、全記事のリンクが死んでいたことになる。
【救済編】関数をすべて捨てろ。「生のURL直結」が唯一の正解だった
両方の問題を解決した方法を、順番に書く。
① 楽天API問題：「スプレッドシート経由」という無敵の迂回ルート
楽天APIとMakeの直接接続を、完全に諦めた。
代わりに採用したのが、「スプレッドシート（Googleスプレッドシート or Excel）に一度データを預ける」という設計だ。
[楽天API] → [スプレッドシート（国内から定期更新）] → [Make] → [Claude] → [WordPress]スプレッドシートへのアクセスは、国内の通常ユーザーと同じ経路で行われる。楽天側のセキュリティフィルターに引っかかる要素がない。Makeはスプレッドシートから行データを読み込むだけなので、楽天とは直接戦わない。
エラー発生確率、理論上ゼロ。
遠回りに見えるが、これが最も安定した設計だ。
② リンク破損問題：URLは「生のまま直結」が正義
もしもアフィリエイトのリンク生成で発生するmoshimo.comhttps問題の解決策はシンプルだ。
Makeの文字列関数を一切使わず、生のURLをそのまま連結する。
Makeのテキストフィールドに直接こう書く。
https://af.moshimo.com/af/c/click?a_id=【自分のアフィリエイトID】&p_id=54&pc_id=54&pl_id=616&url={{商品URLの変数}}※ 【自分のアフィリエイトID】の部分は、もしもアフィリエイトの管理画面から取得した自分固有のIDに置き換えること。このIDは他人に見せるものではないので、ブログ等には絶対に公開しないこと。
関数でURLをエンコードしたり、encodeURL()で処理しようとすると、プロトコル部分が二重になったり、文字列が意図しない形で結合されたりする。変数をそのまま埋め込む形にすることで、余計な処理が入らず、正しいURLが生成される。
about:blank#blockedが出る場合は、最終的なURLをログで確認し、https://が一つだけ存在しているかを必ず検証すること。
【資産化】このエラーを乗り越えた「仕組み」そのものが、最強の商品になる
ここで視点を変えて話したい。
今回の格闘で構築したシステムは、単なる「自動投稿ツール」ではない。
- 楽天APIの直接接続が不安定であることを知っている
- スプレッドシート経由という迂回ルートで安定稼働させた実績がある
- もしもアフィリエイトのURL破損問題と解決法を体得している
- Claudeの2段階構成で「AI臭さを消す」文章生成フローを持っている
これら全部を「再現可能な仕組み」として整理すれば、それ自体がnoteやBrain、あるいはコンサル商品として高単価で売れる情報資産になる。
「ズボラちゃんの妄想通販」というサイトの収益だけが目標ではない。このサイトを構築・運営するプロセスで積み上がる「泥臭い実戦知識」こそが、他の誰にも真似できない差別化資産だ。
苦労した時間は、コンテンツだ。格闘したエラーは、実績だ。諦めかけた夜は、信頼になる。
次のステップ：「スプレッドシート自動収集フロー」の完全構築へ
楽天APIとの正面衝突を諦め、迂回ルートを確立した今、次のフェーズに入る。
スプレッドシートに楽天の売れ筋商品データを自動で収集・更新するフローの構築だ。これが完成すれば、ズボラちゃんは文字通り何もしなくても、商品データが集まり、記事が生まれ、投稿される。
うまくいくかどうかは、まだわからない。
でも今回わかったことがある。エラーが出た時点では「詰み」に見えても、一段上から俯瞰した設計を考えれば、必ず突破口はある。
次回の記録も、全部さらけ出す。
【このサイトについて】
「ズボラちゃんの妄想通販」は、AI×自動化で「寝てても稼げるブログ」を目指す公開実験サイトです。
使用ツール：Make / Claude / Perplexity / もしもアフィリエイト / WordPress（Cocoon）/ ConoHa WING
コメント