「NetSuiteと、あのサービスをつなぐ仕組みも、AIで作れるのでは」
生成AIでプログラムが書けるようになり、経営者や情報システムの担当者から、こう聞かれることが増えました。
NetSuite連携とは、NetSuiteと外部のサービスの間で、データを受け渡す仕組みのことです。
答えは、作れます。
ただし、AIが速くするのは「書く」工程だけです。
連携の開発には、書く前に「決める」工程があります。
書いた後には、「確かめる」「直し続ける」工程が続きます。
この3つは、AIを使っても人が担う部分が残ります。
では、人が握る「決める」とは、具体的に何を決めることなのか。
答えは、AIに書かせる5つの手順の2番目にあります。
この記事で分かること
- 生成AIで、連携開発の何が変わり、何が変わらないのか
- NetSuite連携の2つの作り方と、AIとの相性
- AIに連携を書かせるときの5つの手順
- つまずきやすい4つの難所
- 費用を考えるときに見るべき要素
生成AIで、連携開発の何が変わったか
AIコーディングエージェントとは
AIコーディングエージェントとは、指示を受けて、プログラムを書き、動かし、直すところまでを自分で進めるAIのことです。
Claude Code（Anthropic社のAIコーディングツール）や、Codexなどがあります。
これまでは、人が1行ずつ書いていました。
いまは、人が指示と資料を渡し、AIが書いたものを人が点検する。そういう分担ができます。
工程ごとに見ると
工程に分けると、AIが効く部分と、効きにくい部分がはっきりします。
| 工程 | これまで | 生成AIで変わること | 人に残ること |
|---|---|---|---|
| 決める | 何を、どちら向きに、いつ流すかを決める | 対応表の下書きを速く作れる | 何を正本にするか・例外をどう扱うかの決定 |
| 書く | 人が1行ずつ書く | 大きく速くなる | 書かれたものの確認 |
| 確かめる | テスト用の環境で試す | テストの手順やデータの下書き | 業務として正しいかの判断 |
| 直し続ける | 担当者が仕様を覚えて直す | 変更点の調査や修正の下書き | 誰が責任を持つかの決定 |
速くなるのは、主に「書く」工程です。
決めていないことをAIに書かせても、速く間違ったものができるだけです。
似た言葉との違い
「NetSuite×AI」には、いくつかの意味があります。
| 何をするか | 例 | この記事との関係 |
|---|---|---|
| AIに、NetSuiteのデータを読ませたり操作させたりする | AI Connector Service、MCP | 別の話。AI Connector Serviceで扱っています |
| NetSuiteの開発者向けに、Oracleが用意したAIを使う | SuiteCloud Developer Assistant | 近い話。NetSuite Developer Assistantとはにあります |
| 汎用のAIに連携のプログラムを書かせる | Claude Code、Codexなど | この記事のテーマ |
NetSuite連携の2つの作り方
AIに書かせる前に、連携のプログラムをどこに置くかを決めます。
作り方は、大きく2つです。
作り方A：外に中継のプログラムを置く
NetSuiteの外にプログラムを置き、NetSuiteと相手のサービスの両方と通信させる方法です。
NetSuite側の入口には、REST Web Servicesを使います。
REST Web Servicesとは、NetSuiteのレコードを外から読み書きするための、公式の窓口です。
Oracleの公式ドキュメントでは、次のことができるとされています。
- レコードの作成・参照・更新・削除
- レコードの定義（メタデータ）の取得
- 問い合わせ（クエリ）の実行
公式ドキュメントは、RESTletと違い、自分でスクリプトを書いて配置しなくてよい点も利点に挙げています。
作り方B：NetSuiteの中で完結させる
NetSuiteの中にスクリプトを置き、そこから相手のサービスを呼ぶか、相手から呼ばれる方法です。
RESTletとは、NetSuiteの中に置く、外から呼び出せる独自の窓口のことです。
スクリプトを書く言語は、SuiteScriptです。
基本はSuiteScriptとはで扱っています。
どちらを選ぶか
| 観点 | A：外に中継を置く | B：NetSuiteの中で完結 |
|---|---|---|
| NetSuite側の窓口 | REST Web Services | RESTlet・スクリプト |
| 処理量の上限 | 外側は自社の環境しだい | NetSuiteの処理量の上限（ガバナンス）の中で動く |
| 相手サービスの変更への強さ | 外側だけ直せばよいことが多い | NetSuiteの中を直す必要がある |
| 保守の担い手 | 外側の環境も含めて誰かが持つ | NetSuiteに詳しい人が持つ |
| AIとの親和性 | 高：一般的なプログラムとして書けるため、汎用のAIが得意な形 | 中：NetSuite固有の書き方と上限の知識が要る。後述のAgent Skillsで補える |
Aのプログラムの置き場所は、NetSuiteの外（自社や外部のサーバー）です。Bは、NetSuiteの中に置きます。
どちらが正しいということはありません。
目安は1つです。相手のサービスが変わりやすいなら外に、NetSuiteの中の動きと強く結びつくなら中に置きます。
AIに連携を書かせる5つの手順
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、次の5つの手順を勧めています。
| # | 手順 | AIの役割 | 人の役割 |
|---|---|---|---|
| 1 | 資料をそろえる | — | 相手の仕様書と、NetSuite側の定義を集める |
| 2 | 対応表をつくる | 下書き | 正本と例外の扱いを決める |
| 3 | 作り方を選ぶ | 選択肢の比較 | A（外）かB（中）かを決める |
| 4 | テスト用の環境で繰り返す | 書く・直す | 業務として正しいかを確かめる |
| 5 | 仕様書と再実行の仕組みを残す | 下書き | 保守の担い手を決める |
手順1：資料をそろえる
AIは、渡された資料の範囲でしか正しく書けません。
最初に渡す資料の質が、出来上がりの質を決めます。
そろえるのは、次の3つです。
- 相手のサービスのAPI仕様書：何をどう送れば、何が返ってくるか
- NetSuite側のレコードの定義：どの項目に、どんな値が入るか。REST Web Servicesでは、レコードの定義を取得できます
- NetSuite固有の書き方の手引き：次のAgent Skills
SuiteCloud Agent Skills
Oracleは、AIコーディングツール向けにSuiteCloud Agent Skillsを公開しています。
Agent Skillsとは、AIにNetSuite開発の決まりごとを教えるための、手引きの集まりです。
Oracleの公式ドキュメントとGitHubの公式リポジトリの説明は、次のとおりです。
| 項目 | 内容 |
|---|---|
| 対応するツール | Claude Code、Codex、Cline |
| 配布の場所 | GitHubのOracle公式リポジトリ |
| 含まれる手引きの例 | レコードと項目の参照、安全なコーディング（Webアプリの安全対策の指針であるOWASP）、SDF（NetSuiteの開発・配布の仕組み）のベストプラクティス、SuiteScript 1.0から2.1への移行 など |
| ライセンス | Universal Permissive License 1.0 |
汎用のAIは、NetSuite固有の書き方を知らないことがあります。
Agent Skillsを渡せば、NetSuiteの決まりに沿ったコードに近づけられます。
手順2：対応表をつくる
冒頭の問いの答えは、この手順にあります。
対応表とは、相手のサービスのどの項目が、NetSuiteのどの項目に入るかを1行ずつ書いた表のことです。
マッピング表とも呼びます。
AIに下書きさせれば、速く作れます。
ただし、次の2つは人が決めます。
- 正本はどちらか：同じ情報を両方で持つとき、どちらを正しいとするか
- 例外をどう扱うか：相手にない項目、NetSuiteにない区分、金額の端数
ここを決めずに先へ進むと、手順4で何度もやり直すことになります。
手順3：作り方を選ぶ
第2章のA（外に中継）かB（NetSuiteの中）かを決めます。
AIに両方の案を書かせて比べることもできます。
それでも、決め手は保守を担う人の体制です。
手順4：テスト用の環境で繰り返す
本番のNetSuiteで試してはいけません。
サンドボックス（本番と切り離されたテスト用の環境）で、書いて、動かして、直すを繰り返します。
AIは、この繰り返しを速くします。
ただ、業務として正しい結果かどうかは、経理や現場の担当者が見る必要があります。
サンドボックスの使い方は、NetSuiteのサンドボックスとはで扱っています。
手順5：仕様書と再実行の仕組みを残す
AIで速く作れたものほど、なぜそう作ったかが残りにくくなります。
最後に、次の2つを成果物として残します。
- 仕様書：対応表、正本の決め方、例外の扱い、認証の方式
- 再実行の仕組み：途中で止まったとき、どこからやり直せば二重に登録されないか
AIに下書きさせて構いません。
作った人がいなくなっても、別の人が直せる状態で残すこと。それが手順5の目的です。
開発・レビュー・スキル｜AIへの頼み方で差が出る3点
5つの手順を回すとき、AIへの頼み方で出来が変わります。
先に決めておきたいのは、次の3点です。
- 開発は標準機能と上限から：「まず標準機能（ワークフロー・保存検索）で足りるか検討し、足りない場合だけコードを書く」と指示に入れる。Fit to Standardの考え方と相性がよい
- スキルで決まりを渡す：Claude Codeには、Oracle NetSuiteが公開する公式プラグイン「netsuite-suitecloud」を入れられる。SuiteScript・SDF・権限などの観点をまとめて使える
- レビューもAIに頼める：GitHubのプルリクエストに「@claude このSuiteScriptのガバナンス消費を確認して」と書く。指摘を採るかどうかは人が決める
（出典：Tim Dietrichのブログ、Claude Marketplace、Claude Code Docs、2026年9月確認）
処理量の上限（難所④）を指示に書くかどうかで、結果はこう変わります。サンプルは架空です。
| 手順 | 中身 |
|---|---|
| 元データ | 「全受注のメモ欄を更新するスクリプトを書いて」。本番の約1万件で止まった |
| AIへの頼み方 | Map/Reduce（大量処理向けの型）で、上限を意識して書く。本番と同じ件数で試す手順も付ける |
| 結果 | Map/Reduce型のスクリプトと、Sandboxで本番相当の件数を流す確認手順 |
| 人の確認 | 本番と同じ件数を流し、全件が更新されたかを件数で見る |
（出典：Amit Kothari「Claude for NetSuite SuiteScript」、2026年9月確認）
どの頼み方でも、AIは下書きまでです。
本番に入れるかを確定するのは人です。
つまずきやすい4つの難所
AIで速く書けても、止まりやすい場所があります。
難所①：日本固有の会計・税務の要件
消費税の区分、インボイス制度、支払の締めと期日。
日本の業務には、海外の資料には書かれていない要件があります。
AIは、渡されていない日本の要件を知りません。
対応表をつくる段階で、経理の担当者が要件を書き込む必要があります。
日本向けの機能は、NetSuiteの日本向けローカライズにまとめています。
難所②：相手のサービスの審査や契約
相手のサービスのAPIは、誰でも使えるとは限りません。
契約者だけ、上位のプランだけ、パートナーの審査を通った会社だけ。そうした条件がよくあります。
プログラムを書く前に、相手のAPIを使える条件を調べてください。
書き上げてから「使えない」と分かるのが、いちばん大きな手戻りです。
難所③：双方向・明細の同期
片方向に、見出しの情報だけを送るのは、比較的簡単です。
難しくなるのは、次の場合です。
- 双方向：両方で更新されたとき、どちらを優先するか
- 明細：1件の取引に複数の行があり、行の追加・削除も同期する
ここは、対応表と正本の決め方でほぼ決まります。
AIに書かせる前に、手順2で決めきってください。
難所④：NetSuiteの処理量の上限と、認証の変更
NetSuiteの中で動くスクリプトには、使ってよい処理量の上限（ガバナンス）があります。
Oracleの公式ドキュメントでは、スクリプトの種類ごとに上限が決められています。
| スクリプトの種類 | 使える処理量（使用単位） |
|---|---|
| スケジュールスクリプト | 10,000 |
| RESTlet | 5,000 |
| ユーザーイベントスクリプト・Suitelet・クライアントスクリプト | 1,000 |
| マップ／リデュース | 全体の上限なし（処理の段階ごとに管理） |
RESTletの入出力は、1つの文字列あたり10MBまでと公式に書かれています。
同時に動かせる数も、ほかのウェブサービスの呼び出しと合わせて、アカウント単位で管理されます。
汎用のAIが書いたコードは、この上限を見落としやすい。
これが、ベンチャーネットの実感です。
件数の少ないテストでは動き、本番の件数で止まる。財務に関わるレコードを扱う処理は、必ず人がレビューしてください。
あわせて、認証の方式も変わります。
NetSuiteでは2027年に向けて、古い認証方式が使えなくなり、OAuth 2.0への移行が必要になります。
期限と移行の手順は、NetSuite認証の「2027年問題」で扱っています。
これから作る連携は、最初からOAuth 2.0で作ってください。
費用は、何で決まるのか
「AIで作れば、いくらで済むのか」。
多くの方が、最初に気にする点です。
金額は規模で大きく変わるため、一律の数字は出せません。
ただ、何で決まるかは言えます。
| 費用を決める要素 | 小さく済む | 大きくなる |
|---|---|---|
| つなぐ相手の数 | 1つ | 複数 |
| 流す向き | 片方向 | 双方向 |
| 流す単位 | 見出しだけ | 明細まで |
| 例外の多さ | 少ない | 業務ごとに例外がある |
| 相手の仕様の変わりやすさ | 変わりにくい | よく変わる |
| 保守の体制 | 社内に担い手がいる | 外に頼む |
AIで小さくなるのは、主に「書く」工程の費用です。
決める・確かめる・直し続ける費用は、AIを使っても残ります。
見積もりを比べるときは、書く工程の金額だけでなく、この3つが含まれているかを見比べてください。
NetSuiteの導入全体で見ても、連携は費用を動かす要因の1つです。
ベンチャーネットが支援してきた導入では、費用と期間を左右する要因が4つありました。
機能範囲、開発（特に外部システムとの連携）、社内の体制、ユーザー数です。
導入全体の費用の考え方は、NetSuiteの料金で扱っています。
AIで作るか、既製品を使うかの考え方は、AIでスクラッチ開発とERP、どちらを選ぶべきかにあります。
生成AIで連携を作るときの、3つの失敗
AIでの開発を否定したいのではありません。
速く作れるようになったからこそ、起きやすくなった失敗です。
失敗①：AIに丸投げして、仕様が残らない
よくある現象
- 担当者がAIと対話しながら、数日で連携を作った
- 動いているが、なぜその作りなのか誰も説明できない
- 担当者が異動した後、相手のサービスの変更に対応できない
なぜ起きるか
書く工程が速すぎて、決めた内容が記録に残らないからです。
AIとの対話の中で決めたことは、会話が終われば消えます。
どう回避するか
手順5の仕様書を、成果物として必ず残します。
AIに下書きさせ、人が確認して保管する。それだけで、次の人が直せる状態になります。
失敗②：テスト用の環境を飛ばして、本番で試す
よくある現象
- 「少しだけなら」と、本番で動かしてみた
- 重複した取引や、誤った金額が本番に入った
- 取り消しの作業のほうが、開発より時間がかかった
なぜ起きるか
AIで書く速さに、確かめる工程が追いついていないからです。
書けたら、すぐ動かしたくなります。
どう回避するか
本番の前に、必ずサンドボックスで試します。
手順5の「再実行の仕組み」を先に作っておけば、止まっても二重に登録されません。
失敗③：処理量の上限や認証を見落とし、ある日止まる
よくある現象
- テストでは動いた連携が、月末の件数で止まった
- NetSuiteの更新の後、認証に失敗してデータが流れなくなった
- 止まっていることに、しばらく誰も気づかなかった
なぜ起きるか
NetSuite固有の上限と、認証の変更は、汎用のAIが知らないことが多いからです。
どう回避するか
Agent Skillsを渡し、処理量の上限を意識したコードにします。
最初からOAuth 2.0で作り、止まったときに知らせる仕組みを入れておきます。
そもそも、作るべきか
AIで作れるようになっても、作らないほうがよい場合があります。
| 状況 | 向いている選択 |
|---|---|
| 相手のサービスに、NetSuite向けの既製のつなぎ込みがある | まず既製品を検討する |
| つなぐ処理が単純で、画面で組み立てられる | iPaaSを検討する |
| 件数が少なく、月に数回の手作業で済む | つながずに運用する |
| 自社固有のルールが多く、既製品では合わない | 作る |
判断の順番は、NetSuiteの連携を「内包・連携・再販」で切り分ける判断軸で扱っています。
連携の手段の全体像は、NetSuiteの連携方法まとめにあります。
ERPを段階で育てる中で連携がどこに位置づくかは、ERPの育て方は守破離をご覧ください。
今日できること：つなぎたい相手を1つ調べる
所要は30分です。
- つなぎたいサービスを1つだけ選ぶ
- そのサービスに公開されたAPIがあるか、使える条件（契約・プラン・審査）を調べる
- 流したい情報を5つ書き出し、それぞれどちらを正本にするかを決める
2で条件が合わなければ、作る前に止まれます。
3で正本を決められない項目があれば、そこが最初に話し合う論点です。
ベンチャーネットならこう見る｜書く前に決め、入れる前に試す
ベンチャーネットの仕事は、ゼロからの導入より、他社のあとの引き継ぎや、他システムとの連携が多くを占めます。
その経験から、連携開発では次の2つの型を守っています。
型1：標準に合わせる／開発する／残す
第7章の表は、この3つの選択にそのまま重なります。
- 標準に合わせる：既製のつなぎ込みやiPaaSで足りるなら、それを使う
- 開発する：自社固有のルールが多く、既製品では合わないときだけ作る
- 残す：件数が少ないなら、つながずに手作業の運用を続ける
既製のつなぎ込みやiPaaSで足りる連携を、あえて開発することはお勧めしません。
作ったものは、直し続ける必要があるからです。
型2：ベストプラクティスは、自社環境で試してから入れる
ベンチャーネットは、Oracleのベストプラクティスも、自社環境で検証してから入れます。
Agent Skillsも同じです。
AIが手引きどおりに書いたコードでも、サンドボックスで業務の件数を流してから本番に移します。
この2つの型に沿って、相手のAPIの確認、対応表と正本の設計、開発とテスト、仕様書と保守までを引き受けます。
開発では、生成AIも使います。
生成AIを使った連携開発の進め方を、自社の開発に取り入れることも検討しています。
NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。
特定の製品に誘導しない立場です。
よくある質問（FAQ）
Q1. 社内にプログラマーがいなくても、AIで連携を作れますか
A. 書く工程は、AIでかなり進められます。
ただし、対応表で正本と例外を決めること、業務として正しいかを確かめること、作った後に直し続けることは、人が担います。
とくに直し続ける担い手がいないと、相手のサービスが変わったときに止まります。
社内に担い手がいない場合は、保守まで含めて外部に頼むことを検討してください。
Q2. Oracleが用意しているAIと、Claude Codeのような汎用のAIは、どちらを使うべきですか
A. 目的によって違います。
NetSuiteの中のスクリプトを書くなら、Oracleの開発者向けAIが向いている場面があります。
ただし、北米先行・英語前提の機能のため、日本ですぐ使えるとは限りません。
外のサービスとつなぐ中継のプログラムを書くなら、汎用のAIのほうが扱いやすいことが多いです。
汎用のAIを使う場合は、SuiteCloud Agent Skillsを渡してNetSuite固有の決まりを補ってください。
Q3. AIで作れば、費用はどのくらい下がりますか
A. 一律の数字は出せません。
AIで小さくなるのは、主に「書く」工程の費用です。
「決める」「確かめる」「直し続ける」の費用は、AIを使っても残ります。
つなぐ相手の数や、双方向か、明細まで同期するかによって、大きく変わります。
Q4. 既存の連携を、AIで作り直すべきですか
A. 動いているなら、急ぐ必要はありません。
ただし、古い認証方式を使っている連携は、2027年に向けて見直しが必要です。
見直しのついでに、仕様書が残っていない連携を整理するのは、よい機会になります。
Q5. AIが書いたコードを、そのまま本番に入れても大丈夫ですか
A. いいえ。必ず人が確認し、サンドボックスで試してから本番に移してください。
とくに、処理量の上限と、財務に関わるレコードの扱いは、人がレビューする必要があります。
AIは下書きまで。確定は人が行います。
Q6. 社内の開発ルールを、毎回AIに説明するのが手間です
A. Claude Codeなら、プロジェクト直下のCLAUDE.mdに書いておけます。
命名規則などを200行以内でまとめ、チームで共有します。
（出典：Claude Code Docs、2026年9月確認）
AIのコードがルールを守っているかは、レビューで人が見ます。
まとめ
- 生成AIで、NetSuite連携は作れる。ただし、速くなるのは主に「書く」工程
- 「決める」「確かめる」「直し続ける」は、AIを使っても人が担う
- 作り方は、外に中継を置くか、NetSuiteの中で完結させるか。保守の体制で選ぶ
- 手順は、資料をそろえる→対応表→作り方を選ぶ→テスト用の環境で繰り返す→仕様書と再実行の仕組みを残す
- 難所は、日本の会計要件・相手の契約条件・双方向と明細・処理量の上限と認証
- 費用は規模で大きく変わる。書く工程以外の費用が見積もりに入っているかを見る
AIは、連携開発を速くします。
速くなった分を、「決める」と「確かめる」に回せた会社の連携が、長く動き続けます。
まずは、つなぎたい相手を1つ選び、流したい情報の正本を決めるところからです。
出典
- Oracle NetSuite Help Center「SuiteCloud Agent Skills Introduction」
- Oracle「netsuite-suitecloud-sdk / agent-skills（GitHub公式リポジトリ）」
- Oracle NetSuite Help Center「Overview of SuiteTalk REST Web Services」
- Oracle NetSuite Help Center「Script Type Usage Unit Limits」
- Oracle NetSuite Help Center「RESTlet Governance and Security」
（いずれも2026年9月23日確認）
もう少し詳しく知りたい方へ
つなぎたいサービスがあるなら、作るべきかどうかから、一緒に考えられます。
- 連携を作るべきか相談したい方 → お問い合わせ
- NetSuiteの開発・連携を依頼したい方 → NetSuiteアドオン開発サービス「NetSuiteリブート」
