10 人の視点で点検する：2026 年 10 月の Turian

10 人のペルソナ：Turian は誰のためのものかでは、Turian が想定する 10 人と、それぞれが大切にすること、嫌うことを紹介しました。この記事はその続編です。現状を率直に点検します。

以下では、それぞれについて、今日の Turian が提供できること、まだ足りないこと、そして実際に支持を得られていると判断するための成功指標を一つ挙げます。基準は、最初の記事と同じ「大切にすること」と「嫌うこと」です。存在する機能と計画中のものは分け、大切な要望に半分しか応えられていない場合は、そう書きます。すべて完成したかのような機能一覧は、誰の役にも立ちません。

これは 2026 年 10 月時点の分析です。このページと現実が食い違うなら、正しいのは現実です。次の分析でこの記事を置き換えます。

Ana

趣味でゲームを作る高校生

P·S·I·J：試作型（Prototyper）、購入活用型（Shopper）、統合型（Integrator）、実務型（Journeyman）。

今日の Turian でできること

Turian Studio は、初期シーン付きのプロジェクトを作成できます。Play（F5）で Studio 内から実行できます。停止すると実行用コピーを破棄するため、試して失敗しても編集中のシーンは壊れません。
サイトには初心者向けに書いたマニュアルが 4 言語であり、Studio 自体も同じ仕組みでローカライズしています。
アセットストアには、いくつかの brick が並んでいます。カメラコントローラー（Free Fly、FPS、Orbit、Follow）とゲーム内 UI は、作り直さずにインストールできます。
入力の actions。操作を生のキーではなく、名前付きのアクションとして扱えます。
バリアントによる Mod 制作。プレハブやデータアセットのバリアントは、元のアセットと上書きした値から成り、元が変更されても追従します。

まだ足りないこと

手順を追って学べるチュートリアル。まだありません。マニュアルはリファレンスであり、初心者にはゼロから最初のゲームまで導く道筋が必要です。
ストアで選んで購入・ダウンロードできる、サードパーティーのアセット。
2D の制作機能。初心者が最初に選ぶのは 2D ですが、今日の Turian は 3D エディターです。
分野ごとに焦点を絞った、完成度の高いサンプルプロジェクト。開いて編集し、そのまま実行でき、README と必要なエンジンバージョンが明記されたものです。
アセットストアで入手できるプロジェクトテンプレートと、ひと通りそろった制作キット。

**成功指標：**初めての利用で、実行・エクスポートできるものを作って終えられた割合。

Benjamin

コード中心の個人インディー開発者

C·P·A·J：完成重視型（Closer）、純粋主義型（Purist）、設計型（Architect）、実務型（Journeyman）。

今日の Turian でできること

turian-cli は Studio と同じコンパイラー、インポーター、エクスポーター、レンダラーを実行します。コマンドは new、compile、export、play、scene、screenshot、playmode、pick です。失敗時は終了コードが 0 以外になるため、スクリプトから信頼して使えます。
プロジェクトは普通のファイルを収めたフォルダーです。スクリプトは通常の C# で、データとして保存するアセンブリ定義の下に置きます。パッケージは Bricks/manifest.json に宣言するため、エディターを開く必要はありません。
GPU のないマシンでも、ヘッドレスで avif にレンダリングできます。turian-cli ui ならシーンなしで UI ドキュメントを描画できます。
エンジンのライセンスは MPL 2.0 で、ソースを読めます。実装を信じるだけでなく、自分で調べられます。
Graph や Guinevere など、エンジンの外にあり、エンジンなしでも使える再利用可能なライブラリー。それぞれ固有の名前とリリースを持ちます。
一時停止と単一ステップ実行に対応した、設定可能な固定 tick のシミュレーションとコマンドリプレイ。ヘッドレスのテストからゲームを 1 tick ずつ進められます。

まだ足りないこと

エンジンと属性の NuGet パッケージ。通常の C# プロジェクトから、Studio をインストールせずに Turian を参照できるようにする必要があります。
一度もエディターを開かずにビルド・実行できる、コードだけのサンプルプロジェクト。
コードだけで扱えるデータアセット。エディターを介さず、通常の C# から作成、読み込み、利用できることです。
プロファイラー。まだありません。

**成功指標：**一度もエディターを開かないプロジェクトの割合。

Carlos

ジャムから生まれた小さなスタジオの一員

I·W·I·C：反復型（Iterator）、世界構築型（Worldbuilder）、統合型（Integrator）、指揮型（Conductor）。

今日の Turian でできること

Studio 内で、開いているシーンのコピーを Play、Pause、Step Frame（F5、F6、F10）で実行できます。スクリプトのコンパイルに失敗しても、最後に動作したビルドを読み込んだままにするため、タイプミスで作業が中断しません。
brick はプラグインシステムでもあり、アセットストアから入手できます。ジャムで必要な機能を、自作せずにインストールできます。
Studio での複数オブジェクト編集。複数選択して共通のフィールドを一度編集し、一括変更を一回の Undo で戻せます。
ジャムの途中で役立つキャッシュ。プロジェクトを開き直したとき、変更がなければインポート済みファイルとコンパイル済みコードを再利用します。File → New Scene では、実験用の使い捨てシーンを開けます。

まだ足りないこと

Fernando が使うデータアセットを土台に、デザイナーがゲームの実行中に値やリスナーを変更すること。部品はありますが（Fernando の項を参照）、ライブ編集のサイクルはまだありません。
Play Mode 中に変更した値を残すこと。現在は停止すると必ず実行用コピーを破棄し、そこで調整した値もすべて失われます。

**成功指標：**稼働中のプロジェクトにおける、編集からプレイまでの所要時間の中央値。

Daniela

ゲームアーティスト

A·P·I·J：錬金術型（Alchemist）、純粋主義型（Purist）、統合型（Integrator）、実務型（Journeyman）。

今日の Turian でできること

モデル用の FBX・OBJ インポートプラグイン。
Studio のドッキング可能なレイアウト。自分で整えた作業スペースを維持できます。
Studio の Scene・Game ビュー、ヘッドレスのスクリーンショット、エクスポートしたゲームを、一つのレンダラーで描画します。マテリアルは PBR の metallic-roughness 方式です。Daniela が見ているものが、そのまま製品になります。
インスタンス化した各モデルに、バッチを分割せずに色のティントと四つのカスタム値を持たせられます。
プレハブとプレハブバリアントに加え、アセットブラウザー、Undo、Redo が、キットの一貫性を保ちます。

まだ足りないこと

カーブ編集とタイムラインを備えたアニメーションシステム。
2D スプライト。Turian は 3D を描画しますが、2D の制作フローはまだありません。
パーティクル。
オーディオシステムもまだありません。
影、イメージベースライティング、スカイボックス、ポストプロセス、プロジェクトのコードから追加するカスタム描画パス。その後に、ノードベースのシェーダーエディター。

**成功指標：**制作ツールとの往復後に手直しが不要だったアセットインポートの割合。

Eduardo

レベルデザイナー

I·W·C·J：反復型（Iterator）、世界構築型（Worldbuilder）、選定型（Curator）、実務型（Journeyman）。

今日の Turian でできること

Bepu による物理を標準で使えます。
失敗しても編集中のシーンには触れません。Play Mode はコピーを実行し、停止時に破棄します。プレハブ、バリアント、アセットブラウザー、Undo、Redo により、要素の多いシーンでも一貫性を保てます。
GPU インスタンシングは、同じメッシュとマテリアルが連続する範囲を一つの描画にまとめます。テストシーンでは、同じ小道具 10,000 個の描画が 8,791 ドローコールから 1 回になり、ピクセルは同一でした。視錐台カリングで、カメラから見えないものは描画を省きます。
タグと独立したレイヤー分類、表示と選択のロック、矩形選択、回転ギズモ、向きの操作部品。要素の多いシーンで作業するための、小さな道具がそろっています。

まだ足りないこと

パーティクル。パーティクルシステムはまだありません。
トゥイーンとアニメーションタイムライン。Turian にはまだアニメーションシステムがありません。
ポストプロセス。
ファイルマネージャーから、モデルファイルをシーンへ直接ドラッグ＆ドロップすること。
ワールドグリッドだけでなく、ほかのモデルにも合わせられるスナップ。
オブジェクトの散布や地形などのワールド制作ツール。アニメーションと描画の不足を埋めた後に取り組みます。

**成功指標：**コードファイルを一度も開かない利用者の、クラッシュなしで終えたセッションの割合。

Fernando

ゲーム内経済のデザイナー

I·H·I·J：反復型（Iterator）、独立型（Hermit）、統合型（Integrator）、実務型（Journeyman）。

今日の Turian でできること

ゲームデータは、Inspector のフォームで編集する通常の JSON ファイル、データアセットに保存します。プログラマーが一度 [CreateAssetMenu] で型を公開すれば、以後はデザイナー自身が作成・編集できます。データアセットのバリアントは、変更した値だけを上書きします。
Studio のファイル監視が外部の変更を再インポートします。エディターの外でデータファイルを編集すれば、指示しなくても反映されます。
タグとレイヤーもアセットなので、名前や順序を変えてもシーンやプレハブの参照は壊れません。
データアセット主導の設計の第一段階。イベント、変数、ランタイムセット、ステートマシンを、デザイナーが接続するアセットとして扱い、エンジンとともに brick として配布しています。
データ交換の経路。ロケールごとに一つの .strings テーブルがあり、安定したキー、原文、訳文、注記、状態を保持します。例外を投げないフォールバック、置換、複数形と選択のブロックに対応し、--locale でセッションやスクリーンショットの言語を指定できます。エディター用ライブラリーは、キー、原文、訳文、注記、状態を維持したまま XLIFF 1.2 と CSV を読み書きします。

まだ足りないこと

何が何をリッスンしているかを示す Studio の全体表示と、ゲーム実行中の値の表示、手動でイベントを発火するボタン。
検証と Undo に対応した、データアセットの表形式インポート・エクスポート。文字列テーブルはすでに CSV で往復できますが、バランス調整用の表はまだです。
ライブラリーを取り巻く XLIFF の作業フロー。Studio とコマンドラインからの入出力、往復のテスト、前回のエクスポートからの変更報告、XLIFF 2.x、キーとプレースホルダーの検証、右から左へ書く文字体系への対応。
プレイヤーが実際に何をしたかに基づいて調整を評価するための分析機能。
クラウドサービス。現在の Turian はバックエンドを前提としませんが、その運用を助ける機能もありません。

**成功指標：**プログラマーを介さずゲームに取り込まれたコンテンツ変更の割合。

Gabriel

DevOps 担当

C·P·A·C：完成重視型（Closer）、純粋主義型（Purist）、設計型（Architect）、指揮型（Conductor）。

今日の Turian でできること

SDK とソフトウェア Vulkan ドライバー入りの公式コンテナーイメージがあります。turian-cli export はどの CI サービスでも実行でき、マニュアルには二つのサービス向けに、そのまま使えるワークフローを掲載しています。
入力の固定。CI=true なら brick の復元は自動的に --locked になります。ロックファイルはバージョン、ハッシュ、レジストリー、署名鍵を記録し、署名には通常の OpenSSH ed25519 鍵を使います。brick のキャッシュフォルダーは実行間で共有できます。
turian-cli oap validate は、パッケージのヘッダーと全アセットの CRC-32 を検証し、失敗時は 0 以外の終了コードを返します。
tick ごとの状態ハッシュを持つシミュレーションチェックポイント。描画が 30、60、144 Hz の場合と、セーブして再開した場合とで比較しています。ヘッドレスのテスト環境におけるゲームプレイの再現性は、約束ではなく検証結果です。

まだ足りないこと

brick ごと、パッケージごとのサイズとビルド時間のレポート。配布前にパッチの重さを知るためです。
二度ビルドしてバイト列を比較する CI チェック。現在の Turian が保証できるのは入力が同一であることまでで、出力が同一であることはまだ保証できません。
ビルド時のグラフアセット解析。
配布用のアセットパッキング。現在のエクスポートは、インポート済みのツリーをそのまま配布します。
プロファイラー。
iOS、Android、コンソール向けの出力。現在の出力先はデスクトップ（Windows・Linux）です。
ヘッドレスの NativeAOT サーバー。初期のサンプルは、すでにトリミング警告なしでエクスポートできます。プラットフォーム間での物理の決定性は、今後の課題です。

**成功指標：**CI で CLI を使っている組織の数。

Isabela

AA スタジオの社長

C·H·A·D：完成重視型（Closer）、独立型（Hermit）、設計型（Architect）、監督型（Director）。

今日の Turian でできること

条件を平易な言葉で示しています。MPL 2.0、ロイヤリティなし、ゲームのライセンスはスタジオが選べます。小さなリリースを頻繁に行い、プロジェクトを壊す可能性のある変更にはメジャーバージョンを付けます。各メジャーにはマニュアル内の移行ガイドがあります。
リリースノートでは実測値を挙げ、その数字で証明できないことも説明しています。たとえば「インスタンス化した小道具 10,000 個を 1 ドローコールで描画」「色付きキューブ 10,000 個の CPU 時間は約 0.6 ms」、または「プラットフォーム間での物理の決定性は今後の課題」といった形です。
Studio とランタイムの統計表示で、ドローコール数、インスタンス数、カリングされた数を確認できます。ヘッドレスのスクリーンショットでも同じカウンターを出すので、誰でも数字を再現できます。

まだ足りないこと

発売されたゲーム。誰が作ったものでも、どのストアでも、何でもかまいません。現在は 0 本です。別の数字であるかのようには書きません。
説得力のあるデモ。数字を書いたリリースノートではなく、入社初日の人に渡せるようなものです。
無料または有料の公式サポート。現在のサポート担当は私です。
公開された再現可能なベンチマーク一式。固定したシーン、アセット、カメラ、品質設定に加え、ハードウェア、ドライバー、正確なバージョン、日付を公開し、平均と最悪時のフレーム時間、ピークメモリ、最初のフレームまでの待ち時間、出力サイズを報告するものです。
リリース済みバージョンを使ったサンプルプロジェクトと、合格基準を公開したモバイル向けエクスポート。

**成功指標：**Turian を使用ツールとしてクレジットしている商用ゲームの数。

Julio

AAA プロデューサー

C·H·A·C：完成重視型（Closer）、独立型（Hermit）、設計型（Architect）、指揮型（Conductor）。

今日の Turian でできること

各チームのコンテンツを、ID、バージョン、明示した依存関係、エンジンの互換バージョン範囲を持つ brick として扱います。ストアの自動承認対象の名前以外で公開するリリースは承認待ちになります。バージョンは削除も差し替えもせず、選択対象からの取り下げ（yank）や非推奨化は、理由付きで明示的に行います。
アセンブリ定義。チームのスクリプトは明示的な参照を持つ単位としてコンパイルされるため、全員がすべてをコンパイルせずに作業を分担できます。
プリコンパイル済み brick。brick pack --precast でコンパイル済みアセンブリを配布できるので、brick の復元時に再コンパイルする必要はありません。
アセットパッケージ（OAP）は、ベースパッケージを必須とし、参照を書き換えずに ID でアセットを上書きできます。変更分だけを配布するための基盤です。
プロジェクトを開き直すときや Build & Run では、インポート済みファイルとコンパイル済みコードを再利用し、変更分だけをコピーします。これによりビルド時間を週ごとに追跡できます。

まだ足りないこと

brick ごと、パッケージごとのサイズとビルド時間のレポート。配布前にパッチの重さを知るためです。
ビルド、インポート、スクリプトのそれぞれについて、問題箇所を特定できるよう警告とエラーメッセージを体系的に見直すこと。すでにできているものもありますが、全体としてはまだ約束できません。
スケジュールに組み込める回答時間を持つサポート。
専用サーバーのビルドに対応した、任意導入のマルチプレイヤー brick。

**成功指標：**パッケージングやパッチ配布を理由に寄せられた問い合わせ。

Mariana

ツール開発者

C·S·T·I：完成重視型（Closer）、購入活用型（Shopper）、ツール職人型（Toolsmith）、発信型（Influencer）。

今日の Turian でできること

Studio 自体が、プラグインプラットフォーム上のプラグインです。パネル、コマンド、メニュー、ショートカット、設定ページ、テーマは、サードパーティーのプラグインと同じレジストリーを通ります。
拡張はプロジェクトの C# コードから属性で作れ、エディターのアセンブリを参照する必要はありません。[MenuItem]、[Panel]、[CreateAssetMenu]、[ComponentContextMenu] などに加え、Inspector 用の [Button]、[Range]、[ReadOnly] といった属性があります。
brick のマニフェストには、ID、バージョン、対応エンジンの範囲、依存関係、必要な NuGet パッケージ、SPDX ライセンスを記載します。各スクリプトとアセットには .meta ファイルが付き、ほかのプロジェクトはその ID を参照するので、名前や場所を変えても参照先は壊れません。
Guinevere.Autoformer。GUI フォームやツールを自動生成するライブラリーです。
brick verify --against はスタブが実物の brick と一致しているか検証し、brick stub は未完成の作業を土台としてほかの人が開発を進められるようにします。インストール済み brick は読み取り専用で、利用者はバリアントとインポート設定の上書きによって変更します。
破壊的変更は、すべて移行ノートに記載します。
バージョンは削除も差し替えもしません。取り下げたバージョンも、ロックファイルで固定したプロジェクトには引き続き提供し、新たな選択対象にはしません。フォークには brick diff と brick rebase を使えます。署名付きレジストリーへの公開では、releases、yank、deprecate などのスコープを持つトークンを使います。

まだ足りないこと

拡張用の機能を、エンジンの各バージョンで何を互換保証するか明示した、バージョン付き API として文書化すること。また、プラグインから参照できる、エンジン、属性、SDK のパッケージ。
自動生成してバージョン管理する API リファレンスサイト。プラグイン作者がシグネチャーを探すためにソースを検索せずに済むようにするためです。
レジストリーの上に載る公開ストア。公開者のスコープ、承認フロー、リリースに関する注意情報と来歴、同じパッケージのターゲット別バリアントが必要です。

**成功指標：**コアチーム以外の人が公開した拡張やプラグイン。

点検の土台：八つの観点と一覧表

私が行うエンジンの判断は、どれも八つの観点のいずれかに入ります。

観点	含まれるもの
アート	描画、シェーダー、2D、3D、オーディオ、制作ツール
自動化	CI/CD、テスト、パッケージング、ヘッドレスビルド、再現可能なビルド
ビジネス	価格、料金プラン、条件、権利、サービス、サポート
コード	コード中心の作業フロー、API、細部までの制御、パッケージ、性能
エコシステム	拡張、補助ツール、アセットストア、連携、データの入出力
エディター	使いやすさ、ドラッグ＆ドロップ、ビジュアル「プログラミング」ツール、シーン構成
学習	チュートリアル、文書、コミュニティー、動画、チャット、翻訳
プラットフォーム	モバイル、VR、コンソール、サーバー、マルチプレイヤー

次の表は、10 人それぞれが各観点に何を求めるかについての、私の見立てです。各ペルソナには四つのスタイルがあり、その中で最も強い要求を基に、各セルの初期評価を決めています。固定した結論ではなく、変わり得る意見です。

観点／ペルソナ	A	B	C	D	E	F	G	I	J	M
アート	◐	○	◐	●	●	○	○	◐	○	○
自動化	○	●	◐	○	○	○	●	◐	●	◐
ビジネス	◐	●	◐	○	○	○	◐	●	●	●
コード	○	●	●	○	○	○	●	○	○	●
エコシステム	●	○	●	◐	●	◐	◐	◐	◐	●
エディター	●	○	●	●	●	◐	○	○	○	●
学習	●	◐	◐	◐	◐	◐	◐	◐	◐	●
プラットフォーム	◐	●	●	○	○	○	●	●	●	◐

黒丸は必須条件です。その観点が欠けたり壊れたりしていれば、ほかがどれほど良くても、そのペルソナは離れます。半分の丸は重要ですが、採用の必須条件ではありません。白丸は、ほかの作業の結果として対応できればよいものです。

表から読み取れること

エディターが必須なのは、そのツールの中で日々を過ごす人です。 Ana、Carlos、Daniela、Eduardo、Mariana が該当します。ほかの人は、別のところに必須条件を置いています。
アートが必須なのは、ちょうど二人です。 ゲームの見た目を作る二人です。残りは、その成果を使う側か、まったく触れない側です。
エコシステムが必須なのは、ストアを利用する作り手です。 Benjamin のセルが白丸なのは意図的です。コード中心の利用者は、ライブラリーをストアではなくコードとして入手します。必須とする四人にとって、ストアは単なる一機能ではなく、製品の半分を占めます。
パイプラインを重視する人には共通点があります。 Benjamin、Gabriel、Julio は、自動化、コード、プラットフォームのいずれかに必須条件を持ち、プラットフォームでは Isabela も加わります。エディター選びでは一致しなくても、パイプラインでは一致します。
学習が必須なのは、初心者とツール開発者です。 ほかの人はマニュアルやソースを読めます。
ビジネスが必須なのは、支払い、契約、販売、供給を担う人です。 それ以外の人は、日々の仕事に取り組みます。

MASS4 はこのペルソナをどう使うか

この表が、人物像と実際の作業を結びます。

Issue にラベルを付ける。 一部の Issue には persona:* ラベルを付けます。そのラベルは、対象のペルソナがその話題を重視することを示します。
内部整備なら、そう明記する。 誰のためにもならない機能は、内部整備か、判断の誤りです。どちらもあり得ますが、そう明示する必要があります。
主張は指標の変化につながること。 上の各ペルソナには最後に一つの指標があります。Turian が実際に支持を得ているかを観察するためのものです。ある項目がペルソナに役立つと言うなら、どの指標を動かすか示せるはずです。示せないなら、飾りです。
必須条件による拒否のルールを、個々の変更にも適用する。 対象のペルソナの必須条件を壊すものを出荷すれば、その人にとっては全面的な失敗です。誰が影響を受けるかは、この表で分かります。

10 人全員に応えるのは、エンジンだけでなく、エコシステム全体です。

最も分かりやすいのはアセットストアです。Ana はテンプレートやキットを、Carlos はジャムを助ける brick を、Eduardo は小道具を探し、Mariana はそこで公開します。ストアの買い手にも売り手にも、この中に居場所があります。
次はライブラリーです。Graph、Guinevere、OAP、KTX2 などはエンジンの外にあり、まず Benjamin と Mariana に役立ちます。土台のエンジンが変わっても、独自の名前とリリースを維持します。
三つ目は、サービスとコミュニティーの場です。Isabela が必要とする人材市場、Julio のサポート窓口、そして Ana の最初の質問に彼女の言語で答えてくれる場所です。
表のビジネスとエコシステムの領域を満たすのは、エンジンそのものではありません。その周囲にあるすべてです。その全体こそが MASS4 の目指すものです。

最後に一つ。この 10 人は実在しません。Turian のようなツールが何に応えるべきかについての、私の見立てです。表の丸はすべて意見であり、間違っている可能性があります。でも、あなたは実在します。ゲームを作る人、あるいはゲームを作る人のために道具を作る人なら、この文章全体が想定する利用者はあなたです。あなたが大切にすること、嫌うこと、納得できないことは、私の意見より重要です。ペルソナは地図であり、あなたは実際の土地です。地図が間違っていたら、コメントでも Issue でも、この記事を見つけた場所への投稿でも、教えてください。それが次の点検をよくしてくれます。