信頼できる開発プラットフォームをどう作るか？ - Governance as Codeと 継続的監視／フィードバックが導くPlatform Engineeringの進め方- 2025.08.20 Yurie Mori, Yutaka Osada 

INTRODUCTION 

このセッションで学べる事 GitHub Enterprise のような開発プラット フォームのガバナンスのた めのリポジトリ作成/運 用 01 ガバナンスのためにどのよ うなことをコード化すれば よいのか 02 管理者だけでなくプラッ トフォームユーザー（開 発者）も含めてプラット フォームを育てていくため のプロセス 03 セキュリティリスクや不審 なユーザーアクティビティ を人力に頼らず継続的 に監視、即時フィード バックするための仕組み 04 

Agenda 01 背景とアプローチ 02 Governance as Codeによる 開発プラットフォームの構成のコード化とインナーソース 03 継続的監視とセキュリティフィードバック 04 まとめ 

Yurie Mori（森 友梨映） • Sr.Consultant(DevOps Engineering)@Avanade • Microsoft MVP for Developer Technologies(DevOps) 2024～ • Microsoft MVP for DevOps & Cloud Security 2025~ • Zennでの記事執筆（Azure DevOpsを使ったAgile/DevOpsの実践, エンタープライズでGitHubを使うとか） • TFSUGでの登壇 • 書籍執筆(AZ-400の試験対策本) • お仕事 • Solution Architect (AI assisted SDLC & DevOps) • エンタープライズへのDevOpsソリューション（ Azure DevOps/GitHub Enterprise）の導入・構築 • DevOps/DevSecOps Transformationの技術アドバイザリ • 技術スタック • Azure DevOps, GitHub, Azure, .NET, C# • Please follow me 

Yutaka Osada（長田 豊） • Manager (DevOps Engineering) @Avanade Japan • Solution Architect (AI assisted SDLC & DevOps) • エンタープライズへのDevOpsソリューション（ Azure DevOps/GitHub Enterprise）の導入・構築 • Azure PaaS × GitHub Enterpriseのオファリング開発 • 個人活動 • Zennでの記事投稿（IaC、CI/CD Pipelines Azure DevOps Rest API等） • 登壇（DevOps Days Tokyo 2025、各種Azure系ユーザコミュニティ） • 書籍執筆(AZ-400の試験対策本) • 技術スタック • C#, .NET, Azure(PaaS), Azure DevOps, GitHub • Please follow me 

背景とアプローチ 

開発プラットフォームの運用に関する背景と課題 • 開発プラットフォームとしてGitHub Enterpriseを、クラウドはAzureを使用 • ベストプラクティスに基づいたGitHub Enterpriseのガバナンス、構成の横展開が必要になった • Excelでパラメーターシートを書くとかだと時間が取られすぎ&メンテしにくい • Enterprise ownerだけでなく開発プラットフォームを使うすべての人にガバナンスや設定を公開して 透明性を担保し、できればプラットフォーム運用に貢献して欲しい（リクエストを出すなど） • GitHub Enterpriseの環境、その配下で作成されるOrganizationやReposの監査可能性やセ キュリティ的に安全であるということを可視化したい • 監査ログはGitHubの機能で取得できるけど、なかなかログを見に行ってログを読んで不審なアクティビ ティがないかを確認して。。。というのはあまり現実的でない • システムで継続的に監視/なにか異常があったときには即座に検知されるようにしたい 

開発プラットフォームに対する「信頼性」をどう担保するか？ Governance as Code • 開発プラットフォームのガバナンスの方針や設定・構成をコードとして管理することで、再現性と透明性を確保 • ルール・ガイドラインをInnerSource化し、誰でも参照・改善可能に • 設計意図（なぜその構成なのか）もADR(Architecture Decision Record)としてGOVERNANCE.mdに 記録し、属人化を排除 継続的監視/セキュリティフィードバック • 開発プラットフォームを継続的に監視して、プラットフォーム上の不審なアクティビティやセキュリティ的な脆弱性を即 検知し、運用にフィードバック • セキュアで拡張性が高く、かつ開発者にとって“使いやすい”状態を維持し続ける仕組みを目指す 

GitHub Enterprise ガバナンスの方針、設定をコードで管理 インナーソースとして公開 監査ログ Resource Group Event Hubs Container Apps Cosmos DB Enterpriseデータ受信 [Backend endpoint using Dapr] Enterpriseデータ登録 Enterpriseデータ Key Vault Log Analytics Application Insights Near realtime Storage account Container Registry CI /C D Log Analytics Defender for Cloud Sentinel Logic Apps Playbooks 推奨事項/アラート Analytics Rules / UEBA / Hunting GitHubAudit_CL 等 通知/自動化 Enterprise owner セキュリティ監視 ・フィードバック 監査ログの永続保存 不審なユーザーアクティビティ やGitHub上のセキュリティリス クをチケット登録 Enterprise ownerに通知 GitHub Issues ソリューション全体像 

Governance as Codeによる 開発プラットフォームの構成のコード化とインナーソース 

Governance as Code(GaC) • 開発プラットフォームに関わる構成、ルール・権限をコード化してバージョン管理するこ とで再現性と透明性を確保 • ガバナンス構成は .md/.json などで管理 • GitHub Enterpriseの設定をコードベースで管理可能に（ブランチ保護、ロール 設計等） • 管理者だけでなく開発者にも可視化され、理解される基盤へ 

GitHub Enterpriseのガバナンス設定のコード化 • GitHub Well Architected Frameworkを参照し、ガバナンスの為にドキュメ ント化すべきものを識別 • ロール設計やアクセス制御、セキュリティルールをすべてコードで定義 • 変更プロセス（Pull Request）自体もGitHub上で管理 • コンプライアンス要件やポリシーを構成ファイルとしてリポジトリに保存 • ブランチ保護ルールセット/pushルールセット/Tagテンプレートルールセットはjson でバージョン管理 • 組織全体で参照できるようにInnerSource化 

ガバナンスのためにコード化すべきもの • ブランチ戦略 • GitHubのロールと各ロールがどのような権利と責務を持っているか • インシデント発生時のレスポンス計画 • ガバナンスのポリシー（ステークホルダーもガバナンスポリシーの更新にコミットできるようにする） • トレーニングの資料 • 構成管理のポリシー • エンタープライズの設定 • データレジデンシーのポリシー • サポートとメンテナンスのプラン • 意思決定のプロセス • プラットフォーム内で発生する変更の適用プロセス（コードのマージやGitHub Enterprise内の設定 の変更） 出典：https://wellarchitected.github.com/library/governance/checklist/ 出典：https://wellarchitected.github.com/library/governance/design-principles/ 

コミュニティ正常性のために作成が推奨されている ドキュメント • CODE_OF_CONDUCT.md • CONTRIBUTING.md • ディスカッションのテンプレート • GOVERNANCE.md • イシューと pull request のテンプレートおよび config.yml • SECURITY.md • SUPPORT.md • CODEOWNERS.md 出典：https://docs.github.com/ja/enterprise-cloud@latest/communities/setting-up-your-project-for-healthy-contributions/creating-a- default-community-health-file 

ガバナンス用Reposでのドキュメンテーション(1/2) ガバナンス専用のRepos、enterprise-governanceを作成し、GitHub WAFのGovernanceで 作成を推奨されているドキュメントとコミュニティ正常性のためのドキュメント群を管理。 ドキュメントの種類 記載内容 GOVERNANCE.md エンタープライズレベルのガバナンスポリシー（Enterpriseのルール、ユーザー管 理方針、ポリシー策定プロセス） organization/ORGANIZATIONNAME-GOVERNANCE.md 各Organizationごとのポリシー（Org固有の設定方針） SECURITY.md インシデント対応計画、セキュリティポリシー、報告フロー COMPLIANCE.md 社内で定められているコンプライアンス ACCESS_MANAGEMENT.md ロールと権限の管理、意図しないアクセスの監視ポリシー CHANGE_MANAGEMENT.md プラットフォーム内の変更適用プロセス（コードのマージ、ガバナンスルール変更 管理） enterprise-settings/ Enterpriseレイヤーの設定値（codeのrulesetなどエクスポート/インポート できるものは設定内容をjson形式でエクスポートして保存） organization/organization-settings/ 各Organizationレイヤーの設定値（codeのrulesetなどエクスポート/イン ポートできるものは設定内容をjson形式でエクスポートして保存 policies/data-residency.md データレジデンシーポリシー データの保存場所、転送ポリシーを定義 ※2025/8時点、日本ではまだdata residencyはavailableではない policies/security-audit.md GitHubの監査ログ・セキュリティイベントをどのように監視・分析するか 

ガバナンス用Reposでのドキュメンテーション(2/2) ガバナンス専用のRepos、enterprise-governanceを作成し、GitHub WAFのGovernanceで 作成を推奨されているドキュメントとコミュニティ正常性のためのドキュメント群を管理。 ドキュメントの種類 概要 CODE_OF_CONDUCT.md コミュニティ行動規範 CONTRIBUTING.md 開発者向けのコントリビューションガイドライン（ブランチ戦略、コーディング規約、 コードレビュー方針） SUPPORT.md トレーニング資料やサポートリソースへのリンク CODEOWNERS.md リポジトリごとのオーナー設定 .github/ISSUE_TEMPLATE/ Issueテンプレートの格納 .github/PULL_REQUEST_TEMPLATE.md PRの標準テンプレート .github/DISCUSSION_TEMPLATE.md GitHub Discussions用のテンプレート ReadMe.md Onboardingの際に最初に読まれるドキュメントとして、各種ドキュメントの説 明 

開発プラットフォーム構成とガバナンスのインナーソース化 ガバナンスの方針、設定をコードで管理 GitHub Discussionsで構成に関する変更リクエストやQ&Aを 受け付け Enterprise owner • CODEOWNERとしてガバナ ンス用Reposを管理 • レビュー/merge完了後に設 定を適用 Enterprise member インナーソースとして 公開 • Discussionsで設定変更をリクエスト（新機能有効化など） • リクエストがEnterprise ownerからOKされたらPRで変更を提案 

開発プラットフォーム構成とガバナンスのインナー ソース化 プラットフォームを“共創”する文化基盤 • 管理者だけでなくプラットフォームのユーザー（開発者）もプラットフォームのガバナンスや運用にPull Requestで 貢献 • プラットフォームが一方的な「提供物」ではなく、組織全体で育てる“プロダクト”になる • 「一度設定して終わり」ではなく、プラットフォームのユーザーも巻き込んでプラットフォームを運用できるようになった。 ガバナンス設計や構成などの知見がコードとして残り、組織知として継承可能に • ガードレールの透明化と納得感の向上 • 「管理者に聞かないとわからない」状態を回避 • 設定値だけでなくガバナンスの方針や背景の横展開が可能になった 

継続的監視とセキュリティフィードバック 

継続監視と証跡の蓄積 “使われ続ける” プラットフォームへ 不審・誤設定は“起きる前提”。監視は運用、証跡は資産となる。 Azure Resource Group GitHub Event Hubs Container Apps Cosmos DB Enterpriseデータ受信 [Backend endpoint using Dapr] Enterpriseデータ登録 Enterpriseデータ Key Vault Log Analytics Application Insights Enterprise 認 証 ・ 認 可 Enterprise監査ログ Near realtime GitHubに対して何らかの操作 を実行 監査ログ入力 Storage account Container Registry CI /C D { "@timestamp": 1740509280410, "_document_id": "PESjbtR5IpEtCVRIcfdKzQ", "action": "audit_log_streaming.check", "business": “xxxxx-nfr", "business_id": 277532, "created_at": 1740509280410, "operation_type": "access“ ・・・ } 利用ユーザー Account 蓄積部のアーキ構成（例 • 開発プラットフォームで起きた操作の記録 （監査ログ）をすべて残し、一か所に集約 • 記録はだれ・いつ・どこ・何をが分かる形に 整え、あとから探しやすく。 Point 01 何を「残す」のか Enterprise／Org。例外ゼロ（新規や削除にも自動追従するの か。）操作ログ・権限変更・設定変更、構成スナップショット、ワークフ ロー実行記録 など Point 02 どのくらい「残す」のか どれくらい残すかを先に決める（例：1年／3年／7年） 変更できない保管（一定期間は削除・上書き不可） Point 03 後から「使える」ように整える 標準スキーマ（日時／だれが／どこで／何を）：検索しやすいメタ データと索引 

GitHub Azure 監査ログを“気づき”に変える (Microsoft Sentinel × Defenderで分析と通知を自動化) 溜めるだけで終わらせない。ルール化 → 検知 → 通知 → 対応を標準化。 利用ユーザー Log Analytics Defender for Cloud Sentinel Logic Apps Playbooks アラート 通知 Enterprise owner 推奨事項/アラート Analytics Rules / UEBA / Hunting GitHubAudit_CL 等 通知/自動化 • 事前に決めたルールに沿って、いつもと 違う動き（例：権限の急な変更や公 開設定の変更）を自動で検知。 • 検知したら通知。通知からワンクリック で対応手順（Runbook）を開き、対 応内容がわかるように。 分析・通知部のアーキ構成（例 ガバナンスの方針、設定をコードで管理 インナーソースとして公開 監査ログ GitHub Issues 

アノマリ検知と運用へのフィードバックループ（1/2） 普段を覚える （Baselineモデルの自動学習） 普段のパターンを学習 1. 過去３週間分の監査ログを読 み込む 2. 「誰が・いつ・どこから・何回操 作したか」の”平均値”を作成 異常を見つける （アノマリ検知） 異常を検知（例） 1. repo.delete が普段 0→1 日 10 件 2. 日本の開発者が深夜に米国 IP から admin:org トークン 作成 3. 1 時間で 300 コミット（通常 の ×8） などの通常と異なるaction すぐ知らせる （通知） 異常レベルで出し分け 1. Info (軽微) → 開発者個人 にメール送付 2. Warning (中) → SecOps チャネルに Slack 投稿 3. Critical (重) → Teams チャネルへ全体メンション Solution＆Tool Microsoft Sentinel の UEBA（行動分析）機能 を活用 ログアナリティクスでKQLを関数 化し、Sentinel の「異常ア ラート」を構成 Logic Apps (no-code フ ロー)で各種通知サービスへ連 携 • GitHub監査ログの傾向を学習し、“普段”を理 解するベースラインモデルを構築 • 異常な操作（例：深夜のトークン生成、大量 削除など）を自動検知 • 異常レベルに応じた通知チャネルを使い分け （Teams, Slack, Mail 等） No テンプレート名 説明 1 GitHub Two Factor Auth Disable 二要素認証の無効化イベントを検知するルール、デ フォルトでは 1 日ごとにクエリを実行 2 GitHub Activites from a New Country 新しい国からのアクティビティを検知するルール、デフォ ルトでは過去 7 日分を学習データに利用して 1 日 ごとにクエリを実行 3 Brute Force Attack against GitHub Account GitHub アカウントへのブルートフォース攻撃を検知 するルール、デフォルトでは 1 日ごとにクエリを実行 4 GitHub Signin Burst from Multiple Locations 複数の異なるロケーションからのサインインバーストを 検知するルール、デフォルトでは 1 時間ごとにクエリを 実行 5 TI map IP entity to GitHub_CL TI インジケータに登録した IP アドレスからのアクセス を検知するルール、デフォルトでは 1 時間ごとにクエリ を実行 6 GitHub Security Vulnerability in Repository リポジトリ内にセキュリティ脆弱性が含まれていることを 検知するルール、デフォルトでは 1 時間ごとにクエリを 実行 Microsoft Sentinel の GitHub 固有の脅威に対する分 析ルールのテンプレートの活用 https://github.com/Azure/Azure-Sentinel/tree/master/DataConnectors/GithubFunction#configuration-steps-to-deploy-function-app 

アノマリ検知と運用へのフィードバックループ（2/2） もう一歩踏み込んだ脅威分析を行うには・・・ • リポジトリに対する異常数のクローン操作 • リポジトリの一括削除 • リポジトリをプライベートからパブリックに変更 • リポジトリに対する部外者からのフォーク操作 • GitHub Organization へのユーザ招待およびユーザ追加 • ユーザへのアクセス許可の追加付与 など などなど 

まとめ 

Platform Engineeringの視点で見た意義 それがもたらす３つの価値 民主的なガバナンス インナーソース • 共通ガードレールをGovernance as Codeとしてコード化 • “設定どこ？”がゼロになる • ユーザーがセルフサービスでプラット フォームのガバナンスにコミットできる環 境の整備 • チームや部署間を越えて、コードとナ レッジを共有・活用 • Pull Requestを通じて誰でも改善 提案できる“建設的な透明性” • 「誰かが作ったもの」から「みんなで 育てる資産」へ 3本柱で“信頼と速度”を両立する 継続的監視とフィードバック • いつもと違う“動き”を自動検知して、リ アルタイムに通知・対応 • ログと可視化により、ボトルネックや改 善ポイントが見える化 

まとめ • 開発プラットフォームのガバナンスや設定はコードとしてバージョン管理することで、「い つ/誰が/なぜ/どのように変更したのか」を追跡可能に • インナーソース化することで、Enterprise ownerなどの限られた人だけでなく多くの 人が開発プラットフォームの改善に貢献することができる • Defender for CloudやSentinelとGitHubを連携することで、セキュリティ状況や 不審なアクティビティを継続的に監視 • 異常が発生した場合は、重要度に応じて即時フィードバックされる仕組みにより、安 心して開発プラットフォームの展開と運用が可能に 構成の透明化/継続的なセキュリティ監視により、開発プラットフォームの信頼性を担保する 

THANK YOU ☺