6,055 文字
こんにちは。今日は契約書の自動化についてお話しします。まず状況を簡単に説明しましょう。現在、契約書の自動化や契約書のような複雑な文書の処理は、様々な形のテクノロジーで存在しています。多くの場合、例えば契約書システムがあるでしょう。
そこには全ての契約書が保存され、データベースに格納されています。このシステムはユーザーがコンテンツにアクセスし、契約書に記載されている特定の事業体に関連する条件を扱う場所です。最良ではありませんが、少なくとも一箇所にまとまっています。
これが現状です。他のシステムや組織では、エンタープライズ・コンテンツ・マネジメント（ECM）と呼ばれるシステムを使っているかもしれません。ECMシステムは、より汎用的なワークフローと文書管理システムです。ECMシステムで見つかるのは、基本的にワークフロー、記録管理、電子記録を扱うための基本機能を備えた電子ファイルキャビネットのようなものです。
しかし、これら二つのシステムにおいて、特に契約書を扱う場合、多くの事例があります。このビデオの発想となったのは、契約書やリース契約書が頻繁に参照され、関係する事業体やプロパティがあるため、次のベストアクションを決定する必要があるユースケースでした。
そのため、専門家がその文書の内容や特定の条件を手元に持つことが重要であり、専門家はこのシステムやあるいはこちらのシステムにアクセスして文書を取り出す必要がありました。しかし問題があります。彼らは自分の目でそれを読み、決断に必要な重要な情報を抽出するために、契約書のどこに注目して読むべきかを理解する時間を取らなければなりませんでした。
今日のビデオでは、新しいパラダイムについて話します。それは本質的に自動化された契約書処理です。このパラダイムは、あらゆる種類の複雑な文書に適用できます。リース契約であれ、複数の当事者間または単純な二者間システムにおける何らかの契約条件であれ、この情報が入ってきた時点で、その内容を理解する必要があります。
このような洞察を得ることは、プロセスを迅速化するのに役立ちます。しかし、今日のツールでは、その情報を得るために専門家が常に文書を掘り下げる必要があります。この新しいパラダイムでは、それをどのように自動化し、AIを活用して専門家がより効率的になるよう支援できるかについて話します。
現在「エージェンティック（agentic）」という用語があります。この用語を読むと、AIボットや仮想アシスタントの一種と関連付けるかもしれません。しかし本質的に、エージェンティックという用語は、タスクまたは複数のタスクを実行するために、複雑な問題を理解し推論することができる会話インターフェースのことを指します。
AIが複雑なタイプのタスクを推論する能力は、現在、複数のエージェントを持つシステムがあるため、最近出てきたものです。特定のタイプのタスク専用のボットがあります。それらは特定のことだけを行います。そして今、それらの他のボットの上に位置する新しい種類の仮想アシスタントがあり、それらの活動を調整またはオーケストレーションします。
ビジネスで自動化したいことの多くは、単純な単一のトランザクション以上に複雑だからです。チケットシステムでチケットのステータスを検索するなど。それは今日ボットができることですが、AIを複雑な文書、特に多くの価値に関連する契約書に適用する場合、確かにそれ以上のことをしたいと考えます。
エンタープライズ・コンテンツ・マネジメント・システムや契約書システムで見られるのは…新しい役割や新しいプレーヤーがこの図に登場しています。今日のほぼあらゆる種類の強化や自動化の基盤には、私たちの良き友である生成AIがあります。
AIや大規模言語モデル、または従来のAIは、現在、画像認識、画像生成、音声生成、音声理解、そして間違いなく自由なテキスト理解とテキスト生成からマルチモーダルに解読し、実行する力を持っています。
そしてこの特定のシナリオで使用するAIの部分がそれです。もう一つの要素は、オーケストレーターまたはオーケストレーション・ハブです。これを「ハブ」と呼びましょう。前述のエージェンティックの概念では、ハブ内に存在するか、ハブによって制御される、多くの異なるボットと多くの異なるスキルがあります。
主要なスキルの一つは、ハブが必要に応じてAIを活用する能力です。このシナリオでは、プロセスをより効率的にするために、生成AIと従来のAIをプロセス全体で活用できるフローが見られます。契約書が届いたらすぐに取得します。
それらはまだ契約書システムかECMシステムに保存されるでしょう。そして、これらの文書が到着すると、トリガーイベントが発生し、文書がベクトルストアに入ります。ベクトルストアには目的があります。このシナリオでは、文書に関するすべてのメタデータだけでなく、それらの文書のすべての内容も含まれます。
作成するメタデータは、契約書の要素を決定するのに役立ちます。なぜなら、文書が取り込まれるときのモデルがあるからです。ここにこのモデルを置きましょう。そしてこちらにもモデルを置きます。これらのモデルで、文書を分解し、メタデータを作成して、ベクトルストアにきれいに保存できるようにします。
今日、青色の部分に文書が存在する場所があります。それは変わりません。変わるのは、これらの文書が分岐され、その内容が処理されて、ハブから検索可能かつ使用可能になることです。文書がハブに入ると、ちなみに、ハブにはベクトルストアから取得するスキルもあります。
このプロセスでは、現在存在する必須の契約書のすべての内容を接続することができました。影響は最小限です。クローラーがあり、それはすべての契約書を取得する小さなクローラーです。時々、契約書システムの契約書は実際にデータベースにBLOBとして保存されているので、クローラーは実際にデータベースを開き、そのBLOB列、そのフィールドを取り出し、その方法で処理しなければなりません。
内容を取得したら、必要なメタデータを作成するためにモデルを実行します。それは不可抗力条項や解約条件などのようなものに関連しています。これらの種類の「契約書」セクションはかなり一般的であり、モデルはそれを識別し、ハブからその契約書の特定のセクションを取り出したいときに、そのテキストの周りにメタデータを配置します。そのメタデータは、より効率的に取り出すのに役立ちます。
契約書に関しては、単語検索や単語の検索はできないことを覚えておいてください。それは機能しません。なぜなら、その特定の契約書における句やフレーズ、条項の文脈が全てを左右するからです。そしてそれらの条項やフレーズには、同じ意味を記述したり達成したりするために、多くの異なる分散した単語が含まれています。
そのため、意味的な検索でさえ、特定のものを見つけることができないことがよくあります。つまり、これらのモデルでは、契約書訓練された従来のAIタイプのモデルが必要です。または、生成AIを使用してそれらを識別することもできます。いずれにせよ、内容がベクトルストアに入る前にメタデータを作成するためのモデルが必要です。
ベクトルストアに入ったら、画面を見ているユーザーがいます。以前は、ユーザーはコンテンツ、契約書ストアシステムとECMを一緒にアクセスするか、ECMだけにアクセスしていました。組織がどのように管理とアクセスを展開しているかによって、リモートで接続してこれらの文書にアクセスするユーザーがまだここにいます。
時々、それらのユーザーインターフェースは、契約書システムの場合、実際の契約書システムにネイティブです。しかし、新しいワークフローを見ると、このユーザーをハブに接続します。そして会話的にそれを行います。それが、おそらく以前はプロセスを通じて文書を移動させる連続的なワークフローだったものの会話的な側面を考慮する場所です。
この新しいエージェンティックなアーキテクチャでは、チャットやエージェント・オブ・エージェントと呼ぶものを使用して、契約書のユースケースを達成するためにハブ内のすべてのスキルを活用します。契約書のユースケースは複数あります。
その多くは、条件の確認、有効期限や期限切れの日付の確認に関連しています。しかし、その作業の多くはチャットを通じて対話的に行うことができます。例えば、次のように入力できます：「2023年の不可抗力条項と2024年の不可抗力条項の違いは何ですか？」そして、そのシナリオで起こることは…
質問があると、まず第一に、ベクトルストアから関連コンテンツを取得します。元の契約書はまだレコードシステム内にあることを覚えておいてください。それは変わっていません。私たちがしているのは、ベクトルストアにインデックスされたコンテンツにアクセスすることです。
モデルが内容により速くアクセスするのを助けていることを覚えておいてください。なぜなら、関係者や条件など、契約書内の要素を識別しているからです。だから、メタデータにそれらの種類の要素を含めて検索しています。さて。関連コンテンツを取得したら、次に行うことは…
この場合、AIに提供します。テキストを扱っているので、大規模言語モデル（LLM）と言えるでしょう。そのコンテンツを大規模言語モデルに提供します。そして、一連の指示を与え、AIに問い合わせの目的を与えます。これら二つの条項を比較し、一方と他方を比較して何が欠けているかについてのガイダンスや情報を提供します。
契約書では、実際に責任を負うものに加えて、何が変わっているかを理解する必要があることが多いです。だから複数の質問をすることができます…そしてAIが行うことは、これは検索拡張生成（RAG）シナリオと呼ばれるものかもしれません。かなり人気があります。
しかし指示が行っているのは、ハブを活用し、LLMから得た情報を取得し、ビジネスルールを評価できるようになることです。これをBRと呼びましょう。私たちのビジネスルールは…専門家が最良の行動方針を決定するのを助けるものかもしれません。
なぜなら、ビジネスルール内には、戦略的であり、ユーザーに情報を提供することができる閾値や条件があるからです。今日、ユーザーは契約書システムに行き、契約書を開き、それを読んで消化しなければなりません。
その後、別のシステムで別々にビジネスルールを参照するか、完全な文脈を持つためにビジネスルールに関する専門知識を補完するために何らかの専門家を引き入れる必要があります。しかし、ここに何があるか見てください。これら全てをまとめるハブがあります。
ステップ3では、ビジネスルールを評価できます。どんな影響があるのか？問い合わせの文脈において、どんな重要な閾値が存在するのか？そして、それが完了したら、コミュニケーションを生成するためのもう一つのステップがあるかもしれません。これを「その他」と呼びましょう。
「その他」は、このプロセスに適用される可能性のある、または適用されない可能性のある他の種類の機能をカプセル化するからです。そして、すべての必要なシステムに網羅的に完全に触れたら、ハブがすべての統合を行っていることを覚えておいてください。AIを活用し、真実のシステムである私たちのコンテンツを活用しています。
適用可能なビジネスルールやその他のシステムを活用し、ユーザーとの会話的で対話的なやり取りを維持しています。これは何を意味するのでしょうか？ユーザーは複雑さが少なく、摩擦が少なく、時間のコストが少ないことを意味します。なぜなら、AIとこの場合のLLMが、要約、事実抽出、比較など、ユーザー自身が自分の認知能力で行わなければならないことをすべて提供しているからです。
今、彼らはハブによってオーケストレーションされたAIの支援を受けており、ハブは他のすべてのサービスをもたらします。メールを送る必要があるかもしれませんし、特定の契約に関連する他の文書を取り込む必要があるかもしれません。完全な文脈を確立するために必要なSalesforce、またはERPやCRMシステム内のレコードがあるかもしれません。
それが「その他」が関与する部分です。これらすべてが、一人のユーザーが会話的にトリガーされます。「処理する必要がある」とか「今年の契約書や昨年の契約書を調査する必要がある」とか「このプロパティのリース契約書にアクセスする必要がある」など。これらの種類のことはすべて会話的であり、複数のアクションをトリガーすることができます。
同時に、ユーザーの画面に完全な文脈をもたらすことができます。これは何をするのでしょうか？前述したように、これは本質的に時間を節約します。時間を節約するということは、摩擦が少なく、効率が高まり、このシナリオでは、より自然であるということです。なぜならユーザーは学習や適応をする必要がないからです。
このユーザーが同じままではないことを覚えておいてください。明らかにキャリアの変動があり、これらの契約書や文書を扱うユーザーの集団、彼らはビジネスの他の領域に移動することがあります。そして新しい人が入ります。そして、このオーケストレーションの恩恵を受けずに、この新しい人が今日しなければならないことは、これを知っており、行ってきた人の下で本当に学び、見習いをすることです。
しかし、この新しいアーキテクチャと新しいアプローチは、時間を節約するだけでなく、価値を加速させます。なぜなら、この人は新人であっても、経験豊富な人であっても、同じイベントのオーケストレーションにアクセスできるからです。そして、この特定の組織のコンテンツに調整されたAIモデルを使用すれば、信頼できる結果を得ることができます。
最後に重要なのは、スケールできることです。多くの組織は、複雑な文書を扱う際にスケールに問題を抱えています。なぜなら、スケールする唯一の方法は実際に人を追加することだからです。内容が評価され、判断されるのは専門家を通じてのみだからです。しかし、AIがオーケストレーションハブとともに支援してくれれば…
突然、より速く動き、より早く強い価値を持つことができ、より短い時間でより多くのことができるようになります。まとめると、契約書の自動化は…ビジネスルール、既存の投資（ERPやCRMシステムなど）、そして従来のAIと生成AIの両方を活用するオーケストレーションハブの追加です。
これらすべては、複雑ではあるものの、ユーザーにとってはシンプルな、複雑な文書を処理するという目的のためです。
コメント