「Platform Engineering Kaigi 2025」に参加してきました

• 2025/9/18
• https://www.cnia.io/pek2025/

実例紹介！プラットフォームエンジニアリング導入の成功ポイント

風見恵介さん/菅慎司さん(ウルシステムズ株式会社)

• 開発者と経営層の視点の違い
  • 現場の体験向上
  • ROIの向上
• トップダウン
  • 計画重視
  • 大企業のようなケース
  • アンケートで状況を把握して進めるのがいい
    • 日本CTO協会のDXクライテリア
  • ビジネス価値を試算して効果が高いところから
• ボトムダウン
  • 実績重視
  • 小さく始めて数字で語る

「小さく壊す」は許し「一発アウト」は防ぐ Agentic AI 時代のプラットフォームが備えるべきガードレールを再考する

岡 麦さん(株式会社CAM)

• 一発アウトのリスク
  • 脆弱性
  • バグ
    • プラットフォームが提供する共通機能に問題が入ると全サービスに影響
  • 環境の破壊
  • サプライチェーン攻撃
• 利便性と制約
  • すべてを防ぐことはできない
  • ガードレールを増やしすぎても制約が増えすぎる
  • 小さく壊れるようにしたい
• ガードレール
  • 開発者に準拠してもらうことによる提供
    • 開発者との合意
  • 性善説だけでは不十分
    • AIエージェントは従ってくれない
    • よりシステム的なアプローチがいる
  • 今までの延長ではないことも必要
    • 開発文化の変革

GitLab x Kubernetes x AI ～ チームにスケーラブルな AI 駆動型開発基盤を提供しよう！

今井 陽祐さん/野木 悦孝さん(クリエーションライン株式会社)

• GitLab Workspace
  • k8sを使った仮想サンドボックス開発環境
  • ブラウザ版VSCodeが立ち上がる
  • セットアップ済みの環境を配布できる
  • ローカルにコードを持たなくてよい
• GitLab Duo Agent Platform
  • AI駆動開発を推進するプラットフォーム
  • ソフトウェア開発ライフサイクルの全体をスコープとしている
    • AIコーディングとか
• Slackbotを使ったセルフ構築
  • Slackのメッセージを起点にGitLab Workspaceを構築する
    • Slackbotからプルリク作ってマージするとCI動いてできあがる

使いやすいプラットフォームの作り方 ー LINEヤフーのKubernetes基盤に学ぶ理論と実践

五反田 正太郎さん(LINEヤフー株式会社)
https://speakerdeck.com/lycorptech_jp/pek2025_gotanda

• 使いやすいプラットフォーム
  • ユーザーのシナリオに沿ったもの
  • シナリオを分析して設計改善していくといい
• プラットフォームの構築
  • あらゆる場面に最適化はできない
  • 重要なシナリオを重点的に
  • 普遍的な領域は早めに

AI時代に始める大企業での内製開発──知識を土台に、小さなチームが挑む

中島 清貴さん(株式会社マルイユナイト)

• 丸井グループのFintechとRetailtechの会社
• OMEMIE
  • オンライン出店サービス
  • 内製での新規開発
  • AIを活用して少人数で
• AIを活用した開発
  • 思ったより速度が上がらない
    • 生成してからマージするまでの手直し
  • 人によって使い方さまざま
  • AIに読ませる情報の質が足りない
    • 雑多に貯めるだけでは不十分
• コンテキストの整頓
  • コーディング規約や設計方針など文書化
  • 一般的に知られているアーキテクチャパターン
  • 要件も文書化
    • 人力でマークダウン化
  • ドメインモデリングで構造化
    • 図はMermaidでAIも理解しやすいように
• コンテキストの使い分け
  • ダメなケース
    • 誤情報が入ってることで間違える
    • 長すぎて重点をつかめない
    • 関係ない情報で質が落ちる
  • 開発工程ごとに必要なコンテキストを定義する
  • AIとの伴奏と委託を使い分け
    • 要件定義は前者で開発は後者でとか

開発者の声を起点としたPlatform Engineeringの実践～開発プロセス変革に向けた取り組み～

住木 憲一さん(ニッセイ情報テクノロジー株式会社)

• 2020年CCoEの発足
  • グループ内外向けにクラウド活用するケースが出てきた
  • ニッセイITが提供するサービスでもクラウドを使うようになってきた
  • 各事業部が個別にクラウド対応している状況だった
• 組織体制
  • 親会社向けと外部向けの事業がある
  • 事業部によって言語やクラウド環境が異なっている
  • アジリティの高さを求められるようにもなってきている
• CCoEの取り組み
  • プラットフォームエンジニアリング
    • モダンなクラウド環境をサポート
  • イネイブリング
    • 提供だけでなく自走してもらえるように
• 組織の壁
  • プロダクト思考で利用者目線でやっていく必要がある
    • これまでは提供者の視点で用意するだけだった
  • インタビューやアンケートによるユーザ理解から
  • ワークショップやってCJMを作成したり
  • フィードバックサイクルを回す
• 文化の壁
  • プラットフォームが負担を吸収する
    • 前例踏襲文化
    • 仕組みを変えることによるコスト
• 技術の壁
  • プラットフォームが高セキュリティな環境を提供
    • 金融領域におけるセキュリティやガバナンス
    • 提供された環境を使えば安心となるように

アーキテクチャの境界を越えて

伊藤 泰さん(株式会社MonotaRO)

• レガシーでモノリスなシステムの課題
  • 開発速度低下
    • アイコン変えるだけで9ヶ月
  • チームのサイロ化
    • 同じ機能のAPIがいろんなところに
  • アーキテクチャの老朽化
    • コンテナなど使われていない
• アーキテクチャ変革
  • モノリスの分割/オンプレ脱却
  • 統一された開発基盤や標準プラットフォームの構築へ
• 共通プラットフォーム
  • コンテナ基盤
  • o11y基盤
  • DB基盤
  • 負荷試験基盤
• プラットフォームへのアクセス
  • 共通プラットフォームへアクセスするCLIを提供
  • 新規のプロジェクト作成もCLIから
    • 言語や環境を選択して生成される
• インナーソース化
  • 利用者からのコントリビューターが多数
  • 機能が足りなかったりテンプレートが足りない時にコントリビュート
  • プラットフォームチームの対応待ちがボトルネックにならないように
  • マルチプラットフォームでマルチソースなので要求が多様