2026年5月1日
18Fの功績
18F（エイティーンエフ）は、米国連邦政府調達局（GSA）下に2014年に設立されたデジタルサービス部門です。民間から専門人材を招致し、アジャイルな手法で行政サービスの改善を行う、政府内の実験的な組織でした。
18Fという名称は、GSAの所在地である1800 F Streetに由来します。2025年の政権交代に伴い組織は解散されましたが、その成果は「Login.gov」や、「U.S. Web Design System」など、現在も重要なデジタルインフラとして機能しており、その成果はオープンソースとしてGitHub上に残されています。
その18Fが取り組んだ中でも、特に示唆に富むのが「適格性APIイニシアチブ」です。
制度をコードとして配布するという発想
米国において、SNAPやメディケイドといった社会保障プログラムは、連邦政府が基本ルールを定め、各州がそれをもとに運用します。
制度変更は主にPDFや文書で伝達され、各州はそれを解釈し、自らのシステムに実装します。このプロセスは非効率であり、実装の遅れやエラーの原因となってきました。
18Fの構想はシンプルでした。
ルールそのものをコード化し、APIとして提供する。各州はそれを呼び出すだけでよい。
これはRules as Code（法令や規則をコンピュータが直接解釈・実行可能なコードとして記述する手法）の典型的なアプローチであり、合理的な解決策に見えます。
2017年に始動した本構想は、連邦政府がルールのソースコードをAPIとして提供し、各州が自社システムへ直接取り込める仕組みを目指しました。これは、制度ルールの可読性と汎用性を高めるための実験的な試みでもありました。
現場主義とシビックテックとの連携
18Fは給付制度の運用実態を精査するため、複数の社会保障プログラムの専門家と密接に協働し、被災地での実地調査を含む徹底した現場主義で申請から給付に至るまでのプロセスを検証しました。さらに、Code for America等のシビックテック・コミュニティとも連携し、官民の枠を超えた協力体制を構築しました。当時の詳細な記録は今日もなおGitHubで閲覧可能となっており、そこから日々のコミュニケーションや、組織間の対立や葛藤といったプロジェクトの軌跡を追体験することができます。
技術は問題ではなかった
当時の記録に、API構築の技術的なハードルは決して高くはなかった、と記されています。問題は、州側からの反発でした。
「資格認定のような核心的な判断を、連邦のAPIに委ねることはできない」
この反応は自然です。社会保障制度において、最終的な責任を負うのは州だからです。この問いに対する制度的な答えは存在していませんでした。
Shadow Softwareはなぜ生まれるのか
この構造の帰結が、いわゆる「シャドウソフトウェア」です。
連邦政府が提供するルールが紙のPDFや複雑なマニュアルに留まっているため、州やシビックテックは自然言語の文書をもとに、独自にロジックを実装せざるを得ません。
その結果、
同じ制度に対する複数の非公式実装が生まれる
解釈の不一致が生じる
実装コストが繰り返し発生する
という状況が常態化します。
プリスクリーナーへの方向転換
プロジェクトチームが解決策を模索していた矢先、新型コロナウイルスのパンデミックが重なりました。行政機関は日々の危機対応に追われ、システムの移行リスクを伴うような実験に協力する余裕が失われてしまいました。
そのため、プロジェクトはAPIによるルールの一元提供から、市民が自ら受給資格を試算できる「プリスクリーナー（資格の事前審査ツール）」へと方向転換します。
つまり、公式な判断の提供ではなく、参考情報の提供へと、よりリスクが低い方に目的を切り替えたのです。
政府の外側で広がった実装
18Fが適格性を判断するロジックをオープンソースのコードとして提供したことで、
セーフティーネットを支えるNPOやシビックテックがプリスクリーナーのコードを再利用することが可能となりました。実際に、Virginia Poverty Law Center（VPLC）というNPOのサイトで活用されているほか、たった２人のエンジニアが全米50州と準州を網羅する、複数の給付プログラムの適格判定ツールを開発するという、18Fのプロジェクトメンバーも驚くような成果を収めたのです。
導入負担ではなく、責任の設計
当時のプロジェクト主要メンバーの一人であるMike Gintz氏は、「導入に伴うコストやリスクをインセンティブで上回ろうとするのではなく、そもそも導入時の負担を最小限に抑え、その場で迅速かつ明確な価値を実感できるようにすることが重要だ」と指摘しています。
この視点は、多くのデジタル施策において妥当するものです。
しかし同時に同氏は、適格性APIの性質上、そのようなアプローチを取ること自体が難しかったとも振り返っています。
ここに、このプロジェクトの本質的な難しさがあります。
プロジェクトが残した三つの問い
このプロジェクトは、次のような問いを残して2020年に終了しました。
1．連邦政府がロジックを提供し、州側が運用の自律性をどう維持するかという点。
2．導入側の組織が、移行に伴うリスク以上に価値を実感できるかどうかという課題。
3．そして、コードによる判断の結果に対し、最終的に誰が責任を負うべきかという論点です。
この問いに答えられない限り、どれほど優れた技術であっても、組織はそれを採用できません。
この事例の本質
この試みは失敗ではありません。
その試行の記録と、その後に続いた活用事例は、デジタル変革の本質が単なる技術の実装にとどまらず、「責任」をどう設計し、自律的なエコシステムを構築するかという点にあることを、今日においても明確に示していると言えます。
参考資料
マーコール株式会社 
コメントを残す