Ai Workforceのビジョンとビジネスモデル｜中村 龍矢 | LayerX 執行役員 AI・LLM事業部長

ワークフローからエージェントへ

Ai Workforceの詳細について説明する前に、直近のAi Workforceの進化の方向性について説明します。まず、AIによってソフトウェアのテリトリーが再定義された中で、Ai Workforceの最初のターゲットは、いわゆるドキュメントワーク、つまり、「比較的型のある手続きで、ドキュメントをインプットしてドキュメントをアウトプットする」タイプの業務でした。ドキュメントは例えば、決算書、稟議書、営業資料、契約書などです。アウトプットは具体的には、ドキュメントから情報を抽出して別のファイルに転記することや、レビューを加えること、新しいドキュメントのドラフトを作ることなどがあります。従来のルールベースのシステムでは難しい知的な判断が必要だが、一定のルールを反復する単純性があるという点で、知的単純作業と呼んでいました。

これらはAi Workforceの開発を開始した2023年の初期のLLMでも実現できた、 “low-hanging fruits” 的なユースケースでした。具体的には、Ai WorkforceではAIワークフローの機能があり、業務の手続きを複数のタスクの列として定義する仕組みで、多様な業務を実現していました。

しかし、基盤モデルの進化およびエコシステムの成熟を土台に、より難易度も価値も高い、AIエージェントの基盤へとAi Workforceは進化しています。

ホワイトワーカーの仕事において、必ずしも成果物はドキュメントだけではありません。下記の例の通り、ドキュメントはむしろ副産物でしかないこともあります。

• 営業の仕事において、大事なのは営業の提案そのものであり、資料はあくまでそのコミュニケーション手段

• 内部監査やリスク管理の業務は、その証跡としてレポートを作成することはあれど、本質的には適切性を確認する、もしくは問題点を発見するのが目的

AIワークフローからAIエージェントへの進化より、このような、より本質的なアウトプットに向けて人と伴走することを目指しています。AIワークフローは消えた訳ではなく、引き続き型化しやすい業務を安定的に実行するための仕組みとして内包されており、具体的には、AIエージェントの内側でワークフローが呼び出される形となります。

プラットフォームと個社向けのセットアップ

Ai Workforceのビジネスモデルは、顧客横断の共通のプラットフォームと、プラットフォームの機能を使ってお客様別にセットアップ（AIオンボーディング）を行うためのプロフェッショナルサービス（後述）の組み合わせで成立しています。

そもそも、AIエージェントが活躍するために必要な要素は下記の4つだと考えています。

1. ナレッジ: タスクの遂行に必要な背景情報、ノウハウや過去の事例などの情報

2. スキル: タスクを安定的にこなすための体系的に習得された能力

3. ツール: タスクの遂行に必要な外部のサービスや便利なプログラムなどの道具

4. UI: タスクの遂行中に適切に人間のユーザーが介入するためのインターフェース

Ai Workforceは下図の通り、上記の4つに対応した共通の仕組みや部品をプラットフォームとして備え、それを組み合わせて一社ごとにセットアップしていきます。

結果的に、ChatGPT AgentやManus, Gensparkなどの既存の汎用的なAIエージェント製品（上図最下段）とは大きく異なるAI活用が実現できます。

AIにどうスキルトランスファーするか

上記で「スキル」に記載している「ワークフロー・エージェントビルダーと実行エンジン」について解説します。まず、Ai Workforceにおけるワークフローやエージェントは、独自のYAML形式のフォーマットで定義されます。AIがどういうデータをインプットして、どのようなナレッジ・ツールにアクセスし、どのようなプロセスで処理を行なっていくのかが定義するものです。（DSLといえます。）

そして、このYAMLをGUIから設定するための、ワークフロー/エージェントビルダーが存在します。

AIオンボーディングを自動化する「AIプロセスマイニング」

現状、上記のビルダーを使った設定は、プロフェッショナルサービスもしくはお客様において人力で行なっています。しかし、人力でできる範囲には限界があるため、業務プロセスの発掘からワークフロー・エージェントへの落とし込みまでAIで自動化することで、デリバリーをスケールさせることを目指しています。これを「AIプロセスマイニング」と呼んでおり、積極的に研究開発を行なっています。

将来的にはfine-tuningのアプローチでよりなめらかにAIにスキルを習得させることも想定していますが、現時点では、上記のYAMLのような構造的な形とその自動生成の方が、早く多くの業務をAI化できると考えています。

プラットフォーム開発とラストワンマイルを両方やる

上記の通り、プラットフォームを適切に活用する上で、プロフェッショナルサービス（以下略: プロサービス）の存在は必要不可欠です。ビジネスとエンジニアリングで最低一名ずつアサインする形が一般的ですが、それぞれイメージとしては、「そのお客様にとっての、AI活用のCPO・CTO」の役割に相当します。

特に、Ai Workforceのプラットフォームを使ってお客様の最前線で問題解決に当たる役割として、Forward Deployed Engineer (FDE) というモデルを採用しています。これはLayerXが創業時から参考にしているPalantirのモデルとして有名なものです。具体的な中身については、既に色々発信（コンサルタント・FDE）しておりますのでそちらをご覧ください。

コンサル・FDEは役割ではなくビジネスモデル

プロサービスを前提としたソフトウェアビジネスを考える時、その上段のビジョンが重要だと考えます。「先にプロダクトがあって、実際デリバリーし始めると大変だったので、仕方なくプロサービスを導入した」という考え方は間違いと思います。そうではなく「先にお客様・社会の非常に価値がある、でも難しい課題を解きたい、というゴールがあり、その解決のアプローチを設計した結果、顧客横断のプラットフォームの土台と、その上で輝くプロサービスが必要」という順番であるべきです。PalantirのFDEを真似する企業が増えていますが、ここを間違えると、実態として受託開発やSESと変わらない感じになりがちで、英語圏では「なんちゃってFDE」の問題がよく議論されています。

例えば、「プロサービスの効率化のためにプラットフォームがある」みたいな発想になりがちですが、少なくともAi Workforceではそうではありません。もちろん個別の機能としてプロサービスの作業を効率化するものはありますが、プラットフォームの主たる役割はそこではなく、お客様の最重要課題を解くために、プロサービスのクリエイティビティが余すことなく発揮されることです。プロサービスが「好き勝手大暴れ」しても大丈夫なように、プラットフォームとその外側の境界線を適切にデザインする必要があります。

そもそもなぜラストワンマイルまでやるのか？

エンドユーザーまで届ける「ラストワンマイル」はやらずに、プラットフォームにフォーカスし、アプリケーション開発者・開発企業を顧客とした事業の形もありえますし、むしろそちらの方が多いといえます。しかしAi Workforceでは、両方をやり切ることを目指しています。はっきり言ってとても大変ですが、敢えてやりたいと思っています。

我々は「AIがビジネスにもたらすインパクト」について、今の世の中の平均値よりもはるかに大きな期待を持っています。その夢を描き、戦略とアーキテクチャに落とし実現する上では、今は自分たちで作って届ける方が、お客様への価値提供としても、労働人口の問題を本気でAIで解決するというミッションの達成に向けても速いと考えています。

事業成長という意味でも、プラットフォームとラストワンマイルの相乗効果の価値はとても大きく、その代表例であるPalantirは成長率50%程度で四半期売上約1500億円に達しており、時価総額は記事公開時点でトヨタを優に超えています。以前はPalantirはスケールしない、SIerと変わらないといった話をよく聞きましたが、手のひら返しの評価を受けています。

パートナー様とのコラボレーション

一方、プロサービスの部分について、必ずしも内部の組織でカバーするだけではなく、コンサルやSIerのパートナー企業様と一緒にAi Workforceを届ける想定です。（ただし、あくまで、一緒にお客様の課題を解決する「パートナー」であって、SIer様をエンドユーザーとしたプラットフォーム事業というわけではありません。）

本日、野村総合研究所グループのNRIデジタル様とのパートナーシップも発表させていただきました。今後パートナー様との協業により積極的に取り組んで参ります。