法律事務所の初回相談の録音とメモから、事実関係・相談者の希望・論点・次にもらう資料を相談記録の様式にまとめ、受任の検討に回す

処理の起点を決める

相談番号のフォルダに録音ファイルが置かれたことを起点にします。 ICレコーダーの録音は事務局がフォルダへ移し、オンライン相談の録音は会議の終了後に同じフォルダへ保存します。置く場所を1つにしておけば、相談の形が違っても同じ流れに乗ります。

メモが置かれていなくても文字起こしは始めます。 文字起こしには時間がかかるので、録音を受け取った時点で依頼しておき、メモは記録を埋める段階でそろっていればよいようにします。メモがそろわないまま半日たったら、担当弁護士に知らせます。

録音の同意の記録が無い相談は、流しません。 相談カードに同意の欄を設け、同意が記録されていない相談番号のフォルダでは、録音が置かれても処理を止めて事務局に知らせます。

入力データを集める

質を決めるのは、いちばん下の2つです。 様式の項目の書き方が決まっていなければ、AIの下書きも弁護士ごとの書き方と同じくらいばらつきます。「事実関係は日付の古い順に、1行1つの出来事で書く」のように、書き方の決まりまで渡します。

次にもらう資料の一覧は、言い回しをそろえるためです。 弁護士が「給与明細を何か月分か」と言ったものを、「給与明細（直近○か月分）」と事務所の呼び方で書き出せば、事務局から相談者への連絡がそのまま作れます。

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

録音は、フォルダへの保存を検知した Power Automate が、ストレージに置いてバッチ文字起こしに送ります。依頼のときに、ロケールを ja-JP にし、話者の分離を有効にし、timeToLiveHours を短く設定します。

timeToLiveHours は文字起こしの結果をサービス側に保持する期間で、必須の項目です。 最短6時間、最長31日で、結果を直接使う場合は48時間が推奨とされています。この構成では結果を受け取ったらすぐに使うので、短い期間を設定し、受け取ったあとは削除の操作も呼びます。

結果の置き場所にも気をつけます。 結果の保存先のコンテナーを指定しないと、Microsoft が管理するコンテナーに保存されます。指定するときは、保存先の指定を要求本文の properties の中に入れます。 ルートに置くと無視され、管理されたコンテナーに書き込まれるとされています。

状態の確認を頻繁にしません。 ジョブの状態は10分ごとの確認で十分で、1分に1回以上のポーリングは勧められていません。完了の通知を Webhook で受け取る方法もあります。

AIへ渡す前に整形する

1. 録音の同意の確認 … 相談カードに同意の記録があることを確かめます。無ければ止めます
2. 録音の形式の確認 … ステレオの録音はモノラルに変換します。話者の分離はステレオでは使えません
3. 長さの確認 … 240分を超える録音は分割します。話者の分離を有効にしたときの上限です
4. メモの読み込み … タイプしたメモはそのまま、手書きはスキャンした画像を読み取って文字にします
5. 発言の一覧化 … 結果ファイルから、話者・開始時刻・発言の文字列を1行ずつの表にします
6. 名前の候補の洗い出し … 相談カードの相手方の名前を、照合用の一覧にします
7. 個人の連絡先の扱い … 録音のなかで読み上げられた電話番号や口座番号は、要約には不要なので伏せ字にしてから渡します

2番目を軽く見ないでください。 オンライン会議の録音はステレオで保存されることがあり、そのまま送ると話者の分離が効かず、全員の発言が1人のものになります。 第3章の（b）を防ぐための仕組みが、最初の段階で働かなくなります。

AIに処理させる

させるのは2つです。1つ目は話者の対応の推定、2つ目は様式の項目埋めです。 どちらも、相談のなかで実際に話されたことだけを材料にします。

3行目と4行目を分けることが、この構成でいちばん大事です。 事実関係には相談者が述べたことを、論点には弁護士が述べたことを入れます。相談者が「不当解雇だと思う」と言ったのは事実関係の欄に「相談者の認識」として入り、論点の欄には入りません。

関係者の一覧は、要約とは別に作らせます。 要約は重要なことに絞るので、話の流れで1回だけ出た名前は落ちます。一覧のほうは、絞らずにすべて拾うよう指示します。 利益相反の確認は、拾い漏れたものから崩れます。

2行目がいちばん起きやすい失敗です。 生成AIは、相談の内容から関係しそうな論点を思いつきます。それを論点の欄に書くと、相談のなかで弁護士が説明したように読めてしまいます。 相談者への説明の記録としても誤りになるので、禁じます。

指示内容を固定する

あなたは法律事務所で、初回相談の記録を整える立場です。
渡す文字起こしとメモだけを材料に、相談記録の様式の各項目を埋めてください。
相談のなかで話されていないことを書かないでください。

【話者】
{speaker_map}（例：Speaker1＝担当弁護士、Speaker2＝相談者、Speaker3＝相談者の家族）

【埋める項目】
1. facts：相談者・同席者が述べた出来事。日付の古い順に、1行1つの出来事。
   相談者の評価や意見（「不当だと思う」など）は、kind を client_view にして分ける
2. client_wishes：相談者が「こうしたい」「こうなってほしい」と述べたこと
3. lawyer_points：担当弁護士が相談のなかで述べた論点、見通し、費用の説明
4. documents_requested：担当弁護士が相談者に持ってきてほしいと頼んだ資料
5. parties：相談のなかで出たすべての人と会社の名前。要約で省いたものも含める
6. discrepancies：発言どうし、または発言とメモで食い違う箇所

【厳守事項】
- すべての行に、根拠にした発言の時刻と話者を付けてください。
- 日付が明示されていない出来事は、date を「時期不明」とし、前後から推測しないでください。
- 担当弁護士が述べていない論点を lawyer_points に書かないでください。
  あなたが関係すると考える論点があっても、書かないでください。
- 受任すべきか、見通しが良いか悪いかを書かないでください。
- 時効や期限の計算をしないでください。
- 聞き取れなかった箇所は「（聞き取り不明）」と書き、言葉を補わないでください。
- メモにあって録音に無いことは、source を memo として区別してください。
- documents_requested は、資料の一覧 {document_list} の呼び方に合わせてください。
  一覧に無いものは、弁護士が言ったとおりに書いてください。
- parties には、呼び方しか出ていない人（「部長」「元請けの担当者」）も含めてください。

【文字起こし】{transcript}
【弁護士のメモ】{memo}
【様式の書き方の決まり】{format_rules}

「あなたが関係すると考える論点があっても、書かない」とまで書くのは、そうしないと書くからです。 「弁護士が述べた論点」と指示しただけでは、文字起こしから読み取れる論点を補って並べます。禁じるのは、思いついた論点を記録に入れること自体です。

parties に「要約で省いたものも含める」と書くのも同じ理由です。 要約の指示と同じ呼び出しのなかで、名前の一覧だけは絞らないことを明記しておかないと、重要でないと判断した名前から落ちます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力で JSON スキーマを渡し、この形を守らせます。

{
  "consultation_id": "",
  "speaker_map": { "Speaker1": "lawyer", "Speaker2": "client", "Speaker3": "companion" },
  "facts": [
    { "date": "2025-04 | 時期不明", "event": "", "kind": "fact | client_view",
      "speaker": "Speaker2", "time": "00:12:34", "source": "recording | memo" }
  ],
  "client_wishes": [ { "text": "", "speaker": "", "time": "" } ],
  "lawyer_points": [ { "text": "", "type": "issue | outlook | fee", "time": "" } ],
  "documents_requested": [ { "name": "", "status": "requested | uncertain", "time": "" } ],
  "parties": [ { "name": "", "relation": "", "first_time": "", "in_intake": true } ],
  "discrepancies": [ { "a": "", "a_time": "", "b": "", "b_time": "" } ]
}

1つ目の理由は、発言者と時刻がすべての行に付くことです。 弁護士が下書きを読んで引っかかった行は、time を見て録音のその位置だけを聞けば確かめられます。第4章の①の20分が短くなるのは、ここです。

2つ目は、kind で事実と相談者の認識を分けられることです。 様式に書き出すときに、client_view の行には「相談者の認識として」と前置きを付けます。読む側が、事実と言い分を取り違えません。

3つ目は、parties の in_intake で追加の確認先が機械的に出ることです。 受付時の相談カードにある名前は true、無い名前は false です。false の名前だけを事務局に渡せば、追加の利益相反の確認が漏れません。

構造化出力は、出力を JSON スキーマに沿わせる仕組みで、項目の型と必須の項目が守られます。ただし、拒否の応答や max_tokens に達した場合は、スキーマに合わない出力になることがあるとされています。stop_reason を見て、その場合は人に回します。

システムへ連携する

事件管理システムへは書き込みません。 相談記録は弁護士が確定してから、事務局が登録します。確定前の下書きが事件の記録として残ると、直す前の誤りが正式な記録になります。

利益相反の確認も、この構成からはかけません。 名前の一覧を事務局に渡し、確認は事件管理システムで人が行います。 名前の表記ゆれ（旧社名、略称、読みの同じ別の字）は、人が判断したほうが確実です。

人が確認する

人の確認は3か所です。 話者の対応、追加の名前、そして下書き全体です。

1. 事務局が話者の対応を確かめる … 推定の根拠の発言を読み、違っていれば直します。ここで直すと、下書き全体が正しい話者で作り直されます
2. 事務局が追加の名前で利益相反の確認をかける … in_intake が false の名前だけを確かめます
3. 担当弁護士が下書きを読んで直す … 特に lawyer_points が自分の説明どおりかを確かめます
4. discrepancies を確かめる … 食い違いの両方の時刻を聞き、どちらが正しいかを記録に残します
5. 確定する … 直した下書きを相談記録として確定し、事務局が登録します

3番目は弁護士にしかできません。 弁護士が相談で話した見通しや費用の説明は、そのまま相談者への説明の記録になります。自分が言っていないことが書かれていないかを、必ず本人が見ます。

目標は、100件をならして1件15分です。 話者の確認と名前の確認で数分、弁護士の読み直しで10分前後という想定です。15分を大きく超えるなら、録音の音質か、様式の書き方の決まりの不足を疑います。

例外に対処する

上から3行目までは、録音の受け取り方の問題です。 ICレコーダーの設定とオンライン会議の録音の形式を最初にそろえておけば、ほとんど起きません。

記録を残す

• 録音ファイルと、相談番号・相談日・録音の同意の記録
• 文字起こしの結果（話者・時刻・発言）と、事務局が確定した話者の対応
• Claude API が返したJSONの全文と、そのとき使った様式の書き方の決まり
• 担当弁護士が直した箇所 … どの行を、どう直したか
• in_intake が false だった名前と、追加の利益相反の確認の結果
• Azure AI Speech 側の結果を削除した日時

4つ目で直した箇所を残すのは、指示を直すためです。 同じ種類の直しが続くなら、様式の書き方の決まりか指示の側が足りていません。特に lawyer_points に弁護士が言っていない論点が入っていた件数は、毎月数えます。

最後の行は、外部のサービスに相談の内容を残していないことの記録です。 依頼者の情報をどこに、いつまで置いたかを、あとから説明できるようにしておきます。