コンテンツにスキップ

世界一への戦略

ポジショニング

AI×エンタメの情報は、ニュース（速いが浅い）、学術論文（深いが実務に遠い）、 企業ブログ（実践的だが自社都合）に分断されている。 このナレッジベースはその間を埋める 「作り手と意思決定者のための体系知」 を狙う。

特に以下を差別化の柱にする：

  1. エンゲージメント設計 × AI（リポジトリ名 addictive-game の由来） 「人がハマる仕組み」をAIでどう強化・個別化し、同時にどう健全性を守るか。 ここは既存情報が最も散らばっている領域であり、一番深く掘る。
  2. 日本発の視点 アニメ・マンガ・ゲーム・VTuber・アイドルという日本の強い領域と、 日本の著作権法（第30条の4など）という独特の法環境を英語圏より深く扱う。
  3. 一次情報 要約だけでは世界一にならない。小さなプロトタイプ・実験を回して結果を記録する。

ロードマップ

Phase 1: 骨格（現在）

  • 全体マップ・分類体系
  • 領域別の基礎記事（L1〜L2）
  • 記事テンプレート・運用ルール

Phase 2: 深さ

  • 重点領域を「AIキャラクター・会話NPC」に決定 → knowledge/ai-characters
  • 重点領域の設計パターン集（38パターン）・事例分析（11件）・評価フレームワーク
  • 映像・音楽・アニメ/マンガの事例分析を10本ずつ（計30件）→ domains/case-studies
  • 事例からAI利用の開示の実践ガイドを作成（日英）→ ai-disclosure-guide
  • 日本の事例の追加（公式IPキャラのAI化、AI VTuber）
  • 法務記事を国別（日・米・EU・中・韓）に分割し比較表を作成 → by-country
  • 【要確認】 箇所の出典付与（2026-09-24。すべて解消）→ 確認ログ
  • 確認区分BをA（一次情報の本文確認）に格上げ（2026-09-24: 6項目をA化済み、残りはボット対策のあるサイト）

Phase 3: 一次情報

  • LLM駆動NPCの実験環境（素朴な実装とパターン適用版の比較、攻撃8種・正当なプレイ4種）→ prototype
  • 構造上の保証のテスト（LLMが完全にだまされる最悪の場合）→ 実験記録
  • 実モデルでの予備実行（Opus 5 を1試行、Haiku 4.5 を3試行）と判定器の単体調査 → 実験記録（第2回）
  • Opus 5 の5試行の本実験（クレジット不足で途中停止。再実行が必要）
  • 判定器の弱点（A12）への対策: 主張をゲームの事実で裏づける v2 を実装し、最悪の場合のテストと実際の判定結果の流し直しで有効性を確認 → 第3回・第4回
  • v2 を会話の流れ込みで確認（Haiku 4.5、4シナリオ×1試行、$0.03）→ 第5回
  • 実験結果を実践ガイドにまとめる（説得・交渉NPC、日英）→ playbook
  • AI生成アセットの制作コスト比較実験
  • プレイヤー体験の定量評価フレームの検証

Phase 3.5: ナレッジを制作に使う

  • CLAUDE.md とゲーム制作用スキル3つ（企画・AIキャラ設計・公開前チェック）
  • 試行: ORBIT SWITCH の公開前チェック → studio/orbit-switch
  • 制作で得た学びをナレッジに戻す（App Store・Google Play の規約、AIコーディングで作ったゲームの開示）

Phase 4: 外部化

  • 静的サイト化（検索・タグ付き、GitHub Pages）→ https://kouki0727mickey.github.io/addictive-game/
  • 英語版の作成（済: AIキャラクター一式、事例分析30件、国別法務、開示ガイド。残り: 基礎・領域別の記事）
  • 定期レポート（四半期ごとの「AI×エンタメ動向」）

更新サイクル

頻度 作業
週次 ニュース・論文・リリースのインボックス整理 → 該当記事に反映
月次 90日以上未更新の記事をレビュー
四半期 全体マップの見直し、動向レポート発行

情報源リスト（定点観測）

  • 学会: GDC, SIGGRAPH, NeurIPS/ICML/ICLR（生成モデル）, AIIDE, CHI, FDG, CEDEC
  • 論文: arXiv（cs.AI, cs.CL, cs.CV, cs.SD, cs.HC）
  • 業界: 各ゲームエンジン（Unity/Unreal）の公式発表、主要AIラボのリリースノート
  • 法規制: 文化庁（AIと著作権）, 米国著作権局, EU AI Act 関連文書

API試験の費用方針（2026-09-25〜）

実モデルでの試験は行うが、最小コストで進める。

  1. APIなしで分かることを先にやる: 構造上の保証のテスト、記録済みの結果の流し直し（replay_probe）
  2. 実行前に見積もる: run_eval --dry-run で呼び出し回数と費用を確認する
  3. 必要な分だけ流す: --only（シナリオ）と --engines（実装）で絞る。試行は1回から
  4. 安いモデルから: まず claude-haiku-4-5。大きなモデルは、結論が分かれて本当に必要なときだけ
  5. 上限を必ず付ける: --max-usd（既定 $0.50）。上限に達したら止まり、完了分は残る
  6. 結果に費用を記録する: 出力の「推定費用」を実験記録に残す