notebooklm-pyの使い方｜NotebookLMをPython/CLIで自動化・音声概要も一括生成

notebooklm-pyは、Google NotebookLMをPythonコードやCLIから操作できる非公式OSSライブラリだ。GitHubで1.7万スター超・2.3kフォーク（2026年7月時点）を獲得しており、PyPIの最新版はv0.7.3。MITライセンスで公開され、Python 3.10〜3.14に対応する。NotebookLMのブラウザ操作を丸ごとコードに置き換え、PDFの一括取り込みから音声ポッドキャスト生成、クイズのJSON出力まで、Web UIでは手が届かない自動化を実現するのが最大の特徴だ。

この記事ではRAGに特化して解説します。RAG全般は RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ をご覧ください。

notebooklm-pyとは：NotebookLMをコードから自動化するPythonライブラリ

notebooklm-pyはGoogleのNotebookLMが内部で使用する非公開APIにアクセスし、Webブラウザを経由せずにPythonコードやCLIからNotebookLMの全機能を制御できるライブラリだ。まず「結局これで何ができるのか」を数字で押さえておこう。

公式NotebookLMは「あなたのソースだけを読み、引用つきで答える」グラウンデッド（grounded）なエンジンだ。重い読み込みと分析はGoogle側のGeminiが担い、利用者はソースを渡すだけでよい。notebooklm-pyはこの仕組みをブラウザ操作ではなくコードから叩くためのラッパーであり、「Geminiに重い解析をさせて、手元のエージェントは指示出しだけに専念する」という使い方を可能にする。

そもそもNotebookLMとは、Googleが提供する「あなた専用のリサーチアシスタント」だ。ChatGPTのように学習済みの一般知識で答えるのではなく、利用者がアップロードした資料だけを根拠に回答する点が本質的に異なる。回答には必ず「どのソースの何ページ目に書いてあったか」という引用マーカーが付くため、ハルシネーション（もっともらしい嘘）を検証しやすい。この「自分の資料に閉じて、引用つきで答える」性質こそが、社内文書QAや論文リサーチにNotebookLMが選ばれる理由であり、notebooklm-pyはその強みをそのままコードから呼び出せるようにする。つまりエンジニアにとっては「引用つきRAGを自前のベクターDBなしで手に入れる近道」、非エンジニアにとっては「ブラウザで毎回やっていた面倒な繰り返し作業を丸ごと自動化する道具」になる。

このライブラリが実現することは大きく4つに整理できる。

・ソース管理の自動化：URL、YouTube動画、PDF、テキスト、Markdown、Word、EPUB、音声・動画ファイル、画像、Google Driveなど多様な形式をプログラムから一括取り込み
・コンテンツ生成の自動化：音声概要（ポッドキャスト形式）、動画概要、スライドデッキ、クイズ、フラッシュカード、インフォグラフィック、マインドマップ、データテーブル、各種レポートを生成
・成果物のダウンロード：MP3/MP4/PDF/PPTX/PNG/CSV/JSON/Markdownなどをローカルに一括保存。Google Docs/Sheetsへのエクスポートも可能
・AIエージェント連携：Claude Code、Codex、その他のLLMエージェントへツールとして組み込み。MCPサーバー・スキルとして同梱される

この4本柱がどう繋がって動くのか、全体像を1枚にまとめたのが下図だ。ソース投入からGoogleクラウドでの処理、成果物のダウンロード、そしてAIエージェントとの往復までが一続きのパイプラインになっている。

大量のPDFや技術ドキュメントを前処理してから投入したい場合は、MinerUでPDFをMarkdown/JSONに変換する方法と組み合わせると、表・数式・レイアウトを保ったままソース化でき、より精度の高いパイプラインを構築できる。

notebooklm-pyのインストールと初回ログイン認証：pip/uvで始める

導入は「インストール → 初回ログイン認証」の2ステップで完了する。公式が推奨するのはuv toolまたはpipxでCLIを独立環境にインストールする方法だ。これは依存の衝突を避けられるうえ、pip installがexternally-managed-environmentエラー（PEP 668）で弾かれる最近のmacOS（Homebrew Python）やDebian/Ubuntuでも動くためだ。

# 推奨：CLIを独立環境へ（uv tool もしくは pipx）
uv tool install "notebooklm-py[browser]"   # or: pipx install "notebooklm-py[browser]"
notebooklm login                            # 初回はChromium(約170MB)を自動DL → Googleサインイン
notebooklm auth check --test --json         # 認証確認（"status": "ok" が出ればOK）

# アプリに組み込むライブラリ用途（Playwright/Chromium不要）
uv add notebooklm-py                         # or venv内で: pip install notebooklm-py

[browser]付きのインストールは、PlaywrightによるGoogleアカウント認証に使う。初回ログイン後は認証情報がローカルに保存され、以降はブラウザなしで動作する仕組みだ。企業のSSO環境でMicrosoft Edgeが必須ならnotebooklm login --browser msedge、すでにログイン済みブラウザのCookieを再利用するならnotebooklm login --browser-cookies chromeを使う。

インストール方法が複数あるのは、使い方（ペルソナ）ごとに最適解が違うからだ。公式ドキュメントはエージェント用途、エンドユーザー用途、ライブラリ組み込み、ヘッドレスサーバー、コントリビューター、パワーユーザーの6通りに分けて手順を示している。ポイントを絞ると、ターミナルからコマンドとして使う人やAIエージェントに持たせる人はuv tool／pipx＋[browser]、自作アプリのコード内から呼ぶ人はPlaywright不要の素のnotebooklm-py、という2択で考えれば迷わない。サーバー上でブラウザを立ち上げられないヘッドレス環境では、手元のブラウザからCookieを取り込む--browser-cookies方式を使えば、GUIなしでも認証を通せる。自分がどのペルソナに当てはまるかを最初に決めておくと、余計な依存（約170MBのChromium）を入れずに済む。

実際の初回セットアップから操作までの流れは、公式READMEに掲載されているターミナル録画で一気に把握できる。16分の実セッションを30秒に圧縮したものだ。

notebooklm-py CLIでNotebookLMを自動化：作成→ソース追加→生成→ダウンロード

CLIはシェルスクリプトやCI/CDパイプラインへの組み込みに向く。「ノートブック作成 → ソース追加 → チャットで質問 → 各種コンテンツ生成 → ダウンロード」という一連の流れが、すべてコマンド1行ずつで表現できる。

# 1. ノートブックを作って使う対象に設定し、ソースを追加
notebooklm create "My Research"
notebooklm use <notebook_id>
notebooklm source add "https://en.wikipedia.org/wiki/Artificial_intelligence"
notebooklm source add "./paper.pdf"

# 2. ソースに質問（--json で構造化・引用つき回答）
notebooklm ask "主なテーマは何ですか？"

# 3. 各種コンテンツを生成（--wait で完了まで待機）
notebooklm generate audio "engaging and concise" --wait
notebooklm generate video --style whiteboard --wait
notebooklm generate quiz --difficulty hard
notebooklm generate flashcards --quantity more
notebooklm generate slide-deck
notebooklm generate mind-map                       # 既定はインタラクティブ studio map
notebooklm generate data-table "compare key concepts"

# 4. 成果物をローカルに保存（Web UIには無い形式で書き出せる）
notebooklm download audio ./podcast.mp3
notebooklm download quiz --format json ./quiz.json
notebooklm download slide-deck ./slides.pdf
notebooklm download mind-map ./mindmap.json
notebooklm download data-table ./data.csv

生成コマンドには細かいオプションが用意されている。音声概要（Audio Overview）は「deep-dive（深掘り対談）／brief（要点）／critique（批評）／debate（討論）」の4フォーマットと3段階の長さ、50以上の言語を指定できる。動画概要は「explainer／brief／cinematic」の3フォーマットに9種類のビジュアルスタイル、スライドデッキは詳細版とプレゼン版を選べて長さも調整可能だ。クイズとフラッシュカードは問題数と難易度を、インフォグラフィックは向きと詳細度を指定できる。つまり同じソースセットでも、出したい成果物の形と密度をコマンド引数だけで細かく制御できる。

ここで重要なのは、推論の重い部分はすべてGoogleのクラウド側で走るという点だ。手元のマシンやエージェントは「作れ」「保存しろ」と指示を出すだけで、30本のドキュメントを読み込んで要約する作業そのものはGeminiが肩代わりする。だからこそ、トークン課金のかかるコーディングエージェントと組み合わせても手元の消費を大きく抑えられる。これが「何を解決するのか」への答えだ。研究の下読み、社内資料の要約、教材づくりといった時間のかかる知的作業を、人間とローカルLLMの負荷から切り離してクラウドへ逃がす——notebooklm-pyはそのオフロードの配管を担う。

Web UIでは使えないnotebooklm-py専用機能とNotebookLM本家との違い

notebooklm-pyの最大の価値は、Google NotebookLMのWebブラウザUIでは公開されていない機能をAPIから利用できる点にある。通常のブラウザ操作では「閲覧」しかできないものを、構造化データとして取り出し、別システムに流し込めるようになる。

具体的にどの機能がAPI/CLI専用なのかを整理すると次のとおりだ。

特にクイズ・フラッシュカードのJSON出力は、社内研修システムや学習管理システム（LMS）、Ankiのようなスペースドリピティションツールとの連携に効く。ブラウザではインタラクティブなUI上でしか閲覧できない内容を、構造化データとして取得してそのまま別システムに流し込める。PPTXダウンロードもWeb UIがPDFしか出さないスライドを、編集可能なPowerPoint形式で保存できる。自動生成したスライドを後から人手で仕上げるハイブリッドなワークフローに対応できるわけだ。

では、そもそも「notebooklm-pyを使う」と「公式NotebookLMをブラウザで使う」は何が違うのか。両者を正面から比較すると、住み分けがはっきりする。

要するに、生成AIとしての中身は同じNotebookLM。違うのは「操作の口」だけだ。単発で手軽に使うならWeb UI、繰り返す・自動化する・別システムに繋ぐならnotebooklm-py、という切り分けになる。notebooklm-pyは本家を置き換えるのではなく、本家にプログラマブルな操作口を後付けするツールだと捉えるのが正確だ。

「何を代替するのか」をより具体的に言えば、これまで人が手でやっていた一連の作業——ブラウザを開いてノートブックを作り、資料を1つずつドラッグして、生成ボタンを押し、できあがったスライドをダウンロードして、次のノートブックに移る——という反復を、スクリプト1本に置き換える。10個のテーマについて同じ処理をしたいとき、Web UIなら10回同じクリックを繰り返すが、notebooklm-pyならループで回して寝ている間に終わる。さらにクイズをJSONで受け取れるということは、生成結果を人間が読むためではなくプログラムが処理するデータとして扱えるということでもある。ここがWeb UIとの決定的な差であり、NotebookLMを「便利なWebアプリ」から「パイプラインの一部品」へと格上げする。

AIエージェント連携とRAG：Claude Code/CodexのツールとしてのnotebooklmとPython API

notebooklm-pyはAIエージェントのツールとして使うことを明示的に想定した設計になっている。Claude Code、Codex、その他のLLMエージェントへのインストール手順が公式にサポートされ、リポジトリにはスキル定義（SKILL.md）やCodex向けのAGENTS.mdが同梱される。

# Claude Code / .agents スキルとしてローカルにインストール
notebooklm skill install
# → ~/.claude/skills/notebooklm と ~/.agents/skills/notebooklm に配置される

# オープンなスキル・エコシステム経由（GitHubからSKILL.mdを取得）
npx skills add teng-lin/notebooklm-py

# 各エージェント向けの指示テンプレを確認
notebooklm agent show claude
notebooklm agent show codex

Pythonから使う場合は非同期（asyncio）ベースのAPIになっており、複数ノートブックの並列処理やアプリ組み込みに向く。以下は「ソース追加 → 質問 → 音声とクイズを生成してダウンロード」までを1つのasync関数にまとめた例だ。

import asyncio
from notebooklm import NotebookLMClient

async def main():
    async with NotebookLMClient.from_storage() as client:
        # ノートブック作成とURLソース追加
        nb = await client.notebooks.create("Research Pipeline")
        await client.sources.add_url(nb.id, "https://example.com/paper", wait=True)

        # 引用つきで質問
        result = await client.chat.ask(nb.id, "このドキュメントを要約してください")
        print(result.answer)

        # 音声概要（ポッドキャスト形式）を生成 → 完了待ち → 保存
        status = await client.artifacts.generate_audio(nb.id, instructions="make it engaging")
        await client.artifacts.wait_for_completion(nb.id, status.task_id)
        await client.artifacts.download_audio(nb.id, "podcast.mp3")

        # クイズを生成してJSONで保存
        status = await client.artifacts.generate_quiz(nb.id)
        await client.artifacts.wait_for_completion(nb.id, status.task_id)
        await client.artifacts.download_quiz(nb.id, "quiz.json", output_format="json")

asyncio.run(main())

このコードが示すのは「ソースを渡す→引用つきで聞く→成果物を生成して保存する」というnotebooklm-pyの基本ループそのものだ。ポイントは3つある。第一に、NotebookLMClient.from_storage()は初回notebooklm loginで保存済みの認証情報を読み込むため、Python側でパスワードやトークンを直接扱う必要がない。第二に、生成系メソッド（generate_audio／generate_quizなど）は「生成を依頼してtask_idを返す」非同期ジョブとして設計されており、wait_for_completion(nb.id, status.task_id)で完了をポーリングしてからダウンロードに進む。重い解析はGoogle側で走るので、この待ち時間に手元のプロセスがCPUを食うことはない。第三に、chat.ask()が返すresult.answerにはソースに根拠づいた回答が入り、引用の裏取りが前提のRAG用途にそのまま使える。

真価が出るのは、この基本ループを複数ノートブックに対して並列で回すときだ。asyncioベースなので、asyncio.gatherでテーマごとのノートブックを同時に立ち上げ、それぞれにPDFを流し込んで音声とマインドマップを生成する、といった「一晩バッチ」を数十行で書ける。以下は3件のPDFレポートを別々のノートブックとして処理し、各ノートで音声概要とマインドマップJSONを作る例だ。

import asyncio
from notebooklm import NotebookLMClient, MindMapKind

async def build_one(client, title, pdf_path):
    nb = await client.notebooks.create(title)
    # ローカルPDFをソースとして追加（URL/YouTube/テキストも同じ流儀）
    await client.sources.add_file(nb.id, pdf_path)

    # 音声概要（ポッドキャスト形式）を生成 → 完了待ち → 保存
    audio = await client.artifacts.generate_audio(nb.id, instructions="日本語で要点を対談形式に")
    await client.artifacts.wait_for_completion(nb.id, audio.task_id)
    await client.artifacts.download_audio(nb.id, f"{title}.mp3")

    # マインドマップをインタラクティブ形式で生成（JSONで抽出できる）
    await client.mind_maps.generate(nb.id, kind=MindMapKind.INTERACTIVE)
    return nb.id

async def main():
    reports = {
        "AI規制の動向": "./reg.pdf",
        "RAG最新手法": "./rag.pdf",
        "エージェント設計": "./agent.pdf",
    }
    async with NotebookLMClient.from_storage() as client:
        # 3件を並列処理（Google側で解析が走るので手元は待つだけ）
        ids = await asyncio.gather(
            *[build_one(client, t, p) for t, p in reports.items()]
        )
        print("created notebooks:", ids)

asyncio.run(main())

このように「テーマ数だけループを回す」構造にできるのが、Web UIに対するnotebooklm-pyの決定的な優位だ。ブラウザ操作なら3件で3回、30件なら30回同じクリックを繰り返すことになるが、コードなら辞書に行を足すだけでスケールする。しかも解析の重量部分はGoogleのGeminiが肩代わりするため、並列数を増やしても手元のマシンやコーディングエージェントのトークン消費はほとんど増えない。定期実行（cron/launchd）と組み合わせれば、「毎朝、前日追加された資料でブリーフィング音声を更新する」といった常設パイプラインも構築できる。

この「エージェント × NotebookLM」の組み合わせから生まれる代表的なレシピが、公式READMEにいくつも挙げられている。いずれもライブラリの基本操作（create → source add → ask → generate）の組み合わせで実現できるものだ。

・ゼロトークン・リサーチオフロード：30本のドキュメントをノートブックに放り込み、重い分析はGeminiに任せ、エージェントは最後の仕上げにだけトークンを使う
・常設のクロスセッション記憶：「Master Brain」ノートブックを1つ用意し、セッションごとの決定事項をnote createで追記。次回セッションの冒頭でaskして過去の文脈を思い出す
・Obsidian／ナレッジグラフ連携：vaultのルートでCLIを走らせ、ダウンロードしたレポート・マインドマップJSON・文字起こしをそのままノートとして落とす
・多形式コンテンツ展開：1つのソースセットからgenerate audio（ポッドキャスト）・generate video・generate slide-deck・generate report（ブログ下書き）・generate quizまで、全チャンネル分を一気に量産
・引用つきの社内ナレッジベース（RAG）：製品ドキュメント・FAQ・RFC・過去チケットを読み込ませ、ask --jsonでソースに根拠づいた回答を取得。サポートやオンコール対応に使える

notebooklm-pyはMCP（Model Context Protocol）サーバーも同梱しており、Claude Desktop／Claude Code、Cursor、Windsurfなど各種MCPクライアントに対してNotebookLMのツール群を公開できる。これを使うと、コーディングエージェントが「社内のRFCやアーキテクチャ文書を集めたノートブック」に対して、憶測ではなく自分たちのコードとドキュメントに根拠づいた引用つきの答えを返せるようになる。ベクターDBと埋め込みパイプラインをゼロから立ち上げる代わりに、既存のNotebookLMをそのまま「エージェントのグラウンデッドな記憶」として差し込めるわけだ。REST APIサーバー（実験的）も用意されており、CLIプロセスを毎回起動せずローカルのHTTP経由で呼び出す構成も選べる。

とくに最後のRAG用途は、LangChainで独自のRAGパイプラインを構築するアプローチと好対照だ。LangChainがベクターDB・チャンキング・埋め込みの設計を自前で握るのに対し、notebooklm-pyはGoogleのインフラをそのままバックエンドにするため、自前のベクターDBを立てずに引用つきQ&Aが手に入る。用途の重さと安定性の要求で使い分けるとよい。

利用シーン別の活用方法と類似ツール比較：研究・制作・学習・開発

ここまでの機能を、誰がどう使うかの視点で具体化しておく。読者の立場に近いものから読み進めてほしい。

研究者・アナリスト向け

論文やレポートの一括処理パイプラインに使える。特定テーマの論文PDFを複数まとめてソースに追加し、音声概要を自動生成して移動中にリサーチ内容を耳で把握する、といったワークフローが組める。音声概要は50言語以上に対応するため、英語論文を日本語のポッドキャストに変換することも可能だ。

コンテンツ制作者向け

スライドデッキやインフォグラフィックの自動生成が有用だ。PPTXでのダウンロードに対応しているので、生成したスライドをテンプレートとして受け取り、あとから人手で仕上げる分業ができる。動画概要はホワイトボード風など9つのビジュアルスタイル、インフォグラフィックは向きと詳細度を指定できる。

開発者・エンジニア向け

CI/CDパイプラインへの組み込みや、成果物の構造化に使える。クイズやフラッシュカードのJSON出力は社内研修システムやLMSへの自動連携に、マインドマップのJSON出力は独自の可視化ツールへのデータ供給に活かせる。MCPサーバー経由でコーディングエージェントに社内ドキュメントを「引用つきで答える記憶」として持たせれば、ベクターDBを自前で立てずに済む。

学習支援向け

教材からのクイズ・フラッシュカード自動生成が使える。Web UIのインタラクティブ表示に縛られず、JSON/Markdown/HTMLの任意形式で出力できるため、Ankiなどの反復学習ツールとも連携しやすい。カリキュラムやロードマップをトピックごとにノートブック化し、各トピックの音声・クイズ・カードをまとめて生成する「学習セット・ビルダー」も定番だ。

いずれのシーンでも共通するのは、「1回の手作業」ではなく「同じ処理の繰り返し」を対象にすると効果が跳ね上がるという点だ。単発でノートを1つ作るだけならブラウザで十分だが、毎週最新の資料でブリーフィング音声を更新したい、数十テーマ分の学習セットを一晩で用意したい、リサーチ結果を定型フォーマットのレポートに落として社内共有したい——こうした「繰り返し・定期・大量」の要件が出てきた瞬間に、notebooklm-pyの自動化が手作業を圧倒する。逆に言えば、繰り返しが発生しない使い方であれば無理に導入する必要はなく、Web UIで完結させたほうが速い。導入判断は「この作業を今後も繰り返すか？」という一点で決めるのがわかりやすい。

続いて、notebooklm-pyの立ち位置を近い選択肢と並べて整理する。

notebooklm-pyの最大の強みは、Google NotebookLMの全機能をPythonから直接操作できる唯一のライブラリである点だ。ただし非公式APIに依存するため、安定性を最優先するならLangChainでRAGシステムを構築するか、Onyxで企業向けRAGチャットボットを構築するといった、公式にサポートされたスタックを選ぶ判断も十分に合理的だ。

notebooklm-py導入前の注意点とサポート環境：非公式APIのリスクを理解する

繰り返しになるが、notebooklm-pyを実務に取り入れる前に最も理解しておくべきは「非公式API依存」というリスクだ。

リスクを踏まえたうえでも、プロジェクトの開発は活発だ。PyPIには19以上のリリースが積まれており、破壊的変更の移行ガイドやAPI安定性ポリシー、トラブルシューティングのドキュメントが整備されている。バージョンは頻繁に上がるため、自動化スクリプトに組み込む際はバージョンを固定（ピン留め）し、アップグレード時に挙動を確認してから本番へ反映するのが安全だ。Linuxでplaywright install chromiumがTypeError: onExit is not a functionで失敗する既知の問題など、環境依存のつまずきも公式ドキュメントに回避策がまとまっている。

一方で、対応プラットフォームとPythonバージョンの広さは実用上の安心材料になる。主要3OSがCIで検証されており、Python 3.10〜3.14まで対応する。

導入判断をまとめると、次のようになる。「NotebookLMの成果物を繰り返し・大量に・別システムと繋げて扱いたい」なら、notebooklm-pyは現状ほぼ唯一の選択肢だ。逆に「たまに1本ポッドキャストを作るだけ」ならWeb UIで十分であり、非公式APIのリスクを負う必要はない。自動化で削れる手作業の量と、API変更で止まったときの影響を天秤にかけて選ぶのが正解だ。まずは個人のリサーチ用ノートブックで小さく試し、壊れても困らない範囲から自動化を広げていくことをおすすめする。

関連記事: RAGとは？仕組み・構築・ベクトルDB選定まで【2026年完全ガイド】

参照ソース

• teng-lin/notebooklm-py - GitHub
• notebooklm-py - PyPI
• Google NotebookLM 公式サイト