Microsoft 365とPower Platformを活用した費用可視化プラットフォームの構築

Tokyo Jazug Night #55 Microsoft 365とPower Platformを活用した費用可視化プラットフォームの構築 株式会社バンダイナムコスタジオ 八重樫 剛史 Takeshi Yaegashi 2025/07/15

自己紹介 • 名前: 八重樫 剛史 Takeshi Yaegashi • 組織: 株式会社バンダイナムコスタジオ (BNS) • 部署: テックスタジオ 第1グループ オンラインテクノロジー部 基盤ソリューション課 • 肩書: テクニカルディレクター • 社内開発者向けのクラウドサービス導入推進 プラットフォームエンジニアリングのプロジェクトに従事 • Microsoft MVP for Microsoft Azure (2023-2025) https://mvp.microsoft.com/ja-jp/PublicProfile/5005134 2

• https://mvp.microsoft.com/ja-jp/PublicProfile/5005134

本日のお話 • Microsoft 365 Power Platformを活用した「自己流」クラウド費用可視化プラットフォームの構築 • これをネタにした過去の登壇 • 2025/05/10 Global Azure 2025 Azure のコスト集計システムの開発について [1] • 2025/05/21 マイクロソフトゲーム開発者会議2025 バンダイナムコスタジオにおけるFinOpsプラットフォームエンジニアリングとGitHub Copilot導入推進の取り組み [2] • 2025/07/01 Platform Engineering Meetup #13 MicrosoftのIDaaS/SaaS/PaaSで広がるプラットフォームエンジニアリングの実践領域 [3] • 2025/07/11 GitHub Copilot Meetup Tokyo GitHub Copilot と Premium Requests のビリングについて [4] [1] https://www.docswell.com/s/yaegashi/5V13Y3-global-azure-2025 [2] https://www.docswell.com/s/yaegashi/ZL1YQ8-2025-05-23-msgamedev2025 [3] https://www.docswell.com/s/yaegashi/59G36V-pfem13 [4] https://www.docswell.com/s/yaegashi/Z7E6LD-ghcmt 3

• https://www.docswell.com/s/yaegashi/5V13Y3-global-azure-2025
• https://www.docswell.com/s/yaegashi/ZL1YQ8-2025-05-23-msgamedev2025
• https://www.docswell.com/s/yaegashi/59G36V-pfem13
• https://www.docswell.com/s/yaegashi/Z7E6LD-ghcmt

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/ 4

• https://www.finops.org/
• https://www.oreilly.co.jp/books/9784814401086/
• https://www.finops.org/framework/phases/

FinOps プラットフォームエンジニアリング • バンダイナムコスタジオにおけるFinOps • FY2024 で Inform(可視化) プラットフォームの実装が完了し FY2025 より社内運用開始 • FinOps はプラットフォームエンジニアリングプロジェクトからのボトムアップな取り組みとして始まったばかり • クラウドサービス支出の増大とオーナーシップの不在が問題視されているらしいという背景がある • バンダイナムコスタジオのプラットフォームエンジニアリング視点からのFinOpsのねらい • クラウドサービス利用のゴールデンパスを整備し、さらなるクラウドサービスの活用を推進する → 一般的なプラットフォームエンジニアリング • クラウドサービス支出の可視化と配賦のシステムを整備し、オーナーシップを定めて効果の測定と改善を可能にする → FinOpsにつながるプラットフォームエンジニアリング • 財務・ビジネス・経営層などのステークホルダーに情報を提供し、さらなるクラウドサービス投資の決断を促す → FinOpsの文化の醸成と実践を実現 5

クラウドサービスビリング: アーキテクチャの概要 6

SharePoint Lists による費用計上設定、Power Apps による GUI 構築 • Azure サブスクリプションなど各種サービスの 費用計上先 (ビリングコード) の設定を SharePoint Lists で保持する (DBの代わり) • Power Apps で開発した専用 GUI アプリの提供で セルフサービスの登録と管理を実現 7

SharePoint フォルダによるレポートの出力・公開 • 請求月ごとにSharePointフォルダを作成 • 各利用者向けのレポートExcelファイルを出力 • 各ファイルは利用者が指定した関係者のみが 閲覧可能なように自動設定 ファイル個別に アクセス許可設定可能 2025年6月のフォルダ 8

利用者向けレポート (Excelファイル) の内容 • サービスごとの金額と利用者がわかる明細を出力 • GitHub Copilotなどの個別SaaSのビリングAPIによる利用実績や Azure EA契約価格表も反映している 9

クラウドサービスビリングシステムの特徴 • 使用プラットフォーム • Microsoft Azure: Blob Storage, SQL Server, Logic Apps • Microsoft 365: SharePoint Sites, Lists, Forms, Copilot • Power Platform: Power Automate, Power Apps • GitHub Enterprise: Repository, Actions, Codespaces, Copilot • システム開発のポイント • エンジニア3名のプロジェクトで、複雑なWebアプリ開発を回 避しSaaS/PaaS/IDaaSを活用することで工数を削減 • Microsoft Entra ID・Microsoft 365・SharePoint Online・Power Platform を徹底的に研究・活用 • 重要な前提: Microsoft 365 E3 のみ (Power Automate / Power Apps プレミアムライセンスなし) • インフラエンジニアチームなので IaC や DevOps はしっかり やっていく (開発・テスト・本番の環境分離など) [1] https://qiita.com/kazu_yasu/items/78472db719114c6d86df [2] https://qiita.com/kazu_yasu/items/deed51e36dcb7ed7d40c 10

• https://qiita.com/kazu_yasu/items/78472db719114c6d86df
• https://qiita.com/kazu_yasu/items/deed51e36dcb7ed7d40c

Microsoft SaaS/PaaS/IDaaS 活用のアドバンテージ • Microsoft SaaS/PaaS/IDaaS = Microsoft 365 / Power Platform / Microsoft Entra ID • 必要な情報を、必要なユーザーにのみ見せる Visibility の機能がビルトイン • Microsoft Entra ID には組織情報 (会社・組織・プロジェクト) を反映したグループが定義できる・されている • SharePoint Online にはファイル単位・リスト項目(DB Row)単位の RBAC の仕組みが備わっている • AI エージェントなどによる安全なデータ分析・再利用が容易 • Microsoft 365 Copilot は Microsoft 365 のデータに Visibility を尊重したアクセスが可能 • うかつにデータを外部のサービスに置いてしまうと、再利用時に Visibility の一貫性の維持に苦労することになる • Slack とか Notion とか Confluence とか Redmine とか使いたいのはわかりますが… 11

Microsoft SaaS/PaaS/IDaaS の完全自動化への険しい道のり: APIアクセスの認証 • 基本的には Microsoft Graph API を OAuth 2.0 で扱うことになる • Microsoft Entra ID にアプリを登録 • Application Permissions (サービスプリンシパル) または Delegated Permissions (一般ユーザー) を選択 • Group.ReadWrite.All や Files.ReadWrite.All などの権限をアプリに付与 • 完全自動化 (人間を介さない自動化) の高いハードル • Application Permissions: スコープが広すぎる → User.ReadWrite.All や Files.ReadWrite.All でテナント全体のリソースがアクセス可能になってしまう！→ 使用禁止 → Microsoft Entra Agent ID に期待: AI エージェントの未来 - OAuth にも進化が必要な理由 [1] • Delegated Permissions: 一般ユーザーの認証がめんどくさすぎる → 多要素認証、条件付きアクセス、リフレッシュトークン維持、etc. → 認証の条件を緩めた共有ユーザーアカウント (Machine User) を作って対処することも [1] https://jpazureid.github.io/blog/azure-active-directory/the-future-of-ai-agents%E2%80%94and-why-oauth-must-evolve/ 12

• https://jpazureid.github.io/blog/azure-active-directory/the-future-of-ai-agents—and-why-oauth-must-evolve/

Microsoft による API アクセス認証のソリューション • Azureリソース "API接続" (Microsoft.Web/connections) もしくは Power Platform "接続" • 一般ユーザーの適切なWebブラウザによる認証を経て発行さ れた Delgated Permissions のトークンを維持してくれる • Azure Logic Apps や Power Automate や Power Apps と いったローコード開発環境でしか利用できない • IaC や DevOps との相性が悪いのが難点 • 経験豊富なインフラエンジニアにとっては苦行 • それでも API アクセス認証維持の面倒を見てくれるメリット は大きいので採用 13

Azure Logic Apps の Infrastructure as Code と DevOps • Azure Logic Apps は次の手法で IaC 化 • Azure Portal の Workflow Designer でアプリ作成・編集 • Azure CLI で ARM テンプレートをダウンロード • 環境による可変部分をパラメーター化 • Bicep の loadJsonContent() 関数で読み込んで Microsoft.Logic/workflows リソースに埋め込む • 上記の手順を自動化するスクリプトを開発 • 開発者は Azure Portal の Workflow Designer の作業に専念 できるようになった Azure Portal の Workflow Designer で アプリ作成・エクスポートした JSONファイルをBicepで使用 • Azure Logic Apps の IaC・DevOpsの完遂には かなりの労力が必要 • 経験豊富なインフラエンジニアであっても苦行 • GitHub Copilot のおかげでだいぶ楽にはなった API接続リソース指定 14

Power Platform の Infrastructure as Code と DevOps • やりたいこと • Power Automate や Poewr Apps のアプリを開発・テスト・本番などの環境を分けて運用したい • できるものなら Git でソースコードを管理したい • プレミアムライセンスは使いたくない (Microsoft 365 E3 のみ) • Power Platform Application Lifecycle Management (ALM) [1] • 「ソリューション」としてアプリのエクスポート・インポートが可能になり Git でも管理できるようになる • ソリューションを利用するには Dataverse が有効な Power Platform 環境が必要 → Azureサブスクリプションの従量課金プランで Power Apps ライセンスなしで運用環境が作成可能 → Microsoft 365 E3 ライセンスしかなくても使える • Power Platform ALM・DevOps の公式ツール • Power Platform Pipeline (GUI による DevOps 機能) [2] → 複数の環境間でソリューションのエクスポート・インポートができる → ただしユーザー全員に「マネージド環境」ライセンスが必要、Microsoft 365 E3 ライセンスだけではだめ • Dataverse Git Integration (Git リポジトリ統合、プレビュー) [3] → Azure DevOps Git リポジトリにソリューションが保存できるようになる (GitHub に対応していないのが残念) [1] https://learn.microsoft.com/ja-jp/power-platform/alm/overview-alm [2] https://learn.microsoft.com/ja-jp/power-platform/alm/pipelines [3] https://learn.microsoft.com/ja-jp/power-platform/alm/git-integration/overview 15

• https://learn.microsoft.com/ja-jp/power-platform/alm/overview-alm
• https://learn.microsoft.com/ja-jp/power-platform/alm/pipelines
• https://learn.microsoft.com/ja-jp/power-platform/alm/git-integration/overview

Power Platform CLI による DevOps の実装 • Power Platform CLI (pac) の活用 • ソリューションのエクスポートやインポートが可能になる CLI • Power Platform Actions という GitHub Actions で簡単に利用できる • GitHub Actions ベース DevOps ワークフロー実装 • 環境・ソリューション間のコピー・デプロイ [1] → デプロイ後 GitHub の Variables をソリューション環境変数に設定する • 環境・ソリューション間の環境変数定義のコピー (未公開) → コピー元のソリューションファイルを展開して新しい環境変数を読み 取り対応する GitHub の Variables の定義を自動作成する • Microsoft 365 E3 だけで実用的な DevOps が可能になった！ [1] https://qiita.com/kazu_yasu/items/78472db719114c6d86df 16

• https://qiita.com/kazu_yasu/items/78472db719114c6d86df

まとめ • お話したこと • FinOps プラットフォームを SaaS/PaaS/IDaaS で実装することの意義 • ローコード開発ツールにより開放されたユーザー認証の苦悩 • ローコード開発ツールによりもたらされた ALM・DevOps の苦悩と解決 • 今後のロードマップ • Power Apps Component Framework などの Fusion 開発を含む ALM・DevOps 対応 • Azure 以外のクラウドや SaaS の対応 (Azure, Google, Oracle, wtc.) • Microsoft FinOps ツールキット[1] の導入、FOCUS などの FinOps 標準仕様の対応 [1] https://learn.microsoft.com/ja-jp/cloud-computing/finops/toolkit/finops-toolkit-overview 17

• https://learn.microsoft.com/ja-jp/cloud-computing/finops/toolkit/finops-toolkit-overview

Thank You!! 18