7月21日、Hatem Ayedが「Agentic AI in the enterprise: Why architecture matters more than marketing claims」と題した記事を公開した。エンタープライズへのAIエージェント導入において、マーケティング上の謳い文句ではなくアーキテクチャ設計の質が成否を分けるという主張を展開している。

なお本稿はTechRadar Pro Perspectivesへの寄稿として公開されており、著者のHatem AyedはClarvosのCTOを務める。TechRadar Pro Perspectivesは業界関係者・ベンダー幹部によるオピニオン寄稿欄であり、編集部の中立的レビューを経た記事とは性質が異なる点は念頭に置いておきたい。その上で、本稿の主張は業界の実態を突いており、購買判断の参考になる視点を多く含んでいる。

「AIツール」と名乗るだけのルールエンジン問題

マーケティングオートメーション市場を見渡すと、ほぼすべての製品が「AI搭載」を謳っている。しかし実態を見ると、多くは数年前に人間のエンジニアが書いたif/thenワークフローをそのまま動かしているルールエンジンに過ぎない。リードスコアが閾値を超えたらメールを送る、行動A・B・Cが揃ったらシーケンスYを発火させる——そういった仕組みだ。

ルールエンジンは既知のルール範囲内では正確に動く。問題はエッジケースに直面したときだ。想定外の状況が発生すると、エラー・不適切なメール送信・意味不明な出力が起きる。解決策は「ルールを追加・更新すること」だが、世界の変化速度にエンジニアのルール記述が追いつけるはずがない。

Ayedはこの状況を「同じラベル、同じ古いアーキテクチャ」と断じる。ニューラルネットワークをルールエンジンに振りかけるだけで「AIプラットフォーム」と名乗る製品が溢れているが、販売資料の裏側を見ればif/then文が並んでいるだけだ、という指摘は業界関係者には刺さる内容だろう。

真のエージェントが違う理由：「次のルール」ではなく「次の行動」を問う

記事の核心はここにある。

• ルールエンジンが問うこと：「この入力に対して、次に発火すべきルールは何か？」
• エージェントが問うこと：「目標に近づくために、次に取るべき行動は何か？」

エージェントは「目標」「現在のコンテキスト」「利用可能なアクションのリスト」の3要素をもとに推論し、目標達成に最も近づく行動を選ぶ。アーキテクチャは本質的に反応的（reactive）ではなく反復的（iterative）だ。キャンペーンのパフォーマンスが落ちれば自律的に適応し、他のエージェントと連携し、エンジニアがルールを書き直しに介入しなくても動き続ける。

汎用モデルより専門エージェントが有利な場面

Ayedが強調するのが専門化（Specialization）の重要性だ。

汎用AIモデル（たとえばOpenAIのモデル群）はマーケティング戦略の草案や創作テキストは書ける。しかし以下を同時に満たすマーケティング素材を生成することはできない、と指摘する。

• 特定パブリッシャーのピクセル比率要件への適合
• ブランドのカラーパレットとの整合
• ターゲットオーディエンスの感情的親和性プロファイルへの対応
• 前日のトレンドトピックの組み込み

これらを一括して任せられる単一モデルは存在しない。解決策として記事が提示するのが、「エージェントクルー（agent crews）」と呼ばれる専門エージェント群の構成だ。戦略生成専門のクルー、クリエイティブライティング専門のクルー、パフォーマンス分析専門のクルーをそれぞれ構築し、協調させる。汎用システムでは扱いにくいアトミックなワークフローを個別に担わせる設計だ。

プライベートホスティングとデータプライバシー

専門化と並んで論じられるのがモデルのホスティング先だ。公開LLMを使うたびに、データは第三者のインフラへ送信される。「顧客データをトレーニングに使わない」という約款は読み替えれば「入力の取り込み・処理・保存をプロバイダーの内部ポリシーに従って行う」ことと同義だ。そのポリシーはいつでも変わり得る。

また、社内でPIIスクラブのルールを徹底していても、1人の従業員が内部価格データを含むスプレッドシートをプロンプトに添付すればコンプライアンスは崩れる。モデルを自社インフラ内でホストすれば、データが外部に送信される経路そのものが消える。トークン課金モデルによるコストの予測不可能性を排除できる点も、大規模展開では経済的に意味を持つとAyedは論じる。

ガバナンスはアーキテクチャに組み込め

多くのチームはAI生成コンテンツに対してガバナンスを「最後の人間レビュー」として実施している。それ自体は否定しないが、Ayedの主張は「ガバナンスは出力に後付けするのではなく、アーキテクチャの根幹に組み込むべき」だ。

具体的には：予測を設定範囲内に収めるガードレール、各生成物をその起源まで追跡できるオブザーバビリティ、内部テストだけでなくサードパーティによるベンチマーキングの実施、がその要素として挙げられている。

エンタープライズ購買担当が本当に問うべきこと

記事後半ではRFP（提案依頼書）段階での確認項目が整理されている。箇条書きで列挙されているが、それぞれの問いには「ルールエンジンとエージェントでは何が違うか」を見抜く意図が込められており、単なるチェックリストではなくアーキテクチャ評価の軸として読むべき内容だ。

• 目標 vs. ルール：未知データに遭遇したとき何が起きるか？ルールエンジンならフォールバックルールを示す。エージェントなら目標の再評価と行動の再選択を説明する。この回答の違いが、製品が本物のエージェントかどうかを判別する最初の試金石になる。
• モデルとホスティング：どこでホストされているか？ドメイン固有データで学習された専門モデルか？汎用モデルの薄いラッパーであれば、前述の専門化の恩恵は得られない。
• 長期メモリとコンテキスト：組織の文脈を蓄積し、過去の意思決定を記憶できるか？これがあれば、エッジケースのたびにエンジニアが新規ルールを書く必要がなくなる。逆に言えば、この機能を持たないシステムは結局ルールエンジンと同じ運用負荷を生み続ける。
• ハルシネーション対策：どう検出・制限・軽減しているか？専門特化モデルはドメイン内でのハルシネーションが少なく、予測ウィンドウのガードレールと人間の承認ゲートが組み合わさることで実用上のリスクを下げられる。
• ガバナンス／監査可能性：全出力のトレーサビリティを提供できるか？精度評価はサードパーティが行っているか？ベンダーが自己評価のみを根拠にしている場合、前述の「ガバナンスをアーキテクチャに組み込む」という原則が実装されているかどうかを別途確認する必要がある。

詳細はAgentic AI in the enterprise: Why architecture matters more than marketing claimsを参照していただきたい。