規制改革推進会議 デジタル・AI WG　第8回

規制改革推進会議 デジタル・ＡＩワーキング・グループ（第８回） 議事次第 令和８年４月１６日（木） １６時～１８時３０分 オ ン ラ イ ン 会 議 議題 政府情報システムの調達・開発等におけるＡＩ駆動開発の導入促進について 資料１ 資料２ 資料３ 一般社団法人日本ＩＴ団体連盟提出資料 富士通株式会社提出資料 株式会社ＮＴＴデータグループ提出資料 資料４ 資料５ 資料６ 資料７ 株式会社ROUTE06提出資料 株式会社Jitera提出資料 株式会社クオンティア提出資料 デジタル庁提出資料 資料８ 村上将一専門委員・村上文洋専門委員・住田専門委員提出資料

資料１ 一般社団法人 日本IT団体連盟 Copyright (C) 2026 一般社団法人日本IT団体連盟 All Rights Reserved. 無断引用・転載禁止 日本IT団体連盟について ITに関わる団体が一丸となって我が国の経済成長を実現すべく 2016年7月に発足した日本最大級のIT業界団体です。 60団体/約5,000企業/約400万人 加盟団体 加盟団体 加盟団体 加盟企業 加盟企業 加盟企業 加盟企業 加盟企業 加盟企業 ・ ・ ・ ・ ・ ・ 一般社団法人 日本IT団体連盟 会長 ・ ・ ・ Copyright (C) 2026 一般社団法人日本IT団体連盟 All Rights Reserved. 無断引用・転載禁止 川邊 健太郎 1 公共調達に関する政策要望 要望タイトル 概要 官公庁が発注する大規模システ 資格要件や支払要件が厳しく、中小企業の参入が難しいため、「JVでの ムの構築に地方 IT 企業が参画 入札参加」、「中小・地元企業への発注枠の設定」、「フェーズごとの 検収・支払」など中小企業が参画できる仕組みを整備してほしい する仕組みの整備 政府調達における工程別入札 制限について 入札公告期間の十分な確保／ 政府調達の期間設定について 技術的対話による企画競争参 加へのインセンティブ導入 付加価値を評価する評価基準 や契約形態について 現状存在する工程別の画一的な受注制限を見直し、より柔軟な運用を行うことで、 中小スタートアップ含めた多様な企業が上流工程の調達にも参画しやすくするべきと 考える。 事業者が十分な準備期間を確保できるよう、十分な入札公告期間を確保 してほしい 調達検討に参加しても、採用されなければそれまでに要したコストは全 て事業者の負担となるため、調達対応により発生するコスト分を報酬と して支弁してほしい 従来の入札価格と技術点という評価軸だけでなく、構築するシステムに よって将来的に創出できる付加価値を示した提案を高く評価してほしい Copyright (C) 2026 一般社団法人日本IT団体連盟 All Rights Reserved. 無断引用・転載禁止 2 官公庁が発注する大規模システムの構築に地方IT企業が参画する 仕組みの整備 【要望の理由・背景】 現在の入札制度では、資格要件、支払要件などが厳しく、結果として中堅・中小企業、地元企業の市場参入が難しい。 2023年3月にデジタル庁情報システム調達改革検討会より開示された「デジタル庁情報システム調達改革検討会最終報告書 簡易版」によると、中 小・スタートアップ企業等の参入機会拡大を実現するための取り組みとして、「技術力を有する多種・多様な企業の参入円滑化」および「DMP導 入検討」が計画されている。これにより、透明性、競争性などが向上され、中小を含めた多くの企業の参入障壁は下がることが見込まれる。 またベンダーロックインの排除についても計画されており、企業が公平に入札に参加できるようになることが期待される。しかし、中堅・中小企 業、地元企業の参入チャンスを増やすためには、今の計画に加え、より中小企業の現状に寄り添った施策が必要と考える。 これにより地方IT関連業者の創業増加及び技術の底上げを行い、地域ユーザーのDX推進及びセキュリティー対策などに寄与することが可能になる と考える。 【要望内容】 ①中小企業が連携して受注する仕組み作り JV制度及びJVでの入札が容易になり加速されるような入札資格制度の見直し。 ・JVでの入札資格取得を可能とする ・首都圏と地方企業でのJVを推奨し、その取り組みに補助金制度を設ける ②完全競争入札ではなく、地元及び中小企業に発注枠を設ける ③完成検収後決済ではなく、工事進行基準に準拠しフェーズ毎の検収を可能にし、支払いも検収に合わせて実行する ④開発期間中の政府融資制度などを創設する 根拠法令/関連予算/関連税制：地方自治法施行令第１６７条の５ Copyright (C) 2026 一般社団法人日本IT団体連盟 All Rights Reserved. 無断引用・転載禁止 3 政府調達における工程別入札制限について（１/2） 【要望の理由・背景】 デジタル庁は政府情報システムの整備及び管理に関する政府共通ルールとして「デジタル・ガバメント推進標準ガイドライン」 （令和6年5月31 日デジタル社会推進会議幹事会決定）をまとめており、その中の「入札参加資格に関する事項」として以下を明示している。 第３編 ITマネジメント 第6章 調達 2.調達仕様書の作成等 1) 調達仕様書の記載内容 ク 入札参加資格に関する事項 入札制限 透明性及び公正性並びに確実な契約履行等を確保するため、次のイ）からハ）までに掲げる者に対し、入札制限を定めるものとする。 イ) 各工程の調達仕様書の作成に直接関与した事業者は、透明性及び公正性の確保の観点から、当該調達案件の入札に 参加させないものとする。ただし、競争上何ら有利とならないと認められるときはこの限りでない。 （後略） 仕様書作成業務に直接的に携わっていない場合、または競争において有利とならないことが明確に認められる場合は、一連の関連する調達の 受託事業者であっても入札制限の対象ではないと示されている。 しかし、実際の各府省庁の政府調達では、これまでの慣習を踏襲し仕様書の作成有無に関わらず上流の工程（調査・計画・要件定義）を受 託した企業が後の工程（設計・構築・運用）の調達への参加を画一的に制限するケースが多く存在している。 このような画一的な受注制限は、上流工程事業者の責任感低下を招く可能性がある。下流工程への参画がないため、不適切な計画や要件 定義を作成しても責任を問われにくい状況が生じ、結果として下流工程事業者が無理な作業を強いられたり、低品質なシステムを納品せざるを 得ない事態を招く可能性がある。さらに、この制限によって、上流工程に優れたノウハウを持つ企業が下流工程に参加できず、効率的で生産性 の高いシステム開発が阻害される懸念もある。 (次頁に続く） Copyright (C) 2026 一般社団法人日本IT団体連盟 All Rights Reserved. 無断引用・転載禁止 4 政府調達における工程別入札制限について（2/2） 【要望内容】 高品質な政府情報システム開発のため、調達における公平性と生産性を両立させるべく、各府省庁の調達における「デジタル・ガバメント推進標 準ガイドライン」に即した入札制限の見直しを検討いただきたい。 現状存在する工程別の画一的な受注制限を見直し、より柔軟な運用を行うことで、中小スタートアップ含めた多様な企業が上流工程の調達に も参画しやすくするべきと考える。 例）上流工程（調査・計画・要件定義）の業務と、その後の工程の調達に係る仕様書作成の業務は別調達にするよう運用ルールを作成 する 例）上流工程（調査・計画・要件定義）の業務の仕様書に、次工程の受注制限の有無を必ず明記するよう運用ルールを作成する 例）仕様書の公平さを第三者的に担保する仕組みを検討する 根拠法令：デジタル・ガバメント推進標準ガイドライン Copyright (C) 2026 一般社団法人日本IT団体連盟 All Rights Reserved. 無断引用・転載禁止 5 入札公告期間の十分な確保/政府調達の期間設定について 【要望の理由・背景】 • 情報システム調達に関しては「政府調達手続に関する運用指針等について」（平成26年3月31日関係省庁申合せ）に基づき、規模に応じた調達期間等が設定さ れ運用されていると認識している。また、これら申合せのレビュー及びフォローアップを行うため、政府調達の自主的措置に関する関係省庁等会議が開催され、今後の政 府調達の運営に関する取組みについて議論されている。 • 上記においては、提案事業者に十分な準備期間が確保されるよう、調達期間は入札公告の日から入札書受領まで50日の期間を設けることとされているが、以下のよ うな場合があり、人材が限られる中堅・中小企業には特に対応が難しい状況となってしまう危惧がある。  政府調達においては、大型連休前（年末やお盆前）に入札等が公示され、連休明けに締切が設定されることがある。そのような場合、事業者としては提案準備 や入札準備期間の確保が難しく、提案品質を低下せざるを得なかったり、本来休暇となるはずの期間を使って準備をしなければならないことがある。  入札公告期間中には疑義照会の期間が設けられているが、照会に対する発注者からの回答が入札期限直前に開示され、提案事業者としては回答を受けてから 非常に短い期間での提案内容や見積内容の修正を対応しなければならないことがある。 • また、現在調達手続の合理化を図るため、事業者が不要と認めた場合の意見招請の省略や、期間の短縮についても検討されていると認識している。手続きの合理化 については柔軟な調達の実現のためにも必要な取組と考え本検討には合意するが、上記事項についても併せて考慮することで、より品質の高い提案の実現、働き方改革やワー クライフバランスの実現が可能になると考える。 【要望内容】 調達手続きの合理化の取組みと合わせ、提案品質の確保、また、政府でも推進されている働き方改革やワークライフバランスの観点から、調達の期間設定(入札公告～ 入札期限)につき、事業者の準備期間が十分に確保されるよう検討いただきたい。 1. 入札公告期間を営業日換算にする 2. 入札公告期間についても意見招請等で事業者から意見を招請した上で決定する 3. 予定していた疑義照会回答日を超過した場合、入札期限を延伸する 根拠法令：「政府調達手続に関する運用指針」（平成 26 年３月 31 日関係省庁申合せ） Copyright (C) 2026 一般社団法人日本IT団体連盟 All Rights Reserved. 無断引用・転載禁止 6 技術的対話による企画競争参加へのインセンティブ導入 【要望の理由・背景】 2020年度から施行されている政府調達における技術的対話による企画競争について、約120日にも及ぶ調達検討に参加した にも関わらず、採用されなければ調達対応に投資したコストがすべて事業者の負担となり、特にこのような負担をすることが難しい 中堅・中小企業やスタートアップ企業の参加への意欲を阻害する要因の一つとなっている。 【要望内容】 事業者が政府調達に参加するハードルを下げるために、事業者に対して調達対応に発生する工数分を直接報酬として支弁する 制度を導入いただきたい。 具体的には、技術的対話相手に指名された場合は官庁からの指示内容に対して工数を提示し、双方合意の上、官庁から事業 者に報酬が支払われる等の対応を検討いただきたい。 関連法令：デジタル社会の実現に向けた重点計画（令和5年6月9日 閣議決定） Copyright (C) 2026 一般社団法人日本IT団体連盟 All Rights Reserved. 無断引用・転載禁止 7 付加価値を評価する評価基準や契約形態について 【要望の理由・背景】 • • • • 現在の政府調達では、「完全定額契約」 (FFP: Firm Fixed Price) が主流であり、SLAのように基準とペナルティは設定されているものの、高 いパフォーマンスを発揮したものや付加価値を創出した取組みへのインセンティブは設定されていない。 一方、デジタル庁「情報システム調達改革検討会」の最終報告書※1でも言及されるアジャイル開発等においては、 疎結合なマイクロサービスを活用する等、開発段階から、構築後の柔軟なサービス改善や利用者の体験価値向上等を意識することが重要とな る。同じ要求仕様に対しても、実現方式によって将来的に創出できる付加価値に差異が生じるが、このような付加価値創出に対して、評価する 枠組み・指標は十分に整理されていないと認識している。 ※1.: デジタル庁情報システム調達改革検討会 最終報告書(本文) 上記のような付加価値の向上に繋がる取組みを評価・促進する仕組みとして、米国の政府調達では、過去にPBA(Performance Based Acquisition)を適用。PBAではインセンティブの基準として“パフォーマンス”、”納期”、”過去のパフォーマンス”等が設定されている。 また、現在ではGSA(米国調達庁)が示す指針「Digital Service Handbook」では、「Develop metrics that will measure how well the service is meeting user needs at each step of the service」と付加価値を向上させるための指標整備が推奨されている。 国内では、防衛省が2023年度より、納期管理で成果を出した企業に対しインセンティブを与え、営業利益として最大15％上乗せする取組み を適用している。 日本のITシステムに関する政府調達においても、 ①従来の入札価格と技術点という評価軸だけでなく、構築するシステムによって創出できる付 加価値を示した提案を高く評価すること、②契約形態においても事業者にシステム構築後も改善を促すインセンティブを設計することを通し、継 続的にシステム/サービスを進化させる仕組みを整備すべきではないか。これらの取り組みによって、政府調達にまだ参画したことがない企業に対し ても、政府調達案件のビジネスとしての魅力が向上し、多種・多様な企業の参入を促すことが可能になると考える。 【要望内容】 受発注者の双方にとって利のある関係性を強化すべく、従来の入札価格と技術点という評価軸だけでなく、構築するシステムによって創出できる付 加価値を示した提案を高く評価すべき。あわせて、SLA等のペナルティの設定だけでなく、事業者に付加価値を生み出すシステムを構築・改善する 動機付けを行うべく、契約形態においてCPIF（Cost Plus Incentive Fee Contract）のようなインセンティブを考慮すべき。 Copyright (C) 2026 一般社団法人日本IT団体連盟 All Rights Reserved. 無断引用・転載禁止 8

ૠ਑੝୓௓ਤভ৮ ॹ४ॱঝ‫؞‬AI ড‫ش‬य़থॢ‫ॢ؞‬ঝ‫ش‬উ ହ৥ৱમ 資料２ AIฌ৿৫৅भ਄ੌापणःथ 2026ফ4া16঩ ୕૒ৢઙૄভ঺ AI Innovation Centerশ ળি ஶয ঃঈজॵॡॺছথ५ইज़‫ش‬ও‫ش‬३ঙথম৖শ ᄌ ෥୬୙ © 2026 Fujitsu Limited ম঩भओହ৥৔ઍ‫ق‬10ী‫ك‬ 1. ਊ঺पउऐॊAIฌ৿৫৅भ਄ੌा໪ਏ zَTakane-Driven Initiativeُपणःथ‫ق‬ਰৣ‫ؚ‬TDI‫ك‬ zَAI-Driven Software Development Platformُपणःथ‫ق‬ਰৣ‫ؚ‬SDP‫ك‬ 2. ৆ਿੲਾ३५ॸ঒भ৹୸पउःथAIฌ৿৫৅॑ ௓ਤघॊ੠भ਋ୄ஍ટृ୳৒ୖ਻ © 2026 Fujitsu Limited 1. ਊ঺पउऐॊAIฌ৿৫৅भ਄ੌा໪ਏ ਊ঺উঞ५জজ‫ش‬५‫ق‬2026ফ2া17঩‫ك‬ পૠெ੉ୁঔॹঝَTakaneُ॑ણ৷ख‫ؚ‬९ইॺक़ख़॔भਏ੯৒ଝऊै ਝੑ‫ؚ‬ৰಎ‫ؚ‬੥়ॸ५ॺपநॊ৸ੵங॑AIग़‫ش‬४ख़থॺऋੈ৹ख ৰষघॊAIॻজঈথ৫৅੦ೕ॑৫৅ख‫ؚ‬ઈ৷৫઩ 2026ফ২রप১੝ਫपൣअୢ௜‫؞‬ষ৆ী৙৸67भ঵ர९ইॺक़ख़॔भ੝ఊपి৷ https://global.fujitsu/ja-jp/pr/news/2026/02/17-01 ੶঻ହ৥ভৱમ॑রੱपओງஂ ͤ঱੶URLभঌ‫ش‬४पൕൗ © 2026 Fujitsu Limited ३५ॸ঒৫৅॑૗୓घॊ AIॻজঈথ৫৅੦ೕ 2026ফ4া16঩ ୕૒ৢઙૄভ঺ ͤ୕૒ৢઙૄভ঺‫୕ؚ‬૒ৢJapanઙૄভ঺ऋ2026ফ2া17঩प ৰ઱खञ੶঻৅਀ହ৥ৱમऊै௷ხखञ৔ઍदघ‫؛‬ © 2026 Fujitsu Limited ୕૒ৢभহ঵૗୓भधऌ ३५ॸ঒৫৅भ౞ਟ॑ীऐॊ‫ؚ‬ৠ৒৓ऩॱ‫ॽش‬থॢএॖথॺ ऒोऽदभ३५ॸ঒৫৅ ऒोऊैभ३५ॸ঒৫৅ జਟ஑SI AI-driven SI • েਛAIણ৷पेॊেਓਙ਱঱ऋਤा੼ત଼ଥऋਸச • েਛAIभড়਌৲पेॉ‫ؚ‬൹௢਌଑भ৔ଲ৲ऋఁপ • ౐ෞऩ৫৅‫؞‬੝ఊम‫ؚ‬હਸ੼க॑েापऎः୩ୠ • ૼ୒৭৒‫شॶ؞‬ঝ૛ऋ੔ষख‫୷ؚ‬શ৲ऋ൑୔ • ୕૒ৢभৗञऩ઀୹੼கम‫ؚ‬ಓ౵৓ऩ५আ‫ॻش‬ ‫ق‬Time to Market‫ك‬धಲਢ৓ऩిૢৡ • AI-Ready Engineering ¼ AIॻজঈথ৫৅੦ೕ • AIधযऋ૽સী૿ख‫ؚ‬஺మ৓पAI਌଑षਤ৲घॊ १‫ش‬অ५ঔॹঝ 5 ୕૒ৢऋරिसऌ౞ੰৠ୩ୠ AIऋःऽटੰऐऩःَളහऩใோ३५ॸ঒भ৶ੰधঽ৿੝ఊُपරि Takane-Driven Initiative ਊ঺ঊঝ५ॣ॔‫؞‬ষ৆ঃॵॣ‫ش‬४ଲષ॑ৌ଴प‫ؚ‬১਑২੝ਫৎभ३५ॸ঒੝ఊ॑ ਏ੯৒ଝऊै੥়ॸ५ॺऽदAIद঳ਞৢฮपঽ৿৲घॊ਄ॉੌा ঊঝ५ॣ॔ ষ৆ ୰੹ृ൧௜ਚ਱ऐपਗ਼৕ढ़ঝॸ॑ রੱधखञୢ௜ੲਾ३५ॸ঒ ঽ੘৬਱ऐपઘਜ‫ؚ‬કড়ੲਾ‫ૣؚ‬ක‫ؚ‬ ৕୘थऩन்ઁः঵ਜपৌૢ 30 ঃॵॣ‫ش‬४ 37 ঃॵॣ‫ش‬४ 6 ऩछ‫ؚ‬ঊঝ५ॣ॔‫؞‬ষ৆ऩभऊ ১਑২੝ਫप୯ྖघॊَ૗৲खਢऐॊೋপ३५ॸ঒ُभ੝ఊम‫ؚ‬ਈ୔ঢ়୩ୠ ਠৃ଀૿॑੖ैख‫঺ؚ‬ভभ੦ೕ॑ૃीऩः‫੅ؚ‬ਢ૭ચऩઈ৷ष ঺ভ୭୆भ૗৲षभৌૢ धखथभ১਑২੝ਫ ଒ैोञ਋৑दৗ਑২ षभৌૢऋ૑ਏ ਑২भ੗஘৲पेॊ ३५ॸ঒भളහ৲ ১਑২भ஺మ৓ऩถ಍৲ध ৫৅प૑ਏऩ਋৑भਂଌ • ൧௜ਾີ੝৒ऩन৒਋৓ऩ ੝৒पਸइ‫঺ؚ‬ভୖ਻ੰৠ प਱ऐञ১੝ਫऋ੺ফੜਸ • ১਑২भੰ๸म૙৩दुਫ નप৶ੰखৌૢघॊऒधऋ ൑୔ • ಢ਋৑दभৌૢद୻ਗभৰ୻ ॑ેীपઅൟदऌङহਜૌෙ ॑েिऒधऋँॊ • ১਑২੝ਫ਋৑ध਋ଜ෬႞਋ ऋ੎ऩॉ૙৩भମ৬৓‫ੱ؞‬৶ ৓଀෰ुপऌः • ૚३५ॸ঒म൐ফ৅েघॊ ૗ಌਏ੷पेॉૠெऋপऌ ऎऩॉ‫ؚ‬৳ஹ੿঵୤ऋফ‫ر‬ ੜপ • 67ঃॵॣ‫ش‬४‫ؚ‬150MSप఺ वೋপऩ९ইॺक़ख़॔ৱਓ • ১੝ਫभਁ਀ऊै઱ষऽद भ਋৑৔प৸ਃચभ৫৅ऋ ৑प়ॎऩःৃ়ु • ੝ਫ৔ઍभ৥ન৲ऋ஺మ৓ ऊण઱ষभઉ৐ऽदਢऎञ ीুರॉु੗ः 7 Takane-Driven Initiative໪ਏ ॻওॖথ્৲ঔॹঝَTakaneُ॑றप‫ؚ‬১਑২भ৶ੰ‫؞‬ਏ੯৒ଝऊै‫ؚ‬ ਝੑ‫؞‬ৰಎ‫ق‬੝ఊ‫؞ك‬੥়ॸ५ॺऽद‫ؚ‬঳ਞৢฮभঽ৿৲॑AIदৰਠ • ਏ੯৒ଝऊै੥়ॸ५ॺऽद॑‫ؚ‬ঐঝॳग़‫ش‬४ख़থॺद঳ਞৢฮपड़‫ॣش‬५ॺঞ‫ش‬३ঙথ • พ༷ੴ‫୻؞‬ਗઈ৷॑஄ૄੴ৲ख‫ؚ‬AIऋ૞ස૭ચऩGround Truthधखथଁ় • AIग़‫ش‬४ख़থॺऋ୶஭෇೧્॑৒ख‫ිؚ‬ၨ৓पਝੑ‫؞‬ৰಎ‫ق‬੝ఊ‫ك‬ যधAIऋৌਵखणतऐॊ৫৅ऊै‫ؚ‬ঽ൅৓ऩAIपेॊঀথ५ॺॵউभ৫৅ष ਏ੯৒ଝ Today ਝੑ AI ৰಎ‫ق‬੝ఊ‫ك‬ AI ੥়ॸ५ॺ AI AI Takane -Driven Initiative ঐঝॳग़‫ش‬४ख़থॺ‫؞‬ड़‫ॣش‬५ॺঞ‫ش‬३ঙথ 8 ३५ॸ঒ॸ५ॺ AI জজ‫ش‬५ ઈ৷‫؞‬৳ஹ AI ಓ౵৓ਛટ ३५ॸ঒੝ఊम‫ؚ‬যभ੿঵ऊैAIभ੿঵ष 3যা ৺ 4ৎ৑ 100 ೅भেਓਙ 9 Takane-Driven Initiativeऊैजभ੔ष घसथभ३५ॸ঒৫৅षன৫ 10 َ૗৲खਢऐॊ३५ॸ঒ُपਘःAIॻজঈথ৫৅੦ೕ ன৫ॱ‫ش‬।ॵॺमَ૗৲खणतऐॊ३५ॸ঒ُ ੝ఊप੗পऩ॥५ॺृজ९‫ش‬५॑ເଞ৓प଎ાख‫ؚ‬যুൂோऋ঎ॺঝॿॵॡधऩढथःॊ३५ॸ঒ ૗ಌ५আ‫ॻش‬ऋ଼ଥৡ॑ంకख‫ؚ‬Time to Market੝ఒऋजभऽऽঅ४ॿ५੼கपઉ੥घॊ३५ॸ঒ ಲਢ੝ఊऋເଞ৲ ૗ಌᄄ২ऋৈऎ জজ‫ش‬५ऋৈச শফभ੝ఊदೋপ৲‫؞‬ ളහ৲खञৱਓ ૰ਪ‫؞‬ହ৥ிભभ ਏ੷ऋৈः ১ৌૢ‫ૹؚ‬ષ‫؞‬મসট४ॵॡ ಌৗ‫ؚ‬ਗ৖१‫ش‬অ५৴௚ াઃজজ‫ش‬५‫ؚ॔‬४কॖঝऋ ଞଙ ൂோঢ়બ‫؞‬ஆঽல஘‫؞‬ พ༷ੴऋ੗ः ૗ಌ৶૓भ ॺঞ‫ش‬१অজॸॕऋ૑ਏ স੆ ৢਦ ৵ਲ਼ 11 ੟૴ ଲୗ AI-Driven Software Development Platformभ໪ਏ ୕૒ৢभଢ଼஢ਚૼ୒ध঵ਜੴৄ॑றप‫ؚ‬ളਯभAIग़‫ش‬४ख़থॺ॑ੈ৹औच‫ؚ‬ ਏ੯৒ଝऊै੥়ॸ५ॺऽद॑঳ਞৢฮपঽ৿৲घॊAIॻজঈথ৫৅੦ೕ ੵங ਏ੯৒ଝ ਝੑ ৰಎ‫ق‬੝ఊ‫ك‬ ੥়ॸ५ॺ Multi Agents Orchestration ৫৅ੵங AIग़‫ش‬४ख़থॺ ਏ੯৒ଝ ग़‫ش‬४ख़থॺ ਝੑ ग़‫ش‬४ख़থॺ ଲୗ ग़‫ش‬४ख़থॺ ୭୆ଦ૟ ग़‫ش‬४ख़থॺ Takane / ሑ৷েਛAI੦ೕ File Tree RAG ग़থॱ‫ش‬উছॖ६ েਛAI ইঞ‫ش‬঒ড‫ش‬ॡ ॸ५ॺ ग़‫ش‬४ख़থॺ ९‫ش‬५॥‫ॻش‬ ওॱੲਾ ১ഥ‫؞‬૖୻৶ੰ ਝੑછেਛ ॸ५ॺৱਓেਛ ਝੑੲਾ ॻওॖথੴ௙ ঽഞ௬੼‫٭‬੝ఒ ॹ‫ॱش‬ঋ‫ش‬५৴௚ ৫৅ॶ‫ش‬ঝ৴௚ 12 AI-Ready Engineeringधम AIऋใோ३५ॸ঒॑ਫखऎ৶ੰख‫ؚ‬ਦ౅ਙँॊঽ৿৲॑ৰষदऌॊेअ ৱਓ‫؞‬ੴ௙‫؞‬ષସ॑ତइॊੵங‫؛‬ऒभَல੢ाُभਛ࿃২ऋঽ৿৲भಖ২॑ৠीॊ AI-Ready Fitting ঽ৿৲भਛ඘૨॑ৠीॊَல੢ाُ AI॑३५ॸ঒पਫखऎमी੢ि ৱਓ৶ੰ ৫৅ঝ‫ش‬ঝ‫؞‬ਝੑଡୗभఏ૆৲ AI ¼ ใோ३५ॸ঒भి়৹ତ • ใோ३५ॸ঒ৱਓभଡୗ৲धਫ਼ดॖথ ॹॵॡ५৲ • พ༷ੴभ஄ૄੴ৲‫ق‬঵ਜੴ௙‫؞‬৫৅ু ದ‫؞‬ৱਓൂோঢ়બऩन‫ك‬ • ୵੡ૠ৺‫؞‬ਝੑ੿১‫ॸ؞‬५ॺ௴ਡभତ૟ • ఊਫखृघःଡୗषभગౣ ਫੰॹ‫ॱش‬भ૆૟ ৰষ୭୆भତ૟ • ਫੰॹ‫ॱش‬धAI੝ఊ੥ટभॠকॵউ॑௬ ੼ख‫ؚ‬॥থॸय़५ॺृউটথউॺ॑ ॳগ‫ॽش‬থॢ‫ق‬஄ૄੴभৄઉख‫؞‬ਫ਼ดॖ থॹॵॡ५भౄৰ৲‫ك‬ • Takaneभॳগ‫ॽش‬থॢद AI भਖ਼૵ષସ ॑ਈి৲ • ૌு੝ఊभਫੰॹ‫ॱش‬৲ • AIभ੥ટ॑ਫੰॹ‫ॱش‬धૻຎ‫؞‬௬੼घॊ லੌा • ঽ৿অঝॻ‫؞‬ঽ৿ॸ५ॺ‫؞‬ঽ৿ଦ૟भல ੌा‫ق‬CI/CD‫ك‬ • AI ऋলৡखञਛટ੟॑CI/CD੦ೕध৴௚ Asset Understanding Ground Truth Engineering Conventions Execution Readiness 13 Fitting AI-Ready Engineering - ୕૒ৢभਘा যभৰᄷੴध‫ؚ‬AIभৰষੴَ॑੥়ُदऌॊৡ Human knowledge Machine Knowledge ୕૒ৢभਠৃग़থ४ॽ॔ऋ஋ा঱ऑथऌञৰᄷੴ AI ऋَয৑ષସُद৿ऎञीभலੌा পૠெ‫؞‬ളහऩใோ३५ॸ঒॑ഭाੰऎৡ พ༷ੴभ஄ૄੴ৲धିো • ষ৆‫؞‬স੆‫؞‬ୢ௜ऩन‫ؚ‬ളහऩ୩ୠ॑40ফਰ঱૿ਊ • ਯਐই॓ॖঝૠெभ॥‫ॻش‬ৱਓभଡୗ‫؞‬၎ഄ‫؞‬ઈ৷॑৶ੰ • AIभ೴ೊ॑ഃऎَ਀ਠभॅैऍُ॑ৄ௷ऐॊਠৃৡ • ਝੑછपऩः঵ਜঝ‫ش‬ঝ‫୻؞‬ਗ૪৶‫؞‬ਖ਼૵भਔ௕॑ଡୗ৲ • ਏ੯‫؞‬ਝੑ‫؞‬॥‫॑ॻش‬णऩएৄइऩःଶ॑AIऋ⍻ोॊ஄प૗ఌ • Human-onlyटढञਖ਼૵୩ୠ॑‫ؚ‬AI ऋඞइॊোৡष พ༷ੴ‫୻؞‬ਗઈ৷भৢ๨ৡ য৑ੴ॑ગਠदऌॊৰষ੦ೕ • ਝੑછपછऊोथःऩः঵ੀຯষ‫୻؞‬ਗ૪৶‫؞‬ઈ৷ਖ਼૵॑৶ੰ • َல஘છेॉਠৃऋਫखः਼ُੀद‫ؚ‬ல஘ॠকॵউ॑ඇीਢऐ थऌञ৽ୡ • ਝੑृ॥‫ॹش‬ॕথॢ‫ॸؚ‬५ॺभ੥ટ॑஺మ৓प௬੼ख‫ිؚ‬ၨ ਙ‫఻؞‬৬ਙ॑ঽ൅৓पৈीॊग़‫ش‬४ख़থॺණ • ঩মୁ৶ੰ‫؞‬঑ॵ३ঙথॡজॸॕढ़ঝ୩ୠपশऐञTakane॑র றपྚइञAIৰষଡୗ ఏ૆৲‫؞‬ષସଵ৶भ໮஋ ੝ఊউট७५৸৬भड़‫ॣش‬५ॺঞ‫ش‬३ঙথ • ୵੡ૠ৺‫؞‬৫৅ఏ૆‫ॸ؞‬५ॺ௴ਡभশফभ໮஋ • उ௢஘ಕથभ੿১॑ஹॉऩऋै੝ఊघॊঀक़ঁक़ 14 • ਏ੯৒ଝ‫؞‬ਝੑ‫؞‬ৰಎ‫؞‬੥়ॸ५ॺ॑णऩऍ‫ؚ‬౥വऽद௒ॉਢ ऐॊ AI-Ready Engineering ¼ AIॻজঈথ৫৅੦ೕ ঳ਞৢฮभ३५ॸ঒৫৅ঽ৿৲॑ৰਠघॊ૏୽ AI-Driven Software Development Platform AI-Ready Engineering AIऋഊॎङਖ਼૵दऌॊ૾ଙ॑णऎॊ ‫ش‬ৱਓ৶ੰ‫؞‬พ༷ੴ‫؞‬ષସ੦૆‫ش‬ AIपेॊঽ൅৓ऩ৫৅ৰষ ‫ش‬ਏ੯৒ଝ‫ع‬੥়ॸ५ॺभঽ৿৲‫ش‬ 15 2-1. ਋ୄ஍ટ ৅ି঻पधढथَ੧੯ओधभ੃২ৌૢُऊैَ੅ਢਙभન৳ُपૡఌघॊ ీਃधऩॊऒधऋ਋ୄऔोॊ ৹୸ੵங జਟभ૾ய AIฌ৿पेॊ૗৲‫؞‬਋ୄ ⋇੫઺য়੧‫؞‬৹୸૆૟ ‫଻؞‬શ੧੯ओधपਏ੯ତ৶ ‫؞‬พ༷ੴ‫؞‬যभ৽ୡपൂோ ‫؞‬਑২ಉभ૗৲पૢगಲਢ৓पਈి৲ ‫؞‬ใோৱਓ॑ଡୗ৲‫ॼ؞‬ঞॵ४৲ ⋈৘ৃ৹ਪ‫ق‬RFI‫ك‬ ૼ୒भથ૮‫؞‬ৰౚનੳऋরੱ ৌૢৡ‫؞‬ঽ৿৲෇೧‫੅؞‬ਢਙ॑નੳ ⋉৹୸ல஘ੁ৒‫ق‬RFP‫ك‬ ਃચ‫؞‬ல஘॑ಕ৒৓प੶ൗ ਛટ‫؞‬૗ಌৌૢৡ॑੎ଳखथ੶ൗ ⋊োై‫઀؞‬੧௬੼ ৬਑‫੼؞‬તরੱभ௬੼ ੅ਢਙ‫؞‬ષସ‫ؚ‬ৌૢৡ॑௬੼ ⋋ਝੑ৫৅‫؞‬ઈ৷৳ஹ ‫؞‬੝৒भञलपপૠெ੝ఊ ‫؞‬ષସयैणऌ‫ؚ‬രয৲ ‫୶؞‬஭્৒→ಢ਋ৌૢ ‫؞‬ੴ௙॑லੌाप໮஋‫ؚ‬਴૆৲ © 2026 Fujitsu Limited 2-2. ஍ટ॑েिञीभਫ਼ୈহඨ‫਻ୖ؞‬ AIฌ৿षभૡఌभਛ౯॑ীऐॊभम‫ؚ‬AIजभुभदमऩः َAIऋਫखऎ৶ੰदऌॊ૾ଙ॑‫ؚ‬হ৐पତइथःॊऊُऋএॖথॺ జਟ 9 যऋਂ౥৸ऩৱમ॑ഭाੰऌ‫ؚ‬ ৽ୡदଓ౥खथऌञ 9 ᥊዗औृരযਙम َਠৃৡُदลઽ AIฌ৿भৎ৻ 9 AIम ᥊዗ऩऽऽदमਫखऎ৿ऊऩः 9 োৡ‫ق‬ৱਓ‫؞‬ਏ੯‫؞‬ਝੑ‫ك‬ऋਂ৥ᐱदम ෙढञঽ৿৲‫؞‬ঈছॵॡ঎ॵॡ५৲भ জ५ॡऋৈऽॊ ঵ਜ‫؞‬਑২‫؞‬३५ॸ঒ৱਓभଡୗ৲‫؞‬ఏ૆৲ “AI-Ready Engineering” যुঞঅগ‫؞ش‬ਖ਼૵दऌ‫ؚ‬ AIपु৶ੰदऌॊ஄द ॹ‫ॼृॱش‬ঞॵ४॑ତइॊ਄ੌा ऋAIฌ৿৫৅भ৐઀धखथਂ૭ಳ © 2026 Fujitsu Limited © 2026 Fujitsu Limited ච㈐஦㡯 / Disclaimer 1. মৱમप੶ൗऔोथःॊ৔ઍम‫ؚ‬৅਀ৎਡपउऐॊੲਾप੦तऎुभदँॉ‫ؚ‬০৏੒ઔऩऎ૗ಌधऩॊৃ়ऋँॉऽघ‫؛‬ The information contained in this material is current as of the date of presentation and is subject to change without notice. 2. মৱમभੲਾम‫્ؚ‬৒भଲષ‫؞‬१‫ش‬অ५भ୿ਲ਼‫॑୹઀؞‬৺൶‫؞‬৳઒घॊुभदमँॉऽच॒‫؛‬ This material does not constitute a commitment or guarantee for the sale or provision of any specific products or services. 3. মৱમप੶ൗभভ঺੡‫؞‬ଲષ੡‫؞‬१‫ش‬অ५੡ಉम‫ؚ‬૚঺भૹఏऽञमఃஈૹఏदघ‫؛‬ Company names, product names, and service names mentioned herein are trademarks or registered trademarks of their respective owners. 4. মৱમभ঳৖ऽञम৸৖॑‫ؚ‬૮૵दളଲ‫؞‬ૡൗ‫؞‬ૡ৷घॊऒध॑రगऽघ‫؛‬ Reproduction, redistribution, or repurposing of any part of this material without prior written consent is strictly prohibited. 5. মৱમप੶ൗभలਟभৄৢखृੑ઺ಉपम‫ਂؚ‬નৰऩਏಞऋஅऽोथउॉ‫ؚ‬ৰ੠भ੥ટध౮ऩॊৃ়ऋँॉऽघ‫؛‬ Forward-looking statements and plans in this material contain uncertainties and may differ from actual results. 19 ©2026 2026 Fujitsu FujitsuLimited Limited ©

ࣁྋ̑ েਛ$,峼ણ৷峁峉 崟崡崮嵈৫৅峘਄峴ੌ峩峕峎岮峐 ফা঩ © 2026 NTT DATA Group Corporation  6,঵ੀ峕岴岻峵 েਛ$,峘崌嵛崹崗崰 © 2026 NTT DATA Group Corporation 2 ੫঵峘঵ਜ峕岴岻峵েਛAI峘ి৷૨ ঵ਜ峕峙峓峘ব峬AI峼ਹ৷ 55.2 ঺৔ 嵀嵓崿崯崡崗 90.6 90.3 95.8 崿嵕崘嵑嵇嵛崘 嵣 崸崘ఊਫ 嵉嵤嵓嵣৮হஈ ੿ਛଓஃ ৱમ੿ਛ ଓஃ ੫઺峘 崊崌崯崊ল峁 ൹௢ৌૢ峘 ঽ৿৲ ঽ঺ଲષ峮 崝嵤崻崡ਃચ 峢峘਄੢ ઁઔ崛嵛崮嵛崬 AI峙ઞ岰/ઞ峹峔岮峑峙峔岹 岣峓岰ઞ岰岵岤 峘崽崏嵤崢峕峔峍峐岮峵 ‫ق‬ল๕‫ك‬੕ਜ੄‫ق‬2025‫ك‬岣ব৔ਗ峕岴岻峵ਈৗ峘ੲਾৢਦૼ୒峘ଢ଼஢৫৅఺峝崯崠崧嵓ણ৷峘৿਱峕ঢ়峃峵৹ਪଢ଼஢岤 https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/nd112220.html © 2026 NTT DATA Group Corporation 3 $,峙஘‫ر‬峔ਓ঵峕ૢ৷岿島峐岮峵 ଳಁ嵣਑౪ ౼ Brain ଳಁ嵣ඡಁ ঽ৿ઈૡ Autonomous Driving ෗૙‫׽׸ؑآ‬ Humanoid Robot AI Agent ലಁ嵣৅ਵ Hearing ඡಁ /Speech Touch ᚃಁ 崛嵤嵓崣嵛崧嵤 Smell Call Center © 2026 NTT DATA Group Corporation  েਛ$,峘崻崠崵崡嵣嵎嵤崡崙嵤崡 ்ઁ岮ણ৷嵎嵤崡崙嵤崡岶୳৒岿島峵 ৰຉ࿨֩Ⴗ፛ ‫ؖ‬՛‫ؠ‬ఢถ ཐಡ֪ৰ֤փ֞໴ࣤ ،‫ץبؔ؞ץآ‬ ԏՌԳԵՀ৘෾ఢถ ሓ፭࡫ᄗ‫פ׸ל׶‬౫࣍ ‫ר‬՛‫״بװؠ‬՛ ࣤး౫࣍Քࣤ໴ࡱถ ౩ணธጫ ‫ཬ׽יתبי‬ഞ ᇌኜఢถՔ஑ฝ ጅዃՔ቏ዅ ‫آ‬՛‫ؠ‬،‫ץبיء‬ ৫बᇝ໫֠ © 2026 NTT DATA Group Corporation ๔኷࿨֩ਙፘ ೂၾਊ࿊֪ ໋֢֞ᄕཉ౫࣍ ؓ‫بיׯؠח؟׻‬؊‫׮פט׻ؓמ‬ዿԎԌஓཝ ؓ՛‫ץبט׻צ‬ ୔ਰྔ௮Ք࿓ࡎ ፬ಉಈ፯֪‫׊ׇ‬ ఢ઄ሑ෕ଙ၀౫࣍  ࢪ઄‫׽‬՛‫פ‬शื েਛ$,峘崻崠崵崡崌嵛崹崗崰 ੗岹峘崊崲嵒崡崰岶岝েਛ$,岶崻崠崵崡峕প岷峔୶஭峼ଖ岲岝્峕崥崽崰崎崏崊৫৅峑প岷峔崌嵛崹崗崰岶岬峵峒੒୳ ం௕峙嵆崫崕嵛崤嵤峘嵔嵅嵤崰峘঳৖岵峳௷ხ峁峉峬峘峑岝 ૚崻崠崵崡୩ୠ峕岴岻峵েਛ$,峘୶஭২峼ં峁峐岮峵岞 ્峕岝েਛ$,峘崥崽崰崎崏崊৫৅峢峘崌嵛崹崗崰峼ં峃 6RIWZDUH(QJLQHHULQJ 峘ഔ峙岝崻崠崵崡୩ୠ峕峲峳 峄ৈ岹௬੼岿島峐岮峵岞 峎峨峴岝েਛ $, 峙崥崽崰崎崏崊৫৅峘岬峴্峼 প岷岹૗岲岰峵峒੒୳岿島峐岮峵岞 ਬ৷੪KWWSVZZZPFNLQVH\FRPFDSDELOLWLHVPFNLQVH\GLJLWDORXU LQVLJKWVWKHHFRQRPLFSRWHQWLDORIJHQHUDWLYHDLWKHQH[W SURGXFWLYLW\IURQWLHULQGXVWU\LPSDFWV © 2026 NTT DATA Group Corporation   েਛ$,峼ણ৷峁峉 崟崡崮嵈৫৅峘 ਄峴ੌ峩૾ய © 2026 NTT DATA Group Corporation 7 $,ૼ୒ણ৷峕ৌ峃峵177'$7$峘਄峴ੌ峩৸৬൸ 岣஋ா৓峔$,ણ৷峘௓ਤ岤 峒 岣$,崔崸崲嵛崡峘ජೲ岤 峘૏୽峑਄峴ੌ峩岝崻崠崵崡ఁপ峼௕峵 ԋԔ‫ב‬ঊዿ֖֞઄ኃᇥॹ֭ಲଵ ௓ਤ峒ଁ਑峘૏୽岵峳崝嵅嵤崰 ஋ா৓峔$,ણ৷峘௓ਤ $,崔崸崲嵛崡峘ජೲ ੔ਤ൹௢峒峘হ୻൉ল $,崔崸崲嵛崡஼ ਌ਏ崿嵔崌嵌嵤峒峘 ਅറ৓ 崹嵤崰崲嵤崟崫崿 ૼ୒崊崣崫崰峘 ତ૟ ੒ଆ ਫ਼ੴ ൹௢9DOXH&KDLQ૗୓ ঽ঺9DOXH&KDLQ૗୓ ৌૢ ௬੼ 岴௢஘峘 ঵ਜ੝ఒ © 2026 NTT DATA Group Corporation 崟崡崮嵈৫৅峘 ஍૨৲ ਊ঺঺৔峘 2$঵ਜ૗୓  েਛ$,ણ৷૾ய峒০৏峘ன஦ 崧崡崗峘ঽ৿৲峘ৰਠ岵峳岝崿嵕崣崡峘ঽ৿৲岝లਟ৓峕峙崻崠崵崡峘ঽ৿৲峨峑ଳ৙峕 2023-2025 2025-2027 2027 - Task automation Autonomous processes Autonomous businesses ‫֭פ׮״‬ಛ၌ँ ،‫֭׮װآ‬ಛ၌ँ ؈‫֭׮؂׭‬ಛ၌ँ Copilot Agentic AI ภถAIਙട֋ුँ֖Ւᆗਸ֋փ֢֜օුֿ֧֪֒‫׉ׇ‬Ւ؈‫֮׮؂׭‬ශ֖փಐ༉ַ © 2026 NTT DATA Group Corporation  েਛ$,ৎ৻岴岻峵েਓૼ୒୓ৗ峘崊崿嵕嵤崩 $,嵣崯嵤崧崱嵒崾嵛৫৅峼ઃ਼৻峘৫৅峒峁峐ኇ岲岝ঽ঺,3峒ૹ৷崬嵤嵓峼ੌ়峅峉崊崣崫崰ණ峕峲峴岝崥崽崰崎崏崊৫ ৅峢峘েਛ$,ણ৷峼৸ੵங峑崓崸嵤岞੧੯્ਙ峕ૢ峂峐崊崣崫崰峼ి৷峃峵岽峒峑岝௷ম৓峔েਓਙ਱঱峼ৰਠ ফ৻ ফ৻ ফ৻ ਠ૔‫ع‬ ఏ૆৲ ঽ৿৲ 崊崠嵋崌嵓৫৅ $,嵣崯嵤崧 崱嵒崾嵛৫৅ &66ఏ૆ 崿嵕崠崏崗崰ଵ৶ ਏ੯৒ଝਝੑ 崛嵤崯崋嵛崘崮崡崰 ઈ৷ 崥崽崰崎崏崊৫৅峕岴岻峵েਛ $, ઀੧嵣ి৷হ୻ 500+ 崥崽崰崎崏崊৫৅઀੧岝ి৷੯ਯ © 2026 NTT DATA Group Corporation 67% ଲୗ েਓਙ਱঱ ਲਗপু਒ষ ઺એ嵆崌崘嵔嵤崟嵏嵛  19% ૥ୡ েਓਙ਱঱ ব৔পু৳૫ভ঺ ૥ୡ৥಍੿ਛ েਛ$,ి৷嵎嵤崡崙嵤崡ਯ ਏ੷ীෲ ਝੑ ਃચਏ੷ীෲ峒 ঵ਜ崽嵕嵤৒ଝ ਃ ચ 嵎嵤崡崙嵤崡৒ଝ 8,৒ଝ ਗ৖,)৒ଝ ৫ ৅ శ ਃ ચ శਃચਏ੷ীෲ ୎ষ ,7崝嵤崻崡 ଵ৶ 嵣૪৶ਝੑ 嵣8,ਝੑ 嵣ਗ৖ਝੑ 崯嵤崧嵊崯嵓 ਝੑ ঘ ॽ ⑁ ॺ ਝ ੑ 崥崽崰崎崏崊 崊嵤崕崮崗崩嵋 ໪ਏਝੑ 崥崽崰崎崏崊 崊嵤崕崮崗崩嵋 ถ಍ਝੑ 崟崡崮嵈੦ೕਝੑ 崟崡崮嵈੦ೕ 崹嵑嵉嵤崧ਝੑ ୎ষਏ੷ীෲ ଁ় 崌嵁嵛崰 崌嵛崟崯嵛崰 © 2026 NTT DATA Group Corporation 崡崙崠嵍嵤嵓 崝嵤崻崡 ਏ੷ຄষ ਖ਻ ੗ 崿嵕崘嵑嵈 崛嵤崱੿ਛ 嵎崳崫崰崮崡崰 8&崮崡崰 崟崡崮嵈 崮崡崰 ঵ਜ崮崡崰 嵣崟崡崮嵈੦ೕ崮崡崰 ੑ઺峒ਝੑ 嵣崟崡崮嵈੦ೕ崮崡崰 ৰ઱ 崥崽崰崎崏崊崽嵔嵤嵈嵗嵤崗ଡണ ୭୆ଡണ 崟崡崮嵈ઈ৷੿঵੍ର崬嵤嵓৫৅ 嵣崟崡崮嵈崊嵤崕崮崗崩嵋崮 崡崰ੑ઺峒ਝੑ 嵣崟崡崮嵈崊嵤崕崮崗崩嵋崮 崡崰ৰ઱ ୎ষ੍ର崬嵤嵓ಉ৫৅ ୎ষ崮崡崰ੑ઺峒ਝੑ 崟崡崮嵈੦ೕ਑౪ਃચ৫৅ 崛崡崰 ૗ಌ 崮崡崰 ૪৶崮崡崰 ୎ষੑ઺峒ਝੑ 崡崛嵤崿 ૘ ଲୗ 崥崽崰崎崏崊崊嵤崕崮崗崩嵋ਏ੷ীෲ 崟崡崮嵈崊嵤崕崮崗崩嵋৒ଝ 3-ଵ৶ 岧ტ୻岨 嵒嵒嵤崡 ષସ ଡਛ 崊崗崣崡  ৱ౺ হ঵ঢ়બ 崛嵇嵍崳崙嵤崟嵏嵛 崝嵤崻崡 嵔嵁嵓 崕嵋崹崟崮崋 ਭো崮崡崰 嵣崟崡崮嵈崮崡崰 శਃચ ੑ઺峒ਝੑ 嵣崟崡崮嵈崮崡崰ৰ઱ ୎ষ崮崡崰ৰ઱ ୎ষ嵒崷嵤崝嵓ৰ઱ ৹୸ 崡崮嵤崗嵃嵓崨嵤 嵒崡崗 ૭৷ਙ ,7崝嵤崻崡 ಲਢਙ ੲਾ 崣崕嵍嵒崮崋 崝崿嵑崌嵌 ઇ୘ ธಫ ใோ৫৅崿嵕崣崡嵁嵤崡峘஍૨৲  ਏ੯৒ଝ岵峳৔৖੥়崮崡 崰  েਛ$,岶੿ਛ峁峉ਛટ੟峼岝৏ਢੵங峘崌嵛崿崫崰峒峁峐ણ৷ $,峘૽સ ,1387 ਏ੷ীෲ$,崐嵤崠崏嵛崰 ੦মਝੑ$,崐嵤崠崏嵛崰 ถ಍ਝੑ$,崐嵤崠崏嵛崰 ਏ੯৒ଝ岴峲峝੦মਝੑ峘 েਛ੍ର ੦মਝੑ岵峳ถ಍ਝੑ峘 েਛ੍ର 嵎嵤崞嵤ਏ੷嵣ਏ੯ਛટ੟ ‫ق‬঵ਜ໪ਏ嵣崻崠崵崡嵓嵤嵓৒ଝ ಉ‫ك‬ (5௕ 嵉崫崣嵤崠 ਝੑછ 崔崌崱嵑崌嵛 ਗ৖,) ਝੑછ 嵔崻嵍嵤঳༮ ტ୻ 崛嵤崯崋嵛崘$,崐嵤崠崏嵛崰 ถ಍ਝੑ岵峳3*崛嵤崱嵣87 崛嵤崱峘েਛ ુৢ૪৶ ਝੑછ 崛嵤崯崋嵛崘 ૠ৺છ $,岶੿ਛ য岶੿ਛ ੥়崮崡崰$,崐嵤崠崏嵛崰 ৔৖੥়崮崡崰峘 েਛ੍ର ુৢ૪৶ ਝੑછ ถ಍ਝੑછ ถ಍ਝੑછ 崥嵤崡崛嵤崱 287387 (5௕ 64/ ਝੑછ © 2026 NTT DATA Group Corporation 嵉崫崣嵤崠 ਝੑછ ਗ৖,) ਝੑછ 87崮崡崰崛嵤 崱 ถ಍ਝੑછ 崥嵤崡崛嵤崱 ৔৖੥় ૥ୡ 嵆崰嵒崫崗崡 ৔৖੥় ૥ୡ 崮崡崰崛嵤崱 ુৢ૪৶ ਝੑછ  ৔৖੥় ૥ୡ ඨ৯છ 岧૞અ岨崌嵛崿崫崰崯嵤崧峘ତ૟ ೮ਟ峘৫৅峑੗৷峁峐岮峉([FHO峮3RZHUSRLQW஄ૄ峘崱崕嵍嵉嵛崰峑峙岝崥崽崰崎崏崊৫৅峕岴岻峵েਛ$,ણ৷峑ણ৷峃峵//0 峢峘,1387峕ਂిજ岞崛嵛崮崕崡崰峔峓੗஘峔ੲਾ峙峃峣峐崮崕崡崰஄ૄ峑৷ਔ峃峵岽峒岶஦峨峁岮岞 ೮ਟ৫৅峘ৱਓ峘થ஍ણ৷峘峉峫岝([FHO岵峳崮崕崡崰஄ૄ峢峘૗ఌ峼യਤ峃峵崊崣崫崰峬৷ਔ岞 Step1. ਝੑછଡୗ৲ ([FHO337:25' 3')+70/ 崽崑嵤嵆崫崰 9 $,岶ഭ峩਄島峵峲岰峕0DUNGRZQ૗ఌ 嵤 ଡୗ岶ളහ峔਀஄ૄ峕峬ৌૢ 嵤 ਝੑછMD৲AI崐嵤崠崏嵛崰 崓崡崧嵆崌崢 岴௢஘崽崑嵤嵆崫崰峢峘 ৈಖ২崩嵍嵤崳嵛崘峼ৰਠ ৈ২峔ਃચ ঳ฐ૪৶峒崯嵤崧 ࿒௞峼઀୹ ٜٛ +70/ © 2026 NTT DATA Group Corporation ঩ম峘৫৅્થ峘ல஘峕ৌૢ ഀླྀ෇೧峮਄଎଍峢ৌૢ ஄ૄ૗ఌ 岿峨峀峨峔஄ૄ峼 0DUNGRZQ峢૗ఌ ઺൸૪৶ ઺൸峼ྴল峁峐ਈి৲ ଡୗ৳੅ ધછ峘ଡୗ峒ਔ௡峼৳੅  Step2. Markdownਝੑછଵ৶ 9 য৑岶નੳ峁峮峃岮峲岰峕3)ଵ৶ 嵤 ਫ਼ด嵣ౣૐ岶૭ચ峔ଁ়ଵ৶8,峼઀୹ 嵤 ਝੑછଵ৶崿嵑崫崰崽崑嵤嵈 ‫૆୹઀ق‬૟র‫ك‬ ૑ਏ峔ੲਾ峼ਫ਼ด૭ચ ‫ق‬崕嵤嵗嵤崱嵣$,崩嵋崫崰‫ك‬ ૭ഭਙৈ岮૾ଙ峑崿嵔 崻嵍嵤਀ં嵣ౣૐ岶૭ચ *LW৴௚峁峐ଵ৶峃峵岽峒峑 ૗ಌଵ৶峬ઍಔ ‫*ق‬LW/DE嵣*LW+XE嵣%LWEXFNHW峕ৌૢ‫ك‬  েਛ$,峼৸એણ৷峁峉 崟崡崮嵈৫৅ © 2026 NTT DATA Group Corporation 14 েਛ$,峼ણ৷峁峉৫৅峘లਟ൸ AI崐嵤崠崏嵛崰嵣েਛAI峼 ජೲણ৷峁峉েਓਙ਱঱ েਛAIણ৷峙 ใ峕嵔崯崋嵤峔૾ଙ 100ਰ঱峘嵎嵤崡崙嵤崡 ੫઺ ୮੪ ৫৅ AIણ৷৐઀峘৫৅崿嵕崣崡 ৫৅ੵங৸৬峘েਓਙ਱঱ • :嵊崯嵓 • 崮崡崰ฌ৿஑৫৅ ৫৅ੵங嵔嵁嵓峘েਓਙ਱঱ • 1ஊ嵊崯嵓9ஊ஍૨৲ 崧崡崗峘ঽ৿৲ © 2026 NTT DATA Group Corporation ‫ٮ‬崟崡崮嵈嵣৫৅峕岴岮峐岝঱૴ੵங岵峳崮崡崰ਝੑ峼崡崧嵤崰峁岝৫৅峒崮崡崰ੵங峼৊ৎ峕ਤ峫峵  েਛ$,ણ৷峕ి峁峉ৗ峁岮৫৅崿嵕崣崡峘୻ েਛ$,峕峲峴ਛટ੟峼੿ਛ峁岝ਛટ੟峘嵔崻嵍嵤嵣௬੼峼৫৅঻岶ৰ઱峃峵 © 2026 NTT DATA Group Corporation   েਛ$,ણ৷峕岴岻峵峎峘৫৅崿嵕崣崡 岣ใோ৫৅崿嵕崣崡峢峘েਛ$,ి৷岤峒岣েਛ$,峕ਈి৲岿島峉ৗ峁岮৫৅崿嵕崣崡峘ి৷岤峘 峎峘崊崿嵕嵤崩峑௓ਤ ဴೂᅮമ्ᄇ ،‫؎׮װآ‬՛‫֭׮‬ ภถ ԋԔ ঊዿ ใோ৫৅崿嵕崣崡峢峘 েਛ$,ి৷ েਓਙ਱঱২ ి৷෇೧ র‫ع‬ৈ ੗岹峘੧੯峑ి৷૭ચ శଞ峕ৈ岮 ి৷૖੯岬峴 ԋԔӷԝԱՈԺՊԵ ्ᄇ েਛ$,峕ਈి৲岿島峉 ৗ峁岮৫৅崿嵕崣崡峘ి৷ © 2026 NTT DATA Group Corporation  $,1DWLYH৫৅ ৫৅঻রੱ峘৫৅岵峳岝$,রੱ峒峔峵৫৅崊崿嵕嵤崩 ใோ峘崽嵕嵤峕$,崬嵤嵓峼৏હ岻峃峵峘峑峙峔岹岝$,峼রੱ峕ਝੑ嵣ৰಎ嵣ઈ৷峃峵 జਟ஑৫৅ AI ੍ର஑৫৅ AI-Native৫৅ ৫৅঻岶যু峑੿঵ AI 岶৫৅঻峼ଓஃ AI 岶੿঵岝৫৅঻岶嵔崻嵍嵤 ‫ق‬ધછ峙 Excel 峔峓岶রੱ‫ك‬ ‫ق‬৫৅঻峙 AI 峕崮崕崡崰峑੐ં‫ك‬ 峃峣峐峘崯嵤崧岶崮崕崡崰峔峘峑 য৑峕峑岷峵੿঵峙 AI 峕峬峑岷峵 ੐ં ‫ق‬崮崕崡崰‫ك‬ ੿঵ ৫৅঻ ৫৅ ୭୆ োৡ ‫ق‬Excel‫ك‬ AI଑ো ਛટ੟ ‫ق‬Excel‫ك‬ © 2026 NTT DATA Group Corporation ৚௦ ৫৅঻ ‫ق‬崮崕崡崰‫ك‬ োৡ ‫ق‬Excel‫ك‬ AI ਛટ੟ ‫ق‬Excel‫ك‬  ‫ق‬崯嵤崧峙੪岵峳峃峣峐崮崕崡崰‫ك‬ ৫৅ৱ౫ 峼 崮崕崡崰৲ AI崐嵤崠崏嵛崰 ৫৅঻ োৡ ਛટ੟ ‫ق‬崮崕崡崰‫ك‬ ‫ق‬崮崕崡崰‫ك‬ $,1DWLYH৫৅ ৫৅঻রੱ峘৫৅岵峳岝$,রੱ峒峔峵৫৅崊崿嵕嵤崩 ใோ峘崽嵕嵤峕$,崬嵤嵓峼৏હ岻峃峵峘峑峙峔岹岝$,峼রੱ峕ਝੑ嵣ৰಎ嵣ઈ৷峃峵 As-Is‫ ؟‬జਟ஑৫৅峘અ岲্ To-Be‫؟‬AI-Native ৫৅峘અ岲্ ৫৅঻ AI峼଑岹 崡崕嵓 ৫৅঻ ৫৅峘਌৬ ৫৅঻রੱ峘 崿嵕崣崡 ৫৅঻峼 ੍岲峵୭୆ ৫৅崿嵕崣崡 ৫৅୭୆ ৫৅峕岴岮峐৳峎峣岷崸嵑嵛崡 © 2026 NTT DATA Group Corporation AI রੱ峘 崿嵕崣崡 ৫৅崿嵕崣崡 AI崐嵤崠崏嵛崰 ৫৅峘਌৬ • AI 峒৫৅঻峘৴௚ • AI 峢峘੐ંਝੑ • ৫৅঻嵔崻嵍嵤岶৐઀  • AI崐嵤崠崏嵛崰峘਑౪ • ષସ峘૿৳ • ହ৥ிભ峘৳੅ AI 峘峉峫峘 ৫৅୭୆ ৫৅୭୆ • 峃峣峐峼崮崕崡崰峑ଵ৶ • AI 峕ి峁峉ૼ୒৭৒ • 崮崡崰ঽ৿৲ $,1DWLYH৫৅ৎ峘੿঵峘૴島‫ق‬໪ਏ‫ك‬ ਛટ੟峘ષସ૿৳峕ਸ岲岝૿ਊ঻岶েਛ$,峘ਛટ੟峘৔ઍ峼৶ੰ峁ହ৥ிભ峼ટ峉峃峉峫峕岝 যু峕峲峵嵔崻嵍嵤岝崩崏崫崗峼૑೼峕峃峵 ৸৬੿঵ ঵ਜ嵒嵤崨 ঵ਜ嵒嵤崨 崊嵤崕崮崗崰 ٔ$, ٔ$, ٔ$, ਏ੯৒ଝ $, ୭୆૆૟ ૚ਏ੯岾峒‫ق‬ధഔ峑੿঵峑岷峵岽峒岶஦峨峁岮‫ك‬ ਏ੯ীસ ঁॖঞঋঝ ਝੑ $,崐嵤崠崏嵛崰 ৫৅঻ $,崐嵤崠崏嵛崰 ৸৬੿঵ ৫৅঻ ৫৅঻ ٔ$, ট‫ش‬ঞঋঝ ਝੑ ঞঅগ‫ش‬ ଲୗ‫؞‬૥ୡ ঞঅগ‫ش‬ ੥় Vibe Coding峬ણ৷ 峁৿岹崊崿嵒峑൹௢峒 ਏ੯়峹峅峼ৰ઱ ৫৅୭୆૿ਊ ৫৅୭୆ ଡണ ਏ੯ ৒ଝછ ঐॖॡটਏ੯ (ঘ‫ش‬५ॣ‫ش‬५/ਃચ౐ਜ਼) ॸ५ॺॣ‫ش‬५ / ॥‫ॻش‬ ঁॖঞঋঝਝੑછ 崿嵕崠崏崗崰嵆崵嵤崠嵋 ৫৅ুದ ৒ଝ © 2026 NTT DATA Group Corporation ९‫ش‬५॥‫ॻش‬ (॔‫ش‬य़ॸॡॳক, ER௕...) ট‫ش‬ঞঋঝਝੑછ (APIਝੑ, ३‫ॣش‬থ५௕...) ੥়ੋ ਛટ੟ 崛嵤崱岶ిજ峑岬峵岵岝 ใோ峘崣崕嵍嵒崮崋൧ ૵崬嵤嵓峔峓峬ણ৷峁 峐崩崏崫崗 AIषभ੐ંই॓ॖঝ $,1DWLYH৫৅୭୆‫ق‬峃峣峐峘ੲਾ峼崮崕崡崰஄ૄ峑ଵ৶峃峵嵒嵅崠崰嵒‫ك‬   েਛ$,ણ৷峘崧嵤崚崫崰 峃峣峐峘੧੯峕ৌ峁峐$,1DWLYH৫৅峼ৰᄷ峑岷峵峹岻峑峙峔岮 ੧੯્ਙ峕ૢ峂峉ઞ岮ী岻岶૑ਏ পૠெളහ 2 ൹௢峘ਘ৲୩ୠ ൹௢மਡ$3 4 嵇崫崟嵏嵛崗嵒崮崋崓嵓 ྠ৒௺崟崡崮嵈 ੾঵ଵ৶ ੦ୌ崟崡崮嵈 ীෲ ੲਾ௺崟崡崮嵈 1 $JLOLW\ILUVW 3 রૠெ崐嵛崧嵤崿嵑崌崢崟崡崮嵈 093 崊嵛崩嵆崵嵤嵕嵛崨嵒嵛崘 3R& 'HPR0RFN8S © 2026 NTT DATA Group Corporation ৠੋ崌嵛崽嵑 ঺৔嵗嵤崗崽嵕嵤  崝崿嵑崌崩崏嵤嵛 嵆崵崠嵉嵛崰 েਓଵ৶崟崡崮嵈 ৈਦ౅ৈ૭৷ਙ েਛ$,ણ৷峘崧嵤崚崫崰 峃峣峐峘੧੯峕ৌ峁峐$,1DWLYH৫৅峼ৰᄷ峑岷峵峹岻峑峙峔岮 ੧੯્ਙ峕ૢ峂峉ઞ岮ী岻岶૑ਏ ਠ૾ পૠெളහ 2 ൹௢峘ਘ৲୩ୠ 4 嵇崫崟嵏嵛崗嵒崮崋崓嵓 ൹௢மਡ$3 $, 1DWLYH৫৅‫੾ ط‬঵ଵ৶ 崧崡崗౐ਜ਼嵣 $, 崐嵤崠崏嵛崰৫৅ ীෲ ੲਾ௺崟崡崮嵈ളਯੵங峑 峢峘崟崽崰 ి৷ੋ 1 $JLOLW\ILUVW 093 ਠ૾峑峬ેীણ৷૭ચ 3R& ‫ق‬崧崡崗嵣৫৅ੵங৸৬‫ك‬ 'HPR0RFN8S ஋ா৓峕ણ৷௓တ © 2026 NTT DATA Group Corporation ன஦ ྠ৒௺崟崡崮嵈 ৗૠ৫৅峼ৌ଴峕 েਛ$,峼ણ৷峁峉 ৠੋ崌嵛崽嵑ਛટ੟峘੿ਛ峼௓ਤ 崩嵋嵔嵛崠୩ୠ ੦ୌ崟崡崮嵈 3 রૠெ崐嵛崧嵤崿嵑崌崢崟崡崮嵈 崝崿嵑崌崩崏嵤嵛 崊嵛崩嵆崵嵤嵕嵛崨嵒嵛崘 嵆崵崠嵉嵛崰 崧崡崗౐ਜ਼嵣 $, 1DWLYH৫৅‫ط‬ ളਯੵங峑 েਓଵ৶崟崡崮嵈 $, 崐嵤崠崏嵛崰৫৅ ి৷ੋ ঺৔嵗嵤崗崽嵕嵤 峢峘崟崽崰 ৈਦ౅ৈ૭৷ਙ  ੶ൗ岿島峐岮峵ভ঺੡岝ૹષ੡岝崝嵤崻崡੡ಉ峙岝૚঺峘ૹఏ峨峉峙ఃஈૹఏ峑峃

2026.04.16 AI駆動開発時代における政府調達作業の改革と
 AI駆動開発のロールモデル 株式会社ROUTE06 創業取締役 松本 均 ROUTE06 Slide DECK ROUTE06,INC. ALL RIGHTS RESERVED 自己紹介 株式会社ROUTE06 創業取締役 松本 均 ベイカレント・コンサルティング にてITコンサルタントに従事 楽天株式会社、ヤフー株式会社 にて、
 EC／広告システム／データプラットフォーム領域の設計・開発 ストライプデパートメント にて、執行役員CTO Welby にて、執行役員／開発部長 ROUTE06 を共同創業、Acsim事業責任者（現職） 書籍
 『要件定義の極意』（翔泳社） ROUTE06 Slide deck ROUTE06,INC. ALL RIGHTS RESERVED 政府調達における構造的な負のループ IT団体連盟様から共有があった要望の背景を踏まえると『調達依頼の精度』が、 その後のプロセス全体に大きく影響していると考えています 調達依頼の曖昧さ 安全のための高額見積 IT知識の不足 要件定義を実施するコストが高い 各省庁 調達での ベンダー でもスの要 を要件定義をに 納品できるか判断できない 利益が見込めない 見積時間も不足 見積 Iによる時間／見積を 業によるの増加 特定ベンダーの実装ロックイン 発注者が評価できない 仕様追加・作業の手戻りによる
 スケジュール遅延／コスト増 IT知識の不足 評価コストが高い ベンダー 実装 各省庁 調達評価 でもコストで評価をに ROUTE06 Slide deck ROUTE06,INC. ALL RIGHTS RESERVED 政府調達における構造的な負のループ IT団体連盟様から共有があった要望の背景を踏まえると『調達依頼の精度』が、 その後のプロセス全体に大きく影響していると考えています 安全のための高額見積 調達依頼の曖昧さ IT知識の不足 要件定義を実施するコストが高い ❶ 業務でのAI活用 施策 ：調達 現状整理し、システムの要求 内容 整理し、要件定義を可能に 誰でも を 各省庁 ベンダー 納品 できるか判断できない 利益が見込めない 見積時間も不足 ❷ 要件見積にAI活用 施策 ： AIによる時間短縮／見積精度を向上
 →中小企業による提案の増加 特定ベンダーの実装ロックイン 発注者が評価できない 仕様追加・作業の手戻りによる
 スケジュール遅延／コスト増 IT知識の不足 評価コストが高い 施策❹：設計／実装によるAI活用 ベンダー 各省庁 施策❸：調達評価にAI活用 誰でも低コストで評価を可能に ROUTE06 Slide deck ROUTE06,INC. ALL RIGHTS RESERVED 2026.04.16 01 AI活用の全体像：デモンストレーション 現状の課題からAI導入後のプロセスまで ROUTE06 Slide deck ROUTE06,INC. ALL RIGHTS RESERVED AI活用による解決アプローチ → 調達業務全般、及びシステム開発におけるAI活用による変化 調達、システム開発にAIを導入することで、人依存の解消、調達業務全体の速度、品質向上を実現することができる。 【各省庁】 調達業務 いままで AI 活用 手動での対応 個人の知識・経験 AIと対話で 調達仕様を 具体化 調達仕様書 AB市役所 【ベンダー】 見積前の提案 / 見積 情報不足、かつ 時間不足 AIが大量の 情報を解析 適切に提案／ 見積作成 見積前提案書 見積書 【各省庁】 調達の評価 【ベンダー】 システム開発 大量の チェック項目で高負荷 個人の知識、経験、ノウハウ 評価／ 確認事項を 一次評価 AIが、 一次評価結果 判断を支援 A B市役所 よる 開発 効率 AI活用に の 化 設計書 プロダクト 設計書 プロトタイプ エ ジェント AI ー 過去の設計書仕様 ROUTE06 Slide deck ROUTE06,INC. ALL RIGHTS RESERVED 調達側 STEP 1：調達依頼書の作成 調達依頼に必要な質問をAIが適切に聞いてくる 答えた回答に合わせて、深堀り／相談が可能 定められたフォーマットに合わせて出力が可能 別紙：調達仕様書.pdf AB市 AB市役所 AB市 AB市 電子申請システム AB市 窓口DXシステム AB市 AI活用推進基盤 従来: 2週間 → 3日。必要な事項を相談しながら進められるので調達依頼書の品質も向上 ROUTE06 Slide deck ROUTE06,INC. ALL RIGHTS RESERVED ベンダー側 STEP 2：見積前のシステム提案書、及び見積書の作成 AIが大量の仕様を読み込み判断情報を整理 人とAIが適切に議論し見積書を作成 フォーマットに合わせた見積書の作成が可能 別紙：見積書.pdf AB市役所 AB市 AI活用により見積精度と提案スピードを高めることで 少人数でも大規模システム開発案件への提案が可能となり入札機会の拡大につながる。 ROUTE06 Slide deck ROUTE06,INC. ALL RIGHTS RESERVED 調達側 STEP 3（1/2）：見積レビュー 事前に用意したレビューチェックリストを元に自動で レビューを実施 チェックリストをベースに点数を付与 更に、ベンダーへの確認事項をリストアップ AB市役所 見積書が大量、かつ複数あっても公平に定量評価が可能。追加確認事項も明確になり、リスクをヘッジ ROUTE06 Slide deck ROUTE06,INC. ALL RIGHTS RESERVED 調達側 STEP 3（2/2）：評価 作成した見積レビューを ベースに評価を指示 見積比較まとめレポートを作成。
 更に、それぞれの評価をExcelで比較できるように出力。こちらをベースに検討が可能 AB市役所 従来人力で確認していた項目を、10分程度で初版レビューが可能に。人は本質的な議論／比較に ROUTE06 Slide deck ROUTE06,INC. ALL RIGHTS RESERVED ベンダー側 STEP4：設計／実装にする 調達時の見積設計書 システム設計＆開発をAI活用 システムテストを AIで効率化 ケースの自動生成・実行 調達で見積設計した情報をベースに、設計書作成、実装、テスト、プロジェクトマネジメントの効率化 ROUTE06 Slide deck ROUTE06,INC. ALL RIGHTS RESERVED 2026.04.16 02 提言 短期・中期施策と期待効果 ROUTE06 Slide deck ROUTE06,INC. ALL RIGHTS RESERVED ご提案 調達業務／評価におけるAI活用の導入 → クイックに効果を実現 調達向けAIエージェントの構築 パイロット案件での実証実験 Proposal ご提案 AI活用の基盤構築 → AIが活用しやすい状況に AI活用のガイドライン 過去案件情報を活用可能に（RAG化） ROUTE06 Slide deck ROUTE06,INC. ALL RIGHTS RESERVED 2026.04.16 Be a Disruptor. ROUTE06 Slide DECK Route the edge,
 Build the core. RIGHTS RESERVED ROUTE06,INC. ALL

資料５ 政府情報システム調達における AI駆動型開発の導入促進 に関するご提案 1 J ite ra について 「創る」の次の時代を創る。 2 認証 ISO/IEC 27001:2022、SOC2 TypeⅡ保証報告書受領 所在地 日本 〒10 5 - 0 0 0 3 東京都港区西新橋1丁目2 - 9 日比谷セントラルビル Sing a p o re 18 ROBINSON ROAD, # 2 0 - 0 2 , 18 ROBINSON, 0 4 8 5 4 7 USA 2 14 Ho m e r Ave , Pa lo Alto , CA, 9 4 3 0 1 従業員数 約13 0 名（グループ連結） 資本金 9 9 百万円（資本準備金を含む） 設立 2 0 17年8 月 AI Co n te xt Pla tfo rm J ite ra - 特許取得済み (第778 9 2 8 4 号*) コード、ドキュメントをインポートしコンテキストを増やし 溜まったコンテキストを使ってコード、ドキュメントをさらに生成 コード ドキュメント ・COBOL ・Pyth o n ・J a va s c rip t ・ABAP ・HTML ・C ・他あらゆる言語 ・要件定義書 ・概要設計書 ・詳細設計書 ・画面設計書 ・テーブル定義書 ・テスト仕様書 ・コーディング規約 MD 3 *生成AI（LLM）を用いてソースコードから要件定義書・設計書・テスト仕様書等のドキュメントを逆生成（リバースエンジニアリング）し、コードの変更に 合わせてドキュメントを自動で更新可能とする一連の技術プロセスについて、特許（特許第778 9 2 8 4 号）を取得 コンテキストとは DBに溜まっているデータ、仕様書や設計書などのドキュメント（形式知） 人間のコミュニケーションで交換される非形式知がAIにとってのコンテキスト AIにとってのコンテキスト 貯める 構造化データ DB内のテーブル・レコード・API経由で取得可能なデータ 形式知 コード、仕様書、設計書 (Ma rkd o w n , PDF, Exc e l e tc …) 非形式知 AIエージェント 使う 設定 スケジュール実行 We b h o o k Skill スケジュール実行 We b h o o k Skill スケジュール実行 We b ho o k Skill スケジュール実行 We b ho o k Skill 実際にAIを用いて入札の擬似演習による検証を実施 実際に公開されている入札案件などを元に擬似入札の演習を実施 AIを用いた公共案件への取り組みの検証により課題を抽出 ご協力いただいた開発ベンダー様 ベンチャー 地方中小ベンダー 準大手SIer 5 一例）調達・契約業務管理システムの導入等業務一式 （子ども家庭庁） 検証結果 6 クオンティア様、検証内容発表 7 ヒアリング結果 顕在課題 8 1 既存ベンダーと発注者の間にプロジェクトに関 する知識の差が発生している 2 要件が曖昧であり、解釈の余地が大きいため仕 様が揺れるリスクがある 3 政策目的の優先度判断不能、前提条件が提示さ れない場合の判断保留などが起きてしまう 根本課題 AI Ready な コンテキスト の欠如 全てのプロセスにAIを導入し、発注者< > 受注者でコンテキストを共有しあう仕組みへ 霞ヶ関WAN / 政府共通ネットワーク等 セキュアな環境 発注者 コンテキスト 受注者 現状分析 業務フロー・要件定義 入札参加 評価 提案書 発注 進捗確認 受け入れ 運用 9 受注 設計書 設計 コード 開発 テスト仕様書 検査 マニュアル 他ドキュメント、会議内容、メール他 人間が行うコミュニケーションを含む 運用・保守 AI駆動開発による質の高いソフトウェアを創るために 課題 Exc e lやPo w e rp o intなどのフォーマットは現在のAIの精度ではあまり相性が良 くない。 解決 Markdown 形式及びMermaid 記法を用いたドキュメントに集約していくことで 、AIが読みやすい形式・出力しやすい形式となる。 課題 関連するプロジェクトのドキュメントなどが参照しづらい状態であるため、AI を活用したプロジェクトを公共案件で行いにくい。 解決 過去の資料が残っている場合はその資料を安全な環境にあるAIエージェントに 蓄積し、受注者が過去の経緯を理解したAIエージェントを使えるようにする。 課題 AIを意識した形の発注方式にしない場合、その次に発生する運用保守や関連プ ロジェクトでもAI活用がしにくいという負のループが起きる可能性がある。 解決 発注者がコンテキストを保持し、運用・保守を行う業者でも活用できるように することでAI駆動による運用・保守ができるようにしていく。 AI Ready な 状態にする 過去案件の コンテキストを 共有する 新規案件ではAI 活用を意識した 状態にする 10 Ma rkd o w n 及びMe rm a id について Ma rkd o w n及びMe rm a id を用いることにより、チャートやグラフも対応可能。 トークン量の観点からもAIへの負担を軽減できるため、AI駆動開発において推奨されることが多い。 ビジュアライズされたもの ビジュアライズされた Mermaid Markdown 自体 Mermaid 記法 Mermaid 記法はガントチャートやフローチャート、その他グラフ等にも対応し表現力が高い 11 礼 12

資料６ 生成AIを活用した政府調達案件におけ る提案検討プロセスの実証記録 株式会社クオンティア 目次 ０１ 検証前提 ０２ エグゼクティブサマリー ０３ 実証を通じた所感 ０４ 最後に 検証前提 • 本検証を通じ、現行の調達仕様書および評価項目を前提とした場合でも、生成AIを用いて提案作業 の初期工程を効率的に進められることを確認しました。 • 特に、評価項目ごとの提案骨子を一定水準まで網羅的に整理できました。 検証対象 実案件 ⁃ 【デジタル庁】令和8年度デジタルマーケットプレイスカタログサイト開発及び運用等業務 実案件として公開されている調達仕様書および評価項目をそのまま使用 Input  調達仕様書(28P)  技術等提案書作成要領(5P)、総合評価基準書(5P)  評価項目(5P、計34項目) 各評価項目について、以下の内容を骨子レベルで整理 Output  評価項目が求める要件の要点整理  要件に対する提案の方向性・考え方  実績が不足する項目における「実績なし／代替案あり」等の前提条件整理 3 CONFIDENTIAL © Quontier, Inc. エグゼクティブサマリー • 本検証を通じ、現行の調達仕様書を前提とした場合でも、生成AIを活用した提案書作成が可能であ ることを確認しました。(提案骨子の整理は、提案書作成工程において最も検討負荷の高い工程の一つと思料) • また、一定の工夫を行うことで、評価項目に対応した提案書を作成できる可能性が示されました。 「現状の調達仕様書を前提に、生成AIを用いて提案の構造をどこまで短期間で整理できるか」 前提 ⁃ 本実証は、実在する政府調達案件を対象に、生成AIを用いて「提案検討・提案骨子作成」工程を実施したもの。 ⁃ 要件定義、設計、開発、テスト等の実装工程におけるAI活用検証は本実証の対象外。 ⁃ また、今回の検証範囲は、提案書そのものの作成ではなく「提案骨子の整理」までとしている。 調達仕様書・評価項目をインプットとして活用し、評価項目ごとに一定水準の提案骨子を作成できた 検証結果  作成に当たって架空のSier企業がJitera(生成AIソリューション)を用いて提案書を書くというシナリオを想定して実施。  調達仕様書及び評価項目（34項目）の内容をAIが“読解“しWBS及び見積もりが作成できることを確認できた。 提案骨子整理までに要した総作業時間は、約4人日 作業時間  生成AI（Jitera）を用いた作業：約 3人日 (※初回検証のため、プロンプト調整等の試行錯誤を含む)  人手による補完作業：約 1人日 (※AIが出した回答に対する人のRVが中心のため、この時間の削減は難しいと思料) 実証を通 じた所感 現時点で残る課題  図式化やスケジュール表現などは、引き続き人手による整理が必要と理解した。  提案骨子整理と、最終的な提案書表現との間には、一定の人手工程が残ることを確認できた。 4 CONFIDENTIAL © Quontier, Inc. 実証を通じた所感｜AI特有の事象(具体例・一部) • 評価項目ごとの提案骨子を、追加説明や事前補足を与えずに生成AIで作成した結果、AIが一定の 箇所で判断を進められなくなる挙動が、複数の項目で共通して確認されました。 • 以下は、今回の検証で実際に観測された AI側の処理特性です。 AI特有の事象 複数の政策目的が並列に記載された場合、提案の力点を自律的に決定できない 提案骨子生成において、AIは仕様書に明記された業務目的・政策背景・課題をすべて正確に抽出 政策目的の ⁃ ⁃ しかし、仕様書にはどの目的を最優先で扱うべきかを判断する記述が存在しなかった 優先度判断不能 ⁃ AIは目的Aを前面に出す。目的Bを補助的位置づけにするといった構成選択を行わず、すべてを同列 に配置した提案構造を生成 → 人手による再整理を行うまで、提案の「軸」を一本に定めた構成に収束できなかった 前提条件が与えられない場合、AIは単一解を選ばず安全側に振る舞う 前提条件不足による 判断保留 ⁃ 設計・実装方針に関する骨子生成では、AIは妥当だが汎用的な構成案を複数提示した ⁃ 既存システムとの関係、引き継ぐべき設計思想、制約条件が明確でなかった ⁃ そのためAIは、特定の方式や構成に踏み込まず、複数案を保持したまま整理を止める挙動を示した → 「一案に絞った提案」ではなく「条件付きの整理」に留まった 5 CONFIDENTIAL © Quontier, Inc. 最後に • AI活用を前提とする時代においては、評価軸の優先度、判断基準、前提条件を「暗黙知に頼らず言 語化する」調達仕様の高度化が不可欠であると思料。 • これは提案者負担の軽減だけでなく、調達の公平性・再現性・品質向上に直結する。 提言 評価軸の 優先度・重視点が不明確 実務上の判断基準 （暗黙知）が言語化  仕様書から評価要素は読み取れるが、重視度や配点が明示されていないため、AIは全要 素を等価に扱う。結果として「どこまで書けば十分か」を提案者側が仮定せざるを得ない 構造となっている。 されていない  管理手法は記載可能でも、報告頻度・判断粒度・過去の重要論点など、発注者が重視する 実務基準が不明確。その結果、一般論として整っているが、評価の焦点が見えにくい提案 となる。 前提条件・制約条件の 提示粒度が不足  既存資産・制約・設計思想の継承有無等が十分に示されず、AIは踏み込んだ判断ができな い。「どこまで仮定してよいか」が定義されておらず、提案者の解釈補完が不可避となって いる。 6 CONFIDENTIAL © Quontier, Inc. 資料に含まれる情報の取り扱いについて 本資料中の技術情報、価格情報その他の情報は株式会社クオンティアの 秘密情報（ないし機密情報）です。同社による事前の許諾なく、これら情報の一部または 全部を複製、仕様、公開することは、いかなる場合も禁じられております。 株式会社クオンティア 実施 検証結果｜概要(補足※提案書策定プロセス) 未実施 • 提案骨子作成までの大まかな策定プロセスは、下図を参照 • 基本は、調達仕様書をインプットにし、それぞれ評価項目ごとに提案骨子を作成した。 調達仕様書などを インプット 左記情報から自社必 要な情報の洗い出し 自社実績マスタ作成 インプット情報から 要件の抽出 自社適格性判定 （NGの場合は、自社 内で充足観点確認) 評価項目ごとの 提案書骨子作成 QA作成 （不足情報洗い出し) WBS作成 見積作成 QA回答 回答をもとに 内容修正 提案書完成 8 CONFIDENTIAL © Quontier, Inc. 検証結果｜詳細｜評価項目一覧(1/2) No 評価区分 大項目 中項目 評価項目名 1 必須 基本理解・方針 事業理解 デジタルマーケットプレイスの役割理解 2 必須 基本理解・方針 基本方針 業務目的・背景・基本方針 3 必須 基本理解・方針 課題整理 課題理解および解決方針 4 必須 作業計画 スケジュール 作業スケジュール 5 加点 作業計画 スケジュール高度化 作業スケジュール（加点評価） 6 必須 実施体制 体制構成 作業実施体制 7 必須 実施体制 役割定義 役割分担・責任範囲 8 必須 実施体制 要員要件 作業要員の資格・要件 9 必須 実施体制 継続性 要員の継続性・安定性 10 必須 プロジェクト管理 作業環境 作業場所 11 必須 プロジェクト管理 管理手法 プロジェクト管理方法 12 必須 プロジェクト管理 品質・進捗 進捗管理・品質管理 13 必須 要件定義・設計 業務要件 業務要件定義 14 必須 要件定義・設計 要件整理 業務要件整理の進め方 15 必須 システム設計 機能設計 機能要件整理 16 必須 システム設計 画面設計 画面設計方針 17 必須 システム設計 API設計 API設計方針 提案骨子としての到達度  仕様書引用＋自社の解釈（DMPの位置づけ／遵守宣言／取組方針の柱）まで骨 子化されている。かつ、要件遵守の明示もあり  ただし、現行課題・利用状況・フィードバックが仕様書に無く、AIは「課題を踏まえ た方針」の具体化で止まる  フェーズ・マイルストーン・環境別作業・スクラム運用（2週スプリント、会議体、年2 回以上リリース）まで具体化  ただし、図式化はできなかったため、マスケなどは人の手で作成する必要有  6役割の資格・専任要件充足、再委託方針、ツール（Jira/Confluence）等を具体化。 要員資格も職種別に要件充足根拠が表形式で明確  進捗を数値目標で定量管理、遅延レベル定義（4段階）、報告基準まで具体。  作業場所もセキュリティ認証・具体対策まで明記  ただし、「判断基準・重視点が仕様書外にあると一般論に寄りやすい  留意点を5つ挙げ、具体的リスク例まで書き、アプローチで合意・文書化・監視（標 準ガイドライン改定チェック等）に落とし込み  ただし、ここは本来「追加資料・現行理解」によって具体度が上がる領域なため詳 しい検証はできていない  開発対象ごとの「遵守」「要件定義で確定」「根拠実績」などが表で整理  加点の画面観点も具体方針有  ただし、「既存システムの関係・設計思想・制約条件が明確でないと、AIが特定の 方式に踏み込まず“条件付き整理”に留まりやすい」 9 CONFIDENTIAL © Quontier, Inc. 検証結果｜詳細｜評価項目一覧(2/2) No 評価区分 大項目 中項目 評価項目名 18 必須 開発・テスト 開発手法 開発手法 19 必須 開発・テスト テスト方針 テスト方針 20 必須 開発・テスト 品質確保 品質確保の考え方 21 必須 運用・保守 運用設計 運用設計 22 必須 運用・保守 開発テスト 開発テスト 23 必須 運用・保守 受入テスト 受入テスト 24 必須 運用・保守 移行・引継ぎ 引継ぎの実施方法 25 必須 ガバナンス 会議体 会議体運営 26 必須 ガバナンス 意思決定 意思決定プロセス 27 必須 運用体制・信頼性 運用体制 運用体制 28 必須 運用体制・信頼性 認証・資格 公的資格・認証 29 必須 実績・企業評価 実績 受注実績 30 加点 実績・企業評価 付加提案 追加提案 31 加点 社会的要請 労働環境 ワークライフバランス（WLB）認定 32 加点 社会的要請 賃上げ 賃上げ表明 33 加点 政策・制度対応 デジタル施策 マイナンバーカード利活用指標 34 加点 政策・制度対応 産業連携 デジタルスタートアップ連携 提案骨子としての到達度  アクセシビリティ準拠基準（JIS/WCAG等）、ユーザーテスト反映サイクル、スクラム 会議体、受入基準、脆弱性診断、工程定義・品質指標までフロー図＋表で具体化  ただし、「品質基準」「受入基準」の具体定義が未提示  会議体一覧（目的・頻度・所要時間・アウトプット）＋事前準備・会議運営ルール・議 事録/チケット化まで具体化  運用はITIL統合、監視種別・対応時間、問い合わせSLA、保守リリース計画（年間12 人月）まで具体。引継も6必須項目充足を明示し、対象・体制・完了判定まで構造化  「追加提案」は、現行アーキテクチャ・運用実態・ボリューム・ユーザーテスト結果・ 予算感などが非公開だと具体化できない ー ー 10 CONFIDENTIAL © Quontier, Inc. 検証結果(要件の理解)｜例｜No.1、No.28 • No.1：明快な表現での言い換えや、仕様書記載のすべての要件について遵守する旨の記載や • No.28：要件を満たす資格、認証等を取得している旨が整理できることが判明。 No.1：デジタルマーケットプレイスの役割理解 No.28：公的資格・認証 11 CONFIDENTIAL © Quontier, Inc. 検証結果(業務目的・背景・基本方針の整理)｜例｜No.２ • 業務目的・背景・基本方針を提案軸となる骨子として整理できることがわかりました。 業務目的・背景・基本方針の整理 No.2：業務目的・背景・基本方針 業務目的・背景・基本方針  発注者が本業務に期待している背景課題解決したい状態を 踏まえた基本方針を明確化  単なる要約ではなく、提案全体の前提となる考え方・スタン スとして骨子化 提案骨子として整理できた内容  業務の位置づけ（なぜこの業務が必要か）  提案全体を通じて重視すべき基本方針  後続のスケジュール・体制・技術・運用方針につながる 前提条件の整理 12 CONFIDENTIAL © Quontier, Inc. 検証結果(WBS及び詳細見積作成)｜例｜No.4 • 提案骨子の整理を行った結果、業務全体の作業構造をWBSとして整理することができました。 • それに伴い、タスク単位での工数算出が可能となり、詳細な見積作成まで行えました。 WBS及び詳細見積もり No.4：作業スケジュール(＋見積もり) WBS作成の結果  全体タスク数は約400タスク規模になると試算  評価項目・業務内容を起点にフェーズ・タスク分解を実施  実行可能な粒度のWBSを作成  フェーズ別（フェーズ1〜5）のタスク一覧まで整理 詳細見積の作成  WBSに基づき、タスク単位で工数を積み上げ  その結果、詳細レベルの見積書（見積.md）を作成  単なる概算ではなく、作業内容と対応付いた見積を提示で きる状態に到達 13 CONFIDENTIAL © Quontier, Inc.

資料７ デジタル庁における情報システム開発へのAI活用の取り組み 令和8年4月16日 デジタル庁 戦略・組織Ｇ はじめに 情報システム開発におけるAIの活用は、従来の人が主でありAIがコードを補完するという関係から、エージェントによる自 動、自律的なコード生成/変更へと大きく進化している。 また、情報システム開発におけるAIの活用領域は急速に拡大しており、コーディングだけではなく、レビュー、テストコー ドの自動生成、セキュリティチェック、ドキュメントの生成など、情報システム開発のあらゆるフェーズでAIが活用されてい く可能性が高い。 以上のような認識のもと、デジタル庁における情報システム開発へのAI活用に向けた２つの取り組みを報告する。 【目次】 はじめに １ ２ デジタル庁内部開発環境への開発支援AI導入 システム開発文書レビューへのAI活用（1/3 実施概要） システム開発文書レビューへのAI活用（3/3 本格導入に向けた課題） システム開発文書レビューへのAI活用（2/3 検証結果） 2 １ デジタル庁内部開発環境への開発支援AI導入 デジタル庁では、令和8年4月からデジタル庁内部開発環境に開発支援AIを導入。 開発支援AI デザイン・開発支援(AI) 実施スコープ デザイン・開発支援 4月から導入 プロジェクト管理 各種クラウドサービス 開発者・ デザイナー用端末 デジタル庁内部開発環境 導入時期 令和8年4月 （※上半期中に導入後の効果測定結果 を取りまとめる予定） 対象環境 デジタル庁内部開発環境 利用対象者 当庁で開発業務等を行っている職員 （一部） 対象工程 コーディング 政府情報システムにおける設計開発および運用保守の内製化を促進するためのメインソリューションとして、今後、AI利活用 を推進していくうえで、 ➀ 公知情報と比較した当庁における生成AI利活用効果測定結果をふまえたAI適用可能性、または乖離度合いを計測 ➁ 庁内におけるAI利活用推進に関する今後の具体的対応方針を検討するための情報を収集 することを目的に検証を実施。 令和8年度下期からは、情報システム開発の一連のプロセスにスコープを拡大した検証を検討中 3 ２ システム開発文書レビューへのAI活用（1/3 実施概要） デジタル庁では、事業者から提出されたシステム開発文書の受け入れレビュー時にAI（以下、DR_AI※1）を活 用する実証実験を昨年度実施。 Input レビュー対象箇所の抽 出 システム開発文書※2 →pdf化された複数文書対応 →図表・テキスト等の リッチドキュメント対応 【検証観点１】 システム開発文書を理解して、 評価質問に合致した箇所を抽出 できているか？ 【検証観点２】 各評価質問に対して適切な評価/ 判定が行われているか？ 【注釈】 Output 評価/判定の自動化 文書レビュー チェックリスト (評価質問※3 +成功基準※4 ) 評価/判定結果と是正提案 DR_AI 評価/判定結果 に基づく是正案の 自動生成 チェック項目毎の 評価/判定結果 (指摘事項) 【検証観点３】 LLM、Web検索、デジタル・ ガバメント推進標準ガイドラ インを踏まえ適切な是正提案 が行われているか？ LLM+Web検索※5 + デジタル・ガバメント 標準推進ガイドライン(RAG) ※1 DR_AI ：Document Review support AI agent（ドキュメントレビュー支援AIエージェント）の略 ※3 評価質問：チェックリストのチェック項目のこと ※5 Web検索：個人投稿できるブログ等を除外、デジタル庁、政府機関の発刊物、 IPA、 Microsoft公式ドキュメント等の公的機関や権威ある組織・団体中心に検索 ※2 ※4 システム開発文書：本実証実験では「基本設計書」と「全体テスト計画書」の2種類が対象 成功基準：チェック項目がどのような状態になればOKになるのかの具体的な基準 4 ２ システム開発文書レビューへのAI活用（2/3 検証結果） 網羅的な文書理解、評価/判定結果の妥当性、是正案の妥当性に対して、正答率70～90%を記録した。 【検証観点１】 システム開発文書の理解度 【検証観点２】 評価/判定結果の妥当性 成功基準を設けることで、+10%程度高い正答率 検索対象指定はLLMフィルタによって正答率は90%近くへ 76% 87% 73% 85% 76% 89% 検索手段によって品質・精度は5%以内で大差なし 是正根拠の検索AIに渡されるデータの精度が正答率に比例 大差なし 76% 85% 【検証観点３】 是正提案の妥当性 85% 75% 82% 70% 90% (上限) 76% 88% (下限) 71% LLM LLM+Web検索 LLM+ガイドライン 評価質問 成功基準 評価質問 成功基準 評価質問 成功基準 評価質問 成功基準 全文検索型 検索対象指定型 全文検索型 検索対象指定型 評価質問 成功基準 全文検索型 LLM+Web検索+ガイドライン 評価質問 成功基準 検索対象指定型 文書理解・評価/判定結果・是正案生成の品質は実運用を検討するに値する水準であると評価 5 ２ システム開発文書レビューへのAI活用（3/3 本格導入に向けた課題） 今回の検証を通じて、開発ドキュメントのレビューにAIを活用する可能性が定量的な根拠をもって確認でき た。同時に本格導入に向けた課題も見えてきており、さらなる検討が必要である。 関連組織 庁内 関連部署 利用者 （レビューア） 本格開発・導入に向けた課題    システム開発事業者との契約書において、知的財産権の譲渡前である開発事業者の作成物に対して庁内AIによる分析・評価の許可や、作成物にプロ ンプトインジェクション攻撃*を忍ばせることの禁止などについて考慮する必要がある。 レビューアのDR _AI利用ニーズを踏まえて、レビュー対象とするシステム開発文書の範囲を拡大する必要がある。 レビュー対象とするシステム開発文書の範囲を拡大する際は、運用負荷とレビュー精度を両立させたチェックリストの作成・整備と、品質検証用 の模範解答(Ground Truth)の作成・整備が必要になる。 業務要件    DR_AI 開発者 非機能要件  機能要件 DR _AIのための低付加価値の作業（機械可読性を考慮したドキュメントの形式変換 等）を不要とする、またはシステム開発業務 に溶け込ませることで意識せず開発できるような、DR _AIとの役割分担・責任範囲の設計が必要である。 レビューアが日常的にDR_AIを利用する際の文書レビューの目的やチェックリスト、コスト分担の設計や、運用・保守業務の設計 (チェックリストメンテナンス、DR_AIの運用・保守業務、運用・保守体制の整備等)についても検討が必要である。 開発や運用・保守に係る工数・コストを上回る工数削減効果が実現可能な非機能要件の定義が必要となる。 例：期待する品質水準 許容される処理時間 AI特有のリスクへの対応（判断根拠の説明不足、ハルシネーション、機密情報の流出、プロンプトインジェクション攻撃 等) 実用性のあるDR_AIの実現に向けた機能要件の定義が必要となる。 例：システム開発文書の拡大に伴う、各文書固有の図表読取品質の確立 超大容量文書での精度・コスト最適なアーキテクチャ設計 PDF以外のpptx、docx、xlsx等のマルチフォーマットへの対応 レビューアへの効果的な是正提案方法の設計(Excel出力、是正提案の伝え方・優先順位の設計等) 6 7

資料８ 政府情報システム調達における AI 駆動開発の導入に向けた提言 2026 年（令和 8 年）4 月 16 日 内閣府規制改革推進会議 デジタル・AIWG 専門委員 村上 将一 村上 文洋 住田 智子 1. AI 駆動開発がもたらす本質的変化 近年の生成 AI をはじめとする AI 技術の進展は、ソフトウェア開発の在り方に本質的な変化をもたら している。 従来の開発は、仕様を事前に定義し、それに基づいて設計・実装を行うことを前提としていたが、AI の 活用により、要件、設計、コード、テスト等を生成し、その結果を評価しながら継続的に改善する開発手 法が遠い将来ではなく、すでに現実のものとなっている。 この変化は、単なる作業効率の向上にとどまらず、  知識や設計情報の構造化及び再利用  開発プロセスの短縮及び柔軟化  品質管理の高度化及び自動化 を同時に実現するものであり、ウォータフォール型、プロトタイプ型、アジャイル型などの各システム開 発手法において「人が仕様を決め、実装し、改善する」 （決定論的開発）から、 「AI が設計やコードなど の候補を生成し、試行した評価とそのフィードバックによる改善をループしながら最適化を目指す」 （非 決定論的開発）へと転換するものである。 このような開発体系（以下「AI 駆動開発」という。 ）は、従来の制度やプロセスを前提とした部分的な 改善ではなく、開発・調達の前提そのものを見直す契機となるものである。 2. 政府情報システム調達のあるべき姿 AI 駆動開発を前提とした場合、政府情報システム調達のあるべき姿は、以下のように再定義され得る。 （1）知識と成果物が構造化され、共有される調達 要件定義、設計、開発、テスト等の成果物が、AI による処理及び再利用を前提とした形式で整備・ 共有され、特定の事業者に依存することなく、他の事業者や後続工程において容易に活用できる状態が 実現されるべきである。 これにより、従来、特定の事業者に依存してしまった結果、既存事業者に占有されてしまい、暗黙知 として、ブラックボックス化していた設計・実装知識、運用上の課題等（コンテキスト）が発注者側に もドキュメンテーションとして共有化され、他の事業者にも可視化されれば、調達における情報の非対 称性の解消を促し、情報システムの品質の平準化を推進する力となる。 1 （2）生成と評価を組み合わせた開発・調達プロセス 要件、設計、コード等を AI により生成し、その結果を多面的に評価し、改善を繰り返すプロセスが 開発・調達の中核となるべきである。 この場合、仕様は一度確定して固定するものではなく、評価結果や利用状況を踏まえて継続的に更新 される「仮説」として扱われ、 「仮説」 、 「検証」、 「改善」のサイクルの中で、ビジネスモデルを実施し、 当該ビジネスの目標に真に近づけていくものとなる。 （3）リスクに応じた制御と人間関与の組み込み（AI Safety Mechanism） AI の出力は必ずしも決定的ではないことを前提とし、その利用に当たっては、  出力内容のリスクに応じた制御  必要に応じ、人間による確認・判断  不確実な場合の出力抑制 等を組み込むなど、AI が安全に利用される環境が整備された形で運用されるべきである。 これにより、AI の活用と安全性・信頼性の確保が両立される。 （4）発注者主体の意思決定と能力補完 AI の活用により、要件定義に加え、開発仕様（設計）、テスト・評価の方法、評価結果等を踏まえた 出力制御や人間へのエスカレーションの在り方について、発注者が主体的に判断・設計できる環境が整 備されるべきである。 AI 駆動開発では、生成内容そのものだけでなく、何をもって妥当と評価するか、どのような場合に 自動処理を控えるか、どのような場合に人間の関与を求めるかが、品質と安全性を左右する。これらを ベンダー任せにせず、発注者が、その能力・経験を AI で補いながら、主体的に意思決定できる体制を 整えることにより、特定の事業者に依存することなく、適正なシステム構成、価格、品質水準及び統制 の在り方を判断することが可能となる。 （5）継続的に改善されるシステム運用 システムは一度構築して完結するものではなく、運用を通じて評価・改善が継続的に行われることを 前提とし、そのためのデータや成果物が蓄積・活用する状態、すなわち AI-Ready を目指すべきである。 3. 標準ガイドラインの再構成に向けた方向性 上記のあるべき姿を実現するためには、現行の標準ガイドライン群について、個別の手続や記載内容の 修正にとどまらず、設計思想の転換を伴う見直しを行うことが必要である。 標準ガイドラインの見直しに当たっては、AI 駆動型開発が可能である旨を明示し、その方法や留意事 項等を整理するとともに、以下の点を重視すべきである。 （1）AI 活用を前提とした開発プロセスの位置づけ/発注者側のＡＩ活用の位置づけ 事業者が AI 駆動開発を積極的に提案できるようにするため、従来の仕様の確定を前提とした一方向 的なプロセス（決定論的開発）に加え、AI 駆動開発時代における生成と評価を反復するプロセス（非 2 決定論的開発）を標準的な開発手法として明確にし、発注者が AI を活用することを前提とした役割及 びプロセス等を明確化する。困難が伴う要件定義書や設計書、仕様書等の更新については、AI を活用 し、非決定論的開発プロセスの中で、コンテキストの蓄積も含め、常に最新化されるように留意する。 （2）成果物の機械可読性・構造化の標準化 AI-Ready で、政府情報システムの調達・開発の課題を解決するエコシステムな環境を目指すため、 要件定義書、設計書、仕様書等について、AI による利用及び再利用を前提とした形式・構造を標準と して定義する。 （3）AI 生成物に対する多面的な評価の仕組みの導入 AI 生成物の品質を担保するため、AI によるレビューや自己修正も含め、IT ガバナンス及び IT マネ ジメントの各プロセスに、正確性、整合性、安全性等の観点に基づく評価の枠組みを整備し、開発プロ セスに組み込み、AI 駆動開発に対応する。 （4）リスクベースの制御及び人間関与の明確化 AI の利用に伴うリスクを回避するため、例えば、例外処理テストや負荷テストなど AI が判断するこ とが困難なものも含め、リスクに応じて、AI による出力結果の取扱いや AI へのデータの入出力への人 間の関与の在り方を整理し、標準的な運用手法として明示する。 （5）段階的導入と実証の推進、コミュニティへの参加等 上記の内容を一気呵成に行うのではなく、既存制度との整合性を確保しつつ、実証的な取組を通じて 適用範囲を段階的に拡大し、工期・工数・経費の積算の妥当性も含め、知見を蓄積した上で、実行的な プロセス形成を行う。また、民間において最先端な取り組みが行われていることから、本件における先 駆的な知見を有する民間やコミュニティとの継続的な対話や参加が必要である。 4. おわりに AI 駆動開発は、政府情報システム調達における効率化手段にとどまらず、知識の共有、競争環境の改 善、品質管理の高度化を同時に実現し得るものである。 このため、標準ガイドライン群についても、AI の活用を前提とした開発・調達体系へと再構成するこ とにより、政府情報システムの競争性、効率性及び持続可能性の向上を図ることが求められる。 以上 3