MicrosoftのIDaaS/SaaS/PaaSで広がるプラットフォームエンジニアリングの実践領域
4.9K Views
July 02, 25
スライド概要
Platform Engineering Meetup #13
https://platformengineering.connpass.com/event/358498/
Microsoft MVP for Microsoft Azure
関連スライド
各ページのテキスト
Platform Engineering Meetup #13 MicrosoftのIDaaS/SaaS/PaaSで広がるプラットフォームエンジニアリングの実践領域 株式会社バンダイナムコスタジオ 八重樫 剛史 Takeshi Yaegashi 2025/07/01
自己紹介 • 名前: 八重樫 剛史 Takeshi Yaegashi • 組織: 株式会社バンダイナムコスタジオ (BNS) • 部署: テックスタジオ 第1グループ オンラインテクノロジー部 基盤ソリューション課 • 肩書: テクニカルディレクター • 社内開発者向けのクラウドサービス導入推進 プラットフォームエンジニアリングのプロジェクトに従事 • Microsoft MVP for Microsoft Azure (2023, 2024) https://mvp.microsoft.com/ja-jp/PublicProfile/5005134 2
本日のお話 • 情シス視点のプラットフォームエンジニアリングの実践領域 • 情シス = 情報システム部、社内のITインフラの構築と運用を担当する部署、ステークホルダーの一角 • なお登壇者 = 八重樫は情シスの人間ではありません、開発者です • バンダイナムコスタジオにおける事例の紹介 • 情シスとの連携によるマイクロソフトのIDaaS/SaaS/PaaSを活用したプラットフォームエンジニアリング • GitHub Enterprise Managed Users の導入、ユーザーのSSOとプロビジョニングの実現 • クラウド利用料金のビリング、FinOps プラットフォームの構築 [1] https://www.finops.org/framework/phases/ 3
プラットフォームエンジニアリングの実践領域とは？ • PFEM や PEK の講演でよく語られるトピック = 開発者視点 • 実行基盤 → Kubernetes, 各種PaaS • CI/CD → GitHub Actions, ArgoCD, Jenkins • 開発者ポータル (IDP) → Backstage • オブザーバビリティ → OpenTelemetry, Prometheus, Grafana • 生成AI活用 → GitHub Copilot, Azure AI Services, Amazon Bedrock, Google Gemini • セキュリティ → IAM, RBAC, OPA • 開発者文化・組織設計 → DevOps, SRE, DORA Metrics, Team Topologies, InnerSource • あまり語られていない気がするトピック = 情シス視点 • 開発者の作業・コラボレーション環境 • 開発者だけではないステークホルダーも含む情報共有環境 • 開発者プラットフォームの参加者全員をカバーするID基盤 • 両視点に共通する目的 • 認知負荷の削減、開発者体験(DevEx)の改善 4
情シス視点のプラットフォームエンジニアリングの実践領域 • GitHub のような開発に不可欠なサービスを、開発者にいかにスムーズに使わせるか • クラウド利用アカウント (Azureサブスクリプションなど) をどう払い出して管理するか • クラウドサービスの利用料金を各部署・各プロジェクトチームにどう配賦するか • 開発者・ステークホルダー向けのサービス・情報共有のスコープをいかにコントロールするか • 運用チームにだけ見せたいダッシュボードアプリ • 開発者チームにだけ共有したい API ドキュメントやマニュアル • えらい人にだけ共有したいクラウド料金請求明細 • セキュリティ・ガードレールのポリシーをいかに設定するか • 従業員の使用するネットワーク、ファイヤーウォール、VPNなど 5
情シス視点が色濃く出ている過去の登壇 • PEK2024: 大規模エンタープライズの全員参加が可能な内部開発者ポータルの野望 [1] • 大規模エンタープライズにおける インナーソース活動の推進基盤として、 従業員全員が参加できることを目的とした 内部開発者ポータル (Backstage) を構築する話 • 開発者プラットフォームの分断 「全員が GitHub Enterprise が使える」という前提が 成り立たない場合の情報共有基盤をどう構築するか • この取り組みから現在まで、 プラットフォームがどう発展したのかについては PEK2025で詳しくお話します [1] https://www.cnia.io/pek2024/sessions/342bb6b7-33c0-48ef-9476-4a87529c2a37/ 6
情シス視点のプラットフォームエンジニアリングのススメ • もしあなたが開発者なら、 「情シスのサービス」を活用してプラットフォームエンジニアリングの実践領域を広げよう • IT企業であれば従業員全員が使うために情シスが導入したIDaaS・SaaS・PaaSがなにかあるのでは？ • それを開発者プラットフォームの改善に役立てるようなエンジニアリングを行う • 例: Microsoft 365 E3 導入企業の「情シスのサービス」 • IDaaS → Microsoft Entra ID • SaaS → Microsoft 365: SharePoint Online, Microsoft Teams, Microsoft Loop, Copilot, etc. • PaaS → Power Platform: Power Automate, Power Apps, etc. • その他の企業向けグループウェアでも活用できるものはたくさんあるはず • Google Workspace • Confluence • Slack • Notion • Asana 7
情シス視点のプラットフォームエンジニアリングの実践 • 「情シスのサービス」のメリットを認識する • 開発者も「情シスが導入したサービスは使いにくい」といった先入観を持たずに調べて使ってみよう • 多くの場合「開発者のサービス」よりもはるかに多くのユーザーをカバーしていることがメリットになる • 「情シスのサービス」を活用して開発者体験 (DevEx) を向上させる例 • ファイルやドキュメントの社内共有 • ローコード開発環境による従業員向け Web アプリの実装 • チャットボットによる従業員向け自動化インターフェースの実装 • 社内向けWebサービスのユーザー認証・認可 (OAuth2, OpenID Connect, etc.) • GitHubのような他社SaaSのユーザープロビジョニングとシングルサインオン 8
実践例: ユーザーID基盤に含まれる従業員・組織の情報を理解して活用する • 大規模なエンタープライズに特有の多層化した会社・部署・プロジェクトのグループ • アプリやファイルごとに公開範囲が限定したい「エンタープライズ全体」「A会社のみ」「Bプロジェクトのみ」 • ポータル Web サイトなどでのユーザー認証や認可に活用 A会社 A事業部 A部 A課 B課 B会社 B事業部 C事業部 D事業部 B部 C部 D部 E部 C課 D課 E課 F課 Aプロ ジェクト Bプロ ジェクト Cプロ ジェクト 9
実践例: SaaSの機能を深く理解し、自分だけでなく他の従業員にも使ってもらう SharePoint Online & Microsoft Loop: 任意の公開範囲での情報共有手段としておすすめの組み合わせ 運用ドキュメントやマニュアルの公開場所、Thinnest Viable Platform の実装部品に活用できる 10
開発者は情シスと仲良くしましょう！ • 「情シスのサービス」を活用するには特別な権限が必要なこともある • ユーザー認証やプロビジョニングを実現するには、アプリの登録などに管理者権限が必要なことが多い • 自分が「情シスのサービスの管理者」なら問題ないが、そうでない場合は… • 開発者が情シスに交渉することになったら • 情シスは全社員向けのITインフラを預かる身なので、ちょっとした変更も嫌がられることが多い • 情シスが置かれている立場を考えリスペクトすることを忘れないこと • 筆者の所属するバンダイナムコスタジオの場合 • バンダイナムコグループの情シス企業が、従業員 10,000 人以上が利用する基幹ITインフラ(MS365など)を統括する • バンダイナムコスタジオは、従業員 2,000 人程度の事業会社のひとつにすぎない • 交渉は簡単ではないが、10,000人をカバーするIDaaS/SaaS/PaaSを活用できるならその価値はある 11
エンタープライズ (大企業) IT インフラ更新の困難を乗り越える努力 • エンタープライズにありがちなITインフラのアジリティ不足 • バンダイナムコグループのMicrosoft 365はユーザーが1万人を超える巨大な テナントであり保守的になることはやむを得ない • 前例のない機能利用や設定変更の要望を通すことは非常に難しい • ステークホルダーとの対話と根回し • ステークホルダーに対して時間をかけて説明し調整する努力が必要 • 関連部門や上位役職者を巻き込み、事業会社としての正式な要望を基幹IT インフラ統括会社に申し入れしてもらう • クラウドベンダや導入担当SIerからも支援を得る • 自分事とする姿勢を見せコラボレーションする • 要望実現までの道のりを他人事とせず、自分でも十分に研究・検証して担 当者にやってもらうべきオペレーションやリスク対処を一緒に考える • Microsoft 365 開発者プログラム [1] 実験用 Microsoft 365 サブスクリプション / Microsoft Entra ID テナント • コラボレーションの成功を通じて信頼関係が確立できれば、 アジリティは徐々に向上していく [1] https://developer.microsoft.com/ja-jp/microsoft-365/dev-program 12
バンダイナムコスタジオにおける事例の紹介 • GitHub Enterprise Managed Users (GitHub EMU) の導入、SSOとプロビジョニングの実現 • クラウド利用料金のビリング、FinOps プラットフォームの構築 13
GitHub Enterprise Managed Users (GitHub EMU) とは？ • GitHub Enterprise Cloud の特殊な動作モードのひとつ [1] • Microsoft Entra ID などの IdP と連携する → IdP ユーザーのシングルサインオン → IdP ユーザー・グループからGitHub のユーザー・チームを同期 (SCIM プロビジョニング) • 外部の世界と隔離された GitHub Enterprise Cloud を実現する → GitHub Enterprise Server のクラウド移行先の選択肢のひとつ • 一般の GitHub Enterprise Cloud にはない制限がある • 外部のユーザー・リポジトリとコラボレーションできない、Gist が使えないなど • 選択のガイドライン → Choosing an enterprise type for GitHub Enterprise Cloud [2] • バンダイナムコグループでは 2022 年から GitHub EMU を利用している • バンダイナムコスタジオの開発者が、バンダイナムコグループの情シスの多大な協力を得て実現 [1] https://docs.github.com/en/enterprise-cloud@latest/admin/managing-iam/understanding-iam-for-enterprises/about-enterprise-managed-users [2] https://docs.github.com/en/enterprise-cloud@latest/admin/managing-iam/understanding-iam-for-enterprises/choosing-an-enterprise-type-for-github14 enterprise-cloud
GitHub EMU ではない一般的な GitHub Enterprise の問題点 • 面倒な管理作業 → 利用率低迷の懸念 • User, Organization, Team は従業員各自が自分で登録・作成する必要がある • User を従業員が登録・作成するまで Organization や Team に追加できない • User の個人設定の統一が難しい • User 名 → 「yaegashi」「bns-yaegashi」「yaegashiBNS」 • 表示名 → 「八重樫 剛史」「八重樫 剛史」「八重樫剛史」「Takeshi Yaegashi」「YAEGASHI Takeshi」 • セキュリティ侵害や設定・操作ミス → 情報漏洩の懸念 • User のパスワード管理は従業員個人に委ねられる • User は従業員が異動・退職しても Organization や Team から自動的に削除されない • User, Organization, Team の管理・設定ミス • 複数の Organization に所属する User の操作ミス 15
バンダイナムコグループにおける GitHub EMU • バンダイナムコグループの GitHub ユーザーは 自動的にアカウントが作られる • ユーザーネーム: "{社内ADユーザー名}_876" • メールアドレス: "社員番号@bandainamco.co.jp" • 表示名: Microsoft 365 アカウントと同じ • GitHub EMU の特徴 • まるで幽霊のようなユーザーアカウントと組織 876 外部 → 内部: なにも見えない 876 内部 → 外部: 見えるがちょっかいは出せない • 利点:高いセキュリティ、ユーザーアカウント一元管理 • 欠点: 外部の世界は見えるが交流はできない 16
GitHub EMU のサインイン手順 • GitHub.com のサインインでユーザー名に "_876" とだけ入力 (パスワード不要) → Microsoft 365 にリダイレクト → "社員番号@bandainamco.co.jp" でサインイン → 完了！ 17
GitHub EMU の導入の成果 • セキュリティを強化しつつ、高い開発者体験 (DevEx) が実現できた • ライセンスを取得したユーザーはすぐに GitHub にプロビジョニングされて使えるようになる • Microsoft Entra ID のグループと GitHub のチームの同期が便利 • 情報漏洩やアクセス侵害のセキュリティの懸念の多くが解決 • 開発者と情シスが協力して成し遂げたプラットフォームエンジニアリングの実例 • 情シスの持つ Microsoft Entra ID テナント管理者権限が SSO やプロビジョニングの設定に必要 • 開発者側が持つさまざまな要件を粘り強く説明し、情シスの理解を得ることで実現にこぎつけられた 18
FinOps プラットフォームの構築 • FinOps とは？ • クラウド利用のコストと価値を最適化するためのフレームワークおよび文化的実践 • エンジニアリング・財務・ビジネス・経営など各部門のチームが協働して推進する • 業界団体: FinOps Foundation [1] • 参考書籍: クラウドFinOps 第2版 [2] • FinOps の3段階 [3] • Inform (可視化) – クラウドコストの見える化と正確な割り当て • Optimize (最適化) – リソース最適化や無駄削減によるコスト最適化 • Operate (運用) – ガバナンスと継続的改善による持続的な運用最適化 [1] https://www.finops.org/ [2] https://www.oreilly.co.jp/books/9784814401086/ [3] https://www.finops.org/framework/phases/ 19
FinOps プラットフォームエンジニアリング • バンダイナムコスタジオにおけるFinOps • FinOps はプラットフォームエンジニアリングプロジェクトからのボトムアップな取り組みとして始まったばかり • クラウドサービス支出の増大とオーナーシップの不在が問題視されているらしいという背景がある • バンダイナムコスタジオのプラットフォームエンジニアリング視点からのFinOpsのねらい • クラウドサービス利用のゴールデンパスを整備し、さらなるクラウドサービスの活用を推進する → 一般的なプラットフォームエンジニアリング • クラウドサービス支出の可視化と配賦のシステムを整備し、オーナーシップを定めて効果の測定と改善を可能にする → FinOpsにつながるプラットフォームエンジニアリング • 財務・ビジネス・経営層などのステークホルダーに情報を提供し、さらなるクラウドサービス投資の決断を促す → FinOpsの文化の醸成と実践を実現 20
FY2024 までの Azure クラウドサービスビリング • Azure EA契約の多数のAzureサブスクリプションに計上される様々なクラウドサービス利用料金を 単一の「クラウド開発推進」予算でまかなっていた 21
FY2025 からの Azure クラウドサービスビリング • サービスの利用者である会社・部署・プロジェクトをビリングアカウントとして、 利用料金請求を適切に配賦できるような集計・レポートのシステムを構築した 22
クラウドサービスビリング: アーキテクチャの概要 23
クラウドサービスビリング: アーキテクチャの説明 • 使用プラットフォーム • Microsoft Azure: Blob Storage, SQL Server, Logic Apps • Microsoft 365: SharePoint Sites, Lists, Forms, Copilot • Power Platform: Power Apps • GitHub Enterprise: Repository, Actions, Codespaces, Copilot • システム開発のポイント • エンジニア3名のプロジェクトで、複雑な Web アプリ開発を回避し SaaS・PaaS を活用することで工数を削減 • Microsoft Entra ID・Microsoft 365・SharePoint Online の機能研究 • ステークホルダー (システム管理者や経理部門担当者) との連携、インフラ運用体制とドメイン知識の理解 • GitHub Copilot および Microsoft 365 Copilot による支援が非常に役に立った 24
SharePoint Lists・Forms による集計・配賦設定の入力 • Azure サブスクリプションや Azure DevOps 組織 などサービスごとの費用計上先(ビリングコード) を SharePoint Lists で保持する • Lists Form でユーザーの登録申請を受付 サービス初期段階では十分な機能 25
Power Apps による専用アプリの実装 • 現在は Power Apps による専用 Web GUI アプリを提供中 • SharePoint Lists を検索してビリングアカウントや費用計上先を選択し Lists に保存するアプリ • アプリの開発・テストの期間は1か月程度 26
ビリングアカウント向けレポートの出力・公開 • 請求月ごとにSharePointフォルダを作成 • Logic Apps を使って各ビリングアカウント 向けのレポートExcelファイルを出力 2025年4月のフォルダ • 各ファイルはビリングアカウントが指定した Microsoft Entra IDグループのユーザーのみが 閲覧可能に設定 27
ビリングアカウント向けレポート (Excelファイル) の内容 • サービスごとの金額と利用者がわかる明細を出力 • Azure DevOpsやGitHub Copilotなどの個別SaaSのビリングAPIによる利用実績や Azure EA契約価格表も反映している 28
GitHub Copilot Premium Requests • 06/18(水) Premium Requests 開始 • 無料枠を含む基本料金 + 超過分の料金の従量課金 • ChatやEditなどを使用するたびに1リクエストを消費 • リクエスト単価 $0.04 モデルごとに乗数が設定 [1] https://docs.github.com/en/enterprise-cloud@latest/copilot/about-github-copilot/plans-for-github-copilot [2] https://docs.github.com/en/enterprise-cloud@latest/copilot/managing-copilot/monitoring-usage-and-entitlements/about-premium-requests 29
GitHub Copilot Premium Requests ビリング対応 • Premium Requests 利用実績の取得 [1] • ユーザーごとの利用実績をCSVファイルとして出力・ダウンロード可能 • BNSクラウドサービスビリングの Premium Requests 対応 • ユーザーごとの Premium Requests 超過利用料金を集計し、 所属部署の費用として計上する • 各部署やプロジェクト向けにExcel ファイルのレポートが1日1回生成され、 前日までに各メンバーが利用した Copilot の金額がわかる • CSVファイルのダウンロードの自動化が面倒なのが問題だが、 Microsoft 365 と PaaS で対処可能 → CSVファイル出力をリクエストするとダウンロードURLがメールで届く → Power Automate で自動化を実装する [1] https://github.blog/changelog/2025-05-16-github-copilot-premium-request-report-available-today/ 30
GitHub Copilot Premium Requests ユーザー個人の利用状況の把握 • Copilot ユーザー個人も自身の Premium Requests 利用状況が把握可能 • Visual Studio Code などのエディタに専用の UI が用意され、リアルタイムに利用状況を把握できる • プリウス効果 • 「クラウドFinOps」書籍の冒頭で紹介されている用語 • システムのフィードバックレスポンスが強化され、現在の状況が リアルタイムで正確に把握できるようになると、ユーザーの行動が 変化し、利用効率が大幅に向上する現象を指す言葉 • FinOps の文脈では、コスト消費の遅延のないフィードバックにより、 ユーザーは効果的にコスト対策を講じることができるようになり、 また高額なサービスの利用も自信を持って行えるということ • BNSのクラウドサービスビリングシステムも、プリウス 効果が得られるような遅延のない正確な情報提供を 目指していく 31
FinOps プラットフォーム導入の効果 • 経理部門や予算を預かるステークホルダーからはすこぶる好評 • 開発者も自分の部署・プロジェクトからの支出という意識ができた結果、 • クラウド利用料金の削減努力を怠るようなモラルハザードが低減 • 手続きや承認の簡略化により GitHub Copilot の申し込みが今年度より急激に増加 • 具体的な数値による効果測定はこれから • プラットフォームエンジニアリングとしての 成果は出ていると思われる 32
まとめ • 情シス視点のプラットフォームエンジニアリングの実践 • 開発者でも情シス視点で「情シスのサービス」を活用しプラットフォームエンジニアリングを推進しよう • 情シスの人々とは仲良くしよう • バンダイナムコスタジオにおける事例の紹介 • GitHub Enterprise Managed Users の導入、情シスの協力によるユーザーのSSOとプロビジョニングの実現 • クラウドサービスビリング FinOps プラットフォームの構築 、「情シスサービス」の IDaaS/SaaS/PaaS をフル活用 • GitHub Copilot の導入推進、Copilot Premium Requests にクラウドサービスビリングが対応予定 • 将来はAIエージェントがみんなやってくれるかも？ • 社内の情報を整理し分析システムやAIエージェントが利用可能な場所に置くように整備することはまだ人間の仕事 • 特に M365 Copilot については情シスのサービスとIDaaS/SaaS/PaaS の活用が近道 33
Thank You!! 34