OpenClawをまだインストールしていませんか？ワンラインインストールコマンドはこちら
curl -fsSL https://openclaw.ai/install.sh | bash
iwr -useb https://openclaw.ai/install.ps1 | iex
curl -fsSL https://openclaw.ai/install.cmd -o install.cmd && install.cmd && del install.cmd
PCへの影響が心配ですか？ClawTankならクラウドで動作し、インストール不要で誤削除のリスクもありません
主要な知見
  • OpenClawはネイティブWindows 11（非WSL2）でPowerShellコマンド1行でインストールできる。インストーラーはシステム既存のNode.jsを自動検出し、openclawをグローバルnpmパッケージとしてインストールする
  • インストール後、openclaw onboardを実行するとインタラクティブセットアップウィザードが起動し、ネイティブターミナル内でTelegram連携、Gatewayモード選択、基本設定をワンステップで完了できる
  • Dashboardが開けない根本原因はブラウザの問題ではなく、Gatewayサービスが動作していないことにある――openclaw dashboardはブラウザを開いてローカルWebSocketサーバーに接続するだけであり、Gatewayが動作していなければ接続先が存在しない
  • ネイティブWindows環境でのGateway永続化は、管理者権限でopenclaw gateway installを実行する必要がある（内部でschtasksに依存）。または、フォアグラウンドモードopenclaw gatewayを使用して素早く検証できる

1. ネイティブWindowsインストールを選ぶ理由

OpenClawの公式ドキュメントやコミュニティチュートリアルは、macOS、Linux、WSL2環境に圧倒的に偏っている[1]。これは理にかなっている――OpenClawのコアアーキテクチャはUnixエコシステムから生まれており、Gatewayデーモン管理はsystemdに依存し、Node.jsとShellツールチェーンはPOSIXシステム上でより成熟して動作する。

しかし現実は異なる物語を語っている：大多数のエンタープライズユーザーはWindowsで日常業務を行っている。StatCounterの2026年1月データによると、Windowsは世界のデスクトップOS市場シェアで依然として72%という圧倒的なシェアを保持している。OpenClawの能力を素早く検証したい技術意思決定者に対して、まずWSL2をインストールし、Ubuntuサブシステムをセットアップし、クロスシステムファイルアクセスやネットワークブリッジングの問題に対処することを要求する――この追加の技術的ハードルは、評価プロセスを遅延させるか完全に阻止するのに十分なことが多い。

本記事では、Windows 11 Pro（Build 26100）でのインストール、設定、トラブルシューティング、そしてDashboardへの接続成功までの完全な過程を、WSL2を一切使用せず、ネイティブPowerShell環境で記録する。これは理想化されたチュートリアルではなく、遭遇したすべての問題点とその解決策を含む、実際のインストールジャーナルである。

2. インストールプロセス：PowerShellワンラインコマンドからDoctor診断まで

2.1 ワンラインコマンドインストール

管理者としてPowerShellを開き、公式インストールスクリプトを実行する[1]：

iwr -useb https://openclaw.ai/install.ps1 | iex

インストーラーは以下のように動作する：

  1. OSの検出：Windows環境を認識
  2. Node.jsの確認：システムに既にインストールされたNode.js v24.13.1を検出し、Node.jsのインストールをスキップ
  3. OpenClawのインストール：npm install -g openclaw@latestでグローバルインストールを実行、バージョン2026.2.23
  4. Doctorの自動実行：インストール後に自動的にopenclaw doctorを実行して環境診断を行う

インストールプロセス全体は約30秒で、手動の介入は不要であった。

2.2 Doctor診断レポートの読み方

インストーラーが自動的にトリガーしたDoctorレポートは以下のステータスを示した：

openclaw doctor

[PASS] Node.js version: v24.13.1 (>= 22 required)
[PASS] openclaw version: 2026.2.23
[FAIL] Gateway not configured
[FAIL] Gateway not running
[FAIL] Gateway service not installed
[FAIL] OAuth directory missing
[FAIL] Session store directory missing
[WARN] Memory search needs embedding provider

6つのFAIL、1つのWARN。初回インストールとしては、これらの結果は完全に正常である――Gatewayはまだ設定されておらず、サービスは登録されておらず、OAuthとSessionディレクトリも作成されていない。これらはすべてopenclaw onboardインタラクティブセットアップウィザードが処理する項目である。注目すべきはMemory searchのWARN：セマンティック検索機能に追加のembeddingプロバイダー（OpenAIやローカルモデルなど）が必要であることを示しているが、基本的な動作には影響しない上級機能である。

3. Onboardインタラクティブセットアップ

Doctorがベース環境の準備完了を確認した後、インタラクティブセットアップウィザードを実行する：

openclaw onboard

openclaw onboardはTTYターミナルを必要とするインタラクティブプログラムである（これはSSHやヘッドレス環境で失敗する理由でもある――以前のデプロイガイドのピットフォール#1を参照）。ネイティブWindows PowerShellでは、インタラクティブウィザードは正常に動作し、以下のセットアップステップを順番にガイドする：

3.1 通信チャンネルのセットアップ――Telegram Bot

Onboardウィザードはどの通信チャンネルに接続するかを尋ねる。Telegramを選択し、事前に@BotFatherから取得したBot Tokenを入力した[6]。ウィザードは自動的にTokenを%USERPROFILE%\.openclaw\openclaw.jsonのchannels.telegramセクションに書き込み、Telegramプラグインを有効化する。

3.2 Gatewayモードの選択

ウィザードはGatewayの動作モードを尋ねる。localを選択した――Gatewayはローカルマシンで動作し、クラウドリレーは使用しない[2]。これはローカルテストに最も適したモードで、すべてのデータ転送がローカルネットワーク内に留まる。

? Gateway mode: local
Setting gateway.mode to local...

Onboard完了後、設定ファイルの準備が整った。しかし次のステップ――Dashboard起動による検証――が最初の大きな障壁となった。

4. Dashboardが開かない：Gateway起動問題の根本原因分析

4.1 症状の説明

Onboard完了後、以下を実行した：

openclaw dashboard

システムデフォルトブラウザがURLを開いた：

http://127.0.0.1:18789/#token=eyJhbGci...

しかしブラウザページはほぼ即座に閉じるか、接続失敗を表示した。何度試みても同じ結果であった。

4.2 根本原因分析

この現象の根本原因は、ブラウザの互換性問題でもトークンの期限切れでもない。問題は、Gatewayサービスが単純に動作していないことにある。

OpenClawのアーキテクチャを理解することが重要である[2]：openclaw dashboardコマンドはいかなるサービスも起動しない――単にブラウザを開き、URLをローカルWebSocketサーバー（ws://127.0.0.1:18789）に向けるだけである。Dashboardフロントエンドは、GatewayとWebSocket経由で通信する静的ページである。Gatewayがポート18789をリッスンしていなければ、ブラウザは当然接続を確立できず、ページは即座に失敗する。

これは見落としがちな暗黙の前提条件である：GatewayはDashboardの必須前提条件であるが、openclaw dashboardコマンドの出力はこれを明示的に示していない。

4.3 Gatewayサービスの起動を試みる

以下のコマンドを順に試した：

# 試行1：Gatewayサービスの起動
openclaw gateway start
# 出力：Gateway service missing

# 試行2：Gatewayサービスのインストール
openclaw gateway install
# 出力：Access is denied

最初のコマンドは、Gatewayサービスがまだ登録されていないために失敗した。2番目のコマンドは、openclaw gateway installが内部でWindowsのschtasksツールを呼び出してスケジュールタスクを作成するため[3]、schtasksに管理者権限が必要であるために失敗した。当時のPowerShellは管理者として実行されていなかった。

これはネイティブWindowsとLinux環境の重要な違いを明らかにしている：Linuxでは、OpenClawはsystemdを使用してデーモンサービスを管理し、ユーザーはsystemctl --userで非rootモードでサービスを登録できる。しかしWindowsでは、OpenClawはschtasksに依存しており、schtasks /Createは非管理者PowerShellでは常に拒否される。

5. Gatewayを起動する3つのパス

根本原因を特定した後、異なるシナリオに適した3つの実行可能なGateway起動パスを整理した：

パスA：フォアグラウンドモード（最もシンプル、テスト・検証用）

ターミナルでGatewayを直接フォアグラウンドモードで起動する：

openclaw gateway

Gatewayがフォアグラウンドで動作を開始し、ws://127.0.0.1:18789をリッスンする。ターミナルは継続的にログを出力し、ターミナルウィンドウを閉じるとサービスが停止する。これは最速の検証方法であり、管理者権限は不要で即座に使用可能である。

同じPowerShellで他の作業を続けたい場合は、Gatewayをバックグラウンドで実行できる：

# PowerShellバックグラウンド実行
Start-Job -ScriptBlock { openclaw gateway }

テスト中はこのパスを選択した。Gatewayが正常に起動した後、再度openclaw dashboardを実行すると、ブラウザにDashboardインターフェースが正常に表示され、Telegram接続ステータスは「ok」を示した――問題は完全に解決した。

パスB：システムスケジュールタスク（永続的、管理者権限が必要）

管理者としてPowerShellを開き、以下を実行する：

# 管理者として実行が必須
openclaw gateway install

このコマンドはschtasks /Createを呼び出してWindowsスケジュールタスクを作成し[3]、ユーザーのログイン時にGatewayを自動起動するように設定する。インストール後、GatewayはWindowsの起動時に手動介入なしで自動的に実行される。

スケジュールタスクが正常に作成されたことを確認する：

# OpenClaw関連のスケジュールタスクを確認
schtasks /Query /TN "OpenClaw*"

これは本番環境に推奨されるアプローチであるが、注意：Windowsアカウントに管理者権限がない場合（例：エンタープライズ環境の標準ユーザーアカウント）、このパスは利用できない。

パスC：NSSMまたはスタートアップスクリプト（代替手段）

schtasksが利用できないが永続化が必要なシナリオでは、サードパーティのサービスマネージャーNSSM (Non-Sucking Service Manager)を使用してopenclaw gatewayをWindowsサービスとして登録できる：

# NSSMダウンロード後
nssm install OpenClawGateway "C:\Program Files\nodejs\node.exe"
nssm set OpenClawGateway AppParameters "C:\Users\%USERNAME%\AppData\Roaming\npm\node_modules\openclaw\bin\openclaw gateway"
nssm set OpenClawGateway AppDirectory "C:\Users\%USERNAME%"
nssm start OpenClawGateway

または、最もシンプルな代替手段として、Windowsのスタートアップフォルダにバッチファイルを配置する：

# startup.batを作成し、shell:startupディレクトリに配置
@echo off
start /min cmd /c "openclaw gateway"

このファイルを%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ディレクトリに保存すると、Windowsログイン時にGatewayが自動起動する。

3つのパスの比較

パス管理者権限永続性ユースケース
A. フォアグラウンドモード不要なし（ターミナル終了で停止）クイックテスト、機能検証
B. schtasksスケジュール必要あり（起動時に自動開始）長期使用、本番環境
C. NSSM / スタートアップスクリプトNSSMは必要、スクリプトは不要あり管理者権限なしで永続化が必要な場合

6. Doctorレポートの読み方とさらなる最適化

Gatewayが正常に起動した後、再度openclaw doctorを実行してシステム状態を確認する：

openclaw doctor

[PASS] Node.js version: v24.13.1
[PASS] openclaw version: 2026.2.23
[PASS] Gateway configured (mode: local)
[PASS] Gateway running on ws://127.0.0.1:18789
[PASS] Gateway service installed
[WARN] OAuth directory missing
[WARN] Session store directory missing
[WARN] Memory search needs embedding provider

3つのWARNの解釈：

6.1 OAuth directory missing

OAuthディレクトリはサードパーティサービス（Google Calendar、Notion連携など）の認証トークンを保存する。これらのサードパーティ連携が不要であれば、この警告は安全に無視できる。必要な場合は、openclaw doctor --fixを実行すると必要なディレクトリが自動作成される。

6.2 Session store directory missing

セッションストアは会話セッションを永続化し、Gatewayの再起動後に進行中の会話を復元できるようにする。これもopenclaw doctor --fixで修正できる。テスト環境では、このディレクトリがないとGateway再起動後にすべての進行中の会話が失われるが、基本機能には影響しない。

6.3 Memory search needs embedding provider

これはエラーではなく機能的なリマインダーである。OpenClawのMemoryレイヤーはセマンティック検索に対応しており、十分な会話履歴が蓄積されると、AIが（キーワードマッチングではなく）セマンティック類似性を通じて過去の会話を検索できる。この機能を有効にするにはembeddingプロバイダーの設定が必要であり、例えば：

# OpenAIのembeddingモデルを使用
openclaw config set memory.embedding.provider openai
openclaw config set memory.embedding.model text-embedding-3-small

設定なしでもOpenClawは正常に機能する。セマンティック検索機能のみが利用できない。初回インストールと機能検証段階では、この項目はスキップすることを推奨する。

7. ネイティブWindows vs WSL2デプロイ判断マトリクス

ネイティブWindowsの完全なインストールプロセスを経た後、2つのデプロイパスのトレードオフを比較するための十分な実践データが得られた。以下の判断マトリクスは、チームがネイティブWindowsとWSL2の両環境での実際のデプロイ経験に基づいている：

評価項目ネイティブWindowsWSL2
インストールの複雑さ低い（PowerShell1行）中程度（まずWSL2有効化＋Ubuntuインストールが必要）
Gateway永続化schtasks（管理者が必要）またはNSSMsystemd（ネイティブサポート、root不要）
ファイルシステムアクセスネイティブNTFS、最高のパフォーマンスクロスシステムアクセスにレイテンシあり（/mnt/c/）
ブラウザ自動化システムのChrome/Edgeを直接使用ヘッドレスChromium＋Xvfbが必要
Skills互換性一部のUnixツールに代替手段が必要フルLinuxツールチェーンをサポート
ネットワーク設定システムネットワークを直接使用NATブリッジ、一部のポートに転送が必要
Docker連携Docker Desktopが必要ネイティブDockerエンジンをサポート
最適な用途技術意思決定者のクイック検証、非開発職長期デプロイ、フルLinuxツールチェーンが必要な開発者

推奨：30分以内にインストールを完了しOpenClawのコア機能（Dashboardコントロール、Telegram連携、基本会話）を検証することが目標であれば、ネイティブWindowsが最も抵抗の少ないパスである。長期的にOpenClawを運用し高度な機能（ブラウザ自動化、Claude Code連携、スケジュールタスク）を使用する予定であれば、WSL2がより完全なインフラサポートを提供する[4]。

注目すべきは、この2つのパスは相互排他ではないということである。多くのユーザーは実際に以下のように進める：まずネイティブWindowsでクイックインストールし、基本機能を体験し、OpenClawがニーズを満たすことを確認してから、WSL2環境に移行して正式にデプロイする。OpenClawの設定ファイル（openclaw.json）はWSL2環境に直接コピーして使用できる。

まとめ

このインストール過程を振り返ると、全体は1つの核心的な知見に凝縮される：GatewayはOpenClawのすべての機能の暗黙の前提条件であり、ネイティブWindows環境でのGateway起動パスはLinuxとは根本的に異なる。

インストール自体は痛みがない――PowerShellコマンド1つで完了する。Onboardインタラクティブセットアップもかなり直感的である。しかしOnboard完了からDashboardの接続成功までの間に、ドキュメントで十分にカバーされていないギャップがある：Gatewayサービスは独立して起動する必要があり、Windowsではサービス登録に管理者権限が必要である。この一見単純な権限の問題が、明確なエラーメッセージがない状況では、ユーザーがDashboardで繰り返し失敗するのに多大な時間を浪費させるのに十分である。

OpenClawは、急速にイテレーションが続くオープンソースプロジェクトとして[5]、ネイティブWindowsサポートは「使用可能だが洗練されていない」段階にある。インストーラーはWindows環境を正しく検出しインストールを完了し、Onboardウィザードはpowershellで動作し、コア機能（Gateway、Dashboard、Telegram連携）はすべてネイティブWindowsで機能する――しかし、これらの機能を取り巻くエラーハンドリング、プロンプトメッセージ、ドキュメンテーションのカバレッジには、まだ明確な改善の余地がある。

AIエージェントツールを評価している技術意思決定者にとって、本記事は現場で検証済みのネイティブWindowsデプロイパスを提供する。チームがOpenClawをAI自動化戦略の評価に含めることを検討している場合は、当社リサーチチームにお気軽にご連絡いただきたい――OpenClawのWindowsプラットフォームサポートの進捗とベストプラクティスを引き続き追跡していく。