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

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

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

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

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

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

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

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

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

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

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

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

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 });
}

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

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

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

なぜFAQから始めるのか？

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

最小構成の技術スタック

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

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

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

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

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

導入にかかる費用感はどのくらいか？

当社の開発費用は1時間11,000円（税込）が基準です。FAQ数十件の最小構成であれば、ランニングコスト（Embeddings API + ベクトルDB）は月数百〜数千円程度に収まることが多く、初期構築の開発費用が投資の中心になります。

具体的な開発費用は対象文書の量・既存システムとの連携範囲によって変わるため、ヒアリング後に要件定義・開発・テストの各工程を見積もり、概算をご案内します。お客様が開発工数をご自身で見積もる必要はありません。

ランニングコストの内訳

FAQ数十件の最小構成であれば、ランニングコストが業務に大きな負担になることは少なく、費用の中心は初期構築（チャンク分割の設計、メタデータ設計、検索UIの実装）にかかる開発工数です。 対象を「全マニュアル」まで広げる場合は、チャンク分割・メタデータ設計の工数が増えるため、まずFAQで小さく始めて費用対効果を確認してから範囲を広げる進め方が現実的です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なお、検索ではなく「対話」で答えを合成させたいケース——たとえば就業規則のように複数条文にまたがる質問に一つの回答で答えたい場合は、社内規定を参照して回答するチャットボットのような対話型の設計が向いています。検索UIと対話UI、どちらが適するかは問い合わせの性質によって変わります。また、対象が社内文書ではなく顧客とのやり取りの場合は、時系列の重みや個人情報保護など考慮点が変わります。詳しくは顧客対応履歴をNext.js×AIで検索できる仕組みの設計で扱っています。

まとめ

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

本記事は Next.js 16.x 時点の情報です。最終更新：2026-04-11／2026-09-11 費用感セクションを追加

次のステップ

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

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