Graphを完成形ではなく、測定する仮説として扱う

AIを組み合わせたワークフローを作ると、処理が増えた時点でノードを足し、並列にし、役割別のエージェントを置きたくなる。けれど、構成図が精密になることと、仕事が良くなることは同じではない。最初は一本の単純な処理に見えても、運用を重ねるうちに例外処理や特定条件の分岐が足され、気づけば誰も全体像を把握できない複雑な構造へ肥大化してしまうことがある。

私たちはGraph（複数のAI処理や確認作業をつなげた実行の流れ）を、最初に正解へ到達するための完成図ではなく、運用で確かめる仮説として扱いたい。だから最初から大きなGraphを作らず、少数のノード(Graphを構成する一つひとつの小さな作業単位)で始める。そこで見るのはノードごとの時間、AI利用料、品質、失敗率、再試行率、遅い場所、そして統合にかかる費用だ。ノードを追加する行為自体が、受け渡しのオーバーヘッドや状態管理の手間という新たな複雑さを伴う。だからこそ、測れない複雑さは増やさない、というのが私たちの設計原則である。

これは「小さい構成が常に優れる」という主張ではない。独立して進められる仕事が多く、部分的な再実行や複数視点の確認が重要なら、Graph化には価値がある。ただし、その価値は直感や予想ではなく、品質と総費用がどう変わったかで確かめるべきだ。

ノードごとに何を残すか。時間だけでは構成を決められない

最初に必要なのは、全体の平均処理時間ではなく、実行をノード単位で追える記録である。各ノードへ実行ID(一回の処理のまとまりを識別する番号)を付け、開始時刻、終了時刻、状態、失敗理由、再試行回数、AI利用量を残す。さらに入出力のトークン数や使用したモデルの識別子、キャッシュの利用有無まで記録しておくと、後の分析が容易になる。ログとメトリクス(数値で表した観測データ)を扱う国際的な仕様も、イベントや時系列の記録を属性と実行の文脈に結びつけて扱うための考え方を示している。

ただし、時間と費用だけでは不十分だ。たとえば、より軽いモデルへ替えて応答が速くなっても、最終確認で差し戻しが増えたなら、全体の仕事は改善していない。ちょうど、近道を選んだつもりが、後で余計な回り道を強いられるようなものだ。ワークフローには、目的に応じた品質の合格条件が必要になる。抽出なら必要項目の充足率、分類なら判断の再現性、レビューなら重大な見落としを許さないこと、といった明確な条件だ。

記録したいのは六つの面である。ノードの所要時間、AI利用料、品質判定、失敗率、再試行率、統合待ちまたは統合にかかる手間である。一つだけ良くなっても、ほかの面が悪化していないかを見る。速度・費用・妥当性・信頼性を文脈に応じて併置するという考え方は、AIのリスク管理に関する国際的な枠組みの観点とも合う。

症状ではなく原因仮説から、分割・統合・モデル変更を比べる

仮に四つのノードからなるレビューGraphで、一つの判定ノードだけ再試行が多いとする。これは説明のための仮想例であり、実案件の実測結果ではない。この症状に対して、原因を調べずにすぐノードを増やすのは早い。

原因は少なくとも四つ考えられる。入力の形式や前提が曖昧で、そのノードが毎回解釈から始めている。判断の難度に対してモデルが軽すぎる。前段で確認すべき条件が抜け、後段へ不完全な入力が流れている。あるいは、一つのノードへ異なる責務を詰め込み過ぎている。たとえば、情報の抽出と妥当性の評価を1つのノードで行っている場合、抽出の失敗なのか評価の失敗なのかが識別できず、無駄な再試行コストが発生する。

それぞれの対策は違う。入力契約(受け渡すデータの形式や前提の取り決め)を明確にする、重要な判断だけ高性能モデルへ替える、直列の確認ゲートを加える、ノード境界を分ける、逆に受け渡しが過剰なら統合する。ノードを2つに分ければ失敗箇所の特定と部分再実行はしやすくなるが、ノード間の文脈伝達やシリアライズの負荷が増す。比較では、一度に全部を変えない。品質の合格条件と比較期間を固定し、一つの原因仮説に対して一つの変更を置く。失敗時も全体を最初から回さず、状態を保存した失敗ノードだけを再実行できれば、原因の観察と復旧の両方がしやすくなる。まるで故障した部品だけを取り替えるように、壊れていない部分まで作り直す必要はない。

構成を変える前の五つの問い

次の変更を入れる前に、私たちは五つを確認する。

  1. 何を改善したいのか。遅延、費用、品質、失敗、統合待ちのどれか。
  2. その症状の原因仮説は何か。入力契約、モデル、確認、依存、ノード境界を混同していないか。
  3. 変更後も守る品質条件は何か。速くなる代わりに失ってよいものを曖昧にしていないか。
  4. どのログを同じ実行IDで比較するか。開始・終了、状態、再試行、利用量、品質判定まで追えるか。
  5. 変更しない案を含め、追加・分割・統合・モデル変更・確認追加を比べたか。

この五つの問いは、チーム内で構成変更の妥当性を議論する際の共通言語としても機能する。単に「処理を速くしたいから並列化する」といった安易な提案に対し、比較期間や対象サンプル数、想定される品質への影響を揃えて議論できるようになるからだ。この問いに答えられないなら、先にGraphを変えるのではなく観測を整える。変更しないという結論も、次に何を測るべきかが分かるなら前進である。

数字にできない品質と、観測そのものの費用を残す

観測を増やせば自動的に正しい判断ができるわけではない。属性を細かくし過ぎれば記録の費用と扱いにくさが増える。ログ収集やメトリクス保管そのものがシステムのボトルネックになっては本末転倒である。また、利用者が感じる説明の分かりやすさや、重大な例外に対する安心感、出力結果の自然さといったものは、単一の数値へ簡単には収まらない。

だから数値は判断を代行する装置ではなく、対話を具体化する材料として使う。定量的メトリクスで異常やボトルネックの兆候を捉え、定性的なサンプル調査で実際の成果物品質を人間が確認する、という補完関係が不可欠だ。どの品質を守るのか、失敗のどこまでを許容するのか、運用者が原因を説明できるかを最後に人が読む。Graphは複雑にするほど賢く見える。しかし、複雑さを引き受ける理由を実行ログで説明できないなら、その構成はまだ早い。小さく始め、測り、比較し、必要になった部分だけを変える。その順序を守ることが、Graphを長く運用可能にする。

なお、本稿で挙げた計測項目や判断手順は、私たちが設計上の立場として持つ原則であり、特定案件での実測による改善効果を示すものではない。品質とコストの重み付けや、統合・分割・モデル変更を決める数値の閾値についても、唯一の正解を提示するものではなく、目的とリスクに応じて読者自身のワークフローで確かめてほしい判断の出発点である。