2026 年 7 月 15 日、Red Hat が開催した自動化に関するイベントに参加しました。都合により最後まで聴講できたわけではありませんが、参加したセッションの中で特に印象に残ったのが、AI と融合した自律運用の実現に向けた内容です。
Ansible による構成管理や作業自動化そのものは、すでに新しい話ではありません。しかし、今回の説明は単に「人間が実行していたコマンドを Playbook に置き換える」という範囲にとどまらず、イベント駆動、オーケストレーション、AI による状況評価まで含めて、運用全体をどのように発展させるかを扱っていました。内容を聞きながら、これは私が以前から考えている自動化や AI 活用の構造にかなり近いと感じました。
手動運用から自律運用までを段階的に考える
セッションでは、運用自動化の発展をおおむね次のような段階で整理していました。ここで重要なのは、いきなり AI にインフラストラクチャーの操作を任せる構造ではないことです。
| 段階 | 処理の起点 | 主な役割 |
|---|---|---|
| 手動運用 | 人間 | 手順書を読み、個別にコマンドや GUI を操作する |
| Task-Based | 人間 | 人間が Playbook やジョブを選択して実行する |
| Event-Based | 監視や外部イベント | アラートや状態変化を契機に処理を起動する |
| AI-Driven | AI による評価 | 状況を分析し、実行すべき処理を提案または選択する |
まず、確実に実行できる処理を Playbook として定義します。次に、どのようなイベントが発生したときに、どの処理を起動するかを Rulebook やワークフローとして定義します。その上で、あらかじめすべての条件を列挙することが難しい領域に AI を配置します。つまり、決定論的に処理できる部分を先にコードで閉じ、その外側に AI による評価を追加する構造です。この順序は非常に妥当だと思います。
AI に自由に操作させることが自律運用ではない
AI を運用に導入するという話になると、自然言語で指示すれば AI が自由にサーバーやネットワーク機器を操作してくれる、というイメージが先行しがちです。しかし、実際の運用では、AI が生成したコマンドをそのまま本番環境へ投入するような設計は危険です。生成された処理が正しいかだけでなく、実行範囲、権限、影響範囲、ロールバック方法、監査記録まで考える必要があります。
今回の説明では、AI は主として状況を評価し、実行すべき処理を選択または提案する位置に置かれていました。実際の変更処理は、事前に定義され、検証された Playbook が担当します。処理の構造は、概念的には次の流れとして理解できます。
- 監視や外部イベントを受け取る。
- 対象システム、構成情報、チケット、過去の実行結果など、判断に必要な状況情報を集める。
- ルールまたは AI が状況を評価し、実行候補を選ぶ。
- 承認、権限、ポリシーによって実行可否を判定する。
- 検証済みの Playbook を実行する。
- 結果を確認し、チケットや監査ログへ記録する。
この構造であれば、AI の自由度を制限しながら、固定的なルールだけでは判断できない状況を扱えます。AI に操作方法を毎回生成させるのではなく、AI が選択できる行動を検証済みの処理に限定するわけです。これは自律性を下げているようにも見えますが、実運用では逆です。実行の安全性と再現性が確保されて初めて、人間の介入を減らせるからです。
定数を決めなければ、AI も自動化も成立しない
私は、システム設計では最初に何を固定するのかを決める必要があると考えています。目的、責任分界、正常な状態、許容される変更範囲、失敗時の動作など、本来は定数として扱うべきものを決めないまま、自動化だけを進めても安定した運用にはなりません。すべてを変数として扱えば、実行のたびに人間が判断しなければならなくなります。反対に、判断すべきでない部分まで AI に渡せば、結果の再現性を失います。
今回の内容を私なりに整理すると、各要素の役割は次のようになります。
| 要素 | システム上の役割 |
|---|---|
| Infrastructure as Code | あるべき状態を定義する |
| Playbook | 実行手順を固定する |
| Rulebook | イベントと処理の関係を固定する |
| Orchestrator | 複数の処理と承認を接続する |
| AI エージェント | 固定できない状況を評価する |
| 人間 | 責任や影響の大きい判断を承認する |
AI を導入する前に、AI へ渡してよい変数と、システム側で固定すべき定数を分離しなければなりません。その意味で、今回の内容は「AI ですべてを柔軟にする」という話ではなく、「決定可能な領域を固定した上で、残った不確実性を AI に扱わせる」という設計でした。この点が、私の考え方に近いと感じた最大の理由です。
書籍
Ansible と構成管理の関連書籍を探す
Playbook、構成管理、自動化設計を体系的に確認したい場合の検索リンクです。価格、在庫、内容はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
自動化しても負荷は消えない
自動化の説明では、作業時間の削減や運用効率の向上が強調されます。もちろん、それ自体は間違いではありません。ただし、自動化によって負荷そのものが消えるわけではありません。負荷の置かれる場所が変わります。
手動運用では、担当者が毎回コマンドを入力し、結果を確認することに負荷がかかります。自動化後は、その代わりに次のような作業が必要になります。
- 正常な状態を定義する
- 自動化できる範囲を決める
- Playbook を設計し、検証する
- 例外処理とロールバックを実装する
- 権限と承認経路を設計する
- 実行結果を監査できるようにする
- 環境や製品の変更に合わせてコードを保守する
負荷は、実行作業から設計作業へ移動します。これは悪いことではありません。人間が毎回同じ作業を繰り返すより、最初に設計へ負荷をかけ、以後はシステムが再現可能な形で処理する方が、全体としては合理的です。しかし、自動化によって運用負荷が消滅すると考えると、設計や保守に必要なリソースが見落とされます。AI を導入した場合も同様です。人間の判断負荷を AI へ移したとしても、今度は AI が参照する情報、選択可能な処理、権限、評価方法を設計する負荷が発生します。負荷はなくなるのではなく、より上位のレイヤーへ移動します。
特に興味深かった脆弱性対応のワークフロー
セッションでは、脆弱性対応を自動化する例も紹介されていました。監視製品や ITSM から脆弱性情報を受け取り、AI エージェントが影響範囲や対応方法を分析し、人間の承認後に Ansible が修復処理を実行する流れです。処理後には、チケットの更新や結果の要約まで行います。
従来は、アラート確認、対象機器の調査、影響範囲の確認、対応方法の検討、変更申請、作業実施、結果確認、チケット更新という工程を、それぞれの製品や担当者の間で人間が接続していました。この一連の流れをオーケストレーションし、必要な箇所だけ人間が判断する構造へ変えるわけです。
ここで重要なのは、一つひとつの作業を自動化することではありません。監視、構成情報、チケット、承認、修復、記録という、分断されていた運用プロセスを一つのワークフローとして扱うことです。Ansible は従来、処理を実行するエンジンとして認識されることが多かったと思います。今回の内容では、それをイベントや AI エージェントと接続し、運用判断を含むオーケストレーション基盤へ広げようとしていました。この方向性は興味深いと思います。
AI ファーストとは、何でも AI に任せることではない
私は、企業のシステムや業務は今後 AI ファーストで設計すべきだと考えています。ただし、AI ファーストとは、すべての処理を AI に生成させることではありません。人間が行っている作業をそのまま AI に代行させるだけでは、既存の非効率な業務構造を維持したまま、実行主体だけを変更することになります。
まず、業務や運用を構造化しなければなりません。どの処理は決定論的に実行できるのか。どの処理はイベントを契機に起動できるのか。どの判断には不確実性が含まれるのか。どの判断は責任上、人間に残すべきなのか。それらを分離した上で、AI を適切な場所へ配置する必要があります。
今回の Red Hat の説明は、少なくとも私が参加した範囲では、この順序を外していませんでした。既存の自動化を土台にし、その上にイベント駆動と AI による評価を積み上げています。AI を魔法のように扱うのではなく、システムを構成する一つの判断コンポーネントとして扱っている点は、現実的だと思います。
まとめ
今回のイベントで紹介された内容は、単なる Ansible の機能紹介ではありませんでした。手動運用を Playbook へ置き換え、イベントを起点として処理を実行し、さらに AI による状況評価を加えることで、運用全体を段階的に自律化する構想です。
特に共感したのは、AI を最初から自由な実行主体として置かず、決定論的な自動化を土台にしている点です。自律運用を実現するには、AI の性能だけでは不十分です。あるべき状態、実行可能な処理、権限、承認、例外処理、ロールバック、監査という、地味ですが重要な設計が必要になります。
AI が扱うべきなのは、事前に固定できない部分です。固定できる部分まで AI に判断させる必要はありません。決定できる領域はコードで閉じ、不確実な領域だけを AI に渡す。今回のセッションは、私が以前から考えていた自動化と AI 活用の構造を、Red Hat が具体的な製品やワークフローとして示し始めたものに見えました。途中までの参加ではありましたが、自分の考え方が製品側の方向性とも大きく外れていないことを確認できた、興味深いイベントでした。
参考資料
- Red Hat Ansible Automation Platform
- Red Hat Ansible Automation Platform 2.5 Documentation
- Red Hat Ansible Lightspeed and collaborative automation