Base44の独自LLM「Base 1」はノーコードEC内製をどう変えるか

齋藤竹紘2026年7月23日2026年7月23日EC×AI活用

Base44とは、自然言語でアプリを作るノーコード開発基盤のことです。

本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）が解説します。

2026年6月29日、ノーコード開発基盤のBase44が、自社で訓練したLLM「Base 1」を公開しました。これまで外部のフロンティアモデルを借りてアプリを生成してきたサービスが、初めて自前のモデルへ舵を切った動きです。EC事業者にとっての論点は、モデルの技術論そのものより手前にあります。受注管理や在庫アラートといった社内ツールを、こうしたノーコード基盤で内製すべきか、それとも既存のSaaSを使い続けるべきか。この判断を、開発コスト・保守・セキュリティ・楽天やAmazonの実運用という4つの軸で切り分けられるよう整理します。

Base 1発表で何が変わったのか

Base 1の発表がEC事業者に意味するのは、「ノーコードでアプリを作る」という選択肢が一過性の流行ではなく、事業として腰を据えたレイヤーになりつつある、という点です。理由は資本の動きに表れています。Base44は2024年に創業し、社員8人・創業約6か月の段階で、ホームページ制作大手のWixに約8,000万ドルで買収されました（TechCrunch報道、2025年6月）。その後も伸び、The Next Webは、2026年3月頃に年換算売上（ARR）1億ドルを超え、2か月後の5月には1億5,000万ドルに達したと伝えています。

Base 1は、この成長を土台に投入された最初の独自モデルです。Base44は公式リリースで、アプリ生成に特化したLLMを自社で持つ「アプリ制作基盤として初の事例」だと位置づけました（Base44公式リリース）。学習に使ったのは、プラットフォーム上で積み上がった「数千万件規模の実際のユーザー操作」から作ったデータセットだとしています。ゼロからの巨大モデルではなく、既存のオープンソース基盤モデルをファインチューニングした構成である点も、複数の報道が一致して伝えています。ベースにした具体的なモデル名は公開されていません（要確認）。

技術的な狙いは、汎用の巨大モデルを「借りる」構造から抜けることにあります。外部のフロンティアモデルを使うと、ユーザーのアプリが生成するトークンごとに費用がかかります。Base44創業者兼CEOのマオール・シュロモは、自社モデルなら遅延・コスト・効率の最適化余地が大きく、将来的にはOpusのようなフロンティアモデルよりもBase44の顧客にとって速く安くなる、と説明しています（TechCrunch）。発表時点のモデル選択画面では、Base 1はClaude Opus 4.8やGPT-5.5といった外部モデルと並んで選べる形で提供されました。

ここで冷静に押さえたい数字があります。Base44自身は、Base 1が置き換え対象のモデルに対して「すでに競争力のある性能を示している」段階だとしており、フロンティアモデルを上回ったとは主張していません（The Next Web）。つまり現時点のBase 1は「専用に振ったことで速度とコストで有利になりうる第一世代」であって、生成品質で頂点を取ったモデルではありません。EC事業者が導入を検討するときは、この温度感を出発点に置くのが妥当です。なお、報道ではユーザー数を約200万人とする記述も見られますが、集計基準が示されておらず、ここでは目安として扱います。

ノーコードで内製できるEC社内ツールの具体例

ノーコード基盤で内製する価値が最も出やすいのは、既製SaaSの「痒いところに手が届かない」隙間を埋める小さな社内ツールです。理由は明快で、汎用SaaSは多くの店舗の平均に最適化されているため、自店固有の運用ルールや商品構造にぴったり合わないことが多いからです。ここでは、EC運営で実際に手が止まりやすい4つの領域を挙げます。

1つ目は受注管理まわりの補助ツールです。複数モールを回している店舗では、楽天市場とAmazon、自社Shopifyの注文が別々の画面と別々のCSV形式で降ってきます。これを1画面に集約し、出荷期限が近い注文を色分けする、同梱すべき注文を購入者単位でまとめる、といった小回りの利くダッシュボードは、既製の受注管理システムの標準機能から少しずれた要望になりがちです。

2つ目は在庫アラートです。ある食品ジャンルの中規模店舗では、賞味期限と在庫数の両方を見て「値下げに動くか、まとめ売りにするか」を毎朝判断していました。こうした複合条件のしきい値通知は、汎用の在庫管理ツールでは設定しきれないことがあります。残数と回転日数を掛け合わせて通知するだけの内製ツールでも、朝の確認作業を数分に圧縮できる余地があります。

3つ目はレビュー集計です。楽天のレビュー一覧やAmazonのレビューを手作業で読み、頻出クレーム語を数えて商品改善に回す作業は、担当者の負担が重い割に属人化しやすい領域です。星の分布と自由記述の頻出語を並べるだけの内製ビューアーがあると、週次のレビュー会議の準備が楽になります。4つ目は商品マスタの整形です。型番・容量・色の表記ゆれを正規化し、モールごとの文字数制限に合わせて商品名を切り出す作業は、ノーコードで作った整形ツールと相性が良い部分です。楽天RMSの商品名フィールドは半角255文字（全角換算127文字）まで、スマートフォン用商品説明文は半角2,560文字（全角換算1,280文字）までと決まっているため、この上限内に収める整形ロジックを1つ持っておくと横展開が効きます。

こうした社内ツールをどう組み立てるかは、ノーコードでECアプリを作る手順でも触れています。Base44は認証・データベース・ホスティングを最初から内蔵しているため、この種の「1画面＋データ保存」で完結するツールは、比較的短時間で形になります。公式の導入事例では、ある個人開発者が端から端まで動く製品を約1週間で作ったと紹介されています（Base44公式）。

内製と既存SaaSをどう切り分けるか

内製とSaaSの線引きは、「業務の中心か、周辺か」で引くのが実務的です。結論を先に言うと、受発注や決済のように事故が売上に直結する基幹業務は既製SaaSに任せ、その周辺で自店固有の判断を助ける道具を内製する、という配分が無難です。理由は、基幹をノーコード内製に寄せると、保守とセキュリティの責任を自社で負い切れなくなるからです。

コストの見え方から整理します。Base44の料金は無料プランが月0ドル、有料プランが年払い換算で月16ドルから始まり、上位のEliteが月160ドルです（Base44料金ページ、2026年6月時点の公表値）。金額だけ見ると既製SaaSより安く映ります。ただしノーコード内製の総コストは月額利用料だけでは終わりません。仕様を決める人、作る人、動かなくなったときに直す人の時間が乗ります。作った本人が異動・退職すると、誰も触れない「作りっぱなしツール」が残るリスクもあります。既製SaaSはこの保守と属人化の負担をベンダーへ外出しできる点に価値があります。

保守の観点では、ノーコード基盤の仕様変更に自店が引きずられる可能性を見ておく必要があります。Base44は親会社Wixが2026年に人員を約20%削減した局面にあり（The Next Web）、こうしたプラットフォームの経営判断は、機能追加や料金体系の変更として利用側に返ってきます。基幹業務を1つの外部基盤に載せ切ると、その方針転換がそのまま事業リスクになります。周辺ツールであれば、最悪作り直せば済むため、影響を局所にとどめられます。ツール選定の全体像はAIコーディングツールの比較やShopifyのAIアプリの選び方もあわせて参照してください。

セキュリティと規約は、EC特有の落とし穴が潜む領域です。内製ツールが顧客の氏名・住所・注文履歴を扱うなら、データがどこに保存され、誰がアクセスできるかを把握しておく必要があります。加えて、モール連携には各社の規約が効きます。楽天RMSのAPIやAmazonのSP-APIから注文データを引く場合、利用規約とレート制限の範囲で使うのが前提です（各社仕様は変更されるため要確認）。もう1つ実務で見落とされやすいのが、楽天の外部誘導規約です。内製した管理ダッシュボードのURLを楽天R-Mailや商品ページに貼って社外の受注導線に使う、といった設計は規約に触れます。内製ツールはあくまで社内の業務用にとどめ、モールの購入者向け面には外部URLを持ち込まない、という線引きを最初に共有しておくべきです。

Base44でEC内製ツールを作る手順（プロンプト4本）

内製を成功させる鍵は、いきなり画面を作らせず、要件・設計・データ・テストの順に言語化することです。理由は、ノーコード基盤ほど「曖昧な指示から曖昧なUIが生まれる」ためで、Base 1が狙う「画一的なAI量産デザインの回避」も、入力側の解像度が低ければ活きません。ここでは、ChatGPT・Claude・Geminiのいずれでも使える汎用プロンプトを4本用意しました。生成AIで要件と設計を固めてから、Base44の対話欄にその結論を渡す流れを想定しています。

まずは要件定義です。作りたい社内ツールの目的と利用者を先に固め、機能の優先順位を引き出します。

プロンプト1：EC社内ツールの要件定義を引き出す

あなたはEC事業者の業務システムに詳しい要件定義の専門家です。
以下の状況をもとに、ノーコードで内製する社内ツールの要件を整理してください。

前提：
- 扱うモール：{楽天／Amazon／Shopify のいずれか、複数可}
- 解決したい業務：{例：複数モールの受注を1画面で確認したい}
- 利用者：{役職・人数・ITリテラシー}
- 1日の想定利用回数：{回数}

出力してほしいもの：
1. このツールが解決する課題の一文要約
2. 必須機能と、あると望ましい機能の切り分け（各3〜5項目）
3. 扱うデータ項目の一覧（個人情報が含まれるものには印を付ける）
4. 既製SaaSで代替できないと言える理由
5. 最初のリリースに含めない機能（スコープ外）

要件が固まったら、画面とデータ構造の設計に進みます。ここで在庫アラートを例に、通知条件まで含めて設計させます。

プロンプト2：在庫アラート画面のUIとデータモデルを設計する

あなたはBtoBの業務アプリ設計者です。
以下の要件から、在庫アラートツールの画面構成とデータモデルを設計してください。

要件：
- 商品ごとに「在庫数」「1日平均出荷数」「賞味期限または入荷日」を持つ
- 残日数が{日数}を下回ったら警告表示にする
- 商品ジャンル：{例：食品ギフト}

出力してほしいもの：
1. 一覧画面に表示する列と並び順（警告が上に来る設計）
2. 各データ項目の型（数値・日付・テキスト）と必須任意
3. 警告・注意・正常を色ではなくラベル文言でも区別する方法
4. 手入力を減らすためのCSV取り込み項目の対応表
5. この設計でありがちな失敗と、その回避策

3本目はデータ整形です。モールごとにばらばらな注文CSVを、社内の共通フォーマットへ寄せるロジックを言語化させます。

プロンプト3：複数モールの注文CSVを共通フォーマットへ正規化する

あなたはデータ整形に強いECオペレーション設計者です。
楽天・Amazon・Shopifyの注文CSVを、社内共通の1フォーマットに正規化する
変換ルールを設計してください。

前提：
- 共通フォーマットの必須列：{注文ID／購入者名／商品コード／数量／出荷期限}
- 表記ゆれの例：{全角半角、型番の枝番、色名の日英混在}

出力してほしいもの：
1. 各モールの元列と共通列の対応表（文章で）
2. 表記ゆれを正規化するルール（大文字小文字・全半角・空白の扱い）
3. 変換できなかった行を捨てずに退避する方法
4. 個人情報列を扱ううえでの最低限の注意
5. 変換結果を人が最終確認するためのチェック観点

最後はテスト観点です。ノーコードで作ると動作確認が甘くなりやすいため、受け入れテストの項目を先に洗い出します。

プロンプト4：内製ツールの受け入れテスト項目を洗い出す

あなたは業務アプリの品質保証担当です。
以下のツールについて、公開前に確認すべきテスト項目を洗い出してください。

対象ツール：{例：複数モール受注ダッシュボード}
主な利用シーン：{例：毎朝9時に当日出荷分を確認する}

出力してほしいもの：
1. 正常系のテスト項目（想定どおり動くか）
2. 異常系のテスト項目（空データ・重複・想定外の文字が来た場合）
3. 権限まわりのテスト（見せてはいけない人に見えていないか）
4. 数字がずれていないか検算する方法
5. 公開後1週間で確認すべき運用チェック

この4本を通すと、Base44の対話欄に投げる指示が「なんとなく在庫管理ツール」から「列・型・通知条件まで決まった設計」に変わります。より踏み込んだ業務自動化はClaude CodeでEC業務を自動化する方法でも扱っています。

内製でつまずく失敗例と回避策

内製でつまずく典型は、技術ではなく運用設計の側に集中します。ここでは現場で繰り返し見る3つのパターンを、回避策とセットで挙げます。いずれもBase 1のようなモデルの性能が上がっても、自動では防げない部分です。

1つ目は、クレジット消費の想定違いです。Base44の料金は、開発時に消費する「メッセージクレジット」と、公開後にエンドユーザーの操作で消費する「統合クレジット」の二本立てになっています。メール送信・画像生成・LLM呼び出しといった操作は、そのつど統合クレジットを消費します（Base44料金ページ）。社内ツールでも、利用人数と1日の操作回数が増えれば消費は伸びます。作り始めの軽い気持ちで無料プランの月25メッセージクレジットに収めるつもりが、本格運用で足りなくなる、というずれが起きがちです。回避策は、公開前に「1日の想定操作回数×稼働日数」で消費を見積もり、開発時の消費ではなく運用時の消費でプランを選ぶことです。

2つ目は、規約とセキュリティの後回しです。動くものが早くできるぶん、個人情報の扱いや権限設計を「後で」と先送りしやすくなります。直近の支援案件で観測したのは、内製ダッシュボードに全スタッフがアクセスでき、退職者アカウントが放置されていた例です。顧客の住所と電話番号が誰でも見える状態は、事故が起きたときの被害が大きくなります。回避策は、プロンプト4の権限テストを公開条件に組み込み、閲覧範囲を役割ごとに絞ること、そして退職・異動時のアカウント棚卸しを月次の運用に入れることです。

3つ目は、属人化とベンダーロックインです。作った本人しか仕様を知らないツールは、その人がいなくなると誰も直せません。あわせて、基幹に近い処理をノーコード基盤へ寄せすぎると、その基盤の料金改定や仕様変更から逃げられなくなります。回避策は2つあります。要件と設計をプロンプト1・2の出力としてドキュメントに残し、担当が代わっても読めば分かる状態にしておくこと。もう1つは、GitHub連携などでコードを自社側にも持ち出せる構成にし、いざとなれば移せる逃げ道を確保しておくことです。Base44はBuilder以上のプランでGitHub連携とカスタムドメインに対応しています。

KPI設計と費用・工数の目安

内製ツールの成否は、作った本数ではなく、業務時間をどれだけ削れたかで測るのが筋です。結論として、追うべき指標は「対象業務にかけていた時間の削減」「手作業に起因するミスの発生率」「そのツールを使い続けている人の割合」の3つに絞れます。売上の増減はツール単体では説明しにくいため、まずは工数と品質を見ます。

工数の見立ては、断定を避けて目安で持つのが安全です。たとえば、複数モールの注文CSVを手作業で整形するのに毎朝2〜3時間かけていた店舗が、内製の整形ツールで確認中心の数分作業に短縮できる、という改善は起こりえます。ただし削減幅は商品点数と表記ゆれの多さで大きく変わるため、自店で1週間試してから数値を確定させるのが現実的です。レビュー集計のように「やれば効くが後回しになる」業務は、内製で軽くしておくと着手率が上がります。

費用は、プラットフォーム料金と外部モデルの利用料を分けて考えます。Base44の有料プランは、年払い換算で月16ドルのStarter、月40ドルのBuilder、月80ドルのPro、月160ドルのEliteという構成です（2026年6月時点）。参考までに、外部のフロンティアモデルをAPIで直接使う場合の料金は、2026年7月時点の各社公表値でGPT-5.6の下位Lunaが入力100万トークンあたり1ドル・出力6ドル、Gemini 3.6 Flashが入力1.50ドル・出力7.50ドル、Grok 4.5が入力2ドル・出力6ドルといった水準です（要確認）。Base 1が狙う「専用モデルで速く安く」は、この従量課金をプラットフォーム側で最適化する試みだと捉えると分かりやすくなります。生成AIの月額サブスクリプション（ChatGPT・Claude・Geminiの個人向け上位プランはおおむね月20ドル前後）と、ノーコード基盤の料金は別勘定である点も、費用計画では取り違えないようにします。

独自LLM時代にEC内製をどう構えるか

これから起きるのは、アプリ制作基盤が「どのモデルを積むか」で競う時代から、「自前のモデルとデータで囲い込む」時代への移行です。Base44が独自モデルへ動いた背景には、外部モデルに全依存する事業は模倣されやすいという危機感があります。VCのヘッドラインでゼネラルパートナーを務めるジョナサン・ユセロビッチは、AI企業の防御力はデータ・流通・技術スタックの3点で決まると述べています（TechCrunch）。一方で慎重論もあり、法務AIのハーヴィーが自社モデルの計画を撤回した例も引かれています。専用モデルが汎用モデルの進化に追い抜かれる可能性は残ります。

EC事業者の立場では、この綱引きの勝敗を当てにいく必要はありません。押さえるべきは「どの基盤に載っても、要件・設計・データが自社の資産として残る形にしておく」ことです。競合を見ても、外部モデルに依存したままのLovableが年換算売上5,000万ドルではなく5億ドル規模に達しているとされ（The Next Web）、内製モデルが必ずしも事業規模の必要条件ではないと分かります。モデルの覇権争いは供給側の話であり、利用側は「乗り換えられる状態」を保つほうが実利があります。

AIエージェントの広がりも見ておきます。Base44はアプリと並走してタスクを実行する「Superagents」を打ち出し、Base 1もマルチターンの対話とコード生成、ツール利用を1つでこなす汎用エージェントとして設計されています（The Next Web）。この方向は、社内ツールが「人が開いて操作する画面」から「条件を満たしたら自動で動く仕組み」へ寄っていくことを示します。EC運営で言えば、在庫が閾値を割ったら自動で発注候補を作る、レビューの異常増加を検知して担当へ通知する、といった常時稼働の使い方です。ただし自動化の範囲を広げるほど、誤作動が売上へ跳ね返る危険も増えます。最初は通知や下書き生成までを自動化し、発注や公開といった不可逆な操作は人の確認を挟む設計から始めるのが、当面の落としどころとして望ましいと考えます。

よくある質問

Base 1はフロンティアモデルより高性能ですか

いいえ、現時点で上回ったとは示されていません。Base44自身が、Base 1は置き換え対象のモデルに対して「すでに競争力のある性能を示している」段階だと説明しており、フロンティアモデルを超えたとは主張していません（The Next Web）。専用に振ったことで速度とコストで有利になりうる第一世代のモデルだと捉えるのが正確です。

EC事業者はBase 1を選ぶべきですか

用途しだいです。社内向けの小さなツールを速く安く作りたいなら、Base44のモデル選択画面でBase 1を試す価値はあります。一方で、生成の完成度を最優先するなら、同じ画面から選べるClaude Opus 4.8やGPT系の外部モデルと出力を見比べて決めるのが安全です。1つのモデルに固定せず、目的ごとに切り替えられるのがこの基盤の利点です。

ノーコードで作ったツールのコードは自社のものになりますか

はい、Base44は生成したアプリの知的財産権は利用者に帰属すると明記しています（Base44料金ページ）。加えてBuilder以上のプランではGitHub連携が使えるため、コードを自社側にも保持し、必要なら別環境へ移す備えができます。属人化とロックインを避けるうえで、この持ち出し経路は最初に確保しておくのが望ましいです。

楽天やAmazonのデータと連携できますか

技術的には各モールのAPI経由で連携できますが、規約とレート制限の範囲内が前提です。楽天RMSのAPIやAmazonのSP-APIから注文・在庫データを取得する構成は一般的ですが、仕様は変更されるため実装前に公式ドキュメントの確認が要ります。あわせて、内製ダッシュボードのURLを楽天R-Mailや商品ページへ貼って外部送客に使う設計は規約に触れるため、社内業務用にとどめてください。

月額料金だけで内製の総コストは足りますか

いいえ、料金は総コストの一部です。Base44の有料プランは年払い換算で月16ドルから月160ドルですが（2026年6月時点）、実際には仕様を決める人・作る人・保守する人の工数が上乗せされます。さらに公開後はエンドユーザーの操作で統合クレジットを消費するため、運用時の利用量を見積もってプランを選ぶ必要があります。

最初の一歩は何から始めればよいですか

無料プランで小さな社内ツールを1つ作り、業務時間が実際に減るかを1週間試すのが第一歩です。いきなり基幹業務を載せ替えるのではなく、受注確認や在庫アラートのような周辺業務から入ると、失敗しても影響が小さく済みます。要件と設計を本記事のプロンプト1・2で言語化してから作ると、作り直しの手戻りを減らせます。

著者：齋藤竹紘（株式会社オルセル編集長／5,000社以上のEC支援実績／書籍3冊）

参考文献

※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/

【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）

齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。

投稿者: 齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。齋藤竹紘のすべての投稿を表示