完全ガイド：OpenClawエンタープライズガバナンス

2026年3月25日Ollie @puppyone

エンタープライズガバナンス図：FeishuとTelegramチャネル、承認フロー、コンテキスト境界シールド、監査ログを備えたOpenClawカーネル

OpenClaw V3をFeishu/LarkやTelegramに導入する場合、最も難しいのはボットに返信させることではなく、セキュリティとコンプライアンスチームに、エージェントが安全なコンテキスト境界内で動作し、高リスクアクションには明示的な人間の承認が必要で、機密の読み取り/書き込みがすべて監査可能であることを証明することです。本ガイドはガバナンスのプレイブックです：エンタープライズの厳格な審査に耐えるメッセージングエージェントをデプロイするための具体的なパターン、最小限の前提、検証可能なステップを提供します。

重要なポイント

OpenClawエンタープライズガバナンスを最優先事項として扱う：各エージェントのコンテキストをスコープし、ツール権限を最小化し、リスクの高いアクションには承認を必須とする。
Feishu/Larkでは、長接続イベント処理を有効にし、@メンションでフィルタリングする；Telegramでは、プライバシーモードをオンにし、チャット/管理者ごとにコマンドをスコープする。
送信/投稿/変更/流出アクション用のステートフルな承認フローを設計し、リクエストと決定の両方を監査ログに記録する。
監査スキーマを標準化し、Elastic Agent/FilebeatまたはSplunk HEC経由でSIEMに送信する；証拠が再構築可能であることを定期的にテストする。
ロールアウト前にDMとグループでパリティテストを行いガードレールを検証する；ペアリングリクエストの急増、承認失敗、レート制限エラーを監視する。

メッセージングエージェントでガバナンスファーストが重要な理由

メッセージングエージェントは、従業員が一日中いる場所—グループチャット、DM、共有ファイル—に配置されます。ガードレールがなければ、単一のプロンプトで機密コンテキストが誤ったチャネルに流出したり、ポリシーを超えて動作するツールがトリガーされたりする可能性があります。ガバナンスファーストの姿勢により、OpenClawは業界のコントロールと整合します：最小権限、明示的な承認、永続的な監査。

NIST SP 800-53 Rev. 5によると、AC-6は最小権限を要求し、AU-*コントロールは組織がセキュリティ関連の監査レコードを生成、保護、レビューすることを要求しています。これらはエージェントのスコープ設定、アクション承認、インシデント対応のためのログエクスポートに直接対応します。NIST SP 800-53 Rev. 5の公式カタログでAC-6とAUコントロールを参照してください（NIST 2020年発行、2026年現在有効、Special Publication 800-53 Revision 5）。ポリシー設計の基盤として、NIST SP 800-53 Rev. 5 PDFの権威あるガイダンスを参照できます：https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf

リスクとコントロールがすぐに焦点になります：

メッセージングエージェントのリスク	実装できるガバナンスコントロール
チャネル間のコンテキスト漏洩	スコープ付きメモリを持つチャネルごとのエージェント；トリガーに@メンション/コマンドを必須；デフォルトでチャネル間取得を拒否
破壊的または流出アクション	送信/投稿/変更/ダウンロードのヒューマンインザループ承認；実行ツール用の短期トークン
スキルのサプライチェーンリスク	署名/検証済みパッケージ；レジストリ許可リスト；サンドボックスシェル；デフォルト拒否ツール
弱い説明責任	リクエスト/決定ペアを持つ追記専用監査ログ；SIEMエクスポート；定期レビュールーチン

エンタープライズでスケールするアーキテクチャパターン

レイヤーで考えてください。ローカルコントロールと観測可能な運用のバランスを取る、OpenClawエンタープライズガバナンスの実用的なリファレンスパターンは以下のとおりです：

ローカルファーストカーネル：OpenClawカーネルを独自インフラストラクチャ上のコンテナ化された非rootコンテキストで実行する。Web UIはVPN/SSOの背後に配置する。ファイルシステムマウントは読み取り専用ルートと明示的な書き込みボリュームに制限する。
チャネルごとのエージェントとスコープ付きメモリ：Feishu/LarkとTelegramで別々のエージェントインスタンスを使用する。メモリと取得スコープをチャネルとチームにバインドする；全チャネルで単一の共有メモリを避ける。
デフォルト拒否ツール：厳格な許可リスト（例：read_file、構造化取得、安全なWebフェッチ）から始める。リスクの高い動詞（execute_command、send_email、external_post）は承認のゲートの背後に置く。
承認ブローカー：承認者ID、決定タイムスタンプ、理由を保存する承認ステートマシン（requested → triaged → approved/denied）を実装する。承認プロンプトは承認者が既に作業している場所（FeishuカードまたはTelegramインラインフロー）に表示するが、決定の証跡は監査ログに保持する。
観測可能性：セキュリティ関連イベントのJSONログを出力し、中央SIEMに転送する。ペアリングリクエスト、承認、拒否、ツール実行、送信投稿のレートを追跡する。

Feishu/Larkの実践的ハードニング

Feishuの開発者プラットフォームは、必要なチャネル側のプリミティブを提供します—エンタープライズ内部アプリ、スコープ付き権限、長接続、メッセージイベント。Feishuの公式イベント購読概要に従ってアプリを作成し、必要な最小限のチャット/メッセージスコープのみを割り当て、長接続イベント購読を有効にし、im.message.receive_v1を購読してください。Feishuのイベント購読ガイド概要を参照：https://open.feishu.cn/document/server-docs/event-subscription-guide/overview および一般的なエラーコードを含むメッセージイベントリファレンス：https://open.feishu.cn/document/ukTMukTMukTM/ugjM14COyUjL4ITN

Feishu側でOpenClawと共に適用するガバナンスパターン：

グループで@メンションを必須にする：メッセージハンドラーで、ボットがメンションされているイベントのみを処理する；周囲の雑談は無視する。これは「メンション必須」の動作を反映し、忙しいチャネルでのプロンプトインジェクションリスクを大幅に削減する。
DMの前にペアリング：初回DMで、ペアリングコードを生成し、会話前に管理者承認を必須とする。pairing.requestedとpairing.approvedをユーザーとテナントIDでログに記録する。
承認済みグループ許可リスト：許可されたグループIDのリストを維持する；他のチャットからのイベントを拒否する。リストを毎月レビューする。
レート制限とバックオフ：Feishuのプラットフォーム制限を尊重する。繰り返しのスロットリングや配信エラーをアラートし、ジッターでバックオフする。
最小権限スコープ：IM読み取り/送信とメンバーシップ読み取りのみで始める；具体的なユースケースで必要になった場合のみ追加する。各スコープに存在理由を文書化する。

SDKセットアップとアプリ作成ステップの正規チェックリストが必要な場合は、Feishuの「開発前の準備」ページを参照：https://open.feishu.cn/document/server-side-sdk/nodejs-sdk/preparation-before-development

Telegramの実践的ハードニング

TelegramのBot APIには、ガバナンス関連の明確なスイッチがあります：

プライバシーモードを有効にする：プライバシーがオンの場合、ボットはグループ内のコマンドとメンションのみを受信する—最小権限に最適。@BotFatherで/setprivacyを使用して設定する。Telegramのプライバシーモードと機能ドキュメントを参照：https://core.telegram.org/bots/features#privacy-mode
管理者権限を最小化する：ボットを本当に必要な権限でのみ昇格させる（例：必要な場合を除きcan_delete_messagesは使用しない）。管理者権限はTelegram Bot APIのChatAdministratorRightsで定義されている：https://core.telegram.org/bots/api
コマンドをスコープする：BotCommandScope*でsetMyCommandsを使用し、チャットまたは管理者ごとに関連するコマンドのみを公開する。そのAPIサーフェスはTelegram Bot APIのsetMyCommandsとコマンドスコープで文書化されている：https://core.telegram.org/bots/api
レート制限を尊重する：429でバックオフし、バーストを監視する（大まかな目安：チャットあたり約1メッセージ/秒、全体で約30/秒—常に最新のTelegramドキュメントを参照）。制限とリクエストガイダンスは同じBot APIリファレンスにある：https://core.telegram.org/bots/api

これらをOpenClawのチャネルごとのスコープと組み合わせると、TelegramでのOpenClawエンタープライズガバナンスの強力なベースラインが得られます。

リスクの高いアクションの承認フロー

すべてのアクションに承認は必要ありません。ただし、外部に送信する、共有リソースを変更する、またはファイルを流出させるメッセージには、人間の承認を必須とします。

リスクの高い動詞の小さな明示的なセットを定義し、ステートフルな承認プロセスのゲートの背後に置きます。フローと証拠を同等に真剣に扱います。

承認フローポリシーの例（パターン；キー名は実装に合わせて調整）：

approvals:
  verbs:
    - send_message_external
    - post_to_group
    - modify_shared_doc
    - export_file
  routing:
    by_channel:
      feishu: security-approvers
      telegram: platform-approvers
  sla:
    pending_timeout: 30m
    auto_deny_after: 8h
  record:
    include:
      - requester_id
      - approver_id
      - reason
      - decision
      - decided_at

実装上の注意

承認プロンプトをチャネル内（Feishuインタラクティブカード；Telegramインラインキーボード）に表示するが、永続的なレコードを書き込むバックエンドブローカーで確定する。
すべてのリクエストは生成されたapproval.request_idでtool.exec.requestedを出力する；すべての決定は同じIDでtool.exec.approvedまたはtool.exec.deniedを出力する。
承認SLAが期限切れになった場合、自動拒否し、理由とともにリクエスターに通知する。

最小限の監査イベント（JSONパターン）：

{
  "@timestamp": "2026-03-09T10:12:34.567Z",
  "event.dataset": "openclaw.audit",
  "event.action": "tool.exec.requested",
  "channel.type": "feishu",
  "chat.id": "oc_abcdef",
  "user.id": "u_feishu_123",
  "agent.id": "agent_feishu_ops",
  "tool.name": "post_to_group",
  "approval.request_id": "apr_9f3a",
  "outcome": "pending"
}

監査ログとSIEMエクスポート

OpenClawエンタープライズガバナンスのストーリーは、証拠の強さに比例します。フィールドを標準化し、セキュリティチームが既に信頼しているシステムにログを送信してください。

推奨最小スキーマ（ECS風；スタックに合わせて調整）：

event.dataset = "openclaw.audit"
event.action = message.received | message.sent | tool.exec.requested | tool.exec.approved | retrieval.requested | retrieval.permitted | retrieval.denied
user.id, channel.type, chat.id, message.id
agent.id, skill.id, tool.name
approval.request_id, approval.actor_id, approval.state
context.collection, context.version_id
outcome, error.code, error.message

Elasticルート（2つの一般的なオプション）

JSON用のElastic Agent「Custom Logs」統合；可能な限りECSにマッピングする。ElasticのSIEMフィールドとオブジェクトスキーマドキュメントは、Elastic（2025–2026）のECS互換フィールドと統合について説明している：https://www.elastic.co/docs/reference/security/fields-and-object-schemas/siem-field-reference
Agentが実現できない場合はFilebeat。ElasticのFilebeatインストールと設定クイックスタートに従う：https://www.elastic.co/guide/en/beats/filebeat/8.19/filebeat-installation-configuration.html

Splunkルート（HEC）

HTTPS HECを有効にし、JSONイベントを/services/collectorまたは/services/collector/eventにAuthorization: Splunkと_jsonのようなsourcetypeで送信する。SplunkのHTTP Event Collectorの例とフォーマットガイダンスが正規の詳細を提供する：https://help.splunk.com/splunk-enterprise/get-started/get-data-in/9.1/get-data-with-http-event-collector/http-event-collector-examples および https://help.splunk.com/en/data-management/get-data-in/get-data-into-splunk-enterprise/9.4/get-data-with-http-event-collector/format-events-for-http-event-collector

検証のヒント：「approval.request_id AND event.action:tool.exec.*」の保存検索を作成し、外れ値を週次でレビューする。

実践的ワークフロー：puppyoneを使用した監査可能なコンテキスト境界

コンテキストアクセスにエンドツーエンドの監査証跡を持つガバナンスされたコンテキストソースが必要な場合、OpenClawをエージェント間で権限と系譜を保持するコンテキストベースに接続できます。

例（中立的、再現可能なパターン）

ガバナンスされたコンテキストベースでポリシー境界付きコレクション（例：projects/sales-notes）を定義する。MCPエンドポイント経由でOpenClawに公開し、Feishuエージェントにのみバインドする。
コレクション間取得リクエストには、承認を必須とし、context.collectionとcontext.version_idでretrieval.requestedを出力する。承認時のみretrieval.permittedをログに記録し、データを返す。
ログを追記専用に保ち、上記のスキーマでSIEMにエクスポートし、インシデント対応者が誰がいつ何にアクセスしたかを再構築できるようにする。

エージェント向けに構築されたコンテキストベースを評価している場合、puppyoneはこのワークフローをサポートし、ハイブリッドインデックスと権限パターンを文書化している。配布オプション（MCP/API/Claude Skills）の概要はpuppyoneホームページで参照：https://www.puppyone.ai および、ハイブリッドインデックスと構造化Know-Howの背景については、puppyoneブログの「エージェントコンテキストベース完全ガイド：ハイブリッドインデックス」：https://www.puppyone.ai/en/blog/ultimate-guide-to-agent-context-base-hybrid-indexing

注：実装上の注意ではこのパターンをベンダー中立に保ってください；重要なのは、特定の製品に関係なく、決定論的な取得境界と監査可能なアクセスを持つ単一のガバナンスされたソースを持つことです。

OpenClawエンタープライズガバナンスランブック

Day-0（最初のユーザーより前）

カーネルをロックダウンする：コンテナ非root、読み取り専用ルートFS、明示的な書き込み可能ボリューム、VPN/SSOの背後にWeb UI。
シークレット：env/SecretRef経由で読み込む、平文キーをコミットしない；スモークテスト後にテストキーをローテーションする。
チャネル：最小スコープと長接続設定でFeishuアプリを作成；プライバシーモードを有効にし、過剰な管理者権限のないTelegramボット。
ログ：JSONロガーを有効にする；Elastic Agent/FilebeatまたはSplunk HECへのフォワーダーをテストする。

Day-1（パイロットユーザー）

DMのペアリングを有効にする；パイロットユーザーのみを承認する。承認済みグループ許可リストを維持する。
リスクの高い動詞の承認フローをオンにする；リクエスト/決定イベントが一致するapproval.request_idでSIEMに届くことを検証する。
ペアリングリクエストの急増、承認失敗、レート制限エラーに対するアラートを追加する。

Day-30（定常状態）

アクセスレビュー：過去30日間のペアリング承認とグループ許可リストをエクスポートする；古いユーザー/チャットを削除する。
ローテーション：Feishu/TelegramトークンとMCP/APIキーをローテーションする；カナリアテストでロールアウトを検証する。
パッチ：コンテナベースイメージと依存関係を更新する；スモークテストとチャネル間のパリティテストマトリックスを再実行する。

トラブルシューティングと検証

ボットがTUIでは返信するがFeishu/Telegramでは返信しない：チャネル認証情報、長接続ステータス（Feishu）、またはプライバシー/コマンドスコープ（Telegram）を確認する。プラットフォームログとSIEMの最近のエラーコードをレビューする。
グループの@メンションが無視される：ハンドラーがメンションフラグ（Feishu）をチェックするか、プライバシーモード+ /commands（Telegram）に依存していることを確認する。ツールを呼び出さない最小限のコマンドで再現する。
承認が保留のまま：ブローカーのwebhook/キュー健全性をチェックする；pending_timeoutを強制し、自動拒否時にリクエスターに通知する。tool.exec.approved/deniedイベントが正確なapproval.request_idを使用していることを確認する。
監査のギャップ：一時的にログをローカルファイルとSIEMにteeする；パリティが証明されるまでevent.actionごとのカウントを毎日比較する。

次のステップ

一度に1つのチャネルをハードニングする。Feishu/Larkから始める：内部アプリを立ち上げ、長接続イベントを配線し、Feishuのイベント購読ドキュメントを権威あるリファレンスとして使用して、プライベートスペースで@メンションとペアリングパターンを証明する：https://open.feishu.cn/document/server-docs/event-subscription-guide/overview
承認ブローカーをオンにし、監査ログをSIEMに送信する。すべてのリクエストに一致する決定イベントがあり、両方が同じapproval.request_idを持つことを検証する。
権限を複製せずに複数のエージェントエントリーポイントに公開できる、ガバナンスされた監査可能なコンテキストソースが必要な場合、この役割でpuppyoneを評価できる；その概要と背景資料は上記にリンクされており、アプローチは本ガイドのパターンと互換性がある。

よくある質問

Q1: FeishuまたはTelegramでOpenClawの最小コントロールセットは何ですか？

A: 最小限：チャネルごとのエージェントスコープ、@メンション/コマンドのみのトリガー、デフォルト拒否ツール、リスクの高いアクション（送信/投稿/変更/流出）用の承認ブローカー。説明責任のために追記専用監査ログとSIEMエクスポートを追加する。

Q2: 承認者が異なるタイムゾーンにいる場合、承認はどのように処理しますか？

A: 明確な期限付きの短期承認ウィンドウ（例：24〜48時間）を使用する；タイムアウト時に自動拒否し、リクエスターに通知する。承認プロンプトをFeishuカードまたはTelegramインラインフローに表示し、承認者が通常のワークスペースから対応できるようにする。監査のためにリクエストと決定の両方をタイムスタンプ付きでログに記録する。