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

AIが社内規定を参照して回答する「規定チャットボット」は、Next.js + Firebase + ベクトル検索の最小構成で数週間規模から着手できます。総務・人事への同じ質問の繰り返しを減らしたい情シス担当者向けの設計指針です。

こんな状況ではありませんか？

• 就業規則や経費精算のルールを聞かれるたびに、総務担当が同じ説明を繰り返している
• 規定集はPDFやWordで社内共有フォルダに置かれているだけで、誰も読まずに毎回担当者に聞く
• 「AIチャットボットを作りたい」と思っても、既製ツールは月額数万円からで、自社の規定更新にどう追従させるか見えない

この記事で分かること

• 社内規定チャットボットが「検索」ではなく「対話」であるべき理由
• Next.js 16 + Firebase + ベクトル検索での最小構成の作り方
• Vercel AI SDK 6のAgent機能を使った実装のポイント
• 費用感・導入期間・運用でつまずきやすい失敗パターン

情シス担当者の方へ——規定集の管理と問い合わせ対応を一人、あるいは兼務で抱えている状況を想定し、既製SaaSに頼らずNext.jsで内製する場合の設計を整理します。

なぜ「検索」ではなく「対話」型で作るべきか？

社内規定は条件分岐が多く、キーワード検索だけでは該当条文にたどり着けないことが多いためです。

たとえば「育休から復帰したときの時短勤務は何時まで申請できるか」という質問は、就業規則の「育児休業」の章と「勤務時間」の章の両方にまたがっていることがあります。単純なキーワード検索では、質問文に含まれない条文（例：時短勤務の申請期限を定めた別条項）を拾えません。

これは、以前この連載で紹介した社内マニュアルのベクトル検索とは目的が異なります。マニュアル検索は「該当ページを探し出す」体験に向いていますが、規定チャットボットは「複数条文を横断して、質問に対する一つの答えを合成して返す」体験が求められます。検索エンジン型のUIではなく、対話型のUIを選ぶべき理由はここにあります。

もう一つの理由は、規定は改定されるという点です。就業規則も経費精算ルールも、年に数回は更新が入ります。対話型のチャットボットであれば、参照元のドキュメントを差し替えるだけで回答内容が自動的に更新されます。FAQページを手動で書き換え続ける運用と比べて、更新の手間が大きく減ります。

典型的な問い合わせパターンをどう分解するか？

「勤怠・休暇」「経費・稟議」「福利厚生」の3カテゴリで全体の大半を占めるのが一般的な傾向です。

規定チャットボットを設計する前に、実際にどんな問い合わせが総務・人事に来ているかを棚卸しすることが最初のステップです。過去のメール・チャットのやり取りを1〜2週間分でも見返すと、次のようなパターンに分類できます。

• 勤怠・休暇系：有給休暇の繰越上限、時短勤務の申請期限、慶弔休暇の対象範囲
• 経費・稟議系：交通費の精算ルール、出張時の宿泊費上限、稟議の承認ライン
• 福利厚生系：健康診断の対象者、資格取得補助の申請方法、社宅制度の条件

このパターン分解が甘いまま実装に入ると、「なんでも答えられる汎用チャットボット」を目指してスコープが膨らみがちです。最初のMVPは、問い合わせ件数が多い1〜2カテゴリに絞り、そのカテゴリの規定文書だけをベクトル化して回答精度を高めるほうが現実的です。

Next.jsでどう設計するか？最小構成と拡張ステップ

Next.js 16のRoute HandlersとFirestore、Vercel AI SDKを組み合わせれば、規定チャットボットの最小構成は3つのレイヤーで完結します。

構成は次の3層に分けて考えます。

1. ドキュメント取り込み層：就業規則・経費規定などのPDF/Wordファイルをテキスト抽出し、章・条文単位でチャンク分割してFirestoreに保存する
2. 検索層（Retrieval）：ユーザーの質問をベクトル化し、関連する条文チャンクを類似度検索で取得する
3. 回答生成層（Generation）：取得した条文チャンクを根拠として、LLMに「この条文の範囲内で答える」よう指示して回答を生成する

コード例（Route Handlerの骨子、30行程度）：

// app/api/rules-chat/route.ts
import { streamText, embed } from 'ai';
import { anthropic } from '@ai-sdk/anthropic';
import { getFirestore } from 'firebase-admin/firestore';

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

  // 1. 質問をベクトル化
  const { embedding } = await embed({
    model: 'text-embedding-3-small',
    value: question,
  });

  // 2. Firestoreから類似条文を検索（findNearest）
  const db = getFirestore();
  const snapshot = await db
    .collection('ruleChunks')
    .findNearest('embedding', embedding, { limit: 5, distanceMeasure: 'COSINE' })
    .get();
  const context = snapshot.docs.map((d) => d.data().text).join('\n---\n');

  // 3. 根拠条文の範囲内で回答を生成
  const result = streamText({
    model: anthropic('claude-sonnet-4-5'),
    system: `以下の社内規定の抜粋のみを根拠に回答してください。根拠が無い場合は「規定に記載がないため総務にご確認ください」と答えてください。\n\n${context}`,
    prompt: question,
  });

  return result.toTextStreamResponse();
}

Firestoreはネイティブでベクトル検索（findNearest）に対応しているため、別途ベクトルDBを立てずにFirebaseだけで最小構成を組めるのがこの構成の利点です。既にFirebase Authenticationで社員認証を組んでいるプロジェクトであれば、会員認証の仕組みをそのまま流用して「社員だけが使えるチャットボット」に絞り込めます。

拡張ステップとしては、まず1〜2カテゴリの規定でMVPを動かし、社内テストで「根拠なく答えてしまうケース」を洗い出してプロンプトを調整し、そのあとで対象規定を広げていく順序が現実的です。

いくらで作れるか？費用感の目安

最小構成であれば、開発工数は数週間、月々の運用コストは数千円〜数万円が目安です。

内訳の考え方は次のとおりです。

既製のAIチャットボットSaaSは月額1万円〜5万円程度からのプランが多く、社内規定という特化用途であれば内製のほうがランニングコストを抑えられるケースがあります。ただし、これは「開発を内製・外注どちらで行うか」の初期投資とのトレードオフであり、問い合わせ件数が少ない組織では既製SaaSのほうが総コストで有利な場合もあります。台数（問い合わせ件数）と改定頻度が費用対効果を左右する変数です。また、LLM APIコストは選ぶモデルのティアに大きく左右されるため、検証段階と本番でモデルを切り替える設計を含めて、GPT-5.6のティア構成を踏まえたPoC設計の考え方が判断材料になります。

失敗しやすいパターンと回避策

実装を進める中でつまずきやすいのが次のようなケースです。

• 根拠のない回答を生成してしまう（ハルシネーション）：プロンプトで「根拠条文の範囲内でのみ回答する」ことを明示し、根拠が見つからない場合は「総務に確認してください」と答えさせるフォールバックを必ず入れる
• 規定改定への追従を忘れる：ドキュメント差し替えの運用フローを決めずに公開すると、古い規定のまま回答し続けるリスクがある。改定時のチャンク再生成を運用手順に組み込む
• 全社規定を一度に対象にしてスコープが膨らむ：最初から全カテゴリを対象にすると、精度検証の負荷が跳ね上がる。問い合わせ頻度の高いカテゴリから段階的に広げる
• 認証を後回しにする：社内規定は機微な情報を含むため、Firebase Authenticationなどで「誰が使えるか」を先に設計しておく。Next.jsのセキュリティ設計にある入力検証の考え方は、チャットの入力欄にもそのまま当てはまります

AI駆動開発で何が変わるか？

Vercel AI SDK 6のAgent抽象化により、モデル・指示・ツールを一度定義すれば使い回せるようになり、実装の見通しが立てやすくなりました。

2025年12月にリリースされたVercel AI SDK 6では、Agentという抽象化が導入され、モデル・システムプロンプト・使用ツールをひとまとめに定義して、アプリ全体で再利用できるようになりました。また、Anthropic Claude向けにプログラム的なツール呼び出しがサポートされ、中間的な検索結果をコンテキストに含めずに処理できるため、トークン消費とコストを抑えやすくなっています（出典: Vercel AI SDK 6 公式ブログ）。

Claude Codeでこの構成を組む場合、Route Handlerの骨組みやFirestoreのクエリ部分はAIに下書きさせやすい領域です。一方で「どの条文を根拠として扱うか」「ハルシネーションをどう防ぐプロンプトにするか」といった業務ロジックの判断は、実際の問い合わせパターンを見ている人間側の設計判断が必要です。この線引きを曖昧にしたままAIに丸ごと任せると、もっともらしいが実際の規定と食い違う回答を返すチャットボットになりかねません。

ゼットリンカーでの進め方

私たちが受託で関わった小規模プロジェクトの範囲では、まず問い合わせ件数の多いカテゴリを1つに絞ってMVPを作り、数週間の短いサイクルで実際の質問パターンをテストしながらプロンプトと根拠条文の紐付けを調整する、という進め方をとることが多いです。全社規定を一度に対象にするのではなく、小さく動かして精度を確認してから対象を広げるほうが、手戻りの少ない進め方だと考えています。

よくある質問

Q. 既存のAIチャットボットSaaSと内製、どちらを選ぶべきですか？

問い合わせ件数が少なく規定改定も稀であれば、既製SaaSの方が総コストで有利な場合があります。逆に、社内規定という特化領域で回答精度を継続的に調整したい場合や、既にFirebaseなど自社基盤がある場合は、内製の方が長期的な柔軟性で優位になりやすいという傾向があります。

Q. 規定が改定されたら、チャットボットの回答もすぐ反映されますか？

対話型の構成では、参照元のドキュメントを差し替えてベクトルを再生成すれば回答内容が更新されます。ただし自動追従ではなく、改定のたびにドキュメント差し替えの運用フローを回す必要があります。

Q. 誤った回答をしてしまうリスクはどう抑えますか？

プロンプトで「根拠条文の範囲内でのみ回答する」ことを明示し、根拠が見つからない質問には「総務にご確認ください」と答えるフォールバックを組み込むことが基本です。加えて、公開前に想定される質問パターンで検証しておくことが欠かせません。

Q. 小規模な組織でも導入する意味はありますか？

社員数が少なくても、同じ質問が繰り返されている状況であれば効果はあります。ただし問い合わせ件数自体が少ない組織では、開発コストに見合わない場合もあるため、まず1〜2週間分の問い合わせを棚卸しして件数を把握してから判断するのが現実的です。

まとめ

社内規定チャットボットは、検索ではなく対話型として設計し、根拠条文の範囲内で答えるフォールバック設計を最初から組み込むことが要になります。全社規定を一度に対象にせず、問い合わせ件数の多いカテゴリから小さく始めるのが、手戻りの少ない進め方です。規定の管理と問い合わせ対応に負荷を感じている情シス担当者の方は、まず自社の問い合わせパターンの棚卸しから始めてみてください。

自社の問い合わせパターンを整理してから相談したいという方には、15分のカジュアル相談（事例・要件未定でもOK／営業はしません）をご用意しています。要件が固まっている方は、ゼットリンカーの無料相談フォームからご相談ください。