【検証】Google Antigravityで「生産管理」は作れるか？非エンジニアがf-MRPを完全実装した話

導入：AIで「電卓」を作るのと「生産管理」を作るのは次元が違う

「すごいけど、仕事には使えない」という虚しさ

「Cursorを使えば、プログラミング知識ゼロでもアプリが作れる！」

2024年、この言葉に背中を押され、私もAIエディタの世界に飛び込みました。そして、確かに魔法のような体験をしました。
私のブログでも紹介した「Stamp Factory（LINEスタンプ生成ツール）」がその典型です。「ボタンを押したら、AIが画像を生成してダウンロードする」。自分が書いた日本語がそのまま動くアプリになる——その感動は本物でした。

しかし、その熱狂が冷めた頃、ある種の「虚しさ」が襲ってきました。

「で、これが何になるんだろう？」

作ったツールは楽しい。でも、それはあくまで「おもちゃ」です。
明日の会議で必要なデータ分析や、経理部門が毎月悲鳴を上げている請求書処理、現場が手書きで管理している在庫表……そういった「飯のタネ」になっている本業の課題解決には、このAIツールは全く歯が立たなかったのです。

「自分の会社の業務システムを、この手で作り直したい」
そう意気込んで、自社の業務フローをAIに伝えた瞬間、あれほど雄弁だったAIが急にポンコツになります。出力されるコードはエラーだらけ。Aを直せばBが壊れ、Bを直せばデータが消える。

数日間の格闘の末、私は悟りました。
「やっぱり、本物のシステム開発はエンジニアじゃないと無理なんだ」

もしあなたが今、同じような挫折感——AIへの期待と失望の狭間——にいるなら、この記事はあなたのために書きました。
結論から言います。諦めるのはまだ早いです。

今回、私はその「壁」を壊すために、あえて製造業で最も複雑で難解とされるシステムの実装に挑戦しました。

なぜAIは「電卓」を作れて「業務アプリ」で失敗するのか

Todoアプリや電卓アプリは簡単に作れて、なぜ業務システムは失敗するのか。
それは、「状態（State）」と「依存関係（Dependency）」の複雑さが次元違いだからです。

電卓アプリを想像してみてください。「1 + 1」を押せば「2」が出ます。これは入力に対して出力が一意に決まる、いわば「一問一答」の世界です。昨日どんな計算をしたかは、今日の計算に関係ありません。

しかし、企業が使う「業務システム」、特に今回挑む生産管理システムはそうはいきません。

1. ある部品を「出庫」すれば、在庫テーブルの数字が減る。
2. 在庫が減れば、発注点割れを起こして、自動的に「購買データ」が作られる。
3. その購買データは、「入荷予定」を作り、来月の「支払い予定」に影響し、経理の「キャッシュフロー表」にも顔を出す。

たった一つの操作が、ドミノ倒しのように複数のデータベースを書き換え、未来の予定まで変えてしまう。
プロのエンジニアでさえ、この「副作用」の連鎖を設計するのに何ヶ月も悩みます。
これを、文脈（コンテキスト）のメモリ制限があるAIに丸投げすれば、破綻するのは当たり前でした。AIは「今の画面」のことは分かっても、「3ヶ月後の支払い予定」への影響まで想像してコードを書くのが苦手だったのです。

今回の実験台：製造業のラスボス「オーダーメイドと既製品の混流」

今回、AIの進化を検証するために選んだ題材は、日本の製造業独特の「製番管理」と「MRP（所要量計算）」を完全に融合させたハイブリッド型の生産管理システムです。

製造業に馴染みのない方のために、もっと身近な例で説明しましょう。

• 製番管理（Seiban）
  これは「フルオーダーメイドの高級スーツ」を作る手法です。「Aさんのための生地」「Aさんのためのボタン」として、すべての材料に「Aさん用」という名札（製番）を付けて管理します。絶対に他の人のスーツには使いません。
• MRP管理
  こちらは「ユニクロのTシャツ」を作る手法です。白い糸やボタンは、誰の服になるか関係なく、1万個まとめて安く買います。在庫の山から、必要な分だけ取って使います。

この2つは管理の発想が真逆（水と油）です。
しかし、実際の工場では「Aさんの特注スーツを作るが、裏地の糸だけは大量購入した安いやつ（MRP品）を使いたい」というニーズが頻繁に発生します。

これをシステム化するには、「ある部品はAさん専用」「ある部品はみんなで共有」というルールを、数千点の部品ごとに動的に切り替え、かつ在庫の紐付け（引当）計算を分岐させるという、極めて複雑なロジックが求められます。

Google Antigravity：「ナビ」から「運転手」への進化

この無謀な挑戦のパートナーとして選んだのが、2025年11月にGoogleがリリースしたGoogle Antigravityです。

これまでのAIエディタ（CursorやWindsurf）と何が違うのか。
車に例えるなら、Cursorは「超優秀なカーナビ（Copilot）」でした。「次を右だよ」と教えてくれますが、ハンドルを握って運転するのはあなた（人間）です。だから、あなたが道（システム設計）を知らなければ、目的地には着けません。

対して、Antigravityは「運転手（Agent）」です。
「海に行きたい」と告げれば、自分でルートを引き、ハンドルを切り、アクセルを踏みます。
人間がやるべきは、後部座席で「おい、そっちは行き止まりだぞ」とたまに注意するだけ。

• 自分でターミナルを開いてデータベースを作る。
• 自分でブラウザを立ち上げ、ボタンを押して「在庫が減らないバグ」を発見する。
• 複数のファイルを同時に開き、あちこち修正して整合性を取る。

この「自律性」こそが、複雑な依存関係を持つ業務システム開発の自動化における突破口になります。
仕様書v2.0を読み込ませた瞬間、画面の向こうで何が起きたのか。
衝撃の開発プロセスを、包み隠さず公開します。

第1章：なぜこれが難しいのか？そして「仕様書」すらAIが書いた衝撃

冒頭の「システム詳細仕様書 v2.0」を見てください

まず、この記事の冒頭（または別添PDF）にある目次や仕様の一部をご覧ください。「システムアーキテクチャ」「データモデル」「f-MRPロジック」……専門用語が並び、いかにもベテランのシステムエンジニアが数週間かけて書き上げたようなドキュメントに見えるはずです。

ここで一つ重大なネタばらしをさせてください。
この仕様書、私が書いたものではありません。

これを作成したのは、他ならぬ Gemini（Googleの生成AI） 自身です。
私はただ、AIが書いた設計図に「OK」を出しただけ。
なぜそんな大胆なことができたのか？ それは、開発の初期段階で行ったある「テスト」によって、AIへの疑念が確信に変わっていたからです。

「こいつ、完全に理解してやがる…」確信に変わったPythonコード

プロジェクト開始直後、私は正直疑っていました。
「いくら最新のAIでも、日本の製造業特有のドロドロした現場ルールなんて理解できないだろう」と。

そこで私は、Geminiの業務理解度を試すために、あえて意地悪な「抜き打ちテスト」を仕掛けました。チャット欄に投げたのは、こんなプロンプトです。

コードを書かせるだけでなく、「業務メリット」という文脈を理解していないと解けない設問です。
しかし、AIは瞬時にコードを生成。私が恐る恐るそれを実行すると、画面上に本当にアプリが立ち上がりました。

驚愕したのはその中身です。
画面上の「f-MRP所要量計算」という項目にマウスを乗せると、黄色い付箋（ツールチップ）がポップアップし、こう表示されたのです。

ただの用語解説ではありません。「短納期」「計画変更」といった、現場が一番困っているポイント（ペイン）を正確に射抜いていました。
このPythonアプリが動いた瞬間、私の中でスイッチが切り替わりました。

「こいつは、用語を暗記しているだけじゃない。『製造業の現場で何が起きているか』を完全に理解している」

この理解力があるなら、もう私が拙い設計図を書く必要はない。
私は即座に次の指示を飛ばしました。
「完璧だ。じゃあその理解度をベースに、このシステムを実現するためのデータベース設計図（スキーマ）を書いてくれ」

AIが自ら設計した「難攻不落のロジック」

こうして生成されたのが、冒頭の「仕様書 v2.0」です。
AIは、私の「製番とMRPを混ぜたい」という抽象的な願いを、論理的なデータ構造へと翻訳しました。

特にAIがこだわったのが、「製番（オーダーメイド）」と「MRP（量産品）」の共存ロジックです。
これを料理に例えてみましょう。

• 製番品（特選和牛）: 「佐藤様のカレー用」として確保された肉。絶対に他の客には出しません。
• MRP品（お米）: 巨大な米びつに入ったお米。誰の注文か関係なく、古い順（先入先出）に使います。

人間なら「いい感じに使い分けて」で済みますが、システムの場合はそうはいきません。
もし設計を間違えれば、「佐藤さんの肉を田中に出す」ミスが起きたり、お米の在庫データに複数の注文が同時にアクセスして「データベースのロック競合（デッドロック）」を引き起こし、システムがフリーズしたりします。

この難所に対し、AIは以下のようなMarkdown仕様書を出力してきました。

見てください。Note: 同時アクセス時の整合性を保つため... という注釈。
AIは、私が口にしなかった「排他制御のリスク」まで予見し、仕様書に落とし込んでいたのです。
自分が設計したからこそ、矛盾のないコードが書ける。これこそが、今回成功した最大の要因です。

第2章：Google Antigravityの実力検証。仕様書を投げるだけで「核心」を理解するか

「Manager View」：画面の中に開発チームが住んでいる

「仕様書 v2.0」という最強の武器を手に入れた私は、いよいよGoogle Antigravityでの実装フェーズに移りました。
Antigravityには「Manager View（マネージャービュー）」と呼ばれるモードが存在します。私が「仕様書v2.0に基づき、まずはデータベースの初期構築をお願い」と指示を出した瞬間、画面がまるで司令室（コックピット）のように動き出しました。

画面左側のチャット欄で私が指示を出すと、画面下部のステータスバーから複数の「エージェント（作業員）」が同時にポップアップします。

• [Agent A]: 右上のエディタ領域で schema.prisma ファイルをガリガリと記述中。
• [Agent B]: 左下のターミナルで npm install prisma を実行し、ライブラリをインストール中。
• [Agent C]: 裏で環境変数 .env の設定を確認中。

これらが同時に、並行して動くのです。
私はキーボードに触れていません。ただ、画面のあちこちで勝手にウィンドウが開閉し、コマンドが走り、緑色の「Success」ログが流れていく様子を眺めているだけ。
それはまさに、3人の腕利きエンジニアを率いるプロジェクトマネージャー（PM）になったような感覚でした。

衝撃1：難解な「親ガメ・子ガメ構造」を一発クリア

数分後、Agent Aから通知が届きました。
「データベースの設計図を作成しました。変更内容を確認してください」

画面中央に「Diff（差分）ビュー」が表示されます。そこには、生産管理システムで最も設計が難しい「BOM（部品表）の自己参照リレーション」が、完璧な形で記述されていました。

model BOM {
  id           String @id @default(uuid())
  parentItemId String
  childItemId  String
  
  // 親と子を自己参照で紐付け
  parentItem Item @relation("ParentItem", fields: [parentItemId], references: [id])
  childItem  Item @relation("ChildItem", fields: [childItemId], references: [id])
}

model BOM {
  id           String @id @default(uuid())
  parentItemId String
  childItemId  String
  
  // 親と子を自己参照で紐付け
  parentItem Item @relation("ParentItem", fields: [parentItemId], references: [id])
  childItem  Item @relation("ChildItem", fields: [childItemId], references: [id])
}

これは「親ガメの背中に子ガメが乗り、その子ガメの背中に孫ガメが乗る」ような無限の階層構造を、たった一つのテーブルで表現する高度なテクニックです。人間が手書きすると混乱しがちなこのパズルを、AIは一発で解いてきました。

私はDiff画面で緑色にハイライトされたコードを確認し、満足げに「Accept（承認）」ボタンをクリックしました。その瞬間、待機していた別のエージェントが即座に npx prisma migrate dev を実行。実際のデータベースが一瞬で構築されました。

衝撃2：鬼門「再帰ロジック」を実装した瞬間

器（データベース）ができたら、次は魂（ロジック）です。ここが最大の山場、「f-MRPエンジン」の実装です。
私はエージェントに指示しました。
「受注データを受け取ったら、BOMを最下層まで展開し、製番の継承ルールに従って所要量を計算する calculateRequirements 関数を作って」

ここでも、Antigravityは再帰関数（Recursive Function）を用いて、「親から渡された製番を、自分のタイプ（MRPか製番か）によって『引き継ぐか、捨てるか』を判断する条件分岐」をさらりと実装してきました。

衝撃3：「気が利きすぎる」部下

最後に、納期の計算です。
Antigravityは、私が指示する前に、右上のターミナルで勝手に npm install date-fns が走ったかと思うと、チャット欄でこう報告してきました。

「仕様書の穴（未定義部分）」を検知し、「とりあえず土日除外で」という安全策（フォールバック）を提案してくるあたり、もはや指示待ちのAIではありません。

あまりにも順調すぎる進捗に、私は少し浮かれていました。
しかし、優秀すぎる部下（AI）が猛烈なスピードでコードを積み上げていくその裏で、人間には制御不能な「歪み」が静かに蓄積されていることに、まだ気づいていなかったのです。

第3章：最大の壁「型安全性」との戦い。TypeScriptの地獄をAIと突破する

突然、開発が強制停止した

順調に見えた開発プロジェクトに、その瞬間は唐突に訪れました。
いざ受注一覧画面（Order List）をプレビューしようとした時です。画面上のコードエディタに、不吉な赤い波線（エラー表示）が大量に出現しました。1つや2つではありません。ファイル全体が真っ赤になるほどの量です。

「さっきまで動いていたのに、なぜ？」

これは、モダンなWeb開発（TypeScript）につきものの「型（Type）の不一致」というエラーです。
このエラーが出ている限り、アプリはビルドすらできません（起動さえ許されません）。門前払いです。ここを突破しない限り、完成したはずのシステムはただの電子ゴミです。

Prismaの「マトリョーシカ地獄」とは

原因は、今回のシステム特有の「複雑なデータ構造」にありました。
「受注データ」を表示するとき、「品名」「製番ごとの在庫状況」「子部品の工程進捗」……これら関連するデータをすべて結合（Join）して持ってくる必要があります。

この「マトリョーシカ」のようにネストしたデータ構造が、悲劇を生みました。バックエンド（Server Actions）が渡そうとしているデータの形と、フロントエンド（画面）が受け取ろうとしている箱の形が、複雑すぎて一致しなくなったのです。

私は非エンジニアです。もし私が独力でGoogle検索して解決しようとしていたら、このエラーだけで丸3日は溶かし、最悪の場合ここで挫折していたでしょう。

AIが出した「共通辞書」という解決策

私は藁にもすがる思いで、Antigravityのエラーログをそのまま投げつけました。
「画面が真っ赤でビルドできない。助けて」

すると、AIエージェントは数秒の沈黙の後、驚くべき提案をしてきました。

分かりやすく言うと、「公式の辞書（型定義）」をバックエンド側で一冊作り、フロントエンド側に「この辞書の通りに喋れ」と渡すことにしたのです。これなら絶対に意味のズレ（型エラー）は起きません。

// 【バックエンド側】公式辞書を作成して配る
export type OrderWithItem = Prisma.OrderGetPayload<{ include: { item: true, allocation: true } }>;

// 【フロントエンド側】公式辞書を受け取って使う
import { type OrderWithItem } from '@/app/actions/orders';
export default function OrderList({ orders }: { orders: OrderWithItem[] }) { ... }

// 【バックエンド側】公式辞書を作成して配る
export type OrderWithItem = Prisma.OrderGetPayload<{ include: { item: true, allocation: true } }>;

// 【フロントエンド側】公式辞書を受け取って使う
import { type OrderWithItem } from '@/app/actions/orders';
export default function OrderList({ orders }: { orders: OrderWithItem[] }) { ... }

修正が終わった瞬間、画面を埋め尽くしていた赤い波線が、魔法のように消え去りました。
「型安全性（Type Safety）」が回復したのです。
AIは単にエラーを消しただけでなく、システムのアーキテクチャ自体を「将来の変更に強い設計」へと進化させました。

「検証スクリプト」でAIを監査する

型エラーは解決し、アプリは起動しました。しかし、ロジック（計算結果）は本当に合っているのか？
私は、もう一つのAI活用テクニックを使いました。「検証スクリプト（テストコード）」自体をAIに書かせるのです。

「以下のシナリオを検証するスクリプトを書いて実行して。1. 製番品Aを受注。2. 子部品の在庫引当確認。」
AIは即座にスクリプトを作成し、ターミナルで実行しました。

[CHECK] Step 3: Allocation... OK. (Used 10 from Inventory)
[SUCCESS] All logic is correct.

[CHECK] Step 3: Allocation... OK. (Used 10 from Inventory)
[SUCCESS] All logic is correct.

画面には SUCCESS の文字。
念のため、私はPrisma Studio（データベースの中身を直接見るツール）を開き、手元の電卓で計算した数値と見比べました。

• 手計算: 在庫100 – 引当10 = 残り90
• DB: Inventory: 90

「……合ってる」

背筋がゾクッとしました。AIが書いたコードを、AIが書いたテストで検証し、最後は人間がダブルチェックして承認する。この「人間とAIの多重監査体制」こそが、爆速開発と品質担保を両立させる鍵だったのです。

第4章：完成したv2.0の全貌。在庫引当からQRコード連携まで

ついに目覚めた「現場の守護神」

数日間の激闘の末、ついにシステムがビルドを通過しました。
ブラウザのアドレスバーに localhost:3000 と打ち込み、Enterキーを押した瞬間。
そこには、私が長年夢見ていた「オーダーメイド（製番）と既製品（MRP）が融合した世界」が広がっていました。
それはもはや、制御不能な「怪物」ではなく、私の業務を完璧に守ってくれる頼もしい「守護神」の姿でした。

1. 「製番優先引当」の瞬間（f-MRPの証明）

まず、このシステムの心臓部である「在庫引当」の画面です。ここでは、あえて意地悪なテストを行いました。

• 在庫状況: 共通在庫（MRP品）が100個ある。
• アクション: ここに「製番: A-001（特注案件）」を指定した注文を投入する。

一般的な簡易システムなら、勝手に共通在庫から引当してしまいます。しかし、AIが構築したシステムは違いました。

画面には「引当不可（在庫不足）」の鮮やかな赤いアラートが表示されています。
詳細ログには [Allocation Failed] Item is SEIBAN type. の文字。
「特注品のオーダーには、共通在庫は使わせない」。仕様書v2.0で定義した鉄の掟が、完璧に守られています。

この「融通の利かなさ（厳格さ）」こそが、業務システムにおいて最も重要な品質です。AIは「なんとなく動くもの」ではなく、「ルールを絶対遵守するもの」を作り上げたのです。

2. ガントチャートの「ヌルっと」した快感

次に、「生産計画」タブを開きます。受注納期から逆算（バックワード）された生産スケジュールが、美しいガントチャートで描画されています。

驚くべきは、その操作感（手触り）です。
マウスでバーを掴んで右にずらすと、「ヌルっと」した滑らかなアニメーションと共に移動し、指を離した瞬間に再計算が走ります。カチッという音と共に納期遅れのアラートが出るまでのレスポンスは、0.1秒もありません。

「ReactでこのレベルのUIを作るなんて、プロでも1週間はかかるぞ…」
Antigravityは、dnd-kit などのモダンなライブラリを自律的に選定し、わずか数時間でこのリッチな操作体験を実装してしまったのです。

3. スマホ連携：現場のDXが一瞬で完了

そして、私が最も感動したのが「周辺機能」の実装スピードです。
システムができあがった後、私はダメ元でこんな指示を出しました。

「現場の作業員がスマホで実績登録できるようにしたい。製造指図書にQRコードを表示して、それを読み取ったら完了報告できる機能を追加して」

AIは文句ひとつ言わずに qrcode.react ライブラリを導入。次の瞬間には、画面上の指図書にQRコードが出現しました。

私は震える手で自分のスマートフォンを取り出し、画面上のQRコードをスキャンしました。NextAuth.jsのログイン画面が一瞬表示され、即座に「完了報告画面」へ遷移。
ボタンを押すと、PCの管理画面の在庫数がリアルタイムで「+1」されました。

「これ、大手ベンダーに頼んだら数百万取られるやつだ……」
現場のDXが、たった一言のプロンプトで実現してしまったのです。

4. Google Drive連携：Google製AIの強み

さらに、図面管理機能の実装でもAntigravityの強みが光りました。
「品目マスタにPDFをドラッグ＆ドロップしたら、Google Driveにアップロードして」という指示に対し、AIは完璧なOAuth2.0の実装で応えました。

Google APIの面倒な認証周りも、そこは同じGoogleファミリー。Antigravityは必要なクレデンシャル情報を .env に設定するよう指示した後、認証フローの定型コードを一発で書き上げました。私がやったのは、Google Cloud ConsoleでIDを発行してコピペしただけです。

週末の2日間だけで、ERPは作れる

恐ろしい事実をお伝えします。
仕様書の作成から、DB構築、f-MRPの実装、型エラーとの格闘、そしてこのスマホ連携まで。
これら全てにかかった時間は、週末の土日、合計15時間程度です。

もしこれを従来のやり方でやっていたら？ 設計に1ヶ月、実装に2ヶ月……半年コースのプロジェクトだったでしょう。
「半年」が「2日」に短縮される。 これが、Google Antigravityがもたらす破壊的インパクトです。

結論：非エンジニアこそ「複雑なシステム」に挑め。AIはあなたの「業務知識」をコードに変える

AIは「定型作業」よりも「複雑なパズル」が得意だ

今回の検証を通じて、私は一つの確信を得ました。
「AI開発は、簡単なツールを作る時より、複雑な業務システムを作る時の方が、その真価を発揮する」

人間は、変数が3つを超えると混乱します。「あの部品、佐藤さんの分だっけ？ 田中さんの分だっけ？」。こうして現場は疲弊します。
しかし、コンピューター（AI）は違います。変数が1000個あろうが、疲れを知らずに整合性を保ち続けます。私が書かせた「仕様書v2.0」というルールブックさえあれば、AIはその通りに動き続けるのです。

「複雑だから無理」ではありません。「複雑だからこそ、AIに任せる」のです。

「業務知識（ドメイン知識）」が最強のプログラミング言語になる

私たち非エンジニアには、コードを書く力はありません。しかし、最強の武器を持っています。
それは、「業務の正解（What）」を知っていることです。

• 「この部品は、勝手に他の注文に流用してはいけない」
• 「現場はスマホ入力じゃないとやってくれない」

これまでは、この「肌感覚」をエンジニアに伝えるために膨大な労力が必要でした。
しかし今は、Google Antigravityという「天才エンジニア」が、あなたの隣（画面の中）にいます。

このエンジニアは、PythonもTypeScriptも完璧に話せますが、「業務」だけは知りません。
だからこそ、あなたが教えるのです。そして、上がってきた成果物が「業務的に正しいか」をジャッジするのです。
コードレビューなんてできなくていい。「これじゃ現場が困るよ」と指摘できれば、それで十分なのです。

「半年」を「週末」に変える魔法を手に

私が今回作ったのは、製造業のシステムでした。しかし、この手法はあらゆる業界に応用可能です。

• 複雑なシフト管理にパズルを解いている店長さん。
• 賞味期限と廃棄ロスの計算に追われる食品卸のオーナーさん。

「ウチの業務は特殊で複雑だから無理だ」と諦めないでください。
あなたの熱意と週末の2日間があれば、自分専用のERP（基幹システム）は作れます。

さあ、次はあなたの番です。
まずはGeminiに向かって「ウチの業務の愚痴」を話すところから始めてみてください。それが、最強の仕様書への第一歩になるはずですから。

この記事を読んだ人におすすめの記事

• Gemini 2.5 ProでAIのみブログ記事作成術
• AIブログ運営ならどっち？ChatGPT vs Gemini徹底比較
• AIブログ成功の「全自動執筆フロー」全解剖