AI導入の12〜18か月という期間は、調達プロセスが生んだもの

ベンダーに導入にかかる期間を尋ねると、ある程度の幅をもった答えが返ってきます。一方、エンタープライズの購買担当者にどれくらいの期間を見込んでいるかを尋ねると、12〜18か月という答えが少なくありません。どちらの数字も誠実なものですが、測っているものが違います。ベンダーが数えているのは設定作業です。購買側が数えているのは、契約締結から最初の自律的に解決されたチケットまでの期間です。

大きいほうの数字は精査する価値があります。それはテクノロジーの特性ではないからです。多くのエンタープライズが想定する12〜18か月というタイムラインは、製品要件ではなく、調達プロセスが生み出したものです。3つのワークストリームが同時並行ではなく、順番に進められることで生じています。

3つの遅延要因と、それらが直列で進む理由

最初はベンダー選定です。要件をまとめ、デモを設定し、候補を絞り込み、意思決定を行います。セキュリティレビューが始まるのはその後です。5社のうち4社が落選するのに、5社すべてのコンプライアンス審査を行いたい人はいないからです。続いてインテグレーション計画が始まります。まだ選んでいないベンダーのためにインテグレーションの範囲を定めるのは無駄に感じられるからです。

書面上は、どれも理にかなっています。しかし組み合わさると、何も重ならない非効率なタイムラインが生まれます。これらを並行して進めるのは心地よいものではありません。選ばれないベンダーにセキュリティレビューの労力を割き、破棄されるかもしれないインテグレーションの範囲定義を行うことになるからです。それでも、これは導入期間を短縮するうえで最大のレバーです。破棄される作業のコストは、機能がもたらすはずだった価値を1四半期分失うことに比べればわずかです。

タイムラインが延びると何が起きるか

Gartnerは、コストの高騰、不明確なビジネス価値、不十分なリスク管理を理由に、2027年末までにエージェント型AIプロジェクトの40%以上が中止されると予測しています。同じ分析の中でGartnerは、レガシーシステムへのエージェントの統合は技術的に複雑な場合が多く、ワークフローを混乱させ、コストのかかる改修が必要になると指摘しています。

この2つの調査結果は、同じひとつの失敗パターンを表しています。テストでモデルの性能が振るわなかったことを理由にプロジェクトが中止されることはまれです。中止されるのは、システムをつなぐ作業が膨らみ続ける一方で、ビジネスケースがまだ出ていない成果を待ったまま止まってしまうからです。長いタイムラインは単に遅いだけではありません。中止が合理的な選択になってしまう状況そのものなのです。

アーキテクチャが各段階を長引かせるポイント

移行型モデルでは、本格的な設定が始まる前に、記事のエクスポートと再フォーマット、分類体系の再構築、チケット履歴のインポート、権限の再マッピング、ID連携の再構成が必要です。さらに、誰も見積もりに含めないコストもあります。移行期間中、ナレッジベースは事実上「工事中」の状態になるため、管理チームは更新を止めるか、2か所で更新するかのどちらかになります。その間にも製品はリリースされ、ポリシーは変わり、移行されたコピーは誤った内容になります。しかも顧客が古い回答を受け取るまで、誰もそれに気づきません。

オーバーレイ型モデルでは、エージェントがすでに運用しているシステムに接続し、ナレッジを元の場所のまま読み取り、チームが使い慣れたツールを通じてアクションを実行します。何も移動しないため、インテグレーションの工程は短くなり、更新の凍結も発生しません。同じ考え方は音声にも当てはまります。voice-to-voiceエージェントは、先に電話システムを移行することなく、すでに運用しているテレフォニーに接続できます。

後回しにされがちな依存関係

ナレッジは目に見える部分にすぎません。インテグレーション計画の実際の作業は残りの依存関係にあります。だからこそ、早く終えることより早く始めることが重要なのです。

• ID。 エージェントは誰と話しているかを把握する必要があります。そのためシングルサインオンや顧客認証のフローに組み込まれ、セキュリティチームの対応待ちリストに入ることになります。
• 権限。問題を解決するエージェントには、アクションを実行する権限が必要です。どのアクションを、どのアカウント種別に対して、どの上限まで許可するか、何を人間に委ねるかを誰かが決めなければなりません。これはエンジニアリングのチケットではなく、意思決定者を必要とするポリシー策定の作業です。
• 下流システム。 返金処理は請求システムに関わります。住所変更は受注管理に関わります。個々の接続は単体なら単純ですが、それぞれに当初のプロジェクト計画には含まれていなかった担当者がいます。

どのようなアーキテクチャでも、これらがなくなることはありません。問題は、1週目から取り組み始めるか、データプロジェクトが終わってから始めるかです。

短縮されたタイムラインの実例

K1xは本番稼働後、最初の1週間で80%の自律解決率に到達しました。1週目にパイロットを行い、本番はその後、という話ではありません。1週目に解決を実現したのです。Papaya Payは3週間で90%の自律解決率に達しました。エンタープライズ導入全体では、契約から本番稼働までの期間は平均4〜6週間です。

これらのタイムラインは、顧客の準備が並外れて整っていたから実現したわけではありません。クリティカルパスに移行作業がなく、3つの遅延要因が順番待ちではなく並行して進んだ結果です。

本当のタイムラインを見極めるための質問

• エージェントはナレッジを元の場所のまま読み取るのか、それともコピーが必要なのか
• チームが記事を更新した場合、エージェントの回答に反映されるまでどれくらいかかるのか
• 最初のチケットが自律的に解決されるまでに、何を移行する必要があるのか
• 現時点でネイティブに対応しているインテグレーションはどれで、オンボーディング中に構築するものはどれか
• これまでで最も早く本番稼働に至った顧客はどのくらいの期間で、何がその速さを可能にしたのか

最後の質問は特に掘り下げてください。迅速な導入には通常、共通の要因があります。それを説明できないベンダーは、アーキテクチャではなく運に恵まれただけかもしれません。

タイムラインこそが戦略である理由

数週間で稼働する導入であれば、予算の議論がまだ続いているうちに、実際のボリュームでResolution Rate（解決率）を測定できます。数四半期かかる導入では、最初の実データが届くのは、そのデータに基づくはずだった意思決定の後になります。どのモデルのベンチマークよりも、この順序こそが、継続されるプログラムと打ち切られるプログラムを分ける要因になりがちです。

90日間パイロットのスコープ では、State of AI in CX 2026レポート の「Deployment Paradox」の章をもとに、本格展開の前に解決率を実証するための標準的なスコープを紹介しています。