AppSheetアプリをAIで再開発する手順！既存アプリを「動く仕様書」にする方法

2026年9月9日

AppSheetで作った業務アプリを、CodexやClaude CodeなどのAIで作り直すには、何から始めればよいのでしょうか。

結論は、AIへいきなり「このアプリを作って」と頼まないことです。

先に既存アプリから「目的・データ・機能・画面」を整理し、実装前にAIの理解と計画を確認していくことが大切です。

この記事では、当社が実務で使っている作業者管理アプリをAppSheetからAI版へ再開発した例をもとに、具体的な進め方を解説していきます。

結論：AI開発ではプロンプトより先に『仕様を整理』する

AIで業務アプリを作るときに最も重要なのは、巧妙なプロンプトではありません。

何を作るのかを、人間側で整理することです。

今回の再開発では、次の順序で進めました。

1.既存のAppSheetアプリから、目的・データ・機能・画面を棚卸しする
2.ChatGPTなどで、実装AIへ渡せる仕様書に整理する
3.仕様書と画面コピーをCodexなどへ渡す
4.すぐに実装させず、理解内容と構築手順を先に出してもらう
5.確認事項に回答し、実装と確認を繰り返す

既存のAppSheetアプリには、業務で必要なデータや機能、画面がすでに組み込まれています。

その意味で、AppSheetはAI再開発に使える「動く仕様書」です。

ただし、アプリをそのまま自動変換するという意味ではありません。

画面に現れない計算式、権限、自動化、例外処理などは、別途言語化する必要があります。

再開発したのは、重複作業と確認チャットを減らすアプリ

題材にしたのは、当社が実務で使っている作業者管理アプリです。

目的は、誰がどのクライアントで作業しているかをチームで共有し、同じクライアントへの重複作業を防ぐことです。「クライアントB様は作業中ですか」といった確認チャットも減らせます。

管理するデータは次の5項目です。

データ	内容
ID	レコードを識別するキー
クライアント名	作業対象の顧客
ステータス	「作業中」または「未使用」
更新者	最後に状態を変更した人
更新時間	最後に状態を変更した日時

必要な機能は、クライアント登録、ステータス変更、作業中の色分け、更新者と更新時間の自動記録、一覧からの対象選択です。

AI版では、作業中・未使用で一覧を絞り込めます。

AppSheetアプリをAIで再開発する5つの手順

1. 目的・データ・機能・画面を棚卸しする

最初に整理するのは、次の4項目です。

仕様の項目	確認すること	今回の例
目的	何を解決するのか	重複作業と確認チャットを減らす
データ	何を保存するのか	ID、顧客名、状態、更新者、更新時間
機能	何ができればよいか	登録、状態変更、色分け、自動記録、選択
画面	何をどこに見せるか	左に一覧、右に詳細

「登録できる」のように当然だと思う機能も、省略しないほうが安全です。

人間同士なら暗黙に補える前提も、AIが同じように補うとは限りません。

ここで大切なのは、現在の画面を写すことではなく、アプリが解決している業務課題を確認することです。

今回も、見た目の完全再現ではなく「重複作業と確認チャットを減らせること」を成功条件にしました。

2. ChatGPTで実装用の仕様書に整理する

棚卸しした情報は、そのまま断片的に実装AIへ投げず、まず仕様書にまとめます。

動画ではChatGPTを使いましたが、仕様を整理できる対話AIであれば構いません。

依頼の考え方はシンプルです。

以下の内容を、CodexやClaude Codeへ開発依頼できる形に整理してください。この段階では実装せず、目的、使用技術、管理データ、必要機能を仕様書にしてください。

仕様整理と実装を分けることで、実装前に抜けや曖昧さを確認できます。

AIが整えた文書も、人間が読み返して修正してから次へ進みます。

3. 画面コピーを添付し、文章で動作を補う

画面の配置、色、情報量は、文章だけで説明するより画面コピーを見せたほうが伝わりやすいです。

今回も、AppSheet版の画面コピーを仕様書と一緒に実装AIへ渡しました。

実運用を想定するなら、静止画だけではクリック後の動き、エラー表示、スマートフォンでの表示、権限による違いまでは決められません。

画像は見た目の参考資料とし、次の内容は文章でも指定します。

・一覧を選択したとき、右側の詳細を切り替える
・作業中の行は色で区別する
・ステータス更新時に更新者と更新時間を記録する
・対象が見つからない場合や更新に失敗した場合の表示

4. 実装前にAIの理解と計画を確認する

仕様書と画像を添付しても、すぐに「作ってください」とは依頼しません。動画では、まず次のように依頼しました。

添付した仕様ファイルと画面イメージを確認してください。内容を読み取ったうえで、アプリを構築する手順を整理してください。

この一手間で、AIが何を作ろうとしているか、どの順序で実装するか、何を未決事項と捉えているかを、コードが増える前に確認できます。

認識がずれたまま進むと、最後までずれた成果物を修正し続けることになります。

尚、実運用するアプリなら、計画に要件と実装の対応、データの流れ、認証、テスト方法、失敗時の挙動、未解決の質問が含まれるかも確認します。

長期運用も含めた考え方は、Codexで業務アプリを設計・運用するポイントで詳しく解説しています。

5. 確認事項へ回答し、実装と確認を繰り返す

今回、Codexから出た確認事項の一つが「利用者は全員同じGoogle Workspaceのドメインか」でした。

更新者の取得方法やアプリの公開範囲を決めるための質問です。

この例では、更新者を記録するために利用者と認証方式を先に決めます。

利用者、認証、データへのアクセス権などが曖昧なままでは、画面は動いても業務で安全に使えるアプリにはなりません。

確認事項に一つずつ回答し、実装結果を確認し、必要なら仕様を直して再実装する。この反復で完成度を上げます。

AppSheetはAI開発の『動く仕様書』になる

今回の再開発で特に有効だったのは、AppSheetアプリを完成品としてだけでなく、実際に操作できる仕様書として見直したことです。

画面を見れば、利用者に何を見せているかが分かります。列の設定を見れば、必要なデータ型、初期値、選択肢、自動記録の条件を確認できます。

実運用を想定して仕様を広げる場合は、Automationや式など画面に出ない業務ルールも確認します。

ただし、棚卸しは見える画面だけで終わらせません。AI版へ移すときは、次も確認します。

・列の型、必須条件、初期値、計算式
・Automationや通知など、画面外の処理
・誰が何を閲覧・更新できるか
・同時更新が起きた場合の扱い
・エラー時の表示と復旧方法
・元アプリと同等と判断する受け入れ条件

データ構造が曖昧だと、AIに頼んでも期待するアプリになりにくいものです。

AIでも期待するアプリを作れない原因とデータ設計も、棚卸し時の参考になります。

AppSheet版とAI版は、見た目より業務目的で比較する

今回の2つのアプリは、主要な業務目的と機能は同じですが、見た目が大きく違います。

比較項目	AppSheet版	AIで独自実装した版
業務目的	重複作業と確認チャットを減らす	同じ目的を再現
主な操作	顧客を選び、状態を更新する	同じ主要操作（一覧の絞り込みも確認できる）
UI	AppSheetの部品と画面構成	コードで柔軟に設計できる
今回の評価軸	実務で使っている元アプリ	元アプリと同じ目的を果たせるか

AIを使った独自開発では、画面を細かく作り込めます。しかし、自由度が高いほど、何をどこまで作るかを人間側で決める必要があります。

今回は、豪華な見た目や多機能化を優先しませんでした。元アプリと同じ業務目的を実現することを第一段階の完成条件としています。

動画外の選定論点として、AppSheetを残すか、AIで独自開発するかは、認証、保守性、費用、構築速度、独自UIの必要性、社内で改修できるかを並べて判断します。

詳しくはAppSheetとAI開発の役割の違いをご覧ください。

実運用前に追加で決めたい3つの仕様

ここからは動画の手順を、業務利用へ進めるための補足です。

1. 認証と更新者の記録方法

AppSheetの USEREMAIL() は、サインイン中の利用者のメールアドレスを返し、サインインしていない場合は空になります（USEREMAIL()｜AppSheet Help）。

AI版でも更新者を確実に残すなら、誰をどの方法で認証し、どの情報を更新者として保存するかを決めます。

同じGoogle Workspaceドメインかどうかだけでなく、許可する利用者、公開範囲、退職・異動時の権限変更も設計対象です。

2. Googleスプレッドシートへのアクセス権

独自アプリからGoogle Sheets APIを使う場合は、利用者本人のOAuth認証で読み書きするのか、バックエンドのサービスアカウントを使うのかで構成が変わります（Google Workspace APIの認証情報を作成する｜Google for Developers）。

必要以上に広い権限を渡さず、対象ファイルと操作を絞ります。

3. 同時更新と受け入れテスト

このアプリの目的は重複作業を防ぐことです。

そのため、2人がほぼ同時に同じクライアントを「作業中」にした場合を仕様に入れる必要があります。

AppSheetの公式ヘルプでは、同じ行に対する競合は原則として最後の書き込みが残ると説明されています。AI版では、更新直前の再確認、条件付き更新、競合メッセージなど、目的に合う動作を決めます。

最後に、正常系だけでなく、権限のない利用者、通信失敗、同時更新、スマートフォン表示も確認します。

画面が似ていることではなく、決めた業務目的と受け入れ条件を満たしたかで完成を判断します。

よくある質問

AppSheetのアプリをAIでそのまま変換できますか？

今回行ったのは自動変換ではありません。既存のAppSheetアプリから目的、データ、機能、画面を抽出し、仕様書と画面コピーをもとにAIへ再実装させました。

AIへ渡す仕様書に最低限必要なものは何ですか？

まずは目的、データ、機能、画面の4項目です。

業務利用するなら、認証、権限、同時更新、エラー時の挙動、受け入れ条件も追加します。

画面コピーを添付すれば、UI仕様は十分ですか？

十分ではありません。

配置や見た目を伝えるには有効ですが、クリック後の動作、状態変化、エラー、権限、スマートフォン表示などは文章で補います。

ChatGPTとCodexはどう使い分けましたか？

動画では、ChatGPTで要件を開発依頼書に整理し、その仕様書と画面コピーをCodexへ渡して実装しました。

製品名よりも、仕様整理と実装を分け、実装前に理解内容を確認する流れが重要です。

AI版ができたらAppSheet版は廃止すべきですか？

一律には決められません。独自UIや処理の自由度を優先するならAIを使った独自開発が候補になります。

短期間での改善、保守のしやすさ、既存のGoogle Workspace環境との相性を重視するなら、AppSheetを継続する選択もあります。

まとめ

AppSheetアプリをAIで再開発するときは、プロンプトを工夫する前に、既存アプリから目的・データ・機能・画面を整理します。

AppSheetを「動く仕様書」として使い、仕様書と画面コピーを実装AIへ渡し、理解と計画を確認してから作り始めます。

今回の実例で優先したのは、見た目を豪華にすることではなく、重複作業と確認チャットを減らすという元の目的を再現することでした。追加機能の要否も、この2つを改善できるかで判断します。

AppSheetやAIを使った業務アプリ開発の進め方も紹介しています。自社の業務に合う作り方を具体化したい方はご覧ください。