推論能力が上がるほど任せられる範囲は広がる。結果を受け取る側には、発見から修正までを確認できる記録が必要になる。
Google は2026年10月28日、Gemini 4 Carbon を発表した。重点はサイバー防御と長時間のエンジニアリング作業。大規模なコードベースや低レベルシステムの微妙な不具合を調べ、行き詰まれば別の経路を試し、修正につなげる仕事を想定している。
仕事を数日任せられるなら、最後の要約だけでは足りない。何を再現し、なぜ変更し、どの検証が通り、どこで止まったのか。次の担当者が確かめられる形で残す必要がある。
正式発表と、実際に使える範囲を分ける
Carbon は正式に発表されたモデルだ。Google はまず一部のサイバー防御担当者に提供し、Fairwind Program を通じて信頼できるパートナーへ拡大した後、開発者・企業・一般利用者向けの提供を進めるとしている。
導入を判断するときは、公表された能力と、自分のアカウントや環境で使える経路を別々に確認したい。必要な権限、実行環境、利用条件が揃わなければ、発表を読んだだけで既存システムを置き換えることはできない。
Google は Argon を発展させたモデルと位置づけている。ただし、短い文章整理と、複数リポジトリにまたがる障害調査では、失敗時の影響も検証方法も異なる。すべての軽作業を移行する理由にはならない。
三つのスコアは、別の段階を測っている
発表値は SEC-bench Pro が88.2%、ExploitGym が54.8%、CWE-bench が71.0%。それぞれ脆弱性の発見、悪用可能性の検証、修正に関係する。Google は外部ベンチマークを guardrails なしで評価したと説明している。
これらを一つの「安全性の正解率」にまとめることはできない。欠陥を見つけても、修正が正しいとは限らない。悪用可能性を調べる能力があっても、本番環境に対する試験が許可されたことにはならない。各段階に固有の環境、権限、証拠がいる。
安全なコード生成については、内部ベンチマークで Argon の2倍を超える成功率を示したと Google は報告する。これは提供元による結果だ。自社コードでの効果は、自社のテストとレビュー基準で判断する。内部の改善倍率と外部スコアも別の指標として扱いたい。
数日続く実行には途中の引き継ぎが要る
Google は社内で Carbon が数日間、複雑な問題を追い続けたとしている。失敗した試みから別案へ進めることに価値がある一方、中間状態の管理も重要になる。
修正を受け取る人に必要なのは四種類の記録だ。再現条件と観測された不具合。選んだ修正の根拠、除外した説明、残る仮説。実際に変えたファイルやインターフェース。そして、実行済みの検証結果と、本番でしか確かめられない項目である。
入力の版、権限、作業範囲が変わったら、該当する段階を見直す。最初の調査許可が、そのまま外部システムの更新や配備まで許すわけではない。読み取りから変更へ進む境界を明示したい。
これは推奨する受け入れ方法であり、特定顧客で実施済みの試験ではない。架空の教材を作るより、既存の作業記録から不足する証拠を探せる。
止まった場所も成果の一部
長い仕事では、局所的に妥当な変更が「完了」として渡されることがある。実際の出力が支える結果、限定環境でのみ通った検証、情報や権限不足で止まった作業を分けて示すべきだ。
Google は内部試験で、根拠のない主張や手法上の制約の扱いが改善したと説明する。それでも、組織の完了基準は維持する。モデルが限界を上手に説明することと、ツールが実際に結果を確認することは別だ。
コードのマージ、テスト成功、本番確認は三つの状態。調査や文書でも、資料を読んだ、草稿を作った、正式記録を更新した、は異なる。受け手が次にレビューするのか、補証するのか、実行するのかを判断できるようにする。
作業場所に受け入れ条件を置く
Buda を使って、資料・実行・人のレビューをつなぐフローを構築できる。担当 Agent に必要なファイルを用意し、許可する操作と成果物を指定して、結果を保存させる。Drive とメモリは継続作業を支える資料管理の参考になる。
「丁寧に確認」だけでなく、変更理由、実行済みの検証、未完了事項を要求する。レビュアーは実物を開いてから次の操作を許可する。Agent ワークスペースで資料と実行をまとめつつ、モデルの能力と操作の許可は別々に管理する。
導入前の二つの判断
今のモデルをすぐ置き換えるべきか
現在の構成で繰り返し失敗する、結果を確認できる仕事を一種類選ぶ。同じ入力と受け入れ条件で、正確性、見落とし、人の手戻り、総待ち時間を比べる。すでに要件を満たす軽作業まで発表直後に移す必要はない。
セキュリティ能力が高ければ本番を自動修正できるか
明確に許可された隔離環境から始める。再現可能な発見、根因説明、パッチ差分、回帰試験を求め、本番変更は既存のレビューと配備手順に従う。実行時間を決める前に、誰が何を許可できるかを決めたい。