こんにちは！AIエージェント開発課です。 近年、生成AIの進化スピードは凄まじく、単なるテキストの要約やドラフト生成の枠を超え、自律的に判断してタスクを実行する「AIエージェント」が大きなトレンドとなっています。 このような技術的な潮流の中、私たちのチームは2025年5月に「AIエージェント開発課」として産声を上げました。累計導入社数 約20,000社以上の顧客基盤と、16年以上にわたって蓄積された膨大な業務データ（ドメイン知識）というラクスの強みを活かし、バックオフィス業務の「完全自動化」という未来へ向けて、日々泥臭く開発を続けています。 私たちがメインで取り組んでいるのは、主力プロダクトである「楽楽精算」へのAIエージェント機能の実装です。 この記事では、私たちが直面した「3つの壁」とそれを突破した設計原則、そしてそこで得られた知見を社内の他プロダクトへ共通LLM基盤として還元していくファーストペンギンならではの面白さについて、生々しい試行錯誤のプロセスを交えてお届けします。 「プロダクトへAI機能を実装してみたいけれど、何から手をつければいいかわからない」「大規模言語モデル（LLM）の不確実性を前にアーキテクチャ設計で立ち止まっている」というエンジニアの皆さんに、明日から試せるヒントとして届くことを願っています。 ラクス最先端の挑戦を担う「AIエージェント開発課」とは 主力プロダクト「楽楽精算」をAIネイティブへ進化させるミッション 理想と現実。リリースへ向けて立ちはだかった「3つの壁」 【コストの壁】大規模クラウドサービスならではの推論量とLLM費用の問題 【精度の壁】個社ごとに異なる複雑な社内ルールにどう寄り添うか 【応答速度の壁】完了までの待ち時間、ユーザー体験を損なわないための葛藤 技術的工夫で壁を突破した「設計原則」 「ルールを考えさせる」から「お手本を真似させる」への転換 AIの不確実性を受け入れ、既存のルールベース機能と組み合わせるハイブリッド構成 「定期起動」から「イベント駆動」へ。非同期アーキテクチャ進化の裏側 ファーストペンギンとして「共通LLM基盤」を検証・構築する面白さ ビジネスロジックと責務を分離する「LLMゲートウェイ」の構築 他チームのコンパスとなる「オブザーバビリティ（監視基盤）」の検証・構築 楽楽精算での検証が、他プロダクトの道標になるダイナミズム 技術を「机の上から社会の中へ」実装したいエンジニアへ ラクス最先端の挑戦を担う「AIエージェント開発課」とは AIエージェント開発課は、エンジニアだけでなくUXデザイナーやビジネスサイドのメンバーも内包する、9名のクロスファンクショナルな少数精鋭チームとして立ち上がりました。 従来のラクスの開発スタイルは、「熟考を重ねた綿密な設計と、確実な法要件対応」を最大の強みとしていました。しかし、数日単位で前提が変わる現在のAI領域においては、既存のやり方に縛られない高速な試行錯誤（仮説検証ループ）が求められます。 そこで私たちは、顧客の「一次情報」に最も早くアクセスできるよう、開発本部の枠からあえて飛び出し、ビジネスサイド直結の組織という特異な構造を選択しました。職能の垣根を完全に取り払い、顧客ヒアリングの結果を受けて全員でUI/UXの改善案を出し合うような「オールラウンド型チーム」を醸成するのが狙いでした。 ※現在はファーストリリースを終えたため、開発本部へ戻っています。 主力プロダクト「楽楽精算」をAIネイティブへ進化させるミッション 私たちが最初に課されたミッションは、「楽楽精算」における経費申請ワークフローの自動化、すなわち「伝票作成AIエージェント」の開発です。 従来の経費精算では、申請者がスマートフォンなどで領収書をアップロードした後、自ら手作業で関連する事前申請やクレジットカードの利用明細をデータの山から探し出し、それらを一つひとつ目視で確認しながら紐付ける必要がありました。この「めんどくさい」「煩わしい」という体験を、AIエージェントの力で根本から変えることが私たちの目的です。 利用イメージとしては、ユーザーが領収書を選択するだけで、AIエージェントがその内容を意味的に推論し、関連するデータを裏側で自動的に探し出して申請用の伝票の下書きを作成します。申請者は、最後に「内容を確認するだけ」という、入力作業ゼロの世界を目指す挑戦が始まりました。 理想と現実。リリースへ向けて立ちはだかった「3つの壁」 「領収書を投げれば、AIが考えていい感じに伝票をつくってくれる」と言葉にするのは簡単ですが、いざ本番運用を前提とした開発に着手すると、AIならではの不確実性と、大規模なプロダクトゆえの制約が、重い壁となって私たちの前に立ちはだかりました。 【コストの壁】大規模クラウドサービスならではの推論量とLLM費用の問題 最初の壁は「コスト」でした。 LLMに対して、領収書データ、事前申請の候補リスト、個社ごとの勘定科目マスタ、さらには過去の申請履歴といった大量のコンテキストを愚直に流し込んで推論させると、1リクエストあたりのトークン消費量が爆発的に跳ね上がります。 検証段階でLLM費用の試算を行った際、このまま数万社という規模のお客様に機能を提供すれば、莫大な運用コストが発生し、事業継続性（Viability）が破綻しかねないという現実に直面しました。 【精度の壁】個社ごとに異なる複雑な社内ルールにどう寄り添うか 2つ目の壁は「精度」です。 経費精算というドメインは、法規制だけでなく、「この部署のこの用途なら勘定科目は交際費にする」「交際費の備考欄には必ず同席者の氏名と人数を記載する」といった、企業ごとに異なる明文化しづらい独自のルールが無数に存在します。この独自ルールが汎用的なLLMモデルでの推論精度に大きく影響しました。 【応答速度の壁】完了までの待ち時間、ユーザー体験を損なわないための葛藤 3つ目の壁は、ユーザーが体感する「応答速度（パフォーマンス）」でした。 伝票作成のワークフローの中で、データの検索、仕訳の推論、構造化出力の生成など、複数回のLLM呼び出しを同期的に（順番に待ちながら）実行する設計にしていたため、画面のローディングが完了するまでに最低でも5～15分という、とてつもない時間がかかってしまうことが判明しました。 その結果、画面遷移を同期的にすると「自分で入力した方が早い」という感想を持たれてしまったのです。この応答速度の遅さは、リリースを阻む最大のボトルネックとして私たちの前に横たわっていました。 技術的工夫で壁を突破した「設計原則」 これらの課題に対して、私たちは「最新のモデルをただ叩く」というアプローチを捨て、ラクスが大切にしてきた「顧客志向（誰のどんな課題を解決するか）」の原点に立ち返り、泥臭いアーキテクチャの変更と設計原則の再定義を行いました。 「ルールを考えさせる」から「お手本を真似させる」への転換 開発が大きく前進したブレイクスルーは、β版公開後のタイミングで導入した「ベクトルDBを用いた過去伝票のコンテキスト注入」でした。 それまでは、LLM自身に「複雑な社内規定や多様な仕訳ルール」を解釈させてゼロから深く推論させようとしていましたが、これでは推論の難易度が上がり、精度が出ないばかりか処理コストも膨らむ一方でした。 そこで私たちは、アプローチを転換しました。過去に確定した膨大な伝票データから、ベクトルDBを用いて「申請者本人が過去に作成した、今回と最も類似している確定伝票（真に正しいお手本）」を高速に検索。そのお手本データをプロンプトの「コンテキストとして補強する」RAGアーキテクチャを採用しました。 LLMに高度なルール解釈を強いるのをやめ、目の前に提示した正しいお手本を「そのまま真似しなさい（Few-Shot）」と指示する。この設計により、LLMが迷うことなく一瞬で正確な伝票を作成できるようになり、精度が劇的に向上しました。さらに、深く考えさせるプロセス（推論の難易度やループ回数）を大幅に下げられたことで、高額な推論コストをカットし、LLM費用を当初の数十分の一にまで抑え込むことに成功したのです。 AIの不確実性を受け入れ、既存のルールベース機能と組み合わせるハイブリッド構成 精度の壁を乗り越えるための私たちの結論は、「AIに完璧を求めない」ということでした。ハルシネーションをプロンプトだけで完全に防ぐのは不可能です。 そこで、AIの責務を「高速にドラフト（下書き）を作成すること」に特化させ、出力されたデータの正当性の担保は、「楽楽精算」が元々持っている強力なルールベースの「規定違反チェック機能」に委ねるというハイブリッドな構成を採用しました。 AIが推論した結果に矛盾や規定違反があれば、既存の強固なシステムが検知して申請前に画面上でユーザーに「確認」を促します。人間が最終的な「確認・承認」の責任を持つ「Human-in-the-Loop」の思想を取り入れたことで、AIの利便性を活かしつつ、業務システムとしての絶対的な安心感と確実性を担保することができました。 「定期起動」から「イベント駆動」へ。非同期アーキテクチャ進化の裏側 応答速度の課題は設計段階からある程度想定していました。伝票作成のような重い処理をユーザーを待たせながら同期的に実行するのは現実的ではないと早い段階で判断し、当初からAWSの「Amazon SQS」を用いた非同期処理をアーキテクチャの前提としていたのです。 とはいえ、ファーストリリース時点では、キューに溜まったリクエストを一定間隔で確認しに行く「定期起動」方式で処理を捌いていました。ところがベータ版として実際にユーザーに使っていただくと、この定期起動の間隔そのものが待ち時間のボトルネックとなり、「思ったより遅い」という声が集まってきたのです。 そこで私たちは、Kubernetesのイベント駆動型オートスケーラーである「KEDA」を導入。キューに溜まった未処理の伝票作成リクエスト数に応じて、K8s jobをスケーリングする仕組みへと進化させました。 この改善を反映したベータ版をリリースした結果、ユーザーは領収書を「まとめて一括で投げる」だけで、ローディングを待つことなく次の画面へ進めるようになり、AIの処理が裏で完了したものから順次、確認・申請ができるという圧倒的にスムーズな体験（従来比約40%の工数削減）へと昇華させることができました。 ファーストペンギンとして「共通LLM基盤」を検証・構築する面白さ 私たちAIエージェント開発課のミッションは、単に「楽楽精算」の機能を良くすることだけではありません。ラクス開発本部のビジョンである「AIネイティブな開発組織への変革」を牽引するファーストペンギンとして、自ら検証したアーキテクチャを全社の「共通LLM基盤」として型化し、波及させていくことに大きなやりがいがあります。 ビジネスロジックと責務を分離する「LLMゲートウェイ」の構築 開発を進める中で、各プロダクトのアカウントから外部のLLMプロバイダーへ直接APIを叩きに行くと、リトライ制御やモデルのバージョン管理、レートリミット対策がアプリケーションコード内に散らばり、保守性が著しく低下するという課題が見えてきました。 そこで私たちは、独立した抽象化レイヤーとして、プロキシ層となる「LLMゲートウェイ」をAmazon EKS上に構築しました。 ここでは、プロバイダーのAPI障害が発生した際に、自動で別リージョンや別モデルへリクエストを切り替える「フォールバック制御」や、一時的なネットワークエラーに対するリトライ処理を一元管理しています。アプリケーション側のビジネスロジックから外部AIへの依存性を完全に分離したことで、外部APIとの接続に関わる改修コストを最小限に抑える足回りを構築しました。もちろん、モデルを差し替えたからといって、そのまま期待通りに動作するとは限りません。モデル固有の出力特性やハルシネーションの傾向変化に伴い、アプリケーション側でのプロンプトの微調整や追加のバリデーション改修は必要になりますが、そうした検証と変更のサイクルを素早く回すための強固な土台となっています。 他チームのコンパスとなる「オブザーバビリティ（監視基盤）」の検証・構築 AIエージェントが本番環境で「今、どんな推論をして、なぜそのエラーを起こしたのか」を追跡する仕組み（トレース収集）は、プロダクト運用において死活問題となります。 私たちは、OpenTelemetry（OTel）Collectorを活用したログ・メトリクス・トレースの収集基盤を他プロダクトに先んじてEKS上に検証・構築しました。 当初、AWS Distro for OpenTelemetry（ADOT) Collectorと呼ばれる配布ディストリビューションを利用していましたが、必要なプラグインが不足していたため、自分たちでカスタムビルドを行うなど、かなり泥臭い対応も経験しています。 この基盤により、Amazon CloudWatchのダッシュボード上に、リアルタイムでのトークン消費量やエラーレート、エージェントの推論プロセス（トレース）が綺麗に可視化できるようになりました。 楽楽精算での検証が、他プロダクトの道標になるダイナミズム 私たちが「楽楽精算」の伝票作成AIエージェントを通じて血を流しながら検証したこれら「LLMゲートウェイ」や「オブザーバビリティ基盤」のアーキテクチャマニフェストは、開発本部全体へ展開され大きな反響を呼びました。 個別最適のサイロ化に陥りがちな複数プロダクトの開発組織において、自分たちの小さな試行錯誤が、数百名の開発体験（DevEx）を一気にAIネイティブへと変革していく「全体最適」のダイナミズムを肌で感じられることこそが、この課で働く最大の面白さだと断言できます。 技術を「机の上から社会の中へ」実装したいエンジニアへ ラクスのAI開発の根底にあるのは、論文の精度を競う研究ではなく、日々の業務の中で実際に動くシステムをつくり、数万社のお客様の働き方を変えていくという「実装主義」の思想です。 AIエージェントという不確実で正解のない未知の領域だからこそ、私たちは完璧を待つよりも、仮説を立てて小さく試すスピードを何よりも大切にしています。 私たちが構築した足回りはまだ完成形ではありません。2030年の「完全自動化」という高いゴールに向けて、これからさらに「個社別のルール最適化」や、「領収書収集から伝票作成までの自動化」、「共通LLM基盤」の整備など、エキサイティングな課題への挑戦が続いていきます。 「AIの力で、働く人の日常を本質的に『楽！』にしたい」 「最先端の技術を自らの手で社会のインフラへと落とし込んでみたい」 そんな熱い顧客志向とAIネイティブな視点を持ったエンジニアのあなたと、これからのクラウドサービスの新しい常識を一緒に創り上げていける日を、AIエージェント開発課一同、心から楽しみに待っています！

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

! この記事は、Tableauで会員登録者数を可視化する際に発生した「総数」と「内訳の合計」が一致しない問題について、原因と対応方針を整理したものです。 公式仕様を網羅するものではなく、実務で起きた数値差異の調査・解消観点をまとめています。 はじめに Tableauで会員登録者数の推移を可視化していた際、ツールヒントに表示される「登録者数の総数」と「登録チャネル別内訳の合計」が一致しない事象が発生しました。 やりたかったことは、以下のようなダッシュボード作成です。 登録者数を日別に表示する 登録チャネルA、登録チャネルBを色分けする ツールヒントに総数とチャネル別内訳を表示する