先に結論
Linear Agent は、単に backlog を読んで要約する道具から一段進みました。
今回の更新で見えるのは、Slack や Teams から呼ぶ、良い会話を Skill として残す、triage で自動実行する という 3 段構えです。
しかも、Agent と Skills は全プランで試せます。
最初の判断は簡単です。Slack や Teams の会話から issue 化や backlog 整理が回るなら、そのまま使う価値があります。triage 自動化や codebase 理解まで欲しくなった時だけ、Business / Enterprise を検討すれば十分です。
導入先の比較から入りたいなら、Linear Agent vs Jira Agents vs GitHub Copilot for Jira を先に見ても判断しやすいです。
今回何が増えたか
今回の更新で増えたのは、会話を一度きりで終わらせない仕組みです。
まず、Slack、Microsoft Teams、コメント、デスクトップ、モバイルから Linear Agent を呼べる導線が前面に出ました。会話の場所を変えずに、issue 作成、要約、担当探し、進捗整理まで進めやすくなっています。
次に、うまくいった会話結果を Skills として保存できるようになりました。定例の進捗整理、会議メモからの issue 起票、休暇明けのキャッチアップを毎回打ち直さずに済みます。
さらに、issue が triage に入ったタイミングで Automations を走らせる案内が加わりました。新しい issue を受けた瞬間に、整理、要約、次の担当判断まで寄せられるので、planning layer の価値が少し実務寄りになっています。
Slack と Teams で何が楽になるか
一番分かりやすい変化は、Slack や Teams が単なる通知先ではなく、Agent を使う入口になったことです。
Slack では @Linear を会話の中で呼び、スレッドから bug や feature request を起こせます。誰がその領域をよく触っているかを尋ねたり、会話全体から要件を拾って issue 化したりもできます。
Linear の docs では、Slack 側で issue 作成、既存 issue への紐付け、thread sync、通知、project updates までまとめて扱える構成が案内されています。会話から起票までが近いチームほど、この導線の価値は大きいです。
Teams についても、Linear は Agent を使える surface の一つとして明示しました。Slack 中心の会社だけでなく、Microsoft 365 側へ寄せている組織でも同じ考え方を持ち込みやすくなっています。
Skills は誰に効くか
Skills が効くのは、同じ依頼を何度も書いているチームです。
たとえば、毎週の project update、商談後の要望整理、会議メモからの issue 作成は、毎回ゼロから書くと意外に重いです。
Linear Agent は、うまくいった会話を保存し、次から同じ形で再利用できます。再利用した Skill は chat のメニューや slash command から実行でき、必要なら Agent 側が適切そうな場面で使うこともあります。
ここで大事なのは、Skill が単なるテンプレではないことです。会話の狙いと出力の型を一緒に残せるので、PM や EM の頭の中にある進め方をチームへ移しやすいです。
Automations はどこで効くか
Automations は、triage を人手だけで回すのがつらいチームに向いています。
Linear は、新しい issue が triage に入った時に Agent workflow を自動で走らせる流れを案内しています。最初の整理、似た issue の確認、要件のまとめ直し、担当候補の検討を人が全部手でやらなくてよくなります。
ここは無料枠との差がはっきりしています。Agent と Skills を試して価値が見えたあと、毎回同じ整理を自動化したい なら Business / Enterprise へ上げる理由が生まれます。
Code Intelligence はまだ約束段階
Code Intelligence は期待してよいですが、まだ完成した機能として読む段階ではありません。
Linear は、codebase 理解を Agent に広げる機能として Code Intelligence を予告しました。将来的には、機能の仕組み、最近の変更、担当領域の理解まで、エンジニア以外でも聞ける形を目指しています。
ただし現時点では coming soon です。導入判断では、今すぐ買う理由ではなく、planning layer から execution layer に少し近づく方向性 として扱うのが安全です。
料金と導入判断はこう見る
今回の pricing で見やすくなったのは、どこまで無料で試せるかです。
Linear は、Agent と Skills を全プランに含め、Automations と Code Intelligence を Business / Enterprise に置いています。ベータ期間中は追加料金なしで提供しつつ、一般提供後は高計算の機能を usage-based pricing に寄せる可能性も先に明示しました。
この線引きなら、最初にやることは明確です。
- まず Agent と Skills で、会話から issue 化と backlog 整理が楽になるか確かめる
- 次に、triage を自動化したいチームだけ Automations を評価する
- codebase まで広げたいなら Code Intelligence の正式条件を待つ
最初から上位プラン前提で考えるより、この順で見たほうが失敗しにくいです。
どんなチームが試す価値が高いか
Linear Agent が特に合うのは、issue を書く前と書いた直後が重いチームです。
- PM や EM が backlog 整理に時間を取られている
- Slack や Teams の会話から issue 化することが多い
- 会議メモや顧客要望を毎回手で整えている
- 開発そのものより、何を優先するかの整理が遅い
逆に、今すぐ欲しいのが PR 作成やコード修正の自動化なら、主戦場はまだ GitHub や Jira 側です。その判断には GitHub Copilot for Jira とは？Jira起点でAIコーディングを回す方法 や Cursor in Jira rollout guide のほうが近いです。
まとめ
Linear Agent の更新で一番大きいのは、planning layer の価値が会話と自動化へ広がったことです。
- Slack / Teams から使える
- 良い会話を Skills として残せる
- triage で Automations まで伸ばせる
- Code Intelligence で codebase 理解へ進む方向が見えた
なので、まず見るべきなのは「他社より強いか」ではありません。自分たちの会話、issue 化、backlog 整理が短くなるか です。
そこが回るなら、Linear Agent はかなり試す価値があります。より広い比較が必要なら、Linear Agent vs Jira Agents vs GitHub Copilot for Jira から横並びで見ると判断しやすいです。