mcptoolsclaudecodexopencodemulti-machine

最終更新: 2026-10-26

MCP サーバーを一度定義して、Claude Code、Codex、OpenCode で使う方法（すべてのマシンで）

MCP の JSON を3つのツールにコピー&ペーストするのをやめ、プロバイダーとマシンをまたいで一貫したツール群を使うための実践的な方法です。

すべてのガイド

MCP サーバーを一度定義して、Claude Code、Codex、OpenCode で使う方法（すべてのマシンで）

MCP の JSON を3つのツールにコピー&ペーストするのをやめ、プロバイダーとマシンをまたいで一貫したツール群を使うための実践的な方法です。

対象バージョン

CLI: 0.2.17
プレビュー ref: a2c45c8

MCP サーバーを「ちゃんと」セットアップしたことがあるなら、たぶんこんな手順を踏んだはずです。

MCP の JSON を Claude Code に貼り付ける
少し違う MCP の JSON を Codex に貼り付ける
OpenCode は別の場所を使うと気づく
同じことをノートPCとサーバーでもう一度やる

これでも動きます。

でも、どのマシンを使っているかでセッションの振る舞いが変わる原因にもなります。

本当に欲しいのは:

ツールは一度だけ定義する
一貫して使えるようにする
それでもマシン固有のツールはマシン固有のままにする

このガイドは、そのワークフローについてです。

要点

MCP を何に使いたいか決めます（ブラウザー自動化、GitHub、ドキュメント検索、社内ツール）。
よくある失敗は設定のずれです。マシンやプロバイダーごとに MCP の JSON が違ってしまいます。
より良いモデルは「1つのツールライブラリと明示的な適用範囲」です。
Happier では、MCP サーバーを一度定義し、既存のプロバイダーの MCP 設定を検出し、セッションで実際に使われるツール群をプレビューして、次の範囲に適用できます。
- すべてのマシン
- 1台のマシン
- 1台のマシン上の1つのワークスペース

課題

MCP は良い考え方ですが、素朴なセットアップ方法は壊れやすいものです。

複数の設定ファイル
複数のマシン
複数のプロバイダー

だから問題は「MCP を動かせるか？」ではありません。

問題は:

信頼できるくらい、ツールの構成を一貫させられるか？

よくある方法とトレードオフ

JSON をあちこちにコピー&ペーストする: 1台忘れるまでは動きます。
1つのプロバイダーだけで設定する: 移植性という目的そのものを失います。
ツールをプロジェクトごとにだけ持つ: 場合によっては良い方法ですが、GitHub のような共通ツールではつらくなります。

Happier を初めて使う場合

Happier を初めて見る方へ。Happier は、Claude Code、Codex、OpenCode などのセッションをマシンをまたいで動かすためのオープンソースのコンパニオンアプリ（モバイル/Web/デスクトップ）です。

ここで関係するのは、MCP サーバーを1か所で管理し、一貫して適用できる点です。

セットアップ:

スマホから Happier を使う方法
GitHub: https://github.com/happier-dev/happier
インストール/ダウンロード: https://github.com/happier-dev/happier#how-it-works
Discord（コミュニティとサポート）: https://discord.gg/W6Pb8KuHfg

動くワークフロー

1) ツールを JSON の山ではなくライブラリとして扱う

マシンが2台以上になった時点で、MCP の設定はインフラになります。

だからライブラリとして扱います。

保存されている
見直せる
範囲が決まっている

2) 「設定済み / 検出済み / プレビュー」で考える

Happier では、MCP サーバーは3つのタブに整理されています。

設定済み（Configured）: アプリで管理するサーバー
検出済み（Detected）: プロバイダーネイティブの設定ファイル（Claude、Codex、OpenCode）で見つかったサーバー
プレビュー（Preview）: 特定のバックエンド、マシン、ワークスペースで実際に使われるツール群

プレビューが要です。

「このセッションには実際に何が見えるのか？」に答えてくれます。

3) 正しい範囲で適用する: すべてのマシン / 1台のマシン / 1つのワークスペース

ずれの多くは、範囲を明示しないことから生まれます。

うまくいくルール:

リモートの HTTP/SSE サーバー → すべてのマシン（All machines）
npx でインストールしたローカルの stdio サーバー → マシン（Machine、1台）
プロジェクトローカルのサーバー → ワークスペース（Workspace、1台のマシン上の1つ）

4) シークレットを JSON に入れない（トークンの漏えいを止める）

トークンを MCP の JSON に直接貼り付けるたびに、シークレットが散らばります。

シェルの履歴に残る
dotfiles に残る
スクリーンショットに写る
いずれうっかりリポジトリに入る

よりうまくいくのは:

シークレットを一度だけ保存する場所
埋め込まずに MCP 設定から参照する方法
それをマシン間で安全に再利用する方法

Happier は、MCP サーバーのヘッダー/環境変数の値として3つのソースに対応しています。

保存済みシークレット（Saved Secrets、推奨）
${MY_TOKEN} のようなマシンの環境変数の参照
プレーンテキスト（本当に機密でない場合を除き避ける）

この「保存済みシークレット」が、複数マシンでの MCP を大きく楽にします。

シークレットを一度紐づければ、MCP サーバーの定義はマシン間で同じままにできます。

実例: Authorization ヘッダーを使う GitHub MCP サーバー（保存済みシークレット）

よくあるパターンは、次を必要とするリモート MCP サーバー（HTTP/SSE）です。

Authorization: Bearer <token>

トークンを JSON に一度も貼り付けずに済む、最初から最後までのセットアップです。

ステップ 1: GitHub トークンを作る

必要な最小限のスコープで GitHub トークンを作ります（classic PAT または fine-grained トークン）。

（必要なスコープは、呼び出す予定の MCP ツールによって変わります。リポジトリ、Issue、PR など。）

ステップ 2: トークンを保存済みシークレットとして保存する

Happier で:

設定（Settings）→ 保存済みシークレット（Saved Secrets）（または設定（Settings）→ シークレット（Secrets））
新しいシークレット（New secret）
わかりやすい名前を付ける（例: github_pat_work）
トークンの値を貼り付ける

これで値は設定ファイルではなく、Happier の暗号化された設定ストアに置かれます。

ステップ 3: Happier に GitHub MCP サーバーを追加する

Happier で:

設定（Settings）→ MCPサーバー（MCP servers）→ サーバーを追加（Add server）
リモート HTTP（Remote HTTP）または リモート SSE（Remote SSE）を選ぶ（サーバーの対応に応じて）
名前を付ける（例: github）

そして次を設定します。

適用先（Applies to）: 通常は すべてのマシン（All machines）（リモートサーバーは持ち運べるため）

ステップ 4: 保存済みシークレットで Authorization ヘッダーを設定する

MCP サーバーの設定でヘッダーを追加します。

ヘッダー名: Authorization
ヘッダーの値: Bearer <your-saved-secret>

大事なのは、シークレットをどう参照するかです。

トークンの値は貼り付けない
ヘッダーの値の欄で、保存済みシークレット（例: github_pat_work）を選ぶ/参照する

ヘッダーエディタでは、値のソースを選べます。

リテラル（Literal、プレーンテキスト）
保存済みシークレット（Saved Secret）

保存済みシークレット を選ぶと、Happier はシークレットの値ではなくシークレットへの参照を保存し、MCP サーバーのテストや起動時に解決します。

ステップ 5: テストしてからプレビューする

テスト（Test）で、Happier が次をできるか確認します:
- 保存済みシークレットの参照を解決する
- サーバーに接続する/起動する
- ツールを一覧表示する
プレビュー（Preview）（バックエンド、マシン、ワークスペース）で、目的のセッションに GitHub のツールが本当にあるか確認します。

テストは成功するのに、プレビューでそのセッションのツールが 0 なら、ほぼ範囲の不一致です（すべてのマシン / マシン / ワークスペース）。