こんにちは、大平です。
受託開発や技術顧問の現場で、仕様検討のたびに繰り返し出会う要件があります。 「他社のサービスをiframeで埋め込んで、そこに入力された内容をこちらで受け取れますよね？」というものです。 結論から言うと、iframeにできるのは他社のページを「表示する」ことまでで、その中身を読むことも操作することもブラウザが遮断します。 しかもこれは実装力や予算の問題ではなく、ブラウザというプラットフォームの根幹ルールです。 この記事では、その境界線がどこにあるのか、そして境界線に当たった要件をどう仕様に落とし直すのかを、PdMや事業責任者の方に向けて整理します。
仕様検討でよく出る、できそうでできない要件
僕が実際に相談を受けることが多いのは、次の3つのパターンです。
- 他社サービスの画面を自社システムに埋め込み、そこに入力された値を自社のデータベースにも保存したい
- 埋め込んだ他社の画面を、利用者の代わりに自動で操作したい（予約サイトを埋め込んでボタン1つで予約を完了させる、など）
- 利用者が他社サービスにログイン済みであることを前提に、その状態を使って情報を表示したい
どれも一見、筋の通った要件に見えます。 実際、iframeを使えば他社のページを自社の画面の中に表示することまでは本当にできてしまうからです。 デモの段階では埋め込みが動いて見えるため、「あとは中身を読むだけ」「あとは操作するだけ」と地続きの追加開発に感じられます。 しかしこの3つは、どれも同じ壁に当たって実現できません。
3つの要件に共通する壁
ブラウザには同一オリジンポリシーという大原則があります。 オリジンとは「どのサイトから配信された画面か」を区別する単位で、同一オリジンポリシーは「別のオリジンから来た画面の中身は、読むことも操作することも許さない」というルールです。
自社ページと埋め込んだ他社ページは、同じウィンドウに並んで見えていても、ブラウザの中では別々の区画に隔離されています。 同じビルにテナントとして入っていても、隣の店舗の中に立ち入ったりレジを開けたりはできないのと同じです。
なぜブラウザはそこまで厳しく守るのか。 もし埋め込んだページの中身を読めるなら、悪意あるサイトが銀行のページを透明にして埋め込み、利用者が入力したパスワードや残高を盗めてしまうからです。 この壁は、自社サービスの利用者を攻撃者から守っている壁と同一のものです。 だからこそ設定や実装の工夫で外すことはできませんし、外せてしまったらそれはブラウザの脆弱性として扱われます。
さらに言えば、多くのサービスは他サイトへの「表示」自体も拒否しています。 ログインページや管理画面をiframeに入れようとすると空白になるのは、埋め込みを拒否する設定（クリックジャッキング対策）が入っているためです。
iframeでできることとできないこと
境界線を表に整理します。
| やりたいこと | 可否 | 理由と補足 |
|---|---|---|
| 他社ページを自社画面内に表示する | ○ | 相手が埋め込みを許可している場合に限る |
| 決済フォームや地図など、埋め込み用に提供された部品を組み込む | ○ | Stripe、Googleマップ、YouTubeなどが典型 |
| 埋め込んだ部品と自社画面の間でデータをやり取りする | △ | 相手が連携用の窓口（postMessage）を用意している場合だけ可能 |
| 自社の別画面（同一オリジン）を埋め込んで読み書きする | ○ | 同一オリジンなら制限はない |
| 埋め込んだ他社ページの表示内容や入力値を読む | × | 同一オリジンポリシーが遮断する |
| 埋め込んだ他社ページを利用者の代わりに操作する | × | 同上 |
| 他社サービスのログイン状態を流用する | × | 同上。第三者Cookieへの規制強化で年々さらに厳しくなっている |
判断の目安はシンプルです。 「相手のオリジンをまたいで読む、書く、操作する」が要件に含まれていたら実現できないと考えてください。 「表示する」だけの要件であれば、相手が埋め込みを許可している限り成立します。
代替案を検討する順序
エンジニアから「それはできません」と返ってきたとき、要件そのものを捨てる必要はありません。 僕が実際の案件で検討する順序は次のとおりです。
- 公式APIや公式の埋め込み部品を探す：決済、地図、予約、カレンダーといった主要な領域では、事業者側が正式な連携手段を用意していることが多いです。iframeで無理に実現したかったことの大半は、公式APIで正攻法として実現できます。
- 相手企業に連携窓口の開設を打診する：パートナー契約を結び、API開放や埋め込み部品の提供をしてもらう形です。技術ではなくビジネスで壁を越える選択肢で、相手にも送客のメリットがあれば十分成立します。
- ブラウザの外での自動化を検討する：サーバー側での連携やRPAがこれに当たります。ただし相手の利用規約に抵触する可能性、利用者のログイン情報を預かる責任、相手の画面変更のたびに壊れる保守コストが伴うため、技術判断ではなく事業リスクの判断になります。
- 要件の目的に立ち返る：「他社画面の入力値が欲しい」の裏にある目的が「利用者の二度手間をなくしたい」なら、相手サイトへ遷移させて完了後に戻す設計や、OAuthによるアカウント連携で足りることが多いです。
運用としては、他社サービスの画面や状態に「触る」要件が出た時点で、見積もりの前にエンジニアへ実現可能性を確認するのが確実です。 境界線に触れる要件は、この段階で潰しておけば手戻りになりません。
まとめ
- iframeにできるのは表示まで：他社ページを見せることはできるが、中身を読むことも操作することもブラウザが遮断する
- 境界線は実装力の問題ではない：同一オリジンポリシーは利用者を守るためのブラウザの根幹ルールで、予算や工夫では越えられない
- 代替案には検討の順序がある：公式API、パートナー連携、ブラウザ外の自動化、要件の見直しの順で仕様に落とし直す
他社サービスに「触る」要件が出たら、見積もりの前にこの境界線と照らし合わせてみてください。 それだけで、実装段階での「できません」の大半は防げます。