PLAY DEVELOPERS BLOG

HuluやTVerなどの日本最大級の動画配信を支える株式会社PLAYが運営するテックブログです。

HuluやTVerなどの日本最大級の動画配信を支える株式会社PLAYが運営するテックブログです。

GitHub ActionsとNotebookLMで実現する、AIを活用したドキュメント運用基盤の構築

1. はじめに

こんにちは、ソリューション技術部 開発第2グループの篠原です。

AIの導入により開発効率は飛躍的に向上していますが、コードを書いた後の「次に繋げるための資料整理」など、基礎となる部分を固めることが更なる生産性向上には不可欠です。そのため、私は日々プロジェクトの標準プロセスや運用ツール周りの開発・整備を行っています。

最近、プロジェクトの仕様書や運用資料をNotebookLMへ投入し、次の機能開発時の参考情報抽出や資料作成に活用する取り組みを始めました。今回は、その情報ソース(ドキュメント)をAIに読み込ませるために、どのように環境を準備・自動化したかをご紹介したいと思います。

2. 昨年度下期の活動とNotebookLMの活用について

昨年度下期は、所属グループの製品におけるリグレッションテストの整備やドキュメント管理、開発ツールの改善などを担当していました。その活動の中で「あちこちに散らばったドキュメントの情報を、もっと効率よく引き出したい」という課題が生まれました。

情報はGitHubリポジトリ、Googleドライブ、Backlogなどに点在していたため、まずは一箇所に集約しようと調査していたところ、GoogleのNotebookLMが要件に合致したため活用することにしました。

notebooklm.google

NotebookLMは、ユーザーがアップロードしたドキュメントをAIが整理・分類し、情報収集を効率化してくれるツールです。自分でアップロードした資料のみがデータとして蓄積・参照されるため、誤った学習データによって発生するハルシネーション(もっともらしい嘘)を避けられるという強力なメリットがあります。

情報ソースとして、以下のものをNotebookLMに追加しました。

  • 各リグレッションテストの結果(スプレッドシート)
  • ドキュメントの内容(サーバ構成や機能仕様などを1枚のPDFにまとめたもの)
  • 機能要件などをAIで整理した内容

また、集約したソースからStudio機能を使って、スライド資料やレポートの作成も行っています。

NotebookLM studio部分

これらの機能を機能の要件定義や開発時の資料作成に活用し、各タスクの大幅な時間削減に繋げています。

3. GitHubからNotebookLMへの連携の全体像

ドキュメントの活用方針が決まった後、次に「GitHubで管理している複数のMarkdownファイルを、どのように1枚のPDFにしてNotebookLMへ反映するか」という課題に取り組みました。

私たちのGitHubリポジトリでは、docsディレクトリ配下に単元ごとにディレクトリを分けてドキュメントを管理しています。

docs/
├── 01_introduction/
├── 02_setup/
├── 03_api/
│   ├── 01_auth.md
│   ├── 02_users.md
│   └── 03_items.md
├── 04_db/
│   ├── users_table.md
│   └── items_table.md
├── ・
├── 98_other/
└── 99_old/

運用ルールとして、機能開発などでドキュメントを更新する際は、対象ファイルを作成・修正し、masterブランチへPRを作成してマージしています。

Markdownファイルごとの個別管理は書き手にとっては便利ですが、「一括で閲覧したい」「AIの情報ソースとして利用したい」場合には、ファイルを横断する手間がかかります。そこで、チーム内から「1つのファイルに集約してからAIに情報を引き出させたい」という要望が上がり、以下の全体フローを検討しました。

検討した構成: GitHub Actions → PDF生成 → Googleドライブ(現在は手動配置) → NotebookLM

チームからの要望と、実現したい要点は以下の4つです。

  • ドキュメントは1枚に集約して閲覧できるようにすること
  • 不要な情報(古いファイルなど)は含めないこと
  • 集約したドキュメントからアイデアを抽出し、資料化に活かすこと
  • 元ドキュメントを更新したら、集約版のドキュメントまで自動反映される仕組みにすること

これらの要件を満たすため、MarkdownからPDFを生成するツール md-to-pdf を採用し、以下のGitHub Actionsのワークフローを構築しました。

name: Generate Document PDF

on:
  push:
    branches:
      - master
    paths:
      - 'docs/**'
  workflow_dispatch:

jobs:
  build-pdf:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Japanese Fonts
        run: |
          sudo apt-get update
          sudo apt-get install -y fonts-noto-cjk

      - name: Get Current Date
        run: echo "TODAY=$(TZ='Asia/Tokyo' date +'%Y%m%d')" >> $GITHUB_ENV

      - name: Combine Markdown files
        run: |
          cd docs
          > ../project_document.md

          # 1. 先頭に index.md のみを書き込む
          cat index.md >> ../project_document.md
          echo -e "\n<div style=\"page-break-after: always;\"></div>\n" >> ../project_document.md

          shopt -s globstar

          # 2. 残りのファイルを順番に結合
          for f in **/*.md; do
            if [[ "$f" == "index.md" ]] || [[ "$f" == "docusaurus_tips.md" ]] || [[ "$f" == 99_old/* ]]; then
              continue
            fi

            cat "$f" >> ../project_document.md
            echo -e "\n<div style=\"page-break-after: always;\"></div>\n" >> ../project_document.md
          done

      - name: Generate PDF
        run: |
          echo '{"pdf_options": {"format": "A4", "margin": {"top": "15mm", "right": "15mm", "bottom": "15mm", "left": "15mm"}}, "launch_options": {"args": ["--no-sandbox", "--disable-setuid-sandbox"]}}' > config.json
          npx md-to-pdf project_document.md --config-file config.json

          mv project_document.pdf project_document_${TODAY}.pdf

      - name: Upload PDF Artifact
        uses: actions/upload-artifact@v4
        with:
          name: ${{ env.TODAY }}_${{ github.run_number }}
          path: project_document_${{ env.TODAY }}.pdf
          retention-days: 30

生成したPDFをそのままNotebookLMのソースとしてAPI等で直接追加する方法も模索しましたが、まずはアウトプットを優先しました。 現状は、Actionsで生成されたArtifact(PDF)を手動でGoogleドライブに配置し、NotebookLM側から参照する運用としています。

4. Geminiでの活用方法と利用時の注意点

NotebookLM内でもソースに対する情報収集は可能ですが、実はAIモデルのGemini側からNotebookLMのノートを指定してプロンプトを投げることも可能です。

画像のように、入力欄のプラスボタンから「Notebooks」を選択し、対象のノートを選ぶことで、NotebookLMに登録した情報を参照しつつGeminiの高度な推論を利用できます。

gmini_add_notebooklm

どちらもGoogle製であるため、シームレスにソースを横展開できるのは非常に便利です。NotebookLM側のチャットではモデルの細かい選択ができませんが、Gemini側でノートを指定して最新の上位モデルを利用することで、より精度の高い回答や深い考察が得られます。

5. Googleドライブの自動同期対応について

今回のワークフローを構築していた当時は、Googleドライブへファイルを配置した後、わざわざNotebookLMの画面を開いて手動で同期ボタンを押す必要がありました。

しかし、2026年5月に嬉しいアップデートがあり、Googleドライブ上のファイルが更新された際の自動同期に対応しました。これにより、以前の手動運用からさらに一手間減らすことができ、最新のドキュメントがよりシームレスにAIへ反映される運用が可能になっています。 (注:記事執筆時点では、Google Workspace契約者およびNotebookLMにアクセス可能な個人用Googleアカウントのユーザー向けが対象のようです)

share.google

6. 今後の課題について

「ドキュメントのPDF1枚化」「NotebookLMへの反映」「Geminiでの設計・開発への活用」という当初の目的は達成できました。 しかし、さらに運用を洗練させるため、以下の改良を計画しています。

  • GitHub ActionsでのPDF生成後、Googleドライブの対象ディレクトリへ自動でアップロードする処理の追加
  • MCP(Model Context Protocol)サーバを経由し、Claudeなどの別AIモデルからも読み込みや操作ができる状態への対応
  • 集約したソースを元にした、自社製品用MCPサーバ構築のための下地作り

まだまだ改善の余地はありますが、AIを積極的に活用し、プロジェクト運用上の課題をより早く確実に解決できるよう、日々アップデートを続けていきたいと思います。