MULTI-AI ORCHESTRATION
しきがかり
複数のAIを束ね、止まった仕事を人の判断へ戻す。
Claude CodeやCodexなど複数のAIエンジンへ仕事を配分し、キュー、進捗、監査、安全停止をまとめて扱う社内検証基盤です。自律実行の範囲を広げても、自動マージは行いません。
- Multi-AI orchestration
- Job queue
- Context recovery
- Audit log
- Safety gates
TECHNICAL SNAPSHOT
- STATUS
- Internal test
- ENGINES
- Multi-AI
- MERGE
- Manual only
PROJECT CONTEXT
解こうとした課題
AIを導入すること自体ではなく、実務で責任を持って使い続けられる状態を設計対象にしました。
01
長い仕事は途中で止まりやすい
セッション切断、コンテキスト肥大、利用上限、外部依存の失敗が重なると、担当AIだけでは再開判断が難しくなります。
02
複数AIの進捗が分散する
エンジンごとの画面や履歴だけでは、依存関係、次の担当、停止理由を横断して把握できません。
03
自律性と変更権限を分ける
処理を連鎖できても、コード統合や公開など不可逆な判断まで自動化しない境界が必要です。
ARCHITECTURE
判断点を含めた処理設計
入力から成果物までを一続きの自動処理にせず、確認・停止・再開できる単位へ分けています。
01 / DIRECT
指令
目的と完了条件を受け取る
02 / QUEUE
キュー
依存関係と実行順を管理する
03 / ROUTE
AI選択
仕事に応じて実行先を分ける
04 / OBSERVE
監査・復旧
進捗、失敗、再開点を記録する
05 / DECIDE
人間判断
マージや公開は人へ戻す
IMPLEMENTATION
実装上の工夫
見栄えだけでなく、状態・権限・記録の境界がコード上でも混ざらないことを重視しました。
マルチAIの横断オーケストレーション
Claude CodeやCodexなど実行特性の異なるAIを、同じ仕事のキューと状態モデルから扱います。
停止を前提にした再開設計
長い処理を一度のセッションへ閉じ込めず、完了条件、途中成果物、次の担当、再開位置を記録します。
利用量と仕事に応じた振り分け
作業内容、コンテキスト量、利用可能なエンジンを見て実行先を選び、不要な再実行を抑えます。
QUALITY & SAFETY
品質と安全境界
できることと、意図的に自動化しないことを同じ強さで定義しています。
品質のための設計
監査ログを正本にする
タスクの状態、担当、停止理由、判断結果を記録し、画面上の完了表示だけで成功とみなしません。
安全停止を複数層に置く
キルスイッチ、月次予算上限、サーキットブレーカー、承認ゲートを役割ごとに分けます。
失敗を完了へ丸めない
再試行不能、依存待ち、承認待ちを区別し、次に人が判断するための情報を残します。
越えない境界
社内検証の基盤
現時点ではYOLX自身のAI駆動開発で検証している仕組みで、顧客向けSaaSとしての提供を示すものではありません。
自動マージをしない
AIが作業を完了しても、変更の採否、統合、公開は人のレビューと承認に戻します。
自律実行を無制限にしない
予算、失敗回数、権限、外部影響の境界を越える場合は停止し、状態を明示します。
掲載範囲：YOLX社内で検証中の開発基盤です。顧客提供実績や業務効果を示すものではなく、運用状況に応じて設計・機能は更新されます。
DELIVERABLES
開発した成果物
顧客効果の推計ではなく、今回の開発で実際に設計・実装した技術成果を示します。
マルチAI実行キュー
複数エンジンへの仕事配分と依存順序を管理
進捗・承認インターフェース
スマートフォンからも状態確認と人間判断を行える導線
監査・安全制御
ログ、キルスイッチ、上限、サーキットブレーカー
再開用コンテキスト
途中成果物、停止理由、次の担当を引き継ぐ記録
RELATED LINKS
