【経験者は共感できるはず】AIプロジェクトのPMがぶつかる課題と対処法【全然キラキラしてない】
1. はじめに
「AIプロジェクト難しい！」「AIなんて仕事にしなければよかった！」AIの仕事をしている人であれば、このように思ったことのある人も多いのではないでしょうか。
AIプロジェクトはかなり特殊です。そして、実務をやるまでそれに気づけません。この記事では、AIプロジェクトのPMをやる人がみんなぶつかる壁と、私なりの対処法をお伝えします。
こうしたAIプロジェクト特有の課題を円滑に乗り越えていくためには、経験豊富なPMの存在が非常に重要になります。AIプロジェクトのPMは「ビジネス知識」「ITシステム開発知識」「AI技術への理解」という3つの領域すべてをある程度カバーする必要があり、広範な知識と柔軟な調整能力が求められます。この記事では、そんなAIプロジェクトのPMが直面しやすい“あるある”な課題を中心に、それぞれの課題を解決するための実践的な方法・ノウハウを紹介していきます。
2. AIプロジェクトの特徴とPMの役割
本題に入る前に、AIプロジェクトと一般的なシステム開発プロジェクトとの相違点、そしてそれがPMの役割にどのように影響するのかを整理しておきましょう。
データドリブンであること
従来のシステム開発は、ビジネスロジックを明確に定義し、要件に合わせてシステムを設計・実装する流れが一般的でした。しかし、AIプロジェクトでは、データそのものが価値の源泉になります。大規模データや品質の高いデータを活用できるかどうかで、モデルの性能が大きく変化します。そのためPMは、データ活用の可能性を真っ先に検討し、データの取得・前処理・アノテーションなど、プロジェクト開始時点でデータについて十分に計画することが重要です。場合によっては、「取得できるデータが足りないからやりません」も正しい判断です。
不確実性が高い
AIモデルの精度や学習に必要なデータ量などは、実際に手を動かしてみなければわからない部分が多々あります。PoC段階では良好な結果が得られても、本番環境に移行した途端に精度が落ちることも珍しくありません。従来のウォーターフォール型開発のように、“仕様どおりに作れば問題ない”というわけにはいかず、試行錯誤と小回りの利く開発・運用のプロセス設計が求められます。
要件定義が難しい
従来型のシステム開発であれば、“どのような機能を実装するか”が明確化しやすかったのですが、AIプロジェクトでは、“どの程度の精度ならばビジネスとして成立するのか”といった曖昧な基準が絡んできます。また、「AIでなにかすごいことをしたい」という曖昧な要求しかないままスタートしがちなのも特徴です。PMはビジネス価値を見極めつつ、技術的な制約や可能性を確認し、“妥当なゴール”を設定する必要があります。ここで精度目標や指標をきちんと決めないと、「何かパッとしない成果物」と思われてプロジェクト打ち切りになります。
モデル開発とシステム開発の融合
AIモデルを実際にシステムに組み込む際には、データを取り込み、推論を実行し、その結果をユーザーや他のシステムにフィードバックするためのインフラ・アプリケーション開発が必要です。モデル開発とシステム開発のスケジュールと成果物を合致させる必要があり、この調整はPMの腕の見せ所となります。ちなみに経験上、モデル開発のできるエンジニアは多くてもシステム開発までできるAIエンジニアは少ないです。一方で企業から必要とされているのは、きちんとシステムまでわかっている人です。（これはAI開発が目的でなく手段であることを考えると当たり前だが）
以上の特徴からわかるように、AIプロジェクトのPMは従来のプロジェクトマネジメントに加えて、「データ」「アルゴリズム」「インフラ」に関する知見と、チーム内外の調整力が求められることが多いです。
3. 要件定義・企画編
3.1 「AIでなんかすごいことしたい」という要望だけ投げられる
課題の背景
AIプロジェクトの企画段階でよくあるのが、経営層やステークホルダーから「AIで新規事業を作りたい」「業務効率化したいが、具体的にはわからない」などのざっくりした要望しか出てこないケースです。AIブームも手伝って、「とにかくAIを使え」「他社もやっているからウチも負けられない」といった、いわゆる“思いつき”レベルで始まる場合もあります。
解決アプローチ
ビジネス課題を具体化するためのヒアリング
PMは、ビジネス側の要望を漠然と受け止めるのではなく、実際の現場や経営者にヒアリングを行い、現状のビジネスプロセスや課題、KPIを掘り下げます。どこにAIが適用できるのか、どの課題が優先度が高いのかを洗い出しましょう。経験上このプロセスは、結構クライアントから面倒臭がられます。しかし、ここをちゃんとやらないと後々が苦しくなります。この段階で要件がほとんど固まらないプロジェクトは実際の開発でもうまくいくことは少ないので、クライアントに迷惑をかけない程度に深く課題について考えておくべきです。また、大事なのは、こちらの立場が下という上下関係でなく、可能であれば「一緒にやる」というポジションを取ること。こうすることでこちらの要望も通りやすくなり、お互いにとって良い結果に結びつきます。
AI適用領域の仮説と検証
ヒアリング情報をもとに、実際にAIを導入することで得られるメリット（コスト削減、売上向上、リスク低減など）を仮説として立てます。そして、小さなPoCから始めることで、その仮説がどの程度有効かを評価し、プロジェクトの方向性を具体化していきます。ここでスコープを絞るためには、広範な経験が必要です。顧客からの「ここをAI化したい」という要望と、本当にAI化の恩恵を受けられる業務は、多くの場合において別です。ここを見極めることで、大きく成功に近づきます。
ROIやKPIを明確にする
ビジネス上のゴールを設定し、AI導入の効果を測定できるKPIを明確化することが重要です。最初の段階でROIを計算するのは難しくても、「何を指標にすればAIの価値が測れるか」をチーム全体で共有しておくことで、後々のプロジェクトの評価がスムーズになります。客観的な指標を定めていないと、「なんとなく精度が低い気がする」みたいな感覚の沼に陥ってしまい、プロジェクト成功は難しいです。AIプロジェクトではいろんな指標候補があるので、始めに明確に握っておくのが大事です。
3.2 データが足りない or 使えないことが後から判明
課題の背景
AIプロジェクトはデータがなければ始まりません。しかし、いざAIを使おうとした時、実は必要なデータが蓄積されていなかった、あるいは社内に存在していたもののプライバシー規定や法的問題で使えなかった、というケースは多々あります。特に大企業においてこのパターンは多いです。散々社内調整をした挙句、「使えると思ってたデータにアクセスできない」が原因でプロジェクトがクローズするパターンは知り合いからもたくさん聞いてきました。実際に経験するまでは「そんなことが本当にあるの？」と思うでしょうが、意外と多いのです。特に「個人情報をセキュリティの問題でまともに使えない」はあるあるですね。
解決アプローチ
データアセスメントを早期に実施
要件定義の初期段階で、使用可能なデータの棚卸しを行いましょう。どの部署がどんなデータを持っているのか、どのような形式で保存されているのか、取得頻度や保管期間、利用権限などを整理します。ここで、権限問題や品質、フォーマットの違いなどに気づくことができれば、後のトラブルを回避しやすくなります。
外部データや他部署との連携も検討
自社内のデータだけでは不十分な場合、外部のオープンデータやパートナー企業のデータを活用する方法を検討します。ただし、その際には利用契約やプライバシー保護などの法的リスクを事前に確認しておく必要があります。ここで工数がかかるようなら、社内外の調整と並行して今できる範囲での技術検証を進めることも忘れずに。
データ整備の予算とスケジュールを確保
データが存在しない、もしくは散在している場合は、新たにデータを収集したり整形するフェーズを計画に組み込む必要があります。データ構築に時間とコストをかけるだけの価値があるのかをビジネス面で評価し、プロジェクトの優先度やスケジュールを調整しましょう。
3.3 モデル開発とシステム開発のスケジュール感が全然合わない
課題の背景
AIモデルの開発は、ある程度トライ&エラーを前提とした進め方になる一方、システム開発は要件を固めてから着手し、厳密なリリーススケジュールに基づいて進捗を管理することが多いです。この両者のサイクルのズレが原因で、PMが板挟みになりがちです。
解決アプローチ
アジャイル的なアプローチの導入
ウォーターフォール型の一括開発ではなく、スプリントを区切って短い開発サイクルの中でモデル改良とシステム側のUI・API整備を同時並行で進める手法を取り入れると、早めに両者を統合して問題点を洗い出せます。言うは易し行うは難しですが、少なくとも途中からの変更に柔軟に対応できるように考えることは必須です。「スプリントごとにモデルの精度・性能を評価し、必要に応じてシステム側と調整する」「システム側の要件変更が出ても、柔軟に対応できるようにしておく」
モデル開発フェーズとシステム統合フェーズを明確に区切る
ある程度、モデルのアーキテクチャやデータ要件が固まるまでは、システム開発側は仮モックやダミー推論APIを用意するだけに留め、本格的な開発はモデルの基本要件が安定してから着手する方法もあります。これにより、無駄な再開発を減らし、リソースを効率的に配分できます。
PoC段階でシステム要件をしっかり検討する
PoCではあくまでモデルの性能評価にフォーカスしがちですが、その結果を実際のシステムに落とし込む時点で考慮すべき要件（推論の速度やインフラ構成など）が見えてくるはずです。PoC段階のうちにシステム要件をある程度洗い出しておくことで、スケジュールギャップを最小化できます。これをやるために、「システムに詳しいAIエンジニア」が今様々な企業において求められています。
4. データ・学習編
4.1 データが集まるまで何も進まない
課題の背景
AIモデルの開発は、学習に必要なデータが揃って初めて本格的にスタートできます。しかし、データの権限問題や取得元との交渉、セキュリティの制限などによって、想定よりも時間がかかりがちです。その間、開発チームが手持ち無沙汰になってしまうこともしばしばです。大体「手法のリサーチをしておく」で時間を潰すことも多いですが、正直DeepResearchを使えばリサーチもすぐできてしまうことも多いので、時間の有効活用に悩む人は多いのではないでしょうか。
解決アプローチ
データ取得のリードタイムを織り込んだ計画作り
データの収集・クリーニングにどれだけ時間がかかるか、あらかじめ見積もっておくことが大切です。ステークホルダーとの合意が得られるまではモデル開発に着手できない場合があるため、プロジェクト計画時にリスクとして明示しておきましょう。どのタイミングで誰をプロジェクトに入れるのか調整する際も、リードタイムの見積もりをきちんとやっておきましょう。
小規模サンプルや合成データでの試作
大量のデータを待っている間に、公開されているサンプルデータや、必要に応じてシミュレートデータを使って、アルゴリズムの当たりをつけたりコードの全体像を構想することは可能です。大規模学習は無理でも、小さなデータセットで試験的にパイプラインを構築することで、後から本番データが来てもスムーズに移行できます。この作業をしているうちに、大体のプロジェクトでは必要なデータが揃ってきます。「あとはデータを本物のデータに置き換えれば検証できる」状態を早めに作りましょう。そうすると、「データを渡したらすぐに検証結果をアウトプットしてくれた」とクライアントは思ってくれるので、印象も良いです。
4.2 クレンジングと前処理が8割、モデリング2割
課題の背景
AI開発においては、実際にモデルを組む作業よりも、データをきれいに整形し、学習に適した形式に落とし込む作業のほうが多くの工数を占めます。特に企業内のデータは、フォーマットや粒度がバラバラだったり、欠損が多かったりするため、手間がかかることが多いのです。エンプラ系のプロジェクトは特に、化石のようなExcelに直面することが多いです。
解決アプローチ
データエンジニアやデータアナリストの役割を明確化
データのクレンジングや前処理は、AIエンジニアが丸ごと担当するよりも、データエンジニアやデータアナリストといった専門家の協力を得るほうが効率的です。PMは、どの作業を誰が担当するのかを明確にし、チームメンバーのスキルセットに応じたタスク分担を行いましょう。もし他組織に外注できるのならそっちの方が良いです。時間単価を考えた時、専門職に前処理をまるっとやらせるのはコスパ悪いです。外注の場合はセキュリティ要件が問題になることが多いので、「どんな形のデータなら外部に出してもいいか」など調整が必要になることもあります。
ETLパイプラインの自動化
AIプロジェクトでは繰り返し学習や再学習が必要になるため、データの取り込みから変換、ロードまでのフローを自動化できるように設計するのが望ましいです。手作業が多いと人的ミスが発生しやすく、再現性も下がるため、できるだけパイプライン化しておきましょう。
前処理とモデリングのサイクルを短く保つ
前処理段階でデータをいくらきれいにしても、実際に学習したモデルがどの程度効果を発揮するかはやってみないとわかりません。前処理とモデリングのサイクルを短く回すことで、無駄に完璧を目指さなくてもすぐに改善ポイントが見つかります。クイックに検証を繰り返すのが、AIプロジェクトの原則です。特にPoC段階では1週間単位でこれを繰り返すのが望ましいです。
4.3 期待したデータ分布と現実が違いすぎる
課題の背景
PoCやテスト環境で集めたデータとは異なる環境で本番運用を始めたら、データの分布やクオリティがまったく違い、モデルがうまく動かないことがあります。これはAIプロジェクトにおける典型的な失敗パターンです。
解決アプローチ
事前に幅広いデータを収集する努力
PoC時には限定的なサンプルデータを使う場合が多いですが、本番運用で想定される多様なケースをできるだけ取り込むように心がけます。データ取得の段階で季節性や地域差、部署差など、異なる切り口でデータを集めることが重要です。
分布モニタリングとアラート機能
データの分布が変化する可能性は常にあります。運用開始後も継続的にデータの統計量をモニタリングし、しきい値を超えたらアラートを上げる仕組みを作っておくと、モデルが変化に対応できなくなる前に対策を打てます。
オンライン学習や定期的な再学習
データ分布の変化が想定される場合、モデルを定期的に再学習する体制を整えるか、もしくはオンライン学習でリアルタイムにモデルをアップデートする仕組みを検討します。ただし、学習データが不適切なままでは精度が低下する可能性もあるため、あくまでも分布変化をモニタリングしながら慎重に行う必要があります。
4.4 使えそうなデータが著作権やプライバシー問題で使えない
課題の背景
特に個人情報や著作権が絡むデータは、法規制や企業のコンプライアンス規程により、思うように使えないことがあります。これを後から知ってしまうと、計画していたモデル開発が根本的にできないことになりかねません。
解決アプローチ
リーガルチェックを早期に実施個人情報保護法、著作権法などは専門的な知識が必要です。社内の法務部や外部の法律事務所に相談し、どのデータがどこまで利用可能なのかを明確にしておきましょう。
匿名化や合成データの活用
個人情報などセンシティブな情報を含むデータでも、匿名化やマスキング技術を使うことで合法的に利用できる場合があります。また、実データをもとに統計的な特徴を保持した合成データを生成し、本番データの代わりとして検証に使う手法もあります。この辺りは前例のない会社も多いので、法務部とのやりとりにおいてはサンプルを用意して持っていくなど、しっかり準備をすることが大事です。使えるデータの範囲が増えればAIのできることが広がり、精度が上がります。面倒でもしっかりやるのが大事です。
データ利用規約の整備と利用者教育
データを扱うメンバー全員に対して、どこまでが利用可能範囲でどこからが違法や規約違反になるのかをしっかり共有しなければなりません。PMは、データガバナンスポリシーの浸透と徹底に努める必要があります。扱うデータの機密性が高い、かつ自由にデータを扱える権限をメンバー渡すことが多いのが、AIプロジェクトの特徴です。なので、ルール周りはチーム全体にしっかり伝えて管理する必要があります。
4.5 アノテーションのコストが想像以上に高い
課題の背景
画像認識や自然言語処理など、多くのAIタスクでは正解ラベル（アノテーション）が必要です。これを大規模に実施するには人手・コスト・時間が膨大にかかることも珍しくありません。アノテーションが終わらないと学習すら進められないため、PMにとっては大きな懸念事項です。
解決アプローチ
アノテーション要件を最適化する
最初から完璧に詳細なラベルをつける必要があるか、あるいは簡易的なラベルでも十分にモデルの方向性を確認できるか検討します。細かいラベルが必要になればなるほど手間とコストは増えますので、ビジネス目標に照らして最適なラベル設計を検討しましょう。
アノテーションツールの活用とプロセス設計
UIが優れたアノテーションツールを選定し、作業者がラベル付けをしやすい環境を用意することで、効率を大きく向上できます。また、作業者への教育や品質管理を行い、精度の高いラベルを効率的につけられるようにしましょう。一通り実装した後で分析精度が出ない時に、「実はアノテーションが間違っていた」と気づくのは一番不毛なので、ここはしっかり労力を割きましょう。必要ならちゃんとお金を使うのです。
5. モデル開発・評価編
5.1 「精度90%超えないと使えない」と言われる
課題の背景
AI導入にあたり、ビジネス側から「精度が90%を超えないなら導入価値がない」「精度99%は欲しい」といった要望を受けることがあります。これは特に、「職人技術をAIに落とし込む」系のプロジェクトでよく起こります。AIによる職人技術の再現を期待している職人本人からしたら「まだ足りない」と思われてしまうことが多いのです。しかし、AIモデルの精度指標は単純な正解率だけで測れないことも多いです。さらに、実際には90%以上でもビジネス上インパクトがある場合もあれば、90%あってもリスクが許容できない場合もあります。
解決アプローチ
適切な評価指標を設定する
二値分類ならPrecision、Recall、F1スコアなど、回帰ならRMSEやMAEなど、プロジェクトの目的に沿った指標を選び、なぜその指標が重要なのかをステークホルダーに説明します。たとえば、医療診断AIであれば偽陰性（本当は病気なのに検出できない）を最小化するRecallが最重要になることもあります。
ビジネス上の許容リスクとコストを考慮
精度向上にコストや開発時間をかけるほど、ROIが低下する可能性があります。また、多少の誤判定があってもヒトが最終確認できる仕組みなら、90%を下回っていても十分にビジネスが回るケースもあります。ビジネスプロセス全体を考慮して、リスクやコストとのバランスをとりながら目標精度を決定しましょう。ここの、「ビジネスプロセス全体を考慮」ができていない人がとても多いです。しかし、もっとも大事な部分です。ちなみに職人相手だと、クライアント側もビジネス観点が抜けていることもしばしば。「この仕事はROI的に考えた時、やった方が良いのか」を常にPMは自問自答しましょう。
目標精度に満たない場合の代替策を用意
機械学習モデルだけに頼らず、必要に応じてルールベースやヒューリスティックを組み合わせる、もしくはモデルの予測値をヒトが確認するフローを導入するなど、精度不足を補う仕組みを用意することも重要です。正直、機械学習モデルなんていきなり使わずにルールベースでまず試してみた方がうまくいくパターンも多いです。ルールベースで試してダメなら機械学習を使う、が基本の方針です。あとは数理最適化の手法を組み合わせるなど、引き出しをいろいろ持っておき、もし精度が満たなくても案をいろいろ出せるとベストです。
5.2 誤差の原因がわからず、ハイパーパラメータ沼にはまる
課題の背景
モデルがうまく学習しない場合や精度が伸び悩む場合、AIエンジニアはハイパーパラメータの調整に入り込みがちです。しかし、原因がわからないまま闇雲にパラメータをいじっても、時間とリソースを消耗するばかりで効果が薄い場合もあります。あとは経験上、パラメータを多少いじったところで成功に結びつくことは少ないです。（よっぽどクリティカルに間違えていれば話は別ですが）
解決アプローチ
エラーログや可視化を徹底する
学習過程や推論結果のエラーを詳細に分析・可視化し、どの種類のデータでミスが多いのかを把握します。例えば分類タスクなら混同行列を見て、どのクラス間の誤分類が多いのかを確認し、原因を探るのが有効です。データの定性理解をすることで、いい感じに特徴量を作れることも多いです。思ったように精度が出ない時は数理的側面だけでなく、ビジネス観点で理解することがプラスに働きます。あまりに精度が出ないようなら、プロジェクトメンバーのビジネス理解をさりげなく確認しましょう。
シンプルなモデルから検証する
いきなり複雑なニューラルネットワークや最先端アーキテクチャを試すのではなく、まずは単純なモデルでベースラインを作り、そこから段階的にモデルを複雑にしていくほうが原因追及がしやすいです。LightGBMなんかは前処理が少なくて、実装も手軽で良いですね。
外部リソースやドメイン知識を活用
データのドメイン知識に詳しいメンバーの知見を取り入れたり、類似プロジェクトの事例を参照することで、原因の手がかりを得られることがあります。PMは開発チームが孤立しないよう、社内外の専門家やコミュニティにつなぐ役割を積極的に果たしましょう。技術的に実現可能な上限はだいたい決まっています。類似事例が成功していれば成功するし、成功例がなければ成功しません。元も子もないですが、「知っているか知らないか」が明暗を分けます。ドメイン知識を把握した時、それを機械に落とし込むのが難しいと感じたら、その段階で結構厳しいことも多いです。逆に、フローチャートや言語にわかりやすく落とせると感じたら、それで大幅に精度改善できます。
6. PoC編
6.1 PoCはうまくいくけど、実運用で破綻する
課題の背景
小規模データや限定された環境でPoCを行うと、モデルの精度も高く動作も軽快に動き、「これはいける！」となりがちです。しかし、実際に運用フェーズでデータ量が増えたり、システム連携が複雑になったりすると、思ったように精度が出ない・処理が遅い・コストがかかるなどの問題が発覚します。
解決アプローチ
PoCの目的を明確化する
PoCはあくまで技術的な実現可能性を検証するものであり、本番運用の課題がすべて洗い出せるわけではありません。そのため、PoCの段階で「何を検証できれば次のフェーズに進めるのか」「何は検証範囲外なのか」を明確に定義し、過度な期待を持たないようにステークホルダーと共有します。
本番環境を想定した負荷試験やデータ規模のシミュレーション
PoCであっても、可能な限り運用を想定した条件でテストを行うことが望ましいです。特にデータ量が増えた時の処理性能や、通信遅延、エラーリカバリなどは見落とされがちなので、シミュレーションや負荷試験を実施しましょう。
スケーラビリティと拡張性を考慮した設計
PoC段階では高速なプロトタイピングが重視されがちですが、後々の本番運用で拡張しやすいアーキテクチャを選定することも大切です。クラウド環境を活用して水平スケールできる構成にするなど、運用まで見据えた設計が求められます。（実際は、そこまで綺麗なアーキテクチャを最初から見据えることは難しいですが…）
6.2 PoCと本番でデータの性質が変わりすぎて精度が出ない
課題の背景
PoCではデータ量も質も限定的で、しかも多くの場合“キレイな”データを使います。しかし、本番運用ではノイズや欠損が多かったり、まったく新しいパターンが次々と入ってくることがあります。これによってPoCの精度を維持できない問題が頻発します。
解決アプローチ
現場からの実データを早い段階で取り込む
実運用データとできるだけ近い形式や質のデータをPoC段階から取り扱えるようにします。例えば、実システムのログやIoTデバイスの生データなどをサンプルとして使い、ノイズや欠損の処理をPoCのうちから試しておくことが大切です。
データ収集プロセスや入力フローを整備
本番運用で予想外のデータが入力される原因のひとつは、ユーザーが自由入力できるフォームの存在や、機器の誤作動、複数のフォーマットが混在しているなど、データ収集プロセスが統制されていないことにあります。PoCの段階で運用フローそのものを見直し、データ品質を担保できる仕組みを検討しましょう。
モデルのロバスト性テスト
多少のノイズや欠損があってもモデルが安定した結果を出せるよう、ロバスト性をテストします。異常値や外れ値を混ぜたテストデータを学習や評価に取り入れ、本番環境でのエラー率を想定しておきます。
6.3 「PoCで動いたんだから、すぐリリースできるでしょ？」と言われる
課題の背景
PoCでモデルがある程度動作したため、ビジネス側や経営層から「じゃあ来月にはリリースできるよね？」と急かされることがあります。しかし、先述のとおりPoCはあくまで一部機能やデータセットでの検証であり、実運用に耐える設計や周辺システムとの連携にはまだ多くの工数が必要です。
解決アプローチ
PoCと本番開発の差分を可視化する
PoC段階ではアドホックに構築した部分や、テスト用の小規模データしか処理できない部分など、本番運用には向かない要素がたくさん存在します。PMは「本番リリースにはこれだけ追加で開発が必要」というリストを明示し、ステークホルダーに共有します。PoCでしっかり成果が出てれば、この段階で「ストップしよう」となることはそうそうないはずです。ある程度時間をかけてでも、安定運用できるようにしっかりコミュニケーションしましょう。
段階的リリースやベータテストの提案
すべてを一気にリリースするのではなく、まずは限定的なユーザーや部署で試験運用を行い、運用課題がないかを検証するアプローチを提案します。徐々に規模を拡大していけば、大きな失敗リスクを減らすことができます。
7. 運用・リリース編
7.1 モデルの精度劣化が後から発覚
課題の背景
「リリース直後はそこそこ性能が出ていたのに、数ヶ月経ったら精度が下がっていた」、「全くチェックしておらず気づかなかった」というケースがあります。これはデータの分布が変化したり、モデルが想定外の入力を受けたりすることで起こりやすい問題です。
解決アプローチ
精度モニタリングと定期報告
運用に入った後も、定期的にモデルの推論結果と実際の正解ラベルを比較し、精度をモニタリングします。さらに、その結果を関連部署や経営陣に報告する仕組みを作ることで、問題が発生した際に早期に認識・対処できます。
再学習のスケジュールとトリガー
条件の設定精度が一定以下に下がったら再学習を行う、もしくは月次や四半期ごとに学習データを更新して再学習を行うなど、再学習のトリガーとスケジュールをルール化しておきましょう。これによって、“いつのまにか精度が落ちていた”という状況を回避しやすくなります。ここは可能であれば、保守運用業務として定期的に人が入るのが良いです。AI分野、特にLLM関連は進化が早いので、再学習だけでなくモデルのアップデートを考えた時、総合的な判断が必要です。モデルを更新する際は、必ずバージョン管理を行い、いつ・どのデータで学習したモデルかを明確にしておきます。ロールバック可能な体制を整えることで、アップデートで問題が起きた場合でも迅速に対応できます。
7.2 「バッチ処理前提」で作ったのに、リアルタイム推論が求められる
課題の背景
リリース後、ビジネス要件が変わり、リアルタイムで推論結果を返してほしいと要望されるケースがあります。最初からバッチ処理前提で設計していると、インフラやAPI設計を抜本的に見直す必要があり、大きな追加コストが発生します。
解決アプローチ
要件の優先度と実装難易度を再評価
本当にリアルタイムが必要か、あるいは準リアルタイム（数分～数十分の遅延）ではダメなのかを改めてビジネス側と確認します。リアルタイム化のコストに見合うだけのメリットがあるのかを慎重に検討しましょう。
APIやインフラのスケーラビリティ
リアルタイム推論を導入するなら、GPU・CPUリソースのスケールアウトや、コンテナオーケストレーション（Kubernetesなど）を使った柔軟なインフラ運用が必要になります。最初からこうした拡張性を考慮した設計にしておくと、後々の要件変更に対応しやすくなります。
オンライン推論とバッチ推論のハイブリッド化
すべてをリアルタイムで処理しようとするとコストが急増する場合があります。そこで、緊急性が高いリクエストのみオンラインで推論し、残りはバッチで処理するといったハイブリッド構成を検討するのも一つの方法です。この辺は現場の感覚を丁寧にヒアリングして、できれば要件定義の段階で把握しておきたいところです。しかし実際は運用してみないとわからないこともあります。課題の分解をした上でその都度丁寧に構成を検討しましょう。
7.3 モデルを再学習したら精度が下がる
課題の背景
運用開始後の再学習で精度向上を狙ったものの、実際には学習データが偏っていたり、以前のモデルの方が汎化能力が高かったりして、精度が下がってしまうことがあります。さらに、運用環境では古いモデルに戻すのが難しく、トラブルになることもあります。
解決アプローチ
ベンチマークとA/Bテスト
新しいモデルをデプロイする前に、テスト環境で古いモデルと比較するベンチマークテストを行い、精度や速度を評価します。必要に応じてA/Bテストを実施し、実際のユーザーが影響を受けない形で新旧モデルを比較する仕組みを整えると、安全にモデルをアップデートできます。（本当に差があるのか、統計的考察は忘れずに！）
データの検証とクリーニング
新しく追加したデータにラベルの誤りが多かったり、偏ったサンプルが含まれている場合、モデル性能が劣化する原因になります。再学習前に、追加データの品質や分布を検証し、必要に応じてクリーニングを行いましょう。
モデルアンサンブルや切り替えの自動化
新旧モデルをアンサンブルすることで、精度劣化リスクを分散する方法もあります。また、自動的に旧モデルにロールバックできるようにデプロイを設計しておくと、万一の際に被害を最小化できます。
7.4 運用後、AIのせいで現場の仕事が増えてクレーム
課題の背景
AIの導入によって自動化や省力化を期待していたはずが、実際にはAIが吐き出す結果を人間が逐一確認しなければならなくなったり、誤判定のフォローアップ作業が増えたりすることがあります。これによって現場の反発やクレームが生じ、AIの評価が下がるケースも珍しくありません。DX部署が嫌われている事業会社が多いと感じるのは、私だけではないはずです笑キラキラしたDXのイメージとは裏腹に、社内では「面倒を増やす人」「口だけ達者で実務を改善しない人」とか思われたりします。そこを乗り越えてしっかり結果を出せば、「あの人のやる施策なら協力しよう」と思ってもらえるようになります。
解決アプローチ
業務フロー全体での自動化レベルの設定
“AIに任せる部分”“人間が判断する部分”を明確に区分し、過度にAIに依存しすぎないよう設計する必要があります。AIが補助的なロールを担う形で導入し、現場の負担を増やさないフローを検討しましょう。その際大事なのは、深い業務理解。理想を言えば、自分自身がクライアントの業務をこなせるくらいに理解しましょう。その方が、信頼関係も築きやすいです。
UI/UXデザインの見直し
AIの推論結果を現場が利用する際のUI/UXがわかりにくいと、操作や確認作業が煩雑になりがちです。現場スタッフの声をフィードバックしながら、できるだけ手間のかからないワークフローを作ることが重要です。
現場への説明と教育+α
AIは完璧ではなく、一定のエラー率が存在します。それに伴う追加作業が必要になることを事前に説明し、現場スタッフに理解と協力を求める場を設けましょう。また、AIの結果が間違う理由や、その対処法を学習する機会を与えることで、現場との心理的な対立を和らげられます。またプラスで、ウェットなコミュニケーションが大事なこともあります。例えば、クライアントと飲みに行くことで、露骨に協力してくれるようになることもありました笑 もちろん人によって向き不向きがあると思いますが、地道な信頼関係の醸成は間違いなくプラスに働きます。
8. チーム・組織編
8.1 PMはAIエンジニアとビジネス側の板挟みになる
課題の背景
ビジネス側は「早くリリースしてビジネス効果を出したい」「コストは抑えたい」、AIエンジニア側は「精度を上げたいからもっとデータを増やしたい」「最新の研究手法を試したい」など、それぞれ求める方向が異なることが多いです。PMは両者を調整し、妥協点を見つけなければなりません。
解決アプローチ
共通言語の確立
AIエンジニアにはビジネス指標やROIなどの概念を教え、ビジネス側には精度指標や技術的制約を学んでもらう機会を作り、双方が最低限の共通言語を共有できるようにします。PMが翻訳者役として動くことも重要です。
目標を分解してロードマップを策定
“精度をどこまで上げるか”“コストをどこまでかけるか”という対立は、“いつまでに、どの段階までの成果を出すか”という形に分解すると調整しやすくなります。たとえば、第一段階では必要最低限の精度でリリースし、第二段階で精度向上を図る、といった段階的ロードマップを作成し、双方の合意を得ましょう。
コミュニケーションの仕組みづくり
定期的なステークホルダー会議や開発チームとのスタンドアップミーティングなど、情報が不透明にならないようにする仕組みを作ります。PMは“必要な情報が必要な人に届く”ように常に気を配り、問題が小さいうちに解決できる体制を整えましょう。
8.2 AIエンジニアとインフラエンジニアの認識がズレる
課題の背景
AIエンジニアは、GPUリソースや大量のストレージが必要、もしくは特定のフレームワークやライブラリを自由に使いたいと考えます。一方でインフラエンジニアは、セキュリティポリシーや既存システムとの整合性、可用性などを優先します。両者が互いの要件を理解し合わないと、環境構築が進まずプロジェクトが停滞します。
解決アプローチ
要件の整理と優先順位付け
GPU利用やクラウド環境でのスケーラビリティ、オンプレミス環境でのセキュリティ要件など、プロジェクトに必要なインフラ要件を明確にリストアップします。どれが必須か、どこが妥協できるかを最初に把握し、優先順位をつけることで調整しやすくなります。
プロトタイピング環境の用意
本番環境の構築には時間がかかる場合、AIエンジニアが試行錯誤できるプロトタイピング用の環境を用意するとよいでしょう。クラウドの一時的なサンドボックス環境などを活用し、インフラエンジニアの制約を受けずにモデル開発を進めるケースもあります。
継続的な技術交流
AIエンジニアとインフラエンジニアが互いの領域に興味を持ち、定期的に情報交換できる場を設けることも有効です。お互いに理解が深まれば、対立ではなく協力関係が築かれやすくなります。
8.3 途中で「やっぱりルールベースで良くない？」となる
課題の背景
AIを導入する意義が十分に検証されないままプロジェクトが始まった場合、途中になって「ルールベースの方が開発も楽だし運用コストも低いのでは？」といった意見が出てくることがあります。AIを使わなくても業務要件を満たせるなら、それも一つの選択肢ではありますが、プロジェクト全体を振り回す結果にもなります。
解決アプローチ
AIの導入意義とビジネス効果の再確認
初期段階で定義したKPIやビジネス上のメリットを再度見直し、本当にAIが必要なのかを検証します。パターン数が少ない場合や、明確なルールで対処可能なタスクなら、確かにルールベースが妥当なこともあります。導入の目的が曖昧な場合は、プロジェクト自体の方向転換を含めて検討しましょう。
AIとルールベースのハイブリッドアプローチ
すべてをAIに任せるのではなく、ルールで判定可能な部分はルールベースで処理し、それ以外の高度な判断が必要な部分はAIで補完する方式を採用するケースもあります。こうした折衷案を検討することで、リスクを抑えつつAIのメリットを活かせる可能性があります。
コミュニケーションとプロジェクトマネジメント
途中で方針転換が必要になるのは、初期の段階で十分な合意形成ができていなかったことが原因の場合が多いです。PMは、方針転換の背景にあるビジネス上の変化や要望の真意を把握しつつ、プロジェクト全体のスケジュールやコストに与える影響を関係者に明示し、慎重に意思決定を行わなければなりません。
9. まとめ
AIプロジェクトはこのように、「AI以外の問題」が起こることがとても多いです。AI開発ができる人材は多くても、その上で「システムまでわかる」、「ビジネスにも強い」AIエンジニアはまだ希少です。学ぶべきことは多いですが、AIエンジニアは時代の最先端を目の当たりにできるエキサイティングな職業です。PMとしてより大きなプロジェクトをリードできるようになると、できることは無限に広がっていきます。私自身もまだまだ学んでいき、AIによるビジネス価値の創造に引き続き取り組んでいきます！
最後まで読んでいただき、ありがとうございました！よかったらXもフォローしていただけると幸いです！
Discussion