Cowork Linear自動化 — Issueトリアージの定期実行手順

Cowork Linear自動化とは

Cowork Linear自動化は、Claude CoworkのScheduled Tasks機能とLinear連携を組み合わせた仕組みです。Issueのトリアージやサイクルの振り返りを、人手を介さずに作り続けられます。Scheduled Tasksはプロンプトをタスクとして保存し、決めた頻度でクラウド側だけで実行します。パソコンをスリープさせていても、Desktopアプリを閉じていても指定した時刻に動く点が、通常のチャットとの違いです。

Coworkはdesktopで提供されている機能で、web・mobileはbeta扱いです(Pro・Max・Teamプラン、Enterpriseはオーナーが有効化した場合)。面によって挙動が変わる可能性があるため、web・mobileで使う場合はタスクの実行結果を最初のうちはdesktopでも確認しておくと安心です。

Linear連携そのものの接続手順はClaude Linear連携にまとめています。開発フローに組み込む具体的な依頼の型はLinearの開発チケットをClaudeで整理・優先度付けするが扱っています。接続と日々の使い方を確認済みの読者は、ここから「毎週決まった時刻に自動で動かす」設計に進めます。

Linear連携は読み取りと書き込みの両方に対応したConnectorです。HubSpotのような読み取り専用の連携と違い、自動実行がIssueを実際に作成・更新できてしまう分、承認モードの設計がそのまま運用ルールになります。

準備しておくもの

自動化を組む前に、そろえておきたい前提が3点あります。

Coworkは有料プラン(Pro・Max・Team・Enterprise)が前提の機能です。Scheduled Tasksもすべての有料プランで使えますが、FreeプランではそもそもCowork自体が使えません。

プラン以外にまず必要なのがLinear連携の接続です。Coworkのチャット下部の「+」メニューか「Customize > Connectors」から、あらかじめLinearを接続し認証を済ませておきます。この接続はCoworkの通常のチャットと共有されるため、一度つないでおけば以後の設定はScheduled Tasks側だけで完結します。

最後に、自動化したい範囲を先に決めておきます。全チームのIssueを対象にするのか、特定のプロジェクトやtriageキューに絞るのかによって、後述のプロンプトの書き方が変わります。

開発者が多いTeam・Enterpriseでは、メンバー1人ずつの認証作業そのものが導入の壁になります。LinearはOktaと連携したEnterprise管理認証に対応しています。手順は3段階です。まずOkta OIN側でLinearのSAMLアプリを設定し、次にLinearのOkta identity provider設定画面で「MCP enterprise managed authentication」を有効にし、最後にOktaのIssuer URIをLinear側に登録します。ここまで済ませると、対応する外部MCPクライアント(公式ドキュメントはClaudeを例に挙げています)が組織のアクセスポリシーに沿ってユーザーを認証できるようになります。これはLinear側の設定なので、Coworkからの接続がこの経路に乗るかは導入前に自組織で確認します。

Issueトリアージを自動実行する手順

Scheduled Tasksの作成方法は2通りあります。どちらもCowork左サイドバーの「Scheduled」から始めます。

方法1: Claudeに作らせる

「New task」から「Create with Claude」を選ぶと、Claudeが必要な情報を質問形式で聞いてきます。「毎週トリアージしたい内容」を伝えるだけで、タスク名・スケジュール・実行内容をClaude側が組み立て、確認画面で「Schedule」を押すと登録されます。

方法2: 手動で設定する

「New task」から「Set up manually」を選ぶと、次の項目を自分で入力するモーダルが開きます。

週次トリアージには次のようなプロンプトが向いています。

triageキューにあるIssueと、直近1週間動きのない
進行中Issueをそれぞれ確認してください。影響範囲・再現頻度・
放置期間の3軸で優先度を高・中・低に分け、理由を1行ずつ添えて
一覧にしてください。ラベルや担当者の変更はまだ行わず、
一覧の提示だけにとどめてください。

承認モードと書き込み権限をどう選ぶか

Coworkには、Claudeが行動する前にどこまで確認を求めるかを決める3つのモードがあります。

Linear連携はIssueの作成・更新・コメント追加という3系統の書き込みツールを持つ点が、読み取り専用のHubSpot連携などとの分かれ目です。Manualのままなら3系統すべてが毎回承認待ちになり、Autoに切り替えると安全性の判断がClaude任せになります。中間を取りたければ、「Customize > Connectors」でLinearを選び、Tool permissionsから作成・更新系ツールだけを個別に「Needs approval」に固定する構成が現実的です。トリアージの一覧作成だけを任せたい段階では、プロンプト側で「ラベル・担当者の変更は行わない」と明示しておくだけでも誤操作の余地を減らせます。

Autoモードで最初から自動化すると、プロンプトの指示が曖昧だった場合に気づきにくいまま実行が積み重なります。IssueへのラベルやTitleの書き換えが伴うタスクは、初回だけManualで1回流し、取りこぼしや誤検出がないかを確認してから頻度を上げるのが安全です(Autoモードが使えるPro・Maxプランの場合)。Team・Enterpriseではこの切り替え自体ができないため、Manualモードのまま運用します。組織設定の「常に許可を有効にする」トグルがオフの場合、メンバー個人がAlways allowに設定していても、書き込み系ツールはタスクごとの承認が必要になります。承認モードの仕組み自体はCowork自動承認モードとはで詳しく扱っています。

Scheduled Tasksの一覧画面では、決めたスケジュールを待たずに「Run a task on demand」でその場実行できます。プロンプトを微調整するたびに1週間待つ必要はなく、その場で結果を確認しながら文言を詰められます。手動実行だけで十分な用途なら、頻度を最初から「manually」に設定して、スケジュールを組まずにこの機能だけで回す選択肢もあります。

定期実行でこそ効くLinearの使い方

Linear公式のMCPドキュメントは、ロードマップ計画やインシデント報告といった単発の使い方に加え、繰り返し発生する2つの作業を代表例として挙げています。どちらもScheduled Tasksとの相性が良い作業です。

サイクル振り返りの自動生成。スプリント(サイクル)の終わりに何が完了したかをまとめる作業は、対象チームと期間さえ決めておけば、同じプロンプトを毎回使い回せます。

直近で完了したサイクルの対象チームのIssueを集めて、
完了した作業の要点をまとめてください。バグ修正・機能追加・
技術的な整備がそれぞれどれくらいの比率か、目立った傾向が
あれば触れてください。進行中で終わらなかった作業は
誇張せず、現状のまま報告してください。

スタンドアップメモの自動転記。朝会で共有された進捗メモをIssueへのコメントに変換する作業も、毎回手作業で行うと地味に時間を食います。この用途では「確信を持って紐づけられるものだけ処理し、あいまいなメモは未対応として報告する」という条件をプロンプトに必ず入れておきます。確信度の低い紐づけまで自動でコメントさせると、無関係なIssueにノイズが増えていくためです。

タスクの実行結果を確認する・止める

登録して終わりではなく、左サイドバーの「Scheduled」一覧画面が運用の起点になります。この画面から次の操作ができます。

トリアージ結果は各実行が1つのCoworkセッションとして残るため、「先週の出力と比べてどう変わったか」は一覧から過去の実行を開けば確認できます。プロンプトの精度が思わしくないときは、一覧から直接編集すれば作り直す必要はありません。長期の休暇やスプリントの谷間で一時的に止めたいだけなら、削除ではなくPauseを使います。

よくあるつまずき

トリアージ結果に別チームのIssueが混ざる、という報告が出たら、まず閲覧権限を疑います。Linear連携が返すデータは、接続したアカウントの閲覧権限までです。個人アカウントで接続した場合、トリアージの対象も本人が見えるチーム・プロジェクトに限られます。

複数のLinearワークスペースを使い分けているチームも注意が必要です。Scheduled Tasksが参照するのは、タスクを作成したCoworkアカウントに接続済みのワークスペース1つだけです。別のワークスペースの結果がほしい場合は、そのワークスペースで接続し直した上でタスクを作り直す必要があります。

トリアージのつもりが書き込みまで実行される。「優先度を評価して、ついでにラベルも直しておいて」のような指示は、プロンプトの後半部分がそのまま実行されてしまいます。評価と変更は別のタスク、あるいは別の承認ステップに分けておくのが安全です。

Scheduled Tasksは実行のたびに新しいCoworkセッションとして走ります。前回の会話の文脈は引き継がれないため、対象範囲や除外条件はプロンプト自体に毎回含めておく必要があります。

参照だけで十分なのに書き込み権限が残っている構成も見直す価値があります。トリアージの集計・分析だけに用途を絞るなら、Tool permissionsで作成・更新系ツールを個別にBlockedへ変更する方法があります。接続自体を読み取り専用エンドポイントに切り替える方法もあり、切り替え手順はClaude Linear連携にまとめています。承認モードとは別レイヤーの制御なので、両方を組み合わせると自動化の安全域が広がります。

よくある質問

実行結果はどこで確認できますか

左サイドバーの「Scheduled」一覧から、対象タスクを開くとReview upcoming and past runsで過去の実行結果と次回の実行予定を確認できます。各実行は独立したCoworkセッションとして残るため、出力の推移も遡って見られます。

頻度を変えたいときは作り直しですか

作り直す必要はありません。一覧画面からプロンプトやスケジュールを直接編集できます。頻度だけをhourlyからweeklyに変える、といった調整もこの画面で完結します。

トリアージだけさせて書き込みを止められますか

止められます。承認モードをManualに固定するか、Tool permissionsで作成・更新・コメント追加の3系統を個別にNeeds approvalまたはBlockedへ切り替えます。接続自体を読み取り専用エンドポイントに切り替える方法と組み合わせれば、より確実です。

複数チームを別々のタスクに分けるべきですか

チームごとに優先度の基準や除外条件が違うなら、分けたほうがプロンプトがシンプルになります。1つのタスクで全チームを扱うと、条件分岐が複雑になり出力形式もぶれやすくなります。

一時的に自動実行を止めたいだけならどうしますか

タスクを削除せずPauseを使います。休暇やスプリントの谷間で一時停止し、必要になったらResumeで再開すれば、プロンプトやスケジュールの設定を作り直さずに済みます。

まとめ

Cowork Linear自動化は、Scheduled Tasksの定期実行とLinear連携の読み書き機能を組み合わせるだけで組めます。書き込みができる連携である以上、承認モードとTool permissionsの設計を先に決めてから自動化に進むことが、HubSpotのような読み取り専用連携以上に重要になります。同じ「Connector + Scheduled Tasks」の型は、他の連携にも応用できます。HubSpotならCowork HubSpot自動化、Jira・ConfluenceならJira×Confluence×Claudeで社内問い合わせを自動化で同じ考え方が使えます。