社内AIエージェントを自社開発して学んだこと #1 —「出典のない回答」は使われない
本シリーズは、SY Partners（ベトナム・ハノイ／横浜。日本市場向けの開発・QAを行う、ベトナム・日本の2拠点で計約250名の会社です）で、社内AIエージェント基盤「SYAgent」を自社開発・運用する中で得た学びを共有するものです。数値はいずれも社内実績であり、環境によって異なります。
結論：出典を表示するだけでは足りなかった
社内向けRAG（Retrieval-Augmented Generation）を作るとき、「回答に出典を付ける」は自然な要件です。私たちも最初からそのつもりで実装しました。
しかし、初期の出典表示は十分に機能しませんでした。
例えば、AIがプロジェクトの運用ルールを説明したあとに、次のような表示を出します。
出典：プロジェクト管理規程.docx
間違いではありません。ただ、50ページある文書の名前だけを示されても、利用者はどこを確認すればよいのか分かりません。
出典が「ある」ことと、根拠を「検証できる」ことは別でした。
この記事では、Microsoft Teams上で動く社内AIエージェント「SYAgent」を題材に、出典の粒度、回答できない場合の扱い、古いナレッジの管理について、私たちが実際に見直したポイントを共有します。
なぜ自社開発したのか
はじめまして。SY Partnersの副社長・共同創業者 グエン・ディン・バー（Nguyen Dinh Ba）です。社内AIエージェント基盤「SYAgent」の開発・運用で得た学びを、技術面から共有していきます。
SY Partnersはお客様のシステム開発・QAを本業とする会社です。開発プロセスへのAI活用も進んでおり、社内プロジェクトの約9割で何らかの形でAIを活用しています（社内実績です）。
ただし、開発者が個人でAIを使うことと、AIエージェントを組織の業務に組み込むことは、別の課題でした。
お客様にAI活用をご提案する立場として、まず自分たちが最初のユーザーになり、難しいところまで経験しておくべきだ。そう考えて、社内AIエージェント基盤「SYAgent」を自社開発することにしました。
SYAgentはMicrosoft Teams上で動く役割別エージェント群です。現在はプロジェクト管理（PM支援・PMO）領域のベータ版を社内リリースし、複数の実プロジェクトで使いながら改善しています。育成（Tutor）・人材評価（HR）の領域にも拡張中です。
この連載では、開発・運用を通じて得た学びを一つずつ扱います。第1回は、実際に直面した「出典付き回答」の問題です。
解きたかった二つの課題
出発点には、二つの課題がありました。
一つ目は、ナレッジが人と場所に散在していること。開発標準、過去案件の知見、プロジェクトの最新情報は、Redmine、GitHub、共有フォルダ、そして詳しい人の頭の中に分かれていました。必要な情報を探すより「知っている人に聞く」方が速い、という状況です。
二つ目は、管理業務が現場の時間を奪っていること。進捗報告、会議メモ、課題の整理といった仕事が、PMやリーダーの時間を圧迫していました。
全社に一度に展開するのではなく、最も課題が明確だったプロジェクト管理から始め、参照対象をRedmine、GitHub、承認済みの社内ドキュメントに絞りました。
設計の4原則
作り始める前に、チームで次の四つを原則として決めました。
- 実データのみから、出典付きで回答する（今回のテーマ）
- 権限はデータ層で制御する（第2回で扱います）
- AIが提案し、人が決める
- 測って、直して、また測る
今振り返ると、この四つを単なる運用上の希望ではなく、最初から機能要件として考えたことが重要でした。特に一つ目は、実装してみると想像以上に細かい設計判断を必要としました。
回答フローの全体像
概念的には、次の流れです。
Microsoft Teamsで質問
↓
利用者・参照権限を確認
↓
アクセス可能な承認済みデータを検索
├─ Redmine
├─ GitHub
└─ 承認済み社内ドキュメント
↓
取得した情報に基づき、出典とともに回答を生成
↓
利用者が根拠を確認し、必要な判断を行う
ポイントは、検索対象を「承認済み」の情報に限定していることです。ナレッジは取り込み → レビュー → 公開のフローで管理し、版数や機密度をメタデータとして持たせています。古くなった文書は取り下げます。
何を根拠に回答してよいかを、人間側で決めておく。エージェントは、その範囲の情報を使って回答する。この考え方が、後の改善にもつながりました。
失敗1：文書単位の出典では、確認コストが高い
最初のバージョンでは、回答に文書名を付けていました。
出典：プロジェクト管理規程.docx
正しい文書名が表示されていても、利用者はなかなか確認しに行きませんでした。50ページの文書を自分で開いて該当箇所を探すのでは、手間がかかりすぎます。
そこで、検索用に文書を分割する段階で、文書名・版数・セクション・機密度を各チャンクに持たせ、回答に対応する参照箇所を示せるようにしました。
以下は考え方を表す説明用の例であり、実際の社内スキーマや規程の内容ではありません。
document_title: "プロジェクト管理規程"
version: "3.0"
section: "4.2 進捗報告"
classification: "internal"
回答画面では、次のように利用者が確認先を特定しやすい形を目指します。
回答：週次報告では、進捗・課題・次の対応事項を確認します。
出典：プロジェクト管理規程 v3.0 > 4.2 進捗報告
※回答文と版数・節番号も説明用の架空例です。
大切なのは、生成モデルに出典らしい文字列を自由に書かせないことです。検索によって取得した情報のメタデータと回答を対応付け、元の記述を確認できるようにします。
セクション単位まで出典の粒度を下げてから、出典リンクのクリックが明らかに増えました。 単に「出典を付けた」からではなく、「どこを見れば裏が取れるか」が分かるようになったからだと考えています。
出典は、付いていることよりも、検証できることに意味がある。 これが今回の一番大きな学びです。
失敗2：出典付きでも、古い情報なら誤った案内になる
もう一つは、改定前の旧版ドキュメントがナレッジに残っていたことです。エージェントは古いルールを、しかも出典付きで案内してしまいました。
根拠が表示されることで、かえって信頼できそうに見える点が厄介でした。
この問題を機に、公開フローと対になる取り下げフローと、版数管理を見直しました。
文書を取り込む
→ 内容・公開範囲をレビュー
→ 承認済みとして公開
→ 改定時に版を更新
→ 旧版を検索対象から取り下げる
RAGの運用では、文書をどう追加するかだけでなく、古い情報をどう検索対象から外すかも回答品質に直結します。
出典が付いていれば正しいわけではありません。その出典が現行版かどうかまで含めて確認できる必要があります。
「分からない」と答えることも、テストする
社内ナレッジにない情報を、AIが推測で埋めてしまうことは避けたいところです。
そのため、取得した情報から確認できない場合は「該当するデータが見つかりませんでした」と回答するよう、生成プロンプトに制約を入れています。しかし、プロンプトで禁止しただけで誤回答が完全になくなるわけではありません。
リリース時の回帰テストでは、通常の質問だけでなく、次のようなケースも確認しています。
- 実際には存在しない社内制度について質問する
- アクセス権限のないプロジェクト情報について質問する
LLMの出力には揺らぎがあるため、一度直ったように見えても、次の更新で再発する可能性があります。一度の正答ではなく、継続的に品質を確認する。この考え方には、弊社が取り組んできたQAの経験が生きています。
利用者の反応から学んだこと
ベータ版を複数のプロジェクトで使ってもらう中で、回答の流暢さだけでは利用者の信頼は得られないと分かりました。
出典の粒度を直した後、利用者の「使い続ける率」も目に見えて変わりました。もちろん、社内の限られたサンプルでの話であり、他の環境でも同じ結果になるとは限りません。
それでも、出典リンクのクリックと継続利用の両方に変化が見られたことは、私たちにとって重要なフィードバックでした。
個人で使うチャットAIなら、多少の推測を自分で補って使う場面もあるでしょう。しかし、組織の業務に組み込むエージェントでは、根拠を自分で確かめられるかが利用を左右すると考えています。
副社長・共同創業者として重視していること
私が重視しているのは、回答が自然に見えるかだけではなく、利用者が根拠に戻って、自分で判断できるかという点です。
- 回答に示された出典は、実際にその主張を支えているか。
- 元の資料の該当箇所に、利用者がたどり着けるか。
- 旧版や権限外の情報が検索対象に混ざらないか。
- 必要な情報がないとき、無理に答えを作らないか。
- 改善した内容を、リリース後も継続して測れているか。
これらはLLMの性能だけでは解決しません。ナレッジ管理、検索、アクセス制御、テストを一つの仕組みとして考える必要があります。
まとめ・次回予告
今回の学びは、単に出典を付ければ信頼される、ということではありません。
出典を確認できる粒度で示し、古い情報を除外し、答えられないときは答えない。 そして、実際に使われたかどうかを測り、直し続ける。そこまで含めて初めて、業務に組み込めるRAGに近づけると考えています。
SYAgentは現在もベータ版として改善中です。完成された成功事例としてではなく、実際に使って見つかった課題を共有していきます。
第2回は「権限はデータ層で制御する」。画面で隠すだけではなぜ不十分なのか、役割・プロジェクト単位のアクセス制御を検索段階に入れた話を書く予定です。
*SY Partners ／ 副社長・共同創業者 グエン・ディン・バー（Nguyen Dinh Ba）
SY Partnersは、日本市場向けのシステム開発・QA・AI開発を行っています。公式サイト（日本語）
