モバイルとウェブに広がるClaude Cowork：チームがエージェントハーネスを再設計すべき理由

はじめに

Claude Cowork が Web とモバイルに対応したことは、単にボタンをクリックする場所が増えたという話ではありません。これは、AI エージェントが短時間のデスクトップ上の対話から、デバイスをまたいで作業を継続できる、より長時間稼働するタスクシステムへと移行しつつあることを示しています。

プロダクト、エンジニアリング、オペレーションの各チームにとって重要なのは、もはやエージェントがタスクを完了できるかどうかだけではありません。より難しい問いは、作業中にエージェントが適切な境界を保てるかどうかです。つまり、どのファイルを読んでよいのか、どのツールを使ってよいのか、どの操作に承認が必要なのか、どのような証拠を返す必要があるのか、そして人間が結果をどのようにレビューできるのか、という点です。

この記事では、その変化が実務上何を意味するのかを説明します。焦点となるのは agent harness の設計です。これは、コンテキスト、ツール、権限、状態、ログ、検証、人間による制御を管理する、モデルの周辺レイヤーを指します。

ソースおよび画像に関する注記

元のソースページ: Claude Cowork 登上移动端与网页端：团队该重新设计 Agent Harness

解析されたソースページには、デフォルトのブログカード SVG とサイト／フッター画像は含まれていましたが、記事本文に明確に必要とされる本文レベルのスクリーンショット、ワークフロー図、コードのスクリーンショット、結果画像は含まれていませんでした。装飾的または無関係な画像の挿入を避けるため、本文には画像を追加していません。将来のソースに製品スクリーンショットや図が含まれるようになれば、対応するセクションの近くに挿入できます。

重要なポイント

• Claude Cowork がデスクトップ、Web、モバイルへと広がったことで、チームはエージェントの作業の捉え方を見直す必要があります。
• クロスデバイス対応のエージェントは、単なるチャット UI ではありません。バックグラウンドで継続できるタスクスレッドです。
• チームには明確な agent harness が必要です。コンテキストの境界、ツール権限、状態追跡、ログ、検証、承認ルールが求められます。
• モバイルアクセスは進捗確認や軽量な確認作業には便利ですが、コードレビュー、本番承認、機密データ管理を迂回する近道にしてはいけません。
• 市場全体も同じ方向に進んでいます。エージェント製品は、単なるモデル選定の問題ではなく、システムエンジニアリングの問題になりつつあります。

何が変わったのか

Claude Cowork は今、同じタスクをあるデバイスで開始し、別のデバイスで継続できるワークフローを示しています。ユーザーはデスクトップから作業を割り当て、スマートフォンで進捗を確認し、席を離れている間にプロンプトへ応答し、その後戻って最終出力をレビューすることができます。

これは便利に聞こえますが、制御モデルも変化します。従来のチャットウィンドウでは、ユーザーは通常、そのやり取りのすぐ近くにいます。しかしバックグラウンドエージェントでは、ユーザーがすべてのステップを能動的に監視していない間も、エージェントがコンテキストやツールを使い続ける可能性があります。

だからこそ、クロスデバイスでのエージェントアクセスは、単なる製品機能以上のものとして扱うべきです。これはワークフロー設計の問題です。ユーザーがデスクトップ、Web、モバイルのどこにいても、タスク自体が独自の境界、証拠要件、承認ルールを備えている必要があります。

なぜこれは Agent Harness の問題なのか

agent harness とは、モデルの周囲にある運用レイヤーです。モデルは次に何をするかを判断しますが、harness は何が許可されるかを決定します。

モデルが何を見られるか、どのツールを呼び出せるか、状態がどのように保存されるか、アクションがどのように記録されるか、失敗がどのように処理されるか、そして次のステップに人間の承認が必要となるのはどのタイミングか。

弱いハーネスの中に強力なモデルを入れても、深刻な問題を引き起こし得ます。誤ったファイルを読み込んだり、想定された範囲外でツールを使ったり、レビューしにくい成果物を作成したり、チームが出力を検証する前に行動を起こしたりする可能性があります。

エージェントが複数のデバイスにまたがって動作する場合、ハーネスの重要性はさらに高まります。タスクはデスクトップで始まり、リモートセッションで継続し、モバイルで確認を求め、その後に文書、コード変更、またはメッセージを生成するかもしれません。権限モデルはデバイスにひもづくのではなく、タスクに追随すべきです。

優れたハーネスは、タスク開始前に次のような実務的な問いに答えます。

• 正確なタスク目標は何か？
• どのコンテキストが許可されているか？
• どのツールが利用可能か？
• どの行動が禁止されているか？
• どのような出力が期待されているか？
• どの検証を実行しなければならないか？
• どの証拠を含めなければならないか？
• 何に人間の承認が必要か？
• エージェントはいつ停止すべきか？

常時稼働エージェントのリスク

バックグラウンドでの作業は有用です。プロダクトマネージャーは、エージェントに顧客フィードバックの整理を依頼できます。エンジニアは、エージェントにログを調査させ、修正案を提案させることができます。創業者は、移動中に投資家向けアップデートの初稿作成を依頼できます。

リスクは、ユーザーが注意深く見守るのをやめた後も、エージェントが動き続けられることです。それ自体が自動的に危険というわけではありませんが、より適切な境界設定が必要になります。

チームは、エージェントの権限を明確なカテゴリに分けるべきです。

モバイルでの確認はワークフローを高速化できますが、適切な承認設計の代わりにはなりません。スマートフォンでのタップは、適切に範囲設定されたアクションを確認するためのものであるべきであり、不明確なタスクに対して広範なアクセス権を与えるものであってはなりません。

コーディングチームが変えるべきこと

1. 実行前にタスクの境界を定義する

すべてのエージェントタスクは、短いタスクブリーフから始めるべきです。ブリーフには、目標、許可されたコンテキスト、許可されたツール、禁止された行動、期待される出力、検証方法、停止条件を含めるべきです。

これはコーディングタスクでは特に重要です。「この問題を修正して」のような曖昧な依頼は、無人で動くエージェントには広すぎます。より安全な形では、問題を特定し、関連するファイルやモジュールを示し、テストコマンドを指定し、差分とリスクに関する注記を必須にします。

1. 答えだけでなく証拠も求める

エージェントの出力には証拠を含めるべきです。コード関連のタスクであれば、それは差分、テスト結果、ビルドログ、そしてリスクに関する簡潔な説明を意味します。調査タスクであれば、出典リンク、信頼度、未解決の

質問。運用タスクにおいては、アクションプラン、影響を受けるシステム、ロールバックに関する注記、承認が必要なポイントを意味します。

目的は、エージェントにより長いレポートを書かせることではありません。目的は、レビューコストを下げることです。

1. リスクとコストに応じてタスクを振り分ける

すべてのタスクに最強のモデルや最長の推論予算が必要なわけではありません。低リスクの整形、要約、分類タスクは、より安価または高速なモデルで十分に処理できることがよくあります。アーキテクチャ変更、移行、本番環境のデバッグ、セキュリティに敏感なタスクには、より強力なモデルと、より厳格なレビューを用いるべきです。

モデルのルーティングは後付けではなく、ハーネスの一部であるべきです。リスクに応じて振り分けを行うチームは、安全性を下げることなくコストを管理できます。

1. メモリを意図的に制限する

エージェントは、安定したプロジェクトメモリから恩恵を受けることがあります。たとえば、リポジトリのルール、よく使うコマンド、命名規則、アーキテクチャに関するメモ、スタイルの好みなどです。

一方で、秘密情報、認証情報、顧客データ、一時的な仮定、未検証の結論を安易に保存すべきではありません。メモリが有用なのは、適切にキュレーションされている場合に限られます。そうでなければ、それは隠れたコンテキストドリフトの新たな原因になります。

実用的なハーネステンプレート

チームは、始めるために複雑なプラットフォームを必要としません。シンプルなタスクテンプレートから始め、一貫して適用すればよいのです。

task_goal: "エージェントが生み出すべき正確な成果を記述する。"
allowed_context:
- "エージェントが参照してよいフォルダ、ファイル、チケット、ログ、ドキュメントを列挙する。"
allowed_tools:
- "ターミナル、ブラウザ、課題管理ツール、ドキュメント、テストランナーなどのツールを列挙する。"
forbidden_actions:
- "本番デプロイは禁止。"
- "外部へのメッセージ送信は禁止。"
- "ファイルやデータの削除は禁止。"
validation:
- "関連するテストまたはチェックを実行する。"
- "コマンド出力を含めるか、検証を実行できなかった理由を説明する。"
expected_output:
- "差分、要約、リスク、次のステップを提示する。"
human_approval_required_for:
- "メッセージ送信"
- "デプロイ"
- "データ削除"
- "権限変更"
stop_condition: "出力が人間のレビューに回せる状態になった時点、または必要なコンテキストが不足している時点で停止する。"

小規模なコード修正では、ローカルブランチ、差分、テスト出力、リスク注記を必須にします。調査ブリーフでは、情報源と確信度を必須にします。リリースチェックでは、ビルドログ、不合格のチェック、ロールバックのヒントを必須にします。顧客データを扱うタスクでは、データ範囲に関する注記とマスキング計画を必須にします。本番環境での操作については、エージェントが計画を準備すべきですが、実行または承認は人間が行うべきです。

異なるエージェントをどう評価するか

チームは、デモや第一印象だけでエージェントを比較するのを避けるべきです。Claude Cowork、Claude Code、OpenAI Codex、GitHub Copilot、Cursor、社内エージェントのようなツールは、同じ時間予算と受け入れ基準のもとで、実際のタスクに対してテストされるべきです。

有用な評価項目には、次のようなものがあります。

• エージェントは、無関係なファイルを過剰に読まずに、正しいコンテキストを特定できるか？
• 安全にツールを使い、求められたスコープ内にとどまれるか？
• 大きくて不明瞭な書き換えではなく、小さくレビューしやすい変更を生み出せるか？
• テスト結果、引用、ログ、その他の根拠を提示できるか？
• いつ止まり、人間の入力を求めるべきかを理解しているか？
• トークン、時間、レビュー工数の面で、その実行コストはどの程度か？
• それを導入するのはどれだけ難しいか？

失敗した結果をロールバックするべきでしょうか？

各タスクは一度だけでなく、複数回実行してください。エージェントは確率的なシステムです。たった一度の見事な実行で信頼性が証明されるわけではなく、逆に一度の悪い実行でそのツールが使いものにならないと判断できるわけでもありません。完了率、失敗の種類、レビューにかかるコスト、有用な出力あたりのコスト、そして復旧に必要な労力に注目してください。

市場のシグナル

Claude Cowork は、より大きな潮流の一部です。AI ツールは、モデル、ツール、権限、メモリ、ログ、評価を組み合わせたエージェントシステムへと進化しつつあります。

Amazon Bedrock AgentCore は、クラウドプラットフォームが管理型のエージェント基盤へと移行していることを示しています。ハーネスエンジニアリングに関する研究上の議論も、同じ考え方を示しています。つまり、モデルの能力は重要ですが、それを取り巻くシステムこそが、そのモデルを信頼して使えるかどうかを左右するのです。OpenAI の Codex に関する資料でも、エージェントループはプロンプト、ツール、実行、コンテキスト管理を含むオーケストレーションの問題として位置づけられています。

実務的な結論はシンプルです。AI 製品の次の段階で勝つためには、最も強力なモデルを選ぶだけでは不十分です。チームには、より良いコンテキスト戦略、より安全なツール権限、永続的なログ、再現可能な評価、そして明確な人間によるコントロールも必要になります。

推奨アクションプラン

第1週：現在のエージェント利用状況を監査する

チームが使用しているすべての AI エージェントまたはコーディング支援ツールを一覧化してください。デスクトップアプリ、Web エージェント、IDE ツール、ブラウザエージェント、社内ボット、モデル API に接続されたスクリプトを含めます。各ツールについて、何を読み取れるのか、何を書き込めるのか、外部アクションを実行できるかどうかを記録してください。

第2週：タスクをリスク別に分類する

タスクを低・中・高リスクのグループに分けてください。

低リスクのタスクには、書式調整、要約、ドラフト作成などが含まれます。中リスクのタスクには、コード編集、データ変換、課題のトリアージなどが含まれます。高リスクのタスクには、本番環境の変更、顧客データの取り扱い、セキュリティ対応、請求内容の変更、外部とのコミュニケーションが含まれます。

第3週：小規模な社内ベンチマークを作成する

直近1か月の実際のタスクから20件を選び、それをベンチマークセットとして使ってください。成功したタスク、失敗したタスク、曖昧なタスク、人間による修正が必要だったタスクを含めます。

完了率、レビュー時間、根拠の品質、トークンコスト、ロールバックの複雑さを測定してください。これにより、マーケティング上の主張に頼るのではなく、エージェントを実務的に比較する方法をチームは持てるようになります。

第4週：指示と検証を標準化する

リポジトリ向けの指示、タスクテンプレート、検証コマンド、ログに関する期待事項、停止条件を追加してください。レビューのプロセスを可視化してください。エージェントが何を変更し、どのように結果を検証したのかを示せない場合、そのタスクは完了したものとして扱うべきではありません。

FAQ

Claude Cowork とは何ですか？

Claude Cowork は、デスクトップ、Web、モバイルなどの対応環境をまたいで Claude にタスクを渡すための、Anthropic のエージェント型ワークフローです。これは、Claude がファイル、ツール、接続されたワークフローを活用しつつ、ユーザーが重要な結果を確認し承認するような、成果ベースの作業向けに設計されています。

モバイル版および Web 版の Claude Cowork が重要なのはなぜですか？

モバイルおよび Web からアクセスできることで、デスクトップ環境の外でもエージェントタスクを監視し、継続しやすくなります。より大きな変化は、エージェント作業がさらに非同期化することです。つまり、チームには権限、レビュー、ログ、そして管理に関する、より強固なルールが必要になるということです。

検証。

エージェントハーネスとは何ですか？

エージェントハーネスとは、コンテキスト、ツール、状態、メモリ、ログ、検証、人による承認を管理する、モデルを取り巻くシステムのことです。これにより、モデルは単なるテキスト生成器から、制御されたワークフローシステムへと変わります。

エージェントの安全性において、モバイルでの確認だけで十分ですか？

いいえ。モバイルでの確認は有用ですが、承認対象は明確に範囲が定められたアクションに限るべきです。外部メッセージの送信、本番システムの変更、データの削除、権限の変更といった機微な操作については、依然として明示的なレビューと、明確に定義された承認ルールが必要です。

コーディングチームは AI エージェントをどのように安全に使うべきですか？

まずは対象を絞ったタスクから始め、明確なコンテキスト制限、レビュー可能な差分、テスト出力、停止条件を整えるべきです。強固な承認ワークフローがない限り、リポジトリ、認証情報、顧客データ、本番システムへの広範なアクセスは避けてください。

コーディングタスクの後、エージェントは何を返すべきですか？

有用なコーディングエージェントの出力には、変更されたファイル、差分の要約、テストまたはビルドの結果、既知のリスク、追加で必要な作業が含まれているべきです。これによりレビューが速くなり、見えにくいミスが紛れ込む可能性を減らせます。

チームは Claude Cowork、Codex、Cursor、Copilot、その他のエージェントをどのように比較すべきですか？

自分たちの実際のワークフローにあるタスクを使い、各ツールを同じ受け入れ基準で評価してください。単一のデモだけで判断するのではなく、完了率、レビューコスト、失敗の種類、出力の根拠、トークンコスト、ロールバックの手間を比較すべきです。

関連ツール

• Claude Cowork: 対応デバイスや各種作業画面にまたがって Claude にタスクを割り当てるための、Anthropic のエージェントワークフロー。
• Claude Code: ターミナルおよび IDE ベースの開発ワークフロー向けの、Anthropic のコーディングエージェント。
• OpenAI Codex: AI 支援によってソフトウェアの構築、編集、レビュー、出荷を行うための、OpenAI のコーディングエージェント。
• GitHub Copilot: コード提案、チャット、レビュー、開発者ワークフローのための GitHub の AI コーディングアシスタント。
• Cursor: コードベースを理解した編集、チャット、エージェント型のソフトウェア開発に重点を置いた AI コーディング環境。
• Amazon Bedrock AgentCore: 大規模に AI エージェントを構築、デプロイ、運用するための AWS インフラストラクチャ。

関連リンク

• Original NxCode Article: この英語版公開記事の元になったソース記事。
• Claude Cowork Product Page: Claude Cowork の機能、対応する利用画面、プラン提供状況に関する公式ページ。
• Use Claude Cowork Safely: 権限、リモートセッション、プロンプトインジェクション、人による監督に関する Anthropic の安全ガイダンス。
• Amazon Bedrock AgentCore Harness GA: 管理型エージェントハーネス基盤に関する AWS の発表。
• [Harness Engineering for Self-Improvement](https://lilianweng.github.

io/posts/2026-07-04-harness/): ハーネスエンジニアリングとAIシステム改善に関するLilian Wengの考察。

• OpenAI Codex Developers: コーディングエージェントとしてのCodexの公式開発者ページ。
• Unrolling the Codex Agent Loop: Codexがモデル呼び出し、ツール、プロンプト、コンテキストをどのようにオーケストレーションするかについてのOpenAIによる技術的解説。

要約

Claude Coworkがデスクトップ、ウェブ、モバイルへと広がったことは有用な製品アップデートですが、その本当の意味はもっと深いところにあります。AIエージェントは、単一のチャットウィンドウの外でも作業を継続できる、持続的なタスクシステムになりつつあります。

チームにとって適切な対応は、エージェントに無制限の自由を与えることではありません。より安全な道は、統制された委任です。つまり、狭いタスク範囲、明示的な権限、レビュー可能な出力、永続的なログ、検証コマンド、そして機密性の高い操作に対する人間の承認です。

強力なエージェントハーネスは、作業を可視化し監査可能にすることで、エージェントをより信頼しやすくします。まずは小さなタスクから始め、実際のワークフローでパフォーマンスを測定し、レビュー工程が十分に強固になってから権限を拡大しましょう。

エージェント業務の未来は、より賢いモデルだけではありません。モデルを取り巻く、より優れたハーネス設計にあります。