はじめに こんにちは、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

G-gen の西原です。当記事では、Google Meet の機能である自動メモ生成（Take notes for me）の概要と操作方法について解説します。 はじめに 自動メモ生成（Take notes for me）とは 機能 データの保護 ユースケース 議事録作成の自動化 途中参加時のキャッチアップ 対面ミーティングでの使用 前提条件と対応言語 必要なライセンス 対応言語 メモ生成の開始手順 会議前に Google カレンダーから有効化する 会議参加後に生成を開始する PC での操作 モバイル端末（Android、iOS）での操作 会議中の参加者による同意 メモの操作ができるユーザー 対面会議でのメモ生成 PC のブラウザでの操作 モバイル端末での操作 メモの保存場所と共有 Google ドライブへの保存 Google カレンダーへの添付 アクセス権限の管理 はじめに 自動メモ生成（Take notes for me）とは Google Meet の 自動メモ生成 （Take notes for me）とは、Google Meet 上もしくは対面での会議中の会話を AI がリアルタイムに記録し、会議の詳細なメモを Google ドキュメントとして自動的に生成する機能です。 この機能を使用すると、会議の参加者は手動で議事録を作成する必要がなくなります。AI が会議の会話を分析し、単なる文字起こしだけでなく、情報が整理されたドキュメントを生成します。 自動メモ生成機能は Google Workspace の特定のエディション（後述）、または Google AI プランに登録している環境で使用できます。 参考 : Google Meet の「自動メモ生成」 当機能の裏側では、Google の生成 AI である Gemini が稼働しています。Gemini は、さまざまな言語、アクセント、方言の音声録音からなる膨大なデータセットを使用してトレーニングされているため、正確な翻訳とメモ作成が可能です。 機能 自動メモ生成により、単なる文字起こしに留まらず、会話の意図を汲み取った 要約 、会議の文脈に沿った 次のステップの提案 などを含んだ、高度なメモが作成されます。 なお以下のスクリーンショットの、「Gemini でメモを生成する」が当機能にあたります。その下部に表記されている「会議を文字起こし」は、シンプルな 文字起こし （Transcribe）機能の有効化チェックボックスであり、自動メモ生成とは区別されます。 参考 : Google Meet で文字起こしを使用する 自動メモ生成（Take notes for me）の有効化 データの保護 Google Workspace の環境下で使用される Gemini は、強力なプライバシー保護の枠組みのもとで提供されています。会議の音声データや生成されたメモの内容が、他の顧客向けの AI モデルのトレーニングに流用されることはありません。 企業のデータは組織内に留まり、機密情報は保護されます。 参考 : Google Workspace の生成 AI に関するプライバシー ハブ ユースケース 議事録作成の自動化 自動メモ生成の最も効果的なユースケースは、議事録作成業務の自動化です。 従来は、会議中に一人が書記を担当し、会議後に要約して体裁を整えていました。自動メモ生成機能を使用すると、会議中の手動記録の手間がなくなり、参加者全員が議論に集中できます。 会議終了後には自動的に整理された議事録のドラフトが完成しているため、内容を確認して軽く編集するだけで済み、大幅に省力化できます。 途中参加時のキャッチアップ オンライン会議に遅れて参加した場合、自動メモ生成機能の「ここまでの要約」を使用することで、遅れて参加したユーザーは、それまでの会議のハイライトや決定事項をリアルタイムに確認できます。 進行中の議論を妨げたり、他の参加者に質問したりすることなくスムーズに会話に合流できます。 ただし2026年8月現在、「ここまでの要約」機能は Android や iOS 版の Google Meet では使用できません。 対面ミーティングでの使用 対面会議向けの機能を使用することで、オフライン環境での商談やインタビュー、会議室でのブレインストーミングなどでも当機能の恩恵を受けることができます。 例えば営業担当者が顧客と対面で商談を行う場面では、相手の表情やトーンを読み取りながら質の高いコミュニケーションをとることが求められます。スマートフォンの Meet アプリで録音を開始しておけば、担当者はメモを取ることに気を取られず、会話に集中できます。 前提条件と対応言語 必要なライセンス 当機能は、以下の Google Workspace エディションで使用可能です。 Business Standard Business Plus Enterprise Standard Enterprise Plus Frontline Plus 参考 : Google Workspace with Gemini を使ってみる 対応言語 2026年8月現在、自動メモ生成機能は以下の言語で行われる会議に対応しています。 日本語 英語 フランス語 ドイツ語 イタリア語 韓国語 ポルトガル語 スペイン語 また、注意すべき点として、当機能は一度に1つの言語にのみ対応しています。例えば、日本語と英語が混在するなど、複数の言語で進行する会議のメモを同時に生成することはできません。そのため、会議の主要な言語に合わせて設定を行う必要があります。 参考 : Google Meet の「自動メモ生成」 メモ生成の開始手順 参考 : Google Meet の「自動メモ生成」 - 「自動メモ生成」機能を使用する 会議前に Google カレンダーから有効化する 事前に PC 版の Google カレンダーから自動メモ生成を有効化しておくと、会議後に自動的に自動メモの生成が開始されます。手順は以下のとおりです。なお、モバイル端末（Android、iOS）では事前の有効化はできません。 カレンダーの予定作成画面で「Google Meet のビデオ会議を追加」をクリック（予定作成時） 予定の詳細画面でビデオ会議オプション（歯車マーク）をクリック 予定詳細画面で歯車マークを押下 「会議の記録」タブで「Gemini でメモを生成する」「会議を文字起こし」をそれぞれ必要に応じて有効化する 会議の記録タブで自動メモ生成を有効化する 会議参加後に生成を開始する PC での操作 事前に有効化していない場合でも、会議開始後に、自動メモ生成を開始することができます。PC での手順は以下のとおりです。 Google Meet のビデオ会議に参加する 画面右上の Gemini アイコンをクリックする 「メモの作成を開始」をクリックする Google Meet の画面で「メモの作成を開始」を押下 モバイル端末（Android、iOS）での操作 モバイル端末では、会議参加後に以下の手順で自動メモ生成を開始できます。 対象のビデオ会議に参加する 画面下のメニューアイコンをタップする 画面下のメニューアイコンをタップ 「Gemini でメモを生成する」をタップする 「Gemini でメモを生成する」をタップ 案内に従って「メモの作成を開始」をタップする 会議中の参加者による同意 組織の管理者の設定によっては、自動メモ生成や録画などの機能を使用する前に、参加者全員に対して明示的な同意を求めるプロンプトが表示されることがあります。この場合、機能をオンにして会議を継続するには、参加者が「続行」をクリックして同意する必要があります。 参考 : Google Meet の「自動メモ生成」 - 会議機能の利用に同意する メモの操作ができるユーザー メモの開始と停止を操作できるのは、原則として会議の主催者、または主催者と同じ組織に所属する参加者です。 主催者向けの設定が有効になっている場合は、会議の作成者、主催者、共同主催者のみが操作可能です。管理者が「クイック停止」を有効にしている場合、組織内のユーザーの誰かが「停止」をクリックすることで、すべての参加者の自動メモ生成が終了します。 対面会議でのメモ生成 参考 : 対面会議で「自動メモ生成」を使用する PC のブラウザでの操作 Google Meet 上で行われる会議だけでなく、対面での会議でも自動メモ生成機能を使用できます。 具体的には、PC またはモバイル端末で Google Meet を開き、自動メモ生成を有効化したうえで、マイクで会議の音声をインプットします。 PC での手順は以下のとおりです。 ブラウザで Google Meet のトップ画面（ https://meet.google.com/home ）にアクセスする 画面右上の「メモを入力」を押下する 「メモを入力」を押下 画面の案内に従い、その場の参加者に周知した上で「メモの作成を開始」を押下 「メモの作成を開始」を押下 モバイル端末での操作 Android や iOS のモバイル端末を用いて、対面での会議で自動メモ生成を開始する手順は以下のとおりです。 Google Meet アプリを開き、画面下部の「メモを作成」をタップ 「メモを作成」をタップ 画面の案内に従い、その場の参加者に周知した上で「メモの作成を開始」をタップ 「メモの作成を開始」をタップ メモの保存場所と共有 Google ドライブへの保存 自動メモ生成機能によって作成された会議メモのドキュメントは、会議の終了後すぐに自動生成され、 会議主催者のマイドライブ に保存されます。 具体的には、主催者のマイドライブ内に配置される「Google Meet」フォルダ内に、特定の会議ごとのサブフォルダが自動作成され、その中にメモが保存されます。これにより、過去の会議記録を整理された状態で管理できます。 Google カレンダーへの添付 生成されたメモのドキュメントは、Google ドライブに保存されるだけでなく、対象となる会議の Google カレンダーの予定に自動的に添付されます。これにより、カレンダーの予定に招待されているメンバーは、カレンダーの予定詳細画面から直接メモへアクセスできます。 予定詳細画面にメモが追加されている様子 また、会議終了直後にはハイライトのリンクが記載されたメールが会議主催者宛に送付されるため、議事録の URL を手動で共有し直す手間が省けます。 会議メモのメールが届く様子 アクセス権限の管理 メモのドキュメントへのアクセス権限は、会議の主催者（または共同主催者）が、メモの作成を開始する際に選択した共有設定に依存します。 通常、組織内の招待者に対しては自動的にドキュメントのアクセス権限が付与され、参加者の「Google Meet」フォルダ内にドキュメントへのショートカットが作成されます。 しかし、外部ゲストに対しては、カレンダーの予定にドキュメントが添付されていることが確認できても、ドキュメントを開くためのアクセス権限は別途付与されていない場合があります。 また、グループのメールアドレスを使用して一括でメンバーを追加した場合、グループに自動的に権限は付与されません。メモ生成後に、明示的にグループに権限を付与する必要があります。 参考 : Google Meet の「自動メモ生成」 - 会議の終了後 西原 正真 (記事一覧) 事業開発部 クラウドサポート課 大阪府出身、北海道在住。2026年5月よりG-genにジョイン。 現在は Google Workspace を中心に、カスタマーサポートに従事。 Google Cloud 全 14 資格保有。 好きなものは写真と旅行。

こんにちは、株式会社LuupでEngineering Managerをしている瀧川です。 2026年9月1日（火）〜3日（木）にベルサール渋谷ガーデンで開催されたDroidKaigi 2026に、Androidエンジニアのメンバーといっしょに参加してきました！ LuupではLUUPアプリをiOS・Androidともにネイティブで開発しているので、Android開発の最新動向やAI活用の事例をキャッチアップしたく参加してきました。 平日開催のため私は最終日しか参加できず残念でしたが、資料やセッション動画は後日公開されるはずなので、聴けなかったセッションはそちらで追いかけようと思っています。