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」の世界観が実現します。

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やプラットフォームエンジニアの参考になれば幸いです。

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設計の考え方と実践的なアプローチをご紹介します。

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

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

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

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

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

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

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によって、システム開発に携わってこなかった社員も、業務ツールや自動化を作れるようになりました。一方で、機密情報の粗雑な扱い、過剰な権限、意図しない外部公開、作成者依存の運用など、従来はエンジニアリング組織が向き合ってきた信頼性とセキュリティの問題が、非エンジニアの業務現場にも広がっています。すべてを個別に審査していては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で安全に業務を作り変えられる状態」を目指す、現在進行形の実践と課題を共有します。

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）の使い分け - 時間があれば

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

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による恒久対応を一つの運用ループとして設計し、各クラスタの制約に合わせて最適化していく過程を、実際の失敗談やトレードオフを交えて共有します。

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を設計する必要があります。