Antigravityを非エンジニアが活用する方法｜営業・マーケが業務を自動化する実践パターン

本記事を読めば、エンジニアでなくてもAntigravityで小さな業務アプリを作り、見積もり作成や社内集計にかかる毎回30〜60分の手作業を削減できます。

Antigravityは、AIエージェントに計画、実装、確認まで依頼できる開発環境です。AIzen株式会社は、業務アプリ開発とAI活用支援の現場で、非エンジニアが自分の業務を型化する支援を行ってきました。

本記事では、営業・マーケ・企画職が自分で扱える範囲と、エンジニアへ依頼すべき境界線を具体的に整理します。

Antigravityを非エンジニアが扱える範囲

Antigravityは開発者向けの環境ですが、非エンジニアがまったく触れないツールではありません。業務内容を言語化し、AIが作ったものを業務目線で確認できる人であれば、小規模な業務アプリやワークフローの試作に活用できます。

重要なのは「本番の基幹システムを一人で作る」ことではなく、「自分の業務を小さく切り出して、動く形にする」ことです。範囲を絞れば、営業・マーケ・企画職でも十分に成果を出せます。

非エンジニアでも構築できるアプリの種類

非エンジニアがAntigravityで扱いやすいのは、入力、処理、出力がはっきりしているアプリです。たとえば、フォームに情報を入れると見積もり金額を計算する、CSVを読み込んでレポート用の表を作る、社内向けのチェックリストを画面化するといった用途です。

具体的には、見積もり作成フォーム、提案資料のたたき台生成、問い合わせ内容の分類、キャンペーン実績の集計、社内申請の入力チェック、定型メールや案内文の生成などが向いています。

これらに共通するのは、判断基準が業務担当者の頭の中にあり、仕様を文章で説明しやすいことです。「商品Aなら単価はいくら」「この条件なら割引率を変える」「入力漏れがあればエラーを出す」といったルールを洗い出せれば、Antigravityに実装を依頼できます。

コーディング知識が不要な理由

Antigravityでは、AIエージェントに自然文で依頼し、実装計画やタスクリスト、コード差分、確認結果などの成果物を見ながら進められます。コードを一行ずつ書けなくても、「この入力項目が足りない」「計算条件が実務と違う」「画面の並び順を変えたい」といった業務側のフィードバックを出せれば、改善を重ねられます。

非エンジニアに必要なのは、プログラミング文法よりも業務の説明力です。たとえば「見積もりフォームを作って」だけでは不十分ですが、「顧客名、商品カテゴリ、数量、割引率、納期希望日を入力し、税抜・税込金額と営業メモを表示するフォームを作って」と依頼すれば、AIが形にしやすくなります。

Antigravityはブラウザ操作や画面確認も扱えるため、作成後の見た目や操作感を確認しながら修正できます。非エンジニアはコードの正しさを直接判断するのではなく、業務フローに合っているか、入力ミスが起きにくいか、出力内容をそのまま使えるかを確認する役割を担います。

エンジニアに依頼すべき範囲

一方で、Antigravityを使えば何でも一人で完結できるわけではありません。社外公開、個人情報の保存、決済、社内基幹システムとの連携、複雑な権限管理が入る場合は、エンジニアの確認が必要です。

非エンジニアが自分で進めやすい範囲と、エンジニアへ依頼すべき範囲は次のように分けると判断しやすくなります。

判断項目	非エンジニアが進めやすい範囲	エンジニアに依頼すべき範囲
利用者	自分または数名のチーム	全社、顧客、外部パートナー
データ	ダミーデータ、公開してよい社内情報	個人情報、契約情報、売上原価、機密情報
処理	単純な計算、分類、文面生成	複雑な条件分岐、外部API連携、監査ログ
公開方法	ローカル確認、限定的な社内共有	インターネット公開、SSO、権限設計
失敗時の影響	手作業で修正できる	顧客対応、請求、契約、法務に影響する

この境界線を先に決めておくと、非エンジニアの自走とエンジニアのレビューを無理なく両立できます。

非エンジニアがAntigravityで構築できる業務の例

Antigravityの活用先は、営業、マーケティング、企画・管理部門のように、毎回似た作業を繰り返す部門と相性がよいです。特に「Excelで都度加工している」「過去資料をコピーして直している」「担当者ごとに手順が違う」業務は、アプリ化の効果が出やすい領域です。

ここでは、非エンジニアが最初に取り組みやすい3つの業務シーンを整理します。

営業の見積もり作成や提案資料

営業部門では、見積もり作成や提案資料のたたき台作成がAntigravityの入り口になります。商品カテゴリ、数量、割引率、オプション、納期などの入力項目を整理し、計算ルールを文章化すれば、見積もりフォームの試作を依頼できます。

たとえば、営業担当者がAntigravityで見積もり作成フォームを作る場合は、顧客名、案件名、商品カテゴリ、数量、単価、割引率を入力し、小計、消費税、合計金額を表示する流れを依頼します。さらに、割引率が20%を超える場合は上長確認のメッセージを出し、見積もり結果をコピーしやすい文章形式で出力するところまで指定します。

この程度の範囲であれば、営業担当者自身が動作を見ながら修正できます。実際の運用では、入力項目の抜けや割引ルールの例外が後から見つかるため、最初から完璧を狙わず、1案件分を再現するところから始めるのが現実的です。

マーケティングのコンテンツ生成とキーワード調査

マーケティング部門では、記事構成案、広告文、メール文面、キーワード整理などの定型作業にAntigravityを活用できます。たとえば、CSVで渡したキーワード一覧を検索意図ごとに分類し、記事テーマ、想定読者、訴求ポイントを表にする簡易ツールを作れます。

ポイントは、AIに文章を作らせるだけで終わらせないことです。毎回のプロンプトをアプリやワークフローとして固定化すると、担当者ごとの品質差を抑えられます。「この列にはKWを入れる」「この列には想定読者を出す」「重複テーマはまとめる」といったルールを画面や処理に落とし込むことで、作業手順そのものを共有できます。

マーケティングでは、情報の正確性やブランド表現の確認が残るため、最終判断は人が行います。ただし、下調べ、分類、初稿作成、表形式への整理はAIに任せやすく、担当者は編集と判断に時間を使えるようになります。

企画・管理部門の社内データ集計と通知

企画・管理部門では、社内アンケート、問い合わせ件数、申請状況、タスク進捗などの集計業務にAntigravityを使えます。たとえば、スプレッドシートからCSVを書き出し、部署別の件数、未対応一覧、期限超過の項目を表示する簡易ダッシュボードを作る用途です。

また、通知文の生成にも向いています。「期限が近い申請だけを抽出し、担当者向けのリマインド文を作る」「月次報告用に数値の変化を文章で説明する」といった処理は、非エンジニアでも要件を説明しやすい領域です。

ただし、社内データを扱う場合は、ダミーデータで試作してから本番データに近づける順序が重要です。最初から実データをAI環境に貼り付けるのではなく、列名とサンプル行だけで動きを確認し、共有範囲と保存場所を決めてから利用します。

Antigravityでの業務アプリの作り方

非エンジニアがAntigravityで成果を出すには、依頼の粒度を小さくすることが最重要です。複数業務をまとめて依頼すると、AIが作る仕様も曖昧になり、確認する側もどこを直せばよいか分からなくなります。

ここでは、見積もり作成フォームを例に、業務アプリを作る流れを3ステップで整理します。

業務を一つに絞ってAIに依頼するステップ

最初の依頼では、対象業務を一つに絞ります。「営業支援アプリを作る」ではなく、「見積もり金額を計算して営業メモを出力するフォームを作る」と定義します。業務名、利用者、入力項目、出力内容、例外条件をセットで伝えると、AIが実装しやすくなります。

依頼文では、目的、利用者、入力項目、出力内容、条件分岐、確認方法を一つの文章にまとめます。何の作業時間を減らしたいのか、誰が使うのか、画面に何を入れるのか、何を表示・コピー・保存したいのかをまとめて渡すと、AIが実装すべき範囲を判断しやすくなります。

たとえば「営業担当が商談後に使う見積もりフォームを作ってください。入力項目は顧客名、商品カテゴリ、数量、単価、割引率です。合計金額、税込金額、提案メール文を出力してください。割引率が20%を超える場合は上長確認が必要と表示してください。サンプルとして数量10、単価5万円、割引率10%の結果で確認します」という依頼であれば、AIが必要な画面と処理を組み立てやすくなります。

出力結果を確認しながら修正するステップ

Antigravityでは、AIが実装計画やタスク、画面確認の結果を成果物として示します。非エンジニアは、コードそのものよりも、画面と出力結果を見て業務に合っているかを確認します。

確認時は、まず入力項目が実際の業務順に並んでいるかを見ます。そのうえで、必須項目の不足、手元のExcelとの計算結果の一致、例外条件のメッセージ、出力文をそのままメールや資料に貼れるかを確認します。初めて使う人が迷わず操作できるかも、業務担当者だからこそ判断できる重要な観点です。

修正依頼は「見た目をよくして」ではなく、「割引率の入力欄を数量の下に移動してください」「税込金額の下に営業メモ欄を追加してください」のように具体化します。画面を見ながら一つずつ直すことで、業務担当者の感覚に近いアプリへ調整できます。

公開前の入力項目と利用フローの見直し

動くものができたら、公開前に入力項目と利用フローを見直します。特に、営業や管理部門では「誰が、いつ、どの情報を入力し、出力をどこで使うか」が曖昧なままだと、せっかく作ったアプリが定着しません。

公開前には、入力項目の名称が現場の言葉になっているか、必須項目と任意項目が区別されているか、入力ミスが起きたときの表示があるかを確認します。出力結果の使い道、既存のExcelやスプレッドシートとの役割分担、管理者と利用者の違いも合わせて整理します。

小さなチームで使う場合でも、利用フローを1枚のメモにしておくと、後から修正するときに迷いにくくなります。Antigravityに「この利用フローをREADMEにまとめてください」と依頼すれば、運用メモのたたき台も作れます。

非エンジニアが詰まりやすいポイントとエンジニア依頼の判断軸

非エンジニアがAntigravityで業務アプリを作るとき、最初の画面作成までは進みやすい一方で、データ構造、例外処理、公開時の安全性で課題が出やすくなります。これはツールの使い方というより、業務をシステムとして整理する段階で起きる問題です。

自分で続けるか、エンジニアに引き継ぐかを判断するには、「業務担当者が確認できる内容か」「誤動作したときに手作業で戻せるか」を基準にします。

データモデル設計でつまずく場面

データモデルとは、顧客、案件、商品、見積もり、担当者などの情報をどの単位で持つかを決める設計です。非エンジニアが最初に迷いやすいのは、Excelの表をそのままアプリに持ち込もうとする場面です。

たとえば見積もり作成フォームでは、顧客情報、商品マスタ、見積もり明細、承認状況を一つの表に詰め込むと、後から修正しにくくなります。商品単価が変わったときに過去の見積もりまで変わってよいのか、顧客名の表記ゆれをどう扱うのか、複数商品を一つの見積もりに入れるのかといった判断が必要になります。

この段階で悩んだ場合は、Antigravityに「顧客、商品、見積もり、見積もり明細に分けたデータ構造案を作ってください」と依頼すると整理しやすくなります。ただし、将来的にCRMや会計システムとつなぐ予定がある場合は、早めにエンジニアへ確認を依頼するべきです。

例外処理を後付けで入れにくくなる原因

業務アプリは、通常パターンだけなら比較的簡単に作れます。問題になりやすいのは、割引の上限、承認が必要な条件、入力漏れ、対象外の商品、過去データの修正、キャンセル処理などの例外です。

例外処理を後から足し続けると、条件が重なり、どのルールが優先されるのか分かりにくくなります。たとえば「20%以上の割引は上長確認」「特定商品は割引不可」「キャンペーン期間だけ10%自動割引」といった条件が同時に入ると、営業担当者だけでは正しい処理順を判断しにくくなります。

この課題を解消するには、例外条件を表にしてから実装するのが有効です。条件、表示メッセージ、処理内容、確認者を一覧化し、AIに渡します。条件が5個を超える、または金額・契約・請求に影響する場合は、エンジニアにレビューを依頼するのが安全です。

弊社エンジニアからのコメント：

営業担当者がAntigravityで見積もり作成フォームを試作した際、画面は1日で形になりましたが、商品マスタと見積もり明細を同じデータとして扱っていたため、単価改定時に過去見積もりの金額まで変わる設計になっていました。

非エンジニアが作る場合も、金額や履歴が関わるアプリでは「今の正しさ」だけでなく「半年後に見返したときの正しさ」まで確認することが重要です。

エンジニアに引き継ぐべきタイミング

エンジニアに依頼するタイミングは、完成後ではなく、影響範囲が広がる前です。非エンジニアが作った試作をベースに、画面、入力項目、業務ルール、利用者の反応を整理してから渡すと、エンジニア側も要件を把握しやすくなります。

顧客情報や個人情報を保存する、社外ユーザーに公開する、売上・請求・契約・在庫に影響する、外部システムやAPIと連携する場合は、早めにエンジニアへ相談します。複数部署で同時に利用する場合や、権限ごとに見える情報を変える場合も、試作段階で設計確認を入れるべきです。

非エンジニアの役割は、完成品を一人で作り切ることではありません。業務の流れを具体化し、試作品で現場の反応を確認し、必要なタイミングでエンジニアに渡せる状態を作ることです。この分担ができると、開発依頼も抽象的な相談ではなく、検証済みの要件として進められます。

構築した業務アプリの公開・共有ルール

Antigravityで作ったアプリをチームに共有する場合、作ること以上に「誰に、どの範囲で、どう使わせるか」が重要です。便利だからといってそのまま広げると、古いバージョンの利用、誤入力、情報管理の不備が起きやすくなります。

公開前には、利用者、権限、更新担当、問い合わせ先、扱ってよいデータを決めておきます。小さなアプリでも、業務で使う以上は運用ルールが必要です。

社内共有時の権限とアクセス制御

社内共有では、まず利用者を限定します。最初は担当者本人、次に同じチーム、最後に関連部署という順番で広げるのが安全です。いきなり全社公開すると、想定外の使い方が増え、修正要望や問い合わせに対応しきれなくなります。

権限は、閲覧、入力、編集、管理に分けて考えます。見積もりフォームであれば、一般営業は入力と出力のみ、管理者は商品単価や割引条件の変更、責任者は承認条件の確認というように役割を分けます。

Antigravity自体にも、エージェントのファイルアクセス、ターミナル実行、ブラウザアクセスなどの設定があります。初期段階では、コマンド実行や成果物レビューを人が確認する設定にし、必要な操作だけを許可する運用が現実的です。AIに任せる範囲を広げるほど、確認ルールも明確にする必要があります。

業務担当者が継続更新するための運用ルール

業務アプリは、一度作って終わりではありません。商品名、料金、承認者、出力文面、運用手順は変わります。非エンジニアが継続更新するには、どこを変更してよいか、どこからエンジニア確認が必要かを決めておくことが大切です。

更新ルールは、業務担当者が変更できる範囲、管理者確認が必要な範囲、エンジニア確認が必要な範囲に分けます。文言、選択肢、表示順、説明文は業務担当者が直しやすい一方で、単価、割引率、承認条件、通知先は管理者確認が必要です。データ保存方法、権限、外部連携、公開設定に関わる変更は、エンジニアの確認を挟むべきです。

また、変更履歴を残すことも重要です。「誰が、いつ、何を変えたか」が分からないと、出力結果が変わった原因を追えません。簡単な更新メモでもよいので、変更内容を記録する場所を用意しておくと、トラブル時の確認が早くなります。

セキュリティと情報管理の前提

AntigravityのようなAIエージェント型の開発環境では、ファイル、ターミナル、ブラウザへのアクセス権限をどう扱うかが重要です。便利さを優先して広い権限を与えると、意図しないファイル参照や外部アクセスのリスクが高まります。

非エンジニアが使う場合は、最初はダミーデータで試作し、個人情報や契約情報をプロンプトに貼り付けない運用を徹底します。社外公開前には必ずエンジニアレビューを受け、ファイルアクセスは作業フォルダ内に限定します。ターミナル実行は確認ありの設定にし、外部サイト参照やAPI連携は許可範囲を決めてから使うべきです。

業務アプリの価値は、現場で使われて初めて生まれます。ただし、業務データを扱う以上、便利さと安全性はセットで考える必要があります。非エンジニアは業務要件を具体化し、エンジニアは安全に運用できる形へ整える。この役割分担が、Antigravity活用を社内に広げる前提になります。

まとめ

Antigravityは、非エンジニアが自分の業務を小さなアプリやワークフローとして型化するために活用できます。特に、営業の見積もり作成、マーケティングのキーワード整理、企画・管理部門の集計業務のように、入力と出力が明確な作業と相性がよいです。

まずは、単純なフォーム、集計、文面生成、社内向け試作から始めるのが現実的です。データモデル、例外処理、社外公開、個人情報の扱いが入る場合は、早めにエンジニアへ確認します。公開後も、権限、更新担当、変更履歴、セキュリティ設定まで運用ルールを決めることで、現場主導の自動化を安全に広げられます。

AIzen株式会社では、AIを活用した業務アプリ開発や、非エンジニアが使える業務自動化フローの設計を支援しています。Antigravityで試作したアプリを安全に社内展開したい場合や、どこから開発依頼に切り替えるべきか迷う場合は、業務整理から無料でご相談いただけます。