GitHub CopilotでのAndroid開発体験 – ぐるなびをちょっと良くするエンジニアブログ

TL;DR

GitHub Copilotに頼りながら、「極力自力ではコードを書かない」方針でAndroidアプリ(アナログゲーム・ディスクゴルフ向けのスコア集計)を作りました。Androidはほとんど初めてでしたが、CopilotがUIの雛形や集計ロジックを提案してくれて、最終的に実用レベルのアプリに仕上がりました。この記事では取り組み方、実際の使い方(プロンプトの工夫)、得られた学びを共有します。

ほとんどコードを書かないで作ったAndroidスコア集計アプリとGitHub Copilotの話

背景とモチベーション

普段からボードゲームやアナログゲームをよく遊びます。スコア管理は各自の記憶に頼っていましたが、試合数が増えると記憶の齟齬や集計ミスが気になるように。自分用のスコア集計アプリがほしくなり、「せっかくだからAndroidアプリを作ってみよう」と思いました。

ただし、正直に言うとAndroid開発はほとんど未経験。そこで「自分は設計と検証に注力し、コーディングはCopilotに主に任せる」という方針でプロジェクトを進めました。結果として、アナログゲーム全般のスコア管理はもちろん、ディスクゴルフのラウンド記録にも使えるようになりました。

目標(ミニマム要件)

  • プレイヤーを登録してラウンドごとにスコアを入力できること
  • ラウンド終了時に合計を自動計算すること
  • データを端末に保存して次回起動時に復元できること
  • シンプルで直感的なUI(誰でもすぐ入力できる)

制約:自分はAndroidの細かい実装に慣れていないので、実装はCopilotに多くを頼る。自分は要件定義、UIフロー設計、動作確認・デバッグを中心に担当。

開発フロー(ざっくり)

  1. 要件と画面設計を書く(画面遷移、主要UI要素、入力フロー)。
  2. Android Studioを用意して、プロジェクトの雛形を作る(Activity/Fragment、依存関係などは最小限)。
  3. Copilotに対して「Playerデータクラス」「スコアを加算するロジック」「簡単なデータ永続化」などを順に生成してもらう。
  4. 生成されたコードを読み、必要に応じて修正・リファクタリング。
  5. エミュレータや実機で動作確認。UIの使い勝手を改善。

ポイントは「小さな単位でプロンプトを与え、生成されたコードをテストしてから次に進める」ことです。大きすぎる要求を一度に出すと意図とズレることが多いので、段階的に進めるのが正解でした。

Copilotとのやり取り(実例とコツ)

  • 良いプロンプト例:

      Kotlinで、
      Player(name: String, scores: MutableList) 
      のデータクラスを作って。
      合計スコアを返すメソッドも追加して
    
      RecyclerViewでプレイヤー一覧を表示するサンプルコードを書いて。
      各行でスコアを編集できるようにして
    
      Roomを使ってPlayerとラウンドを保存するためのDAOとEntityの雛形を出して
    
  • コツ:

    • 期待する入出力や例を一緒に書く(例:Playerインスタンスを作って合計を計算する短いサンプル)。
    • 生成物が動作しない場合は、エラーメッセージをそのままプロンプトに含めて修正を依頼する。
    • UIの見た目やUXを指定する(ボタンの配置、必須入力の扱いなど)と、実用的なコードが出やすい。

うまくいったこと

  • 雛形コード(データモデル、基本的なUI、永続化ロジック)を短時間で得られたため、学習コストが低くプロジェクトを始められた。
  • Copilotが提案する実装は現代的な書き方(Kotlinの拡張関数やシンプルなCoroutineの使い方など)を含むことが多く、勉強になった。

ハマったこと・注意点

  • Copilotの提案は常に最適でも安全でもない。特に非同期処理やデータベーストランザクション周りは自分で理解してから採用する必要がある。
  • UIの微調整(細かいレイアウトやアクセシビリティ)は手作業で直す場面が多かった。
  • 依存関係やAndroidのライフサイクルに関する知識不足でビルドエラーを出すことがあり、その都度ドキュメントを参照させて解決した。

学びと結論

  • Copilotは「自分が欲しいコードの雛形を素早く得るツール」として非常に有効。未経験分野に踏み込むときの心理的なハードルを下げてくれる。
  • ただし、生成されたコードを鵜呑みにせず、必ず挙動を理解してテストすることが重要。特にデータの永続化やエラー処理は注意深く確認する必要がある。
  • 「自分で1から全部書く」以外の選択肢でプロダクトを作るというワークフローは、短期間でプロトタイプを作るのに向いている。

今後やりたいこと

  • UI/UXの改善(操作ログの取得、スコア入力の高速化)
  • オンライン同期(複数端末での共有)
  • テンプレート機能(ゲームごとのスコアルールを切り替え)
  • テスト(ユニットテストとUIテスト)の整備

アプリ画面フロー図

おわりに

ここまで読んでいただきありがとうございます。
ちなみにこの記事も大枠をリポジトリを読み込んだCopilotに書いてもらいました。
自分では少し手直しした程度です。

そして今日は息子の誕生日という事で、記念に記事を書きました。
健やかに育って欲しい。

荒海

ゲーム業界でコンシューマゲーム等を作っていたが、2016年にぐるなびに中途入社。ぐるなびでは主にAPI開発を担当し、社内でGoのコミュニティを作ったりしてGoの布教活動をしている。趣味は発声とゲーム。




元の記事を確認する

関連記事