2026.08.28 業務システム

法律事務所の顧客管理：依頼者情報の項目設計と権限分離の判断基準

一般的な顧客管理の製品を法律事務所に入れると、機能が足りないという形ではなく、前提が合わないという形で行き詰まります。相談だけで終わった相手の情報を失注として閉じられない。依頼者と相手方が同じ一覧に並んでしまう。紹介元の記録欄が営業成果の集計を前提に作られている。どれも製品の不備ではなく、事業会社向けに設計された枠組みを士業の要件に当てはめたときに生じるずれです。

この記事では、法律事務所が相談者と依頼者の情報をどの項目として持ち、誰にどこまで見せるかを決めるための判断基準を、受託開発の側から整理します。製品のランキングは扱いません。顧客管理そのものの定義と、表計算から移すべきかどうかの一般的な判断基準は顧客管理システムとは？機能・Excelとの違い・脱Excelの判断基準を解説で扱っているため、ここでは法律事務所固有の要件に絞ります。

まとめ：法律事務所の顧客管理は照合の母集団と要配慮情報から決める

先に結論を置きます。項目設計と権限設計を次の順序で決めると、製品選定の議論が空回りしません。

削除と失注クローズを前提にしない。相談のみで終わった相手も利益相反の照合対象として残り続けるため、「失注したら閉じる」「不要になったら消す」という運用をそのまま持ち込むと照合に穴が空きます。
要配慮個人情報が同居する前提で項目を作る。依頼者情報には病歴、犯罪の経歴、犯罪により害を被った事実が構造的に混ざる。取得の経路と同意の有無を記録できる欄を、後付けではなく最初から用意します。
紹介元は営業指標ではなく説明の備えとして記録する。弁護士職務基本規程13条が紹介の対価の授受を双方向で禁じているため、紹介元欄の意味が事業会社とは逆になります。
相手方の閲覧範囲を依頼者と別の軸として切り出す。同じ顧客テーブルに同居させたまま権限だけで制御すると、検索結果や候補表示から情報が漏れます。
既製品のままでよいのは取扱分野が単一で所属人数が一桁の段階まで。照合索引の独立と権限の細分化が要る段階に入ったら、その2点に絞って作り込む。会計と電子提出の法令対応まで自前で抱える計画は見送ります。

なお、利益相反の照合対象が4系統に分かれるという構造そのものと、照合索引を事務所システムの独立要素として持つかどうかという構成判断は、法律事務所のシステムとは？6領域の全体像と既製品／受託開発の判断基準で扱っています。本記事は、その母集団をどの項目として持ち、誰に見せるかという実装側の話に限定します。

一般的な顧客管理製品の項目設計が法律事務所で成立しない3つの理由

事業会社向けの顧客管理は、見込み客を獲得して顧客に転換し、取引を継続させるという流れを前提に設計されています。法律事務所の依頼者情報は、この流れのどこにも素直には乗りません。ずれは主に3か所で表面化します。

相談だけで終わった相手を消せず失注として閉じられないデータ構造

事業会社向けの製品では、商談に至らなかった見込み客は失注として閉じ、一定期間が過ぎたら論理削除または物理削除の対象になります。データ量を抑え、営業の対象リストを絞るための設計です。

法律事務所では同じ扱いができません。弁護士職務基本規程27条は、相手方の協議を受けて賛助した事件や、協議の程度・方法が信頼関係に基づくと認められる事件について、職務を行い得ないと定めています。つまり受任に至らなかった相談であっても、その相手方の情報は将来の照合対象として残します。相談から数年後に、その相談者の相手方となる依頼を受ける可能性があるからです。

この違いは、画面の見え方より先にデータ構造に効きます。相談記録を営業パイプラインの一段目として持つと、パイプラインを整理するたびに照合母集団が削られていく。相談の受付記録と照合のための最小項目を別に持ち、後者は受任の有無と切り離して残す構造が必要です。初回相談の枠取りや受付側の運用設計については士業の予約システムとは？初回相談の枠設計と利益相反チェックを止めない選び方が扱っています。

受任の前と後で同じ項目の意味が変わる二段構えの登録フォーム設計

受任前と受任後では、同じ「氏名」「連絡先」という項目でも、記録として担う役割が変わります。受任前は照合のための識別情報であり、正確さより網羅性が要ります。同姓同名や旧姓、法人名の表記ゆれを含めて拾えることが照合の精度につながるからです。受任後は委任契約と請求に紐づく情報になり、こちらは網羅性より正確さと更新履歴が求められます。職務基本規程30条は、受任にあたり弁護士報酬に関する事項を含む委任契約書の作成を定めており、契約に紐づく情報はここで確定します。

一般的な顧客管理では、見込み客と顧客を同じレコードで扱い、ステータスだけを切り替える設計が主流です。これを採ると、受任前に網羅性のために入れた表記ゆれが、そのまま請求先の情報として引き継がれる。逆に受任時に情報を整えると、照合に使っていた旧い表記が上書きされて消えます。照合用の記録と契約用の記録を分けて持ち、後者から前者を参照する形にすると、この上書きが起きません。

相手方の情報が依頼者と同じテーブルに同居してしまう構造の問題

3つ目のずれは相手方の扱いです。事件には必ず相手方がいて、その氏名や連絡先は照合のために記録します。ところが相手方は顧客ではありません。事業会社向けの製品には「取引先ではないが記録しておく人物」という枠がないため、顧客テーブルに同居させる運用になりがちです。

同居させた場合、権限設定で閲覧を絞っても情報は漏れます。顧客の検索候補、入力補完、宛先の選択リスト、集計の件数といった経路から、相手方として登録された人物の存在が見えてしまうためです。職務基本規程56条は、共同事務所の所属弁護士が他の所属弁護士の依頼者について執務上知り得た秘密を漏らすことも利用することも禁じている。相手方も同じ水準で扱う前提に立つなら、同居させて隠すのではなく、最初から別の入れ物に置く設計が素直です。事件そのものの管理機能との役割分担は案件管理システムとは？機能・SFA・プロジェクト管理との違いと選び方・開発判断で整理しています。弁護士業務に即した事件記録と期日の持ち方は弁護士の案件管理システムの設計基準を参照してください。

依頼者情報に要配慮個人情報が構造的に同居する前提と項目への影響

法律事務所の顧客管理で事業会社との差が最も大きく出るのは、情報の性質です。取り扱う情報の一部は、個人情報保護法が要配慮個人情報として名指しする項目に、事件類型によって自動的に該当します。

病歴と犯罪の経歴が依頼者情報に並ぶ事件類型と登録時の取り扱い

個人情報保護法2条3項と同法施行令2条は、要配慮個人情報として、人種、信条、社会的身分、病歴、犯罪の経歴、犯罪により害を被った事実、身体障害・知的障害・精神障害等の心身の機能の障害、健康診断等の検査結果、医師等による指導・診療・調剤の履歴、刑事事件手続の対象となった事実、少年の保護事件手続の対象となった事実を挙げています（2026年8月時点、個人情報保護委員会のガイドライン通則編で確認）。

この列挙を法律事務所の取扱分野に重ねると、次のように対応します。

事件類型	同居しやすい要配慮項目	記録される場所
刑事弁護	犯罪の経歴	依頼者の基本情報
交通事故・損害賠償	病歴、診療の履歴	相談時のメモ、証拠
犯罪被害者の支援	害を被った事実	相談記録、受任経路
労働・障害年金	病歴、機能の障害	相談記録、添付資料
少年事件	保護事件手続の事実	依頼者と関係者の情報

注意したいのは、これらが添付ファイルの中だけでなく、顧客管理の基本情報や相談メモという検索対象の欄に入り込む点です。刑事弁護を扱う事務所では、依頼者を登録した時点で犯罪の経歴に触れる記録が生まれる。事業会社向けの製品を前提にすると、この情報が全職員の検索対象になっている状態が既定値になります。

取得の同意と取得経路を項目として持たせる設計と例外規定の線引き

同法20条2項は、あらかじめ本人の同意を得ないで要配慮個人情報を取得してはならないと定めています。ただし例外が限定列挙されており、法令に基づく場合、人の生命・身体・財産の保護のために緊急に必要な場合などが並ぶ。事件処理のための取得がすべて本人同意を要するとは限らず、どの例外に当たるかは場面ごとの判断です。

設計上の含意は、その判断を後から説明できる状態にしておくことです。どの経路で誰から取得したのか、本人からか第三者からか、同意を得たのか例外に依拠したのかを項目として持たせる。具体的には、相談記録に「情報の提供元」と「同意取得の有無」を選択式で持ち、依頼者本人・関係者・官公署・相手方といった区分を選べるようにします。自由記述のメモに紛れ込ませると、後から件数を数えられません。

ここを既製品の自由記述欄で済ませるか、選択式の項目として持つかは、事務所の規模ではなく取扱分野で決まります。刑事、交通事故、労働、少年事件のいずれかを常時扱うなら、選択式で持つ側に寄せます。

適用除外の列挙に弁護士の業務が並んでいない前提から決まる範囲

同法57条1項が適用除外として列挙しているのは、報道機関の報道目的、著述を業として行う者の著述目的、宗教団体の宗教活動目的、政治団体の政治活動目的です。主体と目的の二重の要件で構成されており、弁護士の業務はこの列挙に含まれていません（学術研究機関は別に規定）。

したがって、要配慮個人情報の取得に関する規定は、事務所が持つ依頼者情報にもかかる前提で設計します。守秘義務があるから個人情報保護法の枠組みは別、という切り分けは成り立たない。職務基本規程が要求する記録と、同法が要求する説明可能性が、同じ顧客管理の上に二重にかかると捉えると設計を誤りません。

紹介元の記録が営業管理ではなく説明の備えとして必要になる理由

ここが、一般的な顧客管理をそのまま持ち込んだときに最も見落とされる論点です。

職務基本規程13条が禁じる対価と紹介元欄の設計思想が衝突する点

弁護士職務基本規程13条1項は「弁護士は、依頼者の紹介を受けたことに対する謝礼その他の対価を支払ってはならない」と定め、同条2項は「弁護士は、依頼者の紹介をしたことに対する謝礼その他の対価を受け取ってはならない」と定めています（2026年8月時点で確認）。紹介の対価の授受が、支払う側と受け取る側の双方向で禁じられている構造です。

一方、事業会社向けの顧客管理が持つ紹介元、リードソース、流入経路といった項目は、成果に応じた費用の配分を計算するために設計されています。紹介経由の成約に紹介手数料を割り当てる、パートナーごとの成約率を出して報酬料率を見直す、といった使い方が既定の想定です。集計の出口が報酬計算につながっている点が、規程13条の禁止と正面から衝突します。

実害は2段階で出ます。まず、紹介元ごとの成約金額を集計するダッシュボードが標準機能として付いてくるため、事務所の内部にその数字が残る。次に、パートナー管理を有効にすると、紹介者への支払いのレコードを作れる状態になります。機能を使わなければよいという運用回避は、担当者の交代で崩れます。

紹介元を経路の別と対価の有無に分けて記録するための項目の設計

では紹介元を記録しないほうがよいのか、という話にはなりません。むしろ記録します。理由が事業会社と違うだけです。目的は、対価を伴わない紹介であったことを後から示せる状態を保つこと、そして紹介元が既存の依頼者や顧問先であった場合に照合の手がかりになることです。

この目的に合わせるなら、項目は次のように分けます。

経路の別を選択式で持つ。既存依頼者、顧問先、他士業、弁護士会の相談窓口、自社サイト、広告、その他といった区分にします。金額や成約率と結びつく項目にはしません。
対価の有無を独立した欄として持つ。原則は「なし」が既定値で、有償の広告掲載など対価が発生する経路については、それが紹介の対価ではなく広告費であることを区別できる区分値を置きます。
紹介元の実体への参照を持つ。紹介元が既存の依頼者や顧問先である場合、その顧客レコードへの参照を張ります。照合のときに紹介の連鎖を追えるようにするためです。
集計の出口を切る。紹介元別の売上集計、成約率ランキング、パートナー報酬の計算機能は、設定で無効にするだけでなく導入時に落とします。

既製品を使う場合、この4点目が判断の分かれ目になります。紹介元と金額の集計を切り離せない製品なら、その項目は使わず別の枠として持つ。カスタマイズで対応する場合も、集計画面を消すだけでなく、紹介元の項目を売上情報と別のテーブルに置くと運用で崩れません。

守秘と共有を両立させるアクセス権限の分離設計と参照ログの範囲

権限設計は、役職に応じた強弱をつける話として語られがちですが、法律事務所では軸が2本あります。1本は事件への関与、もう1本は情報の立場、つまり依頼者側か相手方側かという区別です。

相手方の閲覧範囲を依頼者情報と別の権限として切り出す判断基準

関与という軸だけで権限を作ると、担当外の弁護士や事務職員から事件が見えなくなり、照合ができなくなります。逆に照合のために全員へ開くと、職務基本規程56条が禁じる範囲に触れかねません。この矛盾は、照合に必要な情報の粒度を落とすことで解けます。

照合に要るのは、その氏名が事務所のどこかに登録されているかという事実と、判断できる担当者への連絡先です。事件の内容、書面、相談メモの本文までは要りません。そこで照合のための索引と事件の中身を持つ記録を別の権限で扱い、索引は事務所全体に開き、中身は関与者に絞ります。

相手方にも同じ考え方を当てます。索引には載せますが、依頼者と同じ画面には出しません。検索結果には「登録あり／担当は誰か」だけを返し、依頼者か相手方かという立場は、照合の判断が必要になった時点で担当者間で確認する運用にします。この索引を事務所システムの独立した要素として持つかどうかという構成上の判断は、法律事務所のシステムとは？6領域の全体像と既製品／受託開発の判断基準の側で扱っています。

参照ログを残すべき操作の範囲と保持期間を決めるときの3つの基準

ログは全操作を残せば安全という性質のものではありません。量が増えると調査に使えなくなり、ログ自体が要配慮個人情報を含む二次的な記録になります。残す範囲は3つの基準で決めます。

第一に、権限の境界を越えた参照。索引の検索、担当外の事件の閲覧、相手方情報の参照が該当します。第二に、外部へ出る操作、つまりダウンロード、印刷、メール送信、外部共有リンクの発行。第三に、権限そのものの変更です。誰が誰にどの範囲を開いたかという記録は、後から経緯を追う唯一の手がかりになります。

逆に、担当事件の通常の閲覧や画面遷移は残さなくても差し支えありません。保持期間を事務所の記録の保存年限より短くすると、照会を受けたときにログ側が先に消えている状態が生まれる。事件記録の保存年限に合わせるか、それより長く取るのが無難です。

表計算による顧客管理が限界に達する4つの兆候と移行の着手順序

移すべきかどうかの一般的な判断基準は顧客管理システムとは？機能・Excelとの違い・脱Excelの判断基準を解説で扱っているため、ここでは法律事務所に固有の兆候と、着手の順序だけを示します。

照合の抜けと二重登録から表計算の限界を判定するための4つの兆候

次の4つのうち2つが当てはまったら、表計算での運用は限界に達しています。

照合のファイルが複数ある。受任事件の一覧、相談受付の記録、顧問先の名簿が別ファイルで、照合のたびに3つ以上を開いている。開き忘れが照合の抜けに直結します。
同一人物が別表記で複数行ある。旧姓、法人の略称、フリガナの有無で行が分かれ、どれが同一人物かを担当者の記憶で判断している状態です。
相談のみで終わった記録が消えている。年度でファイルを切り替えた結果、過去の相談者が照合対象から落ちている状態です。
ファイルが担当者の端末や個別のフォルダにある。誰がどの版を持っているか分からず、参照の記録も残りません。

移行の着手は名寄せ規則の確定からで履歴の移し替えは後ろに回す

移行で失敗しやすいのは、製品を決めて既存データを流し込むところから始める進め方です。名寄せの規則が決まらないまま取り込むと、二重登録がそのまま新しい入れ物に移る。着手の順序は次のとおりです。

最初に名寄せの規則を文章として確定させます。同一人物と判定する条件、旧姓と現姓の持ち方、法人の表記の正規化、同姓同名を区別する情報を何にするかを決める。次に照合の索引に載せる最小項目を固め、ここまで決まってから製品を選びます。既存データの取り込みは、まず索引だけを移し、事件の履歴と添付資料は後ろに回す。索引が動けば照合は止まらず、履歴の移し替えは時間をかけられます。

顧客管理を既製品で賄える条件とカスタマイズが必要な領域の境界

最後に判断を言い切ります。ここまでの要件をすべて作り込む必要はありません。作り込む価値がある領域は限られています。

既製品のまま運用してよい条件は分野の単一性と所属人数の少なさ

取扱分野が実質的に単一で、所属弁護士が一桁、事務職員を含めて十数名までの事務所であれば、士業向けの既製品をそのまま使って差し支えありません。照合の母集団が全員の視界に入る規模であり、権限を細かく分けても守秘の実効性はほとんど上がらないためです。選定の基準は、照合の索引を全文検索できるか、相談のみの記録を残せるか、参照とダウンロードのログが取れるかの3点に絞れます。

カスタマイズや受託開発が効く領域は照合索引の独立と権限の分離

作り込む価値があるのは2領域です。1つは照合の索引を事件管理から独立させ、事務所全体に開く仕組み。もう1つは相手方と依頼者を別の権限軸で扱う分離です。どちらも既製品の設定では届かないことが多く、かつ照合の抜けと守秘の破れという事故に直結します。加えて、顧問先契約との突き合わせ、つまり継続的な法律事務の提供を約している者を相手方とする依頼を検出する仕組みも、既製品の標準機能では持っていないことが多い領域です。こうした要件を既存の業務システムと接続しながら組む場合の進め方は基幹システム開発で扱っています。

作り込みを見送るべき場面は法令対応まで自前で抱える計画のとき

見送るべきなのは、会計や電子提出の法令対応まで自前で作る計画です。預り金の管理や裁判手続のオンライン化は規程や制度の改正に追随し続ける必要があり、追随のコストが機能の価値を上回る。既製品や専用サービスに任せ、自前で作るのは照合と権限に絞ります。書面作成にAIを組み込む範囲を検討している場合は、士業のAIとは？書類作成・調査・相談対応でできることと法令の線引き【2026年8月時点】の線引きを先に確認してから設計に入ると手戻りが減ります。

法律事務所の顧客管理で判断に迷いやすい項目と権限のよくある質問

弁護士1人の事務所でも顧客管理の仕組みは必要ですか？

必要です。ただし作り込みは不要です。1人の事務所でも、過去に相談だけで終わった相手を照合する場面は生じる。むしろ記憶に頼れる規模だからこそ、相談記録の抜けに気づかないまま年月が経ちます。表計算1ファイルでも構いませんが、相談のみの記録を消さない運用と名寄せの規則は、この規模から決めておく意味があります。

一般的なCRM製品を法律事務所で使ってはいけないのですか？

使えないわけではありません。ただし3点の手当てが前提です。失注クローズと自動削除を無効にすること、紹介元と売上集計を切り離すこと、相手方を顧客レコードとして登録しない別枠を用意すること。この3点を設定だけで実現できない製品なら、士業向けの製品か作り込みを検討する側に寄せます。

要配慮個人情報が含まれるとクラウドの製品は使えませんか？

要配慮個人情報が含まれること自体が、クラウドの利用を妨げるものではありません。論点は保管場所ではなく、取得の経路と同意の記録を残せるか、参照とダウンロードのログが取れるか、権限を情報の立場で分けられるかという設計の側にある。オンプレミスに置いても、これらが揃っていなければ説明はできません。

利益相反のチェック機能があると書かれていれば足りますか？

足りません。確認するのは、照合の対象に何が入っているかです。受任事件の依頼者だけを照合する機能と、相手方や相談のみで終わった相手まで含める機能では、実効性がまったく違う。照合の母集団がどう分かれるかは法律事務所のシステムとは？6領域の全体像と既製品／受託開発の判断基準で整理しているので、製品の説明と突き合わせて確認してください。