Windsurfの基本的な使い方｜プロジェクトを開いてAIを使うまで

Windsurfの使い方を今から始める場合は、現在の名称であるDevin Desktopを入れ、既存projectを開き、小さな変更を依頼してdiffとtestを確認するところから始めます。最初から複数agentやMCP連携を足す必要はありません。名前が変わってもIDEとしての作業を引き継いでいるため、旧Windsurfのsettingsやextensionを使う人は移行状態を確認し、新規利用者は公式のcurrent installerから始めると迷いにくくなります。

始める前に用意するもの

必要なのは、対応OSの端末、利用するDevin account、作業するrepository、そして変更してよい範囲です。会社のsource codeを扱う場合は、ツールを開く前に社内AI利用policyとrepositoryの権限を確認します。client repository、未公開機能、秘密情報があるなら、契約やclient consentの確認も先に済ませます。アカウントを持っていることだけで、すべてのrepositoryを入力してよいとは限りません。

作業開始時は、cleanなbranchか既存の変更が分かる状態を用意します。agentへ依頼する前にgit statusを見て、自分の未commit変更が混ざっていないか記録すると、後で差分の所有者を取り違えにくくなります。重要なrepositoryでは、作業branchとrollback方法を確認してから小さなtaskに進みます。

installから最初の起動まで

公式のDevin Desktop install案内でOSに合う配布方法を選び、インストール後にアプリを起動します。初回onboardingではtheme、必要ならVS CodeまたはCursorのsettings importを選べます。terminalから起動したい人は、onboardingに表示されるterminal commandのインストール選択を確認します。最後にDevin accountでsign inし、起動画面が開くことを確認してください。

旧Windsurf利用者は通常の更新でDevin Desktopへ移ることができ、公式案内ではplan、pricing、extensions、settings、作業中の内容を引き継ぐとされています。新規installと既存installの移行を混同すると、profileやextensionを二重に作ることがあります。まず既存appのversionとsettingsが見えることを確認し、問題が出た場合に限って公式のFAQやmigration案内を使います。

表は横にスクロールできます

手順	画面で確認すること	次へ進む条件
installerを選ぶ	OSに合う公式配布物か	install完了と起動を確認
onboarding	theme、settings import、terminal command	必要な項目だけ選んだ
sign in	正しい個人 / 組織account	Workspaceが開いた
projectを開く	対象repositoryとfolder	変更範囲が意図どおり
最初の依頼	小さく検証可能なtask	diffとtest結果を人が確認

projectを開いたら、依頼範囲を先に固定

最初の依頼では「このprojectを改善して」ではなく、対象、制約、終了条件を短く指定します。例として、「src/settingsのこの表示で、空欄時の文言だけ変更してください。API、schema、他画面は変更せず、関連testを実行し、変更fileと結果を報告してください」のように伝えます。これは依頼文の型を覚えるためではなく、変更範囲を比較できるようにするためです。

依頼には、少なくとも目的、対象fileや画面、変更してよい範囲、触れない範囲、受け入れ条件を含めます。曖昧な用語があるならagentに編集前に確認させ、設計判断が必要なときはコードを書き始める前に選択肢を返すようにします。production環境、secret、外部serviceへの書き込みなどは、repo内変更と同じ権限で扱わないでください。

良い最初のtaskは、失敗しても元に戻しやすく、正しさを人が確認できるものです。たとえば既存testに従った文言修正、関数の説明、単純な表示bugの局所fixなどです。認証、billing、データ削除、migration、production deployは初回の練習題材には向きません。権限が必要な操作を頼む前に、その権限と影響範囲を明示します。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  Windsurf

  公式サイトを見るTool詳細を見る

agentが返した変更を受け入れる前に

agentの完了報告を、そのまま成功の証拠とはみなしません。差分を開き、意図したfileだけが変わったか、既存の未commit変更を消していないか、testが実際に通ったかを確認します。testがない場合は、それ自体を隠さず手動で確かめる方法を決めます。

表は横にスクロールできます

確認	見るところ	NGなら
scope	変更fileが依頼範囲内か	追加変更の理由を尋ね、不要分を戻す
behavior	要件を満たし既存動作を壊していないか	具体的な再現条件を伝えて修正
tests	実行したcommandと実際の結果	未実行なら未検証として扱う
data/security	secret、個人情報、危険な権限変更がないか	値を伏せてsecurity reviewへ
rollback	変更前へ戻す手段があるか	mergeやdeploy前に手順を作る

特にagentが「testを追加した」と言っても、testを実行したとは限りません。実行ログ、終了状態、失敗時の説明を確認します。生成コードや依存の追加は、差分に現れる理由とmaintenanceコストも見ます。agentが実際にはアクセスできないbrowserやserviceを試したと主張していないかも確認してください。

terminal commandとshell環境

onboardingでterminal commandを有効にした場合でも、新しいshellがそのcommandを見つけるかを確認します。アプリ内terminal、OSのterminal、別のshellで結果が異なることがあります。command not foundなら、公式FAQの現行command名と設定先を確かめ、古いsurf / windsurf commandと新しいdevin-desktop commandが混在していないかを調べます。古いshortcutをいきなり消さず、どのappへ接続するか確認してから整理します。

複数OSを使うチームでは、install手順、更新方法、terminal commandの導入をREADME等へ分けて記録すると再現しやすくなります。特定OSのinstallerや自動更新挙動を他OSに当てはめないでください。企業端末では管理者が配布した版や更新policyが優先される場合があります。

うまくいかないときの切り分け

アプリが起動しない場合は、OSとinstall method、version、表示されたerrorを確認します。appは開くがsign inできないなら、組織account、browser session、network policy、SSOを分けます。terminal commandだけ失敗する場合は、commandのinstall選択、PATH、起動shellを確認します。projectが見えない場合は、workspace pathとOS permissionを見て、agentへ広い権限を付ける前に対象folderを確かめます。

変更後のtestが失敗した場合は、agentへ「直して」だけでなく、失敗したtest名、期待値、実際の出力を渡し、変更が要求範囲内であることを再確認させます。何度も修正が続き、diffが大きくなるならtaskを止め、最初の要件へ戻って作業を分割します。原因を理解せずに大規模な変更を受け入れるより、小さく戻して再依頼する方が安全です。

最初の10分を使った導入チェック

1. 正しいOS向けのDevin Desktopを公式案内からinstallする。

2. 旧Windsurfからの移行か新規利用かを確認する。

3. accountへsign inし、必要なら組織管理者の承認を得る。

4. 変更してよい小さなrepositoryを開く。

5. 目的、scope、禁止事項、test条件を含む小taskを渡す。

6. diff、実行test、未確認点を自分で読んで、受け入れるか戻すか決める。

このチェックで確認するのは、agentが速いかどうかだけではありません。依頼の境界を保てるか、意図しないfileを触らないか、失敗を説明できるか、人間が変更を確認できるかです。これができれば、より大きなtaskやteam workflowへ進む判断材料になります。

AIものさしの判断

使い始めるときは、現在のDevin Desktopを公式手順でinstallし、設定を必要な分だけ取り込み、小さな変更を一つ依頼してください。次に、diffとtestを人が確認する手順を作ります。旧Windsurfからの移行はデータやplanの継承が案内されていますが、個別の組織policyと端末管理は別です。まだreviewやrollbackの方法がないなら、agentへ任せる作業範囲を広げる前にそこを整えるのが先です。