AIチャットボットの作り方｜生成AI＋RAG・ノーコード・受託開発の方式選定と実装手順

AIチャットボットの作り方は、生成AIとRAG（検索拡張生成）を組み合わせて自作する、Difyのようなノーコード基盤で組む、開発会社に受託開発を依頼する、という3方式に集約されます。どれを選ぶかで費用は数万円から数百万円まで、期間は数日から数カ月まで変わるため、コードを書き始める前に方式選定を確定させることが手戻りを防ぐ近道です。本記事では、シナリオ型から生成AI型までの仕組みの違い、LLM・ベクトルDB・オーケストレーション層からなるRAG構成、3方式の比較基準と実装ステップ、精度が出ない失敗パターンまでを実装者の視点で解説します。AIチャットボットという技術そのものの整理はAIチャットボットの定義と導入判断を解説した記事を先に読むと、本記事の方式選定を判断しやすくなります。

まとめ：AIチャットボットの作り方は方式選定とデータ整備で決まる

結論から示します。社内FAQや定型問い合わせの範囲なら、Dify（2026年7月時点で1.16系）のようなノーコード基盤に社内文書を読み込ませる構成が、コードを書かずに数日で動く現実解です。プログラミングできる担当者がいるなら、LLM APIとベクトルDBを組み合わせた生成AI＋RAGの自作で、検索や回答の挙動を細部まで制御できます。

一方で、基幹システムとの双方向連携、誤答が許されない顧客対応、回答根拠の提示義務がある業務では、自作もノーコードも精度保証の壁に当たります。この条件に1つでも該当するなら、要件定義と評価設計まで含めて受託開発に出す方が総コストは下がります。

方式がどれであっても、成否を分けるのはコードではなくAIに読ませるデータの整備です。文書の構造化とチャンク設計に工数の半分を割く。これが本記事全体を貫く前提です。

AIチャットボットの仕組み全体像：シナリオ型・機械学習型・生成AI＋RAG型の違い

作り方を選ぶ前に、AIチャットボットの応答方式を3系統に分けて確定させます。方式ごとに得意な問い合わせと構築コストがまったく違うため、ここが曖昧なままツール比較を始めると評価軸がぶれます。

シナリオ型と機械学習型の動作原理：ルール分岐・意図分類と自作の適否

シナリオ型は、あらかじめ用意した選択肢と回答を木構造でたどらせる方式です。自由入力の解釈をしないため誤答がほぼ起きず、営業時間の案内や手続きの振り分けのような、答えを固定できる問い合わせに向きます。作る作業は会話フローの設計が中心で、プログラミングはほとんど必要ありません。

機械学習型は、入力文の意図（インテント）を分類器で判定し、対応する回答やアクションを返す方式です。オープンソースではRasa（3.6系）が代表格で、意図分類と対話管理を学習データから構築できます。ただし学習データの作成と保守に継続的な工数がかかるため、生成AIの普及後、新規の自作でこの方式を第一候補にする理由は薄れました。特徴と使いどころはオープンソースAIチャットボットRasaの特徴と使い方を解説した記事で詳しく扱っています。

生成AI型がRAGを必要とする理由：LLM単体の限界とハルシネーション対策

生成AI型は、GPTやClaudeのようなLLM（大規模言語モデル）に回答文を生成させる方式です。自由な質問に自然な文章で答えられる半面、LLM単体では自社の就業規則や製品仕様を知りません。そのまま社内問い合わせに使うと、事実と異なる回答をもっともらしく返すハルシネーションが避けられなくなります。

この弱点を補う仕組みがRAG（Retrieval-Augmented Generation：検索拡張生成）です。質問を受けるたびに自社文書から関連箇所を検索し、その内容をプロンプトに添えてLLMに渡すことで、回答の根拠を自社データに固定します。モデル自体を再学習するファインチューニングと違い、文書を差し替えるだけで知識を更新できるため、2026年時点の社内チャットボット構築ではRAGが標準構成になっています。

生成AI＋RAGチャットボットの技術構成：LLM・ベクトルDB・検索の設計

生成AI＋RAG型を作る場合、構成要素はLLM API・埋め込みモデルとベクトルDB・両者をつなぐオーケストレーション層の3つに分かれます。それぞれの選定観点を順に見ます。

LLM APIの選定観点：精度・料金・データの取り扱い条件の比較軸

LLM APIは、回答品質・料金・データの取り扱い条件の3軸で選びます。料金は入出力トークン量に対する従量課金が基本で、同じ提供元でも上位モデルと軽量モデルでは単価が1桁違う水準です。FAQ回答のような定型処理は軽量モデルで足りることが多いため、まず軽量モデルで正答率を実測し、不足した場合だけ上位モデルへ切り替える順序が費用を抑えます。

業務利用では、入力データがモデルの学習に使われない契約条件かを必ず確認します。主要プロバイダーはAPI経由の入力を既定では学習に使わない方針を公表していますが（2026年7月時点）、時点で変わる情報のため契約時の原文確認が必須です。AWS内で完結させたい場合はAmazon Bedrockが候補で、複数のモデルを共通APIで切り替えられます。会話履歴を保持する実装の具体例はBedrock Converse APIで会話を維持するチャットボットの作成方法として公開しています。

埋め込みモデルとベクトルDBの構成：pgvector・FAISS・マネージド型の使い分け

RAGの検索側は、文書と質問を埋め込みモデルで数値ベクトルに変換し、ベクトル同士の近さで関連文書を探す仕組みです。日本語の検索精度は埋め込みモデルの性能に直結するため、多言語対応をうたうモデルでも、自社の日本語文書で検索一致を実測してから採用を決めます。

ベクトルDBは規模と運用体制で選びます。

• pgvector（0.8系・2026年7月時点）：PostgreSQLの拡張。既存DBに相乗りでき、社内文書規模なら十分実用
• FAISS：Meta製の検索ライブラリ。サーバー不要で試作に向くが、永続化と更新の仕組みは自前実装
• マネージド型（PineconeやVertex AIのベクトル検索など）：運用を外部に任せ、大規模・高可用性が要件のとき

社内FAQのように検索対象が数千〜数万件の範囲なら、PostgreSQLにpgvectorを足す構成で足ります。専用のベクトルDBは、対象が百万件規模に達するか更新頻度が高い場合に検討すれば遅くありません。

オーケストレーション層の役割：LangChainとDifyが担う検索と生成の接続

質問の受け付け、ベクトル検索、プロンプト組み立て、LLM呼び出し、会話履歴の管理という一連の流れを制御するのがオーケストレーション層です。これを素のコードで書くと定型処理が積み上がります。LangChain（コアライブラリ1.4系・2026年7月時点）はこの定型部分を部品化したフレームワークで、検索器やモデルの差し替えを小さな変更で行えます。

コードを書かずに同じ構成を組めるのが、DifyのようなLLMアプリ開発基盤です。ナレッジ登録・チャットフロー設計・公開までをGUIで完結でき、RAGとエージェントを1つの管理画面で扱えます。フレームワークは自由度、GUI基盤は構築速度に振れているため、次章の方式選定はこの層をどう持つかの選択とほぼ同義です。

自作・ノーコード・受託開発の方式比較：費用と体制で決める選定基準

ここまでの技術要素を踏まえて、作り方の3方式を比較します。判断材料は機能の有無ではなく、費用の内訳と作った後に誰が面倒を見るかという体制です。

3方式の費用・期間・保守の比較表と読み方：どこにコストが乗るか

3方式の違いは、初期費用・稼働までの期間・保守体制・カスタマイズ性の4点に表れます。

費用の乗る場所が方式ごとに違う点に注意が必要です。自作はAPI利用料そのものより、設計・実装・評価にかかる人件費が大半を占めます。ノーコードは月額費用が低い代わりに、ナレッジ整備の内部工数が消えずに残ります。受託開発は初期費用こそ最大ですが、要件定義と評価まで委託でき、社内の技術要員を拘束しない構造です。

ノーコード型が成立する条件：Dify 1.16系で作る社内ボットの範囲

ノーコード基盤で成立するのは、回答の根拠が社内文書に収まり、外部システムとの連携が浅い用途です。総務・情シスへの定型質問、製品マニュアルの照会、社内規程の検索が典型で、Difyならナレッジに文書を登録し、フローを画面上で組むだけで公開まで到達します。セルフホストできるOSS版があるため、データを社外に出しにくい組織でも採用しやすい構成です。社内チャットボットをDifyで組む実例はDifyで社内チャットボットを作成する手順を紹介した記事にまとめています。

逆に、基盤が提供する部品の外に出る要件が出た時点で、ノーコードの優位は消えます。独自の権限制御、複雑な業務ロジック、既存システムへの書き込みがその典型です。この場合は基盤の中で無理に作り込まず、方式ごと切り替える判断が妥当です。

受託開発を選ぶ判断基準：基幹システム連携と精度要件が譲れない場合

受託開発を選ぶ基準は3つあります。第1に、在庫・受注・顧客管理など基幹システムと双方向に連携し、チャットから業務処理まで実行する要件があること。第2に、誤答率や根拠提示の水準が数値で決まっており、評価設計そのものに専門性が要ること。第3に、社内にAI実装の経験者がおらず、内製の学習コストが外注費を上回ること。いずれかに該当するなら、最初から開発会社と要件を詰める方が早く安く着地します。

一創では、LLM・RAG構成の設計からナレッジ整備、公開後の精度改善までを一貫して請け負うAIチャットボット開発サービスを提供しています。方式選定の段階から相談できるため、自作かノーコードかで迷っている状態でも、要件を整理する入口として使えます。

生成AI＋RAGチャットボットを作る実装ステップ：要件定義から評価・運用まで

方式を生成AI＋RAGに決めた場合の実装工程を、順序どおりに示します。工程の前半（要件とデータ）に時間を割くほど、後半の精度改善が短くなります。

要件定義と回答範囲の設計：対象業務・想定質問・エスカレーション先の確定

構築は次の順序で進めます。

1. 対象業務と回答範囲の確定（何に答え、何に答えないか）
2. 想定質問の洗い出しと優先度付け（過去の問い合わせログから抽出）
3. 答えられない場合のエスカレーション先の設計（有人窓口・フォーム）
4. ナレッジ整備とチャンク設計
5. 検索・生成パイプラインの構築
6. 評価・テストと公開後の改善

最初の3項目が要件定義です。回答範囲を決めずに作り始めると、評価段階で「どこまで答えられれば合格か」の基準がなく、精度改善が終わらなくなります。答えない領域を先に確定し、範囲外の質問には定型文で有人窓口へ誘導する設計にしておくと、公開後の誤答リスクと利用者の不満を同時に抑えられます。

ナレッジ整備とチャンク設計：RAGの回答精度を左右する前処理の実務

RAGの回答品質は、検索で正しい文書片を取り出せるかでほぼ決まります。元文書の整備では、1文書1トピックへの分割、見出し構造の明確化、表や画像内テキストの文字起こしを先に済ませます。PDFのレイアウト崩れやExcelの結合セルは検索精度を直接下げるため、読み込ませる前の変換こそが実務の中心作業です。

チャンク設計は、文書を検索単位に切る工程です。目安として数百字〜1,000字程度の意味のまとまりで区切り、章や節の見出しをチャンク側に含めて文脈を保持します。チャンクが大きすぎると無関係な文が混ざって生成がぶれ、小さすぎると文脈が切れて根拠不足になります。固定長で機械的に切らず、文書構造の境界に合わせる。それだけで検索一致率は目に見えて変わります。

回答評価とテストの進め方：正答率・出典提示・禁止応答の3点検証

公開前の評価は、正答率・出典提示・禁止応答の3点で行います。想定質問から50〜100問の評価セットを作り、期待回答と突き合わせて正答率を測るのが基本形です。合格ラインは用途によりますが、社内FAQなら「頻出質問で9割、全体で8割」のように業務側と数値で合意しておくと、改善の終了条件が明確になります。

出典提示は、回答がどの文書のどの箇所に基づくかを文書名やリンクで示す仕組みです。利用者が真偽を確かめられるため、多少の誤答があっても業務事故につながりにくくなります。禁止応答のテストでは、人事評価や法的判断のような答えてはいけない領域の質問を意図的に投げ、回答を拒否して窓口へ誘導するかの確認が中心です。公開後は回答ログを週次でレビューし、誤答の原因が検索漏れか生成のぶれかを切り分けて、ナレッジとプロンプトに反映し続けます。

RAGの精度が出ない失敗パターンと自作を見送るべき場面の判断

最後に、実装で最も相談の多い「精度が出ない」原因の切り分けと、そもそも自作すべきでない場面を整理します。この章は競合の入門記事が扱わない、運用まで見据えた判断の話です。

精度が伸びない典型原因：文書の構造崩れ・チャンク過大・検索の不一致

精度が出ない原因は、LLMの性能よりデータと検索の側にあることが大半です。頻出するのは次の系統です。

• 文書の構造崩れ：PDF抽出でレイアウトが崩れ、表が意味を失った文字列になっている
• チャンク過大：数千字単位で切っており、質問と無関係な文が生成を引っ張る
• 検索の不一致：質問の言い回しと文書の用語が食い違い、関連文書が上位に来ない
• 鮮度切れ：旧版の規程が残り、新旧の矛盾した文書が同時に根拠として検索される

切り分けの手順は決まっています。まず検索結果だけを取り出し、正しい文書片が上位に来ているかを確認する。来ていなければ埋め込み・チャンク・用語のそろえ方の問題で、来ているのに回答が誤るならプロンプトと生成側の問題です。モデルの変更は最後の手段に回し、先にデータを疑う方が改善は速く進みます。

自作を見送るべき場面の言い切り：兼任1名の体制と誤答が許されない業務

自作を見送るべき場面を言い切ります。第1に、開発も運用も兼任1名に依存する体制です。RAGは公開後のログレビューとナレッジ更新が続く、運用前提の仕組みです。担当者の異動で止まる構成は、作った時点で負債になります。第2に、誤答がそのまま損害になる業務、例えば契約条件の回答や金額提示です。生成AIの誤答率をゼロにはできない以上、この領域は人の確認を挟むフローにするか、シナリオ型で答えを固定する設計に倒すべきです。

逆に、社内FAQ・マニュアル照会・問い合わせの一次受付のように、誤答しても訂正が利き答えの根拠が文書にある用途は、小さく自作して確かめる価値があります。対象業務を1つに絞って2週間で試作し、正答率の実測値を見てから拡張可否を決める。この順序を守れば、方式選定に失敗しても損失は試作分で済みます。

よくある質問

AIチャットボットの作り方について、検索で聞かれることの多い質問に答えます。

AIチャットボットは無料で作れますか？

試作段階なら、OSSと無料枠の範囲でほぼ無料で作れます。DifyのOSS版をセルフホストし、LLM APIの低額枠を使えば、動くものは数千円以内でも用意できます。ただし業務利用では、APIの従量課金・サーバー費・ナレッジ整備と運用の人件費が継続して発生する点に注意が必要です。「無料で作れるか」より「月いくらで運用し続けられるか」で判断する方が実態に合います。

プログラミングの知識がなくても作れますか？

社内文書に基づくFAQ用途なら、DifyのようなGUI基盤で作れます。ナレッジ登録もフロー設計も、画面操作だけで完結する仕組みです。ただし精度が出ないときの原因切り分け、たとえばチャンク設計や検索の調整には仕組みの理解が求められます。技術者が全くいない組織では、初期構築と評価設計だけ外部に依頼し、日々の運用を内製する分担が現実的です。

RAGとファインチューニングはどちらを選ぶべきですか？

社内知識に答えさせる目的ならRAGを選びます。文書の差し替えだけで知識を更新でき、回答の根拠提示もできるからです。ファインチューニングは知識の追加ではなく、口調・出力形式・分類基準のような挙動の調整に向く手法で、両者は排他ではありません。まずRAGで作り、出力形式への不満が残る場合に限って追加を検討する順序が定石です。

AIチャットボットの開発期間はどのくらいかかりますか？

ノーコード基盤なら数日〜2週間、生成AI＋RAGの自作なら試作までで2週間〜1カ月、業務公開に耐える評価と改善を含めて1〜2カ月が目安です。受託開発で基幹システム連携を含む場合は、要件定義からで1〜3カ月以上を見込みます。期間を左右する最大の要因は実装ではなくナレッジ整備で、文書が部門ごとに散在している組織ほど前工程に時間がかかります。

社内データを外部のLLM APIに送っても安全ですか？

主要プロバイダーは、API経由の入力を既定ではモデル学習に使わない方針を公表しています（2026年7月時点）。そのうえで機密区分に応じて、個人情報のマスキング、社外送信可否の文書区分、契約済みクラウド内で完結する構成（Amazon Bedrockなど）、セルフホストLLMの採用という順に対策を重ねます。方針は変わりうるため、契約条件の原文確認だけは省略しないでください。

関連記事

• AIチャットボットとは？生成AI型と従来型の違い・仕組みと導入判断を解説：本記事の親にあたる定義ハブ。種類の整理と導入判断を先に確認したい方に
• チャットボット導入の進め方とは？手順・費用相場・シナリオ型とAI型の選び方：発注者視点の導入手順と費用相場。作る前の社内合意づくりに