データソースの種類：File・JDBC・LDAP・OIDC
インポート・連携シリーズの4本目です。ここまで、3段構造の真ん中（変換マップ）と、重複を防ぐ coalesce を見てきました。今回は3段の入口、データソースを扱います。
データソースは「どこから、どんな形式で取り込むか」を1レコードで定義するものです。CSV ファイルなのか、外部データベースなのか、ディレクトリサービスなのか。取り込み元が変わると、指定する項目もがらりと変わります。今回は、実機の17件を種類ごとに開いて、その違いを読み解きます。
この記事は、ServiceNow の PDI（Personal Developer Instance、無料の個人検証環境）Zurich リリース・OOTB（初期設定）で確認した実測メモです。件数・設定値はすべて REST と実画面で確認しました（確認日 2026-07-13）。本番環境では設定が異なります。
4つのタイプに分かれる
まずデータソースの一覧を、種類（type）で見ます。実測で17件あり、内訳はこうでした。
File が8件でいちばん多く、外部IdP連携の OIDC が5件、データベース直結の JDBC が2件、ディレクトリ連携の LDAP が2件。一覧では Name / Type / Format / Updated の列が並び、それぞれのサンプルがどのタイプ・形式かがひと目で分かります。この4タイプが、取り込み元の代表格です。File が最多なのは、ファイル取り込みが最も汎用的で、相手を選ばず使えるからです。相手システムが何であれ、CSV さえ出せれば繋がる。だから OOTB のサンプルも File が厚めに用意されています。ファイルを読むのか、DBに繋ぐのか、認証基盤と連携するのか。取り込み元の性質が違えば、指定すべき情報も違います。だから、同じ「データソース」というテーブルでも、タイプごとに見える項目が変わる作りになっています。この「タイプで顔が変わる」ところが、今回いちばん面白い部分です。
File タイプ：ファイルから取り込む
まず、いちばん基本の File タイプを開きます。「Example CSV Test Users on Path」というサンプルです。
Type は File、Format は CSV。ここまでは素直です。注目したいのは右上の File retrieval method（ファイルの取得方法） で、この例では Attachment（手でファイルを添付）になっていました。この項目の選択肢には、Attachment のほかに FTP、FTPS、HTTP、SCP があります。つまり同じ CSV でも、「手で添付する」「FTPサーバから取りに行く」「HTTPで落とす」といった取得方法を、ここ1つで切り替えられる。取り込み元のシステムがどこにあっても、この1項目で対応できるわけです。
ほかにも File タイプらしい項目が並びます。Zipped（圧縮ファイルか）、Use Batch Import（バッチ取り込みを使うか）、CSV delimiter（区切り文字の指定）。CSV がカンマ区切りでなくタブ区切りやセミコロン区切りのときは、この delimiter で指定する。ファイルを扱ううえで必要な設定が、ひととおりそろっています。画面の下には Transforms（変換マップ）の関連リストもあり、このデータソースをどの変換マップが使うかを結びつけられます。
つまり File タイプのデータソースは、「1つのファイルを、どこから、どんな区切りで読むか」を1レコードにまとめたものです。CSV でも Excel でも、圧縮されていても、この1画面の設定で吸収できます。取り込み元のファイルの形が多少変わっても、データソースの設定を直すだけで済む。ファイルの扱いに関する知識が、この1レコードに凝縮されている、と捉えると分かりやすいです。
JDBC タイプ：データベースに直結する
次に、まったく毛色の違う JDBC タイプを開きます。「Example JDBC MySQL Glide.sys_user」です。同じデータソースの画面とは思えないほど、項目が変わります。
Type は JDBC、Format は MySQL。File タイプにあった「ファイル取得方法」は消え、代わりにデータベース接続の項目がずらりと現れます。Server（接続先サーバ）、Database name（データベース名）、Database port（ポート）、Username と Password（認証）、Table name（対象テーブル）、Query（取得クエリ）。この例では、localhost の glide というデータベースの sys_user テーブルを、「All Rows from Table（テーブルの全行）」で取りに行く設定になっていました。
JDBC は、CSV のようなファイルを介さず、外部データベースに直接繋いで読む方式です。だから、どのサーバの、どのDBの、どのテーブルを、どんなクエリで取るか、という接続情報が要ります。多くの場合、社内DBは外から直接見えないので、MID Server（社内に置く中継サーバ）経由で繋ぎます。画面の「Use MID Server」がそのための項目です。File と JDBC を並べると、「取り込み元が変わると、こんなに指定するものが変わる」ことがよく分かります。なお、この例の Username や Server は OOTB のサンプル値で、実際にどこかに繋がっているわけではありません。
Query の項目にも注目です。この例は「All Rows from Table（テーブルの全行）」でしたが、ここを変えれば、条件を絞ったクエリで必要な行だけを取ることもできます。さらに「Use last run datetime（前回実行日時を使う）」という項目もありました。これをオンにすると、前回の取り込み以降に更新された行だけを取る、という差分取り込みができる。毎回全件を取り直すと重いので、大きなテーブルでは差分取り込みが効きます。File が「渡されたファイルを読む」受け身なのに対し、JDBC は「必要な行を、必要な条件で、自分から取りに行く」能動的な取り込みだ、と捉えると違いがはっきりします。同じデータソースでも、性格がずいぶん違うわけです。
File と JDBC、どう使い分けるか
File と JDBC は、どちらも「業務データを取り込む」点では同じです。では、どう選ぶのか。ざっくり言えば、やり取りの頻度と鮮度で決まります。
File は、ファイルを介する分、ひと手間かかります。誰かがファイルを出力し、それを取り込む。日次のバッチ処理のように「1日1回、決まったファイルを取り込む」運用に向いています。相手システムとの結合がゆるく、ファイルさえあれば繋がるので、導入も手軽です。
JDBC は、相手のデータベースに直接繋ぐので、ファイルを介さずその時点のデータをそのまま読めます。鮮度が高く、ファイルの受け渡しも要りません。一方で、DBへの接続情報や権限が必要で、社内DBなら MID Server も要ります。結合が密なぶん、導入のハードルは上がります。「毎晩のバッチなら File、常に最新を見たいなら JDBC」というのが、大まかな選び分けの目安です。実際には、相手システムがファイルしか出せない、DBを直接開けない、といった制約で決まることも多いのですが、まずはこの2つの性格の違いを押さえておくと判断しやすくなります。
LDAP と OIDC：認証基盤との連携
残る2タイプは、認証・ディレクトリ系です。LDAP は2件（Example LDAP Users、Example LDAP Groups）。社内のディレクトリサービス（Active Directory など）からユーザーやグループを取り込む方式です。取り込んだデータは ldap_import / ldap_group_import というステージングに入り、そこから sys_user / sys_user_group へ変換されます。
OIDC は5件（Okta、Google、ADFS、Auth0、Azure AD の Example）。こちらは OpenID Connect という規格で、外部のIDプロバイダ（IdP）と連携するためのものです。取り込み先はやはり sys_user 系です。File や JDBC が「データを取ってくる」ためのものだとすれば、LDAP と OIDC は「認証基盤の情報を取り込む」ための特化型、と捉えると位置づけがはっきりします。OOTB でこれだけのIdPテンプレートが並んでいるのは、それだけ多くの企業が外部認証と連携している、という現実の反映でもあります。
これらの認証系データソースが、なぜ専用のタイプになっているのか。理由は、ユーザー情報の取り込みが、企業システムでとりわけ頻繁だからです。人の入退社、部署異動、権限変更。こうした変化を ServiceNow に反映するには、人事システムや Active Directory から定期的にユーザーを取り込む必要があります。だから ServiceNow は、代表的なIdPごとにテンプレートを用意し、繋ぎやすくしています。前回まで見てきた変換マップの一覧に、LDAP や OIDC のマップがずらりと並んでいたのも、同じ理由でした。データソースの側でも、変換マップの側でも、ユーザー取り込みが手厚く用意されている。ユーザー情報は「取り込みの主役」だと言えます。
取り込める形式と拡張子
File タイプで取り込めるファイルは、無制限ではありません。プロパティにその制限が表れています。
glide.import.file.extension_whitelist を実測すると、csv,xls,xlsx,json,xml,zip,txt に限定されていました。CSV や Excel だけでなく、JSON や XML も取り込めます。zip は圧縮ファイルの中身を展開して読むためのものです。逆に言えば、この一覧に無い拡張子（実行ファイルなど）は弾かれます。想定外の形式を誤って取り込ませない、という安全弁です。取り込みで「このファイルは受け付けられない」と言われたら、まずこのホワイトリストを疑う、という勘所になります。
JSON や XML が入っているのも見逃せません。CSV や Excel は「表形式」のデータですが、JSON や XML は入れ子構造を持てます。外部システムの API が返すデータは JSON のことが多いので、それをファイルとして受け取って取り込む、という使い方もできます。データソースが扱えるのは、単純な表だけではない、というわけです。ただし、入れ子のデータをステージングの平らな表に落とし込むには、それなりの設定が要ります。まずは「CSV / Excel が基本、JSON / XML も扱える」という守備範囲を押さえておけば十分です。取り込める形式の広さも、データソースの設計値の1つとして読めます。
タイプでフォームが変わる仕組み
File と JDBC で項目がこれほど変わるのはなぜか。答えは、sys_data_source テーブルが、あらゆるタイプの項目をあらかじめ持っているからです。
データソースのテーブル定義を見ると、name / type / format といった共通項目に加えて、ファイル取得方法、DBのサーバ・ポート、認証情報など、各タイプ固有の項目がずらりと定義されています。実際の画面では、選んだ type に関係する項目だけが表示され、関係ない項目は隠れます。File を選べばファイル系が、JDBC を選べばDB系が現れる。1つのテーブルで、複数の取り込み方式を扱うための作りです。裏側は1枚のテーブルで、見た目だけタイプに応じて切り替えている、というのが実態でした。
この「表示・非表示の切り替え」は、ServiceNow では UI Policy や Client Script という仕組みで実現されています。type の値を見て、関係ある項目だけを出す。だからこそ、File のときにDBのパスワード欄が出てきて混乱する、といったことが起きません。利用者から見れば「タイプを選ぶと、必要な欄だけが出てくる親切なフォーム」ですが、その裏には、1枚のテーブルに全項目を持たせ、条件で出し分けるという設計があります。データソースは、この「1テーブル・多タイプ」の作りの、分かりやすい実例です。新しい取り込み方式が増えても、テーブルに項目を足して出し分ければよい、という拡張のしやすさも、この設計の利点です。
データソースと変換マップの関係
最後に、データソースが3段構造のどこにいるかを、もう一度確かめます。
データソースは、いちばん左の「取り込み口」です。ここで取り込んだデータは、ステージングテーブルに着地し、変換マップを通ってターゲットへ移ります。データソース（取り込み口）と変換マップ（移し方）は分かれています。だから、取り込み元が CSV から JDBC に変わっても、データソースを差し替えるだけで、後段の変換マップはそのまま使えます。取り込み方と変換ルールを分離しているからこその柔軟さが、ここでも活きています。
この分離は、移行プロジェクトでよく効きます。たとえば、最初はテスト用に手元の CSV（File / Attachment）で取り込みを試し、動作が固まったら本番では社内DB（JDBC）に切り替える、という進め方ができる。そのとき、作り込んだ変換マップや coalesce の設定は、そっくりそのまま使い回せます。取り込み口だけを差し替えればよいからです。もし取り込み口と変換ルールが一体だったら、方式を変えるたびに全部を作り直すことになります。データソースという「口」を独立させたことで、試作から本番への移行が滑らかになる。地味ですが、実務で助かる設計です。
確認導線
実機で開くときの入口です（URL形式は list.do 規約に基づきます。実クリック確認は今回の範囲外です）。
データソース一覧 … sys_data_source_list.do
データソース1件 … sys_data_source.do?sys_id=...
取込可能拡張子 … sys_properties_list.do?sysparm_query=name=glide.import.file.extension_whitelist
まとめ
データソースは、3段構造の入口として「どこから、どんな形式で取り込むか」を定義するものでした。実測17件は、File 8・OIDC 5・JDBC 2・LDAP 2 の4タイプ。File はファイルの取得方法と形式を、JDBC はDBの接続情報を、LDAP と OIDC は認証基盤との連携を指定します。同じテーブルでも、選んだタイプで見える項目が変わる。取り込み元の性質に合わせて、必要な情報だけを指定する作りです。
そして、この取り込み口は変換マップと分離されているので、口だけを差し替えて後段を使い回せます。試作は CSV、本番は JDBC、という進め方が自然にできる。データソースは、インポートの柔軟さを支える起点だと言えます。
実機で新しい取り込みを作るときも、順番は決まっています。まず type を選ぶ。すると、そのタイプに必要な項目だけが現れる。File なら取得方法と形式、JDBC なら接続情報。あとは現れた項目を埋めていけば、取り込み口が1つできあがります。タイプの数だけ入口の種類はありますが、「タイプを選んで、出てきた欄を埋める」という手順そのものは、どのタイプでも同じです。だから4タイプの性格さえ掴んでおけば、初めて触るタイプでも迷いません。
次回は、これらのデータソースを「決まった時刻に自動で取り込む」スケジュールインポートを見ていきます。手で取り込むのではなく、毎晩勝手に走らせる仕組みです。
その他、実機で確認した記録
用語
データソース（sys_data_source） … どこから・どんな形式で取り込むかの定義
File retrieval method … ファイルの取得方法（Attachment / FTP / FTPS / HTTP / SCP）
JDBC … 外部データベースに直接繋いで読む方式
MID Server … 社内に置く中継サーバ。外から見えないDBに繋ぐときに使う
extension_whitelist … 取り込めるファイル拡張子の許可リスト
自分の環境で確認するときのURL
自分のインスタンス名を先頭に付けると、同じ画面が開けます。
/sys_data_source_list.do（データソース17件・type列で絞れる）
/sys_data_source.do?sys_id=...（1データソースの設定・typeで項目が変わる）
/sys_properties_list.do?sysparm_query=name=glide.import.file.extension_whitelist
実測の要点（再掲）
データソース17件: File 8 / OIDC 5 / JDBC 2 / LDAP 2
File: retrieval method（Attachment/FTP/FTPS/HTTP/SCP）・format（CSV/CSV tab/Excel）・delimiter
JDBC: Server / Database / Username / Table / Query（MID Server 経由も）
取込可能拡張子: csv,xls,xlsx,json,xml,zip,txt
検証範囲とおことわり
この記事の件数・タイプ別内訳・フィールドは、PDI（Zurich / OOTB）の実測です。
実接続（FTP / JDBC / LDAP / OIDC の接続先）は当然この環境では未接続で、実際の取り込みは sys_import_set が0件のため未確認（検証範囲外）です。
JDBC 例の Username（root）や Server（localhost）は OOTB のサンプル値で、実在の資格情報ではありません。
list.do のURL形式は規約に基づくもので、実クリック確認は今回の範囲外です。
