kintone Cowork連携の限界と日報自動化の現実的な進め方

「kintoneのデータをCoworkのスケジュールタスクで毎朝集計させたい」という発想は自然ですが、公式ドキュメントを突き合わせると、kintone MCPサーバーをCoworkのスケジュールタスクに直結する経路はありません。理由はどちらもクラウド完結の実行環境を前提にしている一方、kintone MCPサーバーはローカル専用のstdioサーバーだからです。この記事では、その仕様上の不一致と、実際に日報・週報の自動化を組み立てる現実的な2段構成を扱います。

Cowork Scheduled Tasksとは何か

Claude Coworkのスケジュールタスクは、決まった周期またはオンデマンドで実行するタスクを作成し、作業をCoworkに委任できる仕組みです。日次ブリーフィング、週次レポート、定期リサーチ、ファイル整理、チーム更新の集約といった用途がAnthropicのヘルプ記事で挙げられており、Pro・Max・Team・Enterpriseの有料プランで利用できます。

スケジュールタスクは接続済みのconnector・skill・pluginを使ってセッションを実行し、結果はタスク一覧から確認します。ここで重要なのは実行場所です。ヘルプ記事は、スケジュールタスクが接続済みのconnectorとClaudeアカウントに保存されたファイルを対象に動作し、手元のパソコン上のフォルダには紐付けられないと明記しています。コンピューターがスリープ中でもDesktopアプリを閉じていても、決めた周期で走り続けます。

kintone MCPサーバーはなぜCoworkに直結できないか

ここが本題です。kintone MCPサーバーはcybozu.devが「公式ローカルMCPサーバー」と明記する通り、npmパッケージ・Dockerイメージ・Claude Desktop用MCPBパッケージの3方式でしか配布されていません。いずれもユーザーの手元でプロセスを起動するstdio方式で、インターネット越しに直接呼び出せるリモートエンドポイントは提供されていません。

一方、Coworkのカスタムコネクタはユーザーのローカルデバイスではなく、Anthropicのクラウド側からMCPサーバーへ接続する設計です。ヘルプ記事は、接続先のサーバーがパブリックインターネット上で到達可能である必要があると明記しています。ローカルで完結するstdioサーバーは、この要件を満たせません。

Claude Code Routinesも同様の制約を抱えています。Routineの実体はAnthropicが管理するクラウド側で動き、実行のたびにリポジトリを新規cloneします。ローカルマシンの電源が落ちていても走る設計そのものが、ローカルプロセスであるkintone MCPサーバーとは相容れません。

実際に動く自動化パターン — ローカル実行とクラウド配信を分ける

現実的な解決策は、kintoneへのアクセスをローカルで完結させ、その結果をクラウド側の仕組みに橋渡しする2段構成です。

1. kintone側の処理はローカルのClaude Codeが担当する: OSのタスクスケジューラ(cronやlaunchd、Windowsのタスクスケジューラ)からclaude -pをヘッドレスモードで起動し、kintone MCPサーバーに接続したうえで日報・週報の集計を実行します。ヘッドレスモードは--mcp-configでMCPサーバーを指定でき、.mcp.jsonをそのまま使い回せます
2. 結果を接続済みのconnectorへ書き出す: 集計結果をGoogle DriveやSlackなど、Coworkが対応するプリビルドconnector側のファイル・チャンネルへ書き込みます。この書き込み自体もローカルのClaude Codeセッション内で完結させられます
3. 仕上げと配信はCoworkのスケジュールタスクが担当する: Google DriveやSlackはCoworkのプリビルドconnectorとして動作するため、クラウド側のスケジュールタスクが「今日追加されたファイルを整形して要約を投稿する」といった仕上げ作業を無人で実行できます

# cron/launchdから定期実行するイメージ(平日朝7時を想定)
claude -p "kintoneの「日報」アプリから昨日分の投稿を取得し、
担当者別に要約したMarkdownをGoogleドライブの
「日報サマリー」フォルダに保存して" \
  --mcp-config .mcp.json \
  --allowedTools "mcp__kintone,mcp__google-drive"

この構成なら、kintoneに触れる部分だけがローカルのマシン起動を前提とし、それ以外の配信・整形・通知はクラウド完結のCoworkスケジュールタスクに任せられます。完全無人化ではなく「kintone部分だけ手元のマシンが必要」という制約を、正しく理解したうえで運用する形です。

この構成で注意すべきこと

cronやlaunchdからkintoneの認証情報を渡す場合、平文の環境変数をスクリプトに書き込んだままにしないことが要点です。macOSならKeychain、Linuxならsystemdのcredential機構やシークレット管理ツール経由で読み込ませ、スクリプトファイル自体には値を残さない構成にします。ヘッドレスモードのclaude -pは対話的な承認プロンプトを出さないため、書き込み系のkintoneツール(レコード更新・削除)を無人実行に含める場合は、--allowedToolsで許可するツールを明示的に絞り込み、意図しない操作が自動承認されないようにしておく必要があります。

どの業務ならこのパターンが向くか

OSのスケジューラを使う理由

Claude Code Routinesではなく、あえてOSのスケジューラ(cron・launchd・タスクスケジューラ)を勧めるのには理由があります。Routineはクラウド側で毎回リポジトリを新規cloneして実行する設計で、ローカルのファイルシステムやローカルプロセスに依存する処理と根本的に相性が悪いという点です。kintone MCPサーバーのようなローカル資産を扱う自動化は、同じくローカルで完結する仕組みに乗せるのが素直です。将来的にkintone側がリモートMCPのエンドポイントを提供すれば、Cowork・Routineどちらからも直接呼び出せるようになりますが、そうした選択肢はREADME・cybozu.devのいずれにも記載がありません。

よくある質問

Coworkのプリビルドconnectorにkintoneが将来追加される可能性は?

kintone MCPサーバーがリモートMCPのエンドポイントを提供すれば、Anthropicのconnectorディレクトリに掲載される道は開けます。ただしGitHub READMEとcybozu.devのページには、リモート提供の予定について記載がありません。

Claude Desktopのチャット画面からならkintoneをすぐ使える?

使えます。kintone MCPサーバーはMCPBパッケージでClaude Desktopに直接組み込めるため、Desktop上のチャットやCode機能からは通常のMCPサーバーとして呼び出せます。制約があるのは、あくまでCoworkのクラウド実行スケジュールタスクに直結する経路の部分です。

この2段構成をSlack連携だけで完結させることはできる?

できます。Google Driveの代わりにSlackを仲介にする場合、ローカルのClaude CodeがkintoneのデータをSlackの特定チャンネルに投稿し、Coworkのスケジュールタスクがそのチャンネルを要約・転送する構成にできます。CoworkのSlack連携ワークフローで権限設計の考え方を扱っています。

まとめ

kintoneのデータをCoworkのスケジュールタスクだけで完全自動化することは、公式ドキュメントが示す範囲ではできません。kintone MCPサーバーがローカル専用のstdioサーバーである一方、Coworkのカスタムコネクタとスケジュールタスクはクラウド完結を前提にしているためです。実務で日報・週報の自動化を実現するなら、kintoneに触れる集計処理をローカルのClaude Codeとcron・launchdに任せ、仕上げと配信をGoogle DriveやSlack経由でCoworkのスケジュールタスクに渡す2段構成が現実的な落としどころになります。ローカル実行とクラウド配信の役割分担を切り分けておけば、機能追加を待たずに今ある構成のまま日報・週報の自動化を回せます。同じ業務データの定期レポート自動化でも、SalesforceはHosted MCP Serverを提供しているためCoworkのカスタムコネクタに直接接続でき、この制約を受けません。詳しくはCowork Salesforce連携 — 週次営業レポートを自動生成する手順で扱っています。kintoneとの接続そのものはClaude kintone連携ガイド、レコード検索・集計の具体的な指示例はkintoneレコード検索・更新の実践ガイドにまとめています。Coworkの接続先の全体像はClaude CoworkのConnectors一覧、Routinesの仕組みはClaude Code Routines完全ガイドを参照してください。