サービスを見る

MCPは​「便利な​拡張機能」ではなく、​AIに​何を​触らせるかの​“権限レイヤー”だ ──GitHubが​企業研修に​した​日、​AI導入は​“統制の​設計”に​なった

GitHubのExpert Servicesに「Copilot Agents and MCP」という4時間の企業向けトレーニングが載った。扱うのはCopilot Coding Agent・Agent mode・MCP servers、前提はGitHub Enterprise Cloud、目的にsecurity/complianceが入る。これはMCPが「開発者がローカルで試す便利ツール」から「会社が管理すべきAIエージェントの権限レイヤー」へ移ったサインだ。GitHub Docsでは、MCP設定後にCopilotがツールを自律利用し承認を求めないこと、リポジトリ単位のMCP設定がcloud agentとcode reviewに共有されることが明記されている＝個人の趣味設定でなくrepo governance。だから設計対象はagentの作り方でなく、5層（作業契約＝AGENTS.md／権限＝MCP／専門手順＝skills／検証＝hooks/eval/CI/review／記録＝logs/監査）。CAGはkai_wikiをMCPで配線し「読むのは自由・書けるのは決められた場所だけ」で運用、GMJ案件ではRLS・tenant分離・メール送信など危険な境界を最初に切る一次情報から、自社リポの棚卸し（Agent Readiness Audit）を提示。外部の機能はGitHub公式ベースでCAG非検証。

甲斐ショウジ甲斐ショウジ
CAG主宰／合同会社ATK CAIO（最高AI責任者）
技術10分で読めます
技術MCPは「便利な拡張機能」ではなく、AIに何を触らせるかの“権限レイヤー”だ ──GitHubが企業研修にした日、AI導入は“統制の設計”になった

技術ノート ｜ AIの最新動向を、現場目線で

GitHub の Expert Services に、「GitHub Copilot Agents and MCP」という4時間の企業向けトレーニングが載っている。扱うのは Copilot Coding Agent、Agent mode、MCP servers。受講の前提には GitHub Enterprise Cloud アカウントと、連携や自動化を設定できる権限が並ぶ。そして学ぶ目的に、はっきりと security と compliance が入っている。[1]

小さな変化に見えて、これは大きい。MCPが「開発者がローカルで試す便利ツール」から、「会社が管理するAIエージェントの権限レイヤー」へ移ったということだからだ。GitHub 自身が、この領域を個人の趣味設定ではなく、企業導入の運用課題として扱い始めた。

私たち電脳技巧集団（AI職人ギルド）は、自分たちの開発でも顧客の案件でも、MCPで外部システムにAIをつなぎ、AGENTS.md で作業のルールを渡している。だからこの動きは「GitHubの新サービス」ではなく、「AI導入支援で売れるのは、agentの作り方ではなく、安全に動かす設計（governance）になる」サインとして読む。なお外部の機能・数値は GitHub 公式ページとドキュメントに基づくもので、CAGが検証したものではない。

ダークなコントロールプレーンのUI。中央にAIエージェント、その周囲にMCPサーバー（GitHub・ブラウザ操作・データベース等）が並び、それぞれにallow/denyの権限ゲートが付いている。権限レイヤーを通してのみツールにつながる構図。シアンとゴールド
MCPの本質は「便利な拡張機能」ではない。AIエージェントが何を読め、何を書け、どこへつなげるかを決める"権限レイヤー"だ

01GitHubが​MCPを​「企業研修」に​した、​その​意味

2025年のMCP（Model Context Protocol）は、Claude DesktopやVS Codeに外部ツールをつなぐ、開発者向けの実験という色が濃かった。便利な人が便利に使う、ローカルの設定だった。それが2026年6月のGitHub公式情報では、Copilotの複数の面（IDE、Copilot CLI、Copilot app、GitHub.com上の委任）にまたがる接続レイヤーとして説明されている。[2]

研修の対象も象徴的だ。GitHub はこの講座の受講者として、運用エンジニア、DevOps、テックリード、開発者、開発リーダーを挙げている。[1] 「agentを作る人」ではなく、「agentを業務に入れて回す人」に向いている。講座の主題は、強いエージェントの作り方ではなく、agentic workflow を安全に業務へ入れる方法になっている。MCPを語る場所が、開発者の手元から、企業の導入会議に移った。

02MCPは​"接続口"であって、​安全境界ではない

ここで効いてくるのが、GitHub Docs の素っ気ない注意書きだ。MCPサーバーを設定すると、Copilotはそのサーバーのツールを自律的に使い、事前の承認を求めない。[3] 便利さの裏側で、これは企業導入で最も注意すべき点になる。「つないだら、あとはAIが自分で使う」のが既定の挙動だからだ。

もうひとつ見落としやすいのが、設定の影響範囲だ。リポジトリ単位のMCP設定は、コードを書く cloud agent と、コードをレビューする code review の両方に共有される。[3] GitHub公式のMCPサーバーとブラウザ操作系のMCPサーバーは、既定で有効とされている。[3] つまりMCP設定は「自分だけの便利設定」ではなく、そのリポジトリに紐づくすべてのagentとレビューに効く、リポジトリの統制（governance）になっている。

repo の MCP 設定は、複数の面に効く repo のMCP 設定tools allow-list IDE / CLI cloud agent code review 外部システム 承認なしで利用 既定では、agent はツールを自律的に使う
リポジトリのMCP設定は、IDE・CLI・cloud agent・code review・外部システムに共有され、agentは既定でツールを承認なしに使う。だから設定は"統制"の対象になる

03設計するのは​「agentの​作り方」でなく、​権限と​統制

こう整理すると、企業が本当に買うべきものが見えてくる。MCPサーバーそのものではない。MCPの棚卸し、権限設計、秘密情報の扱い、作業契約（instructions）、レビューの関所、監査ログを束ねた、運用のパッケージだ。AIエージェントの導入は、5つの層で考えると崩れにくい。

AIエージェント導入の5層 ① 作業契約（instructions）AGENTS.md / CLAUDE.md ＝ 何をする・何をしない・完了条件 ② 権限（MCP）どのツールを、読み／書き、どの外部へつなぐか ③ 専門手順（skills）繰り返す作業を、再利用できる手順資産に ④ 検証（hooks / eval / CI / review）書くagentも、レビューするagentも関所を通す ⑤ 記録（logs / 監査証跡）何を読み、何をしたかを残す
AIエージェント導入の5層。MCPは②の「権限」にあたる。便利だから入れる、ではなく、①〜⑤を一緒に設計して初めて安全に回る

この層で見ると、MCPの位置がはっきりする。MCPは標準化された接続の規格であって、セキュリティ境界そのものではない。[3] つなぐ先が増えるほど、権限・秘密情報・ログ・承認・ツール経由の攻撃（prompt / tool injection）の管理が増える。「GitHub公式の研修があるから安全」とも言えない。研修は安全運用を学ぶ入口であって、その会社のデータ分類・権限設計・監査要件まで自動で解いてくれるわけではない。

04​私たちは、​MCPを​"権限レイヤー"と​して​運用している

この話は、私たちにとって机上の議論ではない。CAGの開発では、社内の知識基盤（kai_wiki）をMCP経由でリポジトリにつなぎ、AIが参照・記録できるようにしている。ただし、つなぎ方には線を引いている。読むのは自由、書けるのは決められた場所だけ。秘密情報や組織のIDはMCP越しに出さない。AGENTS.md には「秘密値を出さない」「本番への書き込みは内容確認してから」といった、作業の契約を書いてある。MCPは便利だから全開にする、ではなく、何を読め、何を書け、どこへ残すかを決める権限の層として扱っている。

ダークなMCPサーバー棚卸しのUIモック。サーバー名・提供ツール・読み取り/書き込み・秘密情報の要否・外部通信・承認要否・ログ保存先が列になった表。一部の書き込み行が承認必須として赤系で強調されている。シアンとゴールド
MCPサーバーの棚卸し表。サーバー名・ツール・読み書き・秘密情報・外部通信・承認・ログ保存先を一覧にして、初めて「何を触らせているか」が見える

顧客の案件では、線の引き方がもっと重要になる。たとえばGMJ向けに作った予約システムやセキュア資料共有ツールは、顧客情報・店舗ごとの分離・メール送信・非公開ファイルの配信など、agentに触らせると危険な境界が多い。ここでMCPを「便利だから」と全開にすると、AIが店舗をまたいで顧客情報を読める、本番メールを勝手に送る、といった事故につながりうる。だから設計の最初にやるのは賢いモデル選びではなく、「どのagentが、何を読めて、何を書けるか」を決めることだ。GitHub公式が示す「GitHub MCPサーバーは強力なので、利用するツールを最小限に絞る」という考え方[3]を、案件ごとに当てはめていく。

05自社の​リポジトリで、​棚卸しすべきこと

「自社でもAIに仕事を任せたい」と考えたとき、最初に見るのはモデルではない。自分のリポジトリが、AIに安全に仕事を渡せる状態になっているかだ。私たちが診断（Agent Readiness Audit）で見る項目を、表にした。[5]

棚卸しの項目危ない状態整えた状態
作業契約AGENTS.md が無い・複数の指示が矛盾指示が1本化され、安全・完了条件まで書いてある
MCP棚卸しどのサーバーが何をできるか誰も把握していないサーバー・ツール・読み書き・所有者が一覧化
権限広い権限を一括付与役割ごとに最小権限、ツールはallow-list
秘密情報平文・ログに出る・コードに直書き専用の保管・出力禁止・接続口に渡す前に検証
レビューの関所AIの変更がそのまま通るcode review・人のレビュー・RLS確認を通す
記録誰が何をしたか追えない実行ログ・PR・監査証跡が残る
最初の業務いきなり重要業務を任せる低リスク業務から・禁止業務と戻し方を決める

※ GitHub Enterprise / Copilot の細かな要件、preview機能（code review のMCP対応など）は仕様が変わりうる。本番導入の前に、各サービスの最新の管理者向けドキュメントで確認してほしい。

この表で大事なのは、どの項目も「便利か」ではなく「取り返せるか」で向きを決めることだ。秘密情報の漏れや本番への破壊的な操作は、起きてから戻せない。だから迷ったら止める側へ。社内ドキュメントの整理のような取り返せる作業は、迷ったら任せる側へ倒す。MCPサーバーを誰が追加してよいかも、個人ではなくリポジトリや組織のポリシーで決める対象になる。[3]

06​私たちなら、​どう​導入するか

もし「自社にAIエージェントを入れたい」と相談されたら、最初の納品はコードではなく診断レポートだ。AGENTS.md の状態、MCPサーバーの一覧、ツールの許可・禁止、秘密情報の扱い、GitHub・Supabase・Vercel の権限マップ、レビューと人の承認の関所、そして最初に任せる低リスク業務。「どのモデルが賢いか」ではなく、「どこまで触らせて、どこで人が止めるか」から決める。

ダークなAgent Readiness Audit（エージェント導入診断）のレポート画面UIモック。作業契約・MCP棚卸し・権限マップ・秘密情報・レビュー関所・記録の各セクションに状態のスコアが付き、人間の承認が必要な操作が赤系で示されている。シアンとゴールド
導入診断は「強いAIを1体作る」ではない。作業契約・MCP棚卸し・権限・レビュー・記録を一枚に並べ、どこで人が止めるかまで決める作業だ

そのうえで、外部への送信、金額が動く操作、顧客情報や契約に関わる判断には、人間の承認（HITL）を必ず挟む。AIが一次対応で速く動き、取り返しのつかない判断だけを人が引き取る。これはCAGが受注・クライアント対応で掲げる運用原則そのものだ。GitHubがCopilot Agents and MCPを企業研修にした今、答えははっきりしている。勝つのは「最新のAIを入れた会社」ではなく、「AIに安全な権限と仕事の境界を設計できた会社」だ。MCPは便利な拡張機能ではなく、その会社が管理すべき権限レイヤーになった。

MCPの扱い方「便利ツール」として入れる「権限レイヤー」として設計する
位置づけ開発者の趣味設定リポジトリ・組織の統制対象
権限つないだら全開で使わせるツールを最小化・allow-listで絞る
影響範囲自分の手元だけと思い込むcloud agent と code review に共有される前提
承認自律利用に任せきり取り返せない操作は人が止める
記録何をしたか残らない実行ログ・監査証跡で追える

※ 上表はMCPの運用姿勢の対比であり、特定製品の優劣比較ではない。

AGENTS.md記事のサムネイル 関連記事 ｜ 5層の①「作業契約」AIエージェント時代、強いリポジトリは「AGENTS.md」を持っている → 作業場設計記事のサムネイル 関連記事 ｜ 常駐AIの作業場設計AIエージェントは、チャット欄から「チームの作業場」に引っ越した →

出典・脚注

  1. GitHub Expert Services「GitHub Copilot Agents and MCP」。4時間のトレーニング、扱う内容（Copilot Coding Agent / Agent mode / MCP servers）、目的としての secure / compliant operations、受講前提（GitHub Enterprise Cloud アカウント・必要権限）に基づく。
    https://github.com/services/github-copilot-agents-and-mcp
  2. GitHub Docs「About Model Context Protocol (MCP)」。MCPがIDE・Copilot CLI・Copilot app・GitHub.com上の委任にまたがって使えるとの説明に基づく。
    https://docs.github.com/en/copilot/concepts/context/mcp
  3. GitHub Docs「Configure MCP servers for your repository」。リポジトリ単位のMCP設定が cloud agent と code review に共有されること、設定後にCopilotがツールを自律利用し承認を求めないこと（warning）、GitHub MCP server と Playwright MCP server が既定で有効なこと、ツールの最小化やポリシー管理に基づく。code review のMCP対応は public preview のため仕様変更の可能性がある。
    https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/configure-mcp-servers
  4. GitHub MCP Server（公式実装・MIT）。GitHubのファイル・issue/PR・Actions・code security などをツールとしてagentに渡す。利用範囲は toolsets / individual tools で絞れる。
    https://github.com/github/github-mcp-server
  5. 本記事の診断項目（Agent Readiness Audit）および「読むのは自由・書けるのは決められた場所だけ」「危険な境界の分離」は、CAGが自社開発（kai_wiki MCP連携・AGENTS.md運用）とGMJ向け案件で実装してきた一次情報（クライアント名・固有値は伏せた匿名例）に基づく。外部製品の機能・数値はCAGが検証したものではない。

AIに、​安全に​仕事を​渡せる​状態を​つくりたい方​へ

AGENTS.md整備・MCP棚卸し・権限境界・レビューの関所・監査ログまで、Agent Readiness Audit として診断します。導入のご相談はこちらから。

CAGに相談する
技術AIエージェントMCPGitHub CopilotAI導入ガバナンス解説
Related関連記事技術をもっと見る→
AIエージェントは、チャット欄から「チームの作業場」に引っ越した ──Claude Tagが示す、次の競争軸は“作業場設計”技術10分AIエージェントは、チャット欄から「チームの作業場」に引っ越した ──Claude Tagが示す、次の競争軸は“作業場設計”2026-06-23、AnthropicがClaude Tagを発表した。Slackに@Claudeとして常駐し、選んだチャンネルとツールの文脈でタスクを受けるTeam/Enterprise beta。これを「SlackでClaudeが使える」と読むと半分しか見えない。本当に動いたのは、AIのUIが個人のチャット欄からチームの作業場へ引っ越したことだ。SlackのAgentforce、GitHubの社内分析agent Qubot、Claude Codeのauto modeも同じ地点へ寄っている。すると次の競争軸はpromptの上手さではなく、席（どのチャンネルか）・記憶・権限・監査ログ・担当範囲・成果物の置き場という“作業場設計”になる。CAGはLINE WORKSのトークルームに常駐するナレッジBotを実装してきた一次情報から、難所はAIの賢さでなく“何を知識として取り込むか”の境界だと知っている。メタ会話をingest段階で分離し、確定値をコードのガードで保護する。常駐AIを置く前のチェックリスト（席/記憶/権限/監査/担当/成果物）を提示。外部製品の機能・数値は各社公式・報道ベースでCAG非検証。「どのモデルが最強か」はもう古い ──Sakana Fuguが見せた、AIを束ねる”司令塔”の競争技術11分「どのモデルが最強か」はもう古い ──Sakana Fuguが見せた、AIを束ねる”司令塔”の競争「GPT・Claude・Geminiどれが最強か」はそろそろ古くなる。Sakana AIが2026-06-22にGA公開したFugu / Fugu Ultraが面白いのは、新しい巨大モデルを作ったからでなく、複数の強いモデルをどう呼び分け協調させるかを“モデルそのもの”にした点だ。モデル選択・役割分担・検証・やり直しを、外側のコードでなく学習済みの司令塔（coordinator）へ寄せる。OpenAI互換APIでbase_url/modelの差し替えで試せ、Codex CLIにはcodex-fuguラッパー。ルーターでもMixtureでもなく、TRINITY/Conductor基盤で役割（Thinker/Worker/Verifier）と協調・自己再帰を学習。ただし第三者初日検証では、軽いコード生成でfugu 55秒/2,141トークン vs fugu-ultra 269秒/28,950トークン（司令塔トークン込み）で品質差は限定的＝軽い仕事にUltra常用は割に合わない。司令塔トークンは可視だがモデル別呼び出しは見えず監査に不足しうる。導入軸はquality/latency/cost/traceability/governance、置き換えでなくadvisor/fallback/benchmarkとして測ってから。数値は各社公式主張/初日小サンプルでCAG非検証。「たくさん書けるAI」から「無駄を書かないAI」へ ──Agent Minimalism、上手さはAIに余計な仕事をさせないことへ技術10分「たくさん書けるAI」から「無駄を書かないAI」へ ──Agent Minimalism、上手さはAIに余計な仕事をさせないことへAIコーディングを使い込むと、悩みが「書けない」から「書きすぎ」に変わる。読ませるログが長すぎる、差分が大きすぎてレビューできない、標準機能で済むのに自作する——生成能力が飽和したあと残るのは“無駄”だ。2026年6月、この課題に別角度から答えるツールと研究が並んだ。入口を絞るheadroom（渡す前に文脈を圧縮・60〜95%削減は公式claim）、出口を絞るponytail（書く前にYAGNI→標準→最小実装を問う判断階段・平均−54%LOC等は自己ベンチ）、過程を測るHugging Face（最終答えでなくturns/tokens/errors/traceを測る）。鍵は「少ないコード≠雑なコード」——削っていいのは儀式と重複、削ってはいけないのは検証・セキュリティ・アクセシビリティ。AGENTS.mdに判断階段と測り方を契約として落とし、安全は別ゲートにする実装案まで。数値は各プロジェクトの公式claim/自己評価でCAG非検証、「Agent Minimalism」は本記事の整理概念。AIエージェント時代、強いリポジトリは「AGENTS.md」を持っている ──CopilotがレビューにAGENTS.mdを読み始めた日技術11分AIエージェント時代、強いリポジトリは「AGENTS.md」を持っている ──CopilotがレビューにAGENTS.mdを読み始めた日AIコーディングの差は、もう「どのモデルか」だけではない。効くのは「そのリポジトリが自分の作法をAIに渡せているか」だ。賢いAIほど、リポジトリ固有のルール（日本語で返す/RLSを確認/秘密値を出さない/公開後の確認）を知らないと堂々と間違える。2026年6月、各社が同じ“指示の層”に寄ってきた——GitHub Copilotのコードレビューが AGENTS.md を読み始め、Codexは作業前に命令チェーンを組み、Microsoft AgentRC はリポジトリのAI対応度を計測。AGENTS.md は「AI向けREADME」ではなく、setup/test/secret/権限/完了条件を渡す“作業契約＝運用OS”だ。何を書くか（言語/スタック/コマンド/安全/Done）、私たちが各リポに持たせている一次情報、そして万能論への釘（skills/MCP/eval/人のレビューとセット・秘密値は書かない）まで。外部仕様はCAG非検証＝公式発表ベース。「人間が読むWiki」から「AIが引き継ぐ知識」へ ──Google CloudのOKFが名付けた、AIエージェント時代の知識設計技術11分「人間が読むWiki」から「AIが引き継ぐ知識」へ ──Google CloudのOKFが名付けた、AIエージェント時代の知識設計AIエージェントを毎日使うと、すぐ壁に当たる。モデルは賢いのに、前提・過去の決定・正本・禁止事項を読めないと使えない。足りないのは長いプロンプトでなく「引き継げる知識」だ。Google Cloudが公開した Open Knowledge Format（OKF v0.1）は、知識を Markdown＋YAML frontmatter＋ディレクトリのvendor-neutralな“束”として表す仕様で、この感覚に名前を与えた。私たちは人間とAIが共同編集するMarkdownナレッジベースを日々運用しており、OKFは「ずっとやってきたこと」に共通語がついた感覚。ただし正本はObsidian最適のまま、export層でwikilink→通常リンク・category→type・description補完して書き出すのが安全（実際にOKF互換ページを試作）。企業ナレッジをagent-readyにする導入支援の角度、v0.1 Draft/形式は質を上げない/機密のレーン分けという留保まで。外部仕様はCAG非検証＝公式発表ベース、ナレッジ運用は自社一次情報。「あの資料、見てもらえたかな」を終わらせる ──提案資料をURL一つで安全に届け、閲覧まで見える共有ツールを作った制作事例技術10分「あの資料、見てもらえたかな」を終わらせる ──提案資料をURL一つで安全に届け、閲覧まで見える共有ツールを作ったメールに添付した提案資料は、相手が開いたのか、どこまで読んだのか分からない。PDFは重くて開かれず、共有リンクは転送し放題で機密には使えない——資料を「送って終わり」にした瞬間、その先は暗闇になる。私たちは提案資料を多く扱う支援企業向けに、資料をURL一つで安全に届け、閲覧の状況まで見えるセキュアな共有ツール（DocSend的）を設計・実装した。①クライアント閲覧者を“会員”にしない二系統認証（Web暗号＋署名付き一時通行証）、②直リンクを塞ぎ隔離枠で映す“見えるけど抜けない”配信、③資料をAIで生成し必要箇所だけ差分編集・同一URLで改訂・自動分類、④現場の要望を1日7リリースで即日反映・大容量50MB対応。技術判断を主役に、安全性とAI活用と改善速度の作り方を書く。クライアント名・ドメイン・認証情報は伏せ、数値は自社実装の事実に基づく匿名例。

言語化できるものは、全て作る。

あなたの「作りたい」を、定価とスピードで形に。まずは無料の相談から。

制作事例を見る