法律事務所で相手方から届いた準備書面を要約し、主張ごとに認否と反論の論点・必要な証拠を整理した論点表の下書きを作る
相手方から届いた準備書面を読み、主張を1つずつ切り出して要約し、論点表の下書きを作ります。各行に、当方のこれまでの認否と主張、反論の論点の候補、依頼者に確かめる事実と必要な証拠の候補を並べます。
- 生成AI
- Azure OpenAI Service/Claude/Gemini
- 対象業界
- 保険/士業/金融
- 対象部門
- 法務
- 対象業務
- 書類作成/要約
- 主な課題
- 属人化している/書類作成に時間がかかる/確認ミスが多い
- AIで行う処理
- 要約
- 主な効果
- 入力漏れ削減/判断支援/工数削減
- 導入難易度
- ★★★★☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 相手方の書面が届いたら、パラリーガルが案件のフォルダに保存し、担当の弁護士に知らせる
- 若手の弁護士が書面を通読し、主張の段落ごとに見出しと要旨をメモする
- 当方のこれまでの書面を開き、同じ事実について当方が何と言ってきたかを探す
- 相手方が引用した証拠の番号を拾い、証拠の一覧と照らす
- 論点表の行を足し、要旨・当方の従前の主張・反論の方向・必要な証拠を書く
- 依頼者に確かめる事実の一覧を作る
- 主任の弁護士が論点表を見て、認否と反論の方針を決める
- 人パラリーガルが相手方の書面を案件のフォルダの所定の場所に保存する
- 自動保存をきっかけに処理が動き、書面の本文を段落ごとに切り出す
- 自動同じ案件の当方の過去の書面と、証拠の一覧を引く
- 自動AI が、段落ごとに主張を切り出し、事実と評価に分け、要約する
- 自動AI が、各主張について当方の過去の書面の該当箇所を抜き出し、反論の論点と必要な証拠の候補を挙げる
- 自動プログラムが、すべての段落が表のどこかに入ったかを照合し、入らなかった段落を一覧にする
- 人若手の弁護士が、表を書面の原文と照らし、入らなかった段落を確かめる
- 人主任の弁護士が、認否と反論の方針を決め、依頼者に確かめる事実を選ぶ
各工程の詳しい説明を読む
- 相手方の書面が届いたら、パラリーガルが案件のフォルダに保存し、担当の弁護士に知らせる
- 若手の弁護士が書面を通読し、主張の段落ごとに見出しと要旨をメモする
- 当方のこれまでの書面を開き、同じ事実について当方が何と言ってきたかを探す
- 相手方が引用した証拠の番号を拾い、証拠の一覧と照らす
- 論点表の行を足し、要旨・当方の従前の主張・反論の方向・必要な証拠を書く
- 依頼者に確かめる事実の一覧を作る
- 主任の弁護士が論点表を見て、認否と反論の方針を決める
(a)通読して表にするのに時間がかかる。 40ページの書面なら、通読だけで1時間かかります。段落ごとに当方の過去の書面を探しに行くので、表の行を1つ足すたびに別のファイルを開くことになります。
(b)認否の検討から漏れる主張が出る。 前の書面の主張を引き直した段落や、評価の段落に紛れ込んだ事実は、見出しだけを追うと読み飛ばします。漏れに気づくのは、次の当方の書面を書き始めてからです。
(c)表の作り方が人によって違う。 ある弁護士は事実と評価を分け、別の弁護士は分けません。主任の弁護士が複数の案件を見るとき、表ごとに読み方を変えなければなりません。
(d)提出期間が迫ると論点表が省かれる。 裁判長は、準備書面の提出の期間を定めることができ、期間を過ぎて出す当事者は理由を説明しなければなりません。期間が短いと、論点表を作らずに当方の書面を書き始めます。 漏れが起きやすいのは、まさにそのときです。
- 【人】 パラリーガルが相手方の書面を案件のフォルダの所定の場所に保存する
- 【自動】 保存をきっかけに処理が動き、書面の本文を段落ごとに切り出す
- 【自動】 同じ案件の当方の過去の書面と、証拠の一覧を引く
- 【自動】 AI が、段落ごとに主張を切り出し、事実と評価に分け、要約する
- 【自動】 AI が、各主張について当方の過去の書面の該当箇所を抜き出し、反論の論点と必要な証拠の候補を挙げる
- 【自動】 プログラムが、すべての段落が表のどこかに入ったかを照合し、入らなかった段落を一覧にする
- 【人】 若手の弁護士が、表を書面の原文と照らし、入らなかった段落を確かめる
- 【人】 主任の弁護士が、認否と反論の方針を決め、依頼者に確かめる事実を選ぶ
6番目が、この設計の分かれ目です。 AIの要約は、どの段落を拾ったかを自分では保証しません。拾われなかった段落をプログラムが出すことで、漏れが人の目に入ります。
8番目を自動にしないのは、意図してのことです。 認否は、依頼者が何を知っていて何を認めるかで決まります。AIは依頼者の話を聞いていません。 表の認否の列は、空欄のまま主任の弁護士に渡ります。
02今回想定するシステム構成
相手方の準備書面(裁判所のシステムから受け取った電子データ/スキャンしたもの) │ パラリーガルが案件のフォルダの所定の場所に保存 ▼【トリガー】保存 Azure Functions ├──▶ 本文の取り出しと、段落への切り出し(段落番号を付ける) ├──▶ 同じ案件の当方の過去の書面を取得(段落番号つき) └──▶ 証拠の一覧(甲号証・乙号証)を取得 ▼ Azure OpenAI(Microsoft Foundry) │ ① 主張の切り出し、事実と評価の区別、要約 │ ② 当方の過去の書面の該当箇所、反論の論点と必要な証拠の候補 ▼ Azure Functions ── 段落の網羅の照合、証拠の番号の照合、表の作成 ▼ 【若手の弁護士が原文と照らす】 ▼ 【主任の弁護士が認否と方針を決める】 ▼ SharePoint(案件のフォルダの論点表)
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 生成AI | Azure OpenAI(Microsoft Foundry) | Claude API、Gemini API |
| 連携 | Azure Functions(切り出し、照合、表の作成) | Azure Logic Apps |
| 保管 | SharePoint(案件のフォルダ、論点表、入出力の控え) | 事務所のファイルサーバー |
案件のフォルダと論点表は、新しく足すものではありません。 この構成は論点表の下書きを別のファイルとして置くだけで、弁護士が使っている確定版の論点表には書き込みません。
生成AIを Azure OpenAI にするのは、事件の記録を事務所の取り決めの中で扱いやすいためです。 Microsoft Learn のデータ、プライバシー、セキュリティのページでは、プロンプトと出力は他のお客様に提供されず、OpenAI にも提供されず、モデルやサービスの改善に使われないとされています。グローバルやデータ ゾーンのデプロイの種類を使う場合を除き、プロンプトと応答はお客様が指定した地域内で処理されるとされています。
出力の形は構造化出力で固めます。 公式のページでは、構造化出力ではモデルが指定した JSON スキーマに従い、Chat Completions API では response_format、Responses API では text.format にスキーマを書くとされています。表の列をスキーマで決めておけば、案件や担当が変わっても同じ形の論点表が出ます。
03どうやって実装するのか
処理の起点を決める
相手方の書面が案件のフォルダの所定の場所に保存されたことを起点にします。 所定の場所は「相手方書面」のような決まった名前のフォルダにし、そこに置かれたファイルだけを処理します。 当方の書面の下書きや依頼者からの資料が置かれる場所とは分けます。
保存と同時に、書面の種類と提出の日付を入れてもらいます。 準備書面か答弁書か、第何準備書面かは、ファイル名ではなく入力の欄で受け取ります。表の行に「どの書面の何段落目か」を書くとき、この情報が出どころになります。
届いたその日のうちに下書きを出します。 提出期間が短い案件ほど、論点表が省かれやすいからです。下書きが当日に出れば、論点表を作るかどうかを迷う必要がなくなります。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 相手方の書面 | 準備書面・答弁書の本文(電子データ、またはスキャンしたもの) | 案件のフォルダ |
| 書面の情報 | 書面の種類、第何準備書面か、提出の日付 | 保存のときの入力 |
| 当方の過去の書面 | 訴状または答弁書と、これまでの準備書面の本文 | 案件のフォルダ |
| 相手方の過去の書面 | これまでに届いた書面の本文 | 案件のフォルダ |
| 証拠の一覧 | 甲号証・乙号証の番号、標目、作成者、作成日、立証の趣旨 | 証拠説明書と事務所の証拠の一覧 |
| 論点表の型 | 列の定義と、事実と評価の分け方の決まり | 事務所で定める |
質を決めるのは、当方の過去の書面がそろっていることです。 訴状や答弁書が欠けていると、「当方の従前の主張」の列が空になり、AIは当方の主張が無いものとして反論の論点を挙げます。 書面の一覧を案件ごとに持ち、欠けていれば処理の前に知らせます。
依頼者との打合せのメモは、入力に入れません。 依頼者の言ったことと、書面に書いたことを混ぜると、まだ主張していないことを「当方の従前の主張」として表に書くおそれがあります。依頼者の話は、主任の弁護士が表を見ながら照らします。
データの取得方法を決める
| 取るもの | どこから | 何に使うか |
|---|---|---|
| 相手方の書面の本文 | 案件のフォルダの所定の場所 | 主張の切り出し |
| 当方の過去の書面の本文 | 案件のフォルダの当方の書面の場所 | 従前の主張の抜き出し |
| 相手方の過去の書面の本文 | 案件のフォルダの相手方の書面の場所 | 主張の変化の確認 |
| 証拠の一覧 | 事務所の証拠の一覧のファイル | 引用された証拠の番号の照合 |
書面は段落ごとに番号を付けて渡します。 番号は「第3準備書面・第2・1・(2)・第2段落」のように、書面の見出しの階層と段落の順から作ります。AIには、どの段落から主張を切り出したかを、この番号で答えさせます。 番号で答えさせることで、第6章の網羅の照合ができます。
当方の過去の書面は、全文を毎回渡しません。 書面が10通を超える案件では、量が多くなりすぎます。相手方の今回の書面の見出しの語で当方の過去の書面の段落を絞り込み、候補の段落だけを渡します。 絞り込みで落ちた段落があっても、主任の弁護士の確認で拾える余地を残します。
AIへ渡す前に整形する
- 本文の取り出し … 電子データは文字をそのまま取り出します。スキャンしたものは、読み取りの品質を担当者が確かめてから使います
- ヘッダー・フッター・頁番号の除去 … 事件番号や頁番号が段落の途中に入らないようにします
- 段落への切り出しと番号付け … 見出しの階層(第1、1、(1)、ア)を読み取り、段落に番号を付けます
- 証拠の番号の拾い出し … 本文の「甲第3号証」「乙5」などを拾い、表記をそろえます
- 当方の過去の書面の絞り込み … 見出しの語で候補の段落を選びます
- 依頼者の個人情報の扱いの確認 … 当事者の氏名・住所は事件の記録として必要な範囲で残し、事件と関係の無い第三者の情報は伏せます
3番目が、この構成でいちばん手間のかかるところです。 書面ごとに見出しの書き方が違い、「第1」の次が「1」のこともあれば「(1)」のこともあります。切り出しに失敗すると、2つの主張が1つの段落になり、片方が表から消えます。 切り出した段落の数と、見出しの数を比べて、極端にずれていれば人に回します。
切り出した段落は、次のような形で AI に渡します。番号は見出しの階層をそのままつないだもので、表の「出どころ」の列にもこの番号が入ります。
[P3-2-1-1] 第2 1 (1) 第1段落
原告は、令和○年○月○日、被告との間で本件契約を締結した(甲1)。
[P3-2-1-2] 第2 1 (1) 第2段落
被告は、同契約に基づく代金の支払期限である同年○月末日を経過しても、
代金を支払わなかった。被告の行為は債務不履行に当たる。
[P3-2-2-1] 第2 2 第1段落
被告は答弁書において、検収が終わっていないと主張するが、失当である。
2つ目の段落には、事実(支払わなかった)と評価(債務不履行に当たる)が並んでいます。 これを1行にまとめさせず、事実と評価の2行に分けさせるのが1回目の指示の要点です。3つ目の段落は、当方の主張を引いたうえでの評価なので、relation と当方の従前の主張の列で扱います。
4番目は、AIに任せずにプログラムで行います。 証拠の番号は形が決まっているので、正規表現で拾えます。拾った番号を証拠の一覧と照らし、一覧に無い番号を「未提出の証拠の引用」として出します。
AIに処理させる
させるのは、2回に分けて2つです。 1回目は主張の切り出しと要約、2回目は当方の過去の書面との突き合わせと検討の材料です。
| 見るもの | させること | 判断できないときの扱い |
|---|---|---|
| 相手方の段落(1回目) | 主張を1つずつ切り出し、事実か評価かを分け、1〜2文で要約する | 分けられなければ mixed |
| 主張の出どころ(1回目) | どの段落番号から切り出したかを書く | ― |
| 前の書面との関係(1回目) | 相手方の前の書面の主張と同じか、変わったか、新しいか | 判断できなければ unknown |
| 当方の過去の書面(2回目) | 同じ事実について当方が書いた段落を抜き出し、その文を写す | 見つからなければ「該当なし」 |
| 反論の論点(2回目) | 相手方の主張の弱いところの候補を、書面と証拠の一覧に書かれたことから挙げる | 挙げられなければ空 |
| 必要な証拠(2回目) | 証拠の一覧から関係しそうな証拠と、依頼者に確かめる事実の候補 | 一覧に無ければ「依頼者に確認」 |
1回目の「事実か評価か」が、この構成でいちばん大事な列です。 事実の主張は認否の対象として必ず表に残し、評価は反論の対象として別に扱います。mixed の段落は、弁護士が事実の部分を切り分けます。
2回目の「当方の過去の書面」は、要約させず、文を写させます。 当方が「否認する」と書いたのか「不知」と書いたのかで、意味が違います。民事訴訟法第159条第2項は、相手方の主張した事実を知らない旨の陳述をした者は、その事実を争ったものと推定するとしています。要約すると、この違いが消えます。
| させないこと | 理由 |
|---|---|
| 認否の決定 | 依頼者の話と証拠を踏まえて弁護士が決める |
| 反論の方針の決定 | 主任の弁護士が案件全体を見て決める |
| 裁判例や学説の引用 | 書面に書かれていない出典を持ち込ませない |
| 当方がまだ主張していないことを「従前の主張」と書く | 依頼者の話と書面を混ぜない |
| 証拠の内容の推測 | 証拠の一覧に書かれた標目と立証の趣旨だけを使う |
| 相手方の主張の要約に評価を混ぜる | 「不当な主張」などの言葉を表に入れない |
3行目がいちばん起きやすい失敗です。 反論の論点を挙げさせると、AIは関係しそうな裁判例を名前つきで書くことがあります。実在しない裁判例が論点表に載ると、そのまま当方の書面の下書きに流れ込むおそれがあります。 出典が要る論点は、弁護士が調べます。
指示内容を固定する
あなたは法律事務所で、相手方の準備書面を整理する立場です。
渡すのは、相手方の書面を段落ごとに番号を付けて切り出したものです。
書面に書かれていることだけを使い、推測で補わないでください。
【作るもの】
段落ごとに、含まれている主張を1つずつ切り出し、次を書いてください。
1. source_paragraphs:切り出した段落の番号(複数可)
2. kind:fact(事実の主張)/ evaluation(法的な評価)/ mixed(分けられない)
3. summary:主張の要約(1〜2文。相手方の言い方を変えずに)
4. quote:要約の根拠にした文(原文のまま)
5. relation:前の書面と同じ same / 変わった changed / 新しい new / unknown
6. cited_evidence:引用された証拠の番号(書かれている分だけ)
【厳守事項】
- 1つの段落に複数の事実が書かれていれば、事実ごとに分けてください。
まとめて1つにしないでください。
- 事実と評価が1文に混ざっていて分けられなければ、mixed にしてください。
- summary に「不当」「失当」などの評価の言葉を足さないでください。
- 認める・否認する・不知・争うのどれにすべきかを書かないでください。
- 裁判例、学説、条文を、書面に書かれていないのに書かないでください。
- 証拠の内容を推測して書かないでください。番号だけを写してください。
- 主張が含まれない段落(あいさつ、目次、引用だけの段落)は、
source_paragraphs に入れず、no_claim_paragraphs に番号を入れてください。
- どの段落も、主張を切り出したか no_claim_paragraphs に入れたかの
どちらかにしてください。
【書面の情報】{brief_meta}
【相手方の前の書面の主張の一覧】{previous_claims}
【今回の書面(段落番号つき)】{paragraphs}
最後の2行の指示が、網羅の照合の土台です。 すべての段落を「主張を切り出した」か「主張が無い」かのどちらかに入れさせることで、どちらにも入っていない段落を、プログラムが機械的に見つけられます。 入っていない段落は、AIが読み飛ばした段落です。
「認否を書かない」を明記しないと、認否の列を埋めます。 表に「否認」と書かれていると、若手の弁護士はそれを前提に読みます。依頼者に確かめる前の認否が、確かめた後の認否のように見えることが問題です。
2回目の指示では、1回目の主張の一覧と、絞り込んだ当方の過去の書面の段落、証拠の一覧を渡し、「当方の過去の書面の文は原文のまま写す」「該当が無ければ該当なしと書く」を厳守させます。
出力形式を固定する
1回目は、次の形の JSON で受け取ります。
{
"brief_id": "",
"claims": [
{
"claim_id": "",
"source_paragraphs": [""],
"kind": "fact | evaluation | mixed",
"summary": "",
"quote": "",
"relation": "same | changed | new | unknown",
"cited_evidence": [""]
}
],
"no_claim_paragraphs": [""]
}
2回目は、主張ごとに次の形で受け取ります。
{
"claim_id": "",
"our_prior_statements": [
{ "brief": "", "paragraph": "", "quote": "" }
],
"rebuttal_points": [""],
"related_evidence": [""],
"facts_to_confirm_with_client": [""]
}
1つ目の理由は、網羅をプログラムで確かめられることです。 source_paragraphs と no_claim_paragraphs を合わせた段落の番号を、切り出した段落の一覧と照らします。差が出れば、その段落を「未処理の段落」として表の先頭に出します。
2つ目は、quote を原文と照らせることです。 プログラムが quote の文字列を原文の段落から探し、見つからなければその行に印を付けます。 要約がどの文から来たかを、人が探さずに済みます。
3つ目は、表の形を案件にかかわらずそろえられることです。 論点表の列は次のように決まります。
| 列 | 中身 | 作るもの |
|---|---|---|
| 出どころ | 書面と段落の番号 | AI(1回目)の番号をプログラムが整形 |
| 区分 | 事実/評価/分けられない | AI(1回目) |
| 相手方の主張 | 要約と原文 | AI(1回目) |
| 当方の従前の主張 | 当方の書面の段落と原文 | AI(2回目) |
| 認否 | 空欄 | 主任の弁護士が記入 |
| 反論の論点の候補 | 箇条書き | AI(2回目) |
| 証拠と確かめる事実 | 証拠の番号、依頼者に確かめる事実 | AI(2回目)とプログラムの照合 |
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 案件のフォルダ | Azure Functions のトリガー | 相手方の書面の保存を検知する |
| 案件のフォルダ | 読み取り | 当方・相手方の過去の書面、証拠の一覧 |
| Azure OpenAI | API 呼び出し | 主張の切り出しと要約、突き合わせと検討の材料 |
| 案件のフォルダ | ファイルの保存 | 論点表の下書きを別のファイルとして置く |
確定版の論点表には書き込みません。 下書きは「論点表_下書き_第3準備書面」のような別のファイルにし、弁護士が必要な行を確定版へ写します。 自動で確定版に書き込むと、照らす前の行が確定版に混ざります。
裁判所のシステムとはつなぎません。 書面の受け取りと提出は、弁護士とパラリーガルが従来どおり行います。
人が確認する
- 未処理の段落を確かめる … 表の先頭に出た段落を読み、主張があれば行を足します
- 原文との照合 …
quoteに印が付いた行と、mixedの行を原文で確かめます - 当方の従前の主張を確かめる … 「該当なし」の行は、絞り込みで落ちていないかを当方の書面で探します
- 認否と方針を決める … 主任の弁護士が、認否の列を埋め、反論の論点を選びます
- 依頼者に確かめる事実を選ぶ … 候補から、依頼者に聞く事実を選んで連絡します
1番目を省かないでください。 未処理の段落は、AIが読み飛ばした段落か、切り出しに失敗した段落です。どちらも、放っておけば認否の検討から漏れます。
目標は、30通をならして1通36分です。 短い書面は照合が早く済み、新しい主張の多い長い書面は時間がかかります。
例外に対処する
| 起きること | 対応 |
|---|---|
| スキャンした書面の文字が取れない | 処理せず、担当者に戻す。電子データを取り寄せられるかを確かめる |
| 段落の切り出しの数が見出しの数と大きくずれる | 下書きを作らず、人が切り出す |
| 当方の過去の書面が欠けている | 処理の前に知らせ、そろってから動かす |
| 引用された証拠の番号が一覧に無い | 「未提出の証拠の引用」として表に出す |
quote が原文に見つからない | その行に印を付け、人が原文で確かめる |
| 未処理の段落が出る | 表の先頭に出し、人が確かめる |
| 書面が長く一度に渡せない | 見出しの単位で分けて1回目を行い、最後に主張の一覧をつなぐ |
| AI の応答が無い・形が崩れる | 担当者に知らせ、従来どおり手で論点表を作る |
2行目と6行目が、この構成で一番効く例外です。 どちらも、主張が表から消える経路をふさぐためのものです。
記録を残す
- 相手方の書面の原本と、書面の情報(種類、第何準備書面か、提出の日付)
- 切り出した段落と番号の一覧
- AI に渡した入力と、返ってきた JSON の全文
- 網羅の照合と、
quoteの照合の結果 - 人が直した記録 … どの行を足し、どの行を直したか
- 確定版に写した行
人が直した記録は、切り出しの規則の見直しに使います。 同じ相手方の代理人の書面で毎回同じ種類の段落が未処理になるなら、見出しの書き方に合わせて切り出しの規則を足します。
ログは案件のフォルダと同じ権限で守ります。 事件の記録そのものなので、事務所の中でも、その案件の担当者だけが見られる場所に置きます。
04実装レベルの3段階
最小構成では、当方の過去の書面を探す作業が手で残ります。 確かめるための段階です。 半自動化で、1通120分が70分程度になります。 通読と要旨のメモは減りますが、当方の過去の書面を探す作業と表への記入が残ります。本格構成で36分になり、この段階が本記事の想定です。 段階を飛ばさないでください。 半自動化の段階で、どの代理人の書面で切り出しが失敗するかが分かります。切り出しの規則を固めてから本格構成に進むほうが、未処理の段落が減ります。 本格構成に進んだあとも、案件の種類で効き方が違います。 取引の代金や損害の額を争う案件は、事実の主張が多く、前の書面の引き直しも多いので、網羅の照合がよく効きます。法律の解釈そのものを争う案件は評価の段落が中心で、論点表の下書きより、主任の弁護士の検討の比重が大きくなります。 どの種類の案件から使い始めるかを、事務所で先に決めておきます。
05工数削減シミュレーション
導入後 30件 × 36分 ÷ 60 = 18 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 民事訴訟を常時数十件抱え、相手方の準備書面が毎月数十通届く法律事務所。企業の法務部で、訴訟を外部の弁護士と分担しながら社内でも主張の整理をしている場合。準備書面を読んで論点表を作る作業が若手の弁護士やパラリーガルに集中し、表の作り方が人によって違う場合。案件ごとの書面と証拠が一つの場所にそろっていて、Microsoft Azure の利用について事務所の取り決めができる場合。
- 訴訟がごく少なく、相手方の書面も短い場合。案件の書面がメールの添付や個人のフォルダに散らばり、当方の過去の書面と証拠の一覧を引けない場合。依頼者との取り決めで、事件の記録を外部のクラウドサービスで処理することが認められていない場合。なお、何を認め何を争うか、どの論点で反論しどの証拠を出すかは、依頼者の意向を踏まえて弁護士が決めるもので、この構成では代替できません。
07最小構成で試す方法
- 終わった案件から、相手方の準備書面を3通選ぶ(長いもの、前の書面の引き直しが多いものを入れる)
- 依頼者との取り決めで外部での処理が認められているかを確かめ、認められた案件だけを使う
- 社内で利用を認められた Azure OpenAI の環境で、段落番号を付けた書面を渡し、第7章の1回目の指示で主張を切り出させる
- 当時の論点表と比べ、漏れた主張と、事実と評価の分け方を確かめる
- 段落の番号を数え、どの段落にも入らなかったものが出るかを見る
3通は、当時の論点表が残っている案件を選んでください。 正解が手元にあるので、漏れと要約の誤りを1行ずつ確かめられます。
| 出てきた内容 | 判断 |
|---|---|
| 当時の論点表と同じ主張が、段落番号つきで出る | 案件のフォルダとの連携に進む |
| 1段落の複数の事実が1つにまとめられる | 指示の書き方で直る。構成は有効 |
| 段落の切り出しがずれる | 切り出しの規則が先。 AIの問題ではない |
3行目が出ることは珍しくありません。 失敗ではなく、その書面の見出しの書き方を規則に足せばよいということです。
試すときは、段落番号を付ける作業を手で行ってかまいません。 3通なら、見出しごとに番号を書き込むだけで1時間ほどで済みます。手で付けてみると、どの書き方の見出しで切り出しが迷うかが分かり、半自動化で作る規則の下書きにそのまま使えます。比べた結果は、漏れた主張の数と、事実と評価の分け方が当時の表と違った行の数で記録しておきます。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 主張が表から漏れる | 全段落をどちらかに入れさせ、照合で未処理の段落を出す |
| 1段落の複数の事実が1行になる | 事実ごとに分けるよう指示し、mixed を人が切り分ける |
| 認否の列が埋まる | スキーマに認否の項目を作らない。列は空欄で出す |
| 実在しない裁判例が書かれる | 書面に無い出典を書かせない。出典は弁護士が調べる |
| 当方の従前の主張が要約で変わる | 原文のまま写させる。「不知」と「否認」を混ぜない |
| 依頼者の話が従前の主張に混ざる | 打合せのメモを入力に入れない |
| 段落の切り出しがずれる | 見出しの数と段落の数を比べ、ずれれば人に回す |
| 証拠の番号の表記がばらばら | プログラムで拾ってそろえる |
| 当方の過去の書面が欠けている | 処理の前に知らせる |
| 確定版の論点表に書き込む | 下書きを別のファイルにする |
| 要約に評価の言葉が混ざる | 「不当」「失当」などを足さないよう指示する |
上の3行が、この構成の失敗のほとんどです。 どれも「AIの表がそれらしく見える」ところから出発しています。
運用の面でつまずくのは、下書きが「確定したもの」として回覧されることです。 下書きのファイルが案件のフォルダに置かれると、主任の弁護士が若手の確認を待たずに開き、そのまま方針を考え始めることがあります。下書きのファイル名と表の先頭に「未照合」の印を付け、若手の弁護士が照合を終えたら印を外す運用にしておくと、どこまで確かめた表かが一目で分かります。漏れはプログラムで見つけ、認否は空欄で渡すことで、運用に乗るかが決まります。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 事件の当事者の氏名・住所、紛争の経過、依頼者の主張と証拠の内容、相手方の主張です。
- 依頼者との取り決めを先に確かめる … 事件の記録を外部のクラウドサービスで処理してよいかは、依頼者との取り決めと事務所の規程によります。認められていない案件は、この構成の対象から外します
- 処理の地域を決めておく … 公式のページでは、グローバルやデータ ゾーンのデプロイの種類を使う場合を除き、地域内で処理されるとされています。どのデプロイの種類を使うかを事務所の取り決めに書きます
- 不正使用の監視の扱いを確かめる … 公式のページでは、不正使用の可能性が検出されるとプロンプトと出力のサンプルがレビューの対象になり、必要に応じて人が確認するとされています。管理対象のお客様は、不正使用の監視の変更を申請できるとされているので、事件の記録を扱う前に申請の要否を検討します
- 事件と関係の無い第三者の情報を伏せる … 書面に出てくる第三者の情報で、論点の整理に要らないものは前処理で伏せます
- 認否と方針を AI に寄せない … 何を認め何を争うかは、依頼者の意向と証拠を踏まえて弁護士が決めます。この構成が出すのは整理の材料だけです
- 権限を案件の担当に絞る … 論点表の下書きとログは、案件のフォルダと同じ権限で守ります
誤りが起きた場合のリスクは、相手方の主張が表から漏れることと、表に書かれた要約や従前の主張が原文と違うことの2つです。 前者は網羅の照合で、後者は quote の照合で防ぎます。どちらも、AIの外に置いた仕組みで守ります。
10まず何から始めるか
1週目:案件のフォルダと論点表の型をそろえる
案件のフォルダに、相手方の書面・当方の書面・証拠の一覧の置き場所を決めます。論点表の列を事務所で1つの型にそろえ、事実と評価の分け方の決まりを文書にします。
2週目:3通で試す
終わった案件の書面3通で主張を切り出させ、当時の論点表と比べます。漏れた主張が無いか、事実と評価が分かれているかを最優先で見ます。
3週目:段落の切り出しと網羅の照合を作る
見出しの階層を読み取って段落に番号を付け、全段落がどこかに入ったかを照合する仕組みを作ります。この照合が、この構成の安全装置です。
4週目:保存から下書きまでをつなぐ
所定の場所への保存を起点に、切り出し・要約・照合・下書きの保存までをつなぎます。この時点では、若手の弁護士が従来どおり自分でも論点表を作り、下書きと比べます。
2か月目: 当方の過去の書面と証拠の一覧との突き合わせを足します。3か月目以降: 1通120分が何分になったかを実測し、未処理の段落の出方から切り出しの規則を見直した時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| 当事者が相手方の主張した事実を争うことを明らかにしない場合にはその事実を自白したものとみなすこと。知らない旨の陳述をした者はその事実を争ったものと推定すること(第159条)。準備書面に攻撃又は防御の方法と、相手方の請求及び攻撃又は防御の方法に対する陳述を記載すること(第161条)。裁判長が準備書面の提出の期間を定めることができ、期間の経過後に提出する当事者は理由を説明しなければならないこと(第162条)。委任を受けた訴訟代理人が電子情報処理組織を使用して申立て等をしなければならないこと(第132条の11) | e-Gov 法令API: 民事訴訟法 | 2026-10-08 |
構造化出力でモデルが指定した JSON スキーマに従うこと。Chat Completions API では response_format、Responses API では text.format にスキーマを書くこと。すべてのフィールドを必須にすること。additionalProperties: false を設定すること | Microsoft Learn: Azure OpenAI で構造化出力を使用する方法 | 2026-10-08 |
| プロンプトと出力が他のお客様に利用されず、OpenAI に提供されず、モデルやサービスの改善に使われないこと。グローバル・データ ゾーン以外のデプロイの種類では指定した地域内で処理されること。不正使用の可能性が検出されるとサンプルがレビューの対象になり、必要に応じて人のレビュー担当者が確認すること。管理対象のお客様が不正使用の監視の変更を申請できること | Microsoft Learn: Azure が販売する Foundry モデルのデータ、プライバシー、セキュリティ | 2026-10-08 |
何を認め何を争うか、どの論点で反論しどの証拠を出すかは、依頼者の意向を踏まえて弁護士が決めてください。 本記事は公開されている法令と公式ページで確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0968)についてのご相談はこちらから。
