クレーム・紛争案件の経緯と期限を、メールと資料から時系列にまとめる

処理の起点を決める

起点は2つ置きます。毎日18時の定時実行と、法務が押すオンデマンド実行です。

Makeのシナリオは既定で15分ごとに実行され、スケジュールの設定画面で変更します。設定できるのは、一定間隔、1回だけ、毎日、平日（月曜から金曜）、毎週、毎月、特定の日付、オンデマンドです。最短の間隔は契約しているプランによって変わります。 詳細設定では、シナリオが動く期間の開始日と終了日も決められます。

15分ごとのままにしないでください。 案件フォルダには1日のうちに何度も資料が入ります。そのたびに動くと、同じ案件を1日に何度も処理し、通知も同じ回数だけ飛びます。1日1回にまとめ、急ぐときだけ法務が手で起こすのが、この業務に合っています。

即時実行のトリガーを使う場合は、実行回数の上限に注意が必要です。既定では毎分100回が上限で、超えた分はキューに入って順に処理されます。Webhookの応答モジュールを置いている場合は、上限を超えた呼び出しに429が返ります。

案件ごとにシナリオを作らないでください。 案件は増え続けます。フォルダ名に案件IDを入れ、1つのシナリオが案件IDごとに処理を分ける作りにします。

入力データを集める

資料はコピーを案件フォルダに置き、原本は動かしません。 索引には元の場所、置いた人、置いた日を残します。あとで「その資料はもともとどこにあったのか」を答える必要が出るためです。

写真は中身を読ませません。 撮影日時とファイル名だけを時系列に入れ、何が写っているかは人が1行書きます。写真から状態を読み取らせると、それは事実の記録ではなく評価になります。

聞き取りメモを最初から入力に入れてください。 口頭のやり取りは、メモにしない限りどこにも残りません。「4月8日ごろ、現場で口頭の依頼があったと担当者は述べている」という形で、誰の記憶かを書いたうえで資料として扱います。

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

メール： Outlookで該当スレッドを選び、.msgで書き出します。スレッド全体を出してください。 返信に引用された過去のやり取りが、元のメールが消えている場合の唯一の記録になることがあります。書き出しは本人が行い、「関係すると思うもの」ではなく「相手方の社名か案件名が入っているもの全部」という条件で出してもらいます。判断を挟ませないためです。

フォルダの監視： MakeのMicrosoft 365のモジュールで、案件フォルダの新規ファイルを取得します。処理済みのファイルは索引に記録し、次回は飛ばします。

PDF： テキストが埋まっているものはそのまま抽出します。スキャンしたものはOCRにかけ、索引に「OCR」と印を付けます。 OCRを通した資料は、数字と固有名詞に誤りが混ざる前提で人が確かめます。工事管理システムはCSV出力を使います。紛争案件は過去の期間を一度取れば足りるため、手動の出力で十分なことがほとんどです。

取れなかった資料も記録します。 退職した担当者のメールボックス、上書きされた現場の写真、保存期間を過ぎたチャット。「取れなかった」という事実を索引に残さないと、表が完全なものに見えてしまいます。

AIへ渡す前に整形する

1. 資料IDの付与 … S-001 から順に振ります。索引に、ファイル名、資料の種類、日付、元の場所、置いた人、ページ数、OCRの有無を記録します
2. メールの分解 … 1通を1資料として扱い、ヘッダー（差出人、宛先、送信日時）と本文を分けて持ちます。 日付はヘッダーから取り、本文の「昨日お伝えした」は日付として扱いません
3. 引用部分の除去 … 返信に含まれる過去のやり取り（> 以降や区切り行の下）を落とします。同じ発言が10通分だけ並ぶのを防ぐためです。ただし、元のメールが資料として存在しない場合は落とさず、「引用からの復元」と印を付けます
4. 位置の記録 … PDFはページ番号、文書は段落番号を付けます。S-012 p.2 第3段落 の形で、出どころの索引から原本の場所を引けるようにします
5. 分割 … 長い資料は段落の切れ目で分けます。分けた位置も索引に残し、あとで位置がずれないようにします
6. 基準日の付与 … その資料自体の日付（メールの送信日時、議事録の開催日）を一緒に渡します。本文に「来週まで」とあったとき、基準日が無ければ何も確定できません
7. 渡さない資料の除外 … 弁護士とのやり取り、社内の稟議、原価の資料を、この段階で外します。第13章で扱います

3番目の引用除去は、やりすぎないでください。 「元のメールが無いときは落とさない」という例外を置かないと、相手方しか持っていなかった発言が、引用ごと消えます。

AIに処理させる

計算処理にさせること：

生成AI（Claude API）にさせること：

させないこと：

責任の所在、過失の有無、契約違反にあたるかどうか、勝ち負けの見込み、相手方の主張が正しいかどうか、期限を過ぎているかどうかの判断、書かれていない出来事の補完。

期限の判断をさせない理由は、起算日の読み方が事実ではないためです。 「引渡しから1年」という条文があったとき、引渡しがいつ成立したのかが、この案件で争っていること自体であることがあります。条文と、時系列表にある日付を、同じ紙に並べて出すところまでが機械の仕事です。 日数の計算もPythonにさせません。「起算日から何日経過」という列を作ると、その列は起算日を1つに決めたことになります。

指示内容を固定する

資料1点ごとに呼び出す、事実抽出のプロンプトです。

あなたは、紛争になっている案件の資料を読み、事実の時系列を作る担当者です。
下の資料1点から、日付が特定できる出来事を取り出してください。

【この作業でしないこと】
- どちらに責任があるか、過失があるか、契約違反にあたるかを書かないでください。
- 勝てるか負けるか、有利か不利かを書かないでください。
- 相手方の主張が正しいかどうかを評価しないでください。
- 期限を過ぎているかどうかを書かないでください。
- 資料に書かれていない出来事を補わないでください。
  「おそらく連絡したと思われる」のような推測を書かないでください。

【厳守事項】
- すべての行に quote を付けてください。quote は資料の本文から一字一句そのまま
  写してください。要約、言い換え、句読点の変更をしないでください。
- すべての行に locator を付けてください。locator は、下に与えた位置の書き方
  （「p.2 第3段落」など）に合わせてください。
- 日付は、資料に書かれている日付か、資料自体の日付から確実に決まる場合だけ
  events に入れてください。
  「基準日」を渡してあります。「昨日」「来週」などは、基準日から確実に決まる
  場合だけ日付にし、決まらない場合は undated_events に入れてください。
- 月までしか分からない場合は、その月の1日を date に入れ、
  date_precision を「月まで特定」にしてください。
- 日付がまったく分からない出来事、口頭のやり取りで時期が不明なものは、
  undated_events に入れてください。when_text には、資料に書かれている
  時期の表現（「昨年の夏ごろ」など）をそのまま写してください。
- actor は資料に書かれている名前か役職を写してください。
  書かれていなければ「記載なし」とし、推測で補わないでください。
- actor_side は「自社」「相手方」「第三者」「不明」から選んでください。
  下に与えた当事者の一覧に無い名前は「不明」にしてください。
- event は、起きたことを1文で書いてください。評価語（不当、不誠実、遅延の責任）を
  使わず、「◯◯を依頼した」「◯◯と回答した」「◯◯を受領した」のように書いてください。
- 資料の中で、別の記録と突き合わせないと決められないことがあれば、
  data_gaps に書いてください。

【契約書の場合の追加指示】
- 期間、期限、予告、通知、検査、引渡し、解除、支払期日に関わる条文を
  deadline_clauses に入れてください。
- clause_text には条文をそのまま写してください。要約しないでください。
- period_text には、期間の定めの部分だけを写してください（「引渡しの日から1年間」など）。
- starting_point_text には、条文に起算点として書かれている文言を写してください。
- その期限が過ぎているかどうか、有効かどうかは書かないでください。

【当事者の一覧】
{parties}

【資料ID】{source_id}
【資料の種類】{source_type}
【資料の基準日】{base_date}
【位置の書き方】{locator_format}

【資料の本文】
{source_text}

「評価語を使わない」は具体例で示してください。 「不当に」「一方的に」「遅延した」は、書き手の評価が入った言葉です。「4月20日納入の予定に対し、5月2日に納入した」と書けば、遅れていることは読む人に分かります。

「決まらない場合は undated_events に入れる」という逃げ道が要ります。 これが無いと、「昨年の夏ごろ」を勝手に8月1日と決めてきます。日付不明のまま残せる場所を作ることが、この設計でいちばん効きます。

表を並べ終わったあとの3回目の呼び出しでは、行IDを振った時系列表を丸ごと渡し、「同じ事柄について別々の記録が別のことを言っている組み合わせ」を行IDの組で返させます。 ここでも「どちらが正しいか」は返させません。返すのは、食い違っている事柄と、その種類（日付が違う／数量や金額が違う／言った内容が違う／合意の有無が違う）と、関係する行IDだけです。

出力形式を固定する

資料1点ごとの呼び出しでは、次の形のJSONを返させます。Claude APIでは output_config.format に {"type": "json_schema", "schema": {...}} を渡すと、応答をスキーマに沿った形に制約できます。

{
  "type": "object",
  "additionalProperties": false,
  "required": ["source_id", "events", "undated_events", "deadline_clauses", "data_gaps"],
  "properties": {
    "source_id": { "type": "string" },
    "events": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": ["date", "date_precision", "actor", "actor_side", "event", "locator", "quote"],
        "properties": {
          "date": { "type": "string", "format": "date" },
          "date_precision": { "type": "string", "enum": ["日まで特定", "月まで特定"] },
          "actor": { "type": "string" },
          "actor_side": { "type": "string", "enum": ["自社", "相手方", "第三者", "不明"] },
          "event": { "type": "string" },
          "locator": { "type": "string" },
          "quote": { "type": "string" }
        }
      }
    },
    "undated_events": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": ["when_text", "actor", "actor_side", "event", "locator", "quote"],
        "properties": {
          "when_text": { "type": "string" },
          "actor": { "type": "string" },
          "actor_side": { "type": "string", "enum": ["自社", "相手方", "第三者", "不明"] },
          "event": { "type": "string" },
          "locator": { "type": "string" },
          "quote": { "type": "string" }
        }
      }
    },
    "deadline_clauses": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": ["clause_no", "clause_text", "period_text", "starting_point_text", "locator"],
        "properties": {
          "clause_no": { "type": "string" },
          "clause_text": { "type": "string" },
          "period_text": { "type": "string" },
          "starting_point_text": { "type": "string" },
          "locator": { "type": "string" }
        }
      }
    },
    "data_gaps": {
      "type": "array",
      "items": { "type": "string" }
    }
  }
}

このスキーマには、責任、過失、有利不利、見通し、期限の当否を入れる項目がありません。 項目が無ければ、そこには書けません。「書かないでください」という指示と、書く場所を作らないことの両方をやってください。 指示だけだと、event の文の中に評価が混ざります。

公式の説明で確認できた仕様のうち、この設計に関わるものが3つあります。

オブジェクトの additionalProperties は false にする必要があります。 勝手な項目が増えないため、この用途には都合のよい制約です。

文字列の形式では date が使えます。 日付の列が 2026-04-08 の形に揃い、並べ替えがそのまま効きます。ただし空文字を入れられません。 日付不明の行を events に置けないので undated_events を別に作りますが、これは日付不明を別に置くという業務側の要件とたまたま一致しています。

文字列の長さの制約（minLength、maxLength）と数値の範囲の制約は使えず、配列の minItems は0と1だけです。 引用の長さや行数の下限はスキーマで書けないため、プロンプトで指示し、Python側で確かめます。

さらに、この題材では必ずぶつかる仕様があります。引用（citations）と構造化出力は併用できません。 資料を document ブロックで渡して citations.enabled を true にし、同時に output_config.format を指定すると、APIは400エラーを返します。 引用は本文の途中に引用のブロックを差し込む仕組みで、スキーマで形を固定する仕組みと両立しないためです。

そこで、出どころは前処理で振った資料IDと位置で持ちます。 資料1点ずつに分けて渡しているので、その呼び出しの資料IDがそのまま出どころになります。引用が本物かどうかは、Pythonで原本のテキストに含まれるかを確かめます。

引用の位置をAPIに保証させたい場合は、呼び出しを分けます。 引用を有効にすると、平文は文単位、PDFはページ単位、独自コンテンツはブロック単位で位置が返ります。独自コンテンツは追加の分割がされないため、1資料を1ブロックにすればブロック番号が資料IDに対応します。 その呼び出しではJSONを返させられないので、弁護士に渡す前に重要な行だけを確かめる用途に限るのが現実的です。なお引用を有効にする場合、同じリクエスト内の文書は全部有効か全部無効かのどちらかにします。

システムへ連携する

Excelを1つ作り、案件フォルダに保存します。シートは次の4つです。

期限の一覧は、時系列シートの下に続けて置きます。 条番号、条文、期間の定め、起算点の文言、出どころ（資料IDと位置）の5列です。別のファイルにしないでください。 弁護士に渡したあと、期限の紙だけがどこかへ行きます。

Teamsへの通知は、案件名、資料の点数、時系列の行数、日付不明の行数、引用の照合に失敗した行数、論点候補の件数だけを送ります。通知に本文を載せないでください。 Teamsのチャネルは、案件に関係しない人も見られることがあります。弁護士への受け渡しは、この流れの外に置きます。 第13章で扱います。

人が確認する

人の確認は必須です。 確認するのは4つです。

1. 引用と原本の突き合わせ … 機械照合を通った行も、論点に関わる行は原本を開いて前後を読みます。引用が一致していても、前後を読むと意味が違うことがあります
2. 日付不明の行の聞き取り … 担当者に聞き、分かったものは日付を入れて時系列へ移します。分からないまま残すことを、法務が許す運用にしてください
3. 食い違いの扱い … 両方の行をそのまま残します。「こちらが正しい」と1行に直したくなりますが、そこは止めてください
4. 論点候補の追加 … 機械が拾えるのは、記録どうしの食い違いと記録の欠けだけです。論点の大半は、法務と弁護士が足します

確認が終わった行には、時系列シートの「確認済み」列に印を付けます。印の無い行が残ったまま弁護士に渡さないことを、運用の決まりにします。

表の先頭に、必ず次の2行を書いてください。 「この表は、資料から機械的に抜き出したものを人が確認したものです」「この表に入っていない資料は、出どころ索引の末尾に一覧があります」。整った表ほど、これで全部だと見えてしまいます。

例外に対処する

1点ずつ処理しているため、失敗した資料だけを再実行できます。 40通のメールのうち3通で失敗しても、37通の結果は残ります。案件全体をやり直す作りにしないでください。

記録を残す

案件ごとに、次を残します。

• 入力した資料のコピーと、出どころ索引
• AIが返した生のJSON（資料ID別、呼び出し日時つき）
• 人が直したあとの表と、直した差分
• 実行日時、実行者、使ったプロンプトの版
• 表の版番号と更新日（案件が動くたびに更新するため）
• 案件フォルダを誰がいつ開いたかの記録

行ごとに、AIが出したものか人が足したものかを持たせてください。 時系列シートに「出どころ区分」の列を1つ作り、抽出 と 人が追加 を入れます。あとで「この行はどこから来たのか」を答えられるようにするためです。

AIの生のJSONを捨てないでください。 人が直した結果だけを残すと、何を直したのかが分からなくなります。差分が残っていれば、プロンプトのどこを直せば次から間違えないかが見えます。 保存期間は社内の文書規程に従います。紛争案件の記録は、終わってから数年後に別の案件で参照されることがあります。