プロダクションシステムとは：AIの事実・ルール・競合解消

プロダクションシステムとは、AIにおいて、作業記憶に保持された事実の集合に条件と行動のルールを適用する記号推論の構成です。適用可能なルールを照合し、発火させるルールを選び、事実を更新するか、定義された行動を実行します。同じ状況に複数のルールが一致しながら、それぞれ異なる次のステップを提案することがあるため、競合解消が重要です。

ここでいう「プロダクション」は、条件が成立すると結果を生み出すルールを指します。製造の生産ラインや、単に本番環境で稼働しているAIアプリケーションを意味するものではありません。

執筆：Ai Flowi · 公開日 2026-10-11

事実・プロダクションルール・制御サイクル

作業記憶には、処理系が現在利用できる事実を保持します。ルールベースには、条件と行動の定義を保持します。制御機構はルールの条件を作業記憶と照合し、一致したルール間の競合を解消して、選択したルールを発火させます。変更後の照合では、更新された事実を使う必要があります。

例えば、小規模な依頼確認の演習では、case_state = readyが事実です。プロダクションルールとして、案件が準備済みで次の行動が未決定なら確認を依頼する、と定められます。事実は状態を記録し、ルールは許可された遷移を表します。どちらも、モデルが自ら学習してその遷移を発見したことを意味しません。

一致とは、ルールの条件が満たされたことであり、行動が実行済みであることではありません。一致したルールの集合と、発火したルールの記録を区別します。そうしないと、適用可能だったすべての行動を完了済みと誤って説明するおそれがあります。

ルールが競合する架空の事例

これは作成した記号推論のトレースであり、記録されたWorkflowの実行ではありません。依頼は確認の準備ができた状態ですが、依頼者はその依頼を撤回しています。この例の行動はすべて状態レコード内にとどまります。メッセージの送信も外部文書の変更も行いません。

画面が狭い場合は、各事実表やルール表を横にスクロールしてください。キーボードでフォーカスを移し、矢印キーを使うと、残りの列にアクセスできます。

以下の2つのルールは、意図的に条件が重なるようにしています。優先順位は、この架空の処理系で明示した方針です。大きい数値が優先されます。AI Flowi WorkflowのConditionコンポーネントに組み込まれた優先順位フィールドではありません。

初期状態ではR1とR2の両方が一致します。先にR2を発火させると、撤回を処理する前に確認を選ぶことになります。そのため、この例ではR1を優先します。数値はその判断を表すもので、信頼度スコアやルールの品質の測定値ではありません。

照合・競合解消・発火・再照合

選択した行動が、ルールを適用可能にしていた事実を変更するため、トレースは終了します。説明に「依頼をアーカイブする」と書くだけで、next_actionを未決定のままにすると、R1は再び一致できてしまいます。更新は、処理系の状態遷移に含まれていなければなりません。

この判断サイクルの終了は、依頼がアーカイブ済みであることを意味しません。その行動が必要なら、別の権限を持つ手続きで実行を確認する必要があります。ルールの処理系は次のステップを選んだだけで、そのステップを実行したわけではありません。

本番システムで競合解消に明示的な方針が必要なのはなぜですか？

優先順位は、取り得る方法の1つです。別の処理系では、より具体的な一致ルールを優先したり、事実の新しさを考慮したり、固定のルール順序を使ったりします。「より具体的」の意味が自明だと考えず、実際の方針を明示します。条件の多いルールが、必ずしもより適切なわけではありません。

この演習では、2つのルールの優先順位が同じ場合、暗黙に選ばず、確認のために停止します。一致するルールがない場合は「適用可能なルールなし」を返します。これはタスクの完了とは異なります。実際の処理系では、繰り返しの発火や、行動によって変更される事実についても方針が必要です。これらの選択は制御機構に含めます。

明示的なルールは、行動が選ばれた理由を確認者が特定する助けになります。ただし、誤った事実や矛盾したルールベースを修正するものではありません。整ったトレースでも、誤った方針を忠実に実行していることがあります。作業記憶の事実の情報源と、各ルールが意図する結果の両方を確認してください。

1つのConditionノードが示す範囲

比較のインターフェースについては、Conditionのリファレンスを参照してください。ここでのR1の例の状態は文書化済みです。カタログに文書化されていますが、Ai Flowiによる本番環境でのテストは行われていません。

設定例であり、記録されたテストではありません

WorkflowのワークスペースでR1の比較を行う場合、架空の事実レコードをConditionのdata_inputに接続し、key_name = request_state、operator = "equals"、compare_value = withdrawnを設定します。分岐結果の確認には、リファレンスの設定を使います。

これが示すのは、R1のうち1つのキーの比較です。R1の複合条件全体の評価、作業記憶の維持、優先順位の付与、case_stateの更新、照合と発火のサイクルの実行は行いません。公開されたConditionのインターフェースには、ルールのアジェンダや優先順位の入力はありません。こうした動作を実現するには、別途検証した追加のアプリケーションロジックが必要です。

2つの仮想的な事実レコードを比較します。一方はrequest_state = withdrawnとnext_action = undecidedを持ち、もう一方は同じ撤回状態ですが、next_action = archive_requestです。1つのキーの比較では両方の撤回を検出しますが、完全なR1が一致するのは最初のレコードだけです。この違いこそ、分岐結果をプロダクションルールの一致とみなせない理由です。この局所的な比較にモデルプロバイダーの認証情報は不要です。完全なルールのトレースは、別の教材用演習です。

よくある誤りと関連概念

照合、競合解消、状態更新の動作を実装していない限り、視覚的な分岐の集まりを推論エンジンと呼ばないでください。ルールの実行を学習の証拠としないでください。ルールは手動で作成できます。実際の学習プロセスが定義されていないなら、確認後のルール変更は設定の変更です。

検証済みの1つのフィールドで次の分岐が決まる場合は、固定条件で十分です。この限定されたワークフローのタスクには、既存のIf-Elseによる振り分けのチュートリアルを使います。競合するルールや繰り返しの事実更新が不要なら、ルールの処理系に拡張することは避けます。

知的エージェントの例は、行動の選び方を分類します。ReActは行動と観測のループを説明します。エージェントの計画は、複数のステップにまたがる前提条件を説明します。プロダクションルールは、そのような計画を組み立てずに、次の行動を1つ選ぶことができます。