every Tech Blog

株式会社エブリーのTech Blogです。

Cloud SQL for MySQL 5.7 から 8.0 移行計画

Cloud SQL for MySQL 5.7 から 8.0 移行計画

はじめに

こんにちは、TIMELINE 開発部 Service Development をしているほんだです!
つい最近 Aurora MySQL バージョン 3 対応したな...。というのはさておき。
今回は Cloud SQL for MySQL のデータベースバージョンを 5.7 から 8.0 に移行する際に行った方法について紹介します!

前提

皆さんご存知かと思いますが、2025年2月1日からCloud SQLではMySQL 5.7, 5.6の拡張サポートが開始し、2028年2月1日はサポートが終了します。そこでTIMELINE が提供しているサービスの一つで、Cloud SQL for MySQL 5.7を使用しているため8.0への移行を行うことになりました。
今回のシステムでは月に1回程度メンテナンスでサービスが停止するため、そのタイミングでインプレイスアップグレードを行うことにしました。以下では5.7から8.0へ移行する際の事前準備、インプレイスアップグレードの手順、切り戻し方法について説明します。

事前準備

5.7と8.0の差分を確認

MySQLの公式を参考に8.0での差分を確認しました。
今回はデフォルト認証プラグインがcaching_sha2_password, character_set_serverのデフォルト値がutf8mb4に変わったことやcollation_serverのデフォルト値がutf8mb4_0900_ai_ciに変更されたことが差分として上がりました。

Cloud SQLの設定の確認

Cloud SQLはデータベースフラグというものを用いてMySQLパラメータの調整を行っているので、その確認も必要です。データベースフラグのデフォルトやどの値が設定できるかはこちらのサイトで確認ができます。
今回のデータベースでは上述5.7と8.0の差分で上がったdefault_authentication_plugin, character_set_servercollation_serverをデータベースフラグを用いて設定することになりました。

手順

手順は下記の通りになります。

順番 手順
1 インスタンスのクローン
2 インプレイスアップグレード
3 MySQL versionの確認
4 データベースフラグの設定

ここからは実際に実行するコマンドも踏まえて説明していきます。

1. インスタンスのクローン

インプレイスアップグレードを実行する際に、バックアップが作成されますが、こちらはあくまでデータのみのため別途手動でインスタンスのクローンを行います。 Cloud SQLインスタンスの名前は変更することはできないので、アップグレードに失敗した際に切り替えて問題ない名前にしとく事をお勧めします。

$ gcloud sql instances clone <SOURCE_INSTANCE_NAME> <DESTINATION_INSTANCE_NAME> --project=<PROJECT_ID>

2. インプレイスアップグレード

下記コマンドを用いて既存のインスタンスに対してインプレイスアップグレードを実行します。上述のように、インプレイスアップグレード開始時と終了時にデータのバックアップが作成されます。
今回は8.0.33にアップグレードするためdatabase-versionMYSQL_8_0_33を指定します。

$ gcloud sql instances patch <INSTANCE_NAME> --database-version=MYSQL_8_0_33

インスタンスのバックアップについては下記コマンドで確認することができます。

$ gcloud sql backups list --instance=<INSTANCE_NAME>

インスタンスのアップグレード状況は下記コマンドで確認することができます。

$ gcloud sql operations list --instance=<INSTANCE_NAME>

$ gcloud sql operations describe OPERATION

3. MySQL versionの確認

Cloud SQL Auth Proxyを用いてCloud SQLに接続しMySQLのversionを確認します。8.0系になっていることが確認できたらOKです。

$ cloud-sql-proxy --port <PORT_NUMBER> <INSTANCE_CONNECTION_NAME>

$ mysql -u <USER_NAME> 127.0.0.1 -P <PORT_NUMBER> -p

mysql> select version();

4. データベースフラグの設定

上述の通り、MySQLのdefault設定と異なる部分があるので、Cloud SQLのデータベースフラグを更新を行います。

$ gcloud sql instances describe <INSTANCE_NAME>

$ gcloud sql instances patch <INSTANCE_NAME> --database-flags=character_set_server=utf8,collation_server=utf8_general_ci,default_authentication_plugin=mysql_native_password

下記コマンドにてデータベースフラグが更新されていることを確認します。

$ gcloud sql instances describe <INSTANCE_NAME>

念の為インスタンスに接続しMySQL commandでも確認すると良いです。

mysql> show variables like '%char%';

切り戻し方法

インスタンス名が変わっていることに注意して、手順1. で作成した既存のインスタンのクローンにそれぞれのサーバーの向き先を変更します。

まとめ

以前Aurora3への移行を行った際はconsoleベースで、アップグレードを行ったのですが今回gcloud commandを用いて行うことで、以前rymiyamotoの記事でもあった通りメンテナンスの再現性や、レビューが格段に容易になったと感じました。
また、今回の手順に記したものを実際の値に変えた手順書を作成しているため、当日はコピペするだけで作業が完了するので実行者の負荷やヒューマンエラーも軽減することができました!(筆者はタイポが多いです)
今回Cloud SQLのアップグレードを行うにあたって、明確な原因は追求できていませんがsidecar containerとして実行している、Cloud SQL Auth Proxyのimage versionが古すぎて、インスタンスに接続できないという事象が発生したので、定期的にメンテナンスを行うことは大切だと実感しました。
Cloud SQL for MySQLのインプレイスアップグレードを行おうとしてる人や今後本システムの開発に携わる人の参考になれば幸いです。

リテールハブ開発部の新設とDELISHKITCHEN開発部長の交代

タイトル - リテールハブ開発部の新設とDELISHKITCHEN開発部長の交代

はじめに

皆さん、いつもお世話になっております。CTO/開発本部の今井です。 本ブログでは、あたらくリテールハブ開発部を立ち上げたことおよび自分が兼務で務めていたDELISHKITCHEN開発部長の交代についてお話させていただきます。

リテールハブ開発部の設立

このたび、10/1でリテールハブ開発部を新設し、そこの開発部長を私が務めることになりました。
リテールハブ開発部は、これまでDELISHKITCHEN開発部で手掛けてきた小売向けのサービス開発に注力をする新しい部門となります。
先んじて、ビジネス側はすでにリテールハブカンパニーとして切り出されていたところに合わせて、開発部も切り出すことを決断しました。
私たちの会社は、これまで多岐にわたる分野でサービスを提供してきましたが、小売業界は特に大きな成長が期待される分野の一つです。
お客様のニーズが日々変化する中で、より迅速で柔軟な対応が求められるようになりました。
そこで小売業界向けのサービス開発にさらに集中し、その分野におけるリーダーシップを強化するため、リテールハブ開発部を新たに立ち上げました。

組織図

この新しい部門では、既存の「ストアDX」「ネットスーパー」「小売アプリ」の開発を推進し、 『retail HUB』として統合ソリューションの提供を行うとともに、リテールメディアの構築を行っていくことに注力します。
私自身も、これまで培ってきた経験を最大限に活かし、チームと共により良いサービスを提供していけるよう努力していきたいと思っています。

新任DELISHKITCHEN開発部長の紹介

私がこれまで担当してきたDELISHKITCHEN開発部の新しい部長には、村上が就任します。
村上は、新卒で弊社に入社して以来、驚異的なスピードで成長を遂げてきた期待のエンジニアです。
彼の優れた技術力とリーダーシップは、すでに多くのプロジェクトで発揮されており、私たちのチームにとってなくてはならない存在です。
短期間で当時MAMADAYS開発部(現在のトモニテ開発部)のサーバーサイドのマネージャーに就任したのちに、DELISHKITCHEN開発部の副部長として主に広告商品の開発を一手に引き受けるなど大きな役割を果たしてきました。
彼の強みは、単なる技術力だけでなく、チームを引っ張るリーダーシップと、メンバーの意見を尊重しながらも、全体の方向性を見極めて決断する判断力にあります。
DELISHKITCHEN開発部は、新たなリーダーのもとで、さらに力強いチームへと進化していってくれると確信しています。
開発部長を彼に引き継げることは、私自身とても嬉しく思っています。

DELISHKITCHEN開発部の今後

今後村上が率いることになるDELISHKICHEN開発部は、これからも私たちの会社にとって軸となるサービスを運営・発展させるという重要な役割を担い続けます。 特に、小売向けのサービス開発をリテールハブ開発部に引き継いだことで、AIの活用をはじめとし、よりチャレンジングな領域でのイノベーションを生み出すことが期待されています。
村上のリーダーシップのもと、DELISHKITCHEN開発部は新たな成長を遂げ、多くのお客様に価値あるサービスを提供していけるよう邁進していきます。

また、組織は別れたものの、DELISHKITCHENとリテールハブは、それぞれの開発部が独立しているわけではなく、 システム連携や、リソースの共有や協力を行うことでより良いサービスを提供することができると考えています。
両部門の緊密な連携により、相乗効果を生み出し、「食」の領域をリードしていくことを目指していきます。

最後に

今回の新しい開発部の設立および部長交代を通じて、私自身も新たなステージで挑戦を続けていく決意を新たにしています。
リテールハブ開発部での取り組みを通じて、小売業界に革新をもたらし、より多くのお客様に価値あるサービスを届けていけるよう尽力していきます!

また、どちらの部門も進めたいことが増えていく中で、一緒に取り組んでいける仲間がまだまだ足りません!
ぜひ一緒に日本の「食」の領域をリードするサービスを作っていきましょう!

corp.every.tv

満たしたい状態の定義から始めるシステムDD

はじめに

こんにちは。DELISH KITCHEN 開発部 RHRA グループ所属の池です。

2024年6月、エブリーは5つの小売アプリの運営について事業譲渡を受け、『 retail HUB 』へ移管しました。

prtimes.jp

この事業譲渡において、私はシステムに関するデューデリジェンス(以下、システムDD)を担当しました。

今回 retail HUB へ移管したシステムは具体的には 5つプロダクトそれぞれにおける、iOS/Androidのネイティブアプリと、入稿管理画面の Web アプリケーションサーバー、アプリ向け API サーバー、それらを構成するシステム(AWS環境、ロードバランサー、データベース、バッチサーバーなど)です。

システムDDは譲渡されるIT資産の把握やリスクの確認を行う重要なプロセスですが、方法や手順が明確に決まっているようなものではなく、どう進めるべきか迷うことが多くありました。 そこで、本記事では、今回私が行ったシステムDDの具体的な手順の実例について紹介します。進め方に明確な正解のないシステムDDについて、手順の実例を共有することで、同様のプロセスを進める方々の参考になれば幸いです。

システムデューデリジェンスとは

システムデューデリジェンスとは、事業譲渡やM&Aの際に、譲渡対象となるシステムやIT資産の現状を詳細に調査し、リスクを特定するプロセスです。主に、譲渡後に予期しない障害やコストの増加を防ぐために実施されます。

システムDDの手順実例

私が行ったシステムDDの手順を振り返ると、以下の手順に整理できました。

  • 事前準備
    • 前提・目的の認識合わせ
    • 調査範囲の明確化
  • 調査
    • システムの満たしたい状態の定義
    • ドキュメントの満たしたい状態の定義
    • システム評価
      • 調査項目の洗い出しとグルーピング
        • アプリケーション(iOS/Android/サーバー)
        • インフラストラクチャ(AWS)
    • 現場エンジニアへのヒアリング
  • 調査後
    • 見つかった課題・リスクにおける対応の整理

ここからはそれぞれの手順について詳細を紹介します。

事前準備

前提・目的の認識合わせ

システムDDを進めるにあたり、まず最初に取り組んだことは事業譲渡における前提や目的の認識合わせです。

システムDDは社内でも初めても取り組みでもあることに加え、デューデリジェンスは実際にはその時の事業状況や、事業譲渡の目的などによって具体的な調査範囲・内容は変わり得るため、認識を合わせる必要があると考えました。認識合わせは当たり前なことですが忘れてはいけない大切な作業だと考えています。

今回の場合、事業譲渡がプロダクト単位で複数のプロダクトが譲渡対象であることや、各プロダクトの所有権や権利等の状況が異なる状況であること、のようなことが前提となります。

そして、主な目的は、譲渡対象となるIT資産の現状を把握し重大なリスクを特定することです。特に、譲渡後の運用が想定通りの工数で行えるか、また運用に影響を与える潜在的な課題やリスクを洗い出すことが重要でした。さらに、前提を踏まえると譲渡対象のソフトウェア資産を特定することも大事な目的になります。

調査範囲の明確化

以上の前提と目的を踏まえ、以下の点が重要となります。

  • プロダクト固有のリスクの評価
  • 運用に要する工数の把握、および運用に影響するリスクの特定
  • 譲渡対象のソフトウェア資産の洗い出しと特定

これらの点を踏まえて調査範囲を明確化し、システムDDを行いました。

調査

ここからは具体的に行った調査方法について紹介します。

システムの満たしたい状態の定義

運用保守への影響確認という前提の観点を踏まえて、譲渡後にエブリーが運用保守していくあたり、困難なく開発・保守・運用できるかどうかという観点で、システムの満たしたい理想状態を定義し、その状態との差分を確認していくことで調査および評価を行いました。

例えば、「バグ検知」という調査の大項目については以下のように定義しました。

  • エラー検知の仕組みが導入されていてバグやシステム異常の発生が即時に検知・通知されること
  • 各システムの各種メトリクス監視
  • アプリのクラッシュ計測

など...

このような定義との差分をドキュメントや、実際のソースコードおよびシステム構成の確認、現場エンジニアへのヒアリングなどを通して確認していきました。 また、満たしたい状態を定義することで、調査の際に確認すべきポイントが明確になります。

システム状態定義のイメージ

ドキュメントの満たしたい状態の定義

システムの状態定義と同様に、ドキュメントについても運用保守という観点を踏まえて期待する状態を定義し、その状態との差分を確認していくことで調査および評価を行いました。

例えば、「DB設計書・ER図」というドキュメントについては以下のように定義しました。

  • 下記の内容を把握でき、結果としてDBの運用・改修が可能な状態
    • 各物理データベース
      • 用途
      • スペック
      • DBMS ソフトウェアバージョン
      • 各種メトリクスの閲覧方法
      • 異常時の検知手法・対応手法
    • 各論理データベース
      • 各テーブルの構成、ER 図
      • 各テーブルやビュー・ストアド等の用途
      • 各テーブルやビュー内のカラムの定義

以下のようなドキュメントについて、同様の状態定義を行い、評価していきました。

  • 外部システム連携仕様書
  • 機能一覧
  • 要件定義署
  • 機能仕様書
  • API設計書
  • DB設計書・ER図
  • ログ設計書
  • 各種アカウント情報
  • 環境構築手順書
  • リリース手順書
  • 管理画面操作手順書
  • 画面一覧・画面遷移図
  • デザイン
  • バッチ処理概要
  • レポート作成マニュアル

など...

ドキュメント状態定義のイメージ

システム評価

システム評価では、上記の満たしたい状態を踏まえつつ、調査項目を洗い出してグルーピング行い、それぞれの調査項目についてGitHubやAWS環境などに招待いただいて閲覧操作することで評価を行いました。

アプリケーション(iOS/Android/サーバーなど)

アプリケーションの評価は、以下のグルーピング項目に基づいておよそ40項目ほどの調査項目を確認していきました。 確認対象のリポジトリは約30個ほどあり、膨大な作業量であったため、現場エンジニアへのヒアリングを交えながら効率的に調査を進めました。

評価のグルーピング項目

  • ソースコード品質
  • 設計
  • プロセス
  • セキュリティ
  • パフォーマンス
  • 構成要素

具体的な調査項目(一部抜粋)

  • ソースコード品質
    • コードベースの長さ
    • コードベースの複雑さ
    • テストコードのカバレッジ
    • エラーハンドリング
    • 適切なコメントの有無
    • 一定期間内のエラー件数
    • 既知の不具合の数
    • コーディング規約の有無
    • 言語/FW/ライブラリのバージョン

など...

可能であれば、全てのソースコードを実際に動作させて運用保守への影響を確認することが望ましいです。

アプリケーション評価項目のイメージ

インフラストラクチャ(AWS)

インフラストラクチャの評価は、AWS環境に関する以下のグルーピング項目に基づいて行いました。AWSアカウントに招待していただき、各項目に沿って確認しました。 アプリケーション評価と同様、現場エンジニアへのヒアリングを交えながら調査を進めました。

評価のグルーピング項目

  • アーキテクチャ設計
  • セキュリティ
  • コスト管理
  • 運用・保守

具体的な調査項目(一部抜粋)

  • アーキテクチャ設計
    • VPC設計
    • ネットワーク構成
    • データベース設計
    • コンテナ化の有無
    • IaCの有無
    • CI/CD構成
    • ログ収集とモニタリング
  • セキュリティ
    • IAMポリシーとロールの設定
    • セキュリティグループとネットワークACLの設定
    • データの暗号化
    • ログ管理と監視

現場エンジニアへのヒアリング

上述の調査での不明点や把握しきれない点について、現場エンジニアの方々からヒアリングを行いました。 現場のエンジニアの方々は、システムの現状をよく理解しているため、ヒアリングを通して価値のある情報を多く早く得ることができます。 ヒアリングは必須の作業として行うと望ましいです。できればシステムDDの早い段階で行い、かつ定期的に行うことで効率的に調査を進めることができると思います。

見つかった課題・リスクにおける対応の整理

以上の調査を行った結果、見つかった課題・リスクを一覧化し、それぞれに対して影響範囲を整理しました。 その内容をもとに先方と対応方針について協議を行いました。

やっておけばよかったこと

譲渡後に運用保守を始めから振り返ってみて、システムDDでいくつかやっておけばよかったと感じたことがありました。主に運用してみて想定外の工数に繋がったものです。

  • システムの移管作業を想定した調査観点の追加
  • 既知の不具合に対する詳細と影響範囲の把握

など...

譲渡契約後にシステムを当社に移管する作業を行う進め方をしましたが、実際に移管作業を始めると、移管するための事前作業で多くの工数を要するものがあることがわかりました。 例えば、iOSアプリの移管について、キーチェーンやAppleでサインイン機能を利用しているiOSアプリを別組織に移管すると、それらの機能が一時的に利用できなくなることがわかりました。これらをユーザー影響なく移管するには多くの工数を要するため、譲渡時には想定していなかった想定外の工数となります。

また、把握していた既知の不具合が譲渡後に想定外の影響を及ぼし、改修するのに多くの工数を使ったケースがありました。事前に不具合の詳細と影響範囲の把握を行っていれば、多少は事前に織り込めたと思います。

まとめ

今回の経験を通じて、事業への影響を最小限に抑えるために事前にシステムDDを行うことの重要さを再認識したとともに、観点やノウハウなど知見を貯めることができました。 また、5つのプロダクトを同時に移管するという稀有な経験から、私自身の成長として、未知で決まった答えのない領域に対して試行錯誤しつつ最大限の決定を繰り返して推進していく能力が向上したと感じました。

本記事が少しでもどなたかのお役に立てれば幸いです。

Vue Fes Japan 2024 でゴールドスポンサーとして協賛します!

はじめに

こんにちは、トモニテ開発部ソフトウェアエンジニア兼、CTO 室 Dev Enable グループの rymiyamoto です。

この度、エブリーは 2024 年 10 月 19 日(土)に開催される『Vue Fes Japan 2024』に、ゴールドスポンサーとして協賛することになりました!

vuefes.jp

エブリーでは、DELISH KITCHEN を現在 Nuxt.js(Vue.js)で構築しており、2018 年から採用しています。
今回の協賛を通して、さらなる Vue.js コミュニティの発展に貢献できればと考えております。

近年は Vue.js 周辺のエコシステムでは新たな潮流も生まれつつあり情報交換や交流を通じて、新たな出会いや気づきを得ることができるでしょう。

ぜひ、タイムテーブルをご覧いただき、気になるセッションに参加してみてください。

vuefes.jp

エブリーにおける Nuxt.js(Vue.js) の活用

Nuxt.js 導入の背景

エブリーでは、DELISH KITCHEN の Web を最初Riot.jsという SPA ライブラリと クローラー向けには静的な HTML を返すため、Express を使って SSR を行っていました。 この構成上コードが二重管理されており、新規ページや機能の開発、運用コストが大きくなっていました。

このような課題を解決するために、Universal アプリケーション(SSR + SPA)の開発が可能な技術を検討し、Angular Universal、Next.js、Nuxt.js の中から Nuxt.js を選択しました。

選定の決め手は以下の通りです。

  • バックエンドに強いチーム構成で、Web フロント開発に長けたメンバーが少なかったため、Nuxt.js のような薄いフレームワークが取り掛かりやすいと考えた。
  • チーム内に Vue.js の開発経験者がいた。
  • Riot.js の SFC(Single File Component) の構造が Vue.js のコンポーネントと似ていたため、システムリプレースが容易だった。

移行後のメリットとして、ユーザー向けとクローラー向けのコードの二重管理がなくなり、一元管理が可能になりました。
これにより開発や QA のコスト削減が実現され、Nuxt.js(Vue.js)の豊富なドキュメント、ライブラリ、活発なコミュニティの恩恵を受け、開発の問題解決が容易になりました。

詳細については、以下の記事をご参照ください。

tech.every.tv

他にもエブリーのテックブログでは、Vue.js に関する記事を随時公開しています。

Nuxt3 化に向けた取り組み

2018 年から Nuxt.js を採用してきたエブリーでは、現在 Nuxt3 化に向けた取り組みを進めています。 こちらも合わせてご覧ください。

tech.every.tv

tech.every.tv

tech.every.tv

Vue.js の開発効率化

Vue.js を活用して開発開発効率化を図るために、VueUse を扱った内容も公開しています。

tech.every.tv

tech.every.tv

皆様とお会いできることを楽しみにしています!

私たちのブースでは、Vue の活用事例等をご紹介する予定です。

またブースには素敵なノベルティもご用意しております。詳細はまた追ってお知らせいたしますので、ぜひ、お気軽にお立ち寄りください!

Pre Party を共同開催します!

エブリーでは、Vue Fes Japan 2024 を盛り上げるべく、同じくスポンサーである OPTiM さんと共同で Pre Party を開催します!

optim.connpass.com

LT(ライトニングトーク)が主体のカジュアルなイベントとなっております。 募集枠は全部で 4 つありますので、ぜひ奮ってご応募ください!

Vue Fes Japan 2024 の参加予定の方や、惜しくも参加できない方も、ぜひご参加ください!

こんな方におすすめです!

  • Vue Fes Japan 2024 に向けて、知り合いを増やしたい方
  • Vue Fes Japan 2024 のプロポーザルがリジェクトされた、敷居が高いと感じた方で LT で発表してみたいなと思っている方
  • Vue に興味があるエンジニアや学生の方
  • Vue での開発に従事されている方
  • OPTiM、エブリー がどのように Vue を活用した開発をしているのか興味がある方
  • OPTiM、エブリー のエンジニア組織について興味がある方

Vue を中心に知識と交流の輪を広げましょう!

※本勉強会/LT会はVue Fes Japan公式のものではなく、スポンサー同士の有志のイベントとなります。そのため本勉強会へのお問い合わせをVue Fes Japan様へ行うことはご遠慮ください。

エブリーでは、ともに働く仲間を募集しています。

エブリーでは、ともに働く仲間を募集しています。

テックブログを読んで少しでもエブリーに興味を持っていただけた方は、ぜひ一度カジュアル面談にお越しください!

corp.every.tv

X ではテックブログや登壇情報、インタビュー記事などエブリーのエンジニアに関する情報を発信していますので、ぜひご覧ください。

https://x.com/every_engineer

最後までお読みいただき、ありがとうございました!

Android Studio での Gemini 連携について

はじめに

こんにちは、DELISH KITCHEN でクライアントエンジニアを担当している kikuchi です。

昨今 AI がますます普及し業務で AI を活用する事例も増えてきましたが、Google が提供している Gemini が Android Studio の一機能として提供されていることをご存知でしょうか?
2024/9/13 時点ではまだプレビュー版ではありますが無料で公開されていますので、今回は実際に使用した際の環境構築手順、使用感などをまとめてみたいと思います。

Gemini の詳細は今回割愛しますが、Gemini は大きく分けて無料版の Gemini、有料版の Gemini Advanced と分かれており、現時点では Android Studio は無料版の Gemini と連動しているようです。

事前準備

Android Studio と Gemini を連携する場合は Google アカウントが必須となりますので、事前に作成をしておいてください。
なお、プレビュー版では Gemini Advanced への加入状況は反映されないため、Gemini Advanced への加入は不要です。

環境構築手順

  1. 公式サイト から Canary 版 (2024/9/13 時点では Ladybug) をダウンロードし、Android Studio を起動します

  2. プロジェクトを生成後、右上にある Gemini のアイコンをクリックします

  3. 「Log in to Google」をクリックするとブラウザが起動するためブラウザで認証を通し、完了後に「Next」をクリックします

  4. プライバシーポリシーを確認し、「Next」をクリックします

  5. 利用規約を確認し、チェックを付けて「Next」をクリックします

  6. プライバシー設定を確認し、任意の項目にチェックを付けて「Finish」をクリックします

以上で Gemini の機能を使用できる準備が完了しました。

操作方法について

操作方法はコメント入力欄に質問内容を入力し 「Submit」 をクリックすると AI が回答をしてくれるという形で、通常のブラウザ上で操作するものと大きな違いはありません。
以下は 「ログイン画面のソースファイルとレイアウトファイルを作成して」 と質問した時の回答です。

AI のサービスを使用したことがある方は違和感なく使用できるかと思います。

ファイル操作

Android Studio の Gemini では通常のブラウザ上で使用するようなチャット形式でやり取りが出来る点に加え、生成したソースコードに対して特殊な操作が行えるようになります。

上記は実際に Android Studio 上の Gemini で生成したソースコードの直下に表示されるアイコンですが、左から順に

  1. Copy → ソースコードをコピーする
  2. Insert at Cursor → カーソルが当たっている箇所に該当のソースを挿入する
  3. Insert in New Kotlin File → ソースコードを新規ファイルとして生成する (レイアウトファイルの場合はレイアウトファイルとして新規で生成する)
  4. Explore in Playground → 生成されたコードを Playground 上で確認する

といった操作が行えます。
1、2、4 についてはソースコードのコピーやコピー&ペーストを一括で実施してくれる機能となりますが、3 についてもう少し細かく動きを見てみたいと思います。

Insert in New Kotlin File の実施例

実際に回答結果で出力されたソースファイルの「Insert in New Kotlin File」を実行してみたいと思います。
ファイルを追加したいディレクトリを選択した状態で「Insert in New Kotlin File」のアイコンをクリックします。

実行後、ファイルが自動的に追加された上、androidx.appcompat:appcompat:1.7.0 のライブラリが不足していることを検知し、追加するかの提案もしてくれます。

「Add」 をクリックすると build.gradle に追加してくれるだけでなく、Version Catalog でライブラリを管理している場合は libs.versions.toml にも変更を加えてくれます。

1 つ注意点としては、AndroidManifest.xml には自動的に定義が追加されないため、手動で activity の定義を追加する必要があります。

1 つ手動操作が必要なものの、ソースコードはファイル生成からライブラリの導入までスムーズに行うことが出来ました。
では引き続きレイアウトファイルの生成を行ってみます。

レイアウトファイルの場合はアイコンの説明が「Insert in New Layout File」になるため、そちらのアイコンをクリックします。

レイアウトファイルの場合はここで 2 つほど問題が発生してしまいます。追加後の状態は以下の画像のようになります。

問題の 1 つ目、どのディレクトリを選択していても res ディレクトリ直下に「new.xml」というファイル名で生成されてしまうため、手動でリネームとパス移動が必要になります。
そして 2 つ目、自動生成されたレイアウトファイルは ConstraintLayout を使用していますが、このプロジェクトでは androidx.constraintlayout:constraintlayout のライブラリを設定しておらず、
こちらはソースコードの場合と違ってライブラリが不足していることを検知しませんでした。
レイアウトファイルの自動生成については、手動操作、エラーの解析、ライブラリの追加が必要となってしまいます。

本項でファイルの自動生成を試してみましたが、ソースファイルの生成は容易なものの、レイアウトファイルの生成にはまだまだ課題がありました。

コード補完

前項ではチャット形式でのやり取りについて説明しましたが、実際のソースコードのドキュメント作成や補完を行えるコード補完の機能についても触れたいと思います。
先ほど自動生成したファイルのメソッドで右クリックをすると以下の機能を選択できます。

こちらは上から順に

  1. Document Function "<メソッド名>" → メソッドの KDoc を作成する
  2. Comment Code → 処理にコメントを付ける
  3. Explain Code → 処理の解説をする
  4. Suggest Improvements → 処理の改善案を提示する
  5. Rethink variable names → 無反応のため不明 (直訳だと変数名の再定義)

となっており、どれも該当のソースコードに特殊なプレフィックスを付けてチャット欄に貼り付けるものでした。
最終的には通常のチャット形式でのやり取りになるため、3 のみ試してみたいと思います。

Explain Code の実施例

実際にメソッドの部分で Explain Code を選択すると以下の警告が表示されます。

解析のために Gemini のサーバーにソースコードを送信してよいかという質問になります。機密情報を含むソースコードの取り扱いには注意が必要なため、適切な判断をする必要があります。
今回は先程 Gemini で自動生成したソースコードのため、そのまま送信をしてみます。

プレフィックスとして Explain the following code: というものが付いて、後は丸々ソースコードがチャット欄に貼り付けられる、という挙動になりました。
あとは「submit」をクリックします。

ソースコードの解析結果がチャット欄に出力されました。
こちらはチャット欄で「コードを解析して」といった文章を入力したり、ソースコードをコピー&ペーストする手間を省く効果が期待できそうです。

注意点

おそらく 1 時間に 10 回程度質問のやり取りをしたところで上限に達してしまいました。1 時間程度待てば再度使用できるようになりましたが、ここは現時点で無料版を使用しているための制限になるかと思います。

実際の使用例

色々と試した中で一番便利に感じたのは、ファイル操作の「Insert at Cursor (カーソルの位置に自動挿入)」と「Insert in New Kotlin File (ファイル自動生成)」を組み合わせて使用する形でした。
具体的な例を記載してみます。

  1. 「ログを出力する Utility クラスを作成して」と質問し、出力結果で「Insert in New Kotlin File」を実行しファイルを自動生成する

  2. 「verbose のログを出力するメソッドを作成して」と質問し、出力結果で「Insert at Cursor」を実行しクラスを拡張する

手動で実装することなくチャットによるやり取りのみでクラスの生成、クラスの拡張を行うことが出来ました。
ビジネスロジックを含むようなクラスの生成は難しいかもしれませんが、Utility クラスや data クラスなど単純なメソッドの組み合わせになるようなクラスであればこちらの方が速く実装できる可能性があります。

まとめ

今回 Android Studio の Gemini 機能を使用してみましたが、ブラウザと Android Studio を行き来する手間もなくなり、ファイルの自動生成など Android Studio の操作の手間をかなり軽減し、
また最低限の知識さえあればソースコードをほぼ書かずに実行ができる状態まで作れるため、開発のサポートとしては非常に強力だと感じました。

ただし、前述の通りまだプレビュー版のため、無料版の Gemini を使用していることで回答が返るまでに 10 秒程度かかってしまう点、レイアウトファイルの操作は完全に自動化されていないなど、
まだまだ課題も目立っています。
今後どう改修されていくかは分かりませんが、結局は Android 開発の正しい知識は必須であることには変わりないため、あくまで開発の補助に留めて使用するのがベストかと感じました。

今回紹介した内容が少しでも皆さまのお役に立てれば幸いです。