Connected Appsとは何か:定義と2026年に起きた転換点
Connected Appsは、Salesforce外部のアプリケーションとSalesforce組織を安全につなぐための連携フレームワークです。外部システムがSalesforceのデータやAPIにアクセスする際、どのアプリからのアクセスなのかを識別し、どこまでの権限を認めるかを定義する役割を担ってきました。モバイルアプリ、業務システム、iPaaS、AppExchangeのソリューションなど、Salesforceと外部をつなぐ接点の多くはこの仕組みの上に成り立っています。Salesforce Help – External Client Appsも、Connected AppsとExternal Client Appsをいずれもデータ連携のためのフレームワークとして位置づけています。
2026年の転換点:Spring ’26以降は新規作成がデフォルトで無効化される
この前提が2026年に大きく変わりました。Salesforce公式ヘルプによると、Spring ’26以降、新しいConnected Appsの作成はデフォルトで無効化されます。当面はSalesforceサポートに依頼することで例外的に作成を有効化できますが、Salesforceはこの例外措置についても将来のリリースで廃止する方針を明示しており、Connected Appsは実質的にEnd of Supportへ向かっています。長年にわたり標準的な出発点だった作業が、通常の運用フローでは選択できなくなるため、新規案件の設計方針を見直す必要があります。
既存アプリはどこまで影響を受けるのか
一方で、すでに運用中の環境がただちに止まるわけではありません。公式ヘルプは、既存のConnected Appsは引き続き動作し、以下の操作はこの変更の影響を受けないと明示しています。
- 既存のConnected Appsの編集
- パッケージによるインストール
- OAuthによるインストール
- 削除
つまり、影響が及ぶのは新規作成という一点に絞られており、稼働中の連携が突然停止する種類の変更ではありません。
管理者がまず理解すべき影響範囲
2026年時点で管理者が最初に押さえるべきなのは、次の3つの線引きです。第一に、これから増える連携は通常のフローでは作れず、原則としてExternal Client Apps(以下ECA)を選ぶことになること。第二に、既存資産は当面そのまま動くため、慌てて一斉停止する必要はないこと。第三に、Salesforceが次世代として位置づけるECAが受け皿になること。加えて公式ヘルプは、サードパーティ製AppExchangeベンダーに対してECA移行のロードマップを問い合わせるよう管理者に推奨しています。自社で作った連携だけでなく、導入済み製品側の対応方針も確認対象に含まれる点は、初期段階で認識しておきたいところです。
既存Connected Appsを棚卸しする:OAuth Usageで実態を可視化する手順
移行を検討する前にまず必要なのが、いま自社の組織で何が動いているかを正確に把握することです。棚卸しをせずに進めると、業務が止まる連携を見落とすリスクがあります。ここでは可視化から台帳化までの実務手順を整理します。
OAuth Usageページで稼働状況を確認する
起点はSetupのOAuth Usageページです。公式ヘルプによると、External Client AppsもSetupのExternal Client AppsまたはOAuth Usageページから確認でき、従来と同様に管理者がアクティブなセッションやセキュリティログを監視できます。つまりOAuth Usageは、既存の連携と新しい枠組みの両方を一覧できる共通の窓口になります。
- アクティブなセッション数を見て、実際に使われているアプリと使われていないアプリを切り分ける
- セキュリティログで直近のアクセス日時や利用ユーザーの偏りを確認する
- 特定の管理者アカウントに紐づく連携がないかを見る
3つの区分で整理する
洗い出したアプリは、対応主体が誰かという軸で分類すると次の打ち手が決まります。
- 社内開発アプリ:自社エンジニアが作成したもの。仕様書やリポジトリの所在、担当部署を特定する
- AppExchange製・ベンダー提供アプリ:提供元の対応方針に依存するため、契約状況と窓口を確認する
- 用途不明・放置アプリ:作成者が退職済み、検証用のまま残っているなど。セッションの有無で実害を判断する
- 取引先・パートナー由来のアプリ:自社外の組織が利用しているもので、連絡経路の確保が先決になる
ベンダーへの照会と台帳化
ベンダー提供のものについては、公式ヘルプもサードパーティ製AppExchangeベンダーにExternal Client Apps移行のロードマップを問い合わせるよう管理者へ推奨しています。問い合わせでは、対応予定時期、既存アプリのまま提供が継続されるか、利用者側で必要な作業があるかの3点を明確に聞くと回答が揃います。
最後に結果を台帳へ残します。記録項目はアプリ名、区分、社内の管理責任者、提供元と問い合わせ状況、直近アクセス日、利用部門と業務用途、停止した場合の影響範囲、確認日です。棚卸しは一度で終わらず定期的に更新する前提で、情報の粒度を揃えておくと、以降の判断が速くなります。
External Client Appsとの違い:メタデータ準拠と認証方式の見直し
External Client Apps(以下ECA)は、Salesforce公式ヘルプで次世代のConnected Appsと位置づけられています。単なる名称変更ではなく、アプリ定義の管理方法と認証の前提そのものが見直されている点が本質です。
3つの構造改善
- 完全なメタデータ準拠:アプリの定義がメタデータとして扱われるため、環境間での取り回しやバージョン管理を前提とした開発フローに乗せやすくなります。設定画面での手作業に依存しがちだった構成が、成果物として扱える形に近づきます。
- ユーザーロールの分離:アプリを利用する側と管理する側の役割を分けて保持する構造になっており、権限の見通しが立てやすくなります。誰がどの範囲まで触れるのかを設計時点で切り分けられる点が違いです。
- 第2世代マネージドパッケージ対応:パッケージとして配布する連携を、現行のパッケージング方式に沿って構築できます。ISVやパートナー経由の配布を前提とした連携では、この対応の有無が移行判断に直結します。
資格情報を埋め込む認証方式は使えない
認証面での最大の差分は、OAuthのusername-passwordフローのように資格情報を埋め込む従来型のパターンがサポートされないことです。Salesforce公式ブログは、これをOWASP A07(識別と認証の失敗)への対策と説明しています。静的な資格情報と暗黙の信頼に依存する方式は、安全なローテーションが難しく、統合ごとの分離もできないためです。Salesforce公式ブログ – Architecting Inbound Governance with External Client Apps
ECAで使える代替認証フロー
username-passwordフローに依存していた既存連携をECAへ移行する際は、以下の代替フローに切り替えることになります。
- JWT Bearer Flow:秘密鍵で署名したJSON Web Tokenを送信して認証する方式。特定ユーザーの権限で動作するサーバー間連携に適しており、パスワードを持ち回らずに実現できます。
- Client Credentials Flow:ユーザーを介さずアプリケーション自身の資格情報でトークンを取得する方式。定期バッチや管理系のヘッドレス連携に向いています。login.salesforce.comやtest.salesforce.comは使えず、組織のMy DomainのURL経由でリクエストする点に注意が必要です。
- Web Server Flow(PKCE付き):ユーザーの明示的な認可を伴うインタラクティブな用途向け。カスタムWeb・モバイルアプリで使用します。
どの連携から移すべきか
判断軸はシンプルで、静的な資格情報に依存している連携を最優先にします。IDとパスワードをスクリプトや設定ファイルに保持している定期バッチ、退職者や共有アカウントのまま動いている連携などが該当します。これらはECAでは同じ作り方を再現できないため、移行時に認証フロー自体の設計変更が必要になり、着手から完了までの所要が最も読みにくい領域だからです。次点は、パッケージとして配布・受領している連携です。逆に、標準的なOAuthフローで動作し利用範囲も限定的な連携は、相対的に後回しでも影響が小さいと整理できます。
2026年の移行チェックリストと運用体制の作り方
棚卸しと技術差分の理解が済んだら、次は実行計画に落とし込む段階です。ここでは移行を完了させ、同じ問題を繰り返さない運用サイクルまでを整理します。
移行優先度を決める判断チェックリスト
すべてを同時に動かすことはできません。以下の観点でスコアをつけ、上位から着手します。
- 認証方式のリスク:資格情報を埋め込む方式に依存しているか
- 業務影響度:止まると受注や請求など基幹業務が停止するか
- 利用頻度:アクティブなセッションが日常的に発生しているか
- 依存関係:他システムやバッチ処理が連鎖的に影響を受けるか
- 移行主体:自社で改修できるか、ベンダー側の対応待ちか
- 代替容易性:廃止や別手段への置き換えで済むか
リスクが高く自社で改修できるものを先行させ、ベンダー対応待ちのものは回答期限を設定して進捗を追跡します。
検証から本番切替までの確認項目
本番適用前に、Sandboxなどの検証環境で以下を必ず通します。
- 認証フローが想定どおり完了し、トークン取得と更新が機能するか
- API呼び出しの権限範囲が過不足なく設定されているか
- エラー時のリトライやタイムアウト挙動が変わっていないか
- 切替後の旧アプリの停止手順と、問題発生時の切り戻し手順
- 切替直後の一定期間、認証失敗ログが増えていないか
切替は業務閑散時間帯に行い、直後の監視担当をあらかじめ決めておくと復旧が速くなります。
モニタリングと社内ガバナンスの定例化
移行後の再発防止には、定期確認をルール化することが有効です。SetupのOAuth Usageページ、あるいはExternal Client Appsから、アクティブなセッションとセキュリティログを月次で点検する担当と手順を決めます。
あわせて、新規連携の申請フローも整えます。申請時に、用途と接続先、必要な権限範囲、認証方式、責任者、想定利用期間を記載させ、承認者が権限の最小化を確認する流れにします。期限を過ぎた連携は自動的に棚卸し対象へ回す仕組みにしておけば、用途不明のまま残る連携は生まれにくくなります。
新規作成の無効化は制約ではなく、連携の統制を見直す機会です。優先度づけ、検証、切替、監視という循環を定着させることが、2026年以降の安定運用につながります。
