【AI活用】AIにコードを書かせて半年｜正直、効いたこと・効かなかったこと

「開発スピードが何倍に！」みたいな話も見かけますが、正直そこまでの実感はありません。 かといって「使えない」でもなくて、効くところと効かないところが、わりとはっきり分かれたというのが半年使ってみた感想です。

導入を検討しているチームの参考になればと思うので、盛らずに書いていきますね。

まず、どんな開発で使っているか

うちの開発は、お客様の業務システム（受注・在庫・出荷まわりの基幹系）と、自社サービスが中心です。 長く使われてきた既存コードに手を入れる仕事が多くて、ゼロから新規サービスを作る場面ばかりではありません。

この「既存コードが主役」という前提、実は AI の向き不向きにけっこう影響します。 新規プロジェクトで試したときと感触が違うので、そこは差し引いて読んでください。

使っているのは、エディタ内で補完してくれるタイプと、リポジトリ全体を読んで複数ファイルを勝手に編集してくれるエージェントタイプの両方。 この記事で主に書くのは後者のほうです。

効いた使い方 4つ

① 既存コードを読ませる・影響範囲を調べさせる

これが一番はっきり効きました。「この項目を追加したら、どのファイルに影響する？」「この関数、どこから呼ばれてる？」を投げると、 リポジトリ全体から拾ってきてくれます。grep を何度も打つより速いし、見落としも減りました。

ただし、返ってきた答えは結論ではなく出発点として扱うのが大事です。 「この3ファイルです」と言われたら、その3ファイルは自分で開いて確認する。 それでも白紙から探すよりは、ぜんぜん速いです。

② プロジェクトの「ルール」をファイルに書いておく

毎回同じ注意をプロンプトに書くの、面倒じゃないですか？ 実は多くのエージェントは、リポジトリ直下に置いた規約ファイル（CLAUDE.md、.cursorrules、AGENTS.md など、ツールで名前は違います）を勝手に読んでくれます。

ここに書くのは仕様ではなく、守ってほしい制約です。うちだとこんな感じ。

# プロジェクト概要
社内の受注管理システム。PHP 8.2 / Laravel / MySQL。

# 守ること
- 認証情報・接続情報は絶対にコミットしない
- DB スキーマの変更は必ずマイグレーションで行う（直接 ALTER しない）
- 金額の計算に浮動小数点数を使わない（decimal 型で扱う）
- 既存のコーディング規約に合わせる。新しいライブラリの追加は事前に相談する

# やらないこと
- 指示していないリファクタリングを同じ変更に混ぜない

③ 単純だけど量がある作業

命名の統一、同じ構造の画面をもう1本、テストコードの雛形、エラーメッセージの文言そろえ。 このへんは「機械的なのに量がある」作業で、人間がやると疲れる割に価値が出にくいところです。 任せて差分をレビューするほうが、速いし品質も安定しました。

④ 人にレビューを頼む前の下見

レビュー依頼を出す前に、自分の差分を読ませて指摘させています。 Null チェック漏れ、例外処理の抜け、テストケースの不足。 「読めば分かるけど見落としがち」なやつは、そこそこ拾ってくれます。

おかげで、レビュワーの時間を設計判断みたいな人にしか見られない部分に使えるようになりました。

効かなかった使い方 4つ

① 仕様が決まってないものを「いい感じに」

これは期待しちゃダメでした。ふわっとした状態で投げると、それらしく動くものは出てきます。 でも業務要件から見ると的外れで、結局それを読んで直す時間のほうが長くなる。

仕様を決めるのは人間の仕事、という線引きは今のところ動いていません。 むしろ、AI に渡せる粒度まで要件を言葉にする過程で「あれ、ここ決まってなくない？」が見つかることのほうが多くて、 それはそれで有益だったりします。

② 大きい差分を一気に作らせる

「この機能を丸ごと実装して」と頼むと、数十ファイルにまたがる差分が返ってきます。 動いているように見えても、レビューが現実的に無理な量です。 そしてレビューできない差分は、だいたい後で問題になります。

今は「1回で作る差分は、人が15分以内にレビューできる量まで」と決めています。 遠回りに見えて、トータルではこっちのほうが速いです。

③ 業務ドメインの判断

うちがよく関わる鉄鋼業だと、「この場合の端数はどう扱う？」「この伝票はいつ確定扱い？」みたいな、 コードにもマニュアルにも書かれていない現場のルールが必ずあります。

こういうのは、お客様に聞かないと誰にも分かりません。AI はそれっぽい答えを返してきますが、 正解は現場にしかないんですよね。

④ 出力をそのまま信じる

ライブラリのバージョンが古い前提のコードとか、存在しないメソッドとか、今でも普通に混ざります。 更新が速いフレームワークほど起きやすい印象です。 動かして確認する、公式ドキュメントで裏を取る。この手順は省けません。

チームで決めたルール

導入するときに決めた、シンプルなルールを置いておきます。

1. 生成されたコードも、コミットした人の責任。「AI が書いたので分かりません」はナシ、と最初に明文化しました
2. レビューは飛ばさない。むしろ量が増えるぶん、レビューの重要度は上がります
3. 差分は小さく。目安は15分でレビューできる量
4. 規約ファイルを育てる。同じ指摘を2回したら、プロンプトじゃなくて規約ファイルに書く
5. テストがある場所から使う。自動テストが整っている領域ほど、安心して任せられます

お客様の情報をどう扱うか

受託開発だと、ここが技術以前の問題になります。うちで徹底しているのはこのあたりです。

• 契約・NDA で、外部サービスにデータを送っていい範囲を必ず先に確認する
• 本番データ（取引先名、単価、個人情報）はそのまま渡さない。再現にはマスクしたデータを使う
• 認証情報をリポジトリに置かない。.gitignore は変更のたびに確認する
• 使うサービスの学習利用ポリシーと保存期間を、導入前にチームで確認する

「便利だから使う」ではなく、「この案件のこの範囲なら使っていい」を先に決める。 面倒に見えますが、これをやっておいたほうが結果的に導入がスムーズでした。

まとめ

半年使ってみて、こんな感じでした。

• 効いた：調査、定型作業、レビュー前の下見
• 思ったほどでもなかった：仕様が固まっていない領域、業務ドメインの判断

ざっくり言うと、「何を作るべきか分かっている状態」を作れているチームほど恩恵が大きいということかなと。 逆に、そこが曖昧なままだと AI を入れても曖昧なものが速く出てくるだけでした。

そしてこの線引き、たぶん来年にはまた変わります。半年前に効かなかったことが、次のモデルでは普通にできるかもしれない。 だからこそ、試して、効いたものだけ運用に入れる、というやり方を続けています。