Microsoft Igniteで見えたエンタープライズなAI駆動開発のかたち

Microsoft Ignite 2025 では、GitHub Copilot に関するセッションが複数登場しました。以前のレポートでも一つ取り上げておりまして、そちらもぜひご参照ください。

実はもう一つ、非常に示唆に富んだセッションがありました。

今回はその内容を中心に、AI 駆動開発をエンタープライズでどう適用していくべきかという観点から、特に印象に残ったポイントを紹介します。

私たち自身も現在、複数の実プロジェクトで AI 駆動開発の検証を進めています。PoC レベルの実験ではなく、実際の業務要件や制約の中で「どこまで使えるのか」「どう使うべきなのか」を見極める段階に入っています。そうした中で今回のセッションは、AI を開発プロセスに組み込むための考え方が非常に整理されており、実務に落とし込む際の“地図”としても納得感の高い内容でした。

以下では、そのセッションで提示されていたコンセプトを、私なりの視点も交えながら紹介します。

※なおこちらの投稿は「なんでもCopilot Advent Calendar 2025」の12/9分としてお届けしております。

AI駆動開発における役割の再定義

非常にわかりやすいなと思ったのが、「人間の役割はAIに対して良質なコンテキストと制約をインプットすることになっていく」というものでした。

A. プロダクトオーナー / PM / スクラムマスター / ビジネスアナリスト

• 新しい役割
  • GitHub Copilotのための「初期プロダクトコンテキスト」の基盤を作る
• 具体的なアクション:
  • 要件定義セッションをすべて記録し、AIに取り込める形にする
  • プロジェクト憲章（Project Charter）を作成し、AIと対話しながらブラッシュアップする
  • ペルソナなどの情報を「コンテキスト・ヒープ（Context Heap）」や「メモリバンク」として蓄積していく
• 期待成果
  • 開発が始まる前に「何を作るべきか」という製品の文脈をセットする

B. エクスペリエンス・アーキテクト / デザイナー

• 新しい役割
  • デザインシステムを「制約条件（Constraints）」として定義する
• 具体的なアクション
  • デザインルール（フォント、色、コンポーネントなど）をMarkdown形式で記述し、Copilotが参照できるようにする
  • LLMはテキスト（Markdown）の理解に優れているため、デザイン仕様書をコード化可能なルールとして食わせる
• 期待成果
  • 制約を整備しながら、コンテキストを使って、CopilotにSPA（ReactやAngularなど）のプロトタイプを作成させる

C. テクニカル・アーキテクト

• 新しい役割

  • アーキテクチャ図を用いてAIのコード生成を統制する

• 具体的なアクション

  • Mermaid記法を使ってアーキテクチャ図（C4モデルなど）を描く
  • 企業の標準的な開発パターンやエンタープライズアーキテクチャのルールを蒸留し、制約として設定する

• 期待成果

  • AIを使い単に動くコードを書くのではなく、その企業の「入社5〜10年目のベテラン開発者」のような、作法に則ったコードを書けるようにすること

静的コンテキストと動的コンテキストの融合

役割の変化を支える技術的な仕組みとして、2つのコンテキスト管理が紹介されました。

静的コンテキスト（Memory Bank）:

• 要件、デザイン、アーキテクチャなどをMarkdownファイルとして蓄積し、Copilotに参照させる 。

動的コンテキスト（MCPサーバーの活用）:

• MCP (Model Context Protocol) サーバーを使用し、必要な情報を動的に取得する
• バックエンド開発時にデータベーススキーマを読み込んだり 、JiraやAzure DevOpsからユーザーストーリーを直接取得して実装に反映したりする
• 開発者はIDE（VS Codeなど）を「シングルペイン・オブ・グラス（一元管理画面）」として、そこから動かずとも全ての情報にアクセスし、AIに指示を出せるようになる

AI駆動開発プロセスの成熟度

エンタープライズにおけるAI駆動開発の成功は、そのシステム開発に必要なコンテキストと制約を蓄積できるようなプロセスを構築できるかに掛かっているということで、ここでは４段階で示していました。

「もしチームに新しい開発者を一人追加したとして、その人が自分の開発環境（IDE）から一歩も外に出られず、追加のコンテキスト（背景情報）も一切持っていなかったとしたら、どうなるでしょうか？」とあります。それは確かにその通りです。

各レベルをもう少し見てみましょう。

LEVEL 1: Agentic Code Assistant (エージェンティック・コード・アシスタント)

• 状態
  • GitHub CopilotなどCodingAgentをただ導入しただけの状態
• 特徴
  • 一般的なコードは書けますが、プロジェクト固有の事情は知りません。「エージェントモード」を使うことで自律的にタスクをこなす素地はありますが指示待ちに近い

LEVEL 2: Memory Bank - Project Context (プロジェクト・コンテキスト)

• 状態
  • そのプロジェクトで「何を作ろうとしているのか」を教え込んだ状態
• 特徴
  • セッションで触れられていたように、要件定義の記録、プロジェクト憲章、ペルソナなどをMarkdown形式で「メモリバンク」としてAIに与えます
  • これにより、AIはそのプロジェクトの目的に沿った提案ができるようになります

LEVEL 3: Memory Bank - Enterprise Context (エンタープライズ・コンテキスト)

• 状態
  • その会社特有の「開発ルール」や「技術標準」を教え込んだ状態
• 特徴
  • 企業のアーキテクチャ標準、セキュリティ基準、コーディング規約などを「制約（Constraints）」として与えます 。これにより、AIは汎用的なコードではなく、「入社5〜10年目のベテラン社員」のように、会社の流儀に則ったコードを書くようになります

LEVEL 4: Integrations via MCP Servers (MCPサーバーによる統合)

• 状態
  • AIが外部システムと繋がり、リアルタイムに情報をやり取りできる最終形態
• 特徴
  • MCP（Model Context Protocol）サーバーを介して、Jiraのチケットを読んだり、Confluenceの最新仕様を確認したり、データベースのスキーマを直接参照してコードを書いたりします
  • 開発者はVS Codeを一歩も出ることなく、すべての外部ツールと連携して開発を進めることができます

さいごに

弊社も含め、AI駆動開発を組織的に進めるために試行錯誤されている多くの方々にとって参考になればと思いご紹介しました。実際コンテキストの重要性などは多くの資料や講演などで語られていることが多い内容ではありますが、全体像として体系化されていて私は非常にわかりやすく腹に落とすことができました。

不確実性の高いビジネス要件に適応しながら、既存現場の生産性や効率を高めつつ開発者体験を上げることは、我々システム開発に携わる者にとって長年の悲願でした。

一方でエンタープライズなシステム開発の現場には、AI駆動開発をフルに活かすためのハードルがままだ多くあると感じます。より多くの開発現場で新しい技術の価値を享受できるように、成功事例を積み重ねながら仲間とともに研鑽を続けたいと思います。

そして次世代のエンジニアを育成できる土台になっていくことをあわせて実現できるような、そんな仕組みと仕掛けを引き続き模索していきたいと思います。

宣伝

ARIでは仲間を絶賛募集しております。カジュアル面談、随時受付中です。
採用サイトはこちら。お気軽にお問い合わせください。