調べるAIを、判断し実行できる業務システムへ——Business Builders編

Day 1で迎えた「ものすごく優秀な新人」は、資料を読み、検索し、要点をまとめるのが得意でした。Day 2のBusiness Builders Trackでは、その新人へ、もう一段難しい仕事を任せます。

市場と社内データを調べ、買収候補を比較し、レポートを作り、承認されたら次の業務を進めてください。

この記事でいうBusiness Agentは、質問へ答えるだけでなく、資料の調査、データ分析、承認待ち、承認後の業務処理までを支援するAgentです。

一見すると、検索、要約、表計算をつないだだけに見えます。しかし、この仕事には異なる性質の工程が含まれています。

• Webや社内文書から根拠を集める
• 根拠が同じ企業、同じ期間、同じ指標を指すか確かめる
• 欠損や外れ値を処理し、計算する
• 事実と推測を分けて解釈する
• 人がレビューできる形へまとめる
• 承認された内容だけを外部操作へ進める
• 後から、誰が何を根拠に決めたか説明する

ここを一つの「賢いチャット」に押し込むと、文章は流暢でも、引用の取り違え、古い資料、見えない権限漏れ、推測の事実化、承認後の内容差し替え、二重実行が起こります。

この記事では、公開Webの検索、社内データへの接続、画像や動画の分析、資料に基づく回答、Pythonによる計算、人の承認、承認後の処理を、ばらばらの便利機能ではなく「根拠 → 判断 → 承認 → 実行 → 証跡」という一つの業務システムとして読み解きます。各製品名は、その役割を説明する章で示します。

この記事の地図

最初に全体像を置きます。

図は、根拠→判断→承認→実行の順に進み、全段階を監査記録が横断する構造です。

次の表は上から下へ、買収調査の案件が進む時間順に読めます。いまは「各段階には別の失敗がある」と分かれば十分です。防ぎ方は本文で一段ずつ組み立てます。

この記事の中心命題は次の通りです。

Business Agentの品質は、最終文章の流暢さではなく、主張を根拠へ戻せること、判断の前提を説明できること、承認と実行を結び付けること、結果を監査できることで決まる。

この先も、一つの案件だけを追う

機能が切り替わるたびに別のデモへ見えないよう、物語の軸を固定します。ここで、架空の事業責任者として佐藤さん、架空の買収候補としてA社を設定します。佐藤さんは、複数の資料を順に調べる「調査役のAgent」にA社の一次調査を依頼します。この記事では、この調査役をResearch Agentと呼びます。

Research Agentは公開Webと社内資料を調べ、財務データを計算し、動画も確認し、候補を比較します。ただし、候補企業への連絡や社内システムの更新は、承認されるまで実行できません。

佐藤さんとA社は、複数の機能を一つの業務として説明するための架空設定です。本文で「演習では」と示す画面や結果は、ハンズオンで確認した内容です。架空の意思決定と演習事実を混同しないように書き分けます。

この案件を五つの場面に分けます。

1. 何を根拠として集めたか
2. その根拠から何を事実・仮定・予測として判断したか
3. 佐藤さんは何を見て、どの実行案を承認したか
4. 承認された内容だけが一度実行されたか
5. 後日、判断と実行を同じ証跡から再現できるか

検索、資料参照、計算、承認、業務処理の各機能は、この五場面のどこかを担当する道具です。製品名を覚えるより、どの受け渡しを確かにする道具かを追ってください。

先に、用語を日常語へ置き換える

以降で英語を併記するのは、公式資料や実装へ戻れるようにするためです。意味を理解するときは、まず右端の日常語へ置き換えて構いません。

記事は三つの段階で進みます。第1段階（1〜4章）は根拠、権限、映像、承認の境界を作る基礎編、第2段階（5〜8章）は人が判断できる材料を作る分析編、第3段階（9〜16章）は証拠から実行までをつなぎ、運用し続ける統合編です。各段階の終わりに、解けたことと次に残る問題を確認します。

1. 最初の仕事：Web検索を「根拠集め」へ変える

演習で使ったGemini Enterpriseは、組織の利用者がAI Agentを使い、公開情報や許可された業務データを調べるための環境です。その中で、回答をWeb検索の参照情報へ結び付ける仕組みをWeb Groundingと呼びます。まず、この「検索して出典を付ける」工程から見ます。

1.1 検索結果があることと、主張が裏付けられることは別

新人が「A社の売上は20%伸びています」と報告したとします。リンクが一つ付いていても、すぐ正しいとは限りません。

• リンク先はA社ではなく親会社かもしれない
• 売上ではなく取扱高かもしれない
• 年間ではなく四半期かもしれない
• 20%は前年比ではなく計画比かもしれない
• 通貨や会計基準が違うかもしれない
• 記事公開後に訂正されたかもしれない

必要なのは、回答の最後に参考リンクを並べることではなく、一つ一つの主張と、それを支える箇所を対応付けることです。

図は主張から根拠箇所、文書、発行元、時点へ遡ります。下段の対象、期間、指標、単位がそろわなければ、リンクがあっても根拠としては不十分です。

この図では、主張から該当箇所、文書、発行者、時点へ戻ります。さらに企業名、期間、指標、単位を照合します。どれかが違えば、リンクが存在しても、その主張の根拠にはなりません。

1.2 生成途中の文章を、確定した回答と考えない

Web Groundingを使った回答では、検索に使った語句、取得した情報源（source）、生成中の文章が段階的に現れます。演習でも、検索を伴う回答と参照元を確認できました。

利用者にとってstreamingは待ち時間を短くします。しかし、表示された途中の文を下流処理が即座に確定情報として扱うと危険です。後から引用が付き、文章が修正され、結論が変わる場合があるからです。

したがってシステム上は、少なくとも次の状態を分けます。

作成中 → 根拠確認中 → 確定 → 人の確認済み → 実行可能

画面に文字が見えたことと、業務上確定したことを同じにしません。

1.3 Grounding metadataは、真実の証明書ではない

Grounding with Google SearchとGrounding Metadataでは、検索に使った語句、回答を支えた文章断片、参照先、文書名、発行元のドメインなどを取得できます。

これは追跡可能性を大きく改善します。ただしmetadataが示すのは「どの情報を参照したか」であって、「主張が正しい」と自動判定する証明書ではありません。

本番では、主張ごとに次を持つclaim ledgerが有効です。

claim ledgerとは、レポート中の主張と根拠を一行ずつ対応させる「主張台帳」です。

次のJSONは、レポート中の一文を、その根拠と検証状態へ結び付ける例です。コードを読む必要はありません。見るべき点は、文章、引用、対象企業、期間、指標、検証結果を一つの記録にしていることです。

{
  "claim": "対象企業の年間売上は前年比20%増加した",
  "claim_type": "reported_fact",
  "entity": "target-company",
  "period": "FY2025",
  "metric": "revenue",
  "unit": "percent_yoy",
  "source_uri": "https://example.invalid/report",
  "supporting_passage_hash": "sha256:...",
  "published_at": "2026-02-10",
  "retrieved_at": "2026-09-04T04:00:00Z",
  "verification": "entity-period-metric-unit matched"
}

この形式なら、後で資料が更新されても、当時どの箇所を根拠に判断したかを追えます。ここでいうhashは、内容から作る電子的な指紋です。内容が変わればhashも変わるため、同じ版かを確認できます。保存時は著作権、機密、保持方針に合わせ、本文全体ではなく必要な識別子やhashに絞ります。

1.4 どの検索を使うかも、要件で決める

Web Grounding for Enterpriseは、通常のGoogle Search Groundingと比べて、規制要件への対応、入力データの扱い方、検索対象が更新される仕組みに違いがあります。

「検索精度が高い方」だけで選ばず、次を要件にします。

• 入力データの取り扱い
• 検索対象と更新頻度
• 地域、言語、規制要件
• 引用に必要なmetadata
• 監査と保持の要件
• 社内情報と公開Webを混ぜる条件

ここまでの振り返り

A社についてリンク付きの文章を作るだけではなく、主張ごとに該当箇所、対象企業、期間、指標、単位を照合し、取得時点を残すところまで進みました。Grounding metadataは追跡の入口であり、正しさの証明そのものではありません。

次に残る問題：公開Webだけでは買収判断に必要な社内条件や詳細データが足りません。次は社内データへ接続しますが、見つけられることと見てよいことを分けなければなりません。

2. 社内データ接続：見つけられることと、見てよいことを分ける

2.1 利用可能なAgentの一覧（Agent Gallery）は、権限の証明ではない

Agent Galleryでは、Google、組織、利用者、MarketplaceなどのAgentを見つけられます。演習でも、利用可能なAgentを選び、業務データへ問い合わせる流れを確認しました。

ここで大切なのは、一覧に見えること、起動できること、データを読めること、変更できることが別の権限である点です。

たとえば、Google Cloudのデータ分析基盤であるBigQueryを使うAgentへ「売上上位商品を教えて」と頼むだけなら、原則として読み取りに必要な範囲へ絞れます。Agentを動かす主体へ、データ更新や削除、権限変更まで渡す理由はありません。

ただし「読み取り専用Agent」という説明文だけでは不十分です。実際にどの名義で動くか、どのデータ集合・表・行・列を読めるか、検索処理を作成できるか、結果を外へ書き出せるかまで確認します。つまり、画面の説明ではなく、実効的に可能な操作を調べます。

2.2 読み取りでも、情報流出能力を持つ

閲覧だけなら安全とは限りません。社内データを読み、外部Web、メール、文書共有へ送れるなら、複数の小さな権限を組み合わせて情報流出の経路ができます。

そのため権限は、個々のrole名ではなく、次のような行為の連鎖で評価します。

社内データを読む
  → 内容を要約する
  → 外部の宛先へ送る

必要に応じて、読み取りAgentには外部送信Toolを与えない、export先を限定する、結果へ機密分類を付ける、利用者のACLを引き継ぐ、といった対策を組み合わせます。

2.3 社内システムとの接続（Connector）と、Agentへ直接渡す資料は別

Connectors and Data StoresとSource Access Controlでは、元システムの文書とACLをData Storeへ取り込み、利用者Identityに応じて検索を制御できます。

一方、Agentを共有する公式資料では、Agentへ直接追加したKnowledge fileについて、共有先が元ファイルへ直接アクセスできなくても、Agent経由で内容を質問できる可能性が警告されています。

この違いは重要です。

「Agentを共有しただけ」のつもりでも、Knowledgeを通じて情報共有範囲が広がる場合があります。公開前に、共有相手のIdentityで質問し、見えてはいけない情報が返らないことを否定試験します。

3. 動画や画像を扱う：Multimodal分析を監査可能にする

A社の財務資料だけでは、現場の安全や業務実態までは分かりません。そこで佐藤さんは、候補企業の現場確認映像も調査材料へ加えます。文章だけでなく画像、動画、音声も一緒に扱う分析をMultimodal分析と呼びます。情報源は文章から映像へ変わりますが、問いは同じです。「その判断を、元データのどこへ戻せるか」です。

3.1 AIの説明を、映像中の場所へ戻す

動画監査で「安全違反がありました」と回答されても、どの映像の何秒か分からなければ、人は確認できません。必要なのは、最終結論だけでなくchain of custody、つまり証拠がどこから来て、どう処理され、どの結論へ使われたかの連鎖です。

演習では、動画と別の業務データを組み合わせた監査結果を確認しました。

Multimodalでは、少なくとも三種類の誤りを分けます。

1. 知覚の誤り：物体、人物、文字、音声、時刻を読み違えた
2. 対応付けの誤り：正しく見えたが、別の店舗、機器、注文に結び付けた
3. 規則適用の誤り：事実は合っているが、規程の解釈を誤った

3.2 記録したい証拠

次のJSONは、動画中の一件をレビュー可能にする例です。目的は複雑な形式を作ることではなく、人が同じ場面を開き、同じ規則で再確認できるようにすることです。

{
  "asset_id": "video-20260904-001",
  "asset_hash": "sha256:...",
  "segment": {"start_ms": 42100, "end_ms": 48700},
  "observation": "保護具が確認できない人物を検出",
  "perception_confidence": 0.82,
  "linked_context": {
    "site": "warehouse-east",
    "camera": "loading-bay-2"
  },
  "policy_reference": "safety-policy-2026-07",
  "review_status": "needs_human_review"
}

元映像のhash、時間範囲、観測内容、対応付けた場所、適用規則、確認状態を分けることで、モデルの結論をそのまま処分や警告へ使うことを防げます。

3.3 「違反なし」は、完全に見た証明ではない

否定的な結論には注意が必要です。「違反を検出しなかった」は、次のどれかかもしれません。

• 本当に違反がない
• 映像の一部しか解析していない
• 暗い、遮蔽、音声欠損で判断できない
• 規則の対象行為を定義していない
• 閾値が高く、候補を落とした

報告書には、解析した映像範囲、除外区間、品質不足、未確認箇所も書きます。

3.4 レポート編集面（Canvas）は完成品ではなく、レビューの場所

ここでいうCanvasは、Agentの出力を文章や表として編集し、人が読みやすいレポートへ整える作業面です。Canvasで読みやすいレポートを作ると、調査結果を人が確認しやすくなります。

しかし、整った見た目は正しさの証明ではありません。レビュー画面には、主張から根拠へ戻るリンク、不確実性、未確認事項、使用データ版、承認者、更新履歴を表示したいところです。

ここまでの振り返り

調査範囲は公開Webから社内データ、さらに映像へ広がりました。その分、佐藤さんが見るレポートには、利用者ごとのアクセス権、取得したデータの版、映像の時刻範囲、未確認区間まで必要になりました。情報を増やすほど確かになるのではなく、情報ごとの権限と出所を追えることが大切です。

次に残る問題：ここまでは読み取りと分析でした。候補企業への連絡や、顧客・取引先情報を管理するシステム（CRM）の更新のような副作用を持つ操作へ進む前に、人の判断を技術的な停止点へ変える必要があります。

4. Human-in-the-loop：人を置くのではなく、実行を止める

4.1 人が画面を見るだけでは安全装置にならない

複数の処理を順番や条件付きでつなぐAgentをWorkflow Agentと呼びます。調査、条件分岐、別のAgent、社内外システムへの接続、人への確認を組み合わせられます。Workflow AgentとHITL Stepには、追加情報の要求や承認の仕組みがあります。

演習でも、人の承認を含むWorkflowを確認しました。

安全なHuman-in-the-loopには、次の条件が要ります。

• 承認前は副作用を起こさない
• 承認者が、対象、変更内容、根拠、リスクを見られる
• 承認後に内容が変わったら、その承認を使えない
• 拒否、期限切れ、無応答で安全に停止する
• 誰が、いつ、何を承認したか残る

図は、根拠→計画→レビュー→実行→実行証跡の順です。承認されなければ停止へ進み、実行には到達しません。

図で最も重要なのは、レビューの門が「計画」と「実行」の間にあることです。実行後に人へ通知するだけでは、承認ではなく事後報告です。

4.2 承認した内容と、実行内容を結び付ける

承認画面で見た内容と、Toolへ渡す内容が同じであることを保証します。代表的な方法は、実行計画を正規化し、そのhashを承認記録へ入れることです。

次の例は、承認された計画と実行直前の計画が同じかを確認する最小形です。コードを読むより、「内容が一文字でも変われば再承認」という性質に注目してください。

import hashlib
import json

def plan_hash(plan: dict) -> str:
    canonical = json.dumps(plan, sort_keys=True, separators=(",", ":"))
    return hashlib.sha256(canonical.encode()).hexdigest()

def execute_if_approved(plan: dict, approval: dict):
    if approval["status"] != "approved":
        raise PermissionError("承認されていません")
    if approval["expires_at"] < current_time():
        raise PermissionError("承認の有効期限が切れています")
    if approval["plan_hash"] != plan_hash(plan):
        raise PermissionError("承認後に計画が変更されています")
    return execute_once(plan, idempotency_key=approval["approval_id"])

この処理では、承認済み、期限内、内容一致を確認し、承認IDを二重実行防止にも使います。実務では承認者の権限、職務分離、署名、取消し、監査保持も加えます。

4.3 部分失敗を先に設計する

「三人へメールを送り、CRMを更新する」処理で、二人目の送信後にCRMが失敗したらどうするか。自動再試行で一人目と二人目へ再送すれば事故になります。

必要なのは、単純な成功・失敗の二値ではありません。

• 同じ依頼を二度実行しないための識別子（idempotency key）
• 操作ごとのreceipt
• どこまで完了したかを示す状態
• 補償操作が可能か
• 人へ引き継ぐ条件
• 再実行時に残りだけ進める仕組み

4.4 Workflowの更新も変更管理する

Workflowの共有では、所有者がLive versionを更新すると共有利用者は新しい版を使います。

承認者、接続先、条件式、AIへの指示文（Prompt）、Toolのいずれかが変われば、同じWorkflow名でもリスクは変わります。版の公開前に差分レビュー、評価、再承認を行い、実行ログには版を残します。

ここまでの振り返り

Human-in-the-loopを「人が眺める工程」から、「承認した計画と実行直前の計画が同じでなければ止まる工程」へ変えました。期限切れ、拒否、内容変更、部分失敗、二重実行も、正常系と同じくらい先に設計します。

次に残る問題：承認の仕組みが正しくても、承認者へ渡す分析が、事実と予測を混ぜたり、欠損を隠したりしていれば意味のある判断はできません。次は判断材料そのものの品質を整えます。

5. 企業買収（M&A）分析：数字を並べる前に、文章の種類を分ける

佐藤さんがA社の評価を読んで意思決定する段階へ進みます。買収候補の分析では、事実、要件、解釈、予測、決定が混ざりやすくなります。

これらを同じ文章の調子で書くと、予測が既成事実に見えます。表やレポート上でも、reported、calculated、assumed、projected、decidedのように型を分けます。

演習では、複数資料からリスク行列と代替案を作る流れを確認しました。

表が整っていることより、各セルがどの根拠、式、仮定から来たかをたどれることが重要です。合計、比率、将来の現金収支を現在価値へ換算するDCF法など、再計算できるものはコードや表計算で再実行し、モデルには式の意味と前提を説明させます。

6. 資料限定の作業帳（Notebook）：引用の正確さと完全さを分ける

ここでいうNotebookは、調査に使う資料を一か所へ集め、その資料の範囲内で質問するための作業帳です。指定した資料へ範囲を絞り、引用付きで質問できる点が強力です。NotebookLMの説明とGemini Enterprise Notebookでは、選択したsourceに基づく回答とinline citationを提供します。

ただし、次の二つは別です。

• 引用の正確さ：その文章が、引用箇所に本当に支えられているか
• 回答の完全さ：必要なsourceと論点を漏れなく扱ったか

引用が完璧でも、重要な契約書をNotebookへ入れていなければ、全体として不完全です。逆に必要資料が全部あっても、違う箇所を引用すれば不正確です。

6.1 取り込まれた複製（Static copy）の鮮度

Notebook Source APIではsourceの追加と管理を扱えます。取り込んだsourceがstatic copyなら、元文書の更新と同時に変わるとは限りません。

そこでsourceには次を持たせます。

• 元文書のURIと版
• 取り込み時刻
• 元文書の最終更新時刻
• hash
• 再同期状態
• 失効条件

「引用がある」だけでなく、「いつの資料を引用したか」を確認します。

7. Python実行：計算を再現できるようにし、仮定を隠さない

7.1 データをきれいにすることは、真実に戻すことではない

業務データには、欠損、単位違い、外れ値、重複、時刻ずれがあります。Pythonで整形すれば、計算を再実行できるようになります。しかし欠損補完は、失われた真値を復元する魔法ではありません。

図の上段は、生データ→整形→分析→判断、下段は入力データ→変換処理→仮定→結果です。判断だけでなく、そこへ至る変換と仮定を対にして残します。

この図では、欠損を補った値を明示し、分析段階で相関と感度を分け、最終判断に不確実性を残しています。下段にはsource、transform、assumption、resultの証跡があります。

演習でも、データをPythonで清掃し、分析へ進む過程を確認しました。

7.2 欠損補完は仮説として記録する

平均値や中央値で埋めると計算はできますが、結果が過度に安定して見える場合があります。たとえば売上の欠損が障害日の店舗に集中していれば、ランダム欠損ではありません。

最低限、次を記録します。

• 元の欠損位置
• 補完方法と理由
• 補完した値の印
• 補完前後の件数と分布
• 別手法での感度分析
• 補完を除外した結果

7.3 感度分析で「結論の丈夫さ」を見る

一つの補完方法で結論が出ても、仮定を少し変えたら逆転するなら、強い判断材料ではありません。

たとえば次を比較します。

• 欠損行を除く
• 中央値で補う
• グループ別中央値で補う
• 悲観値と楽観値で範囲を作る

どの方法でも候補Aが優位なら結論は比較的頑健です。手法ごとに順位が変わるなら「追加調査が必要」が正しい結論かもしれません。

7.4 相関を因果へ飛ばさない

演習では変数間のcorrelationも確認しました。

相関が高くても、AがBを引き起こしたとは限りません。共通原因、時系列trend、選択bias、逆因果があり得ます。

レポートでは、観測した相関、考えられる交絡、因果を主張するために追加で必要な実験や準実験を分けて書きます。

Gemini API Code Executionと、Agent本体から隔離してコードを動かすCode Execution Sandboxは、名前が似ていても実行方法、ファイルの読み書き、状態保持、制限時間などが異なります。分析結果を証拠にするなら、コードだけでなく入力のhash、利用ライブラリの版、乱数の初期値、時刻、実行出力、生成物のhashも残します。

8. Research Agent：停止条件と「見つからない」の扱い

Research Agentは、複数の情報源と候補をたどり、調査結果をまとめる役割のAgentです。佐藤さんの案件では、A社だけでなく複数候補を順に調べるため、いつ次へ進み、いつ人へ戻すかが重要になります。

8.1 「問題が見つかったら止める」を会話上のお願いにしない

複数企業を順に調査し、重大リスクを見つけたら止める仕事を考えます。Promptへ一文書くだけでは、Agentが後続候補の調査や外部操作を続ける可能性があります。

停止条件は、明示した状態遷移にします。

stateDiagram-v2
    [*] --> Researching
    Researching --> NeedsReview: 重大候補を検出
    Researching --> NextCandidate: 基準内
    NextCandidate --> Researching
    NeedsReview --> Stopped: 人が停止
    NeedsReview --> Researching: 人が再開
    Researching --> Completed: 全候補を確認

NeedsReviewに入ったら、後続の検索だけでなく、メール、更新、承認依頼などの副作用も技術的に止めます。

演習では、停止条件に関係する結果のpreviewも確認しました。

8.2 「不祥事が見つからない」は、無実の証明ではない

検索で重大問題が見つからなかったとき、言えるのは通常「定義した検索範囲、言語、期間、sourceでは見つけられなかった」です。

否定的な結論には次を添えます。

• 検索した企業名、別名、旧名
• 対象言語と地域
• 対象期間
• 使用query
• sourceの範囲
• 閲覧できなかった資料
• 最終検索時刻

8.3 対象企業の同定（Entity resolution）を誤ると、引用があっても失敗する

同名企業、親子会社、ブランド名、買収前後の名称を取り違えると、引用は実在していても対象企業の証拠ではありません。企業ID、所在地、公式domain、親会社、期間を照合し、曖昧なら自動判定を止めます。

ここまでの振り返り

A社の調査材料を、原文の事実、社内要件、解釈、予測、決定へ分けました。Notebookの引用には資料の範囲と鮮度を添え、Pythonの計算には入力、欠損処理、仮定、感度を残し、Research Agentには調査範囲と停止条件を与えました。

次に残る問題：個々の工程はよくなりましたが、根拠から実行までを一本につながなければ、途中で文脈や版が入れ替わります。ここからは、証拠の強さと工程間の受け渡し条件を決め、同じ案件を最初から最後まで再構成します。

9. 引用の有無で終わらせない：証拠の強さを段階で見る

引用の有無を二値で判定せず、証拠の質を段階で扱うとレビューしやすくなります。

次の表は、上から下へ証拠が強くなる順に読みます。URLがあるだけでは手動確認の入口にすぎません。対象・期間・指標を照合し、当時の版を固定し、独立した資料や反証まで調べて、重要な意思決定に使える状態へ近づきます。

重要な決定ほど上の段階を要求し、満たさなければ「不明」として止めます。

10. 工程の間で情報を落とさない：受け渡し条件を定義する

業務Agentを安定させる鍵は、各機能の間に受け渡し条件を置くことです。

ここは箇条書きが続きますが、四つの別テーマではありません。上の工程が下の工程へ渡す「入場券」です。条件を満たさない成果物は、次へ送らず、前の工程へ戻します。

根拠から判断へ

• 主張とsourceが対応している
• 対象、期間、指標、単位が一致している
• sourceの版と取得時刻がある
• 不確実性と未確認事項がある

判断から承認へ

• 事実、仮定、予測、提案が分かれている
• 代替案と主要リスクが表示される
• 承認者が必要な権限を持つ
• 判断材料の版が固定される

承認から実行へ

• 承認対象のhashと実行計画が一致する
• 承認が期限内で、取消されていない
• 実行主体と対象範囲が一致する
• idempotency keyがある

実行から監査へ

• 各操作のreceiptがある
• 部分失敗と補償結果がある
• 根拠、判断、承認、実行を共通traceで結べる
• Workflow、Agent、Tool、policyの版を残す

11. ここまでを一つの案件へ戻し、最初から最後まで歩く

ここまでの内容を、冒頭で設定したA社の一次調査へ戻して、最初から最後まで通します。事業責任者は佐藤さん、調査役はResearch Agentです。そこへ計算を行うTool、承認者、候補企業への連絡や社内更新を行うToolが加わります。

11.1 依頼を「調べて」から検査可能な条件へ変える

最初の依頼が「A社を調べて、良さそうなら次へ進めて」では、良い、次、進めるの意味が曖昧です。着手前に次へ分けます。

• 対象企業：法人ID、正式名称、別名、所在地
• 調査期間：いつからいつまでか
• source：公式開示、規制当局、信頼できる報道、社内資料
• 指標：売上、利益、顧客集中、訴訟、情報セキュリティなど
• 足切り条件：重大訴訟、制裁、予算超過など
• 出力：主張、引用、未確認事項、選択肢、推奨
• 許可された次の行為：追加調査までか、面談依頼のdraftまでか
• 人の承認が必要な行為：メール送信、データ共有、契約処理

この時点ではコードを書いていません。しかし、後の検索、評価、承認が可能になる重要な設計です。

11.2 調査結果をEvidence packetにする

Agentは最初から長い結論文を書くのではなく、再利用できる証拠の束（Evidence packet）を作ります。

Evidence packet
├─ 対象企業の確定情報
├─ 主張ごとの根拠箇所
├─ sourceの版・取得時刻・権威
├─ 反証または矛盾する資料
├─ 見つからなかった項目と検索範囲
├─ 欠損・品質不足・ACLで見えなかった範囲
└─ 計算に使う構造化データ

ここで「見つからなかった」情報も成果物に含めます。空欄をAgentの推測で埋めず、追加調査が必要な箇所として渡します。

11.3 分析は、入力と仮定を固定して行う

売上成長率や買収倍率を計算する前に、対象期間、通貨、会計基準、為替レート、欠損処理を確定します。

たとえば、A社と、もう一つの買収候補であるB社の利益率が異なるとき、事業の強さではなく、計上区分や一時費用の扱いが違う可能性があります。Agentは計算を速くできますが、比較可能性は人と明示ルールで確保します。

分析結果には、点推定だけでなく範囲を持たせます。

11.4 承認用の資料一式（Review packet）は、人の判断を助ける

承認者へ長文を一つ渡すのではなく、次を同じ画面で見せます。

1. 提案する行為
2. 対象と影響範囲
3. 主要な根拠
4. 仮定と不確実性
5. 反対材料
6. 代替案
7. 承認しない場合の扱い
8. 実行予定の正確な引数

ここでのHuman-in-the-loopは、AIの責任を人へ押し付ける仕組みではありません。人が意味のある判断をできるよう、EvidenceとActionの差を見せるinterfaceです。

11.5 実行後は「成功しました」ではなくreceiptを返す

面談依頼を送ったなら、送信先、template版、message hash、外部systemのmessage ID、送信時刻を残します。CRMを更新したなら、更新前後、record version、応答IDを残します。

最終的に次の一線をつなげられる状態が完成形です。

依頼
→ 検索条件
→ 使用したsource
→ 主張
→ 計算と仮定
→ 提案
→ 人が見た内容
→ 承認
→ 実行引数
→ 外部systemのreceipt

この一線が切れていなければ、結果が良かった理由も、事故が起きた理由も、次の改善も説明できます。

12. 公開後も崩れないようにする：継続的な保証を業務へ組み込む

一度正しく動いたWorkflowも、source、権限、model、Tool、規程が変われば挙動が変わります。そこで、品質保証を公開前の試験だけでなく運用中の循環にします。

12.1 変化を検知する

• Connectorの同期遅延が増えた
• 主要sourceのURLや版が変わった
• 利用者の所属とACLが変わった
• Agentまたはmodelの版が変わった
• Tool schemaや外部APIが変わった
• Workflowの条件や承認者が変わった
• 実データの分布が変わった

12.2 変化に応じて試験を選ぶ

すべての変更で全試験を回す必要はありません。影響範囲から選びます。

12.3 人のレビューも測定可能にする

「最終的に人が見るから大丈夫」ではなく、レビューの質も改善します。

• 承認者が根拠を開いた割合
• 修正・差し戻しの理由
• 後から発見された見落とし
• 一件の確認に必要な時間
• 不確実性表示の有無による判断差
• 自動化へ移せる低リスク項目

人を最後の万能防波堤にせず、どこで判断しやすく、どこで見落とすかを学習する仕組みにします。

案件を通した振り返り

佐藤さんの依頼は、対象と調査条件に分解され、Evidence packet、再現可能な分析、Review packet、承認済み実行計画、外部システムのReceiptへ変換されました。どの段階でも、前の成果物の版と根拠を引き継ぎます。公開後は、資料、権限、モデル、Tool、規程の変化に応じて必要な試験を再実行します。

次に残る問題：この長い流れを実務へ持ち帰るには、守る約束、監視する数字、導入順序へ圧縮する必要があります。以降はその運用版です。

13. 本番で守る約束

ここまでの設計を、個別機能の説明から「業務として必ず守る条件」へ変換します。左列が約束、右列が確認方法です。

監視したい指標

• 根拠付き主張の割合
• 主張と引用箇所の一致率
• 対象企業・期間の取り違え率
• sourceの鮮度違反数
• ACL否定試験の失敗数
• 補完値を含む指標の割合
• 感度分析で結論が逆転する割合
• 承認後の計画不一致数
• 副作用の重複率、部分失敗率
• 根拠から実行まで追跡できた割合

14. 導入するなら、小さくても証拠の強い仕事から

まず読み取り専用の調査から始める

公開情報を調べ、claimとsourceを対応付け、人が確認するところまでにします。何をもって十分な根拠とするかを先に決めます。

次に社内データへ接続する

利用者ごとの閲覧権限、Agent専用の実行名義、検索条件の制約、結果の機密分類を確認します。共有設定を変えたときは、見えてはいけない情報が返らないことも試験します。

計算とMultimodalを加える

入力hash、変換、仮定、計算結果、映像の時間範囲を残します。欠損と不確実性を消さずに表示します。

Workflow化する

実行計画を固定し、副作用の直前に承認を置きます。期限切れ、拒否、部分失敗、重複再試行を試験します。

継続保証へ進む

source、model、Agent、Tool、Workflow、policyの版が変わるたびに、評価と標本レビューを回します。品質は一度の受入試験で終わりません。

15. よくある誤解を短く解く

「引用があるので正しい」

引用は追跡の入口です。対象、期間、指標、単位、該当箇所が主張と一致するかを確認します。

「sourceを限定したので完全」

限定範囲への忠実さと、必要sourceが全部そろっていることは別です。

「読み取りAgentなので安全」

読み取った情報を外部へ送れるなら、流出能力があります。権限の組み合わせで評価します。

「人の承認があるので安全」

承認が副作用の前にあり、見た内容と実行内容が結び付き、拒否と期限切れで停止する必要があります。

「Pythonで計算したので客観的」

計算は再現できますが、入力選択、欠損補完、外れ値処理、因果解釈には判断が残ります。

「問題が見つからなかったので問題なし」

検索した範囲で検出できなかっただけかもしれません。範囲と限界を結論へ添えます。

16. 実務チェックリスト

根拠

• 重要な主張を該当箇所へ戻せる
• 対象、期間、指標、単位を照合した
• sourceの取得時刻、版、hashを用途に応じて残す
• 反証と未確認事項を表示する
• 「見つからない」の検索範囲を記録する

権限

• Gallery表示、Agent実行、Data access、Actionを別権限として扱う
• 読み取りと外部送信の組み合わせを評価する
• Connector ACLと直接Knowledgeの境界を区別する
• 共有先利用者のIdentityで否定試験する

分析と判断

• reported、calculated、assumed、projected、decidedを分ける
• 欠損補完を印付けし、感度分析する
• 相関と因果を分ける
• コード、入力、library、結果を再現できる
• 不確実性が大きければ「追加調査」を選べる

承認と実行

• 副作用の直前に承認がある
• 承認者へ対象、差分、根拠、リスクを示す
• 承認内容と実行計画をhashで結ぶ
• 期限切れ、取消し、拒否で停止する
• idempotency、receipt、部分失敗を扱う

運用

• Agent、Tool、Workflow、policyの版を記録する
• 根拠から実行まで共通traceで追える
• sourceやモデルの更新後に回帰評価する
• 重大案件を人が標本reviewする

おわりに

Business Builders Trackの価値は、AIがWebを検索できた、BigQueryを読めた、動画を理解できた、Pythonを実行できた、という機能一覧ではありません。

根拠を集める。主張との対応を確かめる。データを整えながら仮定を残す。事実と予測を分ける。人が理解できる形で承認し、その内容だけを一度実行する。そして後から全経路を説明できる。

この流れがあって初めて、優秀な新人のレポートは、意思決定に耐える証拠になります。さらに承認と実行を厳密に結べば、AIは「答える画面」から、組織が責任を持って使える業務システムへ進みます。

公式資料

• Gemini Enterprise Documentation
• Grounding Overview
• Grounding with Google Search
• Grounding Metadata
• Web Grounding for Enterprise
• Agent Gallery
• Create BigQuery Data Agents
• Connectors and Data Stores
• Configure Source Access Control
• Share an Agent
• Workflow Agents
• Use HITL Steps
• Share a Workflow Agent
• Gemini Enterprise Notebook
• Notebook Source API
• Gemini API Code Execution
• Agent Platform Code Execution Sandbox