トークン消費では見えない層を測る
Linear が「How teams build」という定量レポートの第1版を公開した。有償ワークスペースの実データから、AI が製品開発をどう変えたかを 6 年分の時系列で観測している。著者は Head of data の Tim Qi。
モデル提供各社やコーディングツールは、これまでトークン使用量やコード生成量に関する数字を数多く公開してきた。だがそれは作業のうちの一層でしかない。Linear が自ら述べているのは、最初の Issue から、それを閉じる Pull Request までのワークフロー全体を見られる立場にあるという点だ。実際、このレポートで最も価値のある発見は、コード量ではなく「人間が何にどれだけ時間を使ったか」の側から出てきている。
レポートは 3 部構成で、それぞれ 3 つの指標を持つ。
Adoption（誰が使っているか）
職種別、経営層別、企業規模別の AI アクティブ率。直近 30 日の利用有無で測る。
Application（どこに時間を使うか）
作成・整理、計画、AI という 3 領域での、ユーザーあたり月間作業時間の推移。
Output（どれだけ出荷したか）
非エンジニアの PR 添付率、ワークスペースあたり総 PR 数、コーディングエージェント有無による差。
観測できない範囲
Linear の外で起きた AI 利用は完全に不可視。市場全体ではなく Linear の顧客ベースの姿である、と明記されている。
採用は職種も企業規模もほぼ選ばない
2026 年 1 月から 6 月のわずか半年で、AI 機能のアクティブ率はすべての職種で 2 倍以上になった。伸びが最も速かったのは Engineering ではなく Product だった。
| 職種 | 2026年1月 | 2026年6月 | 変化 |
|---|---|---|---|
| Product | 12% | 34% | +22pp |
| Engineering | 12% | 30% | +18pp |
| Founder | 14% | 30% | +16pp |
| Design | 6% | 22% | +16pp |
| GTM | 5% | 18% | +13pp |
コードベースから最も遠い GTM ですら 5% から 18% に伸びている。AI の採用はもうエンジニアだけの話ではない、という主張の裏付けとしてはかなり強い。
さらに目を引くのが経営層のカットだ。従業員 201 名以上の企業の CEO は 9% から 36% へ、+27pp とレポート全体で最大の伸びを記録している。Linear はこれを「最上位のリーダーが、読むのではなく使うことでこの技術を学んでいる」と解釈している。
そして企業規模はほとんど効いていない。1001 名以上でも 1〜50 名でも、採用率はおおむね 3 倍になった。通常なら新技術の採用速度をよく説明する変数が、ここではまったく分岐条件になっていない。
AI が Issue のほぼ半分を書いている
2 年前、AI によって作成された Issue は 1000 件に 1 件を下回っていた。それが 2026 年 8 月第 1 週の時点で、次の水準に達している。
| 作成元 | 2024年6月（週） | 2026年8月（週） |
|---|---|---|
| エージェント・MCP クライアント | 約 0 件 | 約 2,435,000 件 |
| 人間・インテグレーション | 約 605,000 件 | 約 2,481,000 件 |
ほぼ拮抗している。この勢いが続けば、AI が作成する Issue は人間とインテグレーションの合計を近いうちに追い越す。転換点は明確に 2026 年 1 月以降で、そこから半年で 10 倍以上に膨らんでいる。
実務上の含意: Issue はチケット管理ツールにおいて、人間の意図をシステムに流し込む入口だった。その半分がエージェント生成に置き換わるということは、Issue を読んで動く下流のツールやスキルにとって、入力の性質そのものが変わることを意味する。人間が書く Issue は省略が多く文脈が暗黙、エージェントが書く Issue は冗長だが明示的になりやすい。
出力は 2 年で倍増、その大半はエージェント由来
興味深いのは、この加速がどこから来ているかを Linear が分解している点だ。コーディングエージェントを接続したチームとそうでないチームで、固定コホートの推移を比べている。
| コホート | 2024年6月 | 2026年6月 |
|---|---|---|
| コーディングエージェント連携チーム | 21 PR / 週 | 65 PR / 週 |
| 従来型チーム | 8 PR / 週 | 10 PR / 週 |
職種でも企業規模でも差がつかなかったのに、エージェントを繋いだかどうかだけが 3 倍の差を生んでいる。ただしレポート自身が注意を促している通り、これらのチームはエージェントが存在する前から高出力だった。21 対 8 という初期値の差がすでにある以上、水準の直接比較には意味がなく、各コホートを自分自身のベースラインと比べる読み方しかできない。
もうひとつ、役割の境界が溶けつつあることを示す数字がある。PR を添付したユーザーの割合だ。
| 職種 | 2024年6月 | 2026年6月 |
|---|---|---|
| Engineering | 20% | 34% |
| Founder | 11% | 23% |
| Product | 3% | 10% |
| Design | 1% | 8% |
| GTM | 1% | 3% |
Linear の表現を借りれば、変更を説明していた人が、自分で出荷するようになった。しかもこれは Linear に接続されたリポジトリのみのカウントなので、実際の値の下限にすぎない。
最大の発見は「時間が減っていない」こと
ここがこのレポートで最も重要な部分だと思う。Linear は時短をまったく観測できなかった。
2025 年 6 月と 2026 年 6 月で、ユーザーあたりの月間作業時間を比較すると、既存業務の時間はほぼすべての職種で増えている。
| 領域 | 2025年6月 | 2026年6月 |
|---|---|---|
| 作成・トリアージ（Engineering） | 24分 | 28分 |
| コメント（Engineering） | 35分 | 40分 |
| 作成・トリアージ（Founder） | 40分 | 57分 |
| コメント（Founder） | 39分 | 64分 |
| AI チャット（Product） | 0分 | 5分 |
| エージェント Issue（Engineering） | 0分 | 1分 |
AI チャットとエージェントへの委任は、1 年前には存在しなかったカテゴリの作業だ。それが全職種の週に現れている。そして何も縮まなかった。AI は既存の作業を置き換えたのではなく、その上に新しい層として乗った。
Linear はこれを「より多くの作業にはより多くの調整が必要で、その調整がエージェントの動作する文脈を作る」と説明している。締めくくりの言葉はもう少し踏み込んでいて、AI にはトークン消費を超えたところで Jevons のパラドックス的な性質があるとしている。効率が上がった分だけ、総消費量が増える構造だ。
意思決定のフェーズにはまだ食い込めていない
ほぼすべての指標が上振れした 1 年のなかで、唯一動かなかった領域がある。顧客要望、ドキュメント、プロジェクトに費やす時間、つまり計画のフェーズだ。全職種で ±1 分の範囲に収まっている。
この横ばいが示すもの: AI は「どう作るか」を大きく変えたが、「何を作るかを決める」プロセスはこれまでのところほとんど変えていない。計画の実践はチームごとの差が大きく、多くが Linear に記録される前の会話のなかで起きているため平均が鈍る、という留保はつくものの、実装フェーズとの対比は鮮明だ。
裏を返せば、ここは市場全体でまだ手つかずの領域ということでもある。エージェント関連の投資が実装フェーズに集中している現状は、この数字とよく一致している。
このデータの読み方
レポート自身が自らの限界をかなり率直に列挙している。数字を引用する側としては、こちらを外さないほうがいい。
解釈上の制約
- Linear の外で起きた AI 利用は観測できない。市場全体ではなく Linear の顧客ベースの姿である
- 有償ワークスペース限定。無料ユーザーや個人開発は含まれない
- PR は「オープンされた数」であって「マージされた数」ではない。かつ Linear に接続されたリポジトリのみのカウント
- コーディングエージェント連携チームは 2024 年時点ですでに高出力だった。水準の直接比較はできない
- 職種分類は職位名の正規化ベースで、エッジケースに誤差がある
- Founder のコホートは小さく、振れ幅が大きい
- 企業規模はサードパーティのエンリッチメント由来で、このカットだけ対象が少ない
- 年末年始に見られる大きな落ち込みは季節要因であり、トレンドと混同しない
そして最も重要な留保として、Linear は出力の増加が事業成果に繋がったかどうかは分からないと明言している。観測できるのは AI 採用と加速の相関だけだ、と。
それでも Linear は、PR を指標にすること自体には意味があると主張する。PR は価値ではなく動きを示すにすぎないが、それはトークンよりは前進だという立場だ。機械的なリファクタリングは大量のトークンを焼くが、意味のあるバグ修正やコードレビューはそうではない。だからトークン支出と価値はまったく揃わず、片方を他方の代理指標にすることは「AI 黎明期の遺物」として記憶されるだろう、と締めている。
ハーネス設計への含意
個人的に、このレポートで一番自分の設計判断が揺さぶられたのは「時間が減っていない」という一点に尽きる。
自分が組んでいる Claude Code ハーネスは、不可逆・外部影響のあるアクションで止める、敵対的な品質レビューを挟む、バッチ進捗をまとめて確認する、という形でゲートを設計している。どれも人間の関与を減らす方向の設計だ。だが Linear の観測が示すのは、AI を入れたチームの人間側の時間はむしろ増えるという実態である。
ゲートの評価軸を「回数」から「密度」へ
人間が楽になるのではなく、コンテキスト供給者と判断者に配置転換され、その仕事量自体は増える。だとすればゲートの評価軸は「何回止まったか（少ないほど良い）」ではなく「止まった 1 回あたりにどれだけ濃い判断ができたか」であるべきだ。ハーネスの評価フレームワークを根本から見直す必要がある。
motion と value を分けて記録する
Linear 自身が「PR は動きであって価値ではない」と認め、次版でライフサイクル全体を追うと予告している。個人スケールのハーネスなら、PR 数とマージ後に生き残った変更を分けて記録することは今すぐできる。指標設計で先に手を打てる領域だ。
人間の介在時間そのものを計測する
AI で時間が減っていないのなら、減っていないことをまず測るべきだ。ループのログに人間の介在時間を残しておけば、ゲートの設計変更が実際に何を変えたのかを事後に検証できる。
エージェントを繋ぐ組織能力は交絡している
「エージェント連携チームは元から高出力だった」という但し書きは重い。ツールを入れれば 3 倍になるという読み方は誤りで、エージェントを繋げるだけの体制がすでにあったことのほうが効いている可能性がある。個人の文脈に引き直せば、ハーネスが効くのは元々ループを回せている人であって、ハーネスがループを作ってくれるわけではない。
まとめ
Linear の「How teams build」第 1 版は、トークンやコード量ではなく Issue から PR までのワークフロー全体を測った点で、既存の AI 利用レポートとは性質が違う。
採用は職種も企業規模もほぼ選ばずに半年で 2〜3 倍になり、AI が作成する Issue は人間が作成する数に迫っている。出力面では PR が 2 年で 111% 増え、その加速のほぼすべてがコーディングエージェントを接続したチームに集中している。
だがその利得は時間の節約としては現れていない。既存の作業時間は維持されたまま AI 利用が新しい層として上に乗り、製品開発に費やす総時間はむしろ増えている。一方で「何を作るか」を決める計画のフェーズは 1 年間ほとんど動いていない。
AI 前提のワークフローを自分で設計している立場からすると、この 2 つ ── 人間の時間は減らない、意思決定はまだ手つかず ── は、そのまま設計指針として使える観測だと思う。