「スローai」のススメ:開発者が速度偏重をやめるべき理由

The rise of Slow AI: Why devs should stop speedrunning stupidの意訳です。

私たちがコンピューターを使い始めて以来、そこには常に1つの基本ルールが存在しました。それは、速ければ速いほど良いということです。低レイテンシ、高スループット、待ち時間の短縮、これが鉄則でした。ボタンの応答に600ミリ秒もかかったり、注意力が維持できなくなるほど長いスピナーを見たりすることを望む人はいません。遅いということは、それは壊れているということです。議論の余地はないでしょう。

そのため当然ながら、AIツールが私たちの開発ワークフローに忍び込み始めたとき、自動補完やエージェント、Copilot、その他何でも、同じ原則が適用されました。それはつまり、「速くしろ」「インスタントに感じさせろ」「魔法のように見せろ」です。

しかし、実際のところ、AIは魔法ではありません。それは推論です。パイプライン、RAG、コンテキスト、そしてツールの呼び出しです。乱雑なコンテキストと確率的推測をジャグリングしているのです。そして、単なる自動補完以上のものを求めるなら、ベースとなるプロセスのパイプラインを構築する必要があります。そして、それは処理時間がかかります。それ以外では、基本的に愚かさのスピードランをしているだけなのです。そして、ツールがどれだけ速くとも、間違っているなら速度はまったく意味がありません。

CodeRabbitでは、私たちが「スローAI」と呼ぶものを優先しています。そして、多くのAI企業が恐れて言えないことを言う勇気があります。私たちは「あなたを待たせます」。

(そして、あなたはそれに感謝するでしょう)

AI開発ツールはしばしば速く、自信に満ち、そして間違っている

最近AIコーディングエージェントを使ったことがあるなら、こんな経験をしたことがあるのではないでしょうか。タイピングを止めるとほぼ同時に、驚くほど速い提案がポップアップしてきます。それは一見すると、正当なものに見えます。しかしその後…失敗します。場合によっては、派手に失敗します。さらに悪いことに、テストには合格するものの、別なファイルで何かを壊していたりします。

これはなぜでしょうか? なぜなら、今日のほとんどのAI開発ツールは、1つのことに最適化されているからです。それは速度です。数トークンをタイプすると、モデルは統計的に最も可能性の高い続きを予測します。それは必ずしも正しいものではなく、安全なものでもなく、アプリが実際に何をしているかを理解しているものでもありません。ただ、次のもっともらしいコードの塊でしかありません。

それは、ボイラープレートには十分でしょう。しかし、ロジックには? エッジケースには? 実際のエンジニアリングには? それは、会議で速く自信を持って話すものの、仕様を読まない人を雇うようなものです。

こうしたツールのほとんどは、コンテキストを 読んで いません。少なくとも深くは読んでいません。近くの数行、おそらく関数名を取得するかもしれませんが、生成しているものを全体像に対して検証することは滅多にありません。課題のクロスチェックはしませんし、アーキテクチャレベルの認識もなく、ファイルやユースケースをまたいだ推論もありません。

思慮深く、テスト可能で、コンテキストを認識した出力が必要な場合、速度を落とし、俯瞰し、実際に問題に取り組むAIシステムが必要です。

それがスローAIの役割です。そして、AIが何をしているかを理解する時間を取ると、ハルシネーションを止めて実際にサポートしてくれるようになることがわかります。

AIが遅いときに優れている理由

核心として、大規模言語モデルは統計的推論マシンだということです。確率、パターン、そして(願わくば)あなたが与えたコンテキストに基づいて、次に何が来るかを予測して出力を生成します。しかし、ほとんどの開発者が忘れている注意点があります。良い予測には、それなりの作業が必要だということです。これは特に、ロジックを書く、アーキテクチャを理解する、複数のステップにわたって推論するなど、複雑なことをモデルに求める場合に当てはまります。出力の品質は、多くの場合において、推論の深さや段階に直接結びついています。

これは、単純なプロンプトを超えて、マルチステージパイプラインとエージェント的な動作に移行する際において、特に当てはまります。AIツールが出力を検証し、関連ファイルを取り込み、矛盾をチェックし、または複数のアクション先を計画している場合、それは単に次のトークンを出力しているだけではないのです。それは思考しています。または、少なくとも、それに近いことを実行しています。

このような非線形推論は、単一のフォワードパスでは実行できません。それには反省と検索、計画、そして時には自己修正さえも含まれます。こうしたプロセスはレイテンシ・フレンドリーではなく、インテリジェンス・フレンドリーなのです。

要するに、AIに複雑なコードで実際に助けてもらいたいなら、それを調理させる必要があるのです。

遅いことが新しいスマート:なぜ私たちはAIに考えさせるのか

スローAIは、私たちが話している用語の1つです。言い換えるなら包括的AIや正確なAI、あるいは正直に言えば「 実質的 役立ち有用なAI」と呼ぶこともできます。そして、それは今のAIプロダクトデザインで最もバズワードなアイデアの1つに密接に結びついています。そう、コンテキストエンジニアリングです。

AIが問題について知っている、 関連性があって解析された 情報が多いほど、パフォーマンスは向上します。しかし、そのコンテキストは取り込まれ、解析され、優先順位が付けられ、推論される必要があります。そのようなパイプラインは、超低レイテンシAIの敵です… そしてそれは精度の敵でもあります。

そして、それが私たちのAIコードレビューにおいて、最初のコメントを見るまでに最大5分かかる理由です。誤解しないでください。私たちは遅さを最適化しているわけではありません。コードベースとPRの複雑さに応じて、3分、あるいは1分でレビューを受け取ることもできます。私たちのパイプラインが複雑なのは、ユーザーが必要とする結果を出すために必要だからです。いつでも同時に実行されているプロセスの数を知りたくもないでしょう!

しかし、どうでしょう? 複数のレビューおよび検証エージェントを使用した、非線形のマルチパスパイプラインでAIに時間をかけさせると、他のツールよりもノイズが少なく、より関連性の高いコードレビューコメントが生成されるのです。

非線形推論は決して、速くありません。しかし、それは優れているのです。

では、なぜほとんどのAIツールは遅さよりも愚かさを選ぶのか?

まず、スローAIはすべてのツールにとってオプションではありません。たとえば、AIコーディングエージェントに質問をしている場合、返信を5分間待てる人はいないでしょう。そのやり取りには、即時性への期待が本質的に備わっています。

ではコードレビューはどうでしょうか? 提出されたPRに対して、同僚がすぐに手を止めてコメントし始めることを期待する人はいません。したがって、ボットからのレビューの遅延も受け入れる余地があります。そして、そのレビューがより関連性が高いことで時間を節約するなら、その遅延を受け入れる価値は特に高くなります。

しかし、なぜ多くの企業が、常に（実際にはそれを必要としないときでも）低レイテンシを優先するのでしょうか? まあ、私たちは訓練されてきましたし、即座の満足を期待するようユーザーを訓練してきました。ボタンをクリックすれば、速攻のレスポンスを得られます。関数名をタイプすれば、それについて考える前に提案を得られます。即効性がなければ壊れている、遅い、またはスタートアップがAWS料金の支払いを忘れたように感じられます。

これは非常に強く叩き込まれているため、企業は遅延よりも間違っている方を積極的に選択しています。そして、人々がそうするとき、私たちの開発文化には有害で、後ろ向きな何かがあります。

なぜなら、真実はこうだからです。最高のAIツールは必ずしも速く感じられず、代わりに思慮深く感じられます。時々、彼らは一時停止します。時々、プロンプトを推論したり、関連するコードを検索したり、応答を検証したりするために余分な時間を必要とします。しかし、それは待つ価値があるのです。たとえば、OpenAIのDeep Research機能が質問により良く答えるためにインターネットを最大20分かけて調査するからといって、利用を止める人はいません。処理中に他のことをして、戻ってくるだけです。

もはや遅い = 壊れているという意味ではありません。それはスマートという意味です。むしろ、AIに関しては、速度こそがバグです。開発プロセスに実際に価値を追加するAIツールが必要な場合、それには応答性から信頼性へ、即時性からインサイトへの移行が必要です。そして、特に開発者にとって、そのトレードオフは理にかなっています。

私たちは、今後5年間で最も価値のあるアプリは、速度を最適化するものではなく、インテリジェンスを最適化するものになると信じています。速いけど不要な結果と、遅いけれど価値あるもの、どちらが欲しいですか?

CodeRabbitのマントラ:ゆっくり動いて物事を修正する

CodeRabbitでは、他のツールのように、速度を優先するAIパイプライン最適化に過剰投資はしません。私たちは、信頼のために最適化を行います。それはコードを理解し、コンテキスト全体で推論し、より良いソフトウェアを構築するのに実際に役立つ出力を生成する時間を取るシステムを受け入れることを意味します。確かに、クイックプロンプトをたたき出すよりも遅いです。しかし、その余分な時間は明瞭さやカバレッジ、そして自信へと変わります。

「Move fast and break things（素早く行動し破壊せよ）」は、MVPをデリバリーするには素晴らしいものでした。しかし、品質をデリバリーすることに関しては、私たちは別のものを信じています。ゆっくり動いて物事を修正する、AIに場の空気を読ませる、話す前に考えさせる…そして、本当に自信のある自動補完ではなく、シニアエンジニアから得られるようなサポートを提供する。それが、間違ったAIをスローAIよりも優先する、現在の後ろ向きな文化から抜け出す唯一の方法です。

私たちのレビューを試してみたいですか? こちらから 14日間の無料トライアルを入手してください!