【AI×モバイルアプリ開発のリアル】BLOCKSMITH&Co.が明かす「AIが得意なこと、AIに決して任せてはいけないこと」

生成AIが一般化し、「AIがアプリを全部作ってくれるのでは？」という期待が高まっています。しかし、実際にAIサービスを活用してモバイルアプリを開発した現場では、異なる現実が見えてきました。

AIは確かに設計・調査・定型作業を自動化してくれます。しかし、アプリの開発が進むにつれ、「AIが知識として知っていること」と「人が経験から判断すべきこと」の境界が浮き彫りになっていきました。

AIが担えるのはあくまで「知識の自動化」であり、アプリを壊さず動かし続けるための無数の「経験的判断」までは、現時点では再現できません。

本記事では、株式会社BLOCKSMITH&Co.のエンジニアがAIを活用して開発した『フリくじ』アプリの事例をもとに、AIが貢献した領域、AIが引き起こした具体的な失敗と限界、そしてそれらを乗り越えた工夫を詳しく解説します。

AIを活用してエンジニア1名×2か月でアプリリリース

本プロジェクトは、

• 「人員・資金が限られた状況で新規事業企画を素早く開発したい」というビジネス上のニーズ
• 「AIエージェントを活用することで、開発を短期間で完了できるか実案件で検証したい」という技術的目的

からスタートしました。

開発したのは、歩くだけで無料でくじが引けるポイ活アプリ『フリくじ』です。

『フリくじ』は日常の通勤や散歩といった歩行活動を、気軽な“運試し”に変えることができるポイ活アプリで、

• 歩数に応じて「スタンプ」を獲得
• スタンプを消費して“くじ券”を発行
• 週2回の抽選でアプリ内通貨「CHIP」が当たる
• CHIPは10CHIP＝1円分として各種ポイント・電子マネーと交換可能

という特徴を持ち、歩数データとロト6抽選を組み合わせたヘルスケア要素を持つミニゲームアプリ（iOS / Android対応）となっています。

開発体制とスケジュール

• 開発者1名、企画1名、QA数名の極小チーム
• 開発開始：2025/5/1 → β版：6/25 → 正式版：8/19
• 技術構成：Flutter / Python（Flask） / PostgreSQL / AWS
• AI利用：Claude 4、Gemini 2.5 Pro を中心に ChatGPT無料版も併用
• 自動修正ツール（Cursor / Claude Code）は、過剰修正による品質低下のため不採用
• サーバーなどの運用費は月数万円に抑制

驚異的な開発実績とKPI

AIの活用により、1人開発としては異例の成果を達成しました。一般的なモバイルアプリ開発（開発期間3〜6ヶ月、人員2〜3名、画面数10〜15程度）と比較して、本プロジェクトは「2ヶ月・1名・30画面以上」という高い生産性を実現しました。

KPIの例

• Flutter 画面クラス100件、Python クラス50件、DBテーブル4つ、3環境構築
• 修正・改善タスク 112件
• TestFlightビルド 15回（3日に1回ペース）
• リリース遅延ゼロ
• 総開発コスト：一般的相場の半分以下

しかし、これは「AIを使ったから自動的に短縮できた」という単純な話ではありません。

裏では、AIの限界と失敗に何度も直面し、それらのリカバリーに多くの時間を費やしました。

AIが貢献した領域：知識の自動化で作業を削減

AIは、知識集約型・定型的な作業 において絶大な効果を発揮しました。

【実装面での貢献】

AIは、明確な仕様が決まっている部分のコード生成において、開発者の作業量を劇的に削減しました。

• 画面テンプレートの自動生成: 一覧画面、詳細画面、設定画面といった汎用的なUIの雛形を即座に生成。（手作業比70%減）
• データモデルの自動生成: バックエンド（Flask）とフロントエンド（Flutter）間でやり取りするデータモデル（JSONの型定義クラス）を自動作成。型整合の検証も含め。（手作業比90%減）
• テストコード・データの生成: 正常系・異常系のテストコードや、テスト用のダミーデータを自動生成。（手作業比60%減）
• ドキュメント作成支援: README.mdのたたき台作成やAPI仕様書のドラフト作成。（手作業比80%減）
• 技術調査の代行: Flutterのパッケージ選定比較レポートや、最新のベストプラクティスを要約。（手作業比50%減）

【運用面での貢献】

リリース後の運用フェーズにおいても、AIは調査・分析タスクで開発者を強力にサポートしました。

• エラーの一次調査: AWS CloudWatchの難解なエラーメッセージやスタックトレースをAIに渡すことで、原因特定と修正方針を即座に解析。
• SDKのマニュアル作成: ヘルスケア連携（Apple HealthKit / Google Fit）など、ドキュメントが膨大な外部SDKの仕様をAIに調査させ、日本語の簡易マニュアルを作成。
• インフラコストの最適化: AWSの最新設定や料金体系を調査させ、コストパフォーマンスの良いインフラ設計（例：Lambdaのメモリ割り当て最適化）を提案。

このようなAIの貢献により、初期構築の工数を局所的に70〜90％削減できました。AIが定型処理を肩代わりすることで、開発者は「この機能は本当にユーザーに価値があるか」といった、より重要な設計意図やUXの検証に集中することが可能となります。

しかし、これらの「工程ごとの効率化率（最大90%減）」と、「プロジェクト全体の手作業削減率（約40%減）」には大きな差が生じました。AIの出力したコードの検証・修正に多くの手戻りが発生したためです。

AIの限界と失敗事例：”現時点”での「開発経験」の欠如

AIが失敗する根本原因は、知識不足ではなく 「開発経験の欠如」 にあります。

少なくとも現行のモデルでは、プロジェクト全体の依存関係や設計思想を考慮した一貫性のあるコードが書けません。

具体的な失敗例

• UI崩壊: デザイン画像からの自動生成で、実機ではレイアウトが破綻
• アーキテクチャ崩壊: 既存構成を無視し類似フォルダが乱立、1,500行の巨大ファイル生成
• デグレ多発: 直前の文脈のみ見て修正し、他機能への影響を考慮せず
• パフォーマンス無視: 過剰な状態管理コード、無限リロードループでバッテリー消費
• 陳腐化情報: 実画面と乖離した旧AWSコンソールUI仕様に基づく操作手順で1日浪費、非推奨SDK提案で3日浪費、証明書設定誤案内で7日損失

これらは「設計しかしたことがない人」が見逃す問題です。現時点でAI時代にまず求められるのは”壊れないコードを書くことの難しさを知っている経験豊富な開発者”です。

【AIが最も苦手な領域：デプロイとモバイルリリース】

• デプロイ（バックエンド）: dev/stg/prod 3環境の構築において、VPC、IAMロール、Lambdaメモリ最適化など、実運用を前提とした設計は現状のAIでは困難。
• モバイルリリース: 署名・証明書・TestFlight配布は自動化不可。環境ごとの証明書管理と自動ビルドスクリプトとの整合性確保は、現段階では人間が最終制御する必要がありました。

これらは、現時点のAIではほぼ自動化が不可能でした。

開発難易度マトリクス：「難易度 × 経験 × AI理解度」で決まる開発速度

AIの影響度を整理すると、以下の2軸が重要であることがわかりました。

• 開発知識レベル（下図 縦軸） … 実装経験、設計・依存関係の理解
• AIサービス理解度レベル（下図 横軸）… AIの癖・指示方法の理解

この2軸が「開発達成速度」（マトリクス図では明るい色ほど高い）にどう影響するかを、アプリの難易度別に3段階で示します。

【レベル1：単純な開発（LP, GAS, 業務アプリ）】

単一機能の軽量な構成です。この領域では、「開発知識レベル」の影響は比較的小さく、「AIサービス理解度レベル」を上げる（＝AIへの指示がうまくなる）ほど、開発達成速度は素早く向上します。

【レベル2：中規模アプリ（データ通信あり）】

状態管理や複数API連携を含む、一般的なアプリです。この領域では、「AI理解度」と「開発知識レベル」の両方が求められます。どちらかが欠けても、開発速度は伸び悩みます。

【レベル3：大規模アプリ（フル機能）】

本プロジェクトの「フリくじ」のように、複数サービス（AWS）や外部SDK（ヘルスケア）と複雑に連携するアプリです。

「開発知識レベル」が低い（0〜3）ままだと、たとえ「AIサービス理解度レベル」を最大（10）にしても、開発達成速度はほぼゼロ（0.0〜4.6）のままであるということを上記マトリクスにて示しています。

これは、AIが生成したコードの依存関係を人間が管理できず、前述した「デグレ多発」や「構成崩壊」によってプロジェクトが必ず破綻するためです。AIに丸投げするだけでは、複雑なアプリは（少なくとも現行の技術レベルでは）絶対に完成しません。

AIの「罠」を乗り越えた実践的工夫

• 4段階プロンプト: ①仕様策定 → ②概要提示 → ③AIからの質問確認 → ④コード生成。認識ズレを早期修正。
• ツール使い分け: 創造的タスクはClaude 4、正確性重視はGemini 2.5 Pro。
• 固定プロンプト: 「過剰なデータ読み込みはコスト増大につながる」等、AIの悪癖を抑制。
• アーキテクチャ遵守: ファイル命名規則、行数上限を厳格化。違反時は即リファクタリング。
• 小さくリリース: 週1回TestFlight配布（全15回）で不具合を早期発見。

未来展望と実践的Tips

AI進化により、将来的にはAI自身が「開発経験」を内包し、マトリクスの様相も変わる可能性が非常に高いです。

しかし現時点では、AIが生成したコードを理解し制御できる開発経験者が不可欠です。AIを使う開発は「人がAIを育てながら制御する”過渡期”の開発」なのです。

まとめ：AIは強力だが万能ではない。だからこそ“AI×人間”の開発が最適解になる

本プロジェクトを通じて最も強く実感したのは、AIが「開発のすべてを代替する未来」はまだ遠いという事実でした。

AIは膨大な知識を即座に提示し、スクリプトやUIの雛形を高速に生成し、一定の定型作業を驚くほど効率化します。しかし同時に、AIは開発現場で必要とされる“経験に基づく判断”や“コンテキストを踏まえた最適解の選択”、そして“アプリ全体の整合性を保つ視点”を持ち合わせていません。

今回のアプリ開発も、表面的には「AIを使ったから速かった」ように見えますが、実際には以下のような要素が成功を支えました。

• AIの出力を理解し、正しく軌道修正できる“人間の判断力”
• 非連続に現れるエラーやデグレへの迅速な対応
• プロダクト観点での優先順位付けと仕様決定
• スケジュール管理、品質担保、SDKやOS仕様の最新知識

これらは、現時点ではAIが代替できない領域です。

しかし逆に、AIが得意とする「知識集約的な作業」をうまくプロジェクトに組み込むことで、開発者1名 × 2か月で30画面規模のアプリを完成させるという、従来では考えられないスピードを実現しました。

つまり、重要なのは「AIか、人か」という二項対立ではありません。

これからのモバイルアプリ開発は、

• AIが“知識と反復作業”を担い、
• 人が“判断と責任領域”を担う、
• その二者が補完し合う新しい開発モデル

へと確実に移行しつつあると言えます。

AIを上手く使いこなすことは、開発の省力化だけでなく、限られたリソースでも高品質なプロダクトを素早く市場へ届ける力へとつながります。

一方で、AIの特性を誤解したり、万能感を過信したりすると、プロジェクト全体が容易に崩壊しかねません。

現実の開発現場では、AIは「魔法の杖」ではなく、正しく扱えば劇的な生産性向上をもたらす“協働パートナー”です。

本記事で紹介した成功と失敗の両面の知見が、これからAI活用を検討する企業や開発者にとって、実践的なヒントになれば幸いです。