匿名加工情報とは？加工基準と第三者提供の義務をデータ提供の設計要件に翻訳

保有している購買履歴や利用ログを、本人の同意を取り直さずに社外のパートナーへ渡したい。この要求に応える制度が匿名加工情報です。特定の個人を識別できず、元の個人情報も復元できない水準まで加工すれば、個人情報ではなくなり、本人の同意なしに第三者へ提供できます。その代わり、施行規則第34条が定める5つの加工基準と、作成時・提供時の公表、識別行為の禁止、削除した情報を捨てる義務が課される。本稿では条文とガイドラインの記述を、どのカラムをどう削り、加工処理をどの経路に置くかという設計要件へ翻訳します。2026年9月時点の一次情報にもとづく整理です。

まとめ：本人同意なしで社外へ出せる制度としての匿名加工情報と適用の限界

匿名加工情報は、特定の個人を識別できないように個人情報を加工し、かつ元の個人情報を復元できないようにしたものを指します（法第2条第6項）。この水準まで加工すると個人情報に当たらなくなるため、本人の同意なく第三者へ提供でき、目的外利用の制限もかかりません。社外提供や外販データを前提とする企画で、唯一まっすぐ選べる制度がこれです。

負担は加工の重さに現れます。規則第34条は5つの基準を並べており、氏名や個人識別符号を消すだけでは足りません。分散管理のために振った連結ID、症例数の少ない病歴のような特異な記述、データベース全体の性質を踏まえた追加の措置まで求められる。ここを軽く見積もると、加工したつもりのデータが基準未達のまま外へ出ます。

設計上いちばん効くのは、作った後の破棄義務でしょう。氏名と仮IDの対応表は作成後に破棄しなければならず、仮IDの生成に使った乱数等のパラメータも同じく破棄が求められます。仮名加工情報のように対応表を隔離して持ち続ける運用は成り立たない。この一点でパイプラインの組み方も、後から再加工したいという要望への回答も変わります。

匿名加工情報の定義と、仮名加工情報および統計情報との境界の引き方

まず押さえるべきは、匿名加工情報が「個人情報ではなくなる」点です。ここが仮名加工情報との決定的な差になります。

復元できないことまで求める法第2条第6項の定義と通常の方法という基準

法第2条第6項は、匿名加工情報を、区分に応じた措置を講じて特定の個人を識別することができないように加工して得られる個人に関する情報であって、当該個人情報を復元することができないようにしたもの、と定義します。措置の内容は、記述等で識別できる個人情報については記述等の一部の削除（第1号）、個人識別符号を含む個人情報についてはその全部の削除（第2号）です。いずれも、復元できる規則性を持たない方法で他の記述等へ置き換える形を含みます。

実務が救われるのは要求水準の書き方です。個人情報保護委員会のガイドライン（仮名加工情報・匿名加工情報編）は、識別できないという要件について、あらゆる手法によって特定できないよう技術的側面から全ての可能性を排除することまでを求めるものではない、と明記しています。基準は「一般人および一般的な事業者の能力、手法等を基準として、通常の方法により特定できない状態」であり、復元できないという要件も同じ立て付けだ。完全な匿名化の証明を求められているわけではない、と読んで差し支えありません。なお同ガイドラインの最終改正は令和8年4月です。上位の区分については個人情報保護法の基本的な概念を整理した記事を先に押さえておくと読み進めやすくなります。

仮名加工情報との違いを分ける復元可能性・第三者提供・個人情報該当性

比較されることの多い仮名加工情報は、法第2条第5項で「他の情報と照合しない限り特定の個人を識別することができない」水準と定義されます。照合すれば個人にたどり着ける状態が許されるぶん加工は軽く、その代わり第三者提供は原則として禁じられる。両者の性格を、個人情報保護委員会のFAQの整理にそって並べます。

選択の分かれ目は用途です。社内の分析だけで完結するなら加工の軽い仮名加工情報が向き、社外へ出す計画があるなら匿名加工情報しか選べません。仮名加工情報の作成基準と利用制限を整理した記事と読み比べると判断が早くなります。

統計情報が規制の対象外になる理由と、匿名加工情報を選ぶ場面の切り分け

もう一つの選択肢が統計情報です。ガイドラインは、複数人の情報から共通要素に係る項目を抽出して同じ分類ごとに集計したデータであり、特定の個人との対応関係が排斥されている限りにおいては「個人に関する情報」に該当しないため規制の対象外になる、と説明しています。集計してしまえば制度の外に出る、ということ。切り分けの軸は、レコードが個人単位で残るかどうかです。1行が1人に対応したまま外へ出すなら匿名加工情報、集計値だけを出すなら統計情報でよい。提供先が独自の分析軸で切り直したいと言うなら前者が要ります。統計情報で足りる案件に匿名加工情報の枠組みを持ち込むと、公表義務も破棄義務も背負い込むことになる。先に提供先の分析要件を確かめてください。

規則第34条が定める5つの加工基準を、テーブルと変換処理の設計に置き換える

加工基準は法第43条第1項が規則へ委任し、規則第34条が5つの号で具体化しています。号ごとに、どのカラムへ何をするかを見ていきます。

第1号と第2号が求める識別記述等と個人識別符号の削除をカラムで捉える

第1号は、特定の個人を識別することができる記述等の全部または一部の削除を求めます。氏名のように単体で識別できるものだけでなく、住所と生年月日のように組み合わさって識別できるものも対象です。ガイドラインPDF本体の加工事例は具体的で、氏名を削除し、住所は削除するか「○○県△△市」に置き換え、生年月日は削除するか日を落として生年月に置き換える、という形になっています。別の事例では会員ID・氏名・電話番号を削除します。

第2号は個人識別符号の全部削除です。旅券番号、基礎年金番号、免許証番号、住民票コード、マイナンバー、医療・介護保険各法の保険者番号や被保険者番号、生体情報をデジタルデータへ変換したものが該当する。第1号と違って「一部」という逃げ道がなく、全部を消すか、復元できる規則性を持たない方法で置き換えるかの二択です。テーブル設計では、これらを1つのカラム群としてタグ付けし、変換処理の入口で必ず落とす構成にすると取りこぼしが減ります。

第3号の連結符号の削除が、分散管理している基盤にいちばん重く効く理由

実装者にとって効くのが第3号でしょう。個人情報と、それに措置を講じて得られる情報とを連結する符号のうち、現に取り扱う情報を相互に連結するものに限って削除または置き換えが求められます。事例は、氏名等の基本情報と購買履歴を分散管理し管理用IDで連結している場合にその管理用IDを削除する、というもの。委託先への提供に付けた管理用IDを仮IDへ置き換える事例も挙がっています。

安全管理の観点でテーブルを分割し、代理キーで結合する設計は珍しくありません。その代理キーがそのまま第3号の対象になる。分散管理のIDとして実際に使われていれば、管理用に採番したIDでも電話番号でも該当します。対象は加工時点で現に取り扱われている情報を連結するものに限られる。既存の結合キーの棚卸しが、実務では最初のヤマになります。

第4号の特異な記述等と第5号のデータベースの性質を踏まえた追加の加工

第4号は特異な記述等の削除です。珍しい事実や他の個人と著しい差異が認められる記述は、それ自体が特定につながり得ます。事例は、症例数の極めて少ない病歴の削除と、年齢「116歳」の「90歳以上」への置き換え。どの記述が特異かは情報の性質を勘案して個別に客観的に判断するとされ、機械的な線引きはありません。

第5号は、第1号から第4号までの措置を講じてもなお識別や復元の余地が残る場合に、データベース等の性質を勘案した追加の措置を求めるものです。事例は、自宅や職場の所在が推定できる位置情報の削除、購入者が極めて限定される商品情報の商品カテゴリーへの置き換え、身長150cm以上を「150cm以上」へまとめるトップコーディングです。購買履歴や位置情報のように反復される行動の記録は、蓄積によって行動習慣が読み取れるため、単体では識別できない項目でも加工の対象になり得ます。取りうる手法は別表2に一覧化されている。

k匿名性の考え方を第5号の適切な措置にどう対応させて水準を決めるか

技術文献でよく出てくるk-匿名性、つまり同じ属性の組み合わせを持つレコードが必ずk件以上存在する状態にする、という考え方は、規則の条文にもガイドラインの加工基準にも登場しません。規則第34条第5号が求めているのは、データベース等の性質を勘案して適切な措置を講ずることであって、特定の指標をいくつ以上にせよという数値基準ではないのです。

とはいえ、第5号を満たしたと社内で説明するには何らかの物差しが要ります。実務では、別表2の一般化やトップコーディングを当てた後、準識別子の組み合わせごとの件数を数え、1件しかない組み合わせが残っていないかを確認する手順を置く。k-匿名性の考え方を、法令要件そのものではなく第5号の充足を判断する検査手段として使う位置づけです。この区別を曖昧にしたまま「k=5を満たしたので適法」と書いた設計書は、根拠を問われたときに崩れます。

作成後にかかる公表・安全管理・識別行為禁止の義務と実装上の置き場所

加工が終われば自由に使える、とはなりません。作成した事業者には加工とは別の義務が続きます。

加工方法等情報の安全管理措置と、対応表や乱数パラメータの破棄の義務

法第43条第2項は、削除した記述等・個人識別符号・加工の方法に関する情報を「加工方法等情報」と呼び、その漏えいを防ぐ措置を求めます。規則第35条の基準は3つで、取り扱う者の権限と責任の明確化、規程類の整備と取扱状況の評価・改善、正当な権限を持たない者による取扱いの防止です。

ただし、匿名加工情報でいちばん効くのはその先の記述でしょう。ガイドラインは、氏名と仮IDの対応表について、匿名加工情報と容易に照合でき元の本人を識別できることから、作成後は破棄しなければならない、と述べています。さらに、置き換えアルゴリズムと乱数等のパラメータの組み合わせを保有していると再度同じ置き換えができてしまうため、乱数等のパラメータも作成後に破棄しなければならない、と続く。仮名加工情報が対応表を隔離して持ち続ける運用であるのに対し、匿名加工情報は捨てる運用になります。この差がパイプラインの設計を分けます。

作成時の公表と第三者提供時の公表・明示を運用フローのどこに埋め込むか

公表義務は2段階です。作成時は法第43条第3項と規則第36条により、作成後遅滞なく、インターネットの利用その他の適切な方法で、匿名加工情報に含まれる個人に関する情報の項目を公表する。個人情報保護委員会の匿名加工情報のページも、作成後遅滞なくホームページ等で項目を公表しなければならない旨を説明しています。公表項目の例は、氏名を削除し生年月日を一般化した場合の「性別」「生年」「購買履歴」です。

第三者提供時は法第43条第4項（自ら作成した場合）または法第44条（他者が作成したものを扱う場合）により、あらかじめ提供する情報の項目と提供の方法を公表し、提供先に対して匿名加工情報である旨を明示します。明示の方法は規則第37条第2項が電子メールの送信または書面の交付その他の適切な方法と定めており、口頭では足りません。提供の方法の事例はハードコピーの郵送とサーバへのアップロードで、ネットワーク経由で利用できる状態に置けば提供に当たる、という整理も明記されています。

項目が同じ匿名加工情報を同じ手法で反復・継続的に作成または提供する場合は、最初の公表で継続的に作成・提供する旨を明記しておけば、その後の分は先の公表で行われたものと解される、とされています。バッチで毎月出す構成なら、この書き方を最初の公表文へ入れておくと運用が軽くなります。

識別行為の禁止が分析チームの日常の作業にかける制約と例外の見分け方

法第43条第5項と法第45条は、元の個人情報の本人を識別する目的で他の情報と照合することを禁じています。受領側については加工方法等情報を取得する行為も禁止の対象です。照合先の「他の情報」に限定はなく、個人関連情報や仮名加工情報も含み、どの技術を使うかも問われません。

境界はガイドラインの事例が示しています。当たらないのは、複数の匿名加工情報を組み合わせて統計情報を作ること、気象情報や交通情報のような個人と関係のない情報とあわせて傾向を分析すること。当たるのは、保有する個人情報と匿名加工情報の共通する記述等を選別して照合することです。外部データとの結合そのものが禁じられているわけではなく、結合の目的が本人の識別に向いているかどうかが分かれ目になります。

データ提供の実装として組むときの処理経路とアクセス制御の設計方針

ここからは条文を基盤の設計へ落とします。受託の現場で判断が割れるのは、加工処理の置き場所と公表運用の維持です。

加工処理を取り込み経路のどこに置くかで運用の重さが変わる3つの案

1つめは、ソースから取り込む段階で加工し、生データを基盤に入れない案です。破棄義務と相性がよく、対応表も乱数パラメータも取り込みジョブの中で消せる。反面、加工基準を後から見直すときに元データへ戻れないため、提供項目が固まっている案件向きです。

2つめは、生データを保管する層と提供用データセットを分け、後者を生成するジョブでのみ加工する案。加工の見直しがきき、複数の提供先へ異なる粒度で出す構成も組めます。ただし生データ側は個人データのままなので、通常の安全管理措置とアクセス制御が残る。この点はデータレイクの層設計を整理した記事の考え方が土台になります。

3つめは、提供先ごとに都度クエリで加工してエクスポートする案。柔軟ですが加工の内容が実行のたびに変わり得るため、公表した項目との一致を担保しにくく、反復・継続提供の公表を1回で済ませたいなら避けたほうが無難でしょう。データ分析基盤の構築支援では、この処理経路の切り分けと権限設計を要件定義の段階から詰めています。

公表項目をデータカタログと同期させて記載の陳腐化を防ぐ運用の組み方

運用が壊れる典型は、公表したホームページの記載と実際に出しているデータの項目がずれることです。カラムを1本足しただけで公表項目の記載は不足になり、第三者提供の公表は「あらかじめ」行うものなので、追加した後で書き足すのでは順序が逆になってしまう。

実装の手当てとしては、提供用データセットのスキーマ定義を単一の情報源として持ち、そこから公表用の項目一覧を生成する構成が有効でしょう。スキーマにカラムを足すと公表文の差分が生成され、公表を済ませるまで提供ジョブが動かない、という順序をパイプライン側で強制します。データカタログがあるなら、提供用データセットに「公表済み項目」の属性を持たせ、日次のチェックジョブで突き合わせる形でも成立する。人の記憶に依存させないことが要点です。

匿名加工情報を採用すべき条件と、見送って別の手段を選ぶべき場面

ここまでの整理を踏まえ、採否の判断を言い切ります。制度は強力ですが、向かない案件に持ち込むと運用だけが重くなる。

匿名加工情報の採用が向く3つの条件と、そこで得られる運用上の見返り

採用が向くのは、次の3条件がそろう場合です。第一に、個人単位のレコードを社外へ出す必要があること。第二に、提供する項目が事前に確定していて頻繁に変わらないこと。公表が「あらかじめ」の行為である以上、項目の流動性はそのまま運用リスクになります。第三に、元データへの再照合を将来にわたって必要としないこと。破棄義務がある以上、後から突き合わせる要望には応えられません。

この3つを満たすなら見返りは大きい。本人同意の取得も利用目的の変更手続きも不要になり、提供先が増えても同意取得の作業は発生しません。義務がかかるのは匿名加工情報データベース等を構成するものに限られるため、散在する単発の加工データには及ばない点も、運用範囲を絞る材料になります。

見送って仮名加工情報や統計情報、契約で処理すべき場面の具体的な条件

逆に、次のいずれかに当てはまるなら見送りを勧めます。社内の分析だけで完結する案件は、加工が軽く対応表も保持できる仮名加工情報が向く。提供先が固定の集計レポートしか見ないなら統計情報で足ります。グループ会社との共同分析なら、共同利用の枠組みで個人データのまま扱う道も比較対象に入ります。

いちばん危ういのは、加工の重さを見誤ったまま「匿名化すれば同意は要らない」という前提で企画が進む場合です。規則第34条第5号はデータベース等の性質しだいで追加の措置を求める規定であり、必要な加工の程度は事前に一律には決まりません。位置情報や購買履歴のような行動の記録を含むなら、加工の設計と検証だけで相応の工数を見込むことになる。制度の枠組みは令和8年改正個人情報保護法の解説記事で触れているとおり見直しが続いており、改正法は令和8年7月17日に公布されたものの施行はこれからです。長期の企画では、施行時点で加工基準の運用に変更がないかを確かめる前提で進めてください。

よくある質問｜匿名加工情報の作成・提供と漏えい対応に関する5問

検討の場でよく寄せられる質問を、条文とガイドラインにそって整理します。

匿名加工情報にすれば本人の同意なく第三者へ提供できますか？

提供できます。匿名加工情報は個人情報に該当しないため、本人の同意は求められません。ただし無条件ではなく、法第43条第4項または法第44条により、あらかじめ提供する情報の項目と提供の方法を公表し、提供先に対して匿名加工情報である旨を明示する必要がある。公表を怠ったまま提供すれば、加工が適正でも義務違反になります。

氏名を消してハッシュ化したIDを残せば匿名加工情報になりますか？

それだけでは足りません。ガイドラインは、個々人に固有の記述へ同じハッシュ関数を単純に当てると元の記述を復元できる規則性を持つ可能性があるとして、元の記述に乱数等を加えたうえでハッシュ関数を用いる手法を示しています。加えて規則第34条は、第3号で連結符号、第4号で特異な記述等の削除、第5号でデータベース等の性質を踏まえた措置も求める。氏名を消してハッシュIDを振る処理は、5つの基準の一部を満たすにすぎません。

匿名加工情報が漏えいした場合、委員会への報告は必要ですか？

匿名加工情報は個人情報に該当しないため、個人データの漏えい等の報告を定める法第26条は直接には及びません。一方、加工方法等情報、つまり削除した記述等や個人識別符号、復元につながる加工の方法に関する情報は別です。法第43条第2項と規則第35条が漏えい防止の措置を求めており、これらが漏れれば元の個人情報の復元につながる。流出したのが加工後のデータか加工方法等情報かを切り分けて判断してください。

加工を外部のベンダーに委託した場合、公表は誰が行いますか？

委託元です。規則第36条第2項は、委託を受けて匿名加工情報を作成した場合、委託した側が情報の項目を公表するものとし、その公表をもって作成した側が公表したものとみなす、と定めています。委託契約では公表の主体と、項目一覧を委託先から引き渡す時期を明記しておくと公表の遅れを防げます。

作成した匿名加工情報をあとから元データと突き合わせて検証できますか？

できません。法第43条第5項は、自ら作成した匿名加工情報を取り扱うにあたり、元の本人を識別するために他の情報と照合することを禁じています。ガイドラインも、自ら作成した匿名加工情報を元の個人情報と照合することを識別行為に当たる事例として挙げている。対応表と乱数等のパラメータも作成後に破棄が求められるため、技術的にも手段が残りません。加工の妥当性は作成の過程で検証を済ませておく必要があります。

関連記事

• 仮名加工情報とは？作成基準と利用制限を分析基盤の設計要件に翻訳して解説：社内分析にとどめる場合の選択肢を加工基準の対比で確認できます。
• PII（個人を特定できる情報）とは？piiデータの定義・種類と個人情報の違い：加工対象を洗い出す前段として個人を特定しうる情報の範囲を整理できます。
• データレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説：加工処理を置く層を決めるための、基盤アーキテクチャの前提知識です。
• Pマーク（プライバシーマーク）とISMSの違い｜最新規格・2026年改正で選ぶ判断基準：規程類の整備を第三者認証と結びつけて進める場合の判断材料です。