【連載】第2回～エンジニアの本音：「Cursorを標準ツールに」懐疑的だった開発チームが変わった瞬間と、見えてきた新しい壁

 #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ドルを即決。実装を任せる日 へ続く。