みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 2026 年も折り返し地点を過ぎ、いよいよ下半期に入りました！上半期は生成 AI とエージェントに関するアップデートが目立ちましたが、その勢いは下半期も止まる気配がありません。今週も Claude Sonnet 5 の登場や Amazon WorkSpaces for AI agents の一般提供開始など、エージェント活用を後押しするアップデートが多数ありました。 一方で 6/30 には AWS のサービス提供状況が更新され、いくつかのサービスがメンテナンスモードやサンセット (提供終了予定) へ移行しています。本記事にて主張なアップデートとして取り上げておりますのでご確認の上、該当サービスをご利用中の方は、代替サービスへの移行計画をお早めにご検討ください。 それでは、先週の主なアップデートについて振り返っていきましょう！ 2026年6月29日週の主要なアップデート 6/29(月) Amazon S3 サーバーアクセスログが Amazon CloudWatch Logs と Amazon S3 Tables への配信に対応 Amazon S3 のサーバーアクセスログを Amazon CloudWatch Logs へ直接配信できるようになりました。これにより、アクセスログデータに対する即時クエリ、アラーム、クロスアカウント/クロスリージョンの集約、AWS Key Management Service (KMS) 暗号化が利用可能になります。また、追加のストレージコストなしで Apache Iceberg 形式の Amazon S3 Tables にミラーリングすることも可能です。CloudWatch Logs への配信ではエラー率のアラーム設定やアクセスインシデントの調査などに活用できます。S3 Tables にミラーリングされたログは Amazon Athena や Amazon Redshift など Iceberg 互換のクエリエンジンから標準 SQL で即座にクエリでき、アクセスパターンの監査やコスト要因の分析に役立ちます。AWS 中国リージョンおよび AWS GovCloud (米国) を除くすべての AWS リージョンで利用可能です。 AWS WAF が Amazon Bedrock AgentCore Gateway のサポートを追加 Amazon Bedrock AgentCore Gateway 向けの AWS ウェブアプリケーションファイアウォール (AWS WAF) 保護の一般提供が発表されました。エージェンティック AI ワークロードを一般的なウェブ脆弱性や悪用から保護できるようになります。AWS WAF 保護パックを AgentCore Gateway に関連付けることで、IP ベースのアクセスコントロール、レートベースのルール、一般的なルールセット・既知の不正入力・Bot Control を含む AWS マネージドルールグループを適用できます。Gateway レベルで一度設定するだけで、その背後にあるすべてのターゲットに一貫して適用されるため、単一の設定でダウンストリームのツールやエージェント、統合をまとめて保護できるのがポイントです。AWS WAF と Amazon Bedrock AgentCore Gateway の両方が利用可能なすべての AWS リージョンで提供されます。 6/30(火) AWS のサービスおよび機能の提供状況変更のお知らせ 複数の AWS サービスおよび機能について、提供状況が更新されました。メンテナンスに移行するサービスは 2026 年 7 月 30 日以降、新規のお客様はご利用いただけません (既存のお客様は継続利用可、AWS の運用・サポートも継続)。対象は、Amazon Bedrock Agents (2023 年 11 月リリース版、Amazon Bedrock Agents Classic に名称変更)、Amazon Cognito Sync、Amazon Kendra、Amazon Q Business、AWS Directory Service – Simple AD、AWS IoT Device Defender – Detect (2026 年 8 月 31 日以降)、AWS Mainframe Modernization – Self-Managed Experience、AWS Management Console – myApplications、AWS Resource Groups – Group Lifecycle Events、AWS Service Catalog – Application Registry、AWS Systems Manager – Application Manager、Amazon SageMaker AI の A2I / Clarify / Debugger / GeoSpatial / Ground Truth / Mechanical Turk / Model Monitor / Role Manager / Studio Lab です。サンセット (提供終了予定) に移行するサービスは、Amazon WorkSpaces – PCoIP / Pool、AWS Managed Services (AMS) Advanced、AWS re:Post Private、Amazon SageMaker AI – Profiler です。2026 年 6 月 30 日をもってサポート終了となったのは、Amazon Chime SDK – Carrier Voice Focus、Amazon SageMaker AI – Ground Truth Plus です。詳細は AWS 製品ライフサイクルページをご覧ください。 Amazon SageMaker AI が Gemma 4 モデルのサーバーレスモデルカスタマイズをサポート Amazon SageMaker AI が、教師ありファインチューニング (SFT)、直接選好最適化 (DPO)、強化ファインチューニング (RFT) を用いた Gemma 4 E4B および 31B モデルのサーバーレスカスタマイズをサポートするようになりました。Gemma は Google DeepMind が構築したオープンモデルのファミリーです。今回のリリースにより、Gemma 4 を含む Nova、Nemotron 3、Qwen、Llama、gpt-oss、DeepSeek などのモデルファミリーが SageMaker AI でサーバーレスカスタマイズに利用できるラインナップに揃いました。サーバーレスカスタマイズではインフラのプロビジョニングとトレーニングのオーケストレーションを SageMaker AI が引き受けてくれるため、クラスター管理ではなくデータと評価に集中できます。米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (アイルランド) で利用可能です。 Claude Sonnet 5 が利用可能に AWS で Claude Sonnet 5 の提供が開始されました。Anthropic の最新世代における最初の Sonnet モデルで、Sonnet の価格帯を維持しつつコーディング・エージェント・専門業務でトップクラスのインテリジェンスを提供します。コーディングでは大規模なコードベースの複数ファイルにまたがる変更やデバッグ・リファクタリングを、エージェント用途ではツール呼び出しや多ステップの状態保持・エラー回復を、ナレッジワークではドキュメント起草や非構造化データの構造化変換をこなします。アクセス方法はAmazon Bedrock 経由での利用と Claude Platform on AWS での利用の2 種類あります。Amazon Bedrock 経由ではデータを AWS インフラストラクチャ内に保持したまま、Guardrails や Knowledge Bases、リージョンデータレジデンシーなどのマネージド機能と組み合わせて利用できます。Claude Platform on AWS では、AWS コンソールから Anthropic のネイティブプラットフォーム体験に直接アクセスでき、Anthropic と直接やり取りする場合と同じ API・機能・コンソールを AWS の請求と認証に統合された形で利用できます。 Amazon WorkSpaces for AI agents の一般提供を発表 AI エージェントがマネージド WorkSpaces 環境を通じてデスクトップアプリケーションに安全にアクセス・操作できる Amazon WorkSpaces for AI agents が、一般提供開始となりました。ERP、CRM、メインフレーム、独自ツールなど、モダナイズが難しいデスクトップアプリケーションを、アプリの改修なしにエージェントから操作できるのが特徴です。エージェントは人間のユーザーと同じ ID 制御、ネットワーク分離、コンプライアンス境界を継承するため、ガバナンスを損なわずに保険金請求処理や取引決済などのバックオフィス業務を自動化できます。Model Context Protocol (MCP) を使うあらゆるエージェントフレームワークと連携します。プレビュー期間中のフィードバックを反映し、MCP 呼び出しで直接アプリケーションや OS を操作する MCP ツールフォワーディング、オペレーターがエージェント活動をライブで可視化しセッション中のアクセスを取り消せるリアルタイムセッション制御、既存の Active Directory ID の下で動作させられるドメイン参加フリートサポートといった機能も追加されています。 7/1(水) Amazon OpenSearch Service にログ分析向けに最適化された新エンジンが登場 Amazon OpenSearch Service に、ログ分析ワークロード向けに専用設計された新エンジンが導入されました。集計ワークロード向けのカラムナーストレージにより最大 70% のストレージ削減を実現し、同じコストで最大 3 倍のデータを保持できます。加えて、同じハードウェアで最大 2 倍の取り込みスループットと 2 倍高速な分析クエリを提供します。ポイントは、OpenSearch が得意とするフルテキスト検索と、新エンジンによる高速な集計・分析クエリを同一クエリ内で組み合わせられる点で、集計とインシデント調査を 1 つのドメインで両立できます。開始するには OpenSearch 3.5 以上でドメインを作成し、オブザーバビリティのユースケースを選択、エンジンモードを optimized に設定してください。米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、カナダ (中部)、アジアパシフィック (ムンバイ、シンガポール、シドニー、東京)、欧州 (フランクフルト、アイルランド、ロンドン、スペイン) のグローバル 12 リージョンで利用可能で、新エンジンの利用に追加料金はかかりません。 AWS AppConfig が A/B テスト向けのマネージド実験ツールを提供開始 AWS AppConfig で、A/B テストや機能実験を実行できる実験ツールの一般提供が開始されました。個別の実験インフラストラクチャを構築・管理する必要なく、25 年以上にわたる Amazon の実験ベストプラクティスをベースに、AI 駆動のガイダンスで堅牢な実験の構築を支援します。UI 変更やレコメンデーションアルゴリズム、AI モデルの選択やプロンプト実験まで、アプリケーションスタック全体で A/B テストや多変量実験を実行可能で、機能バリエーションの定義やトラフィック割り当て率の設定を、AWS Management Console、CLI、API、AWS CDK から行えます。結果は Amazon CloudWatch や既存の分析ツールで分析でき、勝ちパターンは AppConfig の安全なロールアウトで本番環境へ適用できます。この機能は Amazon EC2、AWS Lambda、Amazon ECS、Amazon EKS、AWS AppConfig Agent 経由のオンプレミスサーバー上で動作します。AWS GovCloud (米国) を含むすべての AWS リージョンで利用可能です。 Amazon RDS のクロスリージョン自動バックアップが 4 つの追加 AWS リージョンで利用可能に Amazon RDS のクロスリージョン自動バックアップレプリケーションが、4 つの AWS リージョンで追加提供されました。今回のリリースで、メキシコ (中部) と欧州 (アイルランド) または米国西部 (北カリフォルニア) の間、アジアパシフィック (台北) とアジアパシフィック (シンガポール) または アジアパシフィック (東京) の間、アジアパシフィック (ニュージーランド) とアジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (メルボルン) の間、アジアパシフィック (タイ) とアジアパシフィック (シンガポール) または アジアパシフィック (ジャカルタ) の間で、自動バックアップレプリケーションを設定できるようになりました。クロスリージョン自動バックアップレプリケーションでは、RDS がスナップショットとトランザクションログを選択した送信先リージョンへレプリケートしてくれるので、プライマリリージョンが利用できなくなった場合でも、セカンダリリージョンで任意の時点に復元して迅速にオペレーションを再開できます。Amazon RDS for PostgreSQL、MariaDB、MySQL、Db2、Oracle、Microsoft SQL Server で利用できます。 7/2(木) AWS Config が 8 つの新しいリソースタイプに対応 AWS Config が、Amazon API Gateway、Amazon EC2、Amazon S3 Vectors を含む主要サービスにわたる 8 つの追加リソースタイプに対応しました。追加されたリソースタイプは、AWS::ApiGateway::DomainNameV2、AWS::ApiGatewayV2::VpcLink、AWS::EC2::VPCEncryptionControl、AWS::NetworkFirewall::ContainerAssociation、AWS::OpenSearchServerless::SecurityPolicy、AWS::OSIS::Pipeline、AWS::S3Vectors::VectorBucket、AWS::S3Vectors::VectorBucketPolicy の 8 種類です。すべてのリソースタイプの記録を有効にしている場合、これらの新規リソースは自動的に追跡されます。新しくサポートされたリソースタイプは Config ルールと Config アグリゲーターでも利用可能で、リソースが利用可能なすべての AWS リージョンで対応します。 Amazon EC2 X8i インスタンスが追加リージョンで利用可能に Amazon EC2 X8i インスタンスが、アジアパシフィック (ソウル)、アジアパシフィック (マレーシア)、アジアパシフィック (東京) の各リージョンで利用可能になりました。AWS でのみ提供されるカスタム Intel Xeon 6 プロセッサを搭載しており、クラウド上の同等 Intel プロセッサの中で最高のパフォーマンスと最速のメモリ帯域幅を提供します。前世代の X2i と比較して、最大 43% 高いパフォーマンス、1.5 倍のメモリ容量 (最大 6TB)、3.3 倍のメモリ帯域幅を実現し、SAP HANA、大規模データベース、データ分析、電子設計自動化 (EDA) などのメモリ集約型ワークロードに適しています。X2i との比較で SAPS 性能は最大 50%、PostgreSQL 性能は最大 47%、Memcached 性能は 最大 88%、AI 推論性能は 最大 46% の高速化が期待できます。large から 96xlarge まで、2 つのベアメタルオプションを含む 14 サイズで提供され、Savings Plans、オンデマンド、スポットで購入可能です。 Amazon SageMaker Unified Studio が Terraform によるプロビジョニングをサポート Amazon SageMaker Unified Studio が Terraform に対応しました。オープンソースの terraform-aws-sagemaker-unified-studio モジュールを使用して、バージョン管理されたテンプレートから SageMaker Unified Studio ドメインをデプロイできます。プラットフォームチームは、既存の Infrastructure-as-Code パイプラインに SageMaker Unified Studio を組み込むことで、開発・ステージング・本番アカウント間の一貫性を維持できます。サブモジュールにより、ブループリントの有効化、プロジェクトプロファイルへの構成、プロジェクトの独立作成が可能で、既存の IAM ロールを流用したプロジェクト作成もできます。SageMaker Unified Studio が利用可能なすべての AWS リージョンで利用できます。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

こんにちは！ LIFULLでユーザーファーストを推進しているチームに所属している木住野（きしの）です。 職種はQAEですが、ユーザーにとっての"あらゆる品質"をより良くするため、UXリサーチャーのメンバーと共にビジョン実現に向けて動いています。 2026年6月28日開催の RESEARCH Conference 2026 に参加してきたので、 カンファレンスの様子や刺さったセッションについてご紹介いたします。 会場の様子 今回響いた2つのキーワード 共体験 - 一緒にやるから深くわかる モンスト海外展開のリサーチ：「そのまま出さない」判断はどう生まれたか 「LOCAL RESEARCH LAB 中津川」の立ち上げと産学官横断での街のアクティベーション 風の人・土の人 - 組織にリサーチを根付かせる 組織にリサーチを根付かせる、技術よりも大切な「土着」の視点 まとめ - 自チームとの重なり 終わりに 会場の様子 入口 ランチと過去5年のリサーチカンファレンスの歩みを振り返れるZINE 今回響いた2つのキーワード 2026年のテーマは「WEAVING（織る）」でした。 年々リサーチに求められることは多様で高度になり、一つの専門性や視点だけでは抱えきれなくなっています。この状況において、私たちは異なる特徴をもつ人や役割を「織る」ことに可能性があると考えました。 そのため、リサーチに関わる人たちの関係性に着目するセッションが多かったです。 複数のセッションを聴いた中で、特に印象に残ったのが「共体験」と「風の人・土の人」という2つのキーワードでした。 どちらも、支援者として組織に伴走し、リサーチの価値を届けようとしている自分たちのチームに深く通じるテーマです。 特に印象に残っている3セッションをご紹介します。 共体験 - 一緒にやるから深くわかる モンスト海外展開のリサーチ：「そのまま出さない」判断はどう生まれたか 登壇：島崎 顕北 氏・古藤 拓実 氏（株式会社MIXI） 島崎氏・古藤氏からは、モンストのグローバル版「STRIKE WORLD」の開発プロセスが語られました。 印象的だったのは、単なる翻訳ローカライズではなく「再構築」するという判断に至った経緯です。 14名の多様な立場のメンバーが現地に赴き、プレイテストを実施しました。 ここでのポイントは、リサーチャーだけが現地を見るのではなく、エンジニアやプロデューサーを含む全員で「その場の空気を共有する」ことを最優先にした設計だったという点です。 市場調査の数字からではなく、ともに体験したからこそ見えた発見がありました。たとえば「引っ張る動作が海外ユーザーには直感的に伝わらない」という想定外のインサイト。机上のデータ分析では到達しにくい気付きが、共体験によって生まれていたのです。 ステークホルダーと同じ体験をしたうえで目線を合わせながら開発へ反映していくプロセスは、「リサーチ結果をレポートで伝える」モデルとはまったく異なる説得力を持っていました。 「LOCAL RESEARCH LAB 中津川」の立ち上げと産学官横断での街のアクティベーション 登壇：牛丸 維人 氏（株式会社KESIKI）・吉澤 克哉 氏（東海旅客鉄道株式会社） もう一つ「共体験」の力を感じたのが、JR東海グループ × KESIKI × 岐阜県中津川市による協働プロジェクトです。 旧中山道の宿場町というフィールドで、地域内外の多様な参加者を「ラボメンバー」として募集し、コ・フィールドリサーチ（共同でのフィールドリサーチ）を実施。人類学・デザイン・まちづくりの知見を横断的に応用した「共創」がプロジェクトの核になっていました。 このセッションで特に響いたのは、「ともにリサーチすることで深い理解が生まれ、仲間になることでアイデアの実装につながる」というメッセージです。 リサーチの成果物がレポートではなく「関係性」であり、その関係性が具体的なアクションを生み出す。実際に多数のコミュニティが生まれ、まちづくりを支える動きが創出されていたそうです。 風の人・土の人 - 組織にリサーチを根付かせる 組織にリサーチを根付かせる、技術よりも大切な「土着」の視点 登壇：福島 麻衣 氏（株式会社Muture） 福島氏のセッションでは、デザイン会社として外からインサイトを持ち込む立場と、中で組織に伴走する立場の両方を経験してきた知見が語られました。 ここで紹介されたメタファが「風の人」と「土の人」です。 風の人 ：異文化や革新的な技術を外部から導入する役割を担う存在 土の人 ：地域や組織の特性を深く理解し、基盤を整える存在 新しいものへの感度が鋭いリサーチャーは、往々にして「風」の役割を持ちます。しかし風は土壌を理解しないと、持続的な変化をもたらせません。リサーチの技術やメソッドの前に、その組織固有の文化や慣習を深く理解し尊重することが土台になるという主張でした。 土の人を理解することで得られるものとして、以下の3つが挙げられていました。 価値を感じてもらいやすい方法がわかる 風を吹かせるタイミングが見える 信頼が生まれる セッションの後半では、実践している パターン・ランゲージ も紹介され、具体的な実践知として持ち帰れる内容でした。 まとめ - 自チームとの重なり 2つのテーマに通底していたのは、「関係性を築くことでリサーチの価値が生まれる」という考え方です。 私たちはインハウスのリサーチチームではありますが、横断部署として各事業部を支援する立場にいます。 つまり、新しいプロジェクトに入るときは「風」として入ることが多いです。 だからこそ、土の人を理解し、ともに体験するプロセスを丁寧に踏むことで、支援が一時的なもので終わらず組織に根付いていくことに繋がると思います。 またステークホルダーとのユーザー観察の共体験も実践している部分があるので重要性を再認識しました。 今回のカンファレンスで得た2つのキーワードは、自分たちのチームがこれから目指す方向をあらためて言語化してくれたように感じました。 明日からの支援の現場で、意識を変えて動いていこうと考えるきっかけになりました。 終わりに 今回 LIFULL はポスターセッションで登壇しました。 そのポスターの紹介は別記事で行う予定です。ご期待ください！ LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co

Kibanaのダッシュボードで、標準の「Lens」では表現できない複雑なチャート（サンキーチャートやカスタムマップ、特殊な散布図など）を作りたいとき、強力な武器になるのが  Vega / Vega-Lite  です。 しかし、これまでは重厚な Elasticsearch の Query DSL（JSON）を手書きしてデータを集計する必要があり、記述の複雑さに頭を悩ませた方も多いのではないでしょうか？ そんな開発者・アナリストに朗報です。バージョン 9.4+（Serverless Stack）以降、直感的で強力な新しいクエリ言語  ES|QL（Elasticsearch Query Language）  を Vega のデータソースとして直接利用できるようになりました！ 今回は、この  ES|QL × Vega  の組み合わせがもたらすメリットと、具体的な実装方法をコード例付きで解説します。 目次 なぜ ES|QL × Vega なのか？ 3つのメリット 1. 複雑な Query DSL からの解放 2. データ形式の自動変換 3. ダッシュボードの「時間範囲」や「フィルター」と完全同期 ES|QL を呼び出すための設定パラメータ Vega / Vega-Lite を使った Visualization の作成手順 【実践】サンプルコードで見る実装例1：折れ線グラフ（Vega-Lite） 💡 コードの解説 🖼️ 実行結果 【実践】サンプルコードで見る実装例2：時間帯×日付のヒートマップ（Vega-Lite） 💡 コードの解説 🖼️ 実行結果 まとめ：データ分析と表現の幅を広げよう なぜ ES|QL × Vega なのか？ 3つのメリット 1. 複雑な Query DSL からの解放 パイプライン演算子（  |  ）を使ってデータを段階的に加工できる ES|QL を使うことで、ネストの深い Elasticsearch 独自の集計クエリを書く必要がなくなります。クエリの可読性が劇的に向上します。 2. データ形式の自動変換 ES|QL のクエリ結果は本来「列指向（Columnar）」ですが、Kibana の Vega インテグレーターが自動的に  Vega が期待する「行ベース（Row-based / 1行1オブジェクト）」のJSON形式へ変換  してくれます。手動でのパース処理（  format.property  などの指定）の手間が大幅に減ります。 3. ダッシュボードの「時間範囲」や「フィルター」と完全同期 Kibana の拡張トークンを利用することで、ユーザーがダッシュボード上で操作した時間フィルターや検索条件を、ES|QL クエリ内に動的にマッピングできます。 ES|QL を呼び出すための設定パラメータ Vega の  data.url  オブジェクト内に以下のパラメータを指定することで、ES|QL モードが有効になります。 パラメータ 必須/任意 概要 "%type%" 必須 "esql"  を指定します。 "query" 必須 実行したい ES|QL （1行で書く） "%context%" 任意 true  に設定すると、ダッシュボードのグローバルフィルターがクエリに自動適用されます。 "%timefield%" 任意 タイムスタンプのフィールド名を指定。これを設定すると、クエリ内で名前付きパラメータ  ?_tstart  と  ?_tend  が利用可能になります（ダッシュボードの時間範囲が代入されます）。 "dropNullColumns" 任意 true  （デフォルト）の場合、null 値しか含まれない列をレスポンスから自動で除外します。 "params" 任意 クエリに動的に代入したい名前付きパラメータの配列を指定します。 Vega / Vega-Lite を使った Visualization の作成手順 Kibanaにおけるカスタム可視化の作成手順は以下の通りです（従来通り）。 1: Dashboard を新規作成するか、既存の Dashboard を編集モードにします。 2: 右上の [Add panel] プルダウンメニューから [New panel] を選択します。 3: パネル選択画面から [</> Custom visualization] を選択します。 4: Vega / Vega-Lite の作成画面が表示されるので、右側のエディタに JSON を記述していきます。 5: デバッグしたい場合は、上部の Inspect をクリックしてください。 【実践】サンプルコードで見る実装例1：折れ線グラフ（Vega-Lite） 以下は、サンプルデータ（Webログ）を使用し、時間の経過に伴うイベント数を2時間おきに集計して折れ線グラフ（Line Chart）で描画する Vega-Lite (v6) の定義例です。 { "$schema": "https://vega.github.io/schema/vega-lite/v6.json", "title": "Event counts per 2 hours", "data": { "url": { "%type%": "esql", "%context%": true, "%timefield%": "@timestamp", "query": "FROM kibana_sample_data_logs | WHERE @timestamp >= ?_tstart AND @timestamp < ?_tend | STATS doc_count=COUNT() BY tbucket=TBUCKET(2 hour) | SORT tbucket" } }, "mark": "line", "encoding": { "x": { "field": "tbucket", "type": "temporal", "axis": { "title": false } }, "y": { "field": "doc_count", "type": "quantitative", "axis": { "title": "Document count" } } } } 💡 コードの解説 ** %timefield%: "@timestamp"  と  ?_tstart  /  ?_tend** ES|QL クエリ内の  WHERE @timestamp >= ?_tstart AND @timestamp < ?_tend  に注目してください。これにより、Kibana ダッシュボードの右上にある時間セレクター（例: 「過去24時間」など）の範囲が、自動的にこのプレースホルダーに流し込まれます。 STATS ... BY tbucket=TBUCKET(...) ES|QL の強力な関数  TBUCKET  を使い、2時間ごとのバケットに丸めてカウント（  COUNT()  ）しています。従来の Query DSL で  date_histogram  アグリゲーションを書くよりも圧倒的にシンプルです。 mark : "line" "mark": "line"  を指定することで、集計データを折れ線グラフとして描画するよう指示しています。 encoding  セクション ES|QL で集計した結果の列名（  tbucket  と  doc_count  ）が、そのまま Vega-Lite の  field  として直感的にマッピングされているのがわかります。 🖼️ 実行結果 【実践】サンプルコードで見る実装例2：時間帯×日付のヒートマップ（Vega-Lite） 次に、1時間ごとのイベント数を「曜日や日付×時間帯」のマトリクスで可視化し、アクセスの時間帯トレンドを一目で把握できるヒートマップ（パンチカード）の例をご紹介します。 { "$schema": "https://vega.github.io/schema/vega-lite/v6.json", "title": "kibana_sample_data_logs 内の時間ごとのログ数", "data": { "url": { "%type%": "esql", "%context%": true, "%timefield%": "@timestamp", "query": "FROM kibana_sample_data_logs | WHERE @timestamp >= ?_tstart AND @timestamp < ?_tend | STATS count=COUNT() BY datetime=TBUCKET(1 hour) | LIMIT 10000 | SORT datetime" } }, "config": { "view": { "strokeWidth": 0, "step": 13 }, "axis": { "domain": false } }, "mark": "rect", "encoding": { "x": { "field": "datetime", "timeUnit": "hours", "type": "ordinal", "title": "時" }, "y": { "field": "datetime", "timeUnit": "date", "type": "ordinal", "title": "日" }, "color": { "field": "count", "type": "quantitative", "legend": { "title": "カウント" } } } } 💡 コードの解説 mark : "rect"によるグリッド描画 Vega-Lite でヒートマップを作る際は、タイル（四角形）を描画する  "rect"  マークを使用します。 timeUnit を使った「時」と「日」の切り出し ES|QL 側からは  TBUCKET(1 hour)  で丸められた一連のタイムスタンプが返ってきます。それを Vega-Lite 側の  timeUnit  プロパティを使って、X軸には「時（hours）」、Y軸には「日（date）」として切り出してマッピングしています。これにより、複雑なクエリを書くことなく、フロントエンド側で綺麗な2次元マトリクスを表現できます。 color による密度の可視化 集計したイベント数（  count  ）を  color  の  quantitative （量的データ）として指定することで、ログ件数に応じた色の濃淡が自動的に適用されます。 🖼️ 実行結果 まとめ：データ分析と表現の幅を広げよう これまでの Kibana カスタム可視化は、「Query DSL が難解で手が出せない」というエンジニアも多かったかと思います。しかし、ES|QL の登場によって、SQL ライクな直感的な記述でバックエンドのデータを引き出し、Vega の表現力をフルに活かせるようになりました。 ダッシュボードの表現力をもう一段階引き上げたい方は、ぜひ公式ドキュメントの  Custom visualizations with Vega | Elastic Docs  を参考に、ES|QL × Vega の強力なタッグを試してみてください！ その他の参考URL Kibana dashboards improvements | Elastic Search Labs Vega公式 Vega-Lite公式 The post Kibanaの新定番！ES|QL と Vega を組み合わせて自由自在なカスタム可視化を実現する first appeared on Elastic Portal .