— 株式会社ノウデルのAI活用への取り組み —
2026年3月に着手した、クローズドネットワーク環境で動作するRAG型AI基盤の構築が、製品「ROOTA（ルータ）」として形になりました。当社は本製品の企画・開発を担当しています。
社内の規程やマニュアルをAIに読ませたい。けれども、その情報を外部のサービスへ送ることはできない。この2つを同時に満たすことが、開発の出発点でした。
設計 データを「学習させない」のではなく、「渡さない」
クラウドのAIサービスでは、「入力データを学習に使わない」という設定が用意されていることがあります。しかしそれは、データが通った上での取り決めにすぎません。
ROOTAは、そもそもデータを外に出しません。入力・回答・会話履歴・学習させた文書と、そこから作られる検索用データまで、すべてお客様の社内ネットワークの中に留まります。外部のAIサービスやAPIへの送信はありません。
利用状況を外部へ送る仕組みも無効にし、画面表示に使うフォントやアイコンまで製品内に同梱しました。外部のCDNからも読み込みません。通信そのものが発生しない構成にすることで、「設定を間違えると漏れる」という状態をなくしています。
分離 部門やグループ会社ごとに、構造で分ける
複数の部門やグループ会社で同じ基盤を使う場合、互いのデータが見えてはいけません。
ROOTAでは、会話履歴・学習させた文書・利用者情報を、運用に合わせた単位ごとに分離しています。データベースは行レベルセキュリティで保護し、文書の検索領域も単位ごとに分けているため、他の単位の文書が回答や引用に混ざることは構造上起きません。
この点は自動テストと実機の両方で検証しています。設定の書き方で守るのではなく、仕組みとして成立することを重視しました。
また、管理者が利用状況を把握できる一方で、会話の本文は管理者にも見えない設計にしています。「使われているのは知りたいが、中身は見せたくない」という運用実態に合わせたものです。
構成 社内のサーバーだけで完結する
ROOTAは、お客様の社内ネットワークに置いたサーバー群だけで動きます。
利用者がアクセスするのはROOTAの画面だけで、データベースやAI処理基盤、LLMサーバーに直接つながる経路はありません。すべて社内ネットワークの内側に閉じています。
言語モデルは社内のGPUサーバー上でオープンモデルを動かし、日本語の文書検索には日本語に特化した埋め込みモデルを使っています。どちらも外部のAPIを呼びません。運用時にインターネット接続を必要としない構成です。
送付はコンテナ形式にまとめており、お客様の環境の中で組み上がります。検証環境と本番環境で同じものが動くため、動作環境の違いによる不具合を持ち込みません。
機能 検索から、業務エージェントの自作まで
開発を進める中で、お客様の関心は「AIと話せること」から「自分たちの業務そのものを任せること」へ移っていきました。
そこで、利用者が画面から業務エージェントを組み立てられる機能を用意しました。入力するファイル、処理の手順、出力する形式を画面で並べることで、プログラムを書かずに業務の流れを組めます。
- 文書を根拠に回答する — 社内文書を検索し、どのファイルのどこを見たか示しながら答える
- 帳票を読み取る — 紙の帳票をスキャンし、様式に沿って項目を取り出す
- 音声を扱う — 通話や会議の音声を文字にし、内容を確認・修正できる形にする
- 結果をファイルで出す — 既存の業務システムに取り込める形式で出力する
社内文書はPDF・Word・Excel・PowerPointなど主要な形式に対応し、画像を添付して質問することもできます。回答はWordやPDFとしてそのまま持ち出せます。
ここで重視したのは、業務ごとの違いを設定データ側に置くことです。帳票の様式や、出力する項目をコードではなく設定として持ちます。そのため、別の業務に広げるときにプログラムを書き換える必要がありません。
実際に、性質の異なる複数の業務エージェントが同じ基盤の上で動いています。
品質 検索の精度を、測りながら作る
社内文書を根拠に回答する仕組みは、「それらしく答える」を返すだけでは実務で使えません。根拠として引いた文書がずれれば、利用者が引用元を開いたときに無関係な内容が出てきます。
そこで開発では、あらかじめ正解を用意した問いの集合を作り、変更のたびに採点する方法を採りました。「資料に書かれていない問い」も意図的に含め、答えられないときに答えないことも測っています。
閾値の調整や検索方式の変更は、この採点結果を見ながら進めています。感応ではなく数字で判断できるようにしたことで、改善を積み上げられるようになりました。
この過程では、思ったどおりにならなかったことも記録に残しています。検索の閾値を上げれば精度が上がると考えていたものの、実際には利用者の問いかけの言葉と文書の中の言葉が噛み合っていないことが原因だった、といった事例です。原因を取り違えたまま調整を重ねないためにも、測定と記録を欠かさない方針をとっています。
今後 業務ごとのエージェントを増やす
基盤としての形は整いました。今後は、実際の業務に合わせたエージェントを増やしていきます。
紙の帳票を業務システムへ取り込む工程や、大量の書類を読んで報告書の下書きを作る工程など、人手で時間がかかっていた作業から順に取り組んでいます。
いずれも、担当者の判断を置き換えるものではありません。根拠を示し、下書きを用意し、人が確認して直すという形を基本にしています。最終的な判断と責任は、あくまでどこまでも担当者に残ります。
当社は引き続き、ROOTAの開発を担当してまいります。