ガバメントAI、プロジェクト「源内」の構想紹介
デジタル庁でAIを担当している大杉直也です。2023年度からデジタル庁で生成AI関連のワークショップ等のイベントの企画や講師等を行なっており、2025年度からはガバメントAIの一環であるプロジェクト「源内」の立ち上げ、企画、開発運用、推進を担っています。
「100回の会議より、1回のAPI callの方が理解が進みます」「アイデアの価値は「検証」してみないとわからない」と、中央省庁の職員向けの生成AIワークショップの講義資料で書きました。これは当時から2年以上経過した2025年11月現在でも変わっていないと確信しています。しかし、生成AIの調達や利活用に係るガイドラインの作成等の進歩はありましたが、2025年11月現在でも一般職員にとって生成AIのAPI利用には多くの会議等を必要とし、なかなか気楽に試せないのが現実です。
一方で、この2年間で行政領域での生成AI利活用において何をすべきか、の検討は進んでおり、
行政固有の情報検索ニーズへの特化や、業務固有の参照情報を踏まえた、汎用型だけではない業務特化型の生成AI開発も必要である
生成AIの行政業務利用のニーズのヒアリングから簡単なプロトタイプの作成までは難しくはない。課題はその先にある「動く状態のプロトタイプを実際に職員に届ける」「それを業務の中で使ってもらい実践的な検証を行う」への移行の部分である
職員にとって安心・安全に使えるという環境が大事であり、特に実際の業務利用でほとんど必須な要機密情報の取り扱いが可能であることが最重要である
といった知見もこの2年間で得られました。
これらの知見を踏まえ、内製開発により、小さく始まったのが、プロジェクト「源内」です。源内の名前の由来は、生成AIを英語略称でGenAIと書くことから、と様々な生成AIアプリケーションの発明が集まって欲しいという願いを込めて、の2点からです。
自分の手元で作った業務特化の生成AIアプリケーションを、早く・安全に・簡単に実際の業務で使ってもらうために、基盤的なアプリケーションを作りました。これがないと、生成AIの業務活用の促進は非常にやりにくいと個人的にも日々実感しています。一例として、2025年8月に行った「子ども霞が関見学デー」で開催した「生成AIで学ぶ・考えるワークショップ」では源内を利用することで準備期間の短縮ができました。
プロジェクト「源内」では
業務特化の生成AIアプリケーションは追加開発しやすいように、ヒューマンインターフェースとは独立に開発可能
要機密情報を扱えるWebアプリケーション（ヒューマンインターフェース）の展開
そのWebアプリケーションでは業務特化の生成AIアプリケーションを追加し、職員がそれを気楽に試せる
の3点を最重要とし、開発を進めています。
2025年5月からデジタル庁全職員向けに展開し、開始3か月経過時点の利用実績について公開しました。2025年度末には希望する他省庁の職員への展開も視野に入れています。このプロジェクト「源内」は、直近のデジタル庁職員の生産性改善だけでなく、ガバメントAIの推進に対する課題の解決も視野に入れており、生成AIのサービス提供というよりも、技術検証の意味合いが大きいです。
ガバメントAIの推進に対する課題の仮説
2025年11月現在では、生成AI利活用に先行的に取り組んでいる自治体や省庁で、生成AIの業務利用に適したユースケースの発見や、それに伴う参照データの追加やワークフローの工夫等による特化型の生成AIアプリケーションについての成功事例が報告されるようになってきました。
日本全体で車輪の再発明のムダを減らし、行政領域に生成AIの恩恵を迅速に届けるためには、このような成功事例をしっかりと横連携していくことが大切だと考えています。
しかし、生成AIの成功事例の横展開にはいくつも壁があります。ここでは、他の組織での成功事例と自組織に取り入れるまでに4段階の課題があると仮定します。
段階1: 他の組織の成功事例を知らない
段階2: 他の組織での導入効果に不明瞭な点があり、コストをかけて導入する価値を見出せない
段階3: 同様の生成AIアプリケーションの導入方法がわからない
段階4: 同様の生成AIアプリケーションの導入方法がわかっても実現コストが高い。特にすでに他の生成AIサービスを利用している場合
このそれぞれの課題に対して、有効な打ち手を具体的に検討するのが、プロジェクト「源内」での技術検証の目的の一つです。
プロジェクト「源内」の技術検証の目的
プロジェクト「源内」では、いくつかの点で一定の共通化やルール整備を行えば、上述の4つの課題の解消につながるのでは、という仮説を立てています。
生成AIアプリケーションの「記述（ドキュメント）」についての共通化やルール整備。例えば以下のような観点が挙げられる。
AIエージェントの概要と機能
業務での具体的な効果（削減工数、コスト削減率など）とその算出方法
必要なデータ・外部システム
権利・セキュリティ上の懸念事項
運用費用（初期費用、月額費用など）
導入時の留意点
等
生成AIアプリケーションとヒューマンインターフェースとの間の「約束」についての共通化やルール整備。例えば以下のような観点が挙げられる。
生成AIアプリケーションとヒューマンインターフェースの間の通信のプロトコル
入出力の形式や項目、認証認可方法、非同期処理の実現方法等
ヒューマンインターフェースと生成AIアプリケーションの責務分離
ログ取得要件、主体認証はどこで行うか、個別の生成AIアプリケーションについての記述の情報の持ち方と利用者への表示方法等
ヒューマンインターフェース側の典型的なユーザーインターフェース（UI）の類型
チャット利用の場合、非同期かつファイル入力ありの場合、校正や翻訳の場合等で入力や出力のUIはどのようにあるべきか等
等
生成AIアプリケーションの「代表的な実装パターン」についての共通化やルール整備対象の例
複数のファイルの入出力が伴う場合
非同期処理で大量のデータ処理を伴う場合
マニュアル等の特定の種類の書類を参照する場合
AI側で自律再実行してさまざまな外部リソースにアクセスする場合
生成AIアプリケーションの記述についての共通ルールが整備されれば、検索性の高い状態で一覧性を高く保ちやすくなり、課題の段階1,2は軽減されると考えています。自組織が、成果をだした他組織と同じ「約束」に従うヒューマンインターフェースをすでに導入していれば、生成AIアプリケーション部分だけを調達（それもコピー構築やマルチテナント化等で安価かつ迅速に実現）すれば良くなるので、課題の段階3,4は大幅に軽減されると考えています。
また自組織で独自で構築する場合も、「代表的な実装パターン」が「記述」と関連する形で公開されていれば、同様の生成AIアプリケーションをまず試してみる、までの開発に対して再開発のムダを軽減できると期待しています。ここでの各種の共通ルールは利用者だけでなく開発者にとって使いやすいものであるべきで、業界標準とも整合性の取れた形で必要最小限のものを目指すべきだと考えています。
プロジェクト「源内」の進め方と展望
プロジェクト「源内」では、このヒューマンインターフェースと代表的な実装パターンの生成AIアプリケーションを、内製開発し、実際に職員に広く使ってもらうことで、さまざまな検討事項や実装上の工夫を明らかにします。そして、それらを解決することで、「記述」「約束」「代表的な実装パターン」のあるべき姿の解像度を上げていきます。十分にこれらの解像度があがったら、プロジェクト「源内」での技術検証の結果を公開し、多種多様なステークホルダーと協議をしながら、共通ルール化に向けた検討を行いたいと考えています。
とはいえ、このような協議の場をデジタル庁として設けるには、企業・産業界からの声や要望が寄せられることが不可欠です。また、共通ルールのドキュメンテーション作業には、民間からのボランティア参加も必要となります。企業・産業界の積極的な関与に期待しています。また、共通ルールの議論のための参照実装として広く使われるように、職員向けに展開しているソフトウェア（ヒューマンインターフェースも生成AIアプリケーションの実装方法も可能な限り全て）を商用利用可能なライセンスでの公開も検討中です。
これらが整備・公表されることで、例えば、調達仕様書を書く行政職員からすると業務固有の箇所といった最低限の記述だけで済むようになります。また、事業者も生成AIアプリケーションの根幹部分の開発にリソースを集中でき、行政領域でのAI利活用の市場自体の拡大につながるのではないか、という展望をもって進めています。また、デジタル庁のミッションである「誰一人取り残されない、人に優しいデジタル化を。」を実現した生成AIアプリケーションの実装を公開することで、行政・民間ともにアクセシビリティを意識したアプリケーションが広がることを期待しています。
プロジェクト「源内」では、行政領域の業務特化の生成AIアプリケーションの中で広く使われるものを実際に内製開発し、職員に展開していますが、これは業務特化の生成AIアプリケーションの全てをデジタル庁で内製開発しようという試みではありません。生成AIアプリケーションの「代表的な実装パターン」とは何かの検討や、それをヒューマンインターフェースで利用可能にする「約束」への反映、実際に職員に使ってもらう中で見えてきたあるべき「記述」の検討の具体的材料の獲得を目指しての活動です。
行政領域と一口でいってもさまざまな組織が多種多様な業務を行っており、大勢の人の創意工夫と努力なしでは、ガバメントAIと呼ぶべき行政領域での利便性の高いAIの開発や定着は困難だと考えています。人口減少と少子高齢化による担い手不足が深刻化する我が国において、公共サービスを維持・強化するためには、政府および地方公共団体の生成AIをはじめとするAIの積極的な利活用が不可避です。その中で、デジタル庁は共通ルール整備に向けた技術検討と、その検討過程や参照実装を広く世に公開することで、行政領域のAI利活用がより一層促進されることを狙っています。
最後に求人票の宣伝
デジタル庁では、「源内」の内製開発に特化したポジションを募集しています。実際にAI（特にテキスト生成AI）を活用し、行政の業務改善・効率化の実現を通して、データとAIにより何ができるかの実証を職務とする役割を担っていただきます。
付録（検討中の技術詳細）
2025年11月現在の源内のシステム構成や、デジタル庁で追加開発した生成AIアプリケーション（行政実務用AIアプリ）との間の「約束」についての技術的な記載を載せます。このシステム構成や「約束」はまだまだ試行錯誤中ですし、今後大きく変わる可能性があります。特に「約束」に関しては2024年末あたりに決め打ちで作ったものなので、業界標準の調査やAI開発事業者等との協議の結果、改良していきたいと考えています。
Amazon Web Servicesの改変可能なオープンソースのGenerative AI Use Cases (GenU)に(1)外側にマイクロサービスとして構築した生成AIアプリケーションの追加・実行と、(2)それらAIアプリケーション(画面上はAIアプリと表記)の認可管理を行うためのチーム機能を追加開発したものをデジタル庁では利用しています。
展開初期では行政実務用AIアプリが不足しており、まず職員が汎用的な生成AI利活用ができるように、初期状態でいくつかの生成AI機能が実装されていたGenUを改変する、という技術選定を行いました。行政実務用AIアプリは独立した環境で構築されたマイクロサービスで良いため、AWSに限定されることなく、例えばデジタル庁ではGoogle CloudのGeminiを用いた行政実務用AIアプリが源内上で実行可能となっています。
ここで名前、概要、使い方の箇所に記載されたテキストは以下のように利用者に表示されます。
APIリクエストのデータ形式(JSON)の記述から、利用者向けの実行画面が自動生成されます。
行政実務用AIアプリのAPIリクエストのデータ形式は以下のように定義されます。
## `行政実務用AIアプリ` のリクエスト形式定義
源内Webインターフェースは、行政実務用AIアプリとして外部のREST APIを呼び出すことが可能です。
このページは、「チーム管理」メニューから行政実務用AIアプリを登録する際に「リクエスト形式」に登録するJSONのフォーマットを解説しています。
## Request Format
### 行政実務用AIアプリに定義するリクエスト形式
リクエスト形式は辞書形式で表現し、APIに送出するリクエストのキーを辞書のキーとして設定します。
```:json
{
"Request-key1": <request-definition>,
"Request-key2": <request-definition>,
....
}
```
`<request-definition>` には以下のコンポーネントのいずれかを設定してください。
- [テキストフィールド](#テキストフィールド)
- [数値フィールド](#数値フィールド)
- [テキストエリア](#テキストエリア)
- [ファイル](#ファイル)
- [セレクトボックス](#セレクトボックス)
- [チェックボックス](#チェックボックス)
- [ラジオボタン](#ラジオボタン)
- [hidden](#hidden)
### テキストフィールド
#### 記述例
```:json
"Request-key": {
"type": "text",
"title": "ラベルに表示されるタイトル",
"desc": "フィールドの説明文",
"required": true,
"min_length": 10,
"max_length": 1000,
"default_value": "デフォルト値"
}
```
#### パラメータ一覧
- title
- 必須
- 文字列
- desc
- 任意
- 文字列
- required
- 任意
- 真偽値（true or false）
- 指定しなかった場合、任意コンポーネントとして扱われます
- min_length
- 任意
- 数値（負の値は設定できません）
- max_length
- 任意
- 数値（負の値は設定できません）
- default_value
- 任意
- 文字列
### 数値フィールド
#### 記述例
```:json
"Request-key": {
"type": "number",
"title": "ラベルに表示されるタイトル",
"desc": "フィールドの説明文",
"required": true,
"min": 10,
"max": 1000,
"default_value": 100
}
```
#### パラメータ一覧
- title
- 必須
- 文字列
- desc
- 任意
- 文字列
- required
- 任意
- 真偽値（true or false）
- 指定しなかった場合、入力が任意のコンポーネントとして扱われます
- min
- 任意
- 数値（負の値は設定できません）
- max
- 任意
- 数値（負の値は設定できません）
- default_value
- 任意
- 数値
### テキストエリア
#### 記述例
```:json
"Request-key": {
"type": "textarea",
"title": "ラベルに表示されるタイトル",
"desc": "フィールドの説明文",
"required": true,
"min_length": 10,
"max_length": 1000,
"default_value": "デフォルト値"
}
```
#### パラメータ一覧
- title
- 必須
- 文字列
- desc
- 任意
- 文字列
- required
- 任意
- 真偽値（true or false）
- 指定しなかった場合、入力が任意のコンポーネントとして扱われます
- min_length
- 任意
- 数値（負の値は設定できません）
- max_length
- 任意
- 数値（負の値は設定できません）
- default_value
- 任意
- 文字列
### ファイル
#### 記述例
```:json
"Request-key": {
"type": "file",
"title": "ラベルに表示されるタイトル",
"desc": "フィールドの説明文",
"required": false,
"accept": "image/png,image/jpeg",
"multiple": true,
"max_size": "4.5MB",
}
```
#### パラメータ一覧
- title
- 必須
- 文字列
- desc
- 任意
- 文字列
- required
- 任意
- 真偽値（true or false）
- 指定しなかった場合、入力が任意のコンポーネントとして扱われます
- accept
- 任意
- 文字列
- 仕様は https://developer.mozilla.org/ja/docs/Web/HTML/Reference/Attributes/accept を参照してください
- multiple
- 任意
- 真偽値（true or false）
- 1つのフィールドで複数のファイルを送信したい場合は true を設定してください
- max_size
- 任意
- 文字列
- KB, MB, GBのいずれかを指定してください
- 添付ファイルのサイズ制限
### セレクトボックス
#### 記述例
```:json
"Request-key": {
"type": "select",
"title": "ラベルに表示されるタイトル",
"desc": "フィールドの説明文",
"required": false,
"items": [
{ "title": "タイトル1", "value": "value1" },
{ "title": "タイトル2", "value": "value2" },
],
"default_value": "value2"
}
```
#### パラメータ一覧
- title
- 必須
- 文字列
- desc
- 任意
- 文字列
- required
- 任意
- 真偽値（true or false）
- 指定しなかった場合、入力が任意のコンポーネントとして扱われます
- items
- 必須
- `{ "title": "", "value": "" }` 形式
- default_value
- 任意
- 文字列 / 数値
### チェックボックス
#### 記述例
```:json
"Request-key": {
"type": "checkbox",
"title": "ラベルに表示されるタイトル",
"desc": "フィールドの説明文",
"required": false,
"items": [
{ "title": "タイトル1", "value": "value1" },
{ "title": "タイトル2", "value": "value2" },
],
"default_value": "value2"
}
```
#### パラメータ一覧
- title
- 必須
- 文字列
- desc
- 任意
- 文字列
- required
- 任意
- 真偽値（true or false）
- 指定しなかった場合、入力が任意のコンポーネントとして扱われます
- items
- 必須
- `{ "title": "", "value": "" }` 形式
- default_value
- 任意
- 文字列 / 数値
- デフォルトでチェックされるのは現状1つまでで、将来的に複数の値をデフォルトでチェック可能にします
### ラジオボタン
#### 記述例
```:json
"Request-key": {
"type": "radio",
"title": "ラベルに表示されるタイトル",
"desc": "フィールドの説明文",
"required": false,
"items": [
{ "title": "タイトル1", "value": "value1" },
{ "title": "タイトル2", "value": "value2" },
],
"default_value": "value2"
}
```
#### パラメータ一覧
- title
- 必須
- 文字列
- desc
- 任意
- 文字列
- required
- 任意
- 真偽値（true or false）
- 指定しなかった場合、入力が任意のコンポーネントとして扱われます
- items
- 必須
- `{ "title": "", "value": "" }` 形式
- default_value
- 任意
- 文字列 / 数値
### hidden
見た目上には表示されないコンポーネントです。
内部的に送っておく必要のあるパラメータがある際に利用してください。
#### 記述例
```:json
"Request-key": {
"type": "hidden",
"default_value": "value"
}
```
#### パラメータ一覧
- default_value
- 必須
- 文字列 / 数値
## 会話履歴（疑似チャット）
会話履歴はAPI定義のJSONに conversation_history というキーを入れ込むことで可能になります。 ※ conversation_history 自体はUIとして表示はされません。
title等の入力は不要ですが、分かりやすくするために入れることを推奨します。 このキーを入れると実行結果および履歴に「会話を続ける」ボタンが表示されて過去の情報を保持してやり取りが可能になります。
過去の情報をどのように保持すれば良いかはAIアプリ側の実装にも依存するため、保持方法について源内のWebインターフェースでも何パターンか用意しておきます。
```:json
{
"question": {
...
},
"conversation_history": {
"title": "会話履歴",
"desc": "過去の会話履歴を入力することで、その内容を参照した回答を生成できます",
"type": "textarea"
}
}
```
## サンプル
```:json
{
"question": {
"title": "入力",
"desc": "質問したい内容を入力してください。",
"type": "text",
"required": true,
"default_value": "デフォルト値"
},
"content": {
"title": "コンテンツ",
"desc": "マークダウンでコンテンツを入力してください。",
"type": "textarea"
},
"step": {
"title": "number inputの例",
"type": "number",
"required": true,
"min": 10,
"max": 1000,
"default_value": 20
},
"file": {
"title": "添付ファイル",
"type": "file",
"accept": "image/*"
},
"prefecture": {
"title": "都道府県",
"type": "select",
"items": [
{"title": "東京都", "value": "13"},
{"title": "神奈川県", "value": "14"}
]
},
"fruits": {
"title": "フルーツ",
"type": "checkbox",
"items": [
{"title": "りんご", "value": "apple"},
{"title": "ばなな", "value": "banana"},
{"title": "ぶどう", "value": "grape"}
]
},
"gender": {
"title": "性別",
"type": "radio",
"items": [
{"title": "男性", "value": "1"},
{"title": "女性", "value": "2"}
]
}
}
```
## 送出されるリクエスト
上記のサンプルを定義すると、源内WebアプリはAIアプリに対し以下のようにリクエストを送出します。
inputs配下のリクエストを取得して処理するようAPIを実装してください。
```
{
"inputs": {
"question": "デフォルト値とは何ですか？",
"content": "コンテンツコンテンツ\nコンテンツ",
"step": 35,
"files": [
{
"key": "key名",
"files": [
{
"filename": "ファイル名",
"content": "base64データ",
},
{
"filename": "ファイル名",
"content": "base64データ",
}
]
},
{
"key": "key名",
"files": [
{
"filename": "ファイル名",
"content": "base64データ",
},
{
"filename": "ファイル名",
"content": "base64データ",
}
]
},
],
"prefecture": 13,
"fruits": "apple,banana",
"gender": 1
}
}
```
### 注意点
- 数値は `""` で囲んだとしても、文字列ではなく数値として送られます。
- true / false は `""` で囲んだとしても、 真偽値（true/false）として送られます。
- チェックボックスで複数選択した場合、`"a,b,c"` のようにカンマ区切りの文字列として送られます。
- チェックボックスで単数選択した場合は, `"a"` のようにカンマなしの文字列として送られます。
- ファイルはBase64化されたコンテンツが送られます。
- ファイルのサイズがmax_size未満だとしても、Base64変換後の値でバリデーションされるため注意が必要になります。
## Response Syntax (同期処理の場合)
源内Webインターフェースは、行政実務用AIアプリへのリクエストのResponseとして以下の形式を期待します。
outputsの値であるテキストは源内Webインターフェースのフロントエンドで処理されます。
テキストデータにはMarkdown記法を含めることが可能です。
```
{
"outputs": "xxxxxxxxxxxxxxxxxx"
}
```
行政実務用AIアプリを非同期実行する場合は、以下のような仕様にしています。
**リクエスト例1: テキストのみ**
```bash
# デプロイ時の出力に置き換えてください
URL="YOUR_INITIAL_REQUEST_URL" # /requests で終わるURL
API_KEY="YOUR_API_KEY"
# 送信するデータ。必ず "inputs" キーでラップすること。
# この形式は後述のカスタマイズポイントで定義します。
DATA='''{
"inputs": {
"question": "日本の歴史について、500文字程度で要約してください。",
"max_length": 512
}
}'''
curl -v -X POST \
-H "Content-Type: application/json" \
-H "x-api-key: ${API_KEY}" \
-d "${DATA}" \
"${URL}"
```
**リクエスト例2: ファイルを含む場合**
ファイルは `inputs.files` に `{"任意のキー": {"contents": "...", "filename": "..."}}` の形式で含めます。`contents` はBase64エンコードされた文字列です。
```bash
# デプロイ時の出力に置き換えてください
URL="YOUR_INITIAL_REQUEST_URL"
API_KEY="YOUR_API_KEY"
# Base64エンコードされたファイルコンテンツ (例: "hello world"というテキスト)
FILE_CONTENTS=$(echo -n "hello world" | base64)
# 送信するデータ
DATA='''{
"inputs": {
"question": "このファイルの内容を要約してください。",
"files": [
{ "key": "source_document"
"contents": "'${FILE_CONTENTS}'",
"filename": "input.txt"
}
]
}
}'''
curl -v -X POST \
-H "Content-Type: application/json" \
-H "x-api-key: ${API_KEY}" \
-d "${DATA}" \
"${URL}"
```
**レスポンス (202 Accepted):**
リクエストが正常に受け付けられると、以下のレスポンスが返ります。
```json
{
"outputs": "リクエストを受け付けました",
"request_id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
"status": "PENDING",
"status_url": "/status/a1b2c3d4-e5f6-7890-1234-567890abcdef"
}
```
### ステータス確認 (ポーリング)
上記で受け取った `request_id` を使って、処理のステータスを問い合わせます。
```bash
# デプロイ時の出力に置き換えてください
URL="YOUR_STATUS_CHECK_URL_BASE" # /status/ で終わるURL
API_KEY="YOUR_API_KEY"
REQUEST_ID="a1b2c3d4-e5f6-7890-1234-567890abcdef"
STATUS_URL="${URL}${REQUEST_ID}"
curl -X GET \
-H "Content-Type: application/json" \
-H "x-api-key: ${API_KEY}" \
"${STATUS_URL}"
```
**レスポンス (処理中):**
`status` は `PENDING` または `IN_PROGRESS` となり、`progress` フィールドで進捗状況を確認できます。
```json
{
"created_at": "2025-08-06T10:00:00.123Z",
"progress": "処理中... ステップ 3/5",
"request_id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
"status": "IN_PROGRESS",
"updated_at": "2025-08-06T10:02:30.456Z"
}
```
**レスポンス (処理完了時):**
`status` が `COMPLETED` になると、`outputs` (テキスト形式の出力) と `artifacts` (ファイル形式の出力) が含まれます。`artifacts` 内のファイルコンテンツはBase64エンコードされています。
```json
{
"artifacts": [
{
"contents": "JVBERi0xLjAKMSAwIG9iago8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFI+...",
"display_name": "dummy-report.pdf"
}
],
"created_at": "2025-08-06T10:00:00.123Z",
"outputs": "This is a dummy output for question: '日本の歴史について、500文字程度で要約してください。'",
"progress": "処理が完了しました。結果を保存しています...",
"request_id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
"status": "COMPLETED",
"updated_at": "2025-08-06T10:05:00.789Z"
}
```
**レスポンス (エラー発生時):**
`status` が `ERROR` になり、`error` フィールドにエラーの詳細が含まれます。
```json
{
"created_at": "2025-08-06T10:00:00.123Z",
"error": {
"details": "Required resource not found.",
"message": "An error occurred during processing."
},
"request_id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
"status": "ERROR",
"updated_at": "2025-08-06T10:03:00.500Z"
}
```非同期実行の出力結果は個別のAIアプリの利用履歴から確認ができます。
ここで紹介した画面や仕様は、デジタル庁で展開しているものではありますが、これらをそのまま共通ルールにするつもりは全くなく、さらなる検討や検証、調査や協議が必要であるという認識です。我々の検討したい内容についての具体例のひとつとして提示しました。種々の個別具体の課題に対し、実際に開発・運用してみないとわからないことも多数あるため、デジタル庁では地に足のついた議論を行うべく、自分たちでも開発・運用をしながらプロジェクト「源内」を進めていきます。
参照した関連記事一覧（時系列順）
