デジタル庁OSS『源内Web』が解こうとしている4つの課題｜地方DX担当が読み解く設計思想

2025年11月、デジタル庁がプロジェクト「源内」のWebインターフェース部分をOSSとしてGitHubに公開しました。2026年4月24日にはv1.0.3がリリースされており、少しずつアップデートが続いています。

やまと

私は地方中小の製造業でDX推進担当として、社内向けの業務システムをゼロから内製しています。「業務特化の小さなAIアプリを、組織内に安全に・たくさん並べて配る」というテーマは、行政も民間も同じ悩みどころです。公式READMEとデジタル庁のnoteを読んでみたら、「共通基盤とは何なのか」を真面目に考えている筋の良いプロジェクトだったので、エンジニア視点で整理して紹介します。

源内Webとは何か

ざっくり言うと「行政職員向けの生成AIアプリ共通プラットフォーム」

源内（GenAI）は、デジタル庁が開発・運用している生成AI利活用基盤で、「源内Web」はそのヒューマンインターフェース部分にあたります。行政職員が業務特化の生成AIアプリを、安全に・簡単に業務で使えるようにする共通のWebアプリ、という位置づけです。

技術構成の特徴は次の通りです。

• ベース: AWS製OSSの Generative AI Use Cases（GenU）をフォークして大幅改変
• 実装言語: TypeScriptが大半（GitHub上の言語比率は約99%）
• ライセンス: MIT（ソフトウェア）／ CC BY 4.0（ドキュメント）
  ※ AWS Prototyping Programで作成された一部のLambda・CDKファイルはAmazon Software License対象
• 展開実績: 2025年5月からデジタル庁全職員向けに展開開始。2025年度末には他省庁職員への展開も視野

GenU（AWS製OSS）から何を変えたのか

公式READMEで明記されている主な変更・追加点は5つです。

また、庁内アクセシビリティチームによるアクセシビリティ試験が実施されている点も、行政プロダクトらしい特徴です（ただし一部ページには課題が残存していると明記されています）。

なお、GenU本家とは独立した開発方針をとっており、「GenUの行政版」ではなく、GenUを出発点にした別物、と捉えたほうが正確です。

源内Webが解こうとしている4つの課題

ここが個人的に一番面白い部分です。デジタル庁のnote記事では、「成功事例の横展開を阻む4段階の壁」という仮説が提示されています。

「他組織の成功事例を自組織に持ち込めない」4段階の壁

他の組織で生成AIの成功事例が出ても、自組織に取り入れるまでには段階的な障壁がある、という整理です。

やまと

製造業のDXでも全く同じ構造があります。「他社のAI活用事例はカンファレンスで聞くけれど、自社に持ち込もうとすると要件定義・PoC・本番移行で力尽きる」という流れです。行政も民間もここは共通だな、と読みながら何度も頷きました。

源内が仕掛けている3つの打ち手（記述・約束・実装パターン）

この4段階に対して、源内Webは次の3つの共通化・ルール整備を試験的に行っています。

• ①「記述（ドキュメント）」の共通化
  AIアプリの概要、効果、必要データ、権利・セキュリティ、運用費用、導入時の留意点などの書き方を揃える。これで段階1・2（知らない／価値が見えない）を軽減する狙い。
• ②「約束（プロトコル）」の共通化
  Webインターフェースと個別AIアプリ間の通信プロトコル、責務分離、UI類型を揃える。同じ「約束」に従う別組織のAIアプリを、アプリ部分だけコピーすれば動かせる、という世界を目指す。段階3・4の軽減。
• ③「代表的な実装パターン」の共通化
  複数ファイル入出力、非同期大量処理、マニュアル参照、自律再実行など、典型パターンのリファレンス実装を用意する。ゼロから車輪を再発明しなくて済む状態を作る。

つまり源内Webは、「AIアプリのApp Store」ではなく、「行政AIアプリ界の共通ルールを実地で試すための参照実装」という位置づけです。noteでは「生成AIのサービス提供というよりも、技術検証の意味合いが大きい」と明言されています。

技術アーキテクチャの要点

ここから技術者目線で一段掘り下げます。業務システムを内製する立場で参考になる設計判断が多く、読み応えがあります。

ヒューマンインターフェースとAIアプリの分離（マルチクラウド前提）

源内のキモは、画面（源内Web）と業務特化AIアプリがマイクロサービスとして完全に分離していることです。

職員（ブラウザ）
  ↓
源内 Web（ヒューマンインターフェース）
  ↓  REST API / JSON
  ├─ 行政実務用AIアプリ A（例: AWS Bedrock）
  ├─ 行政実務用AIアプリ B（例: Google Cloud Gemini）
  └─ 行政実務用AIアプリ C（独自実装）

この分離によって、AIアプリ側はAWSに縛られません。実際、デジタル庁内ではGoogle CloudのGeminiを使った行政実務用AIアプリも源内上で動いている、とnoteに明記されています。マルチクラウド前提で設計されているのは、行政システムとしてかなり現実的な判断だと感じます。

業務システムを内製する立場で言うと、「UIを持つ共通基盤」と「ロジックを持つ業務アプリ群」を分けておくと、後でベンダー切り替え・モデル差し替えが桁違いに楽になります。源内WebはそれをAPI契約の標準化でやろうとしている、と読めます。

AIアプリの入力UIをJSONで定義できる（フォーム自動生成）

個人的に最も「おっ」と思ったのがこの部分です。AIアプリを登録するときに、リクエスト形式のJSONを書くだけで、利用者向けの入力フォームUIが自動生成される仕組みになっています。

サポートされる入力コンポーネントは次の通りです（公式仕様ベース）。

たとえば、テキスト入力と都道府県セレクトボックスを持つAIアプリは、こんなJSONで定義できます。

{
  "question": {
    "title": "入力",
    "desc": "質問したい内容を入力してください。",
    "type": "text",
    "required": true,
    "default_value": "デフォルト値"
  },
  "prefecture": {
    "title": "都道府県",
    "type": "select",
    "items": [
      { "title": "東京都", "value": "13" },
      { "title": "神奈川県", "value": "14" }
    ]
  }
}

この定義を登録すると、源内Web側がフォームを描画してくれて、ユーザーが入力した値は inputs キーでラップされたJSONとしてAIアプリのAPIにPOSTされます。

{
  "inputs": {
    "question": "デフォルト値とは何ですか？",
    "prefecture": 13
  }
}

要は「UIを持たないREST API」を書けば、UIは源内Webが面倒を見てくれる、という構造です。AIアプリ開発者は画面のことを忘れてロジックに集中できる。業務系のプロトタイピング体験としてはかなり良い設計だと思います。

同期・非同期の両対応（ステートマシン管理）

レスポンス形式も仕様化されています。

• 同期処理: {"outputs": "テキスト"} を返す。Markdownも解釈される
• 非同期処理: 202 Accepted と request_id を返し、クライアント側がステータスURLをポーリング。完了時には outputs（テキスト）と artifacts（Base64エンコードされたファイル群）が返る

進捗は4段階のステートマシンで管理されます。

大量ファイル処理や時間のかかる処理を、UXを壊さず業務フローに乗せるための工夫が入っています。「とりあえず202で返して、結果はポーリングで取りに来てね」という割り切りは、行政システムでも普通に必要になる設計です。

チーム機能による認可管理（OSSの元ネタには無い独自追加）

AIアプリの認可は「チーム」という単位で行われます。これは公開OSSの元ネタ（GenU）には無い、源内独自の追加機能です。詳細は公式のチーム管理権限表にまとまっています。

要機密情報を扱うことを前提にしているからこそ、「誰がどのAIアプリを使えるのか」の制御を単体機能として持っているのは納得感があります。社内導入を考えるときも、ここの権限設計は絶対に外せないポイントです。

地方DX担当として「ここは盗みたい」4つのポイント

ここからは業務システム内製者の視点で、源内Webから学べると感じた点を4つに絞って紹介します。

①「UIを生成する汎用API仕様」を業務側で先に決めるという発想

JSON Schema風のフォーム定義DSLは世の中にいくつもありますが、「業務特化AIアプリを組織内に並べる」という具体の課題設定で、入力・出力・非同期処理まで含めて仕様化している実例は貴重です。

自社で複数の業務アプリを内製していると、「画面の作りが各アプリでバラバラ」という問題が必ず出てきます。源内Webのように「API契約だけ標準化して、UIは共通基盤で吸収する」という方針は、少人数の内製チームでもスケールさせる現実解として強く参考になります。

②アクセシビリティを最初から設計に入れている

デジタル庁のミッション「誰一人取り残されない、人に優しいデジタル化を」を反映し、JIS X 8341-3:2016 適合レベルAA相当を判定基準に据えています。Issueで受け付ける報告対象にも「アクセシビリティ上の重大な障壁」が明記されており、後付けではなく設計原則として組み込まれています。

民間の業務システムでも、キーボード操作のみで完結するか・スクリーンリーダーで読み上げ可能かは、現場のオペレーターの作業効率に直結します。「最初から入れておけばコストは小さい、後から入れると倍以上かかる」典型例なので、内製プロジェクトの初期から組み込みたいポイントです。

③Issue／PR の受付方針を最初に明示している

これは運用面で地味に重要なポイントです。READMEには次が明記されています。

• PRは受け付けない
• Issueは致命的な問題のみ受付（データ損失、サービス不能、法令違反、アクセシビリティの重大障壁）
• 機能要望、軽微な表示崩れ、使い方の質問などは受付対象外

「OSSとして公開する ≠ コミュニティから集合知的に育てる」というスタンスを明確に示しているのは、運用負荷とサービスの安定性を天秤にかけた現実的な判断だと思います。個人開発でOSSを公開する人にとっても参考になる方針です。

④「技術検証プロジェクト」であることを公言している

noteに「生成AIのサービス提供というよりも、技術検証の意味合いが大きい」と明記されている通り、これは完成品ではなく「共通ルール策定のための実験台」です。

この立ち位置をちゃんと表明していることで、「なぜフィードバックを反映しづらいか」「なぜ今の仕様が将来変わり得るのか」が読み手に伝わります。「これは完成品です」と言いきらない誠実さは、社内の業務システム開発でも見習いたい姿勢です。

やまと

「これはまだ実験段階です」と言いきれる組織は、社内向けシステムでも強いです。正直に言うことで、関係者の期待値を正しい方向にコントロールできる。私もDX推進の場でよく経験します。

どうやって試す・読むか（実践入門）

フルデプロイするにはAWSアカウントとある程度のインフラ知識が必要ですが、公式ドキュメントが日本語で整備されているので、手順自体は追いやすいです。

自前でデプロイしなくても、ドキュメント（docs/ディレクトリ）を読むだけで学びが多いリポジトリです。特にAPI仕様書とアーキテクチャドキュメントは、社内向けの業務アプリ基盤を設計するときのリファレンスとして普通に役立ちます。

まとめ｜「業務特化AIアプリのUIと配布をまとめて面倒見てくれる、行政向けの参照実装」

源内Webを一言でまとめるなら、「業務特化AIアプリのUIと配布をまとめて面倒見てくれる、行政向けの参照実装」です。

「庁内ツールのソースコードが公開されている」というだけでもニュース性がありますが、本質はそこではなく、「行政AIアプリの“共通ルール”を実地で検証するための土台」として設計されている点です。民間の社内AIプラットフォームを作っている人、特にマイクロサービス＋フォーム自動生成でアプリをたくさん並べたい人にとっては、一度ドキュメントを読んでおく価値があります。

よくある質問

源内Webは個人や民間企業でも使える？

ライセンス上はMIT（ソフトウェア）／CC BY 4.0（ドキュメント）なので、個人・民間問わず利用は可能。ただし、AWS Prototyping Programで作成された一部のLambda・CDKファイルはAmazon Software Licenseの対象。商用利用や改変前にライセンス表記をリポジトリで必ず確認すること。動作にはAWSアカウントが必須で、運用コストも発生する。

本家GenU（AWS製OSS）と源内Webはどちらを採用すべき？

用途で分かれる。GenUは「AWSベストプラクティスを学びたい」「自社で改造前提」の場合に向く。源内Webは「複数の業務AIアプリを並べたい」「チーム単位で権限管理したい」場合に向く。両者は独立した開発方針なので、「源内＝GenUの上位版」ではない点に注意。マイクロサービス前提で複数AIアプリを並列運用したいなら源内のほうが参考になる。

なぜPRを受け付けない方針なのか？

READMEに明示されている通り、サービスの安定性と運用負荷を優先した判断と読める。行政システムは不特定多数からのコード取り込みを審査・管理するコストが大きい。「OSS公開＝集合知で育てる」という公式モデルではなく、「ソースコードの透明性確保」が主目的のOSS公開という割り切り。Issueも致命的な問題（データ損失・サービス不能・法令違反・アクセシビリティ重大障壁）に限定されている。

こうした公的OSSや一次情報を読み解く力はどこで身につく？

独学で訓練することも可能だが、体系的なレポート訓練の場がある環境のほうが早い。私の場合はサイバー大学のIT総合学部でレポート課題を4年間繰り返したことが、引用の作法・論旨と根拠の対応・一次情報の探し方を身につける土台になった。次セクションで詳しく書きます。

公的情報を読み解いてレポートにまとめる力は、どこで身につくか

ここまでが源内Webの内容紹介でした。最後に、こうした記事を書くために必要なスキルのほうにも触れておきたいと思います。

源内Webのような公的OSSを読み解いて自分の業務に活かす力 — これは「技術力」というより「情報リテラシー」そのものです。私が今こうして読み解けているのは、大学のレポート授業で叩き込まれた基本姿勢があるからです。

一次情報を取りに行く習慣（GitHub・公式note・公式ドキュメント）

同じプロジェクトでも、情報源によって得られる粒度が違います。私は必ず3つの層を分けて読むようにしています。

この順序を守るだけで、「ネットの記事を読んで分かった気になる」状態から、「自分の言葉で正確に説明できる」状態に変わります。今回の源内Webの紹介も、この4ステップを順番に踏んだ結果です。

引用の作法 — 出典URL・参照日・改変の有無を必ず書く

ブログにせよ社内レポートにせよ、引用の書き方が雑だと、信頼が一気に落ちます。私が大学のレポート授業で厳しく叩き込まれたのはこの3点です。

この3点を守るだけで、同じ内容でも記事の信頼度がワンランク上がります。逆にここを雑にやっている記事は、どれだけ内容が良くても「本当かな？」と読み手に疑われます。社内レポート・提案書でも全く同じです。

私がこの読み解き方を身につけた背景 — サイバー大学のレポート授業

正直な話、高校までは「URL貼って終わり」でレポートを出していたタイプです。
それが変わったのは、サイバー大学のIT総合学部で4年間でレポート課題に取り組んだ経験でした。

やまと

最初に提出したレポートで、「出典がない」「参考文献の書式が崩れている」「論旨と引用の対応関係が不明瞭」と細かく指摘されたのが本当に効きました。当時はキツかったけど、結果的に4年間で身についた最大の武器のひとつが、この「情報を取りに行き、整理し、自分の言葉で再構成する」一連の動作です。

サイバー大学のレポート授業で具体的に学べることを並べると、こんな感じです。

• 参考文献の書式（APA形式・著者名・発行年・URL・参照日の並び順）
• 主張と根拠の対応づけ（どの主張がどの出典から来ているのかを明示する書き方）
• 一次情報・二次情報の使い分け（公式ドキュメントを引くべき場面と、論文・統計を引くべき場面）
• 論理構造（序論・本論・結論）を読み手に伝わる順序で組み立てる訓練
• 添削とフィードバックのループ（指摘 → 修正 → 再提出を繰り返す経験そのものが財産）

これらは「IT技術」ではないけれど、IT技術を「業務に活かす」段階で必ず必要になる土台です。私が今、業務システム内製とブログ・Zenn記事の両方を続けられているのは、この土台があるからです。社会人で大学に入り直すかどうか迷っている方には、「卒業後に一番効いたのはレポート訓練だった」という1票として、私の経験をお伝えしておきます。

もっと詳しく知りたい方へ｜サイバー大学関連記事

サイバー大学について、卒業生としての具体的な体験は別記事で詳しくまとめています。気になる切り口から読んでみてください。

やまと

「行政DX × 公的OSS × 情報リテラシー」という今回のテーマと、サイバー大学のような社会人の学び直しは、表面のキーワードは違えど、「情報を読み解いて自分の業務に翻訳する力」を磨くという意味で同じ筋の話です。少しでもピンと来た方は、関連記事のどれかを覗いてみてください。

参考リンク

• digital-go-jp/genai-web（GitHub）
• ガバメントAI、プロジェクト「源内」の構想紹介（デジタル庁note）
• Generative AI Use Cases（GenU、AWS公式）
• デジタル庁デザインシステム