はじめに こんにちは。2026年4月にInsight Edge（以下、IE）へデータサイエンティストとして新卒入社した田中です。 本記事を執筆している2026年9月時点で、入社から約5か月が経ちました。新卒データサイエンティスト（DS）の2期生として、新卒研修から最初の案件への参画までを経験する中で、入社前には見えていなかったIEの特徴が少しずつ分かってきました。本記事では、実際に働いて感じたことを新卒の視点からお伝えします。 IEへの新卒入社を検討している学生の方はもちろん、商社グループでデータサイエンティストとして働くことに興味がある方にとっても、本記事が参考になれば幸いです。 目次 1. 自己紹介とIEを知ったきっかけ 1.1 大学での研究 1.2 IEを知ったきっかけ 2. 新卒でInsight Edgeに入社した理由 2.1 幅広い事業領域と少数チームの機動力 2.2 メンターから感じた高い技術力と温かい人柄 2.3 学び続けながら柔軟に働ける環境 3. 入社して初めて分かった3つのこと 3.1 分野横断の研修と早期の案件配属 3.2 オフィスで実感した住友商事との距離の近さ 3.3 案件外の活動を通じた学びと交流 4. まとめ 1. 自己紹介とIEを知ったきっかけ まずは自己紹介として、学生時代のバックグラウンドとIEを知ったきっかけについて紹介します。 1.1 大学での研究 大学時代は、経営工学を専攻しており、さまざまな産業領域のテキスト・表・画像・動画データから知識抽出をすることに焦点を当てた研究分野と、自動運転を中心とする強化学習の応用研究の両方を専門とする研究室に所属していました。当時は25人ほどいた学生のうち6〜7割が留学生で、ミーティングは常に英語で行われる国際色豊かな環境でした。 修士の頃は、産総研との共同研究として、スポーツの試合から収集したプレーデータや映像をもとに、テキスト速報や実況・解説を生成する応用研究に取り組んでいました。 1.2 IEを知ったきっかけ IEを知ったきっかけは、修士1年の夏に受講した大学のデータサイエンス講義です。毎回異なる企業が登壇し、さまざまなデジタル活用事例を紹介する講義でした。ある回にIEの社員が登壇し、そこで初めてIEを知りました。 講義では、IEが住友商事グループ内のDX推進を担っている会社であることが紹介されていました。また、案件としては商社ならではの幅広い産業分野を扱い、その中でPoCからプロダクト開発までを内製の少人数のチームで進めていることも知りました。 講義を通じて、私はIEに次のような魅力を感じました。 さまざまな事業領域に触れられそうで、面白そう 海外案件に関わり、研究室で英語を使ってきた経験も生かせそう 優秀な技術者と働きながら、若いうちから裁量を持って成長できそう いずれも自分の就職活動の軸と合っていたため、講義の最後に案内されたインターンシップへの応募を決めました。 その後、面接を経て、2024年夏の1か月間のインターンシップに参加しました。このインターンシップは、講義だけでは分からなかったIEの詳しい仕事内容や組織体制などを、より深く知る機会になりました。その内容については次の章で詳しく説明していきます。 また、インターンシップで取り組んだ内容は、 こちらの記事 で紹介していますので、興味のある方はぜひこちらもご覧ください。 2. 新卒でInsight Edgeに入社した理由 本章では、インターンシップでの経験を踏まえた、私がIEへの入社を決めた理由について、3つ紹介します。 2.1 幅広い事業領域と少数チームの機動力 IEは住友商事グループの内製的なパートナーとして、コーポレートや、グループ内の事業会社の方々と目標を共有しながらプロジェクトに取り組みます。案件によっては、提示された要件を実装するだけでなく、課題がまだ明確になっていない段階から議論し、PoCや開発、現場での活用まで継続して関わります。IEがデータやAIに関する知見を提供する一方で、クライアントからは業務や事業について学び、双方の知見を持ち寄って解決策を考えられることに、内製パートナーならではの健全な関係性を感じました。 また、住友商事グループには多様な事業会社があり、海外案件を含むさまざまな業界の事業や課題に触れられることも魅力でした。IEは、住友商事グループの幅広い事業基盤をフィールドとしつつ、比較的少人数でのプロジェクトを進めます。新しい技術を積極的に取り入れ、まずは自分たちで検証してみるという姿勢が根付いており、成長環境として理想的だと感じていました。 2.2 メンターから感じた高い技術力と温かい人柄 インターンシップでは、3人の方にメンターとしてご指導いただきました。皆さんが豊富な経験と高い技術力を備えながらも、新しい技術に強い好奇心と探究心を持ち、学んだことを楽しみながら仕事に生かそうとする姿勢を持っていたことが印象に残っています。経験を積んだ後も学び続ける方々と働ける環境は、技術者として成長していくうえで非常に魅力的だと感じました。 加えて、私の話や疑問へ耳を傾け、気さくに応じてくださった姿も印象的でした。入社後に活躍できるか、不安を持つ新卒もいると思いますが、私の場合は、「IEであれば大丈夫」と思えたことも入社を決めた理由の1つです。 2.3 学び続けながら柔軟に働ける環境 働く環境や制度の充実も、IEへの入社を決めた理由の1つです。例えば、業務時間の一部を自己研鑽や勉強会に充てられる制度があります。目の前の案件に必要な知識だけでなく、自分が興味を持った技術を試し、将来の仕事につなげる時間も用意されています。そこに、社員の継続的な成長を大切にする姿勢を感じました。 また、業務内容やチームの状況に応じて、テレワークやサテライトオフィスを利用できる点にも魅力を感じました。私自身は出社派で、対面で働くことから得られるものも大きいと感じています。一方、その日の業務や生活に合わせて働く場所を選べる点は、ライフステージが変化しても働き続けるうえで大きな魅力だと思いました。 IEに入社してから、「いろいろな選択肢があった中で、なぜ新卒でIEに入社したの？」と聞かれることがあります。私にとっては 大企業グループの幅広い事業にパートナーとして関われること 技術力と人間的な魅力を備えた社員の方々と働けること 新しい技術を学びながら柔軟に働けること の3つが、私がIEへの入社を決めた大きな理由でした。以上が本章のまとめです。 3. 入社して初めて分かった3つのこと 夏季インターンシップ後に本選考を経て、内定をいただきました。その後、自ら志願し、修士2年の4月から約6か月間、内定者インターンシップに参加しました。途中で1か月の研究留学を挟みましたが、このインターンシップでは音声対話型マルチエージェントに関する調査に主に取り組みました。この内容に興味がある方は、ぜひ こちらの記事 をご覧ください。 2つのインターンシップを通じてIEへの理解は深まりましたが、それでも、入社して初めて分かったことがいくつかありました。ここからは、新卒研修や最初の案件への参画を通じて特に強く感じたことを、3つに分けて紹介します。 3.1 分野横断の研修と早期の案件配属 研修 入社後の最初の2か月間は、新卒研修として座学とアプリ開発に取り組みました。開発したアプリの詳細は割愛しますが、アプリ開発研修では1つのアプリを企画から開発まで形にしました。参加者は私一人だったため、データサイエンティスト（DS）だけでなく、エンジニア（ENG）やプロジェクトマネージャー（PM）の業務も体験しました。各職種に求められる基礎知識と、プロジェクトにおける役割を学べるように設計された研修でした。 新卒研修で体験したPM・ENG・DSの役割（筆者作成） この研修で特に良いと感じたのは、アプリ開発の進捗に合わせて、その時点で必要となる技術を座学で学べるようなスケジュールが組まれていたことです。座学で得た知識をすぐにアプリ開発で試せるため、知識を学ぶだけで終わらず、実践を通して理解を深めることができました。 この座学研修で学んだ内容を、DS・ENG・PM・その他の分野に分けると、次のようになります。 分野 座学研修で学んだ分野 DS ・データ前処理・後処理 ・時系列分析 ・画像処理 ・統計 ・数理最適化 ENG ・エンジニア心構え ・データベースモデリング ・オブザーバビリティ ・Webを支える技術（TCP/IP） ・ソフトウェアテスト ・AIコーディング ・生成AI概論 ・GitHub/Gitワークフロー ・IaC・CI/CD ・UI/UX ・良い設計・良いコード ・セキュリティ PM ・プロジェクトマネジメント ・開発プロセス その他 ・テクニカルライティング ・スライド作成技術 研修を通じ実感したことは、DSに求められるのは、与えられたデータを分析してモデルを作ることだけではないということでした。IEのプロジェクトでは、エンジニアチーム内のPM・ENG・DSがそれぞれの専門性を持ち寄ります。PMの視点を知ることは、プロジェクトでのヒアリングや課題整理、検証計画について、技術者の立場から意見を出す際に役立ちます。また、ENGの視点を知ることで、PoC後の本番開発を見据えてコードやインフラを整備したり、PMが整理した要件を開発へつなげたりしやすくなります。 生成AIをはじめとするツールによって、技術の調査やコーディングの進め方は変わりつつあります。だからこそ、これからのDSには自分の専門領域だけに閉じない姿勢が必要で、PMやENGの仕事も自分ごととして捉え、プロジェクト全体を前に進める力がより重要になると私は考えています。分野を横断して学ぶこの研修は、私にとって、将来どのようなDSを目指したいかを考えるきっかけを与えてくれました。 案件配属 5月に研修を終え、6月から実際のプロジェクトチームに参画しました。私が配属されたチームは比較的少人数で、新卒の私にも早い段階からタスクを任せていただき、議論の中で意見を求められました。たとえばMVP開発の方針提案を検討する場面では、対象モデルの仕様を調査し、その内容をチームに報告した上で、推奨する活用方針などを提案しました。指示された作業をこなすだけでなく、研修や学生時代に学んだことをプロジェクトに生かし、技術者の一人として自分の考えをチームに伝えることが期待されている点は、入社前の想像以上に印象的でした。 早い段階からタスクを任せていただきながら、一方で分からないことや判断に迷うことがあれば、いつでもメンターに相談できる環境が整っていました。案件への配属後も、案件について相談する機会や、仕事の進め方・今後伸ばしたいスキルについて話す機会が設けられています。 このサポート体制には、現在も大きく助けられています。うまくできた点は評価していただき、改善すべき点は具体的に指摘していただけます。そのため、これまでの経験を振り返り、学びを次にどう生かすかを考える力を日々鍛えることができています。一人の新人にきちんと向き合い、成長を支えてくれる方々がいることは、IEの良さだと感じています。 3.2 オフィスで実感した住友商事との距離の近さ 私は新卒DSの2期生ということもあり、入社前は、IE社内で同世代とのつながりをどの程度持てるのかは、少し気になっていたポイントでした。実際に入社してみると、1つ上の先輩方が優しく接してくださったので安心しました。 また、オフィスの同じフロアには、住友商事の複数のデジタル関連部門が集まっています。そこで働く新卒社員の方々に自分から声をかけ、一緒にランチへ行くなど、会社や部署の枠を越えて交流できました。IE社内に限らず、住友商事グループまで視野を広げて同世代とのつながりを持てることは、入社前には想像していませんでした。 交流の中では、互いの仕事や担当領域について話すこともあります。そうした会話を通じて、住友商事の方々がどのような視点で事業やデジタル活用を捉えているのかを知ることができます。一方で、私から技術的な考え方を伝えることもあり、それぞれの立場や専門性を生かした意見交換ができています。将来同じプロジェクトに関わる際も、こうした日頃の関係が連携のしやすさにつながると感じています。 「住友商事グループと近い距離で働く」という言葉を、入社前は主に仕事上の関係として捉えていました。実際には同じフロアで働き、日常的に会話できる環境があります。そのため、同じグループの仲間として働いていることをより実感できました。 3.3 案件外の活動を通じた学びと交流 IEには、担当案件以外にも、業務時間内の自己研鑽や、社員同士で交流するための活動があります。 私が実際に参加している学習活動には、次のようなものがあります。 勉強会 ：業務時間の10％を目安に自己研鑽へ充てる取り組みがあり、執筆時点では、私は先輩社員と一緒に統計の勉強をしています。疑問点を相談し、考え方を共有しながら学べることに、一人で勉強する場合にはない良さを感じています。 DSチームのLT会 ：DSチームのメンバーが最近学んだ技術や試したことを、短い発表形式で共有する会です。自分の担当案件だけを追っていると触れにくい技術も知ることができ、継続的なキャッチアップの機会になっています。 海外グループとの技術交流会 ：私は有志として、住友商事グループの海外拠点で働く方々と英語で技術情報を交換する会に参加しています。海外での技術活用や異なる考え方に触れられるだけでなく、実際に英語で技術について議論する経験にもなっています。これは将来、海外案件に参加するための良い練習だと感じており、積極的に参加しています。 このように、基礎をじっくり学ぶ機会、新しい技術を社内で共有する機会、海外の方々から異なる視点を得る機会など、案件外でも自分を高める機会がたくさんあります。こんなにたくさん学びの機会があるとは入社前は知りませんでした。 また、技術に関する活動だけでなく、部活動やシャッフルランチなど、社員同士の交流を目的とした取り組みもあります。仕事の性質上、少人数のチームで案件を進め、テレワークも利用できる環境では、担当案件が異なる社員との接点が少なくなることもあります。そのため、こうしたイベントが会話のきっかけとなり、案件や職種を越えて、社内にどのような経験や専門性を持つ人がいるのかを知ることができます。 入社前は、勉強会や社内活動を、それぞれ独立した制度のように捉えていました。しかし実際には、技術を学ぶ場であると同時に、普段は一緒に仕事をしない人とつながる入り口にもなっています。用意された機会を自分から活用することで、学べる範囲も、相談できる相手も国内外へ広げていけることが、入社して分かったIEの特徴の1つです。 4. まとめ 入社前の私は、IEに対して「住友商事グループの幅広い事業に関われる」「優秀な技術者と働ける」「新しい技術に挑戦できる」という印象を持っていました。入社して5か月が経った今、その印象は大きく変わっていません。一方で、実際にIEの一社員として働いたからこそ、それぞれの魅力をより具体的に理解できるようになりました。 分野横断の研修を経て、早い段階から案件に入り、新卒でも一人の技術者として意見を求められること。その一方で、メンターをはじめ、困ったときに相談できる方々がいること。住友商事のデジタル関連部門と同じフロアで働き、会社の枠を越えて日常的に交流できること。そして、案件外にも技術を学び、人とつながるための機会が用意されていること。これらは、入社前には十分に想像できていなかったIEの姿でした。 IEは私にとって、データサイエンスの専門性を深めるだけでなく、他職種やグループ内会社の方々と協力しながら、技術を企業価値につなげる経験を積める環境だと感じています。一方で、こうした環境を生かすためには、自分から学び、周囲に働きかける姿勢も必要です。入社からまだ5か月で、私自身も学ぶことばかりですが、これから1つずつ経験を積んでいきたいと思います。 本記事が、IEへの新卒入社や、商社グループでデータサイエンティストとして働くことに興味を持つ方にとって、少しでも参考になれば幸いです。 Insight Edgeでは、新卒採用に加えてインターンシップの募集も行っています。少しでも興味を持っていただけた方は、ぜひ 新卒採用、インターンシップ募集ページ をご覧ください。

はじめに さくらのナレッジ編集部の法林です。 2026年8月1日(土)に、さくらインターネットの大阪本社でもあるBlooming Campにおいて「きのこカンファレンス 2026 in 関西」が行われました。本記事ではこ […]

はじめに # 大まかな構成は把握していても、細かい実装には手が回らずぼんやりとしか理解してなかったので、勉強を兼ねてRAG（Retrieval-Augmented Generation）を実装してみました。 今回は、RAGの核となる「ベクトル化」「類似度検索」「コンテキスト注入」を理解することを目的に、フレームワークやVectorDBをあえて使わず、最小構成で動かしてみます。 これらは実運用ではライブラリやVectorDBに置き換える選択肢がありますが、まずは本質を素の形で体感します。 そのうえで、ミステリーというわかりやすい題材を使って、RAGの動作をイメージしやすい形で見ていきます。 本記事で使用している用語の定義 Instruction: 役割や振る舞いの指定 ドキュメント: 原文である文書のこと プロンプト: 質問や依頼文の原文 クエリ：指すモノはプロンプトと同じですが、検索に使用する質問を指す場合、呼び変えています チャンク: 原文をもとに分割された状態 コンテキスト: LLMに渡す背景情報 本記事で使用している図、小説 Geminiで生成したものを用いています。 技術スタック # node 26 Google AI Studio gemini-embedding-2（Embeddingモデル） gemini-3.5-flash-lite（テキスト出力モデル） typescript 7 @google/genai 2.17.1 --> Google AI Studio 無料枠でも十分に試せて、導入ハードルが低いことから、今回利用しました。 事前準備として Google AI Studio の無料枠を使ってAPI Keyを取得します。 無料枠はクレジットカード登録不要で試せます。 サンプルアプリ # まずRAGの基本構造を見えるようにするため、今回のサンプルではあえてフレームワークやVectorDBを使わずに、最小構成で動かしてみました。 このアプリでは、RAGの本質である「ドキュメントをどのように扱うか」「どこを類似検索するか」「どの情報をLLMに渡すか」を、最小限のコードで確認できます。 本記事で掲載しているコードは こちら で公開しています。 スペック # Instruction 空行で分割する。 起動後、ユーザーに選択を促し、選択した内容をLLMに渡すコンテキストの一部に含める。 ドキュメント 空行で分割する。 プロンプト 空行で分割する 起動後、ユーザーに選択を促し、選択した内容をLLMに渡すコンテキストの一部に含める。 類似度検索は、Top1のスコアを基準に相対評価で決定する。 処理フロー # 今回作成したアプリの処理フローは下図の通りです。 sequenceDiagram autonumber actor cli participant app as 今回のアプリ participant llm as Google AI Studio cli --> app: 起動 app -->> cli: Instructionの選択確認 cli --> app: Instruction選択 app --> llm: ドキュメントの組み込み llm -->> app: ベクトル化されたドキュメント app -->> cli: Promptの選択確認 cli --> app: Prompt選択 app --> llm: プロンプトの組み込み llm -->> app: ベクトル化されたプロンプト app --> app: コサイン類似度計算 app --> app: 類似度検索 app --> llm: 回答生成 llm -->> app: 回答 app -->> cli: 回答 ベクトル化（Embedding） # 自然言語や画像などを人が使うデータを、AIが理解できるように意味を表す数値のリスト（ベクトル）に変換する処理です。 LLMやEmbeddingモデルは、文字をトークン単位で処理し、学習を通じて言葉どうしの関係を扱います。 ただし、文章どうしの意味の近さを検索で直接比較するには、数値として扱える形にする必要があります。 たとえば「有休」と「有給休暇」のような近い意味の言葉を、近い位置に配置するのがEmbeddingです。 そこで、テキストをEmbeddingモデルを使って「意味の位置関係を表す数字のリスト」に変換します。これがベクトル化です。 具体例で考える（イメージ）たとえば言葉を「ジャンル」「フォーマット」などの軸（次元）で数値化してみます。 言葉 軸①：仕事っぽさ 軸②：休みっぽさ ベクトル（座標） 有給休暇 0.9 0.9 [0.9, 0.9] 有休 0.9 0.9 [0.9, 0.9] リモートワーク 0.8 0.2 [0.8, 0.2] ラーメン 0.0 0.0 [0.0, 0.0] ※Embeddingモデルは、この軸を膨大な数（今回は3072個）使って、複雑な言葉の意味を「数字のリスト」として表現しています。 ベクトル化することで、文字がまったく違っても「有給休暇」と「有休」はグラフ上で近い位置にあるということをAIが理解できるようになります。 const vectorizedDoc: number[][] = await embedAndVectorizedContents(LLM_MODEL_EMBEDDED, documents); async function embedContent(model: string, content: string): Promise<EmbedContentResponse> { // モデルに渡したcontentsが数値化されて返される return await ai.models.embedContent({ model, contents: content }); } async function embedAndVectorizedContent(model: string, content: string): Promise<number[]> { // モデルから返された値を後続のコサイン類似度算出で使いやすいように数値配列に変換 return extractValues(await embedContent(model, content)); } async function embedAndVectorizedContents(model: string, contents: string[]): Promise<number[][]> { const res = await Promise.all( contents.map(async (doc) => { return await embedAndVectorizedContent(model, doc); }), ); return res; } --> Gemini Embedding 2のクエリとドキュメント指定について 検索用途の場合、クエリとドキュメントを役割に応じた形式でEmbeddingすることが推奨されています。 たとえば、クエリは task: question answering | query: ... 、ドキュメントは title: ... | text: ... と付与します。 サンプルでは、ベクトル化とコサイン類似度の仕組みに焦点を絞るため、クエリとドキュメントを同じ形式でEmbeddingしています。 実運用では 公式ドキュメント に沿って用途別の形式を使うことで、検索精度の改善が期待できます。 コサイン類似度の考え方（Cosine Similarity） # 2つの文章（ベクトル）の「意味がどれくらい似ているか」を0〜1（または -1 〜1）の数値で判定すること。 テキストがすべて「数字のリスト（矢印）」になったので、プロンプトのベクトルと、ドキュメント側のベクトルの「向きの近さ」を計算できます。 なぜ「距離」ではなく「向き（角度）」なのか 距離で比べた場合： 長文の「有休についての詳しい説明」と、短文の「有休はいつ」というプロンプトは、文章の長さに対応するベクトルの大きさも含めて比べるため、「離れている」と判定される場合があります。 角度で比べた場合： 長さが違っても、テーマが同じなら矢印の向いている「方向」がほぼ一緒になります。 コサイン類似度は、ベクトルの大きさの影響を除き、向きだけを比べる計算です。 1.0に近ければ意味が近く、0.0に近ければ関係ないコンテキストと言えます。 function cosineSimilarity(v1: number[], v2: number[]): number { const dotProduct = v1.reduce((sum, a, idx) => sum + a * v2[idx], 0); const mag1 = Math.sqrt(v1.reduce((sum, a) => sum + a * a, 0)); const mag2 = Math.sqrt(v2.reduce((sum, b) => sum + b * b, 0)); if (!mag1 || !mag2) return 0; return dotProduct / (mag1 * mag2); } 類似度検索で関連情報を絞り込む（Vector Search） # プロンプトのベクトルとドキュメントのベクトルを「コサイン類似度」で比較し、関連度の高いテキストを抽出する処理です。 プロンプトに近しいドキュメントを使って回答生成するため、チャンク粒度によっては、複数のチャンクを扱う必要があります。 「単純にTop n固定で取得する」と、関係のない情報（ノイズ）までLLMに渡してしまい、ハルシネーション（誤情報）や精度の低下に繋がります。 今回は「Top 1のスコアに対する閾値を設けて、その範囲内のn件を取得する」方法でコンテキストを特定する方法を採りました。 これにより、**「関連する情報が複数ある時はまとめて取得し、関連情報が1つしかない時はムダなノイズを混ぜない」**制御ができました。 function selectRelevantContents( scoredContents: ScoredContent[], topN: number, relativeScoreMargin: number, ): ScoredContent[] { const topContents = [...scoredContents] .sort((a, b) => b.score - a.score) .slice(0, topN); // Top1のスコアから相対的にみて関連の深いドキュメントを抽出 const filteredContents = topContents .filter((item) => item.score >= topContents[0].score - relativeScoreMargin); return filteredContents; } 回答生成 # 抽出したテキストを「コンテキスト（背景情報）」としてプロンプトに埋め込み、LLMに回答させる処理です。 const prompt = ` 以下のInstructionおよびコンテキストに基づいて回答してください。 Instruction: ${instruction} コンテキスト（背景情報）: ${retrievedContext} 質問: ${query}`; // LLMにコンテキストと質問を投げて、回答を生成 const response = await ai.models.generateContent({ model: LLM_MODEL_GENERATED, contents: prompt, }); console.log(`【LLMの回答】:\n${response.text}`); ミステリーを使ってRAGの挙動を確認してみる # ここからは、サンプルアプリで解説した内容をミステリー小説を題材にして確認します。 RAGのポイントは「何を選ぶか」と「どの情報を渡すか」であり、ミステリーはこの検証に適した題材です。 ミステリー小説（ドキュメント） # 第1章：吹雪の夜 標高1,500メートルに位置する観測所「雪山荘」。12月24日夜、猛烈な吹雪により館は完全な孤立状態となった。当時館内にいたのは、館主の神楽坂、助手の有馬、研究員の黒田、家政婦の白石の4名のみである。 第2章：開かずの密室 翌朝8時、敷地内の鐘楼2階で神楽坂が遺体となって発見された。現場の扉は内側から重厚なボルトで施錠されており、窓もすべて内側から木枠が打ち付けられていた。室内に鍵はなく、神楽坂のポケットに入っていた1本のマスターキーが唯一の鍵だった。 第3章：証言とアリバイ 事件当夜の午前0時（推定死亡時刻）、全員の行動ログが残されている。有馬は1階の無線室で外部との交信を試みており、その通信記録はログサーバーに刻まれていた。家政婦の白石は食堂でずっと明日の朝食の仕込みをしており、防犯カメラにその姿が映っていた。一方、黒田は「自分の部屋で寝ていた」と主張するが、彼を証明する客観的な証拠は何もない。 第4章：現場に残された違和感 鐘楼2階の窓枠には、極めて細い「ピアノ線」の摩擦痕と、わずかな「氷の破片」が残されていた。また、鐘楼の外壁を伝う外排水管には、上から吊り下げられたような擦れ傷が存在していた。 第5章：決定的な証拠 警察の鑑識により、外排水管の擦れ傷から黒田のコートの繊維が検出された。また、黒田の自室のゴミ箱からは、細かく切断された大量のピアノ線の端切れと、外からの吹雪で削られた氷を固めるために使われた保温ボトルの残痕が発見された。これにより、黒田が氷で作った重りとピアノ線、排水管を利用し、屋外から窓の木枠越しに内側のボルトを閉めて密室を作り上げたトリックと、彼が犯人であることが確定した。 探偵の設定（Instruction） # 探偵1人目 探偵の検埼索斗 口調が軽い感じの探偵です。 探偵2人目 ロンドン出身の調査ジャーナリストのEleanor Reed 「Case noted. Moving on.」が決まり文句。 3人目 新米刑事の小室慎一 推理はまだまだだけど、好感の持てるキャラクターです。 実践：質問と回答 # 同じミステリーでも、渡すコンテキストの数や、Instructionの違いによって回答の質や方向性が変わります。 ここでは、その変化を具体例で確認します。 1. 単一コンテキストを使う必要がある質問 # コンテキストを使って回答できるか検証します。 Instruction: 探偵の検埼索斗 質問: 怪しい人物は LLMの回答とコンテキスト利用ログ 実行時、どのように数値化され、どのチャンクを選択したのか見えるように debug info として参考掲載しています。 やあ、検埼索斗だ。ちょいと今回の事件のログを洗わせてもらったぜ。 推理を進めると、状況はこうだな。 まず、有馬は1階の無線室で外部と交信していて、その通信記録がしっかりログに残ってる。お次は家政婦の白石さん、彼女は食堂で朝食の仕込みをしていて、防犯カメラにバッチリその姿が映っていた。 さて、問題はもう一人の黒田クンさ。「自分の部屋で寝てた」なんて主張してるけど、それを裏付ける客観的な証拠は――ゼロ、ナシ、何もなし、と。 つまり、現時点で**アリバイがない人物は黒田**だな。いやはや、怪しい影がプンプンするじゃねえか。 --- debug info --- embedding model: gemini-embedding-2 generated model: gemini-3.5-flash-lite retrieval: topN=2, top1 score margin=0.05 instruction: resources/novel.inspection.txt document: C:\...\developer-site-article-examples\rag-sample\resources\novel.context.txt prompt: C:\...\developer-site-article-examples\rag-sample\resources\novel.prompt.txt query: アリバイがない人物は誰ですか？ chunk scores: 1. 第3章：証言とアリバイ: score=0.7098 selected 2. 第1章：吹雪の夜: score=0.6258 excluded 3. 第5章：決定的な証拠: score=0.6219 excluded 4. 第4章：現場に残された違和感: score=0.5941 excluded 5. 第2章：開かずの密室: score=0.5929 excluded アリバイのない「黒田」をコンテキストから導き出して、しっかり回答してくれました。 2. 複数コンテキストを使う必要がある質問 # 関連するコンテキストを使って回答できるか検証します。 Instruction: 探偵の検埼索斗 質問: 密室トリックを解き明かす（伏線が存在する） LLMの回答とコンテキスト利用ログ やあ、検埼索斗だ。ちょいと軽い感じに見えるかもしれないが、事件の推理にかけては任せてくれよな。 さて、今回の「開かずの密室」のからくりさっきまでじっくり洗い出してみたんだけどさ、なかなかよくできたトリックだったわけよ。じゃあ、証拠に基づいてサクッと解説してやるよ。 ヒントと答えをまとめると、ポイントは**「氷」「ピアノ線」「外排水管」**の3つだ。 1. **氷の重り** 外からの吹雪で削られた氷を固めて「重り」を作ったんだ。これがトリックのキモになる部分ね。 2. **ピアノ線** 黒田の部屋のゴミ箱から、細かく切断された大量のピアノ線の端切れが見つかっている。こいつが遠隔操作の糸代わりってわけだ。 3. **外排水管と窓の木枠** 外排水管からは黒田のコートの繊維がバッチリ検出されてる。犯人は屋外から窓の木枠越しにピアノ線と氷の重りを使って、内側のボルトを操作したのさ。 つまりどういうことか？ 犯人は、外からピアノ線と氷で作った重りを使って巧妙に内側のボルトを閉め、完璧な密室を作り上げたってわけ。ちなみに、使った氷の重りは時間が経てば勝手に溶けて証拠隠滅できるって寸法よ。いやはや、頭は使うもんだよねぇ。 ま、そういうわけで、今回の事件もスッキリ解決って感じだな！ --- debug info --- embedding model: gemini-embedding-2 generated model: gemini-3.5-flash-lite retrieval: topN=2, top1 score margin=0.05 instruction: resources/novel.inspection.txt document: C:\...\developer-site-article-examples\rag-sample\resources\novel.context.txt prompt: C:\...\developer-site-article-examples\rag-sample\resources\novel.prompt.txt query: 密室はどのように作られましたか？仕掛けのヒントを教えてください。 chunk scores: 1. 第5章：決定的な証拠: score=0.7352 selected 2. 第2章：開かずの密室: score=0.7212 selected 3. 第4章：現場に残された違和感: score=0.6732 excluded 4. 第3章：証言とアリバイ: score=0.6551 excluded 5. 第1章：吹雪の夜: score=0.6432 excluded 関連性が高いとして導出された2, 5章の内容をもとに回答が返ってきました。 使い古されたようなトリックですが、しっかり回答してくれました。 3. コンテキストの存在しない質問 # コンテキストが存在しない質問をして、ハルシネーションの発生を検証します。 Instruction: 探偵の検埼索斗 質問: 犯人の動機は（情報が一切ない ＝ RAGのガードレール検証） LLMの回答とコンテキスト利用ログ やあ、検埼索斗だ。軽そうに見えて頭のキレは抜群って評判の、あの探偵さ。 さて、今回の事件、なかなか厄介な「開かずの密室」だな。鐘楼の2階で神楽坂さんが遺体で見つかって、扉も窓も内側からがっちり施錠されていた。部屋には鍵がなくて、神楽坂さんのポケットにあったマスターキーが唯一の鍵だったってわけだ。 ……で、君からの質問は「犯人が神楽坂さんを殺害した『動機』は何ですか？」だな。 ふむ。証拠（コンテキスト）をよーく読んでみたんだけどさ……。 実はこの提供された情報の中には、**犯人がなぜ神楽坂さんを殺害したのかという「動機」については一言も書かれていない**んだよね。 わかるのは、現場が標高1,500メートルの孤立した「雪山荘」で、容疑者が助手の有馬、研究員の黒田、家政婦の白石の3人に絞られているってことと、密室のトリックの状況証拠くらいだ。 動機についてのピースがまだ揃ってない。これじゃあ、いくら名探偵の俺でも推理のしようがないってわけ！ もう少し事件の背景や人間関係がわかる証拠を持ってきてくれよ。そしたらこの華麗な頭脳で、犯人の下心まで丸裸にしてあげるからさ！ --- debug info --- embedding model: gemini-embedding-2 generated model: gemini-3.5-flash-lite retrieval: topN=2, top1 score margin=0.05 instruction: resources/novel.inspection.txt document: C:\...\developer-site-article-examples\rag-sample\resources\novel.context.txt prompt: C:\...\developer-site-article-examples\rag-sample\resources\novel.prompt.txt query: 犯人が神楽坂さんを殺害した『動機』は何ですか？ chunk scores: 1. 第2章：開かずの密室: score=0.7569 selected 2. 第1章：吹雪の夜: score=0.7171 selected 3. 第5章：決定的な証拠: score=0.6835 excluded 4. 第3章：証言とアリバイ: score=0.6819 excluded 5. 第4章：現場に残された違和感: score=0.6435 excluded 今回の小説には「動機」を書いていないため、分からないと回答していますね。 ハルシネーションが防げたように見えますが、これは「証拠以外から推測しないよう指定したInstruction」が効いているのではないかと思われます。 RAGは関連性の低いチャンクを取得する可能性もあるため、根拠のない回答を完全には防げません。 実運用では最低スコアの検索結果棄却や、根拠不足時の回答方針も考慮する必要がありそうです。 コンテキストに関する文章を外して再検証 LLMに渡すコンテキストから、コンテキストを読むように言及する記述を除去してハルシネーションが発生するか検証します。 LLMの回答とコンテキスト利用ログ ふむ……事件の真相に迫る重要な質問だな。 だが、提示されたデータ（コンテキスト）を隅々まで検証したが、神楽坂が殺害された具体的な**『動機』**に関する記述はどこにも見当たらなかった。 分かるのは以下の客観的事実だけだ： * 犯行現場は完全な密室（内側からのボルト施錠と木枠の打ち付け）。 * 被害者である神楽坂のポケットから発見されたマスターキーが唯一の鍵。 * 容疑者は館内にいた有馬、黒田、白石の3名に絞られている。 動機を暴くには、彼らの人間関係や過去の秘密、あるいは遺留品のさらなる調査が必要不可欠だな。……まだ見えていないピースを探すとするか。 --- debug info --- embedding model: gemini-embedding-2 generated model: gemini-3.5-flash-lite retrieval: topN=2, top1 score margin=0.05 instruction: resources/novel.inspection.txt document: C:\...\developer-site-article-examples\rag-sample\resources\novel.context.txt prompt: C:\...\developer-site-article-examples\rag-sample\resources\novel.prompt.txt query: 犯人が神楽坂さんを殺害した『動機』は何ですか？ chunk scores: 1. 第2章：開かずの密室: score=0.7569 selected 2. 第1章：吹雪の夜: score=0.7171 selected 3. 第5章：決定的な証拠: score=0.6835 excluded 4. 第3章：証言とアリバイ: score=0.6819 excluded 5. 第4章：現場に残された違和感: score=0.6435 excluded 今回はInstructionおよび共通プロンプトからコンテキスト参照の指示を外した状態で複数回実行しても、動機を創作する回答は発生しませんでした。 モデルが、与えられた情報に動機がないことを認識して回答を保留したと考えられます。 今回確認した範囲では発生しなかっただけであり、ハルシネーションが発生しないことを保証できるわけではありません。 4. 同じ条件で再度質問してみる # 同じInstructionおよび質問を指定した挙動を確認してみます。 Instruction: 探偵の検埼索斗 質問: 密室トリックを解き明かす（伏線が存在する） LLMの回答とコンテキスト利用ログ やあ、検埼索斗だ。ちょいと軽い感じに見えるかもしれないが、謎解きにかけては一級品だぜ。それじゃあ、今回の事件の「開かずの密室」のからくりをサクッと暴いていこうか。 証拠品を並べて論理的に組み立てれば、答えは一つしかないのさ。仕掛けのヒントは以下の通りだ。 1. **氷の重りとピアノ線** 外からの吹雪で削られた氷を固めて「重り」を作り、それに「ピアノ線」を結びつけて使っていたのさ。細かく切断されたピアノ線の端切れや、保温ボトルの残痕が黒田の部屋からしっかり見つかっている。 2. **外排水管と窓の木枠** 外排水管には黒田のコートの繊維がしっかり残っていた。犯人は屋外から、この排水管を利用して窓の木枠越しにアプローチしたんだ。 3. **トリックの全貌** つまりこういうことだ。犯人は**「氷で作った重りとピアノ線、そして外排水管」**を巧妙に利用して、屋外にいながら窓の木枠越しに内側のボルトを閉めたのさ。時間が経てば氷の重りは自然に溶けて証拠も消える……はずが、鑑識の執念と俺の推理の前には隠し通せなかったってわけだ。 完璧なロジックだろ？ 事件の真相は、いつだって証拠のなかに眠っているのさ。さて、次の依頼はどこかな？ --- debug info --- embedding model: gemini-embedding-2 generated model: gemini-3.5-flash-lite retrieval: topN=2, top1 score margin=0.05 instruction: resources/novel.inspection.txt document: C:\...\developer-site-article-examples\rag-sample\resources\novel.context.txt prompt: C:\...\developer-site-article-examples\rag-sample\resources\novel.prompt.txt query: 密室はどのように作られましたか？仕掛けのヒントを教えてください。 chunk scores: 1. 第5章：決定的な証拠: score=0.7352 selected 2. 第2章：開かずの密室: score=0.7212 selected 3. 第4章：現場に残された違和感: score=0.6732 excluded 4. 第3章：証言とアリバイ: score=0.6551 excluded 5. 第1章：吹雪の夜: score=0.6432 excluded 口調は変わってますが、内容は概ね同じでした。 ただし、この回答に含まれている「氷の重りは自然に溶けて証拠も消える」は、実は小説本文にはない補足です。 根拠に基づく回答を厳密に求める場合は、事実と推測を区別する必要があります。 これも厳密にいえばハルシネーションに該当するのでしょうね。 5. Instructionによる変化を確認 # 今回のサンプルアプリではドキュメントとは別にInstructionを作成し、検索したコンテキストとあわせてLLMに渡しているので、これによる変化を確認してみます。 ロンドン出身の調査ジャーナリストのEleanor Reed LLMの回答とコンテキスト利用ログ Based on the evidence provided in the case files, here is the factual verification regarding the construction of the locked room, clearly separated from any speculation. ### Facts (Based on Evidence) * **The Mechanism:** The suspect, Kuroda, utilized an ice-weight, piano wire, and an exterior drainage pipe to manipulate and secure the heavy interior bolt from the outside through the window frame. * **Physical Evidence (Drainage Pipe):** Forensic analysis by the police detected fibers from Kuroda's coat on the abrasions of the exterior drainage pipe, placing him in direct physical contact with the mechanism used. * **Physical Evidence (Kuroda's Room):** A search of Kuroda's personal waste bin yielded a large quantity of finely cut piano wire ends, alongside residue from a thermal bottle. The latter was used to compact ice, which served as the temporary weight for the trick before melting away. * **Resulting Illusion:** Through this setup, the room—featuring a door bolted from the inside and windows secured by nailed wooden frames—was successfully converted into a closed room ("locked room") from the outside. ### Speculation * Any hypotheses regarding Kuroda's exact motive, his precise psychological state during the execution of the crime, or the timeline of events prior to the discovery of Kagurazaka's body at 8:00 AM remain outside the direct scope of the current forensic findings. Case noted. Moving on. --- debug info --- embedding model: gemini-embedding-2 generated model: gemini-3.5-flash-lite retrieval: topN=2, top1 score margin=0.05 instruction: resources/novel.inspection.txt document: C:\...\developer-site-article-examples\rag-sample\resources\novel.context.txt prompt: C:\...\developer-site-article-examples\rag-sample\resources\novel.prompt.txt query: 密室はどのように作られましたか？仕掛けのヒントを教えてください。 chunk scores: 1. 第5章：決定的な証拠: score=0.7352 selected 2. 第2章：開かずの密室: score=0.7212 selected 3. 第4章：現場に残された違和感: score=0.6732 excluded 4. 第3章：証言とアリバイ: score=0.6551 excluded 5. 第1章：吹雪の夜: score=0.6432 excluded Instruction通り、英語で整然と回答してくれました。 新米刑事の小室慎一 LLMの回答とコンテキスト利用ログ あ、あの……！事件のことで頭がいっぱいで、つい考え込んじゃっていました。僕、新米の小室慎一って言います。どうぞよろしくお願いしますね。 密室の謎についてですね……。みなさんすごく深刻に考えていらっしゃいますけど、僕、黒田さんとお話ししていて、なんだかすごく心が温かくなったんです。あんなに優しくて、丁寧にお茶を入れてくださる方が、冷たいトリックなんて使えるわけがないって、どうしても思ってしまうんですよね。 それに、黒田さんって本当に気配り上手で、僕のくだらない質問にも優しく耳を傾けてくださるんです。「寒いから風邪をひかないようにね」なんて声をかけてもらっちゃって……あ、すみません、つい脱線しちゃいました！ ええと、仕掛けのヒントですよね？ 鑑識の方たちの話だと、外の排水管のあたりに擦れ傷があって、黒田さんのコートの繊維がちょっとだけ付いていたみたいなんです。それに、お部屋のゴミ箱からピアノ線の細かい切れ端とか、なんだか冷たそうな保温ボトルが見つかったとか……。 でも、きっとこれって、黒田さんが音楽の趣味でピアノ線を大切に使っていただけですし、寒い日に温かい飲み物を持ち歩いていた優しい証拠だと思うんです。 外から窓の木枠越しに、その……氷の重りとピアノ線を使って、内側のボルトを器用にカチャッと閉めちゃったのかなぁなんて、ちょっとだけ推理してみたりして……。 うーん、でもやっぱり、あんなに穏やかな黒田さんが犯人だなんて、僕にはどうしても信じられないんです。もう少しだけ、みんなであたたかいコーヒーでも飲みながら、ゆっくりお話しして確かめてみませんか？ きっと何か、別の温かい真相があるはずですよ。 --- debug info --- embedding model: gemini-embedding-2 generated model: gemini-3.5-flash-lite retrieval: topN=2, top1 score margin=0.05 instruction: resources/novel.inspection.txt document: C:\...\developer-site-article-examples\rag-sample\resources\novel.context.txt prompt: C:\...\developer-site-article-examples\rag-sample\resources\novel.prompt.txt query: 密室はどのように作られましたか？仕掛けのヒントを教えてください。 chunk scores: 1. 第5章：決定的な証拠: score=0.7352 selected 2. 第2章：開かずの密室: score=0.7212 selected 3. 第4章：現場に残された違和感: score=0.6732 excluded 4. 第3章：証言とアリバイ: score=0.6551 excluded 5. 第1章：吹雪の夜: score=0.6432 excluded Instruction通り、推理が迷走しました。 まとめ # 自前でRAGを組むことで、以下の原理が明確になりました。 RAGはLLMに知識を記憶させているのではなく、「関連するコンテキストを動的に作って渡しているだけ」。 今回は最小構成でRAGの仕組みを理解することに集中しましたが、実運用ではPostgreSQLのpgvectorやQdrantなどの仕組みを使うことで、より大規模なデータに対応できます。 実装が複雑化しても基本原理は変わらない。 今回は「本質を見えやすくする」ことを目的に、最小構成で作ってみました。 実際にシステムに落とし込むときには、適切なライブラリやストレージを選ぶことが重要です。 まずは素のコードでブラックボックスを排除し、RAGの基本構造を体感してみてはいかがでしょうか。