「承認待ちを、Slackで知らせられないか」
NetSuiteが動き始めて数か月たつと、よく出てくる声です。
承認をひとつ見るためだけに、NetSuiteにログインするのは面倒だからです。
NetSuiteとチャットの連携とは、NetSuiteの出来事をSlackやChatworkに知らせ、承認などを行いやすくする仕組みです。
答えは「できる」です。
ただし、SlackやChatwork向けの標準コネクタはありません。
つなぎ方は3つあり、運用し続けられるかで選びます。
- 開発と保守の体制があるなら、SuiteScript＋Webhookの自前開発
- 連携をこれから増やすなら、iPaaS
- まず通知から小さく始めるなら、ノーコードのツール
では、最初の1つの通知は、どう作ればよいのか。
「承認待ちが24時間を超えたら知らせる」を例に、設定の順番まで追います。
この記事で分かること
- チャット連携でできること（通知と承認）
- 連携の3方式の違いと、保守の負荷
- 「承認待ち24時間超え」をSlackに知らせる設定の順番
- いまの連携を見直すときの目安
- よくある3つの失敗と避け方
チャット連携でできること
中心は「通知」と「承認」です。
通知
- 受注や発注が登録されたら、担当のチャンネルに知らせる
- 承認待ちの申請がたまったら、承認者に知らせる
- 期日を過ぎた案件を、関係者に伝える
承認
- 発注書や経費の申請を、チャット上のボタンで承認する
- NetSuiteを開かずに、外出先のスマホから判断する
承認をチャットに寄せると、待ち時間が短くなることがあります。
「在庫はいくつ？」と、AIに照会する使い方もあります。
こちらは、ClaudeやChatGPTなどのAIチャットとNetSuiteをつなぐ領域です。
NetSuiteの経営データをAIに直接聞くMCP活用ユースケースをご覧ください。
前提｜標準コネクタはない
NetSuiteには、SlackやChatwork向けの標準コネクタがありません。
つなぎ方は、次の3つです。
- SuiteScript＋Webhookで自前開発する
- iPaaSを使う
- 外部ツールやノーコードでつなぐ
言葉を補足します。
- SuiteScript：NetSuiteの動きをプログラムで広げる仕組み
- Webhook：ある出来事を、別のシステムへ自動で送る仕組み
- iPaaS：複数のクラウドサービスをつなぐ、連携の中継役のサービス
- API：システムどうしがデータをやり取りする接続口
チャット側の受け口
Slackには、Incoming Webhooksという受け口があります。
固有のURLにメッセージの内容を送ると、チャンネルに投稿されます。
Block Kitを使えば、ボタンなどの部品も載せられます。
一方で、投稿した後にメッセージを削除することはできません。
投稿先のチャンネルは、Slackアプリの設定で決まります（出典：Slack公式ドキュメント、2026年9月確認）。
Chatworkには、Chatwork APIがあります。
認証はAPIトークンとOAuth 2.0に対応し、Webhookの機能もあります。
パーソナルプラン以外では、利用に組織の管理者への申請が必要です（出典：Chatwork API公式ドキュメント、2026年9月確認）。
NetSuite側の送り口
SuiteScriptには、外部へHTTPSで送信するN/httpsモジュールがあります。
外部との通信には、平文の資格情報ではなく、TBAかOAuth 2.0を使うよう案内されています。
（出典：Oracle NetSuiteヘルプ、2026年9月確認）
iPaaSやツールがNetSuiteに接続する場合は、認証の変更に注意します。
2027.1以降、TBA（トークンベース認証）では新しい連携を作れません。
新しい連携はOAuth 2.0が前提です（出典：Oracle NetSuiteヘルプ、2026年9月確認）。
詳しくはNetSuite認証の「2027年問題」で扱っています。
標準コネクタがない構成は、NetSuiteに限った話ではありません。
考え方は、標準コネクタがない物流SaaSとの連携と共通しています。
連携の3方式を比べる
| 判断軸 | ①SuiteScript＋Webhook | ②iPaaS | ③外部ツール・ノーコード |
|---|---|---|---|
| 初期コスト | 開発の工数次第（小さく始めれば低め） | 月額の利用料が中心 | 比較的低め |
| 必要なスキル | SuiteScriptの開発 | 設定が中心、開発は最小限 | ほぼ不要（画面で設定） |
| 自由度 | 高い | 中（用意された範囲＋一部の作り込み） | 低〜中（ツールの機能の範囲） |
| 保守・運用の負荷 | 自社で保守（属人化に注意） | 提供元の更新に合わせやすい | ツール側が吸収しやすい |
| 承認など双方向の連携 | 作り込めば対応できる | 対応できる場合が多い | 通知が中心、単純な連携向き |
| 向くケース | 開発の体制があり、独自の要件が多い | 連携を続けて増やしたい | まず通知から小さく始めたい |
いちばん差が出るのは、保守・運用の負荷の行です。
連携は、作る日より、何年も動かし続けるほうが難しい。
通知の前にAIで要約し、急ぎのものだけ知らせる使い方もあります。
これを組み込みやすいのは①と②で、③はツールの機能の範囲に限られます。
iPaaSは、CeligoとはやNetSuite向けiPaaSの比較が参考になります。
例：「承認待ち24時間超え」をSlackに知らせる
①の自前開発で、最初の1つを作る場合の順番です。
画面の操作はバージョンで変わるため、決めることの順番で書きます。
手順1：対象と条件を決める
どの承認を、どの条件で知らせるかを1つに絞ります。
例は「発注書で、承認待ちが24時間を超えたもの」です。
条件が決まらないうちに作り始めると、通知が増えすぎます。
手順2：送る項目を決める
通知に載せるのは、承認者が次に動くための最小限です。
- 申請の番号と種類
- 申請者と、待っている時間
- NetSuiteの該当画面へのリンク
金額や取引先名を載せるかは、投稿先のチャンネルを見る人で決めます。
手順3：Slackの受け口を用意する
Slackアプリを作り、Incoming WebhookのURLを発行します。
投稿先のチャンネルは、アプリの設定で決まります。
承認者だけが入る非公開チャンネルにしておくと、手順2の迷いが減ります。
投稿は後から消せないため、テスト用のチャンネルで試してから切り替えます。
手順4：NetSuite側の送り口を作る
SuiteScriptで、条件に合う申請を見つけ、N/httpsモジュールでURLへ送ります。
ここでつまずきやすいのは、WebhookのURLの置き場所です。
URLは接続の情報として扱います。
スクリプトの中に直接書かず、管理者だけが触れる場所に置きます。
手順5：権限と担当を決める
処理は、権限を絞った専用のユーザーとロールで動かします。
管理者の権限のまま動かすと、見せなくてよい情報まで送れてしまいます。
設定の中身と更新の手順を文書に残し、担当は2人以上にします。
承認そのものは、最初はNetSuiteの画面へのリンクで行います。
チャットのボタンで承認まで済ませるには、押された結果をNetSuiteへ戻す仕組みも要り、作る量が増えます。
通知が回り始めてから、次の段階として考えれば足ります。
②iPaaS・③ノーコードの場合
②は、NetSuiteとチャットの間に中継サービスを置き、画面の設定でデータの流れを作ります。
よく使われる連携はテンプレートが用意されていることもあり、対応の範囲は提供元に確かめます。
③は、両方のシステムに接続し、対象を選び、項目を対応づけて通知を始めます。
ツールは、NetSuite SuiteApp.comなどで探せます。
どちらでも、手順1・2・5の決めごとは同じです。
どの方式が合うか
| 方式 | 向いている会社 | 向いていない会社 |
|---|---|---|
| ①自前開発 | SuiteScriptを保守できる人が2人以上いる | 詳しい人が1人だけ |
| ②iPaaS | チャット以外の連携も増やす予定がある | 通知1つだけのために月額を払いたくない |
| ③ノーコード | 通知を1〜2種類、すぐに試したい | 承認の双方向や複雑な条件が要る |
連携しなくてよい場合もあります。
承認が1日に数件なら、NetSuiteの画面とメールの通知で足りることがあります。
誰が・いつ・何を承認するかが決まっていないなら、チャットより先に承認の設計です。
こちらはNetSuiteの承認ワークフロー実装ガイドで扱っています。
すでに連携を使っている会社の見直しの目安
次のどれかに当てはまるなら、見直しの時期です。
- 通知が多すぎて、チャンネルが読まれていない
- 作った人が異動し、設定の中身が分からない
- 連携がTBAやパスワードで接続している
まず、いまの通知を一覧にし、誰も行動しない通知を止めます。
接続は、2027.1の認証の変更に合わせて、OAuth 2.0への切り替えを計画します。
よくある3つの失敗
失敗1：通知を盛り込みすぎて、誰も見なくなる
起きること：すべての更新を通知にし、チャンネルが埋まる。重要な通知が埋もれ、やがて誰も開かない。
原因：通知は多いほど親切だと考えた。
避け方：通知は行動が要るものだけに絞ります。
承認待ち・例外・期日の超過などです。
効果の高い1つから始め、育てていきます。
失敗2：個人が作った連携がブラックボックスになる
起きること：詳しい1人が作り、記録がない。その人が異動すると誰も触れず、ある日突然止まる。
原因：連携は一度動くと手がかからず、記録と引き継ぎが後回しになる。
避け方：設定の中身・権限・更新の手順を文書に残し、担当を2人以上にします。
属人化の考え方は、属人化とはで扱っています。
失敗3：権限の設計が甘く、情報が広がりすぎる
起きること：管理者の権限のまま連携し、公開のチャンネルに金額や取引先名が流れる。
原因：チャットは情報が広がりやすい場なのに、誰に何を見せるかを決めていなかった。
避け方：権限を絞った専用のユーザーとロールで接続します。
接続はOAuth 2.0などのトークンを使う方式にし、パスワードを渡しません。
ロールの考え方は、NetSuiteの権限・ロール設計で扱っています。
ベンチャーネットならこう見る｜標準で足りるか、作るか、いまのままか
NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、方式の比較から入りません。
最初に、知らせたい承認を1つずつ、3つに仕分けます。
- 標準に合わせる：NetSuiteの画面とメールの通知で足りる。承認が少なく、いまの形で回っている
- 作る：待ち時間が長く、件数も多い。SuiteScript・iPaaS・ノーコードのどれかでチャットにつなぐ
- いまのまま残す：承認のルールがまだ決まっていない。連携より先に業務の設計をする
「作る」に入った承認だけに、手間とお金をかけます。
「連携しなくてよい」とお伝えすることも、珍しくありません。
チャット連携は、NetSuiteの外にあるSlackやChatworkとの連携です。
ベンチャーネットの仕事は、ゼロからの導入より、他社のあとの引き継ぎや他システムとの連携が多くを占めます。
作った人がいなくなった通知の中身を読み解き、動かし続けられる形に直す依頼もあります。
最初に伺うのは、次の3つです。
- どの承認が、どれだけ待たされているか
- 誰に何を見せてよいか（金額・取引先名の扱い）
- 誰が保守するか
今日できること｜承認の待ち時間を1つ測る
最近の承認を1種類選び、次の表を埋めてみてください。
| 項目 | 記入例 |
|---|---|
| 承認の種類 | 例：発注書 |
| 1か月の件数 | 例：120件 |
| 申請から承認までの平均 | 例：2日 |
| 承認者が気づくきっかけ | 例：NetSuiteを開いたとき |
| チャットで知らせたい相手 | 例：部門長2人 |
例の数字は、いずれも架空です。
待ち時間が長く、件数が多い承認ほど、通知の効果は大きくなります。
この承認が、第4章の手順1の「対象」になります。
よくある質問
Q1. NetSuiteにSlack・Chatworkの標準コネクタはありますか
専用の標準コネクタはありません。
SuiteScript＋Webhook、iPaaS、ノーコードのツールなどでつなぐのが一般的です。
どの方式で組むかは、保守を続けられるかで決めます。
Q2. プログラミングなしで連携できますか
通知であればノーコードのツールやiPaaSで始められます。
画面の設定だけで通知を始められる場合があります。
複雑な条件や承認の双方向の連携には、自前開発が向くこともあります。
Q3. チャット上のボタンで承認まで完結できますか
作り込めば可能ですが通知だけより作る量が増えます。
Slackのメッセージにはボタンを載せられますが、押された結果をNetSuiteへ戻す仕組みも要ります。
最初は通知とNetSuiteの画面へのリンクで始めるのが現実的です。
Q4. セキュリティや権限の管理は大丈夫ですか
設計しだいで安全に運用できます。
権限を絞った専用のユーザーで接続し、トークンを使う認証にします。
金額などの通知は、非公開チャンネルに限ります。
Q5. 「見るだけ・承認だけ」の人のライセンスは減らせますか
Oracleとの契約の条件によるため事前の確認が要ります。
チャット経由で承認や確認を行う人に、NetSuiteのライセンスが要るかは契約の内容で変わります。
連携を設計する前に、Oracleのアカウントの担当に聞いてください。
Q6. 2027.1の認証の変更は、チャット連携に関係しますか
iPaaSやツールがNetSuiteに接続する場合は関係します。
2027.1以降、TBAで新しい連携は作れず、OAuth 2.0が前提になります。
使っているツールの対応状況を、提供元に確かめてください。
まとめ
- NetSuiteとSlack・Chatworkの標準コネクタはない
- 方式は自前開発・iPaaS・ノーコードの3つ。保守の負荷まで含めて比べる
- 最初は「承認待ち24時間超え」のような行動が要る通知を1つ。承認は画面へのリンクで
- WebhookのURLと接続のユーザーは、管理者だけが触れる形にする
- 承認を「標準に合わせる／作る／いまのまま残す」に仕分けてから方式を選ぶ
「承認待ちを、Slackで知らせられないか」。
答えは、測った待ち時間の長い承認を1つ選ぶところから始まります。
もう少し詳しく知りたい方へ
チャット連携や、その先の承認の設計について、自社に合う進め方をご相談いただけます。
通知の絞り込みから、開発・導入後の保守までご一緒します。
