AI Graphで条件分岐を設計するとき、最初に疑うべきはモデルの性能ではなく、評価結果の受け渡し方だ。ここでいうAI Graphとは、AIが行う複数の作業を、ノード（一つひとつの処理の単位）としてつなぎ、結果に応じて次に進む道を変える仕組みを指す。AIの出力に「危険そう」「十分に調査した」「変更は軽微」と書かれていても、その文章を次の処理が安全に読み取れるとは限らない。人間なら文脈から察してくれる曖昧さも、機械にとっては霧の中の道しるべのようなものだ。同じ言葉でも書き方が少し違えば意味がぶれ、想定外の言い回しが紛れ込むこともある。だからこそ、評価の「文章」とルーティング（分岐処理）の「判定値」を、はっきり分けて設計することが重要になる。
曖昧な評価文を「判定値」に翻訳する
条件付きルーティングとは、作業結果に応じて次に進む道を変える仕組みである。危険度が高ければ人が確認し、信頼度が低ければ再調査し、変更が小さければ簡易確認へ送る、といった具合だ。このとき「なんとなく危険」という自然言語をそのまま条件に使うと、同じ意味に見える出力でも判定がぐらつく。まるで、天気予報を「なんとなく怪しい空」だけで判断して傘を持つかどうか決めるようなものだ。
私たちなら、評価を行うノードの出力を文章だけで終わらせない。たとえばstatus（状態）をapproved（承認）、needs_research（要再調査）、needs_review（要人間確認）、invalid（無効）といった選択肢の値にし、risk_level（危険度）はlow・medium・high、confidence（確信度）は0.0から1.0までの数値で表す。さらに、処理可能かどうかを示すis_executable（実行可能フラグ）を真偽値で持たせ、なぜその判定になったかを示すreason_code（理由コード）も構造化して必須にする。説明文は人が読むために残しつつ、実際の分岐処理は決定論的に検証できる値だけで行う。
ここでの狙いは、文章の解釈という不安定な仕事を、次のルーティングノードに持ち込まないことにある。評価ノードは「観察と値の抽出」に専念し、分岐ルーターは「値に応じた経路決定」だけに専念させる。役割を分離することで、どの判定値がきっかけで分岐が切り替わったのかを明確に追跡できるようになる。
未知値を成功経路に戻さない退避先と境界値の扱い
安全なルーティングは、正常な値だけを想定して設計しても完成しない。確信度の値が欠けている、危険度の表記が誤って重複している、状態が空文字のまま届く。こうした「想定外」は現実に起こる。問題は、その想定外をどこへ流すかだ。
ルーティングの既定経路（デフォルトルート）を自動承認や正常通過にしてしまうと、壊れた出力が出たときに誰にも気づかれないまま成功扱いになってしまう。私たちは、未知の値・形式の誤り・根拠不足が検知された場合、必ず保留キュー（hold）か人間確認（needs_review）へ送る退避経路を基本に置いている。これは単に慎重だからではない。失敗した入力と判定理由を安全な領域へ隔離し、何が起きたのかを後から確実に観測できるようにするためだ。
境界の値も同じように決定論的な基準で扱う必要がある。たとえば確信度がちょうど閾値の0.80だった場合に、自動承認へ送るのか人間確認へ回すのかは、数字の見映えだけで決められるものではない。境界値の判定では、「誤って自動通過させたときに発生する手戻りや損害」と、「人間が確認に割り込まれる運用負荷」のバランスを評価して決めるべきだ。影響の大きい処理ほど、閾値と一致する境界値は安全側（人間確認側）へ倒す設計原則を守りたい。
分岐をループさせないための停止条件と例外ルーティング
再調査や修正依頼の分岐を作成する場合、評価結果が改善しないまま同じルートをぐるぐると回り続けるリスクに留意する必要がある。一度目の不合格であれば、具体的な不合格理由コードを渡してAIノードに再生成を促す分岐は有効だ。しかし、同じ指示で二度以上失敗している場合、文章の微調整だけで解決する可能性は低い。
そのため、分岐の判定条件にはデータの内容だけでなく、実行回数（retry_count）の数値を組み合わせる設計が不可欠となる。再試行回数が指定した上限（たとえば2回）に達した時点で、通常の再調査ルートではなく、例外ルーティングとして人間による介入ルートや管理者向けの保留通知へパスを切り替える。上限に達したあとの退避先を分岐条件の中に明記しておくことで、無限ループによる計算資源の空費や、終わりのない処理遅延を防ぐことができる。
AIの自己評価ではなく、外から確かめられるアンカーで分岐を検証する
AIが「要件をすべて満たしました」と自己評価する文章を出力しても、その一言だけを分岐の合格根拠にしてはならない。分岐ルーターの判定値には、コードの型チェック結果、単体テストの実行可否、仕様書との差分検証、公式資料の参照ハッシュといった、外部から客観的に確かめられる基準（アンカー）を組み込むべきだ。
複数のAIモデルに同一の検証を行わせて同意の多さを測る手法もあるが、単に意見の数を集めるだけでは同一の見落としを回避できない。正確さ、セキュリティ、仕様への適合性など、観点ごとに外部アンカーを用意し、それぞれのアンカーが返す真偽値や判定コードを論理積（AND）や論理和（OR）で組み合わせることで、初めて安全な通過ゲートが完成する。どれか一つのアンカーだけであらゆるリスクを防げるわけではないからこそ、処理の影響度に応じたアンカーの選定と分岐の組み合わせが求められる。
条件分岐を無駄に増やさないための判定基準
分岐や例外経路、検証ゲートを増やせば増やすほどシステムは安全になるように見える。しかし、過度に複雑な分岐網を構築すると、全体の処理フローの把握が困難になり、運用保守のコストが跳ね上がる。新しい条件分岐や退避ルートを追加する際には、私たちは以下の5つの問いを自分たちに投げかけて確認している。
- 判定値は自然言語の解釈を含まない、数値・列挙値・真偽値・理由コードになっているか。
- 未知の値や形式不正が発生した際、既定経路が安全側（保留・人間確認）へ倒れているか。
- 閾値と一致する境界値において、誤承認リスクを考慮した安全側の倒し方が定義されているか。
- 再評価の分岐に実行回数の上限が組み込まれ、上限超過時の退避ルートが明示されているか。
- この分岐を選んだ理由と判定結果が、将来のルーティング設計改善に使えるログとして残るか。
AI Graphのルーティング設計とは、もっともらしい評価の言葉を選ぶ作業ではない。AIが生成した不安定な評価を、検証可能で再現性のある値へと翻訳し、自動化できる道と人間へ委ねる道を安全につなぐ設計である。評価の文章を磨くよりも先に、判定値、既定経路、境界値の扱い、そして停止条件を決めておく。その設計順序を守ることが、予期せぬ自動通過や無限の再試行を排除し、AIを活用する私たちのシステムを真に信頼できるものへ育てていく。
