カナダ・アルバータ州政府は、約 25 年前に 5 か月をかけて開発した行政システムを、AI Factory によって 4 日で再構築したと報告している。対象となったのは、遠隔地域で石油やプロパンを暖房に使う住民への補助を処理する Remote Area Heating Allowance システムである。再構築版には、従来の内部処理だけでなく、住民向けの申請画面と書類の直接提出機能も追加された。さらに州政府は、校長と教員が利用する Alberta Classroom Information Portal（ACIP）を、11 週間、約 10 万 8,000 カナダドルで本番公開した。従来型の製品開発チームであれば、同程度のシステムに 1 年から 1 年半、130 万から 190 万カナダドルを要したという[1]。
二つの数字は、同じ種類の成果を測っているわけではない。4 日で作られた遠隔地域暖房手当システムは、既存業務を知る元の開発者が実現可能性を確認した試作品である。一方、ACIP は新規に構築され、個人情報保護、セキュリティ審査、本人確認、本番基盤を含む統制を通過した業務システムである。前者が示すのは、仕様を理解している既存業務を短期間で再現できる可能性であり、後者が示すのは、組織的な審査と運用条件を含めても従来見積もりより短い期間で提供できた事例である。
比較対象の性質にも注意が必要である。遠隔地域暖房手当システムの 5 か月は、約 25 年前に実際に費やされた開発期間であるが、4 日には制度調査や要件発見をゼロから行う時間が含まれていない。ACIP の 1 年から 1 年半と 130 万から 190 万カナダドルは、同じシステムを別チームが並行開発した実測値ではなく、従来方式を採った場合の内部見積もりである。どちらの事例にも大きな差はあるが、その差をそのまま普遍的な速度倍率や費用削減率へ変換することはできない。
AI 支援開発に関する外部研究にも、条件によって異なる結果が現れている。限定された新規実装課題では、AI 支援によって完了時間が 55.8 ％ 短縮された研究がある[2]。これに対し、成熟した既存リポジトリを熟知する開発者を対象とした無作為化比較試験では、AI を使った参加者の作業時間が 19 ％ 長くなった[3]。新しく独立した機能を作る作業では、生成されたコードをそのまま利用できる部分が多い。既存システムの変更では、設計意図、依存関係、互換性、試験、既存規約との整合を確認する時間が増える。この違いが、同じ AI 支援でも逆方向の結果を生む。
作業単位の速度と、システム全体の提供速度を分ける必要がある理由もここにある。第一段階では、AI がコード、試験、文書、設定を生成することで、実装に必要な時間が短くなる。第二段階では、生成された成果物を既存要件へ適合させ、セキュリティを確認し、関係者が承認し、本番環境へ移す工程が残る。前半だけが速くなっても、後半が従来のままであれば、プロジェクト全体の短縮幅は限られる。AI の有無だけではなく、対象業務の性質、既存知識、品質条件、確認負荷、組織内の承認経路によって最終的な効果が変わる。
アルバータ州の事例が示す固有の変化は、この後半まで開発工程の対象にしたことである。AI Factory は、コードを生成する機能だけで構成されていない。要件と完了条件を定義し、エージェントが作業する実行環境を用意し、生成物を検証し、権限と操作を記録し、本番へ配備し、そこで得た知識を次の案件へ引き継ぐ一連の仕組みとして構築された。個々の作業を速くする道具を導入したのではなく、個別案件ごとに繰り返していた判断と作業を、再利用可能な工程へ移している。
既稿では、生成 AI の能力を業務成果へ変えるには、データ、権限、確認、監査、既存システム、運用、責任分界を接続する業務実装が必要だと整理した[4]。AI Factory は、この業務実装がソフトウェア開発の生産ラインとして具体化された事例に位置づけられる。生産ラインという表現が指すのは、大量にコードを生成することではない。同じ種類の判断、基盤、検査、配備手順を案件ごとに作り直さず、後続案件が先行案件の成果を利用できる構造である。
本稿を貫く問いは、5 か月が 4 日になったという倍率そのものではない。問うべきなのは、5 か月の工程に含まれていた何が省略され、何が自動化され、何が共通資産へ移され、何が人間の判断として残ったのかである。この分解を行うことで、AI Factory の成果を過小評価せず、同時に一つの成功数字をあらゆる開発へ広げる誤りも避けられる。
1. 5 か月と 4 日は、同じ条件の比較ではない
1.1 旧システムを知る本人が再構築した
最初の事例は、Remote Area Heating Allowance という遠隔地域暖房手当の処理システムである。この制度は、天然ガス網から離れ、石油やプロパンを暖房に使う住民への補助を扱う。約 25 年前には、対象地域でインターネット利用を前提にできなかったため、申請者が必要書類を郵送し、州政府職員が内部システムへ内容を入力して小切手を発行していた。Chris Wright 氏は、この内部システムを Java で開発し、完成までに 5 か月を要した[1]。
AI Factory による再構築では、旧システムの処理を再現するだけでなく、住民が利用する公開申請画面と、書類を直接提出する機能が追加された。従来は郵送された書類を職員が受け取り、内容をシステムへ転記していた。再構築版では、申請者側から情報と書類を直接受け取れるため、画面の追加だけでなく、入力経路そのものが変わっている。4 日という期間は、旧版より多い機能を持つ試作品が短期間で成立したことを示している。
一方、再構築を担当した Wright 氏は、元のシステムを開発した本人である。制度の目的、必要な入力、期待される出力、職員の処理手順、旧システムが満たすべき条件をすでに理解していた。新しい開発者が制度文書を読み、利用部門へ聞き取りを行い、曖昧な要件を整理し、関係者間の認識をそろえるところから始めた事例ではない。業務知識を持つ人間が、既知の問題を AI Factory へ渡したという開始条件がある。
この開始条件は、4 日という成果を無効にするものではない。むしろ、何が短縮されたかを特定するために必要である。制度理解と要求の大枠が人間側に存在していたため、AI Factory は、実装方法の選択、画面と処理の生成、機能間の接続、試験、修正へ早く進めた。第一の原因は、生成 AI と自動化された工程によって、実装に必要な作業量が減ったことである。その背後には、業務の目的と評価基準を知る人間が、AI に渡すべき問題をすでに構造化できていたという条件がある。
4 日が測っているのは、未知の行政制度を発見し、合意し、制度化する速度ではない。問題の内容と期待される結果が分かっている状態から、動作する試作品を作るまでの速度である。この境界を明確にすると、AI Factory が得意とする部分も見えやすくなる。既知の業務を、既存の標準と部品を使って実装可能な形へ変換する工程では、大きな短縮が生じている。
1.2 試作品と本番システムを分ける
遠隔地域暖房手当システムの再構築は、一次情報でも試作品と位置づけられている。試作品の目的は、必要な機能を実現できるか、生成された処理が元の業務要件に合うか、追加した申請経路が成立するかを確認することである。元の開発者が評価した結果、出力の品質は期待を満たしたと報告されている[1]。
試作品が動作することと、行政サービスとして継続運用できることの間には、複数の工程がある。利用者や職員の情報をどの範囲で保存するかを決め、権限のない利用を防ぎ、障害を検知し、復旧手順を用意し、利用者からの問い合わせへ対応しなければならない。さらに、システム変更後も制度要件を満たしているかを確認し、監査時には誰が何を行ったかを説明できる必要がある。試作品は機能の成立を確認するが、本番システムは機能に加えて、継続利用と説明責任を引き受ける。
ACIP は、この本番運用側の条件を含む事例である。校長と教員が利用する新規システムとして構築され、2026 年 6 月 1 日に公開された。個人情報保護、セキュリティ審査、本人確認、本番基盤を含む本番業務向けの統制が必要であり、州政府は従来の製品開発チームが提供するシステムと同じ基準を適用したと説明している。所要期間は 11 週間であり、4 日の試作品より長いが、従来方式による 1 年から 1 年半という見積もりより短い[1]。
4 日から 11 週間へ期間が延びた直接の理由は、本番公開に必要な確認と統制が追加されたことである。さらに背後には、行政システムが単独のプログラムではなく、個人情報保護、認証、基盤運用、組織上の承認、利用者支援を含むサービスとして成立しているという構造がある。コードの生成が完了しても、これらの条件を満たさなければ、行政サービスとして利用を開始できない。
| 比較項目 | 遠隔地域暖房手当システム | ACIP |
|---|---|---|
| 開発目的 | 既存業務を AI Factory で再構築できるかを確認する試作品である。 | 校長と教員が実際の業務で継続利用する本番システムである。 |
| 出発点 | 元の開発者が制度、処理、期待される出力を理解した状態から始まっている。 | 新規システムとして、要件形成から本番公開までを進めている。 |
| 追加機能 | 住民向けの公開申請画面と書類の直接提出機能が追加されている。 | 利用者向け機能に加え、本人確認、個人情報保護、セキュリティ、本番基盤が必要である。 |
| 所要期間 | 4 日と報告されている。 | 11 週間と報告されている。 |
| 比較対象 | 約 25 年前に同じ開発者が 5 か月で作った旧システムである。 | 従来型の製品開発チームなら 1 年から 1 年半を要するという内部見積もりである。 |
| 費用比較 | 一次情報では、旧版と再構築版の費用比較は示されていない。 | AI Factory による費用は約 10 万 8,000 カナダドル、従来方式は 130 万から 190 万カナダドルと見積もられている。 |
| 証拠の強さ | 元の開発者が出力を直接評価できるが、本番運用の品質と費用は確認できない。 | 本番公開まで到達しているが、従来方式で同じシステムを並行開発した比較実験ではない。 |
| 確認できる成果 | 既知の業務を、追加機能を含む試作品へ変換する速度を示している。 | 組織的な統制を含む新規システムを業務へ届ける速度と費用の事例を示している。 |
二つの事例を分けると、AI Factory の成果がどの範囲に及ぶかを段階的に読める。遠隔地域暖房手当システムは、業務知識と期待される結果が既知であれば、実装と試作を大幅に短縮できる可能性を示す。ACIP は、その短縮効果が試作品の生成だけに閉じず、個人情報保護、セキュリティ審査、本人確認、本番基盤を伴う提供工程にも及んだ事例である。
同時に、証拠の限界も残る。遠隔地域暖房手当システムでは、本番移行後の障害率、保守費、利用者対応は測られていない。ACIP では、本番公開という事実は確認できるが、従来方式との期間・費用差は並行比較ではない。AI Factory の構築費も、個別案件の費用へどのように配賦されたかが明らかではない。得られた数字は有力な実務事例であるが、あらゆる行政システムに適用できる一般的な効果量ではない。
それでも、11 週間という事例は、4 日の成果を試作品特有の速さだけで説明できないことを示している。AI Factory は、実装を速くしただけでなく、本番公開までに必要な要件、基盤、検証、監査、配備の一部を、反復可能な工程として先に整備していた。次に確認すべきなのは、個々のモデルが何を生成したかではなく、この工程がどのような部品から構成され、なぜ後続案件で再利用できたのかである。
2. AI Factory は刷新戦略の一つである
アルバータ州政府は、保有する旧来システムをすべて AI Factory で置き換える構想を採っているわけではない。The Four Approaches to AI Modernization では、個別システムの状態、業務機能の重複、データ統治の成熟度に応じて、AI Garage、AI Factory、AI Rationalization、Government 3.0 という 4 方式を使い分ける刷新戦略を示している[5]。4 方式は同じ問題に対する代替案ではなく、修理する対象、新しく作る対象、統合する対象、アプリケーションという単位そのものを解体できる対象を分けるための枠組みである。
2.1 システムの状態が刷新方法を決める
刷新方式を選ぶ前に必要なのは、AI で何を実現できるかを列挙することではなく、既存システムへ今後も投資する理由があるかを判定することである。州政府は、システムごとに、現状を許容する、投資する、移行する、廃止するという 4 方向の判定を行う。正常に稼働し、技術的な危険も小さいシステムは、軽微な修正を加えながら維持できる。業務手順は有効でも、基盤技術が保守期限を迎えているシステムは、新しい基盤へ移す価値がある。重複した機能を多数のシステムが個別に持つ場合は、個別改修よりも統合が適する。業務上の必要性を失ったシステムは、刷新せず廃止する[5]。
この判定を先に置く理由は、技術的に作り直せることと、作り直す価値があることが一致しないためである。AI によって再実装費用が下がっても、不要になった業務を新しい技術で再現すれば、不要な運用費と保守責任が残る。反対に、利用者が依存する安定したシステムを全面再構築すれば、移行時の障害、操作変更、データ不整合という新しい危険を持ち込む。刷新の第一段階は生成能力の評価ではなく、維持すべき業務と除去すべき重複を識別する資産判断になる。
| 方式 | 判断単位 | 適する対象 | 実施内容 | 成立条件と制約 |
|---|---|---|---|---|
| AI Garage | 個別システムを判断単位とする。 | 業務手順は有効であり、修理、脆弱性対策、基盤更新によって継続利用できるシステムである。 | 既知の欠陥の修正、古い依存部品の更新、不足している試験の追加、保守期限を迎えた技術基盤の同等機能への置換を行う。 | 既存の画面、データ配置、業務手順を維持できる反面、業務設計そのものに存在する非効率や重複は残る。 |
| AI Factory | 新規または置換対象のシステムを判断単位とする。 | 旧技術を残す合理性がなく、現在の要件に基づいて土台から設計し直すべきシステム、または旧版を持たない新規サービスである。 | 共有仕様を基準として、設計、実装、データベース、試験、セキュリティ、アクセシビリティ、文書を担当する複数の AI エージェントが新しいシステムを構築する。 | 要件と受入条件を明文化し、共通基盤へ適合させる必要がある。既存システム固有の挙動をすべて維持する案件には適さない。 |
| AI Rationalization | 省庁またはシステム群を判断単位とする。 | 認証、書類提出、報告、案件管理などの同じ機能を、複数のシステムが重複して実装している領域である。 | システム群のコードと業務機能を横断的に分析し、重複部分を一度だけ構築する共有基盤と、少数の業務モジュールへ統合する。 | 技術部品の統合だけでは完了せず、各システムに合わせて形成された職員の業務手順、権限、組織境界も変更する必要がある。 |
| Government 3.0 | データ、業務規則、操作要求を判断単位とする。 | データの意味、アクセス権、法令・規則に基づく処理条件を、機械が安全に利用できる形で統治できる領域である。 | 固定されたアプリケーションを介さず、AI エージェントが統治されたデータとコード化された業務規則を利用し、利用者、目的、時点に応じた操作画面を一時的に構成する。 | データ統治、規則の正確なコード化、全操作の記録、権限を与えた人間への責任帰属が前提になる。州政府自身も、現時点では到達していない将来方向と位置づけている。 |
2.2 4 方式は対象範囲と組織変更の深さが異なる
AI Garage と AI Factory の差は、新旧どちらの技術を使うかだけではない。Garage は既存の業務手順を有効な前提として、危険な部品や不足した試験を修正する。利用者が慣れた画面や処理を維持できるため、移行範囲と業務変更を抑えやすい。その代わり、同じ情報を複数回入力する手順や、部門ごとに異なる処理方法まで保存される。技術的負債は減っても、業務上の重複は残り得る。
Factory は、既存システムの構造を保存する義務から離れ、現在の要件に基づいて新しいシステムを構築する。古い依存部品や過去の技術的制約を持ち込まず、共通のアーキテクチャ、試験、セキュリティ基準を最初から適用できる。これが直接的な速度向上を生む。しかし、旧システムの挙動には、文書化されていない例外処理や部門固有の判断が埋め込まれている場合がある。新規構築を選ぶときには、それらを必要な業務要件として再定義するのか、過去の慣行として除去するのかを人間が判断しなければならない。
Rationalization は、一つのシステムを修理または置換する判断から離れ、省庁全体で重複している機能を探す。例えば、数十のシステムがそれぞれ利用者認証、書類提出、通知、報告機能を持っている場合、個別に AI Factory で再構築しても、重複した構造を新しい技術で再生産することになる。先に共通機能を一つの共有部品へ統合すれば、その後の各業務システムは固有の処理だけを持てばよい。個別案件の実装量が減り、共通部品の修正が利用するすべてのシステムへ反映されるため、後続案件ほど費用と保守負荷が下がる。
この方式が人間側へ要求する変更は、Factory よりも大きい。重複したシステムには、技術的な重複だけでなく、部門ごとに形成された責任範囲、承認経路、予算、運用慣行が結び付いている。共通認証へ統合するだけでも、誰が利用者を登録し、どの部門が障害対応を担い、共通部品の変更を誰が承認するかを決め直す必要がある。コード分析と再実装を AI が高速化しても、組織境界を越える合意形成までは自動的に完了しない。
Government 3.0 は、さらに前提を変える。従来のシステムは、画面、処理、データアクセスを一つの固定されたアプリケーションとして組み合わせる。Government 3.0 では、統治されたデータと明文化された業務規則を基盤に置き、AI エージェントが必要な操作画面を要求ごとに構成する。固定画面を持つ多数のアプリケーションを維持する必要が減るため、理論上は最も大きな費用削減につながる。
同時に、この方式は 4 方式の中で最も厳しい統治条件を要求する。法令、規則、政策をコードとして正確に表現できなければ、エージェントは一貫した処理を実行できない。データの意味とアクセス権が統一されていなければ、必要な情報を安全に組み合わせることもできない。さらに、画面と操作がその都度生成される環境では、誰の権限で、どの規則を適用し、どのデータを書き換えたかを後から再現できなければならない。技術的な実現可能性より先に、データ統治、規則管理、監査、責任帰属の成熟度が適用範囲を決める。
2.3 AI Factory を選べる条件
この配置の中で見ると、AI Factory が大きな効果を出せる条件は限定できる。第一に、既存システムの技術構造を保存する価値が低く、現在の要件から設計し直す方が合理的であることが必要になる。第二に、完成条件を共有仕様として明文化できなければならない。第三に、認証、監査、試験、配備などを共通基盤として再利用できる必要がある。第四に、旧システムに埋め込まれた例外処理を、維持すべき要件と廃止できる慣行に分ける判断主体が必要になる。
遠隔地域暖房手当システムは、元の開発者が業務を理解し、期待される処理を説明できたため、Factory 方式へ投入しやすかった。ACIP は新規システムであり、古いアーキテクチャとの互換性を保つ必要がなかった。二つの事例に共通するのは、AI の能力だけではない。既存構造を保存する必要が小さく、作るべき機能を仕様として与え、Factory の共通基盤へ適合させられたことである。
反対に、安定稼働しているシステムへ軽微な脆弱性修正だけが必要な場合、全面再構築は移行危険を増やす。省庁内の数十システムが同じ機能を重複している場合、個別の Factory 開発を繰り返す前に Rationalization が必要になる。業務自体が不要であれば、最も費用対効果が高い選択は廃止である。AI Factory の価値は、すべての旧来システムを新しく作り直すことではなく、新規構築が合理的な対象を選び、共通工程によって再実装費用を下げることにある。
4 日と 11 週間という成果は、この選択を経た Factory 適合案件で生じた。刷新対象を選別せず、同じ方式を政府全体へ適用した結果ではない。数字の射程を決めるのは、AI モデルの性能だけでなく、既存業務を残す価値、機能の重複、要件の明文化可能性、共通基盤への適合、データ統治の成熟度である。AI Factory を刷新戦略全体の一方式として捉えることで、成功事例の倍率を一般化するのではなく、どの条件で同じ構造を再現できるかを判断できる。
3. 速度を生んだ単位は、モデルではなく工程である
AI Factory の速度は、AI モデルがコードを生成する時間だけでは説明できない。業務システムが本番へ届くまでには、何を作るかを決め、実行環境を用意し、生成物を試験し、利用部門が確認し、権限を与え、本番へ配備する工程がある。実装だけが短くなっても、要件の確定や環境準備で数週間止まれば、案件全体の所要期間はほとんど変わらない。
アルバータ州政府は、この前後工程を Pronghorn、Nexus、Velocity という 3 段階へ分けている。Pronghorn は、作るべきものと完成条件を整える。Nexus は、AI エージェントが安全に作業し、生成物を試験・配備できる環境を提供する。Velocity は、人間と AI の間で作業がどこに滞留しているかを測る。それぞれが、要件の曖昧さ、環境待ち、確認待ちという異なる停止原因を扱っている。
3.1 Pronghorn は作り始める前を構造化する
AI Factory の第一段階は Pronghorn である。依頼者との対話、試作品、業務資料、要件、受入条件、アーキテクチャを、一つの案件文脈としてまとめる。アルバータ州政府は、生成 AI を使った数百件の試作を通じて、品質を制約する要因がモデル性能だけではないと判断した。案件ごとに異なる標準、不明確な要件、参照すべき資料の分散が、生成後の修正と手戻りを増やしていた。そこで、標準、ひな型、共通部品、参考実装を機械が利用できる形で集約し、実装開始時から適用する構造を作った[6]。
要件を構造化するとは、説明文を長くすることではない。入力される情報、その情報を評価する規則、処理状態が変わる条件、判断を行う役割、完了と認める条件を、実装と試験へ接続できる形で定義することである。例えば、申請システムで「申請を受け付ける」とだけ指定しても、必須項目、添付書類、重複申請の扱い、差し戻し条件、承認権限が決まっていなければ、業務上の正しさを判定できない。
生成 AI は、曖昧な依頼からでも操作可能な画面や一見整った処理を作れる。この能力は試作では有効だが、見た目が動くことと、制度上正しく処理できることは一致しない。受入条件が定義されていなければ、生成物が間違っているのか、要求自体が未確定なのかを切り分けられず、修正のたびに判断が揺れる。
Pronghorn が最初に減らすのは、コーディング時間ではなく、誤った前提のまま実装を進める危険である。要件と標準が実装前にそろえば、AI エージェントは採用すべき構成、満たすべき規則、試験すべき条件を参照できる。その結果、第一段階では不必要な選択肢の探索が減り、第二段階では後工程で要件不一致が発覚して作り直す回数が減る。速度は生成量の増加だけでなく、生成後に捨てる成果物の減少によっても生じる。
3.2 Nexus は自律的な作業を隔離し、観測する
第二段階の Nexus は、AI エージェントがコードを読み、変更し、試験し、配備するための隔離された実行環境である。エージェントは一定の自律性を持って作業するが、操作内容、利用した権限、発生した費用、加えた変更は記録される。権限には期限を設け、費用上限を設定し、変更を取り消せる状態を維持することで、自律的な試行と政府環境に必要な統制を両立させている[7]。
隔離が必要になるのは、AI エージェントが文章を提案するだけでなく、実際の開発資源を操作するためである。コードの変更、依存部品の追加、データベースの更新、クラウド資源の作成には、費用超過、情報漏洩、設定破壊、意図しない外部接続といった危険が伴う。エージェントの権限を完全に取り除けば作業を実行できず、広い権限を恒久的に与えれば事故時の影響範囲が大きくなる。
Nexus は、権限の有無を二者択一にせず、作業に必要な範囲と時間だけ委任する。エージェントが何を行ったかを追跡でき、異常があれば停止し、変更を戻せるため、試行錯誤を許容できる。ここで安全性を支えているのは、エージェントが誤らないことではない。誤りが起きても、影響範囲を限定し、原因を確認し、元の状態へ戻せることである。
開発速度への効果は、環境準備と権限調整の待ち時間を減らす点に現れる。従来の組織では、開発環境の申請、クラウド資源の準備、配備権限の付与、監査設定の確認が別々の手続きとなり、実装が終わった後に数日から数週間停止することがある。Nexus は、試験、監査、配備に必要な基盤を共通化し、個別案件が一から環境を申請する必要を減らす。
第一段階では、常設された実行環境によって、生成されたコードをすぐに動かし、試験し、修正できる。第二段階では、配備手順、監査記録、権限管理が基盤側に組み込まれているため、本番移行時に同じ統制を案件ごとに作り直さずに済む。Nexus が短縮するのは、AI の思考時間ではなく、生成物が実際に動作する環境へ到達するまでの準備と引き渡しである。
3.3 Velocity は作業時間ではなく滞留を測る
第三段階の Velocity は、AI と人間が共同で進める案件の流れを計測する。要件、計画、アーキテクチャ、試作品、開発、利用者試験、受入、配備という段階を設定し、案件が前進した時点だけでなく、前段階へ戻った時点も記録する[8]。
生成 AI 導入後は、実装時間だけを測っても全体の遅れを説明できない。AI が 10 分で修正案を作っても、担当者が確認するまで 3 日間待てば、案件に加わる時間は 10 分ではなく 3 日を超える。確認後に要件との不一致が見つかり、再び設計段階へ戻れば、生成速度が高いほど大量の手戻りが生じる場合もある。
Velocity が分離しようとするのは、AI が処理している時間、人間が判断している時間、次の担当者へ渡るまでの待ち時間、要件変更による手戻りである。この区別がなければ、案件の遅れをモデル性能の不足と誤認し、さらに高速なモデルを導入しても、確認待ちや承認待ちは残る。
滞留を測定すると、改善対象が変わる。AI の作業時間が長ければ、モデル、指示、計算資源、参照情報を改善する余地がある。人間の確認待ちが長ければ、確認担当者の不足、承認権限の集中、受入条件の曖昧さを見直す必要がある。手戻りが多ければ、実装能力ではなく、Pronghorn で形成した要件や設計の品質に原因がある可能性が高い。
計測の目的は、AI の作業量を多く見せることではない。生成速度、確認能力、承認経路のうち、どこが案件全体の上限になっているかを特定することにある。AI が高速になるほど、実装以外の待ち時間が全体に占める割合は大きくなる。Velocity は、モデルの速度向上によって隠れていた組織側の停止を可視化する。
| 段階 | 対象となる停止原因 | 直接的な作用 | 案件全体への帰結 |
|---|---|---|---|
| Pronghorn | 要件、標準、受入条件、関連資料が分散し、何を正解とするかが定まらない状態である。 | 実装前に判断基準をそろえ、AI エージェントが参照する案件文脈を形成する。 | 誤った前提に基づく生成と、後工程での大規模な作り直しを減らす。 |
| Nexus | 実行環境、権限、試験、監査、配備が個別手続きとなり、生成後の成果物が停止する状態である。 | 隔離された共通環境で作業させ、操作記録、期限付き権限、費用上限、変更の取り消しを提供する。 | 実装から試験、本番配備までの環境待ちと手続きの重複を減らす。 |
| Velocity | AI の実行時間、人間の確認、引き渡し待ち、手戻りが混在し、遅延原因を特定できない状態である。 | 工程間の移動と滞留を分けて記録し、停止している役割と段階を明らかにする。 | 改善対象をモデル性能だけでなく、要件形成、確認能力、承認経路へ広げる。 |
3 段階は独立した道具ではなく、連続した因果関係を持つ。Pronghorn で完成条件が明確になれば、Nexus 上のエージェントは判断の揺れを減らして実装できる。Nexus で実行と配備が共通化されれば、生成物は環境準備を待たずに検証へ進める。Velocity が工程の滞留を記録すれば、次の案件では Pronghorn の要件形成や Nexus の権限設計を修正できる。
この循環によって、一件の案件で得た改善が、その案件だけの経験で終わらなくなる。要件の不足はひな型へ反映され、環境上の障害は共通基盤で修正され、確認の遅れは工程設計の改善対象になる。後続案件が前の案件より速くなる理由は、AI モデルが案件ごとに急速に賢くなるからではない。失敗と修正が、次回も利用できる工程へ蓄積されるからである。
3.4 特定モデルだけの成果ではない
アルバータ州政府は、Google、Microsoft Azure、Amazon Web Services、オンプレミスの計算資源を組み合わせ、用途、費用、データ区分に応じて複数のモデルを使い分ける方針を示している。構成には、モデル提供者の違いを吸収する中継層、利用費用の制御、個人情報の検出、情報漏洩の防止も含まれる[9]。
複数モデルを利用する理由は、すべての作業で最高性能のモデルを使うためではない。要件整理、コード生成、画像解析、文書確認では、必要な能力、許容費用、扱えるデータ区分が異なる。機密性の高い情報を外部サービスへ送れない場合は、政府が管理する環境で動くモデルが必要になる。大量の単純作業へ高価なモデルを使えば、案件費用が増え、Factory 方式の経済性を損なう。
モデルを中継層の背後へ置けば、個別案件が特定事業者の呼び出し方法へ直接依存する範囲を減らせる。モデルを変更しても、要件、試験、権限、監査、配備の工程は維持できる。第一の効果は、作業ごとに適切な性能と費用を選べることである。第二の効果は、特定モデルの提供条件や性能が変化しても、生産ライン全体を作り直さずに済むことである。
この構成では、5 か月から 4 日、11 週間という成果を、一つの基盤モデルや一つの開発支援製品だけへ帰属させることはできない。モデルは実装能力を提供するが、その出力を行政システムへ変えるのは、要件、標準、実行環境、検証、監査、費用管理を接続した工程である。
既稿で確認したように、AI ソフトウェアエンジニアは、質問に回答したりコード断片を提示したりする道具から、独立した実行環境で調査、実装、試験、修正を継続する開発実行基盤へ変化している[10]。AI Factory は、その実行能力を個別利用者の作業環境に閉じず、組織共通の要件、標準、権限、検証、監査へ接続した形である。
モデルの生成速度だけを比較すると、AI Factory の再現条件を見誤る。必要なのは、同じモデルを導入することではない。作るべきものを定義する工程、エージェントが安全に作業できる基盤、生成物を検証して本番へ渡す経路、滞留と失敗を次の案件へ反映する仕組みをそろえることである。アルバータ州政府の事例で速度を生んだ単位は、一回の推論でも一人のエージェントでもなく、これらを連結した開発工程である。
4. 速さは共通部分の再利用から生まれる
Pronghorn、Nexus、Velocity によって一件の開発工程を整えても、案件ごとに要件表現、認証、監査、試験、配備を作り直していれば、短縮効果は個別案件の内部にとどまる。AI Factory が後続案件でも速度を上げられるのは、前の案件で作ったコードを複製するからではない。複数の行政サービスに共通する業務構造を抽出し、要件、技術基盤、品質条件、運用手順として再利用するためである。
再利用によって短縮される作業は、実装だけではない。共通の認証方式が決まっていれば、方式選定とセキュリティ審査を一から繰り返す必要がない。監査記録の形式が基盤へ組み込まれていれば、案件ごとに記録方法を設計しなくてよい。受入条件と試験ひな型が対応していれば、要求を確認する方法も再利用できる。前の案件で確定した判断が、次の案件では検討事項ではなく初期条件になることで、待ち時間と手戻りが同時に減る。
4.1 行政サービスには同じ骨格が繰り返される
アルバータ州政府は、AI Factory を案件管理型の業務に合わせて構築した。案件管理型とは、住民や事業者から情報を受け取り、職員が内容を確認し、規則に従って処理状態を変え、承認、差し戻し、通知、記録を行う業務である。給付、許認可、補助金、契約、規制執行は制度上の目的が異なるが、情報システムとして見ると、申請者、案件、添付書類、処理状態、担当者、判断結果という近い構造を持つ。
例えば、給付制度では、申請を受け付け、資格条件を確認し、承認後に支給する。許認可制度では、申請を受け付け、法令上の条件を確認し、許可または不許可を決定する。結果は異なるが、情報の提出、形式確認、担当者への割当、追加資料の要求、承認、通知、監査記録という処理は重なる。この重なりを制度名ごとに別のシステムとして実装すると、同じ認証、書類提出、通知、検索、報告機能が繰り返し作られる。
Git Insights Ministry は、一つの省庁に存在する約 200 のリポジトリを横断して読み取り、画面、業務手順、外部接続、データベース、業務規則、依存関係を抽出する。そのうえで、各システムが実際に提供している業務機能を分類し、共通する機能を共有基盤へ、固有の処理を個別モジュールへ分ける。アルバータ州政府は、一つの省庁で 185 のアプリケーションを 16 の再利用可能なモジュールへ整理できると分析している[11]。
185 から 16 という数字は、すでに 185 の本番システムを置き換えた実績ではなく、コード資産を横断分析して作成した目標構成である。それでも、個別システムだけを見ていては発見できない重複を示している。同じログイン機能が多数のシステムに存在していても、一つずつ調査すれば、それぞれに必要な機能として見える。省庁全体を一つの資産群として読むと、個別には合理的に見えた実装が、全体では重複した保守対象と攻撃経路を増やしていることが分かる。
重複機能を共有モジュールへ移すと、第一に、新規案件が実装する範囲が狭くなる。認証、書類提出、通知、監査、報告を共通基盤から利用できれば、案件固有の規則と画面に作業を集中できる。第二に、共通部分の欠陥を一度修正すれば、利用する複数のシステムへ改善を反映できる。個別案件の高速化だけでなく、政府全体で保有するコード量、保守箇所、脆弱性の発生面を減らす効果につながる。
ただし、似ている機能を同じ部品へ統合するだけでは不十分である。二つの制度が書類を受け付けるとしても、許容する形式、保存期間、閲覧権限、削除条件が異なる場合がある。共通化すべきなのは書類提出という表面的な名称ではなく、共通の処理と制度固有の規則を分離できる構造である。差異を設定値や交換可能な規則として表現できなければ、共有部品には例外条件が蓄積し、後に変更しにくい巨大な共通システムへ変わる。
4.2 共通資産は定められた工程と組み合わせて使う
共通資産から複数のシステムを構築する考え方は、生成 AI とともに生まれたものではない。Software Engineering Institute が整理したソフトウェア製品系列は、共通の目的を持つ製品群について、製品間の共通性を利用し、共通資産から定められた方法で個別製品を構築する考え方である。生産上の経済性は、部品を保管しておくだけではなく、どの資産をどの条件で組み合わせるかを組織的に管理することで得られる[12]。
ここでいう共通資産には、再利用可能なプログラムだけでなく、アーキテクチャ、要件、試験、設計規則、開発手順も含まれる。同じ認証部品を持っていても、案件ごとに接続方法、権限設定、試験方法が異なれば、導入のたびに設計と確認が必要になる。共通部品と利用方法を一体として管理して初めて、過去の判断を再利用できる。
AI Factory は、この既存の再利用戦略を、AI エージェントが実行できる形へ変えている。標準は人間が読む規程として置くだけでなく、生成時に参照する指示、ひな型、設定、試験として表現される。共通部品には、利用方法と受入条件を対応させる。配備手順は、担当者が文書を読みながら再現するのではなく、Nexus 上の工程として実行する。再利用の主体が、過去の設計を知る開発者だけでなく、組織共通の文脈を参照するエージェントへ広がっている。
この変更によって、再利用が担当者の記憶や判断に依存しにくくなる。従来は、共通部品が存在していても、開発者がその存在を知らない、利用方法が分からない、個別実装の方が早いと判断するといった理由で重複が増えた。AI Factory では、承認済みの構成と参考実装を最初から案件文脈へ含める。第一段階で選択肢を共通資産へ誘導し、第二段階で生成物が標準へ適合しているかを試験するため、再利用が任意の推奨ではなく工程上の既定値になる。
工場という名称が指すのは、同じ製品を大量に複製することではない。制度ごとに異なる業務規則を保ちながら、共通の品質条件と製造工程を繰り返し適用することである。自動車工場が車種ごとの差異を残しながら溶接、塗装、検査の設備を共有するように、AI Factory は申請制度ごとの差異を残しながら、認証、監査、試験、配備の工程を共有する。ただし、本稿における工場は比喩だけではなく、ひな型、実行環境、検査、操作記録として実装された仕組みを指す。
| 再利用対象 | 個別案件方式 | AI Factory 方式 | 速度へ変わる経路 |
|---|---|---|---|
| 要件表現 | 案件ごとに担当者が文書の形式と詳細度を決め、実装者が内容を解釈する。 | 状態、権限、業務規則、受入条件を共通形式で表し、実装と試験へ接続する。 | 要件の再解釈と確認往復が減り、実装後の認識違いによる手戻りを抑える。 |
| 業務部品 | 認証、書類提出、通知、検索、報告を案件ごとに実装する。 | 共通機能を共有基盤として一度構築し、制度固有の規則だけを個別モジュールへ置く。 | 新規案件の実装範囲を狭め、共通部分の設計、実装、試験を省く。 |
| 技術基盤 | 認証、監査、配備、監視、秘密情報管理を案件ごとに選定して構成する。 | 政府の基準を満たす承認済みの基盤と設定を標準として繰り返し利用する。 | 技術選定、環境申請、基盤審査、配備準備に伴う待ち時間を減らす。 |
| 品質確認 | 担当チームが試験観点を組み立て、必要な検査を個別に実装する。 | 機械的な試験、セキュリティ検査、専門エージェントによる確認を工程へ組み込む。 | 検査方法を設計する時間を減らし、欠陥を後工程より早い段階で検出する。 |
| 配備手順 | 案件ごとに環境、権限、監査記録、公開手順を調整する。 | Nexus 上の共通手順として実行し、操作履歴と取り消し可能性を維持する。 | 生成物が完成してから本番へ到達するまでの引き渡しと承認待ちを短くする。 |
| 学習結果 | 欠陥の原因と修正方法が案件内の文書、課題管理表、担当者の経験に残る。 | 発見した欠陥を標準、ひな型、共通部品、試験、監視規則へ戻す。 | 後続案件が同じ失敗を繰り返すことを防ぎ、案件数の増加とともに工程を改善する。 |
4.3 再利用は先行投資を後続案件で回収する
共通化は、最初の案件を必ず安くする方法ではない。共有基盤、要件ひな型、検査、配備手順には先行投資が必要であり、同じ構造を持つ後続案件がそれらを利用して初めて、設計範囲と確認作業が減る。個別案件の費用だけではこの構造を評価できないため、共通基盤の費用、再利用件数、旧システムの廃止を含む経済性は次章で確認する。
4.4 共通化できる部分と個別判断を分ける
再利用の効果が大きいからといって、すべての業務を一つの共通システムへ統合すればよいわけではない。制度固有の規則まで共通部品へ埋め込むと、一つの制度変更が無関係なシステムへ影響する。共通部品が多数の条件分岐を抱えれば、利用する側が挙動を理解できず、変更時の試験範囲も広がる。重複を除去する目的で作った基盤が、変更しにくい新しい巨大システムになる危険がある。
分離の基準は、処理が似て見えるかではなく、同じ変更理由を持つかにある。認証方式、監査記録、書類保存の基本機能は、政府共通のセキュリティ方針や法的要件によって変わるため、共有しやすい。給付の資格条件、許可の判断基準、補助率の計算は、個別制度の法令や政策変更によって変わるため、業務モジュール側に残す必要がある。共通基盤と個別モジュールの境界を、変更主体と変更理由に基づいて設計することで、再利用と独立性を両立できる。
人間の判断も同じ境界に残る。AI はコード資産を横断して重複候補を抽出し、共通モジュールの案を作れる。しかし、二つの処理が制度上も同じ意味を持つか、統合によって責任分界が変わらないか、例外を廃止してよいかは、業務部門、法務、セキュリティ、運用担当者が判断する。技術的な類似性は統合候補を示すが、統合の正当性までは決めない。
アルバータ州政府の事例で速さを支えているのは、共通部分を増やしたことだけではない。共通化できる認証、監査、配備、試験を工場側へ移し、制度固有の規則と例外を案件側へ残したことである。この境界が適切であれば、前の案件で確立した品質条件を再利用しながら、制度ごとの判断を保てる。境界を誤れば、共通基盤への変更調整が新しいボトルネックになり、案件ごとの自律性も失われる。
AI Factory における再利用は、既存コードをコピーする行為ではない。共通の業務骨格を見つけ、変更理由の異なる部分を分離し、要件、部品、試験、配備、改善結果を一つの製造方式として蓄積することである。5 か月から 4 日、11 週間という速度差を後続案件でも再現できるかは、モデルが同じコードを再び生成できるかではなく、前の案件で行った判断と検証を、次の案件がどれだけ初期条件として利用できるかによって決まる。
5. 費用は消えず、個別案件から共通基盤へ移る
AI Factory によって個別案件の費用が下がるとしても、要件整理、実行環境、品質確認、配備、教育に必要な作業が消滅したわけではない。案件ごとに繰り返していた作業の一部を、複数案件が利用する共通基盤へ移したのである。費用が発生する時点と負担する単位が変わるため、ACIP の案件費用だけでは、Factory 方式全体の経済性を判断できない。
個別開発では、各案件が認証方式を選び、試験環境を用意し、監査記録を設計し、配備手順を作る。同じ判断を別の案件でも繰り返すため、案件を増やすたびに近い費用が発生する。Factory 方式では、これらを共通資産として先に構築する。最初の費用は大きくなるが、後続案件では、すでに承認された基盤と工程を利用し、制度固有の要件へ作業を集中できる。
5.1 最初の一件より工場構築の方が重い
一次情報は、最初のアプリケーションを作る作業よりも、AI Factory 自体の構築へ多くの労力を投入したと説明している[1]。先に整備した対象には、要件と受入条件の表現方法、複数の AI エージェント、隔離された実行環境、権限管理、品質検査、監査記録、配備工程、進捗計測が含まれる。これらは一つのアプリケーションだけを完成させるなら過剰に見えるが、後続案件でも使うことを前提とした設備投資である。
ACIP の約 10 万 8,000 カナダドルは、個別案件へ直接計上された費用を示す。これに対し、Pronghorn、Nexus、Velocity、共通基盤、標準、教育へ投入した費用が、どの割合で ACIP に配賦されたかは示されていない。従来方式の 130 万から 190 万カナダドルという見積もりと比較すると大幅な差があるが、その差を Factory 全体の純粋な費用削減額とみなすには、共通投資の総額と利用案件数が必要になる。
費用移転の直接的な効果は、後続案件が一から準備する範囲を減らすことである。承認済みの認証、監査、試験、配備を利用できれば、設計、実装、審査に必要な追加費用が下がる。その背後には、共通基盤の費用を一案件で回収せず、複数案件へ分散する構造がある。追加の一案件を作るために必要な費用は下がるが、共通基盤を所有し続ける費用は組織側に残る。
| 費用区分 | 従来の個別開発 | AI Factory 方式 | 評価時の注意 |
|---|---|---|---|
| 共通基盤の初期投資 | 案件固有の環境と手順だけを用意するため、政府全体の共通投資は小さく見えやすい。 | 標準、実行環境、エージェント、検査、監査、配備、教育へ先行投資する。 | 個別案件の費用だけを比較すると、Factory 構築に要した費用が評価から抜ける。 |
| 案件固有の開発費 | 要件、認証、監査、試験、配備を案件ごとに設計して実装する。 | 共通部分を利用し、制度固有の業務規則、画面、外部接続へ作業を集中する。 | 共通部品へ適合しない要件が多い案件では、追加開発費が再び大きくなる。 |
| 基盤の運用費 | 複数の案件が個別環境を持つため、監視、更新、障害対応も分散する。 | 共通基盤の監視、更新、モデル利用、容量管理、障害対応を継続する。 | 集約によって重複を減らせる一方、共通基盤の障害が複数案件へ波及する。 |
| 品質保証費 | 担当チームが試験観点と確認手順を案件ごとに作る。 | 共通試験と専門エージェントを利用し、案件固有部分を追加確認する。 | 検査の再利用は費用を下げるが、人間による例外判断と最終承認は残る。 |
| 人材と組織変更 | 案件単位の技術教育と引き継ぎが中心となる。 | 要件構造化、エージェント管理、検証、共通資産管理の能力を組織的に育成する。 | 教育費を削ると、共通基盤を使いこなせず、外部事業者への依存が強まる。 |
| 移行と廃止 | 新旧システムの並行運用、データ移行、旧版廃止を案件ごとに実施する。 | 移行手順を共通化できるが、制度固有のデータと利用者調整は個別に残る。 | 新システムの開発費が低くても、旧システムを廃止できなければ総費用は下がらない。 |
5.2 先行投資は案件数だけでは回収できない
共通基盤を利用する案件数が増えれば、先行投資を広く配賦できる。ただし、案件数が多いだけで回収が成立するわけではない。各案件が共通部品を実際に利用し、個別実装を減らし、旧システムを廃止できた場合に初めて、政府全体の費用が下がる。
例えば、10 件の案件が共通認証を利用しても、各案件が独自の認証機能を並行して残せば、共通基盤と個別機能の両方を保守することになる。新システムを公開しても旧システムを停止できなければ、利用料、監視、脆弱性対応、問い合わせ対応が二重に発生する。再利用件数は増えていても、保有システム数と運用費が減らなければ、費用は別の場所へ移っただけである。
回収条件には、共通資産の安定性も含まれる。利用案件が増えるほど、共通基盤の変更は多くのシステムへ影響する。所有者、変更承認、互換性維持、障害対応が定まっていなければ、個別案件が短縮した時間を、共通基盤との調整待ちが相殺する。共通化は保守箇所を減らすが、残された箇所の重要度を高める。
| 回収条件 | 費用低下へつながる経路 | 成立しない場合の帰結 |
|---|---|---|
| 類似案件が継続する | 要件表現、認証、監査、試験、配備を複数案件へ配賦できる。 | 利用案件が少なければ、共通基盤への先行投資を回収できない。 |
| 共通資産を実際に利用する | 個別案件の設計、実装、審査、試験を削減できる。 | 独自実装を併存させると、共通基盤と個別機能の二重保守になる。 |
| 旧システムを廃止する | 利用料、基盤、監視、脆弱性対応、運用支援を削減できる。 | 新旧を並行運用し続けると、開発費が下がっても総保有費用は増える。 |
| 共通基盤の所有者を定める | 変更判断、障害対応、互換性維持を一貫して実施できる。 | 責任主体が曖昧であれば、変更待ちと部門間調整が新しいボトルネックになる。 |
| 制度固有部分を分離する | 共通部品を安定させながら、個別制度の変更を独立して実施できる。 | 制度固有の例外を共通基盤へ蓄積すると、変更費と試験範囲が拡大する。 |
この費用構造を評価するには、個別案件の平均費用に加えて、追加の一案件に必要な費用、共通基盤の年間運用費、旧システムの減少数を追う必要がある。案件単価が下がっていても、共通基盤の費用が急増していたり、旧システムが残り続けたりすれば、政府全体では費用削減にならない。Factory 方式の経済性は、安く作れた件数ではなく、共通投資が重複作業と保有資産をどれだけ減らしたかによって決まる。
5.3 成功を案件費用だけで測らない
アルバータ州政府の Measuring Failure and Success は、AI 導入の成功を、準備度、システム健全性、費用という 3 つの軸で判定する方針を示している[13]。費用削減だけを指標にすると、現在の業務を少ない人員で維持しただけでも成功に見える。州政府が測ろうとしているのは、人員削減の一時的な効果ではなく、組織が新しい開発方式を自立して運用し、老朽化したシステム群を継続的に減らせる能力である。
準備度には、職員教育、安全な利用環境、外部事業者に過度に依存しない自立運用能力、関係者が信頼できる統治が含まれる。Factory が短期間でシステムを作れても、少数の専門家しか運用できず、モデルや基盤の変更を外部事業者へ全面的に依存するなら、組織能力は強くなっていない。短期的な速度と長期的な自立性を別々に測る必要がある。
システム健全性は、老朽化したシステムの待ち行列、脆弱性への曝露、政府が保有するアプリケーション総数が減っているかを見る。新規システムの公開件数が増えても、旧システムが同じ速度で残れば、技術的負債は解消されない。Factory の成果は、新しいものを作った量だけでなく、危険な資産を廃止し、保守対象を減らした結果として判定される。
費用についても、情報技術部門の直接費だけでは足りない。新しいシステムによって、利用部門の処理時間、住民とのやり取り、政策実施、問い合わせ対応がどう変わったかを含める必要がある。情報技術部門の費用が共通基盤へ増えても、政府全体の事務処理費がそれ以上に下がれば、全体としては改善となる。反対に、案件費用だけを低く見せ、確認や例外処理を利用部門へ移せば、費用の付け替えにすぎない。
| 評価軸 | 確認する対象 | 成功を示す変化 | 見かけ上の成功 |
|---|---|---|---|
| 準備度 | 職員教育、安全な利用環境、自立運用能力、統治への信頼を確認する。 | 職員が要件、検証、権限、例外判断を担い、組織が方式を継続運用できる。 | 案件は速いが、少数の専門家や特定事業者がいなければ運用できない。 |
| システム健全性 | 脆弱性、刷新待ち件数、保有アプリケーション数、旧システムの廃止を確認する。 | 危険な資産と重複システムが継続的に減少する。 | 新規システムの公開件数は増えるが、旧システムと技術的負債が残る。 |
| 政府全体の費用 | 情報技術部門、利用部門、行政サービス全体に生じる費用を確認する。 | 共通基盤への投資を含めても、政府全体が少ない資源で多くの業務を処理できる。 | 情報技術部門の案件費用だけが下がり、確認と例外処理の負担が利用部門へ移る。 |
5.4 生産量と品質を同じ指標で代用しない
AI Factory の処理能力を評価するとき、生成したコード量、完了した作業数、公開したシステム数は測定しやすい。しかし、活動量が増えたことと、価値ある成果が増えたことは同じではない。欠陥を含む変更を大量に生成すれば、レビュー、修正、障害対応の作業も増える。活動量だけを成果指標にすると、後工程へ押し出した負担を生産性として数えることになる。
開発者の生産性を扱う SPACE は、満足度と健康、成果、活動量、意思疎通と共同作業、効率と流れという複数の次元から測定する枠組みを示している[14]。一つの指標で生産性全体を表そうとすると、指標に現れない作業や副作用を見落とす。例えば、コードレビューの件数が増えても、確認待ちが長くなり、開発者が頻繁に中断され、欠陥の検出率が下がれば、工程全体は改善していない。
AI Factory に当てはめると、活動量には生成した変更数、実行した試験数、公開した案件数が含まれる。効率と流れには、要件確定から配備までの時間、引き渡し待ち、手戻りが含まれる。成果には、利用部門の処理時間、障害率、利用率、旧システムの廃止が含まれる。意思疎通と共同作業には、AI の生成物を業務部門、開発者、セキュリティ担当者が共通の根拠で確認できるかが含まれる。
短期化と品質の関係も一方向ではない。共通試験と早期検証によって欠陥を早く発見できれば、期間短縮と品質向上を同時に実現できる。一方、公開件数を優先して確認工程を省けば、運用開始後の障害、脆弱性、問い合わせ、修正費が増える。期間と費用を品質から切り離して評価すると、開発段階で削った費用が運用段階へ移っただけの状態を成功と誤認する。
5.5 製品品質は受入条件として定義する
ISO/IEC 25010:2023 は、情報通信技術製品とソフトウェア製品の品質を、9 つの品質特性とその下位特性から指定、測定、評価する参照モデルを定めている[15]。このモデルは、品質を公開後の印象で判断するための一覧ではない。要件の網羅性を確認し、設計目標、試験目標、品質管理基準、受入条件を定めるために利用できる。
AI Factory では、この位置づけが特に重要になる。AI エージェントは、明示された受入条件を試験へ変換できるが、明示されていない品質要求を自動的に補償するわけではない。機能が動作することだけを完了条件にすれば、負荷が増えたときの安定性、障害からの復旧、権限外アクセスへの防御、将来の変更可能性が確認されないまま公開へ進む可能性がある。
第一段階では、Pronghorn が業務要件とともに、対象システムで必要な品質条件を定義する。第二段階では、Nexus 上の試験と検査が、その条件を満たす証拠を生成する。第三段階では、人間が証拠を確認し、残された危険を受け入れてよいかを判断する。品質モデルは AI の判断を置き換えるものではなく、生成物を何によって評価するかを、生成前に固定するための基準になる。
| 評価対象 | 測定例 | 費用との関係 | 確認しない場合の危険 |
|---|---|---|---|
| 業務上の成果 | 処理時間、利用率、制度上の誤判定、旧システムの廃止数を測る。 | システムを作ったことではなく、行政業務全体の費用を減らしたかを判定できる。 | 利用されないシステムや、旧版を置き換えられないシステムを成功として数える。 |
| 工程の流れ | 要件確定から配備までの時間、確認待ち、手戻り、差し戻し回数を測る。 | 実装時間以外に残る滞留と人間側の負荷を把握できる。 | AI の生成時間だけを短縮し、案件全体の停止を見落とす。 |
| 製品品質 | 受入条件の充足、障害、脆弱性、復旧、変更時の影響を測る。 | 開発時に削減した費用が、運用障害や保守負担へ移っていないかを確認できる。 | 短期的な案件費用を下げる代わりに、長期的な総保有費用を増やす。 |
| 組織能力 | 教育受講だけでなく、職員が要件、検証、運用、改善を自立して行えるかを測る。 | 外部事業者への依存費と、将来の変更対応力を評価できる。 | 導入件数が増えるほど、特定事業者への依存と契約費用が増える。 |
| 資産全体の健全性 | 保有システム数、刷新待ち、重複機能、脆弱性、旧基盤の残存数を測る。 | 個別案件の削減額を、政府全体の資産縮小と対応させられる。 | 新しいシステムを追加しながら、古いシステムも維持する二重費用が続く。 |
ACIP の約 10 万 8,000 カナダドルは、Factory 方式が個別案件の費用を大きく下げる可能性を示す有力な事例である。ただし、その数字だけでは、共通基盤への先行投資、職員教育、モデル利用料、品質確認、旧システムの廃止、長期保守まで含む経済性は分からない。Factory 方式の成否は、安価な案件を何件作ったかではなく、共通投資によって重複作業、危険な資産、運用負荷をどれだけ減らし、その状態を品質低下なしに維持できたかによって決まる。
6. 組織知は人の記憶から工程へ移る
AI Factory が後続案件を速くできるのは、前の案件で生成したコードだけを再利用するためではない。要件をどの粒度で表現したか、どの品質条件を満たせば公開できるか、どの権限を誰に与えるか、どの例外を人間へ戻すかという判断も、標準、ひな型、試験、監査規則として蓄積される。個別案件の経験を次の案件が利用できる形へ変えることで、組織の学習が担当者の記憶から開発工程へ移る。
この移行は、知識を文書へ書き残すだけでは成立しない。設計書が保管されていても、後続案件の担当者や AI エージェントが必要な箇所を見つけられず、実装や試験へ接続できなければ、同じ判断を再び行うことになる。AI Factory が必要とするのは、読むための記録だけでなく、生成、検査、承認、配備の各段階で実際に参照される知識である。
6.1 残るのはコードだけではない
行政システムには、プログラムだけを読んでも十分に分からない判断が含まれている。入力項目が必須である理由、一定期間を過ぎた申請を受理しない理由、特定の職員だけが承認できる理由、例外時に手作業へ戻す条件は、法令、政策、現場運用、過去の障害対応から形成される。コードには最終的な条件分岐が現れていても、その条件を維持すべき理由までは残らない場合がある。
AI Factory が共通資産として保持する対象には、画面部品、データ構造、配備設定に加えて、要件の表現方法、セキュリティ標準、受入条件、過去に見つかった欠陥、文書作成手順、例外処理の規則が含まれる。これらを Pronghorn の案件文脈、Nexus の権限と実行規則、共通試験、監査記録へ組み込むことで、後続案件は過去の判断を初期条件として利用できる。
第一の効果は、担当者が変わっても、最低限満たすべき条件が工程に残ることである。例えば、過去の案件で個人情報が記録へ混入した問題が見つかれば、注意事項を報告書へ記載するだけでなく、検出規則や試験として追加できる。次の案件では、担当者がその障害を知らなくても、同じ種類の問題を検査できる。
第二の効果は、一つの案件で得た改善を複数案件へ反映できることである。個別チームの課題管理表に修正方法を残すだけなら、効果はそのシステムに閉じる。共通ひな型、検査、配備手順を更新すれば、その後に Factory を利用する案件すべてが変更の対象になる。組織学習の単位が、担当者や開発チームから生産ライン全体へ広がる。
ただし、AI が会議、文書、コードを読み込めば、暗黙の経験を自動的に組織知へ変えられるわけではない。現場で行われている例外対応には、正式な規則、過去の暫定措置、担当者個人の工夫が混在している。そのまま標準化すれば、廃止すべき慣行まで次のシステムへ固定する危険がある。人間は、観察された手順から、維持すべき制度要件と見直すべき運用慣行を分けなければならない。
Alberta AI Academy は、この変換を担う人材を段階的に育成する構想である。一般的な AI 利用から始め、再利用可能なエージェント、制御枠組み、本番業務向けアプリケーションの構築へ進む教育を行う[16]。目的は、職員が生成 AI の操作方法を覚えることだけではない。業務知識を要件、技能、試験、監査可能な工程へ変換し、その工程を組織内で維持できるようにすることにある。
| 組織知の種類 | 人の記憶に依存する状態 | 工程へ移した状態 | 後続案件への効果 |
|---|---|---|---|
| 要件の理由 | 担当者だけが、入力項目、期限、承認条件が必要な理由を理解している。 | 業務規則、状態遷移、受入条件として表し、実装と試験へ対応させる。 | 後続案件で要件を再発見する時間と、理由を理解せず削除する危険を減らす。 |
| 品質基準 | 経験のある開発者や審査担当者が、過去の問題を思い出しながら確認する。 | 共通試験、検査規則、公開条件として生産ラインへ組み込む。 | 担当者の経験差に左右されにくく、同じ欠陥の再発を早い段階で検出できる。 |
| セキュリティ判断 | 案件ごとに権限、記録、秘密情報の扱いを設計し直す。 | Nexus の権限設定、隔離、監査記録、情報検出規則として共通化する。 | 審査の出発点をそろえ、過去に承認された統制を再利用できる。 |
| 例外処理 | 現場担当者が個別判断し、理由が記録されないまま運用が続く。 | 自動処理できる条件、人間へ戻す条件、判断記録の形式を分けて定義する。 | 定型処理を再利用しながら、制度固有の例外を人間の判断として維持できる。 |
| 障害からの学習 | 原因と修正方法が、障害報告書や担当者の経験に残る。 | 標準、ひな型、試験、監視、配備手順を修正する。 | 一件の障害対応を、後続案件全体の予防策へ変えられる。 |
6.2 人間に残る仕事は判断基準の形成である
AI が実装、試験、文書作成を高速化すると、人間の作業がそのまま減るとは限らない。定型的な作業時間が短くなる一方で、何を作るか、生成物を何によって評価するか、どの危険を受け入れるかを決める仕事の比重が高くなる。人間の役割は工程から消えるのではなく、実装の内部から、工程の入口、境界、出口へ移る。
工程の入口では、解くべき問題を確定する必要がある。利用部門から提示された要望をそのまま機能一覧へ変えるだけでは、既存手順の重複や不要な例外まで再実装することになる。何を維持し、何を廃止し、どの成果を優先するかは、制度目的と業務責任を持つ人間が決める。
工程の途中では、一般規則と個別例外の境界を定める必要がある。AI は過去資料から頻出する処理や判断候補を抽出できるが、それが法令上必要な規則なのか、特定担当者の慣行なのかは自動的には確定できない。誤った慣行を共通規則へ変換すると、従来は一部の職員に限定されていた問題が、Factory を利用する複数システムへ拡大する。
工程の出口では、試験結果と残存リスクを受け入れてよいかを判断する。自動試験がすべて成功しても、試験項目に含まれていない制度上の危険は残る。反対に、軽微な警告が残っていても、業務継続のために期限付きで公開し、後日修正する判断が必要になる場合がある。公開、延期、停止、復旧には、技術的な正誤だけでなく、利用者への影響、法的責任、代替手段を含む判断が必要になる。
既稿で整理したように、AI に任せる前には、問いの切り方、判断軸、優先順位、任せない領域を人間が定める必要がある[17]。AI Factory では、この役割が抽象的な原則にとどまらず、要件、受入条件、権限設定、停止条件、承認記録として工程へ実装される。人間が判断するという方針だけでは、どの段階で誰が判断するかが曖昧なまま残る。
| 判断地点 | AI が支援できること | 人間が引き受けること | 判断を誤った場合の帰結 |
|---|---|---|---|
| 問題設定 | 関連資料を整理し、重複、欠落、代替案、影響範囲の候補を提示する。 | 何を解くべき問題と定義し、制度上の目的と期待する成果を確定する。 | 不要な業務や過去の非効率を、新しい技術で正確に再生産する。 |
| 要件確定 | 文書から候補要件、状態、例外、権限、試験条件を抽出する。 | 法令、政策、現場運用が衝突する箇所を解き、優先順位を決める。 | 曖昧な要件が実装後まで残り、大量の手戻りや制度上の誤処理を生む。 |
| 共通化 | 複数システムの類似処理と重複部品を検出し、統合候補を提示する。 | 制度上も同じ意味を持つか、責任境界を変更してよいかを判断する。 | 制度固有の規則を誤って統合し、無関係な案件へ変更影響を広げる。 |
| 品質評価 | 試験を実行し、標準違反、不整合、脆弱性、性能問題の候補を検出する。 | 残存リスク、利用者への影響、代替手段を踏まえて公開可否を決める。 | 試験結果を形式的に通過しても、制度上受容できない危険を本番へ持ち込む。 |
| 権限委任 | 必要な操作、資源、費用、時間の候補を作業内容から推定する。 | 影響範囲を評価し、どの権限をどの期間だけ与えるかを決める。 | 権限不足による停止、または過剰権限による情報漏洩や環境破壊を招く。 |
| 運用対応 | 監視、異常検知、影響分析、修正案、復旧手順の候補を提示する。 | 停止、継続、復旧、利用者通知、制度上の救済措置を決定する。 | 技術的な復旧を優先し、利用者や制度運用への損害を拡大する。 |
6.3 繰り返せる規則と案件固有の判断を分離する
組織知を工程へ移すとき、すべての判断を固定された規則へ変換することはできない。認証方式、操作記録、必須試験のように、複数案件へ一貫して適用すべき条件がある。一方、制度変更への対応、例外申請の救済、公開時期の判断のように、案件の状況と責任主体によって結論が変わる領域もある。
繰り返せる規則は、標準、ひな型、試験、権限設定として Factory 側へ置く。個別事情を評価する判断は、案件側の業務責任者、法務、セキュリティ、運用担当者へ残す。この分離によって、定型部分は自動化と再利用の対象になり、人間は制度固有の対立や例外へ時間を集中できる。
分離が不十分な場合には、二つの失敗が生じる。人間が毎回判断する範囲を広く残しすぎると、共通工程を構築しても確認待ちと属人性が減らない。反対に、例外を過度に規則化すると、現場の状況を考慮できない硬直したシステムになる。自動化率を最大にすることではなく、同じ根拠で繰り返せる判断だけを工程へ移すことが境界になる。
工程へ移した規則には、所有者と更新手順も必要である。法令、政策、セキュリティ基準が変われば、要件ひな型、試験、権限設定も変更しなければならない。誰も更新責任を持たなければ、かつて正しかった組織知が、古い規則を自動的に再生産する仕組みへ変わる。工程化された知識は属人性を減らす一方、誤りが複数案件へ拡散する速度も高める。
このため、共通資産には、内容だけでなく、根拠、適用範囲、変更日、承認者を残す必要がある。後続案件で規則が適用されたとき、その判断がどの法令、標準、過去の障害に由来するかを確認できれば、変更時に影響範囲を追跡できる。監査可能性は AI エージェントの操作だけでなく、エージェントが従う組織知にも必要になる。
AI Factory における組織知は、AI モデルの内部へ蓄積される記憶ではない。Pronghorn の要件と受入条件、Nexus の権限と実行規則、共通部品、試験、監査記録、教育内容として、組織が所有し更新できる形で残る。担当者が異動しても工程を再現でき、モデルを変更しても判断基準を維持できることが、組織能力としての価値になる。
人間の役割も、この構造によって明確になる。実装の細部を一件ずつ作ることから、何を標準とし、何を例外として残し、どの証拠をもって公開を認めるかを決める役割へ移る。AI Factory が保持するのは、過去の答えそのものではない。組織がどの根拠で答えを選び、誤りをどのように検出し、判断基準をどのように更新したかという工程である。
7. AI の出力は独立した検証を必要とする
AI Factory が実装を高速化すると、一度に生成されるコード、試験、設定、文書の量も増える。人間が一行ずつ確認する従来の方法だけでは、生成量に検証能力が追いつかない。一方、生成を担当した AI エージェントに、そのまま合否判定まで任せれば、要件の読み違い、誤った前提、見落とした例外を自己評価でも引き継ぐ可能性がある。
このため、AI Factory は生成と採用の間に、別の目的と検査方法を持つ確認工程を置く。検証対象もコードの構文や単体試験だけに限定されない。制度上の要件、製品品質、セキュリティ、成果物間の整合性を別々に確認し、最終的に人間が公開可能かを判断する。速度を維持するには検証を省くのではなく、検証自体を分解し、反復可能な工程へ変える必要がある。
7.1 作成役と確認役を分ける
AI Factory では、生成したエージェント自身の自己評価だけで品質を確定しない。Green はコード品質と衛生状態、Yellow は画面や文書の文章品質、Red は攻撃者視点の動的検査、Blue はセキュリティ標準への適合、脅威モデル、攻撃経路を確認する[18]。
役割分離の目的は、同じ成果物に複数回感想を述べさせることではない。作成役と確認役が同じ要求解釈、同じ判断基準、同じ参照情報を共有していれば、確認回数を増やしても同じ誤りを繰り返す可能性がある。独立性を持たせるには、各役割が異なる問い、規則、証拠を使って成果物を評価しなければならない。
例えば、申請画面が正常に送信できることを作成役が確認しても、それだけでは業務上の正しさを示さない。Green はコード品質と要件への適合を確認し、Yellow は画面、通知、操作説明が利用者に誤解なく伝わるかを調べる。Red は不正な入力、権限の回避、予期しない操作順序によって処理を破壊できないかを試し、Blue は認証、秘密情報、依存部品、操作記録が定められたセキュリティ基準を満たすかを検査する。
第一段階では、目的の異なる確認役が、作成役の視野に入らなかった欠陥候補を抽出する。第二段階では、検出結果を試験記録、標準違反、再現手順として残し、人間が採用可否を判断できる証拠へ変える。単に別の AI が「問題がある」と述べるだけでは、差し戻しの根拠にも、公開判断の根拠にもならない。
役割を分けても、すべての確認役が同じ基盤モデルを使う場合には、共通した弱点が残り得る。モデルが理解しにくい要件、学習データに乏しい技術、誤った参考実装は、複数の役割へ同時に影響する。そのため、AI による確認の下には、決められた入力に対して同じ結果を返す機械的な試験、静的解析、構成検査、権限検査を置く必要がある。
| 確認役 | 主な目的 | 用いる証拠 | 単独では残る限界 |
|---|---|---|---|
| Green | 実装が要件、状態遷移、受入条件を満たしているかを確認する。 | 要件との対応表、受入試験、処理結果、例外時の挙動を用いる。 | 要件自体が誤っていれば、誤った要件へ正確に適合してしまう。 |
| Yellow | 画面、通知、操作説明、運用文書が利用者に誤解なく伝わるかを確認する。 | 用語統一、文章構造、利用者行動との対応、アクセシビリティ要件を用いる。 | 文章が明快でも、背後の業務処理が正しいとは限らない。 |
| Red | 想定外の入力、操作順序、権限利用によって処理を破壊できないかを確認する。 | 異常入力、境界値、権限逸脱、状態遷移の迂回、再現手順を用いる。 | 試した攻撃経路以外に脆弱性が残る可能性がある。 |
| Blue | 認証、認可、秘密情報、依存部品、操作記録が標準を満たすかを確認する。 | 構成検査、静的解析、依存関係検査、監査記録、標準との対応を用いる。 | 標準に含まれていない新しい攻撃や、制度固有の危険は別途判断が必要となる。 |
7.2 部分が正しくても全体はずれる
個々の変更が単体試験を通過しても、システム全体が同じ仕様を保っているとは限らない。要件では申請を取り消せることになっていても、画面に取消操作が存在しない場合がある。データベースには新しい状態が追加されていても、通知文書や運用手順が旧状態のまま残る場合もある。各成果物を個別に確認するだけでは、成果物同士のずれを検出できない。
Anti-Drift Harness は、成長するコードベースについて、要件、データベース、業務処理、画面、試験、文書が同じ仕様を表しているかを継続的に確認する仕組みである[19]。ここでいうずれは、コードが動かなくなる故障だけを指さない。変更の一部だけが反映され、利用者、開発者、運用担当者が異なる業務像を前提にする状態も含む。
生成 AI は、指定された狭い範囲では整合した変更を高速に作れる。しかし、作業単位が細かく分割され、複数のエージェントが並行して変更すると、一つの修正が他の成果物へ与える影響を見落としやすくなる。第一の変更ではデータ構造が更新され、第二の変更では画面が更新されても、試験や運用文書が旧仕様のまま残る可能性がある。
変更速度が上がるほど、このずれは短時間に広がる。人間の開発者が数週間かけて行っていた変更を複数のエージェントが数時間で進めれば、レビュー時点には関連成果物が大きく分岐している場合がある。生成能力を並列化するなら、依存関係と整合性の確認も同じ頻度で実行しなければならない。
Anti-Drift Harness の直接的な役割は、仕様を基準として成果物間の矛盾を検出することである。その背後には、要件を参照可能な形で保持し、どのコード、画面、試験、文書がどの要件を実現しているかを追跡できる構造が必要になる。仕様との対応が記録されていなければ、自動検査は文字列や形式の違いを見つけられても、業務上の意味がずれたかを判定できない。
全体整合性の確認は、要件を一度固定して変更を禁止することでもない。制度変更や利用者試験によって要件が変われば、変更の起点を明らかにし、影響を受けるデータ、処理、画面、試験、文書をまとめて更新する必要がある。ずれを防ぐのではなく、変更が全成果物へ伝播したことを確認する仕組みである。
| ずれの種類 | 具体例 | 局所試験だけでは見落とす理由 | 業務上の帰結 |
|---|---|---|---|
| 要件と実装 | 制度上は再申請を認めるが、実装では重複申請として拒否する。 | 実装された拒否処理自体は、開発者が作った単体試験に合格する。 | 適格な申請者が制度を利用できなくなる。 |
| データと処理 | 新しい処理状態を追加したが、集計処理が旧状態だけを対象とする。 | 状態更新と集計処理を別々に試験すると、それぞれは正常に動作する。 | 管理報告の件数が実態と一致せず、政策判断を誤る。 |
| 画面と権限 | 画面には承認操作が表示されるが、利用者に必要な権限が付与されていない。 | 画面試験と権限試験の対象利用者が異なると、結合時の不整合が残る。 | 正規の担当者が処理を完了できず、案件が滞留する。 |
| 実装と文書 | 操作方法を変更したが、利用者向け説明と運用手順が旧版のまま残る。 | コード試験では、利用者が誤った手順を案内されることを検出できない。 | 問い合わせ、誤操作、職員による手作業の補正が増える。 |
| 試験と現行仕様 | 要件変更後も、旧仕様を前提とした試験が成功条件として残る。 | 試験が成功していること自体が、古い挙動を維持する圧力になる。 | 新しい制度要件を実装すると試験が失敗し、誤って変更を戻す可能性がある。 |
7.3 セキュリティは完成後の審査ではなく工程に置く
従来型の開発では、実装がほぼ完成した後にセキュリティ審査を行い、問題が見つかれば設計や実装へ戻ることがある。この方法では、認証方式、データ保存、外部接続のような基盤部分に欠陥があった場合、修正範囲がシステム全体へ広がる。生成 AI によって実装が速くなっても、完成後の審査で大規模な差し戻しが発生すれば、提供期間は短くならない。
NIST の Secure Software Development Framework（SSDF）Version 1.1 は、安全な開発実践を個別のソフトウェア開発ライフサイクルへ組み込み、公開される脆弱性を減らし、未発見の脆弱性が悪用された場合の影響を抑え、脆弱性の原因が再び入り込むことを防ぐための枠組みである[20]。完成物だけを検査するのではなく、組織、開発環境、成果物、脆弱性対応を含む工程全体へ安全性を配置する。
OWASP Application Security Verification Standard（ASVS）Version 5.0.0 は、Web アプリケーションに必要な技術的なセキュリティ制御を検証する基準と、安全な開発要件を定めるための参照点を提供する[21]。認証、セッション、アクセス制御、入力検証、暗号、通信、構成、データ保護などを具体的な確認対象へ分解できるため、「安全であること」という抽象的な要求を試験可能な条件へ変えられる。
AI Factory では、これらの基準を公開直前の確認表としてだけ使うのではなく、Pronghorn で要件と受入条件へ組み込み、Nexus 上で自動検査し、確認役が結果を評価する必要がある。第一段階で安全性を設計条件に含めれば、生成エージェントは承認された認証方式、秘密情報管理、操作記録を初期構成として利用できる。第二段階で変更のたびに検査すれば、欠陥が他の機能へ広がる前に差し戻せる。
政府の業務システムでは、セキュリティ上の欠陥が技術的な障害だけに終わらない。申請情報の漏洩は、住民の氏名、住所、所得、健康、家族状況を第三者へ露出させる可能性がある。権限検査の不足は、職員が担当外の案件を閲覧または変更できる状態を作る。監査記録が不足すれば、不正操作が起きた後に、誰の権限で何が変更されたかを説明できない。
共通基盤へセキュリティを組み込むと、案件ごとに同じ制御を作り直す必要が減る。一方、共通認証や共通監査に欠陥があれば、利用する複数のシステムへ影響が広がる。共通化によって検査箇所は減るが、1 か所の重要度は高くなる。このため、共通部品には個別案件以上に厳しい変更管理、互換性試験、障害時の停止手順が必要となる。
7.4 検証は品質特性ごとに証拠を分ける
品質確認を一つの合否へまとめると、何を確認でき、何が未確認なのかが見えなくなる。機能試験が成功しても、負荷が高いと停止する可能性がある。脆弱性検査で問題が見つからなくても、制度上の判断条件が誤っている場合がある。文章が分かりやすくても、権限外の利用者に操作が表示される可能性もある。
前章で参照した ISO/IEC 25010:2023 の品質モデルは、製品品質を単一の印象ではなく、複数の品質特性へ分けて指定・測定・評価するために利用できる[15]。AI Factory では、各品質特性について、どの試験、記録、審査結果を受入証拠とするかを事前に決める必要がある。証拠が分かれていれば、一部の条件が未達でも、公開を延期すべきか、影響を限定して受け入れられるかを人間が判断できる。
| 確認層 | 確認する問い | 主な証拠 | 失敗時の帰結 |
|---|---|---|---|
| 要件適合 | 実装は制度上の目的、入力条件、状態遷移、承認権限、受入条件を満たしているか。 | 要件との対応表、業務シナリオ、受入試験、例外処理の記録を用いる。 | 技術的には動作していても、誤った給付、審査、許可、通知を行う。 |
| 機能外の製品品質 | 性能、安定性、復旧性、利用性、変更容易性を含む品質条件を満たしているか。 | 負荷試験、障害試験、復旧試験、利用者試験、変更影響分析を用いる。 | 短期的に公開できても、障害、操作誤り、保守費が運用段階で累積する。 |
| セキュリティ | 認証、権限、入力、記録、秘密情報、通信、依存部品、構成が安全か。 | 静的解析、動的試験、依存関係検査、権限試験、構成検査、監査記録を用いる。 | 個人情報漏洩、不正操作、権限逸脱、供給網からの侵害が起こる。 |
| 全体整合性 | 要件、実装、データ、画面、試験、文書が同じ業務状態を表しているか。 | 追跡関係、横断検査、成果物差分、状態定義の照合を用いる。 | 一部は正しくても、利用者、開発者、運用者が異なる挙動を前提にする。 |
| 運用可能性 | 監視、障害対応、停止、復旧、問い合わせ対応、変更手順を組織が実行できるか。 | 運用試験、障害訓練、手順書、担当者、連絡経路、復旧時間の記録を用いる。 | 公開後の異常に対応できず、技術的な障害を行政サービスの停止へ拡大する。 |
7.5 検証結果を採用判断へ接続する
検証工程が多数の警告と報告書を生成しても、それだけでは品質保証にならない。検出された問題を誰が評価し、どの重大度なら公開を止め、どの条件なら期限付きで受け入れるかを決める必要がある。確認役の出力は判断材料であり、責任主体の代わりではない。
自動検査は、既知の規則へ高速かつ一貫して適用できる。人間は、制度上の影響、利用者への損害、代替手段、公開延期の費用を含めて判断する。例えば、軽微な画面表示の不整合と、誤った受給資格判定を同じ失敗件数として扱うことはできない。検出数ではなく、業務上の影響と修正可能性に基づいて優先順位を付ける必要がある。
公開を認める場合も、問題が存在しないと断定するのではなく、どの範囲を確認し、何が未確認で、残存リスクを誰が受け入れたかを記録する。後に障害が起きたとき、この記録があれば、判断時点で利用可能だった証拠と、見落とされた条件を分けて検証できる。監査可能性はエージェントの操作履歴だけでなく、品質を受け入れた人間の判断にも必要となる。
AI Factory の検証構造が前提としているのは、AI が誤らない未来ではない。生成量が増え、変更速度が上がっても、誤りを異なる視点から検出し、影響を追跡し、採用前に止められる状態である。作成役と確認役の分離、成果物間の整合性検査、安全性の工程内組み込み、証拠に基づく人間の承認がそろって初めて、生成速度を本番システムの提供速度へ変換できる。
8. 生成コードの速さは、確認負荷を消さない
生成 AI が作るコードは、完成品ではなく、短時間で作られた実装候補である。構文が正しく、試験が通り、説明も整っている場合でも、業務要件、既存設計、権限境界、例外条件まで満たしているとは限らない。生成時間が短くなることと、採用可能な品質へ到達することは、別の工程として評価する必要がある。
GitHub Copilot の初期版を、危険度の高い脆弱性分類に関する 89 の条件で評価した研究では、生成された 1,689 個のプログラムの約 40 ％ に脆弱性が含まれていた[22]。この数値は、研究当時のモデル、課題、生成条件に依存するため、現在のモデルや AI Factory の脆弱性率として利用できない。それでも、コードが生成され、意図した入力で動作したという事実だけでは、安全性を証明できないことを示している。
8.1 生成物の見栄えは品質の証拠にならない
生成コードが危険なのは、常に明らかな誤りを含むからではない。むしろ、命名、構造、説明が整い、もっともらしく動作するため、見落としが生じやすい。正常系の入力では期待した結果を返していても、異常入力、権限外の利用者、同時実行、外部サービスの失敗、依存部品の更新によって安全性が崩れる場合がある。
人間側にも、生成物を実際より高く評価する危険がある。AI 支援を利用した参加者が、安全性の低いコードを書きながら、支援を利用しなかった参加者より自分のコードを安全だと認識しやすかった研究がある[23]。この結果が示すのは、AI が誤ることだけではない。整った出力と流暢な説明が、確認者の警戒水準を下げ、判断の校正を崩す可能性である。
確認者がコードを自分で書いていない場合には、さらに別の負荷が生じる。手作業で実装した開発者は、設計上の選択、迷った箇所、暫定対応を作業過程から理解している。生成された変更を受け取る確認者は、その背景を持たないまま、変更理由、依存関係、失敗条件を差分から復元しなければならない。コード作成時間が短くなっても、理解形成の時間まで同じ比率で短くなるとは限らない。
8.2 生成量が増えるとレビュー工程が飽和する
AI が一件の変更を速く作るほど、一定時間内にレビューへ送られる変更数は増える。開発者 1 人が 1 日に作成できる差分量を前提として設計されたレビュー工程へ、複数のエージェントが並行してコード、試験、設定、文書を送り込めば、確認者の処理能力が先に上限へ達する。
第一段階では、レビュー待ちの変更が増える。生成エージェントは次の作業へ進めても、採用、差し戻し、本番反映は確認者の判断を待つ。第二段階では、確認者が処理量を維持するため、一件当たりの確認時間を短くする圧力が生じる。変更を表面的に確認するだけになれば、生成速度によって増えた成果物が、欠陥と運用負荷を本番へ送り込む経路になる。
確認待ちを避けるために変更単位を大きくすると、影響範囲を理解しにくくなる。小さく分割すると、件数、引き渡し、承認操作が増える。生成能力だけを拡張し、レビュー方針、試験基盤、権限分担を変更しなければ、案件は実装工程ではなく確認工程で滞留する。
| 生成能力の変化 | 確認工程への影響 | 放置した場合の帰結 |
|---|---|---|
| 変更件数の増加 | レビュー待ち、試験待ち、承認待ちの件数が増える。 | AI は作業を完了していても、案件全体は人間の確認地点で停止する。 |
| 変更速度の上昇 | 確認者が前の変更を理解する前に、関連する次の変更が追加される。 | 差分間の依存関係を追えず、個別には正しい変更が全体不整合を生む。 |
| 並列エージェントの増加 | 同じコード、設定、文書へ複数の変更が同時に加えられる。 | 競合、重複実装、異なる前提に基づく変更が短時間で蓄積する。 |
| 説明文の自動生成 | 変更理由や安全性について、整った説明が大量に添付される。 | 説明の流暢さを根拠の強さと混同し、実際の検証を省略しやすくなる。 |
| 試験の自動生成 | 試験数は増えるが、生成コードと同じ要件解釈に依存する場合がある。 | 誤った実装と、それを正しいと判定する試験が同時に生成される。 |
8.3 自動検査は確認対象を減らすために使う
生成コードに危険が含まれ得ることから、AI に検査を任せてはならないという結論は出ない。静的解析、依存部品検査、型検査、単体試験、権限検査、構成検査は、大量の変更へ同じ規則を一貫して適用できる。自動検査は、既知の違反を先に除外し、変更された要件、制度固有の例外、重大な権限変更、未検証の依存関係を人間へ提示するために使う。
ただし、生成と検査を同じ根拠へ依存させてはならない。生成エージェントが参照した説明だけから試験を作れば、要件の読み違いが実装と試験の両方へ入る。業務上の受入条件、独立したセキュリティ基準、機械的な検査、過去の障害から追加された回帰試験を別の証拠として置くことで、同じ誤りを自己確認する危険を減らせる。
8.4 確認能力が開発速度の上限になる
AI Factory の処理能力を上げるには、生成エージェントの数だけでなく、組織が検証して採用できる量を増やす必要がある。要件と試験の対応を明確にし、既知の違反を自動検出し、重大な差分だけを業務、セキュリティ、運用の各担当者へ送ることで、人間の判断能力を必要な地点へ配分できる。
生成コードの速さは、確認作業を消すのではなく、確認工程の設計を開発能力の中心へ押し上げる。AI が作れる変更量より、組織が根拠を確認し、危険を比較し、責任を持って採用できる変更量が小さければ、後者が案件全体の上限になる。
9. 自律性は観測可能性と可逆性で支える
AI エージェントの自律性は、権限を広く与えることと同義ではない。作業の目的を与えた後、調査、変更、試験、修正を一定範囲で任せながら、許可された資源、利用時間、費用、変更内容を制御できる状態を指す。一手ずつ人間が指示しなければ動けないなら、探索と並列実行による速度向上は失われる。反対に、行動範囲を定めず、操作を記録せず、変更を戻せない状態では、一度の誤判断が政府のデータや本番基盤へ広がる。
Nexus は、この両極の間に統制を置く。エージェントを隔離された環境で動かし、作業に必要な権限だけを期限付きで与え、利用費用と操作履歴を記録し、変更を差し戻せる状態を維持する。自律性を成立させているのは、エージェントが常に正しいという前提ではない。誤りが起きても、何が行われたかを確認し、影響範囲を限定し、停止または復旧できることである。
9.1 権限は作業範囲と時間に合わせて委任する
開発エージェントがコードを読むだけなら、必要な権限は参照に限定できる。依存部品を更新する場合は、開発環境のファイルと外部の部品保管場所へ接続する必要がある。本番へ配備する場合は、さらに強い権限が必要になる。すべての作業へ同じ権限を与えると、簡単な調査で生じた誤操作が、本番環境や機密情報へ到達できる。
権限境界は、エージェントの名称やモデル性能ではなく、実行する操作と失敗時の影響から決める必要がある。コード調査、試験、開発環境への配備、本番環境への配備では、許容できる影響が異なる。同じエージェントを利用する場合でも、工程が進むにつれて権限を段階的に変更し、本番に近づくほど人間の承認と追加証拠を要求する構造が必要になる。
期限付き権限は、作業終了後に不要な権限が残ることを防ぐ。作業のたびに再委任が必要であれば、誰が、どの目的で、どの操作を許可したかを記録できる。恒久的な権限を与える方式では、当初は妥当だった権限が、担当変更や利用目的の変化後も残り、事故時の影響範囲を広げる。
費用上限も権限境界の一部である。AI エージェントは、試験、再生成、複数モデルの呼び出し、クラウド資源の作成を反復できる。技術的に安全な操作であっても、終了条件が曖昧なら利用費用が増え続ける。操作可能な資源だけでなく、何回試行し、どの金額まで利用できるかを定めることで、経済的な影響も限定できる。
| 作業段階 | 必要となる権限 | 追加すべき統制 | 境界が広すぎる場合の帰結 |
|---|---|---|---|
| 調査 | コード、要件、文書、操作記録を読み取る権限が必要となる。 | 機密情報の除外、参照範囲、外部送信の禁止を設定する。 | 調査目的で取得した個人情報や秘密情報が外部サービスへ送信される。 |
| 実装 | 開発用のコード、設定、依存部品を変更する権限が必要となる。 | 隔離環境、変更履歴、利用可能な外部接続、費用上限を設定する。 | 誤った変更や危険な依存部品が、他の案件や共有基盤へ混入する。 |
| 試験 | 試験環境、模擬データ、検査用資源を操作する権限が必要となる。 | 本番データとの分離、資源利用量、試験終了後の消去を確認する。 | 試験用処理が本番データを変更し、不要な資源と費用が残り続ける。 |
| 配備 | 承認された成果物を対象環境へ反映する権限が必要となる。 | 人間の承認、配備対象の固定、変更前状態の保存、段階的な公開を要求する。 | 未承認の変更が本番へ入り、複数の利用者と行政処理へ影響する。 |
| 運用対応 | 監視情報を読み、停止、切り戻し、復旧を実行する権限が必要となる。 | 発動条件、責任者、利用者通知、復旧後の検証手順を定める。 | 誤った自動復旧が障害を拡大し、証拠やデータを失わせる。 |
9.2 自由を奪うのではなく、行動を追えるようにする
観測可能性とは、エージェントが正常に動いているかを画面で眺められることではない。どの入力と権限を与えられ、どの資料を参照し、何を判断し、どの資源を変更し、どの結果を得たかを後から追跡できることである。最終状態だけを記録しても、失敗原因や判断経路は再現できない。
例えば、エージェントが依存部品を更新した後に障害が起きた場合、変更されたファイルだけでは原因を特定できないことがある。どの脆弱性情報を根拠に更新を選び、どの版を候補から除外し、どの試験を実行したかが分かれば、判断過程と検証不足を分けて分析できる。操作履歴は、責任追及だけでなく、再発防止のための工程改善に使われる。
記録量を増やせば観測可能になるわけでもない。モデルへの入力、生成された文章、すべての内部処理を無差別に保存すると、個人情報や秘密情報が監査記録へ複製され、記録自体が新しい危険になる。大量の記録から重大な変更を見つけられなければ、事故後の調査にも利用できない。
必要なのは、判断と影響を再現するための構造化された証拠である。作業目的、委任者、利用した権限、変更対象、試験結果、未確認事項、承認者を対応させる。これにより、エージェントの一連の行動を、技術的な操作と組織上の責任へ結び付けられる。
NIST AI Risk Management Framework 1.0 は、AI の設計、開発、利用、評価を通じて、信頼性に関する考慮を組織のリスク管理へ組み込む枠組みを示している[24]。Generative Artificial Intelligence Profile は、この枠組みを生成 AI に適用し、生成物の誤り、情報の完全性、個人情報、情報セキュリティ、人間と AI の関係など、生成 AI 固有のリスクを識別して管理するための補助文書である[25]。
これらの枠組みを AI Factory の統制へ引きつけると、AI を安全または危険のどちらかへ分類するのではなく、利用目的、扱うデータ、与える権限、失敗時の影響、確認方法を分けて設計する必要がある。モデルやエージェント単位で一律の可否を決めるより、作業ごとの危険に合わせて統制を変える方が合理的である。
9.3 可逆性は変更を戻せるだけでは成立しない
可逆性は、自律的な試行を許すための第二の条件である。変更前の状態へ戻せれば、エージェントが複数の実装案を試し、失敗した案を破棄できる。隔離された開発環境では、この試行錯誤を比較的安全に行える。
ただし、すべての操作が完全に元へ戻せるわけではない。コード変更は版管理によって取り消しやすいが、外部へ送信した情報、住民へ発送した通知、実行済みの支払い、削除された記録は、単純な切り戻しでは回復できない。技術的に変更を戻せても、利用者や制度運用へ生じた影響は残る。
この違いに応じて、操作前の統制を変える必要がある。コードや設定の変更は、自動試行と事後切り戻しを許しやすい。外部通知、金銭処理、法的判断、個人情報の削除は、実行前に人間の承認を要求し、対象と内容を固定する必要がある。可逆性が低い操作ほど、事後対応ではなく事前確認の比重が高くなる。
切り戻しには、戻す対象だけでなく、発動条件と復旧後の確認も必要となる。障害率、応答時間、誤処理件数がどの値を超えたら停止するかを決めていなければ、異常を検知しても判断待ちになる。旧版へ戻した後に、移行中に更新されたデータをどう整合させるかが決まっていなければ、技術的には復旧しても業務記録が食い違う。
| 操作 | 可逆性 | 必要な統制 | 残る影響 |
|---|---|---|---|
| コード変更 | 版管理によって以前の状態へ戻しやすい。 | 変更単位、試験結果、依存関係、切り戻し対象を記録する。 | 変更中に作成されたデータや外部処理は別途整合させる必要がある。 |
| 基盤設定 | 設定値を戻せる場合が多いが、停止時間が発生する。 | 変更前状態の保存、段階的な適用、稼働確認、停止条件を定める。 | 一時的な利用不能や処理遅延は取り消せない。 |
| データ更新 | 更新履歴と退避があれば戻せるが、同時更新との調整が必要となる。 | 対象件数、更新前値、更新者、整合性確認、復旧手順を記録する。 | 利用者が更新後の情報を基に行動した場合、その影響は残る。 |
| 外部通知 | 送信後に取り消すことはできない。 | 送信前の内容確認、対象者の固定、段階送信、誤送信時の訂正手順を置く。 | 誤った情報を受け取った利用者への説明と救済が必要になる。 |
| 給付・許認可判断 | 制度上の再処理は可能でも、事後影響を完全には消せない。 | 実行前承認、判断根拠、対象案件、例外条件、異議申立て経路を確認する。 | 住民の権利、金銭、期限、行政への信頼へ影響が残る。 |
9.4 人間を置くだけでは監督にならない
人間による最終承認を工程へ置いても、確認者が AI の行動、変更内容、残存リスクを理解できなければ、実質的な監督にはならない。大量の生成物へ短時間で承認を求めれば、人間は内容を確認せず、AI の結論を追認する役割になりやすい。
人間と AI の相互作用に関する 18 の指針は、AI が何をできるかを利用者へ示し、状況に応じた情報を提供し、誤りを修正できるようにし、利用者の操作から学ぶ範囲を制御できるようにすることなどを整理している[26]。監督する人間には、結果を見る権限だけでなく、状態を理解し、訂正し、停止し、委任範囲を変更する手段が必要となる。
承認画面へ「問題ありません」と表示するだけでは、判断材料にならない。変更された要件、影響を受けるデータ、実行した試験、失敗した試験、未確認事項、切り戻し可能性を、判断者の役割に合わせて提示する必要がある。業務責任者には制度上の変更と利用者影響を示し、セキュリティ担当者には権限、データ、外部接続の変更を示す。同じ情報を全員へ提示するのではなく、各判断主体が引き受ける責任に対応した証拠を渡す。
人間が介在する地点も、危険に合わせて選ぶ必要がある。軽微なコード整形や既知の試験実行まで毎回承認させれば、確認待ちが増え、自律性の効果が失われる。個人情報の外部送信、本番データの変更、行政判断の確定のような影響の大きい操作には、人間の事前承認が必要となる。判断の有無を一律に決めるのではなく、操作の可逆性と影響範囲によって承認地点を変える。
| 監督の状態 | 確認者へ提示される情報 | 可能な操作 | 実質的な結果 |
|---|---|---|---|
| 名目的な承認 | AI の結論と成功表示だけが提示される。 | 承認または拒否だけを選べる。 | 判断根拠を確認できず、AI の提案を追認する手続きになる。 |
| 技術的な監視 | 操作履歴、変更差分、試験結果、費用が提示される。 | 停止、再試行、切り戻し、権限変更を実行できる。 | 技術的な異常へ対応できるが、制度上の妥当性は別途判断が必要となる。 |
| 業務上の監督 | 要件変更、対象利用者、例外、残存リスク、制度への影響が提示される。 | 公開、延期、限定利用、追加確認を決定できる。 | 技術的な結果を行政上の責任と利用者影響へ接続できる。 |
| 継続的な統治 | 失敗傾向、承認履歴、例外件数、停止実績、基準変更が集約される。 | 権限方針、検査規則、承認地点、利用範囲を更新できる。 | 個別事故への対応を、生産ライン全体の改善へ反映できる。 |
9.5 信頼ではなく依存度を調整する
自動化への信頼は、全面的に信用するか、利用を拒否するかという二者択一ではない。Trust in Automation は、自動化の能力と限界に合わせて依存度を調整する「適切な依存」の必要性を論じている[27]。誤りが多い状況でも従い続ける過信と、十分に有効な状況でも利用しない不使用は、どちらもシステム全体の性能を下げる。
適切な依存には、エージェントの平均的な性能を知るだけでは足りない。どの作業で強く、どの条件で失敗し、失敗をどの検査で検出できるかを把握する必要がある。コード整形では高い自律性を許せても、制度上の例外判定では提案に限定するというように、作業ごとに依存度を変える。
依存度は固定値でもない。新しいモデル、標準、試験、運用実績によって変更される。ある作業で誤りが繰り返されれば、権限を狭め、追加検査や事前承認を置く。十分な期間にわたり安定し、失敗が自動検出できるなら、人間の逐次承認を減らせる。自律性は導入時に一度決める設定ではなく、証拠に基づいて拡大または縮小する運用対象となる。
この構造では、監督の対象も個々の回答から工程全体へ移る。人間がすべてのコードを読む代わりに、権限境界が守られているか、重大な警告が適切に停止を発動したか、切り戻しが成功したか、承認者へ必要な証拠が届いたかを確認する。個別作業の細部を逐次指示せず、エージェントが安全に行動できる条件を管理する。
AI Factory における自律性は、人間の統制を弱めた状態ではない。作業前には権限と費用を限定し、作業中には行動と変更を観測し、作業後には証拠を検証し、異常時には停止と復旧を行える状態である。さらに、取り消せない行政判断には実行前の人間承認を残す。この統制があるため、エージェントへ一手ずつ命令せず、一定範囲の探索と実装を委任できる。
権限、観測可能性、可逆性、人間の承認は、独立した確認項目ではなく一つの因果関係を作る。権限境界が事故の最大範囲を決め、観測可能性が異常と原因を捉え、可逆性が技術的な復旧を可能にし、人間の承認が制度上の影響を引き受ける。いずれかが欠ければ、自律性は速度向上の手段ではなく、確認できない危険を高速に実行する仕組みへ変わる。
10. 実装が速くなると、判断が新しいボトルネックになる
AI がコード、試験、設定、文書を数分から数時間で生成できるようになると、開発期間に占める実装作業の割合は小さくなる。しかし、業務システムを本番へ届けるには、要件の確定、利用部門による確認、セキュリティ審査、例外判断、公開承認が残る。実装だけを高速化すると、案件全体が同じ比率で短縮されるのではなく、従来は実装期間の内側に隠れていた人間側の待ち時間が表面化する。
例えば、AI エージェントが修正案を 10 分で作成しても、業務担当者が内容を確認するまで 3 日を要すれば、案件が前進するまでの時間は 10 分ではなく 3 日を超える。確認後に要件の曖昧さが判明し、設計へ戻れば、AI は短時間で再実装できるが、再び確認と承認を待つ。生成時間が短くなるほど、案件全体に占める引き渡し待ち、判断待ち、手戻りの割合が大きくなる。
10.1 処理能力の差が待ち行列を作る
開発工程は、要件、設計、実装、検証、承認、配備という複数の処理段階から構成される。各段階が一定時間内に処理できる量は異なる。実装段階の処理能力だけを増やし、検証と承認の能力を変えなければ、生成された成果物が後工程の前に蓄積する。
第一の変化は、未確認の変更件数が増えることである。複数のエージェントが並行して実装を進めれば、コード、試験、設定、文書が短時間にレビューへ送られる。第二の変化は、確認者が一件当たりに使える時間が減ることである。処理件数を維持しようとすると、変更理由、影響範囲、失敗条件を十分に確認できず、形式的な承認へ近づく。
この状態でエージェント数をさらに増やしても、提供量は増えない。実装済みだが未確認の変更が増え、変更同士の依存関係も複雑になる。前の変更が承認される前に次の変更が加われば、確認者は個々の差分だけでなく、複数変更を統合した状態を理解しなければならない。生成能力の増加が、レビュー待ちと手戻りを拡大する原因になる。
| 工程 | AI 導入前の主な制約 | AI 導入後に生じる変化 | 能力が不足した場合の帰結 |
|---|---|---|---|
| 問題設定 | 利用部門への聞き取りと資料整理に時間を要する。 | AI が資料を整理して要件候補を大量に提示する。 | 候補を選ぶ基準がなければ、要件が増え、目的が曖昧になる。 |
| 要件確定 | 実装期間と並行して調整され、曖昧さの影響が見えにくい。 | 曖昧な条件が短時間で多数の実装と試験へ展開される。 | 誤った前提に基づく成果物が増え、大規模な手戻りが発生する。 |
| 実装 | 設計をコード、設定、試験へ変換する人間の作業時間が大きい。 | 生成、修正、文書化を複数のエージェントが並行して進める。 | 後工程の能力を超える量の未確認成果物が作られる。 |
| 検証 | 人間が作成できる変更量に合わせて確認対象が増える。 | 生成量が確認者、試験環境、専門審査の処理能力を上回る。 | レビュー待ちが増えるか、一件当たりの確認が浅くなる。 |
| 承認 | 開発終了後の大きな節目として実施される。 | 短い反復ごとに、公開、差し戻し、例外受容の判断が必要となる。 | 少数の責任者へ判断が集中し、案件全体が承認待ちになる。 |
| 配備と運用 | 公開頻度が低く、一回ごとの変更量が大きい。 | 小さな変更を高頻度で公開できる。 | 監視、問い合わせ対応、障害判断が追いつかず、運用負荷が増える。 |
10.2 判断の量だけでなく、判断の種類も変わる
AI 導入後に増えるのは、承認件数だけではない。人間が判断すべき内容も、実装の細部から、要件間の対立、共通化の妥当性、残存リスク、例外の扱いへ移る。これらは、試験結果が成功か失敗かだけでは決められない。
申請処理が技術的に正常でも、制度上救済すべき例外を拒否する可能性がある。セキュリティ上の警告が残っていても、代替手段がなく、行政サービスを停止できない場合がある。反対に、すべての自動試験が成功していても、個人情報の利用範囲を拡大する変更には、法務、業務、セキュリティの判断が必要となる。
AI は、関連資料、試験結果、変更差分、影響候補を整理できる。しかし、複数の価値が衝突する場面で、どの損失を受け入れるかまでは技術的な正解として決まらない。実装能力が高くなるほど、人間はコードを書く作業よりも、何を正しい状態とするかを決める作業へ時間を使う。
10.3 個別成果物の監督から、工程全体の監督へ移る
The Compression Problem は、AI によって情報の作成、分析、伝達が高速化すると、従来の階層、意思疎通、人間による監督がその圧縮に耐えられなくなると論じている[28]。一人の管理者が部下の成果物を順番に確認する方式を、そのまま多数の AI エージェントへ適用すれば、管理者がすべての作業の待ち行列になる。
| 監督単位 | 確認方法 | 適する対象 | 限界 |
|---|---|---|---|
| 成果物単位 | コード、設定、文書を一件ずつ人間が確認する。 | 影響の大きい変更、前例のない処理、判断基準が未確立な作業に適する。 | 生成量が増えると確認者が飽和し、待ち時間が急増する。 |
| 例外単位 | 自動検査で通常変更を処理し、標準外、警告、未確認事項だけを人間へ送る。 | 判断規則と検査方法が明確な反復作業に適する。 | 検査規則に含まれない新しい失敗を見落とす可能性がある。 |
| 工程単位 | 権限、試験、停止条件、承認経路、切り戻しが正しく機能しているかを監視する。 | 多数のエージェントと案件を継続運用する組織に適する。 | 工程指標だけを見て、個別案件の制度上の誤りを見落とす危険がある。 |
| 制度単位 | 自動化が政策目的、利用者の権利、行政責任へ与える影響を評価する。 | 給付、許認可、規制執行など、行政判断を伴う領域に必要となる。 | 判断主体と評価基準が曖昧であれば、技術部門だけでは結論を出せない。 |
10.4 AI は組織の能力差を増幅する
DORA の State of AI-assisted Software Development 2025 は、約 5,000 人の技術専門家を対象とした調査と定性研究から、AI の作用を組織能力の増幅器として整理している[29]。明確な役割、短いフィードバック経路、十分な試験、安定した配備基盤を持つ組織では、AI が既存の強みを拡張する。一方、要件、責任、品質管理が曖昧な組織では、誤った変更、手戻り、確認待ちも同じ速度で増える。
要件管理が弱い組織では、AI が曖昧な依頼を高速に実装し、認識違いを大量の成果物へ展開する。試験基盤が弱い組織では、生成量だけが増え、品質確認は人手に集中する。責任分界が曖昧な組織では、誰も公開判断を引き受けず、変更が承認待ちに滞留する。AI は既存の組織問題を解消する外部装置ではなく、その問題が工程へ現れる速度を上げる。
反対に、Pronghorn で要件と受入条件を構造化し、Nexus で権限と実行環境を統制し、Velocity で滞留と手戻りを測る組織では、AI の生成能力を提供能力へ変えやすい。共通試験が既知の欠陥を除き、専門担当者には制度固有の例外と残存リスクだけを提示できれば、人間の判断能力を重大な箇所へ集中できる。
この差は、導入しているモデルやエージェント数だけを比較しても分からない。同じモデルを利用しても、要件が曖昧で、試験が不足し、承認者が不明な組織では、生成量が未処理の仕事として蓄積する。組織能力が整っている場合には、生成、検証、承認、配備が連続し、一件の改善が次の案件の標準へ戻る。
10.5 Velocity は人間と AI の担当時間を分ける
Velocity が AI の作業時間、人間の作業時間、引き渡し待ち、手戻りを分けて測る理由は、案件全体の上限を特定するためである。実装時間だけを測れば AI 導入は大きな成功に見えるが、要件待ち、確認待ち、承認待ちが増えていれば、利用者へ届くまでの時間は短くなっていない。
AI の担当時間が長ければ、案件文脈、作業分割、モデル選択を見直す。人間の確認時間が長ければ、専門判断の集中と証拠の提示方法を見直す。引き渡し待ちや手戻りが多ければ、責任者、完了条件、Pronghorn で形成した要件、Anti-Drift Harness の検査を改善する。計測値は担当者を順位付けするためではなく、危険度と判断責任を踏まえて工程のどこへ能力を追加するかを決めるために使う。
10.6 提供能力は生成、検証、判断の最小値で決まる
AI Factory の実効的な処理能力は、エージェントが生成できる量だけでは決まらない。要件を確定できる量、検証できる量、責任を持って承認できる量、本番で安全に運用できる量のうち、最も小さい能力が全体の上限になる。
生成能力が毎週 100 件あっても、検証能力が 20 件、承認能力が 10 件なら、本番へ届けられる量は 10 件を超えない。残りはレビュー待ちとして蓄積するか、優先順位を失って放置される。未確認成果物にも、依存部品の更新、要件変更、競合解消が必要になるため、滞留自体が新しい保守費を生む。
全体の速度を上げるには、最も遅い段階を特定して改善する必要がある。実装が上限ならエージェントと共通部品を増やす。検証が上限なら自動試験と専門担当者への振り分けを改善する。承認が上限なら、危険度に応じて権限を分散し、定型変更の逐次承認を減らす。運用が上限なら、公開頻度を増やす前に監視、停止、復旧の能力を整える。
この構造から、AI 時代の開発速度は、AI がどれだけ作れるかではなく、組織がどれだけ検証し、採用し、責任を引き受けられるかによって制約される。アルバータ州政府の AI Factory が工程計測、人材教育、品質検査、期限付き権限を同時に整えているのは、実装能力だけを増やしても行政サービスの提供量には変わらないためである。
5 か月から 4 日という差を継続的な組織能力へ変えられるかは、エージェントの生成速度では決まらない。要件を確定する人間、証拠を作る検査工程、例外を裁定する責任者、異常時に停止・復旧する運用体制が、生成能力と同じ速度で働けるかによって決まる。実装が速くなった後に残る判断を設計できることが、AI Factory を一時的な試作環境から行政システムの生産ラインへ変える条件となる。
11. 効果を決めるのは業務の同型性である
AI Factory の効果は、対象システムの古さや規模だけでは決まらない。先行案件で整備した要件表現、共通部品、試験、権限、配備手順を、後続案件がどこまで同じ形で利用できるかによって決まる。制度名や利用部門が異なっていても、申請、審査、承認、通知、記録という処理構造が共通していれば、前の案件で確立した工程を次の案件へ持ち越せる。
ここでいう同型性は、画面が似ていることや、同じプログラミング言語を使っていることではない。情報を受け取る主体、処理状態が変わる条件、判断する権限、保存すべき証拠、例外を人間へ戻す地点が、共通の構造として表現できることを指す。表面的に似た申請システムでも、判断規則、法的効果、保存期間、異議申立ての手続きが異なれば、共通化できる範囲は限定される。
11.1 Factory 方式が適合しやすい条件
Factory 方式へ適合しやすい第一の条件は、業務を明示的な状態遷移として表現できることである。申請を受け付け、形式を確認し、不足資料を求め、審査し、承認または却下し、結果を通知するという流れを定義できれば、各段階の入力、権限、完了条件を実装と試験へ接続できる。処理状態が明確であるほど、Pronghorn で要件を構造化し、AI エージェントへ作業を分配しやすくなる。
第二の条件は、同じ骨格を持つ案件が継続して存在することである。一度限りのシステムでは、標準、共通基盤、検査、教育へ投じた費用を他の案件へ配賦できない。給付、補助金、許認可、報告受付のように、異なる制度でも共通の案件管理機能を繰り返し利用できれば、案件数が増えるほど一件当たりの準備範囲を狭められる。
第三の条件は、正しさを受入条件と証拠へ変換できることである。入力条件、権限、状態遷移、計算結果、通知内容を試験可能な形で定義できれば、生成物を機械的に確認できる。判断の大部分が担当者の経験、関係者との交渉、個別事情の総合評価に依存する業務では、実装を自動化しても、人間による確認と裁定が工程の中心に残る。
第四の条件は、共通基盤へ接続できることである。認証、書類提出、通知、監査記録、配備を承認済みの方式へ統一できれば、案件固有の開発範囲を業務規則へ集中できる。古い外部システムが独自形式、専用回線、文書化されていない通信手順へ依存している場合には、接続調査、模擬環境、データ変換、移行試験が支配的となり、生成コードの速度が案件全体へ反映されにくい。
第五の条件は、失敗時の影響を段階的に限定できることである。小規模な利用者群から公開し、誤処理を差し戻し、案件を再処理できる業務では、短い反復から証拠を集めながら適用範囲を広げられる。一度の誤動作が生命、安全、法的権利、巨額の資産へ不可逆な影響を与える領域では、事前検証と人間承認の比率が高くなり、Factory 方式の速度効果は小さくなる。
| 判断条件 | 適合しやすい状態 | 慎重な評価が必要な状態 | 開発速度への影響 |
|---|---|---|---|
| 業務構造 | 申請、審査、承認、通知などの状態遷移と担当権限を明文化できる。 | 担当者の暗黙判断、関係者との交渉、案件固有の事情によって処理が変わる。 | 状態と完了条件を明示できるほど、実装、試験、進捗管理を共通化できる。 |
| 反復件数 | 同じ業務骨格を持つ複数の制度やシステムで共通基盤を利用できる。 | 一度限りの案件であり、先行投資を後続案件へ配賦できない。 | 反復件数が増えるほど、要件ひな型、部品、試験、配備手順の再利用効果が大きくなる。 |
| 品質条件 | 受入条件、計算結果、権限、監査証跡を機械的な検査へ変換できる。 | 正しさが状況依存であり、評価者間の合意形成と裁量判断が中心となる。 | 自動検査できる範囲が広いほど、人間は制度固有の例外と残存リスクへ集中できる。 |
| 外部連携 | 標準化された認証、データ形式、接続仕様、模擬環境を利用できる。 | 仕様が不明な旧システム、専用機器、個別契約、手作業のデータ交換へ依存する。 | 外部接続が不透明であるほど、調査、調整、移行、結合試験が全期間を支配する。 |
| データ移行 | データ定義、品質、所有者が明確であり、移行結果を照合できる。 | 重複、欠損、意味の不一致が多く、旧システムの挙動から意味を推定する必要がある。 | 移行準備が重い案件では、新システムの実装が速くても公開時期は短縮しにくい。 |
| 失敗影響 | 段階公開、差し戻し、再処理、旧版への切り戻しによって影響を限定できる。 | 一度の誤動作が生命、安全、権利、金銭、行政期限へ不可逆な影響を与える。 | 可逆性が低いほど、事前審査、専門家確認、利用者救済の準備に時間を要する。 |
| 変更頻度 | 制度変更の起点と責任主体が明確であり、規則を一貫して更新できる。 | 複数機関の判断で頻繁に例外が追加され、正式な規則と現場運用が一致しない。 | 変更理由を追跡できなければ、共通部品へ例外が累積し、再利用効果が低下する。 |
11.2 同型性は制度名ではなく変更理由から判定する
二つのシステムが同じ申請画面を持つからといって、同じ部品へ統合できるとは限らない。共通化の境界は、現在の形が似ているかではなく、将来どの理由で変更されるかによって決める必要がある。政府共通の認証方式は、セキュリティ方針や本人確認基準の変更によって更新されるため、共有基盤へ置きやすい。給付資格や許可条件は、個別制度の法令や政策によって変わるため、制度固有のモジュールへ残す方が安全である。
変更理由の異なる処理を一つの部品へ押し込むと、共通部品に制度別の条件分岐が増える。一つの制度を変更するたびに、無関係な制度への影響を確認しなければならず、試験範囲と承認者が拡大する。再利用によって減らすはずだった調整作業が、共通基盤の変更待ちとして戻ってくる。
反対に、同じ理由で変更される機能を個別案件へ残すと、同じ修正を複数システムへ反映しなければならない。例えば、政府共通の本人確認基準が変わったとき、各システムが独自認証を持っていれば、改修、試験、公開を個別に繰り返すことになる。共通基盤へ統合されていれば、一度の変更と互換性確認によって利用案件へ反映できる。
AI はコード資産を横断し、似た処理、重複した画面、共通するデータ項目を抽出できる。Git Insights Ministry も、省庁内に散在する重複機能を共有モジュールへ整理する構想を示している[11]。ただし、技術的な類似性は統合候補を示す証拠であり、制度上も統合してよいという結論ではない。業務責任者、法務、セキュリティ、運用担当者が、規則の意味、責任境界、変更主体を確認する必要がある。
| 処理例 | 共通化しやすい部分 | 個別に残すべき部分 | 境界を誤った場合 |
|---|---|---|---|
| 本人確認 | 認証方式、セッション管理、操作記録、共通の本人確認基準を共有できる。 | 制度ごとに利用資格を判定する条件は個別規則として残す。 | 認証と制度資格を混同し、本人であっても利用資格のない処理を許可する。 |
| 書類提出 | アップロード、形式検査、ウイルス検査、保存、監査記録を共有できる。 | 必要書類、保存期間、閲覧権限、証拠としての効力は制度ごとに定義する。 | 一制度の保存規則を他制度へ適用し、過剰保存または早期削除を招く。 |
| 案件状態 | 受付、確認中、追加資料待ち、完了という基本的な状態管理を共有できる。 | 承認条件、却下理由、再申請、異議申立ての遷移は制度固有となる。 | 状態名だけを統一し、実際には異なる法的効果を同じ処理として扱う。 |
| 通知 | 送信経路、宛先確認、配信記録、再送制御を共有できる。 | 通知内容、法定期限、到達によって生じる効果は個別に管理する。 | 技術的には送信できても、必要な説明や期限を満たさない通知を行う。 |
| 監査 | 操作主体、時刻、対象、変更前後の値を記録する形式を共有できる。 | 保存期間、閲覧可能者、監査時に必要な証拠は制度ごとに追加する。 | 記録は存在していても、法的・業務的な説明に必要な情報が不足する。 |
11.3 不確実性が高い案件では実装以外が支配的になる
Factory 方式への適合度が低い案件では、AI の生成能力が役に立たないわけではない。コード調査、試験作成、移行手順の候補、文書整理には利用できる。しかし、案件全体の期間を決める作業が実装以外にあるため、4 日や 11 週間という速度差を再現しにくい。
古い外部システムとの接続では、仕様書が現状と一致せず、実際の通信内容や運用手順から挙動を推定する場合がある。AI が接続コードを短時間で生成しても、接続先の利用可能時間、試験用データ、相手組織の承認、障害時の責任分界が確定しなければ結合試験へ進めない。技術的な実装速度より、組織間の調整速度が上限になる。
データ移行でも同じ構造が生じる。新しいデータベースを短時間で作れても、旧システムに重複、欠損、表記揺れ、意味の変化があれば、何を正しい値として移すかを決めなければならない。データ修正が住民の権利や支給額へ影響する場合には、自動的な補正ではなく、根拠を確認できる判断手順が必要となる。
例外の多い業務では、定型処理を自動化しても、残された少数の例外が多くの確認時間を消費する。標準処理の 90 ％ を短縮しても、残りの 10 ％ が法務、業務責任者、外部機関の合意を必要とすれば、案件全体の期間はその判断に制約される。割合だけでなく、例外一件当たりの処理時間と影響を評価する必要がある。
失敗影響が大きい領域では、検証を増やすこと自体が正常な費用となる。段階公開できない基幹処理、誤判定が権利喪失につながる行政判断、停止が許されない安全関連システムでは、複数環境での試験、独立審査、障害訓練、復旧確認が必要になる。Factory 方式はこれらの検査を支援できるが、必要な証拠を省略して速度だけを合わせることはできない。
11.4 4 方式を使い分ける理由へ戻る
The Four Approaches to AI Modernization は、AI Garage、AI Factory、AI Rationalization、Government 3.0 を、対象システムの状態と必要な組織変化に応じて使い分ける構想として提示している[5]。第 2 章で確認した 4 方式と廃止の選択を、Factory 方式の適合条件へ戻して整理すると次のようになる。
| 対象の状態 | 適する方式 | 選択理由 | 誤った方式を選んだ場合 |
|---|---|---|---|
| 業務は有効で技術的欠陥が限定的 | AI Garage を適用する。 | 既存の挙動を維持しながら、脆弱性、依存部品、試験不足を修正できる。 | 全面再構築によって、移行危険、教育費、仕様漏れを不必要に増やす。 |
| 新規サービスまたは旧構造を保存する価値が低い | AI Factory を適用する。 | 現在の要件と共通基盤から、標準化された工程で新規構築できる。 | 修理を繰り返して、古い設計、依存部品、運用上の非効率を固定する。 |
| 多数のシステムが共通機能を重複して保有 | AI Rationalization を適用する。 | 省庁全体を分析し、共有部品と制度固有モジュールへ再編できる。 | 個別再構築を高速化しても、重複した保守対象と費用が残る。 |
| データと業務規則を直接統治できる | Government 3.0 を適用する。 | 固定アプリケーションを減らし、目的に応じてエージェントが操作環境を構成できる。 | 統治が未成熟なまま適用すると、誤った規則と不明確な責任でデータを操作する。 |
| 業務上の必要性を失っている | 廃止を選択する。 | 開発、移行、運用、セキュリティ対応を将来にわたって発生させずに済む。 | 不要な業務とシステムを新しい技術で再生産し、保守責任を延長する。 |
11.5 対象選定が Factory の経済性を決める
Factory 方式の成果を政府全体へ広げるには、Factory を利用する案件数を増やすだけでは足りない。共通工程を利用できる案件を選び、個別判断の多い案件へ無理に適用せず、重複したシステム群を先に整理する必要がある。適合度の低い案件を大量に投入すれば、例外対応、個別部品、追加審査が Factory 側へ蓄積し、共通基盤の単純さが失われる。
対象選定には、技術部門だけでなく、業務部門、法務、セキュリティ、データ所有者、運用担当者の判断が必要となる。技術部門は共通化可能な構造と実装費を評価できる。業務部門は制度上残すべき差異を判断する。法務とセキュリティは、誤りの影響、保存義務、権限境界を確認する。運用担当者は、公開後に監視、停止、復旧を継続できるかを評価する。
選定時に見るべき数字も、現行システムの開発費だけではない。類似案件の将来件数、共通部品の利用率、旧システムの廃止可能性、データ移行費、外部調整期間、例外処理の割合を見積もる必要がある。Factory の初期費用が高くても、同型の案件が継続し、旧システムを廃止できるなら、政府全体では回収できる。個別案件が安く見えても、共通化できず旧版も残るなら、総費用は下がらない。
AI Factory の効果を決めるのは、AI がどれほど多様なコードを書けるかではない。異なる制度の中から同じ工程を見つけ、共通化する部分と人間の判断へ残す部分を分け、その工程を複数案件で反復できるかである。同型性が高い領域では、前の案件で確立した要件、部品、試験、監査、配備が次の案件の初期条件となる。同型性が低い領域では、実装が速くても、制度調整、例外判断、移行、検証が案件全体を支配する。
4 日と 11 週間という成果は、Factory 方式へ適合する条件の下で得られた。そこから導かれる刷新戦略は、すべてのシステムを AI で作り直すことではない。修理すべきもの、作り直すべきもの、統合すべきもの、廃止すべきものを先に分け、新規構築が合理的で、共通工程を再利用できる対象へ Factory の能力を集中することである。生成能力が高くなるほど、何を作らないか、何を共通化しないか、どの方式へ送るかという対象選定の価値が高くなる。
12. 速くなったのはコードだけではない
5 か月から 4 日という差は、生成 AI が実装候補を作る速度を大きく変えたことを示している。既知の業務と期待される結果を理解する元の開発者が、AI Factory を使って、旧システムの処理に公開申請画面と書類提出機能を加えた試作品を短期間で成立させた。要件が一定程度明らかな業務では、コード、画面、試験、文書を作る時間が従来より短くなる可能性を確認できる。
一方、2026 年 6 月 1 日に本番公開された ACIP の 11 週間には、4 日の試作品には含まれない個人情報保護、本人確認、セキュリティ審査、本番基盤、利用部門の確認、公開判断が含まれる。両者の期間差は、AI の効果の強弱ではなく、成果物の成熟度と対象範囲の違いによる。
11 週間という結果を成立させたのは、単一モデルのコード生成ではなかった。Pronghorn は業務資料、要件、受入条件、アーキテクチャを実装と試験へ接続し、Nexus は期限付き権限と隔離環境の下で試験と配備を可能にした。Velocity は AI の実行時間、人間の判断時間、引き渡し待ち、手戻りを分け、生成後に案件が停止する場所を測定した。短縮されたのはコーディング時間だけではなく、実装の前後にある待ち時間と再作業である。
再利用の単位も、個別のコード片から開発工程へ広がった。認証、監査、試験、配備を共通基盤へ置き、過去の欠陥を試験へ戻せば、前の案件で行った判断が次の案件の初期条件になる。その代わり、費用の一部は個別案件から共通基盤へ移るため、ACIP の約 10 万 8,000 カナダドルだけでは経済性を判定できない。先行投資の再利用件数、個別実装の減少、旧システムの廃止、共通基盤の運用費を合わせて測る必要がある。
品質保証と自律性も工程へ移された。作成役とは異なる確認役、機械的な試験、成果物間の整合性検査、セキュリティ基準によって既知の危険を絞り込み、人間は制度固有の例外、残存リスク、取り消せない操作、公開可否を判断する。作業前には権限、時間、費用、対象資源を限定し、作業中の操作を記録し、異常時には停止と切り戻しを行う。この観測可能性と可逆性があるため、一手ずつ指示せずに一定範囲の作業を委任できる。
同じ構造が、あらゆるシステムへ同じ効果を生むわけではない。Factory 方式が適合しやすいのは、状態遷移を明文化でき、共通基盤を複数案件で利用でき、受入条件を機械的な検査へ変換できる業務である。暗黙判断、個別交渉、複雑な旧システム連携、不可逆な失敗が支配的な領域では、制度調整、データ移行、例外判断、独立審査が案件全体の期間を決める。修理、Factory による新規構築、システム群の統合、廃止を先に分ける対象選定が必要となる。
アルバータ州政府が報告する期間と費用は、二つの内部事例から得られた値である。従来方式との並行比較、AI Factory の総構築費、長期保守費、障害率、利用者満足度、旧システムの廃止実績は、今後の検証を必要とする。4 日、11 週間、約 10 万 8,000 カナダドルという数字は有力な実務上の証拠だが、あらゆる行政システムへ適用できる効果量ではない。
アルバータ州政府の事例から導かれる帰結は、生成 AI がソフトウェア開発を自動化したということではない。要件、基盤、検証、監査、権限、組織知を再利用可能な生産ラインへ変え、制度上の判断を引き受ける人間と接続したとき、生成 AI の速さが一時的な試作から組織の継続的な開発能力へ変わるということである。
参考文献
- Government of Alberta, Ministry of Technology and Innovation, AI Factory Case Study: From Five Months to Four Days（2026-06-19）. https://thevelocitywhitepapers.com/paper/rhx4t/
- Sida Peng, Eirini Kalliamvakou, Peter Cihon, Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot（2023-02-13）. https://arxiv.org/abs/2302.06590
- Joel Becker, Nate Rush, Elizabeth Barnes, David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（2025-07-12）. https://arxiv.org/abs/2507.09089
- id774, 生成 AI の競争軸は、モデルから業務実装へ移る（2026-06-25）. https://blog.id774.net/entry/2026/06/25/4922/
- Government of Alberta, Ministry of Technology and Innovation, The Four Approaches to AI Modernization（2026）. https://thevelocitywhitepapers.com/paper/zgym1/
- Government of Alberta, Ministry of Technology and Innovation, The AI Factory: Design and Ideation (Pronghorn)（2026）. https://thevelocitywhitepapers.com/paper/qthji/
- Government of Alberta, Ministry of Technology and Innovation, The AI Factory: Orchestration and Observation (Nexus)（2026-06-16）. https://thevelocitywhitepapers.com/paper/uwpxr/
- Government of Alberta, Ministry of Technology and Innovation, The AI Factory: Measuring Project Delivery (The Velocity Game Engine)（2026）. https://thevelocitywhitepapers.com/paper/k3tc3/
- Government of Alberta, Ministry of Technology and Innovation, The Agentic Technology Stack（2026）. https://thevelocitywhitepapers.com/paper/qxlzo/
- id774, 2026 年上期の Devin の進化を振り返る（2026-07-10）. https://blog.id774.net/entry/2026/07/10/4976/
- Government of Alberta, Ministry of Technology and Innovation, Git Insights Ministry（2026-06-16）. https://thevelocitywhitepapers.com/paper/offjm/
- Linda M. Northrop, Paul C. Clements, Felix Bachmann, John K. Bergey, Gary Chastek, Sholom G. Cohen, Patrick Donohoe, Lawrence G. Jones, Robert W. Krut Jr., Reed Little, John McGregor, Liam O’Brien, A Framework for Software Product Line Practice, Version 5.0, Software Engineering Institute（2012-12-31）. https://www.sei.cmu.edu/library/a-framework-for-software-product-line-practice-version-50/
- Government of Alberta, Ministry of Technology and Innovation, Measuring Failure and Success（2026）. https://thevelocitywhitepapers.com/paper/yu5k9/
- Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler, The SPACE of Developer Productivity: There’s More to It than You Think, ACM Queue 19(1)（2021-03-06）. https://queue.acm.org/detail.cfm?id=3454124
- ISO/IEC, ISO/IEC 25010:2023 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model（2023-11-15）. https://www.iso.org/standard/78176.html
- Government of Alberta, Ministry of Technology and Innovation, The AI Academy: Investing in People（2026-06-19）. https://thevelocitywhitepapers.com/paper/dt725/
- id774, AI に任せる前に、人間が残すべき判断（2026-06-21）. https://blog.id774.net/entry/2026/06/21/4912/
- Government of Alberta, Ministry of Technology and Innovation, Red, Blue, Green, and Yellow Agents（2026-06-16）. https://thevelocitywhitepapers.com/paper/l199t/
- Government of Alberta, Ministry of Technology and Innovation, Technical: The Anti-Drift Harness（2026）. https://thevelocitywhitepapers.com/paper/of1cj/
- Murugiah Souppaya, Karen Scarfone, Donna Dodson, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, NIST SP 800-218（2022-02-03）. https://doi.org/10.6028/NIST.SP.800-218
- OWASP Foundation, OWASP Application Security Verification Standard, Version 5.0.0（2025）. https://owasp.org/www-project-application-security-verification-standard/
- Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, Ramesh Karri, Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions（2021-08-20）. https://arxiv.org/abs/2108.09293
- Neil Perry, Megha Srivastava, Deepak Kumar, Dan Boneh, Do Users Write More Insecure Code with AI Assistants?, Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security（2023）. https://doi.org/10.1145/3576915.3623157
- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1（2023-01-26）. https://doi.org/10.6028/NIST.AI.100-1
- Chloe Autio, Reva Schwartz, Jesse Dunietz, Shomik Jain, Martin Stanley, Elham Tabassi, Patrick Hall, Kamie Roberts, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1（2024-07-26）. https://doi.org/10.6028/NIST.AI.600-1
- Saleema Amershi, Dan Weld, Mihaela Vorvoreanu, Adam Fourney, Besmira Nushi, Penny Collisson, Jina Suh, Shamsi Iqbal, Paul Bennett, Kori Inkpen, Jaime Teevan, Ruth Kikin-Gil, Eric Horvitz, Guidelines for Human-AI Interaction, Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems（2019）. https://doi.org/10.1145/3290605.3300233
- John D. Lee, Katrina A. See, Trust in Automation: Designing for Appropriate Reliance, Human Factors 46(1)（2004）. https://doi.org/10.1518/hfes.46.1.50_30392
- Government of Alberta, Ministry of Technology and Innovation, The Compression Problem（2026）. https://thevelocitywhitepapers.com/paper/eujjc/
- DORA, State of AI-assisted Software Development 2025（2025）. https://dora.dev/research/2025/dora-report/