AIエージェント開発の最前線『Cursor』が証明した事実 —— 優秀なAIも『指示』が悪ければただの無能になる

「AIエージェントを使えば、開発が爆速になる」
「自然言語で指示するだけで、アプリが完成する」

そんな甘い言葉に誘われて、今、多くのエンジニアが『Cursor』などのAIエディタを導入しています。特に、複数のファイルを読み込んで実装を行ってくれる「Composer」機能などは、魔法のようなツールに見えることでしょう。

しかし、実際に現場で使い倒している筆者が直面した現実は、もっとシビアなものでした。

それは、「使う側に『設計図（要件）』がない限り、AIはゴミしか生み出さない」という事実です。

最強のAIエージェントと言われるCursorであっても、指示が曖昧なら、驚くほど無能な動きをします。逆に言えば、Cursorがうまく動かない時、それはAIの性能不足ではなく、私たち人間の「言語化能力」や「要件定義力」の不足が露呈しているに過ぎないのです。

本記事では、AI開発の最前線で見えてきた「AI時代に本当に必要なスキル＝業務プロセス構造化」について、Cursorの実例を交えて解説します。

AIは「察して」くれない

Cursor、特にそのComposer機能は非常に優秀です。プロジェクト内の複数のコードを読み込み、文脈を理解しようと努めます。しかし、彼らには人間のような「空気を読む」「よしなに計らう」という能力は一切ありません。

曖昧な指示が引き起こす悲劇

私たちは普段、人間相手に以下のようなコミュニケーションを取りがちです。

• 「この辺のロジック、あの画面と同じ感じに直しておいて」
• 「ちょっと使いにくいから、いい感じにリファクタリングして」
• 「エラーが出てるから直して」

人間同士であれば、過去の経緯や暗黙の了解（コンテキスト）を共有しているため、これでも通じるでしょう。しかし、AIに対してこれをやると大惨事が起きます。

• 影響範囲の誤認：「この辺」の定義が曖昧なため、関係ない共通関数まで書き換えて、他の画面を壊す。
• 仕様の暴走：「いい感じ」を勝手に解釈し、不要なライブラリを追加したり、謎のデザイン変更を行ったりする。
• デグレの連鎖：エラーそのものは消えたが、本来のビジネスロジックまで消滅している。

筆者も導入当初は、「AIなんだから、これくらい予測してくれるだろう」と高を括っていました。しかし、その期待は裏切られ続けました。AIは、指示者の脳内にある「曖昧さ」を、忠実にコードとして出力していただけだったのです。

コード生成で露呈する「言語化能力」の欠如

なぜAIは失敗するのでしょうか。それは、プロンプトの書き方が悪いのではありません。「何を作りたいか（What）」の定義が、構造化されていないからです。

DXの失敗と同じ構造

これは、現在多くの企業が直面している「DXの失敗」と全く同じ構造です。

「AIを導入すれば業務が効率化する」と信じて導入しても、現場の業務プロセス自体が属人的でグチャグチャ（スパゲッティ状態）であれば、AIは何を処理していいかわかりません。

エンジニアがコードを書く前に設計するように、ビジネスパーソンも業務を「原子分解」し、構造化してAIに渡す必要があります。Cursorを使っていると、この「要件定義スキル」の有無が、生産性に直結することを痛感させられます。

AIは「優秀な部下」ですが、「指示待ち人間」の極致でもあります。彼らを動かすためには、私たち自身が「作業者」の思考を捨て、「設計者（Planner）」としての思考に切り替えなければならないのです。

AIを御するための「業務原子分解」5ステップ

では、具体的にどうすればCursor（およびAIエージェント）を使いこなせるのでしょうか。筆者が実践している、タスクをAIに渡す前の「業務原子分解」の5ステップを紹介します。

このステップを踏むだけで、Cursorの精度は劇的に向上します。これはプログラミングに限らず、あらゆるAI活用の場面で応用可能です。

1. コンテキストの範囲指定（Scope Definition）

AIに「全部見て」と言ってはいけません。ノイズが増えるだけです。

• 対象ファイルの限定: @src/components/Button.tsx のように、修正対象のファイルをピンポイントで指定します。
• 参照ファイルの限定: 仕様の参考にするファイルがあれば、それも明示的に含めます。
• 無関係な情報の遮断: 迷わせないために、関係ないファイルはコンテキストに入れない勇気を持ちます。

2. ゴール（成果物）の定義（Output Definition）

「何をしてほしいか」ではなく「何が欲しいか」を定義します。

• 形式の指定: 「修正後のコード全体」なのか、「差分のみ」なのか、「修正案のリスト」なのか。
• 完了条件: 「TypeScriptの型エラーが消えること」「テストが通ること」など、成功の定義を明確にします。
• 禁止事項: 「既存のCSSは変更しないこと」「外部ライブラリは追加しないこと」など、やってはいけないことを先に伝えます。

3. 入力データの構造化（Input Structure）

指示出し自体をマークダウンなどで構造化します。

• 自然言語でダラダラ書かない: 箇条書きや見出しを使って整理します。
• パラメータの明示: 変数名や具体的な値が決まっている場合は、それを明記します。
• 擬似コードの活用: 複雑なロジックの場合、日本語のコメントや擬似コードで処理の流れを書いてから、「これを実装して」と渡します。

4. 処理プロセスの分割（Process Decomposition）

「A機能を作って」という大きな塊（チャンク）で投げると失敗します。

• Step 1: まずデータベースの定義を変更する。
• Step 2: 次にAPIのエンドポイントを作成する。
• Step 3: 最後にフロントエンドをつなぎこむ。

このように、1回のプロンプトで完結するサイズまでタスクを分解し、順次実行させます。これを「Chain of Thought（思考の連鎖）」を人間側がガイドしてやるイメージです。

5. レビューと修正（Judge Role）

AIが出力したものを鵜呑みにせず、必ず人間が「検品」します。

• 動作確認: 書かれたコードが本当に動くか確認します。
• ロジック確認: 意図しない仕様変更が含まれていないかチェックします。
• フィードバック: 間違いがあれば、「ダメだ」と切り捨てるのではなく、「〇〇の条件が漏れている」と具体的に指摘して修正させます。このフィードバックループこそが、AIを「教育」する過程になります。