老舗企業や中小事業者が直面するDXの壁を突破する鍵は、高額なシステム外注ではなく、クラウドデータ基盤（ERP）と生成AI（LLM）を組み合わせたツール開発の内製化にあります。本稿では、創業155年の老舗漬物店における「Claude」と「NetSuite」の連携事例をモデルケースとし、非エンジニア主導で現場に定着する業務ツールを迅速に構築する構造的アプローチを分析します。
報道の背景と2つの視点：事業拡大による摩擦とAI解法
今回取り上げる話題は、神奈川県小田原市の老舗漬物店「ちん里う本店」における経営改革とIT活用のプロセスです。2つの情報源を横断して読み解くと、伝統企業の変革における「課題発生の背景」と「技術的解決策」という相互補完的な構造が見えてきます。
- 情報源2（グローバル展開とオペレーション限界の提示）：国内市場の縮小に伴い、越境EC「NIHON ICHIBAN」を開設して海外販路を開拓。商品数が約8,000点規模へ爆発的に拡大する一方、取扱商品数が2,000点を超えた段階で、従来の個別手作業によるデータ管理や出荷作業が限界を迎えたという「事業成長に伴う構造的 bottleneck（ボトルネック）」を報告しています。
- 情報源1（クラウドERPと生成AIによる内製化実践）：そのオペレーション限界を打破するため、基幹データをクラウドERP「NetSuite」へ集約。さらに2026年4月に「NetSuite AI Connector Service」を介してAnthropicの生成AI「Claude」を連携させました。非ITエンジニアの経営陣が対話し「チャット＋コピペ」でプログラミングコードを生成することで、現場職人向けポータルや出荷・管理ツールを自作・実装した具体策を解説しています。
これら2つの視点を統合すると、単なる作業効率化としてのAI導入ではなく、「急速な事業拡張にバックオフィスと現場オペレーションが追いつかなくなる」という成長課題に対して、生成AIを用いた迅速な内製開発が極めて有効な解となり得ることを示しています。
構造解説：なぜ「クラウドERP × LLM」が内製化の起爆剤となるのか
これまで中小企業や老舗店舗におけるシステム化は、資金力の乏しさと社内エンジニアの不在という二重のハードルに阻まれてきました。システム開発会社への外注は予算的に難しく、汎用パッケージソフトウェアでは現場固有の細かな運用に適合しないケースが多く見られました。
しかし、「クラウドERPによるデータの一元管理」と「LLMによるフロントエンドコード・ロジックの即時生成」を組み合わせることで、システムのレイヤー構造そのものが変容しています。
1. データ層と統合ロジックの分離
基幹データ（在庫・取引先・価格・販売実績）は、APIを備えたクラウドERP（NetSuite）に安全かつ一元的に保持されます。AIはこのデータ層に安全にアクセス（コネクタ経由）し、必要な抽出・加工ロジックをプロンプトベースで組み立てます。
2. 対話型プログラミングによる開発コストの格段な低下
プログラマーでなくとも、必要な仕様（例：「六曜を考慮した売上予測」「複雑な割引条件を反映した卸売価格表」など）を言語化して生成AIに提示することで、即座にコード（JavaScriptやポータル構築用スクリプト）が生成されます。開発の手間は「チャットで要件を伝え、出力されたコードを貼る」という高速な試行錯誤ループに置き換わります。
現場実装における課題と解決策：リテラシーギャップの解消
どれほど優れた基盤と高度な生成AIがあっても、最終的に現場の作業者が利用できなければ形骸化します。最大の実装ハードルは、現場オペレーター（例：PC操作に不慣れな職人）とシステム間のインターフェース設計です。
課題：PC操作への抵抗感と複雑なUI
マウス操作や複雑な階層メニュー（「メニューの3番目を開き、フィルタを設定する」等）の指示は、現場作業者にとってストレスとなり、入力漏れやデータ不備の原因となります。
解決策：タスク特化型・最小クリックUIの自作
生成AIを活用して、特定の現場タスクだけに絞り込んだ専用ポータル（UI）を作成します。例えば、出荷管理や製造管理ポータルでは、直感的なダッシュボードや選択式のインターフェースを生成AIに記述させます。「画面上のカードを選ぶと買い物かごに入る」ような視覚的UIを採用することで、教育コストゼロで正確なデータ入力を実現できます。
| 比較項目 | 従来の外注開発モデル | 生成AI ＋ クラウドERP内製モデル |
|---|---|---|
| 開発コスト | 高額（数百万円〜） | 極めて安価（既存AIライセンス＋内製工数） |
| 開発スピード | 数カ月〜半年 | 数日〜数週間（即時改修可能） |
| 現場UIの適合性 | 標準機能への合わせ込みで不便が残る | 現場の習熟度に応じた専用UIを即座に自作 |
| 仕様変更への柔軟性 | 追加の改修費用と交渉が発生 | 対話型プロンプトにより自社で即時修正 |
| ガバナンス・セキュリティ | ベンダーの設計と権限設定に依存 | クラウドERP側の権限管理・API制御を活用 |
実務導入での注意点：ガバナンスとデータ品質
生成AIを活用した内製開発を推進するにあたり、実務担当者やDX推進者が配慮すべきリスクは以下の3点です。
- 基幹データ権限の制御：AIコネクタ経由でデータにアクセスする際、全社データがロール（役職）を無視して参照されないよう、ERP側で閲覧・編集権限を厳密に定義しておく必要があります。
- プロンプトとコードのブラックボックス化：非エンジニアが生成したコードが増えると、後任者がメンテナンス不能になる「野良ツール化」のリスクが生じます。生成AIに対し「生成コード内に十分なコメントを残させる」「開発ログをドキュメントとして自動出力させる」運用ルールを設けることが推奨されます。
- マスターデータのクレンジング：AIが正確な規格書や売上予測を出力するためには、ERP内の商品コードや原材料名などのマスターデータが標準化されていることが前提となります。
よくある質問
Q1. プログラミング経験が全くない非エンジニアでもツールの自作は可能ですか？
適切な生成AI（Claude等）と対話できれば、基本的なツールの構築は十分に可能です。重要なのはプログラミング言語の知識ではなく、「どのような業務課題があり、入出力をどう設計したいか」を論理的に整理・言語化する能力です。
Q2. 導入にあたり、どのようなインフラ基盤が必要になりますか？
データの一元管理とAPI連携ができる環境（クラウド型ERPやデータベース）が必要です。ローカル環境の分散ファイルのみでは生成AIの能力を十分に活かせないため、まずは基幹データのクラウド集約（ERP化）を先行させる必要があります。
Q3. 生成AIで作成したツールを現場に定着させるコツは何ですか？
現場の操作能力に徹底的に合わせることです。階層メニューを辿らせるのではなく、特定の業務に特化した単機能のダッシュボードや、数回のクリックで完了するUIをAIに作成させることが成功のポイントとなります。