メインコンテンツにスキップ
株式会社ゼットリンカー - Next.js システム開発専門
AI開発

社内マニュアルをAIで検索可能にする|Next.js × ベクトル検索の始め方

Conclusion

社内マニュアル検索はFAQ数十件から始められる。Next.js × ベクトルDBの最小構成なら数週間で動くものが作れます。

「あのマニュアルどこだっけ?」を解決するベクトル検索の仕組みを、非エンジニアにも分かるように解説。Next.js 16 × OpenAI Embeddings × ベクトルDBで社内FAQ検索を最小構成で始める方法をお伝えします。

9分で読めます
Next.jsNext.jsAI駆動開発中小企業社内検索ベクトル検索

「あのマニュアル、どこにあったっけ?」——この一言に覚えがある方は少なくないのではないかと思います。ファイルサーバーの奥深く、あるいは誰かのデスクトップに。社内マニュアルや手順書は存在するのに、必要なときに見つからない。結果として、隣の席の人に聞く、過去のチャットを遡る、あるいは自分の記憶を頼りに作業する。こうした「探す時間」は1回あたりは小さくても、部門全体で積み重なると無視できない量になります。この記事では、AIを使った「意味で探せる検索」——ベクトル検索を、Next.js 16のアプリケーションに組み込む方法を、技術者でない方にも分かるようにお伝えします。

従来のキーワード検索とベクトル検索は何が違うのか?

社内マニュアルの検索というと、多くの方がイメージするのは「キーワードを入れて、一致するページが出てくる」という仕組みだと思います。いわゆる全文検索です。これはこれで有用なのですが、一つ大きな弱点があります。検索する側が「正しい言葉」を知っていないと、目的の文書にたどり着けないという点です。

たとえば、「出張の申請方法」を知りたいとします。しかし社内マニュアルのタイトルが「旅費精算規程」だった場合、「出張 申請」で検索しても引っかからないことがあります。書いた人と探す人の「使う言葉」が違うだけで、情報にたどり着けなくなる。これがキーワード検索の構造的な限界です。

ベクトル検索は、この問題を「意味」で乗り越えようとする仕組みです。ここで、図書館の司書に例えてみます。

優秀な司書は、来館者が「海外出張のときの経費の出し方を知りたい」と言ったら、「旅費精算規程」の棚に案内してくれます。言葉がぴったり一致していなくても、「意味が近い」ことを理解しているからです。ベクトル検索は、この「意味が近い」をコンピュータに判断させる技術です。

具体的には、文章を「数百個の数字の並び(ベクトル)」に変換します。意味が近い文章同士は、この数字の並びも近くなるように設計されています。「出張の申請方法」と「旅費精算規程」は、言葉は違っても意味が近いため、ベクトルの距離が近くなり、検索結果に出てくるようになります。

キーワード検索が得意なこと、ベクトル検索が得意なこと

誤解のないように補足すると、ベクトル検索がすべての場面でキーワード検索より優れているわけではありません。

  • キーワード検索が向いている場面:型番、社員番号、固有名詞など「その言葉そのもの」で探したいとき
  • ベクトル検索が向いている場面:「こういうことが知りたい」と曖昧な意図で探したいとき

実務では両方を組み合わせる「ハイブリッド検索」が現実的な構成になることが多いです。

キーワード検索とベクトル検索の違いを『旅費精算規程』の具体例で対比し、FAQから手順書、全マニュアルへと対象を段階的に広げる3段階の導入ステップを示す図解。

Next.js × OpenAI Embeddings × ベクトルDBでどう構成するのか?

技術的な構成の全体像をお伝えします。非エンジニアの方は「こういうパーツで成り立っているのか」という理解で十分です。

3つの主要パーツ

  1. Next.js 16(App Router) —— ユーザーが検索窓に質問を入力し、結果を表示するWebアプリケーション本体
  2. OpenAI Embeddings API —— 文章を「数字の並び(ベクトル)」に変換するAPI。先ほどの司書の「意味を理解する力」にあたる部分
  3. ベクトルDB —— 変換されたベクトルを保存・検索するデータベース。Pinecone、Supabase pgvector、Qdrantなど複数の選択肢がある

データの流れ

事前準備の段階と、ユーザーが検索する段階の2つに分かれます。

事前準備(データの登録)

社内マニュアル(テキスト)
  ↓ チャンクに分割(後述)
  ↓ OpenAI Embeddings API でベクトル化
  ↓ ベクトルDBに保存

検索時

ユーザーの質問
  ↓ OpenAI Embeddings API でベクトル化
  ↓ ベクトルDBで「近いベクトル」を検索
  ↓ 該当するマニュアルの文章を取得
  ↓ Next.js の画面に結果を表示

この仕組みは「RAG(Retrieval-Augmented Generation)」と呼ばれるパターンの基本形です。RAGを先ほどの司書の例えに戻すと、司書が本棚から関連する資料を引っ張り出して、利用者の質問に合わせて要約してくれるようなイメージです。

Next.js 16 で組む利点

Next.js 16 の App Router では、Server Components を使ってサーバー側でベクトルDBへの問い合わせを処理できます。API キーをブラウザに露出させずに済むため、セキュリティ面でも合理的な構成です。Route Handlers を使えば、検索APIのエンドポイントを app/api/search/route.ts のようなファイル1つで定義できます。

// app/api/search/route.ts のイメージ(簡略化)
import { NextResponse } from 'next/server';

export async function POST(request: Request) {
  const { query } = await request.json();

  // 1. ユーザーの質問をベクトル化
  const embedding = await openai.embeddings.create({
    model: 'text-embedding-3-small',
    input: query,
  });

  // 2. ベクトルDBで類似検索
  const results = await vectorDB.query({
    vector: embedding.data[0].embedding,
    topK: 5,
  });

  // 3. 結果を返す
  return NextResponse.json({ results });
}

上のコードは概念を伝えるための簡略版です。実際のプロダクションコードでは、エラーハンドリングや認証チェックなどが加わります。

ここで一度お知らせ

15分のカジュアル相談

事例・要件未定でもOK/営業はしません/所要時間15分

カジュアルに相談する

まず社内FAQだけで試すのが現実的な第一歩

「社内マニュアルをすべてベクトル化して検索可能にする」——と聞くと、大がかりなプロジェクトを想像するかもしれません。しかし、最初から全文書を対象にする必要はありません。むしろ、小さく始めることを強くお勧めします

なぜFAQから始めるのか?

  • データの整理が不要:FAQは「質問と回答」の対になっているため、チャンク分割(後述)を考える必要がほとんどない
  • 精度の検証がしやすい:「この質問をしたら、このFAQが出てくるべき」という正解が明確
  • データ量が少ない:FAQ数十件であれば、ベクトルDBの無料枠で十分に収まるケースが多い
  • 社内の理解を得やすい:「まずFAQだけ」と限定することで、稟議も通りやすくなる

最小構成の技術スタック

パーツ選択肢の例備考
フロントエンド+APINext.js 16(App Router)Server Components + Route Handlers
ベクトル化OpenAI text-embedding-3-small低コスト・高品質のバランスが良い
ベクトルDBSupabase pgvector / Pinecone無料枠があるものが始めやすい
ホスティングVercel / Firebase HostingNext.js との相性が良い

この構成であれば、FAQデータの準備さえできれば、数週間で検索画面の試作品(MVP)が動く状態にできると考えています。私たちゼットリンカーでも、小規模なプロジェクトからまず動くものを作り、そこから対象文書を広げていくアプローチを取っています。

FAQで手応えを掴んでから広げる

FAQで「意味で探せる検索」の手応えを社内で体感できたら、対象を段階的に広げていきます。

  1. FAQ(数十件)→ まずここで精度と使い勝手を検証
  2. よく使う手順書(数十〜百件)→ 問い合わせが多い文書から優先的に
  3. 全マニュアル(数百件以上)→ チャンク分割とメタデータ設計が本格的に必要

この段階を踏むことで、「全部まとめて作ったけど精度が低くて使われない」というリスクを避けられます。

精度を上げるために何を工夫するのか?

ベクトル検索は「入れたら終わり」ではありません。精度を実用レベルまで引き上げるには、いくつかの工夫が必要です。ここでは、技術的な詳細に立ち入りすぎず、「何をやるのか」と「なぜやるのか」に絞ってお伝えします。

チャンク分割:文書を適切な大きさに切る

長いマニュアル文書をそのまま1本のベクトルにすると、検索精度が下がります。先ほどの司書の例えで言えば、「この本のどこかに書いてあります」と本1冊を渡されるのと、「この章のこのページです」と開いて見せてくれるのでは、使いやすさが違います。

文書を数百文字〜千文字程度の「チャンク(断片)」に分割し、それぞれをベクトル化するのが一般的な方法です。分割の粒度は文書の性質によって調整が必要で、ここが精度に大きく影響します。

メタデータ付与:「誰向けの、いつの情報か」を添える

ベクトル化した文書に、以下のようなメタデータ(付加情報)をセットで保存しておくと、検索結果の絞り込みや表示に活用できます。

  • 文書名・カテゴリ:「経理マニュアル」「人事関連」など
  • 部署・対象者:「全社共通」「営業部向け」など
  • 最終更新日:古い情報と新しい情報を区別する
  • ソースファイルのパス:原本にたどり着けるようにする

「経理部の人が検索したら経理関連の文書を優先的に出す」といった制御が、メタデータによって可能になります。

フィードバックループ:使いながら育てる

検索システムは、リリースした瞬間が完成ではありません。実際に社内で使ってもらい、「この検索で欲しい結果が出なかった」というフィードバックを集めて改善していくサイクルが重要です。

具体的には、以下のような仕組みを検索画面に組み込んでおくと改善が回りやすくなります。

  • 検索結果に対する「役に立った/立たなかった」ボタン
  • 検索クエリのログ収集(どんな言葉で検索されているかの把握)
  • ヒットしなかった検索クエリの定期的なレビュー

私たちが関わったプロジェクトの範囲でも、初回リリース時の精度と、フィードバックを数回反映した後の精度には明確な差が出る傾向があります。「作って終わり」ではなく「使いながら育てる」前提で計画を立てるのが現実的です。

なお、検索ではなく「対話」で答えを合成させたいケース——たとえば就業規則のように複数条文にまたがる質問に一つの回答で答えたい場合は、社内規定を参照して回答するチャットボットのような対話型の設計が向いています。検索UIと対話UI、どちらが適するかは問い合わせの性質によって変わります。

まとめ

社内マニュアル検索の課題は「言葉が一致しないと見つからない」という構造にある。ベクトル検索は意味で文書を探せるため、この問題に対する有効な手段です。全文書を一気に対象にする必要はありません。まずFAQ数十件から小さく始め、手応えを確認してから広げてください。Next.js 16 × ベクトルDBの構成であれば、最小限の投資で「意味で探せる検索」を社内に導入できます。


本記事は Next.js 16.x 時点の情報です。最終更新:2026-04-11

次のステップ

「自社のマニュアル検索をどう改善すればいいか分からない」という段階でも問題ありません。まずは15分のカジュアル相談で、現状の文書管理の課題を整理するところから始められます。要件が固まっていなくても構いません。営業目的のお電話はいたしません。

15分のカジュアル相談を予約する →

本記事は Next.js 16.x 時点の情報です

最終更新:2026年4月13日

Share this article

15分のカジュアル相談

事例・要件未定でもOK/営業はしません/所要時間15分

カジュアルに相談する

次に読む記事

ALL ARTICLES →
01 / 03AI開発

AIが社内規定を参照して回答するチャットボットをNext.jsで実装する|情シスのための最小構成

結論、社内規定チャットボットはNext.js 16 + Firebase + ベクトル検索で数週間規模から内製できます。就業規則や経費規定への同じ質問を減らしたい情シス担当者向けに、設計パターンと費用感、失敗しやすいポイントを整理しました。

·10
02 / 03AI開発

Cursor と Claude Code をどう使い分けているか|中小企業向け Next.js 受託の現場

Cursor と Claude Code を比較する記事は増えていますが、中小企業向け Next.js 受託の現場では「どちらか一方」ではなく「役割分担」で運用しています。社内での具体的な使い分け、Next.js 16 系での実例、予算感、AI に任せすぎないラインの引き方を整理します。

·9
03 / 03Next.js

中小企業のNext.jsフルスクラッチで、Server Actions のセキュリティを現実的に守る|Data Access Layer の置き方

Next.js 16 系の App Router で Server Actions を使う以上、middleware だけの認証では足りません。Data Access Layer (DAL) に認可ロジックを集約し、Zod 検証と DTO 返却を最低ラインに置く。中小企業向けフルスクラッチで「やりすぎず、抜けも作らない」セキュリティ設計を、受託の現場感で整理します。

·9

プライバシーポリシー

株式会社ゼットリンカー(以下、「当社」といいます。)は、お客様の個人情報の重要性を認識し、 その保護の徹底を図るため、以下のプライバシーポリシー(以下、「本ポリシー」といいます。)を定めます。

1. 個人情報の定義

本ポリシーにおいて「個人情報」とは、生存する個人に関する情報であって、 当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの、 及び他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを指します。

2. 個人情報の収集

当社は、お客様が当社のサービスをご利用になる際、お客様の個人情報を収集することがあります。収集する個人情報は以下の通りです:

  • 氏名
  • メールアドレス
  • 電話番号
  • 会社名・組織名
  • 住所
  • その他当社が定める入力フォームにお客様が入力する情報

3. 個人情報の利用目的

当社は、お客様からご提供いただいた個人情報を、以下の目的で利用します:

  • お客様への連絡やサービスの提供
  • お客様からのお問い合わせへの対応
  • 当社サービスの改善や新サービスの開発
  • メールマガジンの配信(お客様の同意がある場合)
  • 契約や法令等に基づく権利の行使や義務の履行
  • その他、上記利用目的に付随する目的

4. 個人情報の第三者提供

当社は、以下の場合を除き、お客様の同意なく個人情報を第三者に提供することはありません:

  • 法令に基づく場合
  • 人の生命、身体または財産の保護のために必要がある場合であって、本人の同意を得ることが困難である場合
  • 公衆衛生の向上または児童の健全な育成の推進のために特に必要がある場合
  • 国の機関もしくは地方公共団体またはその委託を受けた者が法令の定める事務を遂行することに対して協力する必要がある場合

5. 個人情報の管理

当社は、お客様の個人情報を正確かつ最新の状態に保ち、個人情報への不正アクセス、 個人情報の紛失、破損、改ざん及び漏洩などを防止するため、 セキュリティシステムの維持・管理体制の整備等の必要な措置を講じ、安全対策を実施し個人情報の厳重な管理を行います。

6. 個人情報の開示・訂正・削除

お客様は、当社に対してご自身の個人情報の開示を求めることができます。 また、開示の結果、個人情報の内容が事実でないことが判明した場合には、 速やかに訂正または削除に応じます。

7. 導入事例の公開について

当社は、お客様から依頼いただいたプロジェクトを導入事例として記事にさせていただく場合があります。導入事例として公開する場合は、以下の点に配慮いたします:

  • 機密情報や個人情報は公開いたしません
  • 社名を公開する場合は、公開内容について事前にお客様に確認いただきます
  • 社名を非公開とする場合でも、お客様のご要望に応じて公開内容を確認いただくことが可能です

8. Cookie(クッキー)の使用について

当社のウェブサイトでは、お客様により良いサービスを提供するため、Cookie を使用することがあります。 Cookie により個人を識別できる情報を収集することはありません。 お客様はブラウザの設定により Cookie の受信を拒否することができます。

9. SSL(Secure Socket Layer)について

当社のウェブサイトはSSLに対応しており、ウェブブラウザとウェブサーバーとの通信を暗号化しています。 お客様が入力する個人情報は自動的に暗号化されて送受信されるため、 万が一、第三者が傍受した場合でも内容を解読することは困難です。

10. プライバシーポリシーの変更

当社は、必要に応じて、本ポリシーの内容を変更することがあります。 変更後のプライバシーポリシーについては、当社ウェブサイトに掲載したときから効力を生じるものとします。

11. お問い合わせ

本ポリシーに関するお問い合わせは、以下の窓口までお願いいたします。

株式会社ゼットリンカー

〒160-0023

東京都新宿区西新宿3丁目3番13号西新宿水間ビル2F

代表取締役: 金原隆利

お問い合わせ先: info@zetlinker.com

制定日:2024年1月1日

最終改訂日:2026/7/20

利用規約

この利用規約(以下、「本規約」といいます。)は、株式会社ゼットリンカー(以下、「当社」といいます。)が 提供するウェブサイトおよびサービス(以下、「本サービス」といいます。)の利用条件を定めるものです。 お客様は、本規約に同意した上で、本サービスをご利用ください。

第1条(適用)

1. 本規約は、お客様と当社との間の本サービスの利用に関わる一切の関係に適用されるものとします。

2. 当社は本サービスに関し、本規約のほか、ご利用にあたってのルール等、各種の定め(以下、「個別規定」といいます。)を することがあります。これら個別規定はその名称のいかんに関わらず、本規約の一部を構成するものとします。

3. 本規約の規定と個別規定の規定が異なる場合は、個別規定において特段の定めなき限り、個別規定の規定が優先されるものとします。

第2条(定義)

本規約において使用する以下の用語は、各々以下に定める意味を有するものとします。

  • 「利用契約」とは、本規約を契約条件として当社とお客様との間で締結される、本サービスの利用契約
  • 「知的財産権」とは、著作権、特許権、実用新案権、意匠権、商標権その他の知的財産権(それらの権利を取得し、またはそれらの権利につき登録等を出願する権利を含みます。)
  • 「投稿データ」とは、お客様が本サービスを利用して投稿その他送信するコンテンツ(文章、画像、動画その他のデータを含みますがこれらに限りません。)

第3条(本サービスの提供)

1. お客様は、本規約に同意の上、当社の定める方法によって利用登録を申請し、当社がこれを承認することによって、本サービスを利用することができるようになります。

2. 当社は、お客様に以下のいずれかの事由があると判断した場合、利用登録の申請を承認しないことがあり、その理由については一切の開示義務を負わないものとします。

  • 利用登録の申請に際して虚偽の事項を届け出た場合
  • 本規約に違反したことがある者からの申請である場合
  • その他、当社が利用登録を相当でないと判断した場合

第4条(ユーザーIDおよびパスワードの管理)

1. お客様は、自己の責任において、本サービスのユーザーIDおよびパスワードを適切に管理するものとします。

2. お客様は、いかなる場合にも、ユーザーIDおよびパスワードを第三者に譲渡または貸与し、もしくは第三者と共用することはできません。

3. 当社は、ユーザーIDとパスワードの組み合わせが登録情報と一致してログインされた場合には、そのユーザーIDを登録しているお客様自身による利用とみなします。

第5条(禁止事項)

お客様は、本サービスの利用にあたり、以下の行為をしてはなりません。

  • 法令または公序良俗に違反する行為
  • 犯罪行為に関連する行為
  • 本サービスの内容等、本サービスに含まれる著作権、商標権ほか知的財産権を侵害する行為
  • 当社、ほかのお客様、またはその他第三者のサーバーまたはネットワークの機能を破壊したり、妨害したりする行為
  • 本サービスによって得られた情報を商業的に利用する行為
  • 当社のサービスの運営を妨害するおそれのある行為
  • 不正アクセスをし、またはこれを試みる行為
  • 他のお客様に関する個人情報等を収集または蓄積する行為
  • 不正な目的を持って本サービスを利用する行為
  • 本サービスの他のお客様またはその他の第三者に不利益、損害、不快感を与える行為
  • 他のお客様に成りすます行為
  • 当社が許諾しない本サービス上での宣伝、広告、勧誘、または営業行為
  • 面識のない異性との出会いを目的とした行為
  • 当社のサービスに関連して、反社会的勢力に対して直接または間接に利益を供与する行為
  • その他、当社が不適切と判断する行為

制定日:2024年1月1日

最終改訂日:2026/7/20