本連載では、プロのエンジニアによるアドバイスで伴走してもらいながら、いま話題の開発手法「バイブコーディング」を実践。初心者がつまずきやすいところなど、はじめの一歩から解説していきながら、オリジナルのウイスキー認識アプリの完成を目指す。
【画像】マイページを追加し、登録履歴の確認やタグなどによる絞り込みをできるようにした
前回までは……
「非エンジニアでもアプリを作りたい！」という思いから、生成AIを活用して自作アプリの開発（バイブコーディング）に挑戦するが、「公開の壁」に立ち尽くしてしまう筆者。
そこで、GMOインターネットグループの現役エンジニア、石丸智輝氏に教えを仰いだ。Google AI Studioでフロントエンドを作り込み、アプリの名前を「AiLA」に決定。開発の場をClaude Codeに移し、数々のトラブルを乗り越えながら、ついに登録ユーザーを管理者が承認しなければアプリを使えない「承認制ログイン」も実装。あわせて、Claude CodeのPlan Modeや、チャット版Claudeのプロジェクト機能、CLAUDE.mdの更新運用なども学んだ。
これは、素人とプロの二人三脚による、泥臭くもリアルな開発ドキュメンタリーである……
今回は、ローカル環境で動いているアプリをいったん仕上げ、次回のステージング環境公開に向けて不足機能や公開前の注意点を洗い出していく。
■ 調子に乗って自分で機能を追加してみたら、アプリらしくなってきた
前回の取材後、開発の進め方をある程度理解した筆者は、一人でVisual Studio Codeを使ってアプリのブラッシュアップにチャレンジしてみた。もちろんコードは書けないので、これまでと同様、Claude Codeに日本語で要望を伝え、出てきた実装を動かしてみて違和感があればまた直してもらう、という作業の繰り返しだ。
それでもお願いしたことのほとんどは実現し、どんどんアプリがリッチになっていくのが面白い。十分な機能を用意したと考えていたのに、ユーザー目線で使ってみると、次々とダメなポイントが見つかり、何度も修正を繰り返す。だんだん「AIに作らせている」というより「AIと一緒に作っている」という感覚になってくるのが最高だった。
具体的にはまず、全ユーザー向けにマイページを作成した。自分が登録したウイスキーの履歴を確認できるようにし、場所やタグで絞り込めるようにもした。ログアウトや退会のボタンはトップ画面に置くと邪魔なので、マイページの下部へ移動した。
管理者画面も少し強化した。前回実装した承認申請の管理に加えて、問題のあるユーザーを利用停止にする機能や、退会したユーザーが一定期間内であれば復活できるようなバッファ機能も追加した。さらに、お知らせを登録してユーザー画面に表示する機能も作ってみた。
とはいえ、筆者では判断がつかないこともあった。例えば、ブラウザーの［戻る］ボタンを押すと、アプリ内の前画面に戻るのではなく、アプリ自体が閉じたような挙動になるのだ。
そこで、Claude Codeに相談すると、ブラウザーバックに対応するにはアプリ全体の画面遷移の仕組みを見直す必要がある、という回答が返ってきた。
現状は画面を切り替えると、ブラウザーからは同じページ内で表示内容を変えているだけの作りになっているらしい。普通に対応するなら、各画面にURLを持たせ、ブラウザーの履歴とアプリ内の状態を連動させる必要があるとのこと。要するに「戻るボタンくらい簡単でしょ」と思っていたら、意外と根が深い問題だったのだ。手を出してよいのかわからないので、ひとまず各画面に［戻る］ボタンと［ホーム］ボタンを置く形で保留することにした。
■ 今日でローカル開発を完了させる。まずは石丸氏に中身を見てもらう
今回の取材では、最初に石丸氏をGitHubの共同作業者として追加した。筆者の手元で動いているアプリを口頭で説明するだけではなく、実際のリポジトリを見てもらうためだ。
GitHubでは、他の人をリポジトリに招待し、読み取り専用にするのか、変更を書き込めるようにするのか、といった権限を設定できる。非エンジニアからすると、GitHubに他人を招待する行為はなかなか大げさに感じるが、チームで開発するならごく普通の操作だという。
「今後チーム開発をする場合も、このようにGitHubへ招待して権限を設定します。読み取りだけ許可することもできますし、変更を書き込めるようにもできます。誰にどこまで任せるかを決めて、必要な範囲でアクセス権を渡すイメージです」（石丸氏）
最初に相談したのは、先ほど保留していたブラウザーバックへの対応だ。
「ブラウザーバックは、Webアプリケーションではよく議論になるポイントです。一般的なアプリケーションであれば、［戻る］ボタンで前の画面に戻れる方が使いやすいのはたしかです。ただ、フォーム入力や決済処理のように、状態管理が複雑な画面では、戻られると操作のやり直しになったり、データの整合性が崩れたりすることがあるので、対応の難易度がぐっと上がります。きちんと対応するには、アプリ側の画面遷移を見直してブラウザーの履歴と状態を連動させる必要があります。ユーザービリティの話なので最優先ではありませんが、使い勝手を考えると、いずれ対応するのもよいと思います」（石丸氏）
少し悩んだところだが、アプリの完成を優先することにする。
今回のゴールは「ローカル環境での開発を完了させる」こと。ここまででアプリは一通り動くようになっている。ログインもできるし、ウイスキーの情報も登録できる。管理者によるユーザー承認も動いている。筆者としては、もうかなり完成に近い気分だ。
しかし、いま動いているのは、あくまで自分のPC上のローカル環境だ。Firebaseエミュレーターなどを使って開発用に動かしている状態であり、このまま誰かに使ってもらえるわけではない。
「今回は追加で必要な機能がないかを確認し、動作や実装の気になるところを洗い出して、次の段階に進める状態にします」（石丸氏）
ローカル環境で動くアプリを作るだけなら、勢いで何とかなる部分も多いが、外部に公開するとなると話は変わってくる。ユーザーの権限やデータの扱い、APIの利用制限、エラー時の挙動など、見た目には出てこない確認事項が増えてくるのだ。
■ “AIがそれっぽく出した情報”を、そのまま信じてはいけない
もう1つ悩ましかったのが、ウイスキーのフレーバー情報だ。アプリではウイスキーのラベル画像などから情報を読み取り、銘柄や度数、産地などを整理して表示する。さらに、オレンジ、バニラ、スモークといったフレーバーも表示するようになっている。
ところが確認してみると、一部のフレーバー情報は、公式のテイスティングコメントを読み取っているわけではなく、AIが一般論からそれらしく付けていることがわかった。ユーザーが自分で編集できるので大きな問題ではないが、最初から表示される情報としては少し気持ち悪い。ウイスキー好きとしては、できれば公式のテイスティングコメントに近い情報を反映したいところ。
AIに相談すると、選択肢はいくつか出てきた。1つは、画像解析とは別にフレーバー情報を取得する処理をもう1回走らせる方法。ただし、APIを追加で呼び出すため、処理時間も料金も増える。もう1つは、代表的なウイスキーのフレーバー情報をあらかじめマスターデータとして用意しておき、該当する銘柄が登録されたときにそこから初期値を入れる方法だ。
「代表的なウイスキーのマスターデータを事前に作っておく方法はあります。例えば、柳谷さんがCSVなどでデータを用意し、それを初期データとしてプロジェクトに持たせる。登録されたウイスキーがマスターデータにあれば、それをもとにフレーバーをセットし、なければ別の処理を検討する、という考え方です」（石丸氏）
データベースを自分で持つとは考えもしなかったが、たしかに、ユーザー体験をリッチにし、ハルシネーションを抑えるにはよい方法かもしれない。API利用料を抑制できるのもメリットだ。すぐには準備することはできないが、ゆくゆくは対応しようと思う。
■ AIレビューで公開前の課題が一気に出てきた
筆者が考える機能は一通り開発できたので、次は公開準備に入る。
石丸氏のアドバイスに従い、Claude Codeに「現在のアプリの実装状況を確認し、不足している機能や実装すべき機能があるかどうかを調査してください」と質問した。
するとClaude Codeは、ソースコードを検索し、ファイル構成を読み取り、現在の実装を確認し始めた。ターミナルにはgrepやlsなどのコマンドが次々に表示される。AIが「いま何が足りないか」を調査しているのだ。
しばらくすると、Claude Codeは公開前に確認すべき項目をリストアップしてきた。その数はなんと10項目。うち、4つは「緊急（セキュリティ・コスト直撃）」となっている。ちょっと素人だと驚いてしまうが、石丸氏のアドバイスのもと対応していく。
具体的には、APIキーの扱いや、外部APIを呼び出す機能の利用制限、Firebaseに保存したデータへのアクセス権限ルールの見直しなど、公開時には必ず見直すべき項目が挙がっていた。なかには具体的に書くと攻撃のヒントになりかねない指摘もあったため、記事では詳細を伏せることにする。どこまで読者に共有し、どこから先を伏せるかも、公開前レビューで確認すべきポイントだとアドバイスしてくれた。
「アプリケーション開発では、本来のセキュリティ対策を施した上で、内部的に何を使っているか、どのような実装になっているかをむやみに外へ出さないことも、攻撃のヒントを減らす意味で大切です。連載として伝える部分と、伏せるべき部分のバランスは大事ですね」（石丸氏）
AIのレビュー結果を見ると、つい「全部直して」と言いたくなるが、それはリスキーだという。
石丸氏によると、複数の課題をまとめて修正すると、何が原因で動作が変わったのかわかりにくくなるとのこと。動作確認も複雑になり、Gitの履歴も追いづらい。重要な修正ほど、1件ずつ対応し、確認し、コミットするのが基本だという。
「まとめて修正してしまうと、品質の担保や動作確認が複雑になります。セーブポイントも、実装ごとに区切った方が安全です。AIが複数の指摘を出してきたときも、1つずつ確認して進めるのがおすすめです」（石丸氏）
このあたりは、非エンジニアがバイブコーディングでつまずきやすいポイントだと思う。AIが大量の改善案を出してくれると、それだけで賢くなった気がするが、本当に大事なのは、その中から「いまやるべきこと」「あとでやるべきこと」「そもそもいまの段階では不要なこと」を見分けることなのだ。
実際、Claude Codeが出した指摘の中には、次回のステージング公開時に対応すべきものもあれば、ローカル開発中のいますぐ直せるものもあった。筆者だけでは判断できないので、Claude Codeに追加で質問していった。
「非エンジニアにもわかるように説明してください」
「現在はローカル開発段階ですが、いま対応すべきですか」
「ソースコードの修正だけで対応できるものを優先してください」
「指摘内容をメモとして残してください」
こう聞くと、AIの回答が一気に扱いやすくなる。単に「危険です」「修正してください」と言われるより、なぜ必要なのか、いまやるべきなのか、公開時にやるべきなのか、が見えやすくなるからだ。
石丸氏は「AIへの伝え方や質問の仕方、いわゆる国語力はバイブコーディングでかなり重要」だと教えてくれた。AIの出力を理解できない場合はそのまま進めるのではなく「初心者にもわかるように説明して」と聞く。いま必要かわからないなら「ローカル開発中のいまやるべきか」と聞く。地味だが覚えておきたいノウハウだ。
■ 見た目は変わらなくても、公開前の品質は着実に上がっている
最終的にはいくつかの改善をClaude Codeに任せた。
例えば、エラーが起きたときに画面が真っ白にならないようにする処理や内部的なコードの整理といったところだ。ユーザーから見ると大きく変わらないが、アプリとしての安定性や保守性を高める修正だ。
この“見た目は変わらないが、中身を整える”作業は、非エンジニアにはかなりわかりにくい。ボタンが増えたり、画面がきれいになったりすれば成果が見える。しかし、エラー処理やコード分割、不要な重複の整理などは、画面だけ見ていても違いがわからない。それでも公開に近づくほど重要になってくるという。
作業後はアプリを一通り操作して違和感がないかを確認した。大きな問題はなさそうだったので、最後にコミットしてプッシュする。これでローカル開発の仕上げは一区切りだ。
今回、AIは実装だけでなくレビューにも使うことが大切だということを学んだ。公開が近づいてくると「足りないものは何か」「危ないところはないか」「いまやるべきことはどれか」をAIに聞く使い方が重要になる。
ただし、AIの指摘を鵜吞みにして一気に全部直すのは危険だということは肝に銘じておきたい。わからない言葉が出てきたら説明してもらい、いまやるべきかを確認する必要がある。直したら動作を確認して、Gitにコミットする。地味ではあるが、この積み重ねが、AI任せの危うい開発と、AIを使った現実的な開発の分かれ目なのだろう。
筆者も石丸氏が見ていなければ「全部任せます」と答えてしまいたくなるが、今後も頑張っていこうと思う。すでにわからないことを聞きまくっていると、AIが何を言っているのかをある程度理解できることも増えてきた。ペースは遅いかもしれないが、少しずつ学習できている手応えもあり、うれしい。
次回は、いよいよステージング環境へのデプロイに進む。ローカル環境で動いていたアプリをクラウド上に配置し、FirebaseやAPIキーの扱いなども公開前提の形に切り替えていく。自分のPCの中で動いていたアプリが、他の人にも見える場所へ出ていく。いよいよ「作っている」から「公開する」フェーズに入るとしよう。
（第9回へ続く）
■ 著者プロフィール：柳谷 智宣
IT・ビジネス関連のライター。キャリアは26年目で、デジタルガジェットからWebサービス、コンシューマー製品からエンタープライズ製品まで幅広く手掛ける。近年はAI、SaaS、DX領域に注力している。日々、大量の原稿を執筆しており、生成AIがないと仕事をさばけない状態になっている。
・著者Webサイト：https://prof.yanagiya.biz/
窓の杜,柳谷 智宣