2026.1のリリースノートを読んで、「量が多くてどこを見ればいいかわからん」となった方向けに整理しました。 全部は書きません。「これは実務に効く」と判断したものだけ取り上げます。
セクション1：結論を先に言う
2026.1は「派手な新機能より、じわじわ効く改善が多い」リリースだな、という感想です。
正直なところ、「これを使えばERPが劇的に変わる」という目玉機能はありません。そのかわり、「なんで今まで対応してなかったの」という地味な穴を複数埋めてきました。
とくに開発者として重要なのは以下の3点です。
- TBAの廃止タイムラインが正式確定した（2027.1で新規不可）
- REST APIにバッチ処理が追加された
- SuiteCloud Developer AssistantというAIコーディング支援がVS Codeに来た
財務・運用担当者向けには、AI搭載の月次締め管理ツールや、コンサインメント在庫管理の追加も大きい変更です。順番に見ていきます。
セクション2：開発者が一番先に確認すべきこと――TBA廃止タイムライン
何が変わるか
Token-Based Authentication（TBA）、つまりOAuth 1.0ベースの認証方式について、廃止のスケジュールが正式にアナウンスされました。
| 時期 | TBAの扱い |
|---|---|
| 現在（2026.1） | 既存・新規ともに利用可能 |
| 2027.1（来年前半） | 新規インテグレーションでのTBA使用が不可になる |
| 2027.2以降 | 既存TBAは継続サポートだが、新機能はOAuth 2.0のみ |
「2027.1なんてまだ先の話でしょ」と思われるかもしれませんが、インテグレーションの移行はそれなりに時間がかかります。既存の連携を棚卸しして、TBAを使っているものがいくつあるか把握するだけでも、今すぐやっておく価値があります。
また、2027.1からはOAuth 2.0の認可コードフロー（Authorization Code Grant）を使う場合にPKCEが必須になります。新規でOAuth 2.0を実装するなら、最初からPKCEを実装しておかないと後で書き直しになりますので、合わせて覚えておいてください。
実務への影響
今から新規インテグレーションを作るなら、無条件でOAuth 2.0を選んでください。
TBAで作り始めて来年移行するのは二度手間です。当ブログの別記事でRESTlet認証についてTBAベースで書いたものがありますが、あれは今後使う場面がなくなっていきます。新しく作るときはOAuth 2.0で設計することをおすすめします。
セクション3：REST APIにバッチ処理が追加された
何が変わるか
2026.1で、REST Web Servicesにバッチ操作（Batch Operations）が追加されました。
これまでREST APIで複数レコードを操作しようとすると、ループで1件ずつリクエストを投げるしかありませんでした。これが地味にパフォーマンスの足を引っ張っていました。バッチ処理の追加により、複数の操作を1リクエストにまとめて送れるようになっています。
イメージとしてはこういうことです：
【これまで】 POST /record/v1/salesorder/1 → 1件更新 POST /record/v1/salesorder/2 → 1件更新 POST /record/v1/salesorder/3 → 1件更新 ... （ループ） 【2026.1以降】 POST /record/v1/batch → 複数の操作をまとめて1リクエストで送れる
外部システムからNetSuiteに大量のデータを同期するような連携を作っている場合、ここは実測値の改善が期待できます。
合わせて追加されたREST操作
バッチ以外にも、以下が追加・拡張されています。
- Create Form Requests：フォームを介したレコード作成がREST経由で可能になりました
- SuiteScript 2.1のPATCHメソッドサポート：フィールドの部分更新がしやすくなりました
RESTとSuiteTalk（SOAP）の差は縮まり続けています。新規で統合を作るならRESTを選ぶ判断がより明確になってきました。
セクション4：VS CodeにAIコーディング支援が来た――SuiteCloud Developer Assistant
何が変わるか
SuiteCloud Developer Assistantという、VS Code上でSuiteScriptを書く際のAI支援ツールがアーリーアクセスで提供開始されました。
具体的にどこまで使えるかはまだ情報が限定的ですが、SuiteScript特有のモジュールやAPIに対応したコード補完・生成ができるとされています。
NetSuiteの開発でVS Codeを使っている方からすると、これは地味に大きい変化です。SuiteScriptのAPIはドキュメントを都度引かないと書けないことが多く、SuiteScript専用のコンテキストを理解した上でコード補完してくれるツールがあるのとないのとでは、作業速度がかなり変わります。
正直なところ
アーリーアクセスという位置づけなので、現時点での実用性は使ってみないとわかりません。ただ、NetSuiteがここに投資し始めたのは歓迎すべき方向性だと思います。新人のオンボーディングコストが下がるなら、チームとして助かります。
ただ、個人的にはここで少し立ち止まって考えたいことがあります。
このブログでは以前から「AIを上流工程から活用してコミュニケーションロスを減らす」ことをひとつのテーマに据えています。要件定義のあいまいさをつぶす・業務担当者との認識ズレを早期に解消する・設計段階でAIを巻き込む、といった話です。
その視点から見ると、「コーディングをAIで速くする」というアプローチは、正直なところレベル感が一段低いと感じています。コードを書くスピードを競っても、そもそもの要件が間違っていたり、ビジネス側との合意が取れていなかったりすれば、速く作った分だけ速く間違ったものが完成するだけです。
AIをコーディングの補助に使うことを否定しているわけではありません。ただ、「AIでコードが速く書ける」という話に同調して終わりにしてしまうのは、AI活用の本来の価値をかなり手前で止めてしまっている気がします。
SuiteCloud Developer Assistantが「SuiteScript専用の文脈を理解した上で設計の妥当性を問い返してくれる」ようなツールに育っていくなら話は別です。現状は「コード補完が賢くなった」という段階ですので、便利に使いつつも、そこで思考を止めないようにしたいと思っています。
セクション5：財務チームに効く変更――AI搭載の月次締め管理
Intelligent Close Manager
月次締め（Month-End Close）の進捗管理がAI化されました。
これまで月次締めのチェックリスト管理をスプレッドシートでやっていたチームは多いはずです。Intelligent Close Managerは、それをNetSuite上に集約し、AIが例外検知や進捗の可視化をやってくれるダッシュボードです。
具体的には以下のことができます：
- 締め処理の進捗をひとつの画面でリアルタイム確認
- 未処理・漏れ・例外をAIが自動でサーフェスアップ
- タスクへのハイパーリンクで直接作業画面に飛べる
「何が残っているか探す」という締め作業特有の非効率が減ります。管理者が各担当者に個別で確認する手間が省けるのが現実的なメリットです。
AI支払い日予測
売掛金の管理において、顧客ごとの過去の支払い履歴をもとに、いつ支払われるかをAIが予測する機能が追加されました。
フィールドとして追加されるのは以下の3つです：
Predicted Payment Date（予測支払い日）Predicted Overdue Days（予測延滞日数）Prediction Availability（予測の信頼性）
キャッシュフロー予測の精度が上がる可能性があります。ただし有効化が必要で、予測はあくまで推定値です。過信しすぎず補助情報として使うのが現実的な運用だと思います。
セクション6：在庫管理に関わる変更――コンサインメント在庫の正式対応
何が変わるか
コンサインメント在庫（ベンダーが所有したまま自社倉庫に置いておく在庫）の専用管理機能が追加されました。
これまで、コンサインメントを管理しようとすると：
- カスタムワークフローで無理やり管理
- 手動で仕訳を作って対応
- 「なんか合わない」と毎月修正
という状況になりがちでした。卸売・製造業では珍しくないビジネスモデルなのに、NetSuiteが長年対応していなかった部分です。
2026.1では以下が正式サポートされます：
- ベンダー所有在庫と自社在庫を別々に追跡
- 消費時点で自動的に資産勘定とCOGS（売上原価）に計上
- 通常品・ロット番号管理品・シリアル番号管理品すべてに対応
そもそも預託在庫と自社在庫は「管理の本体」が違う
ここで少し立ち止まって整理しておきます。コンサインメント（預託在庫）と自社在庫は、言葉としては似ていますが、管理として何を守るかがまったく異なります。
預託在庫の本体は「使用実績の管理」です。 在庫がいくつあるかではなく、いくつ使ったかが請求の根拠になります。使用量の記録が不正確なら、仕入先への支払い根拠が崩れます。
自社在庫の本体は「残数量の管理」です。 今いくつあるかが資産評価の基準であり、棚卸差異は自社の責任で調整します。
この違いを表にすると以下の通りです。
| 項目 | 預託在庫（コンサインメント） | 自社在庫 |
|---|---|---|
| 所有権 | 仕入先 | 自社 |
| 仕入計上タイミング | 使った時点 | 入庫した時点 |
| 在庫評価 | しない（資産外） | する（資産計上） |
| 棚卸・調整 | 勝手に調整不可（仕入先との合意が必要） | 自社で調整可能 |
| 管理の肝 | 使用量の正確さ＝請求根拠 | 残数量の正確さ |
これまでNetSuiteでこの区別を正確に管理しようとすると、カスタムスクリプトや手動仕訳でなんとか辻褄を合わせるしかありませんでした。2026.1でこの区別がシステム側に組み込まれたことで、「使った分だけ仕入計上」という預託本来の会計処理をNetSuiteネイティブで実現できるようになります。
倉庫管理でコンサインメントを扱っているなら、カスタム開発のメンテから解放される可能性があります。ただし、既存の運用フローとの整合確認は必要ですので、サンドボックスで十分に検証してから本番適用してください。
セクション7：セキュリティ関連の変更――地味だが見落とすと困るやつ
複数セッションに2FAが必要になった
NetSuiteで複数のセッションを同時に使う（複数ブラウザタブや別ウィンドウでのログイン）には、2FAが有効なロールが必要になりました。
開発者や管理者がテスト中に複数アカウントを同時に開いて作業することはよくあります。そのユーザーのロールに2FAが設定されていないと、この動作ができなくなります。気づかずに詰まるパターンが出てきそうなので、今のうちにロール設定を確認しておくことをおすすめします。
インテグレーションの証明書上限
インテグレーションレコードごとに、アクティブな証明書は最大5件までという上限が設けられました。無効化された証明書は上限の対象外です。
大量のインテグレーションレコードを持っている環境では、アップデート前にアクティブ証明書の棚卸しをしておく必要があります。
ログインメッセージの強制確認
管理者が設定したログインメッセージをユーザーが確認しないとシステムに入れない設定が追加されました。確認の記録（タイムスタンプ・ユーザー情報）はLogin Audit Trailに残ります。
コンプライアンス要件でログイン時の同意取得が必要な環境では、カスタム開発なしで対応できるようになりました。
まとめ：2026.1で今すぐやること
開発者として優先度が高い対応を整理します。
【今すぐ】 □ TBAを使っているインテグレーションを棚卸しする □ 新規インテグレーションはOAuth 2.0で設計する □ 複数セッションを使うユーザーのロールに2FAを設定する □ インテグレーションのアクティブ証明書が5件以内か確認する 【今月中】 □ REST APIのバッチ操作を試してみる（パフォーマンス改善の余地がある連携がある場合） □ SuiteCloud Developer AssistantのVS Code拡張を触ってみる 【財務担当者と一緒に確認】 □ Intelligent Close Managerの有効化を検討する □ AI支払い日予測フィールドを試験的に有効化してみる □ コンサインメント在庫を扱っているなら新機能で置き換えられないか確認する
2026.1は「大きく壊れるものはないが、TBAだけは計画的に対応が必要」というリリースです。今すぐ動かなくなるわけではありませんが、2027.1は想像より早く来ます。インテグレーションの棚卸しだけは今月中にやっておくことをおすすめします。
