EastCloudCMS

デジタル庁が政府AI源内をオープンソース公開 — コードの中身と行政DXの現在地

執筆者:

毎輝高野

カテゴリ:

, ,

2026年4月24日、デジタル庁のガバメントAI源内（げんない）のソースコードがGitHubで公開された。リポジトリを開いてまず目に入るのは、CONTRIBUTING に書かれた一文だ。Pull Requestは受け付けていない。Issueも、データ損失やサービス障害、法令違反、重大なアクセシビリティ障壁に限定されている。

多くのOSSプロジェクトがPR歓迎の文言を掲げるなか、真逆の方針が堂々と書かれている。最初は違和感を覚えるが、読み進めるほどデジタル庁なりの筋が見えてくる。

そもそも源内とは何か

源内は、デジタル庁が内製で開発・運用している政府職員向けの生成AI利用環境だ。ガバメントクラウド上に構築されており、2025年5月にデジタル庁内部での提供が始まった。名前の由来は、Generative AI を縮めた GenAI の音読みと、エレキテルを復元した江戸時代の発明家・平賀源内を重ねたもので、役所の命名としてはかなり攻めている。

アーキテクチャは4層に分かれている。一番下がガバメントクラウドのコンピューティングリソース、その上がAIエンジン層で、ここで複数のLLMを切り替えながら実行できる。さらにAPI層が既存の府省庁システムと繋がり、最上位には行政実務に特化した20種類以上のAIアプリケーションが並ぶ。

アプリ層の顔ぶれが興味深い。汎用のチャット、要約、校正に加えて、法制度調査を支援する Lawsy、国会答弁検索、公用文チェッカーといった業務特化型が揃う。法律条文を横断検索して回答するようなAIは、民間のチャットボットラッパーでは手が出しにくい領域になる。

ここで見逃せないのが、源内そのものがさらに上流のOSSを土台にしている事実だ。ベースになっているのは、AWS Japan のボランティアが中心になって開発している Generative AI Use Cases、略して GenU。民間OSSを政府が拡張して庁内で運用し、その拡張分をふたたびOSSとして戻している。往復構造ができあがっているわけだ。

利用実績レポートから見える現場の姿

ここからが面白い。デジタル庁は2025年8月、職員による源内の利用実績を公開しており、数字を追うとかなり具体的な状況が見えてくる。

3ヶ月間の集計で、対象約1,200人のうち950人が利用。利用率にして約80%にのぼる。総利用回数は65,032回、1人あたり平均70回。週ごとの利用回数は3,000〜6,000回のレンジで推移している。業務効率化を実感したかというアンケートでは、110人中79.1%が肯定的に回答した。

具体的な時短事例も公開されている。Teams会議の議事録作成で10分程度、VBAマクロの自動生成で数時間、マニュアル検索で30分〜1時間の短縮。役所仕事の地層を成しているのが議事録と表計算で、そこが素直に省力化できている事実は、そこそこ効いている。

一方で、同じレポートのなかで目を引くのは、使われ方の偏りのほうだ。ヘビーユーザー150人以上が3ヶ月で100回以上使っているのに対して、170人は5回未満にとどまる。さらに踏み込むと、係員級の半数以上が50回以上使っている一方で、課長級の半数は利用実績ゼロ、という段差が出ている。民間から出向してきた専門人材は最高利用率を示した。

これは源内の性能の話ではなく、組織とリテラシーの話だ。末端で使うほどメリットの大きい道具を、権限を握っている層が触っていない。下から有効性を訴えても、上にピンと来ていなければ、申請フローや許容される使い道は広がらない。OSS公開というニュースの裏には、この上の層にどう触らせるかという、技術では解けない宿題が残っている。

Lawsy開発チームの内幕

源内を語るうえで、法制度調査AI Lawsy（ロージー）は外せない。もとはデジタル庁主催の法令×デジタルハッカソンから生まれたプロトタイプで、その後、源内の行政実務特化アプリのひとつとして磨き上げられていった。

開発チームは PolicyGarage の note に詳細な記録を残している。コアメンバーは3名。国家公務員でデータ分析とAIを担当する鈴木宏和氏、DSPy実装を中心に技術面を支えた白川達也氏、フロントエンドの神代洋明氏。この小さなチームが、本番LLMに OpenAI GPT-4o、フレームワークにスタンフォード大学発のリサーチツール STORM が採用する DSPy、フロントエンドに Streamlit を選んで作り上げた。

興味深いのが、途中でターゲットペルソナを変更した経緯だ。当初は専門家レベルの法令調査を助けるツールを目指していたが、ハッカソン期間内では精度が間に合わず、法令に詳しくない人向けの解説ツールへと舵を切り直している。この手の方向転換は民間のプロダクト開発では日常茶飯事だが、官公庁発のプロジェクトで公然と記録に残っていることのほうが珍しい。

技術の苦労も具体的だ。e-gov の法令データはXMLで提供されているが、チャンク化しようとすると文脈の維持と処理効率のトレードオフにぶつかる。Web検索APIの文字数上限、具体的には Tavily の400字制限に長いクエリが引っかかり、クエリ自動最適化のワークフローを挟むことになった。STORM の6段階パイプラインを Lawsy 独自の9段階に再編したのも、法令特化ゆえの要請だった。

こういう手触りの話が一次情報として残っているのは貴重で、源内を巨大な箱ものとして語るイメージを壊してくれる。実際には、顔の見える小さなチームが、民間のハッカソンと変わらない試行錯誤を重ねた成果物に、政府の名前が冠されている。

公開されたリポジトリの中身

公開されているリポジトリは大きく2つ。Web側の digital-go-jp/genai-web と、アプリ側の digital-go-jp/genai-ai-api だ。

Web側 — digital-go-jp/genai-web

ユーザーインターフェースを担うのがこちら。言語構成は TypeScript 99%、主要ライブラリは React と Tailwind CSS、インフラは AWS CDK。冒頭で触れたとおり、AWS の GenU をベースに、デジタル庁が機能を追加した格好になっている。拡張内容は次のあたりが中心になる。

  • チーム管理機能
  • AIアプリ管理機能。外部マイクロサービスとして生成AIアプリを追加し、実行できる
  • デジタル庁デザインシステムの適用
  • 庁内アクセシビリティチームによる試験の反映
  • 運用監視とモニタリング機能

GenU がAIアプリの一般的なひな型だとすれば、源内Webは大規模組織での運用に耐える業務基盤まで踏み込んだ拡張になっている。この差分を読むだけでも、組織内AIプラットフォームを構築したい人にとっては教材として値打ちがある。

ライセンスは MIT が中心だが、一部の Lambda や CDK ファイルは Amazon Software License の対象になる。フォークして再配布するなら、ファイル単位のヘッダ確認が必要だ。

アプリ側 — digital-go-jp/genai-ai-api

行政実務向けAIアプリの実装が置かれているリポジトリ。言語比率は Python 44%、Bicep 25%、TypeScript 25%。Web側とはまったく異なるスタックで、ここにマルチクラウド前提の設計思想がはっきり表れている。

収録されているテンプレートは3つある。

  • AWS には行政実務用RAGの開発テンプレート
  • Azure にはLLMをセルフデプロイして利用する開発テンプレート。IaCは Bicep
  • Google Cloud には最新の法律条文を参照して回答する法制度AIアプリの実装

AWS、Azure、Google Cloud それぞれにサンプル実装が整理されているのは、率直にいって気合が入っている。自治体や企業の側では、手持ちのクラウド契約や調達制約によって採用候補が変わる。そこを政府が特定のクラウドに寄せろと押し付けないよう、意図的にフラットな構えで作られている。

特徴的なOSSポリシー

冒頭で触れた、PRを受け付けず Issue は致命的案件のみという方針は、従来型のOSSコミュニティの感覚からすると違和感を覚えるものだ。一緒に作ろうではなく、参照してくださいに近い。

ただ、政府OSSとしては筋が通っている。Pull Request を受け入れるということは、受け取った側が法的責任と運用責任を負うことを意味する。政府基幹システムに組み込まれるコードに、誰が書いたか分からない変更を取り込むのは、たしかに難しい。公開はするが統治は中央で、という姿勢を明示してくれるほうが、使う側としても判断しやすい。

国産LLM 7モデル選定という布石

源内のOSS公開と並行して、もうひとつ動いているのが国産LLMの選定プロセスだ。2026年3月、デジタル庁は15件の応募から7モデルを選定したと発表した。内訳は次のとおりで、名前を並べるだけで日本のLLMプレイヤーの現在地が見えてくる。

  • tsuzumi 2（NTTデータ）
  • CC Gov-LLM（カスタマークラウド）
  • Llama-3.1-ELYZA-JP-70B（KDDI・ELYZA共同応募体）
  • Sarashina2 mini（ソフトバンク）
  • cotomi v3（日本電気）
  • Takane 32B（富士通）
  • PLaMo 2.0 Prime（Preferred Networks）

選定基準は、国内で開発された大規模言語モデルで、開発経緯や開発方法が具体的に説明可能であること、そして行政実務で使える性能を持ち、デジタル庁のテストを通過していることだった。2026年度は無償で試用、2026年8月ごろから源内で順次稼働し、2027年4月以降の政府調達を視野に入れている。

この動きとOSS公開は無関係ではない。基盤はオープンにし、モデルは国産重視でという二段構えで、ガバメントAI全体の独立性を確保しにいっている。先行して導入された Preferred Networks の PLaMo Translation はすでに政府職員向けの提供が始まっており、翻訳という比較的評価しやすいタスクから実地データを集める段階に入っている。

海外の政府AIとの温度差

比較軸として、海外の政府AI事情に目を向けておきたい。国ごとに思想がかなり違っていて面白い。

シンガポールのPairは、政府職員向けチャットボットの先行事例だ。GovTech が開発し、トライアル開始から2ヶ月で100以上の政府機関、1万1,000人以上が利用したという。建設庁ではレポートレビューの時間を数時間から数分に短縮したと報告されている。源内の80%利用に近い浸透度で、日本とシンガポールはここでは似た立ち位置にいる。

エストニアのBürokrattは方向性がかなり違う。政府チャットボットでありながら、民間企業が自社サービスを統合できる仕組みを持っており、天候情報などは外部から提供されている。2026年以降は個別職員向けのAIエージェント化と、他国政府との相互接続まで視野に入れている。行政の内側にとどまらず、国境を越えたエコシステムとして設計されている点で、源内とは発想が違う。

日本の源内はシンガポール型の職員向け内製基盤を起点にしつつ、エストニア型のエコシステム志向を、今回のOSS公開で手前から試みているようにも読める。コードを開くことで、民間SIerや自治体が組み込みやすい状態を作り、少しずつエコシステム寄りに寄せていく狙いが見える。

民間SIerにとっての変化

この動きは、行政向けシステム開発を主業にしてきたSIerにとっては無視できない。自治体向けに独自の生成AI基盤を売る余地はこれまで十分にあったが、源内互換を語れるかどうかで、提案の意味が変わってくる。

現実的な構図は次のように整理できる。

  • フルスクラッチ型の提案は、差別化できる独自性がない限り厳しくなる。自治体側は、源内を参考にしてこの金額なのかと問える立場になる。
  • 源内の運用とカスタマイズ支援は新しい商売になりうる。そのまま動かすには手直しがいる以上、そこを埋めるコンサルや運用委託の需要は出てくる。
  • アプリ層での差別化は十分可能だ。法令、税務、福祉、教育といった業務特化のAIアプリは、政府の汎用基盤だけではカバーしきれない。

自治体のDX担当者からすれば、源内のこの機能は標準で入っていますが御社の提案には含まれていますか、というフラットな問いを投げられるようになったこと自体が大きい。ブラックボックスのなかで見積もりを受け取る時代から、少しずつ抜け始めている。

触る前に押さえておきたい注意点

現実的な落とし穴もいくつかある。

  • 公開されているのはアプリと基盤のコードで、LLM本体は含まれていない。動かすには Azure OpenAI や Amazon Bedrock、あるいは国産LLMを別途用意する必要がある。
  • 政府向けの脅威モデルと民間のそれは同じではない。コードを流用しても政府水準のセキュリティが自動的に引き継がれるわけではない。認証や監査ログ、秘匿情報の扱いは自組織の要件で設計し直すことになる。
  • ライセンスの混在もある。MITが中心だが、一部のファイルは Amazon Software License なので、再配布時はファイル単位で確認を。
  • コミュニティとの付き合い方にも注意がいる。PRが受け付けられない以上、独自拡張は基本的にフォーク側で管理することになる。本家への追随にはそれなりのコストが乗る。

独自の視点 — 参照実装としての政府OSS

今回の公開は、典型的なコミュニティ型OSSとも違えば、単なる成果物の公表とも違う、その中間に位置している。PRを受け付けない政府OSSは、参照実装、いわゆる reference implementation に近い姿をしている。自由に使っていいが、正典はあくまで中央にある。

この形が日本の行政に馴染む理由は、おそらくふたつある。ひとつは、法的責任のラインをぼかさずに済むこと。もうひとつは、自治体や企業が本家に合わせて作り直さなければいけないというプレッシャーから解放されることだ。源内のコードをそのまま使わなくていい。自組織の事情に合わせて切り貼りすればいい。本家は本家で独立して進む。

このやり方が上手くハマれば、今後ほかの政府OSSも似たポリシーで出てくる可能性は十分ある。法令APIやベース・レジストリの周辺、マイナポータル系のツールチェーン、自治体共通DBの周辺など、公開可能な素性を持つアセットはまだ残っている。源内のOSS公開は、日本的な政府OSSの型を作りにいった一手として捉えた方が、ニュース単体で見るより視野は広がる。

もうひとつ書いておきたい違和感がある。利用実績レポートの、課長級の半数が利用ゼロという数字は、OSS公開では動かない指標だ。コードを開いても、管理職がAIを触るようになるわけではない。ここは教育や人事評価、権限設計の領域で、技術OSSの射程外になる。源内というソフトウェアが、使える人のところにだけ届き、使えない人のところには届かないというリスクは、自治体に展開しても同じ形で再現されるはずだ。技術の話と組織の話を切り分けずに語ると、源内を入れたのに変わらないという結論に早晩ぶつかる。

最後に

公共機関のAIプロジェクトは、これまで外から中身の見えない箱だった。仕様書や調達資料は読めても、実際にどう動いているコードなのかは関係者以外には分からなかった。

源内のOSS公開は、そこに小さくない穴を開けた。自治体は重複開発から降りる選択肢を手にし、開発者は行政ドメインのRAGやマルチテナント設計を教材として手に取れる。民間SIerは源内互換という新しい会話のレイヤーを持ち、発注側はブラックボックスのなかで見積もりを受け取る状況から一歩抜けられる。

EastCloudでも、自治体や中堅企業向けの業務システム開発と生成AIの社内実装に日常的に取り組んでいる。源内のリポジトリは、日本の行政ドメインでRAGやマルチテナントをどう設計するかを考える上で、当面は重要な参照点になりそうだ。手元で動かしてみるなら、まず digital-go-jp/genai-web をクローンして docs/ を読むところから始め、次に genai-ai-api 側の AWS、Azure、Google Cloud テンプレートを目的に合わせて触ってみるのが現実的だろう。

ただし、OSSの公開だけで片付く話ではない。課長級の利用ゼロ問題、セキュリティ要件の再設計、運用人材の不足。ソフトウェアが手に入っても、組織が使いこなせるようになるかは別の話だ。そこが埋まって初めて、源内は政府が作った便利なコードから、日本の行政DXのインフラに昇格する。

国が作ったAI基盤を、個人や地方自治体が自分たちの土俵に引き込める段階に入った。使いこなせるかどうかは、ここからの動き方にかかってくる。

参考リンク

コメント

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

投稿をさらに読み込む