2026年2月の主な製品アップデートをご紹介します。 製品アップデート Global Fieldsでプロジェクト間のフィールドを標準化 これまでプロジェクトごとに個別に作成していたフィールドを、アカウントレベルで定義できるようになりました。 Global Fieldsを利用することで、複数のプロジェクトにわたってフィールド構造を統一できるほか、重複したカスタムフィールドの作成を防ぎ、運用やメンテナンスの負担を軽減できます。 また、現在ベータ版として提供されている社内のMigration Toolを使用すれば、既存のプロジェクト単位のフィールドをGlobal Fieldsへ移行することも可能です。詳しくは ドキュメント をご覧ください。 ログイン後すぐに必要な情報へアクセスできる新しいランディングページ PractiTestのランディングページを刷新し、ログイン直後に重要な情報へすばやくアクセスできるようになりました。 新しいレイアウトでは、プロジェクト一覧、「Assigned to Me（自分に割り当てられた項目）」、最近のアクティビティをすぐに確認できます。 さらに、プロダクトのアップデート情報やライブトレーニングなどの主要リソースにも簡単にアクセスできます。 今後の予定 PractiTestライブトレーニング カスタマーサクセスチームによるライブトレーニングセッションを開催します。製品の使い方や活用方法について、疑問点を直接質問できる機会です。 ヨーロッパ：3月4日（水）14:00（CET） 北米：3月25日（水）15:00（EDT） / 12:00（PDT） アジア太平洋：3月11日（水）16:00（AEDT） ライブトレーニングに申し込む LLMのセキュリティ対策：OWASPガイドから学ぶ Maryia Tuleikaによるゲストウェビナー AIシステムはブラックボックスのように見えることがありますが、適切にテストを行うことで実際の脆弱性が明らかになります。 本セッションではMaryia Tuleikaが登壇し、OWASPの原則をLLMを活用したアプリケーションにどのように適用できるのかを解説します。 さらに、従来のテストスキルを活用して、プロンプトインジェクション、データ漏えい、不十分な安全対策といったリスクをどのように発見できるのかを実践的に紹介します。 参加登録はこちら PractiTestとその先へ オンデマンド配信：Orchestrate AI for Testing 先日開催されたMCPに関するウェビナーを見逃した方も、現在はオンデマンドで「Orchestrate AI for Testing」を視聴できます。 このセッションでは、Joel MontveliskyがPractiTestのMCPアプローチを紹介し、AIツールが実際のテストコンテキストと連携して動作する仕組みを解説しています。 AIを単なる個別のプロンプトツールではなく、テストプロセスと連携したアシスタントとして活用する方法を学べます。 録画を視聴する 2026年にQAテスターに求められる5つの必須スキル 「第13回 State of Testing レポート」の調査結果をもとに、AIがQA分野にどのような変化をもたらしているのか、そしてテスターに求められるスキルがどのように変化しているのかを解説した記事です。 批判的思考、オートメーションの基本原則、コミュニケーション能力など、2026年に重要となる5つのスキルを紹介しながら、テスターが単なる実行担当から品質の意思決定に関わる存在へと進化していく姿を描いています。 ブログを読む

はじめに こんにちは。開発本部 開発1部 デリッシュリサーチチームの 江﨑 です。 本記事では、これまでHive Metastore上のDeltaテーブルで管理していたデリッシュリサーチ用データ（約40テーブル）をUnity Catalogへ移行したプロジェクトの全体像を、インフラ整備からAthena連携・Databricks Managed MCP活用まで紹介します。 はじめに 背景：なぜ Unity Catalog に移行したか 課題 1：テーブルスキーマが「コードを読まないと分からない」 課題 2：データリネージを Mermaid で管理していた Unity Catalog とは マネージドテーブル vs 外部テーブル 移行手順の全体像 Step 1：インフラ整備 IAMロールの設定 Catalogの作成 Step 2：Unity Catalog テーブルの作成 移行スクリプトの流れ Step 3：既存 ETL コードの変更 主な変更：テーブル参照パスの書き換え Step 4：Athena から Unity Catalog のデータを参照する 実際に行った変更 Step 5：Quick Suite のデータセット移行 移行結果 Before / After Before（Hive Metastore 時代） After（Unity Catalog 移行後） Databricks Managed MCP Databricks Managed MCP とは DBSQL MCP：ETL 開発が変わる 具体的な開発体験 まとめ 背景：なぜ Unity Catalog に移行したか 移行前、デリッシュリサーチではDatabricksのHive Metastore上で約40個のDeltaテーブルを運用していました。その中で、運用上の課題が積み重なってきていました。 課題 1：テーブルスキーマが「コードを読まないと分からない」 「このテーブルに user_id カラムってあったっけ？」という確認をするたびに、Notebookを開いて display(spark.table("schema.table")) を実行するか、ETLコードを読み返す必要がありました。テーブルが増えるほど、この手間もかさんでいきます。 課題 2：データリネージを Mermaid で管理していた テーブル間の依存関係（「このテーブルはどのテーブルから作られているか」）をMermaidのコードで手作業管理していましたが、40テーブルを超えると複雑すぎてメンテナンスが限界になり放置されていました。テーブルを追加するたびにMermaidを手で更新する運用は、明らかにスケールしません。 これらの課題を解消するためにUnity Catalogへの移行を決めました。 Unity Catalog とは Unity CatalogはDatabricksの統合データガバナンスソリューションです。Hive Metastoreとの最大の違いは、 三層の名前空間（Catalog > Schema > Table） を持つ点です。 Catalog（例: marketing_research） └── Schema（例: search） └── Table（例: search_count） Hive Metastoreでは schema.table の二層構造でしたが、Unity Catalogでは catalog.schema.table の三層になります。この変更によって、チームやプロジェクトを跨いだデータの整理がしやすくなります。 主な機能は以下の3点です： データカタログ ：テーブルのスキーマ・カラムの説明文をUI上で管理・参照できる データリネージ ：データの流れ（どのテーブルがどのテーブルを参照しているか）を自動追跡・可視化 アクセス制御 ：行・列レベルの細粒度なセキュリティ設定 Unity Catalogのオブジェクト階層。今回の移行ではCatalog > Schema > Tableの三層構造を利用。（出典: Databricks公式ドキュメント ） Unity CatalogのUI。テーブルを選択するとカラム名・データ型・コメントを一覧で確認できる。 マネージドテーブル vs 外部テーブル Unity Catalogへの移行を検討するとき、決めなければならないのが テーブルタイプ です。 観点 マネージドテーブル 外部テーブル データ保管場所 Unity Catalogが管理するパス 任意のストレージパス（S3など） S3パスの形式 自動生成されたID形式になる 任意のS3パスを指定できる テーブル削除時 データも削除される データは残る Databricksの推奨 ほとんどのユースケース 既存ストレージとの互換性が必要な場合 Databricksはマネージドテーブルを推奨していますが、本プロジェクトでは 外部テーブル を選択しました。 その理由は、データ参照構成にあります。デリッシュリサーチではダッシュボードを Amazon Quick Suite(以下Quick Suite) → Athena → Glue Crawler → S3 という構成で構築しています。Glue Crawlerはクロール先のS3パスを読み取ってテーブル名を付与します。 ここで問題になるのが、マネージドテーブルのS3パス形式です。マネージドテーブルに移行すると、S3パスは s3://unity-catalog-metastore/__unitystorage/... のような __unitystorage 配下のシステム管理ディレクトリ（ランダム生成IDを含むパス） に配置されます。Glue CrawlerはS3プレフィックス/フォルダ名ベースでテーブル名を付けるため、Athena側のテーブル名が人間可読でない名前になり、現実的な運用が難しくなります。 外部テーブルであればS3パスを s3://<バケット名>/table_name のようにテーブル名ベースで保持できるため、Athena上のテーブル名が人間にとって分かりやすい名前のままになり、移行コストを抑えつつ今後の管理も楽になります。 移行手順の全体像 移行は以下の5ステップで実施しました。 Step 1 ：インフラ整備（IAM・Catalogの作成） Step 2 ：Unity Catalogテーブルの作成 Step 3 ：既存ETLコードの変更（テーブル参照パスの更新） Step 4 ：AthenaからUnity Catalogのデータを参照できるようにする Step 5 ：Quick Suiteのデータセット移行 Step 1：インフラ整備 Unity Catalogを有効化するにあたって、AWS・Databricks側でいくつかの設定が必要でした。 IAMロールの設定 DatabricksがS3バケットにアクセスするためのIAMロールと、それをDatabricks側に登録するストレージクレデンシャルを新規作成しました。インフラ変更はTerraformで管理しています。概念的には以下のような構成です。 resource "aws_iam_role" "databricks_unity_catalog" { name = "<ロール名>" assume_role_policy = jsonencode ( { Statement = [{ Effect = "Allow" Principal = { AWS = "arn:aws:iam::<Databricks の AWS アカウント ID>:role/unity-catalog-prod-role" } Action = "sts:AssumeRole" Condition = { StringEquals = { "sts:ExternalId" = <databricks_sts_external_id> } } }] } ) } Catalogの作成 Unity Catalogを利用するには、Databricks上にCatalogを作成する必要があります。Catalog作成時のmanaged storage location指定は任意ですが、今回は運用上の理由から指定のS3バケットをmanaged storage locationとして指定しました。 参照： Unity Catalog の Catalog を作成する（Databricks 公式ドキュメント） Step 2：Unity Catalog テーブルの作成 インフラが整ったら、既存のHive MetastoreテーブルのデータをUnity Catalogの外部テーブルとして再作成します。旧パスから schema/table というパス構成に移行するため、CTAS（CREATE TABLE AS SELECT）を使いました。 移行スクリプトの流れ 旧パスのDeltaテーブルを SELECT * で読み取る schema/table 形式のパスにDelta形式で書き込みながらUnity Catalogの外部テーブルを作成 # 旧 Delta からデータをコピーしながら UC 外部テーブルを作成 spark.sql(f """ CREATE TABLE IF NOT EXISTS {catalog}.{schema}.{table_name} USING DELTA LOCATION '{new_s3_path}' AS SELECT * FROM delta.`{old_s3_path}` """ ) Step 3：既存 ETL コードの変更 主な変更：テーブル参照パスの書き換え Hive MetastoreではS3パスを直接指定してデータを読み書きしていましたが、Unity Catalogでは catalog.schema.table の三層構造で参照するよう書き換えました。 # Before（Hive Metastore）：S3 パスを直接指定 df = spark.read.format( "delta" ).load( "s3://path/to/delta" ) df.write.format( "delta" ).save( "s3://path/to/delta" ) # After（Unity Catalog）：カタログ名で参照 df = spark.table( "catalog.schema.table" ) df.write.saveAsTable( "catalog.schema.table" ) Step 4：Athena から Unity Catalog のデータを参照する 前述の通り、Quick Suiteのデータソースは Athena → Glue Crawler → S3 という構成です。Unity Catalogに移行しても、この構成を維持する必要があります。 実際に行った変更 Glue Crawlerのクロール先を、Unity Catalog外部テーブルのS3パスに変更しました。 Before： 旧 S3 バケット（Hive Metastore 用）→ Glue Crawler → Athena After： Unity Catalog 外部テーブルの S3 バケット → Glue Crawler → Athena 具体的な変更内容： Glue Crawlerのクロール先S3パスをUnity Catalog外部テーブルのパスに変更 GlueのIAMポリシーにS3バケットへのアクセス権限を追加 Terraformで管理しているIAMポリシーとGlueリソースを更新し、 terraform apply 後にGlueコンソールからクローラーを手動実行してテーブルが正しく作成されることを確認しました。 Step 5：Quick Suite のデータセット移行 Step 4でGlue → Athena側の変更が完了したら、Quick Suiteのデータセット参照先を新しいAthenaテーブルに切り替えます。 変更自体はQuick SuiteのUIから接続設定を変更するだけで完結しますが、切り替え前に テーブルスキーマの互換性確認 が重要です。カラム名・データ型が一致していないと、ダッシュボードの集計が壊れます。 移行結果 Before / After 移行の成果をBefore / Afterでまとめます。 Before（Hive Metastore 時代） 項目 状態 テーブルスキーマ確認 Notebookを実行するかコードを読む必要がある データリネージ Mermaidで手作業管理 After（Unity Catalog 移行後） 項目 状態 テーブルスキーマ確認 Unity CatalogのUIでカラム一覧・データ型・説明文を即時参照 データリネージ UI上で自動生成・可視化（Mermaidでの手作業管理が不要に） 特にデータリネージの自動可視化は、Mermaidの維持コストをゼロにしてくれる大きな恩恵でした。Unity CatalogにETLジョブが書き込むと、どのテーブルがどのテーブルから作られているかが自動でグラフとして記録されていきます。 Unity Catalogのデータリネージ画面。どのテーブルがどのテーブルから作られているかが自動でグラフ表示される。 Databricks Managed MCP Unity Catalogへの移行をきっかけに、Databricks Managed MCPも使えるようになったので紹介します。 Databricks Managed MCP とは Databricks Managed MCPとは、DatabricksがホストするMCP（Model Context Protocol）サーバーです。Claude CodeなどのAIエージェントからDatabricksのリソースをツールとして呼び出せるようにする仕組みです。 Databricks Managed MCPはUnity Catalogとの統合を前提に設計 されています。今回の移行後、実際に使えるようになりました。 DBSQL MCP：ETL 開発が変わる Databricks Managed MCPの中でも、ETL開発が中心のデリッシュリサーチにとって特に相性が良さそうだと感じたのが DBSQL MCP です。これはClaude CodeやCursorのMCPとして設定することで、ETL開発中にSQLをその場で実行・確認できるようになるツールです。 提供されるツール： execute_sql_read_only ：テーブルの内容・カラム定義・データ分布をその場で確認 execute_sql ：SQLの実行 poll_sql_result ：長時間クエリの結果をポーリング ※ ツール名や提供機能はアップデートで変更される可能性があります。上記は執筆時点（2026年3月6日）で使用できるツールです。 具体的な開発体験 ETLコードを書きながら、Claude Codeに対して次のような依頼ができるようになります： 「 catalog.schema.table のカラム構成を確認して」 「 product_id カラムのユニーク数を調べて」 「このテーブルとJOINするテーブルのスキーマを見せて」 DBSQL MCPを使うことでCursorやVS CodeなどのエディタからDatabricksのテーブルの中身・スキーマをリアルタイムで確認しながらコーディングができます。 なお、DBSQL MCP以外にもUnity Catalog functionsやGenie spaceなども使えるようになっています。 参照： Databricks Managed MCP 公式ドキュメント MCPの詳細な設定方法や活用例については、 こちらの記事 も参照してください。 まとめ 約40テーブルのHive Metastore → Unity Catalog移行を通じて得た主な成果を3点でまとめます。 データカタログとデータリネージの整備 ：Unity CatalogのUIでスキーマ情報を参照でき、データリネージも自動管理されるため、「コードを読まないと分からない」問題が解消されました 外部テーブルで構成互換性を維持 ：Athena連携（Glue Crawler）がある場合は外部テーブルを選ぶことで、既存のBI構成に影響を与えずに移行できました Databricks Managed MCPが使えるようになった ：ETL開発中にエディタから出ずにテーブル情報を確認できるようになり、開発体験が向上しました 今後は、Unity Catalogへの移行によって使えるようになった機能の検証・活用をしていきたいと考えています。 Unity Catalogへの移行を検討している方の参考になれば幸いです。

2025 年 12 月 15 日に AWS Startup Loft Tokyo (目黒) で開催された「 Amazon Q Developer & Kiro Meetup #5: AWS re:Invent アップデート速報 & お客様の活用事例紹介 」のイベントの様子をレポートします。 登壇資料は こちらからダウンロード (zip) していただけます。 このイベントは、AWS re:Invent 2025 でアップデートのあった Kiro の機能紹介と、お客様による Amazon Q Developer / Kiroの実践活用事例をテーマに実施しました。まずソリューションアーキテクトの稲田から Kiro の概要と AWS re:Invent 2025 前後で発表されたアップデートをご紹介しました。続いて、株式会社ゼンリンデータコム様、株式会社NTTドコモ様から Amazon Q Developer / Kiro の社内展開や活用方法の事例を共有していただきました。最後に株式会社リクルート様に AI-DLC の導入状況について発表していただきました。 参加者の方からは「各社の取り組み、AIに対する考えを知ることができ非常に有意義でした。」などのご感想をいただきました。現地参加の方のみ、ケータリングをご用意し、ネットワーキングのための懇親会を実施しました。 登壇者の方への質問や、参加者同士の意見交換、AWS メンバーへの相談が活発におこなわれていました。 イベント概要 開催日時: 2025年12月15日 19:00- 会場: AWS Startup Loft Tokyo (目黒)、オンライン配信 スピーカー 株式会社ゼンリンデータコム様「Amazon Q Developer の組織展開 ～IAM IdC × ルールファイルで実現する標準化と統制～」 株式会社 NTT ドコモ様「NTT ドコモにおける Amazon Q Developer 活用事例の紹介」 株式会社リクルート様「AI-DLC を現場にインストールしてみた：プロトタイプ開発で分かったこと・やめたこと」 ソリューションアーキテクト 稲田 大陸 Amazon Web Services Japan G.K. 「Amazon Q Developer および Kiro のAWS re:Invent のアップデート」 乾杯の挨拶: 事業開発マネージャー　井形 健太郎 Amazon Q Developer および Kiro の AWS re:Invent のアップデート スピーカー: ソリューションアーキテクト 稲田 大陸, Amazon Web Services Japan G.K. はじめに、ソリューションアーキテクトの稲田より、AWS re:Invent 2025 前後の Amazon Q Developer / Kiro のアップデート情報をご紹介しました。 AWS Japan 独自の Blog 連載イベント「 Kiroweeeeeeek in Japan 」をご案内し、Kiro の概要や Kiro がガイドする仕様駆動開発 (Spec Driven Development) についてもご説明しました。Kiro のアップデート情報として、GA (一般提供開始) や Kiro for Enterprise の提供開始、チェックポイントやプロパティベーステストの導入、Kiro CLI の提供開始をご紹介しました。 さらに、AWS が提供する フロンティアエージェント の一つである Kiro Autonomous Agent が生まれた背景や特徴についてご説明しました。Kiro powers といった新機能や新しい料金体系についてもご紹介しました。 株式会社ゼンリンデータコム様「Amazon Q Developer の組織展開 ～IAM IdC × ルールファイルで実現する標準化と統制～」 株式会社ゼンリンデータコム様からは、「Amazon Q Developer の組織展開 ～IAM IdC × ルールファイルで実現する標準化と統制～」と題して AWS 環境の管理業務に対する Amazon Q Developer / Kiro の活用と、全社展開における取り組みについて発表していただきました。 社内展開にあたって実施した、AWS IAM Identity Center によるマルチアカウント環境でのユーザ管理や、役割ベースの権限セットへの集約といった工夫についてお話しいただきました。さらに、利用者ごとのスキル差や誤操作リスクの緩和のための、独自のルールファイルを作成によるプロンプト入力の簡素化や MCP サーバーの利用についてもご説明いただきました。 Kiro CLI のカスタムエージェント の活用による AWS 環境管理業務の効率化の取り組みについてもご紹介いただきました。 株式会社 NTT ドコモ様「NTT ドコモにおける Amazon Q Developer 活用事例の紹介」 株式会社 NTT ドコモ様からは、「NTT ドコモにおける Amazon Q Developer 活用事例の紹介」と題して、社内の主要 Web サービス提供基盤「POPLAR」開発における Amazon Q Developer の活用状況と利用上の工夫について発表していただきました。 まず Amazon Q Developer 採用に至る経緯についてお話しいただき、活用状況として設計・実装・テスト・運用各フェーズにおける利用状況や品質・効率面での成果についてご共有いただきました。また、POPLAR の開発における Amazon Q Developer の組織的な活用のための取り組みについて利用ガイドラインの策定・周知や利用状況の可視化といった具体例を挙げてご説明いただきました。最後に、Kiro の採用も含めた今後の展望についてご紹介いただきました。 POPLAR における Amazon Q Developer の活用状況の詳細については AWS ブログ 「 NTTドコモの Web サービス基盤『 POPLAR 』開発における Amazon Q Developer 活用 」もぜひご覧ください。 株式会社リクルート様「AI-DLC を現場にインストールしてみた：プロトタイプ開発で分かったこと・やめたこと」 株式会社リクルート様からは、「AI-DLCを現場にインストールしてみた：プロトタイプ開発で分かったこと･やめたこと」と題して、AI を最大限ソフトウェア開発に活用する手法として提唱されている AI-DLC (AI-Driven Development Lifecycle, AI 駆動開発ライフサイクル) の活用状況について発表していただきました。 まずソフトウェア開発フェーズやタスクの計画を AI で作成する、検討内容は AI でドキュメント化する、AI の成果物は人間がレビューし、必要に応じて AI との質疑応答を取り入れる、などのテクニックについておさらいとしてご説明いただきました。 AI-DLC を実プロジェクトに取り入れる上での各フェーズでの流れやプロンプト、アウトプットの例をご紹介いただきました。最後に AI-DLC の採用に向いているプロジェクトの要素として、求められる品質やリードタイム、既存のインプット、チームの状況といった観点からそれぞれご説明いただきました。 株式会社リクルート様の登壇資料は「 AI-DLCを現場にインストールしてみた：プロトタイプ開発で分かったこと･やめたこと 」からご覧いただけます。 AI-DLC の詳細については過去の開催報告 「 [資料公開 & 開催報告] Amazon Q Developer Meetup #3 を開催しました 」 や、AWS ブログ 「 AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 」 をご覧ください。 おわりに 今回の Amazon Q Developer & Kiro Meetup #5 では、AWS re:Invent 2025 でアップデートのあった Kiro の機能紹介と、お客様による Amazon Q Developer / Kiroの実践活用事例をテーマとして開催させていただきました。株式会社ゼンリンデータコム様、株式会社NTTドコモ様、株式会社リクルート様にご登壇いただき、各社での取り組みや工夫、得られた知見についてお話しいただきました。 今後も、開発者の皆様が生成 AI をより有効に活用していただくための AI-DLC をはじめとしたプラクティスや Amazon Q Developer や Kiro といったツールについて発信・アップデートをお届けします。 筆者 yamazaki hiroki profile-20250806 山崎 宏紀 (Hiroki Yamazaki) 山崎宏紀 は Amazon Web Services Japan G.K. のソリューションアーキテクトとして、ISV/SaaS 業界のお客様を中心にアーキテクチャ設計や構築、生成 AI の活用・AI エージェントの開発をご支援しています。Kiro CLI や AWS CDK を好みます。(より良いご支援のために) AI エージェントに代わりに働いてもらおうと画策しています。