ITインフラの自動化に対するニーズがかつてないほど高まっている。数年前まで、自動化は余裕があれば行うオプションに位置付けられていたが、現在では自社のITインフラにおける最優先課題として取り組む企業が増えているのだ。

背景にあるのは、ITインフラの変化、アプリ開発部門の変化、社会や株主からの要求の変化、社会情勢の変化といった要因だ。中でもレッドハットの中島 倫明氏が強調するのは、セキュリティー分野における規制強化だという。

例えば米国では金融機関に対して公的機関からの監査が強化されており、セキュリティーガイドラインの遵守が今まで以上に求められる。これにはパッチの適用状況も含まれているものもあり、規定に従わなければペナルティが科される場合もある。「このような規制は米国企業だけでなく、米国で営業する外国企業やその取引先にも適用されはじめています。当然、日本企業も例外ではありません」（中島氏）。

それでは、ITインフラの自動化に企業はどのように取り組み、実装を進めていけばよいのだろうか。これについてレッドハットでは、数年前から「インフラ自動化の習熟レベルとマイルストーン」を提示している（図1）。大きく5段階のレベルを設定したもので、AIを活用した自律運用を実現するレベル5は、効率的なインフラ運用の最終到達点とされている。要するにレベル1～4が、そこに至るまでの過程となるわけだ。

図1　自動化の習熟レベルとマイルストーン

ITインフラ自動化の最終ゴールは、AIを活用して自律運用を実現したレベル5だ。ここに到達するためにも、まずはレベル3、4に取り組み、自動化が定着して“当たり前”に行われる状態を築くことが重要となる

レベル1と2は、自動化に対してより積極的な努力が必要な状態だ。これをレベル3や4に進めることで、自動化が定着して“当たり前”に行われる状態となる。「したがってITインフラ自動化に向けて、まず目指すべきはレベル3、4となります。作業のセルフサービス化、CI/CDによる品質担保、自動化前提のシステム運用設計などが、このレベルでの達成目標となります」と中島氏は説く。

「実際に様々な業界の多くの企業が、当社のRed Hat Ansible Automation Platform（以下、Ansible）を活用し、自動化レベル3、4を目指した取り組みを開始しています」と中島氏は3つの典型的なユースケースを挙げる。

1つ目は、「作業のセルフサービス化・API化」である。従来のインフラ業務では、アプリ担当者からの依頼を起点としていた。これを受けてインフラ担当者や運用担当者が部署内で連携や調整、確認を行い、IT基盤に対して作業を実施するという流れだ。自動化が行われるのは、この最終段階のみに限られる場合が多い。Excelの手順書に従って作業を進めていく中で、用意されたスクリプトを流すといったことはその一例だ。

これに対してITインフラ構築・運用のセルフサービス化・API化を実現したレベル3の自動化では、インフラ担当者が直接操作する必要はない。「カタログやワークフローに基づき、仮想サーバーの払い出しやサーバーの再起動、ネットワークのファイアウオール設定などが自動実行されるのです」（中島氏）

2つ目は、「イベント・アラートへの自動対応」だ。これはインフラ自動化のマイルストーンにおけるレベル4に該当する。

現在のシステムはプライベートクラウドやパブリッククラウドなど多様なプラットフォームに分散して運用されており、企業は監視ツールや情報収集・解析ツールを用いて、各システムの状態や稼働状況を監視している。こうした監視や情報収集・解析のプロセスから発生するアラートやイベントを受け取り、その内容に応じた処理をAnsibleで自動的に起動するわけだ。

「例えばサーバーのプロセスがダウンした場合にそのプロセスを再起動する、障害が発生したシステムのログを自動取得してチケットを作成するといった対応を行います。また、不審なアクセスを検知した際には、即座にそのIPアドレスを遮断するルールをファイアウオールに設定することも可能です」（中島氏）

こうしたイベント・アラートへの自動対応を、セルフサービスと組み合わせることで、システム全体の運用はさらに効率化されていく。これが3つ目のユースケース「分断されたプロセス・ツールの結合」である。

「現在は各部署がばらばらのツールを使って、複雑な作業プロセスの連携を人が隙間を埋める形で行っていますが、Ansibleを中心とした一元化を図ることで、サーバーとネットワークを連動させた自動化を実現するほか、人間同士のコミュニケーションやドキュメント作成も自動化することができます。例えば、様々な作業結果を自動的にITSM（ITサービスマネジメント）ツールに格納する、あるいはチケットの承認ワークフローに従ってジョブを自動化するといったことが可能です」（中島氏）

これまでは情報の分断を解消するために、人間が多くのコミュニケーションを重ねて対応してきた。そこにAnsibleを用いてツールとプロセスを統合することで、人間はコードの開発や改修に集中できるようになるなど、自動化による大きな効果が生み出されるのである。

ここまで述べてきたように、まずはレベル3、4の自動化を土台とすることで、企業はAIによるITインフラ自律運用を行うレベル5の自動化に踏み出すことができる。

裏を返せば、最低限でもAnsibleによる作業のセルフサービス化・API化が実現されていなければ、レベル5の自律化には到達できなない。「仮にAIがどれだけ高速かつ高度な判断を行ったとしても、対処を実行するAPIがなければ、結局は人が作業することになってしまうからです」と中島氏は説明する。

それでは、レベル5のAI自律運用が具体的にどんな自動化を実現するのか。ここからはその具体例を見ていこう。

まず、監視ツールが何らかのイベントを検知すると、自動的にサーバーの再起動やログの取得が行われる。ここまでは前述のレベル3、4の状態だ。レベル5では「どの自動化ジョブを起動するのか」といった、対処自体をAIが判断して実行できるようになる。

「検知したイベントが既知のエラーであれば、人間があらかじめつくったルールに当てはめることで対処を自動化できます。未知のイベントが発生した場合でも『AIエージェント』が原因調査を行い、適切な対処方法を考えて実行します。さらにAnsibleの自動化コード生成AIである“Lightspeed機能”を活用すれば、新しいインフラ操作コードをAIが生成し、自動化ジョブに登録することも可能です」と中島氏は、自律運用が確立されていく過程を示す。

もっともAIが勝手に判断し、勝手に生成したコードを動かすことについては、不安を感じる人も多いかもしれない。そこでレッドハットが開発を進めているのが、「Ansible Policy as Code」という新機能だ（図2）。人間が定めたポリシーの中に、どの条件下で自動化を実行できるかをあらかじめ定義しておくことで、危険な操作をブロックするものである。「この機能を併用することで不安を解消し、AIと組み合わせた安全な自律運用を実現できます」と中島氏は話す。

図2　Ansible Policy as Codeの概要

Ansibleの動作をポリシーに基づいて禁止または許可することができる。これにより、AIが勝手に判断し、操作することの「不安」を解消する

なお、Ansible Policy as Codeは既にオープンソース版が利用可能となっており、製品版についても2025年度内にAnsibleに組み込まれる予定だという。今後もレッドハットではAnsibleを軸に企業のITインフラの自動化を支援していく考えだ。