法務への相談・契約審査の依頼を仕分けて、ひな形で済むものと審査が必要なものに分ける

処理の起点を決める

法務依頼フォームに新しい応答が送信されたことを起点にします。Power Automate の Microsoft Forms コネクタの「新しい応答が送信されるとき」トリガーを使います。

フォーム以外の入口をどうするかを、運用で決めてください。現実には、メールと立ち話はなくなりません。

• メールで届いた依頼は、法務がフォームに転記せず、依頼者にフォームを案内する。 転記すると法務の手間が増え、フォームに寄せる意味がなくなります
• 緊急のものだけ例外を認める。 「商談が今日ある」といった場合は、従来どおり直接連絡を受けます。ただし、処理後にフォームへ記録します

Microsoft Forms コネクタは組織アカウントでのみ動作します。 社外からの依頼を受ける用途には使えません。

入力データを集める

「希望期限の理由も書かせる」ことが、緊急度の判定を成り立たせます。 「至急」とだけ書かれた依頼と、「9月25日の商談で先方に提示するため」と書かれた依頼では、判定の材料がまったく違います。フォームの項目を「希望期限（日付）」と「その期限である理由」の2つに分けてください。

データの取得方法を決める

フォームの回答： 「新しい応答が送信されるとき」トリガーが応答IDを返すので、「応答の詳細を取得する」アクションに渡して回答を取得します。このアクションの出力は動的です（フォームの項目によって変わります）。

添付ファイル： Microsoft Forms のファイルアップロード項目は、回答者のOneDriveまたはフォーム所有者のOneDriveに保存され、回答にはそのリンクが入ります。リンクからファイルの中身を取るには、OneDrive コネクタで別途取得する必要があります。

契約書の中身をAIに渡すかは判断が分かれます。この構成では、1ページ目だけを渡す設計にします。契約類型と相手方の名称は1ページ目でほぼ分かります。全文を渡すと、入力量が増えるうえ、機微な情報が外部に出る範囲も広がります。

過去の相談記録： 相談台帳から、同じ相手方または同じ契約類型の直近の相談を数件だけ取ります。全件を渡す必要はありません。

AIへ渡す前に整形する

1. 添付ファイルの1ページ目だけを取り出す … PDFなら1ページ目、Wordなら先頭の1,500文字程度。全文を渡さない
2. 個人名の扱いを決める … 依頼者名は判定に不要です。部門名だけを渡す構成にできます
3. 期限の正規化 … 「今週中」「来月頭」といった表現を、フォームの送信日を基準に日付へ変換します。この変換はAIではなくワークフロー側で行うほうが確実です。フォームで日付項目を必須にしていれば、そもそも不要です
4. 同一案件の検出 … 同じ依頼者が同じ相手方について1週間以内に出した依頼は、追加情報の可能性があります。台帳を引いて、関連する既存案件のIDを添えます
5. 添付なしの契約審査依頼の除外 … 「契約書の審査をお願いします」で添付が無い依頼は、判定に回す前に自動返信で差し戻します

AIに処理させる

「ひな形適用の判定」は、断定させません。 「ひな形で対応できる」ではなく「ひな形で対応できる可能性が高い／要審査の可能性がある／判定できない」の3段階にします。相手方が提示した契約書を審査する案件を、ひな形提供と誤って分類すると、審査されないまま締結される危険があります。

指示内容を固定する

あなたは法務部門の受付担当です。
各部門から届いた相談を読み、種別と緊急度を判定し、
不足している情報を挙げてください。審査はしません。

【厳守事項】
- 契約内容の是非、リスクの有無、修正すべき条項について
  意見を書かないでください。これは受付の判定であり、審査ではありません。
- 「ひな形で対応できる」と断定しないでください。
  template_applicable は likely / needs_review / unknown の
  3つから選び、判断できないときは unknown にしてください。
- 相手方から提示された契約書（自社ひな形ではないもの）は、
  内容にかかわらず template_applicable を needs_review にしてください。
- 緊急度は、希望期限の「日付」と「理由」から判定してください。
  「至急」「なるべく早く」という表現だけでは high にしないでください。
  具体的な予定（商談日、締結日、取締役会の日）がある場合のみ high です。
- 不足情報は、下の必要情報リストに照らして挙げてください。
  リストにない項目を独自に追加しないでください。
- 法令の解釈や条文の引用を書かないでください。

【種別ごとの必要情報】
{required_fields_by_type}

【自社ひな形の一覧】
{template_list}

【依頼内容】
{form_response}

【添付書類の1ページ目】
{attachment_head}

【同じ相手方・類型の過去の相談（直近3件）】
{past_cases}

「審査はしません」「意見を書かないでください」を最初に置いています。 生成AIは契約書の断片を見ると、頼まれなくてもリスクの指摘を始めます。受付の判定結果に審査めいた文章が混ざると、依頼者がそれを法務の見解と受け取る危険があります。 自動返信の文面に混ざれば、なおさらです。

出力形式を固定する

{
  "request_type": "contract_review | template_request | legal_question | other",
  "contract_category": "",
  "counterparty": "",
  "template_applicable": "likely | needs_review | unknown",
  "template_name": "",
  "urgency": "high | medium | low",
  "deadline_date": "",
  "urgency_reason": "",
  "missing_information": [],
  "summary_one_line": "",
  "reply_draft": "",
  "related_case_id": "",
  "confidence": "high | medium | low"
}

template_applicable と urgency を列挙値にしているのは、台帳で並べ替えと絞り込みができるようにするためです。自由文で返させると、台帳が読めるだけの文字列の山になります。

confidence が low のものは、自動返信の対象から外します。判定に自信が無い依頼に自動で差し戻しを送ると、依頼者が混乱します。

システムへ連携する

台帳への記録： 相談台帳のスプレッドシートに1行追加します。列は、受付日、依頼部門、種別、契約類型、相手方、緊急度、期限、要約、不足情報、担当（空欄）、状態（空欄）です。担当と状態は法務が手で埋めます。

依頼者への自動返信： 不足情報があり、かつ confidence が high または medium の場合だけ送ります。文面には必ず次の2つを入れてください。

• これは自動の確認であり、法務の見解ではないこと
• 不足情報を追記して再度フォームから送るか、急ぐ場合は直接連絡してよいこと

Teamsへの通知： urgency が high のものだけを法務のチャネルに流します。全件を流すと通知が意味を失います。

ひな形の自動送付はしません。 template_applicable が likely でも、ひな形を送るのは法務が判断します。相手方が提示した契約書なのに likely と誤判定された場合、ひな形を送ることが事態を悪化させます。

人が確認する

判定結果は全件、法務が台帳で見ます。自動で完結する依頼はありません。

自動で行われるのは、不足情報の差し戻しだけです。ここだけは人を介しませんが、送っているのは「これとこれが書かれていません」という事実の確認であり、法務としての判断は含みません。

法務が台帳で見るのは次の3点です。

• 種別の判定が合っているか（違っていれば手で直す）
• 緊急度の判定が合っているか
• template_applicable が likely のものが、本当にひな形で済むか

3つ目は必ず人が確認してください。 ここを飛ばすと、審査が必要な契約書がひな形提供の列に落ちます。

例外に対処する

「極秘案件」の分岐は必ず作ってください。 M&A、係争、労務の重大案件は、受付の自動化の対象から外します。フォームのチェック1つで分岐できます。

記録を残す

• フォームの回答（Microsoft Forms に残る）
• AIに渡した内容と、返ってきた判定
• 自動返信を送ったかどうか、その文面
• 法務が手で直した項目（判定前と判定後）
• 実際の処理結果（ひな形提供で済んだ／審査した）

「法務が手で直した項目」と「実際の処理結果」の2つが精度の実測値になります。 種別の判定を毎月10件直しているなら、種別の定義かフォームの項目に問題があります。template_applicable が likely だったのに審査が必要だった件は、1件でも起きたら判定条件を見直してください。 逆方向の誤り（審査に回したが不要だった）より重大です。