
どうもみなさん、こんにちは!ギフティでエンジニアをやっているj-maki(じぇまき)です。
2025年9月18日に開催されたPlatform Engineering Kaigi 2025に参加してきました。 プラットフォームエンジニアリングについては弊社でも取り組みが始まったところで、関心のある領域なのでとても勉強になりました。 またオフライン参加は今回が初めてだったのですが、現地参加ならではの熱気を感じたので、この記事ではその様子や感想を自由に書いていきます!
会場の様子・スポンサーブース
会場では屋台や指圧コーナーといった趣向を凝らしたスペースや催しがあり、会場全体が活気に満ちた雰囲気でした。


またスポンサーブースでは、各社それぞれの会社の概要やサービスを紹介するための工夫が凝らされており、とても賑わっていました。
スポンサーブースの企画の中で個人的に印象に残ったのは、 株式会社リンクアンドモチベーションさんの「モチベーションチップス」です。 モチベーションを高める"Tips"が書かれた"チップス"を配るというウィットに富んだ企画なのですが、このTipsがとても役に立つ内容でした。
#PEK2025 のブース企画をご紹介🎉
— リンクアンドモチベーション技術広報 (@LinkandM_dev) September 17, 2025
リンクアンドモチベーションのブースでは『モチベーションチップス』と題して、モチベーションを高める"Tips"が書かれた"チップス"をお配りします!
技術の壁、組織の壁、文化の壁という3つの課題に対して、すぐ使えるTipsをご用意しています。ぜひお越しください! https://t.co/GWYFsBhxAL pic.twitter.com/J0j41zTikn
自分はラダー効果について紹介されているチップが当たりました。ラダー効果はその名の通り「はしご(ladder)」のように、物事の表面的な側面からその本質や大きな目的へ視点を引き上げることで、行動の意義や価値を捉えてモチベーションを高める技法ということらしいです。 自分はそれが手段か目的かということをよく考えるのですが、逆にいうとその二択で捉えがちなので、より抽象的な意義で捉えることの重要性に気づかされました。その他の全てのモチベーションチップスの内容も公開されているので、興味がある方はぜひご覧ください。
また今回は弊社でもスポンサーブースを出展していて「今、一番乗り越えたい壁は?」というアンケートボードを設置していました。 みなさんから多種多様な「壁」を教えて頂きました。参加頂いた方ありがとうございます!
#PEK2025 お疲れ様でした!運営の皆さま、登壇者の皆さま、参加者の皆さま、楽しいイベントをありがとうございました。
— giftee_engineer (@giftee_dev) September 18, 2025
ギフティのブースでは、「今、一番乗り越えたい壁は?」というアンケートボードを設置していました。みなさんからいただいたコメントです! pic.twitter.com/nhzkNnOAB9
また唐突に宣伝を挟みますが、10/8にて今回のブースのアンサー企画(?)として「あなたが超えた境界」をテーマに「TSUDOI by giftee Tech」というイベントを開催するので、興味のある方はぜひ、参加ください。
セッションレポート
さて、ここからはセッションの感想を書いていきます。 どのセッションも面白かったのですが、今回はその中でも特に印象に残った3つを紹介します。
Engineering Tomorrow’s Platforms: Staying Relevant in the Age of AI
まず初めに紹介するのはNicki Wattさんのキーノートです。 Nicki Wattさんは、プラットフォームエンジニアリングの分野で数々のカンファレンスで登壇されている重要人物です。詳しく知りたい方は今回のPlatform Engineering Kaigiの運営のブログをご覧ください。
さて、セッションの内容について触れていきます。まず冒頭でCNCFが定めるプラットフォームエンジニアリングの成熟度モデルについて紹介されていました。 そして生成AIが台頭してきた昨今、この成熟度モデルやプラットフォームエンジニアリング自体がどのように変わっていくのかを説明に進みました。
Nickiさん曰く、「Platform as Product」「デフォルトとしての信頼性」「セルフサービスによる支援」といった、これまでのプラットフォームエンジニアリングの原理原則については今後も変わらないだろうということでした。しかしAIの活用により先ほどの成熟度についての進化はどんどん早まっていくだろうと予想されていました。全体的に今まで「リアクティブ」であったものがより「アダプティブ」に変わっていくということについて繰り返し主張されていた印象です。
「Platform as Product」 についてはユーザのニーズを把握する方法が変わってくるという話でした。 従来のプラットフォームは、ユーザのFBやアンケートなどをもとに改善を進める「リアクティブ」であったが、よりリアルタイムにユーザの行動自体を分析をする「アダプティブ」になっていくだろうということでした。例えば、ユーザがオンボーディングやパイプラインの設定などに時間がかかっている時に、FBを待つのではなくリアルタイムに状況をキャッチするというような、ユーザの行動の可観測性が高くなっていくという話でした。
「デフォルトとしての信頼性」 についても「リアクティブ」から「アダプティブ」に変わっていくということで、 デプロイが遅くなってきたりなど問題となりそうな兆候を、より早い段階で異常検出することができ、さらにはそれを自然言語をインターフェースとして用いることができるという話でした。
「セルフサービスによる支援」 についても従来の静的なフォームなどを使うのではなく、copilotのようにより対話的にかつユーザの習熟度に合わせて適切なインストラクションができるようになるという話でした。
さて、ここまでは特にプラットフォームの利用者側の話でしたが、それを作る側、つまりプラットフォームエンジニアリングをする私たちにも変化は訪れるという話もされていました。詳しい話はここでは省略しますが、一例としてkube-aiやk8sgptについて紹介されていました。
セッションの後半では、「現在生成AI関連で様々なツールが入れ替わりが発生しているが、今後何を使い続ければ良いかは誰にもわからない。重要なことをそれを投資と捉えて、プラットフォームは常に投資ができるような状態にしておくこと。」という話がありました。自分もついつい目先の機能開発に囚われてしまうことがありますが、プラットフォームのエンジニアが率先してAIを活用していきたいと思いました。また投資をするには投資先を理解することが非常に重要です。このようなカンファレンスに参加して情報を収集していきたいですね。 そして締めくくりとして「ギャップを眺めるだけではなく、橋を設計し、AIを味方につけよう」という言葉も印象的でした。プラットフォームエンジニアリングの本質を表した言葉だと思います。技術的な課題や組織的な課題をただ問題として認識するのではなく、それらを解決するための具体的な仕組みやツールを設計し、AIという新しい技術を味方につけて課題解決を加速させていく。そんな姿勢が重要だと感じました。
認知負荷理論で挑むPlatform Engineering:サイボウズにおけるKubernetesプラットフォームの拡大に向けて
さて、次はサイボウズ株式会社の池添 明宏さんと山田 高大さんの発表です。 前半の話者の山田さんは大学・大学院で認知負荷理論を援用した心理学研究を行なっていた背景があり、認知負荷とは何かを学術的に掘り下げる内容でした。「認知負荷は本当に下げるべきなのか?認知負荷を下げた後は、どうするのが良いのか?」 という問いからセッションがスタートしました。認知負荷を下げることに着目されるが、負荷を下げるのはあくまで過程で本来的には、その先の深い学習(豊かなスキーマ)を達成することが目的」ということでした。 また、認知負荷は、「課題外在的負荷」、「課題内在的負荷」、「学習関連負荷」の3つに種別することができて、それぞれに対応した打ち手を考えることが重要ということを話されていました。
個人的には正直、認知負荷そのものについて掘り下げて考えたことがこれまでなく、"認知負荷は下げれば下げるだけ良い"と思っていたので、今回の必要な認知負荷とそうでないものがあるという内容はとても衝撃的でした。先程のリンクアンドモチベーションさんのラダー効果では無いですが、認知負荷を下げるという表面的な目的に囚われすぎていて、その先の達成したい意義のようなものに目を向けられていなかったなと反省をしています。
後半パートの池添さんはプラットフォームエンジニアリングのプラクティスが、この3種類の認知負荷に対してどのような影響を与えるかを考えて、実際にサイボウズで実施している取り組みを紹介されていました。 具体的には、課題外在的負荷の削減についてはクラウドネイティブベースとした抽象化レイヤーを提供し、課題内在的負荷の軽減についてはユーザの習熟度に応じたドキュメントなどの導入支援を行い、学習関連負荷の増加についてはSelf Serviceインターフェースを提供しているとのことでした。 実際の効果としては、ユーザからプラットフォームチームへの的確なフィードバックにより改良が実施できており、プラットフォームを理解したユーザが応用的な利用方法を編み出して効率的な開発運用を実現できているとのことです。一方、課題としてはクラウドネイティブの知識が前提となっているため、慣れるまで苦労しているユーザも多いという状況でした。
前半パートで認知負荷について掘り下げられていたので、実際に取り組んでいることについてもとても説得力がありました。課題についても述べられていましたが、こちらはまさに必要な認知負荷を受けてスキーマを獲得している最中だと思うので、今後どうなっていくのかぜひ注目したいところです。
全レイヤーで実現するスケーラブルなサービス分離: 国内最大級のメディアを支えるマルチテナントPlatform設計の全貌
最後に紹介するのはサイバーエージェントの石川雲さんの発表です。 Amebaプラットフォームについてのテナントの課題と解決について発表でした。
初期のAmebaでは「みんなで一緒に面倒見よう」というアプローチで、共通化と可視化を優先していました。しかし、単一テナント設計では全てのサービスに同じ設計を当てはめることで妥協が生じ、要件に応えられない場合は基盤が乱立し、運用コストの増加や属人化が進むという問題が発生してしまったらしいです。特に、一部サービスの「全レイヤーにおける完全分離」というセキュリティ要件が満たせないという大きな課題があったそうです。 そこで対策となるIdentity、Cloud(AWS)、Kubernetes、DevToolsといったすべてのレイヤーでスケーラブルなサービス分離を実現するための4つの原則が紹介されていました。
個人的にとても印象に残ったのが、「二分法から始める分離戦略」 についてです。 これは最初から複雑な体系を作るのではなく、保護と非保護、管轄Aと管轄Bといったシンプルな二分法から分けていくことで、誰もが理解できる共通語彙で分離のルールを統一するという考え方でした。
私もプラットフォームエンジニアリングを始める上で、テナント分離の考え方はとても苦心しています。テナントの分離や統合などの最適化作業はコストの削減には繋がるかもしれませんが、売上などのすぐにリターンがあるものではないですし、かつ簡単に実施できない作業でもあり技術的負債になりやすく難易度が高いと捉えています。 しかし、今回の発表のように一度で完璧な分離や統合をしようとして複雑な抽象化をするよりは、シンプルに誰もが理解できること、そして分離の作業自体を成熟度応じて細分化できるようにプラクティスを学ぶこと・検討することが大切なのだと思い直しました。 詳細のIAM Policyの設定例やKubernetesのRBACの実装例は時間の都合上発表の中では割愛されていましたが、チェックしていきたいですね。
全体として
今回も興味深いセッションばかりで学びが多かったです。 またslidoで質問を募集して、セッションの時間に回答するという形式だったのですが、他の人の質問で内容の理解も進むインタラクティブな場になっていたので、良い設計だなと思いました。
懇親会
懇親会もセッションやブースを回った感想や、日々業務で実施しているプラクティスや直面している課題などを様々な方とお話できて、とても有意義でした!いくら時間があっても足りませんね。

最後に
今回もPlatform Engineering Kaigiを通してさまざまな知見や実践例に触れることができ、大変刺激を受けました。 プラットフォームエンジニアリングは特に組織のコンテキストやサービスのドメインに大きく影響を受けるので、書籍やネットの記事などでは学びきれない実践的な課題解決が大切だと感じているのですが、このような皆さんが集まり、リアルな話をインプットできたのは、貴重な経験でした。
また来年もオフラインで参加しようと思います!最後までお読みいただきありがとうございました!
Platform Engineering Kaigi 2025は無事に終了致しました!
— Platform Engineering Kaigi / クラウドネイティブイノベーターズ協会 (@cnia_pfem) September 18, 2025
多くの方にご参加頂きありがとうございました!#PEK2025 pic.twitter.com/aAX0JH4scc