[🛠] AI Orchestration #4: Telegramの後続作業を22分から9分に短縮した

✨ GPT-5.6 Solの要約

同じSessionでの自己デッドロック、繰り返される探索、その場限りの検証処理を実務canaryで見つけ、既存の生成・検証処理と部分的な再作業によってTelegramへのファイル返却時間を57.6%短縮した記録。

同じSessionのcanaryで発生した自己デッドロック

前日のドッグフーディングでは、Telegramで目標だけを指示し、PDFとXLSXを受け取った。プロジェクト探索、役割分解、並列実行、再作業、ファイル返却まで一通り動いたが、22分6秒かかった。小さな後続作業まで毎回この速度では、実際に使うにはもどかしい。

別のbenchmarkは作らなかった。同じTelegram Topicに「品質は維持したまま、22分かかった流れを短縮してほしい」と目標だけを再び送った。AI Orchestratorが実際のボトルネックを見つけ、共通Workflowを直し、後続のファイル作業まで完了できるかをそのまま見ることにした。

ところが最初の検証ですぐに自己デッドロックが起きた。AI Orchestratorは現在の依頼を処理している途中で同じSessionにcanaryを送り、その応答を待った。新しい依頼は現在のturnが終わるまで実行できないのに、親側はその依頼の完了を待っているため、どちらも終われなかった。

待機中のCLIだけを終了し、製品変更用Topicとcanary用Topicを分けた。これはモデルが作業できなかった問題ではない。Orchestratorが自分で占有しているSessionの中で次の作業を待ってはいけないという、実行境界の問題だった。

既存の生成・検証処理を再利用する部分再作業

独立したTopicで実行した最初のcanaryは、17分35秒でファイルを返した。以前より速かったが、成果物には承認済みのPilotを再び承認待ちとして表示する内容上の誤りが残っていた。速くなっただけでは合格にできなかった。

実際の実行を追うと、同じ証拠を何度も探し、子作業をpollingし、成果物の生成開始後になってdependencyを確認していた。検証済みのPDF・XLSX生成器とverifierがあるのに、似た検証経路をその場で作り直すコストも大きかった。

共通Workflowには次の基準だけを残した。

• 必要な証拠は一度の限定されたsnapshotで固定する。
• 子作業の結果は繰り返しpollingせず、完了eventで回収する。
• 既存の生成器やverifierがあれば、新しい実装を作らず再利用する。
• 最新の決定と数値の差分だけを反映し、欠陥がある範囲だけを再作業する。
• 最後に成果物全体を一度だけ検証し、Source provenanceを一致させる。

最初の結果で誤っていた承認状態と文言だけを直し、全体レンダリングと独立した再オープン・再保存を改めて検証した。すべてを最初から作り直すのではなく、意味が変わった部分だけを修正し、結果全体の整合性を再確認する流れにした。

Telegramへの9分23秒でのファイル返却と品質境界

再作業canaryは、ユーザーの介入なしで9分23秒後にPDFとXLSXをTelegramへ返した。最初の22分6秒から57.6%短縮し、Orchestrationのtool callも56回から21回に減った。

検査を省いて速くしたわけではない。PDF 2ページとXLSX 4シートのレンダリング、構造、内容、数式、独立したopen/re-saveを再確認し、Telegramから再ダウンロードしたファイルのhashも生成元と一致した。最後には、ファイル内のWorkflow provenanceが古いhashを参照している問題も見つけ、内容と構造には触れず、その値だけを修正した。

最も重要だったのは、最初の17分台の結果を成功として数えなかったことだ。最新の決定が間違っていれば、処理時間を短くしても誤った結果をより速く作るだけになる。今回は品質Gateを維持したまま実際の返却時間が短くなったため、改善を合格とした。

単一ユーザーv0.1と複数ユーザーPilotの境界

現在の単一ユーザーv0.1は、自然言語の目標を受け取り、プロジェクトを探し、作業を分け、成果物を検証してTelegramへ返せる。それでも完全な無人運用と呼ぶには早い。今回もCEO役の私が同じSessionの自己デッドロックを止め、最初の結果の内容上の誤りと、抜けていたローカルcommitを指摘する必要があった。

次に必要なのは新しいbenchmarkではない。同じ品質基準で実際の非機密業務をさらに任せ、処理時間を蓄積して分布と回帰を見る必要がある。別ユーザーの接続が承認された後は、2つのCellを同時に動かしてもSession、Memory、ファイルが混ざらないことも検証する。完全なTask Flow controllerは現在のユーザー経路の主要なボトルネックではないため、別の長期課題として残した。