はじめに
2025年は、生成AIを「便利な補助ツール」としてではなく、開発プロセスの中にどう組み込むかを考え続けた年でした。
最初は、AIに依頼するプロンプトをうまく書けば十分だと思っていました。ところが、実務に近いタスクで使うほど、問題はプロンプト単体では閉じないことが見えてきました。
- 頼んでいない変更まで広がる
- テストが後回しになる
- 仕様の前提が会話の途中で揺れる
- セッションが切れると、どこまで進んだのか分からなくなる
- レビューするときに、人間が差分の意図を追い直す必要がある
AIの能力が足りないというより、人間側のワークフローがAIとの協働を前提に設計されていなかったのだと思います。
この記事では、2025年にAIコーディングエージェントを使いながら考えたことを、個人開発とチーム開発の間にある運用の話として振り返ります。
何を試したか
自分が試したのは、主にWebアプリケーション開発や記事管理リポジトリのように、既存ファイルを読みながら小さな変更を積み上げるタスクです。AIには、実装そのものだけでなく、実装前後の整理も任せました。
- 仕様のたたき台を作る
- 実装前にテストケースを洗い出す
- 既存コードを読ませて変更計画を作る
- 小さな実装をAIに任せる
- 実装後のセルフレビューをさせる
- PRレビュー前に観点漏れを確認する
どれも単体では便利でした。
ただ、2025年の途中までは「AIが速く書けること」に意識が寄りすぎていました。実際に困ったのは実装速度ではなく、あとから差分を読んだときに「なぜこの変更が入ったのか」「どこまでが今回の依頼だったのか」を説明し直す時間でした。
ただし、便利さに任せて使うと、だんだん人間の確認コストが増えていきます。AIが大量の差分を一気に作れるようになるほど、その差分を人間が理解し直す負担も増えるからです。
そこで、途中から意識が変わりました。
「AIにどこまで任せられるか」よりも、「AIが迷わず走れるレールをどこまで先に置けるか」を考えるようになりました。
具体的に起きたこと
印象に残っているのは、既存コードに小さな機能追加を入れたときのことです。
最初は、Issueの要約と該当ファイルを渡して、AIにそのまま実装案を出してもらいました。実装はすぐ動きましたが、レビューしてみると、依頼していない命名整理や周辺コンポーネントの軽いリファクタまで混ざっていました。
コードとしては悪くありません。でも、チームで見る差分としては重くなりました。
そこで次のタスクからは、実装前に次の3点を先にファイルへ固定しました。
- 今回やること
- 今回やらないこと
- 受け入れ条件とテスト観点
すると、AIへの依頼もレビューの入口もかなり安定しました。差分を見たときに「この変更はスコープ内か」「このテスト観点を満たしているか」から確認できるようになったからです。
体感として、実装速度そのものよりも、レビューで迷う時間が減ったことの方が効果が大きかったです。
よかったこと
特に効果を感じたのは、実装そのものよりも、実装前後の思考をファイル化するところでした。
たとえば、AIにいきなりコードを書かせるのではなく、次の順番に分けます。
- 目的を書く
- スコープを書く
- 受け入れ条件を書く
- テストケースを書く
- 変更計画を書く
- レビュー観点を書く
- その後で実装する
この順番にすると、AIはかなり扱いやすくなりました。
会話の勢いで進めるのではなく、ファイルを正本にすると、途中でセッションが切れても再開しやすくなります。チームでレビューするときも、「AIが何を考えてこうしたのか」を会話ログから掘り起こす必要が減ります。
つまずいたこと
一方で、AIをチーム開発に入れると、単に「速く書ける」だけでは済まない問題も見えました。
スコープが広がる
AIは、周辺の改善まで気づいてくれることがあります。それ自体はありがたいのですが、チーム開発ではスコープ外の改善が混ざるとレビューが重くなります。
「ついでに直した方がよさそう」は、人間同士でも危険です。AIが相手だと、その「ついで」が数十ファイルに広がることもあります。
テストが後付けになる
実装を先に作らせると、テストが「実装を正当化するもの」になりがちでした。
本当は、テストは仕様の確認であってほしい。だから、AIに実装させる前に、最低限のテスト観点を先に書くようにしました。
レビューの入口が曖昧になる
AIが作った差分を見るとき、人間はつい「コードが動くか」から確認しがちです。
でも、本当に先に見るべきなのは、そもそも計画が正しいか、受け入れ条件と一致しているか、スコープ外の変更が混ざっていないかです。
この入口を揃えないと、レビューがコードの細部に吸い込まれてしまいます。
たどり着いた運用: PlanGate
そこで、自分はAIコーディングの前に小さなゲートを置くようになりました。
考え方はシンプルです。
計画を承認しないとAIは1行もコードを書けない
自分はこの運用を PlanGate と呼んでいます。
PlanGateでやりたいのは、AIを縛ることではありません。むしろ逆で、AIが安心して走れる範囲を先に決めることです。
この記事ではテンプレートの細部よりも、なぜそのゲートが必要になったのかを残しておきたいです。
自分にとって大きかったのは、AIに渡す情報を会話ログではなくファイルに残すようにしたことでした。目的、スコープ、受け入れ条件、テスト観点、レビュー観点を分けておくと、AIに依頼するときも、人間があとから読むときも、判断の入口が揃います。
この形にすると、AIとの協働が「お願い」から「運用」に変わります。細かい手順を増やしたというより、作業の途中で迷ったときに戻る場所を作った感覚に近いです。
チーム開発で効いたこと
チームで効くのは、AIが出したコードの量ではなく、レビュー可能性が上がることでした。
AIが作った差分でも、次の情報がそろっていればレビューしやすくなります。
- なぜこの変更をするのか
- どこまでが今回のスコープか
- 何を満たしたら完了なのか
- どのテストで確認するのか
- AI自身はどこをリスクだと見ているのか
逆に、これがないと、AIで速く実装してもレビューで詰まります。
2025年に感じたのは、AI活用のボトルネックは「コードを書く速度」から「変更を安全に受け入れる速度」へ移っていく、ということでした。
2026年にやりたいこと
2026年は、AIコーディングを単発の便利技ではなく、チームの開発プロセスに自然に溶け込ませたいです。
特に深掘りしたいのは次の3つです。
- PBIやIssueの情報を、そのままAI実行の入力にできる形へ整える
- テストケースとレビュー観点を実装前に固定する
- AIが作った変更を、チームが安心してレビューできる単位に分ける
AIに任せるほど、人間の役割はなくなるのではなく、より設計寄りになるのだと思います。
何を任せるか。
どこで止めるか。
どの情報を正本にするか。
どうレビュー可能な差分にするか。
このあたりを設計することが、AI時代のチーム開発ではかなり重要になりそうです。
まとめ
2025年に生成AIを使ってみて一番感じたのは、AIは「賢い個人」ではなく「チームの一部として扱う対象」になってきた、ということです。
AIがコードを書けること自体は、もう珍しくありません。
これから大事になるのは、AIが作った変更をチームが理解し、レビューし、継続的に保守できる形へ落とし込むことだと思います。
自分にとっての答えのひとつが、PlanGateのように、実装前の計画とテスト観点をファイルとして残す運用でした。
AIとチームがうまく協働するためには、AIを自由に走らせる前に、走る場所を一緒に整える。
2025年は、その必要性に気づいた年でした。