「検証環境がない。でも申請期限は待ってくれない。」そんな極限状態に追い込まれたことはありませんか。私は実際にそれを経験しました。本番環境への接続制限と検証環境の払い出し待ちが重なり、実機を一度も触れないまま設計書とエビデンスを揃えなければならない状況に陥ったのです。そのとき私を救ったのが、NotebookLM を「論理的サンドボックス」として使うというアプローチでした。az CLI形式のコマンドをPowerShell形式に変換しながら、実機なしで申請を通した実戦記録をお届けします。
関連情報: 【時短革命】NotebookLMを使ったAI活用事例
GeminiにNotebookLMをソースとして加えることで「Web検索＋ソース参照」を両立する
まず、今回の活用を支えた仕組みを正確に整理しておきます。NotebookLM 単体は、ユーザーが登録したソースの範囲内でしか回答しません。回答時にリアルタイムでWebを参照する機能は持っていないため、登録した仕様書や設計ドキュメントに書いていないことは答えてくれません。これは制約でもあり、同時に「登録ソースへの忠実性」という強みでもあります。
一方、2025年に Google は「Notebooks as a source within Gemini」という統合機能を発表しました。これにより、Gemini のチャット上で NotebookLM のノートブックを情報源として追加できるようになりました。Gemini は Google 検索によるリアルタイムなグラウンディング機能を持つため、「Gemini の Web 検索能力」と「NotebookLM に登録したプロジェクト固有ソースへの参照」を同時に活用できます。
つまり、手元の制約仕様書は NotebookLM に登録しておき、Gemini 上でそのノートブックをソースに指定しながら作業することで、古い仕様書の制約を遵守しつつ、最新の公式ドキュメント情報もリアルタイムで補足できるという構成が実現します。これが今回の「論理的サンドボックス」の核心的な仕組みです。
（出典：Google Blog — Smarter research with Notebooks in Gemini）
極限プロジェクトの背景 — 検証環境が使えない制約
私が直面した状況を具体的にお伝えします。あるAzureインフラ構築プロジェクトで、私はネットワーク設計の担当になりました。しかし、プロジェクトの立ち上がり直後から想定外の制約が重なりました。
まず、本番環境への接続は厳しいセキュリティポリシーで制限されていました。次に、検証用サブスクリプションの払い出しには2週間以上かかる見込みでした。一方で、申請期限は1週間後に迫っていました。つまり、実機を一度も動かさないまま設計書とエビデンスを揃えるという、通常では考えられない状況だったのです。
手元にあったのは以下の資料だけでした。
- プロジェクト独自の制約仕様書（ネットワーク構成の制限が詳細に記載）
- 過去の類似プロジェクトの設計ドキュメント（az CLI形式で記述）
- Azureの公式ドキュメント（一部ダウンロード済み）
そこで私が思いついたのが、これらの資料を NotebookLM にソースとして登録し、NotebookLM 論理的サンドボックスとして活用するという発想でした。実機の代わりに、AIが「仮想的な検証環境」として機能してくれないかと考えたのです。
NotebookLM の特徴として、登録したソースの内容を忠実に参照しながら回答してくれる点があります。つまり、プロジェクト固有の制約仕様書を登録しておけば、その制約に準拠した形で設計の検証ができると判断しました。これが「論理的サンドボックス」という概念の核心です。
【山場】az CLI → PowerShell 設計変換の実戦
最大の課題は、設計書が az CLI 形式で書かれているのに対し、申請システムが PowerShell 形式のみ受け付けるという要件でした。これは単純な構文の書き換えではありません。az CLI と Azure PowerShell モジュールでは、パラメータの構造や処理の順序が異なる場合があるためです。
NotebookLM への問いかけ方
私が NotebookLM に対して行ったのは、単純な「変換してください」という依頼ではありませんでした。制約仕様書を参照させながら、以下のような形で問いかけました。
「登録しているソース（制約仕様書）に従って、以下の az CLI コマンドを Azure PowerShell 形式に変換してください。変換後のコマンドが仕様書の制約（アドレス空間の制限、サブネット命名規則など）を満たしているかも確認してください。また、最新の Az モジュールのコマンドレット名についてはWeb検索で補足した上で回答してください。」
このプロンプト設計のポイントは3点あります。まず、登録ソースを明示的に参照させること。次に、制約の遵守確認も同時に依頼すること。そして、Gemini の Web 検索による最新情報の補足を明示的に求めることです。
VNet 作成コマンドの変換例
実際に変換したコマンドの例を示します。まず変換前の az CLI 形式です。
az network vnet create \
--resource-group MyRG \
--name MyVNet \
--address-prefixes 10.0.0.0/16 \
--subnet-name MySubnet \
--subnet-prefix 10.0.1.0/24NotebookLM が仕様書の制約と最新モジュール情報を参照した上で出力した、変換後の PowerShell 形式がこちらです。
$vnet = New-AzVirtualNetwork `
-ResourceGroupName 'MyRG' `
-Name 'MyVNet' `
-Location 'japaneast' `
-AddressPrefix '10.0.0.0/16'
$subnetConfig = Add-AzVirtualNetworkSubnetConfig `
-Name 'MySubnet' `
-VirtualNetwork $vnet `
-AddressPrefix '10.0.1.0/24'
$vnet | Set-AzVirtualNetworkaz CLI では1コマンドで完結できた処理が、PowerShell では「VNet作成 → サブネット設定追加 → 変更をAzureに反映」という3ステップに分かれます。NotebookLM はこの構造の違いを正確に把握した上で変換してくれました。加えて、仕様書に記載されていた「japaneast リージョン固定」という制約も、-Location パラメータに自動的に補完してくれました。このように、プロジェクト固有の制約がコマンドレベルで反映される点が NotebookLM 論理的サンドボックスの強みです。
Gemini＋NotebookLM連携による最新モジュール情報の補足
変換作業で特に役立ったのが、Gemini と NotebookLM の連携による最新情報の補足です。私が登録した仕様書は数ヶ月前に作成されたものでした。そのため、Azure PowerShell モジュールの最新バージョンで廃止されたパラメータや、推奨されなくなったコマンドレットが含まれている可能性がありました。
Gemini 上で NotebookLM のノートブックをソースに指定して作業することで、Gemini が Google 検索経由で Azure 公式ドキュメントの最新情報を参照し、「このパラメータは Az 12.x 以降では非推奨です。代わりに〜を使用してください」といった補足情報を添えて回答してくれました。NotebookLM 単体では得られなかったリアルタイム情報と、プロジェクト固有の制約参照を同時に活用できた点が決め手でした。
（出典：Google Blog — NotebookLM joins Gemini for Google Workspace）
NotebookLM 論理的サンドボックスで手戻りゼロの審査通過を実現
結果として、NotebookLM 論理的サンドボックスで生成した設計書とPowerShellコードは、手戻りゼロで審査を通過しました。審査担当者からも「コードの品質が高い」とコメントをいただきました。実機を一度も使わずに、です。
この成果を生んだ核心的な要因は2点あります。まず、制約仕様書を NotebookLM にソースとして登録したことで、プロジェクト固有のルールを完全に遵守した回答が得られたことです。汎用的なAIチャットツールでは、プロジェクト独自の制約を毎回プロンプトに書き込む必要がありますが、NotebookLM ではソースとして登録しておけば自動的に参照されます。
次に、Gemini と NotebookLM の連携により最新の公式情報を補足してくれたことで、古い仕様書に起因するエラーを防ぐことができた点です。この2つの組み合わせが「論理的サンドボックス」の真価です。
この手法が再現できる条件
この手法を再現するために必要な条件をまとめます。以下が揃えば、同様の成果が期待できます。
- 整備されたソース資料：制約仕様書・設計ドキュメント・要件定義書など、プロジェクト固有のルールが文書化されていること
- 適切なプロンプト設計：「ソースを参照して」「制約に準拠しているか確認して」「Web検索で最新情報を補足して」という指示を明示的に含めること
- 段階的な検証：一度に大量のコマンドを変換するのではなく、機能単位（VNet、サブネット、NSGなど）で分割して確認すること
逆に言えば、ソース資料が存在しない・整備されていないプロジェクトでは、この手法の効果は限定的です。NotebookLM はあくまでも登録されたソースを論理的に参照する仕組みであるため、ソースの質がそのまま回答の質に直結します。
関連情報: AIツール活用の記事一覧
汎用AIとの比較
ChatGPT や Claude などの汎用AIと NotebookLM を比べると、プロジェクト固有の制約対応という点で大きな差があります。
| 比較項目 | 汎用AI（ChatGPT等） | NotebookLM（ソース登録） |
|---|---|---|
| プロジェクト固有制約の遵守 | 毎回プロンプトに記述が必要 | ソース登録で自動参照 |
| 最新公式情報の補足 | 学習データの範囲に依存 | Gemini連携でWebリサーチ＋ソース参照を両立 |
| 回答の根拠の明示 | 引用が不明瞭な場合あり | どのソースからの情報か明示 |
| 複数ドキュメントの横断参照 | コンテキスト制限あり | 複数ソースを自然に組み合わせ |
関連情報: 生成AI活用の記事一覧
参考資料
あわせて読みたいおすすめ書籍
NotebookLM をより深く使いこなしたい方に向けて、活用ガイド本を2冊ご紹介します。基本操作から実務活用まで体系的に学べる内容です。
まとめ：AIによる実機レス構築という新手法
NotebookLM を「論理的サンドボックス」として活用することで、実機なしのインフラ構築という新たなアプローチが現実のものになりました。この記事のポイントを整理します。
- GeminiにNotebookLMをソースとして追加することで、Gemini の Web 検索とプロジェクト固有ソース参照の両立が実現した
- 制約仕様書・設計ドキュメントをソースとして登録することで、プロジェクト固有のルールを自動遵守した回答が得られる
- az CLI → PowerShell のような設計変換タスクは、NotebookLM の論理的サンドボックス活用と特に相性が良い
- Gemini と NotebookLM の連携により、古い仕様書に起因する問題を最新の Web 情報で補完できる
- 成功の鍵はソース資料の整備と適切なプロンプト設計の組み合わせにある
今すぐ試せるステップとして、まずは手元のプロジェクトの制約仕様書を NotebookLM に登録してみてください。次に、Gemini のチャットでそのノートブックをソースとして追加し、Web 検索と組み合わせながら設計の検証を行ってみましょう。制約環境こそ、AIの論理的サンドボックス活用が真価を発揮するフィールドです。
コメント