AI 2026年4月23日

Googleの新規コード75%がAI製。「エンジニア＝コードを書く人」という定義が終わりに近づいている

Googleが公式に認めた「75%」という数字

2026年4月22日、Google Cloud Next 2026でサンダー・ピチャイCEOが言った。

「Googleでは現在、新規コードの75%がAIによって生成され、エンジニアが承認しています」

これ、ニュースとして流れてきたとき「またAI誇張話か」と思った人もいるかもしれない。でも数字の推移を見ると、誇張どころか加速している話だとわかる。

時期	AI生成コードの割合
2024年10月	25%
2025年秋	50%
2026年4月	75%

たった1年半で3倍。しかも直線的ではなく、加速している。

なぜ今、この話をする必要があるか

「Googleだから特殊」という逃げ道は、もうあまり使えない。

GoogleはAI開発の最前線にいる企業ではある。でも彼らが75%に達したということは、ほかの大手テック企業も遠くない場所にいるということだ。去年の50%という数字が出たとき、「すごいね」で済んでいた。今年の75%は、もう「業界標準が動いている」という話になってきた。

重要なのは速度感だ。1年半で3倍というのは、技術的な実験フェーズを終えて、実運用として定着しているということを意味する。

何が変わったのか：「書く」から「監査する」へ

ピチャイの発言が注目されがちだが、もう一つ見落としてはいけない数字がある。

GoogleのエンジニアはAIが書いたコードを平均11分でレビューしている。

この11分という数字、どう解釈するか。「速い」と思う人もいれば「そんな短時間でちゃんと見られるの？」と思う人もいるはず。後者の感覚は正しい。だからこそ、エンジニアに求められる視点が変わってきている。

シンタックスを追うのではなく、セキュリティの脆弱性と設計の整合性を確認することに集中する。インジェクションや認証バイパスのリスク、アーキテクチャとしての一貫性、将来の保守性。これらはAIが自動的に保証してくれるものではない。

また、Googleは実際に大規模なコード移行をAIとエンジニアの協業で実施し、1年前と比べて6倍の速さで完了させている。「ちょっと便利」ではなく、ビジネスのスピードそのものが変わる話だ。

Googleは社内で、AIコーディングツールの利用をパフォーマンス評価に組み込んでいる。一部チームではClaude Codeのようなサードパーティツールも許可されている。ツールを使えているかどうかが、すでに評価軸になっている。

AIおじさんの見方：「適応」じゃなくて「再定義」の話だ

ピチャイのもう一つの発言を改めて読んでほしい。

「AIはエンジニアを置き換えるのではなく、エンジニアリングの意味を根本的に再定義している」

これはポジティブな言い換えではなく、かなり正確な表現だと思う。

「置き換え」だと思うとパニックになる。でも「再定義」として受け取ると、問いが変わる。「コードを書けること」がエンジニアリングの本質だと思っていたなら、その前提を一度外す必要がある。本質は何だったか——システムの設計、品質の担保、リスクの判断。それは今も残る。

ただし、留保も必要だ。「エンジニアの仕事はなくならない」という楽観論は半分正しい。でも「今のスキルセットのまま仕事が続く」は別の話だ。コードを書く量が減れば、その分だけ「判断の質」で差がつく場面が増える。ここを甘く見ると足元をすくわれる。

日本企業の話もしておくと、AIコード生成を本格導入している大企業はまだ少ない。これは遅れている、という見方もできるし、今から動けばアドバンテージになる、という見方もできる。どちらが正しいかは、動くかどうかで決まる。

実務的に何をするか：3つの軸で考える

「では何をすればいいか」という話になると、元記事でも3つが挙げられている。そのまま紹介するが、解釈を少し加えたい。

① AIコーディングツールを毎日使う

Claude Code、GitHub Copilot、Cursor。どれでもいい。重要なのは「慣れること」ではなく、「どこで間違えるかを体で知ること」だ。AIが生成したコードを信頼しすぎず、かつ無駄に疑いすぎない感覚は、使い込まないと身につかない。

② コードレビュースキルを意識的に磨く

セキュリティ、アーキテクチャの整合性、保守性。これらは以前から大事だったが、今後は「AIが書いたコードを前提として」評価する場面が増える。AIは動くコードを書くが、正しいコードを書くとは限らない。その差を見抜く力が価値になる。

③ Context Engineeringを覚える

元記事では「プロンプトエンジニアリング」ではなく「Context Engineering」という表現が使われている。プロジェクトの背景、期待する出力形式、エッジケースの事前指定——これらを正確に伝える能力は、AIへの「指示出し」のスキルとして今後ますます重要になる。ざっくり言うと、「AIに何を伝えれば意図通りの結果が出るか」を設計する力だ。