GitHub Copilot Agentsは、GitHub Copilotを「コード補完ツール」として使うだけでなく、Microsoft Agent Frameworkから呼び出せる開発者向けエージェント基盤として扱えるようにする仕組みです。2026年5月26日に更新された公式情報では、GitHub Copilot SDKをバックエンドにし、シェル実行、ファイル操作、URL取得、MCPサーバー連携などをエージェントから利用できる点が整理されています。導入時に重要なのは、機能そのものよりも、権限管理・Copilot CLIの認証・MCP接続範囲・利用量管理を先に決めることです。(Microsoft Learn)
GitHub CopilotのAI/Copilot更新で何が変わるのか
今回のポイントは、GitHub Copilotを「IDEでコードを書かせるAI」から、「自社アプリや社内開発ツールに組み込めるエージェント実行基盤」として扱いやすくなることです。
Microsoft Learnの「GitHub Copilot Agents」では、Microsoft Agent FrameworkがGitHub Copilot SDKをバックエンドとして利用するエージェント作成をサポートすると説明されています。GitHub Copilot agentsは、コーディング向けAI機能に加えて、シェルコマンド実行、ファイル操作、URL取得、MCPサーバー統合を扱えるとされています。(Microsoft Learn)
つまり、開発者が得られる変化は次の通りです。
| 変化 | これまでの使い方 | GitHub Copilot Agentsでの使い方 |
|---|---|---|
| 利用場所 | IDE、GitHub.com、CLIが中心 | .NETやPythonのアプリケーションから呼び出す |
| 作業単位 | 補完、チャット、単発の質問 | 複数手順のタスク、ファイル編集、外部ツール連携 |
| 拡張方法 | エディタ拡張、CLI設定 | Agent Frameworkのツール、MCP、セッション管理 |
| 管理観点 | Copilotの有効化、モデル、利用量 | それに加えて実行権限、サンドボックス、MCP接続先を管理 |
特に重要なのは、GitHub Copilot Agentsが「何でも自動で安全に実行してくれる機能」ではないことです。エージェントにファイルやシェルを扱わせる場合、どの操作を許可するかを開発者側で明示的に設計する必要があります。
GitHub Copilot Agentsとは何か
GitHub Copilot Agentsは、Microsoft Agent Frameworkの中でGitHub Copilot SDKを利用するエージェント実装です。Microsoft Agent Framework自体は、.NETやPythonでAIエージェントとワークフローを作るためのフレームワークで、エージェント、ツール、会話履歴、ワークフロー、テレメトリなどを扱います。(Microsoft Learn)
GitHub Copilot Agentsを使うと、たとえば次のような開発支援ツールを作れます。
- 社内リポジトリの変更内容を読み取り、PR説明文の下書きを作るツール
- 特定のルールに従って設定ファイルを修正する社内CLI
- テスト失敗ログを読み、原因候補と修正案を出す開発支援ボット
- Microsoft Learnや社内ドキュメントをMCP経由で参照しながら回答する技術支援エージェント
- レガシーコードの小規模リファクタリング案を作るレビュー補助ツール
ただし、GitHub Copilot Agentsは「GitHub Copilot cloud agent」や「GitHub.com上のagent apps」と同じものとして扱うべきではありません。この記事で扱う中心は、Microsoft Agent FrameworkからGitHub Copilot SDKを使う開発者向けの実装です。GitHub側の管理画面には、Copilot cloud agent、third-party coding agents、agent appsなど別の設定項目も存在するため、管理者は名称の近さだけで同一機能と判断しないよう注意が必要です。(GitHub Docs)
2026年5月26日更新の公式情報で押さえるべき要点
Microsoft Learnの該当ページは、2026年5月26日に更新されています。そこで示されている内容を、管理者・開発者が確認しやすい形に整理すると次のようになります。(Microsoft Learn)
| 確認項目 | 公式情報上のポイント | 実務上の意味 |
|---|---|---|
| バックエンド | GitHub Copilot SDKを利用 | Copilotのエージェント実行能力をアプリから使う構成になる |
| 前提条件 | GitHub Copilot CLIのインストールと認証が必要 | 開発PC、CI環境、Dev ContainerでCLIが起動・認証できるか確認する |
| 権限 | 初期状態ではシェル実行、ファイル読み書き、URL取得はできない | Permission Handlerを実装し、許可操作を制御する |
| MCP | ローカルstdio型、リモートHTTP型のMCPサーバーを設定可能 | 社内ツールや外部ドキュメント連携の入口になる |
| セッション | 複数ターンの文脈維持に対応 | 継続的な調査、修正、レビューに向く |
| ストリーミング | 応答を生成中に逐次受け取れる | CLIやWeb UIで体感速度を改善しやすい |
| 対象外のHosted Tool | Code Interpreter、File Search、Web SearchはCopilot CLI capabilityとしては扱われない | Azure OpenAIやFoundryの同名機能と混同しない |
開発チームにとって大きいのは、エージェントが「コードを提案する」だけでなく、許可された範囲で「調べる」「編集する」「コマンドを実行する」流れまで担える点です。一方、管理者にとっては、従来のCopilotライセンス管理だけでは不十分で、実行環境と権限境界を合わせて設計する必要があります。
開発者への影響：Copilotを自社ツールに組み込める
GitHub Copilot Agentsにより、開発者はGitHub Copilotのエージェント機能を自分たちのツールに組み込みやすくなります。GitHub Copilot SDKは、Copilot CLIの背後にあるエージェントランタイムをプログラムから利用するためのSDKとして説明されており、GitHub公式のリポジトリではPython、TypeScript、Go、.NET、Java、Rust向けのSDKが案内されています。(GitHub)
使いどころは「繰り返し発生する開発作業」
GitHub Copilot Agentsが向くのは、毎回人間が手順を考えて実行している開発作業です。
たとえば、次のような作業は相性がよいです。
| 活用シーン | エージェントに任せる範囲 | 人間が確認すべき点 |
|---|---|---|
| PR作成支援 | 差分確認、説明文作成、影響範囲の要約 | 仕様意図、リスク、レビュー観点 |
| テスト失敗調査 | ログの要約、関連ファイルの探索、修正候補の提示 | 根本原因、修正の妥当性 |
| リファクタリング補助 | 対象ファイルの抽出、小さな変更案の生成 | 設計方針、互換性、テスト結果 |
| ドキュメント更新 | コード変更に合わせたREADMEや手順書の更新案 | 最新仕様との整合性 |
| 社内ルールチェック | 命名規則、設定漏れ、テンプレート違反の検出 | 例外対応、最終判断 |
逆に、承認なしで本番環境に触る作業、大量ファイルを一括変更する作業、機密情報を広範囲に読ませる作業は、最初の導入対象にすべきではありません。
管理者への影響：Copilotの有効化だけでは足りない
組織でGitHub Copilot Agentsを展開する場合、管理者は「GitHub Copilotが使えるか」だけでなく、「Copilot CLIが使えるか」「MCPを許可するか」「どのモデルを使わせるか」「利用量をどう監視するか」を確認する必要があります。
GitHub Docsでは、Copilot CLIはすべてのCopilotプランで利用可能とされつつ、組織からCopilotを受け取っている場合は、組織設定でCopilot CLIポリシーが有効になっている必要があると説明されています。さらに、組織やEnterpriseの管理者が無効化している場合は利用できません。(GitHub Docs)
管理者が最初に確認すべき設定
| 確認項目 | 見るべき場所・観点 | 判断基準 |
|---|---|---|
| Copilotプラン | GitHub Copilot Business / Enterpriseなど | 対象ユーザーに必要な機能と管理権限があるか |
| Copilot CLIポリシー | 組織またはEnterprise設定 | 開発者やCI環境でCLIを使わせるか |
| モデル利用ポリシー | CopilotのModels設定 | 高コスト・高性能モデルを誰に許可するか |
| MCPポリシー | MCP servers in Copilot | 社内外のMCPサーバー接続を許可するか |
| third-party coding agents | Cloud agent関連設定 | GitHub Copilot Agentsとは別物として管理する |
| 利用量・予算 | Billing、AI Credits、使用状況 | PoC段階から上限・通知・レビュー頻度を決める |
GitHub Copilot BusinessやEnterpriseでは、組織管理者がCopilot機能やモデルの可用性を制御できます。Enterprise側でポリシーが固定されている場合、組織側では上書きできない点にも注意が必要です。(GitHub Docs)
権限管理が最重要：最初は「読めるが書けない」から始める
GitHub Copilot Agentsを安全に使ううえで最も重要なのは、Permission Handlerの設計です。
公式情報では、デフォルトではエージェントはシェルコマンド実行、ファイル読み書き、URL取得ができず、それらを有効化するにはPermission Handlerを提供すると説明されています。(Microsoft Learn)
これは実務上、非常に重要です。エージェントは便利ですが、ファイル削除、Git操作、外部URL取得、秘密情報を含むファイルの読み取りなど、誤ると影響が大きい操作も扱えます。
推奨される権限設計
| フェーズ | 許可する操作 | 避ける操作 |
|---|---|---|
| 検証初期 | リポジトリ内の読み取り、限定的なファイル一覧取得 | 書き込み、削除、任意シェル実行 |
| PoC | 特定ディレクトリ内の書き込み、テストコマンド実行 | rm、git push、認証情報ファイルの読み取り |
| チーム展開 | 許可コマンドのホワイトリスト化、MCPサーバー単位の制御 | --allow-all-toolsの常用 |
| 本番運用 | サンドボックス、監査ログ、レビュー承認付き実行 | 個人PCの広範な権限での自動実行 |
GitHub Copilot CLIには、ツール利用を手動承認なしで許可する--allow-all-tools、特定ツールを拒否する--deny-tool、特定ツールを許可する--allow-toolがあります。ただし、GitHub Docsは自動承認オプションについて、ユーザーが事前承認する機会なしにコマンド実行が可能になり、データ損失やセキュリティ問題のリスクが増えると説明しています。(GitHub Docs)
実務では、次のような方針が現実的です。
# 例：危険な削除やリモート反映を拒否しつつ、限定的に使う考え方
copilot --allow-tool='shell(git status)' \
--allow-tool='shell(git diff)' \
--deny-tool='shell(rm)' \
--deny-tool='shell(git push)'最初から自動実行を広く許可するのではなく、読み取り中心で効果を確認し、必要な操作だけを段階的に開放するのが安全です。
MCP連携でできることと注意点
MCPは、AIモデルやエージェントが外部ツールやデータソースと接続するための標準化された仕組みです。GitHub Docsでは、MCPを使うことでGitHub Copilotの機能をさまざまな既存ツールやサービスと統合できると説明されています。(GitHub Docs)
GitHub Copilot Agentsでは、SessionConfig.McpServersやdefault_options["mcp_servers"]を使って、ローカルstdio型またはリモートHTTP型のMCPサーバーを設定できます。Microsoft Learnの例では、filesystemのローカルMCPサーバーと、Microsoft LearnのリモートMCPサーバーを設定する例が示されています。(Microsoft Learn)
MCPを使う前に決めるべきこと
| 論点 | 確認すべきこと | 失敗しやすいポイント |
|---|---|---|
| 接続先 | 社内MCPか、外部MCPか | 便利だからと外部MCPを無制限に許可する |
| 権限 | 読み取り専用か、更新も許可するか | ファイルシステムやチケット管理を広く開けすぎる |
| 認証 | APIキー、OAuth、PATの保管方法 | 個人トークンを共有環境に置く |
| 監査 | どのツールが呼ばれたか記録できるか | 生成結果だけ見て、ツール実行履歴を見ない |
| データ範囲 | 送信されるコード、ログ、文書 | 機密データを外部サービスに渡してしまう |
また、GitHub Docsでは、組織やEnterpriseがMCPの利用可否を制御できる一方で、Copilot CLIでは一部の組織レベルMCPポリシー制限を現時点でサポートできないと説明されています。具体的には、MCP servers in CopilotやMCP Registry URLに関するポリシー制御がCopilot CLIでは制限される可能性があります。(GitHub Docs)
そのため、MCPを使う場合は「GitHubの管理画面で制御しているから安全」と決めつけず、CLI実行環境側でも設定ファイル、環境変数、ネットワークアクセス、コンテナ権限を確認してください。
導入前に確認する環境設定
GitHub Copilot Agentsを使うには、開発環境でGitHub Copilot CLIが動作し、認証できる状態が必要です。Microsoft Learnでは、GitHub Copilot AgentsにはGitHub Copilot CLIのインストールと認証が必要であり、シェルやファイル権限を持たせる場合はDockerやDev Containerのようなコンテナ化環境で実行することが推奨されています。(Microsoft Learn)
Copilot CLIのインストールと認証
GitHub Docsでは、Copilot CLIのインストール方法として、WindowsのWinGet、macOS/LinuxのHomebrew、npm、macOS/Linux向けのインストールスクリプトが案内されています。npmで使う場合はNode.js 22以降が前提です。(GitHub Docs)
# npmでインストールする例
npm install -g @github/copilot
# 認証は初回起動後に /login を使う
copilot認証については、GitHub Copilot CLIがOAuthトークン、環境変数、GitHub CLIのフォールバックなど複数の方法をサポートします。BYOKを使う場合はGitHub認証なしでも利用できるケースがありますが、その場合はCopilot cloud agent、GitHub MCP server、GitHub Code Searchなど一部の機能が使えないと説明されています。(GitHub Docs)
Agent Framework側のパッケージ
Microsoft Learnの2026年5月26日更新ページでは、.NET向けに次のNuGetパッケージ追加例が示されています。(Microsoft Learn)
dotnet add package Microsoft.Agents.AI.GitHub.Copilot --prereleasePython向けには、次のインストール例が示されています。(Microsoft Learn)
pip install agent-framework-github-copilot --preここで注意したいのは、GitHub Copilot SDK自体は2026年6月2日のGitHub Changelogで一般提供開始が発表されている一方、Microsoft Agent Frameworkの該当ページではAgent Framework側パッケージに--prereleaseや--preを付ける例が掲載されていることです。導入時は、Copilot SDKのGA状況だけでなく、Agent Framework連携パッケージのバージョン、破壊的変更、サポート範囲を個別に確認してください。(The GitHub Blog)
最小構成の実装イメージ
.NETでは、CopilotClientを作成して起動し、AsAIAgent()でAgent FrameworkのAIAgentとして扱う流れになります。公式例では、CopilotClientを開始したあとにagent.RunAsync()で問い合わせています。(Microsoft Learn)
using GitHub.Copilot.SDK;
using Microsoft.Agents.AI;
await using CopilotClient copilotClient = new();
await copilotClient.StartAsync();
AIAgent agent = copilotClient.AsAIAgent();
Console.WriteLine(await agent.RunAsync("What is Microsoft Agent Framework?"));Pythonでは、GitHubCopilotAgentを作成し、async with agent:の中でagent.run()を呼び出す形です。公式情報では、default_optionsにinstructions、model、timeoutなどを指定する例も示されています。(Microsoft Learn)
import asyncio
from agent_framework.github import GitHubCopilotAgent
async def main():
agent = GitHubCopilotAgent(
default_options={"instructions": "You are a helpful coding assistant."},
)
async with agent:
result = await agent.run("What is Microsoft Agent Framework?")
print(result)
asyncio.run(main())社内ツールとして展開するなら、いきなりファイル編集やシェル実行を有効にするのではなく、まずは読み取り専用の調査エージェントとして試すのが現実的です。
環境変数で管理すべき項目
GitHub Copilot Agentsでは、必要に応じて環境変数でCLIパス、モデル、タイムアウト、ログレベルを設定できます。Microsoft Learnでは、GITHUB_COPILOT_CLI_PATH、GITHUB_COPILOT_MODEL、GITHUB_COPILOT_TIMEOUT、GITHUB_COPILOT_LOG_LEVELが設定項目として挙げられています。(Microsoft Learn)
| 環境変数 | 用途 | 設定時の注意 |
|---|---|---|
GITHUB_COPILOT_CLI_PATH | Copilot CLI実行ファイルのパス | Dev ContainerやCIでは固定パスにすると再現性が上がる |
GITHUB_COPILOT_MODEL | 使用モデル | 高性能モデルほど利用量・コストに影響する可能性がある |
GITHUB_COPILOT_TIMEOUT | リクエストタイムアウト秒数 | 長すぎると障害検知が遅れ、短すぎると大規模タスクが失敗しやすい |
GITHUB_COPILOT_LOG_LEVEL | CLIログレベル | 本番では機密情報がログに残らないよう確認する |
環境変数は便利ですが、チームで運用する場合は.envやローカル設定に依存しすぎないことも大切です。Microsoft Agent Frameworkの概要では、.envファイルは自動ロードされないため、Pythonで使う場合はload_dotenv()を呼び出すか、シェルやIDEで環境変数を直接設定する必要があると説明されています。(Microsoft Learn)
利用量とコストの注意点
GitHub Copilot Agentsは、Copilot SDKやCopilot CLIのランタイムを利用するため、利用量管理を無視できません。
GitHub Docsでは、Copilot CLIのインタラクティブ利用やプログラムからの利用では、処理されるトークン数に基づいてGitHub AI Creditsが消費され、消費量はモデルによって変わると説明されています。また、大きなコンテキストウィンドウや高い推論レベルは、より多くのトークンを消費するため、AI Creditsの消費にも影響します。(GitHub Docs)
コストを膨らませないための実務ルール
| ルール | 理由 |
|---|---|
| まず小さなリポジトリや限定ディレクトリで検証する | 大量ファイルを読ませるとトークン消費が増えやすい |
| モデルをタスク別に使い分ける | すべてを高性能モデルにすると費用対効果が悪くなる |
| 長いログをそのまま渡さず要約・抽出する | ノイズが多い入力はコストと品質の両方に悪影響 |
| 同じ大きなプロンプトを何度も再送しない | 試行錯誤のたびに利用量が増える |
/usageや請求画面で定期的に確認する | 体感ではなく数値で利用状況を判断できる |
GitHub Copilotの各プランにはAI Creditsの扱いがあり、BusinessやEnterpriseでは組織向けの管理やポリシー制御も含まれます。導入前に、PoC用ユーザー、対象リポジトリ、月次の上限、レビュー頻度を決めておくと、後から利用量の説明に追われにくくなります。(GitHub Docs)
セキュリティ上の展開方針
GitHub Copilot Agentsの展開では、ローカルPCで広い権限を与えるより、Dev Container、Docker、専用VM、クラウドサンドボックスなど、影響範囲を限定できる環境から始めるべきです。
GitHub Docsでも、自動承認オプションのリスクを軽減する方法として、Copilotのクラウド・ローカルサンドボックス、または仮想マシン、コンテナ、権限とネットワークアクセスを厳しく制御した専用システムでの実行が挙げられています。(GitHub Docs)
最初の展開で避けたい設定
| 避けたい設定 | 理由 | 代替案 |
|---|---|---|
個人PC上で--allow-all-toolsを常用 | ユーザー権限と同じ範囲でファイルやコマンドに触れる | コンテナ内で必要ツールだけ許可 |
| リポジトリ全体を無条件に読み書き可能にする | 機密ファイルや生成物まで対象になる | 対象ディレクトリを限定する |
| 本番認証情報を含む環境で実行 | 誤参照やログ出力のリスクがある | ダミー環境・検証用シークレットを使う |
| MCPサーバーを一覧で無審査導入 | 外部送信や権限拡大の入口になる | 承認済みMCPサーバーだけを登録 |
| 監査ログを残さない | 後から原因追跡できない | 実行ログ、ツール呼び出し、差分を保存 |
特に、GitHub Copilot Agentsは開発効率化のための機能であり、セキュリティレビューやコードレビューの代替ではありません。生成された変更は、通常のPRレビュー、テスト、静的解析、シークレットスキャンを通す前提で運用してください。
移行・展開で失敗しやすいポイント
GitHub Copilot Agentsは新しい開発体験を作りやすい一方、既存のCopilot運用とは違う落とし穴があります。
Copilot Chatの延長だと思って権限を広げすぎる
Copilot Chatは主に回答や提案が中心ですが、GitHub Copilot Agentsは権限を与えるとファイル操作やコマンド実行を伴います。チャットの感覚で「便利だから全部許可」とすると、予期しない変更や削除が起こる可能性があります。
MCPサーバーを便利ツールとして無審査で追加する
MCPは強力ですが、接続先によっては外部サービスにコードやプロンプトが渡る可能性があります。社内規程、データ分類、ログ保存、認証方式を確認してから使うべきです。
CI/CDに個人認証を持ち込む
ローカルPoCでは個人アカウント認証で動いても、CI/CDや共有環境では別の設計が必要です。トークンのスコープ、保存場所、失効時の運用、退職者対応まで考えておく必要があります。
利用量を後回しにする
エージェントは複数ファイルを読み、試行錯誤し、モデルを何度も呼び出すため、通常の補完より利用量が増えやすい場面があります。PoCの時点で、1タスクあたりの実行回数、対象ファイル数、利用モデルを記録しておくと判断しやすくなります。
Agent Framework側とCopilot SDK側のバージョンを混同する
GitHub Copilot SDKがGAになっていても、Microsoft Agent FrameworkのGitHub Copilot連携パッケージが同じ安定度とは限りません。導入時は、SDK、Agent Framework、Copilot CLI、各言語パッケージを分けてバージョン管理してください。
おすすめの導入ステップ
GitHub Copilot Agentsを組織に展開するなら、次の順序が現実的です。
| ステップ | 実施内容 | 完了条件 |
|---|---|---|
| 用途を絞る | PR要約、テスト失敗調査、README更新など1つに限定 | 成功・失敗の判断基準がある |
| 実行環境を固定する | Dev Containerや専用検証環境を用意 | 誰が実行しても同じ結果を再現できる |
| 読み取り専用で試す | ファイル一覧、差分確認、要約だけを許可 | 危険なコマンドなしで価値を確認できる |
| 書き込みを限定許可する | 特定ディレクトリや一時ブランチだけ編集可能にする | 差分レビューとロールバック手順がある |
| MCPを段階導入する | 社内承認済みMCPだけ接続 | 接続先、認証、ログ、データ範囲が明確 |
| 利用量を可視化する | AI Credits、モデル、実行回数を記録 | 月次で継続判断できる |
| チームに展開する | ガイドライン、禁止操作、問い合わせ先を整備 | 開発者が安全に使える状態になる |
最初の成功例としては、「PR差分を読んでレビュー観点を出す」「失敗したテストログを要約する」など、人間の最終判断が残る用途がおすすめです。いきなり自動修正や自動マージに進めるより、チームがエージェントの得意・不得意を理解しやすくなります。
よくある疑問
GitHub Copilot AgentsはCopilot cloud agentと同じですか？
同じではありません。この記事で扱っているGitHub Copilot Agentsは、Microsoft Agent FrameworkからGitHub Copilot SDKを使うエージェント実装です。一方、Copilot cloud agentはGitHub.com上でタスクを委任する機能として扱われます。管理画面でも、third-party coding agentsやagent appsは別の設定として説明されているため、導入時は対象機能を明確にしてください。(GitHub Docs)
Code InterpreterやFile Searchは使えますか？
Microsoft Learnのツール表では、Code InterpreterとFile SearchはCopilot CLI capabilityではないと整理されています。また、Web SearchもHosted Toolとしては公開されていません。GitHub Copilot Agentsで外部情報やファイル検索を扱いたい場合は、MCPや自前のFunction Tool、リポジトリ内の読み取り処理などで設計する必要があります。(Microsoft Learn)
MCPは必須ですか？
必須ではありません。シンプルなエージェントであれば、Function Toolや通常のプロンプト、セッション管理だけでも始められます。MCPは、GitHub、社内ツール、ドキュメント、外部APIなどと標準的に連携したい場合に有効です。
本番導入してよいですか？
GitHub Copilot SDKは2026年6月2日に一般提供開始が発表されていますが、Microsoft Agent FrameworkのGitHub Copilot連携ページでは、パッケージ例に--prereleaseや--preが使われています。業務利用する場合は、利用する言語、パッケージ、CLI、認証方式、サポート範囲を個別に確認し、小さな用途から段階的に展開するのが安全です。(The GitHub Blog)
まず確認すべきこと
GitHub Copilot Agentsは、開発作業を自動化・半自動化する強力な選択肢です。一方で、シェル実行、ファイル編集、MCP接続を扱えるため、導入効果とリスクが同時に大きくなります。
最初にやるべきことは、コードを書くことではありません。まず、次の4点を確認してください。
- 対象ユーザーがCopilot CLIを利用できるライセンス・ポリシーになっているか
- 実行環境をDev Container、Docker、専用VMなどに分離できるか
- Permission Handlerで許可する操作と拒否する操作を明文化できるか
- MCP接続先、利用モデル、AI Creditsの管理方法を決めているか
この4点が整理できていれば、GitHub Copilot Agentsは「便利そうな新機能」ではなく、社内の開発プロセスに組み込める実用的なAIエージェント基盤になります。まずは読み取り専用の小さなPoCから始め、差分レビュー、テスト、利用量、セキュリティログを確認しながら段階的に展開しましょう。
コメント