## はじめに

Cloud Run でサービスを運用していると、「エラーが起きていたのに気づかなかった」という経験はないでしょうか。ログを毎日目視で確認するのは現実的ではありませんし、障害の検知が遅れればユーザーへの影響も大きくなります。

Google Cloud には Cloud Logging と連携したアラートポリシーの仕組みがあり、特定の条件に合致するログが発生した際に自動で通知を受け取ることができます。実はこのアラートポリシーには3種類の方式があり、それぞれ得意な場面が異なります。

本記事では、Cloud Run を題材に、3種類のアラートポリシーの特徴と設定方法を Google Cloud コンソール（GUI）と Terraform の両面から解説します。

---

## Cloud Logging のアラートポリシーとは

Cloud Logging では、以下の3種類のアラートポリシーを利用できます。

| 種類 | トリガー条件 | ユースケース | 特徴 |
| :----------------------- | :------------------------------- | :----------------------------------------- | :--------------------- |
| ログベースのアラート | 特定のログエントリが出現 | セキュリティイベント、重大エラーの即時検知 | シンプル、即時性が高い |
| ログベースの指標アラート | ログから作成した指標が閾値を超過 | エラー率の監視、一定期間の集計 | 統計的、柔軟な閾値設定 |
| SQL ベースのアラート | SQL クエリの結果 | 複雑なパターン分析、複数ログの結合 | 高度な分析が可能 |

簡単に言えば、「このエラーが出たらすぐ知りたい」ならログベース、「5分間にエラーが10件以上なら知りたい」なら指標ベース、「複雑な条件で集計して判定したい」なら SQL ベースが適しています。

---

## 事前準備：通知チャンネルの設定

アラートポリシーを作成する前に、通知先となるチャンネルを設定しておきましょう。ここではメール通知を設定します。

### コンソールでの設定

1. Google Cloud コンソールで Monitoring > アラート を開く
2. 上部の「通知チャンネルを編集」をクリック
3. Email の「ADD NEW」からメールアドレスと表示名を登録
4. テスト通知を送信して、正しく届くことを確認

> Tips: メール以外にも Slack、PagerDuty、Webhook など[多数の通知チャンネル](https://cloud.google.com/monitoring/support/notification-options?hl=ja)に対応しています。

### Terraform での設定

以降の Terraform コード例で共通で使用する通知チャンネルの定義です。

```hcl
resource "google_monitoring_notification_channel" "email" {
 display_name = "Email - ops-team"
 type = "email"
 labels = {
 email_address = "ops-team@example.com"
 }
}
```

---

## 1. ログベースのアラート

### 概要

最もシンプルなアラート方式です。ログエクスプローラで定義したフィルタに一致するログエントリが発生するたびに通知されます。

向いているケース:

- セキュリティ上重要なイベント（不正アクセスの試行など）
- 発生頻度が低いが見逃せない重大エラー
- 特定のメッセージやステータスコードの検知

制限事項:

- ポリシーごとに5分に1件のインシデントが上限
- ポリシーごとに1日最大20件のインシデント
- フォルダ・請求先アカウント・組織レベルのログは監視不可
- インシデントはデフォルト7日で自動クローズ

### コンソールから作成する

1. Logging > ログエクスプローラ を開く
2. クエリエディタに以下のフィルタを入力して「クエリを実行」をクリック

```
resource.type="cloud_run_revision"
resource.labels.service_name="my-service"
severity>=ERROR
```

3. 結果を確認したら、ヘッダーの「アラートを作成」>「ログエントリに基づくアラートを作成」をクリック
4. アラートの詳細を入力（アラート名: Cloud Run エラーログ検知、説明: 任意でアラートの目的を記載）
5. 通知先にメールを追加
6. 「保存」をクリック

### Terraform で作成する

```hcl
resource "google_monitoring_alert_policy" "cloud_run_log_alert" {
 display_name = "Cloud Run エラーログ検知"
 combiner = "OR"

 conditions {
 display_name = "Cloud Run ERROR ログの検出"
 condition_matched_log {
 filter = <<-EOT
 resource.type="cloud_run_revision"
 AND resource.labels.service_name="my-service"
 AND severity>=ERROR
 EOT
 }
 }

 notification_channels = [
 google_monitoring_notification_channel.email.name,
 ]

 alert_strategy {
 notification_rate_limit {
 period = "300s"
 }
 auto_close = "604800s"
 }
}
```

condition_matched_log がログベースのアラート専用のブロックです。alert_strategy の notification_rate_limit で通知間隔を制御できます（上記は5分間隔）。

---

## 2. ログベースの指標アラート

### 概要

ログからカスタム指標（メトリクス）を作成し、その指標に対して閾値ベースのアラートを設定する方式です。「5分間にエラーが10件以上」のような統計的な条件で通知したい場合に適しています。

設定は2ステップで行います：

1. ログベースの指標を作成 — ログエントリを数値データに変換
2. アラートポリシーを作成 — 指標に対して閾値を設定

### コンソールから作成する

#### ステップ1：ログベースの指標を作成

1. Logging > ログベースの指標 を開く
2. 「指標を作成」をクリック
3. 以下を設定（指標タイプ: カウンター、指標名: cloud-run-error-count）

```
resource.type="cloud_run_revision"
resource.labels.service_name="my-service"
severity>=ERROR
```

4. 「指標を作成」をクリック

#### ステップ2：アラートポリシーを作成

1. Monitoring > アラート を開き、「ポリシーを作成」をクリック
2. 「指標を選択」で logging.googleapis.com/user/cloud-run-error-count を選択
3. トリガーの条件を設定（条件タイプ: Threshold（閾値）、閾値: 10（5分間に10件以上でアラート））
4. 通知チャンネルにメールを追加して保存

### Terraform で作成する

```hcl
# ログベースの指標
resource "google_logging_metric" "cloud_run_error_count" {
 name = "cloud-run-error-count"
 filter = <<-EOT
 resource.type="cloud_run_revision"
 AND resource.labels.service_name="my-service"
 AND severity>=ERROR
 EOT
 metric_descriptor {
 metric_kind = "DELTA"
 value_type = "INT64"
 }
}

# 指標に対するアラートポリシー
resource "google_monitoring_alert_policy" "cloud_run_metric_alert" {
 display_name = "Cloud Run エラー率アラート"
 combiner = "OR"

 conditions {
 display_name = "5分間のエラー数が10件を超過"
 condition_threshold {
 filter = "metric.type=\"logging.googleapis.com/user/${google_logging_metric.cloud_run_error_count.name}\" AND resource.type=\"cloud_run_revision\""
 comparison = "COMPARISON_GT"
 threshold_value = 10
 duration = "300s"
 aggregations {
 alignment_period = "300s"
 per_series_aligner = "ALIGN_SUM"
 }
 }
 }

 notification_channels = [
 google_monitoring_notification_channel.email.name,
 ]
}
```

ログベースのアラートとの違いは、condition_threshold を使っている点です。duration と alignment_period で評価期間を指定し、threshold_value で閾値を設定します。

---

## 3. SQL ベースのアラート

### 概要

Log Analytics（ログ分析）を有効にした状態で、SQL クエリの結果に基づいてアラートを発行する最も高度な方式です。複数のログソースを結合した分析や、GROUP BY を使った集計など、柔軟な条件指定ができます。

前提条件: ログバケットで Log Analytics が有効化されている必要があります。

### コンソールから作成する

1. Logging > ログストレージ でログバケットの「Log Analytics をアップグレード」を有効化
2. Logging > ログ分析 を開く
3. SQL クエリを入力して「クエリを実行」で結果を確認

```sql
SELECT
 resource.labels.service_name AS service_name,
 COUNT(*) AS error_count
FROM
 `PROJECT_ID.global._Default._AllLogs`
WHERE
 resource.type = 'cloud_run_revision'
 AND severity >= 'ERROR'
 AND timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 10 MINUTE)
GROUP BY
 1
HAVING
 error_count > 20
```

4. クエリ結果が意図通りであれば、「アラートを作成」をクリック
5. 評価間隔や通知先を設定して保存

この例では、10分間にエラーが20件を超えた Cloud Run サービスを検出します。PROJECT_ID は実際のプロジェクト ID に置き換えてください。

### Terraform で作成する

Terraform では condition_sql ブロックを使って SQL ベースのアラートを定義できます。

```hcl
resource "google_monitoring_alert_policy" "cloud_run_sql_alert" {
 display_name = "Cloud Run SQL ベースアラート"
 combiner = "OR"

 conditions {
 display_name = "10分間のエラー数が20件を超過"
 condition_sql {
 query = <<-EOT
 SELECT
 resource.labels.service_name AS service_name,
 COUNT(*) AS error_count
 FROM
 `PROJECT_ID.global._Default._AllLogs`
 WHERE
 resource.type = 'cloud_run_revision'
 AND severity >= 'ERROR'
 AND timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 10 MINUTE)
 GROUP BY
 1
 HAVING
 error_count > 20
 EOT
 minutes {
 periodicity = 10
 }
 row_count_test {
 comparison = "COMPARISON_GT"
 threshold = "0"
 }
 }
 }

 notification_channels = [
 google_monitoring_notification_channel.email.name,
 ]
}
```

minutes.periodicity でクエリの評価間隔（分単位）を指定し、row_count_test でクエリ結果の行数に対する条件を設定します。

---

## 運用のポイント

アラートポリシーは「設定して終わり」ではなく、運用しながら調整していくものです。以下のポイントを意識すると、効果的な監視体制を構築できます。

### フィルタは具体的に

フィルタが広すぎると大量の通知が届き、重要なアラートが埋もれるアラート疲れの原因になります。service_name や severity は必ず絞り込みましょう。

### テスト通知を忘れずに

アラートポリシーを作成したら、意図的にエラーを発生させて通知が正しく届くか確認しましょう。通知チャンネルの設定ミスは意外と多いものです。

### ポリシーの一時停止を活用する

メンテナンス時は、コンソールからアラートポリシーをワンクリックで無効化できます。作業完了後に有効に戻すのを忘れないようにしましょう。

### 3種類の使い分け

| やりたいこと | おすすめの方式 |
| :------------------------------------- | :----------------------- |
| 特定のエラーが出たらすぐ知りたい | ログベースのアラート |
| 一定期間のエラー数で判断したい | ログベースの指標アラート |
| 複雑な条件や複数ログの結合で判断したい | SQL ベースのアラート |

迷ったら、まずはログベースのアラートから始めて、必要に応じて指標ベースや SQL ベースに移行するのがおすすめです。

---

## まとめ

本記事では、Cloud Logging の3種類のアラートポリシーについて、Cloud Run を題材に設定方法を解説しました。

- ログベースのアラート: 特定のログ出現を即座に検知。設定がシンプルで導入しやすい
- ログベースの指標アラート: ログをメトリクスに変換し、閾値で監視。統計的な判断が可能
- SQL ベースのアラート: SQL クエリによる高度な分析。複雑な条件も柔軟に対応

おすすめのフローは、まず GUI で試して動作を確認し、本番運用では Terraform でコード化することです。これにより設定の再現性が担保され、チームでのレビューも容易になります。

Cloud Run に限らず、GCE や Cloud SQL など他のサービスでも同様の仕組みでアラートを設定できるので、ぜひ自分のプロジェクトに合った監視設定を構築してみてください。

---

## 参考リンク

- [ログに基づくアラート ポリシーを構成する - Cloud Logging ドキュメント](https://cloud.google.com/logging/docs/alerting/log-based-alerts?hl=ja)
- [ログベースの指標の概要 - Cloud Logging ドキュメント](https://cloud.google.com/logging/docs/logs-based-metrics?hl=ja)
- [SQL クエリ結果をモニタリングする - Cloud Logging ドキュメント](https://cloud.google.com/logging/docs/analyze/sql-in-alerting?hl=ja)
- [google_monitoring_alert_policy - Terraform Registry](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/monitoring_alert_policy)
- [google_logging_metric - Terraform Registry](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/logging_metric)

large_eyecatch.jpg

medium_eyecatch.jpg

small_eyecatch.jpg

thumbnail_eyecatch.jpg

eyecatch.jpg

Cloud Logging のアラートポリシーを活用して Cloud Run を監視しよう

large_eycatch-gemini-vs-cloud.png

medium_eycatch-gemini-vs-cloud.png

small_eycatch-gemini-vs-cloud.png

thumbnail_eycatch-gemini-vs-cloud.png

eycatch-gemini-vs-cloud.png

画像処理系AIの Gemini 2.5 Flash Image と Cloud Vision API を比べてみる（Next.jsの実装例付き）

## はじめに
最近のソフトウェア開発では、AIの活用が急速に進み、すっかり当たり前のものとなりました。コードの自動補完やエラーチェックを行うAIコーディング支援ツールはすでに多くの開発者に利用されていますが、さらに一歩進んだ「AIコーディングエージェント」という概念をご存知でしょうか？ まるで開発チームの一員のように自律的にタスクをこなすAIの登場は、私たちの開発スタイルを大きく変えるでしょう。

### AIコーディング支援とAIコーディングエージェントの違い
AIコーディング支援は、開発者がコードを書く際の補助を目的としています。例えば、入力中のコードの自動補完、構文チェック、簡単なリファクタリングの提案などがこれにあたります。IDE（統合開発環境）に組み込まれているCopilotのようなツールがこれにあたります。これらは開発者の作業を「支援」するものであり、最終的な判断や実装は開発者自身が行います。

一方、AIコーディングエージェントは、より自律的に開発タスクを実行する能力を持つツールです。単にコードを提案するだけでなく、要件を理解し、開発計画を立て、実際にコードを生成・修正し、テストまで実行できます。与えられたタスクに対して一連のプロセスを自律的に進めていくのが特徴です。

### Julesの簡単な紹介と始め方

今回体験したのは、そんなAIコーディングエージェントの一つである「[Jules](https://jules.google/)」です。Julesは、開発者が自然言語で与えた指示に基づき、コードの生成、テスト、デバッグ、リファクタリングといった一連のソフトウェア開発タスクを自動化するツールです。まるで優秀なペアプログラミングパートナーがいるかのように、開発者はより本質的な問題解決に集中できるようになるでしょう。

Julesの詳しい始め方については、以下の参考リンクをご確認ください。GitHubリポジトリにJulesのGitHub Appをインストールし、Write権限を付与すれば、すぐにタスクを依頼できます。

#### 参考リンク
- https://jules.google/docs/
- [Note記事: AIコーディングエージェントの導入](https://note.com/tandago/n/n2363371f46b8)
- https://qiita.com/syukan3/items/2c8989a59d7800b1c896#4-%E5%B0%8E%E5%85%A5%E6%89%8B%E9%A0%865-%E5%88%86%E3%81%A7%E5%AE%8C%E4%BA%86

### 実際にやってみた例の紹介

今回は、「Dependabotの指摘に対応するため、Honoのバージョンアップを実施してください。」と日本語で依頼してみました。

![planning](https://cont.sterfield.co.jp/uploads/planning_03e7631bf6.jpg)

Julesはまず、与えられたタスクを詳細に分解し、実装の手順をプランニングしました。

---

![complete](https://cont.sterfield.co.jp/uploads/complete_f0fb0989f6.jpg)

プランニング結果を承認すると、Julesは実際にコードの修正を開始しました。注目すべきは、具体的な指示を与えていないにもかかわらず、Julesが自律的に動作確認の方法（npm run devによるローカル実行）を特定し、実行した点です。これは、単にコードを生成するだけでなく、開発プロセス全体を理解しているJulesの能力を強く示すものです。

上記の画像は、すべての作業が完了し、Julesが変更内容を「dependabot/npm/hono-4.7.11」というブランチにプッシュした後の状態です。

### やってみた所感

Julesを体験してみて、まず感じたのはその自律性の高さです。従来のAIコーディング支援ツールでは、開発者が積極的に指示を出し続ける必要がありましたが、Julesは一度タスクを与えれば、まるでジュニアエンジニアがタスクを進めるかのように自律的に動きます。これにより、開発者はより複雑な問題解決やアーキテクチャ設計などに集中できる時間が格段に増えると感じました。

一方で、まだ完璧ではない点もいくつかありました。例えば、レスポンスに時間がかかる場合がある点や、日本語入力時の細かなUI挙動に改善の余地がある点など、少しストレスを感じる場面もありました。しかし、これらは現在ベータ版として提供されているため、今後の改善に期待しています。

### まとめ

AIコーディングエージェント「Jules」を体験してみて、その将来性を強く感じました。まだ発展途上ではありますが、今後AIコーディングエージェントがさらに進化することで、ソフトウェア開発のあり方は大きく変わっていくでしょう。単純作業はAIに任せ、人間はより創造的で戦略的な業務に集中する、そんな未来がすぐそこまで来ているのかもしれません。

皆さんもぜひ一度、JulesのようなAIコーディングエージェントを体験してみてはいかがでしょうか。

large_Gemini_Generated_Image_tibdtetibdtetibd.jpeg

medium_Gemini_Generated_Image_tibdtetibdtetibd.jpeg

small_Gemini_Generated_Image_tibdtetibdtetibd.jpeg

thumbnail_Gemini_Generated_Image_tibdtetibdtetibd.jpeg

Gemini_Generated_Image_tibdtetibdtetibd.jpeg

Julesで体験！AIコーディングエージェントの可能性

## はじめに
サイトの監視アラート通知をメールで受け取ると埋もれがちなので、普段使っているチャットツールで受け取りたいということがあります。

今回は、[さくらクラウドのシンプル監視](https://cloud.sakura.ad.jp/products/simple-monitor/)のアラート通知をGoogle Chatで受け取る方法を紹介します。

シンプル監視はSlackのみを公式にサポートしています。弊社ではGoogle Chatをメインで利用しているため、SendGridとGoogle Apps Scriptを活用し、Google Chatにアラート通知を送信する仕組みを構築しました。この方法であれば、追加費用をかけずに、柔軟なカスタマイズが可能です。

以下、具体的な設定方法を解説します。

## 概要 
![Overview](https://cont.sterfield.co.jp/uploads/overview_f0a47bc2aa.png) 

図のとおりシンプル監視からのメール通知をSendGridで受信して、そこからGoogle App Sriptを経由してGoogle Chatに書き込む仕組みです。

### ポイント
- シンプル監視のWebhook通知は、ZapierやIFTTT経由でGoogle Chatに通知できますが、2024年12月現在は有料プランが必要なため、今回は無料のメール通知を利用します。
- SendGridのInbound Email Parse Webhook自体は無料で利用可能ですが、SendGrid自体のアカウント開設には審査が必要となっています。また、Inbound Email Parse Webhookを利用するためには、SendGrid上でドメイン認証を行ったドメインのメールアドレスのみ設定可能です。詳細は[SendGridのヘルプ](https://sendgrid.kke.co.jp/docs/User_Manual_JP/Settings/parse.html)を参照してください。
- Google Chatで外部からWebhookを受け取る機能は無料版では使えません。有料のGoogle Workspaceを契約している必要があります。

## Google ChatのWebhook設定
スペースの設定画面でアプリと統合メニューを開いた画面で下の方にあるWebhookを追加からWebhookを追加してリンクをコピーしておきます。

![Google Chat](https://cont.sterfield.co.jp/uploads/google_chat_29b557565c.png) 

## Google App Scriptの設定
コピーしたリンクを使って下記のスクリプトを作成して外部から起動できるようにデプロイしてください。シンプル監視から送られるメールのエンコードはISO-2022-JP(いわゆるJISコード)のため、文字コード変換が必要です。

```js
function doPost(e) {
  const { text } = e.parameter;

  // Google ChatのWebhook URL (事前にコピーしたURLを貼り付ける)
  const webhookurl = 'https://chat.googleapis.com/v1/spaces/**********/messages?key=**********';

  // JISコードで送信されてくるメールデータを、Google Chatで扱えるUTF-8に変換します。
  const data = {
    'text': Utilities.newBlob(text).getDataAsString("JIS")
  };

  const options = {
    'method': 'post',
    'headers': {
      'Content-Type': 'application/json; charset=UTF-8'
    },
    'payload': JSON.stringify(data)
  };
  UrlFetchApp.fetch(webhookurl, options);
}
```

デプロイが完了したらウェブアプリのURLをコピーしおきます。

![deploy](https://cont.sterfield.co.jp/uploads/deploy_d3a68796ab.png) 

## SendGridの設定
SendGridにログインして、Setting > Inbound Parseを開いてAdd & Hostボタンを押して、下記の設定値を入力してWebhook設定を追加します。

Receiving Domain:

シンプル監視からのメール通知を受け取るためのメールのドメイン

Destination URL:

前項でコピーしておいたウェブアプリのURL

![sendgrid](https://cont.sterfield.co.jp/uploads/sendgrid_1a2731c45b.png) 

## シンプル監視の設定
さくらのクラウドの設定画面でオプション > メールアドレスを開いて、前項で設定したドメインのメールアドレスでアラートの通知を受け取るように設定します。

![simple](https://cont.sterfield.co.jp/uploads/simple_b79b0c893e.png) 

アラートの通知設定はデフォルトのまま（通知方法：メール、メールタイプ：テキスト）にしておきます。

## アラート通知の例
シンプル監視でアラートが発生した際にGoogle Chatに下記の通知が表示されたら設定成功です。

![example](https://cont.sterfield.co.jp/uploads/example_fe539f6c67.png) 

## まとめ
以前はIFTTTの有料プランを利用して通知の自動化を行っていましたが、今回構築した新しい仕組みによって、運用コストの削減が実現できました。

今後は、Google App Scriptのコードをカスタマイズしてサイトごとに通知先スペースをわけて複数サイトのアラート通知をうまく受け取れる仕組みの構築を進めてもっと活用していこうと思います。皆様も是非参考にしてみてください。

## 参考リンク
- [お知らせをWebhookでGoogle Chatに通知してみよう &ndash; Shopらんサポートサイト](https://shoprun.support-dreamarts.com/hc/ja/articles/17847405156377-%E3%81%8A%E7%9F%A5%E3%82%89%E3%81%9B%E3%82%92Webhook%E3%81%A7Google-Chat%E3%81%AB%E9%80%9A%E7%9F%A5%E3%81%97%E3%81%A6%E3%81%BF%E3%82%88%E3%81%86)
- [ISO-2022-JP（7bit JIS）のeml形式データをApps Scriptで解読する #JavaScript - Qiita](https://qiita.com/takatama/items/696557f4eb51d4e50b8f)

medium_3-4-2line-rgb-blackback-solidcolor.png

small_3-4-2line-rgb-blackback-solidcolor.png

thumbnail_3-4-2line-rgb-blackback-solidcolor.png

3-4-2line-rgb-blackback-solidcolor.png

さくらのシンプル監視のアラートをGoogle Chatで受け取る方法

## はじめに

Google Cloud 上でバッチ処理を行う際に、[Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)を使用したので紹介します。
本記事では、他サービスとの比較と[Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)の使い方について説明します。

## Google Cloud でバッチ処理できるサービス

Cloud Run jobs を使用するにあたって、他のサービスについても調べたのでそれぞれの特徴をまとめました。

### [Cloud Functions](https://cloud.google.com/functions)

様々なイベントをトリガーにできるので、特定のイベントが発生したときに動かしたいバッチ処理の場合は Cloud Functions を使うと良さそうです。
例えば [Cloud Storage](https://cloud.google.com/storage) に画像がアップロードされた際に、自動的にサムネイルを作成したり、画像にフィルターをかけたりする処理が簡単に作れます。
しかし、最大実行時間に制限(60 分)があるため長時間の処理には適さない場合があります。

### [Batch](https://cloud.google.com/batch)

大規模なバッチ処理ワークロードを効率的に実行するためのフルマネージドなサービスです。
高性能コンピューティング（HPC）、機械学習、データ処理など、さまざまな種類のバッチジョブをスケーラブルかつ柔軟に実行できます。
また、最大実行時間に制限が無いので長時間の処理に適しています。
しかし、Cloud Functions や Cloud Run jobs よりも設定が複雑になってしまうので採用しませんでした。

### [Cloud Run jobs](https://cloud.google.com/run/docs/create-jobs)

Cloud Run の一機能で、バッチ処理や非同期タスクの実行に特化したサービスです。
最大実行時間に制限がありますが、24 時間実行できるのでほとんどのバッチ処理は問題ないでしょう。

## Cloud Run jobs の基本要素

### Cloud Run jobs のリソース構造

Cloud Run jobs は以下のようなリソースで構成されています。 
 ![リソース構造](https://cont.sterfield.co.jp/uploads/resource_a778e2a692.jpg) 

### ジョブ (Job)

実行したいタスクの全体像を定義するルートリソースです。

ジョブでは以下の項目を設定できます。

- コンテナイメージ
- タスク数
- 並列実行数
- リソース(各タスクに割り当てる CPU やメモリなどのリソース量)
- 環境変数
- サービスアカウント

### タスク (Task)

ジョブによって定義されたタスクのインスタンスです。
タスクはジョブに設定された数だけ実行されます。コンテナインスタンスを 1:1 で用意し、コンテナインスタンスごとの進捗を管理します。タスクがエラーで終了した場合は、タスク単位で再実行もできます。

### 実行 (Execution)

タスクの実行履歴です。
ジョブの設定に応じてタスクを実行し、全てのタスクが完了するまでの状態を管理します。1 度作成した実行は、何度でも再実行が可能です。

## Cloud Run jobs の作成・実行方法

### サンプルアプリケーションの用意

以下のコードを適当なフォルダに作成します

環境変数に`SLEEP_MS`を設定すると、設定した時間だけスリープするようになり、時間のかかる処理を再現できます。
`FAIL_RATE`を設定すると、指定した確率でジョブがエラーになり、エラー時の挙動を確認できます。

main.js

```js
// Retrieve Job-defined env vars
const { CLOUD_RUN_TASK_INDEX = 0, CLOUD_RUN_TASK_ATTEMPT = 0 } = process.env;
// Retrieve User-defined env vars
const { SLEEP_MS, FAIL_RATE } = process.env;

// Define main script
const main = async () => {
 console.log(
 `Starting Task #${CLOUD_RUN_TASK_INDEX}, Attempt #${CLOUD_RUN_TASK_ATTEMPT}...`
 );
 // Simulate work
 if (SLEEP_MS) {
 await sleep(SLEEP_MS);
 }
 // Simulate errors
 if (FAIL_RATE) {
 try {
 randomFailure(FAIL_RATE);
 } catch (err) {
 err.message = `Task #${CLOUD_RUN_TASK_INDEX}, Attempt #${CLOUD_RUN_TASK_ATTEMPT} failed.\n\n${err.message}`;
 throw err;
 }
 }
 console.log(`Completed Task #${CLOUD_RUN_TASK_INDEX}.`);
};

// Wait for a specific amount of time
const sleep = (ms) => {
 return new Promise((resolve) => setTimeout(resolve, ms));
};

// Throw an error based on fail rate
const randomFailure = (rate) => {
 rate = parseFloat(rate);
 if (!rate || rate < 0 || rate > 1) {
 console.warn(
 `Invalid FAIL_RATE env var value: ${rate}. Must be a float between 0 and 1 inclusive.`
 );
 return;
 }

 const randomFailure = Math.random();
 if (randomFailure < rate) {
 throw new Error("Task failed.");
 }
};

// Start script
main().catch((err) => {
 console.error(err);
 process.exit(1); // Retry Job Task by exiting the process
});
```

package.json

```json
{
 "main": "main.js",
 "scripts": {
 "start": "node main.js"
 },
 "engines": {
 "node": ">=20.0.0"
 }
}
```

Dockerfile

```Dockerfile
FROM node:20
WORKDIR /app
COPY . .
RUN npm install
CMD [ "npm", "start" ]
```

### コンテナをプッシュ

次のコマンドで [Artifact Registry](https://cloud.google.com/artifact-registry) にコンテナをプッシュします。`${REGION}`と`${PROJECT_ID}`は各自で置き換えてください。

```
gcloud builds submit --tag ${REGION}-docker.pkg.dev/${PROJECT_ID}/gcr.io/job-sample
```

### ジョブを作成

今回は、以下の Cloud Run のコンソールから作成します。 
https://console.cloud.google.com/run/jobs

「ジョブの作成」をクリックします。 
 ![ジョブの作成ボタン](https://cont.sterfield.co.jp/uploads/job_create_1_691d934c36.png) 

「コンテナ イメージの URL」に先ほど作成したコンテナを選択します。
イメージ名が自動的に設定されます。
リージョンやタスク数はお好みで設定して下さい。 
 ![ジョブの詳細](https://cont.sterfield.co.jp/uploads/job_create_2_c2c65e6a14.png) 

### ジョブの実行

「実行」をクリックし、ジョブを開始します。 
 ![実行ボタン](https://cont.sterfield.co.jp/uploads/job_create_3_3049895faf.png)

しばらく経つと、全てのタスクが完了し、実行が完了します。実行の詳細を開くとタスクが完了していることが確認でき、各タスクのログ等が確認できます。 
 ![タスク](https://cont.sterfield.co.jp/uploads/job_create_4_6281075873.png) 

### 作成した Job を定期実行する方法

「トリガー」タブを選択し、「スケジューラ トリガーを追加」をクリックします。 
 ![トリガー追加ボタン](https://cont.sterfield.co.jp/uploads/scheduler_1_1e1f8511c4.png) 

頻度を unix-cron 形式で選択します。
今回は 5 分ごと(`*/5****`)に実行してみます。 
 ![トリガー詳細](https://cont.sterfield.co.jp/uploads/scheduler_2_f70181ea5b.png) 

指定した通り、5 分ごとにジョブが実行されました。 
 ![ジョブ一覧](https://cont.sterfield.co.jp/uploads/scheduler_3_69acf4aa19.png) 

## まとめ

今回は Cloud Run jobs について説明しましたが、各サービスのメリット・デメリットを比較し、要件に合った最適なサービスを選択することが重要です。
今後、他サービスにも触れる機会がありましたら紹介したいです。

## 参考

- https://speakerdeck.com/satohjohn/gcptenohatutichu-li-hatanwokao-etemiru
- https://zenn.dev/google_cloud_jp/articles/cloudrun-jobs-basic
- https://cloud.google.com/run/docs/quickstarts/jobs/build-create-nodejs

small_cloud-run.png

thumbnail_cloud-run.png

cloud-run.png

Cloud Run jobs を利用したバッチ処理

# はじめに
近年、チームワークや情報共有の重要性が高まる中で、さまざまなツールやサービスが活用されています。その中でも、GoogleスプレッドシートとGoogle Chatは、多くの企業や組織で利用されている定番ツールです。
この記事では、Google Apps Scriptを使用して、Google スプレッドシートで特定の操作が行われた際にGoogle Chatへ自動で通知を送る方法について、その**手順**と**応用例**を紹介します。

### 手順概要
1. Google Chat Webhook URLの取得
2. Google Apps Scriptの作成
3. Google Apps Scriptのトリガー設定
4. Google Chatへの通知送信の確認

#### 1. Google Chat Webhook URLの取得
最初に、Google Chatに通知を送信するためのWebhook URLを取得します。

1. Google Chatを開き、通知を送りたいチャットルームを選択します。
2. チャットルーム名をクリックし、「アプリと統合」を選択します。
3. 「+Webhookを追加」をクリックし、名前を入力して「保存」をクリックします。
4. 表示されたWebhook URLをコピーします。このURLは後でスクリプト(手順2)に使用します。

 ![](https://cont.sterfield.co.jp/uploads/webhook_f7e4ed54ef.png) 

**補足**

・Webhook URLは、Chatルームごとに個別に発行されます。

・複数のWebhook URLを作成し、異なるChatルームへ通知することも可能です。


#### 2. Google Apps Scriptの作成
次に、Google スプレッドシートに関連付けるGoogle Apps Scriptを作成します。

1. 対象のGoogle スプレッドシートを用意して開きます。
2. メニューバーから「拡張機能」をクリックし、「Apps Script」を選択します。
3. スクリプトエディタが開きます。新しいプロジェクトが作成され、デフォルトのコードエディタが表示されます。
4. 以下のコードをエディタに貼り付け、Webhook URLを先ほどコピーしたURLに置き換えます。

 ![](https://cont.sterfield.co.jp/uploads/script_4be5865e34.png) 

```
function sendToGoogleChat(message) {
  var url = "YOUR_WEBHOOK_URL";  // ここをWebhook URLに置き換えます

  var payload = JSON.stringify({ "text": message });
  
  var options = {
    "method": "POST",
    "contentType": "application/json",
    "payload": payload
  };

  UrlFetchApp.fetch(url, options);
}

function notifyOnEdit(e) {
  var sheet = e.source.getActiveSheet();
  var range = e.range;
  var editedValue = range.getValue();
  var message = "Cell " + range.getA1Notation() + " was edited. New value: " + editedValue;
  
  sendToGoogleChat(message);
}
```
このスクリプトは、スプレッドシートのセルが編集された際に、その情報をGoogle Chatに送信します。

**ポイント**

・YOUR_WEBHOOK_URL を、1で取得したWebhook URLに置き換えてください。

・必要に応じて、messageの内容を編集してください。


#### 3. Google Apps Scriptのトリガー設定
1. スクリプトを保存し、トリガーを設定してスクリプトが自動的に実行されるようにします。
2. スクリプトエディタの時計アイコン（「トリガー」）をクリックします。
3. 「トリガーを追加」をクリックし、「notifyOnEdit」を選択します。
4. イベントの種類を「スプレッドシートから」に設定し、「編集時」を選択します。
5. 保存してトリガーを有効にします。(認証ダイアログが出てくる場合は、認証を行います。)

 ![](https://cont.sterfield.co.jp/uploads/trigger_7bf337dbff.png) 

#### 4. Google Chatへの通知送信の確認
設定が完了したら、実際にGoogle スプレッドシートでセルを編集してみてください。編集が行われると、指定したチャットルームに通知が送信されるはずです。

 ![](https://cont.sterfield.co.jp/uploads/spreadsheet_ba705a00a8.png) 

 ![](https://cont.sterfield.co.jp/uploads/chat_05129bfbf6.png) 


### 応用例
#### 応用例1: 特定のシートやセル範囲でのみ通知を送る
特定のシートやセル範囲に変更があった場合のみ通知を送るようにスクリプトをカスタマイズできます。

```
function notifyOnEdit(e) {
  var sheet = e.source.getActiveSheet();
  
  // シート名が「Sheet1」でない場合は通知を送らない
  if (sheet.getName() != "Sheet1") {
    return;
  }

  var range = e.range;
  var editedValue = range.getValue();
  var message = "Cell " + range.getA1Notation() + " was edited. New value: " + editedValue;
  
  sendToGoogleChat(message);
}
```
これにより、「Sheet1」でのみ変更があった場合に通知が送られます。


#### 応用例2: 通知内容の詳細化
通知内容を詳細にカスタマイズすることも可能です。例えば、変更があったセルの前の値と新しい値の両方を通知に含めることができます。

```
function notifyOnEdit(e) {
  var sheet = e.source.getActiveSheet();
  var range = e.range;
  var oldValue = e.oldValue;  // 前の値
  var editedValue = range.getValue();  // 新しい値
  var message = "Cell " + range.getA1Notation() + " was edited. Old value: " + oldValue + ", New value: " + editedValue;
  
  sendToGoogleChat(message);
}
```
これにより、編集前と編集後の値を通知に含めることができます。


# まとめ
Google Apps ScriptとWebhookを使って、スプレッドシートの操作をGoogle Chatへ自動通知する方法をご紹介しました。これにより、チームメンバーは**リアルタイムで情報共有**でき、**タスク管理**や作業のトラッキングが**効率化**されます。ぜひ、活用してチームワークを強化してください。

large_eyecatch.png

medium_eyecatch.png

small_eyecatch.png

thumbnail_eyecatch.png

eyecatch.png

Googleスプレッドシートでの操作をGoogleChatに通知する方法

## はじめに

Google Cloud の [Cloud Run](https://cloud.google.com/run?hl=ja) を使ってインターネット上に公開せず内部からのアクセスのみを受け付けるサービスを構築する場合、いくつかの方法がありますが認証オプションを「認証が必要」にしてデプロイする方法がもっとも簡単です。

 ![cloud-run-deploy](https://cont.sterfield.co.jp/uploads/cloud_run_deploy_0b4c2235ac.png) 


この方法でデプロイした Cloud Run サービスの URL にブラウザでアクセスするとリクエストに認証情報が含まれてないため

```
Error: Forbidden
Your client does not have permission to get URL / from this server.
```

というエラーが表示されます。このエラーを回避して、アクセスする方法のうち代表的な3パターンを紹介します。

## 前提

Node.js で書かれたアプリケーションがデプロイされた次の 2 つの Cloud Run サービスがデプロイされている環境があるとします。

- 「Front」はインターネット上から直接アクセスされることを想定しているため、認証オプション「未認証のアクセスを許可」を設定してデプロイされている
- 「Internal」は「Front」から内部でアクセスされるもので外部からのアクセスを拒否したいため、認証オプション「認証が必要」を設定してデプロイされている

![cloud-run-diagram](https://cont.sterfield.co.jp/uploads/cloud_run_diagram_a0a3472409.png) 

## ① 他の Cloud Run サービスからアクセスする方法

「Front」 → 「Internal」

同じプロジェクトでデプロイされた Cloud Run 同士でアクセスする場合、[Google Auth Library](https://github.com/googleapis/google-auth-library-nodejs)を使うことで認証に必要なトークンを含んだ HTTP ヘッダーが取得できます。

「Front」の Cloud Run サービスをデプロイしたサービスアカウントに`Cloud Run 起動元` (`roles/run.invoker`) ロールが付与されている場合、下記のようなコードでアクセスが可能になります。

```
import { GoogleAuth } from "google-auth-library";

・・・

const auth = new GoogleAuth();
const client = await auth.getIdTokenClient(`${「Internal」のURL}`);
const headers = await client.getRequestHeaders();

// headersの中に Authorization: Bearer ${トークン} が設定されている
await fetch(`${「Internal」のURL}`, { headers });
```

## ②Cloud Run 以外のサービスからアクセスする方法

Cloud Scheduler → 「Internal」

[Cloud Scheduler](https://cloud.google.com/scheduler?hl=ja)から「Internal」にアクセスする場合は、HTTP ターゲットを作成する際、Auth ヘッダーを「OIDC トークンを追加」に設定してサービスアカウントに`Cloud Run 起動元` (`roles/run.invoker`) ロールが付与されているものを設定すると、自動でトークンを付与した HTTP アクセスを行ってくれます。

 ![cloud-scheduler](https://cont.sterfield.co.jp/uploads/cloud_scheduler_74457eda15.png) 

[Cloud Pub/Sub](https://cloud.google.com/pubsub?hl=ja)などでも同じように OIDC 認証を設定することでアクセス可能になります。

## ③ ローカルからアクセスする方法

開発者のローカル PC のコンソール → 「Internal」

gcloud CLI を使うことで開発用の汎用 ID トークンを生成することができます。`Cloud Run 起動元` (`roles/run.invoker`) ロールが付与されているユーザーでログインして、[`gcloud auth print-identity-token`](https://cloud.google.com/sdk/gcloud/reference/auth/print-identity-token)を実行するとログインユーザーのトークンが取得できます。

curl コマンドと組み合わせて下記の様に実行することでアクセスが成功します。

```
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" ${「Internal」のURL}
```

## まとめ

今回紹介した内容はすべて Google Cloud の公式ドキュメントに記載されているものですが、複数のページにまたがって解説されており、個人的に探すのが大変だったのでブログにまとめました。同じような苦労をされている方のお役に立てれば幸いです。

## 参考リンク

- https://cloud.google.com/run/docs/tutorials/secure-services?hl=ja
- https://zenn.dev/steelydylan/scraps/60f3536dd0c9b4
- https://cloud.google.com/scheduler/docs/http-target-auth?hl=ja
- https://cloud.google.com/run/docs/authenticating/developers?hl=ja#curl

small_cloud_run.png

thumbnail_cloud_run.png

cloud_run.png

認証が必要な Cloud Run サービスにアクセスする方法まとめ

## はじめに
先日、東京ビッグサイトで開催されたGoogle Cloud Next Tokyo '23のDay2に参加してきました。

 ![](/uploads/PXL_20231116_001744341_2_90d59a9df4.jpg) 

全体としては生成AIに関するトピックが盛り上がってましたが、セキュリティに関するセッションもいくつかあり、その中で私は下記のセッションに参加して話を聞いてきました。

- [セルフで行う Google Cloud 環境のセキュリティ チェックの方法](https://cloudonair.withgoogle.com/events/next-tokyo?talk=d2-di-04)
- [Google Cloud のセキュリティ機能、基本のキ｜Security Command Center で実現するリスク管理](https://cloudonair.withgoogle.com/events/next-tokyo?talk=d2-sec-02)

どちらのセッションでもSecurity Command Centerを使うことでGoogle Cloudを安全に運用できるという内容でした。
こちらをもとに本記事では、Google Cloudを利用しているがSecurity Command Centerは使ったことがない人向けに、Security Command Centerを使い始めるための設定方法と簡単な使い方の解説します。

## Security Command Centerとは
Security Command CenterはGoogle Cloud上の脆弱性や脅威となりうる設定を検知してくれるサービスです。

有効化しておくと自動で利用しているサービス、リソースを認識して、それらを対象に設定内容をスキャンしてくれるため運用に負荷がかからないのが特長です。また有償版のプレミアムティアーのみの機能となりますが、ISO 27001やPCI DSSのような業界標準への遵守状況も確認できるなどスキャン以外にも様々な機能があります。

今回は無償版のスタンダードティアーでも利用可能なSecurity Health Analytics機能を使って、Google Cloudの設定ミスの診断を試してみました。

## 実際に適用してみた結果
ありがちなユースケースとして、組織の管理権限はもってないが開発環境のプロジェクトだけ変更権限だけを持つユーザーが、Security Command Centerを使ってプロジェクトの脆弱性を診断してみるというシナリオでやってみました。

1. Security Command Centerの有効化
  - まず最初にコンソールでプロジェクトを選択した状態でSecurity Command Centerを開いて有効化を行います。スタンダードとプレミアムの2つのティアーを選択する画面になるので、無償版であるスタンダードを選んで次へを押します。すると、どの機能を有効化するか設定するダイアログが表示されます。すべてデフォルト値のままで進めます。

     ![](/uploads/249ce2bfaa98636550da620a_d3f7f1273a.png) 
      (引用：https://zenn.dev/cloud_ace/articles/scc_standard#security-command-center(%E3%82%B9%E3%82%BF%E3%83%B3%E3%83%80%E3%83%BC%E3%83%89)%E3%82%92%E6%9C%89%E5%8A%B9%E3%81%AB%E3%81%97%E3%81%A6%E3%81%BF%E3%82%8B)

  - 詳細な手順は公式ドキュメントで解説されているのでそちらを参照してください。
  https://cloud.google.com/security-command-center/docs/activate-scc-for-a-project?hl=ja#project-activation-scc-inactive-in-org

2. 診断結果の確認
  - 設定が完了すると自動で脆弱性のスキャンが行われますが、初回のスキャンは少し時間がかかります。今回の例だと24時間ほど待つ必要がありました。
  - 完了するとダッシュボードにスキャン結果が表示されます。脆弱性ページで脆弱性の種類、件数などが確認できます。

     ![](/uploads/scc_1_762224c8e4.png) 
    

3. 脆弱性の対応
  - ここではデフォルトのまま使っていると必ず検出されるOpen RDP portを対象として、実際に対応する場合の流れを解説します。

  - 詳細を開くと脆弱性の詳細や、対象のリソースの情報が確認できます。更に次のステップのところに対応方法が示されます。
    ![](/uploads/scc_2_0a09b3e035.png) 

  - それに従って、ファイアウォール ルールのdefault-allow-rdpの設定を変更します。IPの範囲が0.0.0.0/0がまずいとのことなので削除して35.235.240.0/20を設定します。
     ![](/uploads/scc_3_4f9c670868.png) 

  - なお、ルール自体を無効にしてしまえばIP範囲は変更しなくてよさそうに思えますが、この対応ではだめでした。脆弱性の判断基準としてルールが無効かどうかは関係ないようです。現時点で実害があるかどうかではなく、潜在的な脆弱性として指摘しておくポリシーなのかもしれません。

4. 対応結果の確認
  - 初回スキャンと同様に対応後の確認も特に操作は不要で、自動で再チェックが行われて脆弱性ページの件数が1=>0になります。初回スキャン時と異なり、設定変更後の再スキャンはほぼ即時反映のようで数分後には対応済みになりました。
  - 対応済みの脆弱性を確認したい場合、脆弱性ページ上からは見られなくなってしまいますが、検出結果ページのクエリ編集画面で下記のとおりクエリを変更すると確認可能になります。
    ```
    変更前）
    state="ACTIVE" AND NOT mute="MUTED"

    変更後）
    state="INACTIVE" AND NOT mute="MUTED"
    ```
     ![](/uploads/scc_4_19e81badad.png) 

## まとめ
- Security Command Centerは有効化するだけで特に設定も不要かつ無料で始められるので、使ってみることをおすすめします。
- 検出された脆弱性ごとの対応方法まで案内されるので非常に親切だが、今すぐ対応すべき問題かどうかは利用者自身が判断する必要があります。そのため、まったく知識がない状態で運用することは難しそうです。これについてはGoogle側でも課題と考えているようで、Duet AIによる支援機能が現在開発中とのことです。
- 組織単位でSecurity Command Centerの有効化を行うことで、アカウントの設定不備のようなプロジェクトをまたがった設定内容もスキャン対象となるため、より効果的な運用ができそうです。今回の検証結果をもとに、全社的にSecurity Command Centerを利用する方針を検討していきます。

## 参考リンク
- [Security Command Center](https://cloud.google.com/security-command-center?hl=ja)
- [Security Command Center でお手軽セキュリティ診断](https://zenn.dev/cloud_ace/articles/scc_standard)
- [[Google Cloud] SCC -Security Health Analytics-を試す](https://qiita.com/khoshina/items/f6ccea548e9ed39cdea8)


small_security-command-center.440x512.png

thumbnail_security-command-center.440x512.png

security-command-center.440x512.png

Security Command Centerを使ってGoogle Cloudの設定内容を診断してみよう

Blogブログ

Articles

Contact Us