なぜAI開発はプロンプトから環境設計へ変わるのか。Windsurfのルールファイル機能が示すAIが働きやすい仕組み構築

プロンプトをこね回す時間は終わった

AIコーディングエディタWindsurfが、2025年2月から2026年3月の1年間で100以上のバグ修正と3つの新モード追加を実施した。

GPT-5系列やClaude 4.5、Gemini 3系列への対応拡大だけではない。

本質は、AIエージェントを動かす環境そのものの根本的な再構築だ。

プロンプトエンジニアリングの賞味期限は切れた。

AIにどう指示するかを悩むフェーズは過ぎた。

AIが失敗しても再開でき、ルールを逸脱できない環境の構築が勝負を分ける。

これは2026年に入って注目を集めるHarness Engineeringと呼ばれる領域だ。

AIエディタが「統合実行環境」へ進化した1年

Windsurfのアップデートは単なる機能追加の枠を超えている。

エディタがAIエージェントの実行と協調を管理するオーケストレーターへと変貌した。

Arena Modeの導入が象徴的だ。

2つのCascadeエージェントをモデル名非公開で並列実行する。

どちらが優れた回答を返すかユーザーが投票し、個人とグローバルのリーダーボードで結果が集計される。

開発者はモデルの選定すらAI同士の競争に委ねる形になった。

CodeとAskに並ぶ第三のモードとしてPlan Modeも追加された。

megaplanコマンドで明確化質問付きの高度な実装計画を事前に作成する。

いきなりコードを書かせるのではなく、事前の合意形成を強制する仕組みだ。

Git Worktreeのサポートにより、フィーチャーブランチごとに独立したCascadeセッションを走らせる。

別のタスクを進めながら、裏でAIに重いリファクタリングを任せることが可能になった。

ファイルベースルールの設定も追加された。

.windsurf/rules/ディレクトリにマークダウン形式でルールを配置する。

これだけで特定パターンのファイルに対するAIの挙動を根本から制御できる。

ワークフローの定義も外部化された。

.windsurf/workflows/にファイルを置けばスラッシュコマンドとして呼び出せる。

コードレビューの観点やテストの実行手順をプロジェクト固有の制約としてAIに強制できる。

2025年4月21日に全既存プランが新価格モデルに移行し、ツールコールが無料になった。

MCPサーバー経由で外部ツールを呼び出すワークフローがコスト面でも有利になった。

主要モデルの多くは期間限定プロモーション価格で提供されている。

GPT-5の例では無料からHigh 2xへ価格が上がるケースがある。

コスト計画にはシビアな視点を向ける。

※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。

Harness Engineeringという新しい主戦場

AIエージェントを実務に組み込むと壁にぶつかる。

プロンプトでanyを使わないでとお願いしてもAIは普通に忘れる。

セッションが変われば文脈は薄れる。

複雑な作業では優先順位も崩れる。

プロンプトは本質的に依頼ベースだ。

依頼は効くこともあるが動作の保証にはならない。

個人が一度使うだけなら十分だ。

チーム開発や継続運用ではお願いではなく強制できる仕組みが求められる。

次に流行したコンテキストエンジニアリングも万能ではない。

1回のセッション内の精度は上がった。

AIエージェントは長時間かかる作業を1回で終えられない。

途中で止まり、次のセッションで再開し複数日にまたがって仕事を進める。

前回どこまでやったのか、何を判断済みなのかが簡単に失われる。

ここで求められるのは単発のコンテキスト供給ではない。

継続的に仕事が進むように環境を設計することだ。

これがHarness Engineeringの核心だ。

Harness EngineeringはAIにうまくお願いする技術ではない。

AIエージェントが安定して働けるように制約と継続性と回復性を持った実行環境を作る技術だ。

AIに賢く振る舞ってもらうことを期待しない。

賢く振る舞わざるを得ない環境を作る。

WindsurfのファイルベースルールやMCP統合はこの環境設計の具現化だ。

IDEというベンダー提供の統合環境内でエージェントを管理し完結させる方向に向かっている。

開発者はプロジェクト自体をAIが働きやすいアーキテクチャへ再構築する。

しんたろー：
Claude Codeの挙動を見ていると、この流れはすごく気になる。
プロンプトをこねるより、ディレクトリ構成とCIを整えた方がAIは素直に動くと思った。
結局、人間がサボるための環境作りに行き着く。サボるための環境作りに週末を全部潰している本末転倒な日々だ。

マルチエージェント協調の文脈でも同じ問題が起きている。

単一のランタイムを賢くする問題と複数のエージェントを協調させる問題は別物だ。

複数のエージェントがいる場合、単にランタイムを増やせばいいわけではない。

求められるのはランタイム間の交通整理だ。

エージェント同士が自然言語で会話する仕組みはデモとしては機能する。

実務で求められるのはもっとシステム指向な協調基盤だ。

ここで状態とイベントの分離が鍵を握る。

状態は永続化される事実や履歴だ。

後から参照できる真実の情報源として残す。

イベントは何かが変わったのでランタイムを起こすというシグナルだ。

状態だけでは反応できない。

イベントだけでは履歴や説明可能性が弱くなる。

AIエージェントに人間のような記憶を期待してはいけない。

記憶はAIの中に持たせず環境側で管理する。

これだけで次のセッションが別人のように始まる問題を8割方軽減できる。

エージェントの起動条件も整理する。

状態変化や時刻条件から発生するシグナル。

所有権を伴う作業単位。

どのイベントでどのエージェントを起こすか。

これらを明確に分離して設計する。

AIエージェントは必ず失敗する。

期待値を間違えてはいけない。

失敗しないことではなく、失敗しても途中から再開できる構造を作る。

長時間タスクほどこの設計の差がもろに出る。

最小限の運用可能なハーネスから始める

では僕らの開発にどう関係するのか。

明日からプロンプトの微調整をやめる。

代わりにプロジェクトの環境設計に時間を投資する。

まずはエージェントの行動を構造化する。

AIエージェントを自由に動かすと余計なファイルを触り勝手に設計を広げる。

何をしてよいかを明示的に定義する。

Claude Codeでも同じだ。

.claude/commands/ディレクトリに呼び出し可能なコマンドを定義する。

テストの実行や機能の作成やドキュメントの更新。

許可された手順の中だけで動かす。

自由を与えないことが生産性を生む。

次にプロンプトでの禁止事項をシステムの設定に置き換える。

anyを使うなと指示する代わりにTypeScriptの厳格モードやESLintやBiomeを導入する。

MCP経由でCIを回す。

使いたくてもエラーで弾かれAIが自己修正せざるを得ない環境を作る。

AI向けのガイドファイルも書き方を変える。

プロジェクトのルートに配置するCLAUDE.mdなどのファイルだ。

ここに長大なシステム仕様や背景説明を書いてはいけない。

長すぎるファイルは読まれにくくノイズになる。

ガイドファイルはドキュメントではなくポインタとして扱う。

テストの実行コマンド。

リンターの実行コマンド。

参照すべき設計ドキュメントのパス。

何を見て何を実行し何に従うかだけを簡潔に定義する。

AIが迷わずツールを実行できる状態を作る。

しんたろー：
AI向けの指示書を極限まで削るアプローチはすごく気になる。
結局、AIも人間と同じで長いマニュアルは読まないんだと思った。
迷う余地をなくすアプローチを試してみたい。試す前に自分の部屋の迷う余地をなくすのが先だ。

マルチエージェント協調の考え方も日常の開発に取り入れる。

WindsurfのGit Worktreeごとの独立セッションを使う際のメンタルモデルだ。

エージェント間で直接会話させるのではない。

タスクとコードを介して非同期に連携させる。

状態の外部化を意識する。

エージェントに記憶を頼らない。

タスクの進捗や決定事項は常にdocs/progress.mdなどのテキストファイルに書き出させる。

セッションが切れてもそのテキストを読み込ませればすぐに作業を再開できる。

最初から完璧な環境を作る必要はない。

最小限の運用可能なハーネスから始める。

コマンドを1つ定義する。

リンターを1つ追加する。

その小さな制約の積み重ねがAIエージェントの安定稼働を支える強固な基盤になる。

AI開発環境の設計に関するFAQ

WindsurfのルールファイルとHarness Engineeringはどう結びつくか？

Windsurfの.windsurf/rules/ディレクトリはHarness Engineeringにおける制約の設計そのものだ。

プロンプトでこのライブラリは使わないでとお願いするアプローチは過去のものになった。

ルールファイルやMCP経由のリンターを組み合わせて、禁止されたコードを書こうとしてもエラーで弾かれAIが自己修正せざるを得ない環境を作る。

人間の介入なしにAIを正しい方向へ補正する仕組みの構築がHarness Engineeringの実践だ。

マルチエージェント協調の考え方は日常の開発にどう活かせるか？

直接的なシステム開発だけでなくAIエディタを使いこなす際のメンタルモデルとして機能する。

WindsurfのGit Worktreeごとの独立セッションを活用する場面を想像する。

複数のエージェント間で直接会話させるのは非効率だ。

タスクとコードやドキュメントを介して非同期に連携させる設計を意識する。

これにより複雑な機能開発を並行して進めやすくなりコンフリクトや文脈の喪失を防ぐ。

最小限の環境設計を始めるには何から手をつければいいか？

まずはプロジェクトのルートディレクトリにAI向けのポインタとなるファイルを配置する。

CLAUDE.mdや.windsurf/workflows/などだ。

ここに長大なシステム仕様を詰め込んではいけない。

テストの実行コマンドやリンターの実行コマンドや参照すべき設計ドキュメントのパスだけを簡潔に定義する。

AIが迷わずツールを実行し自己検証できる状態を作ることが強固な基盤への第一歩だ。

まとめ

AIエージェントを使うフェーズは終わり、安定稼働させる環境を作るフェーズへ移行した。

Windsurfのルールファイル機能と、Harness Engineeringの環境設計思想、そしてマルチエージェント協調における状態とイベントの分離。

これら3つの視点を統合すると、AI開発の主戦場がプロンプトからシステムアーキテクチャへと完全に移行したことがわかる。

しんたろー：
ツールが進化するほど、基礎的な設計力の差が浮き彫りになると思った。
プロンプト職人を卒業して、環境構築のプロになるタイミングが来ている。
結局、ソフトウェアエンジニアリングの基本に回帰している。基本に回帰しすぎて、最近は紙とペンで設計図を書いている。

👉 ThreadPostでSNS運用を自動化する