Claude Media
ClaudeとPortを連携する方法 — サービス所有者とスコアカードを会話で引く

ClaudeとPortを連携する方法 — サービス所有者とスコアカードを会話で引く

開発者ポータルPortのMCPサーバーをClaudeにつなぐ手順です。EU・US区分のURL、読み取り専用ヘッダー、実行できるアクションの絞り込み、CIでのトークン認証まで、運用で迷う点を順に扱います。

Claude Port連携とは — 開発者ポータルのカタログを会話で引く仕組み

Claude Port連携は、開発者ポータル(IDP)のPortが提供するリモートMCPサーバーをClaudeにつなぐ仕組みです。サービスの所有者、依存関係、スコアカードの合否といったカタログの情報を、Portの画面を開かずに自然文で問い合わせられます。

LLMを動かすのはClaude側で、Portはカタログを扱うツールを公開するだけです。PortにはAIアシスタント機能の「Port AI」もありますが、MCPサーバーはPort AIの機能を使いません。有効化もPort AI利用規約への同意も不要です。

接続の可否は、Portの権限がそのまま決めます。見えるツールは自分のロール次第で、書き込み系のツールはヘッダーひとつで隠せます。この記事では、接続手順に加えて、この「どこまで触らせるか」の設計を中心に扱います。

コネクタ全般の仕組みはClaudeのコネクタ解説にあります。ここではPort固有の手順と運用に絞ります。

何が聞けるのか — 開発者向けツールの一覧

Portのドキュメントは、ツールを「Developer」と「Builder」の2つの役割に分けています。Developerはポータルを使う側で、サービスの検索、アクションの実行、データの分析に使うツールです。Builderはポータルを作る側のプラットフォームエンジニアや管理者で、Developerのツールに加えて構成を変えるツールを持ちます。

まずDeveloperが使える読み取り中心のツールです。

分類ツール用途
データモデルツールlist_blueprints用途ブループリント(データ型)の一覧。識別子を指定するとプロパティ定義まで返る
データモデルツールlist_entities用途ブループリントのエンティティを絞り込み・並べ替え・件数集計で取得
スコアカードツールlist_scorecards用途スコアカードの一覧。識別子指定でルール設定の全体が返る
アクションツールlist_actions / list_workflows用途アクションとワークフローの一覧
監査ツールsearch_audit_logs用途エンティティの監査ログを状態・操作・日付などで検索
全般ツールdescribe_user_details用途接続中のユーザーが属する組織やチームの情報
全般ツールsearch_port_knowledge_sources用途Portのドキュメントを検索して該当節を返す

list_entities には groupBy による値の分布と、countOnly による総数の取得があります。「本番のサービスは何件あるか」のような質問は、一覧を全部引かなくても件数だけ返せる設計です。

Portのドキュメントが例に挙げる質問は次のとおりです。いずれも、Claudeにそのまま投げる想定の文面です。

  • 「サービスXの所有者は誰か」
  • 「バックエンドチームが持つマイクロサービスを全部見せて」
  • 「OrderProcessing サービスの依存関係は」
  • 「セキュリティ要件のスコアカードで落ちているサービスはどれか」
  • 「InventoryService がGoldに届かない理由は何か」

所有者や依存関係は、Wikiや表計算で管理されているうちは更新が止まりがちです。Portに集約済みなら、そのデータがそのまま会話の入口になります。逆に言えば、カタログに入っていない情報は聞けません。回答の質はClaudeの賢さより、ブループリントとエンティティの整備度で決まります。

Claudeにつなぐ手順 — Claude.aiとClaude Codeの2経路

接続先のURLは、Portの組織のリージョンで決まります。

くらべる

リージョンで変わる接続先

標準

EU(app.port.io)

MCPサーバーのURLは https://mcp.port.io/v1 です。

リージョン違い

US(app.us.port.io)

MCPサーバーのURLは https://mcp.us.port.io/v1 です。

URLを取り違えると、組織に届きません。接続前に、ブラウザでPortを開いたときのドメインを確かめてください。

Claude.ai(デスクトップとWeb)の場合

Claudeのコネクタライブラリに、Portの公式コネクタが載っています。手順は次のとおりです。

手順

Claude.aiでPortコネクタを追加する

  1. 1

    Portコネクタのページを開く

    コネクタのページへ直接移動するか、コネクタを「Port」で検索します。

  2. 2

    Connectを押す

    ページの「Connect」を押します。

  3. 3

    MCPサーバーのURLを入力する

    求められたら、リージョンに合うURLを入れます。EUなら https://mcp.port.io/v1 です。

  4. 4

    ブラウザで認証する

    Portのサインイン画面が開くので、接続したい組織でログインしたまま承認します。

カスタムコネクタとして追加する場合は、公開するツールを作成時に個別に選べ、すべてを有効にする必要はありません。

Claude Codeの場合

Claude Codeからは、HTTPで直接つなぐのが推奨です。Node.jsもnpxもローカルのMCPサーバーも要りません。

claude mcp add --transport http port-eu https://mcp.port.io/v1 \
  --header "x-read-only-mode: 1"

USリージョンなら、名前を port-us、URLを https://mcp.us.port.io/v1 に置き換えます。登録後に claude を起動して /mcp を開き、port-eu を選んでブラウザ認証を済ませます。認証が通ると、利用できるツールが一覧に出ます。

動作確認の質問として、Portのドキュメントは「List my Port blueprints.」を挙げています。ブループリントの一覧が返れば、接続と権限の両方が通っています。

上のコマンドは、書き込みを許す x-read-only-mode: 0 の例を 1 に変えた形です。最初の接続を読み取り専用にすると、書き込みを開ける判断を後回しにできます。理由は次の節で述べます。

触らせる範囲を決める — 書き込みツールと実行アクションの絞り込み

Portは接続時のヘッダーで、できることを2段階に絞れます。

ヘッダー既定値効果
x-read-only-mode既定値0効果1 にすると書き込みツールが一覧から消える。0 は権限の範囲で全ツール
x-allowed-actions-to-run既定値すべてのアクション効果run_action で実行できるアクションを識別子のカンマ区切りで限定。空文字なら実行不可

x-read-only-mode: 1 は、書き込みツールを「拒否」するのではなく、ツール一覧から「隠す」動作です。Claudeはそのツールの存在を知らないので、うっかり呼ぶ経路自体がありません。

x-allowed-actions-to-run は、セルフサービスアクションを実行させたい場面で効きます。たとえば開発者のIDEセッションにはデプロイ系のアクションだけ、CIには雛形作成の1アクションだけ、という切り分けです。アクションの識別子は、Portのセルフサービスのページで、対象のアクションから確認できます。

ヘッダーを2本付けるときは、--header を1本ずつ書きます。

claude mcp add --transport http port-eu https://mcp.port.io/v1 \
  --header "x-read-only-mode: 0" \
  --header "x-allowed-actions-to-run: create_github_issue,create_incident"

すでに port-eu を登録済みでヘッダーを変えたいときは、claude mcp remove port-eu で一度消してから、変更後のヘッダーで claude mcp add をやり直します。登録内容は claude mcp get port-eu で確かめられます。

Claude Code側の許可ルールを重ねる

ヘッダーはPortのサーバーが効かせる制限です。Claude Code側にも、MCPツール単位の許可ルールがあります。ルール名は mcp__<サーバー名>__<ツール名> の形で、サーバー名は claude mcp add で付けた名前です。

次は、構成を変えるBuilder系ツールを拒否し、アクションの実行は毎回確認に回す設定例です。

{
  "permissions": {
    "deny": [
      "mcp__port-eu__upsert_blueprint",
      "mcp__port-eu__delete_blueprint",
      "mcp__port-eu__delete_entity",
      "mcp__port-eu__delete_scorecard"
    ],
    "ask": [
      "mcp__port-eu__run_action",
      "mcp__port-eu__trigger_run",
      "mcp__port-eu__upsert_entity"
    ]
  }
}

ここでのツール名は、Portのツール一覧にある名前です。deny に置いたツールは、Claudeの手元から外れます。ask に置いたツールは、実行のたびに承認を求められます。

ヘッダーと許可ルールは、片方だけでも成立しますが、役割が違います。ヘッダーは「このトークンで何ができるか」の上限を決め、許可ルールは「このPC、このリポジトリで何を許すか」の運用線を決めます。ヘッダーを 1 にしたうえで、許可ルールを重ねる必要は薄いのですが、0 で書き込みを使う場合には、2層の価値が出ます。

MCPサーバーの向こう側の権限設計の考え方は、MCPで本番環境に接続する権限設計に横断でまとめています。許可ルールの構文はMCPセキュリティガイドが詳しい記事です。

会話で何ができるか — 実運用の3つの場面

前節までの質問を、日々の運用に当てはめるとこうなります。以下はいずれも例示の質問で、実際の返答はカタログの中身で変わります。

場面

Port連携の使いどころ

  • オーナー調査

    障害対応のときに「このサービスの所有者とオンコール担当は誰か」を聞きます。カタログのチーム情報を引くだけなので、読み取り専用のままで足ります。

  • スコアカードの棚卸し

    「本番準備度のスコアカードで、Goldに届かないサービスを理由つきで並べて」と聞きます。ルールごとの合否を引けるので、改善の優先順位づけに使えます。

  • ポータル自体の設計

    Builder権限があれば、「本番準備度のスコアカードを新しく作りたい」と頼んで、ブループリントやアクションの案を作らせられます。

スコアカードの棚卸しは、Claudeにとって集計と整理が得意な領域です。「どのルールで落ちているサービスが多いか」を list_scorecards と list_entities から組み立てさせ、結果を表で出させると、レビューの下調べが短くなります。

一方、Builder権限での構成変更は、ポータルの設計図を書き換える操作です。upsert_blueprint は既存のブループリントがあれば更新し、なければ作成します。更新の対象を取り違えると、その型のエンティティ全体に影響します。変更前に list_blueprints で現状を確認させ、差分を文章で説明させてから実行する、という順序を依頼文に組み込むと安全です。

次は、構成変更の前に確認を挟ませる依頼文の例です。

upsert_blueprint を呼ぶ前に、次の順で進めてください。
1. list_blueprints で対象ブループリントの現在の定義を取得する
2. 現状と変更後の差分を日本語で説明する
3. 私が「実行してよい」と返すまで、書き込みツールは呼ばない

delete_blueprint の説明は「ブループリントと、その配下のすべてのエンティティを削除する」です。取り消しのきかない操作なので、前節のとおり deny に置いたままにしておくのが無難です。

複数の組織とSSO — 認証でつまずく3つの場面

Portは、ブラウザで開いているPortのOAuthセッションを使って接続を承認します。ここから、次のつまずきが生まれます。

切り分け

Port接続で認証が通らないときの切り分け

  1. Q認証前に、接続したい組織でPortにログインしていましたか?
    答えがいいえのとき

    別の組織のセッションで承認した可能性があります。接続したい組織に入り直してから、MCPクライアントの認証をやり直してください。

    答えがはい
  2. QSSOを使っている組織で、接続時のエラーは出ずに通りますか?
    答えがいいえのとき

    PortのSSO接続をドメインレベルに切り替える必要があります。この変更はPortのバックエンドでしかできないため、Portのサポートに連絡します。

    答えがはい

サポート対応後に再接続する

Dynamic Client Registrationを使うOAuthフローが通るようになります。設定が更新されたら、接続を再試行してください。

一度承認した後にブラウザのセッションを別の組織へ切り替えても、接続済みの組織は変わりません。複数の組織を同時に扱うなら、組織ごとに別の設定を追加し、それぞれの組織にログインした状態で承認します。port-eu と port-us のように、サーバー名で区別しておくと取り違えを防げます。

接続のセッションは、対話利用なら最長30日続きます。ただし15日間アイドルだと切れます。Cursorで一日おきに再認証を求められる場合は、Port側のセッションでなく、CursorのOAuth処理にある既知の問題が原因のことがあります。

CIから使う — クライアントクレデンシャルによる認証

ブラウザでの承認ができないCI/CDや無人のエージェントには、Portのクライアントクレデンシャルを使う方法があります。MCPの認証エンドポイントにクライアントIDとシークレットを渡して、アクセストークンを受け取ります。

curl -s -X POST "https://mcp.port.io/v1/token" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=client_credentials" \
  -d "client_id=YOUR_CLIENT_ID" \
  -d "client_secret=YOUR_CLIENT_SECRET"

USリージョンでは、URLを https://mcp.us.port.io/v1/token に置き換えます。返ってくるアクセストークンは短命で、有効期間はおよそ3時間です。client_credentials には更新トークンがないため、期限が切れたら同じ手順でもう一度取得します。クライアントIDとシークレットは長寿命の認証情報なので、個人のものでなく、自動化専用のサービスアカウントの資格情報を使い、CIのシークレット管理に置きます。

client_credentials のリクエストには、クライアントごとに15分あたり50回までのレート制限があります。MCP呼び出しのたびにトークンを取り直さず、期限が近づくまで使い回してください。

トークンを受け取った後は、mcp-remote に Authorization: Bearer ヘッダーを渡して接続します。GitHub Actionsでこの形のワークフローを組めば、Claude Codeから list_blueprints などを呼べます。allowed_tools には使うPortのツールだけを列挙し、読み取り用途なら x-read-only-mode を 1 にします。

CIで使うときは、ヘッダーと許可ツールの絞り込みが、そのまま最小権限の設計になります。ClaudeのGitHub Actions連携の下地は、組織へのGitHub Actions導入の手順にまとめています。

導入前に確かめたい点

接続する前に、次の4点を確かめておくと、手戻りが減ります。

  1. Portの組織のリージョン: EUかUSかで、接続先のURLが変わります
  2. 自分の役割: DeveloperかBuilderかで、見えるツールが変わります。Portでの権限が、MCP経由でもそのまま効きます
  3. 古いローカルMCPサーバーの残り: DockerイメージとuvxのパッケージによるローカルのMCPサーバーは、メンテナンスが終わっています。以前使っていたなら、そのエントリをMCPの設定から消してから、リモートサーバーへ移ります
  4. mcp-remote 経由の設定の残り: 過去に mcp-remote で追加した設定は、ローカルのプロキシを起動するため、初回にパッケージの取得が走り、接続が遅くなったりタイムアウトしたりします。HTTPで直接つなげるクライアントでは、直接つなぐ設定に置き換えるのが推奨です

Port連携の限界は、カタログの更新頻度にある

Port連携は、ツールの数より「何をカタログに入れているか」で価値が決まります。ブループリントに所有者の項目がなければ、「所有者は誰か」には答えられません。スコアカードのルールが少ない組織では、棚卸しの質問は薄い結果で終わります。

一方で、IDPがすでに運用に乗っている組織では、Wikiを探し回る手間が会話に置き換わります。既存の調査フローを置き換えるのでなく、最初の一手を短くする道具として始めるのが現実的です。

最初の一週間は、x-read-only-mode: 1 のまま、オーナー調査とスコアカードの棚卸しだけに使ってみてください。書き込みやアクション実行を開けるのは、回答の精度に納得してからで遅くありません。

まとめ

導入効果が出やすいのは、所有者やスコアカードをすでにPortで更新している組織です。カタログが空に近い段階では、接続を急ぐより先にブループリントの整備が先に来ます。

Builder権限を開けるかどうかは、構成変更の差分をレビューする担当が決まっているかで判断できます。担当がいなければ、x-read-only-mode: 1 のまま使い続けても、調査用途の価値はほとんど損なわれません。

この記事を共有:XはてブLinkedIn