Fujitsuの最新AIの成果を無料で試せるのを知っていますか？

Fujitsu Research Portalをご存じでしょうか？
portal.research.global.fujitsu.com
富士通の先進技術を、様々な用途で、いち早くお試しいただく環境として、技術コンポーネントのAPIやWebアプリケーションを無償で公開しています。
製品の無料評価などはありますが、日本企業で、このような先端技術を体験できる取り組みはまだまだ珍しいのではないでしょうか。

Fujitsu Reseach Portalで試すには

アカウント作成

アカウント作成開始

Fujitsu Reseach Portalの利用にはアカウントが必要です。まずは、ポータル上部の[アカウント作成]をクリックします。

個人情報取り扱い

個人情報を適切に取り扱う（他に流通させない）旨の内容に合意します。

アカウントの種類の選択

法人利用の場合、事前にPoc IDの払い出しが必要ですが、富士通と企業通しの連携を正式に進めている場合以外は、業務のための調査のような場合も含め、「個人利用」でアカウント登録します。

サインアップを選択

富士通の従業員の場合は、SSOでサインインできるようですが、社外利用者の場合は[サインアップ]を選択します。

確認コード送信

メールアドレスを入力して、[確認コードを送信]して、メールアドレスが正しいかを確認します。

入力するとメールが送信されますので、メールの内容を確認します。

メールに記載されたコードを入力します。

アカウント名などの入力

アカウント名、パスワード、氏名を入力してアカウントを作成します。

電話番号認証

本人確認という意味でSMSによる確認を行うので、スマホの電話番号の先頭の0を除いて入力します。このSMSによる本人認証はアカウント登録時以外も随時実施されます。

スマホのSMSに届いたコードを入力します。

作成完了

無事にアカウントが作成できたら自動的にログインが行わて、ポータルのヘッダが変化します。

デモやAPIが試せるもの一覧（2024/09/30現在）

ポータルの内容は日々拡充されています。
動画で詳細を知ることができるものもだけではなく、WebアプリやAPIを試せるものを数を多くあります。
ポータルを見ると、５つの分類（AI、Data & Security、Converging Technologies、Computing、Network）ごとにまとまっていますが、これは、「Fujitsu Technology and Service Vision | 富士通」 に書かれている５つの重点技術領域に相当します。

AI Fujitsu Kozuchi (R&D)

Fujitsu Kozuchiは、富士通が研究開発した先端AI技術です。公開されている研究開発版の技術をWebアプリやAPIで試せるものとしては次のようなものがあります。

1. Fujitsu AutoML [WebApp][API]
2. Fujitsu Auto Data Wrangling [WebApp]
3. TDA時系列異常検知 [WebApp]
4. Wide Learning [WebApp]
5. 因果発見 [WebApp]
6. 対話型生成AI [WebApp]
7. AI Trust (AI Ethics, Security) [WebApp]
8. Actlyzer [WebApp]
9. マルチカメラトラッキング [WebApp]

Data & Security

富士通では、次世代インターネットや生成AIの普及に伴う新たなデータ流通・活用技術と、その裏に潜む様々な脅威やリスクに対応できる先進セキュリティ技術の研究開発を行っており、WebアプリやAPIで試せるものとしては次のようなものがあります。

1. 透過的トラスト [WebApp]
2. Data e-TRUST [WebApp]
3. ConnectionChain [WebApp][API]
4. カメラ生体認証 [WebApp]
5. Trustable Internet [WebApp]
6. Robust Localization based MFA [WebApp]
7. Federated SNS [WebApp]
8. VC-Token Federation [WebApp]
9. ゼロ知識エビデンス技術 [WebApp]
10. セキュリティ監査自動化 [WebApp]
11. マルチカメラトラッキング [WebApp]

Converging Technologies

富士通は、デジタル技術と人文科学の知見を融合し、物理とデジタルの境界がない世界における社会的課題の解決を目指しており、デジタルツインとして、WebアプリやAPIで試せるものとしては次のようなものがあります。

1. シェアドモビリティ最適配置 [WebApp][API]

Computing

Coming soonとのことで今後更新されたら改めてご紹介します。
富士通のいうとろのComputingとは、AI Computing Broker、FUJITSU-MONAKA、HPC、量子コンピューター、量子シミュレーターなどが該当します。量子コンピューターというとデジタルアニーラとかでしょうか。
このあたりの研究成果や、どのようなお試しができるようになるのか、今から楽しみですね。

FUJITSU-MONAKAとは

FUJITSU-MONAKAって初めて聞いたので、ちょっと脇道にそれてしまいますが調べてみました。
www.fujitsu.com
コードネーム「FUJITSU-MONAKA（ふじつうもなか）」は、富士通が2027年度提供に向けて開発中の次世代プロセッサーのことだそうです。ARMベースということは、富岳テクノロジーから派生でしょうか。
FUJITSU-MONAKA搭載のノートPCとかが登場してARM版WIndowsが動いて、「Copilot+PC」にラインナップされたりしたら胸熱ですね（妄想過多でしょうか）。
www.microsoft.com

Network

6G、ソフトウェア基地局、Open RAN、インテリジェントネットワーク、光電融合、ディスアグリゲーテッド・コンピューティングなどが該当する領域です。
どのようなものが登場するか、ちょっとわからない分野になりますが、こちらも情報が更新されたら改めてご紹介したいと思います。

お試しお勧め（その１）：対話型生成AI [WebApp]

思った以上に様々なWebアプリが公開されていてどれから試そうか迷いますよね。
そんなときにお勧めなお試しWebアプリが「対話型生成AI」です。
documents.research.global.fujitsu.com
利用できるAIモデルは、GPT-3.5、GPT-4o、Claude Instant、Fugaku-LLM(CPU版)となっています(2024/09/30現在)。

特徴的な機能

生成系AIを使った他のチャットボットと比較して特徴的なのは「ハルシネーション」検出機能がある点です。
ハルシネーションとは、幻覚とも日本語訳される生成系AIでは避けて通れない、「データに基づかないもっともらしい誤り」のことです。
想像力豊かな回答をするAIだなーともポジティブに捉えることもできるのですが、それが「想像力豊か」なのか「現実なのか」の判断は、ひとえに回答をもらった人の経験値によって差が出てしまうので、「想像力豊かなのですが」と断りをいれて回答をしめしてくれるのは助かりますね。

早速使ってみよう

「対話型生成AI」ページの一番下に「技術のお試しはこちら」というボタンがあるので、一番下までページをスクロールしてボタンをクリックしましょう。
これ、左サイドメニューに「お試し」ってメニューつけてほしいところですね。
「技術のお試しはこちら」ボタンを押すと次のような画面が表示されます。

利用規約の同意

個別の利用規約がありますので、初回利用時に表示されるので同意します。

アプリを試す

利用規約に同意すると「技術を試す」という表記が「アプリを試す」に変わります。

login

ログイン画面が表示されたら[login]をクリックします。

Create New Chat

ログイン直後の画面は次のようになっています。

[Create New Chat]をクリックした新しいチャットを開始します。
チャット開始時にはチャットのスタイルを選択します。

• Chat name：チャット名を指定
• Flow：シンプルチャットなのか、ドキュメントを参照してのチャットなのかを選択します。
• Retriever：ドキュメント管理機能で登録したドキュメントを指定します。
• Model：モデルを選択します。

[Create]ボタンをクリックすると新しいチャットセッションが開始されます。

対話型生成AIを試そう

GPT-4oを使って、Fugaku-LLMで動作させて、FUJITSU-MONAKAでARM版Windowsが動くか聞いてみましょう。

ARM版Windowsをサポートしているという情報は現時点ではないと教えてもらいました。また、デスクトップOSを動作させることを前提としていないということも回答しています。

「ハルシネーション」検出機能を試してみよう

それではこの回答について、「ハルシネーション」検出機能を使って、どれくらい信用してよいかを確認してみましょう。
確認は簡単で回答にある縦マークをクリックします。

結果は次のように、回答の主張は正当であり他の意見とも一致しているため「ハルシネーションスコア」は０となっています。これが100に近ければ近いほど「ハルシネーション」が含まれていることになります。

その他のお勧め

APIが公開されている「Fujitsu AutoML」「ConnectionChain」「シェアドモビリティ最適配置」なども試したいところです。
次回の投稿では、APIで試せるものをとりあげる予定です。

世の中の動向

AIは不思議なもので、説明を聞いてみても理解はしても肌感覚として理解するためには、実際に問題をそのAIで解決してみるというStepが非常に重要です。
そのことを理解しているAzureやAWSなど、クラウド上でAIサービスを展開している海外ベンダーは、AIを手軽に試せる仕組みを用意しています。
また、製品化前のものも積極的に試せるような情報発信に力を入れています。
このような施策により、AIを使った時の第一印象から「面倒」「大変」のようなネガティブ要素を排除して、「これはすごい」ということが強く残るようになっています。
「初見から気に入りました！」
数ある中から自社AIを選んでもらうためには、または、そのときは選ばなくても、何かあったときに再見してもらうためには、このような印象が重要なのではないでしょうか。

おわりに

今回ご紹介した取り組みは、パーパス（社会における企業の存在意義）として「イノベーションによって社会に信頼をもたらし、世界をより持続可能にしていくこと」を掲げる富士通らしい取り組みといえるでしょう。
www.fujitsu.com
利用するのに住所などは不要なので、気軽に試すことができます。
この機会に登録だけでもしておくとよいのではないでしょうか。

Thunkable でSNSを作ってみよう（テーブル編）

前回：
hatsune.hatenablog.jp

前回の記事で、SNSを作るときの変数について取り上げてみました。
その中で、Firebaseというクラウド上のデータベースとつないだ「Cloud Variable」という変数についてとりあてました。
今回は、クラウド上のデータベースにどのように保存しておくとSNSをつくれるのかについて説明していきます。

現在、Firebaseには認証用の「Authentication」テーブルと、ユーザー管理用の「Users」テーブルの２つのテーブルがあります。
「Authentication」テーブルは、Firebaseで「FireBaseプロジェクト」を構成してサインインの方法を指定すると自動的に作成されるテーブルで次のような形をしています。

少し専門的な表記となりますがER図という形で上のテーブルを表記してみると次のようになります。

PKは「プライマリキー」または「主キー」と呼ぶものになります。
PKはそのテーブルで行を特定するものになります。

「Users」テーブルはThunkableアプリの「Cloud Variable Users」と対になるテーブルになります。そのテーブルの形はThunkableで定義します。

こちらもER図で表記してみましょう。

「Users」テーブルでPKは「ID」としています。「Users」テーブルにおけるPKとは「だれが」と言い換えることができます。
それでは、なぜ「メールアドレス」ではなく「ID」を使って「だれが」としているのでしょうか。
それは、あとからメールアドレスを変更できるようにするためです。
もし、メールアドレスを使って「だれが」を特定できるようにしてしまうと、あとからメールアドレスを変えるたびに「だれが」という値をそこらじゅうのテーブルから探して書き換えないといけなくなります。
そのため、人の目に触れないIDという項目を作って、メールアドレスとは別に管理しているのです。
それでは、このIDというのはどこで入力するのでしょうか。
実は、「Users」テーブルのIDは人が入力するものではなく、Firebaseが自動的に作った値を採用しています。

そのあたりの関係をER図では「Authentication」テーブルと「Users」テーブルの間のRelation（リレーション）という線で表現できます。

例えば、ER図の次の表記は、「Authentication」テーブルの「ユーザーUID」と「Users」テーブルの「ID」は同じ値を入れることで「１対１」であること、つまり「Authentication」テーブルの１行と「Users」テーブルの１行がペアになっているということを表しています。

それでは、なぜ、「Authentication」テーブルの他に「Users」テーブルが必要なのでしょうか。
なぜ、「Users」テーブルが必要かといえば、「Authentication」テーブルはFirebaseが自動的に作成するテーブルのため、アプリを利用する人の「姓」「名」などを保存する項目を追加できないためです。そのため、アプリが必要とする利用者１人１人の情報は「Users」テーブルを作ってあげて、そちらに保存する必要があるからです。

つぎにSNSへ投稿した内容を保存するテーブルを考えてみましょう。
投稿内容に必要なのは「内容」「投稿日時」「投稿した人」などが最低限必要です。
「Tweets」テーブルに「内容」「投稿日時」「投稿した人」をいれてみましょう。

「ID」が「だれが」つまり「投稿した人」なので「Users」テーブルと関係づけてみましょう。
１人の人が投稿できるのは１つではないので、「Users」テーブルと「Tweets」テーブルは「１対N」の関係になります。
ER図では「１対N」の関係は次のように表します。

ここで「FK」という新しい表記がでてきましたが、FKとは「外部キー」と呼ぶもので、今回の場合「ID」は「Tweets」テーブル以外（つまり外部の）「Users」テーブルのキーであることを表しています。

さて、それでは投稿に「いいね」がつけられるようしてみましょう。「いいね」は画面では「いいねの数」のように数字で表示されていますが、実際は「だれが」いいねしたかが保存されていて、ある投稿に何人「いいね」したかを「いいねの数」として表示します。
そのため、「いいね」を保存するテーブルに必要なのは「どの投稿」「だれが」「いつ」という３つの要素になります。

それでは、「Users」テーブル「Tweets」テーブル「Favs」テーブルの３つの関係を表してみましょう。
１つの投稿に１人の人がつけられる「いいね」は１つだけなので、「１対１」の関係が３つのテーブルの間で成り立たないといけないので、ER図のRelationは次のようになります。

これで、使う人が好きな投稿に対して「いいね」を付けたり消したりすることができるようになりました。

それでは、テーブル編はひとまずここまでにして、次回はER図をみながらThunkableアプリのブロックを書いていくことにしましょう。

Microsoft MVP for Mixed Realiyを受賞

2023-2024 Microsoft MVP for Mixed Realiyを受賞しました。
2008年から17年連続となります。

オフラインイベントなども増えてきましたし、オンライン中心からの再シフトなどもあるかもしれませんが、状況に応じて自分ができる範囲で無理せずコミュニティ活動を続けていけたらと思います。

今年は、.NET 6/7/8/9、.NET MAUI、AzureのAI関係を基軸にして、xRealやMeta Quest 3のアウトプットを増やしていけたらと思っています。
特にセンシングした結果をAzure OpenAI Serviceなどで情報負荷/変換し、HMDに表示するようなアプリ作成方法にフォーカスしていきたいと思います。
また、Thunkableをつかったローコード開発についても引き続き注目していきます。

Windows DevelopmentからMixed Realiyへとカテゴリ移動となりましたが、引き続きよろしくお願いいたします。

Microsoft Build 2024 Day 0

Microsoftの年次開発者イベントである「build」が今年もシアトルで開催されます。
運よく現地参加できましたので、イベント前日の5/20（現地時間）にシアトル入りしました。

まずは明るいうちにマーケットプレイスにいってクラムチャウダーですね。
日本夜発でシアトル現地午後着ですから、このまま寝ずに現地夜まで耐えれば時差ボケ知らずになるはず。
がんばります。

Thunkable でSNSを作ってみよう（変数編）

Thunkableには「App」「Stored」「Cloud」の３つの変数（variable）タイプがあります。
Thunkableで変数を使うときは、一部の例外を除いて、initializeブロックを使って変数の名前を宣言してあげる必要があります。

3つの変数タイプ

App Variable

App Variableは実行中だけ値を入れて置ける箱になります。アプリを終わらせて再起動したときには値はなくなっています。
それではどのような時にApp Variableを使うのでしょうか。

App Variableを使うときはこんなとき

1. 途中の計算結果をいれておきたいとき
2. 画面と画面の間で値を受け渡したいとき（例：画面Aで選択したデータの詳細を画面Bで表示したいときに「選択」したものをApp Variableに入れて渡す）

App Variableを使うときはこの２つの場合が大半です。あとは迷ったらまずはApp Variableとしておいて、それでは問題があるようなら、あとでStored VariableやCloud Variableに変更してみるという使い方もよい使い方です。

なぜ、まずはApp Variableなのか？

App Variableはアプリ実行中のメモリ上に箱があるため、他の２つの変数タイプに比べると圧倒的に出し入れが速いからです。この出し入れの速さは、アプリの動作速度に直結しますので、必要もないのにStored VariableやCloud Variableを使うよりも快適な動きになるからです。

App Variableの初期化方法

App Variableの初期化方法は、initializeブロックで初期値を指定して行います。
初期値が文字ならば文字型変数、数字ならば数字型変数、EmptyListならばリスト型変数として初期化されます。

Stored Variable

Stored Variableは、アプリごとに用意された端末（スマホ）の領域に箱を用意している変数です。
そのため、アプリを終わらせて再起動したとしても、値が残っています。

Stored Variableを使うときはこんなとき

1. IDやパスワードなど、その端末（スマホ）に覚えさせておくことで、次回実行時に１から入力しなくて済ませたい
2. ネット対戦のないゲームなどのスコアなどを記録しておく

Stored Variableは、アプリを再実行したときも前回実行時までの記録をとっておきたいようなときに使います。

なぜ、Stored Variableなのか？

例えば、すごく一生懸命入力していたものがアプリが万が一落ちてしまって消えたら悲しいですよね。
そういった場合、再実行すれば落ちる直前からやり直せるようにしていたらどうでしょうか。
App Variableではこのようなことができないので、こんなときはStored Variableを使うといいでしょう。

Stored Variableの初期化方法

Stored Variableの初期化方法もinitializeブロックですが、初期値は指定できません。
どうして初期値が指定できないといえば、initializeブロックで初期値を指定してしまうと、アプリを再実行したときに初期値に初期化されてしまって、せっかく残っていた前回終了時の値が消えてしまうからです。
それではどう初期化すればいいのでしょうか。
アプリ実行時の一番最初に開く画面のオープン時に「まだ初期化されていなかったら初期化する」というIfブロックを使って初期化します。

上のようにブロックを組むことによって

• Screen1がOpneするとき(When)
  • もし(if)、Stored Variableのusersがnull（値が入ってない）ならば
    • Stored VariableのusersにEmpty Listをいれてリスト型変数として初期化する

のような動きが作れます。
こうすることによって、「本当の」初回起動時だけ初期化、それ以降は初期化せずに保存されている値を継続利用、というような動きが作れます。
通常の学習では、変数を習ってから WhenブロックやIfブロックを習うという順番で学習していくため、このStored Variableの初期化が最初の妻月になることが非常に多いようです。
なので、initialize、when、ifのこの３点セットは「こういったもの」としてStored Variableを使うときには必ず最初に塊として覚えておくといいでしょう。

Cloud Variable

Cloud Variableは、クラウド上の保存領域に箱が用意されている変数です。

Cloud Variableを使うときはこんなとき

Cloud Variableは端末（スマホ）ごとの領域ではなく、そのアプリを使っている利用者全体で１つの領域が使われます。
そのため、いろいろな利用者の間で情報を共有するようなSNSをつくるときには、SNS上に表示する内容にはCloud Variableを使うことになります。

なぜ、Cloud Variableなのか？

App VariableやStored Variableでは、同じアプリを使っていても変数が格納される場所が端末（スマホ）ごとになってしまうため、他の端末（他の人）からの投稿を自分がみたり、自分の投稿を他の端末（他の人）が見たりすることができません。
すなわり、他の人に見せたくないものはCloud Variableにいれたらダメなのですが、見せたいものは入れないといけないということになります。

Cloud Variableの初期化方法

Cloud Variableの初期化方法もinitializeブロックですが、初期値は指定できません。
どうして初期値が指定できないといえば、initializeブロックで初期値を指定してしまうと、誰かがアプリを実行するたびに初期値に初期化されてしまって、せっかく残っていた前回終了時の値が消えてしまうからです。
それではどう初期化すればいいのでしょうか。
アプリ実行時の一番最初に開く画面のオープン時に「まだ初期化されていなかったら初期化する」というIfブロックを使って初期化します。

上のようにブロックを組むことによって

• Screen1がOpneするとき(When)
  • もし(if)、Cloud Variableのusersがnull（値が入ってない）ならば
    • Cloud VariableのusersにEmpty Listをいれてリスト型変数として初期化する

のような動きが作れます。
こうすることによって、「どこかのだれか最初にアプリを使った人」の「本当の」初回起動時だけ初期化、それ以降は初期化せずに保存されている値を継続利用、というような動きが作れます。

Cloud Variableはどこに保存されるのでしょう

変数を格納できるクラウドサービスは様々なものがありますが、Cloud Variableの格納先はFireBaseとなります。
firebase.google.com

格納先のFireBaseを指定する

FireBaseに格納するといっても、FireBaseの「どこ」に？という疑問が湧いてきます。FireBaseを使うときには

• どこに：DatabaseURL
• どのアプリが：API Key

の２つを指定して、FireBaseの「どこ」に「どのアプリ」が読み書きするを紐付けます。

FireBaseプロジェクトの追加

1. FireBaseを使ってみる

2. プロジェクトを追加

3. 名前を付ける

4. Google アナリティクスの構成

FireBaseプロジェクトの構成

表現がわかりづらいですが、アプリからFireBaseを使うための設定を行うことを「アプリを追加」とFireBaseでは呼びます。
Thunkableのアプリの種類「ウェブ」になります。
1. FireBaseにウェブアプリを追加

2. アプリの登録
アプリ名は何でもいいので「Thunkable」としておくといいでしょう。

3. Firebase SDK の追加
特に何もせず「コンソールに進む」をクリックします。

サインインの方法を追加

コンソールが表示されたらAuthenticationを選んで、FireBaseへのサインイン方法を設定します。
1. 始める

「始める」をクリックします。
2. 「メール/パスワード」プロバイダを選択します。

3. メールとパスワードで登録できるように「有効」にして「保存」をクリックします。

RealtimeDatabaseの作成

コンソールのRealtimeDatabaseをクリックします。
1. データベースを作成

「データベースを作成」をクリックします。
2. ロケーション設定

「米国」を選択して「次へ」をクリックします。
3. セキュリティルール

「ロックモード」を選んで「有効にする」をクリックします。
4. 公開する
ルールをクリックしてルールの中の「false」を「"auth != null"」に変更して「公開する」をクリックします。

これは「認証が通っているときのみ読み書きできる」という最低限のルールになるので、アプリに準じたルールに適時書き換える必要があります。
でも、まずは、これでドンドン開発を進めてみてください。

API KeyとDatabaseURLを確認する

1. ウェブAPIキー

API Keyは、FireBaseコンソールの「プロジェクトの設定」に「ウェブAPIキー」という項目名で表示されています。
2. DatabaseURL

DataBaseURLはRealtime Databaseの「データ」のところに表示されます。

API KeyとDatabaseURLをThunkableのプロジェクトに紐付ける

FireBase側でAPI KeyとDatabaseURLが設定できたら、それをThunkableのプロジェクトに紐付けます。

Thunkableの「Design」で左側に表示される一番したの歯車マークのSettingsをクリックすると色々な設定を入れる場所がでてくるので、そこをスクロールしてFireBaseと表示されているところの[API Key]と[DatabaseURL]をみつけてください。
ここにFireBase側で表示されている「API Key」と「DatabaseURL」をコピーします。

ここまでのまとめ

1. ThunkableのCloud VariableはFireBaseというクラウドデータベースに保存される
2. FireBaseとThunkableアプリ（Thunkableプロジェクト）はAPI KeyとDatabaseURLの２つの値で紐付ける
3. API Keyは、FirebaseのサイトでFirebaseプロジェクトを作成すると表示される
4. DatabaseUrlは、Firebaseコンソールで、FireBaseプロジェクトを指定してRealtime Databaseを作成すると表示される
5. アプリからFireBaseにサインインするためにAuthenticationでアプリからのサインイン方法を指定する

ユーザ登録（サインアップ）を実現するブロック

アプリからFirebaseにサインインするためには、まずは、Firebaseに対して、そのアプリのユーザ登録（サインアップ）を行わなければなりません。
ユーザ登録は２つのステップがあります。

1. メールアドレスとパスワードの登録
2. 登録したメールアドレスに届く認証メールのURLをクリックして、メールアドレスの有効性確認（なりすまし防止）

メールアドレスとパスワードを登録するためのブロック

Thunkableアプリで、Firebaseに【そのアプリの利用】ユーザ登録を行うためには「Firebase Sign Up」ブロックを使います。
「Firebase Sign Up」ブロックは、Blocksの左サイドメニューの[App Features]-[Sign In]グループの中にあります。

この「Firebase Sign U」ブロックですが、このまま使わずに、右クリックでメニューを表示して[Show Advanced Block]を選んで拡張表示ブロックにしてから使います。

拡張表示ブロックにすることで、FirebaseへSign Upしたときの処理結果を処理できるようになります。

IfブロックでErrorだったらラベルにエラーメッセージを表示し、
Errorではければ（else）つまり正常ならば "認証メールのURLをクリックしてサインアップを完了してください。"と表示するような処理を行います。

よくあるエラーと防止策

よくあるエラーとしてはパスワードの長さが短い場合で、そのようなときは次のようなエラーとなります。

Firebase: Password should be at least 6 characters (auth/weak-password).

このようなエラーを防ぐためには、パスワード欄に６文字以上入力された時だけサインアップボタンが押せるようにするとよいでしょう。

このほかによくあるエラーとしては、すでに登録済のメールアドレスが指定されたときです。そのときには次のようなエラーメッセージとなります。

Firebase: The email address is already in use by another account.

ユーザー登録と認証について

正常にサインアップできたら、入力したメールアドレスとパスワードがFirebaseのAuthenticationに登録され、認証メールが送信されます。
認証メールをクリックするまでは、メールアドレスは「有効」になっていないため、Firebaseにはユーザ登録できていますが、アプリの登録ユーザーとしては認証されていないので、Cloud Variableに値の出し入れはできません。

認証メール

認証メールが届いたらリンクをクリックします。正しく認証できれば、次のような表示がでます。

サインインを実現するブロック

Thunkableアプリで、Firebaseに【そのアプリの利用】ユーザのサインインを行うためには「Firebase Sign In」ブロックを使います。
「Firebase Sign In」ブロックは、Blocksの左サイドメニューの[App Features]-[Sign In]グループの中にあります。

メールアドレスとパスワードでサインインを実行して

• もし(If)、errorだったら
  • Message_Labelにエラーメッセージを表示
• そうではなく(else)もし(if)、認証済(is email verified>)じゃない(not)なら
  • "認証メールのURLをクリックしてサインアップを完了してください。"と表示
• それ以外(else) 、つまりメール認証も済んでいるのなら
  • App Variable IDにFirebaseで認証された「user id」値を代入し、App Variable IDがnullかどうかで認証できているかが一目で分かるようにしておく

という処理を実施します。

サインインできたあとの具体的な動きの例

サインインできた後の動きはアプリごとに異なりますが、ここでは、名前などのプロファイルが登録されていれば「Main_Screen」、登録されていなければ「Profile_Screen」を表示する動きになるようにelseブロックの中を拡張してみましょう

App Varialble Mailの初期化

elseブロックの最初の命令は、プロファイルが登録されているかどうかの判定用のApp Variable LastNameの初期化です。
後々、nullだったらプロファイルなしという判断をしたいので、ここでnullを代入しています。

Cloud Variable Usersの初期化

elseブロックの次の命令は、もし(if)、Cloud Variable users自体がFirebase上に存在しない(=null)だったらというIfブロックです。
存在しない場合は、empty listを設定します。このブロックが実行されるとFireBaseのRealtime Database上に「users」というテーブルが作成されます。

usersテーブルからのプロファイルの取り出し

Cloud Variable usersが存在しない以外(else)の場合、つまり、存在する場合は、「cloud variable users」から１行づつ取り出してサインインした人のプロファイルデータを探します。

１行づつ取り出すのは、[for each item]ブロックとなります。取り出した行は変数userに格納されます。この「user」ですがブロック初期値は「j」となっていますがわかりやすくするために名前を変更しています。
もし(if)、変数userには複数の要素が含まれているので、要素(property)「ID」が「App Variable ID」ならば、その行がサインインした人のプロファイルになるので「App Variable LastName」を設定しています。
あとはプロファイルが見つかったので[Break out of loop]ブロックで[for each item]ブロックのループから抜けます。

### プロファイルのあるなしで次の画面を判断する
[for each item]ブロックを抜けたときに、「App Variable LastName」は２つの状態が考えられます。
プロファイルが最後まで見つからなかった時の「null」と、見つかったときにLastNameが入っている状態です。
そこで、もし(if)、「App Variable LastName」が「null」だったならば、[Navigate]ブロックで「Profile_Screen」画面に移動します。
それ以外(else)ならば、[Navigate]ブロックで「Main_Screen」画面に移動します。

Profile_Screen画面でのBlocks

それでは最後にProfile_ScreenでFireBaseのusersテーブルに値を設定する部分を紹介しましょう。

1. IDとMailはサインイン画面でApp Variableに設定されているので、あとはプロファイル画面で「姓」「名」を入力したオブジェクト（１行分の要素の入ったもの）を[Create Object]ブロックで作成
2. オブジェクトを[in list]ブロックを使って、「Cloud Variable Users」テーブルの最後(last)に追加(insert at)します。

[Create Object]ブロックは、Blocksの左サイドメニューの[core]-[Objects]の中にあります。
[in list]ブロックは、Blocksの左サイドメニューの[core]-[Lists]の中にあります。

Cloud Vairableへの「代入」がFireBaseへの格納

FireBaseへのサインインが成功している状態でのCloud Variableへの代入はになります。

ちょっとした工夫

名前を入力せずにプロファイルを登録できないように次のように入力欄チェックをいれておくとよいでしょう。

最後に

ThunkableでSNSを作るときに必要になってくる知識の中で「変数」に着目してみました。
FireBaseの設定の仕方から、ThunkableでFireBaseがどのようにみえるのか、FireBase側とThunkable側を対比することで少しだけイメージしやすくなったのではないでしょうか。
次回は、なぜ、Cloud Variable usersの要素をどうきめたのか、また、自分の投稿と他の人の投稿はどう区別がつくようにできるのかなど「テーブル要素」に注目してご紹介します。
hatsune.hatenablog.jp

Thunkableでノーコードアプリケーション開発を極めよう

Thunkableって知っていますか？
thunkable.com
Thunkableは、scratchのようなビジュアルプログラミングでモバイルアプリ開発ができるツールです。
ブラウザでプログラミングできるだけではなく、アプリ画面デザインやテスト動作などもブラウザで行うことができるため、Androidアプリ、iOSアプリ、Webアプリ（PWA）などが実機がなくても開発できてしまうというツールです。

Thunkableの特徴

Thunkableの特徴の一つは「Block」と呼ばれる部品を使ってロジックがかける点です。

基本的な使い方は、画面左端にあるCoreと書かれているところからBlockを選んで、それを組み合わせます。
ブロックの形には上に凹、下に凸があるブロックと、右に凹、左に凸があるブロックがあります。
上下の凹凸のブロックを縦に並べることでプログラムの流れが作れます。左右の凹凸は数式などに使うブロックになります。

Blockには次のようなCoreブロックと呼ばれる基本的なBlockの種類があります。

• Control
• Logic
• Math
• Text
• Lists
• Color
• Device
• Objects
• Variables
• Functions

そのほかにも、App Featuresと呼ばれるデバイス特有の機能を使うBlock、AdvancedとよばれるWeb APIやOpenAIを呼び出すのに便利なBlockがあります。

今回の一連の投稿では、１つ１つの機能を網羅的に説明するのではなく「〇〇するには」のような遣りたいことデザインパターンを色々紹介していきます。

Index

1. hatsune.hatenablog.jp
2. hatsune.hatenablog.jp

次回投稿をお楽しみに！

Microsoft AI Tour Tokyoに参加して思ったこと

少し報告が遅くなってしまいましたが、2024年2月に開催された「Microsoft AI Tour Tokyo」について、参加した感想を書きます。
news.microsoft.com

一言でいえば「最高のMicrosoftグローバルイベント」でした。

まずゆるゆると入場する感じがいいし、入ったら軽食とコーヒーがあるのがBuildとかIgniteっぽいしと開場からセッションが始まるまでの時間がすばらしい。会場も通路というか導線が広くて、何よりも外の景色が見えるのがいい。

キーノートや各セッションもすばらしかったのですが、特筆すべきはハンズオンですね。
２回お手伝いさせていただいたのですが、時間内で動くところまでもっていくコンテンツの流れもよかったのですが、参加している人たちの真剣度が高く「このハンズオンで知識をものにする」という思いが会場に満ちていて、それがよい空気感をだしていて、すごく素敵な空間になっていました。
ハンズオンで立ち見という状況が生じていて、着席できた人も背後からの（立ったままノートPCを抱えてハンズオンしている立ち見勢の）勢いに圧されてというのもあったかも。

つまずいたり質問がある場合には挙手していただいて、手伝っている我々が駆けつけてトラブルシューティングをしていたのですが、そこで感じたのは、参加者の中には、明らかにマイクロソフトのツールが初めてという方もいらっしゃるけれど、「使ったことないから」としり込みするのではなく「使ったことがないからこそ」という前向きな気持ちが、手伝っているこちら側としても気持ちよくサポートできたので、手伝わせてもらってありがとうという気持ちになりました。