「動きました」の次に、何を確認するか
たとえば、金曜のレビューです。同僚が画面を共有して、「写真を渡したら、レースゲームができました」と言います。机の本やコップが障害物になり、ブラウザですぐ遊べます。
見た目は、完成に近いです。聞きたい問いは、その先にあります。何をもって正しいゲームだとしたのか。写っていない面は、測ったのか。衝突の確認は、遊べる範囲なのか、測量としての精度なのか。
2026年10月13日、GoogleはGemini 4 Argon: Built to solve your hardest problemsを公開しました。コーディング、金融、法務、科学などの難しい作業を、長く進めるモデルです。この記事では、発表にある作り方を読んで、IT技術者の仕事がどの作業から移るかを整理します。
頼む単位が、関数から動くソフトウェアへ
少し前の使い方は、こうでした。売上のCSVを商品別に集計するPythonを書いてほしい、と頼む。返ってくるのはソースコードです。保存し、環境を整え、実行し、エラーを直すのは人の仕事でした。AIは、開発の一部を手伝う存在です。
今の頼み方は、もう少し広いです。「毎月の売上CSVを置くと、商品別の推移が出て、急に落ちた商品が分かるWebアプリにしてください」。言語、ライブラリ、データベースの種類は、指示の外です。エージェントは、機能の整理、構成、ライブラリの選定、画面とAPI、テスト、実行、修正まで進もうとします。
止まることもあります。権限、環境、データの癖。一見動いて、中身が違うこともあります。それでも、担当する単位はコードの断片から、開発タスクへ広がっています。
先に、出力の形を分けておきます。Gemini 4 ArgonのAPI出力はテキストです。動く3Dは、モデルがコードとツール呼び出しを書き、Blenderやブラウザ側が形と動きを作った結果です。
机の写真を、ブラウザのレースにする
公式ブログでは、本物の机の写真から、遊べるミニチュアのレースを作った例が出ています。開発エージェント環境のAntigravity上で、複数エージェントのループを回しています。机の上の物、部屋、コースはBlender MCP（Blenderを外部から操作する接続）でモデル化し、衝突も確認しています。テクスチャは画像生成のNano Bananaです。Three.js（ブラウザで3Dを描くライブラリ）上で物理と独自シェーダを結び、エンジン音はGemini Omni Flashで付けています。紹介ページはTurn photos of your desk into a 3D racing gameです。
人が同じものを作るなら、写真から物体を分け、机の上の位置を推定します。その位置をゲーム空間の形に置き、車の動き、衝突、カメラ、操作を実装します。画像、空間、ルール、物理、画面。別々の技術を、1つの成果物でつなぐ作業です。人が手順を1行ずつ指定しなくても、このつながりが出てくるようになっています。
ここで分けたいことがあります。遊べることと、測れたことは別です。 ブログが書いているのは、モデル化と衝突の確認までです。写っていない面の3次元形状を、測量として復元した話は、この事例の範囲外です。
形はPythonで作り、遊びはThree.jsで渡す
もう1つの例は、3Dのチェスです。Antigravity上のArgonは、Pythonスクリプトで手続き的に造形し、リグを組み、アニメーションを付け、PBR（物理ベースの質感）用の画像を事前に書き出しています。そのあと、Web向けにThree.js、画面の見た目を描くGLSL、破片の物理、1人用のAIへ結んでいます。ショーケースでは、ゴシック様式の大聖堂を舞台にしたウィザードチェスとして紹介されています（Gemini 4 Argon Builders Showcase）。
人が指定するのは、どんなゲームにするかと、Blender、Python、Three.jsのどれを組み合わせるかです。組み合わせの一部を、エージェントのループが担い始めています。
タスクを分けてサブエージェントに振る流れは、Claude CodeのDynamic Workflows：数百のサブエージェントで大規模開発を進める時代へで追っています。ここでは、その結果として人が何を残すかに絞ります。
50GBの計測データは、1回のプロンプトには入らない
チャコキャニオン（米国南西部の古代遺跡）の例は、種類の違う資料を1つの3Dにしています。公式ブログの表現では、約50GBの航空LiDAR、部屋の区画を表すGIS（地理情報システム）のベクトル、米国議会図書館のCAD、米国国立公園局（NPS）のアーカイブを合わせて、探索できる遺跡のモデルにしています。
LiDARは、レーザーなどで対象までの距離を測り、空間の形を点の集まりにする技術です。建築、測量、自動運転、文化財の記録で使われます。
数字の読み方は、分けた方がよいです。Argonの入出力を合わせた上限は1,048,576トークンです。約50GBの点群は、この枠には入りません。ブログの「synthesize（資料を合わせて再構成する）」から読めるのは、ファイルとツールをまたいで組み立てた、という側です。根拠は、公開されている上限です。パイプラインの内部手順は、ブログに書かれていません。
企業のシステムに置き換えると、こうです。設備のセンサー値、点検記録、故障報告、図面、手順書、現場写真は、別のシステムに分かれていることが多いです。設備の形を開くと、過去の故障、今のセンサー値、関連する手順が出る。異常が出たら、似た過去の事例を探す。この関連付けの一部は、自然言語の指示から作りやすくなります。
画面のあとで、元データの正しさを別に確認します。古い図面、誤った対応付け、権限のない写真が混ざれば、それらしい説明が危ない説明になります。品質、機密、誤った結合の確認は、生成の外に残ります。
同じ発表には、本番のコードを直した例もあります。Chromeでは、Chromiumの約4,000万行のうち、ブラウザ機能の約600万行の古いフォルダから、ページ処理の中核を切り離す改修を進めた、とあります。規模は数百ファイルです。数か月分の作業が数週間になった、というGoogleの報告です。ブログが書いているのは、改修にかかった期間です。
Agent Development Kit（ADK）では、スキルのルールブックと1段落の目標を渡し、一晩で動いた最適化がgoogle/adk-pythonに入った、とも書かれています。長いセッションでの、メモリ上のセッション準備時間を40%短縮し、コールドインポートを21%速くした、という数字です。どちらも、人が目標と制約を渡し、結果をリポジトリへ取り込んでいます。数字は、公開ブログに書かれたものです。
試作品に数日かけていた順番は、短くできます。その場で動くものを見ながら、本当に要る機能を探せます。その試作品で何を決めるかが、開発の仕事になります。
100万トークンは、100万トークンの正解ではない
発表では、Gemini APIで入出力を合わせた上限が100万トークン、と説明されています。仕様のページでは、次のように分かれています。
| 項目 | 上限 |
|---|---|
| 入力、思考、関数呼び出し、出力の共有枠 | 1,048,576トークン |
| 1ホップの出力（ストリーミング、またはGoogle GenAI SDK） | 65,536トークン |
| 1ホップの出力（非ストリーミングのREST） | 32,768トークン |
| long decodeを使ったときの出力 | 共有枠から、入力などを引いた残り |
コンテキストウィンドウは、同時に参照できる情報の枠です。最大出力トークン数は、応答として生成できる量です。Argonでは、この2つは同じ枠を共有します。入力、思考、出力で共有する1,048,576トークンです。Long contextには、入力トークンと max_output_tokens の合計が1,048,576を超えると、出力側が残りの枠まで自動で縮む、とあります。以前のGemini 3と2.5は、入力100万トークンと出力64Kトークンが別枠でした。
100万トークンは、継続のホップを足した合計の上限です。Long decodeでは、続きが必要なら finish_reason が CONTINUATION になり、continuation_token を付けて次のホップへ進みます。max_output_tokens は、全ホップの思考と出力の合計です。思考のレベルを高くすると、その分だけ本文に使える量が減ります。難しい問題では、1ホップが思考だけで終わり、本文が空のまま継続トークンだけ返ることがあります。これは想定された動きで、続きのホップで本文が出ます。
SDKの google-genai 2.30.1以上は、max_output_tokens を65,536より大きくすると、この継続を自動で行います。それより前のSDKでは、64Kトークンで止まります。非ストリーミングのRESTで、継続トークンなしに32,768を超えて指定すると、400エラーになります。
次のコードは、その設定の形です。APIキーは環境変数から読み、ソースには書きません。262,144は、全ホップの合計の例です。
from google import genai
from google.genai import types
# google-genai 2.30.1 以上。APIキーは環境変数 GEMINI_API_KEY。
client = genai.Client()
response = client.models.generate_content(
model="gemini-4-argon",
contents="受け入れ条件を、テストできる形で列挙してください。",
config=types.GenerateContentConfig(
# 全ホップの思考と出力の合計。1回の応答長ではない。
max_output_tokens=262_144,
thinking_config=types.ThinkingConfig(thinking_level="high"),
),
)
動く条件は、上記のSDK、課金の使えるAPIキー、モデルID gemini-4-argon です。長い出力は請求にも出ます。公開ブログの注記では、導入価格は2026年11月30日まで、入力100万トークンあたり2ドル、出力100万トークンあたり10ドルです。その後は4ドルと20ドルになります。キャッシュされた入力は95%引き、とあります。対象は、公開向けのArgonです。
出力が長いモデルは、リスト上の単価と、タスクあたりの費用がずれやすいです。この見方は、Claude Opus 5から読む、生成AI競争の次のステージ──性能競争から「コスト・信頼性・運用設計」へで整理しています。Argonで足しておくのは、単価が日付で変わる、という1点です。
枠が大きいことと、中身を矛盾なく扱えることも別です。長いチャットに情報を詰め込むほど答えが雑になりやすい問題は、長いチャットほど答えが雑になる——Context Rotを防ぐMemory・Projects・Skillsの使い分けで扱っています。上限が100万トークンでも、必要な資料を選んで渡す作業は残ります。
たとえば、顧客管理を作るとします。画面、テーブル、API、認証までは生成できるかもしれません。それでも、次はコードの長さでは決まりません。
同じ顧客が2件登録されたとき、どちらを正とするか。担当者が異動したあと、その顧客を誰が見られるか。削除した顧客の、過去の取引を残すか。保存期間は、どの規則に合わせるか。
これらは、判断基準を渡せば案を出せます。渡せないまま生成すると、それらしい実装が、組織の規則と違う実装になります。見るべきなのは、判断材料が入力に入っているか、出力を人が確かめられるか、です。
コードを読むために、基礎を残す
プログラミングを学ぶこと自体は、残ります。変わる可能性があるのは、学ぶ目的の中心です。
これまで中心にあったのは、変数、分岐、繰り返し、関数、データ、ネットワークを組み合わせて、自分でアプリケーションを動かすことでした。この知識は、そのまま使えます。すべての行を自分で打つ比重は、下がる可能性があります。
生成されたSQLが、次の形だったとします。
SELECT *
FROM orders
WHERE customer_id = 100;
構文としては通ります。orders が数千万行で、customer_id に使えるインデックスがなければ、遅くなります。この文を実行する人に、顧客ID 100の注文を見る権限があるかも別問題です。SELECT * は、返さなくてよい列まで持っていきます。
構文が正しいことと、システムとして適切であることは違います。この差を見るには、データベース、権限、インデックスの知識が要ります。データ構造、ネットワーク、OSも同様で、残すのは原因を推定できる範囲です。実装の経験がないまま、設計の判断だけを鋭くするのは難しいです。遅いクエリを自分で追った経験が、どこを疑うかを教えます。
委任しすぎると、説明できる範囲が狭くなる、という技能の話は、便利すぎるAIは、なぜ技術者の思考を弱くするのかに譲ります。ここでは、生成結果を疑うために基礎を残す、という1点だけ置きます。
仕様は、説明文から正しさの定義へ
AIが文章から実装まで進むと、仕様書は人への説明であると同時に、生成への入力になります。画面遷移や項目の説明に加えて、合否の基準も載せることになります。
「使いやすい勤怠にしてください」では、解釈が割れます。「従業員はスマートフォンから出退勤を記録する。管理者は月の勤務時間を見る。計算は就業規則に従い、修正の履歴を残す」まで書くと、実装の範囲は狭まります。それでも、例外、権限、締日の扱いに漏れは残ります。仕様を渡して作らせる使い方に加えて、矛盾と未決事項を先に出させる使い方もあります。
効きやすいのは、文章の要求と、自動で確かめられる条件を組にすることです。
「8時間を超えたら、就業規則どおりに残業を計算する」
この文には、8時間の数え方が複数あります。隣に、次の確認を置きます。
「9時から18時、休憩1時間なら、実働は8時間」
pytestで書くなら、条件は次の形です。worked_hours は未実装でも、先にテストだけ置けます。これは、何をもって正しいとするかをコードにした例です。勤怠システム一式は、別の仕事です。日をまたぐ勤務、有給の休憩、タイムゾーンは、この条件の外です。
def test_standard_day_is_eight_hours():
# 9:00-18:00、休憩60分。休憩は実働に含めない。
assert worked_hours(start="09:00", end="18:00", break_minutes=60) == 8
生成モデルに正しさの最終判断を任せない、という考え方は、「LLMに任せきり」が危ない理由——数学が示す限界と、設計で補う3つの原則でも整理しています。ここでは、その原則を仕様の書き方に接続します。何を作るかと、何をもって正しいとするかを、同じ文書に書きます。この2つがそろうほど、生成結果を確かめやすくなります。
確かめる速度が、生成の速度に追いつくか
ウォーターフォールは、要求、設計、実装、テストを段階で進めます。大規模で、変更の管理が厳しい開発に向きます。アジャイルは、小さい機能を短く出して、使う人の反応で直します。実装の時間が縮むと、この試行の周期も短くできます。2週間かかっていた試作品が、数時間になることはあり得ます。
縮みにくい工程もあります。業務の合意、セキュリティ審査、データの移行、使う人への説明です。ここを実装と同じ速度だと見積もると、計画が崩れます。
速度が上がると、別の問題も出ます。検証が薄いコードが、短い時間で溜まることです。並ぶのは、生成したものを確かめる速度です。
自動テスト、静的解析、依存ライブラリの脆弱性、APIの契約テスト、性能、権限、本番の監視。これらをCI/CDに載せて、変更のたびに同じ確認が走るようにします。エージェントが直したときは、変更の理由、実行したテスト、見つかった問題を残します。モデルの外側に制御を置く整理は、ハーネスエンジニアリングとは？——AIエージェントを「手綱」で導く設計思想にあります。
公式ブログは、抑制する動機がないコーディング評価でも、近道を試す割合がGemini 4 Argonで2%だった、と書いています。以前のGeminiより低い、という自己報告です。テストが落ちたとき、禁止されている手段で通そうとする試みも含みます。生成が上手なときほど、確認の仕組みを先に用意します。
作業の単位で、仕事を組み直す
「プログラマーは不要になる」は、粗い予測です。見る単位は、作業です。定型のCRUD、単純な画面、形式だけの変換は、自動化されやすいです。複雑な業務の整理、既存システムとの接続、性能の原因、権限の判断は、環境の制約を知らないと外れます。後者も、AIが下書きできるようにはなっています。
境界は、能力が上がるたびに動きます。自分の作業は、そのたびに組み直すことになります。同じモデルを使える人が増えます。差になりやすいのは、渡す情報の質、課題の切り方、結果を評価する力、現場の業務に合わせる力です。
広がり方は、3つあります。
一緒に作り、結果を読める
コード、テスト、リファクタリング、文書にAIを使います。指示に加えて、生成物への問いが要ります。なぜそのデータ構造なのか。処理量が10倍でも持つか。例外のとき、データの整合は残るか。この問いを出せることが、仕事になります。
AIを部品にしたシステムを設計する
社内文書を検索して答える仕組みでは、どの文書を対象にするか、権限をどう切るか、根拠をどう見せるか、誤った回答をどう見つけるかを設計します。APIを呼ぶ処理は、その一部です。外部の操作をさせるなら、できる操作を制限し、取り消せない処理は承認にします。従来の設計に、評価、監視、権限が足されます。データの収集、品質、アクセス制御が弱いと、モデルが賢くても結果はずれます。
何を作るかを、現場から決める
実装の費用が下がると、以前は試せなかった案の一部は、試作品にできます。そのとき前に出るのは、何を作るかです。
たとえば、利用者から「検索を足してほしい」と頼まれたとします。そのまま検索を足すこともできます。話を聞くと、分類が崩れていて、探す言葉が揃っていないだけかもしれません。その場合に効くのは、分類と名前の直しです。画面が早くできても、課題の切り方を誤ると、効果は小さいままです。
同じ問いは、社内の申請、設備の点検、顧客対応の重複入力でも起きます。技術と現場の両方を知っているほど、この切り分けはしやすくなります。
最初の1本は、毎月の手作業でよい
試し方の1つは、身近な繰り返し作業を題材に、小さいシステムを最後まで通すことです。基幹系の置き換えは、最初の題材にしなくてよいです。公開時点では、APIはAI Studioなどの有料枠、AntigravityはGoogle AI Ultra、Geminiアプリと検索のAI ModeはUltraとPro、という分け方です。詳細は発表ブログにあります。
題材は、毎月の集計や、複数の表を手でつなぐ作業が向きます。実現したいこと、入力、期待する出力、動かす環境を書きます。言語は最初から固定せず、案を2つ比べてもよいです。
動かす段階では、エラーをエージェントだけに返さず、原因を自分でも追います。確認では、正常データに加えて、欠け、異常値、想定外の入力、遅さ、権限を見ます。最後に、使う人に触ってもらい、楽になった点と使いにくい点を聞いて直します。
この一周で分かるのは、課題の切り方、設計、実装、検証、改善のどこで自分が判断したか、です。足りない知識は、その一周で分かります。
3年から5年、評価は解けた問題に寄る
今回の事例から、置ける方向はあります。
自然言語の指示で進められる作業は、今より増える可能性があります。試作品が速いと、初期に試す回数は増えます。実装が自動に寄るほど、要求が妥当か、品質を保証できるか、セキュリティと運用を回せるか、の比重が上がります。個別の技術に加えて、技術と業務を組み合わせる力が問われます。評価の軸は、どの問題がどれだけ軽くなったかへ寄ります。
日付まで入れた予定表は、まだ書けません。性能、費用、信頼性、法制度、社内の運用で、速度は変わります。試作品を短時間で出す能力と、基幹システムを安全に動かし続ける能力のあいだには、まだ大きな差があります。可能性は試し、本番に載せる条件は分けて見ます。
これまで多くの時間は、どう作るかに使ってきました。言語、フレームワーク、アルゴリズム。これらは残る判断です。実装の支援が増えると、次の問いに時間を使いやすくなります。なぜこのシステムが要るのか。誰の、どの問題を解くのか。どの状態なら成功と言えるのか。生成したものを、どう確かめ、どう安全に動かすのか。
目的の整理も、見落としていた問題の指摘も、AIに渡せます。どこまで任せてよいかを確かめながら、協働の仕組みを設計します。基礎の上に、指示の渡し方、結果の評価、運用の確認を足していきます。
これからの価値は、AIを含む技術で、適切な問題を確かめながら解けているかにあります。最初にやることは、毎月の手作業を1本選び、正しさの条件をテストに書いてから、エージェントに作らせてみることです。
作成日: 2026-10-18