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

「小さく壊す」は許し「一発アウト」は 防ぐ Agentic AI 時代のプラットフォー ムが備えるべきガードレールを再考 する 株式会社 CAM / 株式会社サイバーエージェント 岡麦 PEK 2025

プロフィール 岡麦 - 2022年度新卒入社 株式会社サイバーエージェント /株 式会社CAMへ出向 - SRE Unit manager / Platform Engineering Unit member - 社内プラットフォームの運用・保守をメインとして活動 #Kubernetes #Istio #Datadog @mugiokax @mugioka

会社紹介 株式会社 CAM 2025年で設立 25周年 サイバーエージェントで最初にできた子会社 エンタメコンテンツ、ビジネスバラエティメディア、ライフ スタイルメディアを主軸に 20サービス以上を開発・運用 エンジニアは 約30名

本セッションで話すこと 「高品質なサービスを、より早くユーザーに提供」 し、開発者によるビジネスインパクトを最大化する ために、独自のマルチテナント型プラットフォーム を構築しています 20以上のサービスがプラットフォーム上で稼働 2019年から運用開始

本セッションで話すこと

本セッションで話すこと AI や AI Agent の普及により Platform Engineering の実践における優先度が変わってきた その中の一つが「ガードレール」 「不確実性の高い大量の作業」を安全に受け入れるために 「ゴールデンパスの提供」だけでなく、 よりシステム的なアプローチができるプラットフォームが求めら れるようになってきた と思っている

本セッションで話すこと 弊社の Platform Engineering 実践の道のりを振り返りつつ AI Agent 元年の今、プラットフォームが備えるべきガードレールを実際の現場視点で再考します

1.Platform Engineering 実践の振り返り 2.AI Agent の登場による変化 3.何を恐れているのか、防ぎたいのか 4.なぜ「小さく壊す」は許すのか 5.「これまで」と「これから」のガードレール 6.ガードレールの実践事例の紹介 7.終わりに

Platform Engineering 実践の 振り返り

これまでの振り返り（2022 - 今） 大きなコンセプト 「不必要な認知負荷を軽減し、開発生産性を高める」 その結果としてビジネスがより加速している状態を目指す

具体的に何をやってきたか 1. 2. 3. 4. 5. 6. ローカル開発環境の改善 開発生産性の観測 不必要な複雑性の排除 内部開発者ポータルの提供 セルフサービス化の推進 ドキュメント拡充

具体的に何をやってきたか 1. 2. 3. 4. 5. 6. ローカル開発環境の改善 開発生産性の観測 不必要な複雑性の排除 内部開発者ポータルの提供 セルフサービス化の推進 ドキュメント拡充

具体的に何をやってきたか 1. 2. 3. 4. 5. 6. ローカル開発環境の改善 開発生産性の観測 不必要な複雑性の排除 内部開発者ポータルの提供 セルフサービス化の推進 ドキュメント拡充 開発者の生の声をベースによりよ い Platform Engineering をしたい 定期的な勉強会 アンケート ツール利用率の可視化 デプロイ頻度の計測

具体的に何をやってきたか 1. 2. 3. 4. 5. 6. ローカル開発環境の改善 開発生産性の観測 不必要な複雑性の排除 内部開発者ポータルの提供 セルフサービス化の推進 ドキュメント拡充 技術的負債の返済 多すぎるマイクロサービスの統合 モジュラーモノリスの採用 K8s クラスタの統合 etc… 分散しすぎて管理できない、わかりにくいものを適切な 粒度で集約

具体的に何をやってきたか 1. 2. 3. 4. 5. 6. ローカル開発環境の改善 開発生産性の観測 不必要な複雑性の排除 内部開発者ポータルの提供 セルフサービス化の推進 ドキュメント拡充

具体的に何をやってきたか 1. 2. 3. 4. 5. 6. ローカル開発環境の改善 開発生産性の観測 不必要な複雑性の排除 内部開発者ポータルの提供 セルフサービス化の推進 ドキュメント拡充

具体的に何をやってきたか 1. 2. 3. 4. 5. 6. ローカル開発環境の改善 開発生産性の観測 不必要な複雑性の排除 内部開発者ポータルの提供 セルフサービス化の推進 ドキュメント拡充 誰でもすぐプラットフォームを利用した開発ができる 属人化させない オンボーディングドキュメントの継続的な見直し How To ドキュメントの拡充

後回しにされがちだったもの 「ゼロトラスト的思考なアーキテクチャの構築」 もちろん全くやっていないわけではない 例えば、 CI / CD の分離による明確な権限の棲み分けなど ... ただ、これはセキュリティの強化がメインではない 「GitOps の推進によるセルフサービス化の加速」という 攻めのアプローチを行いたい ことが背 景であり、セキュリティの強化は副次的な効果の一つ

なぜ後回しにされがちだったのか？ 「限られたエンジニアリソースで開発生産性を改善」 し、ビジネスをより加速させるため 「守りのアプローチ」より「攻めのアプローチ」に重点が置かれてきた

振り返りをまとめると セルフサービス化などトレンドに沿った 「攻めのアプローチ」をしてきた 一方で、特に大企業のようなエンジニアリソースがない我々は、様々な内情からゼロトラスト 的思考なシステムの構築など 「守りのアプローチ」は後回しにされがちだった

AI Agent の登場による変化

AI Agent に「これやって」をお願いする時代 「攻めのアプローチ」で作り上げた便利なプラットフォーム 大変だったけど、開発者に「開発しやすくなった」と言ってもらえるところまでやっときた けど今は？

AI Agent に「これやって」をお願いする時代 コードの記述？ もちろん AI Agent にお任せ

AI Agent に「これやって」をお願いする時代 コードレビュー？ もちろん AI Agent にお任せ

AI Agent に「これやって」をお願いする時代 サーバー増強？ もちろん AI Agent にお任せ

AI Agent に「これやって」をお願いする時代 サーバー増強の振り返り？ もちろん AI Agent にお任せ

AI Agent に「これやって」をお願いする時代 開発フロー？ NotebookLM に仕様を貯める NotebookLM に GitHub Issue の 雛形書いてもらう GitHub Issue 作ってラベルを付 与したら実装開始！！

AI Agent すげえええ 今までやったどんな施策より圧倒的にぶち上 がる開発生産性 一方で不安要素もある

不確実性 セッションが長くなると意味わからないことをしだす 全く同じプロンプトでも出力は毎回異なる ハルシネーション 暴走

AI Agent の登場による変化 開発生産性はめちゃくちゃ上がった 一方で「守りのアプローチ」が充分でないプラットフォームは AI の「不確実性」によりサービス の継続を脅かすような「一発アウト」に見舞われてしまうのではないか プラットフォームを育ててきた、育てていく人たちが抱える「漠然とした不安」

何を恐れているのか、防ぎた いのか

漠然とした不安は何なのか？ AI Agent という革新的だが不確実性の高いツールの登場が「プラットフォーム」や「サービス」 にどのような侵害を与えることを恐れているのか 1. 2. コード品質 a. 保守性 b. バグ c. 脆弱性 d. スケーラビリティ 内部システムの不適切な⾏動 a. 環境の破壊 b. サプライチェーン攻撃

何が一発アウトに繋がりやすいのか？ 1. 2. コード品質 a. 保守性 b. バグ c. 脆弱性 d. スケーラビリティ 内部システムの不適切な⾏動 a. 環境の破壊 b. サプライチェーン攻撃 提供しているサービスやプラットフォー ムによって異なる 我々は、特に 4 つを恐れている

何が一発アウトに繋がりやすいのか？ 1. 2. コード品質 a. 保守性 b. バグ c. 脆弱性 d. スケーラビリティ 内部システムの不適切な行動 a. 環境の破壊 b. サプライチェーン攻撃 プラットフォームで提供している共通機 能に大きなバグが混入 複数のテナントが影響を受ける 信頼を失う ...

何が一発アウトに繋がりやすいのか？ 1. 2. コード品質 a. 保守性 b. バグ c. 脆弱性 d. スケーラビリティ 内部システムの不適切な行動 a. 環境の破壊 b. サプライチェーン攻撃 対策 動作確認文化（ビジ職と共同） テスト リポジトリ分割による管理の厳格化

何が一発アウトに繋がりやすいのか？ 1. 2. コード品質 a. 保守性 b. バグ c. 脆弱性 d. スケーラビリティ 内部システムの不適切な行動 a. 環境の破壊 b. サプライチェーン攻撃 OWASP Top 10 に入るような攻撃されや すい脆弱性を仕込んでしまう 情報漏洩 ...

何が一発アウトに繋がりやすいのか？ 1. 2. コード品質 a. 保守性 b. バグ c. 脆弱性 d. スケーラビリティ 内部システムの不適切な行動 a. 環境の破壊 b. サプライチェーン攻撃 対策 静的解析 WAF 脆弱性診断

何が一発アウトに繋がりやすいのか？ 1. 2. コード品質 a. 保守性 b. バグ c. 脆弱性 d. スケーラビリティ 内部システムの不適切な行動 a. 環境の破壊 b. サプライチェーン攻撃 重要なリソースやデータが削除された結 果 復旧困難な状態になってしまい、サービ スが長期間提供できなくなってしまう ...

何が一発アウトに繋がりやすいのか？ 1. 2. コード品質 a. 保守性 b. バグ c. 脆弱性 d. スケーラビリティ 内部システムの不適切な行動 a. 環境の破壊 b. サプライチェーン攻撃 対策 最小権限の徹底 リストアできる状態でのバックアップの 保持 バックアップの分離

何が一発アウトに繋がりやすいのか？ 1. 2. コード品質 a. 保守性 b. バグ c. 脆弱性 d. スケーラビリティ 内部システムの不適切な行動 a. 環境の破壊 b. サプライチェーン攻撃 マルウェアに感染した結果 情報漏洩 ... 金銭要求 ...

何が一発アウトに繋がりやすいのか？ 1. 2. コード品質 a. 保守性 b. バグ c. 脆弱性 d. スケーラビリティ 内部システムの不適切な行動 a. 環境の破壊 b. サプライチェーン攻撃 対策 最小権限の徹底 SIEM GHA の管理 ちょっと弱め？？

全く何もしていないわけではない リストアップした上で対策できているかを確認していくと、何も対策していないわけではない でも、不安を感じるのは何故なのか？

シフトレフトとサプライチェーン 「守りのアプローチ」の優先度を高くしてこな かった AI Agent がもたらした「不確実性の高い生産 性の向上」により後手に周りがちだった課題 が浮き彫りになってきた シフトレフトとサプライチェーンの保護に対す る不安が大きくなってきた https://cloud.google.com/solutions/shifting-left-on-security?hl=ja

• https://cloud.google.com/solutions/shifting-left-on-security?hl=ja

なぜ「小さく壊す」は許すのか

利便性と制約のバランスを取りたい AI Agent の普及で「制約」の重要性も高まってきている 全ての事象を防ぐことはできないし、闇雲にガードレールを増やせば「利便性」を損なう 「小さく壊す」ことは許容した上で、「一発アウト」対策は取ることで両者のバランスを取りたい

たくさんデプロイすればそりゃ障害も増える “障害のほとんどはデプロイによって引き起こ される。 ” AI による爆発的な生産性の向上によってデ プロイが増えることは当たり前で、我々もそれ を望んでいる 一方で、大きな障害の発生頻度が増えたり、 開発者が疲弊することは望んでいない

「小さく壊れる」にはどうしたら良いのか Platform Engineering という取り組みを通し て、AI Agent が調査を行える環境を準備 その上で、 AI Agent に作業を移譲することで、 例え障害が増えたとしても開発者が疲弊せ ず、「小さく壊れる」ことが可能な状態を目指 す 調査ができる状態にできれば様々な部分で 応用が効く - CI のエラーを自動で修正 定期的なキャパシティプランニング

ここまでの流れをざっくりまとめ これまでの、 Platform Engineering ではセルフサービス化など 「攻めのアプローチ」が重要視 されてきた AI Agent の普及により「不確実性の高い大量の作業」が発生する中、 「漠然とした不安」を感 じるようになり「守りのアプローチ」も重要視されるようになってきた 一方で、これまで通り 「利便性と制約のバランス」は担保したい 「小さく壊す」ことは許容する ことで、 「一発アウト」は防ぐ必要最小限なガードレールを整備 し たい

「これまで」と「これから」の ガードレール

「これまで」のガードレール ゴールデンパスの提供 組織規模、開発している物、開発文化に合っ ている

「これまで」のガードレール ゴールデンパスの提供 開発者に準拠してもらうことで、ある一定 の品質が保たれる 組織規模、開発している物、開発文化に合っ ている コスト セキュリティ 信頼性 etc...

「これまで」のガードレール ゴールデンパスの提供 開発者が納得いく形での合意形成を取る 組織規模、開発している物、開発文化に合っ ている ガードレールの存在意義の明確化 利便性と制約のバランス etc...

「これから」のガードレール 本質的には変わらないが、 AI Agent の登場により「変 わったこと」や「変わっていくこと」がある 「不確実性の高い」大量の作業を高速に実行可能に エンジニアの人数だけでは測ることのできない、組織 規模

「これから」のガードレール ゴールデンパスの提供 性善説のゴールデンパスの提供だけでは不 十分かも？ 組織規模、開発している物、開発文化に合っ 不確実性の高い AI Agent が必ず準拠してく れるとは限らない ている 準拠していない状態が「一発アウト」を招くか もしれない システム的なアプローチ（仕組み）もより必要 になってくる

「これから」のガードレール ゴールデンパスの提供 利便性と制約のバランスがより難しく、より重 要に？ 組織規模、開発している物、開発文化に合っ ている 自社のサービスにおける「一発アウト」は何な のか、対策をより明確に 「一発アウト」を防ぐにはこれまでの延長線上 ではない大きな改革も必要かもしれない

ガードレールの実践事例の紹 介

開発ツールキットの提供 実装レベルのベストプラクティスを提供 1. 2. 3. 4. 5. 6. etc... アプリケーション起動 共通機能の SDK をラップ 認証・認可 データ永続化 OpenAPI 統合 オブザーバビリティ

開発ツールキットの提供 実装レベルのベストプラクティスを提供 1. 2. 3. 4. 5. 6. etc... アプリケーション起動 共通機能の SDK をラップ 認証・認可 データ永続化 OpenAPI 統合 オブザーバビリティ メリット フルスクラッチでの実装を AI Agent にさせない ので、複数のサービスの品質を保ちやすい

開発ツールキットの提供 実装レベルのベストプラクティスを提供 1. 2. 3. 4. 5. 6. etc... アプリケーション起動 共通機能の SDK をラップ 認証・認可 データ永続化 OpenAPI 統合 オブザーバビリティ デメリット AI Agent に開発ツールキットの知識を Context として詰め込む必要がある Devin MCP Server 等を用いてシームレスに Context を詰め込むことにトライしている

コアとなる共通機能の分離 コア機能をマイクロサービスとして提供 1. 2. 3. etc... 認証 決済 通知

コアとなる共通機能の分離 コア機能をマイクロサービスとして提供 1. 2. 3. 認証 決済 通知 メリット 品質を保ちやすい etc...

コアとなる共通機能の分離 コア機能をマイクロサービスとして提供 デメリット 1. 2. 3. etc... 認証 決済 通知 AI Agent にマイクロサービスの知識を Context として詰め込む必要がある Devin MCP Server 等を用いてシームレスに Context を詰め込むことにトライしている マイクロサービスあるあるは多少なりともあ る...

積み上げ式の開発がフィットした 少人数でたくさんのサービスを開発し、運用する ため色々なレイヤで共通化を行ってきた サービス開発・運用において 「やることを減らし た」ことが結果として AI Agent の行動を抑制 して おりガードレールとなっている 一方で、独自のレイヤを増やしたためフルスク ラッチ開発と比べると Context の詰め込みには苦 労している Devin の DeepWiki を MCP Server から利用するこ とで課題をクリアできないか検証している

終わりに

まとめ 伝えたかったこと 1. 2. 3. 4. 不安を漠然としたもののまま放置しない 小さく壊れることは許容しよう これまで以上に利便性と制約のバランスに注意する 組み込まれたガードレールの重要性

不安を漠然としたもののまま放置しない AI Agent の登場で Platform Engineering における「守りのアプローチ」に「漠然とした不安」を 抱えている人は 自社のサービスにおける「一発アウト」の言語化と、その対策が充分かどうかを考察してみ よう 意外と対策されていて、不安が解消される人もいるかも？

小さく壊れることは許容しよう デプロイが増えれば障害も起きやすくなる 障害を起こさないことに執着しない 「小さく壊れる」にはどうすれば良いのか、「開発者を疲弊させない」ためにはどうすれば良 いのかを考えよう

これまで以上に利便性と制約のバランスに注意する AI Agent の普及により「守りのアプローチ」が重要視されてきている ガードレールという How に執着するとやれることは無限に出てきてしまう 自分たちが防ぎたいことを明確にした上で、それをするために必要最小限なガードレールと は何なのかを考察しよう 闇雲なガードレールの整備による利便性の低下には注意しよう

組み込まれたガードレールの重要性 AI Agent の登場により「不確実性の高い大量の作業」が実施可能になり、ゴールデンパスに 準拠しない可能性が高くなってきた プラットフォームにガードレールを組み込むというシステム的なアプローチ（仕組み）をするこ とで準拠していないことを早期に検知し、強制的に準拠させるようにしよう

ご清聴ありがとうございました