はじめに
Google AI Studioで、プロンプトからAndroidアプリを作成できる機能が紹介されていました。
公式ブログによると、Google AI Studio上でプロンプトを入力することでKotlinベースのAndroidアプリを生成し、ブラウザ上のAndroid Emulatorで動作確認できるようです。
さらに作成したアプリは実機へインストールしたり、Google Playの内部テストトラックへ公開したり、ZIPやGitHub経由でAndroid Studioへ引き継いだりすることもできるとのことです。
かなり大きな変化だと感じたので、この記事ではAndroidエンジニア視点で気になった点を整理してみます。
できるようになったこと
今回紹介されていた内容をざっくり整理すると、以下のようなことができるようです。
- プロンプトからAndroidアプリを生成できる
- Kotlinベースのアプリを作成できる
- ブラウザ上のAndroid Emulatorで動作確認できる
- 実機にインストールできる
- Google Playの内部テストトラックへ公開できる
- ZIPやGitHub経由でAndroid Studioに引き継げる
これまでAIによるアプリ開発支援というとコード補完や一部実装の生成という印象が強かったですが、今回はアプリの叩き台を作るところまで一任できるレベルに寄ってきた印象です。
プロトタイプ作成にはかなり強そう
一番相性が良さそうなのは、プロトタイプ作成だと思います。
例えば、以下のような用途ではかなり便利そうです。
- 新規アプリのアイデア検証
- 社内向けの簡単なデモ作成
- UIイメージのたたき台作成
- 企画段階での画面イメージ共有
- 非エンジニアとの認識合わせ
特に企画段階では、どういうアプリにしたいかを文章で説明するより、実際に動くものがある方が認識を合わせやすい場面があります。
その意味では、Google AI Studioで素早くアプリの原型を作れるようになるのはかなり大きいと感じました。
Compose前提の流れとも相性が良さそう
最近のAndroid開発は、Jetpack Compose中心の流れがさらに強くなっています。
今回のようなAIによるアプリ生成でも、宣言的UIであるComposeとは相性が良さそうです。
XMLレイアウトの場合、画面定義、Adapter、ViewHolder、FragmentやActivityの実装など、構成が分かれやすくなります。
一方でComposeの場合、UIの構造をKotlinコードとして表現できるためAIが画面構造を生成しやすいのではないかと感じます。
もちろん、生成されたコードがそのまま実務品質になるかは別問題です。
ただ、AIによるAndroidアプリ生成とCompose中心の開発スタイルはかなり自然につながっていきそうな印象です。
実務でそのまま使うには注意が必要
一方で、実務でそのまま使えるかというとそこは慎重に考える必要があります。
特に気になるのは以下の点です。
- アーキテクチャが適切か
- 状態管理が破綻していないか
- エラー処理が考慮されているか
- セキュリティ的に問題がないか
- 保守しやすい構成になっているか
- テストしやすいコードになっているか
- 既存プロジェクトのルールに合っているか
個人開発やプロトタイプであれば、多少荒くても動くこと自体に価値があります。
ただ、チーム開発や長期運用するプロダクトでは、動くだけでは不十分です。
将来的に修正しやすいか、他のメンバーが読めるか、仕様変更に耐えられるか、といった観点が必要になります。
AIが作ったコードをどう扱うべきか
個人的な印象としては、AIが生成したコードは完成品ではなく叩き台として扱うのが現実的だと思います。
例えば、以下のような使い方です。
- Google AI Studioでアプリの原型を作る
- 画面構成や操作感を確認する
- ZIPやGitHub経由でAndroid Studioに持ってくる
- エンジニアが設計や実装を整理する
- 必要に応じて既存アーキテクチャへ組み込む
この流れであればAIのスピード感を活かしつつ、実務品質への調整もできます。
逆に生成されたものをそのまま本番投入するような使い方は、さすがにまだ怖さがあると思います。
Androidエンジニアの役割はどう変わるか
こうした機能が増えてくると、Androidエンジニアの役割も少しずつ変わっていきそうです。
これまでは、画面を作る、APIをつなぐ、状態を管理する、といった実装する力が中心でした。
もちろん今後も実装力は重要です。
ただそれに加えて、AIが生成したものを見て、
- この設計で問題ないか
- この状態管理で保守できるか
- この実装はAndroidとして自然か
- このコードはチームのルールに合っているか
- このまま進めるべきか、作り直すべきか
を判断する力がより重要になっていく気がします。
つまりコードを書く力だけではなく、コードを見極める力の価値が上がっていくのではないでしょうか。
非エンジニアとの距離も変わりそう
もう一つ気になったのは、非エンジニアとの距離です。
プロンプトからアプリの原型を作れるようになると、企画者やデザイナーが先に簡単なアプリイメージを作るケースも増えるかもしれません。
その場合、エンジニアはゼロから作るというより、
「この方向性なら実現できる」
「この仕様だと後でつらくなる」
「ここはプロトタイプでは見えていないが、実装上は考慮が必要」
といった形で、より早い段階から技術的な判断を求められるようになりそうです。
これは良い面もありますが、雑に作られたプロトタイプがそのまま仕様として扱われるリスクもあります。
そのためAIで作ったものはあくまで検討用であり、実装方針とは分けて考える必要がありそうです。
個人的な所感
今回の内容を見てAndroidアプリ開発もいよいよ、AIに一部を手伝ってもらう段階から、AIと一緒にアプリの形を作る段階に近づいてきた印象を受けました。
特にプロトタイプや小規模なアプリでは、開発初速がかなり変わりそうです。
一方で実務ではまだエンジニアの判断が重要です。
AIが作ったものをそのまま信じるのではなく、設計、保守性、セキュリティ、チーム開発への適合性を見ながら整えていく必要があります。
AIによってAndroidエンジニアが不要になるというより、Androidエンジニアに求められる役割が少し変わっていくのだと思います。
さいごに
AIによって開発が便利になっていく一方で、AIをツールとして使いこなすのか、逆にAIに振り回されてしまうのかが、エンジニアとしての差につながっていく時代が近づいているように感じます。
我々エンジニアとしてもAIとの向き合い方や、AIとエンジニアの最適な役割分担について、都度考えていく必要がありそうです。