「構成員情報管理システム一式

仕様書」

構成員情報及び統合ID管理システム一式仕様書案（意見招請）からの主な変更点

仕様書案（意見招請）

主な変更点

I.仕様書概要説明

1.調達の背景及び目的一橋大学（以下 、 「本学」という。） では、教職員、学生、その他本学に関係する職員等の人的な情報を集約し、 ID 情報等の一意性を担保すると共に、情報のライフサイクルをリアルタイムで管理するために、人事給与シ

統合ID管理機能、サービス連携管理機能、ICカード管理機能及び学術認証フェデレーション連携管理機能を

ステム及び学務情報システムと一体となって本学の構成員に関する属性情報を管理する仕組みを構成員情報管理システムとして構 実現するシステムは別に調達することとし、本仕様書
築し運用している。 また、本学の構成員が使用する各種情報システムのユーザー 認証情報を統括するシステムを統合認証システ
ムとして構築、運用している。

からは削除しました。

さらに、本学の職員証及び学生証等について、構成員情報管理システムから構成員のID 及び属性情報を受信し、職員証等の発行委託データの作成、発行データの取込みを行うシステムを IC カード管理システムとして構築、運用している。
本調達は、本学構成員のID 、属性情報、アカウント、 IC カードの各管理機能向上及び運用負荷の軽減を目的として、構成員情報管理システム、 統合 I D 管理 システム及び IC カード管理システムを 1 つの アプリケー
ション システム の機能として、 一体的に更新することを目的とするものである。

2.調達内容調達内容を構成員情報管理システム一式に変更しまし構成員情報及び統合 I D 管理システム 一式

た。
構成員情報管理機能、共通機能のみとしました。

（構成内訳）（1）構成員情報管理 機能（2）統合 I D 管理機能
（3）サービス連携管理機能（4）IC カード管理 機能（5）学術認証フェデレーション連携管理機能（6）共通機能
3.調達の種類
購入（導入 及び５年間の 保守 ・ 運用等の役務を含む）
II.全般的要件
1.納入場所及び納入期限
納入場所は、 本 学国立キャンパス 及び別途調達のパブリッククラウドに構築する仮想基盤
1.1.

（以下、「クラウド基盤」という。）上 とする 。

1.2.

納入期限は、 2025 年 9 月 3 0 日（火） とする。

協議の上、指定するパッケージ等のライセンスにかか指定する期日までに、本 アプリケーション システム （以下、「本システム」と言う。 構築に関わるすべての作業を
1.3.

終え、本学の希望する状態にすること。すべての機能についての 稼働を確認し受入検査が完了していることを想定する。

2.納入（ 導入 、調整等）に関すること
本案件に関する作業において、打合せ、現地調査 ・作業 、資料搬入等で作業員が本学に出2.1.

入りする場合は、必ず事前に作業員の所属する組織名、組織の住所及び組織の代表電話番号に加えて、各作業員の所
属部署、役職、氏名、連絡先（直通電話番号、電子メールアドレス等）を本学に対して通知又は申請し、本学の承認を得ること。本学立入り後は本学の2.2.

指示に従うこと。
本案件に係る作業用資源（機器類等）、作業場所、その他必要となる環境や費用については、受注者の負担で用意す
ること。

2.3.

受注者が故意又は過失により、本学の建物、機器類等の一部又は全部を、 滅失 又は毀損した場合は、受注者が直ちに原状に復すること。

2.4.

本システムの設計、構築、初期設定、動作テスト及びバックアップイメージの作成、すべての納入品の搬入はすべて受注者が責任をもって実施し、 本 システムの稼働確認を行って報告すること。なお、これらに要する費用はすべて本調達に含まれる。
本学ネットワークとの接続に付帯する設定、調整はすべ て受注者が責任をもって実施すること。 ただし 、接続に関する実作業については、受注者は保守・運用業者及び本学と協議・調整の上、本学の指示

2.5.

により行うこと。なお、これらに要する費用はすべて本調達に含まれる。また、本学ネットワークとの接続に際しては、本学ネットワークの運用に支障のないよう配慮すること。

る納入期限を別途設定することとしました。

本システムを実装する クラウド基盤 については、 本システムと同じ令和７年10月１日（水）より運用を開始する。
2.6.

これに先立ち、同 6 月２日（月）～ 9月30日（ 火 ）の 4 か月間を本調達に係る構築作業のための利用期間とする。
この日付は クラウド基盤 の構築作業の状況により前後することがある。

本システムを実装する サーバー の OS のライセンス のうち 、 Microsoft Windows Server 及び Red Hat Enterprise
2.7.

Linux Server については、 クラウド基盤を構築する業者が調達する 。また、 これらの OS のインストールについてもクラウド基盤を構築する業者 が行うが、 OSの設定及び調整は受注者が責任をもって実施すること。

本システムのミドルウェア、アプリケーション等ソフトウェア（導入作業期間のみ必要となるものを含む 。 ）のインストール、設定及び調整はすべて受注者が責任をもって実施し、利用可能な形で提供すること。ライセンスやインストールメディア等、これらに要する物
品及びその費用はすべて本調達に含まれる。ただし、 DBMS のうち、 本システムで必要で あり、かつ PaaS 構成を2.8.

選択できる 場合においては、 Oracle Database については クラウド基盤を構築する業者が 用意する 設定及び調整
は、他のミドルウェアと同様に本調達の受注者が行う。） 。また、 本学が所有する マイクロソフト社の EES/Microsoft 365 Education A3 プログラムに標準的に含まれるライセンス については、受注者がこれを利用してシステム構築をしてもよいものとする。
本学では 、 統合 I D 管理 システム に当たるアプリケーションソフトウェアとして、エクス ジェン・ネットワークス
株式会社「 LDAP Manager 」を使用して いる。所有する 「 LDAP Manager 」の ライセンス については 、 下記一

2.9.

覧のとおりであり、これらを 継続して使用することができる 。 また、 本システム導入に際し、 「Ⅲ Ⅲ. アプリケー「LDAP Manager」は統合ID管理機能にかかるアプリ
ケーションソフトウェアのため、削除しました。

ションソフトウェア」で示す 検証環境で使用する冗⾧化ライセンスを含め、 ライセンス等 で不足する 分があった場
合には、 本調達に含めること 。

2.10.

受注者は 本 システム 導入後、仕様に定められた機能、性能であることを本学担当者の立ち会いのもとで確認すること。

3.情報セキュリティ要件
受注者が実施する作業、構築するシステム、提示する納入物等、受注者の責任範囲にある役務、物品及びシステムに3.1.

対して、受注者は本仕様書の要件及び本学の指示に基づいて責任を持ってセキュリティ対策を実施すること。かかる諸経費は受注者で負担すること。
受注者はシステム構築後にセキュリティ専門サービスを提供する第三者によるプラット フォーム診断（ポートスキャ
ン、サービスの情報取得・挙動確認、アプリケーションの脆

3.2.

弱性、脆弱点やアクセス可能ポートに対する侵入等）を実施し、本学に報告書を提出すること。また、運用に支障のない軽微な脆弱性及び本学が許容すると認めたもの以外の脆弱性については対応を行うこと。

3.3.

導入時にセキュリティ対策を行わなかった結果、本学のシステム又はサービスに影響が出る事態が発生した場合は、受注者の責任を問い、本学から受注者に対して損害賠償を求めるものとする。

受注者が実施する作業、構築するシステムが影響を及ぼす可能性がある他の役務、物品及びシステムに対して、受注
3.4.

第三者によるプラットフォーム診断及びWebアプリ
ケーション診断は、本学で別途調達することとしたた
め、記載を変更しました。
第三者によるプラットフォーム診断及びWebアプリ
ケーション診断は、本学で別途調達することとしたた
め、削除しました。

者が事前に予測できる範囲内で、本学に対して本仕様書の要件に基づくセキュリティ対策の提案を行うこと。
受注者は、 本 システムが構築中であるか完成であるかといった状態にかかわらず、 本システム及び各ファイルの信頼性とセキュリティを十分に考慮して、以下のセキュリティ対策 を施し、 本システムへの不正侵入や攻撃、ウイルス

3.5.

感染等への防止に万全を期すること。また、 本 システムに関する開発、導入等の一連作業においても、受注者は以下のセキュリティ対策を行うこと。詳細については、受注者と本学で協議して決定すること。
本学からセキュリティポリシー等の提示があった場合は、本学からの提示要件を優先してセキュリティに係る設計を

3.5.1.

行うこと。 不正アクセス及び悪意のあるソフトウェアによる情報の誤用、破壊、破損、改ざんからシステム及びデー
タを保護するとともに、他のシステム及びネットワークに影響を及ぼすことのない仕組みを持つこと。

システムの動作に必要のない IP アドレスや通信ポートからのリクエストを遮断すること。 導入するアプリケーショ
3.5.2.

ンソフトウェアのみならず、本調達に含まれない OS 並びに Oracle Database 及び Microsoft SQL Server DBMS に
ついては、本調達で必要となった場合に限る。） についても、設定を行うこと。

3.5.3.

許可しない ユーザー に不正に侵入されない仕組 みを持つこと。

3.5.4.

コンテンツ、ログ、設定、環境等を改ざんされないよう対策を講ずること。

3.5.5.

セキュリティホールが発見された場合は、パッチ、サービスパック、レベルアップ等の適用といった必要な対策情報を提供し、本学が実施する作業の支援を行うこと。

Microsoft SQL Server DBMSについての記述を削除し
ました。

3.6.

セキュリティ事件、事故及びセキュリティの違反については、本学に速やかに報告し、本学の指示に従って対応を行うこと。
受注者は、 契約不適合責任期間中、上記の対策を講じているにもかかわらず、セキュリティ侵害、各種攻撃、ウイル

3.7.

ス感染又はそれらが推測される兆候があった場合は、本学と協議の上、速やかに必要な作業、対策を講じ、サービスを維持すること。

3.8.

本システムへのアクセス記録が採取可能であり、必要に応じて参照及び電子データ出力が行えること。

3.9.

本学の情報処理設備及び施設の利用は、本学が承認したアクセス方法及びアクセス制御によること。

3.10.

受注者は、個人情報の取扱いについて適切な保護措置を講ずる体制を整備しており、 ISO/IEC 27001 JIS Q 27001 ）「情報セキュリティマネジメントシステム ISMS ）」認証又はプライバシーマーク認定を取得済であること。

3.11.

個人情報の管理 の状況 について、本学の調査に協力すること 。

3.12.

暗号化の際に使用する暗号アルゴリズムについては、「電子政府推奨暗号リスト」を参照し決定することが望ましい
。

3.13.

受注者が本調達・役務内容の一部を外部に再委託する場合は、 本学の了解を得なければならない。また、 再委託されることにより生ずる脅威に対して、情報セキュリティが十分に確保されるよう本仕様書と同水準の措置の実施を担保すること。

4.守秘義務及び厳守事項
4.1.

受注者は、案件及び案件に関連する役務過程において知り得た案件に関する一切の情報（以下、「案件に関する情報」という。）につい て、次の義務を遵守すること。

4.2.

故意又は過失にかかわらず、案件に直接従事する担当者であることを本学が書面にて認めた者以外の者（以下、「他者」という。）に案件に関する情報を漏らさないこと。
案件の履行に関連して知り得た本学の秘密情報の加工、改ざん、複写、複製等をしてはな

4.3.

らない。ただし、委託契約の範囲内のものや安全管理上必要なバックアップを目的とする

4.4.

契約中は、案件に関する情報の取扱いに十分留意し、他者に情報を開示しないこと。

4.5.

契約終了後は、案件に関する情報を返却し、又は確実に破棄するとと もに、本学の書面による許可なく案件に関するものはこの限りではない。

情報を他者に開示しないこと。
案件に関する情報を知り得た者が、異動、転職、退職等の事由によって案件と無関係になった場合でも、本学の書面
4.6.

による許可なく案件に関する情報を他者に開示させないこと。

4.7.

万が一受注者先において秘密情報の漏えい等の事故が発生した場合は、直ちに本学へ報告し、また、受注者先が責任をもって対応すること。
本学秘密情報の取扱いにおいて、再委託をする場合は、本学の了解を得なければならない。本システムの開発及びカ

4.8.

スタマイズに関して、業務の再委託を行う場合は、 委託先企業に

4.9.

その他、本学の指示に基づいて守秘義務を全うすること。

ついても本義務を遵守させること。

5.その他
5.1.

技術仕様等に関する留意事項

5.1.1.

提案書は日本語で具体的に記述すること。

5.1.2.

本調達物品に係る機能、 性能、技術等の要求要件（以下、「技術的要件」という。）は、「 Ⅲ. 調達物品に備えるべき技術的要件 」に示すとおりとする。

5.1.3.

技術的要件は、すべて必須の要求要件とする。技術的要件を満たしていないと判断される提案は、不合格とし落札決定の対象から除外する。

5.2.提案に関する留意事項
現有のシステムとの総合運用性又は本調達に含まれないソフトウェアの動作保証を要 求する要件については、本学よ5.2.1.

り必要な資料を入手し十分な調査検討を行った上で提案すること。

5.2.2.

提案書には、本仕様書の要件の各項目とそれに対する提案内容を明確かつ簡潔に示した対照表を添付すること。

5.2.3.

提案書には以下の項目を明瞭に記載すること。

5.2.3.1.

システムの全体構成

5.2.3.2.

本システムを構成する ソフトウェア （ミドルウェア等を含むの構成、規格、性能等に係る資料

5.2.3.3.

本システムを構成する ソフトウェア （ミドルウェア等を含むの仕様と機能要件を満たしていることを示す具体的資料

5.2.3.4.

本システムを構成する ソフトウェア （ミドルウェア等を含むの稼働実績を求める項目については、実績を示す資料

論理ネットワークの構成・機能等に関わる資料
5.2.3.5.

特に論理ネットワーク構成については、グローバル・プライベート・ DMZ 等の別を明示的に示すこと（ネットワークアドレスは仮のもので示せばよい 。 ）。
導入の作業日程 （詳細な日程があることが望ましい（データ連携する他システム構築業者 （人事給与システム、学務 データ連携する他システムに統合ID管理システムを追情報システム、図書館システム、入退システム、文書管理システム、各種認証システム）との打合せ等を含5.2.3.6.

む。）。）と体制（再委託する場合は委託先の体制も含む。導入に係る構成メンバーの業務経歴があることが望まし

5.2.3.7.

保守・ 運用支援計画に係る資料 （体制図、人員数等）

5.2.3.8.

その他、提案内容を説明するために必要な資料

5.2.4.

提案書に疑義が生じた場合、詳細な資料の提出を求めることがある。また、必要に応じ、提案物品についてサンプル加しました。

い。）、受注者側と本学側の作業の区分の提供やデモンストレーションの実施を求めることがある。
5.2.5.

提出要領

5.2.5.1.

提出先及び提出期限は入札説明書を参照すること。

5.2.5.2.

紙媒体で 3 部、電子媒体で 1 部提出すること。

5.2.5.3.

電子データを格納する媒体の種別は CD-R 又は DVD-Rとする。また 、 データの形式はマイクロソフト社の Oﬃce 製
品 のものとする 。

5.2.5.4.

納入媒体及びデータについては、ウイルス等を混入させないように、納入前に受注者側で責任を持ってチェックを行うこと。
紙媒体でしか納入できないもの（手書き図面等）又は電子データのみで納入

5.2.5.5.

する方が効率的であるもの（膨大なログデータ等）の納入方法については、受注者と本学が協議

5.2.5.6.

問合せの受付については、入札説明書を参照すること。

5.3.

著作権に関する留意事項

して決定すること。

受注者は、本業務の目的として作成される成果物に関し、著作権法（昭和 45 年法律第 48 号）第 27 条及び第 28 条
5.3.1.

を含む著作権の全てを本学に無償で譲渡するものとする。

ないものとする。ただし、本学が承諾した場合は，この限りではない。

5.3.3.

ました。
「5.3.4.受注者は、本業務の目的の範囲において本学が受注者著作物を利用、複製、公衆送信、翻訳、翻案

受注者は、成果物に関する著作者人格権（著作権法第 18 条から第 20 条までに規定された権利をいう。 ）を行使し5.3.2.

著作権に関する留意事項について、以下の項を追加し前2項に関わらず，成果物に受注者が既に著作権を保有しているもの（パッケージソフすることを許諾するものとする。ただし、プログラムの著作物はその目的の範囲において利用のみとする。」

トウェア含む 。 ）（以下 、「受注者著作物」という。）が組み込まれている場合は，当該受注者著作物の著作権についてのみ、受注者に帰属する。

5.3.4.

提出される成果物に第三者が権利を有する著作物が含まれる場合には、受注者が当該著作物の使用に必要な費用の負担及び使用許諾契約等に係る一切の手続きを行うものとする。
5.4.その他の留意事項
本 システムの本稼働後1年間に、本システムを構成する ソフトウェア、システム構成、作業等に契約不適合があった
5.4.1.

場合、本学はこれらの修復、再作業に加えて、本学が被った損害の賠償を求めることができるものとする。

「本システムの本稼働後1年間に」を「契約期間中」に変更しました。

本システムの稼働期間は、5年間を予定しており、本稼働後 5 年間までの保守の費用を本調達に含むこと。 期間中の5.4.2.

保守及び運用支援のほか 、運用条件の変更を行う際のシス
テム改修の検討などの支援体制を確保すること。

5.4.3.

各種設定及び登録は本学担当者と打合せの上実施すること。

5.4.4.

受注者が自社製以外の製品を納入する場合、受注者は一元的な窓口となり、自社製以外の製品についても自社製品と同様の保証をすること。

5.5.仕様変更及び未定義事項

5.5.1.

案件を遂行する上で役務内容、仕様 若しくは 条件に疑問点や変更が生じた場合又は本仕様書に記載のない内容の案件が生じた場合、受注者は直ちに本学と協議し、解決に向けて最善の努力を行うこと。

III.調達物品に備えるべき技術的要件
1.アプリケーションソフトウェア
以下に構成員情報管理機能 、一橋認証アカウント管理機能、サービス連携管理機能、 ICカード管理機能 及び共通機能 の技術的要件を示す。 これら機能 については、 単一のアプリケーションソフトウェア で構築する 必要はなく 、複数のアプリケーション
ソフトウェア を相互に連携し構築しても構わない。その場合、連携に齟齬が出ないよう設計を行うこと。
また、本アプリケーションソフトウェア は、クラウド基盤に構築する ことができる 。リソース は以下を上限とし、 また、本番
環境及び検証環境で システムを滞りなく動作させること。 【以下は例示であり、本件意見招請においてご提案をいただきたい。】

一橋認証アカウント管理機能、サービス連携管理機
能、ICカード管理機能を削除しました。

・本番環境：ＣＰＵ ６コア
メモリ １６ＧＢ

サーバーリソースに関する情報を更新しました。

ＨＤＤ ８００ ＧＢ
・検証環境：ＣＰＵ ４コア
メモリ １２ＧＢ
ＨＤＤ ５００ ＧＢ

1.1.導入実績に係る前提条件
本調達に係る受注者又は再委託先が、 本学と同規模 令和５年 5 月 1 日現在、 教職員数 約 500名、学生数約 6,000名以上の国立大学法人 、公立大学法人 又は 私立大学のいずれかにおいて、認証基盤アカウント管理、各種認証システムとの認証情報の連携、システムとのデータ連携等及び認証基盤に関係するアプリケーションソフトウェア 教職員、学生、その他本学に関係する職員等の基本情報と各種サービス提供履歴を管理する 機能等） の 開発又は導入をした実績 （再委託先としての実績含む。） が「教職員及び学生の情報管理に関係するアプリケー
ションソフトウェアの開発又は導入をした実績」に変更しました。

あり、開発又は導入をしたシステム概要を提示できること 。

1.2.構成員情報管理機能
教職員、学生、その他本学に関係する職員等（以下、「構成員」という。）の基本情報と各種サービス提供履歴を管理する機能とする。本機能は、構成員の基本情報を提供する人事給与システ
ム及び学務情報システム（以下、 「 上位システム 」 と 呼ぶ 。） からデータを受信し、その基本情報に基づく各種データを必要とする下位システムにデータ送信を行う。構成員は、 時系列又は同時期に複数の身分を持つ場合でも同一人の特定を行い、 1 人の構成員に集約する。 構成員情報管理機能は 1人の構成員に対し唯一の IDを付与し 、この ID を一橋 ID と呼ぶ。
1.2.1.全般的要件
本学に所属・関係する全ての構成員を一元管理するために構成員 情報 管理機
1.2.1.1.

能を提供すること。構成員 情報 管理機能は、構成員情報を保持するデータベ
ース機能、及びその情報をメンテナンスするための各種連携機能や Web GUI等によるメンテナ
ンス機能を有すること。

構成員情報管理機能では、構成員を一意に識別するための一橋 ID を発行する。一橋 ID は生涯 ID とし、構成員の退職や卒業後も保持し、後に同一人物の採用や入学があった場合には、身分の変更があった場合も含め、既に付与され1.2.1.2.

IDの数を令和６年６月現在の数字に更新しました。

ている一橋 ID を引き続き識別に用いること。 なお、令和６年３月現在の一橋 ID の数は、約 32,000 件（うちアクティブな一橋 ID は約 11,000 件）
である。
構成員情報管理機能は、人事給与システムから人事課が管理する教員及び事務職員等の構成員基本データを、学務情報シ ステムから教務課が管理する学部生及び大学院生等の構成員基本データを受信 し、この情報を元に構成員情報の1.2.1.3.

新規登録や更新などを行う。

構成員のうち上位システムからデータが提供されない名誉教授、 派遣職員 、委託職員等の職種については、 直接登録対象者としてそれぞれの構成員の所管部署の担当者が Web GUI 等により構成員基本データの登録、更新などを可能
1.2.1.4.

とする 。

新たに構成員情報が登録された場合は、本学が提供する各種情報システムやネットワークサービスを利用するための1.2.1.5.

アカウント（一橋認証アカウント）を発行すること。

一橋認証アカウントは、構成員情報の異動に合わせてアカウントの有効・無効や、所属、職務、職種に応じた各種シ
1.2.1.6.

ステム利用やアカウント情報連携の可否権限の付与・剥奪が行われるものとする。

別調達の機能とするため、削除しました。

別調達の機能とするため、削除しました。

上位システム からの連携情報以外による構成員情報管理 、 一橋認証 ID に付随するアカウント情報の生成、下位シス 削除しました。
テムあるいは利用者が必要とする情報など（その他情報と呼ぶ）を管理するための インターフェース を備え 、 CSVファイルなどによる一括更新が可能
1.2.1.7.

であること 。その他情報は一橋 ID にて
構成員情報と紐づけられるようにすること。 なお、その他情報 については、現在のところ「科研費番号」を想定しているが、 その他情報 として将来使用するデータ項目 枠を 10 項目 以上 用意すること。

1.2.2.上位システムデータ受信 の基本要件
各上位システムのあらかじめ定められたデータフォーマットに応じた構成員基本データを自動受信し、構成員情報管
理機能内部に保存する。データフォーマットは下位システムからの要望により仕様や項目の変更が発生する可能性が高いため、データフォーマットの変更に柔軟に対応できること。 提案にあたっては変更対応できる範囲と別途契約と1.2.2.1.

なる基準あるいは例を明示すること。 データ受信処理は原則、日次 1 回自動運用とする。
また、業務上の都合により随時データ受信処理が実行できる仕組みを用意すること。

データ受信の際は、あらかじめ定められたデータ インターフェース 要件に基
1.2.2.2.

づくデータチェックを実施すること。 データチェックは構成員情報単位に実 施し、 チェックの 結果、要件外のエ
ラーを検知した場合は、 当該情報のみ 構成員情報管理機能内部へのデータ保存を中止し、そのエラー内容を記録すること。

データフォーマットについての記載を変更しました。

データチェック仕様についてはデータ インターフェース 詳細設計時に確定すること。 想定するデータチェックは、
1.2.2.3.

値の指定有無（必須チェック）、文字数（最小・最大）、文字種、選択値（値の候補が予め定められている）とする 。

1.2.3.人事給与システムとの送受信連携
人事給与システム から のデータ受信連携については、 人事給与システムで作成した View を参照して 連携すること。具体的な方法については、本学及び人事給与システム 受注 者と協議の上、決定すること。 また、別の連携方式
1.2.3.1.

を提案する場合は、本学及び人事給与システム受注者と協議の上で採用することとする。
人事給与システムへのデータ送信連携については、本システムで作成した

1.2.3.2.

View を用いて連携すること。具体的な方法については、本学及び人事給与システム 受注 者と協議の上、決定すること。 また、別の連携方式を提案する場
合は、本学及び人事給与システム構築業者 と協議の上で採用すること。

人事給与システムから送信されるすべての人事発令データ及び各種マスターデータを受信できること。 参考として、
現在連携している人事発令データ及び各種マスターデータ を下記に例示する。
・人事発令データ
作成年月日、一橋ID 、職員番号、戸籍）漢字氏名、戸籍）カナ氏名、漢字 氏名、カナ氏名、旧姓）漢字氏名、旧姓）カナ氏名、生年月日、性別区分コード、採用・任用年月日、退職年月日、任免区分コード、任免区分、系区分
コード、系区分、所属コード、所属名称、職種区分コード、職種区分、係講座区分コード、係講座区分、発令年月日、任免異動種目区分コード、任免異動種目区分、送信フラグ、常勤・非常勤区分コード、任期満了日、職員証発行
区分コード、 キャンパス区分コード、キャンパス区分、削除フラグ、 名寄せ実施有無
1.2.3.3.

・所属マスタ
コード、名称、ソート順、開始日、終了日
・職種マスタ、人事区分マスタ、任免区分マスタ、係講座マスタコード、名称、開始日、終了日

1.2.3.4.

人事発令データについては、人事発令単位に指定された「名寄せ実施有無」の内容から名寄せ処理の実行を制御し、名寄せを行わない場合は構成員情報の新規登録を行うこと。

２回目以降の連携となる人事発令データにて一橋 ID を指定できるよう、職
員番号と一橋 ID の関連付けを示す一橋 ID 情報を 「Ⅲ 1. 2.3.2. 」 で示す人事給与システムが読み込み可能な View
1.2.3.5.

を 用いて 、人事給与システムに 提供する。 また、別の 連携方式を提案する場合は、本学及び人事給与システム構築
業者の了解を得た上で採用すること。
前項に記載した 一橋 ID 情報のデータ 項目 は以下のとおりとする。

1.2.3.6.

職員番号、一橋 ID 、 データ開始日

1.2.4.学務情報システムからの送受信連携
学務情報システムからの受信データ項目は以下のとおりとする。
学籍番号、受験番号、学生区分、在学区分、学部、研究科、専攻、コース、分野、入学年月日、有効期間終了日、卒1.2.4.1.

業予定日、学年、生年月日、氏名、カナ、英字氏名、性別、 キャンパス区分、 現在住所、現住所郵便番号、券面
用所属名、券面用住所、 E Mail アドレス、連絡先電話番号、連絡先携帯電話、帰省先電話番号、帰省先住所、帰省
先郵便番号、一橋 ID 、強制新規フラグ

学務情報システムから、学生（学部生、大学院生）に関するデータを受信できること。データを受信する際には、名寄せ機能の使用有無を個人別に指定できること。 データを受信した際の処理の流れを下記に示す。
・受信したデータの「一橋ID 」の項目が空白 かつ 「強制新規フラグ」がないデータを受信した場合、構成員情報管理システムは名寄せ機能を実施する。 名
寄せ候補者が存在する場合は、対象データをエラーとして処理し、学務情報 システムに名寄せ候補者情報を送信する。 具体的な方法は、「Ⅲ.1. 2.6.2 」を参照すること。
1.2.4.2.

・受信したデータの「一橋ID 」の項目が空白 かつ 「強制新規フラグ」があるデータを受信した場合、構成員情報管理システムは 新規の「一橋 ID 」を 発行 する。
・受信したデータの「一橋ID 」の項目に 「 一橋 ID 」 が記載されている場合は、「一橋 ID 」に属する情報を正常に取り込む。

1.2.4.3.

学生に対し、「 一橋 ID 」 を新規に発行した場合は、その 「 一橋 ID 」 を学務情報システムへ送信すること。送信
データの項目は以下のとおりとする。
一橋ID 、学籍番号、データ開始日

1.2.4.4.

学務情報システムとのデータ連携は CSV 形式 とすること。 別の データ形式を提案する場合は、本学及び学務情報システム受注者と協議の上で採用することとする。

学務情報システムへの教職員情報連携を追加しまし1.2.5.構成員情報の直接登録機能た。

直接登録 対象 者を構成員情報管理 機能 へ登録する際は、構成員基本情報（氏名、生年月日、性別、所属、職務、採1.2.5.1.

用日、退職予定日）を入力する。入力 インターフェースは画面とすること。
直接登録 対象者は常に新規登録だけでなく、 複数の身分 ・所属 を持つ者を想1.2.5.2.

1.2.5.3.

定し、既存の構成員情報に対し身分・所属を追加（新規発令）登録も可能なインターフェースを提供すること。 この操作を行った場合、１つの一橋IDに
対し、複数の身分・所属情報が保持される。
直接登録機能により登録された身分・所属に限り、発令の訂正、取消ができること。

1.2.6.名寄せ機能
人事給与システムからのデータ連携において直接登録者を登録する際には、登録対象者が既存の構成員と同一人物であるか否かの判断ができる名寄せ候補者情報を提供すること。名寄せ候補者は漢字氏名 （旧姓情報含む 、英字氏
名、カナ氏名、生年月日が今回登録対象者の項目と一致している者とする。情報提供の方法は 本システムで作成したView による提供とし、人事給与 システムからコマンド送信があった際に名寄せ候補者を View に表示する。 また、
1.2.6.1.

別の連携方式を提案する場合は、本学及び人事給与システム構築業者の了解を得た上で採用すること。 名寄せ候補者の項目一致基準は部分一致 とし 、
この基準は柔軟に変更可能な仕組みとすること。

学務情報システムからのデータ連携において、 直接登録者を登録する際には、登録対象者が既存の構成員と同一人物であるか否かの判断ができる名寄せ候 補者情報を提供すること。名寄せ候補者は漢字氏名 （旧姓情報含む 、英字氏
1.2.6.2.

名、カナ氏名、生年月日が今回登録対象者の項目と一 致している者とする。 情報提供の方法は CSV 形式での連携
データ 出力とする。名寄せ候補者の項
目一致基準は部分一致 とし 、この基準は柔軟に変更可能な仕組みとすること。
構成員情報管理機能において直接登録者を登録する際には、登録対象者が既存の構成員と同一人物であるか否かの判断ができる名寄せ候補者情報を提供

1.2.6.3.

すること。名寄せ候補者は漢字氏名 （旧姓情報含む） 、英字氏名、カナ氏名、生年月日が今回登録対象者の項目と一致している者とする。情報提供の方法
は画面表示とする。名寄せ候補者の項目一致基準は部分一致 とし 、この基準は柔軟に変更可能な仕組みとすること。

1.2.7.一橋 ID の決定（構成員の特定）上位システム担当部署は、構成員情報管理機能が提供する名寄せ候補者情報を基にして最終的な同一人決定判断を行う。上位システム担当部署が新規情報を構成員情報管理 機能 へデータ送信する際には、既存構成員の存在有無を
1.2.7.1.

既知とした 「Ⅲ 1. 2. 7.2 」 及び 「Ⅲ 1. 2. 7.3. 」 で示す 名寄せ処理 モードを指定できること。
上位システム担当部署が同一人の構成員が存在すると判断する場合は 、 上位システム担当部署が既存構成員の一橋

1.2.7.2.

ID を指定することにより、構成員情報管理機能はその構成員情報の追加更新処理を実施すること 。

上位システム担当部署が 同一人の構成員が存在しないと判断する場合は 、 上位システム担当部署が 新規登録処理を
1.2.7.3.

1.2.7.4.

指定することにより、構成員情報管理機能は新規の一橋 ID を発行してその構成員情報の新規登録を実施する こと 。

上位システムからのデータ受信により構成員情報管理機能が新規に一橋 IDを発行した場合は、その上位システムへその一橋 ID を通知する目的でデータ送信する こと 。
直接登録対象者については、その登録担当部署が構成員情報管理機能へデータ登録を実施する際に 、 構成員情報管

1.2.7.5.

理機能が提供する名寄せ候補者情報を基に同一人構成員の存在をその登録担当部署 確認した後に、一橋 ID の決定を行えるようにすること 。

1.2.7.6.

一橋 ID の配番ルールは 、本学が別途提供する 「一橋 ID 付与規則について」によること。

1.2.7.7.

一橋 ID の配番時に、全学統合認証に用いる一橋 認証 ID を発行し、その初期パスワードを生成すること。初期パス
ワードに使用する文字種、桁数等については、本学の承認を得て決定すること。

1.2.7.8.

一橋認証 ID の発行は、一橋 ID に対し 原則として １つのみとする。

別調達の機能とするため、削除しました。

一橋認証 ID に付随するアカウントの状態や各種システム利用やアカウント

制御フラグは別調達の機能とするため、削除しまし

情報の連携を制御するフラグ（ 以下 、 「 システム利用可否フラグ 」 と呼ぶ 。は 、構成員が身分・所属を条件に一定の規則で決定する。将来的に条件変更が発生しても対応できる仕組みを有すること。また、一橋認証 ID の発行対象となる構成員が 複数の身分・所属を持
1.2.7.9.

つ場合は、主たる身分・所属でシステム利用可否フラグが設定されるものとする。なお、主たる身分・所属は、構成
員情報の閲覧画面で選択できること。一定の規則で設定されるシステム
利用可否フラグ以外で利用を要望するシステムが有る場合は、 「Ⅲ.1. 3.5. 」 で示すワークフロー機能で申請が可能とし、最終承認をもって付与できるものとする。

1.2.8.構成員情報データベース機能
1.2.8.1.

別調達の機能とするため、削除しました。

構成員情報を保持するデータベ ース 等 以下 、 「 構成員情報データベース 」 と呼ぶ。 ）を持つこと。

た。
また、記述を変更しました。

構成員情報データベースでは、最新の構成員情報と過去の更新情報をそれぞれ保持する。過去の更新情報は、上位シ
1.2.8.2.

1.2.8.3.

ステムから異動（変更）情報が連携された場合や、直接登録機能による登録・更新操作が行われた場合にその時
点での情報を保持する。
構成員情報データベースに登録された情報は原則削除せず、保持し続ける。

1.2.9.構成員情報検索機能
1.2.9.1.

構成員情報管理 機能 に保存しているデータについて、利用者が指定する様々な条件により抽出できる条件検索機能を備えること。
検索項目における検索条件は、部分一致 とし、 項目の属性に応じて多様な条件を指定できること。検索項目を複数

1.2.9.2.
1.2.9.3.

指定する際は、項目間のAND検索及びOR検索も指定できること。

検索結果は、対象構成員候補一覧を表示すること。一覧から選択指定された １人の構成員について詳細情報を表示すること。 対象構成員候補一覧及び検索結果詳細情報は画面表示の他、CSV 出力が可能なこと。

1.2.9.4.

検索結果詳細情報については、構成員基本情報の最新情報、 及びこれまでの異動（更新）情報、及び紐づく一橋認証
ID のアカウント情報を有機的に紐づけた情報断面を表現できるようにすること。

構成員情報の修正について項を追加しました。

データアクセス制御は、ユーザーの所属、職務、職種にて初期権限が付与され、これに対し個人別に権限の付与を可能とすること。付与された権限により、システム操作に制限を掛けられるものとすること。本システムの操作画面を
1.2.9.5.

使用する ユーザーの認証は、本学の指定する認証システムと連携させること。

1.3.一橋認証アカウント管理機能
1.3.1.一橋認証 ID の決定
構成員情報管理機能にて新規に一橋 ID が登録された場合、及び構成員情報を登録せず管理者やワークフロー申請に
1.3.1.1.

て直接一橋認証アカウントの登録を行った場合に一橋認証 ID を発行する こと 。

1.3.1.2.

一橋認証 ID は、アカウントの状態を問わず必ず一意の値となる。

1.3.1.3.

管理者が構成員情報を登録せず直接一橋認証アカウントの登録 を 行う場合、付番ルール が 一橋 ID の書式や学生における一橋認証 ID の書式と重複しないよう入力チェックを行うこと 。

1.3.2.一橋認証 アカウントデータベース 機能
1.3.2.1.

一橋認証 ID のアカウント情報を保持するデータベース 等 以下 、 「 一橋認証アカウントデータベース 」 と呼ぶ。
）を持つこと。
一橋認証 アカウントデータベース では、最新の一橋認証アカウント情報と過1.3.2.2.

去の更新情報をそれぞれ保持する。過去の更新情報は、アカウント情報の更新が行われた場合にその時点での情報を保持する。 なお、一橋認証アカウントの数は、令和６年３月現在、約 44,000 件（うち、アクティブアカウントは
約 10,000 件）である。
一橋認証アカウントデータベースでは、 ユーザー ID 、パスワード、姓名（英字、漢字）有効期間、身分コード、所

1.3.2.3.

属コード、役職コード、メールアドレス、各種システム利用フラグ等を保持する。

1.3.2.4.

本学が提示するルールに従い、 構成員のメールアドレス情報を自動生成し、一橋認証アカウントデータベースに格納すること。

1.3.2.5.

一橋認証 アカウントデータベース に登録された情報は原則削除せず、保持し続ける。

1.3.3.一橋認証アカウントのライフサイクル管理
一橋認証アカウントのライフサイクルは利用期間開始日から利用期間終了日によってのみ決定されること。アカウン
トを一橋認証アカウントデータベースから削除しないこと。削除要求が行われた場合は、アカウントの利用期間終了
日を 削除要求日 の前日に変更することで有効期限切れとしてアカウントを利用不能な状態として扱うこと｡ 下位シス
1.3.3.1.

テムに連携する際は 、 システム毎に削除処理 又は 無効化処理を行うが、 本学と協議の上 、設計時に詳細を決定すること。
認証システムへの連携については、利用期間終了日から 一定期間 （現行 60 日間） は猶予期間として アカウント が有効 で あり、通常と同様に利用が可能とすること。利用期間終了日から一定期間 を経過したアカウント を システム

1.3.3.2.

の自動処理により機械的に 無効化し、ログイン 不可の無効状態へと遷移させる

1.3.3.3.

有効期限が満了したアカウントは、 システムの自動処理により機械的にアカウント状態を猶予期間状態へと遷移させこと｡ なお、この一定期間の日数は下位システム毎に設定可能とすること。

ること｡

別調達の機能とするため、削除しました。

構成員情報にて退学・退職などの異動が行われた場合は、システムの自動処理により機械的に紐づく一橋認証アカウ
1.3.3.4.

ントが自動的に廃止や無効化などの更新が行われること。

1.3.4.一橋認証アカウントの管理機能
管理者がウェブブラウザー から接続し、一橋認証 アカウントデータベース のアカウント情報をメンテナンス 情報変1.3.4.1.

更、利用可否フラグ変更、新規登録、廃止、再有効化できること｡

一橋認証アカウントに対する操作や、連携先となる各種システムへの連携処理結果をログとして保持すること。保持
1.3.4.2.

されたログ情報は、管理者が閲覧可
能かつ内容がわかりやすい記載とすること 。

1.3.4.3.

一橋認証アカウントデータベース にて無効化されたアカウントは、管理者メンテナンス機能での再有効化や、 CSV
ファイルからの利用期間延⾧を行うことにより、アカウントの復帰が可能であること｡

1.3.4.4.

CSVファイルによるアカウント一括追加・変更・廃止を可能であること｡

1.3.4.5.

アカウント区分グループの全件のアカウント情報を CSVファイル等に出力できること｡

1.3.4.6.

パスワードポリシー（文字数、利用必須文字、利用可能文字）を設定できること｡
管理者がウェブ ブラウザー から接続し、一橋認証アカウントデータベースのパスワードを変更した場合には、その1.3.4.7.

パスワードをテンプレートに合わせて

1.3.4.8.

上記の変更 及び設定は、データ連携管理機能により各種連携先に即時反映できること。

1.3.4.9.

一橋認証 ID に紐付き全学認証に用いるパスワード通知用のデータを CSVファイル等に出力できること｡

印刷可能なこと。（パスワード再発行）

パスワード通知書や通知のためのデータを、各部局担当者などあらかじめ定めた 権限 を持つ者が、画面上での参1.3.4.10.

照、ファイルのダウンロード・紙への出力ができること。また、パスワード通知済みであるかなど、通知状況の管理を行えること｡

1.3.5.一橋認証アカウントのワークフロー機能
1.3.5.1.

申請部署が申請した一橋認証アカウント情報について、承認部署がその内容を確認し、承認することで一橋認証アカ
ウントの登録を可能とするワークフロー機能を有すること。

一橋認証アカウントのワークフロー機能は下記（ 1 ）～（ 2 ）で示す申請を行うものとする。申請は、新規・変更・廃止申請の３つとし、申請の種類は導入以降、業務要件の変化により増減する
1.3.5.2.

可能性があり、柔軟に対応できること 。
（1） 研究員登録申請（2） 日本学術振興会特別研究員登録申請（3） 業務委託教員等登録申請
登録済みの全ての一橋認証アカウント に ついて、下記の（ 1 ）～（3 ）で示す申請を可能とするワークフロー機能を有すること。申請の種類は導入以降、業

1.3.5.3.

務要件の変化により増減する可能性があり、柔軟に対応できること。
（1） 利用期間変更申請（アカウントの利用期間満了日の延⾧する申請）（2） 利用可否フラグ変更申請（各種システムの利用可否を変更する申請）（3） パスワード変更申請（パスワードの強制変更を依頼する申請）
これらのワークフロー申請は、管理者による承認プロセスを経て、一橋認証アカウントとして登録・反映を行うこ

1.3.5.4.

と。承認が完了していない申請や棄却された申請情報は一橋認証アカウントとしては扱わないものとする。

1.3.6.一橋認証アカウントの利用者メンテナンス機能

1.3.6.1.

利用者がウェブブラウザー から接続し、自身の一橋認証アカウント情報パスワード、名称、メールエイリアス を変
更 及び 設定可能なこと。メールエイリアスは教員のみが設定可能とし、一回のみ設定可能であること。

1.3.6.2.

上記の変更 及び 設定は、データ連携管理機能により各種連携先に 即時反映できること。

1.3.6.3.

管理者がウェブブラウザーから接続し、利用者メンテナンス機能の画面にて変更可能な項目の設定を行えること｡

1.4.サービス連携管理機能
1.4.1.全般的要件
1.4.1.1.

一橋認証 アカウント情報を、アカウント毎の利用可能期間や、システム利用可否フラグに基づき、 各種システムへ
データ 連携すること。

1.4.1.2.

連携に失敗した際には、連携のリトライを自動的に行い 、失敗した際に管理者のメールを送付する等、 本学と協議の上設計し、 設定を行うこと。

別調達の機能とするため、削除しました。

一橋認証アカウント情報の連携は、各種認証システム（教研メタ LDAP 、
UNIX コマンド実行 サーバー （教研 AD） 、事務 AD 、 CALL AD ）、図書館システム、入退システム、 文書管理シ
1.4.1.3.

ステム、 IC カード管理機能、グループウェアシステム、人事給与システム、学務情報システム、 Google Workspace を対象とすること。連携先は導入以降、業務要件の変化により増減する場合で も簡易なシステム設定の実施や必要に応じてライセンスの追加購入を行うことで対応できる構成とすること｡

1.4.1.4.

サービス連携管理機能による連携は、一橋認証ア カウントに個別に付与されたシステム利用可否フラグにて連携可否を制御すること。
サービス連携管理機能 の下位連携先へ送信するデータは、サービス利用開始日・データ連携実行日等の基準日を基に

1.4.1.5.

1.4.1.6.

して時系列的に閲覧できる検索・一覧表示画面、及び CSV ファイルダウンロード機能を提供すること。

一橋認証アカウント情報の 連携方式は、 CSV に限定せず API 、 DB リンク、 LDAP 等複数の方式の選択が可能なこと。
一橋認証アカウント情報の連携では、連携先となる下位連携システム、及び連携情報を条件として連携用文字列

1.4.1.7.

（メールドメイン名など）を生成し、連携に使用できること。

1.4.1.8.

連携先システム等の仕様に応じて、 連携タイミングは、バッチ処理に限定せずオンライン処理や随時処理等複数の実
行タイミングの選択が可能なこと。

1.4.1.9.

フラグ変更（アカウント区分の変更など）があった場合には、その処理日付を格納できること｡

1.4.1.10.

アカウント区分が変更された場合は変更前のアカウント区分が履歴として保存できること｡

1.4.1.11.

アカウント利用期日（利用期間開始日 及び 利用期間終了日）は、下位連携先システム毎に柔軟に設定・変更ができること｡
各種認証システム及び人事給与システムを除き、 データ連携は CSV とすること。 別の データ形式を提案する場合

1.4.1.12.

は、本学 及び当該 システム受注者と協議の上で採用することとする。
今後、連携するシステムを追加すること、また各システム間の連携を見直 すことがある。追加・連携方式の変更を予

1.4.1.13.

定して、拡張可能な設計を行っておくこと。

1.4.2.認証システム連携
一橋認証アカウント情報を下記の認証システムへ連携すること。
・教研メタ LDAP
1.4.2.1.

・ コマンド実行 サーバー （教研 AD
・事務 AD・ CALL AD

1.4.2.2.

連携について は、バッチ連携プロセスと 即時連携プロセスを実行できること。
バッチ連携プロセスについては、次の方法で実行できること。

1.4.2.3.

・管理者の手動実行
・外部コマンドからの実行
・スケジュール設定による実行

1.4.2.4.

パスワードの連携は、暗号化して実行できること。

1.4.2.5.

各種認証システムへの連携対象アカウントは、アカウント単位に指定された連携可否により決定する。
認証システムへのアカウント連携では、一橋認証 ID やパスワード、氏名など連携先ごとに連携項目と連携値の格納

1.4.2.6.

先属性を柔軟に指定可能とする。

1.4.3.図書館システムへのデータ送信
1.4.3.1.

構成員情報、及び一橋認証アカウント情報を図書館システムへ送信すること。送信データは差分データと全件データとすること。
差分データ、全件データとも同一ファイルフォーマットとすること。項目は
以下 を想定している 。
各項目の日本語見出し（ ヘッダー ）行、 有効化・無効化・ 削除の別、初期登録日、更新日、更新時間、発効日、管理 ID 、図書館利用者コード、 LDAP 認証 ID 、学籍番号、所属コード、身分コード、有効期限、発行回数、利用者
名、名称読み１、名称読み２、生年月日、旧姓、 E Mail アドレス、連絡先電話番 号、連絡先携帯電話番号、現住所

1.4.3.2.

郵便番号、 現住所、 帰省先電話番号、帰省
先郵便番号、帰省先住所、 サービス開始日 、 サービス終了日 、 連携日 、 図書館独自利用者コード 、 勤務（在籍）キャンパス区分、 学生所属キャンパス区 分、 科研費番号
項目編集定義については詳細設計時に確定すること。

1.4.4.入退システムへのデータ送信
1.4.4.1.

構成員情報、及び一橋認証アカウント情報を入退システムへ送信すること。送信データは身分別に教職員、大学院生、学部生の３種類とそれぞれにつき差分データと全件データとすること。

身分別データ、差分データ、全件データとも同一ファイルフォーマットとすること。項目は以下のとおりとすること。
送信状態、登録削除状態、カード種類、個人コード、管理番号、所属コ ード、区分コード、氏名、カナ、暗証番号、
1.4.4.2.

指紋照合レベル、指紋インデックス１、指紋インデックス２、有効期限、初期登録日、更新日、読み取り禁止動作
時、アンチパスバック、警備セット時の操作、監視カード、鍵保管ボックスモー
ド、通門コード・ホルダコード
項目編集定義については詳細設計時に確定すること。

1.4.4.3.

出力するファイル名の変更は、柔軟に対応できること。（例：年度毎にファイル名称の接頭語 YYYY を変更する等）
所属コードの追加や区分コードの追加等の組織変更への対応に柔軟に対応で1.4.4.4.

きること。（例：所属コードや区分コードの管 理マスタ情報を ユーザー が画面から入力変更したり、 CSV イン
ポートして更新したりする等）

1.4.5.グループウェアシステムへのデータ送信
構成員 （学生を除く。 情報、及び一橋認証アカウント情報をグループウェアシステムへ送信すること。送信データは
1.4.5.1.

新規採用、異動、退職、復帰の４種
別とし、それぞれ差分データとすること。
新規採用のデータファイルフォーマットの項目は以下のとおりとすること。

1.4.5.2.

ログイン ID 、氏名漢字、氏名カナ、初期パスワード、メールアドレス、内線、所属名、職種名
項目編集定義については詳細設計時に確定すること。
異動のデータファイルフォーマットの項目は以下のとおりとすること。ログイン ID 、異動先所属名、職種名

1.4.5.3.

項目編集定義については詳細設計時に確定すること。

1.4.5.4.

退職のデータファイルフォーマットの項目は以下のとおりとすること。ログイン ID
項目編集定義については詳細設計時に確定すること復帰のデータファイルフォーマットの項目は以下のとおりとすること。
1.4.5.5.

ログイン ID 、氏名漢字、氏名カナ、初期パスワード、メールアドレス、内線、所属名、職種名
項目編集定義については詳細設計時に確定すること。

1.4.6.学務情報システムへのデー タ送信
1.4.6.1.

教職員に関する 構成員情報を 学務情報システムへ送信すること。送信データは差分データとすること。 なお、教職員に関する連携は「Ⅲ.1.2.4. 学務情報システムからの送受信連携」で実現してもよい。

教職員に関する差分データのデータ項目は以下の とおりとすること 。
一橋ID 、氏名漢字、氏名カナ、 性別コード、生年月日、採用年月日、退職年月日、 所属コード、役職コード、在職／離職、勤務区分 、人事区分、職種区分、削除フラグ
1.4.6.2.

項目編集定義については詳細設計時に確定すること。具体的な項目、連携方法等については、本学及び学務情報シス
テム構築業者と協議の上、決定すること。

1.4.7.連携先システムからのデータ受信
連携先システムから受信したデータ内容につき、他の連携先システムへ連携する必要が新たな要望として出てくる可能性がある。その際の新たなデータ連携ルートの追加について柔軟に対応できること。
1.4.7.1.

提案にあたっては変更対応できる範囲と別途契約となる基準あるいは例を明示すること。

1.4.8.クラウドメールサービス連携
一橋認証アカウント情報を下記のクラウドサービスへ連携し、プロビジョニングが可能なこと。
1.4.8.1.

・ Google Workspace・ Microsoft 365

1.4.8.2.

クラウドサービスへの連携対象アカウントは、アカウント単位に指定された連携可否により決定する。

1.4.8.3.

クラウドサービスへのアカウント連携では、一橋認証 ID やパスワード、氏 名など連携先ごとに連携項目と連携値の格納先属性を柔軟に指定可能とする。

1.4.8.4.

Microsoft 365 への連携に関しては、一橋認証アカウントの区分を条件に適切なライセンス割当を行うこと。

1.4.8.5.

一橋認証アカウントが無効状態となった場合、クラウドサービスへ連携対象外となった場合は、クラウドサービスからアカウントを削除する。

1.5.IC カード管理 機能
1.5.1.全般的要件
1.5.1.1.

構成員情報管理機能内のデータベースにより各構成員の IC カード発行状況を管理できるものとする。

別調達の機能とするため、削除しました。

1.5.1.2.

IC カード の作成印刷を外部委託するため、 IC カード印刷に必要な IC カード印刷委託データを IC カード管理機能が作成し提供すること。

1.5.1.3.

ICカードの仕様は、原則として FCF キャンパスカードフォーマットに準拠し、独自拡張領域も使用する。

ICカードによる個人識別は、現在は独自拡張領域に格納している情報を使用
1.5.1.4.

しているが、今後のシステム拡張に備え、共通領域の情報も使用できるよう

1.5.1.5.

ICカードは再発行できるものとし、カード単位の管理ができること。

1.5.1.6.

ICカードを紛失した際そのカードの悪用を防止する目的にて当該 IC カードを無効化する情報を登録できることとするにする。

。
1.5.1.7.

作成印刷された IC カードを受領管理するため、 IC カード固有情報等を含めたカード納品データを取り込む事ができること。

1.5.1.8.

ICカード管理機能を操作する業務担当は教職員担当部署、学生担当部署とする。その他システム運用管理担当として情報推進課とする。

1.5.2.構成員情報と ICカード管理対象者
1.5.2.1.

ICカード作成対象者の決定は上位システム（人事給与システムあるいは学務情報システム）で行い、 ICカード作成対
象者を IC カード管理機能において管理できること。

1.5.2.2.

ICカード管理機能における人（構成員）情報は構成員情報管理機能のデータベースそのものとする。

1.5.3.IC カード印刷委託データの作成
1.5.3.1.

教職員担当者あるいは学生担当者がシステム操作者として、 IC カード作成印刷対象者のデータを画面から選択して、IC カード印刷委託データを作成する。
IC カード印刷委託対象者の選択画面は、各種条件検索によるものとし以下項目指定ができるものとする。

1.5.3.2.

所属、入社日（入学日）、氏名、学籍番号、職員番号、一橋 ID

IC カード印刷の外部委託先に提出するためのデータ項目は 受注者のみに開 示する。 なお、データ項目の種類は 、教職員用と学部生・大学院生用の 2 種類があり、共にデータ項目の項目数は 53 であり、 うち本システムと連携す1.5.3.3.

る 項目は 19 である。 また、本学の指示に基づき、適切にハッシュ関数、その他暗号化を行うこと。 なお、フォー
マットは教職員、学生の２種類が存在する。

1.5.3.4.

IC カードの発行に係る処理日付として以下項目を管理できるようにする。作成委託日、納品日、本人受渡日、無効化
日、所管部署回収日、廃棄日

1.5.4.顔写真データの登録
IC カード券面に表示する顔写真データは、 IC カード管理機能に保存する。顔写真データはあらかじめ別途手順にて
1.5.4.1.

JPEG 形式として作成したものを、 IC カード印刷委託データと紐づけるキーを指定して取込みできる仕組みを提供すること。

IC カード管理機能に取り込まれた顔写真は、 IC カード管理機能操作画面から閲覧できること。 ただし、顔写真を構
1.5.4.2.

1.5.4.3.

成員情報管理機能のデータベースに保存してある場合には、 利便性が落ちないよう配慮した上で、 構成員情報管理機能で閲覧できることとしてもよい 。
顔写真データのサイズは IC カード印刷要件に沿うものとし、要件サイズと合致しないデータは取り込み時にエラーとすること。

1.5.4.4.

顔写真データは IC カード印刷委託データとともに IC カード印刷委託先に提出できること 。

1.5.4.5.

学生の顔写真データは、学務情報システムからのデータ連携によっても取込みできること。

1.5.5.IC カード情報の納品処理
1.5.5.1.

印刷を外部委託した IC カードが本学へ納品される際に、 IC カードの固有情報であるカード ID 、 IDm 、 FCF UN 等のデータ を含んだ CSV ファイルが納品されるので、これ を IC カード管理機能に 取り込める こと。

1.5.5.2.

IC カード固有情報を取り込んだ後、その情報を必要とする図書館システムや入退管理システムへデータ提供できる
データ連携とすること。

1.5.5.3.

IC カード印刷委託後、納品までの間に諸種事情により IC カードの作成が中止となった場合は、その結果が分かる記
録を IC カード管理機能に残すこと。

1.5.6.IC カード再発行指示処理
教職員担当者あるいは学生担当者がシステム操作者として、 IC カード再発行印刷対象者のデータを画面から選択し1.5.6.1.

て、 IC カード再発行印刷委託データを作成できること。

1.5.6.2.

IC カード再発行印刷対象者の選択画面は、各種条件検索によるものとし以下項目指定ができるものとする。
所属、入社日（入学日）、氏名、学籍番号、職員番号、一橋 ID

1.5.6.3.

1.5.6.4.

IC カード再発行印刷委託データ項目は、 「 1. 5 」 の IC カード作成印刷データと同様とする。
再発行指示の際には、以下管理項目を登録できること。
再発行理由（紛失、 IC カード券面情報変更、 IC カード汚破損、その他）、本

人申請日、再発行指示日、カード利用開始日
1.5.7.IC カード無効化処理
教職員担当者あるいは学生担当者がシステム操作者として、 IC カード紛失時にカードが悪用されないよう、画面か
1.5.7.1.

ら対象者及び対象カードを特定して無効化する処理ができること。

1.5.7.2.

IC カード無効化対象者の選択画面は、各種条件検索によるものとし以下項目指定ができるものとする。
所属、入社日（入学日）、氏名、学籍番号、職員番号、一橋 ID

1.5.7.3.

無効化した情報を 、 IC カードを活用している図書館シス テムや入退管理システムへデータ提供できるデータ連携とすること。
無効化処理の際には、以下管理項目を登録できること。

1.5.7.4.

無効化理由（紛失、 IC カード券面情報変更、 IC カード汚破損、その他）、本
人申請日、無効化実施日

1.5.8.IC カード有効化処理
1.5.8.1.

無効化 IC カードを有効化できること。ただし、 「Ⅲ.1. 5.6. 」 で示す再発行委託データ作成を完了したものについて
は、有効化できないものとする。

1.5.9.IC カード作成スケジュール
ICカード作成印刷業務は基本的に月例作業とし、あらかじめ本学が定める IC カード作成委託データ作成 及び カード
1.5.9.1.

納品の年間スケジュールに従ったデータ管理 及び 印刷管理が行えること。 なお、 IC カード作成印刷業務自体は本調達には含まない。
以下、月例処理のタイミングと件数に対処できる処理能力を持つこと。教職員新規採用
及び 再発行：毎月 20 日委託データ提供 平均 20 件、当月末カード納品
学生再発行：毎月 20 日委託データ提供 平均 30 件、 当月末 カード納品以下、新年度新入生向け年次処理のタイミン
グと件数に対処できること。学生新入生：毎年3 月 20 日前後 委託データ提供 約 1,700 件、

1.5.9.2.

3月25日前後カード納品

1.6.学術認証フェデレーション 連携 管理 機能
1.6.1.全般的要件
大学共同利用機関法人情報・システム研究機構国立情報学研究所が運営する
1.6.1.1.

学術認証フェデレーション「学認」 （以下、「学認」という。 に参加し連携するため、学認 IdP を構築すること。
クラウド基盤上 で Shibboleth サーバー等を構築する方法のほか、 SaaS 、 IDaaS 等の既存 サービスを使用してもよい。

1.6.1.2.

学認と連携する ID は一橋認証 I D とする。

1.6.1.3.

学認における一橋認証 ID の使用 について、 「Ⅲ.1.3.3.2. 」 で示す猶予期間は適用せず、利用期間終了日を過ぎた
ID は 無効とする こと 。

1.6.1.4.

認証に際しては、多要素認証を設定できることが好ましい。

1.7.共通機能
1.7.1.コードマスタ管理
1.7.1.1.

構成員情報の基礎となる組織・所属情報、職務・身分情報を本システムにおいて構成員基礎コードマスタとして管理を行うこと。

1.7.1.2.

構成員基礎コードマスタ管理においては、履歴管理ができるようにすること。

1.7.1.3.

管理者が構成員基礎コードマスタデータの追加を行う必要があるため、登録機能を有すること 。

1.7.1.4.

構成員基礎コードマスタデータは二次活用を想定し、 CSVファイルの出力ができること。

1.7.1.5.

構成員基礎コードマスタデータに変更が発生した際は、その情報を下位システムへデータ提供すること。
その他、データ連携やデータ編集等の実行に際して必要となる処理条件や名称等の情報は、可能な限りプログラム内部に保持せずプログラム外部のマスタや定義ファイルに登録する仕様とすること。提案にあたっては、変更対応

1.7.1.6.

できる範囲（ 又は 保守契約内での対応も含む 。 ）と別途契約となる基準あるいは例を明示すること 。

別調達の機能とするため、削除しました。

1.7.2.データ保全管理
データ連携の実行記録については、本学運用管理者が容易に常時確認できるよう閲覧性を高めた情報提供機能を用意
1.7.2.1.

すること。情報通知は原則、メール送信などプッシュ型の通知を行うこと。

1.7.2.2.

データ連携実行結果を本学運用管理者が正確に把握できる内容情報を提供すること。正常・異常の別、処理時刻、処
理件数、処理区分内訳、エラー内容明細等を提供すること。

1.7.2.3.

画面操作を含むシステム操作記録については、処理時刻、処理端末、処理ユーザー ID 、処理内容を記録すること。
画面操作を含むシステム操作記録については、ログ情報として時系列で管理すること。また、必要に応じて参照を行

1.7.2.4.

う場合の操作性に関して考慮すること。なお、改ざん対策などセキュリティ面を考慮した対応を提案すること。
実行記録 及び 操作記録については、本学の文書保存規程に基づく一定期間をディスクに保管すること。保存期限を

1.7.2.5.

経過したデータを削除する機能を備えること。

1.7.2.6.

構成員情報管理機能内部のデータについては、本学の文書保存規程に基づく
一定期間を 記憶領域 に保管すること。保存期限を経過したデータを削除する機能を備えること｡
1.7.3.そ の他異なる文字コードシステムを持つ上位システム、及び認証連携及びサービス連携機能の下位連携先の間でデータ連携
1.7.3.1.

1.7.3.2.

を行えるよう必要に応じて異なる文字コードデータを連携データの取込み前、又は連携データの出力後に一定の文字コードに変換する機能を実装すること｡
上位システムからのデータ受信に際して実行する名寄せ機能においては、文字コード変換時の差異等が発生する可能性を留意した設計とすること。
上位システムのデータ項目をそのまま構成員情報管理機能あるいは下位システムが使用する場合は、その項目名称を

1.7.3.3.

上位システムが扱う名称 に統一する設計とすること。（本番システム運用時のデータ確認や事後の保守改修段階
での関係者の認識共有を図るため。）

上位システムにおいて構成員情報管理機能へ連携済の 情報 を取り消した場合、上位システムから取消データを構成員
1.7.3.4.

情報管理機能へ送信することで、各下位連携先へ必要な取消データを送信できること｡

1.7.3.5.

本システムに登録されている本人に関する情報を表示できること。表示範囲はシステム設定により制御可能とすること｡

IV.設置・導入
1. システムの設計及び構築に関する項目
1.1.全体要件
提案したすべてのシステムに関して、受注者は本学と協議の上、運用面、環境面、ネットワーク全般にわたる設計を
1.1.1.

行うこと。 なお、現行の連携・設定を見直す場合があるので本学の要請に従い十分に対応すること 。本学担当者及び連携先システム関連業者との打合せの時間を十分に見込んでおくこと 。

1.1.2.

導入にあたっては，作業予定及び進捗状況を日次及び週次で本学へ提示し、 都度連絡調整を行うこと。

2.データ移行に関する項目
2.1.全体要件
2.1.1.

移行に係る要件
後述の要件を参照し、データ移行作業の進め方、移行ツールのテスト方法、移行後の検証方法、スケジュール等につ2.1.1.1.

2.1.1.2.

いて検討し、移行計画書としてまとめること。作成した移行計画書をもとに本学と協議し、承認を得ること。

移行作業が正しく実施されたことの結果について、移行結果報告書としてまとめ、本学に報告すること。

2.1.2.移行データ 等
本システムへの主な移行対象データを保持するシステムとして、 現行システ
2.1.2.1.

ムである 「 構成員情報管理システム（ One人事株式会社製） 」、 「 統合 ID 管理システム LDAP Manager 、 エク
スジェン・ネットワークス株式会社製 ）」 等がある。 移行するデータの 項目の詳細については、本学と協議し、基本設計完了時までに確定することとする。

2.1.2.2.

本システムの項目の構成をもとに、移行ツールの設計、取込ファイルレイアウトの作成を行うこと。

2.1.3.現行システム 等 のデータ
移行データについては、 現行システム又は 連携先システムの保守事業者が CSV等の汎用的なデータ形式で抽出した
2.1.3.1.

データを、本学を介して受注者が受け取り、必要な加工を行った上で取込作業を行うこと。

2.1.3.2.

現行システム又は 連携先システムで管理していない項目のデータは、本学と協議の上、受注者が用意すること。

2.1.4.移行ツール開発
データ移行に係るツールの設計・開発を行う。移行ツールのテストは十分に行い、その結果を本学に報告した後に、移行作業を実施すること。
2.1.5.移行作業
受注者は、移行作業が完了したという結果について、本学に報告すること。なお、正確に移行したことを示す記録等も併せて提出すること。
2.1.6.移行に係る役割分担
移行に係る作業分担を以下に示す。

3.マニュアル、ドキュメント等に関する項目
3.1.全体要件
納品されるすべての機器、機能、ソフトウェア等について、その構成、設定、利用方法、保守等に関する 下記に示す
マニュアル、ドキュメント等を作成し、紙媒体及び電子媒体
3.1.1.

（原本のファイル形式及び PDF 形式の 2 種）で提出すること。
なお、パッケージソフトウェア等 において、著作権上 、 提出できないものについては、この限りではない。
プロジェクト管理 ・実施計画 に関するもの① 設計・開発実施計画書（プロジェクト管理の実施内容、計画 WBS を含む）
② 作業完了報告書 プロジェクト管理の実施内容、実施結果、構成管理状況等を含む）

3.1.2.

③ 進捗状況報告書④ 進捗管理表（中日程）⑤ 課題事項一覧⑥ 変更管理票／変更管理状況一覧⑦ リスク管理票／リスク管理一覧

設計に関するもの① 要件定義書改定案② 基本設計書 （全体概要図、 ER 図、新業務フロー図、データフロー図、ハードウェアリソース設計、機能／画面一覧表、画面デザイ
ン設計、名寄せ機能概要設計等）③ 移行実施計画書④ 全体テスト実施計画書⑤ 詳細設計書（画面設計書、 プログラム設計書（処理フロー図含む）、 インターフェース仕様書、テーブル定義書、バッチジョブ設
計書（ジョブフロー図含む）、システム環境
設計書、システム環境変数定義書 等⑥ プログラム（ソフトウェア、ソースコード、実行プログラム、環境設定ファイル等）⑦ 結合テスト仕様書

3.1.3.

⑧ 結合テスト 結果報告書⑨ 総合 テスト仕様書⑩ 総合テスト 結果報告書⑪ 移行リハーサル実施結果報告書（移行スケジュール検証結果を含む）⑫ 移行結果報告書⑬ 研修用資料⑭ 運用設計書⑮ 運用手順書⑯ 運用関連ドキュメント⑰ 保守関連ドキュメン ト⑱ 情報セキュリティ管理計画書

3.1.4.

前項において受注者が作成するものは、原則としてマイクロソフト社の Oﬃce 製品のファイル形式とする。

3.1.5.

使用言語は原則として日本語であること。

3.1.6.

導入時には本学担当職員に管理運用に必要なトレーニングを行うこと。

V.保守・運用
1.保守に関する項目
1.1.全体要件
1.1.1.

受注者は、本稼働開始以降の保守のため、 本 調達の導入を担当した者か業務経験及び専門知識を有する要員を確保
し、遠隔保守の体制を保持すること。

1.1.2.

本システム導入後の保守計画を提示すること。

1.1.3.

本システムに関するすべての保守・運用窓口を一本化すること。

1.1.4.

障害発生時に、 障害の一元受付、切り分け、手配が実施可能な体制を有すること。

1.1.5.

本仕様の一部又は全部を他社の製品で満たしている場合にも、受注者が責任をもってそれらの製品の保守を行う体制をとること。

1.1.6.

平日（土・日祭日以外）の午前 9 時から午後 5 時において 障害 受付が可能な連絡先を設定すること。

1.1.7.

本システムに障害が発生した場合に、連絡後 2 時間以内に 障害の切り分け、原因調査に着手できる体制をとること。

1.1.8.

障害が発生した場合は、来学、通信連絡又は遠隔操作のいずれかにより復旧措置をとること。
遠隔操作には、本学が提供する VPN 接続環境を利用すること。なお、この通信路は必 要な場合以外は常に閉じた状

1.1.9.

態とし ている。使用する場合は事前に本学へ申請を行い 、1.1.10.

本学が提供する VPN 接続環境の利用については、本学の指示に従い接続機器のセキュリティ対策や利用者教育を徹

許可を得ること。
底すること。
1.1.11.

アプリケーションソフトウェア 、 ミドルウェア及び OS の不具合、 セキュリティホール及びウイルスによる本シス
テムの機能低下を未然に防ぐため、常に最新の情報を収集し、それらを提供するとともに、その対策を迅速に行うこと。

1.1.12.

前項の対策について、安定的に動作するために必要なもの及びセキュリティ保持に必要なものは、速やかに提供すること。その他、 緊急度の低いパッチについては、必要に応じて随時提供すること。

障害によるサービス中断は、 障害連絡を受けてから休日を除く連続 2 日以内、保守作業によるサービス中断は、保守作業を開始してから 4 時間以内を原則とすること。障害復旧又は保守作業がこれを超えて⾧期に及ぶことが判明した場合には、本学にその旨を報告すると共に、受注者の負担により、障害の原因と考えられる ソフトウェア の同等
1.1.13.

又は同等以上の機能・性能を有する代替品を用いて障害箇所を交換する等の適切な処置を行うことによって、復旧までの間システムを利用する ユーザー に支障をきたさないようにすること。
受注者は、操作方法、障害時の対処等の対応を迅速に行うことができる Web サポート

1.1.14.

サイト等の仕組みを設け、事前に本学担当者に通知すること。このほか、電子メール 及び電話による照会にも対応すること。

障害通知を受けた場合には、速やかに技術者が状況を把握し、適切な指示又は処置を行うこと。
1.1.15.
1.1.16.

システムの不具合により ユーザー データに不整合や不具合が 発生した場合には、受注者が責任をもって復旧すること。

1.1.17.

既設機器及びネットワークに係る他社製品の障害復旧にも協力的であること。
本学の依頼に応じ、一度配番・決定された一橋 ID を変更できること。一橋 ID の変更に際しては、従来、別 ID （別1.1.18.

人）とし ていた構成員を同一人に合体させる処置と、同一 ID（同一人）としていた構成員を別 人に分離する処置が想定される。

2.運用に関する項目
2.1.全体 要件
受注者は、本稼動開始以降の運用のため、 本 調達の導入を担当した者 か 業務経験及び 専門知識を有する要員を確保
2.1.1.

し、 遠隔保守の体制を保持すること。

2.1.2.

受注者は、本学の求めに応じて、登録データの整合性保持、ドキュメントの更新等の作業を行うこと。
受注者は、操作方法、障害時の対処等の対応を迅速に行うことができる Web サポートサイト 等の仕組みを設け、事

2.1.3.

前に本学担当者に通知すること。このほか、電子メール 及2.1.4.

運用に関わる最新マニュアルを Webサイト等の仕組みで提供すること。

2.1.5.

既設機器及びネットワークに係る他社製品の障害復旧にも協力的であること。

び 電話による照会にも対応すること。

2.2.作業報告等
受注者は、保守運用に関する作業内容について進捗リスト等の形でドキュメント管理し、随時報告を行うこと。ま2.2.1.

た、１か月に１回程度の頻度で定例会を開催し、進捗等について報告すること。 定例会の議事録案は受注者が作成し、本学の承認を得て確定するものとする。本定例会にかかる費用は本調達に含める。

VI.総合評価基準（略）

総合評価基準を掲載しました。