yuan-lab-llm--clawmanager/docs/use_guide_ja.md

<- README トップへ戻る

ClawManager デプロイとクイックスタートガイド

目次

• 一、環境と目標
• 二、デプロイ方式の概要
• 三、方式 A：k3s を使用したデプロイ
• 四、方式 B：標準 Kubernetes を使用したデプロイ
• 五、中国国内ネットワークでのイメージ取得に関する推奨事項（任意）
• 六、ClawManager のデプロイ
• 七、Web ページの起動
• 八、クイックスタートガイド（ログイン後に初期化して OpenClaw インスタンスを作成）
• 九、コンソールと AI Gateway のその他の機能説明
• 十、ワークスペースモジュールの説明
• 10.4 Team 協働
• 十一、問題と対処のクイックリファレンス
• 十二、推奨される最終確認手順（セルフチェック用）

一、環境と目標

• 想定システム：x86_64 アーキテクチャの Linux サーバー。
• デプロイ目標：ClawManager をデプロイし、Web ページ上でセキュアモデル設定を完了した後、OpenClaw Desktop インスタンスを作成して起動すること。
• 適用シナリオ：
  • 方式 A：k3s 単一ノード / 軽量クラスター構成
  • 方式 B：標準 Kubernetes クラスター構成（kubeadm クラスター、企業内 K8s クラスター、クラウド上の K8s クラスターなど）

---

二、デプロイ方式の概要

以下の 2 つの方式のいずれかでデプロイできます：

方式 A：k3s デプロイ

単一ノード、テスト環境、または軽量な本番環境に適しています。

方式 B：標準 Kubernetes デプロイ

標準 Kubernetes クラスターをすでに備えているサーバー環境に適しています。

どの方式を使用しても、最終的には同じ ClawManager マニフェストを適用します：

kubectl apply -f deployments/k8s/cluster/clawmanager.yaml

---

三、方式 A：k3s を使用したデプロイ

3.1 k3s のインストール

curl -sfL https://get.k3s.io | sh -

中国国内ネットワークでは、ミラーソースを使用してインストールできます：

curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh |   INSTALL_K3S_MIRROR=cn sh -

3.2 サービス状態の確認

sudo systemctl status k3s --no-pager
sudo systemctl enable k3s

3.3 kubectl の設定

現在のユーザーで kubectl を直接使用できない場合は、次を実行します：

mkdir -p ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown "$USER:$USER" ~/.kube/config

または一時的に指定します：

export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

3.4 クラスターの検証

kubectl get nodes

通常、ノードが Ready 状態で表示されます。

---

四、方式 B：標準 Kubernetes を使用したデプロイ

すでに利用可能な Kubernetes クラスターがある x86 サーバー環境に適用されます。

4.1 前提条件の確認

現在の kubectl が対象クラスターに接続されていることを確認します：

kubectl get nodes
kubectl get ns

通常、少なくとも 1 つの Ready ノードが表示されます。

4.2 デフォルト StorageClass の確認

ClawManager の MySQL と MinIO では永続ストレージが必要です。まず、クラスターにデフォルト StorageClass があるか確認することを推奨します：

kubectl get storageclass

クラスターにデフォルトのストレージクラスがすでにある場合は、そのままデプロイを続行できます。

デフォルト StorageClass がない 場合は、事前に利用可能な PV / PVC を準備するか、ローカルパスストレージ方式を使用することを推奨します。そうしないと、後続で次のようなエラーが発生する可能性があります：

pod has unbound immediate PersistentVolumeClaims

---

五、中国国内ネットワークでのイメージ取得に関する推奨事項（任意）

サーバーから Docker Hub またはその他の公開レジストリへのアクセスが遅い場合は、イメージ高速化を設定できます。

5.1 k3s シナリオ：/etc/rancher/k3s/registries.yaml を設定する

mirrors:
  docker.io:
    endpoint:
      - "https://docker.m.daocloud.io"
      - "https://docker.nju.edu.cn"
      - "https://docker.1ms.run"
  quay.io:
    endpoint:
      - "https://quay.mirrors.ustc.edu.cn"
  gcr.io:
    endpoint:
      - "https://gcr.mirrors.ustc.edu.cn"
  k8s.gcr.io:
    endpoint:
      - "https://registry.aliyuncs.com/google_containers"

変更後に実行します：

sudo systemctl restart k3s

5.2 イメージ取得の確認

sudo k3s crictl pull docker.io/rancher/mirrored-pause:3.6

---

六、ClawManager のデプロイ

6.1 プロジェクトコードの取得

git clone https://github.com/Yuan-lab-LLM/ClawManager.git
cd ClawManager

6.2 デプロイマニフェストの適用

リポジトリのルートディレクトリで実行します：

kubectl apply -f deployments/k8s/cluster/clawmanager.yaml

6.3 基本リソースの確認

kubectl get ns
kubectl get pods -n clawmanager-system
kubectl get svc -n clawmanager-system

通常、以下のコンポーネントが表示されます：

• clawmanager-app
• mysql
• minio
• skill-scanner

次のエラーが表示された場合：

0/1 nodes are available: pod has unbound immediate PersistentVolumeClaims

これは、クラスターのストレージで MySQL / MinIO が PVC 未バインドのため起動できないことを意味します。文末の次の項目へ直接移動してください：

• 十一.1 ストレージ問題の専用対応（PV/PVC）

---

七、Web ページの起動

7.1 NodePort 経由でアクセス

ClawManager のフロントエンド Service はデフォルトで HTTPS NodePort を使用します。まず確認します：

kubectl get svc -n clawmanager-system

フロントエンドのポートが次の場合：

443:30443/TCP

ブラウザから直接次へアクセスできます：

https://<サーバーIP>:30443

7.2 初回 HTTPS アクセス時の説明

通常は自己署名証明書のため、ブラウザに「安全ではない」または証明書警告が表示される場合があります。以下をクリックします：

詳細設定 → 続行してアクセス

これでページに入れます。

---

八、クイックスタートガイド（ログイン後に初期化して OpenClaw インスタンスを作成）

上記のデプロイを完了して管理ページを正常に開いた後、実際に OpenClaw インスタンスを作成して起動するには、さらに以下の初期化手順を完了する必要があります。

8.1 システムにログイン

1. デプロイ後のページを開きます。例：https://<ノードIP>:30443。
2. デフォルトの管理者アカウントでログインします：
   • ユーザー名：admin
   • パスワード：admin123
3. 初回ログイン後は、必要に応じてデフォルトパスワードを変更することを推奨します。

8.2 セキュアモデルの設定（AI Gateway）

ログイン後、まず利用可能な セキュアモデル を設定する必要があります。これはプラットフォームおよび後続インスタンスで共通して使用されます。

1. 左側メニューの AI Gateway → モデル をクリックします。

2. 新しいモデルを追加するか既存モデルを編集し、接続するモデルサービスに応じて次の情報を入力します：

   • 表示名：識別しやすい名前を入力します。
   • ベンダーテンプレート：モデルサービスの種類に応じて該当テンプレートを選択します。カスタムまたは互換インターフェースを使用する場合は Local / Internal を選択できます。
   • プロトコル：インターフェースのプロトコルに応じて、OpenAI Compatible またはその他の実際のプロトコルを選択します。
   • Base URL：モデルサービスが提供するインターフェースアドレスを入力します。
   • API Key：対応するモデルサービスの有効なキーを入力します。
   • Provider Model：実際に呼び出すモデル名を入力します。
   • 通貨：実際の状況に応じて入力します。課金表示が不要な場合はデフォルトのままでも構いません。
   • 入力価格 / 出力価格：課金統計を行わない場合は 0 を入力できます。

3. 送信前に必ず次にチェックを入れてください：

   • セキュアモデル
   • 有効化

4. 保存 をクリックします。

注：ページ内の画像は、入力位置と例示形式を示すためのものです。実際の内容は、使用するモデルサービスの設定に従ってください。

8.3 OpenClaw インスタンスを作成

モデル設定の完了後に、OpenClaw Desktop インスタンスを作成します。

1. 左下の ADMIN をクリックし、ワークスペース に切り替えます。
2. インスタンスを作成 をクリックします。

ステップ 1：基本情報

• インスタンス名 を入力します（3 文字以上）。
• 説明は任意で、空欄でも構いません。
• 次へ をクリックします。

ステップ 2：タイプを選択

• OpenClaw Desktop を選択します。
• 次へ をクリックします。

ステップ 3：設定

• Small 仕様を直接選択できます：
  • 2 CPU
  • 4 GB RAM
  • 20 GB Disk
• 下部のカスタム設定で必要に応じて変更することもできます。
• OpenClaw リソース注入セクションでは、必要に応じて以下を選択できます：
  • 手動リソース
  • リソースパック
  • アーカイブ導入
• 初回利用時は、デフォルトのままにするか 手動リソース を選択してください。
• 最後に 作成 をクリックします。

8.4 初回作成時の説明

• OpenClaw インスタンスを初めて作成するときは、必要なイメージのダウンロードと環境の初期化が行われるため、明らかに時間がかかります。
• ネットワークが遅い場合や初回のイメージ取得時には、インスタンスの状態が長時間 作成中 と表示されることがあります。しばらくお待ちください。
• 長時間経っても起動しない場合は、Kubernetes / Docker ログに戻って、イメージ、PVC、Gateway モデルなどの問題を確認してください。

---

九、コンソールと AI Gateway のその他の機能説明

モデル設定に加えて、プラットフォームのホームページコンソールと AI Gateway には、監査、コスト、ルールガバナンスなどの機能もあり、管理者がクラスター状態、モデル呼び出し記録、およびセキュリティポリシーの実行状況を一元的に確認しやすくなっています。

9.1 コンソール概要

コンソールのホームページは、現在のクラスターとプラットフォームの全体的な稼働状況を表示し、管理者がリソース使用状況とシステム健全性を素早く把握できるようにするためのものです。

主に以下の情報が含まれます：

• クラスター基本情報の概要：現在のプラットフォームのユーザー総数、インスタンス総数、稼働中インスタンス数、総ストレージ使用量を表示します。
• ノード概要：現在利用可能なノード数と、現在のクラスターにおける主要スケジューリングノード情報を表示します。
• リソース申請状況：現在のプラットフォームで申請済みの CPU、メモリ、ディスクリソースの総量を表示します。
• 容量ダッシュボード：ノード、CPU、メモリ、ディスクなどの観点で全体リソース容量と現在の使用率を表示し、クラスターに利用可能な余裕があるかを判断しやすくします。
• インフラストラクチャテーブル：現在のノード、リソース、および基本実行環境の状態情報を表示するために使用します。

注：コンソールは主にプラットフォーム全体のリソース、ノード、インスタンス稼働状況を確認するためのものであり、特定インスタンス内の OpenClaw 操作には直接使用しません。

9.2 セキュリティセンター（skill-scanner）

コンソールの セキュリティセンター は、プラットフォーム資産のスキャン状態、履歴レポート、およびスキャナー設定を一元的に確認するために使用されます。これはバックエンドの skill-scanner サービスに依存して動作し、資産に対する静的スキャン、深度スキャン、および LLM に基づく補足分析を行うことで、管理者が潜在的なリスクコンテンツ、異常な資産、および疑わしいスキルを識別できるよう支援します。

セキュリティセンターには現在、主に以下の 3 つのモジュールがあります。

• 実行概要
• レポート履歴
• スキャナー設定

9.2.1 実行概要

「実行概要」ページは、現在のプラットフォーム全体のスキャン状況とリスク分布を確認するために使用され、管理者が現在のセキュリティ状況を迅速に把握するのに役立ちます。

ページには主に以下の内容が含まれます。

• 現在有効なモード：現在使用されているのが Quick モード か Deep モード かを表示します。

• クイックスキャン / 全量スキャン：

  • クイックスキャン：新規追加または変更された資産の処理に適しており、スキャン範囲が軽く、実行速度が速いです。
  • 全量スキャン：定期的にすべての資産を再スキャンし、プラットフォーム上の全資産の状態を完全に再確認するのに適しています。

• 資産総数：現在セキュリティセンターのスキャン対象となっている資産数。

• スキャン完了数：スキャンが完了した資産数。

• 高リスク / 中リスク：現在のスキャン結果で識別されたリスクレベルの統計。

• スキャンカバレッジ：実際にスキャンが完了した資産数が、プラットフォーム総資産数に占める割合を表示します。

• SAFE / 高リスク / 待機中 / 失敗：

  • SAFE：スキャンに合格し、現時点でリスクが検出されていない資産数
  • 高リスク：直ちに対処が必要なリスク資産数
  • 待機中：証拠取得待ち、またはスキャン待ちキューに入っている資産数
  • 失敗：スキャン実行に失敗し、再実行が必要な資産数

• プラットフォーム資産リスク動向：リスクレベル別に集計した現在のプラットフォーム資産のリスク分布を表示します。

• ホット資産：最も頻繁に使用されているスキルや高頻度利用資産を表示し、管理者が重点資産を素早く特定できるようにします。

• スキャナー状態：現在の skill-scanner の利用可否と接続状態を表示します。たとえば「静的スキャン利用可」「接続済み」などです。

• リスク通知と対処提案：現在のリスク状況に応じた簡潔な通知情報を表示します。

• 最近のスキャンタスク：最近実行されたスキャン記録を表示し、直近のスキャン活動を振り返りやすくします。

説明：

• ページに「現在、高リスクまたは中リスク資産はありません」と表示される場合、現在のスキャン結果では重大なリスクが見つかっていないことを意味します。
• ページに「まだスキャンタスク記録がありません」と表示される場合、まだスキャンが実行されていない、または有効なスキャン結果が生成されていないことを意味します。

9.2.2 レポート履歴

「レポート履歴」ページは、過去のスキャンレポートおよび関連結果記録を確認するために使用され、管理者が過去のスキャン実行状況を振り返りやすくします。

このモジュールは主に以下の用途で使用されます。

• 過去に実行されたスキャンタスクの結果を確認する
• 異なる時点でのスキャン出力を比較する
• 特定資産の各段階におけるセキュリティ変化を補助的に追跡する
• 今後のレビュー、再スキャン、および問題切り分けのための履歴的根拠を提供する

説明：

• 「レポート履歴」は履歴結果の保存と追跡により重点があります；
• 「実行概要」は現在状態と全体概要により重点があります。

9.2.3 スキャナー設定

「スキャナー設定」ページは、skill-scanner の動作方式、LLM 関連設定、および quick / deep の 2 つのスキャン戦略を管理するために使用されます。保存後は Deployment rollout がトリガーされ、新しい設定が有効になるまで待機します。

ページには主に以下の内容が含まれます。

（1）skill-scanner サービス状態

• 現在のバックエンドスキャンサービスの namespace、Deployment 名称、および接続状態を表示します。
• ページに 接続済み、静的スキャン利用可 と表示される場合、基本的な静的スキャン機能が利用可能であることを示します。

（2）LLM 設定

このエリアでは、scanner が必要に応じてモデルベースの分析を実行できるよう、主 LLM を設定します。

主なフィールドは以下の通りです。

• 主 LLM 統合：AI Gateway に設定済みのモデルから主 LLM 設定を直接読み込めます。
• LLM API Key：SKILL_SCANNER_LLM_API_KEY に対応し、主 LLM analyzer の認証に使用されます。
• LLM Model：SKILL_SCANNER_LLM_MODEL に対応し、具体的なモデル名などを指定します。
• LLM Base URL：SKILL_SCANNER_LLM_BASE_URL に対応し、主 LLM サービスのアドレスを設定します。

（3）Meta LLM 統合

このエリアでは、meta analyzer が使用するモデルを設定します。通常、findings のさらなる要約、整理、または二次処理に使用されます。

主なフィールドは以下の通りです。

• Meta LLM 統合：AI Gateway に設定済みのモデルから meta analyzer 設定を直接読み込めます。
• Meta LLM API Key：SKILL_SCANNER_META_LLM_API_KEY に対応します。
• Meta LLM Model：SKILL_SCANNER_META_LLM_MODEL に対応します。
• Meta LLM Base URL：SKILL_SCANNER_META_LLM_BASE_URL に対応します。

説明：

• 現在 LLM が未設定の場合、ページには通常、現時点では静的スキャンのみ対応している旨が表示されます；
• 主 LLM と Meta LLM の両方を設定した後にのみ、scanner はより完全な意味解析と要約機能を有効にできます。

（4）現在のスキャンモード

ページでは、現在プラットフォームで実際に採用しているスキャンモードを選択できます。

• Quick モード：quick analyzers を使用してスキャンを実行し、日常的な高速チェックに適しています。
• Deep モード：deep analyzers を使用してスキャンを実行し、より完全かつ深い分析に適しています。

注意すべき点は以下です。

• Dashboard 上の「クイックスキャン」と「全量スキャン」は、どちらもここで選択したスキャン強度を使用します；
• 両者の違いは主にスキャン範囲にあり、analyzer の深さそのものではありません。

（5）Quick / Deep スキャン戦略

ページ下部では Quick と Deep の 2 つのスキャン戦略設定をそれぞれ管理しており、管理者が異なるシナリオに応じて異なる analyzer の組み合わせを選択できるようになっています。

各戦略には以下の設定項目があります。

• タイムアウト（秒）：現在のモードにおけるスキャンタスクのタイムアウト時間を設定します。
• 呼び出し方法：必要に応じて異なる analyzer を有効または無効にできます。

現在表示されている analyzer タイプには以下が含まれます。

• Static：YAML + YARA 静的ルールスキャン
• Bytecode：Python bytecode の完全性検証
• Pipeline：コマンドチェーンおよび taint 分析
• Behavioral：AST ベースの挙動およびデータフロー分析
• LLM：外部 LLM に依存する意味解析
• Meta：findings の二次要約分析

通常、以下のように理解できます。

• Quick モード：より高速な実行を重視し、日常的な増分チェックによく使われます
• Deep モード：より多くの analyzer を有効にでき、より深いレビューやセキュリティ監査に適しています

（6）保存して適用

ページ右上の 保存して適用 は、現在の scanner 関連設定をまとめて送信するために使用されます。保存後は以下が行われます。

• ClawManager 内の quick / deep スキャン戦略を更新する
• skill-scanner Deployment の関連環境変数を更新する
• rollout 完了を待って新しい設定を正式に有効化する

説明：

• スキャナー設定を変更した後は、新しいスキャンタスクを実行する前に、設定が完全に有効になるまで待つことを推奨します；
• 設定後に接続状態が異常になった場合は、AI Gateway モデル、LLM アドレス、Key、および Deployment rollout 状態を優先的に確認してください。

9.3 AI Gateway 機能概要

AI Gateway には「モデル」設定以外にも、以下のモジュールがあります。

• AI 監査：モデル呼び出し Trace、リクエストとレスポンスのペイロード、命中したリスク、ルーティング判断、および呼び出し詳細を確認します。
• コスト：Token 使用量、推定費用、内部コスト、およびトレンド統計を確認します。
• リスク制御ルール：機微検出ルールを設定し、命中時に許可するか安全モデルへルーティングするかを制御します。

9.4 コストモジュール

コストページは、プラットフォーム上のモデル呼び出しに関する費用と Token 使用状況を統計し、管理者が全体の消費状況を把握するのに役立ちます。

ページには主に以下の内容が含まれます。

• 入力 Token：入力プロンプト総量の統計
• 出力 Token：モデル生成内容総量の統計
• 推定費用：Provider 単価に基づいて見積もられた費用
• 内部コスト：安全モデルに関連する内部精算コスト
• 日次費用トレンド：直近 7 日間の現在ウィンドウ内における推定費用と Token 変化を確認
• ユーザー集計：ユーザー単位で使用量と費用を集計
• インスタンス集計：インスタンス単位で使用量と費用を集計
• 最近のコスト記録：Trace、ユーザー、モデルなどの条件でコスト記録を検索・ページ表示し、さらに監査詳細へ遷移可能

説明：現在まだモデル呼び出し記録が生成されていない場合、入力 Token、出力 Token、費用、およびトレンド図がすべて 0 の場合がありますが、これは正常です。

9.5 AI 監査モジュール

AI 監査ページは、最近の管理対象モデル呼び出し記録を確認するために使用され、管理者がモデル呼び出し、Token 使用、およびルーティング結果を調査するのに役立ちます。

主な機能は以下の通りです。

• 最近の AI Trace：最近のモデル呼び出しチェーンを確認
• Trace リスト：最近の管理対象 Trace を統一テーブルで確認
• 検索とフィルタリング：Trace、リクエスト内容、ユーザー、モデルなどの条件で検索可能
• 状態フィルタ：状態別に異なる呼び出し結果を確認可能
• モデルフィルタ：モデル別に対応する呼び出し記録を絞り込み可能
• ページネーションと更新：監査結果のページ表示および手動更新に対応

説明：ページに「まだ AI 監査記録はありません」と表示される場合、まだ実際のモデル呼び出しリクエストが生成されていないことを意味します。

9.6 リスク制御ルールモジュール

リスク制御ルールページは、機微内容の検出ルールを設定し、ルール命中後の処理動作を決定するために使用されます。

このモジュールでは主に以下をサポートします。

• ルール一覧管理：すべてのルールとその有効状態を確認
• ルール分類表示：個人情報、会社情報、顧客業務、安全資格情報、財務法務、政治的機微、カスタムなどの分類でルールを確認可能
• ルール項目設定：ルール ID、表示名、重要度、アクション、順序、正規表現 Pattern、説明を設定可能
• ルール動作制御：ルール命中時に通過させるか、安全モデルへルーティングするかを選択可能
• 一括有効化 / 無効化：ルール状態の一括調整に対応
• ルールテスト台：サンプルテキストを貼り付けて、有効ルールまたは下書きルールが何に命中するかをテスト可能

現在の内蔵ルール例には以下が含まれますが、これらに限定されません。

• 個人情報：メールアドレス、携帯電話番号、身分証番号、パスポート番号、銀行カード文脈、住所、履歴書内容など
• 会社情報：内部 IP、内部ドメイン、ホスト命名、Kubernetes Service DNS、プロジェクトコード名、組織構成、給与 / HR 情報など
• 顧客業務：顧客リスト、契約 / 見積書、請求税番号、CRM / チケットデータなど
• 安全資格情報：秘密鍵、API Key、Token、JWT、Cookie / Session、データベース接続文字列、Kubeconfig、環境変数秘密情報など
• 財務法務：予算、利益、売上、法務意見、訴訟、NDA など
• 政治的機微：政治機関、軍事国家安全、極端暴力に関する表現など

説明：デフォルトルールは多くの一般的な機微情報検出シナリオをすでにカバーしています。実際の利用では、業務要件に応じてルールを追加、調整、または無効化できます。

---

十、ワークスペースモジュールの説明

ワークスペースは、一般ユーザーがプラットフォームに入った後の主要な操作領域です。個人のリソースクォータ確認、インスタンス作成、インスタンス管理、および OpenClaw 関連リソースの維持に使用します。このモジュールは、管理者側の「コンソール概要」とは異なり、日常利用と運用寄りの機能です。

10.1 ワークスペースホーム

ワークスペースホームは、現在のアカウントにおけるインスタンスとリソース使用状況の概要を表示するためのもので、主に以下を含みます：

• マイインスタンス：現在のアカウントで作成されたインスタンス数を表示します。
• 稼働中：現在実行中のインスタンス数を表示します。
• 使用済みストレージ：現在のアカウントが使用しているストレージ容量を表示します。
• マイリソースクォータ：現在のアカウントで使用可能なクォータ情報（インスタンス数、最大 CPU コア数、最大メモリ、最大ストレージ、最大 GPU 数）を表示します。
• クイック操作：新規インスタンス作成 と 全インスタンス表示 の 2 つの入口を提供し、素早くプラットフォームを使い始められます。

注：ページに「まだインスタンスがありません」と表示される場合は、直接 新規インスタンス作成 をクリックして最初の OpenClaw Desktop インスタンス作成を開始できます。

10.2 マイインスタンス

マイインスタンス ページは、現在のアカウントで作成されたインスタンスを一元的に表示・管理するためのページです。このページは主にインスタンス管理機能を担当します。 一般的にサポートされる操作は次のとおりです：

• インスタンス状態の確認：インスタンスが作成中、稼働中、停止済み、または異常状態かを確認します。
• インスタンス詳細に入る：インスタンスの基本情報、リソース構成、および実行状況を確認します。
• インスタンス停止：インスタンスが異常な場合や環境の再読み込みが必要な場合に、停止操作を実行できます。
• インスタンス削除：インスタンスが不要になった場合、CPU、メモリ、ストレージなどのリソースを解放するために直接削除できます。

注：インスタンスを削除すると、そのインスタンスに関連するリソースも一緒にクリーンアップされます。実行前に、中のデータや設定がバックアップ済みか確認してください。

10.3 リソース管理

リソース管理 ページは、利用可能な OpenClaw リソース内容を保守し、インスタンス起動後に注入して使用しやすくするためのものです。 ページには主に以下の部分があります：

• リソース：利用可能なリソース項目を表示・保守します。
• リソースパック：複数のリソースを再利用可能なパックとして組み合わせ、一括注入を容易にします。
• 注入記録：リソース注入の履歴と実行状況を確認します。

リソース管理ページの左側では、リソースタイプごとに分類して管理することもできます。現在ページ上で確認できるタイプは次のとおりです：

• チャネル
• スキル
• エージェント（近日公開）
• 定期タスク（近日公開）

ページ右上では次をサポートします：

• 更新：現在のリソース一覧を再読み込みします。
• 新規作成：新しいリソース項目を作成します。

注：リソース管理は主に、インスタンス起動後に使用できる OpenClaw リソース内容を準備するためのものであり、インスタンス作成フローそのものを直接置き換えるものではありません。インスタンス作成時には、手動リソース、リソースパック、アーカイブ導入 などの方式と組み合わせてリソース注入を行えます。

10.3.1 チャンネルの新規作成

「チャンネル」は、OpenClaw と外部メッセージプラットフォームまたは接続先との接続方法を設定するために使用します。例として Telegram、Slack、Feishu / Lark などがあります。

チャンネルを作成する際は、以下の手順で操作します。

1. リソース管理 ページに入り、リソース タブのままにします。

2. 左側のリソースタイプで チャンネル を選択します。

3. ページ右側の 新規作成 をクリックし、「新規リソース」ダイアログを開きます。

4. ダイアログで基本情報を入力します。

   • タイプ：チャンネル を選択
   • リソース Key：このチャンネルの一意な識別子を入力します。識別しやすく、重複しない英語名または組み合わせ名を使用することを推奨します
   • 名前：チャンネルの表示名を入力します
   • タグ：任意、分類検索に使用します
   • 説明：任意、このチャンネルの用途を補足するために使用します
   • 有効化済み：チェックを入れたままにすることを推奨します

5. Channel テンプレート 領域で初期テンプレートを選択します。現在サポートされているテンプレートは以下の通りです。

   • Telegram
   • DingTalk
   • Slack
   • Feishu / Lark

6. テンプレートを選択した後、テンプレートを読み込む をクリックします。システムは対応するテンプレートの基本設定を下部の 内容 JSON 領域に自動で書き込みます。

7. 実際の接続情報に基づいて、内容 JSON 内の各フィールドを追加または修正します。

8. 設定内容に誤りがないことを確認したら、保存をクリックしてチャンネル作成を完了します。

説明：

• Channel テンプレート は基本設定を素早く生成するために使用します；
• 内容 JSON は最終的に有効となるチャンネル設定内容です；
• 完全に一致するテンプレートがない場合は、内容 JSON に直接手動で設定を記入することもできます。

10.3.2 スキルのアップロード

スキルは、OpenClaw に再利用可能な機能を提供するために使用します。プラットフォームは、アーカイブファイルをアップロードすることでスキルを一括インポートすることをサポートしています。

スキルをアップロードする際は、以下の手順で操作します。

1. リソース管理 ページに入り、リソース タブのままにします。
2. 左側のリソースタイプで スキル を選択します。
3. ファイルを選択 をクリックし、ローカルのスキル圧縮パッケージを選択します。
4. 現在のページでは .zip ファイルのみアップロードをサポートしています。
5. 選択完了後、右側の スキルアーカイブをアップロード をクリックします。
6. システムはアップロード内容を自動解析し、各第1階層ディレクトリを1つのスキルとしてインポートします。
7. アップロード完了後、スキル一覧でインポート済みのスキルを確認できます。

説明：

• スキルアーカイブは事前にディレクトリ構成を整理しておくことを推奨します；
• 各第1階層ディレクトリは独立したスキルとして認識されます；
• アップロード後に一覧がすぐ更新されない場合は、ページ右上の 更新 を手動でクリックして再読み込みしてください。

---

10.4 Team 協働

Team では複数の OpenClaw Lite メンバーが共通目標に取り組みます。Teams を開き、メンバーテンプレートを選び、Team 名を入力して作成します。メンバーごとの Runtime やリソースプリセットの設定は不要です。

作成後、Team チャットで Leader に目標を説明します。Leader が計画、実行、レビュー、最終統合を調整します。現在の段階と完了した成果物は Execution Kanban で、共有成果物は Files で確認できます。

詳しくは Team Workspace Quick Guide を参照してください。

十一、問題と対処のクイックリファレンス

11.1 ストレージ問題の専用対応（PV/PVC）

次のエラーが表示された場合：

0/1 nodes are available: pod has unbound immediate PersistentVolumeClaims

クラスターのストレージが自動でバインドされていないことを意味します。この場合は、x86 単一ノードサーバー方式でローカル hostPath PV/PVC を手動作成できます。

この方式は単一ノードサーバーのテストまたは軽量環境に適しています。本番環境では NFS、Ceph、クラウドディスクなどの正式なストレージの使用を推奨します。

11.1.1 PV の作成

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv-local
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  hostPath:
    path: /tmp/mysql-data
EOF

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolume
metadata:
  name: minio-pv-local
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  hostPath:
    path: /tmp/minio-data
EOF

11.1.2 PVC の作成

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-data
  namespace: clawmanager-system
spec:
  storageClassName: ""
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  volumeName: mysql-pv-local
EOF

kubectl apply -f - <<EOF
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: minio-data
  namespace: clawmanager-system
spec:
  storageClassName: ""
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  volumeName: minio-pv-local
EOF

11.1.3 Pod の再作成

kubectl delete pod --all -n clawmanager-system

11.1.4 状態の再確認

kubectl get pvc -n clawmanager-system
kubectl get pods -n clawmanager-system -w

期待される結果：

• mysql-data / minio-data が Bound
• mysql / minio / skill-scanner / clawmanager-app が最終的に Running

---

症状	原因	対処
kubectl の localhost:8080 接続が拒否される	kubeconfig が設定されていない	KUBECONFIG を設定するか ~/.kube/config にコピーする
Pod のイメージ取得がタイムアウトする	Docker Hub / GHCR へのネットワークが不安定	イメージ高速化またはプロキシを設定する
MySQL / MinIO がずっと Pending	PVC がバインドされていない	StorageClass を確認するか、PV/PVC を手動作成する
ブラウザでページを開けない	NodePort が解放されていない / port-forward プロセスが維持されていない	ポートを解放するか転送用ターミナルを維持する
ページは開くが OpenClaw インスタンスを作成できない	セキュアモデルが未設定	先に AI Gateway → モデル でセキュアモデルを設定して有効化する
インスタンスが長時間「作成中」のまま	初回のイメージ取得に時間がかかる / ストレージまたはネットワークの問題	しばらく待ち、必要に応じて Pod とイベントを確認する

---

十二、推奨される最終確認手順（セルフチェック用）

1. kubectl get nodes
2. kubectl get storageclass
3. kubectl get pods -n clawmanager-system
4. kubectl get pvc -n clawmanager-system
5. kubectl get svc -n clawmanager-system
6. ブラウザで https://<IP>:30443 を開く
7. バックエンドにログインして セキュアモデル設定 を完了する
8. ワークスペースで OpenClaw Desktop インスタンスを作成する