chore(i18n): refresh ja-JP translations

2026-04-08 04:47:04 +00:00 · 2026-04-08 04:47:04 +00:00 · 5fb5bd9966
commit 5fb5bd9966
parent cf0be8a534
8 changed files with 1466 additions and 1000 deletions
--- a/docs/ja-JP/concepts/memory.md
+++ b/docs/ja-JP/concepts/memory.md
@ -1,89 +1,114 @@
 ---
 read_when:
    - メモリの仕組みを理解したい
-    - どのメモリファイルに書けばよいか知りたい
-summary: OpenClaw がセッションをまたいでどのように記憶するか
+    - どのメモリファイルに書き込むべきか知りたい
+summary: OpenClaw がセッションをまたいで物事を記憶する仕組み
 title: メモリの概要
 x-i18n:
-    generated_at: "2026-04-06T03:06:44Z"
+    generated_at: "2026-04-08T04:42:03Z"
    model: gpt-5.4
    provider: openai
-    source_hash: d19d4fa9c4b3232b7a97f7a382311d2a375b562040de15e9fe4a0b1990b825e7
+    source_hash: 3bb8552341b0b651609edaaae826a22fdc535d240aed4fad4af4b069454004af
    source_path: concepts/memory.md
    workflow: 15
 ---

 # メモリの概要

-OpenClaw は、エージェントのワークスペース内に**プレーンな Markdown ファイル**を書き込むことで物事を記憶します。モデルが「記憶」できるのはディスクに保存されたものだけであり、隠れた状態はありません。
+OpenClaw は、エージェントのワークスペース内に**プレーンな Markdown ファイル**を書き込むことで物事を記憶します。モデルが「記憶」するのはディスクに保存された内容だけであり、隠れた状態はありません。

 ## 仕組み

 エージェントには、メモリに関連する 3 つのファイルがあります。

- **`MEMORY.md`** -- 長期記憶。永続的な事実、好み、決定事項。すべての DM セッションの開始時に読み込まれます。
- **`memory/YYYY-MM-DD.md`** -- デイリーノート。継続中の文脈と観察事項。今日と昨日のノートは自動的に読み込まれます。
- **`DREAMS.md`**（実験的、任意） -- 人間が確認するための Dream Diary と dreaming sweep の要約。
+- **`MEMORY.md`** -- 長期メモリ。永続的な事実、設定、判断を保存します。すべての DM セッションの開始時に読み込まれます。
+- **`memory/YYYY-MM-DD.md`** -- 日次ノート。継続中のコンテキストと観察内容を保存します。今日と昨日のノートは自動的に読み込まれます。
+- **`DREAMS.md`** (実験的、任意) -- 人間が確認するための Dream Diary と dreaming sweep の要約です。

 これらのファイルはエージェントのワークスペース（デフォルトは `~/.openclaw/workspace`）にあります。

 <Tip>
-エージェントに何かを覚えていてほしい場合は、単にそう頼んでください: 「TypeScript を好むことを覚えておいて」。すると適切なファイルに書き込まれます。
+エージェントに何かを覚えておいてほしい場合は、単にこう頼んでください: 「TypeScript を好むことを覚えておいて。」すると、適切なファイルに書き込まれます。
 </Tip>

 ## メモリツール

 エージェントには、メモリを扱うための 2 つのツールがあります。

- **`memory_search`** -- 元の表現と語句が異なっていても、意味検索を使って関連するメモを見つけます。
+- **`memory_search`** -- 元の表現と語句が異なる場合でも、セマンティック検索を使って関連するノートを見つけます。
 - **`memory_get`** -- 特定のメモリファイルまたは行範囲を読み取ります。

-どちらのツールも、アクティブなメモリプラグイン（デフォルト: `memory-core`）によって提供されます。
+どちらのツールも、アクティブなメモリ plugin（デフォルト: `memory-core`）によって提供されます。
+
+## Memory Wiki コンパニオン plugin
+
+永続メモリを単なる生のノートではなく、維持管理されたナレッジベースのように扱いたい場合は、同梱の `memory-wiki` plugin を使用してください。
+
+`memory-wiki` は、永続的な知識を次の要素を持つ wiki vault にコンパイルします。
+
+- 決定論的なページ構造
+- 構造化された主張と根拠
+- 矛盾と鮮度の追跡
+- 生成されるダッシュボード
+- エージェント/ランタイム利用者向けにコンパイルされたダイジェスト
+- `wiki_search`、`wiki_get`、`wiki_apply`、`wiki_lint` などの wiki ネイティブなツール
+
+これはアクティブなメモリ plugin を置き換えるものではありません。アクティブなメモリ plugin は引き続き、想起、昇格、dreaming を管理します。`memory-wiki` は、その横に出所情報が豊富な知識レイヤーを追加します。
+
+詳しくは [Memory Wiki](/ja-JP/plugins/memory-wiki) を参照してください。

 ## メモリ検索

-埋め込みプロバイダーが設定されている場合、`memory_search` は**ハイブリッド検索**を使います。これはベクトル類似度（意味的な近さ）とキーワード一致（ID やコードシンボルのような正確な語）を組み合わせるものです。サポートされている任意のプロバイダーの API キーがあれば、追加設定なしで動作します。
+埋め込みプロバイダーが設定されている場合、`memory_search` は**ハイブリッド検索**を使用します。これは、ベクトル類似度（意味的な近さ）とキーワード一致（ID やコードシンボルのような正確な用語）を組み合わせるものです。対応プロバイダーのいずれかの API キーがあれば、そのまま利用できます。

 <Info>
 OpenClaw は、利用可能な API キーから埋め込みプロバイダーを自動検出します。OpenAI、Gemini、Voyage、または Mistral のキーが設定されていれば、メモリ検索は自動的に有効になります。
 </Info>

-検索の仕組み、チューニングオプション、プロバイダー設定の詳細は、[メモリ検索](/ja-JP/concepts/memory-search) を参照してください。
+検索の仕組み、調整オプション、プロバイダーの設定について詳しくは、[Memory Search](/ja-JP/concepts/memory-search) を参照してください。

 ## メモリバックエンド

 <CardGroup cols={3}>
-<Card title="Builtin（デフォルト）" icon="database" href="/ja-JP/concepts/memory-builtin">
+<Card title="内蔵（デフォルト）" icon="database" href="/ja-JP/concepts/memory-builtin">
 SQLite ベース。キーワード検索、ベクトル類似度、ハイブリッド検索がそのまま使えます。追加の依存関係は不要です。
 </Card>
 <Card title="QMD" icon="search" href="/ja-JP/concepts/memory-qmd">
-ローカルファーストのサイドカーで、再ランキング、クエリ拡張、ワークスペース外のディレクトリをインデックス化する機能を備えています。
+ローカルファーストのサイドカー。再ランキング、クエリ拡張、ワークスペース外のディレクトリのインデックス化に対応します。
 </Card>
 <Card title="Honcho" icon="brain" href="/ja-JP/concepts/memory-honcho">
-ユーザーモデリング、意味検索、複数エージェント認識を備えた、AI ネイティブなクロスセッションメモリ。プラグインのインストールが必要です。
+ユーザーモデリング、セマンティック検索、マルチエージェント認識を備えた、AI ネイティブなクロスセッションメモリ。plugin のインストールが必要です。
+</Card>
+</CardGroup>
+
+## ナレッジ wiki レイヤー
+
+<CardGroup cols={1}>
+<Card title="Memory Wiki" icon="book" href="/ja-JP/plugins/memory-wiki">
+永続メモリを、主張、ダッシュボード、bridge mode、Obsidian に適したワークフローを備えた、出所情報が豊富な wiki vault にコンパイルします。
 </Card>
 </CardGroup>

 ## 自動メモリフラッシュ

-[compaction](/ja-JP/concepts/compaction) が会話を要約する前に、OpenClaw は重要な文脈をメモリファイルに保存するようエージェントへ思い出させるサイレントターンを実行します。これはデフォルトで有効で、設定は不要です。
+[compaction](/ja-JP/concepts/compaction) が会話を要約する前に、OpenClaw はエージェントに重要なコンテキストをメモリファイルへ保存するよう促すサイレントターンを実行します。これはデフォルトで有効で、設定は不要です。

 <Tip>
-メモリフラッシュは、compaction 中のコンテキスト損失を防ぎます。会話の中に、まだファイルへ書き込まれていない重要な事実がある場合、要約が行われる前に自動的に保存されます。
+メモリフラッシュは、compaction 中のコンテキスト損失を防ぎます。会話の中に重要な事実があり、まだファイルに書き込まれていない場合は、要約が行われる前に自動的に保存されます。
 </Tip>

 ## Dreaming（実験的）

-Dreaming は、メモリのための任意のバックグラウンド統合処理です。短期的なシグナルを収集し、候補をスコアリングし、条件を満たした項目だけを長期記憶（`MEMORY.md`）へ昇格させます。
+Dreaming は、メモリのための任意のバックグラウンド統合処理です。短期的なシグナルを収集し、候補をスコアリングし、基準を満たした項目だけを長期メモリ（`MEMORY.md`）に昇格させます。

-これは、長期記憶のシグナル対ノイズ比を高く保つよう設計されています。
+これは、長期メモリのシグナル品質を高く保つよう設計されています。

 - **オプトイン**: デフォルトでは無効です。
- **スケジュール実行**: 有効にすると、`memory-core` が完全な dreaming sweep のための定期 cron ジョブを 1 つ自動管理します。
- **しきい値あり**: 昇格は、スコア、想起頻度、クエリ多様性の各ゲートを通過する必要があります。
- **レビュー可能**: フェーズ要約と日誌エントリは、人間が確認できるよう `DREAMS.md` に書き込まれます。
+- **スケジュール実行**: 有効にすると、`memory-core` が完全な dreaming sweep 用の定期 cron ジョブを 1 つ自動管理します。
+- **しきい値判定**: 昇格には、スコア、想起頻度、クエリ多様性のゲートを通過する必要があります。
+- **レビュー可能**: フェーズ要約と日記エントリは、人間が確認できるよう `DREAMS.md` に書き込まれます。

-フェーズの動作、スコアリングシグナル、Dream Diary の詳細は、[Dreaming（実験的）](/concepts/dreaming) を参照してください。
+フェーズの挙動、スコアリングシグナル、Dream Diary の詳細については、[Dreaming (experimental)](/ja-JP/concepts/dreaming) を参照してください。

 ## CLI

@ -96,9 +121,10 @@ openclaw memory index --force   # インデックスを再構築
 ## さらに読む

 - [Builtin Memory Engine](/ja-JP/concepts/memory-builtin) -- デフォルトの SQLite バックエンド
- [QMD Memory Engine](/ja-JP/concepts/memory-qmd) -- 高度なローカルファーストサイドカー
+- [QMD Memory Engine](/ja-JP/concepts/memory-qmd) -- 高度なローカルファーストのサイドカー
 - [Honcho Memory](/ja-JP/concepts/memory-honcho) -- AI ネイティブなクロスセッションメモリ
- [Memory Search](/ja-JP/concepts/memory-search) -- 検索パイプライン、プロバイダー、チューニング
- [Dreaming（実験的）](/concepts/dreaming) -- 短期想起から長期記憶へのバックグラウンド昇格
- [メモリ設定リファレンス](/ja-JP/reference/memory-config) -- すべての設定項目
+- [Memory Wiki](/ja-JP/plugins/memory-wiki) -- コンパイル済みナレッジ vault と wiki ネイティブなツール
+- [Memory Search](/ja-JP/concepts/memory-search) -- 検索パイプライン、プロバイダー、調整
+- [Dreaming (experimental)](/ja-JP/concepts/dreaming) -- 短期的な想起から長期メモリへのバックグラウンド昇格
+- [Memory configuration reference](/ja-JP/reference/memory-config) -- すべての設定項目
 - [Compaction](/ja-JP/concepts/compaction) -- compaction がメモリとどう相互作用するか
--- a/docs/ja-JP/concepts/model-providers.md
+++ b/docs/ja-JP/concepts/model-providers.md
@ -1,38 +1,40 @@
 ---
 read_when:
    - プロバイダーごとのモデル設定リファレンスが必要な場合
-    - モデルプロバイダー向けの設定例や CLI のオンボーディングコマンドを確認したい場合
+    - モデルプロバイダー向けの設定例や CLI オンボーディングコマンドを確認したい場合
 summary: 設定例と CLI フローを含むモデルプロバイダーの概要
 title: モデルプロバイダー
 x-i18n:
-    generated_at: "2026-04-08T02:16:11Z"
+    generated_at: "2026-04-08T04:43:51Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 26b36a2bc19a28a7ef39aa8e81a0050fea1d452ac4969122e5cdf8755e690258
+    source_hash: 558ac9e34b67fcc3dd6791a01bebc17e1c34152fa6c5611593d681e8cfa532d9
    source_path: concepts/model-providers.md
    workflow: 15
 ---

 # モデルプロバイダー

-このページでは、**LLM/モデルプロバイダー**（WhatsApp/Telegram のようなチャットチャネルではなく）を扱います。
+このページでは、**LLM/モデルプロバイダー**（WhatsApp/Telegram のようなチャットチャネルではありません）を扱います。
 モデル選択ルールについては、[/concepts/models](/ja-JP/concepts/models) を参照してください。

 ## クイックルール

 - モデル参照は `provider/model` を使用します（例: `opencode/claude-opus-4-6`）。
 - `agents.defaults.models` を設定すると、それが許可リストになります。
- CLI ヘルパー: `openclaw onboard`、`openclaw models list`、`openclaw models set <provider/model>`
- フォールバックのランタイムルール、クールダウンプローブ、セッション上書きの永続化は
-  [/concepts/model-failover](/ja-JP/concepts/model-failover) に記載されています。
+- CLI ヘルパー: `openclaw onboard`, `openclaw models list`, `openclaw models set <provider/model>`
+- フォールバックのランタイムルール、クールダウンプローブ、セッション上書きの永続化は、[/concepts/model-failover](/ja-JP/concepts/model-failover) に
+  記載されています。
 - `models.providers.*.models[].contextWindow` はネイティブなモデルメタデータです。
  `models.providers.*.models[].contextTokens` は実効ランタイム上限です。
- プロバイダープラグインは `registerProvider({ catalog })` によってモデルカタログを注入できます。
+- プロバイダープラグインは `registerProvider({ catalog })` を通じて
+  モデルカタログを注入できます。
  OpenClaw はその出力を `models.providers` にマージしてから
  `models.json` を書き込みます。
- プロバイダーマニフェストは `providerAuthEnvVars` を宣言できるため、
-  汎用の環境変数ベース認証プローブでプラグインのランタイムを読み込む必要がありません。残るコアの環境変数マップは、非プラグイン/コアプロバイダーと、Anthropic の API キー優先オンボーディングのような一部の汎用優先順位ケース向けだけになりました。
- プロバイダープラグインは、以下を通じてプロバイダーのランタイム動作も所有できます:
+- プロバイダーマニフェストでは `providerAuthEnvVars` を宣言できるため、
+  汎用の env ベース認証プローブでプラグインランタイムを読み込む必要がありません。残るコアの env var
+  マップは、非プラグイン/コアプロバイダーと、Anthropic の API キー優先オンボーディングのような一部の汎用優先順位ケースのみを対象としています。
+- プロバイダープラグインは、以下を通じてプロバイダーのランタイム動作も所有できます。
  `normalizeModelId`, `normalizeTransport`, `normalizeConfig`,
  `applyNativeStreamingUsageCompat`, `resolveConfigApiKey`,
  `resolveSyntheticAuth`, `shouldDeferSyntheticProfileAuth`,
@ -48,131 +50,219 @@ x-i18n:
  `isCacheTtlEligible`, `buildMissingAuthMessage`, `suppressBuiltInModel`,
  `augmentModelCatalog`, `isBinaryThinking`, `supportsXHighThinking`,
  `resolveDefaultThinkingLevel`, `applyConfigDefaults`, `isModernModelRef`,
-  `prepareRuntimeAuth`, `resolveUsageAuth`, `fetchUsageSnapshot`, and
+  `prepareRuntimeAuth`, `resolveUsageAuth`, `fetchUsageSnapshot`, および
  `onModelSelected`。
- 注: プロバイダーランタイムの `capabilities` は共有ランナーメタデータ（プロバイダーファミリー、トランスクリプト/ツールの癖、トランスポート/キャッシュのヒント）です。これは、プラグインが何を登録するか（テキスト推論、音声など）を説明する [public capability model](/ja-JP/plugins/architecture#public-capability-model) とは異なります。
+- 注: プロバイダーランタイムの `capabilities` は共有ランナーのメタデータです（プロバイダーファミリー、文字起こし/ツール関連の癖、トランスポート/キャッシュのヒント）。これは、プラグインが登録する内容（テキスト推論、音声など）を説明する
+  [公開 capability model](/ja-JP/plugins/architecture#public-capability-model)
+  とは同じではありません。

 ## プラグイン所有のプロバイダー動作

-プロバイダープラグインは、OpenClaw が汎用推論ループを維持しつつ、
-ほとんどのプロバイダー固有ロジックを所有できるようになりました。
+OpenClaw が汎用推論ループを維持しつつ、プロバイダープラグインが
+プロバイダー固有ロジックの大半を所有できるようになりました。

-一般的な分担:
+典型的な分担:

- `auth[].run` / `auth[].runNonInteractive`: プロバイダーが `openclaw onboard`、`openclaw models auth`、ヘッドレスセットアップ向けのオンボーディング/ログインフローを所有
- `wizard.setup` / `wizard.modelPicker`: プロバイダーが認証選択ラベル、レガシーエイリアス、オンボーディング許可リストのヒント、オンボーディング/モデルピッカー内のセットアップ項目を所有
- `catalog`: プロバイダーが `models.providers` に表示される
- `normalizeModelId`: プロバイダーがレガシー/プレビューのモデル ID を検索または正規化前に正規化
- `normalizeTransport`: プロバイダーが汎用モデル組み立て前にトランスポートファミリーの `api` / `baseUrl` を正規化し、OpenClaw はまず一致したプロバイダーを確認し、その後、実際にトランスポートを変更するまで他のフック対応プロバイダープラグインを確認します
- `normalizeConfig`: プロバイダーがランタイムで使用する前に `models.providers.<id>` 設定を正規化します。OpenClaw はまず一致したプロバイダーを確認し、その後、実際に設定を変更するまで他のフック対応プロバイダープラグインを確認します。どのプロバイダーフックも設定を書き換えない場合、バンドルされた Google ファミリーヘルパーが引き続き対応する Google プロバイダーエントリーを正規化します。
- `applyNativeStreamingUsageCompat`: プロバイダーが、設定プロバイダー向けにエンドポイント駆動のネイティブ streaming-usage 互換リライトを適用
- `resolveConfigApiKey`: プロバイダーが、設定プロバイダー向けに完全なランタイム認証読み込みを強制せず環境変数マーカー認証を解決します。`amazon-bedrock` には、Bedrock ランタイム認証が AWS SDK のデフォルトチェーンを使うにもかかわらず、ここに組み込みの AWS 環境変数マーカーリゾルバーもあります。
- `resolveSyntheticAuth`: プロバイダーが、平文シークレットを永続化せずに local/self-hosted やその他の設定ベース認証可用性を公開可能
- `shouldDeferSyntheticProfileAuth`: プロバイダーが、保存済みの synthetic profile プレースホルダーを env/config ベース認証より低い優先度として扱うよう指定可能
- `resolveDynamicModel`: プロバイダーが、まだローカル静的カタログに存在しないモデル ID を受け入れ
- `prepareDynamicModel`: プロバイダーが、動的解決の再試行前にメタデータ更新を必要とする
- `normalizeResolvedModel`: プロバイダーが、トランスポートまたはベース URL のリライトを必要とする
- `contributeResolvedModelCompat`: プロバイダーが、別の互換トランスポート経由で届いた場合でも自社ベンダーモデル向けの互換フラグを提供
- `capabilities`: プロバイダーがトランスクリプト/ツーリング/プロバイダーファミリーの癖を公開
- `normalizeToolSchemas`: プロバイダーが埋め込みランナーが見る前にツールスキーマをクリーンアップ
- `inspectToolSchemas`: プロバイダーが正規化後にトランスポート固有のスキーマ警告を公開
- `resolveReasoningOutputMode`: プロバイダーがネイティブかタグ付きかの reasoning-output 契約を選択
- `prepareExtraParams`: プロバイダーがモデルごとのリクエストパラメーターをデフォルト化または正規化
- `createStreamFn`: プロバイダーが通常のストリームパスを完全カスタムのトランスポートに置き換え
- `wrapStreamFn`: プロバイダーがリクエストヘッダー/ボディ/モデル互換ラッパーを適用
- `resolveTransportTurnState`: プロバイダーがターンごとのネイティブトランスポートヘッダーまたはメタデータを供給
- `resolveWebSocketSessionPolicy`: プロバイダーがネイティブ WebSocket セッションヘッダーまたはセッションクールダウンポリシーを供給
- `createEmbeddingProvider`: プロバイダーが、コアの embedding スイッチボードではなくプロバイダープラグイン側に属するメモリ embedding 動作を所有
- `formatApiKey`: プロバイダーが保存済み認証プロファイルを、トランスポートが期待するランタイム `apiKey` 文字列へ整形
- `refreshOAuth`: 共有の `pi-ai` リフレッシャーで十分でない場合に、プロバイダーが OAuth 更新を所有
- `buildAuthDoctorHint`: OAuth 更新失敗時に、プロバイダーが修復ガイダンスを追記
- `matchesContextOverflowError`: プロバイダーが、汎用ヒューリスティクスでは見逃すプロバイダー固有のコンテキストウィンドウ超過エラーを認識
- `classifyFailoverReason`: プロバイダーが、プロバイダー固有の生のトランスポート/API エラーを、レート制限や過負荷などのフェイルオーバー理由へマッピング
- `isCacheTtlEligible`: プロバイダーが、どの上流モデル ID がプロンプトキャッシュ TTL をサポートするかを判定
- `buildMissingAuthMessage`: プロバイダーが、汎用 auth-store エラーをプロバイダー固有の回復ヒントに置き換え
- `suppressBuiltInModel`: プロバイダーが古い上流行を非表示にし、直接解決失敗時にベンダー所有のエラーを返せる
- `augmentModelCatalog`: プロバイダーが、検出と設定マージの後に synthetic/final カタログ行を追加
- `isBinaryThinking`: プロバイダーがバイナリのオン/オフ thinking UX を所有
- `supportsXHighThinking`: プロバイダーが選択モデルを `xhigh` に対応させる
- `resolveDefaultThinkingLevel`: プロバイダーがモデルファミリー向けのデフォルト `/think` ポリシーを所有
- `applyConfigDefaults`: プロバイダーが認証モード、環境変数、またはモデルファミリーに基づき、設定マテリアライズ時にプロバイダー固有のグローバルデフォルトを適用
- `isModernModelRef`: プロバイダーが live/smoke の優先モデル一致を所有
- `prepareRuntimeAuth`: プロバイダーが設定済み資格情報を短命なランタイムトークンへ変換
- `resolveUsageAuth`: プロバイダーが `/usage` および関連するステータス/レポート画面向けの使用量/クォータ資格情報を解決
- `fetchUsageSnapshot`: プロバイダーが使用量エンドポイントの取得/解析を所有し、コアは引き続きサマリーの外枠と整形を所有
- `onModelSelected`: プロバイダーが、テレメトリーやプロバイダー所有のセッション記録管理のような選択後副作用を実行
+- `auth[].run` / `auth[].runNonInteractive`: プロバイダーが `openclaw onboard`、`openclaw models auth`、ヘッドレスセットアップ向けのオンボーディング/ログイン
+  フローを所有します
+- `wizard.setup` / `wizard.modelPicker`: プロバイダーが認証選択ラベル、
+  レガシーエイリアス、オンボーディングの許可リストヒント、およびオンボーディング/モデルピッカー内の設定項目を所有します
+- `catalog`: プロバイダーが `models.providers` に表示されます
+- `normalizeModelId`: プロバイダーが、検索または正規化の前に
+  レガシー/プレビューのモデル id を正規化します
+- `normalizeTransport`: プロバイダーが汎用モデル組み立て前に
+  トランスポートファミリーの `api` / `baseUrl` を正規化します。OpenClaw はまず一致したプロバイダーを確認し、
+  次に、実際にトランスポートを変更するものが現れるまで、他のフック対応プロバイダープラグインを確認します
+- `normalizeConfig`: プロバイダーがランタイムで使用する前に
+  `models.providers.<id>` の設定を正規化します。OpenClaw はまず一致したプロバイダーを確認し、
+  次に、実際に設定を変更するものが現れるまで、他のフック対応プロバイダープラグインを確認します。プロバイダーフックが設定を書き換えない場合でも、
+  バンドルされた Google ファミリーのヘルパーが引き続きサポート対象の Google プロバイダーエントリを
+  正規化します。
+- `applyNativeStreamingUsageCompat`: プロバイダーが設定プロバイダー向けに、エンドポイント駆動のネイティブ streaming-usage 互換書き換えを適用します
+- `resolveConfigApiKey`: プロバイダーが、完全なランタイム認証ロードを強制せずに、
+  設定プロバイダー向けの env-marker 認証を解決します。`amazon-bedrock` にもここに
+  組み込みの AWS env-marker リゾルバーがありますが、Bedrock のランタイム認証は
+  AWS SDK のデフォルトチェーンを使用します。
+- `resolveSyntheticAuth`: プロバイダーは、平文シークレットを永続化せずに
+  ローカル/セルフホスト型やその他の設定ベース認証の利用可否を公開できます
+- `shouldDeferSyntheticProfileAuth`: プロバイダーは、保存された synthetic profile
+  プレースホルダーを env/config ベース認証より低い優先順位として扱うよう指定できます
+- `resolveDynamicModel`: プロバイダーは、ローカルの
+  静的カタログにまだ存在しないモデル id を受け入れます
+- `prepareDynamicModel`: プロバイダーが動的解決を再試行する前に
+  メタデータ更新を必要とします
+- `normalizeResolvedModel`: プロバイダーがトランスポートまたは base URL の書き換えを必要とします
+- `contributeResolvedModelCompat`: プロバイダーは、そのベンダーモデルが別の互換トランスポート経由で到着した場合でも、
+  互換フラグを提供します
+- `capabilities`: プロバイダーが文字起こし/ツール/プロバイダーファミリーの癖を公開します
+- `normalizeToolSchemas`: プロバイダーが、埋め込みランナーが参照する前に
+  ツールスキーマをクリーンアップします
+- `inspectToolSchemas`: プロバイダーが、正規化後に
+  トランスポート固有のスキーマ警告を提示します
+- `resolveReasoningOutputMode`: プロバイダーがネイティブとタグ付きの
+  reasoning-output 契約を選択します
+- `prepareExtraParams`: プロバイダーがモデルごとのリクエストパラメータを
+  デフォルト化または正規化します
+- `createStreamFn`: プロバイダーが通常のストリームパスを
+  完全にカスタムなトランスポートに置き換えます
+- `wrapStreamFn`: プロバイダーがリクエストヘッダー/ボディ/モデル互換のラッパーを適用します
+- `resolveTransportTurnState`: プロバイダーがターンごとのネイティブトランスポート
+  ヘッダーまたはメタデータを提供します
+- `resolveWebSocketSessionPolicy`: プロバイダーがネイティブ WebSocket セッション
+  ヘッダーまたはセッションクールダウンポリシーを提供します
+- `createEmbeddingProvider`: プロバイダーが、コアの埋め込みスイッチボードではなく
+  プロバイダープラグイン側に属するメモリ埋め込み動作を所有します
+- `formatApiKey`: プロバイダーが、保存された認証プロファイルを
+  トランスポートが期待するランタイム `apiKey` 文字列へ整形します
+- `refreshOAuth`: 共有の `pi-ai`
+  リフレッシャーでは不十分な場合、プロバイダーが OAuth 更新を所有します
+- `buildAuthDoctorHint`: OAuth 更新が
+  失敗した際に、プロバイダーが修復ガイダンスを追加します
+- `matchesContextOverflowError`: プロバイダーが、汎用ヒューリスティックでは見逃す
+  プロバイダー固有のコンテキストウィンドウ超過エラーを認識します
+- `classifyFailoverReason`: プロバイダーが、プロバイダー固有の生のトランスポート/API
+  エラーを、レート制限や過負荷などのフェイルオーバー理由にマッピングします
+- `isCacheTtlEligible`: プロバイダーが、どの上流モデル id が prompt-cache TTL をサポートするかを判断します
+- `buildMissingAuthMessage`: プロバイダーが、汎用認証ストアエラーを
+  プロバイダー固有の復旧ヒントに置き換えます
+- `suppressBuiltInModel`: プロバイダーが古くなった上流行を非表示にし、
+  直接解決の失敗に対してベンダー所有のエラーを返せます
+- `augmentModelCatalog`: プロバイダーが、発見と設定マージ後に
+  synthetic/最終カタログ行を追加します
+- `isBinaryThinking`: プロバイダーが二値の on/off thinking UX を所有します
+- `supportsXHighThinking`: プロバイダーが、選択したモデルに `xhigh` を有効化します
+- `resolveDefaultThinkingLevel`: プロバイダーがモデルファミリー向けの
+  デフォルト `/think` ポリシーを所有します
+- `applyConfigDefaults`: プロバイダーが、認証モード、env、またはモデルファミリーに基づいて
+  設定具体化時にプロバイダー固有のグローバルデフォルトを適用します
+- `isModernModelRef`: プロバイダーが live/smoke の優先モデル照合を所有します
+- `prepareRuntimeAuth`: プロバイダーが、設定済み認証情報を
+  短命なランタイムトークンに変換します
+- `resolveUsageAuth`: プロバイダーが、`/usage`
+  および関連するステータス/レポート画面向けの使用量/クォータ認証情報を解決します
+- `fetchUsageSnapshot`: プロバイダーが使用量エンドポイントの取得/解析を所有し、
+  コアはサマリーの枠組みと整形を引き続き所有します
+- `onModelSelected`: プロバイダーが、
+  テレメトリーやプロバイダー所有のセッション管理など、選択後の副作用を実行します

 現在のバンドル例:

- `anthropic`: Claude 4.6 の前方互換フォールバック、認証修復ヒント、使用量エンドポイント取得、cache-TTL/プロバイダーファミリーメタデータ、認証対応のグローバル設定デフォルト
- `amazon-bedrock`: Bedrock 固有のスロットリング/未準備エラーに対するプロバイダー所有のコンテキスト超過一致とフェイルオーバー理由分類、および Anthropic トラフィック上の Claude 専用 replay-policy ガード向け共有 `anthropic-by-model` リプレイファミリー
- `anthropic-vertex`: Anthropic-message トラフィック上の Claude 専用 replay-policy ガード
- `openrouter`: パススルーモデル ID、リクエストラッパー、プロバイダー capability ヒント、プロキシ Gemini トラフィック上の Gemini thought-signature サニタイズ、`openrouter-thinking` ストリームファミリー経由のプロキシ reasoning 注入、ルーティングメタデータ転送、cache-TTL ポリシー
- `github-copilot`: オンボーディング/デバイスログイン、前方互換モデルフォールバック、Claude-thinking のトランスクリプトヒント、ランタイムトークン交換、使用量エンドポイント取得
- `openai`: GPT-5.4 の前方互換フォールバック、直接 OpenAI トランスポート正規化、Codex 対応の認証不足ヒント、Spark 抑制、synthetic OpenAI/Codex カタログ行、thinking/live-model ポリシー、使用量トークン別名の正規化（`input` / `output` および `prompt` / `completion` ファミリー）、ネイティブ OpenAI/Codex ラッパー向け共有 `openai-responses-defaults` ストリームファミリー、プロバイダーファミリーメタデータ、`gpt-image-1` 向けバンドル画像生成プロバイダー登録、`sora-2` 向けバンドル動画生成プロバイダー登録
- `google` と `google-gemini-cli`: Gemini 3.1 の前方互換フォールバック、ネイティブ Gemini リプレイ検証、ブートストラップリプレイのサニタイズ、タグ付き reasoning-output モード、modern-model 一致、Gemini image-preview モデル向けバンドル画像生成プロバイダー登録、Veo モデル向けバンドル動画生成プロバイダー登録。Gemini CLI OAuth はさらに、認証プロファイルのトークン整形、使用量トークン解析、使用量画面向けクォータエンドポイント取得も所有
+- `anthropic`: Claude 4.6 の前方互換フォールバック、認証修復ヒント、使用量
+  エンドポイント取得、cache-TTL/プロバイダーファミリーメタデータ、および認証対応のグローバル
+  設定デフォルト
+- `amazon-bedrock`: Bedrock 固有のスロットル/未準備エラーに対する、プロバイダー所有のコンテキスト超過判定と
+  フェイルオーバー理由分類、さらに Anthropic トラフィックに対する Claude 専用 replay-policy
+  ガード用の共有 `anthropic-by-model` リプレイファミリー
+- `anthropic-vertex`: Anthropic-message
+  トラフィックに対する Claude 専用 replay-policy ガード
+- `openrouter`: 透過的なモデル id、リクエストラッパー、プロバイダー capability
+  ヒント、プロキシ Gemini トラフィック上の Gemini thought-signature のサニタイズ、
+  `openrouter-thinking` ストリームファミリー経由のプロキシ推論注入、ルーティング
+  メタデータの転送、および cache-TTL ポリシー
+- `github-copilot`: オンボーディング/デバイスログイン、前方互換モデルフォールバック、
+  Claude-thinking 文字起こしヒント、ランタイムトークン交換、使用量エンドポイント
+  取得
+- `openai`: GPT-5.4 の前方互換フォールバック、直接 OpenAI トランスポート
+  正規化、Codex 対応の認証不足ヒント、Spark の抑制、synthetic な
+  OpenAI/Codex カタログ行、thinking/live-model ポリシー、使用量トークン別名
+  正規化（`input` / `output` および `prompt` / `completion` ファミリー）、ネイティブ OpenAI/Codex
+  ラッパー用の共有 `openai-responses-defaults` ストリームファミリー、
+  プロバイダーファミリーメタデータ、`gpt-image-1` 向けバンドル済み画像生成プロバイダー
+  登録、および `sora-2` 向けバンドル済み動画生成プロバイダー
+  登録
+- `google` および `google-gemini-cli`: Gemini 3.1 の前方互換フォールバック、
+  ネイティブ Gemini リプレイ検証、ブートストラップリプレイのサニタイズ、タグ付き
+  reasoning-output モード、modern-model 照合、Gemini image-preview モデル向け
+  バンドル済み画像生成プロバイダー登録、および
+  Veo モデル向けバンドル済み動画生成プロバイダー登録。Gemini CLI OAuth も
+  使用量画面向けの認証プロファイルトークン整形、使用量トークン解析、およびクォータエンドポイント
+  取得を所有します
 - `moonshot`: 共有トランスポート、プラグイン所有の thinking ペイロード正規化
- `kilocode`: 共有トランスポート、プラグイン所有のリクエストヘッダー、reasoning ペイロード正規化、プロキシ Gemini thought-signature サニタイズ、cache-TTL ポリシー
- `zai`: GLM-5 の前方互換フォールバック、`tool_stream` デフォルト、cache-TTL ポリシー、バイナリ thinking/live-model ポリシー、使用量認証 + クォータ取得。未知の `glm-5*` ID はバンドルされた `glm-4.7` テンプレートから合成されます
- `xai`: ネイティブ Responses トランスポート正規化、Grok 高速バリアント向け `/fast` エイリアス書き換え、デフォルト `tool_stream`、xAI 固有のツールスキーマ / reasoning ペイロードのクリーンアップ、`grok-imagine-video` 向けバンドル動画生成プロバイダー登録
+- `kilocode`: 共有トランスポート、プラグイン所有のリクエストヘッダー、reasoning ペイロード
+  正規化、プロキシ Gemini thought-signature のサニタイズ、および cache-TTL
+  ポリシー
+- `zai`: GLM-5 の前方互換フォールバック、`tool_stream` のデフォルト、cache-TTL
+  ポリシー、二値 thinking/live-model ポリシー、および使用量認証 + クォータ取得。
+  不明な `glm-5*` id は、バンドル済みの `glm-4.7` テンプレートから生成されます
+- `xai`: ネイティブ Responses トランスポート正規化、Grok fast バリアント向け
+  `/fast` エイリアス書き換え、デフォルト `tool_stream`、xAI 固有のツールスキーマ /
+  reasoning ペイロードのクリーンアップ、およびバンドル済み動画生成プロバイダー
+  `grok-imagine-video` 向け登録
 - `mistral`: プラグイン所有の capability メタデータ
- `opencode` と `opencode-go`: プラグイン所有の capability メタデータに加え、プロキシ Gemini thought-signature サニタイズ
- `alibaba`: `alibaba/wan2.6-t2v` のような直接 Wan モデル参照向けのプラグイン所有動画生成カタログ
- `byteplus`: プラグイン所有カタログに加え、Seedance テキスト動画/画像動画モデル向けバンドル動画生成プロバイダー登録
- `fal`: ホスト型サードパーティー画像モデル向けバンドル画像生成プロバイダー登録に加え、ホスト型サードパーティー動画モデル向けバンドル動画生成プロバイダー登録
+- `opencode` および `opencode-go`: プラグイン所有の capability メタデータに加え、
+  プロキシ Gemini thought-signature のサニタイズ
+- `alibaba`: `alibaba/wan2.6-t2v` のような直接 Wan モデル参照向け、
+  プラグイン所有の動画生成カタログ
+- `byteplus`: プラグイン所有のカタログに加え、Seedance の text-to-video/image-to-video モデル向け
+  バンドル済み動画生成プロバイダー
+  登録
+- `fal`: ホスト型サードパーティ向けのバンドル済み動画生成プロバイダー登録、
+  FLUX 画像モデル向けの画像生成プロバイダー登録に加え、ホスト型サードパーティ動画モデル向けの
+  バンドル済み動画生成プロバイダー登録
 - `cloudflare-ai-gateway`, `huggingface`, `kimi`, `nvidia`, `qianfan`,
  `stepfun`, `synthetic`, `venice`, `vercel-ai-gateway`, および `volcengine`:
-  プラグイン所有カタログのみ
- `qwen`: テキストモデル向けプラグイン所有カタログに加え、マルチモーダル画面向けの共有 media-understanding と動画生成プロバイダー登録。Qwen の動画生成は、`wan2.6-t2v` や `wan2.7-r2v` のようなバンドル Wan モデルを用いる Standard DashScope 動画エンドポイントを使用します
- `runway`: `gen4.5` のようなネイティブ Runway タスクベースモデル向けプラグイン所有動画生成プロバイダー登録
- `minimax`: プラグイン所有カタログ、Hailuo 動画モデル向けバンドル動画生成プロバイダー登録、`image-01` 向けバンドル画像生成プロバイダー登録、ハイブリッド Anthropic/OpenAI replay-policy 選択、使用量認証/スナップショットロジック
- `together`: プラグイン所有カタログに加え、Wan 動画モデル向けバンドル動画生成プロバイダー登録
- `xiaomi`: プラグイン所有カタログに加え、使用量認証/スナップショットロジック
+  プラグイン所有のカタログのみ
+- `qwen`: テキストモデル向けのプラグイン所有カタログに加え、
+  そのマルチモーダル画面向けの共有
+  media-understanding および動画生成プロバイダー登録。Qwen の動画生成は、
+  `wan2.6-t2v` や `wan2.7-r2v` のようなバンドル済み Wan モデルを用いた、
+  標準 DashScope 動画エンドポイントを使用します
+- `runway`: `gen4.5` のようなネイティブ
+  Runway タスクベースモデル向けのプラグイン所有動画生成プロバイダー登録
+- `minimax`: プラグイン所有のカタログ、Hailuo 動画モデル向けのバンドル済み動画生成プロバイダー
+  登録、`image-01` 向けのバンドル済み画像生成プロバイダー
+  登録、ハイブリッドな Anthropic/OpenAI replay-policy
+  選択、および使用量認証/スナップショットロジック
+- `together`: プラグイン所有のカタログに加え、Wan 動画モデル向けのバンドル済み動画生成プロバイダー
+  登録
+- `xiaomi`: プラグイン所有のカタログに加え、使用量認証/スナップショットロジック

-バンドルされた `openai` プラグインは現在、両方のプロバイダー ID を所有しています:
-`openai` と `openai-codex`。
+バンドル済みの `openai` プラグインは現在、`openai` と
+`openai-codex` の両方のプロバイダー id を所有しています。

-ここまでが、OpenClaw の通常トランスポートにまだ収まるプロバイダーです。完全にカスタムなリクエスト実行器を必要とするプロバイダーは、別のより深い拡張サーフェスになります。
+これで、OpenClaw の通常トランスポートにまだ収まるプロバイダーは網羅されます。完全にカスタムなリクエスト実行器が必要なプロバイダーは、
+別の、より深い拡張サーフェスになります。

-## API キーローテーション
+## API キーのローテーション

- 選択されたプロバイダー向けの汎用プロバイダーローテーションをサポートします。
+- 選択したプロバイダーに対する汎用プロバイダーローテーションをサポートします。
 - 複数キーの設定方法:
  - `OPENCLAW_LIVE_<PROVIDER>_KEY`（単一の live 上書き、最優先）
-  - `<PROVIDER>_API_KEYS`（カンマまたはセミコロン区切りリスト）
+  - `<PROVIDER>_API_KEYS`（カンマまたはセミコロン区切りのリスト）
  - `<PROVIDER>_API_KEY`（プライマリキー）
-  - `<PROVIDER>_API_KEY_*`（番号付きリスト、例: `<PROVIDER>_API_KEY_1`）
+  - `<PROVIDER>_API_KEY_*`（番号付きリスト。例: `<PROVIDER>_API_KEY_1`）
 - Google プロバイダーでは、フォールバックとして `GOOGLE_API_KEY` も含まれます。
- キーの選択順序は優先順位を維持し、値の重複を除去します。
- リクエストは、レート制限応答の場合にのみ次のキーで再試行されます（例: `429`、`rate_limit`、`quota`、`resource exhausted`、`Too many
-concurrent requests`、`ThrottlingException`、`concurrency limit reached`、
+- キー選択順序は優先順位を維持し、値は重複排除されます。
+- リクエストは、レート制限レスポンスの場合にのみ次のキーで再試行されます（例:
+  `429`, `rate_limit`, `quota`, `resource exhausted`, `Too many
+concurrent requests`, `ThrottlingException`, `concurrency limit reached`,
  `workers_ai ... quota limit exceeded`、または定期的な usage-limit メッセージ）。
- レート制限以外の失敗は即座に失敗し、キーローテーションは試行されません。
- すべての候補キーが失敗した場合、最後の試行での最終エラーが返されます。
+- レート制限以外の失敗は即座に失敗し、キーのローテーションは試行されません。
+- すべての候補キーが失敗した場合、最後の試行からの最終エラーが返されます。

 ## 組み込みプロバイダー（pi-ai カタログ）

 OpenClaw には pi‑ai カタログが同梱されています。これらのプロバイダーでは
-`models.providers` 設定は**不要**です。認証を設定してモデルを選ぶだけです。
+`models.providers` の設定は**不要**です。認証を設定してモデルを選ぶだけです。

 ### OpenAI

 - プロバイダー: `openai`
 - 認証: `OPENAI_API_KEY`
- オプションのローテーション: `OPENAI_API_KEYS`、`OPENAI_API_KEY_1`、`OPENAI_API_KEY_2`、および `OPENCLAW_LIVE_OPENAI_KEY`（単一上書き）
+- 任意のローテーション: `OPENAI_API_KEYS`, `OPENAI_API_KEY_1`, `OPENAI_API_KEY_2`, および `OPENCLAW_LIVE_OPENAI_KEY`（単一上書き）
 - モデル例: `openai/gpt-5.4`, `openai/gpt-5.4-pro`
 - CLI: `openclaw onboard --auth-choice openai-api-key`
- デフォルトのトランスポートは `auto`（WebSocket 優先、SSE フォールバック）
- モデルごとの上書きは `agents.defaults.models["openai/<model>"].params.transport` で行います（`"sse"`、`"websocket"`、または `"auto"`）
+- デフォルトのトランスポートは `auto` です（WebSocket 優先、SSE フォールバック）
+- モデルごとの上書きは `agents.defaults.models["openai/<model>"].params.transport` で行います（`"sse"`, `"websocket"`, または `"auto"`）
 - OpenAI Responses WebSocket ウォームアップは、`params.openaiWsWarmup`（`true`/`false`）によりデフォルトで有効です
 - OpenAI priority processing は `agents.defaults.models["openai/<model>"].params.serviceTier` で有効化できます
- `/fast` と `params.fastMode` は、直接 `openai/*` Responses リクエストを `api.openai.com` 上の `service_tier=priority` にマッピングします
- 共有 `/fast` トグルの代わりに明示的な tier を指定したい場合は `params.serviceTier` を使用します
- 非表示の OpenClaw 帰属ヘッダー（`originator`, `version`,
-  `User-Agent`）は、`api.openai.com` へのネイティブ OpenAI トラフィックにのみ適用され、
+- `/fast` と `params.fastMode` は、直接の `openai/*` Responses リクエストを `api.openai.com` 上の `service_tier=priority` にマップします
+- 共有の `/fast` トグルではなく明示的な tier を使いたい場合は、`params.serviceTier` を使用してください
+- 非表示の OpenClaw 属性ヘッダー（`originator`, `version`,
+  `User-Agent`）は、ネイティブ OpenAI トラフィックの `api.openai.com` にのみ適用され、
  汎用の OpenAI 互換プロキシには適用されません
- ネイティブ OpenAI ルートでは、Responses の `store`、プロンプトキャッシュのヒント、
-  OpenAI reasoning 互換ペイロード整形も維持されます。プロキシルートでは維持されません
+- ネイティブ OpenAI ルートでは、Responses の `store`、prompt-cache ヒント、および
+  OpenAI reasoning 互換のペイロード整形も維持されます。プロキシルートでは維持されません
 - `openai/gpt-5.3-codex-spark` は、live OpenAI API がこれを拒否するため、OpenClaw では意図的に抑制されています。Spark は Codex 専用として扱われます

 ```json5
@ -185,12 +275,12 @@ OpenClaw には pi‑ai カタログが同梱されています。これらの

 - プロバイダー: `anthropic`
 - 認証: `ANTHROPIC_API_KEY`
- オプションのローテーション: `ANTHROPIC_API_KEYS`、`ANTHROPIC_API_KEY_1`、`ANTHROPIC_API_KEY_2`、および `OPENCLAW_LIVE_ANTHROPIC_KEY`（単一上書き）
+- 任意のローテーション: `ANTHROPIC_API_KEYS`, `ANTHROPIC_API_KEY_1`, `ANTHROPIC_API_KEY_2`, および `OPENCLAW_LIVE_ANTHROPIC_KEY`（単一上書き）
 - モデル例: `anthropic/claude-opus-4-6`
 - CLI: `openclaw onboard --auth-choice apiKey`
- 直接の公開 Anthropic リクエストでは、共有 `/fast` トグルと `params.fastMode` もサポートされます。これには `api.anthropic.com` に送信される API キー認証および OAuth 認証トラフィックも含まれ、OpenClaw はこれを Anthropic の `service_tier`（`auto` 対 `standard_only`）にマッピングします
- Anthropic に関する注記: Anthropic スタッフから、OpenClaw スタイルの Claude CLI 利用は再び許可されていると伝えられたため、Anthropic が新しいポリシーを公開しない限り、OpenClaw はこの統合において Claude CLI の再利用と `claude -p` の利用を認可済みとして扱います。
- Anthropic setup-token は引き続きサポートされる OpenClaw トークン経路として利用可能ですが、OpenClaw は現在、利用可能な場合は Claude CLI の再利用と `claude -p` を優先します。
+- 直接の公開 Anthropic リクエストでは、共有の `/fast` トグルと `params.fastMode` もサポートされます。これには `api.anthropic.com` に送信される API キー認証および OAuth 認証トラフィックが含まれます。OpenClaw はこれを Anthropic の `service_tier`（`auto` と `standard_only`）にマップします
+- Anthropic 注記: Anthropic のスタッフから、OpenClaw スタイルの Claude CLI 利用は再び許可されていると伝えられたため、Anthropic が新しいポリシーを公開しない限り、OpenClaw は Claude CLI の再利用と `claude -p` の利用をこの統合において認可済みとして扱います。
+- Anthropic setup-token も引き続きサポートされる OpenClaw のトークン経路として利用可能ですが、OpenClaw は現在、利用可能であれば Claude CLI の再利用と `claude -p` を優先します。

 ```json5
 {
@ -204,15 +294,15 @@ OpenClaw には pi‑ai カタログが同梱されています。これらの
 - 認証: OAuth（ChatGPT）
 - モデル例: `openai-codex/gpt-5.4`
 - CLI: `openclaw onboard --auth-choice openai-codex` または `openclaw models auth login --provider openai-codex`
- デフォルトのトランスポートは `auto`（WebSocket 優先、SSE フォールバック）
- モデルごとの上書きは `agents.defaults.models["openai-codex/<model>"].params.transport` で行います（`"sse"`、`"websocket"`、または `"auto"`）
- `params.serviceTier` もネイティブ Codex Responses リクエスト（`chatgpt.com/backend-api`）で転送されます
- 非表示の OpenClaw 帰属ヘッダー（`originator`, `version`,
+- デフォルトのトランスポートは `auto` です（WebSocket 優先、SSE フォールバック）
+- モデルごとの上書きは `agents.defaults.models["openai-codex/<model>"].params.transport` で行います（`"sse"`, `"websocket"`, または `"auto"`）
+- `params.serviceTier` も、ネイティブ Codex Responses リクエスト（`chatgpt.com/backend-api`）で転送されます
+- 非表示の OpenClaw 属性ヘッダー（`originator`, `version`,
  `User-Agent`）は、`chatgpt.com/backend-api` へのネイティブ Codex トラフィックにのみ付与され、
  汎用の OpenAI 互換プロキシには付与されません
- 直接 `openai/*` と同じ `/fast` トグルおよび `params.fastMode` 設定を共有し、OpenClaw はこれを `service_tier=priority` にマッピングします
+- 直接の `openai/*` と同じ `/fast` トグルおよび `params.fastMode` 設定を共有し、OpenClaw はこれを `service_tier=priority` にマップします
 - `openai-codex/gpt-5.3-codex-spark` は、Codex OAuth カタログが公開している場合は引き続き利用可能です。権限依存です
- `openai-codex/gpt-5.4` はネイティブの `contextWindow = 1050000` とデフォルトのランタイム `contextTokens = 272000` を維持します。ランタイム上限は `models.providers.openai-codex.models[].contextTokens` で上書きできます
+- `openai-codex/gpt-5.4` はネイティブの `contextWindow = 1050000` と、デフォルトのランタイム `contextTokens = 272000` を維持します。ランタイム上限は `models.providers.openai-codex.models[].contextTokens` で上書きできます
 - ポリシー注記: OpenAI Codex OAuth は、OpenClaw のような外部ツール/ワークフロー向けに明示的にサポートされています。

 ```json5
@ -235,7 +325,7 @@ OpenClaw には pi‑ai カタログが同梱されています。これらの

 ### その他のサブスクリプション型ホストオプション

- [Qwen Cloud](/ja-JP/providers/qwen): Qwen Cloud プロバイダーサーフェスに加え、Alibaba DashScope および Coding Plan エンドポイントのマッピング
+- [Qwen Cloud](/ja-JP/providers/qwen): Qwen Cloud のプロバイダーサーフェスに加え、Alibaba DashScope と Coding Plan エンドポイントのマッピング
 - [MiniMax](/ja-JP/providers/minimax): MiniMax Coding Plan OAuth または API キーアクセス
 - [GLM Models](/ja-JP/providers/glm): Z.AI Coding Plan または一般 API エンドポイント

@ -257,40 +347,41 @@ OpenClaw には pi‑ai カタログが同梱されています。これらの

 - プロバイダー: `google`
 - 認証: `GEMINI_API_KEY`
- オプションのローテーション: `GEMINI_API_KEYS`、`GEMINI_API_KEY_1`、`GEMINI_API_KEY_2`、`GOOGLE_API_KEY` フォールバック、および `OPENCLAW_LIVE_GEMINI_KEY`（単一上書き）
+- 任意のローテーション: `GEMINI_API_KEYS`, `GEMINI_API_KEY_1`, `GEMINI_API_KEY_2`, `GOOGLE_API_KEY` フォールバック、および `OPENCLAW_LIVE_GEMINI_KEY`（単一上書き）
 - モデル例: `google/gemini-3.1-pro-preview`, `google/gemini-3-flash-preview`
- 互換性: `google/gemini-3.1-flash-preview` を使う従来の OpenClaw 設定は `google/gemini-3-flash-preview` に正規化されます
+- 互換性: `google/gemini-3.1-flash-preview` を使用するレガシーな OpenClaw 設定は、`google/gemini-3-flash-preview` に正規化されます
 - CLI: `openclaw onboard --auth-choice gemini-api-key`
- 直接 Gemini 実行では `agents.defaults.models["google/<model>"].params.cachedContent`
-  （または従来の `cached_content`）も受け付け、
-  プロバイダーネイティブの `cachedContents/...` ハンドルを転送します。Gemini のキャッシュヒットは OpenClaw の `cacheRead` として表示されます
+- 直接の Gemini 実行では、`agents.defaults.models["google/<model>"].params.cachedContent`
+  （またはレガシーな `cached_content`）も受け付け、
+  プロバイダーネイティブの `cachedContents/...` ハンドルを転送します。
+  Gemini のキャッシュヒットは OpenClaw の `cacheRead` として表示されます

 ### Google Vertex と Gemini CLI

 - プロバイダー: `google-vertex`, `google-gemini-cli`
- 認証: Vertex は gcloud ADC を使用、Gemini CLI は独自の OAuth フローを使用
- 注意: OpenClaw における Gemini CLI OAuth は非公式統合です。サードパーティークライアントの使用後に Google アカウントの制限が報告された例があります。利用する場合は Google の利用規約を確認し、重要でないアカウントを使ってください。
- Gemini CLI OAuth は、バンドルされた `google` プラグインの一部として提供されます。
+- 認証: Vertex は gcloud ADC を使用し、Gemini CLI は自身の OAuth フローを使用します
+- 注意: OpenClaw における Gemini CLI OAuth は非公式な統合です。サードパーティクライアント利用後に Google アカウントの制限が発生したという報告もあります。利用する場合は Google の規約を確認し、重要でないアカウントを使用してください。
+- Gemini CLI OAuth は、バンドル済みの `google` プラグインの一部として提供されます。
  - まず Gemini CLI をインストールします:
    - `brew install gemini-cli`
    - または `npm install -g @google/gemini-cli`
  - 有効化: `openclaw plugins enable google`
  - ログイン: `openclaw models auth login --provider google-gemini-cli --set-default`
  - デフォルトモデル: `google-gemini-cli/gemini-3-flash-preview`
-  - 注: `openclaw.json` に client id や secret を貼り付ける必要は**ありません**。CLI ログインフローは
+  - 注: `openclaw.json` に client id や secret を貼り付ける必要は**ありません**。CLI のログインフローは
    トークンを Gateway ホスト上の認証プロファイルに保存します。
  - ログイン後にリクエストが失敗する場合は、Gateway ホストで `GOOGLE_CLOUD_PROJECT` または `GOOGLE_CLOUD_PROJECT_ID` を設定してください。
  - Gemini CLI の JSON 応答は `response` から解析され、使用量は
-    `stats` にフォールバックします。`stats.cached` は OpenClaw の `cacheRead` に正規化されます。
+    `stats` にフォールバックされます。`stats.cached` は OpenClaw の `cacheRead` に正規化されます。

 ### Z.AI（GLM）

 - プロバイダー: `zai`
 - 認証: `ZAI_API_KEY`
- モデル例: `zai/glm-5`
+- モデル例: `zai/glm-5.1`
 - CLI: `openclaw onboard --auth-choice zai-api-key`
  - エイリアス: `z.ai/*` と `z-ai/*` は `zai/*` に正規化されます
-  - `zai-api-key` は一致する Z.AI エンドポイントを自動検出します。`zai-coding-global`、`zai-coding-cn`、`zai-global`、`zai-cn` は特定のサーフェスを強制します
+  - `zai-api-key` は一致する Z.AI エンドポイントを自動検出します。`zai-coding-global`, `zai-coding-cn`, `zai-global`, `zai-cn` は特定のサーフェスを強制します

 ### Vercel AI Gateway

@ -307,86 +398,91 @@ OpenClaw には pi‑ai カタログが同梱されています。これらの
 - CLI: `openclaw onboard --auth-choice kilocode-api-key`
 - ベース URL: `https://api.kilo.ai/api/gateway/`
 - 静的フォールバックカタログには `kilocode/kilo/auto` が同梱されており、
-  live の `https://api.kilo.ai/api/gateway/models` 検出によりランタイム
-  カタログをさらに拡張できます。
+  live の `https://api.kilo.ai/api/gateway/models` 検出によって
+  ランタイムカタログがさらに拡張される場合があります。
 - `kilocode/kilo/auto` の背後にある正確な上流ルーティングは Kilo Gateway が所有しており、
-  OpenClaw にハードコードされていません。
+  OpenClaw にはハードコードされていません。

 セットアップの詳細は [/providers/kilocode](/ja-JP/providers/kilocode) を参照してください。

 ### その他のバンドル済みプロバイダープラグイン

- OpenRouter: `openrouter` (`OPENROUTER_API_KEY`)
+- OpenRouter: `openrouter`（`OPENROUTER_API_KEY`）
 - モデル例: `openrouter/auto`
- OpenClaw は、リクエストが実際に `openrouter.ai` を対象としている場合にのみ、
-  OpenRouter の文書化されたアプリ帰属ヘッダーを適用します
+- OpenClaw は、リクエストの実際の送信先が `openrouter.ai` の場合にのみ、
+  OpenRouter の文書化されたアプリ属性ヘッダーを適用します
 - OpenRouter 固有の Anthropic `cache_control` マーカーも同様に、
-  任意のプロキシ URL ではなく、検証済み OpenRouter ルートにのみ適用されます
- OpenRouter は引き続きプロキシ型の OpenAI 互換パス上にあるため、
-  ネイティブ OpenAI 専用のリクエスト整形（`serviceTier`、Responses `store`、
-  プロンプトキャッシュヒント、OpenAI reasoning 互換ペイロード）は転送されません
- Gemini ベースの OpenRouter 参照では、プロキシ Gemini thought-signature サニタイズのみ維持されます。ネイティブ Gemini リプレイ検証とブートストラップ書き換えは無効のままです
- Kilo Gateway: `kilocode` (`KILOCODE_API_KEY`)
+  任意のプロキシ URL ではなく検証済みの OpenRouter ルートに対してのみ有効です
+- OpenRouter は引き続きプロキシ型の OpenAI 互換パス上にあるため、ネイティブ OpenAI 専用のリクエスト整形（`serviceTier`、Responses の `store`、
+  prompt-cache ヒント、OpenAI reasoning 互換ペイロード）は転送されません
+- Gemini ベースの OpenRouter 参照では、プロキシ Gemini thought-signature のサニタイズのみが維持されます。
+  ネイティブ Gemini のリプレイ検証とブートストラップ書き換えは無効のままです
+- Kilo Gateway: `kilocode`（`KILOCODE_API_KEY`）
 - モデル例: `kilocode/kilo/auto`
- Gemini ベースの Kilo 参照では同じプロキシ Gemini thought-signature
-  サニタイズ経路が維持されます。`kilocode/kilo/auto` やその他の proxy-reasoning 非対応ヒントでは、プロキシ reasoning 注入をスキップします
+- Gemini ベースの Kilo 参照でも、同じプロキシ Gemini thought-signature
+  サニタイズパスが維持されます。`kilocode/kilo/auto` やその他のプロキシ推論非対応
+  ヒントでは、プロキシ推論注入はスキップされます
 - MiniMax: `minimax`（API キー）および `minimax-portal`（OAuth）
 - 認証: `minimax` には `MINIMAX_API_KEY`、`minimax-portal` には `MINIMAX_OAUTH_TOKEN` または `MINIMAX_API_KEY`
 - モデル例: `minimax/MiniMax-M2.7` または `minimax-portal/MiniMax-M2.7`
- MiniMax のオンボーディング/API キー設定では、`input: ["text", "image"]` を持つ明示的な M2.7 モデル定義を書き込みます。バンドルされたプロバイダーカタログでは、そのプロバイダー設定がマテリアライズされるまではチャット参照を text-only のままにします
- Moonshot: `moonshot` (`MOONSHOT_API_KEY`)
+- MiniMax のオンボーディング/API キー設定では、
+  `input: ["text", "image"]` を持つ明示的な M2.7 モデル定義が書き込まれます。バンドル済みプロバイダーカタログでは、
+  そのプロバイダー設定が具体化されるまで、チャット参照は
+  テキスト専用のままです
+- Moonshot: `moonshot`（`MOONSHOT_API_KEY`）
 - モデル例: `moonshot/kimi-k2.5`
- Kimi Coding: `kimi` (`KIMI_API_KEY` または `KIMICODE_API_KEY`)
+- Kimi Coding: `kimi`（`KIMI_API_KEY` または `KIMICODE_API_KEY`）
 - モデル例: `kimi/kimi-code`
- Qianfan: `qianfan` (`QIANFAN_API_KEY`)
+- Qianfan: `qianfan`（`QIANFAN_API_KEY`）
 - モデル例: `qianfan/deepseek-v3.2`
- Qwen Cloud: `qwen` (`QWEN_API_KEY`, `MODELSTUDIO_API_KEY`, または `DASHSCOPE_API_KEY`)
+- Qwen Cloud: `qwen`（`QWEN_API_KEY`, `MODELSTUDIO_API_KEY`, または `DASHSCOPE_API_KEY`）
 - モデル例: `qwen/qwen3.5-plus`
- NVIDIA: `nvidia` (`NVIDIA_API_KEY`)
+- NVIDIA: `nvidia`（`NVIDIA_API_KEY`）
 - モデル例: `nvidia/nvidia/llama-3.1-nemotron-70b-instruct`
- StepFun: `stepfun` / `stepfun-plan` (`STEPFUN_API_KEY`)
+- StepFun: `stepfun` / `stepfun-plan`（`STEPFUN_API_KEY`）
 - モデル例: `stepfun/step-3.5-flash`, `stepfun-plan/step-3.5-flash-2603`
- Together: `together` (`TOGETHER_API_KEY`)
+- Together: `together`（`TOGETHER_API_KEY`）
 - モデル例: `together/moonshotai/Kimi-K2.5`
- Venice: `venice` (`VENICE_API_KEY`)
- Xiaomi: `xiaomi` (`XIAOMI_API_KEY`)
+- Venice: `venice`（`VENICE_API_KEY`）
+- Xiaomi: `xiaomi`（`XIAOMI_API_KEY`）
 - モデル例: `xiaomi/mimo-v2-flash`
- Vercel AI Gateway: `vercel-ai-gateway` (`AI_GATEWAY_API_KEY`)
- Hugging Face Inference: `huggingface` (`HUGGINGFACE_HUB_TOKEN` または `HF_TOKEN`)
- Cloudflare AI Gateway: `cloudflare-ai-gateway` (`CLOUDFLARE_AI_GATEWAY_API_KEY`)
- Volcengine: `volcengine` (`VOLCANO_ENGINE_API_KEY`)
+- Vercel AI Gateway: `vercel-ai-gateway`（`AI_GATEWAY_API_KEY`）
+- Hugging Face Inference: `huggingface`（`HUGGINGFACE_HUB_TOKEN` または `HF_TOKEN`）
+- Cloudflare AI Gateway: `cloudflare-ai-gateway`（`CLOUDFLARE_AI_GATEWAY_API_KEY`）
+- Volcengine: `volcengine`（`VOLCANO_ENGINE_API_KEY`）
 - モデル例: `volcengine-plan/ark-code-latest`
- BytePlus: `byteplus` (`BYTEPLUS_API_KEY`)
+- BytePlus: `byteplus`（`BYTEPLUS_API_KEY`）
 - モデル例: `byteplus-plan/ark-code-latest`
- xAI: `xai` (`XAI_API_KEY`)
-  - ネイティブにバンドルされた xAI リクエストは xAI Responses パスを使用します
-  - `/fast` または `params.fastMode: true` は `grok-3`, `grok-3-mini`,
-    `grok-4`, `grok-4-0709` をそれぞれの `*-fast` バリアントに書き換えます
-  - `tool_stream` はデフォルトで有効です。
-    `agents.defaults.models["xai/<model>"].params.tool_stream` を `false` に設定して
-    無効化できます
- Mistral: `mistral` (`MISTRAL_API_KEY`)
+- xAI: `xai`（`XAI_API_KEY`）
+  - ネイティブのバンドル済み xAI リクエストでは、xAI Responses パスを使用します
+  - `/fast` または `params.fastMode: true` は、`grok-3`, `grok-3-mini`,
+    `grok-4`, および `grok-4-0709` をそれぞれの `*-fast` バリアントに
+    書き換えます
+  - `tool_stream` はデフォルトで有効です。無効にするには、
+    `agents.defaults.models["xai/<model>"].params.tool_stream` を `false` に設定してください
+- Mistral: `mistral`（`MISTRAL_API_KEY`）
 - モデル例: `mistral/mistral-large-latest`
 - CLI: `openclaw onboard --auth-choice mistral-api-key`
- Groq: `groq` (`GROQ_API_KEY`)
- Cerebras: `cerebras` (`CEREBRAS_API_KEY`)
-  - Cerebras 上の GLM モデルは `zai-glm-4.7` および `zai-glm-4.6` の ID を使用します。
-  - OpenAI 互換ベース URL: `https://api.cerebras.ai/v1`。
- GitHub Copilot: `github-copilot` (`COPILOT_GITHUB_TOKEN` / `GH_TOKEN` / `GITHUB_TOKEN`)
- Hugging Face Inference のモデル例: `huggingface/deepseek-ai/DeepSeek-R1`。CLI: `openclaw onboard --auth-choice huggingface-api-key`。詳細は [Hugging Face (Inference)](/ja-JP/providers/huggingface) を参照してください。
+- Groq: `groq`（`GROQ_API_KEY`）
+- Cerebras: `cerebras`（`CEREBRAS_API_KEY`）
+  - Cerebras 上の GLM モデルは `zai-glm-4.7` および `zai-glm-4.6` という id を使用します。
+  - OpenAI 互換の base URL: `https://api.cerebras.ai/v1`
+- GitHub Copilot: `github-copilot`（`COPILOT_GITHUB_TOKEN` / `GH_TOKEN` / `GITHUB_TOKEN`）
+- Hugging Face Inference のモデル例: `huggingface/deepseek-ai/DeepSeek-R1`; CLI: `openclaw onboard --auth-choice huggingface-api-key`。 [Hugging Face (Inference)](/ja-JP/providers/huggingface) を参照してください。

-## `models.providers` 経由のプロバイダー（カスタム/ベース URL）
+## `models.providers` 経由のプロバイダー（カスタム/base URL）

-`models.providers`（または `models.json`）を使用して、**カスタム**プロバイダーまたは
-OpenAI/Anthropic 互換プロキシを追加します。
+`models.providers`（または `models.json`）を使うと、**カスタム**プロバイダーや
+OpenAI/Anthropic 互換プロキシを追加できます。

 以下のバンドル済みプロバイダープラグインの多くは、すでにデフォルトカタログを公開しています。
-デフォルトのベース URL、ヘッダー、モデル一覧を上書きしたい場合にのみ、明示的な `models.providers.<id>` エントリーを使用してください。
+デフォルトの base URL、ヘッダー、またはモデル一覧を上書きしたい場合にのみ、
+明示的な `models.providers.<id>` エントリを使用してください。

 ### Moonshot AI（Kimi）

-Moonshot はバンドル済みプロバイダープラグインとして提供されます。
-通常は組み込みプロバイダーを使い、ベース URL やモデルメタデータを上書きする必要がある場合にのみ、明示的な `models.providers.moonshot` エントリーを追加してください。
+Moonshot はバンドル済みプロバイダープラグインとして提供されています。デフォルトでは組み込みプロバイダーを使用し、
+base URL またはモデルメタデータを上書きしたい場合にのみ、明示的な `models.providers.moonshot` エントリを追加してください。

 - プロバイダー: `moonshot`
 - 認証: `MOONSHOT_API_KEY`
@ -440,13 +536,13 @@ Kimi Coding は Moonshot AI の Anthropic 互換エンドポイントを使用
 }
 ```

-従来の `kimi/k2p5` も互換モデル ID として引き続き受け付けられます。
+レガシーな `kimi/k2p5` も互換モデル id として引き続き受け付けられます。

 ### Volcano Engine（Doubao）

-Volcano Engine（火山引擎）は、中国で Doubao やその他のモデルへのアクセスを提供します。
+Volcano Engine（火山引擎）は、中国国内で Doubao などのモデルへのアクセスを提供します。

- プロバイダー: `volcengine`（コーディング: `volcengine-plan`）
+- プロバイダー: `volcengine`（coding: `volcengine-plan`）
 - 認証: `VOLCANO_ENGINE_API_KEY`
 - モデル例: `volcengine-plan/ark-code-latest`
 - CLI: `openclaw onboard --auth-choice volcengine-api-key`
@ -459,22 +555,23 @@ Volcano Engine（火山引擎）は、中国で Doubao やその他のモデル
 }
 ```

-オンボーディングはデフォルトでコーディングサーフェスを使用しますが、一般的な `volcengine/*`
+オンボーディングでは coding サーフェスがデフォルトですが、一般的な `volcengine/*`
 カタログも同時に登録されます。

 オンボーディング/モデル設定ピッカーでは、Volcengine の認証選択は
 `volcengine/*` と `volcengine-plan/*` の両方の行を優先します。これらのモデルがまだ読み込まれていない場合、
-OpenClaw は空のプロバイダースコープピッカーを表示する代わりに、フィルターなしカタログへフォールバックします。
+OpenClaw は空のプロバイダー限定ピッカーを表示する代わりに、
+フィルタなしカタログへフォールバックします。

 利用可能なモデル:

- `volcengine/doubao-seed-1-8-251228` (Doubao Seed 1.8)
+- `volcengine/doubao-seed-1-8-251228`（Doubao Seed 1.8）
 - `volcengine/doubao-seed-code-preview-251028`
- `volcengine/kimi-k2-5-260127` (Kimi K2.5)
- `volcengine/glm-4-7-251222` (GLM 4.7)
- `volcengine/deepseek-v3-2-251201` (DeepSeek V3.2 128K)
+- `volcengine/kimi-k2-5-260127`（Kimi K2.5）
+- `volcengine/glm-4-7-251222`（GLM 4.7）
+- `volcengine/deepseek-v3-2-251201`（DeepSeek V3.2 128K）

-コーディングモデル（`volcengine-plan`）:
+Coding モデル（`volcengine-plan`）:

 - `volcengine-plan/ark-code-latest`
 - `volcengine-plan/doubao-seed-code`
@ -482,11 +579,11 @@ OpenClaw は空のプロバイダースコープピッカーを表示する代
 - `volcengine-plan/kimi-k2-thinking`
 - `volcengine-plan/glm-4.7`

-### BytePlus（国際版）
+### BytePlus（International）

 BytePlus ARK は、国際ユーザー向けに Volcano Engine と同じモデルへのアクセスを提供します。

- プロバイダー: `byteplus`（コーディング: `byteplus-plan`）
+- プロバイダー: `byteplus`（coding: `byteplus-plan`）
 - 認証: `BYTEPLUS_API_KEY`
 - モデル例: `byteplus-plan/ark-code-latest`
 - CLI: `openclaw onboard --auth-choice byteplus-api-key`
@ -499,20 +596,21 @@ BytePlus ARK は、国際ユーザー向けに Volcano Engine と同じモデル
 }
 ```

-オンボーディングはデフォルトでコーディングサーフェスを使用しますが、一般的な `byteplus/*`
+オンボーディングでは coding サーフェスがデフォルトですが、一般的な `byteplus/*`
 カタログも同時に登録されます。

 オンボーディング/モデル設定ピッカーでは、BytePlus の認証選択は
 `byteplus/*` と `byteplus-plan/*` の両方の行を優先します。これらのモデルがまだ読み込まれていない場合、
-OpenClaw は空のプロバイダースコープピッカーを表示する代わりに、フィルターなしカタログへフォールバックします。
+OpenClaw は空のプロバイダー限定ピッカーを表示する代わりに、
+フィルタなしカタログへフォールバックします。

 利用可能なモデル:

- `byteplus/seed-1-8-251228` (Seed 1.8)
- `byteplus/kimi-k2-5-260127` (Kimi K2.5)
- `byteplus/glm-4-7-251222` (GLM 4.7)
+- `byteplus/seed-1-8-251228`（Seed 1.8）
+- `byteplus/kimi-k2-5-260127`（Kimi K2.5）
+- `byteplus/glm-4-7-251222`（GLM 4.7）

-コーディングモデル（`byteplus-plan`）:
+Coding モデル（`byteplus-plan`）:

 - `byteplus-plan/ark-code-latest`
 - `byteplus-plan/doubao-seed-code`
@ -522,7 +620,7 @@ OpenClaw は空のプロバイダースコープピッカーを表示する代

 ### Synthetic

-Synthetic は、`synthetic` プロバイダーの背後で Anthropic 互換モデルを提供します。
+Synthetic は `synthetic` プロバイダーの背後で Anthropic 互換モデルを提供します。

 - プロバイダー: `synthetic`
 - 認証: `SYNTHETIC_API_KEY`
@ -550,7 +648,7 @@ Synthetic は、`synthetic` プロバイダーの背後で Anthropic 互換モ

 ### MiniMax

-MiniMax はカスタムエンドポイントを使用するため、`models.providers` 経由で設定します。
+MiniMax はカスタムエンドポイントを使用するため、`models.providers` で設定されます。

 - MiniMax OAuth（Global）: `--auth-choice minimax-global-oauth`
 - MiniMax OAuth（CN）: `--auth-choice minimax-cn-oauth`
@ -561,16 +659,16 @@ MiniMax はカスタムエンドポイントを使用するため、`models.prov

 セットアップの詳細、モデルオプション、設定スニペットについては [/providers/minimax](/ja-JP/providers/minimax) を参照してください。

-MiniMax の Anthropic 互換ストリーミングパスでは、明示的に設定しない限り OpenClaw は thinking を
-デフォルトで無効にし、`/fast on` は
+MiniMax の Anthropic 互換ストリーミングパスでは、OpenClaw は
+明示的に設定しない限り thinking をデフォルトで無効化し、`/fast on` は
 `MiniMax-M2.7` を `MiniMax-M2.7-highspeed` に書き換えます。

 プラグイン所有の capability 分担:

- テキスト/チャットのデフォルトは `minimax/MiniMax-M2.7` のまま
- 画像生成は `minimax/image-01` または `minimax-portal/image-01`
- 画像理解は、両方の MiniMax 認証パスでプラグイン所有の `MiniMax-VL-01`
- Web 検索は引き続きプロバイダー ID `minimax`
+- テキスト/チャットのデフォルトは `minimax/MiniMax-M2.7` のままです
+- 画像生成は `minimax/image-01` または `minimax-portal/image-01` です
+- 画像理解は、両方の MiniMax 認証パスでプラグイン所有の `MiniMax-VL-01` です
+- Web 検索はプロバイダー id `minimax` のままです

 ### Ollama

@ -582,7 +680,7 @@ Ollama はバンドル済みプロバイダープラグインとして提供さ
 - インストール: [https://ollama.com/download](https://ollama.com/download)

 ```bash
-# Ollama をインストールし、その後モデルを pull します:
+# Ollama をインストールしてから、モデルを pull します:
 ollama pull llama3.3
 ```

@ -594,27 +692,27 @@ ollama pull llama3.3
 }
 ```

-Ollama は `OLLAMA_API_KEY` でオプトインするとローカルの `http://127.0.0.1:11434` で検出され、
-バンドルされたプロバイダープラグインが Ollama を直接
-`openclaw onboard` とモデルピッカーに追加します。オンボーディング、cloud/local モード、カスタム設定については [/providers/ollama](/ja-JP/providers/ollama)
+Ollama は、`OLLAMA_API_KEY` でオプトインしたときに
+`http://127.0.0.1:11434` でローカル検出され、バンドル済みプロバイダープラグインは Ollama を直接
+`openclaw onboard` とモデルピッカーに追加します。オンボーディング、クラウド/ローカルモード、カスタム設定については [/providers/ollama](/ja-JP/providers/ollama)
 を参照してください。

 ### vLLM

-vLLM は、local/self-hosted な OpenAI 互換
-サーバー向けのバンドル済みプロバイダープラグインとして提供されます。
+vLLM は、ローカル/セルフホスト型の OpenAI 互換
+サーバー向けバンドル済みプロバイダープラグインとして提供されています。

 - プロバイダー: `vllm`
- 認証: オプション（サーバー依存）
- デフォルトベース URL: `http://127.0.0.1:8000/v1`
+- 認証: 任意（サーバー構成による）
+- デフォルトの base URL: `http://127.0.0.1:8000/v1`

-ローカルで自動検出にオプトインするには（サーバーが認証を強制しない場合、任意の値で動作します）:
+ローカルで自動検出を有効化するには（サーバーが認証を強制しない場合は任意の値で動作します）:

 ```bash
 export VLLM_API_KEY="vllm-local"
 ```

-その後、モデルを設定します（`/v1/models` が返す ID のいずれかに置き換えてください）:
+次にモデルを設定します（`/v1/models` が返す ID のいずれかに置き換えてください）:

 ```json5
 {
@ -628,21 +726,21 @@ export VLLM_API_KEY="vllm-local"

 ### SGLang

-SGLang は、高速な self-hosted
-OpenAI 互換サーバー向けのバンドル済みプロバイダープラグインとして提供されます。
+SGLang は、高速なセルフホスト型
+OpenAI 互換サーバー向けバンドル済みプロバイダープラグインとして提供されています。

 - プロバイダー: `sglang`
- 認証: オプション（サーバー依存）
- デフォルトベース URL: `http://127.0.0.1:30000/v1`
+- 認証: 任意（サーバー構成による）
+- デフォルトの base URL: `http://127.0.0.1:30000/v1`

-ローカルで自動検出にオプトインするには（サーバーが
-認証を強制しない場合、任意の値で動作します）:
+ローカルで自動検出を有効化するには（サーバーが
+認証を強制しない場合は任意の値で動作します）:

 ```bash
 export SGLANG_API_KEY="sglang-local"
 ```

-その後、モデルを設定します（`/v1/models` が返す ID のいずれかに置き換えてください）:
+次にモデルを設定します（`/v1/models` が返す ID のいずれかに置き換えてください）:

 ```json5
 {
@ -691,7 +789,7 @@ export SGLANG_API_KEY="sglang-local"

 注:

- カスタムプロバイダーでは、`reasoning`、`input`、`cost`、`contextWindow`、`maxTokens` は省略可能です。
+- カスタムプロバイダーでは、`reasoning`, `input`, `cost`, `contextWindow`, `maxTokens` は任意です。
  省略した場合、OpenClaw のデフォルトは次のとおりです:
  - `reasoning: false`
  - `input: ["text"]`
@ -699,15 +797,17 @@ export SGLANG_API_KEY="sglang-local"
  - `contextWindow: 200000`
  - `maxTokens: 8192`
 - 推奨: プロキシ/モデルの制限に一致する明示的な値を設定してください。
- ネイティブでないエンドポイントに対する `api: "openai-completions"` では（ホストが `api.openai.com` ではない任意の非空 `baseUrl`）、OpenClaw は、未対応の `developer` ロールによるプロバイダー 400 エラーを回避するため、`compat.supportsDeveloperRole: false` を強制します。
- プロキシ型の OpenAI 互換ルートでも、ネイティブ OpenAI 専用のリクエスト整形はスキップされます:
-  `service_tier` なし、Responses `store` なし、プロンプトキャッシュヒントなし、
-  OpenAI reasoning 互換ペイロード整形なし、非表示の OpenClaw 帰属
-  ヘッダーなし。
+- ネイティブでないエンドポイント上の `api: "openai-completions"`（`api.openai.com` ではないホストを持つ、空でない `baseUrl`）では、OpenClaw は
+  サポートされない `developer` ロールによるプロバイダー 400 エラーを避けるため、
+  `compat.supportsDeveloperRole: false` を強制します。
+- プロキシ型の OpenAI 互換ルートでは、ネイティブ OpenAI 専用のリクエスト
+  整形もスキップされます。`service_tier` なし、Responses の `store` なし、prompt-cache ヒントなし、
+  OpenAI reasoning 互換ペイロード整形なし、非表示の OpenClaw 属性
+  ヘッダーなしです。
 - `baseUrl` が空または省略されている場合、OpenClaw はデフォルトの OpenAI 動作（`api.openai.com` に解決される）を維持します。
 - 安全のため、ネイティブでない `openai-completions` エンドポイントでは、明示的な `compat.supportsDeveloperRole: true` も引き続き上書きされます。

-## CLI の例
+## CLI 例

 ```bash
 openclaw onboard --auth-choice opencode-zen
--- a/docs/ja-JP/concepts/qa-e2e-automation.md
+++ b/docs/ja-JP/concepts/qa-e2e-automation.md
@ -1,51 +1,52 @@
 ---
 read_when:
-    - qa-labまたはqa-channelを拡張する場合
-    - リポジトリに裏付けられたQAシナリオを追加する場合
-    - Gatewayダッシュボード周辺で、より現実に近いQA自動化を構築する場合
+    - qa-lab または qa-channel を拡張する場合
+    - リポジトリに基づくQAシナリオを追加する場合
+    - Gateway ダッシュボードを中心に、より現実的なQA自動化を構築する場合
 summary: qa-lab、qa-channel、シード済みシナリオ、プロトコルレポート向けのプライベートQA自動化の構成
-title: QA E2E自動化
+title: QA E2E 自動化
 x-i18n:
-    generated_at: "2026-04-08T02:13:58Z"
+    generated_at: "2026-04-08T04:41:52Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 3b4aa5acc8e77303f4045d4f04372494cae21b89d2fdaba856dbb4855ced9d27
+    source_hash: 57da147dc06abf9620290104e01a83b42182db1806514114fd9e8467492cda99
    source_path: concepts/qa-e2e-automation.md
    workflow: 15
 ---

-# QA E2E自動化
+# QA E2E 自動化

-プライベートQAスタックは、単一のユニットテストよりも、より現実的で
-チャネルに近い形でOpenClawを検証することを目的としています。
+プライベートQAスタックは、単一のユニットテストよりも、
+より現実的でチャネルの形に沿った方法でOpenClawを検証することを目的としています。

 現在の構成要素:

 - `extensions/qa-channel`: DM、channel、thread、
-  reaction、edit、deleteの各操作面を備えた合成メッセージチャネル。
- `extensions/qa-lab`: トランスクリプトの観察、
-  受信メッセージの注入、Markdownレポートのエクスポートを行うためのデバッガーUIとQAバス。
- `qa/`: キックオフタスクとベースラインQA
-  シナリオ向けの、リポジトリに裏付けられたシードアセット。
+  reaction、edit、delete の各操作面を備えた合成メッセージチャネル。
+- `extensions/qa-lab`: トランスクリプトを観察し、
+  受信メッセージを注入し、Markdownレポートをエクスポートするための
+  デバッガーUIとQAバス。
+- `qa/`: キックオフタスクおよびベースラインQA
+  シナリオ向けの、リポジトリに基づくシードアセット。

-現在のQAオペレーターのフローは、2ペインのQAサイトです:
+現在のQAオペレーターフローは2ペインのQAサイトです:

- 左: エージェントを備えたGatewayダッシュボード（Control UI）。
+- 左: エージェント付きのGateway ダッシュボード（Control UI）。
 - 右: Slack風のトランスクリプトとシナリオ計画を表示するQA Lab。

-次のコマンドで実行します:
+実行方法:

 ```bash
 pnpm qa:lab:up
 ```

-これによりQAサイトがビルドされ、DockerベースのGatewayレーンが起動し、
-オペレーターまたは自動化ループがエージェントにQA
-ミッションを与え、実際のチャネル動作を観察し、成功したこと、失敗したこと、
-またはブロックされたままのことを記録できるQA Labページが公開されます。
+これによりQAサイトがビルドされ、Dockerベースのgatewayレーンが起動し、
+オペレーターまたは自動化ループがエージェントにQAミッションを与え、
+実際のチャネル動作を観察し、何が機能し、何が失敗し、あるいは
+何がブロックされたままだったかを記録できるQA Labページが公開されます。

-Dockerイメージを毎回再ビルドせずにQA Lab UIをより高速に反復するには、
-bind mountしたQA Labバンドルでスタックを起動します:
+Dockerイメージを毎回再ビルドせずに、より高速にQA Lab UIを反復開発するには、
+bind mountされたQA Labバンドルでスタックを起動します:

 ```bash
 pnpm openclaw qa docker-build-image
@ -54,43 +55,44 @@ pnpm qa:lab:up:fast
 pnpm qa:lab:watch
 ```

-`qa:lab:up:fast` は、事前ビルド済みイメージ上でDockerサービスを維持しつつ、
+`qa:lab:up:fast` は、Dockerサービスを事前ビルド済みイメージで維持しつつ、
 `extensions/qa-lab/web/dist` を `qa-lab` コンテナにbind mountします。`qa:lab:watch`
 は変更時にそのバンドルを再ビルドし、QA Labアセットのハッシュが変わると
-ブラウザは自動的にリロードされます。
+ブラウザは自動的に再読み込みされます。

-## リポジトリに裏付けられたシード
+## リポジトリに基づくシード

 シードアセットは `qa/` にあります:

- `qa/scenarios.md`
+- `qa/scenarios/index.md`
+- `qa/scenarios/*.md`

-これらは、QA計画が人間と
-エージェントの両方から見えるように、意図的にgitに置かれています。
-ベースラインの一覧は、次をカバーできる程度に十分広く保つ必要があります:
+これらは意図的にgitに含められており、人間と
+エージェントの両方がQA計画を確認できます。ベースライン一覧は、少なくとも次を
+カバーできるよう十分に広く保つ必要があります:

- DMとchannelチャット
- threadの動作
+- DM と channel のチャット
+- thread の動作
 - メッセージアクションのライフサイクル
- cronコールバック
- メモリの再呼び出し
- モデル切り替え
+- cron コールバック
+- メモリの想起
+- モデルの切り替え
 - サブエージェントへの引き継ぎ
- リポジトリ読み取りとドキュメント読み取り
- Lobster Invadersのような小さなビルドタスクを1つ
+- リポジトリの読み取りとドキュメントの読み取り
+- Lobster Invaders のような小規模なビルドタスク1件

 ## レポート

-`qa-lab` は、観測されたバスタイムラインからMarkdownのプロトコルレポートをエクスポートします。
-レポートは次の問いに答える必要があります:
+`qa-lab` は、観察されたバスタイムラインからMarkdownのプロトコルレポートをエクスポートします。
+レポートでは次に答える必要があります:

- 何がうまく動作したか
+- 何が機能したか
 - 何が失敗したか
 - 何がブロックされたままだったか
 - どのフォローアップシナリオを追加する価値があるか

 ## 関連ドキュメント

- [Testing](/ja-JP/help/testing)
- [QA Channel](/ja-JP/channels/qa-channel)
- [Dashboard](/web/dashboard)
+- [テスト](/ja-JP/help/testing)
+- [QAチャネル](/ja-JP/channels/qa-channel)
+- [ダッシュボード](/web/dashboard)
--- a/docs/ja-JP/gateway/configuration-reference.md
+++ b/docs/ja-JP/gateway/configuration-reference.md
--- a/docs/ja-JP/plugins/memory-wiki.md
+++ b/docs/ja-JP/plugins/memory-wiki.md
@ -0,0 +1,343 @@
+---
+read_when:
+    - 単なる MEMORY.md ノートを超える永続的な知識が必要な場合
+    - バンドルされた memory-wiki plugin を設定している場合
+    - wiki_search、wiki_get、または bridge モードを理解したい場合
+summary: 'memory-wiki: 出典、主張、ダッシュボード、bridge モードを備えたコンパイル済みナレッジボールト'
+title: Memory Wiki
+x-i18n:
+    generated_at: "2026-04-08T04:42:15Z"
+    model: gpt-5.4
+    provider: openai
+    source_hash: b78dd6a4ef4451dae6b53197bf0c7c2a2ba846b08e4a3a93c1026366b1598d82
+    source_path: plugins/memory-wiki.md
+    workflow: 15
+---
+
+# Memory Wiki
+
+`memory-wiki` は、永続メモリをコンパイル済みのナレッジボールトに変換するバンドルされた plugin です。
+
+これはアクティブな memory plugin を**置き換えるものではありません**。アクティブな memory plugin は引き続き、想起、昇格、インデックス作成、dreaming を担います。`memory-wiki` はその隣に位置し、永続的な知識を、決定論的なページ、構造化された主張、出典、ダッシュボード、機械可読なダイジェストを備えた、たどれる wiki にコンパイルします。
+
+メモリを Markdown ファイルの山というより、維持管理された知識レイヤーのように扱いたい場合に使います。
+
+## 追加されるもの
+
+- 決定論的なページレイアウトを持つ専用 wiki ボールト
+- 単なる散文ではない、構造化された主張と証拠のメタデータ
+- ページ単位の出典、信頼度、矛盾、未解決の疑問
+- agent/runtime コンシューマー向けのコンパイル済みダイジェスト
+- wiki ネイティブな search/get/apply/lint ツール
+- アクティブな memory plugin から公開アーティファクトを取り込むオプションの bridge モード
+- オプションの Obsidian 対応レンダーモードと CLI 統合
+
+## メモリとの関係
+
+分担は次のように考えるとわかりやすいです。
+
+| レイヤー                                                | 担当                                                                                       |
+| ------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
+| アクティブな memory plugin (`memory-core`, QMD, Honcho など) | 想起、セマンティック検索、昇格、dreaming、メモリ runtime                               |
+| `memory-wiki`                                           | コンパイル済み wiki ページ、出典が豊富な統合、ダッシュボード、wiki 固有の search/get/apply |
+
+アクティブな memory plugin が共有想起アーティファクトを公開している場合、OpenClaw は `memory_search corpus=all` で両レイヤーを一度に検索できます。
+
+wiki 固有のランキング、出典、またはページへの直接アクセスが必要な場合は、代わりに wiki ネイティブのツールを使ってください。
+
+## ボールトモード
+
+`memory-wiki` は 3 つのボールトモードをサポートします。
+
+### `isolated`
+
+独自のボールト、独自のソース、`memory-core` への依存なし。
+
+wiki をそれ自体でキュレートされた知識ストアにしたい場合に使います。
+
+### `bridge`
+
+公開された plugin SDK の継ぎ目を通じて、アクティブな memory plugin から公開メモリアーティファクトと memory event を読み取ります。
+
+非公開の plugin 内部実装に踏み込まずに、memory plugin がエクスポートしたアーティファクトを wiki でコンパイルして整理したい場合に使います。
+
+bridge モードでは次をインデックスできます。
+
+- エクスポートされたメモリアーティファクト
+- dream レポート
+- daily note
+- memory ルートファイル
+- memory event ログ
+
+### `unsafe-local`
+
+ローカルの非公開パスに対する、同一マシン専用の明示的なエスケープハッチです。
+
+このモードは意図的に実験的で、移植性がありません。信頼境界を理解しており、bridge モードでは提供できないローカルファイルシステムアクセスが明確に必要な場合にのみ使ってください。
+
+## ボールトレイアウト
+
+plugin は次のようなボールトを初期化します。
+
+```text
+<vault>/
+  AGENTS.md
+  WIKI.md
+  index.md
+  inbox.md
+  entities/
+  concepts/
+  syntheses/
+  sources/
+  reports/
+  _attachments/
+  _views/
+  .openclaw-wiki/
+```
+
+管理対象のコンテンツは生成ブロック内に保持されます。人間が書いたノートブロックは保持されます。
+
+主なページグループは次のとおりです。
+
+- `sources/`: 取り込んだ原資料と bridge に支えられたページ
+- `entities/`: 永続的なもの、人、システム、プロジェクト、オブジェクト
+- `concepts/`: アイデア、抽象概念、パターン、ポリシー
+- `syntheses/`: コンパイル済みの要約と保守されたロールアップ
+- `reports/`: 生成されたダッシュボード
+
+## 構造化された主張と証拠
+
+ページには、自由形式のテキストだけでなく、構造化された `claims` frontmatter を持たせることができます。
+
+各主張には次を含めることができます。
+
+- `id`
+- `text`
+- `status`
+- `confidence`
+- `evidence[]`
+- `updatedAt`
+
+証拠エントリには次を含めることができます。
+
+- `sourceId`
+- `path`
+- `lines`
+- `weight`
+- `note`
+- `updatedAt`
+
+これにより、wiki は受動的なノート置き場というより、信念レイヤーのように振る舞います。主張は追跡、採点、異議申し立て、そしてソースへの解決ができます。
+
+## コンパイルパイプライン
+
+コンパイルステップでは wiki ページを読み取り、要約を正規化し、安定した機械向けアーティファクトを次に出力します。
+
+- `.openclaw-wiki/cache/agent-digest.json`
+- `.openclaw-wiki/cache/claims.jsonl`
+
+これらのダイジェストがあることで、agents や runtime コードは Markdown ページをスクレイプしなくて済みます。
+
+コンパイル済み出力は、次にも利用されます。
+
+- search/get フロー向けの初回 wiki インデックス作成
+- claim id から所有ページへの逆引き
+- コンパクトなプロンプト補足
+- レポート/ダッシュボード生成
+
+## ダッシュボードとヘルスレポート
+
+`render.createDashboards` が有効な場合、コンパイルは `reports/` 配下でダッシュボードを維持します。
+
+組み込みレポートは次のとおりです。
+
+- `reports/open-questions.md`
+- `reports/contradictions.md`
+- `reports/low-confidence.md`
+- `reports/claim-health.md`
+- `reports/stale-pages.md`
+
+これらのレポートは、次のようなものを追跡します。
+
+- 矛盾メモのクラスター
+- 競合する主張のクラスター
+- 構造化された証拠が不足している主張
+- 低信頼度のページと主張
+- 古い、または鮮度不明の情報
+- 未解決の疑問があるページ
+
+## 検索と取得
+
+`memory-wiki` は 2 つの検索バックエンドをサポートします。
+
+- `shared`: 利用可能な場合は共有メモリ検索フローを使う
+- `local`: wiki をローカルで検索する
+
+また、3 つの corpus をサポートします。
+
+- `wiki`
+- `memory`
+- `all`
+
+重要な動作:
+
+- `wiki_search` と `wiki_get` は、可能な場合はコンパイル済みダイジェストを最初のパスとして使います
+- claim id は所有ページへ解決できます
+- 異議あり / 古い / 新しい主張がランキングに影響します
+- 出典ラベルは結果に引き継がれる場合があります
+
+実用的なルール:
+
+- 広く想起したい場合は `memory_search corpus=all` を使う
+- wiki 固有のランキング、出典、またはページ単位の信念構造を重視する場合は `wiki_search` + `wiki_get` を使う
+
+## Agent ツール
+
+plugin は次のツールを登録します。
+
+- `wiki_status`
+- `wiki_search`
+- `wiki_get`
+- `wiki_apply`
+- `wiki_lint`
+
+それぞれの役割:
+
+- `wiki_status`: 現在のボールトモード、健全性、Obsidian CLI の利用可否
+- `wiki_search`: wiki ページを検索し、設定されていれば共有メモリ corpus も検索する
+- `wiki_get`: id/path で wiki ページを読み取り、失敗した場合は共有メモリ corpus にフォールバックする
+- `wiki_apply`: 自由形式のページ編集なしで、限定的な統合/メタデータ変更を行う
+- `wiki_lint`: 構造チェック、出典の欠落、矛盾、未解決の疑問
+
+plugin はさらに、非排他的な memory corpus supplement も登録するため、アクティブな memory plugin が corpus 選択をサポートしていれば、共有の `memory_search` と `memory_get` から wiki にアクセスできます。
+
+## プロンプトとコンテキストの動作
+
+`context.includeCompiledDigestPrompt` が有効な場合、メモリプロンプトセクションには `agent-digest.json` からのコンパクトなコンパイル済みスナップショットが追加されます。
+
+そのスナップショットは意図的に小さく、高シグナルです。
+
+- 上位ページのみ
+- 上位主張のみ
+- 矛盾数
+- 疑問数
+- 信頼度 / 鮮度の修飾子
+
+これはプロンプト形状を変えるためオプトインです。主に、メモリ補足を明示的に利用する context engine やレガシーなプロンプト組み立てで役立ちます。
+
+## 設定
+
+設定は `plugins.entries.memory-wiki.config` に置きます。
+
+```json5
+{
+  plugins: {
+    entries: {
+      "memory-wiki": {
+        enabled: true,
+        config: {
+          vaultMode: "isolated",
+          vault: {
+            path: "~/.openclaw/wiki/main",
+            renderMode: "obsidian",
+          },
+          obsidian: {
+            enabled: true,
+            useOfficialCli: true,
+            vaultName: "OpenClaw Wiki",
+            openAfterWrites: false,
+          },
+          bridge: {
+            enabled: false,
+            readMemoryArtifacts: true,
+            indexDreamReports: true,
+            indexDailyNotes: true,
+            indexMemoryRoot: true,
+            followMemoryEvents: true,
+          },
+          ingest: {
+            autoCompile: true,
+            maxConcurrentJobs: 1,
+            allowUrlIngest: true,
+          },
+          search: {
+            backend: "shared",
+            corpus: "wiki",
+          },
+          context: {
+            includeCompiledDigestPrompt: false,
+          },
+          render: {
+            preserveHumanBlocks: true,
+            createBacklinks: true,
+            createDashboards: true,
+          },
+        },
+      },
+    },
+  },
+}
+```
+
+主な切り替え項目:
+
+- `vaultMode`: `isolated`、`bridge`、`unsafe-local`
+- `vault.renderMode`: `native` または `obsidian`
+- `bridge.readMemoryArtifacts`: アクティブな memory plugin の公開アーティファクトを取り込む
+- `bridge.followMemoryEvents`: bridge モードで event ログを含める
+- `search.backend`: `shared` または `local`
+- `search.corpus`: `wiki`、`memory`、または `all`
+- `context.includeCompiledDigestPrompt`: コンパクトなダイジェストスナップショットをメモリプロンプトセクションに追加する
+- `render.createBacklinks`: 決定論的な関連ブロックを生成する
+- `render.createDashboards`: ダッシュボードページを生成する
+
+## CLI
+
+`memory-wiki` はトップレベルの CLI surface も公開します。
+
+```bash
+openclaw wiki status
+openclaw wiki doctor
+openclaw wiki init
+openclaw wiki ingest ./notes/alpha.md
+openclaw wiki compile
+openclaw wiki lint
+openclaw wiki search "alpha"
+openclaw wiki get entity.alpha
+openclaw wiki apply synthesis "Alpha Summary" --body "..." --source-id source.alpha
+openclaw wiki bridge import
+openclaw wiki obsidian status
+```
+
+完全なコマンドリファレンスは [CLI: wiki](/cli/wiki) を参照してください。
+
+## Obsidian サポート
+
+`vault.renderMode` が `obsidian` の場合、plugin は Obsidian 対応の Markdown を書き出し、オプションで公式の `obsidian` CLI を使用できます。
+
+サポートされるワークフローには次が含まれます。
+
+- ステータスの確認
+- ボールト検索
+- ページを開く
+- Obsidian コマンドを呼び出す
+- daily note に移動する
+
+これはオプションです。wiki は Obsidian なしでも native モードで引き続き動作します。
+
+## 推奨ワークフロー
+
+1. 想起 / 昇格 / dreaming には既存のアクティブな memory plugin を使い続けます。
+2. `memory-wiki` を有効にします。
+3. bridge モードを明確に必要としない限り、`isolated` モードから始めます。
+4. 出典が重要なときは `wiki_search` / `wiki_get` を使います。
+5. 限定的な統合やメタデータ更新には `wiki_apply` を使います。
+6. 意味のある変更の後には `wiki_lint` を実行します。
+7. 古さや矛盾の可視性が必要ならダッシュボードを有効にします。
+
+## 関連ドキュメント
+
+- [Memory Overview](/ja-JP/concepts/memory)
+- [CLI: memory](/cli/memory)
+- [CLI: wiki](/cli/wiki)
+- [Plugin SDK overview](/ja-JP/plugins/sdk-overview)
--- a/docs/ja-JP/providers/glm.md
+++ b/docs/ja-JP/providers/glm.md
@ -1,39 +1,39 @@
 ---
 read_when:
-    - OpenClawでGLMモデルを使いたい場合
-    - モデル命名規則とセットアップが必要な場合
-summary: GLMモデルファミリーの概要とOpenClawでの使い方
-title: GLM Models
+    - OpenClawでGLMモデルを使いたい
+    - モデルの命名規則と設定方法が必要
+summary: GLMモデルファミリーの概要と、OpenClawでの使い方
+title: GLMモデル
 x-i18n:
-    generated_at: "2026-04-05T12:53:32Z"
+    generated_at: "2026-04-08T04:41:47Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 59622edab5094d991987f9788fbf08b33325e737e7ff88632b0c3ac89412d4c7
+    source_hash: 79a55acfa139847b4b85dbc09f1068cbd2febb1e49f984a23ea9e3b43bc910eb
    source_path: providers/glm.md
    workflow: 15
 ---

-# GLM Models
+# GLMモデル

-GLMは、Z.AIプラットフォームで利用できる**モデルファミリー**（企業名ではありません）です。OpenClawでは、GLM
-モデルは `zai` providerと、`zai/glm-5` のようなmodel ID経由で利用します。
+GLMは、Z.AIプラットフォームで利用できる**モデルファミリー**（企業ではありません）です。OpenClawでは、GLM
+モデルは`zai`プロバイダーと、`zai/glm-5`のようなモデルIDを通じて利用します。

 ## CLIセットアップ

 ```bash
-# Generic API-key setup with endpoint auto-detection
+# エンドポイント自動検出を使った汎用APIキー設定
 openclaw onboard --auth-choice zai-api-key

-# Coding Plan Global, recommended for Coding Plan users
+# Coding Plan Global。Coding Planユーザーに推奨
 openclaw onboard --auth-choice zai-coding-global

-# Coding Plan CN (China region), recommended for Coding Plan users
+# Coding Plan CN（中国リージョン）。Coding Planユーザーに推奨
 openclaw onboard --auth-choice zai-coding-cn

 # General API
 openclaw onboard --auth-choice zai-global

-# General API CN (China region)
+# General API CN（中国リージョン）
 openclaw onboard --auth-choice zai-cn
 ```

@ -42,17 +42,17 @@ openclaw onboard --auth-choice zai-cn
 ```json5
 {
  env: { ZAI_API_KEY: "sk-..." },
-  agents: { defaults: { model: { primary: "zai/glm-5" } } },
+  agents: { defaults: { model: { primary: "zai/glm-5.1" } } },
 }
 ```

-`zai-api-key` を使うと、OpenClawはキーから対応するZ.AI endpointを検出し、
-正しいbase URLを自動適用します。特定のCoding Planまたはgeneral API surfaceを
-強制したい場合は、明示的なリージョンchoiceを使ってください。
+`zai-api-key`を使うと、OpenClawはキーから対応するZ.AIエンドポイントを検出し、
+正しいベースURLを自動的に適用できます。特定のCoding PlanまたはGeneral APIの利用先を
+明示的に固定したい場合は、リージョンを明示した選択肢を使用してください。

-## 現在同梱されているGLMモデル
+## 現在バンドルされているGLMモデル

-OpenClawは現在、bundled `zai` providerに次のGLM refsを初期投入しています:
+OpenClawは現在、バンドルされた`zai`プロバイダーに以下のGLM参照を初期登録しています。

 - `glm-5.1`
 - `glm-5`
@ -70,6 +70,6 @@ OpenClawは現在、bundled `zai` providerに次のGLM refsを初期投入して

 ## 注意

- GLMのversionと提供状況は変わることがあるため、最新情報はZ.AIのdocsを確認してください。
- デフォルトのbundled model refは `zai/glm-5` です。
- providerの詳細は [/providers/zai](/providers/zai) を参照してください。
+- GLMのバージョンと提供状況は変更されることがあります。最新情報はZ.AIのドキュメントを確認してください。
+- デフォルトでバンドルされているモデル参照は`zai/glm-5.1`です。
+- プロバイダーの詳細は[/providers/zai](/ja-JP/providers/zai)を参照してください。
--- a/docs/ja-JP/providers/zai.md
+++ b/docs/ja-JP/providers/zai.md
@ -1,32 +1,33 @@
 ---
 read_when:
-    - OpenClawでZ.AI / GLM modelsを使いたいとき
-    - シンプルな `ZAI_API_KEY` セットアップが必要なとき
-summary: OpenClawでZ.AI（GLM models）を使う
+    - OpenClawでZ.AI / GLMモデルを使いたい
+    - シンプルなZAI_API_KEYのセットアップが必要
+summary: OpenClawでZ.AI（GLMモデル）を使う
 title: Z.AI
 x-i18n:
-    generated_at: "2026-04-05T12:54:49Z"
+    generated_at: "2026-04-08T04:41:48Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 48006cdd580484f0c62e2877b27a6a68d7bc44795b3e97a28213d95182d9acf9
+    source_hash: 66cbd9813ee28d202dcae34debab1b0cf9927793acb00743c1c62b48d9e381f9
    source_path: providers/zai.md
    workflow: 15
 ---

 # Z.AI

-Z.AIは **GLM** models向けのAPIプラットフォームです。GLM向けREST APIを提供し、認証にはAPI keysを使用します。Z.AI consoleでAPI keyを作成してください。OpenClawは `zai` providerをZ.AI API keyとともに使用します。
+Z.AIは**GLM**モデル向けのAPIプラットフォームです。GLM向けのREST APIを提供し、認証にはAPIキーを使用します。
+APIキーはZ.AIコンソールで作成してください。OpenClawは、Z.AI APIキーとともに`zai`プロバイダーを使用します。

 ## CLIセットアップ

 ```bash
-# endpoint自動検出付きの汎用API-keyセットアップ
+# エンドポイント自動検出を使った汎用APIキー設定
 openclaw onboard --auth-choice zai-api-key

-# Coding Plan Global。Coding Plan利用者向けの推奨
+# Coding Plan Global、Coding Planユーザーに推奨
 openclaw onboard --auth-choice zai-coding-global

-# Coding Plan CN（中国リージョン）。Coding Plan利用者向けの推奨
+# Coding Plan CN（中国リージョン）、Coding Planユーザーに推奨
 openclaw onboard --auth-choice zai-coding-cn

 # General API
@ -36,22 +37,22 @@ openclaw onboard --auth-choice zai-global
 openclaw onboard --auth-choice zai-cn
 ```

-## Config snippet
+## 設定スニペット

 ```json5
 {
  env: { ZAI_API_KEY: "sk-..." },
-  agents: { defaults: { model: { primary: "zai/glm-5" } } },
+  agents: { defaults: { model: { primary: "zai/glm-5.1" } } },
 }
 ```

-`zai-api-key` を使うと、OpenClawはkeyから一致するZ.AI endpointを検出し、
-正しいbase URLを自動的に適用できます。特定のCoding Planまたはgeneral API surfaceを
-強制したい場合は、明示的なリージョン選択を使ってください。
+`zai-api-key`を使うと、OpenClawはキーから対応するZ.AIエンドポイントを検出し、
+正しいベースURLを自動的に適用できます。特定のCoding PlanまたはGeneral APIサーフェスを
+強制したい場合は、明示的なリージョン選択を使用してください。

-## Bundled GLM catalog
+## バンドル済みGLMカタログ

-OpenClawは現在、bundledの `zai` providerを次で初期化します。
+OpenClawは現在、バンドル済みの`zai`プロバイダーに次をシードしています。

 - `glm-5.1`
 - `glm-5`
@ -67,14 +68,14 @@ OpenClawは現在、bundledの `zai` providerを次で初期化します。
 - `glm-4.5-flash`
 - `glm-4.5v`

-## 注
+## 注意

- GLM modelsは `zai/<model>` として利用できます（例: `zai/glm-5`）。
- デフォルトのbundled model ref: `zai/glm-5`
- 未知の `glm-5*` idも、idが現在のGLM-5 family形状に一致する場合は
-  `glm-4.7` templateからprovider所有metadataを合成することで、
-  bundled provider path上でforward-resolveされます。
- Z.AIのtool-call streamingでは、`tool_stream` はデフォルトで有効です。無効にするには
-  `agents.defaults.models["zai/<model>"].params.tool_stream` を `false` に設定してください。
- model familyの概要は [/providers/glm](/providers/glm) を参照してください。
- Z.AIは、API keyを使ったBearer authを使用します。
+- GLMモデルは`zai/<model>`として利用できます（例: `zai/glm-5`）。
+- デフォルトのバンドル済みモデル参照: `zai/glm-5.1`
+- 不明な`glm-5*` IDも、IDが現在のGLM-5ファミリーの形式に一致する場合、
+  `glm-4.7`テンプレートからプロバイダー所有のメタデータを合成することで、
+  バンドル済みプロバイダーパス上で引き続き解決されます。
+- Z.AIのツールコールストリーミングでは、`tool_stream`がデフォルトで有効です。無効にするには、
+  `agents.defaults.models["zai/<model>"].params.tool_stream`を`false`に設定してください。
+- モデルファミリーの概要は[/providers/glm](/ja-JP/providers/glm)を参照してください。
+- Z.AIは、APIキーを使ったBearer認証を使用します。
--- a/docs/ja-JP/refactor/qa.md
+++ b/docs/ja-JP/refactor/qa.md
@ -1,137 +1,137 @@
 ---
 x-i18n:
-    generated_at: "2026-04-08T02:19:22Z"
+    generated_at: "2026-04-08T04:42:35Z"
    model: gpt-5.4
    provider: openai
-    source_hash: 0e156cc8e2fe946a0423862f937754a7caa1fe7e6863b50a80bff49a1c86e1e8
+    source_hash: 4a9066b2a939c5a9ba69141d75405f0e8097997b523164340e2f0e9a0d5060dd
    source_path: refactor/qa.md
    workflow: 15
 ---

-# QAリファクタリング
+# QA リファクタリング

-ステータス: 基盤となる移行は完了しました。
+ステータス: 基盤となる移行は着地済み。

 ## 目標

-OpenClawのQAを分割定義モデルから単一の信頼できる情報源へ移行します:
+OpenClaw QA を分割定義モデルから単一の信頼できる情報源へ移行する:

 - シナリオメタデータ
 - モデルに送信されるプロンプト
- セットアップとクリーンアップ
+- セットアップとティアダウン
 - ハーネスロジック
 - アサーションと成功条件
 - アーティファクトとレポートのヒント

-目指す最終状態は、TypeScriptに大半の動作をハードコードするのではなく、
-強力なシナリオ定義ファイルを読み込む汎用QAハーネスです。
+望ましい最終状態は、TypeScript にほとんどの動作をハードコードするのではなく、強力なシナリオ定義ファイルを読み込む汎用 QA ハーネスです。

 ## 現在の状態

-現在の主要な信頼できる情報源は `qa/scenarios.md` にあります。
+現在の主要な信頼できる情報源は `qa/scenarios/index.md` と、`qa/scenarios/*.md` 配下のシナリオごとの 1 ファイルにあります。

 実装済み:

- `qa/scenarios.md`
-  - 正規のQAパック
-  - operator identity
+- `qa/scenarios/index.md`
+  - 正式な QA パックメタデータ
+  - オペレーター ID
  - キックオフミッション
+- `qa/scenarios/*.md`
+  - シナリオごとに 1 つの markdown ファイル
  - シナリオメタデータ
  - ハンドラーバインディング
+  - シナリオ固有の実行設定
 - `extensions/qa-lab/src/scenario-catalog.ts`
-  - Markdownパックパーサー + zod検証
+  - markdown パックパーサー + zod バリデーション
 - `extensions/qa-lab/src/qa-agent-bootstrap.ts`
-  - Markdownパックからのプラン描画
+  - markdown パックからのプラン描画
 - `extensions/qa-lab/src/qa-agent-workspace.ts`
-  - 互換ファイルと `QA_SCENARIOS.md` を生成するシード
+  - 互換性ファイル群に加えて `QA_SCENARIOS.md` を生成して配置
 - `extensions/qa-lab/src/suite.ts`
-  - Markdownで定義されたハンドラーバインディングを通じて実行可能なシナリオを選択
- QAバスプロトコル + UI
-  - 画像/動画/音声/ファイル表示向けの汎用インライン添付ファイル
+  - markdown 定義のハンドラーバインディングを通じて実行可能なシナリオを選択
+- QA バスプロトコル + UI
+  - 画像/動画/音声/ファイル描画用の汎用インライン添付ファイル

-残っている分割サーフェス:
+分割されたまま残っている面:

 - `extensions/qa-lab/src/suite.ts`
-  - 依然として実行可能なカスタムハンドラーロジックの大半を所有
+  - 依然として実行可能なカスタムハンドラーロジックの大半を保持
 - `extensions/qa-lab/src/report.ts`
-  - 依然としてランタイム出力からレポート構造を導出
+  - 依然として実行時出力からレポート構造を導出

-そのため、信頼できる情報源の分割は修正されましたが、実行は依然として完全に宣言的というより、
-主にハンドラーバックです。
+つまり、信頼できる情報源の分割は修正されたものの、実行はまだ完全な宣言型ではなく、主にハンドラーバックのままです。

-## 実際のシナリオサーフェスの姿
+## 実際のシナリオ面はどう見えるか

-現在のsuiteを読むと、いくつかの異なるシナリオクラスがあります。
+現在のスイートを読むと、いくつかの異なるシナリオクラスが見えてきます。

-### 単純なインタラクション
+### シンプルなインタラクション

 - チャネルベースライン
- DMベースライン
+- DM ベースライン
 - スレッド化されたフォローアップ
 - モデル切り替え
- 承認の完遂
- reaction/edit/delete
+- 承認の継続実行
+- リアクション/編集/削除

 ### 設定とランタイムの変更

- config patch によるskill無効化
- config apply による再起動ウェイクアップ
- config再起動による機能切り替え
- ランタイムインベントリ差分チェック
+- 設定パッチによる Skill 無効化
+- 設定適用後の再起動ウェイクアップ
+- 再起動時の設定機能切り替え
+- ランタイムインベントリドリフトチェック

 ### ファイルシステムとリポジトリアサーション

- ソース/ドキュメント探索レポート
- Lobster Invaders のビルド
+- ソース/ドキュメント検出レポート
+- Lobster Invaders をビルド
 - 生成画像アーティファクトの検索

 ### メモリオーケストレーション

- メモリ再呼び出し
+- メモリリコール
 - チャネルコンテキストでのメモリツール
 - メモリ失敗フォールバック
 - セッションメモリランキング
 - スレッドメモリ分離
- メモリdreaming sweep
+- メモリ dreaming sweep

-### ツールとプラグイン統合
+### ツールと plugin 連携

 - MCP plugin-tools 呼び出し
- skill可視性
- skillホットインストール
+- Skill の可視性
+- Skill のホットインストール
 - ネイティブ画像生成
 - 画像ラウンドトリップ
 - 添付ファイルからの画像理解

 ### マルチターンとマルチアクター

- subagent handoff
- subagent fanout synthesis
- 再起動復旧スタイルのフロー
+- サブエージェントのハンドオフ
+- サブエージェントのファンアウト統合
+- 再起動リカバリ系フロー

-これらのカテゴリはDSL要件を左右するため重要です。プロンプト + 期待テキストの
-フラットな一覧だけでは不十分です。
+これらのカテゴリは DSL 要件を左右するため重要です。プロンプト + 期待されるテキストの単純な一覧だけでは不十分です。

 ## 方向性

 ### 単一の信頼できる情報源

-作成対象の信頼できる情報源として `qa/scenarios.md` を使います。
+`qa/scenarios/index.md` と `qa/scenarios/*.md` を、作成時の信頼できる情報源として使います。

-このパックは次の状態を維持する必要があります:
+パックは次を維持するべきです:

- レビューで人間が読みやすい
- 機械が解析できる
- 次を駆動できるだけの十分な情報量がある:
-  - suite実行
-  - QA workspaceブートストラップ
-  - QA Lab UIメタデータ
-  - ドキュメント/探索プロンプト
+- レビューで人が読みやすい
+- 機械解析可能
+- 次を駆動できるだけの豊かさを持つ:
+  - スイート実行
+  - QA ワークスペースのブートストラップ
+  - QA Lab UI メタデータ
+  - ドキュメント/検出プロンプト
  - レポート生成

-### 推奨する作成形式
+### 推奨する記述フォーマット

-トップレベル形式としてMarkdownを使い、その中に構造化YAMLを入れます。
+トップレベルのフォーマットとして markdown を使い、その中に構造化 YAML を入れます。

 推奨形状:

@ -144,11 +144,11 @@ OpenClawのQAを分割定義モデルから単一の信頼できる情報源へ
  - code refs
  - model/provider overrides
  - prerequisites
- 散文セクション
+- 説明文セクション
  - objective
  - notes
  - debugging hints
- フェンス付きYAMLブロック
+- フェンス付き YAML ブロック
  - setup
  - steps
  - assertions
@ -156,13 +156,13 @@ OpenClawのQAを分割定義モデルから単一の信頼できる情報源へ

 これにより次が得られます:

- 巨大なJSONより優れたPR可読性
- 純粋なYAMLより豊かなコンテキスト
- 厳密な解析とzod検証
+- 巨大な JSON よりも優れた PR 可読性
+- 純粋な YAML よりも豊かなコンテキスト
+- 厳密なパースと zod バリデーション

-生のJSONは、中間生成形式としてのみ許容されます。
+生の JSON は、中間的な生成形式としてのみ許容されます。

-## 提案するシナリオファイル形状
+## 提案されるシナリオファイル形状

 例:

@ -187,7 +187,7 @@ codeRefs:

 # Objective

-Verify generated media is reattached on the follow-up turn.
+生成されたメディアがフォローアップターンで再添付されることを確認する。

 # Setup

@ -208,7 +208,7 @@ Verify generated media is reattached on the follow-up turn.
 - action: agent.send
  session: agent:qa:image-roundtrip
  message: |
-    Image generation check: generate a QA lighthouse image and summarize it in one short sentence.
+    画像生成チェック: QA 用の灯台画像を生成し、それを 1 文の短い文で要約してください。
 - action: artifact.capture
  kind: generated-image
  promptSnippet: Image generation check
@ -216,7 +216,7 @@ Verify generated media is reattached on the follow-up turn.
 - action: agent.send
  session: agent:qa:image-roundtrip
  message: |
-    Roundtrip image inspection check: describe the generated lighthouse attachment in one short sentence.
+    ラウンドトリップ画像検査チェック: 生成された灯台の添付画像を 1 文の短い文で説明してください。
  attachments:
    - fromArtifact: lighthouseImage
 ```
@ -235,9 +235,9 @@ Verify generated media is reattached on the follow-up turn.
 ```
 ````

-## DSLがカバーすべきランナー機能
+## DSL がカバーすべきランナー機能

-現在のsuiteに基づくと、汎用ランナーはプロンプト実行以上のものを必要とします。
+現在のスイートに基づくと、汎用ランナーにはプロンプト実行以上のものが必要です。

 ### 環境およびセットアップアクション

@ -248,7 +248,7 @@ Verify generated media is reattached on the follow-up turn.
 - `thread.create`
 - `workspace.writeSkill`

-### agentターンアクション
+### エージェントターンアクション

 - `agent.send`
 - `agent.wait`
@ -273,7 +273,7 @@ Verify generated media is reattached on the follow-up turn.
 - `artifact.captureGeneratedImage`
 - `artifact.capturePath`

-### メモリおよびcronアクション
+### メモリおよび cron アクション

 - `memory.indexForce`
 - `memory.searchCli`
@ -283,7 +283,7 @@ Verify generated media is reattached on the follow-up turn.
 - `cron.waitCompletion`
 - `sessionTranscript.write`

-### MCPアクション
+### MCP アクション

 - `mcp.callTool`

@ -305,134 +305,135 @@ Verify generated media is reattached on the follow-up turn.

 ## 変数とアーティファクト参照

-DSLは、保存された出力とその後の参照をサポートする必要があります。
+DSL は、保存された出力と後続参照をサポートする必要があります。

-現在のsuiteからの例:
+現在のスイートの例:

 - スレッドを作成し、その後 `threadId` を再利用する
 - セッションを作成し、その後 `sessionKey` を再利用する
 - 画像を生成し、次のターンでそのファイルを添付する
- wake marker文字列を生成し、それが後で現れることをアサートする
+- ウェイクマーカー文字列を生成し、それが後で現れることをアサートする

 必要な機能:

 - `saveAs`
 - `${vars.name}`
 - `${artifacts.name}`
- パス、セッションキー、thread id、marker、ツール出力向けの型付き参照
+- パス、セッションキー、スレッド ID、マーカー、ツール出力の型付き参照

-変数サポートがなければ、ハーネスはシナリオロジックをTypeScriptへ逆流させ続けます。
+変数サポートがなければ、ハーネスはシナリオロジックを TypeScript に逆流させ続けることになります。

 ## エスケープハッチとして残すべきもの

-フェーズ1で完全に純粋な宣言的ランナーを実現するのは現実的ではありません。
+フェーズ 1 で完全に純粋な宣言型ランナーを実現するのは現実的ではありません。

 一部のシナリオは本質的にオーケストレーション負荷が高いです:

- メモリdreaming sweep
- config apply による再起動ウェイクアップ
- config再起動による機能切り替え
+- memory dreaming sweep
+- 設定適用後の再起動ウェイクアップ
+- 再起動時の設定機能切り替え
 - タイムスタンプ/パスによる生成画像アーティファクト解決
 - discovery-report 評価

-これらは当面、明示的なカスタムハンドラーを使うべきです。
+これらは、当面は明示的なカスタムハンドラーを使うべきです。

 推奨ルール:

- 85〜90%は宣言的
+- 85-90% は宣言型
 - 残りの難しい部分には明示的な `customHandler` ステップ
- カスタムハンドラーは名前付きかつ文書化されたもののみ
- シナリオファイル内に匿名インラインコードは置かない
+- 名前付きで文書化されたカスタムハンドラーのみ
+- シナリオファイル内に匿名のインラインコードは禁止

-これにより、汎用エンジンをクリーンに保ちながら進展も可能になります。
+これにより、進捗を維持しつつ汎用エンジンをクリーンに保てます。

 ## アーキテクチャ変更

 ### 現在

-シナリオMarkdownはすでに次の信頼できる情報源です:
+シナリオ markdown はすでに次の信頼できる情報源です:

- suite実行
- workspaceブートストラップファイル
- QA Lab UIシナリオカタログ
+- スイート実行
+- ワークスペースブートストラップファイル
+- QA Lab UI シナリオカタログ
 - レポートメタデータ
- 探索プロンプト
+- discovery prompts

-生成される互換性:
+生成される互換性要素:

- シード済みworkspaceには依然として `QA_KICKOFF_TASK.md` が含まれる
- シード済みworkspaceには依然として `QA_SCENARIO_PLAN.md` が含まれる
- シード済みworkspaceには現在 `QA_SCENARIOS.md` も含まれる
+- シードされたワークスペースには依然として `QA_KICKOFF_TASK.md` が含まれる
+- シードされたワークスペースには依然として `QA_SCENARIO_PLAN.md` が含まれる
+- シードされたワークスペースには теперь `QA_SCENARIOS.md` も含まれる

 ## リファクタリング計画

-### フェーズ1: ローダーとスキーマ
+### フェーズ 1: ローダーとスキーマ

 完了。

- `qa/scenarios.md` を追加
- 名前付きMarkdown YAMLパック内容向けパーサーを追加
- zodで検証
- 利用側を解析済みパックへ切り替え
+- `qa/scenarios/index.md` を追加
+- シナリオを `qa/scenarios/*.md` に分割
+- 名前付き markdown YAML パック内容用のパーサーを追加
+- zod でバリデーション
+- パース済みパックを使うようコンシューマーを切り替え
 - リポジトリレベルの `qa/seed-scenarios.json` と `qa/QA_KICKOFF_TASK.md` を削除

-### フェーズ2: 汎用エンジン
+### フェーズ 2: 汎用エンジン

- `extensions/qa-lab/src/suite.ts` を次のように分割:
-  - ローダー
-  - エンジン
-  - アクションレジストリ
-  - アサーションレジストリ
-  - カスタムハンドラー
+- `extensions/qa-lab/src/suite.ts` を次に分割:
+  - loader
+  - engine
+  - action registry
+  - assertion registry
+  - custom handlers
 - 既存のヘルパー関数はエンジン操作として維持

 成果物:

- エンジンが単純な宣言的シナリオを実行する
+- エンジンがシンプルな宣言型シナリオを実行する

-まずは、主にプロンプト + 待機 + アサートで構成されるシナリオから始めます:
+まずは主に prompt + wait + assert で構成されるシナリオから始める:

 - スレッド化されたフォローアップ
 - 添付ファイルからの画像理解
- skill可視性と呼び出し
+- Skill の可視性と呼び出し
 - チャネルベースライン

 成果物:

- 汎用エンジン経由で提供される、最初の実際のMarkdown定義シナリオ
+- 汎用エンジン経由で出荷される、最初の実際の markdown 定義シナリオ

-### フェーズ4: 中程度のシナリオを移行
+### フェーズ 4: 中程度のシナリオを移行

 - 画像生成ラウンドトリップ
 - チャネルコンテキストでのメモリツール
 - セッションメモリランキング
- subagent handoff
- subagent fanout synthesis
+- サブエージェントのハンドオフ
+- サブエージェントのファンアウト統合

 成果物:

- 変数、アーティファクト、ツールアサーション、request-logアサーションが実証される
+- 変数、アーティファクト、ツールアサーション、request-log アサーションが実証される

-### フェーズ5: 難しいシナリオはカスタムハンドラーのまま維持
+### フェーズ 5: 難しいシナリオはカスタムハンドラーに残す

- メモリdreaming sweep
- config apply による再起動ウェイクアップ
- config再起動による機能切り替え
- ランタイムインベントリ差分
+- memory dreaming sweep
+- 設定適用後の再起動ウェイクアップ
+- 再起動時の設定機能切り替え
+- ランタイムインベントリドリフト

 成果物:

- 同じ作成形式だが、必要に応じて明示的なカスタムステップブロックを使用
+- 同じ記述フォーマットだが、必要な箇所に明示的な custom-step ブロックを使う

-### フェーズ6: ハードコードされたシナリオマップを削除
+### フェーズ 6: ハードコードされたシナリオマップを削除

 パックのカバレッジが十分になったら:

- `extensions/qa-lab/src/suite.ts` から、シナリオ固有のTypeScript分岐の大半を削除
+- `extensions/qa-lab/src/suite.ts` からシナリオ固有の TypeScript 分岐の大半を削除

 ## Fake Slack / リッチメディア対応

-現在のQAバスはテキスト優先です。
+現在の QA バスは text-first です。

 関連ファイル:

@ -442,17 +443,17 @@ DSLは、保存された出力とその後の参照をサポートする必要
 - `extensions/qa-lab/src/bus-server.ts`
 - `extensions/qa-lab/web/src/ui-render.ts`

-現在のQAバスがサポートしているもの:
+今日の QA バスが対応しているもの:

 - テキスト
- reaction
- thread
+- リアクション
+- スレッド

-まだインラインメディア添付はモデル化していません。
+まだインラインメディア添付ファイルはモデル化されていません。

-### 必要な転送コントラクト
+### 必要なトランスポート契約

-汎用QAバス添付モデルを追加します:
+汎用的な QA バス添付ファイルモデルを追加します:

 ```ts
 type QaBusAttachment = {
@ -471,67 +472,67 @@ type QaBusAttachment = {
 };
 ```

-その後、次に `attachments?: QaBusAttachment[]` を追加します:
+そのうえで `attachments?: QaBusAttachment[]` を次に追加します:

 - `QaBusMessage`
 - `QaBusInboundMessageInput`
 - `QaBusOutboundMessageInput`

-### なぜ最初に汎用化するのか
+### なぜまず汎用化なのか

-Slack専用のメディアモデルを作らないでください。
+Slack 専用のメディアモデルを作らないでください。

 代わりに:

- 1つの汎用QA転送モデル
+- 1 つの汎用 QA トランスポートモデル
 - その上に複数のレンダラー
-  - 現在のQA Labチャット
-  - 将来のfake Slack web
-  - その他のfake転送ビュー
+  - 現在の QA Lab チャット
+  - 将来の fake Slack web
+  - その他の fake transport views

-これによりロジックの重複を防ぎ、メディアシナリオを転送非依存に保てます。
+これによりロジックの重複を防ぎ、メディアシナリオをトランスポート非依存に保てます。

-### 必要なUI作業
+### 必要な UI 作業

-QA UIを更新して次を描画します:
+QA UI を更新して次を描画します:

 - インライン画像プレビュー
 - インライン音声プレーヤー
 - インライン動画プレーヤー
 - ファイル添付チップ

-現在のUIはすでにthreadとreactionを描画できるため、添付描画は同じメッセージカードモデルの上に重ねられるはずです。
+現在の UI はすでにスレッドとリアクションを描画できるため、添付ファイル描画は同じメッセージカードモデルに積み重ねられるはずです。

-### メディア転送によって可能になるシナリオ作業
+### メディアトランスポートによって可能になるシナリオ作業

-添付ファイルがQAバスを通って流れるようになれば、より豊かなfake-chatシナリオを追加できます:
+添付ファイルが QA バスを流れるようになれば、より豊かな fake-chat シナリオを追加できます:

- fake Slackでのインライン画像返信
- 音声添付理解
- 動画添付理解
- 混在する添付順序
+- fake Slack でのインライン画像返信
+- 音声添付ファイルの理解
+- 動画添付ファイルの理解
+- 混在添付ファイルの順序
 - メディアを保持したスレッド返信

-## 推奨
+## 推奨事項

-次の実装チャンクは次の順にするべきです:
+次の実装チャンクは、次にするべきです:

-1. Markdownシナリオローダー + zodスキーマを追加
-2. Markdownから現在のカタログを生成
-3. まずいくつかの単純なシナリオを移行
-4. 汎用QAバス添付サポートを追加
-5. QA UIでインライン画像を描画
+1. markdown シナリオローダー + zod スキーマを追加
+2. markdown から現在のカタログを生成
+3. まずいくつかのシンプルなシナリオを移行
+4. 汎用 QA バス添付ファイル対応を追加
+5. QA UI でインライン画像を描画
 6. その後、音声と動画へ拡張

 これは、両方の目標を実証する最小の道筋です:

- 汎用のMarkdown定義QA
- より豊かなfakeメッセージングサーフェス
+- 汎用的な markdown 定義 QA
+- より豊かな fake messaging surfaces

 ## 未解決の質問

- シナリオファイルで、変数補間付きの埋め込みMarkdownプロンプトテンプレートを許可するべきか
- setup/cleanup は名前付きセクションにするべきか、それとも単なる順序付きアクション一覧にするべきか
- アーティファクト参照はスキーマで強く型付けするべきか、それとも文字列ベースにするべきか
- カスタムハンドラーは1つのレジストリに置くべきか、それともサーフェスごとのレジストリにするべきか
- 移行中、生成されるJSON互換ファイルを引き続きチェックインしておくべきか
+- シナリオファイルで、変数補間付きの埋め込み markdown プロンプトテンプレートを許可するかどうか
+- setup/cleanup を名前付きセクションにするか、単なる順序付きアクションリストにするか
+- アーティファクト参照をスキーマ上で強く型付けするか、文字列ベースにするか
+- カスタムハンドラーを 1 つのレジストリに置くか、surface ごとのレジストリにするか
+- 移行期間中、生成される JSON 互換性ファイルを引き続きチェックインしておくべきかどうか