Cursor × AI駆動開発 3ステップ実践シリーズ
- AI駆動開発で生産性を高める3つの段階
- Cursorで実現する Vibe Coding 〜基本フロー編〜
- Cursorで実現する Vibe Coding 〜10個の実践Tips編〜
- Cursorで実現するContext Engineering 〜チャット運用ルール編〜 ← 今ココ
- Cursorで実現する Agentic Workflow（関連記事を順次公開予定）
1. はじめに
Cursorを使った開発をしていると、
- 少し前に指摘した内容をエージェントがすぐに忘れてしまう
- 途中から出力の質が不安定になる
- 同じミスを何度も繰り返す
という声をよく耳にします。
これらの問題はモデルの性能というより、チャットに不要なコンテキストが混在していたり、会話ログが長大化することによる出力品質の劣化が原因で起きているケースがほとんどです。
こうした問題を防ぐために必要なのが Context Engineering であり、その中核にあるのが チャットの利用方法にあると考えています。そこで本記事では、Cursorを使った開発における、 コンテキスト品質を守るためのチャットの使い方 に焦点を当てて解説します。
2. Context Engineeringにおける「チャット」の位置づけ
Context Engineeringの前提として、Cursorでは チャット履歴そのものが入力コンテキスト になる、という点を押さえておく必要があります。AIの出力品質は、どんな会話ログを前提としているかで大きく変わってしまうということです。
そのため、チャットは単なる対話手段ではなく、成果物の品質を左右する設計対象です。
情報を多く渡すのではなく、そのタスクに必要な前提だけを壊さずに保つことが重要事項となります。
3. 3つのチャット運用原則
原則1： 1つのチャットに与える責務は1つまでにする
そのチャットで何を達成したいのか、目的を1つに絞るという考え方です。
責務を1つに限定することで目的が明確化され、不要なコンテキストが混在しづらくなります。開発者自身もコンテキスト選定やプロンプト入力に迷いが生じづらくなるため、目的思考を持って作業を進めることが可能となります。
原則2： チャット内で付与するコンテキスト量を必要最小限にする
ここでのポイントは、エージェントがタスクを遂行するために必要な情報のみをコンテキストとして付与するという点にあります。余計な情報を削ぎ落とすことで、エージェントが注目すべき情報が明確化され、開発者の意図から外れた提案・実装を削減することが可能となります。
原則3： チャット履歴をトレース可能なものにする
トレース可能とは、エージェントとのチャットでのやり取りの中で「どんな前提で、どんな議論を経て、その結論に至ったか」をあとから追える状態を指します。
この状態を実現することで、開発者の意図した出力をエージェントから得られなかった場合に、その原因を特定することが容易になります。手戻りの原因を「プロンプトが下手だったから」と曖昧なもので終わらせず、入力設計の問題として見直せるようになることに価値があります。
4. チャット運用アンチパターン集
前述の原則を破るとどのような問題が発生し得るのか、日々のチャット運用において原則をどのように実践に落とし込んでいくのかを、7つのアンチパターンと共に見ていきます。
①画面実装時に、デザインとロジックを一括で実装させてしまう
何が起きるか/なぜ起きるか
デザインとロジックに関するコンテキストを同一プロンプト内で付与して実装させてしまうと、必要コンテキストが膨大となり、見た目が崩れる・ロジックが抜けるなど、中途半端な実装になりやすくなります。これらは原則1、2に違反しています。
対策
デザイン専用チャットとロジック専用チャットを分割することを推奨します。先にスタイルデータ等をコンテキストにviewのみを完成させ、その後にロジック部分のコンテキストのみを別チャットで付与して実装させることでコンテキスト最適化を図ります。
②実装時にコンテキストとして付与した設計書のサイズが膨大すぎる
何が起きるか/なぜ起きるか
500行を超えるような膨大な量の仕様書・詳細設計書を丸ごとコンテキストとして付与した場合、本来そのタスクに必要のないコンテキストが含まれたり、最も重要度が高い部分のコンテキストを把握できない状態でエージェントが実装を進めるため、開発者の意図とは異なる成果物が出力されてしまいます。これらは原則2に違反しています。
対策
そのタスクで本当に参照すべき箇所を抜粋・要約したmdを別途用意し、それをコンテキストとして渡します。抜粋したい部分を範囲選択してチャット欄にドラッグ＆ドロップすることで、以下のように行単位でのコンテキスト指定も可能です↓
③Cursorと詳細設計を詰める際に、本筋と関係のない質問をしてしまう
何が起きるか/なぜ起きるか
私のような若手エンジニアだと、Cursorが提案してきた実装案を理解するために、技術的な質問をチャット上で投げたくなる開発者は多いと思います。しかしながら、同一チャット上でこれを実施すると、質問部分のチャット履歴は全てノイズコンテキストになり、出力品質は低下してしまいます。これらは原則1、3に違反しています。
対策
定めた目的を遂行するチャットを本流チャットとし、その出力に対して別途質問・検討をしたい場合はチャットを複製する/別チャットを立ち上げることを推奨します。
以下の複製機能（duplicate caht）を利用すれば、本流チャットのコンテキストをそのまま再利用できるのでオススメです。
④チャット履歴を振り返っても、何の作業をしていたか把握できない
何が起きるか/なぜ起きるか
実装計画・実装・デバッグといった異なるフェーズのやり取りを1つのチャットに積み上げてしまうと、どこで設計判断をしていたのか・各作業で何のコンテキストを付与していたのか等を後から把握するのに大きな時間がかかるため、開発者自身が過去の経緯をトレースできなくなります。これらは原則1、3に違反しています。
対策
チャット利用時は必ず「このチャットで何をするのか」という目的を1つだけ設定し、その内容に沿ってチャット名をReNameすることを推奨します。フェーズが変わったタイミングで新しいチャットを立てることで、チャット履歴がトレース可能なものとなります。
なお、ReName方法は以下のようにチャット名をダブルクリックすれば可能です。
⑤開発者がプロンプト内容を理解しないままCursorに作業させてしまう
何が起きるか/なぜ起きるか
Cursorが提案した設計案や修正方針を十分に理解しないまま、「よく分からないが正しそうだから」とプロンプトに載せて実装させると、動きはするけど品質保証ができない・PRレビュー時にコードの意図を説明できないといった理解負債が発生します。これらは原則3に違反しています。
対策
理解が曖昧な内容については、本流チャットとは別の「質問・壁打ち用チャット」を用意し、まずそこで自分が納得できるまで質問・確認を行うことを推奨します。必要に応じて公式リファレンス等を自ら参照しにいく必要もあると思っています。自分が理解している内容のみをCursorに指示することで、理解負債の解消・コード品質の向上が期待できます。
⑥同一チャット内のスレッドが長すぎる
何が起きるか/なぜ起きるか
1つのチャットあたりのスレッドが長くなると、初期に付与していた前提条件・方針をエージェントが忘れ、出力の一貫性が落ちてしまいます。たとえ１つの作業しかさせていなくても、長すぎるスレッドはこのような事象を発生させます。これらは原則2に違反しています。
対策
詳細設計・実装・UT・バグ改修など、フェーズの区切りごとに新しいチャットを立ち上げることを推奨します。
以下のように、チャットのコンテキスト使用率の閲覧も可能ですので、これが100%を超えないことを一つの基準にしてもいいかもしれません。
⑦軽微な修正を何度も小出しに指示してしまう
何が起きるか/なぜ起きるか
「このラベルだけ文言を変えて」「やっぱりこの条件も追加で」といった軽微な修正を、その都度思いつきで小出しに指示してしまうと、⑥で説明したスレッドを長くする大きな要因となります。こちらも原則2に違反しています。
対策
修正が必要な箇所を一度洗い出し、箇条書きで整理してから1回のプロンプトでまとめて指示することを推奨します。また、インライン編集をすることで本流チャットのコンテキスト汚染を防ぐことも可能です。インライン機能に関してはこちらの記事を参照してください。
5. まとめ
これまで見てきたとおり、CursorをはじめとしたAIツールの利用を前提とするAI駆動開発において、チャットの利用方法はエージェントの出力品質を大きく左右する要素です。
本記事で紹介した3つの原則を守ることで、出力の安定性と再現性が上がり、理解負債や手戻りを大きく減らすことができると考えています。まずは新しくチャットを立てるときに「このスレッドで何を達成したいのか？」を一言で言語化するところから、Context Engineeringを始めてみてもらえればと思います。
本記事が、AI駆動開発をよりうまく実践するうえで少しでも参考になれば嬉しく思います！