2026.09.06 セキュリティ

仮名加工情報とは？作成基準と利用制限を分析基盤の設計要件に翻訳して解説

氏名を消して仮のIDに置き換えたデータを社内の分析基盤に載せ、取得時に想定していなかった分析にも回したい。この要求に法的な枠を与えたのが仮名加工情報です。他の情報と照合しない限り特定の個人を識別できない状態まで加工すれば、利用目的の変更が柔軟になり、漏えい時の報告義務や本人からの開示請求も外れます。その代わり第三者提供は原則として禁止され、本人への連絡にも使えません。本稿では、施行規則第31条が定める3つの作成基準、作成後の義務と適用除外の範囲、加工処理をどこに置き対応表を誰から隠すかという設計要件を、個人情報保護委員会の一次情報にもとづき2026年9月時点で整理します。

まとめ：社内分析の自由度を広げる制度としての仮名加工情報と適用の限界

仮名加工情報は、個人情報を加工して「他の情報と照合しない限り特定の個人を識別することができない」状態にしたものを指します（法第2条第5項）。狙いは社内での分析にあります。通常の個人データであれば、取得時に特定した利用目的と関連性のある範囲でしか目的を変更できませんが、仮名加工情報にはこの制限（法第17条第2項）が適用されません。取得時に想定していなかった機械学習モデルの学習や新規事業の需要分析へ回す道が開きます。あわせて漏えい等の報告（法第26条）と、本人からの開示・訂正・利用停止等の請求への対応（法第32条から第39条まで）も外れる。運用側の負荷は目に見えて軽くなります。

ただし、外へ出す用途には使えません。第三者提供は法令に基づく場合を除いて禁止（法第41条第6項）で、本人を識別する目的での照合も、本人への電話・郵便・メール送信・訪問も禁じられています。社外のパートナーへ渡す前提の企画なら、匿名加工情報や統計データを選ぶのが筋です。

設計上の急所は、加工後のデータではなく削除した側にあります。氏名と仮IDの対応表や、ハッシュに加えた乱数といった「削除情報等」は規則第32条の基準で隔離しなければならず、漏えいすれば従来どおり報告義務の対象です。加工処理を取り込み経路のどこに置き、対応表を分析者から見えなくできるか。成否はこの実装で決まります。

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

仮名加工情報は個人情報でなくなるわけではなく、多くの場合は個人情報のまま扱いが緩和される。この理解が出発点になります。

他の情報と照合しない限り識別できないという法第2条第5項の定義

法第2条第5項は、仮名加工情報を「他の情報と照合しない限り特定の個人を識別することができないように個人情報を加工して得られる個人に関する情報」と定義しています。条件は「他の情報と照合しない限り」という留保に集約されます。氏名を消して会員IDだけを残したデータは、社内に会員マスタがある限り照合すれば個人にたどり着く。それでも成立します。復元されないことまでは求められていないからです。

個人情報の定義や個人データ・保有個人データの区別については個人情報保護法の基本的な概念を整理した記事を先に押さえると、以降の読み替え規定の理解が速くなります。加工の水準と義務の内容は個人情報保護委員会のガイドライン（仮名加工情報・匿名加工情報編）にまとまっており、最終改正は令和8年4月です。

匿名加工情報との違いを分ける復元可能性・第三者提供・開示請求の3点

混同されやすい匿名加工情報は、法第2条第6項で「特定の個人を識別することができないように加工し、当該個人情報を復元することができないようにしたもの」と定義されます。復元できない水準まで求められるぶん加工は重い。その代わり本人の同意なく第三者へ提供できます。両者の性格の違いを、個人情報保護委員会が公開しているFAQの整理にそって並べると次のようになります。

比較軸	仮名加工情報	匿名加工情報
根拠条文	法第2条第5項	法第2条第6項
復元可能性	照合すれば識別できる	復元できない水準まで加工
個人情報該当性	原則として個人情報のまま	個人情報に当たらない
第三者提供	原則禁止（法第41条第6項）	本人同意なしで可能
利用目的の変更	関連性を超える変更も可	目的の制限を受けない
開示等の請求	対象外（法第41条第9項）	対象外

選択の分かれ目は用途です。社内で分析するだけなら加工が軽い仮名加工情報で足り、社外へ渡すなら匿名加工情報しか選べません。加工の重さと使える範囲がきれいに反比例している、と捉えると迷いません。社外提供を前提にするなら、匿名加工情報の加工基準と第三者提供の義務を整理した記事で規則第34条の5つの基準を確認してください。

削除情報等を保有する側と提供を受けた側で変わる個人情報該当性の判定

同じデータでも、持っている主体によって扱いが変わります。作成した事業者は元の個人情報や対応表を手元に残しているのが普通で、この状態では「他の情報と容易に照合することができ、それにより特定の個人を識別することができる」ため、その仮名加工情報は個人情報に該当し、法第41条の義務がかかります。

一方、委託や共同利用で提供を受けた側が元データも削除情報等も持っていない場合、そのデータは個人情報ではない仮名加工情報になります。適用されるのは法第42条で、第1項と第2項で第三者提供が禁じられ、第3項によって安全管理措置・従業者の監督・委託先の監督・苦情処理・識別行為の禁止・本人への連絡等の禁止が準用されます。委託先に渡すデータの設計では、受け手がどちらの立場に立つのかを先に確定させてください。

規則第31条が定める三つの加工基準と、実データでの削除対象の具体例

加工の水準は、法第41条第1項を受けた施行規則第31条が3つの号で定めます。いずれも「削除するか、復元できる規則性を持たない方法で置き換える」という選択肢があり、丸ごと消す必要はありません。

氏名・住所・生年月日など識別記述等の削除と仮IDへの置き換え方

第1号は、特定の個人を識別できる記述等の全部または一部の削除を求めます。ガイドラインPDF（全62ページ）に載る想定事例は具体的です。氏名・住所・生年月日を含む情報なら、氏名は削除、住所は削除するか「○○県△△市」まで丸める、生年月日は削除するか日を落として生年月に置き換える。会員ID・氏名・住所・電話番号の組であれば、会員IDと氏名と電話番号を削除し、住所を市区町村まで丸める。この粒度で示されています。

注意したいのは仮IDの作り方です。ガイドラインは、個々人に固有の記述へ同じハッシュ関数を単純に適用すると元の記述を復元できる規則性を持つ可能性があると指摘し、元の記述に乱数等を加えたうえでハッシュ関数を用いる手法を挙げています。ソルトなしのハッシュは加工基準を満たさないおそれがある。実装で最初に決めるべき事項です。

個人識別符号の全部削除が求められる顔認証データや公的番号の扱い

第2号は個人識別符号を対象とし、こちらは「全部を削除」と定められています。一部を伏せる処理では基準を満たしません。対象には、指紋や顔の特徴を変換した認証用データのほか、旅券番号・基礎年金番号・運転免許証番号・住民票コード・個人番号など、政令と規則で列挙された符号が含まれます。

見落としやすいのは、業務システムから取り込んだテーブルの末尾に本人確認用の番号列が残っているケースです。マスキング対象を「氏名・住所・電話番号・メールアドレス」だけで定義していると、この列が素通りします。取り込み対象テーブルの列定義を洗い、個人識別符号に当たる列の台帳化を加工処理の設計より前に置いてください。

クレジットカード番号など財産的被害のおそれがある記述の削除範囲

第3号は、不正に利用されると財産的被害が生じるおそれのある記述等の削除を求めます。ガイドラインの事例は、クレジットカード番号の削除と、送金や決済の機能を持つウェブサービスのログインIDとパスワードの削除です。被害の大きさが類型的に高いものを、識別性とは別枠で落とす趣旨になります。

この号が効いてくるのは、決済ログを分析対象に含めるときです。購買金額や決済手段の種別は残したい一方、カード番号は下4桁でも他の情報と組み合わせれば不正利用の足がかりになり得る。認証情報と決済識別子は取り込み経路の入口で落とす設計が現実的です。

仮名加工情報の作成後にかかる義務と、漏えい報告や開示請求の適用除外

加工して終わりではありません。法第41条は第2項から第9項にかけて、作成後の義務と適用除外を並べています。

利用目的の変更が広く認められる代わりに課される公表義務の範囲

個人情報である仮名加工情報は、法令に基づく場合を除き、特定された利用目的の達成に必要な範囲を超えて取り扱えません（法第41条第3項）。作成時には、元の個人情報について特定していた利用目的が引き継がれます。範囲を超えて使うなら、あらかじめ利用目的を変更する必要がある。

その変更が緩いところに、この制度の値打ちがあります。法第41条第9項によって法第17条第2項が適用されないため、変更前の利用目的と関連性を有すると合理的に認められる範囲を超える変更も認められます。ただし変更したら公表しなければなりません。しかも第4項の読み替えにより「本人への通知」という手段は使えず、公表のみが残ります。プライバシーポリシーの改定フローに、仮名加工情報の利用目的を書く欄を作っておくのが安全です。

削除情報等の安全管理措置として規則第32条が求める三つの体制

法第41条第2項は、仮名加工情報を作成したとき、または仮名加工情報と削除情報等を取得したときに、削除情報等の漏えい防止措置を義務づけています。削除情報等とは、削除した記述等・個人識別符号に加え、加工方法に関する情報のうち元の個人情報を復元できるものを指します。氏名と仮IDの対応表や、仮ID生成に使った乱数のパラメータが典型例です。

規則第32条が定める基準は3項目あります。削除情報等を取り扱う者の権限と責任を明確に定めること。取扱いに関する規程類を整備し、それに従って取り扱ったうえで取扱状況を評価し、結果にもとづいて改善を図ること。そして、正当な権限を持たない者による取扱いを防止する措置を講じること。3つ目が、後述するアクセス制御の設計要件へ直結します。

漏えい報告と開示請求が外れる範囲と、元データ側に残る報告義務

法第41条第9項により、仮名加工情報である個人データには漏えい等の報告および本人通知（法第26条）が適用されず、仮名加工情報である保有個人データは開示・訂正等・利用停止等の請求（法第32条から第39条まで）の対象外となります。第5項は、利用する必要がなくなった仮名加工情報である個人データと削除情報等に、遅滞なく消去する努力義務を課しています。

ここで線を引き違えると事故対応を誤ります。適用除外はあくまで加工後のデータの話であって、作成の元になった個人データや、氏名と仮IDの対応表のような削除情報等には法第26条が適用されます。分析テーブルの流出なら委員会報告が不要でも、対応表が一緒に流出していれば要件を満たす限り報告と本人通知の対象になる。インシデント対応手順書には、流出範囲が分析層だけか対応表を含むかで分岐を作っておくべきです。なお個人情報保護法は令和8年改正法が2026年7月17日に公布された段階で、施行はこれからです。条文と新旧対照表は個人情報保護委員会が公開しているため、社内規程の改定では現行法と改正後の記述を分けて管理してください。

第三者提供の禁止と、委託・事業承継・共同利用で外部に出すときの条件

つまずきやすいのが提供の可否です。原則は禁止、ただし読み替えられた例外がある、という構造を押さえます。

委託・事業承継・共同利用で提供が成り立つ条件と公表すべき5項目

法第41条第6項は、法令に基づく場合を除き、仮名加工情報である個人データの第三者提供を禁じています。同項では法第27条第5項が読み替えて適用され、利用目的の達成に必要な範囲内での取扱いの委託、合併その他の事由による事業承継、共同利用の3つは第三者提供に当たらないものとして扱われます。本人同意による提供という選択肢は残っていません。

共同利用を選ぶ場合、提供にあたって公表しておく事項は次の5つです。

共同利用をする旨
共同して利用される仮名加工情報である個人データの項目
共同して利用する者の範囲
利用する者の利用目的
管理について責任を有する者の氏名または名称等

仮名加工情報の共同利用には、通常の個人データにはない自由度があります。共同利用の範囲や利用目的を、元の個人情報を取得した時点で通知・公表していた利用目的の内容にかかわらず設定できるためです。グループ内でデータを寄せて分析する構想があるなら、通常の個人データより設計しやすい枠組みになります。

識別行為の禁止と本人連絡の禁止がマーケティング施策に課す制限

法第41条第7項は、元の個人情報に係る本人を識別する目的で仮名加工情報を他の情報と照合することを禁じています。続く第8項は、仮名加工情報に含まれる連絡先その他の情報を使って、電話・郵便・信書便・電報・ファクシミリ・電磁的方法による送信・住居訪問を行うことを禁止します。

この2つは施策の設計を実質的に縛ります。仮名加工情報でセグメントを切り、該当する会員へメールを配信する運用は成り立ちません。配信したいなら、通常の個人データとして本人同意や利用目的の範囲を確保する経路を別に用意しておく必要があります。第42条第3項により、これらの禁止は個人情報でない仮名加工情報を受け取った側にも準用されます。

分析基盤に持ち込むときの加工処理の置き場所とアクセス制御の設計

ここからは条文を実装へ翻訳します。パイプラインのどこで加工し、誰に何を見せるかという設計に落ちて初めて、この制度は機能します。

取り込み経路のどこで加工するかで決まる削除情報等の保管範囲と責任

加工処理の置き場所は3つに分かれます。基幹システム側で加工してから連携する、分析基盤の取り込み直後に加工する、分析層で参照するときにマスキングする。最後の選択は避けるべきです。生の個人データが基盤に丸ごと残り、基盤全体が安全管理措置と法第26条の報告義務の射程に入ったまま運用が続きます。適用除外の恩恵はどこにも生じません。

現実的なのは取り込み直後に加工する構成です。連携された生データは短期保持の領域に着地させ、加工ジョブが仮名加工情報を生成したら生データを消去する。分析者が触れる層には仮名加工情報だけを置く。この形なら法第41条第5項の消去努力義務にも自然に対応できます。既存基盤への組み込みは取り込み経路の再設計を伴うため、データ分析基盤の構築とMLOpsの支援のように要件定義から実装まで一貫して引き受けられる体制で進めるほうが、手戻りは少なくなります。

対応表と分析テーブルを分離する権限設計とRLS・ABACの使い分け

規則第32条第3号の「正当な権限を有しない者による取扱いの防止」を、そのまま権限設計の要件に翻訳します。守る対象は分析テーブルではなく、氏名と仮IDの対応表、仮ID生成に使ったソルト、加工ジョブの設定値です。同一データベース内でスキーマを分けるだけでは、管理者権限を持つ運用者が結果的に両方を見られる構成になりがちです。アカウントやプロジェクトの単位で分離し、加工ジョブ専用のサービスアカウントだけが対応表へ到達できる形にします。

分析層の中でも粒度の制御は要ります。部署ごとに参照できる行を限定するなら行レベルセキュリティ（RLS）による制御が向き、案件や属性の組み合わせで動的に判断するなら属性ベースアクセス制御（ABAC）のほうが規程との対応を書きやすくなります。いずれにせよ、規則第32条第1号の「権限と責任の明確化」を満たすため、ロール定義と規程の記述を1対1で対応させてください。

再識別を防ぐための結合制限とクエリログの監査という運用の設計

法第41条第7項が禁じるのは、本人を識別する目的での照合という行為です。禁止対象が目的である以上、システムは意図を判定できません。実装で担保できるのは、照合が起きにくい状態を作ることだけ。具体策は2つあります。外部から購入したデータや別系統の顧客マスタを同居させるときは、仮名加工情報のデータセットと結合キーを共有しない設計にすること。そして分析層へのクエリログを保存し、結合先の異常な組み合わせを定期的に点検することです。

ログの保存は、規則第32条第2号が求める取扱状況の評価と改善に対応する記録にもなります。あわせて、データセットに保持期間を設定し、期限を過ぎたものを消去するジョブを組んでおく。第5項が努力義務だからと放置すると、目的を終えたデータが基盤に堆積します。

仮名加工情報を採用する条件と、匿名加工情報や統計処理へ回す判断

仮名加工情報は便利な制度ですが、すべての分析案件で選ぶべきものではありません。

社内分析の目的変更が繰り返し発生する場面という採用が効く条件

採用が効くのは、次の4条件がそろう場面です。元データが自社で取得した個人データであること。モデルの再学習や新しい仮説検証で分析目的が動くこと。分析結果を外部へ提供する予定がないこと。対応表とソルトを分析者から隔離できる権限設計を組めること。

典型例はECや会員サービスの購買ログです。取得時の利用目的が「商品の発送と会員管理」であっても、仮名加工情報にすれば需要予測モデルの学習や離脱分析へ回せます。法第41条第9項によって開示請求の対応も外れるため、分析用データセットを本人請求のたびに検索する運用も不要になる。分析の回転数が高いほど効き目は大きくなります。

外部提供が前提の案件で仮名加工情報を選ぶ失敗パターンと代替策

逆に、次の2つの場面では採用しないでください。第一に、データを社外へ渡す計画が少しでもある案件です。広告事業者やパートナー企業への提供は法第41条第6項で禁じられており、あとから匿名加工情報へ作り直すことになります。外部提供が前提なら、はじめから匿名加工情報か、集計した統計データを選ぶべきです。

第二に、分析の目的が固定されていて、対象データも小規模な場合です。仮名加工情報にすると、対応表の隔離・規程類の整備・取扱状況の評価という新しい義務が増えます。取得時の利用目的の範囲で分析が完結するなら、通常の個人データとして安全管理措置を維持するほうが管理は単純です。「加工したほうが安全そうだから」という理由だけで選ぶと、守るべき資産が1つ増えるだけに終わります。

よくある質問｜仮名加工情報の具体例と実務での判断に関する5問

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

仮名加工情報の具体例にはどのようなものがありますか？

ガイドラインが挙げる加工事例は、氏名・住所・生年月日を含む情報について、氏名を削除し、住所を「○○県△△市」まで丸め、生年月日を生年月に置き換えるというものです。別の事例では、会員ID・氏名・電話番号を削除し、住所を市区町村まで置き換える形が示されています。実務でよく見るのは、会員IDをソルト付きハッシュで仮IDに置き換え、購買履歴だけを分析テーブルに残す構成です。

仮名加工情報と匿名加工情報はどちらを選べばよいですか？

判断軸は加工の重さではなく用途です。社内で分析するだけなら仮名加工情報で足り、加工の負担も軽く済みます。社外へ提供または公開する計画があるなら、法第41条第6項で第三者提供が原則禁止されているため匿名加工情報しか選べません。両方の用途があるなら、社内分析用と提供用を別のデータセットとして作り分けることになります。

仮名加工情報を作成したら本人への通知は必要ですか？

本人への通知は求められていません。利用目的を変更した場合に必要なのは公表です。法第41条第4項の読み替えにより、通常なら選べる「本人に通知し、または公表する」という選択肢から通知が外れ、公表のみが残ります。プライバシーポリシーに、仮名加工情報として取り扱う旨と変更後の利用目的を記載する運用が実務的です。

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

仮名加工情報である個人データの漏えいは、法第41条第9項により法第26条が適用されないため、委員会への報告と本人への通知が不要です。ただし、作成の元になった個人データや、氏名と仮IDの対応表のような削除情報等が漏えいした場合には法第26条が適用され、要件を満たせば報告と本人通知の対象になります。流出範囲を切り分けて判断してください。

仮名加工情報を外部のクラウド事業者に保管しても問題ありませんか？

利用目的の達成に必要な範囲内での取扱いの委託は、法第41条第6項で読み替えて適用される法第27条第5項第1号により、第三者提供に当たらないものとして扱われます。委託の形をとるクラウド保管は可能です。ただし委託先の監督義務（法第25条）は残るため、保管場所と権限、再委託の可否を契約で押さえてください。委託先が削除情報等を持たない場合、その事業者にとって当該データは個人情報でない仮名加工情報となり、法第42条の規律が適用されます。