0921 | AIの仕事を信頼する、その境界線

葵: こんにちは、Product Huntの毎日ブリーフィング、葵です。

悠真: 悠真です。今日も24時間以内に投稿されたローンチから、特に話す価値のあるものを選んできました。今日は全体を貫くテーマがいくつかあって、一番大きいのは「AIが実行するけど、人が最後に見る」という設計ですね。その話から始めましょう。

葵: そうですね。まず最初の製品はMycel。これはクライアントワークをやる人向けのツールで、サービス業をしていると、納品物、レポートとかアップデートとか資料って、最終的に必ず自分の目を通さなきゃいけない。それがクライアントの件数の上限を決めてしまう、という問題から入ってるんです。

悠真: メイカーの説明によると、解決策は「仕事をAIにやらせるけど、離した環境でやらせる」こと。各ジョブごとに使い捨てのサンドボックスが立ち上がって、仕事をして、破棄される。そして重要なのは、そのエージェントが認証情報を持たないこと。何もクライアントに届く前に人の承認が入る。承認前の出力はユーザーの目には見えない、というところまで言っています。

葵: 面白いのは承認前の機械的なチェックね。例の中で「要約は4つの発見と言っているのに、表は5つある」といった矛盾を見つけると、ドラフトを保留にして理由を書かせる。それが直るまでユーザーには見せない、と。あと、前の月にそのクライアントに納品したものを参照して書くから、先月のオープンな項目が勝手に消える、みたいなことが起きない設計。

悠真: 承認前に編集したら、修正前と修正後の両方が保存されて、その差分が学習材料になる。つまり「あなたが直したやり方」を覚えて次のドラフトに生かす、という流れです。チャットウィンドウでドラフトさせるのとの違いはここで、彼らの説明では、チャットはタブを閉じた瞬間に何を直されたか忘れる、そのコストが6ヶ月後にまた発生する、と対比されています。

葵: もう一つの柱がタイマー。5つのタイマーがデモで動いていて、例えば請求されているものの催促、止まった仕事の再開、ビジネスの見つけやすさの維持。朝だれも自分からやらない類の仕事を、自分の時計で回す、と。価格は月額299ドルから、あるいはセルフホストなら無料。

悠真: コミュニティの反応では、承認レイヤーと過去の編集からの学習が特に刺さったというコメントがあって、企業の承認プロセスに合わせた差分や承認コメントの読み書きができるかという問いも出ています。これは正しい質問で、現時点では回答が見えていない。

葵: それと鋭い質問が一つ、「修正ループは最初に試す部分です。複数のクライアントのレポートがまったく違う形の場合、片方の修正が他のクライアントの下書きに影響するの?」というやつ。これ、概念的には自然な疑問で、クライアントごとに学習が分かれるのか、横串で効くのかは説明では明確にされていない。未知の部分として正直に残しておくべきですね。

悠真: そういう設計判断は「どこまで学習を共有するか」で、実は難しい。共有しすぎると別クライアントの語調に汚染されるし、分けすぎると学習の利が薄い。回答がまだないのは、後で確認する価値のある開いた問いです。

葵: 次の製品は、その逆側の問題を解いています。Epismo。あなたはAIツールの間のつなぎ役に疲れていませんか、という話。

悠真: 話者本人の説明がまず説得力があって、「ChatGPTで始めて、Claudeで続き、Cursorで仕上げて、チームメイトに渡す。モデルは仕事どんどん上達してるのに、仕事そのものが移動しない。ドラフトは動く。ドラフトの背後にある決定は動かない」と。

葵: そしてここで自白的なエピソードがあるんです。今回のローンチ準備をEpismoでやっていたら、実は決めていたことがある。自動で会話をすべてキャプチャする、とは言わない、と。それがドラフトでChatGPTからClaudeに移ったとき、テキストだけがコピーされて決定が一緒に移らなかったから、次のバージョンはまさにそう書いてしまってた、と。

悠真: 決定がテキストに付いてこない、という実例をメイカー自身が提供してるのが皮肉が効いてるし、正直だなと思います。

葵: そこでEpismoは、この「仕事」をチャットの外に置く場所を用意する。Caseと呼んで、現在の成果物、背後にある決定、レビュー、次のステップを保存する。だからClaudeでもChatGPTでもCursorでも、次の人でも、同じ仕事の状態から続けられる。

悠真: Auto reviewという機能もあって、保存された成果物に新しい視点でレビューを与える。例では「カッコ良い」じゃなくて「使用量の根拠がない。解約の主張はまだ推測」といった具体的な指摘を書く。しかも元の成果物は変えずに、問題を指摘するだけ。次のターンがそれを受ける。

葵: 使い方の流れは「パターンから始めない」こと。まず仕事を保存し、手渡しし、繰り返す価値のあるものだけがプレイブックとして残る。だから自動化の型を最初に設計しなくていい、というアプローチ。起動前のローンチ自体をEpismoで回したtrailが公開されてて、確認できるようになってます。

悠真: コミュニティの反応はユーモア多めで、「コピーアンドペーストは少なくとも自分が必要とされている感をくれる」っていうコメントがあって笑いました。それと別のコメントで、これが7回目のローンチらしい、と指摘されていて、「前回から実際に何が変わったの?」という鋭い質問が出ている。

葵: その点、明確な答えはまだ出てない。ただ、公開されたtrailで自分の作業を具体的に示してるのは、他のAIツールのローンチだとあまり見ない形。そして「自動キャプチャをしない」と決めたのは、実は信頼の問題で、何でも自動で取るとユーザーが驚くから、明示的な保存を基本にしてる、という考えが透けて見える。未知は、実際に複数のモデルを横断するチームでどれだけ friction が減るか、は実運用でしか確かめられない。

悠真: さて、同じ「AIが実行する、人は確認する」の発想を個人向けに振ると、Minicartという製品に行きます。これはecomerceをやったことのない人に向けて、店を立ち上げて運営するのをAIチームに任せるもの。

葵: チームというのがポイントで、一つのAIじゃなくて3体に分かれてる。Sloaneが店を作って、写真を商品リストにして、在庫と支払いを設定。Miloがマーケティングを担当して、プロモーションの割引、ソーシャルポスト、キャンペーン、Instagramへの公開。Loganがオペレーション、つまり注文と発送と顧客サポートの返信のドラフトを扱う。チャットで普通の言葉で頼んで、レビューする。

悠真: メイカーのChrisさんの例がわかりやすい。作ったものの写真をアップして「これを15ドルで売りたい」と言うと、Sloaneがリスティングと商品画像を作る。それからMiloに「これを広めたい」と言うと、ソーシャルポストができる。従来のECビルダーは道具を提供するが、Minicartのエージェントは1つの繋がったプラットフォーム内で、あなたの商品とビジネス文脈を使って実際にアクションを取る、という対比です。

葵: 既に4,000以上の店がMinicartで作られたというのがメイカーの主張。Handmade goods、コレクション、アパレル、サービスと幅がある。CTOのコメントで、コマース専用に作ったAIハーネスがある、という言及も。

悠真: コミュニティの質問が集中したのがまさに「自律性の範囲」。どこまで Milo や Logan が自分で完結して、どこからが承認待ちか、という問い。レビューの粒度も、各段階で承認か、最後だけか、という質問。そして Loga が顧客に返信するとき、本当に人のように聞こえるのか、ボットとわかるのか、という実践的な質問。

葵: ここはメイカーの説明だけでは確かめられない。だから正直に言うと、Minicartの一番重要な未知は「実際にどの程度、日常運営で人が押さえるべき点が残るか」です。ただ、3体に分けて各々が同じビジネス文脈を共有するという設計は、他のAI店ビルダーと違う方向性。1つのAIが全部やるときに起こる「文脈が断片化して他の部門と食い違う」問題を避けてる、という読み方もできる。

悠真: コミュニティにもその点を褒めたコメントがありました。他のECビルダーの発展形として、店作り、マーケ、オペレーションを分業させるのが理にかなってる、と。

葵: 一つ価格の情報があって、Product Hunt用に最初の3か月が月1ドル、コードはPH2026。そこにCTOからの独自のハーネスの話、あとキャンペーンの割引コードや季節の変更をSloaneがどこまでカバーするかという具体的な質問、などコメントに残ってる。国際的に使えるか、という質問も。今の時点で答えはまだ見えてない。

悠真: ここから少し軸を変えて、営業や開発者マーケティングの側に移ります。Morsa Signalsという、開発者ツールのための GTM と SEO/GEO のワークフロー集。

葵: メイカーのSergeiさんの説明だと、開発者ツールは、良い製品でも、正しい開発者に届かない、その重要性を説明できない、AIと検索の世界で見つけてもらえない、という問題がある。だから4つのワークフローを一つにまとめた。

悠真: 一つ目がContact Search、つまり規模を拡大するための連絡先検索。特徴は各連絡先に「なぜ適合するか」と「開口メッセージ」が付くこと。例では「あなたのissueでまさにこういうツールを求めてました」みたいな具体的な理由。

葵: 二つ目がFirst Users、初期ユーザー探し。ソロの開発者や初期段階のdevtool創業者向けに、実際に最初の会話をしそうな人を手作業で選ぶ。製品の説明を貼り付けるだけで、sales deckもペルソナも要らない。bioとrepo activityと公開技術シグナルを合わせて判断、という。

悠真: 三つ目がAI Visibility Auditで、ChatGPT、Perplexity、Claude、Google AI OverviewみたいなAIが、あなたのツールをどう理解してるかをスコア化。技術的な準備度、ポジショニング、公開フットプリントをスコアして、AIがあなたのツールをスキップしたり、うまく分類できなかったりする穴を指摘する。サンプル出力ではAI Visibility Score 62/100で、「弱いカテゴリシグナル」「比較の文脈がない」「ICPやバイヤーが不明確」みたいな具体的な項目が出てる。

葵: 四つ目が競合追跡。GitHub活動、リリース、価格変更、RedditやHacker News、Product Huntでのローンチなど、比較対象のdevtoolが実際どう動いてるかを読み取る。なぜその動きが大事か、を平易に説明するのが特徴。

悠真: そのほか、positioningのワークフローもあって、カテゴリ、ICP、バイヤー、ワークフロー、証拠を明確にして、AIやバイヤーが繰り返せる形にする、というやつ。あとGitHub、Reddit、Hacker Newsを監視して、参加価値のある会話をランキングするワークフローも。ただしこれは代理投稿はしない、というのがはっきり書かれてる。

葵: コミュニティコメントで印象的だったのは、AI Visibilityスコアが特に有用と評価されたこと。それと、開発者オーディエンスは特定しにくい。連絡先の鮮度と検証をどう確保してるか、という質問が出てる。これは信頼の問題で、Morsaが常に返答できるとは限らない点は開いたままでいい。

悠真: Morsaに続くのがManyPI。これはMorsaよりさらに包括的な営業側のAI。

葵: 理想の顧客を一文で書くと、ManyPIが見つける。見つけたリードのメールアドレスを検証し、ウォームアップを回しながら自分のインボックスから複数ステップのキャンペーンを送り、返信を一か所に集めて、返信したら自動でタグ付けして次のステップを始める、というのを全部一つのサブスクリプションで。

悠真: ここで面白いのはMCPサーバー。ClaudeやChatGPT、GeminiのようなMCPクライアントから「リードをリストにして」と頼むと、結果は会話のトランスクリプトに落ちるんじゃなくて、実際のテーブルに置かれる。これはAIが生成したものをデータとして扱う、という違い。CRMの統合もHubSpotやSalesforce、Claude、OpenAIと並んでる。

葵: 価格の情報も具体的で、すべてのプランにCRMとパイプライン、統合インボックス、AIエージェント、Webスクレイピング、データ分析、APIとwebhooksが含まれる。2 Product of the Dayの表示もあった。Berlinのマーケティングエージェンシーを探す例で、1284社がマッチ、みたいな。

悠真: コミュニティからは「どのようにリードを見つける? ウェブを検索するのか、Apolloみたいな既存プレイヤーと組むのか。ウェブで見つけたら更新と検証はどう確保する?」という質問。これはMorsaと同じ本質で、連絡先データの鮮度と出所の信頼性。ここはどちらも、返答がまだ確定していない点で似ています。

葵: そして営業が終わった先、つまり顧客に何を見せるかの問題がEmbedful。

悠真: SaaSチームが、既存データに繋いで、数分で顧客向けダッシュボードを構築して埋め込めるもの。PostgreSQL、MySQL、Firebase、Google Analytics、スプレッドシート、APIなど、既存のデータソースに繋ぐ。視覚的に設計して、1つのダッシュボードを作れば、顧客のアカウントIDを対応づけるだけで、各顧客は自分のデータだけを見られる。

葵: セキュリティの面では短命のJWTトークン、特定の顧客としてプレビューする機能、ホスト型だからインフラを運用する必要がない、という説明。Fernanさんの動機は「SaaSチームはデータを持ってる。足りないのは、BIロールアウトや追加インフラや数週間のエンジニアリングなしで、顧客に大事な指標を見せられること」。

悠真: コミュニティコメントで重要なのが、アプリが5か国語対応のとき、ダッシュボードのUIもユーザーの言語に自動で合うのか、英語のままか、という質問。これは実運用で重大な問題で、回答がまだ見えていない。ローカライズは小さい問題に見えて、マルチテナントのダッシュボードでは外せない。

葵: Embedfulは30%オフの3か月のPH30コードと、年間プランで20%オフが用意されてた。価格体系はシンプルで良い。

悠真: ここから3つ目のセクションに移ります。これは全部独立開発者の話で、共通するのは「失われた自由を正気の価格と正直さで取り戻す」という立ち位置。まずYABAI。

葵: YABAIは日本語スラング辞書のアプリで、308語を扱う。教材が扱わない、スラング、ネットスラング、ファン用語。一枚のカードに巨大な日本語タイポが置かれてて、各語に、意味、実例、Vibe check(使ってもいいのか、友達だけなのか、注意が必要か)、文化メモ、来歴がある。

悠真: ここで一番力を入れたのが「正直さ」と、メイカーが言ってる。全語が日本語でリサーチされて書かれ、英語からの機械翻訳ではなく13か国語に翻訳されてる。そして語源が本当に争われてるとき、アプリはきれいな一つの話を選ばず、「誰も同意していない」と書く。yabai自体がその例。

葵: 動機の話が良い。「日本語を何年も勉強した人でも、グループチャットが追えない」という事実から来てる。望まないのは「もう一つの学習アプリ」で、streakもテストもXPもなく、罪悪感で動かさない。スナックのように設計されてて、巨大なタイポ、一枚のカードをスワイプして発見、保存。308語まで進んでいて、オフラインで動作。Google Playで有料、広告なし、登録なし、サブスクリプションなし。

悠真: カード構成は8カテゴリ、各カテゴリから一つずつの8語がエントリーとして挙げられてる。yabai、oshi、kusa、emoi、sorena、mofumofu、taipa、tsundere。端末で読み上げ可能な機能もある、という説明。コミュニティコメントで具体的に質問が出たのは、iOS版があるか、無料か有料か、308という数字はどう決まったのか(完全な「ネイティブコンテンツに追いつける」セットなのか、追加パックを予定したスターターパックなのか)という点。

葵: 308という数字の論理は説明されてない、というのが正直なところ。その問いは未解決のまま残ってます。

悠真: 次の独立開発者の製品がHarbor。これはEvernoteの代替というやつで、Spicerさんの動機が強い。

葵: 自分は10年以上Evernoteを使ってた。スキャンした郵便物、子どもの成績表、会議の録音、15年分のノート。それが売られて、価格がほぼ倍になり、無料プランは50ノートまでに縮んで、自分のデータを出しにくくなった。彼らはEvernoteの最近の500件のUS App Storeレビューを数えて、否定的レビューのうちバグやクラッシュや同期の問題は9%、価格についてが54%。つまり「製品は良くなったが取引が悪くなった」と。Harborはこの「取引」を直すもの。

悠真: その約束を書面にしてるところが特徴。価格は3年間凍結され、その後も年10%までの上限。全プランで完全エクスポートが可能。HTML、Markdown、ENEXで。オープンAPIとCLIとMCPサーバー。支払いをやめても、記憶が消えることはなく、アカウントは読み取り専用になって、依然としてエクスポートできる。

葵: 機能面では、ノートとスキャンとPDFと写真と録音が一か所に。検索は写真やスキャンPDFの内側の文字を読むOCRで、手書きまで。録音は検索可能なトランスクリプトに。ネイティブアプリで、Mac、Windows、iPhone、iPad、Android、Web、CLI。Electronではない。オフラインで動作。Webクリッパー、ゼロ知識暗号化をノートやノートブック単位で。内蔵AIアシスタントはなしで、ChatGPTやClaudeを持ち込んで検索や整理をさせる。Evernoteからの1ステップインポートで、ノートブック、タグ、チェックリスト、添付、Webクリップが揃う。価格は月8.25ドル、年99ドル。

悠真: コミュニティコメントは少ないが鋭い。「Evernoteはエクスポートをほぼ不可能にした。皆さんはそれを直したか? Evernoteの内容をHarborにエクスポートできるか」というやつ。これはHarborの一番の価値提案がまさにそこに向かってるので、実際のインポートの体験が本番環境でどうなるかが一番大事な未知。

葵: そして3つ目がLaunchie。macOS 26 TahoeでLaunchpadが削除され、macOS 27でも戻らなかったことへの回答。

悠真: Nickさんの説明がいい。「Appleの代替、SpotlightのApps viewは全部ソートして、フォルダを作らせない。だから自分が組み立てられるグリッドを失った」と。Launchieはその失われたLaunchpadを再現して、さらに先へ行く。

葵: レイアウトは自分でドラッグして決められ、順番は固定され、フォルダは無制限、無料。Spacesという機能が、仕事用、ゲーム用、デザイン用など、アプリのページを分けて、スワイプで切替。即時検索と、最近使った・よく使うアプリのQuick Access。Proは、壁紙がグリッドの背後でぼやける元のLaunchpadのような見た目、ホットコーナー、非表示のアプリ、ピンチジェスチャーでAppsの代わりにLaunchieを開く。一回の買い切り、サブスクリプションなし。

悠真: Mac App Store、直接ダウンロード、Homebrewで入手可能。評価はMac App Storeで4.6/5、141件。iDownloadBlog、Mac & i、MacGadgetで取り上げられてる。レビューには「Launchpad以上の機能がある。ソートツール内蔵、追加フォルダ、隠しアプリ」といった声が並んでて、コメントがすぐ実装されたという開発の反応の速さも言及されてる。

葵: ここで一番伝えたいのは、Appleの代替が使えない理由と、独立開発者の代替が何を足してるか、その対比。AppleのApps viewは視覚的にブラウズしたい人向けじゃない。Launchieはそこを正確に埋めてる。未知の部分は、macOSの将来バージョンでAppleが同機能を取り込むかどうか。それは不確定。ただ、これら3つの独立開発者製品は、どれも「市場が便利さを捨てた場所を、正気の価格と正直な情報で回復してる」、という共通の立ち位置。

悠真: 4つ目のセクションに移ります。2つの小さな職人的ツール。まずTermphin、次にSmartPause。どちらも小さい摩擦を正確に潰してる。

葵: TermphinはAndroid向けのSSHクライアントで、いわゆる「接続が切れて作業が死ぬ」問題。スマホの画面をロックした、Wi-Fiからモバイルデータに変わった、そうすると長時間のジョブやエディターセッション、AIコーディングエージェントが死ぬ。

悠真: メイカーの説明では、普通はtmuxを入れて設定する、でも全部のサーバーでそれをやるのは面倒、という話。だからTermphinは、SSH経由で小さなRustヘルパーをサーバーにアップロードして、その下でシェルを走らせる。接続が切れてもシェルはサーバーで生きてて、再接続したら同じ画面に戻る。

葵: ここで重要なのは、このヘルパーがTermphin側で自動的にアップロードされる、つまりユーザーはサーバーに何もインストールしなくていい、という点。コミュニティコメントでも「agentはサーバーに自分でインストールするのか、最初の接続で自動的にpushされるのか」という質問が出てて、これはまさに良い問い。説明からすると自動アップロードという読みができるが、明示的な確認はしてない。

悠真: 機能面では、ターミナル描画はネイティブで、Webビューじゃない。htop、vim、フルスクリーンのTUIがデスクトップのように描画される。SFTPブラウザ、SSHキーマネージャ、スニペット、ローカルとリモートのポートフォワーディング、ジャンプホスト(ProxyJumpのような)が含まれてる。14のカラースキーム。鍵は端末内の暗号化されたボールトに保存され、PINか指紋でガードされる。サーバーのホストキーが変わったら止まる。ジャンプホストを通るときは端末間で暗号化され、ジャンプホストはトラフィックを運ぶだけ。

葵: これはただのSSHクライアントを超えてる部分で、AIコーディングエージェントとの相性が良い点。Kilo Code、Claude Code、opencode、OpenAI Codex CLIのようなエージェントの長い実行が、画面をロックしても続く。というのもエージェントのタスクは長く走ることが多いから、接続が切れてもロスがない。

悠真: セキュリティ面で言うと、鍵はデバイスに保存されてアップロードされない。匿名使用の分析は、yesと言ったときだけ。サーバーの指紋を最初の接続で表示して覚えて、変更があったら止まる。すべて端末側で完結してる。

葵: ターミナルレンダラーとサーバーヘルパーの2つはオープンソースで公開されてる。iOSとデスクトップ版が進行中だが、リリース日はない。現在はGoogle Playのみ。無料で、広告なし、アプリ内課金なし。

悠真: 一方、SmartPauseはmacOS用で、もっと小さい問題を解く。

葵: 問題は、Macのメディアキーが「今鳴ってる」アプリじゃなくて、「macOSが記憶してる」アプリに行くこと。YouTubeを観てて再生を止めようとキーを押すと、動画が続いてApple Musicが開く。macOSはメディアキーを自分の"Now Playing"の概念にルーティングしてるが、それがしばしば古く、ときに何もない。

悠真: SmartPauseは、キーを捉えて、Core Audioにどのプロセスが今実際に音を出してるか尋ねて、そこにコマンドを送る。Apple Musicは開いたままにならない。何も鳴ってないときは、最後に止めたものが再開する。

葵: 2つのアプリが鳴ってるときが面白い。シングルプレスで切替:鳴ってるアプリが止まり、もう一方が始まる。ダブルプレスで選択中のアプリを再生/停止。ウィジェットが右上に、何が起きて、次の押下が何をするかを表示する。

悠真: 技術的には、Core Audioの公開プロセスリストを使って、キーが押されたときだけオーディオ検出が走る。アイドル時のコストはゼロ。Accessibilityの許可が一つだけ必要、マイクや画面録画はない。アダプターのないアプリにはキーがシステムに手渡されて戻る、つまり「死んだキー」にならない。Swiftで書かれてて、分析なし、アカウントなし、MITライセンスでソースはGitHubに。

葵: Spotify、Apple Music、VLC、Chrome、Brave、Safariが動作対象。英語とトルコ語。macOS 14.2以降、Apple SiliconとIntel。Brewでインストール可能。無料のままで、Developer IDのnotarizationのためのコーヒー寄付を募ってる。

悠真: コミュニティの反応が少ないのは、比較的ニッチで静かなユーティリティだからでしょう。ただ、この2つ、TermphinとSmartPause、どちらも「どれだけ小さな摩擦か」を正確に計って、それだけを潰す。無駄な機能を足さない。MIT、無償、分析なしというスタンスは共通してる。

葵: 最後のセクションは、最も実験的な話で、独立開発者シリーズの締めとしてぴったり。The 101 Plays Itselfというプロジェクト。

悠真: これは道具というより純粋な実験で、Jay Judahさんという人が作った。スタジオシティのUS-101の南向き車線を捉えるライブのCaltransカメラを、ブラウザで「音楽」として再生する。

葵: 仕組みが面白い。車線に沿って10個のサンプリングパッチが置かれてる。5車線に2個ずつ。ただしこれは矩形じゃなくて、それぞれが自分の車線のスライスで、距離に応じて傾いたり狭くなったりする。つまり車線の幾何学そのまま。

悠真: ブラウザはそのパッチを毎秒15回読んで、「道路が道路じゃなくなった」箇所を監視する。それが車で、それが音符。技術的には、2つのパッチを車が踏む間隔が速度を教える。これは本物のスピードトラップで、13.4メートルの距離。パッチを踏んでいる時間が車長を教えるから、トラックと乗用車を区別して違う音色を与える。

葵: だから聞こえるのは「今この瞬間の渋滞そのもの」。午後1時40分に聞けば賑やかで、早朝3時に聞けばほぼ静かなフリーウェイ。timestampが実際にカメラに焼き付いてるのが本物さの証拠。サーバーは使わず、検出と合成はすべてブラウザ内。レーンの幾何学は、同じカメラの以前の録像からオフラインで解いたもの。

悠真: カメラが落ちたときの設計も良い。Caltransの動画網全体が届かないときは「何もできず待つしかない」と表示し、代わりに3分間の録音を再生できる。あと複数のパッドをタップしてスタックできて、16のボイス、つまり同時再生が可能。

葵: この作品は外部でも評価されてて、kottke.orgが取り上げて「A musical instrument」と紹介した。NBC4ロサンゼルスのThe News Zoneでもセグメントがあって、ローカルLAフリーウェイ、公開Caltransカメラ、リアルタイムの交通がスコアを作ってる、という枠組みで。The Driveも「Strangely beautiful」と表現してる。

悠真: 聞いてる統計も表示されてて、ノート数、時速の速度、1分あたりの数、トラック数、車線数、聞いてる時間。これは自動車の速度やトラックを見分けてることを確認できる。

葵: 今日のローンチから全体を振り返ると、4つの軸がありました。AIが実行して人が承認する(Mycel、Epismo、Minicart)。開発者を見つけられるか(Morsa Signals、ManyPI、Embedful)。自分用の自由を取り戻す(YABAI、Harbor、Launchie)。小さな摩擦を潰す(Termphin、SmartPause)。そして最後の実験(101)。

悠真: どれも共通するのは、メイカーが自ら語ってる点で、主張は主張として見せてて、検証結果として提示してない。だから「この価格でこの機能がある」という利用可能性の情報は信頼できるけど、実際の効果や運用の感触はまだ実証が進んでない。コミュニティコメントも、賛美より鋭い質問が多い。連絡先データの鮮度、修正ループの横串効果、レビューの粒度、ローカライズの対応。これらの質問が答えられてこそ、ローンチが本物になる。

葵: そういう意味では、今日のローンチは「未完の正直さ」が多い。でも、その未完さは私たちのリスナーにとっての取引材料になります。明日は別のローンチセットでまたお会いしましょう。今日も聞いてくれてありがとう。

悠真: ありがとうございました。また明日。