6月30日、Dataconomyが「Why I built our agentic BI around a rules engine, not a language model」と題した記事を公開した。この記事では、アジェンティックBI（Agentic BI）の中核にLLMではなくルールエンジンを据えるべき理由と、その設計判断に至った実践的経緯について詳しく紹介されている。「デモは素晴らしかった。実運用はそうではなかった」——その一言が、設計思想を根本から変えた。
LLMを「脳」にしたら失敗した
著者が構築したのは、多拠点の警備・施設管理オペレーションを支援するBI基盤だ。夜勤明けのコントローラーが「今この瞬間、どの問題を最初に処理すべきか」を5秒で判断できるようにする——そのために「推薦を出し、根拠を添え、人間が判断する」という層を作ることを目指した。
最初のバージョンはLLMを中心に据えた構成だった。LLMがイベントを読んでDBからコンテキストを取得し、推薦を生成する。ルール層は薄く、「モデルが賢いから大丈夫」という設計思想だ。
デモは素晴らしかった。実運用はそうではなかった。
モデルはシフト表に載っていない担当者を引用し、同じ状況を2回問い合わせると異なる回答を返した。問題は「間違えること」ではなく、「間違いを再現できないこと」だった。再現できなければテストできない。テストできなければ本番に出せない。チームはゼロから作り直した。
60/40という分割——ルールエンジンが決め、LLMが語る
再構築後のアーキテクチャは「60%ルールエンジン、40%LLM」という割合に落ち着いた。著者の説明によれば、この比率はシステム全体の意思決定ロジックの中でどちらが主導権を持つかを示す概念的な重み付けであり、コード行数やレイテンシの計測値ではない。ルールエンジンが「何をすべきか」を決定し、LLMは「それをどう伝えるか」だけを担う。著者はこれを「ルールエンジンが耐力壁、LLMは漆喰」と表現している。
この設計を選んだ理由は3点が積み重なっている。
① テスト可能性
各ルールには名前、フィクスチャ、期待値、回帰テストがある。「チェックコールの許容遅延を12分から10分に変更する」という業務判断を、変更・レビュー・テスト・リリースという通常のソフトウェア開発フローで扱える。
② 説明可能性
コントローラーが「なぜこの推薦が出たのか」と聞けば、「このルールが発火し、この記録を確認し、このしきい値を超えた」というトレースが返ってくる。プレッシャー下での判断において、根拠を確認できない助言は使われない。
③ 役割の適合
LLMは要約と言い換えに強く、オペレーション上の最終判断には弱い。推薦文の表現が少々ぎこちなくてもコストはゼロだが、エスカレーション判断の誤りは契約損失につながりかねない。
見逃したチェックコールを処理する実例
「06:30のチェックコール（定期安否確認）が未着」というイベントが発生したとする。これは単なる事実であり、そのままでは「軽微な遅延なのか、安全確認が必要な案件なのか、SLA違反なのか」が判別できない。
ルールエンジンはこう処理する：
- 該当サイトは規制対象か？
- 適用SLAは何分か？
- 超過時間は？
- 安否確認は試みられたか？
- 代替要員は手配可能か？
- この担当者に遅延履歴はあるか？
この朝のケースでは「規制対象サイト、チェックコール未着、安否確認未実施、しきい値超過、代替要員あり」と解決し、エスカレーションティア2に分類される。そこで初めてLLMが登場し、構造化された判断を人間が読める文章に変換する：
Site 14の担当者が06:30のチェックコールを逃し、現在14分超過しています。これは15分以内の対応が必要な規制対象サイトです。安否確認の記録はなく、代替要員は待機中です。推奨アクション：今すぐ安否確認を記録し、代替要員を派遣し、当直マネージャーに通知してください。5分以内に連絡が取れなければ、クライアント担当者にエスカレーションしてください。
LLMはエスカレーションを「決定」していない。ルールエンジンが決定し、LLMがそれを伝えた。
「ミスを隠す」が信頼を壊した
初期に著者が犯したのは、システムの誤りを隠すというミスだった。明らかに不正確な推薦は静かに抑制し、表現が微妙なものは事前に修正した。「信頼を守るため」という名目だったが、ベテランのコントローラーに指摘されて気づく——「いつ間違っているかを見たことがなければ、間違っているかどうかわからない」。
そこで方針を逆転させた。現在のシステムは：
- 全推薦に信頼スコアを表示し、低信頼案件は明示的にマーク
- 「なぜこの推薦か」のビューを常に表示（ルールと根拠をトレース可能）
- 推薦を却下した場合、その理由をオープンにログへ記録
- 週次で「最も精度が低かった判断」をチームで振り返る
この最後の習慣が、文化をもっとも大きく変えた。システムが「信用できない外部ツール」から「チームが改善に責任を持つもの」に変わった。
パイロットの結果
著者は数値をベンチマークとして読むべきでないと断った上で、1件のパイロットの結果を公開している。
- 週次シフト準備にかかる時間：ほぼ1日 → 約90分
- チェックコール遅延などの対応率：4割 → 6割（優先度ランキングの導入後）
- 推薦の受諾率：**41% → 78%**（信頼スコアと可視化された根拠の追加、週次レビューの定着後）
受諾率の改善はモデルの精度向上によるものではない。「見える化」によるものだ、と著者は明言している。
もし最初からやり直すなら
著者が提案する立ち上げ手順は6週間のパイロット設計だ。Week 1〜3でルールエンジンとフィードバックログを固め、Week 4以降でLLMを段階的に追加・検証するという順序が肝になる。
- Week 1：対象とする判断を1文で書く（「チェックコールが未着の場合、代替要員を派遣すべきか？」）。1行に収まらなければ対象が大きすぎる
- Week 2：ルールブックをエンジニアではなくオペレーション担当者と書く。15〜25ルールで十分
- Week 3：ルールエンジンとフィードバックログを構築。この段階ではLLMを使わない
- Week 4：LLMを追加するが、「ルールの説明」専用に限定
- Week 5：現場の実際の判断と並走させてシャドウモードで検証
- Week 6：協力的なチームで本番稼働し、受諾率・対応時間・誤検知・見逃しを測定
Gartnerは「アジェンティックAIプロジェクトの大部分が2027年までに廃棄される」と警告している（2025年公開レポート「Top Strategic Technology Trends for 2025」における予測。詳細はGartner社の公式サイトで確認できる）。ビジネス価値が不明確なまま拡大したプロジェクトがその主因だ。1つの判断を証明してからスケールする、というアプローチはその逆を行く。
「より大きなモデル」はほとんどの場合、答えではない。明確なルールブック、見える推論、フィードバックループ——それが実運用で生き残るアーキテクチャの正体だ、と著者は締めくくっている。
詳細はWhy I built our agentic BI around a rules engine, not a language modelを参照していただきたい。
