NotebookLM・Gemini・Figmaを組み合わせたAIプロダクト開発ワークフロー

NotebookLM・Gemini・Figmaを組み合わせることで、AI時代のプロダクト開発は大きく変わります。従来の開発では、リサーチ資料、ユーザーインタビュー、競合分析、要件定義、ワイヤーフレーム、デザインファイルが別々に管理され、プロダクトマネージャーやデザイナーがそれらを手作業でつなげる必要がありました。しかし、NotebookLMをリサーチ基盤、Geminiを思考整理と要件化の支援、Figmaを設計とプロトタイピングの場として使うことで、情報収集から画面設計までの流れをより一貫したものにできます。

重要なのは、AIにすべてを任せることではありません。ユーザー調査や市場調査をもとに根拠を整理し、その情報をプロダクト要求仕様書、ユーザーストーリー、画面構成、プロトタイプへ変換し、最後に人間がレビューする流れを作ることです。AIはプロダクト開発を代替する存在ではなく、調査・思考・設計・検証の速度を上げるための支援役です。本記事では、NotebookLM、Gemini、Figmaをどのように組み合わせれば、プロダクトマネージャーやUX/UIデザイナーがより速く、より根拠のある開発を進められるのかを詳しく解説します。

1. NotebookLMとは

NotebookLMは、複数の資料や文書をもとに情報を整理し、要点を抽出し、質問しながら理解を深めるためのAIリサーチ支援ツールです。プロダクト開発では、ユーザーインタビュー、アンケート結果、競合分析、議事録、仕様書、過去の意思決定記録などを読み解くための知識基盤として活用できます。特に、情報が複数の資料に分散している場合、NotebookLMを使うことで、資料ごとの断片的な情報を横断的に整理しやすくなります。

NotebookLMの価値は、単なる要約だけではありません。プロダクト開発では、「ユーザーは何に困っているのか」「複数のインタビューに共通する課題は何か」「競合が解決していて自社がまだ対応できていない点は何か」といった問いを立てる必要があります。NotebookLMは、このような問いに対して、資料を参照しながら論点を整理するために役立ちます。つまり、NotebookLMはプロダクト開発における“調査資料を読むための補助脳”として使うと効果的です。

2. Geminiとは

Geminiは、文章生成、要約、構造化、アイデア生成、分析支援、コード支援などに使えるAIアシスタントです。プロダクト開発では、NotebookLMで整理したリサーチ結果をもとに、プロダクト要求仕様書、ユーザーストーリー、ユースケース、機能要件、画面構成案、コピー案、レビュー観点などを作成する場面で活用できます。NotebookLMが資料に基づいた情報整理に向いているとすれば、Geminiは整理された情報を実務で使えるアウトプットへ変換する役割を持ちます。

たとえば、NotebookLMで「ユーザーが初回設定でつまずいている」という課題を見つけた場合、Geminiを使って、その課題をもとにユーザーストーリー、受け入れ条件、オンボーディング改善案、画面構成案へ展開できます。Geminiはゼロから正解を出すためのツールではなく、与えられた文脈をもとに複数の案を出し、プロダクトマネージャーやデザイナーの思考を加速するためのツールです。そのため、Geminiを使うときは、対象ユーザー、課題、制約、成功指標をできるだけ具体的に渡すことが重要です。

3. Figmaとは

Figmaは、UI設計、ワイヤーフレーム、プロトタイピング、デザインシステム、チームコラボレーションに使われるデザインツールです。プロダクト開発では、言葉で整理された要件やユーザーフローを、実際の画面や操作体験として可視化するために使います。プロダクトマネージャー、デザイナー、エンジニア、ステークホルダーが同じ画面を見ながら議論できるため、認識のズレを減らしやすくなります。

Figmaの役割は、単に見た目の美しいUIを作ることではありません。ユーザーがどの順番で情報を理解し、どの画面で判断し、どの操作で目的を達成するのかを検証することです。NotebookLMで抽出したユーザー課題や、Geminiで整理した要件をFigma上に落とし込むことで、リサーチと設計が分断されにくくなります。Figmaは、AIが生成した要件やアイデアを、実際に使える体験へ変換するための検証環境として考えると分かりやすいです。

4. なぜ3つのツールを組み合わせるのか

NotebookLM、Gemini、Figmaを組み合わせる理由は、それぞれがプロダクト開発の異なる工程に強みを持っているからです。NotebookLMは資料に基づく理解、Geminiは思考の整理とアウトプット生成、Figmaは画面化と検証に向いています。3つを別々の便利ツールとして使うのではなく、リサーチから設計までをつなぐ一つのワークフローとして設計することで、AI活用の効果が大きくなります。

4.1 リサーチから設計までをつなげられる

プロダクト開発でよく起きる問題は、リサーチ結果がデザインに十分反映されないことです。ユーザーインタビューやアンケートを行っても、その結果が要件定義や画面設計の根拠として使われなければ、リサーチは単なる参考資料で終わってしまいます。NotebookLMでリサーチを整理し、Geminiで要件へ変換し、Figmaで画面化する流れを作ることで、調査結果を設計判断に反映しやすくなります。

この流れがあると、デザインレビューの質も変わります。単に「このUIが好きかどうか」を議論するのではなく、「この画面はユーザー調査で見つかった課題に対応しているか」「この導線は主要なユースケースを支援できているか」といった会話ができるようになります。リサーチ、要件、デザインがつながることで、プロダクト開発はより根拠のあるものになります。

4.2 情報の再利用が容易になる

プロダクト開発では、一度集めた情報を何度も使います。ユーザーインタビューの内容は、プロダクト要求仕様書にも使えますし、ロードマップの優先順位判断にも使えます。競合分析は、ポジショニング、価格設計、UI改善の参考にもなります。NotebookLMに情報を集約しておくことで、同じリサーチを複数の場面で再利用しやすくなります。

さらに、Geminiを使えば、同じリサーチ結果から用途別のアウトプットを生成できます。たとえば、プロダクトマネージャー向けには要件定義、デザイナー向けには画面構成案、エンジニア向けには仕様整理、経営層向けには要点サマリーを作成できます。情報を一度整理して終わりにするのではなく、目的に応じて再利用できる形にすることが、AI時代のプロダクト開発では重要です。

4.3 AI活用を最大化できる

AI活用で失敗しやすいのは、すべての作業を一つのAIに任せようとすることです。リサーチ、要件定義、デザイン、レビューはそれぞれ性質が異なるため、適したツールと使い方も異なります。NotebookLMは資料に基づく情報整理に向いており、Geminiは生成と構造化に向いており、Figmaは具体的な画面設計と共同編集に向いています。

この役割分担を明確にすると、AI出力の品質も上がります。NotebookLMで根拠を整理してからGeminiに渡せば、一般論ではなくプロジェクト固有の文脈に近いアウトプットを作りやすくなります。そして、Geminiが作った要件や画面案をFigmaで検証することで、抽象的なアイデアを具体的な体験へ変換できます。AIを最大限活用するには、ツール単体ではなく、ツール間の接続を設計することが重要です。

4.4 プロダクト開発速度を向上できる

NotebookLM・Gemini・Figmaを組み合わせると、リサーチ整理、要件作成、画面案作成、レビュー準備にかかる時間を短縮できます。特に少人数チームやスタートアップでは、プロダクトマネージャーがリサーチ、要件定義、仕様整理、デザインレビューまで幅広く担当することが多いため、AIによる支援は大きな効果を持ちます。

ただし、速度を上げることは、品質を犠牲にすることではありません。AIを使って初期案を早く作り、人間がユーザー価値、事業戦略、技術制約、デザイン品質を確認することで、検証サイクルを早められます。プロダクト開発速度を向上する本当の目的は、早く作ることではなく、早く学び、早く改善し、より良い意思決定を行うことです。

5. 全体ワークフローを理解する

NotebookLM・Gemini・Figmaを使ったワークフローは、情報収集、知識整理、要件化、画面設計、検証という流れで考えると分かりやすくなります。まずNotebookLMで資料を集めて読み解き、Geminiで課題や要件へ変換し、Figmaで画面として可視化します。その後、関係者レビューやユーザーテストを通じて改善点を見つけ、再びリサーチや要件へ戻す循環を作ります。

このワークフローは一方向ではありません。Figmaで画面を作ってみた結果、要件の曖昧さに気づくこともありますし、Geminiで要件を整理している途中で追加リサーチが必要になることもあります。AI時代のプロダクト開発では、最初から完璧な仕様を作るよりも、情報を整理し、仮説を作り、素早く可視化し、検証しながら改善する姿勢が重要です。

5.1 情報収集

最初のステップは、プロダクト開発に必要な情報を集めることです。ユーザーインタビュー、アンケート、カスタマーサポートへの問い合わせ、営業メモ、競合資料、市場調査、既存仕様書、過去の議事録など、プロダクト判断に関係する情報を集約します。情報収集の質が低いと、その後の要件定義やUI設計も浅くなってしまいます。

NotebookLMを使う場合は、プロジェクトやテーマごとに資料を整理すると効果的です。たとえば、「オンボーディング改善」「料金ページ改善」「管理画面リニューアル」のようにテーマを分け、そのテーマに関係する資料をまとめます。情報をただ保存するだけではなく、後で質問しやすい状態にしておくことで、NotebookLMをリサーチ基盤として活用しやすくなります。

5.2 知識整理

情報を集めた後は、それを意思決定に使える知識へ変換します。複数の資料を読み比べ、ユーザーがどこで困っているのか、どの課題が繰り返し出ているのか、競合がどのように解決しているのか、自社プロダクトにどのような制約があるのかを整理します。この段階では、単なる要約ではなく、プロダクト判断に使える論点を抽出することが重要です。

NotebookLMを使うと、複数の資料にまたがる共通点や矛盾を確認しやすくなります。たとえば、ユーザー調査では「設定が難しい」と言われている一方で、サポート問い合わせでは「設定後の確認方法が分からない」という声が多い場合、課題は設定画面そのものではなく、設定完了後のフィードバック不足かもしれません。このように、資料を横断して意味を見つけることが知識整理の中心です。

5.3 アイデア生成

知識整理ができたら、次はGeminiを使ってアイデアや要件へ展開します。ユーザー課題をもとに、解決策、ユーザーストーリー、画面構成案、コピー案、検証方法などを生成します。この段階では、最初から一つの正解を出すのではなく、複数の選択肢を出して比較できる状態にすることが重要です。

Geminiに依頼するときは、NotebookLMで整理した内容をそのまま貼るだけではなく、目的や制約を明確に伝えると精度が上がります。たとえば、「新規ユーザーの初回設定完了率を改善したい」「対象はITに詳しくない中小企業の管理者」「画面数は増やしすぎたくない」といった条件を加えることで、より実務に近い提案が得られます。AIに自由に考えさせるのではなく、良い判断材料を渡すことが大切です。

5.4 UI設計

最後に、Geminiで整理した要件や画面案をFigmaで具体化します。まずはワイヤーフレームで情報配置やユーザーフローを確認し、その後UIデザインやプロトタイプへ進めます。Figmaでは、画面ごとの見た目だけでなく、ユーザーがどの順番で操作し、どこで迷い、どのタイミングで判断するのかを検討します。

Figmaで設計するときは、NotebookLMで得たリサーチ結果とGeminiで整理した要件を横に置いて確認すると効果的です。画面の各要素がどの課題に対応しているのか、どの主要アクションを支援しているのかを説明できる状態にしておくことで、デザインレビューの質が上がります。UI設計は見た目を整える作業ではなく、ユーザー課題を体験として解決する作業です。

6. NotebookLMでリサーチ基盤を構築する

NotebookLMをプロダクト開発で使う最初の目的は、リサーチ基盤を構築することです。プロダクトに関する情報は、ユーザー調査、営業メモ、問い合わせ、競合分析、仕様書、議事録などに分散しやすく、そのままでは意思決定に使いにくい状態になりがちです。NotebookLMを使って情報を集約すれば、資料を読み返す負担を減らし、必要な論点を取り出しやすくなります。

6.1 ユーザー調査を蓄積する

ユーザー調査は、プロダクト開発の根拠になります。インタビュー記録、アンケート回答、ユーザーテスト結果、問い合わせ内容をNotebookLMに蓄積することで、ユーザーがどのような場面で困り、どのような言葉で不満や期待を表現しているのかを整理できます。特に、複数の調査結果を横断して見ることで、一人の声ではなく、複数ユーザーに共通する課題を見つけやすくなります。

ただし、ユーザーの発言をそのまま機能要望として受け取るのは危険です。ユーザーが「この機能が欲しい」と言っていても、本当の課題は別の場所にある場合があります。NotebookLMで複数の発言や行動を比較し、表面的な要望の奥にある本質的な課題を探ることで、より価値のあるプロダクト判断につながります。

6.2 市場調査を保存する

市場調査では、業界トレンド、ユーザー行動の変化、技術動向、規制、価格帯、競争環境などを整理します。これらの情報は、プロダクトロードマップや新機能の優先順位を判断するうえで重要です。NotebookLMに市場調査を保存しておけば、後から「この市場で伸びている利用シーンは何か」「競合が重視している価値は何か」といった問いに答えやすくなります。

市場調査は、一度読んで終わりにすると価値が下がります。時間が経つと細かい内容を忘れ、意思決定時に活用できなくなるからです。NotebookLMに保存しておけば、過去の市場資料を再利用し、Geminiで戦略メモやポジショニング案へ展開できます。市場調査を知識資産として蓄積することが、AI時代のプロダクト開発では重要になります。

6.3 競合分析を整理する

競合分析では、競合の機能、料金、オンボーディング、UI、メッセージ、ターゲット顧客、導入事例などを整理します。NotebookLMを使うことで、複数の競合資料や比較メモを横断し、共通点や差別化ポイントを見つけやすくなります。特に、競合がどの価値を前面に出しているのかを比較すると、自社プロダクトの打ち出し方を考える材料になります。

競合分析の目的は、競合を真似ることではありません。むしろ、自社がどのユーザー課題に集中し、どの体験で差別化するのかを明確にするために使います。NotebookLMで競合の傾向を整理し、Geminiで差別化仮説やポジショニング案を作ることで、競合分析を実際のプロダクト戦略へつなげやすくなります。

6.4 プロジェクト知識を集約する

プロジェクト知識には、過去の議事録、仕様書、デザインレビュー、意思決定記録、リリースメモ、振り返りなどが含まれます。これらをNotebookLMに集約しておくと、過去にどのような判断が行われたのか、なぜその仕様になったのか、どの課題が未解決のまま残っているのかを確認しやすくなります。

プロダクト開発では、同じ議論が何度も繰り返されることがあります。過去に却下された案が再び出てきたり、以前の制約が忘れられたりすることもあります。プロジェクト知識をNotebookLMで扱える状態にしておけば、過去の学びを再利用し、意思決定のスピードと品質を高めることができます。

7. NotebookLMで複数文書推論を活用する

複数文書推論とは、複数の資料を横断して情報を比較し、共通点、矛盾、パターン、インサイトを見つける考え方です。プロダクト開発では、ユーザー調査、競合分析、仕様書、議事録、データ分析が別々の資料に分かれていることが多いため、一つの資料だけを見ても全体像は分かりません。NotebookLMは、このような分散した情報を横断的に理解するために役立ちます。

7.1 複数資料を横断分析する

一つのユーザーインタビューだけを見ると、ある課題が非常に重要に見えることがあります。しかし、複数の資料を横断して見ると、それが一部のユーザーだけの課題なのか、多くのユーザーに共通する課題なのかが分かります。プロダクト判断では、個別の声と全体傾向を分けて考えることが重要です。

NotebookLMを使えば、複数のインタビュー記録や問い合わせメモをもとに、共通する困りごとや繰り返し出てくる表現を整理できます。たとえば、「初回設定でユーザーが迷っているポイントを資料全体から抽出して」と問いかけることで、個別資料を一つずつ読み返すよりも効率的に論点を見つけられます。

7.2 共通パターンを抽出する

共通パターンを抽出すると、ユーザー課題の優先順位を判断しやすくなります。複数のユーザーが同じ画面で迷っている、同じ用語を理解できていない、同じ操作で離脱している場合、その課題は改善の優先度が高い可能性があります。NotebookLMは、こうしたパターンを見つけるための補助として活用できます。

共通パターンを見つけた後は、Geminiで課題リストや仮説リストに変換すると実務で使いやすくなります。たとえば、「ユーザーは設定完了後に次に何をすればよいか分からない」というパターンが見つかった場合、それを「完了後の次アクション提示を改善すれば継続率が上がるのではないか」という仮説へ展開できます。

7.3 インサイトを発見する

インサイトとは、単なる事実ではなく、プロダクト判断に使える深い気づきです。ユーザーが「画面が分かりにくい」と言っている場合、本当の課題はレイアウトではなく、専門用語が多すぎて判断できないことかもしれません。複数の資料を横断することで、表面的な発言の裏にある本質的な問題を見つけやすくなります。

NotebookLMは、インサイト発見の補助として使えますが、AIが出したインサイトをそのまま正解として扱うべきではありません。AIが提示した気づきは、仮説として受け取り、原文、ユーザー行動、データと照らし合わせる必要があります。インサイトはAIが完全に決めるものではなく、人間が文脈を理解しながら判断するものです。

7.4 仮説を形成する

リサーチから得たインサイトは、次に検証すべき仮説へ変換します。たとえば、「ユーザーは機能が足りないから離脱している」のではなく、「初回利用時に価値を理解できないため、主要機能に到達する前に離脱している」という仮説が立てられるかもしれません。この仮説があることで、次に何を検証すべきかが明確になります。

NotebookLMで根拠を整理し、Geminiで仮説の形式へ整えると、プロダクト探索に使いやすくなります。仮説は、要件定義やFigmaでのプロトタイプ検証につながります。重要なのは、AIで仮説を作ることではなく、リサーチに基づいた検証可能な問いを作ることです。

8. Geminiで要件を整理する

Geminiは、NotebookLMで整理したリサーチ結果を、実行可能な要件へ変換する段階で役立ちます。プロダクト要求仕様書、ユーザーストーリー、ユースケース、受け入れ条件、機能要件、非機能要件などを整理することで、開発チームやデザインチームが同じ理解で進めるようになります。

8.1 プロダクト要求仕様書を作成する

プロダクト要求仕様書は、何を作るのか、なぜ作るのか、誰のために作るのか、どの成果を目指すのかを整理する文書です。Geminiを使えば、NotebookLMで抽出した課題やインサイトをもとに、背景、目的、対象ユーザー、課題、要件、成功指標の下書きを作れます。ゼロから文書を書くよりも、整理されたドラフトを編集するほうが効率的です。

ただし、プロダクト要求仕様書はAIが書いた時点で完成ではありません。プロダクトマネージャーが、事業戦略、チームのリソース、技術的制約、顧客価値を確認し、内容を調整する必要があります。Geminiは下書き作成や構造化を支援するツールであり、最終的な意思決定を代替するものではありません。

8.2 ユーザーストーリーを生成する

ユーザーストーリーは、ユーザーがどのような目的で何をしたいのかを簡潔に表す形式です。Geminiに対象ユーザー、利用場面、課題、期待する成果を渡すことで、複数のユーザーストーリー案を生成できます。これにより、機能中心ではなく、ユーザー価値中心で要件を整理しやすくなります。

たとえば、「管理者として、初回設定の進捗を確認したい。なぜなら、設定漏れによる利用開始の遅れを防ぎたいから」というような形式にすることで、画面設計や受け入れ条件へつなげやすくなります。生成されたユーザーストーリーは、Figmaでユーザーフローを作る際の設計材料にもなります。

8.3 ユースケースを整理する

ユースケースは、ユーザーがどの状況で、どの目的を持ち、どの手順でプロダクトを使うのかを整理するものです。Geminiを使えば、通常ケースだけでなく、例外ケース、失敗パターン、権限不足、エラー状態、空状態なども洗い出しやすくなります。これにより、実際の利用状況に近い設計ができます。

ユースケースを整理すると、Figmaで必要な画面や状態が見えてきます。たとえば、入力画面だけでなく、確認画面、完了画面、エラー画面、未設定状態の画面が必要だと分かる場合があります。要件定義の段階でユースケースを整理しておくことで、後からデザインや開発で抜け漏れが発生しにくくなります。

8.4 要件を構造化する

要件は、機能要件、非機能要件、UX要件、データ要件、運用要件などに分けて整理すると分かりやすくなります。Geminiは、散らばったメモや議論を構造化し、開発チームやデザインチームが理解しやすい形に整える支援に向いています。特に、要件が複数の資料や議事録に分散している場合、整理の効果が大きくなります。

構造化された要件は、Figmaでワイヤーフレームを作る際にも役立ちます。画面に表示すべき情報、ユーザーが行う操作、システムが返す状態、エラー時の対応が明確になるからです。要件が曖昧なままデザインへ進むと、後から手戻りが増えるため、Geminiで整理する段階を丁寧に行うことが重要です。

9. Geminiでプロダクト探索を支援する

プロダクト探索では、ユーザー課題を理解し、仮説を作り、解決策を検討し、優先順位を決めます。Geminiは、この探索プロセスで問いを整理したり、仮説を広げたり、施策案を比較したりする支援に向いています。特に、NotebookLMで整理したリサーチ結果をもとにGeminiを使うことで、より根拠のある探索ができます。

9.1 問題を明確化する

プロダクト探索で最初に行うべきことは、問題を明確にすることです。ユーザーが本当に困っていることは何か、どの場面で発生しているのか、どれくらい頻繁に起きているのか、事業にどのような影響があるのかを整理します。問題が曖昧なまま解決策を考えると、見た目は良いが価値の低い機能になりやすくなります。

Geminiには、NotebookLMで整理した調査結果をもとに、課題を分類させたり、問題文に変換させたりできます。たとえば、「この調査内容から主要なユーザー課題を3つに整理し、それぞれを問題文として書いて」と依頼すると、探索の出発点を作りやすくなります。問題を明確にすることで、チーム全体が何を解くべきかを共有できます。

9.2 仮説を整理する

問題が明確になったら、次に仮説を整理します。なぜその問題が起きているのか、どの改善が効果を持つのか、どのユーザーに最も影響するのかを仮説として書き出します。仮説があることで、次に何を検証すべきかが明確になり、プロダクト探索が単なるアイデア出しで終わりにくくなります。

Geminiを使うと、一つの課題から複数の仮説を生成できます。原因仮説、解決仮説、価値仮説、リスク仮説に分けると、探索の精度が高まります。たとえば、「初回設定の離脱が多い」という課題に対して、「入力項目が多すぎる」「完了後の価値が見えない」「専門用語が理解しにくい」といった複数の仮説を立てられます。

9.3 ソリューションを検討する

仮説が整理できたら、解決策を検討します。Geminiに複数のソリューション案を出させることで、最初の思いつきに偏らず、複数方向から検討できます。たとえば、機能追加、導線改善、説明文の改善、オンボーディングの短縮、チュートリアルの追加、通知設計の見直しなど、さまざまな案を比較できます。

ソリューション検討では、実装しやすさだけで判断してはいけません。ユーザー価値、事業価値、検証しやすさ、リスク、運用コストも考える必要があります。Geminiで案を広げた後は、人間が優先順位を判断し、Figmaで検証可能な形に落とし込む流れが効果的です。

9.4 優先順位を決定する

すべての案を同時に実行することはできないため、優先順位を決める必要があります。Geminiは、施策ごとの価値、工数、リスク、学習効果を比較するための整理に使えます。特に、複数の案を表形式や評価軸で整理すると、チームで議論しやすくなります。

ただし、優先順位の最終判断はAIではなく人間が行う必要があります。AIは論点整理や比較の補助として使い、プロダクトマネージャーが戦略、ユーザー理解、リソース、技術制約を踏まえて判断します。優先順位は、単にスコアが高いものを選ぶ作業ではなく、チームが何に集中するかを決める重要な意思決定です。

10. GeminiでUX設計を支援する

Geminiは、UX設計の初期整理にも活用できます。ユーザーフロー、情報設計、画面構成、UX課題、マイクロコピー、エラー状態などを洗い出すことで、Figmaに入る前の設計材料を作れます。ここでは、Geminiをデザインの代替として使うのではなく、設計前の思考整理として使うことが重要です。

10.1 ユーザーフローを作成する

ユーザーフローは、ユーザーが目的を達成するまでのステップを整理するものです。Geminiに対象ユーザー、目的、前提条件、制約を渡すことで、必要なステップや分岐を洗い出せます。Figmaで画面を作る前にフローを整理しておくと、画面数や導線の抜け漏れを減らせます。

ユーザーフローが曖昧なままUIを作ると、画面はきれいでも体験が分かりにくくなることがあります。たとえば、登録画面は整っていても、登録後に何をすべきか分からなければ、ユーザーは離脱するかもしれません。Geminiでフロー案を作り、人間がユーザー調査や実際の利用状況と照らして確認する流れが有効です。

10.2 情報設計を整理する

情報設計では、どの情報をどの順番で見せるかを決めます。ユーザーが最初に知りたい情報、判断に必要な情報、行動するための情報を整理することで、画面の分かりやすさが高まります。Geminiは、画面に必要な情報要素を洗い出したり、優先順位を整理したりする支援に使えます。

情報設計が弱いと、ユーザーは何を見ればよいか分からなくなります。特に、管理画面、設定画面、料金ページ、申込フォームのように情報量が多い画面では、情報の順番が体験を大きく左右します。Geminiで情報要素を整理し、Figmaで視覚的に配置を検討することで、より分かりやすい画面を作りやすくなります。

10.3 画面構成を考える

Geminiは、画面構成案の作成にも使えます。画面の目的、ユーザーの状態、主要アクション、必要な情報を指定すると、セクション構成やレイアウトの方向性を提案できます。これは、Figmaでワイヤーフレームを作成する前の下準備として役立ちます。

ただし、Geminiの画面構成案はそのまま最終デザインにするものではありません。実際にFigmaで配置してみると、情報量が多すぎる、主要アクションが目立たない、モバイルで使いにくいといった問題が見えることがあります。Geminiは構成の候補を出すために使い、最終的な画面設計はFigma上で検証する必要があります。

10.4 UX課題を特定する

Geminiは、既存画面やユーザーフローのUX課題を洗い出す支援にも使えます。ユーザーが迷う場所、説明不足になりやすい場所、入力負荷が高い場所、エラーが起きやすい場所を整理できます。特に、デザインレビュー前にチェック観点を作る用途に向いています。

ただし、UX課題の特定では、AIの指摘だけで判断しないことが重要です。AIが問題だと指摘しても、実際のユーザーは迷っていない場合もあります。逆に、AIが見落とした部分でユーザーがつまずくこともあります。Geminiの指摘はレビュー観点として使い、実際のユーザーテストや行動データと組み合わせて判断しましょう。

11. Figmaでワイヤーフレームを作成する

Figmaでの最初の設計段階では、いきなり完成度の高いUIを作るよりも、ワイヤーフレームで画面構造を検討することが重要です。ワイヤーフレームは、情報配置、画面遷移、主要アクション、ユーザーの判断ポイントを確認するための低コストな検証手段です。

11.1 画面構造を可視化する

ワイヤーフレームでは、画面の骨格を可視化します。見た目の細かい装飾よりも、必要な情報、主要アクション、画面の流れを確認することが目的です。Geminiで整理した要件や画面構成案をFigmaに落とし込むことで、文章だけでは見えにくかった問題を早く発見できます。

たとえば、要件上は必要に見えた情報でも、画面に置いてみると多すぎて読みにくい場合があります。逆に、要件には明記されていなかった補足説明や状態表示が必要だと分かることもあります。ワイヤーフレームは、要件と体験のズレを確認するための重要な工程です。

11.2 ユーザーフローを反映する

ワイヤーフレームは、単体の画面だけでなくユーザーフローとして考える必要があります。ユーザーがどこから来て、何を見て、どのアクションを取り、次にどこへ進むのかをFigma上で確認します。画面単体が分かりやすくても、画面間のつながりが悪ければ体験は成立しません。

Figmaでフローをつなげると、確認画面、完了画面、エラー画面、空状態などの不足に気づきやすくなります。特に、初回利用、申込、設定、購入、検索、管理画面のようなフローでは、ユーザーの状態変化を丁寧に設計する必要があります。Geminiで作ったユーザーフロー案をFigmaで検証することで、より実践的なUX設計ができます。

11.3 情報配置を検討する

情報配置では、ユーザーにとって重要な情報をどこに置くかを考えます。画面上部に何を見せるのか、判断に必要な情報をどの順番で並べるのか、主要アクションをどこに配置するのかによって、ユーザーの理解と行動は大きく変わります。Figmaでは、情報の優先順位を視覚的に検討できます。

NotebookLMで得たユーザー課題やGeminiで整理した要件を参照しながら配置を決めると、設計の根拠が明確になります。たとえば、ユーザーが価格の違いで迷っているなら、料金表では比較軸を明確にする必要があります。ユーザーが設定手順で迷っているなら、進捗表示や次の行動を分かりやすく配置する必要があります。情報配置は見た目ではなく、意思決定を支援するための設計です。

11.4 早期検証を行う

ワイヤーフレームは、早期検証に向いています。完成度の高いUIを作る前に、関係者やユーザーに見せて、流れが分かりやすいか、必要な情報があるか、次の行動が明確かを確認できます。早い段階で問題を見つければ、デザインや開発の手戻りを減らせます。

Figmaで簡単なプロトタイプを作れば、クリックの流れも確認できます。この段階では、色や細かい装飾よりも、ユーザーが目的を達成できるかを重視しましょう。早期検証によって、AIで作った仮説や要件が本当にユーザー体験として成立するかを確認できます。

12. FigmaでUIデザインを構築する

ワイヤーフレームで構造が固まったら、FigmaでUIデザインを構築します。ここでは、コンポーネント、デザインシステム、一貫性、開発連携を意識する必要があります。AIで作った案をそのまま使うのではなく、プロダクトのブランド、既存UI、ユーザーの期待、実装制約に合わせて調整します。

12.1 コンポーネントを作成する

Figmaでは、ボタン、入力欄、カード、モーダル、ナビゲーション、アラートなどをコンポーネント化することで、デザインの再利用性が高まります。プロダクトが成長するほど、同じUI部品を一貫して使うことが重要になります。コンポーネント化されていないUIは、画面ごとに微妙な違いが生まれ、ユーザー体験や開発効率に悪影響を与えます。

コンポーネントを作るときは、通常状態だけでなく、ホバー、フォーカス、無効、エラー、読み込み中などの状態も考える必要があります。Geminiで状態パターンを洗い出し、Figmaでコンポーネントとして整理すると、開発チームとの認識ズレを減らせます。UI部品を設計することは、見た目を整えるだけでなく、プロダクト全体の品質を安定させることにつながります。

12.2 デザインシステムを整備する

デザインシステムは、色、タイポグラフィ、余白、コンポーネント、状態、ガイドラインを整理する仕組みです。Figmaでデザインシステムを整備すると、複数画面や複数チームで一貫したUIを作りやすくなります。特に、AIで複数のUI案を出す場合、最終的には既存のデザインシステムに合わせて整理する必要があります。

デザインシステムがない状態でAI生成案を取り入れると、画面ごとに雰囲気や操作感がバラバラになりやすくなります。Figma上で共通コンポーネントやスタイルを整えておけば、GeminiやFigmaのAI支援で作った案も、プロダクト全体のルールに合わせて調整できます。AI時代ほど、デザインシステムの重要性は高まります。

12.3 一貫性を維持する

UIデザインでは、一貫性が重要です。同じ意味のボタンが画面ごとに違う見た目だったり、同じ状態を別の表現で示していたりすると、ユーザーは迷いやすくなります。Figmaでは、コンポーネントやスタイルを活用して一貫性を保つことができます。

一貫性は、ユーザーだけでなく開発チームにもメリットがあります。実装するUIパターンがそろっていれば、開発効率が上がり、品質も安定します。Geminiでデザインレビュー観点を作り、Figma上で画面ごとの表現が揃っているか確認する流れも有効です。AIで速く作るほど、人間による一貫性チェックが重要になります。

12.4 開発効率を高める

FigmaのUIデザインは、最終的に開発へ渡されます。そのため、見た目だけでなく、実装しやすい構造になっているかも重要です。コンポーネント名、状態、レスポンシブ対応、仕様メモ、例外状態を整理しておくと、開発チームとの連携がスムーズになります。

NotebookLMやGeminiで整理した要件をFigma上の仕様メモに反映すると、なぜそのUIになっているのかが伝わりやすくなります。開発時に「この表示はどの条件で出るのか」「エラー時はどうするのか」といった確認が減り、手戻りも少なくなります。Figmaはデザインファイルであると同時に、開発チームとのコミュニケーション資料でもあります。

13. GeminiとFigmaを連携する

GeminiとFigmaを連携させると、UIアイデア、コピーライティング、UX改善案、デザインレビューを効率化できます。Geminiは画面構成や文言の候補を出すことに向いており、Figmaはその案を実際の画面として検証することに向いています。この組み合わせにより、発想と可視化のサイクルを速く回せます。

13.1 UIアイデアを生成する

Geminiは、Figmaに入る前のUIアイデア出しに使えます。画面の目的、ユーザーの状態、必要な情報、主要アクションを伝えると、複数の構成案を生成できます。たとえば、ダッシュボード画面、設定画面、料金比較画面、オンボーディング画面などで、どのようなセクションが必要かを整理する際に役立ちます。

生成されたUIアイデアは、Figmaでラフに検討します。AIの案をそのまま採用するのではなく、ユーザー課題、既存デザインシステム、実装制約を踏まえて調整することが重要です。Geminiは案を広げる役割、Figmaは案を具体化して検証する役割として使うと、効率的に進められます。

13.2 コピーライティングを支援する

UIでは、ボタン文言、見出し、説明文、エラーメッセージ、空状態の文言が非常に重要です。Geminiを使うと、ユーザーに分かりやすいコピー案を複数出せます。特に、専門用語を避けたい場合、短く自然な文言にしたい場合、ユーザーの不安を減らしたい場合に役立ちます。

FigmaでUIを作りながらGeminiでコピーを検討すると、画面内の情報設計が改善しやすくなります。コピーは最後に追加する飾りではなく、ユーザーを次の行動へ導く重要な設計要素です。ボタン一つ、説明文一つで、ユーザーの理解やコンバージョンが変わることがあります。

13.3 UX改善案を提案する

Geminiは、既存のユーザーフローや画面構成に対して、UX改善案を出す支援にも使えます。入力項目が多すぎないか、次のアクションが分かりやすいか、エラー時の説明が十分か、ユーザーが不安になるポイントはないかを整理できます。レビュー前に論点を洗い出す用途に向いています。

ただし、UX改善案は実際のユーザー行動と照らし合わせる必要があります。AIが問題だと指摘しても、実際にはユーザーが迷っていない場合もあります。逆に、AIが指摘しなかった部分でユーザーがつまずくこともあります。Geminiの改善案は、ユーザーテストや行動データと組み合わせて判断しましょう。

13.4 デザインレビューを支援する

Geminiを使って、デザインレビューの観点を整理できます。ユーザー価値、情報設計、一貫性、アクセシビリティ、エラー対応、レスポンシブ対応、実装可能性など、レビュー時に確認すべき項目を事前にまとめられます。レビューが感覚的な好みの議論になりにくくなる点がメリットです。

Figma上でレビューするときは、Geminiが出した観点をもとに、具体的な画面やフローを確認します。レビューは「このデザインが好きかどうか」を話す場ではなく、「この設計がユーザー課題を解決できているか」「要件と矛盾していないか」を確認する場です。AIを使うことで、レビューの質を一定に保ちやすくなります。

14. NotebookLMとFigmaを連携する

NotebookLMとFigmaを連携させる目的は、リサーチ結果を設計に反映することです。ユーザー調査や競合分析で得た情報を、Figma上の画面設計やプロトタイプの根拠として使います。これにより、デザイン判断が主観に偏りにくくなります。

14.1 リサーチ結果を設計へ反映する

NotebookLMで整理したユーザー課題やインサイトは、Figmaの画面設計に反映する必要があります。たとえば、ユーザーが初回設定で迷っているなら、Figmaでは初回導線、説明文、進捗表示、次のアクション提示を重点的に設計します。リサーチ結果が画面に反映されて初めて、調査はプロダクト改善につながります。

リサーチ結果を設計へ反映するときは、各画面がどの課題に対応しているのかを明確にしましょう。Figma上にメモを残したり、関連資料へのリンクを付けたりすると、レビュー時に設計根拠を説明しやすくなります。デザインは感覚ではなく、ユーザー課題に基づく判断として扱うべきです。

14.2 ユーザー課題を可視化する

Figmaでは、ユーザーフロー上に課題を可視化できます。どのステップで迷いが起きるのか、どこで離脱しやすいのか、どの情報が不足しているのかをフロー上に置くことで、チームが課題を共有しやすくなります。これは、プロダクトマネージャー、デザイナー、エンジニアの認識をそろえるうえで有効です。

NotebookLMで抽出した課題をFigmaのフローに対応させると、リサーチと設計がつながります。議論が「この画面をどう飾るか」ではなく、「この課題をどの画面で解決するか」に変わります。ユーザー課題を可視化することで、UI設計の優先順位も決めやすくなります。

14.3 インサイトを設計根拠にする

インサイトは、デザイン判断の根拠になります。たとえば、「ユーザーは機能の多さよりも導入の簡単さを重視している」というインサイトがあれば、Figmaでは機能一覧よりも初回導線の簡潔さを重視する判断ができます。インサイトがあることで、デザインの方向性が明確になります。

NotebookLMで抽出したインサイトをFigma上の設計メモに反映すると、関係者に説明しやすくなります。特に、複数のデザイン案から一つを選ぶ場合、ユーザー課題や調査結果に基づいて判断できるようになります。デザイン判断を属人的な好みから切り離すためにも、インサイトを根拠として扱うことが重要です。

14.4 デザイン判断を支援する

デザイン判断では、複数の案からどれを選ぶかを決める場面があります。NotebookLMで整理したユーザー調査や競合分析を参照すれば、どの案がより課題解決に近いかを判断しやすくなります。たとえば、A案は情報量が多いが理解に時間がかかり、B案は簡潔だが詳細情報が不足している場合、ユーザーの状況に応じて判断できます。

Figmaで複数案を作り、NotebookLMのリサーチ結果と照らし合わせることで、主観に偏らないデザインレビューが可能になります。重要なのは、デザイン案を単体で評価するのではなく、ユーザー課題、成功指標、利用シーンと照らして評価することです。

15. NotebookLMとGeminiを連携する

NotebookLMとGeminiを連携させると、リサーチに基づいたAI出力を作りやすくなります。NotebookLMで資料を整理し、そこから得た要点やインサイトをGeminiに渡すことで、プロダクト要求仕様書、要件、UX案、コピー、レビュー観点の精度を高められます。

15.1 ナレッジを活用する

NotebookLMで整理したナレッジは、Geminiでアウトプットに変換できます。たとえば、ユーザー調査の要点をもとに、プロダクト要求仕様書の背景や課題セクションを作成したり、ユーザーストーリーへ変換したりできます。リサーチを実行可能な形にすることで、調査の価値が高まります。

ナレッジを活用する際は、元資料の文脈を失わないように注意が必要です。Geminiに渡す情報には、対象ユーザー、課題、根拠、制約、目的を含めると、実務に使いやすい出力になりやすくなります。AIに丸投げするのではなく、良い文脈を渡すことが重要です。

15.2 コンテキストを強化する

Geminiに依頼するとき、コンテキストが不足していると一般的な回答になりやすくなります。NotebookLMで整理した資料から、プロジェクト固有の背景やユーザー課題を抽出して渡すことで、Geminiの出力の具体性が高まります。AIの品質は、入力する文脈の質に大きく左右されます。

コンテキストには、ターゲットユーザー、既存課題、利用シーン、成功指標、制約条件を含めると効果的です。たとえば、「B2B SaaSの管理者向け」「初回設定で離脱が多い」「設定完了率を改善したい」「画面数を増やしすぎない」という条件を入れるだけで、出力の方向性は大きく変わります。

15.3 AI出力の精度を向上する

NotebookLMとGeminiを連携させることで、AI出力の精度を高めやすくなります。NotebookLMで根拠を整理し、Geminiで形式化する流れにすれば、思いつきに近い出力ではなく、調査に基づいたアウトプットを作れます。これは、プロダクト要求仕様書やUX設計の品質向上に直結します。

ただし、精度が上がっても人間によるレビューは必要です。AIがもっともらしい要件やUX案を出しても、実際のユーザー行動、技術制約、事業戦略に合っているかは人間が確認する必要があります。AIは出力を速くする存在であり、判断の責任をなくすものではありません。

15.4 リサーチを再利用する

一度整理したリサーチは、複数のアウトプットに再利用できます。プロダクト要求仕様書、ロードマップ、デザインレビュー、ユーザーストーリー、営業資料、社内共有資料など、同じ調査結果からさまざまな成果物を作れます。NotebookLMとGeminiを連携させることで、この再利用がしやすくなります。

リサーチを一度きりの作業で終わらせないことが重要です。プロダクト開発では、過去の学びを次の意思決定に活かせるチームほど強くなります。NotebookLMでリサーチを蓄積し、Geminiで必要な形へ変換する流れを作れば、知識が継続的に価値を生みます。

16. プロダクトマネージャーの実践フロー

プロダクトマネージャーは、ユーザー課題、事業目標、開発制約、デザイン品質を横断して判断する役割を持ちます。NotebookLM、Gemini、Figmaを組み合わせることで、リサーチから要件、デザインまでの流れを管理しやすくなります。

16.1 リサーチを収集する

プロダクトマネージャーは、まず判断材料となるリサーチを収集します。ユーザーインタビュー、問い合わせ、利用データ、競合分析、営業メモ、過去の議事録などをNotebookLMに集め、プロジェクトごとに整理します。この段階で資料をきちんと集めておくと、後の要件定義やデザイン判断が根拠のあるものになります。

リサーチ収集では、量よりも使いやすさが重要です。大量の資料を集めても、目的やテーマごとに整理されていなければ活用しにくくなります。NotebookLMで質問しやすい形にまとめることが、リサーチを意思決定に変える第一歩になります。

16.2 仮説を整理する

収集した情報から、ユーザー課題や解決仮説を整理します。NotebookLMで共通パターンを抽出し、Geminiで仮説リストへ変換すると、プロダクト探索に使いやすくなります。仮説は、次に検証すべき問いであり、プロダクト開発の方向性を決める重要な材料です。

仮説を整理すると、ロードマップや要件定義の判断がしやすくなります。すべての要望に反応するのではなく、重要な課題と検証すべき仮説に集中できます。プロダクトマネージャーにとって、仮説を管理することは、チームの集中力を保つことでもあります。

16.3 要件を定義する

仮説が整理できたら、Geminiを使って要件を定義します。プロダクト要求仕様書、ユーザーストーリー、ユースケース、受け入れ条件、成功指標を作成し、開発チームやデザインチームが理解しやすい形にします。要件は、単なる機能リストではなく、解決すべき課題と期待する成果を含む必要があります。

要件定義では、何を作るかだけでなく、なぜ作るのかを明確にすることが重要です。NotebookLMで得た根拠を要件に反映し、Figmaで設計する際にも参照できるようにします。要件が明確であれば、デザインレビューや開発見積もりもスムーズになります。

16.4 デザインへ落とし込む

要件をFigmaへ落とし込み、ワイヤーフレームやプロトタイプを作成します。プロダクトマネージャーは、Figma上でデザイナーと議論しながら、要件、ユーザー課題、成功指標が画面に反映されているか確認します。ここで重要なのは、デザインを見た目だけで評価しないことです。

Figmaでの設計は、仮説検証の一部です。必要に応じてユーザーテストを行い、NotebookLMやGeminiで得た仮説と実際の反応を照らし合わせます。画面を作って終わりではなく、検証して改善する流れを作ることで、プロダクト開発の精度が高まります。

17. スタートアップでの活用方法

スタートアップでは、少人数で多くの意思決定を行う必要があります。NotebookLM、Gemini、Figmaを組み合わせることで、リサーチ、要件、デザイン、共有資料の作成を効率化し、プロダクト開発速度を高められます。

17.1 少人数開発を加速する

スタートアップでは、プロダクトマネージャー、デザイナー、リサーチャーの役割を少人数で兼ねることがあります。NotebookLMで調査を整理し、Geminiで要件化し、Figmaで設計する流れを作れば、限られた人員でも開発前の整理を進めやすくなります。特に、専任リサーチャーがいないチームでは、AIによるリサーチ整理の効果が大きくなります。

ただし、AIはチームメンバーの代わりではなく、作業を補助する存在です。意思決定、ユーザー理解、品質確認は人間が担う必要があります。AIで速度を上げ、人間が判断の質を担保する使い方が、スタートアップには向いています。

17.2 ドキュメント作成を効率化する

スタートアップでは、ドキュメント作成が後回しになりがちです。しかし、プロダクト要求仕様書、議事録、意思決定記録、仕様メモが残っていないと、後から文脈が失われます。Geminiを使えば、下書き作成や整理を効率化できるため、ドキュメント作成の負担を減らせます。

NotebookLMで資料を整理し、Geminiでドキュメント化する流れにすれば、ゼロから書く負担を減らせます。作成したドキュメントは、Figmaや開発タスクとつなげることで、実行に活かしやすくなります。ドキュメントは作ること自体が目的ではなく、チームの判断と実行を助けるためにあります。

17.3 意思決定を高速化する

スタートアップでは、意思決定の速度が重要です。NotebookLMで資料を確認し、Geminiで論点を整理し、Figmaで案を可視化すれば、関係者との議論が早く進みます。特に、言葉だけでは伝わりにくいアイデアをFigmaで見せることは、意思決定のスピードを大きく高めます。

意思決定を高速化する一方で、根拠を残すことも重要です。なぜその案を選んだのか、どのリサーチに基づいているのか、どのリスクを受け入れたのかを残しておくことで、後から振り返りやすくなります。速く決めることと、雑に決めることは違います。

17.4 プロダクト開発速度を向上する

3つのツールを組み合わせることで、リサーチからプロトタイプまでの時間を短縮できます。情報整理、要件化、UI案作成、レビュー準備をAIで支援できるため、チームは検証と改善により多くの時間を使えます。これは、限られたリソースで動くスタートアップにとって大きなメリットです。

プロダクト開発速度を高める目的は、単に早く作ることではありません。早く仮説を形にし、早く検証し、早く学習することです。NotebookLM、Gemini、Figmaは、この学習サイクルを支える組み合わせとして活用できます。

18. AIファーストなプロダクト開発プロセス

AIファーストなプロダクト開発とは、AIを単発の補助ツールとして使うのではなく、リサーチ、要件、設計、検証、改善の流れに組み込む考え方です。NotebookLM、Gemini、Figmaを組み合わせることで、このプロセスを実践しやすくなります。

18.1 リサーチをAIで整理する

AIファーストな開発では、リサーチ段階からAIを活用します。NotebookLMで資料を整理し、ユーザー課題、競合の傾向、市場の変化を抽出します。これにより、プロダクト判断の前提を早く整理できます。特に、資料が多いプロジェクトでは、AIによる整理が大きな時間短縮につながります。

ただし、AIが整理した内容は必ず原文や出典と照らし合わせる必要があります。リサーチは意思決定の根拠になるため、誤った要約や文脈の抜け落ちを防ぐことが重要です。AIを使うほど、根拠確認の習慣も重要になります。

18.2 要件をAIで生成する

Geminiを使えば、リサーチ結果をプロダクト要求仕様書、ユーザーストーリー、ユースケース、要件リストへ変換できます。これにより、要件定義の初期ドラフト作成が速くなります。プロダクトマネージャーは、ゼロから書くのではなく、生成された下書きを編集する形で進められます。

要件生成では、AIに十分なコンテキストを渡すことが重要です。対象ユーザー、課題、目的、制約、成功指標が不足していると、一般的で浅い要件になりやすくなります。AIを活用するほど、入力する情報の質が成果物の質を左右します。

18.3 設計をAIで支援する

設計段階では、Geminiで画面構成案やUX改善案を出し、Figmaで具体的なデザインに落とし込みます。AIは初期案を出したり、レビュー観点を整理したり、コピー案を作ったりする場面で役立ちます。これにより、デザイナーやプロダクトマネージャーは複数案を比較しやすくなります。

ただし、UI設計はAIだけで完結するものではありません。ユーザーの文脈、ブランド、一貫性、実装制約、アクセシビリティを踏まえて、人間がレビューする必要があります。AIは案を広げるために使い、最終品質は人間が担保します。

18.4 改善を継続する

AIファーストなプロダクト開発では、リリース後の改善も重要です。ユーザーの反応、利用データ、問い合わせ、レビュー結果を再びNotebookLMやGeminiで整理し、次の改善仮説につなげます。これにより、リリースして終わりではなく、継続的な学習プロセスを作れます。

このサイクルを回すことで、プロダクト開発は一度きりの制作ではなく、継続的な改善活動になります。AIは、学習の速度を上げるための仕組みとして活用できます。重要なのは、AIで作ることではなく、AIを使ってより早く学ぶことです。

19. よくある失敗

NotebookLM、Gemini、Figmaを使ったAI活用でよくある失敗は、AI出力をそのまま採用すること、リサーチを省略すること、人間によるレビューを行わないこと、ツール中心で考えることです。AIを使っているからといって、プロダクト判断の質が自動的に上がるわけではありません。

19.1 AI出力をそのまま採用する

AI出力をそのまま採用すると、もっともらしいが実務に合わない要件やデザインが生まれることがあります。AIは文脈を補完してくれる一方で、根拠の弱い提案や一般論を出すこともあります。特に、ユーザー調査や事業戦略の文脈が不足している場合、出力は表面的になりやすいです。

Geminiで作ったプロダクト要求仕様書やUX案、Figmaで作ったUI案は、必ず人間が確認しましょう。ユーザー調査、事業目標、技術制約、既存デザインシステムに合っているかをレビューする必要があります。AIは下書きを速く作るために使い、最終判断はチームで行うべきです。

19.2 リサーチを省略する

AIが便利だからといって、ユーザー調査や市場調査を省略すると、根拠のないプロダクト開発になりやすくなります。AIは与えられた情報をもとに出力するため、入力が浅ければ出力も浅くなります。リサーチを省略したAI活用は、ただ一般論をきれいに整えるだけになりがちです。

NotebookLMを使ってリサーチを整理し、その結果をGeminiやFigmaへつなげることが重要です。リサーチを省略するのではなく、AIでリサーチの活用効率を高める考え方が必要です。AI時代でも、ユーザー理解はプロダクト開発の中心です。

19.3 人間によるレビューを行わない

AI活用では、人間によるレビューが欠かせません。AIは要約、整理、生成を支援できますが、ユーザーの感情、事業上の優先順位、ブランドの一貫性、倫理的な配慮まで完全に判断できるわけではありません。特にプロダクト開発では、文脈を理解した判断が必要です。

人間によるレビューでは、根拠、妥当性、実現可能性、ユーザー価値を確認します。AIが出した案を検討材料として使い、最終判断はチームが行う必要があります。AIを使うほど、人間のレビュー能力も重要になります。

19.4 ツール中心で考える

AI活用で失敗しやすいのは、ツールを使うこと自体が目的になることです。NotebookLM、Gemini、Figmaを導入しても、プロダクト開発の課題が明確でなければ効果は限定的です。まず、何を改善したいのか、どの工程に時間がかかっているのか、どの判断の質を上げたいのかを明確にする必要があります。

ツール中心ではなく、ワークフロー中心で考えましょう。リサーチを早く整理したい、要件定義を改善したい、デザインレビューを効率化したいなど、目的に応じてツールを使い分けることが重要です。AI活用の成功は、どのツールを使うかではなく、どのように開発プロセスへ組み込むかで決まります。

20. NotebookLM・Gemini・FigmaがAI時代の開発基盤になる理由

NotebookLM、Gemini、Figmaは、AI時代のプロダクト開発において、知識活用、思考支援、設計効率化をつなぐ重要な組み合わせです。リサーチを整理し、要件へ変換し、画面として検証する流れを作ることで、プロダクト開発全体を最適化しやすくなります。

20.1 知識を活用できる

AI時代のプロダクト開発では、知識をどれだけ活用できるかが重要になります。ユーザー調査、競合分析、過去の意思決定、仕様書をただ保存するだけではなく、必要なときに取り出して判断に使える状態にする必要があります。NotebookLMは、こうした知識活用の入口になります。

資料を整理し、共通点や論点を抽出することで、GeminiやFigmaでの後工程に使える材料を作れます。知識が整理されていれば、要件定義やデザイン判断も速くなります。逆に、情報が散らばったままだと、AIを使っても十分な効果は出ません。

20.2 思考を加速できる

Geminiを使うと、リサーチ結果から要件、仮説、UX案、コピー案を素早く作成できます。これにより、プロダクトマネージャーやデザイナーは、ゼロから考える時間を減らし、比較や判断に集中しやすくなります。AIは、思考を止めるものではなく、思考の初速を上げるものです。

思考を加速するということは、考えなくてよいという意味ではありません。AIで複数案を出し、人間が選び、修正し、深めることで、より良い意思決定につなげることができます。Geminiは、アイデアを広げ、論点を整理し、文章化するための思考パートナーとして使うと効果的です。

20.3 設計を効率化できる

Figmaを使うことで、要件や仮説を画面として可視化できます。さらにAI支援を組み合わせることで、初期案の作成、コピー調整、レビュー観点の整理を効率化できます。設計の初速が上がることで、検証サイクルも早くなります。

ただし、設計効率化は品質を下げるためのものではありません。早く作り、早く検証し、早く改善するためのものです。Figmaで作った案は、ユーザー課題や要件と照らし合わせて確認し、必要に応じてユーザーテストや関係者レビューを行いましょう。

20.4 プロダクト開発全体を最適化できる

NotebookLM、Gemini、Figmaを連携させると、プロダクト開発全体の流れが改善されます。リサーチが要件に反映され、要件がデザインに落とし込まれ、デザインが検証され、学習が次の改善につながります。この流れができると、AIは単なる便利ツールではなく、プロダクト開発の基盤になります。

重要なのは、ツールを個別に使うことではなく、情報、思考、設計、検証をつなぐワークフローとして活用することです。AI時代の競争力は、どのツールを導入したかではなく、それらをどれだけ実務の流れに組み込めるかによって決まります。

おわりに

NotebookLM・Gemini・Figmaを組み合わせることで、AI時代のプロダクト開発ワークフローを大きく改善できます。NotebookLMはリサーチや資料整理の基盤になり、Geminiは要件定義やUX設計の思考支援に使え、FigmaはUIデザインとプロトタイピングの場として機能します。この3つを連携させることで、リサーチから設計、設計から検証までを一つの流れとして扱いやすくなります。

ただし、このワークフローで重要なのは、AIにすべてを任せることではありません。ユーザー調査や市場調査をもとに根拠を整理し、AIで要件や案を作り、人間がレビューし、Figmaで検証する流れを作ることです。AIはプロダクト開発を代替するものではなく、学習と設計の速度を高めるための支援として使うべきです。

プロダクトマネージャー、UXデザイナー、スタートアップチームにとって、このワークフローは特に有効です。リサーチから要件、要件からUI、UIから検証へとつながる流れを作ることで、より根拠のあるプロダクト開発が可能になります。AI時代の競争力は、どのツールを使うかだけでなく、それらをどのようなワークフローに組み込むかによって決まります。