OpenClawでAI秘書を作って分かった、業務フローと権限の壁

ここ数ヶ月、自分の業務でOpenClawを動かし、AI秘書としてどこまで仕事を任せられるか試してきました。

情報を集める。会議の内容を整理する。タスクや予定を管理する。必要な相手へ知らせる。決まった時間に処理を動かす。いくつもの仕事をつなぐ中で、OpenClawは、会話に答えるだけでなく、実際の仕事を進めるAI秘書になり得ると感じました。

その可能性を自分だけで使うのではなく、顧客にも提供しようと試みてきました。

そこでぶつかった大きな壁が、業務フローと認証・認可の整理です。

実際の仕事では、誰がどの情報を見て、どこで判断し、どのアカウントを使っているのかが、すべて明文化されているとは限りません。人同士なら暗黙の了解で進んでいる仕事も、AIへ任せようとすると、その一つひとつを決める必要があります。

どのアカウントで情報を読むのか。どのファイルまで見せるのか。どこへの書き込みを許すのか。誰の指示を受け付け、どの相手へ連絡してよいのか。失敗したときに、どこで止めるのか。

OpenClawは、やろうと思えばPC上の多くの作業を進められます。ファイルを読み書きし、ブラウザを操作し、コマンドを実行し、外部サービスへ接続できます。一般ユーザーで動かしていても、そのユーザーが触れられるファイルやサービスは操作の対象になります。管理者権限を与えれば、範囲はさらに広がります。

その過程で分かったのは、OpenClawの設定より先に、人間の側が仕事の流れと権限を理解する必要があるということでした。

誰が、何を見て、どこで判断し、どの操作に責任を持っているのか。それが分からなければ、AIに何を任せるかも、どの権限を渡すかも決められません。

この記事では、OpenClawを使ったAI秘書を顧客へ提供しようとする中で見えてきた、業務フローと認証・認可の壁について書きます。

目次

• OpenClawは、AIに仕事の手足を持たせる
• 一例：会議後の作業をつなぐ
• 時間がかかったのは、プロンプト以外の部分だった
• できることが増えるほど、必要な権限も増える
• 1 Gatewayを1つの信頼・権限境界として扱う
• 先に棚卸しするのは、作業と判断と責任
• 権限は、作業単位で決める
• 読み取りから始め、少しずつ任せる
• OpenClaw導入前に確認すること
• 何を任せるか分からないところから相談してよい
• まとめ

OpenClawは、AIに仕事の手足を持たせる

OpenClawは、自分の端末やサーバーで動かせるAIアシスタントです。

公式には、Slack、LINE、Telegram、WhatsAppなど、普段使っている連絡手段からAIアシスタントを利用できる仕組みとして紹介されています。ブラウザ、ファイル、メッセージ、コマンド実行、定期処理などの機能を組み合わせることもできます。

私は、OpenClawを「AIに仕事の手足を持たせるための基盤」として見ています。

LLMに質問するだけなら、AIは文章を返して終わります。OpenClawでは、そのAIにファイルを読ませ、ブラウザを操作させ、コマンドを実行させ、Slackへ投稿させることができます。決まった時間に起こして、仕事をさせることもできます。

たとえば、「今日の予定を教えて」と聞くだけなら、カレンダーの読み取り権限があれば動きます。

一方で、「予定を変更して、関係者へ連絡して」と頼むなら、カレンダーの更新権限と、外部へメッセージを送る権限が必要です。同じAI秘書でも、やらせたい仕事によって必要な権限は大きく変わります。

OpenClawの公式ドキュメントでも、ツールはデータの読み取り、ファイルの変更、メッセージ送信、外部システムの操作に使うものとして整理されています。OpenClawそのものが仕事を理解してくれるというより、仕事に必要な道具と進め方を、人間が渡していく仕組みです。

一例：会議後の作業をつなぐ

私がOpenClawで試してきたことは、会議後の作業だけではありません。情報収集、予定やタスクの整理、各種通知、定期実行など、複数の流れを作ってきました。

以下は、会議が終わった後の作業をつないだ例です。

会議の文字起こしを取得する。議事録を作る。決定事項とタスクを抜き出す。タスクをスプレッドシートへ追加する。処理結果をSlackへ知らせる。さらに、新しい会議記録がないか、一定間隔で確認する。

外から見ると、一つの業務に見えます。しかし、分解すると必要な権限はそれぞれ違います。

この中で、AIらしい処理は議事録の作成やタスクの抽出です。

一方、文字起こしを取ってくる、表へ追加する、Slackへ投稿するといった部分は、APIや普通のプログラムでもできます。OpenClawは、それらをAIの判断や会話とつなげて、一つの仕事として動かせます。

大事なのは、「AI秘書に会議後の作業を任せる」と大きく考えないことです。

読む。まとめる。判断の候補を出す。書く。外部へ知らせる。定期的に確認する。

ここまで分けると、どこなら自動で進めてよいか、どこは人が確認すべきかが見えてきます。

時間がかかったのは、プロンプト以外の部分だった

AI秘書を作り始めた頃は、どのモデルを使うか、どんな指示を書くかが中心になると思っていました。

もちろん、それも大事です。ただ、実際に運用するまでには、別の作業が多くありました。

Google Workspaceでは、どのデータを読むために、どの認証方式と権限が必要なのかを確認する。Slackでは、誰からの指示を受け付け、どこへ投稿してよいかを決める。定期実行では、失敗したときにどこへ通知し、どのログを見れば原因が分かるようにする。

利用を終えるときには、定期処理を止めるだけでは足りません。保存したデータ、トークン、認証情報、キャッシュ、連携先の権限まで確認して、不要なものを消す必要があります。

こうした作業は、派手ではありません。

ただ、ここを決めずにAIへ仕事を渡すと、「動いているが、誰の権限で動いているか分からない」「失敗した後も定期実行が続いている」「担当者が変わったのに認証情報が残っている」といった状態になります。

AIエージェントを業務へ入れるときは、認証、監視、失敗時の復旧、監査、停止、撤去までが一つの導入作業です。

AIの回答精度だけを見ていても、安心して仕事を任せられる状態にはなりません。

できることが増えるほど、必要な権限も増える

OpenClawでは、ファイル操作やブラウザ操作だけでなく、execを使ってシェルコマンドを実行できます。

公式の`exec`ドキュメントには、コマンドによって、実行先のファイルシステムで許可された範囲のファイルを作成、編集、削除できると書かれています。writeやeditなどのファイル操作を止めても、execが残っていれば、コマンドからファイルを変更できる場合があります。

ここで重要なのは、管理者権限を与えたかどうかだけではありません。

OpenClawの公式インストールガイドでは、LinuxのGatewayはsystemdのユーザーサービス、macOSではユーザー単位のLaunchAgentとして動かす方式が案内されています。OpenClawが常にrootや管理者として動くわけではありません。

ただし、一般ユーザーで動かしているから安全ということでもありません。公式セキュリティガイドは、ツールを有効にしたAIアシスタントが、シェルコマンドの実行、ファイルの読み書き、ネットワークサービスへのアクセス、メッセージ送信を行えると説明しています。

さらに、サンドボックスは初期状態では無効です。サンドボックスが動いていない場合、execのhost=autoはGatewayを実行しているホストを選びます。ホスト上のexecは、初期設定ではsecurity="full"、ask="off"で、承認なしに実行されます。

つまり、rootや管理者でなくても、Gatewayを動かすOSユーザーが普段扱っているファイル、認証情報、接続先には届く可能性があります。管理者権限を与えればシステム全体へ範囲が広がりますが、一般ユーザーのままでも、日常業務の多くを進められるだけの権限を持ち得ます。

ファイル変更や外部サービスへの投稿、管理画面の操作まで許せば、任せられる仕事は増えます。その権限が、指示の誤解、設定ミス、外部から入った不正な指示によって、意図しない操作に使われる可能性もあります。

OpenClawでは、ツールの実行をサンドボックスへ移すこともできます。ただし、公式ドキュメントでは、完全なセキュリティ境界ではないと説明されています。また、サンドボックス外で動くelevatedな実行を許せば、ホスト側への操作が可能になります。

サンドボックスを有効にしただけで、安全になるわけではありません。

どのツールを許すか。どこまでファイルを見せるか。どのアカウントを接続するか。どの操作に承認を入れるか。誰がそのAIへ指示を送れるか。これらを合わせて考える必要があります。

1 Gatewayを1つの信頼・権限境界として扱う

OpenClawを仕事で使うなら、ここは特に重要です。

この原則は、GatewayからPCへの操作範囲を狭めるものではありません。Gateway内のエージェントへ委任したツール権限を、誰と共有してよいかを決めるための境界です。

私は、1つのGatewayを、1つの信頼・権限境界として扱うべきだと考えています。これは、OpenClawの公式セキュリティガイドが示している考え方とも一致します。

OpenClawの公式なセキュリティモデルは、1つのGatewayを、1人または互いに信頼できる利用者の集まりが使う前提です。信頼関係のない複数の利用者を、同じGatewayへ入れて安全に隔離するための境界としては設計されていません。

同じGatewayの中でも、エージェントごとにツールやワークスペースを分けることはできます。ただ、それを、別会社や不特定多数を安全に分けるための強いテナント境界として考えない方がよいです。

たとえば、同じ会社で同じ業務を担当し、同じ情報へアクセスしてよい人だけが使うなら、一つの境界として設計できます。

一方で、次のような組み合わせは分けます。

• 個人用と業務用
• 社内利用者と一般公開利用者
• 管理部門と、機密情報へアクセスできない部門
• 自社と取引先
• AI秘書を提供する場合の顧客同士

分けるのはGatewayの設定だけではありません。

• Gateway
• エージェントとワークスペース
• Google、Slack、メールなどの認証情報
• OSユーザー
• 必要に応じてVM、VPS、端末そのもの

ここまで分けて初めて、外側の権限境界がはっきりします。

sessionKeyや会話スレッドを分けるだけでは、認証や権限の境界にはなりません。公開チャットのように不特定多数が触れる入口も、個人情報や強いツールを持つ個人用Gatewayと共用しない方がよいです。

先に棚卸しするのは、作業と判断と責任

OpenClawを入れる前に、私は業務を次の五つに分けて見るようになりました。

たとえば、「問い合わせ対応を任せたい」だけでは、必要な権限を決められません。

問い合わせを読む。内容を分類する。過去の情報を探す。返信案を作る。担当者を決める。顧客へ送る。管理表を更新する。

この中で、読むだけなら読み取り権限です。返信案を作るだけなら、外部送信の権限は不要です。担当者の決定に社内ルールがあるなら、その判断基準を言葉にする必要があります。顧客へ実際に送るなら、誤送信や情報漏えいを考え、人の確認を残すか決めます。

業務を棚卸しする目的は、AIに全部任せるためではありません。

AIに任せられるところを切り出し、人が見るべきところを残すためです。

業務の分け方については、以前の記事「AIエージェント導入は、業務の棚卸しから始める」でも整理しました。OpenClawを使って実際に手を動かすと、この棚卸しがそのまま権限設計になります。

権限は、作業単位で決める

「AIには強い権限を渡さない」と決めるだけでは、まだ具体的ではありません。

作業ごとに、次の五つを決めます。

1. どのデータを見せるか
2. 読み取り、下書き、追記、更新、削除のどこまで許すか
3. 人の指示、定期実行、イベント発生のどれで動くか
4. どの操作で人の確認を必須にするか
5. 何を記録し、異常時にどう止めるか

同じ「読み取り」でも、公開資料を読むのと、顧客情報や秘密情報を読むのでは影響が違います。同じ「書き込み」でも、専用の作業用シートへ追記するのと、会計データを上書きするのでは重さが違います。

そのため、権限はツール名だけでなく、対象と操作を組み合わせて決めます。

AIエージェントの権限管理では、「人の代わりに操作しているのか」「人から仕事を依頼された別の主体として動いているのか」という違いも出てきます。LayerXの権限管理に関する記事では、この違いを「代行か、依頼か」という観点から整理しています。

後から見たときに、人が実行したのか、AIが判断して実行したのか、誰の依頼で動いたのかが分かるようにする。この記録も、権限設計の一部です。

読み取りから始め、少しずつ任せる

AI秘書を最初から完成させようとすると、扱う情報も権限も一気に増えます。

私は、次の順番で任せる方がよいと考えています。

1. 読む

最初は、指定した資料を探す、会議記録を要約する、未処理の項目を一覧にするといった使い方から始めます。

2. 下書きを作る

次に、議事録案、メール返信案、タスク候補などを作らせます。AIは案を出しますが、まだ外部には送りません。

3. 限定した場所へ書く

動作が安定したら、専用の作業用シートへ追記する、指定したフォルダへファイルを作る、決めたSlackチャンネルへ通知するといった操作を許します。

4. 定期的に動かす

最後に、決めた時間や条件で自動的に動かします。失敗時の通知と実行履歴を用意し、安定した作業から承認なしで動かします。

この順番は、必ず一直線に進むものではありません。

人が修正した理由を残し、プロンプト、参照資料、チェックリスト、権限を直します。問題があれば、一つ前の段階へ戻します。

最初から人の確認をなくすのではなく、人が確認しやすい状態を作る。そこから、任せられる範囲を少しずつ広げます。

OpenClaw導入前に確認すること

OpenClawの導入では、少なくとも次を確認します。

• 1つのGatewayに、信頼関係やアクセス範囲の異なる利用者を混在させていないか
• 境界が違う場合、Gateway、認証情報、OSユーザー、必要に応じてホストを分けているか
• 専用のOSユーザー、VM、VPSなどで実行環境を分離できるか
• Gatewayを不用意にインターネットへ公開していないか
• 必要なツールだけを許可しているか
• サンドボックスを使う範囲を決めたか
• 外部送信、削除、コマンド実行に承認を入れたか
• 個人アカウントと業務用アカウントを混ぜていないか
• スキルやプラグインの出所と中身を確認したか
• ログ、通知、停止方法、認証情報の失効方法を決めたか
• 設定変更後にセキュリティ監査を実行したか
• 最新版とSecurity Advisoryを確認したか

OpenClawには、設定を確認するopenclaw security auditがあります。外部公開や設定変更の後は、openclaw security audit --deepで実際のGatewayを含めて確認できます。

ただし、この監査に通れば、業務として安全という意味ではありません。

ツールの設定が正しくても、そもそも必要以上のデータを見せているかもしれません。技術的には許可された送信でも、社内ルールでは人の承認が必要かもしれません。

OWASP Top 10 for Agentic Applications for 2026も、自律的に計画し、判断し、複数の操作を進めるAIエージェントには、従来のチャットAIとは異なるリスクがあるとして、実務向けの確認事項を整理しています。

OpenClawの設定確認と、会社や業務のルール確認は、両方必要です。

何を任せるか分からないところから相談してよい

AI秘書を使ってみたいと思っても、自分の仕事を最初からきれいに説明できる人は多くありません。

どの作業が繰り返しで、どこに判断があり、何を止めるべきか。一緒に作業を見ながらでないと分からないこともあります。

「OpenClawを入れたいが、何を任せればよいか分からない」「AIを使いたいが、自分の業務をどう変えればよいか分からない」という段階から相談してもらって大丈夫です。

最初から大きなシステムを決めるのではなく、まず今の仕事を一緒に分けます。その中から、一つだけ任せられる場所を探します。

普通のプログラムで十分なのか。RPAが向いているのか。AIに読ませた方がよいのか。OpenClawのようなAIエージェント基盤が必要なのか。ツールを決めるのは、その後です。

愛葉では、AI秘書やAI-RPAを入れる前の業務整理から支援しています。何を減らしたいのか、どの情報を扱うのか、どこに人の判断を残すのかを一緒に確認し、現場で使える形にしていきます。

まとめ

OpenClawは、AIにPCや外部サービスを扱う手足を持たせられる強い基盤です。

ファイルを読み書きする。ブラウザを操作する。コマンドを実行する。外部サービスへ連絡する。定期的に仕事を進める。できることは、これからも増えていくと思います。

だからこそ、人間の側が、自分の仕事を理解する必要があります。

何を受け取り、どこで判断し、何を変更し、誰に影響が出るのか。どの権限を渡し、どこで人が確認するのか。異なる信頼関係の利用者を、どのGatewayへ分けるのか。

技術的にできることと、業務として任せてよいことを分けて考える。

読み取りから始める。下書きを作らせる。限定した場所へ書かせる。ログと人の確認を残しながら、安定した仕事だけを少しずつ任せる。

AIエージェントの導入は、AIへ仕事を丸投げすることではありません。人間が自分たちの仕事を見直し、任せ方を決め直すことだと、私は感じています。

参考情報

• OpenClaw GitHub README
• OpenClaw Capabilities Overview
• OpenClaw Exec tool
• OpenClaw Security
• OpenClaw Sandboxing
• OpenClaw Automation
• OpenClaw Releases
• OpenClaw Security Advisories
• OWASP Top 10 for Agentic Applications for 2026
• AIエージェント時代の権限管理が、いまアツい | LayerX

※ 本記事は2026年7月15日時点のOpenClaw公式情報をもとにしています。OpenClawは更新が速いため、導入時は最新の公式ドキュメントとリリース情報を確認してください。