openclaw/docs
openclaw/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(i18n): refresh ja-JP translations

Browse Source
This commit is contained in:
openclaw-docs-i18n[bot] 2026-04-20 04:58:24 +00:00
parent f43278c7de
commit b2744703ad
9 changed files with 3540 additions and 3502 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

748
docs/ja-JP/channels/telegram.md
View File

File diff suppressed because it is too large Load Diff

267
docs/ja-JP/concepts/qa-e2e-automation.md
View File

@ -1,38 +1,37 @@
---
read_when:
- qa-labまたはqa-channelの拡張
- リポジトリ連動のQAシナリオの追加
- Gatewayダッシュボードを中心に、より現実に近いQA自動化を構築する
summary: qa-lab、qa-channel、シード済みシナリオ、プロトコルレポート向けの非公開QA自動化の構成
- リポジトリに裏付けられたQAシナリオの追加
- Gatewayダッシュボードを中心に、より現実に即したQA自動化を構築する
summary: qa-lab、qa-channel、シード済みシナリオ、およびプロトコルレポート向けの非公開QA自動化の構成
title: QA E2E自動化
x-i18n:
generated_at: "2026-04-18T04:40:10Z"
generated_at: "2026-04-20T04:46:32Z"
model: gpt-5.4
provider: openai
source_hash: adf8c5f74e8fabdc8e9fd7ecd41afce8b60354c7dd24d92ac926d3c527927cd4
source_hash: 34245ce871356caeab0d9e0eeeaa9fb4e408920a4a97ad27567fa365d8db17c7
source_path: concepts/qa-e2e-automation.md
workflow: 15
---
# QA E2E自動化
非公開のQAスタックは、単一のユニットテストよりも現実的で、
チャネルに近い形でOpenClawを検証することを目的としています。
非公開QAスタックは、単一のユニットテストよりも、より現実的で
チャネルに即した形でOpenClawを検証することを目的としています。
現在の構成要素:
- `extensions/qa-channel`: DM、チャネル、スレッド、
リアクション、編集、削除の各操作面を備えた合成メッセージチャネル。
- `extensions/qa-lab`: トランスクリプトの観測、
受信メッセージの注入、Markdownレポートのエクスポートを行うための
デバッガーUIとQAバス。
リアクション、編集、削除の各サーフェスを備えた合成メッセージチャネル。
- `extensions/qa-lab`: トランスクリプトの観察、
受信メッセージの注入、Markdownレポートのエクスポートを行うためのデバッガUIとQAバス。
- `qa/`: キックオフタスクとベースラインQA
シナリオ向けの、リポジトリ連動のシードアセット。
シナリオ向けの、リポジトリに裏付けられたシードアセット。
現在のQAオペレーターのフローは、2ペイン構成のQAサイトです:
現在のQAオペレーターフローは、2ペインのQAサイトです:
- 左: エージェントを表示するGatewayダッシュボード（Control UI）。
- 右: Slack風のトランスクリプトとシナリオプランを表示するQA Lab。
- 左: エージェントを備えたGatewayダッシュボード（Control UI）。
- 右: Slack風のトランスクリプトとシナリオ計画を表示するQA Lab。
次のコマンドで実行します:
@ -41,13 +40,12 @@ pnpm qa:lab:up
```
これによりQAサイトがビルドされ、Dockerベースのgatewayレーンが起動し、
オペレーターまたは自動化ループがエージェントにQA
ミッションを与え、実際のチャネル動作を観察し、何が機能したか、
何が失敗したか、何がブロックされたままだったかを記録できる
QA Labページが公開されます。
オペレーターまたは自動化ループがエージェントにQAミッションを与え、
実際のチャネル動作を観察し、何が機能したか、何が失敗したか、
何がブロックされたままだったかを記録できるQA Labページが公開されます。
Dockerイメージを毎回再ビルドせずにQA Lab UIをより高速に反復開発するには、
バインドマウントされたQA Labバンドルでスタックを起動します:
Dockerイメージを毎回再ビルドせずに、より高速にQA Lab UIを反復するには、
bind mountしたQA Labバンドルでスタックを起動します:
```bash
pnpm openclaw qa docker-build-image
@ -56,60 +54,61 @@ pnpm qa:lab:up:fast
pnpm qa:lab:watch
```
`qa:lab:up:fast` は事前ビルド済みイメージ上でDockerサービスを維持し、
`extensions/qa-lab/web/dist` を `qa-lab` コンテナにバインドマウントします。`qa:lab:watch`
`qa:lab:up:fast` は、Dockerサービスを事前ビルド済みイメージ上で維持し、
`extensions/qa-lab/web/dist` を `qa-lab` コンテナにbind mountします。`qa:lab:watch`
は変更時にそのバンドルを再ビルドし、QA Labアセットのハッシュが変わると
ブラウザは自動的にリロードされます。
ブラウザは自動リロードされます。
実際のトランスポートを使うMatrixスモークレーンを実行するには、次を使います:
トランスポート実体のあるMatrixスモークレーンを実行するには、次を実行します:
```bash
pnpm openclaw qa matrix
```
このレーンは、使い捨てのTuwunel homeserverをDockerで用意し、
このレーンは、Docker内に使い捨てのTuwunel homeserverをプロビジョニングし、
一時的なdriver、SUT、observerユーザーを登録し、1つのプライベートルームを作成してから、
実際のMatrix pluginをQA gateway child内で実行します。ライブトランスポートレーンは、
child設定をテスト対象のトランスポートに限定して保つため、
child設定内では `qa-channel` なしでMatrixが動作します。構造化レポートアーティファクトと、
stdout/stderrをまとめたログを、選択したMatrix QA出力ディレクトリに書き出します。
QA gateway child内で実際のMatrix pluginを実行します。ライブトランスポートレーンは、
テスト対象のトランスポートにchild configのスコープを限定するため、Matrixは
child config内で`qa-channel`なしに実行されます。構造化レポートアーティファクトと、
結合されたstdout/stderrログを、選択されたMatrix QA出力ディレクトリに書き込みます。
外側の `scripts/run-node.mjs` のビルド/ランチャー出力も取得するには、
`OPENCLAW_RUN_NODE_OUTPUT_LOG=<path>` をリポジトリ内のログファイルに設定します。
`OPENCLAW_RUN_NODE_OUTPUT_LOG=<path>` をリポジトリ内のログファイルに設定してください。
実際のトランスポートを使うTelegramスモークレーンを実行するには、次を使います:
トランスポート実体のあるTelegramスモークレーンを実行するには、次を実行します:
```bash
pnpm openclaw qa telegram
```
このレーンは、使い捨てサーバーを用意する代わりに、
実際の1つのプライベートTelegramグループを対象にします。必要なのは
このレーンは、使い捨てサーバーをプロビジョニングする代わりに、
実在する1つのプライベートTelegramグループを対象にします。
`OPENCLAW_QA_TELEGRAM_GROUP_ID`、
`OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN`、
`OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN` と、
同じプライベートグループ内にいる2つの異なるボットです。
SUTボットにはTelegramユーザー名が必要で、
ボット同士の観測は、両方のボットで
`@BotFather` の Bot-to-Bot Communication Mode が有効になっていると
最も安定して動作します。
`OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN`
が必要で、さらに同じプライベートグループ内に2つの異なるbotが必要です。
SUT botにはTelegramユーザー名が必要で、bot同士の観察は、
両方のbotで `@BotFather` 内の Bot-to-Bot Communication Mode を
有効にしていると最もうまく機能します。
いずれかのシナリオが失敗すると、このコマンドはゼロ以外の終了コードで終了します。
終了コードを失敗にせずアーティファクトを取得したい場合は、`--allow-failures` を使用してください。
ライブトランスポートレーンは現在、それぞれが独自のシナリオ一覧形式を発明する代わりに、
より小さな1つの共通コントラクトを共有しています:
ライブトランスポートレーンは現在、各レーンが独自のシナリオリスト形式を
考案するのではなく、1つのより小さな共通コントラクトを共有しています:
`qa-channel` は依然として広範な合成プロダクト動作スイートであり、
`qa-channel` は依然として幅広い合成プロダクト動作スイートであり、
ライブトランスポートのカバレッジマトリクスには含まれません。
| レーン | Canary | メンションゲーティング | 許可リストブロック | トップレベル返信 | 再起動後の再開 | スレッドフォローアップ | スレッド分離 | リアクション観測 | ヘルプコマンド |
| -------- | ------ | ---------------------- | ------------------ | ---------------- | -------------- | ---------------------- | ------------ | ---------------- | -------------- |
| Matrix | x | x | x | x | x | x | x | x | |
| Telegram | x | | | | | | | | x |
| レーン | Canary | メンションゲーティング | Allowlistブロック | トップレベル返信 | 再起動後の再開 | スレッド追従 | スレッド分離 | リアクション観察 | ヘルプコマンド |
| -------- | ------ | ---------------------- | ----------------- | ---------------- | -------------- | ------------ | ------------ | ---------------- | -------------- |
| Matrix | x | x | x | x | x | x | x | x | |
| Telegram | x | | | | | | | | x |
これにより、`qa-channel` は広範なプロダクト動作スイートとして維持されつつ、
Matrix、Telegram、将来のライブトランスポートが、
明示的な1つのトランスポートコントラクトのチェックリストを共有できます。
これにより、`qa-channel` は幅広いプロダクト動作スイートとして維持される一方で、
Matrix、Telegram、および今後のライブトランスポートは、明示的な
トランスポートコントラクトのチェックリストを共有します。
QAパスにDockerを持ち込まずに、使い捨てのLinux VMレーンを実行するには、
次を使います:
QAパスにDockerを持ち込まずに使い捨てのLinux VMレーンを実行するには、
次を実行します:
```bash
pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
@ -117,111 +116,107 @@ pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline
これにより新しいMultipass guestが起動し、依存関係をインストールし、
guest内でOpenClawをビルドし、`qa suite` を実行してから、
通常のQAレポートとサマリーをホスト上の `.artifacts/qa-e2e/...` にコピーして戻します。
通常のQAレポートとサマリーをホスト上の `.artifacts/qa-e2e/...` に
コピーし戻します。
ホスト上の `qa suite` と同じシナリオ選択動作を再利用します。
ホストとMultipassのsuite実行は、デフォルトで分離されたgateway workerを使って、
選択された複数のシナリオを並列実行し、
最大64 workerまたは選択シナリオ数のいずれか少ない方まで動作します。
worker数を調整するには `--concurrency <count>` を使い、
直列実行するには `--concurrency 1` を使います。
ライブ実行では、guestに対して実用的なサポート済みQA認証入力が転送されます:
envベースのprovider key、QA live provider設定パス、
および存在する場合は `CODEX_HOME` です。guestが
マウントされたワークスペース経由で書き戻せるように、
`--output-dir` はリポジトリルート配下に保ってください。
ホスト実行とMultipass suite実行はどちらも、選択された複数のシナリオを、
分離されたgateway workerでデフォルトで並列実行します。`qa-channel` のデフォルト同時実行数は4で、
選択されたシナリオ数を上限とします。worker数を調整するには
`--concurrency <count>` を使用し、直列実行には `--concurrency 1` を使用してください。
いずれかのシナリオが失敗すると、このコマンドはゼロ以外の終了コードで終了します。
終了コードを失敗にせずアーティファクトを取得したい場合は、`--allow-failures` を使用してください。
ライブ実行では、guestで実用的なサポート対象のQA認証入力を転送します:
envベースのprovider key、QA live provider config path、そして
存在する場合は `CODEX_HOME` です。guestがマウントされたworkspace経由で
書き戻せるように、`--output-dir` はリポジトリルート配下に維持してください。
## リポジトリ連動のシード
## リポジトリに裏付けられたシード
シードアセットは `qa/` にあります:
- `qa/scenarios/index.md`
- `qa/scenarios/<theme>/*.md`
これらは意図的にgitに置かれており、QAプランが人間にも
エージェントにも見えるようになっています。
これらは意図的にgitに置かれており、QA計画を人間と
エージェントの両方から可視にしています。
`qa-lab` は汎用的なmarkdownランナーとして維持するべきです。各シナリオmarkdownファイルは
1回のテスト実行における信頼できる唯一の情報源であり、次を定義する必要があります:
`qa-lab` は汎用的なmarkdownランナーのままであるべきです。各シナリオmarkdownファイルは
1回のテスト実行における唯一の信頼できる情報源であり、次を定義する必要があります:
- シナリオメタデータ
- 任意のカテゴリ、ケイパビリティ、レーン、リスクのメタデータ
- docsとcodeの参照
- 任意のcategory、capability、lane、riskメタデータ
- docs参照とcode参照
- 任意のplugin要件
- 任意のgateway設定パッチ
- 任意のgateway config patch
- 実行可能な `qa-flow`
`qa-flow` を支える再利用可能なランタイム面は、
汎用的かつ横断的なままで構いません。たとえば、markdownシナリオは、
埋め込みControl UIをGatewayの `browser.request` seam経由で駆動する
ブラウザ側ヘルパーと、トランスポート側ヘルパーを組み合わせてもよく、
そのために特別扱いのランナーを追加する必要はありません。
`qa-flow` を支える再利用可能なランタイムサーフェスは、
汎用的かつ横断的なままでかまいません。たとえば、markdownシナリオは、
特別扱いのランナーを追加せずに、トランスポート側ヘルパーと、
Gatewayの `browser.request` シームを通じて埋め込みControl UIを操作する
ブラウザ側ヘルパーを組み合わせることができます。
シナリオファイルは、ソースツリーのフォルダではなく、
プロダクト機能ごとにグループ化するべきです。ファイルを移動しても
シナリオIDは安定したままにし、実装トレーサビリティには
`docsRefs` と `codeRefs` を使ってください。
プロダクト機能ごとにグループ化するべきです。ファイルが移動してもシナリオIDは安定させ、
実装のトレーサビリティには `docsRefs` と `codeRefs` を使用してください。
ベースライン一覧は、次をカバーできる程度に広く保つべきです:
ベースライン一覧は、次をカバーできる程度に十分広く保つべきです:
- DMとチャネルチャット
- スレッド動作
- メッセージアクションのライフサイクル
- Cronコールバック
- メモリの想起
- メモリー再呼び出し
- モデル切り替え
- subagent handoff
- リポジトリ読み取りとdocs読み取り
- Lobster Invadersのような小さなビルドタスク1件
- Lobster Invadersのような小さなビルドタスク1つ
## Providerモックレーン
`qa suite` には2つのローカルproviderモックレーンがあります:
- `mock-openai` はシナリオ認識型のOpenClawモックです。
リポジトリ連動QAとパリティゲート向けの、
デフォルトの決定的モックレーンのままです。
- `aimock` は実験的なプロトコル、
フィクスチャ、record/replay、chaosカバレッジ向けに
AIMockベースのproviderサーバーを起動します。これは追加的なものであり、
`mock-openai` シナリオディスパッチャーを置き換えるものではありません。
- `mock-openai` は、シナリオ認識型のOpenClawモックです。これは引き続き、
リポジトリに裏付けられたQAとパリティゲート向けのデフォルトの決定的モックレーンです。
- `aimock` は、実験的なプロトコル、
フィクスチャ、record/replay、chaosカバレッジ向けに、AIMockベースのprovider serverを起動します。
これは追加的なものであり、`mock-openai` のシナリオディスパッチャを置き換えるものではありません。
Providerレーン実装は `extensions/qa-lab/src/providers/` 配下にあります。
各providerは、自身のデフォルト値、ローカルサーバー起動、
gateway model設定、auth-profileステージング要件、
およびlive/mockケイパビリティフラグを管理します。
各providerは、それぞれのデフォルト、ローカルserver起動、gateway model config、
auth-profileステージング要件、およびlive/mock capability flagsを所有します。
共有suiteコードとgatewayコードは、provider名で分岐するのではなく、
provider registryを経由してルーティングするべきです。
## トランスポートアダプター
`qa-lab` はmarkdown QAシナリオ向けの汎用トランスポートseamを所有します。
`qa-channel` はそのseam上の最初のアダプターですが、
設計目標はより広いものです:
将来の実チャネルまたは合成チャネルは、
トランスポート固有のQAランナーを追加するのではなく、
同じsuite runnerに接続できるようにするべきです。
`qa-lab` は、markdown QAシナリオ向けの汎用トランスポートシームを所有します。
`qa-channel` はそのシーム上の最初のアダプターですが、設計対象はより広く、
将来の実チャネルまたは合成チャネルも、トランスポート固有のQAランナーを追加するのではなく、
同じsuite runnerに接続できるようにすることです。
アーキテクチャレベルでの分担は次のとおりです:
アーキテクチャレベルでは、分担は次のとおりです:
- `qa-lab` は汎用シナリオ実行、worker並列性、アーティファクト書き出し、レポートを所有します。
- トランスポートアダプターはgateway設定、readiness、受信および送信の観測、トランスポートアクション、正規化されたトランスポート状態を所有します。
- `qa/scenarios/` 配下のmarkdownシナリオファイルがテスト実行を定義し、それを実行する再利用可能なランタイム面は `qa-lab` が提供します。
- `qa-lab` は、汎用シナリオ実行、worker並列実行、アーティファクト書き込み、レポート作成を所有します。
- トランスポートアダプターは、gateway config、readiness、受信と送信の観察、トランスポートアクション、正規化されたトランスポート状態を所有します。
- `qa/scenarios/` 配下のmarkdownシナリオファイルがテスト実行を定義し、`qa-lab` はそれを実行するための再利用可能なランタイムサーフェスを提供します。
新しいチャネルアダプター向けのメンテナー向け導入ガイダンスは
新しいチャネルアダプター向けの、メンテナー向け採用ガイダンスは
[Testing](/ja-JP/help/testing#adding-a-channel-to-qa) にあります。
## レポート
`qa-lab` は、観測されたバスタイムラインからMarkdownのプロトコルレポートを
エクスポートします。レポートは次に答えるべきです:
`qa-lab` は、観察されたバスタイムラインからMarkdownのプロトコルレポートを
エクスポートします。
レポートは次の問いに答えるべきです:
- 何が機能したか
- 何が失敗したか
- 何がブロックされたままだったか
- どのフォローアップシナリオを追加する価値があるか
- 追加する価値のあるフォローアップシナリオは何か
文字やスタイルのチェックについては、同じシナリオを複数のライブモデル参照で実行し、
判定付きMarkdownレポートを書き出します:
キャラクターとスタイルのチェックでは、同じシナリオを複数のlive model参照に対して実行し、
評価済みMarkdownレポートを書き出します:
```bash
pnpm openclaw qa character-eval \
@ -241,41 +236,37 @@ pnpm openclaw qa character-eval \
```
このコマンドはDockerではなく、ローカルのQA gateway child processを実行します。
character evalシナリオでは `SOUL.md` を通じてペルソナを設定し、
その後チャット、ワークスペース支援、小さなファイルタスクのような
通常のユーザーターンを実行するべきです。
候補モデルには、それが評価対象であることを伝えてはいけません。
このコマンドは各完全トランスクリプトを保持し、基本的な実行統計を記録したうえで、
judge modelにfast modeと `xhigh` reasoningで、
自然さ、雰囲気、ユーモアに基づいて実行結果を順位付けさせます。
providerを比較する際は `--blind-judge-models` を使ってください:
judgeプロンプトには依然としてすべてのトランスクリプトと実行ステータスが渡されますが、
候補参照は `candidate-01` のような中立ラベルに置き換えられます。
レポートは、解析後に順位を実際の参照へ対応付けて戻します。
候補実行はデフォルトで `high` thinking、
それをサポートするOpenAIモデルでは `xhigh` になります。
特定の候補を上書きするには
`--model provider/model,thinking=<level>` をインラインで使います。
`--thinking <level>` は引き続きグローバルなフォールバックを設定し、
古い `--model-thinking <provider/model=level>` 形式も
互換性のため保持されています。
OpenAI候補参照はデフォルトでfast modeとなるため、
providerが対応している場合はpriority processingが使われます。
単一の候補またはjudgeに上書きが必要な場合は、
character evalシナリオでは、`SOUL.md` を通じてペルソナを設定し、その後にチャット、
workspaceヘルプ、小さなファイルタスクなどの通常のユーザーターンを実行するべきです。
候補modelには、評価されていることを伝えてはいけません。このコマンドは、
各完全トランスクリプトを保持し、基本的な実行統計を記録し、その後judge modelに対して、
`xhigh` 推論を伴うfast modeで、自然さ、雰囲気、ユーモアに基づいて
実行結果を順位付けするよう求めます。
providerを比較する際は、`--blind-judge-models` を使用してください:
judgeプロンプトには引き続きすべてのトランスクリプトと実行ステータスが渡されますが、
候補参照は `candidate-01` のような中立ラベルに置き換えられ、
レポートは解析後にランキングを実際の参照へマッピングし戻します。
候補実行のthinkingはデフォルトで `high` であり、対応するOpenAI modelでは `xhigh` になります。
特定の候補をインラインで上書きするには、
`--model provider/model,thinking=<level>` を使用してください。`--thinking <level>` は
引き続きグローバルなフォールバックを設定し、従来の
`--model-thinking <provider/model=level>` 形式も互換性のため維持されています。
OpenAI候補参照はデフォルトでfast modeとなり、providerが対応している場合は
優先処理が使われます。単一の候補またはjudgeに対して上書きが必要な場合は、
`,fast`、`,no-fast`、または `,fast=false` をインラインで追加してください。
すべての候補モデルに対してfast modeを強制的に有効にしたい場合にのみ
`--fast` を渡します。候補とjudgeの所要時間は
ベンチマーク分析のためレポートに記録されますが、
judgeプロンプトでは速度で順位付けしないよう明示されています。
候補実行とjudge model実行はどちらもデフォルトで並列数16です。
providerの制限やローカルgatewayの負荷で実行が不安定になる場合は、
すべての候補modelでfast modeを強制的にオンにしたい場合にのみ、`--fast` を渡してください。
候補とjudgeの所要時間はベンチマーク分析のためレポートに記録されますが、
judgeプロンプトでは、速度で順位付けしないよう明示しています。
候補実行とjudge model実行は、どちらもデフォルトで同時実行数16です。
provider制限やローカルgatewayの負荷によって実行が不安定になる場合は、
`--concurrency` または `--judge-concurrency` を下げてください。
候補 `--model` が指定されない場合、character evalのデフォルトは
候補 `--model` が渡されない場合、character evalはデフォルトで
`openai/gpt-5.4`、`openai/gpt-5.2`、`openai/gpt-5`、`anthropic/claude-opus-4-6`、
`anthropic/claude-sonnet-4-6`、`zai/glm-5.1`、
`moonshot/kimi-k2.5`、
`google/gemini-3.1-pro-preview` になります。
judge `--judge-model` が指定されない場合、judgeのデフォルトは
`google/gemini-3.1-pro-preview` を使用します。
候補 `--model` が渡されない場合に使用されます。
`--judge-model` が渡されない場合、judgeのデフォルトは
`openai/gpt-5.4,thinking=xhigh,fast` と
`anthropic/claude-opus-4-6,thinking=high` です。

1602
docs/ja-JP/gateway/configuration-reference.md
View File

File diff suppressed because it is too large Load Diff

2234
docs/ja-JP/help/faq.md
View File

File diff suppressed because it is too large Load Diff

1078
docs/ja-JP/help/testing.md
View File

File diff suppressed because it is too large Load Diff

116
docs/ja-JP/install/index.md
View File

@ -1,15 +1,15 @@
---
read_when:
- はじめにのクイックスタート以外のインストール方法が必要な場合
- 「はじめに」のクイックスタート以外のインストール方法が必要です
- クラウドプラットフォームにデプロイしたい場合
- 更新、移行、またはアンインストールが必要な場合
summary: OpenClawのインストール — インストーラースクリプト、npm/pnpm/bun、ソースから、Dockerなど
- 更新、移行、またはアンインストールを行う必要がある場合
summary: OpenClawをインストール — インストーラースクリプト、npm/pnpm/bun、ソースから、Docker、その他
title: インストール
x-i18n:
generated_at: "2026-04-05T12:48:23Z"
generated_at: "2026-04-20T04:46:34Z"
model: gpt-5.4
provider: openai
source_hash: eca17c76a2a66166b3d8cda9dc3144ab920d30ad0ed2a220eb9389d7a383ba5d
source_hash: ad0a5fdbbf13dcaf2fed6840f35aa22b2e9e458509509f98303c8d87c2556a6f
source_path: install/index.md
workflow: 15
---
@ -18,7 +18,7 @@ x-i18n:
## 推奨: インストーラースクリプト
最も速いインストール方法です。OSを検出し、必要に応じてNodeをインストールし、OpenClawをインストールして、オンボーディングを開始します。
最も速くインストールする方法です。OSを検出し、必要に応じてNodeをインストールし、OpenClawをインストールして、オンボーディングを開始します。
<Tabs>
<Tab title="macOS / Linux / WSL2">
@ -48,29 +48,27 @@ x-i18n:
</Tab>
</Tabs>
すべてのフラグとCI/自動化オプションについては、[Installer internals](/install/installer) を参照してください。
すべてのフラグとCI/自動化オプションについては、[インストーラーの内部](/ja-JP/install/installer)を参照してください。
## システム要件
- **Node 24**（推奨）または Node 22.14+ — インストーラースクリプトがこれを自動で処理します
- **macOS、Linux、またはWindows** — ネイティブWindowsとWSL2の両方をサポートしています。WSL2のほうがより安定しています。[Windows](/platforms/windows) を参照してください。
- `pnpm` はソースからビルドする場合にのみ必要です
- **Node 24**（推奨）またはNode 22.14+ — インストーラースクリプトがこれを自動的に処理します
- **macOS、Linux、またはWindows** — ネイティブWindowsとWSL2の両方をサポートしています。WSL2のほうがより安定しています。[Windows](/ja-JP/platforms/windows)を参照してください。
- ソースからビルドする場合にのみ`pnpm`が必要です
## 別のインストール方法
## 代替のインストール方法
### ローカルプレフィックスインストーラー（`install-cli.sh`）
システム全体のNodeインストールに依存せず、
`~/.openclaw` のようなローカルプレフィックス配下にOpenClawとNodeを保持したい場合に使用します:
システム全体のNodeインストールに依存せず、`~/.openclaw`のようなローカルプレフィックス配下にOpenClawとNodeを保持したい場合に使用します:
```bash
curl -fsSL https://openclaw.ai/install-cli.sh | bash
```
デフォルトでnpmインストールをサポートし、同じ
プレフィックスフローでgit checkoutインストールにも対応しています。完全なリファレンス: [Installer internals](/install/installer#install-clish)。
デフォルトでnpmインストールをサポートし、同じプレフィックスフロー内でgitチェックアウトからのインストールにも対応しています。完全なリファレンス: [インストーラーの内部](/ja-JP/install/installer#install-clish)。
### npm、pnpm、または bun
### npm、pnpm、またはbun
すでに自分でNodeを管理している場合:
@ -89,7 +87,7 @@ curl -fsSL https://openclaw.ai/install-cli.sh | bash
```
<Note>
pnpmでは、ビルドスクリプトを持つパッケージに明示的な承認が必要です。最初のインストール後に `pnpm approve-builds -g` を実行してください。
pnpmでは、ビルドスクリプトを含むパッケージに対して明示的な承認が必要です。最初のインストール後に`pnpm approve-builds -g`を実行してください。
</Note>
</Tab>
@ -100,14 +98,14 @@ curl -fsSL https://openclaw.ai/install-cli.sh | bash
```
<Note>
BunはグローバルCLIインストール経路でサポートされています。Gatewayランタイムについては、引き続きNodeが推奨デーモンランタイムです。
BunはグローバルCLIインストール経路でサポートされています。Gatewayランタイムについては、引き続きNodeが推奨のデーモンランタイムです。
</Note>
</Tab>
</Tabs>
<Accordion title="トラブルシューティング: sharp のビルドエラー（npm）">
グローバルにインストールされたlibvipsが原因で `sharp` が失敗する場合:
<Accordion title="トラブルシューティング: sharpのビルドエラー（npm）">
グローバルにインストールされたlibvipsが原因で`sharp`が失敗する場合:
```bash
SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm install -g openclaw@latest
@ -117,19 +115,19 @@ SHARP_IGNORE_GLOBAL_LIBVIPS=1 npm install -g openclaw@latest
### ソースから
コントリビューターや、ローカルcheckoutから実行したい人向け:
コントリビューターや、ローカルのチェックアウトから実行したい人向け:
```bash
git clone https://github.com/openclaw/openclaw.git
cd openclaw
pnpm install && pnpm ui:build && pnpm build
pnpm install && pnpm build && pnpm ui:build
pnpm link --global
openclaw onboard --install-daemon
```
または、linkをスキップしてリポジトリ内から `pnpm openclaw ...` を使用することもできます。完全な開発ワークフローについては [Setup](/start/setup) を参照してください。
または、linkをスキップして、リポジトリ内で`pnpm openclaw ...`を使用してください。完全な開発ワークフローについては、[セットアップ](/ja-JP/start/setup)を参照してください。
### GitHub main からインストール
### GitHub mainからインストール
```bash
npm install -g github:openclaw/openclaw#main
@ -138,20 +136,20 @@ npm install -g github:openclaw/openclaw#main
### コンテナとパッケージマネージャー
<CardGroup cols={2}>
<Card title="Docker" href="/install/docker" icon="container">
コンテナ化またはヘッドレスのデプロイ。
<Card title="Docker" href="/ja-JP/install/docker" icon="container">
コンテナ化またはヘッドレスデプロイ。
</Card>
<Card title="Podman" href="/install/podman" icon="container">
Dockerのrootlessコンテナ代替。
<Card title="Podman" href="/ja-JP/install/podman" icon="container">
Dockerのrootlessなコンテナ代替手段。
</Card>
<Card title="Nix" href="/install/nix" icon="snowflake">
<Card title="Nix" href="/ja-JP/install/nix" icon="snowflake">
Nix flakeによる宣言的インストール。
</Card>
<Card title="Ansible" href="/install/ansible" icon="server">
<Card title="Ansible" href="/ja-JP/install/ansible" icon="server">
自動化されたフリートプロビジョニング。
</Card>
<Card title="Bun" href="/install/bun" icon="zap">
BunランタイムによるCLI専用利用。
<Card title="Bun" href="/ja-JP/install/bun" icon="zap">
Bunランタイム経由のCLI専用利用。
</Card>
</CardGroup>
@ -160,60 +158,60 @@ npm install -g github:openclaw/openclaw#main
```bash
openclaw --version # CLIが利用可能であることを確認
openclaw doctor # 設定の問題を確認
openclaw gateway status # Gatewayが動作していることを確認
openclaw gateway status # Gatewayが実行中であることを確認
```
インストール後に管理された起動を使いたい場合:
インストール後に管理された起動を使用したい場合:
- macOS: `openclaw onboard --install-daemon` または `openclaw gateway install` によるLaunchAgent
- Linux/WSL2: 同じコマンドによるsystemd user service
- ネイティブWindows: まずScheduled Task、タスク作成が拒否された場合はユーザーごとのStartup-folderログイン項目へフォールバック
- macOS: `openclaw onboard --install-daemon`または`openclaw gateway install`によるLaunchAgent
- Linux/WSL2: 同じコマンドによるsystemdユーザーサービス
- ネイティブWindows: まずScheduled Task、タスク作成が拒否された場合はユーザーごとのStartupフォルダーのログイン項目にフォールバック
## ホスティングとデプロイ
クラウドサーバーまたはVPSにOpenClawをデプロイします:
<CardGroup cols={3}>
<Card title="VPS" href="/vps">任意のLinux VPS</Card>
<Card title="Docker VM" href="/install/docker-vm-runtime">共通のDocker手順</Card>
<Card title="Kubernetes" href="/install/kubernetes">K8s</Card>
<Card title="Fly.io" href="/install/fly">Fly.io</Card>
<Card title="Hetzner" href="/install/hetzner">Hetzner</Card>
<Card title="GCP" href="/install/gcp">Google Cloud</Card>
<Card title="Azure" href="/install/azure">Azure</Card>
<Card title="Railway" href="/install/railway">Railway</Card>
<Card title="Render" href="/install/render">Render</Card>
<Card title="Northflank" href="/install/northflank">Northflank</Card>
<Card title="VPS" href="/ja-JP/vps">任意のLinux VPS</Card>
<Card title="Docker VM" href="/ja-JP/install/docker-vm-runtime">共通のDocker手順</Card>
<Card title="Kubernetes" href="/ja-JP/install/kubernetes">K8s</Card>
<Card title="Fly.io" href="/ja-JP/install/fly">Fly.io</Card>
<Card title="Hetzner" href="/ja-JP/install/hetzner">Hetzner</Card>
<Card title="GCP" href="/ja-JP/install/gcp">Google Cloud</Card>
<Card title="Azure" href="/ja-JP/install/azure">Azure</Card>
<Card title="Railway" href="/ja-JP/install/railway">Railway</Card>
<Card title="Render" href="/ja-JP/install/render">Render</Card>
<Card title="Northflank" href="/ja-JP/install/northflank">Northflank</Card>
</CardGroup>
## 更新、移行、またはアンインストール
<CardGroup cols={3}>
<Card title="Updating" href="/install/updating" icon="refresh-cw">
OpenClawを最新に保ちます。
<Card title="更新" href="/ja-JP/install/updating" icon="refresh-cw">
OpenClawを最新の状態に保ちます。
</Card>
<Card title="Migrating" href="/install/migrating" icon="arrow-right">
新しいマシンへ移行します。
<Card title="移行" href="/ja-JP/install/migrating" icon="arrow-right">
新しいマシンに移動します。
</Card>
<Card title="Uninstall" href="/install/uninstall" icon="trash-2">
<Card title="アンインストール" href="/ja-JP/install/uninstall" icon="trash-2">
OpenClawを完全に削除します。
</Card>
</CardGroup>
## トラブルシューティング: `openclaw` が見つからない
## トラブルシューティング: `openclaw`が見つからない
インストールは成功したのに、ターミナルで `openclaw` が見つからない場合:
インストールは成功したのに、ターミナルで`openclaw`が見つからない場合:
```bash
node -v # Nodeはインストール済み?
npm prefix -g # グローバルパッケージはどこにある?
echo "$PATH" # グローバルbinディレクトリはPATHに入っている?
node -v # Nodeはインストール済みですか？
npm prefix -g # グローバルパッケージはどこにありますか？
echo "$PATH" # グローバルbinディレクトリはPATHに含まれていますか？
```
`$(npm prefix -g)/bin` が `$PATH` にない場合は、シェル起動ファイル（`~/.zshrc` または `~/.bashrc`）に追加してください:
`$(npm prefix -g)/bin`が`$PATH`に含まれていない場合は、シェルの起動ファイル（`~/.zshrc`または`~/.bashrc`）に追加してください:
```bash
export PATH="$(npm prefix -g)/bin:$PATH"
```
その後、新しいターミナルを開いてください。詳細は [Node setup](/install/node) を参照してください。
その後、新しいターミナルを開いてください。詳細は[Nodeセットアップ](/ja-JP/install/node)を参照してください。

120
docs/ja-JP/platforms/windows.md
View File

@ -1,57 +1,54 @@
---
read_when:
- WindowsにOpenClawをインストールする
- ネイティブWindowsとWSL2のどちらを選ぶか検討している
- Windows companion appの状況を知りたい
summary: 'Windowsサポート: ネイティブ環境とWSL2のインストール経路、daemon、現在の注意点'
- WindowsへのOpenClawのインストール
- ネイティブWindowsとWSL2の選び方
- Windowsコンパニオンアプリの状況を確認する
summary: 'Windowsサポート: ネイティブおよびWSL2のインストールパス、デーモン、現在の注意事項'
title: Windows
x-i18n:
generated_at: "2026-04-05T12:51:27Z"
generated_at: "2026-04-20T04:46:33Z"
model: gpt-5.4
provider: openai
source_hash: 7d9819206bdd65cf03519c1bc73ed0c7889b0ab842215ea94343262300adfd14
source_hash: 1e7451c785a1d75c809522ad93e2c44a00b211f77f14c5c489fd0b01840d3fe2
source_path: platforms/windows.md
workflow: 15
---
# Windows
OpenClawは**ネイティブWindows**と**WSL2**の両方をサポートしています。WSL2のほうが
より安定した経路であり、完全な体験には推奨されます。CLI、Gateway、toolingは
Linux内で動作し、完全な互換性があります。ネイティブWindowsでも
コアのCLIとGatewayは利用できますが、以下の注意点があります。
OpenClawは**ネイティブWindows**と**WSL2**の両方をサポートしています。WSL2のほうがより安定したパスであり、フル体験には推奨されています。CLI、Gateway、各種ツールはLinux内で完全な互換性をもって動作します。ネイティブWindowsでも中核となるCLIとGatewayの利用は可能ですが、以下に記載するいくつかの注意事項があります。
ネイティブWindows companion appは計画中です。
ネイティブWindows向けコンパニオンアプリは計画中です。
## WSL2（推奨）
- [はじめに](/ja-JP/start/getting-started)（WSL内で使用）
- [インストールと更新](/install/updating)
- [インストールと更新](/ja-JP/install/updating)
- 公式WSL2ガイド（Microsoft）: [https://learn.microsoft.com/windows/wsl/install](https://learn.microsoft.com/windows/wsl/install)
## ネイティブWindowsの現状
ネイティブWindowsのCLIフローは改善が進んでいますが、依然としてWSL2が推奨経路です。
ネイティブWindowsでのCLIフローは改善が進んでいますが、依然としてWSL2が推奨パスです。
現在ネイティブWindowsでうまく動作するもの:
現在ネイティブWindowsで問題なく動作するもの:
- `install.ps1` によるwebsite installer
- `install.ps1` を使ったWebサイト経由のインストーラー
- `openclaw --version`、`openclaw doctor`、`openclaw plugins list --json` などのローカルCLI利用
- 次のような埋め込みlocal-agent/provider smoke:
- 次のような組み込みのlocal-agent/providerスモークテスト:
```powershell
openclaw agent --local --agent main --thinking low -m "Reply with exactly WINDOWS-HATCH-OK."
```
現在の注意点:
現在の注意事項:
- `openclaw onboard --non-interactive` は、`--skip-health` を渡さない限り、到達可能なローカルGatewayを引き続き前提とします
- `openclaw onboard --non-interactive --install-daemon` と `openclaw gateway install` は、まずWindows Scheduled Tasksを試します
- Scheduled Taskの作成が拒否された場合、OpenClawはユーザーごとのStartupフォルダーのlogin itemにフォールバックし、すぐにGatewayを起動します
- `schtasks` 自体がハングしたり応答しなくなったりした場合、OpenClawは永遠に待機する代わりに、その経路をすばやく中止してフォールバックします
- より良いsupervisor statusを提供するため、利用可能な場合は引き続きScheduled Tasksが優先されます
- `openclaw onboard --non-interactive` は、`--skip-health` を渡さない限り、到達可能なローカルGatewayを引き続き必要とします
- `openclaw onboard --non-interactive --install-daemon` と `openclaw gateway install` は、まずWindowsのScheduled Tasksを試します
- Scheduled Taskの作成が拒否された場合、OpenClawはユーザーごとのStartupフォルダー内ログイン項目にフォールバックし、ただちにGatewayを起動します
- `schtasks` 自体がハングしたり応答しなくなった場合、OpenClawはそのパスをすばやく中止し、無限に待機するのではなくフォールバックするようになりました
- 利用可能な場合でも、より良い supervisor の状態確認を提供できるため、引き続きScheduled Tasksが優先されます
ネイティブCLIのみを使い、Gateway service installを行わない場合は、次のいずれかを使ってください。
ネイティブCLIのみを使いたい場合で、Gatewayサービスのインストールが不要なら、次のいずれかを使ってください:
```powershell
openclaw onboard --non-interactive --skip-health
@ -65,14 +62,14 @@ openclaw gateway install
openclaw gateway status --json
```
Scheduled Taskの作成がブロックされる場合でも、フォールバックservice modeは現在のユーザーのStartupフォルダーを通じてログイン後に自動起動します。
Scheduled Taskの作成がブロックされる場合でも、フォールバックのサービスモードは現在のユーザーのStartupフォルダー経由で、ログイン後に自動起動します。
## Gateway
- [Gateway runbook](/gateway)
- [Configuration](/gateway/configuration)
- [Gatewayランブック](/ja-JP/gateway)
- [設定](/ja-JP/gateway/configuration)
## Gateway service install（CLI）
## Gatewayサービスのインストール（CLI）
WSL2内では:
@ -92,9 +89,9 @@ openclaw gateway install
openclaw configure
```
プロンプトが表示されたら **Gateway service** を選択してください。
プロンプトが表示されたら、**Gateway service** を選択してください。
修復/移行:
修復／移行:
```
openclaw doctor
@ -102,10 +99,9 @@ openclaw doctor
## Windowsログイン前にGatewayを自動起動する
ヘッドレス構成では、誰も
Windowsへログインしていなくても、完全な起動チェーンが動作するようにしてください。
ヘッドレス構成では、誰もWindowsにログインしなくても、起動チェーン全体が実行されるようにしてください。
### 1) ログインなしでもユーザーserviceを動かし続ける
### 1) ログインなしでもユーザーサービスを動かし続ける
WSL内で:
@ -113,7 +109,7 @@ WSL内で:
sudo loginctl enable-linger "$(whoami)"
```
### 2) OpenClaw Gateway user serviceをインストールする
### 2) OpenClaw Gatewayユーザーサービスをインストールする
WSL内で:
@ -123,13 +119,13 @@ openclaw gateway install
### 3) Windows起動時にWSLを自動起動する
PowerShellをAdministratorとして開いて実行:
管理者としてPowerShellで:
```powershell
schtasks /create /tn "WSL Boot" /tr "wsl.exe -d Ubuntu --exec /bin/true" /sc onstart /ru SYSTEM
```
`Ubuntu` は次のコマンドで確認できるdistro名に置き換えてください。
`Ubuntu` は、次のコマンドで表示されるディストリビューション名に置き換えてください:
```powershell
wsl --list --verbose
@ -137,21 +133,18 @@ wsl --list --verbose
### 起動チェーンを確認する
再起動後（Windowsサインイン前）、WSLから次を確認します。
再起動後（Windowsサインイン前）、WSLから次を確認してください:
```bash
systemctl --user is-enabled openclaw-gateway.service
systemctl --user status openclaw-gateway.service --no-pager
```
## 高度な設定: WSL serviceをLANへ公開する（portproxy）
## 高度な設定: WSLのサービスをLAN上に公開する（portproxy）
WSLには独自の仮想ネットワークがあります。別のマシンから
**WSL内で**動作するservice（SSH、ローカルTTS server、またはGateway）へ到達する必要がある場合、
Windowsのportを現在のWSL IPへ転送する必要があります。WSL IPは再起動後に変わるため、
転送ルールを更新する必要がある場合があります。
WSLは独自の仮想ネットワークを持っています。別のマシンから**WSL内**で動作しているサービス（SSH、ローカルTTSサーバー、またはGateway）に到達する必要がある場合、Windowsのポートを現在のWSL IPへ転送しなければなりません。WSL IPは再起動後に変わるため、転送ルールを更新する必要がある場合があります。
例（PowerShellを**Administratorとして**実行）:
例（**管理者として**PowerShellで実行）:
```powershell
$Distro = "Ubuntu-24.04"
@ -165,7 +158,7 @@ netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=$ListenPor
connectaddress=$WslIp connectport=$TargetPort
```
そのportをWindows Firewallで許可します（1回のみ）:
Windows Firewallでそのポートを許可します（1回だけ）:
```powershell
New-NetFirewallRule -DisplayName "WSL SSH $ListenPort" -Direction Inbound `
@ -182,28 +175,27 @@ netsh interface portproxy add v4tov4 listenport=$ListenPort listenaddress=0.0.0.
注意:
- 別のマシンからのSSHは**Windows host IP**を対象にします（例: `ssh user@windows-host -p 2222`）。
- リモートnodeは、到達可能なGateway URL（`127.0.0.1` ではない）を指す必要があります。
確認には `openclaw status --all` を使ってください。
- LANアクセスには `listenaddress=0.0.0.0` を使ってください。`127.0.0.1` ならローカル専用です。
- 別のマシンからのSSHは**WindowsホストのIP**を対象にします（例: `ssh user@windows-host -p 2222`）。
- リモートNodeは、**到達可能な** Gateway URL（`127.0.0.1` ではない）を指す必要があります。確認には `openclaw status --all` を使ってください。
- LANアクセスには `listenaddress=0.0.0.0` を使います。`127.0.0.1` ならローカル専用のままです。
- これを自動化したい場合は、ログイン時に更新手順を実行するScheduled Taskを登録してください。
## WSL2インストール手順
## WSL2のステップ別インストール
### 1) WSL2 + Ubuntuをインストールする
PowerShellをAdminで開きます:
PowerShell（管理者）を開きます:
```powershell
wsl --install
# または、distroを明示的に選択:
# または、ディストリビューションを明示的に選択:
wsl --list --online
wsl --install -d Ubuntu-24.04
```
Windowsから求められたら再起動してください。
Windowsに求められたら再起動してください。
### 2) systemdを有効にする（Gateway installに必須）
### 2) systemdを有効にする（Gatewayのインストールに必須）
WSLターミナルで:
@ -214,13 +206,13 @@ systemd=true
EOF
```
その後PowerShellから:
その後、PowerShellから:
```powershell
wsl --shutdown
```
Ubuntuを再度開き、次で確認します:
Ubuntuを再度開いて、次を確認します:
```bash
systemctl --user status
@ -228,20 +220,28 @@ systemctl --user status
### 3) OpenClawをインストールする（WSL内）
WSL内でLinux向けのはじめにフローに従ってください:
WSL内で通常の初回セットアップを行う場合は、Linux向けの「はじめに」フローに従ってください:
```bash
git clone https://github.com/openclaw/openclaw.git
cd openclaw
pnpm install
pnpm ui:build # 初回実行時にUI依存関係を自動インストール
pnpm build
openclaw onboard
pnpm ui:build
pnpm openclaw onboard --install-daemon
```
初回オンボーディングではなくソースから開発する場合は、[Setup](/ja-JP/start/setup) のソース開発ループを使ってください:
```bash
pnpm install
# 初回実行時のみ（またはローカルのOpenClaw config/workspaceをリセットした後）
pnpm openclaw setup
pnpm gateway:watch
```
完全なガイド: [はじめに](/ja-JP/start/getting-started)
## Windows companion app
## Windowsコンパニオンアプリ
まだWindows companion appはありません。実現したい場合は、
コントリビューションを歓迎します。
まだWindowsコンパニオンアプリはありません。実現に向けた貢献をしたい場合は、コントリビューションを歓迎します。

112
docs/ja-JP/start/setup.md
View File

@ -1,14 +1,14 @@
---
read_when:
- 新しいマシンをセットアップするとき
- 個人設定を壊さずに「最新かつ最高」の状態を使いたいとき
summary: OpenClaw の高度なセットアップと開発ワークフロー
- 新しいマシンのセットアップ
- 個人のセットアップを壊さずに「最新かつ最高」の状態を使いたい場合
summary: OpenClawの高度なセットアップと開発ワークフロー
title: セットアップ
x-i18n:
generated_at: "2026-04-05T12:57:39Z"
generated_at: "2026-04-20T04:46:31Z"
model: gpt-5.4
provider: openai
source_hash: be4e280dde7f3a224345ca557ef2fb35a9c9db8520454ff63794ac6f8d4e71e7
source_hash: 773cdbef5f38b069303b5e13fca5fcdc28f082746869f17b8b92aab1610b95a8
source_path: start/setup.md
workflow: 15
---
@ -16,36 +16,36 @@ x-i18n:
# セットアップ
<Note>
初めてセットアップする場合は、[はじめに](/ja-JP/start/getting-started) から始めてください。
オンボーディングの詳細は、[Onboarding (CLI)](/ja-JP/start/wizard) を参照してください。
初めてセットアップする場合は、[はじめに](/ja-JP/start/getting-started)から始めてください。
オンボーディングの詳細は、[オンボーディング (CLI)](/ja-JP/start/wizard)を参照してください。
</Note>
## 要点
- **カスタマイズはリポジトリの外に置きます:** `~/.openclaw/workspace`（workspace）+ `~/.openclaw/openclaw.json`（config）。
- **カスタマイズはリポジトリの外にあります:** `~/.openclaw/workspace`（workspace）+ `~/.openclaw/openclaw.json`（config）。
- **安定したワークフロー:** macOSアプリをインストールし、同梱のGatewayを実行させます。
- **最先端ワークフロー:** `pnpm gateway:watch` で自分でGatewayを実行し、その後macOSアプリをローカルモードで接続させます。
- **最先端のワークフロー:** `pnpm gateway:watch` で自分でGatewayを実行し、その後macOSアプリをLocalモードで接続させます。
## 前提条件（ソースから実行する場合）
## 前提条件（ソースから）
- Node 24を推奨（Node 22 LTS、現在は `22.14+`、も引き続きサポート）
- `pnpm` を推奨（または意図的に [Bun workflow](/ja-JP/install/bun) を使う場合はBun）
- Docker（任意。コンテナ化されたセットアップ/e2e専用。詳細は [Docker](/ja-JP/install/docker) を参照）
- Node 24推奨（Node 22 LTS、現在は `22.14+`、引き続きサポートされています）
- `pnpm` 推奨（または、意図的に[Bun workflow](/ja-JP/install/bun)を使う場合はBun）
- Docker（任意。コンテナ化されたセットアップ/e2eの場合のみ — [Docker](/ja-JP/install/docker)を参照）
## カスタマイズ戦略（アップデートで困らないように）
「自分向けに100%カスタマイズ」 _かつ_ アップデートも簡単にしたい場合は、カスタマイズを次に保存してください。
「自分向けに100%カスタマイズ」しつつ簡単にアップデートしたい場合は、カスタマイズ内容を次に保持してください。
- **Config:** `~/.openclaw/openclaw.json`（JSON/JSON5風）
- **Workspace:** `~/.openclaw/workspace`（skills、prompts、memories。プライベートなgitリポジトリにしてください）
一度だけブートストラップします:
一度だけ初期化します。
```bash
openclaw setup
```
このリポジトリ内からは、ローカルCLIエントリを使います:
このリポジトリ内からは、ローカルCLIエントリを使います。
```bash
openclaw setup
@ -55,7 +55,7 @@ openclaw setup
## このリポジトリからGatewayを実行する
`pnpm build` の後、パッケージ化されたCLIを直接実行できます:
`pnpm build` の後、パッケージ化されたCLIを直接実行できます。
```bash
node openclaw.mjs gateway --port 18789 --verbose
@ -65,30 +65,30 @@ node openclaw.mjs gateway --port 18789 --verbose
1. **OpenClaw.app**（メニューバー）をインストールして起動します。
2. オンボーディング/権限チェックリスト（TCCプロンプト）を完了します。
3. Gateway が **Local** で実行中であることを確認します（アプリが管理します）。
4. 接続先をリンクします（例: WhatsApp）:
3. Gatewayが**Local**で実行中であることを確認します（アプリが管理します）。
4. サーフェスをリンクします（例: WhatsApp）。
```bash
openclaw channels login
```
5. 動作確認:
5. 正常性を確認します。
```bash
openclaw health
```
使用中のビルドでオンボーディングが利用できない場合:
お使いのビルドでオンボーディングが利用できない場合:
- `openclaw setup` を実行し、その後 `openclaw channels login` を実行してから、Gatewayを手動で起動してください（`openclaw gateway`）。
- `openclaw setup` を実行し、次に `openclaw channels login` を実行して、その後Gatewayを手動で起動します（`openclaw gateway`）。
## 最先端ワークフロー（ターミナルでGatewayを実行）
## 最先端のワークフロー（ターミナルでGatewayを実行）
目的: TypeScript Gateway を開発し、ホットリロードを得ながら、macOSアプリUIを接続したままにすることです。
目的: TypeScript Gatewayで作業し、ホットリロードを使い、macOSアプリのUIは接続したままにします。
### 0) （任意）macOSアプリもソースから実行する
macOSアプリも最先端版にしたい場合:
macOSアプリも最先端で使いたい場合:
```bash
./scripts/restart-mac.sh
@ -98,30 +98,36 @@ macOSアプリも最先端版にしたい場合:
```bash
pnpm install
# 初回のみ（またはローカルのOpenClaw config/workspaceをリセットした後）
pnpm openclaw setup
pnpm gateway:watch
```
`gateway:watch` はwatchモードでgatewayを実行し、関連するソース、
config、および同梱pluginメタデータの変更時に再読み込みします。
config、およびbundled-plugin metadataの変更時に再読み込みします。
`pnpm openclaw setup` は、新しいチェックアウト向けの一度限りのローカルconfig/workspace初期化手順です。
`pnpm gateway:watch` は `dist/control-ui` を再ビルドしないため、`ui/` を変更した後は `pnpm ui:build` を再実行するか、Control UIの開発中は `pnpm ui:dev` を使用してください。
意図的にBun workflowを使っている場合、対応するコマンドは次のとおりです:
意図的にBun workflowを使っている場合、対応するコマンドは次のとおりです。
```bash
bun install
# 初回のみ（またはローカルのOpenClaw config/workspaceをリセットした後）
bun run openclaw setup
bun run gateway:watch
```
### 2) 実行中のGatewayをmacOSアプリに向ける
### 2) 実行中のGatewayにmacOSアプリを向ける
**OpenClaw.app** で:
- 接続モード: **Local**
アプリは設定されたポート上の実行中gatewayに接続します。
- Connection Mode: **Local**
アプリは、設定されたポートで実行中のgatewayに接続します。
### 3) 確認
### 3) 確認する
- アプリ内のGatewayステータスは **「Using existing gateway …」** と表示されるはずです
- またはCLI経由で:
- アプリ内のGatewayステータスが**「Using existing gateway …」**と表示されるはずです
- またはCLIから:
```bash
openclaw health
@ -129,51 +135,51 @@ openclaw health
### よくある落とし穴
- **ポートが違う:** Gateway WSのデフォルトは `ws://127.0.0.1:18789` です。アプリとCLIで同じポートを使ってください。
- **ポート違い:** Gateway WSのデフォルトは `ws://127.0.0.1:18789` です。アプリとCLIで同じポートを使ってください。
- **状態が保存される場所:**
- チャネル/プロバイダーの状態: `~/.openclaw/credentials/`
- チャンネル/プロバイダーの状態: `~/.openclaw/credentials/`
- モデル認証プロファイル: `~/.openclaw/agents/<agentId>/agent/auth-profiles.json`
- セッション: `~/.openclaw/agents/<agentId>/sessions/`
- ログ: `/tmp/openclaw/`
## 認証情報ストレージ対応表
## 認証情報ストレージの対応表
認証のデバッグや、何をバックアップすべきか判断するときに使ってください:
認証のデバッグや、何をバックアップすべきかを判断するときに使ってください。
- **WhatsApp**: `~/.openclaw/credentials/whatsapp/<accountId>/creds.json`
- **Telegram bot token**: config/env または `channels.telegram.tokenFile`（通常ファイルのみ。symlinkは拒否）
- **Discord bot token**: config/env または SecretRef（env/file/exec プロバイダー）
- **Telegram bot token**: config/env または `channels.telegram.tokenFile`（通常のファイルのみ。symlinkは拒否されます）
- **Discord bot token**: config/env または SecretRef（env/file/exec providers）
- **Slack tokens**: config/env（`channels.slack.*`）
- **ペアリングallowlist**:
- **ペアリング許可リスト**:
- `~/.openclaw/credentials/<channel>-allowFrom.json`（デフォルトアカウント）
- `~/.openclaw/credentials/<channel>-<accountId>-allowFrom.json`（デフォルト以外のアカウント）
- **モデル認証プロファイル**: `~/.openclaw/agents/<agentId>/agent/auth-profiles.json`
- **ファイルベースのシークレットペイロード（任意）**: `~/.openclaw/secrets.json`
- **レガシーOAuthインポート**: `~/.openclaw/credentials/oauth.json`
- **従来のOAuthインポート**: `~/.openclaw/credentials/oauth.json`
詳細: [Security](/ja-JP/gateway/security#credential-storage-map)。
## 更新（セットアップを壊さずに）
## 更新する（セットアップを壊さずに）
- `~/.openclaw/workspace` と `~/.openclaw/` を「自分のもの」として扱ってください。個人的なprompts/configを `openclaw` リポジトリに置かないでください。
- ソースの更新: `git pull` + 選択したパッケージマネージャーのインストール手順（デフォルトは `pnpm install`、Bun workflowでは `bun install`）+ 引き続き対応する `gateway:watch` コマンドを使います。
- `~/.openclaw/workspace` と `~/.openclaw/` を「自分のもの」として扱ってください。個人用のprompts/configを `openclaw` リポジトリに入れないでください。
- ソースの更新: `git pull` + 選択したパッケージマネージャーのインストール手順（デフォルトは `pnpm install`、Bun workflowでは `bun install`）+ 引き続き対応する `gateway:watch` コマンドを使用します。
## Linux（systemdユーザーサービス）
Linuxインストールでは systemd **ユーザー**サービスを使用します。デフォルトでは、systemdはログアウト時やアイドル時にユーザー
サービスを停止するため、Gatewayも停止します。オンボーディングは
自動で lingering を有効にしようとします（sudoを求める場合があります）。まだ無効なら、次を実行してください:
Linuxインストールではsystemdの**ユーザー**サービスを使います。デフォルトでは、systemdはログアウト/アイドル時にユーザー
サービスを停止するため、Gatewayも停止します。オンボーディングでは
自動的にlingeringを有効にしようとします（sudoを求められる場合があります）。それでも無効な場合は、次を実行してください。
```bash
sudo loginctl enable-linger $USER
```
常時稼働や複数ユーザーのサーバーでは、ユーザーサービスではなく
**system** サービスの利用を検討してください（lingeringは不要です）。systemdの注意点については [Gateway runbook](/ja-JP/gateway) を参照してください。
常時稼働または複数ユーザーのサーバーでは、ユーザーサービスではなく
**システム**サービスを検討してください（lingeringは不要です）。systemdに関する注意は[Gateway runbook](/ja-JP/gateway)を参照してください。
## 関連ドキュメント
- [Gateway runbook](/ja-JP/gateway)（フラグ、supervision、ポート）
- [Gateway configuration](/ja-JP/gateway/configuration)（configスキーマ + 例）
- [Discord](/ja-JP/channels/discord) と [Telegram](/ja-JP/channels/telegram)（reply tags + replyToMode設定）
- [OpenClaw assistant setup](/start/openclaw)
- [Gateway runbook](/ja-JP/gateway)（フラグ、監視、ポート）
- [Gateway configuration](/ja-JP/gateway/configuration)（config schema + examples）
- [Discord](/ja-JP/channels/discord) と [Telegram](/ja-JP/channels/telegram)（返信タグ + replyToMode設定）
- [OpenClaw assistant setup](/ja-JP/start/openclaw)
- [macOS app](/ja-JP/platforms/macos)（gatewayライフサイクル）

765
docs/ja-JP/tools/browser.md
View File

File diff suppressed because it is too large Load Diff