作業をつなぐ仕事も、AIが担当し始める
たとえば、営業の担当者から「来週の顧客訪問に向けて、提案資料を準備してほしい」と頼まれたとします。
これまでの進め方では、担当者自身が顧客情報を探し、過去の商談を読み、売上を集計し、資料にまとめていました。生成AIを使うと、検索、文章、集計用のプログラムは速くなります。それでも、作業のあいだをつなぎ、途中の誤りに気づき、最後に出してよいかを決めるのは、人の仕事でした。
AIエージェントは、この一連の作業をまとめて引き受けようとします。目的を渡すと、必要な情報を探し、道具を使い、結果を確認し、問題があればやり直します。判断が必要なところでは、人に確認します。これまでの生成AIは、質問に答えていました。エージェントは、人が決めた目的に向かって作業を進めます。
2026年4月22日、Google CloudはNext '26でIntroducing Gemini Enterprise Agent Platformを発表しました。Vertex AIを発展させ、エージェントを作り、広げ、統制し、改善するための基盤です。Thomas Kurian氏の基調講演Welcome to Google Cloud Next26でも、同じ4つ（build、scale、govern、optimize）で説明されています。発表文では、個別のAI作業を管理する段階から、業務の結果を任せる段階へ移す、と書かれています。
この基盤で先に名前を知っておきたいのは、実行の制御、コードの隔離、スキル、記憶、権限、結果の確認です。この記事は、2026年4月時点のこの6つについて、何を学ぶかを整理します。画面の操作手順は、製品が変わるとすぐ古くなります。
手順を自分で選べることと、その結果が正しいことは別です。 情報の不足、誤った前提、システム間の食い違い、権限の制約は、手順を選べても起きます。確認するのは、出てきた結果です。
動くソフトウェアを作る単位の話は、AIがソフトウェアを作る時代、IT技術者は何を作る人になるのかに書きました。画面上の仕事が先に変わることと、必要な5つの力は、シンギュラリティ予測より先にIT技術者の仕事は変わっているにあります。職種ごとに何を伸ばすかは、AI時代、IT技術者が今から準備すべきことです。
提案資料は手順が変わり、給与計算は手順を固定する
先の提案資料は、顧客や商談によって、次に調べるものが変わります。手順を最初から全部書くのが難しい仕事です。
これとは別に、従来の業務システムには、人が手順を先に書くものがあります。問い合わせが来たら、内容を分類し、担当を決め、データベースを検索し、回答を作り、確認してから送ります。ワークフローやRPAの利点は、同じ入力なら同じ手順になることです。
基調講演では、複数のエージェントへ仕事を振り分けるオーケストレーションに、2つの方式があると説明されています。1つは、状況に応じて次の作業を生成しながら任せます。もう1つは、決まった手順を毎回たどります。コンプライアンスのように誤りが許されにくい処理では、指定した手順を毎回たどれるようにする、ともあります。
給与計算、送金、在庫数量の更新は、発表の例には入っていません。同じ入力なら同じ結果が必要な点で、決まった手順に近い仕事として、ここでは扱います。複数の情報源を調べて報告書を書く仕事は、提案資料と同じで、状況に応じて手順が変わる候補です。
学ぶのは、仕事ごとにこの2つを分ける力です。何を自動化するか。どこでAIに判断させるか。どこは従来のプログラムにするか。どこで人の承認を置くか。失敗したら、どの状態へ戻すか。プログラムを仕様どおりに書く力に加えて、この分け方も必要です。
操作画面だけでは、失敗の原因が分からない
方式を分けても、操作画面の「完了」だけでは、失敗の原因は分かりません。モデルなのか、道具なのか、権限なのか、データなのかが分かれないからです。モデルの内部を研究する仕事と、業務システムに組み込む仕事は別です。業務システムで先に知っておきたいのは、先に挙げた6つの名前と、それぞれどこで誤りやすいかです。
次の行動は、モデルの外で決める
エージェントとして動かすには、目的に加えて、道具を呼び、結果を見て、次の行動を決める制御が必要です。モデルの外側で実行を制御する仕組みを、ハーネスと呼びます。詳しい説明は、ハーネスエンジニアリングとは？——AIエージェントを「手綱」で導く設計思想にあります。
売上分析を頼むと、次の繰り返しが起きます。使うデータを決める。問い合わせを作る。実行する。結果の形式を見る。おかしければやり直す。AI自身による見直しには限界があります。最初の前提が誤っていると、その前提を疑わないまま繰り返すことがあるからです。テスト、制約、人のレビューは、モデルの外で行います。
生成したコードは、隔離した環境で動かす
その繰り返しの途中で、エージェントがコードを書いて実行することがあります。どこで動かすかが問題になります。生成したコードには、意図しないファイル操作や、外部への通信が含まれることがあるからです。
基調講演のセキュアサンドボックスは、モデルが生成したコードの実行や、ブラウザ操作を、ホストから隔離する環境です。ホストとは、そのコードを動かしているコンピュータ本体です。説明されているのは、このホストを守ることです。その環境から、どのデータや道具にアクセスしてよいかは、別に設計します。権限と通信を広く許可すると、隔離されていても、できることが増えます。
隔離した環境を扱うときに必要になるのは、コンテナ、クラウド、認証と認可、ログ、自動テスト、例外処理です。AIがアクセスするシステムが増えるほど、これらの設定を読んで、許可する範囲を制限できる人が必要になります。
手順は、できたかを判定できる文で渡す
隔離と制御の次に、仕事の手順をどう渡すかです。ここでいうスキルは、人事の資格ではありません。特定の仕事の手順、判断基準、使う道具をまとめて、エージェントに渡す単位です。
Gemini Enterpriseのアプリでは、Skillsは繰り返し作業を短く呼び出す機能として紹介されています。開発用のADKでは、形が違います。Skills for ADK agentsでは、スキルは手順、資料、道具をまとめた単位です。SKILL.md に名前と説明を書き、本文に手順を書きます。必要なときだけ読み込むので、一度に渡す情報量を抑えられます。ドキュメントでは、この機能は実験的だと書かれています。既定では、エージェントはスキルに書かれた指示どおりに動きます。
営業提案のスキルには、次を書けます。顧客情報を、どのシステムから取るか。情報が矛盾したら、どちらを正とするか。売上では、どの指標を使うか。資料には、どの項目を入れるか。どの段階で、人の確認が必要か。
自然言語で書いても、条件は具体的にします。「重要な顧客を優先する」だけでは、売上なのか、契約期間なのか、これからの伸びなのかが決まりません。指示どおりに動く仕組みでは、この曖昧さが、結果の差として出ます。
書く項目は、目的、条件、例外、禁止、期待する結果です。あとから、できたかどうかを判定できる文にします。ここで必要になるのは、要件定義とソフトウェア工学です。版の管理、レビュー、公開前のテストも、プログラムと同じように行う、というのがこの記事の提案です。ADKのドキュメントが、版管理を必須にしているという意味ではありません。
次のYAMLは、その書き方の見本です。ADKの SKILL.md とは別の、レビュー用の形です。実行はしません。
# 提案資料の条件メモ。製品の設定ファイルではない。
# 実行もしない。曖昧な指示を、判定できる条件に置き換える見本。
name: weekly-proposal
purpose: 来週訪問する顧客1社の、提案資料の下書きを作る
inputs:
customer_id: 必須
visit_date: 必須。YYYY-MM-DD
sources:
order:
- 顧客マスタ
- 直近12か月の売上
- 前回の商談記録
on_conflict: 顧客マスタを正とする。差は注記し、推測で埋めない
metrics:
- 月次売上
- 前年同期比
forbidden:
- 顧客情報の外部送信
- 割引率や契約条件の確定
human_approval:
- 送信の前
- 金額や契約に触れる箇所
done_when:
- 各数値に、システム名と取得日がある
- 必須項目が空でない
- 禁止した操作の記録が0件
「大切な顧客を優先する」だけでは、完了したかどうかを判定できません。上のYAMLのように書くと、足りない項目と、やってはいけない操作を、プログラムでも人でも確認できます。完了条件と、禁止する操作を、同じメモに書きます。
Memory、Projects、Skillsの使い分けは、長いチャットほど答えが雑になる——Context Rotを防ぐMemory・Projects・Skillsの使い分けにあります。上のメモは、そのうち手順を仕様として書く部分だけです。
毎週使う情報は、データとして保存する
条件メモに、業界や資料の形式を毎回書き直すのは手間です。継続して使う情報は、スキルの本文とは分けて保存します。この仕組みを、メモリと呼びます。
人の記憶と同じものとして設計すると、誤りやすくなります。実装では、会話の履歴、データベース、検索、設定ファイルを組み合わせ、必要なときに取り出します。
ADKのMemoryでは、その会話のあいだだけ持つ状態と、会話をまたいで保存する長期の記憶が分かれています。インメモリの実装は、再起動すると消えます。試作向けです。Memory Bankは、会話から要点を取り出し、既存の記憶とまとめて保存し、意味の近さで検索します。要点の取り出しは、LLMが行います。基調講演では、一時的なセッションの代わりに、何か月も前の内容を覚えておける、と説明されています。
要約をモデルに任せると、古い情報や誤った要約が残る可能性があります。組織のルールや担当が変わったとき、過去の記憶をどう直すかも決めておきます。誰がその記憶を見られるかは、アクセス制御で決めます。見られる人は、役割ごとに限られます。
必要な知識は、データベース、データモデリング、検索、更新、削除、履歴です。どの情報を長く保存し、どの情報はそのつど取りに行くかを決めます。条件は、必要な情報を、必要なときに、権限を確認したうえで、信頼できる形で取り出せることです。検索してから答えを作る仕組み（RAG）も、このデータの扱いに含まれます。
誰が、どの権限で操作したかを記録する
記憶を誰が見られるかを決めても、エージェントがデータを更新した理由は、それだけでは分かりません。人が画面を操作するシステムでは、操作した人は利用者です。エージェントは、人の代わりに複数のシステムを読み、ときにはデータを更新します。記録したいのは、利用者に加えて、どのエージェントが、誰の権限で、何を根拠に実行したか、です。
基調講演では、Agent Identityはエージェントごとに暗号的なIDと認可を持たせ、追跡と監査の対象にします。状況が複雑なら、人に助けを求める、ともあります。Agent Gatewayは、エージェントとデータのあいだで、許可する操作の規則を適用します。Model Armorは、プロンプトインジェクション、道具に混ざった不正な指示、機密データの漏えいを検知する、と書かれています。ここまでが、製品の説明にある範囲です。現場の規則を守れるかは、権限と承認の設計で決まります。
プロンプトインジェクションは、参照する文書やページに別の指示を埋め、本来の目的と違う行動をさせる攻撃です。外部の文章を読みながらシステムを操作する構成では、読んだ文章を、実行してよい指示として扱いません。評価に攻撃の例を入れる運用は、攻撃ケースまでEvalsに入れる——間接プロンプトインジェクション防御の運用設計【後編】にあります。
性能が高いことと、広い権限を渡すことは別です。読み取り、更新、外部送信、削除で、許可する操作を分けます。誤った操作が起きたとき、影響が及ぶ範囲を先に小さくします。学ぶ項目は、最小権限、操作の記録、危険な操作の承認、異常が起きたときの停止です。これまでのセキュリティの原則を、エージェントにも適用します。基調講演でも、このプラットフォームはZero Trustを前提にしている、と説明されています。
動いているAIを、止めずに制御する説明は、エージェンティックAI時代のセキュリティは防御から統制へ——「動くAI」を止めずに制御する設計へにあります。
資料の見た目では、数値の正しさは分からない
操作を記録できても、提案資料の数値が正しいとは限りません。プログラムのテストでは、同じ入力なら同じ結果になることを前提にすることが多いです。生成を含む処理では、同じ指示でも、手順や文章が変わることがあります。文章が自然でも、使った売上が古いことや、分析の前提が違うことがあります。最終の資料だけでなく、作業の過程も確認します。
その確認に対応するのが、基調講演の改善機能です。3つに分かれています。Agent Observabilityは、実行の経路と、エージェント、道具、APIの受け渡しを記録します。Agent Simulationは、人が行うような複数回のやり取りを合成し、その流れを試します。Agent Evaluationは、本番の通信を継続的に採点します。この採点の点数と、業務として正しいことは、別に確認します。自然な文章が高い点数でも、数値の出典が正しいとは限りません。
ログを読むときは、次の6つに分けると確認しやすいです。Googleが公式に定めた指標の名前ではありません。
| 観点 | 見ること |
|---|---|
| 完了 | 条件を満たして終わったか |
| 正確さ | 数値と出典が合っているか |
| 安定 | 繰り返しても、許容できる範囲か |
| 安全 | 禁止した操作や、権限外のアクセスがないか |
| 費用と時間 | 処理時間とAPI利用が、業務の範囲か |
| 引き継ぎ | 判断できないとき、止めて人に渡せたか |
モデル自身に「正しい」と言わせて終わらせない、という原則は、「LLMに任せきり」が危ない理由——数学が示す限界と、設計で補う3つの原則にあります。この記事では、記録と採点を、上の6つのどれで読むかを整理します。
コードを書く時間は減っても、読む知識は必要
過程を確認するとき、生成されたコードを読むことになります。単純な実装は、これからさらに自動化されやすいです。自分でコードを書く力と、コードの動作を理解する力は、分けて持っておきます。
たとえば、データ分析のPythonが生成され、実行もできたとします。実行できたことと、分析が正しいことは別です。欠損値をどう扱っているか。集計の範囲は適切か。平均の定義は妥当か。外れ値で結果が偏っていないか。これを判断するには、コードと業務の両方を見る必要があります。性能の問題や脆弱性も、コードの意味が分からないと見逃します。
必要なのは、なぜその処理が必要かを説明できることです。AIに任せすぎると、自分で考える力が弱くなる仕組みは、便利すぎるAIは、なぜ技術者の思考を弱くするのかにあります。この記事で扱うのは、生成された結果を確認するための、プログラミング、アルゴリズム、データ構造、統計です。
モデルの内部を研究する人も必要です。それとは別に、データベース、ネットワーク、セキュリティ、業務システムの専門も必要です。どの専門でも、AIがデータにアクセスし、権限を使い、結果を既存の処理へ返す、という前提で設計します。自分の専門を深めながら、この前提を説明できるようにします。
学ぶときは、3つに分ける
ここまでの6つは、次の順番で学ぶと整理しやすいです。個別の製品の画面はすぐ変わるので、操作手順はその後です。
まず、変わりにくい基礎
プログラミング、アルゴリズム、データベース、ネットワーク、OS、セキュリティ、ソフトウェア工学です。AIが作ったものを読み、問題を見つけ、直すための基礎です。学び始めた人ほど、ツールの操作と同時に、プログラムがどう動くかを確認した方がよいです。遅いSQLを自分で調べた経験があると、生成されたSQLのどこを疑うかが分かります。
次に、AIをシステムにつなぐ
モデルの基本、API、RAG、道具の呼び出し、実行の制御、評価です。呼び出すだけで終わらせず、失敗したときの処理と、出力の確認まで、小さな題材で一通り作ります。社内文書を検索して答える仕組みを作り、回答が参照した資料の文に基づいているかを、別の処理で確認します。集計するエージェントを作るなら、結果を別のプログラムで突き合わせます。この練習で、便利な点と、誤りやすい点の両方が分かります。
最後に、業務の条件を文章にする
何を達成するか。どの条件を満たすか。どの程度の誤りまで許すか。どの判断は人が行うか。技術の知識だけでは整理できません。利用者と話す必要があります。要望の背景を聞く進め方は、「何を作るか」が技術者の価値を決める——コードを書く人から、課題を形にする人へにあります。この記事で行うのは、聞いた条件を、完了条件と禁止事項として書くことです。前のYAMLが、その書き方の見本です。
人がAIと一緒に判断し、責任を持つ力については、「AIが使える」だけでは足りない——Gartnerの予測が示す、これから教育が育てるべき7つの力に書きました。結論は同じです。この記事が扱うのは、仕事をしている技術者が、6つの部品をどの基礎と一緒に学ぶかです。個人の専門性がどう変わるかは、AI時代、IT技術者は何を武器にすればよいのかにあります。
この3つを学ぶとき、デモで動いたことを、そのまま本番の判断には使いません。
デモで完了しても、本番で任せてよいかは別
技術紹介では、複雑な仕事が短時間で終わるデモが多いです。何ができるかを知るには役立ちます。デモと同じデータ、同じ権限、同じ例外が、本番にあるとは限りません。権限、データの品質、例外処理、監査、費用は、デモでは説明されないことが多いです。
たとえば、5,000件を集計できたとします。その件数だけでは、業務の判断に使ってよいかは決まりません。データは正しいか。集計の対象は適切か。出た結論を、判断に使ってよいか。これらは別に確認します。この5,000件は、説明のための数です。調査結果ではありません。
誤った前提のままやり直しを続けると、時間と費用が増え、誤った結果になることもあります。任せる範囲と、人に戻して止める範囲を、両方書きます。能力を低く見積もって使わないのも、高く見積もって条件なしに任せるのも、現場では困ります。測った結果を、利用目的と比べて判断します。
コードの一部、資料作成、集計は、AIが担当しやすくなります。実行を任せても、何を実現するか、どの技術を使うか、どのリスクがあるか、結果をどう評価するか、問題のときどう戻すかは残ります。基礎は、自分でシステムを作るためにも、AIが作ったものを理解して直すためにも必要です。能力が今後どこまで上がるかは、まだ分かりません。職種によって、変わる速さも違います。
何を任せ、何を任せず、どう確かめるか。 この判断には、これまでの基礎と、新しく学ぶ技術の両方が必要です。
最初にやることは、生成された集計コードを1本開くことです。欠損値の扱い、集計の範囲、数値の出典を、自分の言葉で3行書きます。書けない行が、次に学ぶ内容です。プログラミングなら最初の基礎、出典の確認ならシステムのつなぎ方、集計対象の妥当性なら業務の条件です。操作画面の新しい機能を覚えるより、この3行の方が、3つのうちどこから学ぶかを決めやすいです。
作成日: 2026-11-01