朝8時。購買担当が、在庫一覧と発注残をExcelに出します。
2つの表を品目コードで突き合わせ、発注点を割った品目に色を塗る。
別のシートで、3か月動いていない品目を探す。
それが終わるころには、10時が近づいています。
その2時間、在庫は1個も減っていません。
在庫と仕入の毎朝の点検とは、欠品しそうな品目、売れ残っている品目、値上がりした品目、遅れがちな仕入先を、毎朝決まった形で洗い出す作業です。
NetSuiteにAIをつなげば、この洗い出しは一度の頼み方で終わります。
人に残るのは、発注するか、移動するか、仕入先と話すかを決める時間です。
では、AIにはどこまで任せ、どこから人が決めればよいのか。
線を引き違えると、AIの候補がそのまま発注書になる事故が起きます。
この記事で分かること
- 毎朝の点検を5つに分け、AIに一度に洗い出させる頼み方
- 発注点割れと滞留在庫、拠点間の移動、値上がり品目、仕入先の成績表の作業イメージ
- NetSuite標準のSupply Chain Control Towerで、納期の遅れを先に知る方法
- 発注と移動の確定を人に残す線引きと、AIをつなぐときの権限
言葉の整理
- 発注点：在庫がこの数を下回ったら発注する目安の数
- 滞留在庫：長いあいだ出庫されずに倉庫に残っている在庫
- 発注残：発注したものの、まだ入荷していない数量
- 移動伝票（Transfer Order）：拠点から拠点へ在庫を動かす予定と進み具合を記録する伝票
- AI Connector Service：ClaudeやChatGPTなどのAIをNetSuiteにつなぐOracleの連携サービス。MCP（AIが外部のシステムとやり取りする共通の決まり）に対応
この記事のサンプル（社名・品目・数量・金額）は、すべて架空です。
在庫表の突き合わせは「意味のない作業」
在庫一覧と発注残を突き合わせても、売上は1円も増えません。
経費も1円も減りません。
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、こうした作業をブルシットジョブ（意味のない作業）と呼んでいます。
稲盛和夫氏は「売上を極大に、経費を極小に」と説きました（出典：京セラ公式、2026年9月確認）。
ベンチャーネットが考えるAIクラウドERPは、この原則を実現するための考え方です。
会社のデータをNetSuiteに集めて正しく計測し、その前後の手作業をAIで消します。
在庫の点検は、この原則に両側から効きます。
欠品を防げば、取れる売上を取りきれる。
滞留を減らせば、寝ている資金と倉庫の費用が減る。
| ループ | 起きること |
|---|---|
| 負のループ | 手で突き合わせる→点検が昼にずれ込む→発注が1日遅れる→欠品と余りが同時に起きる→在庫の数字が信用されない |
| 正のループ | AIが朝一番に洗い出す→人は判断だけする→発注が早くなる→欠品と余りが減る→在庫の数字がもっと使われる |
世界中のNetSuiteの現場で繰り返される手間は、NetSuiteあるある15選にまとめています。
全体像｜毎朝の点検は5つに分けられる
毎朝の点検は、次の5つに分けられます。
上の4つは、AIに頼み方を1本書けば、一度に出せます。
| 点検 | 使うもの | 日本での状況 | 人が決めること |
|---|---|---|---|
| ① 発注点割れと滞留 | Claude・ChatGPT（AI Connector Service） | 日本のアカウントで使えるかは担当に確認 | 発注するか |
| ② 拠点間の在庫の偏り | 同上 | 同上 | 移動するか |
| ③ 値上がりした仕入品目 | 同上 | 同上 | 価格に転嫁するか、交渉するか |
| ④ 仕入先の成績と遅れ | 同上＋Control Towerの予測リスク（NetSuite標準） | 同上 | どの仕入先と話すか |
| ⑤ 在庫レポートの要約 | Narrative Insights（NetSuite標準） | 全地域・システムの対応言語（Oracleのヘルプ）。日本語画面は要確認 | 原因を伝票で確かめるか |
AI Connector ServiceでつないだAIは、保存検索やレポートを実行できます。
レコードの作成・更新もできます。
SuiteQL（データを読む問い合わせの言葉）での照会は、読み取りだけです（出典：Oracle NetSuiteのヘルプ、2026年9月確認）。
①〜③と仕入先の成績表の頼み方は、海外のNetSuite専門会社のプロンプト集にもあります（出典：GURUS Solutions、2026年9月確認）。
ここでは、日本の製造・卸売の現場に合わせた架空の例で示します。
点検①｜発注点割れと滞留在庫を、一度に出す
購買担当が毎朝、在庫一覧を見て、発注点割れと売れ残りを別々に探している場面です。
探し方が2つあるから、表も2つになります。
元のデータは、次の在庫の表です（架空の例）。
品目,拠点,在庫数,発注点,最終出庫日
部品A-100,東京倉庫,40,50,2026/09/25
部品B-200,東京倉庫,300,100,2026/05/20
製品C-300,大阪倉庫,12,10,2026/09/28
部品D-400,大阪倉庫,0,20,2026/09/15
製品E-500,大阪倉庫,85,30,2026/06/01AIへの頼み方です。
全拠点の在庫で、発注点を下回る品目と、
90日以上出庫のない品目を1つの表にし、理由を付けてください。
（今日は2026/09/29）結果は、1枚の表で返ってきます。
| 品目 | 拠点 | 在庫数／発注点 | 判定 |
|---|---|---|---|
| 部品A-100 | 東京倉庫 | 40／50 | 発注点割れ |
| 部品B-200 | 東京倉庫 | 300／100 | 90日動きなし |
| 部品D-400 | 大阪倉庫 | 0／20 | 発注点割れ |
| 製品E-500 | 大阪倉庫 | 85／30 | 90日動きなし |
人が確認するのは、次の2点です。
- 入荷予定：発注点割れの品目に、すでに発注済みの入荷予定がないか
- 滞留の理由：90日動いていない品目が、季節品や保守用の部品ではないか
1点目を飛ばすと、同じ品目を二重に発注します。
発注残と合わせて見るよう、頼み方に「在庫数に発注残を足した数で判定して」と足すと、この確認が軽くなります。
この点検は、品目ごとの発注点がNetSuiteに入っていることが前提です。
発注点と安全在庫の決め方は、在庫最適化とはで扱っています。
「90日」は、品目の区分ごとに変えます（第12章の失敗2）。
足りないと思ったら、組立品の中を見る
部品J-900の在庫はゼロ。ところが倉庫には、部品J-900を2個ずつ使った組立品Xが40個ある（架空の例）。
AIにBOM（部品表）と在庫を読ませれば、「分解すれば最大80個出せる」という案も出せます。
分解してよいかは、組立品Xの今後の受注見込みを見て、人が決めます。
点検②｜拠点間の在庫の偏りに、移動数の案を出させる
東京倉庫は欠品しがちなのに、大阪倉庫には同じ製品が余っている。
複数の倉庫を持つ卸売・製造で、毎日のように起きる場面です。
元のデータです（架空の例）。
| 品目 | 拠点 | 在庫数 | 1日の販売数 |
|---|---|---|---|
| 製品F-600 | 東京倉庫 | 60 | 6 |
| 製品F-600 | 大阪倉庫 | 240 | 2 |
頼み方の例です。
この品目の拠点別在庫を比べ、販売の速さに合わせて
在庫日数がそろうような移動数量を提案してください。結果は、次のとおりです。
| 拠点 | 在庫日数（いま） | 移動後の在庫 | 在庫日数（移動後） |
|---|---|---|---|
| 東京倉庫 | 10日 | 225 | 約38日 |
| 大阪倉庫 | 120日 | 75 | 約38日 |
提案は「大阪倉庫から東京倉庫へ165個移す」です。
2つの倉庫の在庫は合わせて300個、1日の販売は合わせて8個。
両方とも、約38日分にそろう計算です。
移動の前と後を並べると、次のとおりです。
人が確認するのは、次の2点です。
- 輸送費：165個を運ぶ費用が、欠品を防ぐ効果に見合うか
- 大阪の予定：大阪倉庫に、大口の受注や出荷の予定が入っていないか
移動を決めたら、NetSuiteでは移動伝票で記録します。
移動伝票は、出荷から受け取りまでの各段階を追え、輸送中の在庫も分かります。
承認を必須にする設定にすれば、権限のある人が承認するまで出荷できません（出典：Oracle NetSuiteのヘルプ、2026年9月確認）。
AIの案を人が承認する流れを、この設定で仕組みにできます。
移動の案を需要計画の中で自動で作る方法は、NetSuiteの需要予測（Demand Planning）完全ガイドで扱っています。
卸売の複数倉庫の考え方は、卸売・商社のNetSuite活用ガイドをご覧ください。
点検③｜値上がりした仕入品目を、上昇率の順に出す
原材料の値上げが続き、どの品目がいくら上がったかを追い切れない。
発注書の履歴から単価を拾い、Excelで比べている場面です。
元のデータです（架空の例）。
| 品目 | 仕入先 | 前回単価（円） | 今回単価（円） |
|---|---|---|---|
| ステンレス板 | サンプル資材 | 1,200 | 1,320 |
| 梱包箱 | テスト紙工 | 85 | 85 |
| 樹脂ペレット | 架空化成 | 410 | 470 |
| ボルトM8 | 見本金物 | 12 | 12 |
頼み方の例です。
直近の発注書と前回の発注書の単価を品目ごとに比べ、
値上がりした品目を上昇率の大きい順に出してください。結果は、2品目です。
| 品目 | 仕入先 | 単価（前回→今回） | 上昇率 |
|---|---|---|---|
| 樹脂ペレット | 架空化成 | 410→470 | +14.6% |
| ステンレス板 | サンプル資材 | 1,200→1,320 | +10.0% |
毎朝見るなら、「購買上位20品目で1年の単価の推移を出し、10%超に印を」と広げます。
値上がり分を販売価格に転嫁するか、仕入先と交渉するか。
これは人が決めます。
AIの表は、交渉の場に持っていく材料です。
この点検は、品目コードがそろっていることが前提です。
同じステンレス板に2つのコードがあると、前回の単価が見つかりません。
値上がりが特定の仕入先に偏っていないかを見る考え方は、仕入の偏りをどう測るかで扱っています。
点検④｜仕入先の成績表を、数字で作る
「あの仕入先は、遅れが多い気がする」。
気がするだけでは、交渉の場で押し返されます。
元のデータは、発注と入荷の記録です（架空の例）。
仕入先,発注書,納期,入荷日,発注数,入荷数
サンプル資材,PO-601,2026-09-10,2026-09-10,100,100
サンプル資材,PO-602,2026-09-20,2026-09-24,100,100
テスト紙工,PO-603,2026-09-12,2026-09-12,500,480
テスト紙工,PO-604,2026-09-22,2026-09-22,500,500
架空化成,PO-605,2026-09-15,2026-09-15,200,200頼み方の例です。
仕入先ごとに、発注件数、納期どおり入荷した割合、
発注数に対する入荷数の割合を表にしてください。結果です。
| 仕入先 | 発注件数 | 納期遵守率 | 数量充足率 |
|---|---|---|---|
| サンプル資材 | 2 | 50% | 100% |
| テスト紙工 | 2 | 100% | 98% |
| 架空化成 | 1 | 100% | 100% |
サンプル資材は、PO-602が4日遅れました。
テスト紙工は、納期は守っていますが、PO-603で20個足りませんでした。
「遅れ」と「不足」は、別の問題として話す必要があります。
人が確認するのは、遅れの原因が自社の側にないかです。
発注そのものが遅かった、仕様の確定が遅れた、という例は珍しくありません。
自社の発注の日付も並べてから、仕入先と話します。
入荷日が正しく記録されていることが前提です。
入荷の処理を翌週にまとめて入れている会社では、遵守率が実際より悪く出ます。
先の遅れと欠品は、NetSuite標準のControl Towerで見る
ここまでの4つは、過去と今日の点検でした。
先の遅れと欠品は、NetSuite標準のSupply Chain Control Towerで見ます。
在庫の残高の推移を、先まで見る
Control Towerは、在庫の需要と供給をシミュレーションし、在庫が需要に見合っているかを分析する機能です。
受注・移動伝票・作業指図・発注書から、品目ごとに在庫の残高が先々どう動くかを出します。
対象は在庫品目と組立品で、ロット・シリアルの品目も含みます（出典：Oracle NetSuiteのヘルプ、2026年9月確認）。
たとえば原材料R-12が、東京で10月10日ごろに足りなくなる。
製品P-88が、大阪で積み上がる（架空の例）。
全品目の定期点検をやめ、こうした品目だけを朝に見る運用に変えられます。
人が確認するのは、先の需要の見込みです。
受注の予定が営業の見込みと合っていなければ、推移の線もずれます。
在庫の推移（Snapshot）を使うには、次の4つの機能を有効にします（出典：Oracle NetSuiteのヘルプ、2026年9月確認）。
- 複数拠点の在庫（Multi-Location Inventory）
- Advanced Inventory Management
- Demand Planning
- Supply Chain Control Tower
自社の契約で有効にできるかは、日本のアカウントでの提供状況とあわせて、NetSuiteのアカウント担当に確認してください。
仕入先の納期遅れを、確信度つきで知る
仕入先の遅れに気づくのが、入荷予定日の当日。
そこから生産計画を組み直している会社には、予測リスク（Predicted Risks）が役に立ちます。
予測リスクは、発注書・移動伝票・受注書の遅れや早まりを予測して示す機能です。
しきい値は、Control Towerの設定で決めます。
仕入先の「遅れ・早まりの日数」と「確信度」を組にして設定します。
受注と移動伝票にも、同じ組のしきい値があります（出典：Oracle NetSuiteのヘルプ、2026年9月確認）。
作業イメージです（架空の例）。
（設定）仕入先：遅れ3日以上／確信度70%以上
（表示例）PO-702（テスト素材）：遅れの予測5日、確信度78%予測が出た発注について、人が仕入先に実際の出荷予定を問い合わせます。
電話をかける先が、全仕入先から1社に絞れます。
使うには、2つの機能を有効にします。
Supply Chain Control TowerとSupply Chain Predicted Risksです（出典：同上）。
ヘルプに地域の記載はないため、日本のアカウントで使えるかは、NetSuiteのアカウント担当に確認してください。
一度きりの特殊な発注は、予測から外す
一度きりの特注の金型が45日遅れ、同じ仕入先のふだんの部品まで「遅れそう」と出続ける。
こうした外れ値は、予測を狂わせます。
発注書などの画面に「Exclude From Predicted Risk」の項目を出し、チェックを入れると、その取引を予測から外せます。
外れ値や一度きりの取引を外すと、予測のモデルの精度が上がります（出典：Oracle NetSuiteのヘルプ、2026年9月確認）。
ふだんの遅れまで外すと、予測が甘くなります。
外すかどうかは、購買担当が1件ずつ判断します。
点検⑤｜在庫レポートに、AIの要約を付ける
在庫の台帳を開いても、どこが問題かを読み取るのに時間がかかる。
そういう朝には、NetSuite標準のNarrative Insightsが使えます。
Narrative Insightsは、対応するレポートを生成AIが短い文章で要約する機能です。
在庫と購買の対象は、次のとおりです（出典：Oracle NetSuiteのヘルプ、2026年9月確認）。
- 在庫の台帳（Stock Ledger）
- 入荷待ちの受注（Inventory Back Order Report）
- 在庫の動きの明細（Inventory Activity Detail）
- 未完了の発注（Open Purchase Orders）
- レコードでは、在庫品目（Inventory Items）
レポートを開いてGenerate Insightを押すだけです。
AI設定の「Enable Narrative Insights」は、既定でオンです（出典：同上）。
たとえば、在庫の台帳で部品G-700の期末在庫がマイナス5、製品H-800が入庫120・出庫0だったとします（架空の例）。
要約は「部品G-700がマイナス在庫。出庫の先行計上の可能性。製品H-800は入庫のみで出庫がなく、滞留の恐れ」のような形になります。
人が確認するのは、マイナス在庫の原因です。
入出庫の伝票を開き、出庫の登録が入荷より先になっていないかを見ます。
Oracleのヘルプでは、すべての地域と、システムが対応する言語で使えるとされています（出典：同上）。
一方、海外の解説には、在庫レポートの要約は当初は英語の画面だけだったという記述もあります。
自社の日本語の画面で、在庫の台帳に要約が出るかを一度試してください。
カスタマイズしたレポートは対象外です。
対象のレポートの全体は、NetSuite Narrative Insightsとはで扱っています。
毎朝の点検を仕組みにする｜頼み方1本と、権限の線引き
①〜④の点検は、毎朝1本の頼み方にまとめられます（架空の例）。
⑤の要約と遅れの予測は、NetSuiteの画面で見ます。
平日の毎朝7時半に、在庫と仕入の点検をしてください。
1. 発注点割れ（在庫数＋発注残で判定）と、90日出庫のない品目
2. 拠点間で在庫日数が3倍以上違う品目と、移動数の案
3. 購買上位20品目で、前回より10%超値上がりした品目
4. 入荷予定日を過ぎた発注と、その仕入先
結果は4つの表にし、発注書・移動伝票は作らないでください。決まった時刻に動かす方法（Claudeの予約タスクやChatGPTのタスク）は、毎朝の売上速報を自動で届けるで扱っています。
AIに任せるのは候補まで。確定は人
AI Connector ServiceでつないだAIは、レコードの作成・更新もできます。
できる範囲は、つなぐときのロールの権限で決まります（出典：Oracle NetSuiteのヘルプ、2026年9月確認）。
「発注点割れの品目を発注しておいて」と頼めば、発注書を作れてしまう構成もありえます。
そこで、線を次のように引きます。
| AIが引き受けること | 人が決めること |
|---|---|
| 発注点割れ・滞留の一覧 | 発注するか、いくつか |
| 移動数の案 | 移動するか、いつ運ぶか |
| 値上がり品目の表 | 転嫁か、交渉か |
| 仕入先の成績表・遅れの予測 | どの仕入先と、何を話すか |
| レポートの要約 | 伝票を開いて原因を見るか |
つなぐロールは、発注書や移動伝票を作る権限を持たないものにします。
管理者のロールでは、そもそもつなげません。
ロールには「MCP Server Connection」と「OAuth 2.0 Access Tokens」の権限を付けます。
対応するAIは、公式FAQではClaude ProとChatGPTで、ChatGPTはプランによって開発者モードが要ります（出典：同上）。
ロールの決め方は、AIにNetSuiteを触らせる前の安全ルールで扱っています。
受注の入力が遅れれば、発注点割れの判定も遅れます。
注文を早く入れる方法は、注文書PDF・メール注文をAIで受注データにするで扱っています。
判断の物差し｜どの点検から始めるか
5つを一度に始める必要はありません。
いちばん困っていることから、1つか2つを選びます。
会社の状態ごとに、合う始め方をまとめると次のとおりです。
| 会社の状態 | 始める点検 | AIとの親和性 | 最初にやること |
|---|---|---|---|
| 発注点が品目に入っている | ①から | 高。判定の基準がデータにある | 発注残を足して判定する条件を決める |
| 倉庫が2つ以上ある | ②から | 高。販売の速さを拠点別に読める | 輸送費の目安を決める |
| 購買の金額が大きい | ③と④から | 高。発注書の履歴がそのまま材料 | 品目コードの重複をなくす |
| 在庫の数が帳簿と合わない | どれもまだ早い | 低。AIは合わない数を読むだけ | 入出庫の記録と棚卸し |
最後の行の会社は、点検の前に止まってください。
合わない在庫をAIが毎朝読んでも、合わない一覧が毎朝届くだけです。
NetSuite以外の道が合う場合もあります。
- 品目が数十で倉庫が1つ：いまの在庫表のCSVをAIに渡すだけで足りる。システムは急がない
- 在庫だけを小さく良くしたい：専用の在庫管理システムや、Odooなどほかの製品も比べる
- 点検の形が独特：自社の品目の区分に合わせた小さなAIの仕組みを作る（AIスクラッチ開発）
在庫・購買の深さで製品を比べる考え方は、NetSuiteとOdooの在庫・購買・製造で扱っています。
いま使っている会社と、これから選ぶ会社
いまNetSuiteを使っている会社
AIをつなぐ前の一歩として、発注点割れの保存検索を毎朝メールで届ける方法もあります。
保存検索は、決めた時刻や、レコードが作成・更新されたときにメールを送れます（出典：Oracle NetSuiteのヘルプ、2026年9月確認）。
AIを使うなら、明日から次の順で試せます。
- 品目ごとに在庫数・発注残・発注点を並べた保存検索を1本用意する（項目名は自社の環境で確認）
- その結果をAIに渡し、第3章の頼み方で1枚の表にさせる
- 1週間、担当者の突き合わせの結果と並べ、食い違いを見る
食い違いがなくなれば、AI Connector Serviceでつなぐ段階です。
OracleのFAQには地域の記載がありません（出典：Oracle NetSuiteのヘルプ、2026年9月確認）。
日本のアカウントで使えるかは、NetSuiteのアカウント担当に確認してください。
つなぎ方の全体は、NetSuite AI Connector Service（MCP）とはで扱っています。
これからNetSuiteを選ぶ会社
NetSuiteなら、在庫・発注・入荷・受注が同じデータにあります。
在庫表と発注残を別々に出して突き合わせる作業そのものが要りません。
要件定義で、発注点と滞留の日数を品目の区分ごとに決めておけば、稼働の翌朝から点検が回ります。
在庫の機能の全体は、NetSuiteの在庫管理でできることをご覧ください。
よくある失敗3つ
失敗1：AIの一覧を、そのまま発注する
起きること：発注点割れの一覧を見て、全品目を発注した。翌週、同じ部品が二重に入荷した。
原因：前日に発注済みの品目が、一覧に残っていた。発注残を足して判定する条件を、頼み方に書いていなかった。
避け方：頼み方に「在庫数に発注残を足した数で判定」と書きます。
AIには発注書を作る権限を持たせず、発注は人が決める手順にします。
失敗2：「90日動きなし」を全品目に当てる
起きること：保守用の部品や季節品が、毎朝「滞留」として並ぶ。担当者は一覧を読まなくなる。
原因：品目の性格を分けず、同じ日数で判定した。
避け方：品目の区分ごとに、滞留と見なす日数を決めます（例：食品は30日、保守用の部品は1年）。
毎朝の一覧に出るのは、手を打つべき品目だけにします。
失敗3：点検で同じ品目が出続けるのに、発注点を直さない
起きること：毎朝、同じ部品が発注点割れで出る。その都度の発注が、また毎朝の作業になる。
原因：発注点そのものが、いまの販売の速さに合っていない。
避け方：同じ品目が月に何度も出たら、点検ではなく発注点の設計を見直します。
見直し方は、在庫最適化とはとNetSuiteの需要予測（Demand Planning）完全ガイドで扱っています。
ベンチャーネットならこう見る
在庫の点検の相談を受けると、ベンチャーネットは最初に、いまの点検を見える化します。
誰が、何時に、どの表を突き合わせ、誰に何を伝えているか。
見える化すると、たいてい整理整頓で消せる作業が出てきます。
同じ在庫表を、購買と倉庫が別々に出している。
誰も見ていない「滞留一覧」が、毎週作られている。
先に廃止・統合してから、残った点検をNetSuiteの標準の機能と照らします（Fit&Gap）。
そのうえで、残った点検ごとに3つから選びます。
| 選び方 | 在庫の点検での例 |
|---|---|
| 標準に合わせる | 先の欠品と遅れは、Control Towerの予測リスクで見る |
| 開発する | 品目の区分ごとに滞留の日数を変える判定を作る |
| 残す | 年に一度の仕入先の格付けは、人が面談の結果も入れて作る |
もう1つ、1か月だけ試してほしいことがあります。
ベテランの購買担当の判断と、AIの一覧を、同じ朝の同じ数字で並べて比べることです。
どちらが先に気づいたかの差が、次に何をAIに任せるかの判断材料になります。
今日できること｜1時間で、朝の点検を書き出す
いま社内で毎朝・毎週やっている在庫と仕入の点検を、次の表に書き出してください。
| 点検の名前 | 誰が・何分で | 使う表 | 結果で何を決めるか |
|---|---|---|---|
| （例）発注点割れの確認 | 購買・60分 | 在庫一覧と発注残のExcel | 当日の発注 |
結果で何も決めていない点検は、やめる候補です。
2つ以上の表を突き合わせている点検があれば、明日の朝、第3章の頼み方で試せます。
よくある質問
Q1. AIに発注書や移動伝票まで作らせてよいですか
作らせず候補の一覧までにします。
発注書や移動伝票を作る権限を持たないロールでつなぎ、確定は人が行います（第9章）。
Q2. AI Connector Serviceは日本で使えますか
日本のアカウントで使えるかはNetSuiteのアカウント担当に確認してください。
OracleのヘルプのFAQには、地域の記載がありません。
管理者のロールではつなげない点にも注意します（第9章・第11章）。
Q3. 仕入先の納期遅れは、事前に予測できますか
Control Towerの予測リスクで確信度つきで示せます。
遅れの日数と確信度のしきい値は、Control Towerの設定で決めます。
日本のアカウントで使えるかは、NetSuiteのアカウント担当に確認してください（第7章）。
Q4. 在庫レポートのAI要約は日本語で使えますか
Oracleのヘルプでは全地域とシステムの対応言語で使えるとされています。
在庫の台帳や入荷待ちのレポートなどが対象です。
自社の日本語の画面で、Generate Insightを押して試してください（第8章）。
Q5. 需要予測や発注点の見直しとは何が違いますか
点検は毎朝の実務で発注点は在庫の設計です。
点検で同じ品目が何度も出るなら、発注点の設計を見直します（第12章）。
まとめ
- 毎朝の点検は、発注点割れと滞留・拠点の偏り・値上がり・仕入先・レポートの要約の5つ
- ①〜④は、AI Connector ServiceでつないだAIに、頼み方1本で一度に洗い出させる
- 先の遅れと欠品は、NetSuite標準のControl Towerで見る。日本での提供状況は確認する
- AIは候補まで。発注書・移動伝票を作る権限は渡さず、確定は人が行う
- 同じ品目が出続けたら、点検ではなく発注点の設計を直す
朝の2時間の突き合わせは、在庫を1個も減らさない作業でした。
その2時間を、発注と移動を決める時間に替えられるか。
分かれ目は、AIの性能より先に、在庫の数字が帳簿と合っているかにあります。
もう少し詳しく知りたい方へ
在庫の点検を仕組みにしたいが、発注点が品目に入っていない。
AIをつなぎたいが、権限の線をどこに引くか決めかねている。
そうした段階から、ご相談をお受けしています。
- 在庫・購買をNetSuiteで一つのデータにしたい方：SaaS型クラウドERP NetSuite導入支援
- Claude・ChatGPTをNetSuiteにつなぎ、毎朝の点検を減らしたい方：生成AIによる経営革新伴走サービス
- どの点検から始めるかを相談したい方：お問い合わせ
