AIレビューのコストをハックせよ：ダイニーが挑む「サブスク相乗り」戦略

開発現場において、CI/CDパイプラインのコストは常に「見えない負債」としてエンジニアの肩にのしかかっています。特にAIを活用したコードレビュー基盤を導入した際、そのコスト構造が「PR数×実行単価」という単純な掛け算で増大していく事実に、多くのテックリードが頭を抱えているのではないでしょうか。ダイニー社の事例は、まさにこの「AIによる生産性向上」が「インフラコストの爆発」というデッドロックを引き起こす典型的なケースを、極めて泥臭く、かつエンジニアリングの力で解決しようとする試みです。

同社では、この1年弱で月間PR数が約600〜800本から3,100本超へと約4倍に急増しました。採用を停止していた時期を考慮すれば、エンジニア一人あたりの生産性が3.5倍に向上した計算になります。しかし、ここで突きつけられるのが「レビュアーの時間は3.5倍にはならない」という物理的な制約です。彼らが構築した「Approver」というレビュー基盤は、AIが承認するか人間が見るべきかを判定する仕組みですが、当初はCI上での従量課金のみで運用されていました。実測値として、小さいPRで約2ドル、大きいPRで最大4ドル強というコストは、月3,000PRを処理すれば数千ドル規模に達します。これは単なる金額の問題ではありません。開発者が「レビューを回すたびに課金される」という心理的障壁を感じ、結果として「レビューをためらう」という、本来あるべき開発フローとは逆行する構造を生み出してしまう点にこそ、真の技術的課題が潜んでいます。

我々エンジニアが直面するのは、出力が増えるほどコストが比例し、かつ指摘がマージ直前に集中する「フローの最後尾」というボトルネックです。この構造を放置すれば、AI導入による恩恵はコストによって相殺され、最終的には「コスト削減のためにAIレビューを制限する」という本末転倒な事態に陥ります。ダイニーが選択したのは、この従量課金を「最後の砦」へと格下げし、実行場所を分散させるという極めて現実的かつ戦略的なアーキテクチャの転換でした。

ダイニーが打ち出した解決策は、レビュー基盤を「CI」「ローカル」「定期実行」の3か所で動かし、課金体系を最適化することです。特に注目すべきは、ローカル実行と定期実行を、開発者がすでに契約している「定額サブスクリプション（ClaudeのMaxプラン等）」の枠内に収めるという発想です。これにより、従量課金のCIは「未カバーのPRを拾う安全網」へと役割が変化しました。この設計により、請求をPR数から切り離すことに成功しています。以下に、その役割分担を整理します。

この設計の難所は、クラウド上で動く定期実行（routine）のセッション管理にあります。数GBに及ぶモノレポを扱うため、彼らはMCPサーバーをCloud Run上の常設remote connectorとして再ホストし、推論処理自体はエージェント側のサブエージェントに委譲することで、API従量課金を回避しています。connectorはあくまで「取り次ぎ役」に徹し、リポジトリのcloneやGitHub I/Oのみを担当するという徹底した責務分離が、このアーキテクチャの肝です。これにより、従量課金ではコスト的に躊躇せざるを得なかった「マージ後のfollow-up」や「全ファイルの夜間分類」といったNice to haveな機能が、サブスク枠内で自由に試せるようになりました。

特に興味深いのは、この基盤が「まだ黒字ではない（ROI 0.73）」と公言している点です。しかし、彼らはこれを撤退の理由とはせず、「定額側への転換」と「自動承認範囲の拡大」という2つのレバーを引くための投資と捉えています。特に、ファイル役割インデックスを用いて、LLMに毎回推論させずに決定的なルーティングを行う手法は、既存のAIレビューツールには見られない実験的な試みです。これは、単なるAIの精度向上ではなく、実行基盤の信頼性向上こそが承認率に寄与するという、現場を知るシニアエンジニアならではの鋭い洞察に基づいています。

ダイニーの事例から我々が学ぶべきは、AIを「魔法の杖」としてではなく、既存のインフラコスト構造を破壊し、再構築するための「レバー」として扱う姿勢です。多くの企業がAI導入のROIに悩み、コスト削減のために利用を制限する中、彼らは「サブスクに相乗りさせる」という逆転の発想で、レビューの実行回数を気にしなくてよい自由を手に入れました。この自由度こそが、マージ後の自動修正や、夜間のファイル分類といった、以前なら「コストが見合わない」と切り捨てていた高度な自動化を可能にしています。

しかし、ここで我々エンジニアに突きつけられる問いがあります。それは、「AIの推論コストを誰が負担すべきか」という構造的な問題です。クラウドの従量課金モデルは、スケーラビリティを担保する一方で、開発者の試行錯誤を阻害する側面を持っています。もし、すべての開発者がローカルで強力なLLMを動かせる環境が整えば、CIの役割は「最終確認」のみに収束し、開発プロセスは劇的に加速するでしょう。一方で、それは開発者のラップトップや個人のサブスクリプションに負荷を転嫁することでもあります。この「コストの所在」をどこに置くのが、組織として最も健全な開発体験（DX）を生むのか。それは単なる技術選定の問題ではなく、組織のエンジニアリング文化そのものを問う課題です。

明日から皆さんが取るべき対策は、自社のCIコストを可視化し、どの部分が「従量課金でなければならないのか」を徹底的に分解することです。もし、ローカルで実行可能なレビュープロセスをCIに依存させているなら、それは即座に改善の余地があります。また、自動承認率の低さを「AIの賢さ」のせいにする前に、ダイニーが指摘したように「実行基盤の信頼性」や「機械的な故障」を潰すことから始めてください。AIレビューは、導入して終わりではありません。コスト構造をハックし、開発者の自由を最大化するアーキテクチャを設計し続けることこそが、これからのシニアエンジニアに求められる真のスキルセットではないでしょうか。あなたの組織のレビュー基盤は、開発者の試行錯誤を加速させていますか？それとも、コストという名のブレーキをかけていませんか？