振動型マネジメントとは？AI開発の「揺れ」を前提にした進め方と、4つの撤退基準

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

概要

AI開発プロジェクトでは、前提が途中で変わります。技術検証の結果を受けてゴールの置き方を見直すこともあれば、事業判断の変更を受けて技術アプローチを組み替えることもあります。

本コラムでは、この現象を「揺れ」と呼びます。ここでいう揺れとは、プロジェクトの前提である「何を作るか（What）」と「どうやって作るか（How）」が、検証の結果に応じて何度も置き直されることを指します。スケジュールが遅れることでも、関係者の意見が割れることでもありません。計画の前提そのものが、進めながら書き換わっていくという、AI開発に固有の現象です。

従来のプロジェクト・マネジメントでは、こうした書き換えは「計画が甘かった」「迷走している」と受け取られがちです。しかしAI開発においては、前提が揺れることは学習が進んでいる証拠であり、避けるべきものではありません。避けるべきなのは、揺れそのものではなく、揺れが管理されていない状態です。

本コラムでは、この揺れを管理可能なものに変えて着地点へ収束させる進め方を解説します。当社Laboro.AIではこれを「振動型マネジメント」と呼んでいます。当社が独自に提唱している考え方であり、一般化された手法ではない点をあらかじめお断りしておきます。

AI開発プロジェクトのマネジメント全体については「AI PM（AIプロジェクトマネジメント）とは？」を、プロジェクトのゴールの置き方については「MVPPとは？」をあわせてご覧ください。

目次

・なぜ「揺れ」を前提にするのか
・揺れを管理する3つの原則
・陥りがちな2つの失敗──発散と固着
・励起・共振・収束という3つのフェーズ
・進める基準と、やめる基準
・まとめ──揺れは、管理するものであって、なくすものではない

なぜ「揺れ」を前提にするのか

揺れが起きる理由は、WhatとHowが独立していないことにあります。What（ビジネス価値）とHow（技術的手段）の両方が不確実であるだけでなく、互いに影響し合っているのです。技術検証の結果がビジネス側の問いを書き換え、事業判断の変更が技術アプローチを変える。この往復は、従来のITシステム開発にはほとんど見られない現象です。

そして、片方だけを揺らしても着地しません。技術的に非常に高度なことができても、それがビジネス価値につながらなければ宝の持ち腐れになります。逆にビジネス側で理想的な未来図を描けても、技術的に到達できなければ絵に描いた餅で終わります。ビジネス上の価値と技術的手段、この2つを同時に揺らすことが必要になります。

「振動型マネジメント」という呼び方は、この構造から来ています。2つが同時に揺れ、やがてかみ合う点が見つかり（共振）、着地点へ落ち着いていく（収束）。物理現象になぞらえながら、そのプロセスを意図的に設計するという考え方です。

図にすると、進行のイメージがつかみやすくなります。プロジェクトの初期ほどWhatとHowの振れ幅は大きく、検証を重ねるにつれて徐々に小さくなり、やがて着地点に収まる。揺れをなくすのではなく、揺れを管理可能なものに変えるというのが、この考え方の要点です。

揺れを管理する3つの原則

振動型マネジメントのすべてのフェーズを通じて重要になる原則が、3つあります。

第一に、ビジョンは固定し、手段は柔軟にする。 「何のためにこのプロジェクトをやるのか」「業務プロセス上のどのボトルネックを解消したいのか」。ここは参照点として固定します。そのうえで、そこへ至る技術的手段と価値の置き方は柔軟に探索します。揺れを悪いものと捉えないことが前提です。前提や方針が変わることは、計画の甘さではなく、学習によって解像度が上がっている証拠だと捉えます。

第二に、関係者の認識を動的に同期させる。 経営層が見ているビジョン、現場が直面している実態、技術チームが把握している制約は、最初に一度すり合わせただけでは揃い続けません。途中で「当初の計画とは違うものを作るべきだ」という判断が生まれるのが正常である以上、認識のズレが生じたときにすぐ前提を再定義し、同期し直せる仕組みが必要です。

この仕組みがないと、こうなります。当初は「担当者ごとにパーソナライズされた情報を届けるシステム」を構想していたが、開発途中で現場が「まずは書類から文章を検索するシステムを作ろう」と判断を変えた。現場としては合理的な判断です。しかし意思決定者がその変更を把握していなければ、半年後に「それは当初の目標と違うのでは」という展開になります。

第三に、失敗を許容する。 ここでいう失敗とは、プロジェクト全体の失敗ではなく、仮説検証における否定的な結果を指します。研究の世界で仮説の棄却が重要な発見として扱われるのと同じで、「このアプローチではうまくいかない」と分かったこと自体が、正解に近づくための情報です。

この原則は、とくに減点主義が根づいた組織で重要になります。「試してみたけれど、うまくいきませんでした」と報告した瞬間に評価が下がるなら、担当者は挑戦的な仮説を避け、確実に成功するタスクだけをこなすようになるからです。

陥りがちな2つの失敗──発散と固着

揺れを管理できないとき、プロジェクトは2つのどちらかに転びます。

発散は、WhatもHowも自由に揺らしすぎて、どこにも収束しなくなる状態です。壮大なビジョンだけが掲げられ、技術的にもビジネス的にも選択肢が際限なく広がっていく。「いろいろ試してはいるが、どこへ向かっているのか分からない」という状況に陥ります。終わりがなく、資料の山だけが積み上がるPoCは、たいていこのパターンです。

固着はその逆で、WhatかHowのどちらかを早い段階で固定しすぎ、本来あり得たはずの転回の可能性を自ら潰してしまう状態です。「精度95%のモデルを作る」と決め打ちしたために85%でも十分に回る業務プロセスへの道が閉ざされる、「この業務を完全自動化する」と決め打ちしたために人とAIの役割分担で価値が出るはずの設計が見えなくなる。いずれも固着の典型です。

理想的なAI開発プロジェクトは、この2つのあいだにあります。自由すぎてもいけないし、固定しすぎてもいけない。だからこそ、どこまで揺らし、どこを固定するのかを設計することが、振動型マネジメントの中核に置かれます。

励起・共振・収束という3つのフェーズ

振動型マネジメントは、物理学の用語を借りて、①励起、②共振、③収束という3つのステップで進めます。

STEP1　励起──技術と価値の探索範囲を定める

励起とは、原子や分子が外部からエネルギーを与えられ、より高いエネルギー状態へ移行する現象を指す言葉です。AI開発プロジェクトに当てはめれば、WhatとHowが振動を始める前段階で、揺らしてもよい範囲を設定するフェーズにあたります。

3つのステップの中で、最も見落とされやすく、最も重要なのがこの励起です。幅が広すぎれば発散し、狭すぎれば固着する。先に挙げた2つの失敗を避けられるかどうかは、ここで適切な探索範囲を置けるかにかかっています。

具体的には、まずビジョンを固定します。そのうえで技術側については、どのようなアルゴリズムが選択肢になり得るか、利用できるデータの種類・質・量はどの程度か、計算資源やシステム上の制約はどこにあるかを見ます。ビジネス側については、精度が高い場合と低い場合で業務がどう変わるか、どれくらいの性能なら現場が受け入れられるか、どのような条件が達成されれば価値として成立するかを見ます。

実務上、このフェーズでは次の3つを押さえます。

一つ目は、3つのレイヤーの関係者に会いに行くことです。予算の意思決定権を持つ層、全社的な水平展開に責任を持つ層、技術的に何が成立するかを判断できる層。組織のレイヤーを通過するたびにビジョンの認識は少しずつ変化していくため、推進担当者が早期に直接会って認識を揃えておきます。

二つ目は、ビジョンブレイクと、不確実性を織り込んだロードマップの作成です。ビジョンを実現するためにどんな要素が揃っている必要があるのかを洗い出し、それぞれのリスクと期待値を明らかにします。そのうえで、一般的なロードマップのように「3か月後にここにいる」と定めるのではなく、「最初の2か月はこの技術が成立するかを検証する期間であり、その結果次第で次のフェーズの内容が変わる」と、不確実性の幅を明示した形で合意します。

三つ目は、予算の桁感を合意することです。生成AIツールが個人向けに月数千円で使えるようになったことで「AIは安く始められる」という感覚が広がっていますが、自社固有のカスタムAI開発でこの感覚のまま予算を組むと、ほぼ確実に途中で行き詰まります。

そして、このフェーズで忘れてはならないのが、頭の中だけで設計を完結させないことです。小さく手を動かしながら探索範囲の見当をつける。実験を通じて地図を描くという実践性が、机上の分析で終わるアプローチとの分岐点になります。

なお励起フェーズの最大の難しさは、意思決定に十分な情報がない状態で意思決定をしなければならないことです。データが使えるかも、精度がどこまで出るかも、やってみなければ分かりません。ここでの答えは、プロジェクト全体にGOを出すのではなく、最初のフェーズだけに限定的なGOを出すことです。

STEP2　共振──技術とビジネスがかみ合う点を探す

探索範囲が定まったら、技術検証とビジネス検証を切り離さずに往復させ、両者がかみ合う点を探します。

この往復を成立させるのが「翻訳」の機能です。技術側の検証結果がビジネス上どういう意味を持つのかを訳し、ビジネス側の要求が技術的に何を意味するのかを訳す。この役割を担う人材の有無が、着地の質を大きく左右します。

このフェーズで見落とされがちなのが、データの実情を早期に直視することです。データが揃っていて品質も高ければ、比較的早くモデル構築に入れます。データはあるが使えるか分からない場合、最初のプロジェクトはデータ検証が中心になり、2〜3か月かけてそもそもAIモデルが成立するかを確認することになります。データがほとんどない場合は、まずデータを作りにいく研究開発的な段階から始まり、投資が先行します。励起フェーズで織り込んだ不確実性の多くは、実はデータに起因しています。

共振フェーズの出口、つまり次のフェーズへ移る判断は、「納得解」の3条件──技術・ビジネス・現場──が、それぞれ一定の水準を満たしたときです。納得解という考え方の詳細は、別コラム「MVPPとは？AI開発がPoC止まりで終わる理由と、ゴールの置き直し方」で解説しています。

STEP3　収束──着地点を実務に落とし込む

共振点が見つかったら、それを実際のシステムと業務プロセスに落とし込みます。実装・運用設計・定着支援の比重が増え、見た目は従来型のシステム開発に近づきますが、完全に固定された世界ではありません。実装して初めて見える摩擦や、運用に乗せて初めて分かるズレが出れば、共振フェーズに戻ることもあります。収束とは揺れがゼロになることではなく、揺れが十分に小さくなり、現場で回る水準に近づくことを指します。

そして、このフェーズこそ現場との摩擦が最も顕在化する場面です。励起や共振の段階では現場の関与は限定的でしたが、収束フェーズでは日々の業務のやり方そのものが変わります。ここでのコミュニケーション設計を軽視すると、技術的にもビジネス的にも成立しているのに使われない、という結末を迎えます。

もう一つ、全関係者で共有しておくべき前提があります。最初にリリースするものは完成品ではなく、最小限の価値を回し始める出発点であるということです。この認識が共有されていれば、「まだ完璧ではないが、ここでいったん走らせよう」という判断がしやすくなります。

進める基準と、やめる基準

振動型マネジメントには、2種類の判断基準がセットで組み込まれています。

進める基準──3つすべてを満たすとき

フェーズを先に進めてよいと判断する条件は、次の3つがすべて満たされたときです。

• ビジネス観点：ビジョンに照らし、最低限の事業価値が成立している
• 技術観点：現時点の技術で実現可能な精度・スピードに到達している
• 現場観点：現場が運用に耐え、保守・改善のサイクルを回せる

やめる基準──4つのいずれか1つでも当てはまるとき

どれだけ丁寧に励起し、共振を試みても、成立しないという結論に至ることはあります。問題は、その結論が出たときに撤退を失敗として扱うか、学習として扱うかです。

撤退基準とは、「どの条件を満たせなかった場合に、このプロジェクトをやめるのか」を事前に決めておくことです。これがないと、プロジェクトは惰性で続きます。誰も「やめる」と言い出せないまま、追加検証、追加開発、追加調整が積み重なり、気づけば大きなコストになっている。多くの組織で見られる光景です。

当社では、撤退を検討すべきシグナルを4つに整理しています。

① 技術的限界──一定の検証を行っても、必要な精度や安定性に到達する見込みが立たないとき。その技術アプローチに固執すべきではありません。

② ビジネス価値の不在──AIがモデルとしては動いているものの、工数削減、売上向上、品質改善といった事業成果に結びつかないとき。目的を再定義するか、撤退を検討します。

③ 運用不可──技術的にもビジネス的にも成立しているように見えても、現場の業務フローに組み込めない、責任分界が曖昧なままになる、保守運用コストが大きすぎるといったとき。

④ 投資対効果の崩壊──本格展開に必要なコストが、得られるリターンに見合わないと分かったとき。そこでやめることも重要な経営判断です。

進める条件は3つすべてを満たすこと、やめる条件は4つのいずれか1つに当てはまること。この非対称性が、判断を早めます。

誤解されやすいのですが、撤退基準はプロジェクトを冷たく切るための道具ではありません。むしろ、健全な挑戦のために必要な条件です。やめる条件が明確だからこそ、意思決定者は安心して限定的な投資を決断でき、現場も「このフェーズで何を明らかにすればよいのか」に集中できます。

撤退基準を最初からロードマップに織り込んでおけば、撤退は敗北ではなく学習の結果として扱えます。「このテーマはこの条件では成立しない」と分かったこと自体が、次の投資判断の精度を上げる資産になるからです。

まとめ──揺れは、管理するものであって、なくすものではない

AI開発プロジェクトにおいて、前提が揺れることは異常事態ではありません。異常なのは、揺れが管理されないまま発散するか、揺れを認めずに固着するかのどちらかに陥ることです。

振動型マネジメントが目指すのは、ビジョンを固定したうえで技術と価値の双方を意図的に揺らし、励起・共振・収束の3ステップを通じて着地点へ導いていくことです。そして、進める基準とやめる基準をあらかじめ設計しておくことで、揺れは管理可能なものになります。

AI開発プロジェクトのマネジメント全体像については「AI PM（AIプロジェクトマネジメント）とは？」をご覧ください。

監修者

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

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