シリーズ: AI とともにコードを学ぶ

GDCとモバイルプラットフォーム電撃戦を振り返る

GDC前夜のリリースと、2プラットフォーム分のモバイル攻勢。

1つのC API、あらゆる面へ GDCデモビルド、iOSとAndroidが同じ週に出荷された RakuAI C API タッチ / オーディオ / GPU / アセット iOS・Metal Android・Oboe デスクトップデモ ブラウザフォールバック 空間オーディオ: あらゆるプラットフォームでのHRTF定位
プラットフォームを追加することは、決まった形であって、際限のないアーキテクチャ問題ではない。

本物のコードで動く本物のエンジンは、どんなデッキにも勝る。RakuAIはそれをGDCに持ち込み、同じ週に2つのモバイルプラットフォームを出荷し、新しい面を追加することが決まった形であり、書き直しではないことを証明した。

GDCから1か月が経った。帰りのフライトはメモでいっぱいだった。廊下やサイドミーティングで始まった会話は、今もなお受信箱の中で反響し続けている。今日は、旅の直前に何が出荷されたか、何がほとんど間に合わなかったか、そしてそこから何が生まれたかを書き留めるのにちょうどいい土曜日だ。

GDCとは、3日間の濃密な会話の中で、自分の前提のどれが正しく、どれが事実として扱っていた単なる推測だったのかを知る場所だ。私は両方の種類の答えを持ち帰り、想定していたよりも長いフォローアップリストを持ち帰った。

リリースタグが物語る

私が持ち込んだラップトップで動いていたバージョンはv1.3.8.26.10.09だ。それをバンプしたコミットのメッセージは一行、「GDC 2026 Eve Release」だった。それが3月25日。翌朝、私は飛行機の中にいた。

GDC前夜のこのコミットこそ、私が書きたいものだ。なぜならそれは、ほとんど間に合わなかったものだからだ。

飛び立つ48時間前

誰もが「あのデモビルド」だと合意していたビルドは、GDCの前の週に4つの異なる形で失敗していた。修正コミットは3月7日のb70a48dcで、「fix(demos): fix black screens, crashes, and expand API test coverage」というタイトルの単一のPRにまとめて取り込まれた。その4つの形とは。

黒画面。 アニメーションショーケース、AI振る舞いテスト、CSGブールテスト、ゲームプレイフレームワークテストがすべて黒画面をレンダリングしていた。原因は、デモがデバッグ描画リソースを登録するために必要としていたraku_editor_init()への呼び出しが欠けていたことだった。CMakeのリンクターゲットは1スプリント前にリファクタリングされており、デモバイナリがエディタライブラリに依存していることに誰も気づかなかったため、それがバイナリから刈り取られていた。修正: リンクを再追加し、init呼び出しを復元。

nullクラッシュ。 SLM対話デモが起動時にnullのQAポインタでクラッシュしていた。対話モデルローダーが、エラーをフラグ立てすることなく、設定が見つからない経路で早期リターンしていた。修正: エラーを表面化させ、動作する設定を出荷する。

即座に切断されるネットワークデモ。 ネットワークエコーデモはソケットを開き、ハンドシェイクを得て、その後閉じてしまっていた。切断検出が、実際のタイムアウトの後ではなく、最初のアイドルフレームで発火していた。修正: 「最初のアイドル」ではなく実際のタイムアウトにする。

OpenXRランタイムなしで終了コード1を返すXRテスト。 ランタイムが存在しない状態で非ゼロ終了するのは、XRランタイムがインストールされていないかもしれないデモマシンにとっては間違ったデフォルト挙動だ。修正: 優雅に終了コード0を返し、不在をログに記録する。

これらのどれも巧妙なものではない。どれも、開発者のマシンでは問題なく見えて、見知らぬ人のマシンでは壊れて見える類のものだ。こうした旅の48時間前というのはまさに、こうした失敗が表面化するタイミングだ。なぜならデモは、来週まさに実際に生きることになるラップトップで、15秒で意見を形成する人々の前で、ようやく実行されるからだ。

間に合わせる必要があった仕上げのコミット

出発前日、3月26日にさらに2つのコミットがあった。

地面プレーンの鏡面反射。 ワールドモデルデモには緑の地面プレーンといくつかの浮遊する形状があった。グローバルな鏡面マテリアルが適用されていたため、緑の地面はデモ照明の下で白く飛んでしまっていた。修正はたった10行だった。地面プレーンにマットマテリアルを、動的なオブジェクトにのみ鏡面反射を適用する。それだけで突然、デモはデバッグ途中のエンジンではなく、意図的なアートディレクションのように見えるようになった。

カンファレンス用ラップトップでのNVIDIA dGPU強制。 Intel UHDとディスクリートのNVIDIAカードの両方を持つハイブリッドラップトップは、明示的なヒントがない限りIntelチップをデフォルトにする。そのヒントとは、2つのエクスポートされたシンボルだ。NVIDIA Optimus用のNvOptimusEnablement、AMDの同等物であるAmdPowerXpressRequestHighPerformance。これらをデモバイナリに追加することで、dGPUを強制した。HUDは今、タイトルバーにGPU名も表示するようになり、デモが実際に何の上で動いているかを一目で確認できる。結果: 統合UHDではなくQuadro T2000上で動作した。フレーム時間は半分以上短縮された。

これらのコミットはどちらも50行に満たない。どちらも、「デモが30フレームで動く」と「デモが90フレームで動き、意図的に見える」の違いだ。

より良い実演になったブラウザフォールバック

GDCの週に着地したもう一つのものは、web/seed-explorer/にあるスタンドアロンのブラウザデモだった。単一のHTMLファイル、依存関係ゼロ、ランタイムがネイティブ側で使っているSimplexノイズ地形ジェネレータのJavaScript移植版だ。生成されたワールドの3つのビューを、putImageDataを使って512x512のキャンバスにレンダリングする。バイオームマップ、高度マップ、気温マップだ。シードを共有可能にするためのraku://seed/というURLスキームが組み込まれている。

これは本来、ラップトップが不調になったり、会場のWi-Fiが混乱したりした場合のバックアップであるはずだった。それが、サイドの会話で私が実際に最も頻繁に開くものになった。コーヒーショップのテーブルの上にある他人のラップトップは、その場で私たちのSDKをインストールすることはできないが、URLを読み込むことはできる。会話は「バイナリを送ってくれ」から「このリンクを開いて」へと変わる。それは異なる種類の会話だ。ブラウザデモはローテーションに残ることになった。

モバイルプラットフォーム電撃戦

3月のもう半分はiOSとAndroidで、どちらも同じ週に出荷された。

Android。 F1シリーズ(F1.2からF1.15まで)で12個のコミット。NativeActivityとJNIブリッジの骨組みから始まり、Androidパフォーマンスプロファイラで終わる。その間には、JNI経由で配線されたタッチ入力、AABビルド用のGitHub Actionsワークフロー、Firebase Crashlyticsの統合、そしてオーディオバックエンドとして有効化されたOboeがある。Oboeは、Android上での低レイテンシオーディオにとって正しい選択だ。それを包むC APIラッパーにより、同じオーディオコールバックがクロスプラットフォームで動作する。

iOS。 F2シリーズ(F2.1からF2.7まで)で、2日間にわたる7個のコミット。Xcodeプロジェクトと Swiftアプリシェルから開始。arm64クロスコンパイルツールチェーンを追加。Metalをレンダラーとして配線した(F2.2のコミットメッセージには「iOS Metal renderer integration, glue layer, CMake toolchain, 51 tests」とあり、テスト数の部分が私が最も誇りに思うところだ)。UIGestureRecognizerによるジェスチャー入力を追加。AVAudioEngineの上に空間オーディオバックエンドを構築。URLSession経由でアセットバンドルのダウンロードとキャッシュを配線。

両プラットフォームとも同じ形を得た。タッチ、オーディオ、GPU、アセット配信を、デスクトップランタイムが使うのと同じC APIに公開する薄いネイティブ層だ。それが契約だ。プラットフォーム固有のコードは実装にすぎない。ここから新しいプラットフォームを追加することは、決まった形であって、際限のないアーキテクチャ問題ではない。

空間オーディオこそ過小評価されている勝利

私が今も質問を受け続けている仕事の部分は空間オーディオだ。ヘッダーはinclude/raku/raku_spatial_audio.hにある。実装はプラットフォームごとに分かれている。空間定位のためのHRTF処理、チャンネルごとの制御のためのミキサーグループ、エフェクト(リバーブ、ディレイ)、そして室内音響のためのリバーブゾーン。Androidではオーディオ経路はOboeだ。iOSではAVAudioEngineだ。空間オーディオのコミットは3月6日のe0aef6c6だ。

これがARエンジンにとって重要な理由は、オーディオが没入感の半分を占めるからだ。ステレオ(あるいはもっと悪ければモノラル)オーディオを伴うビジュアルARは、ユーザーが頭を動かした瞬間に没入感を壊す。ユーザーの動きに合わせて更新される空間オーディオは、仮想コンテンツがまるでその部屋にあるかのように感じさせる。コストは本物だ。HRTF処理はタダではない。しかし利益も本物だ。良い空間オーディオのデモを見て、それを無効にしてほしいと言ってきた人は今まで一人もいない。

GDCが実際に動かしたもの

書き留める価値のある3つのこと。

パートナーとの会話。 廊下での会話やサイドミーティングこそが、今カレンダーに着地しつつあるものだ。カンファレンスのトークは素晴らしかった。トークの合間の会話こそが、この旅を元が取れるものにした理由だ。将来のある土曜日に、パートナーの方向性について具体的に書くとき、これらのスレッドがその内容になるだろう。

この分野がどこにあるかについての、より明確な読み。 ワールドモデルについて、AI駆動のコンテンツパイプラインについて、研究デモと出荷可能なランタイムの間のギャップについて、複数の異なるベンダーによる空間ARハードウェアのロードマップについてのセッションがあった。私が競争環境について仮定していたことのいくつかは正しかった。私が密かに心配していたいくつかのことは、思っていたよりも脅威が少ないことが判明した。私が心配していなかったいくつかのことは、より多くの注意に値することが判明した。この再調整だけでも、フライトの価値はあった。

続ける許可。 GDCは強制の契機だった。私が持ち歩いていたデモは完璧ではなかった。しかしそれは具体的で、本物のコードで動く本物のエンジンであり、デッキとは異なる種類の問いに答えるものだった。「フォローアップメールを送ってくれ」という反応の数は、この方向性が正しいことを確認するのに十分なほど多かった。それがその指標だ。

モバイルプラットフォームは出荷された。私が見せたデモは動いた。ブラウザフォールバックは機能へと変わった。土曜日をよく使った。

あなたの顔にあるデバイスのために作られたランタイム

1つのC API、どこでも空間オーディオ、そしてスマートグラス向けに設計された熱感知型ランタイム——縮小されたPCエンジンではない。あなたのAIが実世界のどこに宿るかを見てほしい。

← すべての記事