DevOpsの「Ops」にAIをどのように組み込んでいくのか

はじめに

「DevOps」という言葉が生まれる前、開発(Dev)と運用(Ops)は別々の部署であり、別々の目標を持っていました。

開発チームは新機能を素早くリリースすることを目指し、運用チームはシステムを安定稼働させることを目指します。

この2つの目標はしばしば対立し、「Dev vs Ops」という構図が生まれていました。新機能のリリースはシステムの不安定化リスクを伴うため、運用チームはリリースに慎重な姿勢を取り、開発チームはそれを変化を嫌う壁と感じていました。

DevOpsという考え方は、この対立を「Dev and Ops」という協調関係へ変えるために提唱されました。開発と運用が同じゴール(顧客へ価値を素早くかつ安全に届けること)を共有し、ツールとプロセスを通じて協力する体制を目指したのです。

本連載も、このDevOpsのサイクルを一つひとつのツールを通じて実践する形で進めてきました。では、AI時代において、このDevとOpsの関係はどうなっていくのでしょうか。

前回では、「Dev」側に焦点を当てました。要件定義や設計、実装、コードレビュー、テスト、ドキュメント管理といった開発ライフサイクルの各フェーズでAIがどのように使われ始めているかを解説しました。

多くの開発現場では、人手不足や締め切りに追われて導入できなかった自動テストやコードレビューの徹底を、AIの補助によって現実的なコストで運用できる可能性が出てきたことを見てきました。

今回はその対となる「Ops」に焦点を当てます。運用の現場でも、監視を強化したい、障害対応を自動化したいと分かっていながら、人手不足や既存システムの複雑さから手が回らなかった現場は少なくありません。

Opsライフサイクルの各フェーズで起きている変化

AIの活用は、単一の作業の自動化にとどまりません。監視、障害対応、インフラ運用、セキュリティ運用のそれぞれで、作業のやり方が変わり始めています。

監視とオブザーバビリティ

従来の監視は、CloudWatchアラームのように閾値を人間が設定し、その閾値を超えたら通知する仕組みが中心でした(第19〜20回で解説した内容です)。閾値の設定には経験と調整が必要であり、閾値が厳しすぎれば誤検知が増え、緩すぎれば異常を見逃します。

近年の監視サービスは、この閾値設定そのものをAIに任せる方向へ進んでいます。

Amazon DevOps Guruは、CloudWatchのメトリクスやCloudTrailのイベントを取り込みます。機械学習モデルによってシステムの正常な振る舞いを学習し、そこから外れた挙動を閾値の手動設定なしに検知します。検知した際には、関連する異常や推定原因、対応手順の候補まで提示します。

DatadogのWatchdogやDynatraceのDavis AI、New Relic AIも同様の方向性です。メトリクスやログの基準値を自動学習し、閾値設定の手間なしに異常を検知する機能を備えています。

これらの機能は、すでに主要な監視サービスのほとんどに標準搭載されている、成熟した領域です。普段CloudWatchやDatadogといった監視サービスを利用している場合、気づかないうちにこうしたAIによる異常検知の恩恵を受けていることも少なくありません。

障害対応と一次切り分け

障害が発生した際の一次切り分けも、AIの活用が進む領域です。

第28回で扱ったCloudWatch Logs InsightsやLog Analyticsは、大量のログから必要な情報を検索する機能でしたが、検索条件(クエリ)を組み立てるのは人間でした。

また第29回で触れたように、アラートが発生した瞬間にAIエージェントがログやメトリクスを分析し、原因の候補を提示する動きが広がっています。Log Analyticsの文脈で見ると、この変化は検索条件そのものをAIに組み立てさせる形で現れます。

エンジニアは、検索条件を1から組み立てる代わりに、AIが提示した候補を確認する作業から調査を始められます。

インフラ運用とIaCの変更対応

第15〜18回で解説したTerraformによるIaC(Infrastructure as Code)の運用にも、AIの活用が広がっています。必要なリソースの構成を伝えると、AIがTerraformのコードそのものを生成します。モジュールの雛形やリソース定義を1から書く手間が減り、人間は生成されたコードが要件や既存の構成と整合しているかを確認する作業に集中できます。

Terraform planの実行結果をAIに読み込ませると、その差分が何を意味するのか、既存の構成に対してどのような影響を与えるのかを平易な言葉で説明してもらえます。差分の意味を理解するために公式ドキュメントを読み直す手間が減り、レビューの速度が上がります。

既存のコードベースやTerraformの定義ファイルをAIに読み込ませて、現在のインフラ構成を図として出力させる使い方も広がっています。構成図は本来人間が手作業で作成し、インフラの変更に合わせて更新する必要があり、更新が滞って実態と食い違うことが多い資料でした。AIに都度生成させることで、構成図の鮮度を保ちやすくなります。

ただし、出力の正確性はAIの読み取り精度に依存するため、重要な判断に使う際は実際の構成と突き合わせる必要があります。

セキュリティ運用

第26〜27回で解説したGuardDutyやSecurity Hubは、脅威検知やセキュリティ基準の評価結果をSlackへ通知する仕組みでした。通知された結果に対して、どの指摘から対応すべきかの優先順位付けや、対応内容の洗い出しは人間が行う作業でした。

AIを組み合わせると、検知された指摘内容をAIが読み込み、対応の優先順位や推奨される修正方針を添えてGitHubのIssueを自動で起票する運用が可能になります。セキュリティ担当者はゼロから対応方針を考える代わりに、AIが起票したIssueの内容を確認し、着手する作業から始められます。

運用者の役割はどう変わるか

単純な一次対応や定型的な監視設定の多くをAIが担うようになると、運用者に求められる役割そのものが変化します。IaCの領域では、この変化が最も分かりやすく表れます。

コードを1行ずつ書く作業がAIに移ると、人間の役割は手を動かす部下を持つ立場に近づきます。何を作るべきかを指示し、出てきたコードが設計として妥当か、既存の構成と整合しているかを検証する側に回るのです。第30回で見た開発者の役割の変化、記述者から査読者への移行と同じ構造が、Ops側のインフラ運用にも起きています。

従来、「DevOpsエンジニア」や「運用担当者」という肩書きは、監視設定からインシデント対応、インフラのプロビジョニングまでを広く担う、何でも屋としての役割を指していました。この「何でも屋」としての仕事の多くは、AIによる自動化が進むにつれて縮小しています。

その代わりに進んでいるのが、職種の細分化です。インフラの構築と運用を専門に担う職種、開発者が使う内部プラットフォームの整備を専門に担う職種、セキュリティ対応を専門に担う職種、監視とオブザーバビリティを専門に担う職種などです。かつて1人のDevOpsエンジニアが広く担っていた役割が、複数の専門職に分かれて再編されつつあります。

Gartnerの予測でも、2026年末までに大企業の80%が専任のプラットフォームチームを持つようになるとされ、2022年の45%から大きく増えています。

この流れは、第29回で整理したSREやプラットフォームエンジニアリングという考え方が、DevOpsを置き換えたのではなく具体的な課題解決に応じて深化させた派生形である、という論旨と一致します。AIが単純作業を吸収した結果、残った仕事が専門分化し、SREやプラットフォームエンジニアといった形で結晶化しつつあるのです。

AI活用に必要なスキルも、専門職の基礎的な要件になっています。ログやメトリクスの要約を鵜呑みにせず検証する判断力、AIに読み込ませる構成情報を整理してコンテキストとして渡す設計力は、どの専門職に進んでも共通して求められるようになるでしょう。

AI組み込みの3つのステップ

OpsへのAIの組み込みも、第30回で解説したDev側と同様、一度にすべてを自動化するものではありません。多くのチームは、次の3つのステップを経て成熟していきます。

最初のステップは「個人の生産性向上を目的とした補助ツールとしての活用」です。運用担当者が各自の作業の中でログの解析やコマンドの提案をAIに依頼したり、Terraform planの差分を読み込ませて構成を理解したり、既存の構成から構成図を出力させたりします。この段階の使い方はすでに広く浸透しており、個人の裁量で始められる点が特徴です。

次のステップは「チームのパイプラインに組み込むガードレールとしての活用」です。アラートが発生するとAIが原因を分析し、修正案をPull Requestとして自動で作成し、人間が内容を確認して承認するというパターンがこれにあたります。主要な監視サービスのベンダーがこうした機能を提供し始めており、先進的な企業では実験的な導入や部分的な適用が進んでいます。ただし、まだ業界標準として定着した運用ではなく、どこまで自動化するかはチームごとに判断が分かれる段階です。

さらに進むと「AIが自律的にタスクを進めるエージェント型運用との協調」に入ります。異常の検知から原因の特定、修正案の作成までをAIが自律的に行い、本番環境への適用は人間が承認するという運用です。この段階については原因の調査をAIに任せる部分はすでに実用段階に入りつつある一方、本番環境への修正の自律的な適用はまだ大半のチームで人間の承認を必須としています。

実際、IBMの研究チームが発表したITBenchというベンチマークでは、実世界のSREシナリオ42件に対するAIエージェントの自律解決率を計測しています。最も成績の良いモデルでも完全に自律解決できた割合は13.8%に留まったと報告されており、過度な期待は禁物です。

どのステップまで進めるかはチームの規模やシステムの重要度によって判断が分かれます。Dev側と同様、無理のない範囲から組み込みを広げていくのが現実的です。

おわりに

第30回のDev編と今回のOps編を通じて、開発と運用のそれぞれでAIがどのように組み込まれ始めているかを見てきました。

AIは単純作業の自動化だけでなく、相互理解のための橋渡し役としても機能します。開発者が運用の制約を理解する手助けをしたり、運用者が開発側の意図を把握する手助けをしたりするからです。第29回で述べた「DevとOpsの協調をAIが強化する」という見立ては、DevとOpsそれぞれの現場の変化を踏まえることで、より具体的な形で裏付けられます。

DevOpsが提唱される前、開発と運用は対立する「Dev vs Ops」の構図にありました。DevOpsはそれを「Dev and Ops」という協調関係に変え、本連載はそのための実践的なツールの使い方を解説してきました。AIはこの協調関係をさらに一歩進め、開発と運用の境界をなめらかにしながら、それぞれの役割を専門分化させていく方向に働いています。

本連載を通じて構築してきたDevOpsのサイクルと、そこにAIをどのように組み込んでいくかという視点は、これから先も役立つ土台になるはずです。

次回はいよいよ本連載の最終回です。全31回を通じて構築してきたDevOpsのサイクルを振り返り、連載を締めくくります。