【テクニカル・上級編】LinearのAutomations（自動化）機能完全ガイド：ラベル連動やステータス自動遷移でルーティンワークを全廃する方法 – プロジェクト・ナレッジ管理活用バイブル

Linear Automations極限活用論：ステータス同期とルーティンワーク全廃のアーキテクチャ

開発チームのベロシティを蝕む最大のガンは、コードを書く時間そのものの不足ではない。「チケットを動かす」「ステータスを同期する」「ラベルを付け替える」といった、機械がミリ秒単位で処理できるはずのトリアージ作業にエンジニアの認知リソースが奪われていることだ。

Linearはその美しく洗練されたUIで知られているが、真の強みは奥深くにあるAutomations（自動化）エンジンと、その背後にある堅牢なAPI/Webhookエコシステムに宿っている。

本稿では、標準のUI設定の枠を超え、GitHubやCI/CDパイプライン、さらには自製のCLI/APIスクリプトを完全に統合し、開発チームのルーティンワークを「完全ゼロ」にするための極限のアーキテクチャを解説する。

—

1. Linear Automationsの内部モデルと挙動の理解

手動更新をゼロにするには、まずLinearのイベント駆動型アーキテクチャのプリミティブを理解する必要がある。Linearの自動化は、以下の3つのレイヤーで構成されている。

1. Team-level Automations（チーム標準自動化）: UIから設定可能な宣言的ルール（PR連携、ラベル連動など）。
2. Project/Cycle Automations（マイルストーン連動）: 期間やスコープベースの状態遷移。
3. GraphQL API & Webhooks（外部トリガー）: 任意のCI/CDやカスタムスクリプトからの介入点。

これらを組み合わせることで、「誰がどこを触っても、チケットの状態が物理法則のようにコードの現実と一致する」状態を作り上げる。

—

2. 標準Automationsの限界を突破する実践ルール設定

まずは標準機能の極限活用から始める。多くのチームが「PRがマージされたらDoneにする」程度の浅い設定にとどめているが、インシデント対応やリアクティブな開発フローにおいては、ラベルとアサインの完全連動が不可欠だ。

実践例A：緊急バグ（Sev-1）の自動トリアージとエスカレーション

バグチケットに特定のラベルが付与された瞬間、即座に担当者をアサインし、バックログから「In Progress」へ強制遷移させるルールだ。

  • トリガー (Trigger): ラベル `Severity: 1` が付付与されたとき
  • アクション (Actions):
  • ステータスを `In Progress` に変更
  • チーム内のオンコール担当者（またはリードエンジニア）を自動アサイン
  • 優先度 (Priority) を `Urgent` に強制昇格

これにより、P0/P1障害発生時に「誰がチケットを取るか」のコンフリクトやタイムロスが消滅する。

実践例B：GitHub Pull Requestのライフサイクル完全同期

LinearとGitHubのインテグレーションにおいて、単にPRリンクを貼るだけでは不十分だ。以下のマッピングを厳密に行う。

  • PR Draft作成時: ステータスを `In Review`（またはカスタムの `WIP`）へ移行。タイトルに `[WIP]` を自動付与。
  • PR Review Request時: レビュアーをLinearの同名ユーザーと自動紐付け。
  • PR Merged時:
  • ステータスを即座に `Done`（または `In QA`）へ遷移。
  • デフォルトブランチ（`main`）へのマージであれば、自動的に親プロジェクトの進捗バーを更新。

—

3. WebhookとGraphQL APIを叩く独自自動化スクリプトの構築

標準のAutomationsではカバーできない、複雑なビジネスロジック（例：「特定のファイルパスが変更された場合のみ、特定のコンポーネントラベルを付与する」など）を解決するためには、Linear Webhook × 自製Serverless Function（またはCLI）のアーキテクチャを導入する。

以下は、GitHub Actions等のCIからLinear APIを直接叩き、プレフィックスに応じてチケットのステータスとラベルを動的に制御するTypeScript製スクリプトの核心部分だ。

TypeScriptによる高度なチケット制御スクリプト

import { LinearClient } from ‘@linear/sdk’;

// 環境変数からクライアントを初期化（セキュアな最小権限トークンを使用）
const linear = new LinearClient({ apiKey: process.env.LINEAR_API_KEY });

interface SyncParams {
issueId: string;
gitBranch: string;
prStatus: ‘OPEN’ | ‘MERGED’ | ‘CLOSED’;
}

/

  • PRのライフサイクルに応じてLinearのステータスとラベルを動的に更新する関数

/
async function syncIssueWithPR({ issueId, gitBranch, prStatus }: SyncParams) {
try: (
// 1. チケットの存在確認と現在の状態を取得
const issue = await linear.issue(issueId);
const team = await issue.team();
const states = await team.states();

if (prStatus === ‘MERGED’) {
// “Done” ステータスのIDを動的に取得（名前ハードコードを避ける設計思想）
const doneState = states.nodes.find(s => s.type === ‘completed’);

if (!doneState) {
throw new Error(‘Completed state not found in the target team.’);
}

// ステータス更新の実行
await issue.update({
stateId: doneState.id,
});

console.log(`[Linear Automation] Issue ${issue.identifier} successfully transitioned to Done.`);
}
) catch (error) {
console.error(`[Linear Automation Error] Failed to sync issue ${issueId}:`, error);
process.exit(1);
}
}

// 実行エントリーポイント（CLIからの呼び出しを想定）
const args = process.argv.slice(2);
if (args.length >= 3) {
syncIssueWithPR({
issueId: args[0],
gitBranch: args[1],
prStatus: args[2] as ‘OPEN’ | ‘MERGED’ | ‘CLOSED’,
});
}

このスクリプトを組み込むCIパイプライン（GitHub Actions）

name: Linear State Sync

on:
pull_request:
types: [closed]

jobs:
sync:
runs-on: ubuntu-latest
steps:

  • uses: actions/checkout@v4
  • name: Setup Node.js

uses: actions/setup-node@v4
with:
node-version: ’20’

  • name: Install dependencies

run: npm install @linear/sdk

  • name: Extract Linear Issue ID from Branch Name

id: extract_id
run: |
# ブランチ名（例: feature/LIN-123-fix-auth）からチケットIDを抽出
BRANCH_NAME=”${{ github.head_ref }}”
if [[ $BRANCH_NAME =~ (LIN-[0-9]+) ]]; then
echo “issue_id=${BASH_REMATCH[1]}” >> $GITHUB_OUTPUT
else
echo “issue_id=” >> $GITHUB_OUTPUT
fi

  • name: Execute Linear Sync Script

if: steps.extract_id.outputs.issue_id != ”
env:
LINEAR_API_KEY: ${{ secrets.LINEAR_API_KEY }}
run: |
PR_STATUS=$([[ “${{ github.event.pull_request.merged }}” == “true” ]] && echo “MERGED” || echo “CLOSED”)
npx ts-node ./scripts/sync-linear.ts “${{ steps.extract_id.outputs.issue_id }}” “${{ github.head_ref }}” “$PR_STATUS”

このパイプラインを導入することで、開発者はブランチ名にLinearのID（例：`LIN-42`）を含めてコードを書き、PRをマージするだけで、Linear側の操作を一切行うことなくチケットが美しくクローズされる。

—

4. パフォーマンスとメモリ効率を意識したスケーリングハック

自動化の規模が大きくなり、チーム数が数十、チケット数が数万を超えてくると、APIのレートリミット（Rate Limiting）やWebhookのデリバリー遅延がボトルネックになってくる。真のインフラストラクチャ・エンジニアとして、以下の最適化を施すべきだ。

1. GraphQLクエリの最適化（N+1問題の回避）

LinearのGraphQL APIを叩く際、不必要に深いリレーション（例：`issue -> comments -> user -> team`）を一度のクエリで取得しようとすると、APIサーバー側で重い処理が発生し、レートリミット（通常、秒間制限あり）に抵触する。

  • 対策: 必要なフィールド（`id`, `stateId`, `identifier`）のみを明示的に指定し、バッチ処理を行う際はLinear SDKのページネーション機能を正しくハンドリングすること。

2. Webhookの冪等性（Idempotency）の担保

カスタムWebhookサーバーを運用する場合、ネットワークの再送等により同一のイベントが二重配信されるケースがある。

  • 対策: Linearが送信するWebhookヘッダーのイベントID（またはタイムスタンプとペイロードのハッシュ）をRedis等のKVSに一定時間キャッシュし、重複リクエストを弾く仕組みを必ず実装すること。

—

5. 結び：ツールに奉仕するな、ツールを飼い慣らせ

アジャイル開発の目的は「チケットを綺麗に管理すること」ではなく、「価値あるソフトウェアを最速でユーザーに届けること」だ。

LinearのAutomations、そしてAPIを極限まで使い倒すことで、「チケットのステータス更新」という脳のメモリを消費するコンテキストスイッチを完全にゼロにせよ。 開発者が書くべきなのはコードだけであり、それを追従する世界線は、今日のこの設定から構築できる。

スポンサーリンク
タイトルとURLをコピーしました