はじめに

気がつけば前回の投稿からかなり間が空いてしまいました... その間、別の勉強に力を入れていたり、転職をしたりと色々ありました。そのあたりはまた別の記事で書こうと思います。

表題の通り、2026年9月26日に中野セントラルパークカンファレンスで開催されたPlatform Engineering Kaigi 2026（以下、PEK2026）に参加してきました。今回のテーマは「AI Native Platform Engineering」で、開発者がAIエージェントにコーディングを任せるようになっていく中で、プラットフォームエンジニアリングがどう変わっていくべきかを扱うカンファレンスです。

忘れないうちに、聴講したセッションやブースで学んだこと・感じたことをまとめておきます。

参加理由

参加した理由は大きく3つです。

少人数のSREでプラットフォームを支えるヒントを得たい：今の会社では、少ない人数のSREで各サービスの信頼性やガバナンスを確立していかなければなりません。そのためにはプラットフォームエンジニアリングが必要だと考えていて、そのヒントを得たいと思いました。
AI時代の開発者環境の変化に追いつきたい：今回のテーマにもなっている通り、AIによって開発者の環境は大きく変わっています。会社もその変化に適応していく必要があり、そのために自分が学ばないといけないと思いました。
知り合いと交流したい：これまでカンファレンスのコアスタッフをやってきた関係で知り合った方が多く参加していて、その方々と交流したいと思いました。

Keynote: Architecting Agentic Development Platforms

Architecting Agentic Development Platforms

いま、多くのプラットフォームチームが「AI に対応せよ」と言われています。その典型的な打ち手が、既存のプラットフォームの上にエージェントを載せることです。結果は予想通りで、ハルシネーション、…

www.cnia.io

Architecting Agentic Development Platforms のプレビュー画像

会場入りが遅れてしまったので、キーノートはリモートで聴講しました。

登壇者のKaspar von Grünberg氏は、PlatformConの共同創設者であり、『Thinking in Platforms』の著者でもあるプラットフォームエンジニアリング界隈の第一人者です。恥ずかしながら存じ上げなかったので、Kaspar von Grünberg氏登壇！PEK2026キーノートの注目ポイントで予習させていただきました。『Thinking in Platforms』は読まないと...

Agentic Software Developmentの4つのレベル

一番印象に残ったのは、AIエージェントを使ったソフトウェア開発を、エージェントの実行ループに対して人間がどの位置にいるかで分類した「THE FOUR LEVELS OF AGENTIC SOFTWARE DEVELOPMENT」の話です。

レベル0 Human-driven：人間はExecutor（自分で実行する）
レベル1 In the loop：人間はExecutor（エージェントと一緒に実行する）
レベル2 On the loop：人間はValidator（エージェントの出力を検証する）
レベル3 Orchestrating：人間はOrchestrator（複数のエージェントを指揮する）
レベル4 Outside the loop：人間はConstraint-setter（制約を設定するだけ）

転職して、今はAIと本気で向き合う環境にいます。前職よりは進んでいるものの、自分の働き方を振り返ると、エージェントに書かせたものを人間が一つひとつ確認している「レベル2」だなあと感じました。

さらに面白かったのが、レベルごとに「エンジニアリングのスループットが2倍以上になった」と回答した組織の割合を示したデータです（出典：State of AI in Platform Engineering 2026, Volume 2 / Weave Intelligence, n=350）。

レベル1：30%
レベル2：36%（+6）
レベル3：60%（+24）
レベル4：79%

レベル1→2ではほとんど変わらないのに、レベル3に到達するだけでこんなにも違うのかと数値で表れていて、会社としても自分としても、もっともっとAIの活用を推進していかねばと気が引き締まる思いでした。

レベル3に到達するための鍵「Validate Change Loop」

では、どうすればレベル3に到達できるのか。その答えとして紹介されていたのが「The validate change loop is the key to reach Level 3」というスライドです。正直その場では文脈をしっかり理解できていなかったので、後からスライドを見返して自分なりに整理してみました。

このループは次のような流れになっています。

エージェントが変更の候補（PR、パッチ、設定変更など）を作る
ゲートがそれを評価する（LLMによるレビューのような確率的なものと、テストやポリシーチェックのような決定的なものの両方）
不合格なら「なぜ却下されたのか」がフィードバックされる
そのフィードバックがエージェントのコンテキストに追加される
ゲートを通過するまで1〜4をN回繰り返し、通過したら昇格（Promoted）する

レベル2の状態では、エージェントの出力を検証しているのは人間です。そのため、エージェントをいくら増やしても人間のレビューがボトルネックになり、スループットはほとんど伸びません。これがレベル1→2で+6ポイントしか変わらない理由なのだと思います。

レベル3に進むには、この「検証」を人間の手から切り離し、ゲートとフィードバックの仕組みに任せる必要があります。そうすることで、エージェントは人間を待たずに自律的に修正を繰り返せるようになり、人間は個々の出力の検証から解放されて、複数のエージェントの指揮に専念できるようになります。そして、このゲートやフィードバックの仕組みを整えることこそが、AI時代のプラットフォームチームの役割なのだと理解しました。

後述するIaCのガードレールのセッションやDevSecOps Verify基盤のセッションも、まさにこのループを実装している事例だったので、キーノートを聞いた後だとより納得感を持って聴くことができました。

ちなみに、キーノート後のQ&Aで使われていたシステムは、以前一緒にスタッフをやったazuma_alvinさんが作成されたものでした。参加者の体験をきちんと考えて作られていて、本当に良かったです。

開発者とSREが同じ仕組みを使う、ローカルに閉じない自律AIエージェントのつくり方

ウェルスナビの安部さんのセッションです。ウェルスナビさんは今回スポンサーとしてブースも出展されていました。少ないSREでもSREエージェントを使って開発者に素早く一次回答を出している、という点に興味を持ち、具体的な構成を知りたくて聴講しました。

SREエージェント「Clione」は、開発者がSlackから呼び出して調査や設定変更を自律的に進められるようにしたもので、EKS上でClaude Agent SDKを使って実装されています。 Notion・GitHub・Datadog・AWSなどと連携しつつ、参照範囲の限定やマスキング、実行前のHookによる検査、通信先の制限、変更はPull Request経由にして最終判断は人が行うなど、多層的なガードレールが敷かれていました。その結果、一次回答までの時間が約60分から5分に短縮されたそうです。

セッション後、ブースでも色々と質問させていただきました。

開発者ポータルは何で実装しているのか？
- DatadogのIDP機能を使っているそうです。Datadogにオブザーバビリティを集約してお金をかけているからこそできることだとおっしゃっていました。以前はBacklogを使っていたものの使い勝手が悪かったらしく、ちょっと気持ちはわかります。
なぜEKSなのか？スケールが必要などk8s基盤でないとできない理由があるのか？
- 会社がk8s基盤でデプロイしやすかったからで、ECSでも全然できるとのこと。コンテナ1台程度で十分動くそうです。
みんなが使えるようにするとコストはどうなのか？
- 派遣社員一人分くらいにはなってしまうとのこと。ただ、インターネットで調べれば済むようなことも聞いてくる人がいるので...とのことでした。

今回一番刺さったセッションです。少ないSREで開発者を支えるには、やっぱりこういうエージェントが必要だよなあと改めて思いました。 AIを使ってトラブルシュートを楽にする事例はよく聞きますが、アーキテクチャや工夫している点をここまでしっかり聞いたことはなかったので、すごくためになりました。会社で使っているものと照らし合わせて早速考えてみようと思います。あと、ウェルスナビさんはこんなに進んでいるのかと関心を持ったので、今後もチェックしていきたいです。

人にやさしく、AIにやさしく、書き手を選ばないIaCのガードレール再考

MIXIの杉本（kohbis）さんのセッションです。SRE Kaigiで同じチームだったこともあり、またいつも勉強になる発表をされているので聴講しました。

「AIエージェントを特別扱いしない」という方針のもと、書き手が人間でもAIでも同じガードレールが機能するようにした事例です。レビューでやっていたことを「下限判定」「ルール徹底」「高品質化」に分解し、機械的に判定できるものはレビューでの助言ではなくポリシーテストでCIで強制する形に移行していました。具体的には、TerraformやHelm Chartに対してconftestでポリシーテストを実行しています。なるほど、conftestは取り入れようと思いました。

特に気になったのが、AGENTS.mdを自動で改善していく仕組みです。どうやっているんだろうと思い、セッション後にお話を聞いたところ、GitHub ActionsでラベルをもとにまだチェックされていないPRを集め、そこからSREのレビューコメントを抽出してAGENTS.mdに反映する実装をしているそうです。

また、新しいルールを導入する際に既存リソースが違反していた場合の扱いとして、例外をYAMLで管理し、既存の違反リソースだけを列挙して「追加は禁止、削除（解消）方向のみ」で運用する、という工夫も紹介されていました。まさに自分がポリシーを作ったときに問題になりそうなことを先回りして話してくださっていて、ありがたかったです。

仕組み自体は自分たちでも実装できそうなものでした。他のセッションはAIならではの発表が多い中で、AIがあってもなくても重要なことは変わらないと改めて思わせてくれるセッションでした。また、エラーメッセージに「次に何をすべきか」まで書いておくことで書き手が自律的に修正できるようにする、という話は、キーノートのValidate Change Loopそのものだなと感じました。やっぱり進んでいるところは、自己更新でより良くしていく仕組みをちゃんと作っているんだなあと思います。

その他セッション

全社員がAIを「使う」の次へ ── ノンエンジニア1,500人が安全に業務を作り変えるゴールデンパスとガードレール

リンクアンドモチベーションの河野さんのセッションです。社内でバイブコーディングで作ったものを安全にデプロイできるようにするヒントを得たくて聴講しました。得たい成果から逆算してアウトカムマップを作り、効果を評価できるようにしてからAIを導入する話や、スキルに合わせてClaude Cowork・Dify・Claude Codeと配るツールを変えている話が参考になりました。ツールが実際に使われているかのチェックは、今後SREとして監視していきたいと思います。一方で、非開発者に約2ヶ月間伴走して定着させたという話には驚きました。自分がそこまでコミットできるかというと...

CI/CDではもう遅い - 人とAIが迂回しないDevSecOps Verify基盤の再設計 -

KINTOテクノロジーズの島村さんのセッションです。 Coding Agent向けのHookなどを使って、git pushやPR作成の前、つまりShipする前にチェックを走らせるというアイデアは面白いと思いました。一方で、課題としても挙げられていた通り、導入は難しいだろうなとも思いました。ユーザーに影響がある形でローカル環境に手を入れることになるので...

LC4RIによる実行可能ドキュメントとナレッジ化の実践記（LLM時代のドキュメントプラットフォームの現在地）

スリーシェイクの加藤さんのセッションです。セッション自体はリモートで軽く見ていたくらいですが、手順書とコマンドを一体化させて、手順書上のコマンドをそのまま実行し、その結果も記録として残せる「LC4RI（Literate Computing for Research Infrastructure）」という考え方を知れただけでも良かったです。

ブース

気になるところをちょこちょこ回っていました。印象に残っているのは次の2つです。

Tenable

知らなかったので、ふらっと寄ってみました。ちょうど会社の脆弱性管理を改善したく、この手のサービスを調べていたところでした。 Wizに近いサービスですが、クラウドに特化せず社内の資産を全部見ようとする点や、コスト面が違うのが良さそうでした。早速上司に言ってみようかな。

AppThrust

ちょうど社内で、バイブコーディングで作ったものを簡単にデプロイしたいという機運が高まっていて、まさに今欲しいものだと思いました。 AIで「作る」は速くなったのに、デプロイや環境作成の依頼は同じだけ増え、SREの人数は変わらない...という公式サイトの問題提起は、少人数SREの自分にはかなり刺さります。中身はKubernetesのエコシステムで構成されているので、このタイミングでk8sもちゃんと勉強しようかなと思いました。

感想

自分がSRE・プラットフォームを考える立場になったこともあり、非常に参考になるセッションが多かったです。 AIの使い方や改善の仕方、開発者・非開発者がAIを使って開発しやすくなるためのヒントをたくさんいただきました。少ないSREで社内を支えていくためには、やっぱりこういうプラットフォームが必要になるのだなと改めて感じています。

一方で、プラットフォームエンジニアリングの事例はk8s前提の会社が多いように思え、いつも置いていかれる気持ちを感じます。 k8sはリッチすぎるなあと思っていましたが、AIでどんどんものが作れる世界になっていくと、k8sのような仕組みが利点を生み、必要になっていくのかもしれません。 AI基盤のプラットフォームもほとんどがk8sを使っていますし、やっぱり会社への導入も自分自身の勉強も必要になってくるのかなあと考えています。

また、カンファレンスは知り合いに会える貴重な機会でもあります。ただ、もっと輪を広げないといけないという気持ちもあるので、次は懇親会にも参加しようと思います。私がコアスタッフとして関わっているSRE Kaigi 2027も、これよりもっと盛り上がるものにしないとなと気合いが入りました。

その他拾ったスライド

公式サイトでもスライドを見られますが、記載のないものもあったので、見つけたものをまとめておきます。

おわりに

運営の皆さん、登壇者の皆さん、スポンサーの皆さん、素敵なカンファレンスをありがとうございました！今回得たヒントを会社に持ち帰って、少しずつでもレベル3に近づけるよう取り組んでいきたいと思います。

最後まで読んでいただきありがとうございました。

Tag: Platform Engineering

Platform Engineering (1)

Year 2026

PEK2026 に参加しました