ソフトウェア開発の大きな進歩は常に、チームが意図をどう表現するかを変えてきました。ウォーターフォール開発では、方向転換に時間がかかったため、詳細なドキュメントに大きく依存していました。アジャイルでは、反復のコストが低く、チームが動きながら学べるようになったことで、ドキュメントは軽量化されました。

エージェントにも、エージェントならではのプランニングスタイルが必要です。意図を早い段階で固定してしまうゲート型プロセスではなく、事前に方向性を示しつつ、実際の仕事に根ざして常に更新され続けるようなプランニングアプローチを取ることで、エージェントは最大限に力を発揮します。

#エージェントが効果的に機能するために必要なこと

エージェントは、問題を明確な言葉で言語化できるときにブレずに進められます。質問を投げかけ、前提を取り払い、コードに触れる前に道筋を整理します。そのような行動を取るように訓練されています。

計画が明示的で柔軟に変えられるものであれば、エージェントに長い作業を任せても、方向性が逸れにくくなります。このため、エージェントのプランニングは、固定的な仕様よりも、反復的に更新できるインターフェースとの相性が良くなります。計画そのものがループの一部になります。

エージェントが制約を見つけるたびに、計画が更新されます。ユーザーが意図を磨き込むと、計画は再び変化します。このリズムは、従来のように計画フェーズを明確に区切ったプロセスよりも、エージェント駆動の開発の性質によくなじみます。

#Cursor がエージェントインテリジェンスのために計画をどう設計しているか

私たちは、ソフトウェア開発チームがエージェントを使って最も生産性高く開発を進められる、という理解に基づいて Plan Mode を構築しました。これは、エージェント駆動の開発のために特別に設計された、強力で汎用的な計画アプローチです。

Plan Mode は、エージェントが質問を行い、コードベースをスキャンし、進め方を提案し、ユーザーと一緒にそれを洗練させるための「場」を提供します。軽量に保って素早いタスクに使うことも、より長期的に使うチームの基準成果物に育てることもできます。このプロセスは、次の 5 つのステップに従います。

1. 不明点の明確化。エージェントはあいまいさを取り除くための質問を行います。アジャイルなチームは、素早い往復のやり取りでこれを処理します。Spec-driven development (SDD) では、これを形式的な要件定義ステップに移します。Plan Mode は、あいまいさを減らすという同じゴールを持ちながらも、エージェント自身に直接質問を主導させることで、エージェント中心の開発ペースにより適合させています。

2. リサーチ。エージェントはコードベースをスキャンし、どこに対してやり取りを行う必要があるかを特定します。従来のワークフローでは、これは別個の設計フェーズとして扱われていました。Plan Mode では、これをエージェントの推論プロセスの中に直接折り込みます。

3. プランのドラフト作成。エージェントは、どのような変更を行うか、そしてそれを実装するためのステップを説明する、編集可能なプランファイルを書きます。SDD では、これを固定された仕様として凍結します。アジャイルでは、このドキュメントがしばしば放置されがちです。Plan Mode はプランを「生きた状態」に保ち、新しい情報が現れるたびに、ユーザーとエージェントがそれを洗練できるようにします。

4. 作業の実行。エージェントはステップごとに作業し、進むにつれてタスクにチェックを付けていきます。従来の手法では、計画と実装は分離されていました。Plan Mode はそれらを 1 つのプロセスとして扱い、プランが適応できるようにします。

5. プランの見直し。物事が予定から外れたとき、プランはリセットポイントにもなります。フォローアップのプロンプトで挙動を「つぎはぎ」する代わりに、チームは作業を巻き戻し、プランを洗練し、再実行できます。これにより、意図が明示的に保たれ、実行中のエージェントを途中で操作するよりもクリーンな結果が得られます。

プランは .cursor/plans/ 配下のバージョン管理されたファイルとしてワークスペースに保存されます。コードと並んで配置され、他のプロジェクト成果物と同様に git でトラッキングされます。何がいつ変わったかを確認でき、必要に応じてロールバックできます。

#柔軟な計画のためのプリミティブ

チームごとに、意図の整理のしかたは異なります。形式的な要件に依存するチームもあれば、変化していく設計や段階的なワークフローを使うチームもあります。計画の枠組みは、チームごとのやり方に合わせられる柔軟さを備えているべきです。

この柔軟さは、いま特に重要になっています。足元の前提が急速に変わっているからです。数十年にわたって計画の標準だったのはウォーターフォールでした。その後の二十年を形作ったのはアジャイルです。そしてエージェントインテリジェンスは、さらに短いスパンで進化しています。固定化されたプロセスは、すぐに古くなってしまいます。

そこで私たちは、自由に形を変えられるシンプルなプリミティブを中心にアプローチを設計しました。Agent Skills を使って、チームに合った計画構造を定義できます。エージェントは、その構造に一貫して従います。

あるチームは、より形式的な仕様駆動のワークフローを Agent Skill として定義しています。別のチームは、作業の進行に合わせて進化していく、より軽量なプランを生成する Skill を定義します。プランが固定プロセスではなく Skill によって形作られるため、どちらのアプローチも自然に Plan Mode に収まります。

重要なのは、私たちの計画手法が後方互換である――という点だけではありません (それも事実ですが) 。将来を見据えている、という点です。小さな共通プリミティブの集合の上に構築されたフレームワークであれば、エージェントが、従来の計画スタイルでは想定されていなかった仕事まで担うようになっても、チームは自分たちのやり方を進化させ続ける余地を持ち続けられます。

#今後の展望

エージェントが扱える作業の規模と複雑さは、急速に増しています。Plan Mode はエージェントを念頭に置いたシンプルなプリミティブの上に構築されているため、こうした進歩のペースにも対応できます。

私たちは、extended runs のように 1 つのプロジェクトに長く付き添い、セッションをまたいでコンテキストを保持し、タスクを並列実行したほうが効果的な場面ではサブエージェントを生成できるエージェントをテストしています。複数の開発者が同じセッションに参加し、プランがどのように進化していくかを確認しながら、プロジェクトの進行に合わせてエージェントをガイドできるようになる予定です。私たちの目標は、エージェントが完遂できる作業範囲を広げつつ、プランニングにおいてソフトウェアチームが常に求めてきた核となる要素――明確さ、可視性、そしてユーザーによるコントロール――をそのまま維持することです。