ワークフローの構築

日常的なリクエストを自動化に変換。プレビュー、テスト、デリバリーチャネルに対応。

自動化をどこから始めればよいか迷っていますか？まずここから始めましょう。以下の例は、実際のユーザーが使う自然な言い回しで書かれており、それぞれが現在利用可能なワークフロー機能に対応しています。

まだ資金を入金していない場合は、先に初回セットアップをご覧ください。

💡 ローカルワークフローはデプロイ前に workflow_test を実行できます。メッセージ型ワークフローの場合、テストは設定済みのプラットフォームにメッセージを実際に送信するため、チャネルが正しく機能しているか確認できます。対象プラットフォームがまだ接続されていない場合、テストは事前に拒否され、接続が必要なプロバイダーを通知します。

自動化の考え方

ワークフローは組み込みワークフローエンジンで動作します。スケジュール済みのブリーフィング、アラート、通知、モニタリングに使います。ツールハンドラーを直接呼び出すため、ワークフローに LLM ノードが含まれない限り token を消費しません。

自律型トレーディング戦略は Autopilot をご覧ください。独立したセクションです。

🟢 エージェントワークフロー

最も安全な自動化のエントリーポイントです。監視、要約、通知を行います。資金は移動しません。

1. Telegram 価格アラート

プロンプト

Alert me on Telegram if ETH trades below $3000.

Agent の応答:

価格閾値ワークフローを作成します。

アセット: ETH

トリガー: 直近価格が $3,000 を下回る

デリバリー: Telegram

クールダウン: 通知間隔 15 分

作成しますか？ yes または no でお答えください。

チャネルをまだ設定していない場合、Minara は処理を止め、メッセージングページへ案内します。

2. 朝の市場ブリーフィング

プロンプト

Send me a BTC, ETH, and SOL market brief every day at 8am Shanghai time.

Agent の応答:

スケジュール済みのローカルワークフローを作成します。

スケジュール: 毎日 08:00 Asia/Shanghai

アセット: BTC、ETH、SOL

出力: 前夜からの変動、主要レベル、トレンド、リスクフラグ

デリバリー: チャット＋設定済みメッセージングチャネル

作成しますか？ yes または no でお答えください。

3. カスタムモニタリングワークフロー

プロンプト

Create a workflow that emails me if BTC moves 5% in a day or if NVDA gaps more than 4% at the open.

Agent の応答:

ローカルのモニタリングワークフローを構築します。

トリガー A: BTC の 24 時間変動率 >= 5%

トリガー B: NVDA の寄り付きギャップ >= 4%

チャネル: メール

実行モード: 監視のみ。取引は実行しません

作成しますか？ yes または no でお答えください。

4. 高頻度ウォッチリストスキャン

プロンプト

Watch the top 20 tokens by 24h volume and alert me every 15 minutes if any move more than 5%.

Agent の応答:

ローカルのモニタリングワークフローを準備します。

スケジュール: 15 分ごと

対象: 24 時間出来高上位 20 トークン

トリガー: 変動率が 5% を超えた場合

デリバリー: チャット＋設定済み通知チャネル

許可するツール: 読み取り、メモリ、メッセージング

作成しますか？ yes または no でお答えください。

デプロイ前のローカルワークフローテスト

ローカルワークフローは、本番リリース前にテスト実行できます。

workflow_test は手動テスト実行を作成し、サンプル入力または自動生成されたトリガーペイロードで DAG をエンドツーエンドに実行します。
メッセージングのステップは実際に送信されます。 Telegram / Slack / メールにアラートが届くことを実際に確認できます。ペイロードの形式だけでなく、チャネルの動作も検証できます。
資金移動などの破壊的なツールはシミュレーションのままです。 プレビュー構造には実行予定の内容が記録されますが、実際の処理は行われません。
ワークフローの対象プラットフォームがまだ接続されていない場合、テストは事前に拒否され、どのプロバイダーが不足しているかを通知します。REPL では /connect <platform>、Web UI では Settings → Messaging から接続し、その後再実行してください。
本番スケジュールと definition.active はそのままです。 テストは何度でも安全に再実行できます。

これにより、ワークフローが本番稼働する前に、受信者が実際に目にする内容をエンドツーエンドで確認できます。

1回限りのアラート

「X が発生したら通知して」というアラートは、一度だけ発火して自動的に停止するのが理想的です。GOOGL が $340 を超えた後も 15 分ごとに Telegram メッセージが届き続けるのは困ります。send_message と deactivate ステップを組み合わせてください。

{
  "entry": "fetch_quote",
  "trigger": { "type": "interval", "interval_ms": 900000 },
  "steps": {
    "fetch_quote": {
      "kind": "tool_call",
      "tool": "yahoo_finance_stock",
      "args": { "kind": "quote", "symbol": "GOOGL" },
      "next": "check"
    },
    "check": {
      "kind": "condition",
      "condition": "fetch_quote.price <= 340",
      "next": { "on_success": "alert", "on_failure": null }
    },
    "alert": {
      "kind": "send_message",
      "provider": "telegram",
      "text": "GOOGL hit $340",
      "next": "stop"
    },
    "stop": { "kind": "deactivate" }
  }
}

価格条件が初めて満たされると、send_message がアラートを送信し、deactivate がワークフロー自身の active = false に切り替えます。トリガーマネージャーが非アクティブフラグを尊重するため、次のインターバルはスキップされ、アラートはちょうど一度だけ発火します。

再アームするには、Web UI の Schedule on ボタン、REPL の /workflows activate <id> コマンド、またはチャットで Agent に依頼（「GOOGL アラートを再アームして」）してください。

資金を移動するスケジュールを有効にする場合

ワークフローにトークンのスワップ、売買、資金移動などのステップが含まれている場合にスケジュールを有効にすると、実行のたびに「本当によろしいですか？」という確認は行われません。それがスケジュールの本来の目的です。自動で実行されます。

注意: 資金移動を伴うワークフローで Schedule on をクリックすることは、それ以降のすべての実行に対する一度限りの承認です。 スケジュールを有効にする前に、Web UI はどのステップが資金を移動するか、ワークフローの実行頻度、そして「理解しました」のチェックを確認するよう求めます。キャンセルすると都度実行の Run now に戻り、各実行で取引の確認が求められます。

セーフティチェックの仕組みについて詳しくは、資金移動の確認をご覧ください。

ワークフローと他の機能の使い分け

アラート、定期的なサマリー、モニタリングにはワークフローを使用してください。
上限、緊急停止、継続的な戦略レビューを備えた自動定量トレーディング戦略には Autopilot を使用してください。
プレビューと確認を伴うインタラクティブな一回限りの取引には、初めての取引を使用してください。

次のステップ

ローカルワークフローの動作を詳しく知りたい場合 → 機能 → ワークフロー
通知を設定したい場合 → メッセージング
自律型の戦略実行を使いたい場合 → Autopilot

ワークフローの構築

目次