ooligo
n8n-flow

n8n で受信したすべての法務依頼を適切なレーンに振り分ける

Difficulty
中級
Setup time
120min
For
legal-ops-manager · in-house-counsel
Legal Ops

Stack

法務部門に単一の窓口を用意する n8n フローです。依頼はフォームまたは共有メールボックスから届き、12 種類の分類体系に対して仕分けされ、5 つのレーンのいずれかに着地します。セルフサービス用テンプレート、プレイブック審査、弁護士、依頼者待ち、GC エスカレーションの 5 つです。1 時間ごとのスイープが営業時間ベースで SLA の時計を追いかけ、月曜朝のレポートが「法務部門は実際に何を依頼されたのか」を伝えます。Claude の推論コストは 1 件あたり 0.011〜0.017 USD です。

ワークフローは apps/web/public/artifacts/legal-request-intake-router-n8n/legal-request-intake-router-n8n.json に含まれています。26 個のノードが、それぞれ独自のトリガーを持つ 3 つのブランチに分かれています。必要な 3 つの Postgres テーブルは隣接する schema.sql にあり、認証情報の設定と 6 段階の検証手順は _README.md にあります。

使うべき場合

法務チームが月に 30 件を超える依頼を処理していて、先週何件届いたのか、何についての依頼だったのかを、スプレッドシートを開かずには答えられない状態です。依頼は、その時に依頼者が思い出したチャネルから届きます。Checkbox のインテーク調査によれば、法務依頼の 87% はメールで届き、残りは電話か対面です。着地するもののうち相当な割合は、誰かがテンプレートを指し示せば依頼者自身で完了できる作業です。

価値があるのは分類ではありません。価値があるのは、依頼が 10 分以内に、レーン名と明示された期限を伴う初回対応を受けることと、週末に「法務は何に時間を使っているのか」という問いへの説明可能な答えが手元にあることです。後者こそが、これを構築する理由です。CLOC の 2026 年 State of the Industry Report は、売上中央値 130 億 USD の法務部門 135 社に基づき、規制コンプライアンス(部門の 63%)とサイバーセキュリティ(58%)で業務量が増加している一方、通常の 2 つの逃がし弁が狭まっていることを示しました。社内法務費用の増加を見込むのは 47% にとどまり(前年は 65%)、弁護士人員の増加を見込むのは 32% です。採用で問題から抜け出せないとき、リソース増強の論拠は、今は収集していない需要データから組み立てるしかありません。

このフローは、契約類型ごとの自動化の一段上のレイヤーです。依頼がどのパイプラインに属するかを決めるのがこのフローで、NDA だと特定された後の条項レベルの作業は NDA トリアージフローが担当します。

使うべきでない場合

月 30 件程度を下回るなら見送ってください。2 時間のセットアップは小さいコストです。本当のコストはサービスカタログを明文化し、依頼者ディレクトリを埋めることであり、その量では投資が回収できません。共有メールボックスと週次の当番制のほうが良い答えです。

テンプレートもプレイブックも文書化されていないなら見送ってください。セルフサービスレーンはテンプレートの URL を指し示し、プレイブックレーンは審査者が照合できる文書化された立場を持っていることを前提にします。それがなければ、すべての依頼が弁護士に振り分けられ、高価なキューを構築しただけになります。まずカタログを書いてください。それが本当のプロジェクトであり、このフローはその後にカタログを可視化するものです。

初回接触の時点から秘匿特権で保護されるべきインテークには見送ってください。社内調査、内部通報、すでにリティゲーションホールド下にあるものです。これらには自動化を完全に迂回する別チャネルが必要です。フローの特権ゲートは誤って正面玄関に届いたものを捕捉しますが、意図的に分類器を通すと決めたチャネルは、後で説明責任を負うことになるチャネルです。

法務の問題がルーティングではなく処理能力なら見送ってください。ルーターはキューを読み取り可能にし、需要を測定可能にします。弁護士を生み出すわけではなく、すでに稼働率 100% のチームは同じバックログをより良いラベル付きで見ることになります。

セットアップ

まず schema.sql を実行してください。requester_directory(誰が、誰のペーパーで依頼しているか)、legal_request_log(監査証跡と SLA の時計)、legal_sla_policy(レーンごとに 1 行、4 つのデフォルト時計を投入済み)を作成します。次に JSON をインポートし、README に従って 5 つのプレースホルダー認証情報を紐付け、そして何よりも先にワークフローのタイムゾーンを設定してください。エクスポートは Europe/London で出荷されており、すべての cron 式と Compute Breach Tier の営業時間計算はこの 1 つの設定を読みます。誤って設定してもエラーは発生せず、すべての期限が静かにずれるだけです。

挙動を決める設定は、2 つの Code ノードにあるいくつかの定数です。Apply Routing Policy では、CONFIDENCE_FLOOR が 0.75、VALUE_ESCALATION_USD が 250,000 USD、WALK_AWAY_FLAGS はモデルの結論にかかわらず GC エスカレーションを強制する 6 つのカテゴリを列挙しています。VALUE_ESCALATION_USD は、きりの良い数字ではなく、自社の署名権限マトリクスがすでに定めている値に設定してください。Normalize RequestPRIVILEGE_PATTERNS は、API 呼び出しを一切行わずに依頼を GC チャネルへ迂回させる 8 個の正規表現です。

SLA の時間数は一度調整することを見込んでください。これらはノードではなく legal_sla_policy テーブルにあるため、変更は SQL の UPDATE であってワークフローの編集ではありません。

フローの動作

Intake Form WebhookIntake Mailbox Poll — legal@ が 2 つの入口で、入口が 2 つあることを知っている唯一のノードが Normalize Request です。両方の形式を 1 つのエンベロープに平坦化し、本文を 4,000 文字で打ち切り、privilege_hit というブール値を設定します。依頼者を特定できない依頼は推測せず強制的にフラグを立てます。回答を送る相手がいないからです。

Privileged-Content Gate はそのブール値に基づいて動作します。真のブランチは #legal-gc-escalations へ直行し、モデルは内容を一切見ません。この順序こそが要点です。召喚状や調査案件では、分類のためのラウンドトリップはレイテンシの節約ではなく特権の問題だからです。

Requester Context は送信者をまず完全一致のアドレスで、次にドメインで検索するため、名前付きの例外が組織全体のデフォルトに優先します。Merge Requester Context は該当行がない場合に risk_posture: 'unknown' を割り当てます。'standard' ではありません。このひと言が、認識されていない送信者が自動化された法務回答を受け取ることを防いでいます。

Claude — Classify + Route はエンベロープを Sonnet 5 に送ります。system プロンプトには 12 種類の依頼類型、3 つの候補レーン、9 個のリスクフラグ、そして審査者がいなければ追いかける羽目になるフィールドの固定リストが記述されています。返却されるのは厳密な JSON で、laneconfidence、300 文字未満の判断理由が含まれます。Haiku ではなく Sonnet 5 を使うのは、高くつく誤りが 1 回あたりの価格差ではなく、弁護士レベルの依頼がセルフサービスの自動返信に埋もれることだからです。

Apply Routing Policy は安全ベルトであり、2 つ目のプロンプトではなく意図的に普通の JavaScript です。5 つのオーバーライドが優先順位順に発火します。walk-away リストのリスクフラグは gc_escalation を強制し、エスカレーション下限以上の申告額は lawyer を強制し、0.75 未満の確信度は self_serveplaybook に降格させ、標準外のリスク姿勢も同じ降格を行い、名前付きの不足フィールドは awaiting_requester へ振り分けます。各オーバーライドは理由を監査行に刻印するため、どのガードが存在価値を持っているかを測定できます。パース失敗は捕捉され、未読のまま人間へエスカレーションされます。プロンプトを編集した後の典型的なリグレッションは、モデルが JSON を markdown のフェンスで包むことです。ガードがプロンプトではなくここに存在するのは、プロンプトだけのガードは依頼者がフォームに貼り付けた任意のテキストで回避できるからです。

Lane Switch は 5 つのブランチに分岐し、フォールバック出力は静かな破棄ではなく gc_escalation です。5 つすべてが Write Intake Log に集約し、source_message_id をキーとして ON CONFLICT DO NOTHING で 1 行を挿入します。n8n は Postgres の一時的エラーでリトライするため、行が重複すると週次レポートのすべての数値が二重計上されます。セルフサービスレーンも行を書き込みます。記録されないセルフサービス回答は見えない作業であり、見えない作業こそがこのフローの解消対象だからです。

2 つ目のブランチは平日 1 時間ごとにスイープし、各レーンの SLA に対して経過営業時間を計算し、時計の 50%、100%、150% でエスカレーションを行い、第 3 段階では GC チャネルへ移します。Record Escalation Tier は Slack 投稿のに段階を書き戻すため、投稿が失敗した場合は静かな取りこぼしではなく翌時間に重複したリマインドが出ます。3 つ目のブランチは 1 週間分を集計し、数値が何であるかだけでなく各数値に対して何をすべきかを述べるレポートを投稿します。

コストの実態

Claude の推論が変動費の大部分を占めます。1 件の依頼は入力トークン約 2,400〜3,800 にシリアライズされ(12 種類の分類体系とレーン規則が大半を占め、依頼者の自由記述が 200〜800 を追加します)、構造化された応答は出力トークン 250〜400 に収まります。Sonnet 5 の定価である入力 100 万トークンあたり 3 USD、出力 100 万トークンあたり 15 USD で計算すると、1 件あたり 0.011〜0.017 USD です。月 400 件なら 4.40〜6.80 USD、月 2,000 件なら 22〜34 USD です。

もう 1 つの費目は n8n の実行回数です。インテークブランチは依頼 1 件につき 1 実行、SLA スイープは平日 1 日 10 回で月およそ 220 回、レポートは月およそ 4 回です。したがって月 400 件はおよそ 620 実行となり、n8n Cloud の Starter プラン(月 20 ユーロ、2,500 実行)に収まります。月 2,000 件ではおよそ 2,220 実行となり、余裕と同時実行数の観点から Pro(月 50 ユーロ、10,000 実行)に移るべきです。小規模な VPS でのセルフホストなら、どちらも実行回数の上限なしで処理できます。

対比として、この作業の手動版は、コーディネーターが各依頼を読み、どこへ送るか判断し、追いかけるというものです。読む・分類する・振り分ける・受領を返すまでを 1 件あたり 6〜10 分、コーディネーターの人件費込み単価を時給 60〜90 USD と見積もると、1 件あたり 6〜15 USD の人的時間になります。これらは実測ベンチマークではなく見積もりとして明示した数値です。興味深いのはこの比率ではありません。興味深いのは、コーディネーターの判断力が、40 回目に届く NDA ではなく、振り分けが本当に曖昧な 20〜30% の依頼に費やされるようになることです。

成功指標

週次で 3 つの数値を追跡してください。3 つともすでにレポートに含まれています。

インテークのカバレッジ — そもそも正面玄関から入ってきた法務作業の割合です。source = 'form' の行と source = 'email' の行の比率で代替し、90 日目までにメールを 30% 未満にすることを目標にしてください。カバレッジは、ここにある他のすべてが実在するかどうかを決める指標です。作業の半分しか見ていないルーターは、自信を持って間違った需要レポートを生成します。

セルフサービスの持続性 — テンプレートで回答した依頼のうち、同じ人が 7 日以内に戻ってこなかった割合です。85% 以上を目標にしてください。これは、素早く断ったことしか測定しないディフレクション率に対する誠実な対抗指標です。

すべてのレーンで初回対応 10 分未満。 ずれる場合、原因は振り分けロジックではなく API 呼び出しの遅延か n8n の実行キューです。しきい値をいじる前に実行一覧を確認してください。

代替手段との比較

共有メールボックスとスプレッドシートとの比較。 現状維持は運用コストがゼロで、データも生みません。月 30 件程度までは問題なく機能し、それを超えると特定の形で劣化します。キューは管理可能なままなのにレポートがフィクションになるのです。忙しい週にスプレッドシートを埋め戻す人はいないからです。振り分けを速くしたいだけなら、当番制と良い自動返信でほぼ目的を達成できます。これを構築すべきなのは、誰かが法務に人員を正当化するよう求め、正直な答えが「先四半期に何をしたか分からない」になったときです。

法務向け窓口製品との比較。 CheckboxStreamline AI はまさにこれを製品として販売しており、フォームビルダー、ワークフローデザイナー、レポーティングが最初から入っています。どちらも見積もり制で、2026 年 8 月の価格確認時点で開始価格を公開していませんでした。つまり、午後 1 回の作業ではなくエンタープライズの調達サイクルに入ります。legal ops に予算があってエンジニアリングの支援がない場合、そしてベンダー側の分類体系が自社の依頼構成に合う場合は、こちらのほうが良い選択です。このフローが良い選択になるのは、振り分け規則が自社の事業に固有の何かを符号化している場合です。署名権限のしきい値、常に弁護士を要する事業部、セルフサービスを拒否する取引相手の類型などです。それらの規則は、交渉して手に入れる設定画面ではなく、自社が所有する Code ノードに存在するからです。

すでに保有しているチケットキューとの比較。 Jira Service Management、ServiceNow、Zendesk はいずれも、今日から法務依頼フォームを受け付けられます。情報システム部門がすでに運用しているなら追加のライセンス費用もかかりません。ただし、これらが振り分けるのはフォームのフィールドです。依頼者が「契約審査」を選べば、チケットは契約審査キューへ行きます。これは依頼者の自己分類と正確に同じ精度でしか機能せず、インテークのデータが一貫して信頼できないと示しているのがまさにその自己分類です。このフローでは、依頼類型のヒントは「自己申告であり誤っている可能性がある」と明示したラベル付きでモデルに渡されます。依頼構成が狭く、フォームで列挙できるならチケットシステムを使ってください。決め手となる情報が自由記述の 1 段落に入っているなら、こちらを使ってください。

注意点

セルフサービスがディフレクションの壁になる。 失敗モード: 依頼者はテンプレートのリンクを受け取るが、テンプレートは本当の疑問に答えておらず、彼らはダイレクトメッセージで法務を迂回する。作業は依然として発生するのに、計上されなくなる。ガード: 週次レポートの再接触クエリが、同じ人物が 7 日以内に戻ってきたセルフサービス回答を数え、15% を超えるとフラグを立てます。Slack のセルフサービス返信も明示的な逃げ道で終わります。スレッドに返信すれば審査キューへ回り、新しいフォームは不要です。

分類体系のドリフトが新種の作業を弁護士に送る。 失敗モード: 新しい規制や製品ラインが 12 類型のどれにも当てはまらない依頼を生み、other として着地して既定で弁護士レーンに落ちる。モデルは動いているように見えるのにキューだけが伸びる。ガード: レポートが request_type = 'other' をランク付けし、全体量の 10% を超えるとフラグを立て、これはモデルの失敗ではなく分類体系に欠けている類型だと指示します。Claude — Classify + Route の system プロンプトに追加してください。

特権対象の内容が API に到達する。 失敗モード: 誰かが訴訟の文脈を含むスレッドに定型契約を添付して転送し、スレッド全体が推論リクエストに入る。ガード: PRIVILEGE_PATTERNS が API 呼び出しの前に 8 カテゴリを迂回させ、Normalize Request が本文を 4,000 文字で打ち切るため、長い転送スレッドはいずれにせよ切り詰められます。このフローは、データフローを明示的に承認する文書化された法務チーム向け AI ポリシーと組み合わせて運用し、これらのパターンを編集するたびに README の検証テスト 4 を再実行してください。

SLA の時計が誤った時間を数える。 失敗モード: 経過時間を暦時間で計算した結果、余裕を持って期限内にある依頼について深夜や週末に違反アラートが発火し、チームは 2 週間でチャネルをミュートする。ガード: Compute Breach Tier は月曜から金曜の BUSINESS_START から BUSINESS_END の間だけを数え、スイープ自体も cron で平日の営業時間に限定されています。README の検証テスト 6 は、ワークフロー設定とこれらの定数のタイムゾーン不一致を捕捉するためだけに存在します。

チャネルの規範が定着しない。 失敗モード: フォームは存在するのに、人々はそれでも GC に直接メールを送る。最初の依頼は常に、これまで送られてきたやり方で送られるからです。ガード: legal-intake@ メールボックスのトリガーがそれらを捕捉し、レポートのメール比率しきい値が、そのギャップを感覚ではなく数値として可視化します。最初の 30 日間は、各弁護士個人のメールボックスの自動返信と組み合わせてください。90 日目でもメール比率が 30% を超えているなら、それは組織の問題であり、ノードの編集では解決しません。

スタック

オーケストレーションに n8n、分類に Claude Sonnet 5、各キューと週次レポートに Slack、プレイブックレーンの案件レコードに Ironclad または自社の CLM、ディレクトリとログと SLA ポリシーに Postgres、受け皿となるメールボックスに Gmail を使います。振り分け規則の背景にある考え方は legal intake にあり、これが能力曲線のどこに位置するかは legal ops 成熟度モデル にあります。依頼が振り分けられた後、プレイブックレーンが実際に何を行うかは契約審査 SOP が定めます。

Files in this artifact

Download all (.zip)