AWS DevOps Agent の「スキル」を使いこなそう
2026-09-02 | Author : 山口 正徳 (AWS Community Hero)
はじめに
AWS Community Hero の山口です。2026 年 3 月に GA となった AWS DevOps Agent は、Amazon CloudWatch アラームや手動指示をきっかけに、メトリクス・ログ・変更履歴を横断して障害調査を自律的に実行してくれるフロンティアエージェントです。障害調査を任せられるというだけでも十分に魅力的ですが、AWS DevOps Agentをより効果的に利用する「スキル」という仕組みをご存知でしょうか ?「 スキル」を使うことで自分たちの環境の知識や調査の進め方を Markdown で教え込むことができます。
そこで本記事では、次の 3 つの問いについて、実際に手を動かしながら検証しました。
- スキルを与えることで、調査の速度や品質はどの程度向上するのか ?
- 調査結果の振り返りやスキルの作成を、エージェント自身に任せることはできるのか ?
- スキルを継続的に育てるための運用 (フィードバックループ) は、どのように設計すべきか ?
なお、本検証では各条件につき調査を1回ずつ実施しています。エージェントの応答にはばらつきがあるため、本記事で紹介する数値はあくまで参考値としてご覧ください。
それでも、実際に検証したからこそ見えてきた挙動やつまずきが数多くありました。本記事が、これから AWS DevOps Agent を試す方にとっての道しるべとなれば幸いです。
ご注意
本記事で紹介する AWS サービスを起動する際には、料金がかかります。builders.flash メールメンバー特典の、クラウドレシピ向けクレジットコードプレゼントの入手をお勧めします。
builders.flash メールメンバー登録
builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。
AWS DevOps Agent とスキルの基礎
はじめに、AWS DevOps Agent を構成するコンポーネントを整理します。
- エージェントスペース : AWS DevOps Agent の管理単位です。調査対象となる AWS アカウントを関連付けることで、エージェントが AWS リソースを自動的に検出し、トポロジー (構成マップ) を学習します。
- オペレーター Web アプリ : 調査の実行、レポートの閲覧、チャット、スキルの管理を行うための専用 UI です。
そして、本記事の主役となるのが「スキル (Skills)」です。
スキルは、エージェントへの指示や関連リソースをパッケージ化するオープン標準「Agent Skills 仕様」のサブセットとして実装された、自己完結型のディレクトリです。AWS DevOps Agent では、Markdown、PDF、画像、データファイルなどのドキュメントをスキルとして利用できます。
スキルには、ユーザーが作成する 「カスタムスキル (Custom Skills) 」と、エージェントが調査結果をもとに自動生成する 「マネージドスキル (Learned Skills) 」の 2 種類があります。それぞれについて詳しく見ていきましょう。
カスタムスキル — 人が教え込むナレッジ
カスタムスキルの実体は、SKILL.md を必須ファイルとするディレクトリです。
my-skill/
├── SKILL.md # 必須: スキルの指示本文
├── references/ # 任意: 参照ドキュメント
└── assets/ # 任意: 画像・図・データファイルSKILL.md に記述する内容
SKILL.md の先頭には --- で囲んだフロントマター (メタデータブロック) を書きます。ここが最重要ポイントです。
---
name: rds-performance-investigation
description: RDS のパフォーマンス問題 (接続枯渇、スロークエリ、レプリケーション遅延、ストレージ容量) の調査手順。データベースのレイテンシ、接続エラー、読み書き性能の劣化を調査するときにこのスキルを使用する。
---
# 調査手順
(Markdown で手順や判断基準を記述) - name : スキルの一意な識別子。小文字・数字・ハイフンのみ、最大 64 文字 (ハイフンで開始・終了は不可)
- description : エージェントがスキルを発動するかどうかを判断する材料です。曖昧だったり空だったりすると、本文がどれだけ良くてもスキル自体がスキップされる場合がある、と AWS DevOps Agent ユーザーガイド に明記されています。「どのサービスの・どんな症状・どんなエラーのときに使うか」をエージェント視点で具体的に書くのがコツです (推奨 100 文字以上・最大 1,024 文字)
ターゲティング機能
スキルには、適用するエージェントタイプを指定するターゲティング機能も用意されています。対象は Generic (全エージェント共通) のほか、On-demand、Incident Triage、Incident RCA、Incident Mitigation、Evaluation から選択できます。
例えば、「メンテナンス時間帯の低優先度アラームは調査せずスキップする」というスキルを Incident Triage 専用に設定するといった使い方があります。
このようにエージェントタイプごとにスキルを使い分けることで、不要なコンテキストの消費を抑えつつ、エージェントの役割に応じた調査へと焦点を絞ることができます。
スキルの作成方法
- UIフォームで作成 : Operator Webアプリの Knowledge → Skills → Add skill → Create skill から作成します。名前・説明・指示を入力すると、フロントマター付きの SKILL.md が自動生成されます。手軽に作成できるため、単一ファイル構成のシンプルなスキルに適しています。
- ZIPファイルをアップロード : references/ や assets/ を含む、本格的なディレクトリ構成のスキルを登録する方法です。フロントマターは自分で記述する必要があります。アップロード可能なサイズは最大 6MB で、現時点では scripts/ ディレクトリ (実行コードを含むスキル) はサポートされておらず、アップロードできません。
- GitHubリポジトリからインポート : GitHub リポジトリ内のスキルディレクトリを指定して取り込めます。スキルを Git でバージョン管理しながら運用したいチームに適した方法です。
マネージドスキル (Learned Skills) — エージェントが自分で学ぶナレッジ
もうひとつの種類が、AWS DevOps Agent 自身が エージェントスペースのデータから自動生成するマネージドスキルです。本記事の執筆時点で 4 種類が用意されています。
|
スキル
|
内容
|
|---|---|
|
Agent Space Understanding
|
接続された AWS アカウント、GitHub リポジトリ、テレメトリデータを分析し、環境全体の構 成 (アーキテクチャ、リクエストパス、リソースとコードの対応関係など) を文書化します。この情報は、Topology ページの表示やサマリーレポートの生成に活用されます。 |
|
Understanding Code Dependencies
|
サービス間やパッケージ間の依存関係を可視化したマップです。変更によって影響を受ける範囲 (ブラストラディウス) の評価に活用されます。 |
|
Understanding Pipeline Topology
|
CI/CD パイプラインの構成や、環境間の昇格フローを文書化します。本番環境と非本番環境を区別し、適切な調査や分析を行うための基盤となります。 |
|
Tool Use Best Practices
|
過去の調査で蓄積されたツール利用実績をもとに、有効だったクエリパターンや、よくある失敗とその回避策、効率的な出力の絞り込み方法を抽出します。これにより、調査時の試行錯誤を減らし、より効率的に問題を調査できるようになります。 |
マネージドスキルの仕組み
更新の仕組みも興味深いポイントです。例えば、Agent Space Understanding は構成変更時に加え、アクティブなエージェントスペースでは 3 日ごとに自動更新されます。一方、6 日間調査が行われないと自動更新は停止します。
また、Tool Use Best Practices は、調査実績が一定数蓄積されると自動的に生成・更新されます。つまり AWS DevOps Agent は、使い続けることで環境への理解を深めるとともに、効果的な調査方法も継続的に蓄積していく設計になっています。
マネージドスキルはデフォルトで有効ですが、Knowledge 画面からいつでも非アクティブ化できます。非アクティブ化しても削除はされないため、必要になった場合は再度有効化できます。
スキルの詳しい記述方法 (完全なサンプルスキル、ZIPファイルの要件、GitHubリポジトリからのインポート手順など) については、AWS DevOps Agent ユーザーガイド の DevOps エージェントスキル および 学習したスキル に詳しくまとめられています。本記事では紹介しきれない内容も多いため、詳細はぜひ公式ドキュメントをご参照ください。
検証環境
検証対象として、Amazon API Gateway (HTTP API) → AWS Lambda (Python) → Amazon DynamoDB で構成されたシンプルなサーバーレス API を、AWS CloudFormation を用いて構築しました。監視には、API Gateway の 5xx エラー、Lambda エラー、DynamoDB のスロットリングを検知する 3 つの CloudWatch アラームを設定しています。
2 つの障害注入シナリオ
また、障害をいつでも再現できるよう、次の 2 つの障害注入シナリオを用意しました。
シナリオ A (コード起因の 5xx エラー)
Lambda の環境変数 FAILURE_MODE=error を設定すると、DynamoDB のレスポンス処理で意図的に KeyError が発生し、すべてのリクエストが HTTP 500 エラーを返します。
シナリオ B (キャパシティ不足によるスロットリング)
DynamoDB テーブルをプロビジョンドモード (1 RCU) に設定し、並列で読み取り負荷をかけることでスロットリングを発生させます。
環境のトポロジーを学習
エージェントスペースを作成して AWS アカウントを関連付けると、AWS DevOps Agent は自動的にリソースを検出し、環境のトポロジーを学習します。トポロジーの学習が完了したかどうかは、チャットで「認識しているリソースと依存関係を教えて」と質問するのが確実です。
今回の検証環境では、13 個の AWS リソースをすべて正しく認識し、API Gateway → Lambda → DynamoDB の依存関係についても正確に把握できていることを確認しています。
検証 1 : カスタムスキルなし vs カスタムスキルあり — スキルを通じて情報を与えることで、調査の速度や品質はどの程度向上するのか ?
スキルに何を書くべきか ― 実際に登録したスキルを公開
今回、カスタムスキルは「環境の前提知識と調査の進め方を書く」ことを方針としました。
本検証では、障害シナリオにより意図的に障害を発生させています。そのため、環境変数の存在など「正解」をスキルに記載してしまうと、スキルの効果を正しく評価できません。そこで、実際の運用チームが整備するランブック (手順書) と同等の粒度を意識し、調査のヒントや手順を中心に記述しています。
まず重要なのが、フロントマターの description です。すでに紹介したとおり、この項目はエージェントがスキルを適用するかどうかを判断する材料として利用されます。さらにスキル登録時のフォームには「説明文は 100 文字以上を推奨。具体的に記述するほど適用判断の精度が向上する」と案内されています。そのため、本文の要約を書くのではなく、どのような症状が発生したときに利用するのか、どのアラームを対象とするのか、どの AWS リソースを調査対象とするのかといった、スキルの発動条件を具体的に記述しています。
フロントマターの description
---
name: dvoa-verify-investigation
description: dvoa-verify アプリケーション (API Gateway + Lambda + DynamoDB) の 障害調査を行う際の環境前提知識・参照すべきメトリクス・調査手順・レポート要件。API 5xx エラー、レスポンス遅延、Lambda エラー、DynamoDB スロットリングの各インシデント、およびアラーム dvoa-verify-api-5xx / dvoa-verify-lambda-errors / dvoa-verify-ddb-throttl の発火を起点とする調査で使用する。dvoa-verify 関連リソース (dvoa-verify-api、dvoa-verify-item-api、dvoa-verify-items) が対象の調査では常にこのスキルを適用する。
---スキル本文
本文は、「前提知識」「参照メトリクス」「調査手順」「レポート要件」の4つのセクションで構成しています。以下に、実際に登録したスキルの全文を掲載します。
# dvoa-verify 環境の障害調査ガイド
## 環境の前提知識
- **全リソースは ap-northeast-1 (東京) リージョンにのみ存在する**。メトリクス取得・リソース参照・CloudTrail 検索は必ず ap-northeast-1 に対して行うこと。他リージョン (特に us-east-1) を照会しない。リソースが「存在しない」ように見えた場合は、環境の不在と結論づける前に**照会先リージョンの誤りを最初に疑う**
- 対象は CloudFormation スタック `dvoa-verify` で管理されるサーバーレス API:API Gateway HTTP API `dvoa-verify-api` (ApiId: 3jria4mjmd) → Lambda `dvoa-verify-item-api` (Python) → DynamoDB `dvoa-verify-items`。ルートは GET /items と POST /items の 2 本のみ
- 監視は CloudWatch アラーム 3 本: `dvoa-verify-api-5xx` (5xx≥5 回 / 5 分) 、 `dvoa-verify-lambda-errors` (エラー ≥ 3 回 / 5 分) 、`dvoa-verify-ddb-throttle` (スロットル ≥ 5 回 / 5 分)
- **API Gateway のアクセスログは未設定**。リクエスト送信元の特定はできないため、送信元調査に時間をかけない。この環境では検証・訓練目的の負荷テストが行われることがあり、急激なトラフィック増はテスト起因の可能性を優先的に考えてよい
- DynamoDB テーブルは**低容量のプロビジョンドモード**で運用されており、読み取り負荷への余裕が小さい。Lambda の読み取り実装は Scan ベース
## 参照すべきデータソースとメトリクス
| レイヤー | ネームスペース / 場所 | メトリクス・データ | ディメンション |
|---------|---------------------|-------------------|---------------|
| API Gateway | `AWS/ApiGateway` | `5xx`, `4xx`, `Count`, `Latency`, `IntegrationLatency` | `ApiId=3jria4mjmd` |
| Lambda | `AWS/Lambda` | `Errors`, `Invocations`, `Duration`, `Throttles`, `ConcurrentExecutions` | `FunctionName=dvoa-verify-item-api` |
| DynamoDB | `AWS/DynamoDB` | `ReadThrottleEvents`, `WriteThrottleEvents`, `ConsumedReadCapacityUnits`, `ProvisionedReadCapacityUnits`, `SuccessfulRequestLatency` | `TableName=dvoa-verify-items` |
| Lambda ログ | CloudWatch Logs | ロググループ `/aws/lambda/dvoa-verify-item-api` | — |
| 変更履歴 | CloudTrail | `UpdateFunctionConfiguration20150331v2` (Lambda 設定変更) 、`UpdateTable` (DDB 設定変更) 、CloudFormation スタックイベント | — |
## 調査手順 (この順序で実施する)
1. **直近の変更をまず確認する**: CloudTrail で Lambda 関数設定 (環境変数) ・テーブル設定・スタック更新のイベントを検索し、症状開始時刻との相関を最初に確認する。この環境の障害の多くは設定変更・デプロイ起因である
2. **実発生時刻はメトリクスの生データで特定する**: アラーム発火時刻は5分の評価期間を含むため、実際の開始時刻はメトリクスのデータポイントから分単位で特定する
3. **Lambda エラーは CloudWatch Logs でスタックトレースの行番号まで特定する**
4. **レイテンシ・スロットリング系は DynamoDB の Consumed vs Provisioned を突き合わせる**:消費 RCU、ReadThrottleEvents、Lambda Duration、API IntegrationLatency の因果連鎖で説明する作成したカスタムスキルの画面
作成済みのカスタムスキルの画面キャプチャはこちらです。
実測結果
同一障害シナリオ・同一プロンプトで、カスタムスキルなし/ありの調査を実行した結果です (各条件 1 回の実測) 。
|
シナリオ
|
スキルなし
|
スキルあり
|
差分
|
|---|---|---|---|
|
A : 5xx (コード起因)
|
15 分 15 秒 |
11 分 6 秒 |
-27.8 % |
|
B : スロットリング
|
9 分 24 秒 |
14 分 53 秒 |
+59 % |
結果の比較
スキルは、調査開始からわずか 11 ~ 16 秒でタイムラインに「スキルを読み込み」と表示され、期待どおり確実に適用されていることを確認できました。
シナリオ Aでは、スキルを利用することで約 28 % の時間短縮を確認できました。一方、シナリオ B では、調査時間がかえって長くなる結果となりました。
レポートを比較すると、スキルを適用したケースでは、Auto Scaling の導入提案や Service Quotas の事前確認まで踏み込んだ、より深い調査が行われていました。そのため、追加の調査に時間を要したと考えられます。
この結果から、「スキルを使えば必ず調査が速くなる」とは言えません。 スキルの効果は、「速度」だけでなく、「調査品質 (深さ) 」や「調査の方向性を適切に導けるか」という 3 つの観点で評価する必要があります。もし速度を最優先するのであれば、スキルに調査対象の範囲や、どこまで深く調査するかまで明示しておくと、より効果的だと考えられます。
質的な変化 : スキルは運用ポリシーをエージェントへ伝える手段になる
数値以上に興味深かったのは、調査の進め方とエージェントが提案する内容に変化が見られたことです。
カスタムスキルを適用した調査では、並列に起動されるサブエージェントの役割 (直近の変更確認、メトリクス分析、ログ調査、アラーム確認) が、スキルに記述した調査手順とほぼ1対1で対応していました。つまり、スキルに記述した調査プロセスが、そのままエージェントの行動に反映されていたことが分かります。
さらに、提案される緩和策にも違いがありました。スキルを適用しない場合は「Lambda の環境変数を直接変更して復旧する」という提案だったのに対し、スキルを適用した場合は「CloudFormationスタックを更新してドリフトを解消する」という提案へ変化しました。
この違いを生み出したのは、スキルに記載した「手動変更はドリフトの原因となる」という一文です。わずか一つの運用ルールを記述するだけで、エージェントの推奨アクションを組織の運用ポリシーに沿ったものへと導けることが確認できました。
検証中に発生したトラブル : 調査が us-east-1 に迷い込む
検証を行っている際、シナリオ B (スキルあり) の初回実行では、RCA (Root Cause Analysis : 根本原因分析) を特定できないまま、約 4 分で調査が終了するという失敗が発生しました。
調査のタイムラインを確認すると、DynamoDB を担当したサブエージェントは、東京リージョン (ap-northeast-1) の正しい情報を取得できており、スロットリング 3,180 回、消費 RCU が想定の約 490 倍という異常を正しく検出していました。
一方で、API Gatewayと Lambda を担当したサブエージェントはバージニア北部リージョン (us-east-1) を参照し、「対象の環境が存在しない」と判断していました。リードエージェントは、この否定的な結果を優先して他のサブエージェントを途中で停止し、「No root causes identified」 と結論付けて調査を終了してしまいました。
原因は単純で、AWS DevOps Agent エージェントスペース、検証環境ともに東京リージョンに存在しているため、エージェントは当たり前に東京リージョンを対象に調査を行うだろうという思い込みのもと、スキルにもプロンプトにもリージョンを明記していなかったことです。
そこでスキルに、「すべてのリソースは ap-northeast-1 に存在する。リソースが存在しない場合は、まずリージョンの指定誤りを疑うこと」という前提条件を追記して再実行したところ、この問題は再発しませんでした。
この検証から得られた教訓は、リージョンや AWS アカウントといった「当たり前の前提」こそ、スキルに明記すべきということです。
エージェントは、前提条件が不足していてもエラーとして教えてくれるわけではありません。前提が欠けたまま静かに調査を進め、誤った方向へ到達してしまうことがあります。だからこそ、人間にとって自明な情報ほど、スキルには明示的に記述しておくことが重要です。
検証 2 : エージェント自身に振り返らせてスキルを作らせる
検証 1 では、スキルは人間 (筆者) が作成しました。では、ここまでに実施した 5 回の調査 (失敗 1 回を含む) をエージェント自身に振り返らせ、そこからスキルを作成させたらどうなるのでしょうか。
入力した指示
チャットには、次の指示を入力しました。
これまでに完了した調査 (run1〜run5) をすべて振り返ってください。その上で、今後の dvoa-verify 環境の調査をより速く・正確にするためのスキルを作成し、登録してください。
手順:
①各調査について、うまくいった点と、つまずいた点・非効率だった点を具体的に整理する (例: 実在しないリージョンへの照会、調査の途中放棄、時刻解釈のずれ など) 。
②そこから得られる教訓を、個別事象ではなく今後も使える一般的な知見に昇華する。
③それらを新しいスキルとして作成・登録する。既存の dvoa-verify-investigation スキルに書かれている内容との重複は避け、振り返りから得られた知見のみで構成してください。生成されたスキル
結果は約 5 分で、7 つの知見から構成される新しいスキルが生成・登録されました。
生成されたスキルには、「リージョンの誤認は調査失敗の最大リスク」といった、自身の失敗を一般化した知見や、boto3 の自動リトライパターンに関する解説など、実践的な内容が並んでいました。
ベースライン期間の汚染
中でも特に印象的だったのが、「ベースライン期間の汚染に注意する」という知見です。同じ日に障害注入を繰り返していたため、後続の調査ではベースライン分析に前回検証時の情報が混入することがありました。エージェントは、調査結果を振り返る中でこの問題を正確に指摘し、再利用可能な知見としてスキルにまとめていました。
今回は、プロンプトで既存スキルとの重複を避けるよう指示したため、人手で作成したスキルは「環境知識と調査手順 (フィードフォワード）」、と、エージェントが自己生成したスキルは「失敗や非効率を避けるための知見 (フィードバック）」を担っています。
高い精度の調査レポート
両方のスキルを有効化した状態で追加の調査を実施したところ、2 つのスキルが同時に読み込まれ、変更の実行者や呼び出し経路まで特定できる、これまでで最も精度の高いレポートを得ることができました。
システム運用では日々さまざまな調査が発生しますが、その一つひとつを人手で振り返ることは、振り返りに要する工数や他業務との兼ね合いを考えると、現実的ではありません。
AWS DevOps Agent を活用すれば、調査結果の振り返り (ポストモーテム) をエージェントに任せ、その結果をスキルとして蓄積・改善していくことができます。これにより、継続的に調査品質を向上させるオペレーションサイクルを構築できる可能性があります。
スキルを育てるオペレーションサイクル
スキルは一度作って終わりではなく、育てる仕組みが本体です。検証を通じて確認できた運用の選択肢を整理します。
スキル作成ルートの使い分け:
|
ルート
|
向いている場面
|
|---|---|
|
フォーム (コンソール)
|
人がレビューした内容をもとにスキルを作成・登録します。UI には説明文の推奨要件も表示されるため、適切なスキルを作成しやすくなっています。 |
|
チャット指示
|
調査結果の振り返りからスキルの作成までをエージェントに任せられます (約 5 分）。有効化前には確認が入るため、ガバナンスを維持しながら運用できます。 |
|
アップロード / Git 連携
|
複数チームや複数の Agent Space でスキルを共有・標準化し、バージョン管理しながら運用することが想定されます。 |
フィードバックの 3 経路:
- 人手によるスキルの改善 : 調査結果をもとに人間が原因を分析し、スキルへ知見を追記したうえで再調査を行います。今回発生したリージョン指定の問題も、この方法でスキルに1行追記することで改善できました。
- エージェントによる振り返り : チャットで指示するだけで、過去の調査結果を振り返り、新たな知見をスキルとして蓄積できます。人間が見落としていた課題まで発見できたことから、週次などの定期的な振り返りに活用する価値があると感じました。
- 調査結果へのフィードバック (Human Labeling) : 調査レポートには、👍/👎による評価、「ステアリングが必要でした」の申告、自由記述コメントを送信する機能が用意されています。フィードバックを送信すると、レポートには「✓ 正しい」というラベルが永続的に表示されます。また、調査結果と緩和計画 (Mitigation Plan) をそれぞれ独立して評価できる2層構造になっている点も特徴です。
まとめ
最後に、本検証を通じて得られた知見をまとめます。
- スキルの最も大きな効果は、調査の方向性を導けることです。
スキルによって調査の進め方や探索順序が変わり、エージェントが提案する緩和策も、組織の運用ポリシー (IaC を前提とした運用など) に沿った内容へと変化しました。一方で、調査時間については一律に短縮されるわけではありません。約 28 % 短縮したケースもあれば、より深い分析を行った結果、約 59 % 長くなったケースもありました。 - スキルの前提条件が不足すると、調査の失敗につながることがあります。
今回はリージョン情報の記載漏れが原因で、誤ったリージョンを調査してしまう事象が発生しました。このように、人間にとっては「当たり前」と思える前提こそ、スキルには明示的に記載することが重要です。運用では、失敗 → スキルの改善 → 再調査というサイクルを継続することが前提になります。 - 調査結果の振り返りからスキルを作成する作業は、エージェント自身に任せられます。
今回は約 5 分で新しいスキルを生成し、人間が見落としていた検証設計上の課題まで発見できました。今後は、人間が一からスキルを書くのではなく、エージェントが生成したスキルをレビューし、必要に応じて改善する役割へとシフトしていく可能性があります。
AWS DevOps Agent のスキルは、記述した内容が調査に素直に反映される、非常に手応えのある仕組みでした。
まずは、自分たちのシステムに関する前提知識や調査で参照すべきメトリクスを 1 つのスキルとしてまとめ、登録してみることをおすすめします。調査を 1 回実行するだけでも、その効果を実感できるはずです。
筆者プロフィール
山口 正徳
フォージビジョン株式会社 / AWS Community Hero
大手 SIer 、フリーランスを経て、クラウドインテグレーションを手掛けるフォージビジョン株式会社にインフラエンジニアとして入社。現在、同社で AWS 事業責任者を務める。
JAWS DAYS 2021 実行委員長、AWS BuilderCards 日本語化プロジェクト発起人、AWS re:Inforce 2024 スピーカーなどコミュニティ活動を通じて AWS Samurai、AWS APAC Community Award 2022、APJ Community Leaders Award 2024 を受賞。全世界共通の認定プログラムである AWS 公式の「AWS Ambassador」のひとりでもある。
