9月10日、Telerikが「AI Workflow Automation for Dev: Hand an Agent a Whole Job」と題した記事を公開した。AI評価研究グループMETRの試験では、AIコーディングツールを使った開発者が19%遅くなるという結果が出ている。「AIを活用している」はずのチームで、なぜデリバリーが遅延するのか。本記事はその構造的な原因と、ワークフロー全体をエージェントに委ねるための制約設計・評価指標の考え方を詳説している。
「AIを使っている」と「AIワークフロー自動化」は別物だ
多くのチームは「AIを活用している」と言いながら、実態は手動プロセスの個別ステップにAIを挟んでいるだけだ。
典型的な例が依存ライブラリのアップグレードだ。月曜にボットがPRを開き、エンジニアがチェンジログをAIアシスタントに貼り付けて内容を確認する。ビルドが失敗したら別のアシスタントに貼り付けて修正案を出してもらい、誰かが手で適用して木曜にマージされる。バージョン番号を1つ上げるのに4日かかる。
この場合、AIは個々のステップで機能しているが、ステップ間の「運搬」は人間がブラウザのタブ間でテキストをコピペしている。それはワークフローの自動化ではない。
真のAIワークフロー自動化とは、トリガーが1つ、実行が1回、最後にレビューが1回という形で、ステップ間の手動引き渡しをなくすことだ。
ただし、手動の引き渡しを取り除くと、誰も「コントロール」として認識していなかった暗黙のチェックポイントも消える。誰かが次のステップに渡す前に必ず一度目を通していた、その確認作業だ。これを補うために、ワークフローは「完了の定義」「変更可能な範囲」「誰がレビュー・承認するか」を明示的に定める必要がある。
管理タスクより「デリバリー作業」を狙え
チームが最初に自動化しがちなのは、イシューのラベル付け、チームへのルーティング、PRのサマリー生成といった周辺業務だ。これらは失敗してもインシデントにならない。ラベルの付け間違いで深夜に呼び出されることはない。
一方、デリバリーステージの自動化は「完了の定義」が難しい。以下の表が整理の参考になる。
| ライフサイクルステージ | AI以前の自動化 | ルールで表現できない判断 | 「完了」の意味 |
|---|---|---|---|
| テストメンテナンス | 失敗時のリトライ、隔離リスト | 失敗が本物かどうか、どの変更が修正になるか | アサーションを弱めていないグリーンスイート |
| 依存アップグレード | バージョンバンプPRの自動作成 | チェンジログが実際に呼び出しているコードに影響するか | レビュー可能なサイズのマージ済みアップグレード |
| インシデント対応 | アラートルーティング、ランブックリンク | 直近のデプロイがアラートの原因か | 担当者がロールバックを判断した状態 |
この「完了」列が自動化可否を左右する。チームが「成功の定義」を言語化できていないなら、自動化は時期尚早だ。
最初の実行前に「制約」を書き切れ
AIエージェントがコードやシステムに作用する前に、その境界を明文化する必要がある。制約は実行中に設定できない。ワークフロー定義に書き込んでおくこと。
- 予算：1回の実行で使えるステップ数・トークン数の上限と、上限到達時の挙動。無制限のリトライ権限を与えると、エージェントはコードを直すよりテストのアサーションを弱める方が簡単だと学習しかねない。
- 書き込みパス：変更を許可するファイルの範囲。4,000行の差分を渡されたレビュアーは「承認」はするが「レビュー」はしない。変更範囲を絞ることで、人間が実質的に読めるサイズに収める。
- コマンドと認証情報：呼び出し可能なツールの制限。エージェントがイシューのコメントなど信頼できないテキストを読める場合、悪意ある指示に従うリスクがある（OWASPのプロンプトインジェクションガイダンス参照）。設計を誤ると、バグレポートに仕込まれた指示に従い、自チームのサービスアカウントが深夜3時に有効なトークンで変更を実行するインシデントが起きる。
- 承認：署名が必要なアクション。Microsoftの研究者が1,535人の開発者を対象に実施したアンケート調査では、回答を5段階スケールに分類した結果、開発作業の中央値はレベル3、すなわち「AIが変更を書き、開発者が反映前に承認する」だった。承認を「摩擦」と呼ぶ意見があるが、これは意図的な安全管理だ。
各制約には担当オーナーを置くこと。今日合理的なルールが後に陳腐化することがある。誰も責任を持たなければ、一時的な例外が誰も決断していない恒久的なポリシーになる。NISTのAIリスク管理フレームワークも同じ理由でAIリスク担当ロールの明文化を求めている。
エージェントではなく「ワークフロー」を計測せよ
AI自動化の成否は、AIが速いかではなく、ソフトウェアデリバリープロセス全体が改善されたかで測る。
DORAメトリクスの2つが指標になる：
- リードタイム：コミットが本番に届くまでの時間
- 変更失敗率：変更が問題を引き起こす頻度
重要な反例がある。AI評価研究グループMETRが2025年初頭のコーディングツールを用いて、経験豊富なオープンソース開発者16人・246件の実イシューで実施したランダム化試験では、ツールを使った開発者は19%遅くなった。コードの到着は速くなったが、出力の読解・検証に時間が移動しデリバリーが遅延した。「タイピングが速い」ことは「デリバリーが速い」ことではない。
Googleの2025年DORAレポートでも、AIを多く採用したチームはスループットと不安定性がともに高いと報告されており、AIが両方を引き起こしたとは断定していない。これは小さくないリスクの構造だ。ワークフローがレビュアーの処理能力を超えるペースで出力を生み出すと、不安定性が増す。
まず承認必須モードで実行し、数週間両指標を監視してから、権限を広げるかどうかを判断する。
まず1つのワークフローから始める
ツール選定はワークフローの定義が終わってから行う。多くの製品が「AIワークフロープラットフォーム」を名乗っているが、ラベルより実際に強制できるコントロールを確認する。「実行に上限を設けられるか」「触れないディレクトリを指定できるか」「変更前に人間の承認を必須にできるか」——この3点の答えがツール選定の基準になる。
自動化の範囲を広げるのはその後だ。計測なしに権限だけを拡大すると、上述の19%遅延と同じ構造——速く動いているように見えて、デリバリー全体は遅くなる——に陥るリスクがある。制約設計と計測をセットで進めることが、AIワークフロー自動化を「実験」から「実運用」に移行させる条件だ。
詳細はAI Workflow Automation for Dev: Hand an Agent a Whole Jobを参照していただきたい。
