はじめに

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シナリオは初めて自動化に挑戦するネットワークエンジニアが作成を担当されたそうです。