8月20日、SD Timesが「Beyond AI Coding Assistants: The Next Evolution of Software Development」と題した記事を公開した。この記事では、AIコーディングアシスタントによるコード生成速度の向上にとどまらず、要件定義・テスト・デプロイといった意思決定の全フェーズにAIを組み込む「本当のAIネイティブ開発」とは何かについて詳しく紹介されている。

「AIネイティブ」という誤魔化し

開発チームがAIコーディングアシスタントを導入し、Q2の速度メトリクスが改善する。そして全社集会で誰かが「私たちはAIネイティブになった」と宣言し、会場が頷く――SD Timesはこのシナリオを問題提起の起点として記事を書き起こす。

問題は、何を測定していたかだ。コード出力量は増えた。しかしソフトウェアプロジェクトを殺してきたのは、コードの生産速度ではない。

記事が挙げる現実は辛辣だ：

• 矛盾だらけの要件定義書は、オートコンプリートでは検出されない
• ボードデモ前夜に下されたアーキテクチャ判断に、LLMはセカンドオピニオンを出さない
• ラインカバレッジ89%のテストスイートは、本番で最悪のタイミングで現れる障害モードを見逃す
• 深夜にGrafanaダッシュボードを眺める疲弊したエンジニアの問いに「本当に意図通り動いているか？」——この問いに現行のAIは答えない

AIコーディングアシスタントが本当に前進させたのは、ソフトウェア開発ライフサイクルのうちたった一部分だ。プロジェクトを壊す問題は、別の場所にある。

次のフェーズ：コードを書く前と、書いた後

SD Timesが描く「次の進化」は、より賢いコードレビューボットでも、精度の上がったオートコンプリートでもない。コードが書かれる前の意思決定に参加し、リリース後も参加し続けるAIだ。

要件分析：最も見過ごされている領域

記事が「最も過小評価されている領域」と位置づけるのが要件分析だ。多くのチームはこれを「解決済みの問題」として扱う。プロダクトマネージャーがいて、ユーザーストーリーがあり、リファインメントのプロセスがある。

しかしストーリーに埋め込まれた前提をアーキテクチャに固まる前に洗い出す仕組みは、どこにも存在しない。

AIが担える仕事は具体的だ：

• 要件定義書内の矛盾を検出する
• プロダクトチームが考慮しなかったエッジケースを特定する
• 新機能の提案を既存コードベースと照合し、インテグレーション上の摩擦が生じる箇所を事前にフラグ立てする

洗練されたAIツールを導入している組織でも、こうした活用はスプリントセレモニーの中で起きていない。この機会は「ほぼ手付かず」だと記事は評する。

テスト：「何をテストするか」の判断こそが本題

AIによるテスト支援の現状は、「AIがテストケースを生成する」に収まっている。これは役に立つが、本質的な問いには届いていない。AIはテストを書くだけでなく、何をテストすべきかの判断に参加できるか？

ここで記事が参照するのがリスクベーステスト（Risk-based testing）という考え方だ。障害が発生したときの影響度と発生確率を軸に、テストリソースの優先順位を動的に決める手法で、ISTQBなどのテスト標準でも体系化されている。この考え方自体は数十年前から存在するが、特定のコードベース・特定のデプロイ文脈に対して、直前リリースからの変更差分を踏まえて動的に適用するには、スケールしないドメイン知識が必要だった。まさにここがAIで補強できる判断だ、と記事は指摘する。

SD Times自身もエージェンティックワークフローのテスト駆動アプローチを過去に取り上げているが、大半のエンジニアリングチームはまだ「AIでテストを書く」段階にとどまっている。

デプロイと可観測性：ガバナンスの空白

AIエージェントが本番環境でアクション（異常検知、自動ロールバック、インシデントトリアージ）を取る事例は、2年前には理論上の話だったが、今は現実になっている。

ここで記事が指摘する不都合な問いがある。「人間が意識的に下した決定ではない」判断が生じたとき、組織内の責任帰属の仕組みはそれに対応できていない。

具体的には、AIエージェントが自動ロールバックを実行した場合、その判断の根拠をどこに記録し、誰がレビューし、次のスプリントにどう反映するか——こうした問いに答える組織的プロセスが、ほとんどのチームで未整備のままだ。可観測性ツールの導入が進んでいる組織であっても、「AIが下した判断の説明責任」を制度として設計しているケースは少ない。AI支援開発における可観測性に投資しているリーダーの多くが、ガバナンスの設計では遅れを取っているというのが記事の見立てだ。

ワークフロー自体を問い直せ

記事が最後に指摘する「最もよくある間違い」は本質的だ。既存のワークフローの各ステップにAIを当てはめるだけでは不十分だということ。

人間がすべての意思決定を行うことを前提に設計されたワークフローは、要件・テスト・デプロイ・監視を同時にAIが担うチームには適していない。ハンドオフの位置が変わり、レビューチェックポイントを動かす必要があり、「完了の定義」そのものが変わる。

記事はエンジニアリングリーダーへの問いをこう言い換える：

「どうAIを開発プロセスに使うか？」ではなく、「今、検証に耐えない理由でAIから守っている意思決定はどれか？」

この問いの方が不快で難しい。そして、本物の変革をしている組織とライセンスを買っただけの組織を分けるのも、この問いに向き合えるかどうかだと記事は結ぶ。

詳細はBeyond AI Coding Assistants: The Next Evolution of Software Developmentを参照していただきたい。