Claude Codeでアプリ開発に挑戦してみた—オセロ・チェスからiOSアプリまで
はじめに
Claude Codeを使ってアプリ開発に挑戦中です。
完成にはまだ程遠いですが、ここまでの道のりが面白かったので途中経過として記録しておきます。
Step1:オセロゲームを作ってみた(HTML版)
最初はシンプルにオセロゲームをHTML版で作成してみました。3回ほどのリテイクで完成。難易度を3段階で設定してもらいましたが、そもそも自分がオセロをちゃんとやったのは中学生の頃が最後くらいで、スマホが出始めた頃に試しにアプリでちょっと触った程度。なので最弱レベルでも全然勝てないのが地味に悔しいです(笑)。

Step2:チェスゲームを作ってみた(HTML版)
次にチェスゲームに挑戦。とりあえず動くものは完成しましたが、駒のデザインが敵陣は黒と白、自陣は白枠だけになってしまったので修正したいところです。
そもそもチェス自体のやり方をあまり知らないので、チュートリアル機能も追加したいと考えています。ただ、何度か修正を重ねているうちにClaude Codeのセッション使用量がオーバーしてしまい、現在修正は一時保留中です。

Step3:Xcodeと連携してiOSアプリを作ってみる
ここからが本番です。Xcodeと連携してiOS/iPadOS用のアプリ開発に挑戦することにしました。
何を作るか
特に作りたいものが思い浮かばなかったので「今何が欲しいか」を考えてみたところ、外出先のiPadからキーマップを変更できたら便利だと思い、ZMK対応のキーマップ編集アプリを作ることにしました。今思うと、初手でいきなり大掛かりなものを選んでしまったなと薄々感じています(笑)。
Claude Codeとの連携方法
最初はXcodeを開きながらClaude Codeに操作を聞きつつ進めていましたが、修正のたびに「この行を探してこの内容に差し替えて」という作業が面倒でした。Claude Codeに相談したところ、Xcode側にClaudeエージェントを追加する方法を教えてもらい、途中からその方法に切り替えました。
さらに作業を効率化するために依頼内容を以下のように整理しました。
まず全体の構成を把握する
修正が必要な箇所があれば修正する
終わったら動作確認の手順を教える
途中から追加した指示:
修正箇所はコピペで差し替えられるように完全版(全文)で出力する
さらに「差し替え場所がわからないので直接修正反映して」とお願いしたら対応してくれた
ここまでくると、あとはエラーが出たらエラー内容を貼り付けて修正してもらうだけ。ほぼ半自動でコードが書かれていく様子はただただすごいの一言です。
開発の条件
Claude Codeから提示された主な条件は以下の通りです。
iOS 16以上をサポート対象にする
接続方法はBluetooth接続のみ(USB接続は追加対応が必要なため今回はBluetoothのみ推奨)
現時点での進捗
ここ3日ほど「動かしてはストップ」を繰り返しながら開発中です。Claude Codeはproプランのため1日あたりの使用量に上限があり、上限に達したら数時間待って再開という流れを繰り返しています。一番最初なんだからもっと簡単なアプリから始めればよかったと思いますが、後の祭りです(笑)。
現時点の進捗はおそらく全体の1/4ほど。それでも以下の機能はすでに完成しています。

📋 コア機能
キーマップ作成・編集・削除
レイヤー管理(追加・削除・移動・リネーム)
キーバインディング編集(9種類のBehavior対応)
ファイル永続化(JSON形式)
未保存変更の検知
📊 データ管理機能
キーマップ名の編集・複製
JSONエクスポート/インポート
リアルタイム検索・フィルター
⚡️ エディター機能
レイヤー名の変更(右クリック → Rename)
キーのコピー&ペースト(レイヤー間も可)
Undo/Redo(最大50ステップ)
キーボードショートカット(⌘Z、⌘⇧Z、⌘S)
🎨 UI/UX
macOSネイティブデザイン
ダークモード完全対応
コンテキストメニュー・スワイプアクション
カラーコーディング(Behaviorタイプ別)
今後追加予定の機能
Bluetooth LE接続によるデバイスとの通信・キーマップ読み書き
マクロ・コンボ・タップダンス対応
キーのドラッグ&ドロップ
カスタムキーボードレイアウト定義
やってみて感じたこと
自分でプログラミングができる人が改めてすごいと思いました。
Claude Codeがあれば非エンジニアでもアプリ開発に挑戦できますが、エラーの内容を理解したり方向性を判断したりする部分はまだまだ人間が必要です。
そしてもう一つ気づいたのが、作業の頼み方です。
「これ全部やって」とまとめて依頼するのではなく、「◯◯の部分の作業をやってみて」と作業単位で依頼する方がうまくいきます。理由は2つあって、ひとつは余計な使用量を消費しないこと、もうひとつは今どの工程にいるのかが自分でも把握しやすくなることです。
実際の進め方としては、ひとつの作業と動作確認が終わったら「次に何をやればいいか教えて」と聞いて、提案された選択肢の中から「じゃあ次はこれをお願い」と依頼する流れで進めています。
もしその時点のテストやビルドでエラーが出たらエラー内容を貼り付けて「原因の確認と修正をお願い」と依頼すればその対応もやってくれます。その際、「どのファイルの何行目が〜」などと具体的に指示する必要がないのもすごいところです。エラー内容から原因を探って、適切な箇所を修正してくれるのでとても優秀です。
Claude Codeの動画や他の方の記事で**「部下をマネジメントするみたいに」**という表現を見かけていましたが、実際にやってみてその感覚がリアルに理解できました。
完成したらまた報告します!
