By Jay Revels, Ichizoku株式会社 CEO
本記事は、エンタープライズAIのPoCが失敗する根本原因と成果そのものを届けるOaaS（Outcomes as a Service）への転換、その実装と統制の方法を解説します。
重要なポイント
- 成果を届けるOaaSへの転換：ツールを操作させる発想を捨て、AIを業務へ組み込み成果のみを届けるモデルへの移行
- PoC失敗の根本原因：AIを成果ではなくツールと捉え、長年の業務習慣を変えさせようとする設計の限界
- 業務の現場への組み込み：新旧システムを問わず、APIやコンピューター操作エージェントで既存フローへ直接統合
- プロセスオーナーによる統制：コントロールプレーン（Control Plane）で、裏側のAIをコードなしに可視化し即時停止できる体制
社内のAI PoCの多くが失敗するのは不思議なことではありません。その根本原因は、経営層がAIを成果ではなくツールとして捉えていることにあります。現場が求めているのは、仕事を助けるための新しいツールではなく、仕事そのものが完了している状態です。
しかし現在のエンタープライズAIの多くは、依然として「従業員が自ら操作するツール」として提供されています。チャットボットやコパイロットを導入し、「どのように日々の業務へ組み込むかは各自で考えてください」と求めているのです。
つまり、ワークフローの主導権を握っているのはAIではなく、依然として人間です。同じシステムと手順を10年以上使い続けてきた従業員にとって、その習慣を変えることは容易ではありません。新しいUIを追加したところで、長年の業務習慣が自然に変わることはありません。
従業員の行動変容に依存していては、ROIは生まれません。AIを業務プロセスの奥深くまで組み込み、人が意識しなくても成果が生まれる状態をつくること。それが最も確実な方法です。しかし、多くの企業はAIを業務に組み込むのではなく、新しいツールとして追加してしまいます。例えば、複数のエージェントを管理するダッシュボードを全員に提供するという発想です。一見すると合理的に見えますが、実際には定着せず、多くの人は「また一つ管理しなければならないツールが増えた」と認識するからです。
必要なのはツールの追加ではなく、「ツールの削減」です。SaaS全盛期にCRMやERPを導入した時代には、インターフェースそのものが製品でした。人の労働を支えるために、インターフェースが必要だったからです。しかし、知的作業そのものを自動化できる時代に、企業が求めるのはツールではなく成果です。これから価値を生むのは、タスクを支援するソフトウェアではなく、成果そのものを提供するサービスです。
全員が新しいダッシュボードへログインする必要はありません。AIは背景で動き、成果だけを届けるべきです。つまり、SaaS（Software as a Service）の次に来るのは、OaaS（Outcomes as a Service）です。
ではそれをどのように売り、どのように届けるべきでしょうか。
原則①：業務が行われている場所に組み込む
業務がNetSuite上で動いているならNetSuite上、Salesforce上ならSalesforce上に組み込みます。システムの新旧は問いません。そこが実際に事業が動いている現場だからです。
実装方法は大きく二つあります。十分なAPIが存在する場合は、それを活用してデータを直接読み書きします。一方、モダンなAPIを備えていないレガシーシステムでは、コンピューター操作エージェントを活用します。
エージェントは画面を認識し、UIを操作し、人間と同じ手順で業務フローを実行します。エージェントは企業が信頼する既存システムから情報を取得し、既存の業務フローの中で処理を実行し、その結果を正式な記録システムへ直接反映します。従業員は新しいツールを学ぶ必要も、エージェントを管理する必要もありません。これまでどおり業務を続けるだけで、プロセスの裏側にある手作業は自動化されます。
原則②：統制を保ちながらAIを裏側で動かす
経理の買掛担当者が、複数の自律型エージェントを管理しなければ仕事が終わらないのであれば、本末転倒です。システムの統制は、プロセスオーナーが担うべきです。
そのために必要なのが、プロセスオーナー向けのコントロールプレーン（Control Plane）です。どのエージェントが動いているのかを可視化し、コードを一行も書くことなく、業務フローの停止や権限変更、エージェントの即時停止を行うことができます。同時に、ガバナンスはエージェントそのものに組み込まれていなければなりません。
HITL（Human-in-the-Loop）は、重要な判断の前で処理を停止し、人間による介入が必要かどうかを判断します。必要に応じて、SlackやTeams、メールなど、担当者が普段利用しているチャネルへ通知を送ります。また、エージェントは社内規程や業務ポリシーを参照し、熟練した担当者と同等の基準で行動します。
そして、導入支援を前提としたアプローチが不可欠です。Claude Codeのような汎用AIがソフトウェア開発で高い成果を出せるのは、コードという対象が比較的標準化されているためです。
一方で、調達、物流、経理といったバックオフィス業務は極めて属人的です。業務フロー、取引先との関係、データの扱い方などには企業ごとに大きな違いがあり、その多くは文書化されておらず、現場の暗黙知として存在しています。この領域では、ソフトウェアだけでは不十分です。
FDE（Forward Deployed Engineer）が現場に入り、業務フローを可視化し、暗黙知を抽出し、それをエージェント設計へ反映する必要があります。数週間にわたって現場と伴走しながら業務を理解することこそが、実運用で成果を生み出すための鍵です。
問いはシンプルです。AIを使いたいのか。それとも、AIで会社を変えたいのか。
導入のご相談や進め方のご確認は、こちらからお問い合わせください。https://ichizoku.io/japan/
【FAQ】よくある質問
1. なぜエンタープライズAIのPoCは失敗しやすいのですか？
経営層がAIを成果ではなく、ツールとして捉えているためです。従業員が自ら操作するツールとして提供され、業務の主導権が人間側に残るため、行動変容に依存した設計では成果が出にくくなります。
2. OaaSとは何ですか？
知的作業そのものを自動化できる時代に、ツールではなく成果そのものを提供するサービスを指します。SaaS（Software as a Service）の次に来る考え方で、AIが背景で動き、成果だけを届けます。
3. レガシーシステムでもAIエージェントを組み込めますか？
組み込めます。モダンなAPIがない場合は、コンピューター操作エージェントが画面を認識してUIを操作し、人間と同じ手順で業務フローを実行します。
4. 従業員は新しいツールの操作を覚える必要がありますか？
必要ありません。これまでどおり業務を続けるだけで、プロセスの裏側にある手作業が自動化されます。
5. AIを裏側で動かしながら、どのように統制やガバナンスを保つのですか？
プロセスオーナーがコントロールプレーンで稼働中のエージェントを可視化し、コードを書かずに停止や権限変更を行います。重要な判断の前ではHITL（Human-in-the-Loop）が処理を止め、必要に応じてSlackやTeams、メールで担当者に通知します。