🎮

AI×個人開発で3週間！ゲーム履歴サービスを爆速で作った記録と学び

に公開
Python
個人開発
ゲーム
SPARQL
AI 開発
tech

序章：なぜ、「遊んだ記憶」は消えてしまうのか？

「FF5はリメイク作品何本あって、それのうちどれを遊んだっけ…？」
「あのヒトは本当にゲームに詳しいけど、どれくらいゲームを遊んでるんだろう？」

ファミコン、PS2、Switch、ゲームセンター… 無数に散らばるゲームプレイの経験、あなたはどう記録していますか？その曖昧な記憶を形として残せるようにしたい。その衝動に突き動かされて、AIを相棒にたった3週間でゲーム履歴サービス「YouPlayed」を作って公開しました。

この記事を読めば、以下のことがわかります。

  • AI(Cursor/Claude)を使った爆速開発のリアルな手法
  • マイナー技術(SPARQL: 知識グラフ検索言語)をAIの力で乗りこなす具体的な方法
  • AIは副操縦士か、お節介な新人か？リアルな失敗から学んだ3つの教訓

これは、一個人がAIと共に未知の技術領域に挑み、サービスを爆速で立ち上げた試行錯誤と手探りの開発経験から得られた知見です。

3週間で作ったサービスでできること

この開発スプリントの成果物が、ゲームプレイ履歴記録サービス YouPlayed です。プレイヤーの fleeting（儚い）なゲーム体験を、structured（構造化された）、lasting（永続的な）な「記録」へと変換し、未来の文化資源として蓄積することを目指しています。

主な機能は以下の通りです。

  • ゲーム検索と記録：公的学術データベースを基盤に、過去に遊んだゲームを正確に検索・記録。
  • パーソナル年表：記録されたプレイ履歴から、自分だけの「ゲーム年代記」を自動生成し、SNSで共有可能。
  • 文化的トレンドの可視化：全ユーザーのお気に入り率やプレイ数に基づく散布図やランキングで、ゲーム文化の動向を分析。
  • 研究利用向けデータ出力：記録データをCSVやRDF（.ttl形式）でエクスポート可能。学術研究など二次利用への道を開きます。

ゲーム検索画面
▲ゲーム検索画面：タイトルなどを入力すると候補が表示され、クリックで記録できるUI

プレイ履歴画面
▲プレイしたゲームのリスト、発売日でソートすれば年表にもなります。

AIは最高の相棒？それともお節介な新人？

今回の開発は、そのほぼ全てをAI支援開発環境「Cursor」と、対話型AI「Claude」とのペアプログラミングで進めました。

コード量は27,000行ほどで、AIは、Flaskでのバックエンド実装、Vue.jsでのフロントエンドコンポーネント作成、そしてニッチ技術のSPARQLクエリの生成まで、領域を横断してサポートしてくれました。これにより、私は細かな実装作業から解放され、アーキテクチャの設計、UXの検討、そしてAIが生成したコードのレビューという、より本質的な作業に集中することができました。開発は前述のとおり3週間の間、隙間時間に行いました。私は、データモデルを専門としていますが、フロントエンド周りの知識は初心者レベルです。本当に開発できるか確信はなかったのですが、結果的には短い期間でなかなかのものが仕上がりました。

とはいえ、AIは万能のコード生成器ではありません。開発プロセスでは、AIとの協業の難しさを示す、いくつかの象徴的な“事件”も発生しました。これらは失敗談であると同時に、現代の開発者にとって重要な教訓を含んでいます。

教訓①：AIの“記憶喪失”と戦う「コンテキスト・リセット」術

ある日、ゲームの詳細ページに配置したアイコンが、画面全体を覆うほど巨大に表示されるバグが発生しました。CSSを修正するようAIに指示しても、なぜか別のバグを生むだけで一向に直りません。

根本的な原因は、AIが対話の途中で誤ったCSSの前提知識を「記憶」してしまい、その後の指示を全てその誤った文脈の上で解釈していたことでした。解決策は、修正を重ねることではなく、対話の文脈を一度リセットし、まっさらな状態から再度指示を出すことでした。これは、AIとのペアプログラミングにおける新しいデバッグスキル、すなわち「コンテキスト・マネジメント」の重要性を示しています。

教訓②：AIは機長にあらず。アーキテクチャの舵を取るのは誰か

当初、データベースはスケーラビリティを考慮してPostgreSQLで設計を進めていました。しかし開発の途中、AIとのやり取りの中で、いつの間にかデータベースがローカルで手軽に扱えるSQLiteに変更されてしまっていることに気づきました。

AIは、開発の初期段階における「手軽さ」や「シンプルさ」を優先して、自律的にこの変更を提案し、実装してしまったのです。これは局所的には最適な判断かもしれませんが、プロジェクト全体の長期的な視点からは逸脱した選択でした。

幸い、ORM（Object-Relational Mapper）としてSQLAlchemyを採用していたため、PostgreSQLへの再変更は容易でした。この一件は、AIが決して万能のアシスタントではなく、最終的なアーキテクチャ上の意思決定を行い、その一貫性を担保するのは、依然として人間の開発者の重要な責務であることを教えてくれました。AIは副操縦士であっても、機長は人間なのです。

なぜ僕は「普通のDB」を捨て、国の“文化遺産データ”を選んだのか？

このプロジェクトの根幹をなすデータ基盤には、国立アートリサーチセンターが運営するメディア芸術データベースを採用しました。なぜ、一般的なゲームAPIや商用データベースではなかったのか。その理由は、このプロジェクトの理念そのものにあります。

  • 信頼性（Reliability）：文化機関によって編纂されたデータであり、商用サービスとは一線を画す学術的な信頼性と永続性が期待できます。
  • オープン性（Openness）：データがSPARQLという標準化されたクエリ言語で公開されており、誰でも自由にアクセスし、再利用できます。
  • 構造的優位性（Structural Advantage）：MADBのデータ構造は、単なる「ゲームタイトル」ではなく、「ゲームパッケージ（製品版）」を単位としています。

この「ゲームパッケージ」単位という点が、文化資源としての記録を考えた際に決定的に重要です。例えば、『ストリートファイターII』というタイトルを記録するだけでは不十分です。「スーパーファミコン版」なのか「メガドライブ版」なのか、あるいは「アーケード版」なのか。これらがいかに似て非なるものかはゲーム好きなら認識できると思います。これらの版（バージョン）の違いは、ゲームの歴史や文化を語る上で極めて重要な情報です。MADBの構造は、この解像度での記録を可能にしてくれます。

AIと乗りこなすSPARQL：知識グラフの扉を開いた方法

MADBのデータは、一般的なリレーショナルデータベース（RDB）ではなく、RDF（Resource Description Framework） という形式の知識グラフで構築されています。そのため、データの検索にはSQLではなく、SPARQLという専用のクエリ言語を用います。

これらの技術セットは大手アーカイブ機関の公開データの標準で、Wikidataなどでも採用されるほか、LLMsを含むAI研究で再注目されている技術です。

SQLがテーブル（表）の行と列を操作するのに対し、SPARQLはデータ（ノード）とデータ間の「関係性（エッジ）」を辿って情報を抽出します。例えば、「複数存在するタイトル属性に『ファイアーエムブレム』という文字列を含むゲームパッケージ」といった条件を、データの関係性を直接記述することで表現できます。

# 「エムブレム」シリーズを全文検索するクエリの例
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX schema: <https://schema.org/>
PREFIX neptune-fts: <http://aws.amazon.com/neptune/vocab/v01/services/fts#>
PREFIX class: <https://mediaarts-db.artmuseums.go.jp/data/class#>
PREFIX ma: <https://mediaarts-db.artmuseums.go.jp/data/property#>

SELECT DISTINCT ?game ?title ?platform ?releaseDate ?publisher
WHERE {
  SERVICE neptune-fts:search {
    neptune-fts:config neptune-fts:endpoint "https://vpc-mediaarts-db-qaymrmtqbprlhmqq33a2ncf4ke.ap-northeast-1.es.amazonaws.com" .
    neptune-fts:config neptune-fts:field rdfs:label, schema:name, schema:alternateName, ma:variantTitle, schema:gamePlatform, schema:publisher .
    neptune-fts:config neptune-fts:queryType "query_string" .
    neptune-fts:config neptune-fts:query 'エムブレム' .
    neptune-fts:config neptune-fts:return ?game .
  }
  ?game a class:GamePackage .
  ?game rdfs:label ?title .
  OPTIONAL { ?game schema:gamePlatform ?platform . }
  OPTIONAL { ?game schema:datePublished ?releaseDate . }
  OPTIONAL { ?game schema:publisher ?publisher . }
 }
}

このクエリのリンク（MADB Lab）
SQLが「Aの棚からBの条件に合う本を探せ」と命じる几帳面な司書なら、SPARQLは「『エムブレム』に関わる情報を根こそぎ持ってこい！」と頼める人脈の広い情報屋のようなものです。
とりわけ、このエンドポイントではneptune-fts:searchの機能で高速全文検索が可能です。

特徴 SQL SPARQL
データのかたち Excelのような表 クモの巣のような関係図
得意なこと 決まった形のデータを正確に検索 データ同士の繋がりを辿って検索
柔軟性 低い（最初に決めた構造を変えにくい） 高い（後から自由に関係を追加できる）
主要なスコープ 内部データ 公開データ

▲SQLとSPARQLの比較

さて、柔軟で強力な一方、SPARQLは独特の構文と思考法が求められ、学習コストが高い言語です。しかし、この技術的障壁はAIの支援によって大幅に低減されました。そしてMADB Labで例示されているサンプルクエリは、AIの格好の教材にもなりました。

また、YouPlayedから出力されるデータにはMADBのID（URI）を付与しています。これにより、ユーザーが生成したデータは、常に大元の公的データベースへとリンクされ、情報の出自と信頼性が担保される設計になっています。

あなたのゲーム史が「文化の縮図」になる。データ可視化への展望

YouPlayedは、単にプレイ履歴を記録するだけのツールではありません。蓄積されたデータを文化的・分析的な視点から眺めることで、新たな洞察を得ることを目指しています。そのための機能が、Chart.jsを用いて実装した統計・可視化機能です。

ゲーム人気分析チャート
▲公開直後でデータはまだ疎らですが、記録が増えることで文化の縮図が見えてくるはずです。

この散布図はゲーム文化のトレンドを多角的に捉えるための試みです。

  • X軸：プレイ数（作品の知名度や商業的成功の代理指標）
  • Y軸：お気に入り登録率（作品への熱量や批評的評価の代理指標）

この2軸のマトリクスによって、ゲームを以下のように分類して捉えることができます。

  • 右上（プレイ数が多く、お気に入り率も高い）：広く遊ばれかつ多くの人の思い入れがある「時代を象徴する神ゲー」
  • 左上（プレイ数は少ないが、お気に入り率が高い）：一部のプレイヤーに深く刺さった「隠れた名作」や「カルト的人気を誇る作品」
  • 右下（プレイ数は多いが、お気に入り率は低い）：「話題にはなったが賛否両論を呼んだ作品」や「期待値が高すぎた作品」

将来的には、このデータを基にユーザーの嗜好をクラスタリングし、趣味の近い他のプレイヤーを推薦したり、まだ遊んでいないが好みであろうゲームを提案したりする機能も構想しています。知識グラフとの連携によって、ゲーム文化の「集合知」を浮かび上がらせることが最終的な目標です。

散布図のような多角的な分析だけでなく、より直接的な各種ランキングも実装しました。
ユーザの登録ゲーム数やプラットフォーム別の人気など、様々な角度からゲーム文化の動向を眺めることができます。

ランキング各種
▲各種ランキングです。現時点ではレトロゲームが人気。任天堂が圧倒的人気。1999年は当たり年？

将来的にはユーザーが公開設定しているデータをダンプ出力して、オープンデータ(LOD)として公開することも検討しています。

結論：AIは、個人の「やってみたい」を加速させる最強のブースターだった

今回の3週間の開発スプリントを通じて再認識したのは、AIという強力な「相棒」の存在が、個人開発者一人で達成できることの範囲と速度を、根本的に変えつつあるという事実です。何よりフロントエンド開発能力の不足というスキルギャップを埋める能力には感嘆しました。自分の得意分野を武器とする、それを実現させるための素晴らしいサポーターであることは間違いありません。

同時に、AIは表層的な賢さは間違いなく備えていますが、現時点では以下の点で明確な不足があります：

  • 構造的思考
  • コンテキストの一貫性の保持
  • 再帰的思考

これらを人間がサポートする必要があり、そのペアプロの開発プロセスにこそ大いに学びと気付きがあります。そこに何よりの価値があるし、ヒトには今後そのような能力の開発が求められていると感じました。

かつては大学や大企業の研究室の専売特許であったSPARQLやRDFといった知識グラフ技術でさえ、今やAIのサポートがあれば、個人がWebアプリケーションのコア技術として採用し、短期間でプロトタイプを構築できる時代になりました。

これは、技術的なハードルが下がったことだけを意味しません。「自分の個人的な興味や問題意識を、社会的な価値を持つかたちでアウトプットする」という、創造の本質的な活動が、より多くの人にとって身近になったということです。

👉 YouPlayedで記録をはじめる： https://youplayed.net
🐦 この記事で紹介したAIとのペアプロの成果は、YouPlayedで実際に触れてみることができます。もしご興味を持っていただけたら、ぜひあなたのゲームの記憶を記録してみてください。感想やフィードバックは、X（旧Twitter）で @fukudakz へのメンションか、ハッシュタグ #YouPlayed をつけて投稿いただけると大変励みになります！必ずいいねかレスします！

Discussion