Claude Coworkのスケジュールタスクで、毎週月曜に競合の価格とレビューの一覧表を自動作成する

AmazonとWalmartで小型家電の製品ラインを担当しているなら、競合価格を手作業で確認しているかもしれません。6つの商品ページを開き、数値をシートに写して、先週と比べる作業です。この記事では、その1時間をClaude Coworkのスケジュールタスクに置き換えます。タスクは毎週月曜にクラウドで実行され、カスタムコネクタ経由でデータAPIを呼び出し、変化をまとめた表をGoogle Sheetsに書き込みます。データ側は2026年11月3日に実際の呼び出しでテストしました。Cowork側は実行していないため、ここで紹介するCoworkの手順はすべて設定例であり、Anthropicの情報源へのリンクを添えています。

最も役立った発見はWalmartで得られました。同じWalmartの商品（Ninja Crispiのガラス製エアフライヤー）で、2つの検索キーワードに対して販売者と価格がそれぞれ異なっていました。「ninja air fryer 4 quart」では販売者がPatent Paidで価格は$135、「ninja crispi glass air fryer」では販売者がMercshopで価格は$134.50でした。約1時間後、シンガポール時間の01:13:54と01:14:03に、9秒間隔で両方の検索を再実行しました。それでも、キーワードごとに前回と同じ販売者と価格が表示されました。

つまり、違いは時刻ではなくキーワードによるものです。週次タスクでキーワードが変わると、単に販売者が違うだけなのに、表に$0.50の値下げとして表示される可能性があります。そのため、各商品には固定のキーワードを1つ割り当て、各行には価格と並べて販売者も保存します。

タスク：毎週月曜の競合価格・レビュー表

以下の数値はすべてタスクの定義に左右されるため、まずタスクを定義します。入力は少数の競合をまとめたリストです。各競合について、Amazonの商品を1つ（ASINで識別）、Walmartの商品を1つ（アイテムIDで識別）指定します。例として、4クォートのエアフライヤー3機種を使います。Ninjaのベーシックモデル、Ninja Crispi 4-in-1のガラス製モデル、Instant Vortex miniです。エアフライヤーを選んだのは、どちらのストアでも数多く販売され、価格が頻繁に変動するためです。

タイミングも重要です。Walmartは、2026年11月12日から12月2日まで開催する3つのホリデーセールイベントを発表しました。イベント期間は計14日間で、2025年の10日間より長くなっています（Walmartプレスリリース、Retail Dive）。これからの5週間は、ブランドマネージャーにとって週次の価格チェックが最も必要な時期です。

出力は1つの表です。ストアごと、競合ごとに1行あります。最初の列は今週の価格、定価、割引、販売者、評価、評価数またはレビュー数です。次の列には、先週からの価格の変化とレビュー数の変化を示します。さらに2列で、新しい星1〜2のレビューの数と、その短いメモを示します。最後の列は1行の判断で、「すぐ対応」「様子見」「無視」のいずれかです。

このタスクがスケジュールタスクに向いている理由は3つあります。1つ目は、決まった曜日に繰り返すことです。2つ目は、データを読み取るだけであることです。価格の変更、注文、メッセージ送信は行わないため、エラーが起きてもセルの値が間違うだけで、金銭的な損失にはなりません。3つ目は、前回の実行結果と比較する必要があることです。Coworkで最も注意が必要なのはこの3つ目の点で、後のセクションで詳しく扱います。

セラー向けツールを使わない理由は、表示されるのが競合ではなく自社の出品だからです。Walmart Seller Centerの評価ページには、自社の出品を購入した顧客からのフィードバックしか表示されません。他の販売者の出品に対するレビューは表示されません（Walmart Marketplace Learn）。

Walmartの価格インサイトダッシュボードは自社の価格をBuy Box獲得者の価格と比較しますが、これも対象は自社の商品だけです（Walmart Buy Boxガイド）。競合の情報を見るには、公開されている商品ページを読み取ります。それを行うのがAmazonデータAPIとWalmartデータAPIです。

競合リストはモデルではなく、人が決めるべきです。設定シートに一度だけ書いておきます。各競合について、AmazonのASIN（商品URLの/dp/の後に続く10文字）を記録します。WalmartのアイテムID（商品URLの/ip/の後にある最後の数字）も記録します。たとえば、ピンクのCrispiはhttps://www.walmart.com/ip/20370717802です。さらに商品ごとに検索キーワードを1つ追加し、タスクが検索結果の上位20件からそのIDを見つけられるようにします。

毎週モデルに「同じ商品」を選び直させてはいけません。検索順位は毎週変わります。今週6位の商品が、翌週には25位に落ちることもあります。モデルが新しい「一致商品」を選ぶと、表は異なる2つの型番を比較することになり、変化の列は意味をなさなくなります。固定のIDリストを使えば、これを防げます。

Claude Coworkのスケジュールタスクで現在できること

Anthropicは2026年2月25日、Coworkにスケジュールタスクを追加しました。リリースノートには、Coworkで定期タスクやオンデマンドタスクを作成できると書かれていました（Claudeリリースノート）。当初、タスクは自分のコンピューター上で実行されていました。デスクトップアプリを閉じていたり、コンピューターがスリープしていたりすると、何も実行されませんでした。

これが最も多かった不満です。あるRedditユーザーは、マシンが起動している間しか動かないスケジュールでは意味がないと書いています（Redditスレッド）。この状況は10月に変わりました。

現在ヘルプセンターには、スケジュールタスクはすべての有料プラン（Pro、Max、Ultra、Team、Enterprise）で利用できると記載されています。タスクはリモートで実行されるため、コンピューターがスリープ中でも、デスクトップアプリを閉じていても、スケジュールどおりに実行されます。各実行はそれぞれ独立したCoworkセッションです。実行時には、Coworkで設定したコネクタ、スキル、プラグインを使えます（Schedule recurring tasks in Claude Cowork）。

別のヘルプ記事には、変更日が記載されています。2026年10月6日以降、Pro、Max、Ultraの新しいCoworkタスクはクラウドで実行されます。「Only on your computer」設定は削除され、元に戻すことはできません。10月6日より前から自分のコンピューターで実行されていたスケジュールタスクは、引き続きそこで実行されます。新しいスケジュールタスクはクラウドで実行されます（Use Claude Cowork on web, desktop, and mobile）。

手動でタスクを設定する場合、フォームには6つのフィールドがあります。名前、プロンプト、承認モード、頻度、任意のモデル、任意の作業フォルダーです。頻度の選択肢は、毎時、毎日、毎週、平日、手動のみです。同じ記事には、見落としやすい短い注記があります。

スケジュールタスクがローカルのファイルやアプリを必要とする場合、そのタスクは自分のコンピューター上でしか実行されません（同じヘルプ記事）。そのため、価格表はローカルファイルを必要としない設計にします。データの読み込みも、結果の書き込みもコネクタ経由で行います。そうすれば、ノートPCがスリープしていても、実際にタスクが実行されます。

操作の入口も、人によって表示が異なる場合があります。2026年9月16日、AnthropicはPro、Max、Ultra向けにCoworkとチャットの統合を開始しました。メッセージボックスに「Chat」と「Cowork」の選択肢が表示されなくなっていれば、新しい統合版に切り替わっています。その場合は、どの会話でも「毎週月曜の午前9時にXをして」のような依頼を入力できます。Claudeが名前、スケジュール、指示を表示するので、「Schedule」をクリックして確定します（Claude Cowork and chat are one Claude）。

CoworkのスケジュールタスクとClaude Codeのスケジュールタスクの違い

11月1日に、毎晩Redditのペインポイントを読み取るClaude Codeのスケジュールタスクについてのガイドを公開しました。その記事では、Anthropicが以前「routines」と呼んでいた、Claude Codeのクラウドスケジュールタスクを使いました。どちらの製品も「スケジュールタスク」という名前を使っています。どちらもクラウドで実行され、どちらもサブスクリプションの利用枠を消費します。ただし、向いている作業は異なります。

Claude Codeのクラウドスケジュールタスクは、保存されたClaude Codeの構成です。プロンプト、1つ以上のリポジトリ、コネクタ一式で構成されます。スケジュール、API呼び出し、GitHubイベントのいずれかで起動できます。各実行は完全なClaude Codeセッションで、シェルコマンドの実行、コードの編集、プルリクエストの作成ができます（Automate work with scheduled tasks）。

Coworkのスケジュールタスクにはリポジトリがありません。レポート、ブリーフィング資料、ファイル整理などのナレッジワーク向けです。出力はCoworkセッションとその中のファイルです。

Claude Codeの列は、同じドキュメントページの使用量とトリガーのセクションに基づいています（Claude Code cloud scheduled tasks）。Coworkの列については、スケジュールタスク、TeamとEnterprise、安全性、アーキテクチャの4つのヘルプ記事を読みました。いずれにも、スケジュールタスクの最大数や1時間あたりの実行回数の上限は記載されていません。あるRedditユーザーも同じ質問をしましたが、Anthropicから数値は示されませんでした（Redditスレッド）。そのため、推測はせず「公開された数値は見つかりませんでした」と記載しています。

ブランドマネージャーにとって、選択は明快です。価格表にはリポジトリもコード変更も不要で、マーチャンダイジングチーム向けのシートです。Coworkのほうが適しています。

Claude Codeを選ぶのは、チームがすでにデータとスクリプトをGitで管理している場合に限りましょう。その場合、週ごとの履歴をコミットログに残せます。どちらの構成でも同じリモートMCPアドレスを使えるため、コネクタの設定は一方からもう一方へそのままコピーできます。

EveryInfraをカスタムコネクタとして追加する

Coworkはカスタムコネクタを通じて外部データにアクセスします。ヘルプセンターによると、リモートMCPを使うカスタムコネクタはClaude、Cowork、Claude Desktopで動作します。Free、Pro、Max、Ultra、Team、Enterpriseの各プランで利用でき、Freeユーザーが追加できるのは1つだけです（Get started with custom connectors using remote MCP）。

個人プランの場合は、Customize > Connectorsを開きます。「+ Add」をクリックし、続けて「Add custom connector」をクリックします。名前とリモートMCPサーバーのURLを入力します。

設定で最初につまずきやすいのは認証です。EveryInfraのリモートMCPサーバーは、OAuthではなくAPIキーを使います。initializeとtools/listメソッドはキーなしで動作します。ツール呼び出しでは、Authorization: Bearerの後にAPIキーを続けたヘッダーが必要です（EveryInfra MCPセットアップページ）。MCP仕様では認可は任意とされており、そのOAuthフローはサーバーが対応している場合にのみ適用されます（MCP仕様：Authorization）。Authorization: Bearerヘッダーの形式は、OAuthのベアラートークン標準に由来します（RFC 6750）。

シンガポール時間11月3日00:47に、キーなしでtools/callを1回送信しました。サーバーは0.09秒でunauthorized: no API key providedを返し、続くテキストブロックには「Nothing was charged.」（課金は発生していません）と表示されました。

Anthropicのドキュメントには、APIキー方式のサーバーでの手順が記載されています。Authenticationで「No sign-in」を選択し、Request headersにキーを追加します。Claudeは値を暗号化し、再表示はせず、リクエストごとに送信します。Claudeは入力された値をそのまま送信し、プレフィックスは付けません。そのため、Authorizationの値はBearerという語、半角スペース、キーの順にする必要があります（Add a connector that isn't in the directory）。

Configuration example (Customize > Connectors > + Add > Add custom connector).
Field names follow the Anthropic documentation. We did not run this on our machine.
Name:            EveryInfra
MCP server URL:  https://api.everyinfra.com/mcp
Authentication:  No sign-in
Request headers: Authorization = Bearer <your EveryInfra API key>
Advanced > Transport: keep the default (the URL does not end in /sse, so it uses Streamable HTTP)

2つ目の問題はネットワークです。ヘルプセンターには「Network requirements」というセクションがあります。カスタムコネクタを追加すると、ClaudeはユーザーのコンピューターではなくAnthropicのクラウドからMCPサーバーに接続します。これはclaude.ai、Claude Desktop、Cowork、モバイルアプリのいずれでも同じです。サーバーは、AnthropicのIPレンジから公開インターネット経由で到達できる必要があります。

社内ネットワーク上、VPNの内側、ファイアウォールの内側にあるサーバーには接続できません。自分のコンピューターからは到達できる場合でも同様です（ヘルプセンター）。Anthropicは、外部MCPツールへの呼び出しに使う送信元アドレス範囲として160.79.104.0/21を公開しています（IP addresses）。EveryInfraのアドレスは公開されているため、このルールの影響は受けません。ただし、IT部門が前段に社内ゲートウェイを置く場合は、この範囲を許可する必要があります。

3つ目の問題は、TeamプランとEnterpriseプランでの認証情報の共有です。Teamプランでは、組織にカスタムコネクタを追加できるのはOwnerとPrimary Ownerのみです。Enterpriseでは、ライブラリ管理の権限を持つカスタムロールも追加できます。Ownerがコネクタを追加した後、各メンバーがCustomize > Connectorsを開いて「Connect」をクリックします。

ヘルプセンターでは、この設計について説明しています。コネクタがAPIキーなどの共有認証情報を使わない限り、Claudeがアクセスできるのは各メンバーがアクセスできる範囲だけです。TeamとEnterpriseでは、そのコネクタを使うすべてのメンバーが同じ認証情報を使います。そのため、その認証情報にはメンバーに必要なアクセス権だけを与えてください（ヘルプセンター）。

EveryInfraの場合、キーを共有すると、全メンバーのスケジュールタスクが同じアカウントに課金されます。Cowork専用のキーを別に1つ用意し、1分あたりの上限を低めに設定することをおすすめします。そうすれば、不適切なプロンプトがAPI呼び出しをループしても、そのキーの上限に達した時点で停止します。また、コネクタを追加した後は認証設定を編集できません。キーを変更するにはコネクタを削除して再度追加する必要があり、メンバーも接続し直す必要があります（Anthropicのドキュメント）。

Anthropicはリクエストヘッダー名も審査しています。承認されていないヘッダー名を使うと、保存時にエラーになります。EveryInfraが使うのは標準のAuthorizationヘッダーだけです。キーを?key= URLパラメータとして渡すこともできますが、URLはより多くのログに残るため、Coworkでの利用はおすすめしません。

ツールの承認：タスクを手動で1回実行

スケジュールタスクは誰も見ていないときに実行されます。そのため、結果が空になる原因として最も多いのが承認プロンプトです。安全に関する記事では、3つの承認モードが紹介されています。「Automatically approve」は各アクションの前に安全チェックを実行してから続行します。「Skip all approvals」はチェックを一切行いません。

「Manually approve」は各ステップで確認を求めます（Use Claude Cowork safely）。同じ記事では、要約のような低リスクのタスクから始めるよう勧めています。また、メッセージの送信や購入を行うタスクはスケジュールしないよう求めています。読み取り専用の競合比較表は、まさに推奨されている種類のタスクです。

EveryInfraの12個のMCPツールにはすべて、MCP仕様のツールアノテーションが付いています。11月3日にtools/listを確認しました。カタログツールeveryinfra_list_capabilitiesとジョブ取得ツールeveryinfra_get_jobはreadOnlyHint: trueです。データツールeveryinfra_call_apiは費用が発生するため、readOnlyHint: falseとdestructiveHint: trueが設定されています。

MCP仕様では、これらの値をヒントと呼んでいます。クライアントはこれを使って、先に人に確認するかどうかを判断できます。アノテーションのないツールは、破壊的な操作を行う可能性があるものとして扱われます（MCP仕様：Tools、ツールアノテーションに関するMCPブログ）。

これはTeamとEnterpriseで特に重要です。Teamプランのヘルプ記事では、「Allow 'Always allow' for connector tools」という組織設定が説明されています。この設定はデフォルトでオフです。オフの間、メンバーはCoworkの承認プロンプトで「Allow for all tasks」を選択できません。

書き込みを行うツールについては、以前に選んだ「always allow」も無効になります。プロンプトを省略できるのは、コネクタが読み取り専用としてマークしたツールだけです（Use Claude Cowork on Team and Enterprise plans）。このルールにより、デフォルト設定のままではeveryinfra_call_apiはタスクごとに承認を求めます。

当社にはTeamプランの組織がないため、スケジュール実行がこのステップで待機するのか、スキップするのかは検証できませんでした。安全に進めるには、Ownerにこの設定をオンにしてもらうか、タスクの承認モードを「Automatically approve」に設定してください。タスクを作成したら、「Run now」を1回クリックします。承認プロンプトが表示されたら、「Allow for all tasks」を選択します。

最近のアップデートにも承認に関わるものがあります。10月22日のデスクトップアプリv3.6556.1で、サーバー側で人による確認が必要とマークされたMCPツールの挙動が変わりました。これらのツールはアプリ内のカードでのみ確認を求めるようになり、通知にはAllowボタンが表示されません。スケジュールタスクは、これらの呼び出しを行わずに続行します（Claude Desktop changelog）。EveryInfraのツールはこのマーカーを使用しておらず、使っているのは4つの標準アノテーションだけです。

スケジュール実行時に承認プロンプトがどのように表示されるか、また実行が停止するかどうかは、Cowork上では検証していません。そのため、「Run now」を1回クリックして、このステップを自分の目で確認してください。

このルールが対象とするのはCoworkの組み込みWebフェッチで、MCPツールではありません。ただし、Anthropicがスケジュールタスクでできることをいまも週単位で調整していることがわかります。ツール名とパラメータを正確に指定したプロンプトのほうが、モデルにやり方を自分で探させるプロンプトよりも安定します。

実際の1往復：モデルが送るものと返ってくるもの

Coworkでは実行していません。ただし、モデルがコネクタ経由で送るのは、標準のMCP tools/callリクエストです。実際の形式を示すため、2026年11月3日00:25:46（シンガポール時間）に、同じリクエストをcurlでhttps://api.everyinfra.com/mcpに送信しました。テストキーを使い、「ninja crispi glass air fryer」でwalmart/searchを呼び出しました。

43.6秒後、サーバーはHTTP 200を返しました。結果には13,115文字のテキストブロックが1つあり、20件の商品が含まれていました。料金は$0.001389でした。

// Request: the tools/call that the model sends through the connector
// (November 3, 2026, 00:25:46 Singapore time; real request; the key is in the header and not shown)
{"jsonrpc":"2.0","id":8,"method":"tools/call",
 "params":{"name":"everyinfra_call_api",
           "arguments":{"platform":"walmart","action":"search",
                        "params":{"keyword":"ninja crispi glass air fryer"}}}}

// Response: JSON inside result.content[0].text (result 2, unchanged)
{"item_id": "20370717802",
 "name": "Ninja Crispi 4-in-1 Portable Glass Air Fryer Cooking System FN101PK1, ...",
 "price": 134.5, "was_price": 179.99, "currency": "USD",
 "rating": 4.5, "rating_scale": 5, "review_count": 1877,
 "in_stock": true, "seller_name": "Mercshop", ...}
// Billing in the same response: {"charged": true, "charged_usd": 0.001389, ...}

同じセッションでは失敗したやり取りも1回あったため、起きたとおりに報告します。シンガポール時間00:24:06に、MCP経由でNinja AF101（ASIN B07FDJMC9Q）を対象にamazon/reviewsを呼び出しました。88.8秒後、isError: trueが返されました。理由は、この商品のレビューページにはログインが必要か、アクセスが制限されているというものでした。この呼び出しの料金は返金され、charged_usdは0で、レスポンスにはすぐに再試行しても改善する見込みは低いとも書かれていました。カタログにはもともと、amazon/reviewsは商品ページに表示される注目のレビューのみを返し、通常は1商品あたり12件程度であると記載されています（EveryInfraカタログ）。

そのため、Amazonの行ではレビュー本文を読み取りません。amazon/searchの評価と評価数をレビューのシグナルとして使います。レビュー本文はWalmartから取得します。ご自身のカテゴリでAmazonのレビュー本文が重要な場合は、まず自社のASINでamazon/reviewsを試してください。

テスト1：2つのストア間の価格差

最初のスナップショットは、シンガポール時間00:15:54から00:26:55まで実行しました。「ninja air fryer 4 quart」でamazon/searchを1回呼び出したところ、36.8秒で20件の結果が返され、料金は$0.002236でした。walmart/searchはNinja 4クォート、Ninja Crispi、Instant Vortex miniについて1回ずつ、計3回呼び出し、料金は各$0.001389でした。下の表の数値はすべて、これらのレスポンスからそのまま取ったものです（Amazon検索API、Walmart検索API）。

1行目は注意して見てください。$60.99の差は大きく見えますが、AF101とAF100WMは別のモデルです。AF100WMのWalmartでの商品名には「3 Functions」とあり、AF101は「4-in-1」です。小型家電では、小売店専用モデルが一般的です。

ブランドとサイズで商品を照合すると、表には毎週、意味のない大きな差額が表示されます。競合製品はモデル番号で照合してください。モデルが一致しない場合は、その行に印を付け、差額は計算しないでください。

割引率にも同じ注意が必要です。同じAmazon検索では、20件中15件に参考価格が表示されており、割引率は8.0%から44.4%まででした。参考価格は出品ごとに独自に設定されるため、ある商品の40%割引と別の商品の20%割引を比べてもほとんど意味がありません。最終価格を追跡し、割引率は同じ出品を週ごとに比較する場合にのみ使ってください。

Walmartの検索結果にはupcフィールドがあります。カタログによると、UPCはストアをまたいで同じ商品を照合する最も正確な方法です。同じ注記には、メインのソースが利用できない場合、このフィールドが欠落することがあるとも書かれています。今回の3件のwalmart/searchレスポンスには、いずれもupcの値がありませんでした。そのため、照合リストは人が一度作成し、タスクは毎週同じIDを読み込むようにしてください。毎週モデルに照合を推測させないでください。

2つ目の発見は、Amazonの評価数がバリエーション間で共有されていることです。同じ検索で、Instant Pot VortexのASIN 3件（B08R6KMBQT、B0F9B4YCZF、B0F9B48Q1B）はいずれも評価数が36,519でした。Ninja CrispiのASIN 4件（FN101の3色とFN103の1件）はいずれも8,426でした。色や型番の末尾は違っても数が同じなので、1つのバリエーションファミリーとして評価数を共有しています。4件のCrispiのうち1件は5-in-1のFN103で、4-in-1のFN101とは機能も異なります。

「今週Amazonの評価数が200増えた」を特定の1色の販売シグナルとして読むと、ファミリー全体のレビューをその色の実績として扱ってしまいます。表ではこの数値を「ファミリー評価数」と表記し、それを共有するASINを列挙しています。

テスト2：1つの商品、2つのキーワード、2つの販売者

00:16:52に「ninja air fryer 4 quart」で実行したwalmart/searchの呼び出しでは、Crispi FN101PK1（商品20370717802）は6番目の結果でした。価格は$135、旧価格は$179.99で、販売者はPatent Paidでした。00:25:46に「ninja crispi glass air fryer」で実行したMCPのwalmart/searchの呼び出しでは、同じ商品が2番目の結果でした。価格は$134.50、旧価格は変わらず、販売者はMercshopでした。2回の呼び出しは約9分間隔だったため、当初はその間に販売者が変わったと解釈しました。

約1時間後の2回目のスナップショットで、この解釈が誤りだとわかりました。シンガポール時間01:13:54、1つ目のキーワードでは、Crispiが再び6番目の結果に表示され、販売者はPatent Paid、価格は$135でした。その9秒後の01:14:03、2つ目のキーワードでは再び2番目の結果に表示され、販売者はMercshop、価格は$134.50でした。この違いは時間ではなく、キーワードによるものです。

これはWalmart自身のルールで説明できます。1つの商品ページに、複数の販売者からのオファーが存在することがあります。「Add to cart」ボタンの上に表示される販売者がBuy Boxを獲得しています。Walmartは価格、送料、配送スピード、販売者のパフォーマンス、顧客の所在地をもとに獲得者を決めます（Walmart Buy Boxガイド）。同じガイドでは、Walmart Repricerを有効にして価格を自動で変更するよう販売者に勧めています。

価格ルールのページには、もう1つの仕組みが記載されています。Walmartは、Walmart.comや他サイトでの最近の価格を大きく上回るオファーを自動的に非公開にします。それほど極端でない場合は、商品ページから「Add to cart」ボタンと価格が削除されます（Walmart価格ルール）。つまり、サードパーティの販売者が多い商品では、1つの商品IDに複数のオファーがひもづいています。ただし、これらのルールでは、同じ時点で2つのキーワードによる検索結果に異なる販売者が表示された理由は説明できません。原因はわからないため、観察した事実のみを記録しています。

そのため、各行では価格と併せて販売者を記録します。ルールは3つです。各商品には設定タブで固定キーワードを1つ割り当て、タスクは毎週同じキーワードを使います。行のキーはストア＋商品ID＋販売者名です。販売者が変わった場合は行に「販売者変更」フラグを付け、タスクでは価格変更として報告しません。

レビューデータからは、1つの商品に販売者がどれだけいるかがわかります。Crispiのレビュー100件のうち30件に販売者名があり、その30件は7社の販売者によるものでした。Walmart.comが11件、Shark Ninja Storeが10件、SDG Distributionが4件で、残り4社がそれぞれ1〜2件でした。Ninja基本モデルのAF100WMでは、100件中98件がWalmart.comでした。販売者が多いほど、表で混同しうるオファーも増えます。

テスト3：レビュー（低評価の一部は配送に関するもの）

シンガポール時間00:19:07に、同期のwalmart/reviews呼び出しでNinja AF100WMのレビュー100件を取得しました。結果は66.1秒で返されました。00:22:20には、Crispi FN101PK1を対象に同じ呼び出しを非同期モードで送信し、00:23:49に結果を受け取りました。料金はいずれも$0.001389でした（WalmartレビューAPI）。

ここで最も役立つ数値は、低評価のうち商品とは無関係なものがどれだけあるかです。判定にはシンプルなキーワードルールを使いました。receive、deliver、ship、arrive、package、address、DHL、「never got」などの語を含むレビューを「配送」に分類します。このルールでは、AF100WMの低評価12件中5件、Crispiの20件中6件が配送に関するものでした。短い例としては「Never got it」「Delivered to wrong address」のほか、DHLの注文が届かないという苦情があります。

Walmartのレビューガイドラインでは、商品レビューは商品とその使用体験に焦点を当てるべきだとしています（Walmartのレビュー規約）。しかし実際には、配送に関する苦情も投稿され、評価を下げています。ブランドマネージャーにとって、ここからわかることは2つあります。低評価の割合が高い競合商品でも、商品自体に問題があるとは限りません。サードパーティの販売者による配送に問題がある可能性があるためです。また、自社の低評価の大半が配送に関するものであれば、商品を改良しても解消しません。そのため、表では低評価を「商品」と「配送・販売者」の2列に分けています。

もう1つ注意すべき点は、100件のレビューの対象期間です。AF100WMのレビューは2025年7月から2026年10月にわたります。Crispiは100件中93件が2026年8月から10月に集中しています。並び順は厳密な新着順ではありません。

AF100WMのレビューのうち最初の30件には、6月、9月、10月の日付が混在しています。そのため、このサンプルから「今週の新規レビュー」を数えることはできません。サンプル内では、AF100WMのレビュー5件が10月27日〜11月2日、4件がその前の週に該当します。これはサンプル内の件数であり、総数ではありません。

今週のレビュー総数から先週の総数を単純に引かないでください。テスト4を見ると、その理由が分かります。新たな低評価については、先週のreview_idの値を保存しておき、まだ見ていないIDだけを数えます。

考慮すべき遅延もあります。Walmartによると、新しいレビューがサイトに表示されるまでに5〜7営業日かかります（Walmartのレビュー規約）。WalmartはMarketplaceの顧客に、配送または受け取りの7日後にレビュー依頼メールを送ります。顧客がそれを開封しない場合は、28日後に2通目のメールを送ります（Walmart Marketplace Learn）。

つまり、月曜日の「新たな低評価」の多くは2〜3週間前の注文によるものです。競合が先週、販売数を伸ばすために値下げした場合、そのレビューへの影響が表に現れるのは2〜3週間後です。この遅延は判断列に反映しています。価格が変化した場合は、同じ週に注記を出します。レビューが変化した場合は、少なくとも2週間待ってから対応します。

テスト4：1つのレスポンス内で1つの数値項目が取る3つの値

数値そのものが安定していなければ、週次比較は成り立ちません。1つのセッションで、AF100WMのレビュー数を3つのツールから読み取りました。00:16:52のwalmart/searchの呼び出しでは12,571でした。00:21:10に送信し00:22:03に読み取ったwalmart/product_detailのジョブも12,571でした。

00:19:07のwalmart/reviewsの呼び出しでは、100件のレビューが返されました。各レビューには総数を示すproduct_review_countフィールドがあります。その1つのレスポンス内で、このフィールドには3つの値がありました。12,562が40件、12,571が40件、12,573が20件です。約1時間後の2回目の呼び出しでは、同じ100件のreview_idが返されました。このときの内訳は、12,562が20件、12,571が40件、12,573が40件でした。

1つのレスポンスの中でさえ、値が11件分ずれることがあります。そのため、最初のレビューだけを読まないでください。また、週ごとの総数を引き算して新規レビュー数を求めないでください。

週次の表では3つのルールを使います。1つ目は、各指標を毎週同じツールから読み取ることです。2つ目は、100件のレビューの中で最も大きいproduct_review_countを採用することです。最頻値は安定しません。最初のレスポンスでは、12,562と12,571がそれぞれ40件で並んでいます。

両方の生レスポンスに対してPythonを実行しました。statistics.multimode()は最初のレスポンスに対して2つの値を返します。statistics.mode()は同数の場合に最初に見つかった値を返すため、1回目は12,562、2回目は12,571になります。すると表には、存在しない新規レビューが9件と表示されます（statisticsのドキュメント）。最大値はどちらも12,573でした。

3つ目は、総数の先週との差が15件以下なら「変化なし」と記録することです。15件という基準は、2つのサンプルで見られた11件のばらつきをもとに設定しました。プラットフォームのルールではありません。数週間運用したら、自社のデータに合わせて調整してください。

2つ目の意外な点は、walmart/product_detailに価格がないことです。2つの詳細レスポンスに含まれていたのは、id、url、name、text、brand、rating、rating_scale、review_count、image_url、platformのフィールドだけでした。カタログではこのアクションにprice、original_price、in_stock、seller_nameが記載されていますが、いずれも含まれていませんでした（Walmart商品詳細API）。表はこれを前提に設計しています。

価格、値下げ前価格、出品者はwalmart/searchから取得します。商品が検索結果の上位20件から外れた場合は、詳細の呼び出しで評価とレビュー数を補います。モデル名の表記を確認する際にも役立ちます。

最初に同期モードで詳細呼び出しを行ったところ、88.0秒後にHTTP 503が返され、料金はかかりませんでした。"mode":"async"を指定すると、ジョブIDは2.0秒で返り、結果は約53秒後に取得可能になりました。

これらの時間は、スケジュールされたタスクにとって何を意味するでしょうか。週1回の実行で10回の呼び出しを行います。順番に実行すると7〜8分かかり、最も遅いのはreviewsとdetailの呼び出しです。プロンプトでは、detailとreviewsの呼び出しを非同期モードで送信するようタスクに指示します。タスクはその後、各結果をeveryinfra_get_jobで読み取ります。ツールの説明によると、ジョブの読み取りは無料で、1分あたりの制限にもカウントされません。

タイムアウトした同期呼び出しは再送しないでください。503レスポンスには「Not charged」と記載され、20秒後の再試行（最大2回）と非同期モードの利用が推奨されていました。あるRedditユーザーは、無人実行の主なリスクを次のように説明しています。

429エラーやネットワークの一時的な障害が起きると、エージェントは素直に再試行せず、次々と独創的な回避策を試し始めます。対策は、タスクに「Xが失敗したら停止して報告し、自分で修正しようとしないこと」と書いておくことです（Redditのスレッド）。

今週と先週の比較：データの保存場所

これが、Coworkのスケジュールされたタスクと通常のチャットとの最大の違いです。アーキテクチャの記事によると、クラウドセッションでは、Claudeのループとコードは、Anthropicがホストする隔離された一時的なサンドボックスで実行されます。セッションごとに専用のサンドボックスが割り当てられます。サンドボックスはセッション開始時に作成されて終了時に破棄され、サンドボックス間で状態は共有されません（Claude Coworkアーキテクチャの概要）。そのため、今週月曜日の実行で作成したCSVは、翌週月曜日の実行からは参照できません。

クラウドセッションでは、お使いのコンピューターで接続したフォルダーを読み書きできます。ただし、それができるのはデスクトップアプリが開いている間だけです（Use Claude Cowork on web, desktop, and mobile）。これでは、コンピューターを起動したままにしておく必要があるという従来の問題が再び生じます。

おすすめはGoogleスプレッドシートです。ヘルプセンターによると、Googleスプレッドシートコネクタでは新しいスプレッドシートの作成と編集ができます。検索、アップロード、共有はGoogleドライブコネクタが担います。同じ記事では、「Google」という語を付けず、単に「doc」と依頼すると、代わりにローカルファイルが作成されると注意しています（Use Google Workspace connectors）。

Microsoft 365を使っているチームは、コネクタの書き込みツールを有効にできます。これらのツールで、OneDriveやSharePointにファイルを作成・更新できます（Set up the Microsoft 365 connector）。タブは2つで十分です。snapshotsタブには毎週新しい生データの行を、changesタブには毎週の比較結果を追加します。

比較が正しくなるかどうかはキーで決まります。週には、Pythonのdate.isocalendar()が返す年と週番号を使います。そうすれば、年や月の境目でもエラーが起きません（datetime documentation）。2026年11月2日（月）は2026-W45、11月9日（月）は2026-W46に含まれます。

行のキーは、ストア、商品ID、販売者の組み合わせです。レビューはreview_idで重複を除去します。

# Comparison logic example. It runs in the Cowork session's code tool.
# We ran it on our machine with two real snapshots.
def key(r):  # store + item ID + seller
    return (r["store"], r["item_id"], r.get("seller_name") or "-")

def diff(last_week, this_week):
    prev = {key(r): r for r in last_week}
    prev_item = {(r["store"], r["item_id"]): r for r in last_week}
    out = []
    for r in this_week:
        p = prev.get(key(r))
        if p is None and (r["store"], r["item_id"]) in prev_item:
            out.append({**r, "flag": "seller change", "seller_before": prev_item[(r["store"], r["item_id"])].get("seller_name")})
        elif p is None:
            out.append({**r, "flag": "new"})
        else:
            out.append({**r, "price_change": round((r["price"] or 0) - (p["price"] or 0), 2),
                        "count_change": (r.get("review_count") or 0) - (p.get("review_count") or 0),
                        "flag": "price change" if r["price"] != p["price"] else ""})
    return out

2つのスナップショットによる実際の比較

比較コードを実データでテストするため、1回目の約1時間後に2回目のスナップショットを取得しました。実行時間は2026年11月3日のシンガポール時間01:12:58から01:15:52で、パラメータは同じです。呼び出しは5回で、内訳はamazon/searchが1回、walmart/searchが3回、AF100WMに対する非同期のwalmart/reviewsが1回です。課金額は$0.007792でした。

続いて、両方のスナップショットを前述のdiff()関数に渡し、ストア、商品ID、販売者をキーとして比較しました。実際のレポートでは2週間分を比較します。今回は間隔が1時間なので、このテストで分かるのは手法と、自然に変動するフィールドです。

1時間のあいだに、追跡中の6行はいずれも価格、販売者、評価数、レビュー数が変わりませんでした。AF100WMのレビューを2回目に呼び出したところ、同じ100個のreview_idが同じ順序で返りました。そのため新規レビュー数は0です。product_review_countフィールドも同じ3つの値のままでした。変わったのは内訳だけで、40/40/20から20/40/40になりました。最大値はどちらも12,573だったため、ルールは「変化なし」と記録します。

一方、Amazonの検索順位は変化しました。同じキーワードの上位20件のうち、17件のASINは2回とも現れ、3件は新たに現れました。AF101は2位から14位に下がりました。Crispiは9位から1位に上がり、Vortexは3位から4位になりました。

タスクが「上位の結果」を選ぶのではなく、固定のASINを読み取るのはこのためです。価格が変わらなくても、順位は1時間で大きく動くことがあります。順位で商品を突き合わせる表では、実際にはない変化が多数表示されます。

同じコードで、キーワードを変えた場合のテストもしました。Crispiの2行目を「ninja air fryer 4 quart」の結果に置き換えました。この結果ではPatent Paidが$135で表示されます。diff()の出力は「price up $0.50」ではなく「seller change, before: Mercshop」でした。これがキーに販売者を含める理由です。この行に対するdiff()の実際の出力は次のとおりです。

{"store": "walmart.com", "item_id": "20370717802", "seller_name": "Patent Paid", "price": 135, "review_count": 1877, "flag": "seller change", "seller_before": "Mercshop"}

2回目のスナップショットでは、walmart/searchの3回の呼び出しにかかった時間は5.9〜8.7秒で、1回目は35.8〜43.6秒でした。レスポンスには、結果がキャッシュから返されたかどうかを示すフィールドはありません。そのため、変化は呼び出しにかかった時間ではなく、スナップショットのフィールドで判断してください。

プロンプトと出力テーブル

Coworkのスケジュール済みタスクは、毎回同じように実行される保存済みのプロンプトです。ヘルプセンターでは「Create with Claude」について説明しています。Claudeがいくつかの選択式の質問をした後、名前、スケジュール、手順を表示して確認を求めます（Schedule recurring tasks in Claude Cowork）。おすすめは「Set up manually」と以下のプロンプトです。ツール、パラメータ、失敗時のルールを固定したリストのほうが、モデルが毎週考え直すプロンプトよりも安定します。

「Weekly」を選び、月曜日の朝の時刻を指定します。手動設定のフォームでは、モデルのフィールドは任意です。Redditユーザーの報告によると、タスクの編集ページにもモデル設定があります（Reddit thread）。このタスクは主にツールを呼び出して表を埋めるだけなので、低コストのモデルで十分です。

Configuration example: scheduled task prompt
(Set up manually. Frequency: weekly, Monday 09:10. Approval mode: Automatically approve.)

You are a competitor report assistant. Read only. Do not order, change prices or send messages.
Use only the EveryInfra connector and the Google Sheets connector.
1. Open the Google Sheets file "Competitor weekly" (create it if missing).
   Read all rows in the snapshots tab for the previous ISO week (for example 2026-W45).
2. Read the config tab. One row per competitor: key, amazon_asin, walmart_item_id, walmart_keyword, model.
3. Call everyinfra_call_api: platform=amazon, action=search,
   params={keyword: "ninja air fryer 4 quart", limit: 20}.
   Keep only ASINs from config. Record price, list_price, rating, rating_count (label it family rating count).
4. For each competitor:
   a. platform=walmart, action=search, params={keyword: walmart_keyword}.
      Find walmart_item_id. Record price, was_price, seller_name, rating, review_count.
   b. If step a did not find the ID: platform=walmart, action=product_detail,
      params={url: "https://www.walmart.com/ip/<ID>"}, mode=async. Record rating and review_count only.
   c. platform=walmart, action=reviews, params={url: same, limit: 100}, mode=async.
      Read the result with everyinfra_get_job. Keep only review_id values not seen last week.
      Split new 1-2 star reviews into "product" and "delivery or seller". Write one sentence for each.
5. If a call fails: record the error and request_id, skip that item, retry at most once, do not try other methods.
6. Append this week's rows to snapshots. Key: week + store + item ID + seller.
7. Compare with last week on that key. Append to changes: price change, seller change,
   review count change, new low ratings and summary, action.
8. At the end, show this week's changes rows in the session, sorted by action.
   State how many API calls ran and how many failed.

週間・月間のAPIコスト

カタログ価格でのコストは次のとおりです。amazon/searchは1回あたり$0.002236（1,000回あたり$2.236）です。walmart/search、walmart/product_detail、walmart/reviewsは1回あたり$0.001389（1,000回あたり$1.389）です。これらのprice_usdの値は、2026年11月3日のシンガポール時間00:15に無料のカタログから取得しました。失敗した呼び出しと空の結果には課金されず、非同期ジョブの結果の取得は無料です。以下の数値はすべて、これらの価格からスクリプトで算出しました（料金）。

サブスクリプションと比べると、APIコストはわずかです。競合3社を週1回追跡する場合の費用は月$0.0639で、月額$20のClaude Proの0.32%です（Claudeの料金）。実質的な負担となるのはClaudeの使用量です。ヘルプセンターによると、Coworkは複雑な複数ステップのタスクを処理します（Get started with Claude Cowork）。claude.ai、Claude Code、Claude Desktopでの使用量は、共通の1つの上限にカウントされます。有料プランには、5時間ごとにリセットされるセッション上限と週間上限があります（How do usage and length limits work）。

スケジュール実行のたびに、この上限枠を消費します。20件の結果を含むAmazon検索1回分は71,614バイト、レビュー100件は約60,000バイトです。モデルがこれをすべて読み込むと、1回の実行で上限枠を大きく消費します。そのため、プロンプトでは設定タブにIDだけを保持し、新しいレビューだけを読むよう指示しています。

制限事項と未解決の点

1つ目に、今回のテストではAmazonのレビュー本文を取得できませんでした。AF101に対するamazon/reviewsは「needs a login or is restricted」を返し、返金されました。正常に動作した場合でも、カタログによると、返されるのは商品ページに掲載された12件前後の注目レビューのみです。そのため、表のAmazon側には価格、定価、評価、バリエーション全体の評価数しかありません。

第2に、今回のテストではwalmart/product_detailはどちらの商品についても価格、在庫、販売者を返しませんでした。価格はwalmart/searchから取得する必要があります。検索は20件の結果を1ページで返します。競合が上位20件から外れたら、より具体的なキーワードを使ってください。

3つ目に、多くのブランドマネージャーはTemuも追跡しています。しかし、カタログではtemu/searchが一時停止中です（available: false）。呼び出すと503が返り、課金はされないため、今回のバージョンの表にはTemuを含めていません。

4つ目に、Cowork側はテストしていません。承認、コネクタ、Google Sheetsへの書き込み、モデルの選択は、すべてAnthropicのヘルプセンターとドキュメントに基づいています。Teamプランで「Always allow」がオフの場合にスケジュール実行がどう動作するかは、テストできませんでした。

5つ目に、この表は自社の価格設定と製品に関する判断にのみ使用してください。2024年8月のFTC規則は、偽レビューの販売と購入を禁止しています。また、肯定的または否定的なレビューへの対価の支払いや、否定的なレビューの抑制も禁止しています（FTCプレスリリース、16 CFR Part 465）。競合商品に低評価が多く付いた場合は、自社の製品と配送を改善してください。競合のレビューに影響を与えようとしないでください。本記事はデータ活用の方法を説明するもので、法的助言ではありません。

最近の変更点

• 2026年10月6日：Pro、Max、Ultraプランの新しいCoworkタスクとスケジュール済みタスクはクラウドで実行されるようになり、「Only on your computer」は廃止されました（ヘルプセンター）。つまり、表の更新にコンピューターを起動しておく必要がなくなった一方、スナップショットの保存にローカルフォルダを使えなくなりました。
• 2026年10月22日：デスクトップアプリv3.6556.1では、人の操作が必要なMCPツールを使わずにスケジュール済みタスクを続行できるようになりました。また、スケジュール済みタスクがプラグインやスキルを見つけられない問題も修正されています（変更履歴）。つまり、一部が欠けた状態で完了した実行は、ツールをスキップした可能性があります。
• 2026年10月26日：Walmartは、11月12日から12月2日にかけて3つのホリデーイベントを開催すると発表しました。開催期間は合計14日間で、2025年の10日間から増えています（Walmartのプレスリリース、Retail Dive）。つまり、今後5週間が価格変動の最も大きい時期となります。毎日実行する設定に切り替えることができ、競合3社の場合は週$0.10かかります。
• 2026年10月27日：v4.29.0では、2つの自動モード以外のスケジュールタスクでWebフェッチが制限されます。URLは指示内に記載されているか、検索結果から得たものである必要があります（変更履歴）。つまり、Cowork自体のWebフェッチで商品ページを読み込むのは難しくなり、コネクタを使う方が安定します。

FAQ

Claude Coworkのスケジュールタスクが動作しない場合はどうすればよいですか？

この質問は、検索候補の「claude cowork scheduled tasks not working」と「claude cowork scheduled tasks connector not working」に基づいています。まず、どのレイヤーで障害が発生したかを特定してください。Cowork自体では、あるmacOSユーザーがタスクを作成できず、「Invalid file path: path traversal detected」というエラーが表示されたと報告しています（Redditスレッド）。関連するGitHub Issueには、リモートセッションではローカルのスケジュールタスクを管理するツールを利用できないとあります（GitHub Issue #76968）。

10月22日のアップデートでは、スケジュールタスクがプラグインやスキルを見つけられない問題も修正されたため、まずデスクトップアプリを更新してください（変更履歴）。コネクタについては、ヘッダーの値がBearerとキーの組み合わせになっているか、サーバーが公開されているか、承認が許可されているかを確認してください。EveryInfraについては、request_idを指定してeveryinfra_list_requestsを呼び出すと、ステータスと課金額を確認できます。この呼び出しは無料です。

この表は、実際の呼び出しと上記のスレッドで確認された症状を、問題が通常発生するレイヤーとともにまとめたものです。

Claude Coworkのスケジュールタスクの上限はいくつですか？

この質問は、検索候補「claude cowork scheduled tasks limit」に基づいています。あるRedditユーザーが作成できるスケジュールタスクの数を尋ねましたが、Anthropicが公表した数値を挙げた回答はありませんでした（Redditのスレッド）。関連するヘルプ記事を4本確認しましたが、Coworkのスケジュールタスク数や実行回数の上限は見つかりませんでした。確かなのは、実行によってサブスクリプションの利用枠が消費され、5時間ごとおよび週ごとの上限が適用されることです（使用量の制限）。比較すると、Claude Codeのクラウドスケジュールタスクでは、アカウントあたり1時間に100回のスケジュール実行が可能です（ドキュメント）。EveryInfra側のレート制限は、APIキーごとの1分あたりのリクエスト数で決まり、コンソールで引き下げることができます。

Claude CoworkのスケジュールタスクとClaude Codeのルーティン、どちらを使うべきですか？

この質問は、検索候補「claude cowork scheduled tasks vs claude code routines」に基づいています。データと結果がどこにあるかで決めましょう。結果はビジネスユーザー向けのシートやドキュメントですか？それなら、Google SheetsまたはMicrosoft 365のコネクタと組み合わせてCoworkを使ってください。データやスクリプトはGitリポジトリにありますか？

それなら、Claude Codeのクラウドスケジュールタスク（旧称ルーティン）を使い、履歴はコミットに残しましょう。こちらはAPI呼び出しやGitHubイベントをきっかけに開始することもできます（Claude Codeのドキュメント）。どちらも同じEveryInfraのMCPアドレスを使えます。もう一方のセットアップはClaude Codeスケジュールタスクのガイドで紹介しています。

パソコンの電源が切れていても、Claude Coworkのスケジュールタスクはクラウドで実行されますか？

この質問は、検索候補「claude cowork scheduled tasks cloud」に基づいています。はい。ヘルプセンターによると、スケジュールタスクはリモートで実行されるため、パソコンがスリープ中でも、アプリを閉じていても実行されます。10月6日より後に作成された新しいタスクはクラウドで実行されます（ヘルプセンター）。

例外は、ローカルのファイルやアプリを必要とするタスクと、10月6日より前からすでにパソコン上で実行されていた既存のタスクです。あるRedditユーザーはクラウドのオプションを見つけられませんでした（Redditのスレッド）。そのスレッドの返信では、クラウドのオプションはプランごとに順次提供されていると書かれていました。現在のヘルプセンターでは、Pro、Max、Ultraの新しいタスクは10月6日からクラウドで実行されると説明されています。

スケジュールタスクのモデルは選べますか？

この質問は、スケジュールタスクで使用するモデルの設定方法を尋ねるReddit投稿に基づいています（Redditのスレッド）。はい。手動設定フォームでは、モデルは任意のフィールドです（ヘルプセンター）。投稿への返信では、タスクの編集ページにあるモデル設定も紹介されていました。価格表のタスクは主にツールを呼び出してシートを埋めるだけなので、低コストのモデルで十分です。そこで節約できた利用枠は、判断が必要なタスクに回しましょう。

スケジュールタスクが時間どおりに始まらないのはなぜですか？

この質問は、リモートスケジューラーの実行時刻が、ときには約10分ずれると述べたReddit上の返信に基づいています（Redditのスレッド）。Coworkのヘルプセンターには、実行時刻の精度についての記載がありません。Claude Codeのクラウドのドキュメントによると、正時ちょうどに設定した実行は数分遅れて始まることがあります。そのため、9:07のように正時から数分ずらすことが推奨されています（ドキュメント）。週次の価格表では、実行時刻が厳密である必要はありません。私たちの例でも、同じ理由で09:10を使っています。

始め方

1. 無料のEveryInfraアカウントを作成し、Cowork専用のAPIキーを発行します。クイックスタートに沿って、curlでwalmart/searchを一度呼び出します。
2. Claudeで「Customize」>「Connectors」を開き、カスタムコネクタを追加します。URLにhttps://api.everyinfra.com/mcpを指定し、「No sign-in」を選んで、ヘッダーAuthorization = Bearer <key>を設定します。詳しい手順はMCPセットアップページをご覧ください。
3. Google Sheetsコネクタをオンにします。「Competitor weekly」というスプレッドシートを作成し、設定タブに競合のIDを入力します。
4. 「Scheduled」で「Set up manually」を選び、上記のプロンプトを貼り付けます。「Weekly」を選択します。「Run now」を一度クリックし、表示される承認リクエストに回答します。
5. 次の月曜日に、変更タブを開きます。

関連する方法については、サブスクリプション商品としての価格モニタリングをご覧ください。あわせて、比較可能なオファーを使ったAmazonの価格追跡とエージェントスキルを使った競合レビュー分析もご覧ください。

参考文献

1. Claude Coworkで定期タスクを設定する、Claudeヘルプセンター、2026-11-03閲覧。
2. リモートMCPを使ったカスタムコネクタの始め方、Claudeヘルプセンター、2026-11-03閲覧。
3. ディレクトリにないコネクタを追加する、Anthropicドキュメント、2026-11-03閲覧。
4. Claude Coworkとチャットは同じClaudeです、Claudeヘルプセンター、2026-11-03閲覧。
5. Web、デスクトップ、モバイルでClaude Coworkを使う、Claudeヘルプセンター、2026-11-03閲覧。
6. Claude Coworkを安全に使用する、Claudeヘルプセンター、2026-11-03閲覧。
7. TeamプランとEnterpriseプランでClaude Coworkを使用する、Claudeヘルプセンター、2026-11-03閲覧。
8. Claude Coworkを使い始める、Claudeヘルプセンター、2026-11-03閲覧。
9. 使用量と長さの制限の仕組み、Claudeヘルプセンター、2026-11-03閲覧。
10. リリースノート、Claudeヘルプセンター、2026-02-25から2026-10-21までの項目。
11. Claude Desktopの変更履歴、Anthropic、v3.6556.1（2026-10-22）からv4.4212.0（2026-10-29）まで。
12. 料金プラン、Anthropic、2026-11-03閲覧。
13. IPアドレス、Anthropicドキュメント、2026-11-03閲覧。
14. Claude Coworkのアーキテクチャ概要、Claudeヘルプセンター、2026-11-03閲覧。
15. スケジュールタスクで作業を自動化する、Claude Codeドキュメント、2026-11-03閲覧。
16. プロンプトをスケジュール実行する、Claude Codeドキュメント、2026-11-03閲覧。
17. Google Workspaceコネクタを使用する、Claudeヘルプセンター、2026-11-03閲覧。
18. Microsoft 365コネクタを設定する、Claudeヘルプセンター、2026-11-03閲覧。
19. ツール、Model Context Protocol仕様（2025-11-25版）。
20. トランスポート、Model Context Protocol仕様（2025-11-25版）。
21. リスクを表す語彙としてのツールアノテーション、MCPブログ、2026-03-16。
22. Issue #76968、GitHub anthropics/claude-code、2026-09-14のフォローアップ。
23. Claude Coworkでスケジュールタスクを作成・編集できない人はほかにもいますか、Reddit r/ClaudeAI。
24. スケジュールタスク／ルーティン：実際にうまく機能しているのはどれですか？、Reddit r/ClaudeAI。
25. claude.aiのスケジュールタスクで5時間枠を開始させる、Reddit r/ClaudeAI。
26. リモート（クラウド）でスケジュールタスクを作成できない、Reddit r/ClaudeCowork。
27. Coworkモード：スケジュールタスクを実行するモデルを指定する方法はありますか？、Reddit r/Anthropic。
28. EveryInfraデータ機能カタログ、EveryInfra、2026-11-03 00:15（シンガポール時間）閲覧。
29. 商品詳細ページ：Buy Box、Walmart Marketplace Learn。
30. 価格設定ルール、Walmart Marketplace Learn、2025-12-12更新。
31. マーケットプレイスレビューの概要、Walmart Marketplace Learn。
32. 評価、レビュー、質問と回答の利用規約、Walmartヘルプ。
33. Walmart、3つの大型ホリデーセールイベントを発表、Walmart、2026-10-26。
34. Walmart、ブラックフライデーとサイバーマンデーのセール期間を延長、Retail Dive、2026-10-26。
35. FTC、偽のレビューと体験談を禁止する最終規則を発表、米連邦取引委員会（FTC）、2024-08-14。
36. 16 CFR Part 465、eCFR。
37. datetime：基本的な日付型および時間型、Pythonドキュメント。
38. 認可、Model Context Protocol仕様（2025-11-25版）。
39. RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage、IETF、2012-10。
40. statistics：数理統計関数、Pythonドキュメント。