2026年9月26日土曜日

Platform Engineering Kaigi 2026

2026年9月26日（土）に中野で開催された Platform Engineering Kaigi 2026 に参加してきました。全体の感想と、聴講したセッションのまとめです。

概要

  • 今年も参加しました。昨年と同じく Early Bird チケット（2,000円）を購入。
  • 今年は「Platform City」という企画があり、自己紹介のホームページ作成から CI/CD までをやってくれるプラットフォームが用意されていました。AI で開発のハードルがだいぶ下がったこともあり、面白い試みだったと思います。
  • https://citymap.core.paas.jp/?_gl=1*1vgtjjf*_ga*MTE2MDY0NTUzNC4xNzkwMjMwNjcw*_ga_HNMDVRJB0L*czE3OTA4MTc1MDUkbzExJGcwJHQxNzkwODE3NTA1JGo2MCRsMCRoMA..
  • 会場は中野。久しぶりだったので、駅の出口を間違えました。

全体の感想

  • Wi-Fi：会場の Wi-Fi はありましたが、Room を移動すると切れてしまいます。モバイル Wi-Fi を持っていって正解でした。
  • 記録方法：発表は PC でリアルタイムに録音し、Claude で要約しました。今回は土曜日で仕事をする必要もなかったので、次回からは PC を持っていかなくてもよさそうです。
  • 楽しみ1. 屋台：たこ焼きとクレープでした。以前はお酒もありましたが、今回は Red Bull に。Red Bull の大型コンテナ（？）は初めて見ました。
  • 楽しみ2. マッサージ：「エンジニアは手をよく使うから」ということで、今回は手（手首？）をほぐしてもらいました。今までにない刺激でした。

聴講セッション

1. 基調講演：Architecting Agentic Development Platforms

登壇：Kaspar von Grünberg 氏（『Thinking in Platforms』著者）｜セッションページ

要点：モデルの競争ではなく、プラットフォームの競争

  • モデルはコモディティ化した。AI 導入後の生産性の差を生むのは、モデルを生産的に動かすプラットフォーム。今後はエージェントも「新しいユーザー」として迎える必要がある。
  • エージェント主導開発には 0〜4 の段階がある。レベル3（人間がオーケストレーター）が最大の転換点。レベル2以下が 72% を占め、「Copilot を入れたから十分」は危険。
  • エージェントは制御ループとして設計する（豊田佐吉の自働化が原点）。ハルシネーションは「最初のイテレーション」と捉え、決定論ゲート（CI など）と確率論ゲート（評価）を通ったものだけを人に渡す。
  • Agentic Development Platform は Tooling（既存の IDP）／Paths（ゴールデンパス）／Agent infrastructure（推論基盤・ハーネス・ガバナンス）の 3 レイヤー。
  • 始め方は /pr-review（読み取り専用でリスクがほぼない）→ /validate-change（ハイブリッド）の順に、2〜3人の小チームで磨く。
  • 質疑応答では「全社展開を急ぐと失敗する（あえて減速する）」「モデルアグノスティックに設計すべき」という話が印象的でした。

2. プラットフォームの複雑性はどこに住むべきか

12:15-12:45 Room A｜登壇：小野 大器 氏（enechain）｜セッションページ

要点：認知負荷は消えず、プラットフォームへ移る。それでも引き受ける価値がある

  • PR ごとに環境を複製するプレビュー基盤「prothea」（GKE 上の Kubernetes Controller）の設計事例。
  • マニフェスト生成方式ではなく、クラスター内で複製する Controller 方式を採用。ベースマニフェストは変更しない。
  • 設定は段階的なインターフェースにする。普段は紐付け情報だけを書き、導出結果は困ったときに見る窓口にする。
  • Preview ID と Istio（GAMMA）を使ったヘッダーベースのルーティングで、プロダクトをまたいだプレビューも可能。
  • 学び：必要な複雑さを引き受けられる技術を選ぶ／境界は引き直してよい／既存の概念を混ぜない／インターフェースに力を入れる。

3. AI Slopを生まないPlatform Service設計：価値仮説と効果測定ってどうやるの？

13:00-13:30 Hall｜登壇：木嶋 幸子 氏（レッドハット）｜セッションページ

要点：AI Slop は「低品質」ではなく、受け手の期待値とのずれ

  • 受け手の 42% は、AI Slop を渡してきた相手を信用しなくなる。Platform に置き換えるとアダプションが下がる。
  • AI を使っても渡す側の責任は変わらない。リレーのバトンパス（ハンドオフ）が大事。
  • 4象限（目的への貢献度 × 受け手の負荷）で緑ゾーンを目指す。まず貢献度を上げ、次に負荷を下げる。

成果物の4象限マトリクス

目的への貢献度 ＼ 受け手の負荷 負荷：低 負荷：高
貢献度：高 緑ゾーン（目標）
目的に効き、受け手も楽		 グレー
良いものでも期待値がずれると AI Slop 扱いされる
貢献度：低 グレー
楽だが目的に効かない		 グレー
効かないうえに負荷も高い
  • いきなり緑に入ることはほぼない。まず貢献度を確保して（上へ）、それから負荷を下げる（左へ）。
  • 貢献度が低い状態から上げるのは難しい。戦略の誤りは取り返しがつきにくいので、リリース前に検証する。
  • グレーに入っても即中止にはせず、まず原因を分析する。
  • 価値仮説（因果チェーン）を立て、VSM でハンドオフを観測する。正常系（効果）と異常系（副作用）をビジネスのテストケースとして測る。
  • 検討記録が GitHub で公開されています。
感想
  • 「成果物の4象限マトリクス」がとても良かった。もやもやしていたことが可視化・具体化できました。
  • Value Stream Management も良かった。今後の問題解決にぜひ適用したいです。

4. そのTerraform、マージした後も本当に安全か分かっていますか

13:45-14:15 Room A｜登壇：ハオ 氏（テナブルネットワークセキュリティジャパン）｜セッションページ

要点：静的スキャンの緑チェック ≠ 安全

  • 「その権限が実際に使われているか」はコードの中にない情報なので、静的スキャンでは判断できない。
  • 検証例：どこにもアタッチしない IAM ロールは PR 時の IaC スキャンを通過し、apply 後の継続スキャンで「Inactive IAM Role」として検出された。
  • 静的スキャン（車検）と継続スキャン（ドライブレコーダー）の両方が必要。
  • 見つけたリスクはコンソールで直さず、コードに戻して直す（Cloud to Code）ことでドリフトを防ぐ。
  • AWS 標準機能なら、IAM Access Analyzer（未使用アクセス）や RoleLastUsed で検出し、Claude でコード修正の PR を作る形でも実現できそうです。
感想
  • どちらかと言えば製品の宣伝がメインでした。
  • 少なくとも今の仕事では代わりの手段（IAM Access Analyzer＋Claude）があります。
  • セッションのタイトルに釣られた感じがしました。

5. Agentic Platform Engineering on AWS

15:15-15:45 Hall｜登壇：松岡 雄地 氏、小西 杏典 氏（AWS ジャパン）｜セッションページ

要点：AI エージェントに専門知識を持たせて、ゴールデンパスをスケールさせる

  • 課題：ゴールデンパスを作っても使い方が伝わらず、プラットフォームチームに問い合わせが集中する。
  • AWS が OSS の APEX（Agentic Platform Engineering eXperience）を公開。ECS／EKS 構築のノウハウを Skills・Steering・Rules として持ち、既存のコーディングエージェントに追加して使える。
  • デモ：ECS Architect → ECS Build で要件から ECS Managed Instances を推奨し、検証が通る Terraform を生成。ECS Operation Review では既存環境を 8 つの観点で診断（サーキットブレーカーの無効などを検出）。
  • ガードレールは、人とエージェントの両方に SCP / Permission Boundary / Config / CloudTrail で同じように適用する。
  • リポジトリ：aws-samples/sample-apex-skills
感想

仕事でぜひ活用してみたいです。次のコマンドで導入できるらしいです。

npx apex-skills

6. セルフサービスのオブザーバビリティ基盤をOpenTelemetryで作る

16:45-17:15 Hall｜登壇：山口 能迪 氏（Grafana Labs）｜セッションページ

要点：「人の判断から仕組みへ」

  • 計装漏れ（Propagator の設定漏れでトレースが切れる）や属性値のばらつき（production / prod / PRD）は、チームの怠慢ではなく仕組みの問題。
  • プラットフォームチームは 3 本柱でセルフサービスを作る。
    1. SDK ディストリビューション：デフォルト値を持たせて配布する
    2. Collector 層：Agent と Gateway の 2 層。PII・サンプリングの方針、OpAMP によるフリート管理
    3. セマンティック規約のレジストリ：OpenTelemetry Weaver で許可する値を定義する
  • どの柱も「配布して終わりにせず、CI で検査する」。
  • 生成 AI による障害調査でも、属性がそろっていることが調査時間とトークンの削減につながる。
  • 解説資料：OpenTelemetryで作るセルフサービステレメトリー基盤（Zenn Book・無料）
感想
  • 冒頭の「メトリクスなどの量が多すぎてコストを圧迫する」という話にとても共感しました。
  • 今の仕事ですぐに使う機会はないかもしれませんが、勉強として OpenTelemetry を実際に使ってみたいです。
  • 登壇者が翻訳した『入門 OpenTelemetry』も調べてみましたが、翻訳の評判はあまり良くないようです。ほかに参考になる本も探してみようと思います。

7. インフラとアプリの境界線と委譲の設計

登壇：鈴木 勝史 氏（スリーシェイク）｜セッションページ

要点：境界は「機能」と「役割」の2つ。両者は連動するので継続的に引き直す

  • 機能の境界（プロビジョニング / デプロイ）：値が変わるタイミングで管理する側を決め、値の受け渡し方（インターフェース）まで設計する。
    • 事故例：Terraform で apply したら Cloud Run のイメージが初期値に戻り、アプリが停止した。直接の原因は ignore_changes の漏れ、本当の原因は「イメージを誰が管理するか」を決めていなかったこと。
    • 受け渡し方式：手で転記 → 名前で引く → tfstate を参照（ecspresso / tfstate-lookup）→ ストアに書き出し。
  • 役割の境界（プラットフォームチーム / 開発チーム）：委譲には 5 段階あり、唯一の正解はない。ゴールデンパスは強制せず、標準から外れる逃げ道を用意する。
  • 委譲で渡すものは「書く権限」「適用する権限」「結果への責任」。AI で書くのは楽になったが、結果への責任は人が持つ。
感想
  • 前から気になっていた論点でした。
  • 話はどちらかというと、アプリ開発者へ渡していく方向の内容でした。
  • 一方、今の仕事ではインフラ側でアプリケーションのコードも書いています。

まとめ

  • 今年は「AI エージェントをプラットフォームのユーザーとしてどう迎えるか」というテーマが全体を通して目立ちました。
  • 共通していたキーワード：ゴールデンパス、認知負荷、ガードレール（決定論的な検査）、境界とインターフェースの設計。
  • すぐに試したいのは、APEX Skills の導入と、IAM Access Analyzer による未使用 IAM ロールの棚卸しです。
  • 買いたい本：実践 プラットフォームエンジニアリング　開発者体験を加速するセルフサービス基盤の設計と構築

※ 各セッションの内容は、当日の録音を文字起こし・要約したものです。聞き取りの誤りや解釈を含む場合があります。

投稿者 時刻: