はじめに
AIを業務で使用する話をすると、議論が合わないことがあります。
片方は「AIが自律的に判断して直してくれる世界」を語っていて、もう片方は「AIに調べてもらって最後は自分で確認する」話をしている。どちらも「AIを使う」なのですが、人がどれだけ関与するか が違う。
同じ言葉で違う話をしているのでかみ合いません。
この記事は2部構成です。自身の考えをもとにAIで整理、補足してもらった内容で書いています。
- 前半：AI活用を「人の関与度」で5段階に整理してみます
- 後半：Red Hat公式のMCPサーバーを使って、AAP上のF5 BIG-IP証明書更新ワークフローの設定を実際に確認します。5つの質問だけで設定ドリフトが見つかった実際の画面付きで、「レベル1＝人のための補助ツール」の実務効果を見ていきます
動画
本記事の動画を作成しました。理解の一助にご参照ください。
AI活用の「人の関与度」5段階
なぜ「段階」で考える必要があるのか
自動運転にレベル0〜5があるのは、「自動運転できる/できない」の二択では現実を説明できないからです。
ハンドルは人が握るがブレーキは車が踏む、高速道路だけは車に任せる——実際には無数の中間があります。
AI活用もまったく同じです。「AIを導入した/していない」の二択で語ると重要な問いが抜け落ちます。
その作業で、最終的に責任を持って判断するのは誰か。
この問いを軸に5段階に整理してみます。
5段階の整理
| Lv | 呼び方 | AIの役割 | 実行するのは | 人の位置 | インフラ運用での例 |
|---|---|---|---|---|---|
| L0 | 手動 | なし | 人 | 全工程 | ドキュメントを読み、GUI/CLIを自分で叩く |
| L1 👈 本記事 | 参照補助 | 調べる・要約する | 人 | 全判断 | AIにAAPの現在の設定を聞き、自分で確認して直す |
| L2 | 提案・下書き | 案を作る | 人（承認後） | 承認者 | AIがPlaybookや変更手順を書き、人がレビューして実行 |
| L3 | 監視付き実行 | 決めて実行する | AI（範囲は人が事前定義） | 監視・停止 | 承認ゲート付きでAIがジョブを起動、人はログで追う |
| L4 | 自律 | 決めて実行して完了報告 | AI | 事後確認のみ | 検知→修復→報告を人手なしで回す自動修復ループ |
「AIがAIを使う」という話題でよく想像されるのはL4です。そして話題になりやすいのもL4です。
しかしながら現場の大部分の仕事は今のところL1とL2にあります。 そしてそれは、後れを取っているという意味ではありません。
この記事で扱うのはL1です。 エージェントが自律的に本番を直す話ではありません。読み取り専用のAPIトークンでAIに設定を聞く内容です。
手元で始められて、失敗しても何も壊れない範囲 の話をします。
レベルは「製品の属性」ではなく「作業の属性」
ここがいちばん誤解されやすいところです。
L4対応のすごいツールを買ってきても、現場が自動的にL4になるわけではありません。逆に、同じツールでも作業単位でレベルは変わります 。
後半で扱うAAPのMCPサーバーがまさにそうで、同じサーバーが
- 設定を読むだけに使えばL1（人の補助ツール）
- ジョブの起動を許可すればL3（AIが本番環境に触る）
になります。ツールが決めるのではなく、どの権限を渡すかを人が決めている。
だからレベル選定は、「うちはどのレベルを目指すか」ではなく、「この作業はどのレベルでやるか」 という粒度で考えるべきものです。
レベルを決める判断軸：可逆性
では作業ごとに何を基準に決めるか。私は 可逆性（元に戻せるか） が最も実用的な軸だと思っています。
| 読み取り | 書き込み・実行 | |
|---|---|---|
| 間違えたときのコスト | AIの答えが違っても、人が気づけば終わり | 本番環境が壊れる。ロールバックが要る |
| 検証のしやすさ | 元データと突き合わせればすぐ分かる | 実行してからでは遅い |
| 適したレベル | L1〜L2 | L2〜L3（承認ゲート必須） |
AIの出力には、依然としてハルシネーションのリスクがあります。
ここで大事なのは「だからAIを使わない」ではなく、「間違いが検出できて、かつ安く済む場所から使う」 という発想です。
読み取り作業は、この条件を完璧に満たします。
AIが「ジョブテンプレートは37個です」と答えて、それが違っていても、画面を見れば5秒で分かるし、何も壊れません。(AIへの信頼度がちょっと下がるかもしれません)
もうひとつの軸：そのAI、見えていますか
ここまでは「人がどれだけ関与するか」の軸で話してきました。
これと直交するもう一本の軸があります。そのAIが使う人から見えているかどうか です。
この記事のように自分でMCPサーバーを設定してAIに質問しているとき、AIは完全に見えています。何を聞いて、何が返ってきて、どのツールが呼ばれたか、全部画面に出ている。
しかし、世の中で動いているAIは、そうではないことがあります。
- メールのスパム判定、優先度の並べ替え
- 監視ツールの「アラートノイズ削減」機能
- クラウドのオートスケーリングや異常検知
- ストレージの自動階層化、ジョブスケジューラの最適化
- 問い合わせフォームの一次回答
- 書類選考、与信判断
これらの多くは、「AIを導入する」という明確な意思決定を経ていないことがあります。
ある日ベンダーのアップデートで入ってきて、リリースノートの片隅に一行書いてある。
使う側に自覚はありません。
2つの軸を組み合わせると、こうなります。
| 見えている | 見えていない | |
|---|---|---|
| 人が判断（L1〜L2） | この記事の領域。いちばん安全 | 気づかないうちにAIの要約を鵜呑みにしている |
| AIが実行（L3〜L4） | 承認ゲートと監査ログで追える | リスクが高い。何が起きたか追跡しにくい |
「AIがAIを使う」世界が怖いとしたら、それは自律だからではなく、自律かつ見えないから です。
逆に言えば、見えてさえいれば(制御できるものであれば）、L3やL4もそれほど恐ろしいものではありません。
自分が「見えないAI」を作る側になる
AAPのactivity streamに残るのは、「そのトークンで実行された」という記録だけです。
人が画面から押したのか、AIがMCP経由で叩いたのかは、ログを見ても区別がつきません。
今日は自分ひとりで使っているから分かります。
では半年後、そのトークンがチームの共有アカウントになっていて、誰かがAIエージェントに渡していたら？
「あのジョブ、誰が起動したの？」に答えられない状態 が、いつのまにか完成しています。
対策はL1の段階でやっておくべきものです。
- AI用のサービスアカウントを、人間用と分ける
-
名前で分かるようにする（
svc-ai-readonlyのように） - そうすればログを見た瞬間に「これはAI経由だ」と判別できる
L3になってからでは間に合わないことがあります。
まだ読み取りしかしていない今のうちに、AIの足跡が残る形にしておく。これは権限の話ではなく、後から説明できる状態を作る という話です。
見えないAIそのものが悪いわけではありません。スパムフィルタにいちいち承認を求められても困ります。
ただ、「これは見えないままでいいAIか」を一度は問う。
その判断を人がしている限り、見えないAIも人の管理下にあります。問わないまま増えていくのがいちばん避けたい状態です。
L1をあなどらない
L1は「AIの入り口」であって「AIの練習」ではありません。L1にしかない価値があります。
- 文脈をまたいで探せる：「このジョブテンプレートが使っているインベントリのホスト数と、割り当てられている認証情報の種類を教えて」——GUIなら3画面、APIなら3リクエスト。これが1回の質問で終わる
- 答えの検証コストが低い：出典（どのAPIを叩いたか）が示されるので、疑わしければ自分で確認できる
- 監査の観点で説明しやすい：読み取りしかしていないので、「AIが本番に何をしたか」という説明責任が発生しない
L1で運用に慣れ、AIの答えの精度と癖が体感的に分かってから、L2、L3に上げていく。この順序を飛ばすと、事故ったときに「AIのせい」なのか「渡した権限の設計ミス」なのかすら切り分けられません。
AAP MCPサーバーで設定内容を確認する
ここからは、L1の具体例を見ていきます。
MCPとは（30秒で）
Model Context Protocol（MCP）は、AIツールと外部システムをつなぐためのオープンな標準規格です。従来はAIごと・サービスごとに独自のAPIラッパーを書く必要がありましたが、MCPサーバーを1つ立てれば、Claude / Cursor / 自作エージェントなど、MCP対応のクライアントすべてから同じように使えます。
AAPにとって重要なのは、MCPサーバーがAAPのAPIの前に立つのであって、AAPを迂回するわけではないという点です。認証もRBACもAAP側の仕組みがそのまま効きます。
AAP MCPサーバーの構成
Red Hatは AAP 2.6.4 からテクノロジープレビューとして公式のMCPサーバーを提供しています。AAP 2.7 では Technology Preview の一覧から外れており、正式機能として扱われているようです（コンテナ版・OpenShift Operator版の両方でデプロイ可能）。
- 発表：https://www.redhat.com/en/blog/it-automation-agentic-ai-introducing-mcp-server-red-hat-ansible-automation-platform
- ドキュメント：https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/extend-assembly_deploying_ansible_mcp_server
- ソース：https://github.com/ansible/aap-mcp-server
提供される6つのツールセット：
| ツールセット | できること |
|---|---|
job_management |
ジョブテンプレートの一覧、ジョブの起動、実行状況の確認 |
inventory_management |
インベントリ・ホスト・グループ・ホストファクトの照会 |
system_monitoring |
ログ取得、失敗調査、ヘルスチェック、ping、activity stream |
user_management |
ユーザー・チーム・組織・ロールの管理 |
security_compliance |
認証情報の管理（シークレットは露出させない） |
platform_configuration |
プラットフォーム構成の確認・調整 |
内部的には Controller / Gateway / Galaxy / EDA の各APIのOpenAPI仕様からツールが生成され、controller.jobs_read のような {service}.{operation} 形式の名前を持ちます。
主な設定項目：
| 変数 | 意味 | デフォルト |
|---|---|---|
BASE_URL |
AAPのURL | — |
BEARER_TOKEN_OAUTH2_AUTHENTICATION |
認証トークン | — |
MCP_PORT |
待ち受けポート | 3000（AAP同梱時は8448） |
ALLOW_WRITE_OPERATIONS |
書き込み操作の許可 | false |
ENABLE_METRICS |
Prometheusメトリクス | — |
出典：https://github.com/ansible/aap-mcp-server
（ポート8448はAAP同梱デプロイ時の値：https://techbeatly.com/claude-code-ansible-automation-platform-mcp-server/ ）
今回のユースケースでは ALLOW_WRITE_OPERATIONS は false のままにします。 これがL1の技術的な担保です。
セットアップ
1. トークンの発行
AAPの Access Management > Users から API トークンを発行します。
ここで スコープを Read に絞る ことで読み取り専用操作のみの権限となります。
MCPサーバー側の ALLOW_WRITE_OPERATIONS=false と、トークン側の Read スコープ。
二重に読み取り専用を担保 します。片方の設定ミスでもう片方が効く、という多層防御の考え方です。
2. MCPクライアントへの登録
今回のクライアントは IBM Bob です。Bobの場合、MCPサーバーの定義は mcp.json に書きます。
- グローバル設定：
~/.bob/mcp.json（全ワークスペース共通） - プロジェクト設定：
<プロジェクトルート>/.bob/mcp.json（チームで共有可能）
Bobのパネルから 設定アイコン → MCP タブ → 「Edit Global MCP」でも編集できます。
出典：https://bob.ibm.com/docs/ide/configuration/mcp/mcp-in-bob
AAP MCPサーバーはHTTPで待ち受けるので、streamable-http で登録します。
{
"mcpServers": {
"aap-mcp-server": {
"type": "streamable-http",
"url": "https://<aap-host>:8448/mcp",
"headers": {
"Authorization": "Bearer <read-only-token>"
},
"disabled": false
}
}
}
/mcp は全ツールセットをまとめて公開するエンドポイントです。用途が決まっているならツールセット単位で登録するほうが軽くなります。
{
"mcpServers": {
"aap-job-mgmt": {
"type": "streamable-http",
"url": "https://<aap-host>:8448/job_management/mcp",
"headers": { "Authorization": "Bearer <read-only-token>" }
},
"aap-inventory": {
"type": "streamable-http",
"url": "https://<aap-host>:8448/inventory_management/mcp",
"headers": { "Authorization": "Bearer <read-only-token>" }
}
}
}
ツールセットを絞るのはトークン消費の観点でも効きます。6つ全部つなぐと、ツール定義だけでコンテキストをかなり食います。
なお、MCPクライアントはBobに限りません。MCPは標準規格なので、Claude / Cursor / 自作エージェントなど、対応クライアントであれば同じMCPサーバーをそのまま使えます。設定の書き方が違うだけです。
セットアップの詳細手順について
MCPサーバーをローカル（stdio接続）で起動する方法や、aap-mcp.yamlの各パラメータの設定例、IBM Bobとの接続確認手順については、以前の記事に詳しくまとめています。本記事ではRead専用トークンを使用していますが、前回記事では検証目的でWrite権限を使用しています。
→ IBM Bob × MCP連携の実践：Ansible Automation Platformを日本語で操作
3. alwaysAllow ——ここがレベルの分かれ目
Bobの mcp.json には alwaysAllow というキーがあります。ここに書いたツールは、確認プロンプトなしで自動実行されます。
"alwaysAllow": ["controller.jobs_read", "controller.hosts_list"]
前半の話が、ここで設定ファイルの一行として現れます。
-
alwaysAllowに何も書かない → ツールを呼ぶたびに人が確認する（厳密なL1） - 読み取り系だけ書く → 調査はサクサク進み、それ以外は人が止める（実用的なL1）
- 書き込み系まで書く → AIが確認なしに本番を触る（L3）
今回は読み取り専用トークンなので、読み取り系を alwaysAllow に入れています。毎回確認を押していては調査になりません。ですが、書き込みトークンに切り替える日が来たら、この配列を必ず見直す。ここを忘れたまま権限だけ上げてしまうと、意図しない動作につながりやすくなります。
レベルは、思想ではなくJSONの1行で決まります。
4. 自己署名証明書の場合
検証環境で自己署名証明書を使っているなら、MCPサーバー側の aap-mcp.yaml に以下を設定します。
ignore-certificate-errors: true
検証環境限定の設定です。 本番では正規の証明書を使ってください。
実際にやってみる：BIG-IP証明書更新ワークフローの棚卸し
ここからは実際の画面です。題材は、F5 BIG-IPのSSL証明書を自動更新しているワークフロー。 「そういえばこれ、どういう設定にしたんだっけ？」 という、運用でいちばん頻繁に発生する問いから始めます。
半年前に自分で作ったものでも、記憶は曖昧です。GUIを開いて確認していくのが従来のやり方ですが、これをAIに聞いてみます。
ステップ1：どのテンプレートが本番なのか
私：bigip 証明書発行のワークフロージョブ名を教えて
いきなり収穫がありました。同じ名前のワークフローが2つある。
| ID | 名前 | 状態 |
|---|---|---|
| #322 | 0_BIG-IP_証明書更新ワークフロー @ 18:02:18 |
実際に使われているメイン。手動実行のみ。最終実行 2026-06-16 |
| #306 | 0_BIG-IP_証明書更新ワークフロー |
元テンプレート。次回スケジュール 2026-09-20 00:30 UTC あり |
しかもAIは実行履歴まで突き合わせて、 「実際のジョブは全て #322 で実行されている」「#306 はスケジュールが仕込まれているオリジナル版で、#322 は extra_vars: "target_hosts: bigip" が追加されたコピー版」 という関係まで整理してくれました。
これは見落としがちですが、注意が必要な状況です。 手で動かしているのは #322、スケジュールで動くのは #306。 片方にだけ入っている extra_vars が、スケジュール実行時には効かない。設定ドリフトそのものです。
GUIで気づけるかというと——ワークフロー一覧を開いて、名前が似た2つに気づいて、それぞれのスケジュールタブと実行履歴タブを見比べて、ようやく分かる。やろうと思えばできるが、そもそも疑ってみないと始まらない類の確認です。
ステップ2：対象ホストはどこで決まっているのか
私：ジョブテンプレート ID #306 は、対象ホストを教えて
答えは bigip01 の1台。ですが、そこに至る過程が本題です。
AIはまず Workflow Job Templates Retrieve を叩き、ワークフロー自体には "inventory": null でインベントリが設定されていないことを確認。そこで諦めずに Workflow Jobs Workflow Nodes List を追加で叩いて、各ノードのジョブテンプレートを個別に調べ、「全ノードが bigip01 インベントリを使っているので、対象ホストも bigip01」と結論を出しています。
AAPの設定は階層構造になっていて、上の階層が null なら下の階層を見に行く必要がある。 この「1つ下の階層まで自分で掘る」動きは、ツールを順番に呼べるMCPならではです。1回のAPIコールでは絶対に出てこない答えです。
そして副産物としてワークフロー全体の構成図まで出てきました。
[承認ノード] BIG-IP証明書更新承認
↓ 承認後
[1] BIG-IP_証明書発行 (JT #302) → bigip01
↓ always
[2] BIG-IP_証明書インポート (JT #303) → bigip01
↓ success ↓ failure
[3] BIG-IP_ClientSSL割当 [R] BIG-IP_証明書ロールバック (JT #308)
↓ always ↓ always
[4] BIG-IP_証明書検証 [R] BIG-IP_証明書検証（スキップ）
(JT #305) → bigip01
先頭に承認ノードがあり、失敗時にはロールバック経路が分岐している。前半の言葉で言えば、これは既にL3の設計がされたワークフローです。この点は後半でもう一度触れます。
ステップ3：ホストの接続設定を確認する
私：bigip01 の詳細情報を教えて
ホスト変数、Ansible Facts、直近のジョブ実行履歴がまとめて返ってきます。
注目したいのは ansible_connection: local。AAPコントローラーからSSH接続せず、ローカル実行でBIG-IPのREST APIを叩く構成です。F5の自動化では定番のパターンですが、これをGUIで確認するにはホストの「変数」タブを開く必要があります。
has_active_failures: false も一緒に返ってくるので、「今このホストは健全か」まで1回で分かります。
ステップ4：スケジュールのRRULEを人間の言葉に翻訳させる
ここがいちばん「AIに聞いてよかった」と思った場面です。
私：#306 0_BIG-IP_証明書更新ワークフロー の次の次のスケジュールはある？
返ってきた生の設定はこれです。
RRULE:FREQ=MONTHLY;INTERVAL=1;BYMONTHDAY=19,20,21,22,23,24,25;BYDAY=SU
これ、パッと読めますか。 私は読めません。BYMONTHDAY=19..25 と BYDAY=SU の組み合わせが何を意味するのか、しばらく考える必要があります。
AIの回答は一行でした。
これは「毎月、19〜25日の範囲にある日曜日」に実行するルールです。
つまり「毎月第4日曜日」を表現するためのイディオムです。さらに次回・次々回・3回目の実行日時をJSTに変換した表まで出してくれました。
| 回 | 日時 |
|---|---|
| 次回 | 2026-09-20（日）09:30 JST |
| 次々回 | 2026-10-25（日）09:30 JST |
| 3回目 | 2026-11-22（日）09:30 JST |
RRULEの解読とタイムゾーン変換は、人間がやるとミスが出やすく、しかも面倒くさい。 そしてAIは非常に得意。この非対称性こそが、L1を使う理由そのものです。
（余談ですが、GUIのスケジュール画面にも次回実行日は出ます。ただし「なぜその日なのか」は出ません。ルールの意味を言語化してくれるのがありがたいところです）
ステップ5：他のジョブとの競合を確認する
私：近い日時で別のジョブがスケジュールされているかどうか確認して
システム定義のCleanupジョブ4件を含む全6件を、next_run 昇順で整理してくれました。
そして重要な発見が2つ。
- BIG-IP更新（9/20）の9日前（9/11）に、別の「01_証明書更新ワークフロー」（Webサーバー向け）が動く予定がある
- ただし対象インベントリが異なる（
webserversvsbigip01）ため、同一リソースへの競合はない
さらに、Webサーバー側のインベントリに has_active_failures: true が立っていることまで拾っています。聞いていないことまで気づいて報告してくるのは、横断的にデータを見ているからこその挙動です。
なお、この回答で使われているのは MCP ツールではなく curl でした。
Ran curl -s -k -H "Authorization: Bearer xxxx" "https://xx.xx.xx.xx/api/..."
全スケジュール横断の一覧は登録済みのツールセットではカバーしきれず、AIが自分でAPIを直接叩いています。 MCPは万能の窓口ではなく、足りない部分はシェルで補われる。良し悪しではなく、実際そうなるという話です。ここでは読み取り専用トークンなので問題ありませんが、「AIが何を実行したか」を目視できる状態にしておくことの重要性を示す例でもあります。
5ステップで分かったこと
わずか5つの質問で、ここまで分かりました。
- 同名ワークフローが2つあり、手動実行版とスケジュール版で
extra_varsが食い違っている（要対処） - 対象ホストは
bigip011台、ワークフロー階層ではなく各ノードのJTでインベントリが決まっている - 接続方式は
ansible_connection: local（REST API経由） - スケジュールは「毎月第4日曜 09:30 JST」、次回は 2026-09-20
- 当日に競合するジョブはなし。ただし9日前にWebサーバー側の証明書更新が走り、そちらのインベントリには障害フラグが立っている
そして、この間AIは何も変更していません。 全部読み取りです。間違っていたら私が気づくし、間違っていても何も壊れない。これがL1です。
従来のやり方との比較
| GUI | REST API直叩き | MCP（L1） | |
|---|---|---|---|
| 単発の確認 | ◎ 速い | △ | ○ |
| 横断的な確認 | ✕ 画面遷移が多い | ○ スクリプトを書けば | ◎ |
| 条件付き抽出 | ✕ | ○ 書けば | ◎ |
| 準備コスト | なし | スクリプト作成 | 初回のみMCP登録 |
| 結果の信頼性 | ◎ 画面が真実 | ◎ | ○ 要検証 |
| 定型・反復作業 | △ | ◎ | △ コスト的に不利 |
MCPは万能ではありません。 毎日同じ確認をするなら、Playbookやスクリプトを書いたほうが確実で安く済みます。
MCPが強いのは、毎回少しずつ違う、探索的な問い合わせです。
気をつけていること（落とし穴）
1. 答えは必ず裏を取る
ステップ1で「#322 と #306 で extra_vars が食い違っている」という発見がありました。これは対処が必要な指摘ですが、直す前に必ずGUIで両方のテンプレートを開いて確認します。
「ないと言われた」ときはさらに要注意です。AIが「競合するスケジュールはありません」と答えたとき、それが「本当にない」のか「取得できていないだけ」なのかは、回答からは区別がつきません。
AIの答えは"当たりをつけるため"に使い、確定はGUI/APIで行う。 これがL1のルールです。逆に言えば、当たりをつける段階が速くなるだけでも十分に元は取れます。
2. MCPだけでは完結しない
ステップ5で見たとおり、登録したツールセットでカバーできない問い合わせが来ると、AIは curl でAPIを直接叩きにいきます。
これ自体は悪いことではありませんが、「MCPサーバーの権限設定さえ絞れば安全」とは言い切れないことを意味します。AIが使えるのはMCPツールだけではなく、実行環境のシェルも含まれます。読み取り専用トークンしか渡していなければ実害はありませんが、渡すトークンのスコープこそが本当の境界線だという認識は持っておきたいところです。
3. トークン消費
AAPの環境が大きいと、インベントリ一覧だけでもレスポンスが巨大になります。MCPサーバー側には discover エンドポイントによるトークン消費削減の仕組みが用意されているので、大規模環境ではドキュメントを確認しておくとよいと思います。
質問側の工夫としては、「全部出して」ではなく「〇〇の条件に合うものだけ、名前とIDだけ」のように、最初から絞るのが効きます。
4. 機密情報の扱い
security_compliance ツールセットは認証情報を扱いますが、シークレットそのものは露出しない設計になっています。とはいえ、AIとの会話ログにインフラ構成が残るという事実は変わりません。組織のポリシー上、構成情報を外部LLMに送れるのかは事前に確認が必要です。ここはツールの問題ではなくガバナンスの問題です。
（本記事の画面キャプチャも、FQDN・IPアドレス・トークンはマスクしています。ブログや社内共有に貼るときは、回答本文だけでなくツール実行行のコマンドまで確認してください。ステップ5のように、AIが叩いたcurlのURLとBearerトークンがそのまま画面に出ます）
5. 権限はAAP側で絞る
MCPサーバーはAAPのRBACを継承します。つまりトークンの持ち主の権限を超えることはできません。逆に言えば、管理者権限のトークンを渡せばAIも管理者権限で見えてしまう。専用のサービスアカウントを作って最小権限を与えるのが安全です。
そして前半で書いたとおり、 サービスアカウントを分ける理由は権限だけではありません。 activity streamを見たときに「これはAI経由の実行だ」と判別できる状態にしておく。読み取りしかしていない今のうちにやっておくべき仕込みです。
L1から一段上げるとき
L1に慣れてくると、「ここまで分かってるなら実行までやってほしい」と思う瞬間が必ず来ます。そこで考えるべきことを整理しておきます。
L2へ：AIに案を作らせ、人が実行する
ALLOW_WRITE_OPERATIONS は false のまま、AIには変更手順やPlaybookの下書きを作らせる。実行するのは人。可逆性の観点では、L1とほぼ同じ安全性のまま、価値だけを増やせます。まずここが現実的な次の一歩だと思います。
L3へ：書き込みを許すなら
ここは慎重に。最低限、以下は設計してから進めるべきだと考えています。
- 書き込み用トークンを読み取り用と分ける（用途ごとに別トークン、別サービスアカウント）
-
alwaysAllowを見直す：読み取り前提で入れた自動承認リストを、そのまま書き込み権限に持ち込まない - 対象を絞る：AIが起動できるジョブテンプレートを、レビュー済みのものだけに限定する
- 承認ゲートを置く：AAP側のワークフロー承認ノードを使えば、AIがジョブを起動しても人の承認なしには先に進まない
- ロールバック経路を用意する：失敗時に自動で戻せる設計になっているか
- 監査経路を確保する：誰が（どのトークンが）何を起動したかがactivity streamで追えること
ここで、ステップ2で出てきたワークフロー構成をもう一度見てください。
[承認ノード] BIG-IP証明書更新承認
↓ 承認後
[1] BIG-IP_証明書発行 → [2] インポート → [3] ClientSSL割当 → [4] 検証
↓ failure
[R] ロールバック
先頭に承認ノード、失敗時にロールバック。
AIの話が出てくるずっと前から、Ansibleの世界ではこういう設計をしてきています。
つまり、L3に必要な部品はAAPにすでに揃っている。
AIに「このワークフローを起動して」と頼めるようにしても、承認ノードで人が止まる。これは、ゼロから承認フローを作るより圧倒的に安全で早い道です。
逆に言えば、承認ノードもロールバックもないワークフローをAIから起動できるようにするのは、もう少し先の話かもしれません。
L3に上げる前にやるべきは、MCPの設定ではなくワークフローの設計です。
AIは「どのPlaybookをいつ動かすか」を判断するが、「何をするか」はすでに人 (とAI) が書いてテストしたものに限る。この分業は、インフラ運用には適合性が高いと思います。
まとめ
- AI活用は「使う/使わない」ではなく、人の関与度の段階で考えると議論がかみ合う
- レベルは製品の属性ではなく作業の属性。同じMCPサーバーでも、権限の渡し方でL1にもL3にもなる
- 選定の軸は可逆性。
- 関与度と直交するもう一本の軸が可視性。危ないのは自律だからではなく、自律かつ見えないから
- AAPのログは、人が押したのかAIが叩いたのかを区別しない。 AI用サービスアカウントの分離は、L3になってからでは遅い仕込み
- AAPの設定確認は、L1の教科書的なユースケース
- RRULEの解読、階層をまたいだインベントリの追跡、スケジュール競合の突き合わせ——人間が面倒だと感じる作業ほどAIが得意という非対称性が、L1の価値の源泉
- L3に必要な部品（承認ノード、ロールバック経路）はAAPにすでにある。上げるべきはMCPの設定ではなく、まずワークフローの設計
- すでに自動化できている作業にAIを重ねる必要はない。AIの価値は、まだ人が毎回考えている部分にある
-
ALLOW_WRITE_OPERATIONSのデフォルトが false であることは、ベンダーからの「まずL1から始めよ」というメッセージ - そして自分の側のレベルは、
mcp.jsonのalwaysAllowに何を書くかで決まる。思想ではなく設定ファイルの1行
「AIがAIを使う」世界は確かに面白いテーマですが、その手前にある 「人のための、よくできた補助ツール」 としてのAIは、今日から実務で効きます。しかもそこで積んだ経験が、上のレベルに上がるときの設計判断を支えてくれる。
まずはIBM Bob で MCP サーバーを動かして、Read権限のトークンを1本作り動かしてみることから、始めてみてはいかがでしょうか、ということで本記事を締めさせていただきます。
参考
MCPサーバー for AAP の発表（Red Hat Blog）
https://www.redhat.com/en/blog/it-automation-agentic-ai-introducing-mcp-server-red-hat-ansible-automation-platform
Deploy the MCP server on Ansible Automation Platform（AAP 2.7 Documentation）
https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.7/extend-assembly_deploying_ansible_mcp_server
Deploying Ansible MCP server（AAP 2.6 Containerized installation）
https://docs.redhat.com/en/documentation/red_hat_ansible_automation_platform/2.6/html/containerized_installation/deploying-ansible-mcp-server
ansible/aap-mcp-server（GitHub）
https://github.com/ansible/aap-mcp-server
Using MCP in Bob（IBM Bob Docs）
https://bob.ibm.com/docs/ide/configuration/mcp/mcp-in-bob
MCP server transports（IBM Bob Docs）
https://bob.ibm.com/docs/ide/configuration/mcp/server-transports
IBM Bob × MCP連携の実践：Ansible Automation Platformを日本語で操作（Qiita）
https://qiita.com/c_u/items/a52c2f4203ce76e97aea