Stack Overflowの開発者調査が、ひとつの逆説を記録しています。AIツールを使っている、または使う予定だと答えた人は84%を超えたのに、その正確さを信頼している人は29%にとどまり、前年より11ポイント下がりました。使うほど信頼が下がっているのです。開発チームへのAIコーディング支援ツールの導入を検討している企業にとって、この数字は中止の理由ではなく、導入方法への示唆です。
なぜ利用は増え、信頼は下がるのか
技術は普通、慣れるほど信頼されます。ここでは逆で、実際に使った人なら理由はすぐ分かります。これらのツールは、雛形づくり、繰り返し作業、形式変換がとても速い。開発者が時間を使うが頭は使わない領域です。同時に、見た目はまったく妥当なのに細部が誤っている出力も生みます。ライブラリのバージョン違い、境界条件の抜け、存在しない関数を自信たっぷりに呼ぶコードなどです。
この種の誤りは、構文エラーとは費用の性質が違います。構文エラーはコンパイラで止まります。「正しく見える」誤りはレビューをすり抜け、本番で表に出ます。
AIが明確に報われる場面
- 型の決まった繰り返し作業：DTOの作成、データの対応付け、テストの骨組み、一覧から入力フォームへの変換。
- 他人が書いたコードを読む：800行のクラスの要約、処理の流れの把握、複雑な問い合わせの説明。実際の価値に比べて最も過小評価されている使い方です。
- 文書の初稿：API仕様、リリースノート、利用者向け手順書。
- 機械的な変換：構文の更新、ライブラリの置き換え、性能比較のための問い合わせの書き換え。
人が間に入るべき場面
- 業務ルール。自社の値引き計算の仕方をモデルは知りません。もっともらしく推測し、そして誤ります。
- 権限とセキュリティ。生成された権限判定のコードは、形は正しくてもデータ範囲が抜けているのが通例です。
- 大きなテーブルへの問い合わせ。提案は索引を無視し、結果全件をアプリへ持ってきがちです。
- 金額に触れる処理。債権、税、為替。丸め誤差がそのまま帳簿に入る領域です。
技術的負債を増やさない導入の仕方
次の三つを守れば、生産性だけを受け取れます。
- 責任はプルリクエストを出した人にあり、ツールにはない。なぜ正しく動くか説明できないコードは、誰が書いたものであれ取り込む段階にありません。
- テストは条件であって選択肢ではない。AIはテストを速く書けます。その速さを機能コードだけでなくテストに使ってください。
- データの境界を引く。外部ツールに貼ってはいけないものを明示します。中核のソースコード、顧客データ、設定鍵など。VerizonのDBIR 2026では、企業端末からAIサービスを使った利用者の67%が会社管理外のアカウントを使っていました。悪意がなくてもデータは会社の管理外へ出ます。
何で測るか
数か月後に効果を評価するなら、コード行数は数えないでください。次の三つのほうが実態を映します。
- プルリクエストを開いてから取り込むまでの時間。
- リリース後に修正が必要になった不具合の割合。
- 新しく加わった人が、不慣れな部分を理解して安全に変更できるようになるまでの時間。「読んでもらう」用途が最も効くところです。
AIは、着想から下書きまでの距離を縮めます。下書きから本番で動くものまでの距離は、いまも人が歩いています。
参考資料
- Stack Overflow — Mind the gap: Closing the AI trust gap for developers
- Stack Overflow Developer Survey
- Verizon — 2026 Data Breach Investigations Report
調査数値は上記の出典からの引用で、分析と導入に関する提言はNinePlusの見解です。
