G-gen の杉村です。当記事では、Gemini Enterprise に含まれる AI developer tools （AI デベロッパーツール）に関連して、Antigravity の企業での使用方法やクレジット・超過料金、ライセンスの割り当て、セキュリティ・ガバナンスの管理機能、使用状況の分析機能、および Antigravity Enterprise Gateway などについて解説します。 前提知識 Antigravity とは 企業が Antigravity を使用する方法 概要 AI developer tools とは メリット データの保護 対応エディション 請求先アカウント要件 サードパーティモデル クレジット クレジットのプール 消費の仕組み 超過料金と月間支出上限 使用方法 ライセンスの配布とユーザーへの割り当て Google Cloud プロジェクト側の設定 必要な API の有効化 必要な IAM ロールの付与 AI developer tools の有効化 ユーザー側での認証 管理機能 設定画面の概要 セキュリティ コマンド実行に関する設定項目 ブラウザアクセスに関する設定項目 MCP に関する設定項目 コンプライアンス 機能 モデルの提供 分析 デベロッパーツールの指標 ログのクエリ サードパーティモデルのトークン使用量の追跡 Antigravity Enterprise Gateway 概要とアーキテクチャ 仕組み クレジットは使用不可 技術要件 前提知識 Antigravity とは Google Antigravity （以下、Antigravity）とは、Google が提供する、自律型 AI エージェントを用いて AI ネイティブなソフトウェア開発を行うための開発者向けツール群です。デスクトップアプリケーションとして提供される Antigravity 2.0 や、コマンドラインツールの Antigravity CLI（ agy ）、既存の統合開発環境（IDE）に導入して使用する Antigravity for IDEs などから構成されています。 開発者は Antigravity を用いることで、単なるコード補完にとどまらず、複数の AI エージェントにタスクを委譲し、コードベースの調査、実装計画の策定、複数ファイルにまたがるコード生成、ターミナルコマンドの実行、ブラウザを用いたテストや検証までを一貫して進めることができます。 参考 : Google Antigravity Antigravity 2.0 の画面 Antigravity に関するその他の解説記事については、以下のカテゴリ一覧も参照してください。 blog.g-gen.co.jp 企業が Antigravity を使用する方法 企業が Antigravity を使用するにあたり適切な方法として、以下の2つが挙げられます。 Google Cloud プロジェクトを指定して使用する（従量課金） Gemini Enterprise に付帯する AI developer tools 経由で使用する（クレジット + 従量課金） いずれの場合でも、入出力データがモデルのトレーニングに使用されないなどのデータ保護は適用されますが、後者の場合では、さまざまな管理機能が提供されます。当記事では後者の AI developer tools を解説しています。 概要 AI developer tools とは AI developer tools （Google Cloud コンソールの日本語表記では AI デベロッパー ツール ）とは、Gemini Enterprise に統合された、企業の開発者向けに AI コーディングツールを提供・統制するための機能群です。 なお Gemini Enterprise とは、企業向けの AI アシスタント Web アプリであり、Google Workspace や Microsoft 365、Box といった外部データソースと連携して様々な AI タスクを実行できます。Gemini Enterprise 全体の概要については、以下の記事を参照してください。 blog.g-gen.co.jp Gemini Enterprise の AI developer tools には以下の開発ツールが含まれています。 ツール 概要 対応環境・対象ツール Google Antigravity 自律型 AI エージェントを中核とした AI 搭載の開発環境 Antigravity アプリ、Antigravity CLI（ agy ） Antigravity for IDEs 開発者が日常的に使用する既存の IDE に AI エージェント機能を統合する拡張機能 Visual Studio Code、Visual Studio、JetBrains IDEs（IntelliJ IDEA、PyCharm、WebStorm、GoLand 等）、Zed、Xcode Android Studio Android アプリケーション開発向けの統合開発環境における AI 機能 Android Studio（最新の安定版） メリット 企業が Antigravity を使用するにあたっては、Gemini Enterprise を使わずに、単純に Google Cloud プロジェクトを指定して Gemini Enterprise Agent Platform（旧称 Vertex AI。以下、 Agent Platform ）の API 経由で従量課金で使用する方法もあります。 しかし、Gemini Enterprise のサブスクリプションを購入し、AI developer tools を通じて開発者に Antigravity 環境を提供することで、以下の2つの大きなメリットが得られます。 1. 付帯クレジットによるサブスクリプション形式での使用 Gemini Enterprise のライセンス数に応じた月間クレジットがプロジェクトにプールされ、一定量の範囲内であれば追加の従量課金なしで Antigravity 等を使用できる。 2. エンタープライズ向けの統合管理・ガバナンス機能の適用 ファイルアクセスやターミナル実行、外部 Web アクセス、Model Context Protocol（以下、MCP）サーバーの制限、プロンプト・メタデータのロギング、使用可能な AI モデルの制限、使用状況の指標（メトリクス）の可視化など、組織のセキュリティ基準に合わせた統制を一元的に適用できる。 データの保護 Gemini Enterprise の AI developer tools を介して Antigravity 等を使用する場合、および Gemini Enterprise（AI developer tools）を使わずに Google Cloud プロジェクトを指定して Agent Platform 経由の従量課金で使用する場合のいずれにおいても、Google Cloud のデータガバナンスおよび AI/ML プライバシーコミットメントが適用され、データは保護されます。 開発者が送信したプロンプトやソースコードのコンテキスト、および AI が生成したレスポンスが、Google の基盤モデルやサードパーティモデル（Anthropic Claude 等）の学習（トレーニング）やファインチューニングに使用されることはありません。また、後述する AI developer tools の管理機能で「プロンプトとレスポンスのロギング」を有効化した場合でも、記録されたデータは組織自身の Google Cloud プロジェクト内（Cloud Logging）にのみ保存され、Google によるモデルの学習や人間によるレビューには使用されません。 なお、AI developer tools におけるデータの処理ロケーション（データレジデンシー）やコンプライアンス認証に関しては、以下の仕様・制限事項がある点に留意してください。 項目 内容 モデルの処理ロケーション サードパーティモデル（Claude）の推論は global 、 us 、 eu ロケーションで処理され、国内の単一リージョン（ asia-northeast1 等）には対応していない。また、プレビューモデルおよび画像生成モデル（Gemini 3 Pro Image）は global リージョンのみで提供 コンプライアンス認証の対象外項目 Gemini Enterprise の Antigravity は Access Transparency（AXT）、ISO 27001 / 42001、SOC 1 / 2 / 3、FedRAMP、ITAR などの一部のコンプライアンス認証およびセキュリティ制御の対象外 参考 : How Gemini products in Google Cloud use your data 参考 : Gemini Enterprise Agent Platform and zero data retention 参考 : Configure AI developer tools settings - Key considerations before configuring models 参考 : AI developer tools overview - Compliance limitations 対応エディション Gemini Enterprise で AI developer tools を使用するには、以下のいずれかのエディションを使用する必要があります。 Gemini Enterprise Standard エディション Gemini Enterprise Plus エディション Gemini Enterprise Pay-as-you-go エディション Gemini Enterprise Standard Emerging Market エディション 請求先アカウント要件 Gemini Enterprise で AI developer tools を使用するには、対象の Google Cloud プロジェクトが 請求書発行の Cloud Billing アカウント （Invoiced Cloud Billing account）にリンクされている必要があります。 クレジットカード払いの請求先アカウントでは、AI developer tools を使用できません。請求書払いの請求先アカウントを発行するには、以下のような選択肢があります。 Google に直接申し込む（審査あり） G-gen 社等の Google Cloud 販売パートナーに申し込む 請求書への切り替えを Google に直接申請する場合は、以下のような条件が課されることが公式ドキュメントに記載されています。 会社を登記してから1年以上経過していること Google Cloud 料金が年間 $40,000 以上になることが予測されること 上記は一例であり、他にも条件が課される場合があるとされています。 参考 : Cloud Billing の概要 - Cloud 請求先アカウントの種類 参考 : 毎月の請求書発行を申し込む 一方で、販売パートナー経由の場合は、上記よりもハードルが低いことが一般的であるほか、割引や特典等も付帯している場合があります。 参考 : Google Cloud 請求代行 - 株式会社G-gen（ジージェン） サードパーティモデル AI developer tools を使用すると、Antigravity で Claude Opus 5.5 や Claude Sonnet 5.5 などのサードパーティモデルを使用できます。 参考 : Configure AI developer tools settings - Supported models ただし、サードパーティモデルは Gemini Enterprise の付帯クレジットプールの 対象外 です。すべての使用量が従量課金モデルで課金されます。よってこれらのモデルを使用するには超過料金の有効化が必須です。なお、無償トライアルライセンスでは超過料金を有効化できません。 なお、Antigravity で Claude モデルをメインの推論・コーディングモデルとして選択している場合でも、Antigravity はコンテキスト処理や要約などのバックグラウンドタスクには軽量な Gemini モデルを使用し、画像生成タスクには Gemini 3 Pro Image を使用するハイブリッド実行アーキテクチャを採用しています。そのため、Claude 使用時にもバックグラウンドの Gemini モデルの消費が発生する点に留意してください。 参考 : Configure AI developer tools settings - Key considerations before configuring models 参考 : Quotas and overages - Overages クレジット クレジットのプール Gemini Enterprise の Standard または Plus エディションのサブスクリプションを購入して Google Cloud プロジェクトに紐付けると、ライセンス数（シート数とも呼称）に応じた AI コーディングツール用のクレジットが Google Cloud プロジェクトにプールされます。このクレジットは、Google Antigravity、Antigravity for IDEs、および Android Studio で共通して消費されます。 エディションごとの付与クレジットと課金形態は以下のとおりです。 エディション 1ライセンスあたりの月間クレジット Gemini Enterprise Standard $10/ユーザー/月 Gemini Enterprise Plus $15/ユーザー/月 クレジットを使い切った場合、それ以降は Agent Platform の従量課金レートで請求されます。これを 超過料金 （Overages）といいます。超過料金をオフにして、クレジットを使い切った以降は使用を停止させることも可能です。なお超過料金を有効化するには、無償トライアルではない、有償のサブスクリプションが必要です。 一方で Standard Emerging Market や Pay-as-you-go エディションにはクレジットが付帯せず、すべての使用量が Agent Platform の従量課金レートで請求されます。 消費の仕組み クレジットプールの計算と消費においては、以下のルールが適用されます。 1. プロジェクト・エディション・ロケーション単位での共有 プールされたクレジットは、同一の Google Cloud プロジェクト、エディション、およびロケーションを指定してツールを使用するすべてのライセンス保有ユーザー間で共有（シェア）されます。 2. 7日間ローリングウィンドウによる上限適用 月間クレジットは1か月分が一度に解放されるのではなく、 7日間単位 で割り当て上限が計算・適用されます。1週間あたりの組織全体のプール量は、 (1ユーザーあたりの月間クレジット ÷ 4) × プロジェクトの総ライセンス数 の計算式で算出されます。たとえば、Gemini Enterprise Standard を50ライセンス保有するプロジェクトの場合、月間総額は 50 × $10 = $500 であり、7日間あたりの上限は ($10 ÷ 4) × 50 = $125 となります。 3. ローリングウィンドウの起点と繰り越し不可 7日間のカウントは、組織内のユーザーが最初のプロンプトまたはリクエストを送信した時点から開始されます。7日間の期間内に使い切らなかったクレジットは翌週には繰り越されず、リセットされます。 なお、週あたりの使用量の現在の費消状況は、Google Cloud コンソールの「Gemini Enterprise > 使用状況と費用」で対象エディション（Gemini Enterprise Standard 等）を選択することで確認できます。 参考 : Quotas and overages 週ごとのクレジット費消状況の確認 超過料金と月間支出上限 超過料金 （Overages）を有効化すると、クレジットを使い切った場合でも、それ以降は Agent Platform の従量課金レートで課金され、ツールの使用を継続できます。無効にすると、クレジットを使い切った時点で、ツールの使用は停止されます。 超過料金の有効化、および予期せぬ高額課金を防ぐための月間支出上限（Monthly spend limit）の設定は、エディション（ティア）ごとに行います。 Google Cloud コンソールで「Gemini Enterprise > 使用状況と費用」に遷移 「使用」タブに遷移 複数のエディションを契約している場合は、「別の階層を選択」リストから対象のエディションを選択 「割り当て超過時の従量課金制利用」ブロックの「ステータス」トグルスイッチを有効化 「変更を保存」ボタンを押下 超過料金（Overages）の有効化 参考 : Configure overages あわせて、従量課金による支出額にキャップ（上限）を設けたい場合は、同じ画面の「プロジェクトにおける 1 か月の費用の上限」セクションで上限額を設定できます。 「上限を設定」をクリックする 請求先アカウントの管理画面に遷移するので予算アラートまたは Spend cap を設定 設定手順の詳細は省略しますが、 Vertex AI (aiplatform.googleapis.com) サービスをスコープとした Spend cap（予算上限）を構成することで、上限に達したときに使用を停止できます。この上限額は、AI developer tools（Antigravity）だけでなく、同一プロジェクト内の Gemini Enterprise アプリや Agent Platform の従量課金支出の合計に対して適用される点に注意してください。 以下の記事も参考にしてください。 blog.g-gen.co.jp 使用方法 ライセンスの配布とユーザーへの割り当て AI developer tools の付帯クレジットを使用するには、対象の Google Cloud プロジェクトにサブスクリプションのライセンスが配布されており、かつ各開発者の Google アカウントに Gemini Enterprise のライセンス が割り当てられている必要があります。 参考 : Get subscriptions and assign licenses for Gemini Enterprise 1. プロジェクトへのライセンス配布の確認 Google Cloud コンソールの「Gemini Enterprise > サブスクリプションを管理」画面で、購入したサブスクリプションのライセンスが、AI developer tools の窓口とする Google Cloud プロジェクトに配布されていることを確認します。必要に応じて「ライセンスを配布」から対象プロジェクトへの割り当て数を調整します。 2. ユーザーへのライセンス割り当て ライセンスが配布された Google Cloud プロジェクトにおいて、以下の手順で開発者にライセンスを割り当てます。 Google Cloud コンソールで対象プロジェクトを選択し、「Gemini Enterprise > ユーザーの管理」に遷移する 「ライセンスを追加」等から、対象ユーザーのメールアドレスに対して Gemini Enterprise ライセンスを明示的に割り当てる（または「ライセンスを自動的に割り当てる」を有効化し、ユーザーの初回ログイン時に自動付与させる） ユーザーのメールアドレスにライセンスを割り当てる Google Cloud プロジェクト側の設定 必要な API の有効化 ライセンスの割り当てに加えて、Google Cloud プロジェクト側で API の有効化、IAM ロールの付与、および AI developer tools のトグルスイッチを有効化する必要があります。 対象の Google Cloud プロジェクトで、以下の2つの API が有効化されている必要があります。 Discovery Engine API（ discoveryengine.googleapis.com ） Business AI Code API（ businessaicode.googleapis.com ） なお、Google Cloud コンソールから AI developer tools の設定トグルスイッチを有効化すると、これらの API は自動的に有効化されます。ただし、新規に Gemini Enterprise のサブスクリプションを購入する際は、プロビジョニングの失敗を防ぐため、 サブスクリプション購入の少なくとも5分前までに 両 API を有効化しておくことが推奨されています。 必要な IAM ロールの付与 AI developer tools の管理および使用には、以下の IAM ロールを使用します。 管理者向け ロール表示名 ロール ID 役割と注意点 Gemini Enterprise 管理者 roles/discoveryengine.agentspaceAdmin AI developer tools の設定変更および指標ダッシュボードの閲覧が可能。ただしこのロールだけではツール自体（Antigravity 等）を使用することはできない 利用者（開発者）向け ロール表示名 ロール ID 役割と注意点 Gemini Enterprise ユーザー roles/discoveryengine.agentspaceUser Antigravity 等の AI developer tools にアクセスして使用するために必須。管理者自身がツールを使用する場合も、このロールを併せて付与する必要がある もし「Gemini Enterprise の Web アプリは使用させたいが、Antigravity などの AI developer tools の使用は禁止したい」という特定のライセンス保有ユーザーがいる場合は、 roles/discoveryengine.agentspaceUser をベースにカスタムロールを作成し、 businessaicode. で始まるすべての権限（ businessaicode.* ）を除外して付与することで、AI developer tools へのアクセスのみを制限できます。 参考 : Restrict user access with custom roles AI developer tools の有効化 対応ロケーションにおける新規サブスクリプションでは AI developer tools はデフォルトで有効になっていますが、既存のサブスクリプションでは手動で有効化する必要があります。 Google Cloud コンソールで「Gemini Enterprise > 設定」に遷移する 「AI デベロッパー ツール」タブを開く 画面上部の「 AI デベロッパー ツール 」のトグルスイッチを有効化 AI developer tools の有効化トグルスイッチ ユーザー側での認証 前述の設定が完了したあと、開発者は手元の Antigravity アプリや Antigravity CLI、IDE 拡張機能において、個人の Google アカウント認証ではなく Google Cloud プロジェクトを指定する認証方式 を選択します。 設定を行った Google Cloud プロジェクトのプロジェクト ID を指定してログインすることで、AI developer tools 経由で Antigravity の使用を開始できます。 以降は、2026年10月現在の Antigravity の認証画面です。 まず、Continue with Google Cloud を選択します。 Continue with Google Cloud を選択 すると Web ブラウザで、Google アカウントでの認証画面がポップアップします。Gemini Enterprise のライセンスが割り当てられているユーザーアカウントでログインします。 Gemini Enterprise ライセンスを持つアカウントでログイン Antigravity からの使用であることを確認 認証が完了すると、Antigravity の画面が切り替わります。左上の「Gemini Enterprise」を選択すると、自分が Gemini Enterprise ライセンスを割り当てられている Google Cloud プロジェクトが表示されます。正しいプロジェクトを選択して、Next ボタンを押下します。これで、ログインが完了します。 Gemini Enterprise > プロジェクトを指定して Next を押下 管理機能 設定画面の概要 Gemini Enterprise 管理者（ roles/discoveryengine.agentspaceAdmin ）ロールを持つ管理者は、Google Cloud コンソールの「Gemini Enterprise > 設定 > AI デベロッパー ツール」画面から、組織内の開発者が使用する AI developer tools の動作やセキュリティポリシーを一元的に構成・統制できます。 参考 : Configure AI developer tools settings 設定項目は大きく以下の4つのカテゴリに分かれています。 カテゴリ名 概要 セキュリティ （Security） ファイルアクセス、ターミナル自動実行、サンドボックス、外部 Web アクセス、および MCP サーバーの制御 コンプライアンス （Compliance） プロンプト・レスポンスのロギング、およびメタデータのロギング 機能 （Features） /boost や /teamwork-preview といった高度なマルチエージェント機能の有効化・無効化 モデルの提供 （Model availability） 開発者が使用できる Google モデルおよびパートナーモデルの制限 設定画面 セキュリティ コマンド実行に関する設定項目 Antigravity による意図しないコマンド実行等を防ぐために、コマンド実行を必ず「要審査」にしたり、あるいはサンドボックス内部に限定するといった統制が可能です。 管理者側でコマンド実行を「要審査」にすると、ユーザー側の設定に関わらず管理者側の設定が優先され、Antigravity はコマンド実行のたびに、ユーザーの許可を得るようになります。 詳細な設定項目は、以下のとおりです。 設定項目 概要 選択可能なオプション ファイル アクセス ポリシーの外部 （Outside of file access policy） プロジェクトのワークスペース外にあるファイルへのアクセスを制御する ・ 許可しない : ワークスペース外のファイルへのアクセスを禁止する ・ 常に確認する : アクセス前にユーザーへ承認を求めるプロンプトを表示する ・ 許可 : ワークスペース外のファイルへのアクセスを自動的に許可する ターミナル自動実行モード （Terminal auto-execution mode） エージェントがターミナルコマンドを自動実行する際の動作を制御する ・ 要審査 : コマンド実行前に毎回ユーザーの承認を求める ・ サンドボックスで続行 : サンドボックス内でのみ自動実行を許可する（「サンドボックス モード」が有効な場合のみ選択可能） ・ 常に続行 : すべてのコマンドを自動的に実行する サンドボックス モード （Sandbox mode） ターミナルの実行をファイルシステムおよびネットワークから隔離されたサンドボックス環境内に制限するかどうかを制御する ・ 無効 / 有効 なお、ターミナル自動実行モードを「常に続行」にして、無制限の自動実行を許可した際に考えられるリスクとして、以下のようなものが挙げられます。以下を十分に理解し、開発のスピード感と、セキュリティのトレードオフを考慮する必要があります。 誤操作やハルシネーションによる破壊的コマンドの実行 AI エージェントの判断ミスにより、 rm -rf 等によるローカルファイルの削除や、 gcloud 、 terraform 、 kubectl 等の CLI ツールを介したクラウドリソース・データベースの意図しない変更・削除が、人間の事前確認なしに実行されてしまうリスクがあります。 プロンプトインジェクションによる情報漏洩・不正コード実行 外部の Web ページやリポジトリ内のファイル、MCP サーバーのレスポンスなどに悪意ある指示が埋め込まれていた場合（間接的プロンプトインジェクション）、開発者端末内の認証情報（環境変数、SSH 秘密鍵、クラウドのクレデンシャル等）を外部へ送信するコマンドや、不正なスクリプトをダウンロード・実行するコマンドが自動的に実行されてしまうリスクがあります。 ブラウザアクセスに関する設定項目 以下の項目では、Antigravity のエージェントがブラウザ（ /browser エージェント等）を介して外部の Web サイトにアクセスする機能や、ブラウザ上での JavaScript 実行を制御します。 設定項目 概要 選択可能なオプション ブラウザ アクセス （Browser access） エージェントがブラウザを使用して Web コンテンツの閲覧や操作を行えるようにするかどうかを制御する ・ 無効 / 有効 許可されている URL （Allowed URLs） ブラウザアクセスが有効な場合に、エージェントがアクセスできる URL の許可リストを指定する。設定は Antigravity 内の /browser エージェントに適用される リストで指定 ブラウザ JavaScript 自動実行モード （Browser JavaScript auto-execution mode） Web ベースの高度なコーディングやテストタスクのために、エージェントがブラウザ上で JavaScript を実行できるかどうかを制御する ・ 無効 : JavaScript の実行を禁止する ・ 審査をリクエスト : 実行前にユーザーの承認を求める ・ 許可 : 自動的に JavaScript を実行できるようにする MCP に関する設定項目 以下の項目では、AI エージェントからの MCP サーバー使用可否と、許可するサーバーのリスト（JSON 形式）を構成できます。 設定項目 概要 選択可能なオプション MCP サーバー （MCP servers） 開発者がカスタムまたはサードパーティの MCP サーバーに接続して使用できるかどうかを制御する ・ 無効 / 有効 許可されたサーバー構成 （Allowed server configuration） 「MCP サーバー」が有効な場合に、接続を許可するローカルおよびリモートの MCP サーバーを JSON 形式で定義する JSON 形式で入力 「許可されたサーバー構成」では、以下のようにローカルでプロセスとして起動する local_servers （ id 、 command 、 args を指定）と、HTTP/SSE 等で接続する remote_servers （ id 、 url を指定）を JSON で定義します。 { " mcpServers ": { " local_servers ": [ { " id ": " gopls-mcp-server ", " command ": " go ", " args ": [ " run ", " golang.org/x/tools/gopls@latest ", " mcp " ] } ] , " remote_servers ": [ { " id ": " bigquery " } , { " id ": " custom-remote-server ", " url ": " https://mcp.example.com/mcp " } ] } } コンプライアンス コンプライアンス のセクションでは、監査や使用状況の分析のために、開発者と AI エージェントのやり取りや推論メタデータを組織の Google Cloud プロジェクト内の Cloud Logging に記録するかどうかを設定します。 セキュリティ監査や、ユーザー・モデル別の詳細なトークン消費分析を行いたい場合は、これらのロギング設定を有効化します。 設定項目 概要 選択可能なオプション プロンプトとレスポンスのロギング （Prompts and responses logging） 開発者が送信したプロンプトと、AI が生成したレスポンスの本文を組織のプロジェクト内に記録する。記録されたデータは組織のプロジェクト内に留まり、Google によるモデルの学習や人間によるレビューには使用されない ・ 無効 / 有効 メタデータのロギング （Metadata logging） トークン消費量やモデル名、ユーザー識別子などのプロダクトメタデータを Cloud Logging に出力する。後述するサードパーティモデルのトークン使用量の追跡にも使用される ・ 無効 / 有効 Cloud Logging に出力されたこれらのログは、Google Cloud コンソールの「ロギング > ログ エクスプローラ」からクエリを実行して検索・確認できます。クエリの書き方については、後述の「分析」で解説します。 機能 機能 （Features）のセクションでは、Antigravity で提供される高度なマルチエージェント機能の有効・無効を組織単位で切り替えられます。これらの設定を反映させるには、開発者側で Antigravity アプリ バージョン 2.18.0 以降 、または Antigravity CLI バージョン 1.2.10 以降 を使用している必要があります。 なお2026年10月現在、日本語版の Google Cloud コンソールでは、Features が「特徴量」と誤訳されていますが、「機能」とするのが正しいものと考えられます。 設定項目 概要 選択可能なオプション /boost コマンド （ /boost command） 複雑なアルゴリズムの課題や深いデバッグ作業など、高度な思考・計画・検証が求められるタスクに対して、階層化されたマルチエージェント構成を動員する /boost コマンドの使用を許可する ・ 無効 / 有効 /teamwork-preview コマンド （ /teamwork-preview command） 大規模・長期間にわたるプロジェクトにおいて、複数の自律型サブエージェントが協調して作業を進めるフレームワークである /teamwork-preview コマンド（Preview）の使用を許可する ・ 無効 / 有効 これらの機能は問題解決能力を大きく高める一方で、複数のサブエージェントが並列・階層的に推論を行うため、通常のチャットに比べてトークンおよびクレジットの消費量が多くなります。クレジットプールの消費ペースを抑えたい場合は、管理画面から無効化することも検討できます。 モデルの提供 モデルの提供 のセクションでは、開発者が Antigravity 内で選択・使用できる AI モデル（Google モデルおよびパートナーモデル）を管理します。 Antigravity の承認済みモデル （Antigravity authorized models）という項目では、開発者が Antigravity 内で使用できる Google 製モデルを制限できます。デフォルト（リストが空の状態）では、サポートされているすべての Google 製モデルの使用が許可され、将来新しい Google モデルが追加された際も自動的に有効化されます。モデルを明示的に選択した場合は、チェックを入れたモデルのみが使用可能となります。また、モデルごとに使用可能な思考量（Low / Medium / High）を選択できます。 Google モデルと思考量を選択可能 Google 以外のモデル （Non-Google models）という項目では、サードパーティのパートナーモデル（Anthropic Claude 等）の使用をオプトインで許可できます。使用を許可するモデルを選択し、サービス規約（Terms of Service）に同意して有効化します。また前述のとおり、超過料金の有効化が必要です。なお、Google 製モデルとは異なり、サードパーティモデル（Claude Opus 5.5 や Claude Sonnet 5.5）を有効化すると、そのモデルのすべての思考量（Low / Medium / High / Max）が開発者に開放され、管理者が個別の思考量を制限することはできません。 サードパーティモデルを選択可能 分析 デベロッパーツールの指標 Gemini Enterprise 管理者（ roles/discoveryengine.agentspaceAdmin ）ロールを持つ管理者は、Google Cloud コンソールの「Gemini Enterprise > デベロッパー ツールの指標」画面から、組織内における AI developer tools の利用状況、すなわち、アクティブユーザー数、トークン消費量、API 呼び出し数、ツール実行数などをモニタリングできます。 参考 : View AI developer tools metrics デベロッパーツールの指標 なおダッシュボードには、ユーザーのアクティビティが5〜15分以内程度で反映されます。 「デベロッパー ツールの指標」ダッシュボードで確認できる指標は、 Active Users (Adoption) と Tools & API calls の2つの大きなセクションで構成されています。 1. Active Users (Adoption) 選択した期間における平均値を示すスコアカードと、時系列の推移を示す折れ線グラフの両方が表示されます。 指標名 概要 Hourly active users (average) 1時間あたりに AI developer tools を使用したユニークユーザー数 Daily active users (average) 1日あたりに AI developer tools を使用したユニークユーザー数 Weekly active users (average) 7日間あたりに AI developer tools を使用したユニークユーザー数 Monthly active users (average) 28日間あたりに AI developer tools を使用したユニークユーザー数 2. Tools & API calls トークン消費量やエージェントによるツール呼び出し、API リクエストの成功・失敗の推移を確認できます。 指標名 概要 Total Tokens 選択した期間内にすべてのモデルおよびリクエストで消費された合計トークン数（スコアカード表示） Daily Token Usage 1日あたりのトークン消費量の推移 Daily API Calls 1日あたりのバックエンド API 呼び出し回数の推移。正常なリクエストと失敗したリクエストが error_type ラベル別に分類して表示されるため、クォータ超過や認証エラーなどのトラブルシューティングに役立つ Daily Tool Calls ファイル検索、コード編集、ターミナル実行など、AI エージェントが開発タスク中にトリガーした1日あたりのツール呼び出し回数 Daily Tool Calls Accepted エージェントが提案したツール呼び出しやコード変更のうち、開発者が承認（Accept）した1日あたりの回数。開発者がどの程度 AI の提案を採用しているかを測る指標となる ログのクエリ 前述の管理機能（コンプライアンス設定）でロギングを有効化すると、組織の Google Cloud プロジェクト内の Cloud Logging に以下のログが出力されます。 プロンプトとレスポンスのロギング を有効化した場合、開発者が送信したプロンプトやコンテキスト情報が businessaicode.googleapis.com/inference_request に出力されます。また、AI モデルが生成したレスポンス本文が businessaicode.googleapis.com/inference_response に出力されます。 メタデータのロギング を有効化した場合、各推論リクエストの完了時に、 businessaicode.googleapis.com/inference_response というログ名で InferenceResponseLog エントリが出力され、モデル名やユーザー識別子（ labels ）およびトークン消費量（ jsonPayload.metadata ）が記録されます。メタデータのロギングのみを有効化している場合は、プロンプトやレスポンスの本文は記録されません。 ログ businessaicode.googleapis.com/inference_response には、以下のラベルおよびメタデータフィールドが含まれます。 labels フィールド フィールド名 概要 model 使用されたモデル識別子（ claude-sonnet-5-5 、 claude-opus-5-5 など） model_provider モデルのプロバイダ名（ Anthropic 、 Google など） client_name 呼び出し元のクライアントツール名（ antigravity_cli など） user_id リクエストを実行した認証済みユーザーの識別子（ user:developer@example.com など） trajectory_id / request_id エージェントのタスク履歴（トラジェクトリ）および個別リクエストの追跡用 ID（通常、1回のユーザーターンで1つの trajectory_id の下に複数の request_id が紐づく） jsonPayload.metadata フィールド フィールド名 概要 promptTokenCount 入力プロンプトの合計トークン数（キャッシュから提供されたトークン数を含む） cachedContentTokenCount promptTokenCount のうち、プロンプトキャッシュからヒットしたトークン数（内数）。値が 0 の場合はフィールド自体が省略される。すでに promptTokenCount や totalTokenCount に含まれているため、コスト試算や集計時に重複加算しないよう注意 candidatesTokenCount モデルが生成した出力レスポンスのトークン数 thoughtsTokenCount モデルの内部思考（Thinking）で消費されたトークン数。なお、Anthropic モデルではこのフィールドは出力されない（省略される） totalTokenCount リクエスト全体の合計トークン数。 promptTokenCount + candidatesTokenCount （および出力される場合は thoughtsTokenCount ）の合計と一致する 以下は、Google Cloud コンソールの「ロギング > ログ エクスプローラ」でプロンプトとレスポンスのログを検索するクエリ例です。 PROJECT_ID は、対象のプロジェクト ID に置き換えてください。 logName=( " projects/PROJECT_ID/logs/businessaicode.googleapis.com%2Finference_request " OR " projects/PROJECT_ID/logs/businessaicode.googleapis.com%2Finference_response " ) また各ログに付与される labels.request_id や labels.trajectory_id を条件に加えることで、特定の推論リクエストや一連の会話セッションにおけるプロンプトとレスポンスを紐づけて追跡できます。 さらに、特定のモデルプロバイダ（ Google や Anthropic ）や特定のユーザーの推論レスポンスログに絞り込みたい場合は、 labels フィールドの条件を追加してクエリを実行します。 logName= " projects/PROJECT_ID/logs/businessaicode.googleapis.com%2Finference_response " labels.model_provider= " Anthropic " labels.user_id= " user:developer@example.com " サードパーティモデルのトークン使用量の追跡 特に Anthropic Claude などのサードパーティモデルは従量課金で請求されるため、前述の「 メタデータのロギング 」を有効化したうえで、Cloud Logging の _Default ログバケットで Log Analytics （Google Cloud コンソール上のメニュー表記では Observability Analytics / オブザーバビリティ分析 ）を有効化しておくことで、SQL クエリを用いてモデル別・日別・ユーザー別のトークン消費量を正確に集計できます。なお Log Analytics とは、Cloud Logging ログバケットに格納されているログに対して SQL でクエリできる機能であり、ログバケットごとに有効化します。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - G-gen Tech Blog - Log Analytics たとえば、「ロギング > オブザーバビリティ分析（Log Analytics）」画面で、過去7日間におけるサードパーティモデル（Anthropic）のモデル別・日別のトークン消費量を集計する SQL クエリは以下のとおりです。 SELECT TIMESTAMP_TRUNC( timestamp , DAY) AS usage_date, JSON_VALUE(labels.model) AS model_name, COUNT (*) AS request_count, SUM (SAFE_CAST(JSON_VALUE(json_payload.metadata.promptTokenCount) AS INT64)) AS prompt_tokens, IFNULL( SUM (SAFE_CAST(JSON_VALUE(json_payload.metadata.cachedContentTokenCount) AS INT64)), 0 ) AS cached_tokens, SUM (SAFE_CAST(JSON_VALUE(json_payload.metadata.candidatesTokenCount) AS INT64)) AS output_tokens, IFNULL( SUM (SAFE_CAST(JSON_VALUE(json_payload.metadata.thoughtsTokenCount) AS INT64)), 0 ) AS thoughts_tokens, SUM (SAFE_CAST(JSON_VALUE(json_payload.metadata.totalTokenCount) AS INT64)) AS total_tokens FROM `PROJECT_ID.global._Default._Default` WHERE log_id = ' businessaicode.googleapis.com/inference_response ' AND JSON_VALUE(labels.model_provider) = ' Anthropic ' AND timestamp >= TIMESTAMP_SUB( CURRENT_TIMESTAMP (), INTERVAL 7 DAY) GROUP BY usage_date, model_name ORDER BY usage_date DESC , total_tokens DESC クエリを実行する際は、以下の点に留意してください。 項目 内容 参照先のログビューと権限 FROM 句で指定している `PROJECT_ID.global._Default._Default` ビューは、標準のログ閲覧者（ roles/logging.viewer ）ロールでクエリを実行できる。 _Default._AllLogs ビューに対してクエリを実行する場合は、プライベート ログ閲覧者（ roles/logging.privateLogViewer ）またはログビュー アクセサー（ roles/logging.viewAccessor ）ロールが必要 省略されるフィールドの扱い 前述のとおり、 cachedContentTokenCount はキャッシュヒットが 0 の場合に省略され、 thoughtsTokenCount は Anthropic モデルでは省略されるため、SQL では SAFE_CAST と IFNULL(..., 0) を組み合わせて集計している キャッシュトークンの内数扱い cached_tokens （ cachedContentTokenCount ）は prompt_tokens （ promptTokenCount ）に含まれる内数であるため、トークン単価からコストを試算する際は二重計上しないよう注意が必要 また、 GROUP BY 句に JSON_VALUE(labels.user_id) を追加すれば、どの開発者がどの程度サードパーティモデルのトークンを消費しているかをランキング形式で把握できます。これらのクエリ結果は、そのまま Cloud Monitoring のカスタムダッシュボードにチャートとしてピン留めしたり、ログベースの指標（Log-based metrics）を作成して予算管理用のアラートを設定したりできます。 参考 : Track token usage for third-party models Antigravity Enterprise Gateway 概要とアーキテクチャ 金融機関や公共機関をはじめとする厳しい規制要件を持つエンタープライズ組織では、開発者のワークステーションから外部インターネット上の Google サービスへ直接接続させることや、ブラウザを用いた対話型の Google アカウントログインを行わせることがセキュリティポリシー上制限されているケースがあります。 Antigravity Enterprise Gateway は、このような厳格なネットワーク統制環境において、開発者のワークステーションからの Antigravity トラフィックを、組織が管理・運用するプロキシを経由して Google Cloud へルーティングするための認証ゲートウェイです。 ただし、Antigravity Enterprise Gateway は Google Cloud コンソールの設定のみで完結するマネージド機能 ではなく 、管理者自身がリバースプロキシ（API ゲートウェイ）を構築・運用し、開発者端末の通信をそこへルーティングする必要があります。 参考 : Deploy Google Antigravity Enterprise Gateway 仕組み Antigravity Enterprise Gateway を構成した場合の通信・認証・課金の仕組みは以下のとおりです。 1. API キーによるユーザー認証 開発者のワークステーションは Google に直接接続せず、組織内のエンタープライズゲートウェイに接続する。認証にはゲートウェイが発行した API キー（ Authorization: Bearer GATEWAY_API_KEY ）を使用するため、ユーザー側で対話型の Google アカウントログインを行う必要がない。 2. 一元化されたサービスアカウントによる Google Cloud 認証 エンタープライズゲートウェイは、受信したリクエストの認証ヘッダーを検証したうえで、一元管理された Google Cloud サービスアカウント（ roles/aiplatform.user ロールを保持）のアクセストークンに差し替えて、Agent Platform（ aiplatform.googleapis.com ）へリクエストを転送する。 3. クライアント属性ヘッダーの保持による契約認識 Antigravity クライアントは、リクエストに User-Agent や X-Goog-Api-Client といった属性ヘッダーを自動付与する。ゲートウェイがこれらのヘッダーを保持して Google Cloud に転送することで、単なる未契約の API 呼び出しではなく、組織の Gemini Enterprise 契約に基づくトラフィックとして正しく認識される。 クレジットは使用不可 Antigravity Enterprise Gateway を経由して AI developer tools を使用した場合、リクエストが一元化されたサービスアカウントから送信されるため、Gemini Enterprise のシートベースの付帯クレジット割り当て（Standard の $10/月や Plus の $15/月）は 使用されません 。 ゲートウェイ経由の推論リクエストはすべて、Agent Platform を介した 従量課金 （Pay-as-you-go）として課金されます。 サブスクリプション付帯のクレジットを使用したい場合は、Antigravity Enterprise Gateway を無効にして Google アカウントでログインする必要があります。 技術要件 前述のとおり、Antigravity Enterprise Gateway は、Google Cloud のフルマネージドサービスではありません。管理者自身が構築したリバースプロキシで開発者からのトラフィックを集約することで、Google Cloud API へのリクエストを中継するための設定です。よって、リバースプロキシ自体は、管理者が構築するか、既存のものを使用する必要があります。 管理者が Antigravity Enterprise Gateway を構築・導入するにあたっては、大まかに以下の作業と考慮が必要です。 1. ゲートウェイ（リバースプロキシ）の構築 開発者端末と Agent Platform（ https://aiplatform.googleapis.com ）の間に配置するリバースプロキシを構築します。既存の社内 API ゲートウェイ基盤（Envoy、Apigee、LiteLLM 等）を使用できるほか、Cloud Run 等のコンテナ基盤上にリバースプロキシやゲートウェイをデプロイして構築することもできます。ゲートウェイの実行環境には、推論 API を呼び出すための Vertex AI ユーザー（ roles/aiplatform.user ）ロールを持つサービスアカウントを割り当てます。 2. ゲートウェイ側で考慮すべき通信仕様 ゲートウェイを構成する際は、以下の通信要件を満たす必要があります。 要件 内容 属性ヘッダーの保持 クライアントが付与する User-Agent や X-Goog-Api-Client などの属性ヘッダーを削除せず、そのまま Google Cloud へ転送すること（Gemini Enterprise 契約のトラフィックとして認識させるため） ストリーミング応答と長時間接続の維持 エージェントのリアルタイム応答（Server-Sent Events : SSE）を阻害しないようレスポンスのバッファリングを無効化し、長時間の自律タスクで切断されないようタイムアウトを長め（60分以上推奨）に設定すること テレメトリ用エンドポイントの処理 クライアントが送信するテレメトリ通信（ POST /v1beta:* ）に対してエラーを返さず 200 OK を応答する（または社内 SIEM へ転送する）こと 3. 開発者端末への接続設定の配布 構築したゲートウェイの URL や認証用 API キー、社内プライベート CA 証明書のパスなどを定義した管理者設定ファイル（ admin_settings.json ）を作成し、MDM（モバイルデバイス管理）ツール等で各開発者の端末へ配布します（環境変数での指定も可能）。管理者設定ファイルを所定のシステムディレクトリに配置することで、開発者が個人設定で接続先を変更することを防ぎ、すべての通信を強制的にゲートウェイ経由に統制できます。 参考 : Deploy Google Antigravity Enterprise Gateway 参考 : Connect client workstations to the Antigravity Enterprise Gateway 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 9 月も半ばに差し掛かり、朝晩は少しずつ秋の気配を感じられるようになってきました。 re:Invent 2026 のセッションカタログ も公開され、年末に向けた楽しみが増えてきましたね。 お昼休みの 30 分で最新情報を知れる「 もぐもぐAWS 」では、AI をテーマにした会が 9 月 / 10 月に予定されていますので是非ご参加ください。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、9 月 7 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「Umios(旧マルハニチロ) が時系列基盤モデル Chronos-2 で実現する販売計画 AI – 作業4,200時間削減への裏側」を公開 Umios 株式会社様 (旧マルハニチロ) は、創業 146 年の歴史を持つ冷凍食品中心の食品メーカーです。全国の営業担当者が毎月手作業で行う販売計画の入力に、業務用流通事業部全体で年間約 4,200 時間を要するという課題がありました。Amazon SageMaker JumpStart 上の時系列基盤モデル Chronos-2 を中核とした販売計画 AI を構築し、経験と勘に依存していた予測の属人性を排除しました。特徴量エンジニアリングを重ねた結果、定番品の年累計総計ベースで 95% の予測精度を達成し、年間 4,200 時間の作業削減を見込んでいます。今後は Amazon Bedrock AgentCore を用いた予測結果の説明エージェントの構築や、対象商品の拡大を計画しています。 AWS生成AI国内事例ブログ「CODAS によるデータ秘匿性を考慮した産業特化型 AI 基盤の研究開発と実装検証に関する取り組み」を公開 一般社団法人 AI データ主権共創機構 (CODAS) は、データ秘匿性を基盤とした産業特化型 AI の研究開発・実装・実証に取り組む共創組織です。この記事では、金融領域を最優先とした産業特化型 LLM の学習・評価の取り組みと、それを支える p5en.48xlarge 72 台の AWS ParallelCluster ベースの大規模学習基盤の設計を紹介しています。大規模 GPU クラスターを複数チームで安全に共同利用するための実践知が詰まった内容です。 ブログ記事「第 8 回 AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～【開催報告】」を公開 生成 AI 実用化推進プログラムの参加企業などが一堂に会する「生成 AI Frontier Meetup」の第 8 回が 2026 年 8 月 27 日に開催されました。Weights & Biases 様による LLM 評価のトレンド解説に加え、みずほフィナンシャルグループ様、Sapeet 様、rh labo 様、BTM 様による生成 AI・エージェント活用の取り組みが紹介されています。次回は 11 月 10 日開催予定ですので、興味のある方はぜひプログラムへの参加をご検討ください。 ブログ記事「単一のアクションを越えてエージェントの振る舞いとコストを制御する: Amazon Bedrock AgentCore の新機能」を公開 AI エージェントは自ら実行パスを決めるため、個々のアクションは正当でも全体としては危険な振る舞いになることがあります。この記事では、一連のアクションを評価してポリシー違反をブロックする時系列ポリシー (オープンソースのポリシー言語 Dogwood が基盤) と、ゲートウェイでのレート制限という Amazon Bedrock AgentCore の新機能を紹介しています。エージェントのコードを変えずに、インフラ側で振る舞いとコストの上限を強制できるのがポイントです。 ブログ記事「AWS AI セキュリティフレームワーク: レイヤーとフェーズに応じた適切なセキュリティコントロール」を公開 AI ワークロードのセキュリティを「インフラストラクチャ」「アイデンティティとデータ」「AI アプリケーション」の 3 レイヤーに整理し、Foundational / Enhanced / Advanced の 3 フェーズで段階的に強化する AWS AI Security Framework の解説記事です。プロトタイプから本番、スケールまで、どのフェーズでどのコントロールを適用すべきかが体系的にまとまっています。セキュリティリーダーと開発チームの共通言語として使える内容です。 ブログ記事「エージェンティックセキュリティ: マシンスピードでの検出と対応」を公開 自律型 AI エージェントの台頭は、セキュリティポスチャにとってクラウド移行以来最大の変化と言われています。この記事では、SANS Institute と共同執筆した eBook の章から、エージェントのアイデンティティとガバナンス、振る舞い監視による検出の進化、段階的な自動対応、マルチエージェントエコシステムへの備えという 4 つの基礎領域を紹介しています。エージェント時代のセキュリティ運用を考える出発点になる内容です。 ブログ記事「AI の投資収益率 (ROI) を算出する」を公開 AI 投資の効果をどう測ればよいのかは、多くの企業に共通する悩みです。この記事では、AI のユースケースを分類し、TCO を算出してコストを配分し、ビジネス価値指標と対応付けて「成果当たりコスト」を求める実践的な方法論を解説しています。Amazon Bedrock で使えるコスト帰属メカニズムの使い分けも紹介されており、AI の FinOps に取り組む方の出発点になる内容です。 ブログ記事「AI を活用したスキャフォールディングで、フルスタックの AWS アプリケーションを数分で構築する」を公開 AI アシスタントで作ったアプリケーションを本番品質に固めるには、セキュリティや可観測性などのレビューと修正の繰り返しが必要でした。このギャップを埋める Nx Plugin for AWS バージョン 1.0 がリリースされ、AI を活用したスキャフォールディングで本番相当のフルスタック AWS アプリケーションを数分で構築できるようになりました。プロトタイプ止まりに悩んでいる方はぜひ試してみてください。 ブログ記事「クラウドでのエージェンティックエンジニアリング:Kiro Web とクラウドセッションが一般提供に」を公開 Kiro Web とクラウドセッションが 2026 年 9 月 3 日に一般提供 (GA) になりました。ブラウザから作業を依頼してエージェントに任せきりにしたり、Spec で作業を形にして進めたりと、エンジニアリング作業のより多くをクラウドで実行できるようになります。あわせて、構築済みの Steering やカスタムエージェントといった設定をローカルとクラウドの両方のセッションで使える cloud configuration も提供されています。 ブログ記事「Kiro が ISO/IEC 27001:2022 のカバレッジに対応」を公開 Kiro が AWS の ISO/IEC 27001:2022 認証の適用範囲に含まれました。開発ツールはソースコードや社内ドキュメントなどの機密情報とともに使われるため、組織がツールを承認する際には情報セキュリティリスク管理の明確なエビデンスが求められます。調達・セキュリティ・ベンダーリスクの各チームが第三者による独立検証済みのエビデンスを利用できるようになり、企業での Kiro 導入を進めやすくなりました。 ブログ記事「1 年間無料の Kiro を、世界中の学生へ」を公開 Kiro を 1 年間無料で利用できる Kiro Students プログラムが、新たに 16 か国 121 の大学へ拡大されました。対象の学生は毎月 1,000 クレジットが付与され、プレミアムモデルや Kiro Web といった有料機能にもフルアクセスできます。クレジットカードの登録もトライアル期限もなしとのことなので、対象大学の学生の方はこの機会にぜひ触ってみてください。 ブログ記事「【開催報告】Girls Meet STEM in AWS 2026 を開催しました」を公開 2026 年 8 月 21 日、中高生女子向けプログラム「Girls Meet STEM」の一環として、麻布台ヒルズの新オフィスで生成 AI 体験ワークショップやオフィスツアー、パネルディスカッションを開催しました。ワークショップでは 34 名の参加者が Generative AI Use Cases (GenU) のユースケースビルダーを使い、コードを書かずに自分のアイデアを AI アプリとして形にしました。AI を「使う」側から「作る」側への一歩を体験いただいた様子をレポートしています。 ブログ記事「AWS Certified AI Business Strategist のご紹介 ~ AI をスケールさせる人々のために ~」を公開 AI 導入をビジネス側から推進する方向けの新しい AWS 認定、AWS Certified AI Business Strategist (AIB) が発表されました。技術的な実装ではなく、AI 戦略の立案やビジネスケースの構築、ガバナンス整備といったビジネス判断力を検証する試験です。ベータ試験は 2026 年 9 月 29 日から英語と日本語で受験でき、2027 年 2 月 15 日までに取得するとアーリーアドプターバッジも付与されます。 ブログ記事「AWS 認定資格 (MLA、SAP、DVA) に関するアップデート: 2026 年 9 月」を公開 AWS Certified Machine Learning Engineer – Associate (MLA-C02)、Solutions Architect – Professional (SAP-C03)、Developer – Associate (DVA-C03) の 3 つの認定試験が更新されます。いずれも生成 AI・エージェンティック AI の実装や AI 支援開発といった、今日のクラウドエンジニアに求められるスキルが出題範囲に加わります。MLA-C02 のベータ登録はすでに開始しており、SAP-C03 と DVA-C03 は 2026 年 10 月 27 日に登録開始予定です。 サービスアップデート OpenAI GPT-6 Astra が Amazon Bedrock で一般提供開始 OpenAI 社の最新かつ最高性能のモデル GPT-6 Astra が Amazon Bedrock で一般提供開始されました。より深い推論と判断力、プロフェッショナル品質の文章作成・デザイン、高度なコンピュータ・ブラウザ操作能力を備え、最大 100 万トークンの入力コンテキストウィンドウをサポートします。Amazon Bedrock の API から直接呼び出せるほか、ChatGPT Work や Codex から Bedrock 上のモデルを使う構成も可能です。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock Managed Knowledge Base が TwelveLabs Marengo 3.0 による動画・音声・画像のマルチモーダル埋め込みをサポート Amazon Bedrock Managed Knowledge Base の埋め込みモデルとして TwelveLabs Marengo 3.0 が利用可能になりました。従来の文字起こしベースのメディア検索と異なり、映像シーンや音声、映像上の手がかりを直接埋め込みに変換するため、文字起こしでは捉えられない意味まで自然言語で検索できます。検索結果にはセグメントの開始・終了時刻が含まれるため、動画内の該当シーンへ直接ジャンプするアプリケーションを構築できます。スポーツ映像の分析やメディア、教育などでの活用が期待できます。 Amazon Bedrock Managed Knowledge Base が Confluence Data Center をネイティブデータソースコネクタとしてサポート フルマネージド RAG サービスである Amazon Bedrock Managed Knowledge Base で、セルフホスト型の Confluence Data Center をデータソースとして利用できるようになりました。これまで独自のインジェストパイプラインの構築が必要でしたが、認証情報を設定するだけでクロール、メタデータ抽出、増分同期まで自動で行われます。Confluence 上のエンジニアリングドキュメントやランブックに根ざした社内アシスタントを構築しやすくなります。 Amazon Bedrock Managed Knowledge Base がドキュメントレベルアクセス制御のデバッグ用 API とコンソール機能を追加 Amazon Bedrock Managed Knowledge Base に、ドキュメントレベルのアクセス制御をデバッグするための CheckIngestedDocumentAcl / GetIngestedDocumentAcl API とコンソール機能が追加されました。特定ユーザーがドキュメントにアクセスできるかの確認や、ドキュメントに付与された ACL 全体の監査ができ、検索結果に期待するドキュメントが出てこない原因をサポートケースを起票せずに自己解決できます。 Amazon Bedrock AgentCore Memory が長期記憶への直接取り込みをサポート Amazon Bedrock AgentCore Memory に、コンテンツを短期記憶イベントとして保存せずに長期記憶へ直接取り込める IngestData API が追加されました。これまで長期記憶への抽出には短期記憶イベントとしての保存が必須でしたが、今回のアップデートで長期記憶だけを独立して利用できます。会話形式のペイロードに加えて行動ログなどの JSON ペイロードにも対応しており、取り込んだ記憶は既存の検索 API からそのまま利用できます。AgentCore Memory が利用可能な全リージョンで提供されています。 Amazon SageMaker HyperPod が推論の高速なオートスケーリングを実現するモデルキャッシュをサポート Amazon SageMaker HyperPod で、モデルの重みとコンテナイメージをクラスターノードに事前ロードしておくモデルキャッシュがサポートされました。大規模 LLM の推論ではスケールアウト時のモデルダウンロードがボトルネックでしたが、ローカル NVMe からの読み込みとイメージの事前取得により、ポッドを数分ではなく数秒で起動できます。57〜145 GB のモデルを使ったベンチマークでは約 60% 高速なスケールアウトを実現しています。詳細は こちらのドキュメント をご参照ください。 Amazon Quick デスクトップアプリが macOS と Windows で一般提供開始 Amazon Quick のデスクトップアプリが macOS と Windows で一般提供開始されました。ローカルファイルを直接扱いながらカレンダーやメール、ビジネスアプリとバックグラウンドで連携し、会話・コンテキスト・エージェントはデスクトップとモバイルの間で同期されます。エージェントは PC を閉じた後もクラウドで動き続けるため、退社前に開始した長時間タスクの結果を帰宅後にレビューする、といった使い方ができます。東京リージョンを含む 7 リージョンで利用可能です。 Amazon Quick が常時稼働エージェント、強化されたフィード、エンタープライズ管理機能を追加 Amazon Quick に、業務の整理・組織的なガバナンス・回答の信頼性を高める一連の新機能が追加されました。スケジュールタスクや監視エージェントがクラウド上で実行され、PC を閉じていても結果がフィードに届くようになったほか、アクティビティフィードのフィルターや 1 日 3 回更新のデイリーブリーフィングも加わりました。管理者向けにはモバイルデバイス管理、ユーザーごとのカスタム権限、Microsoft Purview の DLP 統合が提供されます。また、月あたりのエージェント時間が Professional で 4 時間から 8 時間、Enterprise で 8 時間から 18 時間に拡大されています。 Amazon Quick のアクティビティフィードが iOS と Android のモバイルデバイスで利用可能に Amazon Quick のアクティビティフィードが iOS / Android のモバイルアプリでも利用可能になりました。社内のコミュニケーションやツールを横断して対応が必要な項目を 1 つの優先度付きビューで確認でき、アプリを切り替えずにその場でアクションを実行できます。デスクトップとモバイルでコンテキストが引き継がれるため、外出先でも作業の続きをそのまま進められます。 AWS DevOps Agent が Slack との双方向コミュニケーションをサポート AWS DevOps Agent のインシデント調査を Slack 上で完結できるようになりました。接続したプライベートチャンネルで AWS DevOps Agent をメンションするだけで調査を開始・誘導でき、チームが提供したコンテキスト、エージェントの調査結果、推奨アクションが 1 つのスレッドに集約されます。障害対応時にコミュニケーションツールと調査ツールを行き来する必要がなくなり、オンコール対応の負荷を軽減できます。 AWS Transform の .NET モダナイゼーションが CLI で一般提供開始 AWS Transform custom の AWS マネージド変換として、.NET モダナイゼーションを 1 行の CLI コマンドで実行できるようになりました。対話的に実行できるほか、既存のパイプラインやワークフローに組み込んで自律的に実行することも可能です。東京リージョンを含む 8 リージョンで利用でき、無料のエージェント実行時間が毎月 50,000 分が含まれます。 AWS Transform for .NET がモダナイズしたコードのユニットテストを生成可能に AWS Transform for .NET が、モダナイズ後のコードに対するユニットテストを自動生成できるようになりました。これまで .NET Framework から最新 .NET への移行後のテスト整備は手作業でしたが、移行と同じジョブの中でテスト対象クラスの分析からテストコード生成までが行われ、テストが揃った状態で移行を完了できます。Visual Studio 向け AWS Toolkit 拡張でオプトインして利用できます。 AWS Lambda durable functions が Pydantic AI と統合 AWS Lambda durable functions が、Python 製の AI エージェントフレームワーク Pydantic AI と統合されました。エージェントのモデル呼び出しやツール呼び出しが耐久性のある実行ステップとして保存されるため、タイムアウトなどで中断しても完了済みのステップを繰り返さずに再開できます。チェックポイントやリトライのロジックを自分で書くことなく、トークンの二重消費や顧客への二重請求といった副作用を防げます。 Amazon OpenSearch Serverless が v0 by Vercel で利用可能に AI アプリ開発プラットフォームの v0 by Vercel で、Amazon OpenSearch Serverless が利用可能になりました。自然言語のプロンプトで作りたいものを記述するだけで、v0 がフルスタックアプリケーションを生成し、OpenSearch Serverless コレクションのプロビジョニングからデータのインデックス作成まで自動で行います。全文検索や RAG 向けのベクトル検索を備えたアプリを数分で立ち上げられ、東京・大阪リージョンにも対応しています。 Kiro CLI 2.21.4 がセッション検索の対象範囲設定と V2 ハーネスフラグを追加 Kiro CLI 2.21.4 がリリースされました。/sessions のセッション検索の対象を「プロンプトのみ」と「プロンプトとエージェントの応答」から選べるようになり、自分が聞いた内容だけでなく Kiro が答えた内容からも過去のセッションを探せます。また、–v2 フラグでデフォルト設定を変えずにその 1 回だけ V2 エージェントハーネスで実行できるようになりました。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

私はC#が好きなのですが、デリゲートを使ったことがないと気付きました。 昔やったプロジェクトでデリゲートを見たことはありますし、先輩が使っているのを見たこともあります。しかし自分自身が使ったことはなくて、食わず嫌いしていたかもと思えてきました。 そこでデリゲートをコードを書きながら学ぼうと考えたのが今回の記事です。私が書いて動かしたコードで解説していきます。 デリゲート（delegate）とは # デリゲートとは委譲という意味です。 委譲とはコトバンクによると「権利・権限などを他の人・機関に譲って任せること」となっています。つまり自分がやることを他人に任せることです。例えば上司が部下に仕事を振ることなどはいい例でしょう。 https://kotobank.jp/word/%E5%A7%94%E8%AD%B2-432326 ならばプログラミングにおいてはやることは処理です。処理の実行を他の機能に任せるということになります。 しかしこれだけだとなんのこっちゃか分かりません。そこでもう少し具体的に言うと、処理（メソッド）の参照を代入して、値ではなく処理（メソッド）を渡すことで、他の機能（クラス）から処理（メソッド）を実行できるようにするとなります。 例えばある処理が完了したらコールバック処理を呼び出してもらうときに使えます。 事前準備 # この記事のサンプルコードを動かすにはVisual StudioまたはVisual Studio CodeでC#開発ができるようセットアップを行ってください。Visual Studio Codeでのセットアップはこちらの記事を参照してください。 VS Codeで始める！わかる＆できるC#開発環境の構築【2025年版マニュアル】 IDEのセットアップができたら、次はコンソールアプリのプロジェクトを作成してください。この記事のサンプルコードは手軽に動作確認するためにコンソールアプリで作っています。 デリゲートの基本をサンプルコードで解説 # デリゲートの基本的な書き方 # 早速ですがコードを書いて動きを確認していきます。 動かせるサンプルコードを掲載します。 DelegateSample というクラスを作り、以下のコードを書いてください。 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp { internal class DelegateSample { // デリゲートを宣言 // デリゲート型のメソッドを宣言しているようなもの delegate void SampleDelegate(string message); // サンプルの実行 public void ExecSample() { // 宣言したデリゲートを型としてメソッドを引数に渡す // 違和感ある書き方だが、メソッド型のインスタンスを作ってメソッドを代入しているようなイメージ SampleDelegate sampleDelegate = new SampleDelegate(Console.WriteLine); // 試しにメッセージを出してみる // Console.WriteLineを代入したので、デリゲートを実行するとConsole.WriteLineが実行される sampleDelegate("テストメッセージです"); // 次は独自に作ったメソッド（コンソールに文字列を出すだけだが）を代入してみる sampleDelegate = TestMessage; sampleDelegate("カレーとサラダ"); Console.WriteLine(); } void TestMessage(string message) { Console.WriteLine($"今夜の夕食は{message}の予定です。"); } } } そして Program.cs には以下のように書いてください。 using DelegateApp; using DelegateApp.Models; Console.WriteLine("デリゲートを開始します"); DelegateSample delegateSample = new DelegateSample(); delegateSample.ExecSample(); このコードを実行すると、次のようにメッセージが表示されます。 デリゲート初心者には分かりづらいとか違和感があると感じたかもしれません。 デリゲートの宣言は delegate 型のメソッドを定義することです。そして次に宣言したメソッドを型としたインスタンスを作成します。型がメソッドだなんて一瞬意味が分からなく感じますよね。 そして delegate 型のインスタンスにはメソッドを代入できます。メソッドを実行するための仕組みなので、このようになります。メソッドを代入するということ自体が慣れない行為ですよね。 でもここまで見てみると、引数さえ合っていれば、色んなメソッドを代入して実行可能だろうと分かりますね。 複数のメソッドをまとめるマルチキャストデリゲートというものもあります。例えば先ほどの DelegateSample クラスに次のようにコードを追加してみましょう。 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp { internal class DelegateSample { // デリゲートを宣言 // デリゲート型のメソッドを宣言しているようなもの delegate void SampleDelegate(string message); // サンプルの実行 public void ExecSample() { // 宣言したデリゲートを型としてメソッドを引数に渡す // 違和感ある書き方だが、メソッド型のインスタンスを作ってメソッドを代入しているようなイメージ SampleDelegate sampleDelegate = new SampleDelegate(Console.WriteLine); // 試しにメッセージを出してみる // Console.WriteLineを代入したので、デリゲートを実行するとConsole.WriteLineが実行される sampleDelegate("テストメッセージです"); // 次は独自に作ったメソッド（コンソールに文字列を出すだけだが）を代入してみる sampleDelegate = TestMessage; sampleDelegate("カレーとサラダ"); Console.WriteLine(); // ここから追加 // 実はメソッドの追加が可能 sampleDelegate += TestMessageLunch; sampleDelegate("カレーとサラダ"); Console.WriteLine(); // 追加済みメソッドの削除も可能 sampleDelegate -= TestMessage; sampleDelegate("カレーとサラダ"); // ここまで } void TestMessage(string message) { Console.WriteLine($"今夜の夕食は{message}の予定です。"); } // 昼食用のメソッドを追加 void TestMessageLunch(string message) { Console.WriteLine($"今夜の昼食は{message}でした。"); } } } Program.cs を実行すると以下のようになります。 このコードにはデリゲートに対してメソッドを加算及び減算しています。 なんと delegate 型のインスタンスには複数のメソッドの追加や追加したメソッドの削除ができるのです。 これをマルチキャストデリゲートと呼びます。 デリゲートの進化の歴史を知る # 実は先ほど書いたデリゲートのやり方は昔ながらのやり方でした。それがもう少し進化し、C# 2.0の時代には匿名メソッドが使えるようになりました。 匿名メソッドのサンプルコードを掲載します。 DelegateSampleAnonymous というクラスを作り、以下のコードを書いてください。 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp { internal class DelegateSampleAnonymous { // デリゲートを宣言 // デリゲート型のメソッドを宣言しているようなもの delegate void SampleDelegate(string message); // サンプルの実行 public void ExecSample() { // 次は独自に作ったメソッド（コンソールに文字列を出すだけだが）を代入してみる // 定義されたメソッドだけでなく、匿名メソッドも代入可能 SampleDelegate sampleDelegate = delegate(string message) { Console.WriteLine($"今夜の夕食は{message}の予定です。"); }; sampleDelegate("カレーとサラダ"); Console.WriteLine(); // 匿名メソッドを追加してみる sampleDelegate += delegate(string message) { Console.WriteLine($"今夜の昼食は{message}でした。"); }; sampleDelegate("カレーとサラダ"); Console.WriteLine(); // ちなみに匿名メソッドで追加すると削除できない // このように一度別のインスタンスに入れてから追加する必要がある SampleDelegate workDelegate = delegate(string message) { Console.WriteLine($"今夜の朝食は{message}でした。"); }; sampleDelegate += workDelegate; sampleDelegate("カレーとサラダ"); Console.WriteLine(); sampleDelegate -= workDelegate; sampleDelegate("カレーとサラダ"); } } } そして Program.cs には以下のように書いてください。 using DelegateApp; using DelegateApp.Models; Console.WriteLine("デリゲートを開始します"); Console.WriteLine(); Console.WriteLine("匿名メソッドのサンプルです"); Console.WriteLine(); DelegateSampleAnonymous delegateSampleAnonymous = new DelegateSampleAnonymous(); delegateSampleAnonymous.ExecSample(); 実行すると以下のようになります。 ここでちょっと厄介なことは、匿名メソッドを使った場合は追加したメソッドの削除ができないことです。どうしても削除したければ、一度インスタンスに入れてから追加する必要があるのです。 上記のサンプルで言うと workDelegate が該当します。 現在はラムダ式を使うのが主流となっています。ラムダ式を使うサンプルコードを掲載します。 DelegateSampleLambda というクラスを作り、以下のコードを書いてください。 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp { internal class DelegateSampleLambda { // デリゲートを宣言 // デリゲート型のメソッドを宣言しているようなもの delegate void SampleDelegate(string message); // サンプルの実行 public void ExecSample() { // 次は独自に作ったメソッド（コンソールに文字列を出すだけだが）を代入してみる // 定義されたメソッドだけでなく、ラムダ式も代入可能 SampleDelegate sampleDelegate = (string message) => { Console.WriteLine($"今夜の夕食は{message}の予定です。"); }; sampleDelegate("カレーとサラダ"); Console.WriteLine(); // ラムダ式を追加してみる sampleDelegate += (string message) => { Console.WriteLine($"今夜の昼食は{message}でした。"); }; sampleDelegate("カレーとサラダ"); Console.WriteLine(); // ちなみにラムダ式で追加すると削除できない // このように一度別のインスタンスに入れてから追加する必要がある SampleDelegate workDelegate = (string message) => { Console.WriteLine($"今夜の朝食は{message}でした。"); }; sampleDelegate += workDelegate; sampleDelegate("カレーとサラダ"); Console.WriteLine(); sampleDelegate -= workDelegate; sampleDelegate("カレーとサラダ"); } } } そして Program.cs には以下のように書いてください。 using DelegateApp; using DelegateApp.Models; Console.WriteLine("デリゲートを開始します"); Console.WriteLine(); Console.WriteLine("ラムダ式のサンプルです"); Console.WriteLine(); DelegateSampleLambda delegateSampleLambda = new DelegateSampleLambda(); delegateSampleLambda.ExecSample(); 実行すると以下のようになります。 ラムダ式になるともはや delegate という記述すらなくなります。一番シンプルな書き方です。 FuncとActionを使えば宣言不要 # 戻り値がない処理ならAction # ここまでのやり方は delegate 型のメソッドを宣言して、そのインスタンスにメソッドを代入するというものでした。わざわざ宣言しているので、用途別にデリゲートを作成する必要がありました。 そこで汎用型として戻り値がない場合は Action 、戻り値がある場合は Func というものが登場しました。 Action を使ったサンプルコードを掲載します。 DelegateSampleAction というクラスを作り、以下のコードを書いてください。 このようにジェネリックで引数の型を指定します。わざわざ delegate 型のメソッドを宣言する必要がないので、コードもシンプルになります。 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp { internal class DelegateSampleAction { public void ExecSample() { // Actionデリゲートを使用するサンプル // Actionデリゲートは戻り値がvoidで、引数の型を指定できる Action<string> actionDelegate = (message) => { Console.WriteLine($"今夜の夕食は{message}の予定です。"); }; actionDelegate("カレーとサラダ"); } } } そして Program.cs には以下のように書いてください。 using DelegateApp; using DelegateApp.Models; Console.WriteLine("デリゲートを開始します"); Console.WriteLine(); Console.WriteLine("Actionのサンプルです"); Console.WriteLine(); DelegateSampleAction delegateSampleAction = new DelegateSampleAction(); delegateSampleAction.ExecSample(); 実行すると以下のようになります。 ちなみにメソッドの追加や削除については delegate を使う場合と同様に+や-などの演算子を使ってください。また匿名メソッドやラムダ式では削除ができないことも同様ですので、削除したいときは一度インスタンスに入れてから追加してください。 戻り値がある処理ならFunc # Func を使ったサンプルコードを掲載します。 DelegateSampleFunc というクラスを作り、以下のコードを書いてください。ジェネリックの型指定で、<引数の型, 戻り値の型>というように指定します。 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp { internal class DelegateSampleFunc { public void ExecSample() { // Actionデリゲートを使用するサンプル // Actionデリゲートは戻り値がvoidで、引数の型を指定できる Func<int, string> funcDelegate = (num) => { return $"入力された値は{num}です。"; }; Console.WriteLine(funcDelegate(5)); } } } そして Program.cs には以下のように書いてください。 using DelegateApp; using DelegateApp.Models; Console.WriteLine("デリゲートを開始します"); Console.WriteLine(); Console.WriteLine("Funcのサンプルです"); Console.WriteLine(); DelegateSampleFunc delegateSampleFunc = new DelegateSampleFunc(); delegateSampleFunc.ExecSample(); 実行すると以下のようになります。 Func もメソッドの追加や削除については delegate を使う場合と同様です。 デリゲートの本当の使い道 # コールバック処理 # コールバック処理のサンプルコードを掲載します。 DelegateSampleAction というクラスを作り、以下のコードを書いてください。 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp { internal class CallbackSample { // コールバックのサンプル // ここでは、処理が終わった後に呼び出されるメソッドをデリゲートとして渡す // デリゲートを使うことで、処理が終わった後に呼び出されるメソッドを自由に変更できる public void ExecSample(string message, Action<string> callback) { Console.WriteLine($"処理中: {message}"); // 処理が終わった後にコールバックを呼び出す callback?.Invoke($"処理が完了しました: {message}"); } } } そして Program.cs には以下のように書いてください。 using DelegateApp; using DelegateApp.Models; Console.WriteLine("デリゲートを開始します"); Console.WriteLine(); Console.WriteLine("コールバックのサンプルです"); Console.WriteLine(); CallbackSample callbackSample = new CallbackSample(); callbackSample.ExecSample("カレーとサラダ", (result) => { Console.WriteLine(result); }); 実行すると以下のようになります。 このようにメソッドの引数に Func や Action を定義することで処理を受け取ります。そして Invoke メソッドで処理を実行します。 条件に応じた処理の差し替え # 実はLINQの Where は引数が Func になっています。つまり Where メソッドの中ではデリゲートを使っているのです。 では Func の内容次第で結果が異なる例を作ってみましょう。 DelegateSampleLinq というクラスを作り、以下のコードを書いてください。 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp { internal class DelegateSampleLinq { public void ExecSample() { List<int> numbers = new List<int> { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 }; // まずは偶数だけを抽出してみる var evenNumbers = FilterNumbers(numbers, (num) => num % 2 == 0); Console.WriteLine("偶数のリスト:"); Console.WriteLine(evenNumbers.Count > 0 ? string.Join(", ", evenNumbers) : "該当する値はありません。"); // 続いて奇数を抽出してみる var oddNumbers = FilterNumbers(numbers, (num) => num % 2 != 0); Console.WriteLine("奇数のリスト:"); Console.WriteLine(oddNumbers.Count > 0 ? string.Join(", ", oddNumbers) : "該当する値はありません。"); } /// <summary> /// 引数として渡されたFuncを実行し、条件に一致する値だけを返す /// </summary> /// <param name="numbers"></param> /// <param name="predicate"></param> /// <returns></returns> static List<int> FilterNumbers(List<int> numbers, Func<int, bool> predicate) { List<int> resultList = new List<int>(); foreach (var number in numbers) { if (predicate(number)) { resultList.Add(number); } } return resultList; } } } そして Program.cs には以下のように書いてください。 using DelegateApp; using DelegateApp.Models; Console.WriteLine("デリゲートを開始します"); Console.WriteLine(); Console.WriteLine("条件を切り替えるサンプルです"); Console.WriteLine(); DelegateSampleLinq delegateSampleLinq = new DelegateSampleLinq(); delegateSampleLinq.ExecSample(); 実行すると以下のようになります。 デリゲートの脆弱性を補うためのevent # ここまでデリゲートの使い方について色々と見てきました。 しかし便利な反面、危険も伴います。何せ代入次第で何とでも処理内容を変えられます。また Invoke メソッドによって好きなところで実行が可能です。脆弱な面があることは否めません。 下手すると不具合の元になるのはもちろん、セキュリティ面での脆弱性も怖いところです。 そこで event というキーワードを付けることで、外部クラスからの代入や実行ができなくなります。 event を使ったサンプルコードを掲載します。 DelegateSampleEvent というクラスを作り、以下のコードを書いてください。 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp { internal class DelegateSampleEvent { // パブリックだから他のクラスからアクセス可能 public event Func<int, string> SampleEvent; } internal class DelegateSampleExternal { public void ExecSample() { DelegateSampleEvent sample = new DelegateSampleEvent(); // 外部クラスからのデリゲートの代入は不可 sample.SampleEvent = (int x) => $"入力された値は{x}です。"; // 外部クラスからのデリゲートの追加と削除は可能 sample.SampleEvent += (int x) => $"入力された値は{x}です。"; Func<int, string> func = (int x) => $"今日はコーヒーを{x}杯飲みました。"; sample.SampleEvent += func; sample.SampleEvent -= func; // 外部クラスからの実行は不可 sample.SampleEvent.Invoke(99); } } } 上記のようにコードを書くと、以下のスクリーンショットのように代入と Invoke メソッドのところでコンパイルエラーが発生します。 ひとまず先ほどのコードでコンパイルエラーが出ている個所はコメントアウトしてください。 フードコートでの注文を例にデリゲートを試す # デリゲートのやり方が分かったところで、現実世界をイメージして練習してみたいと思います。そこでフードコードのスイーツ屋をテーマに扱います。ただ文字の表示や計算をするよりは楽しい内容になるし、委譲をイメージしやすいと考えたためです。 業務フローは以下の図のようになります。 ここではコードをかなり端折って解説します。本当は注文内容だって明細を持てるようにしたり、注文内容も動的に変えられるようにしたりする必要がありますが、今回はそこが主題でないため簡易的なメッセージで済ませます。 それではソースコードを掲載します。 Models というフォルダに作って、その中に以下の5つのクラスを作成してください。 using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp.Models { internal class Buzzer { public int No { get; set; } public Buzzer(int no) { No = no; } public void Ring() { Console.WriteLine($"ピー！ピー！ピー！{No}番のブザーが鳴っています！"); } } } using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp.Models { internal class Cook { public void CookOrder(Order order) { Console.WriteLine($"料理人が注文を受け取りました: {order.OrderContent}"); Console.WriteLine("料理を作っています..."); Console.WriteLine("料理が完成しました！"); } } } using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp.Models { internal class Customer { private Buzzer Buzzer { get; set; } public Order MakeOrder() { Console.WriteLine("お客様が注文しました。"); return new Order("パンケーキとコーヒーのセット"); } public void Pay() { Console.WriteLine("お会計を済ませました。"); } public void PickUpBuzzer(Buzzer buzzer) { Buzzer = buzzer; Console.WriteLine($"お客様が{buzzer.No}番のブザーを受け取りました。"); } public void PickUpFood() { Console.WriteLine($"お客様が{Buzzer.No}番のブザーを渡しました。"); Console.WriteLine("お客様が料理を受け取りました。"); } } } using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp.Models { internal class Order { public string? OrderContent { get; set; } public Order(string? orderContent) { OrderContent = orderContent; } } } using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace DelegateApp.Models { internal class Staff { private delegate void BuzzerRingHandler(); private IDictionary<int, BuzzerRingHandler> _buzzerHandlers = new Dictionary<int, BuzzerRingHandler>(); public void TakeOrder(Order order) { Console.WriteLine($"スタッフが注文を受け取りました: {order.OrderContent}"); Console.WriteLine("お会計は1,500円になります。"); } public Buzzer HandOverBuzzer(int no) { Buzzer buzzer = new Buzzer(no); Console.WriteLine($"スタッフが{no}番のブザーを渡しました。"); _buzzerHandlers.Add(no, buzzer.Ring); return buzzer; } public void RingBuzzer(int no) { if (_buzzerHandlers.TryGetValue(no, out var buzzer)) { buzzer.Invoke(); _buzzerHandlers.Remove(no); } } } } そして Program.cs には以下のように書いてください。 using DelegateApp; using DelegateApp.Models; Console.WriteLine("デリゲートを開始します"); Console.WriteLine(); Console.WriteLine("フードコートで料理が出来たらブザーを鳴らすサンプルです"); Console.WriteLine(); Customer customer = new Customer(); Staff staff = new Staff(); Cook cook = new Cook(); Order order = customer.MakeOrder(); // 注文とお会計 staff.TakeOrder(order); customer.Pay(); // ブザーを渡す int no = 1; Buzzer buzzer = staff.HandOverBuzzer(no); customer.PickUpBuzzer(buzzer); // 調理 cook.CookOrder(order); // ブザーを鳴らして料理を渡す staff.RingBuzzer(no); customer.PickUpFood(); 実行すると以下のようになります。 ポイントとしては店員がどのお客さんに何番のブザーを渡したかを管理しているということです。 プログラムとしては Staff クラスが Dictionary で番号とブザーを鳴らすメソッドの組み合わせを持っています。 こうすることで、料理ができたときに店員が顧客の手元にあるブザーを鳴らせるようにできます。 おわりに # コードを書いて動かしてみることで、デリゲートとは何かが少し分かりました。やっぱり書いて動かしてみるのが一番ですね。 デリゲートが分からないという方はこの記事のフードコートみたいなものを作ってみてください。