はじめに こんにちは、ZOZOTOWN開発2部Androidブロックの小林（ @kako_351 ）です。普段はZOZOTOWN Androidアプリの開発を担当しています。ZOZOTOWN Androidでは、チーム内の運用でさまざまな作業を自動化しています。最近はリリース準備を、Jira AutomationとGitHub Actionsの組み合わせで自動化しました。本記事では、その仕組みと実装を紹介します。 目次 はじめに 目次 背景・課題 改善前の運用 ブランチ運用の整理 改善後の全体構成 GitHub ActionsによるリリースPRの自動作成 Jira REST APIの準備 ブランチ作成 バージョン更新 PR作成 PRの説明欄に記載する本文生成 PRへラベル付与 マージの対象案件メンバーへSlack通知 Jira AutomationからのGitHub Actions実行 GitHub Actions REST APIの準備 トリガー設定 入力値の設定 ブランチ名の自動生成 REST APIでGitHub Actionsを起動 改善後の実行イメージ まとめ 背景・課題 ZOZOTOWN Androidでは、QAチームへテスト対象のアプリを配布する前に、チーム内で次のリリース内容を確認しています。配布担当者はそれまでにリリース用ブランチを用意し、対象案件をマージできる状態にしておく必要があります。 この運用面での課題が2つありました。 1つは所要時間が人によって大きく違ったことです。配布担当はリリースごとに入れ替わるため、担当が回ってくるのは数ヶ月に一度ということもありました。リリース準備は工程が多いうえ、配布パターンによって使うブランチが変わります。記憶だけを頼りに進めるのが難しいときもあり、毎回マニュアルを確認するところから作業が始まっていました。PRやSlackのタイムスタンプを振り返ると、リリース準備にかかる実作業時間は、担当者によって15分程度から1時間程度まで開きがありました。もう1つは、準備が遅れると対象案件のマージがチーム内での確認の直前になることです。マージ先のブランチが存在しないため、担当者の作業タイミングがそのままリードタイムに響いていました。 改善前の運用 まずは改善前の運用を説明します。おおむね以下のようなリリースフローです。 QAはQAチームが行い、他の工程はZOZOTOWN Androidチームが行う リリース準備 チーム内で配布前確認（次のリリース内容をチーム内で確認する工程） QAチームへ配布 QA リリース 本記事では、このうち1のリリース準備を自動化した内容を紹介します。リリース準備には以下の工程が含まれており、すべて手動で行っていました。 すべて手動で行っていたリリース準備の工程 ブランチ作成 バージョン更新 リリース用PR作成 PRの説明欄に記載する本文生成 バージョンに含める案件内容を収集 ラベル付与 マージの対象案件メンバーへSlack通知 これらの作業は配布担当者が行います。担当するのは、そのリリースに含まれる案件のうち重要度の高い案件の実装者です。そのため担当は毎回入れ替わり、上記工程にも時間を要していました。一方でこの工程は標準化されていたため、自動化しやすい部分でした。 ブランチ運用の整理 自動化する上で考慮すべき点は、ブランチ運用です。hotfixや複数バージョンの同日配布といった、通常とは異なる配布パターンにも対応する必要があったためです。前提としてZOZOTOWN AndroidではGit-flowに近い形でブランチ運用をしています。 イメージとしては、Git-flowのdevelopブランチとreleaseブランチの役割を入れ替えたような運用です。配布前確認までにreleaseブランチへ各案件のfeatureブランチをマージし、QAチームへの配布時点でreleaseブランチをdevelopブランチへマージします。 Git-flowを一部カスタマイズした運用 配布のパターンとしては以下の3つが存在します。 通常 毎週の定例リリースをスケジュールどおりに配布するときの運用 ベースブランチをdevelopとする hotfix リリース済みのバージョンに緊急の修正を入れるときの運用 ベースブランチをmasterとする 複数バージョンを同日配布 規模の大きい改修などQA期間を長く取りたいときや、リリース日が近くバージョンを分けたいときの運用 ベースブランチは、先発配布ならdevelop、後発配布なら先行配布ブランチとする これらいずれのパターンでも実行できるように自動化を設計しました。 改善後の全体構成 改善する際、なるべく手作業の手間を減らす方向性で考えました。前提として、ZOZOTOWN Androidではタスク管理にJiraを利用しており、リリースごとに専用のタスクチケットを作成しています。そのタスクチケットを起点にリリース準備が完了するような構成を目指しました。 改善後の全体構成は以下のとおりです。 Jiraチケットでトリガーを実行するだけでリリース準備が完了する構成 処理の大部分はGitHub Actionsで動かしています。配布日やバージョン名といったリリース情報はJiraに記載してあるため、必要な情報はJira REST APIから取得できます。またJiraには自動化機能のJira Automationがあり、今回はGitHub Actionsを起動するトリガーとして利用しています。 GitHub ActionsによるリリースPRの自動作成 GitHub Actionsでは、前述したリリース準備の工程すべてを実行します。以降、工程ごとに実装を説明します。 Jira REST APIの準備 事前にJira REST APIを利用するために必要な準備をします。Pythonスクリプト内で jiraライブラリ を利用するため、pipでインストールします。 - name : Install dependencies run : pip install jira requests ステップごとにPythonファイルを分けたいので、共通して利用するJiraインスタンス生成を個別のファイルとして作成します。Jira REST APIはメールアドレスとトークンによるBasic認証で行うため、事前にトークンの発行が必要です。Jira REST APIの認証方法は Basic auth for REST APIs を参照してください。 """jira_config.py Jiraの設定 """ from jira import JIRA # Jira APIはメールアドレスとトークンによるBasic認証で行う jira_email = os.environ.get( 'JIRA_BOT_MAIL' ) jira_api_token = os.environ.get( 'JIRA_CLOUD_TOKEN' ) JIRA_HOST = 'YOUR_ATLASSIAN_DOMAIN' JIRA_URL = f 'https://{JIRA_HOST}' headers = { 'Host' : JIRA_HOST, 'Origin' : JIRA_URL, 'X-Atlassian-Token' : 'no-check' , 'Content-Type' : 'application/json;charset=UTF-8' , } def create_jira (url=JIRA_URL, headers=headers): return JIRA(url, basic_auth=(jira_email, jira_api_token), options={ "headers" : headers}) 各PythonスクリプトでJira情報を取得したいときにこのファイルをimportして利用します。 ブランチ作成 ブランチを作成するにあたりベースブランチ、作成するブランチ名の2つの情報が必要になります。その値はGitHub Actionsの inputs として渡せるようにします。 name : Release Preparation on : workflow_dispatch : inputs : branch_name : required : true description : "リリースブランチ名" type : string base_branch : required : true description : "ベースブランチ" type : string env : GH_TOKEN : ${{ secrets.GITHUB_TOKEN }} JIRA_BOT_MAIL : ${{ secrets.JIRA_BOT_MAIL }} JIRA_CLOUD_TOKEN : ${{ secrets.JIRA_CLOUD_TOKEN }} jobs : release-preparation : runs-on : ubuntu-latest steps : # ...他の処理 - name : Fetch base branch env : BASE_BRANCH : ${{ github.event.inputs.base_branch }} run : | git fetch origin "$BASE_BRANCH" git checkout "$BASE_BRANCH" - name : Create release branch env : BRANCH_NAME : ${{ github.event.inputs.branch_name }} run : | git checkout -b "$BRANCH_NAME" ブランチ処理自体は単純なGit操作で済むため、ワークフローファイルだけで完結します。ベースブランチをフェッチ、切り替えた後にリリースブランチを作成しています。なお上記のワークフローファイルでは掲載を省略していますが、事前バリデーションも同じファイル内で実行しています。例えば渡されたbranch_nameと同名のブランチが既に存在しないか、チームの運用で定めたフォーマットになっているかを確認します。 バージョン更新 - name : Get Jira ticket info and extract version id : jira run : python .github/script/get_jira_version.py "${{ steps.parse.outputs.jira_ticket }}" - name : Update version in libs.versions.toml id : version run : python .github/script/update_version.py "${{ steps.jira.outputs.version_name }}" versionCode, versionNameを更新します。ZOZOTOWN AndroidのversionCodeは既存の値に1を足すだけです。一方、versionNameはひと工夫しています。 ZOZOTOWN AndroidではリリースバージョンもJiraで管理しています。リリース用のタスクチケットのタイトルは 【Android】Ver x.y.z(N)対応内容 というフォーマットです。そのため、Pythonスクリプト内でJiraチケットのタイトルからversionNameを抽出します。 import jira_config def extract_version_name (title: str ) -> str | None : """JiraチケットタイトルからversionNameを抽出する""" match = re.search( r'(\d+\.\d+\.\d+)' , title) return match.group( 1 ) if match else None def main () -> None : if len (sys.argv) < 2 : print ( '::error::Usage: python get_jira_version.py <jira_ticket>' ) sys.exit( 1 ) jira_ticket = sys.argv[ 1 ] try : jira = jira_config.create_jira() issue = jira.issue(jira_ticket) summary = issue.fields.summary version_name = extract_version_name(summary) if not version_name: sys.exit( 1 ) set_output( 'version_name' , version_name) # チケットタイトルはリリース用PRのタイトルにも利用する set_output( 'jira_title' , summary) except Exception as e: # 例外処理 sys.exit( 1 ) なお、記事中の set_output は値を $GITHUB_OUTPUT へ書き出す自前のヘルパーです。書き出した値は後続のステップから steps.<id>.outputs.<name> で参照します。 versionNameを取得後、versionCodeと合わせてバージョンを更新します。ZOZOTOWN Androidではバージョンをtomlで管理しているのでtomlを更新します。 VERSION_FILE = 'gradle/libs.versions.toml' def read_version_file () -> str : """バージョンファイルを読み込む""" path = Path(VERSION_FILE) if not path.exists(): print (f '::error::Version file not found: {VERSION_FILE}' ) sys.exit( 1 ) return path.read_text() def get_current_version_code (content: str ) -> int : """現在のversion_codeを取得する""" match = re.search( r'^version_code = "(\d+)"' , content, re.MULTILINE) if not match: print ( '::error::Could not find version_code in libs.versions.toml' ) sys.exit( 1 ) return int (match.group( 1 )) def update_version (content: str , new_version_code: int , new_version_name: str ) -> str : """バージョン情報を更新する""" # version_codeを更新 content = re.sub( r'^version_code = "\d+"' , f 'version_code = "{new_version_code}"' , content, flags=re.MULTILINE ) # version_nameを更新 content = re.sub( r'^version_name = "[0-9.]+"' , f 'version_name = "{new_version_name}"' , content, flags=re.MULTILINE ) return content def main () -> None : if len (sys.argv) < 2 : print ( '::error::Usage: python update_version.py <version_name>' ) sys.exit( 1 ) new_version_name = sys.argv[ 1 ] # バージョンファイルを読み込み content = read_version_file() # 現在のversion_codeを取得 current_version_code = get_current_version_code(content) # 新しいversion_codeを計算（インクリメント） new_version_code = current_version_code + 1 # バージョン情報を更新 updated_content = update_version(content, new_version_code, new_version_name) # ファイルに書き込み write_version_file(updated_content) # GitHub Actionsの出力に設定 set_output( 'new_version_code' , str (new_version_code)) set_output( 'new_version_name' , new_version_name) このようにPythonスクリプトを用いて、GitHub Actions内でバージョンを自動更新しています。バージョン更新後、Gitのコミットとプッシュまで行います。ベースブランチとの差分がないとPRを作成できないため、このバージョン更新をコミットしておきます。 - name : Commit version update run : | git config --local user.email "xxxxxxxx+github-actions[bot]@users.noreply.github.com" git config --local user.name "github-actions[bot]" git add gradle/libs.versions.toml git commit -m "Bump version" - name : Push release branch env : BRANCH_NAME : ${{ github.event.inputs.branch_name }} run : | git push --set-upstream origin "$BRANCH_NAME" PR作成 ここまできたらPRを作成します。ZOZOTOWN Androidではリリース用PRに記載する情報も標準化されており、配布時のメッセージ文とバージョンに含める案件内容を記載します。 PRの説明欄に記載する本文生成 メッセージは定型文で、案件内容はJiraから取得できるのでこれらもPythonスクリプト上で処理して整形できます。 import jira_config def get_epics_by_fix_version (jira, fix_version: str ) -> list [ dict ]: """修正バージョンに紐づくエピックを取得する""" # JQLでfixVersionに紐づくエピックを検索 jql = f 'fixVersion = "{fix_version}" AND issuetype = Epic ORDER BY key ASC' issues = jira.search_issues(jql, maxResults= 100 ) epics = [] for issue in issues: epics.append({ 'key' : issue.key, 'summary' : issue.fields.summary, }) return epics def generate_epics_markdown (epics: list [ dict ]) -> str : """エピック一覧をMarkdown形式で生成する""" if not epics: return '' lines = [] for epic in epics: url = f '{JIRA_BASE_URL}/browse/{epic["key"]}' lines.append(f '### [{epic["summary"]}]({url})' ) return ' \n\n ' .join(lines) def generate_pr_body (jira_ticket: str , version_name: str , version_code: str , epics_markdown: str = '' ) -> str : """PR本文を生成する""" jira_url = f '{JIRA_BASE_URL}/browse/{jira_ticket}' # エピック一覧のセクションを生成 epics_section = '' if epics_markdown: epics_section = f ' \n\n {epics_markdown}' pr_body = f '''## 修正内容 {{配布時のメッセージ文}} ## 仕様書 [{jira_ticket}]({jira_url}){epics_section} ...以降テンプレに沿った内容 ''' return pr_body def main () -> None : if len (sys.argv) < 4 : print ( '::error::Usage: python generate_pr_body.py <jira_ticket> <version_name> <version_code>' ) sys.exit( 1 ) jira_ticket = sys.argv[ 1 ] version_name = sys.argv[ 2 ] version_code = sys.argv[ 3 ] try : jira = jira_config.create_jira() # リリースチケットから修正バージョンを取得 fix_version = get_fix_version_from_issue(jira, jira_ticket) # 修正バージョンに紐づくエピック(案件情報)を取得 epics = get_epics_by_fix_version(jira, fix_version) epics_markdown = generate_epics_markdown(epics) # PR本文を生成 pr_body = generate_pr_body(jira_ticket, version_name, version_code, epics_markdown) # 一時ファイルに書き出し with tempfile.NamedTemporaryFile(mode= 'w' , suffix= '.md' , delete= False ) as f: f.write(pr_body) pr_body_file = f.name set_output( 'pr_body_file' , pr_body_file) except Exception as e: sys.exit( 1 ) バージョンに含める案件情報はJira上でバージョンに紐付けされているので、Jira REST APIでバージョンから取得できます。それをMarkdown形式にしてPR本文中に含めるように文字列生成しています。 本文ができたらPRを作成します。PR作成はghコマンドによりワークフローファイルだけで完結できます。 - name : Generate PR body id : pr_body run : | python .github/script/generate_release_pr_body.py \ "${{ steps.parse.outputs.jira_ticket }}" \ "${{ steps.version.outputs.new_version_name }}" \ "${{ steps.version.outputs.new_version_code }}" - name : Create Pull Request id : create_pr env : JIRA_TITLE : ${{ steps.jira.outputs.jira_title }} BASE_BRANCH : ${{ github.event.inputs.base_branch }} BRANCH_NAME : ${{ github.event.inputs.branch_name }} PR_BODY_FILE : ${{ steps.pr_body.outputs.pr_body_file }} run : | PR_URL=$(gh pr create \ -B "$BASE_BRANCH" \ -H "$BRANCH_NAME" \ -t "$JIRA_TITLE" \ -F "$PR_BODY_FILE" ) echo "pr_url=$PR_URL" >> $GITHUB_OUTPUT PRへラベル付与 ZOZOTOWN Androidには、ラベル付与をトリガーに動く別のGitHub Actionsがあります。リリース用PRには「配布前確認」というラベルを付与します。ラベル付与もPR作成と同様、ghコマンドを使えばワークフローファイルだけで完結します。 - name : Add labels to PR env : BRANCH_NAME : ${{ github.event.inputs.branch_name }} run : | PR_NUMBER=$(gh pr view "$BRANCH_NAME" --json number -q '.number' ) gh pr edit "$PR_NUMBER" --add-label "配布前確認" マージの対象案件メンバーへSlack通知 リリースブランチに案件のfeatureブランチをマージしてほしいため、最後にリリースブランチとPRが作成されたことを通知します。通知内容はシンプルなため、Slack公式の slackapi/slack-github-action で済みます。 - name : Post Slack notification uses : slackapi/slack-github-action@vX.XX.XX with : payload : | { "text" : ":github: リリースブランチが作成されました: ${{ github.event.inputs.branch_name }}" , "blocks" : [ { "type" : "section" , "text" : { "type" : "mrkdwn" , "text" : ":github: リリースブランチが作成されました \n *ブランチ*: `${{ github.event.inputs.branch_name }}` \n *Version*: ${{ steps.version.outputs.new_version_name }} (${{ steps.version.outputs.new_version_code }}) \n *PR*: <${{ steps.create_pr.outputs.pr_url }}|Pull Request>" } } ] } env : SLACK_WEBHOOK_TYPE : INCOMING_WEBHOOK SLACK_WEBHOOK_URL : ${{ secrets.SLACK_WEBHOOK_URL }} 以上により、リリース準備の一連の流れをGitHub Actions上で自動化できました。 Jira AutomationからのGitHub Actions実行 GitHub Actionsに workflow_dispatch を設定しているので、外部からAPIでワークフローを起動できます。ZOZOTOWN Androidでは改善後の全体構成でも説明した通り、タスク管理にJiraを利用しているので、Jiraからそのワークフローを起動できないか考えました。 JiraにはJira Automationというさまざまな自動化を設定できる機能があります。今回はこのJira AutomationからGitHub Actionsのワークフローを起動します。 Jira Automation側の全体構成は以下のスクリーンショットのとおりです。Jiraに詳しくなくても、Zapierなどの自動化ツールを触ったことがある方なら近い印象を持てるはずです。 GitHub Actions REST APIの準備 REST APIでGitHub Actionsの操作をする場合、アクセストークンが必要となるため発行しておきます。本記事では詳細を割愛しますが、アクセストークンの権限設定は GitHub Actionsの権限に関するREST APIエンドポイント を参照してください。 トリガー設定 まずどのようなタイミングでJira Automationを実行するかを設定します。チケットのステータス変更時やチケット作成時などさまざまなトリガーがありますが、今回は手動によるトリガーを選択しました。理由としては以下2点です。 リリース準備のタイミングが固定ではない 配布パターンがその時の状況により変わる ZOZOTOWN Androidでは基本的に毎週リリースがあります。ただしお盆や年末年始などの連休時や、開発状況により2週間以上あく場合もあります。また、 ブランチ運用の整理 で記載したようにhotfixや同日配布の場合には任意でベースブランチやブランチ名を指定したいときがあります。 それらの運用面を考えて、配布担当者が手動でJira Automationを起動するようにしました。 入力値の設定 ブランチ作成に必要なベースブランチとブランチ名の2つを、GitHub Actionsのジョブへ渡す入力値として設定します。Jira Automationを手動起動する際に、インプットデータとして任意の値を渡せます。 これを設定すると、起動時のダイアログに入力フォームが表示され、ベースブランチとブランチ名へ任意の値を指定できます。 ここでは入力の手間を減らすため、それぞれにデフォルト値を設定しています。 ベースブランチ：develop ブランチ名：Jiraチケット上にある情報から運用に沿ったブランチ名を自動生成 デフォルト値があることで、通常パターンであれば担当者はボタンをクリックするだけで済みます。 ブランチ名の自動生成 ブランチ名は、チームの運用で release/{{JiraIssueKey}}/{{yyyy_mm_dd}} というフォーマットが決まっています。JiraIssueKeyにはリリース用のチケットのKeyを、yyyy_mm_ddには配布の日付を値として代入します。 配布の日付はJira上でリリースの説明に以下のようなテキストで記載されているので正規表現を使って抽出可能です。 リリースの説明文（抜粋） QA配布予定日:2026-09-03 正規表現による抽出 {{issue.fixVersions.first.description.match(".*QA配布予定日:(\d{4}-\d{2}-\d{2}).*").toDate.format("yyyy_MM_dd")}} REST APIでGitHub Actionsを起動 最後にREST APIで作成したGitHub Actionsのワークフローを実行します。API実行時にinputsとしてデータを渡せるので、ベースブランチと作成するブランチ名を渡します。 これで配布担当者はJiraからワークフローを起動するだけで、リリース準備が完了します。これまで手作業で行っていた複数の工程にかかる時間を短縮できました。 改善後の実行イメージ 改善後の実行イメージは以下のとおりです。 Jiraのリリース用チケットでリリース準備の自動化トリガーを実行。フォームに指定する内容がなければ「続行」ボタンクリックで完了する 自動でPRが作成される PR作成完了後Slackに通知が届く これまで手動で行っていた作業がトリガー実行1つで完了するようになりました。リリース準備のマニュアルを確認する必要はなく、以降の処理はGitHub Actionsが行い、30秒程度で完了します。 まとめ 本記事では、Jira AutomationとGitHub Actionsによるリリース準備の自動化について紹介しました。手作業だったリリースブランチ作成からSlack通知までの工程がJiraのワークフロー1つで完了するようになり、担当者による作業時間やPR内容のばらつきもなくなりました。標準化された手順を手作業で進めているチームがあれば、ぜひ参考にしてみてください。 ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

本記事は 2026 年 8 月 26 日 に公開された「 AWS and DuckLabs: Building the future of analytics together 」を翻訳したものです。 本日、 Amazon が DuckLabs を買収する最終契約を締結したこと を発表します。DuckLabs はオープンソースの分析データベース DuckDB を開発する、アムステルダム拠点の企業です。取引は通常のクロージング条件が満たされ次第、まもなく完了する見込みです。DuckDB を開発し DuckLabs を共同創業した Hannes Mühleisen と Mark Raasveldt は、AWS の一員として引き続きチームとオープンソースプロジェクトの技術的方向性を率いていきます。DuckDB オープンソースプロジェクトも引き続き DuckLabs チームが推進し、独立した Foundation (DuckDB を統括する非営利団体) の下でオープンソースとして維持され、現在と同様に MIT ライセンスで利用可能です ( DuckLabs ブログ を参照)。 データは常に企業の中核となる資産であり、差別化の源泉でした。組織が自社のデータで推論をカスタマイズし AI エージェントを構築する今、その重要性はこれまで以上に高まっています。AWS は 20 年間、データの最前線を切り拓いてきました。あらゆるビジネスにデータレイクをもたらした Amazon S3 のローンチに始まり、初のクラウド分析サービスである Amazon EMR、初のクラウドデータウェアハウスである Amazon Redshift、さらに Athena や Glue ETL などで導入してきた数々の機能があります。S3 Tables で直接利用できる Apache Iceberg 機能、データレイク内のベクトルストレージ、新しく最適化された Graviton ベースの Redshift クラスターなど、AWS のお客様のためにデータ領域での革新を続けています。 DuckDB もまた、世界のデータの扱い方を変える最前線に立ってきました。Hannes と Mark は、Python を生み出したことでも知られるオランダの国立研究機関 Centrum Wiskunde & Informatica (CWI) 在籍中に DuckDB を開発しました。DuckDB の創業者たちは、従来のデータベースや Spark のような分析エンジンが超大規模データ処理のパフォーマンスに注力する一方で、多くのお客様が SQL 分析で行う作業の中心を占める、より小さなサイズのデータクエリに効果的に「スケールダウン」する手段を持っていないと気づきました。 DuckDB が取り組んだのは、今日のデータクエリの 90% 以上を占める、分析やダッシュボード作成で 1 テラバイト以下のデータを扱うクエリを圧倒的な速度で処理する課題です。DuckDB のアーキテクチャは「日常的な SQL クエリを超高速にする」という前提に基づいており、他のアプリケーションのインプロセスで動作するため、アプリケーションとのデータのやり取りが簡単かつ高速になります。DuckDB はベクトル化実行によって大きなパフォーマンス向上を実現しています。 SELECT * FROM table のような単純な文の実行に重たいコンパイラを必要としないためです。日常的なクエリでうまく機能する仕組みは、当然ながらエージェントでもうまく機能します。エージェントはデータと対話するときに人間とよく似た振る舞いをするからです。軽く探ってみる。試してみる。本当にやりたいことを見極める前に、小さなデータセットで探索的な分析を行う。DuckDB は AI エージェントが使うのに自然と最適化された形になっています。学術プロジェクトとして始まったものが、今ではデータエンジニアリング、データサイエンス、分析、そして AI エージェントに至るまで、使いやすさと純粋なパフォーマンスの点で広く採用されています。私たちは、1 テラバイト以下の日常的なクエリにおける DuckDB の強みを、エクサバイト超のエンタープライズ規模で実績のある S3 と、数百テラバイトからペタバイト級のデータで分析を支える Redshift、Athena、EMR、Glue-ETL、SageMaker プラットフォームなどの AWS 分析サービスと組み合わせる計画です。AWS の Distinguished Engineer である Andy Warfield が、Werner Vogels の All Things Distributed ブログで DuckDB and the Changing Physics of Analytics について語っています。 お客様は現在、DuckDB を AWS サービスと組み合わせて活用しており、その速度とシンプルさを高く評価しています。たとえば DuckDB は現在、ローカルや S3 などのクラウドストレージに保存された Parquet、CSV、JSON といった外部ファイルに対して SQL を直接実行し、他に類を見ないパフォーマンスと大幅に低いコストを実現しています。 Allen Institute の Scientific Computing 担当 Executive Director である David Feng 氏は次のように述べています。 「Allen Institute は、生物学における最大級の問いに大規模に取り組むことで、より健康な世界のための科学を加速しています。そこには、大規模でマルチモーダルなデータの広範な分析が伴います。私たちは 2025 年に数テラバイトの科学データを分析するために DuckDB を使い始め、大変気に入っています。神経生理学および行動データのリアルタイム品質管理と分析のためにデータを S3 に保存しており、これは次のデータ取得を進める上で欠かせません。数分かかっていたクエリが 1 秒未満で返るようになり、データとのまったく新しい対話方法が可能になりました。」DuckDB は AWS Lambda 関数のインプロセスで実行することもできます。 DuckDB アプリケーションが AWS で最高のパフォーマンスを発揮するようにし、DuckDB と AWS のビルディングブロックサービスとの深い統合に引き続き投資していきます。 AWS 自身のインフラでも DuckDB を活用しています。Amazon Quick は独自のダッシュボードエンジンのパフォーマンスを強化するにあたり、S3 Tables のデータへのクエリに DuckDB を選びました。Quick チームは、DuckDB エンジンが CPU 数に応じてスムーズにスケールし、単一のライブラリを Quick の内部コントロールプレーンサブシステムに簡単に組み込めることを確認しました。2025 年 10 月に Quick を提供開始して以来、DuckDB との統合と最適化を組み込んだ独自の Quick クエリエンジンで 25 億件を超えるクエリを処理してきました。DuckDB との統合と最適化により、Amazon Quick は平均クエリレイテンシーを 30% 削減できました。データと分析領域の他の AWS サービスでも、DuckDB のパフォーマンスとシンプルさをどのように取り込めるかを検討していきます。 DuckLabs と AWS が、アプリケーション、データエンジニア、AI のためにデータの最前線をどう再定義していくのか、そしてお客様の現状に寄り添いながら AWS の中で DuckDB のイノベーションの恩恵をどのように届けていくのか。続報にご期待ください。 著者について Mai-Lan Tomsen Bukovec AWS の Technology Vice President である Mai-Lan Tomsen Bukovec は、デジタル変革、ビジネス分析、機械学習、生成 AI、次世代のカスタマーエクスペリエンスにおいて数百万人の AWS のお客様が信頼を寄せる Amazon のクラウドデータサービスを率いています。テクノロジー業界で 25 年以上の経験を持ち、クラウド技術を活用してビジネスを変革するお客様の取り組みを支援するパイオニアです。 この記事は Kiro が翻訳を担当し、Solutions Architect の Sotaro Hikita がレビューしました。

「テスト＝QA」を卒業したい。でも何から？ 以前の記事で、テストとQAは違うという話を書きました。 テストは「測る」行為です。QAは「良いものが生まれる仕組みをつくる」行為です。勉強にたとえるなら、テストは問題を解くことであり、QAは勉強法そのものを改善することです。 反応をもらった中で一番多かったのが、「わかった。で、具体的に何をすればいい？」 でした。正直、自分も最初はそうでした。 品質戦略の担当になったとき、「分析しよう」と意気込んでパレート分析やODCの教科書を開きました。でもデータが整っていません。ツールもありません。チームに「分析会議やりましょう」と言っても「その時間ある