![]()
Windsurfの精度が低いと感じたら見直す7つの設定とプロンプト改善
この記事のポイント Windsurfの精度が落ちる原因は、モデルの性能よりも「文脈の渡し方」にあることがほとんどです。 症状を4パターンに切り分ければ、打つべき手はほぼ機械的に決まります。 指示文は6要素の型に流し込むだけで安定し、Memoriesとルールファイルで毎回の説明が要らなくなります。 2026年3月19日の料金体系の変更で、使用量の考え方も変わりました。
「昨日はいい感じに直してくれたのに、今日はまるで見当違いのコードを出してくる」。Windsurfを使い込むほど、この落差にイライラしてきます。原因はモデルが劣化したからではありません。渡している文脈が、日によって変わっているからです。
直し方は地味です。指示文の型を決め、参照させるファイルを絞り、モードを使い分ける。それだけで体感の精度は変わります。
Windsurfの精度が低い最大の原因は、モデルではなく文脈の渡し方

Windsurfとは、プロジェクト全体の内容を自動で読み取り、自然言語でコードの生成・修正・整理を指示できるAI搭載のIDE(開発環境)です。VS Codeをベースにしているため、既存の拡張機能やキーバインドをほぼそのまま持ち込めます。
この「自動で読み取る」が両刃の剣。うまくハマれば説明ゼロで意図を汲んでくれますが、読み取る範囲がズレると、存在しない関数を前提にしたコードを平然と出してきます。
精度が落ちる要因は、だいたい次の3層に分かれます。
- 文脈の層: どのファイルを見せたか、会話が何往復目か
- 指示の層: 何をしてほしいか、何をしてはいけないかが書かれているか
- 設定の層: モード、モデル、ルールファイル、インデックスの状態
この3層のうち、ユーザーが一番コントロールできるのは指示の層です。そしてほとんどの人が、ここを一番おろそかにしています。
「精度が低い」の正体は4パターンに分かれる

同じ「精度が低い」でも、症状によって原因も対処もまったく違います。まずは自分がどれに当てはまるかを見てください。
下の表は、よくある症状と、その裏側で起きていることを対応させたものです。
| 症状 | 実際に起きていること | 最初に打つ手 |
|---|---|---|
| 存在しない関数・ライブラリを使う | 参照ファイルが足りず、AIが埋め合わせで作文している | 該当ファイルを明示的に指定して渡す |
| 指示と違う場所を書き換える | 対象範囲が曖昧で、AIが「よかれと思って」広げている | 変更してよいファイルと行を限定する |
| 前に決めたルールを忘れる | 会話が長くなり、序盤の内容が薄まっている | 新しい会話を始め、ルールをファイル側に置く |
| 途中で止まる・出力が尻切れになる | 一度に頼んだ量が多すぎる | タスクを3つ以下に割る |
つまり、「精度が低い」という感想を症状に翻訳した時点で、対処は半分決まります。感覚のまま何度もやり直すのが一番の時間泥棒。
なぜ同じ指示でも答えの質が変わるのか?
答えの質が変わる最大の要因は、AIが一度に扱える文字のかたまり(トークン)の量に限りがあることです。会話が長くなるほど、序盤の情報は相対的に薄まります。
10往復目の会話で「さっき言ったコーディング規約に従って」と書いても、AIの中でその規約の重みは初回とは違います。人間なら「さっきの話」で通じますが、AIは全部を同じ濃さでは覚えていません。
さらに、参照するファイルが毎回変わります。プロジェクト全体を自動で読み取る仕組みは、裏を返せば「今日はどのファイルを見たか」がユーザーから見えないということ。だから昨日と今日で答えが変わります。
対策は3つです。
- 会話は1テーマ1スレッド。テーマが変わったら新しく始める
- 守ってほしいルールは会話ではなくファイルに書く
- 参照してほしいファイルは、毎回明示的に指定する
とくに1つ目は効きます。長いスレッドを引きずるより、新しく始めて必要な文脈だけ渡し直したほうが速い。これは慣れるまで抵抗がありますが、慣れると戻れません。
指示文はこの6要素に流し込むと安定する
Windsurfへの指示文(AIへの指示のこと。プロンプトとも呼びます)は、思いつきで書くと質が安定しません。6つの要素を埋める型にすると、当たり外れが小さくなります。
埋めるのは「目的・対象・制約・出力形式・禁止事項・検証方法」の6つ。次の表は、よくある雑な指示と、型に流し込んだ指示を並べたものです。
| 要素 | 雑な指示 | 型に流し込んだ指示 |
|---|---|---|
| 目的 | 「ログイン直して」 | 「ログイン失敗時に画面が固まる不具合を直したい」 |
| 対象 | (書かない) | 「対象はsrc/auth/login.tsとuseAuth.tsの2ファイルのみ」 |
| 制約 | (書かない) | 「既存の関数シグネチャは変えない。依存パッケージも追加しない」 |
| 出力形式 | (書かない) | 「差分だけを示し、変更理由を1行ずつ添える」 |
| 禁止事項 | (書かない) | 「テストファイルとCI設定には触らない」 |
| 検証方法 | (書かない) | 「npm run test:authが通ることを確認する手順も書く」 |
つまり、AIに考えさせる余地を減らすほど精度は上がります。「いい感じに」は最悪の指示。
そのまま使えるテンプレート
コピーして使える形にすると、こうなります。
【目的】○○という不具合を直したい/○○という機能を追加したい
【対象ファイル】src/xxx.ts, src/yyy.ts (これ以外は変更しない)
【制約】既存の型定義は変えない/新しい依存は追加しない
【出力】差分と、変更理由を1行ずつ
【禁止】テスト・CI設定・環境変数ファイルには触らない
【検証】○○コマンドが通ることを確認する手順も出す
この型は開発以外でも同じように効きます。画像生成でも指示の具体性がそのまま結果に出るので、AIイラストツールの選び方を先に読んでおくと、指示文の作法が分野をまたいで共通していることが分かります。細かい制御まで踏み込みたいならComfyUIとStable Diffusionの違いが参考になります。
WriteモードとChatモードを使い分けると事故が減る
WindsurfのUIは「Write」と「Chat」を切り替えられます。Writeはコードを書き換えるモード、Chatは質問して答えをもらうモード。
ここを分けずに使っている人が驚くほど多いです。「この設計どう思う?」とWriteモードで聞くと、意見を返すついでにファイルを書き換えられることがあります。逆に「この関数を直して」とChatモードで頼むと、コードは提示されるのに適用されません。
使い分けの目安は次のとおりです。
- Chat: 設計相談、エラーの原因調査、既存コードの読み解き
- Write: 変更内容が自分の中で固まっている作業
- 迷ったらChatから: 方針を固めてからWriteに渡す
「Chatで設計を決めてからWriteで書く」の2段構えにすると、意図しない書き換えがほぼ消えます。地味に効きます。
Memoriesとルールで「毎回説明する」をやめる
Windsurfには、コードベースを分析して設計パターンや命名規則を記憶するMemoriesの仕組みがあります。ただし、記憶に任せきりにすると「覚えてくれていると思っていたのに違った」が起きます。
確実なのは、守ってほしいことを人間側がファイルに書いておくことです。プロジェクト直下にルールを記述したファイルを置き、そこに以下を書きます。
- 使っている言語・フレームワークとバージョン
- 命名規則とディレクトリ構成の方針
- 触ってはいけないファイル
- コメントや文言の言語(日本語か英語か)
ここを書いておくと、毎回の指示文が短くなります。指示文が短いほど、その回に伝えたい本題の重みが増える。逆説的ですが、書く量を減らすために先に書いておくわけです。
ここまでの整理: 精度の問題は「症状の切り分け → 指示文の型 → モードの使い分け → ルールの外部化」の順で潰すのが最短です。モデルを変えるのは、この4つを済ませてから。
モデルを変えると精度はどれくらい変わるのか?
モデル変更の効果は、タスクの種類によって大きく違います。設計の相談では差が出やすく、単純な置換作業ではほとんど差が出ません。
2026年4月時点で、WindsurfとCursorはどちらもAnthropicのClaude系、OpenAIのGPT-5系、GoogleのGemini Pro系に加え、DeepSeek V3やQwen 3 Coderといった公開重みのモデルを選べます。同じモデルが両方で使えるので、「エディタを変えればモデルが良くなる」わけではありません。
以下は、タスク別にどの系統を当てるかの目安です。
| タスク | 向いているモデル系統 | 理由 |
|---|---|---|
| 設計相談・仕様の整理 | Claude系の上位モデル | 長い文脈の整理と一貫性の維持に強い |
| 複数ファイルにまたがる修正 | Claude系・GPT-5系 | 依存関係の追跡が必要 |
| 単純な置換・定型リファクタ | 軽量モデル(GPT-5 mini等) | 精度差が小さく、速度と使用量で得 |
| コード読解・説明 | Gemini Pro系 | 長い入力を一度に扱いやすい |
つまり、全部を最上位モデルで回すのは使用量の無駄です。軽い作業は軽いモデルへ。重い判断だけ上位モデルに任せる。この振り分けだけで、月末に枠が尽きる問題がかなり緩みます。
精度が落ちたら真っ先に見直す設定7つ
設定側の原因は、症状が「なんとなく調子が悪い」という形で出るため気づきにくいです。上から順に確認すると効率がいい順に並べました。
| # | 見直す箇所 | 確認すること | 効き目 |
|---|---|---|---|
| 1 | 会話の長さ | 10往復を超えていないか | 大 |
| 2 | 参照ファイルの指定 | 対象を明示しているか | 大 |
| 3 | ルールファイル | プロジェクト直下に置いてあるか | 大 |
| 4 | モード | Write/Chatを目的で選んでいるか | 中 |
| 5 | インデックス | 大量のファイル追加後に再構築したか | 中 |
| 6 | 除外設定 | node_modules等が読み込み対象に入っていないか | 中 |
| 7 | モデル選択 | タスクの重さと釣り合っているか | 小〜中 |
5番と6番は見落としがちです。依存パッケージのフォルダや生成物がインデックスに混ざると、AIが的外れなファイルを参照します。除外設定を整えるだけで、答えの精度が戻るケースは珍しくありません。
7番を最後に置いたのは意図的です。モデル変更は分かりやすい打ち手なので真っ先に試したくなりますが、上の6つを放置したままモデルだけ変えても効果は薄い。
それでも直らないときは何を疑うか?
上の7つを潰しても改善しないなら、疑うべきはWindsurf側ではなくタスクの切り方です。1回の指示で頼んでいる内容が、そもそも大きすぎる可能性があります。
判断の目安はシンプルです。「変更するファイルが5つを超える」「新しい概念を2つ以上導入する」。どちらかに当てはまるなら、分割してください。
分割の手順はこうなります。
- Chatで方針だけ決める(コードは書かせない)
- 方針を箇条書きで自分の言葉に直す
- 1ステップずつWriteで実行する
- 各ステップの後で必ず動作確認する
もうひとつ、意外に多いのが「調べ物をコーディングAIにやらせている」パターンです。最新のライブラリ仕様やエラーの事例調査は、AI検索ツールのほうが正確で速い。この使い分けを知りたいならFeloの完全ガイドが実務目線でまとまっています。汎用AIとの役割分担を整理したいときはMeta AIの使い方ガイドも比較材料になります。
料金プランと使用量の関係で「急に精度が落ちた」と感じる罠
体感の精度が突然落ちたときは、使用量の上限に達して軽量モデルへ切り替わっている可能性を疑ってください。上位モデルが使えなくなると、答えの質は目に見えて変わります。
2026年3月19日、Windsurfはクレジット制から使用量の枠(クォータ)制へ料金体系を切り替えました。同時にProは月20ドルになり、Teamsは1席あたり月40ドル、上位のMaxが月200ドルで登場しています。数字は2026年4月時点のもので、公式ドキュメントの表記更新が追いついていない時期がありました。契約前に公式サイトで現行の条件を必ず確認してください。
| プラン | 月額(2026年4月時点) | 想定する使い方 |
|---|---|---|
| Free | 0ドル | お試し。枠は小さい |
| Pro | 20ドル | 個人開発・副業レベルの常用 |
| Teams | 40ドル/席 | チームでの共有ルール運用 |
| Max | 200ドル | 上位モデルを一日中回す前提 |
つまり、月の後半だけ調子が悪いなら、それは指示文の問題ではありません。使用量の設計の問題です。軽いタスクを軽量モデルに逃がす運用に切り替えるのが先決。
社内で複数人が使うなら、利用ルールと記録の設計も同時に必要になります。この観点は社内監査で使えるAIツールの記事が参考になります。
他のAIエディタに乗り換えるべきか?
結論、指示文と設定の見直しを試す前に乗り換えるのは早すぎます。同じモデルが使える以上、エディタを変えても文脈の渡し方が下手なら結果は変わりません。
そのうえで、乗り換えを検討していい条件は3つに絞られます。
- 大規模なプロジェクトで、拡張性やカスタマイズの限界に当たっている
- チーム全体で共有ルールを厳密に強制したい
- 自前のAPIキーで細かくコストを管理したい
1つ目と2つ目ならCursor、3つ目ならClineやClaude Codeが候補です。既存のIDEを変えたくないならGitHub Copilotを足すだけでも足ります。
逆に、UIの分かりやすさと初期の学習コストの低さを重視するなら、Windsurfのまま設定を詰めたほうが得です。小〜中規模のプロジェクトでは特にそう。
AI PICKS編集部の判定
Windsurfの精度問題は、9割が使い方の問題です。ツール側の欠陥として語られがちですが、症状を4パターンに切り分けて、指示文を6要素の型に流し込み、ルールをファイルに外出しする。この3つを済ませた時点で、不満のほとんどは消えます。ここまでやって残る不満だけが、本当のツール側の限界です。
そのうえで正直に書くと、Windsurfは「自動で文脈を読む」設計が強みでもあり弱みでもあります。うまくハマるときの手数の少なさは重宝しますが、外したときに理由が見えにくい。大規模プロジェクトで細かく制御したい人には、この不透明さが微妙に感じられるはずです。
料金面では、2026年3月の改定でProが月20ドルになり、価格での優位はなくなりました。それでも小〜中規模の開発で初期の学習コストを抑えたいなら、いまも十分に有力な選択肢。乗り換えを考える前に、この記事の設定7つを上から順に潰してください。それが一番安上がりです。
よくある質問(FAQ)
Q. Windsurfの精度が低いと感じたとき、最初に何をすべきですか?
会話を新しく始めてください。10往復を超えたスレッドは、序盤の指示が薄まっています。新しいスレッドで、対象ファイルと制約を明示して渡し直すのが最短です。
Q. 日本語で指示すると精度が落ちますか?
日本語そのものが原因になることは多くありません。落ちる場合は、日本語だから曖昧に書いてしまっている可能性が高いです。対象ファイル名やコマンド名など、固有の情報を必ず入れてください。
Q. モデルを最上位に変えれば解決しますか?
タスクが重い場合は効きますが、単純な置換作業ではほとんど差が出ません。使用量の枠を消費するだけになります。設定7つを見直してから変えるのが順番として正解です。
Q. 前に決めたルールをすぐ忘れるのはなぜですか?
会話の中で伝えたルールは、往復が増えるほど重みが下がるためです。守ってほしいことはプロジェクト直下のルールファイルに書いてください。会話ではなくファイルに置くのが原則。
Q. WriteモードとChatモードはどう使い分けますか?
変更内容が固まっている作業はWrite、方針が決まっていない相談はChatです。迷ったらChatで方針を固めてからWriteに渡す2段構えにすると、意図しない書き換えが減ります。
Q. 大量のファイルを追加した後に精度が落ちました。原因は?
インデックスの再構築が追いついていない可能性があります。あわせて、依存パッケージのフォルダや生成物が読み込み対象に入っていないかも確認してください。
Q. 月の後半だけ調子が悪くなるのはなぜですか?
使用量の枠を使い切り、軽量モデルに切り替わっている可能性があります。2026年3月19日にクレジット制からクォータ制へ変わったため、消費の感覚が以前と違う点にも注意してください。
Q. CursorとWindsurfでモデルの性能差はありますか?
2026年4月時点では、どちらもClaude系・GPT-5系・Gemini Pro系など同じ主要モデルを選べます。モデル性能で選ぶ意味は小さく、拡張性やUIの好みで選ぶのが実態に合っています。
あわせて見たいツール・カテゴリ
Windsurfの設定を詰めても物足りないときは、周辺のツールを組み合わせるのが早いです。用途別に候補を挙げます。
- Windsurf — 本記事の主役。VS Code系のUIで移行コストが低い
- Cursor — 大規模プロジェクトと拡張性重視ならこちら
- Claude Code — ターミナル中心で作業する人向け
- Cline — 自前のAPIキーでコストを細かく管理したい人向け
- GitHub Copilot — 既存のIDEを変えずに補完だけ足したい場合
- AIコーディングツール一覧 — カテゴリ全体を眺めて比較する
- AIコーディングツールのランキング — 評価の高い順に確認する
- AIエージェント一覧 — 自律的にタスクを進める系のツール
次に読むならこれ。指示文の型が分野をまたいで効くことを確かめたいなら、AIイラストツールの選び方がおすすめです。同じ「具体性が結果を決める」構造を、まったく違う出力で体感できます。
各ツールの公式サイト(一次情報)
料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。
- Windsurf — 公式サイト(AI PICKSの詳細)
- Cursor — 公式サイト(AI PICKSの詳細)
- GitHub Copilot — 公式サイト(AI PICKSの詳細)
- Claude Code — 公式サイト(AI PICKSの詳細)
