MCP公式ロードマップを日本語で読む　社内AIエージェントが今つまずく場所と、先に決める4つ

社内でAIエージェントを試したい。そう思って調べ始めると、たいてい途中で止まる。原因が自分の理解不足だとは限らない。

結論を先に書く。今つまずく場所の多くは、規格そのものがまだ埋めていない穴だ。AIと社内ツールをつなぐ共通規格「MCP」の公式ロードマップが更新された。そこに並んだ優先5領域は、そのまま「導入が詰まる場所の一覧」として読める。

MCPを1分で

MCPは Model Context Protocol の略だ。AIに社内のカレンダーやファイル、業務システムを触らせるための共通の差し込み口にあたる。USBの規格に近い。対応していれば、どのAIからでも同じ挿し方ができる。

その規格を運営するチームが、今後6〜12か月で何を直すかを公式ロードマップとして公開している。最終更新は2026年8月22日。国内ではLedge.aiが9月1日に報じた。以下は原文を読んだうえで、非エンジニアの実務の言葉に置き換えたものだ。

原文はこう書く。エージェントの仕事には、数分かかる処理や、サーバー側から結果を押し出す通知が要る。途中で方向を変える手段も要る。今は「終わりましたか」とAI側が何度も聞きに行く形で、これが高くつく。

業務に訳すと、数十分かかる仕事はまだ標準の作法が固まっていない。「請求書を100件処理しておいて」は、現時点では素直に任せられる形になっていない。

2026年7月28日版で、リモートのMCPサーバーは普通のWebの仕組みに寄った。ただし手元のPCで動かす場合は別設計が残る。二重管理になっている状態だ。今期はこれを一本化し、キャッシュにETagを足す方向が示された。

業務に訳すと、担当者のPCで動いた設定が社内サーバーではそのまま動かない段階にある。試作と本番の間に、まだ段差がある。

ここが一番効く。原文の指摘は率直だ。MCPの認可は「ブラウザの前に人がいる」前提で作られている。ところが実際の呼び出し元はエージェントになりつつある。そして今のサーバーは、貼り付けたAPIキーと長生きするトークンに頼っている。

対策として、DPoPやワークロードID連携、RFC 8693のトークン交換といった既存の標準を取り込む方針が並ぶ。親エージェントより子エージェントの権限を狭くする話も出てくる。

業務に訳すと、AIは「誰として」社内システムに入るのかが未整理だということ。多くの現場では、担当者の権限をそのまま借りて動いている。

ツール呼び出しの戻り値の形が二通りあり、実装が割れた。これを整理し直す。あわせて、大量のツールを一度に読み込ませず必要な分だけ知らせる仕組みの検討が始まる。

業務に訳すと、つなぐツールを増やすほどAIは迷う。今は絞るほうが結果が良い。

手作業で保守しているSDKを、仕様から自動生成する実験を回す。非エンジニアが直接触る話ではない。ただしベンダーを選ぶときの見方は変わる。「独自実装の作り込み」を売りにする提案は、この流れと逆を向いている可能性がある。

規格の完成を待つ必要はない。決められることが先にある。名古屋の10人規模の会社を想定して書く。

決めること	今の目安
AIに渡す権限の名義	担当者の個人アカウントを共有しない。AI専用のアカウントを1つ作り、そこに必要な分だけ権限を付ける
つなぐツールの数	まず2つまで。カレンダーと社内ファイル置き場あたりから
任せる仕事の長さ	5分で終わる仕事だけ。長時間の自動処理は次の改訂を待つ
鍵の置き場所	設定ファイルへの直書きをやめる。MacならキーチェーンやOSの保管庫へ

4つめは自分の失敗でもある。ツールをつなぎ始めた頃、僕はアクセスキーを設定ファイルに直接書いていた。危ないと分かっていて放置した。先月やっとキーチェーンに移した。作業は30分で終わった。放置していた期間のほうが、比べものにならないほど長かった。

「規格が固まるまで様子見」は、たしかに安全に見える。ただしその間に、社内の誰かが個人契約のAIに資料を貼り付け始める。逆に「全部つないで一気に自動化」も無理がある。身分証の話が未整理なまま権限を広げると、事故のときに誰の操作か追えない。

間を取るなら、小さく繋いで、記録が残る形にしておく。上の4つはそのための最低線だ。

公式ロードマップは、開発者向けの文書として書かれている。それでも読む価値はある。作っている側が「まだできていない」と認めた場所が、そのまま導入の注意点になっているからだ。

AIエージェントが社内で動かないとき、原因は設定ミスとは限らない。規格がまだそこまで来ていないだけのこともある。それが分かっているだけで、止まる場所が変わる。