生成AIに指示すれば、短時間で大量のコードを作れるようになりました。しかし、企業のソフトウェア開発では、書き上がったコードをそのまま本番環境へ投入できるわけではありません。変更内容をプルリクエストとして提出し、担当者が設計上の妥当性や安全性を確認し、必要な修正とテストを重ねて初めてリリースへ進みます。コードの作成だけが速くなれば、その後工程に処理しきれない変更が集中するのは自然な流れです。

アプリケーション開発インテリジェンスを手掛ける新興企業LinearBは、250組織の270万件を超えるプルリクエストを分析しました。同社によると、AIコーディングツールを利用する組織では、マージされたコード変更が前年比でほぼ2倍に増えています。ところが、AI支援によるプルリクエストは規模が約2.6倍に膨らみ、レビュー待ち時間は5倍を超えました。

| 確認された指標 | AI活用時の状況 | 読み取れる課題 |
| --- | --- | --- |
| マージされた変更 | 前年比でほぼ2倍 | 下流工程へ流れる変更量が増加 |
| プルリクエストの規模 | 約2.6倍 | レビュー対象が大型化 |
| レビュー待ち時間 | 5倍超 | 確認工程に滞留が発生 |
| エージェント提案のマージ率 | エリート組織でも79％ | 人間作成コードの92％を下回る |



注目すべきなのは、生成量の増加が、そのまま価値提供の速度にはつながっていない点です。LinearBが「エリート組織」と表現する開発組織でも、AIエージェントが提案した変更のマージ率は79％にとどまり、人間が書いたコードの92％を下回りました。却下や再作業が増えれば、レビュー担当者の時間だけでなく、生成時に使った計算資源も無駄になりかねません。

企業が見るべき指標は、AIが何行のコードを書いたかではなく、変更が安全に承認され、利用者へ届くまでの流れです。LinearBが打ち出したAgentic Studioは、この滞留を個々の開発者の努力で解消するのではなく、開発工程の文脈を人間とAIの双方へ渡すことで改善しようとしています。

従来の開発分析ツールは、サイクルタイムやレビュー時間、プルリクエスト数といった指標をダッシュボードに表示してきました。状況を定点観測するには役立ちますが、数値が悪化した理由や、誰が何を変えるべきかまでは必ずしも示しません。レビューに2日かかっていると分かっても、変更が大きすぎるのか、適切な担当者へ届いていないのか、勤務時間帯が重なっていないのかで、必要な対策は変わります。



生成AIの導入後は、この弱点が目立ちやすくなります。人間の開発者であれば、組織内の暗黙知や過去の障害、担当領域を踏まえて変更を調整できます。AIエージェントは、与えられた情報の範囲外にある事情を自力では把握できません。コード単体では正しく見えても、過去に本番障害を起こした箇所へ不用意に触れたり、本来の所有チームを飛び越えて修正を提案したりする恐れがあります。

LinearBの最高執行責任者Dan Lines氏は、エンジニアリング責任者から長年寄せられてきた不満を、指標は有用でも次の行動を教えてくれないことだと説明しています。問題を示す機能と、原因を絞り込んで対処を提案する機能の間には隔たりがあるという見方です。

Agentic Studioが狙うのは、この隔たりを文脈で埋めることです。開発速度の低下を単一の平均値として扱わず、リポジトリ、案件管理、変更履歴などの関係をたどり、停滞がどこで生じているかを質問できる形へ変換します。企業にとっては、ダッシュボードを増やすことよりも、既存データから意思決定につながる説明を取り出せるかどうかが焦点になります。

Agentic Studioは、Gitリポジトリやプロジェクト管理ツールから得られるデータと洞察を正規化し、統合されたコンテキスト層として提供します。ツールごとに形式や呼び方が異なる情報を関連付け、ソフトウェアが企画されてから変更、レビュー、リリースへ至るまでの流れを横断的に捉える仕組みです。



LinearBの共同創業者兼最高経営責任者Ori Keren氏は、同社がソフトウェアデリバリーのライフサイクル全体を表す独自のナレッジグラフを保有していると説明しています。ナレッジグラフとは、単にデータを一覧にするのではなく、変更、担当者、リポジトリ、障害、作業項目などの関係を結び付けて扱う考え方です。たとえば、レビュー時間の増加と特定チームの担当範囲、過去の手戻りを関連付けられれば、平均値だけでは見えなかった原因候補を探しやすくなります。

利用者は複数のグラフを見比べながら仮説を立てる代わりに、リリース速度が落ちた理由などを自然な言葉で質問できます。Agentic Studioは、関連する開発データを基に根本原因を探し、改善に向けた推奨事項を返す設計です。エンジニアリング責任者だけでなく、現場の開発者も同じ文脈を参照できれば、数値の解釈を巡る認識のずれを減らせるでしょう。

ただし、回答の品質は接続されたデータの整合性に左右されると考えられます。担当者情報や案件の状態が更新されていなければ、統合しても誤った関係が作られかねません。導入を検討する企業には、分析機能の評価と並行して、リポジトリや案件管理ツールの運用ルールを点検する作業が求められます。Agentic Studioは散在する情報をつなぐ基盤であり、入力データそのものの管理まで不要にするものではありません。

Agentic Studioの特徴は、人間向けの分析画面にとどまらず、自律的に作業するコーディングエージェントにも同じ文脈を提供する点です。LinearBは、Model Context Protocol、略してMCPなどのプロトコルを通じて連携します。MCPは、AIアプリケーションが外部のデータや機能へ接続するための共通の受け渡し方法として利用される仕様です。



AIエージェントへ供給される情報には、過去の手戻り率、本番環境で起きた障害、コードの所有者などが含まれます。これらはコードの構文だけを読んでも分かりません。変更対象が過去に問題を起こした領域であれば慎重な検証が必要ですし、特定チームが管理する部分なら、早い段階で適切なレビュー担当者を割り当てる判断につながります。

企業向け開発では、正しいコードを生成することと、組織の条件に沿って安全に変更することは別の課題です。同じ修正であっても、影響範囲、サービスの重要度、過去の障害履歴によって求められるレビューの深さは変わります。Agentic Studioは、AIエージェントが背景を知らないままプルリクエストを変更する事態を防ぎ、作業ごとに判断を調整できる状態を目指しています。

ここでの文脈共有は、AIへ無制限に社内情報を渡すことを意味しません。企業が実際に運用する際は、どのエージェントが、どのリポジトリの、どの種類の履歴へアクセスできるかを定める必要があるでしょう。権限管理や監査記録、機密情報の扱いを既存の開発統制へ組み込めるかが導入判断の要点になります。今回公表された範囲では、こうした運用設定の詳細までは明らかにされていません。

暗号資産取引所を運営するKrakenは、LinearBのMCP連携を利用した初期導入企業の一つです。同社ではコードレビューの遅れが課題になっていました。プルリクエストが大きければ確認に時間がかかるため、変更規模が原因だと考えたくなりますが、分析で浮かび上がった主因は別の場所にありました。



Agentic Studioが示したのは、タイムゾーンのずれです。レビューを依頼する側と対応する側の勤務時間がかみ合わなければ、内容が難しくなくても次の応答まで待ち時間が生じます。この空白は、一件ごとには小さく見えても、質問、修正、再確認が往復するたびに積み重なります。コードの複雑さだけを測るダッシュボードでは、人の稼働時間に起因する滞留を捉えにくかったと考えられます。

Krakenは特定した原因に合わせてワークフローを再編し、4カ月以内にレビュー時間を半分以下へ短縮しました。この事例が示すのは、AIによる自動化の量を増やすことより、待ち時間が生まれる条件を具体的に把握する方が効果的な場合もあるということです。原因が変更規模ならプルリクエストの分割が候補になりますが、タイムゾーンなら担当配置や引き継ぎ方法を見直さなければ改善しません。

同社の成果を、あらゆる企業で同じ期間に再現できると捉えるべきではありません。組織構造やレビュー規則、システムの複雑さは企業ごとに異なるためです。それでも、既存の仮説をデータで検証し、実際の原因に合った対策を選んだ流れは参考になります。開発改善では、測定値を眺めるだけでなく、その背後にあるチーム間の関係や業務の時間軸まで確かめる必要があります。

LinearBは、得られた文脈をAIエージェントの行動へ反映させるため、複数のエージェントスキルを開発しています。最初の機能であるエフォートスキルは早期アクセスとして提供されており、プルリクエストと変更内容の複雑さ、過去の手戻り、リスクを分析します。その結果を使い、コーディングエージェントが作業へ割り当てる計算上の労力を動的に調整します。



単純でリスクの低い変更には、少ないトークンで素早く対応します。影響が大きく優先度の高い変更では、より深い推論と広範なテストを適用する方針です。すべての作業へ同じ水準の計算資源を投入する方式と比べ、速度、費用、安全性のバランスを案件ごとに変えられる構想となっています。

この仕組みでは、リスク判定の根拠が重要です。小さな差分でも、認証や決済など影響の大きい領域に触れるなら慎重な確認が必要かもしれません。反対に、変更量が多くても、限定された低リスク領域であれば、重い推論を常に求める必要はないでしょう。差分の行数だけでなく、所有関係や障害履歴、手戻りを参照することに、コンテキスト層を持つ意味があります。

LinearBは今後数カ月で、エージェントスキルのライブラリを拡充する計画です。対象として挙げているのは、自動コードレビュー、マージ時のガバナンス、トークン費用の最適化です。提供時期や具体的な機能範囲は現時点で詳しく示されていません。企業が評価する際は、生成速度だけでなく、リスク分類の精度、誤判定時の人間による介入、費用をどこまで追跡できるかも確認項目になります。

Agentic Studioの発表から読み取れる中心的な変化は、生成AIの競争軸がコード生成能力だけではなく、組織固有の文脈を使って変更を完了させる能力へ移りつつあることです。AIツールを追加しても、レビュー担当者、変更履歴、障害情報、案件管理が分断されたままなら、生成されたコードが滞留する可能性は残ります。導入数や利用回数よりも、変更がマージされる割合、レビュー待ち、手戻りといった下流指標を追う必要があります。



日本企業が検討する際の第一の観点は、問題の所在です。コード作成に時間がかかっているのか、レビュー依頼から着手までが長いのか、修正の往復が多いのかを分けて測らなければ、適切な機能を選べません。Krakenの例のように、想定していた原因と実際の原因が異なる場合もあります。少数のチームやリポジトリを対象に、生成からマージまでの時間を工程別に把握するところから始めるのが現実的です。

第二の観点は、文脈データの品質とアクセス範囲です。コード所有者や案件の状態が古ければ、AIの推奨も不正確になり得ます。機密性の高いリポジトリや本番障害の履歴を接続する場合は、権限、保存範囲、監査方法を確認しなければなりません。MCPへ接続できること自体よりも、必要な情報だけを安全に渡せるかが重要になります。

第三の観点は、人間が最終判断へ関与する設計です。エージェントがリスクを推定して計算量やテストを変える場合でも、重大な変更を自動承認するかどうかは別の判断です。既存のレビュー規則や責任分担と整合させ、AIの提案理由を担当者が検証できる状態が望まれます。

着手時には、新しいダッシュボードを全社展開するより、レビュー待ちが目立つ一つの工程を選ぶ方が成果を評価しやすくなります。現在の待ち時間、手戻り、マージ率を基準値として記録し、文脈を与えた後に何が変わったかを確かめます。AIが書いたコードの量ではなく、安全に本番へ届けられた変更を測定対象に置くことが、次の投資判断につながるでしょう。