本記事は 2026 年 6 月 3 日 に公開された「 Migrating data from Oracle to Amazon Aurora DSQL 」を翻訳したものです。 Amazon Aurora DSQL は、サーバーレスで柔軟にスケールする分散 SQL データベースサービスです。複数の AWS リージョンにまたがって、強力な ACID 準拠を実現します。データベースのモダナイゼーションに向けて Amazon Aurora DSQL を検討している場合、サービスの現在の機能と制約の範囲内で既存のエンタープライズデータベースを移行するという課題に直面することがあります。 本記事では、 AWS Database Migration Service (AWS DMS) 、 Amazon Simple Storage Service (Amazon S3) 、 AWS Glue 、 AWS Step Functions を使い、Oracle ソースから Amazon Aurora DSQL へデータを移行する手順を説明します。エンタープライズ規模のデプロイに適した、自動化されたコスト効率の高い移行パイプラインを構築します。 このソリューションの完全なソースコードは、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリで入手できます。 Amazon Aurora DSQL の概要 Amazon Aurora DSQL は、高可用性、スケーラビリティ、パフォーマンスを必要とするアプリケーション向けに設計された、サーバーレスの分散 SQL データベースです。主な特長は次のとおりです。 サーバーレスアーキテクチャ – Amazon Aurora DSQL はフルマネージドのサーバーレスデータベースサービスで、需要に応じてコンピューティング、ストレージ、実行レイヤーを自動的にスケールします。 PostgreSQL 互換性 – Amazon Aurora DSQL は PostgreSQL 互換の SQL 構文と機能を提供するため、PostgreSQL インターフェイスで動作するアプリケーションに適しています。 分散設計 – 分散アーキテクチャを採用し、複数のアベイラビリティーゾーンにわたる高可用性と耐久性を実現します。 マルチリージョン対応 – Amazon Aurora DSQL は、ディザスタリカバリやグローバルアプリケーション向けにマルチリージョンデプロイをサポートします。 IAM 統合 – AWS Identity and Access Management (IAM) と統合し、認証とアクセス制御を行います。 暗号化 – Amazon Aurora DSQL は、データセキュリティのために保管時と転送時の暗号化を提供します。 移行の課題と要件 エンタープライズデータベースを Amazon Aurora DSQL に移行する際には、いくつかの固有の課題に直面します。 認証の複雑さ – Amazon Aurora DSQL では、特定のトークン生成要件を伴う IAM ベースの認証が必要です。必要なロールを引き受けられる AWS サービスは限られているため、直接接続できる手段が制限され、認証を慎重に管理する必要があります。 スキーマ作成の自動化 – Amazon Aurora DSQL では、データをロードする前にスキーマとテーブルを明示的に作成する必要があります。そのため、ソースデータベースからのスキーマ分析と変換を自動化する仕組みが必要です。 データロードの制約 – Amazon Aurora DSQL は主にファイルからの COPY コマンドでのデータロードをサポートしており、移行戦略に固有の要件が生じます。ファイルはデータベースエンジンからローカルにアクセスできる必要があり、移行パイプラインの構成方法に影響します。 コスト最適化 – 中間処理に Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使う従来の方法では、特に移行期間が長期にわたる大規模データベースで、ストレージとコンピューティングのコストが大きくなることがあります。 ソリューションの概要 次の図は、ソリューションのアーキテクチャを示しています。 ワークフローは次のステップで構成されます。 パイプラインがオンプレミスの Oracle データベースからデータを抽出します。ソースには、AWS DMS がサポートする他のリレーショナルデータベースを使うこともできます。 AWS DMS がデータを Amazon S3 に移行し、AWS Glue データカタログを作成します。 Step Functions が AWS DMS タスクの進行を開始・監視し、 AWS Lambda 関数と AWS Glue ジョブを起動します。 Lambda 関数が AWS DMS からテーブルマッピングを取得して Step Functions に返し、Step Functions がそれを AWS Glue ジョブに渡します。 AWS Glue がターゲットの Amazon Aurora DSQL データベースに接続し、データカタログを使ってカラムを識別します。続いてターゲットにスキーマを作成し、ターゲットのデータ型にデータを変換します。最後に Amazon S3 からデータを読み取り、Amazon Aurora DSQL データベースにロードします。 前提条件 始める前に、次の前提条件を満たしていることを確認してください。 AWS DMS のレプリケーションソースとして設定し、データベース移行の準備が整ったソース Oracle データベース。 中間データストレージ用の S3 バケット。次の設定を行います。 ブロックパブリックアクセスを有効化。 デフォルト暗号化 (SSE-S3 または SSE-KMS) を構成。 AWS DMS がターゲットとして使用し、AWS Glue がアクセスするために必要な権限。 AWS DMS タスクの監視、Lambda 関数の起動、AWS Glue ジョブの管理を行うサービスロールを引き受ける Step Functions ワークフローを作成するためのユーザー権限。 特定の Amazon Aurora DSQL クラスターにスコープを限定した次の IAM 権限。 iam:CreateServiceLinkedRole 。 dsql:DbConnect 。 dsql:DbConnectAdmin 。 dsql:GenerateDbConnectAdminAuthToken 。 dsql:GenerateDbConnectAuthToken 。 Amazon Aurora DSQL のターゲットインスタンスを作成する Amazon Aurora DSQL クラスターを作成するには、次のステップを実行します。 Amazon Aurora DSQL コンソールのナビゲーションペインで、[ Clusters ] を選択します。 [ Create cluster ] を選択し、[ Single-Region ] または [ Multi-Region ] を選択します。 暗号化設定、削除保護、タグを構成します。 [ Create cluster ] を選択します。 クラスター作成の詳細な手順、高度な設定、マルチリージョンのセットアップオプションについては、 Aurora DSQL の開始方法 を参照してください。 AWS DMS タスクを構成する 次のステップで AWS DMS タスクを構成します。 データ量を処理できる十分な容量のレプリケーションインスタンスを作成します。 接続情報を設定し、転送時の暗号化のために SSL モードを verify-full に設定した Oracle ソースエンドポイントを作成します。 次の設定で Amazon S3 ターゲットエンドポイントを作成します。 DataFormat を CSV に設定。 EncryptionMode を SSE_KMS に設定。 ServerSideEncryptionKmsKeyId を KMS キーの ARN に設定。 GlueCatalogGeneration と IncludeOpForFullLoad を True に設定。 AWS DMS 移行タスクを作成します。 移行タイプに [ full load ] を選択します。 ソーススキーマのテーブルマッピングを構成します。 ラージオブジェクト (LOB) の処理とパフォーマンスに適したタスク設定を行います。 移行タスクの起動設定を [ Manually later ] に設定します。 AWS DMS の詳細な構成手順、エンドポイント設定、タスク構成オプションについては、 Creating a task 、 Using an Oracle database as a source for AWS DMS 、 Using Amazon S3 as a target for AWS Database Migration Service を参照してください。 Lambda 関数を作成する AWS DMS タスクのマッピングからテーブル情報を抽出する Lambda 関数を作成します。この関数は DMS タスクのテーブルマッピングを解析してターゲットのテーブル名を特定し、それを AWS Glue ETL ジョブに渡します。 Lambda 関数の完全なコードは、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 この関数は主に次の処理を行います。 DMS タスクイベントから tableMappings を解析します。 DMS ルールを順に処理し、選択タイプのルールを見つけます。 object-locator からテーブル名を抽出して返します。 Lambda の構成 メモリ – 128 MB (テーブル名の抽出には十分です)。 タイムアウト – 15 秒 (5 秒より長く設定します)。 IAM ロール – 次の AWS DMS 権限を持つ基本的な Lambda 実行ロール。 dms:DescribeReplicationTasks – AWS DMS タスクの詳細とテーブルマッピングを読み取ります。 dms:DescribeTableStatistics – テーブル単位の移行統計にアクセスします。 Lambda の IAM 権限要件の詳細については、 AWS Lambda アクセス許可の管理 および AWS DMS API Reference を参照してください。 AWS Glue ETL ジョブを作成する AWS Glue ETL ジョブは、スキーマの作成、データ型のマッピング、Amazon Aurora DSQL へのデータロードを担います。 データカタログのセットアップ Amazon S3 をターゲットにすると、AWS DMS がデータカタログのエントリを自動的に作成します。別途クローラーを用意する必要はありません。AWS DMS は移行中にデータカタログを生成し、Oracle ソースの適切なスキーマ情報を使ってテーブルをカタログ化します。 ジョブの構成 ジョブタイプ – Spark ETL。 AWS Glue バージョン – 3.0 以降。 依存 JAR のパス – postgresql-42.7.4.jar (JAR ファイルをダウンロードし、S3 のアクセスパスを指定します)。 Python モジュールのパス – boto3>=1.35.95 (Amazon Aurora DSQL の認証に使用します)。 ワーカータイプ – データ量に応じて調整します。 Glue ジョブの IAM 権限 AWS Glue ジョブには、次のサービスにまたがる権限が必要です。完全な IAM ポリシーについては、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 ステートメント アクション 目的 S3Access s3:GetObject , s3:ListBucket 移行データを Amazon S3 から読み取る GlueDataCatalogAccess glue:GetDatabase , glue:GetTable , glue:GetPartitions スキーマのメタデータにアクセスする AuroraDSQLAccess dsql:DbConnect , dsql:DbConnectAdmin ターゲットデータベースに接続する DSQLTokenGeneration dsql:GenerateDbConnectAdminAuthToken , dsql:GenerateDbConnectAuthToken 認証トークンを生成する AWS Glue の IAM 要件の詳細については、 「AWS Glue」 のセキュリティ および Aurora DSQL での Identity and Access Management を参照してください。 AWS Glue ETL ジョブのスクリプト 完全なスクリプトは、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 このスクリプトは主に次の処理を行います。 トークン生成 – boto3.client("dsql") の generate_db_connect_admin_auth_token() を使って IAM 認証トークンを生成します。 スキーマ検出 – AWS Glue データカタログからテーブルスキーマを読み取ります。 データ型マッピング – 次の表のように、Oracle と Glue のデータ型を Amazon Aurora DSQL 向けの PostgreSQL 互換型にマッピングします。 Glue の型 Amazon Aurora DSQL の型 string VARCHAR(255) int INTEGER bigint BIGINT double DOUBLE PRECISION float REAL boolean BOOLEAN timestamp TIMESTAMP date DATE decimal NUMERIC long BIGINT binary BYTEA map JSONB struct JSONB array TEXT[] 入力検証 – SQL インジェクションを防ぐため、テーブル名を SQL ステートメントで使用する前に、正規表現 ^[a-zA-Z0-9_]{1,64}$ で検証します。 DDL 実行 – 明示的なトランザクション管理を伴う JDBC 接続を使って、Amazon Aurora DSQL にテーブルを作成します。 データロード – Amazon S3 から CSV データを読み取り、型キャストを適用し、トランザクション分離レベル REPEATABLE_READ とバッチサイズ 9,900 行で JDBC を使って Amazon Aurora DSQL に書き込みます。 Glue ジョブの主な設定 トークン生成 – boto3.client("dsql") の generate_db_connect_admin_auth_token() メソッドを使用します。 トークンの有効期限 – 最大 24 時間です。ここでは 1 時間に設定しています。 ユーザー ID – サンプルコードで使用するユーザー ID は admin です。 データ型マッピング戦略 – GlueCatalogGeneration を使うと、スキーマのカラムにはソースの値と一致しないことがあるデフォルトのデータ型が割り当てられます。AWS Glue のコードでデータ型マッピング戦略を定義してください。Amazon Aurora DSQL がサポートするデータ型については、 Amazon Aurora DSQL ユーザーガイド を参照してください。 トランザクション分離レベル – Amazon Aurora DSQL ターゲットでは、データ整合性のために REPEATABLE_READ が必要です。 Step Functions ステートマシンを作成する Step Functions ステートマシンが移行ワークフローを制御します。ステートマシンは AWS DMS タスクを開始し、その状態を監視します。AWS DMS タスクが完了すると、テーブルマッピングを抽出してテーブル名を AWS Glue ジョブに渡します。その後、AWS Glue ジョブを起動します。 次の図は、ステートマシンのワークフローを示しています。 ステートマシンワークフローの特徴 AWS DMS の自動開始 – レプリケーションタスクをプログラムで開始します。 進行状況の監視 – AWS DMS タスクの状態を 60 秒ごとにポーリングします。 完了の検出 – stopped ステータスと進行状況 100% を待ちます。 エラー処理 – 失敗した AWS DMS タスクを適切に処理します。 Lambda 連携 – AWS Glue ジョブ向けにテーブル情報を抽出します。 AWS Glue ジョブの起動 – テーブルパラメータを指定して AWS Glue ETL ジョブを開始します。 セットアップの手順 ステートマシンを構成するには、次のステップを実行します。 Step Functions コンソールで、[ Create state machine ] を選択します。 [ Write your workflow in code ] を選択し、ステートマシン定義を入力します。完全なステートマシン定義については、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 定義内の Amazon リソースネーム (ARN) とジョブ名を更新します。 AWS DMS タスクの ARN を、自分のタスクの ARN に置き換えます。 Lambda 関数の ARN を、自分の関数の ARN に置き換えます。 AWS Glue ジョブ名を、自分のジョブ名に置き換えます。 ステートマシンを作成する前に、参照する ARN が存在することを確認します。 次の権限を持つ IAM 実行ロールを作成します。 dms:StartReplicationTask 。 dms:DescribeReplicationTasks 。 lambda:InvokeFunction 。 glue:StartJobRun 。 CloudWatchLogsDeliveryFullAccessPolicy (ステートマシンの実行ログを保存するため)。 ステートマシンのステート ステートマシンは、次のステートを通じて移行を制御します。 ステート タイプ 目的 StartDMSTask Task DMS レプリケーションタスクを開始する GetDMSTaskDetails Task レプリケーションタスクの状態を取得する CheckDMSTaskStatus Choice ステータス (stopped、failed、running) に応じて分岐する WaitForDMSTask Wait 60 秒ごとにポーリングする DMSTaskFailed Fail 失敗したタスクのエラー処理 ExtractTableName Task Lambda を呼び出してテーブル名を取得する StartGlueJob Task テーブル名パラメータを指定して AWS Glue ETL ジョブを起動する Step Functions のセットアップと AWS DMS との統合パターンの詳細については、 AWS Step Functions デベロッパーガイド および Create and run AWS DMS tasks using AWS Step Functions を参照してください。 セキュリティに関する考慮事項 このソリューションでは、機密データを扱う可能性のある複数の AWS サービスを使用します。次のセキュリティのベストプラクティスに従ってください。 責任共有モデル このアーキテクチャは AWS 責任共有モデル に従います。責任は次のように分担されます。 サービス AWS の管理範囲 お客様の管理範囲 Amazon Aurora DSQL データベースエンジン、パッチ適用、高可用性、インフラストラクチャのセキュリティ IAM ポリシー、VPC エンドポイントの構成、暗号化キーの選択 Amazon S3 ストレージインフラストラクチャ、耐久性、可用性 バケットポリシー、暗号化の構成、アクセス制御、ブロックパブリックアクセス AWS DMS レプリケーションインスタンスの OS、エンジンのパッチ適用 エンドポイントのセキュリティ、SSL/TLS の構成、ネットワークアクセス セキュリティ実装の優先順位 データ移行を開始する前に、次の順序でセキュリティ対策を実装してください。 S3 バケットの暗号化 (SSE-KMS) とブロックパブリックアクセスを構成します。 各サービス (AWS DMS、Lambda、AWS Glue、Step Functions) に最小権限の IAM ロールを作成します。 カスタマーマネージド KMS キーで Amazon Aurora DSQL クラスターの暗号化を有効にします。 データがパブリックインターネットを経由しないように、Amazon S3 と AWS Glue の VPC エンドポイントを構成します。 監査とモニタリングのために、AWS CloudTrail と Amazon CloudWatch のログ記録を有効にします。 すべてのデータベース接続で SSL/TLS が強制されていることを確認します。 セキュリティ検証の手順 デプロイ後、次の点を確認します。 # Confirm S3 bucket encryption aws s3api get-bucket-encryption --bucket your-migration-bucket # Confirm Block Public Access aws s3api get-public-access-block --bucket your-migration-bucket さらに、次の点を確認します。 本番環境の IAM ポリシーにワイルドカード ( * ) リソースが含まれていないこと。 DMS レプリケーションインスタンスがパブリック IP を持たないプライベートサブネットに配置されていること。 すべての JDBC 接続文字列で、Amazon Aurora DSQL への接続に sslmode=require が使われていること。 認証トークンが設定した期間内 (AWS は 1 時間を推奨) に失効すること。 移行中のデータ保護 AWS DMS エンドポイントで転送時の暗号化を有効にします (Oracle ソースには SSL/TLS、Amazon S3 ターゲットには SSE-KMS)。 認証トークンをログに出力しないでください。有効期間の短いトークン (1 時間) を使い、設定は環境変数または AWS Secrets Manager に保存します。 aws:SecureTransport 条件を使って、暗号化されていない通信を拒否する S3 バケットポリシーを適用します。完全なバケットポリシーについては、GitHub の sample-oracle-to-aurora-dsql-migration リポジトリを参照してください。 AWS Glue ジョブの IAM ロールを、特定の S3 プレフィックスと Amazon Aurora DSQL クラスターに限定します。ワイルドカードの ARN は避けてください。 KMS キーポリシーを使って、移行データを暗号化・復号できるプリンシパルを制御します。 脅威モデル 次の表は、このアーキテクチャで特定し、緩和した脅威を示しています。 脅威 緩和策 過剰な権限を持つ IAM ロール すべての IAM ポリシーを、ワイルドカードではなく特定のリソース ARN に限定します。 テーブル名を介した SQL インジェクション テーブル名を SQL ステートメントで使用する前に、正規表現 ^[a-zA-Z0-9_]{1,64}$ で入力を検証します。 認証トークンの盗難やリプレイ 有効期間の短いトークン (有効期限 1 時間) を使い、ログには出力せず、認証情報はコードではなく環境変数に保存します。 S3 中間ストレージへの不正アクセス ブロックパブリックアクセスを有効にし、バケットポリシーを特定の IAM ロールに限定し、SSE-KMS 暗号化を使用します。 コードのセキュリティレビュー 本記事のすべてのコードサンプルは、入力検証、安全な認証処理、最小権限のアクセスパターン、インジェクション攻撃への防御を対象に、手動でセキュリティレビューを実施しています。レビューは、Bandit 1.7 (Python) と ESLint security plugin (JavaScript) による静的解析を使って行いました。 検出結果: Critical または High の重大度の問題は見つかりませんでした。Medium の検出結果 (情報レベルのログ出力) はレビューのうえ、サンプルコードとして妥当と判断しました。 本番環境にデプロイする前に、Amazon Inspector や同等のツール (Bandit (Python)、ESLint security plugin (JavaScript) など) で独自に静的解析スキャンを実行し、組織のセキュリティ基準に照らして検証してください。 Lambda のセキュリティガイドライン インターネットアクセスのない VPC プライベートサブネットに関数をデプロイします。AWS サービスには VPC エンドポイントを使用します。 AWS Key Management Service (AWS KMS) を使って環境変数を暗号化します。 リソースベースのポリシーを適用し、呼び出しを Step Functions のみに制限します。 実行ロールには最小権限の原則を適用します ( dms:DescribeReplicationTasks と dms:DescribeTableStatistics のみ)。 予約済み同時実行数を設定し、呼び出しの暴走を防ぎます。 Step Functions のセキュリティガイドライン AWS KMS カスタマーマネージドキーを使って、ステートマシンの保管時の暗号化を有効にします。 実行履歴のために、暗号化を有効にした Amazon CloudWatch Logs を有効にします。 ステートマシンの入力や出力で機密データ (トークン、パスワード) を渡さないようにします。AWS Systems Manager Parameter Store または AWS Secrets Manager を使用します。 実行ロールが最小権限に従っていることを確認します (AWS DMS、Lambda の呼び出し、AWS Glue の StartJobRun の権限のみ)。 IAM リソースベースのポリシーを使って、ステートマシンへのアクセスを制限します。 クリーンアップ 今後の課金を避けるため、このチュートリアルで作成したリソースを削除します。 Step Functions コンソールで、対象のステートマシンを選択し、[ Delete ] を選択します。 Lambda コンソールで、対象の関数を選択し、[ Actions ]、[ Delete ] の順に選択します。 AWS Glue コンソールで、対象の ETL ジョブを選択し、[ Action ]、[ Delete job ] の順に選択します。 AWS DMS コンソールで、次のリソースをこの順序で削除します。 移行タスク。 エンドポイント (ソースとターゲット)。 レプリケーションインスタンス。 Amazon S3 コンソールで、移行用バケットを空にして削除します。 Amazon Aurora DSQL コンソールで、対象のクラスターを選択し、[ Delete ] を選択します。 IAM コンソールで、このソリューション用に作成した IAM ロールとポリシーを削除します。 カスタマーマネージド KMS キーを使用した場合は、まだ必要かどうかを評価し、適切であれば削除をスケジュールします。 まとめ 本記事では、AWS DMS、Step Functions、Lambda、AWS Glue を使った自動化のアプローチで、Oracle から Amazon Aurora DSQL へ移行する手順を説明しました。このソリューションは、Amazon Aurora DSQL のサーバーレスアーキテクチャ特有の課題に対応します。Amazon S3 を中間ストレージとして使い、ワークフロー全体に十分なエラー処理を組み込むことで、手作業や運用の複雑さを抑えつつ、信頼性の高いデータ移行を実現できます。 Amazon Aurora DSQL の進化に合わせて、この移行フレームワークはデータベースモダナイゼーションを進めるうえで確かな基盤になります。インフラストラクチャのコストと管理の負荷を抑えながら、Amazon Aurora DSQL を最大限に活用できます。 この移行アプローチを始めるには、次の手順を実行します。 GitHub の sample-oracle-to-aurora-dsql-migration リポジトリをクローンします。 テストテーブルを使って、AWS アカウントに Step Functions ワークフローをデプロイします。 本番のワークロード全体に拡張します。 ご質問やフィードバックがあれば、コメントで共有するか、 AWS re:Post community をご覧ください。 著者について Aliasghar Hussain AWS の Database Specialist Solutions Architect です。Amazon RDS、DocumentDB、DynamoDB、ElastiCache といったクラウドデータベース技術で 6 年以上の経験があります。また、複雑なデータベース移行戦略、モダナイゼーション、インフラストラクチャ最適化に関する技術的なガイダンスを提供する分野の専門家として、お客様の AWS におけるクラウド導入の加速を支援しています。 Wasim Shaikh AWS でデータベースを専門とする Senior Solutions Architect です。お客様と協力して、さまざまなデータベースおよび分析プロジェクトに関するガイダンスと技術支援を提供し、AWS を利用する際のソリューションの価値向上を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

はじめに こんにちは、タイミーでエンジニアをしている徳富( @yannKazu1 )です。 タイミーではメインサービスのバックエンドを Rails で開発しています（Go を採用しているプロダクトもありますが、本記事では Rails を前提とします）。 突然ですが、皆さんのチームでは CI の待ち時間、気になっていませんか？ 「Push した、コーヒー淹れた、戻ってきた、まだ回ってる……」みたいな経験は、開発者なら一度はあるのではないでしょうか。 本記事では、そんな状況を改善するために GitHub Actions 上のテスト実行パイプラインで取り組んだ 3 つの高速化テク を紹介します。どれも「知っていれば明日から試せる」くらいの温度感なので、気軽に読んでいただければと思います。 1. キャッシュの保存先を GitHub Cache から S3 に移行 課題: actions/cache が安定して速くない 最初にぶつかった壁が actions/cache の速度でした。 vendor/bundle （数百 MB〜1 GB 超）の save/restore でやたら時間がかかることがあり、リストアだけで数分待たされる場面がちょくちょくありました。これはセルフホストランナーに限った話ではなく、GitHub ホステッドランナーでも起きます。 実際、公式リポジトリにも Extremely slow cache on self-hosted from time to time という Issue が立っていて、セルフホスト・GitHub ホステッド問わず同様の報告が寄せられています。 さらに私たちの場合、 AWS 上のセルフホストランナー を使っているのでなおさらです。 actions/cache のバックエンドは Azure Blob Storage のため、セルフホストランナーからだとインターネット経由のアクセスになり、スループットが 約 20 MB/s まで落ちる ケースも報告されています（ Actuated Blog ）。突発的に遅いうえに経路も遠い——これでは安定した速度は望めません。 容量面でも、リポジトリあたり 10GB の制限があります。また、7 日間アクセスのないキャッシュは自動削除されます。その結果、ブランチが増えるとすぐに上限に達し、必要なキャッシュが消えてしまうのも地味にストレスでした。 解決策: runs-on/cache で S3 をバックエンドに そこで [runs-on/cache](https://github.com/runs-on/cache) を導入し、キャッシュの保存先を 同一リージョン（東京）の S3 バケット に切り替えました。 前述のとおり、セルフホストランナーで  actions/cache  を使うとスループットが ~20 MB/s まで落ちるケースがあります。一方  runs-on/cache  は同一リージョンの S3 を使えるため、200 MiB/s 以上 のスループットが出ます（ 公式ドキュメント ）。単純計算で 10 倍近い改善 です。 actions/cache とインターフェースがそのまま同じなので、 uses: を差し替えて環境変数を 1 つ足すだけで移行できました。 # .github/actions/setup-ruby-with-s3-cache/action.yml - name : Restore cache uses : runs-on/cache@v4.2.3-r2 env : RUNS_ON_S3_BUCKET_CACHE : your-gha-cache-bucket with : path : "**/vendor/bundle" key : bundle-v1-${{ runner.os }}-${{ inputs.ruby_version }}-${{ hashFiles('Gemfile.lock') }} restore-keys : | bundle-v1-${{ runner.os }}-${{ inputs.ruby_version }}- bundle-v1-${{ runner.os }}- なぜ runs-on/cache を選んだか S3 をキャッシュバックエンドにする方法は他にもあります（ tespkg/actions-cache 、 whywaita/actions-cache-s3 、自前の aws s3 cp スクリプトなど）。その中で runs-on/cache にした決め手はこのあたりです。 環境変数 1 つで切り替え : RUNS_ON_S3_BUCKET_CACHE を設定するだけで S3 バックエンドに切り替わる 自前実装が不要 : 圧縮・展開・キャッシュキーのマッチング・フォールバックなど、地味にめんどくさい部分を全部やってくれる 容量無制限 : S3 なので 10GB の制限もキャッシュの自動削除もなし キャッシュキーの設計 キャッシュキーは 3 段階のフォールバック構造にしています。 bundle-v1-Linux-3.3.6-<Gemfile.lock のハッシュ> ← 完全一致（最速） bundle-v1-Linux-3.3.6- ← Ruby バージョン一致 bundle-v1-Linux- ← OS のみ一致 完全一致しなくても、部分一致したキャッシュをリストアして bundle install すれば差分の gem だけで済みます。ゼロからインストールするより圧倒的に速いので、新しいブランチでもほぼキャッシュが効く状態を維持できます。 OIDC 認証で安全に S3 にアクセス AWS へのアクセスには OIDC 認証 を使っています。長期的なアクセスキーをシークレットに保存しなくて済むので、セキュリティ面でも安心です。 - name : Configure AWS credentials uses : aws-actions/configure-aws-credentials@v6 with : role-to-assume : arn:aws:iam::123456789012:role/your-gha-role aws-region : ap-northeast-1 2. マイグレーション結果をまるごとキャッシュ 課題: 毎回のマイグレーションが地味に重い テストジョブは毎回データベースをセットアップします。ここで問題になったのが、マイグレーション数が数百を超えてくると rails db:create db:schema:load だけで 数分かかる ということ。 「schema:load だからすぐ終わるでしょ？」と思いきや、テーブル数が多いとそうでもないんですよね。 解決策: MySQL のデータディレクトリごと S3 にキャッシュ 発想を変えて、 マイグレーション済みの MySQL データディレクトリ ( /var/lib/mysql ) をまるごと S3 にキャッシュ することにしました。要は「マイグレーション済みの DB をそのまま持ってくれば、マイグレーション自体を省略できるよね」という作戦です。 仕組みの全体像 【キャッシュの生成】 【キャッシュの利用】 master ブランチ feature ブランチ db/migrate/** 変更 テストジョブ起動 or 毎日定時 │ │ ▼ ▼ S3 からキャッシュをリストア MySQL 起動 → ./tmp/mysql_data に展開 │ │ ▼ ▼ rails db:create db:migrate MySQL 起動（データマウント済み） │ │ ▼ ▼ ./tmp/mysql_data を S3 に保存 rails db:migrate（差分のみ） │ ▼ テスト実行 キャッシュの生成: master で定期的に焼き直す master ブランチでマイグレーションファイルが変更されたとき、または毎日定時に、専用のワークフローがキャッシュを更新します。 # .github/workflows/update-migration-cache.yml on : push : branches : [ master ] paths : - 'db/migrate/**' - 'db/schema.rb' - '.github/workflows/update-migration-cache.yml' - '.github/actions/migration-hash/**' schedule : - cron : '0 2 * * *' # 毎日 UTC 2:00（JST 11:00）に実行 workflow_dispatch : # 手動実行も可能 やっていることはシンプルです。 MySQL コンテナを起動（データディレクトリを ./tmp/mysql_data にマウント） rails db:create db:migrate でフルマイグレーション実行 ./tmp/mysql_data をまるごと S3 にアップロード - name : Run database migration run : bundle exec rails db:create db:migrate - name : Save migration cache uses : runs-on/cache/save@v4.2.3-r2 env : RUNS_ON_S3_BUCKET_CACHE : your-gha-cache-bucket with : path : ./tmp/mysql_data key : test-${{ runner.os }}-${{ runner.arch }}-mysql${{ steps.migration-hash.outputs.mysql_version }}-${{ runner.environment }}-db-migration-${{ steps.migration-hash.outputs.hash }} キャッシュキーの設計: 何をキーに含めるかが大事 キャッシュキーには地味に気を使っています。 test-Linux-X64-mysql8.0.28-self-hosted-db-migration-<db/schema.rb のハッシュ> │ │ │ │ │ OS ARCH MySQL Ver ランナー環境 スキーマハッシュ ポイントは db/schema.rb のハッシュを含めていること。 マイグレーションの内容が変われば schema.rb も変わる ので、自動的に新しいキャッシュが生成されます。MySQL バージョンやアーキテクチャもキーに入れているのは、バイナリ非互換でハマらないための保険です（一度やらかしました……）。 キャッシュの利用: Composite Action で再利用しやすく キャッシュの利用ロジックは Composite Action に切り出して、RSpec だけでなく Steep（型チェック）など他のワークフローからも使い回しています。 # .github/actions/setup-mysql/action.yml - name : Create MySQL data directory run : mkdir -p ./tmp/mysql_data - name : Restore migration cache id : cache-hit-check uses : runs-on/cache/restore@v4.2.3-r2 env : RUNS_ON_S3_BUCKET_CACHE : your-gha-cache-bucket with : path : ./tmp/mysql_data key : test-${{ runner.os }}-${{ runner.arch }}-mysql${{ mysql_version }}-${{ runner.environment }}-db-migration-${{ hash }} - name : Start MySQL service with docker compose run : docker compose -f compose.ci.yml up -d mysql8 Docker Compose では、リストアしたデータディレクトリをそのままボリュームマウントします。 # compose.ci.yml services : mysql8 : volumes : - ./tmp/mysql_data:/var/lib/mysql MySQL が起動すると、キャッシュ内のデータファイルがそのまま認識されるので、 マイグレーション済みのデータベースが即座に使える 状態になります。 テストジョブでの分岐: キャッシュがあれば差分だけ 各テストジョブでは、キャッシュがヒットしたかどうかで処理を分岐しています。 - name : RSpec run : | if [ "${{ steps.setup-mysql.outputs.cache_hit }}" == "true" ] ; then echo "Using cached migration data, running incremental migration" bundle exec rails db:migrate # ← ブランチ固有の差分だけ else echo "No cache found, running schema load" bundle exec rails db:create db:schema:load fi キャッシュヒット時 : master のマイグレーション済みデータが復元されているので、 db:migrate で差分だけ適用。たいていは数秒で終わります キャッシュミス時 : MySQL バージョンアップ直後などキャッシュがない場合は db:schema:load にフォールバック この仕組みのおかげで、並列のテストジョブそれぞれで数分かかっていた DB セットアップが数秒になりました。体感で一番効果が大きかった施策かもしれません。 3. CI 用 MySQL のパフォーマンスチューニング 課題: デフォルト設定の MySQL が意外とボトルネック テスト環境の MySQL をデフォルト設定のまま使っていたのですが、ある日ふと気づきました。テストでは各テストケースごとに BEGIN / ROLLBACK やテーブルのクリーンアップが走るので、 書き込みが尋常じゃない量になっている んですよね。 デフォルト設定だと、コミットのたびにディスクへの fsync が走ります。本番では安全のために必要ですが、テスト環境では……正直、オーバースペックです。 解決策: テスト環境に限定して、耐久性よりパフォーマンスを優先する CI 専用の compose.ci.yml で、 データ耐久性を思い切って犠牲にして、書き込みパフォーマンスを最大化 しました。 # compose.ci.yml services : mysql8 : image : ${MYSQL_IMAGE} command : > mysqld --innodb-flush-log-at-trx-commit=0 --sync-binlog=0 --skip-innodb-doublewrite environment : MYSQL_ALLOW_EMPTY_PASSWORD : "yes" ports : - "3306:3306" volumes : - ./tmp/mysql_data:/var/lib/mysql 各パラメータの解説 innodb-flush-log-at-trx-commit=0 InnoDB のログ書き込み動作を制御するパラメータです。 値 動作 用途 1（デフォルト） コミットのたびにログをディスクに fsync 本番環境（ACID 完全準拠） 2 コミットのたびに OS バッファに書き込み、 fsync は毎秒 レプリカなど 0 ログの書き込みも fsync も毎秒のバッチ処理 テスト環境 テストで 1 秒以内にクラッシュリカバリが必要な場面はないので、 0 にして コミットごとの fsync オーバーヘッドを完全に排除 しています。 sync-binlog=0 バイナリログ（レプリケーション用）の同期タイミングです。 値 動作 1（デフォルト） コミットごとにバイナリログを fsync 0 OS のファイルシステムキャッシュに任せる テスト環境ではレプリケーションを使わないので、バイナリログを sync_binlog=0 にし、同期を OS のキャッシュに任せることでコミットごとの fsync を省いています。 skip-innodb-doublewrite InnoDB の doublewrite バッファを無効化します。これは書き込み途中のクラッシュに備えて全ページを 2 回書く安全機構なのですが、テスト環境では不要です。無効化すれば 書き込み I/O が大幅に減ります 。 注意: 本番では絶対にやらないでください 念のため書いておきますが、上記の設定は データの耐久性・整合性を犠牲にしています 。 innodb-flush-log-at-trx-commit=0 : クラッシュで最大 1 秒分のトランザクションが消える sync-binlog=0 : クラッシュでバイナリログが不完全になる可能性 skip-innodb-doublewrite : 部分書き込みでデータ破損のリスク テスト環境は「テストが通ればデータは捨てる」使い捨ての世界なので、これらのリスクは許容しています。くれぐれも本番には適用しないように！ まとめ 施策 何をキャッシュ/最適化しているか 効果 S3 キャッシュ vendor/bundle （Gem パッケージ） ダウンロード高速化・容量制限の解消 マイグレーションキャッシュ マイグレーション済み MySQL データ DB セットアップ時間を数分→数秒に MySQL チューニング fsync・doublewrite の無効化 テスト中の書き込み I/O を削減 CI の高速化に近道はなくて、結局はボトルネックを一つずつ潰していくしかありません。 DB のデータ耐久性は不要なので無効化する。マイグレーションは毎回ゼロからやる必要がないのでキャッシュする。キャッシュの保存先は、ネットワーク的に近い場所に置く。こうした「当たり前だけど意外とやっていない」割り切りが、大きな高速化につながりました。 同じような課題を抱えるチームの参考になれば嬉しいです。

G-gen の福井です。当記事では、Google が公開している公式 Agent Skills リポジトリ google/skills について、リポジトリの概要から、収録されているスキルの内容を解説します。 概要 google/skills リポジトリとは 公開背景 ライセンス 使い方 製品別スキル gemini-api alloydb-basics bigquery-basics cloud-run-basics cloud-sql-basics firebase-basics gke-basics Well-Architected Framework 柱別スキル google-cloud-waf-security google-cloud-waf-reliability google-cloud-waf-cost-optimization Recipe スキル google-cloud-recipe-onboarding google-cloud-recipe-auth google-cloud-networking-observability 概要 google/skills リポジトリとは google/skills は、Google が公開している公式の Agent Skills リポジトリです。GitHub 上で公開されており、Google Cloud の各製品やワークロードに関する専門知識を スキル としてパッケージ化したものが収録されています。 これらのスキルを AI エージェントツール（Gemini CLI、Claude Code、Cursor など）に導入することで、Google Cloud に関する正確な知識をもとにタスクを遂行できます。 google/skills が準拠している Agent Skills という規格（仕組み、スキルの構造、使い方など）については、以下の関連記事で解説しています。 blog.g-gen.co.jp 2026年5月現在、リポジトリに収録されているスキルは、以下の 3 つのカテゴリに分類されています。 カテゴリ 内容 製品別スキル Google Cloud の主要な製品（AlloyDB、BigQuery、Cloud Run、Cloud SQL、Firebase、Gemini API、GKE）ごとに、その使用方法やベストプラクティスをまとめたスキルです。 Well-Architected Framework 柱別スキル Google Cloud Well-Architected Framework の各柱に基づいた、アーキテクチャ設計のガイダンスを提供するスキル群です。製品別スキルが特定の製品をどう使うかを教えるのに対し、WAF 柱別スキルはワークロードをどのように設計・評価するかを扱います。 Recipe スキル Google Cloud で頻繁に行われる横断的なタスクを、手順の形でまとめたスキル群です。製品別スキルが特定の製品をどう使うか、Well-Architected Framework 柱別スキルがワークロードをどのように設計・評価するかを扱うのに対し、Recipe スキルは特定のタスクをどの順序で実行するかというレシピ（手順書）の形で、AI エージェントツールにタスクの遂行を支援させるスキルです。 参考 : google/skills - GitHub 参考 : Google Cloud Well-Architected Framework 当記事では、google/skills で公開されているスキルについて概要を紹介します。なお、紹介しているスキルは2026年6月現在、リポジトリで公開されているものです。 公開背景 google/skills リポジトリは、Google Cloud Next '26 のタイミングで Google から公開されました。Google Cloud に関する正確な知識を AI エージェントツールに反映させる手段として、Agent Skills を使うアプローチが Google から正式に提示されました。 Google が公開ブログで強調しているのは、 コンテキスト肥大化（Context Bloat） への対応です。コンテキスト肥大化とは、AI エージェントツールに大量のドキュメントを与えることで、AI エージェントツールの動作が不安定になる現象を指します。Google は、MCP サーバーで全ドキュメントを動的に取得するアプローチに加えて、よく使われる知識やワークフローをあらかじめスキルとしてパッケージ化して配布するという新しい選択肢を提供することを、google/skills の目的としています。 Google は、今後も google/skills リポジトリにスキルを追加していくことを公式ブログで明言しています。 参考 : Level Up Your Agents: Announcing Google's Official Skills Repository ライセンス google/skills リポジトリは、 Apache License 2.0 で公開されています。Apache License 2.0 は、商用利用、改変、再配布、プライベートでの使用が認められているライセンスです。スキルを業務で使用する場合や、スキルをカスタマイズして社内向けに配布する場合も、ライセンス条件に従えば自由に使用できます。 ライセンス条件として、スキルを再配布する場合は、元のライセンス表記と著作権表示を含める必要があります。また、スキルを改変して再配布する場合は、変更を加えた旨を明示する必要があります。 参考 : google/skills - LICENSE 使い方 google/skills のスキルは、Agent Skills の規格に準拠しています。そのため、規格に対応した AI エージェントツール（Gemini CLI、Claude Code、Antigravity、Cursor など）であれば、ベンダーを問わず使用できます。 スキルのインストールには、 npx skills install コマンドを使用します。以下のコマンドを実行することで、リポジトリに収録されたスキルから必要なものを選択してインストールできます。 npx skills install github.com/google/skills 製品別スキル gemini-api 概要 gemini-api は、Agent Platform（旧称 Vertex AI）上で Gemini API を使うための、統合ガイドとして機能するスキルです。 このスキルの特徴は、統合 SDK である Gen AI SDK の使用を強制し、レガシー SDK（ google-cloud-aiplatform 、 @google-cloud/vertexai 、 google-generativeai ）を明示的に禁止している点です。なお、Gen AI SDK のパッケージ名は言語ごとに異なり、Python の場合は google-genai 、Go の場合は google.golang.org/genai などとなっています。 モデル選定においても、 gemini-3.1-pro-preview （複雑な推論）や gemini-3-flash-preview （高速・バランス型）などの新世代モデルを推奨しています。一方で、 gemini-2.0-* 、 gemini-1.5-* 、 gemini-1.0-* 、 gemini-pro は legacy・deprecated として明示的に禁止しています。 主なユースケース 社内チャットボットやエージェントから Gemini を呼び出す Python、Go、Java、JavaScript、TypeScript、C# のコードの記述 社内文書を要約・分類・抽出するアプリケーションの実装 Live API によるリアルタイム音声・映像対話の実装 Nano Banana 系の画像生成モデルを使った、画像や動画の生成・編集アプリケーションの実装 社内データによる Gemini のファインチューニングコードの記述 大量データに対するバッチ予測の実行 alloydb-basics 概要 alloydb-basics は、AlloyDB for PostgreSQL のクラスタ・インスタンス・バックアップの管理と、AlloyDB 専用 MCP ツールとの連携を扱うスキルです。AlloyDB の主要な特徴である AlloyDB AI についても、SKILL.md 本文で言及されています。なお、AlloyDB AI には、ベクトル検索、ハイブリッド検索、AI 関数、自然言語機能などが含まれます。 このスキルの特徴は、セキュリティに関する指示が明記されている点です。クラスタ作成のサンプル手順では、本番環境向けにパスワード認証ではなく IAM データベース認証の使用を推奨しており、パスワードを使用する場合も Secret Manager 経由での管理を求めています。 また、 description 内で AlloyDB model context protocol（MCP）tools との統合を明示しています。AlloyDB 専用の remote MCP server と Gemini CLI extension の使い方を扱うリファレンスも備えており、Agent Skills と MCP を組み合わせる代表的なスキルとなっています。 主なユースケース gcloud CLI による AlloyDB のクラスタとプライマリインスタンスの作成・管理 Python・Java・Node.js・Go の各クライアントから AlloyDB に接続するコードの記述 AlloyDB remote MCP server と Gemini CLI extension を組み合わせた、AlloyDB 操作の AI エージェントツールからの自動化 Terraform による AlloyDB リソースの Infrastructure as Code としての管理 IAM データベース認証や事前定義ロールを使ったセキュリティ設定 bigquery-basics 概要 bigquery-basics は、BigQuery のデータセット・テーブル・ジョブの管理、SQL クエリ実行、データ取り込み、BigQuery ML や Gemini との統合を扱うスキルです。 このスキルの特徴は、 description 内で BigQuery ML と Gemini との統合による AI ドリブンなインサイト提供を明示している点です。これは、AI と統合された分析プラットフォームとしての BigQuery の位置づけを反映しています。 また、このスキルとは別に、BigQuery AI & ML 専用のスキルも用意されています。この専用スキルは google/adk-python リポジトリで公開されており、AI 関数（ generate 、 classify 、 forecast 、 search など）ごとに細かく分かれたリファレンスを備えています。これらのリファレンスは、SKILL.md の Related Skills セクションから参照する構成です。 主なユースケース bq CLI によるデータセットの作成、テーブルの作成・スキーマ管理、クエリ実行などの操作 Python・Java・Node.js・Go の各クライアントライブラリから BigQuery にアクセスするコードの記述 BigQuery remote MCP server と Gemini CLI extension を組み合わせた、BigQuery 操作の AI エージェントツールからの自動化 Terraform による BigQuery のデータセット・テーブル・予約（reservations）の Infrastructure as Code としての管理 IAM ロールと権限の設計、およびデータガバナンスのベストプラクティスに沿った権限設計 別途公開されている BigQuery AI & ML 専用スキルと組み合わせた、AI ドリブンな分析（分類、異常検知、予測、生成系関数など）の実装 cloud-run-basics 概要 cloud-run-basics は、Cloud Run の services、jobs、worker pools という 3 種類のリソースを使い分けて、アプリケーションをデプロイ・管理するスキルです。services は HTTP リクエストに応答するリソース、jobs は手動・スケジュール・イベント駆動でタスクを実行するリソース、worker pools は常時稼働のバックグラウンド処理を行うリソースです。 このスキルの特徴は、コード生成時の必須要件を重要ルールとして強制している点です。具体的には、デプロイされたコードは必ず 0.0.0.0 でリッスンし、注入された $PORT 環境変数を使用することを求めています。 デプロイ失敗時のトラブルシューティングも SKILL.md に組み込まれています。IAM/Permission エラー、Crash on Boot/Healthcheck 失敗、Native Dependency エラーの 3 パターンに対して、ログ取得コマンドや Buildpacks への切り替えといった具体的な対処手順が明記されています。 また、コンテナイメージのソースとしては Artifact Registry の使用が推奨されています。Docker Hub のイメージを使う場合も、1 時間キャッシュ制約を回避するため、Artifact Registry remote repository 経由が推奨されます。 主なユースケース Web アプリや API の HTTP サーバーをコンテナ化した Cloud Run service へのデプロイ バッチ処理や定期実行タスクの Cloud Run job としての実装、および並列タスクでの実行 Kafka・Pub/Sub・RabbitMQ コンシューマなど常時稼働のバックグラウンド処理の Cloud Run worker pool へのデプロイ ソースコードからの直接デプロイ（Buildpacks 自動ビルド、Dockerfile 使用、Preview の --no-build ） Terraform による services、jobs、worker pools、IAM バインディングの Infrastructure as Code としての管理 Cloud Run remote MCP server を使った、Cloud Run 操作の AI エージェントツールからの自動化 cloud-sql-basics 概要 cloud-sql-basics は、Cloud SQL のインスタンス、データベース、ユーザーの管理を扱うスキルです。 このスキルは、MySQL、PostgreSQL、SQL Server の 3 種類のデータベースエンジンを統一的に扱える設計となっています。Quick Start のサンプルには、PostgreSQL 18 が使用されています。 クライアントから Cloud SQL に接続する標準手段としては、Cloud SQL Auth Proxy が Quick Start に組み込まれています。これにより、インスタンス接続名（ PROJECT_ID:REGION:INSTANCE_NAME ）を経由したセキュアな接続パターンが示されている点が特徴です。 主なユースケース gcloud CLI による Cloud SQL の MySQL・PostgreSQL・SQL Server インスタンスの作成・管理 Python・Java・Node.js・Go の各クライアントライブラリから Cloud SQL に接続するコードの記述 Cloud SQL Auth Proxy を使ったセキュアな接続の構成 Cloud SQL remote MCP server と Gemini CLI extension を組み合わせた、Cloud SQL 操作の AI エージェントツールからの自動化 Terraform によるインスタンス・データベース・ユーザーの Infrastructure as Code としての管理 事前定義 IAM ロール、SSL/TLS 証明書、Auth Proxy を使ったセキュリティ設定 firebase-basics 概要 firebase-basics は、Firebase の製品・サービスを使うプロジェクト、特にモバイル・Web アプリ開発の作業全般を扱うスキルです。 このスキルの特徴は、SKILL.md の冒頭で別リポジトリ firebase/agent-skills のインストールを重要な事前要件として強く要求している点です。具体的には、プランニングモード使用時の事前タスク登録、npm の存在確認、Node.js のインストール案内、 npx -y skills add firebase/agent-skills -y の実行までを、順序立てて指示しています。 これは、outdated patterns（古いパターン）の使用を防ぐことを目的としています。そのため firebase-basics は単独では完結せず、 firebase/agent-skills リポジトリの別スキル群と組み合わせて使う前提の設計となっています。 主なユースケース Firebase CLI（ npx -y firebase-tools@latest ）を使った Firebase プロジェクトの作成・管理 JavaScript/TypeScript などのクライアントライブラリから Firebase に接続するコードの記述 Firebase MCP server や Terraform などの IaC ツールを使った構成 Firebase のセキュリティ機能の設定 firebase/agent-skills リポジトリの追加スキル群と組み合わせた、Firebase Hosting などの Firebase プロダクトを扱う作業 gke-basics 概要 gke-basics は、Google Kubernetes Engine（GKE）クラスタの設計、作成、構成、運用全般を扱うスキルです。 このスキルは、SKILL.md 内で推奨される Autopilot 構成をデフォルトとして強制しています。これにより、Standard モードではなく Autopilot を推奨する設計指針を、AI エージェントツールに与えます。 また、 description 内で「WHEN:」というキーワードを使い、AI エージェントツールがこのスキルを起動すべき具体的なトリガーキーワードを大量に列挙しています。トリガーキーワードには、 create GKE cluster 、 design GKE networking 、 secure GKE 、 optimize GKE cost 、 GKE inference 、 GKE upgrade などがあります。 リファレンスドキュメントの数も特徴的です。GKE のリファレンスドキュメントは 20 個以上あり、他の製品スキルの 3 倍以上の規模で、GKE の広い側面を網羅しています。なお、他の製品スキルのリファレンスドキュメントは 6 個程度です。さらに SKILL.md 本体には、シナリオ・トリガーキーワード・参照ファイルの対応表が明示されています。これにより、AI エージェントツールが Activation 後の Execution で適切なドキュメントを選択しやすい設計となっています。 主なユースケース Autopilot モードでの GKE クラスタのプロビジョニングと、クラスタ作成時のチェックリストに沿った本番環境のセットアップ VPC ネイティブ、プライベートクラスタ、Gateway API、Ingress などのネットワーク設計 Workload Identity、Secret Manager、RBAC、Binary Authorization を使ったセキュリティハードニングの実装 HPA、VPA、Cluster Autoscaler、Node Auto-Provisioning を使ったオートスケーリング設定 Spot VMs、ComputeClass、Committed Use Discount などを使ったコスト最適化の実装 GPU・TPU ノードプールと vLLM、GIQ などを使った LLM 推論ワークロードのデプロイ Prometheus、Grafana、Cloud Logging を使った可観測性の構築、およびマルチテナント、バッチ/HPC、バックアップ/DR の設計 Well-Architected Framework 柱別スキル google-cloud-waf-security 概要 google-cloud-waf-security は、Google Cloud Well-Architected Framework のセキュリティ柱に基づき、ワークロードのセキュリティ評価と設計推奨を行うスキルです。 このスキルは、製品別スキルと異なり references/ ディレクトリを持たない、設計指針型のスキルです。SKILL.md 本体に、概要、コア原則、関連する Google Cloud 製品、ワークロード評価のための質問、検証チェックリストの 5 セクションが記述されています。 WAF セキュリティ柱には 7 つの原則があり、それぞれに対応する Google Cloud 製品が明示的にマッピングされています。7 つの原則とは、Security by design、Zero trust、Shift-left security、Preemptive cyber defense、Use AI securely and responsibly、Use AI for security、Meet regulatory, compliance, and privacy needs です。 各原則には、それぞれ 10 個程度のワークロード評価のための質問と、検証チェックリストが用意されています。これにより、AI エージェントツールがユーザーのワークロードに対して、評価のための質問を体系的に投げかけられる構造を持つ点が特徴です。 主なユースケース 既存または計画中の Google Cloud ワークロードに対するセキュリティ評価の実施と、改善点の特定 新規プロジェクトの設計初期段階での、Security by Design の原則に沿った要件定義とアーキテクチャ設計 Zero Trust 原則（IAP、VPC Service Controls など）に基づくアクセス制御とネットワーク設計 Shift-left Security の原則に従った、Cloud Build、Binary Authorization、Artifact Registry を使ったセキュア CI/CD パイプラインの構築 Security Command Center、Google Threat Intelligence、Google SecOps を使った脅威検知と対応体制の整備 AI ワークロードのセキュリティ確保（モデル保護、データポイズニング対策、SAIF 準拠） 規制コンプライアンスやプライバシー要件（Assured Workloads、Organization Policy Service など）への対応 google-cloud-waf-reliability 概要 google-cloud-waf-reliability は、Google Cloud Well-Architected Framework の信頼性柱に基づき、ワークロードの信頼性評価と設計推奨を行うスキルです。 このスキルは、セキュリティ柱と同様の 5 セクションで構成された設計指針型のスキルです。信頼性柱には 9 つの原則があり、ユーザー体験に基づく信頼性定義、現実的な SLO 設定、リソース冗長性、水平スケーラビリティ、可観測性、グレースフルデグラデーション、障害復旧テスト、データ損失復旧テスト、ブレームレスなポストモーテムが示されています。 関連する Google Cloud 製品は、Compute、Networking、Storage and databases、Operations、Disaster recovery の 5 カテゴリでマッピングされています。 このスキルの特徴は、 SRE （Site Reliability Engineering）領域の概念が SKILL.md に組み込まれている点です。SLO、エラーバジェット、RTO/RPO、ブレームレス文化などがその例です。これにより、Google が SRE で長年蓄積した知見を、AI エージェントツールから引き出せる構造を持ちます。 主なユースケース 既存または計画中の Google Cloud ワークロードに対する信頼性評価の実施と、改善点の特定 ユーザー体験に基づく SLI/SLO の定義と、エラーバジェットを使った機能リリース速度の管理 単一障害点を排除する冗長構成（マルチゾーン、マルチリージョン）と、ロードバランシング、水平スケーリングの設計 Cloud Monitoring、Cloud Logging、Managed Service for Prometheus を使った可観測性の構築とアラート設計 サーキットブレーカ、リトライ、レート制限などのパターンを使ったグレースフルデグラデーションの実装 カオスエンジニアリングや game days を使った障害復旧テスト、および Backup and DR Service を使ったデータ損失からの復旧テスト（RTO/RPO）の計画 ブレームレスなポストモーテムプロセスの整備と、インシデントからの組織的な学習 google-cloud-waf-cost-optimization 概要 google-cloud-waf-cost-optimization は、Google Cloud Well-Architected Framework のコスト最適化柱に基づき、ワークロードのコスト評価とコスト効率設計の推奨を行うスキルです。 このスキルは、セキュリティ柱・信頼性柱と同様の 5 セクションで構成された設計指針型のスキルです。概要セクションでは、クラウドコストがオンプレミスの CapEx （資本的支出）モデルとは大きく異なる点を明示しています。そのうえで、 OpEx （運営支出）管理と FinOps 文化への移行を前提とした設計指針を提供しています。 コスト最適化柱には 4 つの原則があり、ビジネス価値とのアライメント、コスト意識の文化醸成、リソース利用の最適化、継続的最適化が示されています。これらの原則に対応する Google Cloud 製品は、可視化と監視、自動化と最適化ツール、効率的なインフラ、組織とガバナンスの 4 カテゴリに整理されてマッピングされています。 このスキルの特徴は、検証チェックリストが他の WAF 柱と比べて具体的・定量的である点です。たとえば「100% のリソースに env 、 team 、 app のラベル」「月次でのコミットメント見直し」「アイドルリソースの月次削除」などが挙げられます。これにより、AI エージェントツールがコスト最適化の現状を、実測可能な指標で評価できる構造を持ちます。 主なユースケース 既存または計画中の Google Cloud ワークロードに対するコスト評価の実施と、削減ポイントの特定 クラウド支出のビジネス価値との整合と、IT 投資の優先順位付け BigQuery billing export と Looker Studio を使ったコスト可視化ダッシュボードの構築 Recommender / Active Assist や FinOps hub を使った、アイドルリソース、リサイズ機会、未使用コミットメントなどの自動的な最適化提案の取り込み Spot VMs、Committed Use Discounts（CUD）、Cloud Storage Lifecycle Policies などを使ったコスト削減の実装 Resource Manager（組織・フォルダ・プロジェクト）、Labels、Organization Policy Service を使ったコスト配賦と支出ガバナンスの構築 Cloud Run、Cloud Run functions、GKE Autopilot などのマネージドサービスへの移行による運用コストの削減 Recipe スキル google-cloud-recipe-onboarding 概要 google-cloud-recipe-onboarding は、個人開発者が Google Cloud を初めて使い始めるための、アカウント設定からリソースデプロイまでの一連の手順をまとめたスキルです。 製品別スキルや WAF 柱別スキルと異なり、Recipe 形式の構造を持ちます。具体的には、7 段階の順次実行手順と、4 項目の完了判定ロジックで構成されており、AI エージェントツールが手順を逐次実行しながら、完了状態を検証できる設計となっています。 対象は、エンタープライズ向けではなく個人開発者です。SKILL.md には、個人開発者向けの簡略化された手順であると明記されています。なお、組織のオンボーディングが必要な場合は、SKILL.md 内から別途 Enterprise Setup Guide への参照が案内されます。 さらに SKILL.md の冒頭には、確認質問として 5 個の事前質問が配置されています。事前質問の内容は、Google アカウントの有無、個人と組織のどちらか、IT 管理者かどうか、最初に作りたいリソース、CLI/IDE/Console の選好です。これにより、AI エージェントツールがユーザーの状況を踏まえた手順を選択できる構造を持ちます。 主なユースケース Google Cloud を初めて使う個人開発者による、無料クレジット（$300）の有効化からプロジェクト作成、CLI セットアップ、最初のリソースデプロイまでの順次実行 最初のプロジェクトの作成と、Project ID の取得、および請求アカウントとの紐付け gcloud CLI のインストールと、 gcloud init によるローカル環境から Google Cloud を操作できる状態の構築 必要な API（Cloud Run、Compute Engine、Cloud Storage などの API）の gcloud services enable による有効化 用途に応じた Cloud Run、Compute Engine、Cloud Storage からの最初のリソースの選択とデプロイ Validation Logic による、Project 作成、Billing 連携、CLI 認証、Resource 動作の 4 つの確認と、オンボーディング完了の判定 google-cloud-recipe-auth 概要 google-cloud-recipe-auth は、Google Cloud のサービスや API への認証・認可全般を扱うスキルです。人間ユーザー、サービスアイデンティティ、ADC（Application Default Credentials）、外部クラウドからのアクセスまでを網羅しています。 このスキルの特徴は、Service Account Key の使用を強く非推奨している点です。SKILL.md 内では、Service Account Key を危険な JSON ファイルと表現し、ローカルでの使用を強く避けるよう指示しています。代わりに、Service Account Impersonation、リソースへのアタッチ、Workload Identity Federation を全面的に推奨しています。なお、検証チェックリストにも、キーをローカルで使っていないかを確認する項目が含まれます。 SKILL.md の冒頭には、確認質問として 4 個の事前質問が配置されています。事前質問の内容は、認証主体、実行環境、ターゲット、クライアントライブラリ使用の有無です。これにより、AI エージェントツールが状況に応じて適切な認証方式を選択できる構造を持ちます。 さらに、3 つの実用的な Examples も SKILL.md に含まれています。Human-to-Service（ローカル Python）、Service-to-Service（Cloud Run から Cloud SQL）、Custom App（OIDC ID Token）の 3 例であり、AI エージェントツールが具体的な実装パターンを参照しながらコードを生成できる作りとなっています。 主なユースケース ローカル開発での ADC（Application Default Credentials）のセットアップと、クライアントライブラリから Google Cloud にアクセスするコードの記述 Service Account Impersonation を使った、Service Account Key をダウンロードしないセキュアなローカル開発 Compute Engine、Cloud Run、Cloud Functions などのリソースへのカスタム Service Account のアタッチによる、サービス間認証の構成 GKE での Workload Identity Federation for GKE を使った、Kubernetes Pod から Google Cloud API へのキーレスアクセス AWS、Azure、オンプレなど外部クラウドのワークロードからの、Workload Identity Federation を使ったキーレスアクセスの構成 IAP や Identity Platform を使った、エンドユーザー（従業員や顧客）向け認証の Web アプリケーションへの組み込み IAM ロール（事前定義ロールを優先し、必要なら Custom ロール）の設計と付与 OIDC ID Token を使った、別の Cloud Run サービスへのプライベート呼び出しの実装 google-cloud-networking-observability 概要 google-cloud-networking-observability は、Google Cloud のネットワーク問題を、ログ・メトリクス・診断ツールを使って調査・診断するスキルです。 このスキルは、SKILL.md の冒頭に結果優先という基本方針を掲げています。これは、最小限のクエリで直接答えを出し、0 件や null の結果も結論として受け入れて即座に終了するよう、AI エージェントツールに指示するものです。これにより、冗長な調査を抑制する設計となっています。 さらに重要な制約事項として、多数の禁止事項を明示し、効率的な調査を強制している点が特徴です。具体的には、探索的クエリは 2 個までとすること、Tool A と Tool B の結果差を深掘りする「不一致ループ」の禁止、補助スクリプト（ .sh 、 .py ）の作成禁止、Monitoring API による BigQuery 結果のダブルチェック禁止などが挙げられます。 データソースとしては、Cloud Monitoring MCP、BigQuery MCP、Cloud Logging MCP の使用を最優先としています。特にボリューム分析や Top-N タスクでは、BigQuery 連携データセット（ _AllLogs ）を一次データソースに指定しています。このように、Agent Skills と MCP の組み合わせを前提とした調査フローを定義しています。 主なユースケース 「接続できない」「通信が遅い」「パケットが落ちる」などのネットワーク問題の、VPC Flow Logs、Firewall Logs、Cloud NAT Logs、Networking Metrics、Connectivity Tests を使った原因特定 VPC Flow Logs を BigQuery 連携データセットでアグリゲーションし、トラフィック量、傾向、top talkers の分析 Firewall Logs からの DENY/ALLOW イベントの抽出による、特定の通信がブロックされている原因のファイアウォールルールの特定 Cloud NAT Logs による NAT 翻訳の監査や、ポート枯渇のトラブルシュート Cloud Firewall Plus や Cloud IDS の Threat Logs からの、SQL インジェクションやマルウェアなどの悪意あるトラフィックパターンの検知 Networking Metrics によるスループット、RTT（レイテンシ）、パケットロスの時系列トレンドや過去の性能の分析 Connectivity Tests による、エンドポイント間のファイアウォールやルーティングの設定ミスの静的解析での特定 福井 達也 (記事一覧) カスタマーサクセス課 エンジニア 2024年2月 G-gen JOIN 元はアプリケーションエンジニア(インフラはAWS)として、PM/PL・上流工程を担当。G-genのGoogle Cloudへの熱量、Google Cloudの魅力を味わいながら日々精進