最小構成で先に残すのは、ノード数ではなく実行を説明する責任
AIを使った複数工程の処理を「Graph」として組み始めると、多くの人はまず処理を細かく分けることに意識を向けます。ここでいうGraphとは、複数のAI処理やコード処理を依存関係に沿ってつなぎ動かす実行の仕組みです。しかし、処理を分けただけでは実行系として未完成です。私たちのナレッジ基盤にある設計記録には、最小のGraph実行システムに必要な要素として、作業内容の登録場所、実行順を決めるスケジューラ、状態と成果物の保存場所、実行記録、条件分岐、再試行、最終統合が挙げられています。つまり「どのノードが何をするか」だけでなく、「一回の実行全体をあとから説明できるか」という視点が最初から必要です。
たとえば、調査・検証・統合の3ノードを持つ小さなGraphを考えます。調査が終わらなければ検証は始まりません。スケジューラは前提作業が完了したノードだけを動かす役割を持ちます。この制御が最小構成の中核です。ノードの入出力や失敗条件を決める契約だけでは、誰がいつ何を実行しどこで止まったかを再現できません。実行を後から説明できる系として設計することが最小構成の出発点になります。
実行IDを軸に、状態・成果物・失敗を分けて追えるようにする
一回の実行を説明する具体的な手段が実行IDです。私たちのナレッジ基盤の記録では、実行記録に残すべき項目として、実行ID、ノードID、状態、時刻、試行回数、入出力の保存先、エラー種類が挙げられています。これらを実行IDに紐づけておけば、あとから「どこで何が起き、なぜ失敗したか」を追跡できます。
外部の公式資料として、AWS Step Functionsのドキュメント(Amazon Web Services「Viewing execution details in the Step Functions console」)は、実行状態、状態遷移、入出力、失敗原因、再試行履歴の保持が障害調査を支援すると説明しています。これは特定製品の実装例であり、あらゆる基盤で同じ挙動を保証する根拠ではありませんが、「状態」「成果物」「実行記録」を分けて保存する設計の方向性は参考になります。
同じ資料は、実行履歴の保存量に上限があることにも触れています。だからといって保存範囲を無制限に広げるのではなく、障害調査と再開に必要な最小限を決め、実行IDで結び直せる形にします。すべての中間データを残す設計は、保存コストや管理負担を増やします。何を残すかは要件によるため、ここでは原則にとどめ、具体的な保存期間や保存先は個別に検討すべき事項として扱います。
再試行は全体をやり直す機能ではなく、局所再開の安全条件で決める
Graphの大きな利点は、失敗したノードだけをやり直せることです。私たちのナレッジ基盤の記録でも、再試行や部分再実行の価値は最小構成や採用判断に含めるべき要素とされています。すべてを最初からやり直すのではなく、成功済みの調査結果を使い回し、検証ノードだけを同じ実行IDと試行回数の下で再開する設計です。
外部の公式資料でも、AWS Step Functionsには失敗地点から再開する仕組みがあり、RetryとCatchでエラー処理を行えると説明されています(Amazon Web Services「Restarting state machine executions with redrive in Step Functions」「Handling errors in Step Functions workflows」)。これは局所再開が可能であることを示す実装例であり、対象エラー、再試行間隔、最大試行回数、バックオフといった条件を明示する重要性を示しています。
ただし、再試行できることと安全であることは別です。成果物の妥当性判定、外部副作用に対する安全性、再試行上限を決めずに自動再試行だけを実装すると、同じ副作用を重ねる危険があります。再試行の対象を「失敗したノード」だけで決めるのではなく、「再実行してよい条件」まで含めて設計する必要があります。
Graph化を拡張するかは、測定で決める
依存解決・実行ID・局所再試行は基盤として最初から持つべきですが、Graph自体をどこまで複雑にするかは別問題です。私たちのナレッジ基盤の記録は、最初から大きなGraphを作らず、少数のノードで始め、処理時間、AI利用料、品質、失敗率、再試行率、遅い箇所、統合費用を測定することを勧めています。複雑な仕組みが必要かは予想ではなく測定結果で決めます。
一方で、Graphが常に正解とは限りません。単一のAIですぐ終わる仕事、逐次的にしか進められない仕事、同時実行できない仕事、管理の手間が本作業より大きい仕事、入出力を明確に決められない曖昧な仕事にはGraphを使わない方がよいという指摘もあります。不要に分割すれば、時間、費用、運用負担が増えてしまいます。私たちの経験でも、AI生成がうまくいかない原因は一気にやらせようとしすぎていることにあります。細分化による品質向上と、細分化しすぎによる効率低下の見極めが重要です。
外部の公式資料も、耐久性、監査可能性、保持期間、コスト、実行保証はワークフロー方式ごとのトレードオフだと説明しています(Amazon Web Services「Choosing workflow type in Step Functions」)。特定製品内の話ですが、要件に応じたトレードオフの判断が要る点は共通しています。
新しいノードを増やす前に、次の点を確認することを勧めます。依存関係を満たしたノードだけを実行できるか。実行IDを発行し全ノードの記録と関連付けられるか。各ノードの状態、時刻、試行回数、保存先、エラー種別を追跡できるか。成功済みの成果物を再利用する条件を定義したか。外部に影響を与えるノードの重複実行防止を用意したか。対象エラー、最大試行回数、待機時間、失敗後の扱いを決めたか。最終統合の責任者と失敗時の状態を明確にしたか。時間、品質、失敗率、再試行率、統合コストを測り、次の判断に使えるようにしたか。
これらは単に処理を分けるのではなく、実行を説明でき、必要な部分だけを安全にやり直す仕組みにするための出発点です。個々のノードの入出力や失敗条件については、[AI Graphのノード契約で決める入出力と失敗条件](/journal/ai-graph-node-contracts)で扱っています。測定による拡張判断の実践は[AI Graphを拡張する前に測る指標](/journal/measure-before-expanding-ai-graph)で、規模が読めない段階の育て方は[規模が読めない段階のGraph設計](/journal/graph-design-for-unknown-scale-exploration)で扱っています。
