みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 7 月 28 日（火）に「 AWS Bedrock LLM Day Japan 」が東京 赤坂インターシティにて開催されます。AWS Summit New York で発表された最新のサービスアップデートを日本のお客様向けにいち早くお届けするとともに、Amazon Bedrock上でのAnthropic・OpenAIモデルの活用法や、AIエージェント構築基盤AgentCoreの最新機能を実践的に解説します。ぜひご参加ください！ 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは、7 月 6 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「エムシーディースリー株式会社様：AI-DLC Unicorn Gym による3日間の開発変革」を公開 三菱商事グループの一員として産業 DX を推進するエムシーディースリー株式会社様と実施した、AI 駆動開発ライフサイクル（AI-DLC）の体験型プログラム「Unicorn Gym」のレポートです。7 つのチームが Kiro を活用して実際のプロダクト課題や業務課題に挑み、3 日間で商用レベルに近いアプリケーション開発やレガシー環境のコンテナ化を実現した様子と、各チームが得た学び・活用の工夫を紹介しています。 ブログ記事「フロンティアモデルの安全なリリースに向けた AWS の取り組み」を公開 Anthropic の Claude Fable 5 が、悪用を防ぐためのさらに強力なガードレールを備えて Amazon Bedrock で再び利用可能になりました。本ブログでは AWS の CISO である Amy Herzog が、Project Glasswing を通じた Anthropic との連携のもと、サイバーセキュリティ分野で強力な能力を持つフロンティアモデルを防御側に届けつつ、攻撃者への悪用を防ぐための考え方を説明しています。ガードレール作動時には Opus 4.8 に自動フォールバックする仕組みも紹介されています。 ブログ記事「Amazon Bedrock のゼロデータ保持の強制方法」を公開 Claude Fable 5 のようにモデルプロバイダーとのデータ共有を必要とするモデルの登場を受けて、Amazon Bedrock のデータ保持モード（none / default / inherit / provider_data_share）の仕組みを解説しています。Amazon Bedrock Projects によるプロジェクト単位のきめ細かい制御や、サービスコントロールポリシー（SCP）で組織全体にゼロデータ保持を強制する方法を、具体的なポリシー例と検証手順付きで紹介しています。データガバナンス要件のある組織の方は必見です。 ブログ記事「【公共向け】Claude Mythos 時代の脅威対策ワークショップ開催報告 & 耐障害性ライフサイクル実践ワークショップのご案内」を公開 パブリックセクターのお客様向けに月次開催しているセキュリティワークショップの第 3 回・第 4 回の開催レポートです。「Claude Mythos 時代の脅威への対応」をテーマに、Amazon Inspector による脆弱性管理・パッチ運用自動化と、AWS Security Agent による設計レビュー・コードレビュー・自動ペネトレーションテストのハンズオンを実施しました。ワークショップ教材は 一般公開 されていますので、ぜひお試しください。 ブログ記事「AWS パートナーと実現する生成 AI — 現場を変える8つの実践事例 AWS Summit Japan 2026 Partner Breakout Session レポート」を公開 AWS Summit Japan 2026 で 4 部構成にてお届けした Partner Breakout Session のレポートです。東邦ガス情報システム様の Kiro 導入、青森放送様の Amazon Bedrock を活用した文字起こしシステム、品川区様の音声 AI 実証、日本取引所グループ様の GraphRAG による暗黙知の形式知化など、8 組の AWS パートナーとお客様による実践事例のハイライトと、全セッションを通して見えてきた「AI の価値を現場で実現するために本当に必要なこと」を紹介しています。 ブログ記事「AWS Parallel Computing Service と Kiro CLI で HPC のデプロイを加速する」を公開 従来数週間かかっていた HPC クラスターのデプロイを、Kiro CLI のカスタムエージェントで自動化する方法を紹介しています。AWS PCS のベストプラクティスを組み込んだエージェントとの対話だけで、ネットワーク、コントローラー、キュー、コンピュートノードを備えたクラスターを約 30 分で構築する手順を、 デモリポジトリ とともに順を追って解説しています。 ブログ記事「Kiro の超過利用の上限設定と前払い機能のご紹介」を公開 Kiro の超過利用 (overage) の支出をコントロールする 2 つの新機能を紹介しています。IAM Identity Center 等でサインインするチーム向けには AWS Service Quotas コンソールから超過利用の上限を設定できるようになり、個人開発者向けには最小 5 ドルからのクレジットパックを前払いで購入できるようになりました。想定外の請求を防ぎたい方におすすめのアップデートです。 ブログ記事「Kiro で Claude Sonnet 5 が利用可能になりました」を公開 2026 年 7 月 1 日より、Claude Sonnet 5 が Kiro の IDE、CLI、Web で利用可能になりました。Sonnet 5 は推論力・ツール利用・コーディング能力が大幅に強化され、Sonnet クラスの価格のまま Opus 4.8 に近いエージェント性能を発揮します。クレジット倍率は Sonnet 4.6 と同じ 1.3 倍、100 万トークンのコンテキストウィンドウを備えており、タスクに応じて Opus 4.8 とのコスト・性能バランスを選べるようになりました。 サービスアップデート Amazon SageMaker HyperPod が Prefill と Decode の分離 (Disaggregated Prefill and Decode) をサポート Amazon SageMaker HyperPod で LLM 推論の Prefill と Decode を専用の GPU プールに分離する DPD がサポートされました。従来は両フェーズが同じ GPU を奪い合い、長いコンテキストのリクエストが他のトークン生成を停滞させていましたが、今回のアップデートで安定したレイテンシと高いスループットを実現し、両フェーズを独立してスケールできます。長いリクエストだけを自動で分離パスに振り分けるルーターも備えています。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod が継続的プロビジョニングの Slurm クラスターでディープヘルスチェックをサポート 継続的プロビジョニングで作成した Slurm クラスターでも、GPU の健全性や接続性を検証するディープヘルスチェックが実行可能になりました。非同期に追加される新しいノードを、稼働中のワークロードを中断せずにジョブ投入前に検証できます。自動ノード復旧機能と組み合わせれば、失敗したインスタンスは自動で再起動・交換されます。詳細は こちらのユーザーガイド をご参照ください。 Amazon SageMaker HyperPod が継続的プロビジョニングの Slurm クラスターで AMI ベースのノードライフサイクル設定をサポート 継続的プロビジョニングを使用する Slurm クラスターでも AMI ベースの設定が利用可能になりました。これまで必要だったライフサイクル設定スクリプトの管理が不要になり、Docker や Slurm アカウンティングなどを備えた本番対応のノードを AMI から直接構成できます。ノード追加時点で設定が完了するため、より早くジョブをスケジュールできます。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker Studio がワンクリックのモデルデプロイとカスタマイズのために Hugging Face と統合 Hugging Face のモデルページから「Deploy on SageMaker AI」などを選ぶだけで、モデルがロード済みの Studio 環境に直接アクセスできるようになりました。従来はコンソールでの環境構築や IAM 設定、GPU クォータ申請が必要でしたが、今回のアップデートで数秒で環境が作成され、ファインチューニングやデプロイに必要な権限も事前設定されます。 AWS Neuron 2.31.0 が NKI 0.5.0 と UltraServer Operator とともに利用可能に AWS Neuron 2.31.0 がリリースされました。NKI 0.5.0 では MX FP8 スケール dtype や新しいテンソルビュー API が追加され、Amazon EKS 上の Trainium UltraServer ワークロードの管理を自動化する UltraServer Operator がパブリックベータで登場しました。Trn2・Trn3 でデフォルト有効になった新コンパイラバックエンドによる性能向上や、14 の実験的カーネル追加も含まれます。 AWS MCP Server が OAuth をサポート AWS Sign-In を使って AI エージェントを AWS MCP Server に直接接続できるようになりました。業界標準の OAuth を利用するため追加の認証ソフトウェアは不要で、既存の AWS ID や IAM 権限、ガバナンス制御がそのまま適用されます。ブラウザでの対話型認可とヘッドレス認可の両方に対応し、トークン失効 API や CloudTrail 監査などの統制機能も提供されます。詳細は こちらの Blog 記事 をご参照ください。 AWS DMS Schema Conversion が AI エージェントによる自動化をサポート AWS DMS Schema Conversion が AWS MCP Server を通じた AI エージェント自動化に対応しました。Kiro、Claude Code、Cursor などを接続し、IDE から自然言語でスキーマ変換や評価レポート生成などの移行ワークフロー全体を実行できます。専用スキルが API パターンや操作手順をエージェントに提供するため、試行錯誤を削減できます。追加料金なしで利用可能です。詳細は こちらのドキュメント をご参照ください。 Kiro IDE 1.0.116 — エージェント書き込み時のフック、遅延 MCP 認証、マルチウィンドウ同期 Kiro IDE 1.0.116 がリリースされました。エージェントによるファイル変更をトリガーにフックを実行できるようになり、サインインが必要な MCP サーバーへの自動 OAuth 認証や、複数ウィンドウ間での設定同期にも対応しました。trust 機能や接続まわりの修正も含まれています。 Kiro CLI 2.12 — MCP OAuth サポートの拡張 Kiro CLI 2.12 がリリースされました。Figma のように厳格な OAuth 要件を持つ MCP サーバーに対応し、クライアントシークレットの設定、カスタムコールバックパスの指定、独自クライアント ID 使用時の動的クライアント登録のスキップが可能になりました。複合フラグを持つコマンドのより正確な承認プロンプトや、ASCII モードの完全対応も含まれています。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

2026 年 7 月 1 日より、Claude Sonnet 5 が Kiro の IDE 、 CLI 、 Web でご利用いただけるようになりました。Sonnet 5 は Anthropic がこれまでに提供した中で最もエージェント性能に優れた Sonnet モデルであり、Sonnet 4.6 から大幅にアップグレードされ、推論力・ツール利用・コーディング能力が強化されています。しかも価格は Sonnet クラスのままです。 Sonnet クラスの価格で、Opus クラスに近いエージェント性能を 多くの開発者にとって、Agentic AI の時代は Sonnet クラスのモデルから始まりました。しかし最近では、エージェント性能における最も明確な向上は Opus 系列で見られていました。Sonnet 5 はこのギャップを縮めます。推論、ツール利用、コーディング、知的作業において、その性能は Opus 4.8 に近づきつつ、コストは大幅に抑えられています。 Kiro では、これにより実質的な「コストと性能の選択肢」が手に入ります。最も難しいタスクで最大限の精度が必要なときは Opus 4.8 を、強力なエージェント性能をより多く実行できる価格帯で使いたいときは Sonnet 5 を選べます。両者の間で実行レベルを調整し、タスクごとに最適なバランスを見つけることができます。 エンドツーエンドのエージェント作業のために構築 Kiro の IDE、CLI、Web 全体において、Sonnet 5 は編集前に計画を立て、監督なしでより長く動作し続け、明示的に指示されなくても自身の出力を確認します。初期テストを行ったユーザーからは、従来の Sonnet モデルでは途中で止まってしまっていた複雑なタスクを最後までやり遂げる、という感想が一貫して寄せられています。 IDE における 仕様駆動のワークフロー では、これはより広範囲な変更において、スペックからのズレが少ない、より忠実度の高い実装につながります。CLI と Web においては、ブラウジング、ターミナル操作、複数ファイルにわたるリファクタリングといった複数ステップのエージェントタスクが、より確実に完了まで到達し、手詰まりが減り、密に監督する必要も少なくなります。 利用可能な環境 Sonnet 5 は、AWS us-east-1 (バージニア北部)リージョンおよび AWS Europe (フランクフルト) リージョンにおいて、クロスリージョン推論のサポートとともに、Kiro Pro、Pro+、Pro Max、Power のお客様に対して 実験的サポートとして 段階的に展開されます。100万トークンのコンテキストウィンドウを備え、クレジット倍率は Sonnet 4.6 と同じ 1.3 倍です。 トークナイザーの変更に関する注記 : Sonnet 5 は更新されたトークナイザーを使用しており、Sonnet 4.6 とはテキストの処理方法がわずかに異なります。同じ入力でも、コンテンツの種類によっておおよそ 1.0〜1.35 倍のトークン数になる場合があります。 Kiro をダウンロード するか、IDE や CLI を再起動して最新のモデルを確認してください。 Web をご利用の方 は、ブラウザを再読み込みするとモデルセレクターに Sonnet 5 が表示されます。 本記事は Sonnet 5 is now available in Kiro (2026年7月1日公開、著者: Vipin Mohan)の日本語翻訳版です。

G-gen の武井です。当記事では、Google SecOps で検知したアラートの是正対応を Playbooks で自動化する方法を解説します。 はじめに Google SecOps とは Playbooks（ハンドブック）とは 検証の流れ カスタムルールの設定 インテグレーションの設定 インテグレーションとは カスタムインテグレーションとは カスタムインテグレーションの作成 カスタムアクションの作成 インスタンス設定 Playbooks の設定 Playbooks の構成 トリガー コンディション アクションの設定 動作確認 はじめに Google SecOps とは Google Security Operations （以下 Google SecOps、旧称 Chronicle）は、Google Cloud が提供する 統合セキュリティ運用プラットフォーム です。 SIEM、SOAR、脅威インテリジェンス、Gemini を利用した AI による運用支援を提供します。これらにより、脅威の検知・調査・対応を一元的に行えます。結果として、セキュリティ運用の効率化と高度化を実現できます。 以下の記事も参考にしてください。 blog.g-gen.co.jp Playbooks（ハンドブック）とは Playbooks （和名表記はハンドブック）では、SIEM によって検知されたアラートに対してあらかじめ一連の対応手順を定義することで、自動または半自動でアクションを実行します。これにより、対応プロセスを標準化・迅速化できます。 Playbooks は次の要素で構成されます。 要素 概要 トリガー （Triggers） Playbooks を起動する条件。特定のアラートやイベントの発生時、またはスケジュールを契機に自動実行される アクション （Actions） 実行される処理。例えば「VirusTotal への照会」、「Jira チケット起票」、「ユーザーの無効化」など フロー （Flows） 条件分岐や承認を制御する仕組み。自動判断やアナリストの入力を挟みながら次の処理を決定する ブロック （Blocks） 再利用可能な処理単位。複数の Playbooks で共通利用できる部品化されたモジュール ループ （Loops） 配列（リスト）に対する繰り返し処理。for each として、アラート内のエンティティ群やリスト項目を1件ずつ反復し、各項目に対して同じアクションを実行する AI エージェント （AI Agents） AI エージェントを組み込み、自律的な分析・判断を行わせるステップ。 Triage and Investigation Agent （TIN）で、アラートを自律調査して True/False Positive の判定・信頼度スコアを返し、その結果を後続の分岐に利用できる 参考 : Playbook and automation overview 参考 : Embed AI agents in playbooks 検証の流れ 当記事では GitHub の Private リポジトリが意図せず Public リポジトリに変更されたというシナリオのもと、以下の段取りで検証を行います。 順序 設定項目 設定箇所 1 カスタムルールの設定 Google SecOps 2 カスタムインテグレーションの設定 Google SecOps 3 Playbooks の設定 Google SecOps 4 動作確認 Google SecOps および GitHub なお、GitHub の監査ログを Google SecOps に取り込む方法については、以下の記事で解説しています。 blog.g-gen.co.jp カスタムルールの設定 前述のシナリオに該当するログを取り込んだ際、それをアラートとして検知できるよう、検知ルールを準備します。 Google SecOps には事前定義済みの検知ルールが多数用意されていますが、今回のシナリオ向けに独自のカスタムルールを作成します。事前定義済みの検知ルールを参考にしつつ、 Gemini in Google SecOps を使用したルール作成が効果的です。 参考 : Generate rules with Gemini 作成したカスタムルール（今回の例では g_gen_github_repo_visibility_to_public ）は以下の通りです。また、作成したルールでアラート検知ができるよう、 Detecting と Alerting を有効にします。 rule g_gen_github_repo_visibility_to_public { meta: author = "G-gen" description = "Detects a GitHub repository whose visibility is changed to public" severity = "HIGH" tactic = "TA0010" technique = "T1567" events: $e.metadata.product_name = "GITHUB" $e.metadata.product_event_type = "repo.access" $e.additional.fields["visibility"] = "public" nocase outcome: $repo_name = array_distinct($e.target.resource.name) $actor_id = array_distinct($e.principal.user.userid) $new_visibility = array_distinct($e.additional.fields["visibility"]) $previous_visibility = array_distinct($e.additional.fields["previous_visibility"]) condition: $e } Detecting と Alerting を有効にしないとアラートは検知されない インテグレーションの設定 インテグレーションとは Playbooks は、それ単体で GitHub のような外部サービスを操作できません。外部サービスへの接続と操作を担うのが インテグレーション です。 Google SecOps では、VirusTotal や Slack をはじめ数多くの外部サービスに対応したインテグレーションが Content Hub（マーケットプレイスに相当）で提供されています。 参考 : Google Security Operations response integrations カスタムインテグレーションとは カスタムインテグレーション とは、Google SecOps 組み込みの IDE （統合開発環境）を使って独自に作成するインテグレーションです。 2026年7月現在、GitHub に関するインテグレーションは存在しないため、「GitHub への接続」と「リポジトリの可視性（公開範囲）変更」の2つのアクションを含むカスタムインテグレーションを作成し、これらを後段の Playbooks から呼び出します。 参考 : Use the IDE カスタムインテグレーションの作成 SecOps の管理コンソールから Response > IDE > + と遷移し、インテグレーション（今回の例では GitHubCustom ）を作成します。 次に、インテグレーションの歯車アイコンをクリックします。 画面が遷移したら、以下2つのパラメータを追加します。 API Token を必須（Mandatory）にすると既定値の入力を求められ、秘匿値が残ってしまうため、ここでは必須を Off にします。 パラメータ タイプ 既定値 必須 API Root String https://api.github.com On API Token Password （空） Off カスタムアクションの作成 インテグレーション（土台）の次に、その上で動く アクション を作成します。アクションには即座に結果が返る Sync と、長時間処理向けの Async がありますが、今回はいずれも即応答のため Sync を選択します。 先程同様、 Response > IDE > + と遷移し、以下2つのアクションを作成します。 接続確認用アクション （ Ping ）: GitHub に正しく接続できるかを確認します。Google SecOps では、すべてのインテグレーションがこの接続テスト用アクションを1つ持つ必要があります。 可視性変更用アクション （ Set Repository Visibility ）: GitHub REST API の PATCH /repos/{owner}/{repo} を呼び出し、リポジトリの可視性を変更します。 接続確認用アクション （Ping） では GitHub の GET /user を呼び出し、トークンが有効であることを確認します。 from SiemplifyAction import SiemplifyAction from SiemplifyUtils import output_handler from ScriptResult import EXECUTION_STATE_COMPLETED, EXECUTION_STATE_FAILED import requests INTEGRATION_NAME = "GitHubCustom" @ output_handler def main (): siemplify = SiemplifyAction() siemplify.script_name = "Ping" api_root = siemplify.extract_configuration_param(INTEGRATION_NAME, "API Root" , default_value= "https://api.github.com" ) token = siemplify.extract_configuration_param(INTEGRATION_NAME, "API Token" ) status = EXECUTION_STATE_COMPLETED result_value = "true" try : resp = requests.get( f "{api_root}/user" , headers={ "Authorization" : f "Bearer {token}" , "Accept" : "application/vnd.github+json" , "X-GitHub-Api-Version" : "2022-11-28" , }, timeout= 30 , ) resp.raise_for_status() output_message = f "Successfully connected to GitHub as {resp.json().get('login')}." except Exception as e: status = EXECUTION_STATE_FAILED result_value = "false" output_message = f "Failed to connect to GitHub: {e}" siemplify.end(output_message, result_value, status) if __name__ == "__main__" : main() 可視性変更用アクション（Set Repository Visibility） では実行のたびに外から渡す入力パラメータを2つ定義します。 設定パラメータがインテグレーション全体で共通の接続情報であるのに対し、入力パラメータは実行ごとに変わる値（対象リポジトリなど）を受け取ります。 パラメータ タイプ 既定値 必須 Repository Full Name String （空） Off Target Visibility String private On Repository Full Name は、後段の Playbooks でアラートから動的に渡すため、ここでの必須は Off で問題ありません。 from SiemplifyAction import SiemplifyAction from SiemplifyUtils import output_handler from ScriptResult import EXECUTION_STATE_COMPLETED, EXECUTION_STATE_FAILED import requests INTEGRATION_NAME = "GitHubCustom" @ output_handler def main (): siemplify = SiemplifyAction() siemplify.script_name = "Set Repository Visibility" api_root = siemplify.extract_configuration_param(INTEGRATION_NAME, "API Root" , default_value= "https://api.github.com" ) token = siemplify.extract_configuration_param(INTEGRATION_NAME, "API Token" ) full_name = siemplify.extract_action_param( "Repository Full Name" , print_value= True ) target = siemplify.extract_action_param( "Target Visibility" , default_value= "private" , print_value= True ) status = EXECUTION_STATE_COMPLETED result_value = "true" try : owner, repo = full_name.split( "/" , 1 ) url = f "{api_root}/repos/{owner}/{repo}" resp = requests.patch( url, headers={ "Authorization" : f "Bearer {token}" , "Accept" : "application/vnd.github+json" , "X-GitHub-Api-Version" : "2022-11-28" , }, json={ "visibility" : target}, timeout= 30 , ) if resp.status_code == 200 : siemplify.result.add_result_json(resp.json()) output_message = f "Reverted {full_name} to {target}." else : status = EXECUTION_STATE_FAILED result_value = "false" output_message = f "Failed ({resp.status_code}): {resp.text}" except Exception as e: status = EXECUTION_STATE_FAILED result_value = "false" output_message = f "Error: {e}" siemplify.end(output_message, result_value, status) if __name__ == "__main__" : main() パラメータ（オレンジ枠）の入力画面 インスタンス設定 作成したカスタムインテグレーションは、 インスタンス として有効化することで使用可能になります。 SecOps の管理コンソールから Response > Integrations Setup > 環境区分（今回は Default Environment）> + と遷移し、先程作成したカスタムインテグレーションを選択してインスタンスを作成します。 インスタンスが作成できたら、歯車アイコンからパラメーターを入力し、 Test > Save の順で保存します。 なお、今回は検証のため、個人アカウントで発行した Personal Access Token を使用していますが、本番運用では Fine-grained PAT や GitHub App による認証が望ましいです。 Test は成功して✔がつくこと Playbooks の設定 Playbooks の構成 ここまでで、アラートを検知するカスタムルールと、是正対応を実行するカスタムインテグレーションが揃いました。最後に、これらを束ねて「検知から是正までを自動化する」ワークフローを Playbooks として組み立てます。 今回作成する Playbooks は、以下の流れで構成します。SecOps の管理コンソールから Response > Playbooks > + と遷移して新規 Playbooks（今回の例では GitHub_Public_to_Private_Demo ）を作成します。 順序 要素 設定内容 1 トリガー カスタムルールでアラートを検知した場合に起動 2 コンディション 特定の GitHub Organization 配下のリポジトリかを判定 3 アクション① #2 が True の場合、カスタムインテグレーションで可視性を変更 4 アクション② ケースにコメントを記入 5 アクション③ ケースのクローズ 参考 : Create your first playbook トリガー トリガー は Playbooks の起動条件です。今回は、カスタムルールが検知したアラートにのみ反応させるため、Alert Type が g_gen_github_repo_visibility_to_public である場合に設定します。これにより、このアラート以外では Playbooks が起動しません。 コンディション コンディション は Playbooks 内の条件分岐です。ある条件を満たす場合のみ後続の処理へ進み、満たさない場合は別ルート（ ELSE ）へ分岐させられます。 コンディションを挟んだ理由は、是正の対象を特定の Organization のリポジトリに限定するためで、今回の例では g-gen-secops-test/ で始まる場合のみ、後続のアクションへ進むよう設定します。 アクションの設定 アクション は Playbooks で実行する実際の処理です。今回はコンディションの条件を満たした場合、3 つの処理を実行します。 1つ目は、Public に変更されたリポジトリの可視性を Private に戻す処理（ Set Repository Visibility ）です。カスタムインテグレーションで作成したインスタンスを選択し、入力パラメータを以下のように設定します。 対象のリポジトリはプレースホルダ（ Event.event_target_resource_name ）とすることで、発火したアラートから動的に判断します。 2つ目は、ケースにコメントを記入する Case Comment です。これは Google SecOps 標準の Siemplify インテグレーションに含まれるアクションで、ケースに任意のコメントを記入するために使用します。Comment に自動対応の記録を残します。 3つ目は、対応が完了したケースをクローズする Close Case です。先程同様 Siemplify インテグレーションに含まれるアクションで、自動対応の済んだケースを未対応のまま残さずクローズするために使用します。 動作確認 動作確認を行うため、カスタムルールの検知対象となる操作（リポジトリの可視性を Public に変更）を実行します。 しばらくすると、Google SecOps のケース画面にてアラートを検知していたことがわかりますが、その時点で既にケースがクローズされています。 Playbooks の起動条件を満たすアラートが検知されたため、可視性変更からケースのクローズまでの一連処理が自動的に実行され、かつ、正常終了していることがわかります。 ケースの詳細を確認すると、 Case Comment で定義したコメントが入力済みです。 肝心の GitHub リポジトリの可視性についても Public -> Private に変更されていることを確認できました。 武井 祐介 (記事一覧) クラウドソリューション部。 Google Cloud Partner Top Engineer 2026 選出。 Follow @ggenyutakei