ソニーのクラウド共通基盤の変遷と AI時代の開発スタイルに合わせた進化 / The Journey of Sony’s Common Cloud Platform and Its Evolution for AI-Native Development

Platform Engineering Kaigi 2026 にて登壇
https://www.cnia.io/pek2026/sessions/f5336f72-4cd2-4955-989a-109e380ddd5a/

Transcript

1. ソニーのクラウド共通基盤の変遷と AI時代の開発スタイルに合わせた進化 ソニー株式会社 技術センター 設計DX部門 AI & Cloud Center of Excellence 共通サービス設計課 米山兼治
2. 自己紹介 米山 兼治 • 経歴： • • • 2017年 ソニー株式会社 入社 TV・スピーカー・スマートフォンアプリ・360 Reality Audio 他、様々な製品に跨って ソリューション提供するクラウドシステムを担当 好きな物： • ペンギン
3. 今日の目的 我々のプラットフォームの変遷と知見を 成功事例・失敗事例を交えながらリアルに紹介し AI 時代に求められる進化について考える
4. アジェンダ • 組織紹介 • 事例紹介 • • • • 機器管理・制御サービス データ配信基盤 Coding Agent 実行環境 Sandbox • プラットフォームの進化について考察
5. 組織紹介 AI&CCoE テレビ、カメラ、ヘッドホンといったハードウェアや それらに付加価値を提供するソフトウェアに対し、 横断的にクラウド、データ、AI を提供する共通基盤 を支える組織 キーワードは民主化 5
6. 機器管理・制御サービス (2020-) • もともとは Amazon Alexa と Actions on Google から TV を操作する案件 • しかし、スマートデバイスの進化により他の音声サービスとの連携、 音声以外のインタフェースへの発展、 TV 以外の機器の操作といった機能拡張が予想された • 同じようなシステムを乱立せず効率よくリソースを活用したい • 一方ビジネス継続性という観点では、本来は終了するべきサービスに対し 他のサービスが依存してしまっているため継続するしかない状況は避けたい ⇒ サービス継続の民主化 6
7. 機器管理・制御サービス (2020-) SOLUTION plugin 層 ＼テレビつけて／ 共通サービス Alexa 用 plugin service device management Actions on Google 用 plugin service • plugin 層によりサービス毎の差異を吸収 • デバイス視点では呼び出し元のサービスを意識せず、 独自定義のフォーマットで機器制御のやり取りを行う • plugin 層は他部署での開発・運用を可能にすることで、 導入や終了を個別にビジネス判断できる作りを実現 OUTCOME • LINE や Facebook messenger との連携を効率よく実現 • サウンドバーも対応デバイスに加わった • TV・スピーカーのコンパニオンアプリ Bravia Connect とも連携することで更なる顧客価値を生んでいる 参考：ソニーでの事例から考えるプラットフォーム開発 7
8. 新たな課題：ビジネス価値の可視化 運用コスト • アーキテクチャとしてはサービス継続の民主化を 行ったが、これに加えビジネス判断のための材料 を可視化したい • 統一した指標でサービスのビジネス価値を比較し、 改善や終了といった運用方針の客観的な判断を やめる 可能にする施策も検証中 この領域の サービスは 終了を検討する この領域の コストを下げる改善は 運用チームが主導する 顧客価値 （機能によって基準は異なる） この領域の 顧客価値を上げる改善は 機能開発チームが主導する やめない この領域の サービスは継続 継続改善！ 参考：FinOpsの考えをベースにした継続的なコスト改善の取り組み 8
9. データ配信基盤 (2022-) • クラウド利用ケースは単純なデータ配信の要件も多い • しかし、単純な仕組みであっても要件の詳細化やデータ設計のため にサーバサイドとクライアントサイドでの打ち合わせや、新規シス テムのためのセキュリティ対応、社内プロセスなど、非効率な工数 が発生していた • また、案件ごとに API 設計を行ってしまうと API 仕様がクライアント仕様に依存するため、 ほとんど同じデータを他のクライアントに流用したいケースで 不都合が生じることが多かった • ドメイン知識のあるクライアントサイドでデータ定義を行いたい • データ配信エンドポイントを共通化し、フォーマットの秩序を保つ ことでクライアントを跨いだデータ取得を実現したい ⇒ データの民主化 9
10. データ配信基盤 (2022-) SOLUTION GraphQL for Project A GraphQL Gateway Data for Project A • 共通エンドポイントをクライアントアプリに提供する GraphQL Gateway と、プロジェクトごとに用意した GraphQL の二段構えの構成 • 個別の GraphQL schema とデータの管理は各プロジェクト のチームに委任 Project A team OUTCOME GraphQL for Project B • Data for Project B API 修正のセルフサービス化に成功し、クライアントサイ ドの UX を追求できるようになり、改善頻度が加速した Project B team AppSync, DynamoDB, S3 を AWS console から直接操作させることで データモデル管理のセルフサービス化 参考：GraphQLを活用したデータ配信プラットフォームの事例紹介 10
11. 新たな課題：俯瞰的な役割の不在 • • 一方で、クライアント開発者が自律して UX を追求できる ようになった結果、アップデートに対するコスト感覚がク ラウドチームとずれてしまうという新たな課題を発見 現在はコスト管理も民主化するためにサーバ・クライアン トで共有したコストダッシュボードを提供し、アップデー トによる影響をクライアントチーム自ら確認できる環境を 実現している • また、当初描いていたクライアントの種類を超えたデータ 配信のユースケースにも困難があった • TV に配信するデータをコンパニオンアプリである Bravia Connect にも配信するケースには成功したが、 事業領域を跨いだ製品間では微妙なデータ定義の差が摩擦 になり途端に共有が困難になった • 複数事業領域を跨いだ際に誰がどの立場で標準化を行うの かユースケース設計が不十分だったためだろう $ イメージ クラウドチーム の関心 クライアント チームの関心 アプリv2.0 配信開始 t イメージ type device { id: string model: string name: string icon: string } モデルを共有してるように見せかけて それぞれ独自のフィールドしか使わない状況 TIPS： 技術選定でも困難に直面しました ソニーにおける App Runner 導入事例と生の体験談の紹介 11
12. Coding Agent 実行環境 (2025-) • Coding Agent が台頭 • 素早く導入しないと競争力を失うが、 ソニーという巨大なブランドとビジネスを守るためには 無邪気にインシデントを起こすわけにはいかず慎重にな らざるを得ないというジレンマに直面 • 全社的に安全な AI 利用のためのポリシーが敷かれたが、 ルールを増やすとそれだけ導入の下準備が膨らむ • また、コストへの不安がある状態では利用部署が躊躇し てしまう • 全社ポリシーに追従し続け、ガバナンスが効いた環境 • マネジメント視点、エンジニア視点両面からコストへの 不安を解消し、自身の責任でコスト意識をもって利用判 断を可能にする ⇒ AI 管理の民主化 ここぞとばかりに AI に作らせた挿絵 12
13. Coding Agent 実行環境 (2025-) Organization SOLUTION Account ＼◦◦作って／ Identity Center Amazon Bedrock • Amazon Bedrock を介してベンダを AWS に一本化 • AI 利用ポリシーへの追従や AWS アカウントそのものの ガバナンスをクラウドチームが管理 • 利用部署毎にコストレポートを通知 • Budgets SNS 部署単位でコストレポート & 異常検知アラート 利用者の心理安全確保の側面もあり、 部署単位で発生しているコストにとどめて可視化している OUTCOME • 社内25部署に Claude Code を展開、全社的な取り組みと 合流し、GitHub Copilot, Claude Code, Codex 等をニー ズに合わせて選択できる仕組みとして拡大中 • コストアラートにより新規モデルの利用料の急増を食い 止めた事例も実際にあり、着実に運用知見を蓄積中 AWS Control Tower でアカウント自体の セキュリティガバナンスを確保 本日ブース展示でも Coding Agent 導入のための全社施策 について深く紹介しています ぜひ聞きに来てください！ 13
14. Sandbox (2026-) • 使い捨て環境 Coding Agent の利用が簡単になった結果、 無邪気に vibe coding する環境が求められるようになった • AI が作った最強の試作品 ＼完全に理解した／ 機器管理・制御 サービス • 既存システムの利用ケースでも、とにかく動くものを作った方が 学習が早い • 他システムに影響することなく、コスト不安なく、 よく分からなくなったら最初からやり直せる使い捨て環境 • 既存アセットに対し AI に好き勝手させて理解を深める環境 ユーザ認証 サービス データ配信 サービス 小規模なチームが気軽にクラウド利用ケースの実験を行う 受け皿が必要 ⇒ 試す権利の民主化 試作機能 14
15. Sandbox (2026-) SOLUTION (PROTO) ISB Account ISB Innovation Sandbox on AWS ※ ロゴがまだない Account ライフサイクルの管理 リソース初期化/アカウント払い出し/使用期限・コスト上限 etc Sandbox Account 1 • プロトタイプとして、 Innovation Sandbox on AWS (ISB) と AWS Service Catalog を組み合わせたセルフサービスコンソール • 開発者が ISB コンソールから新規利用を申請すると ISB が遊休アカウントを一つ払い出す • 払い出されたアカウント内の Service Catalog コンソー ルから、試行錯誤に使いたい数だけアセットを選択して デプロイ • コスト上限に達したらアカウントの凍結 (強制初期化も 可) が発火するため安心して作っては壊しながら試行錯誤 が行える • 現在は PoC を行っている段階であるが、 チーム内で実験用に使い捨ての環境が欲しいケースでは 早速活用中 Sandbox Account 2 (略) 試行錯誤用 domain Sandbox Account 3 (略) 試行錯誤に用いたいアセットを 適宜 CloudFormation Deploy 15 … Service Catalog
16. プロトで発見した懸念事項 技術的懸念 UX 懸念 • • Innovation Sandbox と AWS Control Tower が コンフリクトするため管理が複雑化する • • ISB の構成上、CostExplorer API を polling して Budget Limit を実現してるため、最大 24 時間のタイムラグがあ る • • アカウントにアタッチできる SCP の上限に達する模様 Account 1 安心感のある開発者体験を実現するには、 特にコストが膨らみやすいサービスに対しては別途安全策 を付け足す必要がある AuthServer A AuthServer B client 001 ISB コンソールの UI はカスタマイズできないため、 開発者体験の追求には技術的な限界がある client 002 • 16 一つ一つのコンソールの出来は良いが、 使い捨てアカウント内の使い捨てリソースという関係性 の理解と、コンソールを跨いだ操作は初学者にとって厳 しい印象を受ける 昨年参加した PEK で、プラットフォーム設計と認知負荷 理論の関係性についてのお話を聞いて感銘を受けたため、 その学びを活かした工夫を取り入れたい
17. プラットフォームの進化について考察 一貫して民主化の仕組みを設計してきた AI という新たな属性の開発者 • PF には PF のライフサイクル、PF 利用サービスには利用サービ スのライフサイクルがある • • それらを分離し、個別に開始・終了できる仕組みを維持する施策 が上手くいっている 関心の異なるさまざまなクライアント開発者に対し、セキュリ ティガバナンスやコストガバナンスを効かせた状態で民主化を実 現する仕組みに取り組んできた • そこに AI という新たな属性の開発者が加わった形になる • AI が欲していたのが試行錯誤する環境と捉えると、これまでの延 長で地続きにプラットフォームを進化させていると言えるだろう 成功事例と失敗事例を見比べると • 俯瞰的な立場から最適化した形を策定した上で、ビジネスオー ナーや開発者のユースケースを深く理解してブレイクダウンする これからも変わらないこと • そうして進めた施策が、その後の拡大に繋がっている • • 一方で何もかも先手を打つことは難しく、 失敗が初めて改善や標準化のドライバーになるのもまた事実であ るため、変更容易性の担保もプラットフォームの成功条件だろう 横断的な立場から利用者体験の感触や困難を発見する、 Platform as a Product の重要性は今後もずっと続くのだろう プラットフォームの未来像について語りましょう！ 17
18. SONY is a registered trademark of Sony Group Corporation. Names of Sony products and services are the registered trademarks and/or trademarks of Sony Group Corporation or its Group companies. Other company names and product names are registered trademarks and/or trademarks of the respective companies.