次世代郵便情報システム共通基盤共通基盤ガイドラ …20%e4%bb%95...レビュー、確認作成日2009.9.10 項番作業項目業務アプリ-3-4

1/76 Copyright (C) 2009 Japan Post Co., Ltd. All Rights Reserved. P-01-AP-DS-2600_共通基盤ガイドライン（調達編）

別紙３

次世代郵便情報システム共通基盤

共通基盤ガイドライン

（調達編）

Ver03.07

2013 年 10 月 31日

日本郵便株式会社

情報システム本部情報システム部

200109098755

タイプライターテキスト

200109098755


200109098755


別紙６

200109098755



改版履歴

改版履歴

版数改版内容更新者更新日

01.00 新規作成 2009/05/11

01.01 全面的に見直しを実施 CTC 2009/09/09

01.02 業務アプリケーション構築支援 9/10 打合せ結果反映 CTC 2009/09/10

01.03 共通基盤ガイドライン（調達編） 9/15 レビュー結果反映 CTC 2009/09/15

01.04 BAM を可視化基盤から SOA基盤に修正 CTC 2009/10/07

01.05 内容変更を反映、誤記を修正 CTC 2010/02/09

01.06 新データセンタ利用上の注意事項を追記 CTC 2010/05/31

01.07 2.1.環境についての整理を修正

5.2.共通基盤提供機能一覧を修正

5.3.共通基盤提供機器スペックを修正

CTC 2011/06/03

02.00 6.5.1.アプリケーション実行基盤に追記 CTC 2011/09/09

03.00 6.4.データ連携・可視化基盤

6.6.3.ハードウェア(HW)

6.6.4.ファシリティ

提供予定時期について修正

CTC 2012/02/03

03.01 文章体裁を修正 CTC 2012/06/20

03.02 文章体裁を修正 JP 2012/6/26

03.03 文章体裁を修正 JP 2012/7/10

03.04 二社統合に伴う社名変更 CTC 2012/10/01

03.05 5.3.共通基盤提供機器スペックを修正

5.4.共通基盤提供機器搭載インタフェース構成を新規追加

CTC 水野 2012/12/21

2.1「環境についての整理」へ研修環境の記載を追加

2.3「共通基盤構成と利用フェーズの想定」へ研修環境の記載を

追加

CTC 篠崎

5.1「共用基盤構成概要」の不要機器の記載を削除

5.2.1「ネットワーク基盤」の不要機器の記載を削除

6.1「ネットワーク基盤」の不要機器の記載を削除

CTC

酒井(賢)

03.06

6.6.1.「業務アプリケーション開発支援」の記載ツールの見直し

8.2.「業務アプリケーションの構成管理方針」へ研修環境の記載

を追加

9「運用」へ研修環境の記載を追加

CTC 篠崎

2013/01/21

5.3.共通基盤提供機器スペックを修正

5.4.共通基盤提供機器搭載インタフェース構成を新規追加

CTC 町田03.07

1.4.「ディザスタリカバリ導入の検討」を追加 CTC 大澤

2013/10/30


1.5.「テスト環境（検証環境）多面化の検討」を追加

2.1.「環境についての整理」に災害時本番稼働の記載を追加

6.6.4.「ファシリティ」のデータセンタに関する記載を更新

Appendix1.「技術略語・用語の説明」に DRの記載を追加

※適宜修正することとする。


目次

1. はじめに

1.1. 本書の目的

1.2. 共通基盤利用の促進

1.3. SOA利用の促進

1.4. ディザスタリカバリ導入の検討

1.5. テスト環境（検証環境）多面化の検討

2. 調達・構築の方針

2.1. 環境についての整理

2.2. 調達・構築の流れ

2.3. 共通基盤構成と利用フェーズ想定

3. アプリケーション実装形態の決定

3.1. 共通基盤想定アプリケーション形態

3.2. （参考）アプリケーションイメージ

4. 共通基盤の利用サービスの決定

4.1. アプリケーション実装形態毎の技術構成の活用想定マトリクス表（概要）

4.2. アプリケーション実装形態毎の技術構成の活用想定イメージ

4.3. 業務アプリケーションによる基盤の共同利用方針

4.4. 共通基盤サービス利用申請・承認

5. 共通基盤の提供機能

5.1. 共通基盤構成概要

5.2. 共通基盤提供機能一覧

5.2.1. ネットワーク基盤

5.2.2. 認証基盤

5.2.3. 運用基盤

5.2.4. データ連携・可視化基盤

5.2.5. 共用アプリケーション基盤

5.3. 共通基盤提供機器スペック

5.4. 共通基盤提供機器搭載インタフェース構成

6. 共通盤提供範囲とアプリケーション構築者対応事項

6.1. ネットワーク基盤

6.2. 認証基盤

6.3. 運用基盤

6.4. データ連携・可視化基盤

6.4.1. 可視化基盤

6.4.2. データ連携基盤

6.4.3. SOA 基盤


6.5. 共用アプリケーション基盤

6.5.1. アプリケーション実行基盤

6.5.2. 統合データベース基盤

6.6. その他

6.6.1. 業務アプリケーション開発支援

6.6.2. オペレーティングシステム（OS）

6.6.3. ハードウェア（HW）

6.6.4. ファシリティ

7. 共通基盤利用時の役割分担

8. 業務アプリケーション開発支援

8.1. 業務アプリケーションの実装方法・制限

8.2. 業務アプリケーションの構成管理方針

8.3. 業務アプリケーションのリリース方針

8.4. 業務アプリケーションのセキュリティ診断

9. 運用

9.1. 共通基盤の運用管理

9.2. 共通基盤の構成管理

9.3. 共通基盤のメンテナンス/バージョンアップ

9.4. 共通基盤の拡張方針

Appendix1. 技術略語・用語の説明

Appendix2. 統合データベースの補足説明


1. はじめに

1.1. 本書の目的

本書の目的

本書は、業務アプリケーション担当に対して、共通基盤

をどのように利用すべきか決定するためのガイドラインを

示すものである。

業務アプリケーション担当は、対象のアプリケーション

がどのような実装形態をとるべきなのかを決定し、共通

基盤の提供する NW、HW、OS、MW、運用、ファシリティな

どの共通基盤のサービス（提供物／作業）の利用範囲に

ついて決定する。

実装形態の決定、利用サービスの決定のどちらを先に

検討するかはどちらでもかまわない。

利用サービス決定後、利用したいサービスに定義され

たルールについて理解すること。

対象読者

・日本郵便株式会社の業務アプリケーション担当者

日本郵便株式会社内で、原課からの業務要件に基づき、業務アプリケーション企画に関わる企画担当者、及び

企画担当者を支援する IT スキルを保有するメンバー

・業務アプリケーション構築の入札希望ベンダ

業務アプリケーション構築の調達公告に対して、提案書や見積りを作成し入札を希望するベンダ

・業務アプリケーション構築受託ベンダ

業務アプリケーション構築を落札し、業務アプリケーションを構築するベンダ

アプリケーション実装形態の決定

共通基盤の利用サービスの決定

利用予定サービスに対してルールを理解する

検討スタート

検討ゴール

不適合。再考

共通基盤要求定義書を理解する

順不同どちらが先でも可

個別システム化検討再検討後利用せず

不適合。再考適合。

適合。共通基盤利用。

アプリケーション実装形態の決定

共通基盤の利用サービスの決定

利用予定サービスに対してルールを理解する

検討スタート

検討ゴール

不適合。再考

共通基盤要求定義書を理解する

順不同どちらが先でも可

個別システム化検討再検討後利用せず

不適合。再考適合。

適合。共通基盤利用。


前提事項

本書に記載の内容は、以下の事項を前提としている。

【共通基盤予算の確保と調達】

・共通基盤構築（または増強）に必要なハードウェア及びミドルウェア、それに付随するライセンスなどの予算、及

び個別サイジングは業務アプリケーション企画・構築担当で確保すること。

・ほかのアプリケーションに影響を与える場合は、その影響範囲も含めサイジング・調整・予算を確保すること。

・但し、共通基盤へ搭載するためのサイジングや、資材の搭載作業に関しては共通基盤担当が行う。

【共通基盤未選定の資材調達について】

・共通基盤の選定した各種資材以外に有償で必要なものがある場合は、連絡・相談すること。

【共通基盤の変更影響について】

・共通基盤を利用している各アプリケーションは、共通基盤の変更（バージョンアップ、HW 構成変更、セキュリティ

パッチ適用など）によって、サービス停止などの影響を受ける可能性がある。

【本書記載事項について】

・現在、共通基盤は構築段階であり、本書に記載されている提供物／作業については随時、拡張・変更が行わ

れていく。

・共通基盤は段階的な構築を想定しており、本書に記載の内容は、共通基盤が既に構築されている状態を前提

に記載している。したがって、共通基盤に搭載されるアプリケーションのスケジュールによっては、共通基盤の提

供物／作業が提供できない可能性があるため、適宜共通基盤担当との協議・検討を行う必要がある。

・本書に記載の内容は、現時点における共通基盤担当の想定事項を基に記述されている。記載されている内容

は、他担当との認識統一が完了しているものではなく、今後随時変動する可能性がある。

【本書利用対象者について】

・業務アプリケーションについての要件の概略が整理されており、アプリケーションの規模や構築に必要な技術

想定目処があること。


1.2. 共通基盤利用の促進

業務アプリケーション担当、業務アプリケーション構築の入札希望ベンダ、業務アプリケーション構築の受

託ベンダは、本書の内容を理解のうえ、「4. 共通基盤の利用サービスの決定」に従い、共通基盤の提供サ

ービスを積極的に利用して業務アプリケーションを構築すること。

共通基盤を利用することにより、業務アプリケーション担当、業務アプリケーション構築の入札希望ベンダ、

業務アプリケーション構築の受託ベンダにおいては、それぞれ以下の効果が期待できる。

業務アプリケーション担当業務アプリケーション構築の入札希望ベンダ

業務アプリケーション構築の受託ベンダ

・共通基盤で提供する統一されたサービス、機能（ネットワ

ーク、運用、認証など）を利用できる。

・システム基盤についての検討作業が軽減されるため、業

務アプリケーションの機能要件の検討に集中できる。

・システム基盤を単独で構築する場合にはコスト面などで利

用が難しいミドルウェアについても利用できる可能性が広が

る。

・共通基盤全体で運用を行うため、単独で運用を行う場合と

比べて運用コストの削減が期待できる。

・業務アプリケーションの開発及び保守のみ対応可能なベ

ンダに対しても入札の機会を提供でき、競争によるコスト削

減が期待できる。

・共通基盤で提供する統一されたサービス、機能（ネットワー

ク、運用、認証など）を利用できる。

・システム基盤についての検討作業が一部軽減されるため、

業務アプリケーションの機能要件の検討に集中できる。

・入札時、調達仕様書でのシステム基盤・運用の要件に対し

て実現方法を検討する負荷が軽減できる。

・業務アプリケーションの開発及び保守のみ対応可能なベン

ダも入札に参加しやすい環境ができる。

1.3. SOA 利用の促進

業務アプリケーションの調達・構築を行う際には、業務アプリケーション担当と業務アプリケーション構築の

受託ベンダの間で SOA でのサービス公開について協議し、公開サービスを決定すること。特に、既存システ

ムで外部システムとの連携があり再構築後も見込まれる場合や、既存システムでは外部システムとの連携

はないが今後は連携する可能性がある場合などには積極的に SOA でのサービス公開を検討すること。

また、業務アプリケーションの調達・構築を行う際には、共通基盤担当と業務アプリケーション担当の間で

SOA での公開サービスの中から利用するサービスについて協議し、業務アプリケーション構築の受託ベンダ

に提示すること。業務アプリケーション構築の受託ベンダは、提示されたサービスが利用可能な場合には積

極的に利用を検討すること。


1.4 ディザスタリカバリ導入の検討


受託ベンダの間でSLA/BCPの要件に照らし合わせてディザスタリカバリについて協議し、ディザスタリカバリ

要件を検討すること。

また、業務アプリケーションの調達・構築を行う際には、業務アプリケーション担当からディザスタリカバリ

要件の検討結果を共通基盤担当に連絡すること。

1.5 テスト環境（検証環境）多面化の検討


受託ベンダの間でテスト要件（機能系、非機能系、統合テストなど）を整理し、テスト環境（検証環境）多面化

を検討すること。

また、業務アプリケーションの調達・構築を行う際には、業務アプリケーション担当からテスト環境（検証環

境）多面化の検討結果を共通基盤担当に連絡すること。

テスト環境（検証環境）多面化はテスト環境のリソースを分割して実現する。詳細な実装方法については、

共通基盤ガイドライン（実装編）に記載しており、業務アプリケーション構築受託後に提示する。


2. 調達・構築の方針

2.1. 環境についての整理

以下に業務アプリケーションを構築する際に想定される環境について記載する。

環境名ベンダ開発環境 AP 保守環境テスト環境（検証環境）

研修環境本番環境

利用目的業務アプリケーション

を開発するためにベ

ンダ側で用意する環

境。また開発された

業務アプリケーション

を検証するための環

境。


のコンパイルが行え

る、アプリケーション

保守を実施するため

の必要最小限の環

境。(業務アプリケー

ションのテスト、シス

テムテストは行わな

い環境)

本番環境リリース前

の最終的なアプリケ

ーションテスト、シス

テムテストを実施し、

本番環境へリリース

する最終的な構成を

確定させるための環

境

次世代郵便情報シス

テム共通基盤上で動

作するシステムに対

し、システム利用者

向けの業務研修や

訓練を行うための環

境。

次世代郵便情報シス

テム共通基盤の本番

稼働環境。(システム

テストは行わない環

境)

利用フェーズ設計開発設計開発/保守テスト/

災害時本番稼働※

業務研修/訓練/

災害時本番稼働※ 本番稼動


担当


担当


担当


担当調達業務アプリケーション

構築ベンダ共通基盤担当共通基盤担当共通基盤担当共通基盤担当


構築ベンダ


構築ベンダ


構築ベンダ


構築ベンダ構築


構築ベンダ共通基盤担当共通基盤担当共通基盤担当共通基盤担当

設置場所業務アプリケーション

構築ベンダ指定場所


指定場所


指定場所


指定場所


指定場所


担当


担当


担当管理者


構築ベンダ共通基盤担当共通基盤担当共通基盤担当

共通基盤担当

※災害時本番稼働：本番環境が災害により稼働停止した際に DR 発動を契機に復旧活動がされ、本番稼働

する。

2.2. 調達・構築の流れ

業務アプリケーション担当は、共通基盤ガイドライン（調達編）により、共通基盤を使用するかを決定し、使

用する場合は下図のような流れで調達を行う。業務アプリケーション担当は、業務要件に加えて共通基盤ガ

イドライン（調達編）を提示し、提案を受けるものとする。

＜調達フェーズ（調達方式は総合評価落札方式を想定）＞

① 業務アプリケーション担当は業務要件と共通基盤ガイドライン（調達編）を公開し調達内容を公示する。

② 入札を希望する各ベンダは共通基盤を利用した構成で、AP保守・テスト・研修・本番環境用のハードウェ

アミドルウェアについて、性能要件に基づきサイジングなどを実施し必要な機器、スペックなどを提案す

る。

ベンダ開発環境 AP保守環境テスト環境（検証環境）

研修環境本番環境


③共通基盤担当は提案書からハードウェアを中心に見積り内容を精査し、結果を業務アプリケーション担当

へフィードバックする。

④業務アプリケーション担当は共通基盤担当からのフィードバック結果も踏まえ、各ベンダの提案内容を評

価する。

⑤評価基準を満たしたベンダが入札に参加する。入札金額の内訳は、業務アプリケーションの構築費用、保

守費（必要に応じて運用費）とする。

⑥業務アプリケーションを共通基盤へ搭載することによって発生する増強分（AP 保守・テスト・研修・本番環

境に必要なハードウェア、ミドルウェア、パラメータ変更作業及び、他システムへの影響調査など）につい

ては、共通基盤担当が調達･構築を実施する部分も含め、かかる費用については業務アプリケーション担

当が負担する。

業務要件

基盤ガイドライン

公示

アプリ構築

ハードウエア等

提案

アプリ保守

業務要件の提示

共通基盤搭載へのガイド

システムの内容

保守内容

性能、容量等をもとにサイジング(CPU数等見積り)

アプリ構築

評価

アプリ保守


保守内容

業務システムの調達

＋

アプリ構築

アプリ保守


保守方法の内容


見積りの内容

内容確認


構築

基盤側で見積り精査本番

環境


業務アプリ用機器の調達

調達

業務アプリ用機器の増設

① ②

③

④ ⑤

⑥ ⑥

入札・契約

共通基盤の調達

業務要件

基盤ガイドライン

公示

アプリ構築


提案

アプリ保守

業務要件の提示

共通基盤搭載へのガイド


保守内容

性能、容量等をもとにサイジング(CPU数等見積り)

アプリ構築

評価

アプリ保守


保守内容

業務システムの調達

＋

アプリ構築

アプリ保守


保守方法の内容


見積りの内容

内容確認


構築

基盤側で見積り精査本番

環境


業務アプリ用機器の調達

調達

業務アプリ用機器の増設

① ②

③

④ ⑤

⑥ ⑥

入札・契約

共通基盤の調達

＜構築フェーズ＞

業務アプリケーション担当は、アプリケーションの構築スケジュールと共通基盤の対応スケジュールを合わ

せ、共通基盤担当と協力して業務アプリケーションを構築する。

開発は業務アプリケーション構築受託ベンダが用意するベンダ開発環境にて行う。これ以外に開発に必

要なものについても、業務アプリケーション構築受託ベンダが用意するものとする。AP 保守環境はアプリケ

ーション保守が実施できる必要最小限の構成とし、共通基盤担当が調達、業務アプリケーション構築受託ベ

ンダが構築するものとする。

なお、AP保守環境に必要なスペックなどについては提案内容に含めること。


＜テストフェーズ＞

結合テスト工程まではベンダ開発環境にてテストを実施する。他システムとの連携、回帰テスト、システム

テスト、負荷テスト、受入試験などはテスト環境にて行う。

＜本番環境へのインストール＞

業務アプリケーション担当は、各テストが完了した後に本番環境へインストールを行い、動作を確認する。

動作確認が終了した業務アプリケーションについて、共通基盤側担当が運用を行う。


2.3. 共通基盤構成と利用フェーズ想定

以下に共通基盤の提供する構成と利用フェーズの想定について記載する。

AP保守環境

(保守が可能

な最小構成)

開発

サイジング調達・セットアップ

テスト環境

本番環境

追加調達・セットアップ

（負荷テスト結果、性能要件を満たさない

場合は、業務アプリケーション構築ベンダ

側にて共通基盤担当へ追加の調達を依

頼する。）

OS、ミドルウェアのパッチなどの適用確認

追加開発、改修内容によって各環境へ与える影響を

調査し、各環境の増強要否も合わせて検討。

テスト（個別）

保守（追加開発・改修）

OS、ミドルウェアのパッチはテスト環境で動

作確認を行った後、必要に応じてベンダ開

発環境、AP 保守へ提供する。

OS、ミドルウェアのパッチはテスト環

境で動作確認を行った後、必要に応

じて本番環境に適用する

ベンダ開発環境

テスト（他システム連携、回帰テスト、負荷テスト、受入テストなど）

サービス稼働・運用

サイジング精査


原課管理環境

共通基盤管理環境

ベンダ管理環境

調達・要件定義設計･開発検証･受入検収本番＆保守

サイジング


調達・セットアップ

研修環境


業務研修・訓練


3. アプリケーション実装形態の決定

3.1. 共通基盤想定アプリケーション形態

Web アプリケーションの場合は、まず共通基盤上で SOA アプリケーションとして構築することを検討する。

共通基盤を利用できない場合や SOA アプリケーションとして構築できない場合は、その理由を明確にしてお

くこと。

（①～⑦については、4.1 マトリックス表にて定義）

3.2. （参考）アプリケーションイメージ

（1） SOA と Web

START ②Web

③バッチ

・ネットワークも個別にしたい。

⑤ASP④PKG

①SOA

⑥個別技術 ⑦完全独立

・Webアプリケーションでもなく、パッケージなどでもない。

・Webアプリケーションで構築する

・バッチを想定している。・適合する既成アプリケーションがある（例：パッケージ、外部サービスの利用など）

・外部のサービスをそのまま利用する

Webアプリケーションではあるが・・・・業務フローは特に必要はない。・共通マスタ(*1)や共通サービスは利用しない。・他業務アプリケーションとの連携はない。（利用することも利用されることもない）

(*1)②Webの場合でもデータ連携基盤を利用してマスタデータを個別アプリに配信することは可能。要相談。

（SOA+バッチまたはWeb+バッチ）

START ②Web

③バッチ

・ネットワークも個別にしたい。

⑤ASP④PKG

①SOA

⑥個別技術 ⑦完全独立

・Webアプリケーションでもなく、パッケージなどでもない。

・Webアプリケーションで構築する

・バッチを想定している。・適合する既成アプリケーションがある（例：パッケージ、外部サービスの利用など）

・外部のサービスをそのまま利用する

Webアプリケーションではあるが・・・・業務フローは特に必要はない。・共通マスタ(*1)や共通サービスは利用しない。・他業務アプリケーションとの連携はない。（利用することも利用されることもない）

(*1)②Webの場合でもデータ連携基盤を利用してマスタデータを個別アプリに配信することは可能。要相談。

（SOA+バッチまたはWeb+バッチ）

在庫商品

商品情報を確認する

顧客

画面

利用者情報を確認する

出荷指示をだす

在庫確認する

出荷

①SOAアプリケーション・業務フロー単位での提供となる。・アーキテクチャ的にはサービスを組み合わせて業務フローを開発する。・他業務アプリケーションとの連携はサービスレベルでの連携を前提としている。

XXアプリ

画面

個別アーキテクチャ

②Webアプリケーション・機能単位での提供となる。・アーキテクチャ的にはアプリケーションサーバ上にMVCモデルでの実装が一般的。・他業務アプリケーションとの連携は基本的にはない。

アプリ実行基盤

SOA基盤

統合DB基盤

また今後もその予定はない。


（2）バッチ

（3）パッケージと ASP

パッケージ

画面

④パッケージ・基本的にパッケージは独自となる。

・他業務アプリケーションが提供しているサービスを利用したりその逆は可能であるが、その場合はSOA基盤で実現する。

商品

画面

他業務アプリケーションから

利用

他業務アプリケーションを利用

画面

BI用データ

画面

個別アーキテクチャ

③バッチアプリケーション①SOAアプリケーションタイプや②Webアプリケーションタイプにおいて、「データのファイル出力」「BI用データ収集」などのためにバッチを使用する場合がある。データ連携基盤を利用する。


SOA基盤

統合DB基盤

ファイル出力スクリプト

連携スクリプト

①SOAアプリケーション ②Webアプリケーション

データ連携基盤

③バッチ

⑤ASP・基本的にサーバ及びロジック含め外部に存在。・クライアントのみ存在。

個別

ASP

※ASPサービスからデータを取得して加工するアプリケーションを構築する場合は、「②Web」又は「⑥個別技術」での対応を検討すること。


SOA基盤

統合DB基盤


4. 共通基盤の利用サービスの決定

4.1. アプリケーション実装形態毎の技術構成の活用想定マトリクス表（概要）

共通基盤の提供する MW・OS・HW・NW・ファシリティなどのアプリケーション構築資材（以降、資材）と共通

基盤に関わる運用・保守やアプリケーション構築の際の支援などの作業・情報提供（以降、支援）は、アプリ

ケーションの要件・形態に合わせて部分的な利用が可能である。以下にアプリケーション実装形態毎の共通

基盤提供資源と支援についての活用想定を記載する。以下の表を参考に提供するサービスの選択、決定を

行うこと。

【アプリケーション実装形態】

①SOA・・・推奨する SOAの考え方にのっとり、サービスを利用したアプリケーション開発。

②Web・・・個別アプリケーション内部実装方式としてサービス化やサービス提供はしない従来どおりのJavaに

よる Web アプリケーション開発。

③バッチ・・共通基盤の提供する技術を利用した、データ連携も含むバッチ処理の開発。

④PKG・・・ EBS,SAP などの業務パッケージ導入。

⑤ASP・・・ ASP サービスの活用による IT 外部委託。

⑥個別・・・共通基盤のサービスを最小限利用する（認証基盤やネットワーク、ファシリティなど）が、これ以外の

機能は業務要件を満たせないため個別に構築する。

⑦独立・・・センターの設置場所以外、NW も含め共通基盤が用意したものを利用しない業務アプリケーション。

【活用想定】

◎・・・利用必須。アプリケーション要件の有無に関わらずアプリケーション開発には必ず利用する。標準技術・

利用規定準拠の上利用。

○・・・利用任意。アプリケーション要件によって各プロジェクトで利用判断。利用時は標準技術・利用規定準拠

の上利用。

△・・・利用任意。アプリケーション要件によって各プロジェクトで利用判断。アプリケーション要件が特殊な場合

は個別調整の上、運用も含めたプロジェクト個別調達の余地あり。個別調達の場合、共通基盤担当での

保守運用は別途費用面の調整を行い判断。

×・・・利用不可。運用も含めプロジェクト個別調達。

完全共通

基盤化

一部共通基盤化 ASP 個別システム化

カテゴリ ①SOA ②Web ③バッチ ④PKG ⑤ASP ⑥個別 ⑦独立

業務アプリケーション開発支援 ◎ ○ ◎ × × ◎ ×

認証基盤 ◎ ◎ × ◎ △ ◎ ×

運用基盤 ◎ ◎ ○ △ × △ ×

可視化基盤 ◎ ○ △ ○ △ △ ×

データ連携基盤 ○ ○ ◎ ○ △ ○ ×

SOA 基盤 ◎ × ○ ○ △ △ ×

アプリ実行基盤 ◎ ◎ ◎ × × × ×

ミドルウェア

統合データベース基盤 ◎ ◎ ○ △ × × ×

ネットワーク基盤 ◎ ◎ ◎ ◎ × × ×

オペレーティングシステム（OS） ◎ ◎ ◎ ◎ × × ×

ハードウェア（HW） ◎ ◎ ◎ ◎ × × ×

ファシリティ ◎ ◎ ◎ ◎ × ◎ △

基本コンポーネント運用 ◎ ◎ ◎ △ × △ ×


4.2. アプリケーション実装形態毎の技術構成の活用想定イメージ

共通基盤の適用については、スケジュール及びシステムの特性により、適用のパターンを 4つに大別。

4.3. 業務アプリケーションによる基盤の共同利用方針

アプリ実行基盤（Web/AP サーバ）、統合データベース基盤（DB サーバ）以外の基盤については、基本的

に各業務アプリケーションでの共同利用を想定している。アプリ実行基盤（Web/AP サーバ）、統合データベ

ース基盤（DB サーバ）については、障害時の影響範囲が同程度であることなどを条件として共同利用を行う

ことを想定している。実際に共同利用を行うかについては、共通基盤担当、業務アプリケーション担当、業務

アプリケーション構築の受託ベンダの間で検討し、最終的に決定する。

4.4. 共通基盤サービス利用申請・承認

共通基盤のサービスを利用（新規、変更、削除）する場合には、業務アプリケーション担当から共通基盤

担当へ申請書を提示し、共通基盤担当で承認後に共通基盤の増設などの対応を行う。具体的な申請書、申

請方法、承認方法、承認フローなどについては、共通基盤ガイドライン（実装編）に記載しており、業務アプリ

ケーション構築受託後に提示する。

ミドルウェア

アプリA開発支援基盤

運用基盤

アプリB

アプリ実行基盤アプリ実行基盤アプリ実行基盤

アプリC

アプリ実行基盤アプリD

認証基盤

統合DB基盤

可視化基盤

SOA基盤


業務PKGアプリ個別技術

アプリASPアプリ

バッチアプリ

オペレーティングシステム

ハードウェア

ネットワーク

ファシリティ

運用

独自インフラ

独自インフラ

独自インフラ

共通基盤化（全面適用）⇒共通基盤を全面的に適用。

一部共通基盤化（部分適用）⇒システムの入り口部分（ネットワーク、ポータル）に限定して共通基盤を適用。

個別システム化⇒特殊な構成のシステムは個別に構築。

ＡＳＰ⇒ＡＳＰを利用し、構築しない

①SOA ②Web ③バッチ ④業務PKG ⑤ASP ⑥個別技術 ⑦完全独立

ミドルウェア

アプリA開発支援基盤

運用基盤

アプリB

アプリ実行基盤アプリ実行基盤アプリ実行基盤

アプリC

アプリ実行基盤アプリD

認証基盤

統合DB基盤

可視化基盤

SOA基盤


業務PKGアプリ個別技術

アプリASPアプリ

バッチアプリ

オペレーティングシステム

ハードウェア

ネットワーク

ファシリティ

運用

独自インフラ

独自インフラ

独自インフラ

共通基盤化（全面適用）⇒共通基盤を全面的に適用。

一部共通基盤化（部分適用）⇒システムの入り口部分（ネットワーク、ポータル）に限定して共通基盤を適用。

個別システム化⇒特殊な構成のシステムは個別に構築。

ＡＳＰ⇒ＡＳＰを利用し、構築しない

①SOA ②Web ③バッチ ④業務PKG ⑤ASP ⑥個別技術 ⑦完全独立①SOA ②Web ③バッチ ④業務PKG ⑤ASP ⑥個別技術 ⑦完全独立


5. 共通基盤の提供機能

5.1. 共通基盤構成概要

共通基盤の論理構成の概要を記載する。詳細な論理構成、物理構成については、共通基盤ガイドライン

（実装編）に記載しており、業務アプリケーション構築受託後に提示する。


5.2. 共通基盤提供機能一覧

共通基盤の提供する機能一覧を記載する。具体的な製品名、バージョンについては、共通基盤ガイドライ

ン（実装編）に記載しており、業務アプリケーション構築受託後に提示する。

基本的には、共通基盤担当の指定するデフォルト値での提供となるが、一部についてはカスタマイズ提供

可能とする。具体的なデフォルト値、カスタマイズ提供範囲については、共通基盤ガイドライン（実装編）に記

載しており、業務アプリケーション構築受託後に提示する。

5.2.1. ネットワーク基盤

機能説明

インターネット接続ルータインターネットとの接続機能を提供する。

インターネット接続用マルチホーム機

器

インターネット回線の負荷分散機能を提供する。

インターネット接続用ファイアウォー

ル（不正アクセス制御）

インターネットと共通基盤の間の通信制御機能を提供する。

インターネット接続用帯域制御装置業務アプリケーション毎にインターネット接続の通信帯域の制御機能を提供する。

インターネット接続用侵入検知・防御インターネットと接続される箇所にてパケットの中身を分析し、ファイアウォールでは防ぎ

きれない脅威から共通基盤を守る侵入検知・防御機能を提供する。

インターネットロードバランサインターネット上のクライアントから業務アプリケーションへアクセスを行う際に、サーバ

への負荷分散を行う機能を提供する。

インターネット接続用 L2 スイッチインターネットと接続される箇所にて L2 スイッチとしての機能を提供する。

センター間接続用ルータ WAN（センター）との接続機能を提供する。

支店/支社間接続用ルータ WAN（支店/支社）との接続機能を提供する。

外部接続用帯域制御装置業務アプリケーション毎に WAN（センター、支店/支社）接続の通信帯域の制御機能を提

供する。

外部接続用侵入検知・防御 WAN（センター、支店/支社）と接続される箇所にてパケットの中身を分析し、ファイアウォ

ールでは防ぎきれない脅威から共通基盤を守る侵入検知・防御機能を提供する。

外部接続用ファイアウォール（不正ア

クセス制御）

WAN（センター、支店/支社）と共通基盤の間の通信制御機能を提供する。

外部接続用 L2 スイッチ WAN（センター、支店/支社）と接続される箇所にて L2 スイッチとしての機能を提供する。

SSO、内部 Web、外部 Web、AP、DB

セグメントコアスイッチ

インターネットとイントラネットの論理セグメントの分離、及び通信制御機能を提供する。

イントラネットロードバランサイントラネット上のクライアントから業務アプリケーションへアクセスを行う際に、サーバへ

の負荷分散を行う機能を提供する。

AP サーバ接続用 L2 スイッチ AP サーバと接続される箇所にて L2 スイッチとしての機能を提供する。

DB サーバ接続用 L2 スイッチ DB サーバと接続される箇所にて L2 スイッチとしての機能を提供する。

管理接続用 L2 スイッチ管理・運用サーバと接続される箇所にて L2 スイッチとして機能を提供する。


機能説明

管理用リモートコンソールサーバ装置ネットワーク機器をシリアルコンソールサーバに接続することで、シリアル操作をリモート

から操作する機能を提供する。

管理用 NW リモート電源操作装置ネットワーク機器のリモートからの電源オフ・オン機能を提供する。

管理用 NTP装置サーバ機器、ネットワーク機器において、時刻同期を行う機能を提供する。

5.2.2. 認証基盤

機能説明

リバースプロキシサーバ AD 認証連携、統合認証連携機能を具備し、対向システムを含めた認証インタフェースを

提供する。[製品] IceWall SSO

SSO＆認証サーバ追跡システムを源泉とした IDマスタファイルを取り込み、取り込んだ ID情報を業務アプリ

ケーションに公開する機能を提供する。[製品] IceWall SSO、IceWall Identity Manager

5.2.3. 運用基盤

機能説明

トラフィック測定ネットワークトラフィック測定及びレポーティング機能を提供する。

DB ログ収集データベースに対するアクセス情報を監視してアクセスログを蓄積し、不正アクセス者を

追跡する機能を提供する。

システムログサーバやNW機器などが出力するログを統合的に一元管理する機能を提供する。

特権ログサーバへのアクセスを一元管理し、サーバへのアクセス記録を集中管理・分析する機能

を提供する。

ジョブスケジューラ共通基盤の MW、業務アプリケーションなどのバッチジョブの自動実行を制御する機能を

提供する。

[製品] JP1/AJS3

コンソールサーバ管理ネットワーク機器のログ管理/設定情報管理、ネットワーク管理者の証跡管理/権限管理

機能を提供する。

ウィルス対策共通基盤内の OS（HP-UX、RHEL、Windows）のウィルス対策を一元管理する機能を提

供する。

[製品] Sophos Anti-Virus

チケット管理 ITIL ベースのチケット管理により、インシデント、変更管理と構成管理などの主要な IT

プロセスを自動化し、統合する機能を提供する。

帯域制御共通基盤内の帯域制御装置を一元管理する機能を提供する。

バックアップ共通基盤内のシステム・業務データのバックアップ機能を提供する。

[製品]Veritas NetBackup

ブレード管理共通基盤内のブレードサーバの管理機能を提供する。

SAN 管理共通基盤内の SAN ストレージの管理機能を提供する。


機能説明

機器管理・監視共通基盤内の各サーバに対する死活監視、ログ監視、リソース監視機能を提供する。

[製品] HP Operation Manager

商用 UNIX バックアップ OS（HP-UX）にバンドルされる基本ミドルウェアで、HP-UXのシステムバックアップ機能を

提供する。

Web アプリケーションの機能テスト、

負荷測定

Web アプリケーションの機能テスト、負荷測定の機能を提供する。

Web サービスの負荷測定 Web サービスの負荷測定の機能を提供する。

5.2.4. データ連携・可視化基盤

機能説明

SOA&BI 用 Web サーバ HTTPなどの問合せを受付け、要求内容に従ってSOAサーバ又はBIサーバに要求を送

信する機能を提供する。

SOA サーバ ESB、BPEL、Service Security、Rule Engine、BAM機能を提供する。

[製品] Oracle Weblogic Suite、Oracle SOA Suite For Oracle Middleware

BI サーバダッシュボード、レポーティング、分析・クエリ、アラートなど、業務データの分析機能を提

供する。

[製品] Oracle WebLogic Server Standard Edition、Oracle Business Intelligence Suite

Enterprise Edition Plus

5.2.5. 共用アプリケーション基盤

機能説明

メールサーバ電子メールの送受信を行う機能を提供する。

メール中継サーバ共通基盤内のサーバがインターネットへメールを送信する際にメールを中継する機能、

パターンマッチングによるウィルスチェック機能を提供する。

内/外 DNS サーバ名前解決を行う機能を提供。PNET や他システムとの通信には内 DNS サーバ、外部接

続などインターネット網との通信には外 DNSサーバを使用する。

プロキシサーバ社内サーバなどから外部Web アクセスをするための機能を提供する。

WEB/AP サーバ業務アプリケーションを実行する基盤としての機能を提供する。

[製品] Weblogic Standard Edition

SSO&IDM 用 DB サーバ SSO、IDM のデータを管理するためのデータベース機能を提供する。

DB サーバ各種マスタデータや MW 用データなど、各業務アプリケーションや運用基盤が共通で用

いる多用途のデータベース機能を提供する。

[製品] Oracle 11g Enterprise Edition + オプション

イントラネット用 NAS ストレージ PNETと通信を行うサーバー群に対して、統合データベース機能で使用されるデータやシ

ステムログ、クラスタ構成を組む上で共用する必要のあるデータなどを保存する機能を

提供する。


機能説明

インターネット用 NAS ストレージインターネットに接続するサーバー群に対して、統合データベース機能で使用されるデー

タやシステムログ、クラスタ構成を組む上で共用する必要のあるデータなどを保存する機

能を提供する。

2 次 NAS ストレージイントラネット用NASストレージ及びインターネット用NASストレージのバックアップデータ

を同一サイト内で保存する機能を提供する。

3 次 NAS ストレージイントラネット用NASストレージ及びインターネット用NASストレージのバックアップデータ

を遠隔地で保存する機能を提供する。

SAN ストレージ SSO&IDM 用 DB サーバで使用されるデータを保存する機能を提供する。

管理用 NTP装置サーバ機器、NW機器において、時刻同期を行う機能を提供する。

5.3. 共通基盤提供機器スペック

共通基盤で提供する標準の機器（HW、OS）のスペックを記載する。なお、業務アプリケーションを搭載する

機器及びサービスとして機能を提供する機器のみ記載する。記載したスペックは、2013/10/11 時点の情報

であり、今後変更される可能性があるため、実際に利用を検討する際には共通基盤担当に確認すること。

（1） HP Integrity Superdome 2

項目内容

製品名 HP Integrity Superdome 2 16s

セルブレード CB900s i2 標準構成 8

CPU Itanium 1.73GHz

Quad Core (9350)

標準構成 16 プロセッサ/64 コア

最小構成 256GB （1 セルブレードあたり 32GB 「4GB DIMM ×4 ×2組」 ×8 セルブレード）メモリ

最大構成 2TB （1 セルブレードあたり 256GB 「8GB DIMM ×4 ×8 組」 ×8 セルブレード）

DISK 外付け FC または SAS 接続ディスク

NIC/FC 標準構成オンボード・・・10Gb 2 ポート ×2 計 4 ポート

拡張(IOX)・・・10Gb 2 ポート ×4 計 8 ポート

・・・１Gb 4 ポート ×2 計 8 ポート

拡張(IOX)・・・8Gb FC HBA 2 ポート×4 計 8 ポート

※本構成を必要とする場合は、別途共通基盤担当に確認すること。

IOX エンクロージャ標準構成 4 台拡張スロット

PCIe スロット（1IOX

につき 2 ベイ）

標準構成 48 スロット（1 ベイあたり 6 スロット）

OS HP-UX 11i


（a） nPar の構成

項目内容

最小構成 8 コア CPU

最大構成 64 コア

最小構成 32GB メモリ

最大構成 2TB



・・・１Gb 4 ポート ×2 計 8 ポート



IOX エンクロージャ標準構成 2 ベイ拡張スロット

PCIe スロット（1IOX

につき 2 ベイ）

標準構成 12 スロット（1 ベイあたり 6 スロット）

（b） vPar の構成

項目内容

最小構成 1 コア CPU

最大構成 64 コア

最小構成１GB メモリ

最大構成 2TB （2GB を管理領域として使用する。）



・・・１Gb 4 ポート ×1 計 4 ポート



拡張スロット PCIe スロット標準構成 6 スロット


（2） HP Integrity BL860c i2 サーバーブレード

項目内容

製品名 HP Integrity BL860c i2

サイズフルハイト（C7000 エンクロージャに最大 8 台）

CPU Itanium 1.73GHz

Quad Core (9350)


メモリ標準構成 16GB

DISK（内蔵）標準構成 300GB (300GB/10krpm 2.5 インチ ×2 台 RAID1)

オンボード 1Gb 2 ポート ×2 計 4 ポート NIC

拡張スロット 1Gb 4 ポート ×1 計 4 ポート

OS HP-UX 11i


項目内容


サイズワイドフルハイト（C7000 エンクロージャに最大 4 台）

CPU Itanium 1.73GHz

Quad Core (9350)




オンボード 1Gb 2 ポート ×2×2 計 8 ポート NIC


OS HP-UX 11i

（4） HP ProLiant BL620c G7 サーバーブレード

項目内容

製品名 HP ProLiant BL620c G7


CPU Xeoｎ E7-2830 2.13GHz 標準構成 1 プロセッサ/8 コア


DISK（内蔵）最小構成 300GB (300GB/10krpm 2.5 インチ ×2 台 RAID1)



OS RedHat Linux 5 , Windows Server 2008R2


（5） HP ProLiant BL460c G7 サーバーブレード

項目内容

製品名 HP ProLiant BL460c G7

サイズハーフハイト（C7000 エンクロージャに最大 16 台）

CPU Xeoｎ X5672 3.2GHz 標準構成 1 プロセッサ/4 コア





OS RedHat Linux 5 , Windows Server2008R2


項目内容



CPU Itanium 2.53GHz

Octa Core (9560)






FC 拡張スロット 8Gb 2 ポート ×2 計 4 ポート

OS HP-UX 11i


項目内容


サイズワイドフルハイト（C7000 エンクロージャに最大 4 台）

CPU Itanium 2.53GHz

Octa Core (9560)




オンボード 1Gb 2 ポート ×2×2 計 8 ポート NIC


FC 拡張スロット 8Gb 2 ポート ×2 計 4 ポート

OS HP-UX 11i


（8） HP ProLiant BL660c Gen8 サーバーブレード

項目内容

製品名 HP ProLiant BL660c Gen8








（9） HP ProLiant BL460c Gen8 サーバーブレード

項目内容

製品名 HP ProLiant BL460c Gen8

サイズハーフハイト（C7000 エンクロージャに最大 16 台）








（10）サーバ機能-HW機器選定マトリクス

サーバ機能から HW 機器を選定する際に、参考にするマトリクスを記載する。実際に利用を検討する際に

は共通基盤担当に確認すること。

Superdo

me 2

BL860

c i2

BL870

c i2

BL620

c G7

BL460

c G7

BL860

c i4

BL870

c i4

BL660

c Gen8

BL460

c Gen8

DB サーバ ○ ○ ○ ● ● ●

SOA サーバ ○

HA 構成サーバ ※1 ○ ●

WEB/AP サーバ ○ ●

○・・・JPI13 ●・・・JPI14 以降

※1 可用性を持たせるためにクラスタリングソフトで HA を組むサーバ


5.4. 共通基盤提供機器搭載インタフェース構成

共通基盤で提供する機器の搭載インタフェースの標準構成を記載する。サービス系については複数の

NIC を使用することで、単一障害点を作らないことを基本方針とする。

（1） HP Integrity Superdome 2 インタフェース構成

インタフェース通信速度ポートセグメント冗長構成

1 未使用 - オンボード 1 10Gb

2 未使用 -


4 未使用 -

1 監視 Active

2 バックアップ Active

3 NFS Active

PCIe1 1Gb

4 未使用 -

1 Fibre Channel ※2 - PCIe2 8Gb

2 Fibre Channel ※2 -

1 サービス系（裏） Active PCIe3 10Gb

2 未使用 -



1 HA Active PCIe5 10Gb

2 未使用 -

IOX エンク

ロージャ

ベイ 1

PCIe6 未搭載 ※1

1 監視 Standby

2 バックアップ Standby

3 NFS Standby

PCIe1 1Gb

4 未使用 -



1 サービス系（裏） Standby PCIe3 10Gb

2 未使用 -



1 HA Standby PCIe5 10Gb

2 未使用 -

IOX エンク

ロージャ

ベイ 2

PCIe6 未搭載 ※1

※1 PCIe6 は NIC 及び Fibre Channel を搭載することが可能。

※2 Fibre Channel の使用ポート数は要件により決定する。


（2） HP Integrity BL860c i2 サーバーブレードインタフェース構成


1 サービス系（表） Active オンボード 1 1Gb

2 サービス系（裏） Active


2 監視 -

1 Fibre Channel ※3 - メザニン 1 8Gb


1 サービス系（表） Standby

2 サービス系（裏） Standby

3 バックアップ -

メザニン 2 1Gb

4 未使用 -

1

2

3

メザニン 3 1Gb

4

未搭載 ※4

※3 Fibre Channel を使用する場合は、メザニン 1 に搭載する。

※4 メザニン 3 には NIC を搭載することが可能。







2 監視 -

1 - - オンボード 3 1Gb

2 - -

1 - - オンボード 4 1Gb

2 - -






メザニン 2 1Gb

4 未使用 -

1

2

3

メザニン 3 1Gb

4

未搭載 ※6



1

2

3

メザニン 5 1Gb

4

未搭載 ※6

1

2

3

メザニン 6 1Gb

4

未搭載 ※6

※5 Fibre Channel を使用する場合は、メザニン 1、4 に搭載する。

※6 メザニン 3、5、6 には NIC を搭載することが可能。


（4） HP ProLiant BL620c G7 サーバーブレードインタフェース構成




1 HA Active オンボード 2 1Gb

2 監視 -





3 HA Standby

メザニン 2 1Gb


1

2

3

メザニン 3 1Gb

4

未搭載 ※8



（5） HP ProLiant BL460c G7 サーバーブレードインタフェース構成


1 サービス系（表） Active オンボード 1Gb






3 監視 -

メザニン 2 1Gb






1 サービス(裏) Active オンボード 1 1Gb

2 HA Active

1 NFS Active オンボード 2 1Gb


1 サービス(裏) Standby

2 HA Standby

3 NFS Standby

メザニン 1 1Gb

4 監視 -










2 HA Active




2 HA Standby

3 NFS Standby

メザニン 1 1Gb

4 監視 -





1

2

3

メザニン 4 1Gb

4

未搭載 ※13






※12 メザニン 3、5 には FC-HBA を搭載することが可能。



（8） HP ProLiant BL660c Gen8 サーバーブレードインタフェース構成

（a） DB サーバ以外の構成




1 HA Active オンボード 2 1Gb

2 監視 -

1 Fibre Channel ※14 メザニン 1 8Gb

2 Fibre Channel ※14



3 HA Standby

メザニン 2 1Gb


1

2

3

メザニン 3 1Gb

4

未搭載 ※15



（b） DB サーバ構成



2 HA Active




2 HA Standby

3 NFS Standby

メザニン 1 1Gb

4 監視 -







（9） HP ProLiant BL460c Gen8 サーバーブレードインタフェース構成


1 サービス系（表） Active オンボード 1Gb






3 監視 -

メザニン 2 1Gb




6. 共通基盤提供範囲とアプリケーション構築者対応事項

6.1. ネットワーク基盤

以下に共通基盤の提供するネットワーク（NW）機器について、目的と役割、利用イメージ及び共通基盤で

提供する内容と、業務アプリケーション担当対応事項について記載する。

目的と役割

【目的】

インターネット接続部分と、各種WANなどを用いたイントラネット接続部分、及び共通基盤や業務アプリケーシ

ョンへの接続部分との内部接続を提供

【役割】

・WAN回線（支店・支社接続含む）、PNET、インターネットとの接続機能の提供

・ネットワーク基盤に接続する回線や業務アプリケーションとの間の通信制御・侵入検知機能の提供

・ネットワーク基盤に接続するクライアントから業務アプリケーションへアクセスを行う際の負荷分散機能の提

供

・業務アプリケーション毎に通信帯域の制御を行う機能の提供

【提供予定機器】

Router、FireWall、侵入検知・防御、Load Balancer、帯域制御


利用イメージ

蔵前センタ

（PNET、各システム）支店/支社インターネット

センタ間接続用ルータインターネット接続用ルータ

マルチホーム用機器

ファイアウォール

帯域制御装置

進入検知・防御

ロードバランサ

セキュリティ機能を提供する装置

業務業務APAP（イントラネット（イントラネット))

イントラネットセグメントイントラネットセグメントインターネットセグメントインターネットセグメント

内部セグメント内部セグメント


侵入検知・防御

帯域制御装置


支店/支社間接続用ルータ

外部外部WebWeb

業務業務APAP（インターネット（インターネット))

仮想ファイアウォール


SSOSSO APAP DBDB

内部内部WebWeb（メール・プロキシ・（メール・プロキシ・DNSDNS））










外部外部連携連携


（メール・プロキシ（メール・プロキシ

WAF

DNSDNS・外部連携・外部連携））

蔵前センタ

（PNET、各システム）支店/支社インターネット

センタ間接続用ルータインターネット接続用ルータ

マルチホーム用機器


帯域制御装置

進入検知・防御


セキュリティ機能を提供する装置

業務業務APAP（イントラネット（イントラネット))

イントラネットセグメントイントラネットセグメントインターネットセグメントインターネットセグメント

内部セグメント内部セグメント


侵入検知・防御

帯域制御装置


支店/支社間接続用ルータ

外部外部WebWeb

業務業務APAP（インターネット（インターネット))



SSOSSO APAP DBDB

内部内部WebWeb（メール・プロキシ・（メール・プロキシ・DNSDNS））










外部外部連携連携


（メール・プロキシ（メール・プロキシ

WAF

DNSDNS・外部連携・外部連携））

リモートアクセスセグメント


業務アプリケーション担当対応事項共通基盤担当提供事項

・共通基盤で敷設した NW を利用する。

・業務アプリケーション構築に必要な NW経路につい

て提示し、協議・検討する。

（当初は PNET との利用調整となる。）

・センター内 LAN、センター間WAN を提供予定。

・郵便局及び各支店へのアクセスには PNET を提供予

定。

・インターネットへ接続可能な回線を提供予定。

・NW利用にあたって、プロジェクト毎にサイジングを行

い、必要帯域を提示する。

・帯域制御の要否、ベストエフォートの可否について

連絡する。

・NWは共通基盤担当が敷設する。

・サイジングにあたっての基礎値や参考値の提供及び

検討支援を共通基盤担当から提供する。

・特殊な NW構成が必要な場合には、NW構成の変更

要望、内容と理由を提示し協議を行う。

（例：ルーティングの変更、ポート解放など）

・原則として NW機器の追加は認めない。

・NWの変更は共通基盤担当で実施する。

・現状の構成情報を提供する。

・NW の増強依頼を行う際は、その内容と理由、変更

情報の提示及び指示を行う。

・他システムへの影響を調査し、問題がなければNW

を増強する。


6.2. 認証基盤

以下に共通基盤の提供するミドルウェアのうち「認証基盤」について、目的と役割、利用イメージ及び共通

基盤で提供する内容と、業務アプリケーション担当対応事項について記載する。

目的と役割

【目的】

認証基盤はシングルサインオンによるユーザ認証に必要なミドルウェアを提供

【役割】

・ユーザが一度認証を受けるだけで、許可されている全てのアプリケーションに対する認証を可能とするため

の機能の提供（リバースプロキシ方式）

・利用者のユーザ ID、プロファイルの設定を継続的に追加・変更・削除を可能にするための機能の提供

・認証・認可処理に対しての監査機能の提供

・各業務画面を統合するための機能の実装・動作環境の提供

【提供予定ミドルウェア】

Single Sign On（SSO）、ID Management（IdM）ミドルウェア、Portal

利用イメージ

認証

認証、認可情報保持人事マスタ

ＩＤ情報取込

認証基盤

機能利用

Portal

ログイン画面初回ログイン

ID管理データベース

ID 管理機能 Single-SignOn機能

ポリシー定義

認証


業務アプリ

ＩＤ管理作業

… 開発者開発 / 定義部分 … ミドルウェア ※ 点線：利用任意（完全共通基盤化時）

【凡例】【凡例】



・ミドルウェアのインストール及び設定に必要な情報に

関して、特に提示する必要はないが、必要な場合

（Web アプリケーションの URL など）は情報提供を行

う。共通基盤担当からの問い合わせには随時対応す

る。

・SSO 対応要否について連絡する。

・共通基盤で選定したミドルウェアのインストール及び

設定変更を行う。

・セキュリティ基盤は高度な可用性・信頼性に対応可能

な冗長構成を提供する。

・当該ミドルウェアの調達に関しては、プロジェクト毎に

サイジングを行い、ライセンス必要数を提示する。

（例：ログイン・アクセス数（ピーク時/平均）、対象ユ

ーザ数など）

・サイジングは 1度ではなく、企画・実装・テスト段階な

ど複数の段階で実測し精度を向上させる。想定外の

結果が出た場合はすぐに共通基盤担当に連絡・相

談する。



・ミドルウェアの設定変更やチューニングの依頼は業

務アプリケーション担当から情報の提示及び指示を

行う。

・他システムへの影響を調査し、問題がなければミドル

ウェアの設定変更やチューニングを行う。

・共通基盤で選定したミドルウェア製品を利用して業

務アプリケーション実装を行う。

・セキュリティ及びユーザ利便性の観点より共通基盤

のNW上に配置されるアプリケーションは、例外なく

SSO対応を行う。

・業務パッケージ及び個別システム構築する場合にお

いても対応可能とする。

・セキュリティ基盤は SSO によるユーザ利便性・セキュ

リティの向上を実現し、開発・運用を容易にするために

必要なミドルウェア・ガイドラインを提供する。

・ID の一元管理、ID 情報の信頼性確保のため、独自

に ID 管理しないことを推奨する。

・ID管理のため既存システムからのユーザID情報の取

込・同期更新など、日々の ID の管理作業は共通基盤

で行う。

・プロジェクト個別にて、認可（ユーザ権限による機能

利用可否制御）のための情報整備・管理、仕組みの

設計・実装を行う。

・認可の提供は行わない。

・ログイン画面、メニュー画面、ポータル画面などの機

能要件がある場合は、共通基盤で提供するポータル

画面、及びログイン、ログアウト機能などを利用でき

るか検討する。

・ポータル画面、及びログイン、ログアウト機能などを提

供する。


6.3. 運用基盤

以下に共通基盤の提供するミドルウェアのうち「運用基盤」について、目的と役割、利用イメージ及び共通


目的と役割

【目的】

共通基盤上で稼働するシステムを監視し、運用を行うために必要なミドルウェアを提供

【役割】

・各種システムリソース及びサービスなどアプリケーションの監視機能の提供

・運用自動化のためのジョブ管理機能の実装・動作環境の提供


JobController、LogAnalyzer、SystemMonitoring、BackupManager、Repository（提供時期未定）、

VersionControl（提供時期未定）ミドルウェア

利用イメージ

運用監視基盤

LogAnalyzer

Log収集定義

JobController

Job登録・管理

SystemMonitoring

対象・閾値定義

BackupManager

バックアップ定義

監視機能

通知

スケジュール機能

通知機能

ログ収集機能

ログ分析機能

通知機能

バックアップ機能

各基盤技術

履歴管理機能

スケジュール機能

Repository（本番）

設計成果物管理

サービス定義管理

依存性分析

VersionControl（本番）

ソースコード管理

履歴管理

監視・設定

分析

共通基盤（運用担当）

ソースコード&設計成果物（最終版）

ソース・設計成果物最終版管理

監視

…開発者開発/定義部分

…ミドルウェア ※点線：利用任意（完全共通基盤化時）

【凡例】



【凡例】

開発者開発管理者

共通基盤（運用担当）

提供時期未定



・監視・運用管理対象の機器、対象物、希望運用要件

などに関しての情報の提示及び協議を行う。

・運用に関して、他プロジェクトの現状の監視・運用レベ

ルなどの参考情報を提示する。

・監視・運用管理基盤のミドルウェアのインストール及

び設定に必要な情報に関して、特に提示する必要は

ないが、必要な場合は情報提供を行う。共通基盤担

当からの問い合わせには随時対応する。

・インストール及び設定変更は共通基盤担当で実施す

る。

・当該ミドルウェアの調達に関しては、プロジェクト毎

にサイジングを行い、ライセンス必要数を提示する。

（例：管理対象サーバ、ログ出力量、アプリケーション

規模、アクセス数（ピーク/平均）、保持データ量、調

達など）

・サイジングの値に対して想定外の結果が出た場合

は共通基盤担当に連絡・相談すること。

・サイジングに当たっての基礎値や参考値の提供及び


・監視・運用管理対象の構成変更情報は業務アプリ

ケーション担当から情報を提示する。

・他システムへの影響を調査し、問題がなければ変更

する。

・HW、OS、NW、MW、アプリケーションの監視を行いた

い場合は、共通基盤で選定した製品を利用しての実

現を検討する。

・システムを総合的に監視する監視ツール（System

Monitoring）を提供する。

・ジョブのスケジュール実行などの要件がある場合

は、共通基盤で選定した製品を利用しての実現を検

討する。

・ジョブのスケジュール起動を行う運行管理ツール（Job

Controller）を提供する。

・バックアップを行う要件がある場合は、共通基盤で

選定した製品を利用しての実現を検討する。

・バックアップ運用管理ツール（Backup Manager）を提供

する。

・監視対象のログを収集し傾向分析などを行う要件が

ある場合は、共通基盤で選定した製品を利用しての

実現を検討する。

・ログの収集・分析機能開発を容易にするログ分析ツー

ル（LogAnalyzer）を提供する。

・共通基盤でのソースコードのバージョン管理、設計

成果物の構成管理については提供時期未定である

が、提供された場合は、下記 2点を検討する。

・ソースコードなどの開発成果物及び設計ドキュメン

ト、サービス定義などの設計成果物の管理を行う場

合は、共通基盤で選定した製品を利用しての実現を

検討する。

・本番用途の最終成果物一式を、業務アプリケーショ

ン担当保存用とは別に共通基盤担当に提示する。

・ソースコード管理のためのバージョン管理

（VersionControl）及び設計成果物管理のためのリポ

ジトリ（Repository）環境の提供を検討する。（提供時期

未定）

・受領した最終成果物を登録管理し、構成管理を行うこ

とを検討する。（提供時期未定）


6.4. データ連携・可視化基盤

6.4.1. 可視化基盤

以下に共通基盤の提供するミドルウェアのうち「可視化基盤」について、目的と役割、利用イメージ及び共

通基盤で提供する内容と、業務アプリケーション担当対応事項について記載する。

目的と役割

【目的】

画面、帳票など UI 開発・統合を支援し、情報プロセスを可視化するために必要なミドルウェアを提供

【役割】

・帳票などのエンドユーザへのデータ出力を行うための機能の実装・動作環境の提供（提供時期未定）

・業務データの分析を実現するための機能の実装・動作環境の提供


Reports（H25.4 以降提供予定）、BI

イメージ

可視化基盤


データ・ウェアハウス/データ・マート

BI

チャート画面定義分析モデル定義

SOA基盤

データ抽出

BPEL

ビジネスプロセス

業務アプリ画面

チャート画面定義

BAM

ビジネスイベント情報

ポータル画面開発

Portal

Reports

業務データ

データ抽出

帳票開発

画面/帳票出力リクエスト

ポータル画面リクエスト

画面統合

… 開発者開発/ 定義部分 … ミドルウェア ※点線：利用任意（完全共通基盤化時）

【凡例】 … 開発者開発/ 定義部分 … ミドルウェア ※点線：利用任意（完全共通基盤化時）

【凡例】

認証基盤



・ミドルウェアのインストール及び設定に必要な情報・

要件の提示を行う。（例：接続先サーバ/DB など）



・搭載予定の業務アプリケーションの稼働時間を把握

し、当該ミドルウェアの冗長構成の要否を提示する。

・高度な可用性・信頼性に対応可能な共通基盤を提供

する。業務アプリケーションの可用性レベルに合わせ

た構成を選択可能とする。



（例：アクセス数（ピーク/平均）、処理データ量、

Report 出力量・頻度など）

・サイジングは 1 度ではなく、企画・実装・テスト段階な



談する。





行う。





・提供ミドルウェアの部分的利用が可能。どのミドルウ

ェアを利用するか提示する。

・可視化基盤は、帳票の生成、データの分析画面の生

成など、業務アプリケーションにおける各種情報の可

視化機能を構築する場合に、開発・運用を容易にする

ために必要なミドルウェア・ガイドラインを提供する。

・帳票生成・出力要件がある場合は、共通基盤で選定

したミドルウェア製品を利用しての設計・実装を検討

する。

・Reports ミドルウェアにより、帳票デザイン、各種形式

（PDF,Word,etc）によるデジタル出力、プリンタ、Mail 出

力機能などの帳票を開発するための支援機能を提供

する。（H25.4 以降提供予定）

・業務データの分析（チャート化・多次元分析・マイニ

ングなど）の機能要件がある場合は、共通基盤で選

定したミドルウェア製品を利用しての設計・実装を検

討する。

・BI ミドルウェアにより、データのチャート（図・表・グラ

フ）形式表示機能、多次元分析機能、ダッシュボード

表示、帳票出力機能などの業務データ分析機能を開

発するための支援機能を提供する。


6.4.2. データ連携基盤

以下に共通基盤の提供するミドルウェアのうち「データ連携基盤」について、目的と役割、利用イメージ及

び共通基盤で提供する内容と、業務アプリケーション担当対応事項について記載する。

目的と役割

【目的】

各システム間の大量データ連携・同期に必要なミドルウェアを提供

【役割】

・抽出・変換・ロードのデータ連携機能の開発及びデータ連携管理を容易にするため機能の提供

・各種アダプタなどの提供による多様な技術への対応が可能なデータアクセス機能の提供

・情報源のデータ変更を感知し変更を伝播・反映可能な技術の提供


ETL/ELT ミドルウェア（H25.4 以降提供予定）

利用イメージ


データ・ウェアハウス

/データ・マート、業務データ

データ連携ミドルウェア（ETL/ELT）

抽出(E)・変換(T)・ロード(L)定義

オンラインバッチ起動監視・運用管理基盤

Job Controller

Job定義定時バッチ起動

ロード


バッチ・ジョブ

ジョブ起動画面

オンライン

バッチ起動SOA基盤

ESB

仲介定義

バッチ起動

データ連携バッチ起動

（定時/オンライン）

業務データ

差分同期定義

ロード業務データ

変化点検知・抽出

共通マスタデータ連携基盤

データ・ウェアハウス

/データ・マート、業務データ

データ連携ミドルウェア（ETL/ELT）

抽出(E)・変換(T)・ロード(L)定義

オンラインバッチ起動監視・運用管理基盤

Job Controller

Job定義定時バッチ起動

ロード


バッチ・ジョブ

ジョブ起動画面

オンライン

バッチ起動SOA基盤

ESB

仲介定義

バッチ起動

データ連携バッチ起動

（定時/オンライン）

業務データ

差分同期定義

ロード業務データ

変化点検知・抽出

共通マスタ



【凡例】



【凡例】

H25.4以降提供予定




要件の提示について共通基盤担当に要相談するこ

と。（例：連携対象サーバ/DBの情報など）

・データ連携基盤の利用要否について連絡する。





（例：処理対象データ量、実行頻度、処理負荷想定な

ど）




談する。





行う。



・他システム間及び自システムにおけるデータ処理変

換が必要な場合は共通基盤で選定したミドルウェア

製品の利用可否を検討・相談する。

・データ連携基盤は大量データのバッチ連携を実現し、

開発・運用を容易にするために必要なミドルウェア・ガ

イドラインを提供する。

・各個別業務においてマスタデータの配信が必要な場

合は選定ミドルウェアの利用検討・連絡・相談する。

・マスタ配信用途でもデータ連携基盤の利用を可とす

る。ただし、連携の煩雑化、データの散在、不一致と

派生データの増加を防ぐため、マスタを一元管理する

目的で、配信要件内容を確認する。

・各システム間でデータの伝播・同期が必要な場合は

選定ミドルウェアの利用検討・連絡・相談する。

・データ連携基盤はデータ変更を感知し変更を伝播・反

映可能な機能を提供する。


6.4.3. SOA 基盤

以下に共通基盤の提供するミドルウェアのうち「SOA 基盤」について、目的と役割、利用イメージ及び共通


目的と役割

【目的】

サービスの実装・実行・管理に必要なミドルウェアを提供

【役割】

・メッセージの変換・転送、サービスの統合などの機能の提供

・各種アダプタなどの提供による多様な技術・業務アプリケーションに対するサービス化支援機能の提供

・サービスのレジストリやセキュリティ制御などのサービス管理に関する機能の提供

・ビジネスプロセスの実装・動作・可視化環境の提供

・ビジネスプロセスの実行状況監視を実現するための機能の実装・動作環境の提供


ESB、BPEL、Service Registry（提供時期未定）、Service Security、Rule Engine ミドルウェア、BAM ミドルウェア

利用イメージ

アプリ実行基盤（アプリ B ）WebService

アプリ実行基盤（アプリA）

WebService

BPEL

ESB ServiceSecurity

ServiceRegistry

RuleEngine ビジネスルール

セキュリティ設定

フロー定義

変換・転送設定

ルール呼出

サービス/プロセス呼出

サービス呼出

プロセス定義・実行

サービス管理

サービス仲介

サービス呼出サービス呼出

サービス登録・検索

サービス検索

ルール定義・変更

Client

アプリ構築担当

ミドルウェア ※ 点線：利用任意（完全共通基盤化時）… 開発者開発 / 定義部分 …

【凡例】【】提供時期未定

チャート画面定義

BAM

ビジネスイベント情報




要件の提示を行う。（例：各種タイムアウト値、DB コ

ネクション数など）









に、ほかの業務アプリケーションへの影響部分も含

めサイジングを行い、ライセンス必要数を提示する。

（例：利用サービス数、アクセス数（ピーク/平均）、

フロー数など）




談する。





行う。







・SOA 基盤は業務アプリケーションを SOA に親和性の

高い技法で構築する場合に、開発・運用を容易にする

ために必要なミドルウェア・ガイドラインを提供する。

・ほかの業務アプリケーションが所有するサービスを

利用または、自アプリケーションがサービスを公開す

る場合は、SOA 基盤を利用する。

・ESB によるメッセージの変換・転送や各種アダプタに

よるサービス化機能により、アプリケーション間連携の

容易性の向上とサービス化の容易性の向上を支援す

る。

・ビジネスプロセスフローを実装するには共通基盤で

選定したミドルウェア製品を利用してフロー実装を行

う。

・BPEL によるビジネスプロセスフローの定義・実行、サ

ービス統合機能、RuleEngine によるビジネスルールの

定義・実行・変更機能によりビジネスの変化に迅速に

対応し、業務プロセスの可視化を支援する。

・サービス管理作業に必要な仕様、バージョン、SLA

などのサービス定義情報を提示する。

・Service Registry によるサービス登録、検索などの一

元管理機能を提供しサービスの乱立・無秩序化を抑

止し、再利用促進を支援する。（提供時期未定）

・社外へのサービス提供や、エンドユーザへ直接サー

ビスを公開する場合など、不特定多数がアクセス可

能な状態下にサービスを配置する場合は、共通基盤

担当に相談すること。

・Service Security による暗号化/認証・認可などの機能

を提供し、サービスのセキュリティ向上を支援する。



・業務の実施状況や実績が、ビジネス上の目標（KPI

／KGI）を達成しているか否かを監視・計測するため

の機能要件がある場合は共通基盤で選定したミドル

ウェア製品を利用しての設計・実装を検討する。

・BAM ミドルウェアにより、ビジネスプロセスの実行状

況・イベントなどを受信しチャート化ログイン画面や、

複数の異なる提供元のコンテンツを複合させてポータ

ル画面などを開発するための支援機能を提供する。


6.5. 共用アプリケーション基盤

6.5.1. アプリケーション実行基盤

以下に共通基盤の提供するミドルウェアのうち「アプリケーション実行基盤」について、目的と役割、利用イ

メージ及び共通基盤で提供する内容と、業務アプリケーション担当対応事項について記載する。

目的と役割

【目的】

業務アプリケーションの最も基本的な機能を開発する際に必要なミドルウェアを提供

【役割】

・開発者が特定の言語で開発した MVC モデルの各要素に対応するプログラムの実装・動作環境の提供

・Web サービスの実装・動作環境の提供

・Java オブジェクトをメモリ上に保持することで、処理の高速化を図るための実装・動作環境の提供（提供時期

未定）


HTTP サーバ、アプリケーションサーバ（JavaEE コンテナ）

※WEBLogic 以外で JVMで実行するアプリケーション（オンライン、バッチ）を開発する場合は、業務アプリケー

ション担当にてOpen JVM を調達すること。また、その部分のサポートは共通基盤では実施しない。

利用イメージ

アプリ実行基盤（業務アプリA）

SOA基盤アプリ実行基盤（業務アプリB）

JavaEEコンテナ

HTTPサーバ MW

データアクセス/ビジネスロジック

ObjectCache

ユーザインターフェース（画面）

Webサービス（In/Out）

WebService



【凡例】

内容後述

アプリ実行基盤（業務アプリA）

SOA基盤アプリ実行基盤（業務アプリB）

JavaEEコンテナ

HTTPサーバ MW

データアクセス/ビジネスロジック

ObjectCache

ユーザインターフェース（画面）

Webサービス（In/Out）

WebService



【凡例】



【凡例】

内容後述




要件の提示を行う。（例：各種タイムアウト値、セッシ

ョン数、コネクション数）

・ミドルウェアのインストール及び設定変更を行う。








（例：アクセス数、処理負荷想定、DB トランザクション

頻度など）

・サイジングは 1 度ではなく、企画・実装・テスト段階な



談する。

・サイジングに当たっての基礎値や参考値を提供し、検

討を支援する。

・想定外のサイジング結果連絡を受けた場合、共通基

盤の増強などを検討する。

・性能要件が満たせない場合など、ミドルウェアの設

定変更やチューニングを共通基盤担当者に相談す

る。







・アプリ実行基盤は業務アプリケーションの実装の方

針・方法・制約を記述したガイドライン（実装編）を提供

する。

・アプリケーション開発フレームワークの利用を検討

し、業務アプリケーション構築を行う。

・共通基盤では、アプリケーション開発フレームワーク

（Strutsや Spring などをベースとし拡張を行ったフレー

ムワークを想定）は提供しない。

・Java 言語によるプログラム実装及びWeb アプリケー

ションを前提に業務アプリケーション構築の企画・設

計・実装を実施する。

・Java 言語ベースのアプリケーションサーバミドルウェ

アを提供する。

・高度な性能要件がある場合には、共通基盤担当に

相談する。

・Java オブジェクトをメモリ上に保持し、高速化を図るた

めのミドルウェアの提供を検討する。（提供時期未定）

・SOA に基づいてサービスを実装する場合は、アプリ

実行基盤に加え、後述の SOA 基盤を利用して業務

アプリケーション実装を行う。

・JavaEE 仕様に基づくサービス実装（Web サービスな

ど）・実行環境を提供する。


6.5.2. 統合データベース基盤

以下に共通基盤の提供するミドルウェアのうち「統合データベース基盤」について、目的と役割、利用イメ

ージ及び共通基盤で提供する内容と、業務アプリケーション担当対応事項について記載する。

目的と役割

【目的】

可用性・拡張性・運用容易性を確保し、多用途のデータ保持要件に対応可能なミドルウェアを提供

【役割】

・各種業務トランザクション/マスタデータ、データウェアハウス、データマート、ID 管理及びMW用など、多用途

のデータベース機能の提供

・大量データの保持と情報ライフサイクルマネジメントの実現、高可用性を担保するための機能の提供

・高いデータアクセスに耐えうるための高速化機能の提供


RDBMS

利用イメージ

統合データベース基盤

データ・ウェアハウス/データ・マート個別業務データ共通マスタデータMW用データ

リレーショナルデータベース、多次元データベース、インメモリデータベースミドルウェア

共通基盤の

各ミドルウェア可視化基盤アプリ実行基盤アプリ実行基盤

共通マスタサービス個別アプリ

データ操作データ操作データ操作データ操作

BIM/W



【凡例】

個別アプリ個別アプリM/W

MW

統合データベース基盤

データ・ウェアハウス/データ・マート個別業務データ共通マスタデータMW用データ

リレーショナルデータベース、多次元データベース、インメモリデータベースミドルウェア

共通基盤の

各ミドルウェア可視化基盤アプリ実行基盤アプリ実行基盤

共通マスタサービス個別アプリ

データ操作データ操作データ操作データ操作

BIM/W



【凡例】



【凡例】

個別アプリ個別アプリM/W

MW




要件の提示を行う。（例：インスタンス構成、パラメ

ータなど）










（例：アクセス数（ピーク/平均）、保持データ量など）




談する。





行う。







・統合データベース基盤は、業務トランザクション/マス

タデータ、及びデータウェアハウス、データマート、ID

管理、MW用など、多用途のデータベース機能と可用

性・拡張性・運用容易性を実現するために必要なミド

ルウェアを提供する。

・トランザクションデータ/マスタデータを保持する業務

要件がある場合は、共通基盤で選定したミドルウェ

ア製品を利用する。

・リレーショナルデータベース（RDBMS）ミドルウェアによ

り、データ登録・更新・削除・検索の機能や高可用性を

提供し、業務アプリケーションを開発するための支援

機能を提供する。

・データベースを多次元的に解析する要件がある場合

は共通基盤担当に相談する。

・多次元データベース（MDDBMS）ミドルウェアにより、

多次元分析やマイニングを可能とするデータ蓄積機能

の提供及び BI 機能を開発するための支援機能の提

供を検討する。（提供時期未定）

・高度な性能要件がある場合には、共通基盤担当に

相談する。

・データベースのデータをメモリ上に保持し、高速化を

図るための In-Memory DB ミドルウェアの提供を検討

する。（提供時期未定）


6.6. その他

6.6.1. 業務アプリケーション開発支援

以下に共通基盤の提供する「業務アプリケーション開発支援」について、目的と役割、利用イメージ及び共

通基盤で提供する内容と、業務アプリケーション担当対応事項について記載する。

目的と役割

【目的】

システムのテストにおける効率向上のために必要なツールを提供

【役割】

・ユニットテスト・回帰テスト・負荷テストなどを支援するツールの提供（製品サポート終息に伴いサポート不可）

【提供予定ツール】

TestTools

利用イメージ


・システム開発支援基盤の有償ソフトを各プロジェクト

で利用する場合は、プロジェクト毎に利用時期、期

間、ライセンス必要数を提示する。（例：設計・開発者

利用人数、負荷テスト最大リクエスト数など）

・無償のツールに関しては、ライセンス数検討を不要

とする。

・ライセンス数検討に当たっての基礎値や参考値の提

供及び検討支援を共通基盤担当から提供する。

・システム開発支援基盤で提供する有償ソフトは原則と

して貸出とする。

・回帰テスト、機能テスト、負荷テストを行う場合は、共

通基盤で選定した製品を使用し結果をレポートす

る。

・本テスト結果は共通基盤担当者に提出し本番環境

移行許可を得ること。

・回帰テスト、機能テスト、負荷テストなどを支援するツ

ールを提供する。（製品サポート終息に伴いサポート

不可）

TestTool テスト定義機能・回帰テスト支援機能負荷テスト支援機能

テスト担当者


…ミドルウェア ※

【凡例】

…開発者開発/定義部分…ミドルウェア

【凡例】


6.6.2. オペレーティングシステム（OS）

以下にオペレーティングシステム（OS）について共通基盤で提供する内容と、業務アプリケーション担当対

応事項について記載する。


・共通基盤で選定したオペレーティングシステムを利

用する。

・アプリケーション実行環境（Web/AP サーバ）のための

オペレーティングシステムは Linux を提供予定。

・アプリケーション実行環境（バッチサーバ）のためのオ

ペレーティングシステムは商用UNIX を提供予定。

・ SOA実行環境（SOA サーバ）のためのオペレーティン

グシステムは商用UNIX を提供予定。

・ BI 実行環境（BI サーバ）のためのオペレーティングシ

ステムは商用 UNIX を提供予定。

・データベース環境（DBサーバ）のためのオペレーティ

ングシステムは商用UNIX を提供予定。

・監視・運用管理用途にはWindows、Linux、商用 UNIX

を提供予定。

・オペレーティングシステムのインストール及び設定に

必要な情報・要件の提示を行う。

・カーネルの設定や追加パッケージ・パッチ導入、バー

ジョンアップ、追加ユーザ設定などが必要な場合に

は、その内容と理由を提示する。

（例：最大ファイルオープン数、TCPKeepAlive 値な

ど）

・共通基盤で選定したオペレーティングシステムのイン

ストール及び設定変更を実施する。


・オペレーティングシステムの設定変更やチューニン

グの依頼は業務アプリケーション担当から情報の提

示及び指示を行う。

・他システムへの影響を調査し、問題がなければオペ

レーティングシステムの設定変更やチューニングを行

う。


6.6.3. ハードウェア（HW）

以下にハードウェア（HW）について、共通基盤で提供する内容と、業務アプリケーション担当対応事項につ

いて記載する。


・共通基盤で選定した HW メーカの機種を利用する。・サーバは、ハイエンドサーバとブレードサーバを提供

予定。（DB 系用途にハイエンドサーバ、AP系用途に

ブレードサーバ想定）

・ストレージとして SAN と NAS を提供予定。

（原則として NAS を想定しているが、パフォーマンスな

どが不足した場合など、必要に応じて SAN を使用す

る。）






・HW の構成に必要な情報・要件の提示を行う。

・特殊な HWの利用や拡張ボードの追加、機器の接続

などが必要な場合には、その内容と理由を提示す

る。

（例：特殊デバイス制御用ボード、SCSI/USB 機器な

ど）

・共通基盤で選定した HWの構成は共通基盤担当で実

施する。

・現状の構成情報は共通基盤担当から提供する。

・HWの調達に関しては、プロジェクト毎にサイジングを

行い、必要スペックを提示する。

（例：メモリ・ディスク容量、CPU数、台数など）




談する。

・共通サービスなど、自アプリケーション以外の機能利

用によってほかの業務アプリケーションに影響を与え

る場合は、影響先のアプリケーション担当と協力し、

影響先のアプリケーションのサイジングを行う。



・メモリ・CPUやDISK などのHW資源の増強依頼を行

う際は、その内容と理由、変更情報の提示及び指示

を行う。

・他システムへの影響を調査し、問題がなければHW資

源を増強する。

・テスト環境の一時的に利用するサーバについては、

利用時期、期間を提示する。

・利用が完了した際に返却する。

・テスト環境の一時的な利用用途のサーバを貸与す

る。


6.6.4. ファシリティ

以下にファシリティ（データセンタ）について、共通基盤で提供する内容と、業務アプリケーション担当対応

事項について記載する。メインデータセンタ利用上の注意事項については、「別添 2_メインデータセンタ利用

上の注意」を参照のこと。バックアップセンタ利用上の注意事項については、「別添 3_バックアップセンタ利用

上の注意」を参照のこと。


・次世代郵便情報システムの各システムは原則、共通

基盤の提供するメインデータセンタに設置する。

・次世代郵便情報システムのテスト環境（検証環境）

及び研修環境は原則、共通基盤の提供するバックア

ップセンタに設置する。

・メインデータセンタを提供する。

・バックアップセンタを提供する。

・特殊なファシリティ構成が必要な場合には、要望内

容と理由を提示し協議を行う。

（例：大型プリンタ、区分機など特殊な機器設置など）

・増床が必要な場合はあらかじめ共通基盤担当に相

談する。


・データセンタへの機器の搬入、設置作業などについて

指示する。


7. 共通基盤利用時の役割分担

共通基盤利用時の共通基盤担当と業務アプリケーション担当、及び業務アプリケーション構築受託ベンダ

の構築時の作業範囲及び作業分担については、「別添 1_共通基盤利用時の役割分担」を参照のこと。

なお、基盤に搭載されるアプリケーションの形態によっては内容が異なるため、役割分担については例と

なる。

8. 業務アプリケーション開発支援

8.1. 業務アプリケーションの実装方法・制限

共通基盤の提供する各機能を利用して業務アプリケーションを実装する際に注意すべき事項、制限事項

などについては、共通基盤ガイドライン（実装編）に記載しており、業務アプリケーション構築受託後に提示す

る。

8.2. 業務アプリケーションの構成管理方針

以下に業務アプリケーションの構成管理について、共通基盤で提供する内容と業務アプリケーション担当

対応事項について記載する。


・業務アプリケーションのソースコードや設計成果物

の管理は、AP保守環境にSubversionなどを構築し、

業務アプリケーション側で管理する。

・業務アプリケーションのソースコードと設計ドキュメン

トのバージョンを一致させるため、チェックアウト/チェ

ックインは、セットで実施する必要がある。そのセット

については、業務アプリケーション担当の責任で実

施する。

・開発・テスト・研修・本番環境へリリースする業務アプ

リケーションのソースコードと設計ドキュメントについ

ては、バージョンを合わせることを目的として、その

両方を業務アプリケーション側で管理する。

・業務アプリケーションのソースコードや設計成果物の

管理は、業務アプリケーション側で実施するため、共

通基盤担当は関与しない。


8.3. 業務アプリケーションのリリース方針

以下に業務アプリケーションのリリースについて、共通基盤で提供する内容と業務アプリケーション担当対

応事項について記載する。


【設計･開発】

・ベンダ開発環境は、業務アプリケーション構築ベンダ

の構成管理下にあるため、ベンダ開発環境へのリリ

ースを行う際は業務アプリケーション構築ベンダでリ

リース作業を実施する。

・リリース結果の確認は業務アプリケーション構築ベン

ダで実施する。

・ベンダ開発環境は、業務アプリケーション構築ベンダ

の構成管理下にあるため、ベンダ開発環境へのリリー

スを行う場合、共通基盤担当は関与しない。

【テスト】

・テスト環境へのリリース方法について理解する。

・テスト環境は、共通基盤（運用）担当の構成管理下

にあるため、テスト環境へのリリースを行う際は共通

基盤担当への立会いを依頼し、共通基盤担当立会

いのもと業務アプリケーション担当でリリース作業を

実施する。

・リリース結果の確認は業務アプリケーション担当で

実施する。

・テスト環境へのリリース方法について、業務アプリケー

ション担当への情報共有を実施するとともに、その手

続きについても情報共有する。

・業務アプリケーション担当より、テスト環境へのリリー

ス立会い依頼を受け、共通基盤（運用）担当にて立会

いを実施する。

【本番・研修】

・本番・研修環境へのリリース方法について理解す

る。

・本番・研修環境へのリリースは、ほかの業務アプリ

ケーションとの調整が必要となるため、事前にリリー

ス計画を共通基盤（運用）担当に提示する。

・本番・研修環境は、共通基盤（運用）担当の構成管

理下にあるため、本番・研修環境へのリリースを行う

際は共通基盤担当への立会いを依頼し、共通基盤

担当立会いのもと業務アプリケーション担当でリリー

ス作業を実施する。


実施する。

・本番・研修環境へのリリース方法について、業務アプ

リケーション担当への情報共有を実施するとともに、そ

の手続きについても情報共有する。

・本番・研修環境へのリリースについては、ほかの業務

アプリケーションへの影響も考えられるため、影響が

ある業務アプリケーション担当と調整の上、リリースを

実施する。そのため、必要に応じてリリースの調整を

する。

・業務アプリケーション担当より、本番・研修環境へのリ

リース立会い依頼を受け、共通基盤（運用）担当にて

立会いを実施する。



【保守】

・AP保守環境は、業務アプリケーション担当の構成管

理下にあるため、AP 保守環境へのリリースを行う際

は業務アプリケーション担当でリリース作業を実施す

る。


実施する。

・AP保守環境は、業務アプリケーション担当の構成管

理下にあるため、AP 保守環境へのリリースを行う場

合、共通基盤担当は関与しない。

8.4. 業務アプリケーションのセキュリティ診断

共通基盤のミドルウェア以下のレイヤについては共通基盤担当でのセキュリティ診断を実施するが、業務

アプリケーションのセキュリティ診断については、業務アプリケーション担当で実施すること。


9. 運用

9.1. 共通基盤の運用管理

（1）定常運用

以下に共通基盤の提供する運用管理のうち定常運用について、共通基盤で提供する内容と業務アプリケ

ーション担当の考慮事項について記載する。

共通基盤担当提供事項

・共通基盤のシステム監視項目については、以下の項目について実施する。

-システム監視/リモート監視

共通基盤を構成するネットワーク、ハードウェア、オペレーティングシステム、ミドルウェアについての死

活監視、又はCPU使用率やディスク使用率などのパフォーマンス監視を実施する。

-ジョブ運行監視

共通基盤で用意されるジョブスケジューリングツールにより、バッチジョブのスケジューリングとジョブの

運行監視を実施する。

-ログトレース監視

共通基盤を構成するネットワーク、ハードウェア、オペレーティングシステム、ミドルウェアから出力され

るシステムログ、監査ログを蓄積保管すると共に、リアルタイムエラー監視（キーワードによる）を実施

する。（例：Critical、Major、Warning、Normal など）

ただし、業務アプリケーション側で、監査を考慮したログ出力の設計を十分に行い、収集・保管が必要

なログがある場合は申請を行う。申請が行われたログの収集・保管は共通基盤側で実施する。

・共通基盤では以下の項目についてシステム分析評価を実施する。

-ネットワークのトラフィック

（例：通信パケット量、エラーパケット量）

-サーバリソースの使用率（CPU、メモリ、I/O）

（例：CPU使用率、メモリ使用率）

-ストレージの使用量

（例：ディスク使用量、キャッシュヒット率）

・共通基盤で実施するバックアップは以下のとおりである。

共通基盤で実施するバックアップは、基本的には共通基盤の可用性、信頼性を担保する目的で実施する。

バックアップは遠隔地へのDISK to DISK ミラーリング方式で実施する。


（2）システム監視

以下に共通基盤の提供する運用管理のうちシステム監視について、共通基盤で提供する内容と業務アプ

リケーション担当対応事項について記載する。



・共通基盤のシステム監視/リモート監視、ジョブ運行

監視、及びログトレース監視についてその監視項目

について確認する。

・システム監視/リモート監視

新規にプロセス、サービスを立ち上げる場合、共通

基盤で監視するために、プロセス名、サービス名を

共通基盤（運用）担当へ連絡する。

また、監視項目に閾値がある場合については、その

閾値を決定し、共通基盤（運用）担当へ連絡する。

-プロセス名、サービス名

-閾値

・ジョブ運行監視

バッチジョブのジョブフローを設計し、ジョブスケジュ

ーリングツールへの登録を共通基盤（運用）担当へ

依頼する。

-ジョブフロー設計

・ログトレース監視

新規にシステムログの監視が必要となる場合、その

ログについて共通基盤（運用）担当へ連絡する。

-ログ出力ディレクトリ

-ログ出力フォーマット

-ログ出力量（サイズ）、保存期限

-キーワード（リアルタイム監視）

・共通基盤のシステム監視項目については、以下の項

目について実施する。

-システム監視/リモート監視

共通基盤を構成するネットワーク、ハードウェア、

オペレーティングシステム、ミドルウェアについて

の死活監視、または CPU 使用率やディスク使用

率などのパフォーマンス監視を実施する。

-ジョブ運行監視

共通基盤で用意されるジョブスケジューリングツ

ールにより、バッチジョブのスケジューリングとジョ

ブの運行監視を実施する。

-ログトレース監視

共通基盤を構成するネットワーク、ハードウェア、

オペレーティングシステム、ミドルウェアから出力

されるシステムログ、監査ログを蓄積保管すると

共に、リアルタイムエラー監視（キーワードによる）

を実施する（例：Critical、Major、Warning、Normal

など）。

・業務アプリケーション担当より、共通基盤での監視対

象として依頼された項目について、その妥当性を検証

する。

・業務アプリケーションで新規に追加された監視項目に

ついて、共通基盤に登録する。

【テスト】

・新規の監視項目について、その閾値の見直しを実施

する。

・本番環境のサイジングに合わせて、本番環境での閾

値を見積り、共通基盤（運用）担当へ連絡する。

・テスト環境における監視項目、閾値の妥当性検証を

実施すると共に、ほかの業務アプリケーションへの影

響について検証する。

・業務アプリケーション担当から受領した、本番環境で

の監視項目、閾値見積りについて検証する。



【本番、研修】

・共通基盤（運用）担当より、業務アプリケーションに

起因する障害について連絡を受けた場合は、業務ア

プリケーション担当（原課）にて、障害復旧対応を実

施する。

・障害の一時対応のための本番・研修環境への作業

手続きについては、共通基盤（運用）担当に確認の

上実施する。

・業務アプリケーション担当で追加した監視項目につ

いて、その閾値（しきいち）の見直しを実施する。

・共通基盤（運用）担当は、共通基盤のシステムによる

障害の検知と、一次切り分けまでを実施する。

・共通基盤に関わる障害の場合は、共通基盤（運用）担

当にて対応する。

・障害の一時対応のための本番・研修環境への作業手

続きについては、共通基盤（運用）担当が主導で実施

する。

・業務アプリケーション担当固有の監視項目について、

その閾値の見直しのための情報提供を実施する。

・業務アプリケーション担当固有の監視項目について、

業務アプリケーション担当からの変更依頼を受領して

実施する。

（3）システム分析評価

以下に共通基盤の提供する運用管理のうちシステム分析評価について、共通基盤で提供する内容と業務

アプリケーション担当対応事項について記載する。



・共通基盤のシステム分析評価についてその項目を

確認する。

・業務アプリケーションのトランザクション量、固有の

要件によりリソースの評価分析が必要な場合は、そ

の項目を検討し、共通基盤（運用）担当にシステム分

析評価項目として依頼する。

・共通基盤では以下の項目についてシステム分析評価

を実施する。

-ネットワークのトラフィック

（例：通信パケット量、エラーパケット量）

-サーバリソースの使用率（CPU、メモリ、I/O）

（例：CPU使用率、メモリ使用率）

-ストレージの使用量

（例：ディスク使用量、キャッシュヒット率）

・業務アプリケーション担当より依頼された、個別のシス

テム分析評価項目の追加について検討し、必要に応

じて項目を追加する。



【テスト】

・新規のシステム分析評価項目について要否の見直

しを実施する。

・本番環境のサイジングに合わせて、本番環境での閾

値を見積り、共通基盤（運用）担当へ連絡する。

・テスト環境におけるシステム分析評価項目の妥当性

検証を実施する。

・業務アプリケーション担当から受領した、本番環境で

のシステム分析評価項目の準備を実施する。


・共通基盤（運用）担当から受領したシステム分析評

価項目より、リソースの拡張計画を検討する。

・リソースの拡張のための、本番・研修環境への作業

手続きについては、共通基盤（運用）担当に確認の

上実施する。

・業務アプリケーション担当の個別システム分析評価項

目について、業務アプリケーション担当に情報を提供

する。

・共通基盤に関わるシステム分析評価項目について

は、共通基盤（運用）担当にて項目を検討し、リソース

の拡張計画を検討する。

・リソース拡張のための本番・研修環境への作業手続

きについては、共通基盤（運用）担当が主導で実施す

る。

（4）バックアップ管理

以下に共通基盤の提供する運用管理のうちバックアップ管理について、共通基盤で提供する内容と業務

アプリケーション担当対応事項について記載する。



・共通基盤で実施するバックアップ要件について確認

する。

・業務要件から機能単位で業務アプリケーションの

SLA/BCP を策定し、共通基盤へ求める要件を連絡

する。

・業務アプリケーションとしてバックアップサイトに必要

なリソースのサイジングための非機能要件について

とりまとめ共通基盤担当に連絡する。

・業務要件によりデータアーカイブの目的でデータの

バックアップが必要な場合については、個別業務要

件として業務アプリケーション担当で検討する。

（例：会計帳簿の保存年数、法令順守によるデータ保

管など）

・共通基盤で実施するバックアップは以下のとおりであ

る。

共通基盤で実施するバックアップは、基本的には共通

基盤の可用性、信頼性を担保する目的で実施する。

・バックアップは遠隔地への DISK to DISK ミラーリング

方式で実施する。

・業務アプリケーション担当からの SLA/BCP要件によ

り、共通基盤のバックアップ要件を策定する

・業務アプリケーション担当よりバックアップサイトのリソ

ースサイジングのための非機能要件について内容を

検証する。

・バックアップサイトに追加で必要となるリソースについ

てサイジングを実施する。

・データアーカイブ目的のデータバックアップについて、

業務アプリケーション担当を支援する。



【テスト】

・業務アプリケーションのバックアップ/リカバリの検証

を共通基盤（運用）担当と共同で実施する。

・データアーカイブのバックアップについて検証する。

・バックアップサイト、データアーカイブのリソースサイ

ジングについて検証すると共に変更が必要な場合に

ついて、再度見積もりを提示、共通基盤（運用）担当

へ連絡する。

・業務アプリケーションのバックアップ/リカバリの検証を

業務アプリケーション担当と共同で実施する。

・リソースのサイジング見直しに伴う、バックアップサイ

ト、データアーカイブの変更を実施する。


・業務アプリケーションのバックアップ/リカバリの演習

を共通基盤（運用）担当と共同で実施する。

・業務要件の見直しや変更に伴いSLA/BCPの見直し

を実施する。それに伴いバックアップ要件が変更に

なった場合は、共通基盤へ求める要件の変更につい

て連絡する。

・業務アプリケーションのバックアップ/リカバリの演習を

業務アプリケーション担当と共同で実施する。

・業務アプリケーション担当からの SLA/BCP要件見直

し、変更により、共通基盤のバックアップ要件を変更す

る。

・SLA/BCPの要件に合わせてリストアを実施する。リス

トアについては、業務アプリケーション担当からの依

頼により実施する。


9.2. 共通基盤の構成管理

以下に共通基盤の提供する運用保守のうち構成管理について、共通基盤で提供する内容について記載

する。

共通基盤担当提供事項

・運用保守、構成管理では、以下の環境を提供予定である。

・テスト・研修・本番環境の構成管理は、共通基盤（運用）担当によって管理される。

-構成管理対象環境については、共通基盤（運用）担当により、全てのリソース（HW、OS、MW、パッチ含む）

の構成情報が管理される。

-構成管理対象環境については、変更前の環境情報や、障害発生時の環境の戻しについては、共通基盤

（運用）担当より提供される。

環境名 AP保守環境テスト環境研修環境本番環境

利用目的

業務アプリケーショ

ンを開発する環境。

基本的には構成管

理対象外の環境

で、アプリケーション

保守が行える必要

最小限の環境を提

供する。

本番環境リリース前

の最終的なアプリケ

ーションテスト、シス

テムテストを実施

し、本番環境へリリ

ースする最終的な

構成を確定させるた

めの環境。本番環

境の縮小モデルとし

て、適宜、本番環境

の構成より構築す

る。必要に応じて、

パフォーマンス・高

負荷（ストレス）テス

トを実施する。

次世代郵便情報シ

ステム共通基盤上

で動作するシステム

に対し、システム利

用者向けの業務研

修や訓練を行うた

めの環境。本番環

境の縮小モデルとし

て、適宜、本番環境

の構成より構築す

る。

次世代郵便情報シ

ステム共通基盤の

本番稼動環境。基

本的に業務サービ

ス提供時間にシス

テムの変更は行わ

れず（障害発生時

の緊急対応は例

外）、計画停止によ

って構成変更を実

施する。

利用フェーズ保守（設計開発）テスト･検収フェーズ業務研修・訓練本番稼動

構成管理対象外対象対象対象

管理者（AP） ○

管理者（基盤） ○ ○ ○


以下に共通基盤の提供する運用保守のうち構成管理について、共通基盤で提供する内容と業務アプリケ

ーション担当対応事項について記載する。


【設計、開発】

・共通基盤の構成管理について理解し、開発スケジュ

ールを検討する。

・業務アプリケーションの開発スケジュールを共通基

盤（運用）担当と共有すると共に、開発機のサイジン

グや調達時期について調整する。必要に応じて移行

用の開発機も調達する。

・業務アプリケーション担当は、構築する業務アプリケ

ーションの構成アイテムが、全て構成管理対象の構

成アイテムであることを確認する。

・構成管理対象外の構成アイテムについては、共通基

盤（運用）担当と事前調整を行い、構成管理対象の

構成アイテムとするか否か検討する。

・業務アプリケーションを本番に移行する場合のサイ

ジングと構成を検討する要件を共通基盤（運用）担当

に共有する。

・共通基盤の構成管理について、業務アプリケーション

担当に情報共有する。

・業務アプリケーション担当と業務アプリケーションの開

発スケジュールを共有し、開発機のサイジングと調達

スケジュールについて検討する。

・業務アプリケーションを本番機に移行する場合の 1次

サイジング結果を受領し、システム構成の検討、サイ

ジング見積りを実施する。

【テスト】

・テスト環境の構成管理方法について理解する。

・テスト環境は、共通基盤（運用）担当の構成管理下

にあるため、利用時には共通基盤（運用）担当に利

用申請を行う。

・テスト環境の構成管理方法について、業務アプリケー

ション担当への情報共有を実施するとともに、その手

続きについても情報共有する。

・業務アプリケーション担当からテスト環境の利用申請

を受けた場合は、そのための環境を調整し用意する

（事前に調整される）。


・本番・研修環境の構成管理方法について理解する。

・本番・研修環境は、共通基盤（運用）担当の構成管

理下にあるため、利用時には共通基盤（運用）担当

に利用申請を行う。

・本番稼動後は、テスト環境は共通基盤担当へ返却

する必要がある。2 次開発や障害対応などのために

継続して利用したい場合については、共通基盤担当

と調整する。

・本番・研修環境の構成管理方法について、業務アプリ

ケーション担当への情報共有を実施するとともに、そ

の手続きについても情報共有する。

・業務アプリケーション担当からのテスト環境の返却を

受け入れる。

・業務アプリケーション担当からテスト環境を継続して

利用する旨依頼を受けた場合は、そのための環境を

調整し用意する（事前に調整される）。


9.3. 共通基盤のメンテナンス/バージョンアップ

以下に共通基盤の提供する運用保守のうちシステムメンテナンス/バージョンアップについて、共通基盤で

提供する内容と業務アプリケーション担当対応事項について記載する。



・現行（または構築予定）の共通基盤のHW、OS、MW

について、そのバージョンを確認する。

・アプリケーションの開発に必要な機能要件が、現在

のバージョンで満たされているか、あるいは上位バー

ジョンによって機能要件を満たすことが可能である

か、共通基盤（運用）担当と確認する。

・既存の共通基盤をバージョンアップする場合は、共

通基盤（運用）担当と影響分析（内部・外部接続性、

連携など）を実施する。

・現行（または構築予定）の共通基盤のHW、OS、MW

の構成について、及びそのバージョンについて、業務

アプリケーション担当に情報共有する。

・業務アプリケーションの機能要件に対して、共通基盤

として用意する必要のあるバージョンについて業務ア

プリケーション担当と検討する。

・既存の共通基盤と比較して上位バージョンが必要と

判断した場合、既存の共通基盤をバージョンアップす

るか、新たなバージョンの共通基盤を策定するか検討

を行う。

-既存共通基盤のバージョンアップ

-新規の上位バージョンの共通基盤の策定

・既存の共通基盤をバージョンアップする場合は、関連

する業務アプリケーション担当と影響分析を実施す

る。

・パッチについては、テスト環境を利用して検証を行う。

【本番、研修、テスト】

・本番・研修・テスト環境は、共通基盤（運用）担当の

構成管理下にあるため、業務アプリケーション担当

は、システムのバージョンアップ、またはパッチの適

用について共通基盤（運用）担当へ依頼する。

・業務アプリケーション担当にて導入したMWのサポー

トを実施する。

(例：WEBLogic 以外で JVM で実行するアプリケーショ

ン（オンライン、バッチ）を開発する場合は、業務アプリ

ケーション担当にてOpen JVM の調達・導入を行う。こ

の場合、JVMのサポートは業務アプリケーション担当

にて実施する。)

・業務アプリケーション担当より、本番・研修・テスト環境

へのリリース依頼を受け、共通基盤（運用）担当にて

システムメンテナンス/バージョンアップ（構成管理）を

実施する。


9.4. 共通基盤の拡張方針

共通基盤のHW拡張方針については、以下のとおり。

①～③ 業務アプリケーションが単体で使用する、APサーバ／DBサーバ／ストレージの増設

④～⑥ 業務アプリケーションが共通機能を使用することで発生する共通機能用 AP サーバ／DB サーバ

／ストレージの増設

⑦ 業務アプリケーション搭載により、必要に応じて統合運用の追加

⑧ 業務アプリケーションがほかの業務アプリケーションの機能を使用することで発生する AP サーバの増

設

⑨ 業務アプリケーションがテスト時に使用するテスト環境の設置

データベースサーバアプリケーションサーバ

共通機能用DB共通機能

個別アプリ個別アプリ用DB

・・・

・・・

ストレージ

ユーザからのサイジング結果

ネットワーク

アプリはコストを抑えるために最

小構成とし、必要に応じてブレードを追加して増強する

DBは信頼性を重要視して大きなサーバを区分けして利用することとし、必要に応じてCPU、メモリを追加して増強する

流量計

追加ハード

統合運用

構築

他サービスからの利用増業務アプリからの共通

サービス利用増

取扱データ量、トランザクション量増

共通マスタ参照サービス利用増

個別DB、共通DBのデータ量増

業務アプリ開発増に伴う、環境構築

個別アプリ・個別DBアプリ新規構築に伴い、基本的に必ず増強を検討する。また、他アプリケーションからのサービス

利用量に対応して増強を行う。

共通アプリ／DB業務AP増加や業務トランザク

ション増加に伴い、増強を検討する

①

④ ⑤

③

⑥

⑦

②

⑧

⑨

ネットワーク初期設置時に想定される使

用容量を見越して設置。業務APL増設毎に伴う増設

は基本的にないものとする。


Appendix1. 技術略語・用語の説明

略語・用語フルスペル説明

BAM Business Activity Monitoring BPM を推進するうえで、業務の実施状況や実績（パフ

ォーマンス）を監視すること。

BCP Business Continuity Planning 事業継続計画。災害発生時に限られた資源の中で業

務を継続させるための事前に策定された計画。

BI Business Intelligence 業務システムなどから蓄積される企業内の膨大なデ

ータを、蓄積・分析・加工して、企業の意思決定に活用

しようとする手法。

BPEL Business Process Execution Language 実行可能なビジネスプロセスモデリング言語。

BPMN Business Process Modeling Notation ワークフローとしてビジネスプロセスを描画するグラフ

ィカルな標準記法である。

DAO Data Access Object データベースなどの永続性機構の抽象化されたインタ

フェースを提供するデザインパターン。

DR disaster recovery/ディザスタリカバリ自然災害などで被害を受けたシステムを復旧・修復す

ること。また、そのための備えとなる機器やシステム、

体制のこと。「システムを災害から守る」のみならず、

各種の障害は必ず起こりえるものと想定し、いかに効

率よく迅速に復旧するかという点から災害対策を捉え

る。システム停止による利益の損失を最小限に抑える

事を目的とする。

ELT Extract Load Transform ETL と同様であるが、従来の ETL ツールの問題点で

ある、データ変換を専用サーバで行うことによる集中

処理を改善するため、データを抽出（extract）し、デー

タベースに書き出した（load）後に加工（transform）する

方法・アーキテクチャ。

E-R （モデ

ル）

Entity Relation Model データモデリング手法の 1 つで、モデル化対象（実世

界）を“実体”とその“関連”からなるものとして定義、構

造化して、静的な概念データモデルを記述する。

ESB Enterprise Service Bus アプリケーション統合を、“バス”の概念でデザインす

るアーキテクチャパターン。あるいはそれを実現する

ための基盤となる製品。

ETL Extract Transform Load 企業の基幹系システムなどに蓄積されたデータを抽

出（extract）し、データウェアハウスなどで利用しやす

い形に加工（transform）し、対象となるデータベースに

書き出す（load）こと。また、これら一連の処理を支援

するソフトウェア。



IDE Integrated Development Environment 「統合開発環境」の略。エディタ、コンパイラ、デバッガ

など、プログラミングに必要なツールが一つのインタフ

ェースで統合して扱えるような環境のこと。

IdM Identity Management 情報システムにおける何らかの実体のデジタルアイデ

ンティティのライフサイクルにわたる管理を意味する。

ITIL IT Infrastructure Library 1989 年にイギリス政府の CCTA（Central Computer

and Telecommunications Agency）によって公表された

IT サービスマネジメントにおけるベストプラクティス（成

功事例）を収めた書籍群であり、ITサービスマネジメン

トにおける業界標準として認知されている。

Java Object

Cache

Java Object Cache 1 プロセス内、プロセス全体あるいはローカルディスク

上でも Java オブジェクトを管理できる Java のセット

JavaEE Java Enterprise Edition 企業の業務システムで使われるサーバに必要な機能

をまとめた Java 仕様群。

JAX-RPC/

WS

Java API for XML - Remote Procedure

Call / Web Service

Java による Web サービス実装を実現するための仕

様。JavaEE の一部。

JSF JavaServer Faces Java ベースの Web アプリケーション UI 開発を簡単

にする JavaEE 標準の開発フレームワーク。

JSP JavaServer Pages 動的に Web ページを生成してクライアントに返す技

術。JSF でも利用される。

JVM Heap Java Virtual Machine Heap Java 仮想マシンが使用するメモリ領域。

KeepAlive Keep Alive 通信が正常にできるかどうかを判断するために、一定

の時間間隔で送信する制御用のメッセージ。このメッ

セージ又はこのメッセージに対する応答メッセージを

一定時間受信しなかった場合、途中の通信経路に異

常が発生したか、又は相手装置が正常に動作してい

ないものと判断し、回線の切断（タイムアウト）やバック

アップ動作開始のきっかけとする。

KGI Key Goal Indicator 重要目標達成指標。企業目標やビジネス戦略を実現

するために設定した具体的な業務プロセスをモニタリ

ングする指標の 1 つで、何をもって成果とするかを定

量的に定めたもの。

KPI Key Performance Indicator 重要業績評価指標。企業目標やビジネス戦略を実現

するために設定した具体的な業務プロセスをモニタリ

ングするために設定される指標。



MDDBMS Multi Dimensional Data Base Management

System

複数の属性項目（次元）を次々に切り替えてデータを

検索・集計できるデータベース。

OLAP online analytical processing エンドユーザが直接データベースの検索・集計を行

い、その中から問題点や課題を発見する分析型アプリ

ケーションの概念、あるいはそのためのシステムもしく

はツールのこと。

POJO Plain Old Java Object ごく普通の Java オブジェクトであることを強調した名

称。

Portal Portal Site 業務アプリケーションの入り口となる Web サイト。掲示

板や業務アプリケーションのメニューなどが配置され

る。シングルサインオンでも利用される。語源は玄関、

入口。

RDBMS Relational Data Base Management

System

リレーショナルデータモデルの理論に従って実装され

たデータベースを管理するソフトウェア。

Service

Registry

Service Registry サービスのインタフェース定義を登録管理し実行時の

検索に利用する定義ストア。

Service

Repository

Service Repository サービスの設計を登録管理し、依存性分析や実行時

の検索に利用する。

SLA Service Level Agreement 提供するサービスについて合意、締結した契約であ

る。

SOA Service-Oriented Architecture システムを「サービス」の集まりとして構築する考え方・

設計手法・アーキテクチャ。

SSO Single Sign-On ユーザが一度認証を受けるだけで、許可されている全

ての機能を利用できるようになるシステム。

UML Unified Modeling Language オブジェクト指向のソフトウェア開発における、プログ

ラム設計図の統一表記法。

WAM Web Access Manager Web サイトのセキュリティを保護し、認証・認可を実現

するソフトウェア。

Web サービ

ス

Web Services HTTP などのインターネット関連技術を応用して、

SOAP と呼ばれる XML 形式のプロトコルを用いメッセ

ージの送受信を行う技術、又はそれを適用したサービ

ス。

WS-* WS-addressing/WS-Security/WS-Reliabl

eMessaging etc

OASIS など標準化団体で定義された Web サービス関

連仕様群。

データウェア

ハウス

Data Warehouse 企業内のさまざまなデータを一か所に集めたものであ

る。データを集めて管理するシステムや、集めたデー

タをもとにした意思決定支援システムを指すこともあ

る。



データマート Data Mart データマイニングとは、データベースに蓄積されている

大量のデータから、統計や決定木などを駆使して、マ

ーケティングに必要な傾向やパターンなどの隠された

規則性、関係性、仮説を導き出す手法のことである。

バックアップ

サイト

Back-up Site データセンタ（プライマリサイト）が自然災害などによっ

て IT サービスの提供が継続不可能となった場合に、

代わってITサービスを提供するための2次的なデータ

センタ（システムの環境）。

バックアップ

センタ

Backup Center 日本郵便株式会社指定場所として、西日本管内に設

置しているデータセンタ。

詳細な位置情報については、共通基盤ガイドライン

（実装編）に記載しており、業務アプリケーション構築

受託後に提示する。

メインデータ

センタ

Main Data Center 日本郵便株式会社指定場所として、東日本管内に設

置しているデータセンタ。

詳細な位置情報については、共通基盤ガイドライン

（実装編）に記載しており、業務アプリケーション構築

受託後に提示する。

開発フレー

ムワーク

Development Framework アプリケーションのプログラミングを容易に、かつ標準

的に実施するため、アプリケーションソフトを開発する

際に頻繁に必要とされる汎用的な機能をまとめて提

供し、アプリケーションの土台として機能するソフトウェ

ア（クラスやライブラリ）のこと。広義には規約なども含

む。

本書の記述においては、共通基盤で提供するミドルウ

ェア上に、JavaEE やオープンソースのフレームワーク

などを活用して、日本郵便特有の汎用的な機能（ロギ

ング、画面パーツなど）を実装したものを想定して記述

している。


Appendix2. 統合データベース補足説明

（1）（補足）統合データベース基盤とは

統合データベース基盤とは、可用性・拡張性・運用容易性を実現し、多用途のデータ保持要件に対応可能

な統合されたデータベース基盤である。オンライントランザクション処理（OLTP）及びオンライン分析処理

（OLAP）の双方に対応でき、大規模から小規模なデータベースの実現に対応できるデータベース基盤を提

供する。

また、可用性を維持するための冗長化を行うが、待機系用途の無駄な遊休リソースを削減するため

Active-Active 構成を可能とし、業務アプリケーション負荷に応じてリソース配分を柔軟に変更可能な基盤を

提供する。

Storage

DB Server


資源追加

資源追加

・・・DBファイル

・・・DISK資源・・・DBインスタンス

・・・DBサーバ資源

【凡例】Storage

DB Server


資源追加

資源追加


・・・DISK資源・・・DBインスタンス

・・・DBサーバ資源

【凡例】


（2）（補足）統合データベース基盤におけるデータ統合手法

※データ統合手法については、データベース・リンクとマテリアライズド・ビューの組み合わせによる実現方

法を検討しており、検討終了後に統合手法を記載する。

統合データベース基盤は、多数存在するデータ統合手法の中から、業務アプリケーションの要件や特性な

どに合わせて最適なデータ統合手法を選択可能な基盤を提供する。

共通基盤の想定する統合データベースは、全てのアプリケーションデータのデータモデルを統一すること、

又は、全てのデータを一つの物理的データベースへ格納することを強制することは想定していない。

データベース

アプリケーション

概要

バランス型

SOA基盤

完全統一型

共通マスタAP A B CA B C

特徴 ◎データ品質の向上。（統一データモデルと単一DB化により、データの重複・散在を排除）

△統一運用が可能（業務毎の運用が困難）×業務パッケージ導入が困難×データモデル設計が困難（ビッグバン型開発が必要）×変化対応力が低い（データモデルの変更時にアプリケーションに直接影響。吸収層がない）

すべてのアプリケーションのデータのデータモデルを統一設計し、データベースを1つに統合

重要な共通データ部分のみ共通化し、SOAやデータ連携基盤によって連携

○データ品質の向上。（重要データの統一管理により、データ不一致を排除）△業務毎の運用が可能○業務パッケージ導入にも対応可能○段階的データモデル設計が可能△連携の仕組み・機能の構築が必要○変化対応力が高い（変化に対応する連携層）

データ連携

・・・データベース・・・テーブル群

・・・アプリケーション

【凡例】

C

データベース

アプリケーション

概要

バランス型

SOA基盤

完全統一型

共通マスタAP A B CA B C

特徴 ◎データ品質の向上。（統一データモデルと単一DB化により、データの重複・散在を排除）

△統一運用が可能（業務毎の運用が困難）×業務パッケージ導入が困難×データモデル設計が困難（ビッグバン型開発が必要）×変化対応力が低い（データモデルの変更時にアプリケーションに直接影響。吸収層がない）

すべてのアプリケーションのデータのデータモデルを統一設計し、データベースを1つに統合

重要な共通データ部分のみ共通化し、SOAやデータ連携基盤によって連携

○データ品質の向上。（重要データの統一管理により、データ不一致を排除）△業務毎の運用が可能○業務パッケージ導入にも対応可能○段階的データモデル設計が可能△連携の仕組み・機能の構築が必要○変化対応力が高い（変化に対応する連携層）

データ連携



【凡例】

C



【凡例】

C


（3）（補足）データベース構成パターン

統合データベースは業務アプリケーションの SLA 要件に応じて、複数の構成が取れるものとする。以下に

構成例とその特徴を記載する。②を基本構成として業務アプリケーション要件を考慮して検討・決定する。


・・・DBスキーマ

？・・・DBインスタンス・・・アプリケーション

・・・DBサーバ資源・・・仮想DB構成単位

【凡例】

Storage

DB Server

AP Server

想定用途

アプリA アプリD アプリE アプリF

①サーバ資源占有 ②サーバ資源共有 ③インスタンス共有 ④スキーマ共有

アプリG アプリH

⑤単独

可用性

性能影響

運用影響

○あり ○あり ○あり ○あり ×なし

○他APの影響を受けない

○独立して起動/停止可

資源効率

×他APの影響を受ける ×同左 ×同左 -

○独立して起動/停止可 ×独立運用不可 ×独立運用不可

×余剰資源配分不可 ○負荷に応じた配分可能 ○空きリソースを利用可能

アプリB アプリC

×不可

-

×不可

資源活用効率よりも独立性を高めたいクリティカルなアプリで検討する構成

資源活用効率・柔軟性向上と運用の独立性を両立可能なため、基本検討構成とする。

軽量アプリ用途限定

資源の共用活用が可能なため、基本検討構成とする

同左

A A AB

C

BDE DE FG FG H

CC

B

推奨 △採用可 ○推奨 ○推奨 ×非推奨 △採用可


・・・DBスキーマ

？・・・DBインスタンス・・・アプリケーション

・・・DBサーバ資源・・・仮想DB構成単位

【凡例】

Storage

DB Server

AP Server

想定用途




⑤単独

可用性

性能影響

運用影響




資源効率





×不可

-

×不可





同左

A A AB

C

BDE DE FG FG H

CC

B


Storage

DB Server

AP Server

想定用途




⑤単独

可用性

性能影響

運用影響




資源効率





×不可

-

×不可





同左

A A AB

C

BDE DE FG FG H

CC

B


想定用途




⑤単独

可用性

性能影響

運用影響




資源効率





×不可

-

×不可





同左

A A AB

C

BDE DE FG FG H

CC

B



共通基盤利用時の役割分担について ○ 主担当△ レビュー、確認

作成日2009.9.10

項番作業項目業務アプリケーション担当

共通基盤担当

業務アプリケーション受託業者

業務アプリケーション担当作業の内容

共通基盤担当作業の内容業務アプリケーション構築受託ベンダ作業の内容

備考

1 ハードウェア・OS設計、構築【本番環境・テスト環境】

2 アプリケーション稼働スペックの提示 △ ○ △- アプリケーションが稼動す

るH/W、M/Wのスペックを提示する。

-

3 ハードウェアの調達、保守の提供 △ ○ △- 共通基盤担当にて調達・

保守の提供を行う。-

4 OS設定値の提示（アプリ稼働に必須部分） △ △ ○

- 共通基盤としてデフォルトで設定する項目を提示する。それ以外の設定値について業務アプリケーション側で必要なものがあれば申請書ベースで受付を行う。

共通基盤から提示される設定項目に対し、アプリケーション稼働に必要なOS設定値を提示する。

5 OS設定値の提示（その他） △ △ ○

- - 共通基盤から提示される設定項目に対し、アプリケーション稼働に必要なOS設定値を提示する。

6 ハードウェア、OSの設計（その他） △ ○ △ - 上記に基づき実施する。 -

7 ハードウエア、ネットワーク導入作業 △ ○ △- 上記に基づき実施する。 - ネットワークの追加機器の導入作業があれば

ネットワーク機器の導入を実施。8 OS設定作業 △ ○ △ - 上記に基づき実施する。 -9 ネットワーク設計、構築【本番環境・テスト環境】

10 クライアント－共通基盤間ネットワークの要件提示 △ △ ○

PNETや社内LANの担当部署に対し、要件伝達や調整を行う。

申請書をベースに受付を行う。特別な申請がない場合はPNETからのWEBアクセスのみの接続とする。

アプリケーションの稼働に必要な、クライアントからの接続におけるネットワーク要件（利用プロトコル等）を提示する。

11 クライアント－共通基盤間ネットワークの設計 △ ○ △- 上記に基づき実施する。 -

12 クライアント－共通基盤間ネットワークの設定変更 △ ○ △ - 上記に基づき実施する。 -

13 共通基盤内ネットワークの要件提示 △ △ ○

- 申請書をベースに要件の確認を行う。申請書がなければPNETからのWEBの接続のみとする。

アプリケーションの稼働に必要な共通基盤のネットワーク要件（負荷分散条件、利用プロトコル等）を提示する

14 共通基盤内ネットワークの設計 △ ○ △ - 上記に基づき実施する。 -15 共通基盤内ネットワークの構築 △ ○ △ - 上記に基づき実施する。 -16 共用帯域制御設計 △ ○ △ - 上記に基づき実施する。 -17 共用帯域制御設定作業 △ ○ △ - 上記に基づき実施する。 -18 共用IDS/IDP設計 △ ○ △ - 上記に基づき実施する。 -19 共用IDS/IDP設定作業 △ ○ △ - 上記に基づき実施する。 -20 共用ファイアウォール設計 △ ○ △ - 上記に基づき実施する。 -21 共用ファイアウォール設定作業 △ ○ △ - 上記に基づき実施する。 -22 共用ロードバランス設計 △ ○ △ - 上記に基づき実施する。 -23 共用ロードバランス設定作業 △ ○ △ - 上記に基づき実施する。 -24 ミドルウェア設計、構築（Oracle RDBMS）【本番環境・テスト環境】

25 アプリケーション要件によるバージョン、エディションの指定 △ ○ △- 共通基盤担当で用意す

る、バージョン、エディションを提示する。

-

26 ミドルウェアの調達、インストールメディア用意、保守の提供 △ ○ △- 共通基盤担当にてミドル

ウェアの調達・保守の提供を行う。

-

27 アプリケーション要件によるインストール条件の提示 △ △ ○

- 申請書ベースで業務アプリケーションの要件を受け付ける。申請書がなければ共通基盤担当にて用意する設定とする。

共通基盤より提供されるデータベースソフトウェアのインストール条件を確認し、業務アプリケーションとして追加の条件があれば申請する。

28アプリケーション要件による設定条件（メモリ設定、Diskサイズ要件等）の提示

△ △ ○

- 申請書ベースで業務アプリケーションの要件を受け付ける。申請書がなければデフォルトで用意するサイズで設定とする。(別途提示)

共通基盤から提示される設定項目に対し、設定値を提示する。

29 物理設計 △ ○ △- 上記条件に基づき実施す

る。- 設計を行ううえで必要なヒアリング項目を共通基

盤推進から提示の上、設計・設定を共通基盤が行う。

30 インストール作業 △ ○ △- 上記条件に基づき実施す

る。-

31 インスタンス作成作業 △ ○ △- 上記条件に基づき実施す



32 アプリケーション要件によるスキーマ、表領域設計（論理設計） △ △ ○

- - 共通基盤が作成したデータベースサービス上に、アプリケーション稼働に必要なスキーマや表の設計を

33 アプリケーション稼働の為の設定(スキーマ作成) △ ○ △

- スキーマ作成、権限設定までは共通基盤担当にて実施する。

-

34 アプリケーション稼働の為の設定 △ △ ○- - アプリケーション稼働に必

要な表の作成や索引の設定を行う。

35 ミドルウェア設計、構築（WebLogic）【本番環境・テスト環境】

36 アプリケーション要件によるバージョン、エディションの指定 △ ○ △- 共通基盤で用意する、

バージョンエディションを提示する。

-

37 ミドルウェアの調達、インストールメディア用意、保守の提供 △ ○ △- 共通基盤にてミドルウェア

の調達・保守の提供を行う。

-

38 アプリケーション要件によるインストール条件の提示 △ △ ○

- 設定項目を提示する。また、業務アプリから個別に提示された条件の確認を行う。

共通基盤から提示される設定項目に対し、アプリケーションサーバのインストール条件を提示する。

39アプリケーション要件によるインスタンス設定条件（メモリ設定、Diskサイズ等）の提示

△ △ ○

- デフォルトとして設定する項目を提示する。また、業務アプリから提示された条件の確認を行う。

共通基盤から提示される設定項目に対し、アプリケーションサーバの設定条件を提示する。

40 物理設計 △ ○ △- 上記条件に基づき実施す



41 インストール作業 △ ○ △- 上記条件に基づき実施す



42 インスタンス作成作業 △ ○ △- 上記条件に基づき実施す



43 ミドルウェア設計、構築（クラスタウェア）【本番環境・テスト環境】

別添1_共通基盤利用時の役割分担 1/3 Copyright (C) 2012 Japan Post All Rights Reserved.



作成日2009.9.10


共通基盤担当




備考

44 アプリケーション要件によるバージョン、エディションの指定 △ ○ △- 共通基盤で用意する、

バージョンエディションを提示する。

-

45 ミドルウェアの調達、インストールメディア用意、保守の提供 △ ○ △- 共通基盤にてミドルウェア

の調達・保守の提供を行う。

-

46 クラスタ要件の提示 △ △ ○

- システムとして必要なクラスタ設定は共通基盤で実施する。業務アプリとして必要な要件があれば、申請書ベースで作業を実施する。

業務アプリケーションとして必要な業務要件があれば提示する。

47 クラスタ設計 △ ○ △- 上記の条件に基づき実施

する。-

48 クラスタ構築作業（Oracle、WebLogic、仮想IP） △ ○ △- 上記の条件に基づき実施

する。-

49 バックアップ設計、構築【本番環境・テスト環境】

50 業務要件によるOSバックアップ要件の提示 △ △ ○

- デフォルトでは、構築時に実施。それ以外はパッチ適用などのシステム変更時に実施。それ以外のバックアップは申請書ベースで実施する。

バックアップ取得頻度、取得範囲、条件等を提示する。

51 OSバックアップの設計 △ ○ △- 上記条件に基づき実施す

る。-

52 業務要件によるOS以外のバックアップ要件の提示 △ △ ○

- OS以外のバックアップについては申請書ベースで実施する。

業務アプリケーションとして必要な業務要件があれば提示する。

53業務要件によるOS以外のバックアップ設計(コンテンツバックアップの設計)

△ ○ △- 上記条件に基づき実施す

る。-

54 バックアップ環境の構築 △ ○ △- 上記条件に基づき実施す

る。-

55 アプリケーション開発【開発環境】

56 アプリケーション開発環境の準備 △ - ○- - 共通基盤の環境を確認

し、業務システム業者内に開発環境を用意する。

57 アプリケーション設計 △ - ○- - アプリケーションの設計を

行う。

58 アプリケーション開発 △ - ○- - アプリケーションの開発を

行う。

59 アプリケーション単体テスト、単体テスト結果報告書の作成 △ - ○

- - アプリケーション開発環境上でアプリケーションの単体テストを実施し、単体テスト結果報告書を作成する。

60 アプリケーション単体テスト結果の報告 △ - ○テスト結果を確認し承認する。

- 単体テスト結果を報告し、承認を得る。

61 監視・運用設計、構築【本番環境・テスト環境】

62 基盤環境運用要件（サービスレベル等）の定義 △ △ ○- - 現行システムの要件、及

び主管部からの要件を整理し、運用要件を定義す

63 業務アプリケーションのメンテナンス条件の設計、提示 △ △ ○

- - 業務アプリケーションのメンテナンス作業条件（環境、メンテナンス方法）を整理し、設計する。

64 業務アプリケーションのメンテナンスツールの修正 △ △ ○

- - 業務アプリケーションのメンテナンスに必要なツール等を修正する。

65 運用要件の定義 △ △ ○- デフォルト以外の設定に

ついては申請書ベースで実施

アプリケーション稼働の持続に必要なミドルウェア監視項目を提示する。

66 サーバ装置、ネットワーク装置のリソース情報収集設計 △ ○ △- デフォルト設定として実施

する。-

67 サーバ装置、ネットワーク装置のリソース情報収集設定作業 △ ○ △- デフォルト設定として実施

する。-

68 共用サーバ装置監視設計 △ ○ △

- プロセス監視、ログ監視、リソース監視についてはデフォルト設定で実施。それ以外については申請書ベースで実施する。

-

69 共用サーバ装置監視設定作業 △ ○ △

- プロセス監視、ログ監視、リソース監視についてはデフォルト設定で実施。それ以外については申請書ベースで実施する。

-

70 共用ネットワーク装置監視設計 △ ○ △- デフォルト設定として実施

する。-

71 共用ネットワーク装置監視設定作業 △ ○ △- デフォルト設定として実施

する。-

72 共用運用管理(トラブルチケット管理・変更管理)設計 △ ○ △

- 申請書が提示されれば実施。(デフォルトとしては個々の業務アプリケーションシステム毎に業務にあわせた機能を提供しない)

-

73 共用運用管理(トラブルチケット管理・変更管理)設定作業 △ ○ △

- 申請書が提示されれば実施。(デフォルトとしては個々の業務アプリケーションシステム毎に業務にあわせた機能を提供しない)

-

74 共用ウィルス対策設計 △ ○ △- デフォルト設定として実施

する。-

75 共用ウィルス対策ソフトのエージェントインストール作業 △ ○ △- デフォルト設定として実施

する。-

76 共用ウィルス対策ソフトの設定作業 △ ○ △- デフォルト設定として実施

する。-

77 ログ収集設計 △ ○ △

- デフォルト設定として実施する。個別のアプリのパス、ファイル名については共通基盤側から指定したものが対象

-

78 ログ収集エージェントのインストール △ ○ △- デフォルト設定として実施

する。-

79 ログ収集ツールの設定作業 △ ○ △- デフォルト設定として実施

する。-




作成日2009.9.10


共通基盤担当




備考

80 共用バッチ管理設計 △ ○ △ - 申請書に応じて実施 -81 共用バッチ管理エージェントのインストール △ ○ △ - 申請書に応じて実施 -82 共用バッチ管理設定作業 △ ○ △ - 申請書に応じて実施 -83 共用機能の設計、構築【本番環境・テスト環境】

84 基盤提供機能要件定義 △ △ ○

業務要件を提示する。共通基盤の提供する機能一覧を提示の上、どの機能を使用するか決定する。

システムの要件、及び主管部からの要件を整理し、利用する共用機能の要件を定義する。申請書が必要な機能を利用する場合は、申請書を提示する。

85 共用シングルサインオン設計 △ ○ △- 申請書に応じて実施す

る。-

86 共用シングルサインオン設定作業 △ ○ △- 申請書に応じて実施す

る。-

87 共用DNS設計 △ ○ △- 申請書に応じて実施す

る。-

88 共用DNSの設定作業 △ ○ △- 申請書に応じて実施す

る。-

89 共用NTP設計 △ ○ △- デフォルト設定として実施

する。-

90 共用NTP設定作業 △ ○ △- デフォルト設定として実施

する。-

91 共用メール設計 △ ○ △- 申請書に応じて実施す

る。-

92 共用メール設定作業 △ ○ △- 申請書に応じて実施す

る。-

93 共用ディスク装置設計 △ ○ △- 申請書に応じて実施す

る。-

94 共用ディスク装置設定作業 △ ○ △- 申請書に応じて実施す

る。-

95 共用ESB設計 △ ○ △- 申請書に応じて実施す

る。-

96 共用ESB設定作業 △ ○ △- 申請書に応じて実施す

る。-

97 共用BI設計 △ ○ △- 申請書に応じて実施す

る。-

98 共用BI設定作業 △ ○ △- 申請書に応じて実施す

る。-

99 環境引渡【本番環境・テスト環境】

100 共通基盤の環境引渡計画策定 △ ○ △

- どの時期に引渡し可能であるか提示する。

- 引渡環境の操作手順、設定内容等、アプリケーションリリース作業に必要な情報をドキュメントにとりまとめ、スケジュール調整を実施する。

101 共通基盤からの環境引渡 △ ○ △- アプリのメンテナンスに必

要な環境情報を提示す共通基盤から引渡説明を受ける。

102 アプリケーションリリース【本番環境・テスト環境】

103 共通基盤作業環境情報の提示 △ ○ △- アプリのメンテナンスに必

要なアクセス手順等を提示する。

- 共通基盤におけるリリース作業に必要な情報を提示する。

104 リリース計画書の作成 △ △ ○

- - 共通基盤から提示される作業上必要な情報を基にリリース計画を策定し、関係者と合意する。

105 共通基盤へのリリース △ △ ○

- 他システムと共同利用しているシステムについては作業の立会いを実施する。

共通基盤環境へアプリケーションをリリースする。

106 テスト設計（統合、システムテスト） △ △ ○- - 共通基盤上にリリースした

アプリケーションのテスト項目を設計する。

テスト環境にて実施する。

107 統合、システムテストの実施 △ △ ○

- 初回の稼動テストについては立会いを実施する。

共通基盤上にリリースしたアプリケーションのテストを実施する。

テスト環境にて実施する。

108 テスト結果の報告 △ △ ○

テスト結果を確認し承認する。

- 共通基盤上にリリースしたアプリケーションのテスト結果を報告する。

109 性能テスト【テスト環境】110 性能テスト要件の提示 ○ △ △ - - -

111 性能テスト計画の策定 △ △ ○- 性能試験ツールについて

は申請書ベースで提供する。

性能テストの実施項目を主管部と協議し、ドキュメントにまとめる。

112 性能テスト環境の構築 △ △ ○

- - アプリケーションをリリースした共通基盤上にて、アプリケーションの性能テストを実施するための環境を構築する。

113 性能テストの実施 △ △ ○ - - 性能テストを実施する。

114 テスト結果の報告 △ △ ○テスト結果を確認し承認する。

- 性能テストの結果を報告する。

115 受入テスト【本番環境・テスト環境】

116 受入テスト計画 ○ △ △受け入れテストの計画を実施する。

-

117 受入テストの実施 ○ △ △受入テストを実施する。 - 主管部が実施する受入テ

ストの支援を実施する。118 移行作業【本番環境】

119 移行計画の策定 ○ △ △- - 計画策定に必要な情報提

供を実施する。

120 移行作業 △ △ ○

- ネットワーク変更作業を実施する。

業務アプリケーション側でサービスインする上で行う必要がある作業を実施する。

121 移行時の稼働確認 ○ △ △- - 切り替え作業の支援とし

て、サーバー側で待機を122 検収

123 設計図書、作業結果報告の納品 △ ○ ○- 基盤部分については追

加・修正したドキュメントを提出する。

設計図書、作業結果報告等のドキュメントをメディアに取り纏め、納品する。

124 検収 ○ △ △納品物に対する検収を行う。

- -

125


1/2 別添 2_メインデータセンタ利用上の注意 Copyright (C) 2012 Japan Post All Rights Reserved.

別添 2_メインデータセンタ利用上の注意

メインデータセンタを利用するにあたり、アプリケーション実装形態が共通基盤の一部を利用する場合や、

個別に構築する場合等、業務アプリケーション受託業者が機器類を用意しメインデータセンタに設置する場

合は、以下の制約があるので注意すること。

１．サーバラックの制約事項

メインデータセンタに設置するサーバラックは、データセンタ管理業者が予め用意する免震台の上に設

置する。ラックの設置は原則、業務アプリケーション受託業者が行う。

なお、免震台を利用する場合、設置するラックのサイズ等に以下の制約があるので注意すること。サーバラック制約事項

標準サイズ・高さ 42U 以下、幅 600mm以内、奥行き 1,200mm 以内。

設置時の注意事項・サーバラックの底面にレベラーを取り付け、免震台へ設置する。免震台下面とは

固定されない。

・サーバラックの設置は、データセンタ管理業者立会いの下実施する。

1 ラックあたりのサイズ・重量・熱量によっては、フロア/空調工事の対応が必要になる可能性があります。

その場合、データセンタ管理業者にて対応可否を判断する必要がありますので、上記に定めた標準ラッ

ク制限を超えるラックを設置する場合、「4.ファシリティ工期について」の必要工期を十分に満たす期間をも

って共通基盤担当へ相談すること。

データセンタ管理業者の対応が可能と判断されましたら、ラック設置予定日の 3 ヶ月前までにラック底面

図を含むラックの各諸元図を共通基盤担当へ提出すること。

なお、希望する位置とは異なる場所にラックを設置しなくてはならない場合もあるので留意すること。

２．耐荷重

サーバラック、搭載物の合計重量で１ラック当り 500kg 以内を標準とする。

※1 ラックの底面積を 0.72 平米（幅 0.6m×奥行 1.2m）とした場合。

上記制約を超える場合、データセンタ管理業者にて対応可否を判断する必要があります。

「1．サーバラックの制約事項」にあるとおり、必要工期を十分に満たす期間をもって共通基盤担当へ相

談すること。

2/2 別添 2_メインデータセンタ利用上の注意 Copyright (C) 2012 Japan Post All Rights Reserved.

３．電源

PDF 及び PDF からラックまでの電源ケーブルの配線、電源ケーブルと床下コンセントボックスとの接続ま

ではデータセンタ管理業者が実施する。床下コンセントボックスは業務アプリケーション受託業者で必要数

用意し、設置予定日 1週間前までにデータセンタ管理業者へ引き渡すこと。

なお、供給される電源は 2系統、CVCF より配電される。

単相 200V 30A まで

単相 100V 15A まで電源ライン

標準容量三相 200V 30A まで

注：三相電源は特別提供の為、使用可否判断含め提供希望日の 6 ヶ月前までに共通基

盤担当へ相談する事。

ラックあたりの標準電源本数概ね 6本（200V：4 本、100V：2 本）＊PDF2 系統からの合計本数。

ラックあたりの標準供給電力 5.5kVA（皮相）但し、100V については PDF 辺り合計 75kVA の制限あり。

PDF 収容状況によってはデータセンタ管理業者との間で設計交渉となる事あり。

４．ファシリティ工期について

機器構成が判明次第、必要な電力量等を報告すること。（報告様式は契約後に提示する。）

※提出された所要電力情報によりデータセンタ管理業者で電力、空調等の供給量を確認し、必要に応

じた増強工事を行う。このため、必要な電力量は早めに共通基盤担当に報告すること。なお、増強工

事にかかる日数は以下のとおりとなるため、構築スケジュール等に影響がないよう留意すること。工事内容必要工期

既設 PDF 内ユニット追加工事 1 ヶ月

PDF 増設工事 3 ヶ月

架台製作・設置工事 3 ヶ月

CVCF 増強工事（※） 6 ヶ月

空調設備増設工事（※） 6 ヶ月

※CVCF 増強や空調設備増強は長期間必要となるため、大規模システムの構築計画は比較的はやい段

階でデータセンタ管理業者へ報告する必要がある。

上記工事の要否はデータセンタ管理業者の判断による。

既設PDF内ユニット追加工事、PDF増設工事や架台製作・設置工事についてはアプリケーション受託

業者からの情報提供が重要となるため、可及的速やかに報告のこと。

５．その他

・サーバラック間及びラック内の LAN ケーブルは業務アプリケーション受託業者で用意し配線すること。

なお、フリーアクセス床の高さは 450mm。また免震台稼動余長が 300mm 必要である。

・マシンルーム外への構内配線については、データセンタ管理業者が管理する。

・メインデータセンタへの入館及び物品の持込・持出等については別に定める手続きによる。

・その他、不明な点があれば共通基盤担当に確認すること。

ラック

PDFCVCF コンセ

ントボ

ックス

データセンタ管理業者業務アプリケーション

受託業者

PDU

コンセントボックスと電源ケーブルの結線はデータセンタ管理業者にて行う。

1/2 別添 3_バックアップセンタ利用上の注意 Copyright (C) 2012 Japan Post All Rights Reserved.

別添 3_バックアップセンタ利用上の注意

バックアップセンタを利用するにあたり、アプリケーション実装形態が共通基盤の一部を利用する場合や、

個別に構築する場合等、業務アプリケーション受託業者が機器類を用意しバックアップセンタに設置する場

合は、以下の制約があるので注意すること。

１．サーバラックの制約事項

バックアップセンタに設置するサーバラックは、データセンタ管理業者が予め用意する耐震架台の上に

設置する。ラックの設置は原則、業務アプリケーション受託業者が行う。

なお、設置するラックのサイズ等に以下の制約があるので注意すること。サーバラック制約事項

標準サイズ・高さ 2,200mm 以下、幅 600mm以内、奥行き 1,200mm 以内。

各ラック列間は、最低 1,200mm以上の間隔を空けて設置すること。

設置時の注意事項・サーバ室に設置するラックは、データセンタ指定の耐震固定工事を実施します。

・サーバラックの設置は、データセンタ管理業者立会いの下実施する。

1 ラックあたりのサイズ・重量・熱量によっては、フロア/空調工事の対応が必要になる可能性があります。

その場合、データセンタ管理業者にて対応可否を判断する必要がありますので、上記に定めた標準ラッ

ク制限を超えるラックを設置する場合、「4.ファシリティ工期について」の必要工期を十分に満たす期間をも

って共通基盤担当へ相談すること。

データセンタ管理業者の対応が可能と判断されましたら、ラック設置予定日の 3 ヶ月前までにラック底面

図を含むラックの各諸元図を共通基盤担当へ提出すること。

なお、希望する位置とは異なる場所にラックを設置しなくてはならない場合もあるので留意すること。

２．耐荷重

サーバラック、搭載物の合計重量で１ラック当り 500kg 以内を標準とする。

※1 ラックの底面積を 0.72 平米（幅 0.6m×奥行 1.2m）とした場合。

上記制約を超える場合、データセンタ管理業者にて対応可否を判断する必要があります。

「1．サーバラックの制約事項」にあるとおり、必要工期を十分に満たす期間をもって共通基盤担当へ相

談すること。

2/2 別添 3_バックアップセンタ利用上の注意 Copyright (C) 2012 Japan Post All Rights Reserved.

３．電源

PDF 及び PDF からラックまでの電源ケーブルの配線、電源ケーブルと床下コンセントボックスとの接続ま

ではデータセンタ管理業者が実施する。床下コンセントボックスは標準品(NEMA 規格または JIS 規格)をデ

ータセンタ管理者で用意・設置します。

ただし標準品以外の電源コネクタを使用する場合は、業務アプリケーション受託業者でコンセントボック

スを用意し、設置予定日 1週間前までにデータセンタ管理業者へ引き渡すこと。

なお、供給される電源は 2系統、CVCF より配電される。

単相 200V 30A まで単相 100V 15A まで

電源ライン

標準容量三相 200V 30A まで

注：三相電源は特別提供の為、使用可否判断含め提供希望日の 6 ヶ月前までに共通基

盤担当へ相談する事。ラックあたりの標準電源本数概ね 6本（200V：4 本、100V：2 本）＊PDF2 系統からの合計本数。ラックあたりの標準供給電力 5.5kVA（皮相）但し、100V については PDF 辺り合計 75kVA の制限あり。

PDF 収容状況によってはデータセンタ管理業者との間で設計交渉となる事あり。

４．ファシリティ工期について

機器構成が判明次第、必要な電力量等を報告すること。（報告様式は契約後に提示する。）

※提出された所要電力情報によりデータセンタ管理業者で電力、空調等の供給量を確認し、必要に応

じた増強工事を行う。このため、必要な電力量は早めに共通基盤担当に報告すること。なお、増強工

事にかかる日数は以下のとおりとなるため、構築スケジュール等に影響がないよう留意すること。工事内容必要工期

既設 PDF 内ユニット追加工事 1 ヶ月

PDF 増設工事 3 ヶ月

架台製作・設置工事 3 ヵ月

CVCF 増強工事（※） 6 ヶ月

空調設備増設工事（※） 6 ヶ月

※CVCF 増強や空調設備増強は長期間必要となるため、大規模システムの構築計画は比較的はやい段

階でデータセンタ管理業者へ報告する必要がある。

上記工事の要否はデータセンタ管理業者の判断による。

既設 PDF 内ユニット追加工事、PDF 増設工事や架台製作・設置工事については業務アプリケーショ

ン受託業者からの情報提供が重要となるため、可及的速やかに報告のこと。

５．その他

・サーバラック間及びラック内の LAN ケーブルは業務アプリケーション受託業者で用意し配線すること。

・マシンルーム外への構内配線については、データセンタ管理業者が管理する。

・バックアップセンタへの入館及び物品の持込・持出等については別に定める手続きによる。

・その他、不明な点があれば共通基盤担当に確認すること。

ラック

PDFCVCF コンセ

ントボ

ックス

データセンタ管理業者業務アプリケーション

受託業者

PDU

Documents

次世代郵便情報システム共通基盤 共通基盤ガイドラ …20%e4%bb%95...レビュー、確認 作成日2009.9.10 項番作業項目 業務アプリ-3-4

次世代郵便情報システム共通基盤共通基盤ガイドラ …20%e4%bb%95...レビュー、確認作成日2009.9.10 項番作業項目業務アプリ-3-4