AI駆動のエージェントに、1ヶ月間CI/CDパイプラインの運用を任せてみました。試行期間の終わりには、エージェントは失敗したビルドを修正し、プルリクエストを作成し、ジョブを再実行するようになり、人間が行う作業は最終的な承認ステップのみとなりました。この実験は、「エージェンティック（agentic）」なDevOpsが、ルーチン的なトリアージをバックオフィスから自動化された「脳」へと移行させられることを示す一方で、自律型システムが新たなリスク要因にならないようにするためのガードレール（防護策）の重要性も浮き彫りにしました。
なぜこの実験が重要だったのか
ほとんどのソフトウェアチームは、いまだにAIを「高性能なオートコンプリート」——コードの1行を提案したり、エラーメッセージを説明したりするツール——として扱っています。2025年、業界は「タイピングを助けるAI」から「行動するAI」へとシフトしています。行動するエージェントは、ログを読み、修正方法を決定し、それを適用し、その結果から学習することができます。これらすべてを、開発者がコマンドを一つも入力することなく実行できるのです。
基本となる考え方：エージェンティック・パイプライン
エージェンティック・パイプラインとは、本番環境への無制限なアクセス権を持つ単一のモノリシックなモデルのことではありません。それは、専門化されたツールを調整し、コンテキストを保持し、厳格なガードレールの背後で動作する、限定的なオーケストレーターです。そのコアループは、人間のトラブルシューティングのプロセスを反映しています。
- 知覚 (Perceive) – ログ、テスト出力、メトリクスを取得する。
- 推論 (Reason) – 失敗を分析し、最も安全な修復計画を立てる。
- 実行 (Act) – スコープの限定されたツールを呼び出し、パッチの適用、依存関係のアップグレード、またはジョブの再実行を行う。
- 学習 (Learn) – 結果を記録し、次の決定をより適切なものにする。
実験の安全性を保ったアーキテクチャは、以下のようになっています。
- CI/CDプラットフォーム – ジョブのスケジューリングと実行を行う。
- オーケストレーター – データを受け取り、制御ループを実行し、何をすべきかを決定する「脳」。
- ツール – 具体的なアクションを実行する「手」（例：PRの作成、バージョンの更新）。
- コンテキストストア – 最近の失敗と修正に関する軽量なメモリ。
- ガードレール – エージェントが本番環境に直接触れたり、明示的な人間の承認なしに変更を行ったりすることを防ぐための厳格な制限。
大規模言語モデル（LLM）を本番環境への直接的な書き込みから遠ざけることで、システムはモデルに問題の推論を行わせつつ、攻撃対象領域（attack surface）を削減しました。
エージェントの1ヶ月間の歩み
第1週：読み取り専用の観察
エージェントは「説明のみ」モードで動作しました。ビルドが失敗するたびに、エラーを要約し、考えられる原因を提案するSlackメッセージが生成されました。コードの変更は一切行われませんでした。このフェーズにより、知覚と推論のステップが実際のログに対して機能することが証明され、エージェントがコードベースを理解しているという確信をチームに与えました。
第2週：修正案の提示
続く7日間、オーケストレーターは、リンターのエラーや古い依存関係といった低リスクな問題に対してプルリクエストを作成しました。エンジニアはマージ前にそれらのPRをレビューしました。
第3週：制御された実行
承認ワークフローが整ったことで、エージェントは非本番環境でのジョブの再実行権限を与えられました。ビルドが失敗すると、オーケストレーターは自動的に壊れた依存関係の正しいバージョンを固定（ピン留め）し、PRを作成し、PRがマージされた後にパイプラインを再実行しました。
第4週：影響の測定
最終週は結果の測定に焦点を当て、エージェントがどれだけの失敗を解決したかを追跡しました。
メリット：退屈な作業の排除
この実験により、AIエージェントがCI/CDの反復的な部分（ログの読み取り、既知のパターンの特定、バージョンの更新、ジョブの再実行）を処理できることが示されました。エンジニアは、最終的な変更を承認し、エージェントが解決できなかった数少ないエッジケースの失敗を調査するだけで済みました。実務においては、これは深夜の呼び出しの減少、コンテキストスイッチングの軽減、そして開発者にとってより緊密なフィードバックループを意味します。
落とし穴と回避策
- 自信満々な誤った修正 – エージェントが、より深いバグを隠蔽してしまうような、対症療法的なパッチを適用してしまうことがありました。本番コードに触れるあらゆる変更に対して人間の承認を必要とするガードレールによって、このリスクは抑えられました。
- ノイズの過負荷 – フィルタリングされていない通知は、重要なアラートをかき消してしまう可能性があります。
- スコープクリープ – モデルに無制限のアクセス権を与えると、すぐに予期せぬ副作用を招きます。LLM（推論）とツール（実行）を厳格に分離したアーキテクチャにより、エージェントが勝手な変更を行うことを防ぎました。
他のチームのための段階的な導入計画
組織でエージェンティック・パイプラインを試したい場合は、以下の段階的なアプローチに従ってください。
- オーケストレーターのセットアップ – LLMを呼び出し、コンテキストを保存し、CI/CD APIを起動できる軽量なサービス。
- ガードレールの定義 – エージェントがトリガーできるCI/CDジョブをホワイトリスト化し、PRの承認を必須とし、本番環境への直接的な書き込みをブロックする。
- 第1週：観測モード – ログをオーケストレーターに供給し、診断サマリーをチャットチャネルに投稿させる。
- 第2週：提案モード – 非クリティカルな修正に対してエージェントがPRを作成できるようにする。ただし、人間によるレビューは必須とする。
- 第3週：制御されたアクション – PRのマージ後、ステージングまたはテスト環境でジョブを再実行する権限を付与する。
- 第4週：メトリクスとチューニング – トリアージされた失敗、誤検知、節約された時間を追跡し、それに応じてアラートのしきい値やガードレールを調整する。
- 反復（イテレーション） – 各新しい機能が同様の安全性チェックに合格した後にのみ、ツールセット（例：自動ロールバック、セキュリティスキャン）を拡張する。
反論
懐疑的な人々は、エージェントが「自信満々に間違える」可能性があると指摘しています。この実験はその懸念を解消したわけではありません。単に、規律あるガードレールを設けることで、リスクを管理可能な範囲に抑えつつ、その恩恵を享受できることを示したに過ぎません。
要点
CI/CDのコントロールループを実行するAIエージェントは、モデルを分離し、厳格な承認ステップを強制し、低リスクな「観測優先」のアプローチから始めるという条件付きで、リアクティブで手動なトリアージプロセスを、ほぼ自己修復可能なパイプラインへと変えることができます。真の価値はエンジニアを置き換えることではなく、パイプラインを正常（green）に保ち、開発者が構築に集中できるようにするための、退屈で繰り返しの多い雑務を肩代わりすることにあります。