「匿名加工情報として扱えるシステムにしてほしい」「仮名加工情報の要件を満たすように設計してほしい」——法務や経営から下りてきた要件を、どうシステムに落とし込めばよいか迷っていませんか。個人情報保護委員会のガイドラインを読んでも、法的な要件（識別子の削除・再識別の禁止など）は書かれていても、システム設計として具体的にどの技術手法を使えばよいかまでは書かれていません。
さらに難しいのは、複数のベンダーから見積を取ったときに、提案の内容がまちまちなことです。ある社は「マスキング処理を実装します」、別の社は「k-匿名化を採用します」、もう一社は「トークナイゼーション基盤を導入します」。どの提案が自社のケースに適しているのか、判断する軸が持てないまま比較検討が進まない、というのが発注担当者に共通する悩みです。
この難しさの正体は、「匿名化」「仮名化」という言葉が、法律用語と技術用語の 2 層構造になっていることにあります。法律側の言葉（匿名加工情報・仮名加工情報）と、技術側の言葉（k-匿名化・マスキング・トークナイゼーションなど）は 1 対 1 に対応せず、法要件を満たすためにどの技術手法をどう組み合わせるかは、対象データや活用目的によって変わります。
本記事では、この 2 層構造を最初に整理したうえで、代表的な 6 つの技術手法（k-匿名化・一般化・トップコーディング・マスキング・トークナイゼーション・ハッシュ化）を「発注者が RFP に書ける粒度」で比較し、ケース別の選定マトリクス、RFP に含めるべき 5 つの実装要件、ベンダー提案を評価するチェック観点まで通しで解説します。
読み終える頃には、ベンダー提案書に対して「なぜその手法を選んだのか」「マッピングテーブルはどう管理するのか」「監査設計はどうするのか」と具体的に質問できる状態を目指します。RFP・要件定義書のたたき台がなかなか書けずに止まっている方は、順に読み進めてください。
【サンプル】システム開発 提案依頼書（RFP）
この資料でわかること
システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。
こんな方におすすめです
- 初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
- 実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
- 開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方
入力いただいたメールアドレスにPDFをお送りします。
データ匿名化・仮名化とは（法的定義と技術用途の整理）
まず最初に整理しておきたいのが、「匿名化」「仮名化」という言葉が指すレイヤーの違いです。同じ言葉でも、法律の文脈と技術の文脈で意味の粒度が異なります。ここを分けて考えないと、後のセクションで扱う技術手法の選定がすべて曖昧になってしまいます。
匿名化と仮名化 — 法律用語と技術用語の 2 層構造
日本語で「匿名化」「仮名化」と言った場合、次の 2 つのレイヤーが混在しています。
- 法律用語としての意味: 個人情報保護法における「匿名加工情報」「仮名加工情報」を指す。加工の目的・満たすべき要件・扱いのルールが法令で定められている
- 技術用語としての意味: マスキング、k-匿名化、トークナイゼーション、ハッシュ化などの具体的な加工技術を指す。処理の中身と実装難易度が技術ごとに異なる
法律側は「何を達成すべきか（What）」、技術側は「どう達成するか（How）」を扱います。両者は 1 対 1 に対応するわけではなく、たとえば「匿名加工情報として扱えるレベルの加工」を実現するために、k-匿名化と一般化を組み合わせる、といった設計判断が発生します。
発注担当者がベンダー提案を読むときに混乱しやすいのは、この「法律側の要件」と「技術側の実装」を横並びで語ってしまっているからです。以降のセクションでは、まず法律側の位置付けを短く確認したうえで、技術側の手法比較に軸足を移していきます。
個人情報保護法上の匿名加工情報・仮名加工情報の位置付け
法律側の位置付けを最短で押さえるなら、次の 2 点です。
- 匿名加工情報: 特定の個人を識別できず、かつ元の個人情報を復元できないように加工した情報。本人同意なしで第三者提供が可能になる代わりに、加工基準・安全管理措置・公表義務など複数の要件を満たす必要があります（個人情報保護委員会「匿名加工情報」）
- 仮名加工情報: 他の情報と照合しない限り特定の個人を識別できないように加工した情報。原則として社内での分析利用に限られますが、漏えい時の本人通知義務や利用停止請求への対応義務が緩和されます（個人情報保護委員会「個人情報保護法ガイドライン（仮名加工情報・匿名加工情報編）」）
大枠のイメージは「第三者提供までしたい → 匿名加工情報」「社内分析までで十分 → 仮名加工情報」です。いずれもガイドラインで加工基準（識別子の削除・特異値の処理・一般化など）が示されていますが、「どのカラムをどう加工すればガイドラインを満たすのか」の技術判断はシステム側で設計する必要があります。
法対応そのものの全体像や、契約・体制面の要件については、個人情報保護法対応のシステム開発およびプライバシー法対応のシステム開発で扱っています。契約・組織的措置まで含めた俯瞰が必要な方は、そちらも併読してください。
本記事のスコープ（技術手法の選定と実装要件）
本記事は、法要件そのものの解説ではなく、「法要件を満たすためにシステム側でどの技術手法を選び、どう実装要件に落とすか」に絞って解説します。具体的には次の 4 点をカバーします。
- 匿名化と仮名化の技術的な違い（可逆性・活用範囲・判断フロー）
- 代表的な 6 つの技術手法の比較と使い分け
- 発注ケース別の技術手法選定マトリクス
- RFP・要件定義書に書くべき実装要件と、ベンダー提案の評価チェック観点
対象読者は、社内法務や個人情報保護委員会ガイドラインから「匿名加工情報として扱えるようにしてほしい」「仮名加工情報の要件を満たしてほしい」という要件を渡されたあと、RFP に落とし込む段階の発注担当者を想定しています。
匿名化と仮名化の技術的違い（可逆性・活用範囲・法的扱い）
法律側の位置付けを押さえたら、次に「自社ケースは匿名化と仮名化のどちらで進めるべきか」を判断できるようにします。ここでの判断が、後の技術手法選定を大きく規定します。
復元可能性で変わる法的扱い
技術的な最大の違いは、元データへの復元可能性を残すかどうかです。
- 仮名化（Pseudonymization）: 元データとの対応関係を管理するマッピングテーブルや鍵を別途保管しておき、必要に応じて復元できるようにする加工。分析中は個人が識別できない状態にしつつ、後から個人単位で追跡する必要があるユースケースに向く
- 匿名化（Anonymization）: 元データへの復元可能性そのものを排除する加工。一度加工したら、原則として元の個人には戻せない
この違いが、法的な扱いに直結します。仮名加工情報は「他の情報と照合しない限り識別できない」という状態を作ることで、社内での分析利用や漏えい時の対応義務緩和というメリットを得ます。匿名加工情報は「復元不可能」という一段高いハードルを課すことで、本人同意なしでの第三者提供という一段強い自由度を得ます。
「復元可能性を残すか排除するか」は、システム設計上の分岐点にもなります。復元可能性を残すなら、マッピングテーブルや鍵の物理分離・アクセス統制・鍵ローテーション設計が必要です。復元可能性を排除するなら、ハッシュ化やトップコーディングなど不可逆な処理が中心になり、統計指標での再識別リスク評価が必要になります。
第三者提供の有無で選ぶ判断フロー
「自社ケースはどちらか」を判断する際は、次のフローで整理すると迷いにくくなります。
- 加工後データを社外（第三者・委託先・グループ会社の別法人など）に提供するか？
- Yes → 匿名加工情報として設計する必要性が高い
- No → 仮名加工情報での対応が現実的
- 加工後データを本来の利用目的の範囲を超えて利活用したいか？（例: 元は顧客管理目的だったデータを新規事業のマーケ分析に転用したい）
- Yes → 仮名加工情報化により、利用目的変更の制約が緩和される
- No → 既存の個人情報のまま安全管理措置で対応する選択肢もある
- 後から個人単位での追跡や再突合が必要になる可能性があるか？（例: 個別顧客からの停止請求への対応、分析結果を個別顧客の施策に反映）
- Yes → マッピングテーブルを持つ仮名化・トークナイゼーション型が向く
- No → 復元不能な匿名化を選びやすい
このフローに沿って自社ケースを分類すれば、ベンダー提案が「なぜ匿名加工情報を選んだのか」「なぜ仮名加工情報で十分と判断したのか」の根拠を確認できるようになります。
「氏名を削除しただけ」では匿名化にならない理由
発注ケースで最も誤解が多いのが、「氏名や電話番号を消せば匿名化になる」という理解です。これは技術的にも法的にも十分ではありません。
理由は、準識別子（Quasi-Identifier）の存在です。準識別子とは、単体では個人を特定できないものの、複数を組み合わせると個人が特定できてしまう属性群を指します。代表例は「郵便番号・生年月日・性別」の 3 点で、この組み合わせだけでかなりの割合の個人が一意に識別できることが古くから知られています。
つまり氏名を削除しても、準識別子の組み合わせによって元の個人が推定できてしまえば、「特定の個人を識別できない」状態には至らず、匿名加工情報の要件を満たしません。だからこそ、後述する k-匿名化や一般化のような、準識別子の粒度そのものを粗くする技術手法が必要になります。
ベンダー提案書に「氏名・電話番号をマスクします」だけしか書かれていない場合、この準識別子の観点が抜け落ちている可能性が高いので、次の質問で掘り下げると良いでしょう。「準識別子（郵便番号・生年月日・性別など）はどう扱いますか？」「再識別リスクの評価はどう行いますか？」。
代表的な技術手法6種の比較（k-匿名化・一般化・トップコーディング・マスキング・トークナイゼーション・ハッシュ化）
ここからは、実際にシステムに組み込む技術手法を横並びで比較します。ベンダー提案書に出てくる用語をまず一枚の表で押さえ、そのうえで用途別のグループごとに使い分けを解説します。
6手法の一覧比較表
手法 | 処理内容 | 可逆性 | 主な用途 | 実装難易度 | データ有用性への影響 |
|---|---|---|---|---|---|
k-匿名化 | 準識別子を持つレコードが k 件以上のグループになるよう加工 | 不可逆 | 統計分析・第三者提供 | 高（準識別子選定・k 値設計・検証が必要） | 中〜大（粒度が粗くなる） |
一般化 | 属性を粗い区分に置換（生年月日→年代、住所→都道府県） | 不可逆 | k-匿名化の前処理・単独でも使用 | 中 | 中 |
トップコーディング | 極端値を集約（100 歳以上を「100+」に統一） | 不可逆 | 特異値による再識別リスク低減 | 低 | 小〜中（特定範囲のみ） |
マスキング | 特定桁を伏字化（電話番号 090-****-1234） | 不可逆（元値保管あり別扱い） | 表示・帳票・オペレーション画面 | 低 | 大（数値・文字が失われる） |
トークナイゼーション | 元値を無関係なトークンに置換し、対応表を別金庫で管理 | 可逆（対応表参照時） | 決済系・システム間連携 | 中〜高（金庫の設計と運用） | 小（連携用途では値の意味を保持） |
ハッシュ化 | 一方向関数で不可逆に変換（salt 併用） | 不可逆 | ID 突合・ログ収集 | 低 | 大（元値の意味は失われる） |
この表のポイントは、「可逆性」と「用途」の 2 軸で手法が大きく 3 グループに分かれるという点です。
- 統計分析用途（k-匿名化・一般化・トップコーディング）: 集計値としてデータの傾向を保ちながら、個人特定リスクを下げる
- システム連携用途（マスキング・トークナイゼーション・ハッシュ化）: 個々のレコードを扱いつつ、元の値を隠す
- どちらでも使える汎用手法（一般化・ハッシュ化）: 用途を跨いで使えるが、それぞれの目的に応じた設計が必要
以降のサブセクションで、この 3 グループごとに使い分けの判断軸を掘り下げます。
k-匿名化 / l-多様性 / t-近接性 の関係（統計分析用途）
k-匿名化は、統計分析目的で個人情報を安全に扱うための代表的な手法です。仕組みはシンプルで、「準識別子（郵便番号・生年月日・性別など）の組み合わせが同じレコードが必ず k 件以上存在するように、データを一般化（粗粒度化）する」というものです。k=5 なら、どの準識別子の組み合わせを取っても最低 5 人が該当する状態を保証します（NEC ソリューションイノベータ「k-匿名化とは」、Qiita「匿名化技術についてまとめてみた」）。
ただし k-匿名化には既知の弱点があり、実務では次の 2 つの補強手法とセットで検討します。
- l-多様性: k 人のグループの中で、機密属性（病名・年収など）の値が l 種類以上存在することを要求する。「同じ準識別子グループが全員同じ病名だと、個人が特定できなくても病名が推定できてしまう」という属性推論攻撃への対策
- t-近接性: 各グループ内の機密属性分布が、データセット全体の分布に近い（距離 t 以下）ことを要求する。「グループ内の分布が極端に偏っていると、統計的に機密属性が推定できてしまう」という歪度攻撃への対策
「k-匿名化を採用します」というベンダー提案を受けたら、次の 2 点を追加で確認すると良いでしょう。「準識別子は何を選び、k 値はいくつに設定しますか？」「機密属性を扱う場合、l-多様性・t-近接性の追加が必要な種類のデータでしょうか？」。特に医療・センシティブ属性を扱うケースでは、k-匿名化単体では不十分なことが多いです。
マスキング / トークナイゼーション / ハッシュ化 の使い分け（システム連携用途）
こちらは統計分析ではなく、個々のレコードを扱いながら元の値を隠したいケースで使います。ぱっと見似ていますが、目的と設計が異なります。
- マスキング: 特定の桁を「*」などで置き換えて表示する。オペレーション画面や帳票で、担当者に元値を見せずに業務を遂行させたいケースで多用。加工処理そのものは軽量で実装が容易だが、マスキング後の値では業務が回らない場面もあるため、権限別に「元値表示可 / マスク表示のみ」の切り替え設計とセットになる
- トークナイゼーション: 元値を無関係な文字列（トークン）に置き換え、元値との対応表を「金庫」に保管する。金庫は物理的に別セグメント・別権限で管理し、必要時のみ API 経由で復元する。決済業界では PCI DSS 準拠・審査範囲縮小の観点で標準的に採用される手法（NTTデータ先端技術「PCI DSS Tokenization Guidelines」）
- ハッシュ化: 一方向関数で不可逆に変換する。ID 突合（別システム間で同一人物を突き合わせる）やログ収集で、元値を持たずに同一性のみ扱いたいケースで使う。ただし単純なハッシュはレインボーテーブル攻撃に弱く、salt（ランダム値）を必ず付与する必要がある
用途を混同しがちなのは、「マスキングとトークナイゼーションの違い」です。マスキングは元値を復元する仕組みを持たない（あるいは元 DB を参照するだけ）のに対し、トークナイゼーションは対応表の運用そのものが設計の中心になります。ベンダー提案書に「トークナイゼーションで対応します」と書かれていたら、対応表の保管場所・アクセス権限・鍵ローテーションの設計まで確認する必要があります。
一般化・トップコーディング（数値・カテゴリの粗粒度化）
一般化とトップコーディングは、単独で使うよりも k-匿名化の前処理として組み合わせられることが多い手法です。
- 一般化: 数値やカテゴリを粗い区分に置き換える。生年月日 → 年代、住所 → 都道府県、詳細職業 → 業界カテゴリ、といった加工。準識別子の一意性を減らすことで k-匿名性を達成しやすくなる
- トップコーディング: 分布の端にある特異値を丸める。「100 歳以上の人」「年収 3,000 万円以上」など少数派のレコードは、そのままだと再識別リスクが高いため、「100 歳以上」「3,000 万円以上」といった単一カテゴリに集約する
いずれも実装難易度は高くありませんが、「どの粒度まで一般化するか」「どこから特異値と見なすか」の閾値設計が精度と再識別リスクのトレードオフになります。分析要件が「都道府県単位の集計で十分」なら大胆に一般化できますが、「市区町村単位で分析したい」なら準識別子の一意性が残りやすく k-匿名性の達成が難しくなります。この判断を先送りにするとベンダー側でも設計が定まらないため、RFP の段階で「分析軸として必要な粒度」を明示しておくとスムーズです。
発注ケース別の技術手法選定マトリクス
ここまでで手法の中身を押さえたら、次は「自社ケースにどの組み合わせを当てるか」を決められる状態を目指します。ここが本記事の中核です。
選定マトリクスの読み方（3軸）
技術手法の選定は、次の 3 軸で判断するとブレにくくなります。
- 対象データの性質: どんな種類の個人情報か（識別子・準識別子・機密属性・センシティブ属性）
- 活用目的: 統計分析か、個別レコードの連携・突合か。第三者提供の有無
- リスク許容度: 再識別が発生した場合の影響度（法規制の重み・レピュテーション・業界特性）
この 3 軸を明示しないまま「どの手法にしますか？」とベンダーに聞いても、噛み合った提案は返ってきません。RFP の冒頭でこの 3 軸を書いておくと、ベンダー各社の提案が同じ土俵で比較できるようになります。
発注ケース別のおすすめ組み合わせ
代表的な発注ケースと、それぞれに適する技術手法の組み合わせを表にまとめます。
発注ケース | 対象データ | 活用目的 | おすすめ組み合わせ | 補足 |
|---|---|---|---|---|
顧客購買データを外部委託先の BI 分析基盤に投入 | 属性 + 購買履歴 | 統計分析 + 第三者提供 | 匿名加工情報化 + k-匿名化 + 一般化 + トップコーディング | 準識別子の粒度設計と k 値の妥当性検証を PIA でドキュメント化 |
社内マーケ部門でセグメント分析（第三者提供なし） | 属性 + 行動ログ | 社内分析 + 個別ID保持 | 仮名加工情報化 + トークナイゼーション | ID 単位で追跡可能な状態を残しつつ、氏名等の識別子は削除 |
医療・センシティブ属性を含む研究用途 | 属性 + 病名・治療歴 | 統計分析（研究） | k-匿名化 + l-多様性 + アクセス制御強化 | l-多様性を満たさない場合は k-匿名化のみでは不十分 |
決済情報の運用（クレジットカード番号を扱う） | PAN | システム連携（決済） | トークナイゼーション（対応表を PCI DSS 準拠環境で保管） | PCI DSS の審査範囲縮小効果も見込める |
ログ収集で個人特定を回避したい | 一意ID・IP アドレス等 | ログ分析・不正検知 | ハッシュ化（salt 併用） | 突合が必要な場合はソルトの共通化設計が必要 |
オペレーション画面での担当者アクセス | 電話番号・住所 | 業務オペレーション | マスキング（権限別表示切替） | 元 DB の権限管理と組み合わせる |
このマトリクスは決まった正解を示すものではなく、あくまで代表的な組み合わせの例です。実際には対象データや業界規制、既存システムとの接続要件によって微調整が必要になります。ただし「なぜこの組み合わせを選ぶのか」を発注側から示せる状態にしておくと、ベンダー提案書のレビューが格段に楽になります。
差分プライバシーを検討すべきケース
上記の 6 手法でカバーしきれないケースの代表が、AI モデル学習・機械学習の文脈で個人データを扱う場合です。学習済みモデルからの逆算による個人特定リスク（メンバーシップ推論攻撃など）は、k-匿名化や一般化だけでは十分に抑えられません。
このようなケースで検討されるのが差分プライバシーです。統計的にノイズを付加することで、「特定個人がデータセットに含まれているか否かで結果がほとんど変わらない」ことを数学的に保証するアプローチで、AI 開発時の学習データ保護に適しています。詳細な仕組みや発注時の観点は、差分プライバシーとはで扱っています。AI・機械学習を絡めた開発を計画している場合は、そちらも併読することをおすすめします。
システム実装要件（RFPに書くべき5つの観点）
手法の選定が決まったら、次は「加工処理そのもの」だけでなく「継続的な運用」まで含めた実装要件に落とします。ここを RFP で明示していないと、ベンダーは加工バッチだけ実装して終わり、運用が回らない、という事態が起こりがちです。
RFP に含めておきたい観点を 5 つに絞りました。
対象データと加工手法をカラム単位で定義する
もっとも基本になるのが、「どのテーブル・どのカラムに、どの加工手法を適用するか」をカラム単位で定義することです。
- テーブル別・カラム別に「加工手法」「加工後データ型」「精度要件」「アクセス権限」を明記
- 準識別子として扱うカラムを明示的に列挙し、k 値の目標を書く
- マスキング対象カラムは「マスク時に表示する文字数」「元値表示可のロール」も定義
このレベルで書けていない RFP だと、ベンダーの見積前提が揃わず、比較検討ができなくなります。逆にこの粒度まで書けていれば、ベンダー各社の見積比較が「同じスコープに対する価格・工期の比較」として成立します。
マッピングテーブル・鍵の管理設計
仮名化・トークナイゼーションを採用する場合、対応表（マッピングテーブル）や暗号鍵の管理が実装要件の中核になります。ここが甘いと、加工処理自体は正しくても運用でリスクが露出します。
RFP に書くべき項目は次のとおりです。
- 保管場所: 元 DB とは物理的・論理的に分離されたセグメントに保管する（同じ DB インスタンス内は避ける）
- アクセス権限: マッピングテーブルへのアクセスは、加工処理のバッチ用サービスアカウントに限定し、人間の運用担当者は原則アクセス不可
- 鍵ローテーション: 定期的な鍵更新の頻度・手順・過去データの再暗号化ポリシーを規定
- バックアップ・災害復旧: マッピングテーブルの喪失は加工前データが復元不能になることを意味するため、バックアップ要件を明記
- 監査ログ: マッピングテーブルへのアクセスは全件監査ログを取得する
「トークナイゼーションで対応します」というベンダー提案を受けた際に、この観点の設計書が付いてこなければ、「対応表は物理的にどこに置きますか？」「復号 API のアクセス権限はどう設計しますか？」と踏み込んで質問しましょう。
アクセス制御・監査ログの設計
加工後データそのもののアクセス制御と監査ログも、法要件（安全管理措置）を満たすうえで必須の観点です。
- 加工前データへのアクセス: 最小権限（Least Privilege）の原則に従い、加工処理バッチと限定的な運用担当者のみに絞る
- 加工後データへのアクセス: 分析担当者・BI 利用者・委託先など、利用者ロール別にアクセス範囲を定義
- 監査ログの記録項目: 「誰が」「いつ」「どのデータに」「どの操作を行ったか」を全件記録。ログ自体は改ざん検知可能な形式で保管
- ログの保管期間: 法規制・社内規定に沿った保管期間を規定（一般には 3 年以上を目安とする実務が多い）
監査ログは「実装した」だけではなく「異常検知の運用」までセットで設計しないと機能しません。ログを取っただけで確認していない、というのは実効性のない状態です。RFP に「ログを月次で確認する運用フロー」まで含めるかどうかは、社内体制次第で判断します。
再識別禁止の運用（技術＋契約）
匿名加工情報を第三者提供する場合、提供先での再識別行為は法的に禁止されます。この禁止を実効化するには、技術的措置と契約による誓約の両輪が必要です。
- 技術的措置: 加工基準（識別子削除・一般化・k-匿名性など）そのものを担保する加工ロジック
- 契約による誓約: 提供先との契約書に「再識別行為の禁止」「元データとの照合禁止」「加工基準の維持」「違反時の措置」を明記
- 運用モニタリング: 提供先での使用状況をヒアリングまたは監査する仕組み（大規模な提供の場合）
技術だけ、契約だけ、では不十分で、両者をセットで設計する必要があります。RFP には技術的措置の部分を書き、契約テンプレートは法務側で用意する、という分担が現実的でしょう。
加工基準の妥当性検証とドキュメント化
最後に忘れられがちなのが、「なぜこの加工基準で十分なのか」を検証しドキュメントに残す工程です。
- プライバシー影響評価（PIA: Privacy Impact Assessment）の実施: 加工前後の再識別リスクを定量的に評価する
- k 値・準識別子の選定根拠: なぜ k=5 で十分と判断したか、なぜこのカラムを準識別子として扱ったかを記述
- 加工後データの分析精度検証: 加工後データが分析要件を満たすか、事前検証の手順と結果を残す
- 定期的な再評価: データセットの追加・変更に伴い、再識別リスクが変化した場合の再評価タイミング
このドキュメントは、監査対応や個人情報保護委員会への報告時にそのまま提出できる形で残しておくと、後々の運用負担が下がります。RFP には「PIA レポート」「加工基準設計書」「精度検証レポート」を成果物として明示的に含めましょう。
ベンダー提案を評価する5つのチェック観点
RFP を投げたあとは、返ってきた提案書をどう評価するかが勝負になります。ここでは、提案書レビュー時にベンダーへ確認すべき具体項目と、よくある「見落としがちポイント」を整理します。
提案書レビュー時に確認すべき5項目
以下の 5 項目は、複数ベンダーの提案を横並びで比較するときにチェックリスト化しておくと便利です。
- 選定した技術手法の理由: なぜこの手法を選んだのか、他手法との比較検討はしたか、比較の結論を明記しているか
- k 値・準識別子・機密属性の設定根拠: k=5 で十分と判断した根拠、l-多様性の追加要否、機密属性の分類基準
- マッピングテーブル・鍵の保管場所と担当: 物理分離の方式、アクセス権限マトリクス、鍵ローテーションの頻度と手順
- 精度検証: 加工後データが分析要件を満たすかの事前検証手順、精度検証のフェーズがプロジェクトに含まれているか
- 監査・再識別リスク評価のドキュメント: PIA の実施有無、加工基準設計書の納品有無、監査ログの設計方針
この 5 項目に対する回答の「厚み」がベンダーの成熟度を示します。単に「k-匿名化を実装します」「マスキングします」だけで済ませているベンダーと、「準識別子を郵便番号・生年月日・性別の 3 種に設定し、k=5 を最低基準として達成できない粒度は都道府県まで一般化、月次で再識別リスクを再評価します」まで書き込むベンダーでは、後工程での設計手戻りが大きく変わります。
よくあるベンダー提案の「見落としがち」ポイント
複数の提案書を比較していると、次のような「見落とし」がよく見られます。事前に把握しておくと、提案書のレビュー効率が上がります。
- マッピングテーブルの管理設計が薄い: 「トークナイゼーションで対応します」と書きつつ、対応表の保管場所・アクセス権限が具体的に書かれていない。運用フェーズで初めて設計が始まり、追加費用が発生する
- 監査ログの設計が「取得します」で終わっている: ログの記録項目・改ざん検知・保管期間・確認運用まで書かれていないと、実効性のないログ取得になりがち
- l-多様性・t-近接性への配慮が欠落: 機密属性を含むデータで k-匿名化のみ提案されているケース。属性推論攻撃への対応が抜けている
- 再識別リスクの評価がドキュメント化されない: 加工基準は書かれていても、「なぜその基準で十分か」の根拠と評価プロセスが提案に含まれていない
- 加工後データの分析精度検証が別フェーズ扱い: 加工処理が完成した後に「精度が要件を満たしません」となると、加工基準の再設計に戻る大きな手戻りが発生する
こうした見落としは提案時点で指摘して補完してもらえば、実装フェーズでの追加費用・スケジュール遅延を防げます。RFP の段階でこれらを要件として明示的に含めておくと、そもそも提案書に必ず記載されるようになります。
まとめ 〜発注者が今日から始められる3つの行動〜
データ匿名化・仮名化は、法定義の理解・技術手法の選定・実装要件の落とし込みの 3 層で考えると迷いにくくなります。本記事で扱った内容を振り返ると、次のように整理できます。
- 法定義（第 1 層）: 匿名加工情報と仮名加工情報は「第三者提供の有無」と「復元可能性」で選ぶ
- 技術手法（第 2 層）: k-匿名化・一般化・トップコーディング・マスキング・トークナイゼーション・ハッシュ化の 6 手法を用途別（統計分析用・システム連携用）に組み合わせる
- 実装要件（第 3 層）: 加工処理そのものだけでなく、マッピングテーブル管理・アクセス制御・監査ログ・再識別禁止運用・PIA までセットで RFP に書く
このうえで、今日から取り組める行動を 3 つ挙げます。
- 自社データの棚卸し: どのテーブル・どのカラムが「識別子」「準識別子」「機密属性」に該当するかをマッピングする。ここが揃うと、加工手法の選定が具体化する
- 選定マトリクスに沿って RFP を書く: 対象データ・活用目的・リスク許容度の 3 軸で自社ケースを整理し、本記事の選定マトリクスに沿って加工手法の第一候補を決めてから RFP を書く
- 5 つのチェック観点でベンダー提案を評価する: 「選定理由」「k 値・準識別子の根拠」「マッピングテーブル管理」「精度検証」「監査・PIA」の 5 項目を必ず質問し、提案書に書かれていなければ補完してもらう
RFP・要件定義書の粒度が上がれば、ベンダー提案の精度も上がり、実装フェーズでの手戻りが減ります。逆に発注側の準備が甘いままだと、ベンダーは「無難な提案」しかできず、後工程で「そんなつもりではなかった」が発生します。個人情報を扱う受託開発を成功させる第一歩は、発注側が技術手法の選定軸を持つことです。
関連するお役立ち資料
発注ケースの整理や RFP の書き方をより体系的に押さえたい方は、システム開発を成功させるお役立ち資料一覧から、要件定義・ベンダー選定に関するテンプレートをご活用ください。個人情報を扱うシステム開発の発注準備にお役立ていただけます。
個別のご相談
自社の対象データや業界規制を踏まえた技術手法の選定・RFP 作成でご相談があれば、お問い合わせフォームからお声がけください。要件の整理段階からご相談いただけます。
関連記事
【サンプル】システム開発 提案依頼書（RFP）
この資料でわかること
システム開発の発注時に不可欠な「提案依頼書（RFP）」の作成用テンプレートです。課題、機能要件、予算など必須項目を網羅。記入例などのガイド付きで、初めての方でも要件を整理し、スムーズに依頼内容を作成できます。
こんな方におすすめです
- 初めてシステム開発の発注担当になり、何から準備すればよいか不安な方
- 実現したい機能のイメージはあるが、具体的な文章や要件に落とし込むのが苦手な方
- 開発会社への伝え漏れを防ぎ、スムーズに正確な見積もりを取りたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- データの匿名化と仮名化は何が違うのですか？
最大の違いは元データへの復元可能性で、仮名化はマッピングテーブルで復元できる状態を残すのに対し匿名化は復元可能性そのものを排除します。この違いが「第三者提供できるか」「社内分析に限られるか」という法的な扱いを分けます。
- 氏名や電話番号を削除すれば匿名化したことになりますか？
なりません。氏名を消しても郵便番号・生年月日・性別のような「準識別子」の組み合わせが残っていれば個人が特定でき匿名加工情報の要件を満たさず、k-匿名化などによる粗粒度化が別途必要です。
- k-匿名化を採用すれば個人情報保護法の要件は十分満たせますか？
医療情報などの機密属性を含むデータでは不十分な場合があります。同じ準識別子グループ内で機密属性の値が偏っていると、個人特定に至らなくても属性が推定できてしまうため、l-多様性やt-近接性による追加対策の要否を確認する必要があります。
- マスキングとトークナイゼーションはどう使い分ければよいですか？
マスキングは元値を復元する仕組みを持たず、画面や帳票で担当者に元値を見せたくない用途に向きます。トークナイゼーションは対応表を別金庫で管理し、決済連携のように必要時に元値へ復元する用途に向いており、対応表の保管・権限設計が要点になります。
- ベンダー提案を評価するとき最低限確認すべきことは何ですか？
「なぜその手法を選んだか」「k値・準識別子の設定根拠」「マッピングテーブルや鍵の保管場所」「精度検証の有無」「PIAや監査ログの設計」の5点です。回答の厚みがベンダーの成熟度を示すため、具体性が乏しい場合は追加確認が必要です。
