NotebookLMを試してみたら、仕様確認や改修時の調査にかなり使えそうだった話
今までGoogleの「NotebookLM」を使ってこなかったのですが、「仕様書の確認やシステム改修時の影響調査に使えるのでは？」と思い、サンプルの仕様書を用意して実際に試してみました。
すでに開発実務やドキュメント分析で活用されている方も多いかと思いますが、実際に自分で手を動かしてみたところ、「初期の仕様把握」だけでなく「改修時の修正箇所の洗い出しや対応案の整理」において、非常に使い勝手が良いと感じられました。
今回は、開発現場でよくある「画面・API・DB」の3層仕様書（サンプル）を読み込ませ、実際の開発フローでどう活用できそうかを検証した結果をまとめます。
1. なぜNotebookLMを試してみようと思ったか？
すでに多くの方々がさまざまな活用事例を発信されていますが、システム開発（特に既存システムの改修フェーズ）においては、以下のような作業に時間がかかることがよくあります。
- 「この機能を改修すると、どの画面・API・テーブルに影響が出るか？」の調査
- 複数ファイルに分散した仕様書（画面仕様書、API定義書、DB設計書）の横断確認
- 仕様書間での定義漏れや食い違いのチェック
「これらを簡単な設定でAIにアシストしてもらえないか？」と考え、資料特化型AIである NotebookLM の活用を自分でも検証してみることにしました。
なお、今後の実務利用も見据え、データがAIの学習に使用されない「Google Workspace（企業向けアカウント）」環境 で検証を行っています。
2. 検証環境の準備（3層仕様書の投入）
検証にあたり、ECサイトの「クーポン適用機能」を題材として、以下の3つのサンプル仕様書を用意しました。
- 画面仕様書
- API仕様書
- データベース論理設計書
実務でよく使われるExcel形式やテキストベースの仕様書を想定し、すべてPDF形式に出力・変換してから NotebookLM に登録しました。
※NotebookLMはExcelファイル（.xlsx）の直接登録には未対応のため、Excel側で「PDF形式で保存」してから読み込ませる
NotebookLMでノートブックを新規作成し、上記のファイルを「＋ ソースを追加」からアップロードするだけで準備は完了です。
3. 実践検証：開発実務でどう使えそうか？
① 新規参画時や仕様確認：「3層マッピング」の確認
まずは画面・API・DBを横断した基本仕様の確認です。
プロンプト:
「画面仕様書（SCR-001）で定義されている『エラー表示（トースト通知）』は、API仕様書のどのステータスコードおよび error_code と対応していますか？表形式で整理してください。」
結果:
フロントエンドで表示すべきエラー文言と、バックエンドが返すAPIのステータスコード（400/403/500）が対応付けられた表がスムーズに出力されました。
② 改修フェーズを想定：「影響調査」と「修正箇所の洗い出し」
続いて、システム改修時の影響調査を想定した質問を投げかけてみました。
プロンプト:
「将来的に『一般会員でも特定条件下でプレミアムクーポンを使えるようにする』という仕様変更を行う場合、画面仕様書、API仕様書、DB設計書のどこを修正・考慮する必要がありますか？修正箇所と対応案をまとめてください。」
結果:
- 画面: グレーアウト表示ロジックの変更
- API: 権限チェック（
403 RANK_NOT_MATCH）の判定ロジック変更 - DB:
couponsテーブルのtarget_rank判定や条件カラムの追加検討
…といったように、各レイヤーで発生する修正影響範囲と対応案が箇条書きで出力されました。手作業でドキュメントを1つずつ開いて探すよりも手軽に当たりをつけられそうです。
4. 使ってみて分かったNotebookLMの良さと注意点
ここが良かった点
1. 資料ベースで回答してくれる
指定したソース（仕様書）に書かれていることだけを根拠に回答するため、「知ったかぶり」が起きにくいです。資料にないものは「記載されていません」と返してくれます。
2. 引用元（ソース）へ1クリックで飛べる
回答に付く数字のタグ（[1] など）をクリックすると、画面左側で読み込んだPDFの該当箇所がハイライト表示されます。ファクトチェック（原典確認）がすぐに行えるのが非常に便利なポイントでした。
運用上の注意点
ソースのフォルダ分けは不可
ファイル数が増えると平置きで並ぶため、ファイル名の頭に [画面] [API] [DB] などの接頭辞をつけて整理するのがおすすめです。
5. まとめ
すでに定番ツールとして活用されているエンジニアの方も多いかと思いますが、今回改めて自分で試してみて「設定の簡単さ」に対して「仕様確認や改修調査の補助として得られるメリット」が非常に大きいと実感しました。
今後は実際の開発現場でも、以下のような用途で試していきたいと思います。
- Excel等で作成された仕様書同士の矛盾・定義漏れチェック
- 既存システム改修時の修正箇所洗い出し・影響調査の初期整理
- チームメンバーへの仕様共有やキャッチアップ補助
まだ触ったことがない方や、気になりつつも試していなかった方は、ぜひ一度サンプルファイルなどで手を動かしてみてはいかがでしょうか。
