• 1. 初めに
• 2. 注意事項
• 3. 連絡方法
• 4. おまけ課題の概要
• 4.1 内容と独自性について
• 4.2. 課題のゴール
• 4.3. システムの構成図
• 5. 仕組みを理解する
• 5.1. 前提知識ⅰ：モデルが知らないことを、新たに知ってもらうには？
• 5.1.1. 自前でモデルを用意し、自前でゼロから学習させる
• 5.1.2. 学習済のモデルに追加学習させる（ファインチューニング）
• 5.1.3. モデルが知らない情報をプロンプトに含める（RAG：ラグ）
• 5.1.4. モデルが知らない情報の全てを、毎回のプロンプトに含める（ロングコンテキストの活用/ICL）
• 5.1.5. 仕組みを理解する：まとめ
• 5.2. 前提知識ⅱ：ベクトル化と類似度
• 5.2.1. ベクトル化とベクトルDBへのアップロード
• 5.2.2 ベクトル化するメリット
• 5.2.3 ベクトルの類似度を計算する
• ６. 課題1：テキストをベクトル化し、類似度を計算する
• 6.1. 課題1：準備作業
• 6.1.1. 課題1 - 準備作業1：課題用コードのダウンロード
• 6.1.2. 課題1 - 準備作業2：OpenAIのAPIキーの取得
• 6.2. 課題1：作業内容
• 6.2.1. 課題1 - 作業1：ベクトル値を取得する
• 6.2.2. 課題1 - 作業2：取得したベクトルの次元数を調べる
• 6.2.3. 課題1 - 作業3：ベクトルの類似度を計算できるようにする
• 6.2.4. 課題1 - 作業4：ベクトルの類似度を比較するⅰ ～似た文章で比較する～
• 6.2.5. 課題1 - 作業5：ベクトルの類似度を比較するⅱ ～質問文で比較する～
• 7. 課題2：ベクトルデータをDBにアップロードする
• 7.1. 課題2：準備作業
• 7.1.1. 課題2 - 準備作業1：PineconeのAPIキーの取得
• 7.1.2. 課題2 - 準備作業2：Pineconeのインデックス作成 ＆ 通信先URLの取得
• 7.2. 課題2：作業内容
• 7.2.1. 課題 2- 作業1：コードを完成させる
• 7.2.2. 課題 2- 作業2：データをアップロードする。
• 7.2.3. 課題 2- 作業3：ベクトル化とデータアップロードを一発で可能にする
• 7.3. 課題2：まとめ
• 8. 課題3：ベクトルDBからデータを取得する
• 8.1. 課題3：準備作業
• 8.2. 課題3：作業内容
• 8.3. 課題3：まとめ
• 9. 課題4：独自データを加味した回答を得る
• 10. 課題5：スマホで動かす
• 11. 課題6：チャンク分割
• 11.1. 前提知識ⅰ：チャンク分割とは
• 11.2. 前提知識ⅱ：モデルに渡せるテキスト量（トークン数）には限界がある
• 11.3. 前提知識ⅲ：うまく細切れにするとベクトルの価値を高められる
• 11.4. 課題6：作業内容
• 11.5. 課題6：まとめ
• 12. 最後に
• 12.1. 動かす際の注意
• 12.2. 参考情報：RAGの精度問題について
• 12.3. 参考情報：「アタシAI」の精度改善について
• 12.3.1. 候補1：ベクトル化モデルの変更
• 12.3.2. 候補2：ベクトルDBへのクエリをモデルに考えてもらう
• 12.3.3. 候補3：抽象的だが重要な情報は全てプロンプトに含め、具体的で個別的な情報はRAGとするハイブリッドアプローチ
• 12.4. 参考情報
• 12.4.1. Graph RAG
• 12.5.2. AI Agent
• 12.5. まとめ
• 🌟本コンテンツの未来への提言

このページは、参加頂いた某社の「1Dayインターンシップ」の計画者の1人である作者が、

趣味的に作成した「少し高度なおまけ課題」の解説ドキュメントです。

公式な課題ではなく、インターンシップ後に皆さんの個人的な時間を利用して実施してもらうことを想定しています。

この課題を作成した目的は下記です。

• 生成AIに対する理解度を更に高めてもらうこと
• 生成AIを利用したシステムを作る際の難しさの一端を体感してもらうこと

生成AIを組み込んだシステムを作る際、重要になる要素は下記と考えています。

前段のインターンシップ課題では前半3つ扱いましたが、本課題では後半3つを扱います。

• API通信
• システムプロンプトとユーザープロンプト
• 過去プロンプトの処理
• ベクトル化と類似度計算
• ベクトルデータベース
• チャンク分割

最終的な成果物は、下記理由から就活時に面接官へアピールできる材料にもなるでしょう。

• webと生成AIという訴求力の高い技術を利用したものを、スマホでサッと見せることが可能
• 生成AIへの企業の関心は高い一方、知見を持つエンジニアはまだ多くないので、人材として希少性がある

本課題ですが、下記理由からインターンシップのスタッフへ質問をすることは避けてください。

• 作者が趣味的で作ったものであり、公式の課題ではないこと
• スタッフがサポートできる体制（事前の教育）を用意していなこと

ヒントページは用意しましたので、（特にJavaScriptのプログラミングで）詰まった場合は参考にしてください。

300行のHTMLファイル…ヒントページ

課題を進めるには下記が必要になりますが、インターンシップの価値を維持するため、このドキュメントでは扱いません。

• 1Dayインターンシップで学ぶ「HTML/CSS/JavaScriptの基礎的な知識と技術」
• 1Dayインターンシップで学ぶ「ChatGPTをシステムに組み込むための基礎的な知識と技術」

GitHubディスカッション からお願いします。

GitHub Toms-Ito SimpleRAG · Discussions

ただし、趣味的に用意したものなので、返信にはとても時間がかかると思ってください。。。

シンプルなRAGシステム（Retriever-Augmented Generation）を作成します。

詳細は後述しますが、RAGは「生成AIに “元々は知らない情報” を加味して回答させる手段」として、採用確率の高い方法です。

通常、このようなシステムを作成するためには、プログラムを実行させるためのサーバー環境（Node.js等）を用意するのが一般的ですが、

この課題で作成するものは、300行程度のHTMLファイル1つで完結する点に独自性があります。

この特徴はセキュリティリスク（不注意によるAPIキー流出）が高まる一方で、下記メリットがあります。

• 使用技術の種類を限界(？)まで減らせる。具体的には、HTML/CSS/JavaScript のみ。それだけでも本当に使えるシステムが作れる。
• それにより「生成AIを利用したシステム作成に必要となる本質的な知識/技術」をコスパよく得られる

学生向けの課題としては、意義のあるアプローチだと考えています。

下記の３つ（Aⅰ, Aⅱ, B）の達成がゴールです。

詳細は後述しますが、大まかには下図の構成となっています。

前述の構成図を理解するには、いくつかの前提知識が必要になりますので、ここで解説します。

生成AIと言っても色々な種類がありますが、この課題で利用するのは、LLM（Large Language Model）という種類の生成AIです。

LLMはすごく乱暴に説明すると、言語を扱うAIです（画像を扱う生成AIはLLMとは別の種類のAI）。

本ドキュメントでは以後、LLMを「モデル」と称します。

モデルは人間に例えれば脳ですが、全世界の情報を学習させることは不可能なので、答えられないことは多々あります。

ChatGPT

また、モデルは最新情報も知りません。

詳細は後述しますが、モデルに学習させるのは大変なので、日々生まれる世界の情報を随時、追加学習させているわけではないからです。

Claude

生成AIを利用したシステムを作る際の問題の１つがここにあります。モデルは知らないことだらけなのです。

今回のシステムでは、「家族や友人など、個人の情報を加味した回答を得る」ことが狙いなので、

「モデルが知らないことを新たに知ってもらう」 必要があります。

そのための方法は下記の4つです。

• 自前でモデルを用意し、自前でゼロから学習させる
• 学習済のモデルに追加学習させる（ファインチューニング）
• モデルが知らない情報をプロンプトに含める（RAG）
• モデルが知らない情報の全てを、毎回のプロンプトに含める（ロングコンテキストの活用/ICL）

本システムでは3番目の方法を採りますが、その理由を企業の立場から解説していきます。

技術的難易度や費用の点で一般的な企業で採用するのは難しい方法です。

実施している企業の目的は、大まかに下記2種類に分けられます。

• 一般向けに提供するモデルを開発するため
• 自社利用に特化したモデルを開発するため

前者は OpenAI、Google、Meta(旧Facebook)、Anthropic(元OpenAIの人が設立)、alibaba(中国)、Baidu社(中国) といった世界的大企業が多いです。

後者には規模の小さい企業もあります。

後者の企業例を知るには、下記ページが参考になります。

Amazon Web Services, Inc. Machine Learning Service - Amazon SageMaker Customers - AWS

一般的に、モデルを開発するにはNVIDIA社のハードウェア(GPU)を利用することが多いのですが、

上記ページで紹介されている企業は、Amazon社（傘下のAWS社）の「AIモデルのトレーニング用のチップ(Trainium)」を利用することで、コストを抑えた開発を狙っています。

これも費用と効果の点で、一般的な企業では採用しにくい方法です。

モデルをゼロから自前で開発するのは技術的にもコスト的にも厳しいので、完成済のモデルに追加学習させるアプローチです。

実施する場合は、OpenAI社のモデルや、Meta社のモデルを利用することが多いです。

以下、費用と効果についての補足となります。

「モデルが知らないことを知ってもらう」ための方法として、採用確率が高い方法です。作りやすくコスパが良いためです。

今回課題で利用する手法であり、最もトレンドなアプローチでもあります。

ニュース記事を見る機会も増えています。

武田信晃 「生成AI×RAG」の効果と課題は？　実装しないと「競争力を保てない」これだけの理由

RAGは「Retrieval-Augmented Generation」の略ですが、乱暴に説明すると下記です。

• モデルが知らないことを新たに知ってもらうために、外部の情報源を利用する
• 外部情報をプロンプトに含めることでモデルに知ってもらう

モデルに学習させるのは「頑張って脳を賢くする」方法ですが、RAGは「脳はそのままで、毎回カンニングさせる」アプローチと言えます。

Claude

RAGの外部情報源としてよく利用されるものは次の２つです。それぞれ解説していきます。

• 検索エンジン
• データベース

検索エンジンを利用したRAG

有名なサービスはPerplexityです。

Perplexity AI Perplexity

Perplexityを簡単に説明すると「最新情報を使って回答してくれるAI」です。

非常に便利なサービスなので、作者が調べものをするときのファーストチョイスになっています。

Perplexityは最新情報をインターネット検索エンジン（MicrosoftのBing）を利用して取得しています。

ネットから得た外部情報をプロンプトに含めて、モデルに回答させているのです。

Perplexity AI Perplexity

「モデルが知らない情報」の量が少ないなら、全て毎回のプロンプトに入れれば良いじゃん！

というアプローチです。

解説例として、「彼氏との付き合い方を相談💛AIアプリ」を作る際を考えます。

彼氏の全情報を活用したいですが、用意できた「彼氏の全情報」がテキスト量で100万文字を超えることは多くないと思います。

最新のモデルであれば100万文字以内であれば、モデルに渡せる最大テキスト量の範囲内 (例. Gemini 2.0 pro：200万トークン) になりますので、

ベクトルDBを利用するRAGより「ユーザーの質問に関係なく、毎回、彼氏の全情報をシステムプロンプトとして送信する」方式が適切な可能性は高いです。

Qiita 【最新LLM大比較 2025年版 🤖✨ 】Claude 3.7、GPT-4.5、Gemini 2.0、OpenAI o1の徹底解析 - Qiita

「モデルが知らない情報を全てプロンプトに含めていく」例は下記となります。

このような、モデルが知らない全情報をプロンプトに含めてしまう方法には、「これ！」といった名前は無さそうなのですが、敢えていえば、

「ロングコンテキストの活用」や「ICL：In-Context Learning」と呼ばれる手法です。

両者は厳密には異なるもので、それぞれ簡単に説明すると下記です。

ロングコンテキスト：非常に長い文章のプロンプトを処理できる能力（モデル性能の向上により処理可能なプロンプトのサイズが向上している）

ICL：プロンプトで例示や情報を与えることで、モデルに推論や学習を行わせる方法（プロンプトを上手く工夫する手法）

本手法 (モデルが知らない情報を全てプロンプトに含める) は、モデルに渡す情報が「プロンプトの最大長」に収まるまでは欠点の小さい方法ですが、以下のような弱点もあります。

前述したRAGと本手法のハイブリッドアプローチも考えられ、実はそれこそが、高度なRAGの王道パターンと言えますが、

それは本コンテンツの終盤に参考情報として記載します。

「モデルが知らないことを新たに知ってもらう」方法として、採用率が高い順で並べると下記となります。

RAG (データベースや検索エンジン利用） > 知らない情報を全てプロンプトに含める > ファインチューニング > 自前でゼロからモデル用意

次章では、RAGのデータベースとしてよく利用される「ベクトルDB」を説明していきます。

細かい説明の前に、まずは最終成果物の１つで行う具体的な処理をみてもらいます。

下画像では、ユーザーが入力した文章（テキスト）をカンマ区切りの数値に変換し、ベクトルDBへアップロードしています。

このカンマ区切りの数値がベクトルです。

文章のベクトル化は、モデルの持つ能力を利用することで可能になる処理です。

下図では「文章をベクトル化するモデル」と「ChatGPTが利用するモデル」が同じようにみえますが、実際には異なるモデルが利用されます。

それぞれの代表的なモデル例は下記です。

• 文章をベクトル化するモデル (例)：text-embedding-ada-002, text-embedding-3-large
• ChatGPTが利用するモデル (例)：GPT-4o, OpenAI o1

よくある質問は「モデルはどうやって文章の意味をベクトルに変換するのか？」ですが、それはブラックボックス感が強いです。

単語の意味だけでなく、前後の文脈や単語の位置関係を考慮しているようですが、詳細は下記ページが参考になります。

Zenn Embedding（ベクトル化）についてイメージを掴む！

次章では、なぜこのような処理を行うのかを解説します。

「文章全体の意味」を数値データとして表現できることに、そのありがたさがあります。

重要なので繰り返しますが、「意味」を数値データに変換します。

よって、使われている単語は違っても、意味が似ている文章であれば、似た数値データ（ベクトル）となります。

そして、数値データになることで類似度の計算が可能になります。

これがベクトル化するメリットですが、詳細は次で解説します。

ベクトルの類似度を計算する方法は色々とあるのですが、よく利用されるのはコサイン類似度です。

処理コスパが良いことが、その理由です。

コサイン類似度は、2次元ベクトルを利用して説明されることが多いです。

実際のシステムで利用するベクトルは1,000次元を超えるのですが、2次元ベクトルだと平面での説明ができるため、話が分かりやすくなります。

この方法によるコサイン類似度の説明は世に溢れているので、ググったらすぐに出てくると思いますが・・・

一応、私の方でも解説しておきます。

上図でポイントになるのは下記です。

• 「バス」「 電車」「乗客」の3つの文章(単語)の意味を、2次元ベクトルに変換した図になっている（2次元なので平面で説明できる）
• 「バス ⇔ 電車」 の角度（コサイン類似度）を表すのがθ1
• 「バス ⇔ 乗客」 の角度（コサイン類似度）を表すのがθ2

θ1とθ2を求めることで、「バス」に意味的に近いのは、「電車」なのか「乗客」なのか判断するのです。

これがコサイン類似度の考え方です。

「長さの違いは無視なのですか？ 」というツッコミがあると思いますが、下記の考えに基づくのがコサイン類似度です。

• 意味の近さは角度の影響が大きい （長さ無視でも、精度上の問題は大きくない）
• 長さを考慮しないことで、計算量を減らせる （処理コスパが良い）

次に下図をみてください。

最終的にユーザーが利用するシステム（アタシAI）では、コサイン類似度の算出は上図の「２」のタイミングで行います。「１」「３」処理説明も併せて確認してください。

• １：質問をベクトル化 　

　 Xさんと私のケンカが増えているんだけど、どうすればいい？

• ２：上記「1」とコサイン類似度の高いデータを抽出　

　「Xさんの性格は内弁慶外地蔵です」, 「私の性格は真面目です」

• ３：上記「2」で得られた情報も含んだプロンプトをモデルに渡して、回答を得る

　 Xさん私のケンカが増えているんだけど、どうすればいい？　以下は補足情報です。”Xさんの性格は内弁慶外地蔵です”　”私の性格は真面目です”

このような処理が裏側で動くことで、下画像の応答が成立しています。

概念的な話を続けてきましたが、何となくでも理解してもらえたなら嬉しいです。

課題制作を進めることで、ここまでの話を体で理解していきましょう。

まずはベクトル化と類似度計算を行います。

下記の２つの準備を行いますので、詳細を解説します。

• 課題用コードのダウンロード
• OpenAIのAPIキーの取得

本課題で利用するコードを下のリンクからDLしてください。

課題1では、1つ目のファイルのみ使用しますが、ここで全てダウンロードしておいてください。

ファイルをクリックした先にダウンロードボタンがあります。

以下、社内向けの情報です。本ドキュメントは社内教育での利用も想定しています。

APIキーを取得するための具体的な作業手順は、下記ページが分かりやすかったので参考にしてください。

APIキーが取得できたらOKです。

aik0aaac OpenAI API使ってみた 2024年5月版 - Aikの技術日記

ちなみに、作者はOpenAIのAPIキー取得に大変苦労しました。下記Qiitaページ記載のエラーが発生して解決に30分以上かかったためです。

このページを見つけられなかったら、本課題の作成は投げ出していたかもしれません。。

Qiita OpenAI のクレジットカード支払いでエラーになったのですが、解消できました - Qiita

1つめのファイルをエディタで開いてください。

「OpenAIのAPIキー設定」以外は完成しているので、コードを読んで設定してください。

ブラウザで、入力したテキストに応じたベクトル値が取得できるようになったらOKです。

今回の処理は、最終的なシステムにおける「１」処理に相当します。

取得したベクトル値をエディタにコピペしてください。

各次元は（後工程に都合が良いので）カンマで区切っていますが、カンマを改行に変換すると今回取得したベクトルの次元数が分かるので、作業しましょう。

その後、ベクトルの次元数を調べてください。

ちなみに、このような作業を行う場合はエディタの「正規表現を利用した置換機能」を利用するべきですので、分からない方は調べてみてください。

行数から、取得したベクトルの次元数が分かったらOKです。

今回利用した「テキストをベクトル化するためのモデル」は「text-embedding-ada-002」です。

このモデルが作成するベクトル次元数を調べてもらいました。

「text-embedding-ada-002」が作成するベクトルの次元数は後工程で重要になります。

OpenAI Platform

OpenAI社で、テキストから最も高精度なベクトルを作成できるモデルは「text-embedding-3-large」です。

各モデルの精度の違いは上画像の「PERFORMANCE ON MTEB EVAL」項目を参照ください。

精度（テキストの意味をベクトルに変換できる度）は次元数だけでは判断できないのですが、「text-embedding-3-large」では3072次元のベクトルが作成できます。

コード中のmodel指定を変えるだけで、「text-embedding-3-large」が利用できます。

興味のある人は実験してみてOKですが、実験後は「text-embedding-ada-002」に戻しておいてください。

テキストをベクトル化できるようになったので、次は類似度を計算してみましょう。

数式はググるとすぐに出てきますが、今回はExcelを利用します。

数式は以下に記載しますが、ベクトルの次元数(Excelの行数)に計算式を合わせる必要がある点に注意ください。

Perplexity AI Perplexity

手順

1. データの準備
• 2つのベクトルをExcelの別々の列または行に入力します。
• 例えば、A列にベクトル1、B列にベクトル2を入力します。
2. 計算式の入力コサイン類似度の計算式を以下のように入力します:ここで:

=SUMPRODUCT(A1:A5,B1:B5)/(SQRT(SUMSQ(A1:A5))*SQRT(SUMSQ(B1:B5)))

1. *A1:A5*はベクトル1の範囲
2. *B1:B5*はベクトル2の範囲
3. *SUMPRODUCT*は2つのベクトルの内積を計算
4. *SUMSQ*は各ベクトルの要素の二乗和を計算
5. *SQRT*は平方根を計算
3. 結果の解釈
• 計算結果は-1から1の間の値になります。
• 1に近いほど類似度が高く、-1に近いほど逆の関係を示します

下画像のように、Excelで計算できるようになったらOKです。

下記ⅰとⅱでそれぞれ、ベクトルの類似度を算出してください。

• ⅰ：「花子はカレーが好きです。」⇔「花子の好物の１つはカレーです。」
• ⅱ：「花子はカレーが好きです。」⇔「太郎はカレーが好きです。」

ⅰの方が類似度が高い（ⅰの方がⅱより、1に近い）ことを確認できたらOKです。

作者は初めて実験した際、感動しました。

下記ⅰとⅱでそれぞれ、ベクトルの類似度を算出してください。

• ⅰ：「花子の好きなたべものって何？」⇔「花子の好物の１つはカレーです。」
• ⅱ：「花子の好きなたべものって何？」⇔「花子はラーメンが好きではありません。」

ⅰの方が類似度が高い（ⅰの方がⅱより、1に近い）ことを確認できたらOKです。

今回実験してもらった結果が、下図の「3」と「4」の動作原理になります。

「花子の好きなたべものって何？」という質問テキストをベクトル化する処理は上図「３」に相当します。

そして、質問との意味が近い（回答の参考になる情報）情報を取得するのが上図「４」です。

今回の実験では、類似度計算は「手動のExcel操作」で行いましたが、実際のシステムではベクトルDB側の機能を利用します。

テキストをベクトル化する感覚はつかんでもらえたと思うので、次はベクトル化した情報をDBに格納できるようにしましょう。

この課題では、ベクトルDBにPineconeを使用します。PineconeはベクトルDBとして最も人気のあるサービスの1つです。

ちなみに、企業で今回のようなシステムを作成する場合、ベクトルDBにはMicrosoftの「Azure AI Search」の採用確率が高くなります。

Azure AI Search - 生成型検索 | Microsoft Azure

多機能であることも理由の1つですが、環境面を統一できることが背景として大きいです。

「OpenAI社のモデルを企業で利用する場合、Azure環境で動かすことが多い」ので、モデルとDBをAzure環境で統一することができるのです。

個々人で専用のベクトルDBを用意します。

プライベートな情報を登録してもらうので、個人専用のデータベースでなければ安心して使用できません。

なお、Pineconeは無料で使える範囲で利用しますので、費用はかかりません。

下記２つの準備を行いますので、それぞれ解説します。

• PineconeのAPIキーの取得
• Pineconeのインデックス作成 ＆ 通信先URLの取得

下図のとおり進めれば取得できるはずです。

pinecone The vector database to build knowledgeable AI | Pinecone

Googleアカウントでログインしましょう。 GitHubアカウントは試していませんが、Microsoftアカウントだと謎のエラー発生で往生しました。

進めていくと、下記画面になるはずです。

適切な情報を入力して更に進めましょう。

ⅲに記載されているAPIキーを取得できたらOKです。

ここで作成する「インデックス」はデータを入れるための箱のようなイメージです。

下図の手順で進めます。

作成するインデックスの設定をしていきます。下図ⅰ～ⅲの意味は下記となります

• ⅰ：インデックス名。なんでもいいと思うが、作者は「test01」で作成した。
• ⅱ：重要。インデックスに格納するベクトルの次元数。「text-embedding-ada-002」の作成ベクトル次元数である「1536」を入力。間違えたら作り直し。
• ⅲ：ベクトルの類似度計算方法の指定。コサイン類似度を示す「cosine」のままでOK。

更に続けて、インデックスを作成します。

ⅰ：us-east-1のままでOK。AWS環境が置かれる物理的な地域を選択。

ⅱ：インデックス作成を決定

インデックスが作成され、「HOST」下部に記載されているAPIの通信先URLを取得できたらOKです。

「https://」の後の先頭は、作成したインデックス名になるようです。

ゴール

最終成果物の1つである下図を完成させることがゴールです。

ベクトルDBにデータをアップロードできるようにします。

ベクトル値に加えて、元のテキストもデータベースに保存しているのは、ベクトルから元の文章を復元することはできないためです。

ベクトル化は暗号化や可逆圧縮(zip等)ではないのです。

2つめのコードをエディタで開いてください。

コードは下記設定以外は完成しているので、先ほど入手した値で書き換えてください。

書き換えることができたらOKです。

書き換えた2つめのファイルを、次はブラウザで開きましょう。

このHTMLは、ベクトルDBへデータをアップロードする機能しか持っていません。

下図における「2」処理のみ可能なのです。

そのため、上図「１」に相当する処理は別途で行う必要があります。

つまり、初期状態では下図のように利用することになります。

ちょっと面倒ですが、まずはこの方法でアップロードできるかを確かめてください。

下図のように動作確認ができればOKです。

ベクトルDBにアップロードされたレコードは次の手順で確認できます。

先ほどの作業はちょっと面倒でしたので、ファイル１つだけで作業が済むようにしましょう。

下図ⅰ～ⅳを可能にするということです。

実際の成果物は、3番目のHTMLファイルとして新規作成してください。

これまでの知識/技術と、提供したコードを組み合わせれば作れるはずです。

これにより、最終成果物の1つが完成します。

下図のように、今回作成するHTMLファイル1つだけで「テキスト入力→ベクトルDBへデータアップロード」が可能になればOKです。

テキストをベクトルDBにアップロードする感覚を掴んでもらえたと思います。

今回はPicneconeを利用するため、ベクトル化（エンベディング）は「OpenAIのモデルを利用して自分で実施」しましたが、

企業で採用されることの多い「Azure AI Search」の場合は、エンベディング処理もDB側に任せることが可能なので、コード記述量を減らすことができます。

Azure AI Search - 生成型検索 | Microsoft Azure

Azure AI Searchは便利なのですが、便利なものを最初から使うと原理の理解が疎かになりがちなので、意味のある体験をしてもらえたと思います。

ここでは、下図の「4」に相当する処理の体験をしましょう。

課題2で作成したHTMLを利用して、下記のテキストをそれぞれ別々のレコードとして、ベクトルDBに登録しておいてください。

• 太郎はカレーが好きです。
• 良子はカレーが好きではありません。
• 花子の好物の１つはカレーです。

まずは4番目のコードが動くようにします。

課題2同様、PineconeのAPIキーと通信先URLをセットしてください。

提供コードでは、類似度が高い順に2レコードを取得する設定になっています。

下画像のように質問文と意味の似ているレコードが2つ表示されたらOKです。

課題3は、下図「4」の処理感覚を掴んでもらうことが狙いでしたが、ここで利用したコードはこの先で必要となります。

「ユーザーの回答に利用する情報をベクトルDBから取得する」感覚を掴んでもらえたと思います。

今回の処理が「モデルが知らないことを新たに知ってもらう」手法として、最も採用確率の高い「ベクトルDBを利用したRAG」の中核となる処理です。

次章では、最後の成果物HTML「アタシAI」の作成に入ります。

就活で面接官に見せることも考えて(？)、スマホで動くようにしておきましょう。

デザインもスマホに特化させています。

ゴール

スマホのブラウザで動作確認するのがゴールです。

手順

ⅰ：iPhone/Android共通

• 「アタシAI」のHTMLファイルをGmail等を利用してスマホへ送信。
• スマホ側でファイルをダウンロード

ⅱ：iPhoneの場合

• Microsoftの「Edge」ブラウザをインストールしておく（Safari/Chromeはセキュリティ仕様上、ローカルのHTMLファイルを開けない）
• ダウンロードしたHTMLファイルを「ファイル」アプリで選択→ アプリの共有機能から「Edge」を選択
• 「Edgeで開く」的な操作をすればOK

ⅱ：Androidの場合

• ダウンロードしたHTMLファイルを「ファイル」アプリで選択→ アプリの共有機能で「Chrome」を選択（他のブラウザはテストしていない）して開く

各自のスマホのブラウザで利用できることを確認できたらOKです。

ここまでで、２つのシステム（HTMLファイル）の作成は終了です。

最後に改めて、下図を見てみてください。理解度が高まっていると思います。

ここからは、おまけ課題の目的の1つとした「生成AIを利用したシステムを作る際の難しさの一端を体感してもらう」ための内容になります。

まずは、必要となる前提知識を解説します。

ここまでの作業では、短いテキストをベクトルDBに登録しましたが、場合によってはテキストを「チャンク分割」してからベクトル化します。

チャンク分割は簡単に説明すると、「テキストを細切れにする」作業です。

その作業が必要になる理由を乱暴にまとめると下記です。

• モデルに渡せるテキスト量（トークン数）には限界があるから
• うまく細切れにするとベクトルの価値を高められるから

以下、それぞれ解説していきます。

まずは、下画像をみてください。

OpenAI Platform

上画像の「MAX INPUT」は、「テキストをベクトル化するモデル」に渡せる最大テキスト量を示しています。

単位は文字数ではなく、「トークン」です。

トークンはAI初学者にとって、「なにそれ？」となる言葉の１つだと思います。

以下、乱暴に説明します。

• モデルがテキストを扱う際の単位。1文字になる場合もあれば、1単語になる場合もあれば、どちらでもない場合もある。（例：Replay→ Re / play の2トークン）
• 日本語の場合、1文字が1トークンになりやすいが、厳密ではないし、モデルによっても異なる（例：「日本語」 1〜2トークン→ 日本 / 語 の2トークンの場合あり）
• モデルが変わればトークン数のカウント結果は変わる可能性が高い。モデルによってテキストの分割方法が異なる。

「なにそれ・・・」という感が強まったと思います。

モデルがトークンを単位とする理由を上手く説明したWEBページは見つけられなかったので、気になる人向けには（不本意ながら）下記の本を紹介しておきます。

Amazon.co.jp ChatGPTの頭の中 (ハヤカワ新書) | スティーヴン ウルフラム, 稲葉 通将, 高橋 聡, 稲葉 通将 | 工学 | Kindleストア | Amazon（高い上に読み辛いですが、他にお薦めが無く…）

ポイントを下記にまとめました。このことを意識してシステムを作る必要があります。

• モデルに渡せるトークン数には限界がある （OpenAI社の場合「テキストをベクトル化するモデル」に渡せるトークン最大数は8,191）
• モデルに渡す前に、テキストのトークン数を人間が把握するのは難しい（トークン数を把握したい場合は、そのためにモデルを利用する必要あり）

唐突ですが、「推しのアイドルと会話している気分を味わう」ため、下記の推し活(？)をしているヤバめのファンがいるとします。

• アイドルが投稿するブログやXなど、集められるテキストの全てをベクトルDBに保存するRAGシステムを作成。
• システムプロンプトには右記を設定「あなたは私の推している***です。***と***の情報を渡しますので***になりきって回答してください。」

このファンは、推しが13万字以上のエッセイを発表した場合、チャンク分割の検討が不可避になります。

Deview 元SKE48・大場美奈、アイドル人生を自らの筆で綴った自身初「フォトエッセイ」発売決定

「モデルに渡せるトークン数に上限がある」のは事実ですが、それを理由にチャンク分割している例は少ないと思います。

「ベクトルの価値を高める」ために行っている方が多いはずです。

例として、下の資料をみてください。ページでの見た目は表になっていますが、実態はテキストファイル（CSV）です。

これは、アメリカのプロバスケットリーグであるNBAの選手データです（おそらく2015～2016年あたりのデータ）。

NBAの選手数は1チーム15名、全チーム合わせて450人程度しか在籍できない狭き門なので、八村塁は本当に凄いのです。

間違えました。ゆえに、データ行数も450程度になっています。

ここで、NBAについての色々なデータを収集して活用する「NBA教えるクン」というRAGシステムを作る場合を考えましょう。

ユーザーの質問には「LeBron Jamesのプロフィールを教えて」といった内容も想定されますので、このデータはぜひ活用したいです。

今回のテキストデータは「8,191トークン」に収まるかもしれません。

しかしだからといって、ファイルの中身を丸ごとベクトル化するべきでしょうか？

この場合はあえて、１行ずつでチャンク分割する方が良さそうです。

「LeBron Jamesのプロフィールを教えて」とのベクトル類似度が高いのは、ⅰよりⅱ（LeBron Jamesだけのプロフィール）である可能性が高いためです。

ⅰ：「全ての選手のプロフィール」テキスト（1個）をそのままベクトル化したもの

ⅱ：「個々の選手のプロフィール」テキスト（約450個）をそれぞれベクトル化したもの

ベクトルDBを利用するRAGでは、「ユーザーの質問に対応するデータをどれだけ用意できるか」が重要ですが、それに加えて、

「想定される質問との類似度が高まるように、データをベクトル化する」こともポイントになります。チャンク分割はそのための方法の1つになります。

テキストをうまく細切れにすることで、ベクトル化した際の価値を高められるのです。

ここまでの前提知識をふまえて、現実的な問題を考えてもらいます。

チャンク分割はRAGの精度に直結する重要な前工程です。

今回は扱いませんでしたが、「チャンク分割する前のテキストをAIで要約させることで、情報密度を高めておく」など、色々なアイデアがあります。

チャンク分割は幅広く奥深い処理なのです。

下記ページの「Chunk Optimization」章では、様々なチャンク分割手法が紹介されており、参考になります。

Qiita RAG入門: 精度改善のための手法28選 - Qiita

3つの補足をして、課題6の内容を終えます。

補足１：課題6の緩和方法

課題6の問題の解決は簡単ではありませんが、よく採用される緩和方法の1つを紹介します。

arv100kri Chunk documents in vector search - Azure AI Search

図解すると、下記のようなアプローチになります。

Microsoftが提供するチャンク分割のサンプルプログラムでも、この手法が採用されています。

まとめの前に、注意事項と参考情報を記載します。

今回作成したHTMLファイルは、WEBサーバーに置いてはいけません。下記理由のためです。

RAGの精度を高めるための努力は、世界中のAI系エンジニアが取り組んでいることの１つです。

簡単なことではありませんので、現実には下記の2択が迫られることも多いでしょう。

A：精度が高くないことを許容する

B：高い精度が必要なシステムなので、世に出すことを諦める

下記予測は前者Aの結果、ユーザーにとって期待外れのシステム（ファインチューニング含む）が世に増えていることが背景の1つだと考えています。

publickey 企業にとって、生成AIへの投資を正当化することが課題に。ガートナーが予測。2025年末までに検証プロジェクトの3割が放棄されると

後者Bの例が下記ニュースです。このシステムもRAGであったと推測しています（ファインチューニングを併用したハイブリッド型の可能性もありそうです）。

松浦立樹 ChatGPTでの業務効率化を“断念”──正答率94％でも「ごみ出し案内」をAIに託せなかったワケ　三豊市と松尾研の半年間

まだ少量のデータで動かしている人が殆どだと思いますが、データが増えるほど、期待する精度は出辛くなります。シンプルな作りであるためです。

精度を高める際の候補となるものをいくつか紹介しておきます。

• テキストをベクトル化するモデルを高精度な「text-embedding-3-large」 に変更する
• 上記変更に合わせ、ベクトルDB（Pinceconeのインデックス）を作り直し、3,072次元のデータを格納できるようにする

下図は参考情報です。類似度の計算結果にかなりの違いが出ています。

今回作った「アタシAI」について、下記の違和感を持った人もいるのではないでしょうか？

「話題が似ていても、疑問文と定義文は違うものでしょ」的なツッコミです。

対応方法としては、「クエリ変換」等の名前で呼ばれる手法が効果的です。

【RAG】ユーザーの質問を最適なクエリへ変換する query-transformation について | Hakky Handbook

Zenn Azure OpenAIでHyDEを使ったRAGの検索精度向上を目指す！

簡単に説明すると、下記対応を行うことになります。

• モデルを利用して「ユーザーからの質問」を「ベクトルDBに格納されていそうな情報」に変換する（下表ⅰⅱⅲ）
• 上記の変換結果をベクトルDBへのクエリとする（下表ⅳ）

変換するためのプロンプトは様々なものが考えられますが、一例を記載します。

処理順	システムの処理内容	具体例
ⅰ	ユーザー質問の受付	私とＸさんのケンカが増えているけど、どうするといい？
ⅱ	会話能力を持つモデルへ ベクトルDBへのクエリ作成を依頼する	あなたはベクトルデータベースを利用するRAGシステムの処理の一部を担当するAIアシスタントです。 ベクトルデータベースには、性格や好みなどの情報が個人毎にレコードを分けて格納されています。 「ユーザーからの質問」を記載しますので、ベクトルデータベースに格納されている確率の高い情報に変換してください。 あなたが回答する文章は、そのままベクトル化した後、ベクトルデータベースへのクエリとして利用します。 そのため、クエリとして不要なことは回答しないでください。 なお、クエリを複数回実施するべきと判断した場合は、回答を改行してください。回答行ごとに、クエリを発行します。 #ユーザーからの質問 私とＸさんのケンカが増えているけど、どうするといい？
ⅲ	上記ⅱの回答を得る	私の性格 Ｘさんの性格
ⅳ	上記ⅲをクエリに利用して、 ベクトルDBからデータを取得する	クエリ1「私の性格（をベクトル化したもの）」 →取得できたデータ→ 「私の性格は、マジメです」 クエリ2「Xさんの性格（をベクトル化したもの）」→取得できたデータ→ 「Ｘさんの性格は、内弁慶外地蔵です」

この手法はRAGの外部情報源が検索エンジンである場合にも有効で、採用していることが明らかなサービス例の１つが、Feloです。

FeloはPerplexityの類似サービスで、外部情報源には検索エンジンが該当します（ベクトルDBを利用しているかは不明）。

Felo Felo（フェロー）- 無料のAI検索エンジン

本コンテンツでは、「モデルが知らない情報」を扱うための手段の１つである「RAG」に焦点を当ててきましたが、

「モデルが知らない情報の全てを、毎回のプロンプトに含める（ロングコンテキストの活用/ICL）」という手法もあることを、前半で紹介しました。

この手法とRAGを組み合わせるのは、実は王道パターンなので紹介していきます。

まずは、ロングコンテキストとICLについて、改めて簡単に解説すると下記です。

ロングコンテキスト：非常に長い文章のプロンプトを処理できる能力（モデル性能の向上により処理可能なプロンプトのサイズが向上している）

ICL：プロンプトで例示や情報を与えることで、モデルに推論や学習を行わせる方法（プロンプトを上手く工夫する手法）

上記の「ICL」説明はよく分からないと思うので、詳細度を高めます。

• プロンプトに含める情報量や情報の性質の違い、挙動を最適化させる方法の違いで、いくつかの名前がついている
• 例えば下記は「Few-shot」と呼ばれる手法（いくつかの例から、AIの推論方法をチューニングする手法）

• 「Few-shot」は例示量が少ない場合の名称だが、大量にする「Many-shot」というアプローチもあり、注目が高まっている

中田 敦＝日経クロステック／日経コンピュータ RAGよりも高性能で安い、生成AIの精度を高める「メニーショットICL」の威力

• 「モデルが知らない情報を全てプロンプトに含める」という手法は、「ICLそのものではなく、ICL的アプローチの1つ」である点には注意

そして、ここからが本項のポイントになりますが、

「モデルの知らない情報を全てプロンプトに含める」と「RAG」のハイブリッドは、高度なRAGの王道的アプローチです。

情報の性質によって、どちらを採用するか決め、併用するのですが、具体例は下表となります。

ユーザーが下記入力を行った場合を想定しています。

「彼氏にプレゼントを贈りたいんだけど何がいいかな？モノじゃなくて、彼氏と一緒に一緒に楽しめるコトがいいな」

下記はRAGと本手法の比較まとめです。この性質の違いを上手く扱う手段が、本項で紹介したハイブリッドアプローチとなります。

この使い分け方は、システムプロンプトとユーザープロンプトの違いにも通じます。

実際にプログラミングする場合は、「毎回プロンプトに含める情報」はシステムプロンプトに設定するのが自然でしょう。

2024年の後半から注目度が上がっているアプローチの１つに「Graph RAG」というものがあります。

作者も勉強中なので、まだ詳しくは語れませんが、概要が理解できそうな情報を紹介しておきます。

話題のGraphRAGとは - 内部構造の解析と実用性の考察

2025年5月の段階では、一部研究機関、先進的な大企業の実験段階でのみ利用されているという印象ですが、

従来のベクトルDBを利用したRAGでは実現できないことを可能とするアプローチです。

2024年は「RAG」の注目度が高まった年でしたが、2025年は「AI Agent」が興味関心を集めています。

ZDNET Japan 話題のAIエージェント、「対応は冷静に」とガートナー

「AI Agent」は自律的にAIが動作する点に特徴があります。

例えば、「じゃんけんアプリを作って」と依頼することで、「コードを作成し、実際に動く画面をユーザーに提供する」といった具合です。

アイデア検証のために、「サンプル的なアプリや画面を作る仕事 (プロトタイピング) 」は、「AI Agent」に任せるべき時代になりました。

下記の「AI Agentによるアプリ作成アプリ」はスマホでも動かせるので、触ってみることをオススメします。感動や衝撃があるはずです。

replit Replit Mobile App: Available on iOS and Android

私は「AI Agent」と「RAGに代表されるモデルが知らないことを教える仕掛け」は、どちらも重要になると考えています。

「AI Agent」は自律的に動くAIですが、企業情報など「モデルが知らないこと」へのアクセス手段を提供しないと、依頼できる仕事は増えません。

そして、「AI Agent に大量のファイルへ逐次アクセスさせて、必要な情報を判断させる」のは、非常に効率が悪いのです。人間と同じです。

そのため「モデルが知らないこと」を効率的に教えられるRAG (特にベクトルDBの存在) は、引き続き、企業では重要性が高いです。

後編は以上です。前編と併せて、RAGの重要内容を体で体験してもらいました。

• API通信
• システムプロンプトとユーザープロンプト
• 過去プロンプトの処理
• ベクトル化と類似度計算
• ベクトルデータベース
• チャンク分割

冒頭に記載した下記の目的が達成できたなら嬉しいです。

• 生成AIに対する理解度を更に高めてもらうこと
• 生成AIを利用したシステムを作る際の難しさの一端を体感してもらうこと

想定外(？)に、おまけ課題とは思えない量になってしまいました。

ここまで付き合ってもらえた人がいたなら、感謝です。

皆さんの就活がうまくいくこと、私の会社で仲間として会えること、どちらも期待しております。

冒頭でも記載しましたが、下記は詰まった人向けのヒントページになります。答え合わせとしても活用ください。