OpenClaw API Key とモデル設定
2026 インストール・設定の完全チュートリアル
OpenClaw のインストールが終わっても、モデルがつながっていなければ中身のないシェルに過ぎません。API Key の誤入力、ローカル推論サービスの未起動、タスクに合わないデフォルトモデル、ネットワーク不通——どれも「OpenClaw 自体が壊れた」ように見えます。本記事は 2026 年のインストールから初回検証までの完全チュートリアルのまま、モデル・キー・初回受け入れのチェーンを厚く解説します。クラウドとローカルの使い分け、キーの安全な保管、Dashboard でモデル呼び出しを確認する手順まで一通り扱います。
Key → provider → モデル名 → ネットワーク → ログ
Dashboard とプローブの入口
クラウド／ローカル／ハイブリッド
1インストール完了 ≠ モデルが呼べる
OpenClaw が実際に使えるかは、npm install -g openclaw が成功したかより、モデル経路がつながっているか、キーが安全に保管されているか、デフォルトモデルがタスクに合っているかの方がはるかに重要です。ゲートウェイが動き、ポート 18789 のプローブが通っても「シェルが立った」だけです。実作業には有効な provider/model 参照と認証が必要です。以下では、完全インストールの流れの中でそのチェーンを順にたどります。
openclaw models status や最小の Agent 呼び出しを行い、ログで上流 HTTP とトークン消費を確認してください。
2インストール前：モデルとキーの準備
着手前に：① 使用中の OpenClaw バージョンがサポートする provider 一覧（公式ドキュメントで確認）；② クラウド API Key と正しい環境変数名；③ ローカル推論を使う場合は、互換 HTTP エンドポイントが待ち受け済みでメモリに余裕があること；④ provider API または localhost ポートへの到達性。ハイブリッド構成では、ゲートウェイを動かすマシンと推論を動かすマシンを明確に分けてください。
3公式インストールと onboard
Node 24 と CLI を入れたら openclaw onboard（必要なら --install-daemon）でデフォルトモデルとゲートウェイを設定します。node -v を確認し、launchd が環境変数を引き継ぐことも確認してください。再起動後にキーが消える典型原因です。Node 24 と 18789 の詳細は
冷起動手順を参照してください。
4クラウドモデルと API Key
組み込み provider は多くの場合、認証だけで足ります：openclaw onboard --auth-choice openai-api-key（フラグはウィザードに従う）、または export OPENAI_API_KEY="sk-your-placeholder" のあと openclaw models set provider/model。カスタムプロキシでは models.providers を定義し、キーは ${ENV} プレースホルダで参照し、リテラルは使わないでください。確認は openclaw models status。
5ローカルモデルの接続
ローカル推論はプライバシーとコスト管理に向きますが、速度はハードウェア次第です。models.providers でローカルの baseUrl（例：http://127.0.0.1:PORT/v1）とモデル id を指定します。先に curl でエンドポイントを叩き、通ってから OpenClaw を起動してください。
6Dashboard でモデル状態を受け入れる
| 確認項目 | クラウドモデル | ローカルモデル | ハイブリッド |
|---|---|---|---|
| 認証 | models status で provider 認証済み |
キー不要、または内部トークンのみ | 両方の設定が status に表示されること |
| 接続 | provider API への外向き到達性 | ローカル baseUrl を curl |
経路ごとに個別プローブ（切り分けを混ぜない） |
| Dashboard | 18789 正常＋セッションに上流リクエスト | ログにローカル HTTP 呼び出し | 主モデルはクラウド、機密処理はローカルよくある |
| コスト／プライバシー | 従量課金、データは外部へ | 電力とハード、データは端末内 | タスクごとに経路を定義 |
Dashboard は既定で 127.0.0.1:18789 のゲートウェイ状態とログを表示します。ページは開くが応答がない場合は、表の行を上から順に確認してください。
7初回実戦：スモークテスト
openclaw agent --local --session-id smoke-test --message "Reply only: model OK" --timeout 90 — JSON に想定の provider／model が出て、ログに外向きリクエストがあればモデルチェーンは問題ありません。ファイル書き込みや権限エラーは別レイヤで切り分けます。
8モデル障害とインストール障害の見分け
openclaw models list で provider/model の綴りを確認。カスタム provider は models.providers.*.models[].id を照合。lsof -iTCP:18789 と launchd を確認。モデル API の問題ではないため、先にキーをローテーションしない。9運用・メンテナンス
キーは定期ローテーション、カタログ変更は models list で追跡、課金はダッシュボードで監視します。provider を追加したら openclaw models set でデフォルトの primary モデルを更新し、権限は段階的に広げてください。
- 1インストール前にキー・ネットワーク・（任意で）ローカルエンドポイントを準備
- 2受け入れは四段階：
onboard→models status→ Dashboard → 最小 Agent - 3切り分け順：キー → provider → モデル名 → ネットワーク／ローカルサービス → ログ
- 4秘密情報はコミットしない。モデル問題とポート／権限問題を混同しない
Mac mini ならモデルチェーンが組みやすい
macOS 上ではゲートウェイとローカル推論が一本道になります。Node 24、launchd、環境変数の継承が揃い、キーが再起動後も残りやすい構成です。Mac mini M4 のユニファイドメモリは中規模ローカルモデルの試行に向き、待機電力はおおよそ 4W で 24 時間ゲートウェイ向きです。Gatekeeper／FileVault はキー露出のリスクを下げます。onboard と Dashboard の受け入れを安定させたいなら、Mac mini M4 はこのスタックを載せる現実的な選択です。今のうちにハードを揃えておくと、以降のモデル更新や Key ローテーションも楽になります。