AIのパイロットが止まる理由の多くは、モデルとはほとんど関係がありません。データはデモより整理されておらず、ERPには使える接続口がなく、結果に責任を持つ人も、出力を承認する人もおらず、何をもって完了とするかを誰も合意していません。パイロットが本番に移るのは、何かを構築する前に、一つの業務フローに担当者、承認の手順、測定基準が決まったときです。
要点
- デモでうまくいったパイロットが証明したのはモデルであって、その周りの業務フローではありません。
- よくある障害は、データ、古いシステムとの連携、担当者、承認、そして完了の定義の欠如です。
- 使えるAPIのない古いERPにAIをつなぐのは連携プロジェクトであり、ほとんどのパイロット計画には含まれていません。
- パイロットが本番に移るのは、名前のある一人がそれを担当し、別の一人がその出力を承認するときです。
- 三つのパイロットと運営委員会ではなく、一つの業務フローと実際の利用者から始めてください。
#なぜAIのパイロットは本番の前に止まるのですか
三つのパイロットが三つのデモで終わったとしても、それは御社だけではありません。Gartner(2024年7月)は、生成AIプロジェクトの30%が概念実証の後に打ち切られると予測し、その理由として、データ品質の低さ、弱いリスク管理、不明確なビジネス価値を挙げました。MIT NANDAの報告書を取り上げたVirtualization Review(2025年8月)によると、MITの報告書は、95%の組織が生成AIから事業上のリターンを得ていなかったとしています。
オペレーションの比重が大きい企業では、同じ五つの欠落が何度も現れます。
- データ:パイロットはきれいなサンプルで動いていました。実際の入力は、スキャンしたPDF、半分しか記入されていないフォーム、アラビア語と英語のメッセージとして届きます。
- 連携:業務フローは15年前のERPで動いています。そこから読み取り、書き戻す作業は、範囲に含まれていませんでした。
- 担当者の不在:パイロットはイノベーションチームのもので、実際に使うはずの部署はそれを求めていませんでした。
- 承認手順の欠如:出力が顧客、仕入先、元帳に届く前に誰が確認するのかを、誰も決めていませんでした。
- 完了基準の欠如:パイロットは、部署がすでに管理している数字ではなく、人を感心させたかどうかで評価されていました。
本番で動かすことを前提にパイロットを構築すると、何が変わりますか
仕事の順番が変わります。Stennirはモデルから始めるのではなく、業務フローを運用している人と一緒に、その業務フローを一つ整理するところから始めます。入力がどこに届くか、どのルールが適用されるか、結果がどこへ行くか、どの例外に判断が必要か、です。この整理が仕様書になり、本当の障害がデータなのか連携なのかが早い段階で分かります。
次に、構築の前に三つのことを合意します。顧客側で業務フローを担当するのは誰か、出力を承認するのは誰か、そして滞留件数や手戻りなしで処理できた案件の割合など、どの指標をもって完了とするかです。構築は、チームがすでに使っているシステムの中で行い、すべての操作を記録し、最初のバージョンから実際の利用者が使います。
ハッカソンのプロトタイプを、安全に本番へ移すにはどうすればよいですか
ハッカソンのプロトタイプは、役に立つ証拠です。その作業が実現可能であることを示しています。たいてい欠けているのは、エラー処理、アクセス制御、ログ、実際の案件から作ったテストセット、そして停止する手段です。プロトタイプは最初のリリースではなく、仕様書の下書きとして扱ってください。
安全な進め方は、顧客やお金に関わる部分を承認手順の後ろで作り直し、過去の実際の案件のセットでテストし、利用者を増やす前に監視を加えることです。AIのプロトタイプを本番に移す実例では、一つの業務フローでこれらの手順を順に説明しています。
We are
Stennirは、一つの業務フローを、名前のある担当者、出力を承認する人、事前に合意した測定基準とともに、御社のシステムの中でパイロットから本番へ移します。
We aren't
Stennirは、パイロットを増やすだけのラボでも、新しいツールに業務を移すよう求めるプラットフォームベンダーでもありません。
プロジェクトが試行段階で止まっています。まず何をすべきですか
その部署が本当に求めているパイロットを選び、毎日それを使うことになる人に、それが置き換える仕事を説明してもらってください。説明できなければ、そのパイロットは間違った問題を解こうとしていました。説明できるなら、例外を書き出し、承認者を決め、測定基準を合意してください。そうすれば、たいていは欠けているのがデータなのか、連携なのか、担当者なのかが分かります。
湾岸地域のチームは、もう一つ手順を加えることがよくあります。業務フローは、パイロットでテストした英語のサンプルだけでなく、アラビア語と英語の入力を扱えなければなりません。早い段階でそれを確認しておけば、後でまた止まることを防げます。
#パイロットが止まっているCOOは、次に何をすればよいですか
止まっているパイロットを一つと担当者を一人選び、その両方をAI導入についての話し合いに持ってきてください。Stennirは一つの業務フローを実際の利用者のもとで稼働させ、その後も監視を続けます。どのパイロットを選ぶべきか迷う場合は、まずAIコンサルティングが選択肢を順位付けします。あわせてオペレーション向けのAIもご覧ください。無料の準備度診断を受けるか、30分の通話を予約することができます。
よくある質問
止まっているパイロットを再開するために、当社は何を用意すればよいですか。
パイロットそのもの、毎日それを使うことになる人、過去の実際の案件のセット、そして読み取りと書き込みが必要なシステムへのアクセスです。出力を承認する人も決めていただきます。Stennirはこれらを使って業務フローを整理し、五つの欠落のどれがパイロットを止めたのかを突き止めます。
当社の開発者がすでに作ったものを再利用できますか。
多くの場合、できます。プロトタイプは、どのプロンプトと手順が機能するかを示しています。Stennirは、実際の案件で通用する部分を残し、本番に欠けている部分を作り直します。アクセス制御、ログ、エラー処理、承認手順、監視です。御社の開発者は引き続き関わることができ、コードは御社のアカウントに残ります。
まともなAPIのない古いERPでも動きますか。
動かせますが、それは連携の作業であり、最初からそのように範囲を定めます。方法には、エクスポートしたデータを読み取る、読み取り専用の権限でデータベースを直接使う、チームがすでに使っている画面を通じて操作する、などがあります。後で誰も驚かないよう、Stennirは構築の前に方法を明示します。
パイロットでは起きなかったのに、本番で起こり得る問題は何ですか。
実際の入力はより整理されておらず、件数は多く、サンプルにはなかった例外的な案件が現れます。だからこそ、Stennirは人が出力を承認する形を保ち、すべての操作を記録し、過去の実際の案件でテストし、実際の利用者が使い始めたら結果を監視します。そうすれば、問題は苦情としてではなく、数字として表れます。
