Ansibleには実行結果を受け取って処理できるCallback Pluginという仕組みがあります。これを活用すれば、タスク実行時間の計測・Slack通知・実行履歴のDB管理まで、Playbook実行の可視化を設計レベルで制御できます。
この記事では、RHEL 9系~10系(Ubuntu 22.04 LTSでも同様)を想定環境として、Ansible Callback Pluginの仕組みから実践的な設定パターンまでを解説します。
この記事のポイント
・Callback PluginはPlaybook実行イベントを受け取る拡張点。ansible.cfgで有効化できる
・profile_tasksで各タスクの実行時間を計測してボトルネックを特定できる
・community.general.slackでPlaybook完了時にSlackチャンネルへ通知できる
・ARAはPlaybook実行履歴をDBで管理するOSSで、チーム運用の標準ツールとして使われている
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
Callback Pluginが解決する「可視化の問題」
Ansibleを個人の検証環境で使う段階では、ターミナルに流れるログを目で追えば十分です。しかしサーバー台数が増え、チームでPlaybookを実行するようになると、次の問題が浮かび上がります。・誰がいつどのPlaybookを実行したか記録がない
・タスクのどのステップに何分かかったか後から追えない
・失敗通知を見落として翌朝まで気づかない
これらはすべて「実行結果の可視化設計」の問題です。Ansibleのアーキテクチャには、この問題をPlaybookのコードを変えずに解決できる仕組みが最初から組み込まれています。それがCallback Pluginです。
Callback Pluginとは何か
Callback Pluginは、Playbook実行中に発生するイベント(タスク開始・終了・失敗・Playbook完了など)を受け取って任意の処理を行うプラグインです。Ansibleの実行フローを簡単に示すと以下のようになります。
# Playbook実行時のCallback Pluginの呼び出しフロー(概念図) ansible-playbook site.yml を実行 ↓ PlaybookエンジンがイベントをCallbackに送信 ├── v2_playbook_on_start (Playbook開始時) ├── v2_runner_on_ok (タスク成功時) ├── v2_runner_on_failed (タスク失敗時) ├── v2_runner_on_changed (タスクで変更発生時) └── v2_playbook_on_stats (統計情報・Playbook末尾) ↓ 各Callback Pluginが受け取って処理(表示・保存・通知)
ansible.cfg の callbacks_enabled で有効化します。複数のプラグインを同時に有効化でき、それぞれが独立してイベントを処理します。Ansibleに搭載されているCallback Pluginは大きく2種類に分かれます。
・stdout callback:ターミナルへの標準出力フォーマットを制御する。
stdout_callback で指定し、1つだけ有効化できる・aggregate callback:stdout callbackとは独立して動作する追加プラグイン。
callbacks_enabled で複数有効化できる標準搭載Callback Pluginを使う
ansible-coreとcommunity.generalコレクションには、追加インストールなしで使えるCallback Pluginが含まれています。1. ansible.cfgで基本設定をする
Callback Pluginはansible.cfg の [defaults] セクションで設定します。[defaults] # ターミナル出力を見やすいYAML形式に変更 stdout_callback = yaml # 追加のCallback Pluginを有効化(カンマ区切りで複数指定可) callbacks_enabled = profile_tasks
stdout_callback = yaml に設定すると、デフォルトの minimal よりもタスク結果が読みやすい形式で表示されます。2. profile_tasksで実行時間を計測する
profile_tasks プラグインは各タスクの実行時間を計測し、Playbook終了時に時間の長い順に一覧表示します。長時間かかるタスクのボトルネック特定に役立ちます。Playbook実行後、末尾に以下のような一覧が出力されます(出力例・環境により異なります)。
Thursday 06 November 2026 11:30:00 +0900 (0:00:02.312) 0:00:05.401 *** =============================================================================== install nginx ----------------------------------------------------- 2.31s configure nginx template ------------------------------------------ 1.58s start nginx service ----------------------------------------------- 0.80s Gathering Facts --------------------------------------------------- 0.71s
ansible.cfg の pipelining = True や forks 増加と組み合わせることで、実行時間をさらに短縮できます。3. jsonプラグインで実行結果をファイル出力する
json プラグインはPlaybook実行結果をJSON形式で標準出力に流します。リダイレクトと組み合わせることで、後からスクリプトで解析できる機械可読な記録を作れます。# 実行結果をタイムスタンプ付きのJSONファイルに保存する例 ANSIBLE_STDOUT_CALLBACK=json ansible-playbook site.yml \ > /var/log/ansible/$(date +%Y%m%d_%H%M%S).json 2>&1
stdout_callback は1つしか設定できないため、ターミナルで人間向けの出力を見ながら記録も残したい場合は、後述するARAを使う方が実用的です。Slack通知Callback Pluginを設定する
Playbookが完了・失敗した際にSlackチャンネルへ通知するには、community.general コレクションの slack プラグインを使います。1. community.generalをインストールする
# community.generalコレクションをインストール ansible-galaxy collection install community.general
2. Slack Incoming Webhook URLを用意する
Slackの管理画面からIncoming Webhook URLを発行します。このURLはシークレット情報のため、ansible.cfg にハードコードせず、Ansible Vaultで暗号化した変数として管理することを推奨します。Ansible VaultによるシークレットのPlaybook組み込み設計については、Ansibleの構成管理設計の基礎と合わせて習得するとより実践的です。
3. ansible.cfgでプラグインを設定する
[defaults] callbacks_enabled = community.general.slack [callback_slack] webhook_url = https://hooks.slack.com/services/TXXXXXXXX/BXXXXXXXX/XXXXXXXXXX channel = #ansible-notify username = AnsibleBot
ARAでPlaybook実行履歴を管理する
ARA(ARA Records Ansible)は、Playbook実行履歴をSQLiteやPostgreSQLに自動保存し、WebブラウザーやAPIで参照できるOSSです。個人の検証から本番チームの運用管理まで幅広く使われています。1. ARAのインストールとCallback設定
# ARAとAPIサーバーをインストール pip3 install ara[server] # ARAがインストールしたCallback Pluginのパスを確認する python3 -c "import ara; print(ara.__file__.replace('__init__.py', 'plugins/callback'))" # 出力例(環境により異なります) # /usr/local/lib/python3.11/site-packages/ara/plugins/callback
ansible.cfg に設定します。[defaults] # ARAのCallback Pluginのパスを追加 callback_plugins = /usr/local/lib/python3.11/site-packages/ara/plugins/callback callbacks_enabled = ara_default
2. ARA APIサーバーを起動する
# DBの初期化とAPIサーバーの起動 ara-manage migrate ara-manage runserver 0.0.0.0:9191
3. ARAのWeb UIで実行履歴を参照する
ブラウザーでhttp://localhost:9191 にアクセスすると、以下の情報が確認できます。・いつ誰がどのPlaybookを実行したか(実行ユーザー・ホスト名・開始時刻)
・各タスクの成否・所要時間・実際に変更した内容の差分
・ホストごとの実行結果の差異(同じPlaybookを10台で実行した場合の比較)
・gather_factsで収集したホスト情報の変化履歴
jsonプラグインで手動管理するよりもはるかに実用的です。チームでAnsibleを運用する場合の標準ツールとして広く採用されています。
カスタムCallback Pluginを開発する考え方
標準プラグインでカバーできない要件(社内チケットシステムへの自動登録・特定タスクのみ通知など)が出てきた場合は、カスタムCallback Pluginを開発します。開発の基本構造は次のとおりです。
# カスタムCallback Pluginの骨格 # ファイル: callback_plugins/my_custom.py from ansible.plugins.callback import CallbackBase class CallbackModule(CallbackBase): CALLBACK_VERSION = 2.0 CALLBACK_TYPE = 'notification' CALLBACK_NAME = 'my_custom' CALLBACK_NEEDS_ENABLED = True def v2_runner_on_failed(self, result, ignore_errors=False): """タスク失敗時に呼ばれるメソッド""" host = result._host.get_name() task = result.task_name # ここに社内システムへの通知ロジックを書く pass def v2_playbook_on_stats(self, stats): """Playbook終了時に呼ばれるメソッド""" # ここに集計・レポート出力ロジックを書く pass
Callback Pluginは
callback_plugins = ./callback_plugins のようにプロジェクトのローカルディレクトリを指定することもできます。チーム全員が同じバージョンを使うには、Ansible Execution Environmentsにプラグインを含めてコンテナ化するのが確実な方法です。よくあるトラブルと対処
1. callbacks_enabledを設定したのに有効にならない
・コレクション付きのプラグイン名(community.general.slack など)はFQCN形式で指定すること・
callback_plugins パスの設定が正しいか確認する・
ansible-doc -t callback -l で利用可能なプラグイン一覧を確認する# 利用可能なCallback Pluginの一覧を確認する ansible-doc -t callback -l # 出力例(環境により異なります) # ansible.posix.cgroup_perf_recap Profiles tasks and hosts using cgroups # community.general.slack Sends play events to a Slack channel # ara.plugins.callback.ara_default Records Ansible and AWX/Tower data
2. profile_tasksの合計時間と実感が合わない
Gather Factsが時間を消費している場合は、gather_facts: false を設定してfact収集を無効化するか、fact cachingを使って前回収集した情報を再利用します。# ansible.cfgでfact cachingを有効化する例 [defaults] fact_caching = jsonfile fact_caching_connection = /tmp/ansible_facts fact_caching_timeout = 86400
3. ARA APIサーバーへの接続タイムアウトが発生する
ARAのCallback Pluginは起動時にAPIサーバーへ接続します。サーバーが停止していると接続タイムアウトが発生します。接続先URLは環境変数ARA_API_SERVER で指定でき、デフォルトは http://127.0.0.1:8000 です。# 環境変数でAPIサーバーのURLを指定する export ARA_API_SERVER=http://ara.internal:9191 ansible-playbook site.yml
本記事のまとめ
Ansible Callback Pluginを目的別にまとめます。| 用途 | 使うプラグイン | 設定箇所 |
|---|---|---|
| 実行時間の計測 | profile_tasks |
callbacks_enabled = profile_tasks |
| 出力フォーマット改善 | yaml |
stdout_callback = yaml |
| JSON形式で結果保存 | json |
stdout_callback = json(リダイレクトと組み合わせる) |
| Slack通知 | community.general.slack |
callbacks_enabled = community.general.slack |
| 実行履歴のDB管理 | ARA(ara_default) | pip3 install ara[server] → callback_pluginsに追加 |
| カスタム通知・連携 | 自作Callback Plugin | CallbackBaseを継承してv2_runner_on_*を実装 |
profile_tasks と stdout_callback = yaml から始め、チームの規模が大きくなったらARAの導入を検討するのが実践的な道筋です。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:Ansibleのネットワーク自動化入門|ansible.netcommonとios_commandでLinuxサーバーと機器設定を統一管理する設計
- この記事の属するカテゴリ:Ansibleへ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます