"複数のノードを経由し、前記複数のノードいずれかで変換が必要なメッセージが存在するメッセージの配信を制御するメッセージ配信制御装置であって、ノードの動作状況について、複数のレベルに分けた指標を示す診断ルールIDと対応付けて記憶する手段と、前記診断ルールID毎に、前記複数のノードそれぞれが記憶しており、前記変換の要否を含むメッセージの中継方法を示すメッセージ中継ポリシーを更新する為の制御内容を記憶する手段と、前記複数のノードそれぞれから当該ノードの動作状況を示す監視情報を取得する手段と、前記取得した監視情報に対応する診断ルールIDを特定する手段と、前記特定された診断ルールIDに対応する制御内容に基づいて、前記複数のノードのうち少なくとも一部のノードに対して、メッセージ中継ポリシーの更新要求を生成し、生成された更新要求を前記複数のノードの少なくとも一部に送信する手段とを有するメッセージ配信制御装置。請求項1に記載のメッセージ配信制御装置において、前記送信する手段が、前記複数のノードそれぞれに対して、当該ノードにおける診断ルールIDに対応する中継ポリシーを送信することで、前記複数のノードそれぞれが記憶している中継ポリシーに対して、送信された中継ポリシーを上書きすることで前記更新を可能にすることを特徴とするメッセージ配信制御装置。請求項1または請求項2いずれかに記載のメッセージ配信制御装置であって、前記記憶する手段はオペレータ通知要否のフラグを更に記憶し、前記オペレータ通知要否のフラグが要の場合、前記特定された診断ルールIDに基づいて処理するかどうかオペレータの承認要否を判断し、必要に応じてオペレータ端末に対して、判断要求をアラート発信する手段を有することを特徴とするメッセージ配信制御装置。複数のノードを経由し、前記複数のノードいずれかで変換が必要なメッセージが存在するメッセージの配信を制御するメッセージ配信制御方法であって、ノードの動作状況について、複数のレベルに分けた指標を示す診断ルールIDと対応付けて記憶し、前記診断ルールID毎に、前記複数のノードそれぞれが記憶しており、前記変換の要否を含むメッセージの中継方法を示すメッセージ中継ポリシーを更新する為の制御内容を記憶し、前記複数のノードそれぞれから当該ノードの動作状況を示す監視情報を取得し、前記取得した監視情報に対応する診断ルールIDを特定し、前記特定された診断ルールIDに対応する制御内容に基づいて、前記複数のノードのうち少なくとも一部のノードに対して、メッセージ中継ポリシーの更新要求を生成し、生成された更新要求を前記複数のノードの少なくとも一部に送信するステップとを有するメッセージ配信制御方法。請求項4に記載のメッセージ配信制御方法において、前記送信するステップが、前記複数のノードそれぞれに対して、当該ノードにおける診断ルールIDに対応する中継ポリシーを送信することで、前記複数のノードそれぞれが記憶している中継ポリシーに対して、送信された中継ポリシーを上書きすることで前記更新を可能にすることを特徴とするメッセージ配信制御方法。特許文献1は、メールを送信途中のメールサーバにて、電子メールを変換して送信する技術について開示されている。しかしながら、特許文献1では、予めメッセージを変換する装置がメールサーバと、特定されている。このために、変換する装置での変換処理ないし変換処理が必要なメッセージの配信数が多い場合やこの変換する装置で他の情報処理を行っており負荷が掛かっている場合、その装置での変換負荷が増大ないし負荷集中してしまうとの問題が生じる。その中でも、複数の受信装置にメッセージを送信する場合、変換負荷の増加により、このような装置を経由してメッセージが送信される受信装置において、当該メッセージの受信が他の受信装置より遅くなるとの問題が生じる。さらに、以下のようなマルチキャストの場合、この問題が特に顕著になる。例えば、複数の証券市場に上場している企業が複数の証券市場に会社情報等をマルチキャストで複数のノードを経由して送信する場合、上場企業は、株価等に影響する会社情報を適時適切に公開することが義務付けられており、複数市場に上場している場合は、市場間での不公平が生じないように、複数の上場市場に対して、同一情報をできるだけ等しいタイミングで配信する必要があるが、変換負荷の増加によりタイミングがずれることが生じる。例えば株価情報を送信装置から受信装置へ中継ノードA、中継ノードBを経由して送信するケースを考える。送信装置から送信されるメッセージと受信装置で受信できるメッセージが異なる場合、送信装置、中継ノードA、Bのいずれかでメッセージ変換が必要となる。仮に中継ノードAでメッセージ変換を行う場合に、中継ノードAの負荷が高いとメッセージの転送に遅延が発生する。特に送信装置が他の中継ノードにもメッセージを配信している場合には、中継ノードAを経由しメッセージを受信する受信装置は、中継ノードAを経由しない受信装置よりもメッセージを受け取る遅延が大きくなる。もし中継ノードBでメッセージ変換が可能でありかつその負荷が低ければ、メッセージ変換を中継ノードBに割り当てた方が、受信装置のメッセージ受信の遅延を小さく抑えることができる。ここで、この配信されるメッセージについて、扱えるメッセージがそれぞれの受信装置で異なる、例えば、ある受信装置はテキスト形式は扱えるがバイナリ形式が扱えない、他の装置はいずれも扱えることがある。また、各受信装置で扱えるメッセージと扱えないメッセージ、例えば、各受信装置がテキスト形式は扱えるがバイナリ形式は扱えない場合に、送信装置がバイナリ形式とテキスト形式の両方を送信することがある。これらの場合、受信装置によって、複数のノードのいずれかでバイナリ形式からテキスト形式に変換されたメッセージを受け取る必要がある受信装置があれば、バイナリ形式のまま、受け取ることも可能な装置もある。この場合、バイナリ形式で受ける受信装置と、テキスト形式で受ける受信者で受け取る時差が大きくなってしまうという課題が顕著になる。このように、特に、金融業界、例えば、証券の売買注文の判断に直結する情報などは、相手への着信が数秒遅れるだけで、多大な収益/損害に直結するケースにおいては、受信装置にできるだけ時差を少なくしてメッセージを届ける必要がある。そこで、本発明の目的は、メッセージの変換処理が必要な複数のノードを経由するメッセージ送信において、各ノードの状況に応じてより高負荷のノードでの変換処理を避けるように制御可能なメッセージ配信を実現することにある。本発明は、変換処理が必要なメッセージが配信対象のメッセージに含まれる場合、当該変換を実行する装置を、ネットワークに存在するノードの中から特定ないし変更するものである。例えば、マーケット情報の配信など複数のノードを経由するメッセージ配信において,変換の必要のあるメッセージを混在して送信する場合に関するものである。まず、各ノードでのリソースの使用状況等のステータスを診断し、その診断結果に基づき、各ノード毎のメッセージ中継方法を定義しているメッセージの変換を行うかどうかを決定する情報を含むメッセージ中継ポリシーを、動的に変更することで、高負荷であるノードで変換作業が行われることを避けることができる。本発明によれば、メッセージの配信において、より適切な変換装置を特定することでネットワーク全体の送信効率が落ちることを防止する効果がある。以下、図1~図17を用いて、マーケット情報の配信など、マルチキャストの場面において、性能特性の異なる複数のメッセージが混在する場合において、各ノードの変換性能,空きリソース,各メッセージにおけるメッセージの種類,ネットワーク負荷等を考慮して,伝送に用いるメッセージや変換ノードを動的に制御するものを一例として、実施例を説明する。ここでいう、性能特性とは、メッセージの圧縮率変換効率が異なることを指している。一般に、圧縮率が高くサイズが小さいメッセージは伝送効率は優れるが、メッセージ変換の処理効率は低下する。これらはトレードオフの関係にあり、通信インフラの状況や各ノードのメッセージフォーマットの対応状況に応じ使い分ける。なお、本実施例はマルチキャストの場合についてのものだが、これに限定されるものではない。図1は、マルチキャストメッセージ配信制御システムの全体像である。マーケット情報等の送信元となる業務システムA1000と、マーケット情報等を受信する業務システムBCD2000はマルチキャスト通信ネットワーク3000にて接続されており、マルチキャスト通信ネットワーク3000は、メッセージの伝送経路の制御やメッセージの変換を行うメッセージ中継ノード3100から構成される。これらの個々の中継ノード3100の状態を監視して、通信ネットワークを制御するマルチキャストメッセージ配信制御システム4000は、個々の中継ノード3100の状態を監視するネットワーク監視部4100、監視結果から各中継ノード3100の制御要否を判断するネットワーク診断部4200、診断結果にもとづき、各中継ノード3100に対して制御指令を伝達するネットワーク制御部4300から構成され、マルチキャストメッセージ配信制御システム4000は、ネットワーク運用管理端末5000と接続される。次に、マルチキャストメッセージ配信制御システム4000の中核機能である、ネットワーク監視部4100、ネットワーク診断部4200、ネットワーク制御部4300の機能概要を説明する。なお、これらの各構成要件は、コンピュータプログラムで構成することがより好適である。つまり、メッセージ配信制御システムの有するCPUの如き演算装置がコンピュータプログラムに従って後述する各処理を実行する。また、他の装置での処理も同様にコンピュータプログラムに従って実行されることがより好適である。ネットワーク監視部4100は、監視対象であるマルチキャスト通信ネットワーク3000を構成する各中継ノード群とそれぞれ双方向通信を行い、監視対象の中継ノード3100の状態値を監視する。さらに、状態値から何らかの問題を検出した場合にはネットワーク診断部4200に対して検出した問題点の診断を要求する。図2は、ネットワーク監視部4100の構成である。ネットワーク監視部4100は、マルチキャスト通信ネットワーク3000を構成する各中継ノード3100との通信を制御する対ネットワーク通信制御部4110、ネットワーク診断部4200との通信を制御する対ネットワーク診断部通信制御部4120、システム運用管理端末との通信を制御する対システム運用管理端末通信制御部4130、ネットワーク監視条件テーブル4140とネットワーク監視履歴テーブル4150、各中継ノード3100のMACアドレス、IPアドレス、性能機能情報などの静的プロファイル情報を管理するネットワークプロファイル管理テーブル4160と連携して、個々の中継ノード3100の状態を監視管理するネットワーク監視処理4170から構成される。なお、オペレータは、システム運用管理端末を介して、各中継ノード3100の監視条件を修正できる。続いて、ネットワーク監視部4100の処理概要を説明する。図3は、ネットワーク監視部4100の処理フローである。まず、ステップ100にて、ネットワーク監視部4100はネットワーク監視条件テーブル4150を参照して監視対象ノードと監視方法を決定し、ステップ110にて監視要求メッセージを監視対象の中継ノード3100に送信する。図4は、ネットワークプロファイル管理テーブル4140の構成である。ネットワークプロファイル管理テーブル4140は、各メッセージ中継ノード3100の静的属性情報を管理するテーブルであり、MACアドレス、IPアドレス、ハードウェア仕様、ソフトウェア仕様、接続ノードID、稼動開始日等の情報を管理する。図5は、ネットワーク監視条件管理テーブル4150の構成である。ネットワーク監視条件4150は、中継ノード3100毎に定義され、条件項目としては監視要否を設定する監視要否フラグ、緊急通常など監視の重要度、すなわち、監視の厳しさ頻度ないし優先度合いを示す複数のレベルを定義する監視モード、監視モード毎の監視時隔を設定する監視時隔、次回監視予定時刻、監視方法、診断の要否判断の指標を設定する判断基準等を定義する。なお、本実施例においては、監視条件テーブルに設定された次回監視予定時刻に従って監視対象の中継ノード3100を決定しているが、全ての中継ノード3100に対して定期的に一斉監視を行う方法や、周期的に監視対象をローテーションする方法をとってもよい。次に、中継ノード3100ではステップ120にて監視要求メッセージを受信する。監視要求メッセージは、ノードIDおよびノードIDを検索キーとしてネットワーク監視条件管理テーブル4150から取得可能な情報から構成される。次に、メッセージ中継ノード3100では、ステップ130にて自ノード3100と自ノード3100に接続される近接ノード3100のステータス情報を取得し、ステップ140にて図8の監視ID毎に設定される情報メッセージ変換効率などであるステータス情報をネットワーク監視処理に送信する。図6は、メッセージ中継ノード3100の基本構成である。メッセージ中継ノード3100は、ネットワーク監視部4100との通信を制御する対ネットワーク監視部通信制御部3110、ネットワーク制御部4300との通信を制御する対ネットワーク制御部通信制御部3120、自中継ノード3100と接続される他の中継ノード3100との通信を制御する対中継ノード通信制御部3130、中継ノードステータス管理テーブル3140とメッセージ中継ポリシー3190と連携し、他の中継ノード3100とのメッセージ送受信処理を行う送受信処理3160、受信したメッセージに対して、必要に応じてメッセージの変換を行う中継処理3170、受信したメッセージの中継ポリシーを管理する中継ポリシー管理処理3180、自ノードおよび自ノードに接続される周辺ノードの状態を管理するステータス管理処理3170から構成される。このメッセージ中継ノード3100はノードを意味しており、ノードの種類を特定するものではない。図7は、ノードステータス管理テーブル3180の構成である。ノードステータス管理テーブル3180は、個々の中継ノード3100、および中継ノード3100に直接接続される上流ノード、下流ノードの動的な通信属性の状態値を管理するテーブルであり、送受信キューの余裕度、CPU負荷、メモリ使用量などが属性値として管理される。なお、メッセージ中継ポリシー管理テーブル3190の構成については後述する。続いて、ネットワーク監視部4100では、ステップ150でステータス情報を受信し、ステップ160にてネットワーク監視履歴管理テーブル4160を更新する。図8は、ネットワーク監視履歴管理テーブル4160の構成である。監視履歴は中継ノード3100毎かつ時系列に設定される監視ID毎に管理する。監視履歴としての管理情報としては、単位時間あたりのメッセージ変換量を示すメッセージ変換効率、受信して処理待ちの状態にある受信メッセージキューの状態を示す入力メッセージキュー、出力先ノードへの送信メッセージキューの状態を示す出力メッセージキュー、CPU使用率、メモリ使用等から構成される。次に、ネットワーク監視部4100は、ステップ170にてネットワーク監視履歴管理テーブル4160を参照し、監視対象ノードの診断要否を判断する。診断要否の具体的な方法に関しては、あらかじめ閾値を設定しておく方法や、システム運用管理端末にアラートを出してオペレータが判断するといった方法が考えられる。ステップ170で診断不要と判断された場合は、ステップ100に戻り、診断が必要と判断した場合にはステップ180にて監視履歴をもとに診断要求を作成し、これを対ネットワーク診断部通信制御部4120を介してネットワーク診断部4200に送信する。診断要求メッセージは、ノードID、監視IDおよびノードIDと監視IDを検索キーにネットワーク監視履歴管理テーブル4160を参照することで取得可能なメッセージ変換効率、CPU使用率、メモリ使用率などの属性情報から構成される。ネットワーク診断部4200は、ネットワーク監視部4100から受信した診断要求メッセージに対してあらかじめ定義されたネットワーク診断ルール図11の説明で後述するがステータス情報をレベル分けした指標により定義されるものを言うを適用することにより、ネットワークの制御要否と制御内容これは後述するネットワーク制御ルールで判別されるを判断する。また、制御内容については、必要に応じてオペレータ判断を加味することも可能である。図9は、ネットワーク診断部4200の構成である。ネットワーク診断部4200は、ネットワーク監視部4100との通信を制御する対ネットワーク監視部通信制御部4210、ネットワーク制御部4300との通信を制御する対ネットワーク制御部通信制御部4220、システム運用管理端末との通信を制御する対システム運用管理端末通信制御部4230、ネットワーク診断ルール4240、ネットワーク診断履歴4250と連携してメッセージ中継ノード3100の状態を診断するネットワーク診断処理4260から構成される。なお、オペレータは必要に応じて、システム運用管理端末からネットワーク診断ルール管理テーブル4240を修正することができる。続いて、ネットワーク診断部4200の処理概要を説明する。図10は、ネットワーク診断処理フローである。まず、ステップ200にてネットワーク監視部4100は診断要求メッセージをネットワーク診断処理に送信すると、ネットワーク診断部4200では、ステップ210にて診断要求を受信し、ステップ220にてネットワーク診断ルールを参照する。図11は、ネットワーク診断ルール管理テーブル4240の構成である。ネットワーク診断ルール管理テーブルノットワーク診断ルール4240は、メッセージ変換効率、CPU使用率、メモリ使用率等からなる監視情報をレベル分けした指標の組合せに応じて定義される。ここで、このレベルの定義としては、例えば、CPU使用率0~20までをレベル1、20~40までをレベル2、40~60までをレベル3、60~80までをレベル4、80~100までをレベル5というようにユーザが任意に設定することができる。そして、この診断ルールは、ルールID毎に、定義された各レベルについて、当該レベルに応じて中継ノード3100の中継ポリシー管理テーブル3190をどのように書き換えるかを定めるものである。また、ネットワーク診断ルール4240毎にオペレータ通知の要否を表すフラグを記憶してもよい。これにより、自動での制御のみならず、オペレータに通知してオペレータの判断を仰ぐように設定することも可能となる。ここで、メッセージ変換効率とは、例えばバイナリ形式のメッセージをテキスト形式のメッセージに変換する場合の速度等の、変換の処理能力を指すが、これは変換効率が依存するCPU等の処理速度を指標としてもよいし、データ変換のベンチマーク等の指標を使ってもよい。監視情報は各中継ノード3100の負荷を表す指標であり、CPU、メモリ等の情報に限定されるものではない。次に、ネットワーク診断部4200は、ステップ230にて、診断要求を診断ルールの監視情報が示す条件部と照合することにより、ネットワークの診断を実施する。診断要求で要求される情報は、各中継ノード3100の監視ID毎のメッセージ変換効率、CPU使用率、メモリ使用率等の情報が具体的な例として含まれ、各中継ノード3100の処理状況ないし負荷状況を示す監視情報である。照合の結果、適合するルールが存在した場合には、その監視情報に対応付いた診断ルールIDを特定する。更に、ネットワーク診断部4200は、ステップ240にて診断結果をネットワーク診断履歴管理テーブル4250に格納する。図12は、ネットワーク診断履歴管理テーブル4250の構成である。ネットワーク診断履歴管理テーブル4250は、診断ID毎に、監視情報と診断情報を管理する。次に、ネットワーク診断部4200は、ステップ250にて診断ルール4240のオペレータ通知要否を参照し、当該ルール適用にあたってのオペレータによる承認要否を判定する。ここでオペレータによる判断が不要と判断された場合は、ステップ280に至り、オペレータによる判断が必要と判定された場合は、ネットワーク診断部4200は、ステップ260にて対ネットワーク運用管理端末通信制御部4230を介してシステム運用管理端末に診断内容をアラート提示し、診断結果のオペレータによる承認を要求する。ネットワーク運用管理端末5000では、ステップ270にてオペレータによる判断内容をネットワーク診断処理に返す。次に、ネットワーク診断部4200は、ステップ280で、オペレータからの回答を受信、あるいはオペレータによる判断が不要な診断結果を受け取ると、診断結果とオペレータ判断を統合して制御要否を判定する。制御の要否については、例えば診断ルールID001~004は制御否、005~nは制御要のように、制御ルール毎に決めてもよいし、オペレータ判断の要否を見て決めてもよいし、その両方を考慮して決めてもよい。ここで制御が必要と判断された場合には、ステップ290にて制御要求メッセージ作成し、これを対ネットワーク制御部通信制御部を介してネットワーク制御処理に送信する。なお、制御要求メッセージは、どの中継ノード3100の制御であるかを特定する為のノードID、制御ルールIDから構成される。ネットワーク制御部4300は、ネットワーク診断部4200から受信した制御要求メッセージにもとづいて、制御対象の中継ノード3100にて管理される、つまりノードIDにより、中継ノード3100が特定され、特定された中継ノード3100に制御ルールIDで特定された制御内容で、メッセージ中継ポリシー3190が更新される。そのことにより、ネットワーク全体のマルチキャスト通信を制御する。ここで、制御IDとは、診断ルールIDが特定され、制御が必要と判断された場合に、各診断ルールIDに1対1に対応した制御ルールIDが割当てられ特定されるものである。その為、制御ルールIDではなく、診断ルールIDと制御内容を対応付けて管理して、診断ルールIDにより制御内容が特定されることとしてもよい。図13は、ネットワーク制御部4300の構成である。ネットワーク制御部4300は、各メッセージ中継ノード3100との通信を制御する対ネットワーク通信制御部4310、ネットワーク診断部4200との通信を制御する対ネットワーク診断部通信制御部4320、システム運用管理端末に対して制御内容を通知する対システム運用管理端末通信制御部4330、ネットワーク制御履歴4340とネットワーク制御ルール4350と連携してメッセージ中継ノード3100のメッセージ中継ポリシー3190を制御するネットワーク制御処理4360から構成される。続いて、ネットワーク制御部4300の処理概要を説明する。図14は、ネットワーク制御部4300の処理フローである。まず、ステップ300にてネットワーク診断部4200は制御要求メッセージをネットワーク制御部4300に送信すると、ネットワーク制御部4300では、ステップ310にて制御要求を受信し、ステップ320にて制御要求メッセージにもとづいて制御指令を生成し、ステップ330にて制御指令をメッセージ中継ノード3100に送信する。メッセージ中継ノード3100では、ステップ350にて、制御指令に応じてメッセージ中継ポリシー管理テーブル3190を修正し、修正内容を制御結果としてネットワーク制御部4300へ送信する。ここでいう制御指令とは、メッセージ中継ポリシー管理テーブル3190を書き換える為のコマンドでもよいし、後述のネットワーク制御ルールの制御ルールIDもしくは診断ルールIDで特定された、ポリシーIDとポリシーID毎に対応付けられた制御内容を含んだものであってもよい。また、各中継ノード3100それぞれに対して、当該ノードにおける制御ルールIDもしくは診断ルールIDに対応する中継ポリシーを送信することで、前記複数のノードそれぞれが記憶しているメッセージ中継ポリシー管理テーブル3190に対して、送信された中継ポリシーを上書きすることとしてもよい。図15は、ネットワーク制御ルール4340の構成図である。特定された診断ルールIDに1対1に対応する制御ルールID毎にメッセージ中継ポリシー管理テーブル3190のメッセージ中継方法を制御内容で書き換えるために定義するテーブルである。例えば制御ルールID001のポリシーID003の制御内容がメッセージ変換要否を要に変更となっていれば、制御ルールID001が指定された場合に、メッセージ中継ポリシー管理テーブル3190内のポリシーID003のメッセージ変換要否を要に書き換える。ここで、制御IDを介さず、診断ルールIDと各ポリシーID、メッセージ中継ポリシー管理テーブル3190のメッセージ中継方法を書き換える制御内容と対応づけてもよい。図16は、メッセージ中継ポリシー管理テーブル3190の構成である。メッセージ中継ポリシー管理テーブル3190は、各中継ノード3100毎に定義される、条件に応じたメッセージ中継方法を規定するテーブルであり、想定されるメッセージ中継条件のパターンに対して、メッセージ変換の要否、変換要の場合の具体的な変換方法等を規定する。次に、ネットワーク制御部4300では、ステップ370にて制御結果を受信し、ステップ380にて制御結果を制御履歴管理テーブル4340に格納する。このテーブルでいうメッセージ中継条件とは、中継ノード3100に送られてくるメッセージのメッセージ書式textやbinary等や、各メッセージで指定される業務要件遅延不可のメッセージか、遅延可能なメッセージかのフラグ、メッセージを受けた場合の中継ノード3100のリソース状態等の、メッセージの状態や、中継ノード3100のリソース状態等を表すものである。このメッセージ中継条件に対応したメッセージ中継方法を、様々なメッセージ中継条件の場合に対応させて記憶する。それにより、そのメッセージの状態や、リソース状況に応じて、どのようにメッセージの中継方法を適用するかを管理することができる。ここでいうメッセージ中継方法とは、メッセージを変換するかどうかを決めるメッセージ変換要否やその変換方法効率を優先するのか、時間を優先するのか等を決めている。このメッセージ中継方法は先に述べたように各中継ノード3100の状況に応じて、自動で更新される。図17は、ネットワーク制御履歴管理テーブル4340の構成である。ネットワーク制御履歴管理テーブル4340は、制御IDにて管理されており、制御ID毎に、制御対象ノードID、制御対象のポリシーID、メッセージ変換方法等の、メッセージ中継ポリシー3190が更新された内容はこのネットワーク制御履歴管理テーブル4340に書き込まれ管理される。"