Anthropic Simonテストが浮き彫りにするカスタムMCP接続の摩擦
Anthropicを観察してきたSimon Willison氏は、1つのカスタムMCPサーバーをClaudeとChatGPTに接続した。しかしこの実験では、セットアップ手順が大きく異なることが明らかになった。同氏が7月29日に行ったテストは、製品上の制約、リモートホスティングの要件、認可作業があるにもかかわらず、標準的なチャットインターフェースから開発者作成ツールを利用できることを示した。
anthropic simonの実験が重要なのは、Model Context Protocolがコーディングエージェントやデスクトップの設定ファイルの枠を超えつつあるためだ。AIアプリケーションを外部ツールやデータに接続するオープンプロトコルであるMCPは、日常的なチャット画面にも広がっている。これにより利用者層は拡大する一方、製品レベルの制約を無視しにくくなっている。
Claudeはこの接続をカスタムコネクターとして提示する。ChatGPTでは、同等の機能がappsシステムと開発者向けコントロールの背後に置かれている。どちらもリモートサーバーに接続できるが、そのサーバーを汎用的に持ち運べるプラグインへと変えるわけではない。プロトコルが通信を標準化する一方で、検出、権限、承認、利用可否は依然として各ホストが管理する。
Simon Willison氏のMCPテストが実際に変えたこと
ユーザーは標準的なWeb会話画面を離れることなく、1つのカスタムMCPサーバーをClaudeとChatGPTの両方で利用できるようになった。
Willison氏は、2026年7月29日に公開したcustom MCP testでその手順を記録した。中心的な結果は明快だった。開発者はMCPサーバーをホストし、両サービスに登録することで、通常のチャットインターフェース内にツールを公開できる。
この点が、この実験をClaude Code、デスクトップの設定ファイル、あるいは開発者向けクライアントを中心とした従来のMCPデモと区別する。これらの環境では、すでにツール接続が比較的自然に行えた。標準的な消費者向けチャット製品では、アカウント規則とインターフェース制御という別の層が加わる。
サーバーはリモートから到達可能でなければならない。標準入力・出力トランスポートを利用するローカルプロセスは、ブラウザーセッション内にそのまま表示できない。ホストには、各クライアントが期待するMCPの要素を実装した、インターネットからアクセス可能なHTTPエンドポイントが必要となる。
リモートアクセスはデプロイモデルを変える。開発者はもはや、個人のコンピューター上で信頼された1つのプロセスを起動するよう、1つのアプリケーションを設定するだけではない。開発者は、トランスポートセキュリティ、ID、認可、可用性、そして場合によっては複数のユーザーを扱うネットワークサービスを運用することになる。
Claudeは、これらの統合をカスタムコネクターと呼ぶ。Anthropicは、リモートMCPサーバーを通じて、Claudeをホストされたツールやデータソースと接続できるとしている。現在のconnector guidanceでは、対象となる個人アカウントおよび職場アカウント向けにClaudeとClaude Desktopのサポートが記載されている。
ChatGPTは、同じ大枠の機能をカスタムappsとMCPコネクターを通じて説明している。OpenAIのインターフェースでも、appの作成、テスト、承認、ワークスペース内での利用可能化が区別されている。
この名称の違いは、単なる見た目の問題ではない。「コネクター」は既存サービスへの橋渡しを示唆する。「App」は、ホストが管理する製品画面を通じてパッケージ化、レビュー、配布されるものを想起させる。MCPはどちらのモデルも支援できるが、ラベルはユーザーの期待を形づくる。
サーバーには、有用なツール定義も必要だ。これらの説明は、各ツールの機能、呼び出すべき場面、受け付ける入力をモデルに伝える。技術的に有効なエンドポイントであっても、ツールが重複していたり説明が曖昧だったりすれば、十分に機能しない可能性がある。
したがってWillison氏のテストが示したのは、プロトコル層における相互運用性であり、製品間で同一の挙動が得られることではない。ClaudeとChatGPTは同じ基本的な機能を検出できる。それでも、ツールの選択、要求する承認、結果の提示方法は異なり得る。
開発者にとって印象的なのは、両社が何らかの形でMCPをサポートしているという事実ではない。重要な変化は、1つのホスト実装が現在では両方の主要チャット製品内のユーザーに届くことだ。これにより、完全に別々の統合プロトコルを2つ維持せずとも、製品横断のテストが現実的になる。
Anthropic Simonの結果が両AIプラットフォームに与える圧力
MCPは、競争の一部をモデルの知能から、ツール、権限、配布の管理へと移している。
anthropic simonの結果は、MCPを作成し、オープン標準として推進してきたAnthropicに圧力をかける。Claudeは説得力のあるリファレンスクライアントであり続けなければならない。外部サーバーが他所でより予測可能に動作するなら、プロトコルの創始者であることだけではプラットフォームの優位を保証できない。
OpenAIは逆の圧力に直面する。同社はMCPを生み出したわけではないが、ChatGPTはアプリケーションプラットフォームとして非常に大きな役割を持つ。開発者は、すでにClaudeや他のMCPクライアントで動く統合をChatGPTでもサポートすることを期待するだろう。
ここには、プロトコルの可搬性とプラットフォーム制御の明確な競争がある。開発者はツールを一度記述し、互換性のある製品間で接続したい。プラットフォーム運営者は、どのアカウントがサーバーを接続できるか、どの操作を許可するか、リスクの高い呼び出しをどのようにレビューするかを決定したい。
Claudeは現在、複数のアカウント種別で直接的なカスタムコネクターの概念を提供している。コネクターは企業データを公開したり操作を実行したりできるため、職場での利用には管理者コントロールが導入される。所有者は利用可否を設定できる一方、個々のユーザーは自身の権限に基づいて認証を行う。
ChatGPTは、より明示的なデプロイ構造を採用している。OpenAIの現在のdeveloper mode guideによると、完全なMCPサポートはWeb上のBusinessおよびEnterpriseまたはEduの顧客向けに提供されている。また、Proユーザーには、より限定的な読み取りおよび取得アクセスが説明されている。
サーバーが書き込み操作を公開する場合、この違いは重要になる。ドキュメントコレクションを検索することには1つのリスクプロファイルがある。顧客記録の更新、コンテンツ公開、プロジェクト削除には別のリスクがある。
OpenAIによれば、書き込みや変更の操作は、権限、文脈、想定される影響に応じて確認を求める場合がある。特にリスクの高い操作はブロックされることもある。ワークスペース管理者は、appをプライベートテストから承認済みの利用可能な状態へ移すかどうかも管理する。
Anthropicも同様に、ツール要求を確認し、会話に関連するツールだけを有効にするようユーザーに助言している。この警告は、エージェント型インターフェースにおける基本的な制約を反映している。自然言語による要求だけでは、モデルが必要だと判断する可能性のあるすべての外部操作が常に明らかになるとは限らない。
こうした制御は、最も単純な可搬性の約束を弱める。開発者はサーバー、スキーマ、認可基盤を再利用できる。しかし、アクセス、ユーザーフロー、確認の挙動、モデルの判断まで一致するとは想定できない。
この分断は、必ずしもプロトコルの失敗ではない。MCPはクライアントとサーバーの間の共通言語を定義する。すべてのホストに同じ製品ポリシーの採用を求めるものではない。
それでも、実際には製品上の摩擦がプロトコル互換性の重要性を左右し得る。管理者設定の奥に隠れた接続は、個人設定画面から利用できる接続よりも到達するユーザーが少なくなる。読み取り専用の実装は、慎重に承認された書き込みを許可する競合製品の代替にはならない。
ツール呼び出しの品質も、もう1つの圧力要因となる。モデルは正しいツールを選び、有効な引数を生成し、エラーを解釈し、結果を伝えなければならない。MCPトランスポートをサポートしていても、ユーザーのタスクを確実に完了できるとは限らない。
そのため開発者は、同じプロンプトを両プラットフォームでテストすべきだ。サーバーが同一のツールを公開していても、異なる呼び出しパターンを生む可能性がある。こうした違いは、説明に曖昧さがあるのか、あるいは一方のホストがより厳格な制御を適用しているのかを明らかにできる。
より大きな競争上の問いは、ClaudeまたはChatGPTがAPIを呼び出せるかどうかではなくなっている。両プラットフォームとも可能だ。問題は、どちらが外部機能を一般ユーザーにとって理解しやすく、管理しやすく、信頼できるものにできるかだ。
1つのプロトコルが生む2つのセットアップ体験
MCPは統合コードの重複を減らすが、安全な接続を取り巻く運用上の手順までは取り除かない。
Claudeでは、基本的な経路はSettingsとConnectorsを通る。ユーザーはカスタムコネクターを追加し、リモートサーバーのアドレスを入力し、サーバーが必要とする場合は認証を完了する。職場の所有者は、先にコネクターを有効化または設定する必要がある場合がある。
Anthropicのserver documentationは、開発者にプロトコルの認可仕様と公式SDKの例を参照するよう促している。また、現在のリモート認可パターンをサポートしていることも記載している。
ChatGPTでは、Appsと高度な設定を経由する。ユーザーまたは管理者は開発者アクセスを有効にし、appを作成し、リモートMCP URLを入力し、認証方法を選び、カスタムサーバーに関連する警告を受け入れる。
Businessワークスペースの管理者は、自身のワークスペース向けにappsを作成してデプロイできる。EnterpriseおよびEdu環境では、開発者とユーザーに対するロールベースの制御が追加される。これらの規則により、接続は単なる個人設定ではなく、組織ガバナンスの一部となる。
共有される技術的な中核は、リモートMCPエンドポイントだ。現代的なリモートサーバーでは、MCPメッセージをHTTPリクエストとストリーミングレスポンスで運ぶトランスポートであるStreamable HTTPが一般的に利用される。このエンドポイントは、互換クライアントが期待する初期化とツール検出のやり取りをサポートしなければならない。
MCPメッセージは、リクエスト、結果、通知、エラーのための構造化形式であるJSON-RPC 2.0を使用する。プロトコルは、クライアントがツールを検出し呼び出す方法を定義する。各ツールの背後にあるビジネスロジックまでは定義しない。
たとえば、非公開のリサーチサーバーを考えてみよう。保存済みドキュメントを検索するツールと、完全なレコードを取得するツールを提供できる。ClaudeとChatGPTは、同じエンドポイントからこれらの定義を検出できる。
それでも、開発者は誰がどのレコードを検索できるかを決めなければならない。この判断は、サーバーとその認可レイヤーに属する。一方のクライアントインターフェースでツールを隠すことは、データソース側でアクセスを強制する代替にはならない。
サーバーがユーザー固有のデータを扱う場合、OAuthが中心的な役割を果たす。クライアントはユーザーを認可フローに通し、アクセストークンを受け取り、保護されたMCPサーバーを呼び出す際にそのトークンを提示する。サーバーはデータを返す前にトークンを検証する。
MCPのauthorization specificationは、準拠するHTTP認可デプロイメントに保護リソースメタデータを求めている。このメタデータは、認可サービスの場所をクライアントに伝える。すべてのクライアントとサーバーの組み合わせをハードコードせずに検出を支援する。
ここで、簡単な実証が本格的なエンジニアリングプロジェクトへと変わる。サーバーには、安定したHTTPSアドレス、正しいメタデータ、リダイレクト処理、トークン検証、適切なスコープが必要になる。また、認可に失敗した際にクライアントが解釈できるエラーメッセージも必要だ。
クライアント登録も、別の互換性問題を生む可能性がある。動的登録やクライアントメタデータ文書をサポートするシステムもあれば、事前に作成されたクライアント識別子を求めるシステムもある。ある前提に基づいて設計されたサーバーは、両方のチャット製品でスムーズに認証できるようになるまで、適応が必要になる場合がある。
実用的な実装は、対象を絞った読み取り専用ツールから始めるべきです。たとえばチームは、承認済みのプロジェクトノートを1つの検索機能で公開できます。ユーザーは更新や削除の権限を付与せずに、どちらのアシスタントにも過去の意思決定を探すよう依頼できます。
このユースケースは、個人またはチームのナレッジベースへの自然な橋渡しにもなります。MCPはアクセス層を提供し、基盤となるシステムはインデックス作成、権限管理、保持、情報源の品質に引き続き責任を持ちます。
読み取り経路が機能した後、開発者はより精密なアクションを追加できます。各書き込みツールには、明確な目的と限定された範囲が必要です。「1件のタスクのステータスを更新する」は、「任意のプロジェクト操作を実行する」よりもレビューしやすくなります。
ツールの説明には、API契約と同じだけの注意を払う価値があります。モデルは、関数を呼び出すか判断する際にその説明を参照します。曖昧な名前は、誤った選択、繰り返し呼び出し、不必要なデータアクセスの可能性を高めます。
入力スキーマも曖昧さを拒否すべきです。アカウントを変更するツールには、安定したアカウント識別子を必須とする必要があります。複数のレコードに一致する可能性がある顧客名だけに依存すべきではありません。
レスポンスは、何が起きたのかをモデルが説明できるだけの構造化情報を返す必要があります。書き込みツールには、変更されたオブジェクト、その変更前の状態、変更後の状態を含められます。これにより、ホストは意味のある確認を提示できます。
テストは、成功する呼び出しだけを対象にしてはなりません。開発者は、有効期限切れのトークン、取り消された権限、利用不能な依存関係、不正な入力、他ユーザーのレコードへのアクセス試行をテストすべきです。2つのホストでは、こうした失敗の表示方法が異なる可能性があります。
これは、オープンなプロトコルであるにもかかわらず、カスタムサーバーの追加に時間がかかると感じられる理由を説明しています。MCPは、統合の重複の一部を解消します。しかし、デプロイ、アイデンティティ、セキュリティレビュー、製品設定、品質保証までは解消しません。
真のトレードオフはポータビリティと信頼
1つのサーバーが複数のアシスタントに接続できる同じ開放性によって、そのサーバーはユーザー、モデル、機密システムの間で特権的な位置を得ることにもなります。
カスタムMCPサーバーは、そのツールを通じて送られる入力を確認できます。また、モデルがコンテキストとして扱うコンテンツを返す可能性もあります。アクションを公開している場合、ユーザーのアイデンティティのもとで外部データを変更することもあります。
この組み合わせにより、複数の信頼境界が生じます。ユーザーは、チャットプロバイダー、MCPサーバー運営者、接続先サービス、認可実装を信頼しなければなりません。組織は、モデルの挙動を導く説明も信頼する必要があります。
プロンプトインジェクションは大きな懸念です。悪意ある指示は、ドキュメント、サポートチケット、Webページなど、ツールが取得したデータの内部に埋め込まれる可能性があります。モデルは、そのコンテンツを信頼できない素材ではなく指示として解釈するかもしれません。
複数のツールが利用可能になると、リスクは高まります。取得したコンテンツが、機密性の高い引数を使って別のツールを呼び出すようモデルを説得しようとする可能性があります。そのため、読み取り操作が意図しない書き込みシーケンスの起点になることがあります。
AnthropicとOpenAIはいずれも、信頼できるサーバーだけに接続するようユーザーに警告しています。この助言は必要ですが、信頼だけでは完全なセキュリティ制御にはなりません。善意のサーバーであっても、認可のミスや過度に広範なアクションを含む可能性があります。
サーバーは、すべてのリクエストを独立して検証しなければなりません。ClaudeやChatGPTが生成した呼び出しだから安全だと決して仮定すべきではありません。ホスト側の確認はユーザーの助けになりますが、サーバー側のアクセスチェックに取って代わるものではありません。
トークンの取り扱いには特に注意が必要です。MCP仕様は、サーバーがあるサービス向けのトークンを別のサービスに転送するトークンパススルーを禁止しています。トークンには定義された対象者が必要であり、受信側サーバーはその対象者を検証すべきです。
最小権限は、最も明確な出発点です。リサーチコネクターは、書き込みアクセスを求める前に読み取りアクセスを要求すべきです。カレンダーツールは、空き状況の一覧表示だけが必要な場合に削除権限を要求すべきではありません。
書き込み操作も、限定的な意味を持つことが有益です。delete_everythingというツールは明らかに危険ですが、広範な管理機能は、より親しみやすい名前の裏に同様のリスクを隠す可能性があります。各アクションは、レビュー可能なユーザーの意図に対応すべきです。
影響の大きい操作では、意図しない繰り返しによって複数の変更が生じることを防ぐ冪等性もサポートすべきです。モデルは、応答が不明確な後に再試行する可能性があります。保護策がなければ、1つの依頼されたタスクが重複したレコードやメッセージを作成する恐れがあります。
監査ログも同様に重要です。運用者は、どのユーザーが呼び出しを認可したか、どのツールが実行されたか、どのオブジェクトが変更されたか、ホストが確認を報告したかを把握する必要があります。ログでは、不必要なプロンプト内容やシークレットを保持しないようにすべきです。
サーバー運営者は、ユーザー向けデータと制御指示を分離すべきです。ツール結果では、信頼できないテキストを明確にラベル付けし、可能な場合は構造化フィールドを返せます。モデルは依然として操作に脆弱ですが、慎重な出力設計は曖昧さを減らします。
ホストプラットフォームにも未解決の問題があります。その承認プロンプトは、ユーザーがアクションを理解するのに十分な情報を提供しなければなりません。ツールが複数の操作を実行できる場合、「ツールアクセスを許可する」という一般的な要求ではほとんど保護になりません。
ツールの挙動は接続後に変わる可能性があります。Anthropicは、サーバー開発者が警告なしにツールを変更できると明示しています。無害な検索コネクターを承認したユーザーが、後に同じエンドポイントからより広範な機能に遭遇することもあり得ます。
バージョニングとレビューは、このリスクを低減できます。組織はデプロイを固定し、スキーマの変更を監視し、ツールが書き込みアクセスを得る際に再レビューを要求できます。公開サーバーの運営者は、変更履歴を公開し、スコープを安定させることができます。
データ移動をめぐるプライバシー上の問題もあります。企業は、アシスタントによる内部レコードの検索を許可する一方で、それらのレコードが別の処理事業者に渡ることを禁止するかもしれません。MCPサーバーのホスティング場所と保持ポリシーも判断の一部になります。
したがって、安全なデプロイには有効な接続以上のものが必要です。チームは、データカテゴリー、許可されたアクション、認証スコープ、保持ルール、インシデント連絡先、取り消し手順を文書化すべきです。また、各ホストがツール利用をどのように報告するかもテストすべきです。
anthropic simonのデモは、クロスプラットフォーム接続が可能であることを示しています。しかし、到達可能なすべてのサーバーが本番環境に適していることを示すものではありません。互換性は評価の始まりであり、終わりではありません。
この違いは、好みのアシスタントから非公開ノートやプロジェクト履歴にアクセスしたいナレッジワーカーにとって重要です。コネクターはツール間のコピー作業を減らせます。一方で、機密コンテキストが通過する経路を広げる可能性もあります。
このトレードオフを評価するチームは、管理されたアクセスのもとで公開してもよい情報から始めるべきです。承認済みのエンジニアリング文書を検索可能にしたコレクションは、すべての内部システムへの無制限なゲートウェイよりも安全です。
その後、アシスタントが正しい情報源を見つけ、権限を尊重し、ツール利用を明確に説明するかを測定できます。拡張は、単にMCPエンドポイントが利用可能であることではなく、証拠に基づいて進めるべきです。
Anthropic Simonの実験が示す、今後注視すべき点
MCPにとって次の試験は、クロスプラットフォームサーバーが高度な設定を通じて組み立てられる専門的な統合ではなく、日常的な製品になるかどうかです。
最初のシグナルは、リモート認可をめぐる収束です。ClaudeとChatGPTはいずれも、組み合わせごとにカスタム登録作業を行わずに、ユーザーを安全に接続する必要があります。標準準拠のOAuthデプロイメント1つが両方で確実に機能すれば、より広範な採用が強まるでしょう。
認可がクライアント固有の例外だらけのままであれば、ポータビリティという主張は弱まります。開発者はサーバーの一部を再利用できても、別々のセットアップ手順、メタデータ、トラブルシューティング経路を維持することになります。
最も強い証拠は、一般的なサービスが複数のアシスタント向けに検証済みの手順とともに1つのリモートエンドポイントを公開することから得られるでしょう。これらのサービスは、ユーザーに長期間有効なAPIキーをチャット設定へ貼り付けさせるべきではありません。ブラウザベースの同意により、限定的で取り消し可能なスコープを付与すべきです。
2つ目のシグナルは、OpenAIが完全なMCPアクセスをどのように拡大するかです。現在のドキュメントでは、管理された職場アカウントに対する完全なサポートと、より限定的なPro機能が区別されています。より広い個人向け経路が提供されれば、Claudeのカスタムコネクター体験に直接的な圧力がかかるでしょう。
管理者によるデプロイを引き続き重視するなら、異なる戦略を示すことになります。ChatGPT appsは主にガバナンスの効いた職場ソフトウェアとして機能し、Claudeは個人による実験へのより直接的な経路を維持できるでしょう。
どちらの経路が自動的に優れているわけでもありません。企業には承認、監査可能性、ロール管理が必要になることが多いです。独立系開発者は、デプロイ済みサーバーから機能する会話へ至る短い経路を重視します。
3つ目のシグナルは、両プラットフォームが書き込みアクションをどう扱うかです。検索と取得は有用なデモになりますが、MCPが真のアプリケーション層になるかを決めるのはアクションです。同時に、最も難しいセキュリティとインターフェースの問題も生み出します。
より明確な権限の要約、アクションのプレビュー、確認ポリシー、監査記録に注目してください。外部への影響を十分に説明するホストは、書き込みツールがリスクフリーであるふりをせずに、その使いやすさを高められます。
開発者は、ホストがより優れた診断機能を公開するかも注視すべきです。接続の失敗は、複数の原因候補を1つのエラーに集約してしまうことがよくあります。問題は、トランスポートネゴシエーション、認可メタデータ、リダイレクト設定、トークンの対象者、ツールスキーマ検証に関係している可能性があります。
より良い診断機能は、動作するローカルサーバーから信頼できるリモート統合へ至る道のりを短縮します。また、サーバー運営者が異なるホストの期待値をリバースエンジニアリングする必要性も減らします。
レジストリとディスカバリーシステムも、もう1つの重要な層です。オープンなプロトコルは、どのサーバーが信頼できるかをユーザーに教えてはくれません。キュレーションされたディレクトリは役立ちますが、プラットフォーム所有者に別の制御点も与えます。
あるホストに掲載されたサーバーが、別のホストでは手動のカスタム接続のままである可能性があります。実装がポータブルであっても、開発者は配布の問題に直面します。レビュー期間と掲載ルールは、競争上の差別化要因になり得ます。
したがって、ユーザーはサーバーの互換性とサーバーの可用性を区別すべきです。サービスは技術的にはClaudeとChatGPTの両方で動作しても、見つけにくい、あるいはワークスペースポリシーによって制限されている場合があります。
同じ区別はインターフェースサポートにも当てはまります。MCP Appsは互換性のあるホストでインタラクティブなインターフェースを返せますが、基本的なツールサーバーは主に構造化データとテキストを交換します。同じ基盤プロトコルを使っていても、サポートレベルの違いにより、一方の統合のほうが豊かに感じられることがあります。
ビルダーにとって、当面の戦略は保守的です。標準準拠のリモートサーバーをホストし、対象を絞った読み取りツール1つから始め、両製品で同じプロンプトをテストします。認証、ディスカバリー、呼び出し、エラー処理におけるあらゆる違いを記録してください。
次に、明示的な認可の背後で限定的な書き込みアクションを導入します。再試行で変更が重複しないこと、取り消しが機能することを確認してください。アクション実行前に各プラットフォームが何を表示するかを正確にレビューします。
組織にとって、判断はMCPへの熱意ではなく、ワークフローから始めるべきです。チャットベースのアクセスによって実際の切り替えや検索の労力を減らせる反復タスクを1つ特定します。次に、それを完了するために必要な最小限のデータとアクションの範囲を定義します。
有力な候補としては、承認済みの技術文書を検索して情報源へのリンクを返すものが考えられます。別の候補は、公開せずにプロジェクト更新の下書きを作成するものです。どちらも、最終的な変更を人間の管理下に置きながら価値を生み出します。
「anthropic simon」で検索する人は、おそらくSimon Willison氏の特定の実験を探しているだろう。このテストの持続的な価値は、セットアップ手順そのものよりも広い。プロトコルの標準化がどこで終わり、プラットフォームのポリシーがどこから始まるのかを明らかにしている。
MCPは、ClaudeとChatGPTの標準インターフェースにおいて重要な境界を越えた。次に問われるのは、信頼できるサーバーへの接続が、一般ユーザーにとってありふれた、予測可能で、見えるものになるかどうかだ。
開発者はいま、この問いに答える手助けができる。低リスクなワークフローを1つ選び、権限を限定したリモートエンドポイントを構築し、同じテストプロンプトで両方のホストを比較してほしい。その違いは、MCPが実用的なポータビリティを実現しているのか、それとも共有された技術基盤にとどまっているのかを示すだろう。
