Claude Media
陳述書の下書きをClaudeで作る — ヒアリング記録から時系列を整理する手順

陳述書の下書きをClaudeで作る — ヒアリング記録から時系列を整理する手順

依頼者のヒアリング記録をProjectsに入れ、出典付きの時系列表、客観証拠との食い違いの洗い出し、本人への確認質問、陳述書の下書きまでをClaudeで進める手順です。

陳述書の下書きでClaudeに任せやすいのは、ヒアリング記録を出来事に分解し、時系列に並べ、客観証拠と食い違う箇所を拾う作業です。任せにくいのは、記憶の穴を埋める作業です。依頼者が言っていないことを、もっともらしく補ってしまうと、陳述書は依頼者の言葉ではなくなります。

この記事は、Projectsで事件ごとの作業場を作り、「創作させない」縛りをプロジェクト指示に書いたうえで、時系列表、食い違いの抽出、本人への確認質問、下書きの順に進める手順をまとめます。証拠文書の側から時系列を組む方法はディスカバリー文書のタイムライン分析にあり、ここでは依頼者の供述の側を扱います。以下は作業手順の整理であり、個別の事件に対する法的助言ではありません。

陳述書づくりでClaudeを使うときの分担

先に分担を決めておくと、プロンプトの書き方が定まります。

くらべる

Claudeに任せる作業と、人が持つ判断

整理

Claudeに任せる

  • 記録を出来事の最小単位に分ける
  • 日付順に並べ、出典を付ける
  • 客観証拠と供述の食い違いを拾う
  • 本人に聞く質問の案を作る
  • 確定した事実を、本人の語彙で文章にする
判断

人が持つ

  • どの事実を陳述書に載せるか
  • 不利な事実の扱い
  • 食い違いの理由が何か
  • 本人の言葉として正しいかの最終確認
  • 提出するかどうか

右側の判断を、Claudeの出力が先回りして決めてしまわないことが、この手順の骨格です。以降のプロンプトは、左側だけを頼む形に揃えています。

事件ごとにProjectsを作り、縛りを指示に書く

Projectsは、独自のチャット履歴と知識ベースを持つ作業場です。無料アカウントを含む全ユーザーが使え、無料では作れる数が5つまでです。

作成画面でプロジェクトに付ける名前と説明は、Claudeからは見えません。事件名や依頼者名を入れても、Claudeの回答には反映されない一方、一覧には残ります。名前は事件番号のような記号にしておくと、共有画面やスクリーン共有でも依頼者名が出にくくなります。

知識ベースに入れるのは、次の3種類です。

  • ヒアリング記録(逐語に近いメモ、面談の文字起こし)
  • 客観証拠の一覧(メール、契約書、診断書、写真、通帳の写しなど。日付と内容の要約を付けたもの)
  • 事務所の陳述書の書式例

プロジェクト指示には、全チャットに効く縛りを置きます。プロジェクト指示は、そのプロジェクト内のすべてのチャットで使われます。次は書き方の一例です。

プロジェクト指示の例(創作させない縛り)
あなたは弁護士の補助として、依頼者の陳述書の下書きの材料をまとめます。
 
守ること:
1. 事実は知識ベースの記録と証拠一覧に書かれたものだけを使う。
   書かれていない日付・人名・金額・発言・動機を補わない。
2. 記録に無い点は、推測せず「要確認」と書き、本人への質問にする。
3. 事実を述べるときは必ず出典を付ける。
   形式は [面談YYMMDD メモ番号] または [証拠番号]。
4. 供述どうしが食い違うとき、どちらが正しいかを判定しない。
   両方を併記し、確認のための質問を作る。
5. 依頼者に不利な事実も省かず、別の欄に「不利な可能性」と付けて出す。
   載せるかどうかは弁護士が決める。
6. 文体は依頼者本人の一人称。記録にある本人の言い回しを優先し、
   法律用語に言い換えない。

5番を入れる理由があります。依頼者の主張に沿う事実だけを集めさせると、都合の悪い記述が出力から静かに消えます。消えたことに誰も気づかないまま陳述書ができると、相手方の反対尋問や反論で初めて表に出ます。出力には残し、扱いは弁護士が決める形にしておきます。

もう1点、チャットをまたぐ文脈の扱いです。プロジェクト内でも、チャットどうしの文脈は共有されません。共有したい情報は知識ベースに入れる必要があります。時系列表が固まったら、ファイルとして知識ベースに追加しておくと、次の作業チャットが同じ表から始められます。

手順1: ヒアリング記録を出来事に分解する

最初の作業は、記録を「いつ・どこで・誰が・何をした」の単位に割ることです。文章にまとめるのは後です。

プロンプト例(出来事への分解)
知識ベースの面談メモ(面談240901、面談240915)から、
依頼者本人が体験した出来事を1件ずつ抜き出してください。
 
列: 通し番号 / 日付(本人が言った表現のまま) / 場所 / 登場人物 /
    出来事 / 出典 / 日付の確かさ(本人が断言・おおよそ・不明)
 
日付が「去年の夏ごろ」のようにあいまいなら、そのまま書き、
推測で特定の日付に直さないでください。
伝聞(他人から聞いた話)は「伝聞」と明記してください。

「日付の確かさ」の列が、後の工程で効きます。本人が断言した日付と、本人もあいまいな日付を同じ重みで並べると、時系列表が実際より確からしく見えます。伝聞と体験の区別も、同じ理由で最初に分けておきます。

手順2: 出典付きの時系列表にまとめる

分解した出来事を、日付順の表にします。次の形は、一例として示す列構成です。

No.日付出来事出典(供述)対応する客観証拠確かさ
3日付2024/4/12出来事上司から口頭で配置転換を告げられた出典(供述)面談240901-7対応する客観証拠証拠5(同日のメール)確かさ断言
4日付2024年5月ごろ出来事新部署で業務を始めた出典(供述)面談240901-9対応する客観証拠なし確かさおおよそ

「対応する客観証拠」の欄は、ここで空欄を作るためにあります。証拠が付いていない供述が一目で見えれば、依頼者に追加の資料を頼む箇所が分かります。

証拠一覧が長い案件では、プロジェクトの知識がコンテキストウィンドウの上限に近づくと、有料プランでは検索ベースの方式(RAG)に自動で切り替わります。RAGでは、関連する箇所を取り出して回答する仕組みなので、時系列表の作成のように全体を通して読む作業では、拾い漏れが起こりえます。その場合は、期間や論点で分割して依頼し、行数を数え直す運用が安全です。切り替わりの仕組みはRAG検索の仕組みと全文投入との違いにまとめています。

手順3: 客観証拠との食い違いを抽出する

時系列表ができたら、供述と証拠のずれを拾います。ここで頼むのは、ずれの一覧と確認質問までです。どちらが正しいかの判断は頼みません。

プロンプト例(食い違いの抽出)
時系列表の各行について、依頼者の供述と客観証拠の内容を比べ、
食い違いまたは不整合を一覧にしてください。
 
列: 該当No. / 供述の内容 / 証拠の内容 / 食い違いの種類
    (日付・金額・人物・順序・有無)/ 依頼者への確認質問
 
制約:
- どちらが正しいかを判定しない。
- 質問は「はい・いいえ」で答えられる形にせず、
  「その日のことを、思い出せる範囲で教えてください」のように
  依頼者が自分の言葉で答える形にする。
- 質問文に、証拠の内容から導いた答えを含めない。

最後の制約が重要です。「メールには4月12日と書いてありますが、4月10日というのは勘違いですよね」のような質問文は、答えを誘導します。誘導された回答は本人の記憶ではなく、質問者の見立てが入った供述になります。質問案はClaudeが作っても、そのまま使うか、言い換えるかは弁護士が決めます。

出てくる食い違いは、大きく三つに分かれます。

整理

食い違いの典型と、次の動き

  • 日付や金額のずれ

    記憶違いか、証拠の側の誤記かを本人に確かめます。本人が思い出せないなら、陳述書では「ごろ」と書く判断もあります。

  • 順序の逆転

    出来事Aと出来事Bのどちらが先かが、供述と証拠で逆になるものです。因果関係を語る箇所に影響するため、優先して確かめます。

  • 証拠に無い供述

    食い違いではなく、裏付けが無い状態です。追加の資料を探すか、本人の認識として書くかを分けます。

手順4: 本人に確認し、答えを本人の言葉で記録する

質問への回答は、次の面談または電話で得ます。ここは人が行う工程です。回答は、整えずに、言った通りの言い回しで知識ベースの記録に追加します。

追加した回答をもとに、時系列表の該当行を更新するよう頼みます。このとき、更新前の行は消さず、履歴として残すように指示します。供述が途中で変わった経緯は、事件の評価に関わる情報だからです。

プロンプト例(回答の反映)
面談241003のメモを知識ベースに追加しました。
時系列表のNo.3、No.7、No.11について、新しい回答を反映してください。
変更前の記述は「旧」として残し、変更後を「新」として併記し、
変わった点を1行で書いてください。
本人の回答に無い内容は補わないでください。

手順5: 陳述書の文章に起こす

事実が固まった行だけを、一人称の文章にします。文体は、依頼者が普段使う言葉に寄せます。難しい法律用語に言い換えると、後で尋問を受けたときに本人が自分の文書として説明しづらくなります。

プロンプト例(下書きの生成)
時系列表の「確定」欄が○の行だけを使い、
依頼者の一人称で陳述書の下書きを書いてください。
 
- 1段落につき1つの出来事とし、各段落の末尾に出典を [ ] で付ける。
- 面談メモにある本人の言い回しを残す。
- 「要確認」の行は本文に入れず、末尾の「未確認事項」にまとめる。
- 評価や感想(「許せなかった」など)は、
  本人が面談で実際に言った場合だけ書く。

出典の角括弧は、提出前に外す作業用の印です。事務所の書式に合わせた整形は、書式例を知識ベースに入れておけば、別チャットで頼めます。

提出前の確認で、人が見る箇所

下書きの完成は、作業の終わりではありません。次の点は、必ず人が確かめます。

  • 本文のすべての事実に出典が付き、出典が実在の記録と一致しているか。出典番号そのものが誤っていることがあります
  • 記録に無い固有名詞、数字、発言が紛れ込んでいないか。下書きと時系列表を並べて照合します
  • 不利な事実の扱いを、弁護士が判断したか
  • 依頼者本人が、全文を読み、自分の言葉として間違いがないと確認したか。声に出して読んでもらうと、言い回しの違和感に気づきやすくなります
  • 依頼者が署名・押印する場合の手続きを、事務所の運用に沿って行っているか

どの工程でも、Claudeの出力は下書きの位置づけです。確認の責任は、これまで通り弁護士に残ります。

記録を預けるときの設定

ヒアリング記録には、依頼者の秘密が含まれます。守秘義務との関係は弁護士の守秘義務とClaudeの利用形態で、契約形態別に整理しています。ここでは、Projectsの操作に関わる設定だけを挙げます。

  • 個人向けのClaude(Free・Pro・Max)では、モデル改善への利用を許可していると、チャットが改善に使われることがあります。シークレットチャットは、許可していても改善に使われません。ただし、安全性の分類器にフラグが立った会話は、信頼性・安全性の用途に使われる場合があります
  • サポート記事は、機密性の高い個人情報や、機密のビジネス文書・個人文書の入力に慎重であるよう案内しています
  • メモリーは、Free・Pro・Maxでは既定でオンです。Team・Enterpriseでは、オーナーが有効にした場合に使えます。プロジェクトごとに独自のメモリーがあり、プロジェクト外のチャットとは分かれます。1回のチャットだけメモリーを切るには、最初のメッセージを送る前に「+」メニューでオフにします
  • Team・Enterpriseでは、プロジェクトの公開範囲を「非公開」(自分と招待したメンバーのみ)にできます。共有するときは、閲覧のみか編集可かを選べます。事件ごとに担当者だけを招待する運用にすると、他の案件の担当者に記録が見えません
  • プロジェクトをアーカイブしても、共有メンバーと権限は残ります。事件が終わったら、アーカイブとは別に、共有設定でメンバーを外します

契約上のデータ保持は、プランと利用方法で異なります。事務所として入力してよい範囲は、契約条項と所属弁護士会の指針に照らして決めます。

まとめ

陳述書の下書きでClaudeが役立つのは、供述を出来事に分け、証拠と突き合わせ、本人に聞くべき点を洗い出す工程です。文章化は、確定した事実だけを材料にします。プロジェクト指示の「補わない」「判定しない」「不利な事実を隠さない」の3点が、この手順の安全装置になります。

プロンプトを複数の事件で使い回すなら、指示文と書式例をひな形として手元に保存し、事件ごとのプロジェクトに貼る運用が使えます。法務レビューのチェックを標準化する考え方は法務レビューのプレイブックが参考になります。

この記事を共有:XはてブLinkedIn