1026 | AIが現場を書き換える週：エージェント、可視化、そして日常の道具

葵: こんにちは、「24時間のプロダクトハントから選ぶ今日のローンチ便り」の時間です。葵です。

悠真: 悠真です。今日は、ローカルでAIを動かす話から始まって、Gitのワークフロー、チームで同じ現実を見るための道具、数字の監査、人とAIの共有ワークスペース、そしてリスナー向けの道具、音楽プロモーション、最後はちょっと変わった小さな道具まで、今日並んだローンチの中から特に筋が良いと思ったものを選んで並べていきます。

葵: 選び方としてはですね、「誰のどんな問題を、既存の選択肢とどう変える解決で潰すのか」がはっきりしていて、しかも機能や価格が具体的に見えるものを優先しました。あと作り手の説明はあくまで本人の主張として扱う、という約束で今日も進めます。

悠真: ではさっそく、一番重い話から。ローカルAIとエージェント用インフラです。まずはLlamaという、llama.cppチームとHugging Faceが作ったWindows 11向けアプリから。

葵: これは、ローカルでLLMを動かすときの面倒くささを丸ごと引き受けてくれるやつですね。システムトレイに常駐していて、Hugging Faceからモデルをワンクリックでダウンロードできる。しかも自分のPCに合うモデルを推薦してくれる。チャットはAlt+Spaceでどこからでも開ける、という。

悠真: で、個人的に一番効くと思ったのがAPIの話です。localhostの9931番ポートでOpenAI互換のAPIが出る。つまりコーディングエージェントだろうがエディタだろうがスクリプトだろうが、OpenAIに向けるコードのベースURLを変えるだけで全部このローカルサーバーを指せる。APIキーも使用量の請求もなし。

葵: そこに加えて、モデルはHugging Faceのキャッシュに一つだけ置けば済むという設計。これが地味に大きくてね。コミュニティでも「アプリごとにそれぞれ20GBのモデルをダウンロードする地獄がなくなる」というコメントがあって、それがまさにこの機能の価値を言語化してます。

悠真: 使ってないときは何もロードしないで、何かが要求したらモデルをロードして、5分アイドルでアンロードするというのもいいですね。ディスクとメモリを食うローカルAIの悪評を、設計で返している感じ。対応はMacとWindowsで、Mac版は1MBのダウンロード、無料でオープンソース、オフラインで動く。

葵: ただし認識しておくべき落とし穴はあります。モデルの推薦や設定の自動調整は「自分のマシンに合うようにllama.cppの仕組みに基づいて設定する」という主張であって、すべての環境で完璧に動く保証はない。あとParity的には、クラウドモデルの性能とローカルモデルの間には今も差があるので、何をローカルで賄って何をクラウドに残すかは結局ユーザーの判断です。

悠真: その判断の材料として、イベント参加者からの声もありました。プライバシー重視のチームやオフラインの推論ワークフローには向いている、クラウドAPIへの依存が消える、という評価ですね。これはあくまでその人の見立てですけど。

葵: で、次のMoli by Lexmountは、まったく違う層を狙ったローカル寄りインフラです。今ののは「人とそのアプリ」のためのサーバーだったんですが、Moliは「AIエージェントがウェブを見るためのブラウザ」そのものをゼロから作ったエンジン。

悠真: ここでの問題設定はかなり具体的です。エージェントのワークフローを組んだことがある人なら分かるんですけど、何千もヘッドレスChromeを回すとリソースコストがじわじわ膨らむ。ローンチ時のコメントでも「ヘッドレスブラウザを大量に回すのが一番静かに高くつく部分」と書かれていて。

葵: Moliはその解として、Chrome比でおよそ5倍速いコールドスタート、アイドル時のメモリは約7分の1、というベンチマークを主張しています。ただここは開発者本人が提示した数値で、私たちが検証したわけではない。そして彼ら自身も「スライドの主張ではなく、実際に速度とコストを比べてみてほしい」と言ってるのが誠実なところです。

悠真: 展開の仕方も面白い。Moliというエンジンはオープンソースで、その上にLexmountというクラウドプラットフォームが乗っている。クラウド側ではPlaywrightやCDP、拡張、プロキシ、セッションリプレイに対応していて、100ブラウザ時間と25同時セッションで月12ドルという価格を出しています。

葵: 技術的なこだわりで言うと、開発者の一人が書いていたのは、ヘッドレスで軽量化してもブラウザのセキュリティを犠牲にしない、ということ。同一オリジン制限、iframeサンドボックス、CSP、CORS、サブリソース完全性などをちゃんと実装していると。人がブラウズするときと同じ防御をエージェントにも課す、という思想です。

悠真: 使い勝手の面では、プラットフォームにはWeb Search、Web Fetch、Cloud Browser、Agentという4つのプロダクトが並んでいて、Playgroundで認証や挙動をコードを書く前に確認できる。SDKで実運用に移る、という流れです。

葵: ただ、オープンな質問も残ります。コミュニティから「Moliは動的コンテンツをどう扱うのか」「ログイン済みセッションを走行間で保持するのか、毎回クリーンプロファイルなのか」「現代のWeb標準に対応しているのか」といった具体的な問いが出ていて、これらはローンチ当日の段階では明確な答えが出ていません。エンジンを新規に作ると互換性の問題がつきまとうので、ここは今後の観察ポイントです。

悠真: あと開発者の一人が語っていた展望も面白いです。クラウドのブラウザから、ユーザーの明示的な許可を前提に、ローカルのネットワーク経由で社内ポータルやVPNの内側にあるサイトに到達する仕組みが既にあって、そこから「他にローカル側が何を提供できるか」を探っている、と。ファイルやカメラまで含めて、クラウドとローカルの住み分けをどう設計するか、という問いに繋がっています。

葵: そうそう、エージェントが複数で動くと「みんな同じ現実を見る」問題がたちまち出てくるんですよね。だから次の話への繋ぎも自然で。Gitのワークフローの話に行きましょう。git-flow-next、Towerチームが作ったやつです。

悠真: これは、2010年以来の定番だったgit-flowというブランチモデルを、Goでゼロから書き直したものです。元のgit-flowとgitflow-avhの両プロジェクトが discontinued になったので、その後継としての位置づけ。しかもgit-flowの考案者であるVincent Driessen本人の承認を得ている、と紹介しています。既存のgit-flow環境との互換性もある、と主張しています。

葵: そしてバージョン2.1の目玉はworktreeです。featureを --worktree オプションで独立したディレクトリで開始でき、stashしてブランチを切り替える作業がなくなる。git flow feature checkout でworktree間を移動できて、featureをfinishするとworktreeが掃除される。

悠真: ここが今日のテーマとつながるポイントでね。彼らが書いているのは「AI時代には複数のエージェントを並行して走らせるのが標準になっていく」ということです。Claude CodeでもCodexでも、feature開始時にworktreeをデフォルトにすれば、エージェントごとに独立したディレクトリが与えられて、お互いの足を踏まずに並行作業できる。

葵: 昨日話したLlamaの「一つのローカルサーバーをみんなで共有」とは逆の発想ですね。コンピューティング資源は共有しつつ、編集対象のディレクトリは分離する。エージェントの並行性を安全にする工夫の両極が、同じ日のローンチに現れています。

悠真: 補足機能としては、親ブランチと子ブランチの間で変更を自動検出してマージするブランチ依存トラッキング、上流下流のマージ戦略を設定できるカスタマイズ、feature/hotfixの制限をなくして自分のルールでトピックブランチを定義できる統一実装。プリセットとしてGitflow、GitHub Flow、GitLab Flow、スクラッチから作るカスタムが用意されています。無料でオープンソース、brewで入ります。

葵: 次は、開発チームの中だけでなく会社全体が「同じ現実を見る」ための道具です。ここで最初の本命、Specsight。

悠真: Specsightはコードの変更を「生きた製品マップ」に変えて、機能の知識と明確なリリース情報を提供するやつです。作り手のOlaさんの説明が自白調でわかりやすいんですが、彼はあらゆるスタートアップで「エンジニアが社内の窓口」になっていた、皆が同じ3つの質問を持ってくる、これはどう動くの、何が変わった、これは仕様なの。答えはいつもコードの中にあって、しかしそれは会社の大半の人が読めない言語だった、と。

葵: 「翻訳レイヤーを何年も務めていたが、その不合理に慣れなかった」という言い方ですね。そして今、みんながAIでビルドしていて、製品は毎日変わって、誰も実際に何がリリースされたのか追いきれない。でも売ってサポートする自分たちの製品を理解する必要はある、という問題設定。

悠真: 解決としてSpecsightは、GitHubかGitLabに接続してリポジトリとブランチを選ぶだけで、コードから直接「どんな機能があるか、どう振る舞うか、どうつながっているか、リリースごとに何が変わったか」を平易な製品言語で示します。リリースノートが「何が新しくなったか」しか教えないのに対して、Specsightは製品全体の生きた理解を保つ、と主張しています。

葵: 具体的な機能を見ると、プロダクトチェンジログでは「ファイルがまとめて10個アップロードできるようになった」「サイズ上限が20MBになった」「保存ドラフトボタンがなくなった」といった形で何が増え、変わり、消えたかを時間順に示す。プロダクトマップはユーザージャーニーをクリックなしで辿れる。プロダクトスペックは実際のコードベースからドキュメント化されて、変化に合わせて更新される。

悠真: さらに、製品について質問すると数秒で答えてくれる「プロダクトアンサー」、週次のチームアップデートの自動生成、リリースノートのドラフト機能。ワークフローの変化としては「エンジニアリングに確認します」が数秒の回答になる、という表現がされています。

葵: 設定は数分で、リポジトリ接続から最初のプロダクトマップまでほとんどのプロジェクトが1時間以内と主張しています。読み取り専用アクセスで、Specsight自身をSpecsightが追跡しているライブデモもある。価格は組織あたりで、Standardが月150ユーロ、3プロジェクト、50メンバー、月200回の同期。最初の3ヶ月が半額のプロダクトハント特典も。

悠真: 限界としては、コードからの自動生成なので、意図とコードの間に乖離がある場合や、設定や実装意図の背景がコードから読めない部分には限界があるはずです。コミュニティからは、「半分のサポートチケットが『何か変わりましたか』で始まって、答えはいつも『エンジニアリングに確認します』だから、サポート側が刺さった」という声が出ていて、これは attributed な体験として値します。ただし同時に「feature flagsやconfigだけにある変更も拾うのか、リポジトリにあるものだけなのか」という鋭い質問も出ていて、ここは明確な答えが出ていません。

葵: 同じ「正確な情報を速く全員に」という文脈で、次はOpenstatusのインシデント管理です。

悠真: Openstatusは、アップタイムモニターとステータスページをやっているオープンソースのやつですが、今回インシデント管理をローンチしました。タグラインがもうそれを語っていて、「ステータスページは嘘だから、上流に行く必要があった」という笑える言い方です。

葵: コミュニティの反応もこれに刺さっていて、「ステータスページは緑のまま、Slackチャンネルは炎上」という声がいくつも出ています。これはみんなが本気で経験していることなんですよ。だから、この主張が飛び抜けて信じられている。ただ、インシデントをSlackから宣言したときにステータスページが自動更新されるのか、誰かが顧客向けの文言を承認するのか、という質問は出ていて、ここも明確な回答は当日確認できていません。

悠真: 機能としては、Slackから /openstatus incident declare コマンドでタイトルと重大度を指定して承認すると、インシデントが発生して、インシデント専用のSlackチャンネルが自動で開かれ、作業者が招待される。

葵: チャンネルのTOPにはインシデントカードがピン留めされていて、重大度とステータスが見える。そしてSlackの任意のメッセージに📌リアクションをつけると、それがタイムラインのノートになる、というのが美しい設計です。最初の顧客向けステータスレポートは自動でドラフトされ、影響コンポーネントと問題の開始時刻が入って、ワンクリックで公開できる。

悠真: モニターが落ちたときは、そのダウンタイム行からインシデントを宣言できて、開始時刻は影響の始まった時点から数えられる。つまり「誰かが宣言するまでの遅れ」でインシデント時間が歪まない。ステータスが変化するたびに、ノートや公開更新が全部タイムスタンプ付きで記録されるから、ポストモーテムは記憶からではなく記録から組み立てられる。

葵: そして、内部と公開を混ぜない、という明確な線引きです。チーム側は重大度と作業者とメモで作業し、顧客側は自分の言葉で書かれたステータスレポートを読む。二つはリンクされていて混ざらない。静かになったインシデントにはリマインダーもあり、critical は1時間、major は4時間、minor は1日。

悠真: サポートとしては、Starterが14日間無料トライアル、有料プランは月30ドルから。オープンソースなので自ホストも選択肢です。

葵: ここで番外編ですが、数字の透明性というテーマでつなげるのがMRRauditです。ChartMogulチームが作りました。

悠真: 問題はシンプルです。StripeのMRRとChartMogulのMRRが合わない。なぜ合わないのか、どちらの数字が正しいのか、誰が原因かを特定するのに、ChartMogulのチームは2014年以来数千件の問い合わせやサポートチケットを通じて手作業で調査してきた、と説明しています。それで「ツールを作るべきだ」と何度も思って、ついに作った、と。

葵: MRRauditはStripeとChartMogulを顧客ごとに比べて、MRRの差分を説明します。消し込みで言えば、たとえば「Northwind Labs」という例示された顧客では、メーター課金の使用収益がStripeでは非経常収益に分類され、ChartMogulではサブスクリプション収益に含まれているから差が出る、と説明が表示され、それが実際の請求書やサブスクリプションイベントにリンクされる。

悠真: 差分が大きくなる原因としては、自動生成された定期請求書を無効化して一回払いの請求書に置き換えると、StripeのMRRは変わらないのにChartMogulは$0になる、というケース。支払いが止まってもサブスクリプションが解約されていなければ、実際の最終支払いから何ヶ月経ってもフルMRRが計上され続けるというケース。返金のMRRへの反映設定。定期的な割引のMRRへの反映方法。課金モデルの使用収益分類。StripeとChartMogulでサブスクリプションステータスが違うと認識されるケース。

葵: 特徴的なのは「あなたが選ぶ」設計です。たとえば使用収益を経常として扱うかどうかは、Stripeの解釈とChartMogulの解釈のどちらを採用するかをユーザーが選択できるようになっています。どちらが正しいかを決めるのはビジネス側で、ツールは両方の数値を説明して選ばせる、という。

悠真: 読み取り専用アクセスで、ChartMogulのアカウントがなくてもStripeだけの監査で使えます。コミュニティからの質問も実運用の細部に迫っていて、「支払い失敗が数日後に回収される場合、その間顧客はMRRから外れるのか、それとも自分でそのルールを選べるのか」「更新請求書が1時間ほどドラフトのままになってから課金されるんだけど、それを通常の更新と数えられるのか、失敗と誤読されるのか」といった具体的な聞き方がされていて、これらはまだ答えが出ていない。

葵: 次も数字と信頼の文脈ですが、実はドキュメント共有の話。PapermarkのData Rooms 2.0です。

悠真: これは、起業家のIuliiaとMarcという二人の共同創業者がローンチしています。3年前に始めて、80,000人以上のユーザーに使われていると言っていて、繰り返し聞かれる問題が4つあったと。データルームのセットアップが数日から数週間かかる。実際にデッキを読んだか分からない。ベンダーのロゴが付く。AIエージェントが関与できない。

葵: Data Rooms 2.0の回答として、60秒以内でセットアップ、ページ単位の分析と完全な監査ログ、完全なホワイトラベリングで自分のブランドとドメイン、そしてAPI、CLI、MCPサーバーでClaude、Cursor、ChatGPTにルームを作らせることができる、と主張しています。

悠真: Iuliiaの好きな部分はエージェントで、「Project AtlasのためのバイサイドM&Aルーム」と頼むと、フォルダとパーミッションと共有リンクが返ってくる、という。

葵: コミュニティの反応では、実際にファンドレイズで使って愛用しているという声がある一方で、「Claudeに頼んでM&Aルームが返ってくるのはMCPのデモとして分かりやすい。でも、エージェント経由で誰がパーミッションを変更できるのか？外部のアドバイザーに全アクセスを許可させようとした場合、実行されるのか人間の承認待ちなのか？」という鋭い質問が出ています。これはエージェントに権限を渡すときの問題で、ここは明確な回答がまだ出ていません。

悠真: 技術仕様としては、SOC2 Type II、ISO 27001、GDPR、CCPA、HIPAAの認定を宣伝していて、38以上のデータセンター、AES-256、自己ホスト可能、ページ単位の分析、Q&Aモジュール、動的ウォーターマーク、ファイルレベルのアクセス制御、NDA同意の前に見るを求めるなど、データルームとしてのフルスタックを並べています。

葵: さて、監査とパーミッションの話が出てきたので、そのまま「人とAIの共有ワークスペース」の話に進めます。AgentGrid.ioです。

悠真: これはAnimaという会社が作ったもので、コンセプトは「Google Drive for humans, Git for agents」。人間のマルチプレイヤー編集とエージェントのGit的バージョン管理のインターフェースを一つのワークスペースに合わせる。

葵: 具体的には、ドキュメント、レポート、スライド、デザイン、そしてHTML/Reactアプリまでもが一つの「成果物」タイプとして扱われる。Claudeにレポートを作らせて、ChatGPTに改善させて、Grok Botに視覚を作らせて、チームメイトが手で編集する、という複数エージェントと人間の協働が同じ成果物の上でできる。

悠真: 権限の粒度がエージェント単位で設定できる、というのがここでの価値です。読み取り、書き込み、変更、公開をエージェントごとに設定できる。これは前のセクションで話したPapermarkのエージェントパーミッションの問題と同じテーマなんです。

葵: 一つの成果物に永続的なリンクと構造化されたストレージを持たせて、チャットの中に埋もれさせるのをやめる、というのが価値として言われています。「v26 final FINAL.docx」という例が、実際にみんなが経験したものとしてコミュニティから刺さっていました。誰がどのバージョンを使ったか分からなくなる、という問題。

悠真: だから、異なるエージェントが同じ成果物を触るときに、誰が何を変えたのか履歴が追える。身元が提案や承認や行動に付随する。復元もできる。

葵: 次は、方向転換して、リスナー向けのAIメディア道具です。Yourcast 2.0です。

悠真: YourcastはTelegramのポッドキャストBotです。ショーを検索してタップで購読して、新しいエピソードがオーディオでチャットに届く。Konstantinという作り手が、ポッドキャストを聞きながらTelegramに住んでいるので、新しいエピソードがTelegramに届くようにしたかった、と説明しています。

葵: この作品の特徴的な点は、4年前にプロダクトハントでその日の10位になった後、ほとんど独りで動いていたのに、過去7週間で、85件のマージされたPRと約170コミット、それをほとんどLLMで書いた、という数字を出していることです。それと対比して、それ以前の5年間は約55コミットだった。

悠真: 2.0の新機能としては、AI要約がタイムスタンプ付きで付いて、時刻をタップするとオーディオがそこにジャンプする。その後エピソードについて質問できる。Apple Podcastsのリンクを貼って購読したり、OPMLで他のアプリから移行できたり。

葵: それから、フィードが自ら修復する機能。壊れたり移動したりしたフィードが毎日再チェックされて、新しいアドレスが見つかる。これは、多くの独立ポッドキャストのフィードが消えて聞けなくなるという現実的な問題への対策です。2GBまでのエピソードに対応して、ダウンロードが中断から再開できる。Telegram Starsでの課金で、無料で週10エピソード、Bronzeは1ドルで自動配信、Relayは5ドルで月30時間の要約。

悠真: コミュニティからの意見も実用的です。ある人は、「最近ポッドキャストのゲストとして参加するので、収録前にホストのエピソードをいくつか聞いて感触をつかむ。エピソードについて質問できる機能は実際に時間を節約する」と言っていて、そして「複数エピソードを横断して質問できるのか、例えばこのホストはゲストにどういう質問をする人なのか」と聞いています。これは回答がまだない。

葵: 同じテーマの2つ目は、How It Spreadです。

悠真: これは、1600件以上のバズった映画、プロダクト、ミーム、キャンペーンのライブラリで、初投稿からピークまでを追跡するやつです。作り手は「バズるコンテンツのためのMobbinが欲しかった」と言っています。

葵: データとして、Obsessionという映画では、TIFFのミッドナイトマッドネスで予告なしに上映され、Varietyが予告前に監督を特集して、DeadlineがFocus Featuresが1500万ドル以上で買い取り交渉していると報じた、といった時系列イベントが並ぶ。8つのプラットフォーム、9つのソース付き数字、23のソース、という集計が示されています。

悠真: 他にも、DoggfaceのOcean Sprayビデオで15Bインプレッション、Dubai chocolateで120Mビュー、Labubuで20.5億ドルの売上、というような有名な事例が揃っています。ブラウジングは無料、ProはPATIENTZEROというコードで初年度60%オフ、という紹介でした。

葵: ここから制作側のAI活用に移ります。Clips by Plasticです。

悠真: これは、ミュージシャンKai Williamsという人が自分のアルバムを宣伝している間に作ったやつです。問題設定はこうです。曲の広告は曲の複数のパートをテストするのが一番効くんですが、同じ曲を15通りにカットするのをビデオエディタでやると丸1晩かかる。だから普通は2つ作って推測で判断する。Clipsはその部分を自動化する。

葵: 機能としては、完成した楽曲をドロップすると、テンポと各パート(Verse、Pre、Chorus、Bridge)を検出して、各パートごとに、ビートに合わせてカットされた、歌詞が同期された縦型のリリックビデオを作る。自分の映像や写真を使って、レイアウトと54種類のエフェクトを選び、一括でエクスポートする。Ads Managerに直接入るようにファイル名が付いている。

悠真: そして提案されるワークフローが面白いです。すべてのパートを一週間運用して、費用対効果で勝者を選ぶ。デザインの例では、Verse 1が1回あたり$0.36、Preが$0.46、Chorusが$0.63、Verse 2が$0.21で勝者、Bridgeが$0.54、というふうに、コーラスではなくVerse 2が勝った、という見せ方をしています。これはデモ上のデータなので実績ではないですが、概念の説明としてはわかりやすい。

葵: それから、「無題の楽曲がMacから出ていかない」という点も押さえるべきで、ローカルでオフライン動作が保証されています。これはアーティストにとってかなり重要です。まだリリースしていない楽曲をクラウドにアップロードするのは、多くのミュージシャンにとってリスクです。

悠真: 価格は99ドルの買い切り、サブスクリプションなし、クレジットの上限もなし。無料トライアルではエクスポートにClipsのタグが付く。レーベルやスタジオ向けに299ドルのプランがあって、そちらは10台までMacを使えて、他のアーティストのための作業をカバーする。ライセンスのソフトウェアリクエストの比較表では、CapCutなどでできる一回編集とは用途が違い、「15通りのほぼ同じカットを誰も手作業でやりたくないときに使う」と説明しています。

葵: 最後のセクションは、暮らしに寄り添う小さなAI道具です。pawlとBadgeyという2つの小さなアプリで締めます。

悠真: 最初はpawl。Macのメニューバーに常駐するフォーカスタイマーで、猫の肉球を引っ張るとタイマーが始まるというユニークな入力です。作り手のMayさんは、「始めるのを小さくしてから、作業中は邪魔をしない」というデザイン方針を説明しています。フォーカス時間、ブレイク時間、フォーカス間隔を肉球を引っ張ることで調整できる。8匹の猫の肉球から選べて、テーマも変えられる。

葵: コミュニティからの反応が面白いです。実際にフォーカスに困っている人から、「メニューバーのタイマーを使っているけど、音を消して打ち続けてしまう。ブレイクモードは本当に止めてくれるのか、それともただ鳴るだけなのか」「肉球を引っ張るのはフォーカスとブレイク両方を一つの操作で始めるのか」と聞いています。そして別の人は「ブレイクが実際に止めてくれないなら使わない」と笑いながら言っています。

悠真: アクセシビリティの面では、聴覚障害を持つユーザーから、「終了前の静かな通知が thoughtful だ」というコメントが出ています。これは純粋に attributed な声として価値があって、動物に似せた可愛さだけでなく、パターンの多様性に配慮したデザインが評価されているということです。

葵: 価格は9.99ドルの買い切り、サブスクリプションなし。macOS 14以降が必要。学生はメール認証で半額。直接ビルドは約7MBと小さい。まあ、少なくとも、肉球を引っ張ってタイマーが始まるという入力が、始めることへの抵抗を減らすという主張は実際のレビューからも裏付けられている、という声はありました。

悠真: そしてBadgey。これは、iPhoneを名札に変えるというアイデアです。作り手はMarco Lüthiさんで、小さなiPhoneアプリを一人で作っている人です。

葵: ランヤードにクリップしてiPhoneを上下逆にすると、名札が回って会う人に文字が見える向きになり、歩くと少し揺れます。胸ポケットに上から差し込むと、名前がポケットの縁の上に見えるように帯状に縮む。

悠真: ポケットチェックでは、上下逆になったときに数秒間フロントカメラを使って、デバイス上の小さなモデルが判定し、フレームは保存しない、と説明しています。複数の名札を作れて、ワーク、カンファレンス、ミートアップなどのそれぞれに使える。QRコードで自分のリンクをシェアでき、Classic、Office、Event、Minimal、Liveの5つのデザインがある。Liveは動くやつです。

葵: 無料では1つの名札、Proは買い切り。コミュニティからは「カンファレンスでいい会話のきっかけになりそう」という声と、「物理的にどう見えるか写真やビデオが欲しい」「カンファレンス一日中画面が付いていたらバッテリーはどうなるのか」「オートロックを無効にするのか」といった実用的な質問が出ています。バッテリーの話は、名札アプリが実際に動くときの重要な懸念で、まだ回答が出ていません。

悠真: 今日のまとめとしては、一見ばらばらに見えるこれらのローンチは、実は「正確な情報を速く全員に届ける」という共通の問いでつながっています。LlamaとMoliはAIを動かす基盤を統一しようとして、git-flow-nextはエージェントが並行作業するときの現実をどう分けるか、SpecsightとOpenstatusはチームが同じ現実を見るための道具、MRRauditとPapermarkは数字とドキュメントの信頼、AgentGridは人とAIが成果物を共有する場、YourcastとHow It Spreadは情報の消費と分析、Clipsは制作、そしてpawlとBadgeyは日常の小さな瞬間。

葵: 共通して言えるのは、エージェントが並行して動くようになったことで、「誰が何を見て、何を変え、何を承認するのか」を明示的に管理する道具が急速に充実していることです。そして、エージェントに権限を渡すときの人間の承認フローは、まだ多くのローンチで未解決の課題として残っています。

悠真: 今日はこのへんで。次回も最新のローンチから選んでお届けします。お聞きいただきありがとうございました。

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