MCP コネクタの認可を一箇所に集める — 参照先が増えても崩れない個人開発の設計

ある朝、Cowork のスケジュールタスクが「コネクタに接続できません」とだけ残して終わっていました。前日まで動いていたのに、です。原因をたどると、Claude Code 側で同じサーバーのトークンを更新したのに、Cowork が読む設定はそのままで、片方だけ古い認可情報を握っていたためでした。クライアントごとに同じコネクタを別々に書いていると、こういう食い違いは静かに起こります。

2026-06-20 に Anthropic が追加した「エンタープライズ管理型 MCP コネクタ」は、まさにこの食い違いを構造から消す機能です。管理者が一度コネクタをプロビジョニングしておけば、利用者は初回ログイン時にゼロタッチで使えるようになり、Claude チャット・Claude Code・Cowork をまたいだ認可が一箇所に集約されます。企業向けの仕組みですが、ここにある「参照先の認可は正本を一つだけ持つ」という設計思想は、参照先が増えていく個人開発でこそ効きます。

散らばった設定が「無音の障害」になる理由

MCP コネクタの設定は、放っておくと自然に重複します。Claude Code の .mcp.json、Cowork 側の設定、チャットのコネクタ一覧——同じ GitHub や Stripe へのつなぎ込みを、それぞれの場所に書いてしまいがちです。書いた直後は全部同じ内容なので問題は表に出ません。

問題が出るのは「片方だけ」更新したときです。トークンをローテーションした、エンドポイントを変えた、スコープを絞った。そのとき更新を反映し忘れたクライアントは、古い認可のまま動き続け、ある日アクセスが拒否されて初めて気づきます。私自身、4 つのサイトを自動運用していると参照先が増え続けるので、この「片方だけ古い」状態を何度か踏みました。厄介なのは、エラーが 401 や「接続できません」という結果だけで、どの設定が真実なのかをツールが教えてくれないことです。

管理型コネクタが解いているのはこの一点です。正本が一つしかなければ、更新箇所も一つで済み、クライアント間でずれようがありません。

正本を一つに決める — スコープの選び方

個人開発で同じ性質を再現する出発点は、「このコネクタ定義の正本はどこか」を先に決めることです。Claude Code では .mcp.json を置く場所でスコープが変わります。

ユーザースコープ（~/.claude.json などホーム配下）— その端末のすべてのプロジェクトから同じコネクタを共有します。複数リポジトリを横断する個人開発では、これが事実上の「正本」になります。
プロジェクトスコープ（リポジトリ直下の .mcp.json）— そのプロジェクト専用のコネクタ。チームや公開リポジトリで「このプロジェクトはこれを使う」と明示したいときに限って置きます。

迷ったら、横断して使うものはユーザースコープに寄せ、プロジェクト固有のものだけをリポジトリに残す、と切り分けると重複が生まれにくくなります。私は 4 サイトに共通で使うコネクタはユーザースコープに集約し、各リポジトリの .mcp.json には「そのサイトだけが触る対象」しか書かないようにしています。

// ~/.claude.json（ユーザースコープ＝横断コネクタの正本）
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      // トークンは直書きせず、環境変数を参照させる（次節）
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  }
}

ここで大事なのは、正本を決めた以上、他のクライアントには同じ定義を二度書かないという規律です。Cowork やチャットから同じサーバーを使うときも、参照するのは同じ環境変数・同じ資格情報であって、新しくトークンを貼り直すのではありません。

認証情報はインラインに埋め込まない

「正本を一つに」の効果を最大化する鍵が、認可情報の持ち方です。トークンを .mcp.json に直書きすると、正本を一つにしたつもりでも、結局そのファイルが資格情報のコピー先になってしまいます。ローテーションのたびに該当ファイルを開いて書き換える運用は、更新漏れの温床です。

そこで、設定ファイルには環境変数の参照だけを書き、実際のトークンは環境側に一箇所だけ置きます。

# 資格情報の正本はここだけ（例: ~/.config/claude/secrets.env）
export GITHUB_TOKEN="ghp_..."     # 実値はこのファイルにのみ存在
export STRIPE_API_KEY="sk_..."
 
# 設定ファイル側は参照するだけ。ローテーションはこの env を書き換えるだけで全クライアントに反映される

こうしておくと、トークンを更新する作業が「秘密の置き場所を一つ書き換える」だけになります。各クライアントの設定は参照しか持たないので、更新を反映し忘れるクライアントが原理的に存在しなくなります。冒頭の「片方だけ古い」障害は、この一手でほぼ消えます。なお秘密ファイルは .gitignore に入れ、リポジトリに混入させないことを忘れないでください。コミット履歴に資格情報が入ると、ローテーションを一からやり直すことになります。

「全部同じはず」を疑う — ドリフト検査を習慣にする

正本を一つに保つ設計にしても、人は手で例外を作ります。一時的にプロジェクト直下へコネクタを足した、検証用に別トークンを貼った——そうした「その場しのぎ」が残ると、いつの間にか正本が二つに増えています。これを早期に見つけるには、設定の食い違い（ドリフト）を時々あぶり出す軽い検査が役に立ちます。

# プロジェクト配下に紛れ込んだ .mcp.json を一覧する
find ~/projects -name ".mcp.json" -not -path "*/node_modules/*"
 
# 各設定からサーバー名だけ抜き出して、想定外の重複定義がないか目で確認する
for f in $(find ~/projects -name ".mcp.json" -not -path "*/node_modules/*"); do
  echo "== $f =="
  grep -o '"[a-zA-Z0-9_-]*":[[:space:]]*{' "$f" | head
done

検査自体は数秒で終わります。狙いは「正本以外の場所にコネクタ定義が増えていないか」を定期的に確かめることです。見つかったら、それを正本へ畳むか、本当にプロジェクト固有なのかを判断して整理します。管理型コネクタが管理者の手元で一元化を保証してくれるのに対し、個人開発では自分がその管理者を兼ねます。だからこそ、たまに棚卸しする習慣が一元化を生かし続ける条件になります。

公式が一元管理してくれない領域は、自分で正本を決める

エンタープライズ管理型コネクタは、企業の管理境界の中で「一度つないで全クライアントから使い回す」を実現します。個人開発にそのまま降ってくる機能ではありませんが、設計の芯——参照先の認可は正本を一つだけ持ち、各クライアントはそれを参照するだけにする——は、いまの自分の環境でもそのまま採り入れられます。

やることは多くありません。私はこの三点だけを守っています。横断コネクタの定義はユーザースコープに集約し、トークンは設定に直書きせず環境変数の正本一箇所に置き、たまにドリフトを検査する。この三つだけで、参照先が増えても「片方だけ古い」無音の障害は起きにくくなります。コネクタを足すほど運用が重くなる構図を、足すほど整理が効く構図へ静かに変えていける設計だと考えています。

関連する設計の詳細は、Claude Code で MCP サーバーを実践活用する — 設計から運用まで、無人運用での権限設計は無人で動くエージェントに渡す MCP ツールを絞り込む、複数サービスを束ねる全体像はCowork × 複数 MCP オーケストレーションも合わせてご覧ください。

同じように参照先を増やしながら運用している方の、棚卸しのきっかけになれば幸いです。