本記事は 2024 年 2 月 16 日に公開された” Enhance your AWS cloud infrastructure security with AWS Managed Services (AMS) “を翻訳したものです。 はじめに セキュリティやデータ損失インシデントは、金銭的損失と社会的信用の失墜につながる可能性があります。セキュリティとコンプライアンスは、AWS とお客様の間における責任共有により維持されます。この責任共有では、AWS は「クラウドのセキュリティ」に責任を持ち、お客様は「クラウドにおけるセキュリティ」に責任を持ちます。しかし、クラウドにおけるセキュリティは、特にクラウドインフラおよびオペレーティングシステム(OS)レベルにおいて、より広い範囲に及びます。クラウドにおいて、セキュアでコンプライアンスに準拠した監視環境を大規模に構築するには、高度な自動化、人的リソース、およびスキルが必要です。 このブログでは、「クラウドにおけるセキュリティ」を向上させるために AWS サービスを組み合わせて活用する方法を紹介します。多くの組織にとって、スキル不足やビジネスにおける優先順位により、セキュリティのベストプラクティスを大規模に順守し、導入することは容易ではありません。 AWS Managed Services （AMS）が大規模にお客様の AWS インフラのセキュリティおよびコンプライアンス体制を強化してきたベストプラクティスをご紹介します。AMS は、モニタリング、インシデント管理、セキュリティ、パッチ適用、バックアップ、コスト最適化にわたって AWS クラウドでの運用上の優秀性を達成するための能動的・予防的・検出的な機能を提供します。これにより、お客様はイノベーションに集中できます。 例えば、Coinhako が AMS を運用パートナーとして AWS に移行した際、CTO の Gerry Eng 氏は次のように述べています。「AMS に標準搭載されている数多くのセキュリティ機能は、我々が独自に適切に展開するには数ヶ月、場合によっては数年かかっていたでしょう。」詳細は ケーススタディ をご覧ください。 AWS におけるクラウドセキュリティ管理 予防（Prevention） 「予防は治療に勝る」と言われています。セキュリティ体制を改善し、問題を予防するための領域には、アイデンティティとアクセス管理（ IAM ）、受信 （Ingress）と送信 （Egress）トラフィックの保護、バックアップおよび災害復旧、そして脆弱性への対処があります。 AWS は AWS IAM とサービスコントロールポリシー（ SCPs ）を組み合わせてクラウドリソースへのきめ細かいアクセス制御を提供しています。AWS は IAM サービスのセキュリティベストプラクティス を公開しています。しかし、お客様がその最適な利用状況を長期にわたって監視・統制することは容易ではなく、結果として不正なアクセスや不要なアクセスを招いてしまうことが少なくありません。AMS を活用することで、IAM の変更が AWS のベストプラクティスや AMS の技術基準に適合しているかを継続的に検証することが可能です。また、AMS はカスタム AWS Config ルールを使用して IAM のガバナンスコントロールのベストプラクティスを実装し、異常または逸脱を積極的に検出・修正します。 受信 （Ingress）と送信 （Egress）トラフィックの観点から、エッジネットワークで AWS WAF （Web アプリケーションファイアウォールサービス）を使用して、Web アプリケーションリソースへ届く HTTP/HTTPS リクエストを検査することができます。AWS WAF は Amazon CloudFront 、 Application Load Balancer （ALB）、 Amazon API Gateway などほとんどの AWS 外部向けサービスとネイティブに統合されています。ネットワーク層では、 AWS Network Firewall を使用してファイアウォールルールを定義し、すべての受信 （Ingress）と送信 （Egress）ネットワークトラフィックをきめ細かく制御できます。Network Firewall は AWS Firewall Manager と連携して、複数の VPC およびアカウントにわたってポリシーを一元的に適用します。AMS は AWS ベストプラクティスを使用して、これらのサービスを継続的にセットアップおよび運用するサポートを提供します。 さらに、定期的なパッチ適用は脆弱性に対する最も効果的な予防策の一つです。 Ponemon Institute の調査によると、「侵害被害者の 60% は、パッチが未適用の既知の脆弱性を悪用されて侵害された」と述べています。OS レベルでは、最新の脆弱性から保護するための完全なパッチ管理のために AWS Systems Manager の Patch Manager サービスを活用できます。継続的な脆弱性管理には、 Amazon Inspector サービスで、OS の脆弱性のスキャン・特定ができます。しかし、パッチスケジュールの設定、パッチコンプライアンスのレポート、および大規模なパッチ失敗への対応は、困難ではあるもののビジネス上の差別化に繋がらないタスクとみなされることがあります。AMS は自動化とベストプラクティスを駆使し、大規模環境においても、これら一連の作業をお客様に代わって実行します。AMS は Inspector またはお客様のツールによって報告された高リスクまたはゼロデイ脆弱性に対処するための臨時パッチ適用も実行できます。また、AMS を活用して Security Technical Implementation Guide （ STIG ）ベンチマークに準拠したセキュリティが強化された OS の Amazon Machine Images（AMI）を構築し、安全な EC2 インスタンスをデフォルトで保護することもできます。 最後に、インシデント時のデータ損失に対して、堅牢なバックアップおよび災害復旧戦略が不可欠です。 AWS Backup と AWS Elastic Disaster Recovery を組み合わせて AWS クラウドのデータを保護できます。大規模な環境において、バックアップ計画の設定とバックアップコンプライアンスの継続的な監視は複雑になることがあります。AMS は継続的なバックアップの監視・管理を支援するだけでなく、ランサムウェア保護プランを含むデータ復旧のビジネスユースケースに対応した複数のバックアップ計画を提供します。定期的なバックアップのテスト・復元は、予期せぬ問題発生時のビジネスサービスのダウンタイムを最小化するための重要な実践です。AMS はインシデント時の平均復旧時間（MTTR）を短縮するためのサービス復旧に関する SLA を提供します。AMS はお客様のチームとともに、侵害インスタンスやランサムウェアイベントなどのシナリオをシミュレートするセキュリティおよび運用重視のゲームデー（模擬訓練）を実施します。 検出（Detection） クラウド環境を継続的に監視して異常や潜在的な悪意ある活動を積極的に検出・封じ込め・修正することは非常に重要です。AWS は、ログやイベントの処理、およびモニタリングを通じて、監査、自動分析、アラーム通知を可能にするさまざまな検知統制を実装するためのサービスを提供しています。例えば、 Amazon GuardDuty は機械学習（ML）ベースの脅威検出サービスで、アクセス関連アクティビティと不正な動作を継続的に監視して AWS アカウントのワークロードを保護します。GuardDuty は Amazon Macie と組み合わせることができます。Macie はデータセキュリティサービスで、ML とパターンマッチングを使用して AWS アカウント内の機密データの検出・保護を行います。 AWS Security Hub CSPM はクラウドセキュリティ体制管理（CSPM）サービスで、セキュリティのベストプラクティスチェックを実行し、AWS およびサードパーティサービスからのアラートを集約し、修復手順を提案します。しかし、多数の AWS アカウントにわたってこれらのアラートを処理し、修復を実施することは、運用上すぐに困難な状況になることがあります。 AMS は Amazon GuardDuty を活用して、お客様が契約しているすべての AWS アカウントの脅威を監視し、そこから生成されるすべてのアラートを 24 時間 365 日体制でレビューします。AMS は GuardDuty アラートを分析する自動化技術を駆使し、誤検知を減らして、初期トリアージ（優先度判定）を行い、インシデント通知の一環として実用的な対応策を提供します。重大な問題については、AMS は積極的にお客様と連携して共同セキュリティ調査を実施し、修復に必要な承認を取得します。AMS は Amazon Macie の検出結果を監視し、お客様に代わって必要な修復を実施することもできます。 モニタリングとインシデント対応（Monitoring and Incident Response） Amazon CloudWatch はオブザーバビリティのための AWS ネイティブの基盤サービスで、インフラ、アプリケーション、およびエンドユーザーモニタリングにわたる機能を提供します。Systems Manager の OpsCenter により、オペレーションスタッフは CloudWatch や AWS Config などのサービスによって特定された運用上の問題を表示・調査・修復できます。Systems Manager の Incident Manager 機能は、自動化された対応計画を使用して重要なアプリケーション問題をより迅速に解決するのに役立ちます。OpsCenter と Incident Manager は、Atlassian Jira や ServiceNow などの ITSM およびチケットシステムと統合して、お好みのツールでインシデントの包括的なビューを提供します。Incident Manager は Amazon Q Developer in chat applications とも連携しており、Slack、Microsoft Teams のようなコラボレーションツールを使用して、インシデントの調査や修復対応を行うことができます。(※1) AMS は、世界各地の複数のサイトに配置されたエンジニアによる 24 時間 365 日のセキュリティ監視とインシデント対応を通じて、クラウドでの運用上の優秀性の達成を支援します。アラートとイベントは AWS Config、Amazon GuardDuty、Amazon Macie、Amazon CloudWatch、 AWS CloudTrail などのネイティブサービスから監視されます。セキュリティインシデント対応（ SIR ）については、AMS は事前定義された National Institute of Standards and Technology （NIST）準拠のランブック（対応手順書）に従い、セキュリティアラートに対して、特定・分析・封じ込め・根絶・復旧の対応を行います。AMS は Systems Manager の OpsCenter を使用してすべての運用項目をログに記録し、AWS サポートケースを通じて通知し、お客様のチームと連携して解決します。Security Incident and Event Management （SIEM）や Endpoint Detection and Response （EDR）などサードパーティまたは自社開発のセキュリティツールを使用している場合、AMS はそれらによって報告された OS および AWS インフラ関連の検出結果を修復する支援も行うことができます。また、 AWS Service Management Connector を ServiceNow や Atlassian Jira などの ITSM ツールと統合して、AMS とのシームレスなインシデント・チケット対応を実現することもできます。(※2) コンプライアンス（Compliance） AWS の責任共有モデルの下、お客様はゲスト OS、アプリケーションソフトウェア、および AWS アカウント内の AWS サービスの設定と選択に関して、セキュリティとコンプライアンスの責任を負います。さらに、ビジネスニーズに応じて幅広いローカル・グローバルのコンプライアンスフレームワークに準拠する必要があり、それらのフレームワークを AWS セキュリティコントロールにマッピングすることは困難な場合があります。 AMS を使用することで、AWS における全体的なセキュリティ体制を強化するだけでなく、必要なコンプライアンスレベルへの到達を加速できます。まず、AMS というサービス自体が、 HIPAA 、 SOC 、 ISO27001 、 FedRAMP 、 IRAP 、 NIST 、 PCI-DSS 、 GDPR など、多くのグローバルなコンプライアンスフレームワーク、規制、セキュリティ基準に適合し、準拠しています（詳細は AWS コンプライアンスセンター を参照）。そのため、AMS によって管理されるクラウド環境は、特定のコンプライアンス要件や規制要件が求められるアプリケーションをホストするのに適しています。 次に、AMS では利用開始初日から、AWS Config を活用することで、CIS、NIST、PCI、HIPAA という、極めて厳格かつ多岐にわたる 4 つのグローバル・セキュリティ・フレームワークに対するお客様のセキュリティ体制を完全に可視化できます。AMS は、厳選された AWS Config Rules をデプロイし、お客様のアカウント内のリソース状態を継続的に監視することで、これらのコンプライアンス基準やフレームワークの要件への準拠を維持します。これらのルールは、ビジネスのニーズに応じて、自動修復を行うか、インシデントやレポートとして通知を行うかのいずれかに設定することが可能です。例えば、AMS では、AMS アカウント内で AWS CloudTrail によるログ記録がデフォルトで有効化されており、これが必要なときにいつでも行えるレポート作成、アラート通知、および監査に利用されます。この設定だけでも、セキュリティ基準である NIST SP 800-53 の監査と責任（AU）コントロールファミリーにおける AU-06/07（a-c, 1-4） や、ISO 27001 のコントロール A.12.4.1-3 といった複数の管理策を満たす上で有効です。 さらに、AMS はコンプライアンス要件を強化するために、OS レベルと AWS アカウントレベルの両方において、中央集権型のログ記録および監査コントロールを実装しています。AWS アカウント内で行われたユーザーアクセスや変更に関する監査レポートは、 Amazon Athena コンソール経由で、AMS が事前構築した厳選されたクエリを使用して簡単に抽出することができます。 レポートとガバナンス（Reporting & Governance） AWS クラウド環境全体におけるセキュリティ体制や潜在的なリスクを測定・追跡するためには、強固なレポート機能とガバナンスの実践が不可欠です。Key-Value のペアを使ってメタデータを作成する AWS Resource Tagging は、監査、自動化、およびコスト配分を通じて、運用上の優秀性を達成するために極めて重要な役割を果たします。例えば、AWS のメタデータやタグの値は任意の AWS ストレージサービスにエクスポートすることができます。これにより、 AWS Glue 、 Amazon Athena 、 Amazon Quick Sight といったサービスを活用して、パッチ適用状況やセキュリティコンプライアンスのカバー率に関するレポート、あるいはその他のダッシュボードを構築できます。 AMS は、OS のパッチ適用レベル、バックアップのカバー率、および高緊急度のインシデントに関するレポートを、毎週・毎月セルフサービスで提供します。また、お客様専任の AMS Cloud Service Delivery Manager（CSDM）と Cloud Architect（CA）が信頼できるアドバイザーとして、月次ビジネスレビューを主導します。このレビューでは、管理されているすべての AWS アカウントを横断した中央集中型の追加レポートが提供されます。月次ビジネスレビューには、 AWS Well Architected Framework の各柱にわたる主要なクラウド運用リスクへの洞察と高緊急度のアラートに対処するための将来的な計画が含まれています。 AMS のタグまたはお客様独自のカスタムタグを強制適用するために、AMS 管理下にある AWS リソースでは、AMS が提供する Resource Tagger ツールを活用できます。監査やレポート作成に加えて、AMS 固有のタグを使用することで、アクセス制御、監視、パッチ適用、バックアップ、および自動修復にわたる自動化アクションが可能になります。この AMS Resource Tagger とお客様のカスタムタグを組み合わせることで、クラウドガバナンスのための強固なタグ付け戦略を構築できます。 セキュリティオンデマンド（Security On-Demand） AMS は、 Operations on Demand （OOD）サービスを通じて、必要なときに拡張セキュリティサポートを提供しています。AMS OOD を活用することで、AWS サービスに関する変更を行い、AWS クラウドにおけるセキュリティ体制をさらに向上させることができます。このサービスには、既知の、あるいは未対策のセキュリティ脅威から保護するためのセキュリティ関連サービスカタログが含まれており、AWS Network Firewall の運用や、サポート終了が迫っているレガシー OS のアップグレードなどに対応しています。 おわりに 本記事では、AWS クラウドにおけるセキュリティ体制を強化するために実装できる、予防・検出・対応の管理を含む、多くの不可欠なセキュリティベストプラクティスを検討しました。また、お客様の AWS クラウド環境を管理することで、求められる「クラウドにおけるセキュリティ」を実装する信頼できるパートナーとして、どのように AMS を活用できるかを説明しました。AMS は、AWS のベストプラクティスを用いた複数のガードレールの実装に加え、24 時間 365 日のセキュリティインシデント対応および復旧を行うことで、クラウドのセキュリティ体制を強化します。さらに、AMS は初日からお客様の AWS アカウントにログ記録、監査、監視に関する多くの必要なセキュリティ統制とベストプラクティスの導入を支援し、コンプライアンスへの取り組みを加速させます。 セキュリティ特有の機能にとどまらず、AMS はインフラや OS の能動的な監視、アラートの自動復旧、コスト最適化、そして継続的なガバナンスの組み合わせにより、大規模なお客様の AWS クラウド環境における運用上の優秀性の達成を支援します。詳細については、 AWS Managed Services の製品ページをご覧ください。 ※1 2025 年 11 月 7 日に AWS Systems Manager Incident Manager は新規のお客様への提供を終了しました。AWS は引き続き Incident Manager のセキュリティと可用性への投資を継続し、既存の Incident Manager のお客様は、すでに Incident Manager が有効化されているアカウントにおいて、これまで通りサービスを引き続きご利用いただけます。 ※2 2026 年 3 月 31 日に AWS Service Management Connector は新規のお客様への提供を終了しました。既存のお客様は、2027 年 3 月 31 日までサービスを引き続きご利用いただけます。2027 年 3 月 31 日以降、AWS Service Management Connector の機能にアクセスすることはできなくなります。AWS パートナーソリューションへの移行、または直接的な SDK 統合の構築をお勧めいたします。 翻訳はシニアオペレーションズマネージャーの木村が担当しました。 原文はこちら です。 Nitin Verma Nitin は、クラウドオペレーション、自動化、セキュリティにおいて 10 年以上の専門知識を持つプリンシパルソリューションアーキテクトです。お客様が運用上の優秀性を達成し、AWS 上でのクラウドジャーニーを加速できるよう支援することを専門としています。Nitin の重点分野には、クラウドアーキテクチャ、IaC（Infrastructure as Code）、DevSecOps、AIOps などの新興テクノロジーが含まれます。 LinkedIn でフォローできます。 Amit Gupta Amit は、インフラストラクチャセキュリティオペレーションおよび AWS Managed Services（AMS）を専門とするシニアセキュリティエンジニアです。サイバーセキュリティにおいて 10 年以上の経験を持っています。セキュリティインシデント対応やセキュリティリスク管理のバックグラウンドを有しています。適切な戦略と設計により、お客様のサイバーセキュリティリスクを最小限に抑えることを支援することに注力しています。 TAGS: AWS Managed Services (AMS) , Cloud Operations , Management and Governance , Security

自己紹介とインターン参加の理由 自己紹介 公立はこだて未来大学 情報システム科学部 情報アーキテクチャ学科3年の阿部大晟と申します。 大学では主に情報デザインについて学んでおり、現在は数年後の未来で使われるアプリを制作するプロジェクトに携わっています。開発においては、フロントエンド側のUI/UX設計や、チームの進捗管理を担当することが多いです。 趣味はゲームや小説、アニメ鑑賞など日本のサブカルチャー全般です。 サイオスのインターンを選んだ理由 大学での説明会をきっかけに参加を決めました。目的は以下の3点です。 実際の現場で必要な能力の把握と習得 AI駆動開発の正しい手法の習得 （特に「Claude Code」を使用できる点） 就職活動に向けた実践的な学習 加えて、社員の方々の人柄が良く、「一度お話してみたい」と感じたことも大きな決め手でした。 開発したプロダクト：学習支援アプリ「メタゼロ」 制作物の紹介 私たちAチームが10日間で開発したのは、大学生の「メタ学習時間」をゼロに近づける学習支援アプリ 「メタゼロ（MetaZero）」 です。 「メタ学習時間」とは、学習を始める前に資料を探したり、勉強のスコープを定めたりする「探す・計画する・管理する」時間を指す私たちの造語です。 メタゼロは複数の大学サイトに分散した課題・試験情報を自動巡回して1枚の日程表に統合し、そこからAIとの対話で「いつ・何を・どれくらい」やるかの学習スケジュールを決定します。メタ学習時間削減により浮いた時間は、アップロードした資料から自動生成される模擬試験や一問一答に充て、学習そのものに集中してもらう狙いがあります。 私たちは 13画面と、AR実験機能まで実装 しました。 自分の役割 私は フロントエンド側を中心に担当し、UIデザインの方向性も決定 しました。 具体的にはタイトル画面や各種ロードマップの作成・UI調整、模擬試験などの画面実装です。 特にこだわったのは科目別ロードマップで、 「試験本番までの道のりをハニカム（六角形）で見せ、蜂がその日のセルを移動する」という演出 を作り込みました。 成果発表までの道のり ハッカソン形式で行われ、初日はアイスブレイクやセキュリティ研修がメインでした。その後、ワイヤーフレームを作成してイメージを共有しながら開発を進めました。 開発の軸となったのは、 「仕様書を唯一の正とする」こと 。仕様書をもとに「実装→レビュー→テスト」のループを回し続ける手法により、非常にスムーズに開発を進めることができました。 チーム開発を通じて気づいたこと、学んだこと コミュニケーションの大切さとコンフリクトからの学び 開発当初、「ワイヤーフレーム通りに実装すれば大丈夫だろう」と高を括り、大した相談もせず開発を進めていたため、コンフリクト（コードの衝突）が頻発してしまいました。また、途中でフロントエンドとバックエンドで担当を分けた際にも、連携の難しさを実感しました。 そこでチームでの進め方を見直し、 「バックエンド1人・フロントエンド2人」の層（レイヤー）で分担し、両方が触るデータの形（API）だけ事前合意した上で、それ以外は「〇〇を直す。影響ある人がいたら教えて」の一報だけで進めるルールに変更 しました。これにより承認待ちで手が止まることがなくなり、リモートでも開発スピードを維持できるようになりました。 この経験を通して、「短くても的確に伝わるコミュニケーション」の重要性を痛感しました。チームが連動して動くことで、結果的により良いものが生まれます。 コミュニケーションは他人のためだけでなく、「自分のため」でもあるの だと強く感じました。 「1コミット1関心事」とAIを活用した仕組みづくり 開発面では、 コミットを「1コミット1関心事」に徹底 し、メッセージの型（feat:, fix:など）と理由をGitフックで機械的に検査しました。また、AIエージェントを活用し、コードをレビューする役目と、テストの期待値を決める役目を実装者から切り離しました。 「指摘する人と直す人を分ける」「コードを1行も読まずに期待値を先に決める」仕組み により、期待値が実装に引きずられて甘くなるのを防ぐことができました。  SIOS Values（チームワークとパッション）の実践 サイオスが掲げる5つの指標のうち、私は特に 「チームワーク」と「パッション」を意識 しました。常に「チームワークが大事だ」と念頭に置き、環境づくりにも注力したことで、開発そのものも円滑に進むと感じました。 チームメンバーは優秀な方ばかりで、助けられてばかりでした。実装で手が止まった時や意見を求めたい時には必ず丁寧にサポートしてくれました。特に感心したのは、皆さんの物腰が柔らかく、自然と話しやすい環境になっていったことです。笑いながら作業できる和やかさがありつつ、決してたるんでいない、素晴らしい環境でした。 彼らがいなければこのアプリは完成しなかったと思います。  認識共有の難しさと「ほうれんそう」 開発で一番苦労したのは「認識の共有」です。 人が持つイメージは本人にしか100%理解できません。しかしチーム開発では複数人のイメージをすり合わせる必要があります。 これが想像以上に難しく、きちんと共有できていないと、いつの間にか見当違いの方向へ進んでしまうことが多々ありました。 人は間違えるからこそ、見当違いを防ぐ仕組みづくりが必要だ と学びました。 また、Claude Codeのような便利で作りやすいAIツールがあるからこそ、一歩立ち止まって考える時間が必要だと痛感しています。私は「これがあったら喜ばれるだろう」と良かれと思って独断で機能を追加実装してしまい、結果として重めのバグを残してしまうという失敗をしました。 便利だからと勢いで進めるのではなく、 仲間がいる以上、最低限の共有（ほうれんそう）は絶対に欠かしてはいけない と猛省しました。 最大の学びと、これからの目標 サイオスのインターンシップを通じて「エンジニア」のイメージが大きく変わりました。 最大の収穫は、 「エンジニアに一番大切なのはコミュニケーション能力である」と知れたこと です。 もともとエンジニアの仕事は、「頭をフル回転させて一人でコードを実装する」という イメージでした。 しかし実際は、時間の大半は「要件定義」に費やされます。またコードの実装自体も、Claude Codeなどのツールで代行できるケースが今後さらに増えていくからこそ、 最終的に差がつくのは人との対話力だと感じました。 私の中で、エンジニアとは 「プロジェクトのゴールを達成するために、仲間と話し合い、コミュニケーションを通じて物事を解決していく職業」 へと大きく変わりました。 私にとってこのエンジニア像のアップデートは、非常に大きなものでした。 今後の展望 今回のインターンを通じて、今後の自分に向けた明確な目標が2つできました。 1つ目は、 英語の学習 です。 コミュニケーションツールとして英語ができれば、国境の壁を越えてさまざまな人と円滑に連携が取れると感じたためです。 2つ目は、 セキュリティの学習 です。 開発速度が劇的に上がるこれからの時代だからこそ、セキュリティを深く理解していれば、より安心して技術を活用できるのではないかと考えています。 これからインターンを受ける後輩へ向けたアドバイスや応援の一言！ サイオスのインターンシップは、オンライン開催でありながら、社員の方々とのコミュニケーションの機会が豊富にあり、非常に有意義な10日間でした。 これからのIT業界で必要なスキルを、確実に学べるインターンだと思います。 今後参加される方は、ぜひ 「大いなる熱意」 をもって臨んでみてください。必ず素晴らしい経験になるはずです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post コンフリクトの頻発を乗り越え「報告・連絡・相談」でチームが団結！ first appeared on SIOS Tech Lab .

G-genの本間です。当記事では、Gemini Enterprise Agent Platform（略称 Agent Platform）が提供する、フルマネージドの AI エージェント実行基盤である Agent Runtime へ、エージェントをデプロイする際のデプロイ手法について解説します。 はじめに Agent Platform とは Agent Runtime とは 当記事について 5つのデプロイ手法 概要 1. Developer Connect を使用してデプロイする 2. ソースファイルからデプロイする 3. Dockerfile を使用してデプロイする 4. コンテナイメージを使用してデプロイする 5. Agent Platform SDK オブジェクトからデプロイする 選び方と使い分け はじめに Agent Platform とは Gemini Enterprise Agent Platform（旧称 Vertex AI、略称 Agent Platform ）は、AI エージェントを構築、管理、実行するために必要な機能を提供する Google Cloud の統合プラットフォームです。 このうち、エージェントの統制を担う機能として、エージェント固有の ID を発行する Agent Identity 、エージェントやツールを登録して検出可能にする Agent Registry 、これらを参照して通信を制御する Agent Gateway があります。 Agent Platform の全体像については、以下の記事を参照してください。 blog.g-gen.co.jp Agent Runtime とは Agent Runtime は、Agent Platform に内包されたプロダクトの1つで、エージェントを実行するためのフルマネージドの実行基盤です。Agent Runtime では、組み込みの機能として、エージェントのマルチターン会話を実現するセッション機能や自動スケーリング機能、その他エージェントの機能拡張・運用管理に必要な様々な機能を使用できます。 Agent Runtime の全体像については、以下の記事を参照してください。 blog.g-gen.co.jp 当記事について Agent Runtime に対してエージェントをデプロイするにあたり、デプロイ手法を5つのうちから選択できます。当記事では、それら5つの手法について概要を説明します。 参考 : Deploy an agent 5つのデプロイ手法 概要 Agent Runtime で使用可能な5つのデプロイ手法の概要は、以下のとおりです。 No. 名称 概要 1. Developer Connect を使用してデプロイ Developer Connect を介してリンクされた Git リポジトリから直接ソースコードを取得してデプロイする手法。 2. ソースファイルからデプロイ ローカルファイルシステム上のソースコードから直接デプロイする手法。 3. Dockerfile を使用してデプロイ ローカルのソースコードと Dockerfile を送信し、Agent Runtime 側でコンテナイメージを自動でビルドしてデプロイする手法。 4. コンテナイメージを使用してデプロイ Artifact Registry にホストされているコンテナイメージを指定してデプロイする手法。 5. Agent Platform SDK オブジェクトからデプロイ Colab などのノートブック環境で定義されたインメモリのエージェントオブジェクトを直接 Agent Platform SDK の関数に渡してデプロイする手法。 なお 2026年10月現在、Agent Runtime は Google Cloud コンソールや標準の gcloud CLI からの直接デプロイには対応していないため、いずれの方式を選択した場合でも、基本的には Agent Platform SDK （または REST API / ADK CLI）を使用し、コードベースでデプロイを実行する必要があります。 また5つのうち、いくつかの手法では、Terraform を用いたエージェントのデプロイや、インフラ基盤の設定管理も可能です。 1. Developer Connect を使用してデプロイする Google Cloud と GitHub や GitLab などの外部のソースコード管理システムを連携・統合するためのサービスである Developer Connect を使用し、Git リポジトリから直接デプロイする方式です。事前にリポジトリの接続設定を実施したうえで、Agent Platform SDK の developer_connect_source パラメータにリポジトリやブランチを指定してデプロイします。 この方式の場合、エージェントの実装に使用できるプログラミング言語は Python のみです。Developer Connect で Git リポジトリを接続する工数は発生しますが、Git 連携が可能となるため、バージョン管理と連動した継続的デリバリーの自動化に適しています。 参考 : Developer Connect の概要 2. ソースファイルからデプロイする ローカル環境のソースファイルから、Agent Platform SDK を使用して Agent Runtime へ直接デプロイする方式です。デプロイ実行時に、対象の開発ディレクトリやエントリーポイント、公開するメソッド定義を指定します。 この方式の場合も、エージェントの実装に使用できるプログラミング言語は Python のみです。Infrastructure as Code（以下、IaC）や GitHub Actions / Cloud Build などの標準的な CI/CD パイプラインに組み込むワークフローと親和性があり、他の選択肢と比較して導入工数が低い点が特徴です。ただし、デプロイ実行時に指定する開発ディレクトリの合計ファイルサイズが 8MB を超えてはいけないという制限があるため、仮想環境ディレクトリや巨大なアセットが含まれないよう注意が必要です。 3. Dockerfile を使用してデプロイする ローカルのソースファイルとともに、 Dockerfile を指定し、Agent Runtime 側でコンテナイメージの自動ビルドとデプロイを実行させる方式です。 この方式では、エージェントの実装に Python 以外のプログラミング言語を使用できます。また、コンテナ環境を定義できるため、OS レベルでのシステムパッケージのインストールや、エージェントをホストする API サーバーの細かい制御が必要な場合にも適しています。なお、ビルドされるコンテナは Agent Runtime が定める所定のランタイム契約（Runtime contract）に準拠している必要があります。詳細は以下の公式ドキュメントを参照してください。 参考 : Agent Platform runtime contract 4. コンテナイメージを使用してデプロイする 事前に Artifact Registry にビルド済みのコンテナイメージを push し、Agent Platform SDK でイメージ URI を指定して Agent Runtime へデプロイする方式です。実行にあたっては、Agent Platform のサービスエージェントに対して、対象の Artifact Registry の読み取り権限を付与する必要があります。 「Dockerfile を使用してデプロイする」方式と同様に、Python 以外のプログラミング言語でもエージェントの実装が可能であり、ランタイム契約への準拠が必要です。 Dockerfile 方式との主な違いは、 デプロイ時に Agent Runtime 側でビルドするか、事前ビルドしたイメージをデプロイするか という点です。「コンテナイメージを使用してデプロイする」方式は事前ビルドが完了しているため、デプロイ時のパッケージインストール等による待ち時間を最小化できます。 こちらの方式は、CI パイプライン上でコンテナの脆弱性スキャン等のセキュリティツールを通過したイメージのみを本番環境にデプロイするといった、厳格なガバナンス要件や「基盤管理と開発管理の分離」が求められるエンタープライズ環境に適しています。 参考 : Set up the environment - Identity and permissions 5. Agent Platform SDK オブジェクトからデプロイする Colab Enterprise や Agent Platform Workbench などのノートブック環境で定義したメモリ上の Python オブジェクトを、直接 Agent Platform SDK の関数に渡してデプロイする方式です。Python の pickle を用いてメモリ上のエージェントオブジェクトをシリアライズし、Cloud Storage バケットへアップロードします。その後、アップロードされたファイルをもとにコンテナがビルドされます。 この方式では、ノートブック環境でコードを書いて、その場でインタラクティブに動作検証や初期プロトタイピングを手軽に行えます。一方、シリアライズできない複雑なデータ構造や依存関係を持つオブジェクトには適用できず、手動実行が前提となるため、CI/CD パイプラインへの組み込みには適していません。 また、エージェントの実装に使用できるプログラミング言語は Python のみです。 参考 : Introduction to Colab Enterprise 参考 : Introduction to Agent Platform Workbench 選び方と使い分け ここまで紹介した Agent Runtime への5つのデプロイ手法は、主にそれぞれ 「エージェントの対応言語」「Cloud Storage バケットの要否」「カスタマイズ性」「CI/CD や IaC との親和性」 に違いがあります。 開発フェーズ（初期のプロトタイピングか、本番の CI/CD 運用か）や、チームが採用するプログラミング言語・セキュリティ要件に合わせて、以下の比較表を参考に最適なデプロイ手法を選択してください。 名称 エージェントの対応言語 Cloud Storage バケット CI/CD・IaC 適性 主なユースケース 主な特徴・制約事項 Developer Connect を使用してデプロイ Python のみ 不要 ◎ Git リポジトリと直結した継続的デリバリー Developer Connect の事前設定が必要。リポジトリから直接コードを取得してデプロイするため、複雑な事前ビルド処理を伴う運用には不向き。 ソースファイルからデプロイ Python のみ 不要 ◎ Terraform や GitHub Actions 等を用いた標準的な本番運用 Pickle 化を行わないため依存関係の再現性が高く、導入工数も低い。送信するソースコード合計サイズに 8MB の制限 あり。 Dockerfile を使用してデプロイ 任意の言語 （Go や Java 等も可） 不要 ◯ OS パッケージの追加や、Python 以外の言語を使用する場合 クラウド側でコンテナを自動ビルド。ランタイム契約への準拠が必要。 コンテナイメージを使用してデプロイ 任意の言語 （Go や Java 等も可） 不要 ◎ 厳格な脆弱性スキャンや、デプロイ時間短縮が求められる本番環境 Artifact Registry のビルド済みイメージを指定するため、デプロイ時のレイテンシが小さい。サービスエージェントへの権限付与とランタイム契約への準拠が必要。 Agent Platform SDK オブジェクトからデプロイ Python のみ 必須 △ Colab Enterprise 等のノートブック環境での初期プロトタイピング・検証 メモリ上のオブジェクトを pickle で直感的にデプロイ可能。シリアライズできない複雑な構造や CI/CD への組み込みには不向き。 どの方式を採用すべきか迷った場合は、開発のフェーズやプロジェクトの要件を整理したうえで検討してください。 手軽に動作を試したい初期検証フェーズの場合は、ノートブック環境からすぐに実行できる 「Agent Platform SDK オブジェクトからデプロイ」 や、比較的導入コストが低い 「ソースファイルからデプロイ」 から始めることを推奨します。 Python で開発したエージェントを本番運用へ移行し、CI/CD パイプラインへ組み込むフェーズでは、導入コストが低く Terraform などの IaC ツールとも組み合わせやすい 「ソースファイルからデプロイ」 、あるいは Git 連携の機能を十分に発揮できる 「Developer Connect を使用してデプロイ」 が選択肢に入ります。 Go や Java といった Python 以外のプログラミング言語でエージェントを実装する場合や、OS レベルのライブラリ追加といった環境カスタマイズが求められる場合には、 「Dockerfile を使用してデプロイ」 または 「コンテナイメージを使用してデプロイ」 を選択します。特にエンタープライズの本番環境において、CI パイプラインでのコンテナ脆弱性スキャンを必須とする場合や、スケーリング・デプロイ速度、基盤管理と開発管理の分離を重視する場合には、 「コンテナイメージを使用してデプロイ」 の採用が最適です。 本間 優太郎 (記事一覧) クラウドソリューション部 クラウドエンジニアリング2課 北海道在住 2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。 好きなことは子供と遊ぶこと、ゲームをすること。