法人AI導入はどこから設計する？SaaS・API・RAG・ローカルを業務とデータで分ける

法人AI導入を「SaaSにするか、RAGにするか、ローカルにするか」と聞くと、技術選定から始めたくなる。しかし先に決めるべきは、どの業務を変え、どのデータを使い、誰が出力を確認し、誰が停止できるかである。

SaaS、API、RAG、ローカルは一つを選んで終わる階層ではない。SaaSを業務の入口にし、APIで既存システムとつなぎ、RAGで社内文書を参照し、機密度や遅延の条件でローカル処理を置くこともある。重要なのは、増やす技術ごとにデータ経路と運用責任を増やせるかだ。

構成を業務から選ぶ表

構成	向く業務	先に確認するデータ	主な運用責任	増やさない条件
SaaS ワークスペース	要約、下書き、会議支援などの共通作業	入力、ファイル、共有、保持	アカウント、権限、利用規程	外部連携範囲が不明
API組込み	既存アプリの一機能	要求・応答、ログ、費用	認証、評価、例外、版	成功条件がない
RAG	更新される社内文書への質問	参照元権限、削除、引用、更新	検索索引、検索、評価、監査	文書責任者がいない
ローカル処理	外部送信を避ける必要がある限定作業	モデル、端末、保存、更新	端末、モデル更新、監視	実行環境を維持できない

OpenAI、Anthropic、Google、Microsoftの商用向け説明はデータ利用や管理について条件を示す。だが、特定のプランや外部連携が自社のデータ要件を満たすかは別に確認する必要がある。

一業務だけ選び、次の流れを紙に書く。

利用者 → 入力 → AI → 参照データ → 出力 → 人の確認 → 保存・ログ → 削除・更新

RAGを入れるなら、参照データの権限が最初の論点になる。検索結果を出す人と、元文書を読める人が同じ条件か。削除された文書が検索索引、キャッシュ、バックアップからいつ消えるか。回答が誤ったときに引用と元文書へ戻れるか。これを決めずに「社内データで賢くなる」とは言えない。

AWSの導入ガイダンスも、価値、リスク、技術、人、データアクセス、連携、評価、監視を分けて考える。NIST AI RMFの測定も、リスクを主張でなく根拠・証跡で確認する方向を示す。

最初から複数の外部連携、エージェント、検索、外部実行操作をつなげない。次の条件がそろった一業務だけで始める。

この五つが揃わないなら、構成を変える前に業務設計を直す。

法人AIの構成は、最も新しい技術を並べる図ではない。どのデータをどこへ渡し、誰が確認し、誰が運用責任を持つかを一業務ごとに決める図である。

ローカル構成も、外部API、モデル取得、更新、ログ送信、外部連携を使えば通信する。外部送信を避けることが要件なら、構成名ではなく実際の通信経路と設定で確認する。