2026年、改正個人情報保護法が成立しました（成立2026年7月10日・公布7月17日＝令和8年法律第56号。施行は公布後2年以内が予定され、詳細を定める規則やガイドラインは今後具体化される部分が残ります）。
改正のニュースは、法務・管理部門の話として受け取られがちです。でも私は、これは手を動かすエンジニア・情シスにこそ具体的な作業として降りてくる話だと考えています。この記事では、制度の解説は最小限にして、「で、結局うちは"何を"証跡に残しておけばいいのか」 という一点だけを、技術者の設計の言葉に翻訳します。
（※以下は「何が求められる方向にあるか」の整理です。規則・ガイドラインの具体化はこれからなので、断定は避けます。）
まず、課徴金が問うものを正確に置く
改正の要のひとつが、課徴金制度の新設です。この分野に、行政上の金銭的な制裁がはじめて入りました（現行法にあるのは刑事罰としての罰金で、行政上の制裁金は今回が初めてです）。
ここで、技術者ほど正確に押さえておきたい線引きがあります。課徴金は、「情報が漏れたこと」への制裁ではありません。 安全管理が不十分で漏えいした、という類型は、課徴金の対象から外されました。課徴金が向いているのは、不正な手段による取得・不適正な利用・ルールに反した第三者提供——つまり「個人データを、どう入手し、どう使い、誰に渡したか」の正当性です。
なぜこの区別が実装に効くのか。「漏えい＝課徴金」と誤解したまま設計に入ると、証跡の重心を取り違えるからです。課徴金が直接問う層は、アクセス制御の堅牢さそのものではなく、データの授受の記録です。一方で、アクセスログや権限管理も別の理由（漏えい報告義務・安全管理措置・そして"不正取得ではない"ことの証明）で確実に要る。両方を、それぞれ正しい理由で設計する——これが今回の芯です。
以下、優先順に並べます。
① データの授受・第三者提供の記録（課徴金が直接問う層）
誰に・どの個人データを・どの根拠（同意／委託／法令）で渡したか。 ここが、今回の改正で最も重みを増した証跡です。改正では第三者提供時の確認・記録の規律や、連絡可能な個人関連情報の取り扱いが強化される方向にあり、「提供の正当性を後から説明できるか」が問われます。
設計の勘所は3つ。提供イベントに根拠を紐づける （同意ID・委託契約・法令条項のいずれかが必ず参照できる）。 提供先と提供目的を残す （どこへ、何のために）。そして "提供していない"ことも含めて追える（意図しない提供がないことを、ログの不在でなく設計で示せる）。ここが空白だと、不正取得・不適正利用の嫌疑がかかったときに反証できません。
② 個人データへのアクセスログ
誰が・いつ・どのデータに触れたか。 これは課徴金が直接問う層ではありませんが、"正当な経路で取得・利用した"ことを後から示す土台であり、漏えい発生時の報告義務にも直結します。設計で押さえたい点は3つ。
-
主体の特定：ログの「誰が」が、共有アカウントや
adminで潰れていないか。個人まで一意に辿れるか。 - 対象の粒度：「どのデータに」がテーブル単位で止まっていないか。ただし過剰に取ると保護対象が増える（ログ自体が個人データを含む）ので、最小限で追える粒度を意図して決める。
- 改ざん耐性：追記専用（append-only）・保存先の分離・保存期間の明示。後から書き換えられるログは、示す局面で弱い。
③ 権限の付与・変更の記録
誰が・その権限を・いつ・誰の承認で得たか。 アクセスログが「触れた事実」なら、こちらは「触れられる状態にした事実」です。
勘所は、付与と承認をセットで残すこと。申請→承認→付与が別々のツール（チャット・スプレッドシート・IdP管理画面）に散ると、後から突き合わせる作業が地獄になります。付与イベントに承認の参照が紐づく形にしておく。そして見落とされがちなのが、剥奪（解除）の記録です。退職・異動で権限が外れた事実が残っていないと、「今この人がなぜこの権限を持つのか」を説明できません。付けた記録と同じ重みで、外した記録を残す。
④ 検知し、対応した記録
漏洩や不正アクセスを検知し、対応した記録です。平時から検知の仕組みが動いていて、その作動と対応が記録に残っていること自体が、「統制できている」の証跡になります。技術的には、アラートの発火・一次対応・エスカレーション・恒久対応、という一連が時系列で追える状態。インシデント対応を後から物語として再構成できるか、が問われます。
⑤ 強化領域（16歳未満・特定生体）を扱う場合
今回の改正では、規律が強化される方向の領域があります。16歳未満の個人情報、そして顔認証・指紋・声紋などの特定生体個人情報です（具体的な要件は規則・ガイドラインで固まる部分が残ります）。これらを扱うシステムなら、取得と利用の記録を通常の個人データより一段手厚く。生体データを扱うプロダクトや未成年ユーザーを持つサービスは、この領域が自分に当たるかを早めに棚卸ししておくと、後で慌てずに済みます。
「後から追える」の芯は、点ではなく線
ここまでを貫く芯を、ひとつだけ。証跡は、ある時点のスナップショットではなく、連続した線であって初めて意味を持ちます。
- 改ざんできない形で
- 必要な粒度で
- 定めた期間、保存され
- 別々の記録どうしが突き合わせられる
この4つが揃って、はじめて「後から問われたときに示せる」状態になります。ログを"出している"だけの状態と、"示せる"状態のあいだには、設計の意図という距離があります。
一度作る、だけでは終わらない
正直に付け加えます。ここまでの証跡設計は、エンジニアなら「設計して、一度作る」ことができます。手を動かせば構築できる。
でも制度が本当に問うのは、その先です。作った状態が、その後も維持され、今どの水準にあるかを把握し続けられているか。 アクセスログの設計を入れた三か月後、権限の棚卸しは回っているか。新しく増えたSaaSは証跡の網に入っているか。ここが一番続きません。
私が課題だと感じているのは、この 「今、自社の証跡がどの水準にあって、次に何をどの順で固めればいいか」を継続的に把握する 部分です。作って終わりにせず、現在地を測り、次の一手を決め、前回からの改善を推移で残す──この運用のループを軽くしたくて、私は SecuROI を作っています。20問・約15分で、NIST CSF 2.0／ITGC観点の現在地を数字にし、次の一手をレポートにする、という発想のツールです。
設計でこだわっているのは、現在地の数値化に生成AIを使わないことです。点数は決定論的に（同じ入力なら必ず同じ結果になるように）出し、AIは文章化の翻訳だけに使う。監査や取引先に示す証跡が、実行するたびに揺れては困るからです。ここは合否を判定する道具ではありません。現在地を映す鏡であり、次の一手を指す羅針盤に徹する、という立て付けです。
まとめ
- 改正個情法に課徴金が入ったが、課徴金が問うのは「漏れたこと」ではなく「取得・利用・提供の正当性」。安全管理措置違反による漏えいは対象外。
- ゆえに技術者がまず残すべきは、データの授受・第三者提供の記録（誰に・何を・どの根拠で）。
- アクセスログ・権限・検知対応は、漏えい報告義務と"不正取得でないことの証明" のために引き続き要る。
- 「後から追える」の芯は、点ではなく改ざん耐性・粒度・保存・突き合わせが揃った線。
- 本当の難所は"一度作る"より、"今どの水準か"を測り続ける運用のループにある。
制度に振り回される側でいるか、証跡の基盤を持って迎える側になるか。その分岐は、手を動かすエンジニアの現場から始まると、私は思っています。
▼関連：「NIST CSF 2.0の6機能を、J-SOXのITGC（IT全般統制）にどうマッピングするか」という記事を別途書いています。Qiita内で同名検索で辿れます。
▼経営・監査の目線から同じ話を読みたい方は、note に「課徴金時代、経営が示す"統制できているか"」を書いています。