株式会社Schooでフロントエンドエンジニアをしている手登根（てとね）です。
先日9/25に、株式会社コドモン様、株式会社エス・エム・エス様、合同会社DMM.com様と弊社の4社合同で「4社が語るリプレイス・リニューアル最前線」というイベントを行いました。
そのイベントで私は「Deep ResearchとNotebookLMを使い倒す！レガシーリプレイスの技術選定と学習コスト削減術」というタイトルで発表したのですが、その時間では話しきれなかった具体的なノウハウについてより深く掘り下げてこの記事で紹介したいと思います。
発表内容おさらい
まずは発表した内容について軽く触れておきます。発表には大きく2つのテーマがありました。
1. 技術選定の壁：調査対象が多すぎる！
最初の壁は「技術選定」です。例えば、私たちのプロジェクトでE2E（エンドツーエンド）テストツールを選定しようとした際、Selenium, Playwright, Cypress…と、数多くの選択肢が目の前に現れました。
これら全てを詳細に調査し、メリット・デメリットを比較するのは膨大な時間がかかります。この情報収集のフェーズをいかに効率化するかが、プロジェクトの初速を決める上で極めて重要でした。
2. 学習コストの壁：新しい技術のキャッチアップが大変！
次の壁は、新しい技術スタックが決まった後にやってくる「学習コスト」です。チーム全員が新しいフレームワークやライブラリをゼロから学び、足並みを揃えて開発を進めるのは容易ではありません。
「この機能はどう実装するんだっけ？」「このエラーの原因は？」といった疑問が頻発し、その都度ドキュメントを読み込んだり、詳しいメンバーに質問したりする時間が増え、開発のスピードは鈍化しがちです。
AIという「武器」で壁を乗り越える
これらの課題を解決するために、2つのAIツールを利用しました。
-
技術選定の壁には「Deep Research」
広範囲のウェブ情報を基に、比較レポートを自動生成してくれるGeminiの機能です。情報収集の時間を大幅に短縮し、私たちはより本質的な「どの技術が最適か」という議論に集中できるようになりました。 -
学習コストの壁には「NotebookLM」
公式ドキュメントなどの信頼できる情報源（ソース）を読み込ませることで、その情報に基づいた回答だけをしてくれるAIです。これにより、チーム専用の「AIチューター」が完成し、メンバーはいつでも気軽に質問できるようになりました。
重要なのは、これらのツールが 「情報ソース」を明確に示してくれる 点です。AIの回答が本当に正しいのかを人間がすぐに検証できるため、誤った情報（ハルシネーション）のリスクを最小限に抑えながら、その恩恵を最大限に享受できます。
というような話をしました。スライドはこちらです。
で、ここからがこの記事の本題です。スライドでは語りきれなかった、Deep Researchを使いこなすための具体的なプロンプトや、NotebookLMに効率的にURLソースを読み込ませる方法をご紹介します。
Deep Researchのプロンプト例
まずはどんな評価軸で比較するかを検討します。上でも例に出てきているE2Eテストツールで考えます。仮にこんな軸で考えたいとします。
- 対応しているブラウザ
- 利用可能なプログラミング言語
- テストの実行速度
- 開発の継続性（将来性）：リポジトリの更新頻度やコミュニティの活発さなど。
- 情報の入手性：公式ドキュメントや技術記事の豊富さ。
- テストの書きやすさ
- GUIからテストが作成できるか
- デバッグの容易さ：テスト失敗時に原因を特定しやすい機能（スクリーンショット、ビデオ録画、トレースなど）があるか。
比較対象は下記３つであるとします。
-
Playwright
-
Selenium
-
Cypress
するとこんなプロンプトが書けます。
E2Eテストツールを比較するための情報収集をお願いします。対象は下記です。
1. Playwright
2. Selenium
3. Cypress
上記3ツールに対して、特に次の情報について調べて一覧にしてください。
- 対応しているブラウザ
- 利用可能なプログラミング言語
- テストの実行速度
- 開発の継続性（将来性）：リポジトリの更新頻度やコミュニティの活発さなど。
- 情報の入手性：公式ドキュメントや技術記事の豊富さ。
- テストの書きやすさ
- GUIからテストが作成できるか
- デバッグの容易さ：テスト失敗時に原因を特定しやすい機能（スクリーンショット、ビデオ録画、トレースなど）があるか。
これをGeminiのDeep Researchに投げるとレポートをまとめてくれるのですが、ここに全部載せると長くなり過ぎてしまうため、表だけにしておきます。
これに加えて、より詳細なレポートが数分で完成します。人力だとそのスピードでは不可能ですね。
こんな感じで、情報収集に関してはDeep Researchに任せて、人間は意思決定や判断といった、より本質的な作業に注力しよう！（ただし情報元の確認はちゃんとする）という話を発表ではしました。
NotebookLMに入力するURLを効率よく取得する方法
発表で、「新たに学びたいフレームワークやライブラリの公式ドキュメントをNotebookLMに追加すると学習効率が爆上がりする」という趣旨の発表を行いました。
NotebookLMは本当にありがたい存在で、個人的にAI関連のサービスで一番使っています。自然言語でライブラリやフレームワークの公式情報から深掘りできるというのが本当に良いです。
で、「公式ドキュメントのURLを一つ一つ入力するの大変じゃないですか？どうやってます？？」という質問をいただいたので自分のやり方を紹介します。
いくつかやり方はあるのですがここでは一番よく使うwgetを使う方法をお伝えします。
https://www.gnu.org/software/wget/
wgetは簡単にいうと指定したURLをダウンロードするコマンドなのですが、オプションをうまく指定することで公式ドキュメントのURLを簡単に取得することができます。
早速コマンド例です。
wget --spider -r --wait=3 -o wget.log https://example.com 2>&1
https://example.comの部分は自分が取得したいサイトのURLに置き換えてください。
コマンドの各オプションの意味
| オプション | 意味 |
|---|---|
| --spider | 🕷️ ファイルをダウンロードせず、ページが存在するかだけを確認するモード。 |
| -r | サイト内のリンクを再帰的に辿ります。 |
| --wait=3 | 1つのページをチェックするごとに平均3秒待ちます。 |
| -o wget.log | 実行した結果のログを wget.log というファイルに書き出します。 |
| 2>&1 | エラー情報も含め、すべてのログをファイルに保存するために入れています。 |
--wait=3せずにコマンドを実行するとDoS攻撃っぽくなってしまうのでサイト側に迷惑をかけないように入れています。
コマンドが終了するとwget.logに結果が出力されています。出力されていることが確認できたら次のコマンドです。
grep '^--' wget.log | awk '{ print $3 }' | sort | uniq > urls.txt
上記は、wget.logからURLだけを抽出するためのコマンドです。（ただし、wgetが出力するログのフォーマットが将来的に変更された場合、このコマンドは使えなくなる可能性があります）
これでurls.txtにwgetコマンドで指定したサイト配下のURLが取得されているはずです。しかし、これをNotebookLMのソースにするのはまだ早いです。CSSや画像のURLが含まれているからです。
そこで次はこのurls.txtを元にGeminiにこんなお願いをします。私はGeminiを使っていますが他の生成AIでも同じことはできると思います。
このURLのリストを、cssやjsのファイルなどを除いて、ブラウザからアクセスしたときにWebページとして表示されるものだけにして下さい。またブラウザでアクセスした時に同じ結果になるものは重複を除外し一つにまとめて下さい。
これでNotebookLMのソースとして使えるURL一覧が完成します。
最後に：皆さんの活用事例も教えてください！
本記事では、Deep ResearchとNotebookLMを使った具体的なノウハウを紹介しました。これらのツールは、開発体験を大きく向上させてくれました。
変化のスピードは速いですが、AIと開発者の協業はまだ始まったばかりです。もし「私たちのチームではこんな風にAIを使っているよ！」「こんな便利な使い方もあるよ！」といった事例があれば、ぜひコメントやSNSで教えていただけると嬉しいです。一緒に、より良い使い方を探していければと思っています。よろしくお願いします。
Schooでは一緒に働く仲間を募集しています！