ゲーム・エンタメ
AIを使ったというチェック一つでは、何も分からない
公開日: 2026-07-27
解決すべき課題
SteamのAI開示は実質オンとオフの一マスなので、AIがゲームのルールそのものである作品と、生成アセットを載せて売る作品と、ローカライズにだけ使った作品が、同じ表示で同じ棚に並ぶ。
なぜ今なのか
2026年のSteam新作の3割がすでに開示を付けており、Valveが開示フォームの対象範囲まで変えたため表示の意味が年ごとにぶれている。一方で写真と映像には来歴署名の規格がすでに載り始めており、移植できる土台がある。
推薦人材
UnityやUnrealのビルドパイプラインとCIを実務で回した経験があり、コンテンツ来歴署名の仕様を読んだことのある人
どんな問題か
Steamのストアページに出るAI開示は一マスだ。使ったか、使っていないか。その下に開発元が自由記述で数行書く。いまその一マスの中に、まるで違う三種類のゲームが同居している。AIがゲームのルールそのものである作品、生成画像をアセットとして載せて売る作品、そして翻訳の質を上げるためにローカライズにだけ使った作品である。プレイヤーから見れば、この表示は何も教えてくれない。
数字を見ると、このマスがどれだけ過積載かが分かる。PC Gamerがまとめた集計では、AI開示を付けたゲームの比率は2024年10.9%、2025年19.9%、2026年は7月時点で30.8%。PC Guideは累計17,000本超に開示が付き、そのうち30%が二つ以上の用途を挙げていると伝えた。スルカ・ハロが2023年7月から2026年7月までのSteam新作53,597本を全数調査した結果はもっと具体的だ。この期間にAI表示が付いた約9,400本のうち87%が商業的に成果を出せず、その不振作の72%が挙げた用途は「AIアート・画像・テクスチャ」だった。逆に成果を出した作品は、音声(24%対8%)とローカライズ(18%対6%)を挙げた比率がはるかに高い。
つまり同じ表示が正反対の信号を運んでいる。生成アセットで急ごしらえした商品を避けたいプレイヤーと、良い吹き替えや翻訳を歓迎するプレイヤーが、同じバッジを見て別々の判断をしなければならない。開発元の側も損をする。多言語ローカライズにだけAIを使ったチームが、アセット量産の山と同じマスに束ねられる。だから一部のチームは、開示を最小限だけ書いて済ませるようになった。
なぜ今か
三つが重なっている。
一つ目は、表示の意味が揺らぎ始めたことだ。Valveは開示フォームを改訂し、対象は「プレイヤーが消費するAI生成コンテンツ」であって裏方の効率化ツールではないと明記した。定義が動いたのだから、2024年のチェックと2026年のチェックはもう別のものを指す。累積データで何かを判断しようとした瞬間、この継ぎ目でずれる。
二つ目は、議論の語彙が整ってきたことだ。韓国のインベンは7月27日の特集で、Claudeでコードを書いたからといってそれがAIゲームなわけではないと指摘した。記事が引く論文「AI-Native Games: A Survey and Roadmap」は公開済みのゲームとプロトタイプ53本を分析し、AIを外すと作品自体が成立しない種別を切り出している。道具として使ったのか、素材として使ったのか、ルールとして使ったのかを分ける言葉が、ようやく存在する。
三つ目は、移植できる技術があることだ。写真と映像ではContent Credentialsのような来歴署名の規格がカメラや編集ツールに載り始めている。ゲームのビルドにはまだ対応物がない。ただしゲームのほうが条件はいい。写真と違ってビルドパイプラインという単一の関門があり、どのファイルがどのツールを通ってパッケージに入ったかを記録する場所が、すでにコードの中にある。日本のインディーや同人シーンでは、イラストレーターの反発もあってAI利用の線引きが特に敏感な論点になっている。曖昧な一マスのままでは、その線引きを誠実にやっているチームほど不利になる。
flowchart LR
A[エディタと生成ツール<br/>アート・音声・翻訳・コード] --> B[ビルドフック<br/>アセット別に使用ツールを記録]
B --> C[AI利用マニフェスト<br/>機械可読]
C --> D[ストア表示と検証API]
D --> E[プレイヤー側フィルタ<br/>欲しいものだけ絞る]
どう作るか
ビルドに付く薄い記録係から作る。UnityやUnrealのビルドフックで、出荷パッケージに入ったアセットを走査し、そのファイルがどのツールから出たかをメタデータとプロジェクトログで突き合わせて表にする。項目は六つで足りる。アート、音声、テキスト、音楽、コード、そして実行中のモデル呼び出し。各項目に三段階だけ付ける。未使用、人が手を入れた補助、生成物をそのまま出荷。ここまでを開発元が数クリックで終えられなければ、導入で死ぬ。
出力はゲームと一緒に配布されるマニフェストファイルだ。人が読む文章ではなく機械が読む表でなければ、ストアやコミュニティツールが消費できない。Steamの開示文はこの表から自動生成して貼れば、開発元が別途書く手間がなくなる。次が検証である。最初は自己申告にビルドログを証拠として添える程度で始め、虚偽申告が実際に問題になった時点で署名と再現ビルドに締める。最初から完璧な検証を目指すと誰も使わない。
流通は大手ストアを狙わず、小さいところから始める。itch.ioのように方針の実験が速い場所か、インディーパブリッシャー一社と組んで、実際の商品ページにバッジを出してみる。開発元には無料で配り、値段はストアとパブリッシャーが使う検証APIとポートフォリオ監査で取る。パブリッシャーは自社ラインナップのどこにどこまでAIが入っているかを把握できておらず、法務がすでに困っている。
成功の条件
二つで決まる。
一つは、開発元が面倒を引き受ける理由だ。細かい開示のほうが売れるという証拠を出せなければならない。ハロの集計で、音声とローカライズにAIを使った作品が成果を出した側に偏っているという相関は、その論拠の出発点になる。ただし相関であって因果ではないので、初期パートナー作品でA/Bを回し、バッジが実際の転換にどう効くかを自分で測る必要がある。
もう一つは採用だ。ストアが受けなければラベルは飾りになる。だから初期設計でSteamの開示フォームを置き換えようとしてはいけない。そのフォームを自動で埋める道具として入り、ストア側に反対する理由を作らないことだ。標準化は後段の話にする。この順序を逆にした来歴標準がここ数年どうなったかは、事例が十分にある。
一緒に作りましょう
一緒に作る人材を見る