4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

作ったけど公開できなかった個人開発アプリの話

4
Posted at

※ 本記事は技術的な開発記録を目的としたものであり、
ゲームのデータ・画像・素材等は一切使用していません。
また、利用規約を尊重し、最終的に公開は行っていません。

はじめに

個人開発で、スマホ用音楽ゲームのスコアを解析・管理するAndroidアプリ(仮称:ArcAanalyzer)を開発していました。

AndroidアプリとAPIサーバーを組み合わせた構成で、ある程度実用レベルまで完成しましたが、最終的に公開は断念しました。

本記事では、

  • システム構成
  • 技術的に大変だった点
  • 公開をやめた理由
  • 開発を通して学んだこと

についてまとめます。

これから個人開発を始める人の参考になれば幸いです。

作ったものの概要

開発していたアプリの目的は、以下のようなものでした。

  • ゲームのリザルト画像を読み取る
  • スコアや曲名をOCR抽出
  • サーバーに保存
  • 履歴や統計を可視化

OCR(Optical Character Recognition)は、画像から文字を認識する技術です。

いわゆる「スコア管理・分析系アプリ」を目指していました。

当初は「自分用ツール」として作り始めました。

全体構成

システム構成はシンプルです。

Androidアプリ → APIサーバー → データ保存・分析

処理の流れ

  • Androidで画像の前処理や文字認識
  • 必要な情報・一部画像をAPIに送信
  • サーバー側で保存・処理
  • 結果をアプリに返す

個人開発としては、よくある構成だと思います。

技術スタック

Server(バックエンド)

言語:Go
フレームワーク:Echo
API形式:REST
データ保存:軽量DB
認証:firebase Authentication
画像処理:一部OpenCV

Goを選んだ理由は、

  • 軽量で扱いやすい
  • 実行が速い
  • 気分

という点です。

Application(Android)

言語:Kotlin
UI:Jetpack Compose
画像解析:ML Kit
通信:OkHttp

Composeを使っていたため、UIの実装は比較的スムーズでした。
ML Kitは、主にタイトルやプレイヤー名抽出で使用しました。

実装で大変だった点

正直に言うと、「ここが最大の地獄だった」という一点はありませんでした。

その代わり、

  • API設計とセキュリティ対策
  • データ形式の調整
  • 画像認識精度の調整
  • 端末差対応
  • エラー処理

といった細かい問題の積み重ねが大変でした。

画像解析の調整

特に難しかったのは、画像品質への依存です。

  • スマートフォン
  • タブレット

によって認識する部分の位置が変わってくるので「100%安定する状態」を作るのはかなり難しいと感じました。

この部分は、最後まで改善しきれなかった点でもあります。

クライアントとサーバーの連携

クライアントとサーバーの連携でも、地味に苦労しました。

  • パラメータ設計
  • DBスキーマのバージョン管理
  • 互換性維持
  • エラー時の挙動設計

個人開発でも、API設計の重要性を強く実感しました。

運用して分かった問題

しばらく自分用として使っている中で、技術面以外の問題が気になり始めました。

それが「利用規約・二次創作の扱い」です。

Google Play Consoleのアカウントを作成し、公開を意識し始めたことで、

  • 本当に配布して大丈夫か
  • 規約的に問題ないか
  • 収益化できるのか

を真剣に考えるようになりました。

やめた理由:利用規約の問題

最終的に開発をやめた最大の理由は、利用規約の問題です。

対象ゲームの利用規約では、

  • ゲームデータの利用
  • 二次創作
  • 外部ツール

に関して、明確な制限があります。

アプリとして公開・配布する形にすると、規約違反になる可能性が高いと判断しました。

グレーな状態で出すリスク

個人開発では、

  • 「小規模だから大丈夫」
  • 「バレなければ問題ない」

と考えてしまいがちです。
しかし、

  • アカウント停止
  • 法的トラブル
  • 信頼低下

などのリスクを考えると、割に合いません。

それらを考慮すると、公開するメリットよりもリスクの方が大きいと判断しました。

開発を通して学んだこと

① 規約は最初に読むべき

最大の反省点です。

開発前に、

  • 利用規約
  • 二次創作ガイドライン

を確認すべきでした。

後から気づくと、すべてが無駄になる可能性があります。

② 技術力だけでは完結しない

個人開発は、技術だけでは成立しません。

  • 法的リスク
  • 運営方針
  • ライセンス

も含めた設計が必要です。

③ 小さく作って検証するのが重要

最初から完成形を目指したことで、工数が大きくなりました。

今思えば、

  • プロトタイプ
  • 規約確認
  • 公開可否判断

を先にやるべきでした。

「作れる」と「出せる」は別問題だと痛感しました。

まとめ

本記事では、音ゲー解析アプリを個人開発して断念した経験をまとめました。

  • Android+Go構成で開発
  • 技術的には完成した
  • 規約問題で公開断念
  • 多くの学びがあった

結果として公開はできませんでしたが、技術的・経験的には非常に価値のある開発でした。






(そういえば記事書くのは2年ぶりくらいです。)
4
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?