原因の分からない不具合を、どこまで任せられるか
たとえば、10年以上動いている業務システムです。特定の条件のときだけ、データの更新が途中で止まります。当時の担当者はすでに替わっていて、設計書は一部しか残っていません。
これまでは、人が怪しい処理を選び、AIへ順に聞いていました。関数の説明、エラー文の意味、SQL、別の言語への書き換え。作業を分けるのは、人の側です。AIは、渡された1問に答える道具でした。
2026年10月28日、GoogleはIntroducing Gemini 4 Carbonを公開しました。2026年10月13日公開のGemini 4 Argon: Built to solve your hardest problemsから2週間後のモデルで、サイバーセキュリティと、時間のかかる作業に強い、とブログは説明しています。
この記事で確認したいのは、冒頭の更新漏れを、原因の調査からテストまで1件の依頼にできるかです。参考までに、Artificial Analysis Intelligence Index v5.0の点数は59、順位は1位です。
Argonでは、コードの一部を書いてもらう段階から、動くソフトウェアを作る段階へ移る話を、AIがソフトウェアを作る時代、IT技術者は何を作る人になるのかに書きました。質問への回答から、業務の完了までを1つの環境で進める話は、AIは「質問に答える道具」から「業務を完了するワークスペース」へです。この記事では、Carbonの発表をもとに、不具合の調査と修正をどこまでまとめて任せられるかを整理します。
社内の報告と、手元の環境は別である
更新漏れを1件で任せられるかの根拠は、社内の作業です。ブログには、チームが行き詰まりを越えて数日にわたってCarbonを動かした、とあります。対象は、大きなコードと、OSやランタイムに近い層にまたがる、見つけにくい不具合の原因特定と修正です。時間のかかる作業を、途中で止まらず続けるエージェント向けだと、ブログは説明しています。
これは、Google社内での観察です。 手元のリポジトリ、権限、テスト、古い業務ルールで、同じ時間だけ安定して進むかは、まだ分かっていません。
同じことを試すには、誰が使えるのかも見ます。提供先は、いま限定されています。発表では、米国政府による公開前の任意の検証プロセスに加わっている、とあります。その週から、一部のサイバー防御の担当者へ出し、Fairwind Programを通じて、信頼できるパートナーへ段階的に広げる、としています。開発者、企業、消費者へは、ガードレール（安全のための制限）を整えながら、できるだけ早く届ける、と書かれています。日付はありません。
外部のベンチマークは、ガードレールを外した条件の点数です。制限をかけた本番の成功率とは、別の数字です。
調査と修正を、1件の依頼にできるか
冒頭の更新漏れを、1件の依頼にすると、言葉はこうなります。「この条件で時々起きる、原因の分からない更新漏れを調べ、修正案を出してほしい」。関連するコードを探し、モジュールの関係をたどり、ログを見て、仮説を立て、直し、テストする。これまでの使い方では、このそれぞれを人が進め、AIは補助でした。
長い作業を続けられるなら、この一連を1件にまとめられる可能性はあります。根拠として公開されているのは、いまのところ社内の観察です。
発表の説明は、不具合の調査、脆弱性、Web開発の3つに分かれています。この3つについて、どこまでまとめて任せられそうかを見ます。
多くのコードを読むことと、次の調査を選ぶことは別
まず、不具合の調査です。手順を並べると、再現条件の整理、関連プログラムの探索、データの流れ、変更履歴、原因の候補、修正案、テスト結果の報告、になります。
この手順で要るのは、複数の情報を結び、仮説を立て、結果を見て次の調査を選ぶことです。数日続けた、という社内の観察は、この選び直しが途切れなかった、と読むこともできます。選び直しの中身は、公開されていません。
プログラムとして動くことと、業務として正しい結果は、別です。 在庫の端数をどう扱うか、締めのあとで更新してよいかは、コードの体裁からは決まりません。調査が速くなっても、その規則を知っている人がいないと、それらしい修正が誤った仕様になります。
調査時間を縮めても、業務の価値が同じ割合で増えるとは限りません。端数や締めの規則は、その例です。この整理の全体は、AIで生産性が上がったのに、なぜ価値は増えないのかにあります。
脆弱性の3つの点数は、別の作業を測っている
次は、脆弱性です。ブログは、防御の流れを3つに分けています。脆弱性の発見、悪用できるかの確認、根本原因の修正です。報告された結果は、次のとおりです。ガードレールを外した評価で、測っている作業が違います。3つのパーセントで優劣はつけません。
| 評価 | 報告された結果 | ブログが説明している内容 |
|---|---|---|
| SEC-bench Pro | 88.2% | 実在のソフトウェアに埋もれた脆弱性を見つける |
| ExploitGym | 54.8% | どれから直すかを決めるため、悪用できるかを確認する |
| CWE-bench（Collinear） | 71.0% | 確認した問題を、動く修正へ変える |
発見できても、悪用できるとは限りません。悪用の確認ができても、修正が正しいとは限りません。直す順番を決める材料と、直したあとの正しさは、別の確認です。
外部の3つとは別に、社内の比較もあります。安全なコードを生成する成功率が、Argonの2倍を超えた、という内部ベンチマークです。尺度は、上の表とは違います。
同じブログには、Chromeチームの報告もあります。質の高い修正の生成で、他のラボの大規模モデルより10倍を超える結果だった、としています。比較相手の名前は、書かれていません。何を質が高いとしたかの手順も、この記述には含まれていません。
発見や悪用の確認が強くなると、その能力は守る手順にも、攻撃の準備にも使われ得ます。発表では、提供は防御の担当者から始まっています。既知の脆弱性の説明から手順が組まれる速さは、「脆弱性が見つかってから攻撃まで847日」だった時代は終わったに書きました。Carbonの点数は、発見できたか、悪用できるかを確認できたか、修正できたか、に分けて見ます。
現場の作業に戻すと、診断ツールが警告を出したあと、原因と直し方は人が引き受けていました。今後は、変更差分を見て、認証や入力の検証への影響を調べ、必要なテストを提案する、という支援まで広がり得ます。セキュリティ確認を開発の最後にまとめる形から、日々の変更に寄せられる可能性です。
同時に、AIの修正が新しい脆弱性を作ることもあります。レビュー、権限、実行環境の分離、監査ログは、点数が上がるほど残します。1件ずつ見つける仕事に加えて、安全な状態を保つ仕組みを設計する仕事が増えます。
画面が動くことと、予約システムの完成は別
3つ目は、Web開発です。WebDev Arenaでは89 Elo上がり、1768で4位だった、とブログにあります。Eloは、対戦の結果から強さを表す点数です。
社内の備品予約を頼む場面で考えると、画面、入力、認証、保存までの試作品は、短く回せるようになる可能性があります。ボタンが動いたあとに、まだ残る問いがあります。同時に押されたとき、どうなるのか。通信が切れたとき、入力は残るのか。誤った操作は戻せるのか。個人情報の扱いは、仕様どおりか。見た目からは判断できません。
実装の手間が減るほど、「何をもって完成とするか」を先に書く必要が増えます。要望の背景を聞く進め方は、「何を作るか」が技術者の価値を決める——コードを書く人から、課題を形にする人へにあります。聞いた条件を、テストで見られる文にするのが、その次の作業です。
実装が速くなっても、人が見る場所は残る
完成条件を先に書く、という話は、人が確認する項目の変化でもあります。コードを人が中心に書いていたころ、確認の中心は、自分が書いたものが動くことでした。チームにレビューはあっても、実装の工程の中心は人です。
調査や修正をエージェントが進めると、確認する項目が増えます。次の表は、その例です。左の列の仕事がなくなるわけではなく、右の列の仕事が加わります。
| これまで人が中心だった仕事 | エージェントを使うときに残る仕事 |
|---|---|
| コードを最初から書く | 要件を定義し、生成結果を評価する |
| 不具合の原因を探す | 調査の範囲を決め、仮説を検証する |
| テストケースを書く | 品質の水準と、確かめる条件を定義する |
| 設計を文章にする | 制約と、判断の根拠を残す |
| 脆弱性を修正する | 修正の妥当性と、残るリスクを評価する |
| 新しい技術を調べる | 比較の条件を作り、採用を決める |
右の列が増えても、生成されたコードを読む基礎は残ります。変数、制御、データ構造、データベース、ネットワークです。読めないまま任せると、障害のときに経路を追えません。委任が技能を細くする仕組みは、便利すぎるAIは、なぜ技術者の思考を弱くするのかにあります。読む力を残すのは、経路を追うためです。
その前提のうえで、調査の初動が軽くなる場面はあります。少人数のチームで、足りない専門を補うときです。古いライブラリ、足りないテスト、複雑になった処理のように、後回しの作業に着手するときもそうです。どちらも、社内の観察が手元で再現できたときの話です。提案が適切かどうかの判断は、人が残します。
そのあとで起きやすいのが、レビューの詰まりです。生成だけが増え、複数の変更が同時に入ると、衝突と結合テストも増えます。見る項目は、リリースまでの時間、不具合、差分を人が説明できるか、復旧、費用です。
任せる前に、目的と制約を文章にする
見る場所が残るなら、渡す前の文章が作業になります。「処理を速くして」だけでは、結果を評価できません。速くなったあとで、計算結果が変わることもあります。メモリが増えることもあります。
たとえば、次まで書くと見られます。処理時間を30%以上短くする。処理結果は変えない。既存テストはすべて成功する。メモリの増加は10%以内。
変更してよいファイル、使ってよい外部サービス、個人情報の扱い、テストの条件、人の承認が要る操作、失敗したときの戻し方も、同じ文書に置きます。モデルの外で制約を置く整理は、ハーネスエンジニアリングとは？——AIエージェントを「手綱」で導く設計思想にあります。ここから先は、依頼の前に人が書く文です。
更新漏れの調査なら、曖昧な「改善して」との差が分かるメモは、次のようになります。
# 人がレビュー用に残すメモ。実行はしない。
goal: 特定の条件で在庫数が更新されない原因を特定し、修正案を出す
done_when:
- 再現条件が自動テストで固定されている
- 既存の在庫更新テストがすべて成功する
- 採用した修正と、棄却した仮説が残っている
do_not_change:
- 本番のデータベース
- 認証と権限の判定
- 仕様にない在庫の丸め
needs_human_approval:
- 外部サービスへの通信
- スキーマ変更の適用
このメモは、完成の条件と、触ってはいけない範囲を、人の言葉で固定する見本です。モデルが範囲を守った、という数字があっても、守る範囲は人が書いて初めて決まります。
ブログは、Carbonが範囲を超える行動を26%減らし、必要な作業の不足を29%減らした、と内部の比較で書いています。曖昧なときは、推測で進まず、資料を引いて食い違いを人に出す、ともあります。これらは訓練と社内評価の結果です。制約の文章がない仕事では、守るべき範囲は決まりません。
条件を書いても、確かめ方を同じモデルだけに任せると、別のずれが残ります。実装とテストが、同じ誤解を共有することがあるからです。正しさをモデルの自己申告に置かない原則は、「LLMに任せきり」が危ない理由——数学が示す限界と、設計で補う3つの原則です。テストが何を保証しているかは、人が読みます。
アーキテクチャ、テスト設計、セキュリティ設計、運用設計は、このモデルの前から要る技術です。実装を任せられる範囲が広がると、制約を書けるかどうかが、結果の差になります。
1件の費用は、トークン単価とは別に見る
調査を1件頼むと、モデルを呼ぶ回数は増えます。開発者向けに出すときの導入価格は、Argonと同じにする、とあります。入力100万トークンあたり2ドル、出力100万トークンあたり10ドルです。キャッシュされた入力は、入力単価の95%引きです。導入価格で計算すると、キャッシュ入力は100万トークンあたり0.1ドルになります。
導入期間のあとは、入力100万トークンあたり4ドル、出力100万トークンあたり20ドル、と脚注にあります。Carbonの導入期間がいつ終わるかは、このブログにありません。Argonの導入価格は2026年11月30日まで、とそのモデルの説明にあります。Carbonの終了日は、その日付とは別です。95%引きが期間のあとにも続くかは、本文だけでは分かりません。
キャッシュが効く条件、保持期間、実際の節約額も、発表文にはありません。同じコードを繰り返し読む調査では、入力を減らせる可能性があります。エージェントは、1件のあいだにモデルを何度も呼びます。やり直しが多いと、単価の安さは総額に残りません。条件を1回で満たすモデルなら、1件としては安く済むことがあります。
単価と、タスクを終える費用のずれは、Claude Opus 5から読む、生成AI競争の次のステージ──性能競争から「コスト・信頼性・運用設計」へに整理しています。Carbonで先に確認したいのは、導入期間の終わりが書かれていないことです。比べるときは、必要な品質に対して、どのモデルと手順の組み合わせが1件を安く終えるかを見ます。
自分のシステムに当てはめる前に、書くこと
ここまでの点数と社内の観察を、自分のシステムにそのまま当てるには早いです。一般提供の前で、点数の多くはGoogle自身の評価です。生産性が上がると決めるには、まだ材料が足りません。
古いコード、例外の多い業務ルール、足りない設計書、特殊な運用では、ベンチマークの高さがそのまま安定にはなりません。渡すツール、権限、実行時間、参照できる情報でも、結果は変わります。
この発表が示しているのは、質問に答えるだけでなく、調査、修正、検証までまとめて任せられる可能性がある、ということです。すべての開発現場で、すでにそうなった、と扱うには確認が足りません。
モデルが手元に来る前にできるのは、自分の調査を1件選び、先の在庫のメモと同じ形で、完成条件と変えてはいけない範囲を書くことです。本番は触らせず、差分はバージョン管理に残し、自動テストを通過したものだけを人が見ます。空いた時間をどの確認に使うかまで書いておくと、何を任せ、何を任せないかが先に決まります。
作成日: 2026-11-03