山口別府弁天池
これまで当研究会のFAQチャットボットは，無料の「インテント型従来AI」サービスを利用していました。近年，サービスが終了したため代替策を考える必要に迫られています。
しかし，今話題のジェミニやOpenAIなどの新しいAI（LLM：Large Language Model、大規模言語モデル）サービスは，無料サービスがあるものの一定量を超えると有料となるものがほとんどです。
そこで，FAQチャットボットを題材に廉価で安定的な「GAS(Google Apps
Script)とＨＴＭＬ」を組み合わせたルールベースの活用法（小規模ウィジェット）を考えることにしました。
GASは廉価で，小規模なトランザクションシステムに最適な感がありますが，GAS特有の制限事項も多く，上手く使うにはいろいろとコツが必要です。
また，最近はAI（LLM）に問いかけると，プログラムコードを作ってくれるようになりました。ハルシネーション（間違い）やメンテナンスの問題もあり，そのまま利用することは出来ませんが，今後，AIの活用は避けて通れません。
そこで，当ブログも詳細なコーディングは冗長になりますので，そのようなコードはAIに問い合わせて頂くこととして，今後は必要なコードに絞って記載するようにしたいと考えています。
それでは，学習を開始します。
【実証前提条件】
・クラウドアプリ：Google Spread Sheet , Google Apps Script
・PC：Windows 11 Proを利用
・サーバ：Webサーバを利用
１．FAQチャットボットは，AI（LLM）とルールベースのどちらが最適か
チャットボットの構築には，自然言語のAI（LLM）を利用する方法と，キーワードに対応して回答文を提供するルールベースの二通りの方法があります。
前者はどんな問いにもほぼ答えられますが，商用のAI（LLM）サービスを利用することになり費用が発生します。
FAQのような不特定多数の人が使うチャットボットにAI（LLM）を適用すると，高額の利用料が発生する可能性があり，それを防ぐために利用料に上限を設定すると，いつの間にか上限に達し動かなくなる恐れがあります。
また，無料で使い続けられるAI（LLM）サービスがあったとしても，いつまで使い続けられるか分かりません。
後者は廉価に構築できますが，自然言語に対応するのが難しく画一的な応答しかできないという特徴があります。
しかし，FAQサービスのような定型的な回答を返すことが多い場合は，あいまいな表現による答えをなるべく避け，誤解を生まないことも大切です。
【結論】
AI（LLM）サービスは自社の業務効率化など利用者および用途が明確なサービスに使うべきであり，トラフィックや利用者が限定できないサービスには向いていないと考えられます。
（但し，大企業などでAI（LLM）サービスを使うことで大きな費用対効果が認められる場合には，その限りではありません。）
あらためて当サイトのFAQ自動化を考えると，利用者は不特定多数とならざるを得ず，AI（LLM）を使うほどの自動化効果があるとも言い難いことから，ルールベースのシステムとして再構築するのが，最適と判断するに至りました。
加えて，ルールベースのチャットボットサービスでは，お客さまのお問い合わせに対して答えられなかった場合に，そのログを蓄積することが出来ます。その内容から新しいサービスを考えることも可能です。
このデータの収集・分析・対策こそが，自動化・省力化以外でのDXの狙いになります。
なお，ルールベースであっても条件によっては自然言語を扱う必要があります。その場合はGASからAI（LLM）を呼ぶ事で柔軟に対応できると判断しました。
つまり，ルールベースとAI（LLM）のいいとこ取りによるバイブリッド型チャットボットこそが最適と考えます。
２．FAQチャットボットや小規模ウィジェットにはGASを使うのが何故最適か
ルールベース型FAQチャットボットでは，特定キーワードに対して明確な回答文を用意します。
その場合，DBストレージに何を使うかを考えます。トランザクションが多い場合には高速性を考えてSQLサーバになりますが，そうなると本式のシステム開発となり，DBの更新システムなど，小規模店舗で扱えるような手軽さはなくなります。
手軽にチャットボットのルールを登録・変更できて，かつ小規模なアクセス数に対応でき，レスポンスもそこそこに早い。
開発費用も低く，改良もし易いという選択肢でシステム構築を考えると，スプレッドシートをストレージとして利用する考えが出てきます。
また，スプレッドシートはGoogleAppSheetを利用することが出来ますので，スマホを使ってルール利用回数の把握からルールの修正までを簡単にシステム化することが可能です。
特に，メッセージ入力を考える時，Webからのサイト入力か，Lineからのアプリ入力かは重要な問題になりますが，GASであればどちらにも柔軟に対応できるようになります。
加えて，GASからAI（LLM）を使うときの「アクセスKey」をGAS内部に設定することができますので，セキュリティ面からみても安心です。
３．GASを使うことでデメリットはないのか
GASを使う上での長所を述べてきましたが，反面，GASを使うことから生じる短所も数多く存在します。
第一に注意しなければならないのは，GASの制約条件です。以下に注意すべき主な制約条件を列挙します。
①スクリプトの処理回数制限
- 一日当たりの処理回数は無料版で5,000回，有料版で20,000回です。
②スクリプトの稼働時間制限
- スクリプトの最大実行時間は無料版，有料版ともに６分になります。
- 一日当たりの合計実行時間は無料版で90分，有料版で６時間という制限です。
- １トランザクション処理時間が2秒であれば，無料版で2,700回処理できる計算です。
③同時実行数制限
- ユーザ当たりの同時実行数は３０件になります。
④その他制限事項
- メール送信数は無料版は1日100通，Workspaceは1日1,500通です。
- URL Fetch（外部API呼び出し）は1日あたり20,000回です。
- トリガー数は1スクリプトあたり最大20個しか設定できません。
- CacheServiceは，保持時間最大6時間，1件あたりの最大サイズは100KB
- PropertiesService容量は、1プロパティ値あたり最大9KB、合計容量は最大500KB
・カレンダーなどを使う場合は，呼出制限もありますので利用サービスの制限について事前に確認しておく必要があります。
このような制限からスクリプトの実行時間は，出来るだけ少なくする必要があります。
また，GASの実行環境も大切です。GASは，WebのJavaScriptからFetch関数でアクセスを受けた場合，相手のドメインを判定し正規のものでない時，404あるいは302のステータスコードを返します。
そうなるとレスポンスの悪化を招きます。これを避けるためには，正規のサーバサイトにテスト用のHTML構文を用意する必要があります。
これらの具体的な対策は次回以降で記載します。
このように，GASは廉価で手軽にシステムが構築できる反面，いろいろな制約がありますので，その点を留意して設計してください。
４．その他，留意すべき事項
GASでチャットボットを試作するにあたって留意すべき事項は沢山あります。以下に，題目を記載します。詳細は次回以降，記述していきます。
- GASのローカルテスト方法について
- GASウェブアプリのデプロイについて
- スプレッドシートのDB化とキーワード論理検索の実装について
- Cache利用でのGASスクリプトの高速化について
- GASアプリへの不要なアクセスを防ぐ方法について
- GASアプリの費用対効果とAI（LLM）の使い方
これらの項目は，実証試験により得られた効果であり，単にAIにコードを教えてと言うだけでは教えてくれません。
実証して，「こういうエラーが帰ってきているけど，なんで」と問うとはじめて教えてくれます。AIを利用するにあたっては，大変興味深いことです。
それなら，初めから教えてよって言いたいですが，聞かれてないから教えなかったというのがAIの今のところの限界と感じます。
５．まとめ
今回はFAQチャットボットなど小規模ウィジェットをGAS×HTMLで構築するための企画案について記述いたしました。
何をどう作るかという視点で，システム開発でいうところの基本設計（外部設計）にあたります。
具体的にプログラムするわけでもなく，面白みに欠けると思いますが，実はこういうところが一番大切なんです。
設計者は最初にいろんな角度から検討・分析をし，仕掛けを当初計画の中に織り込みます。
こういう人が関わったプロジェクトは大抵上手く行きますが，そうでない場合は，多くの場合プロジェクトが破綻します。
もちろん，プロジェクトの工程において，いろんな想定外のことが出てくるのですが，上手く行くプロジェクトは，その想定外が出てきた場合の処置も含めて検討してあります。
システム開発の醍醐味は，本当はこういう処（分析・目論見・仕掛け）にあるのですが，実際のプログラムやらハードやらに目が向く傾向にあるのは大変残念なことです。
今後，技術は一段と進化していきます。
それらに対応し，新しい発想と知見で時代をリードする人財の出現を期待します。
それでは皆さん，次回以降にGASチャットボットの具体的な構築に入っていきますのでよろしくお願いします。
楽しいＩＴリテラシーライフをお過ごしください。
（ご注意）情報の正確性を期していますが，実施される場合には自己責任でお願いします。
0 件のコメント:
コメントを投稿