- その146： グラフ・データベース利用を考察する（2）
グラフ・データベースの利用、特に当該データをうまく管理・活用できるようにするためには、構成するオントロジー、モデルと語彙の管理が大切である点について前回の最後で触れました。その中でも（日本の）データモデル作成において余り重要視されているとは云えない関係性(グラフデータベース用語では「プロパティ」と呼ばれる事が多い）の精密な命名付与と・漏れ／重複のない管理が必要となります。更に英語語句での名称付与は、英語圏文化の成り立ちという点で取扱をし易いという特徴があるといえますが、日本語語句を用いる場合の名称付けには様々な工夫が必要になると考えておいた方が良いでしょう。これは検索言語の使い勝手にも影響します。
また、グラフ・データベースの基盤の中には、属性項目群を纏めてモデル化し管理可能なものが存在しますが、三つ組み(トリプレット)をベースにするアーキテクチャを採用している基盤の場合には属性項目の設計への取り入れ方を十分考慮に入れなければなりません。更にデータ読取り専門のモデルでなく、データ更新や追加を許す設計にする場合には、その更新手順等の十分な検討を行う必要があると云えます。簡単にいえば、三つ組み形式で表現されただけのLODデータは、基本的に表形式のデータが表頭項目と各行の集まりと考えられるため、集合的な意味や表同士の関係(結合キーの把握等)は、それぞれの表に現れる名称に頼らざるをえない形です。これを機械学習や推論技術で問題なく利用するにはモデル情報が不十分ということになるでしょう。
それを補う技術としてオントロジーといった概念世界の表現が必要とされるという訳です。いわば機械に概念の意図と構造を伝える手段としての位置付けがあるということです。勿論それは形式的な意味付けであり、本当の意味は人間が理解し判定するべきものと云えます。この辺りが機械利用の信頼性に関わる難しさともいえるでしょう。機械学習では、0～1の間の隙間を統計的に片寄せすると考える方が正しいのかもしれません。少し乱暴に語れば、ニューラルネットワーク(NN)のさまざまな技術は、その精度を上げるための手段であると考えることもできるでしょう。人間の判断に比べて幾ら精度が上がったと言っても、AIに百パーセント頼り切ることの危うさを忘れてはならないというのが現時点での筆者の考え方です。
グラフデータとオントロジーの話題から少々離れてしまいましたので、今回の話題に戻します。オントロジー設計に関していえば、実はその考え方はリレーショナルモデルやUMLモデルとそれ程大きく違うということではありません。基本的構造上の考え方においては類似しているため、リレーショナル型でのモデル構築に慣れた技術者に取っては、初めの用語や概念的な違いを乗り越えさえすれば、案外近寄り易い分野だともいえるでしょう。但しこれまでにも触れたように「精密さ」と一層の「概念指向」が要求される分野だということを心得ておく必要性があるでしょう。それを支えるツール技術としては、今後大きな改善が生まれる領域であるでしょう。この辺りは、グラフ利用の場面が増えることで次第に解決されることが期待されます。
(備考) グラフ技術に関連する話題は、これまで游悠レポート資料の中で扱っているため、興味ある方はそちらを参照下さい。
- （先頭に戻る)
- その145： グラフ・データベース利用を考察する（1）
グラフ・データベースが登場してから、既に20年以上の歴史がありますが筆者の認識では、ここ数年になって注目度が一段上がってきたように思われます。データの視覚的イメージを元にした表現形式としては以前から利用されてきましたが、アプリケーションによる利用技術としてはネットワーク型の関係分析、インターネット等での個物の距離や結合度の強さ把握と云った領域で暫く注目されていた技術であったと考えています。またリンクト・オープンデータ(LOD)のような記述的データ表現(主語、述語、目的語のトリプル)を利用したデータの共有、連携のような点に着目し、その中から特徴を見出そうという流れがあったように思われます。
更に注目度が向上してきたのは、ここ数年のAI人気が貢献していると云えるでしょう。グラフ表現技術の利用により、機械による大量データの取込み、そして意味表現の標準化と、そこから派生する意味取り・推論への連携といったことが高い精度で可能になりつつあるといった点だと思われます。ただこの推論品質の高いデータ利用を実現するには、単なるトリプル(三つ組み)表現データの大量集合というだけでなく、データの類似性、意味表現の高度化といった点をカバーする要求への対応性を上げる必要性に迫られることになります。これを行う技術がオントロジーを導入したモデル表現の取り入れになります。
このオントロジー表現の取り入れというのは、使用するデータがリレーショナル・データベースに存在するきちんと整理・モデル化されたテーブル表現をそのまま利用する範囲であれば、ある程度の精度で利用可能でしょう(リレーション情報が体系化された上できちんと設計し、DBMS内のスキーマとして構築されたという前提があります）。そうでない場合、データの品質、精度といったものが犠牲にされ、利用者の信頼感を維持するのが難しいといった状況を生むことになりかねません。この意味で、既存のデータベースのモデル化適用が当初から行われていることが大切であり、後付けでオントロジー設計を行うという方針では立ちゆかないという現象が発生するといっても過言ではないといえます。
実際には、オントロジー設計というのはリレーショナル・モデル設計と根本的な違いがあるということではありません。クラス、サブクラス(リレーショナルでは、エンティティ、サブタイプ)、プロパティまたは関係性と属性(リレーションルではリレーションシップと属性)、インスタンス化(リレーショナルではロウの識別）といった類似性があります。またどちらのモデル化方式でも、ロール(役割)の適切な把握が大切な位置付けとなります。ややもすれば(特に日本では)「動詞句」として扱われ、余り語彙管理が疎かにされていた部分では、オントロジーを用いた設計では、管理上重要視される点に注意が必要です。
- 今後 分科会の議論の中で認識された考慮点等、折に触れこの欄で紹介したいと考えています。 游悠レポートとして関連資料を紹介していますので、当話題に興味ある方は合わせて参照下さい。
- （先頭に戻る）
- その144： 現在のユーザ・デジタル環境考（近頃の経験を通したレビュー）
- サービスサイエンスという研究領域の始まりは1980年代に遡ります。応用領域の中心はマーケティング分野に始まり、顧客満足を取り込む流れでのサービス指向の形で適用領域が広がってきたというのが著者の認識です。今回この話題冒頭に持ってきたのは、最近筆者のスマートフォンを利用機種変更のための作業をしながら浮かんだ考えに端を発します。DXの推進というのが経産省を初めとして様々な官公庁の音頭で進められ、その際の一般利用者に向けたインタフェース領域の主役は主にスマートフォンであると言って過言ではないでしょう（総務省統計によれば、2022年の個人のスマートフォン普及率は84.9%に上ると報告されている）。この機器基盤をベースに、例えばマイナンバー基盤を用いたスマートフォンのアプリケーション(アプリと略)を通じて、様々な利用者情報管理を次々と行おうという流れが進んでいます。
しかし一般利用者視点で改めて眺めて見ると、アーキテクチャやアプリケーション開発といった基本的な部分で、現在かなり無理が通されているのではないかと筆者は感じています。例えばスマートフォン上のアプリは、様々な企業が個別に自社サービスへの取込を狙う形で開発提供しているのが実情でしょう。この結果、利用者に取っては色々な会社のサービスを利用しようとすればするほど、際限のないアプリ導入を余儀なくされてしまいます。アプリというソフトウェアだけでなく、利用基盤であるスマートフォン(ハードウェア)は、電気を利用するという制約がある以上、バッテリー寿命を考慮せざるを得ないことにより2～5年程度といった比較的短期間でのユニット交換を迫られます(勿論、不便を受け入れた形で限界まで利用するという場合、もう少し利用期間は長くできるでしょう。新しい機種ではバッテリー充電量を大容量化しようという流れになっています)。また私企業によりOS開発側の都合により更新されたOS版を使うには、既存のスマホ資源(メモリ、CPU、グラフィックス機能等)が非力になってしまうことにもなります。
新しい機種に容易に乗り換えられる一部の利用者を除 いて 、残された一般的スキル及び経済的環境に置かれる他の利用者にとって、率直に言って経済的・時間的・技術的・
精神的負担は、もはや小さいものだと言い切れない状況と筆者は考えます。アプリ移行においても個別対応により、必要なIdやパスワード、承認方式が異なり、移行に際しての時間負担も小さいとはいえないのが現在のスマホ基盤提供の実態といえるでしょう。勿論、新機能が次々と開発され、それをスムーズに利用可能な「一部の利用者」に取ってはメリットが大きいという意見が出るのは承知の上ですが、ここでは残された(大多数ともいえる)利用者視点からの意見です(実際、筆者の周りの利用者の意見を聞くと、同様な意見をそれほど時間を使わずに集めるこができます。
- また、アプリ提供・開発者側から見ても本当の意味での一般利用者を想定したサービスデザインという点は少しおざなりにされているのではないかと疑いたくなります。話題先行、不具合が起きた場合、後追いで対応すれば良いという傾向もあるように思えます(典型的にはマイナンバーの暗証番号を高齢者向けにはなくそうという変更の話題に突然仕様変更が起きるなど。これはアプリそのものだけの話ではありませんが)。この稿で筆者が述べたいことは、様々なリテラシーおよび経済レベルの多数の利用者が混在する環境向けには、必ずしも「最新の技術に則ったアーキテクチャやインタフェースを導入して環境として放り出せば良い」という訳にはいかないことを十分考慮した方策・設計が必要であり、その点が十分検討されてない状況という点です。
（先頭に戻る）
- その143： オントロジー設計視点とデータモデルの課題考
今回の話題は、6月18日に(財)データマネジメント協会(旧・米Dama日本支部)の月次勉強会で筆者が次の表題で発表した内容を概要紹介するものです。「オントロジー視点と データモデル課題探訪
(誘い編）」（本内容に興味のある方は、「お問い合わせ」ページから筆者宛連絡を下さい） 昨今、リポジトリーといった用語管理や知識グラフとの連携といった点から「オントロジー」に関する技術知識領域に目を向ける人たちが徐々に増えてきています。元来「オントロジー」は哲学領域の「存在論」から始まり、情報学や人工知能の分野では工学的な技術領域として1990年代から研究されてきたものです。その概要的定義は「大雑把にいえば、概念化に現れる個物や関係をインスタンスとしてもつ
クラス（概念）を同定して、それらを上位下位関係に基づいて組織化したもの」と説明されています(※1)。
このオントロジー表現の構成要素の第1は、制約的集合で表される「概念クラス」。これは概念階層の親・子関係で示されます。親クラスの基本属性は子クラスに引き継がれます。その他の要素として、「意味リンク」。このリンクには「全体-部分リンク」「一般-特殊リンク」「抽象-具体リンク」といった代表的なものがあります。更に「属性」「関係」といった基本要素があります。また項目の果たす重要な捉え方に「ロール(役割)」があり、この考え方はデータモデルのエンティティ、リレーション、属性の捉え方(表現)にも影響を与えているといえます。
次にオントロジー設計を考える上で必要な要素は、(1)どのようなクラスを定義すべきか(クラス分類の推奨基準)、(2)本質属性の簡単な基準、(3)作成される対象ドメイン(分類)、(4)ロール(役割)概念の整理と表現、などが上げられます。但しオントロジーは表現レベルや研究者の捉え方により必ずしも同一の標準的表現で表されてはいない点に注意が必要です。またオントロジー設計ツール(エディター)に何を使用するかによって表現の制約が生まれます。オントロジーは表現する概念の構成と構造を表すものであり、実際のデータベースとして利用するには、具体物(インスタンス)群を作成追加することになります。
オントロジーを理解する上での逆の見方として、「オントロジーは何でないか？」を分かることも役立つでしょう。それを列挙すると、(a)オントロジーは単なる語彙集合ではない、(b)
オントロジーは単なる概念階層ではない、(c)オントロジーは知識表現ではない、といった項目が上げられます。そして、このオントロジー設計を支援するツールの代表
的なものには、「法造」(大阪大学溝口研究室開発、2023年現在は、大阪電気通信大学古崎研究室にてサポート)「Protégé 」(スタンフォード大学開発)があります。いずれもインターネットページからダウンロード利用が可能です。以上の内容は、主に溝口教授及び研究室著書を参考に説明したものです(※2)。
最後に、 このオントロジー視点から考察する筆者の捉えるデータモデルの課題点について項目列挙しておきます。(1) データモデル記述方式との類似性と差異は？
(2)用語の異同/類似性比較
(3)ER図 動詞句の果たす役割とその管理
(4)パーティモデルは過度な汎化（一般化）
(5)製造物のオントロジーとインスタンス視点
(6)オントロジー組立て妥当性の考慮例
(7)マスタデータ、リファレンスデータ等、コード系情報整理への活用
- 注※1 知の科学 オントロジー工学 p.6 溝口理一郎 著 人工知能学会 編 2005年 オーム社
注※2． －オントロジー構築入門 古崎晃司 他3名著 溝口理一郎 編 2006年 オーム社
－知の科学 オントロジー工学の理論と実践 溝口理一郎著 人工知能学会 編 2012年 オーム社
- (先頭へ戻る）
- その142： 「デジタル・サニハ」というスキルの重要性を考える
諸々の筆者都合により原稿休載していましたが、久々の話題を投稿します。今回はMLB（メジャーリーグ・ベースボール）の世界で起きた晴天の霹靂とも言うべき話題を題材にしたものです。この話題は、野球というスポーツのルールに詳しくない方々でもドジャースの大谷選手に興味のある人なら世界的に誰でも知っている内容と言って過言ではないものでしょう(大谷選手が米国での活躍をする上で、最も信頼していると思われたM氏(通訳)による大規模横領の件)。ここは内容自体を詮索することが目的ではないため、これ以上の事件詳細は割愛します。
ここでデータマネジメント、特にセキュリティの視点で着目したいポイントは以下の点です。 (1)他者の発するメッセージについて、元情報およびその出所を含めた信頼性の評価が必要(2)受け取ったメッセージについて、元情報およびその出所を含めた正確性の確認が必要
(3)起きている現象、プロセスに関して定期的、継続的なログ管理を行うことが必要 (4)現実的・物理的世界以上に「デジタル世界」では(1)～(3)を一層重要視したアクションが必要
(1)については、どこから、どのように、何を根拠に発生したデータ/情報を見ているのかを、信頼性評価の目で捉えることが常に必要であることを示します。ここでは常日頃、データ/情報の出所がどこまで信頼して良いモノであるかを観察しておくという努力が求められます。(2)については、自分に届けられたメッセージそのものの内容がどのようなものであり、どこまで受け入れて良いモノなのかを見極める習慣が必要だということです。そのためには、なにを元にしてデータ/情報が正しいと判断できるかの判別基準を常日頃鍛えておくことが求められます。ここで課題となるのが、(1)も(2)も100％間違いない答えを得ることが大変難しいという点です。その意味で確率的判断にならざるを得ない
。
そこで必要になるのが項目(3)であり、それを支える事象確認のための手段を用意することと、それが確実にアクション結果として表れていることを定期的にチェックすることが求められます。これが「管理する」という習慣です。過去・現在・未来の流れとして事象がどのように、いつ行われたかを確実に記録し、その結果がどうなったかを見定めることです。ここでは、予期しない事象が発生していないかを予防保守的に確認するという行動が含まれます。そして仮想的に構築された昨今のデジタル世界での事象(例えば金融取引、日常に的ショッピング等)については、より一層の管理習慣が必要であるというのが今回の事件を通じた教訓と言えるでしょう。この一連の習慣ポイントを、ここでは「デジタル・サニハ」習慣と呼んでおきます。
- 実際、今回の事件を有名選手に偶々起きた出来事と見過ごしてしまうことなく、自分の行動習慣として見直しておきたいというのが筆者自身へのメッセージです。（また、事件捜査の経緯を通じて、数年に渡る様々な取引記録(トランザクション処理内容、メッセージ往来記録、電話音声等)が数年に渡って記録され、レビュー可能な状態が裏面で行われていることを確認できた事も、筆者の収穫です。)
- (先頭に戻る)