「AIでコードを書く時代」とよく言われますが、実際にどこまで作れるのか。
今回は、ChatGPTと対話しながら Androidアプリをゼロから実装 してみた記録を、ひとつの記事としてまとめます。
作ったのは、現在地をもとに近くのスポットを提案し、徒歩ルートを表示し、到着するとポイントがたまる 「今日の小さな旅」提案アプリ です。
単なるサンプルアプリではなく、実際に自分のスマホで起動し、位置情報を使い、Google MapsやPlaces APIとも連携しながら作り上げました。
途中ではクラッシュ、テーマエラー、権限まわりの問題、APIレスポンスの例外など、いかにもAndroid開発らしい壁にも何度もぶつかりました。
この記事では、AIでAndroidアプリを作る流れ、どこでハマったか、AIをどう使うと前に進めるか を、実体験ベースで詳しく紹介します。
この記事で作ったアプリの概要
今回作成したアプリのコンセプトは、日常の中で気軽に使える「小さな旅」の提案です。
アプリを開くと現在地を取得し、その周辺の観光地や散歩候補を提案します。
候補には画像、名称、徒歩時間、距離を表示し、Google Map上にルートも描画します。
さらに、現地に実際に到着するとポイントが加算される仕組みも入れました。
最終的には以下のような機能を実装しました。
実装した主な機能
1. 現在地の取得
スマホの位置情報を使って、ユーザーの現在地を取得します。
最初はここがうまくいかないと何も始まりません。
2. 近くのスポット提案
Google Places APIなどを使い、現在地付近の候補を取得。
最初はカフェ中心で考えていましたが、途中で「散歩候補の観光地」に方向転換しました。
3. 地図表示
Google Maps SDK for Android を使って、現在地と目的地を地図上に表示。
4. 徒歩ルート表示
Directions系の処理を使って、徒歩での移動ルートを描画。
時間や距離も併せて表示します。
5. 写真表示
目的地の写真を表示し、見た目としても「行ってみたい」と思えるアプリに近づけました。
6. 到着判定とポイント加算
「到着」ボタンを押した時に、目的地から100m以内にいる場合のみ到着扱い にする仕様を実装。
到着できたら、その旅の徒歩時間ぶんだけポイントが加算されます。
7. ポイントの永続化
ポイントは SharedPreferences に保存し、アプリを再起動しても残るようにしました。
最初は「pt」表記でしたが、途中で仕様を変えて 1分 = 1 point、単位は min に変更しました。
なぜこのアプリを作ろうと思ったのか
普段の生活の中で、遠くへ旅行するほどではないけれど、少しだけ気分を変えたい時があります。
カフェに行くでもいいし、知らない神社や公園に寄るのでもいい。
そんな「小さな移動」や「軽い散歩」を、アプリとして提案できたら面白いと思いました。
しかも、自分のブログや活動テーマである 旅・日常・体験 とも相性がいい。
単なる技術練習ではなく、自分のコンセプトに合ったアプリを実際に形にするのが今回の目的でした。
AIでAndroidアプリを作る流れ
今回の開発で面白かったのは、すべてを自分一人で調べて組み立てるのではなく、AIと対話しながら少しずつ作っていったこと です。
最初から500行の完成版コードを一発で貼って終わり、ではありませんでした。
実際には、以下のような流れで進めました。
ステップ1：アイデア出し
最初に「ryotravel.comのコンセプトに合うAndroidアプリ案」を複数出してもらい、その中から「今日の小さな旅」提案アプリを選定。
ステップ2：ロードマップ作成
いきなり実装に入るのではなく、環境構築から始めるロードマップを作成。
何をどの順でやるべきか整理できたのが大きかったです。
ステップ3：位置情報取得
まずは最低限、現在地を取得して表示するフェーズへ。
Android特有の権限まわりでかなり詰まりました。
ステップ4：地図表示
Google Maps SDKを導入して、マップを表示。
この段階で「アプリらしさ」が一気に出てきます。
ステップ5：スポット提案
Places APIなどを使い、周辺候補を提案する機能を追加。
ステップ6：徒歩ルート描画
目的地までのルートをマップに描画し、時間や距離を表示。
ステップ7：到着判定とポイント機能
ゲーム性を少し入れるために、現地到着で加算される仕組みを追加。
実際にハマったポイント
AIがあるからといって、何の問題もなくスムーズに完成するわけではありません。
むしろ、エラーを貼って一緒に直す という使い方がかなり重要でした。
今回、特に印象に残ったハマりどころを紹介します。
1. MainActivity が見つからず起動時にクラッシュ
最初の大きな壁はこれでした。
ログには ClassNotFoundException: Didn't find class "com.example.testapp1.MainActivity" と出ており、アプリ起動直後に即落ち。
これは、パッケージ名や AndroidManifest.xml の記述、ファイル配置の不整合などが原因になりやすい典型的なパターンです。
AIにログをそのまま貼り、どこを確認すべきかを順番に整理してもらうことで解決できました。
この時感じたのは、AIは「正解コード生成」だけでなく、エラーログの読解補助役として非常に強い ということです。
今回出たエラーはKotlinでのAndroidアプリ作成あるあるのエラーらしいのですが、Kotlinを初めて触る私にとってはどこを確認するべきかも定かではありませんでした。
2. Theme.AppCompat / MaterialComponents エラー
次に詰まったのがテーマです。You need to use a Theme.AppCompat theme やThe style on this component requires your app theme to be Theme.MaterialComponents
といったエラーで落ちました。
これは、MaterialButton などのコンポーネントを使っているのに、テーマ設定がそれに対応していないと起こります。
UIを少しおしゃれにしようとして MaterialButton を使った瞬間に落ちたので、「見た目改善で逆に壊れる」という、Androidらしい体験をしました。
AIに相談すると、テーマとコンポーネントの関係を分解して説明してくれるので、「なぜそのエラーが起きるのか」がわかりやすかったです。
3. 権限チェック不足による警告・不具合
位置情報まわりでは、checkPermission を明示的にやるべきという警告や、SecurityException を考慮しろという指摘が出ました。
Androidでは位置情報取得だけでも、
- マニフェストへの権限追加
- 実行時パーミッション要求
- 許可後の処理分岐
isMyLocationEnabledの例外対策
など、細かい配慮が必要です。
このあたりは、断片的に調べると混乱しやすいですが、AIに「このコードに対して必要な権限処理を全部入れて」と依頼すると、かなり整理された形で返してくれました。
4. APIレスポンスが空で落ちる
ルート取得やスポット取得では、次のようなエラーにも遭遇しました。
Collection is emptyIndex 0 out of rangeJSONArray.getJSONObject(0)で落ちる
これは、APIから期待通りのデータが返ってこなかった時の例外です。
特に「近くに候補がない」「徒歩経路が見つからない」などは実運用では普通に起こりえます。
ここで学んだのは、AIに「正常系のコード」を書かせるだけでは足りず、空配列や null をどう処理するかまで含めて書かせる必要がある ということでした。
5. 見た目は動くけれどUIが終わっている問題
機能が一通り動くようになると、次に気になってきたのがUIです。
正直、最初の画面はかなり素朴でした。
そこでタイトル色、カードレイアウト、総ポイント表示、ボタン配置などを改善。
タイトルの横に大きく総ポイントを表示するように変更したことで、かなりアプリっぽくなりました。
この段階では、AIに「エンジニア向けの無骨な画面ではなく、もう少しおしゃれにしたい」と伝えると、XMLレイアウト改善案をそのまま出してくれたのが便利でした。
AIでAndroidアプリを作って感じたメリット
ここまで実際に作ってみて、AI開発のメリットはかなり大きいと感じました。
1. 詰まった時の突破速度が速い
エラーを見て、調べて、原因候補を洗い出して、修正箇所を探す。
この流れを一人でやるより、AIにログを渡して一緒に見るほうが圧倒的に速いです。
2. ロードマップを作りながら進められる
「次に何をやるべきか」が見えやすくなります。
特に初心者〜中級者にとって、次の一歩を示してくれるのは大きいです。
3. 部分修正との相性がいい
「ここだけ直したい」「この関数だけ完成版を出して」「このエラーだけ見て」という使い方がとても強いです。
Android開発は一発で完成させるより、少しずつ直すほうが現実的です。
4. 学習にもなる
ただコピペするだけだと危険ですが、ログと修正内容を見比べることでかなり勉強になります。
特にテーマ、パーミッション、API例外処理は、今回かなり理解が深まりました。
AI開発で難しかった点
一方で、AIに任せれば何でも完璧というわけでもありません。
1. プロジェクト全体の整合性は自分で見る必要がある
MainActivity.kt だけ正しくても、Manifest、Gradle、XML、クラス名がズレていたら動きません。
Androidはファイル横断で整合性が必要なので、そこは人間側の確認が欠かせません。
2. そのままでは動かないコードもある
特にAPIキー、依存関係、テーマ設定など、環境依存の部分は調整が必要です。
AIが書いたコードをそのまま盲信するのは危険です。
3. エラーの貼り方で精度が変わる
「動きません」より、
「このログが出ています」
「この行で unresolved reference が出ています」
と具体的に伝えたほうが、圧倒的に精度が上がります。
今回のアプリで特に気に入っている仕様
個人的に気に入っているのは、到着判定とポイント仕様です。
最初は単純なポイント制でしたが、途中で発想を変えて、徒歩時間をそのままポイント化する ことにしました。
つまり、10分歩いた旅なら 10 min、25分歩いた旅なら 25 min が加算されます。
この仕様にしたことで、「何点もらえるか」よりも「どれだけ歩いて小さな旅をしたか」が記録される感覚になりました。
このアプリの世界観にもかなり合っています。
さらに、到着判定を「ボタンを押しただけ」でなく、現地50m以内でのみ到着扱い にしたことで、少しゲーム性も出ました。
単なるUI上の疑似ポイントではなく、実際に足を運んだ記録になるのが面白いところです。
これから追加したい機能
現時点でも十分アプリとして成立していますが、今後入れたい機能もいくつかあります。
カテゴリ切り替え
カフェだけでなく、神社、公園、展望スポット、川沿いなどを切り替えられるようにしたいです。
履歴機能
これまでに行った場所や獲得した min を一覧で見られるようにしたいです。
バッジ機能
累計100 min、500 min、1000 min など、歩いた時間に応じてバッジがもらえると楽しくなりそうです。
ブログ連携
訪れた場所のログを、そのままブログ記事の下書きに変換できたら、自分の活動ともつながります。
AIでAndroidアプリを作りたい人へ伝えたいこと
実際にやってみて思うのは、AIを使ったアプリ開発は「魔法」ではないけれど、かなり強力な相棒 にはなる、ということです。
特におすすめなのは、次の進め方です。
小さく始める
最初から全部入りを目指さず、まずは「ボタンを押したら文字が変わる」でも十分です。
エラーをそのまま貼る
うまく動かない時こそ、ログをそのままAIに見せるのが早いです。
一部分ずつ完成させる
Activity全部を毎回作り直すより、suggestTrip() だけ、activity_main.xml だけ、という切り方のほうが安定します。
最後は自分で確認する
AIが出したコードは必ず自分で見て、整合性や例外処理を確認したほうがいいです。
今回の制作を通じて考えたこと
コーディングはAIが行えば明らかに作業効率化を図れます。
というのもこれまでのアプリ開発では、
「人が作りたいものを考える」→「人の言語から機械語に翻訳」→「ソフト完成」
だったものがAIを使うことにより、
「AIが人が欲しそうなものを考える」→「AIが機械語に翻訳」⇔「人がチェック」→「ソフト完成」
という流れになります。
開発のスピードが向上することはもちろん、機械語を知っているという特殊技能が備わっていない人でも簡単にアプリを開発できるようになるわけです。
物理的な労働力が蒸気機関に置き換わった時と同じくらいのインパクトがあるとはよく言ったものです。今回の制作を通じてもその通りだなと感じました。
さて今IT業界にいる人はほとんどが大学や専門学校でプログラミングを学び、開発の技術やお作法を学んできたわけです。しかし今回のように安易にアプリが制作できてしまうとしたら、4年間で培ったプログラミングスキルはほとんど意味をなさないものになっていきます。では彼らは何を学べばよいのでしょうか。
業界の慣習として、「要求定義」→「要件定義」→「基本設計」→「実装」という流れでシステムを作成することがよくあります。また上流工程に行けば行くほどお給料も高くなります。
出典：SPIRAL 『要求定義』システム開発で設計前にすべきこと①
今回のケースでは要求定義、デザイン部分のみ半分私の意見を取り入れ、それ以外の工程についてはすべてChatGPTの言いなりとなっていました。
逆に言えば、こんなことができたらもっと良くなるのではないかという思い付きと、最終的にどのような形になったら美しいのかというデザイン部分ではまだ人が関与していく必要があるのかなと感じます。まあ、デザインの部分は人の好みがあるにしても目的に応じての正解があるので多少の知識がいるもののこちらもAIをうまく活用すれば簡単に置き換わってしまうでしょう。
蒸気機関が登場したときにどのようにものを動かすかではなく、どのような目的でものを動かすのか（移動なのか、発電なのか、水を送るのか）をより考えるようになったことと同じように、システム開発の世界でもどのような目的で作成するのかを考えるポジション以外は衰退していくことは確実です。ということで、プログラミング学習の時間を削っても、実際の社会課題などを題材にどのような打ち手を出せば解決できるかというアイデアを出す中で、先ほども触れた要求定義の部分を鍛える必要が出てきました。
まあ、実際に↑のような授業を行う高校、大学は増えていますもんね。
エンジニアとして仕事がなくなってしまうと悲観するのではなく、エラーと格闘するイライラの時間から解放される（ここではあの時間でアイデアを伴った生産はなされないという考えを採用します）ので私としては希望的な意見を添えます。
まとめ
今回は、ChatGPTと対話しながら Android アプリを作る流れを、実体験ベースで紹介しました。
作ったのは、現在地をもとに近くの散歩スポットを提案し、徒歩ルートを表示し、実際に到着すると歩いた時間ぶんの min がたまる「今日の小さな旅」提案アプリです。
開発中は何度もエラーで落ちました。MainActivity が見つからない、テーマが合わない、権限処理が足りない、APIレスポンスが空で落ちる。
でも、そのたびにAIへログを渡し、原因を絞り、少しずつ直していくことで、最終的にはちゃんと動く形まで持っていけました。
AIでの開発は、全部自動で終わるものではありません。
けれど、構想整理、コード生成、エラー解析、UI改善のすべてで大きな助けになります。
「アプリを作ってみたいけど難しそう」と思っている人ほど、まずは小さな一歩としてAIと一緒に作ってみる価値はあるはずです。
いろいろ書きましたが、自分のアイデアが会話の積み重ねで実際のスマホアプリになる体験は、かなり面白いです。
