外注の前に、まず動くものを自分の手元で作れないか。この検証は、その問いに対する答えです。
AIコーディングツールだけで、企画から実装、ビルド、そして実機のiPhoneへのインストールまでを1日で通しました。費用は0円です。
この検証の概要
検証日 | 2026年6月1日(1日で完了) |
|---|---|
やりたかったこと | AIコーディングだけで企画・設計・実装・ビルド・実機導入までどこまで通せるか検証する |
技術スタック | Expo SDK 56 / React Native 0.85 / TypeScript / expo-sqlite / Xcode 26.5 |
成果 | 単一ファイル(約1,600行)でMVPを実装し、実機へRelease版を単体インストール |
費用 | 0円(無料Apple ID・ローカルビルド) |
状況 | 完了(Phase 1 MVPの実機導入まで到達) |
結論:詰まるのはコードではなく環境
この検証で最も明確に分かったことです。
環境差分(日本語パス・署名・Developer Mode)が主な壁で、コード自体より周辺がボトルネックでした。
記録の中核ループ(開始 → 種目追加 → セット記録 → 完了 → 履歴)の実装は素直に通りました。SQLiteでの永続化、都度保存、履歴集計まで一気通貫です。
止まったのは、すべてネイティブアプリ特有の周辺工程でした。
詰まりポイント①:日本語フォルダ名でビルドが失敗
最も時間を取られた問題です。
日本語フォルダ名でiOSネイティブビルドが失敗しました。Appleのツールチェーンはマルチバイトパスに弱いためです。
技術的な原因も特定できています。React Native 0.85のprebuilt artifactsはローカルパスを file:// URIに変換するため、日本語が混ざると bad component で落ちます。
対処はフォルダ名の英語化(ASCII化)でした。リポジトリを移設せず、パスだけをASCIIにすることで根治しています。
教訓は明確です。モバイル系プロジェクトは最初からASCIIパスで作る。
日本語のフォルダ名は日常的に使いますが、ネイティブビルドが絡む領域では避けるべき習慣になります。
詰まりポイント②:署名がターミナルから通らない
次の壁は、コード署名です。
ターミナルからの署名が errSecInternalComponent で失敗しました。原因はキーチェーンの鍵アクセス権限です。
解決の手順が実用的です。
Xcodeから一度Runして署名を「常に許可」しておくと、以降はターミナルからの署名も通過します。
つまり実機の初回ビルドだけGUIで行い、その後はコマンドラインに戻るという進め方です。全部をコマンドラインで完結させようとすると、ここで止まります。
詰まりポイント③:Developer Modeとビルド種別
- iOS 16以降は実機開発に端末側「デベロッパモード」が必須(有効化して再起動が必要)
- dev buildはMac側のMetroが必要。外出先での単体利用にはRelease ビルド(JS内蔵)が必要
2つ目は用途に直結します。開発中の確認と、実際に持ち歩いて使うことでは、必要なビルドが違います。この検証では実機常用のためRelease ビルドを採用しました。
あわせて、コマンドの落とし穴も記録されています。引数が正しく渡らず、実機を指定したつもりがシミュレータで起動してしまうケースがありました。
無料Apple IDの制約
コスト0円で実現できた一方、制約もあります。
無料Apple IDではアプリが7日で期限切れになります。切れたら同じコマンドで再インストールする運用です。
常用や配布にはApple Developer Program(年99ドル)が必要になります。
「試す」目的なら0円で足ります。継続利用や他人に配る段階で、初めて費用が発生する構造です。
PoCを内製化する価値
この検証の意義として整理されている点です。
外注前のPoCを、追加費用ゼロで実機まで検証できました。技術選定や要件の妥当性を、実物で確認できます。
企画書やモックで判断するのと、実際に自分のスマホで使ってみるのとでは、分かることが違います。使ってみて初めて「この機能は要らない」「これが足りない」が見えます。
実際、この検証でも仕様と実装の突き合わせレビューを行い、フィードバックを受けて記録UXを改修しています(一時保存・履歴の再編集・休憩時間のホイール選択)。
技術選定の判断
実装上の判断も記録されています。
判断 | 理由 |
|---|---|
CocoaPodsを採用 | メンテナンスモード入りだが、Expo SDK 56の |
リポジトリを移設せずフォルダ名だけ英語化 | マルチバイトパス問題の根治 |
Release ビルドを採用 | 実機常用のため(Metro依存のdev buildでは外で使えない) |
1つ目は現実的な判断です。「将来的に非推奨」でも、現時点のツールチェーンが前提としているなら使うしかありません。移行はツールチェーン側の課題として切り離しています。
残っている課題
- Phase 1完了条件のうち2点が未達(前回実績の参照、種目別の推移グラフ)
- 無料枠のため7日でアプリが失効する(常用にはApple Developer Program + EAS Buildが必要)
横展開できること
この検証で得られたのは、アプリそのものより手順の型です。
- 同じ手順で他のモバイルPoCを内製化できる(環境構築・署名・実機導入の型ができた)
- 受託前の「動く検証機」を提示する材料になりうる
一度通した工程は、次からは詰まりません。特に署名まわりは、最初の1回を越えられるかどうかが分かれ目になります。
よくある質問
AIだけでネイティブアプリを作れますか?
実機導入まで到達できました。ただしコード実装より、環境差分(日本語パス・署名・Developer Mode)のほうがボトルネックになります。
ビルドが失敗します
フォルダパスに日本語が含まれていないか確認してください。Appleのツールチェーンはマルチバイトパスに弱く、prebuilt artifactsのURI変換で落ちます。モバイル系プロジェクトは最初からASCIIパスで作るのが確実です。
ターミナルから署名が通りません
Xcodeから一度Runして「常に許可」を選んでください。以降はターミナルからの署名も通過します。初回だけGUIを使い、その後はコマンドラインに戻る進め方が現実的です。
費用はかかりますか?
自分用に試すだけなら0円です。ただし無料Apple IDではアプリが7日で失効します。常用や配布にはApple Developer Program(年99ドル)が必要です。
まとめ
- AIコーディングだけで企画から実機導入まで1日で到達(費用0円)
- 詰まるのはコードではなく環境。日本語パス・署名・Developer Modeが主な壁
- モバイル系プロジェクトは最初からASCIIパスで作る
- 署名は初回だけXcodeでRunして「常に許可」すれば、以降はコマンドラインで通る
- 持ち歩いて使うにはRelease ビルド(JS内蔵)が必要。dev buildはMac依存
- 無料Apple IDは7日で失効。試す目的なら十分、常用には有料プログラムが必要
- 得られたのはアプリより環境構築・署名・実機導入の型
外注や本格開発の前に、動くものを手元で確かめられると判断の精度が上がります。実際に使ってみて初めて分かることは、企画書には書けません。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業の開発内製化とAI導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。
