会社・事業紹介

安藤：テオリア・テクノロジーズは、「認知症との向き合い方を、テクノロジーで変えていく」をミッションに掲げ、エーザイの100%出資の戦略子会社として認知症という社会課題の解決を目指しています。認知症の当事者やそのご家族、医療関係者との対話から得られた膨大な知見をAIなどのテクノロジーと掛け合わせ、脳の健康維持・向上から発症後のケアまで、一貫して認知症に関するサービスを展開しています。

安藤：私たちは認知症のある一つの段階だけに特化したサービスを展開しているわけではありません。認知症を発症する前の健常な段階から、発症後のサポートまで、その間のすべての領域に手を伸ばして包括的に取り組んでいます。直近では毎月のペースで新しいプロダクトがリリースされており、私自身もこのスピードの中に身を置きながら、これがスタートアップなのかと強く実感しているところです。

こうした複数のプロダクト展開により、健常な方からご家族、介護者の方まで、様々な立場のユーザーのデータがデータ基盤に蓄積されていきます。その蓄積されたデータが、私たちの持つコアエンジン、AIエージェントや認知機能の予測モデル、行動変容のアルゴリズムに活用されています。

安藤：それで得られたデータは、ユーザー本人へのフィードバックとして返すだけではなく、必要に応じて主治医にも届けられます。これにより、本人だけではなく、家族や介護者まで含めて、多角的な視点でケアプランを提供できる、そういったエコシステムを構築しています。

Hugwayについて

安藤：「HugWay（ハグウェイ）」について話す前に、認知症とはどういうものかをお伝えしなければいけません。認知症というのは、ある日いきなり発症するものではありません。脳の中に原因となる物質が少しずつ蓄積していき、何年、あるいは何十年という長い年月をかけて脳の働きに影響が出ることで起こる病気です。

最近の研究では、運動や食事、睡眠といった日々の生活習慣が、認知症の発症リスクや進行速度に関わっている可能性があるとわかってきています。そこで、認知症の発症リスクを下げるための代表的な考え方として「5 FINGER」というものがあります。

安藤：1つ目は栄養バランスの良い食事、2つ目は適度な運動、3つ目は脳トレゲームや読書といった頭を使う認知トレーニング、4つ目は地域の集まりやボランティアなど誰かと関わる社会的な活動、そして最後に高血圧や糖尿病、動脈硬化を防ぐ血管リスク管理です。この5つのうちどれか1つだけを実施しても十分な効果が得られないと言われており、すべてを組み合わせることで認知症の発症リスクを下げる可能性が高まると言われています。

5 FINGER を無理なく日常の中で続けていけるように、私たちは今年の6月に「HugWay」というアプリをリリースしました。ターゲット層は、健康や認知症を気にする40代から70代のシニア層を中心とした健常者向けです。

HugWayにはいくつかの機能があります。AIとの会話機能、歩数や睡眠といったヘルスケアデータの記録、脳の健康習慣を学べるコンテンツ、そして脳トレゲームです。こうした機能を組み合わせることで、5 FINGER を無理なく実施できるように設計しています。

安藤：HugWayを通じて5 FINGER の要素を日々続けていくと、私たちが実現したい世界が見えてきます。健常な人が増えることで、医療や介護にかかる費用が削減できるかもしれません。介護を担っているご家族や介護士の負担も軽くできるかもしれません。そして、より多くの人が健康に働き続けられるようになれば、労働力不足の解決にもつながるかもしれません。私たちはそうした未来を目指しています。

HugWayのアーキテクチャ

安藤：HugWayはモバイルアプリとして提供しているため、Flutterを採用しています。バックエンドはTypeScriptで構築しています。インフラについては、特定のクラウドベンダーに縛られないように設計していますが、現時点ではGoogle Cloudを中心とした構成になっています。また、オブザーバビリティの面では、OpenTelemetryを中心に各種サービスへテレメトリを送信し、システム全体の状態を把握できるようにしています。そして、開発では多くのAIツールを積極的に取り入れながら進めています。

安藤：HugWayのアーキテクチャは、Google Cloudを中心にマイクロサービスアーキテクチャを参考に構築しています。認証サーバーがあり、API Gatewayのサーバーがあり、その背後にマイクロサービスが存在します。Google Cloudのほかにも、Appstash、Cloudflare、そしてAWSのBedrockなど、目的に合わせた最適なサービスを組み合わせて構築しています。

安藤：現在、バックエンドとインフラは私1人で担当しています。Claude CodeやDevinをはじめとしたAIツールを駆使しながら開発しています。先ほど説明したマイクロサービスアーキテクチャは、将来的に人によるチームの規模が大きくなることを見越したというよりも、AIが自走して1つのマイクロサービスを開発・運用できるようにするための設計になっています。

慎重に開発すべきコア機能についてはAIと協働して一緒につくり、逆にAIにすべて任せられそうな部分はマイクロサービスとして切り出して、コア機能に影響が及ばないよう独立した環境をつくるようにしています。

安藤：今回のカンファレンスで「AIが実装してマイクロサービスが動いていて、テレメトリもちゃんと取れていますよ」ということをお伝えしたかったのですが、なかなか失敗続きでお話しできることが少ないです。半年ほど前、AWS Kiroがリリースされた時期に仕様駆動開発が盛り上がっていました。その時に実際にAIにマイクロサービスの開発を任せてみるという実験もしてみたのですが、正直、思ったような結果にはなりませんでした。環境の準備不足もありますし、知見も貯まっていなかったなど、さまざまな要因があったと思います。

ですが、今はClaude CodeのSkillsやGoogleのAntigravityなど、エージェントが実装できるバイブコーディング環境が着実に整ってきていると思います。今は人とAIとの共同で開発するという程度に収まっていますが、この領域にはこのアーキテクチャを維持して積極的にチャレンジしていきたいと考えています。

HugWayは会話を中心としたアプリ機能を展開しているので、ユーザー情報や会話データの管理機能などのコア機能に加えて、日々の会話の話題づくりに使うさまざまな小さな機能があります。例えば天気APIなど、「これってAIに丸ごと任せられるかも」と思いながら、現在AIと協働して開発しています。細部まで気にすると難しいところもありますが、チャレンジする価値が十分にあると思っている部分です。

安藤：HugWayではAPI Gatewayを自作しています。これはどこでも動作するというポータビリティを重視していて、クラウドプラットフォームを乗り換える場合でも、あるいは特殊な事情でAPI Gatewayやマイクロサービスの環境を新しく用意する場合でも、同じように動作できるように設計しています。

実はHugWayは先月までAWS上で動いていたのですが、社内の事情からGoogle Cloudへの移行を決断し、そこからわずか2週間で移行を完了しました。このスピードで移行ができたのは、日頃からこのポータビリティを意識した設計をしてきたおかげだと思っています。

安藤：将来の話になりますが、最近注目しているI/Oバウンドに費用がかからない環境についてお話しします。HugWayはAIと会話するアプリなので、裏側ではLLMのAPIを多用しています。ユーザーとの会話はストリーミングレスポンスで会話体験を向上させていますが、それ以外の部分、例えばユーザーの長期記憶に関する処理などは、1リクエストで生成するデータ量によっては最大2〜3分ほどかかってしまいます。

このようなリクエストは、ただLLMのAPIのレスポンスを待っているだけなのに、例えばCloud Runのようなサーバーレス環境ではその待機時間にも費用が発生し続けます。これがなかなかもったいなく感じてしまうポイントです。

そんな中、I/Oバウンド、特にLLMのAPIのような外部API呼び出し時間に課金がされないという新しいタイプのサービスを、今年に入っていくつか目にするようになりました。有名どころだとAWSのAgent Coreがあります。AIエージェントの構築・運用向けのマネージドサービスで、LLMのレスポンスを待つ時間に費用はかかりません。ただ、HugWayは前段に自作のAPI Gatewayを置きたかったので、今回は見送りました。

安藤：今、私が特に注目しているのがVercelのFluid Computeです。LLM APIのレスポンス待ち時間に費用がかからないことに加え、Node.jsのアプリケーションならほぼ何でも動作します。

サーバーレスのマイクロサービス構成では、「前段のAPI Gatewayがマイクロサービスのレスポンスを待つ時間」と「マイクロサービスの実行時間」の両方が課金対象となり、料金が2倍になってしまうという問題がネックになりがちです。Fluid ComputeではI/Oバウンドに費用がかからないため、この問題が解決できそうな点がとても魅力的です。

現在検証中でセキュリティ面も調べていますが、こうしたフットワークの軽い検証を続けつつ、今のステージに最適な構成は何かを常に考えながら、ポータビリティを生かして柔軟にアップデートしていきたいと考えています。

安藤：HugWayのマイクロサービスでは、まずOpenAPIの仕様書を必ず生成することを前提としています。この仕様書さえしっかり用意できれば、どんな環境で動いていても問題ないという柔軟な設計にしています。そして、HugWayではこのOpenAPIの仕様書にできるだけ多くの情報を詰め込む方針にしています。

さらに、APIの宣言だけではなく、API Gatewayの設定まで含めるようにしています。これにより、API Gateway側は仕様書を受け取るだけで必要な設定をすべて把握できます。デプロイ時には設定が自動的に反映され、マイクロサービスへのルーティングが可能になります。

安藤：このOpenAPIの仕様書は、ソースコードから自動的に出力される仕組みになっています。そのため、AIがマイクロサービスを実装する場合でも、Gatewayの設定を含めてひとまとめで実装できるようになっています。これによって、設定やルールなどのファイルがあちこちに分散してしまうのを防ぎ、AIと協働して作業するときも、思わぬファイルまで触ってしまうといったリスクを軽減できます。

さらに、情報を1箇所に集約する仕組みは、人が開発するときにも大きなメリットがあります。APIの振る舞いが一目でわかり、アーキテクチャ全体もシンプルになるため、開発しやすい環境を実現できています。

安藤：それぞれのマイクロサービスがOpenAPIの仕様書を生成するので、その仕様書をまとめて管理するためのCI/CD環境も整えています。具体的にはGitHub Actionsを使って、各マイクロサービスがつくったOpenAPIの仕様書をAPI Gatewayのリポジトリに自動で取り込む仕組みを入れています。これはPull Request経由で行われるので、そのPull Requestがマージされると、そのままデプロイまで自動的に進んで、すぐに新しいAPIが利用できる状態になるという流れです。

安藤：ドキュメントの整備にも力を入れています。まず、リポジトリにはMarkdown形式でドキュメントを配置しています。さらに、そこから生成されたHTMLのドキュメントサイトには、LLMテキストと呼ばれるコーディングエージェント向けのテキストを置いて、AIが必要な情報にアクセスできるようにしています。

加えて、プロダクトの情報が集約されているNotionにはMCPを使ってアクセスし、AIが参照できるようにしています。テオリアではDevinも利用しているので、自動生成されるDeep Wikiも細かく調整しています。こうした取り組みを通して、可能な限りの情報がドキュメントとして整備され、開発だけではなくテオリアの展開するプロダクトのナレッジとして利用しやすい環境づくりを意識しています。

安藤：オブザーバビリティについては、HugWayではOpenTelemetryを採用しています。専用のOpenTelemetryコレクターサーバーを立てていて、そこに集まったテレメトリをそれぞれ適切なサービスに送る仕組みになっています。具体的には、AIに関するテレメトリは専用のLangfuseへ、それ以外のアプリケーション全体のテレメトリはDatadogへ送信しています。

こうした構成にしているおかげで、アプリケーション側が依存するのは基本的にOpenTelemetryのライブラリだけで済みます。そのため、アーキテクチャや実装手順、AIに指示する手順が非常にシンプルになります。さらにOpenTelemetryはさまざまなツールやサービスが対応しているので、今後もしサービスの乗り換えなどが発生した場合でも選択肢が広がります。この構成は維持し続けていくつもりです。

会話の設計

安藤：これは完全に私自身の話ですが、体重が気になるとか、最近運動していないといった理由で健康管理アプリを入れても、正直続きません。目標が「1年後に5キロ痩せる」のように年単位になりがちで、日々努力しても変化がほとんど見えません。そうなるとモチベーションがどんどん下がってしまいます。

HugWayではそうならないように、無理なく続けられる短期的な目標を設定するようにしています。毎日の会話の中で一人ひとりのユーザーに寄り添いながら支援していく、そんなアプローチを重視しています。

AIが寄り添って支援するとはどういうことか、少し具体的にお話しします。HugWayのAIは、日常的な会話の中から、ユーザー自身がまだ言葉にできていない思考や感情を読み取ろうとします。そして「こういうことですか？」「これについてどう思いますか？」といった質問や確認を重ねていきます。この対話のプロセスを通じて、ユーザー自身も気づいていなかった目的や背景が少しずつ整理されていくイメージです。

安藤：その上でAIは、持っているナレッジを活用しながら、「本当にやりたかったこと」や「次に何をすればいいのか」を具体的な行動レベルに落とし込んでいきます。この流れがあるからこそ、ユーザーは「自分が言いたかったのはこれだ」と思考を言語化でき、「次はこれをやってみよう」と行動を明確化できるのです。

朝にAIと会話する場合の例をご紹介します。その日の予定がすでに決まっていても、AIは予定をただこなすのではなく、「どう達成するか」というレベルに引き上げるお手伝いをします。

例えば、ユーザーが「今日はスーパーに買い物に行きます」と伝えたとします。AIは「はい、いってらっしゃい」では終わりません。「買うものは決まっていますか？」「今日使う食材や冷蔵庫のストックの確認はできていますか？」と、一歩踏み込んだ質問や確認を重ねていきます。

このやり取りを通じて、ユーザーは忘れていたことを思い出したり、今日の目的が少しずつ整理されていきます。結果として、「スーパーに買い物に行く」という漠然としたタスクが、「足りない材料を買いに行く」という明確な目的を持った行動へと変わっていきます。

安藤：みなさんが普段使っている一般的なAIチャットを思い浮かべてみてください。ほとんどの場合、私たちユーザーが何かメッセージを入力するところから会話が始まりますよね。ですが、私たちが開発しているHugWayはここが大きく違います。ユーザーの入力を待つのではなく、AIのほうから「昨日はこんなことがありましたね、今日は何をしますか？」と能動的に話しかける設計になっています。

ただ、AIから話しかける仕組みを実現するには、技術的な工夫が必要です。HugWayでは、AIが話しかけるきっかけとして、ユーザーの最初のメッセージを内部的に自動で差し込む仕組みをつくっています。このメッセージは内部処理用なので、ユーザーには表示されません。

私たちはこれを「トリガーメッセージ」と呼んでいます。このメッセージには、AIに会話を始めてもらうための命令や、会話のベースとなるコンテキストを含めています。AIの方から話しかけることで、「何を話せばいいかわからない」というユーザー側のハードルを下げるようにしています。

安藤：AIと長期間対話を続ける上で、注意すべき点があります。AIがユーザーの意見や価値観に合わせすぎてしまうことです。AIがユーザーの意見ばかり肯定し続けると、その考えが強化されてしまう危険があります。これはエコーチェンバーと呼ばれる状態です。

HugWayでは、AIがユーザーに寄り添いながらも偏りを生み出さないよう、2つの工夫を取り入れています。1つ目は、会話履歴の渡し方です。AIに過去のすべての履歴を渡すのではなく、直近の会話だけに絞っています。これにより、AIが過去の文脈に引きずられてユーザーの意見に過度に同調することを避けられます。

2つ目は、長期記憶の扱い方です。AIが重要な内容として記憶する際、偏った意見や考えが含まれていた場合は、AI自身がその偏りを取り除いてから保存します。こうした工夫により、AIがユーザーに寄り添いながらも客観性を失わず、適切な距離感を保つことを目指しています。

安藤：HugWayは日々の会話を積み重ねていくことを前提としたアプリです。その中でも特に重要になるのが、いつ会話したかという情報です。もっと言えば、朝なのか夜なのか、何時に話したのかといった時系列がとても大切になります。

例えば、前日の朝に悩みを相談し、その日の夜に解決したとします。それなのに翌日また同じ話題を振られては困ります。こうした「時間が経つと解決済みになる話題」に自然に対応するため、私たちはシンプルな解決策を取りました。直近の十数ターンの会話だけを履歴としてAIに渡す方針です。

さらに、この履歴にタイムスタンプを付けて、会話の時系列をAIが把握できるようにしています。これにより、AIは「悩みが短時間で解決した」という経緯を理解した上で、翌日以降も自然な会話を続けられるようになりました。

安藤：この方法で会話体験は大きく向上しましたが、コンテキスト量が増えることでコストの問題が出てきました。コストは永遠の課題ですよね。現在は、履歴として渡す会話のターン数を調整することで対応しています。また、HugWayは短時間で会話が終わるケースが多いため、プロンプトのキャッシュがヒットしやすく、これもコスト削減につながっています。

これまでお話ししてきた会話設計の中でも、大きな役割を果たしたのがペルソナです。ペルソナとは、架空の理想的なユーザー像のことです。HugWayでは、想定するユーザー情報を元にペルソナをつくり、その人物になりきってAIとの会話をしてもらっています。

初期の頃はAPIが正しく動作するかという検証程度で使っていました。これだけでも十分役に立ったのですが、このペルソナを生成AIの品質チェックにも使おうという動きになりました。ただ、そうなると新たな課題が見えてきました。ペルソナに基本的なユーザー像の情報を与えただけでは、そこから導かれる日々の行動がどうしても単調になってしまうのです。

安藤：例えば、趣味が古本屋めぐりと書いてあるペルソナがいたとします。するとそのペルソナは毎日古本屋に行ってしまいます。行動が固定されると生成される会話データも似たようなものばかりになり、長期記憶に保存されるデータにも偏りが生まれて、あまり役に立つデータにはなりませんでした。

多様性のある会話データをつくるために、私たちは対策を取りました。それは、1か月分の予定を矛盾なく生成し、それを会話に活用するという方法です。具体的には、朝・昼・夜それぞれの予定を1か月分まとめて生成しておき、会話するときにはその日を中心とした前後の予定だけをAIに渡して会話させます。

こうすることで、その日より前にある情報は過去に実際に起きた出来事として扱われ、その日より後にある情報はこれからの予定として扱われるようになります。これによって会話の幅が一気に広がり、より自然で多様な会話データをつくれるようになりました。

安藤：こうした膨大なコンテキストを生成する上で、Claude CodeのMAXプランに助けられました。とはいえ、100ドルプランでもすぐにレート制限に引っかかってしまい、3時間おきにプロンプトを実行しなければならない状況になりました。その点はかなり苦労した部分でもあります。

AIコンプライアンス

安藤：テオリアは製薬会社の子会社ということもあり、薬機法をはじめとしたさまざまな法律を守らなければいけません。

例えば、ユーザーがAIに「この薬の副作用は何ですか？」と質問したとします。このとき、AIは副作用の内容を説明するのではなく、「医師に相談してください」というように専門家へつなぐ必要があります。このように医療に関する質問に答える際には、AIであっても法律に沿った適切な応答が求められます。

安藤：AIは非常に便利な存在ですが、扱い方を間違えるとユーザーの健康に影響を与えてしまう可能性もありますし、企業としても法令違反につながるリスクを負うことになります。そこで、さまざまなガードレールのような対策を組み込んでいるのですが、それでもすり抜けてしまって、ユーザーの手元に不適切な内容が届いてしまう可能性があります。この不適切な内容が届いてしまう可能性は、おそらく完全にゼロにすることはできないと思っています。

というのも、サービスを運用していくということは、LLMのモデルがアップデートされたり、プロンプトの設計が変更されたり、あるいは多種多様なユーザー側の質問やメッセージのつくり方が変わったりと、避けられない出来事が必ず起こるからです。こうした変化が重なることで、思わぬ挙動が生まれてしまうという可能性がどうしても残ってしまいます。

では、すり抜けてしまう状況を「しょうがない」と片付けてしまうかというと、もちろんそんなことはありません。私たちは、AIが出力したテキストをしっかりと校閲してリスクを把握し、必要に応じて改善していかなくてはいけません。ただ、これを人でやろうとすると、とてつもない労力がかかります。しかも、生成AIの出力は毎回変わりますから、そのすべてを校閲担当と法務の担当がチェックしていくのは現実的ではありません。

そこで私たちは、第三者がいつでも評価・レビューできる仕組みを導入しています。プロダクト内のAIがどのような環境で動作し、どのようなテキストを出力しているのかを可視化するためです。具体的には、2つの取り組みを行っています。

安藤：1つは、日本デジタルヘルス・アライアンス、略してJaDHAが公開しているチェックリストです。JaDHAはデジタルヘルスの環境整備を目指している研究組織で、私たちテオリアも正会員として活動に参加しています。このチェックリストは、ヘルスケア領域で生成AIを安全に活用するための指針がまとめられていて、私たちはこれを評価・レビューのプロセスに取り入れています。

2つ目は、リスクアセスメントシートと呼ばれるものです。リスクアセスメントは、危険を見つけてそのリスクの大きさを見積もり、評価し、優先度をつけて対策していく、この一連の流れを体系的に行うことを指します。これは製造業で普及している考え方ですが、私たちはこの考え方を生成AIに応用しています。AIが生成するテキストに危険がないか、リスクの大きさはどれくらいか、対策すべき内容なのか、そして対策が必要ならプロンプトの改善をしていかなければいけないのか。そうしたプロセスを着実に実施しながら、安全にサービスを提供できる体制を整えています。

安藤：私たちはDifyのワークフローを使って、AIが出力するテキストを自動で評価する仕組みを用意しています。Difyはノーコードでエージェントやワークフローを構築できるサービスで、テオリアもセルフホストで環境を立ち上げてさまざまな用途で活用しています。この仕組みを導入したことで、プロダクトのリリース前はもちろん、LLMのモデルを変更したときや、プロンプトを調整したときなど、さまざまなタイミングで必要になる評価作業の負荷を大きく下げることができるようになりました。

安藤：チェックリストやリスクアセスメントシートがまとまったら、その内容を校閲担当や法務担当にレビューしてもらいます。ここは単なる確認だけではなく、「この表現は誤解を生まないか」「ユーザーが危険な行動につながらないか」といった実務的で専門的な視点から細かくチェックしていきます。問題がなければ、その時点で一つの評価サイクルが完了です。もし指摘があれば、プロダクトチームにフィードバックが戻ってきて、その問題に対して対応すべきかどうかという判断から議論が始まります。

こうしたプロセスを繰り返すことで、生成AIが生み出すリスクをきちんと見える化し、長期的に安心して使えるプロダクト環境を整える。私たちはそんな取り組みを続けています。

まとめ

安藤：まだまだ話したいことはあるのですが、最後にまとめをお伝えします。

HugWayではマイクロサービスアーキテクチャを採用していますが、これはAIが自走してマイクロサービスを開発できる環境を整えるということを目的としています。HugWayでは、5 FINGER という要素を無理なく続けられるように、ユーザー一人ひとりに寄り添った会話を設計しています。AIの生成するテキストのリスクを見える化し、サービスが持続可能になる環境づくりをしています。

そして最後に、5 FINGER という言葉だけでも覚えて帰っていただけると嬉しいです。私たちは積極的に採用活動をしています。ご清聴ありがとうございました。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。