【第９章 情報爆発からのデータ活用】72 : 情報爆発をコントロールし活用する属性データの意味
ダッソー・システムズの工藤です。前回記事では、モデルの種類、評価性能の種類、組合せ種類が増えていくという想定と例をお見せして、シミュレーション世界における情報爆発が進んでいるということと、それらを属性情報化して管理しないと再利用できないことをお話ししました。今回は、なぜそうした管理が重要なのかをかいつまんでお話ししましょう。
まず、KDDという用語で何を思い出しますか？auの前身の国際電信電話会社の名前でしょうか？あるいは、感と経験と度胸の略(KKD)と混同して思い出すでしょうか？AIの世界で有名な1996年発行の下記の論文があって、Knowledge Discovery in Databases (KDD)という言葉が、ポピュラーになっています。KDDという名前のコンファレンスもあります。
From Data Mining to Knowledge Discovery in Databases (PDF)
この論文で示されている有名な図があって、下記にも掲載されています。
Knowledge Discovery in Databases (KDD)
この図によれば、生のデータから知識（Knowledge）に辿りつくためには段階的な手順が必要で、データ選択、前処理、データ変換、データ・マイニング、解釈を経て、知識として活用できるとされています。昨今のAIのプロセスには必ずこうした手順が含まれているはずです。上記の手順を粗く４ステップにし、シミュレーション・データ活用に適用してみたのが、下記の手順になります。
（１）蓄積：データを系統立てて管理し、瞬時に検索ができる管理状態を実現するステップ
すべての履歴データは、いつ、だれが、どこを、どうした、なぜ、結果、判断といった属性情報群やパラメータや接続され、トレーサビリティ可能なデータの集合体として蓄積
（２）収集：大量の元情報から必要な情報を検索し、抽出するステップ
どのような情報を得たいかという意図を与えながら、データを絞り込んで収集を行う。最大値や最小値の設定、制約条件や特定の条件での探索、最適設計探索も広い意味での絞り込みの例。次のステップでの分析を行うためのデータ一式を集める段取りを担う。
（３）分析：絞り込んだ設計空間と解空間の関係性を分析するステップ
設計意図を持って、データを個別ではなく集合体として、多様な視点で分析する。サンプリングの全体特性であれば、寄与度（パレート図）を見る、回帰分析をして、解空間の挙動を可視化するなど。多目的解集合は、強い意図で絞り込まれた設計-解空間なので特別なパターンが見られることが多い。データの意味を思考しながらの操作であることが重要。
（４）知識：設計知見を獲得するステップ
製品の性能設計に関する履歴情報が十分に集まり、設計意図通りのデータが絞り込まれ、分析手順が確立されてくれば、その手法と結果が、組織の設計知見となる。誰しもここを目標にしたいはずです。
（３）の分析や（４）の知識にたどり着きたいのですが、分析や知識化に用いる”シミュレーション情報”とは、どんな情報であればいいのでしょうか？一般論では、フムフムと頷かれたかもしれませんが、どんな分析や知識化を望んでいるのかを想定しておかないことには、どんな情報を収集しておくべきかもわからないのです。闇雲にデータさえあれば、何かありがたい知識が出てくるわけではないのです。言い直すと、”情報爆発”状態の混乱したデータの集まりからは何も生まれてきません。制御された情報集合を取り扱う必要があります。そこで、蓄積と収集に立ち戻ってみましょう。
一つの指針として、5W1H（にRを加えました）で表現されるようなデータ集合を考えてみます。あくまで整理するためですので、下記に限られるわけではありません。重要なのは、IT用語では属性と呼ばれるこれら一連のタグ/ラベル情報を、生成した元データとしっかりと紐づかせるということです。
① いつ（When)
何をするにも、時間は重要な情報です。日付時間的な情報だけではなく、設計プロセスの中のどのフェーズかという属性情報を得ておけば、たとえば企画、基本設計、詳細設計、試験検証といった、各フェーズでの情報を速やかに切り分けて分析できます。また、問題が起こる頻度が、デザイン・レビューの初回か、あるいは最終段階といったどの段階で起きやすいかを見分けることもできます。業務の中での”いつ”的な属性は、改善指針を探るのに重要な意味を持ちます。
② 誰が（Who)
担当者のスキルや過去経験といったプロファイル情報とつなげることで、エンジニアの仕事の品質を定量的に把握し、適切な担当者に割り振ることができるようになるでしょう。あまりありがたくない分析かもしれませんが、本来ものづくりと言われている仕事は高度な技術スキルに基づくくものであって、ある意味職人芸的な技能差もあることを考えれば、シミュレーション・エンジニアの能力と結果も何等かの評価に曝されるようになることは、否めません。
③ 何を（What)
製品や部品とそれらのモデルを特定する属性データになります。製品コード、名称、仕向地、派生オプション、部品番号等々、企業が通常業務で取り扱っている情報は、製品種類を特定するための最初のカテゴリーになります。
④ どこを（Where）
シミュレーションの試行錯誤は、どこのどんなパラメータの値を変更したのかということに帰着できます。製品情報であればある部位の形、板厚、材料など、試験や加工条件であれば、温度、圧力、位置、速度等々、いわゆる入力側のパラメータ情報です。
⑤ なぜ（Why)
やはり、シミュレーションの試行錯誤を行う以上は、これまでの結果の何かに、設計上の条件を満足しない不具合が生じているのです。たとえば、重量未達、応力限界、温度高、圧力高、速度未達、種々の性能未達などです。これらの理由を属性として明記することで、シミュレーションがどんな課題解決のために使われているか、を把握することができるでしょう。
⑥ どのように（How)
どんな解析をどのプログラムを用いてどんな条件で計算したのかといった、シミュレーションの内容を特定する属性情報です。線形応力、大変形、材料非線形、振動、機構、空力、熱流体、電磁場、板成形、射出成型などといった多様な解析種類とそれを計算するプログラムと、定常/非定常、物理モデル、材料モデル、初期条件、規格情報など、シミュレーション業務を理解するのに必須の属性です。
⑦ 結果（Result)
結果はどうだったのか？なぜ（Why)と対で、着目している性能指標の値を取り込み、その結果がOK/NGどちらだったのか、その根拠は、顧客要求か、社内規定か、業界標準ルールか、といった比較元とその数値を明記することで、OK/NGとその理由を正しく分析することができます。
さて、上記の情報の出所は利用するアプリケーションやシステム化のされ方によりさまざまですが、業務で扱うデータのどこかには含まれているはずのものです。元データがどこにあり、個々の属性情報が、データ内のどこに記載されているかさえ特定できれば、自動収集が可能になります。技術的にはそれほど難しいことではありません。シミュレーション情報の”Sensor”機能と見ることもできます。さらに、自動収集と同時に、出所のデータとの紐付けを行うことで、検索や分析を行った際にその元データに速やかにたどりつくことができます。こうした属性情報の自動取得を行うには、これまでに何度も紹介した、Simulation Process & Data Management（SPDM）が役に立ちます。というか、必須の道具立てになります。シミュレーションのデータやモデルが属性情報と紐づけられることで、属性情報と関連している他のデータとの繋がりが分かるので、トレーサビリティもしっかりと確保されます。膨大なデータのトレーサビリティが確保されれば、”情報爆発”とみなされたデータ群は、分析に供することができる、しっかりと制御された構造化データの集まりになります。さて、ここまでの手順が、前述した蓄積と収集の段階となり、次の段階の分析と知識化に供される準備ができたことになります。この記事に関連して、以下の記事をお読みいただくとより技術的な関連性を理解いただけるでしょう。
第56回 : SPDM as Virtual Sensor – AI活用に向けたデータ蓄積
工藤はCAE分野で39年の経験を持つエキスパートとして、CAE開発・販売、HPC活用・マーケティング、最適設計・ロバスト設計市場開拓などを経験し、現在はシミュレーションを活用した設計業務改革コンサルと自身のノウハウ形式知化に取り組んでいます。