Browser Kittyでは、同じ「完全ローカル処理」のツールでも、あるブラウザでは使える機能が別のブラウザでは使えないことがあります。PCでは使えるのにスマートフォンでは使えない、同じブラウザ名でも端末によって高速化機能が使えない、といった差もあります。

これは「完全ローカル処理」と矛盾しません。この記事でいう完全ローカル処理は、ユーザーの処理対象データを外部サーバーへ送らず、その処理を端末内で完結させることを指します。対して、どの機能を使えるかは、その環境がどのWeb APIを実装し、Secure Context・権限・ユーザー操作などの条件や、OS・ハードウェアの要件を満たしているかという別の話です。

同じローカル処理でも、機能可否を決める5つの層

Locality

データをどこで処理するか

ファイルや入力内容を外部サーバーへ送るのか、端末内のJavaScript・Wasm・Web APIで処理するのか。これは「完全ローカル処理」を判断する軸です。

API

そのWeb APIを実装しているか

Web NFCやWebGPUなど、すべての主要ブラウザに同じ時期・同じ範囲で実装されているわけではない機能があります。API自体が存在しなければ、その機能は使えません。

Context

Secure Context・権限・ユーザー操作などの条件を満たすか

カメラ、画面共有、Web Share、Wake LockなどにはSecure Contextや権限、ユーザー操作、Permissions Policyなどの条件があります。API対応だけでは利用可否は決まりません。

Device

OS・GPU・NFC・コーデックがあるか

WebGPUのアダプター、NFCハードウェア、動画コーデック、端末内音声などは環境依存です。同じAPIが見えていても、使える構成や性能は端末ごとに変わります。

Fallback

使えないときにどう振る舞うか

高速化や補助機能を必須条件にせず、基本機能を別経路で残せるかが重要です。Browser Kittyでは、対応確認後に機能を有効化し、必要なら別方式へ切り替えます。

「完全ローカル」と「同じ機能が使える」は別の話

「完全ローカルか」はデータの流れを見る話で、「その機能が使えるか」はAPIの有無、利用条件、端末能力を見る話です。たとえば画像処理自体はJavaScriptやWasmで端末内に完結できても、Web Share、WebGPU、Web NFCなどの補助機能が全環境で同じように使えるとは限りません。

ブラウザは1つの固定された実行環境ではない

Web標準があっても、すべてのブラウザが同じ日に同じ機能を実装するわけではありません。さらに、デスクトップ版とモバイル版、OSのWebView、古いブラウザなどでは対応時期や利用条件がずれることがあります。MDNのBaselineは主要ブラウザでの対応状況を要約する目安ですが、古い端末やWebView、性能、権限まで保証するものではありません。

2026年9月時点のMDNでは、WebAssemblyやカメラ・マイク取得のgetUserMedia()は広く利用可能とされています。一方、Web NFC、WebGPU、Web Share、WebCodecsのVideoEncoderなどは「利用可能性は限定的」とされています。Screen Wake LockはBaseline 2025として最新環境へ広がりましたが、古い端末やブラウザでは使えない場合があります。

執筆時点の代表的なWeb APIと、Browser Kittyで気にする点
機能MDN上の状況（2026年9月）実装時に見る点
WebAssembly広く利用可能Wasm自体に加え、メモリ量・Worker・CSP・性能を確認
getUserMedia()広く利用可能Secure Context、カメラ・マイク権限、端末の入力機器を確認
Screen Wake LockBaseline 2025古い環境、画面の可視状態、端末・ユーザー設定を確認
Web Share利用可能性は限定的OS共有機構、共有できるデータ種別、ユーザー操作条件を確認
WebCodecs VideoEncoder利用可能性は限定的APIの有無だけでなく、使いたいコーデック設定が対応するか確認
WebGPU利用可能性は限定的APIの有無、GPUAdapter取得、features / limits、端末性能を確認
Web NFC利用可能性は限定的・Experimental対応ブラウザ、NFC端末、NDEF対応タグ、利用条件を確認

APIが見えていても、使いたい構成まで対応しているとは限らない

動画処理では特に分かりやすいです。WebCodecsのVideoEncoderが存在していても、使いたいコーデック、解像度、フレームレート、ハードウェアアクセラレーションの組み合わせがその端末で使えるとは限りません。そのためWebCodecsにはisConfigSupported()があり、実際に使う設定を問い合わせてから処理経路を選べます。

WebGPUでも同様です。navigator.gpuが存在していても、requestAdapter()で適切なGPUAdapterを取得できない場合があります。さらに取得できたアダプターごとにfeaturesやlimitsがあります。「APIがあるか」だけを見るのではなく、「この端末で必要な能力が使えるか」まで確認する必要があります。

Secure Contextが必要でも、処理がクラウドになるわけではない

カメラ・マイク、画面共有、WebGPU、Web Share、Screen Wake Lockなどの強力な機能には、HTTPSなどのSecure Contextが必要なものがあります。これは強力なAPIを信頼できる文脈に限定するためのWebの安全要件であり、「データをサーバーで処理する」という意味ではありません。

たとえばHTTPSで配信されたページが、ユーザーのカメラ映像をgetUserMedia()で取得し、その映像をCanvasやWasmで端末内処理することはできます。また、localhostやfile://も状況によって信頼できるオリジンとして扱われますが、APIごとの条件やブラウザ実装は同一ではありません。Browser Kittyでは、単一HTMLとして動くかと、各APIの利用条件を分けて確認します。

Browser Kittyで実際に遭遇した3つの差

Browser Kittyでは、ブラウザ差を「対応ブラウザ一覧」だけで処理せず、実際の機能単位で扱っています。同じツールの中でも、基本機能と高速化・OS連携を分けることで、対応していないAPIが1つあるだけでアプリ全体が使えなくならないようにしています。

Browser Kittyの実装例
ツール環境差が出る機能現在の扱い
Presentation Video MakerWebCodecs / 端末内読み上げの録音経路対応環境ではWebCodecsで高速生成し、使えない場合はMediaRecorder + FFmpeg Wasm経路へ切り替える。スマホではTTS録音を使わず、マイク録音または音声ファイルを使う
Wi-Fi共有Web Share / Screen Wake Lock / Web NFCQR生成やコピーを基本機能にし、OS共有やWake Lockを補助機能として扱う。NFCタグ書き込みは対応環境だけのExperimental機能
Smart Image Sorter画像形式のデコードと端末性能AIモデルとランタイムはHTMLへ内包してローカル推論するが、画像形式のデコード可否や大量・高解像度画像を処理できる余裕はブラウザ・OS・端末で変わる

フォールバックは「機能を諦める」ためではなく、基本機能を残すためにある

ブラウザ差への対応では、最初から全環境で同じ高速化機能を要求するより、まず基本機能を成立させ、その上に利用できる環境だけ拡張機能を載せる方が安定します。これはProgressive Enhancementに近い考え方です。

Browser Kittyでは、API名の有無だけでなく、必要に応じて実際の能力も確認します。WebCodecsなら使いたい設定の対応可否、WebGPUならアダプター、Web Shareなら共有可否などです。使えないときは別経路へ切り替える、ボタン自体を出さない、Experimentalと明示するなど、機能ごとに扱いを変えます。

「このブラウザ対応」より、「この機能がこの環境で使えるか」を見る

「Chrome対応」「Safari非対応」のようなブラウザ名だけの表は分かりやすい反面、実際にはバージョン、OS、端末、GPU、コーデック、権限設定でも結果が変わります。そのためBrowser Kittyでは、ブラウザ名による決め打ちより、必要なAPIや能力をその環境で確認し、使えない場合は「この環境では利用できません」「別の方法を使えます」と案内する設計を優先します。

Browser Kittyでブラウザ差を扱う5つの方針

完全ローカル処理という前提を崩さず、PC・スマートフォン・ブラウザの差を吸収するため、実装では次の順番で考えます。

  1. 機能検出をするnavigatorや対象APIの存在を確認し、ブラウザ名だけで利用可否を決めないようにします。
  2. 必要な能力まで確認するWebCodecsのコーデック設定やWebGPUのアダプターなど、APIが存在するだけでは足りない機能は実際の能力まで確認します。
  3. 基本機能を先に成立させるQR生成、ファイル読込、Wasm処理など、より広く使える仕組みで基本の目的を達成できる経路を先に作ります。
  4. フォールバックを用意する高速化APIやOS連携が使えないときは別方式へ切り替える、機能を非表示にする、Experimentalと明示するなど適切に劣化させます。
  5. 実機でPC・スマホを確認するデスクトップだけでなくスマートフォンでも、権限、画面サイズ、メモリ、Secure Context、OS連携を含めて実際のワークフローを確認します。
Browser Kittyで試す

Presentation Video Maker

PowerPoint（PPTX）を読み込み、発表者ノートや録音・音声ファイルを使ってナレーション付きMP4を完全ローカルで作成します。

ツールを開くツールの詳細を見る

注意点

  • 「APIがある」と「そのAPIで目的の設定が使える」は別です。特に動画コーデックやGPUは、機能検出の後に能力確認が必要になることがあります。
  • Secure Contextが必要という表示を、クラウド処理の証拠とは考えません。HTTPSなどは強力なAPIを安全な文脈で公開する条件であり、処理場所とは別の軸です。
  • 対応状況は変わります。記事やUIで特定ブラウザを永続的に決め打ちするより、実行時の機能検出と、公開前の実機確認を組み合わせる方が長く保ちやすくなります。

よくある質問

完全ローカル処理なのに、Safariでは使えない機能があっても矛盾しませんか？

矛盾しません。完全ローカル処理は、ユーザーの処理対象データを外部サーバーへ送らず端末内で処理するという意味です。Web APIの対応状況は別の問題で、その機能をブラウザが実装していなければローカル処理のままでも利用できません。

Secure Contextでないと使えない機能は、サーバー処理なのですか？

いいえ。Secure Contextは強力なWeb APIを信頼できる文脈だけに公開するための条件です。通常はHTTPSが使われますが、localhostやfile://が信頼できるものとして扱われる場合もあります。いずれの場合も、カメラ映像、ファイル、動画、AI推論などの実処理を端末内だけで行うことはできます。

WebAssemblyが広く使えるなら、FFmpegやAIもどのブラウザでも同じように動きますか？

必ずしも同じにはなりません。Wasm自体が使えても、利用可能メモリ、Worker、SIMDやスレッド条件、画像・動画の入出力、端末性能など別の要素があります。重い処理では「起動できる」と「実用的な速度・容量で動く」も分けて考える必要があります。

WebCodecsがあるかだけ確認すれば十分ですか？

十分とは限りません。VideoEncoder.isConfigSupported()のように、実際に使いたいコーデックや設定が現在の端末で対応しているか確認できます。Browser Kittyでも、高速経路を使う前に環境の能力を確認する考え方を採ります。

ブラウザ名ではなく機能検出を使うのはなぜですか？

同じブラウザ名でも、バージョン、OS、端末、WebView、GPUやコーデック、権限設定で利用できる能力が変わるからです。実際に必要なAPIや設定をその環境で確認する方が、将来のブラウザ更新にも追従しやすくなります。

単一HTMLをオフラインで開けば、Web版と同じ機能が全部使えますか？

いいえ。JavaScriptやWasmなど多くの処理は単一HTML内で完結できますが、Secure Context、オリジン、権限、OS連携などの条件を持つWeb APIは実行方法によって挙動が変わることがあります。Browser Kittyでは単一HTML動作と各Web APIの条件を別々に確認します。

参考資料

ブラウザ対応状況は時間とともに変わるため、この記事では2026年9月時点のMDN Baselineと各APIの公式ドキュメントを基準にしています。Browser Kitty側の実装例は各公開リポジトリで確認できます。