独自の AI エージェントを使用して AWS Partner Central エージェントを環境に組み込む方法

本記事は、AWS で Technical Account Manager を務める Pawan Kumar による「How to fit AWS Partner Central agents into your environment with your own AI agent」を翻訳したものです。

多くの AWS パートナーは、日々のワークフローを支える AI エージェント、自動化パイプライン、または社内ツールをすでに保有しています。これには、商談を要約する Slack ボット、パイプラインの健全性を追跡する CRM 連携、または営業チームが共同作業を行うカスタムポータルなどが含まれます。パートナーは、AWS Marketplace 販売者ジャーニーの一環として共同販売の動きを加速するために、情報を再入力したり、すでに機能しているものを再構築したりすることなく、これらの既存のツールやデータソースを AWS Partner Central に接続したいと考えています。

AWS Marketplace の販売者として、Amazon Web Services (AWS) と効果的に共同販売する能力は、AWS Marketplace における可視性、商談のスピード、および収益成長に直接影響します。ツールが AWS Partner Central とどのように通信するかを効率化することは、パイプラインを構築する新規パートナーであろうと、オペレーションを拡大する既存パートナーであろうと、共同販売の動きを成熟させるための重要なステップです。

この記事では、AWS Partner Central エージェント MCP サーバーを既存の環境に統合する方法を紹介します。Model Context Protocol (MCP) を介したエージェント間通信を使用して、現在のツールを AWS Partner Central に接続する軽量なオーケストレーターを構築します。すでに機能しているものを置き換えるのではなく、統合レイヤーを追加します。このレイヤーにより、エージェントが自然言語を使用して AWS Partner Central エージェントと対話できるようになります。

なぜエージェント間通信なのか？

従来の API 統合では、対象システムのすべてのフィールド、検証ルール、およびペイロード構造を理解する必要があります。エージェント間通信はこのモデルを逆転させます。つまり、エージェントは達成したいことを表現し、AWS Partner Central エージェントがその方法を処理します。

AWS Partner Central 自動化パターンのエージェント間アーキテクチャは、協調して動作する 2 つの AI エージェントを使用します。カスタムオーケストレーターはコンテキストを収集し、何を更新するかを決定し、MCP を介して、組み込みの承認ワークフローで変更を検証・実行する AWS ホスト型の AWS Partner Central エージェントと通信します。これは以下のパターンで示されています。

エージェント間アーキテクチャ。オーケストレーターは MCP を介して AWS Partner Central Agent と通信します。

以下の表は、これと AWS Partner Central API を直接呼び出す場合を比較したものです。

アプローチ	お客様のコードが処理する内容	AWS Partner Central が処理する内容
直接 API	フィールドマッピング、検証、ペイロード構築、エラー処理	API 処理
エージェント間	コンテキストの収集、意図の表現	検証、ビジネスルール、ペイロード構築、承認ワークフロー、API 処理

このアプローチでは、AWS Partner Central エージェントがビジネスルール、必須フィールド、および検証を処理するため、お客様自身がそのロジックをコード化する必要はありません。JSON ペイロードを構築する代わりに自然言語で意図を伝え、ヒューマンインザループの承認ワークフローにより、共同販売の更新が適用される前に明示的な確認が必要になります。

アーキテクチャの概要

このパターンは 3 つのコンポーネントを使用します。

コンテキストソース – 既存のツール (Slack チャンネル、ローカルドキュメント、アップロードされたファイル、CRM エクスポート)
オーケストレーターエージェント – コンテキストを収集し、Amazon Bedrock を呼び出してインサイトを統合し、AWS Partner Central の更新を MCP エージェントに委任する Python アプリケーション
AWS Partner Central MCP エージェント – 自然言語のリクエストを受け取り、それを検証し、人間による承認後に AWS Partner Central API 呼び出しを実行する AWS ホスト型エージェント

このアーキテクチャにより、共同販売の商談管理を既存のワークフローに直接統合できます。カスタム CRM を通じて商談を追跡している場合は、商談メモをエクスポートしてオーケストレーターに渡すことができます。チームが Slack を通じて共同作業を行っている場合は、チャンネルのコンテキストを入力として取り込むことができます。自動化されたパイプラインツールは、スケジュールに基づいてオーケストレーターをトリガーし、商談を最新の状態に保つことができます。

その結果、システムと AWS Partner Central の間の接続が実現し、チームがツール間でコンテキストを切り替える必要なく、共同販売の動きを強化します。

オーケストレーターエージェントの内部パイプライン。コンテキストソースはマージャーを経て Amazon Bedrock で分析され、その後実行のために MCP クライアントに送られます。

図 2: オーケストレーターエージェントの内部パイプライン。コンテキストソースはマージャーを経て Amazon Bedrock で分析され、その後実行のために MCP クライアントに送信

はじめに

サンプルリポジトリには、動作するオーケストレーター、検証スクリプト、およびデモファイルが含まれています。ここで完全なセットアップ手順を再現するのではなく、各ステップを詳細に説明するハンズオンワークショップに従うことをお勧めします。

すぐに始めるには、以下を実行します。

git clone https://github.com/aws-samples/partner-crm-integration-samples.git

cd partner-crm-integration-samples/partner-central-api-sample-codes/agentToAgent

pip install -r requirements.txt

前提条件

Amazon Bedrock モデルアクセスが有効化された AWS アカウント (Amazon Bedrock の Anthropic 製 Claude を使用します)
AWS 認証情報が設定されていること (aws configure)
Python 3.10 以降がインストールされていること
AWS SDK for Python (Boto3) バージョン 1.35.0 以降 (partnercentral-sellingサービスのサポート用)
AWS Partner Central Selling API および AWS Partner Central MCP エージェント用の AWS Identity and Access Management (IAM) 権限 (AWSMcpServiceActionsFullAccessマネージドポリシーをアタッチ)

設定

サンプルでは、カタログとエンドポイントを指定するためにconfig.jsonファイルを使用します。

{
  "catalog": "Sandbox",
  "region": "us-east-1",
  "endpoints": {
    "partnercentralselling": "https://partnercentral-selling.us-east-1.api.aws",
    "partnercentralmcp": "https://partnercentral-agents.us-east-1.api.aws/mcp"
  }
}

テスト用にはcatalogをSandboxに、本番用にはAWSに設定します。Sandbox カタログを使用すると、実際の商談に影響を与えることなく実験できます。

ヒント: Sandbox カタログを使用するには、まずCreatePartner API を使用してパートナーとして登録する必要があります。詳細については、ワークショップガイドを参照してください。

先に進む前に、python verify_setup.pyを実行して、すべてのコンポーネントが動作していることを確認します。

オーケストレーターの仕組み

オーケストレーターエージェント (orchestrator_agent.py)は、4 つのステップからなるワークフローに従います。

1. コンテキストを収集: エージェントは既存のソースから読み取ります。

from orchestrator_agent import OrchestratorAgent

agent = OrchestratorAgent()

context_sources = agent.gather_context(
    slack_channels=["partner-deals"],
    local_folders=["./deal-notes"],
    uploaded_files=["meeting_notes.txt"]
)

2. 現在の商談データを取得: エージェントは、AI 生成のためのコンテキストを提供するために、AWS Partner Central から商談の現在の状態を取得します。

opportunity_data = agent.mcp_client.get_opportunity("O15081741")

3. Amazon Bedrock で次のステップを生成: 収集したコンテキストと現在の商談データを使用して、エージェントは Amazon Bedrock を呼び出し、実行可能な次のステップを統合します。

next_steps = agent.next_steps_generator.generate(
    context_sources=context_sources,
    prompt="Generate next steps based on meeting notes",
    opportunity_data=opportunity_data
)

4. AWS Partner Central MCP エージェントを介して更新: オーケストレーターは、署名付き HTTP リクエストを使用して、生成されたコンテンツを AWS Partner Central MCP エージェントに送信します。

mcp_response = agent.mcp_client.update_next_steps(
    opportunity_id="O15081741",
    next_steps=next_steps
)

MCP エージェントは自然言語のリクエストを受け取り、適切な API ペイロードを構築し、更新を実行する前に人間による承認のためにそれを提示します。

デモの実行

まず、AWS Partner Central を更新せずに生成された出力を確認するために、ドライランを試してください。

python orchestrator_agent.py --opportunity-id O15081741 \
  --upload demo_meeting_notes.txt --dry-run

商談を更新する準備ができたら、--dry-runフラグを削除します。

python orchestrator_agent.py --opportunity-id O15081741 \
  --upload demo_meeting_notes.txt \
  --prompt "Generate next steps based on meeting notes"

エージェントは次のステップを生成し、その後承認プロンプトを提示します。このヒューマンインザループの承認は重要な安全機能であり、明示的な確認なしに AWS Partner Central に更新が反映されることはありません。

MCP 通信の仕組み

オーケストレーターは、単一の署名付き HTTP POST リクエストを介して AWS Partner Central MCP エージェントと通信します。通信フローは次のように機能します。

エージェントは、実行したい更新を記述した自然言語のメッセージを構築します。
メッセージは、AWS Signature Version 4 (SigV4) 認証を使用して MCP エンドポイントに送信されます。
AWS Partner Central エージェントはリクエストを処理し、ビジネスルールに照らして検証し、提案された変更とともにrequires_approvalステータスを返します。
エージェントはユーザーに承認を提示し、承認または却下の決定を返送します。
承認されると、AWS Partner Central エージェントは API 呼び出しを実行し、結果を返します。

以下は MCP リクエストのペイロードです。

payload = {
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
        "name": "sendMessage",
        "arguments": {
            "content": [{"type": "text", "text": f"Update..."}],
            "catalog": "Sandbox",
            "stream": False
        }
    }
}

リクエストは SigV4 で署名され、標準の HTTPS リクエストとして送信されます。特別な SDK やプロトコルライブラリは不要です。

API サーバーとして実行する

本番環境での使用では、環境内の他のサービスから呼び出すことができる FastAPI サーバーとしてオーケストレーターを実行できます。

python server.py
# Server running at http://localhost:8001

これにより、ファイルアップロードを使用して次のステップを生成するためのエンドポイントが公開されます。

curl -X POST http://localhost:8001/api/generate-with-files \
  -F "opportunity_id=O15081741" \
  -F "prompt=Generate next steps from meeting notes" \
  -F "files=@meeting_notes.txt" \
  -F "update_opportunity=true"

パターンを環境に適応させる

このサンプルは会議メモから次のステップを生成する方法を示していますが、同じ通信パターンはさまざまなパートナー環境で機能します。以下の表は、一般的な統合アプローチを示しています。

お客様の環境	統合アプローチ
Slack ボット	現在のチャンネルをコンテキストとしてオーケストレーターをトリガーするスラッシュコマンドを追加する
CRM 統合	CRM から商談メモをエクスポートし、アップロードファイルとしてオーケストレーターに渡す
スケジュールされたパイプライン	オーケストレーターをcronスケジュールで実行し、最近のアクティビティに基づいて商談を最新の状態に保つ
マルチエージェントフレームワーク	既存のエージェントフレームワーク (LangChain や CrewAI など) に MCP エンドポイントをツールとして追加する

オーケストレーターをどのようにトリガーするかに関わらず、AWS Partner Central MCP エージェントとの通信プロトコルは同じです。つまり、実行したいことを記述した自然言語のメッセージを構築し、SigV4 認証を使用して MCP エンドポイントに送信し、承認レスポンスを処理します。お客様側の実装の詳細は、使用するツールやインフラストラクチャによって異なります。

クリーンアップ

テスト用に Sandbox カタログを使用した場合、Sandbox データは本番環境に影響を与えないため、クリーンアップは不要です。FastAPI サーバーをデプロイした場合は、Ctrl+C で停止します。オーケストレーター用に AWS リソース (Amazon Bedrock モデルアクセス、IAM ロール、エージェントを実行するコンピューティングリソースなど) をプロビジョニングした場合は、継続的な課金を避けるために、AWS マネジメントコンソールを通じてそれらを確認して削除してください。

まとめ

AWS Partner Central エージェント MCP サーバーを使用すると、既存の AI ツールを単一の HTTP エンドポイントを介して AWS Partner Central の共同販売ワークフローと統合できます。AWS Partner Central のビジネスルールをコード化する必要がある直接的な API 統合を構築するのではなく、そうした懸念事項を MCP エージェントに委任し、オーケストレーターは最も得意とすること、つまり環境からのコンテキスト収集とインサイトの生成に集中できます。

AWS パートナーにとって、これにより最新の共同販売商談を維持するためのリソースが削減されます。パイプラインツールが自動的に更新を表面化し、それらを AWS Partner Central 経由でルーティングできると、商談のスピードが向上し、AWS フィールドチームへの可視性が高まります。共同販売データを最新の状態に保つことは、AWS Marketplace Channel Incentive Program (ACIP) などのプログラムにおける貴社のポジションも強化します。

環境が Slack ボット、社内サービス、スケジュールされたパイプライン、またはマルチエージェントフレームワークのいずれであっても、AWS Partner Central MCP エージェントとの通信プロトコルは同じです。貴社の統合コードはスタックによって異なりますが、MCP エンドポイントは一貫したインターフェースを提供します。つまり、意図を表現し、エージェントに検証とペイロードの構築を任せ、反映される前に承認するというものです。

このパターンを実装するには、GitHub のサンプルコードを試し、ハンズオンワークショップを完了してください。

著者について

本記事は AWS 社内の生成 AI ツールで機械翻訳し、Partner SA 河原がレビューしました。原文はこちらです。

AWS JAPAN APN ブログ