こんにちは。入社１年目のS.K.です。
今回は、１０月の勉強会についての記事になります。

ITエンジニアであれば、アーキテクチャという用語について知っている方々は多いと思います。
今回は、その中でも基本的なMVCとMVVMについてになります。

MVC

MVCとはModel, View, Controllerにアプリケーションの要素を分割するアーキテクチャになります。
なお、当記事において、特に断りがない限りMVCはMVC2（JSP model 2 architecture）を示します。主にWebアプリケーションの文脈で語られるMVCです。

まず、ブラウザ（ユーザー）からのリクエストを受け付るのが、Controllerになります。
ControllerはModelに対してリクエストを通知し、Modelから受け取った結果を、Viewに反映する役割を持っています。
Modelにはアプリケーションのビジネスロジックを記述され、DBからデータを持ってきたり、ユーザーのリクエストに応じて結果を返す役割を持っています。
ViewはControllerから結果を受けて、それをレスポンスとしてブラウザに返します。

また、WebアプリケーションにおけるMVCでは、アプリケーションの処理はすべてバックエンドで行われているという点も特徴です。

MVCの長所としては、Model、View、Controllerに分割したため、メンテナンス性や拡張性の良さが挙げられます。
一方で、アプリケーションが大きくなってくると、ModelとViewの処理が集中するControllerが肥大化する点や、リクエストの度にViewがすべて更新されるため、動きが重くなりがちという問題を抱えています。

MVVM

MVVMはMVCの後から出てきた概念で（原初のMVCが1979年、MVVMは2006年）、動的なフロント開発により適したアーキテクチャとなっています。
アプリケーションの要素をModel, View, ViewModelという形に分割します。
この3要素のみに注目すると、Controllerの名前がViewModelに置き換わっただけのように感じますが、View, ViewModelがフロント側、Modelがバックエンド側の処理に代わっている点が大きく異なります。（このため、ユーザーが直接Viewを操作する形になっています。）

ModelとViewの役割はさほど変わりませんが、MVCのControllerに相当するViewModelは、役割が若干異なっています。
ViewModelはViewとデータバインディングされており、データはViewModelとViewで同期されているという事です。
データバインディングとは、大まかに下図のようなものです。

MVVMの長所としては、MVCよりもさらに明確なViewとModelの分離がされている点があります。
さらに、データバインディングによって素早いViewの更新を行うことができます。

情報の世界に熱力学の理論を取り入れたテーマになります。
主にエントロピーが絡んだ内容となり、効果的な情報の絞り込みに関して、熱力学の知見を借りてアプローチしようというものです。

情報とエントロピー

情報熱力学のエントロピーは、大まかに言えば、集合の情報量を意味するものです。
「情報のエントロピーが大きい = 含まれている情報量が大きい」と考えてください。
数式で示すと、下記のようになります。

離散確率変数𝑥とその𝑥のとりうる値全体の集合𝑋があり、その確率分布を𝑝[𝑥]とします。
なお、集合𝑋中のすべての𝑥に対する𝑝[𝑥]の総和は1となります。このときの𝑋のシャノンエントロピーは

で、定義される。

もう少し具体的に、ある確率𝑝 (0≤𝑝≤1)で発生する事象と、そうでない事象（発生する確率は 1−𝑝）のみを考えると
シャノンエントロピーは

となるので、グラフで示すと下の画像のようになり、𝑝=0.5で最大となる放物線のようなグラフになります。
つまり、偏りの少ない事象ほど、シャノンエントロピーが大きくなることが分かります。

数当てゲーム

ランダムに出力される、1から100の整数を当てるゲームを考えます。数字を言ったら「あたり」、「小さい」、「大きい」で返ってきます。
先ほどのシャノンエントロピーを考慮すると、50か51という数字を最初に指定すれば、含まれる情報量（= 回答から絞れる数字の量）としては平均的に大きいので、最初に聞く数字として無難であるように思えます。これを、数式で確かめてみます。

宣言した値を𝑥とすると「あたり」、「小さい」、「大きい」の出る確率はそれぞれ1 ∕ 100、(𝑥−1) ∕ 100、(100−𝑥) ∕ 100となります。
よって𝑥に対するシャノンエントロピーは

この導関数は

これは𝑥切片(50.5, 0)の1<𝑥<100で短調減少する関数でなので、シャノンエントロピーが最大になる整数として、50か51が最適解となることが分かります。

さらなる応用

さらに複雑な応用として、Wordleを当てるbotがあります。
候補になりえる単語全ての内、シャノンエントロピーが最も高い単語を出力して行くことで、一見的外れな単語から一気に正解を当てる方法を取ります。
勉強会で、発表者のR.D.さんはこちらのデモも行っていました。

numeronやakinatorのbotも作れるかもしれないとの事です。
botに問題を自動で解かせる方法の一つとして、参考になりました。

従来のSalesforceのチャット製品（Live Agent、Salesforce Chat、埋め込みチャット、サービスチャット）は、2026年2月14日に廃止することが決定されています。
Salesforceは、後継の機能として「アプリ内およびWeb向けメッセージング」の利用を推奨するようになりました。
これを使用してみた所感を記します。

有人チャットの設定

まず、エージェントに直接つなぐ友人チャットの設定を行ってみました。
各種設定については、Salesforceのマニュアルをご参照ください。
簡単なWebサイトを構築し、チャット用のUIを設定しました

Salesforce側でチャット関連の設定をすることで、下の画像のようにユーザーとのやり取りを行うことができます。

詳細な設定などの内容は、過去の「メッセージング（MIAW）設定」のシリーズの記事に投稿して頂いております。
是非、ご覧ください。

Einsteinボットの設定

Einsteinボットによって、サポートのチャットなどを代行させることも可能です。
これによって、ボットによって対応できる範囲ならば、エージェントの負担を軽減することもできます。
フローとしては、下図のようになります。

こちらについては、イメージ通りの物が完成したら、またブログに投稿して頂けるとの事です。

前回の勉強会の記事：【2024/09 勉強会】
「メッセージング（MIAW）設定」シリーズ：第一回、第二回、第三回