#Cursor #AI開発 #生産性向上 #Nextjs #エンジニアの本音
「これ、本当に会社として導入するんですか？」
春の足音が聞こえ始めた頃、新規プロジェクトの立ち上げミーティングで私が「Cursorのチーム標準導入」を提案したとき、
会議室（とZoomの画面越し）に流れた張り詰めた空気は、今でも忘れられません。
第1回で、私はCursorという「劇薬」に魅了され、個人として圧倒的な開発体験を味わいました。しかし、それを「組織の武器」に
するためのステップに足を踏み入れた途端、私は強固な「人間の壁」、そして生成AI特有の「技術的な限界」という2つの大きな壁に
ぶつかることになったのです。
押し寄せるリアルな懐疑論と、冷ややかな空気 …最初に立ちはだかったのは、チームの防衛本能でした。
特に、長年コードの品質と堅牢性を支えてきたシニアエンジニアや、セキュリティーガバナンスを担当するメンバーからの指摘は、
極めて真っ当であり、それゆえに重いものでした。
「AIが自動生成したコードなんて、レビューのコストが増えるだけじゃないか？」
「もしコードベースにセキュリティー脆弱性が紛れ込んだら、誰が責任を取るんだ？」
「そもそも、弊社の機密コードや顧客データがAIの学習に使われるリスクはないのか？」
「とにかく凄いから使ってみてくれ」という私の熱量だけでは、組織は1ミリも動きません。
私はすぐに商用プラン（Business/Enterprise）の仕様書をひっくり返し、データがモデルの学習に使用されない設定（Opt-out）が
可能であることを証明する社内資料を作りました。
しかし、本当に難しかったのはセキュリティーの書類を通すことではなく、メンバーの「心理的ハードル」を溶かすことでした。
「自分の聖域であるソースコードを、得体の知れないAIにいじられたくない」――言語化されずとも、エンジニアとしてのプライドが
混ざった冷ややかな空気が、チームの根底には確かにあったのです。
チームが変わった「あの15分間」のハンズオン
風向きが変わったのは、私が主催した小さなチーム内ハンズオンでした。
理屈を並べるのをやめ、実際にCursorを動かす画面をライブシェアで見せることにしたのです。
ターゲットにしたのは、全員が「面倒くさいけれどやらなければならない」と辟易していた、既存の巨大なレガシーコードに対する
レパトリ（リファクタリング）と型定義の付与、そして単体テスト（Unit Test）の大量量産でした。
「じゃあ、この複雑に入り組んだ古いロジックのファイル（約800行）を、Cursorを使って今から5分でTypeScriptに完全移行して、
テストコードまで書きます」
私が画面上で Cmd + L を叩き、@File_A を元に、ロジックを純粋関数に切り出して型安全にし、Jestのテストケースをエッジケース含
めて10パターン作ってとプロンプトを打ち込んだ瞬間、エディタが猛烈なスピードで動き出しました。
人間が書けば、依存関係を紐解き、型の矛盾と格闘し、テストのボイラープレートを書くのに丸一日は潰れるタスクです。
それが、見る間にクリーンなコードへと再構成され、カバレッジを満たしたテストコードが生成されていく。
「……マジか」
Zoomのミュートの向こうから、漏れ聞こえた声。さっきまで腕を組んで画面を眺めていたシニアエンジニアの目が、明らかに
変わりました。
「あ、これ、自分が本当にやりたい本質的な設計に集中するために、泥臭い作業をすべて肩代わりしてくれるやつだ」と、全員が
直感的に理解した瞬間でした。
この日を境に、チームの Cursor 導入は一気に加速しました。
「トークンの壁」という絶望と、現場のトラブルシューティング
しかし、本当の戦いは全員がCursorを本格的に使い始めてから始まりました。プロジェクトが進行し、機能が追加され、コード
ベースが数万行の規模に膨れ上がってきたとき、私たちは「生成AI特有の技術的限界」――すなわちトークンの壁（コンテキスト
ウィンドウの限界）という、冷酷な現実に直面したのです。
ある日、メンバーの一人が頭を抱えていました。
「昨日まで完璧に動いていた認証周りのコンポーネントが、AIに新しい修正を依頼した途端、めちゃくちゃに破壊されました…」
原因は明白でした。コードベースが大きくなりすぎたため、AIが一度に把握できる文脈（コンテキスト）を超えてしまったのです。
AIは、数ファイル前に定義した「共通のインターフェース」や「グローバルな状態管理のルール」を忘れ始め、勝手に新しい別の重
複コードを出力したり、さっき直したはずの致命的なバグを先祖返り（再発）させたりし始めました。
「AIを信じすぎて、コード全体がじわじわと腐り始めている」
それは、個人で使っていたときには見えなかった、組織開発ならではの泥臭いトラブルシューティングの日々の始まりでした。
私たちは、エディタに丸投げするのをやめ、AIのコンテキストをいかに人間がコントロールするかという「泥臭い運用ルール」を
構築せざるを得なくなりました。
.cursorrules ファイルを徹底的に書き込み、プロジェクトのディレクトリ構造やコーディング規約をAIに厳格に叩き込む。
プロンプトを投げる際は、関係のないファイルをコンテキストから外し、ピンポイントで参照（@filename）を絞り込む。
一気に大きな機能を実装させず、PR（プルリクエスト）が100行未満に収まるような粒度で、小刻みにAIと対話する。
私たちは、AIを「全自動の魔法」ではなく、「優秀だが目を離すとすぐに仕様を忘れる新卒エンジニア」として飼い慣らす術を、
文字通り痛い目を見ながら学んでいきました。
こうして、私たちはコンテキストのコントロールという新たなメタ・スキルを身につけ、トークンの壁を泥臭く乗り越えていきま
した。チーム全体の生産性は確実に数倍へと跳ね上がり、Cursorはなくてはならない「標準の武器」になったのです。
しかし、そんな私たちの前に、さらなる異次元の進化を遂げた「次なる怪物」が現れます。
次回へつづく・・
------------------------------------
■次回予告：次回、【連載③】「Claude Code」に月200ドルを即決。実装を任せる日 へ続く。