AIコードエディタ「Windsurf」下調べ→使い始めた
フロー状態を維持するように設計
初のエージェンティック IDE であり、それ以上のものです。Windsurf エディターは、開発者と AI の作業が本当に融合する場所であり、文字通り魔法のようなコーディング体験を実現します。
Windsurf エディターは、AIが人間と協働する本来の姿を体現しています。Codeiumの優れた機能に加え、比類ないパフォーマンスとユーザーエクスペリエンスにより、作業に集中できます。
自分はCursorを使っているが、ちょっと評判が良さそうなので、少し試してみようかということで下調べ。
この辺に比較記事があった
料金
個人向けはFree / Pro / Pro Ultimateの3つ。一応サイトにも表はあるのだけど、ざっくりまとめてみた。正確性は保証しない。
Cascadeとかフローアクションってのがちょっとまだ良くわかっていないけど、前提として使用できるモデルにはベースモデルとプレミアムモデルがあって、プレミアムモデルを使用する際にクレジットが消費されるというのが基本になるみたい。
以下に記載がある。
プレミアムユーザープロンプトクレジットは、プレミアムモデル(GPT-4o、Sonnetなど)を使用してCascadeにメッセージを送信するたびに1クレジット消費されます。また、プレミアムモデルをAIがWriteモードやChatモードでツールコール(検索、分析、Write、ターミナルコマンドなど)に使用するたびに、フローアクションクレジットが1クレジット消費されます。
クレジットを使い切ると、プレミアムモデルは利用できなくなりますが、Cascadeベースモデルは引き続きご利用いただけます。プレミアムモデルへのアクセスを再開するには、ProまたはPro Ultimateプランにアップグレードしてください。
このあたりはCursorと同じようなイメージでいいかな。
とりあえず
- 現状はモデルの選択肢が少ないように思える。まあ普通に使う分には困らないのかもしれないけども(新しいモデル出たらまあ試したいのが人情)
- 実質Freeじゃ使いにくそうなので課金することになりそう
- やってみないとわからないけど、なんとなくすぐにクレジット使い切りそうな気がする、根拠はないけども
な気がした。
Cascade
個々の機能はおいておいて、Cascadeの概念的なところを少し見てみる。
公式サイトの説明
チャットのフロー進化の紹介
Cascadeは、AIを使用してコーディングする最も強力な方法です。
Cascadeのエージェント機能は、AIと人間との新たなレベルのコラボレーションを実現し、複雑なコーディングワークフローにおける究極のパートナーとなります。
知識、ツール、人間の行動の組み合わせにより、AIは開発者と完全に協調し、同期しながら、同時に可能な限り独立して強力な能力を発揮できるようになります。
公式ドキュメント
Cascadeにより、AIを使った新しいコーディング方法であるAI Flowsを公開できるようになります。
Codeiumが提唱している、この「AI Flows」ってのがCascadeの根底にあるものらしい。
AI Flowはこの動画がわかりやすかった
ざっくりまとめる。
LLMが登場する前まで、開発者はキーボードと連携して作業を行い、開発は完全に手作業、すべてのコードは人間の入力による直接的な結果だった。
LLMが登場し爆発的な人気となり、Copilotが登場する。CopilotはLLMと連携して、コードの自動補完やコマンド実行、あとはチャットで質問に答えたり、といった感じで、開発者のコーディングを「支援」する。
Copilotはどんどん改善していく。その大きな要因はアクセスできる「知識」が増えて「理解力」が高くなったこと。
ただし、Copilotは基本的にLLMに対する1回の呼び出しで完結する、つまり、タスクが終わればそれで終了する。そこで「エージェント」が登場する。
エージェントは、ツールとより進んだ知識ソースへのアクセス、そして反復的な能力を与えることで、より大きなタスクを自律的に解決することが期待された。Copilotからのさらなる前進といえる。
ただし、初期のエージェントは、待ち時間の長さや質の低い出力など、開発者の想定から逸脱するケースも多く、エージェントが行うのは単に開発者の作業部分だけの置き換えで、開発者がレビューにより多くの時間をかけることになった。
そこで、Codeium は「AI Flows」を提唱する。「AI Flows」では、開発者のアクションがリアルタイムでAIと同期する。AIは作業範囲を新たに理解する必要なく、開発者の作業に即座にリアクションする。これにより、開発者とAIのシームレスで継続的なコラボレーションが可能となる。
これを実現するのがCascadeになる。
Cascadeのエージェント機能は、AIと人間の新しいレベルのコラボレーションを解き放ち、複雑なコーディングワークフローの究極のパートナーになります。
知識、ツール、人間の行動の組み合わせにより、AIは開発者と完全に協調し、同期しながら、同時に可能な限り独立して強力な能力を発揮できるようになります。
- コンテクスト認識エンジン
Codeiumのコンテクスト認識エンジンは、ユーザのすべてのSCMと統合し、コードベースの比類ない理解を構築します。これにより、コードの受け入れ率が38%向上するパーソナライズされた提案を行うことができます。- ツール
Cascadeのツールには、編集、ファイルの追加、grep、ディレクトリ内のファイルのリスト、コードの実行、および報道で取り上げられた多数の独自ツールが含まれています。- ヒューマンアクション
人間が行うアクションの適切な粒度と範囲を見つけるのは難しいですが、洗練されたチェックポイントと圧縮により、Cascadeは人間とAIの間の共有認識の連続的な流れのように感じられます。
このあたりの詳細は以下に書かれている様子
Cascadeを使ったフローについてはOverviewの動画がわかりやすい。
また、YouTubeの公式チャネルだとこの辺もわかりやすい
とりあえず現時点での(あくまでも個人的な)所感
書いてあることを読むだけだと、Copilotでは支援しかできない、(現時点の)エージェントだとクオリティがまだ足りない(ので開発者の作業は減らず、つまらないレビューだけが増える)というところの「中間」という印象。
なので「コーディング」をどういうふうに捉えるか?によって、受け止め方は変わってきそうな気がする。
- コーディングに興味がなく、できたものが欲しい、ならば、完全自律型エージェントが望ましいと思う
- エージェントの精度が高くなれば、そもそもコラボレーション(というか開発者そのもの)は不要になる可能性もある
- 逆に、コーディングを「クリエイティブ」な作業として考えるならば、「いい感じ」のコーディング体験を生んで欲しいと思う。
- Copilotでは支援力が足りない
- エージェントが書いたものをレビューするだけは確かにつまらない。
- おそらく何かしらのレビューはどこまでいっても必要だと思うし。
- (自動テストの精度が上がればもしかするとこれもなくなるかもしれないけど)
- 「いい感じ」の落とし所がAI Flow=Cascadeなのかなと。
ビジネス的な視点だと前者になるだろうし、エンジニア的な視点だと後者になると思う(まあIDEの時点で使う人の多くは後者なんだろうとは思うけども)。多分「いい感じのペアプロ的コーディング体験」を生んでくれるってのがウリなのかなと感じた。
ただ、動画内の実際の作業を見ていると、自動である程度のものは作ってて、そのへんはエージェントというかClineのような雰囲気も感じる。あとはそこにちょろちょろ手をいれるとして、そのあたりでもいろいろアシストしてくれる機能があるっぽいので、良さそうではある。
なお、ここまで一切Windsurfを触っていないので、すべて適当な推測である。
あと、自分はCursor使ってはいるけど、全然使いこなせてる感がないし、正直機能が多すぎて追えてないのもあって、表面的な比較ぐらいしかできないかな。
こういうのは実際に触ってみないとわからんというオチ。
ここになるんかな
Windsurf makes coding insanely fun and fast!
あとスレにいろいろな機能についても書かれている
とりあえずまずはこれを始めてみた。
とりあえずWindsurfが実際にどんなふうに動くのか?どう使うのか?の観点だと、以下だけ見ておけばよいと思う。
-
- Getting Stareted & First App
- 画面に従ってハンズオン
- Getting Stareted & First App
-
- Fixing Test Automatically
-
- Understanding Large Codebases
-
- Wikipedia Analysis App - Data Analysis
- 画面に従ってハンズオン
- Wikipedia Analysis App - Data Analysis
-
- Wikipedia Analysis App - Caching
- 8の続き
- Wikipedia Analysis App - Caching
-
- Wikipedia Analysis App - Fullstack App
- 9の続き
-
- Wikipedia Analysis App - Fullstack App
-
- Conclusion
上記以外は、Windsurfがなぜすごいのか?の技術スタックやアーキテクチャの話が多かったように思う。知っておいたほうがいいとは思うが「とりあえず使う」という観点だと不要かな。
あと、モデルはClaude-3.5-Sonnetを使うようになっているが、コースとの途中で使い切ってしまう。Cascade BaseやDeepseek V3で続けれるようなのだけど、いろいろうまくいかなくなる印象なので、詰まりたくないならProプランに課金しておくほうがいいと思う。
自分はしばらく使い込んでみようと思ったので、Proプランに課金した。
なるほど、windsurf.run というサイトがある
これか
.windsurfrules については以下も参考に。
管理は以下を参考にしたい
とりあえず設定等は一切なしで、チャットだけで既存のプロジェクトを少し改修させてみた感じ。
- Cascadeと対話しながらやっていくのは良い体験。
- どういうふうに修正するか、何を修正したか、ってところを説明してくれるのが良い。
- CursorのAgentでもこれはある程度できているけど、Windsurfのほうがより「一緒に」やっている感はある
- (とはいえ、自分はCursorを使いこなせていないと感じているので、正しく評価できていないと思う)
- とはいえ、方向性を間違えることも当然あるので、そのあたりはうまく誘導する必要はあるかな。
という感じで、Cursorと比較してどうか?ということは判断できないのだけど、少なくとも、Cursorの進化にキャッチアップできていなかった・最新の情報を見つけるのがしんどい(古い情報は結構あるのだけど、今の機能やインタフェースに置き換えないといけない)という点では、Windsurfは学習コストが少なく感じていい感じに思える。でもまあ、このままWindsurfに慣れていけば、Cursorに戻れそうな気もしている。
で、デフォルトでもある程度やってくれるのだけど、.windsurfrules
を作ったほうがいいよね、ということで、以下のような感じでやってみた。
-
kinopeeeさんの
.windsurfrules
をまずベースにした。- ただし、元はTS/JSプロジェクト向けに書かれている。自分はPythonで書くことが多いので、Cascadeと対話しながらその内容をPython(バックエンド)向けに修正してもらった。
- この時点では
.windsurfrules
ではなく普通のMarkdownファイルにしている。Cascadeは.windsurfrules
をメモリとして認識しているようなので、どうやら.windsurfrules
ファイルを直接更新できないみたい。 - やり取りが終わったらそれを
.windsurfrules
にリネーム
- 適当なプロジェクトで上記の
.windsurfrules
を有効化して、Cascadeとの開発を開始- いきなり開発はさせずに、まず以下を実施
-
README.md
をしっかり読ませる - ディレクトリ構造を確認させて、それぞれのファイルの概要や全体設計なども確認させる
- その他、プロジェクトの背景情報などの追加情報をチャットで教えていく
- そして、やりたいことを伝えて、開発方針などを相談
- 一通り会話が終わったら、
.windsurfrules
を適当なファイルにコピーして、そこに会話の内容を反映してもらう。 - コピーしたファイルを
.windsurfrules
に上書き
-
- Cascadeとチャットしながら開発していく
- ある程度ルールで縛った内容に沿ってくれるが、それでも、一気にやらせない・必ずテストを書かせて実行させる、内容をチェックして都度注文をつける、などは意識しながら少しづつ進める
- いつでも戻れるように都度都度コミット。ここはまだ自分は手動でやっている。
- Cascadeはターミナルの内容も見てくれるので、実際に動かしてみたりするのも良い
- いきなり開発はさせずに、まず以下を実施
- ある程度開発のタームが落ち着いたタイミングで、振り返りを行う
-
.windsurfrules
に書いてなかったことで問題になったことはあったか? -
.windsurfrules
に書いてあったができていないことはないか? - などをCascadeと会話して、その内容を
.windsurfrules
にフィードバックさせる
-
なんというか人間とやるようなことをそのままやってみた感じかな。
.windsurfrules
に書いてても守らないことはままああって、そのあたりはまだ足りないかな、ということもあるし、自分の.windsurfrules
の書き方がまだ不十分だとも感じている。なので、事前の打ち合わせ+振り返りでそのあたりをカバーしつつ進めていく、という感じにしてる。
で、これをやるとコードを修正している時間よりも、前後の時間がめちゃめちゃかかる。プロジェクトの進め方とか規約とか、そういうのをきちんと言語化できるってのは重要だなとあらためて感じた。
まあどうせ時間がかかるのであれば、Clineなどを使って事前にガッツリ言語化してから自走させるほうががいいのかなーと思ったりもするが、自分のレベルがまだそれについていけてないので、まあ今の自分にはこれが良いかと思った。
あと、自分はまだ使い出したところなので、ルールの整理まで行き着いていないけど、いくつかルールについて気になったこと
- Cursorのように複数のルールファイルを組み合わせるような仕組みはWindsurfにはない?
- ないいならば、ルールを複数のファイルに分割して、プロジェクトの用途に合わせて
.windsurfrules
を作るような仕組みが必要になりそう
- ないいならば、ルールを複数のファイルに分割して、プロジェクトの用途に合わせて
-
.windsurfrules
は6000文字以内という上限があるのでこれに収めないといけない。- 全プロジェクト共通の
global_rules.md
も6000文字以内。で、2つ合わせて12000文字以内らしい - 参考: https://docs.codeium.com/windsurf/memories#memories-and-rules
-
global_rules.md
は今のところデフォルトのままだけど、常に有効化するルールをglobal_rules.md
に移したほうが良さそう。
- 全プロジェクト共通の
このあたりは使っていきながら調整かな
docsに切り出せることは切り出して @ で都度コンテキストに読み出すとかも良さそう。