1.生成AIの仕組み
学習目標
- 生成AIが確率に基づいてトークンを予測する仕組みを説明できる
- GeminiとNotebookLMを目的に応じて使い分けられる
- AIの出力を検証する2つの方法を使い分けられる
生成AI（Generative AI） とは、テキスト・画像・音声・コードなどのコンテンツを生成できるAIです。代表的なサービスに OpenAI の ChatGPT、Anthropic の Claude、Google の Gemini があります。
これらのサービスの基盤になっているのが 大規模言語モデル（LLM: Large Language Model） です。膨大なテキストデータから言語のパターンを学習したモデルで、文脈に応じた文章を生成できます。
本講義では Google が提供する Gemini と NotebookLM を使います。
1. 出力の仕組み
Section titled “1. 出力の仕組み”1-1. プロンプトとトークン
Section titled “1-1. プロンプトとトークン”プロンプト は、生成AIに渡す入力テキストです。指示・質問・参考にする文脈などを含みます。生成AIはプロンプトを受け取り、それに対する応答を生成します。
プロンプトも応答も、AI の内部では トークン という単位で扱われます。トークンは AI がテキストを処理する単位で、モデルが採用するトークナイザーによって粒度が異なります。
よく使われる単語は 1 トークンですが、珍しい単語や長い単語は単語の一部（サブワード）に分かれます。日本語は、漢字 1 文字でも複数のトークンに分かれることがあります。
たとえば OpenAI のトークナイザーで Hello, world! を分割すると、次の 4 トークンになります。
["Hello", ",", " world", "!"]カンマや記号は独立したトークンになります。一方、空白は次の単語と結合されることが多く、上の例でも world ではなく world（先頭に空白付き）で 1 つのトークンになっています。
1-2. 確率に基づく予測
Section titled “1-2. 確率に基づく予測”生成AIは出力を一度にまとめて生成するのではなく、1 トークンずつ順番に生成します。各ステップで、入力されたトークン列の続きとして「次に来る可能性が高いトークン」を予測します。たとえば「peanut butter and」という入力に対して、続きの候補と確率は次のようになります。
| 候補 | 確率 |
|---|---|
| jelly | 高い |
| banana | 中程度 |
| shoelace | 非常に低い |
「peanut butter and jelly」（ピーナッツバターとジャム）という組み合わせは学習データに頻繁に現れるため、jelly の確率が高くなります。一方、「peanut butter and shoelace」（ピーナッツバターと靴ひも）のような組み合わせは見られないので、確率は非常に低くなります。
AIは候補の中からトークンを1つ選び、出力に追加します。生成されたトークンは次の予測の入力にも加わるので、続きを予測する材料が増えていきます。
入力: peanut butter andステップ1: peanut butter and → jelly を生成ステップ2: peanut butter and jelly → is を生成ステップ3: peanut butter and jelly is → a を生成...出力: peanut butter and jelly is a classic American sandwich.この「生成したトークンを次の予測に再投入する」仕組みを 自己回帰的（autoregressive）な生成 と呼びます。
1-3. コンテキスト
Section titled “1-3. コンテキスト”1-2. で見たように、AIは入力されたトークン列の続きを予測するとき、入力全体を材料にしています。AIが次のトークン予測のために参照する入力全体を コンテキスト と呼びます。
コンテキストに含まれるものは、サービスや状況によって異なります。
- 現在のプロンプト
- これまでの会話のやり取り（過去の質問と AI の応答）
- アップロードした資料（NotebookLM など）
AI は直前のメッセージだけを見ているのではなく、コンテキストに入っているすべてを材料に次のトークンを予測しています。
モデルが一度に扱えるコンテキストには上限があり、これを コンテキストウィンドウ と呼びます。トークン数で表され、モデルによって数千から 100 万トークン程度まで幅があります。コンテキストウィンドウを超えると、古い情報から順にコンテキストから外れていきます。
また、コンテキストウィンドウに収まっている場合でも、コンテキストが長くなるほど AI は直近のメッセージに引っ張られやすくなり、最初に渡した指示や前提が相対的に軽視されることがあります。これは「忘れた」のではなく、新しい情報の影響が強まることで最初の指示の重みが下がる現象です。
AI を使っていて遭遇する次のような現象は、コンテキストの仕組みから説明できます。
| 場面 | コンテキストの観点での説明 |
|---|---|
| 長い会話の途中で最初の指示が無視されはじめた | 直近のメッセージへの偏重や、追加された文脈による希釈で、最初の指示の重みが相対的に下がった |
| NotebookLM が資料の質問に答えられる | 資料を毎回コンテキストに注入してから回答を生成している |
| 長文を貼ると応答が遅くなる | コンテキストが長いほど処理量が増える |
2-2. NotebookLM で扱う Grounding（回答を特定の情報源に基づかせる仕組み）も、技術的にはアップロードした資料をコンテキストに注入してから回答を生成する方法です。資料の範囲内で答えられるのはこのためです。
1-4. 予測と理解の違い
Section titled “1-4. 予測と理解の違い”AI は確率分布とコンテキストを材料に、「続きそうなトークン」を予測しています。「peanut butter and jelly が正しい組み合わせだ」と理解しているわけではなく、学習データのパターンに照らして次の一手を選んでいる、という仕組みです。
この性質が、3. 出力の検証 で扱う検証の必要性につながります。
2. GeminiとNotebookLM
Section titled “2. GeminiとNotebookLM”GeminiとNotebookLMは、どちらもGoogleのLLMを基盤にしていますが、回答の作り方が異なります。
2-1. Gemini
Section titled “2-1. Gemini”Gemini は、学習済みの汎用的な知識をもとに回答します。
テキストだけでなく画像・音声・動画・コードなど、さまざまな形式の入出力に対応する マルチモーダル なサービスです。
| カテゴリ | できること |
|---|---|
| テキスト | 質問応答、要約、翻訳、文章作成 |
| コード | 生成、説明、デバッグ、レビュー |
| 画像 | 生成、編集、解析 |
| 動画 | 生成（Veo） |
| 音声 | 音声対話（Gemini Live）、音楽生成 |
| 調査 | Deep Research（複数サイトを調査してレポートを作成） |
次のような場面で Gemini が向きます。
- JavaScript の配列をソートする方法を調べたい
- 候補のライブラリを比較して選択を相談したい
- 英語の技術記事を要約してほしい
2-2. NotebookLM
Section titled “2-2. NotebookLM”NotebookLM は、ユーザーがアップロードした資料のみをもとに回答します。すべての回答に引用（資料のどの部分に基づくか）が表示され、クリックすると該当箇所にジャンプできます。資料に書かれていない情報については、回答を控える傾向があります。
回答を特定の情報源に基づかせる仕組みを Grounding（グラウンディング） と呼びます。NotebookLMはアップロードされた資料に Grounding することで、回答の正確性を高めています。
| カテゴリ | できること |
|---|---|
| 回答 | 資料に基づく回答（引用付き） |
| 要約 | 要約、FAQ、タイムライン生成 |
| 音声 | 音声解説（ポッドキャスト形式の解説） |
| 動画 | 動画解説 |
| 学習 | フラッシュカード、テスト |
| 資料作成 | スライド、インフォグラフィック |
| 調査 | Deep Research |
次のような場面で NotebookLM が向きます。
- 研修資料の
console.log()の説明箇所を確認したい - 自社の業務マニュアルから手順を引用付きで取り出したい
- 研修資料全体を要約してテストを作りたい
2-3. 使い分け
Section titled “2-3. 使い分け”| 観点 | Gemini | NotebookLM |
|---|---|---|
| 情報源 | 学習データ（一部、関連する Web 情報を含む） | アップロードした資料のみ |
| 引用 | 表示されることもある（必ずではない） | すべての回答に必ず付く |
| 資料にない質問 | 回答する | 回答を控える |
やりたいことに応じて使い分けます。
| やりたいこと | 適したサービス |
|---|---|
| 一般的な技術や概念を調べる | Gemini |
| 特定の資料の内容を確認する | NotebookLM |
| 回答の根拠を確認したい | NotebookLM |
| 資料にない情報も含めて広く調べたい | Gemini |
3. 出力の検証
Section titled “3. 出力の検証”3-1. ハルシネーションと不完全な回答
Section titled “3-1. ハルシネーションと不完全な回答”1-4. で見た通り、AIは確率に基づいてトークンを生成しているので、出力には次のような問題が起こりえます。
1つ目は、事実と異なる情報を生成する ハルシネーション です。人名や日付を間違えたり、存在しないライブラリや、実在するライブラリの存在しない API を紹介したりすることがあります。もっともらしい文章で書かれているため、読んだだけでは間違いに気づきにくくなります。
2つ目は、一見正しく見えるが実際には不完全な回答です。文章やコードの見た目は自然でも、論理が間違っていたり、質問の意図に合っていなかったりすることがあります。
どちらの場合も、出力をそのまま使うのではなく、自分で検証してから使うのが基本です。検証には大きく2つの方法があります。
3-2. 一次情報源での確認
Section titled “3-2. 一次情報源での確認”AIの出力に含まれる事実（人名、日付、数値、機能の説明など）は、その情報の発信元となる公式サイトや公式ドキュメントで確認します。NotebookLM のように引用が付いている場合も、引用先を開いて、その箇所が回答の根拠として本当に妥当かを確認します。資料がコンテキストに入っていても、AI がそれを正しく解釈しているとは限りません。
| 確認したい内容 | 一次情報源の例 |
|---|---|
| ライブラリの API・機能 | そのライブラリの公式ドキュメント |
| JavaScriptの言語仕様 | MDN |
| プロダクトの料金や仕様 | プロダクト公式サイト |
自然な文章で書かれていることと、内容が正確であることは別の問題です。
3-3. 実行による確認
Section titled “3-3. 実行による確認”コードの場合は、実際に動かして期待通りの結果が出るかを確認します。AI が返したコードが「動く」ことと、「自分の意図に合っている」ことは別問題です。AI に「配列を昇順にソートしたい」と質問して、次のコードが返ってきたとします。
const numbers = [3, 1, 4, 1, 5];
numbers.sort();console.log(numbers); // [1, 1, 3, 4, 5]この入力では期待通りの結果になります。では、別の入力ではどうでしょうか。
const numbers = [3, 1, 10, 5];
numbers.sort();console.log(numbers); // [1, 10, 3, 5]10 が 3 より前に来ています。これは sort() がデフォルトで文字列として比較するためです。1つの入力で動いたからといって、意図通りに動くとは限りません。別の入力でも試して初めてこの問題に気づけます。