Qiita AI Summit 登壇レポート：PoCで終わらせない、エンタープライズRAGの「権限管理」と「泥臭い実装」の全貌
2026年1月29日に開催された Qiita AI Summit にて、登壇の機会をいただきました。
Qiita AI Summit — AI時代が訪れた今、開発組織のあり方を考える
スライドで伝えきれなかった部分も含めて、記事として残しておきます。
はじめに：なぜこのテーマで話したか
今回のサミットのテーマは「AI時代が訪れた今、開発組織のあり方を考える」でした。
各社のAI活用事例や開発プロセスの変化が語られる場で、私が選んだテーマは少し毛色が違いました。「AI時代の開発組織」を語るなら、PoCを本番に持っていく力があるかどうかが核心だと思っていて、そのテーマで話しました。
「ChatGPTを使ってみた」「開発速度が上がった」という話ではなく、エンタープライズ向けのRAGシステムを実際に作る中で直面した、セキュリティ設計・権限管理・コスト爆発というリアルな壁の話をしました。
企業のAI活用が進まない現状
ChatGPTやCopilotの登場で、個人レベルのAI活用は急速に広まりました。でも企業全体の利益に資するAI活用となると、話は全然違います。
【よくある失敗パターン】
- PoCで止まる：実証実験は成功しても、本番環境に持っていけない
- 業務に定着しない：一部の部署で導入したが、気づいたら使われなくなる
- 全社展開できない：特定のユースケースからスケールできない
理由はシンプルで、企業には「セキュリティ要件」「権限管理」「コスト」という、個人利用では気にしなくていいレイヤーが存在するからです。
我々が開発している IntegratorX は、まさにこの課題に正面から取り組むRAG基盤です。
では具体的に、何がしんどかったのか。ここからは実際にぶつかった壁を順に話していきます。
技術Deep Dive① 権限管理との戦い
最初のアプローチ：SpiceDB
権限管理の設計で最初に検討したのが SpiceDB です。GoogleのZanzibarにインスパイアされたOSSで、ReBACベースの柔軟な権限モデルが強みです。
これだけ聞くと最高に見えます。でも要件を細かく分析した結果、オーバースペックだという結論に至りました。
なぜシンプルな設計を選んだか
RAGの特性を踏まえると、必要な権限チェックはそこまで複雑ではありませんでした
- 参照が主目的なので「見られるか・見られないか」が分かれば十分
- 編集・削除などの副作用ある操作は、接続先（Salesforce・Google Drive等）の認証に任せる
- 接続先の権限をそのまま踏襲するなら、シンプルなリレーションを貼るだけで要件を満たせる
🔑 「最先端・最柔軟」が正解とは限らない。今の要件に合ったシンプルさを選ぶほうが、開発速度・保守性・チームの理解度すべてにおいて優れていることが多い。
技術Deep Dive② Salesforceの「項目レベルセキュリティ」という壁
権限管理の方針が固まったと思ったら、次の壁が現れました。Salesforceの項目レベルセキュリティです。
問題の本質：行は見せていい、でも列は隠したい
| フィールド | 一般社員 | 管理職のみ |
|---|---|---|
| 名前 | ✅ | ✅ |
| 年齢 | ✅ | ✅ |
| 給与 | ❌ | ✅ |
RLSより細かいカラム単位の権限制御です。これがRAGと組み合わさると厄介な問題が起きます。
Salesforceのデータをベクトル化する際、「給与」カラムの情報も一緒にEmbeddingに含まれてしまいます。
最初に考えた解決策（そして失敗）
「ヒットしたIDをもとに、ユーザー権限で再取得すればいいのでは？」
ベクトル検索 → オブジェクトIDを取得 → ユーザー権限で再取得 → 安全なデータを返す
一見うまくいきそうです。でも、もっと深刻な問題に気づきました。
推論攻撃（Inference Attack）のリスク
「検索にヒットした」という事実だけで、情報が漏れる。
給与カラムを見られない一般社員が「高給与の社員を教えて」と質問したとします。中身は返ってこなくても、「そういうデータが存在する」「どのレコードが該当するか」という事実が漏れてしまいます。
根本的な問題は、ベクトル化の時点で権限外の情報がEmbeddingに含まれていることでした。検索の後ではなく、インデックスを作る段階から設計し直す必要がありました。
「コスト度外視の力技」で乗り越える
出した答えは、ユーザー別インデックスです。
各ユーザーが「見られる項目だけ」で構成されたインデックスを個別に作成する
| ユーザー | インデックス内容 |
|---|---|
| 一般社員A | 名前・年齢のみ |
| 管理職B | 名前・年齢・給与すべて |
Embedding段階から機密情報が混入しないため、推論攻撃のリスクを根本から排除できます。
1,000人ユーザーいれば1,000個のインデックス。コストは正直しんどいです。でも限られた期間でセキュリティ要件を確実に満たすには、これしかなかった。
次の一手：権限ハッシュ化アプローチ（検討中）
見られるカラムの組み合わせ → 正規化 → ハッシュ値を生成 → 同ハッシュ = 同インデックス共有
- 現状：1,000ユーザー → 1,000インデックス
- ハッシュ化後：10〜50インデックス程度に削減できる可能性
権限変更時の影響やインデックス更新の複雑さは残りますが、コストとセキュリティのバランスを取る上で最も有望なアプローチだと考えています。
その他の「現実の壁」
600TBのデータとコスト爆発
ある企業では、蓄積データが 600TB に達していました。全部ベクトル化するとEmbeddingのAPIコストだけで莫大な金額になります。さらに：
- 全部インデックスしてから「精度が出なかった」と判明するリスク
- ロジック変更のたびに再処理コストが発生
- エンジニアが失敗を恐れて試行錯誤できなくなる
必要なデータだけを選別してインデックスできる仕組みが不可欠です。
検索精度の低下
古いファイル・重複ファイル・テストデータが検索結果に混入し、精度が落ちます。選択的インデックスでノイズを排除することが重要です。
また、Salesforceのオブジェクト間の参照関係をグラフRAGで持つことで、権限管理の最適化と検索精度向上を同時に狙えると考えています。
データ品質の問題
AIモデルの精度はデータの質に直結します。「レシート画像として集めたはずが、関係ない画像が混在していた」——そういうことは珍しくありません。データ整備の段階から自動化できれば、PoCの速度と精度を大きく改善できます。
まとめ
PoCを本番に持っていく力があるかどうか——それが「AI時代の開発組織のあり方」の核心だと私は思っています。
PoCで喜んでいる場合ではない。本番で動かすまでの泥臭い道を歩き切れる組織だけが、AIの恩恵を企業全体に届けられる。
今回の登壇を通じて改めて感じたのは、エンタープライズRAGには「正解がない問いに対して、制約の中でベストを選び続ける力」が求められるということです。SpiceDBを捨てたのも、ユーザー別インデックスという力技を選んだのも、完璧だったからではなく、その時点で最もまともな選択肢だったからです。
IntegratorXはまだ発展途上で、権限ハッシュ化やグラフRAGなど試したいことは山積みです。今後もこうした「本番でぶつかった話」を発信していくので、同じ課題感を持つ方と議論できたら嬉しいです。
登壇資料
おわりに
登壇機会を用意してくださったQiita運営の皆さん、会場・オンラインで聞いてくださった皆さん、ありがとうございました。