OpenAI の MCP docs は「対応しました」で終わらない責任分界を見せる

要点

要点まとめ

この docs の一番大事な点は、「MCP 対応」と言うだけでは足りず、誰に何を見せ、どこで認証し、どこまで server 側が責任を持つかまで説明しろと迫っていることだ。
争点は接続可否ではなく、導入審査で『この接続は何をし、どこで止まり、誰が管理するのか』を言葉にできるかにある。
OpenAI はそのために、tool の説明情報、読み取り専用データ、承認設定、認証方式、Apps 連携まで一枚で見せている。
読後にやるべきことは schema を足すことではなく、自分の MCP server で『公開するもの』『実行させるもの』『認証で守るもの』を分けて書き出すことだ。

読解

何が変わったのか

OpenAI のこの page は、MCP server を ChatGPT Apps や API integrations につなぐ時の実装責務をまとめています。`descriptor` は server や tool が何者かを host に伝える説明情報、`resource` は読み取り用の文脈データです。さらに `/responses` の `tools` 配列へ `type: "mcp"`、`server_url`、`allowed_tools`、`require_approval` を入れる例まで出しており、host 側にどう露出するかも API 設計の一部だと示しています。認証でも OAuth と `Client ID Metadata Documents` を前に出し、『MCP でつながる』だけで終わらず、『どの client を誰として扱うか』まで server 側責務として明文化したのが変化点です。

日本の文脈

なぜ重要か

日本のチームでは MCP が便利な接続規格として先に走りがちですが、本番では protocol 名より責任分界の説明が問われます。PM や導入担当者が気にするのは『MCP だから安心』ではなく、『どのデータを誰に見せ、承認はどこで入り、認証は誰が持つのか』です。この docs の価値は、その説明を実装と同じ紙に戻してくれることです。tool、resource、approval、auth、Apps 連携が別件ではなく、同じ導入面だと分かれば、実装レビューと社内審査を切り離しにくくなります。

技術ポイント

技術的ポイント

`descriptor` は server や tool の意味を host に伝える説明情報で、名前だけで誤読させないための土台になる。
`resource` は読み取り専用で参照させる文脈データだ。実行系 tool と混ぜないほうが責任分界を説明しやすい。
`/responses` では `type: "mcp"` の tool 定義に `server_url`、`allowed_tools`、`require_approval` を持たせられる。host 側露出の絞り込みも API 入力だ。
OAuth と `Client ID Metadata Documents` は、remote MCP server に来る client を誰として扱うか決める認証土台で、接続できることと安全に許可できることは別問題だ。
Apps integration まで視野に入っているため、MCP は text tool だけの話ではない。UI 側で何を見せるかも責任範囲に入る。

用語

英日キーワード

英語	日本語	補足
descriptor	ディスクリプタ	server や tool の意味を host に伝える説明情報。名前だけで誤読させないための土台になる。
resource	リソース	読み取り用に渡す文脈データ。実行系 tool と分けると責任分界を説明しやすい。
allowed_tools	許可ツール一覧	host 側へ見せてよい tool の絞り込み。全部公開しないための入口になる。
require_approval	承認必須設定	実行前に host 側で確認を求める境界。危険操作を無条件で流さないために使う。
Client ID Metadata Documents	クライアントIDメタデータ文書	OAuth client の登録前提や識別情報を伝える文書。remote MCP server の認証設計で出てくる。

試す

試すなら

自分の MCP server で、『読ませるだけのもの』と『実行させるもの』を分けて棚卸しする。
host に全部の tool を見せる前提をやめ、`allowed_tools` 相当で公開範囲を絞る。
承認が必要な操作を先に分類し、`require_approval` をどこで使うか決める。
remote server なら OAuth と client metadata を実装前に決めて、誰を client と見なすのかを文書化する。

注意

注意点

MCP に対応しただけでは、認証や UI 連携の責任は消えない。そこを host 任せにすると本番審査で止まりやすい。
この page は OpenAI integration 文脈の guide なので、他 host で同じ承認 UI や運用動線になるとは限らない。
`Published date` は docs page 上で確認できなかった。

この記事は役に立ちましたか

公益的に続けるため、役に立った点や読みづらかった点だけを短く送れます。メールアドレスは不要です。