JP6463572B1 - 対象システムの内部状態を推定する支援システム - Google Patents

Abstract

対象システムの内部状態を推定する支援システム（１０）であって、第１の検査データに基づいて、予め定められた少なくとも１つのルールにしたがって推定された第１の推定された状態を出力するように構成された推論モジュール（２２）と、第１の検査データおよび第１の推定された状態に基づき、対象システムの状態を推定することを学習するように構成された学習モジュール（２１０）を含み、第２の検査データに対して第２の推定された状態を出力するように構成されたＡＩモジュール（２１）と、推論モジュールにより推定された状態と、人工知能モジュールにより推定された状態との精度を検証するように構成された検証モジュール（２３）と、検証モジュールの検証結果により推論モジュールにより推定された状態とＡＩモジュールにより推定された状態との優先順位を切り替えて出力する判定モジュール（２８）とを含む支援システムを提供する。

Description

本発明は、対象システムの内部状態を推定する支援システムであって、人工知能モジュールを含む支援システムに関するものである。

日本国特開２０１７−９１５８６号公報には、健康管理対象者の食事や健康状態から適切なアドバイスメッセージを生成して、健康管理のカリキュラム実行のモチベーションを向上させることができる健康管理サーバを提供することが記載されている。この文献には、健康管理対象者が保有する端末とネットワークを介して接続された健康管理サーバであって、健康管理対象者が選択したカリキュラム情報を端末から受信する受信部と、健康管理対象者の行動パターンを記憶する記憶部と、カリキュラム情報に基づく行動が継続されている場合の継続パターンと、カリキュラム情報に基づく行動が停滞した場合の停滞パターンと、に分析する分析部と、将来予測される健康管理対象者の身体情報および容姿を推測する人工知能部と、身体情報および容姿を生成する生成部と、画像情報または文例情報として端末に送信する送信部とを備える。

人工知能を用いて、様々な対象物に関するデータに基づいて、対象物を解析、分析、検査し、対象物の状態を診断（診察、推定、探査、判断）し、対象物の将来を予測するシステムが提案されている。しかしながら、人工知能を用いて、実際の診断支援等に役に立つシステムを構築することは容易ではない。

本発明の一態様は、対象システムの内部状態を推定する支援システムであって、モジュールのセットを有する。モジュールのセットは、対象システムに関する第１の検査データに基づいて、予め定められた少なくとも１つのルールにしたがって推定された上記対象システムの第１の推定された状態を出力するように構成された推論モジュールと、第２の検査データに対して上記対象システムの第２の推定された状態を出力するように構成された人工知能モジュールと、推論モジュールにより推定された状態と、人工知能モジュールにより推定された状態との精度を検証するように構成された検証モジュールと、検証モジュールの検証結果により推論モジュールにより推定された状態と人工知能モジュールにより推定された状態との優先順位を切り替えて出力する判定モジュールとを含む。さらに、人工知能モジュールは、第１の検査データおよび第１の推定された状態に基づき、対象システムの状態を推定することを学習するように構成された学習モジュールを含む。対象システムは、人体であってもよく、エンジンなどのメカトロニクスであってもよく、金融・投資などのサービスであってもよく、ゲームであってもよい。

支援システムは、学習モジュールの学習初期においては、推論モジュールにより推定された状態を優先して当該支援システムの推定結果として出力し、学習モジュールの学習が進み人工知能モジュールにより推定された状態（推定結果）の精度が推論エンジンにより推定された状態（推定結果）の精度を上回ると、人工知能モジュールが推定した状態を当該支援システムの推定結果として優先して出力する。学習が進んだ学習モジュールを含む人工知能モジュールの推定結果を、所定のルールに基づいて推論モジュールにより推定された結果と比較することにより、一方の推定結果を他方の推定結果で検証することが可能となる。このため、推論モジュールに含まれるルールでは対応が難しいケースに対して、学習が進んだ学習モジュールを含む人工知能モジュールであれば内部状態を比較的高い精度で推定できるようになる可能性があり、その推定結果を推論モジュールの推定結果により検証できる。また、推論モジュールに含まれるルールの適用可能な範囲が限定的な場合であっても、人工知能モジュールの学習により推定可能な範囲を拡張できる可能性がある。

モジュールのセットは、さらに、学習モジュールの学習用として対象システムの検査データのレプリカを生成するように構成されたレプリカ生成モジュールを含んでもよい。学習モジュールの学習を大量のレプリカを処理させることで促進できる。モジュールのセットは、さらに、検証モジュールにより検証された、人工知能モジュールにより推定された状態の精度に基づいて、レプリカ生成モジュールに対しレプリカの最適化方針を提供するように構成された最適化モジュールを含んでもよい。人工知能モジュールにより推定された状態の精度が低い結果に対して学習を促進できる。また、実データが不足する現象に対しても、レプリカを量産することにより、学習モジュールの学習を促進させることができる。レプリカによる学習は、推論モジュールが関与する実データと同様に教師あり学習であってもよく、推論モジュールが関与しない教師なし学習であってもよく、検証モジュールで曖昧性などの精度を報酬とした強化学習であってもよい。

レプリカ生成モジュールは、対象システムの検査データに含まれる複数のパラメータの値の実分布を反映したレプリカを生成するモジュールを含んでもよい。実分布を反映した多量のレプリカを訓練データとして、学習モジュールが自動的に、対象システムの内部状態を示す特徴量を学習してもよい。レプリカ生成モジュールは、対象システムの内部状態を示す内部レプリカと、内部レプリカの変化範囲から逆に推定した検査データのレプリカを生成するモジュールを含んでもよい。学習モジュールは、内部レプリカをラベルとした検査データのレプリカにより教師付き学習をおこなってもよい。

モジュールのセットは、さらに、対象システムの検査データを予め定められたルールにより前処理して推論モジュールおよび人工知能モジュールに入力される検査データに変換するように構成された入力処理モジュールを含んでもよい。検査データを、所定のルールにしたがって事前に統計処理したり、相関処理したりすることにより、人工知能モジュールの推論をトレースしやすくしたり、推論根拠を推定しやすくできる可能性がある。入力処理モジュールは、一例として、検査データに含まれる各パラメータ同士の相関を示すマップを生成するモジュールを含んでもよい。複雑系のシステムでは、パラメータ同士の相関は膨大な数になる可能性があるが、２次元または３次元にマップ化することにより画像認識による学習の対象とすることが可能となる。

検証モジュールは、推論モジュールまたは人工知能モジュールにより推定された状態の曖昧性を判断するモジュールと、曖昧性により追加情報を外部から取得するモジュールとを含んでもよい。追加情報は、対象システムの診断専門家のフィードバック、経過観察、追加試験の結果の少なくともいずれかを含んでもよい。曖昧性の高い（曖昧な余地の大きな）推定結果の曖昧性を改善することが可能となり、推論モジュールの推定結果の曖昧性を改善したり、学習モジュールに対して曖昧性の少ない推定結果を用いて教育できる。

モジュールのセットは、さらに、判定モジュールにより選択された推定された状態を対象システムの診断情報として出力するモジュールを含んでもよい。診断情報の出力方法は、診断情報を受け取る側（ユーザー）に依存して変更してもよく、例えば、対象システムの診断情報をデジタルアバタの症状として表現してもよく、ユーザーのソーシャルタイプを予め分析して、そのソーシャルタイプが受け取りやすい、または親近感を覚える方法で出力してもよい。

支援システムは、モジュールのセットをプログラム（プログラム製品）として格納するメモリと、メモリに格納されたプログラムをロードして実行するプロセッサとを有していてもよい。

本発明の他の態様の１つは、上記に開示した少なくとも１つの支援システムと、対象システムの診断専門家の端末とがクラウドにより接続されており、少なくとも１つの支援システムの出力がクラウド（インターネット、その他のコンピュータネットワーク）を介して参照される、クラウドシステムである。支援システムと、対象システムの診断専門家の端末と、対象システムの経過観察が可能な機関とがクラウドにより接続されているシステムにおいては、検証モジュールが、クラウドを介して診断専門家のアドバイスまたは経過観察をオーダーしてもよい。

本発明の他の態様の１つは、コンピュータを上記の支援システムとして機能させる命令を有するプログラム（プログラム製品）である。プログラムは適当な記録媒体に記録して提供してもよい。

本発明の、さらに異なる他の態様の１つは、対象システムの内部状態を推定する支援システムの制御方法である。支援システムは、対象システムに関する第１の検査データに基づいて、予め定められた少なくとも１つのルールにしたがって推定された上記対象システムの第１の推定された状態を出力するように構成された推論モジュールと、第１の検査データおよび第１の推定された状態に基づき、上記対象システムの状態を推定することを学習するように構成された学習モジュールを含み、第２の検査データに対して上記対象システムの第２の推定された状態を出力するように構成された人工知能モジュールと、推論モジュールにより推定された状態と、人工知能モジュールにより推定された状態との精度を検証するように構成された検証モジュールとを含む。制御方法は、推論モジュールにより推定された状態を、人工知能モジュールにより推定された状態より優先して出力することと、人工知能モジュールにより推定された状態を、推論モジュールにより推定された状態より優先して出力することとを含む。

支援システムは、さらに、学習モジュールの学習用として対象システムの検査データのレプリカを生成するように構成されたレプリカ生成モジュールを含んでもよく、制御方法は、さらに、検証モジュールにより検証された、人工知能モジュールにより推定された状態の精度に基づいて、レプリカ生成モジュールに対し前記レプリカの最適化方針を提供することを含む。

診断支援システムの一例を示すブロック図。 相関処理モジュールの一例を示すブロック図。 ヒートマップの一例を示す図。 ヒートマップの一部を拡大して示す図。 ヒートマップの他の例を示す図。 ヒートマップのさらに異なる例を示す図。 複数のヒートマップを比較する図。 ヒートマップのさらに異なる例を示す図。 ベクトルマップの一例を示す図。 ヒートマップが状態とともに変化する様子を示す図。 相関が状態とともに変化する様子を示す図。 個別マトリクスの一例を示す図。 学習システムの一例を示すブロック図。 推論エンジンの一例を示すブロック図。 検証過程の一例を示すブロック図。 検証エンジンの一例を示すブロック図。 支援エンジンの制御過程の一例を示す図。 最終決定・判定モジュールの一例を示すブロック図。 出力処理モジュールの機能の一例を示すブロック図。 レプリカ生成モジュールの一例を示すブロック図。 クラウドサービスの一例を示すブロック図。 クラウドサービスの機能の一例を示すブロック図。 クラウドサービスの拡張の一例を示すブロック図。

発明の実施の形態

図１に、本発明に係る支援システムの一例を示している。この支援システム１０は、人（人体、人間）を診断の対象（対象物、対象システム）とした、診断支援システムの一例である。この支援システム（アクシオンシステム）１０は、学習モジュール２１０を含む人工知能（ＡＩ）エンジン（ＡＩモジュール）２１と、対象物である人間の診察者（診断者）である医者のエキスパートシステムとしての機能を含む推論エンジン（推論モジュール）２２と、対象システムに関する検査データである入力データ１１に対するＡＩエンジンと推論エンジン２２との推定結果に対して人工エンジン２１の学習モジュール２１０を教育するための教師データとしてレプリカ１３を生成する教育システム（学習システム）３０とを含むハイブリッドエンジン（診断支援エンジン、アクシオンエンジン、ＡＸｉＲエンジン）２０を含む。

支援システム１０は、各種データおよびプログラム（プログラム製品）１１５などを格納するメモリ１０１と、プログラム１１５として格納されたモジュールのセット１１０を実行するプロセッサ１０２とを含む。プログラム（プログラム製品）１１５は、メモリ１０１およびプロセッサ１０２を含むコンピュータ１０５を支援エンジン２０および支援システム１０として機能させるための複数の命令を含むものである。

支援エンジン２０は、プロセッサ１０２で実行可能な複数のモジュールの１つのセット１１０として提供される。以降の説明において、モジュールのセット１１０は、支援エンジン２０として説明される。プロセッサ１０２は、汎用型のプロセッサであってもよく、専用回路を備えたＡＳＩＣであってもよく、ＦＰＧＡあるいはＤＲＰなどの再構成型のプロセッサであってもよい。

１． システムの概要
この支援エンジン２０は、人体を、その内部状態を推定する対象システムとした診断支援エンジン２０である。診断支援エンジン２０は対象システムの人体に関する第１の検査データ（第１の入力データ）に基づいて、予め定められた少なくとも１つのルールにしたがって推定された対象システムの第１の推定された状態を出力するように構成された推論モジュール（推論エンジン）２２と、第１の検査データおよび第１の推定された状態に基づき、対象システムの状態を推定することを学習するように構成された学習モジュール２１０を含む人工知能モジュール（ＡＩモジュール、ＡＩエンジン）２１とを含む。ＡＩエンジン２１は、学習モジュール２１０の学習が進むと、第２の検査データに対して、推論エンジン２２が推定する状態とは異なる第２の推定された状態を出力するように構成されてもよい。診断支援エンジン２０は、さらに、推論エンジン２２により推定された状態と、ＡＩエンジン２０により推定された状態との精度を検証するように構成された検証モジュール（検証エンジン）２３と、検証エンジン２３の検証結果により推論エンジン２２により推定された状態とＡＩエンジン２１により推定された状態との優先順位を切り替えて出力する判定モジュール（最終判定・決定モジュール）２８とを含む。

支援エンジン２０は、さらに、学習モジュール２１０の学習用として対象システムの検査データ１１のレプリカ１３を生成するように構成されたレプリカ生成モジュール１９と、検証エンジン２３により検証された、ＡＩエンジン２０により推定された状態の精度に基づいて、レプリカ生成モジュール１９に対しレプリカ１３の最適化方針を提供するように構成された最適化モジュール（最適化エンジン）２４を含む。支援エンジン２０は、さらに、対象システムの検査データ１１を予め定められたルールにより前処理して推論モジュール２２および人工知能モジュール２１に入力される検査データに変換するように構成された入力処理モジュール２５を含む。支援エンジン２０は、さらに、判定モジュール２８により選択された推定された状態を対象システムの診断情報（出力データ）１２として出力するモジュール２９を含む。出力処理モジュール２９は、対象システムの診断情報をデジタルアバタの症状として表現して出力するアバタ処理モジュール２９１と、ユーザーのソーシャルタイプを予め分析して、そのソーシャルタイプが受け取りやすい、または親近感を覚える方法で出力するソーシャルタイプ解析モジュール２９２とを含んでいてもよい。

この支援エンジン２０においては、まず、ＡＩエンジン２１の学習モジュール２１０は、入力データ（検査データ）１１に対して推論エンジン２２に実装されている所定のルールにより解析あるいは推論された結果を教師データとして学習する。さらに、学習モジュール２１０は、検証エンジン２３と最適化エンジン２４からのフィードバックを受けて生成される入力レプリカ１３により教育され、診断精度の自動あるいは自律的な向上が実現される。次に、支援エンジン２０は、推論エンジン２２とＡＩエンジン２１の２つをハイブリッド実装しているので、ＡＩエンジン２１が教育された後に、医療エキスパートシステムである推論エンジン２２と、ＡＩエンジン２１との両方の視点から、非侵襲・侵襲の測定データを含む入力データ１１から人体内部要素の活性状態（健康度・不健康度・未病）や機能不全・不具合（疾病度合い）、劣化・腫瘍・癌化に関する推測・推定を行いアドバイスや参考となる健康情報や見落としがちな視点（可能性・危険性）を提供することができる。

すなわち、診断支援エンジン２０は、予測・推論精度を向上させる目的で、ＡＩエンジン２１の自己学習機能と検証エンジン２３と最適化エンジン２４の２つが機能してこれを支援する点が特徴となっている。特に、推論エンジン２２とＡＩエンジン２１は、ハイブリッド型として機能するが、また、ＡＩエンジン２１が連続して予測・推論精度が推論エンジン２２のそれを上回ると切り替わる点が特徴となっている。少ない入力データ量でも機能する様に、外部にレプリカ生成モジュール１９が存在しており、最適化エンジン２４の指示で、レプリカ生成のバリエーションが変化する構造となっている。

１．１ ＡＩエンジン概要
実装されるＡＩエンジン２１は、ディープラーニング（深層学習）を基本とするが、ＡＩエンジン２１は複数のタイプの異なる学習モジュール２１０を備えていてもよい。学習システム３０は、ＡＩエンジン２１の学習モジュール２１０を、少ない入力データ１１でも機能する様に（自律的に教育されるように）３つのエンジン、推論エンジン２２、検証エンジン２３、および最適化エンジン２４を使用し、ＡＩエンジン２１のサポートと自己学習機能の一部役割を果たしてＡＩエンジン２１の成長を支援する。また、学習システム３０の３つのエンジン２２〜２４は、診断支援エンジン２０およびＡＩエンジン２１の予測精度・推論精度を向上させる機能も担っている。すなわち、学習システム３０は、一種の精度向上のためのフィードバック回路の様な機能を担う。

学習システム３０により、段階的にＡＩエンジン２１は、推論エンジン２２の予測精度を超えることになる。ＡＩエンジン２１と推論エンジン２２との勝率は、検証エンジン２３およびその下流で最終判定を行う最終判定・決定モジュール２８が判断することなり、初期段階では、これらのエンジン２３およびモジュール２８は、推論エンジン２２の診断結果（推論、予測）を優先する。その後、例えば、ＡＩエンジン２１が３カ月間平均で８０％の勝率を超えたり、勝率９０％を連続して超えた場合は、検証エンジン２３および最終判定・決定モジュール２８はＡＩエンジン２１の診断結果を優先し、推論エンジン２２はバックアップ側に回り、その推論や予測は当面利用されない。しかしながら、検証エンジン２３および最適化エンジン２４は、ＡＩエンジン２１がメイン動作している場合でも機能は継続して支援する。

したがって、この診断支援エンジン２０の機能、性質、能力などは、学習システム３０に含まれる３つのエンジン、すなわち、推論エンジン２２、検証エンジン２３および最適化エンジン２４により左右される。これらのエンジン２２〜２４は、基本的にメタ・モデルという概念を基本とする。つまり、診断の対象物、例えば、人体の高精度の異常・故障の予測を必要とする複雑な系に対して、これを構成するシステム要素・構成部品が存在し、この要素・部品の機能がこれらの予測根拠となり、システムの入力と出力が定義可能であるようにする。診断の対象物の、好調・不調・障害・故障が、その程度は別として内部構成要素や部品の不具合から発生していると想定可能であり、その原因や問題点を測定データ・観測データから予測し、対応についてアドバイスを行い、必要とされる情報や期待される情報を提供するという事を想定して設計できる。

これらのエンジン２２、２３および２４の機能を記述するメタ・モデル記述ファイル１４により、診断支援エンジン２０の外部、すなわち、システム独自、またはクラウド上のメモリ１０１に可能な限り定義体や相関情報・入力情報・統計情報・評価情報をモデル記述しておいて、複数のシステムやアプリケーションに対して、この記述情報を変更する事で対応可能な構成としている。したがって、支援エンジン２０は、入力データ１１及びメタ・モデル記述ファイル１４が変更される事で、その役割や守備範囲・対応が違ったものとなる。また、同一のアプリケーション対象分野であっても、特化した入力データ１１とする事で、専門性・性格の異なる支援エンジン２０を作成（教育）する事が可能となる。以下では、ヘルスケア分野での健康度測定、乳癌や膵臓癌、腎臓癌、肺癌、胃癌、肝臓癌、大腸癌など違った分野の入力データ（検査データ）１１を前提としたメタ・モデル記述ファイル１４を前提として説明するが、本診断支援エンジン２０が適用できる分野はヘルスケアに限定されず、ガスタービンエンジン、ファクトリオートメーションなどの工業的分野、金融などの商業あるいはサービス分野、およびゲームなどの娯楽分野などであってもよい。

１．２ 推論エンジン概要
さらに具体的には、診断支援エンジン２０を形成する中心の１つである推論エンジン２２は、測定データ、問診データなどを含む検査に関する入力データ１１から推論して、診断対象である人体の内部状態の推定し、疾病やガンなどの異常の有無を推定する。推論エンジン２２は、医者などの医療関係者からの情報、過去の疾病に関する情報や経験などに基づき生成された１つまたは複数のルールを含むエキスパートシステムである。入力データ１１は、問診・血液・尿・統計・microRNA・遺伝などの複数の要素を含み、それに基づき推論される人体の状態を幾つかの候補をあげて絞り込む機能を含む。ＡＩエンジン２１の予測・推定精度が十分で無い場合は、当面、推論エンジン２２が主導で、診断支援エンジン２０における診断支援サービスを実行する。最終判定・決定モジュール２８は、ＡＩエンジン２１と推論エンジン２２との推定結果の優先のスイッチングのタイミングと判断とを、メタ・モデル記述ファイル１４に従って実行する。診断支援の中心がＡＩエンジン２１に切り替わった場合でも、バックグラウンドでは推論エンジン２２はその機能を継続して、ＡＩエンジン２１の推定結果と常に比較され、ＡＩエンジン２１の推定結果を常に検証する機能を果たす。

診断支援エンジン２０の推論エンジン２２は、診断対象の複雑なシステムの良・不良・不調・故障・破損と因果関係にある、または、直接関係する内部パーツと、それらの関係性・活性度・リカバリー機能・免疫力・調整メカニズム・劣化要因の推定根拠となる入力データ１１を利用して、診断対象のシステムの内部状態を推定する。診断対象の複雑なシステムの良・不良・不調・故障・破損と因果関係にある、または、直接関係する内部パーツ、および、それらの関係性・活性度・リカバリー機能・免疫力・調整メカニズム・劣化要因と、入力データ１１に含まれる各検査パラメータ、数値などのと相関は、メタ・モデル記述ファイル１４により与えられてもよい。推定エンジン２２に実装されるルールの１つは、入力データ１１から、診断対象物の内部レプリカを推定して１次予測とし、１次予測が、ある範囲で信頼可能とすれば、２次予測として、入力データを再推定するものであってもよい。この２次予測から、その先に懸念されるシステムの良・不良・不調・故障・破損（限界）の時期と被害を３次予測として推定してもよい。

診断支援エンジン２０の最終的な推論結果（診断情報）となる出力データ１２を決定する場合、入力データ（測定データ及び問診表などを含んでもよい）１１と、これから推定される内部状態（内部レプリカ）、更に、その内部レプリカのバリエーションからの再度生成された入力レプリカ、これと測定データとの差分値（分散値）の最小のものを有力な推論結果の候補として上げてもよい。

推論エンジン２２は、推定結果を、入力データ１１との相関性を記述した入出力相関テーブル／記述ファイル１５から推定するルールを含んでいてもよい。推定されうる状態の絞込みが難しい場合は、検証エンジン２３が判断し、追試を行って新しい入力データ１１および問診データを得ることで推定精度を向上するルールを設けてもよい。このルールを最適化エンジン２４に利用してもよく、予測・推定精度向上に貢献する。入出力相関テーブル／記述ファイル１５は、この精度向上を確実にする意味でも、定期的に見直しをして更新する必要がある。相関テーブル情報は、入力データや問診情報と人体の内部パーツ（臓器・血管・骨・脊髄・その他）との関係性を示すものを含むようにしてもよい。

１．３ 検証エンジン概要
検証エンジン２３は、推論エンジン２２またはＡＩエンジン２１の推定結果２３１に含まれる、推定された内部状態（内部レプリカ）に対して、メタ・モデル記述ファイル１４の評価式（アルゴリズムや式・最小二乗法その他）にしたがって、予測あるいは推定された状態の精度を検証してもよい。内部レプリカから再生成される入力再生成レプリカを対象として、推定結果の精度を検証してもよい。推定結果２３１の精度が不足し、曖昧さが大きな場合は、検証エンジン２３は、メディカルドクター（ＭＤ）や追試の検査、２週間単位での継続検査を要求する検証結果を示してもよい。さらに、判定で曖昧さが残り、断定できない、あるいは絞り込みが不足する場合、検証エンジン２３は、推定結果に対し、継続検査（検証）フラグを立て経過監査を継続する検証結果を示してもよい。すなわち、検証エンジン２３は、ＡＩエンジン２１および／または推論エンジン２２の推定結果２３１の評価が、その時点では確定できないと判断すると、それらの推定結果２３１を、タイムライン（タイムカプセル）にポストし、検証を、時間が経過した後に行えるようにする機能（経過観察機能）を含んでもよい。これらのオプションは、メタ・モデル記述ファイル１４に含めてもよい。

検証エンジン２３は、ＡＩエンジン２１および／または推論エンジン２２の推定結果２３１の評価のために、入力データ１１が不足していると判断すると、さらなる情報の入手を試みる機能を含んでもよい。例えば、入力データ１１として、健康度を決定する為の測定データは、血液検査、尿検査、呼気・皮膚ガス測定、体温・内臓脂肪・皮下脂肪・筋肉量・体脂肪率・推定骨量・血圧・血流・心拍数・自律神経興奮度等の測定値と画像診断結果、microRNA・ncRNA・DNAの各情報が想定されるがこれらに限定されない。これらの情報と問診票による情報とが、検査データとして入力データ１１に含まれてもよい。検証エンジン２３は、追加のテストを提案する機能を含んでもよく、例えば、ＡＩエンジン２１および／または推論エンジン２２の推定結果２３１から想定される疾病候補とリンクされ、候補となる疾病の可能性を確認するための追試をオーダーする機能を含んでもよい。その際に、メディカルドクターの提案を受け入れ、それを優先する機能を含んでもよい。検証のための追加測定項目については、順次追加する方式を採用してもよい。

検証エンジン２３は、これらの追試が何らかの事情で即時実施が難しかったり、追加の測定の即時実施が難しい場合は、タイムカプセルにポストし、ペンディングとして数ヶ月、半年、１年間、経過後、再度測定をしてその差分から、疑問の残る予測・推論については戻した形でのフィードバックを実行する機能を含んでもよい。この機能は経過観察機能の一部に含むことが可能であり、経過観察を続ける必要がある場合、例えば、２週間単位で精密検査を行い、これを数回実施して、その差分から健康体へと向かっているのか、病体側へと悪化しているのかを微分係数的に観察するという手法を採用してもよい。

１．４ 最適化エンジン概要
最適化エンジン２４は、基本的にＡＩエンジン２１の予測・推定精度が上がる様にレプリカ１３が最適化される方針を指示する。そのために、最適化エンジン２４は、記述ファイル１４中にある初期パラメータを調整してもよく、推論精度・予測精度を高めるために利用しているアルゴリズムの変更を指示してもよい。例えば、ある特定職場や地域・組織での感染症に疑いがある場合、最適化エンジン２４は、これに関係する予測や推定の優先順位を上げるようにレプリカ１３を生成する方針を指示してもよい。もし、診断対象のシステムの特定の部品に、製造不良やバラつきが多くみられる場合は、最適化エンジン２４は、それらの不良の推定に関係するパラメータ強化を行い、それらの不良の推定の学習に有効なレプリカの生成するレベルを上げる指示をおこなってもよい。

２． レプリカ
２．１ レプリカ生成モジュール概要
深層学習は、なんでもできますという様な誤解を与えているが、最終的には、膨大な数の入力データの学習により完成度を上げる必要がある。つまり、従来のデバッグとシステム構築という観点から、全く別物と考えるべきである。特に、システムが複雑な場合、単一機能ではないので、修正や期待した結果を得るには一定の手順が必要で厄介である。

これを可能な限り、入力側の制御により容易化するのが、レプリカ生成モジュール１９となる。例えば、パイロット用の入力パターンを準備しておいて、入力データの学習によりその精度を測定して、短時間で精度向上を実現するために、あるタイミングから次の入力タイミングまで、いくつかの複数パターンを準備してその複数結果を比較しながら、どの様な入力レプリカ生成が良い結果となるかを比較する方法で精度の測定を行えば段階的に意図的な性能向上が可能となる。これは、推論エンジン２２の推理結果とＡＩエンジン２１の推論結果とを比較して、それらの推論結果が違ったパターンから学習成果を評価し、入力レプリカを変えるという方法で予測・推論精度を向上させてもよい。レプリカ生成モジュール１９は、自己学習のためのレプリカの生成パターンをルール化して、自力で学習させながらフィードバックを行う自己学習モデルを提供できる。

古典的システム工学的な手法では、単一機能のモジュールを組み合わせて、システムを構築していく方法が安全であり信頼性の高いシステムを保証可能となる。但し、柔軟性はあまり高いとは言えない。しかしながら、デバックするときに、単一機能であると、どこに原因があるのかがわかり易くバックアップも対応し易いし、将来の障害やトラブルに対しても特定と対策が容易となる。

レプリカ生成モジュール１９は、外部ツールとして提供されてもよい。支援エンジン２０にレプリカ生成モジュール１９を組み込んでもよく、内部の入力処理側から最適化エンジン２４の指定によりレプリカ生成を制御することが可能となる。ＡＩエンジン２１は、基本的に入力データ１１により学習することにより基本的な特徴量を学習し、さらに膨大なレプリカ１３により自己学習を行うことにより推論エンジン２２が想定していない特徴を学習することを含めて、ＡＩエンジン２１を進化させることができる。

レプリカ生成モジュール１９は、推論エンジン２２、検証エンジン２３および最適化エンジン２４とともに学習システム３０を構成するための重要な要素の１つである。レプリカ生成モジュール１９は、十分な量の実データが揃わない状態において、その実データの不足を補い、ＡＩエンジン２１の学習を加速させる為の入力データと、推論・検証・最適化の各エンジンを助けるモジュールとして位置づけられる。レプリカ生成モジュール１９は、特に、検証を容易とするために、比較やエラー・不具合・不整合・不良・損傷・破壊を明確に示す内部要素の状態（レプリカ）を生成するためのツールであってもよい。機能の活動状況をより比較して推論の精度を確認する目的で、レプリカ生成モジュール１９は、生成した内部レプリカ１３ｂから入力レプリカを再生成する方法を備えていてもよく、その場合、最初に生成した入力レプリカ１３ａまたは入力データ１１から生成した内部レプリカ１３ｂのバリエーションを推定して、そのバリエーションから考えられる再生成入力レプリカ１３ｃを用意してもよい。実データ（入力データ）１１と比較して、内部レプリカ１３ｂのバリエーションとして可能性の高いレプリカを増やし、ＡＩエンジン２１の予測・推定精度を向上できる。

レプリカ生成モジュール１９は、ＡＩエンジン２１の機械学習を効率よく進めるツールとしての機能を含んでもよい。例えば、人体が診断対象物の場合、疾病・病体や健康体・未病と分類される境界領域の判定と精度を向上するために、レプリカ生成モジュール１９は、複数の実測データに基づき、統計的にバリエーションを増やしたレプリカ（入力レプリカ）１３ａを自動的に生成する機能を備えていてもよい。

現在の検査コストは、血液検査や尿検査、CTやMRI、X線などを想定した場合、５〜６万円／人が必要とされている。一方、ＡＩエンジン２１の完成を上げるには、数万人から数百万人が理想とされるが、これらのデータを短期間に収集可能な体制や、予算を確保することは容易ではない。レプリカ生成モジュール１９は、複数の実測データ（検査データ）１１をベースに、ＡＩエンジン２１の学習に要するデータを、バリエーションも含めて自動的に増やすことことが可能となる。このため、比較的少数のデータに基づいて、短期間にＡＩエンジン２１の自己学習を進めるための有効なツールである。また、症例が少なく、実測されうる検査データ１１が少ない場合においては、レプリカ生成モジュール１９は、レプリカ１３を用いて、ＡＩエンジン２１の自己学習結果をフィードバックし、ＡＩエンジン２１の推定精度を向上するための最良パスとして機能する。

レプリカ生成モジュール１９は、単独でレプリカを生成してもよい。レプリカ生成モジュール１９は、推論エンジン２２における推定過程の内部レプリカの生成と連動させてもよく、その結果を、ＡＩエンジン２１の自己学習のためのレプリカ生成に利用してもよい。生成するレプリカは、入力データレプリカ（入力レプリカ）１３ａと、内部レプリカ１３ｂと、再生成入力レプリカ１３ｃの３種類を含んでもよい。レプリカ生成モジュール１９は、入力レプリカ生成モジュール１９ａ、内部レプリカ生成モジュール１９ｂ、再生成入力レプリカ生成モジュール１９ｃを含んでもよい。入力レプリカ生成モジュール１９ａは、対象システムの検査データ１１に含まれる複数のパラメータの値の実分布を反映した入力レプリカ１３ａを生成するモジュールであってもよい。内部レプリカ生成モジュール１９ｂは対象システムの内部状態を示す内部レプリカ１９ｂを生成するモジュールであってもよく、再生成入力レプリカ生成モジュール１９ｃは、内部レプリカ１３ｂの変化範囲から逆に推定した検査データ１１のレプリカ（再生成入力レプリカ）１３ｃを生成するモジュールであってもよい。

２．２ 入力データレプリカ
入力データレプリカ（入力レプリカ）１３ａは、統計データや実データを元に確率モデルから生成され、実際の検査データ（入力データ）１１の代わりなるデータであってもよい。平均値と分散値から指定された確率モデルで、ヘルスケアにおける入力データ１１は、血液検査、尿検査、呼気・皮膚ガス測定、体温・内臓脂肪・皮下脂肪・筋肉量・体脂肪率・推定骨量・血圧・血流・心拍数・自律神経興奮度等の測定値と画像診断結果、microRNA・ncRNA・DNA等とも共に問診票などもこのデータに含まれる。

入力レプリカ生成モジュール１９ａは、統計データ、及び実際のデータに基づき、実際の測定データの代わりをするデータ（入力レプリカ）１３ａを生成するモジュールである。入力データのレプリカ１３ａは、生態データに対しては、大きく２つのモデル（単純モデルと階層モデル）を想定した確率モデルに基づいて生成してもよい。確率分布の一例は、一様分布等の単純な分布数種と正規分布である。

非相関モデル（単純モデルともいう）はデータ間に相関がないモデルであり、これは、スーパーノーマルと呼ばれるような超健康体のモデルをベースに生成する。レプリカの要素Ｙｉは以下の式（１）で表現する正規分布に従う。
Ｙｉ＝Ｎ（μｉ,σｉ２）・・・（１）
ここでのμｉ、σｉ２は定数であり、それらを要素毎に設定することでそれぞれの確率モデルが決定される。

相関モデル（階層モデルともいう）はデータ間に相関があるケースであり、主に病体を想定したモデルである。このケースでは、μｉとσｉ２は定数ではなく、他の要素と関連させて算出した値となる。そこで、要素の平均μｉと分散σｉ２に他の要素の値から算出した階層モデルを導入すれば、このような要素間の相関を統計モデルに反映することができる。ある要因（説明変数）となる変数をｘとし、それにより他の要素の平均Ｙ１、Ｙ２が増減する場合、次式（２）で表現することで、相関をもった要素を生成することができる。このケースでは、ｘの指定とａ１、ａ２、ｂ１、ｂ２を定数として定義する。
μ１＝ａ１ｘ＋ｂ１
μ２＝ａ２ｘ＋ｂ２ ・・・（２）
なお、ｘ自身をレプリカの要素として出力することも可能である。また、分散値も同様に指定可能である。

２．３ 内部レプリカ
内部レプリカ１３ｂは、入力データ１１に対する内部の部品の状態、すなわち診断対象物の状態を推定したデータであり、本来は、入力レプリカ１３ａに対する教師データの役目を担うデータである。本エンジン２０では、推論エンジン２２の推論、および／または、ＡＩエンジン２１の推論に基づいて、入力データ１１から推定した内部レプリカ１３ｂを生成してもよい。ヘルスケアにおける内部の部品は、主に人体の要素であり、臓器・血管・骨・脊髄・その他からなり、この内部レプリカ１３ｂは、これらの部品の活性度を数値で指標するものであってもよい。これらに関する情報は、入出力相関テーブル１５により提供してもよい。

内部レプリカ１３ｂの具体的な例の１つは、入力データ１１に含まれる以下のような測定（検査）データに対し、相関のある臓器の状態を活性率などの指標を使い、その指標値がとり得る範囲を確率モデルで生成したものであってもよい。内部レプリカ生成モジュール１９ｂは、測定データ（問診含む）に対し、入出力相関テーブル１５および最適化エンジン２４からの指定により、内部レプリカ１３ｂを生成する。学習を目的として生成される入力レプリカ１３ａが、それを生成する段階で、臓器の状態が定義されている場合は、この生成モジュール１９ｂを用いなくても、入力レプリカ１３ａと臓器の状態のセットで教師付きデータとして、ＡＩエンジン２１の学習用のデータとして、また、その評価用のデータとして、そのまま利用できる。医者の所見付きの測定データ（入力データ）１１も、測定データと臓器の所見のセットになるので、その扱いは基本的に教師付きデータと同様である。一方、医者の所見のない入力データ（測定データ）１１から内部の状態を推論するためには、入出力相関テーブル１５を参照し、その都度、測定データ１１に対し、可能性のある内部レプリカ１３ｂのバリエーションを生成する必要がある。後にこの内部レプリカ１３ｂのバリエーションから生成された再生成入力レプリカ１３ｃは、入力データ１１と比較され、最適な内部レプリカ１３ｂと再生成入力レプリカ１３ｃとのセットが教師付きデータとして利用される。

内部レプリカ生成モジュール１９ｂは、測定データ（問診含む）１１から入出力相関テーブル１５および最適化エンジン２４からの指定により、フェーズ＃１として生成された入力レプリカ１３ａをベースに内部レプリカ１３ｂを生成してもよい。フェーズ＃１では、入力データ（測定データ・問診・他）１１に基づいて限られた自由度から入力レプリカ１３ａを生成し、入力レプリカ１３ａと１対１で内部レプリカ１３ｂを生成してもよい。

入出力相関テーブル１５は、後述するように、入力データ（検査データ）１１と内部の状態指標（各パーツの活性率などで）との相関を定義したファイルである。統計モデルとしては、測定データについて正常な範囲と異常な範囲が統計的に分るものについて、それらが関連する内部の状態を指標として、正常な範囲を１００、異常な範囲をその異常の程度により、階段状に減じた値を与えることで定義してもよい。疾病データについては、その測定データに対し、医者の判定をベースに内部の状態の指標を定義してもよい。問診データについては、設問時に予め紐付けされた内部とその状態の指標に従い、問診結果に対する指標を定義してもよい。このテーブル１５は、再生入力レプリカ生成モジュール１９ｃにおいて利用してもよい。

内部レプリカ生成モジュール１９ｂは、内部レプリカ１３ｂを、多段階のレプリカとして生成してもよい。例えば、１次内部レプリカは入力データ１１と統計予測から生成されてもよい。対象となる入力データは、入力データ（測定データ・問診を除く）１１または入力レプリカ１３ａである。１次内部レプリカ生成では、１つ以上の入力データ１１の相関は参考にしてもよい（弱い相関）。１次内部レプリカの生成では、未解決（Ｕｎｋｎｏｗｎ）な要素を許す構造としてもよい。

２次内部レプリカは、入力データ相関／疾病から生成されるレプリカであってもよい。対象となる入力データは１次内部レプリカであり、入力データ相関と相関テーブル（強い相関：病気や疾病・病歴・遺伝・その他）から生成されてもよい。最適化エンジン２４から指定されて生成パターンを変えてもよい。

３次内部レプリカは、問診によるフィルター／絞込みにより生成されるレプリカであってもよい。対象となる入力データは２次内部レプリカと問診データである。３次内部レプリカは、問診データから２次内部レプリカを再度チェックし、補正や修正・除外を実行してもよい。最適化エンジン２４から指定されてこれらの処理を実行してもよい。

４次内部レプリカは、インフルエンザ・感染症の拡大への対応を考慮して生成されるレプリカであってもよい。対象となる入力データは３次内部レプリカと、後述するクラウドサービス（Ｐ−ＨＡＲＰ）から指定される状況あるいは情報であってもよい。４次内部レプリカは、Ｐ−ＨＡＲＰからの指定により３次内部レプリカを再度チェックし、補正や修正・除外を実行する。最適化エンジン２４から指定されてこれを実行してもよい。

５次内部レプリカ生成は、パンデミックへの対応を考慮して生成されてもよい。対象となる入力データは４次内部レプリカとＰ−ＨＡＲＰから指定される状況あるいは情報であってもよい。５次内部レプリカは、Ｐ−ＨＡＲＰからの指定により４次内部レプリカを再度チェックし、補正や修正・除外を実行する。最適化エンジン２４から指定されてこれを実行してもよい。

２．４ 再生成入力レプリカ
再生成入力レプリカ１３ｃは、入出力相関テーブル１５を逆方向に読み、内部レプリカ１３ｂから入力データ１１を推定したデータ（レプルカ）である。このレプリカ１３ｃは、基本的に入力データ１１と同じ種類のものが対象となるが、生成されるデータは異常が検出された内部エレメントに相関のあるデータだけであってもよい。ＡＩエンジン２１はこの再生入力レプリカ１３ｃと実際の入力データ１１を比較し、その評価関数から入力データ１１に最も近い内部レプリカ１３ｂをそのバリエーションの中から特定することで、内部の状態の予測・推論をすることを学習してもよい。

入力レプリカ１３ａが、健常者や疾患、あるいはその間の未病等の群をベースにした分布にしがたって生成されるのに対し、再生成入力レプリカ１３ｃは、臓器の活性率をベースにしている点で異なる。つまり、再生成入力レプリカ１３ｃは、活性率からそれらがとり得る検査値の範囲を確率モデルで生成したものであってもよい。

再生成入力レプリカ生成モジュール１９ｃは、生成された内部レプリカ１３ｂのバリエーションに対し、逆に入力データ１１の変化範囲を推定して入力データ１１を再構成（再生成入力レプリカの生成）するモジュールであってもよい。統計的な手法で生成された入力レプリカ１３ａとは別に内部レプリカ１３ｂを生成して、この内部レプリカ１３ｂから再度、入力レプリカ（再生成レプリカ）１３ｃを生成することで、統計的にレプリカの可能性を広げるという操作と、広げた可能性からより絞り込んだ要因（状態）を示すレプリカを生成することが可能となり、ＡＩエンジン２１の推定精度を向上することができると考えられる。

内部レプリカ１３ｂおよび再生成レプリカ１３ｃを生成することは、診断対象のシステム内部の部品を直接的に確認可能とすることにつながり、検証確度を向上させることに貢献する。診断対象の人体の構成部品と病気や健康状態を特徴付けるデータ相関を使ったレプリカを生成することが可能となり、統計処理により生成された最初の入力レプリカ１３ａよりも、精密検査や病気が確定してから測定された病体モデルを反映したレプリカとすることが可能となり、ＡＩエンジン２１の学習効果を、疾病に絞込んで行うためには有効であると考えられる。

再生入力レプリカ生成モジュール１９ｃは、入力レプリカ生成モジュール１９ａと共通する構成を含み、必要に応じて、機能強化を実施し、原則、モデルファイルの指定を変えるだけで、必要な再生入力レプリカ１３ｃの生成を可能としてもよい。再生入力レプリカ１３ｃを生成するための条件は、内部レプリカ１３ｂと同様に、入出力制御テーブル１５に記述されていてもよい。内部レプリカ１３ｂとは逆方向に読み出すことで、これを利用してもよい。メタ・モデル記述ファイル１４は入出力相関テーブル１５と共に再生入力レプリカ１３ｃの生成に必要な定義ファイルであってもよい。

再生入力レプリカ生成モジュール１９ｃは、相関情報を、入出力相関テーブル１５とメタ・モデル１４から得て、多次的に入力レプリカを再生してもよい。内部レプリカ１３ｂの生成とは逆方向に入出力相関テーブル１５を読むことで内部レプリカ１３ｂのバリエーションから生成された再生入力レプリカ１３ｃは、検証エンジン２３によって、測定データ１１との差分値（分散値）を求め、その結果から人体内部パーツの活性状態・稼働状態・不良状態（不調・疲労・劣化）を特定してもよい。

１次レプリカ再生成は、統計予測による内部レプリカ１３ｂから行われてもよい。検査データ間に相関がないケースの統計データに基づき、臓器の状態（活性率）に応じて、再生入力レプリカ１３ｃを確率モデルで生成してもよい。２次レプリカ再生成は、入力データ相関／疾病から生成されてもよい。１次レプリカ再生成よりも複雑なケースとして、検査データ間に相関がある固有の疾病のケースを想定した統計データに基づき、臓器の状態（活性率）に応じて、再生入力レプリカを確率モデルで生成してもよい。３次レプリカ再生成は、問診によるフィルター／絞込みで行われてもよい。臓器の状態（活性率）に応じて、問診データを再生入力レプリカとして確率モデルで生成してもよい。４次レプリカ再生成は、インフルエンザ・感染症の拡大への対応として生成されてもよい。特定の疾病に対する２次レプリカ再生成に属するものであるが、緊急性を要する事態に迅速に対応することを優先して、単純化した相関データを作成し、対応してもよい。５次レプリカ再生成は、パンデミックへの対応として生成されてもよい。特定の疾病に対する２次レプリカ再生成に属するものであるが、緊急性と共にその重大性の見地から、その状況に最も適した相関データを、緊急性を持って作成し、対応してもよい。

３．システムのデータ構造
３．１ メタ・モデル記述ファイル
メタ・モデル記述ファイル１４は、診断エンジン２０が、様々なアプリケーション領域に利用・応用される事を容易にするために設けられてもよい。メタ・モデル（メタモデル）は診断エンジン２０が診断の対象とするシステムを、ソフトウェアで利用可能なデータあるいはコンセプトの集合として記述したモデルである。診断エンジン２０が診断の対象とするシステムは、多数の内部パーツで構成される複雑なシステムであってもよく、内部パースの１つ１つの稼働状態や好調・不調・不良・故障の状態があり、これらの１つがある限界を超えるとシステムとして異常・破綻となる様な系であってもよい。対象システムの検査データ（観測データ、測定データ・入力データ・補足データ）１１から、内部パーツや構成部品の状態を推定して、これらの内部状態のバリエーションから検査データ１１がどうあるのかを再推定して、実際の検査データ１１と再推定した検査データの差分値（分散値）から予測・推論をするものである。支援エンジン２０の応用の１つのターゲットは、ヘルスケアであり、診断対象のシステムは人体である。

３．２ 入力データ
診断支援エンジン２０への入力データは検査データ１１であり、血液・尿・呼気・インナースキャン他などの測定データと問診データに分けられる。測定データは、一般検診で見られる様な項目（パラメータ）を含むデータと、より精密検査で得られる様な項目（パラメータ）を含むデータに分けてもよい。測定データは、負荷時の心拍数や正常値に戻る迄の時間、筋肉量や肥満度、インナースキャンで得られる情報を含んでいてもよい。問診で得られる情報（問診データ）は、家族の膵臓癌等の病歴や自分の病歴、免疫度を示す様な質問を、複数違った視点から問い合わせて得られたものであることが望ましい。測定データの測定環境は、個人によって変わることがあり、問診データがある程度、個人の測定環境の差を埋める役割を果たすことになってもよい。

さらに具体的には、ヘルスケアを対象とした検査データ１１の種類としては、血液、尿、呼気・皮膚ガス、体温・内臓脂肪・皮下脂肪・筋肉量・体脂肪率・推定骨量、血圧・血流・心拍数・自律神経興奮度等の測定値と画像診断結果、microRNA・ncRNA・DNAの各情報と問診表等が含まれていてもよい。支援エンジン２０において、過去のデータを検査データ１１として参照する場合、上記のデータは、必ずしも全てが揃うという訳では無いが、いくつかのデータが揃っていれば推論が可能な様に機能させることが可能である。

検査データ１１の最初の入力形式は、分類、一般名称と略称、数値、単位から構成されてもよい。検査データ１１は、画像診断等のデータを含んでいてもよい。画像データの解析負担が大きいことから、検査データ１１は、体の内部パーツと腫瘍・癌の位置、サイズ、進行状況を記述して代替させたものであってもよい。問診表に関しては、医療関係者が利用しているものを最初の問診として使用してもよい。検査データ１１は、検証エンジン２３から要請された追加テストの結果や、２〜３ヶ月後、６ヶ月後、１年後に再測定データ、経過観察の結果などを含んでいてもよい。検査データ１１は、２週間などの単位での連測測定を数回実施した結果や、健康体へシフト（回復）しているのか病体（悪化）しているのかを判定する為の微分係数要素を含むものであってもよい。

３．３ 出力データ
出力データ処理モジュール２９は、出力データ１２を、基本的に本プロジェクトに参加をしているメディカルドクターの視点で、各疾病と関係するマーカーとなる内部状態あるいは物質を中心に、各疾病と相関が取れるような形式で出力してもよい。出力データ１２は、メタ・データの評価関数と相関関数を中心に纏めてもよい。入力データ１１の蓄積量と時間軸での各入力項目の増減を単独またはグループで評価を行い、これらの傾向も加えた形で出力データ１２との相関を取れるような形式で出力してもよい。診断対象のシステムに対し、注目すべきと判断あるいは推定される状態のトップ１０〜３０を優先して、メディカルドクターに対しアドバイスする形式で出力データ１２をまとめてもよい。

出力処理モジュール２９は、対象システムとしてあまり重大では無い領域である推定される状態についても、１〜３年先、５年先の心配事項・懸念事項はメッセージとして出力データ１２に含ませておいてもよい。ヘルスケアの場合は、法律的な制限もあることからメディカルドクターのチェックは受けることが前提になるが、出力データ１２の推論（予測）は診断支援という点で重要であり、ある条件での予測であること、確率的な要素を含んでいることを出力データ１２に含ませておいてもよい。継続して診断支援エンジン２０の出力を何回か利用しているユーザーに対しては、前回の出力データ１２との差分をより意識したメッセージを出力データ１２に含ませてもよい。

出力データ１２は、複数の性質の情報が提供可能な様にしてもよい。この診断支援エンジン２０の目的の１つは、健康度の予測・推定を行い個人や企業レベルで健康な状態を維持し易いツールを提供して健康予防や先制医療への貢献を行うことであってもよい。従来の画像診断装置、特に、１回〜２回の健康診断ではトレースに限界があり、個人が健康管理する場合に限界がある。診断支援エンジン２０およびそれを含むシステム１０を普及させることにより、疾病（腫瘍・癌・成人病・感染症・他）などへの注意喚起や未病から病体へと移行リスクがある場合の注意メッセージを早い段階で届けることを可能にできる。それにより、健康対策や維持を容易にして、個人的にも経済負担を少なくして、国全体が負担する医療費の低減を実現することが可能となる。診断支援エンジン２０は、それぞれ専門性のあるエンジンであってもよく、その出力情報１２も経験値に比例して具体的で詳細になる様な設計であってもよい。出力データ１２には、人体内部パーツの活性状態・稼働状態・不良状態（不調・疲労・劣化）が確率と一緒に情報（健康度：安心・警告）として提供されてもよい。また、出力データ１２には、これらに合わせて、今後健康増進、対策としてのアドバイス情報も参考程度に追加されてもよい。

出力処理モジュール２９が生成する出力データ１２のデータ構成は、音声出力・テキスト出力・画像出力であってもよい。診断対象システムの内部構成部品の活性化率・稼働率（貢献・機能）とその複数組み合わせのマトリックス（数値）とそれぞれの出力インデックス及び補助情報テーブル（追加）を連携させて、出力データ１２を決定する様にしてもよい。

出力データ１２は、健康度という情報を含んでもよい。健康度は、単純な一次元的な数値情報となるが、これは、消化器官・呼吸器官・咽喉・泌尿器・脳・心臓・循環系・血管・自律神経・骨・脊髄・その他に分類すれば、その経時変化、悪化・改善・急激・緩やかと考えると、ベクトル量というよりテンソル量として階層化した表現形式が有用である。

西洋医学的な分析・解析の観点からは、内部の部品間の相互作用とその時間経過と悪化・改良の情報が見える予測推定が出力データ１２に含まれていてもよい。これらの情報は、個人ヘルスケアサービスの利用・有用度としても価値がある。例えば、内部の部品の活動状態が数値化されて、また、経時変化が測定される様になると、物理学的な加速や減速というイメージからも想像が容易となり、回復や病体の悪化がより明確になる。個人の注意を喚起したり、運動や食事療法の効果を確認して計画を立てたりと分かり易くなる。

メタ・モデルの記述ファイル１４には、入力データ１１と内部構成要素（部品）を関連付ける相関式が記述されてもよい。また、メタ・モデルの記述ファイル１４には、最終的に外部で観測される健康度・未病度・病体度といった情報が記述されていてもよい。これは、一般的には、病気の種類や分類の推定根拠となる情報となる。出力データ１２は、複数の入力データ（測定値）１１間の相関性と内部構成要素間の活性度や不調度、これをリカバリーする簡単なヒントやガイドラインを含んでいてもよい。但し、出力データ１２は、メディカルドクター（ＭＤ）の一般的なアドバイス的情報であり、病院や専門医に相談する様に進める記述を含んでいてもよい。

出力処理モジュール２９は、出力データ１２を、ＷＥＢサーバーを介して提供してもよい。ＷＥＢサーバーとＡＩサーバーは、ＴＣＰ／ＩＰを用いて通信を行ってもよい。使用するライブラリはＰｙｔｈｏｎであればｓｏｃｋｅｔライブラリであってもよい。ＷＥＢサーバーとの通信では、テキストまたはファイルを用いてもよい。ＷＥＢサーバー側への表示を指示する方法は、ＷＥＢサーバーと診断支援エンジン２０側で同一のテーブルを保持し、診断支援エンジン２０側がインデックス番号を指示することにより実現してもよい。ＷＥＢサーバーが表示する内容は、画像情報・音声情報・テキスト情報であってもよい。診断エンジン２０は、複数のその他の診断支援エンジン（人工知能を含む）や、メディカルドクター（人間）と端末を介して通信を行うことにより、精度の高いディシジョンの為のコミュニケーションを行ってもよい。この時、ＡＩプロトコルとＡＩゲートウェイを利用して通信してもよい。ＡＩゲートウェイは、人間とのコミュニケーションを行う場合に必要となる。

診断支援エンジン２０または出力処理モジュール２９は、ユーザーの最大関心事を示すユーザーの検索・行動履歴をベースに、ユーザーが気になると想定される情報を出力データ１２に含めて提供してもよい。また、出力処理モジュール２９は、ユーザーが特定のヘルスケア・プラットフォームで特定のランクのメンバーになることで、通信ＫＥＹを受取り、クラウド経由のサービスを利用できる機能を含んでいてもよい。ユーザーは、自身の問診データがあれば、診断支援エンジン２０から、自身の健康状態についてＷＥＢサーバーを通して、推定結果を受け取ってもよい。また、診断支援エンジン２０は、健康状態と同時に医療行為にならない程度の健康アドバイスも行ってもよい。

診断支援エンジン２０または出力処理モジュール２９は、複数のエンジン同士のやりとりやメディカルドクターとの通信を実現するためにＡＩプロトコル／ＡＩゲートウェイを通してクラウド経由のサービスに接続する機能を含んでいてもよい。可能な限り対称性を維持するために、複数の診断支援エンジン２０が、ＡＩユニフォーム（ＡＩシェル／ＡＩスーツ）を実装して他のＡＩとのリンクを統一的に扱える様にしてもよい。

アプリケーション開発からは、出力データ１２は、こういうライブラリで呼び出せますよと具体的な記述をＡＰＩとして用意して提供（公開）されてもよい。その場合、ファイルまたはテキストベースのコミュニケーションでやりとりが可能であってもよい。ＷＥＢサーバーとつなぐ目的は複数であってもよい。その目的は、ＡＩプロトコルに従って高精度ディシジョンの為のコミュニケーションを実現することを含んでいてもよい。その目的は、逆に、コミュニケーションをする仕掛けを通して、ユーザーの検索などを元に必要な情報を推定して、ユーザーが気にする情報を段階的に提供することを含んでいてもよい。

特定のサービス会社のヘルスケア・プラットフォームのメンバーになれば、クラウド経由のサービスの世界に入れるようにしてもよい。クラウド経由で自分の問診データを入れれば、ある程度の予測がクラウド経由で診断支援エンジン２０から取得できるようにしてもよい。ＷＥＢサーバーで限界がある場合は、診断支援エンジン２０で扱うプラットフォーム上で、クラウドを介してユーザーと対話型で進めることができるエンジンであってもよい。クラウドサービスの入り口にたどり着くためのの風景・ナビゲーション、必要な情報をガイドライン的に示す機能を診断支援エンジン２０が備えていてもよい。

クラウドサービスなどで提供される問診票には、問診に答えるためのアドバイスが実装されていてもよい。ユーザーの健康状態マップ的なものがわかる一連のＱ＆Ａや、問診に対する回答に対して複数のエンジン同士がやりとりできる機構を実装してもよく、問診に対する回答の解析を含めて、メディカルドクターと複数の診断支援エンジン２０がクラウドなどを介してやりとりをして予測をするシステムは有効である。

３．３．１ デジタルアバタ
出力データ１２のはアバタ処理モジュール２９１が提供するデジタルアバタ（ＤｉｇｉｔａｌＡｖａｔａｒ）であってもよい。デジタルアバタは一般のクラウド上でアクセスできてもよいが、特定のサービス会社が提供する限られたクラウドサービス、例えば、Ｐ−ＨＡＲＰのようなセキュリティの確保が容易なプラットフォームを介してアクセスできるようにしてもよい。デジタルアバタは、ＲＷ（ＲｅａｌＷｏｒｌｄ、実空間）一人に対して、複数設定が可能であってもよい。また、その複数のデジタルアバタは、完全に同一のヘルスケア特性であっても良いし、その可能な複数バリエーションであっても良い。ＶＲ（仮想現実）では、複数のＶＲ空間が存在して、１つのＶＲ空間には１つのアバタを残して、同一次元の別のＶＲのサイバー空間へ移動するようにしてもよい。移動を実行する場合は、元のＶＲ空間とは切り離されてもよく、最大移動回数が規定されてもよい。自分の制御しているデジタルアバタが、１つ存在してアクティベートされるが、これ以外は、全て影となり、あるルールに従って自動更新されてもよい。ＲＷからＶＲへのアクセス（サイバー空間）は、原則、１対１、または１対Ｎに対して実行されてもよい。Ｎ対Ｍを可能としてもよい。例えば、セキュリティ上の問題からシステム運用側でその必要がある場合にこれを実行してもよい。

ＶＲ空間は、（１）ＤＮＡ空間（血縁）、（２）地理空間（国・都市・地方）、（３）Ｗｏｒｋｉｎｇ空間（職場・学校・アルバイト）、（４）ファミリー空間（親族）、（５）運動空間（歩行、ランニング、スポーツ９、（６）趣味空間 （音楽、読書、絵画、芸術、ヨガ、瞑想、ゲーム）、（７）イベント（飲み会・コンペ・デート・引越し・卒業・転職・転勤・退職・旅行・休暇・結婚・出産・葬儀・他）、（８）個体特性空間（年齢・性別・体重・身長・胸囲・ウェスト・座高・内臓脂肪・筋肉量・その他）、（９）ライフ／環境空間（食事・仕事・勉強・運動・睡眠・趣味・会話・瞑想）などに分類されてもよい。限られた空間から他のサイバー空間に設定を行い拡大してもよい。ＶＲ内では、自分の関心が他の空間へ移動しても、自動的に自分の基礎数値（健康度・疲労度・ストレス度・ヘルスケア数値、過去データ）は、更新されて継承されてもよい。

デジタルアバタとＶＲは、ＲＷに存在する個人が、様々な環境や状況に応じてどう変化していくかをシミュレートするものであり、ＲＷの自分のＱｏＬ（クオリティーオブライフ）を大幅に向上するゲームとも見ることも可能である。この中で、健康度・疲労度・ストレス・心的状態と充実感が、今後、活性化してより健康な状態へ移行するのか、さらに悪化するのか、などの色々な角度からシミュレータを通して、その原因や今後の健康度を上げる１つの指針を得るゲームとして提供することも可能である。

ＲＷとＶＲとの一致性や精度を求める場合は、スーパーバイザのアドバイスやガイドラインに従って、デジタルアバタと自分の一致性を高める測定や問診などを定期的に受けてもよい。ＶＲの中には、スポンサー企業が多くいて、健康度を向上する提案を行うようにしてもよい。ＶＲだけでは無く、ＲＷで、同様のシステムを構築してもよい。

デジタルアバタとして情報を提供する際のセキュリティ（プロテクション）に必要なキーは、デジタルアバタとスーパーバイザと呼ばれるＶＲの管理者とこれから派遣されるＫｅｙ−Ｍａｋｅｒにより発行されてもよい。Ｋｅｙ−Ｍａｋｅｒは、時間と場所、デジタルアバタのＩＤに対して、キーを発行して、これがセキュリティとして利用されるが、スーパーバイザから、定期的にキーの変更が要求されてもよい。１つのＲＷの人間（参加者）が、複数のＶＲの違った世界へとアバタとして写像されてマッピングされると、それぞれの視点でのビッグデータ比較と推定精度を上げる事が期待されてもよい。自分の近親者（血縁者）に、もし膵臓癌の罹患者が１人いれば、膵臓癌になるリスクは普通の人に比較して高くなるというようなケースにおいては、例えば、サイバー空間の（４）ファミリー空間では、この様な相関情報からの推定やアドバイスはより強い形で表現されてもよい。今後、検証を要する相関やその他の仮説は、１つの条件として推論エンジン２２に反映されてもよい。ＡＩエンジン２１は、実測データを含む入力データ１１とレプリカ１３により学習して成長するため、パンデミックや感染症に対する予測は、それらが社会的に問題とならない限り、必要以上に強く反映されなくてもよい。

クラウドサービスでデジタルアバタにより出力データ１２を提供する場合、デジタルアバタを最初にエントリーする段階でセキュリティ確認が実行される。ＲＷからＶＲへとダイブする場合に、ＡＲ（ＡｕｇｍｅｎｔｅｄＲｅａｌｉｔｙ）と呼ばれる手法でスイッチしてもよい。そのダイブは、本人の好む方法で実行されてもよい。ＲＷからのダイブは、本人と合意された方法でのダイブとなり、セキュリティ・サイバー・エージェントがこれを監視してもよい。本人だけが知り得る情報や場所（存在）、バイオ認証その他を使ったセキュリティによる保護をおこなってもよい。ＲＷでも本人と分からない様に偽装したり変装したりする手法が取られるが、複数のデジタルアバタの活動するＶＲまたはサイバー空間では、本人が所有するヘルスケア情報を継承しながら、外側から観測可能な状態については簡単に変更可能な形で、追跡が難しい環境を提供することができる。デジタルアバタを通してＲＷへのアクセスは、原則として本人だけが行うようにできるが、必要な場合は、サイバー・エージェントを通してホットラインをオープンして実現するようにしてもよい。ＶＲのサイバー空間に存在する各種アイテムは、ＲＷにも存在するので、その効果を確認する場合は、ＲＷでの利用を経験して、その結果を自分のデジタルアバタを通してＶＲサイバー空間へと持ち込んでもよい。

３．４ 入出力相関テーブル記述ファイル
入出力相関テーブル記述ファイル（相関情報ＤＢ、相関情報）１５は、相関処理モジュール２７と推論エンジン２２で使用する情報であり、ウェブ上で確認可能な相関に信頼性のあるものとメディカルドクター（専門医や医療系研究者）が、確認して正しいと思われる情報をベースにして生成されたものである。

入出力相関テーブル記述ファイル１５は、入力データ１１の種類と数値を分類して、内部状態（各パーツの稼働状態及び活性化率など）の相関表を作成して、結果的に、この膨大な組み合わせから出力データ順位と確度（確率％）を決定する。逆に、内部状態（バリエーション）が分かれば、入力データ１１が推定可能な構造を持つことを意味する。現在の西洋医学における、内部構成部品の不調・不良・破損・異能不全が、病気に繋がっているという考え方から処方箋をプランするという発想が反映されていてもよい。現在、使用されている医療機器・装置の多くがこの考え方を支持する様に開発されている。従って、入出力相関テーブル記述ファイル１５は、この様な環境を想定して、それを可能な限り反映させる様な構成・スタイルとするのが良い。相関情報１５は、現在の疾病や病気・感染症等の上位１０〜２０に関しては、相関性を示す判断用インデックスを記述してもよい。

４． 診断エンジンの各モジュールの詳細
４．１ 入力処理モジュール
入力処理モジュール２５は、推論エンジン２２およびＡＩエンジン２１に対し共通のデータフォーマットとなる様に検査データ１１を整えるとともに、検査データ１１を予め定められたルールにしたがって前処理する機能を含んでいてもよい。本例の入力処理モジュール２５は、入力データ処理モジュール２５０と、プリプロセッシングモジュール２６と、検査データ１１に含まれる各パラメータ同士の相関を示すマップを生成する相関処理モジュール２７とを含む。

４．１．１ 入力データ処理モジュール
入力データ処理モジュール２５０は、推論エンジン２２およびＡＩエンジン２１に対し共通のデータフォーマットとなる様に入力データ１１のアライメントを実現する機能を含んでもよい。入力データ１１を出来るだけ統一したフォーマットに変換あるいは整理し、プリプロセッシング処理を通して、血液データ・尿データ・インナースキャンデータ・皮膚ガス・呼気・問診データを統一的に処理可能なフォーマットへと変換を行ってもよい。また、相関処理を通して、この中のデータ、例えばクレアチニンが、腎機能の低下や腎不全へ繋がる様な数値のどの段階にあるのかをマーキング（ラベリング）してもよい。糖尿病であれば、グルコース値・ＨｂＡ１Ｃが参考として良く使用されるので、これらの数値レベルからその進み具合が推定可能となる。

入力データ１１に問診データが含まれる場合は、曖昧さが残るので複数の質問から数値へと変換する処理を実行してもよい。これらは、予め記述ファイルで指示された様に数値データへと変換を実行してもよい。乳癌の場合は、その***形状やボディライン、ある程度の容量（サイズ）を推定可能な様に問診を構成する必要がある。特に、システム内部構成部品の活性度や機能貢献を推定する場合、内部レプリカ１３ｂによっては入力データ中の測定データから推定できない場合もあり、これらは、全て問診データを複数用意して推定する様にしてもよい。膵臓疾患の場合は、家族や親族に膵臓癌の患者がいるという様な情報があれば、その確率・危険率が上がるように入力データ１１を生成してもよい。

支援エンジン２０では、処理の関係上、入力データ１１を、できる限り統一的に扱うために、数値データとして扱いたい。実測データには、例えば、血液データであれば数値になっているが、問診データの場合は、あいまい性が存在しており、数値データへと変換する必要がある。例えば、問診票に、”とてもあてはまる”、”あてはまる”、”どちらともいえない”、”あてはまらない”、”まったくあてはまらない”というものがあれば、”とてもあてはまる”を４、”あてはまる”を３、”どちらともいえない”を２、”あてはまらない”を１、”まったくあてはまらない”を０と変換することができる。ただし、問診データの場合、その数値が問診票の回答を数値化したことがわかるようなラベルを用いることが望ましい。

入力データ処理モジュール２５０は、その他の、入力データ１１とシステムの構成要素（ex.体の内部構成要素）との対応関係を明確にしておく処理を実施してもよい。例えば、支援エンジン２０は、各病気の専門ＡＩエンジン２１を学習により生成して活用する支援システムであってもよい。入力処理モジュール２５は、専門のＡＩエンジン２１の推論結果と、その推論結果の検証過程などで、エンジン２０が外側の専門医との間で行う情報交換を、検査データ１１として含める入力処理を含んでいてもよい。複数で違った角度からの推論に役立つ付加情報を検査データ１１に入れることで、診断処理対象システムの全体については知っているとともに、さらに専門領域では詳細な知識を持っている支援エンジン２０を提供できる。

入力データ処理モジュール２５０は、入力データ１１に含まれる各パラメータの値に相関がある場合は、相関を表すテーブルを作成してもよい。入力データ処理モジュール２５は、入力データ１１に含まれる各パラメータと、対象システムの構成要素の対応関係を表すテーブルの作成をおこなってもよい。

４．１．２ プリプロセッシングモジュール
プリプロセッシングモジュール（変換・統計・他）２６は、相関処理モジュール２７に対して、性質の違っている入力データ１１を変換して、共通化して推論エンジン２２・検証エンジン２３・最適化エンジン２４、ＡＩエンジン２１が扱える様にする機能を含んでもよい。例えば、腎機能の障害の１つのマーカー物質としてクレアチニンという物質が存在するが、この物質は、年齢や性別により数値と腎機能の障害度に違いがあることが分かっている。これは、変換を行って正規化処理をする様にしないと単純に数値間の比較が意味をなさない。この様な医学的視点からの測定データの前処理をしないと単純に比較が困難となる。血糖値に関しても空腹時なのか食事後どの程度の時間が経過しているのかによって、インシュリンの活性度を推定するのに全く違った状況となる。これは、通常は、問診と一緒に判断してある程度数値の意味を比較可能な様に変換・正規化する必要がある。

４．１．３ 相関処理モジュール
相関処理モジュール２７は、実際に、入力データ１１に含まれる各パラメータの数値の変換を行って正規化処理してもよく、数値間の比較から意味を掴めるようにマップ化してもよい。図２に、統計的な手法を用いて入力データ１１を相関処理して推論エンジン２２およびＡＩエンジン２１に提供する相関処理モジュールの一例を示している。

図３に、相関処理に用いられるヒートマップ１３０の一例を示している。また、図４に、ヒートマップ１３０の一部を拡大して示している。このヒートマップ１３０は、正常状態（超健康体）のヒートマップ１３１の一例である。ヒートマップ（静的マトリクス）１３０は、検査対象の患者が含まれる人種毎、性別毎、特定の地域毎の人々、あるいは人類全体といった多数の人間（多数の検査対象のシステム）を母集団とする検査結果の統計データから作成される相関図の集合体である。１つ（１種類）のヒートマップ１３０は、母集団に含まれる人間が経る可能性がある、いくつかの状況・状態の１つを代表し、複数の状態に対して、複数のヒートマップ１３０が用意される。正常状態のヒートマップ１３１は、患者が属する母集団の中で、健康診断などで正常と判断された患者の検査結果の統計データの相関を解析した結果の一例である。

ヒートマップ１３０は、患者が属するする母集団を形成する複数の患者の各個人の各検査項目（各パラメータ）の検査結果（測定点）が、各検査項目間の相関を示すようにＸ軸とＹ軸とに配置されており、各検査項目間の相関を示す多数の散布図１３９の集合体（マトリクス）である。なお、検査データ（入力データ）１１の項目（パラメータ）間の相関の一例は、散布図を用いた相関であり、多数の患者の検査データのうち、異なる２つの検査項目（パラメータ）の数値をＸ座標およびＹ座標とした点をプロットした散布図における相関である。異なる複数の検査項目の数値を多次元で示した相関であってもよい。

検査内容としては、血液検査、尿検査、呼気・皮膚ガス測定、体温・内臓脂肪・皮下脂肪・筋肉量・体脂肪率・推定骨量・血圧・血流・心拍数・自律神経興奮度等の測定値と、画像診断結果と、ｍｉｃｒｏＲＮＡ・ｎｃＲＮＡ・ＤＮＡ等とも共に問診票なども、検査に含まれ、これらの検査により得られる測定値が散布図１３９の対象となる。例えば、血液検査の測定項目の一例は、ＴＧ（中性脂肪）、ＨＤＬ（ＨＲＬコレステロール）、ＬＤＬ（ＬＤＬコレステロール）、ＦＢＳ（グルコース（空腹時））、ＨｂＡ１ｃ（ヘモグロビンＡ１ｃ）、ＡＳＴ（アスパラギン酸アミノトランスフェラーゼ）、ＡＬＴ（アラニンアミノトランスフェラーゼ）、ｇＧＴ（γ-グルタミールトランスファラーゼ）、ＡＬＰ（アルカリホスファターゼ）、ＬＤ（乳酸脱水素酵素）、ＴＰ（総たんぱく）、ＴＣ（総コレステロール）、ＢＵＮ（尿素窒素）、Ｃｒ（クレアチニン）、ｅＧＦＲ（推算糸球体濾過量）、ＵＡ（尿酸）、ＲＢＣ（赤血球数）、Ｈｂ（ヘモグロビン）、Ｈｔ（ヘマトクリット）、ＭＣＶ（平均赤血球容積）、ＭＣＨ（平均赤血球色素量）、ＭＣＨＣ（平均赤血球色素濃度）が挙げられる。

ヒートマップ１３０は静的マトリクスの一例であり、例えば、超健康体と判断された患者についての、上記の検査項目と、他の項目、例えば、Ｗｅｉｓｔ（腹囲）、ＢＭＩ、ＢＰ＿Ｈ（最高血圧）、ＢＰ＿Ｌ（最低血圧）などの身体あるいは心肺検査項目とを含む多数の検査項目間の多数の散布図１３９が、画像認識しやすいように２次元に配置された例である。ヒートマップ１３０においては、検査項目間の相関を示すように、全ての数値を点として並べたものが左下の三角形で、その相関を図式と数値で表現したものが右上の三角形となる。殆ど相関の見られないものは、小さな数値で＋正を示してあり、−数値は負の相関を示している。大きな相関があるものは大きな数値で表現している。

図５に、ヒートマップ１３０の異なる例を示している。図５に示すヒートマップ１３０は、準正常状態（未病）のヒートマップ１３２の一例であり、患者が属する母集団の中で、健康診断などで正常とも非正常とも判断されなかった多数の患者の検査結果の統計データの相関を解析した結果の一例である。未病とは、測定データ・入力データ群の中で、超健康体と病体を除いたものを指す。超健康体とは、臨床医や人間ドックで全ての項目（測定データ・入力データ・問診）で正常値を示している患者を示し、病体とは、医者から病気と判断された患者を示す。通常、もっとも多数の患者が属する可能性がある状態であり、未病は、健康体に近い状態から、病体に近い状態を複数の段階的な状態で定義し、それぞれについてヒートマップを用意することも可能である。

図６に、ヒートマップ１３０のさらに異なる例を示している。図６に示すヒートマップ１３０は、非正常状態（病体）のヒートマップ１３３の一例であり、患者が属する母集団の中で、医師に特定の病気であると判断された多数の患者の検査結果の統計データの相関を解析した結果の一例である。病体のヒートマップ１３３は、特定の疾病（疾患）について、その疾病の進行段階毎に、用意することができる。

図７に、超健康体のヒートマップ１３１、未病のヒートマップ１３２および病体のヒートマップ１３３の各状態のヒートマップを並べて配置している。現状、各状態に含まれる患者の数に差があるため、各ヒートマップに含まれる散布図の測定値の数にばらつきがあり、各状態を示すヒートマップとしては完全ではない。しかしながら、各状態で、強い相関が認められる検査項目に増減があり、各状態で、多数の検査項目間の相関をまとめたヒートマップ（静的マトリクス）１３０が異なることがわかる。したがって、これらのヒートマップ１３０を、各患者の検査データ１１に含まれる多数の検査項目間の関係と、これらのヒートマップ１３０とを比較することにより、各患者の検査時における状態を推定することができる。

なお、検査項目間の関係の一例は、２次元の関係のマトリクスであり、多数の検査項目の数値のうち、異なる２つの検査項目の数値をＸ座標およびＹ座標としたプロットした図を、ヒートマップに対応して２次元に配置したものである。多数の検査項目の数値を、多数の検査項目のそれぞれを座標とする多次元の位置（関係）で示してもよい。

超健康体から病体まで、以下のような各状態のヒートマップ（静的マトリクス）１３０を用意することが可能である。
レベル０：超健康体
健康体の中で、現在知られている疾患リスクの兆候が全く無い人を指す。所謂、超健康体、スーパーノーマルと言われる人で、人間ドック受診者の数パーセントしかいないという統計がある。
レベル１：未病の始まり／健康体予備軍
超健康体と比較して、標準偏差値が４５〜５０の範囲にあって、疾患を示すマーカー物質や入力値の組み合わせが１つ以上検出されている場合を示す。但し、レベル２には該当しない場合をレベル１とする。
レベル２：未病の進行開始／非健康状態
標準偏差値が４０〜５０の範囲にあり、疾患を示すマーカー物質や入力値の組み合わせが、２つ以上検出されている場合。レベル１・３では無い。
レベル３：未病の代表的位置／疾患リスクの顕在化
標準偏差値が３５〜４５の範囲にあり、疾患を示すマーカー物質や入力値の組み合わせが、３つ以上検出されている場合。レベル４では無い。
レベル４：未病の要注意状態／疾患リスク注意
標準偏差値が３０〜４０の範囲にあり、疾患を示すマーカー物質や入力値の組み合わせが、４つ以上検出されている場合。可能であれば、一度、医療機関で精密検査を受けた方が良いかも知れません。レベル５では、無い。
レベル５：未病から疾患への明確な移行期／疾患リスク警告
標準偏差値２０〜３５の範囲にあり、疾患を示すマーカー物質や入力値の組み合わせが、５つ以上検出されている場合。特定の疾患または合併症だと医療機関で指摘される危険領域に進んでいる可能性がある。急いで、精密検査を受けた方が良い領域に入っている。

図８に、ヒートマップ１３０に含まれる各散布図１３９の相関を確率分布でも示した例を示している。各散布図１３９に、統計的な確率（標準偏差）の異なる領域を、等高線を用いて示している。本願の発明者により、散布図１３９にまとめられた２つの検査項目の検査データの相関が１つの正規分布で表現できるケースと、複数の正規分布の混合として表現することが必要なケースとが見出されている。相関が複数の正規分布の混合として示される場合は、それらの正規分布が１対１で混合されていてもよく、異なる比で混合されていてもよい。検査項目間の相関を確率分布で表現することにより、後述するように、各患者の検査項目間の関係を画像化するフィルターとしてヒートマップ１３０を使用することができる。また、統計データの数が少ないときにレプリカから統計的に意味がある数のサンプルを仮想的に生成して、ヒートマップ１３０を生成したり、ヒートマップ１３０の散布図１３９の一部あるいは全部を補充してもよい。

図９に、ベクトル付きヒートマップ１４０の一例を示している。このベクトル付きヒートマップ（ベクトルマップ）１４０は、動的マトリクスの一例であり、病体（非正常）のヒートマップ１４３に含まれる１つのベクトル付き散布図１４９を示している。図９に示した散布図１４９は、検査項目のうちの、総コレステロール値（ＴＣ）と、低比重リボ蛋白質（ＮＤ ＬＤＬ）との相関を示したものである。動的マトリクスの一例であるベクトルマップ１４０は、各状態のヒートマップ（静的マトリクス）１３０の間の多数の相関の変位を含み、患者が含まれる母集団の経時的な状態の変化を反映したものである。本例のベクトルマップ１４０は、相関の変位を、散布図１４９に、方向と量とを矢印（ベクトル）で示したものである。

図１０に、各状態のヒートマップ１３０の総コレステロール値（ＴＣ）と低比重リボ蛋白質（ＮＤ ＬＤＬ）と相関（散布図）１３９を示している。図１０（ａ）は超健康体、図１０（ｂ）は未病、図１０（ｃ）は病体の散布図１３９を示す。図１１（ａ）に、総コレステロール値（ＴＣ）の測定値の各状態における分布を示し、図１１（ｂ）に、低比重リボ蛋白質（ＮＤ ＬＤＬ）の測定値の各状態における分布を示している。図１１（ａ）および（ｂ）に示すように、超健康体の分布１３５は低いピークのカーブを示し、病体の分布１３７は高いピークのカーブを示し、未病の分布１３６はそれらの間になる。したがって、図１０（ａ）〜（ｃ）に示すように、総コレステロール値（ＴＣ）と低比重リボ蛋白質（ＮＤ ＬＤＬ）と相関は、超健康体のヒートマップ１３１の散布図１３９の相関がほとんど見られない状態から、未病のヒートマップ１３２の散布図１３９の相関が表れる状態を経て、病体のヒートマップ１３３の散布図１３９の高い相関がみられる状態に、散布図のプロットが移動する。

このため、前回の検査結果が得られた第１の時点から時間が経過した次回の検査結果の第２の時点における多数の検査項目間の相関をベクトルマップ１４０として捉えることにより、患者の状態を推定することができる。したがって、ヒートマップ１３０から推定され状態を、ベクトルマップ１４０から推定される状態と比較することにより、動的に推移する状態を含めて推定できる。このため、ヒートマップ１３０およびベクトルマップ１４０を用いた推定を行うことにより、診断対象のシステムの内部状態を、より精度の高い確率で、時間経過を含めて推定できる。

図１２に、ヒートマップ１３０に含まれる個別マトリクス１７０の一例を示している。この個別マトリクス１７０は、個別マトリクス１７０に含まれる検査項目間の関係として、中性脂肪（ＴＧ）とＨＲＬコレステロール（ＨＤＬ）との関係を示している。例として、３人の患者の関係をプロットしており、患者Ａの測定値（関係）は相関が低い（確率が低い）位置であるので面積の小さなドット１７１で表示される。一方、患者Ｃの測定値は、相関の中心１７９に近い、相関が高い（確率が高い）位置であるので面積の大きなドット１７３で表示される。患者Ｂの測定値は、相関が中間（確率が中間）の位置であるので、面積が中間のドット１７２で表示される。したがって、例えば、患者Ａの第１回目の検査結果は、各状態のヒートマップ１３０をフィルターとして、位置が共通し、面積が異なる多数のドットからなる画像を含む複数の個別マトリクス１７０に変換される。患者が異なり、同一の患者でも検査結果が異なれば、多数のドットの位置が異なり、各ドットの面積も異なる。したがって、各患者の各検査で、各状態で異なる画像を備えた個別マトリクス１７０が生成される。ＡＩエンジン２１の学習モジュール２１０は、個別マトリクス１７０に含まれる画像を、画像認識処理することにより、患者の検査結果に対応する状態を推定することを学習できる。学習が進むと、ＡＩエンジン２１は、過去の多数の患者の同様の画像と比較して、患者の現在の状態の推定することができる。

各個人の測定データは、図１２に示すように、ヒートマップ（未病レベル３）に対して、いくつか違った等高線上（似た傾向を示す人達の位置と重ねた場所を示す）にある。これを最も多い中心（２軸の平均値:標準偏差値 ５０：５０）からのユークリッド距離に比例させて、そのドットの大きさや色（輝度）をフィルタリングして表示する様にしてもよい。ＡＩエンジン２１は、その代表的な中心に近ければ、大きなサイズのドットとして認識し、そこから離れていれば、小さなサイズのドットとして認識する。ＸＹ軸（２軸）という事で、それぞれ違った大きさの２つドットでの表現を、特徴を示すパターンとして最終的には認識されようにしているが、ドットの表現は、上述したように、色や輝度であってもよい。他の表現としては、例えば、（sizeＴＧ, sizeＨＤＬ）としてベクトル量として扱う等が考えられる。その場合でも、中心からのユークリッド距離に合わせて、ドットのサイズを変えることで、明確にその相関の中でのポジションを示すことで、強調処理を施してＡＩエンジン２１の判定が容易になる様に準備してもよい。ベクトルマップ１４０については、ベクトルが、ベクトルマップの密度の低い個所（レアケース）に位置する場合はベクトル量を小さくし、密度の高い個所に位置する場合はベクトル量を大きくして強調してもよい。多数のベクトルまたはドットの位置が異なり、各ベクトルの大きさも異なるベクトルマップ１４０を画像としてＡＩエンジン２１が学習し、動的な状態の推移を推定するようにしてもよい。

図２に戻って、相関処理モジュール２７は、モジュール（ブロック）２７５ａにおいて、入力される検査データ１１に含まれる計測した項目についての閾値の判定を行う。具体的には、個別のユーザに対して、検査データ１１の各項目が外部定義ファイル２７１ａ〜２７１ｃに指定している基準値及びカットオフ値を超えているのかどうかを判定する。超健康体の分散・平均を保持するＤＢ２７１ｂは、これまで集めたユーザ／被験者のデータ及び外部のＤＢにあるデータを用いて超健康体に関しての各データについての統計指標が保持される。超健康体のデータは、健康体／未病レベル１を詳細に分析して、疾患リスクの予測推定を行う場合に重要となる。それは、病体データや未病のグループのデータを使う場合に比べて、より正確で精度の高い予想を可能とするからである。

未病の分散・平均を保持するＤＢ２７１ａは、これまで集めたユーザ／被験者のデータ及び外部のＤＢにあるデータを用いて未病のグループに関しての各データについての統計指標が保持される。未病は、未病レベル１〜未病レベル５と分散も広くその目的に応じてグループを変える事も想定した疾患リスクや健康度の予測推定を進める様に準備する。病体の分散・平均を保持するＤＢ２７１ｃは、これまで集めたユーザ／被験者のデータ及び外部のＤＢにあるデータを用いて病体に関しての各データについての統計指標が保持される。外部定義ファイルのデータ更新期限指示ファイル２７２を含んでいてもよい。

さらに、モジュール２７５ｂにおいて、計測した項目の統計指標のクラスタリングを行う。個別のユーザに対して各入力データの閾値の判定結果で、超健康体・未病・病体のクラスタリングを行う。超健康体は基準値を外れた項目が一つ以下である。未病は超健康体と病体の間にある。未病レベル１〜未病レベル５、病体はカットオフ／異常値を超える項目が５つ以上であると定義する。次に、モジュール２７５ｃにおいて、ユーザのデータを用いた統計指標の計算を行う。外部のＤＢに保持されている複数のユーザの各データ（血液データ、尿データ、バイタルデータ、自律神経レベル、問診、その他の検査データ）について、クラスタリング対象ごとに各項目について正規分布と対数分布のどちらの確率モデルを用いるかを外部定義ファイルで指定して統計指標の計算を行い、それぞれを超健康体の分散・平均を保持するＤＢ２７１ａ、未病の分散・平均を保持するＤＢ２７１ｂ、病体の分散・平均を保持するＤＢ２７１ｃとして保存する。

さらに、モジュール２７３において、疲労・睡眠・運動／ストレスについて判定する。未病レベル１〜５で、疲労・睡眠・運動・ストレスは、免疫活性に非常に高い相関がある事が知られていることから、被験者／ユーザのデータから統計指標を計算して、更に、疲労・睡眠・運動・ストレスの項目から、免疫系の活性度や今後の疾患リスクとそのパス、健康へと回復する可能性を計算する。

また、モジュール２７４において、免疫系・その他／生活パターンについて判定する。免疫レベルをそれぞれ単独で、疲労・睡眠・運動・ストレスから推定する事とは別に、生活パターンを解析・分析する事で、疾患リスク及び疾患へとシフト／遷移する時間や時期、或いは、健康体へと回復する可能性を予測・推定する。

上記のプロセスと並列に、モジュール２７６ａにおいて、ヒートマップの位置相関と特定する。未病グループのデータを使って、ユーザ／被験者のデータが、現在どの位置に相当するかを特定する。また、相関処理としては、今後、疾患パスのどの方向へシフト／遷移する可能性があるのかを予測推定する。ただし、疾患リスクがどの程度の期間でという時間的な分析・解析はしない。ベクトルマップでこれは実行する。次にモジュール２７６ｂにおいて、ヒートマップから疾患パス候補をアップする。未病グループのデータを使って、ユーザ／被験者のデータが、現在どの位置に相当するかを特定して、将来の疾患リスクの可能性・危険性の候補を上げる。さらに、モジュール２７６ｃにおいて、 ヒートマップから疾患パスとリスクを判断する。リストアップされた疾患パスの候補について、そのリスクの度合いをいくつかの疾患に絞った解析と予測推定を実行する。

さらに、上記のプロセスと並列に、モジュール２７７ａにおいて、ベクトルマップの位置相関と特定する。未病グループのデータを使って、ユーザ／被験者のデータが、現在どの位置に相当するかを特定する。また、相関処理としては、今後、疾患パスのどの方向へシフト／遷移する危険性があるのかを予測推定する。続いて、モジュール２７７ｂにおいて、ベクトルマップから疾患移行予測情報を生成する。ベクトルマップには、免疫レベルの情報が一部内在していることもあり、ユーザ／被験者のデータから、今後の疾患移行予測を推定することが可能となる。さらに、モジュール２７７ｃにおいて、ベクトルマップから疾患リスク予測順位を生成する。ヒートマップ情報とベクトルマップからは、疾患リスクへのシフト／遷移を予測して、過去のユーザ／被験者のデータがあれば、疾患リスクは、前段の疾患移行時間と合わせてそのリスク順位を推定する。

これらのプロセスの後、モジュール２７８において、対推論エンジン／対ＡＩエンジン出力処理を行う。推論エンジン２２への出力は、対象となるユーザ／被験者のポジションを、統計処理をベースにして特定するのと免疫レベル（活性度）をベースにして、疾患リスクや健康回復の数値的な情報を準備してもよい。ヒートマップやベクトルマップの生成と比較から疾患リスクとして遷移／シフトする時間も推定する様に準備してもよい。ＡＩエンジン２１への出力は、ヒートマップとベクトルマップが中心となり、免疫レベルの情報は、ベクトルマップの中に取り込まれていることにしてもよい。

４．２ ＡＩエンジン
人工知能、“ＡＩ”は、従来の手続き型プログラミング言語では難しかったアプリケーション領域に応用可能な事例が多く見られる様になり、その成果もあって最近注目される様になった。現在期待されている”ＡＩ”の適用アプリケーション領域は、言語処理・画像処理・音声処理・制御技術・最適化と推論の５つで付加価値の高い実装が公開される様になった。ＡＩは、現在、ある程度のレベルには達していて、今後、高性能化へと向かうと期待されている。ＡＩエンジン２１には、現在および今後開発されるいずれのタイプの人工知能であっても適用できる。現在開発されている主なＡＩエンジンの種類とその特徴は以下の通りである。

ＳＶＭは教師データ間のマージンが最大になる場所で分類する。般化能力が高いが主成分分析を用いた次元削減により特徴量を設計してもよい。決定木は教師データを分割するときに最も平均情報量が大きくなる特徴量を用いて分類する。入力と出力の因果関係がわかりやすいが、主成分分析を用いた次元削減により特徴量の設計をしてもよい。Ｋ近傍分類器は入力データの近くにあるＫ個の教師データラベルの多数決で分類する。新しい教師データを分類器に適応させるのが容易であるが、入力データを分類する計算量が、教師データが増えるごとに増加する傾向がある。階層型ニューラルネットワークは、教師データから、特徴量などをバックプロパゲーションで学習して分類する。教師データから、バックプロパゲーションを用いて特徴量を自動で学習するが、入力層に近づくほど、勾配が消失して学習が難しくなる傾向がある。深層学習は、教師データから、特徴量などを自己復号化器で学習して分類する。教師データから、自己復号化器を用いて特徴量を自動で学習するが、入力と出力の因果関係の説明は特に表れない。

強化学習（例：Ｑ−Ｌｅａｒｎｉｎｇ）は、ある状態におけるエージェントの行動に対して報酬を与えることで最適な行動を学習する。報酬の与え方によって、エージェントに学習させる行動を変更可能であり、報酬の設計によって最適な行動を学習させることができる。教師なし学習（例：Ｋ−ｍｅａｎｓ）は、構造が不明なデータに対しクラスタリングを実施する。教師データがない状況でデータ間の類似度に基づいてクラスタリング可能であり、データ群がクラスタリングされた理由は、必要であれば人間が考えてもよい。

診断支援エンジン２０のＡＩエンジン２１に適しているＡＩの１つは深層学習である。深層学習を用いた手法は、画像認識の分野において、非常に有用な結果を残している。この性能を診断支援エンジン２０に応用することが望ましく、精度の高いＡＩエンジン２１を提供できる。ＡＩエンジン２１は、例えば２〜３週間単位での継続的測定を実施して健康度解析を進める。２〜３ヶ月または６ヶ月、１年間の継続的測定と健康度の解析で予測推論の確度が明確になる。診断精度向上のポイントは、最適化エンジン２４の自己予測精度向上（メタ・モデル記述ファイルに初期条件として与えられた相関から、差分データの相関を調べてヒューリステックに予測推論精度を上げる）、１〜数回の追試（追加の精密測定と問診）、２〜３週間毎に実行して経時変化をトレースして検証を行う３つとなる。また、性能指標としては、入力データ量に対するスループット及びターンアラウンドタイムを重視した設計としてもよい。特に、ビッグデータ解析として、最終的に１０〜１００万件のトランザクションを数時間〜数日以内で処理を保証可能なシステム構成として、1つの入力データの処理が、数分程度で完了する程度の能力を備えていてもよい。ＡＩエンジン２１の予測・推定の精度は、医者が行う場合と比較して、誤差が１０％未満で重大な見落としが無いレベルにすることが可能であり、さらに、９５％程度の信頼性を認めてもらえるような予測推論を実現することが可能である。

図１３に、支援エンジン２０におけるＡＩエンジン２１の学習イメージを示している。支援エンジン２０は、推論エンジン２２およびＡＩエンジン２１が検査データ１１に基づいて診断対象のシステムの内部状態を推定する基本システム４０と、ＡＩエンジン２１の学習システム３０とを含んでもよい。学習システム３０は、ユーザデータ（実データ）である検査データ（入力データ）１１を教師データ（学習データ）３５とするパスと、レプリカ生成モジュール（レプリカジェネレータ）１９により生成されるレプリカ１３を学習データ３５とするパスとを含む。レプリカジェネレータ１９は、最適化エンジン２４の指示にしたがい、実データである検査データ１１では不足する量および範囲のレプリカ１３を生成してＡＩエンジン２１の学習を促進させる。すなわち、この支援エンジン２０の制御方法は、検証モジュール２３により検証された、ＡＩエンジン２１により推定された状態の精度に基づいて、レプリカ生成モジュール１９に対しレプリカの最適化方針を提供することを含む。

検証エンジン２３は推論エンジン２２の推定結果の精度と、ＡＩエンジン２１の推定結果の精度とを検証して、エンジン精度ＤＢ（データベース）１６に格納する。最終決定判定モジュール２８は、予測精度の高い方の推定結果を出力データ１２として出力する。最終決定判定モジュール２８は、ＡＩエンジン２１の推定結果の精度が推論エンジン２２の推定結果の精度を下回る状態が継続している間は、推論エンジン２２の推定結果を優先して出力し、ＡＩエンジン２１の推定結果の精度が推論エンジン２２の推定結果の精度を上回る状態が継続するようになればＡＩエンジン２１の推定結果を優先して出力するモジュールあるいは論理を備えていてもよい。

４．３ 推論エンジン
図１４に推論エンジン２２のさらに詳しい構成を示している。推論エンジン２２を構成するメタ・モデルの情報として、記述ファイル１４は、推論を実行させるための評価関数式や、生成されたレプリカのバリエーションを絞り込むための情報を含んでいてもよい。また、入力される検査データ１１に関してもプリプロセッシングするルールを、入出力相関テーブル記述ファイル１５に設定しておいてもよい。推論エンジン２２は、レプリカを生成したり、入力データ・問診から内部状態を推論してもよい。

レプリカはレプリカ生成モジュール１９も生成する。レプリカ生成モジュール１９は、独立してレプリカ生成を実行する機能を持つが診断支援エンジン２０の最適化エンジン２４の指定で、レプリカ生成のバリエーションを変更することが可能である。レプリカ生成モジュール１９は、主に統計データとレプリカの生成比率指定テーブルをベースに実行するが、予測機能を持たない構造であってもよい。レプリカ生成モジュール１９は、指定された内容の入力レプリカ・内部レプリカ・再生入力レプリカを生成するのが主要な機能となる。レプリカ生成は、入力データ（測定データと問診・他）からそれらの情報から得られる範囲で想定されるレプリカをある一定範囲でそれらのレプリカ生成を行う点が、推論エンジン２２とは異なる部分であってもよい。

推論エンジン２２は、生成されたレプリカや入力データ・問診から推論を実行する。推論エンジン２２は、相関テーブル１５、過去の履歴２２１、テンソル量、メディカルドクターからのアドバイス情報を参考にしながら、推定された状態の絞込を行い、複数の可能性についての推論の候補を作り出してもよい。問診では、ＤＮＡデータを使用せずに遺伝的な問題が無いかをＱ＆Ａで調べる様な手法も取り入れてこれを行ってもよい。例えば、自分の家族・親戚に膵臓疾患者が家族にいる場合は、膵臓疾患の可能性はそうで無い場合よりも高く推論あるいは予測されるように、推論エンジン２２のルールを設定してもよい。また、過去に免疫系の機能が弱いと想像される問診を回答している場合は、その高熱経験や疾病からの回復期間を考慮して免疫活性率について推論・予測されるように、推論エンジン２２のルールを設定してもよい。

推論エンジン２２に実装されるルール（予測モデル）は、内部レプリカのバリエーションと再生成された複数の入力レプリカを比較する評価関数で定義されてもよい。推論エンジン２２の推論ルールが、検証エンジン２３の結果を入れて、最適化エンジン２４へとフィードバックされてもよい。ＡＩエンジン２１が学習する学習モデルに、このフィードバックから最適化の方法が含まれてもよい。推論エンジン２２に実装されるルールの１つは、入力データ（実測値＋入力レプリカ）１１と、内部レプリカとから再生成された複数の再生成入力レプリカとの差分を分散（数値：σ）で比較して、一番、少ない差の候補を、検査対象のシステムの内部状態を示す内部レプリカとして正しい候補とするものであってもよい。複数の内部レプリカが示す複数の内部状態を数値化して確率として複数候補を提示してもよい。内部状態には、超健康、未病、病気、腫瘍、癌、疾病などが含まれてもよい。

すなわち、推論エンジン２２は、入力データ１１と統計データから内部状態の仮説として、内部レプリカの候補を複数生成してもよい。

推論エンジン２２は、レプリカジェネレータ１９が生成した複数の候補と、データ間の相関や、地域性、年齢、病歴などの詳細なデータから、入力データ１１を再生成してもよい。推論エンジン２２側では、レプリカジェネレータ１９が生成した複数個の内部レプリカ１３ｂに対して、詳細なデータを用いて、どの内部レプリカ１３ｂがより実態に近いのかを推測してもよい。推論エンジン２２は、内部構成部品の活性度や不良・不具合の推論結果を検証エンジン２３へと渡してもよい。

推論エンジン２２の主な動作に以下の３つが含まれていてもよい。
１つ目は、外部テーブルを元に入力データ１１から臓器の状態を推論する部分である。
２つ目は、推論した臓器（内部レプリカ）の状態から再度入力データ（再生成レプリカ）の推論を行う部分である。
３つ目は、推論した入力データ（再生成レプリカ）から、実際の入力データ及びレプリカデータを元に精度の高そうな入力データを決定し、内部レプリカを再評価する部分である。

推論エンジン２２は、入力データ１１から臓器の状態を推論する部分では、以下に示す様式に従った外部テーブル１４および１５を参照して推論を行ってもよい。推論を行う際のルールとして、指標と臓器の状態（活性度・不良・異常）が１対１で対応している場合（１対１モデル）、１対Ｎ（１対Ｎモデル）で対応している場合、Ｍ対Ｎモデル（合併症含む）の場合の３つを考慮してもよい。

異常と特定可能なマーカー物質が１つ確定するとこれに対応する内部要素（内部構成部品：臓器・他）が１つ対応する１対１モデルの場合は、１つの指標さえわかれば臓器の状態が推定可能であるから、臓器に関連付けられた指標を上から順番に対応（該当）するラベルを探索して決定してもよい。

異常と推定されるマーカー物質が１つ以上存在している場合で、これに対応する内部要素（内部構成部品：臓器・他）が１つ以上ある場合、１対Ｎモデル／Ｍ対Ｎモデルの場合は、外部相関テーブル１５に記述してある各指標に対しての重みを参照して、複数の指標を考慮した形で臓器の状態をそれぞれ個別に推定してもよい。合併症の場合など、判断が困難な推定は後から実装してもよい。また、複数の候補が存在する場合、各マーカー物質のそれぞれは、線形であると仮定して指標に対して係数だけ変化させる実装を採用してもよい。つまり、単純に、複数の不良要因があった場合、その症状により係数を掛けて加算する方式としてもよい。免疫その他のリカバリー要素が関係する場合は、それらのそれぞれに対して逆に係数の影響を独立して減らす様にしてもよい。結果的に、プラス係数とマイナス係数をそれぞれこれに関係する要因を独立してプラス・マイナスして、当面は、連立方程式を解く様な実装としてもよい。

次に、臓器の状態から再度、入力データの推論を行う部分に関しては、１対１モデルの場合は、外部テーブルを用いて、臓器の状態から、各指標の取り得る値を決める。

最後に、推論した入力データと実際のデータの比較を行う部分では、推論した入力データと実際のデータとの距離を比較して、各データとの距離の長さがもっとも短かった推論した入力データの上位５つを推論結果として、再度、入力レプリカの生成を行い、各入力データの上位５つと再生成した入力レプリカを出力として、検証エンジン２３に渡してもよい。

さらに詳しく推論エンジン２２の一例の構成を説明する。図１４に示したモジュール２２１０においては、増減マトリックス推定を行う。急増（急減）は、健康度を考えた場合には、急変する危険性があるサインと考えられる。個人の過去の測定データについては、経時変化を考えてその増減を考慮して、現在の検診データを補正・修正する。検診データの増減は、増減マトリクスとして、個人の過去の測定値をもとに増減をデータと日付のマトリクスとして定義する。推論エンジン２２としては、急激に悪化しているところを発見したいので、係数を用いて、２−３年前の過去のデータよりも２−３週間前の直近のデータの変化を考慮する必要がある。最終的には、マトリクスの増減だけを見れば推定が可能となる。

モジュール２２２０においては、現在値の健康度の推定を行う。相関データをもとにして、ルールベースで推定を行う。相関データ１５には、１対１や１対多の推定、多対多の推定があるので、各相関データにおいて推定手法を変更する必要がある。

様々な要因が検診データに対して影響を与えていると考えられるので、正しい推論を実施するには、補正をかける必要がある。補正には、補正テーブル２２２を用いる。補正テーブル２２２に関しては医者・専門医と作成してもよい。補正テーブル２２２の内容をもとに、検診データに対して、差分の加減、あるいは、補正係数をかけてもよい。補正方法は、内部構成要素を示すインデックスを選択することで、検診データに対して補正を行う方式としてもよい。内部インデックスを選択した場合に、記述テーブルに従って、インデックスが示す内容の補正を行うような実装を行ってもよい。

具体的には、モジュール２２２１において、問診その他補正を本人の自己申告により行ってもよい。疲労・睡眠などの自己申告（２２２２）、免疫系その他の自己申告（２２２３）などが含まれる。モジュール２２２４において、メディカルドクター、その他の補正を行い、主治医・医者や医療関係者からのフィードバックにより補正してもよい。モジュール２２２５において、感染症の補正をインタ−ネットや医療機関からの警告などにより行ってもよい。モジュール２２２６において、パンデミックの補正をインタ−ネットや医療機関からの警告などにより行ってもよい。

モジュール２２２７において、候補の正規化を行う。検査データ／入力データ１１の全ての検査値を、標準偏差として正規化してもよい。男性・女性年齢で、正規化を変えてもよい。企業や地域、都市、地方、国、環境条件によりこの標準偏差が変化してもよく、正規化はその目的により、対応を変えてもよい。

モジュール２２２８において、序列化を行う。序列化では、特に注意すべき疾患リスクのある臓器や健康維持に関係する部位はどこかを具体的に知るために、各臓器や部位に序列を与える。序列の与え方は、健康度が低い（疾患リスクの高い）臓器や部位について、降順に並べる手法を採用してもよい。

モジュール２２３０において、補正前のデータに対して逆推定データを生成してもよい。体内の臓器や部位の活性度に対して、レプリカジェネレータ１９は、入力データ／検査データ１１を逆推定して、その可能性をある範囲で算出する。１つの検査データ／入力データ１１は、必ずしも１つの臓器や部位に対して１対１に対応せずに複数の箇所と連携した数値となるケースが多くあるので、徐々（段階的）に逆推定データを補正してもよい。入力データ／検査データ１１の逆推定をした値をＲ（Ｒｅｖｅｒｓｅ、Ｒａ・Ｒｂ、Ｒｂは補正前の逆推定データ、Ｒａは補正後の逆推定データ）とする。逆推定では、検診データ１１と相関データ１５から推定した、各臓器と部位の健康度に対して、健康度（免疫レベルやストレス・疲労・睡眠・運動など）と相関データ１５を参考にして、入力データ／検査データ１１の逆推定を行ってもよい。

モジュール２２３１において、比較推定を行う。補正前の逆推定データと補正後の逆推定データに対して比較を行う。比較推定は、体内の個々の各臓器や部位に対して行う。比較推定の役割としては、補正した場合にレプリカジェネレータが算出するＲａ・Ｒｂ予測値との差分及びその許容値について、どの範囲で収まっているのかを確認することにある。この結果をもとに、補正をかける度合いも調整して、精度を向上させる。

モジュール２２３２において、絞り込み処理を行う。体内の臓器や部位に対して、疾患リスクの高い候補についての絞り込みを実行する。絞り込みの基準は、ズレが少なくて、陽性＋３レベルで、過去の差分を見たときに増加傾向にある臓器や部位、正常な人は０以上で、数値が低い場合の臓器や部位で、過去分との差分からその疾患リスクが増加しているものを上げてもよい。

モジュール２２５０において、推論決定処理を行う。推論決定処理の役割は、絞り込みまでやったものに対して出力処理を行う。具体的には、検証エンジンに対して、推論エンジン２２が生成したＩ（内部状態、内部レプリカ、または内部臓器および部品）とＲ（逆推定、再生成レプリカ）を渡す。他の処理に対して、なぜ、その推定を決定したのか、すなわち、推定の根拠に関する情報を出力してもよい。例えば、異常度が９０％の臓器が１０個あるが、その内の５個しか出力ができない場合には、推論決定処理の部分でどの臓器や部位を出力するのかを決定する。つまり、絞込み処理で絞り込めなかった場合には、推論決定処理で行ってもよい。具体的には、統計処理や、過去のデータ、遺伝との寒冷性を調べる意味で、家族や親族の疾患履歴を参照してもよい。検証エンジン２３に渡すデータは外部ファイルを経由せず、アプリケーション内部で直接、渡してしまう実装としてもよい。

モジュール２２６０において、履歴データベース（ＤＢ）２２１の更新を行う。個人の現在の入力データ／検査データを標準偏差値として、履歴ＤＢ２２１に登録して参照可能としてもよい。

さらに、推論エンジン２２は、モジュール２２６１において、ＱＶ−Ｓｃｏｒｅ（カテゴリ変数のスコアリング）の計算を行う。推論エンジン２２では疾患リスクと各臓器の健康度の算出をおこなってもよい。ＱＶ−Ｓｃｏｒｅは、バイオマーカ（バイナリ）から疾患リスクの推定を行う。特に、ユーザが記入した問診データから疾患リスクの推定をおこなってもよい。以下、各種の癌リスク（膵臓癌・肝臓癌・肺癌・大腸癌・その他）ごとに計算を実行してもよい。

モジュール２２６２にいて、ＣＶ−Ｓｃｏｒｅ（連続変数のスコアリング）の計算を行う。ＣＶ−Ｓｃｏｒｅは、疾患リスクの算出に用いられ、特に、ユーザのバイオマーカ（連続変数）から疾患リスクの推定を行う。以下、各種の癌リスク（膵臓癌・肝臓癌・肺癌・大腸癌・その他）ごとに計算してもよい。モジュール２２８１においては、ＣＶスコアとＱＶスコアとを所定の配分比率に基づいて換算し、疾病リスクを算出してもよい。

モジュール２２７１および２２７２においては、平均偏差・偏差値の計算を行う。疾患との関連性マトリックス（データと疾病（臓器）との関連付けを表す表）を元に、評価対象ついて関連している項目の偏差値を二乗し、重みづけをした上で、その和の平均を求める。個々の偏差値は必要に応じ、定義ファイルで重みづけが可能としてもよい。

モジュール２２８２において、健康度指標の計算を行う。平均偏差から健康度指標（ＨｅａｌｔｈＳｃｏｒｅ）への変換は以下の式を適用してもよい。式を以下に示す。
Ｈｅａｌｔｈ Ｓｃｏｒｅ＝１００−ＳＤｍｅａｎ×２５
ＳＤｍｅａｎ：平均偏差（評価対象に関連する項目の偏差を基に重みづけをした平均値）
Ｈｅａｌｔｈ Ｓｃｏｒｅ:計算値が０以下になる場合は、０に丸める。

さらにモジュール２２８３において、ヒートマップの解析と予測推定を行う。ヒートマップは、上述したように、入力データ（血液データ、尿データ、バイタルデータ、自律神経レベル、問診、その他の検査データ）の全てについて、ＸＹ相関（二軸の相関性を正規化して調べる）を計算して二次元に配置したものを示す。さらに、全てのＸＹ相関について、疾患リスク（赤系）と健康（青系）が明確になる様に、濃度差に反映して画像情報へと変換したものであってもよい。ＸＹ相関とするので、Ｘ側とＹ側のそれぞれの検査データに対しての赤と青の濃淡が反映された画像となり、一種の疾患リスク・健康状態を示す個人レベルでの画像となる。例えば、平均値に近い場合は、白系の色画像となる。実際は、赤・青・白の濃淡の混入状態の画像が、個人の健康度や疾患リスクに対応して作成される。

この画像を蓄積して、分類すると疾患リクス及び健康状態についての遷移マップが膨大に作成される。疾患リスクは、未病レベル５が最も疾患の顕在化リスクが高く、実際に具体的な疾患傾向が顕著になる。また、未病レベル４は、未病レベル５ヘシフトする手前となる。未病レベル３は、健康状態と疾患へと進行する途中にある。健康体に近いのが、未病レベル１であり未病レベル２は、未病レベル３ヘと遷移する途中となる。未病レベル１であっても、疾患リスクがある場合は、その傾向が赤系の濃淡で見える。疾患リスクの予測推定は、この健康度・疾患リスクの位置により、スタティック（変化量や動きは考慮しない）な位置を特定して、その位置から、今後、疾患リスクがどの方向へとシフト／遷移するリスクがあるのかを予測推定してもよい。

モジュール２２８４において、ベクトルマップの解析と予測推定を行う。ベクトルマップは、先に説明したように、自律神経レベルや疲労・ストレス・睡眠・運動などをベースから免疫レベル（免疫活性度を直接白血球／ＮＫ細胞・Ｂ細胞・Ｔ細胞・マクロファージの検査により決定する事も可）を考慮しながら、過去の入力データ／検査データ（偏差値）を時間変化として見て、変化量を疾患リスクへ向かうベクトルとして表現された図（マップ）である。被験者の入力データ／検査データ（偏差値）１１と一致するベクトルを探して、自分の現在の状態からどの様な疾患リスクへと向かう危険性があるのかを推定してもよい。或いは、逆に、回復して健康状態へと戻ろうとしているのかを予測推定してもよい。

４．４ 検証エンジン
図１５に、検証エンジン２３により実行される検証サイクル４５の概要を示している。推論エンジン２２およびＡＩエンジン２１の推定精度を、検証エンジン２３が要求する追試データまたは時間経過した患者や未病の人の健康状態により向上させてもよい。追試データは、メディカルドクターが指定するテストに従う。例えば、病気の可能性のある検査項目を実行する。但し、健康体と思われる場合は、複数実行しても結果は全て良好となる。

検証エンジン２３が推論エンジン２２およびＡＩエンジン２１の推定精度の評価に用いる評価モデル２３Ｍとしては、測定データ・問診表・統計データなどの検査データ１１と、内部レプリカ１３ｂから再生成した入力レプリカ１３ｃと差分を取り、その分散の最も優秀なものを選択してもよい。この評価モデル２３Ｍは、ＡＩエンジン２１がメインで動作する場合でも動作する。但し、複数の予測・推論候補があり、その差が少ない場合は、追加の測定を実行して、この結果を、評価モデル２３Ｍが考慮して再評価する。検証エンジン２３は、時間軸の過去で、過去に似た様なケースがあった場合、この過去の検証（ペンディング）で決定出来ない状況にあったものを再評価して決定させる機能を備えていてもよい。検証エンジン２３は、評価に問題がある場合（明確化が出来ないなど）、再度、疑いのある項目に関して、再度追加の問診を実施する機能を備えていてもよい。検証エンジン２３は、検証されたデータを元に、入力レプリカ生成方法・ＡＩエンジンの出力方法に変更を加える機能も備えていてもよい。

図１６に、検証エンジン２３のさらに詳し構成の一例を示している。検証エンジン２３は、モジュール２３１０において、推論エンジン２２およびＡＩエンジン２１の出力（状態を推定した値）について、評価モデル２３Ｍによる検証を行う。上述した評価モデル２３Ｍまたは外部に定義した評価モデル２３２を読み込むことにより、入力データ１１と推論エンジン２２またはＡＩエンジン２１の推論結果（推定結果）に対して検証を実施する。モジュール２３２０において、推定結果の曖昧性を判定する。検証結果を受け取った曖昧性判定モジュール２３２０は、検証結果を元に推論エンジン２２およびＡＩエンジン２１の推論結果の精度を図る。曖昧性判定モジュール２３２０では、評価モデルによる検証モジュールの結果からどのような点で曖昧性が残っているのかを判定してもよい。判定基準は外部定義ファイルである曖昧性判定基準ファイル２３３を参照してもよい。

精度が低い（曖昧性が高い）と判定された場合には、次の３つの追加での検証を行ってもよい。追加での検証内容は、より詳細な質問内容をユーザに回答してもらう追試（１）と、メディカルドクターに診断の依頼をする検査依頼（２）と、２週間の継続して検査を行う継続検査（３）とであってもよい。曖昧性判定モジュール２３２０では、（１）から順次、追加での検証を行っていき曖昧性がなくなった時点で検証結果決定モジュール２３８０に検証結果を渡してもよい。曖昧性判定モジュール２３２０は、どのような検証に対してどのような曖昧性判定をしたかの記録も検証結果決定モジュール２３８０に渡してもよい。

モジュール２３２１は、追試内容を決定する。追試内容決定モジュール２３２１では、曖昧性判定モジュール２３２０の判定を元にどのような追試内容を行うかを決定する。追試内容は外部定義ファイルである追試内容ファイル２３４を参照してもよい。モジュール２３２２は、追試実施を制御するモジュールであり、クラウドサービス（Ｐ−ＨＡＲＰ）側へ追試内容を送信する。クラウドサービス側では、追試実施モジュール（検証エンジン）２３２２から受けとった内容を元に追試の実施を行う。

モジュール２３２３は、メディカルドクタ（ＭＤ）の選定を行う。選択モジュール２３２３は、曖昧性判定モジュール２３２０の結果をもとにメディカルドクターに対して、追加の検査の依頼を行う。依頼先のＭＤは、外部定義ファイルであるＭＤファイル２３５を参照して判断してもよい。モジュール２３２４は、ＭＤへの調査依頼を制御する。検査依頼モジュール２３２４では、実際にＭＤファイル２３５に定義されているＭＤに対して検査依頼を行う。

モジュール２３２５は、継続検査ＤＢ２３２６への登録モジュール２３２５である。ＭＤへの検査依頼をしてもそれでも曖昧性が残る場合には、さらに２週間、継続して検査を行うために、継続検査ＤＢ２３２６へユーザを登録してもよい。継続検査ＤＢ２３２６へ登録されたユーザは、２週間の継続した検査結果を入力することになる。継続検査の途中で曖昧性がなくなればその時点で検査を終了し、継続検査ＤＢ２３２６からユーザを削除してもよい。

モジュール２３３１は、経過観察フラグを生成するモジュールである。２週間の継続した検査（継続検査）をおこなっても曖昧性が残った場合には経過観察フラグモジュール２３３１により経過観察フラグがつけられる。経過を定期的に観察することで、曖昧性がなくなるのかについての確認を行う。モジュール２３３２は、経過観察フラグモジュール２３３１において経過観察フラグがつけられたユーザを経過観察ＤＢへ登録する。経過観察結果モジュール２３３５は、定期的に経過を観察した結果、曖昧性がなくなるかどうかを確認する。曖昧性がなくなればその時点で経過の観察を中止し、経過観察ＤＢからユーザを削除してもよい。経過観察ＤＢおよび継続検査ＤＢは過去履歴ファイルＤＢ２３１に含まれていてもよい。

検証結果決定モジュール２３８０は、曖昧性判定モジュール２３２０が曖昧性がなくなったと判定した時点での結果を受け取る。評価モデルによる検証結果と曖昧性判定モジュール２３２０が受け取った入力データ及び検証内容と、それまでの曖昧性判定の記録を受け取り、評価モデルによる検証結果を最終決定判定モジュール２８に渡す。

検証結果決定モジュール２３８０は、検証内容と曖昧性判定の記録を過去の類似事象の探索モジュール２３８１に渡してもよい。過去の類似事象の探索モジュール２３８１では、検証内容と曖昧性判定の記録を元に類似の状態になっているユーザ（事象）が存在しないのかを経過観察ＤＢおよび継続検査ＤＢから確認する。経過観察ＤＢ及び継続検査ＤＢには、各ユーザの検証内容と曖昧性判定の記録が残されていることが望ましい。経過観察ＤＢ及び継続検査ＤＢに類似の状態になっているユーザが存在すれば、過去の類似事象への結果の反映モジュール２３８２へ類似ユーザと類似の検証内容と曖昧性判定の記録を渡す。過去の類似事象への結果の反映モジュール２３８２は、受け取った類似ユーザと類似の検証内容と曖昧性判定の記録を元にして、類似ユーザの曖昧性判定の前の評価モデルに対して結果の反映をして曖昧性判定の実施を行う。この時点で曖昧性がなくなれば、継続検査および経過観察を中止してもよい。

レプリカジェレータ出力方法変更モジュール２３８３は、検証結果と外部に定義されたファイルを基にしてレプリカ生成モジュール１９の出力方法を変更させてもよい。ＡＩエンジン出力方法変更モジュール２３８４は、検証結果と外部に定義されたファイルを基にしてＡＩエンジン２１の出力方法を変更させてもよい。

検証エンジン２３においては、検証結果決定モジュール２３８０により選択された推定結果およびその判断理由を最終判定・決定モジュール２８および最適化エンジン２４に提供してもよく、さらに、臓器の活性度・疾患リスクを判断してから推定結果などを提供してもよい。モジュール２３５０は、本人・医者の知見に基づき臓器等健康度再計算する。検証を行うためには、推論エンジン２２およびＡＩエンジン２１が予測するべき臓器の活性度・疾患リスクを求めておいてもよい。モジュール２３５０においては、医者が算出した臓器の活性度及び疾患リスクを、推論エンジン２２およびＡＩエンジン２１が予測するべき臓器の活性度・疾患リスクとして扱ってもよい。このモジュール２３５０では、ユーザからの入力されたデータ、感染情報２３６０およびパンデミック情報２３６１をもとに医者が臓器の活性度及び疾患リスクに関して計算をおこなってもよい。

検証エンジン２３は、最終決定・判定モジュール２８が推論エンジン２２およびＡＩエンジン２１のどちらの予測を用いるのかを決定するための情報を出力してもよい。推論各臓器の活性度現在過去の差分計算モジュール２３５１では、ユーザから入力されたデータに対して、本人・医者の知見・臓器等健康度再計算モジュール２３５０においての結果と推論エンジン２２およびＡＩエンジン２１の各予測結果の差分を計算し、その結果をＤＢ２３１に保持する。

推論各臓器の活性度現在過去の差分計算モジュールの結果は過去分もＤＢ２３１に保持されていてもよい。最終判定情報整理モジュール２３５２は、推論各臓器の活性度現在過去の差分計算モジュールの過去分の結果及び現在の結果から最終判定・決定モジュール２８で必要になる情報（現在の結果と過去の結果の平均値など）を計算する。

検証エンジン２３では、最適化に用いる情報を収集可能であれば収集してもよい。推論結果と過去比較モジュール２３５３は、現在の推論結果に関して過去の結果と比較を行い、情報（推論精度の推移など）を収集する。最適化情報出力モジュール２３５４では、推論結果と過去比較モジュールで収集した情報から最適化に用いる情報を最適化エンジン２４へ提供する。

このように、検証エンジン２３は、推論エンジン２２またはＡＩエンジン２１により推定された状態の曖昧性を判断するモジュール２３２０と、曖昧性により追加情報を外部から取得するモジュール２３２１〜２３２５とを含んでいることが望ましい。追加情報は、診断対象システムの診断専門家のフィードバック、経過観察、追加試験の結果の少なくともいずれかを含んでいることが望ましい。

４．５ 最適化エンジン
最適化エンジン２４の役割は、推論エンジン２２およびＡＩエンジン２１の推論精度を高める点にある。そのため、最適化エンジン２４は、検証エンジン２３の検証結果を元にして、レプリカジェネレータ１９に対して最適化を行う。最適化においては、微分ができない場合にどうするのかといった点や、局所解に陥らないようにするにはどうするかいった点が考慮されてもよい。最適化手法の一例は、ＧＡ（遺伝的アルゴリズム）、シミュレーテッドアニーリングなどである。数学的手法であってもよく、ラグランジュの未定乗数法、フーリエ級数のように係数を用いて近似を行ってもよい。実際の最適化手法については、メタ記述ファイル１４により指定される。

最適化のための情報は、スタティックな正規分布を含んでいてもよく、ベイズ推定を含んでいてもよい。時間方向と追試を元にベイズ推定を行って、修正を加えることで、誤差を減らしてもよい。予測するバリエーションをいくつか変えて、未来で予測値が決定された場合に、フィードバックをおこなってもよい。本当の未来を利用するのと、現在を未来と仮定して修正を実施してもよい。

４．６ 最終判定・決定モジュール
最終判定・決定モジュール２８は、推論エンジン２２や検証エンジン２３が検証した結果を元に、最終的な判定を下す。最終判定・決定の基準は、メタファイルとして、事前に作成しておき、最終判定・決定モジュール２８は、意思決定基準と検証結果を元に最終的な判定・決定を下してもよい。検証結果が、意思決定基準に従って、実データをよく反映できていると判定されれば、最終判定・決定モジュール２８は、検証結果を受け入れる。一方、検証結果が、意思決定基準に従って、実データを反映できていないと判定された場合や検証結果として複数の仮説が存在していると判定された場合には、最終判定・決定モジュール２８は検証エンジン２３側に、再検証を実施させる。

図１７に示すように、最終判定・決定モジュール２８は、ＡＩエンジン２１と推論エンジン２２の推論精度からどちらの推論を優先するのかといった決定を行う機能を含んでもよい。したがって、ＡＩエンジン２１と推論エンジン２２とを含む支援エンジン２０の制御方法としては、検証エンジン２３の検証結果により、推論エンジン２２により推定された状態を、ＡＩエンジン２１により推定された状態より優先して出力する段階ＳＴ１と、ＡＩエンジン２１により推定された状態を、推論エンジン２２により推定された状態より優先して出力する段階ＳＴ２とを含む。

図１８に、最終判定・決定モジュール２８の一例の構成を示している。検証結果精度判定モジュール２８４は、精度の決定方法について外部定義ファイル２８１を参照し、実際の検証結果を用いて検証結果についての精度の計算を行う。判定結果処理モジュール２８７は、ＡＩエンジン２１、推論エンジン２２それぞれの検証結果についての精度の比較を行う。それぞれに重みをつけて比較するなど、比較の仕方については、外部定義ファイルである意思決定基準ファイル２８１および重み決定ファイル２８２を参照してもよい。判定結果から、出力処理モジュール２９に出力するのか、検証エンジン２３に再検証させるかを、出力先変更定義ファイル２８３を参照して決めてもよい。判定結果保存モジュール２８８は、判定結果について外部のＤＢに保存する。

インターネットや医療機関・政府系・メディアから感染症情報２８５が流れた場合、これを取り込み疾患リスクの予測推定の最終判定の材料の１つとしてもよい。また、インターネットや医療機関・政府系・メディアからパンデミック情報２８６が流れた場合、これを取り込み疾患リスクの予測推定の最終判定の材料の１つとしてもよい。特に、広範囲にその拡散が見られる場合は、その情報を入れて反映する様にしてもよい。

４．７ 出力データ処理モジュール
図１９に、出力データ処理モジュール２９の処理概要を示す。出力データ処理モジュール２９では、予測結果を利用者に提示する際に、医療行為と間違われないようにするために表現方法等に修正を加えて、ＷＥＢサーバーに送信する機能を備えていてもよい。出力データの種類としては、音声情報・画像情報・テキスト情報があり、出力データ処理モジュール２９は、推論エンジン２２またはＡＩエンジン２１および最終決定モジュール２８の指示に従って、該当する出力情報テーブル２９０のインデックス情報をクラウドサービス（Ｐ−ＨＡＲＰ/Ｗｅｂサーバー）５０に依頼する方式であってもよい。メタ・モデルという性格から、このインデックス情報は、制御テーブルの出力側の規則に従った方式で、実現されてもよい。

４．８ レプリカ生成モジュール（レプリカジェネレータ）
図２０に、レプリカ生成モジュール１９の構成の一例を示している。モジュール１９１０は、サンプル処理および統計的特徴量の抽出を行う。このモジュール１９１０は、最初に、サンプル処理／特徴量抽出により、レプリカ生成が対象とする入力データ／検査データを確認する処置をスタートする。このモジュール１９１０の処理は、前処理であってもよい、レプリカ制御ファイル１９１より、どの様な性質のレプリカ生成を実行するのかという指示と合わせてレプリカ生成の方向付けを行う。レプリカ制御ファイル１９１を通して、最適化エンジン２４は、予測精度向上のためのレプリカ生成制御を実現してもよい。レプリカ制御ファイル１９１およびモデルファイル１９２に明確な指示の記述が無ければ、統計的特徴量抽出を、モジュール１９１０を通して行い、ＸＹ相関情報のあるレプリカ生成確率密度からその拘束条件の範囲で、レプリカ生成を実行する準備を行ってもよい。

モジュール１９１１は、混合正規分布解析および１〜Ｎの重ね合わせを行う。入力データ／検査データ１１の数量が膨大に多くなるとその増加に応じて、大数の法則／中心極限定理に従って正規分布に従うことは、統計学として公知である。しかしながら、検査データ１１の数が十分で無い場合、サンプルがあるグループに限定されている場合、また、統計的特徴量を入力データ／検査データ１１の全部でＸＹ相関を取る場合などにおいては、必ずしも正規分布が明確に表れないことがある。特に、ＸＹ相関を取る場合に、統計的な特徴量を確率密度や分散を複数の正規分布が重ね合わさって構成される二次元的な分布として解析をする解析手法を導入してもよい。これにより正の相関や負の相関、また、複数の大小の正規分布が合成された様な二次元的な特徴を拘束条件として、乱数を使って、その特徴量に合う様な合成をする解析を実行してもよい。これは、１つの正規分布で単純に解析可能な場合もあり、ＸＹ相関データによっては、２〜Ｎへと複数の大小の正規分布が重なった形がその統計データの特徴となる場合もあり、これらの解析をこのモジュール１９１１で実行してもよい。

モジュール１９１２は、分散・確率密度、および相関と拘束条件といった特徴量を求める処理を行う。統計データの特徴量として、確率密度と分散（平均・代表値など）があり、全ての入力データ／検査データ１１のＸＹ相関を調べることで、明確に正の相関や負の相関を見つけることが可能となる。求められた特徴量および拘束条件は、レプリカ生成を実行する場合の拘束条件として機能させてもよい。単純なルール、例えば、正規分布だけを仮定して、確率密度もこれに従った形でレプリカ生成を実行してもよい。しかしながら、実際のデータとは、乖離したレプリカが生成される可能性が高い。例えば、人間の体を１つのシステムと考えた場合、１つの臓器や部位に問題が発生すると、それに関係する入力データ／検査データ１１は、あるまとまったグループ同士が関連して数値が悪くなったり良くなったりすることが認められる。このため、１つ１つのデータ（検査データ１１に含まれる各パラメータの値）は、独立している訳では無く、関係性を持っていることが多い。それら複数のパラメータの値の増減をマトリックス化することにより、関係性が表れることがあり、そのような場合には、統計的な特徴量を維持した形でのレプリカ生成を行うことが望ましい。このモジュール１９１２はそのための準備処理を行ってもよい。

モジュール１９１５は、レプリカデータ（Ｘ、Ｉ、Ｒ／Ｇｒ）を生成する。モジュール１９１５は、入力データ／検査データ１１をベースに、疑似入力データ・複製データ（Ｘ：測定データ、入力レプリカ）、そのインプット情報に対応する内部の臓器や部位の活性度（Ｉ:内部レプリカ）、さらに、その内部のＩ値を見て再度、再生成される疑似複製データ（Ｒ:再生レプリカ、再生成レプリカ）を生成する。生成されたレプリカはレプリカファイル１９３に格納されてもよい。

この支援エンジン２０において、学習システム３０は、現在知り得ている情報から、ある仮定をして実際のデータと一連の予測推定を通して得られるデータとの差を比較することにより、その補正を行うことが可能となるパスを提供する機能を含む。人工知能（学習モジュール２１０およびＡＩモジュール２１）は、膨大なデータから潜在的ルールを予測推定してその精度を上げることに貢献する。学習システム３０は、予測推定を検証可能なパスとして機能し、複雑なシステムの解析を自律的に、あるいは自己学習により進めることを可能とする。現在の医療システムにおいて、体内の部位や臓器と入力データ／検査データ１１との関係を単純な形で解析できない。レプリカを用いた学習システム３０は、複雑なシステムに対し、それを部品として観測して疾患との関係を推定する仕組みに非常に似た構造を入れることが可能であり、複雑なシステムが疾患に対してどのように対応しているかの内部状態を追跡しやすくできる。モジュール１９１５は、疾患リスクが見え始めると、そのグループＧｒ.レベル（疾患グループ）で拘束されるパラメータ変動をリンクさせてレプリカを生成することにより、さらに、疾患リスクの予測推定精度をアップさせることに貢献してもよい。

モジュール１９２０は、ヒートマップ相関（ヒートマップ）１９４、特に、正の相関について、スケーリング（疾患に対して）処理を行う。ヒートマップ１９４は、ＸＹ相関を全ての入力データ／検査データ１１のパラメータに対して散布図などにより示したものであり、さらに、標準偏差からその疾患傾向や健康の強弱を赤系と青系の濃度差、また、平均に近い場合は無色の白色として、そのパターンから健康位置や疾患リスクのポジションを決定する手段を提供している。正の相関がある場合、例えば、レプリカ生成を１桁〜２桁増加させてもよい。増加傾向と増加した場合の数値がどうなるかという条件を追加する形で、レプリカ生成を行ってもよく、実際にサンプル数が増加した場合の一致精度を上げることが確認された。サンプルデータ数が限定されている中で、スケールさせる数をランダムに選択して、それをある比率で拡大しながら外挿してもよい。誤差は存在するが、スケールしない場合に比較してその一致精度は格段に高くなる。例えば、３００サンプルの母集団の平均をランダムに、２０、４０、７０、１００、１３０と選んだ得た平均を外挿して算出したラインと、実際の測定済みの母集団サンプルとはよく一致することが判明した。確率密度・分布の傾向に関しても外挿が有効となる。ただし、明確な相関があるデータに限定される。

モジュール１９２１は、ヒートマップ相関１９４、特に負の相関について、スケーリング（疾患に対して）処理を行う。負の相関に関しても、正の相関と同様であり、スケーリングを行う場合は、同様な手法で外挿することができ、予測精度をアップさせることが可能となる。

モジュール１９２２は、ヒートマップ相関１９４のミキシング・混合を行う。ヒートマップを利用して、入力データ／検査データ１１のレプリカ生成をスケーリングして実行する際に、疾患の罹患率や出現頻度を参照しながらこれらを混成・混合させてもよい。

モジュール１９３０は、ベクトルマップ相関（ベクトルマップ）１９５、特に正の相関のスケーリング（疾患に対して）を行う。ベクトルマップ１９５は、自律神経レベルや疲労・ストレス・睡眠・運動などをベースから免疫レベル（免疫活性度を直接白血球／ＮＫ細胞・Ｂ細胞・Ｔ細胞・マクロファージの検査により決定する事も可）を考慮しながら、過去の入力データ／検査データ（偏差値）を時間変化として見て、変化量を疾患リスクへ向かうベクトルとして表現する図（マップ）である。モジュール１９３０は、ベクトルマップ１９５に、疾患リスクおよび時間方向で、正の相関があれば、それを考慮した形で、ベクトルマップの拡大を行う。被験者の入力データ／検査データ（偏差値）と一致するベクトルを探して、自分の現在の状態からどの様な疾患リスクへと向かう危険性があるのかを推定して、拡大させるファクターの数を増加させてもよい。

モジュール１９３１は、ベクトルマップ相関１９５、特に負の相関のスケーリング（疾患に対して）を行う。ベクトルマップ１９５が負の相関にある場合は、健康側への相関が強くあることを示している。これは、回復して健康状態へと戻ろうとしているのかを予測推定して、拡大させるファクターの数を増加させてもよい。

モジュール１９３２は、ベクトルマップ相関１９５のミキシング・混合を行う。ベクトルマップ１９５を利用して、入力データ／検査データのレプリカ生成をスケーリングして実行する場合に、疾患の罹患率や出現頻度を参照しながらこれらを混成・混合させる処理を行ってもよい。

モジュール１９５０は、ヒートマップ１９４、ベクトルマップ１９５による得られる拘束を外さない範囲で、レプリカデータを疾病リスク対応の入力レプリカＸｎ、疾病リスク対応の内部レプリカＩｎ、疾病リスク対応の再生成レプリカＲｎに拡大して生成してもよい。モジュール１９６０は、学習データとなるレプリカデータ１３を出力する。モジュール１９６０は、実測データＡ、測定レプリカ（入力レプリカ）Ｘ、内部レプリカＩおよび再生成レプリカＲを出力してもよい。

５． クラウドサービス（Ｐ−ＨＡＲＰ：Precision Health Analysis Research Platform）
図２１に、本願の出願人が提供するクラウドサービス（Ｐ−ＨＡＲＰ）５０の概要を示している。Ｐ−ＨＡＲＰ５０は、乳癌や膵臓癌・腎臓癌（腎不全）・その他疾病の入力データや相関性を学習している診断支援エンジン２０および診断支援エンジン（ＡＸｉＲエンジン）２０を含む診断支援システム１０と、専門家５１による意思決定チームを形成できるクラウド上のプラットフォームである。Ｐ−ＨＡＲＰ５０においては、ＡＩユニフォーム５５と呼ばれるＡＩスーツ・ＡＩシェルを通して、ＡＩプロトコルが可能とする他のＡＩ５８やアプリケーションであれば、Ｐ−ＨＡＲＰ５０に接続された他のメンバーとの間で共通のインターフェースおよびＡＰＩが提供され、自由または適当に制限されたコミュニケーションが可能となる。

Ｐ−ＨＡＲＰ５０は、複数の診断支援エンジン２０とヘルスケアの専門（メディカルドクター、ＭＤ）５１、スポンサー５２、評価検証最適化ユニット５３および管理ユニット５４を含み、これらの構成要員がイントラネットまたはインターネットなどのコンピュータネットワーク５９で接続される拡張性の高いクラウド上のグローバルプラットフォームである。Ｐ−ＨＡＲＰ５０においては、複数の同一または異なる専門分野のＡＩエンジン５８の接続を容易にする為に、ＡＩユニフォーム（ＡＩシェル・ＡＩスーツ）５５と呼ばれる共通化ＩＦを通して診断エンジン２０および他の構成要員（メンバー）が接続される。

例えば、糖尿病患者や腎臓の機能に不安があるメンバー（スポンサー）５２が、Ｐ−ＨＡＲＰ５０にメンバー登録をして、自分の血糖値・ＨｂＡ１ｃやクレアチン値を入力すると、問診や血液データ、尿データの情報入力を要求される。そしてメンバー５２からの要望・希望があれば、これに関する分析・解析の情報を提供する。また、健康の維持や改善についてのヘルスケア情報やサービスについては、その関心のあるカテゴリーに対してアドバイス情報をシェア可能となる。

有償会員（スポンサー、メンバ）５２に対しては、ある一定期間のヘルスケア情報サービスを提供することで、その個人が良好な状態へと進んでいるのか、逆に、悪い方向へと進んでいるのかの情報とアドバイスは行うことが可能である。ただし、原則、健康状態を保証するものでは無い事と擬陽性・偽陰性という問題が常にあるので、最終的には専門医や病院での相談をお願いするアドバイスとなってもよい。

Ｐ−ＨＡＲＰ５０は、ローカル性を持たせてもよい。この場合、個人情報（ログイン名で個人特定は不要）を可能な限り排除してもよい。本人の主な活動エリア（生活圏・居住区・職場・学校）を入力して貰うことで、感染症、インフルエンザやその他に対しての広がりを把握することが可能となる。したがって、Ｐ−ＨＡＲＰ５０により、疫病や感染症の拡大を予測したり、早めの対策を取る事が可能となる。つまり、Ｐ−ＨＡＲＰ５０により複数のメンバー５２、診断支援エンジン２０などを接続することにより、社会的には、地位的な感染の拡大状況をリアルタイムで把握して、予測する事が可能となる。すなわち、Ｐ−ＨＡＲＰ５０により、１つの個体情報が、社会全体のプロテクションとして機能する事に貢献するシステムを提供できる。

図２２に示すように、Ｐ−ＨＡＲＰ５０は、さらに、複数の診断支援エンジン２０が違った視点で推論を進める共同作業の場を提供するスタジアムとしての機能を含んでもよい。これは、人間社会で言えば、総合病院や裁判所の様に、患者や被告人がいて、専門医や医療スタッフ・医療設備、弁護士や検察・判事・裁判官（警察）が参加して問題解決を進めるという、この治療やその量刑を決定・実行したりする場所に近い概念で、多数の参加者により診断対象物に対する診断をより高い精度で行うためのスタジアムとして機能してもよい。つまり、役割分担された複数の診断エンジン２０と専門のメディカルドクター５１がＰ−ＨＡＲＰ５０に参加して予測精度・推測精度を上げる事を実現することが可能である。

Ｐ−ＨＡＲＰ５０は、異なるＡＩ間のインターフェイスをＡＩプロトコルとして提供し、人間とのインターフェースを実現する機能としてＡＩゲートウェイを提供する。実世界（ＲｅａｌＷｏｒｌｄ）のメンバー各自は、ネットワーク上（インターネットまたはイントラネット）で、自分のヘルスケア情報を仮想現実（ＶＲ：Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）の中のアバター（Ａｖａｔａｒ）にマッピング可能である。この中では、実世界とのリンクを仮定したり利用したりする事が自由に出来る。専門のメディカルドクターのチームは、事前に登録された協力メンバーや実世界のヘルスケアデータをベースに、その健康度や疾病リスクの予測をアバタに対して、個人やグループに対して実施する。また、トレースや追加の検査・チェックを個人やグループの希望があれば実施する。

メンバー５２は、サービスの提供を受ける個人あるいは団体だけではなく、スポンサー企業であってもよい。スポンサー企業は、ＶＲの中でアイテムを提供しても良いしＲＷの中でこれを要求や希望に応じて実行しても良く、Ｐ−ＨＡＲＰ５０により集積される実験データなどを解析し、それぞれ１つの参考値として公開しても良く、集積されるビッグデータを解析することにより新たなビジネスを探ってもよく、メンバー５２に追加の情報を提供するビジネスをおこなってもよい。これらは、Ｐ−ＨＡＲＰ５０に接続されるメンバー５２が、個人データが利用可能な状況が発生するとある合意されたインセンティブと交換される場合があることを意味する。

図２３に示すように、Ｐ−ＨＡＲＰ５０は、複数の専門性のある診断支援エンジン２０および専門家（医者や研究者）５１、エンジニア、当事者などが、クラウドを介して意見交換や情報交換を行い、ビッグデータ解析を進めながら、全体の予測精度を向上させてワールドワイドに利用可能な高精度測定ヘルスケア解析研究プラットフォームを提供してもよい。診断支援エンジン２０の検証エンジン２３はＰ−ＨＡＲＰ５０を通して、メディカルドクター５１の判断を確認可能となる。また、検証エンジン２３は、診断結果が微妙なケースで、例えば、未病状態にあり、病気の発病前で進行が遅い場合は、通常の方法（測定入力データ１回による予測）では、その予測推定の検証確認が難しい場合が想定される。この場合は、検証エンジン２３は、Ｐ−ＨＡＲＰ５０を介して経過観察をＰ−ＨＡＲＰ５０に接続された医師、病院などに依頼することも可能となる。検証エンジン２３はＰ−ＨＡＲＰ５０を介して予め用意された手順に従って追試を行うようにしてもよい。

Ｐ−ＨＡＲＰ５０と診断支援エンジン２０および診断支援システム１０とは、相互に接続可能で通信という意味では対称である。例えば、複数のＮ：Ｍ接続が可能という意味で、上位・下位の概念は無い。Ｐ−ＨＡＲＰ５０は図２３に示すように、複数であっても良く、地域・国・感染症を防ぐ境界・その他の単位でグルーピングしてもよく、単一でカバーするようにしても良い。１つのＰ−ＨＡＲＰ５０は、複数の診断支援エンジン２０または診断支援システム１０を接続してもよく、人間の専門家５１を入れても良い。接続される複数の診断支援エンジン２０は、異なる入力データと学習により、違った専門性を持ち異なる視点を持つ違う推論能力のエンジンであってもよい。Ｐ−ＨＡＲＰ５０は、ハードウェア規模に応じて診断支援エンジン２０の接続数がスケールしてもよい。

また、Ｐ−ＨＡＲＰ５０は、スポンサー単位で形成されてもよい。ビジネスモデルを制限しない様に、それぞれのスポンサーの設計自由度やビジネスの実装が、最大となる構造を許すように構築できる。例えば、チケット発行やユーザー募集、運用方法は、これを所有し管理する所有者の考えるビジネスモデルにより決定する。インターフェース条件は、原則、ＴＣＰ／ＩＰプロトコルと呼ばれるインターネット接続方式をベースに構築できるする。但し、アクシオンリサーチ社のＡＩプロトコルとＡＩゲートウェイに従う方式を採用する。将来的には、ハードウェアセキュリティを採用したより高度なサービスと一般的なサービスが、所有者・管理者を通して提供される可能性がある。

すなわち、Ｐ−ＨＡＲＰ５０は、Ｐ−Ｈｅａｌｔｈ Ａｎａｌｙｓｉｓ Ｒｅｓｅａｒｃｈ Ｐｌａｔｆｏｒｍの略で、ヘルスケア向けに開発されたプラットフォームを指す。Ｐ−ＨＡＲＰ５０は、ＡＸｉＲＥｎｇｉｎｅと称される診断支援エンジン２０（診断支援システム１０）や、他のＡＩ、専門家やユーザー・パートナー・メンバー・スポンサーが、相互接続する場を提供し、複雑なシステムの現在状態・活性度・不調度・不具合・異常・緊急事態・暴走等などに対して、解析を行い予測・推論するサービスを提供する。Ｐ−ＨＡＲＰ５０は、その所有者・管理者の制御を前提に、インターネット上に存在し、専門性と経験則を使って、これへの接続及びコミュニケーションが許さているアプリケーションを通して、診断支援エンジン２０およびその他が相互接続されるシステム・プラットフォームを指す。また、他のＰ−ＨＡＲＰ５０との接続する機能も実装する。自然言語処理、音声処理、ＡＩユニフォーム（ＡＩシェル・ＡＩスーツ）と呼ばれるゲートウェイ等を用いてＰ−ＨＡＲＰ５０は、外部にあるＷａｔｓｏｎやその他のＡＩを利用できる。

上記においては、第１の診断対象物の診断を行う推論エンジン２２と、前記推論エンジンと並列に設けられた人工知能２１と、入力データ１１に対する前記推論エンジンの診断結果と人工知能の診断結果とに対して前記人工知能を教育するための前記入力データ１１のレプリカを生成する教育システム３０とを有するハイブリッドシステム２０が開示されている。ハイブリッドシステム２０は、教育開始直後においては、前記推論エンジン２２の診断結果を優先して当該ハイブリッドシステム２０の診断結果または診断支援結果として優先し、前記人工知能２１の診断結果の精度が前記推論エンジン２２の診断結果の精度を上回ると、前記人工知能２１の診断結果を当該ハイブリッドシステム２０の診断結果として優先して出力する最終判定・決定モジュール２８を有してもよい。前記教育システム３０は、前記推論エンジン２２の診断結果と前記人工知能２１の診断結果とを検証する検証エンジン２３と、前記検証エンジンの検証結果に基づいて入力データのレプリカの最適化方針を生成する最適化エンジン２４と、前記入力データ１１および前記最適化エンジン２４の指示に基づいて前記入力データ１１のレプリカ１３を生成するレプリカ生成モジュール１９とを含んでもよい。

前記レプリカ生成モジュール１９は、入力データの第１のレプリカと、前記第１の診断対象物の状態を示す第２のレプリカと、前記第２のレプリカの変化範囲から逆に推定した入力データのレプリカとなる第３のレプリカとを生成してもよい。前記検証エンジン２３は、前記推論エンジン２２の診断結果および前記人工知能２１の診断結果の検証が困難であると判断すると、前記第１の診断対象物の診断専門家のアドバイスおよび／または経過観察を要求する機能を含んでもよい。前記推論エンジン２２の診断結果または前記人工知能２１の診断結果を、デジタルアバタの状態として出力する出力モジュール２９を有してもよい。

また、少なくとも１つのハイブリッドシステム２０と、前記第１の診断対象物の診断専門家の端末とがクラウドにより接続されており、前記少なくとも１つのハイブリッドシステムの診断結果が前記クラウドを介して参照されるクラウドシステム５０が開示されている。クラウドシステム５０には、前記第１の診断対象物の診断専門家の端末５１と、前記第１の診断対象物の経過観察が可能な機関５２とがクラウドにより接続されており、前記少なくとも１つのハイブリッドシステムの前記検証エンジン２３は、前記クラウドを介して前記診断専門家のアドバイスおよび／または前記経過観察をオーダーするようにしてもよい。

上記におけるポイントの第１は、人命に関係する重大な発見があった場合に、これを最優先に記憶する様な機構を実装することである。致命的な事象とは外的な要因と内部的な要因をカバーしたものである。システムとしての致命的な発見があった場合に、これを最優先させる機構が追加される。ヘルスケアの場合は、癌化や感染症、生命の維持や健康状態を良好に保つ事に困難を伴う様な事象や兆候のシェアと警告、この原因と相関を調べて診断エンジン２０及びＰ−ＨＡＲＰ５０に蓄積してシェアを進める機能が実装される。複雑なシステムや系で、同様に、システム維持や個体の維持に困難を伴う事象（イベント）に対する兆候のシェアと警告は重要な機能となるので、組み入れる。

上記におけるポイントの第２は、緊急対応必要な事象（イベントや突発的経時変化など）についてである。２４時間監視やモニタリング（連続計測）する場合に、緊急対応を要求する事態が発生した場合に、その前後関係、特に、その時点で不明であっても解析を要するデータは、保持しておきその後のデータ解析に利用する。また、上記第１のポイントと同じ意味で、緊急性が高い場合は、被害を最少とする手続きの実行に入る事を実装する。これは、監視の機能を超えて、具体的に、システムの停止や緊急措置の発動を伴う様な事も含める。

上記におけるポイントの第３は、自己最適化（自己学習）である。最適化エンジン２４は、検証エンジン２３の結果からＡＩエンジン２１の推論（予測）精度を上げる様にレプリカジェネレータ１９を制御する。メタ・モデルの記述ファイル１４にある評価関数と検証データとの差分（誤差）が少なくなる様に調整を進める。ＡＩエンジン２１の場合は、実測データ・追加精密検査結果（入力）から学習を進めるが、問診データやレプリカデータにより学習を加速させる事が出来る。

上記におけるポイントの第４は、外部のＡＩを利用する発想や視点である。音声認識技術、文献や文章の作成技術、論文解析技術、会話（通訳）機能などを含み、Ｗａｔｓｏｎの様な、外部ＡＩの成果を利用可能とするＡＩシェルインターフェースやＡＩプロトコルを含む。人間の専門家を入れた場合、ＡＩゲートウェイがカバーする。

上記におけるポイントの第５は、推論エンジン２２とＡＩエンジン２１の切り替えである。これらの２つをスイッチングして、自己学習する機構はＡＩエンジン２１を短時間で教育できる機構として重要である。このスイッチは、後戻りしてもよい。

上記におけるポイントの第６は、ＯＰＥＮ／ＣＬＯＳＥのシステムの暴走(異常)を防ぐことである。システムが、ＯＰＥＮで運用される場合とＣＬＯＳＥで運用される場合に、その制御や外部からのアクセスが可能な様に、ＶＰＮ的な内部へのホットラインを含む。診断エンジン２０とＡＩスーツは、正常動作を保証するタイマー／ＨＷのセキュリティ・リング方式認証トレースＳＷを実装しており、ＰｒｉｍａｒｙＭａｓｔｅｒとＳｅｃｏｎｄａｒｙ Ｍａｓｔｅｒが各メンバー状況を決められたＡＩプロトコルに従ってそのプロファイルを定期的に確認する。これが、一定期間そのアクティビティと貢献・反応が確認されなければ、全体のセキュリティ・リングから遮断されて内部へのアクセスが不可能となる。デジタルアバタのＶＲのサイバー空間移動では、この移動の実行に別のＫｅｙの交換が必要となり、移動の自由度はあるがトレースが残る方式となる。

上記におけるポイントの第７は、判定処理を過去の傾向と未来傾向から類推することである。動的に専門家との対話を通して類推することを含む。検証エンジン２３が、検証可能なケースとペンディングにするケースの扱いとして、追加試験、経過観察を行う（オーダーする）機能を持つ。追試の精密検査という方法と経時変化を利用して、１〜２週間単位でグレーゾーン対象者／ペンディング対象者が、どの状態へと進んでいるのかという観点から、追試の精密検査を実施して、これを何回か繰り返す事で、全体の中で不明確な対象者数を減らすことができる。

なお、以上においては、診断支援の対象システムが人体の例を説明しているが、診断支援の対象は人体に限らず、他のシステム、特に多数の要素を含む複雑系であってもよく、プラント、エンジンなどのメカトロニクスであってもよく、金融・投資などのサービスであってもよく、ゲームであってもよく、他のビッグデータが伴うシステムであってもよい。

Claims (16)

1. 対象システムの内部状態を推定する支援システムであって、
   モジュールのセットを有し、前記モジュールのセットは、
   前記対象システムに関する第１の検査データに基づいて、予め定められた少なくとも１つのルールにしたがって推定された前記対象システムの第１の推定された状態を出力するように構成された推論モジュールと、
   前記第１の検査データおよび前記第１の推定された状態に基づき、前記対象システムの状態を推定することを学習するように構成された学習モジュールを含み、第２の検査データに対して前記対象システムの第２の推定された状態を出力するように構成された人工知能モジュールと、
   前記推論モジュールにより推定された状態と、前記人工知能モジュールにより推定された状態との精度を検証するように構成された検証モジュールと、
   検証モジュールの検証結果により前記推論モジュールにより推定された状態と前記人工知能モジュールにより推定された状態との優先順位を切り替えて出力する判定モジュールと、
   前記学習モジュールの学習用として前記対象システムの検査データのレプリカを生成するように構成されたレプリカ生成モジュールと、
   前記検証モジュールにより検証された、前記人工知能モジュールにより推定された状態の精度に基づいて、前記レプリカ生成モジュールに対し前記レプリカの最適化方針を提供するように構成された最適化モジュールとを含む、支援システム。
2. 請求項１において、
   前記レプリカ生成モジュールは、前記対象システムの検査データに含まれる複数のパラメータの値の実分布を反映した前記レプリカを生成するモジュールを含む、支援システム。
3. 請求項１または２において、
   前記レプリカ生成モジュールは、前記対象システムの内部状態を示す内部レプリカと、前記内部レプリカの変化範囲から逆に推定した検査データのレプリカとを生成するモジュールを含む、支援システム。
4. 対象システムの内部状態を推定する支援システムであって、
   モジュールのセットを有し、前記モジュールのセットは、
   前記対象システムに関する第１の検査データに基づいて、予め定められた少なくとも１つのルールにしたがって推定された前記対象システムの第１の推定された状態を出力するように構成された推論モジュールと、
   前記第１の検査データおよび前記第１の推定された状態に基づき、前記対象システムの状態を推定することを学習するように構成された学習モジュールを含み、第２の検査データに対して前記対象システムの第２の推定された状態を出力するように構成された人工知能モジュールと、
   前記推論モジュールにより推定された状態と、前記人工知能モジュールにより推定された状態との精度を検証するように構成された検証モジュールと、
   検証モジュールの検証結果により前記推論モジュールにより推定された状態と前記人工知能モジュールにより推定された状態との優先順位を切り替えて出力する判定モジュールと、
   前記学習モジュールの学習用として前記対象システムの検査データのレプリカを生成するように構成されたレプリカ生成モジュールとを含み、
   前記レプリカ生成モジュールは、前記対象システムの検査データに含まれる複数のパラメータの値の実分布を反映した前記レプリカを生成するモジュールを含む、支援システム。
5. 対象システムの内部状態を推定する支援システムであって、
   モジュールのセットを有し、前記モジュールのセットは、
   前記対象システムに関する第１の検査データに基づいて、予め定められた少なくとも１つのルールにしたがって推定された前記対象システムの第１の推定された状態を出力するように構成された推論モジュールと、
   前記第１の検査データおよび前記第１の推定された状態に基づき、前記対象システムの状態を推定することを学習するように構成された学習モジュールを含み、第２の検査データに対して前記対象システムの第２の推定された状態を出力するように構成された人工知能モジュールと、
   前記推論モジュールにより推定された状態と、前記人工知能モジュールにより推定された状態との精度を検証するように構成された検証モジュールと、
   検証モジュールの検証結果により前記推論モジュールにより推定された状態と前記人工知能モジュールにより推定された状態との優先順位を切り替えて出力する判定モジュールと、
   前記学習モジュールの学習用として前記対象システムの検査データのレプリカを生成するように構成されたレプリカ生成モジュールとを含み、
   前記レプリカ生成モジュールは、前記対象システムの内部状態を示す内部レプリカと、前記内部レプリカの変化範囲から逆に推定した検査データのレプリカとを生成するモジュールを含む、支援システム。
6. 請求項１ないし５のいずれかにおいて、
   前記モジュールのセットは、さらに、
   前記対象システムの検査データを予め定められたルールにより前処理して前記推論モジュールおよび前記人工知能モジュールに入力される検査データに変換するように構成された入力処理モジュールを含む、支援システム。
7. 請求項６において、
   前記入力処理モジュールは、前記検査データに含まれる各パラメータ同士の相関を示すマップを生成するモジュールを含む、支援システム。
8. 請求項１ないし７のいずれかにおいて、
   前記検証モジュールは、前記推論モジュールまたは前記人工知能モジュールにより推定された状態の曖昧性を判断するモジュールと、
   曖昧性により追加情報を外部から取得するモジュールとを含む、支援システム。
9. 請求項８において、
   前記追加情報は、前記対象システムの診断専門家のフィードバック、経過観察、追加試験の結果の少なくともいずれかを含む、支援システム。
10. 請求項１ないし９のいずれかにおいて、
    前記モジュールのセットは、さらに、
    前記判定モジュールにより選択された前記推定された状態を前記対象システムの診断情報として出力するモジュールを含む、支援システム。
11. 請求項１ないし１０のいずれかにおいて、
    前記対象システムは人体である、支援システム。
12. 請求項１ないし１１のいずれかにおいて、さらに、
    前記モジュールのセットをプログラムとして格納するメモリと、
    前記メモリに格納された前記プログラムをロードして実行するプロセッサとを有する、支援システム。
13. 請求項１ないし１２のいずれかに記載の少なくとも１つの支援システムと、
    前記対象システムの診断専門家の端末とがクラウドにより接続されており、前記少なくとも１つの支援システムの出力が前記クラウドを介して参照される、クラウドシステム。
14. 請求項９に記載の少なくとも１つの支援システムと、
    前記対象システムの診断専門家の端末と、
    前記対象システムの経過観察が可能な機関とがクラウドにより接続されており、前記少なくとも１つの支援システムの前記検証モジュールは、前記クラウドを介して前記診断専門家のアドバイスまたは前記経過観察をオーダーする、クラウドシステム。
15. 請求項１ないし１２のいずれかに記載の支援システムとして、コンピュータを機能させる命令を有するプログラム。
16. 対象システムの内部状態を推定する支援システムの制御方法であって、
    前記支援システムは、前記対象システムに関する第１の検査データに基づいて、予め定められた少なくとも１つのルールにしたがって推定された前記対象システムの第１の推定された状態を出力するように構成された推論モジュールと、
    前記第１の検査データおよび前記第１の推定された状態に基づき、前記対象システムの状態を推定することを学習するように構成された学習モジュールを含み、第２の検査データに対して前記対象システムの第２の推定された状態を出力するように構成された人工知能モジュールと、
    前記推論モジュールにより推定された状態と、前記人工知能モジュールにより推定された状態との精度を検証するように構成された検証モジュールと、
    前記学習モジュールの学習用として前記対象システムの検査データのレプリカを生成するように構成されたレプリカ生成モジュールとを含み、
    当該制御方法は、
    前記推論モジュールにより推定された状態を、前記人工知能モジュールにより推定された状態より優先して出力することと、
    前記人工知能モジュールにより推定された状態を、前記推論モジュールにより推定された状態より優先して出力することと、
    前記検証モジュールにより検証された、前記人工知能モジュールにより推定された状態の精度に基づいて、前記レプリカ生成モジュールに対し前記レプリカの最適化方針を提供することとを含む、制御方法。