前回は「 iOS / Android でもずんだもんにおしゃべりさせるのだ!」として、オフィスの受付に配置することを想定した訪問者無人受付のモバイルアプリケーションを作成しました。
ただ、「無人受付」といっても、訪問者の名前や人数を復唱するだけであり、解決すべき課題は多く残されていました。
今回はこれら課題の解決手段として RAD Server を導入し、『ずんだもん』と一緒に活躍してもらいたいと思います。 RAD Server 未体験の方にも読んでいただけるような構成を心がけましたので、ぜひ最後までお読みください。
なお、構成の都合上、前回の記事 の続編となっておりますので併せて前回の記事もご覧になってください。
※ 本記事における「ずんだもん」という表記は、特に断りのない限り音声(音源)の利用を指すものとします。なお、実際にアプリケーションへ組み込み、運用する際には、必ず公式サイトの利用規約をご確認ください。
ちょっと待って! RAD Server ってなに?
さて、いきなり RAD Server という言葉が出てきました。RAD Server という言葉に馴染みのない方にとっては少し唐突だったかもしれません。
ここでは、まず簡単に RAD Server について触れておきます。
RAD Server を一言で言えば「サーバー側の機能を構築する基盤」です。RAD Server という名前の通り、アプリケーションはサーバー上に配置して運用されます。
サーバーと聞くと、データベースやメールサーバーのように、あらかじめ役割が決まっているものを思い浮かべるかもしれません。一方で RAD Server は、最初から用途が決まっているわけではなく、なにをさせるかは開発者が設計・実装していきます。その際に必要な基本機能はあらかじめ用意されており、それらを組み合わせることで効率よくサーバー機能を構築できる点が特徴です。
RAD Server に実装した機能は、HTTP(S) を通じて呼び出します。あらかじめ用意した URL にアクセスすることで実行され、この URL をエンドポイントと呼びます。
一例として、一般的なデスクトップアプリケーションのプログラミングではTZundamon.TalkToMe(‘goose’);
のような書式で機能を実行します。
一方で REST API では、HTTP(S) プロトコルを介して URL にアクセスすることで機能を実行します。
例えば、https://your-server/zundamon/talktome/?who=goose
のように指定します。
REST API でのやり取りは主に JSON と呼ばれる形式のテキストで行われます。この仕組みはデータのやり取り全般で広く使われており、前回・前々回ご紹介したような VOICEVOX アプリケーションへの『ずんだもん』音声データの作成・取得にも利用されています。
RAD Server を使用した REST API の実装は、Delphi や C++Builder を用いて行うことができます。
そのため、FireDAC や Indy など馴染みのあるコンポーネントをそのまま活用することが可能です。
既存のプロジェクトで作成したコードや資産を再利用しながら、効率的にアプリケーションサーバを構築できる点も、RAD Server の大きな特徴と言えるでしょう。
課題を整理
前回の記事で作成したアプリケーションの現状と今回の課題を整理したいと思います。
現状:
- 来訪者および同行人数を入力するモバイルアプリケーションの用意はできている
- 入力内容を元にウェルカムメッセージを作成し『ずんだもん』で発話することが可能
課題:
- 入力された来訪者情報を社内に通知する仕組みがまだ実装できていない
- 入館時の処理として、来訪者履歴を記録したい
上記の「課題」は iPad アプリに追加実装することで対応可能です。しかし、耐障害性や拡張性等を考慮すると、iPad の責務は入力インターフェースに留め、業務処理は RAD Server へ集約する設計が望ましいでしょう。
無人受付システム構成例
図は前章の課題に対応したシステム構成です。(図をクリックすると拡大表示します)
受付入力端末 (プロジェクト名:ZundaTx)の役割
- 来訪者情報の入力
- 入力された来訪者情報を RAD Server へ送信し、音声データの作成をリクエストする
- RAD Server のレスポンスを受信し音声データを一時フォルダに保存する
- 音声データを再生(『ずんだもん』の音声を再生)
RAD Server (プロジェクト名:ZundaSvr)の役割
- タブレット端末で入力された内容の受信
- 『ずんだもん』音声データの作成 (VOICEVOXを使用)
- 社内通知アプリケーションへの通知 (※ UDP ブロードキャストを使用)
- 受付内容の記録
社内通知アプリケーション (プロジェクト名:ZundaRx)の役割
- RAD Server から送信(ブロードキャスト)された来訪者情報の受信
- 来訪者情報の表示
実装例
次に、各プロジェクトの実装例を見ていきましょう。
受付入力端末 (ZundaTx)の実装
受付入力端末は、前回作成したマルチデバイスアプリケーションのプロジェクトを引き続き使用します。このプロジェクトの詳細については 前回の記事 をご覧ください。
なお、RAD Studio 13 Florence 時点では Delphi のみ iOS/Android OS アプリケーションに対応し、C++Builder ではご利用いただけません。
デザイン例
画面デザインについては、前回と全く同じものを使用します。
引き続き、氏名、人数入力用 TEdit、 受付の TButton、さらに TMediaPlayer、TRestClient、 TRestRequest、 TRestResponse は必要なコンポーネントです。それ以外のレイアウトや配色についてはお好みで変更することが可能です。
コード例
コードについても前回使用したプロジェクトを使用します。但し、前回は VOICEVOX が用意した REST API をコールしていましたが、今回は RAD Server で用意する REST API (http://your-server/ZundaAPI) をコールします。また、前回作成したプロシージャ GoZunda は RAD Server 側で処理しますので、削除して大丈夫です。
// 受付ボタンクリックイベント
procedure TForm1.ButtonUketsukeClick(Sender: TObject);
var
LWavFile : String; // 音声ファイル名
LWavData : TBytes; // RAD Serverから受信した音声データ
LFileStream : TFileStream; // TFileStream
begin
{$IFDEF DEBUG}
RestClient1.BaseURL := 'http://192.168.0.100:8080/ZundaAPI'; // FIXME:DEBUG環境のURLに修正
{$ELSE}
RestClient1.BaseURL := 'http://192.168.0.100/Radserver/EMSServer.dll/ZundaAPI';// FIXME: 運用環境(IIS)で運用する場合のURLに修正
{$ENDIF}
RESTRequest1.Response := RESTResponse1; // デザイナで設定済みならコメント
// WavFileのパス作成
LWavFile := System.IOUtils.TPath.Combine(System.IOUtils.TPath.GetTempPath,'ANSWER.wav') ;
// 音声再生中の場合は中断
LabelInfo.Visible := False;
if MediaPlayer1.State <> TMediaState.Stopped then
begin
MediaPlayer1.Stop;
end;
// 音声データをクリア
if FileExists(LWavFile) then
DeleteFile(LWavFile);
// リクエスト実行
RESTRequest1.AddParameter('visitor',EditVisitorName.Text); // 訪問者名
RESTRequest1.AddParameter('number',EditNumber.Text); // 人数
RESTRequest1.Execute;
// リクエスト結果受信
LWavData := RestResponse1.RawBytes;
if Length(LWavData) > 0 then
begin
LFileStream := TFileStream.Create(LWavFile, fmCreate);
try
LFileStream.WriteBuffer(LWavData[0], Length(LWavData));
finally
LFileStream.Free;
LabelInfo.Visible := False;
end;
MediaPlayer1.FileName := LWavFile;
MediaPlayer1.Play;
end;
end;
// テキストを元に音声データ作成
procedure TForm1.FormCreate(Sender: TObject);
begin
// 情報ラベル初期化
LabelInfo.Visible := false;
end;
RAD Server(ZundaSvr)の実装
RAD Server の準備
InterBaseがインストールされていることを確認します。これは RAD Server を機能させるための情報を InterBase に格納するためです。
開発目的で実行する場合は InterBase Delpoler Edition が利用可能です。これは RAD Studio の [ツール > 機能の管理] を選択し、InterBase Devloper Edition にチェックを入れた状態で[適用] を選択してInterBaseをインストールし、サービスをあらかじめ起動しておきます。
InterBaseをインストールしたら、RAD Server パッケージ プロジェクトを以下の手順で作成します
RAD Studio より [ファイル > 新規作成 > その他 > Delphiプロジェクト > RAD Server > RAD Server パッケージ] を選択します。
RAD Server パッケージウィザードが起動したら「リソースを含むパッケージを作成する」を選択します。
リソース名を ZundaAPI として(またはお好みの名前で) [次へ]を選択します。
今回のアプリケーションでは Get エンドポイントのみ使用しますので、GetItem エンドポイントのチェックボックスは Off にし、[完了]を選択します。
デザイン例
プロジェクトのスケルトンが作成されたら、Unit1 に TRestClient, TRestRequest および TRESTResponse を配置します。 さらに来訪者履歴をデータベースに保存します。今回は InterBase ToGo Lite (旧称 IBLite)を使用するため、TFDConnection も配置します。
コード例
『ずんだもん』音声データ作成エンドポイントを含むデータモジュールを以下の通り実装します。
unit Unit1;
// EMS Resource Module
interface
uses
System.SysUtils, System.IOUtils, System.Classes, System.JSON, REST.Types,
FireDAC.Stan.Intf, FireDAC.Stan.Option, FireDAC.Stan.Error, FireDAC.UI.Intf,
FireDAC.Phys.Intf,
FireDAC.Stan.Def, FireDAC.Stan.Pool, FireDAC.Stan.Async, FireDAC.Phys,
FireDAC.Phys.IB, FireDAC.Phys.IBLiteDef, FireDAC.ConsoleUI.Wait, Data.DB,
FireDAC.Comp.Client, REST.Client, Data.Bind.Components, Data.Bind.ObjectScope,
EMS.Services, EMS.ResourceAPI, EMS.ResourceTypes, IdUDPClient, IdGlobal;
type
[ResourceName('ZundaAPI')]
TZundaAPIResource1 = class(TDataModule)
RESTClient1: TRESTClient;
RESTRequest1: TRESTRequest;
RESTResponse1: TRESTResponse;
FDConnection1: TFDConnection;
procedure DataModuleCreate(Sender: TObject);
private
FLogPath: string; // 来歴データベースのパス
procedure GoZunda(const AText: string; out AData: TBytes);
published
[EndPointRequestSummary('Tests', 'ListItems', 'Retrieves list of items',
'application/json', '')]
[EndPointResponseDetails(200, 'Ok', TAPIDoc.TPrimitiveType.spObject,
TAPIDoc.TPrimitiveFormat.None, '', '')]
procedure Get(const AContext: TEndpointContext; const ARequest:
TEndpointRequest; const AResponse: TEndpointResponse);
end;
implementation
{%CLASSGROUP 'System.Classes.TPersistent'}
{$R *.dfm}
// 起動時の処理
procedure TZundaAPIResource1.DataModuleCreate(Sender: TObject);
begin
// 開始
TEMSEndpointEnvironment.Instance.LogMessage(Format('DataModule %s is being created', [Self.Name])); // コンソール+ファイルにログ出力
// DBの場所セット
FLogPath := TPath.Combine(TPath.GetTempPath, 'Zundalog.ib');
// 本番系では配置場所に書き込み権限があるか確認
TEMSEndpointEnvironment.Instance.LogMessage(Format('Database path = %s',
[FLogPath]));
// FDConnection初期化(デザイナで定義する場合コメント)
with FDCOnnection1 do
begin
Params.Clear;
DriverName := 'IBLite';
Params.Add('Database=' + FLogPath);
Params.Add('User_Name=sysdba');
Params.Add('Password=masterkey');
Params.Add('CharacterSet=UTF8');
end;
// IBLiteの確認
if TPath.Exists(FLogPath) = false then
begin
TEMSEndpointEnvironment.Instance.LogMessage('Database not found. Creating new database');
// IBLiteが存在しない場合は作成
with FDConnection1 do
begin
Params.Add('OpenMode=OpenOrCreate');
Connected := true;
ExecSQL(
'CREATE TABLE T_VISITORLOG (' +
' VISIT_DATE VARCHAR(32) NOT NULL, ' +
' VISITOR_NAME VARCHAR(255) NOT NULL, ' +
' VISITOR_NUMBER VARCHAR(8) NOT NULL' +
')'
);
FDConnection1.Close;
end;
end;
end;
// エンドポイント http://your-server/ZundaAPI の処理
procedure TZundaAPIResource1.Get(const AContext: TEndpointContext; const
ARequest: TEndpointRequest; const AResponse: TEndpointResponse);
var
LRequestTime: TDateTime; // リクエスト受付時刻
LVisitor: string; // 訪問者氏名
LNumber: string; // 訪問者人数
LText: string; // 音声データにする文章
LInfoText: string; // 社内に配信するメッセージ
LBuffer: TBytes; // 音声データ
LMessage: TIdBytes; // 社内に配信するメッセージ(Byte配列)
LUDPClient: TIdUDPClient; // UDPクライアント
begin
// 開始
TEMSEndpointEnvironment.Instance.LogMessage('ZundaAPI: Start prosessing request');
// 受付時刻取得
LRequestTime := Now;
// パラメータ取得 内容チェックの処理は省略
LVisitor := ARequest.Params.Values['visitor'];
LNumber := ARequest.Params.Values['number'];
TEMSEndpointEnvironment.Instance.LogMessage(Format('Parameters LVisitor=%s,LNumber=%s', [LVisitor, LNumber]));
// 受付内容の記録を行う
with FDCOnnection1 do
begin
Connected := true;
ExecSQL('INSERT INTO T_VISITORLOG VALUES(:VISIT_DATE, :VISITOR_NAME, :VISITOR_NUMBER)', [LRequestTime, LVisitor, LNumber]);
Connected := False;
end;
TEMSEndpointEnvironment.Instance.LogMessage('Visitor data saved');
// 音声にする文章を作成
LText := LVisitor + '様';
if LNumber <> '0' then
LText := LText + 'ほか' + LNumber + 'めい様';
LText := LText + '受付が完了しました。担当者が参りますのでこのままお待ちください';
TEMSEndpointEnvironment.Instance.LogMessage(Format('Message=%s', [LText]));
// 音声データ作成
GoZunda(LText, LBuffer);
// 音声データレスポンスデータに添付する
AResponse.Body.SetBytes(Lbuffer, 'application/octet-stream');
TEMSEndpointEnvironment.Instance.LogMessage('Response data sent');
// 社内LANで配信(UDP)
LUDPClient := TIdUDPClient.Create(nil);
try
LInfoText := '【受付】' + FormatDateTime('yyyy/mm/dd hh:nn:ss', LRequestTime) +
'|' + LVisitor + '様他' + LNumber + '名様';
with LUDPClient do
begin
LMessage := ToBytes(LInfoText, IndyTextEncoding_UTF8);
Broadcast(LMessage, 50022);
end;
TEMSEndpointEnvironment.Instance.LogMessage('UDP data sent');
finally
LUDPClient.Free;
end;
// 終了
TEMSEndpointEnvironment.Instance.LogMessage('ZundaAPI: End prosessing request');
end;
// VOICEVOXのREST APIを実行し音声データを作成します
procedure TZundaAPIResource1.GoZunda(const AText: string; out AData: TBytes);
var
LJsonObj: TJSONObject; // TJSONObject
begin
// コンポーネント類初期化(デザイナで設定済みであれば省略可能)
RestClient1.BaseURL := 'http://127.0.0.1:50021';
// FMXME: VOICEVOXを別PCに配置する場合は変更
RestRequest1.Method := rmPOST;
RESTRequest1.Client := RESTClient1;
RESTRequest1.Response := RESTResponse1;
// 1. audio_query 呼び出し
with RestRequest1 do
begin
Resource := 'audio_query';
Params.Clear;
AddParameter('text', AText, pkQUERY); // 発話内容の文字列
AddParameter('speaker', '1', pkQUERY); // SpeakerId 1はずんだもん
Body.ClearBody;
Execute;
end;
// RestResponse1.StatusCode のエラー判定
if RESTResponse1.StatusCode <> 200 then
raise Exception.Create('Error RESTResponse1.StatusCode = '
+ RESTResponse1.StatusCode.ToString);
// 2. synthesis 呼び出しと JSON のパース
LJsonObj := TJSONObject.ParseJSONValue(RestResponse1.Content) as TJSONObject;
try
with RestRequest1 do
begin
Resource := 'synthesis';
Params.Clear;
Body.ClearBody;
AddParameter('speaker', '1', pkGETorPOST);
AddBody(LJsonObj.ToJSON, ctAPPLICATION_JSON);
Execute;
end;
// RestResponse1.StatusCode のエラー判定
if RESTResponse1.StatusCode <> 200 then
raise Exception.Create('Error RESTResponse1.StatusCode = '
+ RESTResponse1.StatusCode.ToString);
// Wavファイルを保存
if Length(RESTResponse1.RawBytes) > 0 then
begin
AData := RestResponse1.RawBytes;
end
else
begin
raise Exception.Create(Length(RESTResponse1.RawBytes).ToString);
end;
finally
LJsonObj.Free;
end;
end;
procedure Register;
begin
RegisterResource(TypeInfo(TZundaAPIResource1));
end;
initialization
Register;
end.
全てのコードを書き終えたらRAD Studio [実行 > 実行 (またはF9)] を選択します。初回起動時は、EMS セットアップウィザードが起動されますので、指示に従いセットアップを完了させます。
セットアップが終了すると、図のようなアプリケーションが起動され、RAD Serverがリクエストを受信できる状態になります。
さらに VOICEVOX を起動後、RAD Studioでは[ツール > REST デバッガ]を選択し、指定のエンドポイントにアクセスできるか確認します。
図の通り、メソッドを GET、URLを http://localhost:8080/ZundaAPI/?visitor=a&number=10 とし「要求の送信」をクリックします。
要求の送信結果、応答としてデータを受信することが出来ました。
さらに RAD Development Server にもログが出力されています。
社内通知アプリケーション (ZundaRx)の実装
このセクションでは RAD Server が配信する来訪者の情報を受信し、受付担当者に通知するアプリケーションを作成しますが、現時点ではまだ決定していないポイントが1つあります。
それは、『来訪者のお知らせをどのように担当者へ伝えるか』です。
1つの方法として、下のイメージ図のようなデジタルサイネージ(電子掲示板)用の大型ディスプレイを使用する方法です。
トライアル目的での導入であれば、受付担当者のPCにアプリケーションをインストールして、トースト通知で伝える方法もありますし、スマートフォンアプリの通知バナーを使う方法も考えられます。このように「後から決定したい」場合でも Delphi で作成するマルチデバイスアプリケーションであれば、あとから使用するハードウエアやスケールにあわせて修正することを柔軟に行うことが出来ます。
以下は今回の実装例の実行結果です。これらは同じDelphiコードを使用し、ターゲットプラットフォームをそれぞれ Windows / Android に切り替えてビルドしたものです。
Windows11のトースト通知表示例
Androidスマートフォンの通知表示例
※ 今回の通知は UDP を使用した簡易的な仕組みとなります。RAD Server を使用したプッシュ通知についてはこちらの記事を御覧ください。
フォームデザイン例
以下の例は動作確認を目的とした Windows アプリケーションとしてのデザイン例です。今後の iOS/Android や MacOSデスクトップアプリケーションへの展開を前提とし、FMX マルチデバイスアプリケーションで作成します。
フォームには UDPデータ受信用の TIdUDPServer、 データ受信内容を表示するための TMemo、そしてトースト通知やバナー通知を行なうための TNotificationCenter を配置します。
今回の例でのフォームデザインの見栄えはあまりよくありませんが、『まずは動かせること』を目標とし、最小構成のアプリを制作します。
コーディング例
// TIdUDPServer OnUDPReadイベント
procedure TForm1.IdUDPServer1UDPRead(AThread: TIdUDPListenerThread;
const AData: TIdBytes; ABinding: TIdSocketHandle);
var
LMessage :String; // 通知テキスト
LNotification : TNotification; // アプリケーション通知
begin
// メッセージ内容を取得
LMessage := BytesToString(AData,IndyTextEncoding_UTF8 );
// Memoに追記
Memo1.Lines.Add(LMessage);
// アプリケーション通知
LNotification := NotificationCenter1.CreateNotification;
try
//
with LNotification do
begin
Name := 'ZundamonNotification';
Title := '来訪者のお知らせ';
AlertBody := LMessage;
end;
NotificationCenter1.PresentNotification(LNotification);
finally
LNotification.Free;
end;
end;
無人受付システム動作確認
さて、今回作成した3つのプロジェクトの準備が出来ました。ビルドを済ませ、それぞれのプロジェクトを配置し、起動してみましょう。VOICEVOX の起動も忘れずに行います。
それぞれのプロジェクトが連携できているかを以下の手順で確認します。
① 受付入力端末(ZundaTx)で、氏名・同行者人数を入力し「受付」ボタンをタップします。
②RAD Server(ZundaSvr)で RAD Development Serverのログに「 REQUEST RECEIVED(リクエスト受信)」が出力されます。
③受付入力端末で『ずんだもん』の音声が再生されます。
④社内通知アプリケーション (ZundaRx)で「来訪者のお知らせ」トースト通知(Windowsの場合)が表示され、来訪者氏名と同行者人数が表示されます。
⑤ZUNDALOG.IB データベースの内容を確認し、来訪者データの内容が記録されていることをFireDAC エクスプローラ 等で確認します。(※ データベースはテンポラリフォルダ(例 “C:\Users\YOUR_USERNAME\AppData\Local\Temp\Zundalog.IB“に保存されています)
最後の仕上げ!運用環境への移行
ここまでで、それぞれのプロジェクトが正常に起動し、互いのプロジェクトが連携し合って動作していることが確認できました。
しかしながら、RAD Development Server はあくまで RAD Server アプリケーションの開発目的で、そのまま運用環境で利用することは現実的ではありません。(もうこの時点で『おなかいっぱい』と感じられている方もいらしゃるかもしれませんが、あと一息です!)
実際に RAD Server を本番環境で使用するためには、IIS や Apache といった Web サーバで利用する拡張モジュール(ISAPI / Apache モジュール)として配置・実行する構成が一般的です。
IIS やApache での配置は RAD Stuioオンラインヘルプ「 Windows での運用環境への RAD サーバーまたは RAD サーバー コンソールのインストール 」がご参考いただけます。また、RAD Server Installer をご利用いただくことでスピーディーな RAD Server の環境構築が可能です。
※ ご注意: RAD Server Installer のご利用にあたっては 以下の記事に補足事項がありますので併せてご確認ください
- RAD Server Installer for Windows によるセットアップ環境で EMSServer.exe が起動しない
- RAD Server Installer for Windows で Embarcadero製品登録が起動しない
図は IIS にRAD Server を配置した階層イメージです。
IIS/ Apacheで運用する際の留意点
RAD Server アプリケーションを IIS/Apache 上で運用する場合、RAD Development Server を使用したデバッグ環境とは動作や設定が異なる点があります。本番環境(IIS/Apache)へ展開する際は、以下の点に注意してください。
エンドポイント URL の違い
RAD Development Server でのエンドポイントは通常、次のような形式になります。http://your-server:8080/ZundaApi
一方、IIS 環境では ISAPI モジュール(EMSServer.dll)を経由するため、エンドポイントは次のような形式になります。http://your-server/radserver/EMSServer.dll/ZundaApi
なお、ポート番号や仮想ディレクトリは IIS の設定によって異なる場合があります。
補足: エンドポイントを任意のものにしたい場合は URL Rewrite Module(IIS)や mod_rewrite (Apache) を使用することで変更が可能です。
ファイルアクセス権の違い
アプリケーション内でファイルの読み書きを行う場合は、ファイルの配置場所とアクセス権限を事前に検討する必要があります。
例えば C:¥Temp¥ などのディレクトリに対して書き込みを行う場合、本番環境(IIS/Apache) ではエラーになることがあります。これは、IIS のワーカープロセスがデバッグ環境とは異なるアクセス権限で実行されるためです。そのため、必要に応じて対象ディレクトリに対して IIS のアプリケーションプールユーザーへ適切なアクセス権を付与する必要があります。
以下の例はIISのプロセスで C:¥Temp のフォルダに書き込みを行なうためのアクセス権限の設定例です。
IISのワーカープロセスが radserver で実行されている場合、ユーザ「IIS AppPool¥radserver」に対しアクセス権限を設定します。
ファイルパスの違い
デバッグ環境(RAD Development Server)と 本番環境(IIS/Apache) の実行環境では、System.IOUtils.TPath で取得できるパスが異なる場合があります。
例えばデバッグ環境で TPath.GetTempPath の実行結果は C:¥Users¥<ユーザ名>¥AppData¥Local¥Temp ですが、IIS環境では C:¥Windows¥Temp¥ が返ります。このように、本番環境ではデバッグ環境と異なるパスが返ることを念頭においておく必要があります。
『ずんだもんで学ぶ』シリーズまとめ
前々回『 Delphi / C++Builder を使って『ずんだもん』におしゃべりさせるのだ! 』、前回『 iOS / Android でもずんだもんにおしゃべりさせるのだ!』では RAD Studio(Delphi / C++Builder)で使用し、『ずんだもん』の音声データを生成・発話を行いました。
RAD Studio の活用は、これら REST API クライアントアプリケーションの作成にとどまりません。今回ご紹介した事例のように、RAD Server をシステムの中心として配置することで、より高度で拡張性のあるシステム構成を実現することも可能です。
さらに、クライアント・サーバの双方で Delphi / C++Builder を使用することで得られるコードの共通化や流用性といったメリットは、開発効率という点でも優位であると言えるでしょう。
今回ご紹介した RAD Server アプリケーションは、無人受付システムとしての必要最低限の機能を実装したものですが、来客対応に必要なさまざまなワークフローを RAD Server 側に追加して担わせることもできます。例えば、来館受付時にゲスト用の入館証を印刷したり、REST API に対応している電子錠を解錠することも可能です。
RAD Server と REST API の組み合わせによって実現できるシステムの可能性は非常に広がります。
さらに、今話題の SwitchBot を使用し、RAD Server から SwitchBot の REST API を実行すれば、応接室のカーテンを開けたり、空調設備の起動を来客時のワークフローに含めることも可能です。
もし SeitchBot が上手にコーヒーメーカーのボタンを上手に押すことができれば、来客時に RAD Server を使ってコーヒーを淹れることだって可能かもしれません。
……というのはいささか跳躍した発想のようにも思えますが、実際にこうした仕組みは実在するようです。
参考
- RAD Server概要
- VOICEVOX
- 東北ずん子・ずんだもんプロジェクト
- VOICEVOX(GitHub)
- RAD サーバー(EMS)
- Delphi / C++Builder を使って『ずんだもん』におしゃべりさせるのだ!
- iOS / Android でもずんだもんにおしゃべりさせるのだ!

