先に結論
AI によるコーディング支援によって、コードを書く速度は確実に上がりました。
ただ、今回の原文を読んで一番強く感じたのは、
本当に難しくなっているのは「コードを書くこと」ではなく、そのコードを安心して本番に出せる状態にすること だという点です。
原文はこちらです。
記事では、Sonar の State of Code Developer Survey をもとに、AI によるコーディング支援の現実がかなり具体的に語られています。
特に印象に残ったのは、次のような数字です。
- AI によるコーディング支援ツールを試した開発者の 72% が、すでに毎日使っている
- 開発者がコミットするコードの 42% は、AI が生成したもの、または AI の支援を受けたもの
- 2027 年には、その割合が 65% まで増えると予想されている
- 一方で、96% の開発者は AI が生成したコードを完全には信頼していない
- それでも、コミット前に常に確認している開発者は 48% にとどまる
このギャップが、今の AI コーディング支援の本質だと思いました。
AI は速い。
でも、速く出てきたコードを、ちゃんと本番に出せる状態にするところで詰まる。
今回は、そのあたりの学びを整理してみます。
AI コーディング支援の問題は「使うかどうか」ではなくなっている
少し前までは、AI によるコーディング支援は「使う人と使わない人」に分かれていた印象があります。
でも今は、もうかなり状況が変わっています。
業務で GitHub Copilot、ChatGPT、Claude Code、Cursor、Codex CLI などを使うことは、特別なことではなくなってきました。
たとえば、次のような場面ではかなり使いやすいです。
- 試作品を素早く作る
- テストコードのたたき台を作る
- ドキュメントを書く
- 既存コードの意味を説明してもらう
- 単純な修正案を出してもらう
つまり、今の論点は、
AI によるコーディング支援を使うべきか
ではなく、
AI によって増えたコードを、どう安全に扱うか
に移っていると思います。
ここを間違えると、「AI で速くなった」はずなのに、後工程でレビュー、修正、テスト、障害対応が増えて、結果としてチーム全体はあまり速くならない、という状態になりやすいです。
学び1: AI は面倒な作業を消すのではなく、場所を変える
原文を読んで、一番刺さったのはこの点です。
AI によって、昔ながらの面倒な作業はかなり減ります。
たとえば、
- 決まりきった定型コードを書く
- テストコードのたたき台を作る
- ドキュメントを書く
- 既存コードを説明してもらう
- 単純な修正案を出してもらう
こういう作業はかなり楽になります。
ただ、その代わりに新しい面倒な作業が出てきます。
それが、検証する作業 です。
AI が出したコードは、それっぽく見えます。
しかも、最近のモデルはかなり自然に、かなり大量にコードを書きます。
でも、それが本当に正しいかどうかは別です。
- 境界条件は合っているか
- 既存仕様と矛盾していないか
- セキュリティ上の問題はないか
- 将来メンテナンスできるか
- チームの設計方針に合っているか
- 障害時にどう振る舞うか
こういう部分は、コードが速く出てくるほど、むしろ重くなります。
つまり、AI は面倒な作業をゼロにするのではなく、
「作る作業」から「確かめる作業」へ移動させている のだと思います。
学び2: 「コードを書く速度」と「本番に出す速度」は違う
AI によるコーディング支援の話では、よく「何倍速く書けるか」が注目されます。
でも、原文で重要だと思ったのは、次の視点です。
コードを速く書けることと、安心して本番に出せることは別である
これはかなり本質的だと思います。
コードを書くことは、ソフトウェア開発の一部でしかありません。
実際には、その後に、
- レビュー
- テスト
- セキュリティ確認
- 他の機能との結合確認
- リリース
- 監視
- 保守
があります。
AI がコードを書く速度を 2 倍にしても、レビューや検証が 3 倍重くなったら、チーム全体としては速くなっていません。
むしろ、確認不足のコードが増えることで、後から技術的負債として返ってくる可能性があります。
なので、AI によるコーディング支援の効果を見るときは、
どれだけ速く書けたか
ではなく、
どれだけ安全に、本番に出せる状態まで持っていけたか
を見るべきだと感じました。
学び3: AI が生成したコードでも、責任を持つのは人間
AI が書いたコードでも、本番で問題が起きたときに責任を取るのは AI ではありません。
最終的には、それを取り込んだ人、レビューした人、本番に出したチームが責任を持つことになります。
ここは忘れがちですが、かなり大事です。
AI が書いたからといって、責任まで AI に移るわけではありません。
むしろ、AI が書いたコードほど、人間側の説明責任が重要になります。
個人的には、取り込む前に最低限これを確認した方がよいと思いました。
- なぜこの実装にしたのか説明できるか
- 失敗ケースを説明できるか
- 既存仕様との関係を説明できるか
- セキュリティや権限周りの前提を説明できるか
- 後から別の人が読んでも理解できるか
説明できないコードは、まだチームのコードになっていない。
AI 時代のレビューでは、この観点がかなり重要になっていくと思います。
学び4: AI によるレビューだけでは足りない
AI がコードを書き、別の AI がレビューする。
この流れは今後かなり増えると思います。
ただ、原文では、AI によるレビューだけに寄せすぎる危うさも示されていました。
AI は便利ですが、書いた側とレビューする側が似たような判断をする場合、同じ種類のミスを見逃す可能性があります。
そこで重要になるのが、自動チェックの仕組み です。
たとえば、
- 静的解析
- 書式チェック
- 型チェック
- 自動テスト
- セキュリティスキャン
- 品質ゲート
- CI/CD 上の自動チェック
こういう仕組みです。
AI は「それっぽく考える」のが得意です。
一方で、静的解析やテストは「決められたルールで確実に確認する」のが得意です。
この2つは競合ではなく、役割分担だと思います。
AI に任せるところと、機械的に落とすところを分ける。
ここを設計しないと、AI によって増えたコードに品質保証が追いつかなくなります。
学び5: 新規開発では強いが、既存システムの修正では文脈が足りない
AI によるコーディング支援は、新規開発ではかなり強いです。
ゼロから作る画面、API、テスト、サンプル実装などは、かなり速く形になります。
一方で、既存システムの修正では難しくなります。
理由は単純で、既存システムにはコードに書かれていない前提が多いからです。
- 昔からある暗黙ルール
- 特定顧客向けの例外処理
- ドキュメント化されていない制約
- 古いフレームワークの癖
- 既存 API の微妙な互換性
- 失敗してはいけない業務フロー
こういう情報は、AI がコードを読んだだけでは分からないことがあります。
だから、既存システムで AI を使うなら、単に「このコードを直して」と言うだけでは足りません。
むしろ重要なのは、AI に渡す前提情報をどう作るかです。
たとえば、
- このモジュールの役割
- 触ってはいけない箇所
- 既存の設計判断
- 過去に起きた障害
- テストで守るべき業務条件
- 参考にすべき既存実装
- 変更時に必ず確認する観点
こうした情報を AGENTS.md や開発ルール、開発メモ、PR テンプレートなどに整理しておくと、AI の出力もかなり変わってくると思います。
今すぐやるべきこと
1. AI に大きな PR を作らせない
AI は放っておくと、大きな差分を一気に出しがちです。
でも、大きな PR はレビューが難しいです。
AI が書いた大きな PR は、さらに難しいです。
なので、AI を使うほど PR は小さくした方がよいです。
目安としては、
この PR は一言で説明できるか
を確認するとよいと思います。
説明できないなら、分けた方がよいです。
2. コミット前の確認を自動化する
AI が生成したコードを毎回人間だけで確認するのは、かなり大変です。
なので、最低限のチェックは自動化した方がよいです。
- 自動整形
- コーディング規約のチェック
- 型チェック
- 単体テスト
- セキュリティスキャン
- 依存ライブラリの確認
- 静的解析
- テストカバレッジ確認
こういうものを、AI によるコーディング支援を前提に見直す必要があります。
AI が速く書くなら、検証も速く回る必要があります。
3. レビューでは「なぜ」を見る
AI 時代のレビューで、人間が見るべきものは少し変わってきます。
細かい typo や命名、書式は AI やツールに任せやすいです。
人間が見るべきなのは、
- なぜこの設計なのか
- なぜこの境界で分けたのか
- なぜこのエラー処理なのか
- なぜこのデータ構造なのか
- なぜこの制約を許容したのか
という判断の部分です。
コードそのものより、判断の根拠を見る。
ここが人間レビューの価値になっていくと思います。
4. AI に渡すプロジェクト情報を育てる
AI に毎回同じ説明をするのは効率が悪いです。
プロジェクトごとに、AI が参照できる前提情報を少しずつ整備した方がよいです。
たとえば、
- コーディングルール
- アーキテクチャルール
- ディレクトリ構成
- テスト方針
- セキュリティ方針
- API 設計ルール
- データ移行ルール
- レビュー観点
こういう情報です。
ただし、立派なドキュメントを作る必要はありません。
大事なのは、AI と人間が同じ前提で作業を始められることです。
5. 「AI が書いた」ではなく「自分が本番に出す」と考える
最後はこれだと思います。
AI が書いたコードでも、取り込むなら自分のコードです。
AI が提案した設計でも、採用するならチームの設計です。
なので、最後に必ず確認したいです。
このコードを自分の言葉で説明できるか
説明できるなら、AI は強力な相棒になります。
説明できないなら、まだ使い方が浅いのだと思います。
まとめ
AI によるコーディング支援は、コードを書く速度を大きく上げました。
でも、それによって開発が自動的に楽になるわけではありません。
むしろ、これから重要になるのは、
- AI が書いたコードを検証する力
- 大きな差分を小さく分ける設計力
- 既存システムの文脈を整理する力
- レビューで判断の根拠を見る力
- 本番に出すコードに責任を持つ力
だと思います。
今回の原文を読んで、自分の中で一番大きかった学びはこれでした。
AI によるコーディング支援の本当の差は、コード生成速度ではなく、検証と説明責任で決まる。
AI はこれからもどんどん速くなります。
だからこそ、人間側は「速く書く力」よりも、「正しく本番に出す力」を磨く必要があると感じました。