ChatGPT Appsとは？MCP・Apps SDKでできることと安全な使い方
ChatGPTの会話だけで資料を探したり、社内のタスクを起票したり、外部サービスの情報を参照したりしたい。そんな場面で出てくるのが ChatGPT Apps です。以前は「コネクタ」と呼ばれることもありましたが、現在はPlugin directoryを入口に、アプリ、スキル、テンプレートを組み合わせて会話の仕事を広げる形になっています。
ただし、Appsを「便利なプラグイン」とだけ捉えると危険です。ファイル検索だけをするAppと、外部システムにレコードを書き込むAppでは、必要な権限も失敗したときの影響もまったく違います。本記事では、利用者としてAppsを選ぶときの見方と、開発者がMCP・Apps SDKでカスタムAppを作るときの設計を、混同しやすい言葉を整理しながら解説します。
この記事の結論
- ChatGPT Appsは、会話から外部の情報・機能へ接続する入口である
- MCPは「ツールをどう公開するか」、Apps SDKは「会話内の体験をどう作るか」を担う
- 最初は読み取り専用の小さな用途から始め、書き込み操作は確認・許可リスト・監査ログを揃えてから有効にする
- Appを入れる前に、送信される情報、利用できる操作、管理者の設定範囲を確認する
本文図1：ChatGPT Appsは会話と外部サービスの間にあり、MCPでツールを接続し、必要に応じてApps SDKで会話内UIを提供する。
ChatGPT Appsを一言でいうと
ChatGPT Appsは、ChatGPTが外部サービスの情報や操作を会話の中で使えるようにする仕組みです。たとえばDriveの資料を探す、デザイン作成を支援する、チームのタスクを起票する、といった作業を、別タブへ何度も切り替えずに進められます。
重要なのは、AppそのものがAIモデルではないことです。Appは「どのサービスの、どの機能を、どの条件で会話に渡すか」という接続面です。モデルは依頼内容を解釈してAppの機能を使いますが、App側が公開していない操作を勝手に実行できるわけではありません。
2026年7月にはApp directoryがPlugin directoryへ移行しました。ここでいうPluginは、単体の外部連携だけでなく、特定の業務を進めるためのスキルやテンプレートも含み得る、より大きい配布単位です。一方で、外部データや外部操作へ実際に接続する部分はAppです。この区別を知っておくと、「何を追加したら、どこまでデータが届くのか」を確認しやすくなります。
よく混同する4つの用語
最初に、ChatGPT Apps、MCP、Apps SDK、Developer Modeを役割で分けます。
| 用語 | 主な役割 | 主に触る人 | たとえるなら |
|---|---|---|---|
| ChatGPT Apps | 会話から使う外部連携 | 利用者・管理者 | 仕事用の入口 |
| MCP | ツールやデータを公開する接続規約 | 開発者 | 共通の差し込み口 |
| Apps SDK | 会話内UIとApp体験を作る開発キット | 開発者 | 画面と接客の部品 |
| Developer Mode | カスタムAppを試験・設定する経路 | 開発者・管理者 | 検証用の作業場 |
Appsは利用者の視点、MCPは接続の視点
MCP（Model Context Protocol）は、AIが外部のツールやデータとやり取りするためのオープンな規約です。サーバー側が「検索」「取得」「作成」といったツールを定義し、クライアント側がその定義を理解して呼び出します。
ここで大切なのは、MCPを入れたからといって安全な自動化が完成するわけではないことです。MCPは接続方式であって、業務ルールそのものではありません。たとえばcreate_invoiceというツールを公開するなら、金額上限、対象顧客、実行前の確認、エラー時の停止、実行履歴といった安全設計は、ツール実装と運用側で別途決める必要があります。
MCPの基礎は「MCPとFunction Callingの違い」も参照してください。Function Callingがモデルへ関数仕様を渡す仕組みであるのに対し、MCPはツール群を発見・接続・運用するための共通レイヤーとして考えると整理しやすくなります。
Apps SDKは、会話内の体験を作る開発キット
Apps SDKは、MCPを基盤にしつつ、ChatGPT内で動くAppのロジックとインターフェースを設計するための開発キットです。単にテキスト結果を返すだけでなく、選択肢、結果一覧、確認画面のような対話的なUIを設計できます。
しかし、最初から凝ったUIを作る必要はありません。最小の価値は「必要な情報を、正しい権限で、再現可能に取り出せる」ことです。UIはその後に、比較や選択を人間がしやすくするために加えます。特に書き込みを伴うAppでは、実行前に対象・差分・影響範囲を示す確認UIの方が、派手なダッシュボードより価値があります。
Developer Modeは本番公開の代わりではない
Developer Modeは、カスタムAppを作成・試験するための経路です。利用可否や設定場所はプラン、Workspace、ロールで異なります。組織利用では管理者が有効化し、誰が開発・利用できるかを制御する形が想定されています。
試験用に接続できたことと、全社で安全に配布できることは別です。本番へ進める前に、Appが扱うデータ、認証方式、ツールの変更時の扱い、ログの保存先、利用者への説明をレビューしましょう。
利用者がAppsを選ぶときの確認手順
便利そうなAppを見つけたら、まず「できること」より「渡すもの」と「起こせる変更」を確認します。以下は個人利用でもチーム利用でも有効な順番です。
1. 目的を1文にする
「情報を探したい」のか、「内容を要約したい」のか、「外部サービスを更新したい」のかを分けます。目的が曖昧なまま複数のAppを有効にすると、必要のないサービスへ会話の文脈を渡す可能性が増えます。
良い最初の目的は、たとえば「指定フォルダの議事録を検索して候補だけ出す」です。悪い最初の目的は「全部つないで仕事を自動化する」です。後者は、検索、要約、作成、送信、権限管理という別問題を一度に抱え込みます。
2. 読み取りと書き込みを分けて見る
検索、取得、要約は主に読み取り操作です。一方、チケット作成、カレンダー変更、CRM更新、公開、メール送信は書き込み操作です。書き込みは便利ですが、誤った対象へ実行したときに元へ戻すコストが大きくなります。
まず読み取り専用で価値を確かめ、書き込みは別の段階で追加するのがおすすめです。書き込みを有効にする場合も、初期は対象を限定し、実行前の確認を残し、実行後に結果を照合できるようにします。
3. 接続時に表示される権限を読む
初回接続では、対象サービスとChatGPTの間でどの権限を渡すかが表示されます。ここで確認するのは、サービス名だけではありません。
- □ どの種類のデータへアクセスするか
- □ 検索・取得だけか、作成・更新もできるか
- □ 組織の共有領域まで対象になるか
- □ 接続を後から解除できる場所はどこか
- □ 管理者が許可・監査する範囲はどこか
権限の文言が期待より広い、用途と一致しない、解除方法が不明といった場合は接続を保留します。Appを使えない不便より、不要な権限を渡す損失の方が大きいことが多いためです。
4. 会話へ入れる情報を最小化する
Appの利用中は、依頼内容や選んだ対象が外部サービスへの問い合わせに使われます。機密情報、個人情報、未公開の契約条件を含む依頼は、必要性を一段階下げて考えます。
たとえば「売上不振のA社の契約を調べて」ではなく、「顧客IDを使わず、今月期限が近い契約の件数を集計して」のように、目的に必要な最小情報へ変換できる場合があります。技術的な接続が可能であることと、その文脈を送るべきことは別の判断です。
開発者が作るときの最小構成
カスタムAppを作る側は、最初のバージョンを小さく保つほど運用が安定します。おすすめは、読み取り専用のツールを1〜2個に絞る構成です。
ステップ1：利用者の問いを固定する
「社内文書を検索するApp」では広すぎます。代わりに「指定プロジェクトの議事録から、決定事項と未解決項目を返すApp」のように、入力・出力・利用者を固定します。
この段階で、取得対象、検索範囲、返す項目、データ保持の考え方を文章化します。仕様が曖昧なままツールを増やすと、後から権限を絞るのが難しくなります。
ステップ2：ツールを許可リストにする
MCPサーバーは、モデルに任せて任意の内部APIを呼ばせる装置ではありません。公開するツールを明示的な許可リストにし、入力スキーマも狭くします。
たとえばsearch_minutes(project_id, query, limit)なら、project_idは許可済み一覧と照合し、limitには上限を置きます。URLやSQLをそのまま受け取る汎用ツールは、入力の自由度が高いぶん、意図しない参照や処理を招きやすくなります。
ステップ3：認証と権限をサーバー側でも検証する
会話画面での確認だけに依存しないでください。サーバー側でユーザーや組織、対象リソースへの権限を検証します。UIで選択できないはずのIDが入力として届いた場合も拒否できるようにします。
認証トークンをログに残さない、エラー表示へ内部URLや秘密情報を含めない、期限切れトークンを安全に処理する、といった境界の設計が重要です。特にOAuthを使う場合は、更新トークンを発行・保持する仕組みと、接続解除時の扱いを早めに決めましょう。
ステップ4：書き込みは「提案」と「実行」に分ける
いきなりcreate_taskを実行するのではなく、最初は作成予定のタイトル、担当者、期限、本文を返すplan_taskを作ります。利用者が内容を確認してから、別の明示操作でcreate_taskを呼ぶ構成です。
この二段階にすると、モデルの解釈ミス、日付の取り違え、対象プロジェクトの誤選択を実行前に見つけられます。さらに、実行ツールには重複防止用のリクエストIDを持たせ、通信エラー時に同じ作成を二度行わないようにします。
本文図2：まず読み取り専用で価値を確かめ、提案、明示確認、実行、照合の順に範囲を広げる。
失敗しやすい3つのパターン
「MCPだから安全」と考える
MCPは接続規約です。ツールの権限、入力検証、監査、確認フローは別に実装します。特に書き込みツールは、利用者が期待する結果だけでなく、失敗時・再試行時・部分成功時の状態を設計して初めて安全になります。
「Appを増やせば生産性が上がる」と考える
Appが増えるほど、選択肢、権限、接続障害、情報の行き先が増えます。生産性はApp数ではなく、1つの反復作業で削減できた切り替え回数と確認時間で測りましょう。毎週使う検索や要約が1つ確実に速くなる方が、使わない連携を10個増やすより価値があります。
「確認画面があるからサーバー側の検証は不要」と考える
確認画面は人間の取り違えを減らしますが、入力の改ざん、古い状態、権限の誤判定は防げません。対象ID、組織、操作種別、金額・件数上限、再試行の扱いは、必ずサーバー側でも確認します。
小さく始めるための設計例
たとえば、チームが毎週の振り返りで散らばった議事録を読む負担を減らしたいとします。このとき最初から「会議を作成し、担当者へ通知し、タスクを完了まで追うApp」を作る必要はありません。第一段階は、指定期間の議事録から決定事項と保留事項を検索し、出典リンク付きで返すだけで十分です。
この最小版の入力は期間とプロジェクト名、出力は決定事項・未解決事項・根拠の文書URLに限定できます。書き込みがないため、利用者は結果を読み、正確さと役立ち方を評価できます。結果が十分に安定してから、「下書きタスクを提案する」機能を追加します。この時点でも、作成先や担当者を確定するのは人間です。
最後に、どうしても繰り返し発生する作成だけを実行ツールへ移します。実行前に対象、期限、担当者、本文、作成数を表示し、同一依頼の再実行を防ぐIDを付けます。実行後は作成されたレコードのURLとIDを返し、失敗時は「作れたか不明」のまま再送しません。再取得して状態を確認してから、必要なら人間が判断します。
このように、検索、提案、実行を別の段階に分けると、実装もレビューも小さくできます。モデルの能力が上がっても、この分離は不要になりません。むしろ自動でできることが増えるほど、どの段階を自動化したかを後から説明できることが重要になります。
チーム導入で最初に決める4つの運用ルール
個人利用では自分の判断で接続を外せますが、チームでは「誰が何を許可したか」が重要になります。導入前に、次の4点を短い運用ルールとして決めておくと、Appが増えても判断がぶれにくくなります。
1. データの分類。公開情報、社内一般情報、限定共有情報、機密情報を分け、各Appで扱ってよい範囲を決めます。分類できない会話をすべて禁止する必要はありませんが、機密情報を含む依頼はまず既存の安全な経路へ戻す、といった逃げ道を用意します。
2. 所有者。各Appに、技術的な問い合わせ先と業務上の責任者を置きます。MCPサーバーを作った開発者だけが全権限を持つ状態は長続きしません。ツール追加、権限変更、障害時の停止を誰が決めるかを明文化します。
3. 変更管理。Appが新しいツールを追加したり、既存ツールの入力・出力を変えたりすると、以前の安全確認がそのまま使えないことがあります。変更内容を比較し、読み取りから書き込みへ性質が変わるときは再レビューする、という原則を置きます。
4. 例外処理。認証切れ、外部API障害、タイムアウト、部分成功、権限不足が起きたときに、Appが何をするかを決めます。失敗したら何度も自動再試行するのではなく、対象と結果が不明な場合は停止して確認へ返す方が安全です。
Appsを評価する指標
導入の成否を「何人が有効化したか」だけで測ると、使われないAppが増えます。代わりに、1つの具体的な仕事について、開始から確認完了までの時間、手動の画面切り替え回数、検索漏れ、実行後の修正回数を見ます。
たとえば議事録検索Appなら、回答の文章量ではなく「根拠の文書へ一度で戻れた割合」「利用者が検索条件をやり直した割合」「誤ったプロジェクトを参照した件数」を記録します。書き込みAppなら、作成成功率だけでなく、確認で中止された割合、重複作成の有無、実行後に手作業で修正した件数も重要です。中止が多いことは必ずしも失敗ではなく、確認が本来の役割を果たしている場合もあります。
導入前の実運用チェックリスト
- □ Appを使う業務目的を1文で説明できる
- □ 読み取り操作と書き込み操作を分けている
- □ 外部サービスへ渡る情報の範囲を把握している
- □ 公開ツールを許可リストで限定している
- □ 入力値をサーバー側でも検証している
- □ 書き込み前に対象・差分・影響を確認できる
- □ 通信失敗時に同じ作成を二度実行しない
- □ 実行者、対象、時刻、結果をログで追える
- □ 接続解除とトークン失効の手順を決めている
- □ Appやツールの変更を本番へ入れる前に試験できる
まとめ：最初に自動化するのは「操作」ではなく「確認しやすい情報」
ChatGPT Appsは、会話を検索や作成などの実務へつなげる強力な入口です。MCPを使えば外部ツールを共通の方法で公開でき、Apps SDKを使えば会話に合ったUIも作れます。しかし価値が出るのは、たくさん接続したときではなく、利用者が安心して繰り返せる小さな仕事を1つ確実に短縮できたときです。
初回は、読み取り専用の用途を選んでください。次に、返す情報を絞り、権限と送信範囲を確認します。書き込みが必要になった段階で、提案と実行を分け、明示確認、サーバー側検証、重複防止、実行後照合を追加します。この順番なら、便利さを試しながら、取り返しのつかない操作を急がずに済みます。
使い始めた後も、接続したままにせず定期的に見直します。不要になったAppは解除し、利用頻度が低いのに権限が広いAppは縮小できないかを確認します。技術は更新されるため、公開時に安全だった設計が、ツール追加や組織設定の変更後も同じとは限りません。小さな用途、限定した権限、確認可能な結果という原則を維持することが、長く使える自動化への近道です。
MCPサーバーをPythonで作る基本は「PythonでMCPサーバーを作る｜FastMCP入門」、OpenAI APIからMCPを使う実装の考え方は「OpenAI Responses APIでMCP連携｜Python実装・承認フロー」もあわせて読んでください。
コメント