FluxNinjaがCodeRabbitに参画

FluxNinja joins CodeRabbitの日本語訳です。

CodeRabbitが、スケーラブルな生成AIアプリケーションを構築するためのプラットフォームを提供するスタートアップ、FluxNinjaを買収したことをお知らせします。この買収により、急速に拡大するユーザー基盤を支えながら、新しいユースケースを産業規模のペースで提供できるようになります。FluxNinjaの製品であるApertureは、信頼性が高く費用対効果に優れたAIワークフローに不可欠な、高度なレート制限と同時実行数制限、キャッシング、リクエスト優先順位付けの機能を提供します。

CodeRabbitの提供開始以来、Apertureのオープンソースコアエンジンは、私たちのインフラストラクチャにとって重要な役割を果たしてきました。最初のユースケースは、OpenAIが課す厳しいレート制限への対処でした。ピーク負荷の時間帯に、有料ユーザーとリアルタイムチャットユーザーを優先しながら、無料ユーザーからのリクエストをキューへ入れられるようにしました。さらに、Apertureのキャッシングとレート制限機能を使用してコストを管理し、不正利用を最小限に抑えることで、オープンソース開発者へ全機能を備えた無料プランを提供できるようにしました。これらの機能により、ウェイティングリストを設けることなく、持続可能な価格でユーザー基盤を拡大できました。Apertureの支援により、CodeRabbitは短期間で10万を超えるリポジトリと数千の組織をレビューする規模へ成長しました。

私たちは、AIファーストの開発者ツール企業をゼロから築くというビジョンを掲げてCodeRabbitを始めました。エンタープライズ対応の応用AI技術を構築することは、過去のどのソフトウェアエンジニアリングの課題とも異なります。複雑なワークフローを構築する中で得た知見から、次の問題を解決できるプラットフォームへ投資する必要があることが明らかになりました。

• プロンプトのレンダリング： プロンプトの設計とレンダリングは、レスポンシブWebデザインに似ています。Webサーバーは画面サイズなどのパラメーターに基づいてページをレンダリングします。たとえばモバイルデバイスでは、通常ナビゲーションバーをハンバーガーメニューとして表示し、人間が使いやすいようにします。同様に、基盤モデルのコンテキストウィンドウに基づいてプロンプトをレンダリングし、ビジネス上の属性に応じてコンテキストを詰め込む優先順位を決め、AIが処理しやすくするプロンプトサーバーが必要です。コンテキストウィンドウのサイズには制限があるため、リポジトリ全体、過去の会話、ドキュメント、学習内容などを1つのコードレビュープロンプトへ含めることは現実的ではありません。たとえ可能でも、コンテキストウィンドウを完全に埋めた状態で推論すると、AIモデルの想起性能は低下します。密に詰め込む方法はチャットのようなユースケースでは許容できても、正確な推論を必要とするコードレビューには適していません。そのため、費用対効果と速度を保ちながら、各ユースケースで高品質な推論が得られるようプロンプトをレンダリングすることが重要です。パッキングロジックに加えて、特にエンドユーザーからの入力に基づいてプロンプトをレンダリングする場合は、基本的なガードレールも必要です。私たちは公開リポジトリへ無料サービスを提供しているため、製品が本来の目的を超えて悪用されたり、ベースプロンプトを含む機密情報を漏らすよう仕向けられたりしないようにする必要があります。

• 検証と品質チェック： 生成AIモデルはテキストを受け取り、テキストを出力します。一方、従来のコードやAPIは構造化データを必要とします。そのため、プロンプトサービスは、ワークフロー内の他のサービスが利用できるRESTful APIまたはgRPC APIを公開する必要があります。前項では、構造化されたリクエストに基づくプロンプトのレンダリングに触れましたが、プロンプトサービスはレスポンスを解析して構造化データとして検証し、推論の品質も測定しなければなりません。これは簡単ではない問題であり、レスポンスが網羅的で品質基準を満たすようにするには、複数回の試行が必要になることがよくあります。たとえば、複数のファイルを1つのコードレビュープロンプトへ詰め込むと、AIモデルがファイル内のハンクを見落としたり、ファイルそのものを完全に見落としたりして、不完全なレビューになることがわかりました。

• オブザーバビリティ： 生成AIとプロンプトの重要な課題の1つは、本質的に非決定的であることです。同じプロンプトからまったく異なる出力が得られることがあり、苛立たしく感じられる一方で、まさにそれがAIシステムの強みでもあります。プロンプトがわずかに異なるだけでも、出力が大幅に劣化したりノイズが増えたりして、ユーザーエンゲージメントの低下につながる可能性があります。同時に、基盤となるAIモデルは絶えず進化し、定期的に更新されるため、確立したプロンプトも時間の経過とともにドリフトします。従来のオブザーバビリティはここではほとんど役に立たず、生成された出力をどのように分類、追跡し、品質を測定するかを考え直す必要があります。これも社内で解決しなければならない問題です。

FluxNinjaのApertureプロジェクトは、負荷管理と信頼性をめぐる別の問題の解決に限定されていましたが、その基盤技術とチームの専門知識がAIプラットフォームを構築するための理想的な土台になると判断しました。プロンプトエンジニアリングはまだ初期段階ですが、AIの振る舞いを制御するジョイスティックとして台頭しています。関連文書でコンテキストウィンドウを満たす方法（検索拡張生成、すなわちRAG）も、モデルをファインチューニングする方法に比べ、独自データを提供するうえで好ましい手法になりつつあります。多くのAIラボは、ファインチューニングを簡単または安価にするよりも、コンテキストウィンドウを拡大することに注力しています。こうした明確な傾向が現れているにもかかわらず、応用AIシステムはまだ黎明期にあります。最近のAIベンダーはいずれも「適切な」プラットフォームを構築しているようには見えません。その多くが、バックグラウンド／永続的実行フレームワーク、モデルルーティングのプロキシ／ゲートウェイ、組み合わせ可能なRAGパイプラインなどに重点を置いているためです。こうしたアプローチの多くは、実世界のAIワークフローが必要とするものを満たしていません。適切な抽象化とベストプラクティスはこれから登場する必要があり、実践者自身がそれらを構築しなければなりません。AIプラットフォームはAIファースト企業の差別化要因になります。私たちは、システムエンジニアリングの考え方でこの問題へ正面から取り組めることをうれしく思います。

FluxNinjaチームを迎え、ユーザーへ最高水準のAIワークフローを提供できることをうれしく思います。また、FluxNinjaの創業者であるHarjot Gillとチームの皆さんをCodeRabbitへ歓迎します。