OpenClaw のアップグレードや設定変更の直後に、Telegram／Slack では会話できるのに exec・read・write・browser が使えない、または Agent がツール呼び出しのテキストだけを出して実行しない場合、本稿では次を整理します。①三類の症状でどの層を先に見るか；② tools.profile の四値対照と tools.deny／agent 上書きの確認順；③六ステップの再現可能な Runbook と検証ラダー。Gateway 無応答とモデルエラーの記事と補完関係にあり、そちらはチャネルとモデル、本稿はツール allowlist の契約を扱います。
tools.profile が messaging／minimal のまま：アップグレードやウィザードの既定でツール面が絞られ、「会話は滑らかだが exec だけ not found」となります。tools.deny の誤設定：コンプライアンス向けに exec／browser を一時 deny し、変更チケットを閉じたあともルールが残っています。agents.list[].tools.profile がグローバルを上書き：グローバルは直したつもりでも、実際の agent はより狭い profile を継承しています。OpenClaw のツール面は「入れたら全部使える」わけではなく、グローバル profile → deny リスト → agent 級の上書きの三層が重なって有効集合が決まります。2026 年時点の上流ドキュメントでは tools.profile を基線 allowlist と定義しています。minimal はセッション状態系のみ、messaging はチャネルと session 寄り、coding はファイルシステム・ランタイム・web・sessions・memory など工程向け、full は profile 層で追加制限しません。多くのチームがアップグレード後に初めて踏むのは Gateway 障害ではなく、契約が「暗黙の全許可」から「明示的な許可」に締まったことで、変更チケットに「restart と最小プローブ」が書かれていないケースです。その結果、on-call がチャットで同じプロンプトを繰り返し、リリース窓を丸ごと失います。
Gateway をスリープする個人ノートブック上で動かしていると、「設定は変えたが launchd／コンテナが reload されていない」という見かけ上の失敗も重なります。権威ある Gateway を常時稼働・専用・チケットで追えるリモート Mac に置き、SSH ローカル転送で Control UI に触れると、「設定変更面」と「端末のノイズ面」を分離できます。下記の検証ラダーでは、Gateway 側で受け入れることを強調します。CLI が success と表示しただけでは不十分です。
| 見える症状 | 優先して疑う層 | 最初の一手（実行可能） |
|---|---|---|
| 応答はあるが exec／read が tool not found | tools.profile が狭い、または agent 上書き |
有効 profile をエクスポート；必要なら openclaw config set tools.profile coding；gateway restart |
| 特定ツールだけ常に不可、他は正常 | tools.deny |
deny ルールを全文検索；公式 tools ドキュメントと照合して誤 deny を除去 |
| ある agent だけ動かない | agents.list[].tools.profile |
その agent の profile をグローバルと揃える；「A を直して B で検証」を避ける |
| メッセージに JSON 状の tool call テキスト | モデルの tool-calling 能力 | function calling を安定して扱うモデルへ切替；並列ツール数を下げて A/B |
| チャネルが完全に無応答 | チャネル／Token／モデルルーティング | Gateway 無応答専用記事へ；本稿の手順は後回し |
tools.profile 四値対照：coding と full の使い分け実務では多くの自動化・開発向け Agent は coding に置くのが妥当です。ファイル読み書き、シェル、web 取得、session、memory などをカバーし、full より安全レビューしやすいです。full は「profile 層でさらに切らない」必要があり、監査と最小露出の仕組みが揃っている場合に限って検討してください。messaging は純粋な転送・カスタマーサポート向け、minimal は状態だけ欲しくファイルシステムに触れない場合向けです。Agents／Skills／memory_search の調整と併読する場合は、「ツール面」と「コンテキスト上限」を同一変更チケットに載せてください。そうでないと memory は検索できるのに read が profile で塞がる、といった半設定になります。
機構として、Gateway はセッション開始時に設定から有効なツール登録表を解決し、モデルへ tool-calling を渡します。登録表に exec が無ければ、モデルが呼び出そうとしても実行時に拒否されるか、弱いモデルでは意図をテキストとして出力します。コミュニティで「アップグレード後いきなりチャットだけ」となる投稿の多くは、最終的に profile か deny に着地しますが、切り分け順は依然として無応答を先に除外し、本稿に入るのが時間の節約になります。
| profile 値 | 典型的に使える能力（概略） | 向くシナリオ |
|---|---|---|
| minimal | session_status など軽量状態 |
読み取り監視のみ。ファイルと shell に触れない |
| messaging | チャネル・session 管理系ツール | 転送・カスタマーサポートのみ。コードとファイル操作なし |
| coding | filesystem、runtime、web、sessions、memory、media など | 開発自動化・スクリプト・リポジトリ操作（推奨既定） |
| full | profile 層で追加裁剪なし | 監査と最小露出が整った本番の特例 |
ヒント：tools.profile を変えたあとはGateway の再起動が必須です（本機 daemon、Docker compose、リモート launchd ユニット）。openclaw doctor だけでは、実行中プロセスが新 allowlist を読み込んだとは限りません。Docker 経路は本番 Runbookの reload 順序に従ってください。
tools.deny と agent 上書き：三層を重ねる確認順on-call が層を行き来しないよう、次の順を固定することをおすすめします。①稼働中 Gateway が報告する有効 profile（または同等のエクスポート）を読む → ② tools.deny を確認 → ③ 対象 agent の agents.list[].tools.profile → ④最後にグローバル config を変更。直前にリリースチャネルのアップグレードをした場合は、変更チケットに「既定 profile の移行が含まれるか」を先に確認してください。イメージの巻き戻しが必要なら不良リリースのロールバックを使い、profile の試行錯誤を無限に続けないでください。
マルチ agent では「グローバルは coding なのに、本番 bot が旧エントリの messaging のまま」という事故がよくあります。チケットには検証した agent 名とトリガーしたチャネルを必須にし、CLI 直聊と Telegram／Slack で最小プローブをそれぞれ実行してください。ルーティングが異なることがあります。セキュリティチームの一時 deny には期限と担当者を記録してください。三ヶ月後に browser が禁じられた理由を誰も思い出せず、ゼロから調べ直すことになります。
openclaw --version、現在の tools.profile、agent リストの要約、失敗した会話の request id（あれば）を保存します。coding。変更前にチケットへ理由とロールバック値を書きます。openclaw gateway restart；Docker は docker compose restart 等で、権威 Gateway は一つに揃えます。openclaw doctor → openclaw gateway status → 非破壊の最小プローブ（読み取り専用 read または小さな exec echo）→ チャネル接続済みなら channels status --probe。# 証跡と整合（フィールドは環境に合わせて調整） openclaw --version openclaw config get tools.profile 2>/dev/null || true # よくある修復経路（変更前に設定をバックアップ） openclaw config set tools.profile coding openclaw gateway restart openclaw doctor openclaw gateway status # 最小プローブ：Control UI または CLI で読み取り専用 read / 無害な exec を一度
tools.profile／deny／agent 上書きだった割合。二週連続で 40% を超えるなら、アップグレードチェックリストに profile 受け入れが欠けています。これらの指標は「チャットできる」と「ツールが動く」を観測可能なイベントに分けるためのものです。六国ノードでビルドと Agent を同時に走らせる場合は、ディスクと CPU のピークを避けた変更窓にしてください。そうでないとプローブ失敗が profile 問題に見えます。
FinOps の観点では、「OpenClaw を試す」ために短期リースしたのに、profile 既定値のせいで最終日までツール面に気づかない、という無駄が起きます。POC 初日に目標 profile、空の deny、agent 上書き方針を受け入れリストに書き、POC 拡張 KPI マトリクスの「初日グリーンビルド／グリーン Gateway」と並べてください。Agent をチャット玩具としてだけ受け入れないことが重要です。
チャットでプロンプトを替え続けたり、restart せずに設定を何度も触る代替案は、たまに当たっても監査できず、第二台で再現できず、セキュリティチームに「そのとき Agent が何ができたか」を説明できません。対照的に、常時稼働・専用・変更をチケット化できるリモート Mac 上の Gateway に、文書化した profile 既定と検証ラダーを載せれば、MTTR は「一晩プロンプト試行」から「十分以内に再現可能」へ短縮しやすくなります。
ノートブックで最新版を追い続ける場合でも、スリープによる Gateway の疑似停止、蓋を閉じたあとの reload 未反映、チームごとの口頭 profile などの隠れコストを受け入れる必要があります。7×24・監査可能・CI の変更リズムと揃えた OpenClaw 本番 Agent には、MACCOME の Mac mini（M4／M4 Pro）と六国の弾力リースが、個人端末の電源管理と戦うより総コストが下がることが多いです。公開ティアは多リージョン・リースガイドを参照し、SSH 転送 Runbook でトポロジをつなげてください。
よくある質問
アップグレード後、tools.profile を必ず full にする必要がありますか。
必須ではありません。coding で多くの工程自動化をカバーできます。full は監査とセットで検討してください。変更後は restart と最小プローブが必須です。本番専用機の計画ではレンタル料金とヘルプセンターもご参照ください。
本稿と「Gateway 無応答」の記事は重複しませんか。
無応答専用記事はチャネル・モデル・ハンドシェイクを扱います。本稿は allowlist の三層のみを扱います。完全無応答のときは先に専用記事へ。tool not found だけのときは本稿の Runbook に従ってください。
profile を変えても tool call テキストだけが出る場合は。
まず function calling を安定して扱うモデルへ A/B してください。特定チャネルだけならチャネル専用記事を確認します。半アップグレードでないと確認できたあとで、バージョンロールバックを検討してください。