法律事務所のナレッジ管理を、Google DriveとCodexで作り直す
こんにちは！Legal Agent 代表弁護士の朝戸です。
Legal Agentは、生成AI時代の法律事務所として、新しい時代の法務サービスを提供しています。
AI Nativeな法律事務所とは、という記事でも触れましたが、法律事務所において、生成AIを動かしやすいデータの持ち方、というのは、非常に重要です。
法律事務所の中には、契約書、相手方から送られてきた修正文案、クライアントからのメール、Slackでのやり取り、打ち合わせの議事録、過去の相談や回答、過去に作ったひな形、社内で使っているレビュー基準、書籍、条文、ガイドライン、裁判例、実務書、当局資料など、実に多くの情報があります。
そして、実務では、これらが一つの場所にきれいに集まっていることは、意外と少ないです。
実際には、資料の一部はメールにあり、やり取りはSlackに残り、契約書の最新版はGoogle Driveに置かれ、過去案件の参考ファイルは別のフォルダに入っている、という状態になりがちです。ひな形が誰かのローカルフォルダにあり、個社ごとの判断基準は担当弁護士の頭の中にあり、書籍やガイドラインはPDFで保存されているものの、案件対応の流れとは接続されていないこともあります。
この状態でも、人間だけで仕事をするのであれば、何とか回ることがあります。
担当者が覚えていたり、過去に見た記憶を頼りに検索したり、詳しい人に聞いたりすることで、多少の非効率は人間の記憶と経験で吸収できます。
ただ、AIを法律業務に本当に入れようとすると、この状態ではかなり厳しいです。
AIは、アクセスできる場所にある情報しか読めません。人間の頭の中にしかない経緯、Slackにだけ残っている判断、メールの奥に埋もれている前提、過去案件フォルダの中にだけ存在する類似事例を、自動的に知ることはできません。
そのため、AI Nativeな法律事務所を作るうえでは、単に高性能なモデルを使うだけでは足りないと考えています。
まず必要なのは、情報を一元管理することです。
ここでいう一元管理は、単に「Google Driveにファイルを置きましょう」という話ではありません。法律業務で使う情報を、案件、クライアント、契約類型、法分野、ひな形、社内ルール、外部文献、やり取り履歴という単位で、AIが読める形にしておくということです。
私は、法律事務所におけるナレッジ管理の本質は、「あとから人間とAIが、同じ文脈を見に行ける状態を作ること」だと考えています。
これができると、法律業務の進め方がかなり変わります。
情報が分散していると、AIは業務担当者になれない
法律業務では、同じ契約書を読んでいても、背景によって結論が変わることがあります。
たとえば、業務委託契約書をレビューする場合でも、その契約が新規事業の実証実験なのか、既存取引の更新なのか、大企業との取引なのか、スタートアップ同士の取引なのか、相手方との力関係はどうか、過去に同じ相手方と揉めたことがあるのかによって、コメントの出し方は変わります。
相手方が大口顧客で、今回の契約を早く締結することが事業上かなり重要であれば、細かい修正を大量に返すよりも、重要論点に絞って交渉した方がよいことがあります。逆に、相手方の業務遂行に依存する割合が大きく、損害が発生した場合の影響が大きいのであれば、責任制限や再委託、情報管理、成果物の権利帰属などをかなり丁寧に見た方がよいことがあります。
こうした判断は、契約書の本文だけからは出てきません。
案件の背景、クライアントの事業、過去の方針、社内での判断基準、担当者とのやり取り、過去案件のコメントが必要になります。
つまり、AIに法律業務を任せるためには、契約書だけを渡すのではなく、判断に必要な周辺情報も渡す必要があります。
従来のAIチャットでは、この周辺情報を人間が毎回添付する必要がありました。
「この契約書を見てください」
「この過去案件も参考にしてください」
「このメールの経緯も見てください」
「この会社では、責任制限は原則として月額利用料の十二か月分までです」
「この相手方とは以前この点で揉めています」
こうした情報を、人間が一つ一つ選んで添付する必要がありました。
これは、実務の感覚としては、かなり重いです。
AIを使うために、先に人間が情報を探して、集めて、添付して、説明するのであれば、その時点でかなりの作業が発生しています。もちろん、それでもAIを使う価値はありますが、法律事務所全体の業務体験を変えるほどのインパクトにはなりにくいと感じています。
そこで重要になるのが、フォルダ設計です。
Google Driveをローカルにマウントする意味
LegalAgentでは、Google Driveを使っています。
ただし、単にブラウザでGoogle Driveを開いているだけではありません。
Google Driveのデスクトップアプリを使って、マイドライブや共有ドライブをローカルのフォルダとしてマウントしています。つまり、見た目としては、パソコンの中にある通常のフォルダと同じように、Google Drive上のファイルが見える状態になっています。
この構成にすると、Codexから見ると、Google Drive上の資料がローカルフォルダとして扱えるようになります。
ここがかなり大きいです。
ブラウザ上のGoogle Driveにファイルが置かれているだけだと、AIは基本的に、人間が選んだファイルを読む形になります。もちろん、Google Drive連携を使って検索することもできますが、実務の操作感としては、ローカルフォルダのように扱える方が圧倒的に自然です。
ローカルにマウントされていると、Codexは、フォルダの中を横断的に見に行けます。
たとえば、次のような指示ができます。
- 「過去に類似の案件があったと思うので探してください」
- 「この契約類型に近いひな形を探してください」
- 「この相手方との過去のやり取りを見てください」
- 「今回の案件で使えそうなベースファイルをコピーしてください」
- 「このフォルダの中にある資料を読んで、時系列表を作ってください」
- 「この会社の過去のコメント方針に合わせて、今回のコメントを作ってください」
これは、従来のAIチャットとはかなり違います。
人間がファイルを添付するのではなく、Codexがフォルダを見に行き、人間が過去案件やひな形を探す前に、Codexに候補を出させることができます。
過去に似た案件があったはずなのにフォルダ名を忘れている、誰が担当したか分からない、似た契約書がいくつもある、最終版がどれか分からない、相手方コメント付きのファイルとクリーン版が混在している、といったことは、どの法律事務所でも起きやすいと思います。
ローカルにマウントされたGoogle DriveとCodexを組み合わせると、この探索作業のかなりの部分をAIに任せることができます。
もちろん、最終的にどのファイルを使うか、どの判断を採用するかは弁護士が見ます。ただ、最初に資料を探して、候補を集めて、文脈を読むところをAIに任せられるだけで、実務の進み方はかなり変わります。
案件対応フォルダを、法律事務所の作業単位にする
LegalAgentでは、案件対応フォルダをかなり重視しています。
法律事務所のナレッジ管理というと、きれいなデータベースや、検索システムや、専用のナレッジマネジメントツールを想像する方もいると思います。
もちろん、そうした仕組みも意味があります。
ただ、私は、まずは案件フォルダをきちんと設計することが、かなり重要だと考えています。
実務の作業は、結局、案件単位で発生します。
あるクライアントから契約書レビューの依頼が来たり、別のクライアントから資金調達の相談が来たり、デューデリジェンス資料が共有されたり、利用規約の作成や相手方との交渉が続いたりする形で、日々の仕事は案件単位で動いています。
このとき、案件フォルダの中に、少なくとも次のような情報がまとまっていると、かなり使いやすくなります。
- クライアントから受領した資料
- 作業中のファイル
- 納品済みのファイル
- 相手方から返ってきた修正文案
- Slackやメールでのやり取り
- 打ち合わせメモ
- 内部検討メモ
- 参考にした過去案件
- 参考にしたひな形
- 最終的な判断理由
特に重要なのは、「やり取り」を案件フォルダに入れることです。
契約書レビューでは、契約書そのものよりも、依頼時の説明や、その後のやり取りの方が重要なことがあります。
「この条項は譲れません」
「相手方とは長期的に付き合いたいです」
「今回はスピードを優先したいです」
「この責任範囲だけは社内で問題になっています」
「前回の契約ではこの条件で合意しています」
こうした情報は、契約書本文には書かれていません。
しかし、レビューの方針を決めるうえでは、かなり重要です。
この情報がSlackやメールに散らばったままだと、あとから担当者以外が見たときに文脈が分かりません。AIに任せようとしても、AIは契約書本文しか読めず、依頼の背景を理解できません。
そのため、案件フォルダの中に、やり取りの全文、送受信日時、送信者、チャンネル、件名、リンク、添付資料の情報が残っていることが重要になります。
Slackやメールを、案件フォルダに入れる
LegalAgentでは、Slackやメールなどのクライアントとのやり取りを、案件フォルダ側に保存する運用としています。
Codexでは、SlackやGmailとのコネクタ機能があり、さらに、スクリプトの自動実行機能があります。
これを組み合わせると、一定の時間において、定期的に、SlackやGmailの内容を取得し、やり取りをGoogle Driveの適切な案件フォルダに格納する、ということが可能となります。
もちろん、これは何でも無制限に保存するという意味ではありません。対象となるチャンネルやメール、保存する情報の範囲、アクセス権限、秘密保持、ログの残し方をあらかじめ設計したうえで、案件対応に必要なやり取りを保存するという考え方です。特にクライアントとのやり取りを扱う以上、人間が確認すべき場面と自動化してよい場面を分けることが重要だと考えています。
たとえば、クライアントからSlackで契約書レビューの依頼が来た場合、そのメッセージの本文、スレッドのやり取り、添付ファイル、投稿日時、投稿者、チャンネル名、リンクを、案件フォルダの「やり取り」に保存します。メールで追加の前提情報が来た場合も、メール本文、件名、送受信者、日時、添付ファイル情報を同じ案件フォルダに残します。
このようにしておくと、あとからCodexに次のように指示できます。
「この案件フォルダを読んで、クライアントからの依頼内容と追加条件をまとめてください」
「契約書レビューの前提となるSlackとメールのやり取りを確認してください」
「この案件で、クライアントが特に気にしているポイントを拾ってください」
「前回の回答と矛盾しないように、今回の修正文案を作ってください」
これは、人間の記憶に依存しない法律業務に近づくということです。
特に、法律事務所のチームで案件を進める場合、担当者が変わったり、弁護士、パラリーガル、スタッフ、別の弁護士が途中から入ったりすることがあります。そのときに、Slackやメールが案件フォルダに残っていれば、引き継ぎの負担がかなり下がります。
AIにとっても同じです。
AIは、案件フォルダに残っている情報を読み、過去のやり取りを踏まえて作業できます。クライアントが何を求めていたのか、どの論点を避けたいのか、どの期限で動いているのかを、フォルダの中から読み取れるようになります。
書籍、条文、ガイドラインをフォルダに体系化する
案件フォルダと並んで重要なのが、参照資料の管理です。
法律事務所では、書籍、条文、ガイドライン、実務書、当局資料、社内チェックリスト、過去の調査メモなどが大量にあります。
これらは、単にPDFとして保存されているだけでは、AIにとっては使いにくいことがあります。
もちろん、PDFのままでも読める場合はあります。ただ、実務で使いやすくするためには、OCRをかける、テキスト化する、Markdown化する、契約類型や法分野ごとに分ける、といった整備がかなり重要になります。
LegalAgentでは、ナレッジ用のデータとして、法令、公的ガイドライン、所内で作成した調査メモ、契約類型ごとのチェックリスト、適法に参照可能な文献情報などを、フォルダに体系立てて格納する運用を進めています。
たとえば、会社法、金融商品取引法、個人情報保護法、特定商取引法、割賦販売法、AIと著作権、AI・データ関連契約、契約書作成、契約書審査、法務デューデリジェンスなど、企業法務でよく参照する情報を、案件対応の中で確認しやすい形にしています。
たとえば、プライバシーポリシーをレビューしているときに、個人情報保護法の条文、個人情報保護委員会のガイドライン、過去のプライバシーポリシー作成メモ、クライアントの既存ポリシー、今回のサービス仕様が、同じ作業環境の中で読める。
資金調達の案件であれば、投資契約、株主間契約、種類株式、ストックオプション、会社法、金融商品取引法、過去のシリーズA案件での論点、投資家側から出やすいコメントを、同じ作業環境の中で見に行ける。
M&Aやデューデリジェンスであれば、法務デューデリジェンスのチェックリスト、過去のDDレポートの構成、開示資料、契約書、登記簿、株主名簿、許認可、個人情報管理、労務資料を、同じ作業環境の中で横断的に読める。
この状態になると、AIは単に一般論を答えるだけではなく、案件資料と参照資料を突き合わせることができます。
スキルフォルダは、実行できるナレッジになる
もう一つ重要なのが、スキルフォルダです。
法律事務所のナレッジは、単なるメモとして置いておくだけでは、使われにくいです。
たとえば、「NDAレビューのチェックリスト」があるとします。もちろん、それ自体は有用です。ただ、実務では、毎回そのチェックリストを開いて、人間が読み、今回の契約書に当てはめ、コメントを作り、Wordに反映する必要があります。
これだと、ナレッジは残っていても、業務の中で自然には動きません。
そこで重要になるのが、ナレッジをスキル化することです。
LegalAgentでは、契約書レビュー、Word修正、コメント作成、法務デューデリジェンス、訴訟書面、発信者情報開示、株主変遷分析など、業務類型ごとにスキルを作っています。
スキルというのは、単なるプロンプトではありません。
どの資料を、どの順番で読み、どのチェックリストを使い、どの形式でコメントを書くのか。Wordの変更履歴をどう扱い、クライアント向けコメントと内部コメントをどう分け、どのフォルダを見て、どのフォルダを触ってはいけないのか。そうした作業ルールを、AIが実行できる形にしたものです。
たとえば、Word文書の修正であれば、変更履歴を勝手に反映しない、既存の変更履歴を維持する、最小差分で修正する、コメントの種類を分ける、書式を確認する、といったルールが必要になります。
契約書レビューであれば、開示側と受領側、委託者側と受託者側、売主側と買主側、賃貸人側と賃借人側では、それぞれ見るべきポイントが違います。
こうすると、Codexは「この契約書を受託者側でレビューしてください」と言われたときに、単に一般論で答えるのではなく、受託者側の観点で、該当するチェックリストやコメントルールを参照して作業できます。
法律事務所のナレッジ管理は、業務設計そのものになる
私は、今後の法律事務所では、ナレッジ管理が業務設計そのものになると考えています。
これまでも、ナレッジ管理は重要でした。
ただ、これまでは、ナレッジ管理はどちらかというと、人間が後から過去のひな形、過去の回答、調査メモを検索するためのものだったと思います。
生成AIとCodexが入ってくると、意味が変わります。
ナレッジ管理は、AIが作業するためのインフラになります。
案件フォルダが整っていれば、AIは案件を読み、やり取りが保存されていれば依頼の文脈を読み、ひな形が整っていれば適切なベースファイルを探せます。さらに、プレイブックが整っていればクライアントごとの判断基準を踏まえられますし、法令、公的ガイドライン、適法に参照可能な文献情報がテキスト化されていれば、一般論ではなく参照資料に基づいて論点を出せます。スキルが整っていれば、法律事務所の作業ルールに従って動くこともできます。
つまり、ナレッジ管理が整っている法律事務所ほど、AIを実務に入れやすくなると考えています。
逆に、情報が散らばっている法律事務所では、どれだけモデルが賢くなっても、AIは十分に力を出しにくいです。
AIが読むべき資料が見つからず、最新版も分からず、過去の判断が残っていないうえに、やり取りがSlackやメールに埋もれ、ひな形が属人化している状態では、AIは毎回、断片的な情報から回答することになります。
これでは、法律実務に耐える品質を安定して出すのは難しいと思います。
だからこそ、LegalAgentでは、Google Driveをローカルにマウントし、案件フォルダを整え、Slackやメールのやり取りを案件側に保存し、法令・公的ガイドライン・文献情報を体系化し、ひな形やプレイブックを整え、スキルとして実行できるナレッジを作っていくことを重視しています。
ナレッジ管理が、外部弁護士を内部法務に近づける
このナレッジ管理は、法務アウトソーシングのあり方にも関わります。
外部弁護士に契約書レビューや法律相談を依頼しても、会社の事業、過去の判断、社内ルール、相手方との関係が分からなければ、どうしても単発の外部回答になりやすいです。その場合、社内法務が外部弁護士のコメントを読み直し、事業部向けに翻訳し、社内のリスク許容度に合わせて判断し直す必要があります。
一方で、案件フォルダ、やり取り、ひな形、個社別の判断基準、参照資料、スキルが一元化されていれば、外部弁護士は過去の文脈を踏まえて判断しやすくなります。Codexがその前提情報を探し、読み、比較することで、弁護士は内部法務に近い粒度で、意思決定を支える回答を出しやすくなると考えています。
法務部員を固定費として採用する前に、必要な時期に、必要な量だけ、外部弁護士とAIを組み合わせた法務機能を使うためにも、このようなナレッジ管理の基盤が重要になると考えています。
最後に
LegalAgentでは、生成AIと企業法務に精通した弁護士の協働により、契約レビュー、資金調達、法務アウトソーシング、M&A対応などを行っています。
法務関係でお困りの方がいらっしゃいましたら、お力になれる場面が多いと考えておりますので、ぜひお気軽にお問い合わせください。