Gemini 4 Carbonが掲げる難しい約束――初日を越えて役立つ仕事を続ける

難しいソフトウェアのバグは、整ったコーディング問題として現れるとは限りません。報告、断続的な失敗、原因から何層も離れた症状として現れます。役立つ作業には、履歴を読み、競合する説明を検証し、1時間前には有望に見えた修正案を捨てることも含まれます。

Googleは、 2026年10月28日にGemini 4 Carbonを発表 し、長期的なエンジニアリングとサイバーセキュリティ防御を重視すると説明しました。Google DeepMindによれば、社内チームは、大規模なコードベースの微妙なバグを含む複雑な仕事に、モデルが数日間取り組む様子を確認しています。これは社内での観察であり、すべての顧客の仕事が数日間うまく進むという約束ではありません。Googleの発表はアクセス範囲も明示しています。最初は選ばれたサイバー防御担当者に提供し、その後Fairwind経由の追加の信頼されたパートナーへ広げ、さらに広い提供を計画しています。

実用上の問いは、長く動くモデルが何を残すべきかです。本記事では、新モデルの位置付け、公開比較の読み方、何時間働いた後でもレビューできる仕事をエンジニアリングチームが準備する方法を解説します。

2013年のScrumbanタスクボードの例。継続的なプロジェクトの作業状態を可視化するイメージであり、Geminiの画面やモデルの出力ではありません。画像：Dr ian mitchell、CC BY-SA 3.0。余白を付けてサイズを調整。画像の出典 · ライセンスと画像に関する注記。公式製品の参考情報。

長く動く価値は、仕事の意味を保ててこそ生まれる

コーディングエージェントは、問題を明確にしないまま動き続けることもあります。元の不具合から離れながら、さらにファイルを探し、修正を試し、コマンドを実行できます。実行時間が長いほど、進展する機会も、誤った前提を積み重ねる機会も増えます。製品上の課題は、その活動を通じて仕事の目的を保つことです。

本稿では、長時間の仕事には持続する作業上の合意が必要だと考えます。問題、修復を立証する根拠、許可された範囲、人の判断を要する操作を定めたものです。仮説や実装が変わっても、この合意は残るべきです。そうしなければ、利用者が依頼したものより簡単な問題を解いて、もっともらしい結末に到達しかねません。

同期のバグを例に考えます。「保存できたように見える項目が、再読み込みすると消える」という報告です。有用な作業は、再現し、状態管理や永続化の問題を特定し、範囲を絞った修正を提案して、同じ利用者の操作で確認することです。再読み込みを一度も試さないテストの成功を添えた大規模なリファクタリングでは、有用性が下がります。

時間がたつほど、この区別は重要になります。数時間後の確認担当者に必要なのは、全コマンドの書き起こしではなく、最も強い根拠と残る不確実性の記録です。実行が止まったらどこから再開し、何をもって受け入れてよいかを同僚に伝えられる記録にします。

独自作成の作業図。継続的な作業では、探索中も元の受け入れ基準を保ち、経緯を追える修正を残すべきです。

Carbonの比較が示すのは、種類の異なる複数の仕事

2026年11月2日に確認したGoogle DeepMindのモデル比較ページは、CarbonとArgonを複数の評価で比較しています。例えば、 Terminal-Bench 4.0では65.2%対57.1% 、 FrontierSWE 2では61.2%対55.0% と報告しています。異なる名称と条件を持つベンチマークの公開結果であり、足し合わせて一つの製品成功率にするべきではありません。

開発チームは、自分たちの仕事に似た課題から始めるべきです。ターミナル操作、リポジトリの修復、ブラウザー上の作業では、エージェントに求めるものが異なります。一つの評価で優れていても、本番用リポジトリでは別のツール設定や追加の背景情報が必要かもしれません。ベンチマークは実験選びを助け、実験の成功は自社リポジトリの実際の動作で決まります。

この表は評価の枠組みであり、Googleの試験手法を言い換えたものではありません。広い能力の主張を、チームが答えられる問いに変えています。手元でのよい結果には、失敗や進められなかった段階も含め、モデルの得意な点と周辺ワークフローの改善点を理解できるようにします。

比較には安定した基準も必要です。モデル構成を比べる際は、リポジトリの版、ツール権限、依頼文、テスト環境をそろえます。一方には再現手順を与え、もう一方はゼロから発見するなら、完了時間の差からモデルの差だけを取り出せません。結果を解釈する前に条件を記録します。

サイバー防御には、発見から検証済みの修復までのつながりが必要

Googleの10月28日の発表は、Carbonについて SEC-bench Proで88.2% 、 ExploitGymで54.8% 、 CWE-benchで71.0% と報告し、これら外部ベンチマークの評価はガードレールなしで行ったと述べています。数値は、脆弱性の発見、検証、修正に関わる異なる課題を扱っています。ベンダー公表の結果の出典はGoogleの発表です。

防御担当者にとって有用な流れは、許可された対象と、確認可能な検出事項から始まります。合意した環境内で、検証によって関連するリスクを確かめます。修復では原因を解消し、正当な動作を維持する必要があります。一つのエージェントがすべてを手伝うとしても、段階ごとに必要な根拠は異なります。

社内ライブラリの確認を例にすると違いが分かります。チームは隔離したライブラリのコピーと、入力処理に関する明確な懸念を渡します。望む結果は、具体的な検出事項、テスト環境内に限定した再現、回帰テスト付きの修正です。資料内でリンクや認証情報を見つけたからといって、無関係なシステムへ作業範囲を広げるべきではありません。

二つ目の例は、既存報告の切り分けです。エージェントは報告をコードの経路と結び付け、実際の問題と誤った前提を区別するテストを検討できます。「修正不要」という有用な結論にも根拠が必要です。自信のある説明で報告を閉じるより、主張された経路が評価対象の版に当てはまらない理由を示す方が強い証拠になります。

最終的な責任は、そのシステムを担当する開発・セキュリティチームに残ります。提案された修正は、実際のサービス境界、展開手順、互換性要件に照らして確認します。隔離環境でのテスト成功は判断材料の一つであり、本番展開と監視は別の段階です。

モデルの安全性評価は、導入先での操作権限を定めない

Googleは、アラインメント、プロンプトインジェクションへの耐性、裏付けのない主張の削減が改善したと説明しています。曖昧さの中で作業を続けるモデルには関連性の高い領域です。運用上は、目立つ安全性の結果を全ツール接続の許可とみなさず、想定するワークフローで評価することが重要です。

長時間の仕事には、段階的な権限が役立ちます。リポジトリを読む、隔離した作業コピーを変更する、サービスを展開するのは異なる行為です。根拠を集め、レビュー可能な変更を準備するところまでは任せ、公開や本番への影響には別の承認を残せます。境界は依頼文に書くだけでなく、環境でも強制するべきです。

信頼できない資料も実務上の課題です。ソースファイル、課題の説明、取得したページには、依頼と衝突する指示が含まれる場合があります。適切なエージェントシステムは、作業の権限と、読み込む内容を区別するべきです。特に、誰も全操作を見ていない長い実行では、想定外の範囲変更を確認用の記録から把握できる必要があります。

認証情報にも同じ考え方が当てはまります。仕事に必要なアクセスだけを与え、誤操作の影響を限定できる環境を優先します。有用な試験では、背景が不足した際に質問し、進められない状態を正直に残すかも確認できます。止まるまでに変更できたファイル数と同じくらい大切な振る舞いです。

独自作成の権限図。実行時間が延びても、許可が自動で広がるわけではありません。段階ごとに担当者と完了条件が異なります。

段階的な提供では、多くのチームはまず準備から

公開時の説明では、選ばれたサイバー防御担当者、追加の信頼されたFairwindパートナーの順に提供し、一般の開発者、企業、消費者向けの提供は今後としています。モデル発表と広い製品提供は別の出来事です。Carbonを前提に納期を計画する前に、Googleの公式窓口で現在の利用経路を確認してください。2026年11月2日確認の10月28日発表。

アクセスのないチームも、有用な準備を進められます。難しいが範囲を限定できる仕事を選び、関連するリポジトリの版を保存し、現在難しさの原因となっている根拠を集めます。テストと確認担当者の期待を定義します。この準備は利用可能になった後にも使え、現在使えるツールとの比較も意味のあるものにします。

準備を、無人で完了できるという約束と取り違えないでください。よく定義した課題から、新モデルを動かす前に、テスト基盤の不足、責任の曖昧さ、不安定な再現手順が見つかることがあります。そうした条件を直せば、最終的にどのモデルが探索するかにかかわらず、開発プロセスを改善できます。

三つ目の例は、複数の層にまたがるアプリの不具合です。画面の状態は正しく見えても、サーバーには別の値が保存されている場合があります。依頼では、リクエスト、永続化、再読み込み後のUIを一連の流れで追い、限定した修正を求められます。継続的な推論の価値は、各層でコードを増やすことではなく、調査中も層同士のつながりを保つことにあります。

長い仕事の費用には、レビューと復旧も含まれる

公開されたトークン料金は、長時間の仕事の費用の一部です。ツール実行、繰り返すコンテキスト、テスト基盤、技術者のレビューも実費に関わります。読みやすく十分な裏付けのある修正を残す仕事は、安くても何時間もの不確実性を確認担当者に残す実行より、価値が高いかもしれません。

最初の試験では、可能ならエージェントシステムに支出と時間の上限を定めます。延長前にどの根拠が必要か決めます。停滞した仕事は、最後に確認した事実、最も有力な残る仮説、次のテストという有用な中間記録を残すべきです。そうすれば、時間を足せば進むはずだという期待ではなく、進展に基づいて継続を判断できます。

レビューの負担も測定できます。全セッションを再生せずに、同僚が原因を理解し、差分を見て、関連する確認を再現できるかを記録します。できなければ、権限を広げる前に成果物の形式を改善します。長い仕事は、長い確認文書へ不確実性を移すのではなく、チームの不確実性を減らすべきです。

終了条件の明確な修復から始める

1. 利用可能な経路と、実際に提供されるモデルを確認します。Carbonの発表された展開と、別のGeminiモデルへのアクセスを区別します。
2. 安定したリポジトリの版と再現可能な不具合がある、許可された隔離環境の課題を選びます。最初の評価を制御できない本番状態に依存させないようにします。
3. 受け入れ基準を、利用者に見える動作またはシステムの振る舞いで記します。維持すべき契約と、承認が必要な外部操作も明示します。
4. 必要なツールと最小限の権限を与えます。別の技術者が確認できる場所へ、変更、ログ、テスト成果物を保存します。
5. 確認済みの根拠、現在の仮説、進められない作業を区別する中間報告を求めます。範囲や予算を広げる前に、その記録を確認します。
6. 提案された修復を、元の不具合と影響範囲の回帰テストで評価します。無関係な変更や、明示されていない契約変更が差分にないか確認します。
7. 通常のリリース手順へ進められるかを、責任ある確認担当者が判断します。未完了の確認と必要な外部検証を明記します。

試験には、無関係なテストの失敗や、任意サービスの利用不能など、意図的に都合の悪い条件を一つ含めます。成果物がその制限と修復自体の根拠を区別するか観察します。検証の不足を正直に報告するモデルは、不確かな状態を何でも完了へ読み替えるモデルより組み込みやすくなります。

数日間働くエージェントは、判断への道のりを短くするべき

Carbonの発表は、行き詰まりを越えて取り組み、レビューする価値のある修復を残すという、コーディングAIへの新しい期待を示します。その粘り強さを役立つものにするのは周囲の開発システムです。明確な範囲、保存した根拠、限定した権限が、意味のある完了へつながる仕事を与えます。

本稿では、優れた評価は引き継ぎの品質を重視すると考えます。元の問いを保ったか。実際に何が失敗したかを突き止めたか。技術者が結果を検証し、次を決められるか。これらが長時間の実行を実際の開発成果へつなぎます。

長く働くAIへの期待は、難しい報告から根拠のある判断までの道のりを短くすることです。次の人が残されたものを信頼できるとき、作業に費やした時間に価値が生まれます。

出典

• Google：Gemini 4 Carbonの紹介、2026年10月28日。2026年11月2日確認。社内観察とベンチマーク結果はGoogleに帰属する説明です。
• Google DeepMind：Geminiモデル比較、2026年11月2日確認。ベンチマークの版と条件は、点数と切り離さずに扱う必要があります。

開発上の判断を、根拠となる資料と結び付けて残す

Telli.shは、利用を許可された資料と、開発上の判断の背景にあるメモを一緒に残すための選択肢です。ノート用ワークスペースを作成する。