外部にデータを渡す機能を設計するとき、多くの時間は「渡してよいか」を判定する一点に使われます。総務省郵政行政部がまとめた検討資料を読むと、判断はその一点で終わっていないことが分かります。渡した後にどう管理し、どう扱っているかも、プライバシー侵害かどうかを判断する材料に含まれているためです²。渡す前の判定だけでなく、渡した後まで続く設計の組み立て方を、この記事で整理します。

1. 渡してよいかは天秤で決まる

比較衡量という物差しの中身

外部提供の機能に着手すると、最初に欲しくなるのは「これは渡してよい」「これは渡してはいけない」という明確な線です。仕様書に書けるくらいはっきりした基準を探して、資料を読み進めることになります。判定用のテーブルや条件分岐をあらかじめ思い描き、そこに当てはめれば設計が完成すると考えるのは自然な流れです。

総務省郵政行政部の検討資料が示すのは、単純な線引きではなく比較の構造です。比較衡量の結果、それらの情報を用いることによる利益が秘密を守られる利益を上回ると認められる場合に、第三者提供が可能となると考えられる事例が示されています¹。可否は固定された基準ではなく、天秤にかけて決まるものとして扱われています。片方の利益だけを見て可否を決める設計は、この構造と噛み合いません。

設計に落とすときの問いも変わります。「渡してよいか」ではなく、「何と何を比べ、どちらの利益が上回っていると判断したか」を、機能の中に残せるかという問いです。判断の根拠を後から追えるかどうかが、この先で扱う渡した後の管理につながっていきます。承認画面の裏側に、比較した内容そのものを残せる作りになっているかどうかが、後になって効いてきます。

出典：郵便分野ガイドライン解説に追記する事例の検討について（郵政行政部・2025年1月）をもとに作成

限られた例外の類型

例外的に渡してよい場面が一覧になっていれば、その一覧に沿って機能を作ればよいと考えたくなります。判定ロジックをいくつかの条件分岐に置き換えるだけで済むように見えるためです。

検討資料が挙げる事例は、緊急時に被災者や負傷者の情報を地方公共団体等に提供する場合のように、類型として限定されています⁹。列挙されているのは特定の場面ではなく、比較衡量が利益の側に大きく傾きやすい類型そのものです。一覧をそのまま機能の条件式へ写し取るための材料ではありません。

例外が存在することよりも、例外が限定されている事実のほうが設計には効きます。例外に該当しない大半のやり取りでは、比較衡量の構造を機能の中に残すことが出発点になります。例外の扱いに時間をかけるより、通常時の判定を厚くするほうが、機能全体の一貫性を保ちやすくなります。

API連携のように自動でデータが流れる仕組みでは、例外の類型を分岐条件として持たせたくなる場面が出てきます。その場合も、分岐の先に人が確認する余地を残すか、比較衡量の記録を自動で残す仕組みにするかを、あらかじめ決めておく必要があります。

2. 判断は渡った後も続く

「渡す前」で終わらない理由

可否の判定ロジックを書き終えると、外部提供の機能は完成したように見えます。判定が通った時点で、設計の役目は終わったと感じても不思議ではありません。テストの対象も、判定の分岐が正しく動くかどうかに集中しがちです。

けれども検討資料には、事後的にどう管理しているのか、どう扱っているのかも、裁判においてプライバシー侵害かどうかの判断基準になっているという意見が記録されています²。渡した瞬間の判断が妥当であっても、渡した後の扱いが評価に影響するということです。検証の対象は、判定ロジックだけでなく、渡した後の状態にまで広がることになります。

設計の対象は、渡した後に続く運用の状態まで広がります。承認が通った後の画面や処理も、設計の対象として扱う必要が出てきます。ここから先は、何を機能として残すかという話になります。

機能の完成度を、判定の正しさだけで測る癖は、実装が進むほど強くなります。渡した後の状態まで含めて設計が終わるという前提を、早い段階でチームの共通認識にしておくと、後からの手戻りが小さくなります。

渡した後に見られる点

「渡した後」と言われても、具体的に何を見られているのかが分からなければ、機能には落とせません。管理という言葉だけでは、実装のイメージが結びにくいところです。

検討資料は、提供をした後や、提供するときの各関係者のデータの取扱いやデータフローのようなものと、その検証の仕方も解説に加えてほしいという意見を記録しています⁵。見られているのは、扱い方の記録と、それを検証できる形になっているかどうかです。記録が残っていても、後から追えない形式では検証の役に立ちません。

判定の記録を残すことよりも、渡した後のアクセスや消去の記録を残すことのほうが、この判断基準には直接効きます。運用の記録を後から足す組み立て方では、抜けが生まれやすくなります。抜けを防ぐ鍵は、管理をガイドラインの文章としてでなく、機能の一部として持つことにあります。

アクセスの記録や消去の実行を、担当者が手作業で残す前提にすると、繁忙期には抜けやすくなります。仕組みの側で自動的に記録が残る形にしておけば、担当者の忙しさに左右されずに済みます。設計の初期段階でこの前提を共有しておくと、後から仕様を追加するより小さな変更で済みます。

段階	問われること	設計に残すもの
渡す前	比較衡量で利益が上回っているかの判定1	判定の根拠を記録する仕組み
渡す瞬間	提供する範囲が目的に対して絞られているか	提供項目を絞り込む仕組み
渡した後	どう管理し、どう扱っているか2	アクセス制御と保持期間の管理
渡した後（継続）	データフローと検証の仕方5	取扱いを追跡できるログ

3. だから事後の管理を組み込む

ガイドラインでなく設計に組み込む

運用のルールを、担当者向けの手順書だけに書いて終わらせたくなる場面があります。手順書は読まれないことがあり、読まれても実行が担当者の注意力に委ねられます。担当が変わるたびに、同じ説明を繰り返すことにもなります。

検討資料は、事後的な管理のところもビルトインした形のガイドラインにしておくことを強く勧める、という意見を記録しています³。手順として書くだけでなく、機能の中に組み込む形が望ましいという立場です。手順書と機能を並べたとき、抜けが出にくいのは機能の側です。

機能に組み込むとは、アクセス権限や保持期間、消去の実行を、担当者の判断ではなく仕組みの側で動かす状態を指します。この組み込み先は、照会書の確認欄という具体的な形ですでに示されています。担当者の記憶に頼らず、確認欄の言葉をそのまま機能要件として読み替えることができます。

図の作成：Remogu編集部。事後的な管理のところもビルトインした形にしておくことを強く勧めるという資料の意見³を図に整理したもので、統計データではありません

照会書の確認欄がそのまま設計項目になる

抽象的に「組み込む」と言われても、何を機能の要件に落とせばよいのか分からなければ、実装には進めません。手がかりになるのは、既存の書式の中にすでにある言葉です。

照会書の確認欄には、提供された情報を、本人の同意を得ることなく目的外利用や第三者提供しないこと、提供された情報を適切に管理すること、提供された情報を利用後適切に消去することが並んでいます⁷。書式の確認欄が、そのまま設計のチェックリストとして読めます。担当者が目視で確かめる欄を、そのまま機能の要件一覧として扱えます。

この3行は、権限管理・保存管理・消去処理という3つの機能要件に、ほぼそのまま置き換えられます。書式の言葉を機能名に置き換えるだけなので、要件定義の会議で合意を取りやすい形でもあります。確認欄の言葉と機能をひとつずつ結ぶと、次の表のようになります。

確認欄の項目	機能として置き換えるもの
目的外利用や第三者提供をしないこと7	利用目的を固定し、別目的での参照を権限で止める仕組み
適切に管理すること7	アクセス権限の分離と保管場所の限定
利用後に適切に消去すること7	保持期間を過ぎたデータを消去する処理

4. 責任は渡す側と受け手の双方にある

片側だけでは決まらない

設計を担当していると、責任の線引きも自分の実装の範囲に閉じて考えたくなります。渡す側の機能さえ正しく作れば、あとは受け取った側の話だと考えることもできます。担当領域の外側は見なくてよいという発想です。

検討資料は、ガバナンスの在り方は、データを提供する側と受け手の双方にあるとしています⁴。渡す側の設計だけで完結する話ではなく、受け手側の扱いも含めて、両方が担う構造です。渡す側の実装だけを厚くしても、受け手側の扱いが伴わなければ、判断の材料はそろいません。

片側の実装を作り込むことよりも、両方の役割がどこで接続するかを先に決めることのほうが、後戻りの少ない設計につながります。役割の境目があいまいなまま実装を進めると、後から責任の所在を追い直す作業が発生します。

接続点を先に決めるとは、渡す側が何を保証し、受け手側が何を引き継ぐかを、機能の仕様として文章に残すことです。仕様に残っていれば、担当者が変わっても同じ前提で運用を続けられます。口頭の申し送りに頼るより、仕様書という残る形にしておくほうが確認の手間も減ります。

経路と検証まで書く

役割を決めても、実際にどう動いたかを追えなければ、後から確認のしようがありません。口頭の申し合わせだけでは、時間が経つほど根拠が薄れていきます。

検討資料には、提供をした後や、提供するときの各関係者のデータの取扱いやデータフローのようなものと、その検証の仕方も、この解説の中に加えてほしいという意見が記録されています⁵。経路と検証の仕方まで、解説に含める対象として挙がっています。個々の担当者の記憶ではなく、記録として残る形が前提になっています。

設計としては、渡す側の記録と受け手側の記録をつなげて追えるかどうかが要点になります。つながっていなければ、検証は言葉のうえだけで終わります。それぞれのログをひとつの経路として結びつけられるかどうかが、検証の実効性を分けます。

渡す側だけのログを厚くするより、受け手側との突き合わせができる最小限の共通項目を先に決めることのほうが、検証の仕組み全体を軽くできます。共通項目が決まれば、双方のシステムが別々でも経路として追うことができます。

主体	担う役割	確認すること
提供する側	渡す範囲と条件の設定	目的の達成に必要な最小限の範囲か8
受け手	受け取った後の管理と消去7	確認欄に沿った運用が続いているか
双方	データフローの記録と検証5	提供時・提供後の取扱いを追跡できるか

5. 条件に「管理する意思表示」が加わった

条件が変わった中身

渡す相手の条件は、いったん決めれば動かないものだと考えてしまうことがあります。契約や運用の初期に固定して、その後は見直さない前提で設計することもあります。

検討資料が扱う改正案では、情報提供の対象となる地方公共団体を、情報を適切に管理する旨を表示して照会を行う者に限る旨が、ガイドライン解説に規定されます⁶。渡す相手の条件に、管理の意思表示という項目が加わりました。渡す相手が誰であるかだけでなく、どう管理すると表明しているかまでが確認の対象になります。

これまでの設計が「渡してよい相手かどうか」だけを見ていたなら、これからは「管理する意思を表示しているかどうか」も確認先に加わります。渡す相手を選ぶ基準そのものが、一段階増えたと捉えたほうが実態に近くなります。

相手の属性だけを確認していた設計に、意思表示という項目を後から差し込むと、確認の順序や画面の構成に無理が出やすくなります。条件が増える方向を先に見込んでおくと、あとから項目を足すときの負担が小さくなります。

確認する項目が増えるたびに画面を作り替える設計より、確認項目を一覧として持ち、そこに追加していく設計のほうが、この先の条件変更にも耐えやすくなります。

出典：郵便分野ガイドライン解説に追記する事例の検討について（郵政行政部・2025年1月）をもとに作成

設計にどう跳ね返るか

条件が増えると聞くと、確認画面をひとつ足すだけで済ませたくなります。表示の有無をチェックボックスで管理すれば十分だと考えることもできます。

画面に表示欄を足すことよりも、その表示を照会の記録として残し、後から参照できる形にしておくことのほうが、事後の管理という本題に沿います。表示させるだけでは、渡した後の検証には使えません。

渡す相手の条件を確認する処理に、意思表示の記録という一項目を加えることが、この章の設計要件になります。表示させて終わりにせず、後から参照できる記録として持たせることが、事後の管理という本題とつながります。

6. まとめ：最小限の範囲と消去まで

最小限の範囲を起点にする

設計の議論は、渡してよいかという入り口に時間を使いがちで、範囲を絞る作業は後回しになりやすい部分です。項目をひとつ減らす判断は、地味な作業に見えてしまいます。

検討資料は、これらの場合に提供できる個人データは、その目的の達成に必要な最小限の範囲のものでなくてはならないとしています⁸。範囲を絞ることは、比較衡量の判定や事後の管理と並ぶ、独立した設計項目です。

比較衡量で可否を判定し、範囲を最小限に絞り、事後の管理を組み込み、データフローを検証する。この記事で見てきた4つの視点は、渡す前の一点ではなく、渡した後まで続く一続きの設計として並びます。どれか一つを厚くしても、他が抜けていれば全体としての判断基準は満たせません。

渡した後まで見える設計者になる

この種の設計判断を任される場面は、実装だけを担当する立場ではなかなか回ってきません。範囲や条件の議論に加われるかどうかは、案件での裁量に左右されます。実装だけを任される立場だと、範囲や条件そのものの議論に触れる機会が少なくなりがちです。指示された仕様をそのまま形にする役回りが続くと、比較や検証の考え方を実務で試す機会そのものが遠くなります。

Remoguが扱う案件は、90%以上がフルリモート可能です¹⁰。場所に縛られずに関われる案件の中には、外部提供のような設計判断そのものに関わる仕事も含まれています。判定ロジックだけでなく、運用や検証の設計まで任されるかどうかは、案件ごとの裁量の大きさによって変わってきます。

渡した後まで見える設計に関わりたいと感じたら、まずは自分の経験に近い案件の条件を確かめるところから始められます。

7. よくある質問

図の作成：Remogu編集部。この記事で扱った4つの視点の関係を整理したもので、統計データではありません

比較衡量の判定はエンジニア側でロジック化できますか

比較衡量は、情報を用いることによる利益と秘密を守られる利益を比べる考え方として資料に示されています¹。承認フローの中に、どちらの利益をどう見積もったかを記録する項目を設けることは、実装として組み込みやすい部分です。判断そのものをどこまで仕組みだけで完結させるかは、渡す情報の性質によって変わります。迷う案件ほど、比較の根拠を後から見返せる形にしておく価値が大きくなります。

渡した後の管理まで、どこまで設計に含めればよいですか

検討資料の照会書の確認欄には、目的外利用や第三者提供をしないこと、適切に管理すること、利用後に適切に消去することが並んでいます⁷。この3点は、権限管理・保管管理・消去処理という3つの機能に対応させやすい範囲です。加えて、提供できる個人データは目的の達成に必要な最小限の範囲でなくてはならない点も⁸、範囲を絞る機能として設計に含められます。項目ごとにどの機能が対応するかを一度整理しておくと、確認欄が増えたときにも同じ型で追加していけます。

改正案が確定する前から、条件の表示を設計に取り入れる意味はありますか

改正案は、情報を適切に管理する旨を表示して照会を行う者に限る旨をガイドライン解説に規定する方向を示しています⁶。この方向に沿って、意思表示を記録できる形をあらかじめ用意しておくことは、条件が変わった後の手戻りを小さくする準備になります。確認の項目を後から差し込む設計より、最初から一項目として持たせておく設計のほうが、変更のたびに手を入れる範囲が狭くて済みます。

渡した後まで見える設計に関わる機会は、案件によって任される範囲が変わります。判定の裏側や運用の記録まで踏み込んで考える経験は、実装の仕様だけを受け取る立場では積み上がりにくいものです。自分の経験がどの案件で活きるかは、登録して条件を確かめるところから見えてきます。

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

出典・参考情報

＊1 郵政行政部「郵便分野ガイドライン解説に追記する事例の検討について」資料7-1（2025年1月）
＊2 郵政行政部「郵便分野ガイドライン解説に追記する事例の検討について」資料7-1（2025年1月）
＊3 郵政行政部「郵便分野ガイドライン解説に追記する事例の検討について」資料7-1（2025年1月）
＊4 郵政行政部「郵便分野ガイドライン解説に追記する事例の検討について」資料7-1（2025年1月）
＊5 郵政行政部「郵便分野ガイドライン解説に追記する事例の検討について」資料7-1（2025年1月）
＊6 郵政行政部「郵便分野ガイドライン解説に追記する事例の検討について」資料7-1（2025年1月）
＊7 郵政行政部「郵便分野ガイドライン解説に追記する事例の検討について」資料7-1（2025年1月）
＊8 郵政行政部「郵便分野ガイドライン解説に追記する事例の検討について」資料7-1（2025年1月）
＊9 郵政行政部「郵便分野ガイドライン解説に追記する事例の検討について」資料7-1（2025年1月）
＊10 Remoguサイト公開情報（フルリモート可能案件の割合）