OpenClawパーソナルゲートウェイの設定：インストール、初期設定、ダッシュボード

OpenClawは、AIエージェント向けのセルフホスト型マルチチャネルゲートウェイです。1つのGatewayプロセスを動かし、セッション、チャネルプラグイン、ツールのコントロールプレーンとして使います。Discord、Google Chat、iMessage、Matrix、Microsoft Teams、Signal、Slack、Telegram、WhatsApp、Zaloなどのチャネルプラグインからメッセージを送り、エージェントの応答を受け取れます。日々の作業をホスト型チャットボットSaaSへ預ける必要はありません。

ドキュメント：docs.openclaw.ai。Webサイト：openclaw.ai。ライセンス：MIT。非営利のOpenClaw Foundationとともにオープンに開発されています。

この記事では、パーソナルゲートウェイを動かします。次の記事では、許可リストとペアリング、スキル、heartbeat、承認を説明します。OpenClawとHermesのどちらを選ぶべきかは、仕事別の選び方を参照してください。

ツールを有効にしたばかりのゲートウェイは強力です。シェル、ファイル、ブラウザーを操作できるため、ボットにメッセージを送れる第三者が、安全でない操作を誘導するおそれがあります。インストール後、公開チャネルの接続やelevatedツールの有効化_より前に_、許可リストとペアリングを設定してください。OpenClawのセキュリティーガイドも参照してください。

Gatewayの役割：メンタルモデル

チャットアプリ + プラグイン → Gateway → エージェントセッション / ツール
                                  ↘ Control UI（ブラウザー）
                                  ↘ CLI

Gatewayは、セッション、ルーティング、チャネル接続の唯一の信頼できる情報源です。ブラウザーのControl UIは、チャット、設定、セッションの確認に使います。設定ファイルは既定で~/.openclaw/openclaw.jsonにあります。

OpenClawは、互いに敵対し得る利用者が1つのエージェントを共有するためのマルチテナントセキュリティー境界ではありません。文書化された信頼モデルでは、1つのゲートウェイにつき1つの信頼済み運用者境界を想定しています。複数の信頼境界は別々のゲートウェイとしてホストし、可能ならOSユーザーまたはホストも分けてください。

Nodeのバージョン要件

現行のNodeインストールドキュメントは、Node 22.22.3+、24.15+、または**25.9+**を要求しており、Node 26も含まれます。Node 26が文書化された既定かつ推奨ランタイムです。Node 23は非対応です。下限は変わるため、古い記録をコピーせず、インストール当日にGetting StartedとNodeのページを再確認してください。

インストールと初期設定

現行のGetting Startedに従います。

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon

onboard --install-daemonは対話型の初期設定を実行し、Gatewayをデーモンとしてインストールします。これにより、各プラットフォームのサービスモデルに従い、ログアウトや再起動後も動作できます。

選択したプロバイダーのAPIキー、またはローカルモデル設定が必要です。ツールを使うボットには、強力な最新世代モデルを優先してください。能力の低いモデルは、ソーシャルエンジニアリングによって危険なツール利用へ誘導されやすいためです（セキュリティー指針）。

初期設定後にopenclaw security auditを実行し、実環境へプローブする準備ができたら--deepも使ってください。個人用の本番環境として扱う前に、受信アクセスとネットワーク公開に関する指摘を修正します。

Control UIを開く

既定のローカルダッシュボード：

http://127.0.0.1:18789/

または、次を実行します。

openclaw dashboard

UIから最初のメッセージを送り、セッションを確認し、Gatewayが稼働していることを確かめます。認証済みのリモートアクセスを意図して設定した場合を除き、Control UIはループバックに限定してください。Tailscaleなどの方式はOpenClawのリモートアクセス指針に記載されています。:18789を認証なしでWANへ公開してはいけません。

セキュリティードキュメントにある強化案には、gateway.mode: "local"、bind: "loopback"、ゲートウェイのトークン認証が含まれます。閉じた状態から始め、意図して開放してください。

設定ファイルとバックアップ

既定の設定ファイルは~/.openclaw/openclaw.jsonです。認証情報とペアリング状態も~/.openclaw/以下に保存されます。実験の前に、次を行います。

1. 設定ファイルを日付付きでコピーし、チームと共有する同期フォルダーの外に保管する。
2. バックアップの横にNodeバージョン（node -v）を記録する。
3. リモートアクセスの変更に失敗したら、チャネルを開いたままデバッグせず、バックアップを復元してデーモンを再起動する。

実際のトークンをGitへコミットしてはいけません。複数の運用者が構成を知る必要がある場合は、機密情報を削除した設定例をランブックへ保存します。

よくあるインストール上の問題

迷った場合は、フォーラムの俗説ではなく、公式のGetting Startedとトラブルシューティングから確認してください。

プロバイダーとモデルの設定

初期設定では、クラウドプロバイダーのAPIキー、またはローカルやOpenAI互換のベースURLをエージェントへ指定します。実用上の規則は次のとおりです。

• ツールを有効にする場合は、費用を払う、またはホストする意思のある範囲で、最も強力な現行モデルを使います。OpenClawのセキュリティードキュメントは、ツールを使うボットに、現代的で指示耐性を強化したモデルを明示的に推奨しています。
• ローカルエンドポイントを使う場合は、n8n → ローカルOpenAI互換エンドポイントと同じ非公開ネットワークと認証の原則を適用します。
• キーをチャットログやコミット対象の設定例に残しません。

モデル選びは後から調整できます。モデルを試す間も、ペアリングや許可リストの設定を先送りしないでください。

デーモン、更新、診断

--install-daemonが重要なのは、ターミナルにひも付いたGatewayはターミナルやSSHセッションが終了すると停止する一方、プラットフォームのサービスマネージャーならログインや再起動をまたいでGatewayを起動または再起動できるためです。スリープ中のノートパソコンは、デーモン化してもメッセージを処理できません。選んだインストール方式に対応するアップデーターを使い、パッケージマネージャーの状態を不用意に混在させないでください。更新後は、対応する診断を実行します。

openclaw doctor --fix   # when docs recommend it for config/monitor drift
openclaw security audit

NodeやOpenClawのメジャーバージョンを上げる際はリリースノートを読みます。リモートアクセスを試した後は、Control UIのポートと認証設定を再確認してください。

最初のチャネルを安全に接続する

個人用のスモークテストでは、Telegramが最も早く接続できることがよくあります。その場合は、次の手順を使います。

1. Telegram向けの現行OpenClaw手順に従ってボットトークンを作成する。
2. 所有者が1人のボットでは、dmPolicy: "allowlist"を優先し、allowFromに自分の数値TelegramユーザーIDを明記する。
3. 既定のpairingフローも初期設定に使える。利用する場合は、openclaw pairing list telegramとopenclaw pairing approve telegram <code>で自分を承認する。
4. ペアリングの範囲を限定的に理解する。付与されるのはDMアクセスだけである。コマンド所有者が未設定の場合、最初に承認したペアリングがcommands.ownerAllowFromを初期化することもある。グループ認可は引き続き明示的な設定上の許可リストで決まる。
5. 最初のスモークテストではグループを禁止する。後から有効にする場合は、安定したグループチャットIDをchannels.telegram.groupsに置き、送信者IDをallowFromまたはgroupAllowFromに残し、requireMention: trueを維持する。

現行のチャネル指針とexecポリシーを組み合わせた、強化済みTelegram初期設定の例です。送信者IDを置き換え、最新ドキュメントも開いたまま作業してください。

{
  channels: {
    telegram: {
      enabled: true,
      dmPolicy: 'allowlist',
      allowFrom: ['123456789'],
      groupPolicy: 'allowlist',
      groups: {},
    },
  },
  session: { dmScope: 'per-channel-peer' },
  gateway: {
    mode: 'local',
    bind: 'loopback',
    auth: { mode: 'token', token: 'replace-with-a-secret-reference' },
  },
  tools: {
    profile: 'messaging',
    deny: [
      'group:automation',
      'group:runtime',
      'group:fs',
      'sessions_spawn',
      'sessions_send',
    ],
    fs: { workspaceOnly: true },
    exec: { mode: 'deny' },
    elevated: { enabled: false },
  },
}

詳細と障害モードは、許可リストとペアリングで説明します。

スモークテストの手順

1. http://127.0.0.1:18789/を開き、Control UIで自分に「ping」と送る。
2. セッションが表示され、モデルが応答することを確認する。
3. DMチャネルを1つ接続し、明示的な許可リストに入れた主要IDからエージェントへメッセージを送れることを確認する。意図してペアリングをテストする場合は、先にその主要IDを承認する。
4. 自分が管理する二つ目のIDからメッセージを送る。dmPolicy: "allowlist"の場合は拒否されることを確認する。pairingをテストする場合は、要求を未承認のままにして、ツールを使えるターンを開始できないことを確認する。
5. openclaw security auditを実行し、open+toolsまたは公開バインドと示された項目を修正する。

手順4が開放側に失敗し、未知の送信者がツール付きの完全なエージェントターンを得た場合は、以後の連携作業を止め、先にDMポリシーを修正してください。

n8n、Hermesとの位置関係

三者は共存できます。評価対象となる構成例は、n8nで定期チェックを行い、Hermesが判断し、厳しい許可リストを設定したOpenClawから当番チャットを利用する形です。HermesはOpenAI互換のAPIサーバーと、独立した署名イベント用のwebhookアダプターを公開します。両者を同じものとして扱わず、1つの契約を選んで文書化してください。

NVIDIAのNemoClawプラットフォーム対応表は、OpenShellを基盤とする別の早期プレビュー版アルファを説明しています。現時点ではOpenClawとHermesのエージェント経路をテスト済みとしつつ、プラットフォーム、推論、導入の各行には個別の制約があります。NemoClawはこのノートパソコン構成の前提条件ではなく、NVIDIAは本番SLAを提供していません。

個人用セットアップのチェックリスト

• 対応するNodeバージョンをインストール済み
• 公式インストーラー、または文書化された別のインストール方法が成功
• openclaw onboard --install-daemonが完了
• 127.0.0.1:18789でControl UIが開く
• openclaw security auditの結果を確認済み
• 最初のチャネルに明示的なDM許可リスト、または意図して承認したペアリングを使用。グループ認可は別に設定
• GatewayやモデルのポートをWANへバインドしていない
• プロバイダーのキーをチャット履歴ではなくシークレットとして保存
• 二つ目のテストIDは、承認前にツールへ到達できない

チャネル履歴、添付ファイル、ツール出力は、~/.openclaw以下のGateway状態に保存される場合があります。このディレクトリーはメールボックス兼認証情報ストアとして扱ってください。ディスクを暗号化し、ファイル権限を厳しくし、明示的な判断なしに状態ディレクトリーを共有クラウドフォルダーへ同期しないでください。

初日に「完了」と呼べる状態

ダッシュボードを開き、自分とのDMを1回完了して、セッションを確認できます。ただし、ペアリングや許可リストを設定し、エージェントが呼び出せるツールを理解するまでは「完了」ではありません。セキュリティーチェックを通していないセットアップはデモにすぎません。

次は、IDとグループを制限し、シェルとブラウザー操作に厳しいポリシーを設定した上で、スキルとheartbeatを追加します。