【クリニックのスタッフさん＆院長先生へ「チャットボットをウェブサイトに設置しませんか？】2️⃣Gemini Gem？ Claude Artifact？ miibo？ Coze？ DocsBot？ —全部検討して全部諦めてしまいました

まずはこの記事の概要を動画で

＊本動画はあくまで記事の概要であり、詳細な内容はすべて反映されておりません。
＊本コンテンツはAIによる完全自動生成です
このサマリー動画は、Note記事をNotebookLMの生成機能に直接投入し、人為的な編集を加えずに出力したものです。
また、AI特有のアルゴリズムにより、論点の誇張や、著者の意図しない表現の増幅（ハルシネーション等含む）が発生する場合があります。
「AIによる解釈」の一例としてお楽しみいただき、ご興味を持たれた方は、ぜひ元記事（全文）をご覧ください。

▼ 元記事（Note）はこちら

【再掲】うまく行くかは不明です。クリニックスタッフさんが運営する前提で

実は当院もまだチャットボットを設置していないのです。多くのクリニックでは院長というよりスタッフの皆さんが運営の主体になることになると思うのでそういった視点でこのシリーズを書いてまいります。
今回の記事は上手くいくかは不明ですが、思考実験として試行錯誤しながら書くシリーズなのでお許しください

前回のおさらい

前回、「NotebookLMみたいに、こちらのリソースだけで答えるチャットボットを患者さんに提供したい。受付スタッフの電話対応負担を減らしたい」という目標を設定しました。

今回は、その目標に向けて検討した7つの選択肢と、それぞれを諦めた理由を書かせていただきます。（あくまで私の選択基準によるものでそれぞれ、個人的には使っているものもあります。あくまでクリニックでそしてスタッフにメンテナンスをして頂くという視点では採用にならなかったという点をご理解下さい。）

選択肢1：Gemini Gem

最初に思いついたのがこれでした。GoogleがNotebookLMを出しているなら、同じGoogleのGeminiでカスタムチャットを作れるのでは？ と。

Geminiには「Gem」という機能があります。カスタム指示とアップロードファイルを組み合わせて、特定の用途に特化したチャットを作れる。「患者向けQ&Aファイルを入れて、『これだけで答えろ』と指示すればいいのでは？」という発想です。

しかし、致命的だったのが共有方法です。Gemを使うにはGoogleアカウントでのログインが必要なのです。

ご高齢の患者さんに「Googleアカウントでログインしてください」と言えますか？ 待合室のタブレットに置くにしても、毎回ログインが必要では実用になりません。スタッフが運用する以前の問題で、患者さんがそもそもたどり着けない。

加えて、Gemは結局Geminiの汎用知識も回答に混ぜてしまうリスクがある。「この情報だけで答えろ」と指示しても、親切心から「一般的には…」と補足してしまうことがある。

諦めた理由：ログイン必須。患者さんに使ってもらう方法がない。

選択肢2：Claude Artifact

次に検討したのがClaudeのArtifact機能です。
ChatGPTやGeminiに比べるとまだまだマイナーなイメージの有るClaudeですが、私の使用頻度No1のAIになっています。最近のイラン紛争でも話題になりましたね

Q&Aデータをアプリ内に埋め込み、システムプロンプトで「この情報だけで答えろ」と厳命。実際にプロトタイプを作ってもらったら5分で動くものが出てきました。花粉症の質問には正しく答え、データにない質問は「お答えできません」と断ってくれた。

「これでいけるのでは？」と一瞬思いました。

ところが、「Spreadsheetから読み込む機能をつけよう」とした時に致命的な問題に気づきました。最初のプロトタイプでは管理画面と患者チャット画面が同一画面に同居していたのです。歯車マークを押すと設定パネルが開く仕様。

「そんな危険な管理画面と患者画面を分けないと、ハックされたら終わりですよ」と指摘しました。患者さんがアクセスする画面に、データソースのURLが表示される設定パネルがある。医療情報を扱うシステムでこれは絶対にあってはならない。

分離版を作り直してもらいましたが、根本的な不安は消えませんでした。データ更新にもClaudeとの対話が必要で、スタッフ運営は難しい。

諦めた理由：データ更新にClaudeとの対話が必要でスタッフ運営が難しい。

選択肢3：miibo（ミーボ）

数年前に記事も書いたツールです。

miiboは日本発のノーコード会話AI構築プラットフォーム。

これはかなり良さそうでした。「ナレッジデータストア」にQ&Aデータや文書を入れると、RAGの仕組みでその知識を元にAIが応答してくれる。Web埋め込みウィジェットもあり、LINEとの連携もできる。日本語のサポートやドキュメントが充実しているのも安心感がある。

しかし検討を進めると気になる点が出てきました。

まず料金体系。トライアルプランの利用期間は1ヶ月で、その後は有料プランに移行する必要がある。ホビーとスタンダードプランの差が大きいということがありました。

次に、グラウンディングの仕組み。miiboもRAGを採用していますが、ベースはChatGPTやClaudeなどのLLMをプロンプト＋ナレッジで制御する方式です。NotebookLMやGoogle Agent Builderのように、Googleのインフラレベルでグラウンディングが保証される仕組みとは設計思想が異なります。

そして、スタッフさんの運用。miiboの管理画面はよくできていますが、それでも「miibo専用の管理画面にログインして操作する」必要がある。Googleのツール（Gmail、Spreadsheet）なら毎日使っているけれど、miibo独自のインターフェースは新たに覚える必要がある。

諦めた理由：独自プラットフォームへの依存。スタッフが日常的に使うツールとしては現実的は無いかも？。グラウンディングの堅さにやや不安。

選択肢4：Coze（コーズ）

CozeはByteDance（TikTokの親会社）が提供するチャットボットビルダーです。ナレッジベース機能付きで、作ったボットをリンクで共有できる。UIも直感的で、「このドキュメント群からのみ回答」という設定ができます。

機能面だけ見ると要件にかなり近いのですが、一つ大きな懸念がありました。

ByteDanceという運営元です。これは善し悪しの話ではなく、医療データを扱う以上、データの保管場所や利用規約について慎重にならざるを得ません。患者さん向けのQ&Aデータ自体は機密情報ではありませんが、チャットログ（患者さんがどんな質問をしたか）は個人に紐づく可能性のある情報です。

加えて、サービスの継続性についても未知数です。Google Cloudのような長期安定のインフラと比べると、特定のサービスが突然終了するリスクは考慮せざるを得ません。

諦めた理由：データガバナンスの懸念。サービス継続性の不安。

選択肢5：DocsBot

DocsBotは海外のサービスで、まさに名前の通り「ドキュメントからチャットボットを作る」ためのツールです。

PDFやCSV、Webサイトをアップロードすると、その内容からAIチャットボットが自動生成される。Web埋め込みウィジェットあり。ノーコード。まさに欲しいものに見えました。

実際に評判も良く、セットアップは数分で完了するとのこと。料金は月$19〜。日本語対応もしているようです。

しかし、いくつかの点で引っかかりました。

まず、海外サービスであること自体。UIは英語ベースで、日本語のサポートは限定的。スタッフさんが「新しいQ&Aを追加したい」と思った時に、英語の管理画面を操作する必要がある。これはスタッフ運営のハードルとして決して低くない。

次に、miiboと同じくLLMのプロンプト制御がベースになっている点。RAGは実装されていますが、Google Agent Builderのようなインフラレベルのグラウンディングとは異なります。

そして、やはり専用プラットフォームへの依存。DocsBotが何らかの理由でサービスを変更・終了した場合、移行先を探す必要がある。

諦めた理由：英語UI。スタッフ運営のハードルが高い。専用プラットフォーム依存。

選択肢6：Dify

ノーコードAIプラットフォームのDifyも検討しました。RAG機能を持ち、Webチャットウィジェットとして公開もできる。機能的にはかなり要件に近い。これは個人的にも他で使っています

しかし、miibo、Coze、DocsBotと同じ根本的な問題がありました。スタッフさんが運用できない。 Dify独自の管理画面は、私がいないと誰も触れないでしょう。

「院長がいないと更新できないシステム」は、それ自体がリスクです。

諦めた理由：スタッフの運用負荷。Googleエコシステムから離れてしまう。

選択肢7：Google AI Studio Build

Google AI Studioの「Build」モードは、自然言語でアプリを生成してくれるバイブコーディングツール。Googleエコシステム内で完結し、デプロイも簡単。

しかし、核心的な問題が残りました。ソース限定の「グラウンディング」がプロンプト頼みなのです。医療情報で「まあ大体従うと思いますよ」は、ちょっと怖いですよね。

諦めた理由：グラウンディングがプロンプト依存。医療情報を扱うには不安が残る。

振り返り：7つ検討してわかったこと

7つの選択肢を全部並べてみると、「諦めた理由」にパターンが見えてきます。

パターンA：患者さんがアクセスできない問題 → Gemini Gem（ログイン必須）

パターンB：独自プラットフォーム依存の問題 → miibo、Coze、DocsBot、Dify（スタッフが普段使わないツールの管理画面）

パターンC：グラウンディングの堅さの問題 → Claude Artifact、Google AI Studio Build（プロンプト依存）

パターンD：セキュリティ/データガバナンスの問題 → Claude Artifact（管理画面の分離）、Coze（データの保管先）

こうやって整理すると、必要なのは：

1. ログイン不要でWebに埋め込める

2. Googleエコシステム内で完結（スタッフが使い慣れた環境）

3. インフラレベルでグラウンディングが保証される（プロンプト頼みではない）

4. Googleのセキュリティ基盤の上にある

この4条件を全部満たすもの。

次回、そんな都合のいいサービスが実はGoogleの中にあった話をします。

今日はここまで

井手の名刺情報

医療関連企業様

クリニック院長先生向けコンテンツとしていかが？

患者さん説明用アプリについて