iPhone向けのテレプロンプターアプリがAppleの審査を通過し、App Storeで公開されました。このアプリはすべて、AnthropicのコマンドラインAIコーディングツールであるClaude Codeで作られています。画面設計、ビルド、テスト、画像素材、そしてApp Storeへの申請まで、すべてこのツールを通じて行われました。ただし、魔法のようなプロンプト一つで完成したわけではありません。215回のプロンプトと120回のコミットを重ね、部品を一つずつ作っては、変更のたびに実機で確認しています。際立つ教訓は、AIがコードを書く速さよりも、それを取り巻くフィードバックループにあります。実機でテストすること、そしてバグが手強いときは推測を求め続けるのではなくデータを集めることです。

アプリでできること

このアプリはテレプロンプター、つまり話し手がカメラを見ながら原稿を読めるようにするツールです。開発のきっかけは、既存のテレプロンプターアプリへの不満でした。画面がごちゃごちゃしている、操作ボタンが小さい、あるいは文字がレンズから離れすぎていて自然なアイコンタクトを保ちにくい、といった問題です。そこで、読み取りラインをフロントカメラの切り欠きのすぐ横に置きました。こうすると、完成した映像を見る人には、話し手がまっすぐ自分を見ているように感じられます。

主な機能は次のとおりです。

  • 原稿を書くか読み込み、固定された読み取りラインの下でスクロールさせる
  • フォント、行間、余白、スクロール速度を調整でき、文字のテーマもカスタマイズ可能
  • ガラス式のテレプロンプター機材に合わせて表示を反転
  • フロントカメラまたはリアカメラで録画
  • ハードウェアのリモコンで再生を操作
  • Apple Watchのコンパニオンアプリから開始、一時停止、速度変更
  • アカウント不要、クラウド保存なし、分析やテレメトリーもなしで、すべてを端末内に保存

一発のプロンプトではなく協働で

項目 数値
Claude Codeに送ったプロンプト 215回
Gitのコミット 120回
自動UIテスト 25件
Apple Developer Programの費用 年額$99

App Storeの審査を通過しなければならない完成度の高い一般向けアプリが、プロンプト一つで出来上がる可能性は低いでしょう。このプロジェクトでは、Claude Codeを対話を続けるエンジニアリングのパートナーとして扱いました。部品を作り、その変更をすぐにテストし、次へ進むという流れです。一度の依頼で出荷できる完成品を期待するのは、現実的ではないようです。

実機のiPhoneでループを回す

ワークフローの柱は、ターミナルから動かす自動ループでした。Claude Codeがコードを変更するたびに、同じ手順が実行されます。

  1. Claude Codeがソースコードを編集する。
  2. xcodebuildでアプリをコンパイルする。
  3. xcrun devicectlで、接続したiPhoneにビルドをインストールする。
  4. iPhone上でアプリを起動し、変更点をすぐに手で試せるようにする。

MacのiOSシミュレーターがすぐそこにあるのに、なぜわざわざ実機を使うのでしょうか。この種のアプリで重要な点こそ、シミュレーターでは見えないからです。タップ領域が十分な大きさか、触覚フィードバックが適切か、原稿が読みやすいか、アイコンタクトの角度が合っているかは、スマートフォンを手に持って初めて判断できます。後の節で触れるように、シミュレーターは深刻なパフォーマンスのバグも覆い隠していました。

このプロジェクトは、より大きな教訓も示しています。AIコーディングエージェント、つまりコードを編集し、自らコマンドを実行して作業を進めるAIは、コードを返すだけの文章生成ツールとして扱うよりも、ビルドとデプロイが絶えず回るループに組み込んだときのほうが、はるかに役立つようです。

光る矢印がコードの変更をノートPCからケーブル経由で手に持ったスマートフォンへ運び、再びノートPCへ戻る様子

▲ 実機でのビルドとテストのループ

Appleの枠内で、コードで直接デザイン

このプロジェクトでは、Figmaで画面のモックアップを作り、それをSwiftで作り直すという通常の手順を省きました。代わりに、Appleのデザインキットにある標準コンポーネントを使い、Claude Code上で直接画面をデザインしています。標準のiOSコンポーネントに徹したことは、有益な制約として働きました。アプリはネイティブらしい一貫した使い心地になり、独自のデザインシステムを一から作る必要もありませんでした。

それでも、細部を詰めるには何度かの手直しが必要でした。操作ボタンは、変化するカメラの背景の上でも、縦向きと横向きのどちらでも、さらにDynamic Islandの周りでも、読みやすく使いやすい状態を保たなければなりません。

ここで人間の役割がはっきりします。Claude Codeは頼まれたコードなら何でも書きますが、それ自体がセンスや判断力を備えているわけではないようです。デザインの感覚、批判的なレビュー、明確なアーキテクチャ上の制約は、人間が与える必要があります。オンボーディング、設定メニュー、ナビゲーションのように、よくあるものの扱いが難しいパターンについては、実際のアプリの画面とフローを検索できるライブラリを使い、リリース済みのアプリがどう処理しているかを調べてからプロンプトを書く方法を取りました。

シミュレーターでは起きなかったフリーズ

開発中、原稿をタップして開こうとすると、iPhone上でアプリが完全にフリーズする問題が起きました。シミュレーターでは、同じ操作が遅延なくスムーズに動いていました。

Claude Codeの最初の対応は推測でした。TextKitの同期的なレイアウト描画を原因とする説も出ましたが、どの推測でも問題は直りませんでした。流れを変えたのは証拠です。Claude Codeは独自のパフォーマンスロガーを書いてアプリに組み込み、devicectlを使って、接続したiPhoneから実行時のログを取り出しました。

ログを見ると、原因は明らかでした。テレプロンプター画面が51.1秒間に11,645回も作り直されていたのです。画面は初期化のたびに、表示のデフォルト設定を保存していました。その保存がSwiftUIのデータクエリを無効化し、クエリの変化が画面を再構築し、再構築された画面がまたデフォルト設定を保存するという循環です。この循環を断ち切ると、フリーズは完全に解消しました。

この教訓は、おそらくこのアプリだけにとどまりません。AIエージェントがバグについて誤った説明を繰り返すなら、次の推測を求めるのはやめましょう。狙いを絞った診断用ログをコードに組み込ませ、端末が実際に何を報告しているかを読むことです。

抽象的なログの行に虫眼鏡を当てると繰り返すループが見つかり、その横に画面がフリーズしたスマートフォンがある

▲ 診断用ログで見つけた終わりのない再構築ループ

壊したところを見つけるテスト

機能が増えるにつれ、ある箇所の変更が別の箇所を知らないうちに壊すことがあります。こうしたリグレッションを防ぐため、Claude Codeは原稿の作成、名前の変更、並べ替え、表示の調整をカバーする25件の自動UIテストを生成しました。

このテスト群は欠かせない存在になりました。後に原稿の保存方法を変更した際、削除と名前変更のフローにまたがる13件のテストが一度に失敗し、根本原因を簡単に突き止められたのです。修正後は、25件すべてのテストが再び通りました。ただし、テストがすべて通ったからといって、バグのないアプリだという証明にはなりません。カメラのハードウェア、センサー、端末の物理的な回転が関わる部分では特にそうです。

App Storeの審査を通過するまで

配布にはApple Developer Programへの登録が必要で、費用は年額$99です。その後、Claude Codeがリリース作業の多くを引き受けました。リリースビルドの作成、さまざまな画面サイズのシミュレーターでのマーケティング用スクリーンショット生成、製品説明文の下書きです。

最初の申請は、Guideline 2.1(Information Needed)により却下されました。Appleは、ハードウェアの権限とリモコン機能を把握するため、実際に動作するデモ動画に加えて、アプリの使い方と依存している外部要素についての詳しい回答を求めました。

そのデモ動画のアップロードでも壁に当たりました。画面録画は399MBのHEVCファイルで、App Store Connectには大きすぎ、受け付けられないコーデックでもあったのです。Claude Codeはffmpegのコマンドを書いて実行し、動画を縮小したうえで、広く対応している動画形式のH.264に変換しました。これでファイルは7.4MBになりました。Appleはこのファイルを受け付け、続いてバージョン1.0を承認し、アプリは公開されました。

段階 結果
最初の申請 Guideline 2.1で却下、デモ動画と回答を要求
デモ動画のアップロード 399MBのHEVC録画を拒否
ffmpegでの変換 7.4MBのH.264ファイルを受理
最終判断 バージョン1.0を承認し公開

このワークフローから取り入れたいこと

このプロジェクトからは、指示する人が要件を具体的に保ち、実機で徹底的にテストする限り、Claude Codeがデザインのアイデアと本番のソフトウェアとの距離を大きく縮められることがうかがえます。自分のiPhoneアプリで同じことを試すなら、次の点から始めましょう。

  1. まず実機のループを作る。エージェントにxcodebuildでコンパイルさせ、xcrun devicectlでインストールさせて、すべての変更が実際のiPhoneに反映されるようにする。
  2. Appleの標準コンポーネントを使ってコードで直接デザインし、オンボーディングや設定のような複雑な画面は、プロンプトを書く前に実際のアプリのフローを調べる。
  3. エージェントによるバグの見立てが外れ続けるときは、診断用ログを追加させ、端末からログを取り出す。
  4. 自動UIテストを早めに書き、データの保存のような共通ロジックを変更したときにリグレッションがすぐ表に出るようにする。
  5. App Reviewに提出するデモ動画はH.264でエンコードし、アップロード上限より小さく圧縮しておく。

センスと最終的な判断は、今も担当する人間が担います。一発でアプリを生成する道具ではなく、ビルドとテストを密に繰り返すパートナーとして扱えば、AIコーディングエージェントは、一人の人間が完成したネイティブアプリをApp Storeに出す手助けができそうです。