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

2026/01/10のBurikaigi2026でお話しさせていただいた内容です。

1. プロンプトエンジニアリングを 越えて： 自由と統制のあいだでつくる Platform × Context Engineering 2026/1/10 Yurie Mori
2. INTRODUCTION
3. 今日話すこと • Agentとコラボレーションするためのプラットフォームづくり • Context Engineering × Platform Engineering • AIに対するPaved PathとGuardrailの提供
4. AGENDA AI×ソフトウェア開発の近現代史 Prompt EngineeringからContext Engineeringへ AIとのコラボレーションを前提としたPlatformづくり AIに対するPaved PathとGuardrail
5. Who Am I? Yurie Mori (森 友梨映) Microsoft Japan Cloud & AI Platform, Software Solution Engineer Carrer ◆ Microsoft Japan Software Solution Engineer ◆ Avanade Japan DevOps Engineer/Architect ◆ Plus Alpha Consulting Web Application Engineer Technology stack ◆ DevOps ◆ DevSecOps ◆ Platform Engineering ◆ Developer Experience/Productivity SNS Awards ◆ Microsoft MVP for DevOps & Cloud Security 2025 ◆ Microsoft MVP for DevOps 2024
6. AI×ソフトウェア開発の近現代史
8. 生成AIを活用したソフトウェア開発、 実際のところはどう変わった？
9. DORA Report 2024: AIを導入するとスループットと安定性は低下 出典: https://cloud.google.com/devops/state-of-devops?hl=ja&region=JP DORA(DevOps Research and Assessment)のState of DevOps2024のレポートでは、AI導入が25%増えること で、デリバリーのスループットと安定性の両方が若干低下する可能性があると示されている。 スループットが-1.5% デリバリー安定性が-7.2%
10. スループットと安定性の定義 • スループット： • リードタイム、デプロイ頻度、失敗したデプロイの復旧時間 • 変更をどれだけ速く・頻繁に・（失敗しても）流せるか • 安定性： • 変更障害率（デプロイ後に即時対応（ロールバック／hotfix）が必要になる 割合）、Rework（本番事故をきっかけに発生する想定外の再作業）が少 ないこと • どれだけ“想定外の介入を発生させずにプロセスを流すか”
11. DORA Report 2025: スループットは向上、しかし依然として安定性は低下 出典:https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf スループット、コード品質、価値ある 仕事の割合は増加
12. DORA Report 2025: スループットは向上、しかし依然として安定性は低下 出典:https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf １年後のState of AI Assisted Software Development 2025のレポートでは、スループットは向上したが、安定性の 低下が依然として観測される デリバリの不安定性の向上 燃え尽き症候群の増加
13. 2024→2025の変化の総評 スループットが向上、AIの導入によりソフトウェア開発の プロセスのフローを流す力は向上 チームパフォーマンス、コード品質も向上 Valuable Work（価値ある仕事の割合）の向上： 単純作業や反復作業からの解放 デリバリーの安定性は依然として低下。本番リリース後 の障害発生率やReworkの割合は向上 燃え尽き症候群のUp:個人にかかる負担の増大 反復作業が少なくなっても、それだけでは摩擦はなくな らない（不十分なドキュメントや不安定なインフラ）
14. コードの品質は向上してるのに安定性は低下？ 出典:https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf
15. コードの品質は向上してるのにデリバリの安定性 が低下しているのは矛盾では？ • コードの品質（＝きれいで正しいコード） • 可読性 • 一貫性 • 規約遵守 • デリバリの安定性（想定外の変更の少なさ） • 最終的にリリースしたあと障害やインシデントの発生が少ないこと • 上記によるhotfixや修正のためのreworkの割合が少ないこと • コードの正しさや美しさは「リリース後の安定性」を保障しない • きれいで正しいコードをスピーディーに流せることができるようになったが、「スピーディーに生成され る膨大なコードを扱うこと」が追いついていない • →ガードレールやプロセスの整備が追い付いていない
16. プラットフォームやプロセスの課題 • AIの導入により、正しくきれいなコー ドを速く流すことができるようになった • しかし、ソフトウェアの安定性は低下 • これはチームに内在するシステムが AIを活用した開発を安全に、適切 に適合するためにまだ進化しきって いない 出典:https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf
17. AIの導入を成功させるために必要な能力 出典:https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf
18. AIとのコラボレーションを向上させるために必要な進化 とは？ • AIとのコラボレーションを前提としたプラットフォームやプロセスづくり • AIが組織内部のデータにアクセス可能で、読むことができる質のよいデー タエコシステムがある • 追跡性を担保する強力なバージョン管理、質のいいIDP（Internal Developer Platform)
19. Prompt Engineeringから Context Engineeringへ
20. Developer Platformの進化 Internal Developer Platform リポジトリ CI/CD Wiki テスト/セキュリティスキャン Internal Developer Platform リポジトリ CI/CD Wiki テスト/セキュリティスキャン
21. Developer Platformの進化 • AIが設計を手伝い • Coding Agentがコードを書き • AIがコードレビューをして • AIがセキュリティチェックをして • AIが修正をして • AIがリポジトリや、リポジトリを越えてプラットフォームのデータを探索する
22. Prompt Engineering モデルのパラメータを変更することなく、タスク固有の指示（プロンプト）を設計することで、LLMから望ましい出力 を引き出す 再現困難性 最適なプロンプトの再現性が 困難 自然言語での指示 属人化しやすい プロンプト設計スキルにより 性能が左右される 汎用化の困難 すべてのドメインに適用できる 普遍的なプロンプトテンプレー トが存在しない 出力の返却
23. Context Engineering AIシステムの周辺に包括的な情報環境を設計することに焦点を当てて、出力を生成する前ににAIエージェントが すべての関連する背景知識、メモリ、ツールにアクセスできるようにし、拡張ワークフロー全体を通じて情報を動的に 管理 自然言語での指示 出力の返却 コードベース 最新のドキュメント セキュリティポリシー コーディングガイドライン 製品 ドキュメ ント 社内 データ ソース テスト ツール
24. AIとのコラボレーションを最大化するため のデータの整理、それに対するガバナン スがプラットフォームとプロセスで必要
25. AIとのコラボレーションを前提とした Platformづくり
26. Platform Engineering × Context Engineering • 開発者（人）をユーザーと捉えたPaved PathとGuardrailの 整備 Platform Engineering • AIをユーザーと捉えたPaved PathとGuardrailの整備 Context Engineering
27. Platform Engineering × Context Engineering • AI導入によってソフトウェアデリバリーのスループットは向上するが安定性 は低下する • →これはチームに内在するシステムがAIを活用した開発を安全に、適 切に運用するためにまだ進化しきっていない • →AIに対するGuardrailの整備が未発達であることを意味するので は？
28. プラットフォームにおける自由と統制 • Paved Path: 開発者がセルフサービスで開発に必要な環境やツール を入手することができる • Guardrail: そしてそれを安全に使用することができる • 過剰な統制（ネットワークでガチガチに制限するなど）はプラットフォーム 自体の機能不全やシャドーAIや認可していないツールなどのセキュリティ リスクが発生する • 過剰な自由はツールや環境の乱立などのカオスやデータ漏洩や不正ア クセスに繋がる • →AIの場合も同様
29. AIに対するPaved Pathと Guardrail
30. AIに必要なPaved PathとGuardrail • Paved Path: • 必要な時に必要なデータにアクセスすることができる • そのデータは最新の状態である • そのデータはAIにとってreadableである • Guardrail: • 認可したデータのみにアクセスすることができる • 誰がどのAIをどの程度使用するかを制御することができる • AIの行動は監査可能である
31. AIにとって必要なデータ Plan Develop Deliver Operate どんなものを作るかを考える 作るために必要なものを整理す る 要件、非機能要件、ビジネス要 件の Fixやドキュメンテーションの 支援 ものが動くための基盤を構築する （インフラの整備） ものを作る 作られているものが適切か判断 する 作ったものが出荷可能な状態に なっているか確かめる 本番相当の環境でちゃんと動くか 確かめる サービスがちゃんと動いているかわ かるようにしておく サービスがちゃんと動いているか確 認する 困っているユーザをサポート 不具合調査＆修正 Process 人がやること AIがやること AIが参照するであろう データ IaC, devcontainer.jsonの記述 による開発環境構築支援 App/Infra設計 テスト、セキュリティスキャン CI/CDのyamlの生成 テスト、セキュリティスキャン 実行リソース＆セキュリティ状況 監視 インシデント調査・分析・修正 機能要件、非機能要件、 ビジネス要件 UIデザイン コードベース、コーディングルー ル、ガイドライン Planフェーズで生まれたドキュメ ント リリース要件、リリースプロセス コードベース コードベース インストルメンテーションデータ （ログなど） 開発ができるようにする（開発 基盤を整える）
32. Paved pathの設計 Plan Develop Deliver Operate Process AIが参照するであろう データ UIデザイン コードベース、 コーディングルールやガイドライ ン Planフェーズで生まれたドキュメ ント リリース要件、リリースプロセス コードベース コードベース インストルメンテーションデータ （ログなど） これらのデータがAIにとって最新の状態で、かつ読めるような状態でアクセスできるようにする必要がある How? 機能要件、非機能要件、 ビジネス要件 • カスタムインストラク ションによるAIに順 守させる指示の設 定 (instruction.md, agent.md, skills.md) • Design as Code • MCPサーバー • クラウド環境と Developer platformの連携 • MCPサーバー
33. AIに対するGuardrailを考える脅威モデリング Plan Develop Deliver Operate Process AIが参照するであろう データ UIデザイン コードベース、 コーディングルールやガイドライ ン Planフェーズで生まれたドキュメ ント リリース要件、リリースプロセス コードベース コードベース インストルメンテーションデータ （ログなど） 機能要件、非機能要件、 ビジネス要件 発生しそうなリスク • テストがないけどそれっ ぽく動くのでマージされ る • センシティブな認証認 可基盤のコード生成 • ガイドライン違反のコー ドがマージされる • セキュリティ的にマージ されてはいけないコード がマージされる（AIに よるセキュリティセンシ ティブなコードの生成は 意外とある） • 古い設計やドキュメント を読んでしまう • 適切にドキュメントをAI が読めてなくて精度が 低い • UIデザインと要件が食 い違っているのに気づけ ない（参照データ間の 整合性の不一致） • AIがアクセスしてはいけ ないデータソースにアク セスしてしまう • すべての環境にチェック なしで全部自動デプロ イ（特に支持しなかっ たらAIは全環境自動 デプロイCI/CD書きが ち） • 環境デプロイ前のチェッ クやテストの考慮不足 • アクセスしてるログが最 新でない • 別の環境のインストル メンテーションデータを 見に行く • AIが提案した修正が 実は間違ってる • 運用ドキュメント書いて くれるけど参照してる情 報が古くて意味がない ドキュメントが生まれる
34. AIの失敗しやすさを誘発するリスク要因の分類 リスク 具体例 どうなるか 見てはいけないデータを見る、してはい けない行動をする • 機密データへのアクセス • 外部ネットワークへのアクセス • 実際は治っていない修正を 適用する • コンプライアンス違反 • データの漏洩 見ても意味がないデータを見る • 最新でないドキュメント • AIにとって可読性が悪いデー タをコンテキストとして渡す • 出力精度の低下 プロセスを意識しない、必要なチェック なしの素通り • すべての環境にバケツリレーさ せるCI/CDの生成 • テストなしでデプロイ • リリース後の障害の発生、差戻し 作業の発生（＝デリバリの安定 性の低下） セキュリティ脆弱性の内在 • シークレットやセキュリティ的な 脆弱性のあるコードの生成 • セキュリティインシデントの発生 • 機密データの漏洩
35. 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
36. GitHub Enterpriseの場合 Enterprise layer Organization layer Repository layer ①AI Controls ②Models ④Custom instruction ③Content exclusion ⑦Ruleset Content exclusion ⑨MCP Server ⑪Internet access ⑤Agent.md ⑥Agent.md ⑩Skills.md ⑧Instruction.md ①Copilotの集中制御を行う。監査ログ、Aアクセスさせ ないデータの指定、使用可能なLLMやMSPサーバーの 指定、使用可能な機能の制御 ②Organization内で使用可能なLLMの制御 ③Copilotに参照させないOrganization内のデータの 指定 ④Organization全体で適用されるCopilotに対する 指示。（Copilot in GitHub.com, Copilot code review, Coding Agentに適用される） ⑤Organization全体で利用可能なカスタムAIエー ジェント ⑥Repos内で利用可能なカスタムAIエージェント ⑦Copilotの行動に対する制限（どのブランチに何をさ せていいのか、何を禁じるか） ⑧Copilotが出力生成の際に参照する指示、参照すべ きルールやガイドラインの指定 ⑩特定の作業を実行する際に参照するナレッジやルー ルの指定 ⑨Copilotが使用するMCPサーバーの指定 ⑪Coding Agentがインターネットにアクセスする際の Firewall設定、アクセスしていいドメインリストの指定
37. まとめ • AI導入による安定性の低下は、AIの性能問題ではなく「プラットフォーム /プロセス設計の問題」 →AIが 何を見て・何をしてよいかが定義されていないことが原因 • これからの開発現場は、人間 × AIエージェントの協業が前提 →人間だけでなく、AIにも Paved Path と Guardrail が必要 • Context Engineering × Platform Engineering がその解決策 →AIが参照するデータ、実行できるアクション、判断ポイントを プラットフォームとプロセスに組み込む • GuardrailはAIを縛るためのものではない →人間とAIが、安全に・安定してコラボレーションするための前提条件
38. まとめ
39. • State of DevOps2024 • https://cloud.google.com/devops/state-of-devops?hl=ja&region=JP • State of AI Assisted Development • https://services.google.com/fh/files/misc/2025_state_of_ai_assisted_software_development.pdf • AI Capability Model • https://services.google.com/fh/files/misc/2025_dora_ai_capabilities_model.pdf • A Systematic Survey of Prompt Engineering in Large Language Models: Techniques and Applications • https://arxiv.org/abs/2402.07927 • Beyond Prompt Engineering: Understanding the Rise of Context Engineering • https://medium.com/devops-ai/beyond-prompt-engineering-understanding-the-rise-of-context-engineering-96686adf2a39 References
40. Appendix:年表の諸元
41. 2020s’~：生成AIの台頭 • 2021 • GitHub Copilot preview開始 • https://github.blog/news-insights/product-news/introducing-github-copilot-ai-pair-programmer/ • 2022 • Azure Open AI Service発表 • https://news.microsoft.com/ja-jp/2023/01/23/230123-general-availability-of-azure-openai-service-expands-access-to-large- advanced-ai-models-with-added-enterprise-benefits/ • GitHub Copilot GA • https://github.blog/news-insights/product-news/github-copilot-is-generally-available-to-all-developers/ • ChatGPTリリース • https://metaversesouken.com/ai/chatgpt/from-when/#GPT-35ChatGPT202211 • 2023 • Azure Open AI Service、GA • https://news.microsoft.com/ja-jp/2023/01/23/230123-general-availability-of-azure-openai-service-expands-access-to-large- advanced-ai-models-with-added-enterprise-benefits/ • Copilot Workspace, Copilot Autofix発表 • https://github.blog/news-insights/product-news/universe-2023-copilot-transforms-github-into-the-ai-powered-developer- platform/