てくなべ

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

[Ansible] ansible-builder 3.2.0 で version: 1 と 2 の定義ファイルは非推奨になった

はじめに

2026/10/14 (JST) に、ansible-builder 3.2.0 がリリースされました。

github.com

ansible-builder は、Ansible を含めたコンテナである EE(Execution Environment)をビルドするツールです。イメージの定義ファイルは、基本的に execution-environment.yml という独自の形式の定義ファイルを利用します。

ansible-builder のバージョンに応じて、定義ファイルのフォーマットにもバージョンがあります(きれいな 1:1 ではなかった気がします)。これまで version: 1、 version: 2、 version: 3 があります。

今回リリースされた ansible-builder 3.2.0 で、古い version: 1、 version: 2 は非推奨(Deprecated)になりました。version: 3 のほうが柔軟なので、古いバージョンを利用する機会はあまりないかなとは思います。なのでメンテナンス性を維持するためには自然の流れだと感じます。

意図的に古い定義ファイルを利用した場合どんな挙動になるのか、簡単に試してみます。

おためし

execution-environment.yml

以下の version: 1 の定義ファイルを利用します。

---
version: 1

build_arg_defaults:
  EE_BASE_IMAGE: docker.io/redhat/ubi9:latest

dependencies:
  galaxy: requirements.yml

ビルド実行

いったんバージョンを確認します。

% ansible-builder --version          
3.2.0

ビルドします。

% ansible-builder build -t my-ee    
DEPRECATION NOTICE: Execution environment schema version 1 is deprecated and will be removed in a future release. Version 3 will be the minimum version supported.
Running command:
  docker build -f context/Dockerfile -t my-ee context
(略)

DEPRECATION NOTICE〜 という警告が表示されました。エラーではないのでビルドの処理自体は続きます。

なお、この警告は ansible-builder 3.1.0 では表示されません。

補足: 3.3 ではサポートされなくなる

Porting Guide によると、ansible-builder 3.3 では非推奨より厳しくなり、サポートされなくなる予定(おそらくエラーになる)とのことです。

Execution environment schema versions 1 and 2 are deprecated and scheduled to be removed from Ansible Builder 3.3.

docs.ansible.com

その他の ansible-builder 3.2.0 アップデート

その他のアップデートはリリースノートを参照してください。

github.com

たとえば、Python 3.9 と 3.10 のサポートがなくなり、3.11 が最小バージョン要件になったようです。

書籍「エンジニアのためのAIに伝わるドキュメントの基本」を読んで

はじめに

最近、人間向けに書かれた Wiki をスキルのサポートファイルに移植する作業をしてました。

基本的にそのまま移植したのですが、自分なりの判断でAI からの読まれ方も少しだけ気にして修正も加えました。ただ、もっとちゃんと知りたいという気持ちが高まっていたところ「エンジニアのためのAIに伝わるドキュメントの基本」という、とても気になる本が発売されたのでさっそく読んでみました。

www.socym.co.jp

本の内容

大まかには、AIにドキュメントをうまく読んでもらうことが重要な背景やAIが読む仕組みから始まり、具体的にどうすればいいかの方法論が紹介されていました。

方法論については、ドキュメントの「配置」「構造」「記述」の3つの要素に整理されていたのがとてもわかりやすかったです。

あと、知りたかった OKF(Open Knowledge Format)について書かれていたのも、本書を買うきっかけの一つでした。

詳細は、目次を参照して下さい。

著者による note 記事もおすすめです。

note.com

私の読み方

先に上げた3つの要素のうち「配置」「構造」については、AI 向け固有な考慮ポイントの割合が多い印象でした。

残る「記述」については「これは人に見やすくしてもらうためにすることと同じだな」という点も見えてきました。

さらに読み進めていくと他の面も見えてきて、私は以下の3つに整理しながら読んでいきました(あくまで勝手な私の分類)。

  • 人間向けと共通な点
  • 人間としてはどっちでもいいけどどうせならAI向けにしたい点
  • AI向けに書くと人間が扱いにくくなるかもしれない点

それぞれ少しだけ例を挙げます。

人間向けと共通な点

たとえば「1パラグラフ1トピックの原則」(P162)。見出しから本文を予想しやすいほうが良い、という点は AI も人間も同じそうに見えました。

なので、これに分類される方法論については、誰/何が相手であっても考慮すべき点として汎用的だなと思いました。

人間としてはどっちでもいいけどどうせならAI向けにしたい点

本書ではAI向けの書き方としてのNG例とOK例がそれぞれ紹介されています。

前述の「人間向けと共通な点」とは異なり、「人間としてはどちらの書き方でもよいかな」というものもありました。あくまで私の感覚としてですが。

たとえば、表の見出し的な部分をセル結合するか、Markdown としての見出しで区切って別の表にするか、です。(P163 「AIが解析しやすいシンプルなテーブル構造」)

AI向けとしてNGかOKの具体例を、本書の趣旨を汲んだうえで私独自の例を挙げます。 (書式の都合上、厳密にはセル結合を再現できないので雰囲気です。書面はもっといい例が載ってます)

【NG記述例】

## 店舗一覧

| 都道府県 | 店名   | 住所 |
| -------- | ------ | ---- |
| 東京都   | 渋谷店 | ○○   |
|          | 新宿店 | ○○   |
| 神奈川県 | 横浜店 | ○○   |
|          | 川崎店 | ○○   |

【OK記述例】

## 店舗一覧

### 東京都

| 店名   | 住所 |
| ------ | ---- |
| 渋谷店 | ○○   |
| 新宿店 | ○○   |

### 神奈川県

| 店名   | 住所 |
| ------ | ---- |
| 横浜店 | ○○   |
| 川崎店 | ○○   |

人間としては私はどっちでもいいかなという感覚です。もしどっちでもいいなら、ついでにAI向けにしておくのもよいでしょう。

どっちでもいいというのは迷いの元でもあります。迷ったときの判断軸として「AI向けとしてはどうだろう?」といったん考えるときの良い指針になるかなと思います。

データの仕上がりとしては、以下のような別解も考えられそうです。

## 店舗一覧

| 都道府県 | 店名   | 住所 |
| ------- | ------ | ---- |
| 東京都   | 渋谷店 | ○○   |
| 東京都   | 新宿店 | ○○   |
| 神奈川県 | 横浜店 | ○○   |
| 神奈川県 | 川崎店 | ○○   |

AI向けに書くと人間が扱いにくくなるかもしれない点

ちょっと悩ましいかもと思ってるのがこちらです。

具体的には「内容を予測できる具体的な見出し名」(P155)です。先ほどと同じく、本書の趣旨を汲んだうえで私独自の例を挙げます。

【NG記述例】

## 会員登録画面の仕様

### 概要
会員登録するための画面です。

### 入力項目
画面には以下の入力項目を設けます。

【OK記述例】

## 会員登録画面の仕様

### 会員登録画面の概要
会員登録するための画面です。

### 会員登録画面の入力項目
画面には以下の入力項目を設けます。

NG記述例のように単に### 概要 と書いても、階層構造を考慮すると「会員登録画面の(概要)」脳内補完できます。一方、AI向けとしてはちゃんと具体的なキーワードを見出しに含めるほうがよい、という工夫の話でした。

この程度であればよいのですが、ボリューム次第では冗長な見出しにもなり得てしまうかなとも思ったのが悩ましい点でした。たとえば、画面名が変更されたときに変更箇所が多くなってしまうという点。

悩ましいと言ってますが、私が懸念してるのはどちらかというと書き手の都合です。読み手のことを考えると、AI向けも人間向けも同じかもしれません。もし ### レベルの見出しが多くあったら、人間の読み手としても「あれ?何の話だっけ?」となってしまう気もしました。となると、やはり書き手としては冗長に感じても、具体的な見出しにする方がよさそうだとも思いました。

おわりに

書籍「エンジニアのためのAIに伝わるドキュメントの基本」の概要と、私なりの読み方についてご紹介しました。

「配置」や「構造」については、機械の気持ちになって(?)、トレーサビリティや権限などがあるか。「記述」は、基本的には人間向けと同じポイントをおさえつつ、より親切に書くことが求める、と理解しました。

性質上、1つの工夫がすごく効くというよりは、細かい工夫を積み上げていく必要があるかなとも感じました。

ちょうど気になっていた分野だったの、本書がありがたかったです!

おまけ

↓どうするのがいいかご存じの方いらっしゃたら、リプいただけるとありがたいです。

[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 があるみたいですね。