Cockroach Labs の移行ツール「MOLT」で IBM Db2 移行を AI エージェントが 2 日で作成した理由：教学病院メタファーによる品質保証

1. Db2 サポート追加の驚異的な効率化

Cockroach Labs は、データベース移行ツール「MOLT」に IBM Db2 のサポートを追加しました。Db2 は商用 relational データベースの一つであり、豊富な SQL ダイアレクトや複雑な型システムを備えています。

従来の課題

• Db2 をサポートするには以下が必要です。
  • 新しいスキーマ変換器
  • データ取り込み用の新規 Fetch パス
  • ロード後の比較用の新規 Verify パス
  • バンドル付き ANTLR グラムマ（解析器）
  • CI 用の Docker イメージ
  • 何万行にも及ぶテストフィクスチャの記述

歴史的なコストと効率の比較

Oracle サポート追加時のデータと比較すると、以下のような劇的な改善が見られます。

項目	Oracle (2024 年)	Db2 (今回)	改善率
作業期間	約 9 ヶ月	2 日未満	スピード +164 倍
エンジニアリングコスト	約 16 万ドル	38 分の 1 に削減
AI トークン使用量	-	4,172 ドル
人間によるコード記述	必要あり	0 文字（エージェントが完遂）

• プロジェクトは、GitHub の Issue に単独で要望を投稿するところから始まりました。

2. 「MOLT Sinai」という教学病院のメタファー

このプロジェクトを牽引した背景には、「教学病院（Teaching Hospital）」という独自の仕組みが存在します。MOLT は総称ですが、ここでは「MOLT Sinai」という名前の付いたコーディング病院として運用されました（Mount Sinai 医科大学に由来）。

病院としての役割定義

• Issue：患者
• マージ：退院（Discharge）
• 人間エンジニア：医学部長（Chief of Medicine）

このメタファーにより、以下の組織的な役割が与えられました。

• チャージ・ナース：30 分ごとに回診を行い、行き詰まった患者を探す
• 感染管理エージェント：メインプロセスの故障時に病院全体をロックする
• 安全部門：週次レビューとインシデント後の会議を開催
• 研究部門：新規作業者の提案を行う

3. 仕組み：GitHub Actions を基盤としたワークフロー

病院内でのすべての動作は GitHub Actions で実装されています。各「患者（Issue）」のステータスは、Issue のラベルとスクリプトファイルで管理されます。

ワークフローの動き

• 進行管理：エージェントが完了したら「ラベルアウト」を書き込み、次の段階のトリガーとなる。
• 逆流（破線矢印）：計画の見直しや CI 失敗時には、医学部長へエスカレーションして作業を戻す。
• 自律的な部門活動：4 つの部門は独自のスケジュールで動作し、システム全体の健全性を維持する。

エージェント向けのプロンプトとルール

ラベル適用時にエージェントは「病院職員」として振る舞うよう指示を受けます。主な安全ルールは以下の通りです。

• 計画なしではコードを書かない
  • 問題の再現、鑑別診断、対象調査、治療計画の公開が必要です。
  • Review Attending（教授相当）が承認するまで治療を開始しません。
• 即興を禁止
  • スコープが変わっても一旦停止し、改訂計画を公開してレビューに戻ります。
• ショートカットとテスト変更を厳格に制限
  • テストの無効化や弱体化は禁止。テストが失敗すればそれが正しい状態として扱います。
  • テスト自体が間違っている場合も、独自のコミットとして提出し別途レビューされます。
• 無駄な努力を許さない（Never Flail）
  • 行き詰まったら「I-PASS」（重症度サマリーなど）のフォーマットを作成し、Attending にエスカレーションします。
• 退院看護師による監査
  • コード自体の再レビューではなく、「レビュープロセスが適切に遂行されたか」を確認します（承認の有無、未解決スレッドがないかなど）。
• 判例の確認
  • 人間（Chief）による決定をエスカレーションする前に、過去ログで類似事例を検索し、それに基づいて判断します。

4. システムの成果と進化：5 ヶ月の運用実績

MOLT Sinai を運用開始後（4 月 21 日〜9 月 11 日）、以下の成果を挙げました。

コードの品質と量

• 約 100 万行以上のコードが取り込まれました。
  • 信頼性の高い小さな変更単位で分割されており、エージェント自身が自信を持ってレビューできます。
• バックログの生成：Issue の半分以上が病院システム自体により起票されました（サブ Issue の分解、研究提案など）。

Migration Assistant の開発

Db2 サポート導入を皮切りとして、AI ベースのMigration Assistantを開発しました。

• スキーマ変換、データロード、検証機能を備えた完全移行ツールです。
• Postgres から CockroachDB への移行で利用可能です。

コストとモデルの進化

• 総コスト：約 13 万 5,000 ドル（平均 84 ドル/Issue）。
• モデル最適化：
  • 初期は Opus モデルを使用 →現在は Fable で計画を立て、実装には適切なモデルを選定。
  • 困難な場合は Fable エスカレーションにより高機能モデルへ切り替え。
• チューニング：数週間ごとに最適化ラウンドを行い、コスト効率を向上させています。

5. システムの課題と教訓

長期運用を通じて得られた教訓や、改善が必要な点についてまとめます。

✅ うまくいったこと

• ペルソナの重要性：役割定義の短い文章が最も効果的でした。LLM は「教学病院」や「鑑別診断」という概念を深く理解しています。
• 計画レビューによるバグ防止：10% 未満しか却下されませんが、早期の発見により多大なコストを削減しました。
• 分解と天井の厳格化：変更量が大きすぎたら再分割するルールにより、人間が把握可能な粒度に保たれています。
• 記録（アーカイブ）の価値：計画や I-PASS、臨床ノートなどを伴うアーカイブブランチにより、レビューとトラブルシューティングが劇的に楽になりました。

⚠️ 改善が必要だった点

• ルールへのやりすぎ（官僚主義）：
  • 「重複」という理由だけでエスカレーションするなど、ルールに固執しすぎて人間が必要な判断を妨げるケースがありました。
• サーキットブレーカーの必要性：
  • 特定の Issue において再作業ラウンドが収束せず、コストを浪費する事態が発生しました。一定回数超えた場合は人間レビューへ引き継ぐ仕組みを導入する必要があります。
• 生産性と有用性のバランス：
  • システムが自ら起票する Issue の質は高いですが、価値が疑わしいものも多くあります（例：解決済み問題の再提案）。
• 教育としての機能不足：
  • 若手エンジニアにとって学びの場として十分ではありません。人間が自らの判断で行うコーディングと AI のレビューを組み合わせることで、より良いエンジニア育成を目指しています。

6. 次のステップ

Cockroach Labs は以下の方向性で開発を進めています。

• 効率化と精度向上：エージェントのパフォーマンスを継続的に改善します。
• 教育ツールの強化：若手エンジニアがスキルアップできる環境を整えます。
• 自律モードの再導入：特定の Issue に対して、人間レビューなしでの自律実行実験を行います。

もし興味のある課題がありましたら、ご連絡ください。