こんにちは、阿部です。 前回 は、Prisma Cloudについての記事を投稿しましたが、今回はPrisma Cloudの後継製品であるCortex Cloudについて書いていきます。 Cortex Cloudには下記表の通りスキャンモードが２つあり、クラウド環境のオンボード時にどちらかを選択する仕様になっています。 今回は「Scan With Outpost」の方を選択してAWSアカウントをCortex Cloudにオンボードする方法を実際に試していきたいと思います。 スキャンモード 説明 備考 Cloud Scan スキャンをPaloAltoNetwoks社所有のCortex Cloud環境から実行 ※推奨はCloud Scan ■メリット ・スキャナーVM等のリソースはCortex Cloudの環境に作成されるため追加コストが発生しない ・オンボード時のエラー発生が比較的少ない ■デメリット ・スキャンされたデータがCortex Cloudのクラウドアカウント環境へ一時的に置かれるため、データを自社環境外に持ち出せない要件には不向き Scan With Outpost ユーザーが所有するクラウドアカウントにOutpost環境を作成し、Outpost環境からスキャンを実行 ■メリット ・スキャナーVM等のリソースもユーザーが所有するクラウドアカウント上に作成するため、データが外部環境に置かれることがない ■デメリット ・Outpost環境専用のクラウドアカウントの用意が別途必要 ・Outpost環境用の追加コストが発生 「Scan With Outpost」モードでオンボードするためには、事前にOutpost環境を作成しておく必要があります。 そのため、以下の流れで作業を進めます。 Outpost環境の作成 監視対象となるAWSアカウントのオンボード用テンプレートファイルの発行 監視対象となるAWSアカウントでのオンボード作業   Outpost環境の作成 まず、Outpost環境の作成から実施します。 Outpostの前提条件 Outpostを作成するクラウドアカウントは、Outpost専用のクラウドアカウントが必要です。Outpost専用のクラウドアカウントでは、他のリソースが使用されていない状態である必要があります。 クラウドアカウントには、1つのOutpostのみをホストできます。 Outpostを利用するには、クラウドプロバイダーからの追加許可が必要となり、追加のクラウド費用が発生する場合があります。 参考：https://docs-cortex.paloaltonetworks.com/r/Cortex-CLOUD/Cortex-Cloud-Posture-Management-Documentation/Outposts 事前準備 Outpost環境の作成は、Terraformで実行します。そのため、以下を準備する必要があります。 ローカルマシンにTerraformをインストール ローカルマシンにAWS CLIをインストール AWS CLIの実行に使用するIAMユーザーおよびアクセスキー リソースを作成する権限を上記IAMユーザーに付与（今回はAdministratorAccess権限で検証しました） TerraformのテンプレートファイルはCortex Cloudコンソール上からダウンロードします。 Terraformのインストール 以下の手順でTerraformをインストールします。 公式ページ からTerraformをダウンロード ダウンロードしたファイルを解凍し、「terraform.exe」を以下のフォルダに配置 C:\Windows\System32 コマンドプロンプトで以下のコマンドを実行し、バージョンが表示されることを確認できればインストール完了 # terraform version   AWS CLIのインストールおよび設定 以下の手順でAWS CLIをインストールします。 公式ページ の手順に従いAWS CLIをインストール コマンドプロンプトで以下のコマンドを実行し、バージョンが表示されることを確認できればインストール完了 # aws –version 以下のコマンドを実行し、Terraform実行に使用するIAMユーザーのアクセスキーとシークレットアクセスキーを設定。 # aws configure   接続してみる テンプレートファイルの発行 Outpost作成用のテンプレートファイルを以下の手順でダウンロードします。 Cortex Cloudコンソールにログインする [ Settings ] → [ Configurations ] → [ Data Collections ] → [ Outposts ] の画面を表示する 画面右上の [ New Outpost ] → [ AWS ] をクリック Cloud Tag（作成するリソースに付与するタグ）を追加したい場合は [ + Add Tag ] からタグを追加する ※今回は特に追加せず進めます [ Next ]をクリック [ Download Terraform ] をクリックしてファイルをダウンロードする テンプレートファイルには7日間の有効期限がある点に注意してください。 期限を過ぎてしまった場合は、再度テンプレートを発行する必要があります。   Terraformの実行 以下の手順でTerraformを実行し、Outpostを作成します。 ダウンロードしたテンプレートファイルを任意のフォルダに配置し解凍する。 コマンドプロンプトを起動し、以下のコマンドを実行して解凍したフォルダへ移動する。 # cd <解凍したフォルダ> 以下のコマンドを実行し、「 Terraform has been successfully initialized! 」と出力されることを確認する。 # terraform init 以下のコマンドを実行する。 しばらく待つと「Only ‘yes’ will be accepted to approve. 」と表示されるので、「 yes 」を入力する。           # terraform apply –var-file=template_params.tfvars 「 Apply complete! 」と表示されることを確認する。 以下のファイルはOutpost環境の削除やアップデートに必要になるため、 必ず保管 しておくこと。 テンプレートファイル（Outpost用のtar.gzファイル） Terraformを実行すると実行フォルダ内に作成される末尾が.tfstateのファイル   Cortex Cloud上で確認 [ Settings ] → [ Configurations ] → [ Data Collections ] → [ Outposts ] の画面を表示し、作成したOutpostが表示され、ステータスがConnectedになっていることを確認します。   以上でOutpost環境の作成は完了です。   監視対象となるAWSアカウントのオンボード用テンプレートファイルの発行 Outpost環境が作成できたら、監視対象のAWSアカウントをオンボードするためのテンプレートファイル（CloudFormationテンプレート）を以下の手順で発行します。 Cortex Cloudコンソールにログインする [ Settings ] → [ Data Sources & Integrations  ] の画面を表示する 画面右上の [ + Add New ] → [ AWS ] → [ Add Another Instance ] をクリック 以下の通り選択し、「Show advanced settings」をクリック 項目名 設定値 備考 Scope 今回はAccountを選択   Scan Mode Scan With Outpost を選択   Choose Outpost 作成したOutpostを選択 作成したOutpostが選択肢として表示される 事前にOutpostを作成しておく必要があるのは、上記のChoose Outpostという項目でOutpostを選択するためです。 詳細設定の各項目を入力・選択し、「Save」をクリック　※今回は基本デフォルトから変更せず進めました 項目名 説明 Instance Name オンボードする環境を示す任意の名前を入力 Scope Modifications ・全リージョン監視の場合は変更不要 ・リージョンを絞る場合は「Modify Scope by Regions」を有効化して指定(Include)または除外(Exclude)するリージョンを選択 Additional Security Capabilities 有効にする機能を選択 Cloud Tags 追加するとCortex Cloud用に作成するAWS側リソースにタグを追加で付与可能 Collect Audit Logs ・デフォルト（Use Automated collection）だとCortex Cloud用にCloudTrail等が新規作成される ・Custom (user defined)を選択すると既存のCloudTrailを指定可能 [ Download CloudFormation ] をクリックし、テンプレートファイルをダウンロードする テンプレートファイルには7日間の有効期限がある点に注意してください。 期限を過ぎてしまった場合は、再度テンプレートを発行する必要があります。 以上で監視対象のオンボード用テンプレートファイルの発行は完了です。   監視対象となるAWSアカウントでのオンボード作業 発行したCloudFormationテンプレートを監視対象のAWSアカウントで実行してCortex Cloudにオンボードします。 CloudFormationテンプレートの実行 監視対象のAWSアカウントにAdministratorAccessのIAMポリシーが付与されているIAMユーザでログイン [ CloudFormation ] > [ スタック ] の画面に遷移し、[ スタックの作成 ] > [ 新しいリソースを使用(標準) ] をクリック [ 既存のテンプレートを選択 ] および [ テンプレートファイルのアップロード ] を選択 [ ファイルの選択 ] を押下して、ダウンロードしたテンプレートファイルをアップロードし、[ 次へ ] をクリック 任意のスタック名を入力し、画面下部の [ 次へ ] をクリック 画面下部の「AWS CloudFormationによってIAMリソースがカスタム名で作成される場合があることを承認します」にチェックを入れ、[ 次へ ] をクリック 確認画面下部の [ 送信 ] をクリック [ イベント ] タブで、スタック名の論理IDのステータスが「CREATE_COMPLETE」であることを確認 AWSアカウント側でスタックが完了すると、作成されたリソース情報がCortex Cloudに通知される仕組みとなっています。 これでAWSアカウント側での作業は完了です。 Cortex Cloud上で確認 [ Settings ] → [ Data Sources & Integrations  ] の画面からAWSを表示して、CloudFormationテンプレートを実行したAWSアカウントがオンボードされていることを確認します。   以上で「Scan With Outpost」モードでのAWSアカウントのオンボード作業がすべて完了しました。   まとめ 今回は、Outpost環境の作成からScan With OutpostモードでのAWSアカウントのオンボードまで確認できました。 次回以降で、AzureでのOutpost環境作成や、Outpost環境をリージョンを絞って作成する方法等も紹介できればと思います。 また、当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp ご興味のある方は是非、お気軽にお問い合わせください。

3 月下旬、世界中の AWS スペシャリストが集まる最も活気あふれるイベントの 1 つである Specialist Tech Conference のために、シアトルを訪れました。同僚とつながり、経験について意見を交換し、生成 AI と Amazon Bedrock の最新の進歩について深く知る、素晴らしい機会でした。また、このイベントは、私が心の底から信じていることをしっかり思い出させてくれました。それは、スペシャリストが集まってお互いに挑戦し、エッジケースを探り、ソリューションを共同で作成するとき、その影響は会議室にとどまらない、ということです。AI のように変化の速い分野では、強力な内部コミュニティを持つことは「あれば便利なもの」ではなく「競争上の優位性」です。 それでは、2026 年 4 月 27 日週の AWS ニュースを見ていきましょう。 ヘッドライン Anthropic パートナーシップ: AWS Trainium と Graviton での Claude、Amazon Bedrock の Claude Cowork – 2026 年 4 月 27 日週、AWS と Anthropic は、ビルダーにとって有意義な方法で製品コラボレーションを深めました。Anthropic は現在、ハードウェアからフルスタックまでの計算効率を最大化するために、最先端の基盤モデルを AWS Trainium および Graviton インフラストラクチャでトレーニングしています。Annapurna Labs とシリコンレベルで直接共同エンジニアリングを行っています。 Claude Cowork が Amazon Bedrock で利用可能に – Claude Cowork は、Anthropic のコラボレーティブ AI 機能を AWS エコシステム内のエンタープライズビルダーに直接提供することで、チームが単なるツールではなく、真のコラボレーターとして Claude と連携できるようにします。Claude Cowork を既存の Amazon Bedrock 環境にデプロイできるようになりました。これにより、AWS 内のデータを安全に保ちながら、チームベースの AI ワークフローに Claude の全機能を活用できます。 Claude Platform on AWS (近日公開予定) – AWS を離れることなく Claude 搭載アプリケーションを構築、デプロイ、スケールするための統合型の開発者エクスペリエンスです。AWS で生成 AI を使用して構築している場合、これは大きな 1 歩になります。Amazon Bedrock を通じて Claude と直接実行できることが増えたのです。 Meta が Amazon の Graviton チップ上のエージェンティック AI を強化するために AWS と契約を締結 – Meta は、AWS Graviton プロセッサを大規模にデプロイする契約を締結しました。リアルタイムの推論、コード生成、検索、多段階のタスクオーケストレーションなど、CPU 集約型のエージェンティック AI ワークロードを強化するために、まずは数千万の Graviton コアを起点とします。 2026 年 4 月 20 日週のリリース 2026 年 4 月 20 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 AWS Lambda 関数が S3 ファイル付きのファイルシステムとしての Amazon S3 バケットのマウントを開始 – S3 ファイルを使用して、Amazon S3 バケットを AWS Lambda のファイルシステムとしてマウントできるようになりました。これにより、処理用のデータをダウンロードしなくても関数は標準的なファイル操作を実行できます。Amazon EFS 上に構築された S3 Filesは、S3 のスケーラビリティ、耐久性、費用対効果を兼ね備えたシンプルなファイルシステムを提供します。また、複数の Lambda 関数が同じファイルシステムに同時に接続して、共通のワークスペースを通じてデータを共有できます。これは、エージェントがメモリを永続化し、パイプラインステップ全体で状態を共有する必要がある AI や機械学習のワークロードに特に役立ちます。 ハイブリッド Kubernetes ネットワーキング用の Amazon EKS Hybrid Nodes ゲートウェイ – Amazon Elastic Kubernetes Service が Amazon EKS Hybrid Nodes ゲートウェイの提供を開始しました。これにより、EKS クラスター VPC と EKS Hybrid Nodes で実行されている Kubernetes ポッド間のネットワーキングが自動化されます。そのため、オンプレミスのポッドネットワークをルーティング可能にしたり、ネットワークインフラストラクチャの変更を調整したりする必要がなくなり、ハイブリッド Kubernetes 環境が大幅に簡素化されます。ゲートウェイは、クラウド環境とオンプレミス環境にわたるポッド間トラフィックやコントロールプレーンからウェブフックへのコミュニケーションを自動的に有効にし、Application Load Balancer などの AWS サービスの接続性を制御します。また、追加料金なしで利用できます。 Amazon Aurora Serverless: 最大 30% 向上したパフォーマンス、スマートなスケーリング、スケーリングゼロは継続 – Amazon Aurora Serverless は、以前のバージョンと比較してパフォーマンスが最大 30% 向上し、高速かつスマートになりました。また、負荷の多い API や、アクティビティが急増してアイドル時間が長くなるエージェンティック AI アプリケーションなど、複数のタスクがリソースをめぐって競合するワークロードを処理できるように設計された拡張スケーリングアルゴリズムを備えています。さらに要求の厳しいワークロードをサーバーレスで実行できるようになりました。お支払いは使用した分のみで、使用しないときは自動的にゼロにスケーリングされます。プラットフォームバージョン 4 では、すべての機能強化を追加費用なしでご利用いただけます。 Amazon Bedrock AgentCore に、開発者がより迅速にエージェントを構築するのに役立つ新機能を追加 – Amazon Bedrock AgentCore では、マネージドハーネス (プレビュー)、AgentCore CLI、コーディングアシスタント用の AgentCore スキルが導入され、開発者がアイデアから実際のエージェントプロトタイプにすばやく移行できるようになりました。マネージドハーネスでは、モデル、システムプロンプト、ツールを指定してエージェントを定義し、オーケストレーションコードを必要とすることなくすぐに実行できます。完全に制御する準備ができたら、ハーネスオーケストレーションをストランドベースのコードとしてエクスポートできます。AgentCore CLI は、コードとしてのインフラストラクチャ (現時点で利用できる AWS CDK、近日提供予定の Terraform) のガバナンスと監査機能を利用してエージェントをデプロイし、14 の AWS リージョンで追加料金なしで利用できます。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 以下は、皆さんが関心を持つと思われる追加の記事とリソースです。 Amazon Bedrockのきめ細かなコストアトリビューションのご紹介 – この投稿では、Amazon Bedrock のきめ細かなコストアトリビューションの仕組みを説明し、コスト追跡シナリオの実用例をご紹介します。Bedrock の使用コストをより詳細にタグ付けして追跡できるようになりました。これは、Bedrock で複数のチームやプロジェクトを運営しており、正確なコスト可視性とチャージバック機能を必要とする組織に役立ちます。 AWS DevOps エージェントと Salesforce MCP サーバーを使用したインシデント調査の自動化 – この記事 (Salesforce との共同執筆) では、Salesforce MCP サーバーと統合された AWS DevOps エージェントが、問題の特定や根本原因の診断から Salesforce Service Cloud を通じた顧客への通知まで、インフラストラクチャインシデント調査のライフサイクル全体を自動化する方法を示しています。これは、AI エージェントと MCP ベースのツール接続によって本番環境の DevOpsワークフローがどのように再構築され、解決までの平均時間が大幅に短縮されているかを示す説得力のある実例です。 AWSの Microcredentials が無料に。これが重要な理由はこちら – プラットフォームが提供されているすべての国で、AWS Skill Builder を使用して AWS Microcredentials に無料でアクセスできるようになりました。従来の多肢選択式の認定とは異なり、Microcredentials は、ビルダーが実際の AWS 環境で直接設定、トラブルシューティング、最適化を行う実践的な評価であり、実際の業務に似せてシミュレートされたビジネスシナリオで実施されます。コスト面での障壁を気にすることなく、実際のクラウドスキルを検証する絶好の機会です。 Amazon SageMaker AI が最適化された生成 AI 推論の推奨事項のサポートを開始 – Amazon SageMaker AI を使用して、インスタンスタイプ、コンテナ、推論パラメータなど、生成 AI モデルに最適なデプロイ設定を自動的に識別できるようになりました。この新機能により、推論インフラストラクチャのチューニングを推測する必要がなくなり、本番環境での AI アプリケーションのコスト削減とレイテンシーの改善に役立ちます。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 What’s Next with AWS – 4 月 28 日に開催される What’s Next with AWS にご参加ください。これは、AWS チームから直接寄せられた最新の発表や製品アップデートを紹介するバーチャルイベントです。今週のリリースを確認する前に、最新情報を入手する絶好の機会です。 AWS Summit – AWS Summit は無料の対面イベントです。クラウドと AI のイノベーションの最新情報を確認したり、ベストプラクティスを学んだり、ビルダーや専門家と交流したりできます。5 月の開催予定: シンガポール (5 月 6 日)、 テルアビブ (5 月 6 日)、 ワルシャワ (5 月 6 日)、 ストックホルム (5 月 7 日)、 シドニー (5 月 13 日～14 日)、 ハンブルク (5 月 20 日)、 ソウル (5 月 20 日)、 アムステルダム (5 月 27 日)、 バンコク (5 月 28 日)、 ミラノ (5 月 28 日)、 ムンバイ (5 月 28 日)そして 6 月には、ロサンゼルス (6 月 10 日) にぜひご参加ください。全スケジュールを確認し、上記のリンクからご登録ください。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供し、テクニカルディスカッション、ワークショップ、ハンズオンラボが行われるコミュニティ主導のカンファレンスです。今後のイベントには、ギリシャのアテネ (4 月 28 日)、カナダのバンクーバー (5 月 1 日)、トルコのイスタンブール (5 月 9 日)、パナマのパナマシティ (5 月 23 日) などがあります。ラテンアメリカにお住まいの場合は、AWS Community Day ベロオリゾンテ (8 月 22 日) への参加をご検討ください。ご登録は awscommunityday.com.br で受け付けています。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 こちら から、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベントとデベロッパー向けのイベントをご覧いただけます。 2026 年 4 月 27 日週のニュースは以上です。2026 年 5 月 4 日週の Weekly Roundup もお楽しみに! – Daniel Abib この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースや発表を簡単にまとめて毎週ご紹介します! 原文は こちら です。

G-gen の高宮です。当記事は、Google Cloud Next '26 in Las Vegas の 3 日目に行われたブレイクアウトセッション「 Accelerate CI/CD with coding agents 」のレポートです。 G-gen Tech Blog では、現地でイベントに参加したメンバーや、日本から情報をウォッチするメンバーが、Google Cloud Next '26 に関連する記事を発信します。 blog.g-gen.co.jp セッションの概要 ソフトウェア開発の加速と CI/CD の課題 Google CI/CD Extension の概要と特徴 Google CI/CD Extension を用いたデモ 1. Cloud Run への自動デプロイとシークレットスキャン 2. 複数ステージの CI/CD パイプライン設計 3. Terraform による Infrastructure as Code の生成 セッションの概要 本セッションでは、Google の Haroon Chaudhry 氏（Software Development Manager）と Yeshwanth Gunasekaran 氏（Software Engineer）が登壇しました。 セッションでは、生成 AI を用いてコードを記述した後、本番環境へデプロイするまでの CI/CD パイプライン構築に関する課題と、それを解決するための新しい拡張機能である Google CI/CD Extension が発表され、デモを交えて紹介されました。 ソフトウェア開発の加速と CI/CD の課題 2026年4月現在、生成 AI の普及により、開発者の 90% が日常的に AI を使用しています。しかし、AI によって生成されたアプリケーションを本番環境へデプロイする際、約 60% の開発者が課題に直面していると語られました。安全な CI/CD パイプラインを構築するには、単にスクリプトを生成するだけでなく、多様なツールが混在する複雑な環境全体を適切に制御する必要があるからです。 複数の CI/CD プラットフォームの利用、DevSecOps ツールの統合、インフラストラクチャとコードの連携などの課題により、AI の CI/CD 領域での採用率は 27% に留まっています。AI エージェントは単なるコード生成ツールから、インフラストラクチャ全体を統合するオーケストレーターへと進化する必要があることが強調されました。 Google CI/CD Extension の概要と特徴 この課題を解決するため、Gemini エージェントを統合オーケストレーターとして機能させる Google CI/CD Extension が発表されました。 この拡張機能は、 Gemini CLI の拡張機能および Claude Code プラグインとして利用可能であり、オープンソースとして提供されます。 Cloud Run や Google Kubernetes Engine （GKE）などのランタイムに対応しており、自然言語を用いて CI/CD パイプラインの設計、構築、デプロイを行うことができます。 参考 : Gemini CLIを解説 - G-gen Tech Blog 参考 : GitHub Repository : Gemini CLI Extension for CI/CD Google CI/CD Extension は、以下の 4 つのコンポーネントで構成されています。 コンポーネント 説明 Skills CI/CD パイプラインの設計やデプロイに関する事前定義されたワークフローと知識。 Local MCP Server ユーザーの認証情報で実行され、Google Cloud の CI/CD ツールを管理するローカルの Model Context Protocol サーバー。 Grounding through knowledge base CI/CD のベストプラクティスやデプロイメントパターンをパッケージ化したナレッジベース。 Offline Evals オープンソースや独自開発のプロジェクトにおける設計・デプロイパターンをテストする評価システム。 Google CI/CD Extension を用いたデモ 1. Cloud Run への自動デプロイとシークレットスキャン 最初のデモでは、Cloud Code を用いて Python の Flask アプリケーションを Cloud Run にデプロイする様子が示されました。エージェントはアプリケーションの構成を理解し、 Buildpacks を使用してコンテナイメージを構築します。 参考 : Google Cloud の Buildpack 注目すべき点として、コンテナイメージをクラウド上にプッシュする前に、ハードコードされた認証情報がないかを確認するシークレットスキャンが、拡張機能の組み込みチェックとして自動的に実行されました。安全性が確認された後、ユーザーがリージョンや公開設定を指定すると、Cloud Run へのデプロイが完了しました。 2. 複数ステージの CI/CD パイプライン設計 2 つ目のデモでは、Gemini CLI を使用して、 Cloud Build と Cloud Deploy を使用した複数ステージのパイプライン設計が行われました。 参考 : Cloud Build の概要 参考 : Cloud Deploy の概要 以下のプロンプトで指示すると、エージェントは自律的なパイプライン構築ステップを開始しました。 アプリケーション向けに、ステージング環境と本番環境を含む CI/CD パイプラインを設計してください。失敗時に自動ロールバックを行い、Cloud Build と Cloud Deploy を使用してください。 CI/CD パイプライン構築のステップは以下のとおりです。 No 概要 内容 1 要件定義と計画 専用の Skills（ google-cicd-pipeline-design 、 google-cicd-release-orchestration ）を使用し、Google のベストプラクティスに基づいた計画を立案。 2 デプロイパイプライン構成生成 各環境の Cloud Deploy 構成ファイルを生成。承認ゲートや自動ロールバックルールを自動で組み込み。 3 インフラセットアップ Developer Connect による GitHub 接続、 Artifact Registry 作成、最小権限の IAM ロールを付与したサービスアカウントを準備。 4 ビルド構成の実装 Cloud Build 構成ファイルを作成。リポジトリへのプッシュをトリガーとしたエンドツーエンドのフローを完成。 参考 : google-cicd-pipeline-design 参考 : google-cicd-release-orchestration 参考 : 構成スキーマ リファレンス 参考 : ビルド構成ファイルを作成する 3. Terraform による Infrastructure as Code の生成 最後のデモでは、設計された CI/CD パイプラインのインフラストラクチャを、 Terraform を用いたコードとして生成する様子が披露されました。元のプロンプトに 「Terraform を生成して。」 の1文を追加するだけで、エージェントは専用の Skills google-cicd-terraform を呼び出し、必要な設定ファイルを出力します。 参考 : google-cicd-terraform 生成されたファイルには、Artifact Registry、Cloud Build、Cloud Deploy の設定に加え、専用のサービスアカウントや厳格な IAM ロールの付与までがコード化されており、本番環境レベルのパイプライン構築が対話のみで完結することが示されました。 高宮 怜 (記事一覧) クラウドソリューション部クラウドエクスプローラ課 2025年6月より、G-genにジョイン。前職は四国のSIerで電力、製造業系のお客様に対して、PM／APエンジニアとして、要件定義から運用保守まで全工程を担当。現在はGoogle Cloudを学びながら、フルスタックエンジニアを目指してクラウドエンジニアとしてのスキルを習得中。 Follow @Ggen_RTakamiya