社労士事務所の中で「過去5年分の労務相談メールや議事録を全部AIで検索できるようにしたい」という要望が出てくる場面があります。新規の相談が入ったときに、似た過去案件を一発で引き出したい、ジュニアの方も過去事例にアクセスできるようにしたい、という流れです。
業務効率の観点だけで見れば、自然な発想です。ハラスメント相談、退職勧奨、未払賃金、労災判断といった対応の蓄積こそが、社労士事務所の競争力の源にもなっています。検索性が上がれば、引き継ぎや育成にかかる時間も短くなります。
ただ、労務相談の履歴は「業務文書」というよりも「機密情報の塊」に近い場面があります。会社別の労務トラブルの生データ、職員の方の健康情報、家庭事情、懲戒の対象になった行為など、性質の異なる情報が同じフォルダの中に混ざっていることが多いです。検索のしくみを先に組んでしまうと、後から分類や権限の整理をやり直す巻き戻しが発生しやすくなります。本稿では、検索のしくみに着手する前に、業務の流れの中で先に決めておきたい論点を順番にご紹介します。
履歴の中に何が含まれているかを棚卸ししておく
最初に置いておきたいのが、自所の労務相談履歴に「何が含まれているか」の棚卸しです。多くの事務所では、メール、Slack、議事録、顧問先別フォルダの中に、性質の異なる情報が混ざっています。
- 会社を特定できる情報（社名、部署構成、売上規模、経営者の意向）
- 職員の方の個人情報（氏名、年齢、役職、雇用形態、給与）
- 要配慮個人情報の候補（病歴、健康診断結果、診療記録、障害情報、犯罪経歴、思想信条）
- 労務トラブルの生データ（ハラスメントの加害者・被害者名、退職勧奨の経緯、懲戒事由、未払賃金の金額交渉）
- 判断にかかる機微（経営者の本音、退職勧奨のシナリオ、訴訟の内部評価）
このうち病歴、健康診断結果、障害情報などは、個人情報保護法上の「要配慮個人情報」に該当します。要配慮個人情報については、本人の同意なしでの取得が原則として認められておらず、第三者提供についてオプトアウト方式も使えない取扱いになっています（個人情報保護委員会のガイドライン）。
つまり、労務相談の履歴をAIで検索できるようにする取り組みは、業務文書のインデックス化というより、要配慮個人情報を含む情報を新しい技術スタックに載せ替える話に近くなります。検索化のメリット（類似事例の即時参照、ジュニアの方の育成期間の短縮、顧問先別の対応傾向の可視化、引き継ぎ時の属人化の低減）と、社労士法21条の守秘義務、個人情報保護法上の安全管理措置や委託先監督義務、要配慮個人情報の取扱いとが、同じ場面で同時に立ち上がります。
文書を三つの観点で分類してから載せる
技術的な構築の前に、既存文書を三つの観点で分類しておく事務所もあります。これを後回しにすると、権限制御を後付けで足すのが難しくなる場面が出てきます。
会社別のタグ
顧問先ごとに一意のテナントIDを振り、全文書にメタデータとして付けます。検索時はテナントIDでフィルタリングし、会社をまたいだ横断検索が物理的に起きない設計にしておく流れです。
案件種別のタグ
労務相談、就業規則改定、労使紛争、懲戒、労災、ハラスメント、退職勧奨、といった区分です。種別ごとに、外部のAIに送信してよいか、要配慮個人情報を含みやすいか、が変わってきます。
機密度のラベル
たとえば次のような区分を使っている事務所もあります。
- L1（公開可）: 一般的な労務知識、公的指針の引用
- L2（社内共有）: 顧問先名などを伏せた上で共有可。伏せ方が十分かは、業種・地域・時期の組み合わせから特定されないかを個別に確認する
- L3（案件担当者のみ）: 個人特定情報を含む
- L4（要配慮個人情報含む）: 病歴、懲戒、思想信条を含む。外部のAI送信は原則として避ける
L4については、外部のクラウドLLM APIに送らない設計を最初から組んでおく事務所もあります。技術的な制約というより、社労士法と個人情報保護法の側から逆算した境界線として置いておく形です。
権限の設計は、「どの方が」「どの会社の」「どの機密度まで」見られるかを、業務の役割と並べて整理しておきます。
| ロール | 自所メンバー | A社担当 | A社L1-L3 | A社L4 | B社 |
|---|---|---|---|---|---|
| 所長 | ◯ | ◯ | ◯ | ◯ | ◯ |
| シニア社労士（A社主担当） | ◯ | ◯ | ◯ | ◯ | × |
| ジュニア社労士（A社副担当） | ◯ | ◯ | L1-L3のみ | × | × |
| 事務スタッフ | ◯ | △ | L1のみ | × | × |
| 外部委託（記帳代行など） | × | × | × | × | × |
ベクトルDB側でこのフィルタが効くか、検索時にロール情報がメタデータと突き合わされるか、ログが残るか、の三点を実際に検証しておく流れです。「ひとまず全員フルアクセスで始めて、後から絞る」という運用は、最初の混線が起きるまで気づきにくいので、避けている事務所もあります。
保管と通信と送信先で、それぞれ別に決めておく
データの状態（保管中・通信中・利用中）ごとに、扱い方を決めておきます。
- 保管中の暗号化: ベクトルDB、オリジナルの文書ストア、バックアップを暗号化します。鍵を所内で管理するか、KMSを使うか、設計時に決めておく形です
- 通信中の暗号化: TLSは前提として、APIキーやトークンの取扱い、所内Wi-Fi経由のアクセス制限まで含めて決めておきます
- 利用中の取扱い: クラウドLLM APIに送信した時点で、ベンダー側でログ保管や学習利用の対象になる可能性があります。各ベンダー（OpenAI、Anthropic、Googleなど）の利用規約や契約書面は随時更新されるため、導入を検討する時点の最新版で、「API経由のデータが学習に使われるか」「ログ保管期間はどれだけか」を確認しておきます
- 削除: 顧問契約の終了時や、本人からの削除請求時に、ベクトルDB、キャッシュ、LLM側のログから消える設計になっているかを確認しておきます。論理削除のみだと、RAG検索で再ヒットする場面が出てきます
LLM APIのデータの取扱いは、エンタープライズプランと無料・標準プランで条件が大きく違うことがあります。標準プランのまま顧問先データを送信していて、後から顧問先からのお問い合わせを受ける、といった場面もあります。
法令・契約の観点で並べると、次のような項目を業務の中に置いておく流れになります。
- 個人情報保護法: 利用目的の特定・通知、第三者提供の同意、委託先の監督、安全管理措置（組織的・人的・物理的・技術的）
- 社労士法: 守秘義務（21条）。AIへの送信が「漏えい」に該当しないと言える設計と契約になっているか
- 顧問契約上の取扱い: 既存契約書に「AIへの送信」「機械学習への利用」の同意・通知に関する条項があるか
- 要配慮個人情報の取扱い: 取得・利用の同意、目的外利用の制限、第三者提供のオプトアウト不可
- 委託先（AIベンダー）の安全管理水準: ガイドライン上、委託先には委託元と同等の安全管理措置が求められます。SOC2、ISO27001、国内データセンター利用の有無などを確認しておきます
業務効率化のためのツール導入と、個人情報処理の委託契約とは、法的には別物として扱う場面が出てきます。
所内で進めやすい範囲と、外の知見を借りる範囲を分ける
事務所内部で進めやすい範囲と、外部の知見を借りる範囲を、最初に分けておく事務所もあります。
所内で進めやすい範囲としては、たとえば次のような取り組みがあります。
- L1（公開可）レベルの一般労務知識のAI検索化
- 顧問先名を完全に匿名化したナレッジベースの構築
- ローカルLLM（所内サーバ完結型）での実験
- AIベンダーの利用規約・データ取扱い規定の読み込みと比較
外の知見を借りる範囲としては、次のような場面が出てきます。
- L3・L4を含む実データのRAG化の設計
- 顧問契約書のAI利用条項の改定
- アクセス権限・監査ログ基盤の設計と実装
- ベンダー選定や契約交渉（特にエンタープライズ契約のSLA、データ取扱条項）
- 漏えいが起きた場合の対応体制の設計
業務に伴走する役割としては、士業の業務知識と情報設計の両方を踏まえる立場の方が入ることが多いです。所内のIT担当の方だけで完結させると、責任の分かれ目が曖昧になりやすい場面もあります。
着手後につまずきやすいところ
労務相談の検索化に着手すると、「ここで止まった」「ここで作り直しになった」という場面が多く出てきます。設計の最初に意識しておくと、巻き戻しを抑えやすくなります。
1.棚卸しを飛ばして、ベクトル化から始めてしまう。既存文書に要配慮個人情報が混ざっていたことに、検索化の後で気づく場面があります。L4を含んだまま外部APIに送ってしまうと、「送らなかったことにする」処理は難しくなります。最初に棚卸しとL1〜L4のラベリングを終えておく流れです 2.会社別のテナント分離を、メタデータの任意項目にしてしまう。必須ではない実装にしておくと、抜けがあるレコードが横断検索に出てきます。テナントIDは必須・空値禁止・後からの修正は禁止、で実装している事務所もあります 3.顧問契約書のAI利用条項を後回しにする。動作確認の後で同意条項を整備しようとすると、既存の顧問先全件への再同意のお願いが発生します。検索化に先立って、契約書テンプレートの改定と通知計画を立てておく流れです 4.エンタープライズ契約のSLAの確認を、営業窓口任せにする。「学習には使いません」という口頭のご説明と、契約書面の条項とで内容が違うことがあります。契約条項、データ処理付録（DPA）、サブプロセッサ一覧を書面で取得して、所内で保管しておきます 5.削除フローを「論理削除」だけで済ませる。RAG検索のインデックス、キャッシュ、LLM側のログから本当に消えているかを、削除後の検索で確認する手順を業務の中に置いておきます 6.インシデント対応を「起きてから考える」にする。誤投入や誤共有が起きたときの連絡経路、本人通知の判断、個人情報保護委員会への報告の要否を、設計の段階で文書化しておく事務所もあります
「便利だから入れる」より先に、「分類・権限・暗号化・契約・削除を業務の流れに置いてから入れる」順序を踏むことで、AIを業務に組み込む取り組みと、士業の守秘義務とが両立しやすくなる場面が増えます。検索性のしくみよりも先に、要配慮個人情報の分類、会社別のテナント分離、L4の送信境界、顧問契約上の同意条項、の四点を業務の中に置いておく流れをご紹介しました。