Dynamic Workflow 動的ワークフロー

MyRM Agent の Dynamic Workflow エンジンはシステムの第 3 世代オーケストレーション層です。単一エージェントのコンテキスト制限を突破し、「一言で数百のサブエージェントを调度する」ことで、大規模・分野横断的な複雑なタスク（全リポジトリの Bug スキャン、大規模コード移行、多角的な深掘り研究）を解きます。

​

コア利点

​

1. オーケストレーションの柔軟性：Code-as-Orchestrator

MyRM は Code-as-Orchestrator パターンを提案・実装しました。大モデルはタスクに応じて Python のオーケストレーションスクリプトを動的に生成し、PTC (Programmatic Tool Calling) の安全サンドボックスで実行します。大モデルは for ループ、if 条件分岐、並行スレッドプールを自由に使えるため、静的な DAG (有向非巡回グラフ) ワークフローに比べて柔軟性が遥かに高いです。

​

2. 耐障害性と永続化：4 層の Durable Execution

数時間かかる大規模タスクの実行中にネットワークが切れたり PC が休止したりすると、従来のワークフローはそのままクラッシュします。MyRM Agent は競争相手に比肩できない 4 層の永続化 を備えています。

1. WorkflowEventStore — SQLite に実行キャッシュを永続化し、完了済みのサブエージェント結果を再実行ではなく再利用する
2. SubagentCheckpointStorage — 実行状態の完全スナップショット（メッセージ・ツール出力・変数・進捗）をファイル単位ロック付きで保存し、真のチェックポイント復元（強制停止やクラッシュ後、中断地点から継続）を実現
3. Chat DB progressSteps — 各ツール実行ステップをメッセージのメタデータとして永続化し事后レビューを可能にする
4. event_log/ — 構造化 JSONL の監査ログ、コンプライアンスとデバッグ用

ネットワーク断やサーバー再起動が起きても、ワークフローはチェックポイントから即座に復旧し、完了済みサブタスクを自動的にスキップし、中断したサブエージェントの正確な位置から継続します。

​

3. コスト制御と可視性：隠れた請求をゼロに

数十のサブエージェントがバックグラウンドで並行に Token を消費すると「隠れた請求」が発生します。私たちは 5 層の硬い予算制約（Token / USD / 時間 / 孫数 / 並行数）を用意し、フロントエンドには Subagent Dashboard のリアルタイムトポロジ木 と Live Token 価格計 を用意し、並行サブタスクごとの進捗・所要時間・費用を明確に把握できます。 イベント駆動の 停滞検知 (Staleness Probe) はサブエージェントが進展しなくなったことを自動検出します — Dashboard の赤いアラート、IM 通知、デスクトップ通知の 3 系統で、既存トークン使用イベント検査に相乗りするため追加コストはゼロ（ツール実行中は 4 倍の猶予で遅いツールの誤報を回避）。さらに各サブエージェントは 4 つの並列チャネルでリアルタイム作業証明をストリーム送信します: SUBAGENT_LOG（リアルタイムツール実行ログ）、FILE_DIFF（完全な diff とワンクリックロールバック付き）、SUBAGENT_PROGRESS（token / 費用 / ETA カウンター）、ARTIFACT_CONTENT（生成成果物の即時推送）。どのサブエージェントが何をしているか、何を変えたか、何biosったかを常時点検できます。 Dashboard には高度な可視化 機能も備わっています: Header Summary で総エージェント数・稼働中・失敗・累計費用・モデル分布を一覧、並べ替えとフィルタ（作成順 / 費用 / 所要時間 / 状態で並べ替え、稼働中 / 失敗 / リーフノードでフィルタ）、各分岐ノードのサブツリー集計バッジ（孫の数・累計費用・token 使用量）、折りたたみ可能な Mini Gantt タイムライン（各サブエージェントの実行区間を CSS 色帯で描画）。すべて GUI ネイティブ実装で、バックエンド変更ゼロ・プロンプト token 影響ゼロです。

​

4. 異種モデルの混在：スマートルーティング

同一ワークフローの中で、システムは自動で「資料収集」のような単純サブタスクを安価で高速なモデル（DeepSeek V3 など）へ、「ロジック集計」のような中核タスクを最強の推論モデル（Opus / GPT-4o など）へ振り分けます。出力品質を保ちながら、実行コストを 10 倍から 60 倍まで削減します。

​

5. 閉ループ検証：物理サンドボックスの証拠

サブエージェントが「コード修正完了」と報告した時、、システムは強制的に「読み取り専用の検証者」を起動し、サンドボックスで実際に npm test やコンパイルを実行します。実際の物理実行の成功証拠が初めて得られた時点で、タスクは真に完了したとみなされます。LLM の推測补完（想像で埋める）を拒否し、確実に信頼できる成果物を届けます。

​

6. バックグラウンドタスクの自動起床：「終わったら自動で報告！」

時間のかかるバックグラウンドサブエージェント（例: 全リポジトリのリファクタ）を派遣しても、主エージェントは黙って待つことはしません — バックグラウンドタスクが完了すると主エージェントが自動的に起床して作業を続けます。AsyncWakeupHandler は Harness フレームワーク層と Server 業務層を結ぶプロトコルで、サブエージェント完了後、結果が自動的に会話履歴へ注入され、無人稼働のエージェント実行が自動起動されます（3 回リトライ + 指数バックオフ + 日次予算ガード）。 さらに カンバンスケジューラ（ハートビート監視、ゾンビ検出、定時起床）と 6 件のアイドルメンテナンスタスク（記憶の統合、認知の推導、コンテキスト圧縮など）を組み合わせ、MyRM Agent は真の「発射して忘れる」自律運転を実現しています。サーバーがクラッシュした場合、中断された会話ターンは再起動後に自動再開されます（設定「クラッシュ自動復旧」は既定で有効。ただし深掘り研究など長タスクモードは自動再開しません）。サーバー停止中に実行中の目標は理由を明示して自動一時停止し、ワンクリックで復帰できます。 あなたが離席している間にバックグラウンドタスクが終わった場合、オフラインガーディアン (Offline Guardian) は成功と失敗を厳密に区別します — SSE error chunk 検出と意味的エラーフラグの二重防守により（シリアライズ形式の変化による誤判定を防止）、模糊な汎用通知ではなく「タスク完了」または「タスク失敗」＋ワンクリックの会話リンクが確実Knowingされます。

​

7. 非クリティカルパスの耐障害性保護：優雅に縮退し、一粒の糞が鍋全体を壊さない

複雑な DAG 計画において、すべてのステップが同等に重要とは限りません。MyRM Agent はステップ単位の allow_failure 宣言的耐障害性 をサポートします — 任意のステップを非重要ステップとしてマークし、そのステップが失敗しても（3 回の自動リトライを経ても）failed ではなく skipped に優雅に縮退します。依存する下流ステップはそのまま実行され、全体タスクは成功として完了します。 実例: 多源研究タスクで、ある検索エンジンの API がレート制限で失敗した時、MyRM は研究全体を中止せず、そのデータソースをスキップして残りのソースで続行し、最終的に完全なレポートを届けます。競争相手のフレームワークは、単一ステップの失敗で DAG 全体を中止します。 この機能は MyRM 固有です — Claude Code、CrewAI、Dify、OpenHands、Hermes のどのフレームワークも DAG ノード級 allow_failure 宣言をサポートしていません。結果: 多段ワークフローにおけるタスク成功率が 30% 以上向上します。

​

8. ワンクリックのワークフロー切り替え：Ultra Mode より賢く

OpenAI は GPT-5.6 Sol で「Ultra Mode」をリリースし、複雑なタスクを 4 つの並行 Agent でワンクリック処理できるようにしました。MyRM の WorkflowModeToggle は同等のワンクリック起動を提供しつつ、設計はより優れています。 スイッチはメッセージ送信後に自動的にオフへ戻るため、後続のメッセージが意図せず高コストを起動することがありません — OpenAI Ultra には無い安全機構です。

​

9. 実行計画の確認：民間事業者に出费する前に審査

複数の子エージェントを调度する動的ワークフローを実行する前に、系統は停止して完全な実行計画を提示し、あなたの審査を仰ぎます。いくつの子エージェントが派生されるか、それぞれが何をするか、推定費用はいくらか — その上で実行を確定 / 編集して実行 / スキップ を選べます。 裏側では PhaseWaiter の保留 / 再開ゲートが動きます。サーバーは SSE phase=plan_confirm イベント（完全な計画プレビュー: 子エージェント数、タスク説明、一括費用推定）を送り、あなたの /agents/plan-confirm-response での応答まで実行を保留します。明示的な承認がある限り、子エージェント実行に 1 Token も使われません。 なぜ重要か: 競争相手のワークフローシステム（Claude Code、CrewAI、Dify）は即座に実行し — 計画が誤っていると気づいたときには、数十の子エージェントが既に大量の Token を消費済みです。MyRM の計画確認は「私はこの ¥15 のワークフローを承認した」と「私のエージェントがなぜ今 ¥350 使ったのか」の差です。 WorkflowRunGuard（子エージェント最大 50、並行セマフォ 5）と合わせて、計画確認は二重の安全網になります: 構造的制限が暴走を防ぎ、人による審査が方向の誤りを防ぎます。

​

10. 計画ガードレール：実行への集中、暴走計画の排除

LLM が多段タスクを計画するとき、典型的な暴走は 2 つです: 過剰計画（50 以上の細碎な項目を生成して Token を浪費）と複数焦点の漂移（3〜5 個を同時に「進行中」扱いして結局どれも完了しない）。 MyRM の todo_write ツールはコード層で硬いガードレールを強制します。

• MAX_TODOS = 20: 計画の爆発を防止。上限超過時は明確なエラーメッセージを返し、LLM に計画の統合や簡略化を導きます。
• 単一 in_progress の強制: 任意の時点で「進行中」になれるタスクは 1 つだけ。LLM がこの制約を破った場合、系統は知的に訂正（古い in_progress を pending に戻し最新のものを保持）し、訂正内容を説明するフィードバック note を返します。
• 拒否より訂正: 直接拒否するのと違い、知的な訂正はワークフローの前進を続け、同時に後続ターンで LLM 自身が調整する習慣を付けます。

これはコード層の強制であり、プロンプトでの助言ではありません — どの LLM モデルや提供を使っても挙動は常に一貫します。

​

11. 単一エージェントゲート：単純優先、必要に応じて解放

MyRM は既定で集中した単一エージェント体験を提供します — suggestWorkflowMode は既定オフ。系統は静かに単一エージェントでほとんどのタスクを処理し、迅速で予測可能な応答を、オーケストレーション費用ゼロで返します。明確に opt-in しない限り、ワークフローの提案は一切表示されません。 複数エージェントの能動的な提案を望む上級ユーザーには、設定 → 環境設定 → 詳細 で検出エンジンをワンクリックで有効にできます。

• LLM 費用ゼロ: 検出は純粋な正規表現ルールのスコア（番号付きリスト、並列キーワード、複数目標マーカー）で行い Token を一切消費しません。
• 非ブロッキング: 提案はインラインカードとしてチャットストリームに現れ、現在の応答を遮りません。
• 完全なユーザー制御: 受理（次のメッセージでワークフローモードを有効化）、無視（カードを隠す）、またはトグルの無効化。
• 保守的な設計: ComplexityRouter がタスクを reasoning 階層に分類し、かつ分割可能性スコアが厳格な閾値（≥4/7）に達した場合にのみ発動します。
• 後方互換: 個人設定に suggestWorkflowMode: true を保存済みのユーザーは、アップグレード後も従来の設定が保持され、暗黙の挙動変更はありません。

なぜ単一エージェント優先か。 Sierra の CEO Bret Taylor（元 Salesforce CEO）が述べているように、最良の複数エージェントシステムは、ユーザーに対しては単一エージェントとして見えます。複数エージェントのオーケストレーションは実現手段であって、製品の表面ではありません。MyRM は完全な複数エージェント DAG オーケストレーション能力を持ちながらその露出を既定で抑制する唯一のプラットフォームです — 新規ユーザーに最も簡潔・最速の体験を提供しつつ、専門家には完全な制御を残します。 すべての競争相手 — Claude Code、OpenClaw、Hermes、DeerFlow、CoPaw、Lobe-Chat を含む — はワークフロー提案ポリシーを設定できません。常に表示してノイズになるか、全く提供しないかのどちらかなのです。

​

12. なぜ「ドラッグ&ドロップのワークフローキャンバス」ではなくENTAL強いのか

GUI AI アシスタント領域（OpenClaw、Hermes、LobsterAI、CoPaw、JiuwenClaw）には workflow の可視化エディタがありません — これは MyRM の欠落ではありません。Deer-Flow などのローコードプラットフォームには可視化オーケストレーションがありますが、位置づけが異なり直接の比較対象にはなりません。 MyRM は Code-as-Orchestrator によって Python オーケストレーションの表現力（for / if / 並列スレッドプール）をそのまま残します。静的なノード-エッジの DAG エディタはこの中核的な利点を弱体化させてしまいます。実際にお的必要は:

• ランタイムトポロジ: AgentWorkMap（ReactFlow + dagre）— 古い静的フロー図ではなく、今動いているサブエージェントの木を見せます
• 計画確認の HITL: 実行前に LLM 生成のオーケストレーション計画をレビューし、無闇に Token を焼かない
• テンプレートライブラリの Export/Import: チームでオーケストレーションスクリプトを共有でき、手で図を描く必要がない
• 自然言語でのオーケストレーション変更: 要件を変えるときは一言で。ノードをドラッグするより速い

移行を一言で: 「visual な workflow 編集がしたい」から来た人へ — MyRM はランタイムトポロジ + 計画確認 + 自然言語で、手で DAG を描くことを置き換えます。

​

13. 跨セッション・跨 Fork のセマンティックフィンガープリントによるチェックポイント再生：Identity-Hash Journal Resume

複雑な複数エージェントワークフローでは、ユーザーが WebUI でセッションを Fork したり、前提 Prompt を修正して案を微調整することがよくあります。従来のフレームワークでは Session ID が変わると、高価なサブタスク（全リポジトリ解析、コード検索など）がすべて失効して再実行され、巨大な Token 浪費と長い待ち時間が発生します。 MyRM は identity_hash セマンティックフィンガープリントに基づく永続実行復元機構を導入しました。

• 読み取り専用タスクは秒単位で再利用（0 Token 消費）: readonly=True と宣言されたすべてのサブタスクについて、系統は入力特徴（agent_type、prompt、verification_mode など）から決定論的 SHA-256 フィンガープリントを計算します。入力が同じであれば、跨セッション / 跨 Fork でも WorkflowEventStore から既存結果を瞬時に読み出せるため、所要時間は数ミリ秒、実行速度は 100 倍になります。
• 書き込み操作は厳格に物理分離: 副作用のある書き込みタスク（ファイル変更、API 操作）は跨 Fork の再利用を物理的に禁止し、環境状態の一貫性と安全性を確保します。
• ワークスペース Sidecar ミラーログ: ワークフロー実行イベントは自動的にワークスペースの .myrm/.workflow-journal.jsonl へミラーされ、タスク資産の自己完結性とオフライン監査追跡を実現します。

​

14. 対抗的監査と複数skeptic の無偏见検証ライブラリ：DW Verification Pattern Library

長期間の複数エージェント協業とコードリファクタリングでは、子エージェント（Worker）が作業完了後に「すべての機能が完璧に修正されました」のような主観的ナラティブを出しがちで、従来の検証者（Verifier）は確認バイアスに Easily 導かれます。さらに、レビュー中に書いた一時テストスクリプトがコードベースを汚し、サンドボックスクラッシュ時のハード遮断も欠けがちです。 MyRM は産業級の対抗的審査とパターンを提供します。

• 物理級 Auditor Blind 盲審マスキング: Worker の自己称揚をアルゴリズム級で物理的に剥离し、検証者は実際のワークスペース Git Diff と独立したテスト表明のみで客観的に裁定できます。
• スナップショット差分とファイルの自動無痕復帰 (Mutation Restore): 審査開始前に軽量なワークスペース Stat スナップショットを記録し、審査後に finally ブロックで検証者が生んだ一時ファイルをすべて自動削除し、ユーザーのコードベースを絶対的に純粋に保ちます。
• Multi-Skeptic 並行skeptic の多数決: 独立した 3 人の怀疑者エージェントを並行に派生させ独立推論を行い、2/3 の多数決で放行、単一点の誤判定と幻覚を根絶します。
• サンドボックスクラッシュ時の Fail-Closed 遮断: サンドボックス異常やクラッシュ時は厳格に Fail-Closed で状態を SubAgentStatus.BLOCKED に固定し、未検証コードの逃亡を一切許しません。
• PTC ネイティブ露出: 動的 Python スクリプト内で spawn_subagent(..., verification_mode="auditor_blind" | "multi_skeptic") ですぐ使えます。

​

15. 構造化ハンドオフ状態と全チェーン証拠鎖の単一真実：Structured Handoff Schema SSOT

複雑な長タスクの多角色リレーと並行協業では、子エージェント（Worker）が数万語の会話履歴をそのまま下流へ渡ميلabling、確実にコンテキスト窓を圧迫して Token 爆発を起こし、検証可能なコード根拠も欠落しがちです。 MyRM は不変の構造化ハンドオフプロトコル（AgentHandoverState SSOT）を確立しました。

• 85% 以上の親通知 Token 圧縮: 長文ダンプを捨て、凍結データ契約で中核要約・完了チェックリスト・TODO だけを厳密に抽出し、複数エージェントのリレー通信コストを 85% 以上削減します。
• 原子的な事実と証拠の正規化: すべての Finding は実際の根拠（例えばコード行番号 test_proof.py:42）と正規化検証済みの信頼度バッジ（HIGH / MEDIUM / LOW）を必ず含み、大モデルの偽の推測の埋め込みを除去します。
• 多源並行集約と証拠系譜の完全性: 並行集約時は重複排除済みの全権威引用（all_citations）を自動収集し、すべての事実結論に誕生源（source_task_id と agent_type）を強制注入して、意思決定の連鎖を 100% 追跡可能にします。
• リーフノードの硬い安全フェンスと WebUI ホログラフィック表示: 下層ではリーフエージェントが計画タスク登録などの高危特権ツールを呼ぶことを厳禁し、フロントエンドの子エージェント詳細ドロワーでは高コントラストのバッジで事実発見・コード根拠・権威リンク・成果物を直感的に示します。

​

16. 入力欄インライン統一コンテキストチップストリップと過負荷ガバナンス：Composer Inline Context Chip Strip

複雑なエージェント対話では、ユーザーがワークフローテンプレートを同時に指定し、スラッシュスキルを指定し、単一ターンの MCP/Skill 権限を動的に絞り込み、複数ファイルや過去コンテキストを引用することがよくあります。従来のチャット UI は各種フローティングバッジを分散描画したり長いプロンプトに依存したりするため、入力欄が混雑して制御を失い、Prompt コンテキストが無秩序に膨張します。 MyRM は統一インラインコンテキストチップストリップ（ComposerInlineContextChipStrip）を提案しました。

• 全コンテキストの単一真実による集約: 出発前（Pre-flight）コンテキスト 4 種（ワークフローテンプレート、明示的にスラッシュされたスキル、単一ターン能力範囲（Turn Capability）、@ メンション引用）を優雅に集約。動的/静的な階層でマルチメディア添付は専任のサムネール描画に委ね、論理コンテキストは整然と正規化します。
• レスポンシブなブレークポイントとオーバーフロー折り畳み: デスクトップは最大 4 個の主要チップ、移动は 2 個までに制限し、超過分は +N のオーバーフローポップオーバーメニューにシームレスに折り畳みます。メニュー内では個別にワンクリックで閉じたり個別アクションを実行できます。
• Amber Overload 警告とワンクリック能力剪定: 単一ターンのツールとコンテキスト総負荷をリアルタイムに定量化し、過負荷時に Amber 警告バッジを起動。ユーザーはワンクリックで単一ターン能力剪定パネルへ直接移動でき、冗長な Tool の肥大と Token 浪費を回避できます。
• 直感的なキーボード操作の安全保護: 入力欄が空のとき Backspace キーを押すと末尾のチップをすばやく除去し、入力欄に文字がある場合は厳密に遮断して未送信コンテキストの誤削除を防ぎます。