**裁判室として機能するLLM**

Japanese Translation:

Falconerは、コード変更を監視し、自動的にドキュメント更新を提案する共有メモリAIシステムです。「ドキュメント劣化」―古くなったドキュメントが負債となる問題 ― を単なる検索性の課題としてではなく捉え、時間のかかるPRごとの手動更新を秒単位で実行される自動プロセスに置き換えます。

システムは裁判所風の議論フレームワークを用いて編集が必要かどうかを判断します。初期バージョンではFalconerが関連性、機能への影響、被害レベルを評価しましたが、評価基準に一貫性がありませんでした。新しいアプローチでは4つのエージェントがあります：

検察官 – 正確なPR引用、正確なドキュメント引用、および具体的な損害声明を証拠として提出しなければならない。証拠が欠落していると却下される。
弁護人 – 各証拠に対抗し、損害を争い、代替説明を提示する。
陪審員 – 5名の独立したエージェントが理由付けと投票を行う。3/5 の多数決でケースを判事へ送ることが必要。
判事 – 低温度、重い推論モデルを用いて構造化された判決（裁定、根拠、最大2つの具体的編集）を有罪の場合に発表する。

すべての法廷用語は内部で使用され、ドキュメント所有者には提案された更新のみが簡潔に通知される。

3か月間の本番運用では、Falconerはレビュー前に65 %のPRをフィルタリングし、裁判所への送付前に95 %のフラグ付きPRを除外しました。63 %のケースがドキュメント更新なしで却下され、人間によるエスカレーションは83 %の確率で正しかったです。設計者はユーザー信頼を維持するために精度を再現性より優先させ、偽陽性が偽陰性よりも信頼を失わせやすいと考えています。

開発者にとってFalconerは手動ドキュメントメンテナンスを削減し、古くなったドキュメントからの責任リスクを低減します。これによりソフトウェアチーム全体で自動技術執筆の新たなベンチマークが設定される可能性があります。

共有知識―意思決定、計画、ドキュメント、プロセス―は、生きたリソースであり、企業が進化するにつれて変化します。Falconer は、横断的なチームとそのエージェントが共有知識を維持できるように、共有メモリ層を構築しています。そのコア機能の一つは、コード変更を監視し、自動でドキュメント更新を提案することです。

「ドキュメントローテーション（Documentation rot）」

ユーザーからよく聞く言葉です。コードやドキュメントが古くなり、一度正しかった知識がリスクに変わる現象を指します。多くのツールは AI を使って情報検索を可能にしていますが、見つけやすさだけでは正確性とは言えません。最新でないドキュメントを簡単に探せたとしても、その内容が古いままであれば問題は解決しません。最も難しいのは「どこから情報を取ってきても信頼できるか」を判断することです。

自動化されたドキュメント更新

Falconer は PR がマージされると、コード変更に応じて自動でドキュメントを更新します。しかし、PR がマージされた時点で「どのドキュメントを更新すべきか」を決めるのは単純なパターンマッチングではありません。テストファイルやロックファイル、CI 設定など明らかな非候補を除外した後は、人間の判断に頼ります。PR のコードは複雑で文脈依存が強く、ドキュメントも同様です。チームごとに優先順位が異なり、顧客サポート向けの更新がエンジニア仕様には不要だったりします。さらに、ドキュメントを読む対象（オーディエンス）も変更自体と同じくらい重要です。

もし人間が全てのコード変更を読み、手動でドキュメントを更新すると、数日かかるでしょう。しかし Falconer のエージェントはそれを数秒で実行します。

ただし、知能的なエージェントを作るだけでは不十分です。大企業向けに毎日数万件の PR を処理するインフラも必要でした。そしてもっと重要なのは、自らが強い意見を持つ判断エンジンを構築することでした。

社会的に最適な意思決定枠組み

「判断（judgment）」という言葉に執着し続けました。主観的でありながら合理性に裏付けられるものです。LLM をジャッジとして使う手法は有用ですが、当社のケースにはあまりにも単純でした。その瞬間、「裁判所全体を構築する以外に、より良い判断を提供できる方法はないだろうか」と思いました。そこで「LLM‑as‑a‑Courtroom」評価システムを設計・構築しました。

最初の試みはカテゴリー化スコアリングでした。モデルに「関連性」「機能追加」「害の程度」を数値で評価させ、閾値と比較して更新するか判断させました。しかし評価が不安定で偏りやすく、実際の意思決定のニュアンスを反映できませんでした。モデルは「何かに点数を付ける」ことには向いていないようです。

一方 LLM は詳細な説明・議論構築に長けています。人間が瞬時に判断するのとは異なり、モデルは思考過程を丁寧に記述してから結論に至ります。数値だけを出すよりも「立場を主張し、根拠を示す」方が合理的です。

評価対象から議論構築へ

評価目標を「1〜10で関連性を点数化する」から、「このドキュメントは更新が必要かどうか議論し、証拠を提示せよ」と変更しました。プロンプトを設計するうちに裁判所のような構造が自然に現れました。

sequenceDiagram
    participant P as Prosecutor
    participant D as Defense
    participant JY as Jury
    participant JG as Judge

    P->>JG: Exhibit A: Line 47 changed from async to sync execution
    P->>JG: Document states "all API calls are asynchronous"
    P->>JG: Harm: Developers will assume async behavior

    D->>JG: Counter: Document section refers to v1 API, not v2
    D->>JG: Change only affects internal implementation, not public contract
    D->>JG: Harm overstated: existing UX doesn't change

    JY->>JY: Deliberates independently
    JY->>JG: Majority votes Not Guilty

    JG->>JG: Weighs all evidence
    Note over P,JG: Verdict: Not Guilty

この構造は偶然ではありません。法制度は、チェック・バランス、議論、判断、そして何よりも正義を担保する社会的枠組みです。数世紀にわたり洗練されてきた二項決定（正当／不正）の問題に対して最適な手法と言えるでしょう。

哲学の学生時代に学んだ「健全な議論」の三要素は次の通りです：

妥当性 (Validity) – 結論が前提から論理的に導かれること
真実の前提 (True premises) – 前提自体が事実であること
健全性 (Soundness) – 妥当性と真実の前提を併せ持つこと

法廷議論は、現実世界における厳密な哲学的議論に最も近い形態です。論理構造と事実基盤の両方を要求し、証拠を明示し、反論を扱う必要があります。

LLM は訓練時に膨大な法的コンテンツ（ジャーナル・判決・裁判記録・ケース分析）を学習しているため、法律用語でタスクを設計すると「議論・検討・推論」の行動パターンが活性化されます。

アーキテクチャ：Prosecutor, Defense, Jury, Judge

裁判所パラダイムは、特定の思考行動を引き出すために設計された役割分担です。

graph LR
    subgraph Input
        PR[PR Diff]
        DOC[Document Corpus]
    end

    subgraph Courtroom
        PROS[Prosecutor<br/>Builds Case]
        DEF[Defense<br/>Rebuts]
        JURY[Jury Pool<br/>5 Agents]
        JUDGE[Judge<br/>Final Verdict]
    end

    subgraph Output
        GUILTY[Guilty:<br/>Proposed Edits]
        NOTGUILTY[Not Guilty:<br/>No Action]
    end

    PR --> PROS
    DOC --> PROS
    PROS -->|Exhibits +<br/>Harm Analysis| DEF
    DEF -->|Counter-<br/>Arguments| JURY
    PROS -.->|Original Case| JURY
    JURY -->|3/5 Guilty<br/>Threshold| JUDGE
    PROS -.->|All Evidence| JUDGE
    DEF -.->|All Evidence| JUDGE
    JUDGE --> GUILTY
    JUDGE --> NOTGUILTY

Prosecutor（検察官）

GitHub 上の主要エージェント。PR がマージされると、差分を解釈し、影響を受けそうなドキュメントを検索して更新の必要性を構築します。実際の検察官と同様に「証拠負担（burden of proof）」を提示する責任があります。

展開構造

graph TD
    subgraph Exhibit Structure
        E[Exhibit] --> Q1[1. Exact PR Quote]
        E --> Q2[2. Exact Doc Quote]
        E --> H[3. Concrete Harm]
    end

    subgraph Validation
        Q1 --> V1{Exists in<br/>PR diff?}
        Q2 --> V2{Exists in<br/>document?}
        H --> V3{Specific<br/>consequence?}
    end

    V1 -->|No| REJECT[Exhibit Rejected]
    V2 -->|No| REJECT
    V3 -->|No| REJECT
    V1 -->|Yes| ACCEPT
    V2 -->|Yes| ACCEPT
    V3 -->|Yes| ACCEPT[Exhibit Accepted]

PR からの正確な引用：差分で示された具体的なコード変更
ドキュメントからの正確な引用：対象文書に文字通り存在するテキスト
具体的害（Harm）：単なる「混乱」ではなく、「サポートエージェントが X を Y と伝えるようになる」という具象的影響

この要件は Retrieval Augmented Generation (RAG) の原則に基づき、LLM が正確な情報を前提とした推論を行うためです。

Defense（弁護人）

検察官の証拠・議論を精査し、反論を構築します。主な役割は「証拠が本当に結論に至るものか」「ドキュメントが既に正しいか」「害が過大評価されていないか」を挑戦することです。

Defense は各文書ごとに以下の構成要素を生成します：

主要反論（更新不要という中心主張）
各証拠への具体的挑戦（妥当性・関連性）
害の争い（害が過大評価または存在しない理由）
代替説明（既に正しい可能性）

対立視点を持つことは、健全な判断へ至るために不可欠です。

Jury（陪審員）

複数の独立したエージェントが両側から聞いた証拠・議論を評価します。彼らは偏見なく証拠と議論を総合的に判断し、投票（有罪/無罪/棄権）を行います。

技術設計

並列実行：すべての陪審員が同時に走る
高温度 (temperature)：多様性を確保するため、各陪審員は異なる視点を持つ
軽量推論モデル：コスト効率と並列実行を両立
独立コンテキスト：他の陪審員の投票を見ることなく判断

各陪審員は投票前に「理由」を説明し、証拠をどのように解釈したかを示します。

graph TD
    subgraph Jury Execution
        CASE[Case Evidence] --> J1[Juror 1]
        CASE --> J2[Juror 2]
        CASE --> J3[Juror 3]
        CASE --> J4[Juror 4]
        CASE --> J5[Juror 5]
    end

    J1 --> R1[Reasoning]
    J2 --> R2[Reasoning]
    J3 --> R3[Reasoning]
    J4 --> R4[Reasoning]
    J5 --> R5[Reasoning]

    R1 --> V1[Guilty]
    R2 --> V2[Guilty]
    R3 --> V3[Not Guilty]
    R4 --> V4[Guilty]
    R5 --> V5[Abstain]

    V1 --> TALLY{3/5 Guilty?}
    V2 --> TALLY
    V3 --> TALLY
    V4 --> TALLY
    V5 --> TALLY

    TALLY -->|Yes| PROCEED[Proceed to Judge]
    TALLY -->|No| DISMISS[Case Dismissed]

デフォルトは 5 名の陪審員で、3 人以上が有罪と投票すれば裁判官へ進みます。必要に応じて統一多数や単一多数などに変更可能です。

Judge（裁判官）

陪審員の初期判断を受け、最終的な判決を下します。裁判官は予測可能で一貫した結論を出すため、低温度設定と重い推論モデルを使用し、構造化された議論を行います。

低温度：結果の安定性確保
重い推論モデル：重要な判断に必要な深い思考
構造化審判：検察官・弁護人・陪審員全ての情報を統合し、最終的な決定と「刑罰」＝提案編集を提示

裁判官は次の要素を含む結論書を生成します：

総合分析：検察官・弁護人・陪審員の証拠と議論を統合
判決（有罪／無罪／棄却）
一文要約
有罪の場合は具体的編集提案（デフォルトでは 1 文書あたり最大 2 件）

用語はツールとして

裁判所の用語は、LLM の訓練セットを活かすための構造化ツールです。ユーザーに対しては「検察官」「証拠」などは表示せず、ドキュメント所有者には簡潔な通知（提案更新）が届きます。

学んだこと

陪審員バイアス：高温度で独立実行しても時に同じ結論になるケースがあります。これは証拠が強い/弱い場合に自然な一致ですが、共通の偏見を検出する必要があります。
新たなパラダイムには新しいテストインフラ：裁判所シミュレーションは確率的で「正解」が議論的です。悪い判決が起きた際、どこで誤りが生じたかを追跡できる観測戦略が必要です。
実運用でエッジケースが浮上：フィルタリングミスや余計なドキュメントフラグ、設定の不具合は実際に使われて初めて判明します。設計パートナーからのフィードバックは不可欠です。

裁判制度はほぼ完璧なマッチでした。そして LLM が法的推論を多く学習しているため、用語と構造だけでそのフレームワークを呼び起こせたのです。

3か月間の実運用結果

指標	値
PR の 65 % がレビュー前にフィルタリング	-
フラグされた PR の 95 % が裁判所到達前に除外	-
裁判所でのケース 63 % がドキュメント更新なしで却下	-
人間へのエスカレーション時、正答率 83 %	-

ドキュメントローテーションは「コードが変わると知識も変わる」ギャップを埋めます。裁判所は積極的にフィルタリングし、誤検出よりも信頼性（精度）を優先しています。

まとめ

Falconer は PR マージ時に自動でドキュメント更新を提案するインフラと判断エンジンを構築しました。
「LLM‑as‑a‑Courtroom」アプローチは、法的推論の長所（議論・検証・対立）を活かし、モデルに「根拠付き議論」をさせることで精度を向上させました。
裁判所構造は Prosecution → Defense → Jury → Judge の 4 役割で実装され、各段階で独自の温度・モデルサイズ・推論方法が設定されています。
実運用で得た知見は、バイアス検出、テストインフラ整備、エッジケース対応に活かす予定です。

これからもより高度な役割（多ターン議論、上訴プロセス）や業界別裁判所を設計し、複雑性を拡大していきます。

参考文献

AgentCourt: Simulating Court with Adversarial Evolvable Lawyer Agents (ACL 2025)
Improving Factuality and Reasoning in Language Models through Multi‑agent Debate
Debate, Deliberate, Decide (D3): A Cost‑Aware Adversarial Framework
Documentation Drift and How to Avoid It