Posts on Wuyukwi's Notebook

FastAPI による軽量マイクロサービスと Webhook 自動化

Tue, 08 Sep 2026 17:05:00 +0900

個人用サーバーでタスク自動化や Webhook 連携を行うためのミニマムな設計手法について。

1GB の VPS に極小ブログと API サーバーを構築した記録

Tue, 08 Sep 2026 17:00:00 +0900

Oracle Cloud の 1GB メモリ VPS 上で、NapCatQQ を稼働させながら、常駐メモリほぼゼロの Hugo + PaperMod と FastAPI を共存させたミニマム構成の紹介。

☝️ 「汎用化したい」という衝動と、開発の現実

Mon, 18 May 2026 17:34:45 +0900

プログラマーを数年やっていると、おそらく全員が一度は同じことを考える。

最初はただ動けばよかったコードが、だんだん気持ち悪く見えてくる。
コピペも増える。責務も混ざる。依存も汚くなる。

すると自然に、

共通化したい
抽象化したい
再利用可能にしたい

という欲求が出てくる。

これは悪いことではない。むしろ健全だと思う。
“設計”を意識し始めた証拠だから。

ただ、この感覚はかなり危ない。

一歩間違えると、
簡単に「過剰設計」に転がり始める。

「将来使うかもしれない」

この一言が、
過剰設計の始まりになることはかなり多い。

今回は、自分がゲーム開発をやる中で感じた、

なぜ人は汎用化したくなるのか
なぜそれが失敗しやすいのか
実際どう考えるとちょうどいいのか

について書いてみる。

汎用化したくなるのは、実はかなり自然なこと

例えば、最初の頃のコードってかなり局所的になる。

if (isBoss)
{
hpBar.color = Color.red;
}

みたいな、「今必要だから書いたコード」が大量にある。

でも経験を積むと、
こういうコードを見るだけで“変更コスト”を想像するようになる。

「これ別のボス出たらどうするんだろう」
「色変えるたびに if 増えるの？」
「そもそも UI が敵情報知ってるのおかしくない？」

みたいなことを考え始める。

つまり汎用化欲求の正体って、単なる意識高い設計趣味ではなく、

“変更に弱いコードへの違和感”

なんだと思う。

だからある程度コードを書いた人ほど、自然と抽象化に向かう。

実際、汎用化にはかなり強いメリットがある

これは間違いない。

1. 「依存」に敏感になる

再利用を意識すると、まずベタ結合が気になり始める。

直接参照
Singleton ベタ依存
MonoBehaviour 神クラス
Inspector 配線地獄

みたいなものを避けたくなる。

結果として、

責務分離
Interface 化
データ駆動
疎結合

みたいな方向へ進む。

🧊 【Unity】10万オブジェクトを回転させたらどこがボトルネックになるのか（後編：ISystemで一桁msへ）

Wed, 01 Apr 2026 12:47:15 +0900

はじめに

前回は、Job System + Burst を使って
10万オブジェクトの回転処理（46ms → 3.5ms） まで最適化しました。

ただしその時点でも、フレーム全体としてはまだ重く、
ボトルネックはレンダリング側に残っていました。

なぜJob Systemだけでは不十分だったのか

前回の時点で回転処理自体はかなり軽くなっていましたが、
それでもフレーム全体としては大きな負荷が残っていました。

原因は、描画周りの処理です。

たとえロジック（Job）が高速でも、メインスレッド側では依然として
10万個の MeshRenderer を個別に処理する必要があります。

具体的には以下のような処理です：

Culling（可視判定）
Bounding Volume（バウンディング更新）
RenderQueue（描画順の整理）

これらがすべて「オブジェクト単位」で実行されるため、
結果として大きなCPU負荷になっていました。

この問題に対するアプローチが、Entities Graphicsです。

目標：
→ GameObjectベースのオブジェクトをEntityに変換する
仕組み：
→ 変換後は、これらの処理を Entities Graphics が内部的に管理し、
BatchRendererGroup を利用して描画処理をまとめて実行します。

その結果：

数万〜数十万単位のオブジェクトでも、
ごく少数のバッチとして扱えるようになります。

■ 結果

今回は DOTS（Entities + Entities Graphics）に移行した結果：

フレーム時間：約120ms → 約9ms
110FPS前後で安定

ほぼ別物レベルまで改善しています。

■ 比較

指標	改造前（GameObject）	改造後（Pure DOTS）	改善
Batches	~120,000	74	約1486倍削減
SetPass Calls	56	26	約2.1倍改善
Tris / Verts	不安定	安定	描画の一貫性向上
Frame Time	120ms（8FPS）	9ms（110FPS）	約13倍高速化

■ Profilerを見ると何が起きているか

Profilerを確認すると：

🧊 【Unity】10万オブジェクトを回転させたらどこがボトルネックになるのか（前編：LateUpdateとJob System）

Tue, 31 Mar 2026 17:31:45 +0900

最近、DOTS（Data-Oriented Tech Stack）が実際どのくらい効果があるのか気になっていたので、
簡単な検証を兼ねて触ってみることにしました。

せっかくなので「大量のオブジェクトを動かした場合にどこがボトルネックになるのか？」も含めて、
段階的に確認していこうと思います。

この記事ではまず、LateUpdateでの回転処理のボトルネックと、
Job Systemによる最適化の効果にフォーカスします。

レンダリング周り（CullingやDrawCall）については、次回以降で触れる予定です。

■ 検証環境

CPU：i7-12700K
GPU：RTX 3070
Unity：URPの新規プロジェクト
オブジェクト数：10万（Cube）

■ テスト内容

シンプルに「10万個のCubeを生成して回転させるだけ」です。

BoxColliderは削除
ランダム位置に配置

各オブジェクトにランダムな回転軸

void Start() { var root = new GameObject(“CubeRoot”).transform;

for (int i = 0; i < spawnCount; i++)
{
var go = Instantiate(prefab, Random.insideUnitSphere * 50f, Quaternion.identity, root);
transforms.Add(go.transform);
}

}

void LateUpdate() { float dt = Time.deltaTime;

for (int i = 0; i < transforms.Count; i++)
{
transforms[i].Rotate(rotationAxes[i], 100f * dt);
}

}

🙌 なぜ Unity は C# を選び、Unreal は選ばなかったのかについての個人の考察

Wed, 11 Mar 2026 19:31:51 +0900

はじめに

ゲームエンジンの言語の話になると、よくこんな対比が出てきます。

Unity は C#。
Unreal は C++ と Blueprint。

この違い、ただの好みではありません。
エンジンの設計思想そのものに関わっています。

C# が優れているとか、C++ が古いとか、そういう単純な話ではない。
両者はそもそも目指している開発体験が違うのです。

Unity が辿った言語統一の歴史

今でこそ「Unity といえば C#」という印象がありますが、最初からそうだったわけではありません。
初期の Unity では、開発者のバックグラウンドに合わせて複数の言語を選択できるのが特徴でした。

具体的には次の3つです。

C#
UnityScript （JavaScript 風の独自言語）
Boo （Python 風の言語）

当時の Unity は「スクリプト言語の自由度」を売りの一つにしており、Web 開発者は UnityScript、Python 系に慣れている人は Boo、という具合に選べるようになっていました。

しかし、この方針は長くは続きませんでした。

Unity 2017 頃から段階的に非推奨となり、
Unity 2019.1 を最後に UnityScript と Boo は完全に削除 されます。

結果として、Unity のスクリプト言語は C# のみ に統一されました。

参考
https://discussions.unity.com/t/which-release-removed-support-unityscript-and-boo/1624299

なぜこうなったのか。理由はいくつかあります。

まず、複数言語の維持コストです。
エンジン側はコンパイラ、ツールチェーン、デバッグ環境などをすべてサポートし続ける必要があります。

さらに重要なのは、UnityScript と Boo の実態です。
これらは見た目こそ別言語でしたが、内部では Mono 上で動作するスクリプトでした。

🎉 Git を「完全に理解」するためのデータ構造の話

Wed, 25 Feb 2026 17:25:36 +0900

はじめに

Git を使っていて、こんな感覚になったことはありませんか？

コマンドは打てるけど、何が起きているか分からない
merge と rebase の違いを、説明しろと言われると詰まる
conflict が出ると、なぜ衝突したのか理解できない

多くの Git 解説記事は、
「何を打つか」 は丁寧に教えてくれますが、
「なぜそうなるか」 までは踏み込んでくれません。

その結果、

という状態に陥りがちです。

この記事では、コマンドの説明はほぼ行いません。
代わりに、Git の内部構造をデータ構造として捉え直す ことで、

と腑に落ちる理解を目指します。

少しだけ グラフ理論 と ポインタの概念（C 言語） の素養があると、
かなりスムーズに理解できると思います。

Git の正体：木構造ではなく DAG（有向非巡回グラフ）

多くの人は、Git の履歴を「木構造」としてイメージしています。

しかし、これは正確ではありません。

Git の本質は有向非巡回グラフです。

Commit は「ノード」

すべての commit は、グラフ上の ノード です。

各 commit は、

ファイルのスナップショット
親 commit への参照（1 個または 2 個）

を持っています。

親が 2 個になる瞬間 = merge

通常の commit は親が 1 つですが、
merge commit は 親を 2 つ 持ちます。

☝️ デバッグ UI を書かずに Unity のデバッグ環境を成立させる設計と実装

Wed, 18 Feb 2026 13:18:23 +0900

はじめに

Unity で開発していると、
実行中にパラメータを触りながら挙動を確認したい
という場面は、ほぼ毎日のように出てきます。

最初のうちは、Unity 標準の仕組みを使って
簡単な Runtime Debug UI を用意すれば十分でした。

ただ、プロジェクトが進み、

デバッグ項目が増える
調整対象が増える
複数人で同時に触る

という状況になるにつれ、
「その場しのぎ」で作ったデバッグ UI が、確実に足を引っ張る
ようになってきます。

この段階で欲しくなったのが、

でした。

この記事では、
そのために設計した 自作 Runtime Debug システム について、
設計意図と実装の要点 を中心にまとめます。

何が問題だったのか

問題の本質は、「UI をどう実装するか」 ではありませんでした。

本当に困っていたのは、

Debug 項目の追加・削除が面倒
どこに何のデバッグ設定があるのか分からない
不要になった項目が整理されず、蓄積していく

という 運用面の破綻 です。

特に後半になると、

という、本末転倒な状態になりがちでした。

目指したゴール

今回の設計で目指したゴールは、かなり明確です。

UI を書かずに Debug 項目を追加できる
構造が自然に整理され続ける
無効化・除去が簡単
プロジェクト規模が大きくなっても破綻しない

つまり、

を最優先にしました。

全体構成

全体の流れは、次のようになります。

起動
↓
RuntimeInitializeOnLoadMethod
↓
DebugManager 自動生成
↓
DebugOption 自動登録
↓
Reflection による項目収集
↓
UI 自動生成 & バインディング

ここで重視したのは、

🧠 AndroidビルドでPlayFabのSecretKeyが丸見えだった話と、ビルド時に自動変換する対策

Thu, 05 Feb 2026 14:15:44 +0900

はじめに

PlayFab を使ったプロジェクトで、
TitleId や DeveloperSecretKey をどう管理するかは、最初に一度は悩むポイントだと思います。

自分も最初は深く考えずに、

const string TitleId = "XXXX";
const string DeveloperSecretKey = "YYYY";

のようにコードに直接書いていました。

ところが Android ビルド後に apk を確認してみると、
strings コマンドで 平文のままキーが抜ける ことに気づき、
「これはさすがにまずいな……」となったのが今回のきっかけです。

問題点：apk 内に平文で残る

C# のコードに直接書いた文字列は、

IL2CPP でも
難読化をしていても

最終的に 文字列リテラルとして apk 内に残ります 。

つまり、

strings app.apk

を叩くだけで、TitleId や SecretKey が見えてしまう状態でした。

もちろん「完全に隠す」ことは不可能ですが、
平文で置いておくのはリスクが高すぎる と判断しました。

方針：コードには平文を置かない

今回の方針はシンプルです。

ソースコード内に 平文のキーを一切書かない
ビルド時に Editor 側で変換・生成する
ランタイムでは最小限の復号処理だけ行う

いわゆる「秘匿」というより、
apk を覗かれたときに即バレしない状態を作る のが目的です。

実装概要

実装は以下の流れにしました。

Editor フォルダ内

🐈 UnityのEditor拡張で「設定の保存先」に毎回悩む話

Mon, 02 Feb 2026 17:57:13 +0900

Unity でエディタ拡張を書いていると、
「この設定、どこに保存するのが正解なんだろう？」
と悩む場面がよくあります。

そのときにまず候補に上がるのが EditorPrefs です。

bool isOpen = EditorPrefs.GetBool("MyTool_Foldout", false);

とても手軽で便利ですが、使い方を間違えると
チーム開発では地味に事故りやすい API でもあります。

この記事では、

EditorPrefs は何のための仕組みなのか
どんな用途に向いているのか
逆に使ってはいけないケース

を整理してみます。

EditorPrefs とは何か

EditorPrefs は、Unity エディタ専用の設定保存機構 です。

プロジェクト単位ではない
ユーザー（マシン）単位で保存される
バージョン管理の対象外

という特徴があります。

つまり、

を保存するためのものです。

保存場所はどこ？

EditorPrefs の中身は、OS ごとに以下の場所に保存されます。

Windows：レジストリ
macOS：~/Library/Preferences
Linux：~/.config

この時点で分かる通り、
Git にも SVN にも乗りません 。

向いているユースケース

1. エディタ UI の表示状態

例えば、

ツールウィンドウの開閉状態
折りたたみ（Foldout）の ON / OFF
最後に選択していたタブ

こういった「見た目の状態」は、EditorPrefs と非常に相性が良いです。

bool isOpen = EditorPrefs.GetBool("MyTool_Foldout", false);

😎 「リンクリストはもう使われない」のか？

Mon, 02 Feb 2026 15:20:02 +0900

――2026年のハードウェア前提で考えるデータ構造の現実

エンジニア向けの記事や SNS で、
「リンクリストはもう終わった」
という表現を見かけることがあります。

最初にこの話を聞いたとき、正直かなり極端だなと思いました。
ただ、実務でパフォーマンスを意識した設計や実装を重ねていくと、この言い方が完全に間違っているとも言い切れない 、という感覚になってきます。

この記事では、「リンクリストがなぜ避けられるようになったのか」「それでも今なお使われ続けている理由」を、現代の CPU・メモリ構成を前提に 整理してみます。

教科書的な理解と、現実のズレ

学生時代にデータ構造を学んだとき、ほとんどの人が次のように習ったはずです。

配列：途中への挿入・削除は O(N)
リンクリスト：挿入・削除は O(1)

理論としては正しいです。
ただし、ここには重要な前提条件 があります。

現実のハードウェアでは、これは成立しません。

キャッシュ階層という「無視できない現実」

現代の CPU では、メモリは階層構造になっています。

L1 キャッシュ：数サイクル
L2 キャッシュ：十数サイクル
L3 キャッシュ：数十サイクル
メインメモリ（RAM）：数百サイクル

この差は無視できるものではありません。
特に問題になるのが、アクセスパターンが予測できない場合 です。

リンクリストが不利になる理由

典型的なリンクリストは、ノードがメモリ上に散らばって配置されます。

Node A -> Node B -> Node C

見た目はシンプルですが、実際のアドレスは次のようになっているかもしれません。

0x1000 -> 0x8F20 -> 0x3A10

リンクリストを走査する場合、

現在のノードを読み込む
next ポインタを読む
次のアドレスが分かってから、次の読み込みを行う

という強い依存関係のある処理 になります。

CPU のプリフェッチ機構は、連続したアクセス（配列など）は得意ですが、
リンクリストのようなポインタ追跡はほとんど先読みできません。

結果として、キャッシュミスが頻発 します。

配列（vector）が速い本当の理由

std::vector や配列を順番に処理しているとき、
実際には CPU はすでに次のデータをキャッシュに読み込んでいます。

📃 UE5 における Gameplay Ability System ＆ Game Features を「いつ使うべきか」という個人的な考察

Wed, 21 Jan 2026 20:30:30 +0900

UE5 には Gameplay Ability System（GAS） や Game Features（GF） といった、拡張性と再利用性を強く意識した公式フレームワークが用意されています。

最近では Epic Games もこれらの利用を積極的に推奨しており、

と感じる方も少なくないと思います。

しかし、すべてのプロジェクト・すべての開発フェーズで導入すべきか というと、
個人的には 明確にそうではない と考えています。

この記事では

なぜプロジェクト初期で GAS / Game Features を導入すると負担になりやすいのか
どの段階で導入すると真価を発揮するのか

について、自身の経験をもとに整理します。

結論：GAS / Game Features は優秀だが「導入時期」が重要

まず前提として

GAS は長年運用され、大規模タイトルで実績のあるシステム
Game Features も 機能分離・モジュール化を重視した現代的な設計

であり、品質や思想そのものに問題があるわけではありません。

問題になるのは 「いつ導入するか」 です。

プロジェクト初期・プロトタイプ段階で起きやすい問題

① フレームワークが過剰に重い

GAS や Game Features は

高い汎用性
拡張を前提とした設計
長期運用への耐性

を重視しています。

その結果

クラス構造が複雑
Ability / Attribute / Effect / GameplayTag など前提概念が多い
正しく使い始めるまでの学習コストが高い

という特徴があります。

🦔 Overwatchにおけるネットコードと予測技術の解説

Fri, 21 Nov 2025 13:06:29 +0900

はじめに：高速対戦ゲームにおけるネットコードの本質

ゲームプレイ（GamePlay）エンジニアにとって、最重要テーマのひとつが ネット同期（netcode） です。
特に Overwatch のような高速リアルタイムアクションでは、「レスポンスの速さ（responsive）」 がゲーム性を決定づけます。

そのため、プレイヤーの操作は サーバーの応答を待たずに即時反映 する必要があります。
これを実現するのが 予測（prediction / pre-presentation） です。

ただし、クライアントを信頼できない（チート対策）というFPSの前提は20年変わっていません。
そのうえで「即時応答」と「サーバー権威」の両立を図るのがネットコード設計の核心になります。

即時応答が必要な操作

移動
スキル
武器（発射や装填などのスキル付き武器）
当たり判定（Hit Registration）

共通原則はただ一つ：
「プレイヤーがボタンを押したら即、見た目の挙動が起きること」

どれほど ping が高くても、遅延を感じさせてはならない。

しかし、予測を行う以上、避けられない問題があります──
それが 予測ミス（misprediction） です。

予測ミスは、
「クライアント側では成功したように見えた操作が、サーバー上では成立していない」
状態を指します。

Overwatch では、予測ミスが起きても「操作を遅延させる」のではなく、
できる限り予測ミスを減らす設計（＝確定性 Determinism） が採用されています。

予測ミスの例：サーバーとの食い違い

ping 250ms。
クライアントでは「ジャンプした」つもりでも、サーバー上では Mei の氷結を受けていた 。
その結果、クライアントは一度ジャンプの予測を行った後、サーバーからの正しい状態（氷結）で「強制的に巻き戻される」。

このように、超高速応答を目指すほど、予測ミスが発生しやすくなります。

▼ ここから：低ミス予測を支える「確定性（Determinism）」

以下では Overwatch が採用している ECS + Deterministic Simulation の要点を整理します。

1. 時間の量子化：Command Frame

確定的なシミュレーションは、

時間の同期
固定更新周期
値の量子化

🧠 モダンなフレームワークは「低レイヤの理解」から遠ざけるか？

Thu, 06 Nov 2025 12:43:17 +0900

〜意図（ビジネス要件）と低レイヤ知識の役割について考える〜

1. プログラミングの本質：意図をコンピュータに伝えること

プログラミングとは、人間の意図をコードという形でコンピュータに伝える行為 です。
言語やフレームワークはそのための「伝達チャンネル」にすぎません。
用途や目的が異なるからこそ、多様な言語やフレームワークが存在しています。

業務アプリ：可読性・保守性を重視
ゲームやリアルタイム処理：性能やレイテンシを重視
研究・プロトタイピング：表現力・試行錯誤のしやすさを重視

重要なのは「何を伝えたいのか（ビジネスの意図） 」であり、
低レイヤ（ハードウェアや OS の仕組み）はそれを実現するための手段にすぎません。

2. 抽象化は「ノイズ除去」の進化である

ソフトウェア開発の歴史を振り返ると、それは常に「ノイズを減らす」試みの連続でした。

アセンブリ言語：レジスタやメモリ操作のノイズを扱う
高級言語：ポインタ操作や手動メモリ管理のノイズを隠蔽
モダンフレームワーク：接続プールやリトライなど運用上のノイズを隠蔽

この観点から見ると、抽象化は「情報理論的に正しい方向への進化」です。
不要な実装詳細を隠すことで、開発者はより本質的な意図に集中できる ようになります。

3. それでも低レイヤ知識は不要にならない

抽象化が進んだからといって、低レイヤの知識が不要になるわけではありません。
実際には「抽象の漏れ（Leaky Abstraction）」や、フレームワークの誤用によって問題が生じることがあります。

そうしたときに求められるのは、下のレイヤを理解し、意図が正しく実現されているかを検証する力 です。
ただし、低レイヤの学習そのものが目的化してしまうと、肝心の「ビジネス意図の理解」が置き去りになります。

4. 最適化の本質は「情報の圧縮」である

最適化とは、突き詰めれば「情報の圧縮」です。
プログラムはビジネスの意図を機械命令に符号化したものとも言えます。
良い最適化とは、業務知識（確信）をもとに冗長性を取り除くこと によって成立します。

たとえば：

キャッシュ導入の根拠は「そのデータは一定期間変化しない」という業務知見
インデックス設計の根拠は「特定フィールドの検索頻度が高い」という利用傾向

つまり、最適化とは単なる技術的チューニングではなく、業務理解と技術の融合による意思決定 なのです。

5. 戦術的勤勉 vs 戦略的怠惰

低レイヤを極めること自体は悪いことではありません。
しかし、それが「業務理解を放棄する言い訳」になってしまっては本末転倒です。

戦術的勤勉：低レイヤを丹念に学ぶ（手段）
戦略的怠惰：業務要件の理解を怠る（目的の喪失）

まずは正しい問題設定──すなわち「ビジネスの意図」を明確にすること。
そのうえで、低レイヤの知識を活用して実装や最適化を行う。
この順序こそが、エンジニアリングにおける本質的なアプローチです。

6. 結論：抽象化の流れは正しい。ただし、バランスが鍵

モダンな抽象化は「意図に近づく」ための進化であり、退化ではない。
低レイヤ知識は「検証・トラブルシューティング・高性能化」のために必要だが、目的ではない。
成功するエンジニアは、**業務理解（何を伝えるか）と技術力（どう実現するか）**をバランスよく使い分ける。

🌟 C++11 が左辺値と右辺値を5分類に拡張した理由

Mon, 27 Oct 2025 14:31:00 +0900

はじめに

C++11 で「右辺値参照（rvalue reference）」が導入されたことで、C++ の値分類（value category）は大きく進化しました。
C++98 では「左辺値（lvalue）」と「右辺値（rvalue）」の二分法しかありませんでしたが、C++11 ではさらに細かく分類されます：

C++11で導入された新しい概念である
xvalue（期限切れ右辺値） と prvalue（純粋右辺値） が、
この章の中核的な進化ポイントです。

C++98 時代の「単純な世界」

C++98 の時代はとてもシンプルでした。

左辺値 (lvalue) ：代入の左側に置けるもの。永続的なアドレスを持つ。
例：a, *ptr, array[i]
右辺値 (rvalue) ：一時的な値。すぐに破棄される。
例：a + 5, 42, func()

ルールも直感的でした：

int a = 3;
&a; // OK 左辺値はアドレスが取れる
&(a + 5); // エラー！右辺値はアドレスが取れない

しかしこの単純さが、性能の壁 になっていました。

問題：無駄なコピーが多すぎる

std::vector<int> create_vector() {
std::vector<int> temp;
temp.push_back(1);
temp.push_back(2);
temp.push_back(3);
return temp; // ここで何が起こる？
}
std::vector<int> v = create_vector();

C++98 の仕様では return temp; で コピーが発生 します。
temp のヒープメモリをまるごと複製し、呼び出し側に返すのです。

💡 【Unity UGUI】Maskを使わずに実現する「穴あき」ハイライト演出

Mon, 20 Oct 2025 19:24:18 +0900

はじめに

UGUIで部分的にハイライトを当てたい場面、特にチュートリアル中の誘導UI では「特定のボタンだけを明るく見せ、他の部分を半透明で覆う」演出がよく使われます。
一般的には Mask や RectMask2D を利用しますが、これらにはいくつかの課題があります。

Mask ：Stencilバッファを使うため、描画コストが高い
RectMask2D ：矩形領域しか扱えず、穴あき表現（逆マスク） はできない

そこで今回は、MaskableGraphic を継承し、完全プログラム制御で「逆マスク（穴あきマスク）」を生成する方法 を紹介します。
最終的には、ハイライト部分がクリック可能で、他の部分はブロックされる 、高性能な HollowOutMask コンポーネントを実装していきます。

目標仕様

機能	説明
視覚効果	自身の `RectTransform` 領域内に半透明のマスクを描画し、指定の `RectTransform` 部分を「くり抜く」
射線処理	穴の部分はクリックが通過し、マスク部分はクリックをブロック
動的追従	対象オブジェクトが動いたりスケールが変化しても、くり抜き領域が追従

これを、Mask 系コンポーネントを使わずに、頂点操作 だけで実現します。

実装の基本構造

HollowOutMask は MaskableGraphic を継承し、OnPopulateMesh() をオーバーライドします。

頂点生成の考え方

想像してみてください。
マスク全体を表す「外側の矩形（Outer Rect）」と、くり抜く「内側の矩形（Inner Rect）」があるとします。

この２つの矩形を組み合わせ、外側を塗りつつ内側を抜くには、8つの頂点 と8枚の三角形 が必要です。

コード例：OnPopulateMesh()

protected override void OnPopulateMesh(VertexHelper vh)
{
vh.Clear();
if (_isTargetNull)
{
base.OnPopulateMesh(vh);
return;
}
// Outer Rect（自身のRectTransform基準）
float outerLx = rectTransform.rect.xMin;
float outerBy = rectTransform.rect.yMin;
float outerRx = rectTransform.rect.xMax;
float outerTy = rectTransform.rect.yMax;
vh.AddVert(new Vector3(outerLx, outerTy), color, Vector2.zero);
vh.AddVert(new Vector3(outerRx, outerTy), color, Vector2.zero);
vh.AddVert(new Vector3(outerRx, outerBy), color, Vector2.zero);
vh.AddVert(new Vector3(outerLx, outerBy), color, Vector2.zero);
// Inner Rect（穴部分）
float innerLx = _targetMin.x;
float innerBy = _targetMin.y;
float innerRx = _targetMax.x;
float innerTy = _targetMax.y;
vh.AddVert(new Vector3(innerLx, innerTy), color, Vector2.zero);
vh.AddVert(new Vector3(innerRx, innerTy), color, Vector2.zero);
vh.AddVert(new Vector3(innerRx, innerBy), color, Vector2.zero);
vh.AddVert(new Vector3(innerLx, innerBy), color, Vector2.zero);
// Triangles（外側と内側の間を埋める）
vh.AddTriangle(0, 1, 5); vh.AddTriangle(5, 4, 0);
vh.AddTriangle(1, 2, 6); vh.AddTriangle(6, 5, 1);
vh.AddTriangle(2, 3, 7); vh.AddTriangle(7, 6, 2);
vh.AddTriangle(3, 0, 4); vh.AddTriangle(4, 7, 3);
}

これで、中央が透明な「リング状ポリゴン を生成できます。

📚 UI開発を10倍速くするための実戦ポイント

Thu, 09 Oct 2025 12:11:28 +0900

はじめに

多くの人は「UI開発＝手の速さ」だと思っています。
でも実際のプロジェクトでは、進行を遅らせる原因はコードの速さではなく、データフローとUI構造設計の悪さ です。

Unity（UGUI）で時間を食う典型的なポイントを挙げると、以下のようになります。

データ前処理がバラバラ ：ソートやフィルタが各UIに散らばっていると、UI層が処理待ちになる。
階層構造が深すぎる ：1回の更新で大量のTransformを走査、処理も重くバグも出やすい。
アニメーション・状態管理が未抽象化 ：新しい状態を追加するたびにコードを壊す。

同じランキングUIでも、ある人は半日で完成、ある人は3日かかる。
その差は、手の速さではなく設計の差 です。

データ層とUI層を明確に分離する

ありがちなアンチパターンは、OnClick() の中で
データ取得 → オブジェクト生成 → UI更新を全部やるケース。

短期的には動いても、UI改修のたびに全部作り直しになります。

もっと良い設計はこうです👇

DataService / Manager にデータロジックをまとめる
UI は DTO（Data Transfer Object） を受け取って表示専念
データ前処理は Python や外部ツールで事前に済ませる

こうすると要件変更が来ても、UI側はほとんど触らずに済みます。
データ層が変わってもUIは安定、これが真の開発効率化です。

リスト描画は「オブジェクトプール」が必須

ランキング、インベントリ、スキルリストなど、
毎回 Instantiate ＋ Destroy していると、
処理が重くなるだけでなく、開発時間も無駄に増えます。

対策：

オブジェクトプールを構築する ：
再利用可能なUI要素をキャッシュして、再描画時はデータだけ差し替え。
シンプルな PoolManager でOK ：
使い終わった要素は SetActive(false) して再利用。
ScrollRect の仮想化レンダリングと併用 ：
数千件でも軽く動作。

あるプロジェクトでは、インベントリUIの描画時間が
500セルで200ms → プール導入後は30msに短縮。
体感で「カクつき」が消えました。

💡 C++ の「奇妙な再帰テンプレートパターン（CRTP）」を理解する

Tue, 30 Sep 2025 12:36:20 +0900

はじめに

C++ のテンプレートには数多くの応用テクニックがありますが、その中でも「CRTP（Curiously Recurring Template Pattern：奇妙な再帰テンプレートパターン） 」は特にユニークで強力な手法です。
Boost をはじめとする有名ライブラリでも多用されており、C++ の表現力を大きく広げてくれます。

この記事では、CRTP の基本から実用例、さらには応用パターンまでを整理して解説します。

CRTP とは？

CRTP の基本形は以下のようになります。

template <typename T>
class Base {
public:
T& getDerived() { return static_cast<T&>(*this); }
};
class Derived : public Base<Derived> {
// Derived 自身を Base のテンプレート引数として渡す
};

一見すると「派生クラス Derived が、まだ完成していない自分自身を基底クラス Base に渡している」ように見えます。この“自己参照”こそが CRTP の特徴です。
コンパイラはこれを問題なく処理でき、基底クラスはコンパイル時に派生クラスの型情報を知ることができます。

実用例：比較演算子の自動生成

C++ では == や < などの比較演算子を定義するのはよくある作業ですが、すべてを個別に書くと冗長になりがちです。
CRTP を用いると、基底クラスに「共通の比較演算子」をまとめ、派生クラスは最小限の実装だけで済ませられます。

基底クラス

template <typename Derived>
class Comparable {
public:
bool operator==(const Derived& other) const {
return static_cast<const Derived*>(this)->equalsImpl(other);
}
bool operator!=(const Derived& other) const {
return !(*this == other);
}
bool operator<(const Derived& other) const {
return static_cast<const Derived*>(this)->lessImpl(other);
}
bool operator>(const Derived& other) const { return other < *this; }
bool operator<=(const Derived& other) const { return !(*this > other); }
bool operator>=(const Derived& other) const { return !(*this < other); }
};

派生クラス例

class Point : public Comparable<Point> {
public:
Point(int x_val, int y_val) : x(x_val), y(y_val) {}
bool equalsImpl(const Point& other) const {
return x == other.x && y == other.y;
}
bool lessImpl(const Point& other) const {
return (x != other.x) ? (x < other.x) : (y < other.y);
}
private:
int x, y;
};

これで ==, !=, <, >, <=, >= がすべて利用可能になります。

🔥 ゲームプログラマーとして成長するために大切な3つの力

Thu, 18 Sep 2025 16:43:12 +0900

はじめに

「どうすればプログラミングが上手くなるのか？」
これは、ゲーム業界を目指すエンジニアにとって、常につきまとうテーマです。

Unity や Unreal Engine などの便利なエンジンやライブラリが整っている時代でも、「本当にゲームを作れる」プログラマーになるためには、言語やフレームワークの知識以上に重要な根本的スキル があります。

本記事では、ゲームプログラマーとして実務を経験する中で特に大事だと感じる3つの力 を紹介します。

① 抽象化の力 —— 巨大なコードを「分けて」考える

ゲーム開発は、数千〜数百万行にもなるコードの集合です。
その全てを頭に入れることは不可能なので、必要な部分だけをブラックボックスとして扱う 考え方が必須になります。

例えば、「プレイヤーが持つ全ての武器を取得する」処理を作る場合を考えます。

// Repositoryパターンによる例
class WeaponRepository {
public List<Weapon> GetAllWeapons(PlayerId playerId);
}

この WeaponRepository クラスを作るときは、

DBやセーブデータへのアクセス
ログやエラーハンドリング
フォーマット変換
など、たくさんの下位レイヤのライブラリを呼び出しますが、上のレイヤからは「GetAllWeapons」だけ見えればよい のです。

これが抽象化であり、モジュールを積み重ねて大規模ゲームを成立させる基本 です。

実戦ポイント

オブジェクト指向（OOP）、関数型（FP）、手続き型といった 複数のパラダイムを状況に応じて使い分ける
トップダウン（設計から実装）とボトムアップ（共通処理の抽出）を行き来しながら開発する
抽象化しすぎると開発が重くなり、抽象化しなさすぎるとコピペ地獄になるため、バランスを取る

② デバッグの力 —— ブラックボックスを「開ける」技術

抽象化したコードは便利ですが、バグが起きたときには中を開ける必要 があります。

たとえば「インベントリ画面に武器一覧が表示されない」と報告されたとき、どこから原因を追うべきでしょうか？

F12（DevTools）や curl でクライアント→サーバ間通信を確認
サーバで WeaponRepository.GetAllWeapons() の戻り値をログ出力
DBにクエリを直打ちして期待通りの結果か確認

こうして層を一つずつ下って調査 するのがデバッグの基本です。
このスキルはバグ修正だけでなく、新しいプロジェクトやチームに参加したときにコードを理解する力 にもなります。

実戦ポイント

ログやアサートを常に入れておく
デバッガでステップ実行できるように設計する
バグ報告を「再現可能な条件」に落とし込む

😯 C++で高性能計算を書くときに意識すべき最適化ポイントまとめ

Mon, 04 Aug 2025 20:10:19 +0900

はじめに

本記事では、私自身が経験したことや、信頼できる実践的な知見を元に、C++で高速な数値処理や行列演算を行う際に意識すべき最適化ポイント をわかりやすく整理しました。
HPCやリアルタイム演算に関心のある方に参考になれば幸いです。

1. メモリのアライメントとキャッシュ効率

アライメント（`attribute((aligned(n))`）

CPUはキャッシュライン（通常64バイト）単位 でメモリを読み込む。
メモリが正しく整列されていないと、キャッシュミスやfalse sharing が発生し、性能が大幅に低下。
GCC/Clangなら __attribute__((aligned(32))) など、MSVCでは __declspec(align(32)) を使う。

連続したメモリを使用する（`std::vector<T>`など）

行列は行優先(row-major)の順番で連続配置することで、CPUの事前読み込み(prefetch)が効きやすくなる。
std::vector<std::vector<float>> のような非連続構造は避ける。

2. メモリ確保の最適化：高速メモリアロケータ

標準の malloc や new は汎用的で安全ですが、性能面ではボトルネックになることがあります。

3. 行列演算の高速化手法

Strassenアルゴリズム（O(n^2.81)）

通常のO(n³)よりも理論上速い。
再帰的に分割しながら計算することで、掛け算回数を削減。

ブロック分割（Block-based Multiplication）

大きな行列を小さなサブブロックに分けて計算 すると、キャッシュが有効活用できる。
代表的なライブラリ（後述するBLASなど）ではこの最適化が組み込まれている。

4. 並列計算（マルチスレッド化）

C++11の標準スレッド

std::thread, std::async を使って並列化可能。
シンプルな制御だが、スレッド数の管理や同期は自前で対応が必要。

OpenMP

#pragma omp parallel for のように、簡潔にfor文を並列化。
コンパイラ依存（GCC/Clang/MSVC全て対応）。

Intel TBB（Thread Building Blocks）

動的なタスクスケジューリング・負荷分散・ワークスティーリングが可能。
不規則な処理を高速並列化したいときに強力。

💡 C++ の emplace_back は push_back を完全に置き換えられるか？

Tue, 24 Jun 2025 12:40:20 +0900

はじめに

C++11 から導入された emplace_back は、コンテナに要素をその場で構築できる便利なメソッドです。
一方、それ以前から使われてきた push_back とはどんな違いがあり、emplace_back は完全に push_back を代替できるのでしょうか？

本記事では、

emplace_back が本当に push_back より常に速いのか
両者がどんなケースに使えるのか
実装の違いと注意点

について、自分なりに整理した考えをまとめます。

`push_back` と `emplace_back` の違い

`push_back`

// C++20以降
constexpr void push_back(const T& value); // コピー
constexpr void push_back(T&& value); // ムーブ

push_back は、すでに生成されたオブジェクトをコピーまたはムーブして格納する関数です。

`emplace_back`

// C++20以降
template<class... Args>
constexpr reference emplace_back(Args&&... args); // その場で構築

emplace_back は、コンストラクタに渡す引数をそのまま受け取り、コンテナ内部で直接オブジェクトを構築します。そのため、中間オブジェクトなし に要素を追加できる点が特徴です。

これらの大きな違いは、push_backが既に生成されたオブジェクト（T型）をコピーまたはムーブする一方で、emplace_backは任意のコンストラクタ引数からその場でT型のインスタンスを構築できる点です。

LLVMにおける内部実装

以下はLLVM(libc++)におけるpush_back内部の実装です。

if (this->__end_ != this->__end_cap()) {
__construct_one_at_end(__x); // 残り容量がある場合、__xをコピーまたはムーブ構築
} else {
__push_back_slow_path(__x); // 足りない場合、新規領域を確保して再配置
}

__construct_one_at_end の中では、allocatorが提供する construct() を使って、指定されたメモリにオブジェクトを構築しています。
また、allocatorが construct() を持たない場合には単純に in-place new を呼び出す仕組みです。

🎉 std::function がヒープメモリを確保する条件とは？— コピーキャプチャされた変数の型がカギ

Thu, 05 Jun 2025 13:03:20 +0900

はじめに

C++ の std::function は「小さいオブジェクトならヒープ確保しない（Small Object Optimization, SOO）」という知識は一般的です。しかし、以下のようなコードでは意外な挙動が観察されます：

struct A {
int value;
A(int v) : value(v) {}
A(const A &other) : value(other.value) {}
};
struct B {
int value;
B(int v) : value(v) {}
};
A a{0};
B b{0};
std::function<void()> funcA = [a] {}; // ヒープ確保あり
std::function<void()> funcB = [b] {}; // ヒープ確保なし

このように、コピーコンストラクタの有無だけ で挙動が変わるのはなぜでしょうか？

`std::function` がローカル格納を行う条件（GCC/libstdc++ 編）

libstdc++ の実装（GCC 標準ライブラリ）では、以下の条件を満たすとオブジェクトはヒープではなくローカルに保存されます：

static const bool __stored_locally =
(__is_location_invariant<_Functor>::value &&
sizeof(_Functor) <= _M_max_size &&
__alignof__(_Functor) <= _M_max_align &&
(_M_max_align % __alignof__(_Functor) == 0));

この中で特に重要なのが：

💨 Fusionの[Networked]属性はどう動いている？IL変換と自動同期の仕組みを解剖する

Wed, 04 Jun 2025 19:50:30 +0900

はじめに

Photon Fusionは、高性能・高柔軟性なネットワーク同期システムを提供する次世代ネットワークライブラリです。
その中でも特に重要な役割を担っているのが、[Networked] 属性です。

この属性を使うことで、プレイヤーの位置やアニメーション状態、ゲーム内オブジェクトの変化 などを自動的に同期でき、煩雑な手動のデータ送受信処理を省くことができます。

本シリーズでは、Fusionの内部同期処理を段階的に掘り下げて解説していきますが、今回は、[Networked] 属性の裏側で何が起きているのか、どのようにして自動同期が実現されているのかを詳しく見ていきます。

Fusionにおける[Networked]属性の同期処理概要

`[Networked]` 属性は？

Fusionでは、[Networked] 属性が付与されたプロパティはネットワーク状態の同期対象 として扱われますが、ユーザーが手動で同期コードを書く必要はありません。
この仕組みは、Unityが提供する ILPostProcessor API を活用しており、C# で書かれたコードをビルド後にIL（中間言語）レベルで自動変換 しています。

ILは、.NET における中間言語です。
Unity では、C# で書いたスクリプトは必ずこの IL を経由してからネイティブコードに変換されます。

具体的には、以下のような処理が行われます：

NetworkedWeaved という属性を追加して、該当プロパティがネットワーク状態バッファに割り当てられることを明示
getter/setter が NetworkBehaviour の内部バッファ（StateBuffer）へのメモリアクセスに差し替え られる
実行時に Spawned() されていない場合のアクセス制限も挿入される

変換前のC#コード：

 [Networked] private Vector2 _position { get; set; }

IL変換後（ILSpyで逆コンパイルしたコード）：

    [Networked]
    [NetworkedWeaved(0, 2)]
    private unsafe Vector2 _position
    {
        get
        {
            if (base.Ptr == null)
            {
                throw new InvalidOperationException("Error when accessing PhotonCapybara._position. Networked properties can only be accessed when Spawned() has been called.");
            }
            return (Vector2)base.Ptr[0];
        }
        set
        {
            if (base.Ptr == null)
            {
                throw new InvalidOperationException("Error when accessing PhotonCapybara._position. Networked properties can only be accessed when Spawned() has been called.");
            }
            Unsafe.Write(base.Ptr + 0, value);
        }
    }

補足解説：

base.Ptr は NetworkBehaviour に割り当てられたネットワーク状態メモリの先頭ポインタ です。