一つのタスク中は十分な背景を持っていたAgentでも、新しい会話では同じ説明が必要になることがあります。どの方針が有効か、どの判断が承認されたか、前回の課題が本当に解決したか。実行が速くなるほど、こうした引き継ぎの負担が目立ちます。
Googleは11月12日、日常的なコーディング、デバッグ、対話的な開発、Agent作業向けにGemini 4 Hydrogenを紹介しました。四段階のthinkingを設定でき、CarbonやArgonとの協働にも対応します。次の作業へ素早く進める能力に加えて、現在の業務知識をどこから受け取るかを設計する必要があります。
モデル、実行環境、知識層を分ける
モデルは渡されたコンテキストを処理します。Agentやアプリは会話、ツール、資料の取得を管理します。外部の知識層は、タスクをまたいで読む文書、構造化した事実、手順を保持します。
Busabaseへ接続するのはツールを使える実行環境です。Gemini APIでアプリを構築するなら、読み取り、文脈の組み立て、書き戻しはアプリ側で調整します。モデル選択だけで、すべてのGoogle画面に同じ接続機能が加わるわけではありません。実際の環境でHydrogenとMCPまたはRESTを利用できるか確認します。
記憶、知識ベース、正式記録の違いを手がかりに、一時的な推論、長期的な説明、責任者付きの業務事実を分けて保存します。
構造図・調整可能な設計
資料、事実、方法にそれぞれ場所を用意する
起点となる設計例は、プロジェクトのFolder、制約と範囲を記すDoc、検索可能な事実のBase、読み取りと提案の方法を記すSkillです。これは調整可能な設計であり、Hydrogen専用の組み込み連携ではありません。
事実Baseには短いタイトル、安定したテーマキー、現在の結論、出典URL、適用範囲、担当者、業務状態を設けます。結果Baseには実際の成果物URL、未解決事項、検証結果を保存し、使った事実へrelationを張れます。維持されている原資料は、複製よりリンクを優先します。
最初は読み取りだけで一巡させる
Bring Your Own AgentまたはMCPガイドで実際の環境を接続し、本人とSpaceを読み取り専用で確認します。複数Spaceがあれば対象を明示します。
Agentは作業前にplaybookを検索し、該当する方法とプロジェクトDocを読み、今回に適用できる事実を取得します。モデルへ渡す文脈には出典、範囲、未確定事項を残します。キーワードが一致するだけの古い情報を実装条件にしません。
構造図・調整可能な設計
発見を確認可能な提案へ変える
接続後には次のように依頼できます。
このプロジェクトの制約と現在有効な事実を読み、出典付きの文脈を整理してください。作業後は再利用できる結論を既存テーマと比較し、既存なら項目更新、新規テーマなら追加を提案します。実在の出典、成果物、未解決事項を残し、人の確認が必要な変更は提案のまま差分とリンクを返してください。
成果は制約一覧、実際の作業成果物、知識変更の提案です。コードのテストと、後続作業が使う業務結論の受け入れは別々に確認します。Agentの完了報告だけで両方を承認済みにしません。
次のタスクは現在の有効な記録から始める
Busabaseの変更は差分と履歴を持つChangeRequestを通ります。提案専用権限なら審査待ちになり、write権限なら即時マージされる場合があります。人の確認が必要なら権限または対応する要求設定で実現します。
マージ後は項目と出典関係を再読します。次の会話でも現在値を読み、業務状態と適用範囲を確認します。マージされた変更が未確定の結論を保存している場合もあるため、mergedだけで業務上の承認を判断しません。
構造図・調整可能な設計
会話を超えて使う情報から始める
一回限りの質問なら、会話と維持された文書だけで十分な場合があります。反復タスク、複数Agentによる共有、変化する業務事実、承認経緯の確認が必要になると、共有知識層の価値が高まります。
一つのプロジェクトと制約Doc、実際の事実から始め、読み取り、実行、提案、受け入れ、再読を一巡させます。新しい会話が有効な知識と根拠を取得できることを確認してください。モデルの重みが社内資料を記憶したという意味ではありません。自分のAgentの接続から小さく始められます。