MCP サーバーとエージェントを使用して開発者のオンボードを高速化する

スタートアップ クレジットを引き換え、テナントのセットアップを完了した後、多くのスタートアップ チームは、Azure ポータルを深く学習することから始めなくなります。 より一般的な出発点は、開発者が既に希望するターミナルまたはエディターに留まり、そのワークフローをAzureに安全に接続できる AI 支援開発ワークフローを構成することです。 この記事は、GitHub Copilot CLI または Claude Code を使用して、スタートアップがアカウントのセットアップからAzureでのエージェント駆動開発に移行するのに役立ちます。 また、CLI ベースの開発者ワークフローを使用して開発者をサポートするための関連する MCP サーバーとツールについても説明します。

Prerequisites

開始する前に、次の点を確認してください。

  • Microsoft for Startups のスタートアップ クレジットを引き換え済みであること。
  • Azure スポンサー プラン サブスクリプションをアクティブ化しました。
  • 引き換え後Azureアカウントのセットアップを完了しました。
  • 環境が 1 人のユーザーに関連付けられないように、会社が支援するMicrosoft Entra テナント、カスタム ドメイン、および管理者のアクセス許可を構成しました。
  • GitHub特典を利用しました。 詳細については、「GitHub、AKS、AI モデルにスタートアップ クレジットを使用する方法」を参照してください。

Tip

クレジットを引き換えたらすぐに、Azure テナントを構成してください。 ユーザーと管理者を追加し、企業ドメインを構成し、スタートアップ クレジットのMicrosoftがアクティブであることを確認します。 詳細については、「Azure アカウントを設定する」を参照してください。

開発環境を設定する

エージェント、MCP サーバー、または Azure アクセスを構成する前に、チームがローカルで一貫した作業方法を提供するベースライン開発環境を設定します。 目標は、すべてのスタートアップを 1 つの正確なツールチェーンに強制するのではなく、開発者が認証し、必要な CLI ツールをインストールし、目の前のタスクに適した作業モードを選択できるようにすることです。

適切な対話モードを選択する: VS Code での CLI とエージェント モード

AI 支援開発は、ターミナル、エディター、またはGitHubホスト環境で発生する可能性があります。 最適な選択はタスクによって異なります。

対話モード 次の場合に使用します。 予期される事柄
GITHUB COPILOT CLI ターミナルで直接制御する必要があります。 アシスタントは、リポジトリの探索、セットアップ タスクの実行、コードの質問への回答、MCP を利用したツールの使用と、目に見える承認手順を支援します。
エージェント モードでの GitHub Copilot Chat エディターでコードを積極的に変更しています。 アシスタントを使用すると、プロジェクトコンテキストを維持しながら、コードの計画、レビュー、編集、および調整を行うことができます。
GitHubホスト型コーディング エージェント タスクは大きく、独立して実行でき、プル要求として戻ってくる必要があります。 エージェントはリポジトリを調査し、計画を作成し、ブランチに変更を加え、レビューのための pull request を開きます。

プロンプトの例

これらの例を開始点として使用し、リポジトリと承認モデルに合わせて調整します。

GitHub Copilot CLI: Azureセットアップを検証する

Review this repository and explain how to run it locally.
Do not edit any files yet.

Then, using azure-mcp tools, verify that:
- Resource groups and deployed resources match the expected naming convention.
- RBAC is scoped correctly, with no broad Owner assignments.
- Diagnostics and monitoring are enabled for key resources.

Summarize findings and gaps as pull request comments.

エージェント モードでの GitHub Copilot Chat: インフラストラクチャと CI/CD を実装する

Create an initial IaC and CI workflow.

Add:
- An infra folder with a Bicep or Terraform structure.
- A GitHub Actions workflow that validates infrastructure and runs tests.
- A rollback note in the pull request template.

Use minimal viable defaults and keep the structure modular for later expansion.

GitHubホスト型コーディング エージェント: pull request を計画して開く

Create an implementation plan for the feature described in docs/feature-spec.md.

If the plan looks safe:
- Make the changes on a new branch.
- Add or update tests.
- Update documentation.
- Open a pull request with a summary and testing steps.

ほとんどのスタートアップ チームでは、最も単純な安全なワークフローから始めます。

  1. Copilot CLI を使用して、AzureとGitHubセットアップを確認します。
  2. VS Code で対話型の変更を行うには、エージェント モードでCopilot Chatを使用します。
  3. より大きなプル要求指向の作業には、GitHubホスト型コーディング エージェントを使用します。
  4. MCP サーバーを追加するのは、各ツールに必要なアクセス許可、承認モデル、ログを定義した後だけです。

エージェントと IDE 用のツールを設定する

オンボード ツールは、コーディング エージェントと IDE を適切なコンテキストと機能に接続することです。 MCP (モデル コンテキスト プロトコル) サーバーは、エージェント ツールに、Microsoftドキュメント、リポジトリ ヘルパー、Azure リソース操作などの承認済み機能にアクセスするための構造化された方法を提供します。 他の開発者の依存関係と同様にオンボードを扱います。構成の自動化、接続の検証、アクセスの境界が明確であることを確認します。

IDE と開発者ツールをコーディング エージェントに接続する

  1. エージェントが有効なワークフローを含む VS Code やターミナル優先ワークフローなど、プライマリ クライアント エクスペリエンスを選択します。
  2. 組織の承認済み ID を使用して、Copilot Chat、Copilot CLI、Claude Code などのエージェント ツールをインストールしてサインインします。
  3. ユーザー設定に属するものとワークスペース設定に属するものを決定します。 リポジトリ固有のMCPサーバー、プロンプト、ガードレール向けにワークスペース設定を使用して、それらをコードとともに持ち運べるようにします。
  4. コーディング規則、ビルドおよびテスト コマンド、エージェントが実行すべきではないアクションのルールなど、リポジトリの手順をチェックインします。 Claude Code の場合、このガイダンスは通常、 CLAUDE.mdに格納されます。
  5. ツールの安全な既定値を定義します。 ファイル書き込みとシェル コマンドに対して明示的な承認を要求し、エージェントが無人で実行できるコマンドを許可リストします。
  6. リポジトリのマッピング、テストの実行、小さなリファクタリングの提案など、小規模なオリエンテーション タスクの実行をエージェントに依頼して、セットアップを確認します。 差分と CI で結果を確認します。
  • Microsoft MCP サーバーの概要: エージェントが信頼できる最新のMicrosoftドキュメントとコード サンプルを必要とする場合に、このサーバーを使用します。 パブリック リモート エンドポイントが /api/mcp。 詳細については、「Microsoft Learn MCP Server の概要」を参照してください。
  • Azure MCP サーバー: エージェントが開発環境からAzureリソースを検査、クエリ、管理する必要がある場合に、このサーバーを使用します。 詳細については、「Azure MCP サーバーの概要」を参照してください。

Important

承認された MCP サーバーにのみエージェントを接続します。 許可リストに登録されたエンドポイント、最小特権のツール スコープ、監査可能なログを優先します。 ツールがリポジトリに書き込んだり、リソースをデプロイしたりできる場合は、運用アクセスのように扱い、適切にゲートします。

Azure最適化されたエージェント チームを構築する

Azureのエンタープライズ レベルの B2B ソリューションの場合は、単純なエージェント モデルから始めて、Azure固有の責任が明確な場合にのみ拡張します。 Azureガイダンスでは、ランディング ゾーンを、スケーラブルでセキュリティで保護された管理された環境の推奨される開始点として扱います。 また、ID、接続、管理などの共有サービスを提供するプラットフォーム ランディング ゾーンと、アプリケーションと環境のワークロード リソースを保持するアプリケーション ランディング ゾーンも区別します。 両方で、Azure RBAC、Cost Management、Microsoft Defender for Cloudなどのコア コントロールを有効にします。

この違いは、B2B 製品にとって重要です。これは、目標が機能を迅速に出荷することだけではありません。 目標は、企業のお客様が信頼できる製品を構築することです。 Microsoft Azureの運用グレードのエージェントのスタートアップ ガイダンスでは、チームがプロトタイプを超えて移動する際に重要になる設計領域 (マルチテナント、アプリケーション レイヤー、オーケストレーションレイヤー、コンテキスト レイヤー) を呼び出します。 エンタープライズ シナリオでは、複数のお客様のセキュリティ、信頼性、適応性にも注意が必要です。

Microsoftでは、エージェント ワークフローに適応できるAzureスキルが提供されます。 スタートアップ企業は、マルチエージェント エンジニアリング チームのモデルとして gstack パターン を使用することもできます。 以下のロールは、Azure 上でエンタープライズ向けの B2B 製品を構築するスタートアップ向けの、Azure に最適化された推奨ロールです。

  1. 製品・要件計画エージェント

    このエージェントを、新しい作業の受付窓口として使用してください。 これにより、製品の要求は、テナントの分離、ガバナンスのニーズ、デプロイの制約、運用上の期待など、機能スコープと非機能要件を含む短い実装計画に変わります。

  2. Azure プラットフォーム アーキテクト エージェント

    このエージェントを使用して、プラットフォーム ランディング ゾーンと環境基盤 (テナントのセットアップ、管理グループ、サブスクリプション戦略、接続性、ID、ガバナンス ベースライン、共有プラットフォーム サービス) を形成します。 Azureランディング ゾーンのガイダンスでは、これらの決定を基本として位置付け、大規模なAzure環境の標準化された開始点としてランディング ゾーン モデルを使用することをお勧めします。 開始点として azure-enterprise-infra-planner スキル を使用します。

  3. エンタープライズ アプリケーション アーキテクト エージェント

    このエージェントを使用して、 アプリケーションのランディング ゾーン とビジネス ワークロード自体に焦点を当てます。 B2B ソリューションの場合、このロールは、ワークロードの境界、環境の分離、アプリケーション層の設計、テナント固有のロジックをより広範なプラットフォーム基盤にマップする方法を所有します。

  4. ID とセキュリティ エージェント

    このエージェントを使用して、エンタープライズ アクセス制御とワークロード保護を確認します。 Azure Well-Architectedガイダンスでは、ID をプライマリ境界として識別し、厳密、条件付き、監査可能な ID とアクセス管理を推奨します。 このロールは、認証パターン、ワークロード ID、RBAC の境界、ネットワークのセグメント化、セキュリティで保護された既定値を確認します。

  5. Azure DevOpsおよびIaC エージェント

    このエージェントを使用して、デプロイ テンプレート、プラットフォームの自動化、繰り返し可能なプロビジョニングという "コードを通じてすべて" レイヤーを所有します。 Azureオペレーショナル エクセレンス ガイダンスは、基盤をプラットフォームの自動化と DevOps に結び付け、Azureガバナンス ガイダンスでは、新しい環境に対してBicepまたは Terraform ベースのデプロイ フローを推奨します。 開始点として azure-prepare スキル を使用します。

  6. 信頼性と可観測性のエージェント

    このエージェントを使用して、正常性、アラート、運用環境の動作を確認します。 Azure Well-Architected信頼性ガイダンスでは、正常性状態のモデル化、監視とアラート戦略の設計、メトリック、ログ、トレースを使用して重要なフローとワークロード コンポーネントを追跡することをお勧めします。

  7. Azure統合エージェント

    このエージェントを使用して、実際のAzure環境で開発者エクスペリエンスを実現します。 Azure MCP Server を使用すると、AI エージェントは自然言語を使用してAzureリソースと対話でき、GitHub Copilot CLI、GitHub Copilotコーディング エージェント、SDK ベースのアプリ、およびその他の MCP 互換クライアントから使用できます。 azure-deploy スキルから始めて、環境に合わせて変更します。

  8. ガバナンスとコスト エージェント

    スタートアップがクレジット資金による実験からエンタープライズ運用に移行する際に、このエージェントを使用して予算、タグ付け、ポリシーの割り当て、コンプライアンス ガードレールを適用します。 Azureガバナンス ガイダンスでは、自動ガードレール、Azure Policyの適用、予算やアラートなどのコスト管理が推奨されます。 Azure コンプライアンスと Azure コストのスキルは、出発点として役立ちます。

  9. レビュー担当者と QA エージェント

    これらのエージェントを使用して、マージ前に正確性、セキュリティ、エッジ ケース、ランディング ゾーンの配置、アクセス境界、監視カバレッジ、インフラストラクチャ変更の安全性を確認します。 azure-validate スキルから始めて、顧客と環境のニーズに合わせて変更します。

これは汎用の gstack セットアップとどのように異なるか

gstack スタイルのパターン（考える → 計画する → 構築する → レビューする → テストする → 出荷する → 振り返る）は、役割の分離、レビューループ、そしてシンプルな運用モデルを提供するため、依然として有用な出発点です。 推奨される変更は、汎用的なエンジニアリング チームを、プラットフォーム基盤、ワークロード設計、セキュリティ、自動化、可観測性、ガバナンスといった Azure のアーキテクチャ境界を反映したチームに再編することです。 その構造により、Azure 固有の考慮事項が後回しにされるのを防げます。

1 日目から、仕様に基づく開発、コードとしてのインフラストラクチャ、CI/CD を使用してビルドする

Azure上で構築を始める際には、アプリケーション コード、インフラストラクチャ、デプロイを 1 つのエンジニアリング システムとして扱います。 ある場所で製品を設計し、別の場所でインフラストラクチャをプロビジョニングし、後でデプロイを自動化する代わりに、次のワークフローを使用します。

  • 仕様では、目的の結果が定義されます。
  • コードとしてのインフラストラクチャ (IaC) は、目的のAzure環境を定義します。
  • CI/CD は、反復可能なパイプラインを介して変更を検証してデプロイします。

このアプローチにより、意図と実装の間の誤差が軽減され、チームに共通の信頼できるソースが提供され、プロトタイプから運用環境にスケーリングするのに役立ちます。

Azureでの仕様駆動型の IaC 優先配信

ワークフローの例

  1. 仕様で機能を定義します。

    仕様優先のアプローチを使用して、コードを記述する前に、問題、ユーザー、要件、制約、成功条件をキャプチャします。

  2. プランナー エージェントに実装準備機能の概要を作成してもらう。

    プランナーはスコープと要件を明確にして、ワークフローがアドホック プロンプトではなく明示的なプランから開始されるようにします。

  3. Azure プラットフォーム アーキテクト エージェントに、この機能のAzure基盤を設計してもらう。

    このエージェントは、ID、ガバナンス、ネットワーク、管理、ランディング ゾーンの配置など、Azure環境に機能がどのように適合するかを決定します。

  4. Azure DevOpsおよび IaC エージェントに、コードとしてインフラストラクチャを定義させます。

    バージョン管理に格納されている Bicep または Terraform に、必要なAzureリソース、環境構造、およびデプロイ構成を実装します。

  5. Azure統合エージェントに実際のAzure環境を確認させます。

    エージェントがリソースを検査し、前提条件を検証し、推測する代わりに実際のAzure環境に対して作業できるように、Azure MCP Server などのAzure対応ツールにワークフローを接続します。

  6. レビュー担当者と QA エージェントに変更を監査してもらう。

    マージの前に、正確性、セキュリティ、エッジ ケース、監視、ログ記録、正常性チェックを確認します。

  7. プル要求と CI/CD を使用して、機能を検証してデプロイします。

    アプリケーション コード、IaC、およびデプロイ ワークフローの変更をプル要求の背後に配置して、マージ前にビルド、テスト、検証を実行します。

  8. 仕様、インフラストラクチャ、デプロイのワークフローを同期したままにします。

    仕様、IaC、パイプラインを生きた成果物として扱い、デプロイされたシステムが時間の経過と共に意図した設計に合わせて配置されるようにします。

このモデルにより、スタートアップ企業は、最初のビルドから、Azureで実稼働可能な配信に移行する、より信頼性の高い方法が提供されます。 チームは、手動でのポータルのセットアップ、切断されたスクリプト、または文書化されていない決定に依存するのではなく、仕様が意図をキャプチャし、IaC がAzure環境をキャプチャし、CI/CD が出荷するたびに一貫性を強制するワークフローを取得します。

Summary

エージェントベースの開発は、明確な仕様、特殊なエージェントロール、Azure対応ツール、反復可能な配信ワークフローを組み合わせることで、スタートアップ企業がアイデアから実装へと移行するのに役立ちます。 チームは、構築する必要がある内容を定義し、計画を使用してその意図を技術的な決定とタスクに変換し、アドホック変更ではなく、バージョン管理されたワークフローを通じてアプリケーション コードとインフラストラクチャを実装する仕様から始めます。

強力なワークフローは、1 つの汎用コーディング アシスタントではなく、特殊なロールからもメリットがあります。 Azure プロジェクトでは、エージェントが MCP Server Azure などのAzure対応ツールを使用できる場合や、プル要求、差分、テスト、CI/CD を使用して変更をレビューできる場合に、エージェントベースの開発がより便利になります。

このアプローチは、スタートアップ企業が将来の手直しを作成することなく、迅速に構築するのに役立ちます。 創設者にとっては、最初のデプロイの高速化、手動での構成ミスの減少、レビューの明確化、プロトタイプから運用グレードのソフトウェアへのスムーズなパスを意味します。

  • 最終更新: