この文章はエンタープライズ・テクノロジーのリーダー向けに書かれ、もともとはWednesday Solutions mobile development blogに掲載されました。Wednesdayはモバイル開発の人材/体制を支援する会社で、米国のミッドマーケット企業が、AIを組み込んだワークフローによって強化された信頼できるiOS、Android、クロスプラットフォームのアプリをリリースできるよう支援しています。
5つの失敗パターン、それぞれが実際にはどのように現れるのか、そして90日間の猶予が閉じる前にそれらを防ぐ方法。
取締役会（ボード）が義務付けたモバイルAIプロジェクトの70%は、発表された四半期中にApp Storeへ到達しません。この数字は、最初のAI提供の試みが頓挫した後に当社へ依頼してくださった米国のエンタープライズ顧客とのポストモーテム（振り返り）作業からWednesdayが得たものです。義務（マンダート）は本物です。ボードからの圧力も本物です。しかし、ほぼすべてのケースで欠けているのは、明確なスコープ、現実的な技術判断、そしてこれまでに実際にAI機能を出荷したことがあるベンダーです。
本分析では、ボードが義務付けたモバイルAIプロジェクトに現れる5つの失敗パターンについて、それぞれが実際にはどのように現れるのか、そして90日間の猶予が閉じる前にどう防ぐかを扱います。
主要な調査結果
Wednesdayのポストモーテムデータに基づくと、ボードが義務付けたモバイルAIプロジェクトの70%は、発表された四半期中にApp Storeへ到達しません。
誤った「オンデバイスAIかクラウドAIか」の意思決定は、AI機能提供におけるコスト超過の最大の要因です。深刻なケースでは、当初見積もりの3倍〜5倍になります。
AI機能に対するApp Storeのリジェクトは、事前に計画していない場合、リリースのタイムラインに2〜4週間を追加します。
以下：5つの失敗パターンと、成功した90日間のAIパイロットの型。
ボード・マンダート問題
取締役会が「アプリにAIを追加しなさい」と命じるとき、同時に成立しているのは次の3点です。命令は本物で、取締役会レベルの精査が伴うこと、スコープは未定義であること、そしてタイムラインが圧縮されていることです。この命令を受け取るCTOまたはVPエンジニアリングは、具体的なスコープを切り出し、それを提供できるベンダーを見つけ、取締役会向けに提示できる成果物を作り上げるための短い期間しかありません。
問題は、多くのモバイルベンダーが、その実行能力を持たないままAIマンダートに「はい」と言うことです。契約が必要だから「はい」と言うのです。プロジェクトが始まり、スコープが膨らみ、技術アプローチが誤って選ばれ、3か月後に取締役会がアップデートを求めると、答えは「まだ開発中」です。
以下の5つの失敗パターンは偶然ではありません。順序立って現れ、それぞれが次の失敗を起こしやすくします。
失敗パターン1：AI能力のないベンダーが「はい」と言う
この失敗は、ボードが義務付けたAIプロジェクトの失敗の大半の根本原因です。従来型のモバイルベンダー――一般的なワークフローで、設計の良いアプリを作るベンダー――に対して、「AI機能を追加できるか」と尋ねます。彼らは「はい」と言います。そうすれば何とかできると思っているのです。しかしできません。あるいは90日間の猶予の中でできません。
どのように見えるか：ベンダーがプロジェクトを開始し、その後数週間をリサーチモードに費やします。モバイルアプリに機械学習モデルを統合した経験がありません。プロダクション環境のモバイル文脈で、オンデバイスのモデル最適化やクラウド推論（inference）APIの統合に対応したことがありません。AI機能をApp Storeに提出し、審査要件を通過したこともありません。
プロジェクトは遅れます。本来は稼働中の機能を見せるはずだった取締役会向けのプレゼンでは、プロトタイプが提示されます。CTOは延長を求めます。延長が認められます。そして同じサイクルが繰り返されます。
防ぐ方法：AI機能提供のためにいかなるベンダーと関与する前に、3つの質問をしてください。第一に、現在App Storeで稼働しているAI機能を含むモバイルアプリとして、あなたが提供した実例を見せてください――機能名と顧客名を挙げてください。第二に、あなたのAIピッチではなく、AIワークフローをデモしてください。第三に、AI機能を含むApp Storeの提出に関して、あなたが実際にナビゲートした回数と、そこで遭遇した具体的な審査要件は何だったのか教えてください。
この3つの質問すべてに対して具体的に答えられないベンダーは、AI提供（デリバリー）ベンダーではありません。あなたのプロジェクトを通じてAIを学ぶことになる従来型のモバイルベンダーです。
失敗パターン2：開始時点でスコープが未定義
次に多い失敗。ベンダーにAI能力はあります。プロジェクトが始まる。ですがスコープは「AIを追加する」ではなく、「AIで書類をスキャンして取り込みフォームを自動で入力する」ではありません。毎週、スコープが少しずつ変わります。AIによる検索が追加されます。次にレコメンデーションエンジン。その次にチャットボット。
追加される要素は、それぞれ単体では理にかなっています。しかし一緒になることで、90日間の猶予が不可能になります。
どのように見えるか：90日プロジェクトの3か月目には、3つの機能に対してチームが40%完了している一方、1つの機能に対して90%完了しているわけではありません。取締役会向けのプレゼンでは、App Storeに出す1つの機能ではなく、開発中の機能が説明されます。
防ぐ方法：プロジェクト開始前に、1つのAI機能だけを定義します。1つです。選定基準は、「最大のユーザーインパクト」「90日以内に技術的に実現可能」「App Storeのリジェクトリスクが低い」「明確な成功指標」です。意思決定を文書として残してください。最初の60日間における1つの機能を超えてスコープを拡大したいという要請は、90日間の目標への脅威であり、その目標に対して明示的に評価されなければなりません。
4つすべての基準を通常満たしやすい機能：書類のスキャンと抽出、構造化データに対するスマート検索、予測型のルーティング/ディスパッチ（配車・振り分け）、パーソナライズされたコンテンツランキングです。これらは具体的で、高いインパクトがあり、技術的にも理解されており、大規模においてApp Storeで承認されやすいものです。
失敗パターン3：成功指標が定義されていない
AI機能は出荷されます。すると取締役会が尋ねます――動いているのか？誰も分かりません。機能は公開され、ユーザーは触っています。しかし、ボードのAIマンダートが満たされたかどうかを取締役会が判断できる計測の枠組みがありません。
どのように見えるか：取締役会向けのプレゼンにはスクリーンショットやユーザー数はありますが、AIが解決すべき課題に対する「導入前と導入後」の比較がありません。取締役会は「AIは何を改善しているのか」と聞きます。答えは、ユーザー体験に関する一般的な説明になります。取締役会は満足しません。
防ぐ方法：最初のコード行を書く前に成功指標を定義します。指標は数値である必要があり、AI機能が存在する前と、出荷された後で測定できるものでなければなりません。例：AIが自動化するタスク（書類取り込み、検索クエリ、ルート選択）の所要時間、当該タスクにおけるエラー率、最初の30日間におけるユーザーの採用率です。この指標は、取締役会向けプレゼンにおける主要なデータポイントになります。
1つの指標。導入前と導入後で測る。取締役会向けプレゼンで差分（デルタ）付きで報告する。
失敗パターン4：オンデバイスAIとクラウドAIの判断が誤っている
この失敗は最も費用がかかります。プロジェクトは1つのアプローチを決めて進みます（典型的にはクラウドAIです。試作が速いため）。そこに対して8週間ほど構築し、その後、特定のユースケースにとってそのアプローチが成立しないことが判明します。
よくある例：患者データ処理のためにクラウドAIを前提にしたヘルスケアアプリが、HIPAAの要件に直面し、PHI（保護対象の健康情報）を第三者のクラウド推論APIに送信できないことが分かるケース。現場サービスアプリがクラウドAIを前提にしたものの、ユーザーの40%が信頼できる接続がない地域で稼働していることが判明するケース。フィンテックアプリでは、本番スケールでのクラウド推論のコストが月額80,000ドルで、試作時のトラフィック見積もりに基づく前提の10倍になるケース。
どのように見えるか：90日プロジェクトの8週間目に、チームが別のアーキテクチャでAI統合をゼロから作り直している。90日間の猶予は消滅しています。コスト見積もりは当初の3倍〜5倍に膨らんでいます。
防ぐ方法：オンデバイスかクラウドかの判断を第8週ではなく、第3週に行うこと。判断のためのフレームワークは以下です：
- クラウド送信に規制がかかるデータ（特定の法域におけるPHI、PII、データ居住要件の対象となる金融データ）を、この機能は処理しますか？はいの場合、デフォルトはオンデバイスです。
- この機能を利用する際、ユーザーのかなりの割合がオフライン、または接続が不十分な状態になりますか？はいの場合、オンデバイス。
- モデルの複雑さは、現在のデバイスのハードウェアに対して大きすぎませんか（通常、中央値仕様のデバイスで許容されるパフォーマンスのためのモデルサイズは、一般的に1〜2GBを超えると不適切です）？はいの場合、クラウド。
- 本番環境の規模における、ユーザー1人あたりのクラウド推論コストはどれくらいですか？実際のユーザー量を前提にモデル化します。日次アクティブユーザーセッションあたり0.05ドルを超える場合は、コミットする前に年間コストを試算してください。
意思決定と、その理由を記録してください。プロジェクトが進むにつれて理由が変わる場合は、黙って調整するのではなく、明示的に見直さなければなりません。
障害モード5：AI機能に対するApp Storeの却下
この障害モードはモバイルAIの提供特有のものであり、過去にAI機能を提出したことがないベンダーによって、いつも過小評価されています。AppleとGoogleはいずれもAI固有の審査要件を持っており、一般的なモバイルベンダーは提出が却下されるまでその存在を知らないことがあります。
そう見えるのはこうです：機能は完成しており、提出も行われる。しかしApp Storeの審査で、ボードプレゼンテーションの開催日の2〜4週間前に却下される。却下の内容により、機能の出力の説明方法を作り直す必要が出たり、プライバシーマニフェストのエントリを追加したり、コンテンツフィルタを実装したりする必要がある。結果としてボードプレゼンが延期されます。
AI機能に対するAppleの最も一般的な却下理由：
精度（Accuracy）に関する主張。「AI診断」「AI予測」または、AI出力が推測的なものではなく決定的であることを示唆するあらゆる言い回し。Appleガイドライン5.1（安全性）は、健康関連のAI主張に対して特に適用されます。対処は、出力の説明を「AIによる支援付きの分析」や「AI分析に基づく提案」として言い換え、結論として述べないことです。
プライバシーマニフェストのエントリ漏れ。アプリがAIによりユーザーデータを処理する場合、そのことをアプリのプライバシーマニフェストで宣言する必要があります。漏れがあると却下されます。対処は、正しいプライバシー栄養表示（privacy nutrition label）エントリを追加して再提出することです。
安全性フィルタなしでのコンテンツ生成。AIを用いてテキスト、画像、その他のコンテンツを生成するアプリは、コンテンツフィルタを実装する必要があります。フィルタが文書化されていないアプリは却下されます。対処は、フィルタリングを実装し、提出ノートにそれを記載することです。
医療または金融アドバイスとしての枠組み。AI機能が医療または金融の助言を提供するものとして提示されている場合、ガイドライン4.8.3が発動します。対処は、適切な免責事項を追加し、出力を助言ではなく情報として提示することです。
防ぐ方法：9週目と10週目に、特定の機能に関するApp StoreのAI審査要件を調査する担当者を割り当ててください。AI審査の基準に明示的に対応する形で提出ノートを書きます。ベンダーが過去にAI機能を提出したことがある場合、これはそのワークフローの一部です。そうでない場合は、専用の時間を要する新しいタスクとして扱ってください。
mobile.wednesday.is/workで、さらに事例研究を読む
成功するAIパイロットがどのように見えるか
App Storeに到達する90日間のAIパイロットには、上記の失敗パターンと区別できる4つの特徴があります。
第1週で定義された1つの機能。機能は、意思決定フレームワーク（ユーザーへの影響、技術的実現可能性、App Storeリスク、測定可能な成果）に基づいて選び、書面で記録します。スコープの拡大は、明示的なタイムラインのトレードオフについての会話なしには受け入れられません。
第3週で決定した技術アーキテクチャ。オンデバイスとクラウドのどちらにするかは、完全なコストとコンプライアンスのモデルを作り込んだ上で決定します。その意思決定を記録してください。状況が変わった場合は、明示的に見直します。
コードを書く前に定義する成功指標。存在する前に測定される、1つの数値です。ボードプレゼンの担当者が、その指標について「導入前」と「導入後」の比較を示します。
開発と並行して作られるApp Store戦略。第8週までに、提出ノートを下書きし、プライバシーマニフェストを完成させ、精度（accuracy）に関する主張の文言を最新のApp Storeガイドラインに照らしてレビューします。第10週での提出はサプライズではありません。予定された日付です。
90日で行うボードプレゼンでは、3つの数値が示されます。つまり、機能に対して何らかの操作を行ったユーザー数、成功指標における「導入前」と「導入後」の差、そして次の四半期における拡大範囲です。この構造は、ボードが命令（mandate）を出したときに開いたループを閉じます。
さらに深掘りしたいですか？関連するツール、事例研究、意思決定フレームワークを含む完全版は、mobile.wednesday.is/writing/why-mobile-ai-projects-fail-board-mandate-analysis-2026にあります。
