内蔵モジュールライブラリ

Braidrun には 120 以上の内蔵モジュールが付属しています。各モジュールはカプセル化されたワークフローであり、型付けされた入力 / 出力契約を備えています。他のワークフローは sub_workflow ステップでそれを参照でき、内部実装を気にする必要はありません。

汎用ツール（約 80 個）

utility-module-* というプレフィックスで、データ処理、HTTP リクエスト、検索・スクレイピング、テキスト AI、監視チェックといった業務に依存しない汎用的な処理をカバーします。代表的なモジュール:

配信と通知

ワークフロー末端の安定した通知出口です。多くは純粋なコードステップで実装され、LLM に依存しないため、モデルの認証情報の欠落によって通知経路が失敗することを回避します。代表的なモジュール:

その他の通知モジュールは、Discord、Feishu、WeChat Work、Microsoft Teams、Mattermost、Rocket.Chat のグループボット、Mailgun / SendGrid のメール、および Bark、Pushover、Server 醤のプッシュ通知をカバーします。また、Telegram ファイル配信モジュールもあり、.md / .xlsx / .pdf / .csv のレポートを説明文とともに指定した会話に直接送信し、dedupe_key による再送時の重複送信防止に対応します。

金融分析（約 10 個）

module-* というプレフィックスの定量分析ツールチェーンです: 相場 → テクニカル指標 → ポートフォリオ分析 → バックテスト。相場モジュールは API key 不要で（テンセント財経 / Yahoo Finance / CoinGecko のデータソース）、指標とバックテストのモジュールは純粋な標準ライブラリで実装されています。

同じシリーズには、株式ニュース、条件による銘柄スクリーニング、オプション価格算定、リスク指標、市場概況などのモジュールもあり、相場からレポートまでの完全なパイプラインとしてつなげられます。

広告とグロース（約 40 個）

これらのモジュールはあるサブスクリプション制アプリチームの実際の広告運用に由来し、Apple Search Ads、Google Ads、および App の収益データをカバーします。用途別に主ないくつかのカテゴリを挙げます。

• ASA レポート取得：campaigns / keywords / adgroups / searchterms の 4 つの次元に対応し、インターフェースのフィールド命名の差異を自動的にならします。
• ASA エンティティ一覧：広告キャンペーン、広告グループ、キーワード、除外キーワードの一括取得。
• Google Ads ツール：GAQL クエリを実行して構造化して返します。広告キャンペーンのパフォーマンスレポートとアクセス可能なアカウントの検出も備えています。
• App 収益取得：時間ウィンドウごとに収益とサブスクリプションのデータを取得します。
• 時間ウィンドウの解析：遡る日数とタイムゾーンを標準化された開始 / 終了日に変換し、一連のレポート内で「昨日 / 先週」の意味が完全に一致することを保証します。
• レポートの組み立て：複数 Sheet の Excel 構築と Markdown レポートテンプレートのレンダリング。
• 複数 App のバッチ処理：同一のサブフローを一連の App に対してそれぞれ 1 回ずつ実行し、結果をマージします。
• 品質レビューループ：生成 → 採点 → 基準未達なら再試行 → 基準達成で終了、という標準化された品質ゲート。

モジュール契約

各モジュールは 1 つの契約を宣言します。入力は型付けされており（string / number / boolean / enum / path / json）、required、デフォルト値、列挙値、数値範囲を注記できます。出力は名前、型、ソース変数を宣言します。契約は、ワークフローの実装バージョンとは独立した contract_version を持ちます。

module:
  enabled: true
  display_name: Web Search
  contract_version: 1.0.0
  inputs:
    - {name: query, type: string, required: true}
    - {name: provider, type: enum, default: duckduckgo,
       allowed_values: [duckduckgo, serper]}
    - {name: max_results, type: number, default: "10", min: 1, max: 100}
  outputs:
    - {name: results_json, type: string, source: "{{var:results_json}}"}
    - {name: result_count, type: number, source: "{{var:result_count}}"}

契約を変更する際、プラットフォームは新しい契約と古い契約を比較します。非破壊的変更（例えばオプション入力の追加）はそのまま通過します。破壊的変更（既存の参照側に影響する）はデフォルトで保存が拒否され、明示的な確認が必要となり、推奨される新しい契約バージョン番号が提示されます。契約は deprecated マークと移行の説明もサポートしており、参照側に代替モジュールへの切り替えを促します。

ワークフロー内での参照

sub_workflow ステップでモジュール id により参照します。inputs の値はすべて文字列で（数字も "10" のように記述）、変数テンプレートに対応します。outputs はモジュールの出力を親ワークフローの変数にマッピングして戻し、後続のステップがそのまま使用します。

workflow:
  - step: fetch_metrics
    sub_workflow:
      name: utility-module-http-request
      version_strategy: latest
      inputs:
        url: "https://api.example.com/v1/metrics"
        method: GET
      outputs:
        status_code: fetch_status
        response_body: metrics_json

  - step: notify
    sub_workflow:
      name: utility-module-slack-webhook
      inputs:
        webhook_url: "{{var:slack_webhook_url}}"
        text: "Metrics updated: {{var:metrics_json}}"
      outputs:
        send_status: notify_status
    depends_on:
      - fetch_metrics
    retry:
      max_attempts: 2
      backoff: exponential

• version_strategy デフォルトは latest です。特定のバージョンに固定することもでき、その場合モジュールの更新が本番稼働中の親ワークフローに影響することはありません。
• モジュールを指す参照は契約モードで動作し、inputs / outputs は契約に従って検証されます。モジュールが通常のワークフローに降格された場合、参照は緩いモードに退化し、自動検証は行われなくなります。
• retry、condition、depends_on などのステップ修飾子は、sub_workflow ステップにも通常どおり使用できます。

カスタムモジュール

どのワークフローもモジュールに昇格できます。エディターのワークフロー設定パネルで「モジュール契約」セクションを見つけ、表示名、説明、入力 / 出力、契約バージョンを入力し、「モジュール契約を保存」をクリックします。その後、モジュールライブラリに表示され、他のワークフローから sub_workflow で参照できるようになります。

モジュールの身分を取り消す（降格する）際、プラットフォームはまず逆依存関係チェックを行います。まだこのモジュールを参照している親ワークフローがある場合、具体的な参照箇所を一覧表示して操作を阻止し、他人のフローを気付かないうちに壊すことを防ぎます。

モジュールもテンプレートと同様にマーケットプレイスに公開でき、バージョン番号を持ち、インストール時に依存関係を自動的に解決します。