JANOG56 Meeting オンライン参加レポート

はじめに

2025/07/30-8/1 に JANOG56 Meeting in MATSUE が開催されました。

www.janog.gr.jp

今回は現地参加はできませんでしたが、オンラインで参加しました。

実際に現地で参加した人数は 2,659人（閉会宣言にて発表あり）。近隣ホテルの事情的に参加人数が少なくなるのではとの声もありましたが、大規模な人数になったようです。

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

なお、各プログラムの詳細ページから資料や、アーカイブ動画が見れます（一部アーカイブなし）。アーカイブ動画は 2026年2月下旬頃までの公開予定とのことです。

今回もアーカイブ期限が長めでありがたいです。

視聴プログラム

当日リアルタイムで視聴できたプログラムについてです。

ネットワーク運用自動化におけるドリフト解消機能の実現と、その後の苦労

www.janog.gr.jp

ニッチかもしれませんが、個人的に以前から気になっていたテーマだったため視聴しました。

Git にコンフィグを置おいてこれを神様として扱い、Git 経由で実機に設定変更を行う構成、何かしらの事情で実機を直接設定変更すると、Git 上のコンフィグと実機のコンフィグに差分が出てしまう問題があります。

これの対処として、以下のような仕組みを実装したというご紹介でした。

• GitLab への コンフィグ push 時に、事前パプラインで実機のコンフィグ差分を検出さる
• 差分がある場合は、実機のコンフィグを GitLab 側へ反映（同期）させるパイプラインを手動実行する
• この同期パイプラインが、GitLab 側に差分を取り込むためのマージリクエストを作成する
• 人が承認して取り込む

GitLab 経由で変更の流れはくみつつも、実機とのコンフィグ差分があれば実機を正として受け入れて GitLab に取り込む、といった感じです。

なお、同期パイプラインを定期実行していないのは、パフォーマンスなどの課題があるためだそうです。

ディスカッションにおける大きなネタの一つは、パイプラインが作成した差分取り込みマージリクエストに対して人の承認が必要かどうかという点です。

資料の中では、開発者視点としては、同期は実機への変更ではないため承認は不要で、現場の視点としては従来からの習慣に則って承認が必要、と意見が分かれていたそうです。今回の実装としては承認が必要という流れになっていました。

ディスカッションや Slack のやりとり全体としては承認不要という意見が多かったように思います（同期パイプラインでちゃんと同期できることとセット）。実機コンフィグを神とするタイミングがあるなら承認は不要という理由付けもありました。承認不要にできれば、人が入る余地がなく一気通貫でできる箇所が増えて理想形になっていきます。

そもそも実機に直接設定するのをやめるのが理想という話もありつつ、障害発生時に1分1秒を争う場面や、試行錯誤が必要な場合は、そうも言っていられないのだろうなと思いました。

別の話題としてディスカッションの二人目のタイミングであったのが、HEAD への変更のみが許可されているのかどうか。今回は HEAD からブランチを作成してマージリクエストを出すという流れのようでした（ディスカッションやりとりを正しく理解できているかやや自信なしです）。複数ブランチからいろんなタイミングでマージリクエストがくると扱いが複雑になってしまうと思うので、この手の制約はシステムをシンプルにしておくためには良いなと思いました。

やや余談ですが、本プログラムの詳細ページでは「SNSやSlackでの議論や情報共有」は「制限しない」とあり、スライド右上には「SNS投稿禁止」のアイコンがありました。ブログへの投稿が可能かどうか登壇者に Slack でお伺いしたところ、ご快諾いただきました。ありがとうございます！

AI Agent によるDC運用自動化の実装と課題

www.janog.gr.jp

内製で kurouto という自動化ツールを開発しており、それでも対応できなかった残り 8% の作業を、AI エージェントを作って解消するというお話です。

まず、明確なロジックを組める部分はルール処理エンジンを残してフィルタリングしておく、というのが前提でした。全部をAIで、全部をルールベースで、ではなく順番を含めて適材適所で使われている印象です。

印象的だったのは、カジュアルにどんどん自分たち用の MCP サーバーを作って使うのが良いという点。OSS 系の MCP サーバーはできることが多くて強い権限が必要だったり、汎用的過ぎることもあるそうです。

手順書をプロンプトとして使うという話がありましたが、この流れで、やっぱドキュメントって大事だなと思いました。

なお、ディスカッションパートで話題に上がりましたが、切り分けはAIがやるのではなく、ネットワークエンジニアのノウハウをルールベースで組み込んでるそうです。これはこれですごいですね。

“自動化やってみた”のその先へ～KDDIネットワーク検証の自動化、現場エンジニアの奮闘と学び～

検証の自動化の取り組みにおいて、時間の確保やどのように進めていったというお話でした。

時間との確保の仕方は、空き時間にやるものではなく「正式なプロジェクト」にして、トップダウンのアプローチをとったそうです。

興味深かったのは、初期開発の対処の選び方について。いろいろヒアリングやアンケートを行ったときに「アンケートを最も詳細に記載してくれた」部署があったそうで、これが選定理由の一つでした。

ツールの選定もなかなか悩ましいところだとは思いますが、この発表では、持続可能な組織開発というコンセプトがあったためか Robot Framework（資料上の表記は Flamework でしたがおそらく Framework） を採用したそうです。「数日程度のOJTでNWエンジニアもシナリオを作成可能（資料P23）」とのこと。ネットワークエンジニア自身が前向きに取り組むための考慮ですね。

成果としても、作成した130個のシナリオのうち、約20シナリオは初めて自動化に挑戦するネットワークエンジニアが作成を担当されたそうです。

アーカイブ視聴予定

当日参加できたプログラム以外にも、興味深いプログラムがあるため、アーカイブが公開されているうちに視聴しようと思います。

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

• LLMでネットワーク構築運用支援実験@Interop Tokyo 2025 ShowNet - JANOG56 Meeting in Matsue
  • Interop Tokyo 2025 ShowNet ステージの「ShowNetに特化させた生成AI Chatbotはどれほど構築・運用の助けになったのか?」のその後
• システム開発の常識が変わる!? ~MCP で SSoT x LLM を実現したら起きること~ - JANOG56 Meeting in Matsue
• 生成AIインフラを構築してわかったケーブリングの重要性 - JANOG56 Meeting in Matsue
• 大規模災害発生時における通信事業者連携 - JANOG56 Meeting in Matsue

プログラム以外

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

過去プログラムへの返答 LT

たぶん今回が初めてだと思うんですが、過去のプログラムをきかっけにして自分たちの業務を改善したり、当時の発表者自身がさらにその後の話をするといった企画がありました。

www.janog.gr.jp

人と時間のつながりを感じて、よい企画だなぁと思いました。

Slack のありがたさ

いつも通り、会場（部屋）ごとに Slack のチャンネルが用意されていました。

今回、各プログラムのディスカッションパートでは、オンライン側にはマイクが用意されない形式でした。なので、そのタイミングでは直接聞くことはできませんでした。Slack があることで、非同期でのディスカッションができたのがありがたかったです。

実際、プログラム途中に書いたことに対して、登壇者の方から返信いただいたこともありました。しかも登壇中です。感謝！

アトリビュートステッカー

自分の立場や興味がどういう属性かを示す「アトリビュートステッカー」が今回もあったようです。

以前は「I ❤ 自動化」がありましたが、今回はなかったようです（参考: 会場諸注意PDF）。

復活するかひっそり気になっています。

おわりに

内容的には AI の話が今回もいくつもありました。前回の JANOG 54 の少し後くらいに盛り上がった MCP の話もよく聞きました。

前回 JANOG 55 からオンライン参加が復活して大変助かりました。オンラインの場合は参加登録が不要だったのは今回が初めてだった気がします。

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

弊社のブース対応をしてくれたメンバーにも感謝です。

次回の JANOG 57 Meeting は 2026/02/11-02/13 に大阪市で開催予定だそうです。さくらインターネットさんがホスト。「ちょっと寄れるJANOG」がテーマだそうで、これだけアクセスがしやすい JANOG はなかなかないと思います。

祝日の 2026/02/11 を含む日程なのも特徴でしょうか。

note.com

参考

show int さんの関連動画

www.youtube.com

www.youtube.com

www.youtube.com

弊社弊品 NEEDLEWORK 担当部署のレポート

needlework.jp

X ポストまとめ

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

posfie.com

今回初めて知ったのですが、posfie というのは、Togetter から分割したサービスのようです。

私と JANOG のこれまで

• JANOG55 Meeting オンライン参加レポート - てくなべ (tekunabe)
• JANOG54 Meeting レポートその2: 登壇編「自動化の教育ってどうやってますか？」 - てくなべ (tekunabe)
• JANOG54 Meeting レポートその1: 参加編 - てくなべ (tekunabe)
• JANOG54 Meeting レポートその2: 登壇編「自動化の教育ってどうやってますか？」 - てくなべ (tekunabe)
• JANOG53 Meeting アーカイブ視聴レポート - てくなべ (tekunabe)
• JANOG52 Meeting 参加レポート - てくなべ (tekunabe)
• JANOG51 Meeting 参加レポート - てくなべ (tekunabe)
• JANOG50 Meeting in Hakodate 参加・登壇レポート - てくなべ (tekunabe)
• JANOG49 Meeting in Kagoshima 参加レポート - てくなべ (tekunabe)
• JANOG48 Meeting 参加レポート - てくなべ (tekunabe)
• JANOG47 Meeting in Fukuoka 参加レポート - てくなべ (tekunabe)
• JANOG46 Meeting in Okinawa 登壇・参加レポート - てくなべ (tekunabe)
• JANOG45 Meeting in Sapporo に参加して視野を広げる必要性を感じた - てくなべ (tekunabe)
• JANOG44 レポートその1【参加編】 - てくなべ (tekunabe)
• JANOG44 レポートその2【登壇編】ここからはじめよう、運用自動化 - てくなべ (tekunabe)
• [Batfish] JANOG43.5 で「ネットワークコンフィグ分析ツール Batfish との付き合い方」という発表をしてきました - てくなべ (tekunabe)
• JANOG43 レポートその1【参加編】 - てくなべ (tekunabe)
• JANOG43 レポートその2【登壇編】自動化の行き着く先は? - てくなべ (tekunabe)
• JANOG43 レポートその3【ハッカソン編】スタッフ兼参加者として - てくなべ (tekunabe)
• 【JANOG42】Ansible ネットワーク自動化チュートリアルを発表してきました - てくなべ (tekunabe)
• 【JANOG42】私にとっての「つなぐ、つたえる、つみあげる」 - てくなべ (tekunabe)
• JANOG41.5 で「もっと気軽に始めるAnsible」という発表をしてきました - てくなべ (tekunabe)
• JANOG41 Meeting in Hiroshima 参加メモ - てくなべ (tekunabe)
• JANOG41で「勉強会のフィードバックから得られた自動化への壁」という発表をしてきました - てくなべ (tekunabe)

[Ansible/AAP] ansible-core 2.17 のマネージドノードのサポートに RHEL8 がない理由を推察する

はじめに

現在の Ansible Automation Platform の ライフサイクルが示されたページに、ansible-core の各バージョンとサポートされるバージョンや、サポートされるマネージドノードのOS (Supported Managed OS (RHEL))が表にまとまっています。

access.redhat.com

Python や PowerShell のバージョンの対応までの情報であれば、コミュニティのドキュメントにもまとまっています。私が把握している限り、マネージドノードのOS（RHEL）の情報は AAP ドキュメント独自の情報です。

2025/08/06 時点の情報では ansible-core 2.16 では RHEL 7 – 10 ですが、2.17 では RHEL 9 – 10 となっていています。

2025/08/06 時点の https://access.redhat.com/support/policy/updates/ansible-automation-platform より

このことから「 ansible-core 2.17 では RHEL 8 のマネージドノードをサポートしていない」と読み取っていました。この点について、以前からなんでだろうと思っていました。

最近、別件で調べていたこととこの件が繋がった（と思う）ので、私が推察したことをまとめておきます。

推察

まず、ansible-core 2.16 のマネージノードでサポートされる Python は 2.7, 3.6 – 3.12 で、ansible-core 2.17 では 3.7 – 3.12 です。

ansible-core 2.17 では Python 3.6 がサポートされていないので Python 3.7 以上を利用する必要があります。普通に考えれば、RHEL 8 であっても Python 3.7 以上をインストールすればいいじゃんて話になると思います。

困るのが ansible.builtin.dnf モジュールです。このモジュールは Python のバインディングが必要です。しかし、RHEL 8向けには DNF のPython バインディングが Python 3.6 用までしか用意されていません。

The python38 and python39 modules and the python3.11 and python3.12 package suites do not include the same bindings to system tools (RPM, DNF, SELinux, and others) that are provided for the python36 module.

これがネックで、ansible-core 2.17 のマネージドノードのサポートに RHEL8 がないのかなと思っています。

おそらく ansible.builtin.ping のような他の ansible.builtin のモジュールは、RHEL 8 + Python 3.8 なマネージドノードに ansible-core 2.17 が使える気もする（未検証）のですが、組み込みのモジュールである ansible.builtin.dnf が動かないのであれば、動くとは言えないって話なのかなと。

私なりにまとめますと・・

• ansible-core 2.17 のマネージドノードの Python バージョン要件が 3.7 – 3.12
• しかし ansible.builtin.dnf の動作に必要な Python バインディングは、RHEL 8 向けには、Python 3.6 までしか用意されていない
• 結果的に、ansible-2.17 では マネージドノードとして RHEL 8 はサポートされない

なにか指摘などありましたら、@akira6592 までご連絡いただけるとありがたいです。

Netmiko が NEC IX ルーターに対応したので試してみた

はじめに

先日、ネットワーク機器の操作を自動化できる Python ライブラリ、Netmiko のバージョン 4.6.0 がリリースされました。

github.com

このリリースで、NEC IX ルーターにも対応したそうなので、少し試してみます。

実装者は inaba-vdom-0（X inaba_aho_me）さん。ありがとうございます！！

• 検証環境
  • netmiko 4.6.0
  • python 3.11.10
  • IX2105 Version 10.2.42

[2025/06/29 追記]

実装者による記事も、Netmiko 4.6.0 リリースに伴って更新されました。一番正確な記事なのでぜひご覧ください。

qiita.com

そもそも Netmiko とは

このブログで Netmiko を取り上げる ことが多くなかったため、前置きです。

Netmiko は、Cisco IOS や、Juniper Junos、YAMAHA RTX シリーズ などのネットワーク機器を操作するための Python ライブラリです。ネットワーク自動化系の書籍、資格でも取り上げられることが多いメジャーなライブラリです。Paramiko をネットワーク機器向けにしたものです。

同じ分野の Python ライブラリだと、他には NAPALM、nornir、scrapli などがあります。

Ansible が Playbook 経由で操作するのとは異なり、Python のコードとして実装するタイプのものです。

これまでもさまざまなプラットフォームに対応していましたが、今回 NEC IX ルーターへの対応が加わった形です。

ログイン、ログアウト、各種モード変更がメソッドで抽象化されていたり、プラットフォーム固有のプロンプトハンドリングが必要なため、プラットフォームごとに対応が必要という事情です。抽象度は低いので、他のライブラリやツールに比べると、対応しやすい印象です。とはいえ、プラットフォーム固有の仕様を Netmiko のどのメソッドに対応させるかは、悩むことも少なくないのではと思っています。

だいぶ古くなってしまいましたが、Netmiko は以下の資料の中でも紹介しています。事情が変わっているところもありますが、抽象度が低いという設計は変わっていません。

ネットワーク自動化、なに使う？ ～自動化ツール紹介～(2017/08/18追加開催) | PPT

準備

久々に使うので、まっさらな venv で Netmiko をインストールします。

% pip install netmiko
...(略)...
% pip list | grep netmiko
netmiko          4.6.0

お目当ての 4.6.0 がインストールできました。

基本的なお作法

device_type の指定

Netmiko では、各種接続の設定を ConnectHandler に渡します。その際、どのプラットフォームなのかをdevice_type を指定します。

NEC IX ルーター の場合、device_type には SSH であれば nec_ix を、TELNET であれば nec_ix_telnet を指定します。後述するサンプルでは、SSH を利用します。この指定により、内部的にプラットフォーム固有のモード変更やプロンプトハンドリングをしてくれるようになります。

なお、Netmiko にはdevice_type を自動判定する機能もあります。自動判定する場合は、device_type には、"autodetect" を指定します。今回の IX ルーター対応の場合は、内部的には show hardware を実行した結果に IX Series が含まれているかをチェックしているようです。ここまで実装いただいてありがたいです。

モード変更など

「そもそも Netmiko とは」で、モード変更などが抽象化されてると書きました。具体的には、netmiko.BaseConnection クラス内のメソッドで抽象化されています。

代表的なものを以下にまとめます。（コードをざっと拝見しただけですが・・）

メソッド	実行されるコマンド	補足
enable	svintr-config	他にコンフィギュレーションモードに入っているユーザーがいたら追い出して自分がはいる（参考）
config_mode	configure
save_config	write memory

ページャーの無効化には、内部的にterminal length 0 を利用しているようです。

show コマンドの実行

まずは、show コマンドを利用して情報を取得して、その結果を画面に表示してみます。ここでは show versions で試します。

なお、機器側は SSH 接続を有効にしていて、Netmiko からも SSH 接続を利用します。device_type はまずはオーソドックスに明示しています。

少々荒いですが、今回は administrator 権限があるユーザーを利用します。

from netmiko import ConnectHandler

ix01 = {
    "device_type": "nec_ix",     # デバイスタイプの指定
    "host": "10.0.0.5",      # 対象デバイスの IP アドレス、ホスト
    "username": "dummy_user",    # ログインユーザー
    "password": "dummy_password" # ログインパスワード
}

command = "show version"
with ConnectHandler(**ix01) as net_connect:
    output = net_connect.send_command(command) # コマンドの実行

print(output)   # 結果の表示

実行します。

% python ix.py 
NEC Portable Internetwork Core Operating System Software
IX Series IX2105 (magellan-sec) Software, Version 10.2.42, RELEASE SOFTWARE
Compiled Sep 09-Fri-2022 13:40:53 JST #2 by sw-build, coregen-10.2(42)

ROM: System Bootstrap, Version 19.1
System Diagnostic, Version 19.1
Initialization Program, Version 19.1

System uptime is 72 weeks 21 hours 51 minutes
System woke up by reload, caused by power-on
System started at Feb 09-Fri-2024 22:16:22 JST
System image file is "ix2105-ms-10.2.42.ldc"

Processor board ID <0>
IX2105 (MPC8314E) processor with 131072K bytes of memory.
2 GigaEthernet/IEEE 802.3 interfaces
512K bytes of non-volatile configuration memory.
16384K bytes of processor board System flash (Read/Write)

Current configuration is based on "startup-configuration"
Default console is web.
% 

無事に show コマンドの結果が表示されました。

なお、show running-config のように、コンフィギュレーションモードになっている必要がある show コマンドは、事前に enable() しておきます。

command = "show running-config"
with ConnectHandler(**ix01) as net_connect:
    net_connect.enable()    # svintr-config が実行される
    output = net_connect.send_command(command)

print(output)

設定変更してみる

今度は設定変更してみます。

ここではインターフェースの description を設定する簡単な例で試します。

from netmiko import ConnectHandler

ix01 = {
    "device_type": "nec_ix",     # デバイスタイプの指定
    "host": "10.0.0.5",      # 対象デバイスの IP アドレス、ホスト
    "username": "dummy_user",    # ログインユーザー
    "password": "dummy_password" # ログインパスワード
}

# 設定したいコンフィグをリストで指定
config_commands = [ "interface GigaEthernet0.0",    
                    "description hogehoge"]
with ConnectHandler(**ix01) as net_connect:
    output = net_connect.send_config_set(config_commands) # 設定の投入
    net_connect.save_config()  # write memory

print(output)   # おまけ的ですが戻り値を表示

実行してみます。なお、実行前の desciption は未設定です。

% python ix_config.py
interface GigaEthernet0.0
IX01(config-GigaEthernet0.0)# description hogehoge
IX01(config-GigaEthernet0.0)# exit
IX01# 
%

出力があるのは、おまけ的に print() しているためです。

手動で確認してみると、無事に running-config にも startup-config にも（write memoryしたため）設定変更されてました。

実行コマンドをデバッグ

今回のケースに限りませんが、DEBUG レベルのログ出力をすると、内部的に実行されるコマンドが確認できました。

例えば、

import logging
logging.basicConfig(filename='debug.log', level=logging.DEBUG)
logger = logging.getLogger("netmiko")

のように仕込んでおくと、以下のような内容を確認できました。

...(略)...
DEBUG:netmiko:read_channel: 
DEBUG:netmiko:In disable_paging
DEBUG:netmiko:Command: 
terminal length 0

DEBUG:netmiko:write_channel: b'\nterminal length 0\n'
DEBUG:netmiko:read_channel: 
...(略)...

おわりに

Netmiko で NEC の IX ルーターの show コマンド事項や設定変更を試してみました。

日本のベンダーの機器に対応するのは嬉しいですね。あらめて機能追加ありがとうございました！

Interop Tokyo 2025 参加レポート（主に ShowNet）

はじめに

2025/06/11-13（現地展示期間として）に開催されたInterop Tokyo 2025に参加してきました。

ShowNet の展示やセッションを見てきましたので、いくつかまとめます。

※ 口頭で聞いたあいまいな記憶を思い出しながら書いた記述が含まれます。正確な情報は一次ソースをあたっていただくようお願いします。何かご指摘ありましたら @akira6592 にご連絡いただけるとありがたいです。

■ 1. ShowNet 関連

Interop といえば ShowNet。

ShowNet は、多くのベンダーの最新鋭の機器を実際に動作させて相互接続性（Interoperability）を検証する大規模なネットワークです。来場者や展示ブースからのインターネット接続性を提供する役割も持っています。新しくて分からないものが満載ですが、毎年これを見るのがたのしみにしています

この記事では、各ラックで気になった機器や、ShowNet ステージ（解説してくれるプログラム）についてまとめます。

1.1. ShowNet ラック

各ラックで気になった機器についてです。

対外接続回線 / 対外接続ルータ (#N-1 / #N-2 ラック)

#N-1

#N-2

ShowNet と外を接続する部分。合計2.335Tbps。

足元にはいつものように、対外接続の線が見えるようになっています。IPA との線があるのが今年の特徴でしょうか。

対外接続の線（足元）

BGP によるピアリングには、認証方式として、MD5 ではなく TCP-AO (Authentication Option)も採用したそうです。

TCP-AOの説明（ラック横ホワイトボード）

TCP-AO は初見だったので、A0 （エーゼロ）か、AO(エーオー)か分からなかったのですが「エーオー」が正しいとしっかり覚えました。トランスポート層での認証なのだそうです。

TCP-AO について（スライド資料より）

[2025/07/03 追記] 参考スライド

speakerdeck.com

コアネットワーク （#N-3 ラック）

コンテナでルートリフレクターを構築しているそうです。

XRd と cRPD

セキュアリモートアクセス （#N-5 ラック）

ShowNet の機器をリモートからアクセスするための機器たちです。方式は4種類あって、その中の SMART GATEWAY という機器ではブラウザがあればアクセスできる仕組みなのだそうです。手軽ですね。

マネジメントネットワークは広い L2 で構築されているようですが、作業者の担当ごとにアクセスできる機器が制限されているそうです。

VXLAN-GBP という仕組みで実現され、「マイクロセグメンテーション」という言葉が出てきました。GBP を BGP に空目してしまったのですが、Group Based Policy の略だそうです。

参考: VXLAN Group Based Policyを利用したマネージメントセグメント:Geekなぺーじ

セイコーソリューションズ アクセス管理ソフトウェア SmartJumper もこのラックに入っていました。

#N-5上部

[2025/07/03 追記] 参考スライド

speakerdeck.com

サイバー脅威検出 （#N-6 ラック）

光の TAP アグリゲーターとして Juniper の QFC5220-32CD が稼働していました。そもそも TAP アグリゲーター自身初めて知りました。

TAP アグリゲーター

統合監視 / フロー監視（#N-7 ラック）

Packetmaster EX5 という機器で、監視トラフィックを集約・転送しているそうです。結構なトラフィック量になるのではないでしょうか。

Packetmaster EX5 など

高密度パッチパネル / ロボット配線システム（#N-8 ラック）

去年知っておもしろいなと思った、高密度ながらも両脇のポートが避けてくれるような仕組みのものは、「揺動カセット」と呼ぶことを今回知りました。

揺動カセット

ネットワーク品質検査（#N-9ラック）

弊社が、今年もコントリビューターとなって、ワークテスト自動化製品 NEEDLEWORK が利用されていました。昔は物理アプライアンスだった本製品ですが、今は Windows で動く exe のソフトウェアです。NEEDLEWORK がインストールされた小さな筐体がラッキングされていました。

NEEDLEWORK と後述の ROME mini

よく見ると、筐体には NEEDLEWORK のロゴが見えます。

NEEDLEWORK のロゴが見える

[2025/082/27 追記] ShowNetコントリビューションレポート：NEEDLEWORKによるファイアウォールポリシーテストの自動化アプローチ | ネットワークテスト自動化 NEEDLEWORK Blog

また、本ラックの下の方には 光配線切替ロボット ROME mini がありました。検査をするにあたって、いろいろ接続を切り替える必要があるので、こちらが大活躍するそうです。ここ数年、毎回眺めていますが実際にがちゃがちゃ動くところを拝めていません。今回は最終日の 16:00 頃から動かす予定、と書かれていましたが、予定が合わずでした。

エンタープライズネットワーク (#N-10 / #N-11 ラック)

400GbE 対応のインラインのファイアウォールとして、Juniper Networks SRX 4700、Palo Alto Networks PA-7500 が動いていました。

400GbE 対応のインラインのファイアウォール

ホワイトボードに書かれている「ラスリゾ」は「ラストリゾート」のこと。ShowNet におけるラストリゾートは、Juniper Networks SRX4600 が動いていました。各機器の障害時にも対応できるように用意された、迂回経路を確保するためのもののようです。

ラスリゾ

トポロジー図でいうとほぼど真ん中。今まで気が付かなかったのですが、確かに去年のトポロジー図にもありました。

トポロジー図 に吹き出し追加

Wi-Fi / オペレータ用ネットワーク（#N-12 ラック）

会場内で利用できる Wi-Fi として、Wi-Fi 6E や Wi-Fi 7 のような新しい規格に対応する AP が動いていました。一番多いのが Wi-Fi7 対応の 41台。

効率化の技術と、法律的な認可の組み合わせで、広帯域や低遅延などでより品質が高くなっていきますね。

#N-12

参考: 6GHz帯の専用SSIDを用意、今年の「ShowNet Free Wi-Fi」。Wi-Fi 7のMLOも、とあるブースで体験可能【Interop Tokyo 2025】 - INTERNET Watch

[2025/07/03 追記] 参考スライド

speakerdeck.com

5G （#N-13 ラック）

去年までの数年間はローカル 5G の取り組みがありましたが、いったん落ち着いたということで、今年はキャリア 5G 連携がテーマになっていました。「閉域」というのもポイントでしょうか。

全国の放送局との映像転送で使っているそうです。

#N-13

[2025/07/03 追記] 参考スライド

speakerdeck.com

Media over IP / Media-X 時刻同期システム （#N-14 ラック）

時刻同期の仕組みとしては、GPS アンテナが2本立っていて、途中で光ケーブルを経由して、まだ同軸になって、グランドマスタにつながっているようです。

時刻同期系

NTP より精度高い時刻同期の仕組みを持つ PTP は、映像分野などで活躍するそうです。

時刻同期はA系、B系と冗長化されて用意されています。以前聞いたお話ですと、屋上のGPSアンテナの雷対策なんだとか。備えが必要なほど重要なのですね。

Media over IP / Media-X network （#N-15 ラック）　

リアルタイムで映像を最適化する機器として、Vecima Solutions KeyFrame が動いていました。この分野は疎いのですがいろいろすごい機器があるものですね。

VECIMA ロゴのある上の 2U の機器が KeyFrame

また、今年は Media over IP という言葉以外にも Media-X という言葉も目立ちました。

参考: Ｍｅｄｉａ―Ⅹが魅せた放送コンテンツ共有のミライ～在阪４局が共同でＭｏＩＰを実証実験 | 電波タイムズ | 日本唯一の放送・情報通信の専門紙の電波タイムズのニュースサイト

連携している放送局が去年より増えている気がします。

放送局連携

[2025/07/03 追記] 参考スライド

speakerdeck.com

インテントベースドネットワーキング/仮想化基盤 （#D-2 ラック）

ラックのタイトルに「インテントベースドネットワーキング」が含まれるのには少し驚きました。

具体的には、Apstra Data Center Director が入っていました。

インテントベースドネットワーキング

RoCE v2 ネットワーク・AIコンテナ基盤 （#D-4 ラック）

キーワードでしか追えてないですが「Ultra Ethernet」という文字が。AI向けの高速なネットワークの仕組みだそうです。分散処理するにあたって効率よく通信させる必要があるということでしょうか。

Ultra Ethernet

この辺りはトポロジー図で見ると 400G / 800G の太い線があるところですね。

参考: RoCEとUltra Ethernetの検証：ShowNet 2025:Geekなぺーじ

1.2. ShowNet ステージ: AI基盤からエッジまで、多様化するネットワークとテストの進化

ShowNet ステージは、NOCチームメンバーなどのみなさんから、ShowNet で使われている機器や技術、取り組みなどの紹介がされるプログラムです。

気になっていた分野ですが、スケジュールをミスって最後の数分間しか聞けませんでした・・。

OTG はここ数年 ShowNet や JANOG で聞き始めた言葉で、気になっています。

試験自動化について（スライド資料より）

最後に、弊社のネットワークテストの自動化 NEEDLEWORK によってコントリビュートしていることを確認できました。ご紹介ありがとうございます。

検証分野のコントリビューター一覧

[2025/07/03 追記] 参考スライド

speakerdeck.com

1.3. ShowNet ステージ: ShowNetに特化させた生成AI Chatbotはどれほど構築・運用の助けになったのか?

今回、ShowNet の構築、運用を支援するため Chatbot を開発して利用されたそうです。

セッションにある「ShowNetに特化」というのは以下によるところです。

• 昨年の ShowNet の機器設定、今年の設計資料、今年の運用ガイドをベクトルデータベースにいれた RAG を構成。Azure OpenAI Serviceを利用
• MCP 経由で実際に ShowNet の機器に SSH 越しにCLIで操作upa/netmiko-mcp-serverを利用
  • 別の記事によると、情報取得系の操作に限定している模様
• MPC 経由で チケットシステムを参照

構成図

これによって、ChatGPT のようなUI（今回は chainlit）で、インターフェースの情報を表示させたり、チケットの情報を表示させたり、トラブルシューティングの支援をしてもらったりできます。ガイドラインも読み込んでいるため、ガイドラインに即した回答をしてくれるようです。

チャットの流れは以下のデモ動画が分かりやすいです。

www.youtube.com

今回肝なのが、はたしてこれが有用だったのかというフィードバックを収集している点です。実際の ShowNet のような規模の環境で、100人以上（確か）が実際に Chatbot を使ってもらって、回答ごとに Good 👍️ や Bad 👎️ をフィードバックする方式です。

このセッションでの速報値としては Good が「6割弱」だったそうです。なかなか解釈に悩むリアルな数字な気がします。

6割弱

複雑なトラブルシューティングについては、熟練者が対応したほうが早いケースもあったようす。一方で、機械に任せるということはスケールさせやすくなる面があるため、全部人がやればいいという話でもありません。やはり使い分けは必要そうです。

使ってみて

現在と未来

なお、最終的な結果や詳細については JANOG 56 で発表があるそうですので、楽しみです。

www.janog.gr.jp

[2025/06/25 追記]

www.janog.gr.jp

参考記事: 生成AIによるネットワーク構築・運用支援実験 : ShowNet 2025:Geekなぺーじ

1.4. ShowNet セルフツアー

セルフツアーという取り組みがあったので、利用させていただきました。

www.youtube.com

まず、ホール4エスカレター付近の申し込みカウンターで端末をお借りします。そして、ShowNet のラックに移動すると、付近のラックに関する情報をタブレット上で見られるというものです。Juniper Mist AP シリーズの vBLE 機能によって位置情報が解析されるそうです。

以下のような感じで位置情報が可視化されます。青いのが自分で、各ラック前の黄色い印を目指す形です。位置情報の認識にはラグがあるので、慌てずゆっくり利用しました。

マップ

実際に見られるのは NOS メンバーによる解説や資料です。

資料は、ラック横や Side View（出島(#D-*ラック)の横にあるスライド表示エリア）で流れるもので、これが手元で見られる点が良かったです。資料は自動ページ送りされるのを見るのではなく、自分でページを繰りできるので助かりました。いつもこの資料を会期内にちゃんと見たかったので。（待てば後日 SpeakerDeck 関連資料が公開されると思います）

タブレット貸出の時間制限は30分。のんびりしていたら最後の方はバタバタしてしまいました。

ShowNet ウォーキングツアー(1,000円)や、テクニカルツアー&セッション(10,000円)は、予約が埋まったり時間が決まったりしているので、ややハードルが高いかもしれません。

一方、セルフツアーは、タブレット端末貸出の申込みこそ必要なものの、自分の時間で利用しやすく無料なので、手軽でアリだなと思いました。このような仕組みを用意していただいてありがたいです。

参考: 以下動画 6:41 頃から仕組みの説明

youtu.be

■ 2. 展示場内セミナー

参加した展示場内セミナーについてです。

2.1. Intentへの挑戦 ― 自律型ネットワークの未来を拓く

COMARCH 社が提供する、生成AI を活用した Intent-Based (意図)なネットワーク管理のプロダクトの紹介でした。

これまでも Intent-Based なプロダクトや手法は見聞きしてきましたが、特徴的だと思ったのは、ビジネス、サービス、リソースの各領域での生成AIの活用です。 意図といってもいろいろな抽象レベルがあります。これまで以上に、幅広い抽象レベルでやり取りできるのかなと興味深かったです。

ビジネス、サービス、リソースの各領域

AIエージェント同士の連携による障害対応

詳細に紹介されたのは障害対応における活用です。

トラブルチケットなどを起点にして、 AI エージェント「たち」が連携して、解決に向かわせるというものです。

各エージェントには専門分野があって、相互に連携し合って自律的にすすめてくれるそうです。キャラ（？）がついてることもおもしろいです。

具体的には、エージェント同士が以下のような会話を展開していきます。

エージェントたちの会話

特徴的だと思ったのが、そのエージェント同士の会話のやり取りを人間が確認できることです。「で、結局どういう理由で何してくれたの？」が分かり、透明性を高めるためには必要な機能だと思いました。

詳細を聞き逃してしまいましたが、ネットワーク環境のデジタルツインを用意して、変更作業を事前に検証できる機能の紹介もありました。個人的な感覚の話ですが、この業界でも「デジタルツイン」という言葉を利用することが多くなってきた気がします。

対応しているネットワーク機器が気になって、あとブースによってさらにお話を伺ったところ、さまざまなネットワーク機器に対応しているとのことでした。

OSS、 Autonomous Networks Level

途中 OSS という言葉がでてきましたが、後で調べたら Open Source Software ではなく、「Operations Support Systems」のことのようです。

順番が前後してしまいますが、途中で自律性レベルのお話がありました。どの作業までを人がやるのか、システムがやるのかによってレベルが分けられています。このレベル分けの定義は今回初めて知ったので参考になりました。TM Forumというオペレーション団体にて定義されているのですね。

自律性レベル

参考: オペレーション標準化団体TM Forumの動向 | NTT技術ジャーナル

■ 3. ブース

近年はブースを回れるうまい段取りができず、あまり回れていません・・・。

3.1. セイコーソリューションズさん

共同のインラインウェビナーなどでお世話になっているセイコーソリューションズさん。

今回は、弊社ブースの真裏でした。弊社ブースから「AnsibleとSmartCSの連携によるZTPのご案内はこちらへ」という導線がひかれていました。

ブースにはアクセス管理ソフトウェアSmartJumper のキャラである、ジャンガくんがいました。

ジャンガくん

参考: 『Interop Tokyo 2025』（2025年6月11日(水)～13日(金)・幕張メッセ）に出展します | セイコーソリューションズ株式会社

https://f2ff.jp/2025/interop/exhibitor/show.php?id=3001&lang=ja

3.2. YAMAHA さん

ネットワーク機器事業は2025年3月で30周年を迎えたそうです。

年表

やや記憶があやふやですが、私が仕事でいちからルーターを設定した初めての機器は RTX1000 （2002年10月発売）でした。なので思い入れがあります。

上司から提示された複数の機器の中から、私が YAMAHA を選択しました。ヤマハさんがルーターも作っていることを知ったのはその時でした。以降の案件でも、特に VPN 系の案件では RTX シリーズや RT シリーズをよく利用しました。

参考: ヤマハ、小規模単拠点向けの無線LANルーターを参考展示 100GbEアップリンク対応スイッチも - クラウド Watch

https://f2ff.jp/2025/interop/exhibitor/show.php?id=3168&lang=ja

3.3 エーピーコミュニケーションズ（弊社）

ネットワークテスト自動化製品の NEEDLEWORK や、Wi-Fi同時接続テストの AirThreads、ITインフラ運用の自動化支援サービス（弊チーム）の展示です。レッドハットの方にもブースに立っていただき感謝です。

ご来場いただいたみなさま、ありがとうございます！

弊社ブース

https://f2ff.jp/2025/interop/exhibitor/show.php?id=2846&lang=ja

また、今回はシスコさんのパートナーブースの方で、ネットワークSI をしている部署が ファイヤウォールの移行ツールなどの紹介をしていました。この部署は初出展ですが、多くの方がいらして盛り上がっていました。

パートナーブース

動画も撮っていただいたみたいです。ありがとうございます。

www.youtube.com

https://f2ff.jp/2025/interop/exhibitor/show.php?id=2864&lang=ja

おわりに

今年も ShowNet の機器や取り組みの情報収集を中心におこないました。

AI の話を聞くことが多くなり、私からすると壮大な話から、現実的な話までさまざまです。ネットワークの世界は、より早く、より小さく、より高密度で、より省電力で、といったことが進化として挙げられることが多いですが、AI の話はまた毛色が違うようにも思いました。来年もおそらくよく話には上がってくるのだと思います。

ShowNet の構築、運用に関わった NOC、STM のみなさま、ブースでご対応いただいたみなさま、ありがとうございました！

なお、ShowNet のより詳しい説明がされる shownet.conf_ は、今年は 2025/09/11 - 12 に開催されるそうです。今年も無料！

f2ff.jp

参考

gorosuke5656.hatenablog.com japan.zdnet.com cloud.watch.impress.co.jp note.com nttdocomo-developers.jp

Speaker Deck | Easily Share Your Presentations Online

ShowNet 2025 説明スライド集 - YouTube

生成AIパスポート試験を受けました

はじめに

ついさっき、生成AIパスポート試験を受けてきました。

guga.or.jp

エンジニアとして、というよりは、社会人として浅くでもでいいので知っておきたいなと思ったのが動機です。

今年の春の応用情報技術者試験で生成AIと著作権についての問題が出たことも後押しになりました。技術的な側面よりも、AIと社会みたいなテーマのほうに興味がありました。

勉強方法

事前の知識はほとんどゼロの状態ではじめました。

最初は本屋で見つけた以下の書籍を読んで付属の問題を解きました。「公認」の方です。

pub.jmam.co.jp

下調べが雑すぎて、「公式」テキストがあることをあとから知りました。こちらも一通り読みました。

生成AIパスポート公式テキスト　第3版guga.dail.jp

試験当日

私は、2025年6月受験分の申し込みだったの2025年6月のうちだったらいつでも受験可能です。

ということで、気分が乗ったときにふらっと家のPCで受験しました。カメラで監視されることもないので気楽です。

全60問で制限時間は60分。見直し含めて 20 分くらいで試験終了しました。

時間が余ったのは自信満々というわけではなく、考えてもわからない問題があったため、諦めたかたちです。

結果はすぐには出ず、受験完了のお知らせのメールによると「試験期間終了翌月末までに合否通知が各自へ送信されます」とのことです。

なのでは現状は合否はわかりません。

おわりに

この分野は、技術的な深堀りはできる自信がないので、いち社会人として正しく付き合っていければと思います。

[Ansible/AAP] AnsibleFest 2025 のキーノートで気になったポイント（Autoamtion Dashboard、Ansible Lightspeed Intelligent Assistant、HashiCorp 連携）

はじめに

2025/05/19-22 (現地時間)、ボストンで Red Hat Summit 2025 と AnsibleFest 2025 が開催されていました。一昨年からこの 2つのイベントが合同開催になりました。

私は現地には行っていませんが、両イベント合計３つのキーノートを YouTube Live で見れました。

• Day1
  • Red Hat Summit: - YouTube
    • まとめ: - YouTube
• Day2
  • Red Hat Summit: - YouTube
    • まとめ: - YouTube
  • AnsibleFest: - YouTube　← 本記事で取り上げるキーノート
    • まとめ: - YouTube

このうち、AnsibleFest のキーノートの気になったパートの個人的なまとめと所感を記載します。

自動画の文字起こしや翻訳を参考にしていますが、私のまとめは誤訳や誤解があるかもしれません。正確な情報は動画などの公式情報を直接参照してください。

なお、イベント開催数日後に、（YouTubeのものではない）翻訳を付けたものが Red Hat TV にアップされました。

Detail - AnsibleFest 2025: Automators, unite! Driving transformative change in the AI era

Autoamtion Dashboard

動画は 40:18 頃から。

概要

AAP に、自動化がどう効果があるかを測定できる Automation Dashboard という機能が追加される予定だそうです。

以下が Automation Dashboard の画面。成功、失敗のジョブ数や、自動化の処理時間、自動化機器台数などが表示されています。様々な条件でフィルターもできます。

Automation Dashboard 画面上部（キーノート動画 40:55 頃からの引用）

下にスクロールするとカスタマイズがフォームが登場します。

• ベース情報
  • Average cost of an employee minute ($)
  • Cost per minute of AAP ($)
• ジョブテンプレートごと
  • Time token manually execute 手動の場合にかかる時間

これらの情報をもとにして、自動化が手動に比べるとどのくらい効果があるかが金額ベースで算出されます。

この機能による情報が、自動化を戦略的に行っていくための意識決定に必要な情報になっていくとのことです。

Automation Dashboard 画面下部（キーノート動画 41:20 頃からの引用）

エクスポート機能

PDF や Excel ファイル、Google スプレッドシートエクスポートする機能もあるので、AAP に直接アクセスしない立場の人に提出するというユースケースも想定されるのだと思います。

提供予定状況

Automation Dashboard は、まず Early Adaptor Program （詳細は分かっていません）で利用でるようになるそうです。

既存の機能「Automation Calculator」との関係は？

Automation Dashboard の画面に若干の既視感がありました。現状の機能でいう Automation Calculator の上位版といった感じでしょうか。

以下は私の環境の AAP 2.5 2025/4/9 パッチリリースにおけるAutomation Calculator の画面です。各項目は Automation Dashboard のものと似ていますね。ただ、エクスポートできるボタンは見当たりません。このあたりが差分でしょうか。

自宅環境の Automation Calculator 画面（値は適当）

Ansible Lightspeed Intelligent Assistant

動画は 1:03:58 頃から。

概要

これまで、Ansible Lightspeed といえば、VS Code の拡張経由で利用する 生成AI による開発支援機能でしたが、これはまた別物です。

Ansible Lightspeed Intelligent Assistant は、AAP の画面に統合されたチャット機能のようなものです。

以下の画面で、右の方にチャットのエリアがあります。 AAP についての初歩的な質問「What is a job template and how does that relate to an Ansible Playbook?」をして、回答を得ている途中の画面です。

基本的な操作説明（キーノート動画 1:05:03 頃からの引用）

他にも「How do I create an EE?」と聞くと、詳細な手順についての回答が得られる様子がありました。

説明だけでなく設定も可能

「Build me a job template to deploy my application mendoza to my ChapelHill inventory」というプロンプトでは、実際に 画面の操作（ジョブテンプレートの作成）まで してくれている様子が紹介されていました。

ええ・・！？これは 1:06:15 頃からの動画を見たほうが早いです。最初は手入力の早送りかと勘違いしました。

自動で入力、設定されていく様子（キーノート動画 1:06:44 頃からの引用）

トラブルシューティングの支援

他にもトラブルシューティングの支援のデモもありました。

概要は以下の通りです。

• 直近24時間でもっとも失敗したジョブテンプレートは？と聞くと、TOP3がs評された
• トラブルシューティングを依頼すると、問題がある RHEL サーバーがリストアップされた
• 仮想マシンの情報を取得して、と依頼すると それ用のジョブテンプレートが自動的に作成されて実行された
• 検出された問題の修正を依頼すると、やはり それ用のジョブテンプレートが自動的に作成されて実行された

うまくハマれば強力そうですね。

利用方法

既に Technical Preview として利用できるようになっているそうです。

紹介されていた構成は完全にオンプレで、インターネットへの接続性がなくても操作可能な状態。デプロイは難易度が高めのように感じました。OpenShift でデプロイし、Red Hat AI（詳細はまだ追えてません）をバックエンドに利用するそうです。あとで公開された公式ブログでも、下の方に要件として「Red Hat OpenShift Container Platform」「Red Hat AI platform」とあります。

将来的には、Ansible Lightspeed Intelligent Assistant が MCP を経由して様々なものと連携するようになる予定だそうです。この辺りはやはり動きは激しそうな気がします。

安全に利用するためのポリシー適用

デモでは、本番環境をいきなり AI に操作してもらっていたことを差し「pretty cool」という冗談で笑いを誘いました。

AI で生成したかどうかに関わらず安全に実行したいものです。ガードレール的な機能として、ポリシーを強制的に適用する機能が追加されるそうです。

ジョブテンプレート設定画面のポリシー適用欄（キーノート動画 1:09:21 頃からの引用）

ここでいうポリシーとは、2024 年の AnsibleFest のキーノートでも発表があった「Policy as Code」や、ansible-policy と同じ文脈だと思います。

今年のキーノートでは、AWS に インスタンスをデプロイするジョブテンプレートに対して「デプロイしようとしているものの性能が、指定の範囲内か」といったポリシーを適用するデモが流されていました。

偶然なのですが、少し前に AAP のドキュメントにポリシー適用に関するページを見つけたところでした。現状ではフィーチャーフラグを立てる（おそらく API でのみ立てられる）と使えるようになる模様です。OPA まわりで色々準備は必要そうですが、おもしろい機能だなと思いました。

[2025/0714 追記]

後日 2025/07/02 のパッチリリースで、policy enforcement が GA になったようです。

All UI elements related to policy enforcement are visible to all users. See the policy enforcement documentation for more information. (AAP-47006)

なお、どんなポリシーが書けるのか？については、サンプルらしきリポジトリを見つけました。たくさんあってありがたいです。

GitHub - ansible/example-opa-policy-for-aap: Example OPA policy for Ansible Automation Platform

[2025/07/10 追記] リポジトリが ansible 配下に引っ越ししてました。

GitHub - ansible/example-opa-policy-for-aap: Example OPA policy for Ansible Automation Platform

参考:

• The evolution of Red Hat Ansible Lightspeed

HashiCorp 製品と AAP 連携

動画は 9:51 頃から。

今回は、IBM による HashiCorp 社買収が完了してから、初めての AnsibleFest です。

各社のプロダクトのコラボレーションが強調されました。Ansible と Terraform は競合じゃない、など。

現状でも、Ansible 側から Terraform を実行したり、Terrafrom のステートファイルからインベントリを生成したりできる cloud.terraformコレクションがあります。逆に、Terraform 側にも ansible/ansible や、ansible/aap プロバイダーがあり、一定の連携はできます。

さらに連携を強めていくといった趣旨のようです。HashiCorp 製品に詳しくないのでざっくりですが、以下のような話があがっていました。

• Terraform Enterprise に AAP のワークフローを呼び出す Post Provisioning Hook が追加される予定
• Ansible と HashiCorp Vault の連携予定

参考:

• Red Hat, HashiCorp reveal Ansible, Terraform and Vault plans | TechTarget
• Red Hat Ansible and HashiCorp Terraform Will Be Coming Together - The New Stack
• ピースは揃った──IBM×Red Hat×HashiCorpが描く新戦略、拡大するポートフォリオ (1/3)|EnterpriseZine（エンタープライズジン）

番外編（通常セッションの資料をたまたま発見）

キーノートではないのですが、「Creating sustainable automation content, the Ansible way」というセッションで使用されたらしき資料のリンクが、Ansible Forum にありました。

forum.ansible.com

個人の環境差分をなくしたり、チームでの開発をうまく進めるためのあれこれが、ツールや手法視点で紹介されています。

Ansible 関連のツールをひとまとめにした、ADT（Ansible development tools）についても触れられています。

おわりに

AnsibleFest 2025 のキーノートのうち

• 自動化の効果を定量的に示す「Automation Dashboard」
• AI が AAP の操作を支援してくれる「Ansible Lightspeed Intelligent Assistant」
• HashiCorp 製品との連携

についてまとめました。

キーノート以外にも気になるセッションがたくさんあるのですが、何かしらの方法で今後情報が得られると嬉しく思います。

参考（再掲含む）

• Unlocking what’s next: Everything we announced at Red Hat Summit 2025
• Automate everything, adapt to anything: Red Hat's vision for the next era of IT operations
• The evolution of Red Hat Ansible Lightspeed

[2025/06/30 追記]

• 4 takeaways from Red Hat Summit and AnsibleFest 2025
• Ansible Automation Platform and HashiCorp Terraform integration for infrastructure lifecycle management
• Better together: The Red Hat Ansible Automation Platform provider for HashiCorp Terraform has been updated

自動車における自動運転のレベルと倫理的な難しさ

はじめに

ITインフラにおける自動化のヒントになるかなと思い、先日「自動運転レベル4 どうしたら社会に受け入れられるか」という本を読みました。

book.gakugei-pub.co.jp

以前、IT インフラ以外の分野だと「人と機械の共生のデザイン」という本で航空機のオートパイロットについて触れることができました。特に自動化レベルの考え方が参考になりました（参考）。

今回の「自動運転レベル4 どうしたら社会に受け入れられるか」という本も同じようにレベルの考え方が気になって手に取ってみました。

自動運転のレベル分け

ひとくちに「自動運転」といっても色々あるだろうなぁとなんとなくは思っていましたが、ちゃんとレベル分けして考えられているそうです。

一番知りたかったレベル分けについてはかなり最初の P10 図1-1 として紹介されていました。

元ネタは国土交通省「自動運転車の定義及び政府目標」別紙１。

レベル	概要	説明
レベル1	運転支援	システムが前後・左右のいずれかの車両制御を実施
レベル2	高度な運転支援	システムが前後及び左右の車両制御を実施
レベル3	特定条件下における自動運転	特定条件下においてシステムが運転を実施（当該条件を外れる等、作業継続が困難な場合は、システムの介入要求等に対してドライバーが適切に対応することが必要）
レベル4	特定条件下における完全自動運転	特定条件下においてシステムが運転を実施（作業継続が困難な場合もシステムが対応）
レベル5	完全自動運転	常にシステムが運転を実施

レベル2と3の間に大きな差があります。レベル2までは「運転支援」とも呼ぶべき領域。一方、レベル3では、一定条件下で「アイズオフ（eyes off）＝目を離してもいい」という状態です。目を離していいとなると、いよいよ自動運転感が高まりますね。

なお、「アイズオフ」とセットで覚えておきたいのが「ハンズオフ（hands off）= 手を離してもいい」です。

本書のタイトルに含まれる「レベル4」は更に高度で、「万が一の備え」もドライバーではなくシステムが担当します（P70「表 3-1 自動運転のレベルと内容」での表現）。ここだけフォーカスすると、ITインフラの自動化に照らし合わせて考えやすいポイントだなと思いました。

倫理的な難しさ

本書を読んでいて非常に難しいと思ったのは、倫理との照らし合わせです。

P42からの話で、

• 車を運転中ブレーキ故障になって、そのままだと前方の5人を轢いてしまう
• 横の歩道に入ればそこにいる1人を轢いてしまう

という状況で歩道に入った場合、手動運転なら緊急回避にあたるとのことです。

しかし、自動運転によって、助かる人が多い方へ進路を設定するようにプログラミングした場合、緊急回避の要件のうち「補充性（やむを得ずにした行為）」を満たさないとのことです。なぜかというと、あえて「ジレンマ状況の対処法をプログラミングしない」という他の方法もあるのにプログラミングをしたから、と。

で、同じ状況でも人の運転では緊急回避が成立して無罪になっても、自動運転のプログラマーは有罪になる可能性がある。いやぁ、難しいです・・・。

この辺の事情は国によって違うらしく、ドイツでの上記のようなジレンマ状況におけるプログラミングの考え方が P50 で紹介されています。

※ 法律の解釈が含まれ、表現が難しいので正確には本書をご参照

おわりに

今後も自動車の分野に限らず、他分野の自動化の考え方にも触れていければと思います。