プロンプトエンジニアリングを超えて：自由と統制のあいだでつくる Platform × Context Engineering

DevOpsDays Tokyo2026で発表させていただいた内容です

Transcript

1. プロンプトエンジニアリングを越えて： 自由と統制のあいだでつくる Platform × Context Engineering 2026/4/14 Yurie Mori 1
2. Introduction 2
3. Agenda AI × ソフトウェア開発の近現代史 Prompt Engineering から Context Engineering へ AIとのコラボレーションを前提とした Platform づくり AI に対する Paved Path と Guardrailをプラットフォームに実装する GitHub EnterpriseにおけるAIに対するPaved PathとGuardrailのアーキテクチャ MicrosoftにおけるAgentic AIのSDLCへの適用 まとめ 3
4. Yurie Mori（森 友梨映） Software Solution Engineer at Microsoft Japan Interests DevOps DevSecOps Platform Engineering Developer Experience / Productivity Awards Microsoft MVP for DevOps & Cloud Security 2025 Microsoft MVP for DevOps 2024 *All Opinions Are Own 4
5. Please follow me X（旧Twitter）とLinkedInで発信しています。ぜひフォローしてください！ 5
6. AI × ソフトウェア開発の近現代史 6
7. 生成AIを活用したソフトウェア開発、実際のところはどう変 わった？ 7
8. DORA Report 2024: AIを導入するとスループットと安定性は低下 出典: DORA: State of DevOps 2024 8
9. DORA Report 2025: スループットは向上、しかし依然として安定性は 低下 出典: DORA: State of AI Assisted Software Development 2025 9
10. 2024 → 2025 の総評 ポジティブ スループット向上 チームパフォーマンス、コード品質の向上 Valuable Work の増加 ネガティブ デリバリー安定性は依然として低下 個人負荷の増大（Burnout） ドキュメント不足・不安定なインフラによる摩擦 10
11. コードの品質は向上したのに安定性は低下？ コードの品質 可読性 一貫性 規約遵守 デリバリーの安定性 障害やインシデントの少なさ Rework の少なさ コードの正しさと美しさはリリース後の安定性を保証しない スピーディに生成されるコード量に、運用と統制が追いついていない → Guardrail とプロセス整備が不足 11
12. プラットフォームやプロセスの課題 チームに内在するシステムがAIを活用した 開発を安全に、適切に適合するためにまだ 進化しきっていない 出典: DORA: State of AI Assisted Software Development 2025 12
13. AI導入を成功させるために必要な能力 出典: DORA: State of AI Assisted Software Development 2025 13
14. Prompt Engineering から Context Engineering へ 14
15. Developer Platform→Multi Agent Platform 15
16. Developer Platform の進化 AIが設計を手伝う Agent がコードを書く AIがコードレビュー AIがセキュリティチェック・修正 リポジトリ横断でデータ探索 16
17. Prompt Engineering モデルのパラメータを変更することなく、タスク固有の指示（プロンプト）を設計する ことで、LLMやVLMから望ましい出力を引き出す 17
18. Context Engineering AIシステムの周辺に包括的な情報環境を設計 出力を生成する前にAIエージェントがすべての関連する背景知識、メモリ、ツール にアクセスできるようにし、拡張ワークフロー全体を通じて情報を動的に管理 18
19. AIとのコラボレーションを最大化するためのデータの整理、 それに対するガバナンスがプラットフォームとプロセスで必 要 19
20. AIとのコラボレーションを前提とした Platform づく り 20
21. Platform Engineering × Context Engineering Platform Engineering 開発者（人）をユーザーと捉えたPaved PathとGuardrailの整備 Context Engineering AIをユーザーと捉えたPaved PathとGuardrailの整備 21
22. Platform Engineering × Context Engineering AI導入によってソフトウェアデリバリーのスループットは向上するが安定性は低下 する それはチームに内在するシステムがAIを活用した開発を安全に、適切に運用するた めにまだ進化しきっていないため AIに対するGuardrailの整備が未発達であることを意味する 22
23. プラットフォームにおける自由と統制 Paved Path: 開発者がセルフサービスで開発に必要な環境やツールを入手すること ができる Guardrail: そしてそれを安全に使用することができる 過剰な統制（ネットワークでガチガチに制限するなど）はプラットフォーム自体の 機能不全やシャドーAIや認可していないツールなどのセキュリティリスクが発生す る 過剰な自由はツールや環境の乱立などのカオスやデータ漏洩や不正アクセスに繋が る AIの場合も同様 23
24. AI に対する Paved Path と Guardrailをプラットフォ ームに実装する 24
25. AIに必要な Paved Path / Guardrailの条件 Paved Path 必要な時に必要なデータにアクセスすることができる そのデータは最新である そのデータはAIにとって readableである Guardrail 認可したデータのみにアクセスすることができる 誰がどのAIをどの程度使用するかを制御することができる AIの行動は監査可能である 25
26. AIにとって必要なデータをUser Story Mappingで探索する 26
27. Paved Path の設計 27
28. Guardrail設計のための脅威モデリング 28
29. AIが失敗しやすいリスク要因 リスク 具体例 どうなるか 見てはいけないデータを見る/ してはいけない行動をする ・機密データへのアクセス ・外部ネットワークへのアクセス ・実際は治っていない修正を適用 する ・コンプライアンス違反 ・データの漏洩 見ても意味がないデータを見る ・最新でないドキュメント ・AIにとって可読性が悪いデータ をコンテキストとして渡す ・出力精度の低下 プロセスを意識しない、必要な チェックなしの素通り ・すべての環境にバケツリレーさ せるCI/CDの生成 ・テストなしでデプロイ ・リリース後の障害の発生、差戻し作業 の発生（=デリバリの安定性の低下） セキュリティ脆弱性の内在 ・シークレットやセキュリティ的 な脆弱性のあるコードの生成 ・セキュリティインシデントの発生 ・機密データの漏洩 29
30. AIに適用すべき Guardrail Guardrail 統制内容 実装例 Context Guardrail AIに何を読ませるべきか、読ませ ないべきか ・Everything as CodeによってAIの参照範囲内に 参照できるデータ形式でデータを置く ・MCPサーバーを介したナレッジベースやファイ ルシステムへのアクセス ・MCPサーバーの連携先には、最新のデータがAI にとって読める形式で管理されている Action Guardrail AIに何をさせてよいのか 何かをさせるときはどのような 縛りを与えるのか ・AIが外部ネットワークにアクセスする際のファ イアーウォールの設定やアクセス許可リスト ・Instruction.mdやAgent.mdによるアクション の際のルール定義、コーディングルールやガイド ラインを参照させる Process Guardrail どこで人間が責任をもつべきか ・デプロイ時の人間による承認チェックの設定 ・CODEOWNERの指定 Security/Compliance Guardrail AIやAIの行動、生み出す生成物へ のセキュリティチェック、コンプ ライアンス準拠チェック ・AIに対する監査の有効化 ・DevSecOps ・Policy as Code 30
31. GitHub EnterpriseにおけるAIに対するPaved Path とGuardrailのアーキテクチャ 31
32. GitHub CopilotへのPaved Pathの整備（1/2） 機能 概要 ファイル 設定場所 Custom instructions 常時オンのコンテキスト copilot- instructions.md *.instructions.md AGENTS.md .github/ （リポジトリ全体） .github/instructions/ （パス指定） GitHub上の個人/Org設定 Prompt files 再利用可能なプロンプト テンプレート *.prompt.md .github/prompts/ Custom agents 独自の指示・ツール制限 を持つ専門エージェント AGENT-NAME.md .github/agents/ （リポジトリ） .github-private （Org/Enterprise） ユーザープロファイル Subagents オーケストレーターから 委譲作業を行う別エージ ェント AGENT-NAME.md 親エージェントの agent.md 内の agents パラメーターで指定 32
33. GitHub Copilotへのコンテキスト付与でPaved Pathを整備（2/2） 機能 概要 ファイル 設定場所 Agent skills タスクに応じてCopilotが読み込む指示・ リソース SKILL.md .github/skills/<name>/ .claude/skills/<name>/ .agents/skills/<name>/ （プロジェク ト） ~/ 配下の同構成（個人） Hooks ワークフロー内で確定的に実行されるシェ ルコマンド *.json .github/hooks/ MCP servers 外部システム・API・DBへの接続 mcp.json IDE設定（パスはIDEにより異なる） GitHubリポジトリ設定 エージェント設定内 mcp-servers 33
34. 実装例 34
35. Tips:　コンテキスト付与とコンテキストウィンドウ コンテキストウィンドウ＝モデルが一度に処理できるトークン 数の上限 多すぎ → 重要情報が埋もれる（Lost in the Middle） 少なすぎ → 的外れな出力 質の高いコンテキストを適切な粒度で渡す設計が鍵 Instructions / Skills / Prompt files の使い分けで、必要なタイ ミングに必要な情報だけを渡す 35
36. コンテキストの汎用化と展開 agent.mdやSKILL.mdをいい感じに書けるか（適切にコンテキストを整備できる か）はjuniorとseniorで大きな差となりやすい それが成果物の品質に左右する そのため、コンテキストを汎用化、展開するためのインナーソース的な取り組みも 重要 36
37. Custom agentをエンタープライズ全体で展開 .github-privateリポジトリでエンタープライズ全体に展開させたいCustom agentをagent.mdとして定義 GitHub Enterprise > AI Controlsで上記のリポジトリを含むOrganizationを選択することで、エンタープライズ 全体でCustom agentを配布可能 EnterpriseレベルのCustom agentはルールセットにより保護され、Enterprise ownerしか編集できないように なる 37
38. GitHub Copilotを使用するための開発環境の展開 Copilot CLIや3rd party agentなどのツールを使用するためには拡張機能のインス トールやVSCodeの設定が必要 必要な設定をDevcontainer.jsonで定義することにより、個人のIDE設定に依存しな いCopilot-use-readyな環境を展開することが可能 38
39. リポジトリのテンプレート化によるコンテキストの テンプレート化 GitHubではリポジトリをテンプレートして設定する機能がある MCP serverの設定やhook, SKILL.mdなどのファイルを含むリポジトリをテンプレ ートにすることで、プロジェクトごとに必要なコンテキストをテンプレート化して 展開することが可能 Repository > Settingsで設定可能 39
40. 各レイヤーでのガバナンス Enterprise AI Controlsでアクセス、使用可能な機能を一元管理 Suggestions matching public codeはBlockにする。意図しないIP侵害を回避。 AIエージェントの作業内容は監査ログに蓄積される。監査ログの内容をストリームしてログを解析することで、AIエージェントの行動を 監視することが可能 MCP Server Registryの制限：使用していいMCPサーバーのレジストリを許可リストで管理。野良MCPサーバーを使用できないように。 Content exclusion: AIに参照させてはいけないファイルの指定 GitHub Advanced Securityによるセキュリティチェックの強制 Organization エージェントに対するFirewallの有効化、アクセスしてよいドメインのリスト エージェントが使用してよいRunnerの制限 Custom instructions: Organization全体で適用される指示。 （ブラウザ上のGitHub Copilotの機能のみがスコープとなる） Content exclusion: AIに参照させてはいけないファイルの指定 Repository Content exclusion: AIに参照させてはいけないファイルの指定 エージェントに対するFirewallの有効化、アクセスしてよいドメインのリスト 40
41. AIエージェントに対するセキュリティチェック GitHubのagentは自らが行った作業に対し、自らセキュリティチェックを実行する ことができる。 これらのセキュリティチェックはonにして運用することを強く推奨。 また、AIエージェントだけでなく一般ユーザーに対してもAdvanced Securityによ るセキュリティチェックが適用されるように。 41
42. GitHub EnterpriseにおけるGuardrailの実装例 Guardrail 統制内容 GitHub Enterprise での実装 Context Guardrail AIに何を読ませるか／読ま せないか ・Content exclusion（Enterprise/Org/Repo各レベル）で参照禁止ファイルを指定 ・MCP Server Registry の許可リストで接続先を制限し、野良MCPサーバーを排除 ・ copilot-instructions.md / *.instructions.md で参照すべきドキュメントを明示 ・Suggestions matching public code を Block に設定し、パブリックコード混入を防止 Action Guardrail AIに何をさせてよいか／ど う縛るか ・Agent Firewall（Org/Repo）でアクセス可能なドメインを許可リストで管理 ・Runner の制限（Org）でエージェントが使用できる実行環境を制御 ・ agent.md / *.instructions.md でコーディングルール・行動規約を定義 ・AI Controls で使用可能な機能・モデルを Enterprise レベルで一元管理 Process Guardrail どこで人間が責任を持つか ・CODEOWNERS による PR レビュー必須化 ・Branch protection / Ruleset によるデプロイ承認フローの強制 ・Hooks（ .github/hooks/*.json ）でエージェントワークフロー内に確定的チェックを挿 入 Security/Compliance Guardrail セキュリティ・コンプライ アンス準拠 ・GitHub Advanced Security（Code scanning / Secret scanning / Dependabot）の有効化 によるDevSecOpsの適用 ・エージェント自身によるセキュリティセルフチェックの ON 運用 ・監査ログ（Audit log streaming）によるAIエージェント行動の記録・監視 ・Custom agent のルールセット保護（Enterprise ownerなど特定メンバーのみ編集可） 42
43. MicrosoftにおけるAgentic AIのSDLCへの適用 43
44. MicrosoftにおけるAgentic DevOpsの世界観 Microsoftのコードベースは多様：数か月〜数十年単位のコード、様々な言語・ア ーキテクチャが混在 DevOpsの各フェーズでエージェントを活用 開発者同士 → 開発者とエージェント → エージェント同士のコラボレーション へ 開発者はエージェントの「ボス」 ワークフローの調整、意図のガイダンス、意思決定の監督 プロダクトのビジョン策定、技術的負債の解消をオーケストレート 目指すのは、SDLCのE2EでInner loopからOuter loopまで、同期・非同期でAgent と協業できること 出典: Inside Microsoft's AI transformation across the software lifecycle 44
45. Platform Engineeringの理念：Start Right, Stay Right Start Right：ベストプラクティスから始める 中央集権的に管理されたPipelineテンプレート ホストプール上で動作する安全なCI/CD基盤 Codespacesによる一貫した開発環境の配布 Stay Right：正しくあり続ける ポリシーのベストプラクティスを強制 セキュリティの継続的な監視 Enterpriseレイヤーでの統制の一元管理 迅速で安全、規制要件を満たし、拡張性があり、開発者がイノベーションを起こす 「余白」を確保するPaved Road 出典: Inside Microsoft's AI transformation across the software lifecycle 45
46. Agentic AIのDevOpsへの適用事例 領域 適用内容 開発支援 ES Chat：エンジニアリングのベストプラクティスやナレッジを持つ社内エージェント。VSCode / Teams / Copilotから呼び出し可能 コーディング GitHub Copilot Coding Agent：コード生成・修正の自動化 コードレビュ ー GitHub Copilot Code Review：SDLC上の摩擦（不安定なテスト、長いビルド等）を軽減 インシデント 対応 Azure SRE Agent：インシデントの自動調査・修正。7,000件以上のインシデントを自動対応 セキュリティ Copilot Autofix + Coding Agent：脆弱性の検知から修正までを自動化 出典: Inside Microsoft's AI transformation across the software lifecycle 46
47. 課題とAI Agentとのコラボレーションに関する学び AIに「正しく」振る舞ってもらうために多くの労力を払った ドキュメントの再編、大量のプロンプト作成 それでも期待通りにならなかった 転機：M365 Copilotに「どうやったらちゃんとやってくれるのか」と聞いた 答え： 「自動化のツールとしてではなくチームメイトとして扱え」 プロンプトのアプローチを変えたら振る舞いが大幅に改善 技術がすべてを変えるのではない、関係性がすべてを変える 出典: Inside Microsoft's AI transformation across the software lifecycle 47
48. Agentとの関係性：ツールからパートナーへ ツールとして扱う 命令を出す → 結果を受け取る 期待通りでなければプロンプトを修正する繰り返し パートナーとして扱う コンテキストを共有し、意図をガイドする タスクを適切に分業し、サブエージェントに委譲する 結果を監督し、フィードバックを返す Agentを「パートナー」 「コラボレーター」として扱うことで、アウトプットの質が 変わる 出典: Inside Microsoft's AI transformation across the software lifecycle 48
49. まとめ 49
50. まとめ 1. Paved Path + Guardrail をプラットフォームに実装する AIエージェントの安全で効果的な運用の土台 2. DevSecOpsはもはやOptionalではない AIの行動・生成物へのセキュリティ／コンプライアンスチェック 3. コンテキストを組織の資産として管理する 属人化防止のインナーソース、専任ロールの設置 50
51. THANK YOU 😊 Yurie Mori X: @1115_lilium