Uberの技術ブログが2026年10月8日に、法務部門向けのAI「Legal Redlining Agent（LRA）」の作り方を公開しました。契約交渉で相手方が入れてきた修正（レッドライン）に対して、AIが「承諾・拒否・修正」を提案し、理由のコメントとリスクの目印を付けます。提案を採るかどうかは、弁護士が全件を見て決めます。
先に、書かれていないことを分けます。ブログが挙げる成果の数字は、平均の契約レビュー時間が20%超減ったことと、AIの判断の正確さが91%という2つだけです。91%が何件を何と照らした値なのか（測り方・比べた相手・件数）は、ブログに書かれていません。この記事では、確認できる構成と、数字の読み方を分けて整理します。
何をAIに任せたのか
出発点は、契約の量です。ブログは、Uberでは毎年数千件の契約が交渉されると書き、この作業を「時間がかかり、繰り返しが多く、取引・オンボーディング・ローンチの詰まりになりやすい」と説明しています。
作ったのは、Microsoft Wordに組み込むアドインです。ブログによると、独立したウェブアプリではなくWordのアドインにしたことが重要な設計判断でした。AIは、弁護士の判断を置き換えずに、相手方の修正を見つけて意図を読み取り、方針に沿って承諾・拒否・修正を提案し、Uberの立場を説明するコメントを作り、さらに深い確認が要る条項にはリスクの目印を付けます。弁護士の過去の判断から学ぶ点も、機能として挙げられています。
時期は、2024年初めから開発を始め、2025年に法務部門で試験運用したとあります。2026年3月9日には、Uber法務部門の受賞案件（ALM Legalweekの技術賞「Most Innovative Legal Department of the Year」）の一部になった、とも書かれています。
ブログで確認できるアーキテクチャ（5つの部品と1つの流れ）
- ▸Wordのアドイン（画面側）：ReactとTypeScriptで作り、文書の横の作業ウィンドウとして動く。Officeの公式API（Office JavaScript API）で相手方の修正（変更履歴）を読み取り、編集を反映または強調表示する
- ▸Pythonのバックエンド：AIの処理をすべてまとめる。弁護士が分析を始めると、LangGraphのワークフローが動き、互いに独立した処理（意図の検出など）は並列で走らせる
- ▸記憶の層（OpenSearch）：ベクトル検索で、関係するルールと過去のフィードバックを引く。埋め込みにはnomic-embed-text-v15を使う
- ▸ルールエンジン：交渉できない方針（non-negotiable）は、AIの推測ではなく決定的な（毎回同じ結果になる）ルールエンジンで扱う
- ▸セッションの記憶（Redis）：会話の状態を持ち、弁護士が追加の質問をできるようにする。モデルの呼び出しはUberの社内基盤（GenAI Gateway）を使う
- ▸① 読む：弁護士がアドインで分析を始めると、バックエンドが相手方の修正を受け取る。意図の検出のように互いに独立した処理は並列で走らせ、速さと正確さの両方を狙う
- ▸② 引く：交渉できない方針はルールエンジンに任せる。交渉の余地がある部分は、過去の弁護士の判断を例として引く。類似検索とメタデータの絞り込みで約20件まで減らし、さらにAIで「今回の意図に合うか」を絞り込む
- ▸③ 作る：判断が「修正」になったときは、過去のフィードバックとルールを参照して、妥協案の文面を作る。ブログは、単純な文章生成では用語を作り話にしたり契約書の定義から外れたりしやすい、と書いている
- ▸④ 整える：最後に、口調を調える処理が入る。ブログの図の説明にはGPT 5.2を使うとある（本文では、他の段階のモデル名は挙げていない）
- ▸⑤ 決める：弁護士が各提案を見て、承諾・拒否・修正を決め、最終的な返答に取り込む。その判断・編集・理由が、②の材料として溜まる
うまくいかなかった点と、直した順番
- ▸最初は、社内の指針書（プレイブック）を検索して使う方式（RAG）だった。ブログは、意味の合う箇所を拾えない、口調が不適切、指針に無い場面に対応できない、という課題を挙げている
- ▸そこで、弁護士の判断を溜める仕組みにした。決定・期待した行動・コメント・最終的な修正文を記録し、最近の判断ほど重く扱う減衰の重みづけ（半減期は現在365日で、変更できる）で、次の提案の材料を作る。溜まったフィードバックは「数千件」に達しているとブログは書く
- ▸口調は、強く出すぎる／譲りすぎる、の両方に振れた。対策として、口調の指示文を「目的」「スタイル」「会話の切り出し例」の3部に分け、構造は技術側、中身は社内の弁護士が書く分担にした
- ▸修正案の文面は、エージェント的な段階を足した。過去のフィードバックとルールを参照して妥協案を作ることで、作り話の用語が減った、とある
- ▸ルールは、弁護士がテンプレート文に結び付けて登録する。重要な文や、よく修正される文を選んで、ルールを付ける
品質の見張りと、苦労した点
- ▸品質の監視：取り出した文脈の質を、AIによる採点（LLM-as-a-judge）で継続的に見ている。指標として、文書の質（document_quality_metric）と、会社のルールをモデルが守っているか（rule_adherence_metric）を挙げている
- ▸Wordの接続で苦労した点：Office JavaScript APIは動作が遅く、アプリ側での最適化が要る。変更履歴の取得には、特定の文書構造でクラッシュする例外がある。変更履歴で削除された文字は空の文字列で返るため、自前で本文の状態を持つ必要がある
- ▸文書が回ごとに変わるので、類似検索が必要：保存した元の文に頼るだけでは、文書が改訂されるたびに合わなくなる
数字の読み方（当サイトの見方）
- ▸「20%超の短縮」は、平均の契約レビュー時間です。ブログは、法務部門で使い始めてからの変化として書いています。何と比べた期間か、どの種類の契約かは書かれていません
- ▸「91%」は、正確さの割合ですが、測り方が書かれていません。何件を、何（弁護士の最終判断など）と照らしたのかが分からないため、「91%の提案は弁護士がそのまま使った」などと読み替えないでください
- ▸「約20件」「365日」は、この仕組みの設定値です。どの会社でも使える正解の値として書かれているわけではありません（365日は変更できると明記されています）
- ▸「数千件」は、溜まったフィードバックの量です。成果の大きさではありません
確認できなかったこと
- ▸91%の測り方と、20%超の比較対象。ブログには書かれていません
- ▸使っているモデルの全体像。GPT 5.2は図の説明にだけ出てきます。意図の検出、絞り込み、案の生成などの各段階がどのモデルかは、本文では明示されていません
- ▸弁護士がAIの提案をそのまま採った割合。ブログに数字がありません
- ▸画面や運用の細かい手順。ブログの図の画像そのものは確認しておらず、本文と図の説明文から確認した範囲で書いています
- ▸契約の種類や範囲。どの契約に使っているか、全社に広がっているかは書かれていません
この事例から持ち帰れること（当サイトの見方）
- ▸「全部をAIに任せる」ではなく、「AIに任せる部分を分ける」。守るべき方針は決定的なルールで固定し、判断が分かれる部分だけ、過去の人の判断を材料にしています。AIの得意・不得意に合わせて分ける設計は、他の仕事にも応用できます
- ▸最後に人が決める場所を、設計に入れておく。ブログは、弁護士が各提案を見て決めると書き、口調の中身も弁護士に任せています。AIの出力をそのまま外に出さない、という線引きです
- ▸最初の方式がうまくいかなかったことを、隠さず書いている。指針書の検索だけでは足りなかった、という失敗の記録は、これから作る人の近道になります
- ▸数字は、定義とセットで読む。「91%」のように、割合だけが書かれ、測り方が書かれていない数字は、そのまま他社の目標値にしないほうが安全です