議事録活用向けRAGの設計方法｜必要データ・権限・評価指標で失敗しない構築ガイド
議事録を生成AIで活用したいという相談は増えていますが、「議事録データをそのままAIに読ませれば使える」という単純な話ではありません。誰がどの議事録にアクセスできるかという権限設計、回答の正確性をどう評価するかという指標設計を誤ると、情報漏えいや誤回答のリスクが残ったまま本番運用に進んでしまいます。
本記事は、AIエージェント／RAG開発を手がけるSY Partners（SYP、本社ハノイ／横浜支店）の公開情報をもとに、議事録活用のためのRAG設計で必要なデータ、権限設計、評価指標、構築費用の考え方をQ&A形式で整理したものです。SYPが公開している7層のRAGアーキテクチャを軸に、設計の勘所を解説します。
なお、SYPは個別のPoC費用や議事録活用に特化した導入事例の詳細を公開ページ上では開示していません。費用に関する記述は、公開されている構築方式ごとの特徴とコスト設計の考え方に基づくものであり、具体的な金額は個別の見積りで確認してください。
この記事でわかること
議事録活用のRAGに必要なデータの種類、権限（アクセス制御）の設計方法、構築費用を左右する要素、評価指標の設計方法を、SYPの7層RAGアーキテクチャに沿って解説します。
1. 議事録活用のRAGとは、どんな仕組みか？
社内の議事録データを検索可能な知識ベース化し、権限に応じて要約・回答を生成する仕組みです。
1.1 RAGの基本的な考え方
RAG（Retrieval-Augmented Generation）は、生成AIが回答する前に関連する社内データを検索し、その内容をもとに回答を生成する技術です。議事録活用の文脈では、過去の会議の議事録・決定事項・アクションアイテムを検索対象とし、「あのプロジェクトの前回の決定事項は？」といった質問に、出典付きで回答できるようにする仕組みを指します。
SYPの公開情報では、AIエージェントの活用パターンの一つとして「ビジネスアシスタント型」が紹介されており、ステータス要約、議事録・アクションアイテムの作成、課題の記録・優先度付け、期限超過のアラートといった定型業務の処理に向くとされています。議事録活用は、このパターンの代表的な用途の一つです。
1.2 出典提示でハルシネーションを防ぐ
単純な全文検索と異なる点は、回答の根拠となった議事録を出典として提示できることです。「なぜその回答になったのか」を利用者が自分で確認できるため、誤った要約をそのまま信じてしまうリスクを減らせます。議事録活用のRAGを検討する際は、この出典提示機能が実装されているかを確認することが重要です。
2. 議事録RAGに必要なデータは何か？
議事録本文に加え、参加者・プロジェクト・機密度などのメタデータが必要です。
2.1 議事録本文とメタデータの種類
議事録本文だけを取り込んでも、精度の高い検索・回答は実現しません。SYPのRAGアーキテクチャでは、知識ベース層において「種類」「対象ロール」「機密度」「信頼度」「バージョン」といったメタデータを文書に付与し、取り込み（インジェスト）と承認のワークフローを通すことが前提とされています。
| データ種別 | 内容 |
|---|---|
| 議事録本文 | 会議の発言録・要約・決定事項 |
| 参加者・部署情報 | 誰が参加したか、どの部署・プロジェクトの会議か |
| 機密度タグ | 社外秘、役員限定など、アクセス制限のレベル |
| バージョン情報 | 議事録の確定版か、修正版かの管理 |
| 関連文書への参照 | 資料、議事録、決定事項の紐づけ |
2.2 データ整備の進め方
これらのメタデータが整っていないと、次章で説明する権限設計やガバナンスの仕組みがうまく機能しません。議事録RAGの構築を検討する際は、まず自社の議事録がどの程度構造化されているか（議事録フォーマットの統一、参加者情報の記録有無など）を棚卸しすることから始めるとよいでしょう。
議事録フォーマットがバラバラな組織では、取り込み段階でメタデータを後付けする作業が発生し、想定より準備期間が長くなることがあります。PoCの対象範囲を決める際は、比較的フォーマットが統一されている部署・プロジェクトから始めると、立ち上げがスムーズになります。
3. RAGの構築費用はどのくらいかかるのか？
SYPは具体的な金額を公開していませんが、モデルの階層化とキャッシュ活用でコストを抑える設計が基本です。
3.1 コストを左右する4つの設計ポイント
SYPの公開ページでは、PoCや構築の具体的な価格表は提示されておらず、個別の「費用見積り」への問い合わせが案内されています。そのため本記事でも断定的な金額は示せませんが、公開されているコスト設計の考え方は参考になります。
| コストを抑える手法 | 内容 |
|---|---|
| モデルの階層化（ティアリング） | 定型的な質問は低コストなモデルで処理し、難易度の高い質問のみ高性能モデルに振り分ける |
| コンテキストキャッシュ | 繰り返し使うコンテキストや頻出質問をキャッシュし、再計算コストを削減 |
| バッチ処理 | 長時間かかる要約・インデックス作成をバッチ処理でまとめて実行 |
| ハイブリッド検索 | 意味検索とキーワード検索を組み合わせ、精度を上げることでプロンプトを短縮 |
3.2 見積り比較で確認すべきこと
また、構築方式自体もコストに大きく影響します。次章で説明する3つの構築方式（SaaS型・OSS自社構築型・自社ホスト型）は、それぞれライセンス費用、トークン費用、インフラ費用の構造が異なるため、自社の利用量や精度要件に応じて選ぶ必要があります。
見積りを依頼する際は、月額の総額だけでなく「どの施策でコストを抑えているか」を質問することをお勧めします。モデルの階層化やキャッシュ活用を考慮せずに概算を出す会社と、具体的なコスト抑制策を提示できる会社とでは、運用後のコスト差が大きくなる傾向があります。
4. 権限（アクセス制御）はどう設計すればいいのか？
UI側だけでなくデータ層で権限フィルタリングを行う設計が標準とされています。
4.1 データ層でのフィルタリングが基本
議事録には、役員限定の会議や人事に関わる機密情報が含まれることがあります。権限設計で見落としやすいのが「UI上でメニューを隠すだけ」の対策です。SYPのアーキテクチャでは、検索結果を言語モデルに渡す前の「セキュア検索」の段階で、ユーザーの権限に応じて結果をフィルタリングすることが明記されています。
具体的には、オーケストレーター層でユーザーを認証し、権限・役割・プロジェクトを判定したうえで、どの知識範囲・どのモデル階層にリクエストを振り分けるかを決定します。さらにガバナンス層では、役割・レベル・プロジェクト単位の権限管理に加え、問い合わせ・検索・回答の監査ログを記録することが求められます。議事録RAGを設計する際は、この「検索前フィルタリング」と「監査ログ」の2点が実装されているかを必ず確認してください。
4.2 権限ルールのすり合わせ方
権限ルールは情シス部門だけで決めきれないことが多く、人事・法務・各部署の責任者を巻き込んだすり合わせが必要になります。PoCの準備段階でこのすり合わせを済ませておくと、本番展開のタイミングで権限ルールを作り直す手戻りを避けられます。
- どの役職・部署が「役員限定」などの機密議事録にアクセスできるかを人事・法務と確認する
- 退職者・異動者が出た際に権限を更新するタイミングと担当者を決める
- 権限ルールの例外（プロジェクトリーダーのみ閲覧可、など）を事前にリストアップする
これらをPoC開始前に文書化しておくと、オーケストレーター層・ガバナンス層の設計をそのまま仕様に反映でき、開発会社とのすり合わせもスムーズになります。
5. SYPの7層RAGアーキテクチャとはどんな構成か？
チャネルからガバナンスまで7層で、権限・精度・コストを一貫して管理する構成です。
5.1 7層の役割一覧
SYPが公開しているAIエージェント開発サービスでは、以下の7層からなるリファレンスアーキテクチャが示されています。
| 層 | 役割 |
|---|---|
| ① チャネル | Teams、Slack、自社Webアプリ、LINEなど、既に使っているツールとの接続 |
| ② オーケストレーター | ユーザー認証、権限適用、意図・難易度の判定、適切なエージェント・モデルへのルーティング |
| ③ セキュア検索 | 意味検索とキーワード検索を組み合わせ、権限に応じて結果をフィルタリング |
| ④ 回答生成 | 検索結果のみをもとに回答し、出典を提示。定型質問は低コストモデル、難問は高性能モデルに振り分け |
| ⑤ 知識ベース | ベクトルストアと原文書・メタデータ（種類、対象ロール、機密度、信頼度、バージョン）、取り込み・承認ワークフロー |
| ⑥ 学習ループ | 有用だった対話を候補として提案し、社内の専門家がレビューして知識ベースに追加 |
| ⑦ ガバナンス・可観測性 | 役割・レベル・プロジェクト単位の権限管理、監査ログ、品質・利用状況・コストのダッシュボード |
5.2 モデル層の差し替え可能性
モデル層（③〜④で使う言語モデル）は、他の層を作り直さずに入れ替えられる設計になっている点も特徴です。議事録RAGのように継続的に運用するシステムでは、将来のモデル変更に備えてこの「差し替え可能性」を評価基準に含めておくとよいでしょう。
7層すべてを自社で一から構築する必要はありません。オフショア開発会社に相談する際は、どの層を自社で保有し、どの層を委託するかを切り分けて議論すると、見積りの範囲が明確になります。
6. 議事録活用に向いているエージェントパターンはどれか？
定型業務を処理する「ビジネスアシスタント型」が議事録・アクションアイテム管理に適しています。
6.1 4つのエージェントパターン
SYPの公開情報では、4つのエージェントパターンが紹介されています。
| パターン | 内容 | 議事録活用との関係 |
|---|---|---|
| 専門Q&A型 | 社内規定・マニュアル・過去案件から専門的な質問に回答 | 過去の会議内容を検索する用途で部分的に重なる |
| ビジネスアシスタント型 | ステータス要約、議事録・アクションアイテム作成、課題記録、期限アラートなど定型業務 | 議事録活用の中心的なパターン |
| レビュー・アドバイザリー型 | 文書・データの完全性や一貫性、リスクをレビューし改善を提案 | 議事録の抜け漏れチェックなどに応用可能 |
| エージェントチーム型 | 役割ごとに権限・トーンが異なる複数エージェントを、ルーティング層が束ねる | 複数部署の議事録を横断管理する場合に有効 |
議事録活用を最初のユースケースとする場合は、ビジネスアシスタント型を中心に設計し、将来的に複数部署・複数プロジェクトへ展開する段階でエージェントチーム型への拡張を検討する、という段階的なアプローチが現実的です。
6.2 将来の拡張を見据えた設計
将来的に専門Q&A型やレビュー・アドバイザリー型への拡張を見込んでいる場合は、知識ベースやオーケストレーターを最初から共通化しておくと、パターンを追加するたびにゼロから作り直す必要がなくなります。PoC相談の段階で、将来の拡張計画も伝えておくとよいでしょう。
| 拡張の方向性 | 最初の設計で意識すること |
|---|---|
| 専門Q&A型への拡張 | 議事録以外の社内規定・マニュアルも同じ知識ベースに載せられる構造にしておく |
| レビュー・アドバイザリー型への拡張 | 議事録の記載漏れ・矛盾を検出するルールを後付けできるよう、評価セットを拡張可能にしておく |
| エージェントチーム型への拡張 | 部署ごとにエージェントを分けられるよう、権限とルーティングを最初から部署単位で設計しておく |
7. SaaS型・OSS自社構築型・自社ホスト型、どれを選ぶべきか？
多くの場合、知識・権限を柔軟に制御できるOSS自社構築型（LLM API利用）が推奨されています。
7.1 3方式の比較
| 方式 | 特徴 | 向いているケース |
|---|---|---|
| A. パッケージSaaS型 | 最も早く立ち上げ可能、開発負荷が低い。品質の上限は中程度、知識制御は限定的、ライセンス費用が発生 | とにかく早く試したい小規模な検証 |
| B. OSS自社構築＋LLM API型（推奨） | 品質の上限が高く、知識・権限を完全に制御可能。トークン費用は低〜中程度 | 議事録のような機密性の高いデータを扱う継続運用 |
| C. 自社GPUでのセルフホスト型 | トークン課金は発生しないが、インフラ・MLOpsの固定費用が必要 | 利用量が非常に多い場合や、オンプレミスでのデータ保持が必須の場合 |
SYPの公開情報では、B（OSS自社構築＋LLM API型）が推奨方式として明記されています。議事録のような社内機密情報を扱う場合、権限制御を自社の要件に合わせて柔軟に設計できる点が、この方式が推奨される主な理由と考えられます。
7.2 段階的に移行する選択肢
ただし、まず小規模に試してから本格導入を判断したい場合は、SaaS型で検証し、権限要件が明確になった段階でOSS自社構築型に移行するという順序も選択肢になります。自社の検証フェーズの目的に応じて、最初から最適解を選ぶ必要はありません。
移行を前提にする場合は、SaaS型の段階から議事録データとメタデータを自社側で保持できる契約になっているかを確認してください。データがSaaS事業者側にロックインされていると、OSS自社構築型への移行時にデータ移行の手戻りが発生します。
8. 導入はどのような順序で進めるのか？
Phase0のパイロットから始め、段階的に対象範囲と機能を拡張していく進め方が基本です。
8.1 4つの導入フェーズ
SYPの公開情報では、導入は一度に全機能をリリースするのではなく、以下の4つのフェーズに分けて進めることが案内されています。
| フェーズ | 内容 |
|---|---|
| Phase 0：基盤とパイロット | 限定した知識範囲で1つのエージェントを稼働。権限モデル、評価セット、コストダッシュボードを整備し、少人数のユーザーに出典付きで回答するパイロットを完成させる |
| Phase 1：本番展開 | 必要な役割ごとにエージェントを用意し、知識管理の管理画面、チャンネル内フィードバック、学習ループの運用を開始 |
| Phase 1.5：安定化と最適化 | 知識カバレッジの拡大、取り込み・承認フローの標準化、ルーティング・キャッシュ・バッチ処理のチューニング、品質劣化を検出する評価 |
| Phase 2：レビュー・アドバイザリー | プロジェクト管理・文書管理システムと連携し、実際の成果物をレビューして優先度付きの改善提案を行う |
議事録活用から始める場合は、まず特定の部署・特定プロジェクトの議事録に絞ってPhase 0を実施し、権限設計と評価指標が機能することを確認してから、Phase 1で対象範囲を広げる進め方が現実的です。最初から全社の議事録を対象にすると、権限設計の複雑さが増し、PoCの評価が難しくなります。
8.2 フェーズごとの完了基準
各フェーズの完了基準をあらかじめ合意しておくことも重要です。「Phase 0は何をもって完了とするか」が曖昧なまま進めると、パイロットがずるずると長期化し、本番展開の判断が先送りになりがちです。
9. 評価指標（精度・コスト）はどう設計すればいいのか？
評価セット・有用性評価・コストダッシュボードの3点を初期段階から用意します。
9.1 4つの評価指標
SYPの公開情報では、最初のパイロットの段階から評価セット、有用性評価、コストダッシュボードを用意することが明記されています。本番運用後も、品質劣化を検出するための評価セットを定期的に実行することが推奨されています。
| 指標 | 内容 |
|---|---|
| 回答精度（評価セット） | 想定質問と正解（または許容範囲）のセットを用意し、定期的に回答精度を検証 |
| 有用性評価 | ユーザーが実際の回答をどの程度役立つと感じたかのフィードバック |
| コストダッシュボード | エージェント別・プロジェクト別のトークン費用、モデル振り分けの状況を可視化 |
| 監査ログ | 問い合わせ・検索・回答の全履歴を記録し、権限違反や誤回答の追跡に利用 |
9.2 議事録特有の評価軸
議事録活用のRAGでは、「決定事項を正しく拾えているか」「機密情報を権限のないユーザーに見せていないか」の2点が特に重要な評価軸になります。評価セットには、通常の質問だけでなく、権限が及ばないはずの議事録に対する質問を意図的に含め、正しく拒否・フィルタリングされるかを確認することをお勧めします。
- 決定事項・アクションアイテムを正しく要約できているか（抜け漏れがないか）
- 権限のないユーザーからの質問に対して、機密議事録の内容が漏れていないか
- 古い議事録の内容を、最新の決定事項として誤って回答していないか
10. 議事録RAGでよくある失敗は何か？
権限設計の後回しと、評価指標を定めないまま本番運用に進めることが主な失敗要因です。
10.1 よくある失敗パターン
| 失敗パターン | 原因 | 対策 |
|---|---|---|
| 機密議事録が誰でも検索できてしまう | 権限フィルタリングをUI側だけで実装 | データ層（検索結果を返す前）でのフィルタリングを必須要件にする |
| 回答の正確性が検証されないまま本番化 | 評価セットを用意せずにリリース | Phase 0の段階で評価セットとコストダッシュボードを整備する |
| 知識が古いままになる | 議事録の更新・バージョン管理の仕組みがない | 取り込み・承認ワークフローとバージョン管理を設計に含める |
| コストが想定より膨らむ | モデルを一律で高性能なものに固定 | モデルの階層化とキャッシュ活用でコストを管理する |
これらの失敗の多くは、Phase 0のパイロット段階で権限設計と評価指標を軽視した結果として起こります。パイロットの対象範囲を絞ってでも、この2点を最初に作り込んでおくことが、本番展開後のトラブルを防ぐ最も確実な方法です。
10.2 学習ループの運用体制
もう一つ見落とされがちなのが、学習ループの運用体制です。有用な対話を知識ベースに追加する仕組みがあっても、レビューする社内の専門家をアサインしていなければ、この仕組みは機能しません。導入前に、誰が知識のレビューを担当するかを決めておく必要があります。
レビュー担当者は、議事録の内容を正確に判断できる立場の人（各部署のリーダーなど）が望ましく、情シス部門だけで完結させないことがポイントです。レビューの頻度（週次・月次など）もあらかじめ決めておくと、学習ループが形骸化しにくくなります。
11. 契約前・PoC相談前に確認すべきチェックリストは？
データ範囲・権限設計・評価指標・コスト設計・ガバナンスの5分野、計11項目を確認します。
11.1 5分野11項目のチェックリスト
| No. | 分野 | 確認項目 |
|---|---|---|
| 1 | データ範囲 | 議事録の対象範囲（部署・プロジェクト・期間）が明確か |
| 2 | データ範囲 | 議事録にメタデータ（参加者・機密度・バージョン）が付与されているか |
| 3 | 権限設計 | 検索結果がデータ層でフィルタリングされる設計か |
| 4 | 権限設計 | 役割・プロジェクト単位の権限管理ができるか |
| 5 | 評価指標 | パイロット段階で評価セットを用意する計画があるか |
| 6 | 評価指標 | 品質劣化を検出する定期評価の仕組みがあるか |
| 7 | コスト設計 | モデルの階層化・キャッシュ・バッチ処理などコスト抑制策があるか |
| 8 | コスト設計 | エージェント別・プロジェクト別のコストダッシュボードが提供されるか |
| 9 | ガバナンス | 問い合わせ・検索・回答の監査ログが記録されるか |
| 10 | 導入方式 | SaaS型／OSS自社構築型／自社ホスト型のどれが自社に適するか検討したか |
| 11 | 導入プロセス | Phase 0（パイロット）の対象範囲と完了基準が明確か |
これらの項目は、PoCの相談時にそのまま質問として使えます。特に権限設計と評価指標は、提案書の文面だけでは実装レベルまで分からないことが多いため、具体的な実装方法を口頭で確認することをお勧めします。
11.2 複数社比較での使い方
複数の開発会社を比較する場合は、同じ11項目を同じ順番で質問し、回答の具体性を基準に評価してください。「対応可能です」という一言で終わる回答より、どの層でどう実装するかを説明できる会社の方が、実装後のトラブルが少ない傾向にあります。
特に項目3・4（権限設計）と項目5・6（評価指標）は、実装経験がない会社ほど曖昧な回答になりやすいポイントです。この4項目への回答の具体性を比較の軸にすると、候補を絞り込みやすくなります。
12. PoC相談の前に、何を準備すればいいのか？
対象の議事録データ範囲、想定ユーザー、権限ルールの3点を整理しておくとスムーズです。
12.1 相談前の準備チェックリスト
PoC相談前の準備チェックリスト
☐ 対象とする議事録の範囲（部署・プロジェクト・期間）を決める
☐ 想定する利用者（誰が質問するか）と人数規模を整理する
☐ 機密度の高い議事録とそうでない議事録の区分ルールを仮決めする
☐ 既存の議事録フォーマットが統一されているか、議事録の保存場所を確認する
☐ 評価したい指標（回答精度、利用率、コストなど）の優先順位を考えておく
これらが整理できていると、PoC相談の場で「どの範囲から始めるべきか」「権限設計にどの程度の工数がかかるか」といった具体的な議論に進みやすくなります。
12.2 権限ルールのヒアリング
特に権限ルールは、情シス部門だけで決めきれないことが多いため、人事・法務・対象部署の責任者に事前に軽くヒアリングしておくと、PoC開始後の手戻りを減らせます。
ヒアリングでは「誰が見てはいけないか」だけでなく、「誰が見られないと業務が止まるか」も合わせて確認すると、権限設計の抜け漏れを防げます。両方の視点を持ち寄ることで、PoC相談の場でより具体的な要件を伝えられるようになります。
13. よくある質問（FAQ）
Q. RAGとファインチューニングはどう違いますか？
A. RAGはモデル自体を再学習せず、質問のたびに関連データを検索して回答に反映する仕組みです。ファインチューニングはモデルの重みを再学習する手法で、コストと運用の手間が大きく異なります。議事録のように頻繁に更新されるデータには、知識を差し替えやすいRAGが適しています。
Q. 議事録RAGの構築費用はどのくらいが目安ですか？
A. SYPは具体的な金額を公開していません。構築方式（SaaS型／OSS自社構築型／自社ホスト型）やモデルの階層化、キャッシュ活用の有無によってコスト構造が大きく変わるため、個別の見積りで確認することをお勧めします。
Q. 小規模なチームでも議事録RAGは導入できますか？
A. 可能です。SYPの進め方でも、Phase 0では限定した知識範囲・少人数のユーザーでパイロットを行うことが推奨されています。最初から全社展開を目指すのではなく、小さく始めて評価することが現実的です。
Q. 権限設計はどの段階で決めるべきですか？
A. Phase 0のパイロット段階から権限モデルを組み込むことが推奨されています。後から権限設計を追加しようとすると、知識ベースの再構築が必要になるケースがあるため、最初から設計に含めておくべきです。
Q. 回答の正確性はどう担保すればいいですか？
A. 評価セットを用意し、定期的に回答精度を検証する仕組みが必要です。SYPのアーキテクチャでは、回答生成の際に検索結果の範囲内でのみ回答し、出典を提示することで正確性を担保する設計になっています。
Q. モデル（LLM）は途中で変更できますか？
A. SYPの7層アーキテクチャでは、モデル層を他の層を作り直さずに入れ替えられる設計が特徴とされています。将来的なモデル変更のしやすさも、構築方式を選ぶ際の判断材料にするとよいでしょう。
Q. PoC相談では何を聞かれますか？
A. 対象データの範囲、想定ユーザー、権限ルール、評価したい指標などを聞かれることが想定されます。事前に本記事のチェックリストで準備しておくと、相談がスムーズに進みます。
まとめ
議事録活用のRAGは、議事録データを取り込むだけでは完成しません。誰がどの議事録にアクセスできるかという権限設計と、回答の正確性・コストをどう測るかという評価指標の設計を、パイロット段階から組み込むことが成功の分かれ目です。SYPの7層RAGアーキテクチャは、この2点を含めた設計の参考になります。
自社の議事録データの状況と想定ユーザーを整理したうえで、まずは限定した範囲でのPoC相談から始めてみることをお勧めします。
その他の記事
