Most platform teams have now been told to support AI. The common response is to add agents on top of the existing platform, and the result is predictable: hallucination, runaway cost, security incidents, and the conclusion that agentic development is not for this organization. That conclusion is usually wrong because in reality the observed failure can be isolated to the platform, not the model. In this session Kaspar von Grünberg makes the case that this is a platform race rather than a model race, then walks through the architecture that wins it: the three layers of an Agentic Development Platform, being tooling, paths, and agent infrastructure, and where a team with a working IDP should start.

AIの支援により、Platform Team自身のサービス開発は以前より速くなりました。企画、設計、ドキュメント作成、実装、テスト、レビューなど、多くの作業をAIが手伝ってくれます。同時に、問い合わせBot、推奨プラットフォームの提示、設定例やテンプレート生成など、AIをPlatform Serviceそのものに組み込む動きも進んでいます。 しかし、私たちはその両方で、本当にAI Slopを防げているでしょうか。 AIで素早く作られた設計やコード、整ったドキュメントが、必ずしも価値あるPlatform Serviceになるとは限りません。また、AIを組み込んだPlatform Serviceも、不完全なドキュメントをもとにもっともらしい回答を返したり、利用者に誤った自己解決を促したり、Platform Teamの確認負荷や例外対応を増やしたりする可能性があります。速く作れることと、価値が出ることは同じではありません。 本セッションでは、Platform Team自身のAI活用と、AIを組み込んだPlatform Serviceの両方に共通するAI Slop対策として、Value Stream Managementの考え方を扱います。見るべきものは、AIの出力が賢そうに見えるかではなく、Value Stream上の摩擦が本当に減ったかです。 Platform Team自身のAI活用においても、Platformユーザーに提供するAI機能においても、AIがどのボトルネックをどのように解消したのか、同時に新たな手戻りや確認負荷を生んでいないかを検証する必要があります。 AI NativeなPlatform Engineeringとは、AIで速く作ることでも、AI機能を華々しく追加することでもありません。AIが実装や生成を助けてくれる時代だからこそ、Platform Teamは価値仮説の構築と検証に時間を使い、開発者が正しい選択をより早く、安全にできるPlatform Serviceを設計する必要があります。

Turingでは、完全自動運転AIの開発を支えるため、計1000GPU以上に及ぶ計算基盤をわずか3人で運用しています。その内訳は、オンプレミスの自社GPU基盤「Gaggle Cluster」、国内GPUクラウドの「GMO GPUクラウド」、そしてGCP / AWS上のGPUクラスタと多岐にわたります。 クラウド環境では、Terraform / Terragruntによるプロビジョニング、Packerによるイメージ作成、startup script、Ansible playbookを組み合わせて再現性を担保しています。しかし、GMO GPUクラウドやオンプレミス環境に同じ抽象化をそのまま適用することはできません。また、AWSとGCPの間でも、利用可能なサービス、GPUの調達状況、リージョン特性、ノード交換の発生条件は大きく異なります。 本セッションでは、「全部を同じ仕組みに揃える」という理想を追い求めるのではなく、「環境ごとの違いを受け入れながら、同じ思想で統合運用する」ためのInternal Platform設計を紹介します。クラウドではインスタンスの再作成を前提とした復元性を重視する一方、オンプレミスではクラウドで培ったAnsible roleや監視パターンを移植し、クラスタ間の差分を現実的なアプローチで減らしていく泥臭い工夫を語ります。 さらに、少人数での運用を成立させるための省力化の仕組みとして、Datadog / New RelicによるObservability、Slackから起動できるRead-onlyなSRE調査AI Agent（主にDevin）、Rundeck / PagerDuty AutomationによるRunbook Automationの整備状況についても触れます。異常検知からAI Agentによる一次調査、承認付きの復旧操作、IaCによる恒久対応を一つの運用ループとして設計し、各クラスタの制約に合わせて最適化していく過程を、実際の失敗談やトレードオフを交えて共有します。

アイデアを人に伝えるとき、私たちはつい分厚い仕様書を書きます。しかし本当に意図が伝わり、議論が前に進むのは「動くもの」を見せられたときです。メルカリの社内基盤Arcaは、この「動くプロトタイプでアイデアを研ぎ澄ます」体験を、エンジニアだけでなく誰もが手にできる状態を目指して作られました。 ブラウザからサンドボックス環境を立ち上げると、AIエージェントがそのまま中身を作り、専用ドメインが割り当てられ、URLひとつで社内に即共有できます。ターミナルやコマンドの知識は要りません。Google DocsやNotionを開くのと同じ感覚で、PdMもデザイナーもエンジニアも、同じ環境で手を動かしながらプロトタイプを育てられます。新機能のアイデア検証にも、既存機能の改善案を試すことにも使えます。導入から約3ヶ月で、100人以上の社員がArca上でプロトタイピングを行い、1000人以上がArcaにアクセスしています。 これを支えているのが、AIエージェントが自律的に動くために設計されたセキュアなサンドボックスです。エージェントに思い切って動ける自由を与えつつ、隔離とガードレールによって安心して全社に配れる。この土台があるからこそ、誰もが気軽に環境を立ち上げ、使い捨てられます。そしてこの手軽さは、一度きりの検証にとどまらず、ちょっとした社内ツールを自分の手で作って回す使い方にも広がっています。 仕様書のレビューではなく、動くものを触りながら議論する。この転換が、アイデアから検証までの距離を劇的に縮めます。本セッションでは、こうした基盤をなぜ・どう作り、社内でどう使われているのかを、設計判断と実例を交えて共有します。AI時代に、プロトタイピングを一部の専門家から全員のものへ広げる入口をどう設計するか、そのヒントを持ち帰っていただけるはずです。

Google Cloud Spanner はコンピュート容量（Processing Units）を無停止で増減可能なため、負荷に合わせた容量調整が運用の役に立ちます。オートスケーラーには公式のマネージド機能や cloudspannerecosystem/autoscaler という選択肢もありますが、我々は Kubernetes 上でアプリケーションを運用しているため、すべてをカスタムリソースで宣言的に扱える OSS「spanner-autoscaler」を開発・運用しています。CRD なら既存の GitOps・RBAC のフローにそのまま乗り、開発チームへのセルフサービス化が容易な点も理由として挙げられます。CPU 使用率ベースの自動スケールに加え、cron によるスケジュール、緊急時に人間が安全に介入する手動スケーリングといった機能も提供しています。 本セッションでは、この実装・運用経験をもとに、Kubernetes コントローラーと CRD 設計の実践パターンを解説します。 - 役割ごとに CRD を分割し（SpannerAutoscaler / SpannerAutoscaleSchedule / SpannerManualScaling）、リソース間参照で協調させるパターン - 「自動化を止めずに人間が介入する」仕組み: kubectl 一発で容量を一時固定し、期限切れで自動制御へ戻す宣言的な緊急対応 - 独立した CRD なので、ArgoCD のような独自 RBAC を作らずに、標準の RBAC と監査ログで「誰が実行できるか」を制御・追跡可能 - AI によるオペレーションの可能についてもお話しする予定 - API バージョニング（v1alpha1→v1beta1）と後方互換性 - 外部システム依存コントローラーのテスト: envtest の限界と、自作 Spanner エミュレータによる e2e テスト - AI エージェントの動作検証基盤としても活用 - 入力検証の選択肢: Admission Webhook と ValidatingAdmissionPolicy（CEL）の使い分け - 時間があれば

生成AIによって、システム開発に携わってこなかった社員も、業務ツールや自動化を作れるようになりました。一方で、機密情報の粗雑な扱い、過剰な権限、意図しない外部公開、作成者依存の運用など、従来はエンジニアリング組織が向き合ってきた信頼性とセキュリティの問題が、非エンジニアの業務現場にも広がっています。すべてを個別に審査していては1,500人規模のAI活用を支えられず、一律に禁止すれば、かえってルールを度外視した運用のリスクも高まります。 リンクアンドモチベーションでは、経営トップのコミットメントのもと、全社員のAI活用スキルを5段階（Lv.1試行／Lv.2日常活用／Lv.3事例創出／Lv.4ツール開発による業務改善／Lv.5事業変革）で定義。コンサル・クラウド事業ではLv.2の全員到達（日常業務でのAI活用100%）を実現し、多くの社員がLv.3に到達しています。いま直面しているのは「使う人」を増やす課題ではなく、非エンジニアを「AIで安全に業務を作り変える人」へ移行させることです。 Gemini・Claudeなどの汎用AIからDify・n8nなどの開発基盤まで、活用段階に応じた環境を提供し、50〜100人規模の組織単位にTechnology Administrator（TA）を配置して、現場課題の発見から事例の横展開まで伴走。さらに情報システム・セキュリティ部門と連携し、非エンジニアが陥りやすいセキュリティ上の穴を、個人の注意力だけに委ねず、設定・権限・標準手順・相談導線によって防ぐ仕組みを整えています。 本セッションでは、5段階のAI活用レベル、複数ツールの提供、TAによるイネーブルメント、情シス・セキュリティ部門と作るガードレールを、一つの社内プラットフォームとして紹介します。「全社員がAIを使う」の次にある「非エンジニアがAIで安全に業務を作り変えられる状態」を目指す、現在進行形の実践と課題を共有します。

HolmesGPT（ホームズGPT）はオープンソースSREエージェントです。CNCFサンドボックスプロジェクトであり、現在も日々成長中です。オープンソースのSREエージェントは他にもいろいろありますが、ホームズGPTの特徴はCNCFエコシステムとの親和性の高さにあります。 K8sをプラットフォームとして運用する場合に必要なArgoCD、プロメテウス、Otel等と非常に親和性が高く、予めツールが用意されていて別途スキル等を設定しなくてもCNCF系のツールを自然に調査に使ってくれます。 さらに、CNCFのみならず様々なベンターとの連携も簡単にできるところが嬉しいポイントです。大抵はMCP経由での連携になりますが、AWS、Google、Azureなど、メジャーなクラウドのMCPとはネイティブに連携でき、マルチアカウント対応も簡単にできます。 また、使用するLLMのプロバイダーも自由に選ぶことができ、OpenAI、Anthropicのみならず、メジャーなLLMプロバイダーはほとんどカバーしています（私はコストメリット重視でGeminiを採用しました）。 でも、エージェントの呼び出しに手間がかかっては障害調査の初動が遅くなりますよね。 そこでエージェントのAPIを呼び出す小さいSlack連携Botを作成し、SlackでメンションするだけでホームズGPTを呼び出せる仕組みを導入しました。 弊社では障害アラートは基本的に全てSlackに流れてくるため、Slackのアラートが最初の障害検知になることがほとんどです。そのため、Slackで気づいたその瞬間にアラートメッセージのスレッドにホームズGPTをメンションすることで即座に障害調査が始められます。 このホームズGPTを導入して最も嬉しかったポイントは、プラットフォームやアプリの構成に詳しくない開発者でも簡単に障害調査ができるポイントでした。 ドメイン知識が浅い開発者は何から始めればいいかわからないことが多いですが、初動調査をエージェントに任せられたことで、プラットフォームエンジニアへの問い合わせが激減しました。 おかげでプラットフォームの社内評判も上がり、ホームズGPT目当てにプラットフォーム利用を検討する部署も出始めました。

AIエージェントがPull Requestの量と並行度を押し上げつつある今、各PRをend-to-endで検証できることは、あれば便利な追加機能ではなく、開発ループに組み込まれるべき要素になりつつあります。PR単位のプレビュー環境はそのための自然な解決策ですが、スケーラブルな形で、プロダクト開発者へ複雑性を漏らさずに構築することは容易ではありません。 私たちは、このプラットフォームをKubernetes Controllerとして開発・運用しています。複数のプロダクトチーム・リポジトリをまたいで動作する設計です。アプリケーションの複製、ルーティング、ライフサイクル管理といった横断的な責務は基盤側で吸収し、プロダクト開発チームは小さく見慣れたセットアップだけで済み、運用時も必要な情報に最適な形で触れられるようにしています。 プラットフォームエンジニアリングの仕事の核は「複雑さをどこに置くか」の意思決定にあります。このセッションでは、私たちがPRプレビュープラットフォームを開発する中で下してきた技術判断を辿り、プロダクト開発チームの認知負荷を吸収するプラットフォームを開発する上での学びを共有します。具体的には、次のような内容を扱います: - なぜマニフェスト生成ではなくControllerを書く選択にしたのか - どの責務をプラットフォーム側で吸収し、何をアプリケーション側に残したか - プロダクト開発チームがネットワークトポロジーの変更を意識せず複数のプロダクト間でのPRプレビューを連携させる仕組み - 開発者の認知負荷を吸収するDevExをどう実現するか うまくいった意思決定だけでなく、後から境界を引き直すことになった意思決定も取り上げることで、より学びの多い教訓を共有します。

AI Nativeなプラットフォームでは、テレメトリーを読み書きするのは人間だけではありません。LLMアプリケーションやエージェントが観測対象として増える一方で、障害調査や運用判断を担うAIもテレメトリーの消費者になります。観測する側とされる側の両方にAIが入るこの状況では、各チームが思い思いに計装したテレメトリーは人間にもAIにも読めません。プラットフォームチームがOpenTelemetryを共通言語としたオブザーバビリティ共通基盤を整備し、開発者がそれに乗るだけで一貫したテレメトリーを得られる状態を作ることが、組織のAI活用力を高める前提条件になります。 本セッションでは、その基盤の全体像を3つの構成要素に分けて示します。1つ目は、SDKディストリビューションと自動計装の配布です。開発者が数行の設定でトレース、メトリクス、ログを送り始められる状態を、どう作り維持するかを扱います。2つ目は、プラットフォームが管理するOpenTelemetry Collector層です。エージェントとゲートウェイの構成パターン、テナント分離、テレメトリー量とコストの制御を説明します。3つ目は、セマンティック規約のガバナンスです。標準の規約に社内独自の属性をどう重ね、チーム間で一貫した意味づけをどう保つかを扱います。それぞれの構成要素について、開発者に何をセルフサービスとして提供し、何をプラットフォーム側で統制するのかという線引きを議論します。 そのうえで、この基盤をAIワークロードへ広げます。生成AIセマンティック規約を使えば、LLMアプリケーションやエージェントも従来のマイクロサービスと同じレールに乗せられます。また、スキーマが統制された機械可読なテレメトリーは、AIによる障害調査や自律的な運用の前提条件でもあります。オブザーバビリティ共通基盤が、AIを観測する基盤とAIが観測に使う基盤を兼ねることを示します。 OpenTelemetryコミュニティでの継続的な活動と、業務上での顧客のオブザーバビリティ基盤支援の経験に基づき、自社の基盤設計にそのまま使える構成要素と判断材料を解説します。OpenTelemetryの実装経験は前提としません。

事業の急成長に伴い「You Build It, You Run It」の負荷が開発者に集中し、認知負荷が高まっていました。私たちのチームはこの課題に向き合い、各プロダクトチームが、負荷を最小化しながら自分たちで運用を回せる状態を目指しています。その手段が、内部開発者プラットフォームという仕組みで解決する「作る」と、チームに伴走して人で解決する「入り込む」です。 「作る」では、内部開発者プラットフォームをプロダクトとして提供しています。常に向き合っているのは、ユーザーから要望として挙げられたものをそのまま作っていないか／本当に必要なものを見極める対話ができているか／作ったものが使われ続けるか、という問いです。実際に動くものを見せながら「これは本当に求めていたものか」をチームと一緒に確認し、要求の優先度を整理した結果、開発者が本当に求めていたものを最速で届けることができました。 「入り込む」ではプロダクトチームに伴走し、信頼性の課題解決を推進しました。大切にしたのは、プロダクトチームを巻き込み、チーム自身が解決できるようリードすること。この課題に時間を割くべきか／チームができるようになっているか／いつまで入り込むのか、を問い続けました。「このエラーを減らす」ではなく「顧客にとって何を守るべきか」から始めたことで、チームが信頼性を自分ゴトとして捉え、定義と計測を自ら進めるようになりました。 一見異なる二つのアプローチですが、どちらも「なぜやるのか」から始めたことで機能しました。AIが実装の多くを引き受けるほど、この問いが価値を左右します。Whyなき「作る」は使われない仕組みを生み、Whyなき「入り込む」はなんでも屋を生みます。さらに、入り込んで初めて何を仕組みにすべきかが見え、仕組みにできて初めて一つのチームを超えて広がる。片方だけでは足りないのです。 本セッションでは、両方を実践した立場から、その判断と、結果としてチームに何が起きたかを、具体的な事例とともにお話しします。 ◼︎対象者 ・プロダクトチームの自律を支えるエンジニア ・「作っても使われない／入っても抜けられない」に悩む方 ◼︎得られるもの ・「作る」と「入り込む」がなぜ両方必要で、どうつながるか ・「なぜやるのか」の有無で結果がどう変わるか

プラットフォームを「プロダクト」と呼び、ロードマップを作って機能をリリースしても、それだけでは開発者に使われ、成果が生まれる状態にはなりません。LegalOn Technologiesの全社アプリケーションプラットフォーム「Akupara」では、テックリードとして運営を担ってきた私がPdMを明示的に担うと宣言し、事業・開発戦略と接続した方針と半期のAchievementを策定しました。 本セッションでは、要望ではなく開発者の困りごとを起点に、Discovery、Delivery、Enablement、Measurementを一つのループとして回してきた実践を紹介します。Discoveryでは、AIエージェントとPM向けスキルを活用してユーザーインタビューを設計・実施し、複数チームの結果を横断分析してバックログへ反映しました。その結果、当初の独自オーケストレーター構想から、共通の実行環境や権限管理を提供して各チームの運用自動化を支える方向へ、作るものと作らないものを見直しました。 さらにPdM自身が一エンジニアとしてプロダクトチームに参加し、AIエージェントを使った開発フローとプラットフォーム機能を検証しました。そこで得たのは、AIエージェント主体の開発では、利用者が便利なツールを意識して呼び出すだけの設計では定着しにくく、標準的な開発フローの中で自然に発見・実行される体験が必要だという学びです。 導入先はGitHub・Slack・NotionをAIエージェントで横断調査し、具体的なユースケースを持つチームから選定しました。オンボーディング状況を可視化しながら、インタビューやアンケートに加え、同意を得た開発セッションからMCPサーバーの発見率・実行成功率・行動可能率を捉える計測にも取り組んでいます。導入率などの先行指標を、開発ライフサイクル全体の時間短縮という遅行指標へどう接続するか、その設計と課題も共有します。 完成形の成功事例ではありません。テックリードがPdMとして、誰のどの課題を解くか、何を作らないか、どう導入し成果まで見届けるかを判断してきた過程を、試行錯誤とともに持ち帰れる形で紹介します。

コードをAIが書く。それはもう、特別なことではなくなりました。当然それは「Infrastructure as "Code"」でも同様です。 私たちのプロダクトでは、もともとTerraformやHelmを、可能な限りSREではなくドメインチームのエンジニアが書いてきました。そこにAIが加わり、今ではその多くをAIが書きます。どのプロダクトでもあるようなアプリケーションエンジニアにとって「IaCが難しい、、、」という課題は、少なくとも表面的にはなくなったと言ってよいと思っています。 一方で、SREのレビューがボトルネックになり、人もAIも設定の抜け漏れをやってしまいます。実際に自分も、AIが生成したチャートの抜け漏れを見落とした経験があります。 このような背景をもとに選択したのは、AIエージェントを特別扱いしないという方針です。それはAIのために新しい統制を足すのではなく人と同じレイヤーのメンバーとして扱い、書き手が人でもAIでもプラットフォーム側で同じガードレールが効くような状態を目指すということです。レビューでの助言に頼りきるのではなく、CIで止められるかたちにしていきました。 このアプローチのよいところは、AIの比率が上がっても仕組みを作り替えなくてよい点です。守る対象が「AIかどうか」に依存しないからです。 本セッションでは、レビューでの助言をCIでの強制へ変える具体的な仕組み、実装時とCIと実行時で多段に守る設計、そして導入の途中でうまくいかなかったこと、まだまだ道半ばのいま抱えている課題をお話します。AI時代のガードレールを「AIのために作る」だけでなく「人とAIの区別なく効かせる」という判断をした、ひとつの事例としてお役に立てればと思います。

生成AIが大量のコードと依存ライブラリを短時間で生み出すようになった今では、CI/CDパイプラインを中心とした従来のDevSecOpsでは検証のスピード、対応が間に合っていません。 AIが提案したライブラリのライセンスは適切か。既知の脆弱性は解消されているか。AI駆動開発では量と速度の前に見落とされやすいと考えています。 検査が遅い、あるいは目的が伝わらない状態だと、開発者は原因を調査せずに遅い部分の仕組みを外すことがあります。AIエージェントも、リリース資材を作成するタイミングで解析して指摘する今までの形式だと、大量の修正指摘を手戻りとして対応を実施することになります。 そこで、SAST、依存関係・脆弱性・ライセンス検査など、ルールとして判定しやすいツールを、ローカル環境のAIエージェントが使えるVerify機能として整備することにしました。 コードを保存・共有する前に問題を検出して、機械的な指摘を解消してからAIレビューへ渡すことでさらなるシフトレフトを行い、AIコードレビューのコスト、ノイズ、手戻りを減らすことを目的としています。 また、SBOMとライセンス情報も保存・可視化しており、定期的な監査運用を実施できる状態を作りました。 その結果、人とAIが同じ基準でルールの適応状況を確認し、リリースタイミングでの手戻り・AIレビューのコストの削減ができるようになりました。 本セッションでは、AI駆動開発を前提にDevSecOpsを再設計した実践と、次に向き合うべき課題を紹介します。

Platform Engineeringの普及により、Internal Developer Platform（IDP）は組織の開発能力を支える重要な基盤となりました。しかし、その価値の高さゆえに、IDP自体が新たな攻撃対象となりつつあります。 2025年以降は、GitHubをはじめとするOSSコミュニティへのサプライチェーン攻撃やAIエージェントの権限や自律性を悪用した新しいタイプの攻撃が相次ぎ、数千人規模の開発者が利用するIDPを預かるエンタープライズの現場では、「Golden Pathをどう作るか」以上に、「自社のIDPを脅威からどう守るか」というSecurity Guardrailへの関心が急速に高まっています。 本セッションでは、GitHubをはじめOSSコミュニティで実際に発生した攻撃事例を出発点に、Platform Engineeringによって生まれた新しいAttack Surfaceをどのように守るべきかという視点で、Agentic AI時代のPlatform Securityを考えます。 また、AIエージェントをPlatform Securityへどう組み込むべきかについても取り上げます。マルチAIエージェントによる脅威ハンティングやAI Red/Blue Teamによる攻撃-防御の演習などAIが大きな効果を発揮する領域がある一方で、PolicyやAccess Control、最終的なSecurity Decisionといった判断を非決定論的なAIへ委ねることにはリスクもあります。 ソリューションエンジニアとして、数多くのエンタープライズのプラットフォームのガバナンス設計やPlatform Engineeringを支援する中で見えてきた課題と、MicrosoftがAgentic AI時代の脅威をどのように捉え、AIとの協調を前提としたセキュリティをどのように考えているのかという知見も交えながら、Platform Engineerが明日から自社のIDPへ適用できるPlatform Security設計の考え方と実践的なアプローチをご紹介します。

Coding Agentの活用が当たり前になり、開発者は専門知識がなくても、開発時の認知負荷となっていたCI/CDやインフラの構築・運用まで自分たちで進められるようになりました。一方で、高速に何でも作れるようになったからこそ、自由に構築を進めると、セキュリティ設定の不備や場当たり的な運用が生まれ、組織全体の品質や信頼性が揺らぎかねません。安全な標準構成と統制の仕組みをプラットフォームとして提供しておけば、Coding Agentがどれだけ高速に変更を生み出しても、品質・信頼性を一定に保つことができます。これこそがAI時代にPlatform Engineeringを実践する価値だと考えています。 ログラスでは事業拡大に伴い、開発チームがセルフサービスでサービスを構築・運用できるよう、Platform Engineeringを推進し、EKSを基盤としたプラットフォームを整備してきました。運用開始から1年で5チーム・約20サービスまで展開し、開発者はCoding Agentとともに安全かつ高速にサービスを構築・運用し、プロダクト価値につながる開発へ集中できています。この状態を実現できた鍵は、SREと開発チームの責任境界を明確にし、役割に応じた権限を設計したことにあると考えています。 そこで本セッションでは、シングルクラスタ・マルチアカウント構成でArgo CD、Argo Workflows、HashiCorp VaultなどのOSSを組み合わせたEKSプラットフォームの全体像と、SRE・開発チームの責任境界を紹介したうえで、以下の2つの取り組みを実装レベルで解説します。 ・SREがHelmテンプレートを管理し、開発者とAIは公開されたValuesのみを変更できることで、意図しない設定変更を防ぐ仕組み ・GitHub Teamをもとに、各OSSやKubernetesの権限を設計し、リソース変更を適切に制御する仕組み Coding Agentはローカルで人間と同じ権限で実行されます。そのため、人間の権限設計がそのままAIへの統制となり、Coding Agentが意図しない操作を実行できない状態を実現しています。課題や今後の展望も紹介します。AI活用と統制の両立を目指すSREやプラットフォームエンジニアの参考になれば幸いです。

IaCやCI/CDによるプラットフォーム運用の自動化が進む一方で、根幹となるオペレーションは依然としてコピー＆ペーストやタイピングによる手作業が主流であり、手順飛ばしや、タイプミスによる作業ミスのリスクを抱えています。さらに、扱う技術要素の多様化、複雑化により、プラットフォームエンジニアの認知負荷の増大が深刻な課題となっています。AIエージェントによる自動化も可能ではありますが、現時点では予期せぬ環境破壊のリスクがあるため、人による手作業に頼らざるを得ないのが実情です。本セッションでは、この課題を解決するため、LLMと相性の良いMarkdown形式の運用手順書をそのまま実行可能にする手法「Literate Computing for Reproducible Infrastructure（LC4RI）」を組織に導入した実践事例をご紹介します。 ①スモールスタートからの組織展開 チームレベルでLC4RIをツールに落とし込み運用を開始。Markdown形式のコマンド部分のみを実行し、結果を元のドキュメントに反映させる仕組みを実装しました。LLMを活用しながらスピーディに手法の評価と追加実装を重ね、運用手順の品質を担保しつつチームレベルの検証や活用から部署レベルの組織全体へ展開しました。 ②Notion AIを活用した再現性の高い手順生成 運用証跡として、誰が・いつ・どのような結果を得たか、をNotionにアーティファクトとして記録。蓄積された過去の実績をNotion AIが学習・生成することで、ケースバイケースで再現性の高い運用手順を作成可能にしました。 ③今後の課題 手順のマスター管理や環境差分の吸収など今後の課題はありますが、生成と実績のループにより蓄積されたドキュメントは、将来的に人間とAIエージェントが安全に作業を行うためのインタフェースとなり、危険な作業を抑制するオントロジーとなります。その先にある人間は承認と例外対応に集中し、AIに安全に作業を委ねる「AI Native Platform Engineering」の世界観が実現します。

TVやスピーカーといった製品のインターネット接続、それらを便利に利用する専用アプリの存在が当たり前になった今、メーカーであるソニーでは毎年大小さまざまな規模でクラウド利用のユースケースが発生しています。 私が所属する AI&CCoE ではこうしたソニーの機器に対して横断的にバックエンドシステムを開発・運用しており、個別製品向けの専用システムではなく、ユーザー認証やデバイスの遠隔操作といった共通機能を提供するプラットフォームとしてのシステムを実現し、現在に至ります。 共通機能の提供と言うと聞こえは良いですが、例えばスマートフォンアプリと TV ではエンドユーザーの操作は全く異なるため、機能の共通化によって体験を損なわないための工夫が必要になります。また、安全を確保した上で各チームにクラウド設定の変更を委譲するガードレールの整備、専門性の異なる多様な開発者との間で共通のコスト感覚を築く FinOps など様々な施策に取り組んできました。 さらに、AI による開発者環境の激変も弊社に大きな影響を及ぼしています。より小規模なチームに対してクラウド環境を素早く提供する必要が生じるのと同時に、"お行儀の悪い" Coding Agent で気軽に試行錯誤してもビジネスに影響を及ぼさない受け皿が求められるようになりました。 そのため現在は、セルフサービスで試行錯誤が可能な独立したサンドボックス環境を提供できるようプラットフォームを進化させています。 本セッションでは、AI 登場以前から取り組んでいるプラットフォームの変遷を成功事例・失敗事例を交えながらリアルに紹介し、あわせて AI による開発者環境の変化に順応すべく現在取り組んでいるサンドボックスの実現方法と、プロトタイピングから得られた技術的知見を紹介したいと思います。

アンドパッドは、マルチプロダクト戦略での事業成長を加速させるため、2021年頃にAmazon EKSを用いたマイクロサービスアーキテクチャを採用しました。各開発チームの裁量で技術選定できる方針はプロダクト立ち上げにアジリティをもたらしましたが、数年を経て3つの課題が現れました。 ・デリバリーパイプラインのサイロ化：デプロイスクリプトがチームごとに独自実装され、運用ナレッジがチーム内に閉じた ・システム構成の把握の難しさ：宣言的でないデプロイや手作業の変更が積み重なり、システムの状態が不明瞭になった ・インフラ管理における自律性の低下：強い権限を要する作業がSREチームへの依頼として積み上がった 私たちは、少人数のSREチームから多数の開発チームへGitOpsを提供することで、これらの課題を解決しました。Kubernetesマニフェストの同期にはArgo CD、Terraformの実行にはAtlantisを用い、デリバリーパイプラインを共通化しています。IaCはモノレポで管理し、Terraform moduleとHelmテンプレートからなるビルディングブロックを改良・拡大することで開発チームの参入障壁を下げ、SREチームへの依頼作業は「Pull Requestの起票とSREチームのレビュー」というフローに移して、オーナーシップを開発チーム側に寄せていきました。 あわせて、このモノレポを開発者がAIコーディングエージェントと一緒に扱えるよう、Skillsやドキュメントの整備も進めています。AIが書いたコードもPull Requestとレビューという同じ動線に乗るため、セルフサービス化のために整えた設計がAI前提の開発にもそのまま効いています。 本セッションでは、Argo CDとAtlantisによる課題解決の事例と、技術的な詳細を解説します。少人数のSRE/Platformチームで多数の開発チームを支えたい方や、Kubernetesの利活用に課題意識を持つ方にとって、実践的なヒントを提供します。

インフラとアプリの境界線を、どこに引くのが望ましいのでしょうか。全部インフラチームが持てば安全ですが反映待ちで開発が止まり、全部アプリチームに渡せば速いですが野良運用が広がり作り直せない構成が残ります。 この問いには二つの境界線が混ざっているように思います。インフラプロビジョニングとアプリデプロイをどこで分けるかという機能の境界と、共通プラットフォームを挟んで開発チームがどこまで自分で動けるようにするかという役割の境界です。 そして二つは独立しているわけではありません。役割が動けば選ぶ道具も変わり、道具が変われば機能の境界の置き場所も変わってくるかもしれません。 クライアントワークで複数のお客様のインフラに関わってきた経験から、実際にどう引かれていたかを交えて整理してみます。題材は ECS や Cloud Run といったマネージドサービスです。

Platform Engineering の本質は、専門知識をゴールデンパスとして組織にスケールさせることです。しかし、ドキュメントやテンプレートを整備しても、それを読んで使いこなす負担は開発者に残ったままです。専門知識を AI エージェントが扱える形で整備しておけば、エージェントが開発者との対話の中で必要な知識を引き出し、設計から運用診断までを一緒に進めてくれるようになります。 本セッションでは、AWS 上で Agentic Platform Engineering を実践するためのアプローチを解説します。エージェントに与える知識・ワークフロー・行動規範の設計パターン、Amazon ECS や Serverless を使った開発のテンプレートやオペレーションをエージェント経由で開発者に届ける方法、そして AWS Control Tower や AWS Config によるガバナンス — エージェントに任せる範囲を広げるほど重要になるガードレールの整備 — まで、すぐに試せる OSS のプロジェクトも交えて紹介します。

CIU（CyberAgent group Infrastructure Unit）では、サイバーエージェントグループ向けのプライベートクラウド「Cycloud」を開発・運用しています。プライベートクラウドのVM基盤では、ハードウェアの世代交代を繰り返しながら基盤を維持していく必要があります。これまでは世代交代のたびにプライベートクラウドのシステムを作り直してきましたが、そのたびに利用者がVMやボリュームデータ、マネージドサービスの設定等を移設しなければならず、CIU・利用者の双方にとって大きな負担となっていました。さらに、新しいシステムでは提供されるサービスの構成やAPIの仕様も置き換わるため、利用者は移設のたびに大きな学習コストを強いられてきました。ハードウェアの寿命が、そのまま利用者の移行負担として現れていたのです。 そこで、Cycloudの新リージョンでは、「半永久的に提供し続けられるプライベートクラウド」を目標として掲げました。鍵になるのはAPIの抽象化です。VM基盤の本体であるOpenStackのAPIを、利用者へは直接見せずに独自のgRPC APIでラップして提供し、KubernetesのCRD（Custom Resource Definition）とカスタムコントローラーによってOpenStack へ反映するという方式をとりました。これにより、利用者から見えるインターフェースを固定したまま、裏側のOpenStackだけを新しいものに入れ替えることが可能になります。ハードウェアの世代交代はOpenStackの置き換えとして処理され、利用者はVMのインスタンスタイプを変更して再起動するだけで、透過的に新しい世代のマシンを利用できます。 本セッションでは、そのような抽象化の仕組みを実現した基盤設計を深掘りします。まず、利用者の要求をそのまま表す「Interface CRD」と、OpenStackなどのプロバイダーへの反映を担う「Provider CRD」による二層アーキテクチャ、それらを制御し、インフラの状態を利用者が要求する状態へ収束させるKubernetesカスタムコントローラーの設計について紹介します。さらに、インスタンスタイプの変更を契機として、世代の異なるクラスター間でVMやボリュームを移行する仕組みについてもお話しします。

AIエージェントの活用は、個人が手元で開発支援に使う段階から、チーム共通の仕事環境に組み込まれる段階へ進みつつあります。例えば、2026年6月にAnthropicが発表したClaude Tagでは、Slack上でAIを呼び出し、チームメンバー間の会話の文脈や許可された情報、コードベースをもとにタスクを任せることができます。 開発や運用の現場でAIエージェントを活用する際には、問題の調査や性能劣化の確認、設定変更など、SREの知識や判断が必要になる場面があります。こうした場面に各自のローカル環境だけで対応しようとすると、利用者ごとの設定やAI活用スキルによって、参照できる情報や判断の根拠、作業の進め方にばらつきが生じます。 当社では、開発者やSREがそれぞれ手元で使うAIエージェントに加え、クラウド上で自律AIエージェントを運用し、Slackから呼び出せる形で提供しています。接続する情報源やツール、権限を管理することで、利用者ごとの設定に依存せず、開発者とSREが同じ仕組みを使い、文脈を共有しながら調査や変更を進められます。AIエージェントが必要な情報を集めて根拠を整理し、Pull Requestのレビューや承認が必要な作業は人に渡すことで、既存の開発・運用フローの中で安全に利用できます。 本セッションでは、ローカルに閉じないAIエージェントの設計と運用を紹介します。安全に活用するためのガードレールや、利用結果をもとに改善する仕組みも扱います。個人のAI活用スキルに依存しすぎず、開発者とSREが共通の仕組みで協働するための学びとなれば幸いです。

弊社では、長年にわたって Platform Engineering を通じた開発生産性の向上を推進してきました。その中で、いくつものコンポーネントが生まれ、今日では 60 以上のコンポーネントが活用されています。 しかし、Platform と Platform Engineering 組織の成長に伴い、多くのコンポーネントが異なるインターフェースを提供する状況は Platform 自体がユーザの認知負荷を高めてしまうという課題を生み出しています。60 以上のコンポーネントは Terraform module や Kubernetes のカスタムリソース、独自設定ファイルなどの異なるインターフェースを提供しており、この状況でコンポーネントを “発見” し正しく利用するのは非常に困難です。 また同時に、AI エージェント等の新たな Platform のインターフェースの消費者の登場によってインターフェースのあるべき姿も変化しています。AI エージェントが素早くコードを生成できるようになったことで開発プロセスのボトルネックが移動し、高速なフィードバックループはますます重要になっています。従来最適だと考えられてきたインターフェースは AI エージェントにとって不都合な場合もあります。 本セッションでは、私たちの取り組みである Platform API を紹介し、人間と AI エージェントの双方が一貫したインターフェースで Platform を利用できる世界に向けた設計と現在地をお話しします。同様の課題を抱える組織が、自社 Platform のインターフェースを再設計する際のヒントを持ち帰っていただければ幸いです。

AIエージェントがTerraform/CloudFormationを書く時代、CI/CDのPRチェックに静的なポリシー(Policy as Code)を入れるだけでは、「ルールには違反していないが、デプロイすると危険な変更」を見逃してしまいます。個々の設定は妥当でも、既存のクラウド環境(権限・接続関係)と組み合わさった瞬間に、過剰権限や外部公開といった重大なリスクに変わるケースは、IaCコード単体の静的解析だけでは判断できません。 本セッションでは、Tenable Cloud SecurityのIaCスキャン機能を例に、CI/CDパイプラインの中で「IaCコードの内容」と「実際のクラウド環境のコンテキスト」を組み合わせて評価し、PRの段階でデプロイ後のリスクを可視化する仕組みを解説します。ガードレール(ポリシーチェック)をより"賢く"する、CI/CD × DevSecOpsの具体的な実装アプローチを、プラットフォームエンジニアの視点でご紹介します。

AI Agentが開発チームの一員として、コード、テスト、ドキュメント、インフラ設定まで担う時代、Platform Engineeringの役割は、従来のポータルやゴールデンパス作りから広がりつつあります。AI Agentには、単なるタスクではなく、ゴール、意図、設計思想、制約、完了条件、フィードバックを継続的に渡す必要があります。本セッションでは、AI Native Platformに必要な要素を Context / Guardrails / Learning Loop と整理し、Backstageと、ソフトバンクで開発しているクラウドネイティブアプリケーション基盤 CNAP を用いたAI Agent向け開発フローの取り組みを紹介します。さらに、Definition of Done、ワーキングアグリーメント、レビュー、レトロスペクティブといったAgile / Scrumの知見を、AI Agentとの協働ルールとしてPlatformにどう組み込めるかを考えます。AIで“作る速さ”が上がる時代に、それを“価値”へ変えるPlatformとAgileのあり方を議論します。