YouTube で「AIに任せる前に知るUnity」を始めました（必ず実測する2分動画）

2026年10月23日から、YouTube でビデオブログ「AIに任せる前に知るUnity」を始めました。AI が普通に書いてくる C#/Unity のコードを1つ取り上げて、本当に問題があるのかを Unity で測り、2分ほどの動画にしています。

始めた理由

知っておくべきことが、AI でむしろ増えた

コードを AI に書かせるようになってから、自分で書く量は減りました。その代わり、AI が書いたコードが良いのか悪いのかを判断する 場面が増えています。

判断するには、ふだん書いているコードより一段上の知識がいります。GC がいつ起きるのか、その API は中で何をしているのか、といったことです。全部を覚えておく必要はありません。でも、AI が出したコードを見て「これは測ったほうがいい」と気づける程度には、理解しておく必要があります。

メモのままでは、記事にするには弱い

そういう知識は、これまで自分用のメモとして書きためてきました。ただ、ドキュメントを読んでまとめただけのメモは、技術ブログの記事にするには弱いです。同じ内容の記事はほかにもたくさんあります。

そこで、メモの内容を自分で測ってみて、その結果を動画にする ことにしました。「よく言われていること」が自分の環境で本当にそうなるのかを確かめれば、ほかには無い情報になります。2分の動画なら、記事を読むほどの時間がない人にも見てもらえるかもしれません。

自分の勉強を続けるため

もう1つは、自分の勉強のためです。2分の動画を毎日1本作ると決めれば、毎日1つ、無理なく調べて測ることになります。人に説明できる形にするので、知識も残りやすくなります。

どこまで続けられるか、見てもらえるかは分からないので、実験として始めています。

必ず実測する

このチャンネルで一番大事にしているのは、どの回も必ず実測する ことです。「こう書くと遅いと言われています」で終わらせず、2つの書き方を同じ条件で動かして、フレーム時間・GC Alloc・GC の回数を比べます。

測ると、よく言われていることと違う結果が出ることがあります。第1回がそうでした。

弾を毎回Instantiate→Destroyでいい？ 測って決めるオブジェクトプール【Unity #01】

弾を毎回 Instantiate して Destroy する版と、オブジェクトプールで使い回す版を、毎秒300発（弾がおよそ600個飛んでいる状態）で30秒ずつ測りました。

	毎回 Instantiate	オブジェクトプール
30秒間の GC 回数	3回	0回
平均フレーム時間	1.1ms	1.09ms
99パーセンタイル	2.4ms	2.4ms

GC はたしかに減りました。でも、フレーム時間はほとんど変わりません。この条件なら、「とりあえずプール化」よりも「プロファイラーで測ってから決める」のが正解です。測らなければ、「プール化は効く」という話で終わっていたと思います。

予想が外れたときは、その意外さを回の主題にします。どちらの結果が出ても、見る人が自分で判断するための材料になるからです。

1本の構成

1本は90〜150秒で、毎回この順番で進めます。

1. 症状：AI が普通に書いてくるコード
2. 実測：何が起きるか（2つの書き方を測った結果）
3. 名前：その対策や書き方の名前（調べるときの手がかりになる語彙）
4. 使わないほうがいい場面：対策にも向かない場面や注意点がある
5. Claude Code への頼み方：AI に直させるときの伝え方

最後を「頼み方」にしているのは、知識を覚えることより、AI に正しく頼めることのほうが今は役に立つと考えているからです。第1回なら「プロファイラーで確認した、と伝える」のがポイントでした。

作り方

動画は、ほぼコマンドだけで作れるようにしています。

• 計測：Unity 6.6 の計測用プロジェクトをコマンドラインからビルドし、条件ごとに1本ずつ実行します（同時に動かすと計測が乱れるため）。ProfilerRecorder でメインスレッドの時間と GC Alloc を毎フレーム記録し、JSON に書き出します
• 動画：Remotion（React で動画を作るライブラリ）で、台本・コード・計測結果のグラフを画面にします。計測の JSON をそのまま読み込むので、測り直せばグラフも変わります
• 読み上げ：VOICEVOX（四国めたん）。「Unity」「Claude Code」などの英字は、読み方の辞書で置き換えています
• 検査：台本と画面の行の対応、尺、読み・誤字・折り返しを書き出しの前に自動で確かめます。音量は -19 LUFS にそろえます
• 投稿：YouTube Data API で予約投稿しています。仕組みは「YouTube への動画アップロードを API で自動化する」に書きました

台本と計測コードは Claude Code と一緒に書いています。そのため、「AI が書きがちなコード」の例には困りません。

ブログ記事との分け方

動画を始めたので、このブログとの分け方も決めました。

• 知識だけの小ネタ：動画だけにする
• 大きい内容：記事と動画の両方で出して、お互いにリンクする
• 記事にするほど読まれなくてよいもの：動画に回す

たとえば「Unityメモ 〇〇NonAllocが用意されているもの」は記事にしてありますが、同じ GC の話である第1回の動画とリンクでつないでいます。

これからの予定

毎日19時に1本ずつ公開する予定で、11月23日の第32回までネタを決めてあります。どの回も、まず AI が書きがちなコードがあって、それを計算量（処理時間）と空間量（メモリ・GC Alloc）の2つの面から測ります。

• GetComponent を毎フレーム呼ぶ（第2回）
• 文字列を毎フレーム作る、ZString に替えたのに GC が減らない（第3・4回）
• Update で Find する、LINQ を使う、RaycastAll で配列を作る
• renderer.material で色を変える、イベントの購読を解除し忘れる
• 最終回：1か月分の「頼み方」を CLAUDE.md にまとめ、同じ指示で書かせたコードが変わるかを見る

公開済みの第2回はこちらです。

GetComponentを毎フレーム呼んでない？ 取り方5通りを計算量と空間量で比較【Unity #02】

※Unity Technologies の公式チャンネルではありません。