ここでのワークフローとは実際に何か
AI領域の「ワークフロー」ツールの多くは、薄い層をかぶせた指示の連なりです。ToRunの作成器は、型のついた段からなる有向非巡回グラフ（DAG）です。モデル呼び出し、ツール呼び出し、条件分岐、繰り返し、下位ワークフローをグラフにつなぐと、機関が依存の順に、グラフが許すところでは並行して実行します。
各段は自分の設定を持つ一人前の実体です。段の種類（LLM呼び出し、ウェブ検索、コード実行、画像生成、取り出し、変換など）、入力の図式、誤りの方針（すぐ失敗する、待って再試行する、代替へ移る）、段ごとの実行予算上限、時間制限。
各LLM段の内側でのモデル振り分けは、ToRunの他のすべてと同じ能力の経路を通ります。必要なものを宣言すれば——構造化出力、視覚、ツール利用、推論、少なくともNトークンの文脈の窓——実行器はその時点で使える提供元のうち最も合うモデルを解決します。ひいきの提供元が5xxを返せば、代替の連鎖が自動的に引き継ぎます。
品質優先の実行器と、それが実務で変えること
ワークフローを走らせるとき、実行器は最も安い選択肢ではなく品質水準のモデルを意図して選びます。理由は二つ。自動化は誰もすぐには見直さない成果物（報告書、生成された内容、コード）を作るため、品質の欠けは静かに積み上がります。そして中程度の量では、費用の差は、やり直しや手作業の修正を強いる粗い出力の代償より小さいのです。
実務上これは、「調査をまとめて報告書を書く」ワークフローが、価格の底へ走るのではなく、まとめには堅実な推論モデルを、執筆には質の高い文章モデルを選ぶということです。そこは軽いモデルで足りると分かっているなら、段ごとに上書きできます。
請求はToRunの他の部分に倣います。ワークフロー内の各モデル呼び出しは、凍結された価格スナップショットとともにちょうど一件の記録を書きます。五段で三つの異なるモデルを呼ぶ実行は、五件の記録を生みます。各実行の正確な費用を段ごとの内訳で、後からでも検証できます——提供元の価格がすでに動いた何か月後でも。
実行を追う
すべてのワークフロー実行は構造化された足跡を残します。足跡はグラフを示し、各節点に注記がつきます。開始時刻、終了時刻、解決されたモデル、入力と出力のトークン数、行われたツール呼び出し、そして誤りがあればそれも。LLMの段では、送られた指示そのものと受け取った生の応答を開けます。
段が失敗したとき、足跡は誤りがモデル呼び出しから来たのか（提供元の誤り、文脈の溢れ、内容方針による拒否）、下流のツールから来たのか（ネットワークの時間切れ、図式検査の失敗）、あなた自身の条件の論理から来たのかを教えます。記録を足す必要はありません。実行ごとに基盤の水準で捕らえられます。
どの実行も同じ入力で繰り返せるので、障害の再現が素直にできます。
小さな例：週次の競合把握ワークフロー
毎週月曜の朝に走らせるワークフローを思い描いてください。
- ウェブ検索の段——競合の一群の語について最近の記事を探し、住所と抜粋の一覧を返します。
- 取り出しの段——知識ベースから直近四件の報告書を引き、出発点の文脈を定めます。
- まとめの段（LLM）——検索結果を構造化された所見に煮詰めます。新機能、価格の変更、目立つ発表。
- 執筆の段（LLM）——まとめた所見に基づき、一貫した社内の書き方で簡潔な覚書を書きます。
- 配信の段——覚書を設定済みのWebhook終端に送ります。
グラフには自然な依存があります。段3は段1と2に依り（この二つは並行して走れます）、段4は3に、段5は4に依ります。実行器は並行の設定を明示せずともこう進めます。辺を読んでいるからです。