AIで作るのは速い、では誰が確認するのか｜内製の落とし穴

回答: AIの支援によって、反響メールの転送のような仕組みを作る工程は以前より短くなっています。ただし作る量が増えても、できたものを確認する人・止まりに気づく人・直す人の数は自動では増えません。増えた分の仕事は、その手前ではなく後ろに溜まります。これが当てはまるのは「作る人と確認する人が同じ」「動いているかを見る担当が決まっていない」場合です。確認者と復旧手順に加えて、保守できる人と監視の仕組みを確保できている場合は、内製を続ける選択肢があります。

この記事でわかること

• AIの導入後にコードの提出量が増えた研究の中身と、その数字が何を測ったものか（別業界・1社の事例）
• 作る量が増えたとき、組織の中でどこに仕事が溜まったのか
• 不動産会社が反響転送を内製する場合、同じ詰まりがどこに出るか
• 着手前に決めておく3点と、GASでの内製で十分なケース

AIで「作る速さ」は本当に上がるのか

答え: 上がったという観測があります。ただし出どころは不動産業ではなく、ソフトウェア開発会社1社の事例です。

カーネギーメロン大学とスタンフォード大学などの研究者が2026年7月に公開した論文「AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate」（arXiv:2607.01904）が、この点を追跡しています。

調査の前提は次のとおりです。

項目	内容
調査主体	カーネギーメロン大学・スタンフォード大学ほかの研究者
対象	中規模のB2Bソフトウェア企業1社（開発組織は数百人規模）
対象人数・件数	開発者 802人 / プルリクエスト 196,212件
期間	2024年1月〜2026年4月
背景	2025年6月にCTOが「AI活用で開発生産性を2倍にする」と公表した社内方針を追跡

結果として、1人あたりの提出量は方針前の基準に対して2.09倍（2026年4月時点）に達しました。論文は、これをAIコーディングツールの実地導入で報告されたものとしては大きい部類の数字だとしています。組織全体の提出量は2025年前半の基準に対して3.1倍になり、AIが書いたプルリクエストは全体の約90%を占めるようになりました。

ここは正直に受け取るべき部分です。「AIで作っても速くならない」という話ではありません。

ただし、この倍率が何を測ったものかは押さえておく必要があります。測っているのは開発者1人あたりのプルリクエスト（コードの提出単位）の件数であり、「同じ仕組みを完成させるまでの時間」ではありません。提出件数という活動量の指標が増えた、という意味です。

加えて、この数字をそのまま自社に当てはめる前に、論文自身が挙げている前提があります。

• 1社の事例である。論文も「単一企業かつAIに前向きな環境であることが外部妥当性の限界になる」と明記している
• その会社はAIツールを座席数やトークン量の上限なしで会社が負担する、AI活用に積極的な環境だった。論文はこれを「成果が出るとすればまず出るはずの、ほぼ理想に近い条件」と位置づけている
• 導入のタイミングは無作為に割り当てられていない（誰がいつ使い始めるかは本人が決めた）ため、論文は因果の大きさを「幅のあるもの」として扱っている
• 対象業務はソフトウェア開発であり、不動産業の業務ではない

つまりこの研究は「不動産会社がAIで内製したらこうなる」を示したものではありません。使えるのは、作る速さが上がったとき組織の中で何が動いたかという構造の部分です。

増えるのは「作った後」の仕事

答え: 組織全体の提出量が3.1倍になる一方、確認役にまわる人は1.5倍にとどまり、1人あたりの確認負担は約2倍になりました。

論文が記録しているのは、速くなった後に起きたことです。

• 提出量は3.1倍になったが、レビュー（確認）を担う人の数は1.5倍にしか増えなかった
• その結果、1人あたりの確認負担は約2倍になった
• 人が1回以上目を通したプルリクエストの割合は89%から68%へ（21ポイント低下）
• 代わりに、AIのレビューボットが自動で確認したものの割合が約19%から約84%へ上がり、方針の公表後まもなく人のレビューを上回った
• 残った人のレビューも中身が薄くなった。人のコメント付きレビューを受けたプルリクエストの割合は、全体の約39%から約21%へ下がり、コメントなしの承認だけがほぼ横ばい（約50%）で残った
• 中央値で見ると、1人の確認者がコメントを書いたレビューは月3件前後のまま変わらず、コメントなしの承認がおよそ倍になった

要するに、増えた仕事は「きちんと見る」ではなく「とりあえず通す」の側に積み上がりました。論文はこれを、組織が確認の不足を自動化へ振り向けて吸収した結果だと説明しています。

品質は下がったのか

ここは誇張せずに書く必要があります。論文の観測期間では、品質の低下はすぐには確認されませんでした。 マージ率とリバート（差し戻し）率はほぼ変わらず推移しています。「AIが書いたものは品質が低い」という結論は、この論文からは出せません。

一方で論文は、測れていないものがあることも書いています。

• 使った指標は粗く、短い期間のもの（マージ率・リバート率）である
• 機械のレビューが何を見落としているか、そして確認を自動化したことで人が学ばなくなったものは何かは測定していない
• AIが書いたプルリクエストは、人が最初に見てからマージされるまでが約20%長く、全体の所要時間も約22%長い。これは手戻りではなく、人の確認の待ち時間に集まっていた

読み方としては「品質が落ちた」ではなく、確認の仕事が目に見えない形で後ろに溜まり、その中身が薄くなったが正確です。

不動産会社の反響転送に置き換えると、どこに溜まるか

答え: 「媒体の変更に気づく」「止まったことに気づく」「直す」の3か所です。担当を決めずに内製した場合、この3つはいずれも作成者に集中します。

以下は論文の対象業務（ソフトウェア開発）ではなく、不動産会社が反響メールの転送をAIの助けを借りて自作する場合に、同じ構造を当てはめた読み替えです。論文が不動産業について述べたものではない点はご注意ください。

反響転送の仕組みは、作るところまでは短時間で形になります。GASで何がどこまでできるかは反響メールのチャット転送をGASで自作する方法に手順としてまとめています。詰まるのはその先です。

作った後に必要な仕事	会社側で決めておくこと	決めていないと起きること
媒体側のメール形式・画面の変更に気づく	変更に気づく担当と、気づく手段（媒体のお知らせの受信先など）	変更の後に取りこぼしが始まり、報告が上がるまで分からない
動いているか／止まっていないかを見る	実行履歴を誰がいつ開くか、失敗の通知先	失敗が「何も起きていない」ように見え、気づく契機が反響の問い合わせになる
直す・作り直す	作成者以外に対応できる人、または外部に頼む判断基準	作成者の手が空くまで止まったままになる
別の人へ引き継ぐ	渡す対象の一覧（コード・トリガー・認証情報・連携先・手順書）	コードだけ共有され、トリガーや認証情報の把握が引き継がれない

論文の会社では、確認役にまわる人が1.5倍まで増える余地がありました。少人数で内製する場合は、その余地が小さくなります。作る量が増えたぶんは、担当を決めていなければ同じ人の持ち分になります。

誤解のないように条件を付けて書くと、次のとおりです。

• 「担当者が辞めたら必ず止まる」わけではありません。 実行している個人アカウントが無効化されたり、必要な権限が失われたりすると、処理が停止するおそれがあります。止めないためには、移管・権限の複数化・手順書・定期確認を会社側で用意する必要があります（GAS自作の属人化リスク）
• 「エラーには気づけない」わけでもありません。 実行履歴を見る運用と通知を自分で作れば気づけます。決めていない場合に気づけません（GASのエラーに気づかず反響を取りこぼす理由と対策）
• 初期のコードはAIで速く作れます。 難所はコードの量ではなく、媒体側の変更検知・影響調査・修正・再実行の判断を誰が責任を持つかです

着手前に決めておく3点

答え: 「誰が見るか」「どう気づくか」「直せないときどうするか」を、作る前に名前を入れて決めます。

内製を止める必要はありません。決める順番を変えるだけで、後ろに溜まる量が変わります。

1. 確認する人を決める。可能なら作った人以外から1人選ぶ

コードを読める人である必要はありません。「週に1回、転送件数と失敗件数を見る」「媒体からのお知らせメールを受け取る」役でも、変更に気づく契機になります。論文の会社で薄くなったのは、まさにこの「人が中身を見る」部分でした。1人で運用せざるを得ない場合は、代わりに監視の通知先・手順書・不在時の引き継ぎ先を先に整えておきます。

1. 止まったことに気づく道筋を決める

実行履歴を誰がいつ開くか、失敗したときどこへ通知するかを決めます。通知先が作った本人の個人アカウントだけになっていないかを確認してください。

1. 直せなくなったときの引き継ぎ先を決める

書いた人が離れたときに誰へ渡すか、渡す対象は何か（コード・トリガー・認証情報・連携先・手順書）を列挙しておきます。この棚卸しは自作したメール転送、止めずに運用できていますか ― 20項目の棚卸しチェックリストに20項目として並べています。

3点とも「担当者名が入るか」で判断してください。名前が入らない項目には、作る量が増えたぶんだけ仕事が溜まります。

GASでの内製で十分なケース／別の手段を検討したいケース

答え: 遅れや取りこぼしが事故や売上の損失にならない範囲であれば、内製で十分です。

全面的にどちらかが優れている、という話ではありません。

内製（GAS等）で十分なことが多い	別の手段も検討したい
1〜数分の遅延が問題にならない	反響の初動速度が受託率に直接影響する
転送漏れが事故や売上損失にならない	個人情報・図面・請求書を扱う
少量・単一チャネル・単純なメール形式	複数店舗・複数グループへ振り分ける
保守できる担当と確認体制がある	停止を自社で検知・復旧しづらい
障害時に社内で復旧できる	担当が変わっても続けたい

両方に分かれる場合は、全部を一度に決める必要はありません。取りこぼすと痛い反響だけを外に任せ、残りは内製で持つという分け方もできます。

なお、数秒単位の即時性が要件に入る場合は、作りが変わります。Apps Scriptの時刻トリガーは、公式ドキュメントで「最短で1分ごと」と示されている間隔で動きます（Installable triggers | Apps Script）。またインストール型トリガーの対象イベントに、Gmailの受信そのものを契機にするものは含まれていません。数秒を狙うならGmail APIとCloud Pub/Subを使うクラウド構成になり、監視や再同期の作り込みが別に必要になります。この違いは反響対応をAI+GASで自作する前の4つのリスクでも扱っています。

よくある質問

AIが書いたコードは品質が低いのですか

今回の論文からは、そうは言えません。観測期間中、マージ率とリバート率はほぼ変わらず、短期の粗い指標では品質低下は確認されませんでした。ただし論文は、機械のレビューが何を見落としているかは測っていないと明記しています。「品質が下がる」ではなく「確認が薄くなったまま進む」が、この研究から読み取れることです。

確認もAIに任せればよいのではないですか

論文の会社では実際にそれが起きました。自動のAIレビューは約19%から約84%へ増え、人のレビューを上回りました。短期の指標は悪化していません。一方で論文は、機械のレビューの見落としと、人が確認をやめたことで学ばなくなるものは測定対象外だと述べています。任せられる範囲と、人が見る範囲を分けて決めるのが現実的です。

担当者1人でも内製できますか

確認者を別に置けない場合でも、本文の3点を1人で満たせる形に整えれば運用できます。条件は、その1人が離れる場面を先に想定しておくことです。具体的には、動作しているアカウントが個人のものになっていないか、失敗の通知先がその人だけになっていないか、手順が本人の頭の中だけにないかの3点です。満たせない場合、内製の可否ではなく「止まったときに誰も動けない」ことが問題になります。

不動産業でも同じ倍率になりますか

分かりません。論文の対象はソフトウェア開発であり、AI活用に積極的な1社の事例です。論文自身が外部妥当性の限界を認めています。倍率を持ち込むのではなく、「作る量が増えると、確認・復旧・引き継ぎの担い手を決めていない場所に仕事が溜まる」という構造だけを参考にしてください。

まとめ

AIコーディングツールの導入後に、開発者1人あたりのコード提出件数が増えた事例が報告されています。論文が記録したのは、その先で何が起きたかです。組織全体の提出量が3.1倍になる一方で確認役は1.5倍にとどまり、1人あたりの負担は約2倍になり、人のコメント付きレビューを受けたプルリクエストの割合は全体の約39%から約21%へ減りました。

内製を避ける理由にはなりません。順番の問題です。作り始める前に「誰が見るか」「どう気づくか」「直せないときどうするか」の3点に担当者名と実行できる手順を入れ、その体制で運用できるかを確認してください。決めないまま進めると、増えたぶんは後ろに溜まります。

いまの自作の状態を確認するところから始める場合は、20項目の棚卸しチェックリストをお使いください。

—

この記事を書いた会社

7plus株式会社 不動産会社向けの営業DX支援を行うITソリューションプロバイダーです。反響対応を即時化する「Mail2Link」「Mail2Link×AI」、ノーコード業務アプリ「BizBlock」の開発・提供に加え、Salesforce認定パートナーとして不動産特化型Salesforceパッケージの導入・定着コンサルティングも行っています。

詳しくはこちら → https://7plus.jp/