こんにちは、花王株式会社の @TsuchiyaK です。
昨今、生成AIによる業務改善を検討している方も少なくないと思いますが、以下のような仕組みを考えたことはないでしょうか。
- SaaSなどのAPIからデータを取得
- そのデータをもとに生成AIによってドキュメントを生成
- これを定期的に自動実行
Claudeのサービスでこれを実現する場合、Claude CoworkのスケジュールタスクとClaude CodeのRoutines が候補になるかと思います。どちらも「プロンプトを保存して定期実行する」仕組みで、比較の観点はリポジトリの要否、トリガーの種類、成果物の扱いなどいくつかあります。
私も業務改善の一環としてドキュメントの自動生成を検討したのですが、その中で連携先サービスの認証情報の管理がひとつの課題になりました。
そこで本記事では、2つの手段を比較したうえで、認証情報の管理という側面についてまとめてみました。
本記事は2026年9月時点の情報に基づいています。Claudeの各サービスについて今後仕様や提供プランは変更される可能性があります。
2つの選択肢
Claude Coworkのスケジュールタスクは、プロンプトを保存して毎時・毎日・平日・毎週のいずれかの頻度で実行する仕組みです。有料プランで利用でき、アカウントに設定済みのコネクタ・スキル・プラグインをそのまま使えます。
Claude CodeのRoutines は、プロンプト・リポジトリ・コネクタをひとまとめにした設定を自動実行する仕組みです。有料プランで利用でき、スケジュールに加えてHTTP API呼び出しやGitHubイベントでも起動できます。実行はClaude Codeのクラウド環境上で行われ、ネットワークアクセスや環境変数を細かく制御できます。
比較
| Coworkスケジュールタスク | Claude Code Routines | |
|---|---|---|
| 想定ユーザー | 非開発者を含む | 開発者 |
| GitHubリポジトリ | 不要 | 1つ以上必須（毎回クローン） |
| トリガー | スケジュール、手動 | スケジュール（定期・一回限り）、API、GitHubイベント、手動 |
| 最短間隔 | 1時間 | 1時間 |
| 承認プロンプト | あり（承認モードを設定可） | なし（完全自律） |
| 実行環境の制御 | タスク単位では不可（組織設定で管理者が制御） | ネットワーク、環境変数、セットアップスクリプト |
| 成果物 | Claudeアカウントに保存 | 実行セッションに残るが、自動ではどこにも保存されない |
| プラン | 有料プラン全般（Team / Enterpriseは管理者による無効化が可能） | 有料プラン全般（Enterpriseは対象シート必須、Team / Enterprise は管理者による無効化が可能） |
実務における比較のポイントは GitHubリポジトリの要否です。Routinesはリポジトリ指定が必須なので、コード資産を持たない用途では置き場所のためだけにリポジトリを用意することになります。
もう1つが成果物の扱いです。Routinesは毎回新しいVMで動き、実行ごとにセッションが1つ残ります。後からセッションを開いて差分をレビューし、PRを作ることはできますが、自動でどこかに保存されるわけではありません。無人運用にするなら、生成したドキュメントの保存先（リポジトリへのコミット、Slackコネクタ経由の投稿、自社ストレージへの送信など）をプロンプトで明示する必要があります。
認証情報をどこに置くか
ここからが本記事の主題です。連携先の認証情報の置き場所には、4つの選択肢があります。
パターン1：MCPコネクタを使う
連携先にコネクタが提供されているのであれば、これが第一候補になるかと思います。コネクタはCoworkでもRoutines でも利用可能です。
認証情報の管理をコネクタ側に寄せられるため、自動化の設定側で認証を意識する必要がありません。 コネクタの呼び出しはAnthropicのサーバー側で実行され、トークンが実行環境（サンドボックス）に入ることもありません（Routines / Cowork）。
なお、コネクタが提供されていない場合でも、自分でコネクタを用意して同じ形に持ち込むことはできます。ただしそれは「認証情報を自社側に置く」話になるので、パターン4で扱います。
パターン2：API credentials（Routinesのみ）
連携先にコネクタがない場合は、Claude Codeのクラウド環境が持つAPI credentialsの使用が候補となります。これはClaude Codeの機能なのでRoutinesでのみ使うことができます。
環境にAPIキーやトークンなどの認証情報を登録しておくことで、API実行時に参照されます。
これによって、ClaudeおよびClaudeが実行するコマンドに認証情報を渡さずにAPIを実行することができます。
認証方式（Credential type）はBearer / Basicのほか、AWS SigV4、GCP、サーバー間OAuth（client credentials / JWT bearer）などが用意されており、トークン取得を先に挟む標準的なフローも組み込むことができます。（認証方式一覧）
注意点：API credentialsにはプランの制約あり
API credentialsは現状ProとMaxプランのみで利用可能となっており、TeamとEnterpriseプランではまだ提供されていません（出典: Add API credentials）。
業務利用ではTeamやEnterpriseを使っている組織が多いかと思うので、導入検討時はここがネックになる可能性が高いです。使えない場合、選択肢はパターン1（コネクタ経由）かパターン4（認証処理を外部に出す）に絞られます。
その他、Anthropicホストのクラウド環境限定（セルフホストには存在しない）、APIがインターネットから接続を受け付ける必要がある、既存環境の編集画面からのみ追加可能で後から編集はできない、といった制約もあります（詳細はドキュメントの Requirements を参照）。
パターン3：環境変数（非推奨）
Routinesの環境変数に認証情報を書く方法です。技術的には動きますが、ドキュメントは明確に警告しています。環境を使用する誰でも値を読み取れるうえ、専用のシークレットストアでもありません。
パターン4：認証処理を外部に出す
コネクタが提供されておらず、API credentialsもプランの制約で使えない場合の選択肢です。長期的な認証情報管理を切り出し、Claude 側には有効期限の短いトークンか認証済みの結果だけを渡す方法で、Claude Codeの機能に依存しないので、Cowork でもRoutinesでも成立します。
見せ方は2通りあります。
(a) リモートMCPサーバーとして見せる
リモートMCPサーバーを自作する方法です。認証処理を自分のサーバーに閉じ込め、Claude側には必要なツールだけを見せます。カスタムコネクタとして登録してしまえば、使い勝手はパターン1と同じになります。連携先が複数あったり、呼び出したい操作が多い場合はこちらが向きます。
(b) トークン交換のエンドポイントだけを用意する
MCPサーバーを立てるほどでもない場合は、短命なアクセストークンを返すエンドポイントを1つ用意し、Claudeがトークンを取得してから連携先のAPIを叩く形にもできます。クライアントシークレットやリフレッシュトークンといった長期の認証情報が実行環境に入らない点は(a)と同じです。ただしそのエンドポイント自体をどう保護するかは別途考える必要があります。
選び方
-
APIトリガーやGitHubイベント連携が必要か？
- Yes → Routines。認証は2へ
- No → 2へ
-
連携先が全てコネクタで賄えるか？
- Yes → パターン1 で認証の問題は解消。あとはリポジトリの要否や成果物の扱いで選ぶ（リポジトリが不要なCoworkが有力）
- No → 3へ
-
Pro / Maxプランか？
- Yes → パターン2（Routines + API credentials）。認証方式がCredential typeに合うか確認
- No（Team / Enterprise） → パターン4（認証処理を外部に出す）
まとめ
- MCPコネクタ（パターン1）が使えるなら認証の問題は解消（Cowork / Routines共通）
- コネクタがない場合、RoutinesのAPI credentialsが候補（パターン2）
サーバー間OAuthを含む標準的な認証方式ならキーをClaudeに見せず実行可能（Routinesのみ） - ただし API credentialsは Pro / Maxのみで、Team / Enterpriseでは未提供
使えない場合は認証処理を外部に出す方法が候補（パターン4 | Cowork / Routines共通） - Routinesはリポジトリが必須かつ成果物が自動保存されないため、無人運用にするなら保存先をプロンプトで明示する必要あり
同じような自動化を検討されている方の設計判断の助けになれば幸いです。