Specterは、なぜすべての指摘事項をワンクリックで検証できるのか

多くのAIツールは、先に結論を生成し、その後で根拠となりそうな出典を探す。Specterは逆である。抽出そのものが、デューデリジェンス特化のオントロジーとナレッジグラフに沿って行われるため、すべての指摘事項は生成時点で根拠と結びついている。その結果、ワンクリックで該当ページまで到達できる出典検証が、毎回機能する。

なぜ一般的なAIツールは検証に苦労するのか

一般的なAIツールは、出典をリトリーバルの問題として扱う。まず指摘事項を生成し、その後で関連しそうなテキストを探す。この方法は性質上、確率に依存する。表面的には近い文を見つけられても、その記述が本当にその指摘事項の根拠である保証はない。そもそも、その文から指摘事項を組み立てたわけではないからである。

そのため、「AIが生成し、人間が検証する」という説明は、実際には「AIが生成し、人間がもう一度探し直す」を意味しがちである。原文書へ戻って確認しなければならないなら、それは検証というより、二回目のデューデリジェンスである。

基盤となるのは、デューデリジェンス特化のオントロジー

Specterの抽出は自由形式ではない。案件分析で本当に重要なものだけを扱うよう、オントロジーによって方向づけられている。企業構造、財務諸表の関係、契約上の義務、規制リスク、案件種別や地域に応じたリスク分類など、熟練したDD実務家が見る枠組みそのものを構造化している。

これは汎用知識ベースではない。法務、財務、税務、人事、技術といったカテゴリを、実際のDDフレームに沿って整理したものであり、データルームが読み込まれた瞬間から、Specterの抽出全体を方向づける。

ナレッジグラフによる決定論的な抽出

このオントロジーの上に、文書間の関係性を構造化するナレッジグラフが重なる。Specterが、子会社契約のチェンジオブコントロール条項、財務コベナンツ違反、クロスボーダーの規制不整合といった指摘事項を示すとき、それは文書全体に散在する情報を自由に推測しているのではない。どの関係性を見ているのか、案件文脈の中でそれが何を意味するのか、どこに根拠があるのかを構造的に把握した上で抽出している。

ここで重要なのは、抽出が確率的ではなく、決定論的である点である。Specterは、関連しそうな文を拾って推測しているのではない。なぜ見つけたのか、どの構造的関係を表しているのか、どの文書階層のどこに証拠があるのかを説明できる。

当社は、ユーザーに出力を信じてもらうことを求めていない。数秒で確認できる仕組みを提供している。100%のトレーサビリティは、後から足した機能ではない。設計上の前提である。

抽出時点で付与される来歴情報

Specterが抽出するすべての情報には、抽出の瞬間に来歴情報が付与される。元文書、ページ番号、位置情報である。これは、指摘事項が生成された後に後付けされるものではない。抽出パイプラインの一部として、最初から埋め込まれている。

その結果、レポート上に重要なリスクシグナルが示された時点で、出典はすでに付いている。クリックすれば、根拠文書の該当ページにそのまま移動できる。文書全体のどこか、ではなく、正しい該当ページである。

ワンクリックで該当ページへ

実務上の意味は大きい。レビュー担当者は、別途データルームを開き直したり、検索をかけ直したり、周辺文脈を再読して位置を特定したりする必要がない。出力からそのまま根拠へ飛べる。しかも、開くページは正しい。

• Specterのワークフローでは、法務、財務、税務、人事、技術の各論点に対して重要なリスクシグナルを提示し、それぞれを該当ページと結びつける。
• 複数文書にまたがる不整合は、双方の文書に対する出典付きで示されるため、レビュー担当者は直ちに差異を確認できる。
• 対象地域ごとの規制論点は、15か国超をカバーする独自データベース内の規制情報と、適用対象となるデータルーム文書の双方に紐づけて示される。
• 日本語の元文書を英語レポートで引用するといった、言語をまたいだ出典提示にも対応している。

トレーサビリティは機能ではなく設計原則である

Specterの出典検証は、機能追加ではなく、設計に組み込まれた性質である。オントロジーが何を扱うべきかを定め、ナレッジグラフが抽出を構造化し、来歴情報のパイプラインが根拠を失わないようにする。この三つが合わさることで、100%のトレーサビリティが実現している。これは、たまたまうまくいった場合にだけ成立するものではなく、設計上そうなっている。