
「在庫管理システムの画面を確認するために、Claudeでの作業をいちいち中断してタブを切り替えるのが面倒」。
そんな声を耳にしたことがある情シス担当者もいるはずです。
2026年7月28日、AnthropicはMCP(Model Context Protocol)の大型仕様更新「MCP 2026-07-28」をClaudeに順次導入すると発表しました。
この更新に含まれる「MCP Apps」という拡張を使うと、社内システムの操作画面をClaudeのチャット内に直接表示できるとされています。
ただし、既存システムをつなぐだけで自動的に画面が出てくるわけではありません。
情シス側での事前の連携設定があってはじめて、現場が恩恵を受けられる仕組みです。
MCP Appsは、MCPサーバーがテキストの応答に加えて、インタラクティブなUI(画面)を返せるようにする拡張仕様です。
Model Context Protocol公式ブログによると、この仕組みはサンドボックス化されたiframe内でUIを描画し、ユーザーがコネクタの動作を見ながらチャットを離れずに操作できるようにするものだとされています。
ダッシュボードや入力フォーム、複数ステップの申請フローなど、幅広いUIをチャット内に表示できるようです。
技術的には、ホスト(Claude側)がMCPサーバーからUIリソースを取得し、サンドボックス化されたiframe内に描画したうえで、JSON-RPC over postMessageという方式で双方向にやり取りする構成になっています。
iframeは親ページの情報にアクセスしたりCookieを盗んだりできない設計だとされており、社内システム側のサーバー作者を全面的に信頼しなくても、比較的安全にUIを描画できる仕組みという説明です。
とはいえ、これはあくまで仕組み上の話です。
実際の安全性は、後述するように運用ルール次第の部分も残ります。
| 項目 | 内容 |
|---|---|
| 対応プラン | MCPコネクタの追加・管理はClaude Platform DocsによるとTeam・Enterpriseプランでは管理者のみが行えるとされています |
| 必要な準備 | 社内システム側にMCP Apps対応のMCPサーバーが必要(既存のMCPサーバーを拡張するか、新規に構築する必要があるとされています) |
| 設定場所(組織単位) | 組織設定 > コネクタ(Team・Enterpriseのオーナー向け) |
| 設定場所(個人単位) | claude.ai/customize/connectors |
| 認証方式 | OAuthのClient ID・Secretによる認証、または2026-07-28仕様で追加されたエンタープライズ管理認証(IDプロバイダー経由でのアクセス権限の継承)が使えるとされています |
MCP Appsは便利な仕組みですが、社内展開の前に押さえておきたい誤解もあります。
| 過剰に期待しがちな点 | 実際に近いと考えられる状況 |
|---|---|
| 既存の社内システムをそのままClaudeに接続すれば画面が出る | 対象システムがMCP Apps対応のMCPサーバーを備えている必要があり、多くの場合は情シス側での開発・拡張作業が伴うとされています |
| iframeで隔離されているので何もリスクはない | サンドボックスによって親ページへの直接アクセスは防げるとされる一方、送信元を厳密に確認しないpostMessageの実装は情報漏えいの余地を残すという指摘があります |
| 社内製のMCPサーバーだから無条件に信頼してよい | エンタープライズでの導入では、自社製であっても各UIを未信頼なものとして扱い、ツール呼び出しに承認を求める設計が推奨されているようです |
| 導入すればどのAIチャットからでも同じように使える | MCP Appsはオープン仕様であるため他クライアントでの実装も可能とされていますが、現時点でどこまで同等に動くかはクライアントごとに確認が必要です |
在庫管理や経費精算など、すでにAPIを持つ社内システムがある場合、そのAPIをラップする形でMCP Appsに対応したMCPサーバーを用意します。
既存のMCPサーバーをMCP Apps対応に拡張した実践例も紹介されており、ゼロから作るよりも既存資産を活かせる場合があるようです。
情シスの管理者が組織設定からMCPサーバーを登録し、利用できるツールや操作範囲をコネクタ単位で制御します。
経理部門には経費精算システムのみ、倉庫部門には在庫管理システムのみといった形で、業務に必要な範囲だけを見せる設計にできるとされています。
チャット内のUIから「申請を送信する」といった書き込み系の操作を行う場合は、ユーザーの明示的な承認を求める設定にしておくことが推奨されています。
読み取り専用の確認作業と、実際にデータを変更する操作とで、承認の要否を分けておくと運用しやすいはずです。

在庫管理システムの在庫数や発注状況を確認するために、日常的に専用画面へログインしている担当者は少なくありません。
在庫管理システムがMCP Apps対応すれば、Claudeに「A倉庫の在庫を確認して」と話しかけるだけで、チャット内に在庫一覧の画面を表示させ、その場で発注申請の入力まで完結させられる可能性があります。
従業員から提出される経費精算の承認作業は、専用システムと社内チャットを行き来しながら進めることが多い業務です。
経費精算システムをMCP Apps対応にしておけば、Claude上のチャットで申請内容を確認し、そのままチャット内の画面で承認・差し戻しの操作ができるようになるとされています。
画面を切り替える手間が減るぶん、確認作業のスピードが上がる可能性があります。
社内からの「アカウントのパスワードをリセットしてほしい」といった定型的な依頼に対応するIT資産管理システムをMCP Apps対応にしておくと、Claude内で依頼内容を受け付け、対応状況を示す画面をそのまま表示させられます。
依頼者とのやり取りの記録がチャット内に残るため、対応履歴の追跡もしやすくなるはずです。
勤怠システムの打刻漏れや残業時間の確認作業は、月末になるとまとまった量が発生しがちです。
勤怠管理システムをMCP Apps対応にできれば、Claude上で対象者の一覧を絞り込みながら、修正が必要な打刻データをその場で確認・修正するといった使い方が考えられます。
もっとも多いつまずきは、対象システムがそもそもAPIを持っていない、あるいはAPIはあってもMCPサーバー化する開発リソースが確保できないというケースのようです。
ベンダー側がMCP Apps対応のコネクタを標準提供しているかどうかを先に確認しておくと、自前で開発する範囲を絞り込みやすくなります。
また、UIを描画するiframeを「安全だから」と過信せず、書き込み系の操作には必ず承認を挟む設計にしておくことも重要です。
postMessageの送信元確認が甘い実装は情報漏えいにつながる可能性があるという指摘もあるため、自社開発する場合は送信元の検証ロジックを丁寧に実装する必要があります。
社内展開の前に、セキュリティ担当者を交えたレビューを一度挟んでおくと安心でしょう。
MCP Appsは、Claudeのチャットとテキストのやり取りだけで完結していた社内システム連携を、実際の操作画面ごとチャット内に持ち込む拡張だとされています。
ただし、既存システムを自動的に対応させてくれる魔法の機能ではなく、情シス側でMCPサーバーを用意し、権限設計と承認フローを整えるという地道な作業が前提になります。
まずは社内でAPIを持つシステムを一つ洗い出し、小さな範囲でMCP Apps対応を試してみるところから始めるとよいでしょう。
そこで得られた知見が、他部署への展開ルールを作るための土台になるはずです。