🎊
【プチアップデート】WindsurfでFast Context が利用可能に

2025/11/09に公開
 はじめに今回は Windsurf の Fast Context 機能についてキャッチアップしていきたいと思います。

 Windsurf のアップデート内容結構前になりますが、2025/10/17 に Windsurf の公式 X で下記のポストがされました。

https://x.com/windsurf/status/1978868382847111414
SWE-grep、SWE-grep-mini という、高速エージェントサーチ用のモデルだそうです。

2800TPS 以上で、コーディングエージェントに従来の 20 倍以上早い正確なファイル検索を提供すると書かれています。
20 倍以上早いって、革命的すぎませんか...
たしかに、X の投稿の動画をみても、

SWE-grep + Sonnet 4.5 : 8.83s

Sonnet 4.5 : 27.16s

と示されており、爆速ですね。
どうやら、Devin の方でも使えるらしく、Cognition のブログリンクが Changelog に載っていました。

こちらを読み解いていこうと思います。

 SWE-grep、SWE-grep-mini の詳細Cognition のブログを読むと下記のようなことが記載されていました。
SWE-grep、SWE-grep-mini は、高度な並列コンテキスト取得に特化した高速エージェントモデルだそうです。

最新のコーディングモデルと同等のコンテキスト取得能力があり、1 桁少ない時間でそれを行えるそうです。

 課題点そもそも、コンテキスト取得の観点で下記のような課題があったそうです。
最新のコーディングエージェントは速度と知能の基礎的なトレードオフに直面している
最新のコーディングモデルは複雑なタスクを解決可能だが、ひとつのファイルの編集前に数分、検索の時間がかかる
この挙動はフロー状態を壊す

Windsurf、Devin でも同様に、エージェントが、ただのコンテキスト取得に初回ターンの 60% より多くの時間を費やしていることを観測したそうです。

 コンテキスト取得の方法歴史的に下記の 2 つの方法があるそうです。
Embedding Search（RAG）
事前のコードベースのインデックス化作業が終わると、クエリは速くなる
しかし、下記の課題がある：
結果が不正確
特に、複雑なクエリでみられる（例：大きいコードベース内での実行パス追跡など）

embeddings（ベクトル化されたデータ）は逆効果になることさえある
エージェントが関係のない情報に、過度に重点を置くかもしれないので



Agentic Search
人間がコードベースを探索するように、モデルがコードベースを探索するために CLI ツールを使う
Claude Code と Cline の両方が、両方の環境で Agentic Search がうまく動作すると示した
Windsurf、Devin でも今日まで同意見だった

より柔軟な一方で、下記の課題がある：
一般的に遅い
ユーザデバイスと推論エンドポイントの間で大量の通信が必要

関連のあるコンテキストを見つける前に、エージェントに無関係な情報に関する数万トークンに注意を払わせる
この動作は、遅さを悪化させ、エージェントのコンテキストを汚染し、回答品質の著しい低下を招く




 SWE-grep、SWE-grep-mini についてSWE-grep、SWE-grep-mini が、この速さと知性のトレードオフを解決するモデルのようです。

情報の取得能力は最新モデル並みで、一桁少ない時間で行えると記載があります。
これらのモデルは Fast Context という機能として搭載されているそうです。

関連のあるコンテキストを高速に取得するために特化したモデルのようです。
Fast Context の機能がみえてきましたね。
今まで：選択したモデルが RAG や、CLI ツールを用いてコンテキストを取得していた

これから：コンテキスト情報取得特化モデルが代わりに、コンテキスト取得する
つまり、単一モデルが担っていたコンテキスト取得を特化型モデルに分担させることで、速さと知性のトレードオフを解消する仕組みです。

コンテキスト取得がボトルネックだったため、ここを高速化することで全体のパフォーマンスが大幅に向上したということですね。
人間でいうところの分業というところでしょうか。素晴らしいですね。

Windsurf にも、AI モデル同士が協調して、問題を解決する時代がきたようです😭
性能測定結果の画像をみると、Code Search Eval、Token Per Second ともに、他の既存の最新モデルを抜いているようです。

特化型モデルだけあり、群を抜いて性能が高いですね。

 SWE-grep、SWE-grep-mini のモチベーションコンテキスト取得がカスタムサブエージェントに独自に適した仕事だと考える理由が記載されていました。
メインエージェントのためにコンテキストを節約する
メインエージェントのコンテキスト取得をサブエージェントに委譲することによって、メインエージェントのエージェントトークンを節約し、無関係な情報でメインエージェントのコンテキスト汚染を避ける
メインエージェントは関係あるトークンにのみ注意を払える

コンテキスト取得は用途が広く、幅広く役に立つ能力である
コンテキスト取得サブエージェントは、賢いモデルと速いモデル間の完璧な受け渡しポイント

コンテキスト取得は確認可能なタスク
しばしば、サブエージェントはメインエージェントのために、見つけた情報を要約するように実装される
これは 2 つのマイナス面がある：
高速モデル（サブエージェント）の要約は、間違った結論を書き、賢いモデル（メインエージェント）を間違った方向に導く可能性がある
自由形式の要約を評価するのは困難


要約する代わりに、Fast Context のサブエージェントは行範囲でファイルのリストを取得するように設計されている
このため、強化学習をするための明確で決定論的な報酬を計算するための、目的の正解データセットを定義できる



 Fast Context の使い方普通に Windsurf のカスケードを使うだけでいいそうで、UI から操作したり、コマンドを打つ必要はないようです。
Cascade にコード検索を必要とする指示をする時、Fast Context が使われるそうです。

カスケードで指示を送る際に、「Cmd + Enter」を押すと強制的に Fast Context を有効にすることができるらしいです。
実際にやってみると...
Fast Context と出るのでわかりやすいですね。「Cmd + Enter」でいけました。

 今後について最後にブログではこう書かれていました。
Windsurf の Fast Context サブエージェントは Fast Agent のためのロードマップ上の最初の踏み石
SWE-grep モデルは DeepWiki、Devin、Windsurf Tab、将来のプロダクトで、検証、調整されてデプロイされる
研究したい将来の方向性は、可変のターンの長さ、より高い知性、ツールスピードの最適化
Windsurf のゴールは利用者をフロー状態に保つこと
究極的なゴールは開発者のソフトウェアエンジニアリングの生産性を最大化すること
ざっくりとこんな感じですかね。
フロー状態について Claude さんに聞いてみました。
 完全に没入している状態
「ゾーンに入っている」状態
時間を忘れて集中している状態
今まで「フロー」=「開発の流れのようなもの」を指しているのかと思いましたが、このフロー状態を指していたのですね。

思いっきり勘違いしていました...
生産性を上げるための手段としてフロー状態に入り作業をすることがあって、その状態をエディタが壊してはいけないというのが Windsurf の考えなのだと解釈しています。

そのためには、十分に速いエージェントが必要ということでしょう。（フローを壊す確率は、エージェントの応答を待つ間、10%/s で上昇すると見積もっているとの記載もありました。それ防ぐために「速さ」が求められているということですね）

 まとめ今回は SWE-grep の速さの秘訣など、テクニカルな部分は置いておいて、概要を紹介しました。
とうとうエディタの世界でもエージェント同士がコラボして、問題を解決する時代がきたということですね。

次のアップデートがものすごい楽しみになってきました😄
次はどんなアプデが来るのでしょうか。次の Wave を今かと待ち侘びています😂

もちろん、Changelog 上のアップデートでも万歳です🙌
では、また次回。