はじめに
私は、2025年9月にアイスリーデザインへ入社しました。
入社前はバックエンド開発が中心でしたが、現在はフロントエンドの開発にも携わり、日々の実装や不具合対応の中で「立ち上がりの速さ」や「変更の影響範囲の読み方」がこれまで以上に重要だと感じています。
そんな環境の変化もあり、入社してからはAIを積極的に活用してきました。
特にAIコードエディタ Cursor は、調査・実装・レビューのスピードを一段階引き上げてくれる一方で、使い方を誤ると差分が膨らんだり、理解が浅いまま進んでしまったりと、AI駆動開発（AIDD）ならではの難しさや、エンジニアとしての振る舞い方の変化も見えてきました。
この記事では、初心者の立場から、3ヶ月間の試行錯誤で分かった「AIに依存しない向き合い方」を整理して共有します。
1. 既存情報の整理と「理解の落とし穴」
新しいプロジェクトに参画する際、これまでは既存のコードや仕様を読み解くために数日を要していました。
特に不慣れな言語やフレームワークの場合、その学習コストも無視できません。
こうした場面でAIに頼ると、以下のような情報を即座に構造化してくれます。
- 概要把握: プロジェクトのアーキテクチャとディレクトリ構成の解説
- 依存関係の可視化: 特定の機能がどのファイルに依存し、どう実装されているかのリストアップ
- 技術スタックの解説: プロジェクト特有の実装パターン（書き方の癖）の抽出
これらを「初期のガイド」として手元に置くだけで、立ち上がりのスピードは格段に上がります。
ただし注意点もあります。AIの要約は非常に「もっともらしく」整っているため、それだけでシステム全体を把握したつもりになるという錯覚が起こります。
しかし、細かい仕様や特有の挙動については、AIの出力が不十分であったり、微妙にニュアンスが異なったりすることも珍しくありません。
「AIのまとめはあくまで仮説」と心得ることが大切です。
それを手がかりに、必ず自分の目でソースコードを追い、最終的な理解を固めるプロセスを省いてはいけないと感じました。
2. コード生成による「複雑化」をどう制御するか
AIに課題を伝えると、すぐに修正案や実装まで出してくれます。便利な反面、頼りすぎると「継ぎ足し建築」のような問題が発生します。
発生しがちな問題
- 差分の見落とし：変更範囲が広すぎると、意図しない破壊的変更に気づきにくい。
- デッドコードの蓄積：既存ロジックをリファクタリングせず、新しい処理を上書き・継ぎ足すようなコードが生成されやすく、結果としてコードベースが複雑化（スパゲッティ化）する。
これらを防ぐために、私は以下の2つの対策を講じています。
1. 手順による対策：急がば回れの「3ステップ」
- まずAIに現在の状況を整理させる。
- 対応方針（設計）をドキュメント形式で出力させ、人間が内容をレビューする。
- 合意した方針に基づき、小さな単位で少しずつ実装を進める。
一見遠回りに見えますが、実装内容がコントロールできるため、不具合が起きた際も原因の特定が容易になります。
2. RULE.md による自動制御
Cursorには RULE.md という、AIの振る舞いをプロジェクト単位で規定できる設定ファイルがあります。
ここに「勝手にコードを書き換えない」「まず提案から始める」といったルールを明文化しておくことで、AIの暴走を防ぐことができます。
結果として、自分の開発スタイルに最適化されたパートナーへと育てることができます。
実践から得た教訓：AIのコード生成は「一発回答」ではなく、「小さく複数回」のほうが品質が上がる
3. AIが「迷走」した時の引き際を知る
単純なエラーであればAIは即座に修正してくれます。ですが、複雑なロジックや構造そのものに原因があるケースでは、途中から限界が見えてくることがあります。
AIが「迷走」するパターン
特にUI関連（React Native等）の不具合で顕著ですが、ログを渡してもAIが「原因がわかりました。修正します」と自信満々に宣言しながら、実際には似たような修正を繰り返したり、変更が増えて逆に状況を悪化させたりすることがあります。
これは、AIが「表面的なエラー解消」のためにパッチを当てようとする一方で、背景にある「根本的な設計の矛盾」まで踏み込めないことが原因です。
だからこそ、AIを過信しすぎないことが重要です。何度かやり取りして解決しない場合は、一旦チャットを閉じ、こちらでログを仕込んでコードを深く読み解く。
根本原因を特定してから「ここが悪いから、こう直して」とピンポイントでAIに指示を出すのが、最短の解決策になることが多いと痛感しました。
実践から得た教訓：3回やり取りしてダメなら自力に切り替える
4. コードレビューに多様な視点を持つ
AIは「今までの会話の流れ」を踏まえて提案できるのが強みです。一方で、提案がどうしても現在の実装方法の延長線上に寄りやすいという弱点も感じました。
実例：SDK導入時の判断
React NativeでPodfileにコードを注入する処理を実装した際、AIは既存の複雑な検索ロジックをベースに修正案を出してきました。
しかし、実際には Expoの mergeContents という標準機能を使えば、コードを大幅削減できるケースがあります。
複数の視点を取り入れる工夫
より良い実装方法を見極めるために、以下の工夫が有効です。
- AIモデルを切り替える: 異なるモデルに意見を聞く。
- コンテキストのリセット: 新しいチャットを立ち上げ、ゼロベースで改善案を提案させる。
- Agent機能の活用: 客観的な視点から、現在の実装の懸念点を洗い出させる。
最終的なベストを判断するのは、あくまで自分自身であるという意識が欠かせません。
AIの提案は強力な材料になりますが、採用する責任まで委ねるのは危険です。
ここを手放さないことが、結果的に品質とスピードを担保できると感じています。
実践から得た教訓：レビューは“別視点の投入”で初めて強くなる
おわりに：エンジニアの「判断力」の価値
「AIがエンジニアの仕事を奪う」という議論もありますが、3ヶ月使ってみて確信したのは、「エンジニアの判断力の重要性はむしろ高まっている」ということです。
AIは強力な加速装置ですが、ハンドルを握り、行き先を決めるのは人間です。
AIという強力なパートナーを正しく使いこなせるかどうかは、使う側の知識と、出力されたコードの良し悪しを見極める判断力にかかっています。
ツールに使われるのではなく、主体性を持って利用し続けること。
そのために、私たちエンジニアも技術の根底にある原理原則を学び続ける歩みを止めてはいけないのだと、改めて実感しています。
付録：私が運用している RULE.md（共通設定）
参考までに、AIの挙動を安定させるために私が定義しているルールの一部を紹介します。
—
globs:
alwaysApply: true
—
## 共通ルール
### 1. コードの整合性とスタイル
既存パターンの尊重: 各サービスの既存コードスタイルやアーキテクチャを厳守すること。
明解なロジック: メンテナンス性を高めるため、暗黙的なロジックを避け、明示的なコードを優先すること。
### 2. ドキュメントとコメント
「なぜ」を記述する: コメントは「何をしているか」ではなく、複雑なロジックの「意図や理由」を説明する場合のみ付与すること。
言語設定: すべての指示・コメントは日本語で行うこと。
### 3. ワークフローとコミュニケーション
まず提案から: 実装を開始する前に、解決案を提示し人間の承認を得ること。
明示的な実行: 指示が "do" や「実行して」で始まらない限り、勝手にコードを書き換えないこと。
思考のプロセスを表示: 回答の前に、どのようなステップで解決しようとしているかを簡潔に述べること。
実践から得た教訓：AIのまとめは「入り口」に過ぎない