11月9日、startuphub.aiが「Claude Code looked right and missed $800K」と題した記事を公開した。もとの発表はAlixPartnersのNatalia ConnollyとKevin MaduraがAI Engineerで行ったもので、startuphub.aiはその内容をまとめた二次メディアの記事だ。Claude Codeを企業の契約文書分析に投入した際に発生した80万ドルの見落としと、その根本原因、そして2週間で構築した対策パイプラインが詳細に報告されている。
LLMは「それらしい答え」を返す——問題はそこにある
ConnollyとMaduraは、M&A後の調達業務を想定したテストケースにClaude Codeを投入し、その全回答を人力で検証した。
テストのシナリオは、Harbor HealthによるSummit Health Plan買収後の状況を再現したものだ。共有ベンダーが数百社、4万件以上の契約文書が互いにリンクされていないデータベースに散在している。調達担当者の問いは「Acme Health Servicesからより良い条件を引き出せるか、削減額はいくらか、いつまでに動く必要があるか」というものだった。
Claude Codeが返した表は見た目には整然としていた。年間総支出、会社別内訳、契約件数はすべて正確に見えた。しかし監査の結果、契約総額が約80万ドルずれていた。
さらに日付も誤っていた。Claude Codeは「最も早く満了する契約の自動更新を止めるには12月1日が期限」と返答したが、正しくは11月1日だった。1カ月の誤差が、不要な契約の自動更新を引き起こしかねない判断ミスに直結する。
原因は推論ではなく、データ構造にあった
誤りの原因はClaude Codeの推論能力ではなく、データの構造的な問題だったとConnollyは説明する。
具体的には2つのパターンが確認された。
- 孤立した修正条項（orphan amendment）：親契約にリンクされていない修正条項が存在し、Claude Codeはその80万ドル分を発見できなかった。
- 金額の二重計上：2つの修正条項がそれぞれ契約の全額を再掲していたため、素朴な抽出処理が3つの金額を合算し、約1,700万ドルという誤った数字を出力した。正しい総額は最新の修正条項に記載された700万ドルだった。
契約の世界では、マスターサービス契約（MSA）を基に、後続の作業明細書（SOW）や修正条項が積み重なる階層構造が標準だ。しかしこの階層が壊れていることは珍しくない。CLM（Contract Lifecycle Management）システム——法務部門が正式にベンダー名や日付、親契約へのリンクを管理するはずのデータベース——は「ほぼ管理されていない」とMaduraは指摘する。つまりLLMの問題ではなく、入力データ側の構造的欠陥が誤答を引き起こした格好だ。
二週間で構築した5段階パイプライン
この問題を受けてConnollyとMaduraが構築したのは、約2週間で作り上げた5段階の処理パイプラインだ。各ステップは前のステップで露わになった問題を潰す形で設計されている。
- 文書インテリジェンスとOCR：まずPDFや画像として存在する契約文書を機械が扱えるテキストに変換する。ページをまたいで分割された表も処理できる形で読み取ることが前提となる。
- 契約タイプの分類：OCRで得たテキストをMSA・SOW・修正条項などに識別する。タイプが判別できなければ、後続の金額抽出で「どの数字が正とみなすべきか」の判断基準が立てられない。
- 条件と料率の抽出：契約タイプが確定した上で、テーブルや料率体系（レートカード）を含む形で数値を構造化する。ここで二重計上を防ぐための「最新修正条項を優先する」というルールが適用可能になる。
- サービスと支出カテゴリのマッピング：抽出した数値を調達カテゴリに紐付け、比較・集計可能な状態にする。
- 階層の再構築：壊れたCLMに頼らず、Claude Codeに契約本文を読ませてボトムアップで親子関係を復元する。孤立した修正条項の問題はここで解消される。
この4万件超の契約群は、パイプライン完成後に一晩で処理された。
DSPy・MCPサーバーの役割
特徴的なのはDSPyの活用だ。DSPyはStanford NLPが開発したフレームワークで、プロンプトを手書きで管理するのではなく、LLMへの指示を繰り返し可能なプログラムとして記述し、構造化された出力を安定的に引き出すことを目的としている。OCR処理ではどうしても図表や料率体系のレイアウト情報が失われてしまう。MaduraはこれをDSPyに対して契約ページを画像ごと渡すことで回避した。DSPyのマルチモーダル対応により、テキスト変換後には失われるセルの位置関係や列構造を、画像として入力した段階で保持させている。
構造化されたテーブルが揃った後は、Claude Code自身に「get rate card page」「get specific vendor spend」といったショートカットを構築させた。ビジネスロジックはプロンプトではなくコードに埋め込む設計だ。さらにMCPサーバー——エージェントに承認済みのツールのみを公開し、それ以外をブロックする標準プロトコルに基づくコネクタ——でツールとビューをパッケージ化し、後続エージェントが取引ルールを継承しつつアクセスを制御できる構造にした。
エンジニアへの示唆
この事例が示すのは、LLMは「それらしく見える誤り」を出力するという点だ。表の形式が整っていても、数字の正確性は別問題だ。特に企業の契約データのように、構造が壊れていることが前提のデータソースを扱う場合、LLMをそのまま投入することより先に、データの階層構造を修復するパイプラインの設計が問われる。ConnollyとMaduraの事例は、その設計によって問題が解決可能であることも同時に示している。
詳細はClaude Code looked right and missed $800Kを参照していただきたい。
