【ITニュース解説】One Hindsight Setting Decided Whether My Agent Could Learn Judges

システムエンジニアを目指す皆さんにとって、AIがどのように現実世界の複雑な情報を理解し、役立つ知識として活用されるのかは、興味深いテーマだろう。この記事では、弁護士の業務を支援するAIエージェント「Tareekh（タリーフ）」が、どのようにして裁判官の「暗黙のルール」を学習するに至ったかを紹介している。この開発の裏側には、AIの「記憶」の仕組みに関する重要な工夫が隠されている。

Tareekhは、弁護士が日々の業務で作成する様々な記録、例えば裁判のメモや裁判所の命令書、証拠書類などをデジタル化して保存し、AIエージェントがそこから質問に答えるシステムである。このシステムは、弁護士がすでに持っている資料をアップロードするだけで利用でき、AIがその内容を読み取り、必要な情報を抽出して格納する。この「記憶」の役割を果たすのが「Hindsight」というメモリシステムである。Hindsightは、ただ情報を保存するだけでなく、保存された情報から「Observations（観察結果）」と呼ばれる、より深い知識やパターンを自動的に見つけ出す機能を持っている。

今回の開発で目指したのは、AIが「裁判官の行動パターン」を学習することだった。例えば、ある裁判官（ムルティ裁判官）は、相手方弁護士が裁判の延期を2回目に要求した際には「これが最後のチャンスだ」と警告し、3回目には延期を認めず、さらに費用を課す、といったルールを持っている。このようなルールは、裁判所の公式な文書には書かれていない。それは、弁護士が複数の裁判を経験する中で、裁判官の言動や判断から推測して学ぶ「暗黙の知識」なのである。AIエージェントにも、人間と同じように、たくさんの記録からこのようなパターンを自力で学習させたいという目標があった。

システムは、FastAPIでバックエンドを構築し、Next.jsでフロントエンドを、そしてGoogleのGemini AIをOCR（文字認識）や推論に利用している。HindsightはDocker上で動作する。Tareekhの設計の重要なポイントは、弁護士一人につき一つのHindsightバンク（記憶領域）を用意し、その弁護士が担当するすべての裁判の情報をそこにまとめることだった。なぜなら、裁判官の行動パターンは、単一の裁判の記録だけでは見えてこないからである。複数の裁判を横断的に見ることで、初めて一貫したパターンが浮かび上がってくるのだ。

Tareekhのデータ処理の流れは次のようになる。弁護士が手書きのメモや裁判記録をアップロードすると、まずOCRで文字を読み取り、必要な情報に分割・整理される。その後、各裁判の「聴聞」（実際の裁判の進行ややり取り）に関する情報が、Hindsightの中に個別の「記憶のエントリ」として保存される。エージェントは、これらの記憶から情報を「Recall（思い出し）」し、「Reflect（熟考）」することで質問に回答する。

しかし、当初AIエージェントは、このような裁判官の行動パターンを学習することができなかった。Hindsightには、保存された記憶から自動的に「Observations（観察結果）」、つまり「多くの記憶から築き上げられる耐久性のある信念」を形成する機能がある。開発者はこの機能を使って、裁判官の行動パターンを見つけさせようとした。Hindsightの observations_mission という設定で、「各裁判官がどのように聴聞を進めるか（延期の繰り返しへの対応、費用請求など）を、具体的な事例（裁判名と日付）とともに学習せよ」という指示を与えていた。

問題は、Hindsightが情報をどのようにグループ化するかというデフォルトの挙動にあった。各記憶エントリには、例えば「case:C5（裁判5番）」「judge:J1（裁判官1番）」「counsel:OC4（相手方弁護士4番）」といった「タグ」が付与されていた。これらのタグは、後で特定の情報（「この裁判だけ」「この裁判官だけ」）をフィルタリングするために使われる。Hindsightはデフォルトで、この「タグセット」が完全に一致するものを一つのグループとして統合する仕組みになっていた。

つまり、「Greenfield訴訟」（裁判5番、裁判官1番、相手方弁護士4番）のメモと、「Seabreeze訴訟」（裁判2番、裁判官1番、相手方弁護士2番）のメモは、どちらも「裁判官1番」に関する情報を含んでいても、タグセット全体が異なるため、Hindsightはこれらを別々のグループとして扱ってしまっていた。結果として、各裁判内でしか観察結果が形成されず、「Greenfield訴訟では、度重なる延期の後で費用が課された」という、単一の裁判の事実しか学習できなかった。これはメモに書かれていることそのものであり、新しい発見ではなかったため、期待通りの学習ができていなかったのである。

この問題を解決したのが、「observation_scopes（観察スコープ）」というHindsightの機能だった。これは、各記憶アイテムを、どの「スコープ」（領域）で統合すべきかを明示的に指定できる設定である。開発者は、記憶アイテムを作成する際に、observation_scopes の中に次のように設定を追加した。「[f"judge:{c['judge_id']}"]（裁判官ごとのスコープ）」「[f"counsel:{c['opposing_counsel_id']}"]（相手方弁護士ごとのスコープ）」「[f"case:{cid}"]（裁判ごとのスコープ）」。

この変更によって、一つの聴聞に関する記憶は、複数のバケット（グループ）に送られるようになった。例えば、ムルティ裁判官に関するすべての記憶は、裁判が異なっても「ムルティ裁判官バケット」にまとめられる。相手方弁護士に関する記憶も同様である。これにより、Hindsightは「裁判官の行動パターン」を、複数の裁判を横断して学習できるようになったのだ。

Hindsightが形成した「Observations（観察結果）」は、そのままエージェントに提示されるわけではない。エージェントが実際に読み取るのは、「Mental Models（メンタルモデル）」という、名前が付けられ、特定のクエリで定義された要約である。開発者は、裁判官ごと、相手方弁護士ごと、未解決の約束ごと、弁護士自身の業務パターンについて、それぞれメンタルモデルを作成した。例えば、裁判官のメンタルモデルには「この裁判官はどのように聴聞を進めるか？習慣、最初に求めるもの、延期要求への対応（特に繰り返される場合）、費用、誓約、要約、調停について。各パターンの背後にある裁判名と日付を挙げよ」というクエリが設定されている。

この「observation_scopes」の変更後、AIエージェントの回答は劇的に改善された。以前は「Greenfield訴訟では費用が課された」といった、単一の事実しか答えられなかったものが、「ムルティ裁判官は2回目の要求で『最後のチャンスだ』と言い、3回目の要求で費用を課します（Greenfield訴訟：2026年6月22日3,000ルピー、尋問終了）[1]。また、不規則な提出は拒否します（Seabreeze SP 2025年7月9日：2,000ルピーの費用[2]；コピーなしのメモは2026年3月11日に拒否[3]）」というように、複数の事例を根拠にした具体的な行動パターンを回答できるようになったのである。各[n]は元の記録（メモや命令書）へのリンクを示しており、弁護士はいつでも根拠を確認できる。

この開発から得られる教訓は、システムエンジニアを目指す皆さんにとって非常に重要である。 一つ目は、「observation_scopes（学習のグループ化）」を「タグ（フィルタリング）」よりも先に設計することだ。タグは「何でフィルタリングできるか？」という問いに答えるものだが、スコープは「何を一緒に学習させるべきか？」という、より根本的な問いに答えるものである。デフォルトの挙動ではこれらが同一視されがちだが、異なる目的を持つことを理解し、学習の設計を優先すべきである。

二つ目は、AIに学習させたい内容を、初期データとしてあらかじめ与えないことだ。例えば「ムルティ裁判官は短気だ」という情報を最初から与えてしまうと、AIが本当にその特性をデータから学習したのか、それとも単に与えられた情報を繰り返しているだけなのかが分からなくなる。AIの自律的な学習能力を検証するためには、意図的に初期データを空にしておくことが重要である。

三つ目は、observations_mission（学習の目的）に「発生回数と事例（裁判名、日付）」を含めることだ。これにより、AIの観察結果は「裁判官は厳しい」といった漠然とした形容詞ではなく、「〇〇裁判で×回、△△裁判で□回」というように、具体的で検証可能な情報となる。

四つ目は、AIのコンソリデーション（情報の統合処理）には時間がかかるという現実を、ユーザーインターフェースで正直に伝えることだ。複数の記憶からメンタルモデルを形成するには処理時間が必要であり、特に初期段階では情報が少ないため、有用なモデルが構築されるまでには時間がかかることを明確にすることで、ユーザーの期待を適切に管理できる。

そして最後に、AIの「ガードレール」（安全対策）を、指示プロンプトだけでなく、Hindsightのメモリバンク自体に設定することだ。「情報源を引用せよ」「法的アドバイスはするな」「不明な点は認めよ」といった指示をメモリバンクに設定することで、AIエージェントが「熟考」（Reflect）する際にもこれらのルールが適用され、誤った情報や危険な予測を提供することを防ぐ。例えば、「裁判官は費用を課すだろう」と予測するAIは危険だが、「裁判官は過去2回費用を課した。それがこれらの命令だ」と根拠を示すAIは非常に有用である。

この経験が示しているのは、AIが単なる情報検索システムではなく、複数の情報からパターンや洞察を学習する能力を持つためには、その「記憶」の層をどのように設計するかが極めて重要であるということだ。個々の記録内の事実だけでなく、複数の記録にまたがる「パターン」こそが価値ある知識である場合、Hindsightのようなメモリ層が情報をどのようにグループ化し、要約するかを深く理解し、適切に設定することが、AIの真の能力を引き出す鍵となる。今回の「observation_scopes」という一つの設定が、AIエージェントを単なるメモの繰り返し屋から、「裁判官を知る」賢いパートナーへと変貌させたのである。