マーコール株式会社

2026年5月1日

政府デジタル化の推進と組織横断的な役割
18F（エイティーンエフ）は、米国連邦政府調達局（GSA）下に2014年に設立されたデジタルサービス部門です。シリコンバレーなどから人材を期間限定で政府に招致し、組織横断的でアジャイルな手法を用いて行政サービスの近代化を推進する役割を担ってきました。18Fという名称は、GSAの所在地である1800 F Streetに由来します。2025年の政権交代に伴い組織は解散されましたが、18Fが開発を主導した政府共通の認証基盤である「Login.gov」や、政府のデザイン標準「U.S. Web Design System」は、現在の米国においても重要なデジタルインフラとなっており、開発されたソースコードについては、全てオープンソースとして公開され、GitHub上で今なおアーカイブとして残されています。

制度のコード化という挑戦
私がRules as Code（法令や規則をコンピュータが直接解釈・実行可能なコードとして記述する手法）の事例を調査する中で、今なお多くの示唆に富み、普遍的な教訓が凝縮された事例として注目したのが、社会保障プログラムの判定基準をコード化する 18F の「適格性APIイニシアチブ」です。

米国において、SNAPやメディケイドといった主要な社会保障プログラムは、連邦政府が資金を提供して基本的なルールを定め、各州へ伝えられる際は、PDFや紙媒体による伝達が主流でした。実際の運用や資格審査、システムの管理は州や地方自治体に委ねられており、制度の変更が伝達されると、各州は多額の費用と時間を投じてシステムのロジックをエンジニアが手作業で修正していました。このプロセスは極めて非効率であり、実装エラーによる給付遅延などの重大なリスクを招いていました。

2017年に始動した本構想は、連邦政府がルールのソースコードをAPIとして提供し、各州が自社システムへ直接取り込める仕組みを目指しました。これは、制度ルールの可読性と汎用性を高めるための実験的な試みでもありました。

現場主義とシビックテックとの連携
18Fは給付制度の運用実態を多角的に精査するため、複数の社会保障プログラムの専門家や現場の担当者と密接に協働し、被災地での実地調査を含む、徹底したユーザーリサーチを行い、申請から給付に至るまでの生のプロセスを直接精査しました。さらに、チームメンバーの個人的ネットワークから、Code for America等のシビックテック・コミュニティとも連携し、官民の枠を超えた協力体制を構築しました。関係者のオンボーディングの様子や週次の進捗報告など、当時の詳細な記録は18Fの解散後もGitHubで閲覧可能となっており、そこからプロジェクトが歩んだ軌跡を詳細に検証することが可能です。

分権の壁による方向転換 　
当時の記録にはAPI構築の技術的な難易度は決して高くはなかったことが記されています。しかし、プロジェクトは次第に国の統治システムという構造的な壁に直面することになります。給付資格を一元判定するAPI構想に対し、州側から「自分たちでプログラムを運営しているのだから、資格認定のような核心的な判断を連邦政府に委ねるのは問題がある」という反発と懸念が示されたためです。さらに不運なことに、解決策を模索していた矢先に新型コロナウイルスのパンデミックが重なりました。行政機関は日々の危機対応に追われ、システムの移行リスクを伴うような実験に協力する余裕が失われてしまいました。

そのため、プロジェクトはAPIの一元提供から、市民が自分で受給資格を試算できる「プリスクリーナー（事前審査ツール）」のプロトタイプの開発へと方向転換します。ロジックをJavaScriptとして公開し、各機関が自由に検証や修正、利用を行える形にプロジェクトの目標を切り替えたのです。

技術の問題を超えた責任の所在
社会給付制度を設計するのは連邦政府ですが、実際の運用に関する作業は州などの現場が行います。本構想の前から、シビックテックや非営利団体もまた、独自に適格性判定ツールを開発するなど、市民の申請支援において重要な役割を担っていました。しかしシビックテックも、複雑な法律やマニュアルを独自に解読し、各団体がゼロからルールをコード化するという多大な重複作業を行っていました。18Fがプリスクリーナーのコードをオープンソースとして公開したことは、この状況を一変させました。適格性判定ルールを再利用することで大幅な時間の短縮が可能になり、実際、たった２人のエンジニアが全米50州と準州を網羅する、複数の給付プログラムの適格判定ツールを開発するという、18Fのプロジェクトメンバーも驚くような結果を収めたのです。

ソースコードの公開は、既存の活動を質的に補完し、官民が連携して信頼性の高い情報を市民へ届ける一連のエコシステムをより強固にする役割を果たしました。しかし、このプロジェクトは2020年に終了した後も、私たちに以下のような重要な問いを残しています。

1．連邦政府がロジックを提供し、州側が運用の自律性をどう維持するかという点。
2．導入側の組織が、その価値を移行に伴うリスク以上に実感できるかどうかという課題
3．そして、コードによる判断の結果に対し、最終的に誰が責任を負うべきかという論点です。

筆者が当時のプロジェクト主要メンバーへ書面で連絡をとったところ、応じてくれたMike Gintz氏からは、「導入に伴うコストやリスクをインセンティブで上回ろうとするのではなく、そもそも導入時の負担を最小限に抑え、その場で迅速かつ明確な価値を実感できるようにすることが重要だ」との知見を得られました。一方で彼は、適格性APIはその性質上、そのようなアプローチを取ることが難しかった点も指摘しています。

18Fによる一連の試行と、その後に続いた活用事例は、デジタル変革の本質が単なる技術の実装にとどまらず、いかにして「責任」と「価値」を再設計し、自律的なエコシステムを構築するかという点にあることを、今日においても明確に示しています。

参考資料

1. 18F Eligibility API Initiative（GitHub）
2. Beeck Center for Social Impact + Innovation（Demo Day）
3. 18F Guides（実務ガイド）
4. 18F公式GitHub
5. 「法制事務のデジタル化に関する取組の概要」（2025年5月、デジタル庁）
6. Virginia Poverty Law Center SNAP Calculator
7. SNAPScreener.com

#18F #EligibilityAPI #DigitalGovernment #CivicTech #PublicPolicy #RulesAsCode