作りかけのiOSアプリをgitで保全し、AIに実力を測らせた記録

以前作りかけたiOSのボードゲームアプリ「きえるまるばつ」に、また手を入れようと考えました。ところが、どこまでできているのか自分でも分かっていませんでした。この記事では、手を入れる前に今の状態を残し、Claude Code に実力を測らせた手順と、分かったことを書きます。

作りたかったもの

きえるまるばつは、まるばつ（三目並べ）に「古い駒が消える」ルールを足したゲームです。置いた順が一番古い駒が消えるので、盤の上の駒はいつも6個までになります。消える予定のマスには置けません。

アプリのコードはSwift（iPhoneアプリを作るための言語）で書かれていて、Macの中のフォルダにありました。ただ、変更の履歴を残す仕組みは使っていませんでした。

私はタスク台帳（やることと結果を記録している表）で作業を管理しています。台帳には、このアプリについて「Swiftの実装あり／完成度は未確認」とだけ書いていました。今回の目的は2つです。

手を入れる前の状態を、いつでも戻れる形で残すこと。
「未確認」のままだった完成度を、実際に動かして確かめること。

AIへの頼み方

作業は Claude Code に任せました。頼んだことは、大きく分けて次の2つです。

1つ目は、フォルダを git のリポジトリにすることです。git は、ファイルの変更の履歴を記録する道具です。リポジトリは、その記録をまとめて置く場所です。そのうえで、変更前の状態を最初のコミット（ある時点のファイルの状態を記録したもの）として残すように頼みました。

2つ目は、今の実状を確かめることです。「ビルド（アプリの形に組み立てること）が通るか」「テストが通るか」「警告が出ていないか」を、実際の結果として記録してもらうことにしました。これを作業の完了の条件にしました。

確かめる流れは、次の図のようになりました。

flowchart LR
  A["今の状態をgitに残す"] --> B["ビルドとテスト"]
  B --> C["ルールだけを取り出して検証"]
  C --> D["CPU同士の自動対戦"]
  D --> E["見た目の実測"]
  E --> F["台帳の記載と比べる"]

つまずいたところ

一番の気づきは、台帳の書き方が実態より低かったことです。「完成度は未確認」と書いていましたが、調べてみると、テストもそろっていて、ルールも正しく動いていました。作ったときの記録を残していなかったので、自分のアプリなのに実力を知らなかったことになります。

次に迷ったのは、何を記録の対象にするかです。Xcode（Appleのアプリ開発ツール）で作業すると、自動で作られるファイルがたくさんあります。たとえば、ビルドのたびに作られる中間ファイルや、画面の配置など個人の設定のファイルです。これらを履歴に入れると、中身の変更と関係のない差分が増えてしまいます。

もう1つ迷ったのが、プロジェクトの設定ファイル（KieruMarubatsu.xcodeproj）の扱いです。このファイルは、xcodegen という道具を使えば、別に書いてある設定の一覧から作り直せます。作り直せるなら、記録しなくてもよいようにも見えました。

見た目の確認では、よくない結果も出ました。オレンジの背景に白い文字を置いた部分の読みやすさです。コントラスト比（文字と背景の明るさの差を数字にしたもの）が、ライトモードで2.31:1、ダークモードで2.23:1でした。アプリ向けの基準ではありませんが、Webのアクセシビリティ（誰でも使いやすくすること）の基準 WCAG 2.2 が目安になります。WCAG 2.2 では、ふつうの文字は4.5:1以上、大きな文字でも3:1以上を求めています。どちらにも届いていません。

どう判断したか

記録から外すファイルは、.gitignore（git に無視させるファイルを書いておく一覧）で指定しました。外したのは次の4種類です。

.DS_Store
DerivedData
xcuserdata
xcuserstate

.DS_Store は Mac が自動で作るフォルダの表示設定です。DerivedData はビルドの中間ファイル、残りの2つは個人のXcodeの設定です。どれも、アプリの中身とは関係がありません。

設定ファイル（.xcodeproj）は、記録に含めることにしました。作り直せるとしても、xcodegen が無い環境ではビルドできなくなるからです。道具が1つ無いだけで動かせなくなる状態は避けたいと考えました。

作ったリポジトリは、GitHub などのネット上の置き場所にはまだ送っていません。今回の目的は「変更前の状態を手元に残すこと」なので、そこまでは必要ないと判断しました。

ルールの確かめ方にも工夫がありました。アプリのコードは、画面を作る部分と、ゲームのルールを決める部分（ドメイン層と呼びます）に分かれていました。ルールの部分は、画面のコードを使わずに書かれていました。そのため、ルールの部分だけを切り離しても動きます。

そこで Claude Code は、ルールの部分だけを取り出して swiftc（Swiftのコードを実行できる形に変える道具）で組み立てました。アプリ全体を動かさなくても、ルールの決まりごとを1つずつ総当たりで試せるからです。

できたもの

変更前の状態は、最初のコミットとして残りました。39ファイル、2,000行です。これで、この先どう手を入れても、この時点に戻れます。

実状を確かめた結果は、次のとおりです。

テスト：シミュレータ（Mac の中でiPhoneの動きを再現する仕組み）の iPhone 17 Pro で、37個のテストがすべて通りました。テストは6つのまとまりに分かれています。
警告：一からビルドし直しても、コードへの警告は0件でした。出たのは、コードの問題ではない、Xcode の定型のメッセージが1件だけです。
ルール：一番古い駒が消えること、消える予定のマスに置けないこと、盤の上が常に6個までであることを確かめました。消える駒を含む3つ並びは、勝ちになりません。消してから勝ち負けを判定する順番が正しいということです。ルールに合わない手を打っても、盤の状態は変わりませんでした。勝負がついたあとは、駒を置けません。

「対局がいつまでも終わらないのでは」という点も確かめました。CPU同士を1,500局、自動で対戦させました。1局の上限は5,000手です。結果は、決着がつかなかった対局が0局でした。一番長い対局で162手、平均は13〜20手です。対局が終わらない問題は、再現しませんでした。

CPUの強さも測りました。アプリには「やさしい」と「つよい」の2つの強さのCPUがあります。つよいCPUは、先読みの「深さ」（何手先まで読むか）の設定で強さが変わります。深さ3のCPUは、やさしいCPUに70%勝ちました。深さ6のCPUは、深さ3のCPUに87%勝ちました。それぞれ300局ずつの結果です。

考える時間は、駒が1つも無い盤で、深さ3が0.0004秒、深さ6が0.0625秒でした。これは、速く動くように最適化して組み立てたときの数字です。開発中に使う組み立て方（Debugビルド）では、これより遅くなります。数字を比べるときは、どちらの組み立て方で測ったかをそろえる必要があります。

見た目では、次のことが分かりました。

文字の大きさ：iPhone の設定で文字を一番大きく（アクセシビリティの XXXL）しても、表示が変わりませんでした。iPhone で文字の大きさを変える機能（Dynamic Type）の設定が、今は画面に反映されていないことになります。画面を撮った画像を比べて確かめました。
色：上に書いたとおり、白い文字とオレンジの組み合わせは読みやすさの基準に届いていません。
iPad：ボタンが画面の幅いっぱいに伸びていました。

まだやっていない確認もあります。盤面を実際に指でタップする確認と、実機での確認です。

まとめ

作りかけのものに手を入れる前は、まず git で今の状態を残しておくと、いつでも戻れます。
自動で作られるファイルは .gitignore で外し、作り直せるファイルでも、無いとビルドできなくなるものは残しておきます。
「たぶんこのくらい」ではなく、テスト・自動対戦・画面の実測で数字を出すと、次に直すところ（文字の大きさ・色・iPadの配置）がはっきりします。

次は、まだやっていない、盤面を手でタップする確認と実機での確認に進みます。

参考にした資料

この記事は、筆者の開発記録をもとにAI（Claude）が下書きし、筆者が確認して公開しています。