Tools / 法務実務ツール

法務実務ツールを一覧で見る

契約管理、問い合わせ受付、個人情報マスキング、契約レビュー支援など、Legal GPT が提供する無料ツール・有償ソフト・有償プロンプトを、用途と対象に沿って一覧で整理しています。「自社に何が必要か」を確かめる入口としてご利用ください。

01 Contract Management LegalOS 契約管理
02 Intake & Logging LegalOS Inbox 受付・証跡整理
03 Personal Information LegalOS マスキング 個人情報マスキング
04 AI Prompts 有償プロンプト 契約レビュー・法改正対応
📋 法務実務スタンダード20選|第4話

「あの案件、今どうなってる?」と聞かれて即答できるか。

法務案件は、受付から完了まで複数の段階を通過する。途中で誰の判断待ちなのか、いつから止まっているのか、なぜ動いていないのか——これらが可視化されていないと、案件は静かに滞留する。担当者本人ですら状況を見失う。

ステータス管理は、案件管理の中核機能だ。本記事では、受付〜クローズまでの標準ステータス設計、滞留検知ルール、可視化方法、社内ルール例までを実務標準として整理する。

🔑 この記事の結論
  • 標準ステータスは 「受付済/受付確認中/レビュー中/差戻し/修正待ち/承認待ち/締結待ち/完了/クローズ」の9段階 が実務標準
  • 各ステータスには 「次に動かす責任者」と「滞留日数の閾値」 をセットで設定する
  • ステータス更新は 受付・差戻し・完了などの遷移時点に必ず履歴を残す。ステータスだけでなく更新者・更新日・コメントを記録
  • 滞留閾値を超えた案件は 担当者・上長に自動通知。「気付いたら2週間止まっていた」を構造的に防ぐ
  • ステータス・更新履歴は 会社法施行規則100条1項1号の「情報の保存・管理体制」 の一環として設計する

まず結論|ステータスは「9段階+滞留検知+履歴保存」がセット

ステータス設計は会社ごとに調整が必要だが、運用が破綻しにくい標準ラインは存在する。実務で再現性が高いのは 9段階のステータスを定義し、各ステータスに「責任者」と「滞留閾値」を紐付け、履歴を不可逆に保存する運用だ。

ステータスを単に「対応中/完了」の2段階にしている法務部門は多いが、これでは「どこで止まっているか」が見えない。逆に20段階・30段階に細分化しすぎると、現場が更新できず形骸化する。9段階は、可視化の粒度と運用負荷のバランスが取れる実務上の落としどころである。

なぜ9段階か
ステータスは「受付フェーズ/審査フェーズ/承認フェーズ/クローズフェーズ」の4局面に分解できる。各局面に2〜3段階を割り当てると合計9段階になる。これより少ないと「審査中」が長期化する案件の状況が見えず、これより多いと現場が更新を怠る。

実務標準(Practical Standard)

① 標準ステータス9段階の定義

実務で機能するステータス体系の標準は以下のとおりだ。各ステータスには、現在の責任者(次に動かす人)と、滞留閾値(このステータスにとどまってよい目安日数)をセットで定義する。

# ステータス 意味 責任者 滞留閾値(目安)
1 受付済 依頼フォームから案件が登録された状態。法務側はまだ未確認。 法務(受付担当) 1営業日
2 受付確認中 必須項目の充足確認・優先度判定・担当者アサインを行う段階。 法務(受付担当) 1〜2営業日
3 レビュー中 担当者がアサインされ、契約書レビュー・法律相談対応を実施中。 法務(担当者) 3〜5営業日(優先度による)
4 差戻し 必須情報不足・前提確認が必要などの理由で依頼者に差し戻した状態。 依頼者 3営業日(依頼者側で滞留しやすい)
5 修正待ち レビューコメント送付後、依頼者・相手方の対応待ち。 依頼者・相手方 5営業日(外部要因で長期化することあり)
6 承認待ち レビュー完了後、稟議・決裁ルートに回付している段階。 承認者(事業責任者・経営層) 5〜7営業日(決裁ルールによる)
7 締結待ち 稟議承認済。電子契約締結・押印手続中。 営業・購買・契約事務 5営業日
8 完了 締結済・契約書原本/PDF確保・台帳登録済の状態。 法務(台帳担当) 3営業日(クローズ準備期間)
9 クローズ 履歴保存・更新期限設定済の最終状態。それ以降は契約管理側へ移管。 恒常状態
補助ステータス:保留
上記9段階に加え、依頼者都合・取引中断などで一時停止する案件向けに「保留」を補助ステータスとして用意する。保留にする際は、必ず再開条件・再開予定日をコメントに残す。再開条件のない保留は、事実上の案件放棄になる。

② 標準ステータス遷移図

9段階の標準的な遷移は以下のとおり。実線は標準ルート、点線は例外ルートを示す。

受付済 受付確認中 レビュー中 修正待ち 承認待ち
クローズ 完了 締結待ち

※ 例外ルート:受付確認中・レビュー中の各段階で「差戻し」、依頼中断時は「保留」へ分岐可。

③ ステータス更新時に必ず記録する4項目

ステータス変更が発生したら、変更内容だけでなく以下4項目を不可逆に保存する。「いつ・誰が・なぜ・次は誰が動くか」が後から再現できる状態を保つ。

  • 更新日時:ステータス変更が発生した日時。秒単位まで保存。
  • 更新者:誰がステータスを変更したか。法務担当者・依頼者・承認者を区別する。
  • 変更理由・コメント:差戻し時は理由、保留時は再開条件、完了時は最終確認結果を記載。
  • 次の責任者:遷移後にボールを持つ人。「修正待ち」のまま誰のボールか不明な状態を避ける。

④ 滞留検知の標準閾値

各ステータスは滞留閾値を超えた段階で、自動的にエスカレーションされる仕組みを持たせる。アラートは段階的に発する。

段階 通知タイミング 通知先 通知内容
第1段階 滞留閾値の50%経過時点 担当者 注意喚起:「もうすぐ閾値です」
第2段階 滞留閾値到達時点 担当者+上長 催促:「閾値に達しました。状況確認をお願いします」
第3段階 滞留閾値の2倍経過時点 担当者+上長+法務責任者 エスカレーション:「異常滞留です。判断を仰いでください」
注意:依頼者側滞留もカウントする
「修正待ち」「差戻し」「承認待ち」など、ボールが法務以外にあるステータスでも滞留管理は必須だ。「依頼者の都合で止まっています」と言い続けて半年経つケースは、法務部門の管理責任の問題として捉えられる。閾値超過時は、法務側から依頼者・承認者に状況確認の連絡を行う設計にする。

⑤ ダッシュボードで可視化する3指標

ステータスは個別案件で見えるだけでなく、チーム全体の健康状態を示す指標として可視化する。最低限以下3指標を週次でモニタリングする。

  • Aステータス別件数:「レビュー中が25件、修正待ちが18件…」と段階別の現在件数を把握する。特定ステータスに案件が偏っていないか確認する。
  • B滞留案件数:各ステータスの閾値を超えた案件数。閾値超過率が20%を超えると、運用全体の見直しが必要。
  • C平均処理日数:「受付済→クローズ」までの平均日数。契約類型別・優先度別に分解すると、ボトルネックが見える。

なぜこの標準になるのか|法的・実務的な理由

① 業務の透明性確保(属人化防止)

ステータス管理がない法務は、必ず属人化する。担当者本人しか進捗を把握できない状態は、退職・休職・異動の瞬間に案件群が空中分解する。ステータスは「担当者の頭の中の情報を、組織の情報資産に変換する仕組み」であり、ステータス標準化は属人化の構造的な解決策となる。

② 内部統制システム(情報の保存・管理)との整合

会社法362条4項6号は、取締役会の専決事項として「取締役の職務の執行が法令及び定款に適合することを確保するための体制」(内部統制システム)の整備方針決定を定める。これを受けて、会社法施行規則100条1項1号は、内部統制システムの内容として「取締役の職務の執行に係る情報の保存及び管理に関する体制」を整備すべき事項として挙げている

法務案件のステータス・更新履歴は、契約レビュー判断・法的助言・コンプライアンス判断の根拠資料であり、これらは取締役の職務執行に関する情報そのものに含まれる。したがって、ステータス管理は単なる業務効率化にとどまらず、内部統制上の情報保存・管理体制を説明しやすくする実務基盤として位置付けられる

対象会社の範囲
会社法上、内部統制システムの整備が義務付けられるのは、大会社(資本金5億円以上または負債総額200億円以上:会社法2条6号)かつ取締役会設置会社であり、整備内容は取締役会の決議事項とされる(会社法362条5項)。義務化対象外の中小企業でも、業務適正確保・属人化防止の観点から、同様の考え方を取り入れることが実務上有用である。

③ 金融商品取引法上の内部統制報告制度との関係

上場会社等は、金融商品取引法24条の4の4第1項により、財務計算に関する書類等の適正性を確保するために必要な体制(いわゆるJ-SOX)について、内部統制報告書を有価証券報告書とあわせて提出する義務を負う。法務案件のうち、会計影響のある契約(リース・収益認識・関連当事者取引等)のレビューと承認プロセスは、内部統制の評価対象に含まれうる。ステータス・履歴の保存は、監査対応の証跡として機能する。

④ 個人情報保護法(個人データを扱う案件の場合)

法務案件には、相手方代表者・個人事業主の氏名・連絡先など、個人情報・個人データが含まれることが一般的だ。個人情報の保護に関する法律23条は、個人情報取扱事業者に対し「その取り扱う個人データの漏えい、滅失又は毀損の防止その他の個人データの安全管理のために必要かつ適切な措置」を講ずべき義務を定める。ステータス管理システム上の個人データへのアクセス制限・履歴保存も、安全管理措置の一部として設計する必要がある。

監督官庁ガイドライン
個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」では、安全管理措置として「組織的安全管理措置」「人的安全管理措置」「物理的安全管理措置」「技術的安全管理措置」が示されている。ステータス・履歴の保存と権限管理は、組織的安全管理措置・技術的安全管理措置の双方に関係する。

よくある誤解

誤解①:「対応中/完了」の2段階だけで足りる

件数が少ない時期は2段階運用でも回るが、年間100件を超えた段階で、2段階運用では滞留や見落としが発生しやすくなる。「対応中」の中身が見えないため、レビュー中なのか修正待ちなのか承認待ちなのかが分からず、滞留検知が機能しない。2段階運用は法務部門の生産性を継続的に毀損しやすい

誤解②:ステータスは細かいほどよい

20段階・30段階のステータスは、現場が更新を放棄する。「更新されていないステータスは存在しないのと同じ」であり、形骸化したステータスは混乱の原因にしかならない。9段階前後が現場が継続更新できる現実的な上限だ。

誤解③:ステータスは法務部内だけで使えばよい

ステータスを法務部内で閉じて管理すると、依頼者は毎回「進捗どうなってる?」と問い合わせることになる。ステータスは依頼者・承認者にも共有されてはじめて機能する。ただし、機微な内部判断(たとえば契約締結を中止すべきとの法務側の所見)はコメント欄でアクセス権限を分けるなど、共有範囲は設計時に検討する。

誤解④:「保留」は便利なステータスだ

保留は便利だが、安易に使うと案件のブラックホールになる。保留は「再開条件」と「再開予定日」を必ずセットで設定する運用にする。条件未設定の保留は禁止し、再開予定日を過ぎたら自動的に通常ステータスに戻る仕組みが望ましい。

誤解⑤:ステータス更新は担当者の手作業で十分

手作業更新は、忙しい時期に必ず後回しになる。ステータス更新を「業務とは別の作業」にすると、忙しい人ほど更新しない逆相関が発生する。可能な限り、依頼フォーム送信・レビューコメント返信・承認回付などの業務アクションと連動して、ステータスが自動遷移する設計にする。

例外・注意点

例外①:訴訟・行政当局対応案件

訴訟・行政照会・立入検査などの案件は、契約レビューと同じステータス体系では管理できない。別ライン(訴訟管理・当局対応管理)として、独自のステータス体系を併設するのが標準だ。具体的には「事案発生/弁護士選任/訴状送達/答弁書提出/第1回期日/和解協議/判決/確定」など、紛争プロセスに沿ったステータスを設計する。

例外②:M&A・大型プロジェクト

M&A・大型ファイナンス・JV組成などは、契約類型が複数同時並行(NDA/LOI/SPA/株主間契約/DDレポート/法律意見書…)で動く。個別契約ごとにステータスを管理しつつ、プロジェクト全体のフェーズ管理(DD/契約交渉/クロージング/PMI)を別レイヤーで重ねる。両者を混同するとステータスが破綻する。

例外③:継続的な相談(顧問的業務)

「××法に該当しないか定期的に相談を受けたい」など、明確な完了条件のない継続相談は、案件管理ではなくナレッジ管理側に分類する。ステータスは「アクティブ」「アーカイブ」程度の単純化で運用する。

注意点①:ステータス変更権限の設計

「完了」「クローズ」など終局ステータスへの遷移は、依頼者だけで完結させない。法務側のチェック(締結書類の確認・台帳登録の完了確認)を経てから完了とする運用にする。依頼者が「もう契約締結したから完了でいいよね」と勝手に閉じてしまうと、法務側で締結版の確認ができないまま履歴が確定する。

注意点②:履歴の改ざん防止

ステータス更新履歴は追記型(append-only)の設計が望ましい。過去のステータスを後から書き換えできる仕組みは、内部統制・監査対応の観点で問題となる。修正が必要な場合は「訂正履歴」として追記する運用にする。

注意点③:年次棚卸し

長期間「保留」「修正待ち」のままになっている案件は、年1回必ず棚卸しする。1年以上動いていない案件は、原則として「クローズ」または「中止」に分類し直す。棚卸ししないと、不良在庫的な案件が雪だるま式に増え、ダッシュボードのノイズになる。

実務対応フロー|ステータス設計を導入する5ステップ

既存運用にステータス管理を導入する場合、いきなり全面刷新を試みると現場が動かない。段階的な導入が標準だ。以下5ステップで進める。

1
現状の業務フロー棚卸し

現在の依頼受付〜完了までのフローを書き出す。担当者ヒアリングで「どの段階で止まりやすいか」「どこに見えない判断待ちがあるか」を洗い出す。所要:1〜2週間。

2
標準ステータス9段階の社内合意

本記事の9段階をベースに、自社業務に合わせて文言調整・統廃合する。法務部内・主要事業部(営業・購買)と意味のすり合わせを行う。「完了とクローズの違いは何か」を全員が同じ理解にする。所要:2〜4週間。

3
滞留閾値とエスカレーションルールの設定

各ステータスの滞留日数閾値を定める。最初は緩めに設定し、運用しながら調整する。エスカレーション通知先(担当者・上長・法務責任者)も明文化する。所要:1〜2週間。

4
運用ツールの選定・設定

ExcelからJiraやAsana、専用ツールへ移行するかを判断する。件数100件超/担当2名以上/監査対応が必要な場合は、専用ツール導入を検討する。ステータス更新が業務アクションと連動する設計を優先する。所要:1〜2か月。

5
運用開始・週次モニタリング・四半期見直し

運用開始後、週次でダッシュボード(ステータス別件数・滞留件数・平均処理日数)をモニタリングする。四半期ごとに閾値・ステータス定義の見直しを行い、現場負荷と可視化のバランスを調整する。所要:継続。

社内共有用ルール例|コピペで使えるステータス定義

以下は社内規程・運用マニュアルにそのまま貼り付けて使える短文版ルールだ。チャットツールにピン留めする運用を推奨する。

① ステータス定義表(社内共有用)

> コピペ用|社内ポータル / 規程 / Slackピン留め用
━━━━━━━━━━━━━━━━━━ 法務案件ステータス定義(標準9段階) ━━━━━━━━━━━━━━━━━━ 【1】受付済 定義:依頼フォームから案件登録された状態 責任者:法務(受付担当) 滞留閾値:1営業日以内に確認 【2】受付確認中 定義:必須項目確認・優先度判定・担当者アサイン中 責任者:法務(受付担当) 滞留閾値:1〜2営業日 【3】レビュー中 定義:担当者が契約レビュー・法律相談対応中 責任者:法務(担当者) 滞留閾値:3〜5営業日(優先度による) 【4】差戻し 定義:必須情報不足等で依頼者へ差し戻した状態 責任者:依頼者 滞留閾値:3営業日(依頼者の追加情報提供待ち) 【5】修正待ち 定義:レビューコメント送付後、依頼者・相手方の対応待ち 責任者:依頼者・相手方 滞留閾値:5営業日 【6】承認待ち 定義:レビュー完了。稟議・決裁ルートに回付中 責任者:承認者(事業責任者・経営層) 滞留閾値:5〜7営業日 【7】締結待ち 定義:稟議承認済。電子契約締結・押印手続中 責任者:営業・購買・契約事務 滞留閾値:5営業日 【8】完了 定義:締結済・契約書原本/PDF確保・台帳登録済 責任者:法務(台帳担当) 滞留閾値:3営業日(クローズ準備) 【9】クローズ 定義:履歴保存・更新期限設定済の最終状態 以降は契約管理側へ移管 【補助】保留 定義:依頼者都合・取引中断による一時停止 責任者:依頼者 ルール:再開条件・再開予定日を必須記載 ━━━━━━━━━━━━━━━━━━ 法務部 ステータス管理ルール ━━━━━━━━━━━━━━━━━━

② チャット共有用ステータス略号(短縮版)

> コピペ用|Slack/Teamsチャネルのトピック・説明文
📋 法務案件ステータス(標準9段階) 受付済 → 受付確認中 → レビュー中 → 差戻し → [5] 修正待ち → [6] 承認待ち → [7] 締結待ち → [8] 完了 → [9] クローズ 🔸 補助:[保留] 再開条件・予定日必須 ⏱ 滞留閾値超過:自動エスカレーション 🔍 進捗確認:法務ダッシュボード(URL)

③ ステータス更新時の記録テンプレ

> コピペ用|ステータス更新時のコメント欄記載ルール
[更新日時]:YYYY/MM/DD HH:MM [更新者]:所属/氏名 [変更前ステータス]:(前のステータス) [変更後ステータス]:(新しいステータス) [変更理由・コメント]:  ・差戻しの場合:不足情報の具体的内容  ・保留の場合:再開条件・再開予定日  ・完了の場合:締結書類の最終確認結果 [次の責任者]:所属/氏名(または「依頼者」「承認者」等)

④ 依頼者向けステータス問い合わせ自動返信文例

> コピペ用|依頼者からの「進捗どうなってる?」への返信定型
○○様 ご依頼の進捗確認、ありがとうございます。 現在のステータス:「(ステータス名)」 最終更新日:YYYY/MM/DD 現在の責任者:(担当者名/依頼者/承認者) 想定完了時期:YYYY/MM/DD前後 なお、案件の最新ステータスは法務ダッシュボード (URL)からいつでもご確認いただけます。 ご不明点があれば本メールにご返信ください。 法務部 ○○

この標準に従わないリスク

ステータス管理を整備しない、あるいは「あるが運用されていない」状態を放置することのリスクは、法務部門の生産性低下にとどまらない。会社全体のガバナンス・コンプライアンス・監査対応にまで波及する。

リスク①:案件失念による契約事故

⚠ 起きること
「修正待ち」のまま3か月放置されていた契約が、相手方からの督促で初めて発覚する。期限を過ぎて締結すると、契約開始日の遡及・割増単価の発生・取引機会の喪失など、直接的な経済損害が生じる。

リスク②:引継ぎ不能による組織知の損失

⚠ 起きること
担当者が退職・休職した瞬間に、進行中案件の状況・交渉経緯・判断根拠が空中分解する。引継ぎ書類を作成する時間もなく、後任は「最初から確認のし直し」になる。営業部門との信頼関係も同時に毀損する。

リスク③:監査対応・内部統制評価での指摘

⚠ 起きること
上場会社等の場合、内部監査・監査役監査・会計監査人監査において「重要な業務執行に係る情報の保存・管理体制」が論点となる。ステータス・履歴管理が機能していないと、内部統制の不備として指摘される可能性がある。是正勧告を受けると、内部統制報告書の記載や監査意見にも影響が及びうる。

リスク④:滞留案件のブラックボックス化

⚠ 起きること
「保留」「差戻し」「修正待ち」のまま長期間放置された案件群が積み上がり、誰も全体像を把握できなくなる。年度末・期末の棚卸しで急に大量の長期滞留案件が発覚し、対応リソースが枯渇する。

リスク⑤:個人データの管理不備

⚠ 起きること
個人データを含む案件のアクセス履歴が残っていないと、漏えい時の調査・本人通知・個人情報保護委員会への報告(個人情報保護法26条)対応に支障が生じる。「誰が、いつ、何を見たか」が再現できない状態は、安全管理措置の不備として整理されうる。

リスク⑥:法務部門への信頼喪失

⚠ 起きること
「法務に依頼してもいつ返ってくるか分からない」「進捗を聞いても要領を得ない」状態が常態化すると、事業部は法務を経由しない非公式ルート(SlackのDM・口頭依頼・直接外部弁護士へ依頼)に流れる。これは、契約の事前審査機能の崩壊につながる。

まとめ|ステータス管理は「業務効率化」ではなく「内部統制」

法務案件のステータス管理は、単なる業務効率化のツールではない。会社法施行規則100条1項1号の「情報の保存・管理体制」の一環として、組織の業務適正確保に資する内部統制機能である。ポイントは以下5点に整理される。

  • 標準9段階(受付済/受付確認中/レビュー中/差戻し/修正待ち/承認待ち/締結待ち/完了/クローズ)で設計する
  • 各ステータスに 「責任者」と「滞留閾値」 をセットで紐付ける
  • ステータス更新時は 「日時・更新者・理由・次の責任者」 の4項目を不可逆に保存する
  • 滞留閾値超過時は段階的にエスカレーションする。「気付いたら2週間止まっていた」を構造的に防ぐ
  • 履歴は追記型・改ざん防止設計とし、内部統制・監査対応の証跡として位置付ける

ステータス設計は「法務担当者の生産性向上」が表の目的だが、その本質は属人化の解体・監査証跡の確保・組織知の蓄積にある。ステータス管理が崩れている法務部門は、件数増加・担当者交代の局面で必ず破綻する。逆に言えば、ステータスが機能している法務部門は、人員規模に対して相当な処理能力を発揮できる。

実務運用に落とし込む

本記事のステータス標準は、受付フォーム・優先度判定・滞留検知・履歴保存をセットで運用しなければ機能しない。Excel・メール・チャットに分散したまま運用すると、ステータスは更新されず、滞留も検知されない。

▼ 法務オペレーションを標準化する

LegalOS Inbox|法務案件のステータス・履歴を一元管理

LegalOS Inboxは、本記事で整理した「9段階ステータス・滞留検知・履歴保存・ダッシュボード可視化」をひとまとめに運用するための法務専用Inboxです。第1話「受付票」、第2話「優先順位ルール」、第3話「依頼メール管理」と本記事「ステータス管理」をそのまま実装に落とし込めます。

LegalOS Inboxの詳細を見る →

法務実務スタンダード20選|シリーズ一覧

本記事は、法務実務の「標準ライン」を20の論点で整理するシリーズの第4話です。受付・案件管理・契約レビュー・社内ガバナンスまでを通しで設計するためのリファレンスとしてご活用ください。

第1話
法務相談受付票はどう作るべきか|実務で使われる標準項目
論点:受付段階の必須項目/情報不足の差戻し基準/受付テンプレート
第2話
法務案件はどう優先順位を付けるべきか|実務標準の判断基準
論点:4軸判定/P0〜P3の4段階/会社法362条4項との整合
第3話
法務依頼メールはどう整理すべきか|実務で崩れない管理基準
論点:件名ルール/添付管理/案件化基準/履歴保存
第4話
法務案件のステータスはどう設計すべきか|実務標準フロー(本記事)
論点:9段階標準ステータス/滞留検知/履歴保存/会社法施行規則100条との整合
第5話
法務資料はどう整理すべきか|実務で崩れない添付管理基準
論点:用途別整理/アクセス管理/属人化防止
第6話
契約と稟議はどう連携すべきか|実務で採用される標準設計
論点:契約審査と決裁プロセスの接続/承認漏れ防止
第7話以降
決裁権限規程/取締役会付議基準/関連当事者取引/子会社管理/NDA省略基準/契約レビューSLA/契約保管 ほか(順次公開)
受付・案件管理から契約ガバナンス・社内統制まで、20論点を順次整理します。
本記事の参考法令・ガイドライン
・会社法362条4項6号(取締役会専決事項としての内部統制システム整備方針決定)
・会社法362条5項(大会社における内部統制整備義務)
・会社法施行規則100条1項1号(取締役の職務執行に係る情報の保存・管理に関する体制)
・金融商品取引法24条の4の4第1項(内部統制報告書)
・個人情報の保護に関する法律23条(安全管理措置)/同法26条(漏えい等の報告等)
・個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」

※本記事は2026年5月時点の法令・ガイドラインに基づいて執筆しています。本記事は一般的な情報提供を目的とするものであり、個別案件に対する法的助言を構成するものではありません。具体的な対応は、自社の実務状況と最新の法令・実務動向を踏まえてご検討ください。