0819 | 妊娠患者の記録を一元化するFinch、医療記録APIのHubble、ブックマーク検索Deepmark、ロボット頭脳Salem Robotics

葵: Bri Radio の「ProductHunt Daily」へようこそ。私は葵です。今日は、患者が自分の医療記録をつかむための新たな取り組みから、AIコーディングエージェントを見守るMacアプリ、カメラロールの中を検索するツールまで、実用的な新製品がそろっています。

悠真: 気になりますね。僕は悠真です。医療記録をめぐるあれやこれやは、多くの人が身に覚えを持つテーマです。それに、ブラウザやSNSに散らばったブックマークをまとめるツールも登場したそうですね。

葵: はい。どれも「面倒なことを片付ける」系のツールばかりで、個人的に今週一番の注目ですね。この先、それぞれの詳しい中身を一緒に確認していきましょう。

悠真: では、始めましょう。

葵: 医療記録の整理を患者の側から変えようとしているアプリ、Finch。出産を控えた人や、複数の医療機関を渡り歩くすべての人を想定ユーザーに据えた健康管理アプリで、妊娠だけでも予約は最低12回、検査結果は数十件にのぼり、さらに新しい専門用語が加わり、それらが異なる医療提供者から異なる形式で届きます。Finchはこれらを一つの画面にまとめ、診察で話された内容を文字起こしし、臨床用語を平易な英語に翻訳します。料金は無料ティアがあり、上位のFinch+は年間99ドルです。共同創業者のIsaac氏は、Finchが3つのことをすると説明します。医療記録を一箇所にまとめること、診察で実際に話されたことを記録すること、その両方を平易な英語で理解できるようにすることです。Isaac氏は医学部に進むところでしたが、代わりにソフトウェア開発の道を選びました。2人の創業者はともに米国の医療制度の外で育ったため、事務手続きの側面が内部から見るとさらに奇妙に映るといいます。チームは2人だけ、プレシード段階で、今回が初の公開ローンチ。出産予定者や最近出産した人、医療記録の整理に苦労した経験がある人からのフィードバックを求めています。

悠真: それがFinchでは一つの画面にまとまるんですね。加えて、診察で実際に話された内容を文字起こしし、臨床用語を平易な英語に翻訳してくれる。料金は無料ティアがあって、上位版のFinch+は年間99ドルです。

葵: 共同創業者の一人、Isaac氏の説明では、Finchは3つのことをすると言います。医療記録を一箇所にまとめること、診察で実際に話されたことを記録すること、そしてその両方を平易な英語で理解できるようにすること。Isaac氏はもともと医学部に進む予定でしたが、代わりにソフトウェア開発の道を選んだそうです。

悠真: 興味深いのは、2人の創業者とも米国の医療制度の外で育ったため、事務手続きの側面が、内部から見ると一層奇妙に映るという点ですね。チームはまだ2人だけで、プレシード段階。今回が初の公開ローンチです。

葵: Finchは今、出産予定の人、最近出産した人、あるいは医療記録の整理に苦労した経験がある人からのフィードバックを求めています。コミュニティからは、患者にFinchを信頼して使ってもらう上での最大の課題は何か、という質問と、健康アプリにとっては奇妙な選択だと指摘する、ロゴの意図を問うコメントが寄せられています。

葵: ほかのAPIでは取れない医療記録を取り出すためのAPIレイヤーとして登場したのが、Hubbleです。医療記録がいまだにfax回線や電話のツリー、忘れられたポータルのログインの奥に分散している問題を対象にしています。患者が一度本人確認を行うと、Hubbleが受診した複数のプロバイダーから記録を集め、1つのAPIでAIエージェントなどに返します。創業者によれば、既存の多くのAPIは患者ポータルの部分集合しか返さないため、従来は数ヶ月かけたプロバイダー別統合やfaxや手動ログインへの後退、患者への負担転嫁が必要だったということです。仕組みとしては、EHRとHIEに接続し、APIが空を返す場合はブラウザエージェントがプロバイダーポータル経由で申請し、音声エージェントが患者に代わって記録部門に電話します。すべてのリクエストは患者個人のアクセス権に基づき、患者は全ソースをレビューでき、いつでも取り消せます。構造化出力、決定論的ID、完全な監査証跡を備え、返される記録の各値には由来するシステムが付きます。企業はY Combinator支援とされ、CEOのPrabha Dublish氏はGrow Therapyの初のプロダクト採用者でMeta出身、CTOのAaron Leon氏はAmazon One Medicalのテックリードだったと説明されています。

悠真: Hubbleは、患者が一度本人確認を行うと、受診した複数のプロバイダーから記録を集め、一つのAPIでAIエージェントなどに返す仕組みです。創業者によれば、既存の多くのAPIは患者ポータルの一部分しか返せないため、従来はプロバイダーごとに数ヶ月かけた統合、faxや手動ログインへの後退、患者への負担転嫁が必要だったそうです。

葵: 仕組みとしては、EHRやHIEに接続し、APIが空を返す場合はブラウザエージェントがプロバイダーのポータル経由で申請し、音声エージェントが患者に代わって記録部門に電話をかけます。すべてのリクエストは患者個人のアクセス権に基づいていて、患者は全ソースをレビューでき、いつでも取り消せます。

悠真: また、返される記録の各値には、どのシステムに由来するかが付くそうで、構造化された出力と完全な監査証跡もあります。接続先はEpic、Oracle Health、Cerner、athenahealth、UnitedHealthcare、Aetnaなど40以上のツールとされ、HIPAAにも準拠しているとされています。

葵: 企業はY Combinatorの支援を受けているとされ、CEOのPrabha Dublish氏はGrow Therapyの初のプロダクト採用者でMeta出身、CTOのAaron Leon氏はAmazon One Medicalのテックリードだったと説明されています。チームが「Grow TherapyとAmazon One MedicalのAIエージェントを支え、数百万人の患者に使われてきた」と主張しているのは自己申告です。

悠真: 患者仲介アクセスは本番稼働中で、プロバイダー仲介アクセス、つまりリアルタイムの適格性・給付・事前認可、スケジューリング、請求、文書アップロードは現在ベータ版。Product Hunt限定で7日間無料の特典もあります。コミュニティからは、音声エージェントがコールバック待ちや口頭での本人確認を求められた場合に人間へ引き継ぐのか再試行するのか、AIだと疑われて不意の質問をされた場合はどうするのか、記録をPDFなどでダウンロードできるのか、対応国や記録の保持・削除方法といった疑問が寄せられていますが、発表時点では回答は示されていません。

葵: 続いてDeepmark。ブラウザのブックマーク、Xのブックマーク、Instagramの保存、YouTubeの「後で見る」と「高く評価した動画」を一つのプライベートライブラリにまとめるChrome拡張機能です。ポイントは、タイトルではなく中身に基づいて自然言語で検索できること。開発者は、ブックマークマネージャーはリンクとタイトルを保存するのに対し、Deepmarkはその中身を保存すると位置づけています。仕組みは、ページを取得して読み、動画やリールを文字起こしし、動画の数フレームを説明してOCRし、各ページのスクリーンショットを「見た記憶の通り」に説明したうえで、AIの要約とタグを付けて埋め込みます。ハイブリッド意味検索は話された内容・書かれた内容・画面の内容・ページの見た目の各層を対象にし、約99言語に対応します。保存から検索可能になるまで約90秒、1万件のライブラリの検索が100ミリ秒未満とされています。価格は月額10ドル、または年額84ドルで、無料トライアルはありませんが、無料で検索できるデモライブラリがあります。

悠真: 仕組みとしては、ページを取得して読み、動画やリールを文字起こしし、動画の数フレームを説明してOCRし、各ページのスクリーンショットを「見た記憶の通り」に説明したうえで、AIの要約とタグを付けます。ハイブリッド意味検索は、話された内容、書かれた内容、画面の内容、ページの見た目という各層を対象にし、約99言語に対応します。開発者は、「ワンパンのパスタのコツが入ったリール」というクエリで、どこにも「パスタ」と書かれていないリールがヒットする例を示しました。

葵: 開発者が挙げる数字としては、保存から検索可能になるまで約90秒、1万件のライブラリの検索が100ミリ秒未満、あいまいな記憶からのクエリにおける上位5件の再現率89％、対応言語99言語があります。ただ、これらはすべて開発者自身の主張で、第三者による検証結果ではありません。

悠真: 同期の仕様についてですが、ブラウザのブックマークは自動で、ツリー全体をフォルダごと一括インポートし、Ctrl+Dでの新規保存も自動インデックスされます。X・Instagram・YouTubeの同期は、ユーザー自身のブラウザで各サイトのエンドポイントを通じて実行され、拡張機能はパスワードには触れません。ブラウザのブックマーク以外のソースは、ユーザーが有効化するまでオフのままです。既存アイテムは重複保存されません。

葵: さらに、ホスト型MCPサーバーも備えていて、一つのURLとOAuthサインインで接続でき、APIキーは不要。検索、最新の保存、ブックマーク詳細の3つのツールを持ち、Claude CodeやClaude.ai、Cursor、ChatGPTなどMCP対応クライアントから使えます。価格は月額10ドル、または年額84ドル、つまり年払いだと月あたり7ドル。無料トライアルはありませんが、無料で試せるデモライブラリがあります。保存数は無制限です。

悠真: 開発者は、意図的に保存したのに失くしてしまう問題、つまり4つのアプリと4つのリストにまたがる保存がまとめて検索できないことが動機だと説明しています。コミュニティからは、ログインやフォローが必要なXスレッドや、PDFリンク、Google系の直接リンクなどはこの方式では扱えないが、そうしたソースはロードマップにあるのか、それとも公開ページと4ソースに意図的に限定しているのか、という質問が残っています。また、ブラウザブックマークがデフォルトで全件インデックスされるため、社内文書などパイプラインに送りたくない項目をフォルダ単位で除外する仕組みが必要だという指摘や、約1,000万のチェス棋譜のインデックスを運用するユーザーから、取り込み時点の抽出内容がその後の検索可能性の上限になり、抽出器を改善しても再取り込みが必要になるという経験も共有されています。

葵: 最後はMemoria。カメラロール向けのローカル検索エンジンです。メーカーのAnas氏は、特定のミームやレシート、友人が特定の言葉を話している動画クリップを探すために10分間スクロールし続けるという問題を挙げ、クラウド型の検索ソリューションには個人のギャラリー全体をサーバーにアップロードしたくなかったと説明しています。本アプリは100%オフラインで、オンデバイスAIを使い、ローカルのWhisperモデルによる動画音声の文字起こし、写真やスクリーンショット内のテキストを読み取るOCR、顔と物体の認識を提供します。電話上にローカルデータベースを作成し、クラウド、アカウント、サブスクリプションは不要です。最初の250メディアまでは無料でテストでき、無制限版は一回限りの購入で、ローンチ期間中は大幅に割引されています。Anas氏は、オフラインMLモデルをローカルで実行すること、特にWhisperをローカルで動作させながらバッテリー消費を管理することが大きな技術的課題だったと述べています。

悠真: 本アプリは100％オフラインで、オンデバイスのAIを使います。具体的には、ローカルのWhisperモデルによる動画音声の文字起こし、写真やスクリーンショット内のテキストを読み取るOCR、そして顔と物体の認識の3つです。これによって、電話上にローカルデータベースを作成し、クラウドもアカウントもサブスクリプションも不要になります。

葵: 最初の250メディアまでは無料でテストでき、無制限版は一回限りの購入で、ローンチ期間中は大幅に割引されているそうです。Anas氏は、オフラインのMLモデルをローカルで実行すること、特にWhisperをローカルで動かしながらバッテリー消費を管理することが、大きな技術的課題だったと述べています。

悠真: Anas氏はフィードバックを求めており、アプリや技術スタックに関する質問には終日対応するとしています。ただ、こうした機能説明はすべてメーカーによるもので、コミュニティによる検証結果や実測データは提供されていない点は、ここまで紹介した他のサービスと同様、頭の隅に置いておきたいところですね。

葵: CrewTowerというmacOS向けアプリが登場しました。MacBook上部のノッチに常駐してAIコーディングエージェントを監視し、Claude CodeやCodex、Cursor、Gemini、Qwen、OpenCodeなどに対応します。エージェントが権限を求めると、実行しようとしている正確なコマンドやファイル編集、質問内容がノッチに表示され、ターミナルを開かずに1クリックで承認・拒否できます。

悠真: なるほど。エージェントが権限を求めると、あのノッチに実行しようとしている正確なコマンドやファイル編集、質問内容が表示されて、ターミナルを開かずにワンクリックで承認したり拒否したりできる、という仕組みですね。

葵: そうです。セッションの一覧も状態付きで見られるので、どれが作業中で、どれが待機中かが一目で分かります。該当するターミナルのタブへ直接ジャンプすることもできる。製作者のSaid氏が、複数のエージェントを並行して動かしているうちに返信を忘れて数時間待たせてしまい、時間とトークンを浪費した経験から作ったということです。

悠真: 承認の仕組みも面白いですね。エージェントのフックがローカルソケットでブロックして、決定が同じ経路を戻ってプロンプトを解決する仕組みで、アプリにはキーストロークの経路がないんだそうです。つまり、承認や拒否が実際に通るのはすべてローカル経由だという設計ですね。

葵: その通りです。しかも、再帰削除のような危険なシェルコマンドはカード上で強調表示されます。承認の種類も「一度だけ」「このセッション中」「常時」の3通りあって、常時を選ぶとプロジェクト設定に永続ルールが書き込まれます。

悠真: コンテキスト残量もリングで表示されて、残りが7割を超えるとアンバー、9割を超えるとレッドになる。サウンド通知やサイレントモード、差し替え可能なピクセルアートのキャラクターまで付いているんですね。対応環境はmacOS 15以降で、ノッチのないMacでも動くそうです。

葵: コミュニティでは、複数のエージェントを立ち上げながらターミナルを確認し続けたくない人に特に有用だという評価が寄せられています。すでにProduct Hunt公開の前から最初のユーザーが使い始めているそうですから、早期の支持が集まっているようですね。

葵: 次に紹介するのはShepherd Terminalです。コーディングエージェント向けに設計された永続型のmacOSターミナルワークスペースで、Product Huntで初のパブリックベータとして公開されました。CodexとClaudeをタブやペイン、リモートマシンをまたいで並行実行でき、アプリを閉じてもセッションを生かしたまま再開時に復元します。

悠真: このアプリの一番の特徴は、アプリを閉じてもセッションが生き続けるという点ですね。再開すれば、以前と同じタブやペイン、セッションがそのまま復元される。各エージェントが「作業中」「入力待ち」「完了」のどれかもリアルタイムで分かるそうです。

葵: メーカーの説明では、Shepherdというプラグインによって、エージェント自身がペインを作ったり、タブを生成したり、別のエージェントを起動したり、コマンドを送信したりというワークスペース操作ができるようになるそうで、ブラウザのレビューへの視覚的な注釈を構造化されたフィードバックとして返す機能や、SSH経由のリモート開発にも対応しています。

悠真: 開発動機が逸話的で面白いんですけど、メーカーは、CodexとClaudeが各ターミナルウィンドウに散らばっていって、どのエージェントが作業中なのか待機中なのか完了したのか、追跡できなくなったことだと言っています。複数のエージェントを別々のウィンドウで管理しきれなくなった開発者を対象にしているんですね。

葵: 入手性としては、Appleシリコン搭載のMacでmacOS 14以降向けのアプリが今日から提供されていて、署名・公証済みです。iOSのコンパニオンアプリは現在開発中で、近日公開とされています。

悠真: コミュニティからは肯定的な声が多い一方で、懸念も出ています。「アプリを閉じてもセッションが生きる」ことへの関心とともに、SSH接続が途中で切れた場合、リモートで書き込み中のエージェントの処理が途切れて、半端なファイルが残る可能性はないのかという指摘があるんです。あるペインのエージェントが別のペインのセッションを参照・操作できるのかという質問や、「Herdrという別のツールと比べてどうか」という質問も寄せられたんですが、いずれもまだ回答は示されていません。

葵: メーカーはその日のうちにコメントで質問やフィードバックを受け付けると述べていて、初のパブリックベータということもあって、バグや未整備の部分があり得ることを明言しています。「実際のコーディングエージェントの使い方に沿って作られている」「ターミナルウィンドウの混乱から救われる」といった反応もある一方で、これからが本番というのが正直なところでしょうね。

葵: Product Huntに登場したGaugeは、AI検索やAIエージェント向けの可視性分析、いわゆるGEOのプラットフォームです。開発者ツール企業に向けて「エージェント主導の成長」、つまりAgent-led Growthを提案し、「ツールをあらゆるコードベースに書き込ませる」ことを掲げています。コーディングエージェントが営業担当と話さずデモも受けずに製品を自律的に実装する時代に対応するというのが売りです。

悠真: 要するに、今のコーディングエージェントは営業担当と話さず、デモも受けずに、製品を自律的に実装していくという状況がありますよね。Gaugeはそうした現実に対応して、実際のコーディングセッションを実行して、エージェントに自社ツールが「選択されるか」「正しく使えるか」を改善するアクションを特定する、という説明です。

葵: 機能としては、ChatGPTやClaude、Gemini、Perplexity、CoPilotなど、AIが生成する回答の上で、自社ブランドがどう言及され、引用され、競合とどう比較されているかを追跡します。そして、コンテンツを生成して自社サイトやCMSに公開し、効果測定まで行う。顧客としてSupabase、Mux、PostHog、Resend、Clerk、Railwayなどが挙げられていて、各アカウントに100ドルの無料クレジットが提供されています。

悠真: 自社サイトのケーススタディも示されています。ただ、これらはすべて自社発表の主張であって、独立した検証は示されていません。たとえばPostHogはLLMからの参照トラフィックが41倍になったとか、Braintrustは可視性が2.5%から45%に、Vellumは7ヶ月で1.4%から40.3%に上がったなどと報告されていますが、あくまで数字は自社公表です。

葵: そうですね。一方で、Sanctumという顧客はSolanaのリキッドステーキング領域で5番目に引用されるドメインになり、主要LLMのAI回答の25.6%に出現したとか、Vellumは6大LLMで業界のAI回答の36.6%に引用され、Zapierに0.2%差の総合2位という報告も載っています。こうした劇的な数字は、そのまま額面通りに受け取るのは慎重になった方が良さそうです。

悠真: コミュニティの反応もやや逆説的に面白くて、「Gaugeを使うな。ツールをあらゆるコードベースに書き込まれたくなければ」というコピーへの好意的な反応や、その続きの「Gaugeを使うな。勝ち続けたいのでなければ」といった声が寄せられています。自社のマーケティングコピーをそのまま引用して楽しむような、好意的な受け止め方のようです。

葵: Salem Roboticsが公開したのは、危険な施設での点検・調査・操作を自動化するロボット用ソフトウェア、いわば「ロボットの頭脳」です。オペレーターがダッシュボード上で巡回ルートを描くだけで、ロボットがドアを開け、バルブを回し、計測を行い、ヒートマップやリスクを可視化したコンプライアンス対応のレポートを自動作成する仕組みです。

悠真: 特徴は、コーディングが不要で、特定のハードウェアに依存せず、既存のロボットにも導入できる点ですね。同社によれば、ロボットを自前で用意するか、既存システムにSalemの自動運転とデータ層を組み込むか、選べるそうです。

葵: 共同創業者のJanak氏の話が核心を突いています。ロサラモス国立研究所で原子力施設向けロボットを展開していた際、放射線調査が何十年も前と同じ方法、つまり技術者が携帯型検出器とクリップボードを持って巡回し、後から手作業でデータをデジタル化する方法で行われているのを目にした。これは遅く、高コストで、エラーが起こりやすく、人を不必要なリスクにさらす。そして、商業用原子力、石油・ガス、化学製造などの顧客にも同じ状況があったというんです。

悠真: 業務フローは3段階なんですね。計画段階では、電話やPCのダッシュボードで施設の地図にルートと停止点を設定する。実行段階ではロボットが自律的に動き、ドアを開け、人や設備を回避し、必要に応じて障害物を動かしながら、同じ任務の中で調査・点検・操作をこなす。そして報告段階では、読み取り値を施設地図に対応付けたヒートマップや、AIによる安全リスクの指摘、ルートや施設の改善提案を含む監査対応レポートが自動作成される。

葵: 対応する業務は、原子力点検、放射線調査、LDAR、腐食検査、NDT、温度計測などです。時刻と位置が記録されたデータは規制環境向けに設計されていて、接続環境、低接続環境、エアギャップ環境、つまり外部ネットワークと完全に切り離された環境でも動く。これは原子力施設のような機密性の高い現場では決定的なポイントでしょうね。

悠真: 自律動作は決定論的で、幾何学を考慮した動的な計画によって、予測可能性を維持しつつ状況の変化にも適応すると説明されています。つまり、場当たり的な判断ではなく、あらかじめ設計された枠の中で安全に動くことを重視した設計ということです。現在、日常業務が危険で高コストで人手不足という現場を対象に、パイロットサイトを募集しています。

葵: 技術者がクリップボードと携帯型検出器を持って歩くという半世紀前と変わらない手法を、こうした自動化が置き換えることになれば、現場の安全と効率の両方に大きな意味がある。規制の厳しい原子力や化学製造の現場から、どのように採用が広がっていくのか、注目したいところです。問い合わせ先も公開されているので、興味のある事業者は直接コンタクトできるようです。

葵: 今回は、判断そのものを記録して振り返るためのアプリ、Reckonを取り上げます。開発者はRoland Lethさんで、iPhoneとiPad向けの意思決定ジャーナル、いわば確信度の校正ツールです。判断を下す時点で、予測と、その推論を一文、そして確信度をパーセントで記録します。その後、結果が出るまでの間、新しく入ってくる情報をポジティブかネガティブかにタグ付けしながら、確信度を更新していく。その記録は全部残るという設計です。

悠真: なるほど。そして結果が確定したら、実際の結果と自分の満足度を記録して、30日から60日後に「この判断をもう一度するか」と自分に問い直す仕組みですね。判断が十数個貯まると、キャリブレーションが表示される。つまり70パーセントと答えた判断が、実際に約70パーセントの確率で当たっていたかどうかがわかる。自分の確信度が結果に対して過大寄りか過小寄りか、その偏りが見えるというのがこのアプリの核心ですね。

葵: ええ。開発者によると、普通のメモアプリは書いたことだけを保存するけれど、Reckonは予測と確信度と結果を保存して、確信度と的中率を比べる計算ができるところが違いなんだそうです。データはアカウント不要、バックエンドなし、端末内保存で、iCloud経由でiPhoneとiPadの間を同期。価格は買い切りで、サブスクリプションはありません。対象はファウンダー、親、プランナー、投資家などで、予測コミュニティ向けに売り出しているわけではないけれど、彼らにも読める内容だということです。

悠真: コミュニティの反応も面白いですよね。プロダクトマネージャーやディレクターに有用で、説明責任が後知恵バイアスやプリンシパルエージェント問題の防止に役立つかもしれないという声がありました。毎日数十件のアーリーステージのスタートアップをスクリーニングしているというユーザーは、30日から60日後の再確認が、ノートアプリと本物の判断記録の間のギャップを埋めると評価しています。ただし、そのユーザーは質問も残していて、判断の途中でポジティブかネガティブとタグ付けした新情報が、結果に無関係だった場合、それがキャリブレーションスコアに反映されるのか、それとも記録として残るだけなのかは不明だそうです。

葵: もう一つ、印象的なコメントがありました。結果が正しくても理由が間違っていることがあるから、推論と確信度を追跡するのが通常の判断ジャーナルより有用だというものです。ただ、サンプルの判断例が欲しいという要望や、開発者自身が「キャリブレーション」という言葉が、予測を専門にしない人に伝わるのかを問いかけているという声も出ています。判断の質を数字で振り返りたい人には、かなり刺さるツールかもしれませんね。

悠真: 続いては、Chrome拡張機能のSkim Recapです。開発者のYui Morii氏が、長い記事を数画面読み飛ばした後、「大事な部分を飛ばしたかもしれない」と不安になる体験から作ったそうです。この拡張機能は高速スクロールを検知すると、読み飛ばしたと推定される範囲だけを、カーソルの隣のカードに短い要約で返してくれます。

葵: ページ全体ではなく、読み飛ばした箇所だけを対象にするのがポイントですよね。それからもう一つ、モデルを都度呼び出すホスト型APIではなく、端末上で処理する点も特徴的です。要約はGemma 4 E4Bというモデルを、LiteRT-LMとWebGPUでローカル実行して生成していて、アカウントやホスト型のLLM APIは不要。テキストがブラウザの外に出ない設計だと言われています。

悠真: 対象は長文記事やドキュメント、エッセイ、調査記事など、流し読みしつつ文脈を失いたくない場面ですね。面白いのは要約の表示形式で、Focusなら段落形式、Smartなら番号付きポイント形式と、同じ生成テキストを整形し直すだけで、モデルは再実行されないそうです。さらに言語を指定すると、要約してから翻訳するのではなく、その言語で1パスで直接生成することもできます。v0.4で追加されたFeynmanという機能は、ページ上またはカード内で単語や語句を選択すると、Gemmaがその段落や周辺コンテキスト、最も近い見出し、ページタイトルを使って、その文脈での意味を説明してくれます。

葵: これはどういう位置づけなんですか？要約は意図的に読み飛ばした箇所の内容に限定されているため、ページが定義していない用語は説明できない。その穴をFeynmanが埋めるという設計で、明示的に要求された場合にだけ実行されるそうです。v0.4では他にも、要約ポイント数の上限、Retryによる別表現での再生成、shadow rootによるホストページのCSSからの隔離も加わっています。

悠真: ただ、制約もあります。初回に一度、約3ギガバイトのモデルダウンロードが必要で、WebGPUと相応のローカルディスク・メモリ要件があります。開発者は、高速スクロールの閾値が自然に感じられるか、そしてFeynmanの説明が十分なコンテキストを使いつつ長くなりすぎないか、この2点についてフィードバックを求めています。なお、これらはすべて開発者自身の説明に基づく主張で、独立した評価や検証結果ではないそうです。ローカル実行でプライバシーを保ちたい人には、とても気になる選択肢ですね。

葵: さて、今回のお話はここまでです。最後までお付き合いいただき、ありがとうございました。皆さんが今日のお話をきっかけに、少しでも新しい視点を持ってくださればうれしいです。

悠真: それでは、次回もどうぞお楽しみに。またどこかでお会いしましょう。今日も良い一日を。