Google Agent Smith コードの25%を作成: APIチームが知っておくべきこと

要約

Googleの社内AIコーディングエージェント「Agent Smith」は、現在、同社の新しい本番コードの25%以上を生成しています。Copilotのような自動補完ツールとは異なり、Agent Smithはバックグラウンドで非同期に動作し、人間の介入なしにコードの作成、テスト、反復を行います。APIチームにとって、コードベースの4分の1が機械によって生成される場合、契約の安定性、テストカバレッジ、ドキュメントのずれ、レビューワークフローについて疑問が生じます。

はじめに

2026年3月の決算説明会で、GoogleのCEOスンダー・ピチャイは、ソフトウェア業界全体を立ち止まらせる数字を発表しました。Googleで生成される新しいコードの25%以上が、現在AIによって生成されているというものです。

これは自動補完ではありません。開発者が受け入れたCopilotの提案でもありません。これはAI生成後、本番環境に出荷されるコードです。その背後にあるツールは、社内でAgent Smith（映画『マトリックス』の自己複製する敵役への言及）と呼ばれ、Googleの18万人以上の従業員の間で非常に人気となり、インフラの負荷を管理するために同社はアクセスを制限する必要がありました。

Agent Smithは、今日のほとんどの開発者が使用するAIコーディングツールとは異なるカテゴリに属します。CopilotやClaude Codeがリアルタイムで支援するのに対し、Agent Smithはバックグラウンドで動作します。エンジニアはタスクを割り当て、作業を離れ、後で戻って完了した作業を確認します。

API開発チームにとって、「AI支援」から「AI生成」コードへのこの変化は、現実的な疑問を提起します。コードベースの25%が自律型エージェントによって記述されている場合、API契約をどのように安定に保つのでしょうか？機械生成されたエンドポイントがテストでカバーされていることをどのように保証するのでしょうか？ドキュメントのずれをどのように防ぐのでしょうか？

💡

Apidogの統合APIライフサイクルプラットフォームは、人間またはAIエージェントが変更を行うかどうかにかかわらず、デザイン、テスト、モック、ドキュメントを同期させます。エージェント対策済みのAPIワークフローを構築するために、Apidogを無料で試してみてください。

ボタン

この記事では、Agent Smithが何をするのか、他のAIコーディングツールとどう異なるのか、そしてAPIチームが何を準備すべきかについて解説します。

Agent Smithの機能

非同期自律型コーディング

Agent SmithはIDEで入力を待つことはありません。バックグラウンドで非同期に動作します。ワークフローは以下の通りです。

エンジニアがタスクを自然言語で記述する
Agent Smithがタスクをサブタスクに分解する
複数のファイルにわたってコードを記述する
テストを実行し、失敗した場合は反復する
エンジニアが完了した作業を確認する

これは、Copilotのインライン提案やClaude Codeのインタラクティブセッションとは根本的に異なります。Agent Smithは、チケットを受け取り、数時間姿を消し、プルリクエストを持って戻ってくるジュニア開発者に近い存在です。

エンジニアは、Googleの社内チャットプラットフォームを介して、モバイルデバイスからでもタスクを委任し、進捗状況を確認できます。このツールは、従業員のプロファイルと関連ドキュメントに自動的にアクセスし、Googleの社内ナレッジベースからコンテキストを抽出します。

GeminiとAntigravityを基盤とする

Agent Smithは、GoogleのGeminiモデルファミリー上で動作し、Googleの広大な社内コードベースとドキュメントへのアクセスを提供する検索システムによって強化されています。これは、Googleの既存のエージェント型コーディングプラットフォームであるAntigravityの上に構築されていますが、自律的なタスク分解と実行機能を追加して拡張されています。

検索拡張が鍵です。Agent Smithは単独でコードを生成するわけではありません。Googleの社内コードベースで類似のパターンを検索し、既存の実装を参照し、社内のコーディング規約に従います。このコンテキスト認識が、25%という規模での本番品質の出力を可能にしています。

「新しいコードの25%」が意味するもの

ピチャイ氏の数字には文脈が必要です。「新しいコードの25%」とは、以下のコードを指します。

AIによって生成され、自動補完されたものではない
コードレビューを通過したもの（人間のエンジニアがAgent Smithの出力もレビューする）
本番システムで出荷されるもの
Googleの全エンジニアリング成果全体で測定されるもの

これは、Googleのコードベース全体の25%がAI生成であることを意味するものではありません。今日の新しいコードの25%がAgent Smithから来ているということです。この区別は重要です。なぜなら、新しいコードは既存の人間が書いたコードベースに追加されるからです。しかし、その傾向は明らかです。この割合は増加しており、ピチャイ氏もそれを戦略的優位性として強調しています。

Agent Smithが他のAIコーディングツールと異なる点

AIコーディングツールのスペクトル

ツール	モード	インタラクション	スコープ	本番コード？
GitHub Copilot	リアルタイム自動補完	IDE内インライン	行/関数レベル	人間が受け入れた後
Claude Code	インタラクティブセッション	会話型	複数ファイル変更	人間がレビューした後
Cursor Agent	バックグラウンド + インタラクティブ	IDE組み込み	プロジェクトレベル	人間がレビューした後
Agent Smith	非同期自律型	タスク委任	フル機能実装	人間がレビューした後
KAIROS (未リリース)	常時稼働デーモン	バックグラウンド監視	リポジトリ全体	未定

Agent Smithはこのスペクトルの自律型側に位置します。これ以上進むとすれば、人間のレビューなしで完全に自律的なデプロイメントとなるでしょうが、主要なツールでそのようなものはまだありません（そしてそうすべきではありません）。

APIチームにとって非同期が重要な理由

リアルタイムAIコーディングツール（Copilot、Claude Code）は、開発者の作業フロー内で機能します。開発者はAIが記述した内容を確認し、コンテキストを理解し、その場で修正を行います。

非同期エージェントは、このダイナミクスを変えます。Agent SmithがAPIエンドポイントを記述した場合、開発者は後からそれをレビューします。レビューは作成コンテキストから分離されます。これは以下のことを意味します。

開発者は、エージェントが特定の応答フォーマットを選択した理由を理解できない場合があります。
API契約の変更が、標準的なコードレビューでは明らかにならない場合があります。
関連する成果物（テスト、ドキュメント、モック）が更新されていない場合があります。
レビュアーが完全な影響を確認しない場合、破壊的変更が見過ごされる可能性があります。

AIがAPIコードを記述する際に問題となること

API契約のずれ

API契約とは、サービスとその消費者間の合意であり、エンドポイント、リクエスト/レスポンススキーマ、ステータスコード、エラーフォーマットなどを指します。人間の開発者がAPIを変更する場合、通常はOpenAPI仕様を更新し、消費者に通知し、変更にバージョンを付けます。

自律型エージェントがAPIを変更する場合、これらの調整ステップは自動的に行われません。Agent Smithはテストをパスするコードを記述します。しかし、テストは以前に記述されたものしかカバーしません。エージェントが既存のテストをパスするが、ダウンストリームの消費者を壊す形で応答スキーマを変更した場合、その破損は本番環境で現れます。

例：

Agent Smithに「プロファイルエンドポイントにユーザー設定を追加する」というタスクが与えられます。
GET /api/users/{id} レスポンスにpreferencesフィールドを追加します。
既存のテストは、追加フィールドの不在をアサートしないため、パスします。
フロントエンドチームのTypeScript型にpreferencesが含まれていません。
モバイルアプリの厳格なJSONパースが、予期せぬフィールドでエラーを発生させます。

コードは正しい。テストもパスする。しかし、契約は破綻している。

テストカバレッジのギャップ

AI生成コードにはAI生成テストが付属しており、AIエージェントは回帰を防ぐテストではなく、構築したものを検証するテストを記述する傾向があります。これにより死角が生じます。テストは新しい動作が機能することを確認しますが、既存の動作が維持されていることを確認しません。

APIエンドポイントの場合、これは以下のことを意味します。

応答時間のベンチマークがテストされない場合があります。
エラー応答フォーマットが、標準のエラー構成と異なる場合があります。
レート制限の動作が検証されない場合があります。
認証の例外ケースがカバーされない場合があります。
ページネーションの動作が既存のエンドポイントと異なる場合があります。

ドキュメントのずれ

APIドキュメントがコード注釈やOpenAPI仕様から生成される場合、エージェントが変更したコードはドキュメントに自動的に反映されるはずです。しかし、多くのチームはドキュメントを別途管理しています。Agent Smithがエンドポイントを追加したり、応答スキーマを変更したりする場合、ドキュメントの更新はエージェントが実行するかどうか不明な別のタスクとなります。

自動生成されたドキュメントであっても、説明、例、使用上の注意には、AIエージェントが持ち合わせていない人間のコンテキストが必要です。エージェントはエンドポイントが何をするかをドキュメント化できます。しかし、それがなぜ存在するのか、誰が使用するのか、どのようなトレードオフがその設計につながったのかをドキュメント化することはできません。

レビュー疲労

コードの25%がAI生成である場合、コードレビューの25%はAIの出力をレビューすることになります。AI生成コードは構文的に一貫しており、適切に構造化されているため、一見「問題ない」ように見えます。しかし、問題なく見えることと、文脈において正しいことは同じではありません。

レビュアーは新たな課題に直面します。コードは読みやすいものの、アーキテクチャ上の決定、チームの慣習、またはレビュアーの頭の中にありながらエージェントのプロンプトにはない暗黙の要件と一致しない可能性があります。時間が経つにつれて、AI生成コードに対するレビュー疲労は、形式的な承認（rubber-stamping）につながる可能性があり、これがバグが出荷され始める時点となります。

エージェントに強いAPIワークフローを構築する方法

1. API契約を唯一の真実の情報源にする

デザインファーストのAPI開発は、エージェントによるずれに対する最も強力な防御策です。OpenAPI仕様が唯一の真実の情報源である場合、契約を破るいかなるコード変更も検出可能です。

デザインファーストではない場合：

コード変更 → テストパス → 出荷 → 契約破損

デザインファーストの場合：

仕様が契約を定義 → コードは仕様と一致する必要がある → 契約検証でずれを検出

ApidogのビジュアルAPIデザイナーを使用すると、コードを記述する前にエンドポイント、スキーマ、および応答フォーマットを定義できます。Agent Smith（または他のエージェント）がコードを生成する際、不完全な可能性のある既存のテストに対してではなく、仕様に対してコードを検証します。

2. ユニットテストではなく契約テストを使用する

ユニットテストは内部動作を検証します。契約テストはサービス間の合意を検証します。AIエージェントがAPIを変更する場合、契約テストはユニットテストが見逃す変更を捕捉します。

契約テストの例：

// This test fails if the response shape changes,
// even if the new shape is "valid"
describe("GET /api/users/:id contract", () => {
  it("returns expected schema", async () => {
    const response = await request(app).get("/api/users/123");

    expect(response.body).toMatchSchema({
      type: "object",
      required: ["id", "name", "email", "created_at"],
      properties: {
        id: { type: "string" },
        name: { type: "string" },
        email: { type: "string", format: "email" },
        created_at: { type: "string", format: "date-time" }
      },
      additionalProperties: false  // This catches unexpected fields
    });
  });
});

additionalProperties: false の行が重要です。これがないと、応答にフィールドを追加するエージェントはすべてのテストをパスしてしまいます。これがあると、いかなるスキーマ変更も明示的な契約更新を必要とします。

Apidogは、API仕様からの契約テストを自動化します。一度スキーマを定義すれば、Apidogは手動テストとCI/CD実行の両方で、すべての応答をそのスキーマに対して検証します。

3. 仕様検証に基づいてデプロイメントを制御する

CI/CDパイプラインにAPI仕様検証を追加します。コード（人間またはAI生成）がデプロイされる前に、それが宣言された契約と一致していることを確認します。

# CI/CD pipeline step
- name: Validate API contract
  run: |
    # Diff the current spec against the running implementation
    apidog run --test-scenario-id CONTRACT_TESTS
    
    # Fail if any contract violations found
    if [ $? -ne 0 ]; then
      echo "API contract violation detected. Review changes."
      exit 1
    fi

これにより、Agent Smithの契約違反変更が本番環境に到達する前に捕捉されます。

4. API変更には仕様更新を義務付ける

開発ルールを設定します。APIの動作を変更するすべてのPRには、対応するOpenAPI仕様の更新が含まれていなければなりません。AI生成のPRの場合、これはエージェントが仕様を更新するか、マージ前に人間がそれを行う必要があることを意味します。

Apidogでは、仕様の変更は自動的に以下に伝播します。

APIドキュメント
モックサーバーの応答
テストアサーション
クライアントSDK型

この連鎖により、契約変更時に成果物がずれることがなくなります。

5. 本番環境でのAPI動作を監視する

契約テストと仕様検証があっても、本番環境の監視は、プレ本番テストが見逃すものを捕捉します。以下を追跡します。

応答スキーマ違反：応答が宣言されたスキーマと一致しない場合にログを記録します。
新しいフィールドの出現：仕様にない応答フィールドについてアラートを発します。
エラー率の変化：AI生成エンドポイントでは、異なるエラー分布が見られる場合があります。
レイテンシの変化：エージェントが記述したコードは、異なるパフォーマンス特性を持つ場合があります。
トラフィックパターンの変化：新しいエンドポイントが予期しないトラフィックパターンを受ける場合があります。

6. APIレビューとコードレビューを分離する

標準的なコードレビューは「このコードは機能するか？」と問いかけます。APIレビューは「この変更は消費者に影響するか？」と問いかけます。

AI生成のAPI変更については、別途レビューチェックリストを作成します。

この変更は既存の消費者を壊さないか？
OpenAPI仕様は更新されているか？
後方互換性のない変更はバージョン管理されているか？
エラー応答は既存のエラーフォーマットと一貫しているか？
新しいエンドポイントは例付きでドキュメント化されているか？
ダウンストリームのチームには通知されたか？

軌跡：自律型コーディングの未来

今日のAgent Smithと明日のAgent Smith

25%のAgent Smithは出発点です。セルゲイ・ブリンは、2026年3月のセールス全体会議でAIエージェントを「大きな焦点」と呼びました。ツールが改善され、アクセス制限が緩和され、ワークフローが適応するにつれて、25%という数字は増加するでしょう。

他の企業も同様のシステムを構築しています。

Claude CodeのKAIROS（ソースコードでリーク）：GitHubのWebhookサブスクリプションとバックグラウンドワーカーを持つ常時稼働デーモン
GitHub Copilot Agent Mode：自律的なファイル編集を伴う複数ステップのコーディングタスク
AmazonのCodeWhisperer：自動補完からエージェント型ワークフローへと拡大中

業界のトレンドは明らかです。AIコーディングツールは「アシスタント」から「自律的な貢献者」へ、そして「バックグラウンドインフラ」へと移行しています。数年以内に、問題はAIがAPIコードを書くかどうかではなく、どれくらいの割合で書くかになるでしょう。

APIチームが今準備すべきこと

デザインファーストはもはや選択肢ではない。

エージェントがコードを記述する場合、API仕様が唯一安定した成果物となります。エージェントの採用が急務となる前に、今すぐそれを唯一の真実の情報源にしてください。

契約テストインフラに投資する。

コード作成者が暗黙の規約を理解していない場合、ユニットテストだけでは不十分です。契約テストはこれらの規約を明示的にエンコードします。

成果物を同期させるツールを選ぶ。

接続されていないツール（別々のAPIクライアント、別々のテストランナー、別々のモックサーバー、別々のドキュメントジェネレーター）は、エージェントが悪用する可能性のあるずれを生み出します。Apidogのような統合プラットフォームは、すべてを同期させます。

AI生成コードのレビュープロセスを構築する。

標準的なコードレビューではAPI契約違反を捕捉できません。API変更専用のチェックリストと自動検証を作成してください。

次のコード変更が人間の開発者、Agent Smith、または次に登場する自律型コーディングツールのいずれから来る場合でも一貫性を保つAPIワークフローを構築するために、Apidogを無料で試してみてください。

ボタン

よくある質問

Google Agent Smithとは何ですか？

Agent Smithは、GeminiモデルファミリーとAntigravityプラットフォームを基盤とするGoogleの社内AIコーディングエージェントです。バックグラウンドで非同期に動作し、エンジニアがタスクを割り当てると、Agent Smithはリアルタイムの人間とのインタラクションなしにコードの記述、テスト、反復を行います。2026年3月時点で、Googleの新しい本番コードの25%以上を生成しました。

Agent SmithはGoogle以外でも利用できますか？

いいえ。Agent SmithはGoogle従業員に限定された社内ツールです。Googleは一般公開の計画を発表していません。その技術はCopilot Agent ModeやClaude Codeに似ていますが、Googleの社内コードベースやドキュメントシステムにより深く統合されています。

AI生成コードはAPI契約を破る可能性がありますか？

可能性はあります。AIエージェントはテストをパスするコードを記述しますが、テストがAPI契約のすべての側面をカバーしているとは限りません。スキーマの変更、新しい応答フィールド、異なるエラーフォーマット、および動作の修正は、ダウンストリームの消費者を破壊しながらテストをすり抜ける可能性があります。契約テストとデザインファースト開発がこれを防ぎます。

APIチームはAgent Smithについて心配すべきですか？

Agent Smith自体については、Google社内ツールであるため心配する必要はありません。しかし、それが示すトレンドについては心配すべきです。同様の自律型コーディングツール（Copilot Agent Mode、KAIROSなど）は、いずれあなたのチームにも導入されるでしょう。デザインファースト開発、契約テスト、統合されたツールを使って今からAPIワークフローを準備することで、自律型エージェントを安全に導入できる立場に立つことができます。

AIエージェントが私のAPIを壊すのをどうすれば防げますか？

OpenAPI仕様を唯一の真実の情報源として、デザインファースト開発を使用します。予期しないスキーマ変更を捕捉するために、additionalProperties: false を含む契約テストを追加します。仕様検証に基づいてデプロイメントを制御します。仕様、テスト、モック、ドキュメントを自動的に同期させるApidogのような統合プラットフォームを使用します。

AI支援コードとAI生成コードの違いは何ですか？

AI支援コード（Copilotの提案、Claude Codeのセッション）は、人間の監督のもとリアルタイムで記述されます。開発者は各変更を確認し、承認します。AI生成コード（Agent Smith）は、リアルタイムの人間の関与なしに非同期で生成されます。開発者は、作業完了後にレビューを行います。この違いはレビューのダイナミクスを変え、未検出の契約違反のリスクを高めます。

AIエージェントはAPI開発者を置き換えますか？

いいえ。Agent Smithは依然として人間のタスク定義、コードレビュー、デプロイメント承認を必要とします。2026年3月のMITの調査では、AIが開発者の生産性を向上させる一方で、人間が提供する判断力、コンテキスト認識、アーキテクチャ思考を置き換えるものではないことが確認されました。役割はコード記述から、タスク定義、出力レビュー、システムの一貫性維持へと移行します。

重要なポイント

GoogleのAgent Smithは、非同期自律型操作により新しい本番コードの25%を生成しています。
これはAI支援コードからAI生成コードへの移行を示し、APIチームのレビューのダイナミクスを変えます。
自律型エージェントがエンドポイントやスキーマを変更する際の主なリスクは、API契約のずれです。
OpenAPI仕様を唯一の真実の情報源とするデザインファースト開発は、契約の破損を防ぎます。
厳格なスキーマ検証を伴う契約テストは、ユニットテストが見逃す変更を捕捉します。
Apidogのような統合プラットフォームは、仕様、テスト、モック、ドキュメントを同期させ、ずれを防ぎます。
自律型コーディングエージェントへの傾向は加速しています。今すぐAPIワークフローを準備してください。

25%のAgent Smithは始まりにすぎません。今日エージェントに強いAPIワークフローを構築する企業こそが、明日、自律型コーディングツールを安全に導入できる企業となるでしょう。