NetSuiteのワークフローエディタや保存検索を使っていて、こんなふうに感じたことはないでしょうか。
状態とアクションが画面いっぱいに並び、アクションの追加変更時はひとつずつマウスとキーボードでカチャカチャしないと直せないワークフロー。Formula(Numeric)に長い式を書いて結果が合わない保存検索。「もっといい方法はないのか」と思っても、たいていの場合、選択肢はもう一つしか思いつきません。「もっと我慢して使い方を覚える、慣れる」――これだけです。
でも、実はもう一つ選択肢があります。コードを書く、です。
「いやいや、コードなんて書けないし、書ける人なんて社内にいないし」――そう思った方にこそ、この記事を読んでほしいと思います。私自身、普段はSuiteScriptを書く側の人間ですが、最近はClaude CodeというAIツールのおかげで、「コードを書く」が以前とはまるで違う行為になりました。日本語で要件を伝えるだけで、動くSuiteScriptが手に入る。これは、SuiteScriptを書いたことがない人にとっても、十分に手の届く選択肢になっているということです。
ためしに、ワークフローで作ろうとしたら1ヶ月はかかりそうな複雑な承認フローを、Claude Codeに書かせてみました。できあがるまで、約2時間。 しかも、できあがったコードの品質は、ワークフローで作るより明らかに高いものでした。
ノーコードツールに苦しんでいるなら、コードという選択肢を一度検討してみる価値があります。この記事では、その第一歩を一緒に考えてみたいと思います。
ノーコードツールが、ノーコードのくせに難しい理由
「コードを書けない人でもカンタンに処理が作れるツール」――それがGUIツールの建前です。でもNetSuiteのGUIツール群は、その建前と現実のあいだに、かなりの距離があります。
ワークフローエディタを思い浮かべてみてください。新しいアクションを追加するには、まず「Add Action」ボタンを押す。アクションの種類を選ぶ画面が開く。種類を選ぶ。条件タブに移る。条件式を組む。フィールドを選ぶ。そのフィールド選択画面で、100を超えるフィールドリストがずらっと出てくる。キャラクターコード順に並ぶのでフィールド名が漢字だとどの順で並んでいるのか皆目見当もつかないうえ、検索機能や分類などされていないから、出したいフィールド名をブラウザ検索(ctrl+F)で探すしかない。出したいフィールド名がわかっていないとできない所業です。 加えて、このフィールド名が画面に表記されている名前と必ずしも一致していないという恐怖。英語版を機械的に日本語に翻訳している障害が随所に現れているUIというそしりは免れない――そういうレベルです。同じ名前のフィールドが二つ並んでいて、片方が正解、片方が不正解。どちらが正しいかはヘルプにも書いていない。フィールドの説明もない。
これだけの操作を、一つのアクションを作るだけで繰り返します。アクションが10個あれば、この操作を10回繰り返すわけです。途中でマウスをミスって条件が消えても、Ctrl+Zは効きません。「保存しない」で閉じれば確かに戻せますが、その間に正しく追加した他の変更も全部消えます。
そして、テストの段階で、また時間が溶けます。
ワークフローを保存して、テスト用のレコードを作って、保存ボタンを押して、想定通りに動かないと気づいて、ワークフローエディタに戻って、原因を探す。条件式の入力欄は小さくて、長い式は途中で見切れる。エラーメッセージは「Validation failed」のような、何の役にも立たない一文だけ。仕方なくフィールドIDを目視で確認する。同名フィールドのどっちを選んだのか思い出せない。最初からやり直す。
これを一日中やっていられる人は、現実にはいません。NetSuiteの保守担当者の方は、たいてい他の業務と兼任していると思います。問い合わせ対応もあれば、月次の処理もあれば、別件の打ち合わせもある。ワークフローの作業を一度中断して、翌日また開いたとき、「自分が昨日どこまで何をやっていたか」を思い出すところから始まるわけです。これが本当に時間を食います。
GUIツールは、「マウスで操作するから簡単」という顔をしています。でも実態は、画面の中の小さな入力欄を、何百回もクリックして、何百回も選択肢を選んで、何百回もスクロールする作業です。マウスが楽なのは、操作の数が少ないときだけです。複雑なロジックになった瞬間、マウス操作の物量がボトルネックになります。
加えて、NetSuiteのGUIツール群には共通の特徴があります。画面上にヘルプがない。フィールドの説明もない。直感的な操作はできない。 使いやすさを改善するアップデートは、ほぼ行われていません。少なくとも私が触れている6年の間、同じ画面のままです。新しい機能はほぼ全部「新しいスクリプトAPI」や「新しいSuiteApp」として追加されていて、既存のGUIツールは置き去りにされてきました。
つまり、NetSuiteのノーコードツールは「コードを書かないかわりに、独自のUIの作法を覚える」ことを要求してきます。条件式の独自記法、画面遷移の手順、フィールド選択の罠、エラーメッセージの解読――これらは全部、NetSuiteのワークフロー専用の知識です。他のどこにも応用が効きません。 SuiteScriptなら、覚えた知識はJavaScriptの知識として一生使えます。学習コストの「リターン」が違いすぎるんです。
別の角度から見ると、NetSuiteのノーコードツールは、一日中NetSuiteを操作していて慣れていないと使えない、ということです。これは開発者やベンダー側から見た立場の見方なんですが、実際にNetSuiteを使っている利用者の方は、そうではありません。
NetSuiteは、自社の業務を円滑に進めるための単なるツールの一つです。もっとわかりやすく言うと、NetSuiteのことをいくら鍛錬したところで、自社の売上は上がりません。 そりゃそうです。そんなことをしているより、自社の商品力を高めたり、有力なチャネルを見つけ出したりするのが、本来の事業ミッションのはずです。
ひなが一日NetSuiteを触っている人間の感覚で「ツールを使え」と言われてできるわけがない――NetSuiteのGUIツールが利用者にとって苦痛になっているのは、ここが根本的な原因だと思います。
「コードは怖い」という感覚は、本当はもう少し正確に言い直せます。「未知のものは怖い」――これだけです。ワークフローも最初は未知だったはずです。慣れたから今は怖くないだけ。SuiteScriptも同じで、最初の一歩を踏み出してしまえば、そんなに違うものではありません。しかも、その最初の一歩を、Claude Codeがほぼ全部代わりにやってくれます。
もう一つ、「コードが怖い」と感じる理由があります。アルファベットで書かれていることです。
厳密には英語ではありません(if、for、returnくらいで、あとは独自の単語の塊です)。でも、アルファベットがずらっと並んでいるだけで、日本語ネイティブには「自分には縁がない世界の話」に見えます。これは生理的な反応に近いので、自分を責める必要はありません。
ただ、こればかりは仕方ないんです。プログラミング言語の主流はアメリカで作られたものが普及したので、そこは受け入れるしかありません。ここだけ諦めましょう。 TRON(日本発のOS)がもっと普及していれば、とか、あの時日本政府がちゃんとバックアップしていれば、とか、レバタラの話をしてもしょうがない。
救いは、SuiteScriptで使う「アルファベット」は、思ったほど多くないということです。if(もし)、for(繰り返し)、return(返す)、record(レコード)、search(検索) ――よく出てくるのはこれくらいです。NetSuiteの管理画面で見慣れた単語が、コードの中でもそのまま登場します。「Sales Order(受注)」「Customer(顧客)」――こういう言葉、もう毎日見ているはずです。
しかも、Claude Codeを使うなら、そのアルファベットの単語を自分で書く必要すらありません。日本語で「受注の保存時に」「ステータスを下書きに戻して」と伝えれば、Claudeがアルファベットの方は全部書いてくれます。読めれば十分。書けなくていい。これだけで、心理的な距離はぐっと縮まります。
逆転の発想：コードの方が「やさしい」5つの理由
ここから先、ちょっとびっくりするかもしれない話をします。
「コードを書く」と言うと身構えてしまうかもしれませんが、SuiteScriptを書く側の人間として正直に言うと、コードはワークフローよりもむしろ扱いやすいんです。「ノーコードの方が簡単だから初心者向け」というのは、少なくともNetSuiteに関しては、もう成り立たない前提だと思います。
理由を5つ挙げてみます。
1. Ctrl+Zで戻せる
これが一番大きいです。
ワークフローエディタは、画面で操作した瞬間に状態が変わっていきます。マウスを誤って条件を消してしまっても、エディタ画面のCtrl+Zは効きません。「保存せずに閉じる」という回避策はありますが、それまでに加えた他の正しい変更も全部消えます。
コードはただのテキストファイルです。エディタで開いて編集するだけ。間違えたらCtrl+Zで戻せる。違う方向に修正してしまったら、Ctrl+Zを連打すれば、やり直す前の状態にいつでも戻れます。「壊しても戻せる」という安心感は、作業のストレスを根こそぎ取り除いてくれます。
2. 履歴がそのまま残る
コードはGit（バージョン管理ツール）で履歴を残せます。「3日前の状態」「1週間前の状態」に、何度でも戻れます。誰が、いつ、どこを変えたかも記録されます。
ワークフローには、これがありません。「先週は動いていたのに、今週は動かない」という現象が起きたとき、何が変わったのかを追う手段はほとんどありません。誰かが触ったのか、触っていないのか、それすらわからない。コードなら、変更前後の差分が一行単位で全部残ります。
3. 何をしているか日本語で読める
ワークフローのアクション一覧画面を、半年前に組んだものを久しぶりに開いてみると、何をしているか即座に思い出せるでしょうか。アクションの名前と種類だけが並んでいて、なぜこれを作ったかは、画面に書かれていません。
コードには「コメント」という機能があります。コードの隣に日本語で「ここで承認者を決めている」「金額が10万円以上のときの分岐」と書いておけます。書きながら自分のためにメモを残せるわけです。半年後に読み返したとき、「あ、こういうことをやろうとしていたのか」とすぐ理解できます。
これ、ワークフローではどうやってもできない芸当です。
4. AIに「これ何してるの？」と聞ける
ベンダーから受け取ったSuiteScript、過去に作られたワークフロー、別の担当者が組んだロジック――「これ、何のためにこうなってるんだろう？」と思う場面は、NetSuiteを長く触っていれば必ず出てきます。
コードなら、ファイルをそのままClaude Codeに渡して「このコード、何をしているか教えて」と日本語で聞けます。Claudeは数秒で「このスクリプトは、受注レコードの保存時に〜の処理をしています」と説明してくれます。読むだけでなく、解説してもらえるんです。
ワークフローではこれができません。画面を見ながら、自力で挙動を読み解くしかありません。
5. 同じものを使い回せる
一度書いたコードは、別のレコードや別の処理に流用できます。Claude Codeに「このスクリプトを、受注レコードじゃなくて見積レコード用に書き直して」と頼めば、5秒で別バージョンができます。ロジックは同じで対象だけ違う、というケースは現場にいくらでもあります。
ワークフローのコピー機能はありますが、コピーしたあとにフィールドの参照先を全部手で直す必要があります。同じ作業の繰り返しです。コードなら、書き換えはClaude任せ、自分は動作確認だけ。
5つ並べてみると、共通項が見えてきます。コードは「人間にやさしいインターフェース」を持っているんです。戻せる、履歴が残る、読める、聞ける、流用できる。これらは全部、人間が間違えることを前提にしたしくみです。
一方でワークフローは、「人間が間違えない前提」のインターフェースになっています。一発で正しい操作をして、一発で正しい設定をすることが暗黙に要求されている。間違えたときの救済策がほとんど用意されていません。
ノーコードという言葉のイメージから、「コード=難しい・ノーコード=簡単」と思いがちですが、実態はむしろ逆です。コードは間違えても許してくれる。ノーコードは一発勝負です。
これが、コードを書く側の人間がワークフローエディタを開くたびにげんなりする理由でもあります。「もっと簡単なはずのツールが、もっと面倒なことになっている」――この感覚です。
やってみた：複雑な承認フローが、1ヶ月から2時間に
理屈の話はここまでにして、実際に何が起きたかを書きます。
ある日、こんな要件を扱う機会がありました。「経費申請の承認フローを見直したい。金額に応じて承認者が変わって、却下されたら状態が戻って、最終承認後は別レコードに連携してほしい」。
要件としては、それほど珍しいものではありません。NetSuiteを業務で使っている会社なら、似た要件はどこにでもあります。「複雑だけど、別に難しくはない」――そういう種類の仕事です。
もしワークフローで作ったらどうなるか
もしこの要件をワークフローで作るとしたら、なかなか手強い仕事になります。私は実際にはこれをClaude Codeで作ってしまいましたが、ワークフローで作っていたらどうなっていたか、現実的なシナリオを書いてみます。
状態を10個ほど用意して、それぞれの状態にアクションを並べて、条件式を書いて、フィールドを選んで、保存して、テストする。一つの状態を作り終わる頃には、おそらく30分は経つでしょう。
これを10個分やります。だいたい一日仕事です。
しかも、そんなに集中して作業できる日は、現実にはなかなかありません。問い合わせ対応が入る、別の会議がある、月次の処理がある。少しずつ、少しずつ、組み立てていきます。
そして、テスト段階でまた時間が溶けます。テスト用の経費申請レコードを作って、保存して、ステータスを変えて、想定通りに動かないと気づいて、ワークフローエディタに戻って、原因を探す。条件式の入力欄は小さくて見づらい。フィールドIDの選び方を間違えていたことに気づくのに30分。直して保存して、また別のところが動かない。
この調子で、構想・実装・テスト・修正を繰り返していると、一つの承認フローを完成させるのに本当に1ヶ月くらいはかかります。 これは大袈裟に言っているのではなく、同様の規模のワークフロー設計を見積もった感覚からの、現実的な数字です。
そもそもClaude Codeって何？
ここで一度、Claude Codeが何なのかを整理させてください。「ChatGPTみたいなものでしょ？」と思われがちですが、いくつか大事な違いがあります。
まず、Claude（クロード）というAIアシスタントがAnthropic社から提供されています。ブラウザで使うClaude.aiのチャット画面を触ったことがある方もいるかもしれません。これはChatGPTやGeminiと同じ系統の、対話形式のAIです。
これに対して、Claude Codeは同じClaudeをベースにしたターミナル（コマンドラインツール）で動く開発専用ツールです。何が違うかというと：
- 自分のPC内のファイルを直接読める（チャット版だとコピペが必要）
- 複数のファイルにまたがる処理ができる
- コードを書きながら、その場で実行・テストできる
- 会話履歴がプロジェクト単位で保持される
ざっくり言うと、Claude.aiが「チャットでAIに質問する」体験だとすると、Claude Codeは「自分の隣に座ってもらって、一緒にコードを書く」体験です。SuiteScriptのような業務ロジックを伴う開発では、後者の方が圧倒的に向いています。
そして、Claude Codeは有料プラン限定です。Claude.aiのチャット版は無料でも使えますが、Claude Codeは月額20ドルのClaude Pro以上の契約が必要になります（2026年4月現在）。
「月20ドルか、ちょっと高いな」と感じるかもしれません。でも、ワークフロー1個に1ヶ月かかる工数のことを思えば、明らかに元は取れます。仕事の道具を1つ買うレベルの投資です。Adobe IllustratorやMicrosoft Office 365を契約するのと同じ感覚と言えます。
ちなみに、もっと重い使い方をする人向けにClaude Max（$100/月、$200/月）というプランもありますが、最初はProで十分です。私自身も最初はProから始めました。
なぜChatGPTやGeminiではなくClaude Codeなのか
ここで先に正直なことを書いておくと、私は別にAnthropicの回し者ではありません。むしろ最初に使ったのは、ChatGPTとGeminiの方でした。Claudeの存在は知らなかったくらいです。
ChatGPTもGeminiも、コードを書く能力自体は確かにあります。SuiteScriptみたいな業務ロジックでも、依頼すれば動くコードは出てくる。人間が手で書けば1〜2週間は確実にかかる規模のスクリプトを、3〜4時間で形にすることはできていました。 その意味では、ちゃんと「使えるツール」ではあったんです。
問題はその、3〜4時間の中身でした。
依頼するとプログラムは作ってくれる。でも、どこに落とし穴があるかわからない。「ここの分岐を直して」と頼むと、頼んだ箇所は直る。でも、頼んでいない別の場所が、いつの間にか壊れている。 これを「デグレード」と言いますが、ChatGPTもGeminiも（Geminiの方がいくらかマシでしたが）、これが頻発するんです。
だから、毎回プロンプトに「他の箇所は変更しないでください」「既存の動作を壊さないでください」という但し書きを入れる。それでも壊れるので、生成されたコードを受け取ったら、毎回前のバージョンとdiff（差分）を取って、変更されたのは依頼した箇所だけかを目視で確認する。少しでも余計な変更があれば、「ここは元に戻して」とまた指示する。それでまた別の場所が壊れる。
開発時間そのものは短いんです。でも、その3〜4時間は警戒と確認の連続で、終わるとぐったりします。 一日の中で1本作ったら、もうその日は他のことをやる気力が残っていません。これを毎日連続でやっていくのは、人間の方が先に持ちません。「ツールとしては使えるんだけど、長期的に運用できる気がしない」――そう感じながら、半ば諦めかけていた頃に出会ったのがClaudeでした。
何が決定的に違ったかというと、この警戒と確認のループから解放されたんです。会話が長くなっても、複雑なロジックでも、こちらが指示した部分だけが正確に直る。他の部分は壊さずに残してくれる。「ここを直して」と言って、本当にそこだけが直っている、という当たり前のことが、当たり前に起きる。
これは試してみないと信じられないと思いますが、本当に、目に見えて違います。「diff確認して、また指示し直す」という心理的負担がなくなるだけで、一日に開発できる量が劇的に変わりました。承認フローを2時間で完成できたのは、コードを書くスピードが速いからではなく、書いた後の検証コストが圧倒的に低いからです。
だから、この記事でClaude Codeを推しているのは、ステマでもなんでもなくて、実際に複数のAIを比較した結果、コード生成に関しては今のところClaudeが頭一つ抜けている、というのが率直な実感です。半年後、1年後にはまた状況が変わるかもしれません。でも、少なくとも今この記事を書いている時点では、SuiteScriptを書かせるならClaude Codeが第一選択です、と自信を持って言えます。
Claude Codeに頼んでみた
そんなわけで、この承認フローもClaude Codeに頼んでみました。長くもない、こんな指示です。
経費申請レコードのUserEventを書いてください。SuiteScript 2.1で。 - 申請金額が10万円未満なら、承認者は直属の上司 - 10万円以上50万円未満なら、部長 - 50万円以上なら、本部長 - 却下されたら、ステータスを「下書き」に戻す - 最終承認されたら、経費精算レコードを自動生成
これを送って、待つこと数十秒。動くコードが返ってきました。
検証環境にデプロイしてテストしてみると、想定通り動きました。完璧ではない部分が一つだけあって、承認者の取得ロジックに少し違和感があったので、「直属の上司は、申請者のレコードのsupervisorフィールドから取ってください」と追加で日本語で指示しました。すぐに修正版が返ってきました。これで動きました。
ここまで、開始から2時間。
数字で振り返ると
| ワークフロー版（仮定） | Claude Code版（実測） | |
|---|---|---|
| 構想・設計 | 数日（割り込みの合間に少しずつ） | 5分（要件を箇条書きにまとめるだけ） |
| 実装 | 1〜2週間 | 数十秒（Claudeが書く） |
| テスト・修正 | 1〜2週間 | 1時間半（実機で動かして調整） |
| 合計 | 約1ヶ月 | 約2時間 |
そして、できあがったものの品質も、Claude Code版の方が高い結果になりました。
ワークフロー版だと、後から見直したときに「なんでここがこうなってるんだっけ？」と思い出せない箇所がいくつも出てきます。Claude Code版なら、コードに日本語のコメントが入っているので、半年後に開いても何をしているか即座に読めます。修正したい箇所があれば、Claudeに「この部分を、〜に変えてほしい」と言うだけで直せます。
「ここまでして、ワークフローエディタを使いたいですか？」――これが、自分でやってみた率直な感想です。
最初の一歩：本番を壊さずに試す環境を作る
ここまで読んでくれた方は、たぶん「試してみてもいいかな」という気持ちが少し出てきているんじゃないでしょうか。
ただ、最初の一歩には、必ず「壊したらどうしよう」という不安がついてきます。本番環境で何かが起きたら、関係各所への謝罪と原状復帰で半日潰れます。それは絶対に避けたい。
その不安は、検証用の環境を用意すれば解消できます。NetSuiteには、本番とは別の環境がいくつか用意されています。ただし、用意のされ方は会社の契約状況によって異なるので、まずは自分の状況を確認するところから始まります。
Sandboxが使えるかを、まず確認する
NetSuiteにはSandbox（サンドボックス）という、本番とは別の検証用環境があります。本番のデータが定期的にコピーされていて、見た目も触り心地も本番そっくり。でも、そこで何をやっても本番環境には一切影響しません。
ただ、Sandboxは標準機能ではなく、追加契約が必要な有料オプションです。決して安くない金額がかかるので、契約していない会社も多くあります。
「うちの会社、Sandboxあったっけ？」とピンとこない方は、まずNetSuiteの管理者か、契約担当の方に確認してみてください。すでに契約していれば、ログイン情報を出してもらえるはずです。
会社が既にSandboxを契約しているなら、これが一番です。本番データを使った現実的な検証ができますし、最終的に本番にデプロイする前提なら、どのみちSandboxでの動作確認が必要になります。
Sandboxがない場合は
会社がSandboxを契約していない場合、いくつか選択肢があります。
ひとつは、Development Account（開発アカウント）という別種の環境です。Sandboxとは違って本番データのコピーは入りませんが、SuiteScriptの動作確認には十分な環境です。ただし、これも自動でついてくるものではなく、取得にはNetSuiteのアカウント担当者への問い合わせが必要です。費用や条件は契約内容によって変わるため、興味があれば担当者に確認してみてください。
もうひとつは、会社にSandboxの追加契約を提案するという王道のアプローチです。「Claude Codeで開発効率が劇的に上がる、ただし安全に試す環境が必要」という具体的な根拠を持って話せば、無下にされる話ではありません。むしろ、Claude Codeで作ったコードを安全に検証する環境がない方が、長期的にはリスクです。この記事の内容そのものが、社内提案の材料として使えるはずです。
「試したいけど、すぐには検証環境が用意できない」という方は、この記事をブックマークしておいて、環境が整ってから戻ってきてもらえればと思います。残念ながら、本番環境でいきなりClaude Codeに書かせたコードを動かすことだけは、絶対におすすめできません。
Claude Codeの導入は5分で終わる
検証環境のあてがついたら、次はClaude Codeを自分のPCに入れます。導入手順そのものは公式ドキュメントが一番正確で最新なので、ここでは細かいコマンドを書きません。代わりに、全体の流れだけお伝えします。
- Claude Pro以上のアカウントを契約する（月額20ドルから）
- Claude Codeを自分のPCにインストールする（Mac/Linux/Windows対応、所要時間5分程度）
- 適当なフォルダを作って、その中で
claudeと打つ（これでClaude Codeが起動する） - 日本語で「こういうSuiteScriptを書いて」と話しかける
それだけです。本当に、それだけ。
導入の詳細手順は、Anthropicの公式ドキュメント（https://docs.claude.com/en/docs/claude-code）が常に最新です。OSや環境によって少し手順が変わるので、自分の環境に合った最新情報をそちらで確認してください。この記事を読みながら実機で進めたい方は、別タブで公式ドキュメントを開きながら読むのがおすすめです。
最初の動作確認は「Hello World」で
インストールが終わったら、いきなり承認フローに挑戦するのではなく、ちょっとしたお試しから始めるのがおすすめです。
例えば、こんな指示で十分です。
SuiteScript 2.1で、UserEventScriptを書いてください。 顧客レコードが保存されたとき、ログに「保存されました」と出すだけのスクリプトでお願いします。
これをClaude Codeに渡すと、数十秒で動くコードが返ってきます。コードを検証環境にアップして、デプロイして、顧客レコードを保存してみる。NetSuiteのスクリプトログに「保存されました」と表示されたら、成功です。
たったこれだけのことですが、「自分のPCで書いたコードが、NetSuiteの中で実際に動いた」という体験は、思っている以上に大きいです。ここまで来ると、後はもう自分の手でいろいろ試したくなってきます。
何かが詰まったら
最初の一歩で、何かが上手くいかないことは普通にあります。Node.jsのバージョンが古い、認証画面でつまずく、コードのアップロード方法がわからない――こうした「最初の壁」は、誰もが通る道です。
そんなときも、詰まった内容をそのままClaude Codeに伝えれば、たいていは解決方法を返してくれます。「claude --versionを打ったら『command not found』と出る」と日本語で書けば、原因と対処法を順番に教えてくれます。
ググって英語のフォーラムを読み込む必要は、もうありません。詰まった瞬間に、その場で日本語で聞ける――これもClaude Codeを使う大きな利点です。
最初のコツ：Claudeへの「最初の一文」に入れる3つの呪文
検証環境とClaude Codeが揃ったら、いよいよ最初の依頼です。
ここで一つ、知っておくと最初の体験が大きく変わるコツがあります。Claudeへの最初の指示に、必ず3つの情報を入れる――これだけです。難しい話ではありません。慣れれば数秒で書けます。
呪文1：「SuiteScript 2.1で」
NetSuiteのSuiteScriptには、バージョンの違いがあります。古い1.0、現行の2.0、そして最新の2.1。書き方も使えるAPIも違います。
これを伝えないと、Claudeは時々2.0の書き方で返してくることがあります。動かないわけではないんですが、せっかく書くなら最新の2.1で揃えておきたい。「SuiteScript 2.1で書いてください」と最初に書くだけで、これが解決します。
呪文2：「スクリプトタイプは○○です」
SuiteScriptには「いつ動くか」を決めるスクリプトタイプという種類があります。レコード保存時に動くUserEvent、画面操作時に動くClient Script、定時実行のScheduled Script、大量データ処理のMap/Reduce、独自URLを持つSuitelet――いくつかあります。
「何のスクリプトを書きたいか」をClaudeに伝えないと、こちらの意図と違う種類で書かれることがあります。たとえば「保存時に動かしたい」なら「UserEventScriptで」、「ボタンを押したら動かしたい」なら「Suiteletで」、と最初に書きます。
「どれを使えばいいかわからない」という場合は、それも正直に書けば大丈夫です。「保存時に動かしたいのですが、どのスクリプトタイプが適切ですか？」と聞けば、Claudeが用途を聞き返してくれて、適切なものを提案してくれます。最初から正解を選ばなくていい、というのは大きな安心です。
呪文3：「対象レコードは○○です」
NetSuiteには標準レコード（顧客・受注・請求書など）に加えて、各社で作ったカスタムレコードがあります。Claudeに「どのレコードに対する処理か」を伝えておかないと、汎用的すぎる（=現場で使いづらい）コードになりがちです。
「対象レコードは受注（salesorder）です」のように、内部IDも一緒に書いておくとさらに精度が上がります。内部IDがわからなければ、レコード名だけでも十分です。「受注レコードに対するUserEventで」と書けば、Claudeはちゃんとrecord.Type.SALES_ORDERを使ったコードを書いてくれます。
3つを組み合わせると、こんな感じ
セクション3で例に出したプロンプトを、もう一度見てみてください。
経費申請レコードのUserEventを書いてください。SuiteScript 2.1で。
この一文の中に、3つの呪文が全部入っています。
- 「SuiteScript 2.1で」（呪文1：バージョン）
- 「UserEventを書いてください」（呪文2：スクリプトタイプ）
- 「経費申請レコードの」（呪文3：対象レコード）
たったこれだけで、Claudeが返してくるコードの精度が一段上がります。逆に、この3つが揃っていない曖昧な指示を出すと、的外れなコードが返ってきて、その修正に時間を使うことになります。最初の一文を丁寧に書くだけで、後の作業時間が大幅に短くなる――これが、AIに開発を任せるときの最大のコツです。
もう一段先に進みたい人へ
慣れてきたら、これに加えて以下の情報も最初に伝えると、さらに使いやすいコードが返ってきます。
- 会社のコーディングルール（命名規則、コメントの書き方、ログの出力形式など）
- 既存のスクリプトの構造（共通モジュール、エラーハンドリングのパターンなど）
- NetSuiteのアカウント環境（マルチサブシディアリ、マルチカレンシー、機能の有無など）
このあたりは、毎回プロンプトに書くのは大変なので、Claude Codeの「CLAUDE.md」というファイルにまとめて置いておく方法があります。これを使うと、Claudeが毎回自動でその内容を読んでからコードを書いてくれるようになります。
ただ、これは最初の一歩としては少し進んだ話なので、慣れてからで全然大丈夫です。まずは3つの呪文だけ覚えて、最初の動作確認をしてみてください。CLAUDE.mdとSuiteCloud SDKを使ったClaude Codeからのデプロイ自動化については、すでに別の記事で詳しく書きました。慣れてきたらこちらも参考にしてみてください。
まとめ：「ワークフロー画面に戻りたくない」が、一番の感想だった
長い記事になりました。ここまで読んでくれて、ありがとうございます。
最後にひとつだけ、Claude Codeを使うようになってからの一番の感想をお伝えしたいと思います。それは、「もうワークフロー画面に戻りたくない」という、地味だけど切実な気持ちです。
ワークフローエディタで作業しているときの、あの独特の重さ――マウスをミスらないように指先に神経を使い、フィールドリストの中から正解を探し、保存するときに少し緊張する、あの感じ。Claude Codeでスクリプトを書くようになってから、あの重さがすっぽり抜けました。「直すのが楽しい」とまでは言いませんが、少なくとも『直すのが憂鬱』ではなくなったんです。これは、毎日NetSuiteに向き合う仕事をしている人間にとって、思っている以上に大きな違いです。
完璧じゃない、けど十分使える
念のため正直に書いておくと、Claude Codeも完璧ではありません。たまに変なコードを書いてくることもあるし、こちらの指示が曖昧だと変な解釈をすることもある。「全部AIに丸投げして人間は何もしなくていい」みたいな世界ではまだないです。
でも、これまで「コードを書ける人」しかできなかったことが、「日本語で要件を伝えられる人」ならできるようになった――この変化は、本当に大きいと思います。NetSuiteの保守運用に関わる人にとって、これは数年に一度レベルの環境変化です。
まずは小さく試してほしい
この記事を読み終えたあと、いきなり業務で使う必要はありません。
まずは、検証環境でHello World的なスクリプトを1本書いてみる。それだけでいいです。「自分のPCで書いたコードが、NetSuiteの中で動いた」という体験を、まず一度してみてください。たぶん、その瞬間、世界の見え方が少し変わります。
そこから先のことは、必要になったときに考えればいい。承認フローを書きたくなったら書けばいいし、書きたくなかったらワークフローのままでもいい。自分の手の届く範囲が広がっている、という感覚さえあれば、もう十分に前進です。
次に書く予定のこと
この記事ではClaude Codeを始めるところまでをお伝えしましたが、実際に使い込んでいくと、もう少し踏み込んだ話題が必要になってきます。たとえば：
- CLAUDE.mdの書き方（自分の現場のルールをClaudeに覚えさせる方法）
- スクリプトタイプの使い分け（UserEvent / Scheduled / Map/Reduce / Suiteletの選び方）
- 大規模開発をAIで進めるときの管理ノウハウ（120ファイル規模の開発で得た知見）
このあたりは、これからこのブログで少しずつ書いていく予定です。よかったら、また覗きにきてください。
それから、もしこの記事の内容で「実際に試してみた」「ここでつまずいた」「こんなふうに使ってみた」というのがあれば、ぜひ教えてもらえると嬉しいです。みんなで知見を持ち寄ったほうが、一人で試行錯誤するより早い――これも、今のNetSuite界隈に足りていないものだと思っています。
ワークフロー画面のあの重さから、抜け出してみる選択肢があります。コードという選択肢、一度試してみませんか。
