グラフィックスAPIの系譜

グラフィックスAPIとは何を規定するものか

グラフィックスAPIは、CPU上のアプリケーションが GPU（/hardware-components/）に描画・計算の命令を渡すための規約 です。頂点の座標、テクスチャ、シェーダ（GPU上で動く小さなプログラム）、そして「どの順にどう描くか」をAPIの呼び出し列として表現し、ドライバがそれをGPU固有の命令ストリームへ翻訳します。

系譜を貫く一本の軸は 「ドライバがどれだけの仕事を肩代わりするか」 です。初期のAPIは状態管理・メモリ配置・同期の大半をドライバに隠蔽させ、アプリは少ない呼び出しで描けました。その代償がCPU側のオーバーヘッドと予測不能な挙動です。近年のAPIはこれらの責任をアプリ側へ明け渡し、薄いドライバと引き換えに性能と並列性を得ました。以下、この責任移譲を年代と分岐で辿ります。

パイプラインの共通骨格 ── どの世代も変わらない土台

APIの世代が変わっても、GPUがフレームを作る大枠のパイプラインは共通です。ここを押さえると、各APIが「どの段をどう抽象化したか」で比較できます。

[頂点データ] → 頂点シェーダ → ラスタライズ → フラグメント（ピクセル）シェーダ → 出力合成 → [フレームバッファ]
                (座標変換)     (三角形→画素)     (色の決定)               (深度/ブレンド)

  ・頂点シェーダ    : 各頂点をクリップ空間へ変換
  ・ラスタライズ    : 三角形を覆う画素を列挙（固定機能）
  ・フラグメントシェーダ: 各画素の色を計算（テクスチャ参照など）
  ・出力合成        : 深度テスト・アルファブレンドで既存画素と混ぜる

初期は各段が 固定機能（設定で振る舞いを選ぶだけ） でした。世代が進むと頂点・フラグメント段が プログラマブル（シェーダで自由に記述） になり、さらにジオメトリ／テッセレーション／コンピュートといった段が加わります。APIの進化とは、この骨格の各段をどれだけ開放し、どれだけアプリに制御させるかの歴史です。

第一世代 ── 状態機械型と固定機能（1992〜）

出発点は 状態機械（ステートマシン）型API です。GPUを「多数のスイッチとレジスタを持つ一つの大きな機械」とみなし、色を有効化 この行列を積む このテクスチャを束ねる と状態を次々セットしてから 描け（draw） を呼ぶ、という手続きで進めます。

• OpenGL（1992, SGI由来）: クロスプラットフォームの業界標準。グローバルな状態機械が核で、glEnable 等で状態を変え、暗黙のコンテキストに描画命令を積む。移植性が高く、CAD・科学可視化・ゲームまで広く普及した。
• Direct3D（1996, Microsoft）: Windows/Xbox向け。Microsoft は 1995 年に RenderMorphics を買収し、その 3D エンジンを DirectX 2.0（1996）として初出荷した。初期はCOMベースで扱いづらかったが、DirectX 9（2002）で洗練され、Windowsゲームの事実上の標準になった。

この世代の設計思想は 「少ない呼び出しで、移植しやすく描ける」 ことです。ドライバが状態の整合・メモリ確保・GPUとの同期をすべて背負うため、アプリの記述は簡潔でした。

状態機械型の典型的な発行（擬似コード）:

  bindShader(myShader)
  bindTexture(0, brickTexture)
  setUniform("mvp", matrix)      // ドライバが内部状態を更新
  setBlendMode(ALPHA)
  draw(mesh)                     // ここまでの「状態」が暗黙に適用される

第二の分岐 ── プログラマブルシェーダの導入（2000〜）

固定機能では表現が頭打ちになり、各段を自由に記述する プログラマブルシェーダ が導入されます。DirectX 8.0（2000）が頂点／ピクセルシェーダ（シェーダモデル1.0）を実用化し、翌2001年の GeForce 3 で対応ハードが普及。OpenGL も拡張と、のちの GLSL（OpenGL 2.0, 2004）で追随します。これによりライティングや特殊効果がアプリ側のコードで決まるようになりました。

重要なのは、これが API骨格の置き換えではなく、状態機械型の枠内での機能追加 だった点です。DirectX 9〜11、OpenGL 2〜4 は依然として状態機械型のまま、シェーダという「差し替え可能な部品」を各段に挿せるように進化しました。この時期にモバイル向けの分岐も生まれます。

なぜ「明示的・低レベル型」へ移ったのか

2010年代前半、GPUの演算能力は伸び続けたのに、状態機械型APIでは CPU側の準備が追いつかない 場面が増えました。低レベル化の動機は主に3つです。

1. ドローコールのCPUオーバーヘッド: 状態機械型はコールごとにドライバが状態検証・メモリ管理・シェーダ再コンパイル判断を行う。これが積もりCPU律速になる。
2. マルチスレッド化のしにくさ: グローバルな暗黙コンテキストは基本的に単一スレッド前提で、複数コアから並行して描画命令を積みにくい。
3. 予測不能なドライバ挙動: メモリ確保や同期のタイミングをドライバが握るため、フレーム時間が安定せずカクつき（スタッター）の原因になる。

解は 責任をアプリへ移す ことでした。状態を毎回セットする代わりに、あらかじめ全状態を固めた パイプラインステートオブジェクト（PSO） を作る。命令はその場で実行せず コマンドバッファ に記録し、複数スレッドで並行に組み立ててからまとめてキューへ投入する。メモリ確保・同期・GPUとCPUの整合（バリア）もアプリが明示的に指示します。

明示的・低レベル型の発行（擬似コード）:

  pso = createPipelineState({ shader, blend, depth, layout })  // 状態を事前に固める
  // 複数スレッドで並行にコマンドを記録できる
  cmd = beginCommandBuffer()
    cmd.bindPipeline(pso)
    cmd.bindDescriptorSet(resources)   // テクスチャ等をまとめて束ねる
    cmd.draw(mesh)
    cmd.pipelineBarrier(...)           // 同期はアプリが明示
  submit(queue, cmd)                   // 記録済みバッファを一括投入

第三世代 ── 明示的・低レベル型API（2014〜）

この思想を体現するAPI群が2010年代半ばに出そろいます。いずれも 薄いドライバ＋明示的な制御 という共通DNAを持ちますが、由来と対象プラットフォームで分岐します。

系譜として押さえるべきは分岐の親子関係です。Mantle（AMD）が低レベル化の口火を切り、その資産が Khronos に渡って Vulkan になった。Vulkan は系譜上 OpenGL の後継 にあたり、両者を同じ標準化団体（Khronos）が管理します。一方 DirectX 12 は Direct3D 11 の直系後継、Metal は Apple が自社の OpenGL/OpenGL ES を置き換えるために作った独自系統 です。

Web系統の分岐 ── WebGL から WebGPU へ

ブラウザ上のGPUアクセスは、その時代のネイティブAPIを写す 形で分岐しました。ここでもネイティブと同じ「状態機械型→明示的型」の世代交代が起きています。

• WebGL（2011）: OpenGL ES 2.0 をほぼそのままJavaScriptに写したAPI。状態機械型で、gl.bindBuffer 等の呼び出しで描く。WebGL 2.0（2017）は OpenGL ES 3.0 相当。ブラウザ標準としてプラグイン不要の3Dを実現した。
• WebGPU（2023勧告作業）: Vulkan／Metal／DirectX 12 世代を写した 新API。ブラウザは内部でこれら各ネイティブAPIへ橋渡しする。コマンドエンコーダ・パイプラインオブジェクト・明示的リソースバインドという低レベル型の語彙を持ち、コンピュートシェーダ（GPU汎用計算）も正式に扱える。

Web系統とネイティブの対応:

  WebGL   ≒ OpenGL ES  （状態機械型・固定的な単一コンテキスト）
  WebGPU  ≒ Vulkan/Metal/D3D12 の共通項（コマンドバッファ型・明示的）

  ブラウザ実装は WebGPU 呼び出しを
    Windows → D3D12 / Vulkan
    macOS   → Metal
    Linux   → Vulkan
  へ翻訳する（同じWebGPUコードが各OSのネイティブAPIで動く）

WebGPU が状態機械型を捨てたのは、ネイティブ側が低レベル化した後にWebへ移植する以上、新しいネイティブAPI群の最大公約数を取るのが自然だった からです。AI推論やGPGPU（/ai/）をブラウザで動かす需要も、コンピュート主体のWebGPUを後押ししました。

系譜の全体像 ── 年代と分岐のまとめ

1992  OpenGL (SGI) ──┬───────────────► OpenGL 4.x (2010) …状態機械型・肥大化
                     │
                     └─► OpenGL ES (2003) ──► WebGL (2011) …Web状態機械型
1996  Direct3D ──► D3D9(2002) ─► D3D11(2009) …状態機械型の完成
2000  プログラマブルシェーダ導入（D3D8.0 / のちGLSL）…状態機械型の枠内で機能追加
                     ┌─ ここから低レベル化への分岐 ─┐
2013  Mantle (AMD) ──► （資産をKhronosへ）
2014  Metal (Apple) …Apple独自・低レベル
2015  DirectX 12 …D3D11の直系後継・低レベル
2016  Vulkan (Khronos) …Mantle源流・OpenGL後継系統・低レベル
2023  WebGPU …Vulkan/Metal/D3D12を写したWeb低レベル型

まとめ

• グラフィックスAPIの系譜は 「ドライバがどれだけ隠すか」 を軸に、固定機能 → プログラマブルシェーダ → 明示的・低レベル制御へと責任がアプリ側へ移ってきた。
• 状態機械型（OpenGL/DirectX9-11） は少ない呼び出しで移植しやすい反面、ドローコールのCPUオーバーヘッドとマルチスレッド発行のしにくさが限界だった。
• 明示的・低レベル型（Vulkan/DirectX12/Metal, 2014〜） は Mantle を源流に、PSO・コマンドバッファ・明示的同期でCPU律速を解消。Vulkan=OpenGL後継、D3D12=D3D11後継、Metal=Apple独自と分岐する。
• Web系統 は WebGL（OpenGL ES を写した状態機械型）→ WebGPU（Vulkan/Metal/D3D12 を写した明示的型）と、ネイティブの世代交代を追って進化した。
• 低レベル化は性能と並列性を得た一方、管理責任を開発者へ転嫁したため、実務ではエンジンが低レベルAPIを覆う構成が主流である。