「エージェント」という言葉は、もはや意味をなさなくなっています。現在では、どのエンタープライズ ソフトウェア ベンダーも口を揃えて、AI エージェントを提供していると謳っています。しかし、AI がワークフロー外の別個のツールとして提供されると、導入は失敗に終わるケースが少なくありません。確認しなければならないダッシュボードや、管理しなければならないシステムが増えるとなると、敬遠されるものです。
これはテクノロジーの問題ではなく、アーキテクチャの問題です。そしてこれこそが、AI に多額の投資をしている多くの組織が期待外れの成果しか得られていない理由です。
Anaplan では、お客様や業界のリーダーと緊密に連携し、実用的で信頼できる AI と、いずれ失敗に終わる AI とを分ける要因を追求してきました。ヒントは、単に機能の多さやモデルの優劣だけが原因ではないという点です。AI「エージェント」とは本来どのようなものであるべきか、そして、どこに存在すべきかを根本から見直すことが必要です。
自律性をめぐる混乱
ベンダーが「自律型エージェント」について語るとき、しばしばまったく異なる２つの概念を混同しています。
１つ目はトリガーの自律性、つまり、AI が「いつ実行されるか」です。これには、スケジュール実行、Webhook、メール トリガー、イベントベースのワークフローなどが含まれます。高度なことに思えますが、単なる自動化に過ぎません。こうしたことは何十年も前から Cron ジョブで実現されてきました。深夜に起動してフォーキャストを更新するワークフローは、エージェントではなく、手順が追加されたタイマーにすぎません。
２つ目は推論の自律性、つまり、AI が「どのように問題を解決するか」です。ここに真のインテリジェンスが存在します。推論エージェントは、スクリプトに従うのではなく、どのツールを使うべきかを自ら判断します。発見した内容に対応し、新しい問題に対して複数ステップのアプローチを計画します。エラーや行き詰まりから回復することも可能です。
テクノロジー業界はトリガーの自律性には非常に長けており、それをイノベーションのように見せてきました。しかし、推論の自律性を伴わないトリガーの自律性は、実態の薄い作業を高速化しているに過ぎません。つまり、間違ったものを自動化しているのです。
本物の AI エージェントが実際に行うこと
あるものが本当に「エージェント」と呼べるかどうかを評価するためのシンプルなフレームワークがあります。私たちはそれを OARE と呼んでいます。これは、Observe (観察)、Act (行動)、Reason (推論)、Evaluate (評価) の頭文字を表しています。
- Observe (観察、コンテキストの収集): 単にデータを取得するだけでなく、状況全体を理解することを意味します。プランニングにおいて、これは、先週火曜日にスプレッドシートにエクスポートされた静的なスナップショットではなく、ビジネス全体のライブ モデルやリアルタイムのシグナルと接続することを意味します。
- Act (行動、ワークフロー内での実行): 本物のエージェントは、プランニング フローの外側ではなく内部で変化を起こします。フォーキャストを更新し、想定を調整し、下流のプロセスをトリガーします。テキストを生成することしかできないエージェントは、エージェントではありません。それは、非常に高価なオートコンプリート (自動補完) 機能に過ぎないのです。
- Reason (推論、一線を画す推論): 価値の高いエージェントは、単にプロンプトに応答するだけではありません。逆に質問を投げかけ、想定の妥当性を問い、深く考えさせます。最近の Gartner との対話でも、アナリストは真の差別化要因は「会話」ではなく「推論」であると明言しています。ユーザーが必要としているのは、新しいチャット インターフェースではありません。自身の意思決定についてより明確に考えさせる何かなのです。
- Evaluate (評価、結果の検証と反復実行): エージェントは結果を振り返り、目標を達成できたかを判断し、次のアプローチを調整します。これが、単発の応答を真の問題解決へと変えるループなのです。
これは単に理論で処理されるものではありません。たとえばファイナンス チームが「今週は何を優先すべきか」という一見シンプルな問いを投げた場合、その答えには深いコンテキスト、複数システムにまたがる情報の把握、そしてさまざまなシナリオやトレードオフを考慮する推論が必要です。質問自体はどうと言うことがないように見えても、それに効果的に答えるためには深い処理が必要です。この処理ができないエージェントは役に立ちません。単に確認すべきインプットが一つ増えるだけなのです。
ワークフローの外側ではなく内部で機能
私たちが一貫して確認しているパターンがあります。それは、ユーザーがすでに「やるべきだ」と分かっている業務から摩擦を取り除くと、AI の導入に弾みがつくということです。「業務の刷新」でも「プロセスの変革」でもありません。同じ仕事をより効率的に行い、その分浮いた時間をより良い思考や判断に振り向けられるようにすることが重要なのです。
このため、Anaplan のインテリジェントなロールベースのエージェント (Finance Analyst、Sales Analyst、Supply Chain Analyst、Workforce Analyst) は、プランニング フローの外側ではなく、内部で機能するように設計されています。これらのエージェントは、売上、コスト、利益率、キャッシュフロー、業務ドライバーに関するシグナルを継続的に監視します。そして変化が起きると、単にアラートを送るだけでなく、対応策を提案します。
実際の OARE ループは、次のようになります。
- Anaplan の Finance Analyst が、特定の販売地域で予期せぬ需要の急増を検知します。
- そして、下流への影響 (売上予測、利益率への影響、リソース要件) について推論を行います。
- 更新されたシナリオを生成し、「What-if」分析を開始します。
- そのシナリオが変化を適切に反映しているかどうかを評価します。
- そして重要な点として、これを人間に提示し、意思決定を委ねます。
これこそが、エンタープライズ プランニングで機能するバランスです。エージェントが分析の労を取り、人間は方針を設定し、調整を承認し、ビジネス戦略との整合性を確保します。Gartner 社はこれを概ね 70 対 30 の割合としています。つまり、ベンダーが標準機能としてロジックや視点の大半を提供し、顧客が徐々に自社固有のコンテキストを重ねていくということです。エージェントのロジックを一から構築したいと思う人はいません。求められているのは、プランニングを理解し、自社のビジネスに合わせて調整できるエージェントなのです。
スピードの問題 (そして CoModeler がそれをどう解決するか)
以上は素晴らしい話に思えますが、ひとつ注意点があります。OARE ループが機能するのは、エージェントが発見した内容に対応できるだけのスピードで、プランニング モデルを構築、修正できる場合に限られます。従来、高度なプランニング モデルの構築には数ヶ月を要していました。ビジネス ロジックをまとめ、計算を検証し、モデルを展開する頃には、当初の状況はすでに変化してしまっていました。これが、多くのプランニング プロセスが常に後手に回っているように感じられる理由です。
Anaplan CoModeler は、この状況を変えます。自然言語を使って、ビジネス ユーザーが複雑なプランニング モデルを数ヶ月ではなく数分で構築、拡張、最適化できるようになります。ここで重要なのは単にスピードではなく、エージェント型のプランニングに必要な迅速な反復処理 (イテレーション) が可能になるということです。手作業でコードを書くことと、インテリジェントな開発環境を使用することの違いだと考えてください。エージェントとモデル ビルダーは、協力者となるのです。迅速にプロトタイプを作成し、シナリオを検討し、想定を検証し、うまくいかないものはすぐに捨てることが可能になり、6 ヶ月もの開発期間が無駄になったと嘆くこともなくなります。
私たちはこれを「バイブ モデリング (vibe modelling)」と呼んでいます。いわばプランニングにおける「バイブ コーディング」です。モデルは不変の成果物ではなく、思考ツールとして、試し、改良を重ねるためのものです。これはプランニング組織の業務の進め方における大きな転換であり、モデルの作成がボトルネックでなくなって初めて実現できることです。
AIOps の台頭
プランニング組織内に「AIOps」チームが設置されるケースが、ますます増えてきています。これは、エージェントやワークフローの作成、トレーニング、ガバナンスに焦点を当てた新しい役割です。 多くの Anaplan のお客様がこれまで構築してきたセンター オブ エクセレンス (CoE) の進化形と言えますが、その業務内容は異なります。
- モデルを構築する代わりに、エージェントが活用する知識や意思決定ロジックを整備/管理します。
- レポートを実行する代わりに、エージェントのビジネス目的との整合性を保つための監視および評価フレームワークを設計します。
- リクエストに対応するのではなく、エージェントが自発的にインサイトを提示する仕組みを設計します。
ここで重要になるのが「コンテキスト キャプチャー (コンテキストの取得)」です。市場における最大の未充足ニーズは、データ アクセスではなく、知識、特定領域の専門知識、意思決定ロジックを捕捉、評価し、徐々に改善していく仕組みのプロダクト化 (体系化) です。これを実現できる組織は、自社のビジネスを本当に理解する AI エージェントを手に入れることができるでしょう。それができない組織は、高価なツールを抱えるだけに終わってしまいます。
AIを中核として構築
Anaplan 後から AI 機能を追加したものではありません。Anaplan のプラットフォームは線形代数エンジンを基盤として構築されています。これは、ニューラル ネットワークや大規模言語モデルの数学的基盤と同じものです。このアーキテクチャにより、リアルタイムのエージェント型プランニングを可能にするスケールでの運用を実現しています。具体的には、本番環境に 210 万のプランニング モデルを展開し、7.3 ペタバイトのモデル ストレージを保持し、ユーザーの平均操作時間は 2.3 秒です。
しかし重要なのはアーキテクチャそのものではなく、それによって実現されるものです。それが、プランニング全体の状況を把握し、ファイナンス、サプライチェーン、営業、ワークフォースにわたる影響を推論し、既存のワークフローの中でアクションを実行し、その結果を継続的に評価するエージェントなのです。
現在のような不確実性の高い環境をうまく乗り切っている企業は、AI 機能を最も多く備えている企業ではありません。 それは、AI が目立たず、既存のワークフローに深く組み込まれており、ツールというよりも「眠ることなく常に推論し、既存の意思決定フローの中で働き続けるアナリスト チーム」のように感じられる企業です。
