Open source software Red Hat Ansible Automation Platform
レッドハット製品
VERSION 2.7 · 提供中
組織全体を貫く自動化基盤
インフラ、ネットワーク、セキュリティ、クラウドまで。「作る・管理する・拡張する」をひとつのプラットフォームで実現するエンタープライズ自動化基盤です。
ーOverview
エンタープライズ自動化の統合プラットフォーム
Red Hat Ansible Automation Platform（AAP）は、Ansible による自動化を組織全体で「作成・管理・拡張」するための統合基盤です。シンプルな YAML で書ける Playbook を核に、複数ドメインにまたがるワークフローを一貫した方法で自動化し、ガバナンスとスケールを両立します。
- 作成する（Create）
- 再利用可能なコンテンツと実行環境で、標準化された自動化を素早く開発。信頼できる認定コンテンツも活用できます。
- 管理する（Manage）
- 統一UI（platform gateway）と RBAC で、ジョブ・認証情報・権限を一元管理。監査性とガバナンスを確保します。
- 拡張する（Scale）
- Automation mesh とコンテナ実行環境で、データセンターからクラウド、エッジまで自動化をスケールします。
ーMotivation / なぜ自動化するのか
なぜ、いま自動化なのか
AI・エッジ・ハイブリッド環境を支えるインフラ投資が急拡大し、その規模と複雑性は人手の限界を超えつつあります。セキュリティ・ガバナンス・ポリシー適用のスピードを保つには、プラットフォームとしての「自動化」が不可欠です。
従来の目的：QCDの向上と人材不足への対応
- Quality（品質）：設定ミスや不良率を削減し、稼働を安定化。
- Cost（原価）：定型作業の省力化で労務コストと無駄を削減。
- Delivery（納期）：インフラ構築時間を短縮し、ビジネス要求に即応。
- 人材不足：減少するインフラエンジニアの負荷を軽減。
2026年の変化：複雑性の爆発とAIOpsへ
- AIインフラ投資の急増：GPU・分散インフラの管理が必須に。
- 手動運用の限界：ハイブリッド／マルチクラウドの混在で、CLI手作業は不可能なレベルへ。
- AI駆動・自律運用の時代：自動化を「省力化」からAIOps の共通ガバナンス基盤へ再定義。
- Ansible の役割：AIの判断を安全・正確に反映する「実行エンジン」。
ーAutomation 2.0
AAP が実現する「自動化 2.0」
手順の置き換えから、コミュニケーションを含むサービス化へ。単なる作業の自動化から、依頼・調整・実行までを含む自動化へ進化します。
自動化 1.0（これまで）
着目点：人間が実行する手順
手順書 →作業者 →ツール/スクリプト → インフラ環境
ー 手順の実行をツールやプログラムに置き換え
ー 作業工数の削減が主目的
ー 自動化が担当者依存になりやすい
ー 依頼・調整・確認のやり取りは残りやすい
属人化サイロ化再利用しにくい横展開しづらい
自動化 2.0（これから）
着目点：コミュニケーションとサービス化
依頼者 →セルフサービス/API/カタログ →Controller/Playbook/Workflow → インフラ環境
ー 人と人のやり取りをツールに置き換え、情報伝達の量を削減
ー Playbook をサービス化・API化して再利用
ー ワークフローや承認を含めて標準化
ー セルフサービスとイベント駆動で自動実行へ
セルフサービスAPI化ワークフローEvent-Driven Ansible 標準化
さらにその先では、監視・AI分析・自動実行・学習改善をつなぐ AIOps（AI駆動の自律運用）へ。AAP はその「信頼できる実行基盤（Trusted Execution Layer）」として、AI の判断を安全・正確に反映します。
ーComponents
主要コンポーネント
CONTROLLER
Automation Controller
Playbook の実行・スケジュール・ジョブ管理・RBAC を担う中核。API と GUI で自動化を制御します。
HUB
Automation Hub
認定コンテンツとプライベートコンテンツの配信・管理。信頼できる Collection を組織内で共有します。
EDA
Event-Driven Ansible
イベントを起点に自動対応を実行。監視やアラートと連携し、運用の自律化（自己修復）を実現します。
AI
Ansible Lightspeed
生成AIによるコンテンツ生成とインテリジェントアシスタント。自然言語で Playbook 作成や運用を支援します。
GATEWAY
platform gateway
全コンポーネントを束ねる統一UIと共通認証・RBAC。単一の入り口で一貫した操作性を提供します。
EXEC ENV
実行環境 / Automation mesh
コンテナ化された実行環境と分散実行基盤。環境差を排し、大規模・分散環境へ自動化を届けます。
ーUse Cases
主なユースケース
TOP TOPIC
証明書の更新 ── 有効期間「47日」時代へ
TLS証明書の有効期間は段階的に短縮され、2029年3月には最長47日に。年1回だった更新は年8回以上に増え、手作業での運用は非現実的です。自動化された証明書更新の仕組みが不可欠となり、自動化需要の拡大を牽引しています。
現在
2026
2027
2029
01
構成管理
サーバー・OS設定をコード化し、一貫した状態を維持します。
02
プロビジョニング
クラウド／仮想／物理のリソース展開を自動化します。
03
ネットワーク自動化
マルチベンダーのネットワーク機器を横断的に自動運用します。
04
セキュリティ自動化
パッチ適用・調査・対応を自動化し、対応時間を短縮します。
05
RHEL 運用連携
RHEL のパッチ適用・設定を自動化し、大規模運用を効率化します。
06
イベント駆動の自律運用
監視イベントを起点に、検知から復旧までを自動実行します。
ーDeployment
提供形態
インフラに合わせて、セルフマネージド（RHEL）または OpenShift Operator を選択できます（AAP 2.7）。
RHEL
セルフマネージド（コンテナ）
RHEL 9.6 以降または RHEL 10 上に、Podman ベースの rootless コンテナとして導入。2.7 では新規はコンテナ化インストーラーに統一されています。
OPENSHIFT
OpenShift Operator
OpenShift Container Platform 4.14〜4.22 に Operator で導入。platform gateway 統一UIで、ライフサイクル管理とスケールを簡素化します。
※ AAP 2.7 では RPM インストーラーは廃止されました。2.6 以前の RPM 環境からは、コンテナ化または OpenShift への移行が必要です。動作要件・対応バージョンは Red Hat のドキュメントをご確認ください。
特集
『RHEL Forever』── 延長ライフサイクルという選択肢
移行できない基幹資産は、止めなくていい。ELC で最長14年、Long-Life Add-On なら期限を定めずに RHEL を使い続けられます。計画の立て方を図解で解説します。
OSSに関するお問い合わせ
サイオステクノロジーがご提供する製品・サービスのお問い合わせはこちらからお送り下さい。