こんにちは、みのり（@minori_aimama）です。本業・育児の合間にAI×ブログ副業に挑戦中です。
今日は、アフィリエイトブログで商品記事を書くときにやっていた、商品リサーチのやり方を書きます。AIに商品を自由に調べさせるのではなく、先に根拠になるソースだけを集めて、そこから商品情報を作る流れです。結論から言うと、主役はNotebookLMで、その繰り返し作業をClaude Codeから半自動で回すのにnotebooklm-pyを使っていました。
最初にひとつだけ補足を。このリサーチ方法は、現在は一部運用が変わっています。ただ「AIに読めないソースをどう補うか」という考え方はいまも効いているので、当時のフローとして残しておきます。
AIに商品を自由に調べさせると、根拠が曖昧になる
商品記事をAIに書かせるとき、いちばん怖いのがハルシネーションです。
AIに「この商品について調べてまとめて」とお願いすると、それっぽい表がすぐ出てきます。ただ、その数字がどこから来たのかが分からない。実際、確認すると微妙に違っていたり、そもそも存在しない仕様が混じっていたりします。
そこで途中から、やり方を逆にしました。AIに検索させるのではなく、こちらで根拠になるソースを先に集めて、それだけを読ませる。参照できる情報を閉じてしまう、というやり方です。
集めていたソースはこのあたりです。
- 公式サイト
- 取扱説明書のPDF
- 楽天の商品ページ
- 楽天レビュー
- LP画像
公式情報と取扱説明書があれば、基本スペックは押さえられます。でも、その商品が「どう売られているか」「買った人が何を良いと感じ、何に困ったか」までは、公式だけだと拾いきれませんでした。
参照させる情報を先に絞ることが、いちばん手前のハルシネーション対策でした。
Claude Codeから、楽天の商品ページとレビューが読めなかった
ここで詰まりました。
記事制作はClaude CodeとObsidianで回しています。ソース集めもそのままClaude Codeにやらせたかったのですが、楽天の商品ページと楽天レビューを、Claude Codeから直接取得できませんでした。
公式サイトや取扱説明書は読めます。でも、商品リサーチでいちばん欲しかった「販売ページ上の訴求」と「購入者の生の声」が、ちょうど読めないところに固まっていた。
公式情報だけで書くと、当たり障りのない記事にはなります。ただ、読者が本当に知りたいのは「実際どうなの」の部分です。そこがソースから抜けてしまうのは、けっこう痛い穴でした。
いちばん欲しい情報ほど、AIが直接読めない場所にありました。
そもそも楽天系をAIで直接読めるのか粘って検証した記録は、別の記事にまとめています。
NotebookLMを、商品リサーチの「中継地点」にした
そこで思い出したのがNotebookLMです。
NotebookLMなら、楽天系のページもソースとして読み込めました。公式情報・取扱説明書・LP画像・楽天レビューを、ひとつのノートブックにまとめて入れられる。
役割分担はこうです。
- Claude Codeで公式情報や取扱説明書などのソースを集める
- 直接取得できなかった楽天系は、NotebookLMを経由して補う
- 最終的に必要なソースをひとつのノートブックにそろえ、その閉じたソース群に質問する
楽天系はあくまで「NotebookLMを使うことになった理由」で、実際に質問を投げるときは、公式・取説も含めた全ソースをNotebookLMに集約していました。
そのうえで、集めた閉じたソースだけを参照させて、商品情報を質問で引き出す。ここで大事なのは、NotebookLMに記事を書かせたわけではない、ということです。あくまで、記事を書く前に根拠のある商品データを作る場所として使いました。
NotebookLMは要約ツールというより、Claude Codeが直接扱えないソースも一度受け止めて、記事の手前で商品データにまとめる中継地点になっていました。
「AIが読めないソースを一度別のAIに預ける」という発想で、穴がふさがりました。
notebooklm-pyで、ソース投入と質問を半自動化した
中継地点はできた。ただ、今度は手作業がしんどくなってきました。
商品ごとに、毎回これを繰り返します。
- ノートブックを作る
- URL・画像・PDFを投入する
- 同じ質問を投げる
- 回答をObsidianに移す
1商品なら大したことはありません。でも商品が増えるほど、同じ操作の繰り返しが地味に重くなる。ブラウザを行ったり来たりする時間が、じわじわ効いてきました。
そんなときにGoogleのおすすめで見かけたのがnotebooklm-pyでした。NotebookLMをCLIから操作できる非公式ツールで、Claude Codeのスキルとしても登録できる。これなら、さっきの繰り返しをClaude Codeから回せるはず。
実際に組んだ流れはこうです。
- ソースのURL・画像・PDFを準備する
notebooklm createでノートブックを作るnotebooklm source addでソースを投入するnotebooklm askで定型の質問を投げる- 返ってきた商品情報をObsidianに保存する
コマンドにするとこのくらいの分量です。
notebooklm login --browser msedge
notebooklm auth check --test
notebooklm create "{商品名}"
notebooklm source add <URLかファイルパス> --notebook <id>
notebooklm ask --prompt-file <質問.txt> --notebook <id> --json --timeout 180質問はいつも同じ4項目にしていました。ここを固定したことで、商品が変わっても同じ形のデータが返ってくるようになります。
| 取得する項目 | 中身 |
|---|---|
| スペック表と概要 | 基本仕様をまとめて把握 |
| 公式の訴求ポイント | 売り手が何を推しているか |
| レビュー傾向 | 購入者がどこを評価し、何に困っているか |
| 客観的な仕様・制約 | サイズ・重量・対応条件などの事実 |
やってみて効いたのは、CLIで操作が速くなったことだけではありませんでした。商品リサーチが「ソースを集める → 投入する → 定型質問する → 整形する → 残す」という工程にきれいに分かれたこと。ここが大きかったです。
繰り返しの作業をコマンドに落とすと、頭の中の手順そのものも整理されました。
抽出した商品情報は、Obsidianの正本にした
もうひとつ、地味だけど効いた工夫があります。
NotebookLMのaskで返ってきた答えを、そのノートブックの中に置きっぱなしにしない。Obsidianに移して、商品ごとの正本にしました。
ファイルは役割で2つに分けています。
ソース.md：どのURL・画像・PDFを入れたかの台帳商品情報.md：askで抽出した商品情報の正本（記事を書くとき参照する）
askで返ってきたのは、公式情報や取扱説明書を含む「こちらで選んだソースだけ」から抽出した情報です。だから、記事を書くときに参照する商品データの正本として扱えました。
台帳と中身を分けておくと、後から「この商品、何を根拠にしてたっけ」を追い直せます。そして正本にしておけば、同じ商品を別の記事で扱うときに調べ直さなくて済む。一度作った商品データが、記事をまたいで使い回せるようになりました。
NotebookLMの中だけで調査を完結させていたら、答えはそのノートブックに閉じたままでした。Obsidianに出したことで、はじめて「再利用できる商品データ」になった感じです。
調べた結果を別の場所に移すだけで、その場限りの調査が資産に変わりました。
この商品データを置いているObsidian側のフォルダ構成は、別の記事で丸ごと公開しています。
実際に使って分かった注意点
ここからは、実際にnotebooklm-pyを試す人向けの細かい運用メモです。考え方だけ知りたい人は次のまとめに飛んでもらって大丈夫です。
便利だった一方で、そのまま使うとハマるところもありました。当時つまずいたポイントを残しておきます。
- askは必ず
--jsonで受け取る（通常出力は改行が崩れやすい） - 使うのはJSONの
answer部分だけ - NotebookLMが付ける引用番号は除去してから使う
notebooklm_idは商品ページに書き残す（後で同じノートブックを開ける）- 非公式ツールなので、仕様変更で急に動かなくなることがある
特に最後の1点は、非公式ツール全般に言えることだと思っています。動いているうちは便利ですが、いつ止まってもいいように、抽出した結果はObsidian側に残しておく。非公式ツールに乗るときほど、成果物を自分の手元に落としておくと安心でした。
まとめ
NotebookLMを使った理由は、単に複数のソースをまとめられるからではありませんでした。
Claude Codeから直接読み取れなかった楽天系の情報を、公式情報や取扱説明書と同じ「閉じた根拠ソース」に加えられたこと。ここがいちばん大きかったです。そのうえでnotebooklm-pyを使うことで、商品データを作るまでの繰り返し作業まで型にできました。
もう一度整理すると、こういう流れです。
- AIに自由に調べさせず、根拠ソースを先に集める
- Claudeが読めないソースはNotebookLMに預ける
- 閉じたソースから定型質問で商品情報を抜く
- 結果はObsidianに正本として残し、記事をまたいで使う
冒頭に書いたとおり、いまは運用が一部変わっています。それでも「AIが読めないものをどう補い、調べた結果をどう資産化するか」という考え方は、別のツールに移っても引き継いでいます。
