開発2部の内原です。 Goは静的型付けで事前コンパイルされる言語なので、WebAssembly(WASM)にコンパイルしておけば、JavaScriptのJust-In-Time(JIT)コンパイルより速度的に有利であるように思えます。 なんとなくGoをWASMにすればJSより速くなるくらいのふわっとした認識でいましたが、果たしてどのような実装でも速くなるのかそうでないのか、速くなるとしたらどれくらいの差が出るのか、という疑問を持ったので調べてみました。 そこで、いくつかのアルゴリズムで実際にベンチマークを取って検証してみましたが、アルゴリズムの特性によって結果が様々であることがわかりました。 事前準備 実行環境 MacOS 26.2 Go 1.25 Node.js v25 Chrome (144) Go WASM のビルドと関数公開 Go側の関数公開は以下のように js.FuncOf でラップしてグローバルに登録します。 import "syscall/js" func main() { js.Global().Set( "goAdd" , js.FuncOf( func (this js.Value, args []js.Value) any { n1 := args[ 0 ].Int() n2 := args[ 1 ].Int() return add(n) })) select {} } Go側では syscall/js パッケージを使って関数をグローバルに公開し、以下のコマンドでWASMバイナリをビルドします。 $ GOOS=js GOARCH=wasm go build -o main.wasm main.go $ ls -lh main.wasm -rwxr-xr-x@ 1 uchihara staff 2.1M Feb 11 16:00 main.wasm 生成されるWASMバイナリのサイズは約2MBです。Goランタイムが含まれるため、それなりのサイズになります。 JS側では WebAssembly.instantiateStreaming でWASMをロードし、 go.run(instance) を呼ぶと、上記で登録した関数がグローバルから呼び出せるようになります。 const go = new Go () ; const { instance } = await WebAssembly . instantiateStreaming ( fetch ( "main.wasm" ) , go . importObject ) ; go . run ( instance ) ; const r = goAdd ( 1 , 2 ) ; 計測方法 ブラウザ版とCLI版（Node.js）の両方で計測（ただし一部を除いて性能差はさほど出なかった） 各テストは複数回計測の平均を採用 ベンチマーク関数は以下です。 function bench ( fn , args , iters ) { const times = [] ; for ( let i = 0 ; i < iters ; i ++ ) { const start = performance . now () ; fn ( ... args ) ; const end = performance . now () ; times . push ( end - start ) ; } return times . reduce (( a , b ) => a + b , 0 ) / times . length ; } フィボナッチ関数 まずはシンプルなフィボナッチ数列の計算で比較しました。その際、関数呼び出しのオーバーヘッドが性能に影響を与える可能性があると考えたため、再帰版とループ版の2パターンで確認します。 Go側とJS側でほぼ同一のロジックを実装しています。 func goFibRecursive(n int ) int { if n <= 1 { return n } return goFibRecursive(n- 1 ) + goFibRecursive(n- 2 ) } func goFibIterative(n int ) int { if n <= 1 { return n } a, b := 0 , 1 for i := 2 ; i <= n; i++ { a, b = b, a+b } return b } function jsFibRecursive ( n ) { if ( n <= 1 ) return n ; return jsFibRecursive ( n - 1 ) + jsFibRecursive ( n - 2 ) ; } function jsFibIterative ( n ) { if ( n <= 1 ) return n ; let a = 0 , b = 1 ; for ( let i = 2 ; i <= n ; i ++ ) { [ a , b ] = [ b , a + b ] ; } return b ; } 再帰版 fibRecursive(40) 実装 実行時間 倍率 JavaScript 660ms 1.0x Go WASM 1,560ms 2.4x ループ版 fibIterative(10000000) 実装 実行時間 倍率 JavaScript 9ms 1.0x Go WASM 15ms 1.7x CLI版だとどちらのパターンでもJSのほうが高速という結果になりました。 ただブラウザ版だとGo WASMのほうが3倍ほど速くなっていました。JSエンジンの最適化による差分かもしれません。 原因分析 フィボナッチ計算は計算自体が軽量で、関数呼び出しのオーバーヘッドが支配的になります。JITコンパイラはこの種のシンプルな数値計算を最適化している可能性が考えられます。 どうやら「WASMにすれば速くなる」という単純な話でもなさそうです。 行列乗算 計算量をもう増やせば差が出るかもと考えたので、比較的計算量の大きい512x512の行列乗算で試してみました。 Go/JS双方でikjループ順を使い、同一の決定的データを生成して計算しています。 Go側は []float64 スライスを使い、JS側では Float64Array を使っています。 func goMatMul() { n := 512 a := make ([] float64 , n*n) b := make ([] float64 , n*n) for i := 0 ; i < n*n; i++ { a[i] = float64 (i% 97 ) * 0.01 b[i] = float64 (i% 89 ) * 0.01 } c := make ([] float64 , n*n) for i := 0 ; i < n; i++ { for k := 0 ; k < n; k++ { aik := a[i*n+k] for j := 0 ; j < n; j++ { c[i*n+j] += aik * b[k*n+j] } } } sum := 0.0 for _, v := range c { sum += v } return sum } function jsMatMul () { const n = 512 ; const a = new Float64Array ( n * n ) ; const b = new Float64Array ( n * n ) ; for ( let i = 0 ; i < n * n ; i ++ ) { a [ i ] = ( i % 97 ) * 0 . 01 ; b [ i ] = ( i % 89 ) * 0 . 01 ; } const c = new Float64Array ( n * n ) ; for ( let i = 0 ; i < n ; i ++ ) { for ( let k = 0 ; k < n ; k ++ ) { const aik = a [ i * n + k ] ; for ( let j = 0 ; j < n ; j ++ ) { c [ i * n + j ] += aik * b [ k * n + j ] ; } } } let sum = 0 ; for ( let i = 0 ; i < n * n ; i ++ ) sum += c [ i ] ; return sum ; } 実装 実行時間 倍率 JavaScript 190ms 1.0x Go WASM 208ms 1.1x 差は縮まりましたが、まだ若干JSが優勢です。 原因分析 JS側ではTypedArrayに対して最適化が行われている可能性があります。 またGo WASM側では以下箇所がオーバーヘッドになっている可能性があります。 WASMではSIMD命令を十分に活用できない？ Goのスライスにおけるbounds checkのコストがある？ 行列乗算は計算量が大きいためJS-WASM境界のオーバーヘッドは相対的に小さくなりますが、依然としてJSが有利でした。 SHA-256 計算量をもっと増やすと変化が出てくるかもと考えたので、SHA-256関数を利用することにします。 その際、JSによる純粋な実装よりネイティブAPIによる実装のほうが効率的である可能性が高いと考えたため、SubtleCrypto:digest()も比較対象に含めました。 ただ、SubtleCrypto:digest()は非同期関数であり、ベンチ時に同期的に呼び出しを行う必要がある点に注意が必要でした。 チェインハッシュ 小さなデータのハッシュ結果を次のハッシュの入力にする、という処理を10万回繰り返しました。 実装 実行時間 倍率 Go WASM 41ms 1.0x JS 純粋実装 114ms 2.8x SubtleCrypto 200ms 4.9x Go WASMがJS純粋実装の約2.8倍速く、最速という結果になりました。また、SubtleCryptoはさらに遅いという結果になりました。 Go WASMが速い理由 SHA-256はビット演算・整数演算が中心のアルゴリズムで、Goのコンパイル済みWASMコードが有利な立場だったと言えそうです。また、10万回のハッシュ計算を1回の関数呼び出しでWASM内で完結させている点で、呼び出しオーバーヘッドの影響がほぼなく、効率的だったと考えられます。 js.Global().Set( "goSHA256" , js.FuncOf( func (this js.Value, args []js.Value) any { data := [] byte (args[ 0 ].String()) iterations := args[ 1 ].Int() h := sha256.Sum256(data) for i := 1 ; i < iterations; i++ { h = sha256.Sum256(h[:]) } return hex.EncodeToString(h[:]) })) JS-WASM境界を跨ぐのは最初の呼び出しと結果の返却の1往復だけで、ループ全体がWASM内で実行されます。これにより crypto/sha256 標準ライブラリの実装がそのまま適用されます。 フィボナッチではJS側から関数を1回呼ぶという意味では同じでしたが、計算自体が軽いためランタイムオーバーヘッドが目立ちました。SHA-256チェインでは1回の呼び出しの中で重い計算を行うため、オーバーヘッドが相対的に無視できるようになります。 SubtleCryptoが遅い理由 ネイティブAPIの crypto.subtle.digest() が最も遅い結果となりました。 async function jsSHA256Subtle ( str , iterations ) { const encoder = new TextEncoder () ; let data = encoder . encode ( str ) ; data = new Uint8Array ( await crypto . subtle . digest ( "SHA-256" , data )) ; for ( let i = 1 ; i < iterations ; i ++ ) { data = new Uint8Array ( await crypto . subtle . digest ( "SHA-256" , data )) ; } return Array . from ( data , b => b . toString ( 16 ) . padStart ( 2 , "0" )) . join ( "" ) ; } SubtleCrypto はasync APIのみを提供しているため、10万回のチェインハッシュでは毎回Promise生成 → microtask enqueue → await復帰を繰り返します。ハッシュ計算自体よりも非同期ディスパッチのコストが支配的になっているようです。 巨大バッファハッシュ SubtleCryptoは大きなデータを一括処理するケースで優位であることが予想されます。64MBのバッファを1回だけハッシュする形式に変更して計測しました。 async function jsSHA256BulkSubtle ( size ) { const data = new Uint8Array ( size ) ; for ( let i = 0 ; i < size ; i ++ ) data [ i ] = i % 251 ; const hash = new Uint8Array ( await crypto . subtle . digest ( "SHA-256" , data )) ; return Array . from ( hash , b => b . toString ( 16 ) . padStart ( 2 , "0" )) . join ( "" ) ; } 実装 実行時間 倍率 SubtleCrypto 350ms 1.0x Go WASM 430ms 1.2x JS 純粋実装 980ms 2.8x 非同期呼び出しは1回だけなのでネイティブの速度がそのまま活かされ、SubtleCryptoが最速という結果になりました。 対して、GO WASM版にはなんらかのオーバーヘッドが存在しているのか、もしくはダイジェスト関数実装における性能差があるのかもしれません。 SubtleCryptoは大きなデータを一括処理する用途向きであり、小さなデータを繰り返しハッシュするような用途には向いていなさそう、ということがわかりました。 おまけ 計測中に興味深い現象を発見しました。Mac Chrome（144.0.7559.110）で、DevToolsを開いた状態では閉じた状態に比べてGo WASMの性能が低下するというものです。 テスト Go WASM（DevTools閉） Go WASM（DevTools開） 劣化率 再帰 fib(40) 1,550ms 3,150ms 2.0x 行列乗算 512x512 203ms 453ms 2.2x SHA-256 チェイン 41ms 136ms 3.3x SHA-256 64MB 428ms 1,461ms 3.4x 一方、JS側にはほとんど影響がありませんでした。 原因 DevToolsを開くと、Chromeが内部的にChrome DevTools Protocol(CDP)の Debugger.enable() を発行するようです。これによりWASMバイトコードにデバッグ用コード（ブレークポイント判定等）を挿入するため、WASMの実行速度が大幅に低下しますが、一方JSのJITコードには同等の影響があまり発生しないようです。 WASMのベンチマーク時はDevToolsを閉じた状態で行う、またはDevToolsを開いている場合にはDebuggerを無効化した状態で行う必要があることが分かりました。 まとめ Go WASMがJSより優位なのは、1回の関数呼び出しで大量の計算をWASM内で完結させるパターン（SHA-256チェインなど） 逆に、関数呼び出しが頻繁・計算が軽い場合は、JS JITが有利（フィボナッチなど） SubtleCryptoなどのasync APIは呼び出し回数に注意が必要。大バッファの一括処理なら効果的 WASMのベンチマーク時はDevToolsを閉じるorDebugger無効化。そうしないと2〜3倍の劣化が発生する 「GoをWASMにすればJSより速くなる」、というのは条件次第で真偽いずれもあり得ることが分かりました。 JS-WASM境界を跨ぐ回数を最小化し、WASM内でまとまった計算を完結させる設計にすることが重要そうです。 WASMの導入を検討する際は、対象のアルゴリズムがこのパターンに合致するかを事前に見極める必要があります。

本記事は「 Open weight models are here: more choice, more speed, less cost 」を翻訳したものです。 当初から、私たちは Kiro を最高の AI コーディング体験を提供できるように構築してきました。それは、現在の最先端コーディングモデルを搭載し、高品質な出力を中心にすべてを構築することを意味していました。6 ヶ月前、私たちは Auto を導入しました。これは、フロンティアモデルと特化型モデルを組み合わせ、インテント検出、キャッシング、その他の最適化技術を重ねることで、パフォーマンス、効率性、出力品質に優れたバランスを提供するエージェントモードです。本日、Kiro にオープンウェイトモデルを追加し、IDE と CLI の両方で利用可能になりました。 速度、品質、コスト効率の優れた組み合わせ 私たちはオープンウェイト分野を注意深く見守ってきましたが、その進歩は目覚ましいものがあります。1 年前であればプロプライエタリなオプションに大きく遅れをとっていたであろうモデルが、今では多くの開発タスクにおいて真に競争力のある結果を提供しています。高速で、コスト効率が良く、そして改善を続けています。多くの方々がこれらのモデルを独自に試し、直接サポートするよう私たちに要望を寄せてくださいました。その声をお聞きしました。 オープンウェイトモデルは、作業方法においてより多くの選択肢を提供します。すべてのタスクが最も重いモデルを必要とするわけではありません。クイックイテレーション、ボイラープレート生成、単純なリファクタリングには、生の推論能力よりも速度と低コストが必要です。他のタスクは、強力なエージェント機能や特化した言語サポートを必要とします。さまざまなモデルを持つことで、仕事に合わせてツールを選択できます。 モデル 本日から利用可能になるモデルと、それぞれが優れている分野をご紹介します。 DeepSeek v3.2 (0.25x クレジット) — スパース Mixture-of-Experts アーキテクチャに基づいて構築された DeepSeek v3.2 は、タスクごとに必要なパラメータのみをアクティブ化します。エマルチステップのツール呼び出し、長いセッション全体での状態維持、複雑な推論チェーンなど、エージェントワークフローに優れています。初期コード生成には優れていますが、複雑なデバッグやコードレビューの品質には課題がある場合があります。エージェントを構築している場合や、複雑なデバッグセッションに取り組んでいる場合は、これが強力な選択肢です。 MiniMax 2.1 (0.15x クレジット) — このモデルは多言語プログラミングで際立っています。Rust、Java、Go、C++、Kotlin、TypeScript、JavaScript などで優れた結果を提供します。また、Web、Android、iOS の UI 生成機能も特に優れています。開発者は、フロンティアモデルと比較して複雑なリファクタリングタスクに苦労する可能性があることに気づいています。チームが複数の言語で作業している場合や、フロントエンド開発が多い場合は、MiniMax 2.1 を試す価値があります。 Qwen3 Coder Next (0.05x クレジット) — トークンあたりわずか 3B パラメータをアクティブ化する 80B スパース MoE モデルである Qwen3 Coder Next は、コーディングエージェント向けに特別に構築されています。SWE-Bench Verified で 70% 以上のスコアを獲得し、256K コンテキストをサポートし、エラー検出、リカバリ、ツール呼び出しにおいて強力な機能を持っています。コミュニティは、より一貫した結果を得るために慎重な設定が必要な互換性と統合の課題をいくつか指摘しています。長いエージェントコーディングセッションを確実に処理する効率的なモデルが必要な場合、特に CLI では、Qwen3 を試してみてください。 IDE と CLI で試してみてください すべてのモデルは、 IDE モデルセレクター と Kiro CLI で実験的サポートとして現在利用可能で、Google、GitHub、AWS BuilderID でログインする無料ユーザーと有料ユーザーの両方が利用できます。推論は AWS US East (N. Virginia) リージョンで実行されます。モデルを切り替えたり、Auto と組み合わせたり、特定のプロジェクトタイプのデフォルトを設定したりできます。いつものように、実験して これらがどのように機能しているかお知らせください 。どのモデルが共感を呼び、どのようなギャップが残っているかに細心の注意を払っています。次にサポートしてほしいモデルがある場合は、 お知らせください 。

G-gen の三浦です。当記事では Google Antigravity を使用し、バイブコーディングで目標管理アプリを開発する手順と、Browser Agent によるデバッグの流れを紹介します。 概要 Google Antigravity とは リリースステージ 使用可能なモデル データの保護 検証手順 検証 インストール 初期設定 日本語化とルール設定 自然言語による開発 Browser Agent によるデバッグ 概要 Google Antigravity とは Google Antigravity は、AI を使用して開発作業ができる IDE（統合開発環境）です。Google Antigravity を使うことで、自然言語でやりたいことを伝えて AI がコードの生成や修正を進める開発スタイルである バイブコーディング （vibe coding）を実現できます。 自然言語を使ってチャットで Google Antigravity に作業を依頼すると、AI エージェントがエディタ、ターミナル、ブラウザを使って、実装や修正を段階的に実行します。 参考 : Google Antigravity 参考 : vibe コーディングとは Google Antigravity の主な特徴は以下のとおりです。 特徴 説明 AI-powered IDE エディタ内で AI と対話しながら、作成・修正・調査を一連の流れで実行 Asynchronous Agents 複数の作業を同時に依頼でき、複数タスクを並行して実行可 Agent Manager エージェントとの会話、進捗、成果物を1つの画面でまとめて管理 Multi-window 編集、管理、ブラウザ確認を分けて表示して効率的に並行作業 Browser Agent エージェントがブラウザを操作し、画面確認や情報収集を行う リリースステージ Google Antigravity は、2026年2月現在、 パブリックプレビュー です。当記事で解説する内容は一般提供（GA）の際に変更される可能性があることをあらかじめご了承ください。プレビュー版のサービスや機能を使うに当たっての注意点は、以下の記事も参考にしてください。 blog.g-gen.co.jp 使用可能なモデル Google Antigravity で使用するバックエンドの AI モデルとしては、Google が提供する Gemini シリーズに加えて、Anthropic の Claude など他社モデルも使用可能です。 2026年2月現在、Google Antigravity では以下の生成 AI モデルを選択できます。 提供元 モデル Google Gemini 3 Pro（high） Google Gemini 3 Pro（low） Google Gemini 3 Flash Anthropic Claude Sonnet 4.5 Anthropic Claude Sonnet 4.5（thinking） Anthropic Claude Opus 4.5（thinking） OpenAI GPT-OSS 参考 : Models データの保護 Google Antigravity は Google 製品であり、以下のような規約が適用されます。 Google Terms of Service Google Cloud - Service Specific Terms Google Workspace AI Ultra for Business で認証する場合に適用 Google Antigravity Additional Terms of Service Google Privacy Policy Generative AI Additional Terms of Service Google Antigravity 自体は無償で利用できますが、その場合、Google Antigravity Additional Terms of Service に記載のとおり、ユーザーデータやメタデータ、AI とのやりとりなどが記録され、保存されます。また、それらの情報はサービス改善に使用される可能性があります。ただし、Google Workspace AI Ultra for Business サブスクリプションを使用して認証する場合は、「当社はお客様のプロンプト、コンテンツ、またはモデル応答を収集しません。」とされています。 上記のような記載があるものの、Google Antigravity の企業による利用に際して、データがモデルのトレーニングに使用されないためにはどうすればよいか、という公式のガイダンスは、2026年2月現在、Google から発表されていません。 2026年2月現在、Google Antigravity のリリースステージがパブリックプレビュー段階であることからも、企業が当サービスを使うにあたりどのようにすべきかは明確になっていません。なお公式料金ページには、 Organization plan が近日中に発表されることが示唆されており、このプランは Google Cloud と連携することでデータの保護を提供するような内容となることが想定されます。 参考 : Choose the perfect plan for your journey 検証手順 検証手順は以下のとおりです。インストールとアプリ開発に加え、意図的にエラーが発生する状況を作り、Browser Agent で原因特定から修正までできるか確認します。 項番 内容 説明 1 インストールと初期設定 インストール後、初回起動〜サインインまでを実施し、エージェントの実行ポリシー（コマンド実行や変更適用のレビュー要否など）を設定します。 2 日本語化とルール設定 画面表示を日本語化し、「回答・計画は日本語で実施する」などのルールを設定します。 3 自然言語によるアプリ作成 チャットに要望を入力し、計画の提示 → レビュー → 実装 → 起動確認までを行います。 4 Browser Agent によるデバッグ検証 わざと不具合を入れ、Browser Agent（ブラウザ操作）でエラー画面を確認し、原因特定〜修正までできるかを確認します。 本検証時の端末と Antigravity のバージョンは以下のとおりです。 OS : Windows 11 Pro 実行環境 : WSL2（Ubuntu） Antigravity : 1.13.3 検証 インストール 公式サイトから、利用する OS に合わせたインストーラーをダウンロードして実行します。対応 OS と要件の詳細は公式ドキュメントをご確認ください。 対応 OS macOS Windows Linux 参考 : Download Google Antigravity 使用許諾契約書を確認して問題がない場合は「同意する」を選択し、「次へ」を選択します。 使用許諾契約書の同意 インストール先を指定し、「次へ」を選択します。 インストール先の指定 ショートカットの作成場所を指定し、「次へ」を選択します。 ショートカットの指定 その他で必要な項目があれば選択し、「次へ」を選択します。 追加タスクの選択 内容を確認し、「インストール」を選択します。 インストールの選択 インストールが完了したので、「完了」を選択します。 完了を選択 初期設定 Antigravity を起動し、「Next」を選択します。 起動と Next の選択 Visual Studio Code （以下、 VS Code ）を使用している場合、設定をインポートできます。不要な場合は「Start fresh」を選択します。 VS Code 設定をインポートするかの選択 次に IDE のテーマ（配色などの見た目）を選択し、「Next」を選択します。 テーマの選択 Antigravity のエージェントをどのように動かすかを選択します。選択したモードに応じて、エージェントの動きが変わります。本検証では Review-driven development を選択します。 エージェントの設定 利用モード（左側）の違い モード 特徴 Secure Mode すべての操作を 都度確認 してから実行します。加えて、より厳格な保護設定が適用されます（詳細は公式ドキュメント参照）。 Review-driven development（推奨） 要所で 人間の確認を挟みながら 作業を実行します。 Agent-driven development エージェントが 自律的に反復 して作業を実行します（確認なしで進む場合があります）。 Custom configuration 実行ポリシー（例 : コマンド実行やレビュー要否）を 細かく設定 できます。 実行ポリシー（右側）の項目 項目 制御項目 選択肢 影響 Terminal execution policy ターミナル（コマンド）実行の扱い Always Proceed / Request Review コマンド 自動実行するか 、 都度確認するか を制御します。 Review policy 変更の適用・進行時の人間の確認の要否 Always Proceed / Agent Decides / Request Review 変更を 即適用するか 、 都度確認するか 、 状況に応じて自動判断するか を制御します。 JavaScript execution policy ブラウザ等での JS 実行 Always Proceed / Request Review / Disabled JavaScript を 自動実行するか 、 都度確認するか 、 無効化するか（Disabled） を制御します。 参考 : Secure Mode 参考 : Agent Modes / Settings エディタの初期設定を行い、「Next」を選択します。 Keybindings（キー割り当て） ：通常は Normal を選択します。 Vim 操作に慣れている場合は Vim を選択します。 Extensions（拡張機能） ：Python や Go などの言語拡張機能をインストールするかを選択します。 エディタの設定 「Sign in with Google」を選択し、Google アカウントで認証を実施します。 Google 認証の実施 認証が完了すると、以下画面に切り替わります。注意事項の確認と必要に応じてチェックボックスを有効化します。チェックボックスを有効化した場合、利用状況データの送信を許可することを指します。 利用規約の確認 初期設定は以上です。これらの設定は後から変更できます。 エディタの表示 日本語化とルール設定 左サイドバーの「Extensions」を選択し、 日本語 と入力して表示された Japanese Language Pack for Visual Studio Code の「Install」を選択します。 画面の日本語化 左下にポップアップが表示されるので、「Change Language and Restart」を選択します。 Antigravity の再起動 日本語表記になっていることを確認し、右上の三点リーダーから「Customizations」を選択します。 Customizations を選択 Rules タブで「Global」を選択し、以下を入力して保存します。Global ルールは全体の共通仕様です。 回答及び計画などの各種ドキュメントはすべて日本語にすること Rules の設定 参考 : Rules 自然言語による開発 右上の「Open Agent Manager」を選択します。 Open Agent Manager を選択 「Open Workspace」 > 「Open New Workspace」 を選択し、作業用フォルダ（ Workspace ）を開きます。 Open Workspace を選択 参考 : Workspaces 作業用のフォルダを選択します。 フォルダの選択 「Next」を選択します。 Next を選択 会話画面が表示されます。モデル（ Gemini 3 など）の選択に加え、会話モードとして以下 2 つを選択できます。 モード 説明 Planning 実行前に計画（手順）を提示してから進めるモードです。調査や設計、複雑な作業を慎重に進めたいケースに適しています。 Fast 計画より実行を優先して、直接タスクを進めるモードです。軽い修正や試行をすぐに動かして確認したいケースに適しています。 モードの選択 モデルの選択 本検証時は以下の設定で、以下プロンプトを入力し、Enter キーを押下します。 モード : Planning モデル : Gemini 3 Pro（high） 社員の目標を管理するシステムを作りたい プロンプトの入力 エージェントから実装計画の確認依頼が来たので、内容を確認します。 実装計画の確認1 実装計画の確認2 実装計画の確認3 計画が問題ない場合、「Review」を選択してコメントを入力し、「Submit」を選択します。 計画の承認 エージェントから、 Next.js のプロジェクト作成コマンドの実行確認依頼が届きます。内容を確認して「Accept」を選択します。 エージェントによるコマンド実行の承認 エージェントから実装（ダッシュボードと社員一覧画面）の完了連絡が届いたら、コマンドを実行して確認します。 エージェントからの動作確認依頼 コマンドの実行 表示された URL にアクセスし、画面が表示されることを確認します。 アプリの表示確認1 アプリの表示確認2 Browser Agent によるデバッグ コードを意図的に改修し、アクセス時にエラーが出るようにします。 エラーが出るように改修 エージェントに対し、エラー内容をブラウザで確認するよう指示します。エージェントから Browser Agent を使用したデバッグの実行許可を求められるため、「Setup」を選択します。 エージェントによる Browser Agent のセットアップ確認 参考 : Browser Agent ブラウザが起動し、Antigravity 用の拡張機能のインストールが求められるため、確認してインストールを実施します。 拡張機能のインストール1 拡張機能のインストール2 拡張機能のインストール3 インストールすると、Antigravity によりエラーページへのアクセスとデバッグ情報の収集が開始されます。 エージェントによるデバッグ情報の収集 エージェントから修正完了連絡が来たので、再度アクセスしてエラーが表示されずに画面が表示されていることを確認します。 エージェントからの修正完了連絡 アクセスの確認 三浦 健斗 (記事一覧) クラウドソリューション部 2023年10月よりG-genにジョイン。元オンプレ中心のネットワークエンジニア。 ネットワーク・セキュリティ・唐揚げ・辛いものが好き。 Google Cloud Partner All Certification Holders 2025 / Google Cloud Partner Top Engineer 2026