GitHub Copilot MCPの設定例と26回の実API呼び出しで作る、競合SNSの週次レポート

B2B SaaS企業のプロダクトマーケターは、毎週月曜日に同じ依頼を受けることがよくあります。依頼の内容はシンプルで、主な競合3社が先週何を投稿したかです。私たちは2026年11月6日、シンガポール時間（SGT）の00:17から00:38にかけて、このレポートのデータ部分を構築しました。Notion、ClickUp、Asanaを対象に、EveryInfra APIを26回実際に呼び出しました。

最初に1つ制約をお伝えします。私たちのテスト環境にはCopilotのサブスクリプションがありません。本記事のCopilotの設定、Issue、ワークフローは、GitHubのドキュメントに基づく設定例であり、Copilot上では実行していません。計測した数値はすべて、EveryInfra APIの実際のレスポンスから得たものです。

10月30日から11月5日までの1週間で、ClickUpはYouTube、TikTok、Instagramに14件投稿しました。Asanaは3件、Notionは2件でした。

本記事の方法では、GitHub Copilotのコーディングエージェントを1回だけ使います。エージェントはMCP経由で実際のレスポンスをいくつか読み、そのうえでシンプルなPythonスクリプトとスケジュール実行のワークフローを書きます。プルリクエストをマージした後は、GitHub Actionsが毎週スクリプトを実行し、モデルは二度と動きません。カタログ価格で計算すると、3ブランド×4プラットフォームの費用は週$0.011961、月あたり約$0.0518です。

本記事が扱う課題は限定的です。毎週月曜日の朝、リポジトリにMarkdownのレポートを置きたいとします。レポートには、各競合が4つのプラットフォームに投稿した内容、最も反応のよかった投稿、投稿頻度の変化を載せます。このレポートのコードはGitHub Copilotに書かせたいものの、AIモデルに毎週データを探させたくはありません。

本記事のGitHubに関する情報はすべて、2026年11月6日に閲覧したGitHub Changelogまたはdocs.github.comに基づいています。EveryInfraの数値はすべて、保存した実際のAPIレスポンスから得たものです。

結論：GitHub Copilot MCPの役割を2つに分ける

このレポートで最も多い失敗は、2つの作業を混同することです。1つはコードを書く作業、もう1つは毎週データを収集する作業です。2026年10月28日、GitHubはこの2つの作業にそれぞれ対応する機能をリリースしました。

まず、コネクタとリポジトリのMCP設定により、Copilotは作業中に外部ツールを呼び出せるようになります。次に、Copilot Automationsに新しいツール、トリガー、コスト管理機能が追加されます（自動化ツール、トリガー、コスト管理に関する変更履歴）。Automationsを使うと、Copilotをスケジュール実行できます。

Copilotに毎週データを収集させてレポートを書かせると、実行のたびにクラウドエージェントのセッションが始まります。Automationsのドキュメントによると、各実行でAIクレジットとActionsの実行時間（分）を消費します（Copilot automationsのドキュメント、課金のセクション）。決まった形式の週次レポートに、モデルの判断は必要ありません。そのため、モデルを動かすのはコードを書くときの1回だけにすることをおすすめします。

ワークフローはシンプルです。ルール、ハンドル、テスト例を記載したIssueを作成し、Copilotにアサインします。エージェントはコードを書く前に、EveryInfraのMCPツールでカタログを読み、3〜4回のテスト呼び出しを行います。

エージェントは実際のフィールド名と日付形式を確認したうえで、weekly_report.pyと.github/workflows/weekly-report.ymlを書き、レビュー用のプルリクエストを作成します。マージ後は、スケジュール実行されるActionsのジョブがPOST /api/v1/socialを送信し、Markdownファイルを生成してコミットします。

次の表は、レポートを実行する2つの方法を比較したものです。内容はGitHubのドキュメントに基づいています。左の列が私たちの推奨する方法です。

30クレジットという値は、オートメーションの作成時に設定できる1回の実行あたりの上限の最小値です（オートメーション作成のドキュメント）。AIクレジット1つは$0.01に相当します（個人向けの従量課金）。一般的な実行で何クレジットを使うかはドキュメントに書かれていないため、推測はしません。確実に言えることは単純です。Actionsのスクリプト方式なら、毎週のAIクレジット消費はゼロです。2つの方式を組み合わせることもできます。毎週の数値はスクリプトで出し、ときどきCopilotに4週分のレポートを読ませて短い分析を書かせる、という使い方です。

それでもCopilotに毎週実行させたい場合は、オートメーションを使います。オートメーションはリポジトリのMCP設定にあるツールを使えるため、この記事のJSONもそのまま使えます。トリガーと課金のルールはCopilotオートメーションのドキュメントに記載されています。オートメーションを有効にする前に、1回の実行あたりと1週間あたりのAIクレジット上限を設定してください。

10月28日の変更履歴で何が変わったのか

2026年10月28日の変更履歴の投稿を読んで「github copilot mcp」と検索する人が多くいます。投稿のタイトルは「Connect your tools to Copilot without all the setup」です。この投稿では、GitHubが検証したMCPサーバー（コネクタとも呼ばれます）がパブリックプレビューとして発表されました。サービスを選び、ログインして、アクセスを承認するだけです。するとコネクタは、Copilotアプリ、Copilot CLI、VS Code、クラウド上のCopilot、GitHub Mobileで使えるようになります（変更履歴の投稿）。提供開始時点の対象は26サービスで、Slack、Figma、Notion、Sentry、Linear、Atlassian Rovo、Cloudflare、Vercel、Work IQなどが含まれます。

投稿ではプランについても触れています。ロールアウトの対象はすべてのCopilotプランです。Copilot BusinessとEnterpriseでは、管理者が「Editor preview features」ポリシーを有効にする必要があります。企業がMCPの許可リストを使っている場合は、管理者がこれらのサービスを許可リストに追加する必要もあります。提供開始に合わせて立てられたコミュニティのスレッドに、ユーザーの質問がまとまっています（GitHub Communityのディスカッション211002）。

今回の提供開始は、このレポートに3つの点で関係します。第1に、EveryInfraは26のコネクタに含まれておらず、GitHubによる検証も受けていません。EveryInfraのデータを使うには、リポジトリのMCP設定か個人のMCP設定にサーバーを追加します。どちらの方法でも、短いJSONブロックを自分で書きます。

第2に、コネクタのドキュメントによると、コネクタはローカルセッションとクラウドサンドボックスのセッションで動作します。GitHub Actions上で実行されるセッションでは、まだ動作しません（Copilotコネクタのドキュメント）。たとえば、IssueをCopilotにアサインしたときに始まるセッションがこれに当たります。リポジトリのMCP設定のページでも、冒頭で同じ注意書きが繰り返されています（リポジトリのMCP設定のドキュメント）。

第3に、製品名です。今でも「Copilot coding agent」と呼ぶ人は多くいます。docs.github.comでは、同じ機能の名前が現在「Copilot cloud agent」になっています（クラウドエージェントについて）。coding agentのMCPに関する旧リンクを開くと、新しいページに移動します。この記事では、2つの名前は同じ機能を指します。

Copilot coding agentのMCP設定：リポジトリ設定に書くJSON

リポジトリのMCP設定は、リポジトリページでSettings、Copilot、MCP serversの順に開いて追加します。形式は1つのmcpServersオブジェクトです。各キーがサーバー名になります。各サーバーにはtypeキーとtoolsキーが必須です。リモートサーバーにはurlも必要で、認証が必要なサーバーではheadersを使います。ヘッダーの値では、名前がCOPILOT_MCP_で始まるシークレットを$COPILOT_MCP_API_KEYまたは${COPILOT_MCP_API_KEY}の形で参照できます（リポジトリのMCP設定のドキュメント）。

ドキュメントでは、toolsには特定の読み取り専用ツールだけを列挙するよう強く推奨しています。理由は明確で、エージェントは事前に確認せず自らツールを呼び出すからです。EveryInfraのリモートMCPエンドポイントはhttps://api.everyinfra.com/mcpです。OAuthではなくBearerキーを使うため、ドキュメントがサポートする方式に合っています。設定例は次のとおりです。

{
  "mcpServers": {
    "everyinfra": {
      "type": "http",
      "url": "https://api.everyinfra.com/mcp",
      "headers": {
        "Authorization": "Bearer ${COPILOT_MCP_EVERYINFRA_API_KEY}"
      },
      "tools": [
        "everyinfra_list_capabilities",
        "everyinfra_call_api",
        "everyinfra_get_job"
      ]
    }
  }
}

なぜツールを3つに絞るのでしょうか。00:16（SGT）にキーなしでtools/listを送信し、00:26（SGT）にキー付きで再度送信しました。どちらも16,247バイトのレスポンスで、12個のツールが列挙されていました。

レポートに必要なのは、そのうち3つです。カタログを読むツール、呼び出しを行うツール、非同期ジョブを読むツールです。残りの9つは、残高の確認、チャージ用リンクの作成、サポートチケットの起票、CAPTCHAの解決を行うツールです。これらはレポートの役に立ちません。許可リストに入れても、エージェントが誤った動きをする余地が増えるだけです。

12個のツールには、それぞれMCPのannotationsがあります。実際のレスポンスを見ると、ドキュメントには書かれていない点が1つ分かります。everyinfra_call_apiは課金が発生しうるため、readOnlyHint: falseとdestructiveHint: trueになっています。GitHubのドキュメントによると、Copilotのコードレビューが使うのは、tools/listでannotations.readOnlyHintがtrueに設定されたツールだけです。このアノテーションがないツールやfalseのツールは、コードレビューではスキップされます。そのため、同じリポジトリ設定でも、クラウドエージェントはEveryInfraのデータツールを呼び出せますが、Copilotのコードレビューは呼び出せません。

この結果は、このレポートにとって好都合です。コードレビューでデータにお金を使うべきではないからです。コードレビューですべてのMCPツールをスキップさせたい場合の設定も、ドキュメントに用意されています。アノテーションのフィールドは、MCP仕様のツールのセクションで説明されています（MCP仕様：ツール）。

セットアップに関わる制限が、ほかに2つあります。第1に、クラウドエージェントとコードレビューが対応しているのはMCPツールだけです。サーバーのリソースやプロンプトには対応していません。このレポートはツールしか使わないため、ここではこの制限は問題になりません。

第2に、設定の確認方法に関する制限です。IssueをCopilotにアサインし、セッションログを開いて「Start MCP Servers」ステップを探します。このステップの最後に、起動したツールが一覧表示されます。

あるRedditユーザーは、coding agent向けにAtlassianのMCPサーバーを設定したところ、接続には成功したものの「retrieved 0 tools」と表示されました（r/GithubCopilotのスレッド）。この表示が出た場合は、まずtools内の各ツール名を、tools/listで返る名前と照合してください。名前は完全に一致している必要があります。

シークレットの置き場所：2つのキーと2つの引き出し

多くのセットアップがつまずくのは、このステップです。GitHubには現在、クラウドエージェント専用のシークレット種別としてAgentsシークレットがあります。Actions、Codespaces、Dependabotのシークレットと並ぶ種別です。ドキュメントによると、クラウドエージェントはActions、Codespaces、Dependabotのシークレットや変数を読み取れません。読み取れるのはAgentsシークレットだけです。

名前がCOPILOT_MCP_で始まるAgentsシークレットは、MCPサーバーにだけ渡されます。エージェントが実行するコマンドの環境変数にはなりません（クラウドエージェントのシークレットと変数）。定期実行のワークフローはActionsシークレットを使い、Agentsシークレットは読めません。そのため、このレポートにはキーが2つ必要です。

同じドキュメントには、さらに3つのルールがあります。第1に、シークレット名はGITHUB_で始めることができません。第2に、Agentsの種類にはシークレットと変数がありますが、クラウドサンドボックスでエージェントが受け取るのはシークレットだけで、変数は受け取りません。第3に、COPILOT_MCP_プレフィックスのないAgentsシークレットは、エージェントが実行するコマンドやツールの環境変数になります。

そのため、エージェントにネットワークアクセスを使ってスクリプトを実行させたい場合を除き、EveryInfraのキーをプレフィックスなしで追加しないでください。組織レベルのAgentsシークレットは、複数のリポジトリで共有できます。複数のリポジトリで競合を追跡しているチームには便利な方法です。

両方の用途に、同じ名前のキーを1つだけ使えばよいのではないでしょうか。そうしない理由は3つあります。第1に、GitHubは2つの引き出しを分けているため、名前を1つにしても意味がありません。第2に、分かりやすい名前を付けたEveryInfraのキーを2つ使えば、リクエストログが読みやすくなります。どちらかのキーが漏えいしたり使いすぎたりした場合に、どちらのキーなのかが分かります。

第3に、GitHubのプッシュ保護がデフォルトでブロックするのは、既知の形式のキーだけです。EveryInfraのキーはその対象に含まれません（プッシュ保護の変更履歴）。エージェントがキーをテストファイルに書き込んでも、プッシュが止まらない可能性があります。そのため、キーは環境変数からのみ読み込むことをIssueに明記してください。

ファイアウォールにも、もう1つ落とし穴があります。デフォルトでは、ファイアウォールがクラウドエージェントのネットワークを制限します。ドキュメントによると、ファイアウォールが適用されるのは、エージェントがBashツールで起動したプロセスです。MCPサーバーのプロセスには適用されません（ファイアウォールのドキュメント、制限事項）。

そのため、EveryInfraへのMCP呼び出しは動作します。しかし、エージェントがセッション内で新しいweekly_report.pyを実行しようとすることがあります。その場合、api.everyinfra.comへのリクエストはファイアウォールで止まり、プルリクエストの本文に警告が表示されます。

選択肢は2つあります。第1に、Internet accessのカスタム許可リストにapi.everyinfra.comを追加し、エージェントのコマンド用にCOPILOT_MCP_プレフィックスのない3つ目のキーを追加する方法です。第2に、実際のMCPレスポンスを1つフィクスチャとして保存するようエージェントに指示する方法です。こうすれば、テストはフィクスチャを読み込み、ネットワークを使いません。

おすすめは第2の方法です。第1の方法では、エージェントのコマンド環境にキーが入ります。ドキュメントにはログでシークレットの値がマスクされるとありますが、わざわざそのリスクを負う必要はありません。

エージェント向けIssueの書き方

GitHubのベストプラクティスのページでは、Copilotに渡すタスクには、問題、受け入れ条件、変更するファイルを明記するよう勧めています。小さく明確なタスクが最もうまくいきます（Copilotタスクのベストプラクティス）。このレポートで最も重要なのは、ハンドルの一覧とテストの例です。ハンドルをエージェントに推測させないでください。

私たちのテストでは、推測した3つのハンドルはいずれも空のリストを返しました。エラーも課金もなく、レポートから1件が気づかないうちに消えていました。Issueの例は次のとおりです。

## Task
Write weekly_report.py and .github/workflows/weekly-report.yml.
Every Monday at 09:00 Asia/Singapore, read config/competitors.yml.
For each brand, collect posts from last Monday 00:00 to Sunday 23:59 UTC.
Write reports/<ISO year>-W<week>.md and commit it to main.

## Data (check parameters with everyinfra_list_capabilities, then make one test call each)
- YouTube: youtube/user_posts, param url (channel link), since=last Monday, mode=async
- TikTok: tiktok/user_videos, param username, limit=30
- Instagram: instagram/user_posts, param username, limit=30, mode=async
- LinkedIn: linkedin/company_posts, param company (the part after /company/), limit=20

## Handles (do not change, do not guess; LinkedIn names are not checked yet)
notion:  youtube https://www.youtube.com/@Notion | tiktok notionhq | instagram notionhq | linkedin notionhq
clickup: youtube https://www.youtube.com/@ClickUpProductivity | tiktok clickup | instagram clickup | linkedin clickup-app
asana:   youtube https://www.youtube.com/channel/UC2BoogM0AqwOJyoSp1S4ClQ | tiktok asana | instagram asana | linkedin asana

## Must handle
1. TikTok: drop is_pinned=true rows, then filter by posted_at. Do not stop at the first old row.
2. YouTube posted_at can be relative text such as "1d ago". Convert it from the fetch time.
3. HTTP 503 or status=failed: wait retry_after, retry once, then write "not collected this week".
4. Zero rows: write "0 this week" and list the handle at the end of the report for a manual check.
5. Read the key only from the EVERYINFRA_API_KEY environment variable. Never write it to a file.
6. Tests read JSON fixtures in tests/fixtures/ (real MCP responses). Tests use no network.

## Test example
With the fixtures, ClickUp TikTok this week = 4 posts (not 0, not 7), total views = 60463.

最後の行は、このIssueで最も重要な行です。期待値は、SGT 00:19時点でClickUpについて取得した実際のtiktok/user_videosレスポンスに基づいています。10件のうち最初の3件は2024年のピン留め動画で、再生回数はそれぞれ20.1百万回、7.5百万回、3.2百万回でした。リストは新しい順に並びますが、ピン留め動画は常に先頭に表示されます。

この並び順が原因で、3通りの誤った答えが生まれます。第1に、最初の1件を最新の投稿とみなすスクリプトは、ClickUpがTikTokに最後に投稿したのは2024年だと判断します。第2に、新しい順に読み、期間より古い最初の1件で止まるスクリプトは、投稿数を0件と数えます。第3に、ピン留め動画を除外しても日付で絞り込まないスクリプトは、7件と数えます。

正しい答えは4件です。この数値をIssueに書いておけば、テストを1回実行するだけでコードが正しいかどうかが分かります。コードを1行ずつ読む必要はありません。

実際の1往復：Copilotが送るリクエストと返ってくるレスポンス

私たちはCopilotを実行していません。しかし、MCPはオープンなプロトコルです。エージェントがツールを呼び出すときは、Streamable HTTPトランスポート上で標準的なJSON-RPCのtools/callリクエストを1つ送信します。各メッセージは1回のHTTP POSTです。

クライアントはapplication/jsonとtext/event-streamの両方を受け付ける必要があります（MCP仕様：トランスポート）。そのため、エージェントと同じリクエストをcurlで送り、サーバーが何を返すかを確認できます。2026年11月6日00:26:28（SGT）に、次のリクエストを送信しました。

curl -s https://api.everyinfra.com/mcp \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call",
       "params":{"name":"everyinfra_call_api",
                 "arguments":{"platform":"tiktok","action":"user_videos",
                              "params":{"username":"notionhq","limit":5}}}}'

サーバーは31.1秒後にHTTP 200を返しました。result.content[0].textフィールドには、13,272文字のJSON文字列が入っていました。NotionのTikTok動画5件が含まれ、それぞれにposted_at、view_count、like_count、is_pinnedなどがありました。最新の動画は2026年5月26日のもので、再生回数は22,800回でした。

レスポンス末尾のbillingには、charged: trueとcharged_usd: 0.000556が示されていました。エージェントも、コードを書く前に同じデータを確認します。そこからフィールド名とISO形式の日付を把握し、このアカウントが5か月を超えてTikTokに投稿していないことも知ります。

先に26回の実際の呼び出しでレポートを作成

エージェントにスクリプトを書かせる前に、正解を用意しておく必要があります。そこで2026年11月6日00:17〜00:38（SGT）に、先に自分たちでレポートを作成しました。対象期間は、UTCで10月30日から11月5日までの7日間です。各機能とそのパラメータは、無料のカタログGET /api/v1/social/catalogから取得しています。使用した4つの機能は、youtube/user_posts（必須：url、任意：sinceとsort）、tiktok/user_videos（必須：username）、instagram/user_posts（必須：username、カタログ上は非同期）、linkedin/company_posts（必須：company）です。各機能のページはYouTubeのユーザー投稿、TikTokのユーザー動画、Instagramのユーザー投稿、LinkedInの企業投稿です。

この表は週次レポートの中核で、3つのことがわかります。第1に、3ブランドの投稿頻度は大きく異なります。ClickUpは1週間に3つのプラットフォームで14件を投稿しました。Instagramでは、最新10件の投稿のうち7件が今週のものです。TikTokでは4件、YouTubeでは3件を投稿しています。

第2に、NotionとAsanaはTikTokへの投稿をほぼ止めています。TikTokの最新動画は、それぞれ2026年5月26日と2026年6月4日のものです。Asanaは最新10件のうち7件が6月のその1日に投稿されたもので、残り3件は2025年と2023年のものです。「今週0件」という結果は有用なシグナルです。ただし、ハンドルが正しいとわかっている場合に限ります。ハンドルが間違っていても0件になるからです。

第3に、今週3ブランドすべてが投稿したプラットフォームはInstagramだけです。1つのプラットフォームしか監視できない場合、この表からはInstagramが有力な候補になります。

この結果には限界があります。対象期間は1週間、サンプルは3ブランドです。TikTokとInstagramは、それぞれ10件を取得しました。ClickUpのInstagramでは、10件で9日分をカバーしていました。

SaaSチームなら、通常はこれで十分です。消費者向けブランドでは事情が異なります。limitは、各アカウントの投稿頻度に合わせる必要があります。これらの機能は件数ではなく呼び出しごとに課金されるため、limitを大きくしても追加費用はかかりません。

今週のデータで作ったサンプルレポート

件数だけでは不十分です。マーケティングチームは、どの投稿が最も反応を得たか、その内容は何だったかも知りたいはずです。下の表は、実際のレスポンスをもとに手作業で作成したサンプルレポートです。エージェントが出力すべき形式として、そのままIssueに貼り付けられます。

ブランドとプラットフォームごとに、最も反応を得た投稿を示しています。TikTokではピン留め動画を除外しています。Instagramはいいね数順、YouTubeは再生数順です。YouTubeの日付は取得時点で「1d ago」「5d ago」から変換しているため、精度は日単位です。

このサンプルからは、件数だけではわからないことが2つ見えてきます。第1に、ClickUpはTikTokでオフィスネタのユーモアを使っています。今週の4件の投稿（2026-11-05、2026-11-04、2026-11-02、2026-10-30）は、合計で再生数60,463、いいね3,392でした。トップ投稿の再生数は27,400です。

対象期間の前日の10月29日には、再生数145,200の投稿がありました。このアカウントは、週に1回ほど大きなヒットを出しているようです。レポートが「実行時点から過去7日間」というスライディングウィンドウを使う場合、こうしたヒットがレポートに入ったり外れたりすることがあります。

第2に、3ブランドとも今ではAIについて発信しています。今週唯一のNotionのYouTube動画は、ChatGPTやClaudeをNotionに接続する方法を紹介しています。ClickUpのYouTube動画は、3本ともAIがテーマです。10月30日には、ClickUpがInstagramの週次まとめで新しいSalesforce MCPに触れていました。対象期間の2日前の10月28日には、AsanaがInstagramでAIアシスタント「Dash」を宣伝しています。自社もコラボレーションソフトウェアを販売しているなら、投稿数よりも「何について発信したか」の列のほうが役立つことがあります。

いいね数を比較するには、母数も必要です。ClickUpのInstagramでは7件の投稿に合計273件のいいねが付き、1投稿あたり1〜73件でした。Asanaでは3件の投稿に合計82件、Notionでは1件の投稿に143件のいいねが付きました。Notionの投稿は、ClickUpのどの投稿よりも多くのいいねを獲得しています。

投稿数ではClickUpがInstagramでリードしているように見えますが、1投稿あたりのいいね数ではNotionが上回っています。そこでレポートには、投稿数、エンゲージメント合計、1投稿あたりのエンゲージメント中央値の3列を入れることをおすすめします。4列目にはトップ投稿を加えます。4列とも、レスポンスにすでに含まれるフィールドからスクリプトで計算でき、追加の呼び出しも追加費用も不要です。

実際の呼び出しで見つかった6つの落とし穴と、スクリプトでの対処法

実際の呼び出し26回のうち、半数は課金されませんでした。結果をグループに分けて整理しました。課金されたのは13回です。5回は結果が空で、返金されました。このうち4回は、ハンドルの推測が間違っていました。残る1回は正しいAsanaのチャンネルでしたが、その週は新しい動画がありませんでした。

7回は503を返しました。内訳は、LinkedIn company postsの呼び出し6回と、タイムアウトしたYouTubeの同期呼び出し1回です。1回は、誤ったパラメータで422を確認する計画的なテストです。失敗した呼び出しで課金されたものはありません。課金額の合計は$0.007228で、ちょうど13 × $0.000556です。

失敗の各グループは、スクリプトのそれぞれの部分に対応しています。Issueの「必ず対処すること」リストは、この表から作っています。

2つ目の落とし穴は、もう少し詳しく説明します。データを返したかタイムアウトした同期呼び出し8回について、最初のレスポンスまでの時間を計測しました。503を返したLinkedInの6回は2.2〜2.4秒、422の1回は0.2秒で返ってきたため、グラフからは除外しています。TikTokの3回は22.2秒、68.9秒、21.6秒、MCP経由の呼び出しは31.1秒でした。正しいハンドルでのYouTube呼び出しは11.5秒です。

ハンドルが間違っていたYouTube呼び出しは、空のリストを返すまでに40.3秒かかりました。別の呼び出しは、89.8秒後に503を返しています。エラーメッセージによると、同期呼び出しの待機時間は最大85秒です。ClickUpのTikTok呼び出しは68.9秒で、この上限まで16秒しか余裕がありませんでした。

Actionsでは待ち時間が長くても問題ありませんが、タイムアウトすると呼び出しを送り直す必要があります。そのため、カタログで許可されている場合は非同期モードを使います。ジョブを送信する呼び出しは、すぐにjob_idを返します。その後、スクリプトは数秒ごとにGET /api/v1/jobs/{job_id}を呼び出します。ジョブの読み取りは無料です。

5つ目の落とし穴はLinkedInです。00:18〜00:38（SGT）に、linkedin/company_postsはNotion、ClickUp、Asana、そしてエラーメッセージに例として示されていた企業googleに対して、503を6回返しました。エラーコードはunavailableで、どのレスポンスもbilling.charged_usdは0でした。3回目の失敗の後、next_stepsには、10分間に3回の呼び出しが課金なしで失敗したと書かれていました。そのうえで、サンプルリクエストで1回呼び出すよう提案していました。サンプルも失敗した場合は当社側の問題なので、チケットを作成する前にユーザーに確認するよう案内していました。

同じ時間帯でも、linkedin/company_profileは動作していました。00:34（SGT）にはNotionの企業ページを6.2秒で読み取り、$0.000556が課金されました。レスポンスには、フォロワー数1,137,647、従業員数7,211が含まれていました。投稿の取得に失敗する週でも、LinkedInの列ではフォロワー数の変化を示せます。

その夜も、カタログではcompany postsが利用可能と表示されていました。そのため、スクリプトはカタログだけを信頼せず、503を処理する必要があります。「今週はLinkedInを収集できませんでした」と書かれたレポートのほうが、黙って列を落としたレポートより優れています。失敗した呼び出しの返金の仕組みと確認方法については、失敗時の返金照合ガイドを参照してください。

スクリプトの完成形：エージェントが返すべきワークフロー

エージェントからのプルリクエストには、少なくとも2つのファイルが含まれている必要があります。以下に、ワークフロー設定の例を示します。主なルールは、GitHub Actionsのドキュメントに基づいています。scheduleはデフォルトでUTCを使いますが、現在はIANA名でtimezoneを指定できます。最短間隔は5分です。毎時0分には、スケジュール実行が遅れることがあります。

高負荷時には、キューに入った実行の一部が破棄されることがあります。そのため、ドキュメントでは毎時0分以外の時刻を指定するよう推奨しています。スケジュール実行は、デフォルトブランチでのみ動作します。パブリックリポジトリでは、60日間アクティビティがないとスケジュールされたワークフローが無効になります（「events that trigger workflows, schedule」）。cronの5つのフィールドは、「POSIX crontab specification」に従います。

name: weekly-competitor-social-report
on:
  schedule:
    - cron: "17 9 * * 1"          # Monday 09:17, not on the hour
      timezone: "Asia/Singapore"
  workflow_dispatch: {}
permissions:
  contents: write
concurrency: weekly-report
jobs:
  report:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Build report
        env:
          EVERYINFRA_API_KEY: ${{ secrets.EVERYINFRA_API_KEY }}
        run: python weekly_report.py --config config/competitors.yml --out reports/
      - name: Commit report
        run: |
          git config user.name "weekly-report-bot"
          git config user.email "weekly-report-bot@users.noreply.github.com"
          git add reports/
          git commit -m "weekly social report" || echo "nothing to commit"
          git push

スクリプトに必要なメイン関数は1つです。この関数はリクエストを送信します。ステータスがrunningなら、job_idでポーリングします。503を受け取ったら、retry_afterの時間だけ待ってからもう1回試します。

最後に、取得したデータか「未収集」マーカーを返します。以下は、テストをもとにしたスケルトンです。フィールド名はカタログのresponse_fieldsと一致しているので、参考としてそのままIssueに貼り付けられます。

import os, time, json, urllib.request, urllib.error

API = "https://api.everyinfra.com"
KEY = os.environ["EVERYINFRA_API_KEY"]          # read only from the environment

def call(platform, action, params, mode="sync"):
    body = {"platform": platform, "action": action, "params": params}
    if mode == "async":
        body["mode"] = "async"
    for attempt in (1, 2):
        req = urllib.request.Request(API + "/api/v1/social", json.dumps(body).encode(),
              {"Authorization": "Bearer " + KEY, "Content-Type": "application/json",
               "User-Agent": "weekly-report/1.0"})
        try:
            data = json.load(urllib.request.urlopen(req, timeout=100))
        except urllib.error.HTTPError as e:
            err = json.load(e).get("error", {})
            if e.code == 503 and attempt == 1:
                time.sleep(err.get("retry_after", 60)); continue
            return {"unavailable": True, "code": e.code, "reason": err.get("code")}
        while data.get("status") in ("submitting", "running", "finalizing"):
            time.sleep(8)
            job = urllib.request.Request(f"{API}/api/v1/jobs/{data['job_id']}",
                  headers={"Authorization": "Bearer " + KEY, "User-Agent": "weekly-report/1.0"})
            data = json.load(urllib.request.urlopen(job, timeout=60))
        if data.get("status", "succeeded") != "succeeded":   # job failed: mark it, never report it as 0 rows
            return {"unavailable": True, "status": data.get("status"), "reason": data.get("error")}
        if "results" not in data:                              # success without results: raise
            raise RuntimeError(f"no results field: {platform}/{action}")
        return {"rows": data["results"], "count": len(data["results"])}

User-Agentヘッダーに注目してください。サイト保護ルールの中には、Pythonのデフォルトのユーザーエージェントをブロックするものがあります。わかりやすいユーザーエージェントを設定しておけば、Actionsのログで原因不明の403に悩まされずに済みます。timeout=100は、サーバー側の上限85秒より少し長くしてあります。そのため、タイムアウト時にはクライアント側の切断ではなく、retry_after付きのサーバーの503を受け取れます。

最も重要なのは、最後の2つのチェックです。非同期ジョブがsucceeded以外のstatusで終了した場合、関数はunavailableマーカーを返し、レポートには「今週は未収集」と表示されます。ジョブが成功してもresultsフィールドがない場合、関数はエラーを送出し、Actionsのステップは失敗（赤）になります。レポートに「今週の投稿0件」と表示されるのは、呼び出しが実際に成功して空のリストが返った場合だけです。この2つのチェックがないと、サービス側の障害が「競合が投稿をやめた」と報告されてしまいます。これは週次レポートで起こりうる最悪の誤りです。

プルリクエストで確認すべき5つのポイント

エージェントがプルリクエストを返してきても、Pythonを1行ずつ読む必要はありません。確認するのは5点で、それぞれ数分で済みます。第1に、secrets.EVERYINFRA_API_KEYがデータ取得ステップのenvにのみ現れることを確認します。echoで出力されていないこと、ファイルに書き込まれていないことも確認します。GitHubはログ内のシークレット値をマスクしますが、ファイルにコミットされた値はマスクしません（「using secrets in GitHub Actions」）。

第2に、tests/fixtures/にあるサンプルJSONファイルを開きます。これらはエージェントがMCPの呼び出しで保存した実際のレスポンスでなければならず、フィールド名も本記事のフィールド表と一致している必要があります。エージェントが自分でサンプルを書いた場合、テストは自分のコードをなぞるだけになります。第3に、テストの例が本物のテストになっているかを確認します。ClickUpのTikTokは、今週の投稿が4件、再生数が60463です。この数字は実際のレスポンスから得たもので、エージェントが変更することはできません。コードはこの数字と一致する必要があります。

第4に、失敗時の処理を確認します。503では1回待ってからリトライします。status: failedでは「未収集」と記録します。0件の場合は、そのハンドルを「ハンドル要確認」リストに追加します。422ではリトライしません。

どれか1つでも欠けていれば、プルリクエストを差し戻します。第5に、エージェントのプルリクエストに対するワークフローは、書き込み権限を持つ人が「Approve and run workflows」をクリックしてはじめて実行されます。workflow_dispatchで1回実行し、Actionsのログで各呼び出しの所要時間と課金額を確認してから、マージします。EveryInfraのコンソールのリクエストログと各課金額を照合することもできます。失敗した呼び出しは、課金なしと表示されます。

カタログ価格で見る週あたり・月あたりのAPIコスト

コストは、EveryInfraのAPI利用料とGitHub側の費用の2つです。当社の利用料は、カタログにある各機能のprice_usdで決まります。これらの機能は呼び出しごとに課金されます。1件を返す呼び出しも、30件を返す呼び出しも料金は同じです。失敗した呼び出しと空の結果には課金されません。料金はEveryInfraの料金ページでも確認できます。

3ブランドの費用は週$0.011961です。52週を12か月で割ると、月あたり約$0.0518になります。対象を増やしても費用は小さいままです。10ブランドで月約$0.1728、30ブランドで約$0.5183、100ブランドで約$1.7277です。今週の実際の実行では、これよりさらに安く済みました。

YouTubeの課金は2回でした。Asanaの呼び出しが空の結果になり、返金されたためです。TikTokとInstagramはそれぞれ3回課金されました。LinkedInは3回失敗し、課金はありませんでした。課金された呼び出しは合計8回で、$0.004448です。

GitHub側の費用は3つあります。2つは明確ですが、3つ目は範囲しか示せません。第1に、Actionsの実行時間です。GitHubホストの標準ランナーは、パブリックリポジトリでは無料です。プライベートリポジトリでは、プランに毎月含まれるコンピューティング枠を使います。GitHub Freeは$12、GitHub ProとTeamは$18です。標準のLinuxランナーは1分あたり$0.006です（GitHub Actionsの課金）。

実測した時間では、12回の呼び出しを順番に実行すると約5分かかり、プライベートリポジトリでは週約$0.03になります。スクリプトがすべての非同期ジョブを先に送信し、まとめてポーリングすれば、実行は1〜2分で済むこともあります。第2に、Copilotのプランの費用です。たとえば、Copilot Proは月$10でAIクレジット1,500、Pro+は月$39でAIクレジット7,000です（Copilotのプラン）。

第3に、スクリプトを書く1回のセッションで使うAIクレジットです。この数値はモデルとセッションの長さによって変わります。ドキュメントには典型的な値の記載がなく、私たちはCopilotを実行していないため、数値は示しません。実際の値はCopilotの使用状況ページで確認できます。

フィールド：プラットフォームごとに返るデータが異なる

このレポートは4つのプラットフォームを比較します。いちばん難しいのは、フィールドが一致しないことです。カタログには機能ごとにresponse_fieldsが記載されています。実際のレスポンスを1つずつこれと照合したところ、レポートの列に影響する違いが3つ見つかりました。第1に、その夜に5アカウントから取得したInstagram user_postsの50件には、どれにもview_countがありませんでした。カタログのfield_noteにも、一部のInstagramリクエストではview_count、is_comments_disabled、author_follower_count、top_commentsが返らないと書かれています。こうしたリクエストで返る投稿は最大48件です。そのためInstagramの列では、いいね数とコメント数は比較できますが、再生数は比較できません。

第2に、カタログにはYouTube user_postsのフィールドが25個記載されていますが、テストでチャンネル一覧から返ったのは14個だけでした。view_count、title、durationはありましたが、like_count、comment_count、is_paid_partnershipはなく、posted_atは相対表記のテキストでした。第3に、TikTok user_videosには35個のフィールドがありました。情報量は最も多いものの、データ容量も最も大きくなります。

この表もIssueに含めてください。どのプラットフォームに再生数があるかを、エージェントに推測させてはいけません。InstagramとLinkedInの再生数の列には「n/a」と表示すること、エンゲージメントはいいね数とコメント数の合計で比較することを伝えてください。エージェントは実際のレスポンスを読めば違いの大半に気づきますが、表がIssueにあれば推測する必要はまったくありません。

Claude CodeやChatGPTの記事との違い

ブログには関連する記事が4本あります。TikTokのブランドアカウントを追うClaude Codeサブエージェント、ChatGPTのスケジュールタスクで作る週次の需要レーダー、Codex Cloudで作るレビュー週次レポート、ChatGPT Spacesで作る競合SNSトラッカーです。ChatGPTに毎週レポートそのものを作らせたい場合は、スケジュールタスクの記事をお読みください。

この記事の主な違いは1点です。AIが働くのはコードを書く1回だけで、その後は通常のスクリプトが毎週実行されます。利点は、形式が安定すること、毎週のモデル費用がかからないこと、失敗したときにActionsのログで原因を確認しやすいことです。その代わり、プルリクエストのレビューが1回必要になり、ブランドやプラットフォームを追加するときは設定の変更が必要です。動画が伸びた理由など、毎週の考察がレポートに必要なら、ChatGPTの方法が向いています。スクリプトで数値を出し、1か月分のレポートをCopilotに読ませて分析を書かせる方法もあります。

各プラットフォームの公式APIを使わない理由

各プラットフォームに開発者向けAPIがあるのに、なぜEveryInfraが必要なのかという疑問はもっともです。ほとんどのプラットフォームAPIでは、他社の公開コンテンツを読むのが簡単ではないからです。下の表の各行は、各プラットフォーム自身の開発者ドキュメントに基づいています。

このレポートの一部には、YouTube Data APIがよく合います。YouTubeだけを追跡するなら、直接使ってください。4つのプラットフォームを扱う場合は、4種類の認証、4つのクォータ、4つのレスポンス形式を管理しなければなりません。エージェントが書くスクリプトにも4つの分岐が増えます。EveryInfraでは、4つのプラットフォームを1つのリクエスト形式、1つの課金モデル、1組のエラーコードで扱えます。

そのため、スクリプトに必要なのはcall()関数1つだけです。各プラットフォームで取得できるデータの詳細は、YouTubeデータAPIとTikTokデータAPIをご覧ください。InstagramデータAPIとLinkedInデータAPIもあわせてご覧ください。LinkedInの企業投稿を取得できない場合は、LinkedInの企業プロフィール機能でフォロワー数の列を埋められます。

制限と注意点

第1に、プロンプトインジェクションのリスクがあります。レポートは競合の投稿テキストを読み、そのテキストはMCPを通じてエージェントのコンテキストに入ります。OWASPはこのリスクを間接プロンプトインジェクションと呼んでいます（OWASP LLM01：プロンプトインジェクション）。Webページやファイルなど外部ソースのコンテンツが、モデルの挙動を変えてしまうというものです。GitHubのリスクに関するページによると、GitHubはIssueやコメント内の隠し文字をフィルタリングします（クラウドエージェントのリスクと対策）。そのため、HTMLコメントはエージェントに届きません。

ただし、この説明はMCPツールの結果に含まれる投稿テキストには当てはまりません。この記事の方法なら、リスクを下げられます。エージェントがサンプルを数件読むのは、コードを書くときだけです。週次レポートはスクリプトが生成し、スクリプトが投稿テキストを指示として実行することはありません。また、ツールを3つに限定した許可リストにより、インジェクションを受けたエージェントにできることも限られます。

第2に、エージェントの権限です。ドキュメントによると、クラウドエージェントがプッシュできるのは自身のcopilot/ブランチだけです。そのプルリクエストは、人がレビューしてマージする必要があります。エージェントは、プルリクエストを準備完了にすることも、承認することも、マージすることもできません。エージェントのプルリクエストでのワークフローは、書き込み権限を持つ人が「Approve and run workflows」をクリックして初めて実行されます。そのため、エージェントが作ったワークフローが、レビュー前にAPI予算を使うことはありません。

第3に、Actionsのスケジュールは正確なアラームではありません。ドキュメントによると、毎時0分前後の実行は遅れることがあり、負荷が高いときには実行が破棄されることもあります。そのため、データの期間は「実行時刻から7日前まで」ではなく、「先週月曜日から先週日曜日まで」にする必要があります。そうしないと、1時間の遅延で1時間分のデータが失われます。パブリックリポジトリでは、60日間アクティビティがないと、スケジュールされたワークフローが停止します。レポートを毎週コミットすれば、それがアクティビティとして数えられます。

第4に、私たち自身の対象範囲です。読むのは公開コンテンツだけで、公開ブランドアカウントの投稿、動画、エンゲージメント数が対象です。非公開アカウント、広告費、オーディエンスデータは読めません。その夜のLinkedInの障害は、実際に起きた例です。

スクリプトはこうした欠落に対応する必要があり、レポートにもその旨を記載しなければなりません。なお、GitHubとEveryInfraの間に取引関係はありません。この記事では、公開されているGitHubのMCP設定を使って、EveryInfraの公開APIに接続しているだけです。

最近の変更点

• 2026年10月28日：GitHubは、GitHubが検証したMCPサーバー（コネクタ）を26サービスでパブリックプレビューとして公開し、すべてのCopilotプランへの順次提供を始めました（変更履歴）。影響：SlackやNotionなどのサービスを1ステップで接続できるようになりました。ただし、サードパーティのデータAPIには引き続きリポジトリのMCP設定が必要で、Actionsのセッションではコネクタはまだ使えません。
• 2026年10月28日：Copilot AutomationsでカスタムMCPサーバーのツールを使えるようになり、GitHubイベントトリガー24種、GitHubツール20種、実行ごと・日ごと・週ごと・月ごとのAIクレジット上限が追加されました（変更履歴）。リポジトリのオーナーに課金される共有Automationsも同日から順次提供が始まり（共有Automationsの変更履歴）、VS Codeからクラウド上のAutomationsを管理できるようになりました（VS Code Automationsの変更履歴）。影響：Copilotを毎週実行できるようになりましたが、実行ごとにクレジットを消費するため、まず上限を設定してください。
• 2026年10月28日：Copilotが1つにつながったクラウド体験になりました。セッションはデフォルトでクラウドサンドボックス内で実行され、プランに含まれるActionsの枠は、ランナーとクラウドサンドボックスで共有するドル建ての枠になりました（変更履歴）。影響：レポートのワークフローの実行時間とエージェントのサンドボックス時間は、同じ枠から消費されます。プライベートリポジトリでは合計に注意してください。
• 2026年10月28日：GitHub Agentic Workflowsが一般提供になりました。タスクをMarkdownで書くと、Copilotやほかのコーディングエージェントを使えるActionsのYAMLにコンパイルされます（変更履歴、プロジェクトページ）。ワークフローのロックファイルも一般提供になり、actions/checkoutなどのアクションを特定のコミットに固定できます（ロックファイルの変更履歴）。影響：レポートのワークフローで使うアクションを固定すれば、依存関係が知らないうちに変わるのを防げます。
• 2026年10月27日：GitHub Copilotが、Organization上のGitHub Appsによるサーバー間認証にパブリックプレビューとして対応しました（変更履歴）。Copilot SDKで構築したサービスは、サインインしたユーザーなしでCopilotを呼び出せ、費用はOrganizationが支払います。影響：今後、チームのサービスがOrganizationの予算内でCopilotを使い、週次レポートを読めるようになります。
• 2026年10月22日：Copilotの使用状況メトリクスAPIで、カスタムMCPサーバー、スキル、カスタムエージェントが名前付きで一覧表示されるようになりました（変更履歴）。表示されるのは種類ごとに最大25件です。影響：Organizationの管理者は、everyinfra MCPサーバーが実際に使われているかを確認できます。

FAQ

GitHub CopilotのMCP設定はどこに置きますか？mcp.jsonと同じですか？

この質問は、検索候補の「github copilot mcp configuration」と「github copilot mcp.json」から来ています。この2つは別物です。クラウドエージェントとコードレビュー用の設定は、GitHub上でリポジトリのSettings > Copilot > MCP serversに置きます。設定は1つのmcpServersオブジェクトで、各サーバーにはtypeとtoolsが必要です。

VS Codeでは、リポジトリ内の.vscode/mcp.jsonまたはユーザー設定を使います。VS Codeの設定を移行するには、いくつか変更が必要です（リポジトリのMCP設定に関するドキュメント、VS CodeのMCPドキュメント）。たとえば、toolsを追加し、inputsをenvに置き換えます。

CopilotコーディングエージェントのMCPサーバーに、リモートHTTPサーバーは使えますか？

この質問は、検索候補の「copilot coding agent mcp server」と「github copilot coding agent mcp configuration」から来ています。使えます。typeにはlocal、stdio、http、sseを指定できます。リモートサーバーではurlとheadersを使います。

制限となるのはOAuthです。リポジトリ設定のリモートサーバーについて、クラウドエージェントとコードレビューはまだOAuthに対応していません。ヘッダーに入れたキーなら使えます。EveryInfraはBearerキーを使います（リポジトリのMCP設定に関するドキュメント）。

コーディングエージェントで使うMCPサーバーのトークンは、どこに置きますか？

この質問は、コーディングエージェントでAtlassianのMCPサーバーを使う方法についてのRedditスレッドから来ています（r/GithubCopilotのスレッド）。トークンは、リポジトリまたはOrganizationのAgentsシークレットに、COPILOT_MCP_で始まる名前で保存します。設定では、それを$COPILOT_MCP_NAMEとして参照します。この種類のシークレットを使えるのはMCPサーバーだけです（クラウドエージェントのシークレットと変数）。

ログに、MCPには接続できたものの取得できたツールが0個と表示されます。どうすればよいですか？

この質問は、同じエラーが報告されたRedditのスレッド（r/GithubCopilotのスレッド）に基づいています。まず、toolsの許可リストにある各ツール名が、tools/listで返されるいずれかの名前と完全に一致しているか確認します。次に、サーバーがリソースまたはプロンプトしか提供していないか確認します。クラウドエージェントが使用するのはツールだけだからです。EveryInfraでは、00:16（SGT）に実施したテストのとおり、APIキーなしでtools/listにPOSTリクエストを1回送ると、12個のツール名がすべて表示されます（リポジトリのMCP設定に関するドキュメント）。

GitHub CopilotのMCP許可リスト（allowlist）で、自分で追加したサーバーがブロックされることはありますか？

この質問は、検索候補の「github copilot mcp allowlist」と「github copilot mcp registry」から来ています。ブロックされることはあります。コネクタのドキュメントには、MCPに影響するポリシーが記載されています。組織またはEnterpriseで「MCP servers in Copilot」がオフになっていると、どのMCPサーバーも動作しません。

「Restrict MCP access to registry servers」でレジストリのサーバーのみが許可されている場合、そのポリシーを適用するクライアントではコネクタがブロックされます。EnterpriseでallowedMcpServersリストが定義されている場合は、サーバーのアドレスがそのリストに含まれている必要があります。まずはこれらの設定について管理者に確認してください（Copilotコネクタのドキュメント）。

毎週のCopilotオートメーションは、Actionsスクリプトより安く済みますか？

この質問は、私たち自身のテストと検索候補の「copilot coding agent mcp」から来ています。費用だけで見れば、ActionsスクリプトはAIクレジットを毎週まったく消費せず、3ブランド分のAPI料金は週$0.011961です。オートメーションは実行のたびにAIクレジットを消費します。1回の実行あたりに設定できる上限の最小値は30クレジット（$0.30）で、オートメーションはプライベートリポジトリまたは内部リポジトリでしか使えません。毎週の分析が必要な場合は、オートメーションのほうが手軽です（オートメーションのドキュメント、オートメーション作成のドキュメント）。数値だけが必要な場合は、スクリプトのほうが安く済みます。

始め方

1. EveryInfraのコンソールで、「copilot-mcp」と「weekly-actions」という名前のAPIキーを2つ作成します。クイックスタートを参照してください。
2. リポジトリで、AgentsのシークレットにCOPILOT_MCP_EVERYINFRA_API_KEYを、ActionsのシークレットにEVERYINFRA_API_KEYを追加します。
3. Settings、Copilot、MCP serversの順に開き、この記事のJSON（ツールは3つ）を貼り付けます。その他のMCPクライアントについては、EveryInfra MCPサーバーのページを参照してください。
4. この記事のテンプレートからIssueを作成し、Copilotにアサインします。マージする前に、workflow_dispatchでワークフローを1回実行してください。

参考文献

1. 「Connect your tools to Copilot without all the setup」、GitHub Changelog、2026年10月28日。
2. 「Copilot connectors」、GitHub Docs、2026年11月6日閲覧。
3. 「Configure MCP servers for your repository」、GitHub Docs、2026年11月6日閲覧。
4. 「Configure secrets and variables for Copilot cloud agent」、GitHub Docs、2026年11月6日閲覧。
5. 「Copilot automations」、GitHub Docs、2026年11月6日閲覧。
6. 「Creating automations with Copilot cloud agent」、GitHub Docs、2026年11月6日閲覧。
7. 「About Copilot cloud agent」、GitHub Docs、2026年11月6日閲覧。
8. 「Risks and mitigations for GitHub Copilot cloud agent」、GitHub Docs、2026年11月6日閲覧。
9. 「Customizing or disabling the firewall for GitHub Copilot」、GitHub Docs、2026年11月6日閲覧。
10. 「Best practices for using GitHub Copilot to work on tasks」、GitHub Docs、2026年11月6日閲覧。
11. 「Plans for GitHub Copilot」、GitHub Docs、2026年11月6日閲覧。
12. 「Usage-based billing for individuals」、GitHub Docs、2026年11月6日閲覧。
13. 「Events that trigger workflows」、GitHub Docs、2026年11月6日閲覧。
14. 「GitHub Actions billing」、GitHub Docs、2026年11月6日閲覧。
15. 「Using secrets in GitHub Actions」、GitHub Docs、2026年11月6日閲覧。
16. 「New tools, triggers, and cost controls for Copilot Automations」、GitHub Changelog、2026年10月28日。
17. 「Build shared workflows for your team with Copilot Automations」、GitHub Changelog、2026年10月28日。
18. 「Create and manage Copilot Automations in Visual Studio Code」、GitHub Changelog、2026年10月28日。
19. 「Work from anywhere with a new, connected Copilot cloud experience」、GitHub Changelog、2026年10月28日。
20. 「GitHub Agentic Workflows generally available」、GitHub Changelog、2026年10月28日。
21. 「GitHub Actions workflow lockfiles are generally available」、GitHub Changelog、2026年10月28日。
22. 「Push protection beyond predefined secret patterns」、GitHub Changelog、2026年10月28日。
23. 「GitHub Copilot supports server-to-server authentication」、GitHub Changelog、2026年10月27日。
24. 「Custom skills, agents, and MCP servers in usage metrics API」、GitHub Changelog、2026年10月22日。
25. 「Secret scanning blocks Anthropic keys by default, adds Salesforce」、GitHub Changelog、2026年10月13日。
26. 「Connect your tools to Copilot without all the setup, discussion 211002」、GitHub Community、2026年10月28日。
27. 「GitHub Agentic Workflows」、GitHub Next、2026年11月6日閲覧。
28. 「Tools」、Model Context Protocol specification 2025-11-25、2026年11月6日閲覧。
29. 「Transports」、Model Context Protocol specification 2025-11-25、2026年11月6日閲覧。
30. 「crontab」、The Open Group Base Specifications Issue 7、2018年。
31. 「LLM01:2025 Prompt Injection」、OWASP GenAI Security Project、2026年11月6日閲覧。
32. 「Quota Calculator」、YouTube Data API、Google for Developers、2026年11月6日閲覧。
33. 「IG User Business Discovery」、Meta for Developers、2026年11月6日閲覧。
34. 「TikTok Research Tools: Access and Eligibility」、TikTok for Developers、2026年11月6日閲覧。
35. 「Community Management Overview」、LinkedIn on Microsoft Learn、2026年11月6日閲覧。
36. 「Add and manage MCP servers in VS Code」、Visual Studio Code docs、2026年11月6日閲覧。
37. 「GitHub Copilot Code Agent: Retrieved 0 tools from MCP server」、Reddit r/GithubCopilot、2026年11月6日閲覧。
38. 「How to use MCP atlassian on Github coding agent」、Reddit r/GithubCopilot、2026年11月6日閲覧。
39. 「EveryInfra data capability catalog」、EveryInfra、2026年11月6日00:16（SGT）閲覧。
40. 「Configure the development environment for agents on GitHub Actions」、GitHub Docs、2026年11月6日閲覧。
41. 「Copilot allowlist reference」、GitHub Docs、2026年11月6日閲覧。
42. 「github/github-mcp-server」、GitHub、2026年11月6日閲覧。