下記を読んでくれ、それだけ。
この記事を読む必要はない。
導入：AIとの開発で直面する「負のループ」
Cursorをはじめとする強力なAIコーディングエージェントを導入したエンジニアが、まず直面する不可避の事象があります。それは、AIに指示を出してバグを修正させればさせるほど、コードの整合性が失われ、システム全体が修復不可能なほど歪んでいく「コンテキストの腐敗」です。「対話さえすれば、AIがよしなに解決してくれる」という期待は、エンジニアリングの観点からは致命的な幻想と言わざるを得ません。AI開発において真に求められるのは、対話のテクニックではなく、ソースコンテキストを厳密にコントロールするための「設計」への回帰です。私たちは今、AIという暴れ馬を御すための「静かなる設計図」の重要性を再認識すべき局面、すなわち技術的特異点に立たされています。
衝撃の事実：LLM開発は「アジャイル」よりも「ウォーターフォール」と相性が良い
現代のソフトウェア開発において「アジャイル」は長らく至高の正義とされてきましたが、LLM（大規模言語モデル）をパートナーとする開発においては、その相性の悪さが露呈します。「走りながら考える」アプローチは、LLMにとって「コンテキスト汚染」を引き起こす最大の要因だからです。LLMの本質は、 「入力に連なるもっともらしい続きを出力する仕組み」 に過ぎません。一度入力（プロンプトや既存のコード）に間違いや曖昧さが混じると、AIはそれを「絶対的な前提」として受け入れ、その歪んだ世界線の中で最適解を生成しようとします。これが、AIが自身の誤りを正解として上書きし続ける 「自己参照的な劣化（Self-referential degradation）」 の正体です。LLMは「一度作ってしまったものを後から修正するのが非常に苦手」という性質を持っています。修正プロンプトを重ねるごとに、コンテキストウィンドウには「負の遺産」が蓄積され、出力精度は加速度的に低下します。つまり、AI開発においては、いかに最初の入力の解像度を高め、確度の高い土台を作るかという「アップフロント・デザイン（事前設計）」、すなわちウォーターフォール的なプラクティスこそが、技術的な必然性として求められているのです。
ベストプラクティス：失敗したら「粘る」のをやめ、「プランからやり直す」
AIエージェントの出力が意図と異なった際、私たちはつい追加のプロンプトで「そこじゃない、こう直して」と食い下がってしまいます。しかし、これはコンテキストにエントロピーを増大させるだけの悪手です。最も効率的なのは、一度変更を物理的に元に戻し、根本となる「プラン」から練り直すことです。Cursorの「Plan Mode」は、以下の厳密なプロセスを辿ります。
- 調査 : コードベースをスキャンし、関連ファイルを特定する
- 質問 : 要件を明確にするため、人間にフィードバックを求める
- プラン作成 : ファイルパスや参照を含む詳細な実装プランを提示する
- 承認 : 人間がその論理を精査し、許可を与えてから実装を開始する
修正しようとするのではなく、プランに立ち戻りましょう。この方が速く、結果もきれいになります。
この際、"Save to workspace" 機能を使い、プランを .cursor/plans/ に保存することを強く推奨します。これは単なるログではなく、将来のエージェントやチームメンバーが迷わないための「設計遺産」となります。また、過去の失敗によるノイズを断ち切るために、新しい会話を開始し、@Past Chats を用いて「必要な文脈だけを抽出して継承する」規律が、AIを迷子にさせないための肝要となります。
コンテキストの層化：認知負荷を抑えるための「構造化」
LLMには「コンテキストウィンドウ」という物理的限界があり、情報が中央付近で埋もれる「Lost in the Middle」現象は避けられません。これを防ぐための知恵が、情報を「層（Layer）」として整理する設計思想です。これは伝統的なエンジニアリングにおける「モジュール化」や「関心の分離」と軌を一にするものです。AIに対する認知負荷を最小化するには、情報を「どの層の、どの粒度の情報を渡すか」という静的な構造として定義し、層化（Layering）しなければなりません。「あらかじめ決まった要求」を整合性を保ったまま細分化し、AIが処理可能な単位に落とし込むプロセスにおいて、アジャイル的な不確実性は排除されるべきノイズでしかありません。
視覚化の力：Mermaid図がAIと人間の「共通言語」になる
「設計」を具体化し、AIとの同期を完璧にする武器がMermaidダイアグラムです。フローチャートやクラス図を用いてロジックを視覚化することは、人間のみならずAIにとっても強力な**「認知の錨（Cognitive Anchor）」**となります。図はデータの流れやコンポーネントの連携を明確にします。Cursorはコードから図、図からコードへの移行をスムーズに行えるため、曖昧な自然言語で対話する代わりに、 「正解の雛形」としての設計図 をAIに与えることが可能になります。ここでは、C4モデルに倣ったアプローチを推奨します。
- 低レベル（コンポーネント単位）の図から始める
- それを要約・統合し、中レベル、高レベルへと抽象度を積み上げる
このように「全体から細部へ」と情報の流動性を制御するプロセスは、まさにウォーターフォールの基本原則そのものです。
エージェントを律する：RulesとSkillsによる「静的・動的」な統制
AIエージェントを自律的に動かすには、場当たり的な指示ではなく、システムとしての統制が必要です。
Rules（静的コンテキスト）
.cursor/rules/ に配置されるルールは、すべての会話で参照される「プロジェクトの憲法」です。
- 本質への収斂 : 実行コマンド、標準パターン、正典（canonical）となるサンプルコードへの参照に絞り込みます。
- 過度な最適化の排除 : 最初から網羅性を求めず、エージェントが「同じミスを繰り返したとき」にのみ、規律として追加します。
Skills（動的コンテキスト）
特定のワークフローやドメイン知識をパッケージ化したSkillsは、現在のコンテキストウィンドウをクリーンに保つための鍵です。常にメモリを消費するRulesとは異なり、Skillsはエージェントが必要と判断した際のみ「オンデマンドでロード」されます。この動的な機能拡張により、大規模な開発においてもAIの処理精度を維持することが可能になります。
結論：エンジニアの役割は「コーダー」から「アーキテクト」へ
AI時代の開発において、エンジニアに求められる能力の重心は「コードを書くこと」から「美しく層化された設計図を描くこと」へと明確にシフトしました。私たちは、AIという強力な実行部隊に対し、正確な地図を与えるアーキテクトにならなければなりません。「何を作るか」が設計レベルで決まっていない状態でAIを駆動させても、コンテキストの泥沼に沈み、自己参照的に自壊するだけです。設計をサボれば、最新のAIを使ってもゴミしか生まれないという現実を、私たちは直視せざるを得ません。「アジャイル」という言葉を「仕様を固定しなくていい免罪符」にしている限り、AIの真の恩恵を享受することは不可能です。あなたは今日、AIに渡すための「美しく層化された設計図」を、その手に描けていますか？