2026.10.05 開発

Keyspiderとは：国産ID管理の連携方式と自社システムをつなぐ実装手順

人事異動のたびに、情シスが十数個のシステムへ手作業でアカウントを作り直している。Keyspider（キースパイダー）は、この作業を人事データ起点で自動化する国産のクラウドID管理サービスです。本記事では、Keyspiderの立ち位置とMicrosoft Entra IDやOktaとの役割の違い、公式機能一覧から読み取れる連携の範囲、そして導入時に必ず発生する「連携先システム側の改修」をSCIMとCSVの実装例つきで説明します。月額300円・最低300ユーザーという価格から逆算した費用感と、採用を見送るべき条件も示します。製品情報は2026年10月5日時点の公式サイトと公開資料で確認した内容です。

まとめ：Keyspiderは人事起点のID配布製品で、成否は連携先の受け口で決まる

結論を先に置きます。Keyspiderはログインを担う製品ではなく、「誰が、どの組織に、どの権限で在籍しているか」を各システムへ配る製品です。導入判断で押さえるべき点は次の4つです。

役割はIDの配布：シングルサインオンはEntra IDやトラスト・ログインなどのIDaaSが担い、Keyspiderはそこへユーザー・組織・権限を同期する上流に立ちます。
強みは日本の人事慣習：階層型組織、兼務、発令日（未来日付の人事異動）への対応を公式が前面に出しています。
工数の山は連携先側：SaaSは既製コネクタで済んでも、自社開発の業務システムはSCIM・API・LDAP・CSVのどれで受けるかを決め、改修が要ります。
費用の下限は年108万円：月額300円×最低300ユーザー×12か月。これに初期構築費が別に乗ります。

数百名以上で人事異動が多い組織なら投資に見合います。100名未満でEntra IDだけに閉じている組織では過剰です。

Keyspiderの位置づけとEntra ID・OktaなどIDaaSとの役割の違い

「ID管理」という言葉は、認証（ログイン）と、アカウントのライフサイクル管理の両方を指して使われます。Keyspiderは後者に特化した製品で、ここを取り違えると選定の比較表が噛み合いません。

人事システムを起点にIDを配布するID管理製品という立ち位置

公式サイトはKeyspiderを「日本企業向けに開発された国産クラウドID管理サービス」と説明し、ユーザー管理・組織管理・権限管理の統合と、クラウドサービスとオンプレミス社内システムのID連携を機能の中心に置いています（Keyspider公式サイト）。提供元はKeyspider株式会社で、アクシオの100%子会社として2019年1月に設立されています。

データの流れは一方向です。人事システムやActive Directoryから社員・組織・役職を取り込み、ポリシーに従って各システムのアカウントを作成・変更・無効化する。海外製品の分類でいえばIGA（Identity Governance and Administration）に近い領域で、ユーザーがKeyspiderの画面からログインして業務システムへ入る使い方は想定の中心にありません。

SSOを担うIDaaSと組み合わせる構成とトラスト・ログイン連携の実例

公式サイトが連携先として挙げるIDaaSは、Azure AD（現Microsoft Entra ID）、Okta、OneLogin、トラスト・ログインの4つです。つまりKeyspiderはIDaaSの競合ではなく、IDaaSへユーザー情報を供給する側に立ちます。

具体例がGMOグローバルサインの発表です。2023年2月28日のプレスリリースでは、トラスト・ログインとKeyspiderがSCIMプロビジョニングでユーザー情報・組織情報・権限情報を連携済みであり、同日からSAML認証連携にも対応したと述べています（GMOグローバルサインのプレスリリース）。人事データの正をKeyspiderに置き、ログインはIDaaSに任せる。この分担が基本形です。IDaaS側の製品比較はIDaaSの選定軸と連携方式の整理を、Entra IDそのものはMicrosoft Entra IDの機能と料金を参照してください。

階層組織・兼務・発令日という日本企業の人事慣習への製品側の対応範囲

Keyspiderを海外製品と分ける最大の要素は、人事データの癖への対応です。公式の比較ページは、階層型組織の定義、兼務を前提にした職制、業務引継期間への対応を強みとして挙げています（Keyspider公式の比較ページ）。

発令日対応は実装で効きます。4月1日付の異動を3月中旬に登録しておき、当日に権限を切り替える。Entra IDの標準機能だけでこれを組むと、人事システム側の連携処理に日付判定を書くことになり、例外処理が膨らみます。兼務者に「主所属の権限と兼務先の権限を両方付ける」要件も同じで、ここを製品側で吸収できるかが選定の分かれ目です。

公式機能一覧から読み解くプロビジョニングとデータマッピングの範囲

連携先を作る側として知っておくべきなのは、Keyspiderが「どこから取り込み、どう加工し、どう配るか」です。公式の機能ページ（Keyspider公式の機能一覧）の記載を、実装の観点で分解します。

取込元はRDB・Active Directory・CSVの3系統という入力側の設計

機能一覧では、データ取込の対応先を「人事システム(RDB)、Active Directory、CSVファイル等」と記載しています。人事システムのデータベースを直接読む経路があるため、人事パッケージにAPIが無くても連携の起点になれます。

実務上の注意は、取込元を1つに決めることです。人事DBとADの両方から社員情報を入れると、どちらが正かで差分が出続けます。正は人事DB、ADは配布先の1つとして扱う。この設計を最初の打ち合わせで固めておくと、後工程の手戻りが減ります。

データマッピングと自動生成で社員番号やメールアドレスを組み立てる処理

機能一覧には「同期先システムの項目に合わせて柔軟にデータマッピング」「社員番号やメールアドレスを自動生成」とあります。人事DBの「氏名（漢字）」「所属コード」を、配布先ごとに「姓名を分けた英字」「部署名」などへ変換する処理を、Keyspider側の設定で吸収する仕組みです。

連携先を開発する側から見ると、受け取る項目名と形式はKeyspider側で合わせてもらえる余地があります。逆に言えば、自社システムが受け取れる項目・桁数・文字種を仕様書として先に出さないと、マッピング設定が決まりません。

差分チェック・承認ワークフロー・監査証跡が担うJ-SOX向けの統制

統制系の機能として、DBとプロビジョニング先の状態に差分がないかを確かめる差分チェック、承認後に反映する承認ワークフロー、「いつ」「誰が」「どのような」操作をしたかを残す監査証跡、抽出条件を指定して作るID棚卸しリストが並びます。

J-SOX対応で監査人に求められるのは、退職者アカウントが残っていない証跡と、権限変更の承認記録です。差分チェックで「Keyspider上は無効なのに連携先では有効」というずれを検出できるため、連携先システム側でも状態を返せる作り（照会APIや一覧出力）にしておくと統制の効きが上がります。

自社開発システムをKeyspiderの連携先にする4つの受け口の選び方

SalesforceやGoogle Workspaceのような主要SaaSは連携実績のある接続先として扱えます。工数が読めないのは、社内で開発した業務システムです。販売パートナーの案内では、KeyspiderはSCIM以外にAPI、LDAP、CSVなどのファイル出力に対応するとされています（スタイルズのKeyspider導入サービス案内）。公式も「APIが無いSaaSやオンプレシステムとも連携可能」と記載しています。

SCIM・API・LDAP・CSVの4方式を比較した実装コストと即時性

連携先システム側の改修量と、変更が反映されるまでの時間で4方式を比べると次の通りです。

方式	連携先側の改修	反映の即時性	向く場面
SCIM 2.0	Users/Groupsの受け口を新設	変更の都度	新規開発・改修余地のあるWebシステム
独自API	既存APIへの認証と項目追加	変更の都度	ユーザー登録APIが既にある場合
LDAP	認証・ユーザー参照をLDAP化	参照時点	AD参照で動く既存のオンプレ製品
CSV	取込バッチの作成	バッチ周期	改修予算が小さい古いシステム

新規に作る場合の選択肢として勧めるのはSCIMです。標準仕様（RFC 7644のSCIMプロトコルとRFC 7643のコアスキーマ）に沿って作れば、Keyspiderを将来Entra IDやOktaへ置き換えても受け口を作り直さずに済みます。CSVは最も安く始められますが、退職者の無効化がバッチ周期ぶん遅れる点を監査側と合意しておく必要があります。

SCIM 2.0の受け口をcurlで検証する手順と最低限のリクエスト例

SCIMの受け口を作ったら、Keyspiderへ接続する前に自分で叩いて確認します。IDライフサイクルで必ず通る「存在確認・作成・無効化」の3リクエストを、社員番号をuserNameに使う前提で示します。トークンとホスト名は自社環境の値に置き換えてください。

# 1. 存在確認（userNameで検索。未登録ならtotalResultsが0）
curl -s -G "https://app.example.co.jp/scim/v2/Users" \
  -H "Authorization: Bearer ${SCIM_TOKEN}" \
  --data-urlencode 'filter=userName eq "E10234"'

# 2. 作成（externalIdには人事側の社員番号を入れる）
curl -s -X POST "https://app.example.co.jp/scim/v2/Users" \
  -H "Authorization: Bearer ${SCIM_TOKEN}" \
  -H "Content-Type: application/scim+json" \
  -d '{
    "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
    "userName": "E10234",
    "externalId": "E10234",
    "name": {"familyName": "山田", "givenName": "太郎"},
    "active": true
  }'

# 3. 無効化（退職・休職。削除ではなくactiveをfalseにする）
curl -s -X PATCH "https://app.example.co.jp/scim/v2/Users/${USER_ID}" \
  -H "Authorization: Bearer ${SCIM_TOKEN}" \
  -H "Content-Type: application/scim+json" \
  -d '{
    "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
    "Operations": [{"op": "replace", "path": "active", "value": false}]
  }'

1で返るidを2以降の${USER_ID}に入れて確認します。RFC 7644はPATCHを「add」「remove」「replace」の3操作で定義し、1件でも失敗すればリソースを元に戻すアトミックな扱いを求めています。退職処理を物理削除ではなく無効化で受けるのは、監査証跡と過去データの所有者を残すためです。Microsoft LearnのSCIMエンドポイント開発チュートリアル（Microsoft Entra IDでのSCIMエンドポイントの開発と計画）も、userName eqによる存在確認と、activeをfalseにする論理削除（ソフト削除）を受け口の要件として挙げています。ページングやエラー応答の設計まで踏み込む場合はSCIMのエンドポイント実装の詳細にまとめています。

Keyspider側が送ってくる属性名や拡張スキーマ（部署・役職を載せる位置）は、データマッピングの設定で決まります。受け口が対応する属性の一覧を、導入ベンダーとの打ち合わせ前に用意しておくと設定が早く終わります。

CSV連携を選ぶ場合の取込スクリプトと全件連携時の退職者の無効化処理

改修予算が限られる古いシステムでは、Keyspiderが出力するCSVを定時に取り込む方式が現実的です。列の並びはデータマッピングで合わせる前提で、社員番号・氏名・部署・在籍状態の4列を受け取り、CSVに無くなった社員も無効化する例をPythonの標準ライブラリだけで書くと次のようになります。

import csv
import sqlite3

# 取込対象: employee_id,name,dept,status（statusは active または inactive）
conn = sqlite3.connect("app.db")
conn.execute("""CREATE TABLE IF NOT EXISTS users(
  employee_id TEXT PRIMARY KEY, name TEXT, dept TEXT, active INTEGER)""")

seen = set()
with open("keyspider_users.csv", encoding="utf-8-sig", newline="") as f:
    for row in csv.DictReader(f):
        seen.add(row["employee_id"])
        conn.execute(
            """INSERT INTO users(employee_id, name, dept, active)
               VALUES(?, ?, ?, ?)
               ON CONFLICT(employee_id) DO UPDATE SET
                 name=excluded.name, dept=excluded.dept, active=excluded.active""",
            (row["employee_id"], row["name"], row["dept"],
             1 if row["status"] == "active" else 0))

# CSVから消えた社員は削除せず無効化する（全件連携のときだけ実行する）
if seen:
    marks = ",".join("?" * len(seen))
    conn.execute(f"UPDATE users SET active=0 WHERE employee_id NOT IN ({marks})",
                 tuple(seen))
conn.commit()
print(f"取込 {len(seen)} 件")

注意点は2つあります。1つ目は、CSVが空や途中切れで届いたときに全員を無効化しないよう、件数がゼロなら無効化を飛ばすこと（上の例の if seen）。実運用では前回件数から一定割合以上減ったら止める閾値を足します。2つ目は、差分出力と全件出力のどちらで受けるかをKeyspider側の設定と揃えることです。差分出力のファイルに対して「CSVに無い社員を無効化」を走らせると、在籍者を大量に止めてしまいます。

料金300円の内訳と最低300ユーザーから逆算する導入費用の見積り方

Keyspiderの公式サイトには価格表がありません。公開されている数字は、ASPIC（日本クラウド産業協会）のサービス紹介に掲載された月額利用料です（ASPICのKeyspiderサービス紹介）。

月額ライセンスと初期構築費が別建てになる費用構造と連携先の改修費

ASPICの掲載では、月額利用料は1ユーザーあたり300円で、最低利用数は300ユーザーからです。販売パートナーの案内は同じ300円を標準価格とし、ユーザー数に応じた割引と、要件に応じて見積もる初期構築費が別途かかると説明しています。

見積りで見落としやすいのは、ライセンスにも構築費にも入らない費用です。自社開発システムをSCIMやCSVで連携先にする改修は、Keyspider側ではなく各システムの保守ベンダーへの発注になります。連携先が5システムあれば、5本の改修見積りが並ぶ。総額を比べるときは、この連携先改修の合計を必ず足してください。

300ユーザーで年108万円から始まる下限と規模別のライセンス費概算

標準価格のまま計算した年間ライセンス費は次の通りです。割引は個別交渉のため含めていません。

利用ユーザー数	月額（300円×人数）	年額
100名（最低300名で計算）	90,000円	1,080,000円
300名	90,000円	1,080,000円
1,000名	300,000円	3,600,000円
3,000名	900,000円	10,800,000円

100名の組織でも300名ぶんを払う計算になり、1人あたりの実質負担は月900円です。この下限が、小規模組織で採用を見送る判断の根拠になります。

Keyspiderを採用すべき組織の条件と見送るべき場面の線引き

製品の良し悪しではなく、組織の規模と人事データの複雑さで判断が決まります。

人事異動の多い数百名以上の組織で採用が効く兼務や連携先の具体的な条件

採用を勧めるのは、次の条件が2つ以上重なる組織です。従業員が300名を超えている。4月・10月などに一斉異動があり、発令日に合わせた権限切替が必要。兼務者が多く、部署単位の権限付与ではずれが出る。連携先にオンプレミスの業務システムが3つ以上ある。J-SOXの監査でアカウント棚卸しの証跡を毎年求められている。

公式の導入事例ページ（Keyspiderの導入事例一覧）で、自社と規模や業種の近い事例があるかを先に確かめておくと、社内稟議の説明材料になります。年1回の大規模異動で情シスが数日を手作業に費やしているなら、年108万円の下限は回収できます。

100名未満やEntra ID単独で完結する組織で見送る判断

見送るべき場面ははっきりしています。従業員が100名未満で、使うSaaSがMicrosoft 365を中心にEntra IDのプロビジョニングで届く範囲に収まっている場合、Keyspiderは過剰です。1人あたり実質月900円を払っても、置き換わる手作業が年に数十件なら回収できません。

もう1つは、人事データが整っていない段階での導入です。人事DBに退職日が入っていない、所属コードが部署改編のたびに振り直されている、といった状態では、どの製品を入れても誤った無効化が起きます。製品選定より先に、人事マスタの整備を済ませてください。Entra IDやOktaの標準機能との比較はOktaの機能と料金の解説も判断材料になります。

受託開発で連携先システムを改修するときの責任分界と障害の切り分け

Keyspider導入プロジェクトで揉めやすいのは、連携が失敗したときの切り分けです。Keyspider側のマッピング設定の誤りか、連携先システムの受け口の不具合か。この境界を契約の段階で決めておく必要があります。実務では、連携先システム側が「受け取ったリクエストと応答をログに残す」ことを要件に入れ、Keyspider側の監査証跡と突き合わせられる状態にしておくと切り分けが速くなります。

一創では、業務システムへのSCIM受け口の追加、CSV取込バッチの作成、兼務や発令日を前提にした権限モデルの改修を受託しています。Keyspiderや各種IDaaSとの接続を前提にした改修の相談は、認証基盤・ID管理システム開発のページから受け付けています。

よくある質問

Keyspiderの検討時に出やすい質問をまとめました。

Keyspiderだけでシングルサインオンは実現できますか？

Keyspiderの役割はユーザー・組織・権限の情報を各システムへ配ることで、ログインの集約は主な守備範囲ではありません。シングルサインオンが必要なら、Entra ID、Okta、OneLogin、トラスト・ログインなどのIDaaSと組み合わせ、KeyspiderからIDaaSへユーザー情報を同期する構成をとります。トラスト・ログインとはSCIMとSAMLの両方で連携した実績が公表済みです。SAMLの仕組み自体はSAMLの認証フローの解説で扱っています。

Keyspiderの料金はいくらですか？

公式サイトに価格表は無く、ASPICのサービス紹介では1ユーザーあたり月額300円、最低利用数300ユーザーと掲載されています。最低ラインの年額は約108万円です。ユーザー数に応じた割引があり、初期構築費は要件ごとの見積りになります。連携先の社内システムを改修する費用は別途、各システムの開発・保守ベンダーへの発注として発生する点に注意してください。

APIが無い社内システムとも連携できますか？

公式の比較ページは「APIが無いSaaSやオンプレシステムとも連携可能」と記載しています。販売パートナーの案内では、SCIMやAPIのほかLDAP、CSVなどのファイル出力に対応するとされています。APIの無いシステムでは、Keyspiderが出力するCSVを連携先側の取込バッチで読む方式が一般的です。その場合、退職者の無効化がバッチ実行の周期ぶん遅れることを監査側と合意しておきます。

Entra IDのプロビジョニング機能との違いは何ですか？

Entra IDもSCIMで各SaaSへアカウントを配れますが、起点はEntra ID上のユーザーです。Keyspiderは人事システムのデータベースを起点に、階層組織・兼務・発令日といった日本の人事慣習を製品側で吸収する点が異なります。異動が少なく組織が単純ならEntra IDで足り、人事データが複雑で連携先にオンプレミスが多いほどKeyspiderの価値が上がります。

Keyspiderの導入期間はどのくらいかかりますか？

公開資料に標準の導入期間は示されていません。期間を左右するのは製品の設定より、人事マスタの整備状況と連携先システムの数です。連携先ごとにマッピング定義と受け口の確認が必要なため、主要SaaS中心なら短く、改修が要る社内システムが多いほど長くなります。見積り依頼の前に、連携先システムの一覧と各システムの連携方式（SCIM・API・LDAP・CSV）を整理しておくと、期間の見通しが立てやすくなります。