法的AI、スキャフォールディング付きコードエージェントではない

法的AI、スキャフォールディング付きコードエージェントではない。

法律AIの利用の大部分は、コード記述用に構築されたエージェントを通じて行われている。法律目的のために構築されたシステムが具体的に何を達成できるかに焦点を当てよう。

一般的に、法的AIは最も強力な支持可能な論点を見つけ、正しい証拠を特定し、その証拠を検証しやすくするべきである。

エージェントワークスペースが正しいインターフェースである。ユーザーはモデルが使用したツールやソースを含む監査証跡を見ることができる。サイドチャットを作成してコンテキストを制御し、特定のソースやスキルを定義してモデルの動作を操作できる。

エージェントのグラウンディングは個々の主張や編集のレベルで行われなければならない。外部文書を取得して全体として引用するだけでは十分ではない。この粒度は論点に依存する——個々の文、段落、または一連のページを必要とする場合がある。各ソースの階層、ステータス、意図された目的は明示されるべきである。その情報はオントロジーや類似のグラフネットワークを介して保存できる。例えば、法的権威とクライアントの事実、現在の文書言語と以前の起草言語など。

AIが編集を提案するとき、弁護士はなぜその変更を行ったかを見ることができるべきである。それには元の指示、レビューした条項、考慮した事実、依存した法的ソース、および決定論的に計算可能でユーザーにきれいにパッケージ化できる警告や不確実性が含まれる。

AIは自動的に変更を行うべきではない。提案された編集を赤線（または変更履歴！）として表示し、個別に処理できるようにすべきである。このワークフローはユーザーが変更を盲目的に受け入れるのを防ぐのに役立つ。言うまでもなく、変更は記録され、いつでも基礎となるバージョン管理システムを使用して取り消すことができる。確率的プロセスにバージョン管理システムなしで文書を編集させるのは単に無謀である。

スキル、メモリ、圧縮は証拠へのアクセスを保持すべきである。証拠を要約で置き換えるべきではない。法律ユースケースではそれでは不十分である。むしろ、正確な元の内容を事実情報として表示できる検索アーティファクトを残すべきである。

AIは、たとえ証拠に基づいていても、法的判断を決して覆してはならない。ソースは時代遅れ、狭い、不完全、または特定の法域に限定されている可能性がある。システムはこれらの制限をより可視化するようにすべきであり、隠すべきではない。弁護士が最新情報で完全に情報を得た決定を行えるようにする。

コードエージェントは機械的な正確性のみを強制し、解釈はガイドラインとして扱う。弁護士は、証拠グラウンディングがコア製品やワークフロー要件ではなく、オプションのガイダンスレイヤーとして扱われているために制裁を受けている。そして残念ながら、それが現在の法律AIツールの状況である。

条項の削除：パッチは一致したか、依存関係はチェックされたか？

「第12.7条を削除する。その義務は他で重複しているように見える」という指示を例に取る。これが間違う可能性は2つある。編集が準備されてからテキストが変更されたか、別の条項がまだ第12.7条を参照している可能性がある。

Codexのネイティブパッチパスは最初の失敗に直接対処する。現在のファイル内の古い行を探す：

期待されるテキストがもはや存在しない場合、パッチは古い位置に適用されるのではなく失敗する。

これは強力なテキスト不変性であるが、法律文書の依存関係については何も言及していない。Codexはクロスリファレンスを検索できるが、ネイティブパッチアプリケーションはその検索が行われたことを要求しない。

Lexifinaは、そのセクションに対して構造化クロスリファレンスルックアップが正常に完了したかどうかを記録する：

セクション全体の削除については、その記録レビューの欠如が編集レベルの警告となる：

各システムは異なる失敗を防ぐ。Codexは古いハンクがもはや一致しないテキストに適用されるのを防ぐ。Lexifinaは構造的依存関係チェックの欠如をレビューオブジェクトに持ち込む。

圧縮：モデルは正確なツール出力を回復できるか？

研究ツールが長い意見の抜粋を返し、モデルがその中の2段落を使用し、起草が完了する前に会話が圧縮されたとする。「このケースは論点を支持する」というナラティブ要約は証拠ではない。関連する質問は、アクティブエージェントが正確なツール出力を取得できるかどうかである。

Codexのローカル圧縮パスでは、置換履歴は保持されたユーザーメッセージと生成された要約から構築される：

それがモデルのアクティブな置換履歴である。各ツール結果のルックアップを要約に追加しない。これはCodexが永続的なロールアウトを削除することを意味するわけではなく、エージェントはソースファイルを再読み取りするかツールを再実行できる可能性がある。

Lexifinaの圧縮マーカーは、クリアされた結果に対してモデルに実行可能なアドレスを残す：

read_tool_resultはそのIDを永続化された完全な出力に解決し、別のモデルに再構築を要求することなく要求された範囲を返す：

この回復はアクティブな実行に限定される。モデルが直面するファイルは一時的であり、実行が終了すると削除される：

要するに、圧縮は大量のテキストを置き換えても、次のモデルに言い換えを信頼させることなく、tool_use_idは正確な永続化されたツールテキストへのルートを残す。Codexのローカル置換履歴は要約を保持するが、それ自体は同等のコールIDルックアップを公開しない。

赤線は何が変わったかを示す。どの起草決定がそれを変えたかを証明できるか？

バージョン3で賠償額を契約上の支払額に上限設定したとする。チームはその後初期ドラフトに戻りバージョン6を作成し、上限は消えている。弁護士の質問は単に「テキストがどう違うか？」ではない。現在の起草ブランチが上限を削除したか、どの受理された編集がそれを引き起こしたか、その編集を生み出した指示は何か、その答えは保存された変更記録に基づくのか後で再構築されたのか。

Codexは、現在のリクエスト中にコミットされたパッチによるファイル変更の正確なネット差分を維持する：

正確なパッチデルタのみがそのトラッカーに受け入れられる。不正確なデルタは結果を無効にし、潜在的に誤解を招く差分を許容しない：

クライアントに送信されるイベントにはその統一差分が含まれる：

イベントの全ペイロードは1つのテキストフィールドである：

これは「このCodexリクエストは何を変えたか？」に対する強力な答えである。しかし、それ自体は差分イベントを保存された文書系譜記録にはしない。ハンクには親バージョン、受理された編集ID、トリガー指示、レビュアー、適用時間、信頼度フィールドがない。Codexは周囲のロールアウトイベントを保持でき、バージョン管理システムはコミット履歴を追加できる。より狭い論点は、これらの関係はこのネイティブ差分オブジェクトの不変条件ではないということである。

[入力に基づき切り詰め]