源内OSSとグループウェア連携｜技術要件・課題・導入手順

はじめに

自治体や公共機関では、生成AIを新たに導入する一方で、庁内にはすでに大量の規程、通知、議事録、契約書、申請書、過去事例が蓄積されています。これらの文書がSharePoint、Google Workspace、Box、ファイルサーバー、独自の文書管理システムに分散している場合、生成AIだけを導入しても十分な業務効果は得られません。

そこで注目されるのが、デジタル庁が一部をオープンソースソフトウェアとして公開したガバメントAI「源内」と、既存のグループウェア・文書管理システムとの連携です。

結論から言えば、公開されている源内Webの外部AIアプリ連携仕様を利用すれば、既存システムとの連携基盤を構築することは技術的に可能です。一方、現時点の公開仕様から、SharePointやGoogle Workspaceへ設定だけで直結できる完成済み標準コネクタは確認できません。各組織の認証方式、権限構造、文書分類、ネットワーク条件に合わせた中継アプリケーションの実装と検証が必要です。

また、添付の技術評価報告書は実装可能性を詳細に分析していますが、処理時間、検索精度、同時接続数、費用などの実測値は示していません。そのため、「連携可能性が高い」という評価と、「本番環境で性能・安全性が実証済み」という評価は分けて考える必要があります。

ガバメントAI「源内OSS」とは

ガバメントAI「源内」は、行政職員が生成AIを安全かつ実務的に利用するためにデジタル庁が開発・運用している基盤です。デジタル庁は2026年4月24日、地方公共団体や政府機関で類似基盤を重複開発するコストを抑え、各機関が主体的にAI基盤を構築できるよう、源内の一部をOSSとして公開しました。

公開された構成は、大きく次の2層に分かれます。

利用者が操作する「源内Web」
特定業務を処理する外部マイクロサービス「行政実務用AIアプリ」

源内WebはAWSのGenerative AI Use Cases、通称GenUを基盤としながら、チーム管理、外部AIアプリの登録・実行、監視・モニタリングなど行政利用向けの機能が追加されています。現在はGenUとは独立して開発が進められています。

デジタル庁は2026年8月25日に源内OSS Ver 2.0の計画に関する説明会を設定しており、公開仕様は今後も更新される可能性があります。導入時には固定した製品として見るのではなく、更新を追跡しながら運用するOSSとして捉えることが重要です。

既存システムと連携できる技術的根拠

外部REST APIを呼び出せる

源内Webは、行政実務用AIアプリとして外部のREST APIを登録し、実行できます。既存の文書管理システムを直接改修するのではなく、両者の間に「連携用ExApp」を置くことで、検索、要約、文書生成、保存といった処理を実装できます。

たとえば、利用者が源内Webで「過去3年間の類似契約を検索し、相違点を整理してください」と入力すると、ExAppがSharePointやGoogle DriveなどのAPIへ問い合わせ、取得した文書をLLMへ渡し、根拠付きの回答を源内Webへ返す構成が考えられます。

JSON定義から入力画面を自動生成できる

源内Webでは、外部AIアプリの登録時にJSON形式で入力項目を定義できます。対応する主な項目は、テキスト、複数行テキスト、数値、ファイル、選択肢、チェックボックス、ラジオボタン、非表示項目です。

これにより、文書種別、対象年度、担当部署、検索対象フォルダ、処理モードなどを、案件ごとに画面へハードコーディングせず設定できます。自治体ごとに異なる文書分類や入力様式にも比較的対応しやすい設計です。

同期処理と非同期処理を使い分けられる

短い照会やメタデータ抽出には同期処理、複数PDFの解析や新旧対照表の作成には非同期処理を使用できます。非同期処理では、受付後にHTTP 202とリクエストID、状態確認URLを返し、PENDING、IN_PROGRESS、COMPLETED、ERRORの状態をポーリングします。

処理結果はMarkdown形式のテキストだけでなく、生成したPDFや表計算ファイルなどをファイルとして返すこともできます。これにより、「検索して答える」だけでなく、「文書を生成し、所定の保存先へ戻す」業務フローまで設計できます。

想定できる3つの連携シナリオ

連携シナリオ	処理の例	期待できる効果
セキュアRAG検索	既存文書をAPIで検索し、参照範囲を限定して回答を生成	規程・議事録・過去事例を探す時間の短縮、根拠の明確化
非同期文書生成・自動保存	複数資料を解析し、新旧対照表、要約、監査資料を生成して元システムへ保存	手作業の転記、抽出、保存先誤りの削減
対話型文書推敲	会話履歴を維持しながら答弁書、通知文、広報文を段階的に修正	推敲ノウハウの共有、属人化の抑制

重要なのは、AIが文書を一括コピーして独自保管する設計に限定しないことです。必要な時点で既存システムへ問い合わせる「分散型RAG」を採用すれば、原本管理を維持しながらAI活用を進めやすくなります。

実装時に直面する4つの課題

1. 認証できても、文書権限が引き継がれるとは限らない

源内WebはSAMLによる複数IdPとのログイン連携に対応し、システム管理者、チーム管理者、一般ユーザーなどの権限を持ちます。しかし、源内へログインできることと、SharePointやGoogle Drive上の各文書について「その利用者が閲覧できるか」を判定できることは別問題です。

固定APIキーだけで外部システムへ接続すると、全利用者が連携用サービスアカウントの権限で文書を検索する危険があります。対策として、利用者IDや所属、役割を安全なトークンでExAppへ伝え、外部システム側で本人の権限を再評価する設計が必要です。

Microsoft Graphは委任アクセスとアプリ単独アクセスを区別し、SharePointでは対象サイトやリスト等に範囲を絞るSelected権限も提供しています。Google Driveでもファイル、フォルダ、共有ドライブごとにACLが存在します。したがって、AI側で独自の権限表を作るのではなく、可能な限り既存システムのACLを検索時に適用することが原則です。

2. Base64変換で大容量ファイルが膨張する

公開API仕様では、ファイルはBase64エンコードして送信します。Base64化するとデータ量は概ね3分の4の逆数、すなわち約1.33倍になります。複数の大容量PDFや画像を一度に送ると、API Gatewayや実行基盤のリクエスト上限、タイムアウトに達する可能性があります。

本番構成では、大容量ファイルをAPI本文へ直接載せず、署名付きURLを発行してオブジェクトストレージへ直接アップロードし、ExAppには保存先URIだけを渡す方式が有効です。ファイルサイズ上限、拡張子、マルウェア検査、保存期間、暗号化、削除処理も併せて設計する必要があります。

3. APIキーだけでは監査と最小権限が不十分になりやすい

外部AIアプリの接続では、送信元IPアドレスの許可とAPIキー認証を組み合わせられます。ただし、本番運用では「誰が、いつ、どの文書を検索し、何を生成し、どこへ保存したか」を追跡できなければなりません。

源内Webには、行政実務用AIアプリのログ、実行履歴、ユーザー情報、ユーザーアクティビティなどを外部のログ収集先へ送信する仕組みがあります。既存システム側のアクセスログと相関できるリクエストIDを設け、入力、参照文書、出力、承認、保存の履歴を一連で監査できる形にすることが重要です。

4. OSSは「無償」でも運用責任はなくならない

源内Webのソフトウェアは原則MIT License、文書や図面はCC BY 4.0ですが、AWS Prototyping Programで作成された一部のLambda・CDKファイルにはAmazon Software Licenseが適用され、AWS以外では利用できないと明記されています。マルチクラウドやオンプレミスへ移植する際は、対象ファイルを特定して置換の要否を確認しなければなりません。

また、ソースコードの利用許諾と、「ガバメントAI 源内」の名称・ロゴの使用許諾は別です。派生サービスを提供する場合は、デジタル庁による運営、認証、推奨を受けたものと誤認させない表示が必要です。

OSSの採用は、保守費用がゼロになることを意味しません。脆弱性対応、依存ライブラリ更新、仕様変更の追従、障害対応、バックアップ、監査、利用者支援を誰が担うかを、調達段階で明確にする必要があります。

現実的な3段階の導入ロードマップ

段階1：閉域・限定文書でRAGを検証する（1〜3か月）

最初は対象部署、対象フォルダ、文書種別、利用者を限定します。既存システムは読み取り専用とし、検索精度、引用元表示、権限外文書の遮断、応答時間、1件あたり費用を測定します。

PoCで最低限確認したい指標は次の通りです。

正しい根拠文書が上位に取得される割合
権限外文書が検索結果と回答へ混入しないこと
回答に出典と該当箇所が表示される割合
代表的なPDF、Office文書、画像PDFの解析成功率
平均・95パーセンタイル応答時間
1問い合わせ当たりの推論・検索・保管コスト
職員が回答を修正した割合と修正理由

段階2：非同期処理と保存ワークフローを実装する（3〜9か月）

次に、複数資料の比較、要約、監査資料の作成など時間のかかる処理を非同期化します。生成物を既存の文書管理システムへ戻す場合は、自動保存ではなく、当初は人の確認と承認を挟むことが安全です。

この段階で、リクエストIDによる監査ログの突合、大容量ファイル転送、エラー時の再実行、保存先の決定規則、原本との関連付けを検証します。

段階3：権限継承と業務横断展開を進める（9か月以降）

最後に、利用者属性と既存システムのACLを連携し、部署や役職、案件単位で参照範囲を制御します。対象業務を増やす際は、共通API、共通ログ、共通評価指標を整備し、案件ごとに個別開発が繰り返される状態を避けます。

導入判断に使えるチェックリスト

既存システムに検索、取得、保存用APIがあるか
APIから文書本文とメタデータを取得できるか
利用者単位または対象範囲単位でアクセスを制限できるか
外部接続元IPを固定し、許可リストへ登録できるか
大容量ファイルを署名付きURL等で分離転送できるか
AIの参照元と生成結果を監査ログで追跡できるか
原本、生成物、承認済み文書を区別して管理できるか
誤回答や権限漏えいを検知する評価データを用意できるか
OSS本体と依存コンポーネントのライセンスを確認したか
更新、脆弱性対応、障害対応の責任者と予算を決めたか

まとめ

ガバメントAI「源内OSS」と既存グループウェア・文書管理システムの連携は、外部REST API、動的UI、同期・非同期処理、ファイル出力などの公開仕様から見て、十分に実現可能性があります。

しかし、技術的に接続できることと、行政実務で安全に使い続けられることは同じではありません。特に重要なのは、利用者権限の継承、大容量ファイル転送、監査ログ、ライセンス、継続保守です。

導入の第一歩は、全庁展開を前提とした大規模構築ではありません。限定した文書と利用者で、検索精度、権限制御、処理性能、費用を測る小さなPoCから始めることです。JAICでは、製品ありきではなく、既存環境と業務課題を整理したうえで、PoC設計、評価指標、利用ルール、研修、定着までを一体で支援することが重要だと考えます。

FAQ

Q1. 源内OSSを導入すれば、SharePointやGoogle Workspaceとすぐ連携できますか？

いいえ。源内Webには外部REST APIを呼び出す仕組みがありますが、組織固有の認証、権限、文書分類に合わせたExAppなどの連携層が必要です。現時点の公開仕様では、設定だけで各製品へ直結する完成済み標準コネクタは確認できません。

Q2. 文書をすべてAI側へコピーする必要がありますか？

必須ではありません。利用時に既存システムを検索する分散型RAGや、更新分だけを同期する方式も選べます。原本管理、応答速度、検索精度、費用、障害時の影響を比較して決めます。

Q3. 機密文書も扱えますか？

技術的には可能ですが、情報分類、権限継承、通信経路、暗号化、ログ、保存期間、モデルへのデータ送信条件を確認する必要があります。「閉域だから安全」「国産だから安全」といった単一条件だけでは判断できません。

Q4. Google WorkspaceとSharePointでは、設計は同じですか？

基本構成は似ていますが、OAuthスコープ、共有ドライブやサイトの単位、権限継承、API制限が異なります。共通のExAppを作る場合でも、接続先ごとの認証・ACL変換モジュールを分離する方が安全です。

Q5. PoCの合格基準は何ですか？

回答の見栄えではなく、根拠文書の取得精度、権限外文書の遮断、出典表示、応答時間、費用、職員による修正率を数値化します。特に権限漏えいは、1件でも発生した場合に原因分析と設計見直しを行うべき重大指標です。

参考資料

営業の声をWebコンテンツ改善に生かす方法｜成果につなげる組織的な仕組み

熟練工の暗黙知をAR教材化する方法｜認知的ヒアリングとAI連携の実践設計

ガバメントAI「源内OSS」は既存グループウェアと連携できるのか？技術要件と導入ロードマップ