はじめに
前回の記事 では、NetSuiteでデータを検索する一つの手法である「N/search」を応用し、自然言語をパラメーターに変換してデータを抽出するボットを作成しました。あえて、NetSuite用のSQLである「SuiteQL」ではなく、より歴史のある「N/search」を選択したのは、自然言語から 「NetSuite専門のSQL文」を作成するよりも、自然言語から 「N/searchのパラメーター」 を作成するほうが、私の試作段階では簡単かつ高精度に実現できたためです。また、N/searchパラメーターは、直感的に目視確認しやすいというメリットもありました。
今回は、SuiteQL（SQLライクな問い合わせ言語）を用いて、NetSuiteの画面からSuiteQLを実行してデータをダウンロードするアプリを試作し、実際のビジネスシナリオでどのように活用できるか、検討してみました。そのサンプルアプリの名前は、「SuiteQL むさし君」 です。
ちなみに、SuiteAnalytics ワークブックとは？
それ は、NetSuiteに標準搭載されている分析機能の一つで、GUIを通じて簡単にデータを抽出・分析し、視覚的にデータセットやレポートを作成できるツールです。「NetSuite上で、エクセルピボットテーブルやピボットグラフを作成する」、というイメージです。
なお、SuiteAnalytics ワークブックで、ドラッグ＆ドロップにより作成したレポートは、複雑なものであっても「SuiteQL」へ変換することができます。つまり、ワークブックと SuiteQL は「表裏一体」であり、「Microsoft Access」の「クエリ」が、専用の「SQL」へ変換できる関係と同じです。さらに例えるなら、SuiteQL は「舞台で頑張る黒子」、「縁の下の力持ち」、「開発者の味方」なのであります。そして、SuiteQL は「N/search」や保存検索では実現できない、柔軟で高度なデータ取得を可能にしてくれます。
具体的なビジネスシーン
順番が逆になりますが、先ずは「SuiteAnalytics ワークブック」の例として、製造業における、データ移行をあげます。製造業では、多段階の階層構造を持つ、複雑なBOM（部品表）などの原価データを、システム上で正確に保持する必要があります。レガシーシステムからNetSuiteへ移行する際、移行した、または移行中の「BOM関連データ」が正しくNetSuiteへ反映されているか、検証が不可欠です。NetSuite の BOM 関連データには、「アセンブリ → BOM → BOMリビジョン → コンポーネント（アイテム）」があります（一部です）。
上記のスクリーンショットのように、ひとつひとつのアセンブリに対してではなく、有効なアセンブリ全てに対して、「BOM関連データ」を一括して取得するのに、SuiteAnalytics ワークブック は、非常に便利です。
a. 「分析」タブを開く
b. 新規ワークブックで、「部品表リビジョン・コンポーネント」データセットを開く
c. ドラッグ＆ドロップで、「アセンブリ → BOM → BOMリビジョン → コンポーネント（アイテム）、数量」などを選択する
d. そのデータをごっそりダウンロードして、レガシーシステムのデータと比較する
なぜ、SuiteQL 「も」使うと便利なのか？
前項にて、「a, b, c, d」と簡単に表現しましたが、ドラッグ＆ドロップで作成されたデータが本当に正しいのか判断する、または、正しいものを作ることは、全員ができるものではありません。それは、どんなツールも同じであり、ドラッグ＆ドロップの「操作」はだれにでもできますが、求められる成果物（レポート）のデータ量や複雑さが増すにつれ、「操作」の後の「見極め」ができる人材のプールのは、残念ながら限られるのが現実でしょう。「BOM関連データ」の一括取得のためのワークブック作成を、「市民開発者 (Citizen Developer)」に完全に任せるのは、少し荷が重いかと思われます。
なお、異なる環境間で、カスタムのワークブックを移植する機能は、標準では存在しませんが、SuiteQL は SQL文 なので、標準のデータソースを参照しているかぎり、それはどの環境でも同じようにデータを取得してくれます。そんな背景がから、「どうやってBOM関連ワークブックを作成するのか」をスクリーンショットの指示書として提供する代わりに、「完成後のワークブック」をSuiteQL へ変換し、SuiteQLで正確なデータを取得してもらうほうが、効率的なケースも存在します。
SuiteAnalytics と SuiteQL の併用の、特殊な場合の例
A: NetSuiteパートナーなど、開発者側の「サンドボックス」環境
1. SuiteAnalyticsワークブックで視覚的にデータセットを作成
2. ワークブックからSuiteQLをエクスポート
3. 「SuiteQL むさし君」や SuiteScript などのツールを使用して、SuiteQL を実行
4. 実行結果を確認し、必要に応じてSuiteQL文を調整して完成させる（1～4を繰り返す）
例： 「ORDER BY」句の追加など
B: ユーザー側（ERP管理チームなど）の「本番」環境
5. 完成品の SuiteQL 文を受け取り、所定のツールを使用してデータを取得し（CSVダウンロードなど）、レガシーシステムのデータと比較する
※従来通り、ユーザー側で標準的に、SuiteAnalytics ワークブックをドラッグ＆ドロップで複製し、そのCSVエクスポート機能を使用頂いて問題ありません。上記1～5 は、あくまで非常に複雑なクエリを SuiteQL文 を通じて複製する、特殊なケースです。
サンプルアプリ「SuiteQL むさし君」の技術的なポイント（開発者向け）
今回のプロトタイプには以下の工夫加えてみました：
- SuiteQL実行前に、SQL文を解析し、大規模または危険な問い合わせを事前にブロック
- 実行成功時のみ結果のプレビューを表示し、CSVダウンロードを許可
- NetSuite標準のLLM「N/llm」を活用し、SQL文とその実行結果に対する分析コメントを生成（※むさし君は、SuiteQL と N/llm の「両刀使い」、というオチです）
※長時間におよぶ巨大なデータ取得が行われる可能性ゼロではないため、「SuiteQL むさし君」の使用は、サンドボックス環境を前提としてください。ただし、実際にそのような問い合わせが実行されたとしても、SuiteCloud は5分後にエラーを返す機能が備わっています。詳細については、以下のリンクを参考にされてください。
NetSuite サポートコミュニティ› 開発者コミュニティ › SuiteCloud 大容量データ処理に関する、5つのFAQ
LLMによる、今後の SuiteQL などの生成について
本日時点では、複雑なBOM関連の SuiteQL（NetSuite 専用 SQL）を、自然言語から正確に生成するのは困難です。しかしながら、それも時間の問題であり、そう遠くない未来（数か月後かもしれません）に実現するでしょう。
一方で、生成AIが提供してくれるヒントやソースコードを細部まで確認し、改良して実用的なものに仕上げていくことは、幸いにもまだエンジニアの役割です。そうした状況が、もうしばらくは続けばいいなと思っています。
まとめ、次回の予定
今回は、NetSuiteのマスタデータである「BOMリビジョンコンポーネント」などを一括取得できる標準ツールとして、「SuiteAnalytics ワークブック」をご紹介しました。それに加えて、「SuiteQL」を併用した、複雑なクエリの再現とデータ取の特殊ケースもご紹介しました。
次回の記事では、NetSuiteにおけるトランザクションデータである、「Costed Bill of Materials（部品表原価）」 に関する情報提供を予定しています。
参考リンク
Oracle NetSuite Help Center > SuiteQL
Oracle NetSuite Help Center > N/llm Module
NetSuite サポートコミュニティ› AI関連機能› SuiteScript 2.x 生成AI API
Qiita > サンタクロースと原価計算
© 2025 Takusuke Fujii
本記事は CC BY 4.0（原作者名の表記が必要）で自由に共有・改変・配布できますが、無保証につき著作者は一切責任を負いません。