投稿者 投稿日: カテゴリー Gemini
Google AI Studioとは、文章で指示するだけでアプリを作れる開発環境のことです。
在庫の棚卸しをスマートフォンで記録したい。返品依頼の受付フォームがほしい。ギフト包装の依頼を写真つきで受け取りたい。こうした「業務にちょうど合う小さな仕組み」は、既製のECツールでは埋まらないことがあります。かといって開発会社に頼めば数十万円。2026年5月のGoogle I/Oで、この隙間を埋める選択肢が広がりました。自然言語での指示からAndroidアプリを生成できる機能が、Google AI Studioに追加されています。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）の現場知見にもとづき、ノーコードでEC業務アプリを作る5つの手順を整理します。
Googleのノーコード開発は2種類ある
結論として、Googleが提供するノーコードのアプリ生成には性格の異なる2つの入口があり、EC業務ではこの使い分けが最初の分岐点になります。
1つ目がGoogle AI Studioのビルド機能です。TechCrunchが2026年5月19日に報じたところによると、Google I/O 2026で発表されたこの機能により、これまで数週間の設定とコーディングを要した作業が数分に短縮されるとされています。公式ドキュメントによれば、フルスタック環境で動くWebアプリケーションと、KotlinおよびJetpack Composeによるネイティブのアプリケーションの両方を、自然言語のプロンプトから生成できます。
2つ目がOpalです。こちらはコードを1行も書かずにAIのミニアプリを組み立てるプラットフォームで、プロンプト、モデル呼び出し、各種ツールを連結して複数工程のアプリを作ります。ロジックを説明すれば、視覚的なワークフローが組み上がる設計です。
EC業務での使い分けは明快でした。スタッフが端末で操作する画面がほしいならAI Studio、社内の判断や文章生成を自動で連鎖させたいならOpal。前者は「入力フォームと一覧画面」が必要な業務、後者は「情報を受け取って加工して出す」だけの業務に向きます。
なぜ2026年になってこの選択肢が現実的になったのか。理由は、生成されるコードの質が実用水準に近づいたことと、公開までの手続きが簡略化されたことの2点です。とはいえ楽観は禁物で、生成されたものをそのまま基幹業務に載せるのは危険です。この記事では、どこまでなら任せてよいかの線引きも含めて扱います。Googleの生成AIをEC業務に組み込む全体像はGemini 3.5 FlashのGAとエージェント活用、検索面での変化はGoogle AIモードのアプリ連携を参照してください。
EC業務のどこにノーコードアプリが効くのか
結論から言えば、効くのは「既製ツールとExcelの隙間に落ちている業務」です。理由は、この隙間が各社固有で、汎用のSaaSでは埋まらないからです。
具体例を挙げます。第一に、入荷検品の記録です。仕入先から届いた商品を検品し、数量と不良の有無を記録する作業を、いまだに紙とペンでやっている現場は少なくありません。記録した紙を後からExcelに転記する二度手間が発生します。スマートフォンで撮影しながら記録できる簡易アプリがあれば、この転記が消えます。
第二に、ギフト・のし対応の受付です。食品ギフトや化粧品を扱う店舗では、繁忙期にのしの表書きや名入れの依頼が集中します。モールの備考欄に自由記述で入ってくると、読み取りミスが起きます。項目を固定した入力画面を作れば、記入漏れと解釈違いが減ります。
第三に、店舗間の在庫確認です。実店舗を併設している事業者では、ECの注文に対して店舗在庫を引き当てる判断が日常的に発生します。基幹システムの改修は重いが、確認用の簡易画面なら現実的です。
第四に、撮影進行の管理です。アパレルや雑貨では、商品撮影の進捗管理が属人化しがちです。撮影済み、レタッチ中、公開済みといった状態を一覧できる画面があるだけで、抜け漏れが減ります。
第五に、クレーム記録の蓄積です。ある食品ジャンルの中規模店舗の事例では、クレーム内容が担当者ごとのメモに散っており、月次で傾向を見ることができませんでした。入力項目を統一した記録画面を用意したところ、3か月で「特定の配送業者と地域の組み合わせ」に偏りがあることが判明しています。
逆に、ノーコードで作るべきでない領域もあります。受注データそのものを扱う仕組み、決済に関わる処理、個人情報を保存する仕組みの3つです。これらは責任範囲とセキュリティ要件が重く、生成されたコードをそのまま使うべきではありません。既製のシステムを使うか、開発会社に依頼してください。この線引きを曖昧にしたまま進めるのが、最も危険なパターンです。
ノーコードでEC業務アプリを作る5手順
実装の手順は5つです。順番に説明します。
第1手順は、対象業務の選定と要件の言語化です。ここで9割が決まります。「在庫管理アプリを作りたい」では抽象度が高すぎて、生成されるものが使い物になりません。誰が、いつ、どの端末で、何を入力し、何を見たいのか。この4点を文章で書き出してください。
書き出す際のコツを1つ挙げます。理想の姿ではなく、いまの手順をそのまま書くことです。「本来はこうあるべき」を先に描くと、現場で使われない仕組みができます。紙の記録用紙があるなら、その用紙の項目をそのまま写すところから始めてください。まず現状を電子化し、運用が回ってから改善する。この順序を守った案件のほうが、定着率は明確に高いという実感があります。逆に、導入と同時に業務手順まで変えようとすると、うまくいかなかったときにアプリのせいなのか手順のせいなのか切り分けられなくなります。
第2手順は、プロンプトによる初回生成です。以下のプロンプトは、要件を構造化して渡す形にしています。
プロンプト1：EC業務アプリの初回生成
以下の要件を満たす業務用アプリを作成してください。
利用者と利用環境：
- 使う人：{例。倉庫スタッフ3名}
- 使う場所：{例。倉庫内、立ったまま片手で操作}
- 端末：{例。Android スマートフォン}
- 想定利用頻度：{例。1日30〜50回}
入力する項目：
- {項目名1}：{形式。テキスト／数値／選択肢／日付／写真}
- {項目名2}：{形式}
- {項目名3}：{形式}
表示したい画面：
1. 入力画面（1画面で完結し、スクロールを最小にする）
2. 当日分の一覧画面（新しい順）
3. 検索画面（{検索したい項目}で絞り込む）
制約：
- 個人情報（氏名、住所、電話番号、メールアドレス）は扱わない
- 決済に関する処理は含めない
- 外部サービスへの自動送信は行わない
- 操作に慣れていない人が使う前提で、ボタンは大きく、項目数は最小限にする
まず画面構成の案を提示し、私が承認してから実装に進んでください。
第3手順は、実際の業務データでの検証です。生成された直後のアプリは、想定どおりの入力しか通りません。現場では想定外が起きます。数量にゼロを入れる、選択肢のどれにも当てはまらない、途中で操作を中断する。こうした状況を意図的に作り、壊れないかを確認してください。
検証は作った本人がやってはいけません。作った人は無意識に正しい操作をするため、問題が見つからないからです。実際に使うスタッフに、説明なしで触ってもらってください。説明が必要な時点で、その画面は複雑すぎます。倉庫での検品のように、手袋をしたまま片手で操作する場面もあります。机の上でうまく動いたことと、現場で使えることは別だという前提に立ってください。この現場検証を飛ばして本番投入し、初日で使われなくなった例を複数見ています。
プロンプト2：業務アプリの異常系テストケース作成
以下の業務アプリについて、現場で実際に起こりうる異常な操作を洗い出してください。
アプリの用途：{用途}
入力項目：{項目一覧}
利用者の習熟度：{例。ITに不慣れなパート社員を含む}
洗い出す観点：
1. 入力値の異常（空欄、ゼロ、極端に大きい数、想定外の文字種）
2. 操作の異常（途中で戻る、二重送信、通信が切れる、電池切れ）
3. 業務上の例外（選択肢に該当しないケース、後から訂正が必要になるケース）
4. 複数人が同時に使った場合の問題
出力形式：
- テストケース番号／操作内容／期待する挙動／確認方法
- 最後に「このアプリで対応しないと決めるべき例外」を理由つきで列挙する
第4手順は、運用ルールの整備です。誰が使い、データをどこに置き、いつ見直すか。この3つを決めます。ノーコードで作ったものは作った本人しか把握していないことが多く、担当者が異動すると誰も触れなくなります。画面構成と項目の意味を1枚のメモに残しておいてください。
プロンプト3：ノーコードアプリの引き継ぎ資料作成
以下の業務アプリについて、作成者以外の人が保守できるようにするための引き継ぎ資料を作成してください。
含めるべき内容：
1. このアプリが解決している業務課題（なぜ作ったか）
2. 画面構成と各項目の意味、入力ルール
3. データの保存場所と、参照・出力の方法
4. 想定していない使い方（このアプリでやってはいけないこと）
5. 変更したくなったときの手順と、変更してはいけない箇所
6. このアプリが使えなくなった場合の代替手段（手作業での回し方）
制約：
- 専門用語には初出時に1行の説明を添える
- 手順は1つの動作につき1文で書く
- 文章は3〜5文の段落でまとめ、箇条書きの多用は避ける
アプリの情報：
{アプリの用途、画面構成、項目を記載}
第5手順は、段階的な拡張です。最初から機能を盛り込まず、1つの業務で1か月運用してから追加を判断します。使われなかった機能を最初に作り込むのが、この手のプロジェクトで最もよくある無駄でした。
1か月後に確認すべきことは3つあります。実際に何回使われたか、入力されたデータが業務判断に使われたか、スタッフから改善要望が出たかです。3つ目が出てこない場合、それは満足している証拠ではなく、関心を持たれていない可能性のほうが高いと考えたほうがよいでしょう。使っている人は必ず不満を持ちます。不満が出てこないアプリは、たいてい使われていません。この時点で撤退を判断するのも、正しい選択肢です。作ったものを維持する義務はありません。
社内の判断を連鎖させたい場合は、Opal側で組む形になります。
プロンプト4：問い合わせ振り分けワークフローの設計
以下の業務を、複数のステップに分解したワークフローとして設計してください。
業務内容：ECの問い合わせを内容に応じて担当者へ振り分ける
設計する内容：
1. 入力（何が起点になるか）
2. 判定のステップ（どの条件で分岐するか。条件は具体的に）
3. 各分岐の処理（誰に、何を、どの形式で渡すか）
4. 例外時の処理（どの条件にも当てはまらない場合）
5. 人が確認すべきポイント（自動で完結させてはいけない箇所）
制約：
- 返金額の決定、送料負担の判断、謝罪の要否は自動判定しない
- 個人情報は処理の途中で出力しない
- 各ステップで「失敗したときにどうなるか」を明記する
当社の前提：
- 1日の問い合わせ件数：{値}
- 担当者の人数と役割：{値}
- 現在の振り分け方法：{値}
生成物の品質を確認する工程も入れておきます。
プロンプト5：生成されたアプリの安全性レビュー
以下の業務アプリの仕様について、EC事業者が業務利用する観点でリスクを洗い出してください。
レビュー観点：
1. 個人情報の取り扱い（保存しているか、外部へ送信されるか）
2. データの保全（誤削除、上書き、消失のリスクと復旧手段）
3. 権限（誰でも全データを見られる状態になっていないか）
4. 業務停止時の影響（このアプリが使えないと何が止まるか）
5. 法令・規約（特定商取引法、個人情報保護法、モールの規約に触れうる点）
出力：
- リスクごとに「重大／中程度／軽微」の判定と理由
- 重大と判定したものには、業務利用前に必ず対応すべき事項を明記
- 判断に専門家の確認が必要な項目は、その旨を明記する
アプリの仕様：
{仕様を貼り付け}
つまずきやすい3つのパターン
結論として、ノーコード開発の失敗は技術面ではなく、範囲設定と運用体制で起きます。
1つ目は、扱ってはいけないデータを扱ってしまうパターンです。顧客の氏名や住所を入力項目に含めた瞬間、個人情報を保存する仕組みになります。保存場所、アクセス権限、削除の手順まで設計する責任が生じ、簡易アプリの範囲を超えます。本記事のプロンプトで個人情報を扱わない制約を明示しているのは、この線を越えさせないためです。
2つ目は、属人化です。作った担当者だけが仕組みを理解している状態は、その人が休んだ日に業務が止まることを意味します。5,000社支援の中で何度も再現したパターンとして、Excelのマクロで同じことが起きてきました。ノーコードでも構図は変わりません。第4手順の引き継ぎ資料を、運用開始の条件にしてください。
属人化への対策として、もう1点付け加えます。作った本人以外が、月に1度は必ず触る運用にしてください。触っていれば、壊れたときに気づけます。引き継ぎ資料を書いただけでは、読まれないまま時間が経ちます。実際に手を動かした人が2人いる状態を維持するのが、最も確実な対策でした。担当者が1人しかいない小規模な体制であれば、そもそも自作せず既製サービスを選ぶという判断も含めて検討する価値があります。
3つ目は、既製ツールで済む業務に作ってしまうパターンです。在庫管理も受注管理も、成熟した既製サービスが存在します。自作すべきなのは、既製品では埋まらない自社固有の隙間だけです。作る前に「これは本当に既製品にないのか」を確認する一手間で、無駄な開発を避けられます。
費用と工数をどう見積もるか
結論として、比較すべきは開発費ではなく、作ったものを維持する年間の手間です。
金額面から整理します。Google AI Studioのビルド機能は、無料の枠内で試せる範囲が用意されています。Opalも無料で利用できるとされています。ただし本格利用時の課金条件や上限は変更されうるため、導入前に公式ドキュメントで最新の条件を確認してください。開発会社に同等の簡易アプリを依頼した場合の費用は、内容によりますが数十万円規模になることが一般的です。この差は大きく見えますが、比較対象として適切なのは初期費用だけではありません。
維持の観点で見ます。既製サービスなら、法令改正やOSの更新への対応は提供元がやります。自作したものは、自分たちで面倒を見る必要があります。年に数回、動作確認と修正のために担当者の時間を割く前提で計画してください。この時間を見込まずに「無料で作れた」と判断すると、1年後に放置されたアプリが残ります。
見積もりの際に忘れられがちなのが、教育と移行の期間です。紙で運用していた業務を電子化する場合、しばらくは紙とアプリを並行させる期間が必要になります。この並行期間は作業が二重になるため、一時的に工数が増えます。2週間から1か月を見込んでおき、その間の負荷増をあらかじめ関係者に伝えておくと、現場の不満が出にくくなります。移行日を決めずに「そのうち切り替える」で進めると、並行運用が半年続きます。
効果の測り方は2つです。第一に、対象業務の所要時間。第二に、転記ミスや記入漏れの件数です。とくに2つ目が重要で、時間の削減より品質の安定のほうが、この種の仕組みでは効果として出やすい傾向がありました。検品記録の転記ミスが月に数件あった状態からゼロになれば、それは在庫差異の削減という形で効いてきます。
小さな自作が現実的になった意味
結論として、2026年の変化は「作れるようになったこと」ではなく「作るかどうかを事業者自身が判断できるようになったこと」です。
これまで、業務に合った仕組みがほしいと思っても、選択肢は既製品を探すか開発会社に相談するかの2つでした。どちらも判断に時間がかかり、結局はExcelと紙で回し続ける結末になりがちです。自然言語で試作できるようになったことで、「作ってみて、合わなければ捨てる」が可能になりました。この試行のコストが下がったことが、本質的な変化だと考えます。
この変化は、EC事業者の社内における力関係にも影響します。これまで「システムのことは分からないから」と外部に委ねていた領域に、現場の担当者が手を出せるようになりました。業務を最もよく知っているのは現場です。その現場が試作できるということは、要件定義の精度が根本的に上がることを意味します。開発会社に依頼する場合でも、試作品を見せながら話せるなら、認識のずれは大幅に減ります。自作するかどうかとは別に、この「叩き台を自分で作れる」という効用は見逃せません。
一方で、作れることと運用できることの差は依然として大きく残ります。楽天/Amazonの両方を回している店舗で観測されたのは、勢いで5つのアプリを作り、3か月後に使われているのが1つだけという状況でした。作る前に対象業務を1つに絞る規律が要ります。
今後の注目点を1つ挙げるなら、生成されたアプリと基幹システムの接続です。現状では簡易アプリと受注管理システムは分断されており、データの受け渡しは手作業になります。ここが接続されると用途は一気に広がりますが、同時に事故の影響範囲も広がります。接続を検討する段階に来たら、簡易アプリの延長ではなく、システム導入として扱うべきです。この切り替えのタイミングを見誤らないことが、ノーコード活用の分かれ目になるはずです。
よくある質問
Google AI Studioのノーコード開発は無料で使えますか
無料で試せる範囲が用意されています。ただし利用量に応じた課金条件や上限は変更される可能性があるため、本格導入の前に公式ドキュメントで最新の条件を確認してください。Opalについても同様です。
プログラミングの知識がなくても作れますか
簡易な業務アプリであれば、知識がなくても試作は可能です。ただし生成されたものが業務に耐えるかの判断、データの保全、権限設計については知識が要ります。本記事のプロンプト5のようなレビュー工程を挟み、判断に迷う場合は詳しい人に確認してください。
受注管理や在庫管理を自作してもよいですか
推奨しません。受注データや決済に関わる仕組み、個人情報を保存する仕組みは、既製サービスを使うか開発会社に依頼してください。自作すべきなのは、検品記録やギフト受付といった、既製品では埋まらない周辺業務に限られます。
AI StudioとOpalはどちらを使うべきですか
スタッフが操作する画面が必要ならAI Studio、情報を受け取って加工して出す処理を連鎖させたいならOpalが向きます。入力フォームと一覧画面が要る業務か、判断や文章生成の自動化かで切り分けてください。
作ったアプリはどこまで社内に配れますか
配布の方法と範囲は提供形態によって異なるため、公式ドキュメントで確認が必要です。まずは少人数で試し、運用が固まってから配布範囲を広げる進め方が安全です。
個人情報を扱わない設計にする方法はありますか
入力項目から氏名、住所、電話番号、メールアドレスを外し、注文番号などの識別子だけで運用する方法があります。本記事のプロンプト1で個人情報を扱わない制約を明示しているのはこの考え方によるものです。
最初に作るべきアプリは何ですか
紙とペンで記録し、後からExcelに転記している業務を探してください。転記という無駄が明確に存在する業務は、効果が測りやすく、失敗しても影響が小さい出発点になります。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
- TechCrunch: Google’s AI Studio now lets anyone build Android apps in minutes
- Google AI for Developers: Build apps in Google AI Studio
- Google Developers Blog: Introducing Opal – describe, create, and share your AI mini-apps
- Google Cloud: Build an App with AI – Get a Shareable URL
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
