見出し画像

番外編 ~ Microsoft AI Tour @ 東京に参加して

はじめに

今回は、連載中のトピックを中断して、2026年3月24日に東京ビックサイトで開催された Microsoft AI Tour に参加して感じたことを書いていきます。

生成系AI を活用したサービス全般について

このイベントは2024年から毎年開催されていて、今回が3回目の開催。私は毎回参加しています。この二年で随分進化したな…というのが素直な実感。
仕事とはあまり関係ない日常生活における普段使いの AI 系サービスは別として、ビジネスにおいては、嫌いな人(特に私の同年代以上の男性:苦笑)はいるかもしれませんが、アカウント管理、コミュニケーション、ドキュメントなど、Microsoft Office の進化系である Microsoft 365 を採用している企業が大多数でしょう。ビジネスにおいて生成系AI を活用するとなれば、日々行われる、メールやチャット、ミーティングによるコミュニケーション、ドキュメント群の作成・共有から派生する膨大なデータ群との連携が必須です。それらのデータ群は、Microsoft 365 に蓄積されているわけです。連携するためにはセキュリティ・アクセス権・利用履歴などの管理・監査も重要であり、それらの機能群も包含して提供しているMicrosoft 365 を採用している企業は、マイクロソフトが提供する生成系AIを組み込んだサービスプラットフォームを採用するのがコスト的に妥当だろうと思います。
「いやいや、ある分野の業務では AWS や Google のサービスを使っていてデータはそっちにあるよ~」という場合も多いかもしれませんが、20年以上のマイクロソフトとは違って、他社サービス内のデータソースへのコネクタも充実しているので、そちらもあまり問題にならないでしょう。

キーノートで沼本さんが「一発芸的な AI とは違います」的なことをおっしゃっていましたが、まさにそうだなと、思った次第です。
また、キーノートデモにおける、写真からTシャツのデザインを作成するデモを、私のマイクロソフト時代の同僚が実演していました。つい10年ぐらい前(還暦越えのおじさんからするとつい最近:苦笑)の de:code のデモで、果物の写真を撮ってそれが何かを識別するなんていう、今やったらそれこそ笑いも取れない一発芸的なデモをやって、「おーっ!」と驚かれていたことを思い出して、随分と世の中変わったな…なんて、元エバンジェリストの感慨です。

生成系AI 以前と以後について

業務を支援するサービスは、生成系AI が使い物になる以前にも多数ありました。それらのサービスに対する私の素直な感想は、サイズ感があっていない着物に無理やり体を併せて着る的なものでした。多分皆さんも多かれ少なかれそんな感じを抱いていたのではないかと思います。
今回、会場であった元同僚や知合いに、「今どきの生成系AIってどうよ」って感じで話をしましたが、まぁこれ、最近はいろんな機会にやっている事なんですが、皆さん、本来的にやるべきことをやればやるほど、生成系AIの恩恵を受けられる、と思っているようですね。
私もそんな印象を受けています。
これ、サービスの心臓部が固定されてなくて、学習によってあなた流に進化していくので、ある意味当然なのかもしれません。
生成系AI を基にしたソリューションを使った結果得られるメリットは、あなたのレベル次第、ってことでしょうか。

Microsoft Fabric について

この連載マガジンの、
153. Digital Twins Builder|Knowledge & Experience
から
173. Fabric IQ|Knowledge & Experience
にかけて取り上げた、Microsoft Fabric に関する展示・ブレークアウト・ライトニングセッションも多数あって、興味深く拝聴してきました。
紹介されていたのは、ほぼプレビュー段階の機能(個人の感想です)といった感じでした。
このマガジンでは、オントロジモデル、セマンティックモデル、グラフモデル、等々、Microsoft Fabric を使うと必ず出てくるであろう、モデル群について解説を披露してきました。記事を書いている中で、私が思っていたのは、

こんなモデル誰が作れるんだろう?
誰も作れなかったら、それらを前提とした機能・サービス群は誰にも使ってもらえないんじゃないの?

心のおもひ 1.0

ってこと。だから、それぞれのモデルの意味を書いたわけですが、今回イベントに参加して思ったことは、

そもそも、これらのモデルの必要性が理解できる人がほぼいないのではないか?

心のおもい 2.0

というそもそも論的な感想です。多分、ここが解決されないと、Microsoft Fabric を有効活用する人は増えないだろうし、生成系AI の恩恵も享受できないのではないか。
そして、モデルの必要性が理解できない理由には、

  • そもそもモデルとは何かを理解していない

  • 何がモデルになるかか理解していない

  • 分析において、何故新たなモデルが必要になるか理解していない

という三段階があるのではないか。この三つを分解して、段階的な理解が必要だろうというのが、私の感想。
んでもって、私が最近注力している、概念モデリングの普及啓発活動についても、概念モデリングの道具立てに関するドキュメントは多数あるけれど、そもそも概念モデリングとは何のためにあるのか、その訴求が弱いなぁ…とも、改めて痛感した次第。そんなわけで、
Art of Conceptual Modeling|Knowledge & Experience|note
の概要文をちょっと変えたんですけどね。

まぁ、そんなこんなで、この三点について書いていこうと思います。

モデルとは何か

まぁこれもね、
154. モデル、モデル図 ~ 一考|Knowledge & Experience
あたりで書いてるんですが、小難しいですね説明が。今回は、すごく簡単に説明を試みようと思います。

考えること、思考することは、あなたが対面している世界を言語でモデリングすることです。あなたが何をするにしろ、考えること、思考することは必須なのは言うまでもありません。つまり、意識的、あるいは、無意識的に、あなたは日常的にモデリングを行っていることになります。 あなたが普段無意識に行っているモデリング、その道具立てを明確かつ厳密に体系化したモデリング技法、それが”概念モデリング”です。

Art of Conceptual Modeling|Knowledge & Experience|note の概要文の冒頭

今回のイベントの参加で触発されて書いたのがこの文章です。え?「既に難解ですけど」ですか。。。あはは。
要するに、あなたが見て思った内容を明快に他の人に示すこと、これがモデリングだよということ。皆さん誰かに思っていることを伝える場合は、母国語で話しますよね。その際、日本語なら日本語の、英語なら英語の文法に従って、思っていることを表現しますよね。文法とは表現する時の形式であり、その形式に従ってお話としてあなたの思っていることを伝えているという事になります。聴かされている方もその形式を知っているから、あなたの思いが理解できます。思っていることを伝えるためには、話し手と聞き手のの両方が共有している形式が必要という事です。そして、形式は、人間の言葉の在り様がベースになっているはず。

あなたが思っていることを、何らかの形式に従って表現すること=モデリングであり、表現された内容がモデルなるもので、表現するための形式が記法、どんなふうに表現すればよいかをまとめたものがモデリング技法だよということ。

あなたの考え・思い・思考を他の人に伝える場合、言語化しなければならないのは言うまでもありません。え?「図や絵を描くこともあるよね」ですか?はい、そうですね。でも、その図や絵に描かれていることを結局は言葉で説明しますよね。だから、結局は一緒ってこと。

更に言えば、紡がれた言葉は意味を伴なっていなければなりません。あなたが伝えたいのは、あなたの考えや思いの意味するところであって、単なる言葉の羅列ではありませんよね。

  • 今期、売上を20%アップする!

この文章を読んで、どう思われます?
多分どこかの会社や事業部門の期初ミーティングあたりでの発言なのでしょうが、部外者には全く何のことを言っているのか判りませんねよ。
”売上?何の?”、”20%?どういう尺度?”、”アップ?アップアップ?”、”今期?年度?月度?クォータ?”ということで謎は深まるばかりです。
会社や部門の関係者にしても、この謎はほぼ一緒でしょう。
要するに、この文章は意味不明だということですね。
この文章自体もそうですが、文章から切り出した単語についても、それぞれの意味は不明です。
”あなたが思っていることを、何らかの形式に従って表現すること=モデリング”なのであれば、この文章もまた、誰かの思考のモデルのはず。それが意味不明とはどういうことか。
でも、関係者には多分多かれ少なかれ概要の意味は伝わるはずですよね。
今期とは、3か月単位のクォータであり、売上とは、その部門が管轄している商品やサービスが売れたときに生じた金額の単純な総計であり、20%とは、(今期の売上ー前期の売上)/前期の売上×100 が20(以上)を目指す、…そんな感じでしょうか。こんなバックグラウンドを聞き手も共有しているわけです。言葉単体では意味はなさなくても、その言葉が指しているものとその特徴、他のものとの意味的なつながりがあれば、意味が伴うということ。

ここから、ちょっと難しくなります。一段思考のレベルを上げることにします。目に見えたり触ったりできるものだけでなく、売上のような人間の思考に浮かんでいるものも含めて、モノと呼ぶことにします。言葉が意味を伴なうには、

  • モノを指す単語

  • そのモノの特徴

  • モノとモノの意味的なつながり

を記述するモデルでなければなりません。”今期、売上を20%アップする!”という文章が意味をなすためには、その様な全体のモデルがあって、そのモデルの一部を切り出した文章でなければならないという事です。

更に一段ギアを上げますね。少々難しくなりますが、ついてきて来てくださいね。

先程の文章と、大体こんな話だろうという文章をもう一度見てみることにします。

  • 今期、売上を20%アップする!

    • 今期とは、3か月単位のクォータであり、売上とは、その部門が管轄している商品やサービスが売れたときに生じた金額の単純な総計であり、20%とは、(今期の売上ー前期の売上)/前期の売上×100 が20(以上)を目指す

この文章に出てくる単語が指すモノについて考えてみましょう。その単語は、あなたの頭に浮かんでいるものも含めたモノそのものですか?
モノそのものとは、その単語が一対一にモノに対応しているということ。
そういう場合もあるとは思いますが、普通は以下のような思考をめぐらせていませんか?

  • 期という分類があって、今期とはその分類に属する

  • 商品という分類があって、担当している商品とはその分類に属する

  • 売上とは、”商品が売れる(販売)”と言う分類が持つ特徴である

ようするに、モノそのものと、モノの分類というものがあって、

  • そのモノは、この分類だ

  • ある特徴と意味的つながりを持っているから、それはこの分類だ

  • この分類なら、そのモノは、こういう特徴と意味的つながりを持つはずだ

という物事の認識スタイルです。普段あまり意識してはおらず、モノそのものとその分類のお話は混在して、言葉になっていると思いますが、その思考の流れを明確にすれば、こんな風に人間は物事を認識しているはず。

概念モデリングでは、このモノそのものの世界のモデルと、分類の世界を明確に分離してモデル化します。分類の世界のモデルのことを、概念モデリングでは、概念情報モデル(スキーマ、圏Cとも呼ぶ)と名付けています。

概念情報モデルなんて、大仰な名前をつけていますが、リレーショナルデータベースのスキーマや、Azure Digital Twins の Twin Model と本質的には同等です。なので、RDBの設計者は、既に体得済みのお話のはず。

補足

説明上めんどくさいので、モノそのものの世界のモデルのことを”インスタンスモデル”と呼ぶことにしますね。

分類の世界のモデル、つまり、概念情報モデルは、

  • 分類の名前

  • 分類が持つべき特徴値の組

    • 特徴値のデータ型を伴なう

  • 分類に属するモノの間の意味的つながり

    • 多重度、意味のフレーズを伴なう

という、インスタンスモデルの道具立てを分類した3要素で記述されることになります。

先程の、”今期、売上を20%アップする!”という文章のことを、インスタンスモデルの一部を切り出したものだと説明しました。そうであれば、この文章が意味をなすためには、別途インスタンスモデルの全体が必要です。インスタンスモデルは、モノ、モノと特徴の組、モノとモノの意味的つながりで記述されるものなので、基本的にはネットワークモデルの形式で表現されます。その全体像を理解するには、モノと特徴値の組というつながりと、意味的なつながりを場当たり的に総なめしていかなければなりません。

ここに、分類の世界のモデルがあればどうでしょう?概念情報モデルがあれば、それを基に、インスタンスモデルを理解することができるだけでなく、他の商品やサービスについても、概念情報モデルを基に、同じような形式で、売上目標を語ることもできるでしょう。

概念情報モデルとは、対象としている世界の意味の構造を記述するモデルであるという事です。

データ分析が重要だと言われている昨今、分析するためには蓄積されたデータが必要です。データ群を構成する数値も同様であり、意味が伴っていなければ分析のしようがありません。最低限、インスタンスモデル全体があって、そこから切り出されたデータ群でなければ、分析なんてできませんよね。また、インスタンスモデルは基本的にネットワークモデルなので、例えば Excel のような表形式で表すことも基本的には困難です。表形式で表すためには、概念情報モデルのような意味の構造を規定するモデルが必ず必要になります。
その様なモデル無くして蓄積されたデータなんぞは、単なるストレージ上のゴミだと言われても仕方ないでしょう。

以上をまとめると、意味のあるデータ群であるためには、データ群単体だけでは不十分で、概念情報モデルのような、その意味の構造を定義する別のモデルが必要だということです。そうして、そのモデルを共有することで、初めて別の人に意味が伝わるということ。

データ分析だけでなく、ビジネス一般の会話においても、関係者がその意味を共有するには、意味の構造を記述する概念情報モデルのようなモデルが必須だということは、お判りいただけたでしょうか。

もしかすると、今どきの生成系AI は既に、概念情報モデルのような意味の構造を記述するモデルを生成可能なのかもしれませんね。
データ分析だけでなく、生成できるにしろできないにしろ、

Microsoft Fabric に出てくるモデル群に話を戻します。
この定期購読マガジンでも解説している通り、オントロジモデル、セマンティックモデルは、本質的には、意味の構造を記述するモデルであり、概念情報モデルと同等だという事です。ただし、概念モデリングの流儀からすると、微妙に不足している道具立てはあるのですがね。

要するに分類の話をしているモデルだよ、ってことをご理解ください。

はい、先ずは、これが最初の基本。
「えー、まだまだつづくのー」

何がモデルになるか

実は、ここまでのお話は、データベースのテーブル設計者やデータアナリストなら、当たり前に知ってるよ的なレベルのお話だったと思います。

でもね、やはり難しいんですよ、概念情報モデル(意味構造を記述するスキーマ的なモデルの総称としてこの言葉を使うことにしますね)を作るのは。
何故かというと、言葉は本来的に多義的だからです。
前節で取り上げた、

ここから先は

2,575字 / 1画像
説明では、Microsoft Azure 中心‼…になっていますが、最近は、Azure に限らず、IoT・Digital Twins、加えて、AI、DX 等のシステム構築に関するもっと本質的な話題を書いています。なんちゃってから卒業したい技術者の皆さんぜひ、ご購読くださいませー

IoT・Digital Twins を極めよう!

¥200 / 月 初月無料

2022年3月にマイクロソフトの中の人から外の人になった Embedded D. George が、現時点で持っている知識に加えて、頻繁に…

この記事が気に入ったらチップで応援してみませんか?