Model Context Protocol対応AIエージェントのGitHub Actionsにおける活用調査

作成日: 2025年05月24日

Model Context Protocol対応AIエージェントのGitHub Actionsにおける活用調査

1. はじめに

本レポートは、Model Context Protocol（MCP）に対応し、GitHub Actionsのランナー上で動作する、またはランナーから指示可能なAIエージェントに関する調査結果をまとめたものです。MCPは、AIアプリケーションが外部ツールやサービスと標準化されたインターフェースを介して接続するためのプロトコルであり 1、AIエージェントのツール連携における複雑性を低減することを目的としています 3。GitHub Actionsは、ソフトウェア開発ワークフローを自動化するための強力なプラットフォームであり、AIエージェントをCI/CDパイプラインやその他の自動化タスクに組み込むことで、開発プロセスの効率化や高度化が期待されます。

本調査では、主要なMCP対応AIエージェントフレームワークやプラットフォームを対象とし、それぞれのGitHub Actions環境での利用可能性、設定方法、制約事項、そして具体的な指示方法について分析します。

2. Model Context Protocol（MCP）とGitHub Actions連携の一般原則

2.1. Model Context Protocol（MCP）の概要

MCPは、AIモデルが外部のデータソースやサービスと構造化されたAPI呼び出しを、一貫性のある安全な方法で行うためのオープンスタンダードです 3。このプロトコルは、AIアプリケーション（MCPホスト）がMCPクライアントを通じてMCPサーバーに接続し、サーバーが提供するツールやリソースを利用するというクライアントサーバーモデルに基づいています 2。MCPの目的は、多様なAIアプリケーションとツールが個別のインテグレーションを必要とせずに相互運用できるようにすることであり、これはハードウェアにおけるUSB-Cポートの役割に例えられます 1。

MCPはJSON-RPC 2.0をベースに構築されており 3、AIアシスタントが外部サービスの関数を呼び出したり、データを取得したり、事前定義されたプロンプトを使用したりすることを可能にします。MCPサーバーは、ファイルやデータベースのようなローカルデータソース、あるいはSalesforceやBoxのようなアプリケーションのAPIといったリモートサービスからのデータや機能を提供する軽量プログラムです 5。

2.2. AIエージェントによるMCPツールの利用

AIエージェントは、ユーザーや他のシステムに代わって自律的にタスクを実行できるシステムまたはプログラムです 2。MCPを利用することで、AIエージェントはコンテキストを認識しつつ、標準化されたプロトコルでツール統合を行うことができます 2。エージェントはMCPクライアントとして機能し、MCPサーバーに接続してそのツールを利用します 1。

プロセスの流れは概ね以下の通りです 3：

1. MCPサーバーへの接続：ホストアプリケーション（AIアシスタント）がMCPクライアントを初期化し、サーバーへの接続を確立します。
2. 利用可能なツール/リソースの発見：クライアントはサーバーが提供する機能を照会します（例：{“method”: “tools/list”}）。
3. LLMによるツールの選択：ユーザーのリクエストに基づき、LLMが使用すべきツールを決定します。
4. MCP経由でのツールの呼び出し：クライアントが選択されたツール名とパラメータを含むtools/callリクエストをサーバーに送信します。
5. LLMへの結果の返却：MCPクライアントがツールの出力を受信し、ホストアプリケーションがそれをAIの応答に統合します。

2.3. GitHub ActionsランナーにおけるAIエージェントの実行と指示

GitHub Actionsランナーは、ワークフロー内のジョブを実行するための仮想環境です。このランナー上でMCP対応AIエージェントを実行したり、ランナーからエージェントに指示を出したりするには、いくつかの基本的なアプローチが考えられます。

• ランナー上での直接実行： PythonやNode.jsなどで記述されたAIエージェントのスクリプトを、必要なライブラリ（MCPクライアントライブラリ、LLM SDKなど）とともにランナー環境にセットアップし、ワークフローのステップとして直接実行します。この場合、エージェントの指示は、ワークフローの入力、環境変数、またはスクリプトへの引数として渡されます。
• 外部エージェントへの指示： AIエージェントがCloudflare WorkersやAWS Lambdaなどの外部プラットフォームでホストされている場合、GitHub Actionsランナー上のスクリプト（例：curlコマンドやPythonのrequestsライブラリを使用）が、HTTPリクエストなどを介して外部エージェントにタスク実行の指示とパラメータを送信します。認証情報（APIキーなど）はGitHub Secretsを通じて安全に管理されます。
• GitHub Actions自体を操作するエージェント： 特定のMCPサーバー（例：GitHub Actions MCP Server 6）を利用することで、AIエージェントがGitHub Actionsのワークフローをリスト化、トリガー、キャンセルするなどの操作を行うことができます。この場合、エージェント（MCPクライアント）とMCPサーバーはランナー上で動作することも、エージェントがリモートで動作しMCPサーバーに接続することも可能です。

いずれのアプローチにおいても、LLMのAPIキーやMCPサーバーへの認証情報などの機密データは、GitHub Secretsを利用して安全に管理することが不可欠です 7。

3. MCPクライアント対応AIエージェントの調査

3.1. GitHub Copilot コーディングエージェント

GitHub Copilotの新しいコーディングエージェントは、GitHub Actions上で動作し、MCPを利用して外部のツールやデータと連携する能力を持っています 9。このエージェントは、GitHubの課題 (issue) をCopilotに割り当てるか、VS CodeなどのIDEからプロンプトを入力することで起動します 9。

MCPクライアント機能とGitHub Actionsでの動作：
Copilotコーディングエージェントは、GitHub Actionsによって提供される安全でカスタマイズ可能な開発環境内で動作します 9。エージェントはMCPを通じて、リポジトリ設定で構成されたMCPサーバーに接続し、GitHub外部のデータや機能にアクセスできます 9。公式のGitHub MCPサーバーからは、GitHubのデータ（issue、プルリクエストなど）を取り込むことができます 9。
現在、CopilotコーディングエージェントはローカルMCPサーバーが提供するツールのみをサポートしており、リソースやプロンプトはサポートしていません 11。MCPサーバーの設定はリポジトリの管理者によってJSON形式で行われ、GitHub.comのリポジトリ設定に直接入力します 11。設定には、MCPサーバーを起動するコマンド、引数、有効にするツール、環境変数（GitHub SecretsからCOPILOT_MCP_プレフィックス付きのシークレットを参照可能）などを含めることができます 11。

GitHub Actionsランナーからの指示方法：
Copilotコーディングエージェントへの指示は、主にGitHubのissueを割り当てるか、VS CodeなどのIDEのCopilot Chatを通じて行われます 9。GitHub Actionsワークフローから直接、特定のMCPツールとパラメータを指定してエージェントをプログラム的に呼び出す明確なAPIやSDKは、提供されている情報からは確認できませんでした 15。エージェントは割り当てられたタスクに基づいて自律的にMCPツールを使用します 11。
GitHub Actionsワークフロー自体がCopilotエージェントの実行環境（コンピュート環境）として機能するため 9、ワークフロー定義（YAMLファイル）を通じてエージェントのタスクを間接的にトリガーすることは考えられます。例えば、特定のイベント（issue作成など）をトリガーとしてCopilotにissueを割り当てるような自動化は可能です。しかし、ワークフローのステップ内で「このMCPツールをこれらのパラメータで使え」といった直接的な命令をエージェントに与える方法は見当たりません。エージェントの自律的な判断に委ねられる部分が大きいです。

このアーキテクチャは、CopilotエージェントがGitHubのネイティブな制御レイヤー内で動作し、既存のセキュリティポリシー（ブランチ保護など）を尊重するように設計されていることを意味します 9。エージェントによるプルリクエストは人間の承認を必要とし、CI/CDワークフローが実行される前にチェックが行われます 10。
この現状は、GitHub Actionsワークフローからより細かくエージェントのMCPツール利用を制御したい場合には制約となり得ます。エージェントの動作はリポジトリ設定で定義されたMCPサーバー構成と、割り当てられたタスク（issueの内容など）に大きく依存するため、ワークフローからの動的な指示や特定のツールコールを強制する直接的な手段は限定的です。将来的にAPIが提供される可能性はありますが、現時点ではUI駆動のインタラクションが主となります。

3.2. PydanticAI

PydanticAIは、Pydanticのデータ検証能力とAI機能を組み合わせたPythonライブラリです 24。LLMの出力を構造化し、信頼性を高めることを目的としています 24。PydanticAIエージェントは、MCPクライアントとして機能し、MCPサーバーに接続してツールを利用できます 1。

MCPクライアント機能とGitHub Actionsでの動作：
PydanticAIエージェントは、MCPクライアントとしてMCPサーバーに接続し、外部ツールやサービスを利用できます 1。これは、PydanticAIが提供するAgentクラスを通じて実現されます。エージェントは、観測、思考、行動のループに従い、各ステップでPydanticモデルによるスキーマ検証を行うことで、LLMの予測不可能性を低減します 24。
PydanticAIで構築されたエージェントは、PythonスクリプトとしてGitHub Actionsランナー上で直接実行可能です。christophergs.comのEV充電成長CLIの例では、PydanticAIとTyperで構築されたCLIアプリケーションが、GitHub Actionsのcron機能によって定期実行されています 7。この例では、main.pyがCLIのエントリーポイントとなり、GitHub Actionsから呼び出される関数（run_ev_charging_growth.py内の関数）がPydanticAIのワークフローを開始します 7。

GitHub Actionsランナーからの指示方法と設定：
GitHub Actionsランナー上でPydanticAIエージェントを実行する場合、指示は主に以下の方法で与えられます：

1. スクリプト引数： Typerのようなライブラリを使用する場合、CLI引数としてタスクの詳細を渡すことができます 7。
2. 環境変数： APIキー（例：OPENAI_API_KEY）や設定値は、.envファイルやGitHub Secretsを通じて環境変数としてエージェントに渡されます。pydantic-settingsライブラリがこの管理を容易にします 7。
3. ワークフローファイル内の直接的な指示： Pythonスクリプトを呼び出す際に、固定的な指示やパラメータをコード内に埋め込むか、ワークフローファイルからスクリプトに渡すことができます。

PydanticAIエージェントは、@agent.toolデコレータを使用してツールを定義し、LLMがこれらを呼び出せるようにします 7。また、result_type引数で期待する結果の型をPydanticモデルとして指定することで、LLMの応答が期待する形式であることを保証します 7。

GitHub ActionsでPydanticAIエージェントを実行するための技術的要件と制約は以下の通りです：

• Python環境： ランナーにPython環境がセットアップされている必要があります。
• 依存ライブラリ： pydantic-ai、logfire（オプション）、および使用するLLMのSDK（例：openai）など、必要なライブラリをrequirements.txtなどで定義し、ワークフロー内でインストールする必要があります 7。
• APIキー管理： OPENAI_API_KEYなどの秘密情報は、GitHub Secretsに保存し、ワークフローを通じて環境変数としてエージェントに提供します 7。
• ネットワークアクセス： エージェントが外部のLLM APIやMCPサーバーにアクセスする場合、ランナーからのアウトバウンドネットワークアクセスが必要です。

PydanticAIの構造化された出力機能は、CI/CDパイプラインのような自動化された環境において特に価値があります。Pydanticモデルによって定義されたスキーマは、LLMの応答が一貫した形式であることを保証し、後続の処理ステップでのエラーを減少させ、パイプライン全体の信頼性を向上させます。これは、LLMの応答が非構造的である場合にしばしば発生する、予期せぬ形式変更によるパイプラインの失敗を防ぐのに役立ちます。PydanticAIのこの特性は、エージェントの出力をプログラムで確実に利用する必要があるGitHub Actionsのユースケースにおいて、大きな利点となります。

3.3. Amazon Bedrock Agents

Amazon Bedrock Agentsは、基盤モデル（FM）をデータソースやアプリケーション、ユーザー入力と連携させ、API統合やナレッジベース拡張を通じてタスクを完了させるフルマネージド機能です 25。エージェントはMCPサーバーにアクション グループとして接続し、タスクを達成できます 25。

MCPクライアント機能とGitHub Actionsでの動作：
Amazon Bedrock Agentsは、アクション グループ内でMCPクライアントを定義することで、MCPサーバーのツールを利用できます 25。Amazon Bedrock Inline Agent SDKは、インラインエージェントの呼び出しプロセスを合理化し、MCPサーバーによって提供されるツールへの直接アクセスを可能にする組み込みMCPクライアント実装を含んでいます 25。エージェントは、ユーザーのタスクに必要なツールを判断し、MCPサーバーツールが必要な場合は、対応するMCPクライアントを使用してそのサーバーにツール実行を要求します 25。
GitHub ActionsからAmazon Bedrock Agentを制御するには、AWS SDK（例：Boto3 for Python）を使用してInvokeAgent APIを呼び出します 8。GitHub Marketplaceには、プルリクエスト内のファイルを分析してフィードバックを提供する「Custom Amazon Bedrock Agent Action」も存在します 8。このアクションは、GitHub Secretsに保存されたAWS認証情報（AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION）またはGitHub OIDCを使用してBedrock Agentと通信します 8。

GitHub Actionsランナーからの指示方法と設定：
GitHub ActionsワークフローからBedrock Agentに指示を出す主な方法は、InvokeAgent API呼び出しです。

1. 認証設定： GitHub ActionsワークフローでAWSの認証情報を設定します。aws-actions/configure-aws-credentialsアクションを使用し、OIDCまたはアクセスキーID/シークレットアクセスキーを設定します 8。IAMロールにはbedrock:InvokeAgentアクションの実行権限が必要です 8。
2. InvokeAgent APIの呼び出し： Pythonスクリプト（Boto3を使用）またはAWS CLI（ストリーミング非対応 29）を使用してInvokeAgentを呼び出します。
   • 必須パラメータ： agentId, agentAliasId, sessionId 31。sessionIdは、会話を継続するためにリクエスト間で同じ値を使用します。GitHub Actionsのコンテキストでは、github.run_idなどを利用して一意のセッションIDを生成できます。
   • 指示の伝達： inputTextパラメータを使用して、エージェントへの自然言語プロンプトを渡します 25。このテキストが、エージェントがMCPツール（アクション グループとして定義）を使用するかどうかの判断材料となります。
   • sessionState： セッションの様々な属性を指定します。特に、アクション グループが制御を返すように設定されている場合（RETURN_CONTROL）、returnControlInvocationResultsフィールドを使用してアクション グループ呼び出しの結果をエージェントに返します 29。この場合、inputTextは無視されます 29。

YAML
# GitHub Actions workflow snippet
jobs:
invoke-bedrock-agent:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: $
aws-secret-access-key: $
aws-region: $
- name: Set up Python
uses: actions/setup-python@v4
with:
python-version: ‘3.x’
- name: Install Boto3
run: pip install boto3
- name: Invoke Bedrock Agent
env:
BEDROCK_AGENT_ID: $
BEDROCK_AGENT_ALIAS_ID: $
SESSION_ID: $-$
PROMPT_TEXT: “MCPツールXを使用してYを実行してください”
run: python invoke_bedrock_agent.py
Python
# invoke_bedrock_agent.py (Conceptual Boto3 script)
import boto3
import os
import json

client = boto3.client(‘bedrock-agent-runtime’, region_name=os.environ)
agent_id = os.environ
agent_alias_id = os.environ
session_id = os.environ
prompt_text = os.environ

response = client.invoke_agent(
agentId=agent_id,
agentAliasId=agent_alias_id,
sessionId=session_id,
inputText=prompt_text,
enableTrace=True # Optional: for debugging
)

completion = “”
for event in response.get(‘completion’):
chunk = event.get(‘chunk’, {})
completion += chunk.get(‘bytes’, b’’).decode(‘utf-8’)

print(f”Agent response: {completion}”)

# If handling RETURN_CONTROL:
# 1. Parse response[‘completion’] for ‘returnControl’ payload.
# This payload contains ‘invocationId’ and ‘invocationInputs’.
# ‘invocationInputs’ specifies the action group, API/function, and parameters.
# 2. Execute the tool/MCP call based on ‘invocationInputs’.
# 3. Prepare ‘returnControlInvocationResults’ with the outcome.
# 4. Call invoke_agent again with ‘sessionState’ containing ‘invocationId’ and ‘returnControlInvocationResults’.

1. MCPツール呼び出し： エージェントは、inputTextに基づいてどのツール（アクション グループ）が必要かを判断します。アクション グループがMCPクライアントである場合、対応するMCPクライアントを使用してMCPサーバーにツール実行を要求します 25。RETURN_CONTROLが設定されている場合、ワークフロースクリプトはMCPツール呼び出しのパラメータを受け取り、実行後に結果をエージェントに返す必要があります 29。

Bedrock Agentsがアクション グループでRETURN_CONTROLを使用する場合 25、GitHub Actionsワークフロースクリプトが「ツール実行」ステップを担当することになります。これは、スクリプトがエージェントのリクエストを解析し、実際のツール（別のライブラリやAPI呼び出し経由のMCPツールである可能性もある）を呼び出し、その結果をエージェントにフィードバックする必要があることを意味します。これによりワークフローの複雑性は増しますが、きめ細かい制御が可能になります。InvokeAgent APIの応答には、ツールとパラメータを指定するinvocationInputsが含まれ 29、呼び出し側アプリケーション（GitHub Actionsスクリプト）がこれを実行し、returnControlInvocationResultsを含むsessionStateを伴うInvokeAgentを再度呼び出します 29。したがって、GitHub Actionsワークフローはエージェントをトリガーするだけでなく、これらのタイプのツールについてはその実行ループに積極的に参加します。

Bedrockエージェント自体は、MCPクライアント（アクション グループで定義）をオーケストレーションするという意味で「MCPホスト」として機能します 25。 「MCPクライアント」部分はアクション グループ定義内に抽象化されており、多くの場合、Bedrock Inline Agent SDKの組み込みMCPクライアントが使用されます 25。開発者はアクション グループ内でMCPサーバーへの接続を設定し、エージェントはその接続の使用をオーケストレーションします。

GitHub ActionsランナーがBedrock Agentを呼び出し、そのBedrock AgentがMCPサーバー（内部または外部の可能性がある）にアクセスするためには、IAMロールとネットワーク構成（VPC、セキュリティグループ、ランナーのインターネットアクセス）が重要かつ複雑になります。GitHub Actionsランナーはbedrock:InvokeAgent権限を持つAWS認証情報を必要とし 8、Bedrock AgentのIAMロールはアクセスするAWSサービス（アクション グループ実行のためのLambda、ナレッジベースのためのS3など）の権限を必要とします 26。MCPサーバーがAWS内でホストされている場合、Bedrock Agent（またはそのLambda関数）はそれらに到達するためのネットワークパスと権限が必要です。MCPサーバーが外部にある場合、Bedrock Agentの環境にはインターネットアクセスが必要です。これにより、慎重に管理する必要がある多層的なセキュリティとネットワーク設定が生じます。

3.4. Cloudflare AI Agents (Agents SDK)

CloudflareのAgents SDKを使用して構築されたAIエージェントは、Cloudflare Workers上で実行されます 35。状態管理にはDurable Objectsが利用できます 35。

MCPクライアント機能：
Agents SDKは、AIエージェントにリモートMCPクライアントを組み込むことを可能にします 35。MCPClientManagerクラスが、リモートMCPサーバーへのトランスポート、認証（OAuth 2.1）、ツールディスカバリ、接続管理を処理します 35。複数のMCPサーバーへの同時接続と、ツール名の衝突を防ぐための名前空間管理もサポートされています 35。
GitHub Actionsからのトリガーと指示：
Cloudflare Workers（エージェントをホスト）は通常、HTTPリクエストによってトリガーされます 37。GitHub Actionsワークフローは、curlやPythonスクリプト（requestsライブラリを使用）を用いて、WorkerのURLにPOSTリクエストを送信し、JSONペイロードで指示やタスクを渡すことができます 39。
認証は重要であり、Workerエンドポイントは保護されるべきです。一般的な方法として、Bearerトークン（APIキー）をAuthorizationヘッダーで渡し、GitHub Secretsで管理します。CloudflareはMCPサーバーとの対話にOAuth 2.1もサポートしています 35。
wrangler-actionによるデプロイ：
cloudflare/wrangler-action GitHub Actionは、Workersのデプロイに使用されます 39。これによりエージェントコード自体がデプロイされます。CLOUDFLARE_API_TOKENやCLOUDFLARE_ACCOUNT_IDのようなシークレットが必要です 39。
GitHub ActionsにおけるPythonスクリプトによる対話パターンの概念実証：

Python

# GitHub Actions内の概念的なPythonスクリプト
import os
import requests
import json

worker_url = os.environ # GitHub Secretsから設定
auth_token = os.environ # GitHub Secretsから設定
task_payload = {
“mcp_instruction”: “GitHub MCPサーバーを使用してmy_repo内のワークフローをリスト化してください”,
“parameters”: {“owner”: “user”, “repo”: “my_repo”}
}
headers = {
“Authorization”: f”Bearer {auth_token}”,
“Content-Type”: “application/json”
}
try:
response = requests.post(worker_url, headers=headers, json=task_payload)
response.raise_for_status() # エラーがあれば例外を発生させる
# 応答を処理
print(f”Worker response: {response.json()}”)
except requests.exceptions.RequestException as e:
print(f”Error calling worker: {e}”)

このスクリプトは、GitHub Actionsのステップ内で実行され、環境変数を通じてWorkerのURLと認証トークンを受け取ります。その後、指定されたタスクペイロードをWorkerに送信します。

Cloudflare AI Agentsの運用において、wrangler-action 39 はWorker（エージェントそのもの）のデプロイを処理し、デプロイされたエージェントへの指示は、通常GitHub ActionsワークフローからのHTTP呼び出しという別のステップになります。これはサーバーレス関数の一般的なパターンであり、デプロイと指示が明確に分離されています。WorkerエージェントはHTTP経由で公開されるため、不正アクセスや指示を防ぐために堅牢な認証が不可欠です。Bearerトークンとして渡されるAPIキー/鍵が一般的なアプローチです 40。Cloudflareプラットフォームは、これを補強する様々なセキュリティ機能（Access、WAFなど）を提供します。もしCloudflareエージェントが呼び出し間で状態（会話履歴やMCP接続状態など）を維持する必要がある場合、KV StoreやDurable ObjectsのようなCloudflareのステートフルサービスを活用します 35。これにより、エージェントは単一のGitHub Actionsジョブ実行を超えたメモリとコンテキストを持つことができ、これは完全にエフェメラルなランナー上で実行されるエージェントとの大きな違いです。

3.5. OpenAI Agents SDK with MCP Extension

このSDKは、OpenAIのAgents SDKを拡張し、MCPサーバーをサポートします。これにより、エージェントはこれらのサーバーのツールをネイティブOpenAIツールと並行して使用できます 47。これはmcp-agentライブラリを使用して構築されています 47。

MCPクライアント機能：
標準のfrom agents import Agentをfrom agents_mcp import Agentに置き換えることで利用可能になります 47。Agentクラスは、設定ファイルで定義されたサーバー名をリストするmcp_serversプロパティと共に初期化できます 47。指定されたMCPサーバーからのツールを他のエージェントツールと集約します 47。
GitHub Actionsランナーでの実行可能性：
Pythonベースであるため、このSDKを使用したスクリプトをランナー上で直接実行することは可能です。Python環境、openai-agents-mcpとその依存関係（例：mcp-agent、OpenAI SDK）のインストールが必要です。
MCPサーバー設定とシークレットの管理：
MCPサーバーはmcp_agent.config.yamlを介して設定されます 47。このファイルはプロジェクトディレクトリまたは親ディレクトリに配置できます。シークレット（MCPサーバーまたはLLMのAPIキー）は、設定ファイル内（本番環境では非推奨）、別のmcp_agent.secrets.yamlファイル、または環境変数（GitHub Secretsを使用するGitHub Actionsに最適）として管理できます 47。SDKは設定ファイルの自動検出、明示的なパス指定、またはプログラムによる設定をサポートしています 47。
概念的な使用例：

Python

# OpenAI Agents SDK with MCPを使用した概念的なPythonスクリプト
from agents_mcp import Agent, RunnerContext
import asyncio
import os

# mcp_agent.config.yamlとシークレットが環境変数経由で設定されていると仮定
# OPENAI_API_KEYも環境変数で設定されている必要がある

async def main():
agent = Agent(
name=”GitHub Actions MCP Agent”,
instructions=”あなたはGitHubランナー上のエージェントです。ツールを使用してください。”,
mcp_servers=[“github_actions_tool_server”] # mcp_agent.config.yamlで定義
)
# RunnerContextはMCP設定ファイルのパスなどを指定できる
# ここでは、自動検出または環境変数による設定を期待
context = RunnerContext()
# secrets.yamlや環境変数からAPIキーを読み込むようにmcp-agentが設定されている必要がある
# 例: os.environ[‘OPENAI_API_KEY’] が設定されていること

result \= await Runner.run(agent, input\="ワークフロー 'deploy.yml' をトリガーしてください", context=context)  
print(result.response.value)

if __name__ == “__main__”:
# OPENAI_API_KEYなどの必要なAPIキーが環境変数に設定されていることを確認
if “OPENAI_API_KEY” not in os.environ:
print(“エラー: OPENAI_API_KEY環境変数が設定されていません。”)
else:
asyncio.run(main())

このエージェントは、mcp_agent.config.yamlファイルに依存するため 47、このファイルがGitHub Actionsランナーに存在する必要があります。リポジトリにチェックインするか、ワークフローのステップで動的に生成することができます。ファイル内の機密情報は、GitHub Secretsからテンプレート化して入力する必要があります。アーキテクチャには複数のライブラリ（OpenAI SDK -> MCP Extension -> mcp-agent）が関与しており 47、強力な抽象化を提供する一方で、管理する依存関係が増え、レイヤー間で問題が発生した場合のデバッグが複雑になる可能性があります。MCPサーバーとネイティブエージェントツールからのツールを単一のリストに自動集約する機能 47 は、エージェントのツール使用ロジックを簡素化し、エージェントは統一された機能セットを参照できます。

3.6. Agent-MCP Framework (rinadelph/Agent-MCP)

Agent-MCPは、MCPを利用した協調作業のためのマルチエージェントシステムを構築するためのPythonフレームワークです 48。専門エージェントによる並行作業を目的として設計されています。

MCP利用：
エージェント間のコミュニケーションとコンテキスト共有のためにフレームワークの中核としてMCPが使用されます 48。Admin AgentがWorker Agentを調整する構造です。
GitHub Actionsにおける課題と考慮事項：

• ローカルMCPサーバー依存： mcp_template.main（またはagent_mcp.cli）というMCPサーバーが実行中である必要があります 48。GitHub Actionsでは、このサーバーをランナー内でバックグラウンドプロセスとして起動する必要があります。
• SQLiteデータベース（.agent/mcp_state.db）： 管理/ワーカーのトークン、プロジェクトコンテキスト、エージェントの知識を保存します 48。これはエフェメラルなランナーでは大きな永続性の課題となります。GitHub ActionsアーティファクトとしてDBファイルをアップロード/ダウンロードする戦略 50 が必要になりますが、大規模/アクティブなDBでは遅延や制限に直面する可能性があります。
• 対話的な初期化： エージェントの初期化（管理者およびワーカー）は、AIコーディングアシスタント（例：Cursor、Claude）へのプロンプトを介して記述されています 48。これはヘッドレスなGitHub Actions環境には直接変換できません。これらの初期化ステップを自動化するには、カスタムクライアントスクリプトが必要になります。
• トークン管理： 管理トークンはSQLite DBから取得されます 48。これをスクリプトで自動化することは可能ですが、追加のステップが必要です。
• Docker化の可能性： 提供された情報にはAgent-MCPのDocker化に関する具体的な記述はありませんでしたが 48、一般的なActionsでのDocker利用 57 はサーバーとエージェントをコンテナ化する可能性を示唆しますが、ランナー上でのSQLiteの永続性とコンテナ間通信は依然として慎重な設計が必要です。

Agent-MCPの現在の設計は、ローカルサーバー、重要な状態を保持するSQLite DB、エージェントのブートストラップのための対話型AIアシスタントへの依存性 48 から、典型的なエフェメラルでヘッドレスなGitHub Actionsワークフローでの直接的な即時利用には不向きです。大幅な再設計または複雑なラッパースクリプトが必要となるでしょう。GitHub Actionsランナーは通常ステートレスでジョブは短命ですが、Agent-MCPは永続的なMCPサーバープロセスと状態・トークン・コンテキストのためのローカルSQLiteファイルを必要とし、エージェント初期化は対話的です。これらの各コア設計側面はGitHub Actionsの性質と衝突し、サーバーライフサイクル、状態永続性（アーティファクトなど、制限あり）、エージェント制御のための非対話型クライアントの回避策が必要です。
また、マルチエージェント（Admin/Worker）協調モデル 48 は強力ですが、管理すべき複雑性のレイヤーを追加します。GitHub Actionsの文脈では、複数のエージェントプロセス（直接実行する場合）の起動と通信を調整したり、他の場所でホストされているマルチエージェントシステムとの対話を管理したりすることは、単一エージェント設定よりも複雑になります。
Agent-MCPは、アーキテクチャ理解のためにMain Context Document (MCD) を使用し、プロジェクトコードベース内のソフトウェア開発タスクに重点を置いているように見えます 48。これはエージェントの有効な使用法ですが、ユーザーのクエリはGitHub Actions統合に関するより一般的なものであり、MCDを介して統合されない限り、GitHub Actionsワークフロー自体の管理や他のCI/CDツールのMCP経由でのオーケストレーションといった、直接的なコード変更を超えたタスクを含む可能性があります。

4. MCP対応エージェントによるGitHub Actionsの操作

MCP対応AIエージェントがGitHub Actionsランナー上で動作し、GitHub Actionsのワークフロー自体を管理・操作するシナリオは、特定のMCPサーバーを利用することで実現可能です。これらのサーバーは、GitHub APIの機能をMCPツールとして公開し、エージェントがこれらのツールを介してGitHubリソースやワークフローと対話できるようにします 6。

4.1. GitHub特化型MCPサーバーの概要

GitHub特化型MCPサーバーは、AIエージェント（MCPクライアント）とGitHub APIとの間のブリッジとして機能します。これにより、エージェントは自然言語の指示に基づいて、リポジトリの管理、issueの追跡、プルリクエストの処理、そしてGitHub Actionsワークフローの管理といったタスクを実行できるようになります。

4.2. 主要なGitHub MCPサーバー

現在利用可能な主要なGitHub関連MCPサーバーには、以下のようなものがあります。

• ko1ynnky/github-actions-mcp-server （およびそのフォークと思われる devopsier/github-actions-mcp）：
  • 主にGitHub Actionsワークフローの管理に特化しており、AIアシスタント（Claude Desktop, Codeium, Windsurfなどが言及されている 6）がワークフローを操作できるようにします。
  • 提供されるツールには、listWorkflows、getWorkflow、triggerWorkflow（ワークフローのトリガー）、cancelWorkflowRun、listWorkflowRuns、getWorkflowRunJobsなどが含まれます 6。
  • Node.jsベースであり、インストールにはリポジトリのクローン、npm install、npm run buildが必要です 6。
  • AIアシスタント（MCPクライアント）側で、このサーバーを起動するコマンドと、認証用のGITHUB_PERSONAL_ACCESS_TOKENを設定する必要があります 6。
  • devopsier/github-actions-mcp 57 はDocker化されており、GitHub Actionsランナー上でこのMCPサーバーをDockerコンテナとして実行し、同じランナー上のエージェントから接続する構成が考えられます。
• 公式GitHub MCPサーバー (github/github-mcp-server)：
  • GitHub Copilotコーディングエージェントによって内部的に使用されるほか 9、他のMCPクライアントからも利用可能です 13。
  • issue、プルリクエスト、リポジトリ、コードセキュリティなど、より広範なGitHub機能に関するツールを公開します 13。
  • --toolsetsフラグまたはGITHUB_TOOLSETS環境変数により、利用可能な機能群（ツールセット）を選択的に有効化/無効化できます 13。
  • 動的なツール発見もサポートしています 13。

4.3. シナリオ：ランナー上のエージェントによるGitHub Actionsの管理

このシナリオでは、GitHub Actionsランナー上でAIエージェント（MCPクライアント）とGitHub特化型MCPサーバーの両方を実行し、エージェントが現在のワークフローや他のリポジトリのワークフローを操作します。

設定：

1. GitHub Actionsワークフローのジョブが開始されます。
2. ランナー環境がセットアップされます（例：PydanticAIやOpenAI SDKベースのエージェントの場合はPython環境）。
3. GitHub特化型MCPサーバー（例：devopsier/github-actions-mcpをDockerコンテナとして、またはko1ynnky/github-actions-mcp-serverをNode.jsプロセスとして）が、同じランナー上でバックグラウンドプロセスまたはサービスコンテナとして起動されます。このMCPサーバーには、GITHUB_TOKEN（ジョブに自動的に付与されるトークン）またはより権限の強いパーソナルアクセストークン（PAT）が認証用に提供されます。
4. AIエージェントのスクリプト（MCPクライアント）が実行されます。

対話：

1. エージェントスクリプトは、ローカルで実行されているMCPサーバーに接続するように設定されます（例：localhost:port経由、またはstdioがサポートされていればそれ経由）。
2. エージェントは、ワークフローの入力、イベントペイロード、またはスクリプト内にハードコードされた指示を受け取ります。
3. 指示例： 「プルリクエストがmainブランチにマージされたら、ワークフロー ‘deploy-production.yml’ をトリガーせよ。」
4. エージェントは、LLMの推論を通じて、GitHub MCPサーバーのtriggerWorkflowツールを使用する必要があると判断します。
5. MCP経由でtriggerWorkflowツールを呼び出し、owner、repo、workflowId、refなどのパラメータを提供します。
6. MCPサーバーは、提供されたトークンを使用してこの要求をGitHub API呼び出しに変換し、実行します。

この構成により、ランナー上でMCPクライアント（AIエージェント）とMCPサーバー（例：GitHub Actions用）の両方を実行することで、強力で自己完結型の自動化ループが形成されます。エージェントはワークフローから指示を受け、ローカルMCPサーバーが提供するツールを使用して外部環境（GitHub自体など）と対話し、その結果に基づいてさらなるアクションを実行できます。これらすべてが1つのジョブ内で完結します。
この設定のセキュリティは最優先事項です。GitHub Actions MCPサーバーが強力なPATを使用し、エージェントがアクションを実行するよう指示する場合、エージェントまたはその指示メカニズムの脆弱性が悪用される可能性があります。MCPサーバーにデフォルトのGITHUB_TOKENを使用するとスコープは制限されますが、機能も制限される可能性があります 6。したがって、MCPサーバーのトークンに対する最小権限の原則が重要となり、公開するツールに必要な権限とのバランスを取る必要があります。
ランナー上でローカルにMCPサーバーを実行することは利点がありますが、ワークフローのセットアップの複雑性が増します。Node.js/Dockerのインストール、サーバーのバックグラウンドでの起動、クライアントが接続試行する前にサーバーが準備完了であることの確認、ログとシャットダウンの管理などが必要です 6。これは、エージェントが外部で既に実行中のMCPサーバーを呼び出すだけの場合よりも複雑です。

5. GitHub Actionsにおけるデプロイと運用上の考慮事項

5.1. MCPサーバーの実行戦略

GitHub Actionsランナー上でMCPクライアントとして機能するAIエージェントを運用する際、エージェントが対話するMCPサーバーの実行場所は重要な検討事項です。

• ランナーローカルでの実行：
  • 直接プロセス： MCPサーバー（例：Node.jsベースのサーバー 6 やPython製MCPサーバー 61）をワークフローのステップでバックグラウンドプロセスとして起動します（例：コマンド末尾に&を付与）。サーバーのライフサイクル管理が課題となります。
  • Dockerコンテナ： MCPサーバーがDocker化されていれば（例：devopsier/github-actions-mcp 57）、ランナー上でDockerコンテナとして実行します。エージェントもコンテナ内で実行されるか、ホスト上で実行される場合、Dockerネットワーキングを介したクライアント・サーバー間通信を設定します。
  • 利点： 外部依存性がなく、通信が高速である可能性があります。
  • 欠点： ランナーのセットアップが複雑になり、ランナーのリソースを消費し、ライフサイクルがジョブに束縛されます。
• リモートMCPサーバーの利用：
  • ランナー上のエージェントは、外部でホストされているMCPサーバー（例：AWS、Cloudflare、または専用ホスト上）に接続します。
  • 利点： サーバーは永続的で独立して管理でき、複数のエージェントやワークフローで共有可能です。
  • 欠点： ネットワーク遅延、MCPサーバーを公開する際のセキュリティ考慮事項、ランナーからサーバーへの認証が必要です。

MCPサーバーをランナーローカルで実行するかリモートで実行するかの決定は、トレードオフを伴います。ローカル実行はネットワークセキュリティを簡素化しますが、ランナーのセットアップと状態管理を複雑にします。リモート実行はランナーのジョブを簡素化しますが、MCPサーバー用の外部インフラの管理とセキュリティ確保が必要です。選択は、MCPサーバーの性質（軽量でステートレスか、重量でステートレスか）、セキュリティ要件、既存のインフラに依存します。

5.2. エフェメラルランナー上のエージェントの状態管理

GitHub Actionsランナーは通常ステートレスですが、多くのAIエージェントは会話履歴やコンテキスト維持のために何らかの状態管理を必要とします。

• GitHub Actions Artifacts： SQLiteデータベースを必要とするPythonエージェント（例：仮にAgent-MCPをランナーで実行する場合）では、ジョブ開始時にSQLite DBファイルをダウンロードし、終了時にアップロードすることで状態を維持できます 50。これは小規模なDBには有効ですが、サイズや頻度には制限があります。特定のユースケースでは、GitHub Actionsアーティファクト 50 は、スケジュールされたワークフローや手動トリガーされるワークフローの実行間で単純な状態（Agent-MCP用の小さなSQLite DBや設定ファイルなど）を永続化するための「十分に良い」状態解決策となり得ます。これは、非常に同時実行性が高い、または急速に変化する状態にはあまり適していません。
• 外部状態ストア： エージェントフレームワークがサポートしているか、適合可能であれば、外部データベース（Redis、PostgreSQLなど）やクラウドストレージ（S3など）を使用します。
• 入力駆動型の状態： タスクが自己完結型であれば、各実行に必要なすべてのコンテキストをエージェントスクリプトへの入力として渡します。
• プラットフォーム固有のソリューション： Cloudflare AgentsやAmazon Bedrock Agentsを使用する場合、それぞれDurable Objects 35 やBedrockのメモリ機能 26 といったプラットフォーム固有の状態/メモリ管理ソリューションを利用できます。

5.3. 認証情報とAPIキーの安全な取り扱い

機密情報の管理は、GitHub ActionsでAIエージェントを運用する上で最も重要な側面の一つです。

• GitHub Secrets： LLM APIキー、MCPサーバー認証トークン、AWS/Cloudflare認証情報など、すべての機密情報はGitHubの暗号化されたSecretsに保存します 7。
• 環境変数： ワークフロー内でSecretsを環境変数としてアクセスします（例：env: OPENAI_API_KEY: $）。
• OpenID Connect (OIDC)： AWSのようなクラウドプロバイダーに対しては、長期的なアクセスキーの代わりに、OIDCを使用して短期的なロールベースの認証情報を取得します 8。
• 最小権限の原則： トークンと認証情報には、タスク実行に必要な最小限の権限のみを付与します。

5.4. ロギング、モニタリング、デバッグ

AIエージェントの動作を理解し、問題を特定するためには、効果的なロギングとモニタリングが不可欠です。

• 標準出力： ランナー上で実行されるエージェントスクリプトやMCPサーバーは、GitHub Actionsのログにキャプチャされるように、標準出力/標準エラー出力にログを出力すべきです。
• トレース有効化： Bedrock Agentsでは、enableTrace=trueを設定することで、エージェントの詳細な推論プロセスを取得できます 29。
• 専用監視ツール： PydanticAIはLogfireと統合されています 1。LangFuseもLLMの可観測性のための選択肢です 64。これらのツールは外部サービスへのデータ送信を伴う場合があります。
• GitHub Actionsデバッグロギング： Actionsのデバッグロギング（ACTIONS_STEP_DEBUGシークレット）を有効にすると、より詳細なワークフロー実行ログが得られます。

エージェントがより自律的になり、その意思決定プロセス（LLMの推論）が複雑になるにつれて、堅牢なロギングと可観測性 7 は、単に望ましいだけでなく、重要なCI/CDパイプライン内でのデバッグと信頼性のために不可欠です。「エージェント失敗」という結果だけでは不十分であり、その理由を追跡する必要があります。Logfire、Langfuse、Bedrockのトレース有効化などのツールは、この可視性を提供します。このようなツールがなければ、自動化されたGitHub Actionsフローにおけるエージェントの動作のデバッグは非常に困難になります。

6. 比較分析と戦略的推奨事項

6.1. AIエージェントフレームワークの比較（GitHub ActionsおよびMCP連携）

以下の表は、本レポートで調査した主要なAIエージェントフレームワークとプラットフォームを、GitHub Actionsでの利用とMCPクライアント機能の観点から比較したものです。

この比較から、組織は利用可能なエージェント機能の「構築か購入か」というスペクトラムに直面していることがわかります。GitHub Copilotのようなすぐに利用できる製品を選ぶか、BedrockやCloudflareのようなマネージドインフラを提供するフレームワークを利用するか、あるいはPydanticAIやOpenAI SDKのようなライブラリでよりカスタムなソリューションを構築するか、その選択は制御の度合い、コスト、開発努力に影響します。

6.2. GitHub Actions MCPサーバーツールの概要

(この内容はセクション4.2.で詳述されていますが、戦略的推奨事項の文脈で再掲します。)
AIエージェントがGitHub ActionsランナーからGitHubのワークフローやリポジトリ自体を操作するためには、GitHub APIをMCPツールとして公開するサーバーが必要です。

6.3. 適切なAIエージェントソリューションの選択指針

最適なAIエージェントソリューションの選択は、以下の要因を総合的に考慮して行うべきです。

• タスクの性質： コード生成、CI/CDオーケストレーション、データ分析など、エージェントに何をさせたいか。
• 既存インフラ： AWS中心、Cloudflare中心、あるいは自己完結型のランナーソリューションを好むか。
• チームのスキルセット： Python、Node.js、Dockerなどの専門知識。
• 状態管理の必要性： ステートレスタスクか、会話メモリや永続的なコンテキストが必要なタスクか。
• セキュリティとコンプライアンス要件： データ管理、ネットワークアクセス、トークン管理に関する規定。
• 複雑性の許容度： 単純なスクリプトで済むか、複数コンポーネントからなる分散システムを許容できるか。

シナリオ別推奨：

• GitHubタスク自動化を最小限の外部インフラで実現したい場合： GitHub Copilot Agent（プログラム制御が進化すれば）またはPythonベースのエージェント（PydanticAI、OpenAI SDK）をランナー上で直接実行し、ローカルGitHub MCPサーバーと組み合わせる。
• 既存のAWS/Cloudflare投資を活用したい場合： Bedrock AgentsまたはCloudflare Agentsを、ランナーから指示する形で利用する。
• 複雑なマルチエージェントワークフローが必要な場合（ただし課題あり）： Agent-MCPは、ランナーでのデプロイ課題を克服できるか、外部でホストしてランナーから指示する場合に検討可能。

6.4. 堅牢で安全な統合のためのベストプラクティス

AIエージェントをGitHub Actionsに統合する際には、以下のベストプラクティスを遵守することが推奨されます。

• 最小権限の原則： すべてのトークンとパーミッションに対して最小権限を適用します。
• 安全なシークレット管理： GitHub Secretsを最大限に活用します。
• 入力検証： エージェントに渡すプロンプトやデータに対して、入力検証とサニタイズを徹底します。
• べき等性： 可能な限り、エージェントのアクションはべき等になるように設計します（CI/CDのリトライにおいて重要）。
• 包括的なロギングとモニタリング： エージェントの動作と決定を追跡可能にします。
• サンドボックス化の検討： 可能であれば、MCPサーバーやエージェントの実行環境をサンドボックス化します。
• 定期的なレビューと更新： エージェントの依存関係やMCPサーバーの設定を定期的にレビューし、更新します。

AIエージェントがCI/CDやDevOpsに不可欠な要素となるにつれて、MLOpsに似た新しい規律、おそらく「AgentOps」とでも呼ぶべきものが必要になるでしょう。これは、本番自動化におけるAIエージェントのライフサイクル管理、モニタリング、セキュリティ、ガバナンスを包含します。エージェントは新しいタイプのコンポーネント（LLM、MCPサーバー、エージェントロジック）を自動化ワークフローに導入し 4、これらは独自の故障モード、セキュリティリスク、パフォーマンス特性を持つため、従来のDevOpsプラクティスをこれらのAI特有の側面を管理するために適応させる必要があります。これは、AIエージェントを大規模かつ安全に運用するための専門的なプラクティスとツールの必要性を示唆しています。

7. 結論と今後の展望

7.1. 主要な調査結果のまとめ

本調査により、MCP対応AIエージェントをGitHub Actionsランナー上で実行またはランナーから指示するための複数のアプローチが存在することが明らかになりました。

• GitHub Copilot AgentはGitHub Actions上でネイティブに動作しMCPを利用できますが、現状ではワークフローからの直接的なプログラム制御よりもissue割り当てやチャットを通じた指示が主です 9。
• PydanticAIやOpenAI Agents SDK with MCP ExtensionのようなPythonベースのフレームワークは、ランナー上で直接スクリプトとして実行しやすく、柔軟なカスタマイズが可能です 7。
• Amazon Bedrock AgentsやCloudflare AI Agentsは、それぞれのクラウドプラットフォーム上で動作するマネージドエージェントであり、GitHub ActionsからはAPIやHTTPリクエストを通じて指示されます 25。これらは既存のクラウド投資を活用する場合に適しています。
• Agent-MCP Frameworkは高度なマルチエージェント協調を提供しますが、ローカルMCPサーバーとSQLiteデータベースへの依存性から、現状のままではGitHub Actionsのヘッドレス環境への統合には大きな課題があります 48。
• GitHub Actionsのワークフロー自体を操作するためには、GitHub特化型MCPサーバー（例：ko1ynnky/github-actions-mcp-serverや公式のgithub/github-mcp-server）をランナー上で起動し、エージェントからローカル接続する構成が有効です 6。

状態管理、認証情報の安全な取り扱い、そしてMCPサーバーの実行戦略（ランナーローカルかリモートか）が、いずれのアプローチにおいても重要な考慮事項となります。

7.2. CI/CDにおけるAIエージェントの進化するランドスケープ

AIエージェントとCI/CDの統合はまだ発展途上にありますが、その将来性は非常に大きいと言えます。

MCPの標準化とエコシステムの成熟 65 が進むにつれて、より洗練されたエージェント機能とCI/CDプラットフォームとのより容易な統合が期待されます。GitHub Actionsのような宣言的でバージョン管理されたワークフローシステムからエージェントに指示を出すという現在のニーズは、GitOpsの原則とも合致しています。将来的には、エージェントの振る舞いやタスク割り当てが、命令的なスクリプトではなく、Gitでバージョン管理された宣言的な設定によって行われるようになるかもしれません。これにより、DevOpsにおけるAI駆動型タスクが、より堅牢で管理しやすいパラダイムの下に置かれる可能性があります。

完全な自律性が目標である一方で、実際のCI/CD統合では、完全に自動化されたエージェントタスクから、GitHub Copilotのプルリクエストのように人間の承認を必要とする変更を提案するエージェント 9、あるいは問題発生時にワークフローから対話的に照会できるエージェントまで、人間の監視のスペクトラムが存在する可能性があります。タスクの重要度や複雑性に応じて最適な自律性と人間による介入のレベルが異なるため、柔軟なエージェント設計の必要性が示唆されます。

AIが複雑なソフトウェア開発や運用タスクの自動化において果たす役割はますます増大し、それに伴い、エージェントの自律性が高まる中でのセキュリティと責任あるAIの実践の重要性も一層高まるでしょう。この進化する分野において、開発者と運用チームは、これらの新しいツールとパラダイムを効果的かつ安全に活用するための知識とスキルを継続的に更新していく必要があります。

引用文献

1. Model Context Protocol (MCP) - PydanticAI, 5月 25, 2025にアクセス、 https://ai.pydantic.dev/mcp/
2. What is Model Context Protocol (MCP)? - IBM, 5月 25, 2025にアクセス、 https://www.ibm.com/think/topics/model-context-protocol
3. Model Context Protocol (MCP): A comprehensive introduction for developers - Stytch, 5月 25, 2025にアクセス、 https://stytch.com/blog/model-context-protocol-introduction/
4. Model Context Protocol - Wikipedia, 5月 25, 2025にアクセス、 https://en.wikipedia.org/wiki/Model_Context_Protocol
5. What you need to know about the Model Context Protocol (MCP) - Merge.dev, 5月 25, 2025にアクセス、 https://www.merge.dev/blog/model-context-protocol
6. GitHub Actions MCP server for AI agents - Playbooks, 5月 25, 2025にアクセス、 https://playbooks.com/mcp/github-actions
7. A Fun PydanticAI Example For Automating Your Life, 5月 25, 2025にアクセス、 https://christophergs.com/blog/pydantic-ai-example-github-actions
8. Custom Amazon Bedrock Agent Action · Actions · GitHub …, 5月 25, 2025にアクセス、 https://github.com/marketplace/actions/custom-amazon-bedrock-agent-action
9. GitHub Copilot: Meet the new coding agent, 5月 25, 2025にアクセス、 https://github.blog/news-insights/product-news/github-copilot-meet-the-new-coding-agent/
10. GitHub Introduces Coding Agent For GitHub Copilot, 5月 25, 2025にアクセス、 https://github.com/newsroom/press-releases/coding-agent-for-github-copilot
11. Extending Copilot coding agent with the Model Context Protocol (MCP) - GitHub Docs, 5月 25, 2025にアクセス、 https://docs.github.com/en/copilot/customizing-copilot/extending-copilot-coding-agent-with-mcp
12. Extending Copilot coding agent with the Model Context Protocol (MCP) - GitHub Docs, 5月 25, 2025にアクセス、 https://docs.github.com/en/enterprise-cloud@latest/copilot/customizing-copilot/extending-copilot-coding-agent-with-mcp
13. GitHub’s official MCP Server, 5月 25, 2025にアクセス、 https://github.com/github/github-mcp-server
14. About assigning tasks to Copilot - GitHub Docs, 5月 25, 2025にアクセス、 https://docs.github.com/en/copilot/using-github-copilot/using-copilot-coding-agent-to-work-on-tasks/about-assigning-tasks-to-copilot
15. GitHub Copilot documentation - GitHub Docs, 5月 25, 2025にアクセス、 https://docs.github.com/en/copilot
16. What is GitHub Copilot? - GitHub Docs, 5月 25, 2025にアクセス、 https://docs.github.com/en/copilot/overview-of-github-copilot/about-github-copilot-individual
17. Getting started with the REST API - GitHub Docs, 5月 25, 2025にアクセス、 https://docs.github.com/en/rest/overview/api-previews#github-copilot-api-preview
18. 1月 1, 1970にアクセス、 https://docs.github.com/en/copilot/github-copilot-enterprise/overview-of-github-copilot-enterprise#copilot-in-the-cli-and-for-ci-cd-automation
19. 1月 1, 1970にアクセス、 https://docs.github.com/en/copilot/overview-of-github-copilot/about-github-copilot-enterprise
20. 1月 1, 1970にアクセス、 https://docs.github.com/en/copilot/overview-of-github-copilot/about-github-copilot-enterprise#copilot-in-the-cli-and-for-ci-cd-automation
21. Agent mode 101: All about GitHub Copilot’s powerful mode - The GitHub Blog, 5月 25, 2025にアクセス、 https://github.blog/ai-and-ml/github-copilot/agent-mode-101-all-about-github-copilots-powerful-mode/
22. Agent mode and MCP support for Copilot in JetBrains, Eclipse, and Xcode now in public preview - The GitHub Blog, 5月 25, 2025にアクセス、 https://github.blog/changelog/2025-05-19-agent-mode-and-mcp-support-for-copilot-in-jetbrains-eclipse-and-xcode-now-in-public-preview/
23. AI Agents with MCP: Practical Takeaways from n8n and GitHub Copilot - Xebia, 5月 25, 2025にアクセス、 https://xebia.com/blog/ai-agents-with-mcp/
24. A Practioner’s Guide to PydanticAI Agents - Association of Data Scientists, 5月 25, 2025にアクセス、 https://adasci.org/a-practioners-guide-to-pydanticai-agents/

25. Harness the power of MCP servers with Amazon Bedrock Agents

    AWS Machine Learning Blog, 5月 25, 2025にアクセス、 https://aws.amazon.com/blogs/machine-learning/harness-the-power-of-mcp-servers-with-amazon-bedrock-agents/

26. Automate IT operations with Amazon Bedrock Agents

    AWS Machine Learning Blog, 5月 25, 2025にアクセス、 https://aws.amazon.com/blogs/machine-learning/automate-it-operations-with-amazon-bedrock-agents/

27. Actions for Amazon Bedrock Agents using AWS SDKs, 5月 25, 2025にアクセス、 https://docs.aws.amazon.com/bedrock/latest/userguide/service_code_examples_bedrock-agent_actions.html
28. 1月 1, 1970にアクセス、 https://docs.aws.amazon.com/bedrock/latest/userguide/agents-invoke.html
29. InvokeAgent - Amazon Bedrock, 5月 25, 2025にアクセス、 https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_InvokeAgent.html
30. 1月 1, 1970にアクセス、 https://aws.amazon.com/blogs/machine-learning/build-a-generative-ai-application-on-aws-using-amazon-bedrock-agents-and-functions-in-amazon-opensearch-service/
31. invoke_agent - Boto3 1.35.6 documentation - AWS, 5月 25, 2025にアクセス、 https://boto3.amazonaws.com/v1/documentation/api/1.35.6/reference/services/bedrock-agent-runtime/client/invoke_agent.html
32. invoke_agent - Boto3 1.38.21 documentation - AWS, 5月 25, 2025にアクセス、 https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/bedrock-agent-runtime/client/invoke_agent.html
33. SessionState - Amazon Bedrock, 5月 25, 2025にアクセス、 https://docs.aws.amazon.com/bedrock/latest/APIReference/API_agent-runtime_SessionState.html
34. amazon-bedrock-samples/agents-and-function-calling/bedrock-agents/features-examples/03-create-agent-with-return-of-control/03-create-agent-with-return-of-control.ipynb at main · aws-samples/amazon-bedrock-samples - GitHub, 5月 25, 2025にアクセス、 https://github.com/aws-samples/amazon-bedrock-samples/blob/main/agents-and-function-calling/bedrock-agents/features-examples/03-create-agent-with-return-of-control/03-create-agent-with-return-of-control.ipynb
35. Piecing together the Agent puzzle: MCP, authentication …, 5月 25, 2025にアクセス、 https://blog.cloudflare.com/building-ai-agents-with-mcp-authn-authz-and-durable-objects/
36. Agents API - Cloudflare Docs, 5月 25, 2025にアクセス、 https://developers.cloudflare.com/agents/api-reference/agents-api/
37. Skip the setup: deploy a Workers application in seconds - The Cloudflare Blog, 5月 25, 2025にアクセス、 https://blog.cloudflare.com/deploy-workers-applications-in-seconds/
38. Write Cloudflare Workers in Python, 5月 25, 2025にアクセス、 https://developers.cloudflare.com/workers/languages/python/
39. GitHub Actions - Workers - Cloudflare Docs, 5月 25, 2025にアクセス、 https://developers.cloudflare.com/workers/ci-cd/external-cicd/github-actions/
40. Auth with headers · Cloudflare Workers docs, 5月 25, 2025にアクセス、 https://developers.cloudflare.com/workers/examples/auth-with-headers/
41. 1月 1, 1970にアクセス、 https://community.cloudflare.com/t/triggering-worker-from-github-action-using-api-token/215835
42. 1月 1, 1970にアクセス、 https://community.cloudflare.com/t/best-way-to-call-a-worker-from-a-github-action/592089
43. 1月 1, 1970にアクセス、 https://community.cloudflare.com/t/triggering-a-worker-from-github-actions-with-a-secret-token/315097
44. Building an MCP server with OAuth and Cloudflare Workers - Stytch, 5月 25, 2025にアクセス、 https://stytch.com/blog/building-an-mcp-server-oauth-cloudflare-workers/
45. Build and deploy Remote Model Context Protocol (MCP) servers to Cloudflare, 5月 25, 2025にアクセス、 https://blog.cloudflare.com/es-la/remote-model-context-protocol-servers-mcp/
46. How to Build and Hosting Remote MCP Servers on Cloudflare - Hugging Face, 5月 25, 2025にアクセス、 https://huggingface.co/blog/lynn-mikami/remote-mcp-cloudflare
47. lastmile-ai/openai-agents-mcp: An MCP extension package for OpenAI Agents SDK - GitHub, 5月 25, 2025にアクセス、 https://github.com/lastmile-ai/openai-agents-mcp
48. rinadelph/Agent-MCP: Agent-MCP is a framework for … - GitHub, 5月 25, 2025にアクセス、 https://github.com/rinadelph/Agent-MCP
49. Agent MCP Server - UBOS.tech, 5月 25, 2025にアクセス、 https://ubos.tech/mcp/agent-mcp-server/
50. Storing and sharing data from a workflow - GitHub Docs, 5月 25, 2025にアクセス、 https://docs.github.com/actions/using-workflows/storing-workflow-data-as-artifacts
51. How I Saved Scraped Data in an SQLite Database on GitHub - Jerry Ng, 5月 25, 2025にアクセス、 https://jerrynsh.com/how-i-saved-scraped-data-in-an-sqlite-database-on-github/
52. 1月 1, 1970にアクセス、 https://github.com/rinadelph/Agent-MCP/issues?q=is%3Aissue+github+actions
53. 1月 1, 1970にアクセス、 https://github.com/rinadelph/Agent-MCP/tree/main/docs
54. 1月 1, 1970にアクセス、 https://github.com/rinadelph/Agent-MCP/tree/main/.github/workflows
55. Issues · rinadelph/Agent-MCP - GitHub, 5月 25, 2025にアクセス、 https://github.com/rinadelph/Agent-MCP/issues
56. Actions · rinadelph/Agent-MCP - GitHub, 5月 25, 2025にアクセス、 https://github.com/rinadelph/Agent-MCP/actions
57. devopsier/github-actions-mcp: A GitHub Actions integration powered by the MCP. This server exposes structured tools to manage GitHub issues, pull requests, and repositories through natural language interfaces and autonomous agents. - GitHub, 5月 25, 2025にアクセス、 https://github.com/devopsier/github-actions-mcp
58. Docker AI Agent and Model Context Protocol (MCP) Server - Working Together, 5月 25, 2025にアクセス、 https://dev.to/docker/docker-ai-agent-and-model-context-protocol-mcp-server-working-together-4c4l
59. ko1ynnky/github-actions-mcp-server, 5月 25, 2025にアクセス、 https://github.com/ko1ynnky/github-actions-mcp-server
60. OpenAI API Compatibility Issue: Missing additionalProperties: false in Tool Parameter Schemas #376 - GitHub, 5月 25, 2025にアクセス、 https://github.com/github/github-mcp-server/issues/376

61. MCP Server in Python — Everything I Wish I’d Known on Day One

    DigitalOcean, 5月 25, 2025にアクセス、 https://www.digitalocean.com/community/tutorials/mcp-server-python

62. prayanks/mcp-sqlite-server: These are MCP server implementations for accessing a SQLite database in your MCP client. There is both a SDIO and a SSE implementation. - GitHub, 5月 25, 2025にアクセス、 https://github.com/prayanks/mcp-sqlite-server
63. Use InvokeAgent with an AWS SDK - Amazon Bedrock, 5月 25, 2025にアクセス、 https://docs.aws.amazon.com/bedrock/latest/userguide/bedrock-agent-runtime_example_bedrock-agent-runtime_InvokeAgent_section.html
64. Integration with Pydantic AI · langfuse · Discussion #5036 - GitHub, 5月 25, 2025にアクセス、 https://github.com/orgs/langfuse/discussions/5036

65. How to Use Model Context Protocol the Right Way

    Boomi, 5月 25, 2025にアクセス、 https://boomi.com/blog/model-context-protocol-how-to-use/