ドキュメントワークフローの構築認証情報

認証情報

API キーを Credential Center に安全に保存し、ワークフローで参照します。

Credential Center は、すべての外部システムキー (OpenAI API キー、Slack Webhook、Stripe Secret、内部 API 認証ヘッダー) の統合ストレージであり、これらはすべてここに配置されます。プラットフォームは AES-256-GCM を使用してデータベースを暗号化し、最初から最後まで YAML エクスポート、ログ、監査イベントには表示されません。

資格情報センターに行く必要があるのはなぜですか?

YAML でキーを直接書きたい場合、次の 3 種類の問題が発生します。

漏れ — YAML、Git 送信、AI アシスタントの差分プレビューのエクスポートはすべて、平文キーを取り出します。
回転できません — キーが取り消された場合は、各 YAML を手動で変更する必要がありますが、これは非常に見落とされがちです。
監査できない — 問題が発生した場合、どの実行でどの Key が使用されたかわかりません。

Credential Center は YAML に「参照」のみを残し、実際の値は実行時に対応するステップに挿入されます。

AI アシスタントはこれらの認証情報を使用します

AI アシスタントの完全な設定は「アカウント設定 → AI アシスタント」にあります。モデル、プロンプト、ツール、Skills、MCP、Claude Code / Codex のパラメーターはそこで管理し、このページでは個人とチームの認証情報を保存します。

資格情報を作成する

左側の「認証情報管理」→右上隅の「新しい認証情報」。
記入してください:
- 名前 — すべて小文字 + アンダースコアの短い識別子。YAML での引用に使用されます。例: openai_main、slack_webhook_url。
- タイプ — api_key / oauth_token / bot_token / webhook_secret / generic。类型决定平台在 UI 上怎么展示它，对解析逻辑影响不大。
- 値 — 一度書き込んだものを読み戻すことはできません。
- 名前空間 — 個人/チーム (Pro+ パッケージのチームに所属している場合)。
- 説明 (オプション) — 自分自身またはチームメンバー向けに作成されます (例: 「OpenAI プロジェクト X の Prod キー」)。
保存します。プラットフォームはデータベースを即座に暗号化し、リストに次のように表示します。 ****abc3 最後の数桁はこの形式です。

値は上書きのみ可能であり、読み戻すことはできません

これは設計上安全です。プラットフォーム管理者でさえ資格情報の値を読み取ることはできません。元の値を忘れて変更する必要がある場合は、それを削除して再構築するか、「値の更新」で上書きするしかありません。

YAML での資格情報の引用

エージェント使用の場合: プロバイダーフィールド

yaml

agents:
  writer:
    preset: writer
    overrides:
      model: gpt-4.1-mini
      provider: openai_main          # 凭据中心里的凭据名

provider: openai_main エージェントに次のように伝えます。「LLM をデバッグするときは、資格情報センターの openai_main という名前のキーを使用してください。」プラットフォームは名前空間の順序で解析し、最初のヒットが有効になります。

コードステップでは、資格情報リストを使用します。

yaml

- id: charge_customer
  type: code
  language: node
  credentials:
    - stripe_secret                  # 声明需要这两个凭据
    - internal_api_token
  code: |
    const stripe = require('stripe')(process.env.STRIPE_SECRET);
    const internal = await fetch('https://api.mycompany.com/invoice', {
      headers: { Authorization: 'Bearer ' + process.env.INTERNAL_API_TOKEN }
    });
    // ...

説明:

credential: リストで明示的に宣言されたもののみを読み取ることができます。それらは他のステップに漏洩されません。
解析後、環境変数として挿入されます: 認証情報名 openai_main → 環境変数 OPENAI_MAIN (SCREAMING_SNAKE_CASE)。
process.env では宣言されたものだけが表示されます。資格情報センター内の他の資格情報は、このコードには表示されません。

変数式で参照される

一部のフィールド (sub_workflow の入力など) は直接入力できます。 {{credentials.xxx}} 引用:

yaml

- id: notify
  type: sub_workflow
  module: dingyue-module-slack-deliver
  inputs:
    slack_webhook_url: "{{credentials.slack_webhook_url}}"
    message_text: "..."

また、名前空間の順序で解析されます。資格情報の値は、現在のステップが実行されている場合にのみ有効になり、実行スナップショットには書き込まれません。

名前空間と解析順序

同じ名前が異なる名前空間に存在する可能性があります。実行中は、最初にヒットしたもの、最初に使用されたものの順に検索します。

個人の名前空間 — 自分でビルドした場合は、自分だけが参照できます。
チームの名前空間 — これはチームで共有され、すべてのメンバーが参照できます。チーム管理者のみが作成/削除できます。

推奨される使用方法

共有プロダクションキー (チーム有料アカウント) → チーム名前空間
自分自身のテスト用 / チームに入れることは決まっていない → 個人の名前空間
チーム全体に共通: 両方のレベルで同じ名前を使用します (openai_main など)。YAML で変更する必要はありません。テスト時には個人用の名前を使用し、オンラインになるとチームの名前に自動的に切り替わります。

プロバイダー: 複数のキーを異なるビジネスにバインドする

同じ LLM プロバイダー (OpenAI など) に複数のキー (テスト / 本番 / チーム / プロジェクト X / プロジェクト Y) がある場合、次のことができます。

資格情報センターのキーごとに 1 つのキーを作成します (名前の区別: openai_test / openai_prod_a / openai_prod_b)。
Agent の overrides.provider フィールドは、どれを使用するかを指定します。
異なるワークフローでは、エージェント定義をコピーすることなく、異なるプロバイダーを使用できますが、同じプリセットを使用できます。

yaml

agents:
  expensive:
    preset: universal
    overrides:
      model: claude-opus-4-7
      provider: anthropic_team_budget     # 团队有预算的那把

  cheap:
    preset: universal
    overrides:
      model: deepseek-v3-5
      provider: deepseek_personal         # 个人账户的

Claude Code / Codex サブスクリプション認証情報

AI アシスタントまたはワークフローエージェントがサブスクリプションクォータモデルを使用する場合は、「私の資格情報」で対応するプロバイダーを作成してください。

claude_code_oauth — Claude Code でログインして取得した OAuth トークン。
codex_subscription — Codex CLI ログインによって生成された auth.json の全文。

これらの値はエージェント/AI アシスタント設定には保存されませんが、実行時に対応する CLI に一時的に挿入されるだけです。

ローテーションと取り消し

正転

認証情報センター → 認証情報をクリック → 「値の更新」。
新しい値を入力して保存します。
それ以降に開始される新しい実行では、新しい値が使用されます。進行中の実行では、起動時にキャッシュされた古い値が引き続き使用されます。

緊急失効

私の認証情報が漏洩した可能性があるため、すぐに無効化したいと考えています。

資格情報センターで資格情報をクリック→「削除」します。
これを参照するすべてのステップは、次回実行時に credential_not_found で即座に失敗します。
次に、上流のプロバイダー (OpenAI / Anthropic...) に移動して、実際のキーを取り消します。

順序は重要です

まず Braidrun で削除してから、アップストリームで取り消します。逆の場合、削除する前にアップストリームで取り消すと、実行中の実行が突然大量に失敗します。

監査

監査ログは、認証情報の作成/更新/削除/参照解決の失敗ごとに記録されます。管理者は、「監査ログ」ページに移動して、event_type で credential_* をフィルターして表示できます。

参照解析が成功した場合、ログの爆発を避けるため、ログは記録されません。ただし、「この実行によってどの資格情報が解析されたか」というメタデータは、各実行の詳細に表示されます。

FAQ

代わりに環境変数を使用できますか?

技術的には可能ですが (チームの自己デプロイ環境変数を介して)、推奨されません。

環境変数はプロセスレベルのグローバル変数であり、任意のコードステップで process.env によって読み取ることができます。 Credential Center は、宣言した少数のもののみを挿入します。
環境変数のローテーションにはサービスを再起動する必要があり、資格情報センターの変更はすぐに有効になります。
環境変数は監査されません。

同僚は私の個人の名前空間認証情報を見ることができますか?

いいえ。チーム管理者でも、資格情報の存在 (リスト内) を確認することしかできませんが、値を確認したり、独自のワークフローで参照したりすることはできません。ランタイム解析は失敗します。

OAuth リフレッシュってどうするの？

主流の OAuth プロバイダー (Google / GitHub / Slack / Notion) の場合:refresh_token は資格情報センターに配置され、access_token プラットフォームは自動的に更新されます。他のプロバイダーの場合は、資格情報に長期有効なトークンを入れるか、更新コードステップを自分で記述する必要があります。

次のステップ

BYOK · 自分の LLM Key を利用 — 最も一般的な認証情報のシナリオ: 独自の LLM プロバイダーキーの構成
変数と式 — {{credentials.xxx}} 式の追加詳細
権限と役割 — 管理者権限はチーム名前空間にどのように割り当てられますか?