Google Cast SDKは、スマートフォンやブラウザのアプリから、テレビ側のキャスト対応デバイスへ再生を引き継ぐための開発キットです。実装で最初につまずくのはコードよりも、「送信側・受信側・アプリID」という3要素の関係と、アプリIDを発行するCast SDK Developer Consoleの登録手順のほうです。なお「Google Cast API」「Chromecast API」と呼ばれているものは、このSDKが各プラットフォームで公開しているAPI群を指し、単体で存在する別のAPIではありません。
まとめ
Google Castの実装は、再生を指示する送信側アプリと、テレビ側で実際にコンテンツを取得して再生する受信側アプリに分かれます。両者はアプリIDで紐付き、そのアプリIDはCast SDK Developer Consoleで発行します。開発者登録料は5ドルで、返金されません。
2026年8月時点の版は、Android送信側がplay-services-cast-framework 22.3.1（2026年4月7日）、iOS送信側が4.8.6（2026年7月27日）、Web Receiverが3.0.0155（2026年8月9日時点でロールアウト中・完了予定は8月25日）です。iOS 4.8.6はCocoaPodsで配布される最後の版で、以降はSwift Package Managerと直接ダウンロードに移ります。まず動かして確認したいだけなら、登録不要のDefault Media Receiverを送信側から指定するのが最短です。以下、要素の役割と各プラットフォームの手順を順に見ていきます。
Google Cast SDKの構成｜送信側・受信側・アプリIDの3要素
送信側アプリと受信側アプリの役割分担
送信側アプリの役割は、キャストセッションのコントローラーです。Android・iOS・Web（Chrome）に送信側SDKがあり、キャストボタンの表示、デバイス選択、再生・一時停止・シークの指示を担当します。一方の受信側アプリはキャスト対応デバイス上で動き、送信側からのコマンドに応答して映像や音声を再生する担当です。
Web受信側は3種類あります。カスタマイズ不可で登録も不要なDefault Media Receiver、ロゴや配色だけを差し替えるStyled Media Receiver、HTMLとJavaScriptを自由に書けるCustom Receiverです。これとは別枠で、Android TV上でネイティブに動くAndroid TV Receiverがあり、Cast Connectで送信側アプリと連携します。
アプリIDは送信側と受信側を結ぶ鍵です。公式ドキュメントは「Receivers (except for the Default Receiver) are registered using a distinct app ID, which is used to ‘key’ the corresponding Sender apps to that Receiver」と説明しており、同じアプリIDを持たない送信側は、その受信側に接続できません。
キャストの仕組み｜mDNSでの検出と受信側による直接取得
キャストが画面ミラーリングだと誤解されがちですが、動作はまったく違います。送信側は映像データを中継しません。送信側が渡すのはコンテンツのURLと再生指示であり、受信側デバイスが自分でストリーミング配信元へ取りに行きます。だからスマートフォンの画面を消しても再生が続き、通信帯域もスマートフォンを経由しません。
デバイスの発見はローカルネットワーク上のマルチキャストで行われます。同一ネットワークにいるはずのChromecastが一覧に出ないとき、原因はアプリ側とは限りません。VLAN分割や無線LANコントローラーのマルチキャスト抑制でパケットが届かないことがあります。前提となるプロトコルの挙動はmDNSとは｜マルチキャストDNSの仕組みとDNSとの違い・Bonjour・Avahiで整理しました。
受信側が直接コンテンツを取得する以上、配信基盤側の設計もキャスト対応の一部です。CORSヘッダーの許可、TLS対応、キャッシュ制御はいずれも受信側デバイスからのリクエストを前提に確認してください。配信の組み立て方は動画配信システムの構築｜トランスコードからHLS配信・視聴制御・DRMまで実装解説にまとめています。
Cast SDK Developer Consoleでのアプリ登録｜5ドルの登録料とデバイス登録
アプリケーション登録とアプリIDの発行
Custom ReceiverとStyled Media Receiverは、Cast SDK Developer Console（cast.google.com/publish）での登録が必須です。開発者登録には5ドルの費用がかかり、公式ドキュメントはこれを明確に非返金と記載しています。個人アカウントで登録すると後の引き継ぎが面倒になるため、組織で運用するなら最初からチーム用のメールアドレスで作成してください。
登録の流れは、コンソールにサインインして「Add New Application」を押し、Custom ReceiverかStyled Media Receiverを選び、アプリ名と受信側アプリのURL（Styledの場合はスキンURL）を入力して保存する、というものです。このとき「Supports relay casting」と「Supports casting to audio-only devices」の2つのチェックボックスも判断します。保存した時点でアプリIDが発行され、送信側のコードにはこのIDを入れます。公開するにはさらに送信側アプリの情報、カテゴリ、説明文、画像素材の登録が必要です。
テスト用Castデバイスの登録と15分の待機
公開前の受信側アプリは、登録済みのデバイスでしかテストできません。テストしたいCastデバイスを開発環境と同じWi-Fiにつなぎ、シリアル番号を確認して「Add New Device」から登録します。
ここで手が止まりやすいのが待ち時間です。公式ドキュメントは登録後に「Wait fifteen minutes before continuing」と指示しており、ステータスが「Ready for Testing」になってからデバイスを再起動する必要があります。登録直後にアプリIDを指定しても受信側が起動しないのは正常な挙動で、コードを疑う前に15分と再起動を済ませてください。
Androidアプリへの送信側SDK組み込み手順
Gradle依存とOptionsProviderの登録
Android送信側SDKはGoogle Play services SDKの一部として配布されます。2026年8月時点の最新は22.3.1で、2026年4月7日にRobolectricのテスト検証エラー修正としてリリースされました。直前の22.3.0（2026年2月11日）でAndroid 13以降のシステム出力スイッチャーに対応し、22.2.0（2025年10月20日）でAndroid 14以降向けのIntelligent Device Suggestions APIが入っています。
dependencies {
implementation("com.google.android.gms:play-services-cast-framework:22.3.1")
implementation("androidx.appcompat:appcompat:1.3.1")
implementation("androidx.mediarouter:mediarouter:1.2.5")
}次に、キャスト設定を返すOptionsProviderを実装します。setReceiverApplicationIdには、前章で発行したアプリIDを渡します。
class CastOptionsProvider : OptionsProvider {
override fun getCastOptions(context: Context): CastOptions {
return CastOptions.Builder()
.setReceiverApplicationId(context.getString(R.string.app_id))
.build()
}
override fun getAdditionalSessionProviders(context: Context): List<SessionProvider>? {
return null
}
}実装したクラスは、マニフェストのメタデータでSDKに知らせます。既存のapplication要素の中へ追記するかたちで、要素ごと置き換えないでください。この記述を忘れるとキャストボタンを置いてもセッションが開始しません。
<application>
...
<meta-data
android:name="com.google.android.gms.cast.framework.OPTIONS_PROVIDER_CLASS_NAME"
android:value="com.example.CastOptionsProvider" />
</application>Castボタンの設置とメディアルーター連携
キャストボタンはAndroidX MediaRouterのMediaRouteActionProviderとしてメニューに置き、CastButtonFactoryでSDKに接続します。ボタンの表示・非表示や接続状態の反映はフレームワークが管理するため、アプリ側でデバイス一覧を実装する必要はありません。
override fun onCreateOptionsMenu(menu: Menu): Boolean {
super.onCreateOptionsMenu(menu)
menuInflater.inflate(R.menu.main, menu)
CastButtonFactory.setUpMediaRouteButton(applicationContext, menu, R.id.media_route_menu_item)
return true
}実行時のチェックも1つ入れてください。GoogleApiAvailability.getInstance().isGooglePlayServicesAvailable(context)でGoogle Play servicesの可用性を確認します。要件を満たすAPKが入っていない端末では、キャストボタン自体が表示されません。言語選択を含めたAndroid側の開発環境はAndroidアプリ開発の言語はKotlinとJavaのどちらか？選定基準と環境まで解説にまとめました。
Web Receiverアプリの最小構成とホスティング要件
Custom Web Receiverは、CAF（Cast Application Framework）の受信側フレームワークを読み込んでCastReceiverContextを開始するだけで動きます。公式ドキュメントが示す最小構成は次のとおりです。
<html>
<head>
<script type="text/javascript"
src="//www.gstatic.com/cast/sdk/libs/caf_receiver/v3/cast_receiver_framework.js">
</script>
</head>
<body>
<cast-media-player></cast-media-player>
<script>
cast.framework.CastReceiverContext.getInstance().start();
</script>
</body>
</html>cast-media-player要素が標準のプレーヤーUIを提供するため、この13行でメディア再生が成立します。スクリプトURLにプロトコルを書かないのは、受信側アプリを配信するサーバーと同じプロトコルで取得させるためです。ただし公開時はTLSが必須なので、本番では実質httpsに固定されます。
もう1つの制約が自己ホストの禁止です。公式は「Do not self-host the cast_receiver_framework.js resource (Web Receiver SDK), not even for local development.」と明記しており、ローカル開発でも例外は認められていません。
受信側デバイスは配信元からコンテンツを直接取得するため、キャッシュ層とCORSヘッダーの設計もここに含まれます。キャッシュ制御の考え方はCDNとは？仕組み・キャッシュ制御からサービスの選び方まで実装目線で解説が参考になります。なお受信側フレームワークの本体は2026年8月時点で約350KBです。
WebブラウザとiOSの送信側｜2026年時点の版と制約
Chrome向けWeb Senderの読み込みと初期化
ブラウザからの送信側は、クエリ付きでローダースクリプトを読み込み、フレームワークの準備完了コールバックで初期化します。
<script src="//www.gstatic.com/cv/js/sender/v1/cast_sender.js?loadCastFramework=1"></script>
<script>
window['__onGCastApiAvailable'] = function(isAvailable) {
if (isAvailable) {
initializeCastApi();
}
};
function initializeCastApi() {
cast.framework.CastContext.getInstance().setOptions({
receiverApplicationId: chrome.cast.media.DEFAULT_MEDIA_RECEIVER_APP_ID
});
}
</script>
<google-cast-launcher></google-cast-launcher>DEFAULT_MEDIA_RECEIVER_APP_IDを指定した場合は登録不要のDefault Media Receiverが起動するため、アプリIDを取る前に動作確認ができます。自作の受信側に切り替えるときは、この値を発行済みアプリIDに置き換え、自動参加の範囲をautoJoinPolicyで指定します。
対応環境はMac、Windows、Linux、ChromeOS、Androidのキャスト対応ブラウザです。公式は「Casting is not supported on the iOS Chrome browser.」と明記しており、iPhoneやiPadのChromeからは送信できません。iOSを対象に含めるならネイティブアプリ側でiOS送信側SDKを使う判断になります。またブラウザがinsecure originでPresentation APIのサポートを終了しているため、送信側ページはHTTPS配信が前提です。
iOS Sender 4.8.6でのCocoaPods配布終了
iOS送信側SDKは2026年7月27日の4.8.6が最新で、対応TVをスリープから起動させるWake-on-LANが有効になりました。同時に最低対応バージョンがiOS 16へ引き上げられています。
実装計画に影響するのは配布経路の変更です。リリースノートは「Note this will be the last update published to CocoaPods. Subsequent updates will be available using Swift package manager, and will continue to be available from direct download.」と告知しており、4.8.6がCocoaPodsに公開される最後の版になります。CocoaPodsで依存を管理しているiOSアプリは、次回のSDK更新までにSwift Package Managerへの移行、または直接ダウンロードによる取り込みを済ませる必要があります。
Node.jsのchromecast-apiを採用すべきでない場面
「Node.jsからChromecastへ動画を投げたい」という要件ではchromecast-apiがよく引き合いに出されますが、業務システムの実装に選ぶべきではありません。npmレジストリ上の最新は0.4.2で、公開日は2023年7月5日です。さらに中核の依存であるcastv2-clientの最新1.2.0は2016年12月30日公開で、10年近く更新が止まっています。
これらはCast SDKではなく、CASTV2プロトコルを外から実装したサードパーティ製クライアントで、Googleが公式に保守する送信側SDKには含まれません。受信側の仕様変更やセキュリティ更新に追随する保証がなく、認証や証明書まわりの変更が入ったときに動かなくなっても修正を待てません。
それでも使う余地があるのは、社内のスクリプトや検証用の使い捨てツールなど、壊れた時点で捨てられる用途に限られます。長期運用するサービスであれば、Web Senderをブラウザで動かすか、モバイルアプリ側に送信側SDKを入れる構成にしてください。なお、ブラウザ間の直接的な映像伝送を目的にしているなら、そもそもキャストではなくWebRTCとは？P2Pの仕組み・ICE/STUN/TURNからSFU選定・実装・運用判断まで実装者向けに解説で扱う技術のほうが要件に合います。
Chromecast生産終了後もCast対応を作る価値
Googleは2024年8月6日の公式ブログで「After 11 years and over 100 million devices sold, we’re ending production of Chromecast, which will now only be available while supplies last.」と発表し、後継としてGoogle TV Streamerを示しました。ハードウェアとしてのChromecastは生産を終えています。
ただしキャストの受け皿が消えたわけではありません。同じ発表でGoogleは既存Chromecastのサポート方針に変更はないとしていますが、ここには限定が付きます。原文は「continued software and security updates to the latest devices」で、ソフトウェアとセキュリティの更新が続くと明言されているのは最新デバイスです。初代や第2世代まで無期限に更新されると読むべきではありません。
受信側の母数そのものは増えています。Google Castの技術はテレビ本体へ「Chromecast built-in」として組み込まれており、Android Developers Blogは2026年5月19日に、Google TVとAndroid TVを合わせた月間アクティブデバイスが3億台を超えたと公表しました。Nestスマートスピーカーとの統合もそのままです。
判断はこうなります。専用ドングルを前提にした導線（「Chromecastを購入してください」といった案内）は書き換えが必要ですが、Cast対応そのものを外す理由にはなりません。重心がテレビ内蔵側へ移った以上、テスト機材をドングルからChromecast built-in搭載テレビやGoogle TV Streamerへ入れ替えるのが妥当です。
Cast APIリファレンスの所在と版の確認先
プラットフォーム別のCast APIリファレンス
「Cast API」「Chromecast API」という名前の単一のAPIは存在しません。実体はプラットフォームごとに分かれたリファレンスで、Androidはcom.google.android.gms.cast.frameworkパッケージ、iOSはGCKプレフィックスのクラス群、ブラウザ側はWeb Sender API、受信側はWeb Receiver APIです。探しものがどれに当たるかを先に決めないと、リファレンスの目次で迷います。
ブラウザ側だけは名前空間が2階層に分かれている点に注意してください。cast.frameworkがCAFの高水準API、chrome.castが低水準のBase APIで、DEFAULT_MEDIA_RECEIVER_APP_IDやAutoJoinPolicyのような定数は後者側にあります。前掲のWeb Senderのコードに2つの名前空間が同居しているのはこのためです。
版の一覧と更新の追い方
Cast関連のコンポーネントは配布元も更新頻度もばらばらです。2026年8月9日時点の状況は次のとおりです。
| コンポーネント | 最新版 | 日付 | 配布元 |
|---|---|---|---|
| Android Sender | 22.3.1 | 2026-04-07 | Google Maven |
| iOS Sender | 4.8.6 | 2026-07-27 | CocoaPods（最終）／SPM |
| Web Receiver (CAF) | 3.0.0155 | 2026-08-04〜08-25 展開中 | gstatic |
| Web Sender | 更新告知なし | 2019-08-27 | gstatic |
| Android TV Receiver | 21.1.1 | 2024-10-28 | Google Maven |
優先して見るべきはWeb Receiverです。版を自分で固定できず、Googleのロールアウトで挙動が変わります。3.0.0155はプレビューが2026年7月16日、ロールアウト開始予定が2026年8月4日、完了予定が2026年8月25日という日程で、既定のShaka Playerが4.9.2から4.15.55へ、useShakaForHlsの既定値がtrueへ変わります。HLS再生の経路が入れ替わる変更なので、HLSを配信しているサービスはロールアウト期間中に実機確認を入れてください。リリースノートの日程は運用カレンダーに載せて追う運用が現実的です。
Web Senderのリリースノートが2019年8月27日で止まっている点は、コードが凍結しているという意味ではありません。Web Sender SDKもgstaticから読み込む方式で、アプリ側の更新なしに配信物が入れ替わります。止まっているのは告知を伴う仕様変更のほうです。一方でAndroid TV Receiver（play-services-cast-tv）は21.1.1が2024年10月28日。送信側の22.3.1とは版系列も更新ペースも別物で、同じ番号体系だと思って揃えようとすると解決できない依存エラーになります。
よくある質問
Google Castとは何ですか？
スマートフォンやパソコンのアプリから、テレビなどのキャスト対応デバイスへ再生を引き継ぐ仕組みです。送信側が渡すのは再生指示とコンテンツのURLだけで、映像そのものは受信側デバイスが配信元から直接取得します。開発者向けの実装手段がGoogle Cast SDKです。
リレーキャストと音声のみデバイス対応は何を指しますか？
どちらもアプリ登録時のチェックボックスです。リレーキャストを有効にすると、受信側と同じWi-Fiにつながっていない送信側からのキャストを受け付けます。音声のみデバイス対応を有効にすると、Google Cast for audio対応のスピーカーが発見対象に入ります。どちらもあとから変更できます。
アプリIDを登録せずにキャストを試せますか？
できます。Default Media Receiverは登録が不要で、送信側でDEFAULT_MEDIA_RECEIVER_APP_ID定数を指定するだけで利用できます。UIのカスタマイズはできませんが、送信側の実装と再生の疎通確認はこれで足ります。作り込みが必要になった段階でCustom ReceiverかStyled Media Receiverを登録してください。
Chromecast本体が生産終了したあともキャスト機能は使えますか？
使えます。Googleは2024年8月6日にChromecastの生産終了を発表しましたが、既存Chromecastのサポート方針に変更はないとしています。ただし継続すると明記されているのは最新デバイス向けのソフトウェア更新とセキュリティ更新です。後継のGoogle TV Streamerもキャストに対応し、Chromecast built-inを搭載したテレビやNestスピーカーも受信側として動作します。
iOS版Chromeからキャストできますか？
できません。Web Senderの対応ブラウザ一覧にiOS版Chromeは含まれておらず、公式に対象外とされています。iPhoneやiPadを対象にする場合は、ネイティブアプリに4.8.6以降のiOS送信側SDKを組み込む構成になります。
