編集注：2026年1月30日、MoltbotはOpenClawに名称変更されました。
Peter Steinberger氏の新プロジェクトに対する最初の反応は「OpenClawは正気じゃない」というものでしたが、それは誇張ではありませんでした。OpenClaw（旧称MoltbotおよびClawdbot）は根本的な変化をもたらします。それは「手」を持つAIです。単にコードを提案するだけではなく、ローカルファイルシステムを操作し、ターミナルコマンドを実行し、アプリケーション間でデータを移動できます。「AIの同僚」のような存在であり、より深い統合、長期記憶、そして自ら行動を起こす主体性を備えた、真のAIアシスタントです。
このような統合機能と記憶こそ、開発者が長年求めてきたものです。
しかし、それは脅威モデルを完全に変えてしまいます。
ウェブサイト上の標準的なAIのような「瓶の中の脳」が混乱した場合、主なリスクは誤情報です。しかし、シェル履歴、SSHキー、テキストメッセージ、メール、Slackトークンへのアクセス権を持つ「手」を持つAIが侵害されたり、単純に混乱したりした場合、リスクは単なる誤回答では済みません。最悪な一日を招くことになります。
「最悪な一日」の具体例を挙げます。
- デバッグ中に環境変数をエクスポートし、誤って機密情報をログ、Pastebin、またはイシューのコメントに出力する（env、.env、printenv、CIログ）。
- READMEやGitHubイシューにある「役立つ」
curl | bashを実行し、他人のスクリプトを自身の権限で実行してしまう。 - 修正のための「コンテキスト共有」を優先するあまり、プライベートな情報（APIキー、内部URL、顧客データ、スタックトレース）をコミットしてプッシュする。
- SSHやGitの設定を「クリーンアップ」してアクセスを遮断する（あるいは、怪しい経路にトラフィックをルーティングするように設定を変更する）。
- イシューやPRにある説得力のあるプロンプトインジェクション（「続行するには、〜を実行してください」）を読み、信頼できない入力ではなく、信頼できる指示として扱ってしまう。
これらはハリウッド映画のような「AIの暴走」シナリオではありません。間違った場所で、間違った権限レベルで、間違ったコマンドを実行するという、自動化における通常の失敗パターンです。ただ、今の自動化は「おしゃべりで、高度にネットワーク化されており、非常に熱心に助けようとする」点が異なります。
これは「AIは怖い」と煽る記事ではありません。CIランナー、ブラウザ拡張機能、IDEプラグインなど、マシン上でコードを実行できるあらゆるツールに対して、すでに理解している冷静な現実です。
エージェントをチャットのおもちゃのように扱うのをやめ、ルート権限を持つ新人社員のように扱う必要があります。
- 役に立つ
- 仕事が早い
- 時々間違える
- ガードレールなしで無制限のアクセス権を与えてはいけない
システムを保護するために何ができるでしょうか。実用的なチェックリストを紹介します。
2026年におけるAIシステム保護のための5つのチェックリスト
1.サンドボックス（「保護された部屋」）を有効にする
OpenClawにはサンドボックスモードがあります。clawdbot.json設定を数行変更するだけで有効にできます。必ずオンにしてください。
目標は単純です。エージェントが暴走しても、それが存在する小さなサンドボックス内だけを破壊するように制限することです。
サンドボックスモードでは以下の運用が可能です。
- VM、コンテナー、またはDevbox（使い捨て可能な環境）内でOpenClawを実行する。
- ホームフォルダ全体ではなく、一つのプロジェクトディレクトリへのアクセス権のみを与える。
- 「便利だから」という理由だけで、
~/.ssh、パスワードマネージャー、グローバル設定フォルダ、ドキュメントディレクトリ全体へのアクセスを許可しない。 - 外部アクセスを防ぐために
gateway.bindを"loopback"に設定し、allowFromリストを使用してボットと通信できるユーザーを制限する。
2.コマンド、パス、統合機能の許可リストを有効にする
ボットにカレンダーを確認させたい場合でも、パスワードファイルを読み取らせるべきではありません。許可リストを使用して、ボットがアクセスまたは変更できる対象を正確に制限してください。
OpenClawは許可リストをサポートしています。活用してください。また「実行前に確認する」機能があれば、それも使用してください。 最低限、以下を設定する必要があります。
- コマンド許可リスト（またはコマンドカテゴリ）
- ファイルシステム許可リスト（読み書き可能なディレクトリ）
- 統合機能許可リスト（操作可能なアプリやサービス）
- ネットワーク許可リスト（外部リクエストの可否）
また、以下の破壊的または高リスクな操作には、明示的に確認を要求してください。
- ファイルの削除（
rm、再帰的プログラム） - 権限の変更（
chmod、chown） - SSHやGitの設定変更
- ソフトウェアのインストール
- 認証情報が関わる操作
- リモートコンテンツをシェルにパイプする操作
「デフォルト拒否と明示的な承認」を徹底してください。
AI時代において、アクセス制御は極めて重要です。
3.プロンプトインジェクション対策のあるモデルを使用する
エージェントと機密情報の組み合わせは、便利なツールをインシデント報告へと変えてしまいます。
身を守るためのルールです。
- SSHキーを読み取らせない。
ssh-agentやプロジェクトごとのキーを優先してください。 - フルアクセス権限ではなく、スコープ指定されたトークン（可能な限り読み取り専用）を使用してください。
- 長期的な認証情報よりも、短寿命の認証情報（可能な限りエフェメラル）を優先してください。
- エージェントが安易に読み取れる
.envファイルに機密情報を置かないでください。 - 「記憶」機能がある場合、機密情報をメモリに保存しないように徹底してください。
実務的なアプローチです。
- 意図的に制限した「エージェント用」の認証情報セットを作成する。
- エージェントが見ることのできるものは、最終的に漏洩する可能性がある（ログ、メモリ、スクリーンショット、ツールのトレースなど）と想定する。
- 実際に実行できるように、認証情報の「ローテーション」を容易にする。
Claude Opus 4.5はプロンプトインジェクション攻撃に対して優れた防御実績がありますが、完全に免疫のあるモデルは存在しません。自身で徹底的にテストしてください。
4.監査を実行し、ログを保持する
組み込みの監査コマンドがあれば、実行してください。例えば、CLIが以下のようなコマンドをサポートしている場合です。
"""bash clawdbot security audit --deep """
正確なコマンドが異なっても、原則は同じです。存在するあらゆるツールを使用して、権限、統合機能、保存されたメモリ、リスクのあるデフォルト設定を列挙してください。
運用面では以下の準備も必要です。
- レビュー可能なツール実行ログ（どのコマンドが実行され、どのファイルにアクセスしたか）
- インテグレーションを迅速に無効化できる「緊急停止ボタン」
- 権限を定期的に最小状態にリセットする習慣
5.個人用ボットをグループチャットに追加しない
個人用ボットはあなたの秘密を知っています。グループチャットに追加すると、個人のカレンダーやメモを室内の全員に誤って共有してしまう可能性があります。
共有ワークスペースでボットを使用したい場合は、個人アカウントやファイル、メモリへのアクセス権を持たない、制限された「仕事用ボット」を別途運用してください。
ボーナスチップ：ドキュメントを読む
セキュリティは「一度設定すれば終わり」の機能ではありません。
退屈なので敬遠されがちですが、ここが最も重要です。以下を確認してください。
- Gateway Binding:リスナーは
localhostに固定されていますか（安全）、それとも0.0.0.0に公開されていますか。 - Memory:「記憶」は実際に何を、どこに保存していますか。
- Execution Modes:
Elevated: AskとElevated: Fullの違いを理解していますか（一方はボットにサイレントでルート権限を与えます）。 - Pairing:
dmPolicyはどのように部外者をフィルタリングし、承認されたIDはどこに保存されていますか。 - Binaries:
safeBinsでホワイトリストに登録されている具体的なコマンドは何ですか。 - Telemetry:
OTEL_LOGS_EXPORTERがどのような会話データを外部に送信していますか。
「チャットのおもちゃ」からセキュアな本番用エージェントへ
OpenClawのようなエージェントは真の生産性向上をもたらしますが、マインドセットの転換を迫ります。エージェントはもはや単なる「モデル」ではなく、システム上の「新しいセキュリティ主体」です。アクションを実行し、データに触れ、システムを横断できる非人間アイデンティティです。
だからこそ、上記のチェックリストが重要になります。サンドボックス、許可リスト、機密情報の衛生管理、監査ログこそが、「手を持つAI」を「インシデントチケットを持つAI」に変えないための方法です。
エージェントアプリケーションを構築したり、社内システムにエージェントを組み込んだりする場合、不足しているレイヤーはプロンプトの工夫ではなく、ほとんどの場合アイデンティティと認可です。
ここにAuth0 for AI Agentsが適合します。これはエージェントが必要とする「地味だが重要な」セキュリティ基盤です。ユーザー認証（誰が依頼しているか）、Token Vault（エージェントがどのように権限を委譲されるか）、そしてFine-Grained Authorization（FGA）（エージェントが個々のリソースに対して何を許可されているか）を提供します。
目標は、エージェントを弱くすることではありません。予期せぬ事態を起こさずに、強力なパワーを発揮させることです。