Graphics Academy Light

この講義では、SGEコア技術本部のグラフィックスチームが日々の開発で実際に取り入れている「AI駆動開発」という進め方をお伝えしていきます。

0 セットアップ

ワークショップ本編（4章）を始める前に、以下のセットアップを済ませておいてください。 各ソフトウェアをインストールするためのコマンドは、WindowsはPowerShell、MacはTerminalを利用してください。

0.1 Git のインストール

Windows

Git for Windows からインストーラーをダウンロードして実行してください。

Mac

ターミナルで以下のいずれかを実行してください。

xcode-select --install   # Xcode Command Line Toolsに同梱のGitを使う場合
# もしくは
brew install git         # Homebrewで最新版を使う場合

0.2 GitHubアカウントの作成

まだGitHubアカウントを持っていない場合は、GitHub にアクセスしてアカウントを作成してください。

0.3 Node.js のインストール

Claude Code・uloop CLI のインストールに必要です。LTS版を使用してください。

Windows

PowerShellを管理者として実行して次のコマンドを実行してください。

winget install OpenJS.NodeJS.LTS

インストール完了後にPCを再起動してください。

Mac

brew install node

0.4 Unity のインストール

Windows/Mac共通の手順です（3.のBuild Supportモジュールの選択のみ異なります）。

1. Unity Hub をインストールします。
2. Unity Hub から Unity 6000.3.19f1 をインストールします（一覧に無い場合は、Unity公式のアーカイブから同バージョンを検索してください）。
3. インストール時のモジュール選択で、以下を追加でチェックしてください。
   • Windows: Android Build Support
   • Mac: iOS Build Support

   このプロジェクトのビジュアルリグレッションテストは、Tools > Sirius > Dev Support > Validate Mobile Target によって、Windows環境ではビルドターゲットが強制的に Android に、macOS環境では iOS に切り替えられます。対応する Build Support が無いとワーク②・③のテストが実行できません。

0.5 リポジトリのクローン

ワークショップ用のリポジトリをCloneしてください。

git clone https://github.com/CyberAgentGameEntertainment/GraphicsAcademyLight.git
cd GraphicsAcademyLight

0.6 Mali Offline Compiler のインストール

Arm Developer から、Mali Offline Compilerを含む Arm Performance Studio をダウンロード・インストールします。

0.7 uloopのセットアップ

Claude Code から Unity Editor を直接操作できるようにするためのセットアップです。Windows/Mac共通の手順です。

以下の1〜2は事前準備として進めておいてください。3〜4は0.5でリポジトリをクローンした後（講義当日）に行います。

1. ターミナル or PowerShellでnpm install -g uloop-cli@2.1.10 を実行
2. ~/.claude/settings.json（Windowsでは C:\Users\<ユーザー名>\.claude\settings.json）の permissions.allow に "Bash(uloop *)" を追加
3. 0.5でクローンしたプロジェクトをUnity Editorで開きます。メニューに Window > Unity CLI Loop が表示されていれば導入は完了です。
4. Unity Editor で Window > Unity CLI Loop > Settings を開き、以下を有効化します。
   • Allow Tests Execution
   • execute-dynamic-code の Security Level を Level 2 (FullAccess) に設定

1 ウォームアップ

サイバーエージェントでは、2028年までに、すべてのプロダクト開発チームが「要件を決めるところから本番リリースまで、AIと一緒に自動で進められる状態」になることを目指しています。ここでエンジニアに求められているのは、AIをただの便利な道具として使うことではありません。「AIエージェントと一緒に手を動かして、事業の成果を生み出すこと」です。実際に、今まで数日かかっていた作業が短時間で終わったり、AIで減らせた分の手間をほかの仕事に回せたりと、成果が少しずつ出はじめています。

1.1 サイバーエージェントで、こんなことが起きています

• 数日かかっていた作業が、数分で終わるチームがあります。
• テンプレートを整えただけで、AIの出す答えの品質がぐっと安定したチームがあります。
• 今までのスクラム（開発の進め方）を壊さずに、AIとの協力をうまく組み込んだチームがあります。

直近の私の作業ですと、メッシュデカールを実現するAir StickerというOSSのJob System + Burst化を行ったバージョン2.0.0をリリースしました。

https://blog.sge-coretech.com/entry/2026/08/06/144416

この対応において、私は一切コードを書いていません。

JobSystem + Burst化を行うためには、データ構造を大きく変更する必要があるため、以前までであれば、10日以上の工数がかかる見込みでした。しかし、AIエージェントを利用することで、テストまで含めて数時間程度で完了しています。

もちろん実装だけではなく、テストコード作成、テストカバレッジの評価、これらもAIが作成/評価しています。

1.2 「個人でAIを使う」から「チームでAIを使う」へ

Cursor や Claude Code といったAIコーディングツールを、みなさんも普段から使っているのではないでしょうか。個人の生産性は、確かに上がっています。でも、こんな場面に心当たりはありませんか？

• 自分が見つけたAIの使い方やプロンプトのコツが、チームのみんなに広がっていない
• 同じチームなのに、人によってAIの使いこなし具合がバラバラ
• AIが書いたコードの「良い・悪いの基準」が人によって違う。「誰がレビューするか」で品質が変わってしまう
• AIのおかげで速く作れるようになったのに、レビューや承認が追いつかない

これは「個人でAIを使うこと」と「チーム・組織でAIを使うこと」の間にある、すき間（ギャップ）です。AIツールの使い方は、一人でも学べます。でも「チームとして、どうAIと協力するか」というやり方は、まだほとんどのチームが持っていません。

1.3 だから、共通の言葉が必要です

昔、私たちがアジャイルやスクラムを学んだとき、「スプリント」「バックログ」「レトロスペクティブ」といった共通の言葉を手に入れました。共通の言葉があると、チーム間でノウハウを共有したり、新しく入った人をすぐに戦力にしたり、組織全体の開発のやり方を底上げしたりできます。

AI駆動開発は、いわば「AI時代の開発の共通言語」です。 今日お話しするのは、明日からすべてを変えるルールではありません。「AIとどう協力して進めるか」を考えるための、ものの見方です。これを知っておくだけで、チームでAIを使うときの話し合いがスムーズになり、ほかのチームの良い事例を自分のプロジェクトに取り入れやすくなります。

1.4 チームとしてのAI活用

このように、サイバーエージェントでは「個人でAIを使う」のはもう当たり前になり、いまは「チームでAIを使うやり方」を固めていく段階に進んでいます。採用で求められるスキルも、個人の活用から一歩進んで、「チームで品質を守るための仕組みづくり」が評価されるようになってきました。

一方で、学校など教育の場でのAI活用には、「お金」という大きな壁があります。 一人でお金を払ってAIを使うのは、まだハードルは低いです。しかし、これがチーム全体でAIを使うとなると、話は変わってきます。 けれども、今日お話しするAI駆動開発は、一人からでも始められます。そして、たとえチーム全体でAIを使うのがむずかしくても、AIコーディングのために整えた仕組みは、AIを使っていないメンバーにもちゃんと役に立ちます。

1.5 SIRIUSを利用したAI活用ワークショップ

このワークショップでは、コアテクグラフィックスチームが開発しているレンダリング基盤「SIRIUS」を利用して行います。

SIRIUSはゲームエンジンではUnityをベースとしながら、各子会社に分散していたシェーダーやレンダリングパイプラインを統合するための描画基盤として開発が進められており、現在は、単なる開発効率化に留まらず、数年先に求められるグラフィック品質を見据えたR&Dの役割も強めています。

今回のワークではSIRIUSで実践されているAI利用を疑似的に体験していただきます。

SIRIUS関連の記事
サイバーエージェントのゲーム・エンタメ事業部が、大規模運営型ゲーム開発を見据えた統合型レンダリングシステム「Sirius」を開発中。Houdiniも推進、現場スタッフに話を訊いた

アーティストの創造性を最大化する横断型テック組織──サイバーエージェントが目指す"アーティストファースト"

現場の声から生まれるゲームエフェクト改善 ー コア技術本部が実践するOSS駆動型R&D戦略 技術・クリエイティブ

2 AI駆動開発とは

AI駆動開発とは、AIを開発の中心に置く、新しいソフトウェア開発の進め方です（AWSが「AI-Driven Development Life Cycle（AI-DLC）」として提唱しているものです）。この章では、AI駆動開発の全体像をお話ししていきます。

2.1 なぜ今、AI駆動開発なのか

2025年、AIコーディングツールは一気に広まりました。Cursor、Claude Code、GitHub Copilot など、多くのエンジニアが毎日のようにAIを使っています。しかし、「個人でAIを使うこと」と「チーム・組織でAIを使うこと」の間には、大きな違いがあります。

段階	どんな状態か	課題
個人でのAI活用	各自がCodexやClaude Codeを使う	知識が個人に閉じてしまい、品質もバラつく
チームでのAI活用	チームでプロンプトや設定を共有する	進め方そのものは昔のまま。一部だけの改善にとどまる
AI駆動開発	AIが開発の中心的なパートナーになる	← ここを目指します

AI駆動開発は、「AIにコードを書いてもらうこと」ではありません。AIが開発全体の進行役になり、自分から分析して提案する。そして人間がそれを判断する。この関係を、一つのやり方としてまとめたものです。

2.2 AI駆動開発の考え方

「AIにコードを書いてもらう」のと「AIと一緒に開発する」のは、やっていることがかなり違います。AI駆動開発は後者の考え方で、AIを補助ツールではなく、開発の中心にいる協力者として扱います。

下の図は、AIを使った開発の3つのやり方を、「AIにどれだけ任せるか（自律度）」と「品質・ガバナンス（安全に管理できているか）」という2つの軸で並べたものです。AI駆動開発は、AI支援型の安全さと、AI自律型の速さを、高いレベルで両立させることを目指すやり方です。

やり方	説明	特徴
AI支援型開発	人間が中心で開発を進め、AIはコード補完やレビューの手伝いとして使う	安全さ重視。AIに任せる度合いは低い
AI自律型開発	AIにほとんど任せて、人の関わりを最小限にする（Vibe Codingなど）	速いけれど、品質・安全さが下がるリスクがある
AI駆動開発	AIが計画・実装を提案し、人間が承認・チェックする協力スタイル	速さと安全さの両方を実現する、理想の位置を目指す

2.3 いちばん大事な考え方（コアメンタルモデル）

AI駆動開発を理解するうえで、いちばん大事なのがこの「コアメンタルモデル」です。要件定義・設計・コーディング・テスト・運用といった開発のいろいろな作業が、この4ステップの高速サイクルにまとまります。

人間がやることは、最初の「やりたいこと」をAIに渡すことだけです（この「やりたいこと」を Intent と呼びます。Intent は「Description＝何を」「Context＝なぜ・どんな制約か」「Completion Criteria＝どうなったら完成か」の3つでできています）。そこから先は、AIが進行役になります。AIが計画を立て、分からない点を整理して質問し、いくつかの選択肢を出し、人間の承認をもらってから実装する。この流れを、AI自身が回していきます。

具体例：要件を分析するとき

AI駆動開発では、「AIが自分から提案し、人間が判断する」という形が大切になります。

• AIは受け身で待つのではなく、自分から提案する
  • 人間はすべてを指示するのではなく、AIの提案に対して「これでいい／ここは違う」と判断する
    • このやり取りを、要件でも設計でも実装でも、同じように繰り返す

2.4 4つのフェーズ ― 背景が途切れにくい開発

昔ながらの開発では、要件→設計→実装→レビューと進むたびに、「なぜこう決めたのか」という背景（コンテキスト）が、だんだん失われがちでした。

複雑な機能を作るとき、一つの会話（セッション）を長く続けすぎると、AIが覚えておく情報でいっぱいになり、だんだん性能が落ちていくことが知られています。こういうときは、会話の記憶を整理する（Clear や Compaction をする）のが良いとされています。ただ、何も考えずに記憶を消してしまうと、それまでの大事なやり取りまで一緒に消えてしまいます。すると、AIはまたコードをイチから調べ直して、背景を組み立て直すことになります。この調べ直しのためにトークン（AIの処理量の単位）が無駄に使われ、その分だけAI利用のコストもふくらんでいきます。

そこで、記憶を消したり整理したりする前に、それまでの情報をマークダウンの文書にまとめてから次の会話へ引き継ぐ。これが定番のやり方（ベストプラクティス）の一つです。

コアテクのグラフィックスチームで実践しているAI駆動開発では、4つのフェーズの間で、この背景情報をきちんと形にして次へ渡すようにしています。こうすることで、さきほどの「記憶が消えて、また調べ直し」という問題を軽くできます。

フェーズ	主にやること
Phase 1 Intent 起票（何を／なぜ）	intent.md を作る
Phase 2 Inception（どう作る）	plan.md を作る
Phase 3 Construction（実装）	コーディング＋PR
Phase 4 Review	チャットでのレビュー依頼／GitHub上でのAIどうしのクロスレビュー

AI駆動開発では、それぞれのフェーズの中に、さらに細かいステージがあります。ただし、すべてのフェーズ・ステージを必ず通るわけではありません。プロジェクトややりたいことに合わせて、AIが「今回はこの組み合わせでいきましょう」と提案してくれます。

フェーズからフェーズへの引き継ぎは、すべてマークダウンの文書で行います（その文書だけを読めば分かる、自己完結した形にします）。だから、フェーズが一つ終わるごとに /clear（会話の記憶をリセット）しても大丈夫です。

また、このマークダウンファイルはそのままドキュメントとして残るため、将来の仕様変更などが起きた際にも、AIは0から膨大なプロジェクトを調査する必要がなくなり、失われていた実装された理由/背景などを引き継いで作業を開始することができます。

3 AI駆動開発を支える「ハーネスエンジニアリング」

3.1 ハーネスエンジニアリングとは

ハーネス（harness） とは、AIエージェントのまわりに組む「足場」のことです。もともとは馬具や、安全帯（登山や高い所での作業で、落ちないように体を支えるベルト）を指す言葉で、ソフトウェアの世界では、テストを自動で動かす仕組み（テストハーネス）として使われてきました。AI駆動開発では、これを 「AIに自分で走ってもらいながら、落ちないように支える足場」 という意味に広げて使います。

なぜ足場が要るのでしょうか。あとの 1-2 / 1-3 節でも見るように、AIは「なんとなくそれっぽい」コードを確率的に書くので、コンパイルは通るし、動いてもいるのに、こっそり間違っているコードを作ってしまうことがあります。ここで足場を組まずに「AIにどんどん任せる」だけにすると、速いけれど品質が保証されない開発（Vibe Coding）に傾いてしまいます（→ 2.2 節）。ハーネスは、この「任せる度合い」を 「安全に任せられる度合い」へ変えるための仕組みです。

良いハーネスは、AIに次の3つを与えます。

役割	与えるもの	具体例
手	環境に働きかける手段	ビルド・テスト実行・エディタ操作を、AIから叩けるCLI／スキル
目	結果を確かめるフィードバック	テスト結果・スクリーンショット・静的解析・レビュー
柵	越えてはいけない境界	触ってはいけないファイル、承認が要る操作、コーディングのルール

さらに、フェーズをまたいでも背景が失われないように 背景を形にして次へ渡す仕組み（→ 2.4 節）も、広い意味でのハーネスに含まれます。

大事なのは、ハーネスは一度作って終わりではなく、少しずつ育てていく「エンジニアリングの対象」だということです。プロンプトのコツを個人でかかえこむのではなく、足場としてリポジトリに組み込む。そうすることで、AIの出力品質がチームでくり返し再現できるようになり、「誰がレビューするか」に左右されない品質基準ができあがります（→ 1.2 節）。この足場を作って育てていく活動を、ハーネスエンジニアリング と呼びます。次の節では、SIRIUS で実際に整えているハーネスを見ていきましょう。

3.2 SIRIUS のハーネス

SIRIUS のハーネスは、「AIに任せる範囲」と「人間が承認する境界」を、はっきり決めておくための仕組みの全体です。「プロセス」「Unity操作の自動化」「品質チェック」「レビュー連携」「ルール」という5つの層でできていて、これらがかみ合うことで、AIが自分から開発を回しつつ、品質は人間が守る という AI-DLC の理想を実現しています。

① プロセスハーネス ― AI-DLC の進行役

開発を、要件から実装・レビューまで、4フェーズの高速サイクルにまとめます（/ct-ai-dlc スキルが入口です）。

Phase	やること	成果物
1 Intent	何を／なぜ（Description・Context・Completion Criteria）	intent.md
2 Inception	どう作る（設計を出して選ぶ、UoW分解、コミット先決定）	plan.md
3 Construction	実装＋コンパイル＋品質チェック＋PR	コード／PR
4 Review	チャットでのレビュー依頼＋GitHub上でのAIどうしのクロスレビュー	―

• フェーズ間の引き継ぎは、すべてマークダウンで行います（docs/ai-dlc/<date>-<topic-slug>/ にたまっていきます）。各フェーズがその文書だけで完結するので、終わるごとに /clear しても背景を組み立て直せて、トークンの無駄づかいを防げます（→ 2.4 節）。
• Intent / Plan / PR のテンプレートが用意してあり、AIの出す答えの品質を安定させます。

② Unity操作ハーネス ― uloop

AIがUnity Editorを直接動かすためのCLIを、Claude Code のスキルとして整えたものです。あらかじめ起動して温まった状態（ウォーム）のEditorにつないで動きます。

種別	主なスキル	用途
コンパイル／テスト	uloop-compile / uloop-run-tests	エラー確認、EditMode / PlayMode のテスト実行
実行時の確認	uloop-control-play-mode / uloop-screenshot / uloop-simulate-keyboard / uloop-simulate-mouse-* / uloop-record・replay-input	Play Mode の操作・画面キャプチャ・入力の再現
状態しらべ	uloop-get-logs / uloop-get-hierarchy / uloop-find-game-objects / uloop-execute-dynamic-code	ログ・階層・GameObjectの調査、Scene / Prefab / AssetDatabase の操作

③ 品質ハーネス ― 3つの防衛線

AIのバグは クラッシュしないので、一見すると気づけません。だから、見つけられる範囲が違う3つの手段を使い分けて、品質を守ります（→ 1-3 節）。

防衛線	見つけられるもの	中身
コードレビュー（目で見る）	はっきりしたロジックのミス、精度の使い分け	人間＋AIのクロスレビュー
ビジュアルリグレッションテスト	ピクセル単位の変化（合成の式のズレなど）	AverageTest.cs（PlayMode）＋EditMode
モバイルGPUの静的解析	レジスタ数・サイクル数の増加	Mali Offline Compiler

PRをマージする前の必須チェック：macOS（iOS向け）と Windows（Android向け）の両方で、すべての AverageTest が成功していること。自動でチェックする仕組み（CI）がまだ無いので、AIが手動で全部実行します。しきい値ぎりぎりで結果が揺れる（flaky な）テストは「最初の1回＋やり直し2回＝最大3回まで試し、1回でも成功すればOK」とし、3回連続で失敗したものは、差分の画像を付けて人間の判断にゆだねます。

④ レビュー・協働ハーネス

• レビュー依頼をスキル化しておく ― GitHubのレビュアー設定と、チームのチャットへの依頼投稿をひとつの手順にまとめます（チームごとに連絡手段が違うので、このリポジトリには含めていません）
• PRの作成や、SiriusPackages/ の CLAUDE.md / SKILL.md ドキュメントの自動更新
• Codexによる自動レビュー → Claudeによる自動対応 → 人間が確認・承認 という、AIどうしのクロスレビュー連携

⑤ ルールハーネス（ガードレール）― CLAUDE.md

AIが自分で走るときに、「ここから先は踏んではいけない」という線をルールにしています。

• .meta はAIが生成・編集しない（GUIDの衝突を避けるため）／サブモジュールのポインタはコミットしない
• レビューの指摘をそのまま受け入れず、必ず実際のソースやコマンドで確かめる
• git 操作（commit / push / PR）は、ユーザーがはっきり許可したときだけ。許可がなければ、実装＋テスト通過まででいったん止まって報告する
• コミットメッセージは日本語で書き、git add はファイル名をはっきり指定する

---

4 AI 駆動グラフィックスプログラミング ワークショップ

ここからは、実際に手を動かすワークショップの説明です。

このリポジトリは、AI駆動開発（AI-DLC） を体験しながら、Unityのポストエフェクト（ブラー系のシェーダー）を題材にグラフィックスプログラミングを学ぶための、学生向け講義用ブランチです。

「AIにコードを書かせて、人間がレビュー・計測・テストで品質を守る」という新しい開発スタイルを、実際に自分の手を動かして体験していきます。

4.1 このワークショップのゴール

• AIが生成したコードは 「動く」けれど「正しい」とはかぎらない ことを、実際に体感する
• コードレビュー／ビジュアルリグレッションテスト／モバイルGPUの静的解析 という3つの防衛線を、使い分けられるようになる
• ブラー系のシェーダーを題材に、デグレ（見た目の劣化）とパフォーマンスの悪化を、自分の目と計測で見つけて直す 力を身につける

---

4.2 ワークショップ

1. 【ワーク①】Directional Blur の品質改善
2. 【ワーク②】Radial Blur の最適化
3. 【ワーク③】新機能の実装（RotationBlur）
4. 【ワーク④】陽炎（HeatDistortion）をゼロから実装

ワーク①〜③と、ワーク④では、進め方が違います。ワーク①〜③は、疑似的なフロー（/workshop-ai-dlc）で、わざと仕込んだ不具合を見つけて直す練習です。ワーク④は、私たちが日々の開発で使っているフロー（/ct-ai-dlc）で、要件の起票から実装まで、エフェクトを1本まるごと新規に作ります。こちらには仕込みの不具合はありません。AIが書いたコードが正しいかどうかを、あなた自身が確かめてください。

ワーク①〜③は、次の流れで進みます。

① AIに実装／改修をお願いする（プロンプトを投げる）
        ↓
② AIが「正しそうに見える」コードを作る（ここに不具合が仕込まれています）
        ↓
③ あなたがレビュー・実行・計測して、デグレやパフォーマンスの悪化を見つける
        ↓
④ 原因をつきとめて直し、答え合わせをする

各ワークの「答え」は docs/workshop/answers/ にあります。まずは自分で探してから、diff（差分）で確認してください。

---

4.3 【ワークー１】Directional Blur の品質改善（時間: 30分）

Directional Blur（方向ブラー） とは、指定した1方向にだけ画像を引きのばすようにブレンドするブラーのことです。スピード線やダッシュの表現などに使われます。

今の実装は、サンプリングを3回だけ行う、粗いブラーです。フラグメントシェーダーの真ん中の部分だけ抜き出すと、こうなっています。

[SiriusPackages\Sirius.PostProcessing\Runtime\Shaders\DirectionalBlur.shader]

// Blur
half4 blur_color = src_color;          // ① 元画像を1枚ぶん、最初に入れておく
for (int n = 0; n < 3; n++)            // ② 追加で3回サンプリングして足し込む
{
    const half displacement = DIRECTIONAL_BLUR_SAMPLING_OFFSET(n);
    blur_color += SAMPLE_TEXTURE2D(_BlitTexture, sampler_LinearClamp,
        IN.texcoord + displacement * _DirectionalBlurNormalizedDirection * _DirectionalBlurWidth * mask * fixed_aspect);
}

blur_color *= rcp(1 + 3);              // ③ 「元画像1枚 + サンプル3回」= 合計4枚で割って平均を出す

このワークでやることは、この「3回」のサンプリングを増やして、もっとなめらかで高品質なブラーにすることです。

🔍 レビューで注目してほしいポイント（ここが、あとで出てくるデグレ・パフォーマンス悪化のヒントになります）

• ③ の正規化 rcp(1 + 3) の 3 は、② のループ回数と同じ数 です。足した枚数で割らないと、平均になりません。ループ回数を増やしたとき、この割る数も一緒に変わっていますか？
• サンプリング回数を増やすほど、SAMPLE_TEXTURE2D（テクスチャの読み込み）も増えます。品質が上がるかわりに、GPUの負荷も上がります。 増やした回数は、そのコストに見合っていますか？

step-1 プロンプトを実行する

Claude Code に、次のプロンプトを投げて、AIに高品質化をお願いしてください。

/workshop-ai-dlc directional-blurを高品質化

このプロンプトを実行するとIntent->Plan->Constructionと進んで、AIがサンプリング数を増やした改修コードを作ります。Intentのフェーズではいくつかの技術的な判断を質問されます。

step-2 極端に明るくなっていないか確認/修正する

実装が終わって、動作確認を行うと、Strength=1.0, Width=0.5でブラーの部分が極端に明るくなってしまうデグレが発生しています。この原因を調査してください。

違いが分かりにくい場合はgit操作などでコードを元に戻して、再度4.3.3のプロンプトを実行して目で確認をしてみてください。

確認のヒント（詰まったら開く）

• 生成コードの正規化（rcp(...) の割る数）とループ回数が合っているか確認する

step-3 シェーダーの静的な性能テスト

今回のワークでは、テクスチャサンプル数を増やして、シェーダーの品質を上げているため、シェーダーの性能は当然悪化しています。 ただし、その悪化が想定範囲かどうかを確認することは重要です。想定外の悪化によって、レジスタスピルの発生、並列実行性の大幅な低下、ロードストアの大幅な増加などといった問題が起きる可能性があります。

そこで、今回はArm社が提供しているMali Offline Compilerを使って、シェーダーの静的な性能テストを行ってみます。

UnityのメニューバーからToos->Sirius->Dev Support->Shader Performance Analyzerを実行して次の図のツールを起動してください。

開くことができたら、解析を実行ボタンを押して、性能テストを実施してください。 今回は悪化が検出されるので、次の図のような結果になります。

(※)Mali Offline Compilerがインストールできていない場合は、入手ボタンからMali OCをダウンロードしてください。

---

4.4 【ワークー２】Radial Blur の最適化（時間: 30分）

Radial Blur（放射状ブラー） とは、見ている中心（画面の真ん中など）を基点に、放射状に画像を流すブラーのことです。集中線・爆発・加速感の演出に使われます。

今の実装は、すべての変数が float（32bit） で書かれています。どんな場面でも安全ではありますが、モバイルGPUでは half（16bit）にしたほうが、レジスタ・メモリ帯域・電池のもちをおさえられます。このワークでやることは、この float を half に置きかえる、モバイル向けの最適化 です。

真ん中の部分を抜き出すと、こうなっています（注目してほしい2行にコメントを付けています）。

[SiriusPackages\Sirius.PostProcessing\Runtime\Shaders\RadialBlur.shader]

// モバイル最適化前: すべての変数が float（ワークショップ演習の出発点）
uniform float _RadialBlurGazePositionX;
uniform float _RadialBlurGazePositionY;
uniform float _RadialBlurStrength;
// ...（中略）...

float4 frag (const Varyings IN) : SV_Target
{
    // ...（距離・方向の計算、6 回サンプリングして平均化）...

    // Composite
    const float blur_strength = max(1e-5, _RadialBlurStrength);
    const float t = SafePositivePow_float(normalized_distance, 0.5h) * blur_strength;  // ★A: pow(x, 0.5)=sqrt でフォールオフを描く
    return lerp(src_color, blur_color, saturate(t));                                    // ★B: saturate() で t を [0,1] に収める
}

🔍 レビューで注目してほしいポイント（ここが、あとで出てくるデグレ・パフォーマンス悪化のヒントになります）

• 最適化とは「見た目を変えずに軽くする」ことです。float → half は基本これに当てはまりますが、「ついでにここも軽くできそう」と削ってはいけない場所があります。
• ★A の SafePositivePow(x, 0.5)（＝平方根） は、中心から端に向かうブラーの効き方（フォールオフカーブ）を決めています。「pow は重いから、直線で近似しよう」とすると、カーブが変わって見た目も変わります（＝これは最適化ではなくデグレです）。sqrt(0.5) ≈ 0.707 と 0.5 は、どれくらい違うでしょうか？
• ★B の saturate(t) は、Strength が 1.0 をこえたときに t が 1.0 をこえて、lerp が 外挿（範囲の外まで計算してしまうこと） するのを防いでいます。「Strength は Volume 側で制限されている はず だから要らない」と思い込んで消すと、画面の端でハイライトが白飛びしたり、暗い部分が反転したりします。

step-1 プロンプトを実行する

/workshop-ai-dlc radial-blurを最適化

AIが half 化した最適化コードを作ります。作ったあと、見た目が「前」と変わっていないか をきびしくチェックし、Mali Offline Compiler で本当に軽くなったか を計測してください。

step-2 ビジュアルリグレッションテストを実施する

では、実施した最適化でデグレが起きていないか確認をしてください。 ビジュアルリグレッションテストは、UnityのメニューバーからToos->General->Test Runnerを選択して次のウィンドウを開いてください。

ウィンドウを開けたら、PlayModeを選択後、Workshop_RadialBlurを選択してRun Selectedを押してください。 すると、リグレッションテストに失敗して、デグレが起きていることが分かります。 この不具合の原因を調査して修正してください。

step-3 パフォーマンステストを実施する

最後にパフォーマンステストを実施します。性能が良化したかどうかはきちんと計測する必要があります。 Toos->Sirius->Dev Support->Shader Performance Analyzerから性能テストを実施してください。 性能が悪化している場合は、問題を修正してください。

---

4.5 【ワークー３】RotationBlurの新規実装（時間: 30分)

このワークでは、まだ存在しない RotationBlur（回転ブラー） を、AIと一緒にゼロから実装します。対象のシェーダーは、次のように「赤一色を返すだけの中身が空のもの（スタブ）」になっていて、ここに中身を作っていきます。

[SiriusPackages\Sirius.PostProcessing\Runtime\Shaders\RotationBlur.shader]

half4 frag(const Varyings IN) : SV_Target
{
    // ワークショップ演習 Part 2: RotationBlur
    // /workshop-ai-dlc rotation-blurを実装 を実行してここを実装してください
    return half4(1.0h, 0.0h, 0.0h, 1.0h);
}

RotationBlur（回転ブラー） とは、指定した中心点を軸にして、各ピクセルを 接線方向（円の接線＝回転していく方向） へブレンドするブラーのことです。カメラや被写体が回転しているような、うずまき・スピン感の演出に使います。

Sirius のポストエフェクトは、Volume（パラメータ）／ RenderPass（描画の制御）／ Shader（画像処理） の3つの層で作ります。RotationBlur も、同じ作りで実装します。

パラメータ（Volume）は、次のとおりです。

パラメータ	意味
Center X / Y	回転の中心点（UV座標 0〜1）
Strength	ブラーの強さ（距離をもとにしたブレンドの係数）
Width	ブラーの幅（接線方向のサンプリング距離のスケール）
Mask	効果をかける範囲（Rチャンネル）

シェーダーがやるべき処理は、大まかに次の流れです。

① 中心点から各ピクセルへ向かうベクトル d と、その距離 dist を求める
② d に垂直な「接線方向」のベクトルを作る  a
③ 接線方向にそって、複数回サンプリングして平均を出す
④ 中心からの距離に応じてブレンドする

🔍 仕様のポイント（ここが、あとで出てくるデグレ・パフォーマンス悪化のヒントになります）

1. 変位は「中心からの距離」に比例させます。 回転では、同じ角速度でも 中心から遠いピクセルほど、えがく弧が長く（＝大きく）動きます。自転車のホイールを思いうかべてください。外側のスポークほど速く動きますね。だから、接線方向のサンプリング量は、距離 dist に合わせてスケールする必要があります。 中心の近くと画面の端で、ブラーの強さが「同じ」に見えたら、距離によるスケールが抜けています。

2. 接線方向には、アスペクト比の補正が必要です。 UV空間（0〜1）は縦横で同じスケールですが、実際のピクセルでは、横長の画面ほど横方向がのびます。補正しないと、本来は正円であるはずの回転ブラーが、横長画面で楕円にゆがみます。

3. モバイル向けに half 精度で書きます。 UVの 0〜1 の範囲での計算なので、half で十分です。float のままだと、レジスタ・帯域・電池のもちで不利になります（ワーク②と同じ考え方です）。

4. ブレンドの係数は saturate でクランプします。 強さが大きいときに lerp が外挿しないよう、ブレンドの係数を [0,1] の中におさめます（ワーク②の ★B と同じ考え方です）。

step-1 プロンプト（このワークを始める）

/workshop-ai-dlc rotation-blurを実装

AIが Volume / RenderPass / Shader を作ります。途中で、中心点のあつかいや、精度、アスペクト比の補正 について、あなたの判断を求められます。

また、今回のワークでは、VolumeとRenderer Featureの設定が必要なのですが、この設定も、次のプロンプトを入力して、Claudeにさせてみましょう。

Workshop_RotationBlurシーンでRotationBlurを確認できるように、Volume、Renderer Featureの設定を行ってください。

UnityでRotationBlurを確認できるようになったら、上の「仕様のポイント」に照らして、見た目 が仕様どおりか検証してください。

step-2 ビジュアルリグレッションテストを実施する

今回の実装は新規実装なので、本来は正解となる画像データがないため、ビジュアルリグレッションテストを実施することはできないのですが、今回は正しい修正ができているかどうかの確認のために、正解画像を用意しています。
対応ができた人はToos->General->Test RunnerからRotationBlurのテストを実行してください。テストに失敗する場合は、不具合を修正してください。

確認のヒント（詰まったら開く）

• 画面の中心の近くと、画面の端（中心から遠い位置）で、ブラーの強さが変わっているか（同じに見えたら、距離スケールを疑う）
• 横長の画面（1920×1080）で、ブラーの形が 正円になっているか（楕円なら、アスペクト比の補正を疑う）

---

4.6 【ワーク④】陽炎をゼロから実装（時間: 50分）

ここからの2つのワークは、疑似体験となるAI-DLCではなく、コアテクのグラフィックスチームで実際に使われているAI-DLCのスキル（/ct-ai-dlc）で、Intent（何を・なぜ）→ Inception（どう作る）→ Construction（実装）と進め、エフェクトを1本まるごと新規に作ります。 実装後はPRの作成 -> Codexによる自動レビュー -> Claude Codeによるレビュー対応の検討といったAIによるクロスレビューまで体験してもらいます。

陽炎（HeatDistortion） は、熱せられた空気ごしに、遠くの景色がゆらいで見える現象です。夏のアスファルトや、たき火の向こう側を思い浮かべてください。ゲームでは、爆発・炎・砂漠・エンジンの排気といった熱の表現に使います。

作りはこれまでと同じ3層（Volume ／ RenderPass ／ Shader）ですが、今回は3Dテクスチャと深度値を利用して、ゆがみを発生させます。 このような技術的仕様はこれまでのシンプルなプロンプト/ct-ai-dlc 陽炎（HeatDistortion）を実装のような指示では決定することが難しいため、プロンプトで明確に指示を出すか、実装の計画自体をAI-DLCを利用して壁打ちして作っていく必要があります。 今回はプロンプトで具体的な指示を出していきます。

このワークでは最終的にPRを作成するため、始める前に以下の追加セットアップが必要です。

step-0 Fork と GitHub CLI のセットアップ

1. リポジトリをFork: GitHub上で本リポジトリ（CyberAgentGameEntertainment/GraphicsAcademyLight）を開き、右上の Fork ボタンからフォークを作成します。

2. Fork先を改めてクローン: ワーク①〜③で使っていたフォルダとは別の場所に、Fork先をクローンします（<your-github-username> は自分のGitHubアカウント名に置き換えてください）。

   git clone https://github.com/<your-github-username>/GraphicsAcademyLight.git
   cd GraphicsAcademyLight

3. GitHub CLI のインストールと認証: PRの作成やレビュー依頼、git push の認証に使います。インストール手順はWindows/Macで異なります。

   Windows

   winget install --id GitHub.cli

   Mac

   brew install gh

   インストール後、認証を行います（Windows/Mac共通）。

   gh auth login
   gh auth setup-git

step-1 プロンプト（このワークを始める）

/ct-ai-dlc 陽炎（HeatDistortion）をfeat/heatDistortionブランチに実装。歪みは3Dのノイズテクスチャと深度情報を元に実装します。ノイズテクスチャはプリセットとして3DCells64Sheetが用意されているので、これを利用してください。

AIがIntentの起票から付き合います。Description・Context・Completion Criteria を一緒に埋め、Inception で精度やマスクの設計を相談し、承認してから Construction で実装します。フェーズごとに /clear を挟んでも、docs/ai-dlc/ に残るMarkdownから続きを再開できます。

step-2 Phase 3の実装完了後

Phase 3の実装が完了すると次のように、動作を確認するための人間の残作業がAIから提示されます。 これらの指示について、不明な点があればAIに質問してすすめるのもよいですし、前節のように、シーンのセットアップなどを全てAIに行わせるのもOKです。 AIから提示された確認事項を進めて、コミット->PR作成まで進めてください。

step-3 AIによるクロスレビューの体験

作成されたPRには、次の図のようにCodexによるレビューとClaudeによるレビューの評価が追加されています。 これを確認して、最終的に人間による対応の決定を行ってください。 （※ 今回のPRはmainにマージはできません。）