先月、Claude を Pro から月額 $200 の Max にアップグレードしました。これで十分だろうと思って。
5 日目：週間制限を使い切りました。
使用ログを見ると、お金の行き先が一目瞭然でした。たった 1 回の午後のセッションで 47 本の論文を調査したところ、その 1 回で週間制限の 10% を消費していました。これを週に 2〜3 回行えば、制限が持たないのは当然です。
問題は、Claude に得意ではないこと—フルテキスト検索エンジンとして機能させる—をさせ続けていたことでした。
50,000 文字のログを会話に詰め込んで質問すると、そのログ全体が毎回入力トークンとしてカウントされます。プロンプトキャッシュ（価格が 1/10）を利用しても、メインセッションはターンごとに徐々に蓄積されていきます。さらに悪いことに、キャッシュの TTL は 1 時間です。時間を置きすぎると、全額で書き直さなければなりません。これは、弁護士に質問するたびに、毎回 50 ページの契約書を声に出して読ませるようなものです。
Claude Code は、推論、オーケストレーション、コーディングに優れています。生のソース資料を読むことは他のツールに任せ、Claude には結論だけを見せるべきです。この論理に従って、NotebookLM を思い浮かべました。
この設定ガイドに従えば、$20 のアカウントで $200 のアカウントの仕事ができるようになります。
ガイド
この投稿は長文です。興味のある部分に飛んでください：
- I: NotebookLM とは何か + 何ができるのか？
- II: なぜ Claude をレイヤーとして追加するのか？
- III: スキルのインストール（10 分セットアップ）
- IV: 実際のトークン料金 + 原則の内訳
- V: 研究者 / 学生向けワークフロー
- VI: IPO / 目論見書読み込み向けワークフロー
- VII: パーソナルナレッジベース向けワークフロー
- まとめ
ワークフローを先に見たい場合は、パート V に直接ジャンプしてください。
一言で言うと：
Claude のトークンを節約する本当の方法は、キャッシュを有効にすることだけではなく、重いデータをそもそも Claude に入れないことです。
具体的には：NotebookLM にストレージと検索を任せ、Claude に推論とオーケストレーションを任せます。分業は明確で、この例えに集約されます：
NotebookLM は教師です
: あなたが集めた論文、財務報告書、メモがその知識ベースを形成します。あなたが質問すると、経験に基づいて引用付きで答え、ソースの範囲内に留まり、幻覚を見ることはありません。
Claude はアシスタントです
: コードを書き、スクリプトを実行し、結果を整理し、ツールを調整する責任があります。わからないことがあれば教師に尋ね、答えを得て、作業を続けます。
あなたはプロジェクトリーダーです
: 重要な決定ポイントにのみ介入します。
重要な原則：なぜこの分業でコストが節約できるのか
1. RAG とコンテキストスタッフィングは、異なるコストモデルです。
50,000 文字を Claude チャットに詰め込むと、入力トークンとしてカウントされます。質問するたびにそれを再度「見る」必要があり、コストは資料のサイズに比例して増加します。RAG では、NotebookLM が内部でベクトル検索を使用して関連スニペットをヒットさせ、Claude は数語の蒸留された回答のみを見るため、コストはほぼ一定になります。
2. プロンプトキャッシュには 1 時間の TTL があり、研究シナリオではヒット率が低くなります。
多くの人はキャッシュを有効にすればすべてが解決すると思っています。実際には、Anthropic のプロンプトキャッシュはデフォルトで 1 時間で期限切れになります。数分考えたり、タスクを切り替えたり、新しいセッションを開いたりすると、次の呼び出しは全額の cache_creation 価格でキャッシュを再書き込みする必要があります。研究セッションは「質問し、考え、再び質問する」リズムに従うため、ヒット率はしばしば悲惨なものになります。これが、高騰する料金の真の原因です。
3. 事実に基づく出力はより効率的です。
NotebookLM の回答はアップロードしたソースに制約され、すべての文にテキストにリンクする [1][2] の引用が付きます。でっち上げることはありません。Claude がこれらの回答を意思決定に使用する場合、常に「再確認」するよう依頼する必要がなくなり、計り知れない時間を節約できます。
この設定をスキップすべき人：
- 資料が 5k トークン未満、または 1〜2 回確認するだけの場合—Claude に直接尋ねてください。
- ワークフロー統合なしの純粋な Q&A ニーズがある場合—NotebookLM のウェブインターフェースをそのまま使用してください。
- 料金よりも応答速度を重視する場合—これは約 3 倍遅くなります。
- コードの構造や定義を理解する必要がある場合—NotebookLM はテキスト RAG に適しています。
読み続けるべき人：
- 具体的なインストール手順と注意すべき落とし穴を知りたい方。
- シナリオがコマンドレベルでどのように変換されるかを見たい方。
- Claude Code ユーザーで、NotebookLM をスキルとして利用したい方。
パート I: NotebookLM を知る
NotebookLM を初めて開いたのは、友人が勧めたからです。彼女の論文のための読書リストには 60 以上の論文がありました。以前は PDF を Ctrl-F で検索していましたが、今ではそれらすべてを 1 つのノートブックにドロップして、「見解 X を支持する人は誰で、反対する人は誰で、どこに意見の相違があるのか？」と尋ねます。すると、クリックすると該当段落にジャンプする [1][2][3] の引用付きで答えが返ってきます。
彼女はこれで週に 10 時間以上節約できていると言っていました。
懐疑的に 1 週間試してみましたが、夢中になりました。NotebookLM の利点は次のとおりです：
- 無料で 50 ソース / Pro で 300 ソースまでサポート。
- 処理能力は無料—アップロード、インデックス作成、生成、チャットはすべて Google のコンピューティングリソースを使用。
- Q&A に加えて、ノートブックから 音声ポッドキャスト（通勤に最適）、マインドマップ、PPT、フラッシュカードなどを自動生成可能。
- ポッドキャストは驚くほど素晴らしい—2 人の AI「見知らぬ人」があなたの資料について、あなたが考えもしなかった角度から議論するのを聞くと、しばしば新しい洞察が得られます。
形式は問題になりません。PDF、URL、YouTube トランスクリプト、Google ドキュメント、プレーンテキスト、画像 OCR、音声トランスクリプションなど、すべてをソースにできます。
多くの人にとって、NotebookLM はすでに強力なスタンドアロンツールです。「座って質問する」だけが必要な場合は、ここで読むのをやめても構いません。
しかし、私はこれが 2 つの点で行き詰まることに気づきました：
1. コンテキストの切り替えが流れを断ち切ります。
あるトピックを調査する場合：質問する → 答えを得る → 引用をクリックしてソースにジャンプする → セクションを読む → ノートブックに戻って答えをコピーする → Claude Code に切り替えて使用する → 実験を実行する → 不足しているソースを見つける → Google 検索に切り替える → ダウンロードする → ノートブックに戻ってソースを追加する → 質問を続ける... 午後中に 200 回もタブを切り替えることになります。
2. ローカルツールから隔離されています。
オンラインインシデントのトラブルシューティング中に、ノートブックでログを検索できます。しかし、ターミナルでローカル設定を grep したり、k8s イベントを確認したり、ポッドを立ち上げたりする必要もあります—ウェブアプリはローカルコマンドを実行できません。常に「ウェブで読む → 手動で入力する → 切り替える」の繰り返しです。
NotebookLM のウェブアプリは、それ自体が最終目的地として位置づけられています。 質問すれば答えが返ってきて、それで終わりです。しかし、私はこれを 組立ラインの一部—スケジュールされ、バッチ処理され、出力が次のステップに流れるもの—にしたいのです。
ここで Claude の出番です。
パート II: Claude をレイヤーとして追加する
NotebookLM を Claude のためのツールに変えます。1 つだけで十分です：Claude がドメイン知識を必要とするとき、教師に尋ねます。
フロー
教師（NotebookLM）は 読み取り専用のヘルプデスク です：47 本の論文を一度に放り込んで、そのままにしておきます。それらは質問を待ってそこに留まります。メモやコードをフィードバックする必要はありません—論文にある見解だけで、すべてのクエリをサポートするのに十分です。
次のプロンプトは、6 つのステップ、規律、特定のノートブック ID を、Claude Code が実行可能な形式にエンコードしたものです（ID は必ず置き換えてください）：
1# 役割2あなたは私の研究アシスタントです。私の主題の教師は、47 本の関連論文を含む固定された NotebookLM ノートブック3（ID: 6634ad4d-0594-4700-bddf-4a400ad46fa2）です。4あなたはインストールされた notebooklm スキル（`/notecraft chat` コマンド）を介して教師と会話します。56# 絶対ルール71. 論文の見解、数式、方法、既知の落とし穴に関する質問については、**まず `/notecraft chat` で教師に尋ねてください**。8 記憶から答えたり、論文のテキストをチャットに貼り付けるように私に依頼したりしないでください。92. 教師は **読み取り専用のヘルプデスク** です：メモ、コード、実験結果をノートブックにフィードバックしないでください。10 知識ベースは 47 本の論文で静的に保たれます。113. 教師の回答には [1][2] の引用が含まれます。これらの引用は、私への出力にそのまま保持してください。124. プロセス中に再び教師に尋ねる必要があるかどうかはあなたが判断します—毎ステップ私に確認する必要はありません。135. 教師が答えられない場合、または引用が弱い場合は、明示的に「教師は答えられません」と言ってください；幻覚を見ないでください。1415# ワークフロー16① 私があなたにトピック/サブ問題を与えます。17② ドメイン知識（論文の見解、過去の方法、数式、失敗モード）が必要なポイントを特定します。18③ `/notecraft chat` を介してこれらのポイントについて教師に問い合わせ、引用付きの回答を取得します。19④ 回答を使用して実行を推進します：コードを書き、スクリプトを実行し、ローカルファイルを grep し、結果を整理します。20⑤ 実行中に新しい質問が発生した場合は、③ に戻って教師に解決されるまで尋ねます。21⑥ 私への最終出力：22 - 結論（教師からの [引用] 付き）23 - あなたのコード / 実験結果24 - 教師がカバーしなかった未解決の質問のための別のセクション2526# 出力形式27配信のたびにこの骨組みを使用してください：2829## 教師の見解30（`/notecraft chat` からの主要ポイント、[引用] を保持）3132## 私が行ったこと33（あなたが書いたコード / 実行したコマンド / 観察された結果）3435## 結論36（私の元のトピックへの回答）3738## 教師がカバーしなかったこと39（教師が答えられなかった、または引用が弱かったポイント。私が手動でフォローアップするため）4041# 開始42私の最初のトピックは：<ここに質問を書いてください>
重要なポイント：
- 47 本の論文は決して Claude チャットに入力されません—メインセッショントークンは推論とコードにのみ使用されます。
- 教師は相談されるだけで、実行には関与しません—その強みは引用付きドメイン検索です。
- あなたはステップ ① でのみ介入します—Claude がいつ教師に相談するかを決定します。
- 知識ベースは静的です—47 本の論文で十分です。
「別々に使う」よりも「連携させる」方が強力なのはこのためです：節約されるタブの切り替えとトークンはボーナスです。そのメリットがどれほど大きいか見てみましょう。
パート III: NotebookLM クライアント & スキルのインストール
Google は公式の NotebookLM クライアントを提供していませんが、@icebear0828 がサードパーティクライアントを作成しました。インストールすると、エージェントがコマンドラインまたは自然言語を介して NotebookLM にアクセスできるようになります。
https://github.com/icebear0828/notebooklm-client
基本的なインストール：
1# クライアントのインストール2npm i notebooklm-client34# ログインセッションのエクスポート（Google ログインのためにブラウザが開きます）5npx notebooklm export-session67# ノートブックとチャット8# npx notebooklm chat <notebook-id> --transport auto --question "これを要約してください"910# インストール後、エージェントで `/notecraft` を使用して NotebookLM 操作を自動化11npx notebooklm skill install
インストール後、チャットで「あのノートブックの X の部分を確認して」と言うだけで、Claude が自動的に呼び出します—毎回構文を説明する必要はありません。
パート IV: 実際のテスト—どれだけのお金が節約できるか？（Opus 4.7）
これらの数値はシミュレートされたものではなく、実際の研究セッション から Claude Code のセッションログを取得したものです。
NotebookLM 側では、アップロード、検索、生成は Google によって完全に無料であり、あなたの請求には影響しません。以下の数値はすべて Claude Opus 側のみをカウントしています。
テスト設定：
- 資料: Image + LiDAR SLAM に関連する 47 本の論文。すべて 1 つの NotebookLM ノートブックに。
- モデル: Claude Opus 4.7
- ターン数: 5 ラウンドの深い Q&A（「最良の SLAM 再構成手法」から「3DGS と NeRF バックエンドの落とし穴」まで）。
- 方法: Claude Code での通常の会話。アシスタントが毎ラウンド
/notecraft chatを呼び出します。
結果（この方法）：
請求額は、トークン入力 + cache_creation と出力によって決まります。より安いレート（cache_read + 入力）は価格の 1/10 未満であるため、高額な部分に焦点を当てます：
5 ラウンドの合計: $0.55、1 ラウンドあたり約 $0.11。
重要な数値: cache_creation はわずか 17,379 でした。
cache_creation は、キャッシュに新しいコンテンツを書き込むためのトークン数です。この 5 ラウンドでは、教師の回答（約 3〜6k トークン）+ 小さなシステム増分のみがキャッシュされました—合計 17,000。
47 本の論文からの単語は 1 語も Claude の `cache_creation` に入力されていません—これが節約の秘訣です。
比較：47 本の論文を直接プロンプトに詰め込む場合
47 本の論文は合計 384,000 ワード ≈ 500,000 トークン。従来のプロンプトスタッフィングは次のようになります：
最も公平な比較は 2 行目（単一セッション、複数ターン）—従来の方法の最良のシナリオです。それでも、5 ラウンドのコスト差は 17 倍（$9.59 対 $0.55）です。セッション間のシナリオはさらに悪化します（86 倍）。
なぜ従来の方法ではキャッシュが役に立たないのか？ Anthropic のキャッシュは有料層でデフォルト 1 時間です。考えたり、ウィンドウを切り替えたり、新しいセッションを開始したりする間に、以前のキャッシュはしばしば追い出されます。
この方法では、論文が Claude に入力されることはないため、キャッシュヒットは重要ではありません。
資料が倍増するにつれて（100、200 論文）、その差は直線的に拡大します。従来の cache_creation は論文の数に応じて増加しますが、この方法はほぼ一定のままです。
Opus で研究を実行している人へ：1 年間の研究セッションでは、$2,000 の差が生じる可能性があります—単に論文を Claude から遠ざけるだけで、Max に再アップグレードするのに十分な額を節約できます。`
代償：3 倍遅くなる
操作 | 中央時間 |
|---|---|
ノートブック作成 + ソース追加 | 10-15 秒 |
NotebookLM チャット | 16-48 秒（中央値約 45 秒） |
Claude Opus 単一クエリ（NotebookLM なし） | 20-35 秒 |
応答時間の秒数が月額料金よりも重要な場合、この設定はあなた向けではありません。
以下のセクションでは、NotebookLM に適した 3 つのワークフローを概説します。
パート V: 研究者 / 学生向けワークフロー
読書リストは自然な知識の境界です。
痛点：学期に数十本の論文、同じ PDF を繰り返しチェック。Ctrl-F は疲れるし、ChatGPT は引用なしで幻覚を見るかもしれません。
資料レシピ（一度アップロードすれば、学期中ずっと使用可能）：
- トピック関連の論文 PDF 20〜50 本
- コースのシラバス、講義のトランスクリプト
- アドバイザーからのメール、草稿の章、読書メモ
教師へのキラークエスチョン：
- 「結論が矛盾している 2 つの論文はどれですか、そしてそれはどの仮定に基づいていますか？」
- 「方法 X はこのコーパスに何回登場し、どのように使用されていますか？」
- 「論文 A の式 3 と論文 B の式 7 は実際に等価ですか？」
Claude の役割：プロジェクトを前進させる—教師から概念/数式を取得 → 複製するコードを書く → 実験を実行する → メモを整理する。生の論文は Claude セッションに入力されることはありません。
パート VI: IPO / 目論見書読み込み向けワークフロー
目論見書は 300〜600 ページあり、投資の期間はわずか 3 日です。人間が時間内にすべてを読むことはできません。
痛点：IPO は動きが速いです。書類は 500 ページ以上で、会社の歴史、ビジネスモデル、財務、リスク、アンカー投資家をカバーしています。1 つ読むのに少なくとも 4 時間かかります。週に 5〜8 の IPO がある場合、それは不可能です。
最も価値のある情報は自己賛辞ではなく、リスク要因や関連当事者取引に隠された「レッドフラッグ」です。人間はこれらを見逃しがちです。
資料レシピ（1 社につき 1 ノートブック）：
- 完全な目論見書—中核。
- アンカー投資家の開示—誰がどれだけの期間支援しているのか？
- 同業他社の財務報告書—バリュエーションのベンチマーク。
- スポンサー/引受会社の調査—公式な価格決定ロジック。
- 経営陣インタビュー & 過去の資金調達ラウンド—バリュエーションのジャンプ。
教師へのキラークエスチョン：
投資判断のために、通常数時間かかる以下の 8 つの質問をします：
- 「中核製品は何ですか？ 3 年間で収益構造はどのように変化しましたか？ 顧客集中度は？」
- 「これは同業他社（A、B、C）と、粗利率、成長率、研究開発費で比較してどうですか？」
- 「アンカー投資家は誰で、金額とロックアップ期間は？」
- 「調達資金の使途を分解してください。最大の部分は何ですか？ IPO 後の希薄化は？」
- 「どのリスク要因が業界全体のもので、どれが会社固有のものですか？」
- 「過去のバリュエーション：前回ラウンドから IPO までの倍率のジャンプは？ 前回ラウンドのロックアップは？」
- 「一時的な利益で利益を水増ししている兆候はありますか？ キャッシュフローは 3 年間の純利益と一致していますか？」
- 「関連当事者取引は収益の何％ですか？ トップ 5 の顧客に関連当事者は含まれていますか？」
すべての回答には [ページ番号] の引用が含まれます。
Claude の役割：
バッチ処理がこのワークフローの要です：
毎週の IPO プール = [株式 A、株式 B、株式 C、…]
Claude は 8 社を 1 つのマークダウン意思決定表に要約します → あなたは 15 分でスキャンして優先順位を付けます。
5〜8 IPO = 40〜64 クエリ。総資料は約 100 万トークン。従来の方法では週に $50 以上を消費しますが、この方法では $2 未満です。
パート VII: パーソナルナレッジベース向けワークフロー
あなたの「セカンドブレイン」を構築しましょう。
痛点：Obsidian の検索はキーワードのみを認識します。「3 年間で X に対する私の見解はどのように変化しましたか？」という質問には答えられません。メモは散在しており、形式もさまざまです。
資料レシピ：
- Obsidian / Notion の完全エクスポート
- Kindle ハイライト、Readwise クリップ
- 仕事日誌、議事録、レビュー文書
教師へのキラークエスチョン：
- 「過去 3 年間で『集中』について何を書きましたか？ 私の見解は変わりましたか？」
- 「『プリンシプルズ』と『ファスト＆スロー』は、認知バイアスについてどこで重複し、どこで矛盾していますか？」
- 「先月のすべての議事録で、プロジェクト X に対する個人の態度はそれぞれどのようなものでしたか？」
Claude の役割：思考の進化に関する質問には、会話型 AI と完全な資料が必要です。Claude は教師の複数ラウンドの回答を構造化された要約（タイムライン、見解比較、フォローアップリスト）に統合します。
3 つのワークフローに共通する点： 繰り返しのクエリ、文書横断、プライベートな境界。 これらのいずれかに該当する場合、15 秒のセットアップコストは 1 週間以内に回収できます。
最終的な考え
注意すべき点：
storage_state.jsonにはアクティブな Google セッションが含まれています。安全に保管してください。notebooklm-clientはリバースエンジニアリングされています。Google は公式にサポートしておらず、バックエンドが変更される可能性があります。
この核心は 分業 です：
- NotebookLM は教師として: 引用付きでドメイン知識に答え、幻覚を見ません。
- Claude はアシスタントとして: ツールを調整し、コードを書き、結果を整理し、行き詰まったら教師に尋ねます。
- あなたはプロジェクトリーダーとして: 重要な決定ポイントにのみ介入します。
これを 1 ヶ月間使用しましたが、節約額は素敵な夕食を何度か楽しむのに十分です。さらに重要なのは、数十本の論文を研究しても制限を心配しなくなったことです—「トークンを数えなくていい」という自由は、節約そのものよりも中毒性があります。
この投稿が気に入ったら、私 @MinLiBuilds をフォローしてください。
最後に、私のキャッシュシリーズの最初のパートを紹介します。キャッシングメカニズムをわかりやすく説明し、トークンを節約するのに役立ちます：
