Executive Summary
AIとの会話だけなら、チャット画面があれば十分に見えます。しかし、仕事を継続し、別の日に再開し、外部システムを使い、危険な操作を止め、作業内容を人が確認するには、会話の外側が必要です。
Google Antigravityを理解する鍵は、AIチャットではなく、Agentの職場として見ることです。
- Projectは、案件のファイル・ルール・会話をまとめる作業境界
- Conversationは、目的と履歴を持つ実行単位
- Scheduled Taskは、時間を起点に仕事を再実行する仕組み
- MCPは、外部システムへ届く標準化された接続面
- Security / Permissionsは、してよい操作を制限する統制
- Plan / Diff / WalkthroughなどのArtifactsは、人間が監督するための証拠
本稿では、Build With Google Day 1 Lab 1の順序に沿って、これらがなぜ一つの職場を構成するのかを解きます。
シリーズの現在地
全5回で「AIがものすごく賢くなった。では、本当に仕事を任せられるのか？」を追っています。
- Agentic Engineeringとは何か
- Antigravityという職場（今回）
- Agent Skillsという業務マニュアル
- Agents CLIとADK Graphによる工程設計
- OutputとTrajectoryによる評価
前回からの接続——能力には「働く場所」が要る
前回は、ものすごく優秀な新人が入っても、仕様、資料、道具、権限、検査がなければ仕事を任せられない、と説明しました。
では、それらをどこで管理するのでしょうか。
普通の会社なら、案件用フォルダ、会議室、社内システム、入館証、予定表、レビュー手続きがあります。AIエージェントにも、それらに相当する構造が必要です。
つまり、Antigravityが管理するのは「回答」だけではなく、回答を仕事として成立させる環境です。
この図では、Projectの内側にConversationとArtifactsを置きました。ScheduleとMCPは仕事を起動し、外部へ到達させます。SecurityとPermissionsは、その全体へ「何をしてよいか」という境界をかけます。
ここから、Lab 1の操作順に見ていきます。
1. Project——案件ごとの作業境界
会社では、顧客Aの資料と顧客Bの資料を同じ机へ無造作に積みません。案件ごとにフォルダ、担当者、ルール、会話を分けます。
AntigravityのProjectも、単なるディレクトリ名以上の役割を持ちます。Lab 1ではProjectを作り、その中でConversationを開始し、Project固有のSettingsやSkillを扱います。
VM上では、Projectの中に複数のConversation履歴が並び、同じ作業領域から再開できることを確認しました。
ここで重要なのは、「会話が保存される」ことだけではありません。
一つの仕事には、ソースコード、設計資料、過去の判断、適用するSkill、許可されたToolが関係します。Projectは、それらを同じ仕事の文脈として束ねる単位です。
ただし、この画面だけから、Projectが完全なセキュリティ隔離を提供するとまでは言えません。ここで直接観測できるのは、会話と設定がProject単位で組織化されていることです。
つまり、Projectは「ファイルの置き場所」ではなく、「このAgentがどの仕事の世界にいるか」を定める境界です。
2. Conversation——目的と履歴を持つ実行単位
Projectが案件なら、Conversationはその案件内の一つの作業依頼です。
「新機能を実装する」と「既存コードをレビューする」は、同じリポジトリを使っていても目的が違います。会話を分けると、それぞれの依頼、途中の判断、実行結果を一つの流れとして追いやすくなります。
Lab 1では、Agent Managerから新しいConversationを作り、Slash commandも使います。Slash commandは、自由文の依頼に加えて、利用可能な定型機能へ明示的に到達する入口です。第3回で扱うProject-local Skillも、この候補に現れます。
Conversationには二つの役割があります。
- 実行の文脈：この作業で何を頼み、何を見て、何を変更したか。
- 監督の単位：人がどの計画や結果を確認し、どこで介入するか。
チャット履歴が長ければよいわけではありません。目的の違う仕事を一つのConversationへ混ぜると、古い前提や不要な指示が残り、判断を濁らせます。
つまり、Conversationは単なるメッセージ列ではなく、一つの目的を持つAgent実行のケースファイルです。
3. Governance——職場の共通規則をProjectへ継承する
新人ごと、仕事ごとに、セキュリティ規則を毎回口頭で説明していたら抜けが起きます。会社では、共通規則を組織や部門へ設定し、案件へ継承します。
VM上のProject Settingsでは、General Security PresetとArtifact Review Policyを継承する設定が確認できました。
さらに全体の設定面には、PermissionsやMCP Toolsを含む統制点がありました。
ここで「継承」は便利であると同時に、責任のある仕組みです。
よい規則を上位で定義すれば、新しいProjectにも一貫して適用できます。一方で、過度に広い権限や曖昧な規則を継承すれば、同じ問題も一貫して配られます。
したがって、設定項目が存在することと、設定が安全であることは別です。実運用では少なくとも次を確認します。
- 既定値が最小権限になっているか
- 危険な操作で人の確認を求めるか
- Project固有の例外が見える形で残るか
- 設定変更を後から追跡できるか
つまり、GovernanceはAgentを賢くする機能ではなく、その賢さをどの境界内で使うかを決める仕組みです。
4. MCP——外部システムへの「接続口」
新人が会社のルールを理解しても、社内データベースやチケットシステムへ入れなければ仕事は進みません。反対に、何へでも無制限に接続できる状態も危険です。
MCP（Model Context Protocol）は、Agentが外部のデータや機能へ接続するための標準化された境界です。Lab 1では、SettingsのCustomizationsからMCP serverを追加・管理し、serverが公開するToolを確認します。
大切なのは、MCPを「外部データそのもの」と考えないことです。
Agent
↓ Toolを選ぶ
MCPという接続面
↓ 定義された操作を呼ぶ
外部システム
MCPが接続方法を揃えても、そのToolを使ってよいか、どのProjectで許すか、読み取りだけか変更も可能かは別の統制です。Lab 1のProject Settingsでは、Projectで許可するMCP Toolsを絞る考え方も示されています。
つまり、MCPが「届く範囲」を作り、Permissionsが「してよい範囲」を決めます。両方がそろって初めて業務用のToolになります。
5. Scheduled Task——時刻ではなく、再実行の契約
毎朝9時にレポートを作る仕事を新人へ任せるとします。予定表へ「9時」と書くだけでは足りません。
- 何を入力として使うのか
- どのProjectとConversationの文脈で動くのか
- どのToolと権限を使うのか
- 成功・失敗をどこへ報告するのか
- 前回途中で止まった場合にどうするのか
これらが決まって、初めて繰り返し可能な仕事になります。
VM上では、Scheduled Taskの登録と、日次・cron形式を含む繰り返し設定を管理する画面を確認しました。
この画面は、予定を登録できることを示します。ただし、長期間にわたって時刻どおり同一結果が出ることまでは証明しません。モデル、参照データ、権限、依存環境が変われば、同じ依頼でも結果は変わり得ます。
Scheduled Taskを設計するときは、時間だけでなく次の契約を持たせます。
| 契約 | 確認する問い |
|---|---|
| Input | 毎回どの時点のデータを読むか |
| Context | どのルールと記憶を使うか |
| Capability | どのToolを使ってよいか |
| Idempotency | 再実行しても二重処理にならないか |
| Evidence | 成否と変更内容をどこへ残すか |
| Escalation | 曖昧・危険・失敗時に誰へ戻すか |
つまり、Scheduled TaskはAgent版の目覚まし時計ではなく、仕事を安全に再開するための運用契約です。
6. Artifacts——AIの「やりました」を検査可能にする
人間の同僚が「終わりました」とだけ報告したら、重要な変更では計画書、差分、テスト結果を確認します。AIエージェントも同じです。
Lab 1では、次のようなAgentic Artifactsを扱います。
- Implementation Plan：何を、なぜ、どの順で行うか
- Task：作業を小さく分けた進行単位
- Code Diff：実際に何を変更したか
- Command Output：テストやコマンドが何を返したか
- Walkthrough：最終的に何を実施し、どう確かめたか
VM上では、Implementation Planと、実装後のrouting evidenceが同じ作業の証拠として並ぶことを確認しました。公開画面には本稿の概念説明に不要な実行条件も含まれるため、ここでは再掲せず、構造だけを扱います。
Artifactの価値は、AIが美しい報告書を作れることではありません。主張と実物を人が突き合わせられることです。
「実装した」
├─ Plan：何を実装する予定だったか
├─ Diff：実際に何を変えたか
├─ Test：期待どおり動いたか
└─ Walkthrough：結果と残課題は何か
PlanどおりのDiffでも、要件自体が誤っているかもしれません。テストが通っても、テストが不足しているかもしれません。Artifactは判断を自動化して消すものではなく、人間が具体的に判断できる形へ仕事を変換するものです。
つまり、ArtifactsはAgentの成果物というより、人間とAgentの間に置く検査インターフェースです。
もう一段深く：Antigravityを3つの面に分けて読む
複数の機能を整理するには、次の3面に分けると見通しがよくなります。
| 面 | 主な要素 | 問い |
|---|---|---|
| Control Plane | Project Settings、Security、Permissions、Schedule | 何を、いつ、どこまで許すか |
| Execution Plane | Conversation、Agent、MCP Tools | 実際に何を読み、呼び、変更するか |
| Evidence Plane | Plan、Task、Diff、Command Output、Walkthrough | 何が起きたと証明できるか |
ここで「Control Plane」は本稿のアーキテクチャ上の読み方であり、画面に表示された製品名称とは限りません。
3面を分ける理由は、障害の種類が違うからです。権限設定の問題をPromptの書き換えで直そうとしても、本質的な解決にはなりません。実行が失敗したのに、最終報告だけを直しても、仕事は成功していません。証拠が残らなければ、後から原因を追えません。
さらに、3面は独立ではありません。ScheduleがConversationを起動し、ConversationがMCP Toolを呼び、その許可をPermissionsが制限し、結果をArtifactsへ残す。この連携が「職場」を作ります。
今回の持ち帰り
- Antigravityは会話UIだけではない。 Project、接続、権限、時間、証拠をまとめるAgentの職場として読める。
- MCPとPermissionsは別の責務。 接続可能であることと、操作を許可することを分ける。
- Artifactsは監督の接点。 AIの完了報告を、計画・差分・実行結果と照合できる形にする。
次回へ
職場の共通規則と道具がそろっても、「このコードをどうレビューするか」「どの観点を必ず確認するか」という個別業務の手順はまだありません。
毎回、長い説明を最初から書くのでしょうか。それとも、必要な仕事の手順だけを、そのとき開く方法があるのでしょうか。
次回は、Agent Skillsを「再利用できる業務マニュアル」として設計します。