Reindeerの共同創業者兼共同CEO、Yoav Naveh――インタビューシリーズ

Yoav NavehはReindeerの共同創業者兼共同CEOで、テクノロジー企業の立ち上げや事業の拡大、創業者への投資に携わってきた経験を持つ。Reindeerを立ち上げる前にはConvertMediaを創業し、その後Taboolaで事業に取り組み、INT3を通じて投資を行った。現在は、企業が個別のAI導入にとどまらず、複雑な業務を担い、人間の専門知識から学び、業務プロセスが変化しても信頼性を保てるエージェントを活用できるよう支援している。

Reindeerは、財務、サプライチェーン、物流、シェアードサービスなど、幅広い分野の基幹業務を担う企業向けAIエージェントを開発している。同社のプラットフォームは、ワークフローの実行に専門家からのフィードバックや評価、人間による承認を組み合わせ、例外や変化する方針にエージェントが適応できるようにする。本インタビューでは、エンジニアリングへの依存度が高い導入モデルの限界、組織に蓄積された知識をエージェントのコンテキストに取り込む方法、そして時間の経過とともに人間の作業負担全体を減らすために必要なガバナンスと効果測定について、Navehが語る。

ConvertMediaを立ち上げ、Taboolaで事業を拡大し、INT3を通じて他の創業者に投資した後、再び会社を立ち上げようと思ったのはどのような課題があったからですか。また、その課題はReindeerを共同創業する決断にどう影響しましたか？

AI市場の盛り上がりは、傍観していられないほどでした。共同創業者のYairと私は、個人でAIを使う際には非常に有用になっている一方で、企業が大規模に導入するのは依然として難しいというギャップに強い関心を持つようになりました。テクノロジーは驚くべき速さで進歩していますが、その可能性を実質的な業務変革につなげられずにいる組織が、今なお大半を占めています。

AIは企業の業務のあり方を変革します。しかし、そこに至るにはテクノロジーの改善だけでは不十分です。仕事の進め方を見直す意志のあるリーダーシップと、新たな複雑さを生み出すことなく、日々の業務にAIを取り入れる実践的な方法が必要です。

この課題がReindeerの方向性を形づくりました。私たちは、企業が最初のエージェントを導入するところから、人間のフィードバックを通じて学び、時間とともに改善するエージェントの群れを構築するところまで支援するプラットフォームを開発しました。AIの可能性と現実の導入とのギャップを埋め、すべてのエージェントを作り直したり、絶えず保守したりすることなく、企業が基幹業務をエージェント型AIの労働力へと変革できるよう支援することが私たちの目標です。

現場に深く入り込むエンジニアリングモデルは、企業向けAIを労働集約型のサービス事業に変えてしまうリスクがあると、あなたは指摘しています。現場に組み込まれたエンジニアリングは、どこで持続的な価値を生み、どこから顧客の規模拡大を妨げる依存関係になってしまうのでしょうか？

現場常駐エンジニア（FDE）は、複雑な統合や、初期エージェントを本番環境に導入するうえで大きな価値を発揮します。問題が始まるのは、業務プロセスそのものが変わったときに、エージェントがその業務を遂行し続けるためにFDEが恒常的に必要になる場合です。とりわけ、大規模に展開する場合はそうです。エージェントが5つならFDEモデルは機能します。しかし、100のエージェントを抱えるようになると成り立たなくなります。

新しいワークフローや予期せぬ例外が発生するたびに、さらにエンジニアリングが必要になるなら、拡大しているのはソフトウェアではなく、高コストな人手です。

FDEを導入している企業の多くは、エンジニアはいずれ別の業務に移ると主張します。FDEを必要とする契約を結ぶ前に、本当にそうなるという証拠を企業は求めるべきです。業務プロセスの変化に伴い、RPAがいかに脆弱になったかは、すでに目の当たりにしてきました。人手で構築したエージェントだけは違うと考えるべきではありません。

企業のワークフローには、文書化されていない例外や、チーム間で相反する慣行がしばしば存在します。Reindeerは、業務の実際の進め方をどのように把握し、自動化に役立つ組織内の知識と、自動化すべきではない慣習をどう見分けているのでしょうか？

大半の企業には、どこにも文書化されていない組織内の知識が膨大にあります。そうした知識は従業員の頭の中に蓄積されています。私たちのエージェントは、限られた知識をもとに始動し、実際の事例を通じて学びます。経験のない状況に直面すると、該当分野の専門家に助言を求めます。

ただし、従業員から学ぶことは、その人の行動を無批判に再現することを意味しません。私たちのシステムは、個別の例外と繰り返し現れるパターンを区別し、より広範な変更を提案して、人間の承認を求めます。

私たちが目指しているのは、あらゆる慣習を自動化することではありません。エンジニアがあらゆる状況を事前に想定する必要がないようにしながら、価値ある組織内の知識を信頼できる知見へと変えることです。

エージェント型AIを手がける企業の多くは、まずプロセスを文書化し、関係者への聞き取りや過去のデータの綿密な調査を通じて、それをコードに落とし込むところから始めます。しかし実際には、プロセスを最も効果的に学ぶ機会は、新しいチームメンバーが加わるたびに訪れます。彼らは1年分のデータや3,000ページの標準業務手順書（SOP）を暗記するわけではありません。いくつかのスキルを身につけ、事例をいくつか見て、仕事を始め、理解できないことがあれば質問し、知識を築いていきます。私たちが構築したのは、このプロセスです。

エージェント型AIは、現状のプロセスをそのまま自動化するのではなく、企業がプロセスを再構想する機会ももたらします。人間だけのチーム、ルールベースの自動化、従来型のソフトウェアは、それぞれ固有の限界に合わせてプロセスを形づくってきました。エージェントが専門家とともに学ぶことで、Reindeerは企業がプロセスのあるべき姿を見直せるよう支援します。その際、どの慣行を残し、どれを廃止するのか、またエージェントと人間がそれぞれどこで最大の価値を発揮するのかも検討できます。

Reindeerのエージェントは本番環境で継続的に学習するとおっしゃっていますが、実際に変化するのは何でしょうか。モデルの重み、メモリ、ワークフローのロジック、それとも明示的なポリシーでしょうか。例外を通じてエージェントが学び、今後の事例に異なる対応をするようになる過程を、具体的に説明していただけますか。

変化するのは、エージェントのコンテキストとスキルです。つまり、ワークフローのロジックやポリシー、それぞれをいつ適用するかについての指示です。

請求書処理エージェントを例に挙げましょう。発注書の金額を4%上回る請求書を受け取り、それに適用できるポリシーが見つからなかったとします。処理を進める代わりに、エージェントは専門家に対応を引き継ぎます。専門家は、この仕入先には燃料サーチャージに関する承認済みの例外があると説明します。エージェントはその案件を処理し、説明はその仕入先に限ったコンテキストとして保存されます。

同じ種類の例外が別の仕入先でも発生し、ほかの専門家も同じ方法で対応した場合、システムは「契約で認められている場合、5%までの燃料サーチャージを許容する」といったポリシー変更を提案します。エージェントがその変更を適用する前に、提案はテストと人間による承認を経ます。専門家一人の回答で解決するのは一つの案件です。複数の案件に見られるパターンは、新たなルールの候補になります。

ある従業員の判断は、特定の顧客や取引には適切でも、一般的なルールとしては適さない場合があります。フィードバックを一度限りの例外として扱うべきか、ポリシー変更の提案につなげるべきか、どのように判断していますか。

個別の案件を解決することと、今後のエージェントの動作を変更することは、別々に扱っています。

従業員がある顧客について例外を認めたとしても、同じ例外をすべての顧客に適用すべきとは限りません。同じ顧客の例外でも、従業員によって異なる対応をすることがあると、私は考えています。私たちのシステムは状況を評価し、繰り返し現れるパターンを特定し、矛盾を調整するとともに、既存のポリシーと衝突する可能性がないかを確認します。

より広範な変更を裏付ける証拠が得られた場合、エージェントを私たちの評価プラットフォームで実行します。いわばエージェントのための「トゥルーマン・ショー」です。そのうえで更新を提案し、人間による承認を求めます。

目指しているのは、人間から学ぶことであり、人間の判断を無批判にそのまま再現することではありません。そうでなければ、単に間違いを自動化するだけです。

エージェントは直近の案件への対応を改善する一方で、以前は正しく処理できていた状況への信頼性が低下することがあります。変更案が本番環境に反映されるまでに、どのようなテストと承認のプロセスを経る必要がありますか。また、性能の後退をどのように検知し、元に戻すのでしょうか。

ガバナンスのない継続的な学習は危険です。そのため、変更案はすべて、回帰テスト、人間による承認、そしてエージェントが自律的に行動するタイミングを制御する信頼度のしきい値という、3つの安全策を通過します。

最初に行うのはテストです。業務には決まった正解がないため、これは聞こえ以上に難しい作業です。専門家からのフィードバックをもとに代表的な事例を選び、出力を比較する基準を定めたうえで、現行のエージェントと変更案の両方に同じ事例を適用して再検証します。メールの送信など、副作用を伴うアクションは過去の実行履歴をもとに構築したシミュレーターで実行し、現行のポリシーに合わなくなったテストケースは廃止します。変更の真の効果を測定するには、エージェントが現実世界にいると認識し、その行動が実際の結果をもたらす必要があります。たとえば、SAPに記録が登録されたり、顧客にメールが送信されたりします。エージェントごとに真の評価フレームワークを構築するには、これしかありません。

その後、人間のマネージャーが変更内容とその根拠となる証拠、テスト結果を確認し、承認、修正、または却下できます。承認されるまでは、エージェントの動作は何も変わりません。

変更の適用後は、信頼度のしきい値が事業を守ります。エージェントが自律的に行動するのは、信頼度がしきい値を超えた場合に限られ、それを下回る案件はすべて専門家に回されます。運用チーム自身がこのしきい値を調整できるため、慎重な設定から始め、実績が積み上がるにつれてエージェントにより大きな自律性を与えられます。

変更後に品質が低下した場合、システムは自動的にレビューのしきい値を厳しくし、より多くの案件を専門家に回します。専門家からのフィードバックによって、変更を提案したときと同じサイクルを通じて問題が明らかになります。ポリシー変更はすべてバージョン管理され、変更者を特定できる形で記録されるため、チームは何が変わったのか、誰が承認したのか、その理由は何かを確認し、以前のバージョンに戻すことができます。

エンジニアリングの作業を減らしても、例外の確認やエージェントの修正を担う運用チームには、依然として大きな負担が残る可能性があります。Reindeerがその負担を別のチームに移すのではなく、必要な人手を全体として減らしているかどうかを、どのように測定していますか。

実際、多くの企業ではすでに、こうした作業を手作業で行うチームがあります。私たちの目標は、その負担を別のチームに移すことではなく、時間をかけて減らすことです。既存チームの中から最も経験豊富な人たちを選び、例外への対応や、より適切な判断を自律的に行う方法をエージェントに教えられるよう支援します。

FDEモデルの問題は、比較的人件費の低い運用担当者から、高額なエンジニアへと作業を移すことが多い点です。それでは人手の問題を解決するどころか、コストを増やすことになります。Reindeerは、その構図にエンジニアを加えません。代わりに、時間の経過とともにエージェントが自律的に処理できる作業がどれだけ増えるか、そしてプロセス全体で必要な人間の介入がどれだけ減るかを、成功の指標としています。

次の3つを追跡しています。人の手を借りずにエージェントが最初から最後まで解決した案件の割合、1案件あたりに専門家が関与した回数、そしてエージェントと人を合わせた1案件あたりの総処理時間です。3つ目の数値が減っていなければ、単に作業を別のところへ移しただけです。

Hellmann Worldwide LogisticsまたはPapaya Globalでの導入事例を1つ取り上げ、稼働開始から継続運用に至るまでに何が変わったのか、説明していただけますか。精度、例外の発生率、処理時間、人の介入が必要な量には、どのような変化がありましたか。

Hellmann Worldwide Logisticsは、エージェントが実際の業務を時間とともに改善できることを示す好例です。同社の価格設定チームは、メールやスプレッドシート、その他の書類に分散した出荷依頼を手作業で処理するのに膨大な時間を費やしており、見積もりの作成に何日もかかることがよくありました。

まず、業務の流れを把握してエージェントをトレーニングするため、約20件のサンプル依頼を用意しました。その後、Hellmannの価格設定の専門家がシステムを直接使い始め、フィードバックを提供しながら、例外への対処を支援しました。テスト期間中は精度と処理速度を追跡し、エージェントの本番稼働後もパフォーマンスの監視を続けました。

現在、定型的な依頼は自動で処理され、より複雑な案件はチームにエスカレーションされます。重要なのは、エージェントが情報不足に気づいた際に憶測で補わず、そのことを認識する点です。これにより、従業員は専門知識が本当に必要な場面で介入できます。

その結果、見積もりの処理時間が短縮され、手作業によるデータ入力が減り、顧客対応により多くの時間を割けるようになりました。Hellmannでは、見積もりの受注率も向上しています。目的は業務から人を排除することではなく、介入が必要な定型業務の量を継続的に減らすことです。

このアプローチの限界について、どのようなことが分かりましたか。どのような業務フローであれば適応型エージェントを導入する準備が整っていると判断でき、どのような場合には、まず業務プロセスを再設計するか、従来型の自動化を維持すべきだと考えられますか。

すべてのプロセスにAIエージェントが必要なわけではありません。最も有望なのは、反復性が高く大量に発生し、状況に応じた判断が求められる業務フローです。特に、情報が複数のシステムにまたがり、従業員が日常的に例外へ対処している業務が該当します。

導入事例から得られた最も明確な教訓は、企業内に新たな機能が生まれつつあるということです。CRMとともに収益オペレーションが、クラウドとともにDevOpsが生まれたのとよく似ています。企業が少数のエージェントから大規模な群れへと移行するにつれ、部門長が人員を管理するようにエージェントを管理する担当者やチームが必要になります。その役割には、エージェントのKPIとROIに責任を持ち、どの業務をエージェントに任せ、どの業務を任せないかを決め、エージェントの変更を承認することが含まれます。すでにこの機能の構築に着手している企業は、最も速く前進しており、勝者となる可能性が高い企業です。

業務慣行に食い違いがあるからといって、導入を待つ必要はありません。ほぼあらゆる業務で専門家の意見は食い違います。私たちのシステムは、そうした矛盾を明らかにし、ポリシー案へとまとめるよう設計されています。その解決は担当責任者の役割の一部であり、エージェントを拡大する前にその役割を設けるべき理由でもあります。

このアプローチ自体にも限界があります。中核業務が完全に自動化されることはなく、私たちもそれを目指していません。エージェントの対応範囲は段階的に広がりますが、リスクの高い案件は意図的に人が担当し続けます。

基盤モデルやエージェント構築ツールの性能が向上するにつれ、企業への導入におけるどの部分がコモディティ化すると予想していますか。また、本番環境への導入を重ねるごとに強まる優位性を、Reindeerはどのように築いていますか。

基盤モデルは、安価かつ高速になり、性能も高まるにつれて、互いに置き換え可能なものになっていくでしょう。基本的なエージェントを構築し、企業システムに接続することも、すでに容易になりつつあります。

しかし、エージェントを構築することと、複雑な企業の業務環境で長期にわたり安定して機能させることは同じではありません。

真の競争優位性となるのは、企業が実際にどのように業務を進めているかについての独自の知識です。そうした業務の実態は常に変化します。本番環境での案件を重ねるたびに、エージェントには学習し、将来の例外に対処し、人の介入を減らす機会が生まれます。

モデルは安価になり、エージェントの構築は容易になります。

勝者となるのは、エージェントを長期にわたり稼働させ、実用性を保つために必要な、高コストの人手によるエンジニアリング体制を不要にする企業です。

素晴らしいインタビューをありがとうございました。適応型の企業向けAIエージェント、業務の自動化、人の指導による学習について詳しく知りたい方は、Reindeerをご覧ください。