こんにちは、SRE の永尾です。
今回は、生成 AI と開発生産性・品質向上について、日々感じていることを研究データと照らし合わせながら考えてみたいと思います。
「生産性が劇的に向上！」は本当か？
生成 AI によるコーディング支援ツールが普及して、「生産性が大幅に向上する」という期待が高まっていますね。
でも、実際のところはどうでしょうか？
GitHub Copilot の研究では、タスク完了が 55% 高速化したという結果が報告されています。(Copilot 利用群は平均 1 時間 11 分、非利用群は平均 2 時間 41 分)
Research: quantifying GitHub Copilot’s impact on developer productivity and happiness
一方で、METR のランダム化比較試験では、経験豊富な開発者が AI ツールを使うと、平均で 19% 長くかかったという結果も出ています。面白いのは、開発者自身は「速くなった」と感じていたという点です。
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
このように、生成 AI で速くなるケースもあれば、条件によっては遅くなることもあるというのが現状だと思います。
人間がボトルネックになっている？
なぜ期待通りの効果が出ないのか？
私は、人間側の理解・判断がボトルネックになりやすいのではないかと考えています。
- AI がコードを生成する速度は非常に速い
- でも、そのコードをレビューして理解して判断するのは人間
- 承認プロセスや組織的な意思決定も時間がかかる
METR の報告でも、AI を使った方が実時間は伸びたのに、主観的には「速くなった」と感じていたというギャップがありました。「生成→検証→修正」の往復が影響しているのかもしれません。
Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
チューニングに時間をかけているフェーズ
こうした背景を踏まえると、今は多くの組織が AI 開発ツールのチューニングに時間を投資している段階なのではないでしょうか。
- プロンプトや指示の最適化
- 社内コンテキストを理解させるためのカスタマイズ
- 開発フローへの統合方法の模索
これらは「短期の生産性向上」には直結しにくいですが、中長期で効果を出すための基盤投資になると思います。
待機時間を活用して「痒いところ」に着手
そうした中で、私たちが SRE 活動を行っている開発チームでは面白い現象が起きています。
AI とのやりとりの待ち時間や、単純作業を AI に任せた分の余裕を使って、これまで手が回らなかった”痒いところ”に着手し始めているんです。
具体的には
- ドキュメントの整備
- テストカバレッジの向上
- リファクタリングや保守性改善
といった取り組みです。これらは「機能開発」としてはカウントされにくいですが、品質向上に直結する活動です。
未然に防いでいるバグや障害
その結果として、生産性は劇的に上がっていないけど、品質は上がっているという状況が生まれているのではないでしょうか。
例えば、
- コードレビューの精度が上がる
- エッジケース対応が増える
- セキュリティ課題を早期に拾える
といった効果が考えられます。
ただし、注意点もあります。GitClear の分析では、重複コードの増加や短期チャーンの増加など、保守性に影響する指標の変化も報告されています。
AI Copilot Code Quality: 2025 Look Back at 12 Months of Data
このように、生成 AI によって品質は上がっている可能性がありますが、問題はその成果が見えにくいということです。
バグが起きなかった、障害が未然に防がれた — これらは「何も起きなかった」という形でしか現れません。
(とはいえ、生成 AI の活用で生まれた余裕を使って、こういったプロアクティブな活動に時間を割けるようになったのは、間接的ですが大きな効果だと思います)
SRE 活動との類似性
この「成果が見えにくい」という構造は、SRE 活動と非常に似ています。
SRE の価値も、「障害が起きなかったこと」で測られる場面が多いです。
「(The Paradox of the Invisible Discipline) 見えない規律のパラドックス」という言葉があります。
これは、仕組みがうまく機能して問題が消えるほど、成果が”見えなくなる”という現象を指しています。
生成 AI によって品質向上活動に時間を割けるようになった結果、バグや障害が未然に防がれている。
しかし、それはまさに SRE と同じく「見えない成果」になってしまうのです。
SLO で「見えない成果」を可視化できるか
では、この「見えない成果」を SLO で可視化することは可能でしょうか？
結論としては、可能だと思っています。
SLI/SLO は本来、ユーザー体験を定量化する仕組みです。Google SRE 本では、SLI を「サービスレベルの定量的尺度」と定義しています。
Google SRE – Service Level Objectives
Google SRE における SLI/SLO の基本
まず、基本的な概念を整理しておきましょう。
- SLI: サービスレベルの定量指標（例：成功率、レイテンシなど）
- SLO: SLI に対する目標値（例：成功率 99.9% 以上など）
なお、QPS など「ユーザーの需要で決まる指標」には SLO を設定できない、という点も触れられています。
Google SRE – Defining slo: service level objective meaning
「見えない品質向上」を SLI/SLO でどう捉えるか
これらの概念を踏まえて、「見えない品質向上」をどう可視化できるか考えてみましょう。
| 品質向上の成果 | 関連する SLI | 可視化の考え方 |
|---|---|---|
| バグの未然防止 | Availability / Error rate | 成功率の維持・改善 |
| パフォーマンス改善 | Latency | p90/p99 の改善 |
| システム安定性向上 | Error budget 消費 | バジェット消費が抑えられる |
エラーバジェットは、SLO を運用判断に落とすための道具です。
Google SRE – Error Budget Policy for Service Reliability
つまり、「SLO を満たし続けて、エラーバジェットを健全に維持できている」という形で、「何も起きなかった」成果を間接的に示せるわけです。
定性的指標との組み合わせ
とはいえ、開発生産性や開発体験は、客観的に測るのが難しい側面があります。GitHub も「生産性の測定の難しさ」について触れていますし、Martin Fowler も「ソフトウェア開発の生産性は合理的に測れない」と述べています。
Martin Fowler – Cannot Measure Productivity
そのため実務では、定量と定性を組み合わせるのが扱いやすいと思います。
- 開発者サーベイ（ブロッカー、快適さ、自信度など）
- コードレビュー指摘の傾向分析
- 保守性指標の推移
まとめ
生成 AI は、「生産性を劇的に向上させる銀の弾丸」というよりも、「品質向上の余地を生み出すツール」として機能しているのではないでしょうか。
- 研究でも結果は混在している（速くなるケース／遅くなるケース）
- 人間の理解・判断がボトルネックになりやすい
- 今はツール統合・運用のチューニングに投資するフェーズ
- 生まれた余裕で”痒いところ”に手が回り、品質が上がる
- これは「見えない規律のパラドックス」と似た構造
- SLI/SLO とエラーバジェットで「見えない成果」を可視化できる(かも
かくいうこの記事もほとんど生成 AI に書かせています。
今後も、生成 AI を過度に神格化せず、品質向上のための一つの道具として活用していきたいと思います！