AI PM（AIプロジェクトマネジメント）とは？従来型のPMが通用しない理由と、AI開発を着地させる進め方

2026.10.13公開
株式会社Laboro.AI　執行役員CIO（最高インキュベーション責任者）　田辺 遼
株式会社Laboro.AI編集部

概要

自社の業務にAIを実装するプロジェクトを任されたとき、多くの担当者が最初につまずくのは技術の難しさではありません。「いつまでに何ができるのか」を誰も断言できないまま、進捗を報告し、予算の承認を取り、現場の協力を取りつけなければならないという、マネジメントそのものの難しさです。

従来のシステム開発で有効だった進め方は、AI開発プロジェクトではしばしば逆効果になります。計画を固めるほど現場は報告しづらくなり、品質・コスト・納期を先に決めるほど判断は歪んでいきます。本コラムでは、AI開発プロジェクトを推進する立場（AI PM）が直面する構造的な難しさと、そこから抜け出すための考え方を整理します。400を超えるAIプロジェクトに伴走するなかで見えてきたものです。

目次

・AI開発プロジェクトは、なぜ従来型のPMで回らないのか
・AI PMが押さえるべき3つの転換
・AI PMを機能させる人材と体制
・自社のAIプロジェクトを点検する5つの問い
・まとめ──AI PMの出発点

AI開発プロジェクトは、なぜ従来型のPMで回らないのか

WhatもHowも不確実であるという構造

AI開発プロジェクトがなぜ扱いにくいのか。それは、プロジェクトの性質を「何を作るか（What）」と「どう作るか（How）」それぞれの不確実性という2軸で整理すると見えてきます。

左下のウォーターフォール型は、WhatもHowも安定している領域です。従来型のITシステム開発が典型で、要件定義から設計、実装、テストへと後戻りせずに進められます。左上のアジャイル型は、Whatが不確実な一方でHowは安定している領域です。Webサービスやアプリの改善が該当し、作るものを小刻みに見直しながら、ユーザーの反応を通じて価値の置き方を探っていきます。右下の研究開発型はその逆で、Whatは明確だがHowが不確実な領域です。新薬開発のように、到達すべきゴールを固定したうえで手段を探索します。

いずれの類型にも、対応する定石があります。ウォーターフォール型には工程管理、アジャイル型には反復開発、研究開発型には仮説検証。従来のプロジェクト・マネジメントの技法は、こうした「少なくとも一方は安定している」という前提のうえに組み立てられてきました。

問題は、AI開発プロジェクトが右上に位置することです。WhatとHowの両方が、同時に、しかも相互に影響しながら揺れる。この象限には、そのまま使える既存の定石がありません。

具体的に見てみます。精度95%の異常検知システムを作ると決めてプロジェクトを始めたとします。検証してみたところ、実際に出た精度は85%でした。ここで話は終わりません。「検知対象を絞れば数値は改善するのではないか」「そもそも85%の精度でも回る業務プロセスを設計できないか」といった新しい問いが立ち上がります。技術側の検証結果が、ビジネス側の問いを書き換えてしまうのです。逆に、事業判断としてスコープが変われば、必要な技術アプローチも変わります。

この相互依存が、右上の象限の実態です。アジャイル型の手法を持ち込んでも、技術的に到達できるかどうかが分からないというHowの揺れは吸収できません。研究開発型のやり方を当てはめても、ゴールそのものが動くというWhatの揺れは扱えません。既存の型のどれか一つを流用するのではなく、2つの揺れを同時に扱う進め方が必要になります。

さらに言えば、他の3象限では不確実性は「解消されていくもの」でした。要件が固まり、設計が固まるにつれて、分からないことは段階的に減っていきます。ところがAI開発では、不確実性は「新たに生まれるもの」でもあります。検証の結果が出るたびに、これまで存在しなかった問いが立ち上がるからです。

工程管理表が足枷になる

いつまでに何を達成するかを決め、進捗を定期的にレビューし、遅延があれば対策を講じる。ゴールが明確でプロセスが予測可能なプロジェクトにおいて、工程管理表は極めて有効な道具です。

しかしAI開発では、この道具が足枷になり得ます。最初に立てた計画どおりに進むことが例外中の例外である以上、計画の固定を暗黙のうちに強制する仕組みを持ち込めば、計画からの逸脱はすべて「遅延」や「失敗」として処理されてしまうからです。

実務上、より深刻なのはその副作用です。工程管理表は各工程に「完了」か「未完了」かの二値的な判断を求めます。すると、「70%の確率でうまくいきそうだが、30%の確率で根本的な見直しが必要かもしれない」という、AI開発に固有の中間状態を報告する場所がなくなります。結果として現場は「一応できました」と報告し、残った不確実性は先送りされます。そして先送りされた不確実性は、後半になって噴出します。それは単なる遅延ではなく、プロジェクトの前提そのものを覆す地雷になり得るのです。

誤解のないように付け加えると、「半年後にこういう状態にしたい」という意志そのものは重要です。問題は、そこに至る道筋まで固定してしまうことにあります。大枠の意志は動かさない、しかし到達方法は探索していく。この両立が要諦です。

QCDが定まらない

もう一つ揺らぐのがQCD（品質・コスト・納期）です。通常のシステム開発であれば、不確定要素が顕在化しても品質・コスト・納期のいずれかを調整して対処でき、「QCDの優先順位を最初に合意しておく」という原則が機能します。

AI開発では、この枠組み自体が成立しにくくなります。品質は確率的であるため事前に確定できず、コストは探索をどこまで深めるかに応じて変動し、納期は探索がいつ収束するかに依存します。三つすべてが不確実な状態では、どれを優先するかという判断そのものが難しくなります。

経験豊富なPMほど、迷走することがある

「では経験豊富なPMを立てればよいのでは」と考えられるかもしれません。しかし実務では、その逆の現象がしばしば起こります。

要件を固め、計画を立て、工程を管理し、品質を保証する。このスキルセットが身体に染みついた人ほど、「作ってみないと分からない」というAI開発の性質に強い違和感を抱きます。そして違和感を解消しようとして、無理に計画を固定したり、不確実性を過小評価したりしてしまう。大企業の大規模開発でキャリアを積んだマネージャーが、スタートアップの新規サービス開発をうまく回せないのと同じ構造が、ここにも存在します。

厄介なのは、この難しさが経験しないと伝わりにくいことです。AI開発に深く関わった人同士なら一言で通じることが、従来のシステム開発やDXプロジェクトを基準に考えている人には理解しにくい。ここに認識のギャップが生まれます。

AI PMが押さえるべき3つの転換

では、何を変えればよいのか。当社Laboro.AIが400を超えるAIプロジェクトに伴走するなかで整理してきたのは、ゴール・進め方・判断という3つの転換です。順に概要を見ていきます。

転換①　ゴールを「AIモデル」から「業務プロセス」へ

AI開発が長期化する典型的なパターンに、「モデル至上主義」があります。AIモデルの性能指標をゴールに据え、その数値を上げることに資源を注ぎ込む状態です。

先ほどの例に戻ります。目標精度95%に対して着地が85%だったとき、これは失敗でしょうか。モデル至上主義の立場では失敗です。しかし、85%でも成立する業務プロセスを設計できるのであれば、事業としては十分に成功し得ます。精度10ポイントの差を埋めるために半年を追加投資するのと、85%を前提にした運用を3か月で立ち上げるのとでは、事業インパクトはまったく違います。

そこで当社が提唱しているのが、MVPP（Minimum Viable Process & Product：実用最小限プロセス＆プロダクト）という設計単位です。ゴールを高性能なAIモデルの完成ではなく、AIモデルが組み込まれた最小限の業務プロセスが現場で回り始めることに置き直します。AIの出力を誰が受け取り、どう判断し、どのシステムに渡すのか。その流れが成立して初めて、AIは事業成果に接続されるからです。

なお、MVPPは当社が独自に提唱している概念であり、業界で一般に定着した用語ではありません。考え方の詳細は、別コラム「MVPPとは？AI開発がPoC止まりで終わる理由と、ゴールの置き直し方」で解説しています。

転換②　進め方を「計画の遂行」から「揺れの収束」へ

ゴールの置き方が変わると、進め方も変わります。計画を立てて遂行するのではなく、WhatとHowが揺れることを前提に、その揺れを管理可能なものに変えながら着地点へ収束させていく。当社ではこの進め方を「振動型マネジメント」と呼んでいます。

具体的には、技術側とビジネス側それぞれの「揺らしてよい範囲」を定める励起、技術検証とビジネス検証を往復させて両者がかみ合う点を探す共振、見つかった着地点を実際の業務プロセスに落とし込む収束という3つのフェーズで進みます。

揺れを管理できないとき、プロジェクトは「発散」と「固着」のどちらかに転びます。発散は、WhatもHowも自由に揺らしすぎて、どこにも収束しなくなる状態です。終わりのないPoCと資料の山が残ります。固着はその逆で、「精度95%のモデルを作る」「この業務を完全自動化する」と早期に決め打ちしてしまい、本来あり得たはずの着地点への道を自ら閉ざす状態です。

こちらも当社が独自に提唱している考え方であり、一般化された手法ではありません。各フェーズの手順と判断基準は、別コラム「振動型マネジメントとは？AI開発の「揺れ」を前提にした進め方」で詳しく扱っています。

転換③　判断基準に「やめる基準」を加える

3つ目の転換が、進める基準だけでなく、やめる基準も最初に決めておくことです。

どれだけ丁寧に進めても、技術的に成立しない、事業価値が出ない、現場に定着しないという結論に至ることはあります。問題は、その結論が出たときに撤退を失敗として扱うか、学習として扱うかです。撤退基準がないと、プロジェクトは惰性で続きます。誰も「やめる」と言い出せないまま、追加検証、追加開発、追加調整が積み重なり、気づけば大きなコストになっている。多くの組織で見られる光景です。

当社では、撤退を検討すべきシグナルを4つに整理しています。技術的限界／ビジネス価値の不在／運用不可／投資対効果の崩壊の4つです。

誤解されやすいのですが、撤退基準はプロジェクトを冷たく切るための道具ではありません。むしろ逆です。やめる条件が明確だからこそ、意思決定者は安心して限定的な投資を決断でき、現場も「このフェーズで何を明らかにすればよいのか」に集中できます。4つの基準それぞれの中身と、対になる「進める基準」については、振動型マネジメントのコラムをご覧ください。

AI PMを機能させる人材と体制

方法論は、それを回す人と組織がなければ機能しません。体制面の論点を2つだけ挙げておきます。

一つは、技術と事業を翻訳できる人材がプロジェクト内にいるかです。技術側の可能性と制約を理解したうえで事業の言葉に訳し、事業側の要求を技術の要件に訳す。この往復を成立させる存在の有無が、着地の質を決めます。当社ではこの役割を「ソリューションデザイナ」と呼んでいますが、これは当社が独自に設定している職種であり、一般的な職種名ではありません。他社では「AIコンサルタント」「AIビジネスアーキテクト」などと呼ばれる場合もあります。名称よりも、技術と事業のあいだを行き来する機能が組織内に置かれているかどうかが本質です。

もう一つは、意思決定・水平展開・開発マネジメントという3つの機能が揃っているかです。意思決定機能は投資判断と撤退判断を下し、水平展開機能は一つのプロジェクトで得た知見を他部門へ展開し、開発マネジメント機能は個別プロジェクトの技術的な推進を担います。この3つが揃わないまま走り出すと、「現場では成果が出ているのに、経営が次の投資判断を下せない」「一つの部門でうまくいった仕組みが、隣の部門で一から作り直される」といった停滞が起こります。

なお、専任のAI推進室を設けるか、事業部門にAI人材を埋め込むかという体制の置き方は、自社のAI活用がどの段階にあるかによって判断が変わります。

自社のAIプロジェクトを点検する5つの問い

ここまでの内容を自社に当てはめるための問いを5つ挙げます。いずれか1つでも「いいえ」があれば、そこが詰まりどころである可能性があります。

1. ビジョンは固定され、手段は柔軟に開かれているか。 「何のためにやるのか」が曖昧なまま手段の議論だけが進んでいないか。逆に、手段まで初期に固定していないか。

2. ゴールはAIモデルではなく、業務プロセスに置かれているか。 「精度○%の達成」がゴールになっていないか。

3. 「70%の確度」を報告できる場があるか。 進捗が「完了／未完了」の二値でしか報告されていないなら、不確実性が先送りされている可能性があります。

4. やめる条件が、始める前に決まっているか。 4つの撤退基準のうち、いくつを言語化できているか。

5. 技術と事業を翻訳できる人が、プロジェクトの中にいるか。 技術チームと事業部門が、それぞれの言葉のまま会話していないか。

これらの問いに答えるなかで、自社だけでは判断が難しい論点が出てくることもあります。カスタムAI開発の実績にもとづく具体的なご相談は、こちらのお問い合わせフォームよりお寄せください。

まとめ──AI PMの出発点

AI開発プロジェクトの難しさの根は、WhatとHowが同時に揺れるという構造にあります。この構造に対して、従来型の工程管理表とQCDの枠組みは有効に機能しません。

必要なのは、ゴールをAIモデルではなく業務プロセスに置き直すこと、揺れを前提としたプロセスで進めること、そして進める基準とやめる基準を最初に設計しておくこと。この3つです。そしてそのすべてを支えるのが、技術と事業を翻訳できる人材と、意思決定・水平展開・開発マネジメントの3機能を備えた体制です。

AI活用を技術の問題ではなく、経営の問題として捉え直すこと。それがAI PMの出発点になります。

監修者

株式会社Laboro.AI　執行役員CIO（最高インキュベーション責任者）　田辺 遼

芝浦工業大学工学部卒業、芝浦工業大学大学院 電気電子情報工学専攻修了。
日本航空株式会社にて、RPAによるデータ分析業務の効率化やBIツールの活用によるデータ利活用の促進に従事。その後株式会社リブコンサルティングにて、新規事業立ち上げ支援やデータ分析体制の構築支援、営業部の立ち上げ及びSFAによるマネジメント体制構築支援などを経験。デジタル領域を主とした経営コンサルティング業務に携わる。
2021年にLaboro.AIに入社。ソリューションデザイナとして、インフラ系企業向けの画像解析や、製造業におけるセンサーデータを活用した予兆検知など、複数のAI案件でプロジェクトリードを担う。2026年10月より執行役員に就任。