IT運用自動化を組織全体へ広げるAnsible活用戦略──AIを制御する「インフラ共通基盤」の真価

人材流出を招くIT運用の限界──今、自動化が急務な理由

　清水氏は「今、IT運用の自動化が必要な理由」について、現代のシステム環境の構造的な変化から説明した。現在のITシステムは、コンテナやマイクロサービスの普及によって規模が巨大化し、複雑性も飛躍的に増しており、数百～数千のコンポーネントで構成されることも珍しくない。こうした環境を人手で管理する運用は、すでに限界に近づいている。

　ビジネス部門側からIT部門に求められるスピードも大きく変化した。かつては仮想マシンの調達に1～2週間を要していたが、現在ではオンデマンドで即時利用できることが当たり前となっている。

　ただ、問題はスピードだけではない。こうした手作業中心の運用はリスクの要因にもなる。「大規模障害の多くは『マニュアルでの設定変更』や『イレギュラーな手順』に起因している。手作業による運用そのものが重大なリスクになっているのが現状だ」と清水氏は指摘する。

　加えて、セキュリティとコンプライアンス対応の負荷も増大。脆弱性への迅速なパッチ適用や証明書管理、監査対応などが継続的に求められ、インフラの拡大とともに運用はさらに複雑化している。

　さらに、IT部門の深刻な人材不足が問題をさらに悪化させている。熟練エンジニアの属人化やトイルの増加によって彼らの負担は増大し、離職のリスクにつながりかねない。また、設定ミスによる無駄なリソース消費がクラウドコストの増大を招くといった問題も看過できない。

　これらの結果として、「スピード低下」「リスク増大」「コスト増」「人材流出」が互いに影響し合う悪循環に陥ってしまうのだ。清水氏は、この状況から脱却するためには「運用の在り方を根本から見直し、自動化へ舵を切ることが急務だ」と訴える。

トリガーは「タスク」から「イベント」へ。“フルスタック・インフラ自動化”へのアプローチ

　人依存のマニュアル運用から脱却した「自動化されたIT運用」とは具体的にどのようなものか。従来の運用では、変更や作業のたびにチケットやメールでIT部門へ作業申請が飛び、担当者のアサインまでに待ち時間が発生していた。IT部門は手順書を参照しながらコマンド入力やGUI操作で作業を進めるが、手順外のノウハウは個人の“暗黙知”に依存し、ミスや属人化を排除することが難しい。こうした状況下では、障害対応も発生後に人が対処するリアクティブなものになりがちだ。

　対して、自動化された運用では人がインフラを直接操作することはない。インフラの“あるべき状態（意図）”をコードとして定義し、システム変更や障害といったイベントをトリガーに、定義済みのポリシーやルールに基づいてシステムが自律的に処理を実行する形だ。

　手順やワークフローはAPIドリブンで動作し、コードとしてバージョン管理されるため、属人化した暗黙知を大きく減らせるメリットがある。人が定義した“あるべき状態”をシステムが継続的に維持するため、障害対応も予防や自動復旧を前提としたプロアクティブな運用へと移行することができるのだ。

IT運用を自律型へ変革する3ステップとは

　清水氏は、IT運用における人の介在を減らし、運用の自律性を高めていくための段階的な進化について下図を示して説明した。

　初期段階は「セルフサービス化」だ。利用者がポータルやGitを通じて要求を発行すると、自動化処理が実行され、VM作成やネットワーク設定、ソフトウェア導入などが行われる。これにより、チケットやメールのやり取りにともなう待ち時間が解消され、利用者だけで一連の手続きを完結できるようになる。

　次の段階は「スケジュールベースの自動化」。証明書更新や設定監査などの定期的に発生する作業を自動実行することで、エンジニアはリアルタイム対応から解放され、結果確認に専念できる。

　最終段階は「イベント駆動（Event-Driven）の自動化」である。監視やログ、セキュリティアラートといったイベントをリアルタイムに処理し、システムが自動で評価／しかるべき対応を判断して復旧対応やパッチ適用、インシデント起票などを実行する。これにより、一次対応から人手を排除し、インフラが自律的に状態を維持／回復する運用が実現する。

　清水氏は、こうした自動化の取り組みをサーバー単体などの個別最適にとどめるのではなく「ネットワーク／ストレージ／クラウド／サイバーセキュリティ／ITSMを含めた『フルスタック・インフラ自動化』へ拡張することが重要だ」と強調する。

自律運用を支える「Red Hat Ansible Automation Platform」の価値

　IT運用の自動化を組織全体に適用するためには、インフラを一元的に扱える共通基盤が欠かせない。その役割を担うのが「Red Hat Ansible Automation Platform（AAP）」だ。AAPは、オープンソースの自動化ツールである「Ansible」をベースとし、企業における運用とガバナンスを一体で扱えるよう設計されたプラットフォームである。

　Ansibleは構成管理ツールとして進化を続けており、現在では主要アナリストからインフラ自動化分野のリーダーに位置づけられている。その基盤上に構築されたAAPが支持される理由について、清水氏は「自動化対象の幅広さと強力なエコシステムにある」と述べる。OSやサーバーに加え、ネットワーク機器、ストレージ、サイバーセキュリティ製品、Kubernetes、パブリッククラウド、エッジまで幅広く対応しており、その基盤となるのが豊富なコンテンツコレクションだ。認定済みコレクションは200以上、パートナー企業も80社以上にのぼる。

　Ansibleの自動化のアクションは、「Playbook」と呼ばれるYAML形式のテキストファイルに記述される。たとえば、対象のWebサーバーに対して、パッケージをインストールして設定ファイルを配置し、サービスを起動するという一連のあるべき状態の流れを、人間にとっても可読性の高いコードとして定義できる。

　Playbookの作成／実行が各エンジニアのローカルマシンにおけるコマンドライン環境にとどまっているうちは、組織的な自動化とはいえない。小規模な環境やステージング環境であれば十分に機能するが、エンタープライズ組織全体で安全に自動化をスケールさせるためには、ガバナンスとコントロールを提供するプラットフォームが必要となる。その役割を担うのがAAPだ。

　AAPは、システム全体のオーケストレーションと統制を行う「コントロールプレーン」と、実際にPlaybookを実行する「エグゼキューションプレーン」に分離されたアーキテクチャを採用している。コントロールプレーンの中核を担うのは「Automation Controller」というコンポーネントだ。

　Automation Controllerは直感的なWeb UIとAPIを備え、RBAC（ロールベースアクセス制御）／監査ログ／認証情報／ジョブスケジューリングなどの運用機能を一元的に扱える。Playbookはジョブテンプレートとして登録し、権限設定に基づいて安全に実行できるほか、複数のジョブを連結したワークフローも定義できる。

　自律運用の中核となるイベント駆動の自動化を実現する仕組みとして、AAPには「Event-Driven Ansible（EDA）」が統合されている。EDAは、監視ツールやセキュリティ製品からのイベントをリアルタイムに受信し、ルールに基づいて評価／判断したうえで、対応するジョブを即座に実行するもの。これにより、人手を介さずにシステムが自律的に状況を判断し、回復処理が可能となる。

　清水氏は、AAPを共通基盤として活用することで、単なる作業削減にとどまらないIT運用の変化が生まれると強調する。

　「AAPを活用することで、リアクティブな対応が中心の運用から、事前に自動化を設計するプロアクティブな文化へと転換させることができ、標準化やオンボーディング、障害対応の効率も向上します。また、自動化された共通パイプラインへの移行によって属人化が解消され、組織のサイロ化抑制にも期待できます」（清水氏）

AIと融合した自律運用プラットフォームの未来と注意点

　IT運用の自律化を進めるうえで鍵となるのが、イベント発生時の評価／判断をどのようにAIで実装するかという点だ。セッションの後半では、自動化とAIの融合について解説がなされた。

　清水氏は、イベント時の評価／判断の実装方法として大きく2つのアプローチを挙げる。1つは従来の「決定論的（Deterministic）なアプローチ」で、想定される条件やエラーパターンを事前に網羅し、“if-then”のルールとしてPlaybookやルールブックに定義する手法だ。確実性が高い一方で、インフラの複雑化にともない、その網羅的な定義を人手で維持し続ける負担は大きくなる。

　これに対し、LLMの発展により実用段階に近づいているのが「エージェント型アプローチ」だ。発生した事象やインフラの状態をAIに読み込ませ、次のアクションを動的に推論／決定させることで、従来のような詳細な事前定義の負担を軽減する効果が期待されている。

　レッドハットはAAPの次世代機能として、このエージェント型アプローチの実装を進めており、自動化ワークフローに生成AIエージェントを組み込める新機能「Ansible Automation Orchestrator」のリリースを予定している。

　このエージェント型アプローチの具体像として、セッションでは深刻な脆弱性が本番環境で発見されたことを想定したデモが行われた。監視ツールが脆弱性を検知すると、その情報をトリガーにAAPがインシデントチケットを自動起票し、AIエージェントが影響範囲の特定とパッチ適用計画（段階適用やロールバックを含む）を立案する。その計画を人が承認した後、自動でパッチ適用とチケット更新が行われ、最後に対応内容のサマリーレポートが生成されるまでの一連の流れが示された。

　こうした高度な自動化を実現するためには、AIの活用について慎重な設計が必要だ。「AIエージェントによる推論は自動化に有効である一方、インフラ変更やパッチ適用といった影響の大きい変更作業を完全に任せることはリスクが高い」と清水氏は指摘する。

　そのため、AIの判断には必ず人の承認プロセスを組み込み、RBACや認証情報管理、監査ログといったAAPの統制機能の下で実行することが欠かせない。AIを組織のガバナンスの枠組み内で適切に制御することが、自律運用の前提になるという。

まずは「タスクの自動化」から──次世代IT運用に向けた必須科目とは

　セッションの締めくくりとして、清水氏はこれからのITインフラ自動化に向けた戦略的な展望を述べた。

　「AI時代のIT運用においては、システム構築（Day1）の自動化だけでなく、日々の運用やトラブルシュート、セキュリティ対応といったDay2オペレーションをいかに自律化できるかが重要なテーマになってくるでしょう。Day2オペレーションには、イベント駆動型の自律運用に向いた作業が多く含まれているため、今後より注力する必要があると考えています」（清水氏）

　とはいえ、明日からすぐにAIエージェントを組み込んだ自律運用を始められるわけではない。清水氏は「まずは、人がトリガーとなる“タスクベースの自動化”を着実に現場で実装し、自動化の実績を作ることから始めるべきだ」と主張する。そのうえで、インフラのあるべき状態を正しく定義し、構成ドリフトを防ぐための大前提として、組織全体でGitとIaC（Infrastructure as Code）を共通の必須科目として習得／定着させることが、強固な土台づくりにつながると強調した。

　こうした土台が整って初めて、その上に生成AIやAIエージェントを組み合わせることができるようになる。AIの活用により、これまで負担となっていた複雑なルールの事前定義を簡素化し、重大なインシデント対応における不要な人手を減らすことで、より高度な自律運用へと変革できるのだ。