債務整理業務を「AI前提」で再設計する：集客は伸びたのに処理が追いつかない法律事務所のための業務設計
─ 既存業務にAIを足すのではなく、AIを前提にフロー全体を設計し直す ─
債務整理の問い合わせは増えている。しかし、受任できる件数が増えていない。
着手金0円モデルが標準化した今、法律事務所の収益は「何件受任して、何件処理できるか」に直結します。集客費用をかけて問い合わせを増やしても、事務スタッフが書類作成に追われていれば受任枠が埋まってしまう。ベテラン事務員の退職で一気にキャパシティが縮小する事務所も少なくありません。
この記事は、債務整理業務にAIを導入して「何をどう変えるか」を、atarayoが法律事務所の支援現場で見てきた設計思想をもとにしています。ツールの紹介ではなく、業務フローそのものの設計に焦点を当てます。
1. 何が起きているか：法律事務所の「処理能力の天井」
日本の弁護士数は、2006年の約2.2万人から2025年には約4.5万人へと20年で約2倍に増えました。法律事務所の数も増加していますが、個人向け法務（債務整理・交通事故・労働問題等）では価格競争が激しくなり、債務整理では着手金0円モデルが事実上の標準になっています。
この状況で法律事務所が売上を伸ばすには、受任件数を増やすしかありません。しかし、ここに構造的なボトルネックがあります。
債務者から届く資料は、紙の給与明細のスキャン、通帳画像、家計簿アプリのエクスポートデータ、ヒアリングの音声記録など、形式がバラバラです。事務スタッフがこれらを1件ずつ目視で確認し、Excelや管理システムに手入力する。そのデータをもとに裁判所指定の「家計収支表」を作成し、さらに提出先の地方裁判所ごとに異なるローカルルール（書式・添付書類・記載ルール）に合わせて申立書一式を準備する。
この作業は1件あたり数時間を要し、しかもその精度はベテラン事務員の経験と知識に依存しています。集客を2倍にしても、この処理工程がそのままでは、受任件数は2倍にはなりません。
2. なぜそうなるか：「人を増やす」以外の選択肢がない構造
一般的に言われる原因は「人手不足」「採用難」「予算の制約」です。
しかし弊社が法律事務所の業務改善を支援してきた中で見えたのは、もう少し根深い構造です。
第1の構造：手作業を前提とした業務フローが固定化している
多くの法律事務所では、債務整理業務のフローが「手作業」を前提に組まれています。資料の受領、内容の確認、管理システムへの入力、申立書の作成──これらの工程はすべて事務スタッフの手作業で行われ、その業務量に処理能力の上限が決まります。受任件数を増やすには人を増やすしかなく、人件費が収益を圧迫する構造が固定化しています。
「AI活用」や「DX」が話題になっても、何から手をつけるべきか分からない。あるいは、OCRソフトやチャットボットを部分的に試してみたが、その前後の工程が手作業のままで全体の処理速度は変わらなかった。こうした状況は決して珍しくありません。
第2の構造：暗黙知への依存
債務整理業務には、マニュアル化しにくい暗黙知が多く含まれています。たとえば、裁判所は家計収支表と預貯金通帳の整合性を最も厳しく審査しますが、どの程度の不整合で差し戻されるかは裁判所によって異なります。東京地裁と大阪地裁では申立書類の名称自体が異なり（「陳述書」と「報告書」）、添付資料の要否にも違いがあります。
こうした知識はベテラン事務員の頭の中にあり、退職・異動で一気に失われます。新人の育成にも時間がかかり、その間の処理品質は不安定になります。問題は「人が足りない」ことではなく、「業務の進め方が人に依存しすぎている」ことです。
第3の構造：使えるツールがそもそも存在しない
日本のリーガルテック市場は約350〜400億円規模で年率20%超の成長が続いていますが、その中心は「契約レビュー」「電子契約」（市場の60〜70%）です。法律事務所の「案件処理の業務フロー全体」を効率化するプロダクトは、ほぼ存在しません。
その理由は明確です。訴訟記録や個人の財務データはクラウドに出しにくく、業務フローは事務所ごとに異なり、非弁行為（弁護士法72条）に抵触しない設計には法務知識とAI設計の両方が必要だからです。汎用SaaSでは対応できない領域であり、だからこそ空白のまま残っています。つまり、法律事務所が「何か良いツールはないか」と探しても、自社の業務に合うものが見つからないのは当然の状況です。
3. どう変えるか：「AI-native」な業務フロー設計の3つの原則
弊社が提案するのは、既存業務にAIを「足す」のではなく、AIを前提にフロー全体を設計し直すアプローチです。弊社はこれを「AI-native業務設計」と呼んでいます。
債務整理業務は、このアプローチと相性が良い領域です。なぜなら、新規事業として立ち上げる場合には「ゼロから設計できる」ため、既存のやり方を壊す必要がないからです。既存システムの改修も不要であり、人間側の「アンラーニング」のハードルも低い。
| 軸 | 従来のアプローチ | AI-native設計 |
|---|---|---|
| AI導入の位置づけ | 既存フローの「一部」をAI化 | フロー「全体」をAI前提で再設計 |
| データの流れ | 手入力→ツール→手修正 | AI一括処理→人が確認・修正 |
| 暗黙知の扱い | ベテランの頭の中 | AIに学習させ、組織資産化 |
| スケール性 | 人を増やす＝コスト増 | AIが処理→人は判断に集中 |
具体的な設計原則は3つです。
原則1：「独自データで独自AIを構築する」ことを起点にする
債務整理業務のボトルネックは、入口にあります。バラバラの形式で届く債務者の資料を、申立に使える構造化データに変換する作業です。
ここで重要なのは、汎用AIをそのまま適用するのではなく、事務所固有のデータを学習させた独自AIを構築するという発想です。債務整理業務で扱うデータ（通帳の読み取りパターン、家計収支の分類体系、裁判所ごとの書式要件）は、汎用的なAI-OCRやLLMが学習していない領域です。自社の過去案件データ、修正履歴、裁判所からの差し戻し事例といった独自データを学習に活用することで、はじめて「業務で使えるAI」が成立します。
AI-native設計では、この構造化を起点に据えます。独自に学習させたAI-OCRが紙のスキャンデータ・通帳画像・アプリのエクスポートデータを一括で読み取り、日付・金額・取引先を自動で抽出・分類する。さらに、裁判所指定の家計収支表フォーマットへの変換、収支の不整合や使途不明金の検出、複数資料間（通帳・給与明細・源泉徴収票等）の突合まで自動で実行します。
ポイントは「文字を読み取る」だけでなく、「申立に使える形にする」ところまでをAIの責任範囲にすることです。OCRだけ入れても、後工程が手作業なら意味がありません。
なお、債務整理業務で扱うデータには債務者の氏名・住所・資産状況・負債額といった要配慮個人情報が含まれます。AI構築にあたっては、個人情報保護法およびその関連ガイドライン（個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」等）への準拠が不可欠です。具体的には、データの取得・利用目的の明示と同意取得、学習データの匿名化・仮名化処理、アクセス権限の厳格な管理、データの保管場所と通信経路の暗号化、委託先との安全管理措置契約の締結といった対策が求められます。日弁連が公表している「弁護士情報セキュリティ規程」（2024年4月施行）および「弁護士の業務における生成AI利用に関する指針」も参照し、事務所としてのセキュリティポリシーを明確にしたうえでAI導入を進めるべきです。
原則2：「ローカルルール」をAIに学習させ、組織の資産にする
債務整理の申立書類は、提出先の地方裁判所ごとに書式が異なります。この「ローカルルール」は従来、ベテラン事務員の経験に依存していました。
AI-native設計では、構造化されたデータをもとにLLM（大規模言語モデル）が提出先裁判所のローカルルールを自動で判定し、陳述書・報告書、財産目録、債権者一覧表、申立書本体のドラフトを一括生成します。各裁判所が求める添付書類リストの自動チェックも行います。
ここで重要なのは、AIが法的判断を行うわけではないという設計原則です。生成されたドラフトは、弁護士または事務スタッフが内容を確認・修正したうえで提出します。AIの修正履歴は学習データとして蓄積され、利用を重ねるほどその事務所の運用に最適化されていきます。
この設計において、弁護士法72条（非弁行為の禁止）への配慮は不可欠です。 同条は、弁護士でない者が報酬を得る目的で法律事務を取り扱うことを禁じています。AIシステムが法的判断を行い、その出力がそのまま依頼者への助言や裁判所への提出書面として機能する設計は、非弁行為に該当するリスクがあります。
弊社が設計原則として徹底しているのは、AIの出力を一貫して「ドラフト・参考情報」の位置づけに留めることです。AIが生成した書面は、必ず弁護士が内容を精査し、法的判断を加えたうえで最終確定する。この「人が最終判断を下す」プロセスを設計上の必須要件として組み込むことが、非弁行為に抵触しないための前提条件です。
日弁連が2024年に公表した「弁護士の業務における生成AI利用に関する指針」でも、生成AIの出力を弁護士が検証せずにそのまま利用することへの注意が示されています。AI活用の設計にあたっては、こうした業界ガイドラインを踏まえたうえで、「AIは補助ツールであり、法的サービスの主体はあくまで弁護士である」という構造を明確にすることが求められます。この設計原則そのものが、AIを安全に業務に組み込むための要件であり、安易な汎用SaaS化を防ぐ参入障壁でもあります。
原則3：「人の役割を変える」ことで処理能力を拡大する
AI-native設計の目的は「人を減らす」ことではありません。人がやるべきことを変えることです。
原則2で述べたとおり、AIの出力はすべてドラフト・参考情報であり、最終判断は必ず人が下します。この前提に立つと、人の役割は明確に変わります。事務スタッフは手入力やフォーマット変換から解放され、AIが出力したドラフトの「確認・修正」に集中する。弁護士は書面作成の負荷が減り、依頼者との面談や法的判断といった「弁護士にしかできない業務」に時間を使えるようになります。
弊社の試算では、類似の法律業務において、AI-nativeフロー設計により1件あたりの総工数が約65%削減、事務員工数に限れば約80%近く削減されるケースが確認されています。人員を増やさずに受任キャパシティを拡大できる構造が、この設計から生まれます。
4. まとめ：「AIを入れる」から「AIを前提に設計する」へ
債務整理業務のAI活用を考えるとき、最初に問うべきは「どのAIツールを入れるか」ではなく、「この業務を、もしAIがあることを前提にゼロから設計するなら、どう設計するか」です。
弊社が大事にしているのは、AIを「既存の業務を少し楽にするツール」ではなく、「業務の前提そのものを変える設計思想」として捉えることです。債務整理業務は、書類処理の工数が大きく、暗黙知への依存度が高く、そしてAI-nativeに再設計した場合の改善幅が特に大きい領域です。
集客は伸びているのに処理が追いつかない。ベテランが辞めたら回らなくなる。そうした課題を、人を増やすことではなく、業務の設計を変えることで解決する。AIの活用は、その手段のひとつです。
この記事の内容について、自社の状況と照らし合わせて話をしてみたい方は、お気軽にご連絡ください。
