AIが書いたコードの6割が、そのまま取り込まれています。誰が6割と決めたのかを、報告書は「決めていない」と書いています。
① 事実
Faros AIが、22,000人の開発者の2年分の記録を分析しました
Faros AI（米国のソフトウェア開発組織向けの計測ツールを売る会社）が2026年、「AI Engineering Report 2026: The Acceleration Whiplash」を公開しました。分析の基準日は2026年3月です。
素材は、同社の顧客である22,000人の開発者・4,000チームの2年分のテレメトリ（開発に使う道具が自動で残す記録。タスク管理・エディタ〈コードを書く道具〉・静的解析・CI/CD〈コードの検査と配置を自動で回す仕組み〉・バージョン管理・障害管理から集めたもの）です。アンケートではありません。Farosは、このデータを取る道具を売っている会社です。
比べ方は、各チームの観測期間の中でAIの利用が最も低かった2四半期と、最も高かった2四半期の変化率です。統計的に有意で、6社以上のデータがある指標だけを載せています。前年との比較ではありません。 2025年版との比較に触れている箇所は、報告書自身が「独立した断面で、縦断パネルではない。方向の一致を示すだけ」と留保しています。
AIが書いたコードの受け入れ率は、20%から60%に上がりました
AIが生成したコードが、そのままコードベース（その製品のコード全体）に取り込まれた割合は、60%です。 2025年版では20%でした。
増やしたのは、Cursor や Claude Code のエージェントモード（AIが提案を出して人が採否を決めるのでなく、AIが直接ファイルを書き換える動かし方）だと報告書は書いています。
AIツールのライセンスを持つ開発者の割合は、横ばいでした。 席は買ってあったので、この1年で変わったのは利用率です。企業は、持っているのに使っていなかった開発者に使わせる方へ動きました。週に1回以上AIツールを使う開発者は60%（前回40%）。半数以上が週に使っているチームは、80%です。
一方、AIエージェントが自分で書いて、コミットして、レビューに出したPR（プルリクエスト＝コードの変更をまとめて提出し、取り込むかどうかの審査にかける単位）は、1%未満です。AIエージェントによるレビューは、0から25%になりました。
報告書は、「ほとんどの組織が決めないまま、AIが境界を越えた」と書いています
冒頭の要約から引きます。
人が指揮し、AIが提案し、人が決める。そうはなりませんでした。（中略）ほとんどの組織による意図した決定がないまま、AIは境界を越えました。AIが生成したコードの60%がコードベースに取り込まれている現在、助手と書き手の区別は実態として崩れています。助手ではありません。書き手です。
原文は author（著者）で、コードを書いた側という意味です。
完了した仕事は増え、本番に出る回数は減りました
AI利用が低い期から高い期への変化率です。
- 開発者1人あたりのタスク完了：+33.7%
- 開発者1人あたりのエピック（複数のスプリントにまたがる大きな機能単位）完了：+66.2%
- 開発者1人あたりのPRマージ（変更を本体に取り込むこと）率：+16.2%（2025年版では+98%）
- 週あたりのデプロイ（本番環境への配置）回数：−11.7%
デプロイ回数は、それを計測している約1割の組織だけの数字です。リードタイム（コミットから本番に出るまでの時間）も同じ約1割で、+480.4%。報告書はどちらも「方向として読む」ように留保しています。
PRマージ率の伸びが前回の98%から16%に落ちた理由を、報告書は「コードの品質がレビューの詰まりを作り、処理量を絞っている」と読んでいます。組織が生み出すコードの量が、レビューして取り込める量を超えています。
消したコードは、9.6倍になりました
コードチャーン（マージ済みのコードについて、四半期に削除した行数を追加した行数で割った比率）は、<strong>+861%</strong>でした。以前の9.6倍です。
報告書は原因を3つ挙げて、「この指標では判別できない」と書いています。
- AIのコードを受け入れてすぐ、使えないと分かって書き直している＝同じ計測期間の中で起きる手戻り。無駄。
- 人手では高くつきすぎた大規模なリファクタリング（動きを変えずにコードの構造を作り直すこと）に、AIで着手できるようになった＝何年も溜まった古いコードの置き換え。
- 出荷時点で納得していなかったコードに、戻って手を入れる頻度が上がった。
3つとも、データと矛盾しません。判別するには、消された行がいつ書かれたものかをGit（コードの変更履歴を残す仕組み）で見る必要があり、それは各組織が自分の環境でやることだと書いています。
そのうえで、こう締めています。
処理量は、何を出荷したかを測る。何が残ったかは測らない。
レビューを通らずに取り込まれたPRは、31.3%増えました
- レビューを一切通らずにマージされたPR：+31.3%
- PRあたりのレビューコメント数：+25%
- レビューの中央値の時間：+441.5%
- 1本のPRの平均サイズ（変更行数）：+51.3%
コメントの増加には留保があります。PRが大きくなっているので、行あたりの欠陥率が同じでもコメントは増えること。AIによるレビューが0から25%に増え、AIは書式や構造にも長く書くので、人が書いたコメントと区別できないこと。
レビュー時間のほうは、その影響を受けません。報告書は、レビューに届くコードの多くが「レビューできる状態になっていない」と読んでいます。 AIが書いたコードは、命名も書式も周囲と揃っていて、分かっている人が書いたように見えます。構造と論理の欠陥は表面の下にあります。見つけるには、意図を読み直して、そのコードが解こうとした問題を組み立て直す必要があります。
それができるのは経験の深いエンジニアで、その人たちの時間が、そこに溶けていると報告書は書いています。
これはコードを書く側の問題であって、レビューの問題ではない。
本番の障害は、PRあたり3.4倍になりました
- PRあたりのインシデント（本番での障害）：+242.7%（3.4倍）
- 月あたりのインシデント：+57.9%
- 開発者1人あたりのバグ：+54%（2025年版では+9%）
- 完了とされたあとに差し戻されたチケット：+12.6%
強い開発体制でも、守られていませんでした。 DevOpsの成熟度が高く、DORA（Googleが運営する開発組織の調査。4つの指標で組織の実力を測る）のスコアが高い組織でも、同じ悪化が出ています。
DORAの2025年版は「AIは組織の強みも弱みも増幅する。土台が強ければ守られる」と結論しています。Farosは、DORAがアンケートに基づいていることを指摘しています。開発者は、生産性が上がったと感じています。個人の単位では、実際に上がっているからです。 下流でレビューが詰まり、障害が積み上がることは、その感覚に月単位で遅れて届きます。
Farosの提言は「決めろ」と「意図を渡せ」です
報告書は10の提言を置いています。うち3つを引きます。
提言2「レビューの方針を決め、ゲートとして強制せよ」。 すべてのPRに人のレビューを求めると、量に押しつぶされます。どの領域は人が見るか、どの領域は信頼できるAIエージェントに任せるか、どこは両方かを、危険度で切り分けて決めます。どの方針でも、レビュー無しは認めません。
提言10「エンジニアリング環境のためのコンテキストエンジンを作れ」。 AIエージェントは、コードベースの現在の状態から意図を読み取れません。意図は、コードがどう変わってきた履歴と、その判断の理由と、積み上がった設計の決定から読めます。それを書き手の側に組み込むこと、と書いています。
もう一つ。提言9「人員を減らすな。転用せよ」。 出力が増えたことを根拠に人を減らすと、品質の問題が重なり、数か月で再雇用することになります。減らそうとしている人は、AIが作った品質の差を吸収している人だ、と書いています。
出典：
- Faros AI「AI Engineering Report 2026: The Acceleration Whiplash」（PDF・29ページ）https://pages.faros.ai/hubfs/AI_Engineering_Report_2026_The_Acceleration_Whiplash_Faros.pdf
② 構造
60%は、コードの層の数字です
ここまで、Faros AIが22,000人の開発者の記録から出した数字を見てきました。整理します。
受け入れ率60%は、コードの層の数字です。 増やしたのは、AIが直接ファイルを書き換える動かし方でした。開発者は、AIが書いたものを一行ずつ採否する形から、書き換わったものを見る形に移っています。
一方で、AIが自分でPRを開く割合は1%未満です。何を作るか、いつ出すかは、人が決めています。書き手になったのはコードの層で、仕事の順番を決める層は人のままです。
報告書は「助手ではなく書き手」と書いていますが、数字を層で分けると、書き手になった層は一つです。
決めたのは調達で、決めていないのは書き手の範囲です
報告書の「決めないまま越えた」には、中身があります。
ライセンスは横ばいでした。企業は席を買っていました。この1年でやったのは、使っていない開発者に使わせることです。つまり調達と普及は、決めています。
決めていないのは、どの層でAIを書き手にするかです。 Farosの提言2は、それを決めろと言っています。どの領域は人が見て、どの領域はAIに任せ、どこは両方か。
本紙はVol.22で、商工中金の調査から、中小企業の6割が生成AIの利用を「個人の判断に任せている」と答えた話を書きました。任せているなら、会社は決めていません。 Farosの4,000チームは規模も違い、道具も配っています。それでも、決めていない場所は同じです。規模も道具も違う組織で、似た構造の混乱が起きています。
戦略の階層に置くと、Farosが測っているのは下の二層です
本紙はVol.22で、戦略の階層を上から順に並べました。
Farosの指標は、技術の層とその手前のレビューに集中しています。受け入れ率もチャーンもレビュー時間も障害も、この層で起きていることです。何を、どの順で作るかを決める戦術の層は、AIが自分でPRを開く1%未満の数字で分かるとおり、人のままです。
提言10は、上の層の話をしています。意図はコードの現在の状態からは読めず、履歴と判断の理由と設計の決定から読める、と報告書は書きました。AIに大戦略の層を渡せ、と言い換えられます。9.6倍消され、4倍待たされている組織に、それが渡っていたかどうかは、報告書からは分かりません。提言として置かれていることから、渡っていない組織が多いと読めます。下の層の数字は、上の層を渡していないことの結果だと読めます。
「残ったか」は、自己申告でも、処理量でも出ません
DORAは開発者に訊き、Farosは記録を見ました。訊けば「上がった」と答え、記録を見ると障害が3.4倍です。 両方が正しく、見ている時点が違います。
本紙は前号で、宮崎県日向市がAIの削減時間を職員のアンケートで測っている話を書きました。出荷した量は記録に残り、残った量は記録に残りません。 同じ穴が、22,000人の開発組織にもあります。
