Build With Google Day 1 / Day 2 2026を「イベント実行基盤」として読む――Antigravityの設定とAgent Skillsに見る、大規模AIハンズオン設計

はじめに――もし明日、多数の参加者へAI開発環境を配るなら

少し状況を想像してみてください。

あなたは、多数の参加者が集まるAIエージェント開発イベントの運営を任されました。参加者が持ち込むPCは、MacもWindowsもあります。会社支給端末にはProxy、DLP、Endpoint Securityが入り、PythonやNode.jsのバージョンも揃っていません。Google Cloudへログイン済みの人もいれば、普段のGoogleアカウントと演習用アカウントを混同する人もいるでしょう。

一方、イベントには時間制限があります。全員に環境構築から始めてもらえば、それだけで半日が終わりかねません。しかし、依存関係や権限を強く固定しすぎると、AIエージェントを自分で動かす面白さが失われます。

ここで必要なのは、単に「性能のよいモデルを用意すること」ではありません。

• 端末差をどこで吸収するか
• どこまでを全員共通にし、どこからを教材固有にするか
• AIへ大量の手順をどう渡すか
• 自動実行の速度と、安全性をどう両立するか
• AIの「できました」を、何で確かめるか
• 途中で壊れた参加者を、どう学習ルートへ戻すか

これらを一つのシステムとして設計する必要があります。

Build With Google 2026のDay 1 / Day 2で使われたAntigravity環境とAgent Skillsを調べると、この難題に対する一つの答えが見えてきました。

表面では、参加者が自然言語で自由に依頼します。しかし舞台裏では、環境、権限、手順、参照資料、期待結果、復旧経路がかなり細かく構造化されています。

本記事の主題は、この設計を次の一文として読み解くことです。

Vibe-like frontend, engineered backstage

参加者には探索の自由を感じさせながら、その自由が事故や迷子にならないよう、裏側を工学的に設計する。

この記事で分かること

この記事では、個々のラボ手順をもう一度なぞるのではなく、一段上の設計を扱います。

1. AntigravityのGlobal設定とProject設定を、どのように使い分けていたか
2. Skillが単なるプロンプト集ではなく、教材・手順・制約・検証を配る単位になっていた理由
3. Day 1 Lab 1 / Lab 2、Day 2 Platform / App / Businessで、Skillの役割がどう変化したか
4. 高い自動実行性を安全に成立させるため、外側にどのような構造が必要か
5. 同じ考え方を企業のAIエージェント基盤へ持ち込む際、何を管理すべきか

なお、本記事では事実の種類を混ぜないようにします。

• 観測：ガイド、設定画面、Skillの定義、実行結果から実際に確認できたこと
• 公式仕様：Googleの公開ドキュメントに記載されていること
• 分析：観測と公式仕様から導いた設計上の解釈

イベント環境の内部実装や、個々のファイルの執筆者を推測で断定するものではありません。

1. 最初の問題はAIではなく、参加者の端末差である

多数の参加者へ同じ演習を提供するとき、最も早く表面化するのはモデル品質より環境差です。

ローカルPCへ直接すべてを導入する方式では、次の差が演習へ流れ込みます。

今回のイベントでは、ブラウザから利用する一時的なリモート環境へ、実行責務の多くを寄せていました。手元のPCは主として表示と入力を担当し、OS、SDK、CLI、クラウド接続、教材ファイルはラボ側へ置かれます。

ここで大切なのは、「全ラボが完全に同一のVMだった」という意味ではないことです。実際に確認できた環境では、共通のUbuntu系デスクトップを使いつつ、agy、agents-cli、Google Cloud SDKなどのバージョンにはラボごとの差がありました。

したがって、設計は一枚の巨大なGolden Imageというより、次の形に近いと考えられます。

共通ベース
  ├─ OS・Desktop・Browser
  ├─ Antigravityの基本機能
  └─ 一時アカウントへ接続する導線

教材別レイヤー
  ├─ 必要なCLI / SDKの版
  ├─ Project-local Skill
  ├─ Starter code / sample data
  └─ 期待する実行結果

この分割には理由があります。すべてを一枚のイメージへ統合すると、あるトラックの更新が別のトラックを壊しやすくなります。反対に、完全に別々に作れば運用コストが膨らみます。「共通ベース＋教材別の固定レイヤー」は、再利用性と再現性の折衷です。

ただし、ここには新しい運用課題も生まれます。ラボごとに版が違うなら、どの教材がどの実行環境を前提にするかを契約として残さなければなりません。再現性とは、単に同じコマンドを打つことではなく、同じ入力、依存関係、実行主体、権限、モデル、状態を揃えることだからです。

ここまでの振り返り

ここまでの話は「VMを使えば解決」という単純なものではありません。

• 手元端末の差を演習の中心から外す
• 共通部分と教材固有部分を分ける
• 教材と実行環境の組み合わせを版として管理する
• 失敗時には環境を再割当し、学習ルートへ戻せるようにする

この土台の上に、Antigravityの設定とSkillが載ります。

2. Antigravityの設定を「便利機能」ではなく制御面として読む

Antigravityの設定画面には、Queued Messages、Security Preset、Artifact Review Policy、File Access、Network Access、Terminal Commands、Commands Outside Sandbox、MCP Toolsなどが並びます。

これをUI項目の一覧として覚えると、本質を見失います。重要なのは、各設定がどの問いに答えるかです。

Globalは共通方針、Projectは仕事固有の差分

確認できたDay 1のProjectとDay 2 PlatformのProjectでは、Security PresetとArtifact Review PolicyがGlobal設定を継承していました。一方、Project側には対象Folder、Local Permission、MCP Toolsなどを局所化する面があります。

これは企業のPolicy設計とよく似ています。

組織・利用者共通のBaseline
        ↓ 継承
Project固有のFolder / Permission / Tool
        ↓
Project内でだけ利用できるSkillと参照資料

すべてをGlobalへ置けば管理は簡単に見えます。しかし、無関係なProjectへToolや手順が見えるため、誤選択の面積と影響範囲が広がります。反対に、共通設定を各Projectへコピーすれば、少しずつ内容がずれるConfiguration Driftが起きます。

そのため、共通BaselineをGlobalへ置き、業務固有の知識と権限をProjectへ閉じ込める設計が自然です。

観測された設定値

次の表は、確認時点の状態です。Day 1環境は演習後であり、配布直後の初期値と同じだったとは断定しません。

なぜTurbo ModeとAlways Proceedなのか

Turbo ModeとAlways Proceedだけを見ると、「承認を減らして、とにかく自動実行させた」と見えます。イベント体験としては、その理解で大きく外れていません。短い時間で多段の処理を体験するには、細かな確認ダイアログで毎回止めない方が進行しやすいからです。

しかし、ここから「本番でも同じ設定が推奨される」と読むのは危険です。

イベントでは、次の外部条件が安全網として働きます。

• 一時的で、終了後に破棄できる環境
• 教材の範囲へ限定されたProject
• あらかじめ用意された入力データとCloud資産
• ガイドに記載された期待結果
• Project-local Skillによる進行規約
• 人間の講師、サポート、リセット経路

つまり、自動実行性を高めた代わりに、実行環境の寿命、到達範囲、データ、復旧可能性を外側で狭めているのです。

これは本番設計にも応用できます。承認回数だけを増やすのではなく、失敗しても戻せるSandbox、限定権限、dry-run、固定fixture、機械的テストを整備すれば、安全性を保ちながら不要な承認を減らせます。

高い自動実行性は、安全策が少ない状態ではありません。人間のクリックを、より再現可能な構造へ置き換えた状態です。

3. Skillとは何か――長いプロンプトではなく、オンデマンドの作業パッケージ

GoogleのAntigravity Skills Codelabでは、SkillはSKILL.mdと、必要に応じてscripts、references、assetsを含むディレクトリ形式のパッケージとして説明されています。

最小構造は次のようになります。

my-skill/
├── SKILL.md          # いつ使い、どう進めるか
├── scripts/          # 必要なら決定論的な処理を置く
├── references/       # 必要時だけ読む仕様・手順書
└── assets/           # Templateや静的素材

この構造が解決するのは、Contextの詰め込みです。

多数の業務手順をSystem Promptへ常時入れると、無関係な知識まで毎回読み込まれます。Context Windowを消費するだけでなく、似た指示が衝突し、重要な制約が埋もれます。

Skillでは、最初に名前とdescriptionという軽量な情報だけを見せます。依頼との関連性が高いと判断されたときに本文を読み、さらに必要な参照資料だけを開きます。この方式はProgressive Disclosure、つまり「必要な情報を必要な段階で開示する設計」です。

Skill、Rule、Tool、MCPは別の役割を持つ

ここは混同されやすいので、作業現場に置き換えます。

Skill本文に「危険な操作をしない」と書くことは重要です。しかし、それだけを強制的なセキュリティ境界と考えてはいけません。自然言語の指示は判断を導く層です。確実に遮断すべき操作は、File / Network / Terminal Permission、Sandbox、IAM、Hook、承認Workflowなど、より決定論的な層でも止める必要があります。

この違いを一言で表すと、次のようになります。

Skillは「どう働くべきか」を教える。Permissionは「実際に何が可能か」を決める。

4. すべてを「Googleが用意したSkill」と呼んではいけない

環境内に見えるSkillには、複数の出自があります。これを混ぜると、設計を誤読します。

実測できたBuilt-in Skillは、少なくとも次の三つでした。

ここで重要なのは、ファイルの存在と、現在の仕事で使えることが同じではない点です。

Skill運用には、少なくとも六つのGateがあります。

1. Availability：ディスク上にSkillが存在する
2. Discovery：現在のScopeでAgentが発見できる
3. Selection：依頼とdescriptionが対応し、Skillが選ばれる
4. Authorization：必要なFile、Network、Terminal、MCP権限がある
5. Execution：本文、Script、Tool callが実際に実行される
6. Verification：結果、実行経路、副作用が期待どおりだったと確認できる

たとえば、Skill一覧にpublish-to-githubが見えても、GitHubへ公開したことにはなりません。選択されていないかもしれませんし、認証や権限がなく、実行できないかもしれません。実行しても、意図したRepositoryだったかは別途検証が必要です。

同じSkill名でも、同じ実体とは限らない

Day 1 Lab 1では、同名のcode-reviewが複数の場所に存在し、それぞれ内容が異なることを確認しました。

• ガイドに従って現在のProjectに作ったもの
• 過去に保存された成果物に含まれるもの
• Antigravity製品内部のSession workflow template

名前だけをInventoryへ記録すると、この三つを同一視してしまいます。再現可能な管理には、少なくともScope、配置Path、Source repository、Version、Hashが必要です。

この問題はSkill特有ではありません。コンテナイメージをlatestだけで管理しない、依存packageを名前だけで管理しないのと同じです。Skillも実行に影響する以上、Software Supply Chainの一部として扱う必要があります。

ここまでの振り返り

Skillは、次の三つを同時に持てる便利な単位です。

• Agentへ渡す手順知
• その手順が使う参照資料やScript
• 成功・失敗を説明するための報告形式

一方、Skillファイルがあるだけでは、安全性も成功も保証しません。Scope、選択、権限、実行、検証が揃って初めて、運用可能な能力になります。

ここからは、各Lab／Trackがこの仕組みをどのように使い分けたかを見ていきます。

5. Day 1 Lab 1――最初に一つだけ作らせる理由

Day 1 Lab 1では、Project-localなcode-review Skillを参加者自身が作ります。

扱う内容は比較的小さいものです。

• コードが意図どおり動くか
• 例外や境界条件を見落としていないか
• 明らかな性能上の問題がないか
• 問題箇所を行番号付きで示すか
• 修正理由を説明するか

一見すると、単純なコードレビュー用プロンプトに見えます。しかし教育設計としては、かなりよくできています。

参加者はこの一つのSkillを通して、次を順番に体験できます。

1. Project配下にSkillを置く
2. descriptionへ「いつ使うか」を書く
3. 本文へ確認項目と出力形式を書く
4. コードレビューを依頼する
5. AgentがSkillを選択した結果を見る
6. 実際の指摘がSkillの契約に沿っているか確かめる

最初から数十個のSkillを見せるより、自分で一つ作り、発見と選択を観察する方が、仕組みを理解しやすくなります。

ここで教えているのは「コードレビューのやり方」だけではありません。

暗黙知を、選択条件と実行手順を持つ再利用可能なパッケージへ変換する。

この変換こそ、企業内でSkillを設計するときの基本動作です。

6. Day 1 Lab 2――Agent開発のライフサイクルを七つへ分解する

Lab 2では、uvx google-agents-cli setupを通して、Agents CLIの開発Skill群を利用できる状態へ進みます。確認できたのは次の七つです。

GoogleのAgents CLIは、AI coding assistantへAgentの作成、評価、デプロイに関するSkillを与えるツールとして公開されています。ADKのCode with AIにも、Scaffoldから実装、テスト、評価、デプロイへ進む考え方が示されています。

なぜ一枚の巨大なADKマニュアルにしないのか

Agent開発には多くの知識が必要です。しかし、Projectを作り始めた瞬間に、DeploymentやObservabilityの細部までContextへ入れる必要はありません。

七つに分けることで、現在の工程に必要な知識だけを読み込めます。これは単なるファイル整理ではなく、Context Engineeringです。

さらに、失敗したときの責任範囲が明確になります。

• Project構造が不正ならScaffold
• ADKの実装patternが誤っていればADK Code
• 評価datasetやmetricが不適切ならEvaluation
• 実行環境への接続が問題ならDeploy
• Traceが不足して原因が追えなければObservability

巨大なSkillでは、どの手順が問題だったのか分かりにくくなります。工程ごとのSkill分割は、認知負荷を下げるだけでなく、Owner、Version、Testを分離する設計でもあります。

最終回答だけでなく、Trajectoryを評価する

Agent評価で重要なのは、最終回答が正しそうに見えるかだけではありません。

たとえば、顧客情報を調べるAgentが最終的に正しい住所を返したとしても、途中で許可されていないデータベースを読んでいれば失敗です。逆に、必要なToolを正しい順番で呼び、権限不足で安全に停止したなら、その失敗は統制上価値があります。

そこで評価を二つに分けます。

• Output Evaluation：最終結果は正しいか
• Trajectory Evaluation：どのToolを、どの引数と順序で使い、どこへ到達したか

Agents CLIのEvaluation Guideは、評価dataset、metric、judge、実行結果を扱うための入口になります。企業では、出力品質だけでなく、禁止Toolを呼ばない、承認前に変更しない、指定した検索源を使うといった経路条件もTest Caseへ含める必要があります。

7. Day 2 Platform――Skillを「実行可能な講師台本」にする

Day 2 Platformのガイドでは、演習用の架空企業としてNovaSmartが登場します。参加者はNovaSmartのAI Platform / Security責任者という立場で、Agent Inventory、Identity、IAM、Gateway、Content Security、Evaluationなどを調べます。

ここでProject-localに置かれていたnovasmart-governance-labは、単なるGoogle Cloudコマンド集ではありませんでした。

Skill本体と、Mission別の参照資料が分離されています。

novasmart-governance-lab/
├── SKILL.md
└── references/
    ├── m0.md
    ├── m1.md
    ├── m2.md
    ├── m3.md
    └── m5.md

m4.mdがないのは、ガイド上で該当Missionが実操作の対象ではない構成と整合します。

Skillが統一していたもの

このSkillには、技術手順だけでなく、進行と説明の品質を揃える規約が含まれていました。

ここには、AIに正解を教える以上の意味があります。

通常、大規模なハンズオンでは講師やTAが参加者ごとに説明します。「先に状態を確認してください」「結果が空なら成功扱いしないでください」「変更後にもう一度読み直してください」といった注意は、人間が繰り返し伝えます。

Platform Trackでは、その講師の一部をSkillとしてProjectへ配布しています。Skillが、次の四つを同時に担っているのです。

1. Curriculum：何を、どの順番で学ぶか
2. Safety protocol：何を勝手に変更しないか
3. Evidence contract：何を実行済みと呼べるか
4. Communication standard：誰に、どの粒度で説明するか

私はこの役割を、Teaching Control Planeと捉えています。

Control Planeとは、個々の処理そのものではなく、「どの処理を、誰が、どの規則で動かすか」を管理する層です。Project-local Skillは、参加者のAgentへ共通の授業進行規約を配るControl Planeとして機能していました。

高い自動実行性と、厳しい証拠規約は矛盾しない

Platform環境でも、UI上はTurbo ModeとAlways Proceedが観測されました。一方、Skill本文では、一度に一つ変更する、変更後に再測定する、実行していない結果を報告しない、といった厳格な規約が置かれています。

これは矛盾ではありません。

• UIは、作業を止めすぎない
• Skillは、作業順序と報告品質を揃える
• PermissionやIAMは、能力の上限を決める
• 一時環境は、失敗時の影響を限定する
• Evidenceは、人間が結果を採用できる状態にする

安全性を一つの「確認ボタン」へ集中させず、複数の層へ分散しているのです。

8. Day 2 App――共通ライフサイクルとアプリ固有レシピを二層化する

Day 2 Appのガイドでは、Agents CLIの共通Skillに加え、Starter repositoryがアプリ構築用のProject-local Skillを提供します。

確認できたSkill directoryは次の八つです。公開Starterの現在の論理名とDirectory名が一部異なるため、両方を記載します。

この構造は、次の二層に分かれます。

共通のAgent開発Lifecycle
  └─ scaffold / code / eval / deploy / publish / observability

イベント固有のApp recipe
  └─ brief / memory / RAG / A2UI / frontend / demo / troubleshooting

上段は複数Projectで再利用できる製品知識です。下段は今回のアプリシナリオに固有の手順です。

この分離により、Agents CLIの共通基盤を更新しながら、イベントのテーマやStarterだけを差し替えられます。企業でいえば、Platform Teamが共通Lifecycle Skillを管理し、各Product TeamがDomain固有のSkillをProjectへ置く形です。

Planning用Skillが実装を始めないことに意味がある

pick-your-agent-projectは、アイデアを整理してproject_brief.mdを作ったところで停止します。その場で実装まで走りません。

これは、AIエージェントへすべてを一度に任せないためのPhase boundaryです。

「相談しただけなのに大量のCloud resourceが作られた」という事故は、自然言語の会話と副作用のある実装を同じPhaseに置くと起きやすくなります。Planning Skillが成果物を作って止まり、人が方向性を確認した後でBuildへ進む構造は、意図を実行へ変換する境界を可視化します。

Troubleshootingを独立Skillにする意味

セットアップ問題は、本来のアプリ設計とは原因が異なります。Account、Project、gcloud、Application Default Credentials、API、IAM、Skill discovery、URL openerなどを独立したTroubleshooting Skillへ集めることで、アプリの不具合と環境の不具合を分離できます。

しかも、基本順序は「読む前に直す」ではなく「確認してから必要な変更だけを行う」です。これは本番運用のDiagnosticsでも重要です。原因を観測する前に状態を変えると、証拠が消え、再現できなくなるからです。

MCPは二つの外部能力をProjectへ与える

Starterには、Project-localなMCP設定も含まれます。

ここでもSkillとMCPの役割は分かれています。

• Skillは「何を、どの順番で行うか」を教える
• MCPは「どの外部情報・機能へ到達できるか」を与える

なお、公開されているApp Builders Starter repositoryには、ワークショップ用のデモであり、公式サポート対象のGoogle製品ではない旨が明記されています。したがって、公開Starterの全内容を「Google製品の標準仕様」として扱うべきではありません。教材実装と公式製品仕様を分けて読む必要があります。

9. Day 2 Business――SKILL.mdを見せないことも設計である

Day 2 Businessのガイドは、Antigravityとfile-based Skillを中心にしたトラックではありません。Gemini Enterprise上でAgent、Connector、Data Source、Canvas、Notebook、Workflow、Human Approvalなどを扱います。

この環境へ、開発者向けのSkill directoryという物差しをそのまま当てるのは不適切です。

Business利用者が知りたいのは、次のような問いです。

• どの業務データを使えるか
• どのAgentを選べばよいか
• どこで人間の承認が入るか
• 結果をReportやNotebookとしてどう利用するか
• 業務Workflowのどこまでを自動化するか

開発者向け環境では、これらがFile、Skill、MCP、Tool、Permissionとして見えます。Business向け環境では、同じ設計要素がUI上のConnector、Workflow node、Approval、Preview、Publishへ翻訳されます。

これは機能の欠如ではなく、対象者に合わせた抽象化です。

三つのTrackは別々のAgent像を教えているのではありません。同じAgent Systemを、構築、統制、業務利用という異なる高さから見せています。

ここまでの振り返り

• Day 1 Lab 1は、Skillの最小単位を自分で作る
• Day 1 Lab 2は、Agent開発Lifecycleを七つのSkillへ分解する
• Day 2 Platformは、進行・安全・証拠を一つの教材Skillへ梱包する
• Day 2 Appは、共通Lifecycleとアプリ固有recipeを二層化する
• Day 2 Businessは、同じ能力をSaaSの業務部品として見せる

ここまで来ると、Skillは単なる「便利な追加機能」ではなく、対象者に合わせて専門知識と作業構造を配る媒体だと分かります。

10. 高度な設計論――SkillはVersioned Operational Packageである

ここから、イベント観測を企業設計へ引き上げます。

10.1 SkillはPrompt assetではなく、変更管理の対象である

SkillはAgentの判断と実行へ影響します。そこには手順、禁止事項、Toolの使い方、Script、参照資料、成功条件が含まれます。

したがって、文書管理だけでもコード管理だけでも不十分です。実運用では、次の性質を持つVersioned Operational Packageとして扱う必要があります。

• Versionを持つ
• Ownerがいる
• 変更差分をReviewする
• Test Caseを持つ
• 依存ToolとPermissionを宣言する
• Rollbackできる
• 実行結果を観測できる
• 廃止時に利用Projectを追跡できる

自然言語で書かれているからといって、変更リスクが低いわけではありません。むしろ、一文の変更が多数のAgentのRoutingや行動を変える可能性があります。

10.2 Scopeは情報整理ではなく、Blast Radiusの制御である

Global Skillは全Projectから利用できるため、再利用性が高い一方、誤った更新の影響範囲も広くなります。Project-local Skillは、特定の業務文脈へ閉じ込められます。

Scopeを決める基準は、「便利だから共有する」だけではありません。

KnowledgeのScopeとPermissionのScopeを揃えることが重要です。Project固有の手順だけを局所化しても、Global MCPが過剰権限なら、能力境界は広いままです。

10.3 「Instruction」と「Enforcement」を分離する

Skillの制約は、Agentの判断を良い方向へ導きます。しかし、すべての制約が確実に守られると仮定してはいけません。

制御を強さの異なる層へ分けます。

高リスクの操作ほど、Guidanceだけでなく下の層でも制御します。

10.4 Evidenceを「完了報告」から独立させる

Agentが「テストは成功しました」と書いた文章は、検証の入口です。独立した証拠ではありません。

証拠の強さは段階的に上げられます。

たとえば、次の順序です。

1. Agentの自己申告
2. Plan、Task List、Walkthroughなどの可視Artifact
3. Command、Exit code、Test、Lint、Trace
4. 対象ArtifactのInventory、Version、Hash
5. 分離した環境での独立再実行

ただし、証拠を増やすほどよいわけでもありません。LogやTraceにCredential、個人情報、顧客データを複製すれば、新しい漏えい面になります。Evidence planeにもData minimization、Retention、Access controlが必要です。

10.5 Skill RoutingにもRegression Testが必要である

Skillが増えると、似たdescription同士が競合します。新しいSkillを追加した結果、既存の依頼が別SkillへRouteされる可能性があります。

最低限、次の三種類を評価します。

• Positive case：対象依頼で正しいSkillが選ばれる
• Negative case：無関係な依頼では選ばれない
• Collision case：似たSkillがある場合も正しい方へ分岐する

さらに、選択後の実行も分けて評価します。

• 正しいToolを選んだか
• 引数は正しいか
• 許された順序で呼んだか
• 禁止されたToolを呼ばなかったか
• 途中失敗時に安全に停止したか

Skillの品質を文章のレビューだけで終わらせず、RoutingとTrajectoryのRegression Testへ落とす必要があります。

11. 自社へ導入するなら、まずSkill台帳を作る

Skill Catalogを作るとき、名前と説明だけを一覧にしても足りません。次の情報を結び付けます。

導入を四段階に分ける

いきなり全社共通Skill Catalogを作るより、次の順序が現実的です。

段階1：低リスクのProject-local Skill

コードレビュー、文書整形、Read-only調査など、副作用が小さい仕事から始めます。Positive / Negative caseを作り、Skillが選ばれる条件を観察します。

段階2：決定論的なValidatorを組み込む

文章だけで判定せず、Schema、Test、Lint、Policy engine、固定Scriptへ判断を委ねます。Agentは結果の説明と修正を担当します。

段階3：権限と副作用を分離する

Read-only、Draft-only、Action-allowedなどのTierを作り、Skillの役割と実権限を一致させます。外部送信や本番変更には明確なApprovalを置きます。

段階4：LifecycleとGovernanceを接続する

SkillのVersion、Evaluation、Observability、Incident、廃止を、通常のSoftware Deliveryと同じ管理へ入れます。

12. このイベントから得られる、本当に高度な学び

表面的な学びは、「Antigravityへ自然言語で依頼すると、Agentやアプリを作れる」です。しかし、設計者の視点で見ると、より重要な学びがあります。

学び1：自由度は、構造を減らすことで生まれるとは限らない

参加者が自由に試せたのは、裏側に構造がなかったからではありません。環境差、認証、依存関係、教材、復旧を運営側が引き受けたからです。

学び2：Skillは専門知識を配るだけでなく、組織の仕事の形を配る

「先に観測する」「一度に一つ変更する」「再測定する」「未確認と書く」といった手順は、技術知識ではなくEngineering Cultureです。Skillはその文化を実行時Contextへ届けられます。

学び3：自動化の成熟度は、何回クリックを減らしたかでは測れない

成熟した自動化は、止まらないことではありません。正しい境界で止まり、失敗理由を説明し、再実行でき、必要なら戻せることです。

学び4：モデルを変えても、Harnessの責任は残る

モデルが高性能になっても、Scope、Permission、Tool、State、Evidence、Recoveryは自動的には設計されません。むしろ、モデルが多くの操作を自律的に行えるほど、周囲のHarnessが重要になります。

学び5：良い教材設計は、そのまま良いAgent運用設計になる

学習目標、前提条件、段階的な課題、期待結果、失敗時のヒント、最終確認。これらは、Agentへ仕事を委任する際のSpecification、Tooling、Evaluation、Observability、Recoveryとほぼ同型です。

Platform Trackの教材Skillが興味深いのは、教材と運用Runbookの境界が薄くなっている点です。人へ教えるために作った構造が、Agentを安全に運用する構造にもなっています。

おわりに――AIへ何を頼むかの前に、AIが働く場所を設計する

Build With Google 2026の環境を俯瞰すると、Day 1からDay 2まで一本の流れが見えます。

最初にProjectとSkillの基本を学び、次にAgent開発Lifecycleを分解し、App Trackで機能を組み合わせ、Platform TrackでIdentity・権限・証拠を統制し、Business Trackで業務Workflowへ接続する。

その中心にあるのは、単一のモデルや魔法のプロンプトではありません。

• 共通BaselineとProject固有差分の分離
• 必要な知識だけを読むProgressive Disclosure
• SkillとPermissionの分離
• 出力とTrajectoryの二重評価
• 一時環境と復旧経路による影響限定
• 観測事実、期待値、推論を混ぜないEvidence設計

これらを積み上げることで、自然言語の柔軟さを残しながら、仕事としての再現性を高めています。

AIエージェント時代の重要な設計対象は、モデルだけではありません。

Agentの能力が高くなるほど、「何を知り、何ができ、どの順番で動き、何を証拠として残すか」を設計する価値が高くなる。

イベント環境で見えた最も大きな知見は、ここにあると考えます。

参考資料

• Authoring Google Antigravity Skills — Google Codelabs
• Code with AI — Agent Development Kit
• Evaluation Guide — Agents CLI
• Google Agents CLI — GitHub
• Build with Gemini App Builders Starter Repository
• Build With Google Day 1 Lab 1 Guide
• Build With Google Day 1 Lab 2 Guide
• Build With Google Day 2 Platform Guide
• Build With Google Day 2 App Guide
• Build With Google Day 2 Business Guide

調査上の制約

• 設定値は観測時点の状態であり、すべてが配布直後の初期値とは限りません。
• App Trackの現在の再割当環境ではAccount Setupが完了せず、現在のGlobal presetとSkill hashは確認できませんでした。そのため、以前の実測と公開Starterの定義を分けて扱っています。
• Fileが存在することと、現在のProjectでactiveであることを区別しています。
• 非公開のSkill router内部実装や、個々の教材ファイルの執筆者は推測していません。
• 本調査では、認証情報の取得・移送、GitHubへのLoginやPush、外部サービスへの成果物送信を行っていません。