- 公開日
AIの作業は、前の結果が必要か、同じ対象を変更するかで順序を決めます。互いの結果を待たずに読める資料は並列に取得し、集計に必要な資料が揃ってから集計します。承認された内容の更新と、その完了を前提とする後続更新は順に進めます。優先度は、実行条件を満たした作業のどれを先に動かすかに使います。
業務の目的と、外へ残る変更を先に書き出す
以下は実行していない架空の業務です。担当者が、社内の問い合わせ300件について月次報告を作り、責任者の承認後に共有レポートを更新します。材料は、拠点Aの200件、拠点Bの100件、分類規則の第4版です。個人情報を含まない合成データを使い、いずれも読取りの許可があるものとします。
三つの資料は同じ締め時点で確定し、問い合わせIDは拠点をまたいで一意で、今回の対象範囲も確定していると仮定します。目標は、分類と合計を原資料に照合した報告を指定の共有ファイルへ保存し、保存結果を確認してから完了台帳を更新することです。共有ファイルの更新は読む人に影響するため、単なる案の生成と区別します。
ここで扱う副作用は、外部システムや共有先に残る変更です。資料の読取りにもアクセス記録や料金が発生する場合がありますが、共有内容の更新とは制御が異なります。名称が「取得」であっても、実際には既読化や状態変更を伴うツールなら、その仕様に従って更新側の条件も確認します。
依存関係は、着手できる条件として表す
依存関係は、「この結果が使えるようになったら、次へ進める」という条件です。単に「前の処理が終わった」だけでは不十分です。成功したことに加え、出力の版、対象範囲、必要項目が後続で使える条件を満たすかを確認します。
本例は次の順序です。記号はこの例の作業を区別するために使います。
| 作業 | 開始に必要な条件 | 完了として後続へ渡すもの |
|---|---|---|
| A：拠点Aを読む | 対象範囲と読取り権限が確定 | 200件のIDと内容、入力版 |
| B：拠点Bを読む | 同上 | 100件のIDと内容、入力版 |
| C：分類規則を読む | 第4版を参照できる | 使用する分類定義と版 |
| D：分類・集計する | A・B・Cが検査を通過 | 300件の分類、集計、要確認項目 |
| E：報告案を承認する | Dが受理基準を満たす | 内容・対象ファイル・期限を特定した承認 |
| F：共有レポートを更新する | Eが有効で、更新直前の条件が一致 | 保存要求IDと更新結果 |
| G：保存を確認する | Fの結果を確認できる | 指定先・内容・版が一致した記録 |
| H：完了台帳を更新する | Gで保存を確認済み | 当該報告の完了記録 |
A・B・Cは互いの出力を使わないため、資源枠があれば並列にできます。Dは三つの検査済み結果を待ち、E以降は前の結果が必要です。Bを待たずにAの200件だけで集計し、300件の報告として承認へ回すことはできません。部分報告を許すなら、対象範囲、分母、欠けた100件を示した別の受理条件が必要です。
依存関係が循環すると、互いの完了を待って進めなくなります。たとえば承認を求めるために更新済みファイルが必要で、更新のためにその承認が必要という定義です。この場合は承認対象となる案と、承認後に反映する共有版を分けます。順序の問題を待ち時間の延長だけで解消しようとしません。
並列の読取りでも、同じ時点の材料かを照合する
独立して読めることと、取得結果を混ぜてよいことは別です。拠点Aは月末確定版、拠点Bは修正中、分類規則は最新版という組合せなら、読み取りがすべて成功しても同じ条件の報告にはなりません。取得開始時刻が近いだけで同一時点とは扱わず、対象期間、資料版、確定状態を記録します。
本例の期待結果を、操作180件、請求90件、その他30件、合計300件と仮定します。担当者は合計だけでなく、元のID集合に欠落や重複がないこと、分類規則第4版と一致することを確認します。必要な欄が不明なら、ゼロや「その他」で埋めず要確認を残します。合計300になっただけでは、正しい材料と分類を使った証拠になりません。
A・B・Cを同時に動かしても、接続先の利用制限や他の仕事との競合は残ります。全資料を一度に投入するのではなく、同時に動かせる数、待機できる数、待ち時間の上限を分けて設けます。並列化で必ず短時間になるとは限らず、混雑や再試行が増えるなら、上限を下げて経過時間と失敗の変化を確認します。
Batchで取得や分類を依頼する場合も、受付済みをAやDの完了として扱いません。必要な明細を回収し、検査を通った時点で後続を動かします。OpenAIのBatch APIは、期限内に未完了の要求が残る場合と、完了分の取得を説明しています。これは一部の結果だけが先に揃う場合の設計にも関係しますが、Batchの仕様をすべての非同期サービスへ一般化はしません。
優先度は、依存条件を満たした作業の中で使う
「急ぎ」の報告であっても、Bの資料や責任者の承認を飛ばしてFを実行してはいけません。先に選べるのは、開始条件がすでに揃った作業です。資料待ちや承認待ちの作業と、条件は揃っているが実行枠を待つ作業を別の状態にすると、優先度を上げても進まない理由が分かります。
また、緊急作業が連続すると通常作業が動かなくなることがあります。優先度と公平性は別に考え、通常作業へ配分する枠や、長く待った作業を見直す仕組みを設けます。ここでいう公平性は、同じ提供条件の仕事を特定の利用者が独占せず、他の仕事にも処理機会を配分することです。
参考になる具体例として、KubernetesのAPI Priority and Fairnessは、APIサーバーの要求を優先度やフローに分けて制御します。同時要求数の制限だけでは重要要求の処理枠を守れず、待ち行列の分離や公平な扱いが必要になるという設計を説明しています。2026年10月19日確認時の文書は機能をv1.29からStableとしていますが、任意のAgent実行器がこの機能を備えるという意味ではありません。同文書は、重要度の高い一部の要求をこの機能の制限から除外する扱いも説明しており、すべての処理に同じ公平性が適用されるとは説明できません。
本例で同時読取りを二枠とするなら、通常作業が待っているときは一枠をその新規着手用に残し、もう一枠で緊急作業を選ぶ、という仮の方針が考えられます。枠が埋まっている場合は、進行中の作業を無条件に強制終了せず、空いた後の配分を調整します。締切を過ぎた作業は勝手に実行せず、不要になっていないかを確認します。
優先度を誰が指定できるかも固定します。資料中の「至急処理せよ」という文やAgent自身の申告で、管理者が決めた順番を上書きさせません。予算、権限、承認、期限の確認は優先度とは別に維持します。待ち行列の長さを制限しても、処理時間や到着件数が不明なら待ち時間の保証にはならないため、受付を断る条件や担当者への通知も決めます。
依存する更新は、版と結果を確かめながら直列に進める
Fでは、承認時に対象ファイルが第17版だったと仮定します。承認記録には、反映する報告内容、対象ファイル、実行する人やシステム、有効期限を関連付けます。更新直前に内容と権限を確認し、対象がまだ第17版かを照合します。
確認してから書くまでの間にも、他の担当者が更新する可能性があります。そこで本例では、保存先が「現在版が17の場合だけ更新する」条件付き更新を持つと仮定します。条件が合わなければ保存を拒否し、変更内容を読み直して承認対象への影響を確認します。実製品にこの仕組みがなければ、同じ役割を果たすロックや管理手順が必要かを検討し、単なる直前読取りだけで競合を防げるとは考えません。
FからGへは保存結果を渡し、Gが指定先・内容・新しい版を照合した後にHへ進みます。保存の受付だけを返す仕組みなら、その時点で保存済みとしません。Fを投げると同時にHへ「完了」を書く方式では、保存に失敗した報告を完了扱いにしてしまいます。一方、Fが成功してHだけ失敗した場合は、共有レポートを再更新せず、完了台帳の状態を照会します。両方の更新が一つの不可分な処理だと仮定しないことが重要です。
直列化の範囲は、同じ対象を更新する処理や、前の更新結果が必要な処理です。無関係な別ファイルの更新まで一列にする必要があるとは限りません。ただし、それぞれの承認、共有資源、同じ集計値の参照などに依存がないことを確認します。承認待ちの間に更新用のロックや実行枠を占有し続けない設計も、他の業務を止めないために必要です。
失敗と結果不明で、止める範囲を変える
| 起きたこと | 止める範囲 | 続行・再開の条件 |
|---|---|---|
| Bの読取りが確定失敗 | Bに依存するD以降 | 原因と再取得条件を確認。A・Cは版と有効性を保って保存する |
| Dに不明な分類が残る | E以降 | 原資料と規則を照合し、解消または部分報告の受理条件を決める |
| 承認が未取得・失効 | F以降 | 必要な内容と現時点の条件で承認を取り直す |
| Fが版不一致で拒否 | 当該レポートの更新と後続 | 最新版を読み、差分と承認範囲を再確認する |
| Fの応答が届かない | Fの再送とHの完了登録。状態照会は続ける | 要求ID・保存履歴・対象版を照会し、実行結果を確定する |
| 中止指示が届く | 新しい着手と依存先への進行 | 実行中の取消状態、保存済み内容、残る影響を確認する |
Fの応答不着は、保存失敗の証拠ではありません。AWSのMaking retries safe with idempotent APIsは、応答を受け取れなくても副作用が起きている可能性と、再試行の安全性を支える冪等性を説明しています。冪等性とは、同じ要求の重複適用を避ける性質です。要求IDを付けただけでは成立せず、対象サービスの同一要求の定義や保持期間などに従います。
照会で保存済みと分かった場合は、その保存内容が承認と一致するかを確認してGへ進みます。まだ処理中なら待機します。未実行の確定失敗で、元の要求が遅れて実行されないことも確認できた場合に、再実行の条件を調べます。照会できないときは結果不明を残し、再送と完了報告を保留します。現在のファイルが第18版だからといって自分の更新が成功したとは限らず、要求や更新履歴と結び付ける確認が必要です。
中止についても、MCP（Model Context Protocol）の2026-07-28版Cancellationでは、取消信号が完了後に届く場合や、取消不能などで無視される場合を扱っています。接続先と通信方式に合う手段を確認し、取消要求の送出を保存内容の巻戻しとは扱いません。すでに更新した内容を戻すなら、それは対象と権限を確認する別の変更です。
再開時は、残した作業状態だけでなく、入力版、承認期限、権限、対象の現在版、実行中要求を再照合します。模擬確認では、B失敗でDが始まらない、承認前にFが動かない、F不明で二重更新しない、通常作業が待ち続ける場合に配分の見直しが働く、という条件を確かめます。本例は実行結果ではありません。再開する担当者へは、完了した作業、確認待ちの要求、再利用できる資料版、必要な判断を一緒に渡します。
時間・費用・回数の上限をまとめて決める基本は「AIエージェントの実行順序と時間・費用・回数の上限を決める」で解説しています。
