実際のワークフローをたどり、プラットフォーム全体を一巡します
Braidrunは、人の承認を伴うAIワークフローを構築・実行するために使います。右側のこのグロース日報は毎日本番環境で稼働しています。cronの時刻になると実行され、Apple Search AdsとGoogle Adsの支出とサブスクリプション収益を取得し、AIがコメントを書き、xlsxを生成してSlackに送ります。これに沿って、プラットフォームの各部分が一度ずつ登場します。
キャンバスとYAMLは同じ1つの定義です
この日報はもともとエディター内で構築されました。左がキャンバス、右がYAMLで、どちらか一方を変更すればもう一方が即座に同期します。どう変更すればよいか説明しづらいときは、要望をそのままAIアシスタントに伝えます。
- キャンバス ⇄ YAMLの双方向同期。運用担当はキャンバスを見て、エンジニアはYAMLを確認しますが、同じ1つの定義です
- 組み込みの診断。変数の参照エラーや設定の欠落は、保存前に指摘されます
- diff付きのバージョン履歴。壊してしまっても、前の動作するバージョンにロールバックできます
- AIアシスタントとの対話で構築し、変更は必ずあなたが保存をクリックしてから反映されます
8種類のステップタイプで、より複雑なプロセスを組み立てます
日報で使うのはコードステップと単一Agentのコメントだけです。ステップタイプは全部で8種類あります。複数のAgentに互いの誤りを指摘させたり、状態に沿って進めたり、ワークフロー全体を1つのステップとして再利用したりするときは、typeを変えるだけで足ります。
- 独身1つのAgentが指示に従って1ステップを完了します。日報のAIコメントがこれにあたります
- コードサンドボックスでスクリプトを実行します。データ取得、クレンジング、ファイル生成を行います
- 分類子入力内容に応じて、実行を異なる分岐に振り分けます
- group_chat複数のAgentが同じ問題をめぐって数回議論し、結論を導きます
- agent_basedコーディネーターAgentが、どのツールとサブタスクを呼び出すかを動的に判断します
- state_machine明示的な状態と遷移で多段階のプロセスを記述します
- sub_workflow別のワークフローを1つのステップとして呼び出します
- workflow_output_readほかのワークフローの実行結果を読み取り、続けて処理します
steps: - name: pull_spend type: sub_workflow # 別のデータ取得ワークフローを再利用します workflow: ads-spend-fetcher - name: review_numbers type: group_chat # 複数のAgentがデータを前に互いの誤りを指摘します agents: [analyst, skeptic] rounds: 2 - name: plan_actions type: agent_based # コーディネーターAgentが必要に応じてツールを呼び出します - name: apply_changes type: code manual_approval: true # 人が承認してから実行します
cronの時刻になると実行し、スクリプトはサンドボックスで実行します
この日報は5フィールドのcron式によって実行されます。タイムゾーンは設定可能で、複数インスタンスで配置する際は分散ロックが一度だけの実行を保証します。データ取得と表を生成するスクリプトは、本番環境ではDockerサンドボックス内で動作し、変数はWF_VAR_*環境変数として注入されます。
- スケジュール。5フィールドのcron＋タイムゾーン、分散ロックが複数インスタンスでの重複実行を防ぎます
- Webhook。あなたのシステムが一度POSTすると、JSONのトップレベルのフィールドが自動的に変数にマッピングされます
- 手動とAPI。画面で実行をクリックするか、外部システムからv1 APIを呼び出して実行します
- チェーン。1つのワークフローが完了してからN秒後に、自動的に次のワークフローを実行します
- コードステップはpython、javascript、typescript、bash、ruby、lua、cliの7種類の言語に対応し、デフォルトのタイムアウトは30秒です
# スケジュール。毎朝8時、タイムゾーンは設定可能 schedule: "0 8 * * *" # またはあなたのシステムが一度POSTして実行します curl -X POST \ https://braidrun.com/api/webhooks/{id}/trigger \ -H "X-API-Key: <your-key>" \ -d '{"channel": "#growth-daily"}'
数値が合わない日に、どのステップが原因かを確認できます
ある朝Slackの数値が正しくないように見えたら、その実行を開きます。各ステップの入出力、ログ、コストがすべてそろっています。問題のあるステップを特定したら、そのステップから再実行すればよいです。
- デバッガー。9種類のブレークポイント、一時停止中に変数を変更してから続行します（Proプラン以上）
- 指定したステップから再実行し、完了済みのLLMステップは重複して課金されません
- サービス再起動後は自動的に再開し、定義のハッシュ検証によって変更後の誤った再開を防ぎます
- 実行ごとのtoken使用量とコストを都度記録し、実行の過程はJSON / YAMLでエクスポートできます
本番データを変更するには、まず人の関門を通します
日報はデータを読み取るだけなので、無人運用で十分です。同じチームの別のワークフローは広告入札を変更するため、実行前に承認を加えています。AIは提案を出すだけで、人が承認してから実行され、却下またはタイムアウトの場合は一切変更しません。
- 承認リストの数値は直接変更できます。AIが提案した入札を少し小さくしてから承認します
- 承認はApp内、メール、またはAPIの3つの経路を通り、タイムアウトすると自動的に却下します
- 認証情報はAES-256-GCMで暗号化して保存し、キーのローテーションに対応します
- 割り当てはFree、Pro、Team、Enterpriseで階層化され、並列実行数とスケジュール数にはいずれも上限があります
- 監査ログはプロセスの変更と承認の判断を記録します（Enterpriseプラン）
同じプラットフォームを、あなたのデータセンターに移すこともできます
この日報はBraidrunのクラウド上で動かせば十分です。データを境界の外に出せないチームは、プラットフォーム一式を自分の環境にオンプレミス配置でき、ワークフロー定義はそのまま持ち込めます。
- オンプレミス配置。データとモデルの呼び出しはいずれもあなたの境界内にとどまります
- 複数インスタンスによる水平スケールで、より多くの並列実行を担います
- 14種類のOAuthログイン方式に対応し、WeChat、Alipay、DingTalk、Larkおよび自前のOIDCを含みます
- Prometheusのメトリクスを公開し、既存のモニタリングダッシュボードに接続できます
- 8種類のUI言語に対応し、GDPRのデータエクスポートと削除はすでに製品機能になっています
各部分にそれぞれ専用のページがあります
このページは日報という筋道を一度たどっただけです。各機能の詳細、割り当て、境界は、それぞれのページにあります。