0920 | 今週の注目ツール巡り：会議から習慣まで

葵: 皆さんこんにちは、Product Hunt今日のブリーフィング、パーソナリティの葵です。

悠真: 悠真です。今日は11個のローンチから、一番話す価値のあるものを厳選して、それぞれ「誰のための何か」「既存の選択肢と何が違うのか」「根拠は何か」「限界や疑問は何か」を順番に見ていきます。

葵: 全部をフラットに並べるんじゃなくて、テーマごとに絡めて話します。で、今日一番面白い共通点は、実は「AIが記憶を管理する」話です。会議とデータの両方で、同じ問題が同じ解き方で攻められている。まずはVoiceCapから。

悠真: VoiceCapはEUの会社が作ったAI議事録ツール。売りは「100以上の言語で文字起こしして、要約・アクションアイテム・決定事項を同じ言語で書き出す」こと。ほとんどのAIノートテイカーは英語が強くて、他の言語だと英語に訳して戻すから、後付けの翻訳みたいな要約になる。

葵: 作った本人のRokasさんはリトアニアでAI代理店を経営していて、クライアントとのミーティングはリトアニア語。三人がそれぞれメモを取って、二週間後には誰も何を決めたかで合意できない、というのを何年も繰り返してきたらしい。だから自分たち用に作って、それが製品になった。

悠真: 機能としては、録音の入り口が三つある。部屋で直接録音、ZoomやGoogle MeetやTeamsにボットを送る、あるいはファイルをアップロード。そして決定的なのは「決定ログ」。ほぼ全員が要約とタスクは出すけど、決定事項を独立したレコードとして扱うノートテイカーはほぼいないと本人が言ってる。

葵: ここ、ちょっと具体的に確認しよう。製品ページの例だと、会議のトランスクリプトから「フェーズ2の予算は9月末までに承認が必要」という文が12:44の発言として抜き出されて、それが「Kick-off: website redesign proposal」の会議と紐付いてる。文脈も付く。トマスが承認者で、ルータが両フェーズを別々に見積もった提案書を送る、とか。

悠真: しかもそのログは全会議横断で検索できて、MCP経由でClaudeやChatGPTから質問できる。例のスクリーンショットでは「過去3回の通話でNorthwindに何を約束した?」と聞くと、まだ未完了の2つのコミットメントが出てきて、出典がどの会議のどの秒かにリンクしてる。Rokas本人が「一番フィードバックが欲しいのは決定ログ」と言っていて、三ヶ月後に誰が何に同意したかを復元したことがある人に、今どうやってるか聞きたいと明言してる。

葵: つまりこの人の主張は、「要約は誰でも出せる。決定をどう記録するかが差別化ポイントだ」ということ。価格は、フリープランが300分でカード不要、Proが1シートあたり月29ユーロで1,000分、Businessが49ユーロで無限録音。閲覧者は全プランで無料で無制限。EU企業として、録音はフランクフルトに保存、学習には使わないとも言ってる。

悠真: もちろん、これはメーカーの説明だから、文字起こしの精度が本当に「業界をリードする」のかは検証のしようがない。コミュニティの反応も、「他と何が違うの?」という一点の質問があったくらいで、実データでの比較はまだ上がってない。ただ、言語の方向性と決定ログという切り口は、少なくとも主張としては明確。

葵: さて、ここでBasedash Modelsに移るんだけど、これがVoiceCapと驚くほど同じ発想なんだ。違うのは、会議ではなくデータの方。

悠真: Basedashの創業者Maxさんが投稿してる。Modelsは「会社が実際に動いている概念」を、再利用可能でガバナンスされたSQLとして一度だけ定義する場所。customers、orders、active accountsみたいな概念をモデルとして作って、そこにメジャー、セグメント、リレーション、シノニム、使い方のガイダンスを全部添付する。

葵: で、使う側はSQLでテーブルのように参照できる。「select * from models.customers」って書くだけで、誰の書き方でも同じ定義にヒットする。そしてAIアシスタントも同じモデルを読む。

悠真: Maxさんの事例は、自分たちのNorthstar指標をこの仕組みで運用してるというもの。customers、orders、active accountsの定義が一つになったことで、以前は「三つの競合する集計結果」が出てきてた質問が、一つのモデルにヒットするようになったと。つまり、部署やSlackのスレッドが変わっても計算がフォークしない、ということ。

葵: 会議で言えば「何が決まったかを一つの記録に残す」、データで言えば「何がactive customerかを一つの定義に束ねる」。どちらも「合意を言語化して保存して再利用する」話。しかもAIがその合意を読むことで、プロンプトが曖昧でもチームが決めたメジャーとフィルターに到達する。

悠真: この週、Product Huntのコミュニティにはトライアルを1週間延長するオファーを出してる。あと、既存のDefinitionsという機能から自動移行するとか、管理者がワークスペースごとにModelsをオフにできる、という運用面の配慮も書いてある。

葵: ただ、限界は手のひらサイズ。これはまだ主張であって、実際に「三つの競合する集計」が消えたかを外から確認する数字はない。Modelsが全部の概念をカバーするには定義作業自体が仕事になるはずだし、そこは今後どう運用されるかをみるしかない。

悠真: さて、こうしたツールの裏側では、AIエージェントがどうツールやモデルと繋がるかが鍵。そこでRuby UTCP。

葵: UTCPは「Universal Tool Calling Protocol」、MCPの代替として設計されたオープン規格で、Ruby UTCPはそのバージョン1.1をRubyに持ち込んだもの。作者のKamil Mościszkoさん。

悠真: 核心はここ。MCPはラッパーサーバーを経由してツールを呼ぶ。UTCPは、発見さえ済めばエージェントがHTTP、gRPC、WebSocket、CLIといったツール本来のネイティブ転送で直接呼ぶ。READMEの言葉を借りると「ラッパー税」をなくす、ってこと。

葵: 「ラッパー税」というのが上手い表現で、既存APIをAIから使えるようにするために新しいサーバーを挟むと、レイテンシが増えて、セキュリティと認証の構造を再構築しないといけない。UTCPは「人間がそのAPIを触れるなら、AIも同じセキュリティ保証で触れていいはず」という原則で、既存の認証・課金・セキュリティをそのまま保つ。

悠真: Ruby UTCPの実装としては12の転送に対応、MCPもその一つに含まれる。ストリーミング、認証、OpenAPIディスカバリー、そしてCodeModeという、複数ツールのワークフローをコンパクトなRubyコードで一気に書ける仕組みも入ってる。MITライセンスでオープンソース。

葵: UTCPのGitHubを見ると、Python、TypeScript、GoのSDKに加えて、GoエージェントフレームワークやLangChainアダプター、Pydantic AI連携などが既にUTCPを統合してる。つまりこれは Ruby だけの話じゃなく、エコシステム全体の流れのRuby版。

悠真: で、同じ「ネイティブに触れる」方向性の話がBolt Forgeにもある。こっちはAI同士の接続じゃなくてモデル自体の話。

葵: Bolt ForgeはBolt.newの中に入った新しいエージェントで、GLM 5.3 FlashとGLM 5.3をメインに、Kimi K3とDeepSeek v4 Proをオプションに、オープンソースモデルだけで動く。

悠真: 取引の構造がこの話の肝だ。Forgeに切り替えると、個人のProプランに10月14日まで最大50倍の追加利用が無料でつく。その代わり、ビルドセッション、つまりプロンプト、コード、修正履歴が匿名化されて、オープンウェイトのモデルを訓練するためのデータセットになる。Arcee AIという米国のオープンモデルラボが最初のライセンシー。シークレットや個人情報はパイプラインで剥ぎ取るとしてる。

葵: ベンチマークは「Bolt Build Index」というBolt独自のもので、Forgeのオープンモデルは92.2、最上位の有料モデルClaude Opus 5は101.0、つまり約91%の能力。有料モデルとの差が9ポイント、その見返りが50倍の使用量。

悠真: ここで、コミュニティの反応に注目したい。じゃなくて、コミュニティの声に注目したい。あるコメントが鋭く突っ込んでる。「内部ベンチマークは新しいものを良く見えるように選ばれるものだ。外部の人が再実行できる公開評価やタスクセットはあるのか、それとも91%は今は信じるしかないのか」。これは確かに正当な疑問で、現時点では公開評価はない。

葵: さらに、使い方にも限界の明記がある。Kimi K3とDeepSeek v4 ProはGLMペアより使用量を速く消費する。ForgeはまだPDFのアップロードに対応してない。そして、本番ビルドをForgeに移す前にプロジェクトを複製すべき、複雑な本番作業はStandardかMaxに残すべき、とBolt自身が言ってる。1つの月次バーでデイリー上限がなく、100%でStandardに自動切替。

悠真: 経済的な背景も書いてある。Stanford HAIのAI Indexを引いて、18ヶ月で推論コストが280倍下がった、その崩壊がこの規模のアロケーションを可能にした、としてる。オープンモデルは「実際のソフトウェアの作られ方」を見ることで向上する、それを人が手作業で書くしかないデータを、Forgeセッションがオプトインで提供する。

葵: 話を戻すと、Ruby UTCPもBolt Forgeも「AIが直接、ネイティブなものに触れる」という流れ。ツールのプロトコル側と、モデル側、両方で。

悠真: そこから、いよいよ身近な制作作業の自動化へ。LumikoというChrome録画拡張。

葵: 問題の切り出しが良い。作者は「5分の録画の後に毎回キーフレームに1時間を失っていた」。チュートリアル映像の滑らかなズームとパンって、実は誰かが全部のクリックの上に手動でマーカーを置いて作ってるんだよね。

悠真: Lumikoは録画中にカーソルとクリックを追跡して、停止した時点で自動的にズームとパンの動きを生成する。キーフレームなし。その上に、タイムラインエディタでクリップのトリム、分割、並べ替えができる。Smart Blurは、APIキーやパスワードを一つのドラッグで隠せる。

葵: 技術的な面白さは「全部ローカル」なところ。レンダリングはマシン上で処理されて、アップロードなし、アカウントなし、待ち行列なし。価格はProが9ドルの買い切りで、透かしを外し、4K出力を解禁し、3台の端末を終身でカバー。無料枠でも無限録音、オートズーム、Smart Blur、1440pまでの出力ができる。

悠真: コミュニティからは、9ドルの買い切りは安いという声と、もっと重要な指摘が一つ。カーソル位置は「ほとんどのとき正しいが、話しながらマウスを動かしているテイクでは間違っている」という人いて、「Lumikoが置いたズームを上書きできるのか?」と聞かれてる。これは録画後の編集で直せるか、つまり自動編集の失敗を人が直せるかの問題。

葵: で、同じ問題、「あとで見返せない」を、録画じゃなくてスクリーンショットで解決するのがBiBimba。

悠真: Mac用のクリップボードマネージャーで、日本のソロデベロッパー、Rihitoさんが作った。スクリーンショットに即座にOCRをかけて、コピー履歴と同じ検索ボックスに入れる。「invoice」と打つと、コピーしたテキスト、その単語を含むスクリーンショット、保存したスニペットが全部出てくる。

葵: AI機能は、翻訳、要約、ビジネスメールのリライト、自分で保存した指示、これがAppleのオンデバイスモデルで完結する。サーバーに何も送らない。履歴とスクリーンショットもローカルに保存されて、何件・何日間保持するか自分で決められる。分析や広告はなし。

悠真: 価格は9ドルの買い切りで3台のMac。同じメールで再購入すれば3台追加。必要なのはApple siliconとmacOS 26以上。これが明確に宣言された制限で、OCRとオンデバイスモデルが現在のOSの機能だから、作者はそうするしかない、としてる。インターフェイスは10言語。

葵: コミュニティの質問が実用的。スクリーンショットヘルプガイドを5言語で作ってる人から、イタリア語、ドイツ語、フランス語のアクセント記号をOCRが正しく拾うのか、またOCRはキャプチャ時に走るのか検索時なのか、スクリーンショットが50枚埋まった後にテキストを探すときにはもう遅い、という指摘。答えとしては、BiBimbaはキャプチャ時に即座にOCRをかけている、というのが作者の説明。

悠真: もう一人が、重いスクリーンショットユーザーでもOCRが追いつくのか、検索可能になるまでのラグはないかと聞いてる。これは同じ懸念の別側面。

葵: ここまでのLumikoとBiBimbaは、共通して「あとで見返せない」問題を、録画とクリップボードという異なる素材で解決してて、どちらもローカル処理と買い切り価格という同じ思想。月額のサブスクとは明確に別の選択。

悠真: 次は、ツールが日々の行動に踏み込む領域へ。Squirrel。

葵: これ、発想がすごく面白い。「開きすぎるアプリに自分で値段を設定する」iPhoneアプリ。

悠真: 構造としてはこう。問題のアプリを設定すると、タップした時にハードブロック。解除したければSquirrelを開いて、開けたい時間と、自分に設定する金額を決める。でも、重要なのは、その金銭はSquirrelを一切通らない。カードも銀行口座も接続しない。自分の証券口座で自分に投資して、何を買ったかをSquirrelに伝えると、ライブの価格で追跡してくれる。

葵: つまり「誓約の証」みたいなもの。アプリは支払いを一切処理しないし、ブロックして開くのは常に無料。保存した金額は自分宛のメモとして機能する。目標、リミット、ストリークは全部なし。ストリークがないから「失敗」がない、という理屈。

悠真: 作者Brianさんは、感謝祭休みの夜に友達と「ソーシャルメディアに脳をハイジャックされた」という共通感覚と「投資が遅れてる」という別の共通感覚を繋げようとして、この2つを一つの構造にしたと説明してる。その人の自己申告では、45分のデイリー上限を何ヶ月も設定していたのに週10時間以上使っていたのが、Squirrelを使った最初の週は1時間45分、翌週は56分になった。

葵: 注意が必要なのは、これが一人分の自己報告であること。Brianさん自身も「これは自分のデータでしかない、ただ違いが大きすぎて他の人にも試してもらいたい」と言ってる。自分を検証対象にした上で、一般化はしてない、というのは誠実な態度。

悠真: コミュニティからの質問で二つ面白いのがあった。一つは「ブロックは本当にハードなのか、一度ついたら上書きはないのか」という点。多くのスクリーンタイムアプリをやめた原因は「今回だけ」という上書きボタンだった、と。もう一つは「時間がそのまま通貨になるなら」という提案。音楽家が1時間スクロールしたら、音楽に1時間を「負う」、戻ってこないのに、次の1時間をどこに使うか考えさせる、という発想。

葵: この「通貨を時間に変える」という提案、実は次の話と地続きで、ここから瞑想と健康系アプリへ。

悠真: Mantra Timer。作者のBrentさんは3,700日以上連続でTranscendental Meditationを実践してる人。10年以上の練習の末に、ただ清潔なタイマーを求めたのに、市場は肥大化したアプリだらけだったと。

葵: 公式の選択肢は侵入的な個人的背景データを要求するか、終わりのないガイド付きプログラムを押し付けるか、そしてほぼ全てが「沈黙に座るだけ」なのに月額サブスクを要求してた、と。だからMantra Timerは、開くと直接タイマーが出る、沈黙を尊重する静かな通知、トラッキングなし、ソーシャル機能なし、で構成されてる。

悠真: 商業的な決断も書いてある。当初は標準的な年間サブスクティアを計画してたけど、スタジオの「アンチレンタル」哲学が固まるにつれてそれが偽善に感じられて、方向を完全に変えた。コアアプリは完全に無料で、上級者向けの機能はMantra+という一回きりの少額支払いで解放。9.99ドルがローンチコードLAUNCH2026で5.99ドル。

葵: 免費版に含まれるのは、30秒のウォームアップ、20分、1分のクールダウンの標準タイマーと40分の拡張タイマー、そしてカスタムタイマー1つ。セッション後の振り返りで精神の明晰さと身体的な質を評価できる。12ヶ月分のローカル履歴。Mantra+を買うと、無限のカスタムタイマー、深い統計、マイルストーンバッジ、iCloud同期、Apple Watch、ファミリーシェアリングまで全部が付く。

悠真: ここで、コミュニティからの鋭い質問が2つ。「ゼロデータ収集って言うけど、どうやって人が実際に毎日使ってるか知るの?」と「アプリに入れないと決めたものは何か?」という。前者はBrentさんが明確に意図的に放棄した限界。後者は瞑想アプリが肥大化する理由への応答として、実はこの質問が一番核心的で、複雑さ自体がもう一つの管理すべき対象になる、という指摘があった。

葵: 一方で同じ市場にLullという全く別の解法。こっちは録音を再生しない。

悠真: 作者Evanさんは3年間の夜と週末をかけて作った。使い方は、1分間、話すかタイプするかで今の状態を伝える。するとLullがその瞬間のために瞑想を書いて、11の声のうちの一つで読み上げる。2日とも同じセッションはない、なぜなら2日とも同じ日じゃないから、という理屈。

葵: 技術的にも深い。Ouraリングを接続すると、Lullは回復度を読んでから書き始める。ひどい夜の翌朝はトーンが変わる。Apple Watchを付けると、セッションが手首で走って、ガイド付き呼吸とハプティクスが付き、心拍が記録される。終わった後、Lullは安静時のベースラインからどれだけ落ち着いたかを示す。ただし、クリーンなデータが取れなかったら何も出さない。

悠真: そしてEvanさんの明確な方針が「嘘をつかない」。無理に安定スコアを作らない。ストリークの圧力なし、罪悪感の通知なし、ゴールドスターなし。深夜3時用のウィスパーボイスがある。HealthKitから心拍・HRV・睡眠を入れて、Mindful MinutesとState of Mindを出力する。Apple Watchアプリが単独で走る、Live Activities、ウィジェット。設計、実装、文章のすべてをEvanさん一人がやったと。

葵: 価格は無料ダウンロードで、サブスクに7日トライアル。iPhoneとApple Watch限定。Evanさんは「アップボートよりも、1セッション試して、どこで離脱するか教えてくれ」と言ってる。それがこの人の現時点での一番の開かれた疑問。

悠真: ただ、コミュニティからの質問でまだ答えが見えてないのが一つ。「ハルシネーションにはどう対処するのか?」つまり、瞑想を生成するAIが、実際に不適切な内容や、意図と違う瞑想を書いてしまう可能性をどう扱うのか。これは実用化で一番の未知数。

葵: そして、同じ市場、同じ「静けさと誠実さ」という価値を売りにしてるのに、アプローチが正反対。Mantra Timerは最小化で誠実さを追求して、Lullは個別化で誠実さを追求してる。共通してるのは、ストリークと通知の圧力を拒否して、サブスク疲れと計測疲れへの反発を代表してること。

悠真: 最後のテーマへ。情報整理と作業の残り。3つの製品を順番に見よう。

葵: まずDoneit 3.2。これはDoneit Assistという機能の刷新で、マルチモーダルのプロンプトに対応して、タスクを計画するときに写真を添付できる。

悠真: 具体的には、手書きのリスト、ホワイトボード、書類の写真を添付すると、それをタスクに変換できる。追加の詳細を入れてタスクの精度を上げるオプション、リマインダーと属性を提案させるオプション、タスクをサブタスクに分割させるオプションもある。さらに、タスクリストの要約を作り、その中のキータスクをハイライトして、次に来るタスクを表示できる。

葵: Siri AIとの連携も追加されてて、Doneitのタスクリストとタスクが新しいSiri AIのスクリーン上の認識に見えるようになり、Siriからタスクを追加できる。ショートカットのパラメータも増えて、iOSの新しい超大きな縦向きのリストウィジェットも対応。

悠真: コミュニティの指摘がここで重要。「ホワイトボードの写真を実際のタスクリストに変えるのは本当に便利なデモだけど、手書き認識は実際にはここで壊れやすい。雑な速記、矢印、線で消された項目。Assistが何かを誤読したとき、AIが『何を見た』かをタスクを作る前に表示するのか、それとも間違ったタスクがリストに現れた後にしか分からないのか」。これは実用性の鍵で、現時点ではこの答えはコミュニティのコメントに見当たらない。

葵: 次がPunch。グループチャットに埋もれる重要情報を保存・共有するアプリ。

悠真: ユースケースが具体的。友達とバカンスに行って、Airbnbの住所、ドアのコード、集合場所を知りたい。100件以上のメッセージをスクロールする代わりに、Punchに全部保存して共有する。

葵: 既存の選択肢との差別化が作者の説明で明確。ノートアプリはすぐに散らかって見た目がくたびれて、個々のピースをノートから共有できない、OS間の非互換もある。DriveやDropboxなどのストレージは共有性を持ってるけど、保存に寄りすぎてる。Punchは「共有ノートとビジュアルボードの間」のものとして、住所、リンク、写真、ビデオ、お母さんへのギフトアイデア、笑いが止まらないミームまで、自由に置ける。

悠真: 作り手の話も結構面白い。3人のチーム、Ryanがバックエンドとデザイン、Justinがモバイル、Paulがマーケティング。クロスプラットフォームの技術選定ではReact NativeとFlutterの間を何度も往復した。デザインでは「目立つとは何か」で大きく意見が分かれて、妥協した今のデザインを愛してる、と。最大の苦戦はApp Storeの審査で、3週間、複数の却下、うち2つは「持ってないと言われたのに実際は持ってた」もの。Play Storeは24時間で一発合格だったのに、という対比が鋭い。

葵: コミュニティの反応は「このローンチはPunchがたっぷりある」という軽い賛辞と、マーケティングの野心への注目。名前からデザインからSNSマーケティングまで「目立つ」ことに全力をかけてる、と本人たちが言ってる。

悠真: 最後はSteam Frame。これはちょっとジャンルが違うけど、情報と作業と娯楽を別の場所に引き出す道具、という点では同じテーマ。

葵: Valveの新しいVRヘッドセットで、Steam Deckの思想をVRに持ち込んでる。SteamOSが走って、対応ゲームは単体でも動く。フルPCライブラリを使いたいときは、付属の6GHzアダプターでゲーミングPCからストリーミングする。

悠真: コントローラーの設計が賢いと評価されてる。VRワンドとしても、フルゲームパッドとしても機能する。ほとんどのスタンドアロンヘッドセットはVR入力か本物のコントローラーのどちらかを選ばせる。Steam Frameはその両方を一つのハードで解決してる。

葵: Product Huntのハンターのコメントが印象的で、「Valveは、デスクトップモードを最初に開きたくなるヘッドセットを作った」と。VRレイヤーの下に普通のLinux PCがいて、VRゲームをするのと同じくらいそこで遊んでしまいそうだ、と。

悠真: ただ、価格は明確な課題。あるコメントが、Meta Quest 3と比べると約3倍の価格だ、と指摘してる。これは普通の批判で、Questのスタンドアロンの生態系と比べると、Steam FrameはPCが必要なケースが多い分、初期投資の見合いが変わる。

葵: コントローラーの重さについても、長時間セッションでQuestとどう比べられるかという疑問が上がってる。Valveのコントローラーは軽くない、という観察。ここも実測待ち。

悠真: さて、今日のまとめ。VoiceCapとBasedash Modelsは「会議とデータの合意を、検索可能な一つの記録に束ねる」話。Ruby UTCPとBolt Forgeは「エージェントがネイティブなものに直接触れる」話。LumikoとBiBimbaは「見返せない素材を検索可能にする」話。SquirrelとMiseは「決める瞬間を意識させる」話。Mantra TimerとLullは「計測とサブスクへの反発」話。Doneit、Punch、Steam Frameは「情報と作業と娯楽を別の場所に引き出す」話。

葵: 共通してるのは、どれも解決策の主張が先行していて、実際の検証データはまだ薄いこと。だから、どれも「どうだったか」を後で知りたい。今日の詳細は、各製品のページを確認してほしい。それでは、また明日。

悠真: お疲れ様でした。