APIを公開する案件に入ると、まず疎通確認とレスポンス形式のチェックに気持ちが向きます。連携先からのリクエストに正しく応答できた時点で、仕事が一段落したように感じることがあります。デジタル庁の政府相互運用性フレームワーク（GIF）説明資料は、相互運用性を「2つ以上のシステムやサービスの間で共通の仕様やデータ形式、ルールなどに対応することで情報交換ができ、交換された情報を想定したとおりに使用できること」と定義しています³。つながる設計と、想定したとおりに使われる設計は、この定義の中では別の条件として並んでいます。この記事では、GIFの説明資料をもとに、公開後に動かしにくい部分がどこにあるかを整理します。

1. つながっても、想定どおり使えるとは限りません

「使える」の基準は、接続の可否だけではありません

GIFは、政府情報システムが保有するデータの相互運用性を確保するためのデータモデルやルールをひな形としてまとめたものです¹。デジタル社会推進標準ガイドラインの中では実践ガイドブックという位置づけにあり²、強制する規格というより、設計の拠り所として置かれています。公開後に届く変更の要求の多くは、接続できるかどうかではなく、「想定したとおりに使えるか」という部分から生まれます。

変更の要求は、公開のあとに段階を追って届きます

公開の直後は、疎通確認とドキュメントどおりの応答さえ取れれば十分に見えます。連携先が増えるにつれて、区分値の解釈違いやコード値のずれが表面化し、想定どおりに使えない箇所への調整の要求へと変わっていきます。図1は、この3つの段階を示したものです。

出典：デジタル庁「政府相互運用性フレームワーク（GIF）説明資料」（2025年3月）をもとに作成³

接続テストが通った時点で気持ちが緩むのは自然なことです。むしろ、そこから先にどんな連携先が増えていくかを想像できるかどうかが、公開後の負担を左右します。案件に入る段階で、この3つの段階のどこを任されるのかを確認しておくと、あとになって想定外の調整に追われる場面を減らせます。この定義が示しているのは、値の扱いを個々の担当者任せにしないという発想です。誰が公開しても、誰が連携しても、想定したとおりに使われる状態を保つことが、値のガバナンスと呼べる部分に当たります。案件に入る前にこの視点を持てているかどうかで、レビューで指摘される内容も変わってきます。

この「想定したとおりに使えるか」を分解すると、品質は1つではなく3つの面に分かれます。

2. 品質は3つの面に分かれています

「使える」を分解すると、3つの基準が出てきます

「想定したとおりに使える」という言葉は、意識してみると幅があります。どこを直せば安心なのか、最初は掴みにくいところです。資料は、標準化されたデータモデルを活用して設計することで、形式的な品質、モデルとしての品質、意味的な品質の3つがそれぞれ向上すると整理しています⁴。3つは別の軸なので、混ぜて捉えると対策も的外れになります。この3つの区分を知らないまま設計を始めると、レビューで「ここは直せない」と言われて初めて気づく場面が出てきます。あらかじめ3つの軸で自分の担当範囲を確認しておくと、レビューの指摘にも落ち着いて対応できます。特に意味的な品質は、技術的な検証だけでは判断できないため、業務側との対話が欠かせません。

型やコード値をそろえることよりも、データ同士の関係を正しく結ぶことのほうが、あとから直しにくい場面もあります。3つの品質は、それぞれ効いてくる場面が異なります。

3つの品質と、効いてくる場面

形式的な品質は値そのものの決め方に関わり、設計の初期段階で固めておくほど、あとの連携がなめらかになります。モデルとしての品質は、データ同士の関係を扱う段階で効いてきます。意味的な品質については、資料は名称を示すにとどまっているため、本記事ではこの先、値の設計に直接関わる形式的な品質を中心に扱います。表1は、3つの品質と、効いてくる場面をまとめたものです。テーブルを俯瞰すると、公開前と公開後のどちらで手を打つべきかも見えてきます。

品質の種類	内容	主に効いてくる場面
形式的な品質	型・桁・区分値・コード値・住所や氏名の持ち方など、値そのものの決め方5	項目を設計する初期の段階
モデルとしての品質	データ同士の論理構造や依存関係が整合していること7	テーブルや項目同士の関係を組む段階
意味的な品質	値の意味が、連携先の受け止め方とずれていないこと	仕様のすり合わせや連携先との協議の段階

表1を見ると、形式的な品質とモデルとしての品質は、どちらも設計の早い段階に集中しています。公開してからこの2つに手を入れようとすると、値を使っている連携先すべてに影響が及ぶため、着手前の設計段階でどこまで詰められているかが、案件の難易度を左右します。

3. 動かしにくいのは形式の側です

型・区分値・住所の持ち方は、あとから動かしにくい領域です

形式的な品質の中身を具体的に見ると、型、桁、区分値、コード値、住所や氏名の持ち方、カナやIDの保持、データの必須項目が挙げられています⁵。どれも見た目は小さな決め事に見えますが、公開したAPIをすでに使っている連携先がある状態で変えようとすると、影響範囲が思いのほか広がります。

図2は、形式的な品質に含まれる項目をまとめたものです。ここに挙がっている項目ほど、公開前に検討しておくことで、あとの調整が軽く済みます。

出典：デジタル庁「政府相互運用性フレームワーク（GIF）説明資料」（2025年3月）をもとに作成⁵

型や桁のように機械的に検証できる項目よりも、区分値や住所の持ち方のように「どう分けるか」を人が決める項目のほうが、あとから直しにくい傾向があります。前者はテストで早期に検出できますが、後者は連携先が実際にその値を使い始めてから、想定とのずれが表面化します。この違いを踏まえると、公開前のレビューで見るべき観点も変わります。型や桁の検証は自動化しやすい一方、区分値や住所の持ち方が業務の実態に合っているかどうかは、連携先の担当者と直接すり合わせないと見えてこない部分です。GIFがこれらを形式的な品質としてまとめて示しているのは、値の扱いを場当たり的にしないためのガバナンスの土台と考えると分かりやすいところです。

図2に並んだ項目は、どれもAPIの1つのフィールドに対応します。フィールド定義書を作る段階でこの7つを意識しておくと、あとから「この項目はどちらの意味だったか」という問い合わせを減らせます。この領域を公開前に詰めた経験は、案件を選ぶときの材料になります。

4. 同じ住所でも、持ち方で別の設計になります

一続きの文字列か、項目に分けるかで、後工程が変わります

住所の持ち方は、形式的な品質の中でも具体的にイメージしやすい例です。資料では、東京都千代田区永田町から始まる一続きの住所文字列と、都道府県・市区町村・町字・番地に分けて保持する形が、並べて示されています⁶。

一続きの文字列のほうが入力の手間は小さく見えても、あとから地域ごとに絞り込む処理を足すとなると、分けて保持する形のほうが扱いやすい場面が出てきます。どちらにするかは、公開後に増える利用のされ方を見越して決める判断です。

住所の持ち方2パターンと、後工程への影響

2つの持ち方は、どちらが正解というものではなく、後工程で何をしたいかによって向き不向きが変わります。表2は、資料に示された2つの例と、それぞれで後工程がどう変わるかを整理したものです。設計の早い段階でこの違いを確認しておくと、公開後に持ち方そのものを組み替える手戻りを避けやすくなります。

持ち方	例	後工程での扱い
一続きの文字列	東京都千代田区永田町のように、1つの項目にまとめて保持する形6	表示にはそのまま使えるが、地域だけを取り出す処理は別に組む必要がある
項目に分けて保持する形	都道府県・市区町村・町字・番地を、それぞれ別の項目に分けて保持する形6	地域ごとの集計や絞り込みがしやすくなるが、表示のたびに項目を組み立てる処理が要る

表2からも分かるとおり、どちらの持ち方にも得意な場面と、手間が増える場面があります。公開前に「この住所データを、将来どんな条件で絞り込みたいか」を関係者と協議しておくことが、あとから持ち方を組み替える事態を避ける近道です。設計時点では地域による絞り込みが不要でも、事業が広がれば必要になる場面は出てきます。最初から分けて保持する形を選んでおくことが、常に正解というわけではありませんが、あとから分割する変更よりは影響範囲を抑えやすいという傾向はあります。この判断に正解はありませんが、少なくとも「あとで両方の形に対応できるようにしておく」という先送りは、システムの複雑さを増やすだけになりがちです。

住所という1つの値の中でも設計が分かれるように、複数の値の間の関係にも、品質を左右する決め方があります。

5. 関係の定義も品質の一部です

会社情報と部署情報のように、データ同士にも関係の設計があります

モデルとしての品質は、データ間の論理構造や依存性が整合されて保持されることです。資料は具体例として、会社情報と部署情報の関係をモデル化することを挙げています⁷。

項目それぞれの型や桁を整えるだけでは、この関係までは保証されません。会社情報と部署情報のように、どちらがどちらに属するのかを先に定義しておくことのほうが、あとの連携では効いてきます。

出典：デジタル庁「政府相互運用性フレームワーク（GIF）説明資料」（2025年3月）をもとに作成⁷

会社情報と部署情報の例は単純に見えますが、実際の案件では項目数がもっと多く、依存関係も複雑になりがちです。どちらが親でどちらが子かを先に決めておかないと、あとから追加するデータをどこに紐づけるかで判断が割れる場面が出てきます。この判断は、一度決めてしまうと後から覆しにくいという点で、住所の持ち方と同じ性質を持っています。設計の初期段階でデータ同士の主従関係を洗い出しておく作業は、地味に見えても、公開後の手戻りを大きく左右します。

システム間の連携の形にも段階があります。連携するシステムごとに取決めとデータ変換を重ねる形もあれば、ハブとなるシステムの規約に合わせて変換する形もあります。GIFが目指す姿は、これらの変換を重ねる形ではなく、参照可能な定義に紐づけられたデータです⁸。参照可能な定義に紐づけるという考え方は、変換の手間を減らすだけでなく、値の意味を後から確認しやすくするという効果も持っています。

関係の定義を先に固めておくことは、変換をどこまで肩代わりするかという設計判断そのものです。

6. ひな形には拡張の余地があります

GIFは固定の規格ではなく、ひな形として置かれています

GIFは、政府情報システムが保有するデータの相互運用性を確保するためのデータモデルやルールをひな形としてまとめたものです¹。デジタル社会推進標準ガイドラインの中では実践ガイドブックという位置づけにあり²、案件ごとの事情に合わせて手を加える余地が残されています。拡張の仕組みも用意されています。GIFはGIFルールとGIFデータ項目に対して、拡張ルールと拡張データ項目を加える形で広げられるものとして示されています⁹。固定の規格ではなくひな形として置かれているからこそ、拡張のルールを誰がどう決めるかという、値のガバナンスの設計が必要になります。

ひな形と拡張の対応

基本の型に何を足せるのかが分かれていると、独自の項目を加える判断がしやすくなります。表3は、ルールとデータ項目それぞれについて、基本の型と拡張の型を並べたものです。資料の終わりには、GIFは成長し続けるという記述も置かれており、ひな形自体が今後も更新される前提であることが読み取れます¹⁰。表3を読むときは、基本の型を崩さずに拡張がどこまで届くかという視点で見ると理解しやすくなります。

要素	基本の型	拡張の型
ルール	GIFルール	拡張ルールを加える形9
データ項目	GIFデータ項目	拡張データ項目を加える形9
資料全体の位置づけ	現時点でまとまっている内容	成長し続けるものとして、今後も更新される内容10

出典：デジタル庁「政府相互運用性フレームワーク（GIF）説明資料」（2025年3月）をもとに作成⁹

拡張データ項目をどこまで足すかは、ひな形をそのまま使う場合よりも判断の幅が大きくなります。案件ごとの独自要件をすべて拡張で吸収しようとすると、ひな形を使う意味が薄れてしまうため、何を拡張し、何をひな形のままにするかを見極める視点が必要になります。拡張ルールをどこまで自由に足せるようにするかも、値のガバナンスの一部です。案件ごとに拡張の判断がばらつくと、ひな形を取り入れた意味が薄れてしまうため、拡張の可否を誰がどう判断するかを、案件の早い段階で決めておく必要があります。

ひな形を土台にしつつ、案件ごとの拡張をどこまで足すかを見極める仕事は、公開後の調整を減らす側の仕事でもあります。

7. よくある質問

この記事でいう「値のガバナンス」とは、具体的に何を指しますか

システムをまたいで使われる値が、公開後も想定したとおりに使われ続けるように、形式的な品質・モデルとしての品質・意味的な品質という3つを保つことを指しています⁴。区分値やコード値、住所や氏名の持ち方といった形式的な品質⁵や、会社情報と部署情報のような関係の定義⁷を、公開前にどこまで固めておくかが、値のガバナンスの中身です。この3つを個別に管理するのではなく、公開前の設計段階でまとめて確認する体制こそが、値のガバナンスの実践的な形です。

APIを公開する案件では、どの工程から関わることが多いですか

案件によって異なりますが、区分値や住所の持ち方のような形式的な品質⁵や、会社情報と部署情報のような関係の定義⁷は、設計の初期段階で固まっていることが望ましい部分です。公開後の調整を減らしたい場合は、この段階から関わる案件を選ぶ視点が有効です。

区分値やコード値の設計は、あとからどのくらい直しにくいものですか

資料は、区分値やコード値を形式的な品質の具体例として挙げています⁵。連携先がすでにその値を前提に処理を組んでいる状態で変更すると、影響は自分たちのシステムだけにとどまりません。件数や期間についての具体的な数値は資料に示されていないため、ここでは踏み込みません。とはいえ、連携先が増えるほど調整の難易度が上がる方向にあることは、図1の流れからも読み取れます。

GIFに沿っていれば、独自の項目は追加できませんか

追加は想定されています。GIFはGIFルールとGIFデータ項目に対して、拡張ルールと拡張データ項目を加える形で広げられるものとして示されています⁹。ひな形という位置づけなので¹、案件の要件に合わせて拡張データ項目を足す判断は妨げられません。ただし、何を拡張データ項目として足すかは案件ごとの判断であり、ひな形が自動的に決めてくれるわけではありません。

こうしたAPI関連の案件は、リモートで進めやすいですか

Remoguで扱う案件の90%以上がフルリモート可能です¹¹。データモデルの設計や仕様の整理は、資料と実装を突き合わせる作業が中心になりやすく、リモートでの協議とも相性が良い領域です。ただし条件は案件によって異なります。

この領域に関わるには、どんな経験が生きますか

データベース設計や、既存システムとの連携を担当した経験は生きやすい領域です⁷。特に、会社情報と部署情報のような関係を整理した経験や、住所のような値の持ち方を設計し直した経験は、GIFが示す形式的な品質やモデルとしての品質の話と重なります⁵。これまでに関わった案件の中から、値の持ち方や関係の定義で悩んだ場面を1つ思い出してみると、次に選ぶ案件の基準が具体的になります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「政府相互運用性フレームワーク」説明資料（2025年3月）
＊2 デジタル庁「政府相互運用性フレームワーク」説明資料（2025年3月）
＊3 デジタル庁「政府相互運用性フレームワーク」説明資料の用語集（2025年3月）
＊4 デジタル庁「政府相互運用性フレームワーク」説明資料（2025年3月）
＊5 デジタル庁「政府相互運用性フレームワーク」説明資料（2025年3月）
＊6 デジタル庁「政府相互運用性フレームワーク」説明資料（2025年3月）
＊7 デジタル庁「政府相互運用性フレームワーク」説明資料（2025年3月）
＊8 デジタル庁「政府相互運用性フレームワーク」説明資料（2025年3月）
＊9 デジタル庁「政府相互運用性フレームワーク」説明資料（2025年3月）
＊10 デジタル庁「政府相互運用性フレームワーク」説明資料（2025年3月）
＊11 Remoguサイト公開情報（案件の90%以上がフルリモート可能）