特開 2024-128437 クラウドサービス支援装置、クラウドサービス支援方法およびコンピュータプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2024128437

(43)【公開日】2024-09-24

(54)【発明の名称】クラウドサービス支援装置、クラウドサービス支援方法およびコンピュータプログラム

(51)【国際特許分類】

   G06Q 10/20 20230101AFI20240913BHJP

   G06F 9/48 20060101ALI20240913BHJP

【ＦＩ】

G06Q10/20

G06F9/48 300A

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2023037410

(22)【出願日】2023-03-10

(71)【出願人】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100109313

【弁理士】

【氏名又は名称】机 昌彦

(74)【代理人】

【識別番号】100149618

【弁理士】

【氏名又は名称】北嶋 啓至

(72)【発明者】

【氏名】野中 澪

(72)【発明者】

【氏名】今井 裕子

(72)【発明者】

【氏名】米田 匡史

(72)【発明者】

【氏名】唐津 杏莉

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049CC15

(57)【要約】

【課題】 連携しているシステムの障害発生に起因したＳａａＳに対するＳａａＳ利用者のサービス利用満足度の低下の抑制を図る。
【解決手段】 支援装置３０の通知部３１は、連携システム３６に障害が発生している場合に、連携システム３６の障害発生を支援対象のＳａａＳ３５に通知する。受付部３２は、支援対象のＳａａＳ３５を利用しているＳａａＳ利用者からＳａａＳ３５を介して連携システム３６に出力された処理対象であるタスクについて障害発生の連携システム３６の復旧時におけるタスクの優先処理に関する要望情報をＳａａＳ利用者から受け付ける。出力部３３は、受け付けた要望情報を含む優先処理依頼情報を優先処理依頼先の連携システム３６に出力する。
【選択図】 図６

【特許請求の範囲】

【請求項1】

クラウドサービスを提供する支援対象のＳａａＳ（Software as a Service）と連携している連携システムに障害が発生している場合に、連携システムの障害発生を支援対象のＳａａＳに通知する通知部と、
支援対象のＳａａＳを利用しているＳａａＳ利用者からＳａａＳを介して連携システムに出力された処理対象であるタスクについて障害発生の連携システムの復旧時におけるタスクの優先処理に関する要望情報をＳａａＳ利用者から受け付ける受付部と、
受け付けた要望情報を含む優先処理依頼情報を優先処理依頼先の連携システムに出力する出力部と
を備えるクラウドサービス支援装置。

【請求項2】

前記要望情報は、障害発生の連携システムにおいて処理待ち状態となっている複数のタスクのうち、連携システムの復旧時において優先処理を要望するタスクである優先処理タスクを表す情報を含み、
連携システムの復旧時における優先処理タスクの優先処理を前記優先処理依頼情報によって連携システムに依頼する優先処理依頼サービスの料金算出用の料金表情報と、前記要望情報に含まれている優先処理タスクの数とを用いて、優先処理依頼サービスの利用料金をＳａａＳ利用者ごとに算出する算出部をさらに備える請求項１に記載のクラウドサービス支援装置。

【請求項3】

支援対象のＳａａＳがサービスを提供できなくなる障害が発生している場合に、ＳａａＳ利用者から障害発生のＳａａＳへの問合せを受け付け当該問合せに対して障害発生のＳａａＳに代わって回答する代行回答部をさらに備える請求項１に記載のクラウドサービス支援装置。

【請求項4】

前記代行回答部は、支援対象のＳａａＳの稼働状況を表す稼働状況情報を用いて、支援対象のＳａａＳに障害が発生していることを検知する請求項３に記載のクラウドサービス支援装置。

【請求項5】

ＳａａＳ利用者から障害発生のＳａａＳへの問合せの内容を分析した分析結果を用いてＦＡＱ（Frequently Asked Questions）を生成し、生成したＦＡＱの情報を支援対象のＳａａＳに向けて出力する生成部をさらに備える請求項３に記載のクラウドサービス支援装置。

【請求項6】

コンピュータによって、
クラウドサービスを提供する支援対象のＳａａＳ（Software as a Service）と連携している連携システムに障害が発生している場合に、連携システムの障害発生を支援対象のＳａａＳに通知し、
支援対象のＳａａＳを利用しているＳａａＳ利用者からＳａａＳを介して連携システムに出力された処理対象であるタスクについて障害発生の連携システムの復旧時におけるタスクの優先処理に関する要望情報をＳａａＳ利用者から受け付け、
受け付けた要望情報を含む優先処理依頼情報を優先処理依頼先の連携システムに出力するクラウドサービス支援方法。

【請求項7】

クラウドサービスを提供する支援対象のＳａａＳ（Software as a Service）と連携している連携システムに障害が発生している場合に、連携システムの障害発生を支援対象のＳａａＳに通知する処理と、
支援対象のＳａａＳを利用しているＳａａＳ利用者からＳａａＳを介して連携システムに出力された処理対象であるタスクについて障害発生の連携システムの復旧時におけるタスクの優先処理に関する要望情報をＳａａＳ利用者から受け付ける処理と、
受け付けた要望情報を含む優先処理依頼情報を優先処理依頼先の連携システムに出力する処理と
をコンピュータに実行させるためのコンピュータプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、クラウドサービスに係る技術に関する。

【背景技術】

【0002】

クラウドサービスを提供するシステムの一つとして、ＳａａＳ（Software as a Service）と呼ばれるものがある。ＳａａＳは、情報通信網（インターネット）を介してソフトウェアを提供する。このようなＳａａＳを運用するＳａａＳ事業者は、ソフトウェアを実行させるために、別の事業者によるＰａａＳ（Platform as a Service）やＩａａＳ（Infrastructure as a Service）を利用することがある。ＰａａＳもＩａａＳも、クラウドサービスを提供するシステムであるが、ＰａａＳは、情報通信網（インターネット）を介してソフトウェア（アプリケーションプログラム）を実行するプラットフォームを提供する。ＩａａＳは、情報通信網（インターネット）を介してソフトウェアを実行する計算機（コンピュータ）や記憶装置などのハードウェアや、通信回線などのインフラを提供する。ＩａａＳは、ＨａａＳ（Hardware as a Service）と呼ばれることもある。

【0003】

なお、特許文献１（特開２０１１－２５８０９８号公報）には、クラウドサービスを提供しているネットワーク装置とサーバ計算機から取得する情報に基づいて、処理応答の遅延の要因を特定する技術が示されている。

【先行技術文献】

【特許文献】

【0004】

【特許文献1】特開２０１１－２５８０９８号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

ところで、ＳａａＳは、利用しているＰａａＳやＩａａＳに障害が発生することに因りサービスを提供できなくなってしまう。これにより、ＰａａＳやＩａａＳの障害発生に起因して、ＳａａＳを利用しているＳａａＳ利用者は作業中の業務などが滞ることになる。このため、障害が解消されてＰａａＳやＩａａＳが復旧した際には、ＳａａＳ利用者にとっては、ＳａａＳを介してＰａａＳやＩａａＳに出力した処理対象（以下、タスクとも称する）が直ちにＰａａＳやＩａａＳによって処理されることが望ましい。しかしながら、復旧したＰａａＳやＩａａＳは、障害発生により滞ってしまった未処理のタスクを処理しなければならない状態であり、そのような未処理のタスクを受け付け順に処理していくこととなる。このようなことから、ＰａａＳやＩａａＳが復旧しても、滞ってしまった未処理のタスクの中で受け付け順が遅かったタスクにあっては処理されるまでに長い時間が掛かってしまうし、ＳａａＳ利用者はタスクが処理される時間を読めない。障害発生に因り作業が滞った上に、このような状況は、ＳａａＳに対するＳａａＳ利用者のサービス利用満足度を低下させてしまう要因となる。

【0006】

本発明は上記課題を解決するために考え出されたものである。すなわち、本発明の主な目的は、ＰａａＳやＩａａＳなどの他のクラウドサービスのシステム障害発生に起因したＳａａＳに対するＳａａＳ利用者のサービス利用満足度の低下の抑制を図る技術を提供することにある。

【課題を解決するための手段】

【0007】

上記目的を達成するために、本発明に係るクラウドサービス支援装置は、その一態様として、
クラウドサービスを提供する支援対象のＳａａＳ（Software as a Service）と連携している連携システムに障害が発生している場合に、連携システムの障害発生を支援対象のＳａａＳに通知する通知部と、
支援対象のＳａａＳを利用しているＳａａＳ利用者からＳａａＳを介して連携システムに出力された処理対象であるタスクについて障害発生の連携システムの復旧時におけるタスクの優先処理に関する要望情報をＳａａＳ利用者から受け付ける受付部と、
受け付けた要望情報を含む優先処理依頼情報を優先処理依頼先の連携システムに出力する出力部と
を備える。

【0008】

また、本発明に係るクラウドサービス支援方法は、その一態様として、
コンピュータによって、
クラウドサービスを提供する支援対象のＳａａＳ（Software as a Service）と連携している連携システムに障害が発生している場合に、連携システムの障害発生を支援対象のＳａａＳに通知し、
支援対象のＳａａＳを利用しているＳａａＳ利用者からＳａａＳを介して連携システムに出力された処理対象であるタスクについて障害発生の連携システムの復旧時におけるタスクの優先処理に関する要望情報をＳａａＳ利用者から受け付け、
受け付けた要望情報を含む優先処理依頼情報を優先処理依頼先の連携システムに出力する。

【0009】

さらに、本発明に係るコンピュータプログラムは、その一態様として、
クラウドサービスを提供する支援対象のＳａａＳ（Software as a Service）と連携している連携システムに障害が発生している場合に、連携システムの障害発生を支援対象のＳａａＳに通知する処理と、
支援対象のＳａａＳを利用しているＳａａＳ利用者からＳａａＳを介して連携システムに出力された処理対象であるタスクについて障害発生の連携システムの復旧時におけるタスクの優先処理に関する要望情報をＳａａＳ利用者から受け付ける処理と、
受け付けた要望情報を含む優先処理依頼情報を優先処理依頼先の連携システムに出力する処理と
をコンピュータに実行させる。

【発明の効果】

【0010】

本発明によれば、ＰａａＳやＩａａＳなどの他のクラウドサービスのシステム障害発生に起因したＳａａＳに対するＳａａＳ利用者のサービス利用満足度の低下の抑制を図ることができる。

【図面の簡単な説明】

【0011】

【図1】本発明に係る第１実施形態のクラウドサービス支援装置（支援装置）の構成を説明する図である。

【図2】第１実施形態の支援装置と支援対象のＳａａＳとの接続関係を表す図である。

【図3】第１実施形態の支援装置における動作の一例を説明するフローチャートである。

【図4】本発明に係る第２実施形態のクラウドサービス支援装置（支援装置）の構成を説明する図である。

【図5】本発明に係る第３実施形態のクラウドサービス支援装置（支援装置）の構成を説明する図である。

【図6】その他の実施形態のクラウドサービス支援装置（支援装置）の構成を説明する図である。

【図7】その他の実施形態の支援装置における動作の一例を説明するフローチャートである。

【発明を実施するための形態】

【0012】

以下に、本発明に係る実施形態を、図面を参照しつつ説明する。

【0013】

＜第１実施形態＞
図１は、本発明に係る第１実施形態のクラウドサービス支援装置の構成を説明する図である。このクラウドサービス支援装置（以下、省略して支援装置とも称する）１は、ＳａａＳ（Software as a Service）３に支援サービスを提供する機能を備える装置である。ＳａａＳ３とは、クラウドサービスとして情報通信網（インターネット）を介してソフトウェアを提供しているシステムである。また、ここでは、ＳａａＳ３を利用している人や企業などをまとめてＳａａＳ利用者と称することとする。

【0014】

支援装置１が支援サービスを提供する支援対象のＳａａＳ３の数は限定されないが、例えば、図２に表されるように、支援対象のＳａａＳ３は複数であり、支援装置１は、支援対象のＳａａＳ３のそれぞれに接続される。それら支援対象のＳａａＳ３は、ＩａａＳやＰａａＳから提供される他のクラウドサービスを利用している。なお、以下の説明では、ＳａａＳ３が利用している他のクラウドサービスのシステムを、説明の便宜上、その総称として連携システムと称することとする。支援装置１は、連携システム５とも接続されている。

【0015】

支援装置１がＳａａＳ３に提供する支援サービスとは、ＳａａＳ３がＳａａＳ利用者７にサービスを提供できない原因がＳａａＳ３ではなく、連携システム５の障害発生である場合に関係するサービスである。

【0016】

すなわち、連携システム５は、例えばキューイングシステムを採用している。これにより、ＳａａＳ３から連携システム５に出力されたタスクは連携システム５のキューに一時的に保持され、保持された順に当該キューから取り出されて連携システム５により処理される。しかし、連携システム５に障害が発生した場合には、ＳａａＳ３から連携システム５に出力されたタスクは処理されず、キューに滞ることになる。

【0017】

このような状態から連携システム５が復旧した場合、ＳａａＳ利用者７にしてみれば、連携システム５の復旧と同時に自身の未処理のタスクが処理されることが望ましいと想定される。また、それができなくとも未処理のタスクが処理される処理予測時間（処理予測時刻）が分かることが好ましいと想定される。しかしながら、システム復旧時に、連携システム５によって未処理のタスクがキューに保持された順で処理される場合には、ＳａａＳ利用者７によっては、連携システム５の復旧から自身の未処理のタスクが処理されるまでに長い時間が掛かることがある。また、ＳａａＳ利用者７は、連携システム５の処理状況が分からないので、自身の未処理のタスクが何時に処理されるのが全く読めないという状況となる。このようなＳａａＳ利用者７に不都合な状況の原因が連携システム５の障害であるのにも拘わらず、ＳａａＳ利用者７がＳａａＳ３に対して不満を持ってしまうことが考えられる。

【0018】

ところで、本発明者は次のようなことに気付いた。気付いたこととは、障害により連携システム５に滞ってしまった未処理のタスクには、ＳａａＳ利用者７にとっての処理の優先度があるということである。つまり、連携システム５に滞ってしまった未処理（処理待ち状態）のタスクの中には、ＳａａＳ利用者７がシステム復旧時にできるだけ早く処理して欲しいタスクもあれば、連携システム５による処理順での処理をＳａａＳ利用者７が待つことができるタスクもある。この気付きから本発明者は、連携システム５に障害が発生してしまった場合に、当該連携システム５の復旧時に処理を優先して欲しいタスクの情報をＳａａＳ利用者７から受け付け、当該情報を障害発生の連携システム５に出力するというサービスを考え出した。この情報を受けた連携システム５において、システム復旧時に、当該情報に基づいて未処理のタスクの処理順が制御されて優先処理の要望があるタスクが優先的に処理されることにより、連携システム５の障害発生に起因したＳａａＳ利用者７の不満を緩和することが期待される。つまり、本発明者は、連携システム５の障害発生に起因したＳａａＳ３に対するＳａａＳ利用者７のサービス利用満足度の低下の抑制を図るべく、連携システム５の復旧時におけるタスクの優先処理依頼サービスをＳａａＳ３に提供することを考え出した。

【0019】

支援装置１は、そのような優先処理依頼サービスを支援対象のＳａａＳ３に提供する機能を備えている。すなわち、支援装置１は、コンピュータ装置であり、図１に表されるように、制御装置１０と、記憶装置２０とを備えている。記憶装置２０は、データや、コンピュータプログラム（以下、プログラムとも記す）２１を記憶する記憶媒体を備えている。記憶装置には、磁気ディスク装置や、半導体メモリ素子などの複数の種類があり、さらに、半導体メモリ素子には、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）などの複数の種類があるというように、多数の種類がある。支援装置１が備える記憶装置２０の種類や数は限定されず、その説明は省略される。また、支援装置１に複数種の記憶装置２０が備えられる場合には、それらをまとめて記憶装置２０と記すこととする。

【0020】

制御装置１０は、ＣＰＵ（Central Processing Unit）などのプロセッサにより構成される。当該制御装置１０は、記憶装置２０に記憶されているプログラム２１を読み出して実行することにより、当該プログラム２１に基づいた様々な機能を持つことができる。ここでは、制御装置１０は、ＳａａＳ３を支援する優先処理依頼サービスを提供する機能部として、検知部１１と、通知部１２と、受付部１３と、出力部１４とを有している。

【0021】

検知部１１は、支援対象のＳａａＳ３が連携している連携システム５に障害が発生していることを検知する。ここでは、連携システム５に障害が発生していることを検知する手法は限定されるものではない。このため、その詳細な説明は省略されるが、連携システム５の障害検知手法としては、連携システム５の稼働状況に関わる情報をＳＮＳ（Social Networking Service）やＳａａＳ３などから取得し、取得した情報に基づいて検知する手法が例として挙げられる。また、連携システム５の障害検知手法の別の例としては、支援装置１の操作者などにより入力された連携システム５の障害発生を表す情報によって、検知部１１が連携システム５の障害発生を検知してもよい。

【0022】

通知部１２は、検知部１１が連携システム５の障害発生を検知した場合に、障害発生通知をもってその連携システム５の障害発生を支援対象のＳａａＳ３に通知する。障害発生通知は、障害が発生したことを表す情報と、障害が発生した連携システム５を表す情報とを含む。障害発生通知の送信先は、障害が発生した連携システム５と連携している支援対象のＳａａＳ３はもちろんのこと、それ以外の支援対象のＳａａＳ３も含まれていてもよい。つまり、障害発生の連携システム５と連携している支援対象のＳａａＳ３に障害発生通知の送信先が限定されるのか否かは、例えば支援装置１の運用者などによって適宜設定されるものであり、ここでは、限定されない。

【0023】

通知部１２は、さらに、要望受け付け可能通知を送信する。要望受け付け可能通知は、障害発生の連携システム５を利用している支援対象のＳａａＳ３に向けて送信される通知であり、次のような要望を支援装置１が受け付け可能であることを知らせる通知である。その要望とは、連携システム５の障害発生によりＳａａＳ３のサービスが受けられなくなっているＳａａＳ利用者７から、障害発生の連携システム５が復旧した際にタスクの優先処理を望むという要望である。

【0024】

支援対象のＳａａＳ３においては、支援装置１から要望受け付け可能通知を受信した場合には、次のような通知が例えば電子メールなどによりＳａａＳ利用者７に送信される。その通知とは、連携システム５に障害が発生してＳａａＳ３がサービスを提供できなくなっていることを知らせると共に、システム復旧時における優先処理の要望を受け付けることを知らせる通知である。

【0025】

受付部１３は、連携システム５の障害発生に因りＳａａＳ３のサービスが受けられなくなっているＳａａＳ利用者７から、障害発生の連携システム５が復旧した場合における優先処理の要望情報を受け付ける。要望情報には、障害発生の連携システム５において滞っている未処理（処理待ち状態）の複数のタスクのうち、ＳａａＳ利用者７が連携システム５の復旧時に優先処理を要望するタスクである優先処理タスクを表す情報（優先処理タスク識別情報）が含まれている。また、システム復旧時における優先処理において、優先度に応じた複数のランク（優先ランク）が設定されている場合がある。この場合には、要望情報に含まれる優先処理タスク識別情報に、ＳａａＳ利用者７により指定された処理の優先ランクを表す優先ランク情報が関連付けられる。

【0026】

受付部１３が要望情報を受け付ける手法としては、例えば、ＳａａＳ３により用意された要望情報受け付け用のウェブページが用いられる手法がある。つまり、ＳａａＳ３により用意された要望情報受け付け用のウェブページによって、ＳａａＳ利用者７からの要望情報が受け付けられ、受け付けられた要望情報が支援装置１に向けて出力される。ＳａａＳ３から支援装置１への要望情報の出力は、例えば、ＳａａＳ利用者７により送信要求が入力されたことを契機として実行される。

【0027】

なお、要望情報の受け付けにウェブページが用いられる場合には、例えば、ＳａａＳ３からＳａａＳ利用者７に送信される優先処理の要望受け付けを知らせる電子メールには、要望情報受け付け用のウェブページに接続する当該ウェブページのアドレス情報であるリンク情報が含まれる。また、ここでは、要望情報は、優先処理を要望するＳａａＳ利用者７により出力される情報であり、連携システム５の障害発生の悪影響を受けている全てのＳａａＳ利用者７により出力されるとは限らない。さらに、障害発生の連携システム５において複数のタスクが処理待ち状態となっているＳａａＳ利用者７が、それら処理待ち状態の全てのタスクの優先処理を要望するとは限らない。

【0028】

支援装置１の出力部１４は、受付部１３により受け付けられた要望情報を含む優先処理依頼情報を障害発生の連携システム５に向けて出力する。つまり、優先処理依頼情報は、優先処理タスクを表す優先処理タスク識別情報を含む。また、優先処理における複数の優先ランクが設定されている場合には、優先処理依頼情報は、さらに、優先処理タスクの優先ランクを表す優先ランク情報が含まれる。

【0029】

支援装置１と接続している連携システム５は、出力部１４から出力された優先処理依頼情報を受信した場合に、受信した優先処理依頼情報を用いてシステム復旧時におけるタスクの処理順を制御する機能を備えている。これにより、システム復旧時において、優先処理が依頼された優先処理タスクは、連携システム５によって、優先処理の依頼が無いタスクよりも優先的に処理されることとなる。ここでは、連携システム５によるタスクの処理順の制御手法は限定されないので、その説明は省略される。

【0030】

第１実施形態の支援装置１は上述したように構成されている。次に、支援装置１における優先処理依頼サービスに関わる動作の一例を、図３を利用して説明する。図３は、支援装置１における優先処理依頼サービスに関わる動作の一例を説明するフローチャートである。

【0031】

例えば、検知部１１が連携システム５の障害発生を検知すると（図３におけるステップ１０１）、少なくとも障害発生の連携システム５と連携している支援対象のＳａａＳ３に向けて通知部１２が連携システム５の障害発生を通知する（ステップ１０２）。また、通知部１２は、障害発生の連携システム５と連携している支援対象のＳａａＳ３に向けて要望受け付け可能通知を出力する。

【0032】

その後、優先処理に関する要望情報がＳａａＳ利用者７からＳａａＳ３を介して送信されてきた場合には、受付部１３がその要望情報を受け付ける（ステップ１０３）。そして、出力部１４が、要望情報を含む優先処理依頼情報を障害発生の連携システム５に向けて出力する（ステップ１０４）。連携システム５は、システム復旧時には、受信した優先処理依頼情報に含まれている要望情報を参照してタスクの処理順を制御する。

【0033】

第１実施形態の支援装置１は、連携システム５の障害発生に起因してＳａａＳ３のサービスを受けられなくなっているＳａａＳ利用者７から優先処理の要望情報を受け付け、システム復旧時における優先処理を連携システム５に依頼する優先処理依頼サービスを提供する構成を備えている。これにより、障害発生の連携システム５が復旧した際に、優先処理が要望された優先処理タスクは連携システム５により優先的に処理されることとなるから、連携システム５の障害発生の悪影響を受けたＳａａＳ利用者７の不満は、優先処理が無い場合に比べて軽減されることが期待される。すなわち、支援装置１は、連携システム５の障害発生に起因したＳａａＳ３に対するＳａａＳ利用者７のサービス利用満足度の低下の抑制を図ることができる。

【0034】

（第１実施形態の変形例）
第１実施形態では、支援装置１は、支援対象のＳａａＳ３を利用する全てのＳａａＳ利用者７が優先処理依頼サービスを利用できる構成となっている。これに代えて、例えば、ＳａａＳ利用者７のうち、優先処理依頼サービスの利用を予め申し込んでいるＳａａＳ利用者７のみに支援装置１による優先処理依頼サービスが提供されてもよい。この場合には、例えば、支援装置１は、優先処理依頼サービスの利用を申し込んでいるＳａａＳ利用者７を表す情報（例えば、利用者識別情報）を記憶装置２０に保持する。また、支援装置１の通知部１２からＳａａＳ３に送信される要望受け付け可能通知には、優先処理依頼サービスの利用を申し込んでいるＳａａＳ利用者７の利用者識別情報が含まれることとする。その利用者識別情報を用いて、ＳａａＳ３は、システム復旧時における優先処理の要望を受け付けることを知らせる通知を優先処理依頼サービスの利用を予め申し込んでいるＳａａＳ利用者７だけに送信する。

【0035】

＜第２実施形態＞
以下に、本発明に係る第２実施形態を説明する。なお、第２実施形態の説明において、第１実施形態のクラウドサービス支援装置（支援装置）を構成する構成部分と同一名称部分には同一符号を付し、その共通部分の重複説明は省略する。

【0036】

図４は、第２実施形態のクラウドサービス支援装置（支援装置）１の構成を説明する図である。第２実施形態の支援装置１は、第１実施形態の構成に加えて、算出部１６が備えられている。算出部１６は、優先処理依頼サービスの利用に係る料金を算出する。

【0037】

すなわち、優先処理依頼サービスがＳａａＳ利用者７に提供されるに際し、ＳａａＳ３がＳａａＳ利用者７からサービス利用の料金を課す場合がある。その料金プランに関しては、ＳａａＳ３のそれぞれがその内容およびプラン数を適宜に設定してよいものであるが、第２実施形態では、支援対象のＳａａＳ３の少なくとも一つが設定した料金プランが従量制を採用している場合を想定している。その従量制の料金プランとは、優先処理依頼サービスを利用して優先処理を依頼（要望）した優先処理タスクの数に応じて課金額が決まるという料金プランであり、ここでは、従量制の種類として、定額従量制、従量課金上限制、逓減課金方式なども含まれるものとする。

【0038】

算出部１６は、そのような従量制の料金プランを設定しているＳａａＳ３に代わって、ＳａａＳ利用者７に課す優先処理依頼サービスの利用料金を算出する。すなわち、支援装置１には、優先処理依頼サービスの利用料金を算出する料金算出用の料金表情報が予め記憶装置２０に登録される。料金表情報は、優先処理依頼サービスの利用に係る料金の算出を代行するＳａａＳ３により設定された料金プランの情報である。算出部１６が料金の算出を代行するＳａａＳ３の数は限定されないが、複数であることが想定される。また、一つのＳａａＳ３が複数の料金プランを設定することも想定される。このようなことを考慮して、料金表情報には、当該情報（料金プラン）を識別する料金プラン識別情報と、当該料金プランに対応するＳａａＳ３を識別するシステム識別情報とが関連付けられている。さらに、記憶装置２０には、優先処理依頼サービスを利用するＳａａＳ利用者７を識別する利用者識別情報が登録され、この利用者識別情報には、そのＳａａＳ利用者７に対応する優先処理依頼サービスの料金プランを表す料金プラン識別情報およびＳａａＳ３のシステム識別情報が関連付けられている。

【0039】

算出部１６は、優先処理依頼サービスを利用するＳａａＳ利用者７ごとに、優先処理依頼サービスの利用料金を次のように算出する。例えば、第２実施形態では、ＳａａＳ３から支援装置１に送信される要望情報には、優先処理の要望元（依頼元）を表すＳａａＳ利用者７の利用者識別情報が含まれている。算出部１６は、支援装置１が受信した要望情報に含まれている利用者識別情報を用いて、ＳａａＳ利用者７ごとに、予め定められた料金算出単位期間（例えば月単位）における優先処理依頼サービスを利用した優先処理タスクの数をカウントする。

【0040】

そして、算出部１６は、予め定められたタイミング（例えば、毎月１０日などの設定されたタイミング）でもって、料金算出対象のＳａａＳ利用者７の利用者識別情報に関連付けられている料金表情報を記憶装置２０から読み出す。さらに、算出部１６は、料金算出対象のＳａａＳ利用者７における料金算出単位期間でのサービス利用のタスクのカウント数と、読み出した料金表情報とを用いて、その料金算出単位期間での料金算出対象のＳａａＳ利用者７における優先処理依頼サービスの利用料金を算出する。

【0041】

然る後に、算出部１６は、算出した優先処理依頼サービスの利用料金を、ＳａａＳ利用者７が利用しているＳａａＳ３に向けて出力する。

【0042】

第２実施形態における支援装置１の上述した構成以外の構成は、第１実施形態の支援装置１と同様である。

【0043】

第２実施形態の支援装置１は、第１実施形態と同様の構成を備えていることから、第１実施形態の支援装置１と同様の効果を奏することができる。その上、第２実施形態の支援装置１は、上述したように、算出部１６を備えているので、算出部１６による効果をも奏することができる。つまり、算出部１６は、ＳａａＳ３に代わって、ＳａａＳ利用者７に課す優先処理依頼サービスの利用料金を算出し、算出結果をＳａａＳ３に提供する。これにより、ＳａａＳ３は、優先処理依頼サービスの利用料金を算出するという新たな処理が増加することなく、優先処理依頼サービスを新規に導入することができる。このことにより、支援装置１は、優先処理依頼サービスをＳａａＳ３が導入しやすくなるという効果を奏することができる。

【0044】

＜第３実施形態＞
以下に、本発明に係る第３実施形態を説明する。なお、第３実施形態の説明において、第１や第２の実施形態の支援装置１の構成部分と同一名称部分には同一符号を付し、その共通部分の重複説明は省略する。

【0045】

図５は、第３実施形態のクラウドサービス支援装置（支援装置）１の構成を説明する図である。第３実施形態の支援装置１は、第１又は第２の実施形態の構成に加えて、代行回答部１７が備えられている。代行回答部１７は、支援対象のＳａａＳ３がサービスを提供できない状態になった場合に、当該ＳａａＳ３に寄せられる問合せを受け付け、当該問合せにＳａａＳ３に代わって回答する。

【0046】

すなわち、第３実施形態の支援装置１は、支援対象のＳａａＳ３から当該ＳａａＳ３の稼働状況を表す稼働状況情報を取得する。代行回答部１７は、稼働状況情報を用いてサービスを提供できない状態に陥った支援対象のＳａａＳ３を検知した場合に、そのＳａａＳ３を回答代行サービス対象として認識する。そして、代行回答部１７は、回答代行サービス対象のＳａａＳ３へのＳａａＳ利用者７からの問合せを、当該ＳａａＳ３を介して受け付ける。さらに、代行回答部１７は、その問合せに対する回答を生成し、当該回答を問合せ元のＳａａＳ利用者７に返信する。その問合せに対する回答は、例えば、チャットポットの技術（換言すれば、ＡＩ（Artificial Intelligence）の技術）が用いられて生成される。

【0047】

第３実施形態の支援装置１は、第１又は第２の実施形態の支援装置１と同様の構成を備えているので、第１又は第２の実施形態の支援装置１と同様の効果を奏することができる。その上、第３実施形態の支援装置１は代行回答部１７を備えている。このため、第３実施形態の支援装置１は次のような効果を奏することができる。すなわち、サービスを提供できなくなった障害がＳａａＳ３に発生した場合に、ＳａａＳ３にあっては、迅速な復旧のために、その障害の原因究明および復旧処理に人的リソースを当てたいところである。一方、ＳａａＳ３がサービスを提供できなくなった場合には、ＳａａＳ利用者７からサービスを利用できないことに因る問合せが増加する傾向にある。ＳａａＳ３では、サービス利用満足度の低下が考慮されて、障害対応だけでなくＳａａＳ利用者７からの問合せにも対応する。つまり、ＳａａＳ３では、限られた人的リソースを障害対応に割り当てて迅速な復旧を図りたいのにも拘わらず、問合せ対応にも人的リソースを振り分けなければならない。これにより、障害対応の人的リソースが削減し、復旧に係る作業の進捗具合が鈍ってしまうという状況が生じてしまう。

【0048】

これに対して、第３実施形態の支援装置１は、障害発生のＳａａＳ３に代わって当該ＳａａＳ３への問合せに回答するという代行回答サービスを提供する構成（機能）を備える。このため、代行回答サービスを受けるＳａａＳ３は、障害発生に因り増加すると想定される問合せに対応しなくて済むこととなり、問合せ対応を考慮することなく、障害対応に人的リソースを充てることができる。これにより、ＳａａＳ３では、障害の原因究明および復旧処理に注力することができ、迅速な復旧が図られる。すなわち、第３実施形態の支援装置１は、代行回答部１７によって、障害発生のＳａａＳ３に対する問合せ対応に起因したＳａａＳ利用者７のサービス利用満足度の低下を抑制しつつ、ＳａａＳ３に復旧作業に注力させることができるという効果を奏することができる。

【0049】

（第３実施形態の変形例）
支援装置１は、代行回答部１７に加えて、さらに、図５の鎖線で示されるような生成部１８が備えられていてもよい。生成部１８は、代行回答部１７が受けた問合せの内容を分析し、この分析結果を用いて、よくある質問とその回答をまとめたＦＡＱ（Frequently Asked Questions）を生成する。生成部１８により生成されたＦＡＱの情報は、支援対象のＳａａＳ３に向けて出力される。そのＦＡＱの情報を受信したＳａａＳ３にあっては、例えば、当該ＳａａＳ３が管理しているウェブサイトにそのＦＡＱを公開する。これにより、ＳａａＳ利用者７からＳａａＳ３への問合せの減少を図ることができる。

【0050】

また、生成部１８は、代行回答部１７が受けた問合せから取得できる情報を用いてＦＡＱ以外の情報を生成してもよい。例えば、生成部１８は、代行回答部１７が受けた問合せに含まれる単語を集計し、直近の所定期間（例えば１時間）における問合せに含まれる単語の増加傾向が急な順からのランキングの情報を生成する。このように生成部１８により生成された情報は、支援対象のＳａａＳ３に提供される。

【0051】

さらに、支援装置１の運用者が代行回答サービスの利用料金をＳａａＳ３に課す場合が考えられる。この場合に、その利用料金の料金プランが、代行回答した問合せの数（換言すれば、処理数）に応じた料金が課される従量制の料金プランである場合が考えられる。このような場合には、支援装置１は、図５の鎖線で示されるような計算部１９が備えられる。計算部１９は、代行回答サービスを利用するＳａａＳ３における代行回答サービスの利用料金を算出する。すなわち、代行回答サービスの利用料金に関する代行回答サービス用の料金表情報が記憶装置２０に予め登録される。また、代行回答サービス用の複数の料金プランが設定されている場合には、それぞれの料金プランに対応する料金表情報が記憶装置２０に予め登録される。複数の料金表情報にはそれぞれ料金表識別情報が関連付けられている。また、代行回答サービスを利用するＳａａＳ３がまとめられた代行回答サービス利用者情報が記憶装置２０に予め登録されている。この代行回答サービス利用者情報には、代行回答サービスを利用するＳａａＳ３のシステム識別情報が含まれ、また、このシステム識別情報には、当該システム識別情報のＳａａＳ３に対応する料金プランの料金表識別情報が関連付けられている。

【0052】

計算部１９は、代行回答部１７が機能（動作）した場合に、代行回答サービスを提供したＳａａＳ３ごとに、予め定められた料金計算単位期間（例えば月単位）における問合せの処理数をカウントする。そして、計算部１９は、予め定められたタイミングでもって（例えば、毎月１日に）、料金計算対象のＳａａＳ３のシステム識別情報に関連付けられている料金表情報を記憶装置２０から読み出す。さらに、計算部１９は、料金計算対象のＳａａＳ３における料金計算単位期間での問合せの処理数と、読み出した料金表情報とを用いて、その料金計算単位期間での料金計算対象のＳａａＳ３における代行回答サービスの利用料金を計算する。さらに、計算部１９は、計算した代行回答サービスの利用料金をＳａａＳ３に向けて出力する。

【0053】

なお、代行回答部１７に代えて問合せ受付部（図示せず）が支援装置１に設けられていてもよい。問合せ受付部は、障害が発生したＳａａＳ３に寄せられる問合せを受け付け、支援装置１に接続されている例えば表示装置（図示せず）に、受け付けた問合せの内容を表示させる。この場合、表示装置に表示された問合せに対して代行回答者がＳａａＳ３に代わってＳａａＳ利用者７に回答する。代行回答部１７に代えて問合せ受付部が設けられている場合であっても、計算部１９により代行回答サービスの利用料金が計算されてもよい。

【0054】

図６は、本発明に係るその他の実施形態のクラウドサービス支援装置（支援装置）の構成を説明するブロック図である。この支援装置３０は、例えばコンピュータ装置であり、コンピュータが予め与えられたコンピュータプログラムを実行することにより実現する機能部として、通知部３１と、受付部３２と、出力部３３とを備えている。支援装置３０は、支援対象のＳａａＳ（Software as a Service）３５と、連携システム３６とのそれぞれに接続している。ＳａａＳ３５は、クラウドサービスを提供しているシステムである。連携システム３６は、支援対象のＳａａＳ３５と連携しているシステムである。

【0055】

支援装置３０の通知部３１は、連携システム３６に障害が発生している場合に、連携システム３６の障害発生を支援対象のＳａａＳ３５に通知する。受付部３２は、支援対象のＳａａＳ３５を利用しているＳａａＳ利用者からＳａａＳ３５を介して連携システム３６に出力された処理対象であるタスクについて障害発生の連携システム３６の復旧時におけるタスクの優先処理に関する要望情報をＳａａＳ利用者から受け付ける。出力部３３は、受け付けた要望情報を含む優先処理依頼情報を優先処理依頼先の連携システム３６に出力する。

【0056】

優先処理依頼情報を受けた連携システム３６は、優先処理依頼情報に含まれている要望情報を参照し、システム復旧時において、優先処理が要望（依頼）されたタスクの処理順が優先処理の依頼の無いタスクよりも優先的に処理されるようにタスクの処理順を制御する。

【0057】

図７は、支援装置３０における優先処理依頼サービスに係る動作の一例を説明するフローチャートである。このフローチャートを参照しながら、支援装置３０における優先処理依頼サービスに係る動作の一例を説明する。例えば、通知部３１は、連携システム３６に障害が発生している場合に、連携システム３６の障害発生を支援対象のＳａａＳ３５に通知する（ステップ２０１）。然る後に、ＳａａＳ利用者からの要望情報が支援装置３０に送信されてきた場合には、受付部３２が、その要望情報を受け付ける（ステップ２０２）。要望情報とは、ＳａａＳ利用者から支援対象のＳａａＳ３５を介して連携システム３６に出力されたタスクについて、障害発生の連携システム３６が復旧した際に、タスクの優先処理を依頼する要望を含む情報である。さらに、支援装置３０の出力部３３は、受け付けた要望情報を含む優先処理依頼情報を優先処理依頼先の連携システム３６に出力する（ステップ２０３）。

【0058】

このような構成および動作を実行する支援装置３０は、連携システム３６の障害発生に起因したＳａａＳ３５に対するＳａａＳ利用者のサービス利用満足度の低下の抑制を図るサービスを支援対象のＳａａＳ３５に提供できる。

【符号の説明】

【0059】

１，３０ 支援装置
３，３５ ＳａａＳ
５，３６ 連携システム
７ ＳａａＳ利用者
１２，３１ 通知部
１３，３２ 受付部
１４，３３ 出力部
１６ 算出部
１７ 代行回答部
１８ 生成部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】