まだ実装していないけれど、最近考えている個人開発のアイデアが5つあります。ゲーム、AI、動画、作業記録まわりの話です。完成したものの紹介ではなく、今の時点で何に困っていて、どこまで作れそうかをメモとして整理しておきます。
なぜ構想段階のものを記事にするのか
個人開発の記事は、作ったあとに書くことが多いです。
実際、このブログでもローカル動画にタイムスタンプ付きメモを残すWebアプリや、FPS録画からキルシーンを切り出す仕組みについては、作ったあとに書きました。
ただ、作る前の段階にもけっこう考えることがあります。
何に困っているのか。 なぜ既存の方法では足りないのか。 最初に作るなら、どこまで削るのか。 どこがまだ分からないのか。
このあたりを残しておくと、あとで作り始めるときのメモになります。もし途中で考えが変わっても、「最初はこう思っていた」と分かるので、それはそれで役に立ちます。
今回の5つは、どれもまだ構想です。技術候補はありますが、採用を決めたわけではありません。実際に測った性能や画面もありません。その前提で、今考えていることを書いていきます。
FPS 動画分析で上達を数値化するツール
FPSの戦績サイトを見ると、キル数、デス数、勝率、命中率、ヘッドショット率、ランクなどは分かります。
でも、知りたいのはそこだけではありません。
自分が前よりよくなっているのか。 同じミスを減らせているのか。 敵を見てから撃つまでが遅いのか。 初弾が頭からどれくらいズレているのか。 デスした場所が毎回同じなのか。
こういう部分は、戦績の数字だけだと見えにくいです。
前に作ったキルシーン抽出は、画面上のOCRを使って「キルが起きた場面」を切り出すものでした。今回考えているのは、その先にあるFPS 上達 分析のツールです。録画を読み、試合ごとの変化を見て、反応時間やクロスヘア位置のズレを数値や画像で確認できるようにしたいです。
技術的には、録画からフレームを取り出し、敵、味方、クロスヘア、HUDを認識する必要があります。OpenCVには動画解析や物体検出、トラッキング系の機能がありますし、ゲームごとにHUDの位置が固定ならOCRやテンプレートマッチングも使えそうです。
ただ、ValorantとOverwatchでは画面情報がかなり違います。マップ、キャラ、スキル、UI、キル通知、リプレイの見え方も違うはずです。ひとつの仕組みですべてを同じ精度で見るのは難しそうです。
特に難しいのは、結果論だけのコーチングにしないことです。
デスしたあとに「そこに出なければよかった」と言うのは簡単です。でも、その瞬間に見えていた情報だけで判断できたのかは別です。録画だけでは、味方の通話、敵の残りスキル、プレイヤーの意図までは分かりません。
最初に作るなら、かなり絞ります。
デスした時刻を取る。 デスした場所を記録する。 敵を視認してから撃つまでの時間を見る。 初弾時のクロスヘア位置を切り出す。 試合ごとに同じミスが何回出たかを見る。
ここまでなら、完全なコーチングツールではなくても、自分の振り返りには使えるかもしれません。
ゲーム動画 AI実況は、フレームを読むだけだと面白くなりにくい
ゲーム動画をAIに見せて、実況文、字幕、音声を自動で作る仕組みも考えています。
やりたいことだけを書くと単純です。動画からフレームを取り出し、AIに状況を説明させ、音声合成して、Remotionなどで字幕と音声を合成する。
でも、これだけだとたぶん面白くなりません。
「敵が現れました」 「プレイヤーが撃っています」 「キルしました」
この文章は間違っていないかもしれません。でも、実況として聞きたいかというと微妙です。
実況っぽくするには、直前の出来事とのつながり、プレイヤーの癖、失敗へのツッコミ、予想、意外性、言いすぎない間が必要になります。画面に映っているものを説明するだけでは足りません。
技術構成としては、一定間隔でフレームを抽出し、重要な場面だけ細かく再解析する形を考えています。動画全体を一度にローカルLLMへ渡すのは重いので、場面ごとの要約を作り、それを後からつなぐ方が現実的そうです。
ゲーム知識も別途必要です。Valorantならラウンド、スパイク、スキル、マップ名が分からないと、状況の説明が浅くなります。複数ゲームへ広げるなら、ゲームごとの知識をRAGや検索で補うことになりそうです。
もうひとつ難しいのは、音声の長さです。実況文が長すぎると、映像の場面が先に進んでしまいます。字幕としても読みにくくなります。文章のうまさだけでなく、尺に収まるかが必要です。
最初の実装では、1本の短い動画だけでよさそうです。
30秒から1分単位でざっくり解析し、重要そうな場面だけ細かく見る。実況文を作り、音声化し、字幕と音声を合成する。最後は人間が見て、どこが面白くなかったのかを記録する。
自動化そのものより、「なぜ実況にならなかったのか」を残せる方が先かもしれません。
Minecraft AI botで作業を手伝う相棒を作りたい
Minecraftでは、会話できるNPCよりも、実際に作業を手伝ってくれる相棒がほしいです。
木材を集める。 鉱石を集める。 指定した場所を整地する。 アイテムをチェストへ運ぶ。 建築を少し手伝う。 危ないときは戻る。
こういうことを、チャットで指示したら少しずつ進めてくれる存在です。
今作っている終末都市系のMinecraft環境では、一人で遊んでいても誰かと作業している感じがほしくなります。ただ話すだけではなく、世界を見て、手順を考えて、実際に動いてほしい。
Minecraft 作業 botとして考えると、MineflayerのようなBotライブラリが候補になります。公式リポジトリを見ると、ブロック、エンティティ、インベントリ、チェスト、採掘、建築、移動などを扱えるようです。ここにLLMをそのままつなぐのではなく、周囲の状態を要約して渡し、実際の行動は小さな命令に分ける必要がありそうです。
違いを分けると、会話するだけのNPCは雰囲気を作るものです。決められた命令だけを実行するBotは、木を切る、移動する、採掘する、といった単発の処理が中心です。自分が作りたいのは、その中間より少し上で、周囲の状況を見ながら作業手順を選び直すAI相棒です。
難しそうなのは山ほどあります。
画面画像だけで操作させるのか、ゲーム内部のデータを取るのか。移動中に引っかかったらどうするのか。作業中に夜になったり、敵が来たり、チェストがいっぱいだったりしたらどうするのか。長時間のタスクを覚えておくのも難しそうです。
誤操作で建築物を壊す危険もあります。ここはかなり慎重にしたいです。
最初の実装では、指定した木を切り、木材を指定チェストへ運び、終わったらプレイヤーのところへ戻るくらいで十分だと思います。失敗したら理由を記録し、次回同じ失敗を避けられるかを見る。
それだけでも、相棒っぽさの入口にはなりそうです。
YouTube 区間再生とローカル動画 管理を合わせた自分用動画棚
YouTubeやローカル動画を見ていると、見たい部分だけをあとで連続して見たいことがあります。
1時間の動画のうち、必要なのは12分30秒から18分、35分から42分、55分から58分だけ。こういう区間を保存して、別の動画の区間と合わせて再生できる自分用の動画棚がほしいです。
通常のYouTubeプレイリストは、動画単位で並べるものです。ブックマークは場所を覚えるだけです。動画編集ソフトは再編集には向いていますが、見るための棚としては少し重いです。
自分がほしいのは、元動画を壊さず、必要な区間だけを登録して、メモと一緒に見返せるものです。
これは、すでに作ったローカル動画メモアプリと近いです。あれは動画の中にメモを残す道具でした。今回の構想では、動画の区間そのものを管理し、複数動画の見たい部分だけをつなげたい。
ただ、YouTubeを扱うなら慎重に考える必要があります。
個人利用でも利用規約の確認は必要です。動画をダウンロードするのか、元動画を直接再生するのかで扱いも変わります。元動画を再配布しないとしても、公開サービスにするなら追加で確認が必要です。技術的にできることと、規約上問題がないことは同じではありません。この部分は、実装前に確認しておきたいところです。
最初はローカル環境だけで、YouTube URL、開始時間、終了時間、メモを保存し、指定区間から再生できるところまでにします。複数区間をプレイリスト化できれば、まずは自分用として使えそうです。
動画が削除された場合や、YouTubeの仕様変更があった場合は壊れるかもしれません。そのあたりも、最初から大きなサービスとして考えない理由になります。
作業ログ 自動記録からObsidianとブログ記事の材料を作る
何かを作ったり、エラーを直したりしているとき、「これはあとでブログに書けそう」と思うことがあります。
でも、作業が終わったあとに書こうとすると、かなり忘れています。
どのコマンドを打ったか。 どのエラーが出たか。 どの方法をやめたか。 どのファイルを直したか。 どの順番で解決したか。
毎回メモを細かく取ればいいのですが、それができるならたぶん困っていません。
そこで、PCでやった作業を自動で記録し、あとからブログ記事の材料へ整理するツールを考えています。
対象にしたいのは、すべてのPC操作ではありません。指定したプロジェクトや、明示的に開始した作業時間だけです。ターミナル履歴、コマンド結果、Git差分、手動メモ、参考URL、スクリーンショットなどを作業単位でまとめます。
出力先は、まずObsidian向けのMarkdownでよさそうです。
「今日やったこと」「発生した問題」「試した方法」「失敗した理由」「解決方法」「記事にできそうなテーマ」「公開してはいけない情報」みたいに整理しておく。そこからAIに記事構成や下書き候補を作ってもらう。
ここで怖いのは、AIが勝手に補完することです。
実際に実行したこと、結果として確認できたこと、作業中に考えていたこと、AIが提案したこと、まだ試していないこと、推測。この区別が混ざると、ブログ記事として扱いづらくなります。
秘密情報も問題です。APIキー、パスワード、個人情報、社内情報がログに混ざる可能性があります。何でも記録すると便利そうですが、その分だけ公開前の確認が重くなります。
最初の実装では、個人開発用の特定フォルダだけを対象にします。
作業開始時に記録コマンドを実行する。 対象プロジェクトを指定する。 その間のターミナル履歴とGit差分を記録する。 手動メモを追加する。 作業終了時にMarkdownへまとめる。 AIが「やったこと」「失敗」「解決」「記事候補」を整理する。 Obsidianへ保存する。
公開用の記事本文は自動投稿しません。人間が確認してから使う形にしたいです。
5つに共通していること
並べてみると、5つとも似たところがあります。
AIを使うこと自体が目的ではなく、自分が面倒だと思っている部分を減らしたい、という話です。
FPS録画分析は、上達の振り返りを楽にしたい。 AI実況は、動画に合う言葉を考える負担を減らしたい。 Minecraft AI相棒は、一人作業の重さを少し減らしたい。 動画棚は、見たい区間を探す手間を減らしたい。 作業ログ整理は、ブログの材料を忘れないようにしたい。
完全自動化より、人間が途中で確認できる方が合っています。
ローカルで動かしたいものが多いのも共通しています。動画や作業ログはファイルサイズも大きいし、外に出したくない情報も混ざります。GPUが必要になるものもありそうですが、最初は手元のPCで小さく試せる範囲にしたいです。
最初から大きなサービスにするより、自分が使えるところまで作る方が続きそうです。
どれから作り始めるか
まだ決め切れていません。
作りたい気持ちだけで選ぶなら、FPS録画分析かゲーム動画のAI実況に寄ります。どちらも、普段のゲーム録画からそのまま試せるし、作れたら自分で何度も使いそうです。
ただ、最初の一歩として考えると、少し重いです。映像解析の精度、処理時間、ゲームごとの差、ローカルLLMの速度など、最初からつまずきそうな要素が多い。小さく作るにしても、何を成功とするかを先にかなり絞る必要があります。
逆に、形にしやすそうなのは自分用動画棚です。
すでにローカル動画にタイムスタンプ付きメモを残すアプリを作っているので、動画と時間を扱う部分は少し再利用できます。最初はYouTube URL、開始時間、終了時間、メモ、プレイリストだけでよさそうです。これなら、完成形ではなくても「自分が使える最小の形」までは近い気がします。
作業ログ整理もかなり欲しいです。ブログを書くときに、作業中の細かい判断を忘れることが多いので、実際に使い続ける可能性は高いと思います。ただ、ログには秘密情報が混ざるかもしれません。便利さより先に、記録する範囲と除外する情報を決める必要があります。
Minecraft AI相棒は、今すぐ作るというより、少し後で腰を据えて考えたいです。小さなBotとして始めることはできそうですが、相棒らしさを出すには、移動、失敗時の再計画、記憶、誤操作対策まで見ないといけません。楽しそうですが、最初の題材としては大きいです。
今の気分では、まずは自分用動画棚か作業ログ整理のどちらかから始めるのがよさそうです。
動画棚は、画面として使えるところまで早く持っていけそうです。作業ログ整理は、ブログを書く習慣そのものに近いので、うまくいけば後の記事にもつながります。
どちらを先にするかは、まだ決めていません。
でも、今回整理してみて、最初に作るなら「動画棚は1つのローカル画面で区間再生まで」「作業ログ整理は1プロジェクトのターミナル履歴とGit差分をMarkdown化するところまで」くらいがちょうどよさそうだと分かりました。
まとめ
今回は、まだ作っていない個人開発のアイデアを5つ整理しました。
FPS録画から上達を数値化するツール。 ゲーム動画をAIが自動実況する仕組み。 Minecraftで作業を手伝うAI相棒。 YouTubeやローカル動画の見たい区間だけをまとめる動画棚。 PC作業を自動記録してブログ記事の材料へ整理するツール。
どれも完成済みではありません。技術候補も、まだ候補のままです。作ってみたら思ったより難しい部分も出ると思います。
それでも、今の時点で困っていることと、最初に作る範囲を書き出せたのはよかったです。
作るなら、小さく始めたいです。
最初からすべてを自動化するのではなく、自分が実際に使う場面をひとつ選び、そこだけ動くものにする。使ってみて足りないところを足す。そのくらいの進め方が今の自分には合っていそうです。