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

2026/9/26
https://www.cnia.io/pek2026/

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

河野智則さん(株式会社リンクアンドモチベーション)
https://speakerdeck.com/lmi/pek2026-link-and-motivation

非エンジニアもAI活用
- 1500人
- 社内のAIツール3000個
- 誰でも作れるかつ安全に
AIツールを配るだけでは使われない
- 配って研修をやってもなかなか使われない
  - 活用できる業務がわからない
  - 指示の出し方がわからない
AIを浸透させるために
- 特定の部門から
  - 深く狭く成功体験を
- トップダウンで目標とつながるように
  - リターンとセットで部門のトップに伝える
- AX推進者のアサイン
  - AIスキルよりも広めていくスキル
- 座学から伴走へ
  - 習慣として定着させる
成果につなげるために
- 成果の指標をアウトカムマップで
  - 先行指標 - 遅行指標 - インパクト
  - 観測してモニタリング
非エンジニアによる開発
- 想定してないツールを使われてしまう
- 危険な操作をapproveしてしまう
ガードレール
- 活用レベルで配布するツールを分ける
  - 非エンジニア向けのorgを作って分けてる
- ノーコード
  - Claude Cowork
    - Claude Codeまで不要なケースが多い
    - Coworkの方が安全
  - Gemini
- ローコード
  - Dify
  - n8n
- プロコード
  - Claude Code
AIセキュリティチーム
- 開発部門
- 情シス
- 法務
ゴールデンパス
- 学ぶ機会がないまま突然作れるようになってしまっている
  - リターンよりリスクが勝ってしまう危険性
- ゴールデンパスの整備
  - 開発標準手順
  - フィットジャーニー
- 1. CPF
  2. 課題特定
- 1. PSF/SPF
  2. 価値検証
  3. セキュリティやコストのチェックなども
- 1. PMF
  2. 浸透
  3. 使われているかログでチェック
- 1. GTM
  2. 他部署展開
- 作っても使われないツールは量産させない

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

木嶋幸子さん(レッドハット)
https://speakerdeck.com/skijima404/ai-slop-o-umanai-platform-service-sekkei

AI Slop
- AIによる低品質な成果物
- 人の目によるチェックに時間がかかってむしろコスト増に
- 受け手がそう感じたら信用が落ちてしまう
成果物やサービスの渡し手と受け手
- 期待値があっているかどうかが大切
- 価値が高くて負荷が低いちょうどいい状態を目指したい
- これがずれるとAI Slopと受け取られてしまうことも
Value Streamのマネジメント
- 企画から運用まで全体を通した効率を見る
- Value Stream Mappingで現状の可視化
  - リードタイムとプロセスタイム

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

安部修平さん(ウェルスナビ株式会社)
https://www.docswell.com/s/WN_Tech-PR/ZY8QXP-2026-09-07-111839

開発者向けのAIエージェント
- slackで質問や依頼をして使う
- DatadogやAWSやGitHubなどにつながる
- 修正が必要ならプルリク作ってくれる
エージェント作成の背景
- 開発者からSREチームへの問い合わせが多く発生していた
  - 定型的な質問や調査も多くあった
- チケットを切って対応してとなるので待ち時間が発生してしまっていた
Slackボット
- メンションするだけで使える
- やりとりがスレッドに残る
- 最初はSRE内部でのナレッジ検索ボットとしてスタート
技術構成
- EKS上でエージェントを動作
  - Claude Agent SDK
  - Socket ModeでSlackと連携
- BedrockのClaude
- AgentCore Memory
- MCPでNotionやGitHubやDatadog
- AWS DevOps Agentも
やりとりの仕組み
- スレッドの内容を踏まえて作業を始める
- アラートをトリガーに動かすケースも
- Skillは独自で作ってリポジトリ管理
  - プルリク作成
  - ナレッジ検索
  - 問題調査
AWS DevOps Agent
- 本番用とそれ以外でAgent Spaceを分け必要な方をエージェントから呼ぶ
Bedrock AgentCore Memory
- エージェント向けの長期記憶
- スレッドをまたいで共有できる
- 会話の要点を記録しておく
- メモリだけを根拠としないように現在の情報もあわせて見る
Claude Agent SDK
- 権限を制御しできる操作を絞りたい
- 入出力のマスクなど制御やログの記録をしたい
- 外部エージェントを状況に応じて呼び分けたい
AIエージェントの安全性
- 参照更新対象の制限
  - slackはpublicチャンネルのみ
- 意図しない漏洩に備える
  - slack投稿前にマスキング処理
- 外部通信の制限
  - 許可した接続先のみ許可
  - shellや任意のwebアクセスはそもそもtoolとして持たせない
エージェントの回答
- 利用者が確認できるように
  - 事実と推測を分けて示す
  - 根拠となるリンクをつける
  - 確認できなかったことも書く
- 処理中の表示と中断
  - 途中の処理状況を表示
  - 意図しない場合は止められるように
動作状況のチェックと改善
- Datadog Agent Observability
  - エラーの傾向
  - 処理時間
  - コスト
- Datadog Dashboard
  - セッション数
  - skillごとの利用数
  - チームごとの利用数
- エージェントが自律的に振り返りと改善

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

杉本浩平さん(株式会社MIXI)
https://speakerdeck.com/kohbis/rethinking-iac-guardrails-for-humans-and-ai-alike

AIの登場での変化
- コードの書き手が変わった
  - IaCを書く負担を減らすための工夫をしてきた
  - 品質を守るということは変わらない
- ルールやガイドラインの想定読者が変わった
  - AIも人間同様構造化した文章が読みやすい
  - 長い文章も文句言わずに読んでくれる
- IaCを書く難しさが変わった
  - 表面的な難しさはなくなった
  - 抜けや漏れは発生する
- プラットフォームがやるべきこと
  - 品質の下限を揃えて下振れを防ぐ
プラットフォームエンジニアリングの役割
- ゴールデンパス
  - 標準の提供
- ガードレール
  - ルールから外れないように
- セルフサービス
  - 利用者が変更や改善をできる
- 認知負荷の軽減
  - ルールを覚える必要がない
- シフトダウン
  - ルールを守る責任をプラットフォーム側へ
IaCのレビュー
- これまでは機械的チェックはCIがそれ以外は人間が
  - AIに移行させていく
- レビューの観点
  - 下限を守っているか
    - ポリシーテスト
  - ガイドラインの遵守
    - AI向けドキュメント
  - 高い品質を目指す
    - 人間がやる
同じものが同じように適用されるようにしたい
- 書き手にかかわらず同じチェックを
  - 認証や権限に依存しないように
- 読めるドキュメントを揃える
  - 人間もAIも
- プラットフォームが提供する情報にエラーケースも含める
  - 失敗の原因から次のアクションを判断できるように
どのレイヤーで守るか
- Lint
  - Lintエラーやformat自動修正
- CI
  - ポリシーテスト
- レビュー
  - AIや人のチェック
例外許容のリスト
- 既存のコードでルール違反なものがあるケース
- リストで管理し例外扱いできるように
- ルールが追加された以降に作成するものはルールを守るように
- 既存のものは影響を与えないように

ソニーのクラウド共通基盤の変遷とAI時代の開発スタイルに合わせた進化

米山兼治さん(ソニー株式会社)

ハードウェア機器に付加価値を提供するソフトウェア
- 横断的なクラウドやデータやAIの共通基盤で管理
サービス継続の民主化とビジネス継続性の民主化
民主化により開発チームの自由度が上がった
- コスト観点を意識せずにUXを追求してしまうことも
  - アプリ通知のドットを出すために大量のサーバリクエストが発生するようになったり
  - コスト管理も民主化したい
- 異なるデバイスでGraphQLを共有していた
  - Device というプロパティがあっても使い手によって全然別物
  - どこかで標準化の整備をしないといけない
コーディングエージェント
- コストレポートを確認できる状態で公開
  - Bedrock
  - Budgets -> SNS -> teamsへ通知
- コストアラートも
AI開発向けのSandbox環境
- 無邪気にvibe codingできる環境
  - 小規模なチームが気軽にクラウドで実験する受け皿
  - 動くものを早く試せる
  - 学習のための動作確認
- Innovation Sandbox on AWSとAWS Service Catalogでセルフサービスコンソール
- AWSアカウント自体を使い捨てできる
  - ハンズオンで使い捨てで立てるようなやつに近い
- コスト上限に到達したらアカウント凍結

AIエージェント時代のPlatform as a Product —— テックリードがPdMとして回す発見・導入・計測

杉田寿憲さん(株式会社LegalOn Technologies)
https://speakerdeck.com/toshi0607/platform-as-a-product-in-the-ai-agent-era

複数プロダクトを支えるプラットフォーム
- エンタープライズ向けのアプリ
- 他国へ展開するアプリ
プラットフォームとして何をするかの判断
- 誰のどの課題を解くか
- 日々の作業で使われるか
- 何を計測して次につなげるか
- Discovery - Delivery - Enabling - Measurement

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

鈴木勝史さん(株式会社スリーシェイク)

インフラとアプリの境界
- 全部インフラが持つと安全重視にできるが開発が止まる
- 全部アプリが持つと速いけど野良運用が広まってしまう
境界
- 機能の境界
  - プロビジョニング
  - アプリのデプロイ
- 役割の境界
  - プラットフォームチームと開発チーム
  - 共通プラットフォーム
機能の境界
- たとえばECSのタスク定義やCloud Runの設定
  - インフラで決めたいこととアプリで決めたいことがある
- どこでインフラリソースを管理するか
  - Terraformで持つ
  - アプリが設定するところをignore_changesで除外しTerraformで管理しない
- インフラとデプロイで分けると受け渡しが発生する
  - 名前で引いたり
  - Terraformでoutputを定義してそれを読んだり
  - JSONなどでストアに書き出してそれを読んだり
  - 手動で書き写したり
役割の境界
- ゴールデンパスの提供と利用
  - 標準から外れるケースは起こる
  - 外れる時にフルスクラッチになるのは極端すぎる
- IaCをどこまで権限を渡すか
  - 書く権限だけ渡してレビューする
  - 適用まで権限を与える
  - 結果の責任はどっちが持つのか
- IaCの習熟度と標準構成からの逸脱具合から個別判断
機能と役割の連動
- 片方の境界が動くともう片方も動く
- チームやツールにも影響が出てくる

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

島村純平さん(KINTOテクノロジーズ)
https://speakerdeck.com/kintotechdev/cd-deha-mou-osoi-hito-to-ai-ga-ukai-shinai-devsecops-verify-kiban-no-saisekkei

AIエージェントの普及でのCIの変化
- プルリク数が30%増加
- 標準RunnerだとWorkflowが詰まる
  - GitHubのorgで同時に60Workerまで
- GitHub Actionsのコストがあがる
  - 呼び出しも実行時間も2倍
- CIで動かしたいものが増えて待ち時間が長くなる
アプリデプロイまでの流れ
- 従来
  - プルリクの段階でCIでチェックしたり人のレビューしたり
- AI時代
  - プルリクを上げるまでのスピードが上がり回数も増えた
  - プルリク作成でのCIの待ちが長くて外したいという要望も出てくる
    - セキュリティスキャンや静的解析はコーディング時にAIでやってるからいいのでは？
AI駆動開発でのCIの再定義
- やりたいこと
  - 速度を上げたい
    - CI待ちせずに開発端末でループを回したい
  - コストを削減したい
    - プルリクでのCIの実行回数削減
    - AIレビューでの既知ルールの分析トークン削減
  - 品質の担保
    - いままで完全に準拠しきれなかった既存ルールへの対応
- 仕組みの整理
  - 静的解析
    - ベストプラクティスへの準拠
    - 重複やメンテナンス性
    - 既知の脆弱性パターン
    - 基本定額
  - 各種スキャン
    - 脆弱性/EOL/ライセンス
    - OSSもあるし安価
  - AIコードレビュー
    - ロジックやバグの確認
    - 改善提案
    - 従量課金が多い
  - より安価なやり方でチェックし後ろへ流す
    - ローカルでやれてることを前提に後段を軽くしていく
プラットフォームでの整備
- hooksとskillsを整備し利用は任意
  - Plugin Repositoryで管理
  - フィードバックをベースに改善中
  - 開発に悪影響を与えないことを確認できるまでは任意
- MCPの接続増によるトークンコストの増加対策
  - MCPを常時ONにすると消費が増えてしまう