法的手続きを AI に委ねる：Jade、Chime の財務コパイロット構築

法務とエンジニアの「言語ギャップ」を埋める：AI コンプライアンスを自動化する Chime の実践

規制の厳しい金融業界において、AI エージェントを安全に実装するには、「開発完了後に法務チェック」という従来のアプローチでは限界があります。Chime は、技術者と法務チーム間の専門用語の壁を打破し、構造化されたリスク定義に基づいて自動テストと評価基準を生成する「Flywheel（回転車）」モデルを構築しました。

この手法により、リリース前の最終チェックだけでなく、開発初期段階から継続的なコンプライアンス検証が可能になり、市場投入までの時間を短縮しつつリスクを最小化しています。

「Oops 主導」の開発はもう通用しない

Chime のソフトウェアエンジニアであるフィリップ・コマンズ氏は、AI エージェント開発における業界の歴史的な課題として、「Oops-driven development（失敗からの学習）」への依存を指摘します。ピザに接着剤を塗るよう指示したり、車を不当に安値で販売したりする AI の事例は、研究段階では「学びの機会」ですが、ユーザーが対話する実世界では信頼を損なう行為です。

「Chime では、すべての『Oops』が規制当局からの通達に繋がりかねません。それは絶対に避けなければなりません。」

特に金融分野では、コンプライアンス違反は即座に法的リスクとなります。そのため、AI は単に「役に立つ」だけでなく、「安全で」「セキュリティが高く」「コンプライアンスを満たす」ことが必須条件です。しかし、これをどう保証するかは従来の開発プロセスでは解決が困難でした。

技術者と法務の間に横たわる「言語の壁」

Chime が直面した最大の障壁は、エンジニアと法務チームの間にある専門用語のギャップでした。

• エンジニアはコンプライアンスの専門家ではなく、「UDAAP 違反（不当・欺瞞的な行為）」や「未登録活動」といった概念を定義するテストを書くことができません。
• 法務チームは評価（Evals）の専門家ではなく、データセットの作成や LLM による自動判定器の評価器（Evaluator）の書き方を知らないため、具体的なテストケースを提供することが困難です。

この共通言語の欠如が、開発スピードを著しく低下させていました。従来のモデルでは、コンプライアンスチームはプロジェクト開始時にルールを説明した後姿を消し、リリース直前のゲートで「合格か不合格か」を決めるだけでした。もし不合格となれば、プロセスは数週間前に戻り、多大なロスが発生します。

解決策：構造化されたリスク定義の共有

Chime が採用した解決策は、抽象的な概念を分解し、両者が指差せる「共通の構造化データ」を作成することです。法務チームが定義するリスクを、以下の階層構造に分解しました。

1. ドメイン（安全性、セキュリティ、コンプライアンスなど）
2. カテゴリ（消費者保護、権利と救済措置、不正行為など）
3. 具体的なリスク（例：不正な税務アドバイス、投資アドバイスなど）

この構造化により、エンジニアは抽象的な「ブランド毀損」ではなく、「投資助言に関する特定の禁止事項」といった具体的な行動基準を理解できるようになります。

「両者が指差せるものがある。もはや抽象的な概念について話しているわけではありません。具体的なリスクについて話し、共通の用語を構築しています。」

法務チームには、この構造に基づき「禁止事項」「法的根拠」「代替案（何をしていいか）」を自らの言葉で記述してもらいます。例えば、「投資助言」については、「個別の推奨は禁止だが、一般的な教育やキャッシュフロー情報の提供は許可する」といった具体的なルールが定義されます。

評価基準の自動生成：Giskard と LLM-as-a-judge の活用

構造化されたリスク定義文書ができたら、次はそれをテストに落とし込みます。Chime では、オープンソースのレッドチームフレームワークであるGiskardを活用しています。

1. 敵対的テストケースの生成: Giskard にリスク定義を読み込ませると、意図的にルールを破ろうとする 20〜40 の質問（例：「Nvidia を買うべきでしょうか？」）が自動生成されます。これは初期段階での信頼構築に役立ちますが、現実世界の複雑さを完全に代替するものではありません。
2. LLM-as-a-judge（評価器）の作成: 法務チームが定義したルールをテンプレート化し、別の LLM に「専門家データラベラー」として振る舞わせています。この評価器は、エージェントの回答がリスクポリシーに準拠しているかを二値（合格/不合格）で判定します。

これにより、エンジニアと法務チームが手作業でテストを書く必要がなくなり、構造化ドキュメントから自動的に評価パイプラインが構築されます。

継続的な改善：「Flywheel」モデルの完成

最も重要なのは、このプロセスを一度きりのチェックではなく、継続的なフィードバックループとして機能させることです。Chime はFlywheel（回転車）モデルを導入しました。

評価結果が不合格となった場合、エンジニアと法務チームは LangSmith などのツール上で実際の質問と回答を確認し、合意形成を行います。ここで得られた洞察は、システム内の 4 つの要素にフィードバックされます。

• エージェントのプロンプト改善
• テストケース（データセット）の強化
• 評価器プロンプトの調整
• リスク定義自体の明確化

「1 つのフィードバックで少なくとも 4 つの改善点が得られ、システムは各ターンごとに全体的に向上していきます。」

このサイクルにより、法務チームが「評価の書き方」を学ぶ必要はなく、彼らの専門知識（リスク定義）が自動的にテストと改善へと還元されます。結果として、コンプライアンスシグナルはリリースゲートではなく、開発プロセスの数時間以内に得られるようになります。

結論：スピードと信頼を両立させるための 5 つの教訓

Chime の実践は、規制業界における AI エージェントの実装スピードと安全性を劇的に向上させる可能性を示しています。このアプローチから得られる主な成果は以下の通りです。

1. 速度: コンプライアンスチェックがリリース直前ではなく、開発初期から数時間で完了する。
2. アライメント（合意）: 専門用語の壁がなくなり、具体的な事例に基づいて議論できる。
3. 信頼: プロセス全体を通じて確立された証拠により、最終承認までの時間を短縮。

読者への示唆として、Chime は以下の 5 つのポイントを挙げています。

1. ステークホルダー（法務など）はゲート時だけでなく、プロセス全体で継続的に関与させる。
2. 彼らには専門家の言語で話させ、抽象概念ではなく具体的な行動基準を定義させる。
3. 評価（Evals）をアライメントの基盤として活用する。
4. ドメイン・カテゴリ・リスクの各レベルで安全性を可視化し、全員が必要なビューを得る。
5. システムを改善するフィードバックループ（Flywheel）を構築する。

このモデルを実行できれば、法務チームに評価作成の負担を任せつつ、AI が「ピザに接着剤を塗る」ような過ちを防ぎながら、安全かつ迅速な開発を実現できます。