MCP と GUI：企業の操作に適したインターフェースの選び方

意味を手がかりにチケットを探し、変更を準備するなら、エージェントとの対話が便利です。書き込み前に複数の項目を確認する場面では、変更前と変更後の値が見えるフォームが役立ちます。MCP はアプリケーションをツールにつなぎます。チケットを変更できるユーザーを決める責任は、業務システムにあります。

以下は社内サービスデスクを想定した学習用の例です。従業員がチケットを読み、新しい担当者を提案し、その変更を確認に回します。特定製品の完成済み連携を説明するものではありません。ツール名やフィールド名は設計用の例であり、導入前に選んだシステムで実装と検証が必要です。

読み取り、提案、書き込みを分ける

MCP のアーキテクチャでは、ホストアプリケーションがクライアントを介してサーバーとやり取りし、サーバーがツールなどの機能を提供します。適切な名前の tool があるだけで、ユーザーの業務権限が決まるわけではありません。

操作	最初に検討するインターフェース	利用条件
ユーザーが閲覧できるチケットを探す	MCP と対話	サーバーがユーザー権限に応じて結果を制限する
新しい担当者を提案する	MCP で下書き、フォームで比較	提案の段階では記録を変更しない
変更を確定する	GUI または検証済みの MCP Apps フォーム	対象項目を明示し、サーバーが権限と最新状態を再確認する

これはこの例に対する設計上の提案です。通常の GUI でも、重要な値が隠れていたり、保護が不十分な backend を呼んだりする可能性があります。実際の書き込み経路と、その検証結果を評価してください。

学習用チケット REQ-204 の担当者が team-a で、ユーザーは team-b に変えたいとします。対話で対象を見つけた後、保存前には ID、元の値、新しい値、変更の影響を示します。通知が送られるか、アクセス権が変わるか、外部の処理が動くかも確認します。タイトルの一致だけで対象を決めてはいけません。

確認を具体的な変更内容に結び付ける

内部の確認オブジェクトは、例えば次のようにできます。

{
  "ticket_id": "REQ-204",
  "expected_revision": "r17",
  "changes": {
    "assignee": {"from": "team-a", "to": "team-b"}
  },
  "mode": "proposal"
}

これはアプリケーション独自の構造で、MCP 標準ではありません。保存時にはサーバーが revision と権限を照合します。チケットがすでに変わっていれば、提案をもう一度表示する必要があります。「確認」ボタンが、別の diff を黙って適用してはいけません。

MCP 仕様の Tools 節は、呼び出しの可視性、ユーザーが操作を拒否できること、サーバー側の入力とアクセスの検証を扱っています。特定の確認画面を必須にしてはいません。そのため、MCP サーバーへの接続許可を、すべての企業操作への許可とみなしてはいけません。

timeout 後の再試行については、backend の動作を事前に決めます。応答が失われたら、保存してある操作 ID で結果を先に照会します。無条件の再試行は、通知や外部への作用を重複させるかもしれません。元の担当者に戻せても、変更のすべての影響を取り消せるとは限りません。

MCP Apps が適する場面

MCP Appsでは、対応クライアント内にサーバーツールの対話型 UI を表示できます。ホストは sandboxed iframe 内に描画します。選んだクライアントとサーバーのバージョンが拡張に対応していれば、会話内に項目比較フォームを置けます。

この例では、チケット、proposed diff、明確な「適用」「キャンセル」ボタンを表示できます。サーバーでの認可、revision の検証、結果ログは引き続き必要です。iframe の sandbox はサービスデスクの権限を代替せず、任意のサーバーを信頼できるものにするわけでもありません。

現在のクライアントで diff を確実に表示できない、社内確認を完了できない、必要なアクセシビリティを満たせない場合は、別の GUI を残します。モデルが使えなくても、ユーザーが ID で同じチケットを開き、実際の状態を確認できるようにします。モデルの障害で、保存できたかを推測させてはいけません。

試行環境を作る：モデルは BetterToken、チケットは MCP

試行では Claude Desktop をクライアントにし、API 設定ガイドに従って BetterToken 経由で Claude モデルに接続できます。Claude provider を利用できる自分の API Key と、Gateway Base URL https://bettertoken.ai を使います。利用バージョンの項目と条件はガイドで確認してください。まず短い通常メッセージへの応答を得て、モデル接続だけを検証します。

次に、選んだクライアントでサービスデスクのテスト用 MCP サーバーを接続し、機密情報を含まないチケット一件へのアクセスを試します。BetterToken はモデル API の層を提供します。サービスデスクの認証情報、ユーザー権限、書き込み確認は別に設定します。モデル接続の成功は、クライアントの特定モードでの MCP Apps 対応を証明しません。埋め込みフォームを選ぶ前に別途確認し、使えなければ GUI に確認を残します。

BetterToken 経由でテスト用のモデルを接続し、以下を検証してください。架空のデータを使います。モデルに渡す MCP の応答内容は API リクエストに含まれる可能性があります。実際の企業データを扱う許可は、組織のルールに従う必要があります。

障害時の動作で選択を検証する

テスト環境で、二つのロールと機密情報のないチケットを使います。一方のロールには担当者の変更権限があり、もう一方は許可された記録の読み取りだけができます。各検証の実際の結果を保存してください。次の表は期待する基準であり、実施済みテストの報告ではありません。

検証	期待する結果
ユーザーが閲覧できない他者のチケットを要求する	サーバーが内容を漏らさず拒否する
読み取り専用ロールが担当者変更を確定する	サーバーが書き込みを拒否する
ユーザーが proposed diff をキャンセルする	チケットが変わらない
表示後に revision が変わる	保存を止め、再表示を求める
保存後の応答が失われる	再試行を決める前に状態を確認する
モデルが利用できない	GUI で実際の状態を読める
キーボードと screen reader でフォームを使う	変更を理解し、確定またはキャンセルできる

検証に失敗した場合、その種類の書き込みは原因が直るまで既存の検証済み画面に残します。MCP による読み取りは別に評価できますが、読み取りにも権限と結果の制限が必要です。

後から確認できる記録を残す

この例では、ユーザー、チケット ID、合意した diff、元の revision、時刻、操作 ID、backend の結果を記録すると役立ちます。必要なく tokens や非公開チケットの全文をログに残さないでください。ログの保存期間とアクセス方針は組織のルールに従います。

試行後は、読み取りは対話、準備は下書き、書き込みは選定した検証済みフォーム、というように操作ごとに決定を記録します。拒否テストの結果と未解決事項の担当者を添えます。権限、確認、障害からの回復方法が明確な操作から MCP の利用を広げられます。