ガバメントAI「源内」は自治体で本当に使えるのか？ クラウド依存による“3つの落とし穴”（2/3 ページ）

[川口弘行，ITmedia]

ローカルで動く「Open GENAI」を作ってみた

　このような問題に対して、筆者は、源内が依存するクラウドマネージドサービスを、ほぼ全てオープンソースの代替技術に置き換えるプロジェクトを立ち上げました。「Open GENAI」（オープン源内）です。

Open GENAI画面（筆者提供）

　実施したことはシンプルです。源内がAWSで実現している各機能を、対応するオープンソース技術に置き換えました。

　認証はKeycloakに、LLM推論はOpenAI互換API経由でOllamaなどのローカルLLMに、チャット履歴はSQLiteに、文字起こしはfaster-whisperに、ファイルストレージはローカルファイルシステムに、RAGのベクトル検索はQdrantに、画像生成はStable Diffusionにそれぞれ置き換えています。

　源内のフロントエンドは、デジタル庁のオリジナルコードをMITライセンス（マサチューセッツ工科大学で作成されたオープンソースライセンス）に基づいて流用し、クラウドサービスを呼び出している部分のみを代替技術に差し替えています。オリジナルのライセンス・著作権表示はそのまま保持しています。

　つまり、源内の設計思想とUI／UXを尊重しつつ、裏側のインフラだけを「オープン」に置き換えた形です。

段階的なAI導入を可能にするOpen GENAI

　現在、Open GENAIは筆者のPC上で動いています。Open GENAIが「完全ローカルで動く」ということの意味を、自治体の文脈で考えてみましょう。

　最大の意義は、データ主権の確保です。全てのデータ（チャット履歴、RAGに登録した文書、文字起こしの音声ファイル、生成された画像など）が、ローカル環境にとどまります。外部クラウドに送信されません。

　これは、これまで「データをクラウドに出せないからAIを試せない」と、導入を保留していた自治体にとって、検証を始めるためのハードルを下げます。「まずは閉じた環境で機能を試し、効果を確認してから、必要に応じてクラウド環境に移行する」という段階的な導入が実現します。

　また、LLMの接続先はOpenAI互換APIなので、OllamaのようなローカルLLMだけでなく、vLLM、LM Studio、あるいはOpenAIなどのクラウドAPIにも切り替えられます。ローカルで検証し、本番運用ではクラウドの高性能なモデルを使う、という使い分けも可能です。

　つまり「ローカルかクラウドか」という2択ではなく「ローカルで始めて、必要に応じてクラウドへ移行する」という段階的な選択肢を実現できます。

「AIアプリ」で自治体向け機能を柔軟に追加

　Open GENAIは、源内の機能をローカル化しただけではありません。源内が備えている「AIアプリ」という拡張機能の仕組みを生かし、独自の機能を追加しました。

　源内には、外部マイクロサービスを「AIアプリ」として登録し、統合UIから呼び出せる仕組みがあります。Open GENAIはこの仕組みを尊重しつつ、Difyで作成したワークフローやチャットフローをAIアプリとして呼び出せる機能を実装しました。

　Difyとは、オープンソースのLLMアプリ開発プラットフォームで、ノーコードでワークフローやチャットボットを作成できるツールです。最近ではMCP（Model Context Protocol）サーバとの連携もサポートしており、AIエージェント的な挙動も実現します。

　これが何を意味するのかというと、自治体固有の業務プロセス、例えば「議事録から議案を抽出して所管課に振り分ける」「住民の問い合わせ履歴からFAQを自動生成する」「条文と条例を横断検索して根拠を示す」などをDifyで構築し、それを源内の統合UIからAIアプリとして呼び出せるのです。

　源内のアプリ拡張の仕組みを生かしているため、Difyで作ったフローは源内の画面にAIアプリとして自然に統合されます。つまり、Open GENAIは単に「源内をローカルで動かした」だけでなく「自治体が自分たちの業務に合わせてAIを拡張できる基盤」を提供しているのです。

　Open GENAIはOSS（オープンソースソフトウェア）として公開しています。GitHubから誰でも自由にクローンし、試すことができます。