てくなべ

ansible / network automation / 学習メモ / 思考メモ

[Ansible] ネットワーク機器へのコマンドとレスポンスを記録できる Transcript recording 機能

はじめに

2026/09/17 リリースの ansible.netcommon コレクション 8.7.0 で、network_cli コネクションプラグイン使用時に「実際にどんなコマンドを実行して、どんなレスポンスが返ってきたのか」をファイルに記録する機能が加わりました。

ネットワーク系のPlaybook のデバッグとして、Ansible とネットワーク機器の間のやりとりを覗き込んで見てみたいと思ったことはないでしょうか?

通信レイヤーでなにか工夫すればできるかも知れませんが、Ansible の世界で簡単にできればなと思っていました。なので、個人的には待望の機能で、こっそりプルリクを追っていました。

さっそく試してみました。

  • 検証環境
    • ansible-core 2.21.3
    • ansible.netcommon コレクション 8.7.0
    • cisco.ios コレクション 11.6.0

検証 Playbook

Cisco IOS に対する以下のタスクで試してみます。

---
- name: Test play
  hosts: ios01
  gather_facts: false

  tasks:
    - name: Gather IOS facts
      cisco.ios.ios_facts:
        gather_subset:
          - interfaces

この cisco.ios.ios_facts モジュールのこのオプションを実行したときにどんなコマンドが実行されるでしょうか。cisco.ios.ios_command のように、Playbook の書き手が直接 show コマンドを指定するわけではないので、パッと見では分かりません。ソースを追えば分かるでしょう。ただ、実際にどうだったかを手軽に、かつレスポンスを含めて確認できるのは、今回の新機能ならではないでしょうか。

実行

デフォルトでは従来通り記録はされません。ANSIBLE_NETWORK_CLI_RECORD という環境変数に 1 を指定して実行すると記録されます。

 % ANSIBLE_NETWORK_CLI_RECORD=1 ansible-playbook -i inventory.ini ios_show.yml

PLAY [Test play] *************************************************************************************************

TASK [Gather IOS facts] ******************************************************************************************
ok: [ios01]

PLAY RECAP *******************************************************************************************************
ios01                      : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   

Playbook 実行ログ自体は普段と変わりません。

記録の確認

記録は /tmp/transcript-recordings/ ディレクトリ配下の .jsonlファイルとして残ります。(環境変数 ANSIBLE_NETWORK_CLI_RECORD_PATH で変更可)

% ls -1 /tmp/transcript-recordings
192.168.1.11_22.jsonl

ファイル名に含まれる _22 はポート番号です。

中身はこんな感じです。レスポンスはだいぶ省略しています。ちなみに、複数回 Playbook を実行すると追記されていきました。

{"command": "terminal length 0", "response": "", "timestamp": 1789652162.5164092}
{"command": "terminal width 512", "response": "", "timestamp": 1789652162.686284}
{"command": "terminal width 0", "response": "", "timestamp": 1789652162.840522}
{"command": "show version", "response": "Cisco IOS Software, (略)", "timestamp": 1789652163.004417}
{"command": "show version", "response": "Cisco IOS Software, (略)", "timestamp": 1789652163.20715}
{"command": "show inventory", "response": "NAME: \"IOSv\", DESCR: \"IOSv chassis, (略)", "timestamp": 1789652163.419025}
{"command": "show interfaces", "response": "GigabitEthernet0/0 is up, line protocol is up \n(略)", "timestamp": 1789652163.6333282}
{"command": "show ip interface", "response": "GigabitEthernet0/0 is up, line protocol is up\n(略)", "timestamp": 1789652163.8225641}
{"command": "show ipv6 interface", "response": "", "timestamp": 1789652163.9971762}
{"command": "show lldp", "response": "% LLDP is not enabled", "timestamp": 1789652164.14175}
{"command": "show cdp", "response": "Global CDP information:\n(略)", "timestamp": 1789652164.290456}
{"command": "show cdp neighbors detail", "response": "-------------------------\nDevice ID: (略)", "timestamp": 1789652164.5402439}
{"command": "terminal length 0", "response": "", "timestamp": 1789652162.5164092}
{"command": "terminal width 512", "response": "", "timestamp": 1789652162.686284}
{"command": "terminal width 0", "response": "", "timestamp": 1789652162.840522}
{"command": "show version", "response": "Cisco IOS Software, (略)", "timestamp": 1789652163.004417}
{"command": "show version", "response": "Cisco IOS Software, (略)", "timestamp": 1789652163.20715}
{"command": "show inventory", "response": "NAME: \"IOSv\", DESCR: \"IOSv chassis, (略)", "timestamp": 1789652163.419025}
{"command": "show interfaces", "response": "GigabitEthernet0/0 is up, (略)", "timestamp": 1789652163.6333282}
{"command": "show ip interface", "response": "GigabitEthernet0/0 is up, (略)", "timestamp": 1789652163.8225641}
{"command": "show ipv6 interface", "response": "", "timestamp": 1789652163.9971762}
{"command": "show lldp", "response": "% LLDP is not enabled", "timestamp": 1789652164.14175}
{"command": "show cdp", "response": "Global CDP information:\n(略)", "timestamp": 1789652164.290456}
{"command": "show cdp neighbors detail", "response": "-------------------------\nDevice ID: (略)", "timestamp": 1789652164.5402439}

いろんな show コマンドとその結果が見れました。モジュール自身が実行するコマンドの他にも、ターミナルプラグイン(今回は cisco.ios.ios)が実行している terminal length 0 などのコマンドも見れました。

ただ、よく見ると2セット出力されています(タイムスタンプが同じ行がある)が詳細は分かりません。

1行だけ切り取って普通の JSON にするとこんな感じです。フォーマットは直感的です。

{
    "command": "show version",
    "response": "Cisco IOS Software, (略)\n\n\n\nConfiguration register is 0x0",
    "timestamp": 1789652163.004417
}

今回初めて知りましたが cisshgo という、Cisco IOS などの機器をテスト目的でエミュレートするツールで使うためのフォーマットのようです。これはこれでおもしろそう・・・。

日本語参考記事: 多数のNW機器をシミュレートするcisshgoについて | NTTテクノクロスブログ

設定系モジュールでも試してみる

参照系ではなく設定系のモジュールを使った例も試してみます。

    # タスク抜粋
    - name: Test Configuration
      cisco.ios.ios_config:
        lines:
          - description test
        parents:
          - interface GigabitEthernet0/0

結果は以下のとおりです。設定コマンド以外にもいろいろ出力されますね。show running-config が含まれるのは、事前にコンフィグを取得して、モジュールで指定したコンフィグがすでに設定されてるか確認するためのはずです。

{"command": "terminal length 0", "response": "", "timestamp": 1789651961.155453}
{"command": "terminal width 512", "response": "", "timestamp": 1789651961.339106}
{"command": "terminal width 0", "response": "", "timestamp": 1789651961.500611}
{"command": "show version", "response": "Cisco IOS Software, (略)", "timestamp": 1789651961.675512}
{"command": "show running-config", "response": "Building configuration...\n\n  (略)\nend", "timestamp": 1789651963.862564}
{"command": "configure terminal", "response": "Enter configuration commands, one per line.  End with CNTL/Z.", "timestamp": 1789651964.0429828}
{"command": "interface GigabitEthernet0/0", "response": "", "timestamp": 1789651964.256902}
{"command": "description test", "response": "", "timestamp": 1789651964.439345}
{"command": "end", "response": "", "timestamp": 1789651964.57701}
{"command": "terminal length 0", "response": "", "timestamp": 1789651961.155453}
{"command": "terminal width 512", "response": "", "timestamp": 1789651961.339106}
{"command": "terminal width 0", "response": "", "timestamp": 1789651961.500611}
{"command": "show version", "response": "Cisco IOS Software, (略)", "timestamp": 1789651961.675512}
{"command": "show running-config", "response": "Building configuration...\n\n  (略)\nend", "timestamp": 1789651963.862564}
{"command": "configure terminal", "response": "Enter configuration commands, one per line.  End with CNTL/Z.", "timestamp": 1789651964.0429828}
{"command": "interface GigabitEthernet0/0", "response": "", "timestamp": 1789651964.256902}
{"command": "description test", "response": "", "timestamp": 1789651964.439345}
{"command": "end", "response": "", "timestamp": 1789651964.57701}

今のところドキュメントには未掲載

今のところ、ansible.netcommon コレクションのドキュメントには本件の記載が見当たりません。なので、network_cli コネクションプラグインのコードにあるコメントを見るのが良いかなと思います。

ansible.netcommon/plugins/connection/network_cli.py at e15c19a707a8e490d5f61bb8a445cd044c321c70 · ansible-collections/ansible.netcommon · GitHub

あまり常用的に使うものでもないのかもしれません。

おわりに

ansible.netcommon コレクション 8.7.0 で導入された、ネットワーク機器とのコマンド・レスポンスを記録できる機能を試してみました。

個人的にはデバッグ用途で期待していた機能ですが、cisshgo にテストのための材料収集にも使えそうで、さらに興味が湧きました。

[Ansible/AAP] 公式 Execution Environment の情報を Red Hat Ecosystem Catalog で確認する

はじめに

AAP 2.x では Ansible Playbook はコンテナ内で実行されます。その Ansible 用のコンテナのことを Execution Environment(EE: 実行環境)と呼びます。

AAP では標準でいくつかの EE がセットされています。AAP 2.5 以降の UI でいうと、左メニューの [Automation Execution] > [Infrastructure] > [実行環境] で確認できます。

ときどき、特定の EE の情報を Web 上で確認したいときがあります。ところが、たぶん私だけだと思うんですが「Red Hat Ecosystem Catalog に載ってるんだけだけどな」と思いつつ、毎回探すのに手間取ってしまっています。

なので、ほぼ自分用に、迷子にならないようにリンクを貼っておきます。

EE の一覧ページ

EE の一覧は以下のページにあります。コンテナ一覧の中から EE を絞り込んだ結果です。

catalog.redhat.com

なお、やや蛇足ですがAAP 関連のイメージは EE 以外にもいろいろあます。EDA (Event-Driven Ansible) で利用する DE (Decision Environment) 、内部処理用のコンテナなど。それらをいろいろ含めた一覧は以下のページで確認できます。

catalog.redhat.com

registry.redhat.io/ansible-automation-platform-<VERSION>/ee-XXX のようなイメージ名がいわゆる EE です。-<VERSION> が付かない場合もあります。

EE の詳細ページ

たとえば、AAP 2.7 向けの EE registry.redhat.io/ansible-automation-platform-27/ee-supported-rhel9 であれば以下のページで詳細を確認できます。

catalog.redhat.com

registry.redhat.io/ansible-automation-platform-27/ee-supported-rhel9

やや上にある Change version から確認したいバージョンやアーキテクチャーを選択できます。

もちろん、今さくっとコマンドライン上で EE の中身を見れるのであれば、コマンドで確認しちゃった方が早いと思います。他人と同じページを共有したい場合は Ecosystem Catalog の URL を共有するのもよいかと思います。Red Hat アカウントによるログインも不要なのでお手軽です。

JANOG58 Meeting in Matsuyama オンライン参加レポート

はじめに

2026/07/15-17 に JANOG58 Meeting in Matsuyama が開催されました。アリスタネットワークスジャパンさんです。四国での JANOG 開催はこれで3県目。つまり全4県までリーチだそうです。副社長が松山出身というご縁があるそうです。

www.janog.gr.jp

閉会宣言での発表によると、登録者数は 4,251人、来場者数合計 3,783人ということで、今回も大盛況だったようです。

今回私は現地参加はできませんでしたが、オンラインで参加しました。といっても今回は Ansible Automates 2026 Japan と日程が被ってしまっていたことや予定の都合、リアルタイムで視聴できたのは1つのプログラムだけでした。

本記事では、リアルタイムで視聴できたプログラムを中心にした感想や、全体的な所感についてまとめます。

なお、各プログラムの詳細ページから資料や、アーカイブ動画が公開されています(一部を除く。2027年1月31日まで)。

YouTube の再生リストも用意されています(DAY1、DAY2、DAY3)。ありがたいです。

視聴プログラム

当日リアルタイムで視聴できたプログラム(1つだけですが・・)についての感想です。

ベテランエンジニアの「勘」はLLMに移植できるのか RAGで再現できるもの・できないもの

www.janog.gr.jp

www.youtube.com

暗黙知を含むナレッジを組織に活かすために生成AIをどう使えるかという点に興味があるので視聴しました。

本プログラムでは暗黙知を3つの層に分ける考え方が紹介されていました。抽象度が高い順に以下の層です。

  1. 横断経験から培われた直感
  2. 分析の型・判断フレーム
  3. 特定システムの事例知識

その上で、3の層は RAG で解決しやすいが、現場でAI活用するためには1段抽象化された2の層が必要という論が示されました。

私は暗黙知と形式知の間にはいくつか段階や種類があるよなと思っていたところでしたが、暗黙知自身の層という観点は持っていませんでした。この考え方はこれから暗黙知に向き合うときに参考になりそうです。

プログラムでこの後カギになってくるのは「型」という考え方です。私なりに解釈すると、ベテランが持っている、特定システムに依存しない汎用的な思考や行動の特性、といった感じです。

この「型」をAIにどう移植していくかが大きなテーマです。そこで、型をプロンプト設計に落とし込むアプローチが紹介されていました。

型を移植するためのプロンプト設計のポイントは、以下です。ここが本プログラムで一番印象的でした(資料のP13)。

  • 思考プロセスを埋め込むこと
  • 段階的推論により、AI自身に「情報の矛盾」に気づく余白を与えること
  • 判断するためのフレームワークを明示すること

テストで利用された型の具体例は、判断を安全側に倒す型です。特定のルールではなく、「分からない時は触るな」のような原理原則的なものです。

型(プロンプト)の有無や情報(ログ)の有無などを組み合わせた4つのパターンで試験した結果、型がある場合は「情報(ログ)がなくても」安全側に倒せたという結果が出たそうです。

ディスカッションパートで特に印象的だったのは「マニュアルは正解をまとめたものだが、正解じゃないものをどう扱うかが重要な点」という話でした(動画 40:07 から)。

また、JANOG Slack にも書いたのですが、仮にベテランの勘や型をすべてAIに移植したとしても、ベテランという「人」の価値は依然として残るものだと思っています。例えば「あの人が言ってるならたぶんそうだ、やってみよう」って周りを動かす力もベテランには備わっている気もしています。

とても興味深いプログラムでした。

総じて、暗黙知や勘といった言葉で一括りせずに、紹介されていた3つの層で考えたり、「疑う力」「メタ認知」「内省」あたりをどう扱うかという点にフォーカスすると良さそう、という視点が得られました。あわせて、様々な経験から得られた「原理原則」を良い粒度で抽象化、言語化することが重要だろうという点にも気づけました。

アーカイブ視聴予定

当日参加できたプログラム以外にも興味深いプログラムがあるため、後日アーカイブを視聴しようと思います。ほとんどリアルタイム視聴できなかったのでありがたいです。

主に以下のプログラムを中心に視聴予定です。

プログラム以外

プログラム本編以外で感じたことです。

NOC

会場のネットワークを整備する NOC も、毎回様々な取り組みをされているようです。

あまり詳細を追えていませんが、今回はAS 番号を取得していたようです。

会期中の AS23811(https://bgp.tools/ にて)

その後の AS23811

弊社からスタッフ

今回は弊社(エーピーコミュニケーションズ)社員がスタッフ(プログラム委員)として参加していました。

JANOG54では「自動化の教育ってどうやってますか?」というプログラムで私と共同登壇してもらったメンバーです。JANOGに関わる人が増えたり関わり方が増えたりして、勝手に嬉しく思っています。

日々の業務もある中での準備や、当日の対応など、お疲れさまでした!

www.janog.gr.jp

野良 BoF たくさん

ここ数回の傾向として野良 BoF の盛り上がりがすごいような印象です。今回は会場が7つも用意され、ざっと数えても30件以上ありました。

www.janog.gr.jp

「ネットワークエンジニアクソミスグランプリBof」という、いかにもオフレコという感じで、かつ学びになるBoFも気になりました。

野良 BoF は現地ならではですので、現地参加できたら是非とも参加して、濃くてインタラクティブ性の高い議論に参加してみたいものです。

プログラム個別アンケート

いつも通り全体のアンケートもありつつ、今回は各プログラムにそれぞれ個別に事後アンケートが用意されていました。

これまで私が参加してきた中では初めてのような気がします。より詳しいフィードバックを差し上げるには良い仕組みだと思いました。

おわりに

今回も AI の話が多かったように思います。机上や妄想ではなく、経験を通じた様々な情報を共有していただきありがたいです。

この度は、スタッフのみなさま、登壇者のみなさま、ホスト企業のみなさま、ありがとうございました!

また、弊社のブース対応をしてくれたメンバーにも感謝です。いつもありがとうございます。

次回の JANOG59 は 2027/1/20-22 に福井県福井市で開催予定。ホストはNTTドコモビジネスさんとミテネインターネットさん。福井では初のNOG(JANOGや地域NOGを含め)だそうです。

次回予告 (PDF)

参考

[2026/09/09 追記]

note.com

[2026/09/09 追記]

note.com

show int さんの関連動画

事前

www.youtube.com

ふりかえり

www.youtube.com

[2026/08/31 追記]

www.youtube.com

X ポストまとめ

実況ポスト、まとめありがとうございます!

posfie.com

私と JANOG のこれまで

tekunabe.hatenablog.jp

[Ansible] Ansible Automates 2026 Japan 参加レポート

はじめに: 7年ぶりのオフライン開催

2026年 7月15日 に Ansible Automates 2026 Japan が開催されました。

ここ数年はオンライン開催のみでしたが、今年は 7年ぶりのオフライン・オンラインのハイブリッド開催でした。

(厳密にはもともと「~ Tokyo」でしたがオンラインになったタイミングくらいで「~ Japan」になりました)

せっかくですのでオフライン会場(四谷)にて参加してきました。オープニングセッションによると、現地登録者数は約120名、リモートは900名以上とのことでした。

技術そのものの他にも、各社のリアルな取り組みのお話も聞けてとても有意義でした。

この記事では、各セッションで私が印象的だった点を中心にレポートします。

なお、オンデマンド動画は以下から視聴できますので是非どうぞ。

www.redhat.com

AIと融合した自律運用の実現に向けて(レッドハットさん)

IT運用を自動化する必要性や、あるべき姿、そして自動化へのAIの関わりなどがご紹介されていました。これまでよく言われていた 自動化 2.0 という表現は直接的にはなくなり、人が介在しない自動化はもはや前提のように語られていた印象でした。

そのうえで、現在の論点はやはり AI。

何でもかんでも AI に任せるのではなく、ルールベース、決定論的な判断は既存の仕組みを利用し、それ以外の部分は AI に評価をゆだねる、といった分担が重要そうでした。

具体的なプロダクトとして紹介されていたのは、Automation Orchestrator です。Red Hat Summit 2026 のキーノートでも紹介されていた、AAP の追加機能的なものです。

ざっくり、AAP のワークフローのもっとすごいやつ、といった感じです。ジョブテンプレートだけでなく、EDA や AI エージェントもワークフローのノードとして設定できるようなものです。

Tech Preview 版として 2026年第3四半期(レッドハット社の)にリリースされるようです。

デモで紹介されていたのは以下のモノです。雰囲気が伝わるかと思います。

interact.redhat.com

また、Playbook を生成する Red Hat Ansible Lightspeed は名称が変更されたことにも触れられていました。私はここで初耳でした。この点は以下の別記事にしています。

tekunabe.hatenablog.jp

AI のように手段が増えてきた今、改めて業務を良く知り、特性を見極め、うまく使い分けることが重要だと感じました。

人材不足時代の維持管理モダナイズ 〜JALデジタルが挑む Platform Engineering とセルフサービス型自動化〜(JALデジタルさん)

社内で利用してもらうための API をクラウド移行、モダナイズするなかで、どのように課題を分析し、ユーザーの声を聴き、「使ってもらう自動化」にしたか、という取り組みが紹介されていました。

改めて感じた重要な点は、課題の特定です。

今回の場合は、API キーの発行を自動化しても、運用の地獄は終わらないのではという問いが新たにできた、とのことでした。さらに分析していくと「本当の課題は手順化できていない部分にある」という事実。

そこで、ユーザーがそもそも「コードを書き始めるまで」のハードルをいかに低く、迷わない仕組みを作ることに取り組まれたそうです。

具体的にはドキュメントや、テンプレート、教育です。必要なドキュメントを誰もが目にする場所に設置したり、いつでも使える環境を用意したり。

特にハッとしたのが、「安全」に利用できるだけでなく、ユーザーの「安心」にも配慮した点でした。今回の API はデータの読み取りだけで、書き込みはしないものでした。そのため、本番環境を利用した検証も、原理上はできそうに思えました。しかし、それでも不安におもうユーザーがいることを考慮して「安心」して使えるように、開発環境を利用した検証の仕組みにしたそうです。

システム同士の連携だけでなく、人とシステムをうまくつないで使ってもらえるようにする工夫。システムとしての安全性だけでなく、ユーザーの安心も配慮する。

本セッションは全体的に、システムだけでなく「人」に向き合ってきた取り組みが印象的でした。

生成AIを活用した自動化チームのスケール(三菱電機デジタルイノベーションさん)

自動化を推進するにあたり、どう生成AIを活用しつつ、どうチームビルディングして成果を出していったか、というお話でした。

印象的だったのは、生成AIは「若手の心理的ハードルを下げた」という件です。機能としてはPlaybook を生成するといったことができますが、それが「人にどう影響を与えるか」に着目されている印象でした。

OS、ネットワーク、仮想化、運用など、さまざまなバックグラウンドの人たちが集まったそうですが、そういった違いを良い意味の多様性と捉えて「学び合いの素材」にしたそうです。油断すると、価値観が違って分かり合えないままになってしまいそうでもありますが、良い化学変化に変えたあたりが、元々の文化の良さや、チームビルディングの手腕によるものだろうと思いました。

具体的な手法としては、学びの機会としてモブプログラミングを導入。興味深かったのは、量産フェーズに入ると効率が落ちたこと。そこで、学び合いのフェーズはモブプログラミングを、量産フェーズはペアプログラミング、のように使い分けたそうです。

なんとなく続けるだけでなく、立ち止まってふりかえって改善する姿勢が素敵だと思いました。

レッドハットさんによる外部支援の利用の仕方も工夫がなされていました。たとえば「レビューで型を学ぶ」。ただレビューで指摘をもらってその通りに直すだけでなく、次回から自分たちで再現できるように型を会得していったそうです。

一連の取り組みの成果は、もちろん自動化を推進したこともありますが、何より自動化を推進できる人と体制が整ったことなのだろうなと思いました。

導入事例に見る共通基盤自動化の設計と実践(みずほ銀行さん)

AAP を導入する上で直面した課題と対応、共通基盤の設定自動化を安全に実施する工夫のお話でした。

AAP 導入にあたっては、複数の環境に対してどのように AAP のコンポーネントを置くかが課題になったそうです。2つの構成のメリットとデメリットを見極めつつ、最終的には、コントロールノードを中心において、実行ノードを各環境に置くという構成を取りました。

主な理由は、コントロールノードをまとめることによる設定データの一元管理と、環境追加の場合は実行ノードを置くだけで良いという拡張性の高さです。興味深かったのは、コントロールノードをまとめておくと、環境横断の操作がしやすくなるという点です。確かに、コントロールノードを各環境に置く構成だと、環境Aの情報を環境Bで利用したい場合は、相応の工夫が必要になります。

もちろん、ビジネス要件などによって、正解は異なってきますが、私自身もこの手の構成検討をすることがよくあるので参考になりました。

設定自動化を安全に実施する工夫は、スプレッドシートでパラメーター定義して、インベントリファイル変数を生成するスクリプトを作成した点です。一足飛びに考えると「設定ファイルは YAML を Git で管理するのが良いのでは?」と思うところです。

しかし、この設定自動化の対象は仮想NW設定であり、ミスの影響が大きいため、承認プロセスが重要となり、従来のレビュー手法を活かすために、あえて最初のステップとしてはスプレッドシートを採用したそうです。

Ansible Automation Platformで挑むメインフレーム運用の標準化・セルフサービス化(大樹生命アイテクノロジーさん)

メインフレームの作業を自動化する上で、工夫したことなどのお話でした。

運用や実装のポイントの1つ目は、完全自動化にはしなかった点。安全性や柔軟性を重視して、判断は人が行う形にしたそうです。

2つ目は、なんでも Playbook で実装するのではなく、従来の自動化資源も活用する点。また、トラブル時は既存の手順でもオペレーション可能にしている点も印象的でした。

自動化をすすめるチームにはベテランの方もいらっしゃって、最初の頃は自動化に対して否定的だったそうですが、次第に受け止め方が変わってきたそうです。おそらく、粘り強く丁寧なコミュニケーションがなされたのではないかなと思います。

まとめの方で「自動化の取り組みは若手中心でやったという発表が多いが、こういうチームもある」といった趣旨のことを話されていて、会場では思わず笑いがこぼれました。素敵です。

Ansibleが切り拓く自動化と次世代運用(伊藤忠テクノソリューションズさん)

C-Nativeというクラウドネイティブ技術支援のサービスのご紹介や、各種自動化の取り組みのお話でした。

自動化の取り組みの1つ目は、証明書自動更新。CA/Browserフォーラムによって、証明書の有効期限が段階的に47日に短縮されることが決定されているため、それに伴って証明書更新を効率化していこうという流れがあります。

構成として紹介されていたのは、AAP と HashiCorp Vault の組み合わせです。HashiCorp Vault に証明書を保管してもらいつつ、AAP が証明書に関連するさまざまな作業を自動化する構成です。

2つ目は、セキュリティパッチ 管理・運用。これは、Claude Mythos に代表される 生成AI による攻撃の高速化や高度化に対してはもはや手動のパッチ適用作業では間に合わず自動化が必須という背景があります。

3つ目は、AIを利用した IaC開発と Terraform/Ansible連携。利用ツールの例として挙げられていたのは、Claude Code。Terraform や Ansible のコードの生成やレビューなどを担当するそうです。特徴的だと思ったのは、IDP( Internal Developer Portal) として、Red Hat Developer Hub が挙げられていた点です。少しずつ事例も聞くようになってきた印象です。

ICTインフラの自律運用に向けた取り組みと、自動化に向けた一歩目の踏み出し方(ネットワンシステムズさん)

Event Driven + AIOps の運用イメージとして、障害検知から分析、対処の検証、適用の一連の流れができる構成が示されていました。

一番ポイントだと思ったのは、分析のフェーズで AI エージェントが対処用の Playbook を生成する点です。障害というものはだいたい未知の現象です。未知の現象に対して、どうすればよいのかはベテランエンジニアの頭の中にしかないかもしれません。それを AI エージェントがやってくれるのであれば、障害対応の大きな助けになるのではないかと思いました。

自動化に向けた一歩目の踏み出し方のパートで紹介されていたのは、自動化の先のセルフサービス化です。

個人的には、これまで英語でしか情報を得られていなかった Self-service automation portalを日本語で紹介していただけたのがありがたかったです。自動化を提供する側としては安全に使ってもらうように、自動化の利用者としては分かりやすく使うために有用なものになり、セルフサービス化の後押しになりそうです。

また「Innovation Showcase」という、デモやディスカッションを実施する取り組みをされているそうです。深い話になりそうで興味深いです。

www.netone.co.jp

おわりに

7年ぶりの Ansible Automates の現地参加、とても有意義なものになりました。

私自身はしばらくオンラインでのイベント参加が多かったのですが、実際に同じことに関心が集まっている様子を見ると、なんだかパワーをもらったような感覚がありました。

イベントに携わったみなさま、ありがとうございました!

[Ansible] Ansible 向けに参考になる Agent Skills やカスタム指示ファイル

はじめに

Ansible の Playbook 作成に携わっている方の中には、Playbook 生成やコードレビューなどで生成AIを活用されている、または活用を予定されている方も多いのではないでしょうか。

私自身も探っている最中です。ただ、カスタム指示ファイルも Agent Skills も、自由度が高くてなかなかとっかかりがつかみにくいのが正直なところです。

ありがたいことに、すでに参考になりそうなものが GitHub リポジトリ上で公開されているので、見つけたものをまとめます。個人リポジトリを含めるとたくさんあると思うのですが、ここでは組織リポジトリ配下のものに絞ります。

中身は英語ではありますが、用途、観点、粒度などの点において参考になりそうです。

なお本記事は、自分で Agent Skills などを書く場合の参考にするためという趣旨で紹介します。(もちろんそのまま利用するのも一手です。そのまま利用する方法については、もしあとで別記事で書いたらリンクを追加しておきます)

主に VS Code 上の GitHub Copilot を前提に説明します。

Agent Skills と Commands

ansible-community/ai-forge

Ansible Forum で案内があったのですが、ansible-community という組織内に ai-forge というリポジトリがあります。ここに Ansible 向けの Agent Skills と Commands が載っています。

github.com

※注意点として、新しいリポジトリなので頻繁に変更が起こり得ることと、人間のレビューが必要であることがREADME.mdに書かれています。本記事では 2026/07/17 のコミット 40367777c1a3cbc983d9ee761f993ccba89aaa7e 時点を前提にします。

本リポジトリを探るには少し前提が必要です。

本リポジトリの Agent Skills や Commands は、Lola という "AI Context Package Manager" によってインストールできるようになっています。その関係で、Agent Skills や Commands が Module という単位で管理されています(Ansible 用語のモジュールとは異なるので 以降 Lola Module と表記)。

リポジトリのトップに Lola Module 単位でディレクトリが並んでいます。そのディレクトリ配下に Agent Skills や Commands が含まれているという構造です。Lola Module によっては、Agent Skills だけだったり、Commands だけだったりすることもあります。

例えば、Lola Module ansible-collection-standards の場合は以下のようになっています。

ansible-collection-standards  # Lola Module トップのディレクトリ
    module
        commands  # Commands のとりまとめディレクトリ
             ansible-collection-inclusion-review.md
             ansible-cop-review.md
             ansible-scaffold-collection.md
        skills  # スキルのとりまとめディレクトリ
             ansible-zen  # スキル ansible-zen のディレクトリ

ここまで本リポジトリにあわせて Commands という表現をしましたが、GitHub Copilot 環境においては Commands はプロンプトファイルと解釈して良さそうです。

実際に Lola (Version 0.7.0)を使って Lola Module を GitHub Copilot 環境向けにインストール(lola install ansible-collection-standards -a copilot-vscode)すると、 Commands は .github/prompts ディレクトリ配下に *.md ファイルが配置されました。例えば ansible-collection-standards/module/commands/ansible-cop-review.md は、.github/prompts/ansible-cop-review.prompt.md (ファイル名に .prompt が差し込まれた)に置かれました。

Lola は、Agent Skills などを各 AI アシスタント(Lola としては GitHub Copilot や Claude Code などを指す)共通のものとしてパッケージで管理しつつ、 各 AI アシスタントの仕様に合わせてインストールするというのが特徴のようです。

以下、いくつか Agent Skills と Commands を紹介します。

所属 Lola Module 名 分類 名前 概要
ansible-collection-standards Commands ansible-cop-review Red Hat Community of Practice 作成の Good Practices for Ansible に基づくレビュー
ansible-content-development Agent Skills write-content Ansible content (Playbook、変数ファイル、インベントリなど)の作成や改善
ansible-documentation Agent Skills ansible-markdown-docs docs.ansible.com から Ansible のドキュメントを Markdown 形式で取得する(この中身を見たことをきっかけで Markdown 形式で取得できることを知りました)

そのまま利用する場合は Lola を使うと簡単に導入できそうです。

カスタム指示ファイル

Awesome GitHub Copilot

github 組織配下でコミュニティベースで運営されている Awesome GitHub Copilot に、Ansible 向けのカスタム指示ファイルが載っています。

awesome-copilot.github.com

中身は以下のファイルです。

github.com

書かれているのは例えば以下の内容です。

  • name を指定する
  • FQCN で指定する
  • インデントは2つのスペース
  • 変数名はスネークケース

人が確認するにも十分現実的なボリュームでまとまっています。

VS Code の Ansible 用拡張内の MCP Server が参照するリソース

VS Code の Ansible 用拡張には、MCP Server が含まれています。

どういう仕組みなんだろうと気になって調べていたときに、Resource として定義されているらしきファイルを見つけました。こちらも参考になりそうです。

github.com

この拡張内の MCP Server を利用するのは結構手軽なので、もし別途記事を書いたらリンクを追加しておきます。

ちなみに、拡張内に MCP Server が含まれることは、2025年の Ansible アドベントカレンダーの記事で知りました。ありがとうございました。

おわりに

改めて一通り眺めてみると、やっぱりいろんな書きっぷりがあって、唯一の正解を探すというのは難しい気もしています。

既存のものをありがたく参考にしつつ自前で書いて改善していくのもよいでしょうし、そのまま使ってみるのも良いかもしれません。

おまけ

Ansible ではありませんが、Red Hat 社提供の Agent Skills がいくつかあるので、ここに Ansible 向けのものも載らないかなぁと妄想しています。

catalog.redhat.com

Terraform だと、hashicorp/agent-skills があるみたいですね。

[Ansible] コーディングルール類の参考になる Good Practices for Ansible

はじめに

Ansible の Playbook は、同じ処理でもいろんな書き方ができます。タスクの name にしても、書かなくても動くことは動きます。

自分一人で書く分にはそんなに問題になりませんが、チームで開発する場合は、コーディングルールがほしいよね、という話になることが多いと思います。

とはいえ、一からコーディングルールを作成するのもなかなか大変です。

ありがたいことに Red Hat の CoP (Community of Practice) 主導によるコーディングルール類をまとめたものが公開されているのでご紹介します。

redhat-cop.github.io

Good Practices for Ansible の各章の概要

Good Practices for Ansible は、現在(2026/07/23)8つの章に分かれています。

いきなり全部読むのは大変なので、各章の概要だけまとめます。また独断ですが、(コレクション開発者ではなく)Playbook やロールを作成する人にとっての重要度を ★ ~ ★★★ でつけてみます。

章 概要 重要度 補足
1. Introduction このドキュメント自体の説明 ★
2. Automation structures 自動化処理の構成要素 ★
3. Roles Good Practices for Ansible ロール作成時のお作法。タスクレベルのお作法もここ ★★★
4. Collections good practices コレクション作成時のお作法 ★ コレクション開発者向け
5. Playbooks good practices Playbook 作成時のお作法。文法やタスクのレベルは基本含まれない ★★★
6. Inventories and Variables Good Practices for Ansible インベントリと変数のお作法 ★★
7. Plugins good practices プラグイン作成時のお作法(Pythonレベル含む) ★ コレクション開発者向け
8. Coding Style Good Practices for Ansible 文法レベルの細かいお作法 ★★★

ざっくり、4 と7 はコレクション開発者向けなのでPlaybook 類の作成者としてはスキップでよくて、逆に 3、5、8、それから 6 は重要に感じました。

なお、全編英語なので、たとえば「コメントは日本語で書くこと」のようなローカルルールが必要な場合もあります。

随時更新されていく

Good Practices for Ansible は、以下のリポジトリで管理されています。必要に応じてプルリクなどを出すのもよいかもしれません。

github.com

ドキュメントは生き物のようなもので、更新され続けています。例えば最近では、 EE(Execution Environment: 実行環境)の定義ファイルの書き方について追加するプルリクがありました。

github.com

やや余談

「ベストプラクティス」ではない

Good Practices for Ansible は「Best Practices」ではなく「Good Practices」です。1. Introduction には、以下の記述があります。唯一絶対の正解ではない、という趣旨です。

Those are opinionated guidelines based on the experience of many people. They are not meant to be followed blindly if they don’t fit the reader’s specific use case, organization or needs; there is a reason why they are called good and not best practices.

また、もう6年くらい前のことですが、Ansible 2.9 のころは公式ドキュメントに「Best Practices」というページがありました。その後、タイトルは「Tips and tricks」になり、現在は「General tips」になっています。

こうして眺めてみると、ベストプラクティスという言葉はあまり使われなくなっている印象があります。

もっとおおざっぱな「The Zen of Ansible」

大原則を示す「The Zen of Ansible」というものもあります。

www.redhat.com

抽象的ですが、何かに迷ったときの判断軸として利用できるかもしれません。

Community of Practice という言葉

Community of Practice という言葉、日本ではあまりなじみがないですかね・・?日本語でなんて言えばいいか迷います。

「実践コミュニティ」「実践共同体」あたりなのでしょうか。

初めてこの言葉を知ったのは、そのままのタイトル「コミュニティ・オブ・プラクティス」という本を10年前に読んだ時でした。

おわりに

コーディングルール類の参考になる、Good Practices for Ansibleをご紹介しました。

前述のとおり、ベストプラクティスではありませんが、迷ったときのとっかかりとしてはとても有用かなと思います。

GitHub Copilot code review でカスタム命令ファイルなどはヘッドブランチを読むようになった

はじめに

GitHub Copilot code review において、カスタム命令ファイル(copilot-instructions.md、*.instructions.md)はベースブランチから読み込まれる仕様でした。

2026/07/17 の案内でヘッドブランチ、つまりプルリク内のものを読み込む仕様に変わったと案内がありました。

github.blog

copilot-instructions.md、*.instructions.md だけなく、Agent Skills、AGENTS.md も含まれるようです。

個人的には嬉しい改善だったので、copilot-instructions.md を使ったごく簡単なサンプルで試してみました。

準備

main ブランチ

.github/copilot-instructions.md は以下の状態から始めます。

# レビューの基本動作

- 誤字脱字レベルのみを指摘する
- コメントは日本語の標準語を利用する

修正作業をする fix-doc ブランチ

修正ブランチ側は以下の修正をします。

.github/copilot-instructions.md では、京都弁を利用するように指示を変更します。

# レビューの基本動作

- 誤字脱字レベルのみを指摘する
- コメントは日本語の京都弁を利用する

指摘をもらうために、README.md に意図的な誤字を含む文章を追加します。

# sandbox

よろしくおねぎあします

プルリクを出す

fix-doc ブランチから main ブランチにプルリクを出します。 同時にCopilot をレビューにアサインします。

無事 fix-doc ブランチ側の .github/copilot-instructions.md で指定した京都弁(?)でコメントしてくれました。

レビュー結果(京都弁?)

補足

ベースブランチのものを読み込むという仕様は、ドキュメント上はまだ記述が残っていました。いずれ修正されるかと思います。

When reviewing a pull request, Copilot uses the custom instructions in the base branch of the pull request. For example, if your pull request seeks to merge my-feature-branch into main, Copilot will use the custom instructions in main.

About customizing GitHub Copilot responses - GitHub Docs より引用

おわりに

1つのプルリク内で、カスタム命令ファイルの修正とそれがどうレビューに影響するかをセットで確認できるのは便利だなと思いました。