By Jay Revels, Ichizoku株式会社 CEO
本記事は、AIを既存プロセスに乗せるだけの取り組みが変革につながらない理由と、FDE（Forward Deployed Engineer）が業務を再設計して生産性を数倍に高める進め方を解説します。
重要なポイント
- 「けもの道の舗装」という落とし穴：既存プロセスを変えずAIを乗せるだけでは、非効率な道を自動化するにとどまり、変革につながらない実態
- 実証データが示すAI導入の限界：英国政府の検証では1,000ライセンスでも利用は1日1.14回、時間短縮が生産性向上につながる証拠は未確認
- 変革を阻む組織とインセンティブ：決裁者にプロセス変更の権限がなく、キャリア上安全な現状維持が選ばれるため、再設計が進まない構造
- 本当の変革はワークフロー再設計：FDEが現場担当者と業務を作り直し、各工程をコード・AI・人間に振り分け、成果を実際のKPIで測る取り組み
AIへの投資は、日本でも世界でも同じように進んでいます。ですが多くの企業で、月曜の朝の景色は以前とほとんど変わりません。Copilotのライセンス、ChatGPT Enterprise、PoCの資料、「AI研修」をYouTubeで受講する、役員会でいくつかデモを見せる…
様々な新しい取り組みを始めたにもかかわらず、現場の日々の仕事はほとんど以前のままです。Excelでのデータの受け渡し、Slackでの進捗確認や承認依頼、部門間に存在する変わらない待ち時間など。
問題は適切なモデルを利用できていないことではありません。多くの取り組みが、既存のプロセスにAIを「乗せる」だけで終わっていることです。
これでは何も変わりません。非効率なプロセスの一部が少し速くなるだけで、誰も「これはゲームチェンジャーだ」とは感じません。最悪の場合、経営陣に「AIは使えない」「効果は限定的だ」という印象を与えてしまいます。
以前にも見た光景
1990年、Michael Hammer氏は『Harvard Business Review』で、ITに多額の投資をしても十分なROIを得られなかった企業について論じました。
「情報技術への多額の投資は、期待外れの結果に終わってきた。主な理由は、企業が古いやり方をそのままにして、それを技術で機械化しようとするからだ。既存のプロセスを変えず、コンピューターを使って単に処理を速くしているだけだ。」
この指摘は、「情報技術」を「AI」に置き換えれば、そのまま今のAIにも当てはまります。Hammer氏はこの状況を「paving the cow paths（けもの道の舗装）」と表現しました。仕事の進め方そのものを再設計するのではなく、非効率な道をそのまま自動化するという意味です。
英国のDepartment for Business and Trade（ビジネス・貿易省）は、Microsoft 365 Copilotの試験導入を行い、その結果を公表しました。その結果は、企業がAIによって「非効率な道を舗装している」可能性を示しています。
1,000ライセンスを3か月かけて展開したところ、Copilotの利用は1人あたり1日平均1.14回にとどまりました。PowerPointの資料作成は18分から11分へ、7分短縮されましたが、品質スコアは半分でした。Excelの分析はむしろ遅くなり、品質も低下しました。メールにかかる時間の削減効果も、報告書いわく「極めて小さい」ものでした。
同省の結論は「時間短縮が生産性の向上につながっているという確かな証拠は見つからなかった」というものでした。それでも、72％の利用者が「満足」または「非常に満足」と回答しています。
これは、AIによって既存の仕事の進め方をそのまま「舗装している」ようにも見えます。もちろん、利用者はAIを気に入ります。プロセスを変えなくても、毎日少し時間を節約できるからです。
しかし、これは本当の変革でしょうか。
働く人はより多くの仕事をこなせるようになったのでしょうか。それとも、同じ量の仕事を少し速く終えられるようになっただけなのでしょうか。
英国の調査結果は、まさにその実態を映しています。
なぜAI変革の実行は、これほど難しいのか
これは主に、組織の設計とインセンティブ構造の問題です。
AI導入を決裁する担当者は、多くの場合、ツールやベンダーの選定を担います。しかしプロセスそのものを管轄しているわけではありません。営業部門や財務部門に入り込み、「今の14ステップを5つにすべきだ」と言える権限を持つ人もいません。そのため、プロセスそのものには手をつけず、既存のプロセスにAIを乗せることを選びます。結局、簡単なほう、つまり現状維持が選ばれるのです。
現状維持は、キャリアの面では安全です。一方、プロセスの再設計にはリスクが伴います。再設計したプロセスにAIを組み込み、結果的に失敗すれば、その失敗の責任を負うことになります。それに対して、大量のライセンスを購入してAIが期待どおりに機能しなかったとしても、モデルやベンダーのせいにして、次の製品に乗り換えれば済みます。
なぜAI変革の実行は、これほど難しいのか
本当のAI変革を成し遂げるのは、AIライセンスを大量に導入する企業ではありません。未来の概念やアイデアを描いた立派な資料を作る企業でもありません。予算はあっても、既存のプロセスを変える権限を持たない「デジタル革新チーム」を置く企業でもありません。
本当のAI変革を実現するのは、現場の担当者とともに業務を見直し、ワークフローを再設計し、実際のシステムに実装し、本番環境でAIエージェントを継続的に運用できるチームです。そこでは、評価（evals）、ガバナンス、モデル非依存のハーネス、Human in the Loopによるガードレールを整える必要もあります。
こうした役割を担うのが、Forward Deployed Engineer（FDE）です。FDEの仕事は、複雑で非効率な業務プロセスをAIによって支えられるシステムへと変えることです。
企業はFDEをどのように確保するかを決める必要があります。選択肢の一つは、現在利用しているSIとの提携です。ただし、誰でもFDEを名乗れますが、実際にこの仕事を経験している人はごくわずかなため、注意が必要です。
もう一つ、有力になりつつある選択肢が、社内のソフトウェアエンジニアをFDEへ育成することです。一定のトレーニングは必要ですが、多くの企業にとって費用対効果の高い方法だといえます。市場からFDEを採用できたとしても、非常に高い給与を求められるでしょう。
技術者の多くは、これまで現場の担当者の隣に座り、日々の業務プロセスを深く理解する経験をしてきませんでした。FDEの役割には、コンサルティングに近いスキルが求められます。こうしたスキルは、トレーニングによって身につけるか、AI関連プロジェクトで豊富な経験を積むことで培う必要があります。
では何をすべきか。Ichizokuの実践ガイド
技術者の多くは、これまで現場の担当者の隣に座り、日々の業務プロセスを深く理解する経験をしてきませんでした。FDEの役割には、コンサルティングに近いスキルが求められます。こうしたスキルは、トレーニングによって身につけるか、AI関連プロジェクトで豊富な経験を積むことで培う必要があります。
1. 部門から始め、ワークフローを1つ特定する
財務や営業部門、コールセンター、サポートなどから、「ステップが多い・毎日何度も繰り返される・複数の人が関わる・複数のシステムからデータを集める必要がある」ようなワークフローを探します。
2. プロセスを整理し、現場の担当者に話を聞く
プロセスにはデータログがありますが、非効率がどこにあるのかを本当に知っているのは、実際にその仕事をしている担当者です。隣に座り、質問し、話を聞きます。インタビューを通じて、FDEは設計やシステム構築の判断を左右する現場の複雑な事情を理解します。
3. 実際の業務の流れを整理する
プロセスがどのように進むのかをステップごとに整理します。想定どおりに進む「ハッピーパス」はどれか。例外は何か。イレギュラーが発生する経路はどれで、どのくらいの頻度で発生するのか。上流・下流のSoR (システム・オブ・レコード) を整理し、どのような状況で何がSoT（信頼できる唯一の情報源）となるのかを明確にします。最後に、将来のシステムに誰が責任を持つのかを明確にします。
4. すべてのステップを3つに分類する
- 決定論的ソフトウェア：XならYとなるような判断を必要としない処理。安価、検証可能、ハルシネーションがないもの。
- エージェント型：判断や知性を必要とする処理。許容できるリスクの範囲内で、出力を測定できるもの。
- Human in the Loop：AIに任せるにはリスクが高すぎる処理。エージェントが根拠を用意し、人間が次の判断を行うもの。
5. 構築前にKPIをベースライン化する
12か月後に「あの指標が、以前の3倍になった」と言えないのであれば、それはプロジェクトではなく、単なるデモです。何をもって成功とするのかを、あらかじめ決めておきます。
適切に進めれば、25ステップあるプロセスは、いくつかのエージェントの作業と決定論的なコード、そして人間による2つのチェックポイントを組み合わせたシステムへと変わります。25回LLMを呼び出すような仕組みにはなりません。
おわりに
後付けのAIはプロセスに変化を加えるものですが、それだけでは変革とは呼べません。
本当のAI変革は、業務プロセスを再設計し、従来型の自動化、AIエージェント、人間による確認プロセスを戦略的に組み合わせることで実現します。そして、その成功は処理時間の短縮だけでなく、実際のビジネスKPIによって測定される必要があります。
これがIchizokuの仕事です。私たちは既存のプロセスにAIを乗せるだけではありません。FDEチームが担当者の隣に座り、現在のプロセスを整理し、どのステップにAIが必要で、どのステップには必要ないのかを見極めます。そしてお客様とともに、プロセスを再設計し、生産性を3倍、4倍、5倍へと高めます。
では、何から始めるべきでしょうか。
まず最も遅く、最も複雑なワークフローを特定してください。長い待ち時間と絶え間ない受け渡しに悩まされている、あのワークフローです。FDEとのワーキングセッションで、先行指標となる品質指標を定め、すべてのステップを標準のコード、AIエージェント、人間によるレビューのいずれかに分類します。
もしそれができないのであれば、自社の業務を具体的に分解できていない証拠です。その段階では、AIエージェントはまだ必要ありません。手にしているのは、動くシステムではなく、ただのデモにすぎません。
上記のようなプロセスでお悩みの方は、ぜひこちらから無料相談をご利用ください。あるいは、自社で進めるために技術スタッフをFDEとして育成したいという場合は、こちらをご覧ください。
より良い未来を築くために、今こそ動き出す時です。
【FAQ】よくある質問
1. 「けもの道の舗装」とは何を指しますか？
仕事の進め方を再設計せず、非効率なプロセスをそのままAIで自動化することです。Michael Hammer氏が1990年にIT投資の失敗を表現した言葉で、そのまま今のAIにも当てはまります。
2. AIを導入しても成果が出ないのはなぜですか？
多くの取り組みが、既存プロセスにAIを乗せるだけで終わっているためです。非効率な処理が少し速くなるだけで、働く人がこなせる仕事量は増えません。
3. 英国政府のCopilot検証では何がわかりましたか？
1,000ライセンスを3か月展開しても、利用は1人1日平均1.14回にとどまりました。資料作成は速くなった一方で品質は半分になり、時間短縮が生産性向上につながる確かな証拠は見つかりませんでした。
4. AI変革の実行が難しいのはなぜですか？
主に組織の設計とインセンティブ構造の問題です。AI導入の決裁者にはプロセスそのものを変える権限がなく、キャリア上も安全な現状維持が選ばれやすいためです。
5. 「デモ」か「本当の変革」かは、どう見分けますか？
プロセスオーナーがコントロールプレーンで稼働中のエージェントを可視化し、コードを書かずに停止や権限変更を行います。重要な判断の前ではHITL（Human-in-the-Loop）が処理を止め、必要に応じてSlackやTeams、メールで担当者に通知します。着手前にKPIをベースライン化し、12か月後に成果を数値で示せるかどうかが分かれ目です。最も遅く複雑なワークフローを、標準のコード・AIエージェント・人間のレビューに分類できなければ、まだ業務を分解できていない段階です。