既存システムにAIを足す一番簡単な場所:ルールエンジンのelse分岐

概要

企業システムにAIを足す作業は、たいてい大きくてリスクの高いプロジェクトだと思われています。新しいプラットフォームを導入し、データを移行し、何か月もかける——そんなイメージです。でも、必ずしもそうではありません。AIを足す一番簡単な場所は、すでに使っているシステムが自ら空けている場所——ルールエンジンが判定を諦めるelse分岐です。本記事では、なぜそこがAIを迎え入れる最も自然な場所なのか、そこでAIが担う三つのケースは何か、そして連携が実際どれほど簡単かをお見せします。

else分岐がきれいな接点である理由

ルールエンジンは、すでに明確に定義された大多数のイベントを高速かつ正確に処理しています。表現できないものだけがelse分岐へ流れ、今はたいてい「許可してログを残すだけ」、つまり何も起きないまま終わります。これは失敗ではなく、ルールが語れる範囲の境界にすぎません。

そして連携の観点では、むしろ贈り物です。else分岐は既存のルールを一つも触らずに新しい判断を加えられる、コード内の明確な一点だからです。AIをシステム全体に移植するのではなく、システムがすでに開けているその一点に取り付けるだけ。だからこそ、リスクも手間も小さい入り口になります。

ケース1: カバレッジの空白——ルール自体がない

管理者が休暇中に、ERPの承認権限が代理委任された状況を思い浮かべてください。職務分掌(SoD)マトリクスに「委任」という概念がなければ、委任された承認は甘く評価されるのではなく、まったく評価されません。こうしたケースは事前にルールで書けませんが、コンテキストを見れば人は数秒で判断します。まさにAIが得意とする種類の仕事であり、ルールが手つかずのまま残す部分です。

ケース2: コンポジットリスク——各ルールは通過、組み合わせが問題

あるサーバーはパッチも完了、権限も適切、90日以上誰もログインしていません。チェックはすべて緑——なのに合わせて見れば放置された資産です。コンポジットリスクが単一ルールの評価に見えないのは、ルール一つひとつが仕事をしているからです。リスクは複数のシグナルを横断してコンテキストを見たときに初めて現れます。そのコンテキストを見るのは、AIには容易で、単独で動くルールには不可能です。

ケース3: コンテキスト依存——条件が言葉でしか存在しない

このマクロの意図は何か?セッションをまたぐこの移動は異常か?オペレーターが毎日答えている本物の問いですが、どれも数値しきい値には変換できません。ルールエンジンには「意図」を入れる構文がないため、この問いはそもそもエンジンに入りません。逆に、周辺のコンテキストとともにモデルに渡せば、答えられる問いになります。

「ルールを増やせばいい」が答えでない理由

反射的に出る答えはルールの追加です。しかしelse分岐は縮みません。三つの構造的な理由があります。

• カバレッジの空白は事後にしか見つかりません——だからルールは常に現実より一歩遅れます。
• コンポジットリスクはルールの組み合わせに関するルールを要します——組み合わせの数が爆発的に増え、どのチームも書き切れません。
• コンテキスト依存の条件はしきい値になれません——条件そのものが数値ではなく言語だからです。

ルールを増やせばカバー範囲が密になるだけです。一方、else分岐にAIを一度取り付ければ、三つのタイプを同じ場所でまとめてカバーできます。手間が増えるのではなく、むしろ減る理由です。

三つのケースを一覧で

実際どれほど簡単か

接点がすでにあるので、連携は本当に小さな作業です。ルールエンジンが判定を流してしまうその地点で、「許可してログ」の代わりに判定を一度リクエストするだけです。

# 既存の決定論的ルールはそのまま、高速に実行されます。
verdict = rule_engine.evaluate(event)
if verdict is None:  # else分岐: 該当ルールなし
    # まさにこの接点にAIを足します——周辺コンテキストを一緒に渡します。
    verdict = crux.evaluate(event, context=gather_context(event))
route(verdict)  # 返ってきた判定を決定論的にそのまま処理

返ってくる判定は、わけのわからないスコア一つではなく、確信度と根拠まで含んだ構造化された決定です。だから既存パイプラインがそのまま処理でき、確信度の低いものは静かに素通りする代わりに人間のレビューキューへ上がります。

{
  "verdict": "risk",
  "confidence": 0.88,
  "mode": "AGENT",
  "signals": ["patch_ok", "perms_ok", "idle_92d"],
  "rationale": "個別には準拠するシグナルが組み合わさり、放置資産リスクを形成。"
}

SIプロジェクトのように導入します

一度に一接点ずつ取り付けるため、この方式はプラットフォーム移行ではなくSI(システムインテグレーション)プロジェクトのように進みます。else分岐が最も多く発生する、価値の高いドメインを一つ選び、そこに判定APIを接続し、少数のケースで検証したうえで、ERP・運用・財務のようにドメイン単位で広げていきます。Cruxがまさにそのレイヤーです。すでに稼働しているシステムのelse分岐に取り付くAI判定レイヤーです。

結論

AI導入は再構築である必要はありません。要点は次のとおりです。

• 一番簡単な入り口はすでにあります——ルールが自ら空けているelse分岐です。
• 三つのケースがまさにAIの仕事です——カバレッジの空白、コンポジットリスク、コンテキスト依存。
• システム全体の改修ではなく接点一つです——呼び出し1行、ルールはそのまま。
• 小さく始めて広げます——一つのドメインでパイロットし、データを根拠に拡張します。

次のステップ: 価値の高いルールエンジンを一つ選び、今else分岐にどれだけ到達しているかを測り、その一接点だけに判定をパイロット導入してみてください。Cruxが既存システムにAIを足す方式を見る、または専門家に相談する。