予定実行タスクと通常の手動実行タスクは、安全機構において根本的に何が違うのか？
手動実行タスクの核心的な防御は「人がその場にいる」ことだ——システム自体の分類器や隔離機構がどれほど優れていても、動作が実際に起こる前に一目見て、おかしいと感じれば止めることができる。これが最後の、そして最も直接的な防衛線だ。予定実行タスクは、まさにこの防衛線を取り除くために設計されている——その存在意義は、あなたがその場にいなくてもタスクを完了できることにある。つまり予定実行タスクは単に「手動タスクにタイマーを付けたもの」ではなく、安全機構全体から「リアルタイムの人間による承認」という層をまるごと取り除いたものだ。分類器や隔離環境は引き続き機能しているが、人間による最後のチェックがないため、リスクの性質は根本的に異なる。
なぜCoworkのスケジュール機能は、自動承認か承認スキップと組み合わせなければ機能しないのか？
これはスケジュール実行という概念そのものの論理的必然の結果だ。予定実行タスクが依然として「手動承認」に設定されている場合、トリガーされるたびにシステムは立ち止まり、あなたが自ら確認するのを待たなければならない——しかしスケジュール実行の前提そのものが、あなたがその場におらず、リアルタイムで応答しないということだ。この2つは互いに矛盾する。そのため予定実行タスクは、自動承認（システムが先に安全性のスクリーニングを行い、問題ないと判断した場合のみ動作を通す）か、すべての承認をスキップする（一切の介入なしにタスクを最後まで実行する）のどちらかに設定するしかない。これはCoworkが意図的に管理を緩めているのではなく、スケジュール実行という機能の形自体が、そもそも「リアルタイムで人間が監視しない」承認モードとしか両立し得ないということだ。だからこそ公式は予定実行タスクに対して特別に追加の利用警告を出しているのだ。
プロンプトインジェクションのリスクは、予定実行の文脈で実際にどう増幅されるのか？
プロンプトインジェクション攻撃が成功するには、2つの条件が同時に成立する必要がある——Claudeが信頼境界の外にあるコンテンツ（外部から届いたメール、公開ウェブページなど）を読み込むこと、そして実際の結果を伴う動作を実行する能力を持っていることだ。誰かがリアルタイムで見ている状況では、この2つの条件が同時に成立しても、異常な動作は実行の瞬間かその直後に人間に発見され、間に合って止められ、被害は小さく抑えられることが多い。予定実行タスクは「誰かがリアルタイムで見ている」という変数を完全に取り除く——悪意ある指示が紛れ込んだ瞬間から、それが実行を完了するまでの間、人間が介入する機会は一切ない。リスクの露出は「気づかれるまでの数秒間」から「スケジュールサイクル全体が動き続け、いつでもトリガーされうる」まで一気に引き延ばされる。これこそが、予定実行の文脈でプロンプトインジェクションのリスクが増幅される具体的なメカニズムだ。
すでに対外コミュニケーション系のタスクを予定実行にしているユーザーにとって、これは実際どのような影響を与えるのか？
最も直接的な影響は、現在予定実行タスクで使っている承認モードが、そのタスクの動作の性質にふさわしいものかどうかを見直す必要があるということだ。あるタスクがあなたに代わって外部の相手にメールやメッセージを送信するもので、自動承認、あるいはすべての承認をスキップする設定になっている場合、「内容が適切かどうかの判断」を、誰も監視していない状態でClaudeに完全に委ねていることになる——ほとんどの場合は問題なくても、一度誤判断が起きれば、相手からの返信や苦情があって初めて気づくことになりかねない。実践的な対策は、この種の対外コミュニケーション系の予定実行タスクを「Claudeが下書きを準備する」と「あなたが手動で送信を承認する」の2ステップに分け、整理や要約のような本質的に可逆な部分だけを完全自動化に任せ、送信という不可逆な動作は手動承認の範囲に留めておくことだ。
毎週月曜の朝に自動実行されるタスクを組んだ——Claudeが先週のカスタマーサポートメールを読み込み、要約をまとめ、定型的な問い合わせのいくつかに直接返信する。うまく設計できたと少し誇らしく思っていた——ある日、自分が休暇中にタスクが予定通り実行され、自動返信すべきではなかったクレームメールに返信してしまった。文面は丁寧だったが、相手が本当に気にしていた点の読み取りが単純に間違っていた。
問題はタスクの設計が悪かったことではない。予定実行タスクという機能そのものに、公式ドキュメントに明記されているにもかかわらず、ほとんどの人が予定を組む瞬間には目にしていない警告が存在するのだ。
Coworkの安全機構は実に慎重に設計されている——Claudeは強化学習によって悪意ある指示を認識し拒否するよう訓練されており、コンテンツ分類器は信頼できない素材が動作に影響を与える前に潜在的なプロンプトインジェクションをスキャンし、実行はAnthropicのサーバー上の隔離された一時的な環境で行われ、自宅や会社のネットワークにはアクセスできず、セッション終了後には削除される。これらの仕組みは、あなたがその場にいて、いつでも介入できる状況ではうまく機能する。
予定実行タスクはまさにその前提を崩す。公式の表現は率直だ——予定実行タスクは「あなたが不在の間、無監督で実行される」。ポイントはClaudeが間違えるかどうかではなく、たとえ間違えても、その場で誰も止められないという点にある。手動承認の下では、少なくとも動作が実行される前にそれを目にすることができる。しかし予定実行タスクが本当に「タイマーで自動的に」動くためには、自動承認かすべての承認をスキップする設定にする必要がある——つまり、予定実行タスクのデフォルトの動作モードは、設計上すでにリアルタイムの人間による監視という層が取り除かれたものなのだ。
ドキュメントには、予定実行を推奨しないタスクの種類が明確に列挙されている——機密ファイルに関わるもの、あなたに代わってメッセージを送信するもの、購入を行うもの。この警告が見落とされるのは、曖昧に書かれているからではなく、それが「安全ガイド」という記事の中にある一方で、ユーザーは通常「スケジュール設定」のインターフェースからタスクを設定するからだ——この2つは別々のページであり、スケジュール設定のインターフェース自体はこの警告を積極的に表示しない。ユーザーはあらかじめ安全ガイドを読み、このルールを記憶しておかなければ、タスクを設計する際に能動的にそれを避けることができない。
より現実的な状況は、ほとんどの予定実行タスクがそもそも「毎回手動でやりたくない」という動機から始まっており、メッセージ送信や注文といった動作こそが、最も予定実行に適し、最も予定実行したくなる種類だということだ。これはちょうど公式ガイダンスが避けるよう勧めているカテゴリと重なる。言い換えれば、スケジュール設定を最も魅力的にするシナリオは、しばしば最もリスクの高いシナリオでもあり、この緊張関係はインターフェース上では一切警告されず、ユーザー自身が気づくしかない。
プロンプトインジェクションのリスクは予定実行タスクにおいて特に増幅される——Claudeが読み込むコンテンツがあなたの信頼境界の外から来ている場合（外部から届いたメール、ウェブページなど）、かつ同時に実際の結果を伴う動作を実行する能力を持っている場合、この2つの条件が揃うと悪意ある指示がClaudeの動作を乗っ取る機会を得る。誰かがリアルタイムで見ている状況では、異常な動作は素早く発見され止められる傾向がある。しかし予定実行タスクはこの「誰かが見ている」という変数を完全に取り除いてしまい、プロンプトインジェクションのリスクの窓を「気づかれるまでの数秒間」から「スケジュールサイクル全体」へと引き延ばしてしまう。
もう一つ過小評価されがちな制限は、予定実行の文脈においてコンピュータ操作には一切サンドボックスの隔離がないことだ——ファイル操作やコード実行にはある程度の境界があるのに対し、コンピュータ操作はあなたの画面に対して直接動作する。予定実行タスクがコンピュータ操作を伴う場合、「無監督」と「サンドボックスなし」という2つのリスクが積み重なることになる。ネットワークアクセスの権限範囲にも特に注意する価値がある——標準的なネットワークアクセス制限は、web fetchやweb searchツール、MCP接続を制限しない——これらの経路はあなたが設定したつもりのネットワーク境界を迂回してしまうため、これらのツールを使う予定実行タスクは、想定より広い範囲に実際には到達している可能性がある。
どんな作業を予定実行にする前にも、シンプルな分類をしておく価値がある——このタスクの動作は「整理や要約」のような本質的に可逆で、間違えても実害のない種類なのか、それとも「送信、購入、削除」のような一度実行されたら取り消せない種類なのか。前者は予定実行に適しているが、後者は、ワークフロー上は自動化できるとしても、誰かがその場にいる手動承認の状況下に留めておくべきだ。すでに対外的なコミュニケーションや金銭に関わる動作を伴うタスクを予定実行にしているなら、現在どの承認モードを使っているか、そしてそのタスクが読み込むデータの中に信頼境界の外にある部分がないかを、改めて確認する価値がある。