日本の人事異動を、
そのままトレースする。
入社、配属、異動、引き継ぎ、退職。人事で決まったことが、そのままアカウントと権限になります。
4月1日付の異動でも、引き継ぎのために4月15日までは旧部署の権限を残しておきたい。5月1日付の配属でも、メーリングリストは4月のうちに申請しておきたい。これまで手作業でしか埋められなかった前後の期間を、HITOBASEはルールとして持ちます。
Active Directoryの廃止まで、一つの製品で。
入社から退職までのIDライフサイクル。所属が重なる期間も、状態として持つ。
連携するID基盤
Microsoft Entra ID
Active Directory
2026.12 予定
2026.12 予定課題
入退社のたびに、人事・総務・情シスの間で
メールが飛び交っていませんか。
HR
人事の困りごと
- 内定者のアカウントを事前に作りたいが、アドレス帳に出したくないので情シスに個別依頼が必要
- 組織変更が急に決まり、異動日に権限が間に合わない
- 兼務・出向・旧姓利用が人事システムにはあるのに、その先に伝わらない
GENERAL AFFAIRS
総務の困りごと
- 誰にどのライセンスを割り当てているかはID管理側にしかなく、人事の在籍情報と突き合わせるのに毎回数日かかる
- 退職者のライセンスが残ったまま課金され続けている
- 「誰が何を持っているか」を聞かれても、情シスに確認しないと答えられない
IT
情シスの困りごと
- 自動化製品を入れたが、例外パターンが多すぎて結局手作業が残った
- カスタム属性が既存製品のスキーマに収まらない
- 依頼の受付・確認・反映がすべて属人化していて、履歴も追えない
これは連携の問題ではなく、人事情報が“正”になっていないことの結果です。
原因
ID管理の問題は、ID基盤の中にはありません。
4月1日付で営業部に異動する社員がいます。人事はそれを3月上旬には知っています。情シスがそれを知るのは、3月下旬に届く依頼メールです。
メールには「営業部へ異動」と書かれています。書かれていないことがあります。引き継ぎのために4月15日までは前の部署の権限も要ること。兼務が解けるのは6月であること。それは人事の頭の中にあって、依頼メールには載りません。
だから確認が発生します。確認した結果は返信メールに残り、システムには残りません。半年後に「なぜこの人がこの権限を持っているのか」と聞かれても、答えはメールボックスの中を探すことになります。
ID管理製品は入れ物を作ります。足りないのは、その入れ物に何を入れるかを決める情報です。それは人事の側にあって、ID基盤の中にはありません。
設計思想
自動化できなかったのは、
御社が特殊だからではありません。
私たちInnovaXは、Microsoft 365とEntra IDの導入・運用を専業としてきました。その中で、同じ壁に何度も当たりました。
自動化の仕組みを入れても、必ず手作業が残ります。残るのはいつも同じ場所でした。兼務、出向、異動日と実際の切替日のズレ、引き継ぎ期間の重複、旧姓利用。どれも日本企業では当たり前にあるもので、例外ではありません。
それでも例外として扱われてしまうのは、設計の前提が異なるからです。一人が一つの役割を持ち、役割が変われば前の役割は終わる。その前提で作られた仕組みに、兼務や引き継ぎ期間を表現する場所はありません。
HITOBASEは逆から作りました。日本の人事と情シスの実務にあるものを、最初からデータモデルに入れています。
例外を減らすのではなく、例外が例外でなくなる構造にしました。
HITOBASEとは
人事情報を正としてアカウントと権限を運用する、
日本の人事構造に対応したID管理ツールです。
人事の事実を期間として持ち、任意の日で切り、実物と照合する。
3つのモジュール
人事の情報を、そのままのかたちで持ちます。
人事システムの中では、兼務も出向も旧姓も、当たり前に存在しています。それが失われるのは、他のシステムに渡すときです。多くの製品は「1人＝1部署」を前提に設計されているため、渡す側が情報を削って合わせることになります。
HITOBASEのSourceは、削らずに受け取ります。
複数所属を同時に持つ
出向は両方を持ったまま
異動日と切替日を、別々に
過去の任意の時点を再現
例外として扱われてきたものを、標準の状態として持つ。これがHITOBASEの出発点です。
「4月1日付人事異動」を、4月1日にやらない。
現場の段取りは、異動日の前後に広がっています。
5月1日付で営業部に配属される社員がいるとします。現場はメーリングリストも用意しておきたいので、4月の後半には申請を出しておきたい。しかし多くの仕組みでは、登録した時点で反映されてしまうため、当日まで待つか、手作業で対応することになります。
翌年、その社員が企画部に異動するとします。引き継ぎのため、4月15日までは営業部の権限も残しておきたい。しかし切替日を過ぎると、旧部署の権限は一律に外れます。ここでも手作業が発生します。
前者は「早く入れられない」、後者は「きれいに切れてしまう」。方向は逆ですが、どちらも実務では必要です。
手作業が発生していた3箇所。HITOBASEでは、いずれも申請の時点でルールになる。
HITOBASEのFlowは、この2つを申請の時点でルールとして持ちます。
- 適用日を指定して、事前に申請できます。適用日が来るまで反映されません
- 旧部署と新部署の権限を、指定した期間だけ重ねて保持できます
- 誰がいつ申請し、誰が承認し、いつ適用されたかが記録として残ります
手作業で埋めていた前後の期間を、そのままルールにします。
送って終わり、にしません。
人事情報を連携先に送り届けても、そこから先でズレていきます。管理者が直接変更する、退職者のアカウントが消えずに残る、誰かが手作業で追加したグループが誰にも把握されない。連携の問題は、送るときではなく送った後に起きます。
Connectionは、送るのではなく照合し続けます。
常に比較し、差分を一覧に
差分の扱いは選べる
管理する範囲を明示的に分ける
退職時は即時削除にしない
自動化とは、任せきることではありません。何がズレているかが、いつでも分かる状態のことです。
AD廃止の現実解
ADをやめる準備は、日々の運用の中で終わります。
→
Active Directory から Entra ID へ、運用しながら移す
Active Directoryを廃止したい。そう考えていても、実際に踏み切れない理由は決まっています。何が依存しているか分からないからです。
移行プロジェクトを立てて調査から始めると、それだけで数ヶ月かかります。しかも調べた結果は、調べ終えた時点から古くなっていきます。
HITOBASEを使うと、この調査が日々の運用の副産物として手に入ります。
可視化
人事情報とAD・Entra IDの差分が、導入した時点で一覧になります
解消
差分を埋めていく過程で、AD側にしか存在しないものが特定されます
切り離し
何が残っているかが分かれば、移行の計画が立てられます。InnovaXが実装まで支援します
停止
依存がなくなった時点で、ADを止められます
廃止のためのプロジェクトは要りません。運用を続けているうちに、準備が終わっています。
比較
違いは、機能の数ではありません。
所属を何が決めるかです。
| 決め方 | どう決まるか | 起こりやすいこと |
|---|---|---|
| 依頼ベース | 都度の依頼を受けて手作業で追加・削除 | 時間が経つと、誰がなぜ入っているか分からなくなる |
| 属性ルール | ユーザー属性の条件式で自動判定 | 条件式に表せない所属（兼務、引き継ぎ期間）は手作業に戻る |
| 申請・承認 | 申請と承認の結果として付与 | 判断基準が承認者に残る。承認者が替わると基準も変わる |
| HITOBASE | 人事の異動そのものが所属を決める | 異動とグループが常に一致する。根拠を人事情報まで遡れる |
どの方式にも用途はあります。ただ、「なぜこの人がこのグループにいるのか」に答えられるのは、人事情報が起点になっている場合だけです。
導入効果
誰が、何を、なぜ持っているのか。
人事情報から答えが出ます。
| これまで | HITOBASE | |
|---|---|---|
| 入退社・異動の反映 | 依頼を受けて都度手作業 | 異動日に応じて自動適用 |
| 引き継ぎ期間の権限 | 期間を覚えておいて手作業で戻す | 期間を指定して自動で解除 |
| 権限の棚卸し | 台帳とAD・Entraを突き合わせ | 常時照合、差分が一覧に |
| 監査対応 | 依頼メールを遡って探す | 申請と適用の記録がそのまま証跡 |
| ライセンス | 実態が把握できず過剰保有 | 保有状況が人事情報と紐づく |
| 例外的な人事構造 | 個別対応として手運用 | ルールとして定義 |
一つひとつの作業は、たいしたことではありません。グループに追加する。権限を外す。数分で終わります。
重いのは、その前後です。依頼の内容を確認する。返事を待つ。待っている間、その案件は止まったまま自分の頭に残り続ける。実際に手を動かした時間より、待っている時間の方がずっと長い。
HITOBASEがなくすのは、この待ち時間の方です。
導入の流れ
導入は、現状を見るところから始まります。
アセスメント
現在のアカウント・グループ・権限を可視化。人事情報とのズレを一覧化します。ここまでで、棚卸しの結果が手に入ります。
設計
人事情報の構造とタイミングルールを定義。兼務・出向・異動日運用など、自社の実務に合わせます。
接続とテスト
Entra ID・ADと接続し、差分検知を稼働。まずは検知のみで運用し、実態を確認します。
自動適用へ移行
対象を段階的に広げます。手運用のまま残す範囲を選べるので、一斉切替は不要です。
最短4週間で、差分の可視化まで到達します。最初から全部を自動化する必要はありません。まず見えるようにすることが、導入の目的です。
料金
月額300,000円 から
ご利用いただくモジュールと、登録ユーザー数に応じて決まります。
フルプラン
Source ＋ Flow ＋ Connection
標準プラン
Source ＋ Connection
Sourceプラン
Source のみ
- 月額は登録ユーザー数に応じて決まります
- 退職された方の分は課金対象外です。データは履歴として残ります
- 最低ご利用ユーザー数：300名
初期費用 800,000円
先着5社、初期費用無料
2026年12月31日までにご契約いただいた企業が対象です。社名の掲載と導入事例へのご協力が条件となります。
セキュリティ・信頼性
人事情報を預かる前提で作っています。
HITOBASEが保持するのは、氏名、所属、在籍状況、異動の履歴。人事情報そのものです。だから、預かる側の構成を先に公開します。
データの保護
- 保存時の暗号化データベースとバックアップをAES-256で暗号化しています。鍵はAWS KMSで管理します
- 通信の暗号化外部との通信はTLS 1.2以上。内部の通信はプライベートネットワーク内に限定しています
- データの所在東京リージョンで運用します。国外への複製は行いません
テナント分離
- 分離方式顧客ごとにデータベーススキーマを分離しています。アプリケーション層でも接続先スキーマを固定し、他テナントへの参照経路を持ちません
可用性と復旧
- 冗長構成複数のアベイラビリティゾーンに分散配置しています。単一データセンターの障害では停止しません
- フェイルオーバーデータベースは自動フェイルオーバーに対応。切替は通常1分以内です
- バックアップ継続的なバックアップにより、過去7日間の任意の時点へ復旧できます
- RPO / RTO目標復旧時点（RPO）5分以内、目標復旧時間（RTO）4時間以内
アクセス制御
- 認証OIDCによるSSOに対応。既存のEntra IDアカウントでログインできます
- 多要素認証MFAはご利用中のIdPの設定に従います。HITOBASE側で別途の認証を挟まないため、貴社の認証ポリシーがそのまま適用されます
- 権限管理管理者権限は役割ベースで割り当てます
- 操作記録管理操作はすべて記録されます
記録と証跡
- 監査ログ誰がいつ何を変更したかを1年間保持します
- 証跡としての利用申請・承認・適用の記録と併せて、監査でそのまま証跡として使えます
運用体制
- 社内規程情報セキュリティ規程を整備し、全従業員に教育を実施しています
- インシデント対応発生時は24時間以内に第一報をお伝えします
- 脆弱性管理実行環境の脆弱性を継続的に自動スキャンし、検出内容に応じて対応します
- 解約時のデータ解約後30日間はデータを保持し、この間はエクスポートが可能です。30日を過ぎるとアクセスできなくなり、90日で完全に削除します
- 詳細資料セキュリティチェックシートは、秘密保持契約の締結後にご提供します
想定ユースケース
こんな状況に置かれている企業に向いています。
日々のやり取りが常態化している
- 入退社・異動のたびに、人事・総務・情シスの間で依頼メールが往復している
- 内定者や入社前のアカウント準備で、毎回個別に依頼が発生している
- 「この人は結局どうなりましたか」という確認が、月に何度も発生している
手作業でしか埋められない部分が残っている
- 引き継ぎ期間の権限を、毎回手作業で付けて外している
- 自動化の仕組みを入れたが、例外が多くて結局手運用が残った
- 兼務・出向が常態化しており、1人1部署では表現できない
規模とタイミングに無理がある
- 4月に一斉異動があり、年に一度のピークのために通年の体制を確保している
- 情シスが1〜2名で、ID運用が特定の人に依存している
- グループ会社が複数あり、出向・転籍が頻繁に発生する
説明を求められている
- 監査で「なぜこの人がこの権限を持っているのか」を問われ、答えられなかった
- 退職者のアカウントやライセンスが残っていると分かっているが、棚卸しに手が回らない
- ADを残したまま廃止の道筋を立てたいが、何が依存しているか分からず着手できていない
よくあるご質問
FAQ
Active Directoryを使っていませんが、導入できますか。
はい。HITOBASEは人事情報を正としてID基盤を運用する製品で、AD廃止はその応用の一つです。Entra IDのみの環境でも、入退社・異動の自動化と権限の棚卸しはそのまま機能します。
どのサービスと連携できますか。
Entra ID、Active Directoryに対応しています。Google Workspace および Okta は、2026年12月頃の対応を予定しています。その他のサービスについては個別にご相談ください。
ファイルやフォルダのアクセス権も管理できますか。
HITOBASEが管理するのは、グループへの所属とロールの割り当てです。個々のフォルダやサイトに対するアクセス権は、それぞれのサービス側の設定になります。ただし多くの場合、アクセス権はグループ単位で設定されているため、所属が正しく保たれていれば結果としてアクセス権も正しく保たれます。
人事システムを入れ替える必要はありますか。
ありません。既存の人事システムからCSVまたはAPIで情報を受け取ります。人事側の運用を変えずに導入できます。
一部の部署から試すことはできますか。
できます。HITOBASEが管理する対象と管理しない対象を明示的に分けられるため、範囲を限定して開始し、段階的に広げられます。
退職者のデータはどうなりますか。
履歴として保持されます。過去の任意の時点で「誰がどこに属していたか」を再現できるため、監査対応で遡って確認できます。なお課金対象からは外れます。
提供元
現場で作ってきた人間が、現場のために作りました。
株式会社InnovaXは、Microsoft 365とEntra IDの導入・運用を専業とする会社です。製薬、不動産、製造業の大手企業で、ゼロトラスト環境の設計とID基盤の構築を担ってきました。
HITOBASEは、その現場で繰り返し当たった壁から生まれています。自動化の仕組みを入れても手作業が残る。残る場所はいつも同じ。その場所を埋めるために作った製品です。
株式会社InnovaX