Canvasフレームワークとは？
Canvas（キャンバス）フレームワークとは、既存の外部WebアプリケーションをSalesforceのUI内にシームレスに埋め込むための統合フレームワークです。
外部アプリをiframe内でSalesforce画面に表示しながら、Canvas SDK（JavaScript） を通じてSalesforceのデータや認証情報と双方向通信が可能になります。
仕組み：署名付きリクエスト（Signed Request）
Canvasの認証は「署名付きリクエスト」方式が代表的です。
① ユーザーがSalesforceにログイン
↓
② SalesforceがユーザーセッションをHMAC-SHA256で署名
↓
③ 署名済みPOSTリクエストを外部アプリに送信
↓
④ 外部アプリが署名を検証 → 再認証なしでアクセス可能
公式引用
"Canvas enables you to easily integrate a third-party application within Salesforce. Instead of requiring users to navigate to a separate web application, you can display the application within the Salesforce environment."
Canvasフレームワークのメリット
| メリット | 内容 |
|---|---|
| 既存アプリの再利用 | 外部Webアプリを作り直すことなくSalesforce内に組み込める |
| SSO（シングルサインオン） | 署名付きリクエストでSalesforceログインと認証を統合できる |
| ユーザー体験の統一 | Salesforceの画面を離れずに外部アプリを操作できる |
| Canvas SDKによる双方向通信 | Salesforceのレコード情報取得・更新が外部アプリから可能 |
| 最小限の改修 | 外部アプリにCanvas SDKを追加するだけで連携が成立する |
外部アプリとの統合実務では、LWCやAPI連携がCanvasより採用される理由
これが本記事の核心です。Canvasフレームワークは機能的には有効ですが、実務プロジェクトではほとんど採用されません。その理由を技術・運用・組織の観点から整理します。
理由① Lightning ExperienceにおけるiframeのCSP制限
SalesforceのLightning ExperienceはデフォルトでCSP（コンテンツセキュリティポリシー）が厳格に適用されており、iframe埋め込みに対して制約があります。
"Salesforce uses a stringent Content Security Policy (CSP) to prevent cross-site scripting (XSS) attacks. Some Canvas apps may not render correctly in Lightning Experience if the third-party app doesn't meet CSP requirements."
引用元：Salesforce Help - Considerations for Canvas Apps in Lightning Experience
特にサードパーティのスクリプトや外部リソースを多用するアプリでは、CSPエラーが頻発し、対応コストが増大します。
理由② モバイルSalesforce・Salesforce1との互換性問題
CanvasアプリはモバイルのSalesforceアプリでの表示に制限があります。
LWCはモバイル対応が標準で組み込まれており、レスポンシブデザインにも対応しています。
理由③ デバッグ・保守のコスト増大
iframeを介した通信はブラウザの開発者ツールでのデバッグが困難です。
特に以下のケースで保守コストが大幅に上昇します。
- 外部アプリ側のライブラリ更新時にCanvas SDKとの互換性が崩れる
- クロスオリジン通信のエラーが発生した際のトレースが困難
- Salesforce側のリリースで挙動が変わった場合の影響範囲が広い
理由④ LWCが「Salesforceの現代標準」として確立されている
Salesforceは2019年以降、LWC（Lightning Web Components）を公式の推奨開発標準として強力に推進しています。
| 観点 | Canvas | LWC |
|---|---|---|
| Salesforceロードマップ | 現状維持（積極投資なし） | 継続的に機能強化中 |
| パフォーマンス | iframeオーバーヘッドあり | ネイティブ描画で高速 |
| UI一貫性 | 外部アプリのUIをそのまま表示 | Salesforce Lightning Designに準拠 |
| テスト容易性 | 困難 | Jest等での単体テストが容易 |
| 開発者採用コスト | Canvas SDK習得が必要 | 広くドキュメント・コミュニティが充実 |
理由⑤ REST API / GraphQL APIで「データ連携」は完結する
外部アプリとのデータ連携が目的であれば、Canvasを使わずとも以下の方法で対応できます。
外部アプリ ←→ Salesforce REST API（CRUD操作）
外部アプリ ←→ Salesforce GraphQL API（柔軟なクエリ）
外部アプリ ←→ Platform Events（リアルタイム連携）
SalesforceのデータをGUIに表示したい → LWCで標準コンポーネントを活用
外部アプリにSalesforceデータを渡したい → REST APIで連携
Canvasはこの両方を「iframeと署名」で解決しようとしますが、
実務では目的に応じた専用技術を組み合わせる方が保守性・拡張性ともに優れています。
Canvasフレームワークを実装した方が良い判断軸
「それでもCanvasを使うべき場面はあるのか？」という問いへの答えをフローチャートで整理します。
判断まとめ
| 条件 | 推奨アプローチ |
|---|---|
| 新規開発・大幅改修が可能 | LWC + REST API |
| 既存アプリ再利用 + SSO要件 + デスクトップのみ | Canvas（署名付きリクエスト） |
| 既存アプリ再利用 + モバイル対応必要 | LWC + API連携 |
| JavaScript追加不可 | 認証プロバイダー + OAuth |
まとめ
Canvasフレームワークは「既存の外部WebアプリをSalesforceに最小改修で組み込む」という特定の要件においては有効な手段です。
しかし実務で採用されにくい理由は明確です。
- CSP・Lightning制約によるiframeの表示問題
- モバイル非対応による適用範囲の限定
- 保守・デバッグコストの高さ
- LWCがSalesforceの現代標準として確立されている
- REST APIで多くのユースケースが代替可能
実際の統合プロジェクトでは、目的ごとに最適な技術を選択することが重要です。
「Canvasが使えるか」ではなく「Canvasである必要があるか」という問いを起点に判断することで、保守性・拡張性の高いアーキテクチャを選択できます。