📅 2026年3月19日 ⏱️ 16分で読めます

NotebookLMはGASで連携できる？Apps Scriptでできること・できないこと・実装の最短ルート【2026年3月19日時点】

執筆ファネルAi編集部編集ファネルAi編集部監修ファネルAi監修チーム最終更新2026年3月19日

2026年3月19日時点の結論は、「個人向け NotebookLM をそのまま GAS から叩く公開 API は確認できないが、NotebookLM Enterprise API なら Apps Script から連携可能」です。 Google Cloud の公式ドキュメントでは、NotebookLM Enterprise 向けに notebook 作成、source 追加、audio overview 生成の API が公開されており、Apps Script 側も ScriptApp.getOAuthToken() と UrlFetchApp.fetch() で Google API を直接呼べます。

NotebookLM と GAS の連携は、単純に yes / no で答えにくいテーマです。理由は、一般向けの NotebookLM と、Google Cloud 側で提供される NotebookLM Enterprise API で、前提も実装方法も違うからです。

また、2025年9月5日付の Gemini Enterprise release notes では「Notebook creation and management using the API」が GA と案内されている一方、NotebookLM Enterprise の API ガイドページには 2026年3月19日時点でも Preview 表記が残っています。実装判断では、どの公開情報を前提にするかを明示しておく方が無難です。

この記事では、NotebookLM と GAS の連携可否を 2026年3月19日時点の Google 公式情報ベース で整理します。あわせて、Gemini と NotebookLM の役割分担や、Apps Script で Gemini を呼ぶ構成も押さえておくと、どこまでを NotebookLM でやるべきか整理しやすくなります。

本記事のポイント

2026年3月19日時点で公式に確認できる NotebookLM API は NotebookLM Enterprise 向けで、個人向け NotebookLM の公開 API は確認できません。
Apps Script は OAuth トークン付き HTTP 呼び出しで Google API を叩けるため、NotebookLM Enterprise なら notebook 作成や source 追加を GAS から実装できます。
Docs や Slides を source に入れる場合は Google Drive への認可や OAuth スコープ設計が必要で、単純な webhook 連携より設計論点が多くなります。

このページで扱う検索テーマ

最初に結論だけ整理する

まず、連携の可否を 2 つに分けると分かりやすくなります。

対象	GAS 連携の現実性	理由
個人向け NotebookLM	難しい	2026年3月19日時点で、Google 公式に公開 API ドキュメントを確認できないため
NotebookLM Enterprise	可能	Google Cloud 公式に notebook 作成・source 管理・audio overview 生成 API があるため
「NotebookLMっぽいこと」を GAS でやりたい	かなり現実的	Gemini API と Drive / Sheets / Docs を Apps Script で組み合わせれば代替構成を作れるため

「NotebookLM の UI を自動操作する」のか、「NotebookLM Enterprise の API を使う」のか、「NotebookLM ではなく Gemini API で同じ業務を作る」のかを先に分ける必要があります。ここが曖昧だと、連携可否の答えもぶれます。

なぜ「条件付きでできる」という答えになるのか

Google Cloud の NotebookLM Enterprise API ガイドには、notebook の作成・取得・共有・削除、source の追加・削除・取得、audio overview の生成 が明示されています。REST でも POST /v1alpha/projects/{project}/locations/{location}/notebooks、.../sources:batchCreate の形で公開されています。

一方で、2026年3月19日時点で確認できる公式の RPC / REST リファレンスでは、NotebookLM Enterprise の notebook そのものに対して「質問して答えを返す」専用メソッドまでは前面に出ていません。公開ドキュメント上で目立つのは NotebookService、SourceService、AudioOverviewService です。つまり、GAS からまず組みやすいのは notebook 管理と source 投入であって、NotebookLM の UI 上で見えている体験をそのまま API 化できるとは限らない、と見ておく方が自然です。

この差は、NotebookLM を「社内ナレッジと会話する完成アプリ」として見るか、「Cloud で管理可能な notebook リソース」として見るかの違いです。企業調査や提案準備で NotebookLM をどう使い分けるかは、企業調査 AI 比較記事でも触れた通り、情報源と運用基盤で考える方が実務には合います。

Apps Script 側の技術論点はそこまで難しくない

GAS 側はむしろ素直です。Apps Script 公式には、ScriptApp.getOAuthToken() で有効ユーザーの OAuth アクセストークンを取得し、UrlFetchApp.fetch() の Authorization ヘッダーで Google API を呼べると明記されています。また、Advanced services が用意されていない API でも、UrlFetchApp なら直接叩けると案内されています。

NotebookLM Enterprise API の各メソッドは cloud-platform か discoveryengine.readwrite スコープを要求します。したがって、Apps Script では 実装そのものより、マニフェストの OAuth scope と、紐付いた Google Cloud project 側の有効化・権限付与 の方が重要になります。

ここは Gemini を GAS から叩く記事と似ていますが、NotebookLM Enterprise の方がライセンス、Cloud IAM、リージョン指定まで絡む分だけ少し重いです。

最低限必要になる OAuth スコープ例

{
          "timeZone": "Asia/Tokyo",
          "oauthScopes": [
            "https://www.googleapis.com/auth/script.external_request",
            "https://www.googleapis.com/auth/script.scriptapp",
            "https://www.googleapis.com/auth/cloud-platform"
          ]
        }

script.external_request は HTTP 通信、script.scriptapp は ScriptApp.getOAuthToken() の利用、cloud-platform は NotebookLM Enterprise API 側の要求に対応するためです。実際には組織ポリシー次第で、より限定的なスコープ設計を検討した方が安全です。

GAS から呼ぶ最小実装はこうなる

まずは「notebook を作る」「text source を入れる」までを最小構成にするのが安全です。Google Docs や Slides を直接 source にする前に、まず raw text で通ることを確認してください。

const NOTEBOOKLM_PROJECT_NUMBER = '123456789012';
        const NOTEBOOKLM_LOCATION = 'global';
        const NOTEBOOKLM_ENDPOINT = 'https://discoveryengine.googleapis.com/v1alpha';

        function notebookLmRequest_(path, method, body) {
          const response = UrlFetchApp.fetch(`${NOTEBOOKLM_ENDPOINT}/${path}`, {
            method: method,
            contentType: 'application/json',
            headers: {
              Authorization: 'Bearer ' + ScriptApp.getOAuthToken()
            },
            payload: body ? JSON.stringify(body) : undefined,
            muteHttpExceptions: true
          });

          const text = response.getContentText();
          const status = response.getResponseCode();
          if (status >= 300) {
            throw new Error(`NotebookLM API error ${status}: ${text}`);
          }
          return text ? JSON.parse(text) : {};
        }

        function createNotebookLmNotebook() {
          return notebookLmRequest_(
            `projects/${NOTEBOOKLM_PROJECT_NUMBER}/locations/${NOTEBOOKLM_LOCATION}/notebooks`,
            'post',
            {
              title: 'GAS から作成した NotebookLM notebook'
            }
          );
        }

        function addTextSourceToNotebook(notebookId, sourceName, content) {
          return notebookLmRequest_(
            `projects/${NOTEBOOKLM_PROJECT_NUMBER}/locations/${NOTEBOOKLM_LOCATION}/notebooks/${notebookId}/sources:batchCreate`,
            'post',
            {
              userContents: [
                {
                  textContent: {
                    sourceName: sourceName,
                    content: content
                  }
                }
              ]
            }
          );
        }

この例なら、Spreadsheet の行データや Google Docs の本文を別途取得してから、NotebookLM Enterprise 側へ text source として流し込めます。つまり最初の勝ち筋は、NotebookLM 側へ直接 Docs をつなぐことではなく、GAS で整形したテキストを notebook に送る ことです。

Docs や Slides を source に入れるときの注意点

NotebookLM Enterprise の source API ガイドには、Google Docs や Google Slides を source にする場合、Google Drive への認可が必要 と明記されています。CLI 例では gcloud auth login --enable-gdrive-access が案内されており、batchCreate の userContents には googleDriveContent として document ID、mime type、source 名を渡す形です。

GAS で同じことをやる場合も、「HTTP が打てる」だけで終わりません。次の論点が増えます。

実行ユーザーが NotebookLM Enterprise のライセンスと IAM ロールを持っているか
Apps Script の OAuth トークンに必要スコープが含まれているか
対象 Docs / Slides への Drive 権限がその実行ユーザーにあるか
script の関連 Cloud project で API が有効化されているか

ここで詰まるくらいなら、最初は raw text か file upload で運用を作り、その後に Docs / Slides 直結へ広げる方が失敗しにくいです。NotebookLM のスライドまわりの進化自体は速いので、UI ベースの活用は NotebookLM の PPTX / スライド更新記事も見ておくと流れが追いやすくなります。

実務では、NotebookLM Enterprise API と Gemini API をどう使い分けるべきか

実務では、API そのものより「資料を読ませて要約したい」「社内ノートをもとに質問応答したい」「定期レポートを自動で作りたい」のどれを実現したいのかを先に決める方が重要です。

やりたいこと	向いている構成	理由
NotebookLM の notebook を programmatic に作る	NotebookLM Enterprise API + GAS	notebook / source リソースを管理できるため
Sheets や Docs から要約・分類・整形する	Gemini API + GAS	構成が軽く、Enterprise ライセンス前提にしなくてよいため
社内資料を UI で見ながら会話し、引用つきで使う	NotebookLM UI か NotebookLM Enterprise UI	最終的に人が読む体験が主役だから
組織横断で AI 活用を管理したい	API 単体ではなくガバナンス設計もセット	権限、共有、監査、費用管理が先に効くため

もし「NotebookLM と同じ見た目の体験を GAS で自動化したい」なら Enterprise API を検討します。逆に「スプレッドシートや Docs を起点に AI 処理したい」なら、NotebookLM にこだわらず Gemini API の方が速いです。後者の方が、日次バッチや通知フローまで含めると設計しやすい場面が多くなります。

また、組織導入を見据えるなら API の有無より、AI エージェント時代の管理統制をどう置くかの方が先に問題になります。NotebookLM は便利ですが、共有設計と権限設計を詰めないまま広げると、後から制御不能になります。

ハマりどころを先に潰しておく

1. 「API がある」と「個人向け NotebookLM を自由に叩ける」は別です

Google Cloud の公式で確認できるのは NotebookLM Enterprise API です。個人向け NotebookLM の UI と同じ前提で、「自分の notebook を GAS からそのまま操作できる」と捉えない方が安全です。

2. release notes と API ガイドの表記差を鵜呑みにしない方がいいです

2025年9月5日の release notes では notebook 管理 API は GA とされていますが、2026年3月19日時点の NotebookLM Enterprise API ガイドには Preview 表記があります。社内提案では、どちらの記載を根拠にするかを明示した方が安全です。

3. Apps Script の壁はコードではなく権限です

エラーの大半は JavaScript の構文ではなく、OAuth scope 不足、Cloud project 側の API 未有効化、NotebookLM Enterprise ライセンス不足、Drive 権限不足で起きます。まず権限から見る方が早いです。

よくある質問（FAQ）

NotebookLM の無料版を GAS から直接操作できますか？

2026年3月19日時点で、Google 公式に公開 API ドキュメントを確認できませんでした。少なくとも「公式 API を前提に実装する」判断はしにくいです。

Apps Script から NotebookLM Enterprise API は本当に呼べますか？

呼べます。Apps Script 公式には、ScriptApp.getOAuthToken() で取得したトークンを UrlFetchApp.fetch() の Authorization ヘッダーに載せて Google API を呼べると明記されています。必要なのは適切な OAuth scope と Cloud 側の設定です。

NotebookLM Enterprise API で何ができますか？

2026年3月19日時点で公式に確認しやすいのは、notebook の作成・取得・共有・削除、source の追加・取得・削除、audio overview の生成です。NotebookLM の UI 体験をすべてそのまま API 化できるとは限りません。

Docs や Slides を source にしたい場合、何が増えますか？

Drive 認可、実行ユーザー権限、OAuth scope、対象ファイルへのアクセス権の確認が増えます。最初は text source で接続し、要件が固まってから Google Drive content に広げる方が無難です。

NotebookLM 連携より Gemini API の方が向くのはどんなときですか？

Sheets の列ごと処理、定期バッチ、Webhook、Slack 通知、JSON 出力のように、処理結果を他システムへ流したいときです。NotebookLM の notebook 体験自体が必要なければ、Gemini API の方が軽く作れます。

参考にした公式情報

ブログ一覧へ戻る