ステップ1: 顧客が待たされる場所から、適切なプロセスを見つける

業務チームに「AIのユースケースは何か」と直接尋ねても、良い答えは得られないことがほとんどです。現場の担当者は日々、顧客対応、関係構築、例外処理に追われており、顧客の方から「来四半期はAIをください」と言うこともありません。現場の人に業務を止めてもらい、白紙の状態からAIのロードマップを考えさせるのは、そもそもの出発点が間違っています。

より確実な方法は、顧客から内側に向かって遡ることです。まず、顧客がどの時点で待たされたり、不満を言ったり、離脱したりするのかを特定し、その体験を生み出している仕事、データ、エビデンス、責任者を調べます。原文では、このチェックを5つの視点に分解しています。

1. 顧客との接点: 顧客にとっての成果を変えられる箇所を見つけます。これまでにない洞察を提供したり、数日かかっていた待ち時間を数分に短縮したり、製品がリリースの合間にも改善され続けるようにしたりすることができます。Ajzenstadt氏は特に、口座開設、書類審査、新規顧客のオンボーディングといったプロセスが過小評価されがちだと指摘します。顧客がなかなかサービスを使い始められないのであれば、それは内側を調査する価値のある入り口です。
2. 背後にある仕事: ステップを、決まったルールに従う作業、判断が多い作業、例外対応、人間関係に依存する作業に分類します。機械は決まったルールに従うステップを引き受けたり、判断のための材料を準備したりするのに適しています。人間は引き続き、意思決定、承認、例外対応を担当します。仕事の大部分が複雑な判断や顧客関係に依存している場合は、それは後のパイロットに回し、まずは明確な受け入れ基準を設定しやすいプロセスを選びます。
3. コンテキスト: 事実がどこに存在するのか、誰が責任者なのか、フィールドが実際に何を意味するのか、機密レベルはどの程度かを確認します。社内の誰もデータの意味を説明できない場合は、データの定義自体が最初の作業になります。
4. エビデンス: 現在、作業単位、処理量、リードタイム、人手による対応時間、手戻り、例外率、単位あたりのコストを測定できるかを確認します。現在のベースラインがなければ、パイロット終了後に何が変わったのかを証明する方法がありません。
5. 責任者: 事前にプロセス責任者、データ責任者、エグゼクティブスポンサーを指定します。パイロット後に運用を引き継ぐ意思のある人、証拠に基づいて継続・中止を判断する意思のある人がいなければ、そのプロセスは不適格です。

企業はまず3〜5つの候補プロセスを洗い出し、価値、実現可能性、リスク、将来の再利用価値で優先順位を付け、1つだけ選んで開始します。実際のユーザー、実データ、合意可能なベースライン、明確な責任者がいないものは、開発前に除外します。「組織全体を再設計する」といった短いサイクルで検証できない目標も、同様に不適格です。

プロセスを選んだら、実際に運用している担当者と一緒にプロセスを一通り確認し、代表的なケース、例外、権限、そして文書化されていない専門家の判断を収集します。最初にインタビューを行い、その後で技術を棚卸しします。コードを読む前に、各データの責任者とフィールドの意味を尋ねます。Ajzenstadt氏はまた、1つのビジネス成果と明確な非目標を書き留めるよう求めています。チームは2週目には小さなパイロットを全システムに拡張しようとしがちだからです。

ステップ2: エージェントの前に、ベースラインと評価基準に合意する

Ajzenstadt氏の10ステップ法で重要なのは、「10」という数字ではなく、アクションの順序を間違えないことです。モデルの回答を見てから指標を選ぶと、人間は自然とモデルが得意な部分を重視してしまいます。パイロット終了後にベースラインを追加するのでは、変化がどこから来たのかを判断できません。ベースライン、ゴールデンセット、重要な失敗カテゴリーは、エージェントよりも先に存在しなければなりません。

双方は先に、現在の作業量、リードタイム、人手による処理時間、品質と手戻り、例外率、運用コスト、そしてどの程度の期間で測定するかに合意します。今日どのように行っているか、どの程度の水準か、改善をどのように計算するかを、試行前に明確にします。

ここでいう「ゴールデンセット」とは、顧客自身の専門家が結果を確認した実際のタスクの集合です。評価には、このビジネスが最も許容できない失敗、例えば数値の誤り、保護データの漏洩、データ不足時の根拠のない確信などのケースも含めなければなりません。成功事例と重要な失敗の両方を基準に含めて初めて、試行結果は意思決定の俎上に載せられます。

この準備には、企業内部の人が参加する必要があります。Limestoneの「証明月」のスケジュールによると、エグゼクティブスポンサーは毎週30分を投資し、関門で意思決定を行います。プロセス責任者は毎週2〜4時間をレビューと受け入れに充てます。データ責任者は開始時に1〜3時間を費やします。ベンダーはシステムを開発できますが、ビジネス目標、フィールドの意味、正しい答えは、企業自身が確認する必要があります。

これは予算の境界も明確にします。Limestoneが報告する提供体制は、エージェントを伴う常駐開発エンジニア1名と非常勤のアーキテクト1名で、月額15,000〜20,000ドルです。別の業務用エージェントプロジェクトでは、4つの顧客データセットを処理するためのインフラ費用が月額約250ドルでした。この2つの金額は基準が異なります。インフラの請求書には、開発、検証、組織的な引き継ぎにかかるすべての投資は含まれていません。彼らが初期診断料を取らず、月単位で契約し、初月に満足できなければ支払い不要とする条件は、このサービスプロバイダーの商業的な約束であり、顧客自身の受け入れ基準の代わりにはなりません。

Ajzenstadt氏は証明月に関して、もう1つ具体的な規律を設けています。すべての活動は、意思決定、検証済みの仮説、実行可能なインクリメント、再利用可能な資産のいずれかを生み出さなければならない、というものです。そのいずれも生み出せない活動は、チームの時間を割く価値がありません。これにより、レビュー、会議、開発がすべて実際の結果に焦点を合わせたものになります。

ステップ3: 2〜4週間並行稼働させ、エビデンスで継続可否を判断する

パイロットは、最初から人間に代わって最終決定を下すものであってはならず、記録システムに直接書き込むものでもありません。より堅実な最小スライスは、エージェントが提案を行い、明確に指定された人間が決定を下すというものです。実際のデータを使用し、旧来の方法と並行して稼働させ、毎回の実行が他の人が確認できる痕跡を残すようにします。

この2〜4週間で、3つの異なる問いに同時に答える必要があります。速くなったか、良くなったか、すべてのコストを考慮した上で価値があるか、です。

原文は、Faros AIによる22,000人の開発者を対象とした2026年のテレメトリーデータを引用し、読者に注意を促しています。タスクのスループットが33.7%向上する一方で、開発者あたりの欠陥は54%増加し、PRあたりのインシデントは242.7%増加しました。この数値は、特定の企業の結果を予測するものではありませんが、速度と品質を分けて測定する必要があることを明確に示しています。

試行の出口は4つあります。継続、調整、停止、拡大です。結果が事前に合意したベースラインを超えなければ、4週間後に停止することで、その後の予算を守ることができます。調整が必要な場合は、実装やプロセス案を修正し、事前に合意した基準で再度検証します。結果が良くないからといってハードルを下げてはいけません。タスクの範囲自体が変わった場合は、検証条件を再定義する必要があり、新旧の結果を同じ比較として扱うことはできません。

図では、「試行」と「3種類の測定」を同じフェーズに置いています。エビデンスは稼働中に継続的に蓄積され、最終的にビジネス側と納品側が共同で次の投資を決定します。

エビデンスが拡大を支持したら、本番展開と運用引き継ぎを整備する

パイロットを通過したエージェントでも、日常運用に入るには、安定したスケジューリング、監視、統合、失敗時のロールバック、コスト上限、継続的な評価が必要です。変更のたびに再評価が必要で、デプロイ環境が特定のエンジニアのPCに依存してもいけません。原文の7段階の採用ラダーは、個人のツールから組織システムへと移行するために必要な能力を表しています。

ラダーの位置は、基本的なアクセス権限管理を後回しにしてよいことを意味しません。Ajzenstadt氏は、知識構造には初日からロールベースのアクセス制御が必要だと明言しています。データ所有者、機密レベル、パイロット責任者も開発前に決定されます。パイロット通過後に追加されるのは、本番運用と拡張のための保護策であり、初期段階でもデータと権限の境界は守られるべきです。

多くの企業はまだレベル1に留まっているのに、レベル7の自動化機能を導入しています。実際のボトルネックはしばしばレベル4です。まずスクリプトを個人のPCから、安定してトリガーでき、ログを残し、失敗を処理し、明確な責任者がいるサービスへと移行します。安定稼働するサービスがなければ、複数のエージェント間の引き継ぎも信頼できる日常的なプロセスにはなりません。

ガバナンスには具体的な撤退ルールも必要です。Ajzenstadt氏は、各エージェントに寿命を設定し、ツール数が100を超えたらライフサイクル管理を徹底し、90日間稼働していない機能は廃止し、評価が基準を下回った能力は排除することを提案しています。これらは作者が提案する管理ルールです。重要なのは、期限切れの機能を停止する責任者がいることです。廃止されたエージェントがまだ有効な認証情報を保持しているのを防ぐためです。

最後に、オペレーターをトレーニングし、運用マニュアルを引き渡し、機能を既存のプロセスに組み込みます。人間の役割は、ツールを一つずつ起動することから、結果の受け入れ、判断、例外処理へと移行します。専門家による修正は、その都度ゴールデンセットに反映されます。責任者を明確にすることは始まりに過ぎず、チームが実際に使いこなし、判断でき、継続的に維持できて初めて、運用引き継ぎが完了します。

3つのケーススタディが示す、このループの効果と限界

Ajzenstadt氏は3つの顧客事例を提供しています。これらは前述のループがどのように機能するかを観察するために使用できますが、この方法がすべての企業で同じようなリターンを生むことを直接証明するものではありません。顧客は匿名であり、元のベースライン、完全な評価セット、第三者による検証資料も公開されていません。

原文はまた、企業が1〜3ヶ月で変革を完了することは不可能であると明確に認めています。ソフトウェア工学におけるエビデンスが最も深いのは、インプット、テスト、手動ゲートが比較的明確だからです。ソフトウェアや単純な反復プロセスから離れると、普遍的に適用できる「明白なユースケース」は存在せず、判断や人間関係に依存する仕事はそれぞれ、独自のベースライン、ゴールデンセット、失敗基準を再構築する必要があります。

これらの限界はループの価値を損なうものではなく、むしろその用途を明確にします。ループは事前に答えを知っていることを約束するのではなく、企業が管理可能な期間で十分なエビデンスを得て、投資を継続するかどうかを判断できるようにするものです。

真の複利効果は、次のプロセスをゼロから始めなくて済むこと

最初のプロセスの価値は、実現するかもしれないコスト削減だけではありません。ループを完全に一回りさせれば、企業は次のパイロットにそのまま持ち込める4つの資産を残せます。

• コンテキスト層: データ定義、所有者、機密レベル、部門間の境界が明確になっています。
• 評価フレームワーク: ゴールデンセット、失敗カテゴリー、ルーティングロジック、品質ゲートを拡張できます。
• 管理されたインフラストラクチャ: スケジューリング、ログ、ロールバック、セキュリティレビュー、コスト上限をゼロから構築する必要がありません。
• ビジネス所有権: 運用マニュアル、承認プロセス、責任者が日常運用に組み込まれ、専門家による修正がゴールデンセットにフィードバックされ続けます。

モデルは変わるでしょうし、今日流行っているエージェントフレームワークも次の四半期には廃れているかもしれません。しかし、ワークフローの知識、評価基準、管理能力、運用責任は、依然として企業のものです。これらの資産が残るからこそ、2つ目のプロセスは1つ目のプロセスが到達した地点から始められるのです。

顧客が待たされている、不満を言っている、離脱している場所から3〜5つの候補を見つけ、5つの視点で1つを選びます。開発前に権限、責任、ベースライン、評価を明確にし、実データで2〜4週間並行稼働させます。スループット、品質、経済性が、継続、調整、停止、拡大の判断を共同で決定します。エビデンスが拡大を支持したら、本番運用と引き継ぎを整備し、毎回の証明で得られた資産を次のプロセスに持ち込みます。