本稿はエンタープライズのテクノロジーリーダー向けに執筆され、当初 Wednesday Solutionsのモバイル開発ブログ で公開されました。Wednesdayは、米国のミッドマーケットのエンタープライズ企業が、信頼性の高いiOS、Android、およびクロスプラットフォームのアプリをAI支援型のワークフローを組み込んだ形で出荷できるよう支援するモバイル開発の人材スタッフィング会社です。
失敗したAIモバイルプロジェクトの5つの根本原因――契約を結ぶ前に、それらを見抜く方法。
Gartnerの2024年の「エンタープライズソフトウェアにおけるAI」レポートによると、エンタープライズのモバイルAIプロジェクトのうち4件中3件が、当初の納期を逃します。取締役会に対して最もよく提示される説明は「想定より機能が複雑だった」です。実際の説明は、多くの場合もっと単純です。モバイルベンダーが、提供する能力を持たないままAIの納品に「はい」と答えてしまったのです。本稿では、この失敗パターンの背後にある5つの根本原因を分解し、契約を結ぶ前に確認すべき質問を提示します。
重要な発見
74%のエンタープライズのモバイルAIプロジェクトが、当初の納期を逃している（Gartner、2024）。
5つの根本原因は、ベンダー評価の段階で（作業開始前に）特定できる。
開発ワークフロー内でAIを活用する能力と、AI機能を構築する能力は別のケイパビリティである。双方をふるい分けるには、異なる質問が必要だ。
以下：各根本原因が外からどう見えるのか、そしてそれをあぶり出すスクリーニング質問。
原因1：自社のワークフローにAIツールがない
自社の提供プロセスでAIを使っていないベンダーには、AI機能の作業に対する根本的な問題があります。つまり、経験からそれを推論できないのです。彼らはAI機能を、プロダクトマネージャーが理解するのと同じように理解しています――ドキュメントから概念的に理解しているだけです。デバッグのサイクル、モデルの挙動におけるエッジケース、そしてAIによるシステムを構築・保守してきたことによって発生する運用上のオーバーヘッドについては理解がありません。
これはAI機能の提供において重要です。AIモバイル開発で最も難しいのは、初期の統合ではありません。問題になるのは、その後に起きる失敗です。古い端末では振る舞いが異なるモデル、3G環境で推論呼び出しが800msのレイテンシを追加してしまうこと、テストでは機能する確信度（confidence threshold）が、本番の実ユーザーの5%ではゴミのような出力を生むこと。自社のワークフローにAIツールがないチームは、こうした失敗モードを見たことがありません。一方で、日々の業務でAIによるコードレビュー、AIによるテスト生成、AIによるドキュメンテーションを回しているチームは、同様の失敗を常に目にしてきており、それらを管理する方法も学んでいます。
外から見えるもの：そのベンダーの求人票にはAIツールが明記されていません。エンジニアは、自分たちが使っている特定のAIツールを挙げられず、それがどのように自分たちの仕事を変えたのかも説明できません。あなたのAI機能に関する提案は、非AI機能の提案とまったく同じに見えます――同じ体制、同じ納品マイルストーン、同じQAプロセスです。
スクリーニング質問：「直近にあなたのチームが出荷したリリースについて、どのような手順で進めましたか。ワークフローの中で、どんなAIツールが使われていて、それぞれが何をしているのか教えてください？」AIツールがないチームは、AIコンポーネントが一切含まれない標準的なモバイル提供プロセスを説明するはずです。
原因2：オンデバイスMLの経験がない
モバイルアプリをクラウドベースのAI API（OpenAI、Google Gemini、AWS Bedrockなど）に接続することは、オンデバイスのモデルを提供することとは同じではありません。どんなモバイル開発者でもAPI呼び出しはできます。オンデバイスモデルを出荷するには、モデル選定、端末制約に合わせた量子化、Core ML（iOS）またはTensorFlow Lite / MediaPipe（Android）との統合、バッテリーや熱の管理、モデルが利用できない場合のフォールバック動作、そして数百種類のハードウェア構成にまたがる端末差分をカバーするテスト戦略が必要です。
ほとんどの従来型のモバイルベンダーは、API呼び出しの実装は行ってきました。ですが、実ユーザーがいるエンタープライズアプリに本番のオンデバイスモデルを出荷したところは、ほとんどありません。ケイパビリティのギャップは大きく、それを埋めるには少なくとも12か月の継続的な投資が必要です。
この論点が重要になるケース：ボード（取締役会）の指示に、プライバシーを損なわないAI（健康データは端末外に出せない）、オフライン・ファーストのAI（信頼できる接続がない現場でサービス作業を行う担当者）、低レイテンシのAI（サーバ往復500msが体験を壊してしまうような機能）を含む場合です。その場合、オンデバイスが必須であり、その経験がないベンダーは、取締役会が見える形のスケジュールでは提供できません。
外から見えるもの：そのベンダーは、あらゆるAI機能に対してクラウドAPI方式を提案します。オンデバイスのほうが適しているものにもです。オンデバイスの選択肢を尋ねると、「もっと複雑になる」と説明しますが、その複雑さが具体的に何なのかは言えません。
スクリーニング質問：「本番のiOSまたはAndroidアプリに、オンデバイスのMLモデルを出荷した経験はありますか。どのフレームワークを使い、モデルサイズはどれくらいで、どのような端末テスト方針を実行しましたか？」実経験のあるベンダーは具体的に答えるはずです。経験のないベンダーはクラウドベースの事例に話を切り替えます。
原因3：App StoreのAI審査を切り抜けた経験がない
AppleとGoogleにはAI機能に関する具体的な審査要件があり、2024年から2025年にかけてそれらを強化してきました。Appleは、ガイドライン2.1に基づきAI生成コンテンツの開示を要求しています。医療、法律、または金融に関する推奨をAIで行うアプリには、追加の免責事項（ディスクレーマー）が必要です。プライバシーポリシーは、ユーザーデータがAIシステムによってどのように処理されるかを明示的にカバーしていなければなりません。カメラ、マイク、ヘルスデータなどのセンシティブなAPIにアクセスするオンデバイスモデルを使うアプリは、より厳しく精査されます。
従来型のベンダーで、App Storeの審査にAI機能を提出したことが一度もない場合、審査で差し戻し（リジェクト）が届くまで、こうした要件が存在することを知りません。AI関連の差し戻しに対処して再提出するまでの平均期間は7〜14日です。取締役会で合意されたローンチ日程があるアプリであれば、審査の最初の週に差し戻しを見つけた場合、誰も予算化していない2〜3週間の遅延になります。
外から見えるもの：そのベンダーの提供スケジュールは、「App Storeに提出して終了」になっていて、審査のバッファがありません。App Storeの審査ノートを納品物として言及しません。AIデータ利用の文脈で、あなたのアプリに既存のプライバシーポリシーがあることについて質問していません。
スクリーニング質問：「AI機能をリリースする際に、どんなApp Store審査のコメント（ノート）を提出しますか。また、AI提出における差し戻し率として、これまでにどの程度の数字を見ていますか？」実経験のあるベンダーは、含めている開示文言や、見込んでいる審査期間について説明できます。経験のないベンダーは、審査プロセスはAppleの責任だと言うでしょう。
原因4：AIに対して不適切なアーキテクチャ
AI機能はUI機能ではありません。モバイルアプリにドキュメントスキャン、パーソナライゼーション、異常検知などを追加するには、アプリのアーキテクチャが推論呼び出し、モデルのロード、レスポンスのキャッシュ、そしてAIコンポーネントが利用できないときの円滑なフォールバック（graceful degradation）をサポートしている必要があります。標準的なMVCまたはMVVMアーキテクチャで、それらの考慮がないものはAI対応（AI-ready）ではありません。AI対応にするには、ライブラリを追加するだけではなくリファクタリングが必要です。
従来型のベンダーは、この点を見誤ることがよくあります。彼らは、AI機能をスタンドアロンの追加物のように見積もり、統合を始めてからアーキテクチャ上の問題が露見します。そして、その後のリファクタリングコストを機能のタイムラインに吸収してしまいます。取締役会が耳にする「AIは想定より複雑だった」という説明は、AIそのものというより、そもそもそのアプリがAIを支えるように作られていなかったという、この問題であることが多いのです。
外から見えるもの：そのベンダーの初期スコープに、アーキテクチャ評価が含まれていません。既存アプリがネットワーク障害にどう対応するのか、非同期処理にまたがる状態管理をどうしているのか、オフラインの状況をどう扱うのか――そうした確認をせずに、どんなAI機能が欲しいかを尋ねてきます。
スクリーニング質問：「AI機能をスコープする前に、既存アプリのアーキテクチャについて何を評価しますか？」対応力のあるベンダーは、具体的な確認内容を説明します。たとえば、非同期処理をどのように管理しているか、データレイヤーが整理されているか、オフラインへの対応がどうなっているか、などです。AI機能の提供経験がないベンダーは、技術的なアーキテクチャレビューをせずに要件の聞き取りだけを行うでしょう。
原因5：AI向けの誤った価格モデル
従来型のモバイルベンダーは、AI機能をUI機能と同じように価格設定します。見積もったエンジニアリング工数で課金するというモデルです。しかしこのモデルは、AI業務では成り立ちません。AI機能のコストのうち2大要素は、エンジニアリング工数ではないからです。主なコストは、推論コストとイテレーションコストです。
推論コストとは、モデルが反応するユーザー操作が発生するたびに、そのモデルを動かすためにかかる費用です。日次アクティブユーザーが100,000人で、セッションごとに2回推論が発生するクラウド型AI機能の場合、インフラコストは、ローンチ後60日以内にエンジニアリングコストを上回る可能性があります。スコープ時点で推論コストを見積もらないベンダーは、不完全な見積りを出していることになります。
イテレーションコストとは、初期の統合後にかかるエンジニアリング時間です。閾値のチューニング、プロンプトの調整、本番データでの再学習、モデルドリフトへの対応などが含まれます。AI機能は、UI機能とは異なり、ローンチ後も継続的なエンジニアの関与が必要です。このため、AI機能に対する固定価格の見積りでは、それを織り込めません。
外から見えるもの：AI機能のベンダー見積りは、単一の明細項目です。推論コストの見積りはなく、ローンチ後の保守予算もなく、モデルの再学習に関する前提もありません。見積りの形式は、あなたにこれまで送ってきた他のあらゆる機能見積りと同じです。
スクリーニング質問：「推論およびローンチ後の保守を含めた、AI機能の総コストはどのように見積もりますか？」AI提供経験のあるベンダーは、あなたの利用量に基づく推論コストのモデルと、ローンチ後最初の2四半期をカバーする保守予算を提示します。
AIワークフローとAI機能提供の違い
これらは別の能力です。開発のワークフローでAIを活用するベンダー（AIコードレビュー、テスト生成の自動化、AIのリリースノートなど）は、そうでないベンダーよりも適切な選択です。実務としてAIを理解していることを示すからです。ただし、それは自動的に「あなたのアプリでAI機能を構築できる」ことを意味しません。
AI機能を作るには、上記の5つの能力が必要です。AIツールの活用経験、端末上でのML（オンデバイスML）の経験、App StoreにおけるAIレビューの経験、アーキテクチャ評価のスキル、そしてAI向けの価格モデルです。ワークフローでAIツールを使うことだけなら、これらは不要です。ワークフローAIでは強いが機能AIでは弱い、あるいはその逆、というベンダーはあり得ます。
ベンダー評価では、両方について聞いてください。別々にです。質問は異なり、これらを混同することが、企業が「AIツールの提供は約束通りだったが、AI機能の提供は約束通りではなかった」という結果に終わる理由の1つです。
AI提供能力でベンダーを見抜く方法
対応可能なベンダーとそうでないベンダーを分ける5つの質問：
1つ目。「最後に本番アプリへリリースしたAI機能について、説明してください。その機能は何で、App Storeのレビューにはどう対応し、ローンチ後はどのように運用しましたか？」モデル名またはタイプ、レビュー戦略、ローンチ後のサポート体制といった具体性を探します。
2つ目。「推論と継続的な保守を含めた、AI機能の総コストを見積もるためのプロセスは何ですか？」ユーザー単位の推論コスト見積りと、ローンチ後の保守に割り当てる体制（配分）を探します。
3つ目。「AI機能をスコープする前に、アプリのアーキテクチャをどう評価しますか？」要件の聞き取りだけでなく、名前付きのアーキテクチャレビュー手順があるかどうかを確認します。
4つ目。「端末上での推論のためにCore MLまたはTensorFlow Liteを使ったチームの経験はどの程度ですか？」一般的な“できる”という主張ではなく、具体的にリリースされた実例を探します。
5つ目。「AI機能を含むリリースを提出する前に、App Storeの審査準備として何を行いますか？」開示文言、プライバシーポリシーのレビュー、レビュー期間にバッファを持たせるためのタイムラインを探します。
この5つすべてに具体的な回答ができるベンダーには、本物のAI提供経験があります。話を逸らす、一般論にする、あるいはAPI連携を“AI機能”ではなく実績として提示してくるようなベンダーには、それがありません。
さらに深掘りしますか？関連ツール、事例、意思決定のためのフレームワークを含む完全版はmobile.wednesday.is/writing/why-traditional-mobile-vendors-fail-ai-feature-delivery-2026にあります。
