組み込みツール

組み込みツール (src/tools/*) 各ツールは任意です — キーがなければ、その機能は静かに無効化されます。

web_search / web_extract バックエンド

web_search と web_extract は同じバックエンドを共有します。モデルはプロバイダーを選べません。利用可能な最初の 1 つを使います: 1. Tavily — TAVILY_API_KEY。最優先。 2. Firecrawl — FIRECRAWL_API_KEY。Tavily が使えないときのみ。 3. Exa — ローカル EXA_API_KEY、またはサインイン済みの Minara セッション（プラットフォーム exaPassthrough）。Tavily も Firecrawl もないときのみ。チェーンフォールスルーはありません。DuckDuckGo / Google / Brave / Anthropic native 経路も、HTML フェッチ抽出もありません。空結果と HTTP エラーは選ばれたバックエンドに留まります。JS で壁打ちされたページは browser_navigate / browser_snapshot に任せます。高度なフィルタ（Exa category、Firecrawl sources/tbs、 Tavily topic/depth）は、稼働中バックエンドのツール schema にだけ出ます。

`EXA_API_KEY`

Exa の Web 検索と抽出（Tavily と Firecrawl の次）です。

制御対象: Tavily も Firecrawl も使えないときの web_search / web_extract バックエンドです。ローカルキーがあれば直接使い（プラットフォーム透過より優先）、未設定でもサインイン済みならプラットフォームの exaPassthrough で Exa を実行します。Exa はニューラル検索インデックスで、検索結果にはハイライトが付きます。抽出は /contents（クリーンなページテキスト）です。失敗しても別バックエンドへフォールスルーしません。
使用箇所: src/app.ts 内の createWebTools() 経由で src/tools/web-backends.ts。
設定するタイミング: Minara ログインに頼らずローカルで Exa を使いたいときに設定します。
未設定時: Tavily キーがあれば Tavily、なければ Firecrawl、なければサインイン済みなら Exa のままです。どれも無ければツールは非表示です。
形式: https://dashboard.exa.ai/api-keys から取得する Exa API キー。
設定の所在: 設定 → API キー

`FIRECRAWL_API_KEY`

Firecrawl の検索 + 抽出（Tavily の次）です。

制御対象: Tavily が使えないときの web_search / web_extract バックエンドです。/search はタイトル/URL、/scrape はクリーンな markdown（onlyMainContent: true）を返します。
使用箇所: src/app.ts 内の createWebTools() 経由で src/tools/web-backends.ts。
設定するタイミング: Tavily なしで検索と高品質な全ページ抽出の両方をカバーしたい場合に設定します。
未設定時: Firecrawl はスキップされ、ローカル Exa キーがあるかサインイン済みなら Exa を使います。
Free tier: 月 500 クレジット。形式: https://www.firecrawl.dev/app/api-keys から取得する Firecrawl API キー。
設定の所在: 設定 → API キー

`TAVILY_API_KEY`

Tavily の Web 検索と抽出（最優先）です。

制御対象: web_search と web_extract のデフォルトバックエンドです。失敗しても Firecrawl や Exa へフォールスルーしません。
使用箇所: src/app.ts 内の createWebTools() 経由で src/tools/web-backends.ts。
設定するタイミング: Tavily を Web リサーチのバックエンドにしたい場合に設定します。
未設定時: Firecrawl キーがあれば Firecrawl、なければ Exa（ローカルキーまたはサインイン透過）です。どれも無ければ web_search と web_extract は非表示のままです。DuckDuckGo フォールバックはありません。
形式: https://tavily.com から取得する Tavily API キー。
設定の所在: 設定 → API キー

`GOAL_MAX_TURNS`

継続中の /goal がレビューのために一時停止する前の、自動継続ターンの最大数です(REPL goal モード)。

未設定時のデフォルト: 20
形式: 正の整数
設定の所在: 設定 → 環境設定（schema キー）

`POSITION_MEMORY_ENABLED`

ポジション / セッションを意識したメモリ注入です。on のとき、資産に関わる各チャットターン(メッセージ内のティッカー、またはユーザーの最近の spot トップシンボルの 1 つ)では、その資産に関する最大 5 件の保存済みメモリが揮発性プロンプトテールに注入されます — アドバイス系の質問には過去の見解と取引メモ、ファンダメンタルズ系の質問にはユーザーの分析の好みと習慣です。決定論的かつローカル(キーワードインテントルーティング + SQLite ルックアップ、追加の LLM 呼び出しゼロ)で、取引シグナルは trading-summary の再構築でリフレッシュされる、事前構築済みの spot トップシンボルアーティファクトから得られます。app.ts (positionMemoryProvider) が memory/position-memory.ts 経由で消費します。preferences マネージャーを通じてライブで読み込まれるため、切り替えは次のターンで有効になります。

未設定時のデフォルト: off
形式: 有効化するには 1/true/yes/on
設定の所在: 設定 → 環境設定（schema キー）

`OPENAI_API_KEY`

OpenAI プラットフォームキー、多目的です。

制御対象: (1) research.knowledge_base スキル — Qdrant に書き込まれる text-embedding-3-* の埋め込み。 (2) src/tools/audio.ts の音声 TTS。 (3) 任意の LLM プロバイダー(オプトイン) — OpenAI OAuth 経路とは別物です。この env を設定するだけでは OpenAI が LLM プロバイダーとして自動選択されません。LLM 経路を有効にするには minara auth login openai --api-key $OPENAI_API_KEY を実行し、openaiApiKey プロファイルスロットに書き込みます。
使用箇所: src/skills/builtin/research/knowledge-base.ts、src/tools/audio.ts、src/llm/openai-api-key.ts。
未設定時: research KB の書き込みはスキップされ、TTS は利用不可、LLM は別のプロバイダーを使用します。
形式: https://platform.openai.com から取得する sk-...。
設定の所在: LLM プロバイダー資格情報（設定 → プロバイダーとモデル）

`OPENAI_BASE_URL`

OpenAI API のベース URL の任意のオーバーライドです。

制御対象: OpenAI api-key の LLM クライアント + ツールが呼び出す先です。
デフォルト: https://api.openai.com/v1
設定するタイミング: Azure OpenAI 互換のゲートウェイや、同じワイヤ形状の企業プロキシをターゲットにする場合に設定します。
未設定時: 公式 OpenAI エンドポイントが使用されます。
設定の所在: ユーザー向け設定ではありません

`OPENAI_ORG_ID`

任意の OpenAI 組織ヘッダーです。

制御対象: すべての LLM 呼び出しで OpenAI-Organization として送信されます。
設定するタイミング: OpenAI アカウントに複数の組織があり、課金を特定の組織へルーティングしたい場合に設定します。
未設定時: API キーに紐づくデフォルトの組織が使用されます。
設定の所在: ユーザー向け設定ではありません

`FAL_KEY` / `FAL_QUEUE_URL`

Fal.ai の画像 / メディアプロバイダーです。

制御対象: image_generate、video_generate、ライブ画像 / 動画モデルカタログの Fal.ai 認証です。
使用箇所: src/media/* とメディア生成ツール。
設定するタイミング: API キー認証を使う場合に設定します。代わりに「設定 > プロバイダーとモデル > 画像・動画」から Fal.ai にサインインできます。
未設定時: メディア生成には Fal.ai へのサインインが必要です。
形式: FAL_KEY は https://fal.ai から取得する不透明な文字列です。FAL_QUEUE_URL はキューエンドポイントの任意のオーバーライドです(絶対 URL。プライベートな Fal.ai デプロイを使用している場合にのみ設定します)。
設定の所在: 設定 → API キー (FAL_KEY)
設定の所在: ユーザー向け設定ではありません (FAL_QUEUE_URL)

メッセージングゲートウェイ

send_message ツール、ワークフロートリガー、オートパイロットレポートが使用するアウトバウンド通知の宛先です。複数のプロバイダーを同時に構成でき、 LLM が provider 引数で呼び出しごとに 1 つを選び、 MESSAGING_DEFAULT_PROVIDER にフォールバックします。 minara auth messaging add <provider> の使用を推奨します — ウィザードが認証情報を ~/.minara/credentials.json (messaging スロット) に保存し、このファイルには一切触れません。

`MESSAGING_DEFAULT_PROVIDER`

呼び出し側が provider 引数を省略したときの send_message のデフォルトプロバイダーです。

制御対象: 明示的な provider なしの send_message への agent-loop / workflow / autopilot 呼び出しは、この id にルーティングされます。
使用箇所: src/app.ts(ゲートウェイマップ構築)、src/tools/messaging.ts(ハンドラーディスパッチ)。
設定するタイミング: 複数のプロバイダーを構成しており、特定の 1 つをデフォルトにしたい場合に設定します(例: 個人向けアラートは telegram、チーム通知は slack — そしてデフォルトを telegram にしたい)。
未設定時: 最初に構成されたプロバイダーが優先されます(挿入順は src/messaging/providers.ts の MESSAGING_PROVIDERS に従います — telegram → discord → slack → whatsapp → signal → email → home_assistant)。
形式: プロバイダー id — telegram、discord、slack、whatsapp、signal、email、home_assistant のいずれか。大文字小文字は区別しません。
設定の所在: ユーザー向け設定ではありません

`MESSAGING_MAX_ATTACHMENT_BYTES`

send_message({attachments: [...]}) 呼び出しの添付ファイルごとのサイズ上限です。

制御対象: 各添付ファイルがプロバイダー API にアップロードされる前に、リゾルバーはサンドボックスファイルを stat し、サイズがこの値を超えると明確なエラーで拒否します。無制限の LLM 制御経路が巨大なファイルで SMTP リレー / Discord / Telegram を DOS することを防ぎます。
使用箇所: src/messaging/attachment-resolver.ts.
設定するタイミング: 運用者が 50 MB のデフォルトを厳しくしたい場合に設定します(例: Slack 無料枠の 1 GB ストレージ枠のため、または 1 分を超える音声をブロックするため)。
未設定時: デフォルトは 52 428 800 バイト (50 MB) です。プロバイダー API はそれぞれ独立して自身の上限を強制します — この上限は Minara 側の制限です。プロバイダーは API が大きすぎると見なすファイルを依然として拒否する場合があります。
形式: 10 進整数(バイト)。0 以下の値は無視されます。
設定の所在: ユーザー向け設定ではありません

`TELEGRAM_BOT_TOKEN` / `TELEGRAM_CHAT_ID`

アウトバウンドの Telegram メッセージングです。

制御対象: send_message ツールが Bot API 経由で指定のチャットに投稿します。ワークフロー通知やアラート出力で使用されます。Telegram は現在、ストリーミング編集サポートが標準で組み込まれている唯一のプロバイダーです(ゲートウェイの streamDefaultIntervalMs を参照)。
使用箇所: src/messaging/telegram.ts.
設定するタイミング: エージェント(またはワークフロートリガー)が Telegram のチャンネルや DM にアラートをプッシュするようにしたい場合に設定します。
未設定時: send_message は他のトランスポートでは引き続き動作しますが、Telegram 経路は明確な構成エラーを返します。
形式: TELEGRAM_BOT_TOKEN は @BotFather から取得する 123456:ABC-DEF... の文字列です。TELEGRAM_CHAT_ID は数値のチャット id です(チャンネル / グループは負、DM は正)。
設定の所在: 設定 → メッセージング

`TELEGRAM_RICH_TEXT`

アウトバウンドの返信を Telegram のリッチテキストとしてレンダリングします。

制御対象: on(デフォルト)のとき、markdown の返信は Telegram HTML(太字、見出し、テーブル、コードブロック、タスクリスト)にレンダリングされ、Telegram がマークアップを拒否した場合は MarkdownV2 → プレーンテキストにフォールバックします。ストリーミング編集は完全に閉じた構造のみをフラッシュするため、ユーザーが中途半端にレンダリングされた書式を見ることはありません。
使用箇所: src/messaging/telegram.ts.
設定するタイミング: エージェントのテキストを書式なしでそのまま送信するには false(または 0/no/off)に設定します。
未設定時: リッチテキストは ON です。
設定の所在: 設定 → 環境設定（schema キー）

`SLACK_BOT_TOKEN` / `SLACK_CHANNEL_ID`

アウトバウンドの Slack です。

制御対象: send_message ツールは、provider: "slack" が要求されたとき(または slack がデフォルトのとき)に Slack へルーティングします。アウトバウンドは共有の Vercel Chat SDK Slack アダプターが担います: SLACK_BOT_TOKEN が送信と post+edit ストリーミングを担い、SLACK_CHANNEL_ID が既定の送信先チャンネルです。下の SLACK_APP_TOKEN と組み合わせて Socket Mode のインバウンドストリームを開きます。
使用箇所: src/messaging/chatsdk/adapters/slack.ts.
設定するタイミング: チーム / 業務通知、および Slack の双方向チャットに設定します。
未設定時: send_message の Slack 経路は利用できません。他のプロバイダーは引き続き動作します。
形式: SLACK_BOT_TOKEN は xoxb- で始まります。SLACK_CHANNEL_ID は C... のチャンネル id です(#name ではありません)。
設定の所在: 設定 → メッセージング

`SLACK_APP_TOKEN`

Socket Mode インバウンド用のアプリレベルトークン (xapp-…) です。

制御対象: クライアントアウトバウンドの Slack インバウンドデーモン (Socket Mode) を有効にします。これを設定すると、エージェントは Slack への WebSocket を開き、Events API メッセージを受信します — 公開の Request URL / webhook サーバーは不要なので、公開 IP のないマシンでも双方向チャットが動作します。SLACK_BOT_TOKEN(返信の送信に使用)と組み合わせてください。
使用箇所: src/messaging/inbound/slack-daemon.ts.
設定するタイミング: 公開 webhook を晒さずに Slack の双方向チャットを行いたい場合に設定します(例: ラップトップ上 / NAT の背後で実行)。Slack アプリ設定の "Socket Mode" / "App-Level Tokens" で connections:write スコープを付けて生成します。
未設定時: Slack インバウンドは webhook 経路にフォールバックします(公開 Request URL + SLACK_SIGNING_SECRET が必要)。
形式: xapp-1-....
設定の所在: 設定 → メッセージング

`DISCORD_BOT_TOKEN` / `DISCORD_CHANNEL_ID`

アウトバウンドの Discord です。

制御対象: send_message ツールは、provider: "discord" が要求されたとき(または discord がデフォルトのとき)に Discord へルーティングします。1000ms スロットルで PATCH /channels/{id}/messages/{id} 経由のストリーミング編集をサポートします(Discord のレート制限 = チャンネルあたり 5/5sec)。
使用箇所: src/messaging/discord.ts.
設定するタイミング: コミュニティサーバー通知、Discord 中心のチーム。
未設定時: send_message の Discord 経路は利用できません。
形式: DISCORD_BOT_TOKEN は Developer Portal のアプリページから取得する不透明な bot シークレットです。DISCORD_CHANNEL_ID は数値のチャンネル snowflake です。bot は Send Messages + Manage Messages 権限でサーバー + チャンネルに招待されている必要があります(Manage Messages はストリーミング編集に依存する場合にのみ必要)。
設定の所在: 設定 → メッセージング

`HASS_URL` / `HASS_TOKEN` / `HASS_NOTIFY_SERVICE`

Home Assistant の通知です。

制御対象: send_message ツールは、provider: "home_assistant" が要求されたとき、Home Assistant の通知プラットフォームへルーティングします。ストリーミングはサポートしません(notify.* は fire-and-forget)。ヘルパーは確定時に単一の送信へフォールバックします。
使用箇所: src/messaging/home_assistant.ts.
設定するタイミング: 取引アラートをスマホプッシュ / Alexa TTS / その他の Home Assistant 経由のエンドポイントにプッシュしたい場合に設定します。
未設定時: send_message の Home Assistant 経路は利用できません。
形式: HASS_URL は完全なベース URL です(https://hass.example:8123、末尾スラッシュなし)。HASS_TOKEN は HA プロファイルから取得する長寿命のアクセストークンです。HASS_NOTIFY_SERVICE は notify サービス id です(mobile_app_pixel、alexa_tts。先頭の notify. は任意 — アダプターが除去します)。
設定の所在: 設定 → メッセージング

`SMTP_HOST` / `SMTP_PORT` / `SMTP_USER` / `SMTP_PASSWORD` / `EMAIL_FROM` / `EMAIL_TO`

アウトバウンドのメール (SMTP) です。

制御対象: send_message ツールは、provider: "email" が要求されたときにメールへルーティングします。件名はメッセージの最初の行から推測されます(120 文字以下、単一行) — それ以外は "Minara alert" にフォールバックします。ストリーミング編集はサポートしません。
使用箇所: src/messaging/email.ts (MIT ライセンスの nodemailer をラップ)。
設定するタイミング: コンプライアンス / アーカイブ用のチャンネル、または対象の受信者がチャットプラットフォームのいずれも使っていない場合に設定します。
未設定時: send_message のメール経路は利用できません。他のプロバイダーは引き続き動作します。
形式: SMTP_HOST はリレーのホスト名です。SMTP_PORT は STARTTLS では 587、SSL では 465 です(アダプターはポートで TLS モードを選びます — port === 465 のときにのみ secure: true)。SMTP_USER / SMTP_PASSWORD は認証情報です(Gmail にはアプリ固有パスワードを使用)。EMAIL_FROM は From ヘッダーのアドレスです。EMAIL_TO はデフォルトの受信者です(channel 経由でメッセージごとに上書き可能)。
設定の所在: 設定 → メッセージング

`GOOGLE_OAUTH_CLIENT_ID` / `GOOGLE_OAUTH_CLIENT_SECRET`

「Email (Gmail)」のワンクリック接続(プロバイダー id email-gmail)を支える、運用者が提供する Google OAuth クライアントです。

制御対象: Settings → Messaging の Connect-Gmail ボタンを有効にします。その後エージェントは、狭い gmail.send スコープを使って Gmail API 経由で通知を送信します(メールを読み取ることはありません)。
使用箇所: src/gateway/api.ts (OAuth init) + src/messaging/gmail.ts。
設定するタイミング: Gmail コネクターを提供する場合に設定します。Google Cloud コンソールで OAuth クライアントを「Desktop app」タイプ(ループバックリダイレクト)で作成し、ID + secret をここか、Email (Gmail) パネルに直接貼り付けます。優先順位は他のすべてのメッセージング認証情報と同じです: エクスポートされた env 変数が優先され、それ以外は UI に保存された値が使用されます。
未設定のとき(かつ UI にも入力されていないとき): Connect-Gmail ボタンは無効になります。他のプロバイダーは引き続き動作します。
preferences-schema-coverage: SKIP — メッセージングプロバイダーの認証情報は Preferences スキーマではなく Settings → Messaging で管理されます(SMTP_* / TELEGRAM_* と同じ)。
設定の所在: 設定 → メッセージング

`GMAIL_REFRESH_TOKEN` / `GMAIL_SENDER_EMAIL` / `GMAIL_TO`

Gmail 接続状態です。GMAIL_REFRESH_TOKEN と GMAIL_SENDER_EMAIL は Connect-Gmail フローによって書き込まれます(手動で設定する必要はありません)。GMAIL_TO は任意の受信者オーバーライドです — 空のままにすると、接続済みの受信トレイ自体に通知をプッシュします(push-to-self)。 preferences-schema-coverage: SKIP — 上記の GOOGLE_OAUTH_CLIENT_ID を参照してください。

設定の所在: 設定 → メッセージング

`WHATSAPP_ACCESS_TOKEN` / `WHATSAPP_PHONE_NUMBER_ID` / `WHATSAPP_RECIPIENT`

Meta Cloud API 経由のアウトバウンドの WhatsApp です。

制御対象: send_message ツールは、provider: "whatsapp" が要求されたときに WhatsApp へルーティングします。ストリーミング編集はサポートしません(Meta の編集 API には 15 分の枠 + 厳しいレート制限があり、LLM のトークンストリーミングには不向きです)。
使用箇所: src/messaging/whatsapp.ts.
設定するタイミング: WhatsApp Business API へのアクセスを持つ Meta Business アプリをプロビジョニング済みで、WhatsApp 経由で通知を配信する必要がある場合に設定します。
未設定時: send_message の whatsapp 経路は利用できません。
形式: WHATSAPP_ACCESS_TOKEN は、Meta Developer Portal またはあなたの Business System User が発行する、長い不透明な Bearer トークンです(通常 EAA... で始まります)。WHATSAPP_PHONE_NUMBER_ID は登録済みのビジネス電話番号の数値 id です。WHATSAPP_RECIPIENT は E.164 形式のデフォルト受信者 (+12025551234) です — send_message の channel 引数が呼び出しごとに上書きします。
Note: 受信者はアクティブな 24 時間のカスタマーサービス枠を持っているか、事前承認済みのテンプレートメッセージを送られる必要があります — これは Meta のポリシー制約であり、私たちのものではありません。プレーンテキストメッセージは、ユーザーが過去 24 時間以内にそのビジネスにメッセージを送った場合にのみ機能します。
設定の所在: 設定 → メッセージング

`SIGNAL_CLI_NUMBER` / `SIGNAL_RECIPIENT` / `SIGNAL_CLI_BINARY`

アウトバウンドの Signal です。

制御対象: send_message ツールは、provider: "signal" が要求されたときに Signal へルーティングします。他のすべてのプロバイダーと異なり、Signal には HTTP API がありません — Minara はローカルで signal-cli(MIT ライセンス、https://github.com/AsamK/signal-cli)にシェルアウトします。ストリーミング編集はサポートしません(Signal プロトコルは編集を許可していません)。
使用箇所: src/messaging/signal.ts.
設定するタイミング: プライバシー重視のアラートを Signal の受信者に送りたく、ホストに signal-cli ツールが利用可能な場合に設定します。
未設定時: send_message の signal 経路は利用できません。
Runtime dependency: signal-cli がインストールされ PATH 上にある必要があります (macOS: brew install signal-cli。Debian: 上流リポジトリを参照)。初回使用の前に、送信元番号を登録します: signal-cli -u +15555550100 register 次に、電話に届く SMS コードを入力します。app のブート時にバイナリが存在しない場合、signal プロバイダーは静かにスキップされます — 他のプロバイダーは引き続き動作します。
形式: SIGNAL_CLI_NUMBER と SIGNAL_RECIPIENT は両方とも E.164 形式でなければなりません (先頭の +、国番号、合計 8〜15 桁、スペースやダッシュなし — 例 +12025551234)。アダプターは構築時と send() 呼び出しごとに正規表現を検証し、受信者の前に -- を置く固定 argv レイアウトを使用して、先頭ダッシュのフラグインジェクションをブロックします。SIGNAL_CLI_BINARY はバイナリパスの任意のオーバーライドです — デフォルトは signal-cli の PATH ルックアップです。
CLAUDE.md §4a Bucket B 免除: このモジュールはサブプロセスを spawn しますが、shell: false の argv 形式を使用し、LLM 入力は argv に到達しません — メッセージ本文は別個の -m スロット経由で渡され、受信者は書き込まれる前に正規表現で検証されます。
設定の所在: 設定 → メッセージング

インバウンドメッセージング Webhook (任意、kill-switch 付き)

インバウンドリスナーは自動的には起動しません — 呼び出し側が自分で InboundServer をインスタンス化します (src/messaging/inbound/server.ts 参照)。有効化されると、Telegram、Discord、Slack からの署名付き Webhook を受信し、正規化された InboundMessage イベントを登録済みの単一ハンドラーへディスパッチします。WhatsApp + Signal のインバウンドはこの PR では接続されていません (WhatsApp は証明書交換のハンドシェイクが必要、Signal は signal-cli デーモンの JSON-RPC ソケットを使用します — どちらも独自の PR に値します)。

`TELEGRAM_WEBHOOK_SECRET`

Telegram が X-Telegram-Bot-Api-Secret-Token ヘッダーでエコーバックする共有シークレットです。setWebhook の secret_token パラメーターと同時に設定します。

制御対象: このヘッダーが欠落または不一致のリクエストは、ハンドラーが実行される前に 401 を返します。
未設定時: /webhooks/telegram ルートは 404 を返します — インバウンドサーバーは Telegram インバウンドが構成されていないかのように振る舞います。
形式: 不透明な文字列、1〜256 文字(Telegram 自身の制約)。
設定の所在: ユーザー向け設定ではありません

`SLACK_SIGNING_SECRET`

Slack アプリの署名シークレット(bot トークンではありません)です。

制御対象: v0:{timestamp}:{body} に対する HMAC-SHA256 を使用した webhook 署名検証で、Slack が公開しているスキームに従います。
未設定時: /webhooks/slack は 404 を返します。
形式: Basic Information → App Credentials から取得する不透明な 16 進文字列。
設定の所在: 設定 → メッセージング

`DISCORD_PUBLIC_KEY` / `DISCORD_APPLICATION_ID`

Discord アプリの識別情報です。

制御対象: Vercel Chat SDK の Discord アダプターのコンストラクターは(Gateway モードでも)アプリケーション公開鍵を必須とするため、アダプターを構築するには DISCORD_BOT_TOKEN と併せて DISCORD_PUBLIC_KEY を設定する必要があります。DISCORD_APPLICATION_ID は任意で、スラッシュコマンド登録のためにアプリを識別します。
未設定時: Discord は未設定として扱われます(公開鍵なしではアダプターを構築できません)。
形式: DISCORD_PUBLIC_KEY は 64 文字の小文字 16 進(生の 32 バイト Ed25519 公開鍵)。DISCORD_APPLICATION_ID は数値のアプリ id です。
設定の所在: 設定 → メッセージング

`WHATSAPP_APP_SECRET` / `WHATSAPP_VERIFY_TOKEN`

WhatsApp Cloud API のインバウンド webhook (Meta) です。

制御対象: - WHATSAPP_APP_SECRET は X-Hub-Signature-256 経由ですべての POST に署名します (生のボディに対する HMAC-SHA256)。署名が不正 → 401。 - WHATSAPP_VERIFY_TOKEN は、運用者が Meta ダッシュボードで webhook URL を登録するときの一度きりの GET ハンドシェイクでエコーされる Meta の hub.verify_token です。
未設定時: - WHATSAPP_APP_SECRET なし → /webhooks/whatsapp POST = 404。 - WHATSAPP_VERIFY_TOKEN なし → /webhooks/whatsapp GET = 404。
形式: 不透明な文字列。app secret は Meta アプリダッシュボードの 16 進、verify token はあなたが構成した任意の値です。
設定の所在: 設定 → メッセージング

PR2: アジア圏 IM プラットフォーム (Lark / WeCom / DingTalk / WeChat OA / QQ / LINE)

各ブロックは、src/messaging/inbound/specs/<id>.ts が必要とするアウトバウンド認証情報とインバウンド Webhook シークレットの両方を設定します。いずれかのブロックを空のままにすると、そのプロバイダーのアウトバウンド + インバウンドが両方とも無効になります。ルートは 404 を返し、ゲートウェイはライブマップから除外されます。

`LARK_APP_ID` / `LARK_APP_SECRET` / `LARK_DEFAULT_CHAT_ID` / `LARK_VERIFICATION_TOKEN` / `LARK_ENCRYPT_KEY` / `LARK_DOMAIN`

Lark / Feishu — LARK_*。テナントトークンのアウトバウンド + 署名 / 暗号化された webhook イベントです。

制御対象: アウトバウンドの Lark IM メッセージング。agent-loop 向けのインバウンド webhook イベント (im.message.receive_v1)。
使用箇所: src/messaging/lark.ts + src/messaging/inbound/specs/lark.ts.
形式: LARK_APP_ID — Lark developer console から取得する cli_xxxxx。 LARK_APP_SECRET — 同じコンソールから取得する不透明なシークレット。 LARK_DEFAULT_CHAT_ID — デフォルトの oc_xxxxx チャット id。 LARK_VERIFICATION_TOKEN — Event Subscription の検証トークン。 LARK_ENCRYPT_KEY — 任意の Event Subscription 暗号化キー。設定されると、インバウンドの POST ボディは SHA256(encrypt_key) の下で AES-256-CBC 暗号化されて届きます。プレーンテキストモードにするには空のままにします。 LARK_DOMAIN — open.feishu.cn(デフォルト、中国本土)または open.larksuite.com(国際版)。
設定の所在: 設定 → メッセージング

`WECOM_CORP_ID` / `WECOM_AGENT_ID` / `WECOM_SECRET` / `WECOM_DEFAULT_TOUSER` / `WECOM_CALLBACK_TOKEN` / `WECOM_CALLBACK_AES_KEY`

WeCom (企业微信) の自作アプリケーションです。

制御対象: WeCom のユーザー / 部門へのアウトバウンド + 署名付き AES 暗号化コールバックのインバウンドです。WeCom は両方の表面を WeChat OA と同じレガシーな SHA1+AES エンベロープでルーティングします。
使用箇所: src/messaging/wecom.ts + src/messaging/inbound/specs/wecom.ts.
形式: WECOM_CORP_ID — "我的企业" ページから取得する corp ID。 WECOM_AGENT_ID — アプリケーションの agent ID(数値)。 WECOM_SECRET — アプリケーションのシークレット。 WECOM_DEFAULT_TOUSER — デフォルトの受信者(エージェント全体には @all)。 WECOM_CALLBACK_TOKEN — "接收消息" コールバック設定の Token。 WECOM_CALLBACK_AES_KEY — 同じページの 43 文字 EncodingAESKey。
設定の所在: 設定 → メッセージング

`DINGTALK_WEBHOOK_URL` / `DINGTALK_WEBHOOK_SECRET`

DingTalk (钉钉) のカスタムグループロボット — HMAC 署名付きのアウトバウンド webhook です。

制御対象: ロボットの webhook URL 経由での DingTalk グループへのアウトバウンドです(DingTalk の仕様に従い timestamp + secret で署名)。インバウンドは DingTalk が POST し返す送信メッセージ webhook を待ち受けます。
使用箇所: src/messaging/dingtalk.ts + src/messaging/inbound/specs/dingtalk.ts.
形式: DINGTALK_WEBHOOK_URL — https://oapi.dingtalk.com/robot/send?access_token=… の URL。 DINGTALK_WEBHOOK_SECRET — "签名" モードの SECxxxx 署名シークレット。
設定の所在: 設定 → メッセージング

`DINGTALK_STREAM_APP_KEY` / `DINGTALK_STREAM_APP_SECRET`

Stream Mode のインバウンドです。

制御対象: クライアントアウトバウンドの DingTalk Stream Mode デーモンを有効にします。両方を設定すると、エージェントはゲートウェイ WebSocket を開き、その上で bot メッセージを受信します — 公開コールバック URL は不要なので、公開 IP のないマシンでも双方向チャットが動作します。上記のロボット webhook とは別物です: Stream Mode は組織アプリ (AppKey / AppSecret) として認証し、返信は依然としてロボット webhook 経由で送出されます。
使用箇所: src/messaging/inbound/dingtalk-daemon.ts.
設定するタイミング: 公開コールバックを晒さずに DingTalk の双方向チャットを行いたい場合に設定します。AppKey / AppSecret は DingTalk developer console のアプリの "凭证与基础信息" ページで見つかります。
未設定時: DingTalk インバウンドは送信 webhook 経路にフォールバックします(公開コールバック URL が必要)。
形式: DingTalk developer console から取得する不透明な文字列。
設定の所在: 設定 → メッセージング

`WECHAT_OA_APP_ID` / `WECHAT_OA_APP_SECRET` / `WECHAT_OA_TOKEN` / `WECHAT_OA_AES_KEY` / `WECHAT_OA_DEFAULT_OPENID`

WeChat OA (公众号) のカスタマーサービスメッセージングです。

制御対象: アウトバウンドのカスタマーサービスメッセージ(ユーザーの 48 時間のインタラクション枠内である必要があります — 枠外ではプラットフォームが errcode 45015 を返します)。インバウンド: 署名 + AES 暗号化されたメッセージイベント。
使用箇所: src/messaging/wechat_oa.ts + src/messaging/inbound/specs/wechat_oa.ts.
形式: WECHAT_OA_APP_ID / WECHAT_OA_APP_SECRET — OA の AppID + AppSecret。 WECHAT_OA_TOKEN — 公众平台 → 设置 → 服务器配置のサーバー設定 Token。 WECHAT_OA_AES_KEY — 同じページの 43 文字 EncodingAESKey。 WECHAT_OA_DEFAULT_OPENID — デフォルトの受信者 openid。
設定の所在: 設定 → メッセージング

`QQ_BOT_APP_ID` / `QQ_BOT_APP_SECRET` / `QQ_BOT_TOKEN` / `QQ_BOT_DEFAULT_CHANNEL_ID`

QQ Bot v2 (Official Bot OpenAPI) です。

RATE LIMIT WARNING: 公式 bot は 1 か月あたり bot ごとにわずか 4 件のアクティブ
メッセージ、加えて 1 日あたり 200 件のアクティブ DM、加えて
チャンネルごとに 1 日あたり 20 件のアクティブサブチャンネルメッセージに制限されています。
ほとんどのインタラクションはパッシブ返信(ユーザー起点のメッセージから 5 秒以内)を使わなければなりません。
アクティブプッシュは重大なアラート用に予約されています。
使用箇所: src/messaging/qq.ts + src/messaging/inbound/specs/qq.ts.
形式: QQ_BOT_APP_ID — bot AppID(数値)。 QQ_BOT_APP_SECRET — bot Secret(アウトバウンド認証と、インバウンドの Ed25519 署名検証のシードの両方に使用)。 QQ_BOT_TOKEN — bot トークン(レガシーフィールド、互換性のため保持)。 QQ_BOT_DEFAULT_CHANNEL_ID — デフォルトのターゲット。形式は <kind>:<id> で、kind は c2c | group | channel | dm。裸の id はデフォルトで channel:。
設定の所在: 設定 → メッセージング

`LINE_CHANNEL_ACCESS_TOKEN` / `LINE_CHANNEL_SECRET` / `LINE_DEFAULT_USER_ID`

LINE Messaging API です。

制御対象: アウトバウンドの LINE プッシュメッセージ(有料の従量課金)と、署名付きのインバウンド webhook イベントです。リプライトークン(無料)はまだ接続されていません — すべてのアウトバウンドは従量課金のプッシュ API を経由します。
使用箇所: src/messaging/line.ts + src/messaging/inbound/specs/line.ts.
形式: LINE_CHANNEL_ACCESS_TOKEN — LINE Developers から取得する長寿命の bearer。 LINE_CHANNEL_SECRET — インバウンドの X-Line-Signature を検証するために使用するチャネルシークレット(HMAC-SHA256、base64)。 LINE_DEFAULT_USER_ID — デフォルトの受信者 userId / groupId / roomId。
設定の所在: 設定 → メッセージング

PR3: 欧米圏 IM + フェデレーション (Mattermost / Teams / Google Chat / BlueBubbles / Matrix)

`MATTERMOST_URL` / `MATTERMOST_BOT_TOKEN` / `MATTERMOST_DEFAULT_CHANNEL_ID` / `MATTERMOST_OUTGOING_WEBHOOK_TOKEN`

Mattermost — bot トークンのアウトバウンド + 送信 webhook のインバウンドです。

CAVEAT: Mattermost の送信 webhook 機能は PUBLIC チャンネルでのみ、かつ webhook に
構成された TRIGGER WORD でのみ発火します。
プライベートチャンネルと DM には WebSocket bot 経路が必要です(将来の PR)。
使用箇所: src/messaging/mattermost.ts + src/messaging/inbound/specs/mattermost.ts.
形式: MATTERMOST_URL — Mattermost サーバー URL(末尾スラッシュなし)。 MATTERMOST_BOT_TOKEN — bot アカウントのパーソナルアクセストークン。 MATTERMOST_DEFAULT_CHANNEL_ID — デフォルトのターゲットチャンネル。 MATTERMOST_OUTGOING_WEBHOOK_TOKEN — 送信 webhook ボディの token フィールドと照合されるトークン(定数時間)。
設定の所在: 設定 → メッセージング

`TEAMS_BOT_APP_ID` / `TEAMS_BOT_APP_PASSWORD` / `TEAMS_BOT_TENANT_ID` / `TEAMS_DEFAULT_CONVERSATION_ID` / `TEAMS_DEFAULT_SERVICE_URL`

Microsoft Teams — JWT 検証付きインバウンドの Bot Framework です。

インバウンドの JWT 検証は JWKS を次から動的に取得します:
https://login.botframework.com/v1/.well-known/openidconfiguration —
JWKS URL をどこにもハードコードしないでください。Microsoft がローテーションします。
使用箇所: src/messaging/teams.ts + src/messaging/inbound/specs/teams.ts.
形式: TEAMS_BOT_APP_ID — bot の Microsoft App ID GUID。 TEAMS_BOT_APP_PASSWORD — bot の Microsoft App パスワード。 TEAMS_BOT_TENANT_ID — マルチテナントは common、シングルテナントは GUID。 TEAMS_DEFAULT_CONVERSATION_ID — プッシュ先のデフォルトの会話。 TEAMS_DEFAULT_SERVICE_URL — デフォルトの Bot Framework serviceUrl (通常 https://smba.trafficmanager.net/teams)。本番コードはこれをインバウンドのアクティビティから学習し、会話ごとに永続化すべきです。この env 変数はブートストラップのフォールバックです。
設定の所在: 設定 → メッセージング

`GOOGLE_CHAT_CREDENTIALS` / `GOOGLE_CHAT_USE_ADC` / `GOOGLE_CHAT_PROJECT_NUMBER` / `GOOGLE_CHAT_DEFAULT_SPACE_ID`

Google Chat — Vercel Chat SDK アダプター(サービスアカウントまたは ADC; webhook インバウンド)です。

制御対象: アウトバウンドとインバウンドは共有の Vercel Chat SDK Google Chat アダプターが担います。インバウンドは Google 署名付きの webhook / Pub/Sub プッシュで、 InboundServer が /webhooks/google_chat を chat.webhooks.google_chat へ転送します(MESSAGING_INBOUND_ENABLED=1 が必要)。
使用箇所: src/messaging/chatsdk/adapters/google_chat.ts.
形式: GOOGLE_CHAT_CREDENTIALS — サービスアカウント認証情報 JSON(またはキーファイルへのパス)。CLAUDE.md §4: パスはデータ / サンドボックスツリーの内部でなければならず、運用者の管理外のパスを参照してはいけません。 GOOGLE_CHAT_USE_ADC — true にするとアプリケーションデフォルト認証情報 (ADC)を使用します。 GOOGLE_CHAT_DEFAULT_SPACE_ID — デフォルトのスペースリソース名 (例 spaces/AAAA1234567)。
設定の所在: 設定 → メッセージング

`BLUEBUBBLES_SERVER_URL` / `BLUEBUBBLES_PASSWORD` / `BLUEBUBBLES_DEFAULT_CHAT_GUID`

BlueBubbles — セルフホストサーバー上の iMessage ブリッジです。

運用者は、目的の iMessage アカウントにサインインし続ける Mac 上で
BlueBubbles サーバーを実行する必要があります。認証は
単一の共有パスワードです — 純粋な定数時間比較で、HMAC はありません。
使用箇所: src/messaging/bluebubbles.ts + src/messaging/inbound/specs/bluebubbles.ts.
形式: BLUEBUBBLES_SERVER_URL — BlueBubbles サーバーの公開 URL (通常 ngrok / cloudflared のようなトンネル)。 BLUEBUBBLES_PASSWORD — サーバーパスワード(?guid= クエリと一致)。 BLUEBUBBLES_DEFAULT_CHAT_GUID — デフォルトのチャット GUID (例 iMessage;-;+15551234567)。
設定の所在: 設定 → メッセージング

`MATRIX_HOMESERVER` / `MATRIX_ACCESS_TOKEN` / `MATRIX_USER_ID` / `MATRIX_DEFAULT_ROOM_ID`

Matrix — フェデレーテッドなクライアント-サーバー API です。インバウンドは long-poll デーモンとして動作し(HTTP webhook なし)、MESSAGING_MATRIX_INBOUND でゲートされます。

使用箇所: src/messaging/matrix.ts + src/messaging/inbound/matrix-daemon.ts.
形式: MATRIX_HOMESERVER — homeserver URL(例 https://matrix.org)。 MATRIX_ACCESS_TOKEN — 長寿命のアクセストークン。Bearer ヘッダーを使用し、非推奨の ?access_token= クエリ形式は使わないでください。 MATRIX_USER_ID — bot ユーザー(例 @bot:example.org)。/sync での自己ループのフィルタリングに使用されます。 MATRIX_DEFAULT_ROOM_ID — デフォルトの room id(例 !abc:example.org)。
Caveats: このゲートウェイはエンドツーエンド暗号化 (E2EE) の
ルームをサポートしません。プレーンテキストのルームのみが、デーモンが消費する
m.room.message イベントを発行します。
設定の所在: 設定 → メッセージング

`MESSAGING_MATRIX_INBOUND`

Matrix /sync デーモンの kill-switch です。

制御対象: 設定されると、app のブート時に、Matrix のルームメッセージを agent-loop ブリッジへ発行する long-poll リスナーが起動します。
使用箇所: src/app.ts のプロバイダーレジストリの inboundDaemon 列挙経由で src/messaging/inbound/matrix-daemon.ts。
形式: 1/true/yes/on(大文字小文字を区別しない)。
設定の所在: 設定 → 環境設定（schema キー）

`MESSAGING_TELEGRAM_POLLING` / `MESSAGING_DISCORD_GATEWAY` / `MESSAGING_SLACK_SOCKET` / `MESSAGING_MATTERMOST_WS` / `MESSAGING_QQ_WS` / `MESSAGING_DINGTALK_STREAM` / `MESSAGING_LARK_WS`

クライアントアウトバウンドのインバウンドデーモン — オーバーライドスイッチです。

これらのプラットフォームは webhook(プラットフォームが公開 URL へ IN 方向に
接続)と、クライアントアウトバウンドのデーモン(エージェントが OUT 方向に接続し、
長い接続 / ポーリングを保持)の両方をサポートします。デーモンこそが、双方向チャットを
公開 IP のない個人マシンで動作させるものです — トンネルなし、第三者
なし。
デフォルトでは、各デーモンは、プラットフォームのアウトバウンド認証情報が
構成され、かつそのための公開 webhook が接続されていない
(すなわち webhook 署名シークレットが未設定、または MESSAGING_INBOUND_ENABLED
が off)ときに自動起動します。プラットフォームに webhook を構成すると、代わりに
webhook インバウンドを維持します。これらのスイッチはその
自動判断の明示的なオーバーライドであり、3 値です: - 未設定 / 空 → auto(上記のデフォルト) - 1/true/yes/on → デーモンを強制的に ON - 0/false/no/off → デーモンを強制的に OFF(webhook のみを維持) MESSAGING_TELEGRAM_POLLING — Telegram getUpdates の long-poll (src/messaging/inbound/telegram-daemon.ts)。Webhook シグナル: TELEGRAM_WEBHOOK_SECRET。 MESSAGING_DISCORD_GATEWAY — Discord Gateway WebSocket。Interactions webhook では扱えない通常のチャンネル / DM メッセージも配信します (src/messaging/inbound/discord-daemon.ts)。Discord developer portal で特権的な "Message Content" インテントを有効にする必要があります。 Webhook シグナル: DISCORD_APPLICATION_PUBLIC_KEY。 MESSAGING_SLACK_SOCKET — Slack Socket Mode。SLACK_APP_TOKEN が必要 (src/messaging/inbound/slack-daemon.ts)。Webhook シグナル: SLACK_SIGNING_SECRET。 MESSAGING_MATTERMOST_WS — Mattermost v4 WebSocket bot。送信 webhook 経路では届かない DM / プライベートチャンネルにも到達します (src/messaging/inbound/mattermost-daemon.ts)。Webhook シグナル: MATTERMOST_OUTGOING_WEBHOOK_TOKEN。 MESSAGING_QQ_WS — QQ v2 ゲートウェイ WebSocket (src/messaging/inbound/qq-daemon.ts)。webhook 専用のシグナルはありません (QQ の webhook はアウトバウンドの QQ_BOT_APP_SECRET を再利用)。そのため QQ が構成されているときは常にゲートウェイデーモンが優先されます。webhook を使うには MESSAGING_QQ_WS=0 に設定します。 MESSAGING_DINGTALK_STREAM — DingTalk Stream Mode。 DINGTALK_STREAM_APP_KEY / _SECRET が必要 (src/messaging/inbound/dingtalk-daemon.ts)。DINGTALK_WEBHOOK_SECRET は webhook インバウンドではなくアウトバウンド送信に署名するため、デーモンを抑制しません。webhook を使うには MESSAGING_DINGTALK_STREAM=0 に設定します。 MESSAGING_LARK_WS — 公式 SDK 経由の Lark / Feishu 長接続 (src/messaging/inbound/lark-daemon.ts)。Webhook シグナル: LARK_VERIFICATION_TOKEN。
設定の所在: ユーザー向け設定ではありません

`MESSAGING_INBOUND_TRANSCRIBE`

インバウンドメッセージでの音声メッセージの文字起こしを有効にします。OPENAI_API_KEY が必要です。

制御対象: 1/true/yes/on に設定されると、インバウンドの音声添付ファイルがダウンロードされ、OpenAI Whisper で文字起こしされ、その文字起こしが InboundMessage.text に格納されます。元の音声は attachments に保持されるため、ダウンストリームの消費側で再生できます。
使用箇所: src/messaging/inbound/transcribe.ts(後続作業でインバウンドメッセージノーマライザーから呼び出されます)。
未設定時: 音声添付ファイルは空の text で届き、どのようにルーティングするかは呼び出し側の責任になります。
形式: 1/true/yes/on(大文字小文字を区別しない)。
設定の所在: 設定 → 環境設定（schema キー）

`MESSAGING_VOICE_REPLY`

インバウンドの音声メモに、ストリームされるテキストに加えて、音声返信の添付ファイルで応答します。

制御対象: エージェントのテキスト返信が確定した後、その返信は音声に合成され、同じチャンネル / スレッドに音声(または機能に応じて audio/file)添付ファイルとして送り返されます。インバウンドメッセージ自体が文字起こしされた音声添付ファイルを含んでいた場合にのみ発火します。TTS の失敗がテキスト返信を壊すことはありません。
使用箇所: voice-delivery ヘルパー経由で src/messaging/inbound/agent-bridge.ts。構成済みの音声プロバイダー(ELEVENLABS_API_KEY または OPENAI_API_KEY)が必要です。
形式: 1/true/yes/on(大文字小文字を区別しない)。
設定の所在: 設定 → 環境設定（schema キー）

`ELEVENLABS_API_KEY`

ElevenLabs の音声プラットフォームキーです。

制御対象: ゲートウェイの /v1/voice/* エンドポイント、Web 読み上げ、メッセージングの音声返信全体にわたる、音声合成(TTS、eleven_turbo_v2_5)と文字起こし(STT、Scribe)の優先プロバイダーです。設定されると、音声には OpenAI より ElevenLabs が自動選択されます(低レイテンシー)。OpenAI はフォールバックのまま残り、OGG/Opus の音声メモ(Telegram)を生成できる唯一のプロバイダーです。
使用箇所: src/voice/resolve.ts.
未設定時: 音声は OPENAI_API_KEY にフォールバックします。それも未設定の場合、音声機能は利用できません(明確なエラー、クラッシュなし)。
形式: https://elevenlabs.io から取得する sk_...。
設定の所在: ユーザー向け設定ではありません

`VOICE_COMPOSER_STT_PROVIDER` / `VOICE_COMPOSER_STT_MODEL` / `VOICE_CONVERSATION_STT_PROVIDER` / `VOICE_CONVERSATION_STT_MODEL` / `VOICE_FILE_STT_PROVIDER` / `VOICE_FILE_STT_MODEL` / `VOICE_REPLY_TTS_PROVIDER` / `VOICE_REPLY_TTS_MODEL`

シナリオ別の音声 Provider とモデル。

制御対象: 入力欄の音声入力、ハンズフリー会話、音声ファイル/メッセージ、Agent の音声返信を個別に設定します。Provider は auto、openai、elevenlabs です。
Defaults: 入力欄/会話は auto + gpt-live-transcribe、ファイル/メッセージは auto + gpt-transcribe、返信は auto + Provider 推奨 TTS モデルが既定です。
Compatibility: VOICE_STT_PROVIDER/MODEL はファイル用、VOICE_TTS_PROVIDER/MODEL は返信用の互換エイリアスです。シナリオ別の変数が優先されます。
使用箇所: src/voice/resolve.ts と /v1/voice/* Gateway ルート。
設定の所在: 設定 → 環境設定（schema キー）

`VOICE_TTS_PROVIDER`

音声合成のベンダーを固定します。

制御対象: TTS のみについて、自動選択(ElevenLabs 優先、OpenAI フォールバック)を上書きします。
使用箇所: src/voice/resolve.ts(ランタイム preference voice.ttsProvider)。
形式: auto | elevenlabs | openai。デフォルト: auto。
設定の所在: 設定 → 環境設定（schema キー）

`VOICE_TTS_VOICE`

返信が読み上げられるときに使用される voice id です。

制御対象: プライマリの TTS プロバイダーにそのネイティブな voice id として渡されます(ElevenLabs の voice id、または alloy のような OpenAI の voice 名)。フォールバックプロバイダーは自身のデフォルト voice を使用します。
使用箇所: src/voice/resolve.ts(ランタイム preference voice.ttsVoice)。
未設定時: プロジェクトのデフォルト voice / OpenAI "alloy"。
設定の所在: 設定 → 環境設定（schema キー）

`VOICE_TTS_MODEL`

プライマリプロバイダーの TTS モデル id です。

制御対象: ElevenLabs のモデル(Settings -> Voice models で選択されるデフォルトでもあります)、および OpenAI がプライマリの場合の OpenAI のモデルです。ElevenLabs の選択肢: eleven_v3(最も人間的、デフォルト)、eleven_multilingual_v2、eleven_turbo_v2_5、eleven_flash_v2_5。
使用箇所: src/voice/settings.ts(ElevenLabs ベース) + src/voice/resolve.ts(OpenAI、ランタイム preference voice.ttsModel)。
未設定時: eleven_v3(ElevenLabs) / gpt-4o-mini-tts(OpenAI)。
設定の所在: 設定 → 環境設定（schema キー）

`VOICE_TTS_STABILITY` / `VOICE_TTS_SIMILARITY_BOOST` / `VOICE_TTS_STYLE` / `VOICE_TTS_SPEAKER_BOOST` / `VOICE_TTS_SPEED` / `VOICE_TTS_FAST_FIRST`

音声配信のデフォルト(ElevenLabs の voice_settings)です。各項目が BASE を設定し、Settings -> Voice models のスライダーがユーザーごとに上から上書きします。

使用箇所: src/voice/settings.ts. VOICE_TTS_STABILITY 0..1 — 低いほど生き生き、高いほど安定(デフォルト 0.6) VOICE_TTS_SIMILARITY_BOOST 0..1 — voice の音色への忠実度(デフォルト 0.8) VOICE_TTS_STYLE 0..1 — 表現力 / 個性(デフォルト 0.45) VOICE_TTS_SPEAKER_BOOST 1/0 — 明瞭度ブースト(デフォルト on) VOICE_TTS_SPEED 0.7..1.2 — 再生レート(デフォルト 0.9) VOICE_TTS_FAST_FIRST 1/0 — 各返信の最初の文を最速のモデルで読み上げ、発話がより早く始まるようにする (デフォルト on)
設定の所在: ユーザー向け設定ではありません

`VOICE_STT_PROVIDER`

音声認識(STT)のベンダーを固定します。

使用箇所: src/voice/resolve.ts(ランタイム preference voice.sttProvider)。
形式: auto | elevenlabs | openai。デフォルト: auto。
設定の所在: 設定 → 環境設定（schema キー）

`VOICE_FFMPEG_PATH`

音声トランスコード用の任意の ffmpeg バイナリです。

制御対象: AMR の音声形式(WeCom、組み込みトランスクリプトのない WeChat OA)は STT の前に ffmpeg を経由し、WeCom の音声返信は mp3 → AMR にトランスコードします。未設定のときは PATH で "ffmpeg" が探索されます。どちらも解決できない場合、それらのトランスコードはスキップされ、影響を受けるプラットフォームは適切に劣化します。
使用箇所: src/messaging/audio-transcode.ts.
設定の所在: ユーザー向け設定ではありません

`VOICE_STT_MODEL`

プライマリプロバイダーの STT モデル id です。

使用箇所: src/voice/resolve.ts(ランタイム preference voice.sttModel)。
未設定時: scribe_v1(ElevenLabs) / gpt-4o-mini-transcribe(OpenAI)。
設定の所在: 設定 → 環境設定（schema キー）

`TWITTERAPI_API_KEY`

サードパーティの Twitter/X スクレイピングプロバイダーです。

制御対象: twitterapi.io スクレイパー経由でツイート、プロフィール、検索結果を読み取ります(レート制限あり、OAuth 不要)。
使用箇所: src/tools/providers/twitterapi.ts。requires_env 経由で research.social.twitter スキルをゲートします。
設定するタイミング: デベロッパーアプリを持たずに research.social スキルでライブの Twitter データを取得したい場合に設定します。
未設定時: research.social.twitter はスキルカタログから隠されます。
形式: https://twitterapi.io から取得する不透明な API キー。
X_API_BEARER_TOKEN(公式の X API)とは別物です — こちらは
サードパーティのスクレイパーに向かい、もう一方は api.x.com/2 に
直接話しかけます。どちらか一方、または両方を設定できます。
設定の所在: 設定 → API キー

`X_API_BEARER_TOKEN`

X (Twitter) 公式 API の bearer トークンです。

制御対象: api.x.com/2 への読み取り専用の app-only アクセス(検索、ルックアップ、タイムライン)。
使用箇所: src/tools/providers/x-api.ts。requires_env 経由で組み込みの x.api スキルをゲートします。
設定するタイミング: https://developer.x.com でデベロッパーアプリを所有しており、エージェントが twitterapi.io スクレイパーの代わりに(またはそれに加えて)公式 API に話しかけるようにしたい場合に設定します。
未設定時: x.api スキルはカタログから隠されます。
形式: console.x.com から取得する Bearer トークン — 長い不透明な文字列。
設定の所在: 設定 → API キー

`GLASSNODE_API_KEY`

Glassnode のオンチェーン分析です。

制御対象: オンチェーンメトリクスのエンドポイント(SOPR、MVRV、realised cap、フローなど)。
使用箇所: src/tools/providers/glassnode.ts。requires_env 経由で research.onchain.glassnode スキルをゲートします。
設定するタイミング: Glassnode のサブスクリプションを持っており、エージェントがオンチェーン指標を直接引用するようにしたい場合に設定します。
未設定時: glassnode スキルはカタログから隠されます。
形式: https://glassnode.com から取得する不透明な API キー。
設定の所在: 設定 → API キー

`QDRANT_URL` / `QDRANT_API_KEY`

research KB 用のベクトルデータベースです。

制御対象: (1) research.knowledge_base スキル — エージェントに、terminal から curl 経由で運用者が精選した Qdrant コレクション(news、projects、people、 docs)をクエリすることを教えます。 (2) kb_search ツール — 同じ Qdrant クエリ経路の第一級ラッパーで、 institution モードのアナリスト(news / fundamentals / sentiment)が web_search にフォールバックする前に使用します。
使用箇所: src/skills/builtin/research-knowledge-base.ts(スキル)と src/tools/kb-search.ts(institution モードのツール)。両方とも QDRANT_URL の存在でゲートされます。kb_search はさらに、構成済みの埋め込みプロバイダー(EMBEDDING_PROVIDER + EMBEDDING_API_KEY)を必要とします。
設定するタイミング: オープン Web 検索が返すよりも新しく / 絞り込まれたニュース + プロジェクトの事実を得るために、エージェントが既存の v1 で投入済みの Qdrant インスタンスをクエリするようにしたい場合に設定します。
未設定時: knowledge_base スキルはカタログから隠され、kb_search ツールは登録されません。institution のアナリストは既存の web_search にフォールバックします(動作変更なし)。
形式: QDRANT_URL は絶対 URL です(https://xxx.qdrant.io)。QDRANT_API_KEY は任意です — デプロイが認証を必要とする場合にのみ設定します(Qdrant Cloud は必要、ローカルの docker は通常不要)。
設定の所在: ユーザー向け設定ではありません (QDRANT_URL)
設定の所在: 設定 → API キー (QDRANT_API_KEY)

`KB_EMBEDDING_PROVIDER` / `KB_EMBEDDING_API_KEY` / `KB_EMBEDDING_MODEL` / `KB_EMBEDDING_DIM`

kb_search 専用の KB 固有の Embedder オーバーライドです。

制御対象: kb_search のクエリ文字列を Qdrant に投稿する前に埋め込むために、どの embedder を使用するかです。embedder は Qdrant コレクションを最初に投入したものと一致していなければなりません — 次元の不一致は、呼び出しごとに Qdrant から 400 を返します。
設定するタイミング: kb_search の Qdrant インスタンスが、メモリに使う embedder(EMBEDDING_PROVIDER / EMBEDDING_MODEL)とは異なる embedder で投入された場合にのみ設定します。よくあるケース: v1 の Qdrant が OpenAI text-embedding-3-small (1536d) で投入されている一方、メモリには voyage-3 (1024d) を使っている。
未設定時: kb_search は共有の embedder(EMBEDDING_PROVIDER + EMBEDDING_API_KEY + EMBEDDING_MODEL + EMBEDDING_DIM)にフォールバックします。メモリと KB が同じモデルを共有していれば、オーバーライドは不要です。
形式: 上記の EMBEDDING_* ファミリーと同一の受け入れ値です。KB_EMBEDDING_API_KEY は未設定のとき EMBEDDING_API_KEY をデフォルトにします(そのため OpenAI ユーザーは provider + model のオーバーライドだけを設定すれば済みます)。
設定の所在: ユーザー向け設定ではありません (KB_EMBEDDING_PROVIDER, KB_EMBEDDING_MODEL, KB_EMBEDDING_DIM)
設定の所在: 設定 → API キー (KB_EMBEDDING_API_KEY)

`E2B_API_KEY`

Kernel クラウドブラウザのコーディネータ（https://e2b.dev）。

制御対象: ワークベンチが Kernel クラウド Chromium（コーディネータサンドボックス）を起動できるようにします。KERNEL_API_KEY と併用。このキーはシェル・ファイル・execute_code をゲートウェイホストから移しません。
使用箇所: ワークベンチのクラウドブラウザランタイム（Kernel bootstrap）が使用。呼び出し時に解決（Settings → API Keys で追加したキーは再起動不要）。
設定するタイミング: Desktop/CLI でローカルブラウザの代わりに Kernel Live View を使うとき。Hosted Web Browser のコーディネータにも必要。
未設定時: クラウドブラウザ placement は使えず、ホストが許せば Desktop/CLI はローカルブラウザのまま。
形式: https://e2b.dev ダッシュボードの不透明キー。
Safety: bash のため共有 org キーを per-user hosted agent に入れない。シェルはゲートウェイ VM に留まる。
設定の所在: 設定 → API キー

`KERNEL_API_KEY`

KERNEL_API_KEY、Web Browser ワークベンチ用のマネージド Chromium。

制御対象: Web Browser ワークベンチが使用する Kernel クラウド Chromium セッションを作成します。同じセッションが埋め込み Live View と Agent のブラウザーツール用 CDP エンドポイントを提供します。
使用箇所: ワークベンチのクラウドブラウザーランタイムが使用します。呼び出し時に解決されるため、Settings > API Keys で保存したキーは再起動なしで反映されます。
設定するタイミング: Web ユーザーが対話型リモートブラウザーを必要とする場合に設定します。kernel-browser コーディネーター用に E2B_API_KEY も必要です。
未設定時: Web Browser は Kernel の公式キードキュメントとダッシュボードへのリンクを含む設定画面を表示します。Desktop のネイティブ Browser は引き続き利用できます。
形式: https://dashboard.onkernel.com で作成する不透明な API キーです。
設定の所在: 設定 → API キー

`WORKBENCH_E2B_SESSION_IDLE_SECONDS`

Web クラウドリソース一時停止の猶予時間。

制御対象: 最後の Web クライアントが Chat または Institution セッションを離れてから、そのセッションのクラウド Browser を一時停止するまで Gateway が待機する時間です。一時停止はタイムアウトまで Kernel セッションを保持します。ゲートウェイ上の shell は影響を受けません。
使用箇所: Preferences computer.cloudSessionIdleSeconds → Gateway のワークベンチクラウドリソースリーパーが使用します。Desktop のネイティブ Browser と Computer セッションはこの設定を使用しません。
未設定時のデフォルト: 60 秒（1 分）。
設定するタイミング: 遅いセッション切り替えでもクラウド状態を維持するには長くし、早く一時停止するには短くします。Settings → Preferences を優先し、env は上書きです。猶予時間内に戻ると保留中の一時停止は取り消されます。
形式: 0 から 3600 までの有限な秒数。無効値または負の値では既定の 60 秒を使用します。Terminal には影響しません。
設定の所在: 設定 → 環境設定（schema キー）

`MINARA_HOST_KIND`

Gateway ホスト分類の上書き。

制御対象: Browser/Computer バックエンド選択に使うホスト種別を強制します: desktop | local-cli | hosted-e2b | web-remote。
使用箇所: src/computer/host.ts（currentHostKind）が使用します。配置、capability、Chromium 起動方針、プライベート URL ルールがこの分類を読みます。
未設定時のデフォルト: 未設定時は MINARA_DESKTOP_PID / computer bridge / CDP、E2B_SANDBOX_ID または CREDENTIALS_DEK+/data、次に GATEWAY_HOST から推定し、それ以外は local-cli です。
設定するタイミング: テストと運用診断専用です。本番の Desktop と hosted-e2b は自動シグナルに依存してください。
形式: 値は desktop、local-cli、hosted-e2b、web-remote のいずれかです。
設定の所在: ユーザー向け設定ではありません

`MINARA_COMPUTER_BACKEND`

セッション実行環境を固定（local / cloud / docker）。

制御対象: セッション実行環境（ブラウザ、シェル、ファイル）を local / cloud / docker に固定するか、auto（Desktop ローカル優先）のままにします。シェルとファイルは docker を固定しない限りゲートウェイプロセスに従います。cloud は Kernel クラウドブラウザだけを選びます。GUI のコンピュータ操作は Desktop のみ。hosted では bash は agent VM、ブラウザは cloud。
使用箇所: Preferences computer.backend → src/computer/backends.ts（readSessionBackendOverride）とセッション実行環境の placement（SessionRuntimeStore 経由）が使用します。
未設定時のデフォルト: 未設定時の自動: hosted → ローカルシェル + クラウドブラウザ；Desktop はネイティブブリッジが使えるとき本機優先（クラウドキーがあっても）；ブリッジ無しの Desktop は E2B_API_KEY + KERNEL_API_KEY があるときブラウザは cloud、なければ local；local-cli は常に local（キーは明示の Cloud ブラウザ固定を有効にするだけ）。auto は docker を選びません — docker を明示してください。
設定するタイミング: Settings → Preferences → セッション実行環境を推奨。cloud は Kernel ブラウザを強制（シェルはこのホスト）；docker はローカルコンテナ（MINARA_DOCKER_SANDBOX_IMAGE が必要）；local は Desktop ブリッジを強制（欠けると明確に失敗）。
形式: auto、local、cloud、または docker。空 / 未設定 = auto。
設定の所在: 設定 → 環境設定（schema キー）

`MINARA_DOCKER_SANDBOX_IMAGE`

Docker 実行バックエンドのイメージ。

制御対象: 粘着 docker 実行バックエンド（同一コンテナ内のシェル + ファイル + execute_code）用のコンテナイメージ。Preferences computer.backend=docker（または MINARA_COMPUTER_BACKEND=docker）で選択——呼び出しごとの environment 上書きはありません。強化: パッケージマネージャに必要な最小限以外の capability を削除、no-new-privileges、PID 制限、サイズ制限付き /tmp；ホスト bind マウントなし、ホスト env 転送なし。チャットセッションごとに 1 コンテナ、呼び出し間で再利用、15 分アイドル後に削除。
使用箇所: src/tools/_execution/docker-environment.ts、src/app.ts の ExecutionRouter 経由。呼び出し時に解決。
設定するタイミング: 別のクラウド VM に送らずに信頼できないコードへ強いローカル分離を付けたいとき。稼働中の Docker（または Podman）デーモンが必要；CLI は PATH と一般的な Docker Desktop の場所から探します。
未設定時: docker バックエンドは使えません；code/shell はゲートウェイホストで動きます。
形式: 必要な言語ランタイムを含むプル可能なイメージ参照、例: python:3.12-slim や node:22-slim。
Safety: ローカル隔離と同じ姿勢——コンテナがセキュリティ境界で、environment_provision_credentials で明示的に供給しない限りホスト資格情報を持ちません。docker は Preferences computer.backend=docker の固定でのみ選択（呼び出しごと上書きなし）。
設定の所在: ユーザー向け設定ではありません

`MINARA_GITHUB_APP_CLIENT_ID`

Coding の GitHub ログイン用公開クライアント ID。

制御対象: 構造化 HTTPS Git と Pull Request 用の GitHub App デバイスフロー資格情報 Provider を有効にします。
使用箇所: Desktop リリース CI が product-config.json に埋め込み、Desktop が公開値を src/app/bootstrap.ts に渡して CodingGitService を配線します。Shell またはプロジェクト .env は開発時の上書きとして残ります。
設定するタイミング: デバイスフローと審査済みリポジトリ権限を持つ Minara GitHub App を登録した場合に設定します。
未設定時: 未設定では GitHub 接続に運用設定が必要と表示され、ローカル SSH は独立して利用できます。
形式: 任意の製品用 GitHub App client id（例: Iv1.example）。client secret ではありません。
設定の所在: ユーザー向け設定ではありません

`MINARA_FILTERED_SSH_AGENT`

Desktop 内部の SSH 権限マーカー。

制御対象: SSH_AUTH_SOCK が Desktop 管理のフィルター済みエンドポイントであり、所有者が選んだ ID だけを公開することを示します。
使用箇所: ローカル SSH 資格情報 Provider の配線時に src/gateway/api.ts が読み取ります。
設定するタイミング: 手動では設定しません。フィルター済み SSH agent プロキシの稼働中だけ Minara Desktop が注入します。
未設定時: 未設定では、制限のない環境 SSH agent を信頼せず、ローカル SSH 資格情報 Provider は利用不可のままです。
形式: 内部値は 1 です。それ以外は未設定として扱います。
設定の所在: ユーザー向け設定ではありません

`MINARA_CLOUD_CREDENTIAL_FILES`

docker 実行コンテナにプロビジョニングされる認証情報ファイル — 運用者が宣言、アップロードのみ。

制御対象: environment_provision_credentials がクラウド VM にアップロードするファイル群で、そこで実行されるコードが認証できるようにします。エージェントはパスを選べません — この設定のみが選べます。各エントリーは、データディレクトリ内のファイルを VM の絶対パスの宛先にマッピングします。ローカルパスは MINARA_DATA_DIR からの相対でなければなりません。絶対パス、.. トラバーサル、データディレクトリを抜け出すシンボリックリンクは、パース時にエントリーごとに拒否されます。プロビジョニングされた VM パスはアップロードのみです: environment_pull_file はそれらを読み戻すことを拒否し、ファイルの内容がモデルコンテキストに入ることは決してありません。
使用箇所: src/tools/environment-files.ts 経由で src/tools/_execution/credential-provision.ts。
設定するタイミング: クラウド VM で実行するコードが API キーファイル / トークンファイルを必要とする場合に設定します。読み取り専用で影響範囲の小さい認証情報を優先してください — VM は完全なネットワーク egress を持ちます。ウォレットキーや資金移動の認証情報をここに宣言してはいけません。
未設定時: environment_provision_credentials はファイルなしと報告します。クラウド実行は認証情報なしです(デフォルトの姿勢)。
形式: {"local": "<relative path>", "remote": "/abs/vm/path"} の JSON 配列。例: [{"local":"cloud-creds/market.json","remote":"/root/.creds/market.json"}]
設定の所在: ユーザー向け設定ではありません

目次