• 2026/06/22 掲載

【保存版】Claudeへの“丸投げ”でバグ地獄…アプリ開発の成功率を爆上げする神設計(2/3)

会員(無料)になると、いいね!でマイページに保存できます。

丸投げはバグの温床…機能崩壊を防ぐ「3層構造」

 ソフトウェアはミルフィーユのように、複数の層が積み重なっている。Webアプリを例に取ると、大きく3つの層に分けられる。ユーザーが目にする「画面」(フロントエンド)、データを処理して判断を行う「処理」(ビジネスロジック)、そして情報を蓄積する「データ」(データベース)だ。処理とデータをまとめて「バックエンド」と呼ぶこともある。

 この3層を知っておく価値は、場所の特定にある。ボタンの色や画面の並びの話なら画面の層だ。保存したはずのデータが消えるなら、データの層に問題がある。どの層の話か見当がつくと、AIに「どこを直すか」を指示できるようになる。

画像
ソフトウェアはミルフィーユのように複数の層が積み重なっている。各層の役割を意識して指示することで、AIが生成するコードの絡み合いを防ぐことができる
(筆者が作成)

 すべてまとめて「こんなの作って」とAIに頼んだらとりあえず形になるが、機能を1つ足すたびに別の機能が壊れた、というのはよくある話だ。ソフトウェアの各層を分離しておく指示をしないと、生成されたコードが複雑に絡み合ってバグの温床となる。

 初期段階で、レイヤー(層)をきちんと分けて作るように指示しよう。さらに修正するときも「画面表示を修正してください」「データの設計は変えないで」もしくは「データの種類を増やして」などと層を意識して指示するだけで、AIの作業は安定する。

 さらに各層は機能ごとに複数の部品に分かれている。各層がどんな機能を持つか大ざっぱに把握できるとさらに指示の精度が上がる。自分が作るアプリがどんな層でできているか、ちょっとずつで良いので理解する努力をしよう。

入力データが消える悲劇を防ぐ「AI制御術」

 ここでいう「静と動」は、Web業界でよく言う「静的サイト/動的サイト」とは別の話だ。もっと素朴な区別で、設計の段階で決めておく「構造」と、実際の運用時に変化する「値」の違いを指している。

 構造(静)とは、画面の枠組みや項目の並び、メニューの配置のように、どのユーザーがいつ使っても変わらない部分だ。値(動)とは、ログイン中のユーザー名、入力中の文字、カートの中身、検索結果のように、状況によって変わる部分を指す。

 この「動く値」のことを「状態(state)」と呼ぶ。stateは設計やデバッグでよく登場する語なので、ここで知っておくと後で役に立つ。

 入力中の文字はページを離れると消える。カートの中身はログアウトすると消えるがログイン中は残る。保存済みの投稿はいつでも残り続ける。どれも「変わる値」だが、「誰のものか・どこにあるか・いつまで残るか」で見ると、それぞれ性質が違う。

「誰のものか」は、全ユーザーに共通の値か、特定のユーザーだけの値か。「どこにあるか」は、画面の中だけに存在するのか、ログイン中だけ一時的に保持されるのか、データベースに保存されるのか。「いつまで残るか」は、ページを読み込み直すと消えるか、ログアウトまで続くか、ずっと残り続けるか、といった話だ。

画像
同じアプリを使う2人のユーザーの画面。ナビゲーションやボタンの配置は同じ(静)だが、ユーザー名やカートの中身は人によって異なる(動)。この「構造」と「値」の違いを意識して指示すると、AIの実装精度が上がる
(筆者が作成)

 この区別が曖昧なまま進めると、落とし穴にはまる。「ページを読み込み直したら入力した内容が消えた」は、どこにも保存していなかったことが原因だ。「ほかのユーザーのデータが自分の画面に表示された」は、誰のものかの線引きを間違えた結果だ。「表示が古いまま更新されない」は、いつ更新するかの設計がずれていた。AIに指示するとき、「その操作の結果、どの値が・誰のものとして・どこに残るのか」まで伝えることが必要になってくる。

汎用的な機能は作らずAPIで外付けする

 バイブコーディングを始める際にやるべきことがある。欲しい機能を「提供している外部サービスがないか」を調べるのだ。

 たとえばアプリにユーザーログイン機能を付けたいとき、イチから作るのは大変だ。ユーザー登録、パスワードのセキュリティ強度チェック、本人確認、パスワードリセット、GoogleやXを使ったSNS認証など、さまざまな細かい機能が必要になる。しかも、セキュリティホールになりやすく、外部からの攻撃の標的にもなる。優秀なAIが使えても自分で作るのは止めたほうが良い。

 複雑なユーザー登録を簡単に実装できる外部サービスとしては「Supabase」などがある。これを使う場合、自分のアプリはSupabaseが定めたAPIのルールに従ってデータを送る。SNS連携、決済、動画配信などにも、同じように外部サービスを使える場合がある。それらをAPIを使ってアプリに取り付ける。APIは外部サービス接続するボルトやパイプみたいなものだ。規格やサイズを合わせないとうまくつながらないという点でもAPIはボルトやパイプにちょっと似ている。

画像
ゼロから作るのではなく、既存の外部サービスをAPIという「ボルト」でアプリに外付けするのが効率的な開発の基本だ。ボルトの規格=APIのルールが合って初めてつながる
(筆者が作成)

 世の中に存在する外部サービスの数は膨大で、日々増え続けているが、すべてを事前に把握する必要はない。ChatGPTやClaudeに「この機能を実現したい。使えそうなAPIやライブラリの最新版をリストアップして」と依頼する。作成されたリストを参考に、どれを使うかは設計段階でAIに決めてもらう。選択肢がある場合はAIから相談される。品質とコストと予算などからAIと一緒に決めていこう。 【次ページ】AIを優秀な部下にするための「3W」
関連タグ タグをフォローすると最新情報が表示されます
あなたの投稿

    PR

    PR

    PR

処理に失敗しました

投稿したコメントを
削除しますか?

あなたの投稿コメント編集

通報

このコメントについて、
問題の詳細をお知らせください。

ビジネス+ITルール違反についてはこちらをご覧ください。

通報

報告が完了しました

コメントを投稿することにより自身の基本情報
本メディアサイトに公開されます

基本情報公開時のサンプル画像
報告が完了しました

」さんのブロックを解除しますか?

ブロックを解除するとお互いにフォローすることができるようになります。

ブロック

さんはあなたをフォローしたりあなたのコメントにいいねできなくなります。また、さんからの通知は表示されなくなります。

さんをブロックしますか?

ブロック

ブロックが完了しました

ブロック解除

ブロック解除が完了しました

機能制限のお知らせ

現在、コメントの違反報告があったため一部機能が利用できなくなっています。

そのため、この機能はご利用いただけません。
詳しくはこちらにお問い合わせください。

ユーザーをフォローすることにより自身の基本情報
お相手に公開されます

基本情報公開時のサンプル画像