－もうひとつのFlash史（What If）
※本記事はフィクションです。
本記事はFlashの技術史をもとにした架空の歴史です。
登場する〇dobe社の経営判断、ロードマップ、製品発表、組織再編、プロジェクトはすべて創作です。一方で、Flash、ActionScript、Flex、Adobe AIRなど実在した技術や、当時の業界情勢を踏まえ、「もし〇dobeが別の選択をしていたら」という視点で構成しています。
本記事の目的は歴史を書き換えることではありません。当時存在した技術だけを使って、Flashという巨大な実験が別の未来へ進めた可能性を考察することです。
200X年 〇dobe、「PIKAPIKA Enterprise Program」を発表
Flashはアニメーションだけでなく、Flexの登場によって企業システムのフロントエンドとして急速に採用が進み始めていた。従来のHTMLでは難しかったドラッグ＆ドロップや複雑なデータグリッド、高速な画面更新を実現できることから、金融、物流、製造業を中心に大規模な業務システムへの導入が相次いでいた。しかし社内調査では、ActionScriptへ認証、権限管理、帳票生成、在庫管理など本来サーバー側で処理すべき機能まで実装されるケースが増え、数十万行規模のActionScriptプロジェクトも珍しくなくなっていた。画面を描くためのランタイムが、業務システムそのものへ変質し始めていたのである。
〇dobeはこの流れを長期的なリスクと判断し、「PIKAPIKA Enterprise Program」を開始する。新しいEnterpriseアーキテクチャでは、Flashは画面描画、入力、アニメーション、データ表示だけを担当し、認証、データベース、帳票生成、トランザクション管理、ファイル操作はJava、ColdFusion、.NETなどサーバー側へ配置することを標準構成として推奨した。同時にFlexコンポーネントもこの設計へ最適化され、ActionScriptから直接データベースへアクセスする設計は非推奨となる。
この方針は、Flash Runtimeを「業務アプリケーション」ではなく「高機能な画面描画エンジン」へ戻すことを目的としていた。クライアント側へ業務ロジックを書かないことで、セキュリティ更新の影響範囲を小さくし、Flash Runtime自体の役割も明確になる。〇dobeは「Flashはリッチクライアントではなく、Thin Client 2.0である」という新しいメッセージを打ち出し、企業システム向け製品の方向性を大きく転換した。
200X年 〇dobe、「PIKAPIKA Secure Profile」を導入
当時のFlashは、ゲーム、広告、動画プレーヤー、企業システムがすべて同じFlash Player上で実行されていた。利用目的はまったく異なるにもかかわらず、利用できるAPIは基本的に共通であり、広告バナーも本格的なゲームも同じActionScript VMと同じJITコンパイラを使用していた。この設計は開発効率には優れていたが、「広告を見るだけなのにゲームエンジンまで起動する」という批判も増え始めていた。
〇dobeは用途ごとにRuntimeの権限を変更する「PIKAPIKA Secure Profile」を発表する。広告、動画、教育、企業システム、ゲームという五つの実行プロファイルを定義し、それぞれ利用可能なAPIを制限した。広告プロファイルではJITを無効化し、ローカルストレージ、カメラ、マイク、クリップボードへのアクセスを禁止する。動画プロファイルではActionScript VM自体を読み込まず、企業システム向けではGPU APIを標準で無効化するなど、用途に応じてRuntime自体が変化する設計となった。
〇dobeはこれを「最小能力実行（Minimum Capability Execution）」と呼び、Flash全体へ一律に権限を与える設計を終了する。特に広告ネットワークから配布されるSWFは広告プロファイルでしか実行できず、仮に広告経由で不正なSWFが配布されても、利用できるAPIそのものが制限されるため、被害の拡大を抑えられると説明した。
200X年 〇dobe、「PIKAPIKA Process Architecture」を公開
Flash Playerは普及率98％を超える一方で、コードベースは急速に巨大化していた。ActionScript VM、動画デコーダ、音声デコーダ、画像解析、フォント処理、GPU描画、ネットワーク通信が一つのプロセスへ集約されていたため、一つの脆弱性がPlayer全体を危険にさらす構造になっていた。当時、ブラウザ自体もまだマルチプロセス化の途上にあり、「巨大な単一プロセス」はFlashだけの問題ではなかったが、普及率の高さゆえにFlashは格好の攻撃対象となっていた。
〇dobeはPlayer内部を全面的に分割する「PIKAPIKA Process Architecture」を発表する。SWFの検証、ActionScript VM、動画・音声デコード、画像解析、GPU描画、ネットワーク通信は、それぞれ独立したプロセスとして動作し、必要最低限の権限しか持たない。Flash Player本体は各プロセスを管理するランチャーへ役割を変更し、相互通信もメッセージパッシング方式へ置き換えられた。
この構成では、たとえば動画デコーダに任意コード実行の脆弱性が見つかっても、侵害されるのは動画プロセスだけである。ActionScript VMやブラウザ本体へ直接侵入することはできず、ネットワーク通信も管理プロセスを経由するため、攻撃者が自由に権限を広げることは難しい。〇dobeはこの設計を「Flash Player最大のアーキテクチャ変更」と位置付け、「性能向上ではなく、生存性を高めるための再設計」であると説明した。
200X年 〇dobe、「PIKAPIKA Mobile」を発表
スマートフォン市場が急速に拡大するなか、〇dobeは従来のFlash Playerをそのまま携帯端末へ移植する方針を見直す。社内の性能評価では、デスクトップ向けFlashは常時電源、高性能CPU、マウス操作を前提として設計されており、バッテリー駆動とタッチ操作が中心となる新しい端末では設計思想そのものが適合しないという結論に達していた。実際、動画再生やゲームではCPU使用率が高く、複雑なActionScriptを含むコンテンツでは発熱や電力消費も課題となっていた。
〇dobeはこの問題を「移植性ではなく設計思想の問題」と位置付け、「PIKAPIKA Mobile」を発表する。従来のFlash Playerから不要な機能を大胆に削除し、JITコンパイラを廃止、描画はGPUアクセラレーションを前提とし、動画再生はOS標準デコーダを利用する構成へ変更した。さらに、通信はHTTPSのみ、バックグラウンド実行は禁止、メモリ使用量には厳格な上限を設け、カメラやマイクへのアクセスは必ずOSの許可ダイアログを経由する仕様とした。
〇dobeは「モバイル版はデスクトップ版の縮小版ではない」と宣言し、この新しい設計を将来のFlash Runtimeの標準へ育てる方針を示した。結果として、モバイル向けに設計された制約がデスクトップ版にも逆輸入され、Flash全体の軽量化とセキュリティ向上につながることが期待された。
200X年 〇dobe、「PIKAPIKA Open Program」を開始
FlashはWeb接続PCのほぼすべてに普及していたが、その実装は実質的に〇dobeだけが管理していた。ブラウザベンダーはFlash Playerを「外部プラグイン」として扱うしかなく、脆弱性への対応も〇dobeの更新を待つ以外に方法がなかった。この状況は、Web全体の安全性を一社の開発体制へ依存させるという構造的な問題を抱えていた。
〇dobeは「PIKAPIKA Open Program」を発表し、SWFファイル形式だけでなく、表示リスト、イベントモデル、ActionScriptバイトコード、サンドボックス仕様、互換性テストまでを公開する方針を示した。ブラウザベンダーやOSベンダーは、これらの仕様を基に独自のFlash Runtimeを実装できるようになる。〇dobe自身も、Flash Playerの独占供給から、制作ツールと互換性認証を提供する立場へ役割を変えていく。
この決定の背景には、「一社だけがRuntimeを開発する時代は長く続かない」という危機感があった。複数実装による相互検証が進めば、脆弱性の発見や修正速度は向上し、Flashは一企業の製品ではなく、Webを支える共通基盤へ進化できると考えられた。
200X年 〇dobe、「PIKAPIKA HTML Strategy」を発表
HTML5、Canvas、SVG、JavaScriptが急速に進化し始めると、Flashが独占してきた機能をWeb標準でも実現できるようになってきた。社内では「Flash Playerを守るべきか、それともFlashという制作文化を守るべきか」という議論が行われる。
〇dobeが選んだのは後者だった。
Adobe Flash Professionalは、Flashを書き出すソフトウェアではなく、HTML5、Canvas、SVG、WebGL、JavaScriptを書き出すオーサリングツールへ進化することが発表される。タイムライン、シンボル、モーショントゥイーン、ライブラリなど、クリエイターが慣れ親しんだ制作環境はそのまま維持し、出力形式だけを段階的にWeb標準へ切り替えていく。
〇dobeは「FlashとはPlayerではなく、制作ワークフローである」という新しいブランドメッセージを掲げる。これにより、クリエイターは長年培ってきた制作手法を変えることなく、新しいWeb技術へ移行できるようになった。Flash Playerは徐々に役割を縮小する一方、Flash ProfessionalはWeb制作ツールとして新たな成長戦略を描くことになる。
200X年 〇dobe、「PIKAPIKA Advertisement Sandbox」を導入
Flashの普及に伴い、インターネット広告の多くがSWF形式で配信されるようになった。一方で、広告ネットワークを経由したマルウェア配布、いわゆるマルバタイジングも社会問題になり始めていた。広告を表示しただけでFlashの脆弱性が悪用される事例が報告され、「広告を見ること自体が危険」という印象が広がりつつあった。
〇dobeは広告専用Runtimeである「PIKAPIKA Advertisement Sandbox」を発表する。広告用SWFは通常のFlash Runtimeでは動作せず、専用サンドボックス内でのみ実行される。JITは完全に無効化され、外部通信は広告配信元ドメインだけに限定される。ローカルストレージ、クリップボード、カメラ、マイク、ドラッグ＆ドロップなど、広告表示に不要なAPIはすべて削除された。
〇dobeは「広告はアプリケーションではない」という方針を打ち出し、広告コンテンツには最小限の実行能力しか与えない設計へ転換した。これにより、仮に広告配信網が侵害された場合でも、攻撃者が利用できる機能は大きく制限され、Flash全体へ被害が広がる可能性を大幅に下げられると説明された。
200X年 〇dobe、「PIKAPIKA Legacy」を発表
HTML5への移行が現実味を帯びる一方、〇dobeにはもう一つの課題が残っていた。それは、十数年間にわたって世界中で制作された膨大なFlash資産である。教育教材、企業研修、デジタルアート、ゲーム、自治体サイト、科学シミュレーションなど、その数は数百万タイトルに達すると推定されていた。Flash Playerを終了させることは、それらを同時に失うことを意味していた。
社内では「Playerを終わらせること」と「作品を失わせること」は別の問題として扱われるようになる。〇dobeはこの考え方を基に「PIKAPIKA Legacy」を発表し、Flashを現役プラットフォームと文化資産へ明確に分離する方針を示した。
PIKAPIKA Legacyは、既存のSWFを閲覧するためだけに設計された専用Runtimeである。ネットワーク機能、JITコンパイラ、ファイル書き込み、カメラ、マイク、クリップボード、外部プログラムの起動など、コンテンツの閲覧に不要な機能はすべて削除された。Runtimeは完全なサンドボックス内で動作し、CPU時間とメモリ使用量にも上限を設けることで、「作品は残すが、攻撃面は残さない」という思想を徹底した。
〇dobeは、「映画を再生するために映写機を保存するように、デジタル作品にも専用の保存環境が必要である」と説明し、PIKAPIKA Legacyを博物館、教育機関、図書館、企業アーカイブ向けへ無償提供すると発表した。
200X年 〇dobe、「PIKAPIKA Converter」を公開
Flash終了に対する企業やクリエイター最大の不安は、「これまで投資してきた資産をどうすればよいのか」という一点だった。当時、世界中には数え切れないほどのSWFが存在し、そのすべてを人手でHTML5へ書き換えることは現実的ではなかった。
〇dobeは「PIKAPIKA Converter」を無償公開する。これは単なるファイル変換ソフトではなく、SWFを解析し、Canvas、SVG、JavaScript、WebGLなど複数のWeb標準技術へ変換する移行支援環境だった。
変換できる部分は自動変換し、ActionScriptの高度な処理や外部ライブラリなど自動変換が困難な部分はレポートとして一覧化する。さらに使用しているAPI、外部通信先、埋め込みフォント、動画形式なども解析し、移行時に修正が必要な箇所を可視化する機能が追加された。
〇dobeは「Flashを終わらせるのではなく、Flash資産を未来へ運ぶことが我々の責任である」と説明し、既存ユーザーが段階的にWeb標準へ移行できる環境づくりを最優先課題とした。
200X年 〇dobe、「PIKAPIKA Platform」構想を発表
Flashを巡る議論は、「Playerを残すべきか、終わらせるべきか」という二者択一になりつつあった。しかし〇dobeは、その議論自体が間違っていると考えていた。
社内戦略会議では、「FlashというブランドをPlayerだけで定義したことが最大の失敗だった」という分析がまとめられる。Flashが評価されていたのは、単なるプラグインではない。タイムラインによる制作環境、ベクターアニメーション、インタラクティブデザイン、豊富な制作ツール群、そしてクリエイターコミュニティそのものだった。
そこで発表されたのが「PIKAPIKA Platform」構想である。
Flashは単一製品ではなく、三つの役割へ再編される。
第一は制作環境であるFlash Professional。HTML5やCanvas、SVG、WebGLを出力するオーサリングツールとして進化を続ける。
第二はPIKAPIKA Legacy。過去の作品を安全に保存し、将来へ継承するための互換Runtimeである。
第三はPIKAPIKA Converter。Flash資産をWeb標準へ移行するための橋渡しとなる変換基盤である。
〇dobeは、「Flashはプラグインからプラットフォームへ進化する」という新しいブランド戦略を打ち出し、Player中心のビジネスモデルから脱却することを宣言した。
200X年 〇dobe、「Flash Playerサポート終了」を発表
数年間にわたる移行期間を経て、〇dobeは一般向けFlash Playerのサポート終了を正式に発表する。
しかし、この発表は世間が予想していたものとは少し違っていた。
終了するのは、ブラウザプラグインとしてのFlash Playerだけだった。
Flash Professionalは制作ツールとして開発を継続する。
PIKAPIKA Legacyは文化資産保存用Runtimeとして提供を続ける。
PIKAPIKA Converterは企業や教育機関の移行支援ツールとして更新される。
さらに、ActionScriptコンパイラやSWF仕様はオープン化され、研究用途やアーカイブ用途で利用できるようになった。
記者会見で〇dobeのCEOは、次のように説明した。
「私たちはFlashを終わらせるのではありません。終わらせるのは、ブラウザプラグインという一つの製品です。Flashが残した制作文化や技術資産は、これからも新しいWebの中で生き続けます。」
エピローグ Flashが残したもの
後年、多くの技術者はこの転換を「Flashの終焉」ではなく、「Flashの分解」と呼ぶようになった。
巨大な一枚岩だったFlash Playerは姿を消した。しかし、その中に含まれていた数多くの技術は、それぞれ独立した形で生き残る。
ベクター描画はSVGとCanvasへ。
動画再生はHTML Videoへ。
音声処理はWeb Audioへ。
GPUアクセラレーションはWebGLへ。
高速実行環境という思想は、より小さく、より安全な設計思想へ受け継がれていった。
皮肉なことに、Flashという製品は姿を変えたものの、Flashが二十年かけて実験してきたアイデアは、ほとんどすべて現代のWebへ受け継がれることになった。
そして技術史家たちは、後にこう記している。
「Flashは消えたのではない。Webそのものへ溶け込んだのである。」
