こんにちは。わさおです。
今回はRAGを用いて企業専用のAIエージェントを構築するための技術要素と手順について解説します。なので、個
人向けというよりは自社でAIエージェントを構築したい大企業向けになっておりますので、ご注意ください。
AIエージェントはまだ技術的に成熟していないため、是非この記事を参考にしていただければと思います。
なお、下記の公式LINEで最新のAI情報を発信しています!!興味がある方は登録してみてください!!
目次
1.AIエージェント構築のための技術要素
1. データの収集・前処理
1-1. データソースの特定・接続
・社内ドキュメント(PDF、Word、Excelなど)
・ナレッジベース(FAQ、Wiki、Confluence、SharePoint など)
・チャットログ(Slack、Teams、メール履歴 など)
・DBや業務システム(ERP、CRM、社内ポータルなど)
これらの複数データソースに対して、適切なAPI連携やバッチ処理等でアクセスし、定期的・継続的にデータを取得します。
1-2. ETL(Extract, Transform, Load)とクリーニング
・形式の統一:ファイルフォーマットの変換、テキスト抽出(OCR含む)
・前処理:ノイズ除去、重複排除、メタデータ付与、機密情報マスクなど
・セキュリティ・アクセスコントロール:機密度に応じてマスク/削除、権限管理
2. 検索基盤の構築(ベクターストア/全文検索)
2-1. 埋め込みモデル(Embedding Model)
RAGでは、ドキュメントや文章を「ベクター表現(埋め込み)」に変換し、高次元空間で類似検索を行います。
オープンソースのSentence-BERT系のモデルや、APIベースのOpenAI Embeddings(text-embedding-ada-002など)がよく利用されます。日本語に強いモデル(例えば日本語特化のモデル)も検討が必要です。
テキスト、画像、音声のような非構造化データをベクトルに変換する処理のこと。
2-2. ベクターデータベース/セマンティック検索エンジン
埋め込み結果を保存し、高速に類似文章の検索を行うためのデータベースが必要です。
主な選択肢としては、Pinecone、Weaviate、Milvus、Qdrant、Chromなど。
企業のセキュリティ要件やオンプレミス環境の場合、Elasticsearch + 近傍検索プラグイン(kNN searchなど)や Milvusのオンプレ版を検討することもあります。
検索者の意図や背景、文脈を考えて検索結果を出す仕組みのこと。検索エンジンが素早くWebサイトの内容を把握するために構造化データマークアップという専用コードが用いられている。
3. Large Language Model(LLM)の選定・利用方法
3-1. API利用か自前ホスティングか
・API利用:OpenAI(GPT-3.5 / GPT-4)、Azure OpenAI、Google PaLMなどを利用すると構築が容易です。
・自前ホスティング:機密情報やオンプレ要件がある場合、LLMを自社サーバー上やクラウドの専用環境でホスティングする選択肢もあります。Llama 2や日本語特化モデル(e.g. rinna社のモデルなど)を利用するケースなど。
3-2. Prompt Engineering / Fine-tuning
・RAG構成の場合、プロンプトエンジニアリングでドキュメントから取得したテキストをうまく要約・加工してLLMに渡す設計が重要です。
・LLMを直接微調整(Fine-tuning)するか、あるいはLoRA等の軽量学習を行うかは、要件・コスト・機密性に依存します。
4. RAGパイプラインの設計
RAGは大きく以下のステップで構成されます。
1.ユーザーのクエリ受け取り
2.Retriever:ベクターストアから関連する文書(または文書断片)を類似検索でピックアップ
3.Generator:LLMに対して、取得した関連文書情報をコンテキストとして渡し、最適な回答を生成
具体的には以下のような実装要素が考えられます。
1.エンベッディング:ユーザーのクエリと文書を同じ埋め込みモデルでベクター化
2.類似検索:コサイン類似度などでトップxx件の文書を抽出
3.プロンプト構築:抽出した文書をもとにLLMへ渡すプロンプトを生成(回答に必要な関連部分のみを渡す)
4.LLM呼び出し:回答生成
5.出力調整:機密情報が含まれていないか、回答品質チェックを挟むことも
4-1. コンテキスト長と要約
LLMによっては入力プロンプトの長さ(コンテキストウィンドウ)に制限があります。抽出した文書が長い場合は要約や抜粋が必要です。要約もLLMや専用の要約モデルを使って行うことが多いです。
4-2. LangChainなどのフレームワーク
・RAGパイプラインを簡潔に実装するために、LangChainやHaystackなどのフレームワークを活用するのも一般的です。
・文書のロード、変換、埋め込み、RAGワークフロー実行などを一貫してサポートしてくれます。
5. ユーザーインターフェース・API
5-1. チャットボットUI
・従業員が使いやすいチャット形式のUIをWebアプリやTeams/Slack連携で提供
・会話ログの保存:問い合わせ内容と回答結果を保存し、後から分析やモデル改善に活かす
5-2. APIエンドポイント
・既存システムや業務フローに組み込む場合は、REST / GraphQLなどでAPIを提供
・外部システムでRAG機能を呼び出し、回答を受け取れる仕組みを用意
6. セキュリティ・認証・権限管理
6-1. 組織内のアクセス制御
・ドキュメントごとに閲覧権限が異なる場合、ユーザーIDやロールによるアクセス管理が必要
・検索段階でユーザーごとに検索結果をフィルタリング(ACL連携)する仕組み
6-2. 機密情報の保護
・API呼び出し時に機密データが外部に流出しないよう、オンプレまたはVPC隔離された環境で運用するか、データをマスクして送信するなどの対策
・LLMのベースモデルに対してファインチューニングする際も、学習データから個人情報や機密情報が復元されないよう配慮
7. 運用・監視・継続的改善
7-1. モデル評価とログ分析
・ユーザーのフィードバック(回答の正確性・満足度など)を蓄積・分析
・回答の品質検証:RAGが正しい文書を参照しているかのモニタリング
7-2. データ更新とインデックス再構築
・企業内のドキュメントは随時更新されるため、定期的にインデックスを再作成・更新し、最新情報を反映させる仕組みが必要
7-3. スケーラビリティとコスト管理
・LLMやベクターストアのリクエスト数・同時接続数に応じてスケーリングが必要
・クラウド利用の場合はリソースのオートスケール設定や従量課金管理が欠かせません
2.生成AIデータ構築の手順
1. データ収集・前処理
1-1. データソースの特定とアクセス手段の確保
社内にあるあらゆる情報を活用するには、まず以下のようなデータソースを洗い出しましょう。
・ファイルサーバー(PDF, Word, Excel, PowerPointなど)
・社内Wiki / ナレッジベース(Confluence, SharePoint, Qiita:Teamなど)
・チャット履歴 / メール(Slack, Teams, Outlook など)
・業務システムのDB(ERP, CRM, 顧客データベースなど)
機密情報や権限設定の確認が必要になる場合が多いので、情報システム部門やセキュリティ部門と連携してデータ取得手順を確立します。
1-2. テキスト化・クレンジング
データソースからテキストを取得していきます。
ファイル系
・PDF→テキスト抽出(PDFのレイアウト崩れに注意)
・Word, Excel→Officeファイルを扱えるライブラリやAPIを利用
・画像やスキャン文書→OCRでテキスト化
データベース・システム連携
SQLクエリやAPIを用いて文章・コメント情報を取得
機密・個人情報のマスク
必要に応じて正規表現やツールで個人情報(電話番号、メールアドレスなど)をマスク
重複排除、ノイズ除去
同じ文書が重複していないか、無意味な文字列がないかチェック
1-3. セキュリティとアクセス制御
・データを一元的に格納する場合、機密レベルに応じた権限管理やアクセスログの取得が必要です。
・重要度が高いデータを外部クラウドにアップロードする場合は、セキュリティポリシーの遵守も必須です。
2. 埋め込み(Embedding)とベクターストア構築
RAGでは、「文書をベクター(数値のリスト)に変換し、それを使って検索する」仕組みが重要です。
2-1. 埋め込みモデルの選定
OpenAI Embeddings(text-embedding-ada-002など)
API経由で簡単に高精度なベクターが得られる。ただしデータを外部APIに送ることになるため、機密情報を扱う場合は注意
オープンソースのSentence-BERT系
クラウドやオンプレ環境で動かせる。日本語特化モデルの利用を検討(e.g., rinna, 東北大CLSモデルなど)
必要に応じて、自社内でホストするモデルかクラウドAPI利用かを決めましょう。
2-2. ベクターデータベースの選定
Pinecone
クラウドベースのマネージドサービス。スケール・管理が容易。
Weaviate / Milvus / Qdrant / Chroma
オープンソースプロジェクトであり、オンプレまたはDockerで運用可能。
Elasticsearch + kNN Plugin
既にElasticsearch基盤がある場合はこれを拡張して利用するのもあり。
2-3. インデックス作成フロー
1.文章の分割(Chunking)
1文書丸ごとではなく、1,000〜2,000文字程度に分割することで、より精度の高い検索が可能。
埋め込み(Embedding)
各チャンク(分割後テキスト)に対して埋め込みを取得。
ベクターストアに書き込み
テキストチャンクとメタデータ(文書のタイトル、URL、アクセス権限情報など)を紐付けて保存。
3. RAGパイプラインの実装
RAGは「Retriever」と「Generator」から構成されます。
3-1. Retriever(検索部)
1.ユーザーのクエリを埋め込み
クエリテキストを埋め込みモデルに渡してベクターを取得。
2.ベクターストアに対して類似検索
上記ベクターと類似度が高い上位k件の文書チャンクを取得。
3.検索結果を整形
必要に応じて要約や重複排除、長文のトリミングなどを実行。
3-2. Generator(回答生成部)
1.プロンプト構築
検索で取得したチャンクを「システムプロンプト」または「コンテキスト」としてLLMに渡す。
例:「ここに関連ドキュメントの抜粋があります。以下を踏まえ、ユーザーの質問に答えてください」
2.LLM呼び出し
GPT-4や自社ホストのLlama 2など、目的・環境にあったモデルを使用。
3.出力取得・後処理
回答結果を適宜整形し、ユーザーに返す。
機密データが混在しないよう注意が必要な場合は、回答前にフィルタリングロジックを入れる。
3-3. LangChainやHaystackの活用
LangChain(Python中心)
ドキュメントロード、分割、ベクターストア操作、RAGワークフローなどがまとまっている。
Haystack
類似の機能を持ち、RAGベースのQA実装を簡単にできる。
これらのフレームワークを利用すると、RAGフローをスムーズに実装できます。
4. ユーザーインターフェース/API設計
4-1. チャットボットUI
RAGを使ったAIエージェントの多くは「チャット形式のUI」を採用します。ユーザーがクエリを入力すると即時に回答が返ってくる形です。
・Webアプリで簡易的なチャットUIを提供
・TeamsやSlackのBot連携を実装し、従業員が普段のツールから直接問い合わせできるようにする
4-2. APIエンドポイント
・社内の他システムから「FAQ回答機能」や「文書レコメンド機能」を呼び出せるように、REST APIやGraphQLを用意します。
・API認証(OAuth, JWTなど)を実装し、ユーザーごとのアクセス権限をチェックすることでセキュリティを担保します。
5. 運用・監視・改善
5-1. 運用時のログ収集
・ユーザーのクエリ、取得した文書、最終回答をログとして保存
・回答品質や誤りの傾向を分析し、必要に応じてモデルを更新/ベクターストアを最適化する
5-2. インデックス更新
・社内ドキュメントは更新・追加・削除が頻繁に行われます。
・定期的なバッチ処理やWebhook連携で、最新データを取得&インデックスを再構築する仕組みを作っておく。
5-3. モデルのバージョン管理
・LLMや埋め込みモデルをアップデートする場合の影響を見極めるため、ステージング環境での検証を推奨
・変更履歴や評価結果をドキュメント化しておく
まとめ
RAGを使った社内向けAIエージェントを構築するには、以下のフローを意識した技術要素が重要となります。
1.データ収集とETL
2.ベクターストア/検索エンジンの整備
3.LLMとRAGパイプライン
4.UI/UXおよびAPI設計
5.セキュリティと権限管理
6.運用・継続的学習
また、構築の手順は以下の通りです。
1.データ収集・前処理
2.ベクター検索基盤の構築
3.RAGパイプライン(Retriever + Cenerator)の実装
4.ユーザーインターフェースとAPIの整備
5.継続的な運用と改善
RAGの強みは、「大規模言語モデルの生成力」+「企業が保有するドメイン知識」を組み合わせることで、汎用的なLLMだけでは得られない正確かつ最新の回答を実現できる点です。社内業務の効率化、ナレッジシェアの促進などに大きく貢献するでしょう。
ぜひ、本記事の手順を参考に、RAGベースのAIエージェント構築を検討してみてください。社内のDXを進める上でも、業務効率やイノベーションを加速させる強力な武器となるはずです。