ワークフロー

ワークフローとは、自然な日本語でチャットして構築する、再利用可 能な Minara の自動化です。Agent はあなたのプロンプトからワーク フロー定義（ステップ、トリガー、通知チャンネル）をドラフトし、 チャットパネルで構築の様子をライブで見ながら、ドラフトがバリ デーションを通過した時点でキャンバスが更新されます。

ワークフローでは次のことができます。

• 価格（BTC、AAPL、EUR/USD、…）を監視し、しきい値を超えたとき にアラートを送る。
• ウォレット、Polymarket トレーダー、またはオンチェーンイベン トを監視し、ルールに合致する活動があったときに通知する。
• ポートフォリオの日次 / 週次 / cron スケジュールのブリーフを 実行する。
• トレードを発注する（標準のプレビュー→確認ゲート付き。サイレ ントな資金移動は発生しません）。

ワークフローの構築

エントリーポイントは 2 つあります。

• ランディングページのフォーム。自然言語の説明を貼り付け て送信すると、Agent がワークフローをドラフトし、成功時に保 存します。
• ワークフロー詳細チャットパネル。既存のワークフローを開 き、変更内容を説明します（「アラートの後にメールの send_message を追加して」「1 時間ごとから 1 日ごとにスケジュ ールを切り替えて」）。Agent が定義を書き直します。

どちらの場合も、チャット画面は作業ログをライブストリーミング します。各ステップの生 JSON がモデルが書いていくにつれて表示 され、ステップの必須フィールドがすべて揃った瞬間に正規のカー ドへ折り畳まれます。キャンバスが変化するのは、Agent のドラフ トがバリデーションを通過したときだけです。

Agent が間違えたときの挙動

ワークフローオーサリングサブ Agent は、リクエストごとに最大 3 回まで試行します。最初のドラフトが壊れた参照（存在しな いステップを指す next）、必須フィールドの欠落（tool のな い tool_call）、またはパースできない条件式を含んでいた場合、 構造バリデーターがそれを検出し、チャットパネルは壊れたドラフ トを Attempt 1 · fixed K issues サマリーへ折り畳み、その 下に新しい Attempt 2 ▪ ●●● building… セクションを開き ます。

折り畳まれた試行は削除されません。展開すると、Agent が試した 内容とそれを失敗させた構造化エラーのリストが見えます。アクテ ィブビューを散らかすことなく、ミスを監査できます。

リトライ中に決して起こらない 3 つのこと。

1. キャンバスが壊れたドラフトから更新されることはない。 キ ャンバスの真実は workflow.commit イベントで、バリデーシ ョンを通過した試行でのみ発火します。中間の workflow.patch イベントはプレビューであり、キャンバスは 無視します。
2. 破棄された試行がカードとしてチャットパネルへ届くことはな い。 サブ Agent は各試行のイベントをサーバー側でバッファ し、バリデーションに失敗するとバッファを破棄します。バリ デーションを通過した試行のカードだけがチャット履歴に残り ます。
3. 保存されたワークフロー定義が壊れた形になることはない。 3 回の試行すべてが失敗した場合、ゲートウェイはロールバッ クイベントを発行し、永続化をスキップします。既存の定義は そのまま残ります。

キャンバス上部のツールバーは現在のフェーズを反映します。試行 1 では Drafting…、リトライが始まると Retrying, attempt N of 3…、検証済みドラフトの保存中は Saving…。チャットが 完了するまで Run / Schedule / Publish は無効のままです。

既存ワークフローの編集

Refine フローは、既存のパラメータを保持します。Agent はメッセ ージで変更を要求されたフィールドだけを触ります。トークンアド レス、webhook ID、カスタム引数の値、変更されていないステップ の条件式は、そのまま透過的に通過します。通知チャンネルの切り 替えを依頼しても、tool_call ステップのアドレスが副作用とし て書き換えられることはありません。

リクエストが、実行可能なワークフローを構築するために Agent が 必要とするパラメータを欠いている場合（指定されていないチェー ン、接続されていない provider など）、Agent は推測する代わり に、何が不足しているかを尋ねる短いアシスタントメッセージを返 します。サイレントなゼロアドレスのプレースホルダーも、「言わ なかったから ETH をデフォルトに」というような不意打ちも発生 しません。

ストリーミング中のリフレッシュ

refine のストリーミング中にチャットパネルをリフレッシュする と、進行中のセッションへ再接続し、すでに到着したイベントを再 生します。折り畳まれた試行セクションは、ライブで見たのと同じ 形で再ロードされます。作業ログのスケルトンは、たとえ基盤の refine が試行の途中であっても、チャット履歴のロードが完了し た瞬間にクリアされます。

逐次実行モデル

すべてのワークフローは逐次実行されます。配列形式の next も、ネイティブな fan-out も、並列分岐もありません。 Agent に「アラートの後に Telegram とメールを送って」と依頼す ると、notify_tg → notify_email のようにチェーンします。チェ ーン化された 2 つの send_message ステップ間のレイテンシは実 測でサブ秒であり、ユーザー視点では並列と区別がつきません。

これは意図的なものです。fan-out セマンティクスは監視ワークフ ローに二重発火バグを持ち込みます（価格モニター webhook がデ ィップ中に 2 回発火すると、並列分岐があるワークフローでは 2 回 buy を呼び出すことになります）。逐次モデル＋資金移動ス テップでのポジションチェックガードが、障害モードをシンプル に保ちます。