tabular-review

/tabular-review

1. ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md を読み込みます → デューデリジェンスの構成、しきい値、社内書式を確認します。
2. 確認します：対象となる文書、列、出力先。
3. 型付きスキーマを作成します。.review-schema.yaml に書き込み、ユーザーに確認します。
4. サンプルを実行します（文書3〜5件）。スキーマを調整し、確認します。
5. 並列処理します。文書ごとにサブエージェントを1つ割り当てます。各セルには、値、状態、原文の引用、場所を記録します。
6. 正規化処理を行います。外れ値と不整合にフラグを付けます。
7. 出力：.xlsx または Google Sheets（どちらにするか確認します）。さらに、.csv、_sources.csv、Markdown 形式を必ず出力します。成果物ヘッダーを付けます。
8. 概要：検証作業量（列ごとの not_present／unclear／needs_review の件数）、フラグが付いた列、ファイルの保存先、すべてのセルは判断ではなく手掛かりであることを改めて伝えます。

/corporate-legal:tabular-review
/corporate-legal:tabular-review --schema .review-schema.yaml --docs ./vdr/02-Contracts/
/corporate-legal:tabular-review --template ma-diligence

--schema <path>： スキーマを作成する代わりに、既存のスキーマファイルを使用します。再実行や段階的な追加に便利です。

--template <name>： references/ のテンプレートを使用して開始します。現在は ma-diligence があります。

--docs <path>： 文書のソースです。ローカルフォルダー、Drive フォルダー ID、または VDR パスを指定します。省略すると、確認します。

--output <xlsx|gsheets|csv>： 出力形式です。省略すると、確認します。

--sample <n>： スキーマ確認用のサンプル数です。既定値は5です。

---

案件のコンテキスト

案件のコンテキスト。 実務レベルの CLAUDE.md で ## Matter workspaces を確認します。Enabled が ✗（社内ユーザー向けの既定値）の場合、この段落の残りはスキップします。スキルは実務レベルのコンテキストを使用し、案件関連の処理は表示されません。有効で、アクティブな案件がない場合は、「どの案件で使用しますか？ /corporate-legal:matter-workspace switch <slug> を実行するか、practice-level と指定してください。」と尋ねます。アクティブな案件の matter.md を読み込み、案件固有のコンテキストと上書き設定を確認します。出力は ~/.claude/plugins/config/claude-for-legal/corporate-legal/matters/<matter-slug>/ の案件フォルダーに書き込みます。Cross-matter context が on でない限り、別の案件のファイルは読み込みません。

---

目的

手元に大量の文書があり、それぞれについて一貫して回答する必要のある質問のリストがあるとします。デューデリジェンスの依頼リスト、ベンダー契約の監査、リースポートフォリオのレビューなどです。出力は表形式で、行は文書、列はデータ項目となり、すべてのセルをソース内の正確な文言までたどれるようにします。

これは問題点の抽出ではありません。diligence-issue-extraction は、2,000件の文書に隠れている30件の問題を見つけます。このスキルは、2,000件すべての文書について、同じ15個の質問に回答します。どちらも有用ですが、目的は異なります。

また、人が文書を読む作業に取って代わるものでもありません。このスキルが作成するすべてのセルは、検証が必要な手掛かりであり、判断ではありません。出力は検証を省略するのではなく、検証を迅速に行えるように設計されています。

コンテキストの読み込み

• ~/.claude/plugins/config/claude-for-legal/corporate-legal/CLAUDE.md → デューデリジェンスの構成、重要性のしきい値、社内書式の設定
• 特定の取引を扱う場合は ~/.claude/plugins/config/claude-for-legal/corporate-legal/deals/[code]/deal-context.md
• ユーザーが既存のスキーマファイルを持っている場合は、そのファイル（.review-schema.yaml）

列の型システム

表形式のレビューが役立つのは、1 行目の列 C と 200 行目の列 C が同じ意味を持つからです。自由記述はばらつきます。型は一貫性を保ちます。

各列には、回答形式を制約する型があります。

型	返される内容	用途
verbatim	文書からの一字一句そのままの引用	定義語、実質的な条項の文言、言葉そのものが重要なもの
classify	定義した固定リストからの値 1 つ	はい／いいえ、あり／なし、条項のバリエーション（例：「単独の同意」／「同意は不合理に拒否されない」／「記載なし」）
date	ISO 日付	発効日、満了日、解約通知期限
duration	数値＋単位	契約期間、通知期間、存続期間
currency	数値＋通貨コード	上限額、しきい値、手数料、購入価格に関する記載
number	数値のみ	件数、割合、ページ参照
free	短い自由記述の要約	控えめに使用してください。ばらつきやすい型です。他の型が本当に当てはまらない場合に限ります。

逐語引用のルール： verbatim 以外のすべての列では、回答を裏付ける原文の正確な引用も、対応するフィールドとして取得します。セル内の回答は解釈であり、引用はその根拠です。「同意は不合理に拒否されない」とする classify セルは、その根拠となった文がなければ役に立ちません。レビュー担当者の役割は、それが正しい解釈かどうかを確認することだからです。

「見つからない」を表す 3 つの状態

空白のセルでは情報が失われます。肯定的な回答を出せない場合は、次の 3 つの状態のいずれかを明示してください。

状態	意味	使用する状況
not_present	文書を確認したが、該当する条項がない	その主題について記載がないと確信できる場合
unclear	該当する記載はあるが、自信を持って分類できない	曖昧な起草、不完全な条項、矛盾する規定
needs_review	該当する記載を見つけたが、人間の判断が必要	境界事例、通常と異なる起草、スキーマで捉えられない判断によって回答が変わる場合

これらは、それぞれ異なる情報です。ディールチームにとって、「契約には譲渡について記載がない」と「譲渡条項が曖昧である」では、対応が大きく異なります。これらを 1 つの空白セルにまとめると、その違いが失われます。

ワークフロー

ステップ 0：対象と場所

以下を確認します。

1. 文書。 保存場所はどこですか？ VDR MCP（Box、Datasite、iManage）、ローカルフォルダー、Google Drive フォルダー、またはファイルのリストですか？ 件数はいくつですか？ 200 件を超える場合は、時間がかかることを伝え、重要度で絞り込んだサブセットから始めることを提案します。
2. スキーマ。 どの列を使いますか？ 次の 2 つの方法があります。
   • ユーザーが references/ からテンプレートを選びます（デフォルトは M&A デューデリジェンス標準です）。
   • ユーザーが自然言語で列を説明し、それを型付きスキーマに整理します。
3. 出力。 Excel（.xlsx）または Google Sheets のどちらにしますか？ チームが普段使っているものを確認します。フォールバックとして、CSV と Markdown は常に出力します。出力先はディールフォルダー、Drive、またはユーザーの指定先です。

ステップ 1：スキーマの作成と確認

ユーザーの列リストを構造化スキーマに変換します。各列には、安定した id、人間が読める label、type、prompt（文書を読むレビュー担当者が尋ねる質問）、および classify 列の場合は options リストを設定します。

出力先と同じ場所に .review-schema.yaml を書き込みます。このファイルは再利用可能な成果物です。ユーザーは編集や列の追加ができ、新しい文書に対して再実行できます。スキーマをユーザーに提示し、処理を一斉に開始する前に確認を取ります。

schema:
  name: "M&A Diligence — Project [Code]"
  created: 2026-05-07
  columns:
    - id: counterparty
      label: "Counterparty"
      type: verbatim
      prompt: "Who is the contracting party other than the target?"
    - id: effective_date
      label: "Effective Date"
      type: date
      prompt: "When did the agreement become effective?"
    - id: change_of_control
      label: "Change of Control"
      type: classify
      options: [silent, consent_required, consent_not_unreasonably_withheld, automatic_termination, notice_only]
      prompt: "Does the agreement address a change of control of the target? What does it require?"
    - id: assignment
      label: "Assignment Restrictions"
      type: classify
      options: [silent, consent_required, consent_not_unreasonably_withheld, freely_assignable, assignable_to_affiliates]
      prompt: "Can the target assign this agreement? What restrictions apply?"
    # ... more columns

ステップ 2：サンプル実行

未検証のスキーマで 200 件の文書を一斉に処理しないでください。まず 3～5 件の文書を実行します。ユーザーに行を提示し、次の点を確認します。

• 回答の大半が unclear になっている列：プロンプトが曖昧なので、書き直します。
• 回答が選択肢に合わない classify 列：選択肢を追加するか、free に変更します。
• 言い換えが返される verbatim 列：一字一句そのままでなければならないことを明確にします。

スキーマを調整し、サンプルを再実行して、確認を取ります。これにより、全件を実行した後に結果を破棄する事態を防げます。

ステップ 3：並列処理

文書ごとに 1 つのサブエージェントを割り当て、並列で処理します。各サブエージェントは次の作業を行います。

1. 文書全体を読みます（RAG のチャンクではなく、文書全体）。
2. 各列について、該当する条項を探します。
3. 構造化された行を返します。各列の形式は {value, state, quote, location} です。
   • value は型に応じた回答です（state が answered でない場合は null）。
   • state は answered | not_present | unclear | needs_review のいずれかです。
   • quote は根拠となるテキストの逐語引用です（正確に引用し、言い換えないでください。文の途中に省略記号を入れないでください。省略する場合は文の境界で切り、そのことを明記してください）。
   • location は引用箇所の位置です（条番号、見出し、ページなど、文書に記載されているもの）。

引用は任意ではありません。また、逐語引用のルールは単なる推奨ではなく、厳守が必要です。 state: answered のセルを返す前に、各サブエージェントは次のすべてを満たす必要があります。

• quote は、サブエージェントが指定した location で確認できる、ソース文書内の連続したテキストを、文字単位で正確にコピーしたものでなければなりません。見出しと、そこに含まれているはずだと考える定型文を組み合わせて引用を作成してはいけません。言い換えを逐語引用として扱ってはいけません。その種の条項で「通常」使われる文言を思い出して、引用を再構成してはいけません。ソース内で連続していないテキストを、省略記号でつないで引用を作成してはいけません。
• location は、正規化処理で文書を再度開き、同じ範囲を読み直せるだけの具体性が必要です。レビュー担当者がたどれる条番号、見出し、ページ参照などを指定してください。
• サブエージェントが正確なテキストを特定してコピーできない場合（ソースの切り詰め、OCR の文字化け、条項の内容は暗示されているが明記されていない、見出しは表示されているが本文が読み込まれていないなど）、セルの状態は needs_review とし、value は null にします。また、notes には quote_unavailable: <理由> を必ず含めてください。作成または再構成した引用を使って state: answered にすることは、決して認められません。
• このルールは、verbatim 型の列だけでなく、classify / date / duration / currency / number / free のセルに付ける対応するソース引用にも適用されます。セルの値だけでなく、根拠となる引用にも同じ逐語引用の要件が適用されます。

ステップ 4 の正規化処理では、指定された location でソースを読み直し、保存された quote とソースのテキストを文字単位で照合して、このルールをスポットチェックします。不一致があれば、セルを needs_review に格下げし、quote_mismatch を記録します。また、列全体を対象とした広範なスポットチェックのフラグを設定します。1 つのサブエージェントが引用を作成していた場合、同じ実行内の他のサブエージェントも作成している可能性があるためです。

Step 4: 正規化

ファンアウトの後、表全体を列ごとに確認します。この作業では、あらゆる表形式レビュー ツールで起こり得る失敗、つまり文書ごとに同じ条項が一貫性なく解釈される問題を検出します。

各 classify 列について：

• answered の値がすべて選択肢リストに含まれていることを確認します。外れ値は再分類するか、needs_review に変更します。
• 集中している値を確認します。180件の文書が consent_required、20件が consent_not_unreasonably_withheld としているなら、おそらく実際の違いです。195件が consent_required、5件が freely_assignable としているなら、その5件を確認します。実際に異なる内容か、誤分類のどちらかです。

各 date ／ duration ／ currency 列について：

• 形式に一貫性があることを確認し、正規化します。
• 不自然な値（99年の契約期間、上限額1ドルなど）には needs_review のフラグを付けます。

各 verbatim 列、および他のすべての列に付随する引用元の引用文について：

• 無作為に抽出したサンプル（各列につき少なくとも3～5行、または行数の10％のうち、多い方）について、引用された location で元文書を開き直し、保存された quote が元の文書と一字一句一致するか確認します。
• 引用文が合成、言い換え、再構成されたもの、または引用された範囲で見つからない場合は、そのセルを needs_review に変更し、notes に quote_mismatch を記録します。また、列全体にフラグを付け、他の行は問題ないと決めつけず、列の残りの行にもスポットチェックを広げます。引用の捏造が1件でもあれば、チェック範囲を広げる根拠になります。
• state: answered のセルで引用文が一致しない場合は、unclear または needs_review のセルより重大な失敗です。証拠の記録を誤って伝えているため、積極的にステータスを下げてください。

Step 5: 出力

表を3つの形式で作成します。

Markdown（常に作成し、セッション中のレビューに使用）：

| Document | Counterparty | Effective Date | Change of Control | Assignment | ⚠️ Flags |
|---|---|---|---|---|---|
| Vendor MSA — Acme | Acme Corp | 2023-04-01 | consent_required | consent_required | — |
| Supply Agmt — Beta | Beta LLC | 2021-11-15 | ⚠️ unclear | silent | CoC ambiguous §14.2 |

CSV（.csv、常に作成）： 値を格納するファイルと、引用文および場所を格納する付随ファイル（_sources.csv）を作成します。これにより、メインファイルをすっきり保ちながら、証拠の記録を完全な状態に保てます。

Excel（.xlsx）または Google Sheets — ユーザーが使用している方を選びます。確認してから選択し、推測で決めないでください。どちらも同じワークブック構成に従います（references/excel-output.md および references/gsheets-output.md を参照）。Excel：利用可能な場合は Claude in Excel（Office エージェント）、代替手段は openpyxl。Sheets：利用可能な場合は Sheets MCP、ADC 経由の Sheets API、代替手段は CSV のインポートです。スプレッドシートの出力では：

• 各データ列に、引用文と場所を含む非表示の参照元列を対応させます。表示列のセルコメント（Excel）またはメモ（Sheets）により、ホバー時に引用文が表示されます。
• 状態ごとに色分けします：白 = answered、黄色 = unclear または needs_review、灰色 = not_present。
• 各データ列に Verified 列を設け、初期状態では空欄にします。レビュー担当者が記入します。この検証／フラグ付けのパターンにより表を監査可能にし、ディールチームは人間が実際に確認した内容を一目で把握できます。
• 列の定義を記載した _schema シートを設け、ファイル単体で内容がわかるようにします。

プラグイン設定の ## Outputs にある成果物ヘッダーを最上段に追加します。その横に、次の配布に関する注意書きを記載します。

このレビューは、秘匿特権の対象、機密情報、またはその両方である可能性のあるソース文書に基づいています。このレビューにもソースの秘匿特権および機密情報のステータスが引き継がれます。秘匿特権の適用範囲外への配布は、秘匿特権を放棄することになり得ます。案件の秘匿特権対象ファイルと一緒に保管し、配布の判断は慎重に行ってください。

Step 6: 要約

表を作成したら、ユーザーに一画面で確認できる概要を提示します。

• 文書数、列数、完了した行数
• 列ごとの not_present、unclear、needs_review の件数 — これが検証作業量です
• 正規化の作業で行の10％を超えるフラグが付いた列
• 出力ファイルの保存場所
• 注意事項：すべてのセルは調査の手がかりであり、確定した事実ではありません。担当者への報告、スケジュール、またはメモに反映する前に検証が必要です。

次のステップを決める判断ツリーで締めくくる

CLAUDE.md の ## Outputs に従い、次のステップを決める判断ツリーで締めくくります。このスキルが今回生成した内容に合わせて選択肢を調整してください。デフォルトの5つの分岐（X の草案を作成する、エスカレーションする、さらに事実を集める、経過を見守る、その他）は出発点であり、固定ではありません。判断ツリーが成果物であり、選ぶのは弁護士です。

このスキルでできないこと

• 文書を読む作業に取って代わるものではありません。 確認すべき箇所を示します。
• 確信度スコアは出しません。 0.73 は情報ではありません。unclear / needs_review の状態と、一字一句そのままの引用が確信度を示します。引用が値を裏付けていない場合は、その旨を指摘してください。
• 文書を黙ってスキップすることはありません。 ユーザーが指定した文書はすべて行に含めます。読み取れなかった文書も、注記を添えて needs_review の行に含めます。
• 言い換えを引用であるかのように装うことはありません。 証拠の追跡可能性こそが重要です。

他のスキルとの関係

• diligence-issue-extraction は問題点を見つけ、このスキルはデータポイントを抽出します。抽出によって問題点（特定の収益目標に言及する MAC 条項や、ポイズンピルなど）が明らかになった場合は、その旨を記し、その文書に対して diligence-issue-extraction の実行を提案してください。
• material-contract-schedule は特定の表（開示スケジュール）を作成します。このスキルの出力を直接利用できます。スケジュールは、表形式でレビューした内容をフィルタリングし、再構成したものです。
• ai-tool-handoff は、対象文書が多すぎる場合や、チームが専用プラットフォームを希望する場合に、一括レビューを Luminance/Kira に引き継ぎます。このスキルで扱える内容には社内向けの選択肢として対応します。まずこのスキルを実行し、残りを引き継いでください。

出力の安全策

すべての出力に作業成果物のヘッダーを付けます。すべてのセルに出典の引用を付けるか、状態を明示します。要約には、検証が必要であることを明記します。Excel の Verified 列によって、検証状態を監査可能にします。これは読む作業を省くためのツールではなく、読む作業を効率化するためのツールです。