システムは動いています。エラーも出ていません。それでも、期日が決まっている宿題があります。
Oracleは、NetSuiteの連携で使われてきた認証方式を、順次終了する方針を公表しています。区切りとなるのは2027.1のバージョンです。
該当する連携があれば、その日を境に動かなくなります。
やっかいなのは、この変更が静かに効いてくる点です。画面に警告が出るわけでも、システムが停止するわけでもありません。連携が認証に失敗し、データが流れなくなるだけです。
この記事では、何がいつ変わるのか、自社に関係があるのかをどう見分けるのか、そして何から手をつければよいのかを整理します。
技術的な詳細は最小限にしています。経営層の方が判断材料として読める内容を目指しました。
この記事で分かること
- 2027.1で何が変わるのか（3つの期日）
- 自社に関係があるかを、どう見分けるか
- なぜこれが技術の話ではなく、経営の話なのか
- 今日から着手できる、最初の一歩
読了時間の目安：約12分
2027.1で何が変わるのか
まず、事実から整理します。
NetSuiteでは、外部システムと連携する際にいくつかの認証方式が使われてきました。認証方式とは、外部のシステムがNetSuiteにアクセスする際の「本人確認の方法」です。
古い方式から新しい方式へ、段階的な移行が進められています。
| 時期 | 変わること | 影響 |
|---|---|---|
| 2027.1 | NLAuthを使う連携が動作を停止 | 該当する連携は止まります |
| 2027.1 | TBAでの新規連携が作成不可に | 既存分は動きますが、新規構築や作り直しができません |
| 2027.1 | OAuth 2.0でPKCEが必須に | これから作るなら、この前提で設計します |
| 2028.1（暫定） | 既存のTBA連携もサポート終了 | 猶予期間の終わりです |
Oracleの公式ドキュメントでは、NLAuthについて「2027.1以降、この方式を使うすべての連携は動作を停止する」と明記されています。
2028.1の期日については、現時点では暫定的な予定とされています。前倒しや延期の可能性があるため、確定情報として扱わないほうが安全です。
ここで押さえておきたいことが一つあります。
NetSuiteのバージョンアップは、自動で適用されます。利用者側で「今回は見送る」という選択はできません。
準備ができているかどうかにかかわらず、期日は向こうからやってきます。
自社に関係があるのか、を見分ける
次の疑問は「うちは該当するのか」でしょう。
判断のために、3つの方式を整理します。技術的な仕組みではなく、性質の違いだけを押さえてください。
| 方式 | どういうものか | 2027.1以降 |
|---|---|---|
| NLAuth | 最も古い方式。IDとパスワードをそのまま送る | 動作停止 |
| TBA | 次の世代の方式。専用の鍵を使う | 新規作成が不可（既存は当面動作） |
| OAuth 2.0 | 現行の標準方式。期限付きの鍵を使う | これが移行先 |
古い連携ほど、上の2つを使っている可能性が高くなります。
とくに、次のような連携は確認の優先度が高いと考えられます。
- ECサイトや通販システムとの受注連携
- 銀行との入出金データ連携
- EDI（取引先との電子データ交換）
- 独自に開発した業務ツールとの連携
- 数年前に構築され、その後触っていない仕組み
自社の状況を知るには、情報システム担当者かNetSuiteのパートナーに、次の3点を確認するのが早道です。
- 現在、外部と連携している仕組みは何本あるか
- そのうち、NLAuthまたはTBAを使っているものはどれか
- それぞれ、誰が管理しているか
画面の操作手順はバージョンによって変わるため、この記事では扱いません。上の3点を質問すれば、担当者は調べられます。
答えがすぐに出てこない場合、それ自体が状況を示しています。
なぜこれが「経営の問題」なのか
ここまでは事実の整理です。ここからが本題です。
認証方式の変更は、一見すると技術部門の作業に見えます。実際、作業そのものは技術的なものです。
それでも経営の問題だと考えるのには、3つの理由があります。
理由1：止まったときに、止まるのは業務だから
連携が動かなくなると、受注データが入ってこなくなります。在庫の数字が実態とずれます。支払いや請求の処理が滞ります。
止まるのはシステムではなく、商売そのものです。
理由2：気づくのが遅れるから
システム障害であれば、誰かがすぐ気づきます。画面が開かない、エラーが出る、といった形で表面化するからです。
ところが連携の停止は、静かに進みます。
データが「入ってこない」ことに気づくには、入ってくるはずのデータを誰かが待っている必要があります。日次でチェックしていなければ、数日は分かりません。
そして気づいた後には、止まっていた期間のデータを突き合わせる作業が待っています。復旧より、この後始末のほうが重いことがあります。
理由3：対応にはリードタイムと予算が必要だから
調査、設計、テスト、切り替え。連携の数と複雑さによりますが、数か月単位の期間を見込む必要があります。
期日が近づくほど、対応できる技術者の確保も難しくなります。同じ期限に向けて、多くの企業が同時に動くためです。
つまり、これは「いつやるか」を経営が決める案件です。技術部門が判断できるのは「どうやるか」までです。
いちばん危ないのは、誰も担当していない連携
3つの理由のうち、最も見落とされやすいのが2番目です。
そして、気づきにくさが最大になるのは、誰も担当していない連携の場合です。
こういう連携は、どの会社にもあります。
- 数年前に、当時の担当者が構築した
- 依頼した会社との取引は、すでに終わっている
- 動いているので、誰も触っていない
- 何のための連携か、正確に説明できる人がいない
こうした仕組みは、日々の業務では問題を起こしません。むしろ、きちんと動いているからこそ、存在を忘れられます。
ところが今回のような変更では、真っ先に問題になります。
理由は単純です。移行の前に、まず調査から始めなければならないからです。設定を見て、何とつながっているかを推測し、業務への影響を確認する。ここに想定外の時間がかかります。
これは、業務の属人化と同じ構造です。
担当者の頭の中にあった知識が、その人の退職とともに失われる。連携の場合、失われるのは「なぜこれが必要で、どう作られているか」という文脈です。
仕組み自体は残っているのに、意味が失われている状態と言えます。
だからこそ、この機会に棚卸しをしておく価値があります。
期限のある変更対応は、面倒な宿題です。ただし、放置されていた仕組みを整理する機会でもあります。
同じ作業をするなら、一覧が残る形で進めたほうが、次の変更のときに楽になります。
まず何を確認するか——棚卸しの手順
ここからは実務の話です。
対応の第一歩は、移行作業ではありません。現状の把握です。次の順序で進めます。
手順1：連携の一覧を作る
何本の連携があるかを、まず数えます。
このとき、次の項目を一覧にします。
- 連携の名称と目的（何のための連携か）
- つながっている相手のシステム
- 使っている認証方式
- 管理している担当者または委託先
- 止まったときの業務影響
最後の項目が重要です。ここが後の優先順位づけに効いてきます。
手順2：該当する連携を絞り込む
一覧のうち、NLAuthまたはTBAを使っているものを特定します。
すでにOAuth 2.0で構築されているものは、今回の対象外です。ただし、PKCEへの対応が必要かどうかは別途確認します。
手順3：影響の大きさで並べ替える
該当する連携を、止まったときの影響で3段階に分けます。
- 大：止まるとその日の業務が止まる（受注、決済、出荷など）
- 中：数日中に対応すれば影響を抑えられる（集計、レポート連携など）
- 小：止まっても業務は回る（参考データの同期など）
この並べ替えが、移行の順序を決めます。
手順4：期間と費用を見積もる
ここまで来て、初めて見積もりが立ちます。
連携1本あたりの作業量は、仕様の明確さによって大きく変わります。仕様書があるものと、調査から始めるものでは、必要な期間が数倍違うこともあります。
見積もりが出れば、予算の判断ができます。逆に言えば、ここまで進めないと経営としては判断できません。
移行の進め方——一斉ではなく、段階的に
移行そのものは、影響の小さいものから順に進めます。
理由は2つあります。
手順を確立できるから
最初の1本は、想定外のことが起こります。認証の設定でつまずく、テスト環境と本番で挙動が違う、切り替え後にエラーが出る。
これを影響の小さい連携で経験しておけば、以降は同じ手順を適用できます。
元に戻す判断ができるから
影響の小さい連携なら、問題が起きたときに落ち着いて対処できます。業務が止まっている状態では、冷静な判断が難しくなります。
また、可能な範囲で並行稼働を取ります。
新しい方式で動くことを確認してから、古い方式を止める。この順序であれば、切り替えのリスクを抑えられます。
期日まで時間があるほど、この進め方が選べます。時間がなくなると、一斉切り替えしか選択肢がなくなります。
移行でつまずく、3つのパターン
期日が決まっている作業には、共通したつまずき方があります。ここでは3つのパターンを整理します。
失敗1：「今は動いているから大丈夫」で先送りした
よくある現象
- 期日は知っているが、具体的な調査は始まっていない
- 「来期の予算で対応しよう」と判断し、そのまま話題に上らなくなる
- 気づいたときには、対応期間が数か月しか残っていない
なぜ起きるのか
今日困っていない課題は、優先順位が上がらないためです。
しかも、この変更は自分たちのタイミングで対応できません。NetSuiteのバージョンアップは自動で適用されるからです。準備ができていなくても、期日は向こうからやってきます。
さらに厄介なのは、期日を過ぎたときの現れ方です。
システムが派手に停止するわけではありません。連携が認証エラーを返すだけです。受注データが同期されない、在庫の数字が少しずつずれる、支払いの連携が静かに止まる。
誰かが気づくのは、たいてい何日か経ってからです。そこから、止まっていた期間のデータを突き合わせる作業が始まります。
どう避けるか
まず調査だけを、先に済ませておくことです。
対応そのものは後でも構いません。ただし「何本の連携があり、どれが該当するか」を把握しておけば、必要な期間と費用の見積もりが立ちます。
見積もりが立てば、予算の議論ができます。何も分からないままでは、判断のしようがありません。
失敗2：構築したベンダーと、連絡が取れなくなっていた
よくある現象
- 「この連携、誰が作ったんだっけ」という会話が出てくる
- 当時の担当者が退職しており、社内に分かる人がいない
- 仕様書が見当たらず、設定内容から推測するしかない
なぜ起きるのか
連携は、一度動きはじめると誰も触らないためです。
設計した人が異動する。構築した会社との取引が終わる。担当者が退職する。それでも連携は動き続けるので、所在が分からなくなったことに誰も気づきません。
そして今回のような変更のときに、初めて問題が表面化します。
移行作業そのものより、「何がどう動いているかを調べる」段階に時間がかかるのは、このためです。
どう避けるか
連携の一覧を、会社の資産として持っておくことです。
何のための連携か、どのシステムとつながっているか、誰が管理しているか。この3点が分かる一覧があるだけで、今回のような場面で動きが変わります。
ベンチャーネットでは、移行の前提としてこの棚卸しから着手します。作業量を正確に見積もるためには、まず全体像が必要だからです。
失敗3：一斉に移行しようとして、止められない業務にぶつかった
よくある現象
- 該当する連携をまとめて切り替える計画を立てた
- 切り替え当日、受注や決済の連携でトラブルが起きた
- 元に戻す手順を決めていなかったため、復旧に時間がかかった
なぜ起きるのか
まとめて対応したほうが効率的に見えるためです。
ところが連携ごとに、止まったときの影響がまったく違います。夜間の集計処理が半日止まっても影響は限定的ですが、受注や決済の連携が止まれば、その日の商売が止まります。
同じ扱いにすると、影響の大きい連携も同じリスクにさらされます。
どう避けるか
影響の大きさで順番を決め、並行稼働しながら段階的に移すことです。
具体的には、次の順序が現実的です。
- 第1段階：止まっても影響の小さい連携で手順を確立する
- 第2段階：影響が中程度の連携に広げる
- 第3段階：受注・決済など、業務の中心にある連携を移す
第1段階で手順とトラブル対応が確立していれば、第3段階のリスクは大きく下がります。
期日まで時間があるうちほど、この段取りが取れます。これが「早く着手したほうが安く済む」理由です。
よくある質問
うちのNetSuiteが何を使っているか、どう調べればいいですか
情報システム担当者、または導入を支援したパートナーに確認するのが確実です。
確認する内容は3点です。外部と連携している仕組みが何本あるか、そのうちNLAuthまたはTBAを使っているものはどれか、それぞれ誰が管理しているか。
社内に分かる人がいない場合は、パートナーに調査を依頼できます。調査だけを単独で依頼することも可能です。
2027.1は、いつ来ますか
NetSuiteは年に2回のバージョンアップがあり、2027.1は2027年前半の予定です。
適用のタイミングはアカウントごとに異なり、Oracleのスケジュールに従って順次実施されます。利用者側で延期を選ぶことはできません。
具体的な適用日は、自社のアカウントで確認できます。
既存の連携は、すぐに止まってしまうのですか
方式によって異なります。
NLAuthを使っている連携は、2027.1で動作を停止します。これは確定した内容として公表されています。
TBAを使っている連携は、2027.1以降も当面は動作します。止まるのは「新規に作れなくなる」という制限です。ただし、既存分のサポート終了も2028.1に予定されています（暫定）。
つまり、NLAuthは対応必須、TBAは計画的な移行が必要、という整理になります。
自社で対応できますか、パートナーに依頼すべきですか
連携の本数と、社内の体制によります。
判断の目安は、次の3点です。連携の仕様が把握できているか、テスト環境で検証できる体制があるか、切り替え時にトラブルが起きた場合の対応者がいるか。
3点とも整っていれば、社内対応も可能です。一つでも不安があれば、調査だけでも外部に依頼したほうが、結果的に早く安く済むことが多くなります。
まとめ：期限のある宿題は、早いほど安く済む
今回の変更について、押さえておきたい点を整理します。
- 2027.1でNLAuthを使う連携は動作を停止する
- 同じく2027.1から、TBAでの新規連携は作成できなくなる
- 既存TBAのサポート終了は2028.1に予定されている（暫定）
- バージョンアップは自動適用で、延期は選べない
そして経営として押さえるべきは、次の1点です。
この案件は「いつやるか」を経営が決め、「どうやるか」を技術部門が決めるものです。
現場からは、期日の話は上がりにくいものです。今日困っていないからです。
しかし、対応には調査・設計・テスト・切り替えの期間が必要です。期日が近づくほど、選べる進め方が減り、対応できる技術者も確保しづらくなります。
今日から着手できることは、一つだけです。
情報システム担当者に、連携の一覧があるかを確認してください。
一覧があれば、次の判断に進めます。なければ、作ることが最初の仕事です。
この作業は、今回の対応が終わった後も残ります。次の変更が来たとき、同じ調査を繰り返さずに済むからです。
期限のある宿題は、面倒です。ただし、放置してきた仕組みを整理する機会でもあります。
もう少し詳しく知りたい方へ
- キーマンが辞めても会社が止まらない仕組み：担当者不在の仕組みが抱えるリスクを、経営視点から
- AIで「作れる」時代の落とし穴：増え続ける仕組みを、どう管理し続けるか
- NetSuiteのバージョンアップとは：年2回の自動アップグレードの仕組みと、備え方
自社の連携がどうなっているか確認したい方は、NetSuite認定パートナー（Solution Provider）であるベンチャーネットにご相談ください。棚卸しから移行計画の作成まで対応します。
