本記事は 2026 年 11 月 9 日 に公開された「 Amazon Athena introduces system tables for query execution observability 」を翻訳したものです。 多くの方が Amazon Athena でデータレイク全体に SQL クエリを実行し、対話型の分析から定期実行のレポートパイプラインまで、幅広い処理に活用しています。ただし、ワークロードの状況を十分に把握できていないことも少なくありません。ユーザー、ワークグループ、クエリが増えて Athena の利用が広がるにつれ、どのクエリのコストが高いのか、誰が実行したのか、パフォーマンスが変化していないか、コストをどう配分するのかを知る必要が出てきます。 Athena でシステムテーブルが使えるようになりました。第一弾として本日提供を開始する query_executions は、利用状況のデータを自動で記録し、オブザーバビリティ、利用状況の分析、監査といったユースケースに使えます。システムテーブルを有効にすると、すべてのワークグループで、クエリの完了から数分以内に利用状況のデータを参照できるようになります。Athena は利用状況のデータを、 Amazon Simple Storage Service (Amazon S3) の機能である Amazon S3 Tables に Apache Iceberg テーブルとして保存します。保持期間は設定で変更できます。スキーマの定義、パーティショニング、コンパクション、スナップショットのメンテナンスを含むテーブルの管理は AWS が担うので、Athena から直接クエリするだけで済みます。テーブルを管理する運用の負担はかかりません。 Athena の利用状況のデータは、 GetQueryExecution などの API、 Amazon CloudWatch のメトリクス、 AWS CloudTrail のログから取得できます。今回のリリースで、利用状況のデータを S3 テーブルとしても使えるようになりました。独自のパイプラインを構築・保守しなくても、直接検索、フィルタリング、集計、結合ができます。プラットフォームチームは、独自の抽出、変換、ロード (ETL) パイプラインを用意しなくても、ワークグループ別、ユーザー別、テーブル別にスキャンしたデータ量を示すコスト配分のダッシュボードを構築できます。さらに、 AWS Agent Toolkit には、システムテーブルをクエリして利用パターンや最適化の提案を導き出すスキルが用意されています。Athena はデータをオープンな Apache Iceberg 形式で保存するため、 DuckDB 、 Amazon Redshift などの Iceberg 互換エンジンからもクエリできます。 本記事では、システムテーブルとは何か、どう始めるのか、そして何より、システムテーブルで何ができるのかを紹介します。 課題: 規模が拡大した Athena ワークロードの把握 これまで、規模の大きなクエリワークロードを把握するには、クエリそのものを実行するよりも多くの手間がかかっていました。よくある次のような疑問を考えてみてください。 コストの配分: 今月、最もコストの高いクエリを実行したのはどのチームか？ パフォーマンス分析: 遅くなっているクエリや、普段より多くのデータをスキャンしているクエリはないか？ 監査とコンプライアンス: 前四半期に特定のテーブルに対してクエリを実行したのは誰か？ 運用状況の把握: 本番ワークロードのエラー率はどのくらいか？ 利用パターン: 日ごとのクエリ数はどのくらいで、ピークの時間帯はいつか？ 以前は、どの疑問に答えるにも、Athena API、Amazon CloudWatch のメトリクス、AWS CloudTrail のログを自分でつなぎ合わせるか、クエリ履歴のスナップショットを取ってクエリできる形式で保存する独自のパイプラインを構築する必要がありました。つまり、分析パイプラインを分析するために、分析パイプラインを構築していたわけです。システムテーブルは、差別化につながらない重労働をなくします。 システムテーブルとは 最初のシステムテーブルである query_executions は、すべてのワークグループで完了した (成功したか、エラーで終了した) クエリ 1 件ごとに 1 行を記録します。記録する内容は次のとおりです。 クエリの識別情報: クエリ実行 ID、クエリ文字列、送信時刻。 コンテキスト: ワークグループ、カタログ、データベース、テーブル。 ユーザーアイデンティティ: クエリを送信したユーザー。 パフォーマンス: 合計実行時間、計画時間、キュー時間など。 リソースの消費量: スキャンしたバイト数、データ処理ユニット (DPU) 数。 結果: 実行状態 (成功、失敗、キャンセル)、エラーの詳細情報。 クエリに関する情報がすべて 1 か所にそろうと、Athena ワークロードの捉え方が変わります。コンソールや API でクエリを 1 件ずつ調べるのではなく、クエリ履歴全体を対象に問いを立てられます。ほかの分析用データセットと同じように、集計、フィルタリング、傾向の分析、結合ができます。ダッシュボードを構築したり、定期的なレポートを設定したり、状況を把握したいときにアドホッククエリを実行したりできます。 始め方 システムテーブルは、数ステップで有効にできます。 Athena コンソール を開きます。 左側のナビゲーションペインで、 Administration の下にある System tables を選択します。 Configure を選択し、 Enable system tables for all your current and future resources をオンにします。 (オプション) Data encryption を展開し、 AWS Key Management Service (AWS KMS) のキーを選択します。キーを選択しない場合、Athena は Amazon S3 マネージドキー (SSE-S3) を使います。 Save を選択します。Athena はアカウント内に、サービスが管理する Amazon S3 のテーブルバケットをプロビジョニングし、すべてのワークグループでクエリ実行の記録を始めます。 有効にすると、Athena は新しいクエリの実行を自動で記録します。システムテーブルには、ほかの Athena テーブルと同じように、コンソールのクエリエディタ、API や SDK、 JDBC ドライバーや ODBC ドライバーからアクセスできます。 AI エージェントでシステムテーブルからインサイトを得る 自然言語で質問して、システムテーブルを探索することもできます。システムテーブルは AWS Glue Data Catalog の標準的なテーブルなので、 Kiro や Claude Code など、 Model Context Protocol (MCP) に対応した AI エージェントから参照できます。接続先は AWS MCP Server です。AWS MCP Server はマネージド型の MCP サーバーで、既存の AWS Identity and Access Management (IAM) の認証情報を使って、エージェントから AWS にアクセスできます。 安定した結果を得るには、AWS が AWS Agent Toolkit で公開している、Athena システムテーブル向けのオープンソースの Agent Skill を使ってください。スキルは、エージェントが機能をうまく使えるように教える指示と検証済みの例をまとめたパッケージで、バージョン管理されています。Athena システムテーブル向けのスキルには、システムテーブルのスキーマとクエリ例のライブラリが含まれています。パーティション列で絞り込む、テーブルを読み取り専用として扱うといった、クエリを正しく、コスト効率よく保つための決まりごとも組み込まれています。スキルを読み込んだエージェントは、正しい列名で、パーティションプルーニングによってスキャン量を抑えた SQL を書きます。自由形式のプロンプトのように、結果が予測しにくくなることはありません。スキルはオープンソースで、今後追加される新しいシステムテーブルにも対応するよう設計されています。 エージェントは質問を SQL に変換して Athena で実行し、答えを返します。会話を続けて結果を絞り込んだり、傾向をグラフにしたりもできます。 コストの配分: 「先月スキャンしたデータ量が最も多かったワークグループはどれですか？先々月と比べてどうですか？」 監査とコンプライアンス: 「前四半期に customer_orders テーブルにアクセスしたクエリをすべて、実行したユーザーとあわせて一覧にしてください。」 運用状況の把握: 「ユーザーの構文エラーを除くと、今週の本番ワークグループのエラー率はどのくらいですか？」 エージェントが使う IAM の認証情報は、最小権限に絞ってください。Athena、AWS Glue、システムテーブルへの読み取り専用のアクセス権があれば十分です。質問するだけなら書き込み権限は必要ありません。AWS MCP Server は IAM ベースのアクセス制御を使い、すべての API 呼び出しを CloudTrail に記録するので、エージェントがユーザーに代わって実行した操作の監査証跡がすべて残ります。 システムテーブルでできること 以降のセクションでは、特によくあるユースケースを、それぞれの代表的なクエリとあわせて紹介します。ここで紹介するクエリは出発点です。すぐに実行できるクエリをさらに多く知りたい場合は、 Athena システムテーブル向けの Agent Skill のクエリ例を参照するか、スキルを使ってエージェントにクエリを書かせてください。 利用パターン: Athena の使われ方を把握する システムテーブルを使うと、組織全体で Athena がどう使われているかの全体像をつかめます。利用パターンは多くのチームが最初に調べる項目で、ワークロードを理解するうえでの基準になります。 日ごとのクエリ数 クエリ数の推移を追跡します (‘day’ を ‘hour’ に置き換えると、ピークの時間帯がわかります)。 SELECT DATE_TRUNC('day', submission_date_time) AS day, COUNT(*) AS query_count FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '30' DAY GROUP BY 1 ORDER BY 1 ワークグループ別の利用状況の推移 SELECT DATE_TRUNC('week', submission_date_time) AS week, work_group_name, COUNT(*) AS query_count, COUNT(DISTINCT principal_arn) AS distinct_users FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '90' DAY GROUP BY 1, 2 ORDER BY 1, 2 クエリサイズの分布 SELECT CASE WHEN data_scanned_size = 0 THEN '0 bytes' WHEN data_scanned_size < 1048576 THEN '<1 MB' WHEN data_scanned_size < 10485760 THEN '1-10 MB' WHEN data_scanned_size < 104857600 THEN '10-100 MB' WHEN data_scanned_size < 1073741824 THEN '100 MB-1 GB' WHEN data_scanned_size < 10737418240 THEN '1-10 GB' WHEN data_scanned_size < 107374182400 THEN '10-100 GB' ELSE '>100 GB' END AS scan_bucket, COUNT(*) AS query_count, ROUND(COUNT(*) * 100.0 / SUM(COUNT(*)) OVER (), 2) AS percent_of_query_count FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '30' DAY AND state_enum = 'SUCCEEDED' GROUP BY 1 ORDER BY MIN(data_scanned_size) コストの配分: チームやユーザーごとに費用を割り当てる スキャンしたデータ量に応じて課金される Athena の料金モデルでは、スキャンしたバイト数をユーザーやワークグループに割り当てれば、そのままコストの配分になります。システムテーブルを使えば、独自の計測パイプラインを立ち上げなくても、チャージバックやショーバックのレポートを作成できます。コストを見積もるには、リージョンごとの 1 TB あたりの料金 を確認するか、 AWS Price List API で最新の料金をプログラムからダウンロードしてください。 請求期間中にユーザーがスキャンしたデータ量の合計 SELECT work_group_name, region_name, ROUND(SUM(data_scanned_size) / POWER(1024.0, 4), 3) AS total_tb_scanned, COUNT(*) AS query_count, ROUND(SUM(data_scanned_size) * 100.0 / SUM(SUM(data_scanned_size)) OVER (), 3) AS percent_of_total_tb_scanned FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '30' DAY AND state_enum = 'SUCCEEDED' GROUP BY 1, 2 ORDER BY 1, 2 work_group_name を principal_arn に変えると、同じレポートをユーザー別に分けられます。 パフォーマンス分析: パフォーマンスの問題を見つけて解決する パフォーマンスの傾向を把握すれば、劣化を早期に捉え、最も重要なクエリを最適化できます。 過去 7 日間で最も遅いクエリを見つける SELECT query_execution_id, work_group_name, principal_arn, submission_date_time, total_execution_duration / 1000.0 AS execution_seconds, data_scanned_size / POWER(1024, 3) AS data_scanned_gb, SUBSTR(query_string, 1, 200) AS query_preview FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '7' DAY AND state_enum = 'SUCCEEDED' ORDER BY total_execution_duration DESC LIMIT 50 ワークロードのパフォーマンス問題を時系列で検出する ワークグループ内の実行時間の集計値を今週と先週で比べ、ユーザーが気づく問題になる前に傾向をつかみます。 WITH weekly_stats AS ( SELECT work_group_name, IF(submission_date_time >= DATE_TRUNC('week', CURRENT_DATE), 'this_week', 'last_week') AS period, COUNT(*) AS query_count, AVG(total_execution_duration) AS avg_exec_ms, APPROX_PERCENTILE(total_execution_duration, 0.95) AS p95_exec_ms, SUM(data_scanned_size) AS total_bytes_scanned FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= DATE_TRUNC('week', CURRENT_DATE) - INTERVAL '7' DAY AND state_enum = 'SUCCEEDED' GROUP BY 1, 2 ) SELECT tw.work_group_name, lw.query_count AS last_week_queries, tw.query_count AS this_week_queries, lw.avg_exec_ms / 1000.0 AS last_week_avg_sec, tw.avg_exec_ms / 1000.0 AS this_week_avg_sec, ROUND((tw.avg_exec_ms - lw.avg_exec_ms) * 100.0 / lw.avg_exec_ms, 1) AS avg_pct_change, lw.p95_exec_ms / 1000.0 AS last_week_p95_sec, tw.p95_exec_ms / 1000.0 AS this_week_p95_sec FROM weekly_stats tw JOIN weekly_stats lw ON tw.work_group_name = lw.work_group_name WHERE tw.period = 'this_week' AND lw.period = 'last_week' ORDER BY avg_pct_change DESC キュー時間を分析してキャパシティの逼迫度を把握する SELECT work_group_name, DATE(submission_date_time) AS query_date, COUNT(*) AS query_count, AVG(query_queue_time_duration) / 1000.0 AS avg_queue_sec, APPROX_PERCENTILE(query_queue_time_duration, 0.50) / 1000.0 AS median_queue_sec, APPROX_PERCENTILE(query_queue_time_duration, 0.95) / 1000.0 AS p95_queue_sec, MAX(query_queue_time_duration) / 1000.0 AS max_queue_sec FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '14' DAY GROUP BY work_group_name, DATE(submission_date_time) HAVING AVG(query_queue_time_duration) > 1000 ORDER BY avg_queue_sec DESC スキャンしたデータ量の多いクエリを見つける スキャンするデータ量が最も多いクエリを特定します。スキャン量の多いクエリはコストを押し上げる最大の要因で、最適化 (パーティショニング、述語のプッシュダウン、データ形式の変更) の最有力候補です。 SELECT query_execution_id, work_group_name, principal_arn, submission_date_time, data_scanned_size / POWER(1024, 4) AS data_scanned_tb, total_execution_duration / 1000.0 AS execution_seconds, SUBSTR(query_string, 1, 300) AS query_preview FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '7' DAY AND state_enum = 'SUCCEEDED' ORDER BY data_scanned_size DESC LIMIT 50 ここで紹介したクエリを使えば、プラットフォームチームは Athena をひとつのサービスとして運用できます。サービスレベル目標 (SLO) を定め、傾向を可視化し、何かが変わったときには早めに気づけます。 監査とコンプライアンス: 誰が、いつ、何を実行したかを把握する 規制やセキュリティの要件がある組織では、システムテーブルを、構造化されたクエリ可能な監査証跡として使えます。 特定のユーザーが一定期間に実行したすべてのクエリ SELECT query_execution_id, work_group_name, submission_date_time, state_enum, total_execution_duration / 1000.0 AS execution_seconds, data_scanned_size / POWER(1024, 2) AS data_scanned_mb, SUBSTR(query_string, 1, 200) AS query_preview FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE principal_arn = 'arn:aws:iam::111122223333:user/example-user' -- Replace with target user AND submission_date_time >= CURRENT_DATE - INTERVAL '7' DAY ORDER BY submission_date_time DESC 特定のテーブルにアクセスしたクエリ SELECT query_execution_id, work_group_name, principal_arn, submission_date_time, state_enum, ROUND(data_scanned_size / POWER(1024.0, 3), 3) AS data_scanned_gb, SUBSTR(query_string, 1, 200) AS query_preview FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" CROSS JOIN UNNEST(tables_accessed) AS t(tbl) WHERE tbl.database_name = 'my_database' -- Replace with target database AND tbl.table_name = 'my_table' -- Replace with target table AND submission_date_time >= CURRENT_DATE - INTERVAL '30' DAY ORDER BY submission_date_time DESC Athena はシステムテーブルを Iceberg のデータとしてお客様自身のアカウントに保存し、レコードを書き込めるのは Athena サービスだけです。そのため、システムテーブルは監査に使える信頼性の高いクエリアクティビティの記録になります。保持期間、アクセスポリシー、暗号化はお客様が管理します。 運用監視: エラー率とワークロードの健全性を追跡する システムテーブルを使うと、CloudWatch の集計メトリクスでわかる範囲を超えて、Athena ワークロードの運用状況を可視化できます。データはクエリ単位なので、ユーザーの構文エラーが急増しただけの問題のないケースと、対処が必要なシステムエラーの急増とを区別できます。集計メトリクスでは両者を見分けられません。 ワークグループ別のエラー率 WITH error_stats AS ( SELECT work_group_name, COUNT(*) AS total_queries, COUNT(*) FILTER (WHERE state_enum = 'FAILED' AND error_category_enum = 1) AS system_errors, COUNT(*) FILTER (WHERE state_enum = 'FAILED' AND error_category_enum = 2) AS user_errors FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '7' DAY GROUP BY work_group_name ) SELECT work_group_name, total_queries, system_errors, ROUND(system_errors * 100.0 / SUM(system_errors) OVER (), 1) AS percent_of_all_system_errors, user_errors, ROUND(user_errors * 100.0 / SUM(user_errors) OVER (), 1) AS percent_of_all_user_errors FROM error_stats 急増の原因を調べるには、失敗したクエリを error_category_enum と error_message でグループ化し、どのエラーがどこに集中しているかを正確に確認します。 リソースを使い果たしたクエリを特定する リソースを使い果たしたクエリは最適化の有力候補です。パーティショニングの改善、クエリの書き換え、キャパシティの追加が効く可能性があります。 SELECT query_execution_id, work_group_name, principal_arn, submission_date_time, error_message, ROUND(data_scanned_size / POWER(1024.0, 3)) AS data_scanned_gb, ROUND(total_execution_duration / 1000.0, 1) AS execution_seconds, SUBSTR(query_string, 1, 200) AS query_preview FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '7' DAY AND state_enum = 'FAILED' AND error_message LIKE 'Query exhausted resources%' ORDER BY data_scanned_size DESC キャパシティ予約の最適化 キャパシティ予約 を使っている場合は、プロビジョニングしたキャパシティの使われ方をシステムテーブルで確認できます。Athena が dpu_count 列に値を入れるのは、キャパシティ予約で実行したクエリだけです。そのため、 dpu_count 列には 2 つの役割があり、予約済みのキャパシティで実行したクエリがどれかと、各クエリが消費した DPU 数の両方がわかります。予約が消費した DPU 時間の推移を追えば、予約のサイズが適切かどうかを確認できます。また、前述の実行時間とキュー時間のパターンから、オンデマンドのワークロードがキャパシティ予約に適しているかどうかも判断できます。 キャパシティ予約で実行したクエリが消費した週ごとの DPU 時間 SELECT DATE_TRUNC('week', submission_date_time) AS week, COUNT(*) AS reservation_queries, ROUND(SUM(dpu_count * total_execution_duration / 3600000.0), 1) AS dpu_hours FROM "s3tablescatalog/aws-athena"."metadata"."query_executions" WHERE submission_date_time >= CURRENT_DATE - INTERVAL '90' DAY AND state_enum = 'SUCCEEDED' AND dpu_count > 0 -- populated only for capacity-reservation queries GROUP BY 1 ORDER BY 1 アーキテクチャとデータモデル Athena のシステムテーブルは、特別な種類の S3 テーブルバケットを使います。通常の S3 テーブルバケットと同じように動作しますが、書き込めるのは AWS のサービスだけです。そのため、データを所有するメリットを得ながら、レコードの完全性も保てます。 お客様がデータを所有 – データはお客様のアカウント内にあり、お客様のキーで暗号化され、お客様のポリシーで管理されます。 不変のレコード – システムテーブルに書き込めるのは Athena だけです。お客様のアカウント内のどの IAM プリンシパルも、個々のレコードを変更・削除できません。 標準的な形式 – Athena、Amazon Redshift、 Amazon EMR 、 Apache Spark 、 Trino など、Iceberg 互換のエンジンであればどれでもデータを読み取れます。 自動メンテナンス – コンパクション、スナップショットの管理、設定した保持期間に基づくデータの有効期限切れの処理は S3 Tables が行います。 Athena は保持期間の既定値を設定しません。S3 Tables でレコードの有効期限を設定するまで、レコードは保持されます。期限は最短 1 日で、上限はありません。データは効率よくスキャンできるようにパーティション分割され、クエリの実行データはバッチで届きます。通常はクエリの完了から数分以内です。パーティション列を確認するには、 DESCRIBE ステートメントを使います。 まとめ Amazon Athena のシステムテーブルを使えば、独自のインフラストラクチャを用意しなくても、クエリワークロードの状況をクエリで可視化できます。チームへのコスト配分、パフォーマンス劣化の調査、コンプライアンスの証跡作成、Athena の使われ方の把握と、目的が何であっても、クエリ 1 本で答えが得られるようになりました。Athena はシステムテーブルを AWS Glue Data Catalog に登録し、オープンな Apache Iceberg 形式でお客様自身のアカウントに保存するため、 Amazon Quick Sight やビジネスインテリジェンス (BI) ツールから直接参照できます。これまでチームが保守してきた独自のパイプラインは不要になります。 まずは Athena コンソールからシステムテーブルを有効にしてください。詳しくは、Amazon Athena ユーザーガイドの「 System Tables 」を参照してください。 著者について Pathik Shah Pathik は、Amazon Web Services のシニアアナリティクスアーキテクトです。2015 年に AWS に入社して以来、ビッグデータ分析を専門とし、お客様が AWS の分析サービスを使ってスケーラブルで堅牢なソリューションを構築できるよう支援しています。 Theo Tolv Theo は、スウェーデンのストックホルムを拠点とするプリンシパルアナリティクスアーキテクトです。キャリアの大半を通じて規模の大小を問わずデータに携わり、2008 年から AWS 上で動くアプリケーションを構築してきました。余暇には電子工作をしたり、スペースオペラを読んだりして過ごしています。 Raza Hafeez Raza は、Amazon Redshift のシニアテクニカルプロダクトマネージャーです。エンタープライズデータウェアハウスの構築と最適化に 15 年以上携わってきました。あらゆる規模のお客様にとって、クラウドでの分析を手軽で費用対効果の高いものにすることに情熱を注いでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Woosuk Choi がレビューしました。

従業員の家族を職場に招く「ファミリーデー」で、子どもたちに通信の仕組みを体験してもらうため、光ファイバーを使った音声通話装置を一から作りました。 この記事では、回路の試作やプリント基板・ケースの製作、人数分の量産、そして当日の実験教室の様子までをご紹介します。 はじめに AIロボット部とは 光ファイバーで「通信」を体験してもらう 通信装置を作る アナログ回路と格闘する プリント基板を作る ケースも3Dプリンターで作る そして量産へ…… 当日の様子 おわりに はじめに こんにちは、AIロボット部（社内サークル）部員の浅野秀平です。 普段はデジタル改革推進部で、社内のデータ分析の仕事をしています。 今回は、従業員の家族を職場に招き、普段働いている場所や仕事に触れてもらう「ファミリーデー」の企画の1つとして、子どもたちに「通信」を身近に感じてもらう体験教室を実施しました。 この記事では、その体験教室で使う実験装置を試作した過程から、当日の様子までをご紹介します。 AIロボット部とは AIロボット部は、ものづくりに興味のある社員が集まる社内サークルです。 普段はSlack上でゆるく情報交換をしたり、ハッカソンなどのイベントに参加したりしています。 これまでの活動については、以下の記事もご覧ください。 AIロボット部の活動記事一覧 光ファイバーで「通信」を体験してもらう 今年のファミリーデーでは、NTTドコモビジネスの事業とも深く関わる「通信」をテーマに、光ファイバーを使った音声通話の実験教室「ひかりでんわ」を企画しました。 コンセプトは、以下のようなものです。 私たちは普段、家族や友人と離れた場所にいても、電話やインターネットを通して当たり前のように会話をしたり、動画を見たりしています。 その「つながる」を支えているのが、通信の技術です。 この教室では、子どもたち自身の手で通信装置を組み立て、自分の声が「光」に変わり、光ファイバーを通って相手に届く仕組みを体験します。 「見て・作って・話して」楽しみながら、普段は意識することのない通信の仕組みや、私たちの暮らしを支える技術への興味を持ってもらうことを目指しました。 子どもたち自身に通信装置を組み立ててもらい、音が光になって伝わる様子を観察することで、ものづくりの楽しさと通信技術の面白さを体験してもらうのが狙いです。 通信装置を作る こちらが、今回製作した通信装置です。 仕組みは比較的シンプルです。 マイクから入った音声の電気信号を増幅し、LEDを光らせる LEDの光を、光ファイバーを通して反対側の光センサーへ届ける 光センサーで受け取った信号を再び増幅し、スピーカーから音として鳴らす つまり、声を一度「光」に変換し、光ファイバーの中を通してから、もう一度「声」に戻しています。 アナログ回路と格闘する 普段からArduinoなどのマイコンを使った電子工作には慣れていましたが、アナログ回路の経験はそれほどありませんでした。 そのため今回は、ChatGPTに回路について教えてもらいながら設計を進めました。 抵抗やコンデンサーの値を変えては試し、うまくいかなければまた回路を修正する、という作業の繰り返しです。 途中では、マイコンを使って音声をデジタル処理する方法も検討しました。 数日間の試行錯誤の末、光ファイバーの先につないだスピーカーから初めて自分の声が聞こえてきた瞬間は、かなり感動しました。 ちなみに当初は、テレビのリモコンのような赤外線LEDを使い、空間を飛ばして音声を送る方法も試していました。 しかし、どう調整しても1〜2m先へ安定して音声を届けることができず、最終的には断念しました。 もし同じような構成でうまくいった方がいたら、ぜひ教えてください。 プリント基板を作る 試作回路が動いたところで、次は回路を回路図に起こし、プリント基板を設計しました。 回路や基板データの詳細は、GitHubでも公開しています。 https://github.com/mikaka-robotics/hikari_denwa ケースも3Dプリンターで作る 基板を収めるケースはBlenderでモデリングし、3Dプリンターで製作しました。 今回特に工夫したのが、送信と受信を切り替える仕組みです。 本体中央には、送信用のLEDと受信用の光センサーが並んでいます。 中央にある水色のパーツをスライドさせると、光ファイバーの接続先が物理的に切り替わります。 同時に基板上の回路も送信／受信で切り替わるため、1つの操作で通信方向を変更できます。 なお、今回使用した光ファイバーは、本格的な通信用のものではありません。 安価で扱いやすい、照明・装飾用として販売されているプラスチック製の光ファイバーを使用しています。 そして量産へ…… 試作品が完成し、いよいよ参加する子どもたちの人数分を量産していきます。 ……が、ここで想像以上に大変なことに気づきました。 今回の基板は部品点数が多く、すべて手作業ではんだ付けすると、1枚を組み立てるだけで約30分かかります。 さらにケースにも3か所のネジ穴があり、3Dプリントしたケース一つひとつに、タップを使ってネジ山を切る必要があります。 今回の参加者は約50人。そして「電話」なので1人につき2台必要となり、用意する通信装置は合計100台です。 つまり、 基板も100枚。 ここからは、AIロボット部の部員総出による地獄の量産作業が始まりました。 ひたすら部品をはんだ付けし、ケースにタップを立て、組み立てる日々です。 途中からは、部品の取り付けやケース加工などを分担し、ちょっとした製造ラインのような状態になっていました。 それでも当日までになんとか必要な台数を完成させ、無事にファミリーデーを迎えることができました。 当日の様子 当日は、子どもたちに説明書を見ながら部品を組み立ててもらいました。 完成した装置を光ファイバーでつなぎ、最後は実際に会話してもらいます。 説明書を読みながら、 「これはどこにつけるんだろう？」 と、謎解きのように1つずつ部品を取り付けていきます。 そして、いよいよ完成した装置で通信実験です。 最初は「本当にこれで声が聞こえるの？」という様子だった子どもたちも、光ファイバーの先から相手の声が聞こえてくると、「聞こえた！」と驚いた表情を見せてくれました。 兄弟同士で話したり、親子で装置を挟んで会話したりと、それぞれ楽しみながら試してくれていました。 普段何気なく使っている「通信」は、音を別の信号へ変換し、離れた場所まで届け、再び音へ戻すことで成り立っています。 その仕組みを、自分で組み立てた装置を通して、少しでも実感してもらえたのではないかと思います。 おわりに 今回、一から実験装置を設計し、基板やケースを作り、人数分を量産して実験教室を開催するところまで、AIロボット部らしいものづくりができたと思います。 特に、実際に装置を使った子どもたちから「聞こえた！」という反応をもらえたのは、作った側としてもうれしい瞬間でした。 一方で、大量の基板を手ではんだ付けするのは想像以上に大変でした。 来年以降は準備をもう少し楽にするため、基板製造だけでなく、部品実装まで依頼できるサービスの利用も検討したいと思います。 今後もAIロボット部では、遊び心と技術を組み合わせたチャレンジを続けていきます。 次回の活動報告もお楽しみに！

本ブログは 2026 年 7 月 20 日に公開された AWS Blog “ Introducing the Amazon GuardDuty investigation agent: on-demand AI-powered threat assessment ” を翻訳したものです。 Amazon GuardDuty の新しい調査エージェント (現在パブリックプレビュー) は、 Amazon Web Services (AWS) 環境全体のセキュリティ検出結果を調査し、調査にかかる時間を数時間から数分に短縮します。 GuardDuty は、AWS アカウントとワークロードを継続的にモニタリングして、不審なアクティビティ、悪意のある可能性のあるアクティビティ、不正な動作を検出するマネージド型の脅威検出サービスです。可視化と修復のために詳細なセキュリティ検出結果を提供します。 単一の不審な検出結果を調査する場合でも、組織全体のセキュリティポスチャを評価する場合でも、調査エージェントはリスクレベル、信頼度スコア、具体的な対応につながる推奨事項を含む構造化された評価を提供します。 セキュリティチームは、セキュリティ検出結果の調査や複数のツールにまたがるデータの関連付けに何時間も費やすことがあります。GuardDuty 調査エージェントはこの関連付けを自動化し、すぐに対応に活かせるインテリジェンスを提供します。この機能は GuardDuty に直接組み込まれており、AWS マネジメントコンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、AWS API、または AWS SDK を通じてオンデマンドでアクセスできます。 この記事では、以下の内容を説明します。 GuardDuty コンソールで調査エージェントを有効化する コンソールまたは AWS CLI を使用して最初の調査を作成する AWS MCP サーバーと調査エージェントを組み合わせて、AI 支援型のセキュリティオペレーションを実現する GuardDuty 調査エージェントの主な機能 GuardDuty 調査エージェントは、GuardDuty で既に使い慣れたパターンに沿った API を提供します。完了した各調査は、リスクレベル、信頼度評価、 MITRE ATT&CK® テクニックマッピング、リソースマッピング、優先順位付けされた推奨事項を返します。 コンソールからは、特定の検出結果、アカウント、または組織全体のすべてのアカウントを対象に調査のスコープを設定できます。また、AWS CLI と API では、最大 2,048 文字の自由形式のトリガープロンプトを受け付けます。これにより、調査対象を自然言語で記述し、懸念事項、疑わしい根本原因、調査の優先事項を指定して、エージェントの分析をガイドできます。 調査エージェントの API は、 Agent Toolkit for AWS の一部である公式の AWS MCP サーバー経由でも利用できるため、既存のセキュリティツールチェーンや AI を活用したワークフローに統合できます。エージェントを直接管理したり操作したりする必要はありません。API エンドポイントを呼び出すと、エージェントが検出結果を調査し、証拠を関連付け、複雑な設定を管理する必要なく評価を提供します。 調査エージェントによる検出結果の分析の仕組み 調査を作成すると、エージェントはクロスリージョン推論を使用してスコープに基づいて検出結果を処理し、構造化された出力を生成します。 クロスリージョン推論 – GuardDuty の調査は Cross-Region Inference Service (CRIS) を使用します。CRIS は、お客様の地域内で調査の評価を処理するのに最適な AWS リージョンを選択します。データは調査リクエストが発生したリージョンにのみ保存されます。ただし、調査データと概要結果は、そのリージョン外で処理される場合があります。データは、Amazon が提供する安全なネットワーク上で暗号化されて送信されます。 リクエストがルーティングされる可能性のある推論リージョンの詳細については、 Amazon GuardDuty ユーザーガイド の調査セクションにあるクロスリージョン推論ルーティングテーブルを参照してください。 調査の出力 – 完了した各調査では、以下のインサイトが生成されます。リスクレベル (Info、Low、Medium、High、または Critical)、信頼度 (Unknown、Low、Medium、または High)、概要 (検出結果と主な観察事項の説明)、調査の詳細 (追加のコンテキスト)、推奨アクション (AWS CLI コマンドを含む詳細なアクション) です。 アカウントのスコープ設定 – アカウントの指定が必要なのは、特定のメンバーアカウントを調査する場合のみです。組織全体などのより広いスコープの場合、アカウント ID は不要です。エージェントは、後述の認可モデルに従ってアクセスを許可されたアカウント内の検出結果のみを調査します。 前提条件 始める前に、以下の前提条件が満たされていることを確認してください。 アカウントで Amazon GuardDuty が有効になっていること サポート対象リージョンの AWS アカウントがあること (「利用可能なリージョンと料金」セクションを参照) 必要な IAM アクセス許可 3 つの新しいアクセス許可が必要です。新しい調査を開始するための guardduty:CreateInvestigation 、結果を取得するための guardduty:GetInvestigation 、特定のディテクターの調査を表示するための guardduty:ListInvestigations です。 IAM ポリシーの例: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "guardduty:CreateInvestigation", "guardduty:GetInvestigation", "guardduty:ListInvestigations" ], "Resource": "*" } ] } 認可モデル 管理者アカウントは、自身とメンバーアカウントに対して、調査の作成、結果の取得、調査リストの表示を行えます。メンバーアカウントは、自身のアカウントの結果の取得と調査リストの表示のみが可能です。メンバーアカウントは調査を作成できず、他のアカウントや管理者アカウントに属する調査にはアクセスできません。アカウントの指定が必要なのは、特定のメンバーアカウントを調査する場合のみです。自身のアカウントや組織全体のアカウントを対象とする場合、アカウント ID は不要です。 調査エージェントを有効化して最初の調査を作成する 始める前に、前提条件に記載されている必要な IAM アクセス許可があることを確認してください。 サポート対象のリージョンで AWS マネジメントコンソールを開き、Amazon GuardDuty に移動します ナビゲーションペインで [Investigations] を選択します 図 1: GuardDuty 調査ダッシュボード 調査が有効になっていない場合は、 [Go to Settings] を選択し、 [Enable] を選択して調査を有効にします 図 2: GuardDuty 調査の有効化画面 調査を有効化したら、調査ページに戻ります ナビゲーションペインで [Initiate Investigation] を選択します 図 3: GuardDuty 調査の開始 調査のスコープを選択します GuardDuty Finding ID を入力: 特定の GuardDuty 検出結果を詳しく調査したい場合に使用します AWS Account ID を入力: 特定の AWS アカウントの全体的なセキュリティポスチャを評価したい場合に使用します All accounts : 組織全体のセキュリティ評価や、ラテラルムーブメント (横展開) の可能性を調査する場合に使用します [Initiate investigation] を選択します 図 4: GuardDuty 調査のセットアップ 調査が完了するまで待ちます (プレビュー期間中は、通常アカウントレベルの調査で 2～5 分、特定の検出結果の調査で 10～12 分かかります)。ステータスは自動的に更新されます 調査が完了したら、調査タイトルを選択して評価の全文を表示します 図 5: GuardDuty 調査完了メニュー 調査の評価には、全般情報、調査の概要、マッピング、脅威評価、推奨アクションなど、調査に関する詳細な情報が含まれています。 [General Information] セクションには、調査 ID、ステータス、トリガー元アカウント、作成日時が表示されます。 図 6: 評価の [General Information] セクション [Summary] セクションでは、主な観察事項と検出結果が説明されます。 図 7: 評価の [Summary] セクション [Mapping] セクションには、攻撃手法と影響を受けた AWS リソースが表示されます。 図 8: 評価の [Mapping] セクション (MITRE ATT&CK) [Threat Assessment] セクションには、リスクレベル、信頼度スコア、詳細な脅威分析が表示されます。 図 9: [Threat Assessment] セクション [Recommended Actions] セクションには、優先順位付けされた修復手順が一覧表示されます。 図 10: 評価の [Recommended Actions] セクション 調査は、以下の API エンドポイントを使用して AWS CLI または SDK からも実行できます。 CreateInvestigation – GuardDuty の調査を開始します。セキュリティ検出結果を自動的に分析し、関連するアクティビティを関連付け、アカウントレベルの分析を実行し、推奨される次のステップを含む構造化された調査概要を生成します GetInvestigation – 特定の調査のステータスと結果を取得します。完了時には、エージェントによる評価、関連付けられた証拠、推奨アクションが含まれます ListInvestigations – フィルタリングとページネーションを使って、環境全体の調査を表示します AWS CLI を使用して調査を実行する エージェントは複数のデータソースへのクエリ、サービス間での検出結果の関連付け、AI ベースの分析を実行するため、調査は非同期で行われます。調査を作成した後は、完了するまで定期的にステータスを確認する必要があります。 ステップ 1: ディテクター ID を確認する 各 GuardDuty のデプロイには、アカウントごと、リージョンごとに一意のディテクター ID があり、これによってお客様固有の GuardDuty 設定が識別されます。このディテクター ID はすべての AWS CLI オペレーションで必要になります。特に複数のリージョンで GuardDuty を有効にしている場合は注意が必要です。ディテクター ID は、GuardDuty コンソールの [Settings] で確認するか、リージョンを指定して以下のコマンドを実行することで確認できます。例えば、対象の GuardDuty ディテクターが us-east-1 (バージニア北部) リージョンにある場合は次のように実行します。 aws guardduty list-detectors –-region=us-east-1 想定されるレスポンス: { "DetectorIds": [ "12abc34d567e8fa901bc2d34eexample" ] } 注記: レスポンスの DetectorID の値は、以降のすべてのコマンドで使用します。 同じリージョンでのみ作業する場合は、繰り返しの入力を避けるため、セッションで環境変数を設定することもできます。例えば Linux では次のようにします。 export AWS_DEFAULT_REGION=us-east-1 その他のオペレーティングシステムでの設定方法については、 AWS CLI のドキュメントを参照してください。 ステップ 2: 調査を作成する 以下は、特定の検出結果を調査するコードの例です。 aws guardduty create-investigation us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --trigger-prompt "Investigate this finding ID 1ab2c3d4e5f6a7b8c9d0e1f2a3b4c5d6" --trigger-prompt パラメータは、GuardDuty のメタデータには含まれておらず、API 経由でも取得できないコンテキストがある場合に役立ちます。 想定されるレスポンス: { "InvestigationId":"a1b2c3d4-5678-90ab-cdef-ef1234567890" } AWS アカウント全体の検出結果を調査するには、以下の例を使用します。 aws guardduty create-investigation –-region=us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --trigger-prompt “Investigate findings in Account 123456789012” 組織全体の検出結果を調査するには、次のようにします。 aws guardduty create-investigation –-region=us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --trigger-prompt “Investigate findings across my AWS Organization” ステップ 3: 調査のステータスを確認する 以下のように、 AWS CLI の --query オプションを使用して出力をフィルタリングし、 Status セクションのみを簡潔に表示して、調査のステータスを確認します。 aws guardduty get-investigation –-region=us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --investigation-id a1b2c3d4-5678-90ab-cdef-ef1234567890 --query 'Investigation.Status' Status フィールドに COMPLETED と表示されるまで、このコマンドを繰り返し実行します。 完了時のレスポンス出力の例: { "Investigation": { "InvestigationId": "a1b2c3d4-5678-90ab-cdef-ef1234567890", "Status": "COMPLETED", "TriggerPrompt": "Investigate finding 1ab2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 in account 123456789012", "TriggeredBy": "123456789012", "RiskLevel": "Critical", "Risk": "Active multi-stage runtime compromise on EKS worker node with root-privileged reverse shell, Docker socket access, malicious file execution, and 500 multi-tactic runtime signals — behavioral evidence is consistent with a genuine intrusion.", "Confidence": "High", "Summary": "{\"keyObservations\":{\"title\":\"...\",\"narrative\":\"...\",\"observations\":[...]},\"countermeasures\":[...],\"threatAssessment\":{...}}", "Cloud": { "Provider": "AWS", "Region": "us-east-1", "Account": "123456789012" }, "Metadata": { "Product": { "Name": "AmazonGuardDuty AI Analyst", "Feature": "Investigation" }, "Version": "1.0.0" }, "StartTime": 1705319400.0, "EndTime": 1705319700.0 } } ステータス値 – RUNNING 、 COMPLETED 、 FAILED 所要時間 – 調査時間は変動することがあります。30 秒ごとにステータスを確認すれば結果を得るのに十分です ステータスが FAILED の場合 – レスポンス内のエラーメッセージを確認し、アクセス許可が認可モデルの要件を満たしていることを確認してください 特定のディテクターのすべての調査を一覧表示するには、以下を実行します。 --max-results オプションは省略可能ですが、返される結果の数を絞り込むのに便利です。 aws guardduty list-investigations –-region=us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --max-results=10 手動で調査を実行するだけでなく、API ファーストの設計により、GuardDuty の検出結果をサードパーティのツールに送信するという一般的なお客様のパターンにも対応しています。既存のパイプラインに自動調査を追加できるため、チームは生のアラートではなく、コンテキストが付加され優先順位付けされたインテリジェンスを受け取れます。 GuardDuty の検出結果を Amazon EventBridge 経由でセキュリティ情報およびイベント管理 (SIEM) プラットフォームにルーティングし、アナリストが各アラートを手動で調査しているお客様を考えてみましょう。調査エージェントを使用すると、パイプラインに AWS Lambda 関数を組み込み、検出結果 ID を指定して CreateInvestigation を呼び出し、完了を待ってから、コンテキストが付加された結果 (リスクレベル、信頼度スコア、MITRE ATT&CK マッピング、推奨アクション) を元の検出結果とともに SIEM に転送できます。Critical の検出結果は、さらなる分析や自動化のために、お客様のインシデント対応キューに直接ルーティングされます。信頼度の高い低リスクの検出結果は、自動的にクローズしたり、週次レビュー用にまとめたりできます。これにより、アナリストは繰り返しのログ関連付け作業から解放され、評価の検証と確認済みの脅威への対応に時間を使えるようになります。 このパターンは、API や EventBridge のメッセージングを使用するようにカスタマイズできる SIEM、チケットシステム、自動化プラットフォームで機能します。調査エージェントは、パイプラインの最終地点としてではなく、処理ステップとして組み込むことができます。 このエージェントは、GuardDuty の検出結果を調査するようにファインチューニングされており、 AWS Security Agent や AWS DevOps Agent といった他の AWS フロンティアエージェントとは異なるものです。調査エージェントのスコープは、GuardDuty の検出結果に特化した分析を提供することに絞られています。 AWS MCP サーバーとの統合 Model Context Protocol (MCP) は、AI アシスタントが外部のデータソースやツールに安全に接続できるようにするオープン標準です。AWS MCP サーバーはこの標準を AWS のサービス向けに実装しているため、Kiro、Anthropic の Claude、その他の MCP 対応クライアントなどのツールを使用して、AI を活用したワークフローに GuardDuty の調査を組み込めます。 AWS MCP サーバーを設定する MCP クライアントが AWS MCP サーバー に接続するように設定します 自然言語を使用して調査を呼び出します (例: 「アカウント 123456789012 の最近の Unauthorized Access の検出結果を調査して」 ) MCP クライアントを通じて返される調査結果を確認します。結果は、使用するモデルやエージェント、設定、AI の非決定的な性質によって異なる場合があります 結果を既存のエージェント自動化に統合するか、検出結果に基づいて手動で対応します。 その他の使用例 「本番アカウントの最新の重要度が高い検出結果を調査して」 「アカウント 987654321098 の検出結果 ID abc123 の調査を作成し、何が起きたかを要約して」 「過去 24 時間の調査を一覧表示し、人によるレビューが必要なものにフラグを付けて」 調査エージェントと AWS Security Incident Response の関係 re:Invent 2024 で、AWS は AWS Security Incident Response (AWS SIR) を発表しました。これは、セキュリティインシデントへの準備、対応、復旧を迅速に行うためのマネージドサービスです。AWS SIR と GuardDuty 調査エージェントは、セキュリティワークフローの異なる段階に対応しています。GuardDuty 調査エージェントは、オンデマンドの評価機能を提供します。特定の検出結果、アカウントのセキュリティポスチャ、または組織全体のセキュリティポスチャについてより深いコンテキストが必要な場合に、調査を作成すると、リスクレベル、信頼度スコア、MITRE ATT&CK® テクニックマッピング、具体的な対応につながる推奨事項を含む構造化された評価が得られます。セキュリティアナリストはこれを使用して、GuardDuty が検出した内容の範囲と重大度をすばやく把握できます。 AWS SIR で AWS がサポートするケースを作成すると、SIR の調査エージェントがアクティブになり、AWS Security Incident Response のエンジニアと並行して証拠を収集し、数分以内に調査の概要を提供します。AWS SIR は、封じ込めと復旧を調整するために AI を活用した自動化と人間の専門知識の両方が必要となる、進行中のセキュリティイベントに特化して構築されています。 セキュリティチームはこれらの機能を活用することで、GuardDuty 調査エージェントによるオンデマンドでの検出結果の評価と優先順位付け、裏付けとなる証拠を添えた確認済みの問題の関係者へのエスカレーション、さらに追加のサポートが必要な場合には AWS がサポートするケースの作成または更新による AWS SIR チームの迅速な関与を実現できます。 利用可能なリージョンと料金 GuardDuty 調査エージェントのパブリックプレビューは、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (ストックホルム)、アジアパシフィック (東京) を含む 10 の AWS リージョンで利用できます。 パブリックプレビュー期間中は、調査エージェントを無料で利用できます。使用量は、アカウントあたり 1 日 10 件の調査に制限されており、プレビュー期間中のアカウントあたりの累計上限は 100 件です。失敗した調査はこれらのクォータにはカウントされません。 今すぐ検出結果の調査を始める Amazon GuardDuty 調査エージェントは、調査にかかる時間を数時間から数分に短縮し、セキュリティチームが手動での関連付け作業ではなく、確認済みのセキュリティイベントに集中できるようにします。 開始手順 GuardDuty コンソールで調査エージェントを有効化する 最近の GuardDuty の検出結果を使用して最初の調査を作成する リスクレベルや推奨される次のステップを含む、構造化された評価を確認する AWS MCP サーバーを使用している組織では、お好みの AI アシスタントで自然言語を使って調査を呼び出すこともできます。 詳細情報 Amazon GuardDuty 調査エージェントのドキュメント – 設定と使用方法の詳細なガイダンス GuardDuty の IAM アクセス許可リファレンス – 調査オペレーションに必要なアクセス許可 Amazon EventBridge ユーザーガイド – 調査イベントを下流のシステムにルーティングする方法 MITRE ATT&CK® フレームワーク – 入門リソース AWS Security Incident Response – AWS セキュリティブログの記事 AWS Activation Days – AWS を使用して成果を達成するための具体的なガイダンスを提供する、今後開催される無料イベントに関する情報 Allan Holmes Allan は、セキュリティとコンプライアンス、ネットワーキング、DevOps にわたる 20 年以上の経験を持ち、現在はセキュリティスペシャリストとして活躍しています。この経験により、クラウドセキュリティの課題を包括的な視点で捉えることができます。AWS、ISC2、CompTIA の複数の技術認定資格と MBA を保有しており、深い技術的専門知識とビジネス戦略の橋渡しを行っています。仕事以外では、熱心なガーデナーであり電子工作愛好家でもあり、革新的なテクノロジーを実際に手を動かして探求することを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。