Linear Freeプランの限界突破：骨の髄まで使い倒す極限のアーキテクチャ設計とアップグレードの境界線
プロダクト開発において、ツール選定は宗教戦争ではない。それは純粋なスループットと認知負荷の最適化問題だ。Jiraの肥大化したUIに殺されかけ、Notionのデータベースの限界に絶望したエンジニアたちが最後にたどり着く聖域、それがLinearである。
「小規模チームだからまずはFreeプランで」——この甘美な響きに騙されてはならない。Freeプランは単なる「お試し版」ではない。妥協なきエンジニアリングによって、その制限の骨格を極限までハックし、有料プラン顔負けの爆速開発パイプラインを構築するための実験場なのだ。
本稿では、LinearのFreeプランが持つ物理的制約をGraphQL APIとCLI、そしてWebhookを駆使して完全に骨抜きにする手法を解説し、さらには「いつ有料プラン（Standard / Plus）へ移行すべきか」というROIの境界線を、ベロシティと認知負荷のメトリクスから冷徹に導き出す。
—
1. Freeプランの要塞：制限事項の全貌と「設計による突破」
まず、敵を知れ。LinearのFreeプランには明確なリソースの壁が存在する。これをそのまま受け入れるのは素人のやることだ。制約を把握し、アーキテクチャで迂回する。
- メンバー数制限: 250名まで（小規模チームなら実質無制限）
- アクティブイシュー数: 250件（※ここが最初の罠）
- ファイルアップロード: 1ファイルあたり10MB
- データストレージ総量: チーム全体で無限ではないが、画像やログの直貼りは即座にパンクする
- インテグレーション: GitHub, GitLab, Slackなどの基本連携は網羅
罠の回避：「250アクティブイシュー制限」の構造的ハック
LinearのFreeプランでは、完了していない（＝Active）イシューの総数が250件を超えると、新しいイシューの作成がロックされる。バックログをゴミ溜めにする文化を持つチームにとって、これは即死宣告だ。
しかし、これは「タスクを溜め込むな」というLinearからの強烈な禅問答である。アジャイルの本質に立ち返れば、250件以上の未着手タスクなど誰も把握できず、単なる「技術的負債の墓場」でしかない。
解決策：
1. 自動クローズ・デーモン（GraphQL API活用）の導入:
長期間（例：30日以上）更新のない`Backlog`ステータスのイシューを、API経由で自動的に`Canceled`または`Closed`に遷移させるバッチを組む。
2. エピック単位の外部化:
詳細な仕様書やロードマップはNotionやMarkdownリポジトリに逃がし、Linearには「実行可能な最小単位（Atomic Task）」のみを載せる。
—
2. 無料の限界を粉砕する：Linear API & CLIによる極限の自動化
Freeプランでは制限されている高度なワークフロー自動化（Advanced Workflowsなど）を、自前のコードとLinearの強靭なAPIで補完する。LinearのGraphQL APIは、ドキュメントの美しさも含めて業界最高峰だ。
スクリプト例：バックログ溢れを防ぐ自動ガーベジコレクション
以下のTypeScriptスクリプトは、特定の日数以上放置されたバックログのイシューを検出し、自動でクローズしつつ、コメントを残すボットのコアロジックだ。これをGitHub ActionsのScheduled workflows（cron）で毎日走らせることで、Freeプランの「250件制限」を完全に回避する。
import { LinearClient } from ‘@linear/sdk’;
// 環境変数からAPIキーを読み込み、クライアントを初期化
const linearClient = new LinearClient({ apiKey: process.env.LINEAR_API_KEY });
async function garbageCollectBacklog() {
const thirtyDaysAgo = new Date();
thirtyDaysAgo.setDate(thirtyDaysAgo.getDate() – 30);
try {
// 1. バックログステータスにあるイシューを取得
const issues = await linearClient.issues({
filter: {
state: { name: { eq: “Backlog” } },
updatedAt: { lt: thirtyDaysAgo },
},
});
console.log(`Found ${issues.nodes.length} stale backlog issues.`);
for (const issue of issues.nodes) {
// 2. 該当イシューに自動コメントを付与
await linearClient.createComment({
issueId: issue.id,
body: “🤖 [Automated GC] 30日間更新がなかったため、バックログの肥大化防止としてクローズされました。必要であれば再オープンしてください。”,
});
// 3. ステータスをCanceledに更新
// ※Linearのチーム設定に合わせてCanceledステータスのIDを取得して指定
await linearClient.updateIssue(issue.id, {
stateId: “CANCELED_STATE_ID_HERE”,
});
console.log(`Closed stale issue: ${issue.identifier}`);
}
} catch (error) {
console.error(“Failed to run Linear GC:”, error);
process.exit(1);
}
}
garbageCollectBacklog();
このようなスクリプトをCI/CDパイプラインに組み込むことで、有料プランの機能を自前で実装し、チームの規律すらも自動化できる。
—
3. 有料プラン（Standard / Plus）へのアップグレード判断基準：ROIの冷徹な算定
では、いかにハックしようとも、いつかは有料プラン（Standard: 月額$8〜/user、Plus: 月額$14〜/user）の門を叩くべき瞬間が訪れる。感情論を排し、エンジニアリングの生産性（Developer Velocity）というメトリクスに基づいて、その境界線を定義する。
移行すべき「3つのトリガー」
1. チーム規模と「ゲストアカウント（Guest Accounts）」の壁
- 現象: クライアント、外部コントリビューター、あるいはステークホルダーにLinearを見せたいが、社内メンバーとしてフルアクセス権を与えるわけにはいかない。
- 判断: Standardプラン以上で利用できる「ゲスト（Viewer/Limited）」権限が必要になる。無駄にフルライセンスを消費するコストと比較して、即座に元が取れる。
2. セキュリティとコンプライアンス（SAML / SCIM / 監査ログ）
- 現象: 組織がスケールし、SOC2やISO27001の監査が入る段階。あるいは、OktaやGoogle Workspaceを通じた厳格なIdP（アイデンティティプロバイダ）連携が義務付けられる。
- 判断: Plusプランへの即座の移行が必須。これはコストではなく「事業継続のための保険」である。自前でアクセス権限を管理するエンジニアの工数を考えれば、数千ドルの投資は数分で回収できる。
3. カスタムフィールド（Custom Fields）と高度な分析（Insights）の限界
- 現象: 「プラットフォーム（iOS/Android/Web）」や「顧客ティア（Enterprise/Free）」ごとのイシュー分類、あるいはサイクルタイム（Cycle Time）の高度な多次元分析が必要になった。Freeプランのデフォルト機能では、データが平坦すぎてボトルネックの特定に限界が来る。
- 判断: エンジニアの待ち時間（Blocked Time）のコストを計算せよ。例えば、5人のエンジニアが週に1時間、ボトルネックの調査に無駄な手間をかけているとする。時給換算すれば、Standardプランの月額料金など数時間で相殺できる。
—
4. 結論：ツールに予算を合わせるな、成果にツールを従わせよ
LinearのFreeプランは、極限まで無駄を削ぎ落とした精鋭チームにとって、世界最強のタスク管理環境だ。APIを叩き、スクリプトで自動化し、認知負荷の限界までイシューを削ぎ落とすプロセスそのものが、エンジニアリングチームの質を高める。
しかし、組織が成長し、セキュリティの担保や外部ステークホルダーとの協業が必要になった瞬間、ためらうことなくStandardやPlusへ移行するべきだ。ツールケチることで失う「エンジニアのコンテキストスイッチのコスト」と「開発サイクルの遅延」は、サブスクリプション料金の100倍重い。
コードを書け。APIを叩け。そして、プロダクトを高速でデリバリーしろ。Linearはそのための最も美しいレバーに過ぎないのだから。