かつて私が午後いっぱいかけていた書類作成が、今では数分で終わるようになりました。
画一的なプロンプトを ChatGPT にコピペして、最初に出てきた答えをそのまま受け入れる話をしているのではありません。それは依然として危険であり、特に法律分野ではそうです。
私が言っているのは、別のことです。
よくある状況を想像してみてください。クライアントから PDF 数点、Word の契約書、バラバラのスクリーンショット、過去の判決、メールのやり取り、そして混乱した音声での説明が送られてくる。法的な問題は確かにそこにあるけれど、まだ整理されていない。
以前は、単純作業はほとんどいつも同じ方法で始まっていました。書類を一つずつ開き、事実を分離し、関連する日付を特定し、条項を確認し、時系列を作り、可能な請求を見つけ、法的根拠を探し、古いテンプレートを修正し、文章を推敲し、余計な部分を削り、書類をもう一度確認し、どこかに矛盾が隠れていないか祈るようにチェックする。何時間もの整理作業です。
ケースによっては、書類の作成を始める前に、これだけで 4 時間、5 時間、6 時間を費やしていました。
今では、適切に設計されたフローがあれば、最初の構造化されたドラフトが数分で得られます。
重要なのは、AI が「書類を作ってくれる」ことではありません。
重要なのは、弁護士が AI をただのテキスト入力ボックスとして使うのをやめ、AI を仕事のシステムとして使い始めることです。
これこそが、私にとって、単なるプロンプトを使うことと、エージェンティックフローを構築することの決定的な違いです。
プロンプトは孤立した指示です。
エージェンティックフローは、タスク、コンテキスト、ファイル、基準、テンプレート、レビュー、そして判断の、整理された連続体です。
プロンプトでは、「これについて書類を作って」と頼みます。
フローでは、エージェントに仕事のやり方を教えます。
どこに書類があるかを示す。どのファイルを最初に読むべきかを指示する。事実をどのように抽出するかを定義する。タイムラインの形式を説明する。自分の訴状テンプレートを提供する。法的根拠の整理の仕方を指定する。書く前に何をチェックすべきかを定義する。絶対に捏造してはいけないことを決める。疑問点のリストを要求する。リスクマトリックスを求める。そうして初めて、起草を指示する。
その実践的な違いは計り知れません。
AI を用いた優れた法律実務フローは、おおよそ次のような論理に従います。
- ケースの書類を読む。
- 関連する事実を抽出する。
- 書類を証拠機能別に分類する。
- タイムラインを作成する。
- 争点を特定する。
- 事実を可能な請求と関連付ける。
- ケースを過去のテンプレートと比較する。
- 書面の計画を立てる。
- セクションごとに起草する。
- 首尾一貫性、欠落、リスクをレビューする。
- Word で最終版を生成する。
- 人間によるレビューのためのチェックリストを作成する。
これは法律的推論を置き換えるものではありません。
むしろ、より多くの法律的推論を必要とします。なぜなら弁護士はプロセスをデザインする方法を知っていなければならないからです。
AI は、それ単独では、あなたの戦略、あなたが好む法的主張、取るに値するリスク、どの論拠が脆弱か、どの事実に証拠が必要か、どの書類を使うべきでないか、どの請求がコストを生む可能性があるか、その裁判所に適した言葉遣いが何かを知りません。
しかし、書類のインプットから書面の最初の実用的なバージョンに至るまでの間に存在する機械的な作業を、大幅に削減することができます。
ここで LLM が登場します。
LLM とは、大規模言語モデル（Large Language Model）の略です。実務上は、コンテキストからテキストを読み、解釈し、要約し、比較し、分類し、書き換え、構造化し、生成できるタイプのモデルです。
しかし、LLM 単体では、まだ単なるエンジンに過ぎません。
仕事を変えるのは、運用の中に組み込まれたエンジンです。
同じモデルでも、使い方次第で良くも悪くもなります。
まとまりのない書類を放り込んで完全な訴状を要求すれば、事実を混同し、法的根拠を誇張し、ニュアンスを見落とし、見た目は美しいが危険な書面を出力するかもしれません。
フローを整理し、段階を分け、テンプレートを提供し、正当性の説明を求め、トレーサビリティを要求し、人間によるレビューを含めれば、結果の性質は変わります。
弁護士は「AI が書いたテキスト」を受け取るのではなく、仕事のパッケージ（抽出された事実、年表、論証構造、ドラフト、疑問点リスト、注意点、検証チェックリスト）を受け取るようになります。
そこに私の関心があります。
Codex や Claude といったツールが興味深いのは、まさに孤立したプロンプトを超えることを可能にするからです。
どちらのツールでも、ファイル、指示、ターミナル、スクリプト、テンプレート、プロジェクト構造を持つ環境内で作業する、という論理で動きます。
これにより、法律実務において非常に具体的な可能性が開かれます。すなわち、各ケースを整理された作業フォルダとして扱うことです。
弁護士向けの簡単なケース別フォルダ構成の例：
/case-client-x
/documents
/templates
/drafts
/timelines
/checklists
/outputs
/documents には、PDF、契約書、判決、委任状、エクスポートしたメール、報告書、スプレッドシート、その他関連するものを入れます。
/templates には、過去の訴状、承認された構成、参考書面、事務所内の標準スタイルを入れます。
指示ファイルには、その種の依頼に対してエージェントがどのように作業すべきかを説明します。
例えば、次のように。
「最初に主要書類を読むこと。」 「事実は、日付、出典、元書類とともに抽出すること。」 「検証が必要であることを明示せずに、法的根拠を作成しないこと。」 「私の訴状テンプレートを構造として使用するが、ケースに適合させること。」 「起草前に、計画を提示すること。」 「起草後、レビューチェックリストを生成すること。」 「弁護士の確認が必要な点を強調表示すること。」
これは単純に見えますが、すべてを変えます。
Codex と Claude はどちらも、作業にファイルが関わる場合に特に有用です。フォルダ内で操作し、コンテンツを読み込み、書類を整理し、スクリプトを実行し、情報を変換し、構造化された出力を作成し、通常の会話では扱いにくい資料を処理できます。
例えば PDF がある場合、フローにはテキスト抽出、関連ページの特定、書類ごとの要約、添付資料リスト、事実と証拠のリンク付けを含めることができます。
Word ファイルがある場合、フローは .docx テンプレートを使用し、バージョンを比較し、新しいドラフトを生成し、構造、フッター、ヘッダーを保持してレターヘッドを壊さず、タイトルをレビューし、人間が編集するための最終ファイルを準備できます。
これは「答弁書を作って」と頼むのとは全く異なります。
より優れたフローは次のようになります。
「1. documents フォルダ内の PDF を読む； 2. 事実、日付、書類、ページからなる表を作成する； 3. 法的に関連する事実を特定する； 4. templates フォルダ内の答弁書テンプレートと比較する； 5. 答弁計画を作成する； 6. 起草前に疑問点をリストアップする； 7. 計画が承認されたら、Word でドラフトを生成する； 8. 矛盾、根拠のない請求、証拠のない事実を探す二次レビューを実行する。」
この時点で、「数分での書類作成」は空虚な約束ではなくなります。
それは整理整頓の結果となります。
弁護士は依然としてレビューします。
弁護士は依然として決定します。
弁護士は依然として回答します。
しかし、ファイルを一つずつ開き、プロセスに変換できるステップを手動で繰り返すために同じエネルギーを費やす必要はありません。
Claude は、この特定の文脈では、読解、要約、長文作成、文章校正、推論の構造化、そして広範なコンテキストでの作業に非常に強いです。法律フローでは、混乱した資料を整理された推論に変換する際に有用です。
Claude Code を使用すれば、プロジェクトやファイルにおけるエージェンティックな実行に近い論理が実現できます。指示、スキル、コマンド、専門エージェント、連鎖タスクを用います。
Claude Cowork を使用すれば、この論理はデスクトップ上のナレッジワークにまで拡張されます。ローカルファイル、アプリケーション、フォルダ、反復タスク、オフィス資料、そして必ずしもコードではない成果物を扱います。
弁護士にとって、これは非常に重要です。
なぜなら、法律実務の大部分は単なる「執筆」ではないからです。
それは情報の調整です。
散在する書類を一つの法的論証に変換すること。
法的論証を一つの書面に変換すること。
書面をレビュー済みバージョンに変換すること。
レビューをチェックリストに変換すること。
学習を再利用可能なテンプレートに変換すること。
Claude Cowork は、知識タスクの実行アシスタントとして捉えることができます。フォルダの整理、書類のレビュー、バージョンの比較、レポートの準備、ドラフトの構造化、Word、Excel、PowerPoint などの作業環境での支援。常にユーザーの監督と許可のもとで動作します。
その利点は、開始、中間、終了が明確なタスクを委任できることにあります。
「このケースを手伝って」ではありません。
しかし：
「このケースフォルダを開き、主要書類を読み、タイムラインを表で生成し、証拠のギャップを特定し、レビュー用の最初のドラフトレポートを準備してください。」
または：
「このドラフトを事務所の標準テンプレートと比較し、重要な相違点を示し、欠落している条項を強調し、より客観的な言葉遣いで修正版を生成してください。」
または：
「これらの書類を読み、事実、申し立て、証拠、そしてまだ確認が必要なものに分類してください。」
このコマンドの変更は表面的には小さく見えますが、運用上は深い意味を持ちます。
エージェントの品質は、あなたが教える仕事の品質に依存します。
ここでスキルが登場します。
スキルとは、簡単に言えば、特定の種類の作業をエージェントに実行させるための、指示、参照、場合によってはスクリプトやテンプレートのパッケージです。
法律分野では、これは非常に強力なものになり得ます。
以下のようなスキルを持つことができます。
- 消費者事件の最初の訴状を起草する
- 役務提供契約をレビューする
- 手続き上のタイムラインを構築する
- 証拠書類を分析する
- クライアント向けの経過報告書を作成する
- 首尾一貫性とリスクに焦点を当てて書面をレビューする
- 裁判所の判決を戦略的サマリーに変換する
- 提出用チェックリストを作成する
- 事務所のテンプレートを特定のケースに適合させる
スキルは単なる「きれいなプロンプト」である必要はありません。
方法を含めることができます。
以下のように指示できます。
*「起草前に、必ず計画を立てること。」
「事実と主張を分離すること。」
「事件番号、判例、書類を決して捏造しないこと。」
「証拠がない場合、保留中とマークすること。」
「明確で専門的な言葉を使うこと。」
「事務所のテンプレートの構造を保持すること。」
「最終チェックリストを生成すること。」
「人間による検証が必要な点を指摘すること。」*
時間が経つにつれて、事務所は即興に頼らなくなります。
インテリジェントな手続きのライブラリを構築し始めます。
これは Codex にも適用されます。
Claude にも適用されます。
API ソリューションにも適用されます。
ツールが既に使いやすいインターフェースを提供している場合、サブスクリプションプランにも適用されます。
「モデル」がすべて同じではないことを理解することも重要です。
よくある間違いは、あたかも選択肢が一つしかないかのように AI を選ぶことです。最も有名で、最も高額で、最も話題になっているモデルだけを選ぶことです。
実際には、法律フローは異なるタスクに異なるモデルを使用できます。
- 高速なモデルは、書類の分類、単純なデータの抽出、名前、日付、金額の整理を行えます。
- 推論能力に優れたモデルは、法的論証の分析、リスクの特定、書面計画の構築、矛盾のレビューを行えます。
- より大きなコンテキストを持つモデルは、多くの書類を同時に読めます。
- 執筆能力に優れたモデルは、計画を明確なドラフトに変換できます。
- ファイルにアクセスできるエージェントは、Word 文書の生成、バージョン比較、フォルダ整理を行えます。
運用上の秘訣は、すべてを単一の AI 呼び出しとして扱わないことにあります。
フローは分割できます。
- まず、抽出。
- 次に、整理。
- 次に、分析。
- 次に、計画。
- 次に、起草。
- 次に、レビュー。
- 次に、フォーマット。
- 次に、チェックリスト。
各段階には機能があります。
そして各段階には独自の基準を設定できます。
これにより、幻覚（ハルシネーション）が減少します。
手戻りが減少します。
トレーサビリティが向上します。
そして人間によるレビューがはるかに客観的になります。
最初の訴状のためのフローの実践例は次のようになります。
1. 書類の入力。
弁護士はケースフォルダを作成し、契約書、会話記録、領収書、通知、過去の判決、委任状、身分証明書、クライアントの所見を入れます。
2. 読取と棚卸。
エージェントはすべての書類をリストアップし、種類、日付、関係者、可能性のある関連性を特定します。
3. タイムライン。
エージェントは日付、事実、出典書類、証拠に関する所見を含む年表を作成します。
4. 法的問題。
エージェントは可能性のある法的根拠を分離しますが、検証が必要なものはマークします。
5. 弁護士への疑問点。
起草前に、エージェントは不足しているものを尋ねます。金額、請求、証拠、裁判管轄、時効、和解の試み、手続き上のリスクなどです。
6. 書面計画。
エージェントは構造を構築します。事実、法的根拠、請求、証拠、仮処分、訴額、添付書類。
7. テンプレートへの適合。
エージェントは事務所のテンプレートを使用し、スタイル、構造、言葉遣いを保持しながら、ケースに適合させます。
8. 起草。
エージェントは最初のバージョンを起草します。
9. 技術的レビュー。
エージェントは、すべての請求に法的根拠があるか、すべての重要な事実に書類があるか、矛盾がないか、箇所が曖昧すぎないかをレビューします。
10. Word での出力。
エージェントは、タイトル、トピック、構造が整った編集可能なバージョンを生成し、弁護士の最終レビューに備えます。
11. チェックリスト。
エージェントは、提出前の確認リストを提供します。
このシナリオでは、最初のドラフトは数分で出来上がります。
しかし、それは無から生まれるわけではありません。
それはシステムから生まれます。
そしてこのシステムは、三つの要素に依存します。良いインプット、良い指示、そして良いレビューです。
これがなければ、AI は単に無秩序を加速させるだけです。
成熟した形で AI を活用したい事務所は、いくつかの内部アセットを作成する必要があります。
それらは以下の通りです。
ここで議論はガバナンスに戻ります。
法律実務における AI は、生産性向上のためのおもちゃとして扱われるべきではありません。
それは、機密性、戦略、職業上の責任、個人データ、機密書類、手続き上のリスク、そしてクライアントの信頼に影響を及ぼします。
したがって、弁護士はテクノロジーについて最低限の理解を持つ必要があります。
エンジニアになるためではなく、自分が何を委任しているのかを知るためです。
エージェントは情報整理に優れていても、職業上の責任を負うことはありません。
LLM は起草は非常に得意でも、その法的主張がそのクライアントにとって最善かどうかは分かりません。
フローは書面作成を加速できても、法的戦略を代替するものではありません。
成熟とは、AI がどこで介入し、どこで止まるべきかを知ることにあります。
私にとって、法律実務が真に変わり始めるのは、弁護士が自分の仕事の周りに小さな AI オペレーションを構築できると理解した時です。
大きく始める必要はありません。
一つのフォルダ、三つのテンプレート、よく書かれた指示、そしてシンプルなフローから始められます。
「読む、整理する、質問する、計画する、起草する、レビューする。」
その後、改善します。
スキルを作成します。
チェックリストを作成します。
出力の標準を作成します。
テンプレートバンクを作成します。
Word 用のフローを作成します。
PDF 用のフローを作成します。
API 経由の統合を作成します。
ガバナンスを作成します。
時間が経つにつれて、弁護士は単に AI と話すだけの人ではなくなります。
エージェントを運用するようになります。
そしてこれは深い変化です。
なぜなら、エージェントを運用することを学んだ者は、法的知識を再利用可能なプロセスに変換できるからです。
既存のテンプレートを取得し、エージェントに特定のケースに適用させることができます。
乱雑な書類を構造に変換できます。
何時間ものスクリーニングを数分のレビューに変換できます。
「この訴状を手伝って」から、「私のテンプレート、私の基準、私のチェックリストを使って、この起草フローを実行して」へと移行できます。
それが要点です。
弁護士がエージェントに自分の方法の中で働くことを教えた時、AI は単なる起草ツールではなくなり、事務所の運用レイヤーとして機能し始めます。
数分での書類作成は、氷山の一角に過ぎません。
その背後には、豊富なレパートリー、よく構築されたテンプレート、整理されたファイル、明確な指示、適切な LLM の選択、人間によるレビュー、そしてガバナンスがあります。
これが、多くの人々がまだ過小評価している点です。
本当の変革は、より多くのテキストを生成することではありません。法的知識を再利用可能なプロセスに変換することです。
これを学んだ事務所は、一貫性を獲得し始めます。
スクリーニングが向上します。
レビューがより客観的になります。
テンプレートは古いフォルダに忘れ去られることがなくなります。
蓄積された知識が、より明確なフローの中で循環し始めます。
そして弁護士は、法律実務において常に希少だったものを手に入れます。それは、よりよく考えるための質の高い時間です。
結局のところ、AI は法律業務をより専門的でなくするわけではありません。
それはより多くの方法を必要とします。
そしてこの方法を構築する方法を知っている人は、無視できない優位性を持って仕事ができるでしょう。
