1022 | 今週のAIツール速報:エージェントから日常まで

葵: こんにちは、ポッドキャストへようこそ。葵です。

悠真: 悠真です。今日もAIプロダクトの話をさせてください。今日の話題は実は一本の線でつながっていて、「AIエージェントがどこで動いて、どこまで実務に入り込んでいるのか」という話なんです。

葵: そう。エージェントの実行コストが下がって、速くなって、複数で協調して、しかも広告費や顧客対応みたいな実際のお金と人のやり取りに触れるようになってる。最後はMacのデスクトップにまで戻ってくる。今日はその流れで話していきますね。

悠真: で、いつもの注意書きをひとつ。今日話すのは全部、各製品が出した情報そのままで、開発者の説明はあくまで「そう主張している」という扱い。検証済みの結果じゃないこと、忘れないで聞いてください。

葵: じゃあ最初から。まず根本のところ、エージェントを長く動かすときの最大の壁って何だと思う?やっぱりコストと速度なんだよね。今日それを直接殴りに来たふたつがある。

悠真: ひとつはNotion Auto。これ、エージェントを最長24時間動かせるって言ってる。24時間って、人間が付きっきりで見てられない時間帯も含めて仕事が続くってことよね。

葵: うん。で、二つ目の見どころがAutoルーターっていう仕組みで、性能はOpus 5.5に近い水準なのに、コストは約90%安いって主張してる。つまり「安い小さいモデルに振り分けて、できるだけ高いモデルを節約する」っていう考え方を自動化してるわけ。

悠真: 90%安いって数字はすごいけど、ここで冷静に言うと、「Opus 5.5に近い」の基準が何なのか、どのベンチマークで測ったのか、それが独立した第三者の検証かどうかは分からない。数字が出やすいものは疑ってかかるのが正しい態度だと思う。

葵: 加えて新しいクレジット制も発表されてる。使い方が変わるのは確かそうだけど、詳しい価格の中身はまだ見えてないね。でもここで方向性としては、エージェントを24時間動かす世界観を見せることで「人間が常に監視しない運用」を前提にしようとしてるのが面白い。

悠真: 一方でもっと根本を突いてくるのがMouse-1。これは「モデル」って言っても、文章を書くためじゃなくて、エージェントが意思決定をするための決定モデルなんだよね。

葵: これが派手な数字を出してる。GPT-6 Solと比べて163倍安くて、65倍速い。で、約100ミリ秒で確率を返す。

悠真: 100ミリ秒で確率を返す、ってのがポイントで、エージェントが次のアクションを決めるとき、いちいち大きな言語モデルに考えさせる必要がなくて、「この状態なら、Aを取る確率が何%」を超高速で出せるようになるってこと。

葵: そう。エージェントの処理のほとんどって、実は「次どうする?」っていう決定の連続なわけで。そこを専用モデルに置き換えられるなら、全体の速度とコストが一気に変わる可能性はある。ただ、Notion Autoの話と同じで、品質が実際どれだけ保たれるのかは未知数。決定の精度が落ちたら、安く速くても意味がないからね。

悠真: 163倍っていう比較対象がGPT-6 Solという特定のモデル指定なのも、素直に受け取る前に、「その設定条件下で」という但し書きがつくものだとは思う。

葵: でね、今日の流れの合間で言うと、この「安く速く動くエージェント」の周りの環境も整ってきてる。例えばSuperCMOなんてのは、オープンソースのスキルで、ClaudeとかCursorとかCodexをAIのCMOに変えてしまう。UGC風の広告やビデオや写真を作る能力を載せるわけ。

悠真: Apache-2.0ライセンスだから、誰でも持ってこれて、自分のエージェントに「マーケティング担当」の能力を加えられる。エージェントがコスト効率化される時代に、「そのエージェントに何をさせるか」をスキルとして配る、っていう構図が面白い。

葵: もうひとつ、小さいけど地味に効くのがilha。Macのアプリで、Claude Code、Codex、Grok Buildの使用上限をMacのノッチのところに表示してくれる。しかも上限に達する前に自動でアカウントを切り替えてくれる。

悠真: つまり「24時間動かしたいエージェントが、枠を使い切って止まる」っていう事故を防ぐツール。長時間実行の話と直結するよね。本体が安く速くなっても、停止する時間が長いと台無しだから。

葵: そういう小さい道具が増えてるのは、実際にエージェントを動かす人が増えてる証拠なんだと思う。じゃあ次。速く安くなったエージェント、複数で動くようになったら、次の問題は当然「どうやって連携するか」。

悠真: ここでBAND。これはコードエージェント同士が協力するための仕組みで、Claude Code、Codex、Copilot、OpenCodeみたいな、普段は独立して動いてるエージェント同士が、共有ルームでタスクを調整できる。

葵: 複数のエージェントを同時に動かしてると、お互い何をやってるか分からなくて、同じ仕事を二重にやったり、片方の変更がもう片方を壊したりする。それを共有の部屋で調整できるって発想。

悠真: で、もうひとつはNimbalyst Wiki。これはローカルのプラグインで、Claude CodeとかCodexみたいなエージェントが動く過程を、markdownのwikiとして記録していく。何を決めて、何がまだ未解決か、を残す。

葵: このふたつ、実は同じ課題の違う面を解いてるんだよね。BANDは「今この瞬間の協調」を扱ってて、Nimbalyst Wikiは「過去の判断と未解決事項の蓄積」を扱ってる。

悠真: 大規模チームで実用になるかはまだ分からないけど、人間のチームでも「誰が何を決めたか」の記録がないと混乱するわけで、エージェントのチームならもっと顕著に必要になるはず。markdownで残るってのが、あとから人間も読める形なのが良い。

葵: で、協調と記録が整ってきたら、次は自然に「エージェントを外の世界につなぐ」話になる。ここで中心的な規格になってきてるのがMCP。

悠真: MCP、ミドルウェアが何種類も出てくるんだけど、まずFlyweil。これは広告用のバーチャルカードを発行するサービスで、カードごとに支出上限が設定できて、さらに広告クレジットも出せる。

葵: で、押さえるべきは、MCP経由でコスト監査をAIエージェントに提供してる点。つまりエージェントが「今日広告にいくら使ったか」をリアルタイムで監査できる。

悠真: これは結構本質的な話で、エージェントに広告運用を任せたいなら、支出をどう統制するかがまず必要になる。エージェントが暴走して予算を溶かす、っていうのが一番怖いシナリオで、カード単位の上限と、エージェントからの監査、っていう組み合わせは安全側の設計として納得感がある。

葵: もうひとつの主役はIntelli。これはChatGPTのディレクトリにプラグインとして入っていて、ClaudeにはMCPでつながる。そして89個のツールを提供してて、対象はWhatsApp、Instagram、サイトのチャット。

悠真: 89っていう数自体より、面白いのは「事前確認付き」ってところ。エージェントがお客様への返信を送る前に、人間がそれを確認して承認するっていう流れになってる。

葵: 顧客対応って、いちばん誤ったらまずい領域で。エージェントが自由に返信してたらブランドが溶ける。だから「自動化するが、送信前は人間が確認する」っていう妥協点を製品として標準化してるのが実用っぽい。

悠真: 同じ方向で、Needleっていうのもあって。これはアウトバウンドセールスをエージェント化するもので、MCPネイティブで設計されてる。リードの生成、エンリッチメント、LinkedInやInstagramやメールへのメッセージ送信まで、一連をエージェントがやる。

葵: つまりFlyweilが「お金を出す側」を整備したとすると、Needleは「顧客を獲得する側」をエージェント化してる。広告と営業の両方がMCPでエージェントに渡せるようになってきた、っていう構図。

悠真: その流れでもうひとつ、Blooio。これはApple Messages for Businessのプロバイダーで、APIが統一されてて、Apple Payもフォームも使えて、RCS、SMS、WhatsAppのサポートも含んでる。

葵: 顧客接点のチャネルをひとつのAPIに束ねる、っていうのは、Needleみたいなエージェントが動くための土台になる。チャネルごとに違うAPIを叩くのはエージェントには重いからね。

悠真: ここまで来ると、権限と誤操作のリスク管理がどんどん重くなるんだけど、その次の話題はまさに「実務エージェントに人間の承認をどう入れるか」ってところがテーマになってくる。

葵: ここからはSlackが舞台。ふたつ、同じ方向性の製品が出てる。まずAskDoozy。これはSlackからAIに指示すると、実際のシステムを操作してくれる。操作する先はStripe、Postgres、GitHub。

悠真: で、信頼のための仕組みとして、サンドボックスで実行されて、行動ログが全部残る。価格はワークスペース単位の一括払い。システムが壊れそうな変更を、Slackの会話から手軽に実行できる、っていう危険と利便が同居してる製品。

葵: もうひとつはScout。Finiっていう会社のやつね。こちらはサポートチーム向けで、Slackにいて、チケットと評価を読み込んで、パターンを見つけて、修正案を書いてくれる。

悠真: で、ここが重要で、Scoutは「すべての変更に人間の承認が必要」っていうルールが明示されてる。パターン発見と修正案の作成は自動だけど、実行は人間が決める。

葵: このふたつを並べると見えてくるのは、実システムに触れるエージェントには二つの段階があるってこと。AskDoozyは「実行まで自動」で、サンドボックスとログで安全性を担保しようとしてる。Scoutは「実行は人間」で、推薦までを自動化してる。

悠真: リスクの度合いによって設計が分かれる、っていうのが今日の流れの自然な帰結だと思う。Stripeに触れるのはStripeの操作を間違えたら金銭に関わる。サポートの修正案は間違ってもチームがレビューするだけ。その差。

葵: 同じ方向でもうひとつ、Tend。これはiMessageとSMSで使えるパーソナルAIで、GmailとかShopifyとかQuickBooksみたいな、本人のアカウントに入り込んで動いてくれる。

悠真: ここでも「何も承認なしには動かない」っていう原則が書かれてて、メモリは「Brain」って名前で、ユーザーが編集できる。

葵: 個人向けでも、法人向けでも、実システムに触れるAIには「承認」というコンセプトが共通の設計思想になってきてる。Slackに限らず、メッセージング全般がAIの操作ハブになってきてる証拠だと思う。

悠真: で、その先、ビジネスの判断に必要なデータと記憶の話に繋げると、Querri Libraryっていう製品があって。これはビジネスの質問でデータを整理してくれるものなんだけど、ここが他と違って、「回答の73%で別の解釈も明示してくれる」って言ってる。一般的なAIだと12%らしい。

葵: ここ、ちょっと考えたいんだけど、73%っていう数字、どう測ったのかはまだ分からない。それでも方向性としては重要で、普通のAIって「この質問への答えはこれです」って断定しがちだけど、実際のビジネスデータって、同じ数値が別の意味も持ちうるわけ。

悠真: 例えば「売上が上がった」って一言でも、「値上げしたから」かもしれないし、「客数が増えたから」かもしれない。解釈が複数あるときに、それを隠さず出すっていうのは、実務での信頼性に関わる話。

葵: 73%対12%っていう比較は「そう主張してる」で止めておくけど、意識のあり方としては「AIが一つの解釈を与える」ことを疑ってかかる、っていう姿勢を製品化してる点が新しい。

悠真: で、データの解釈と並んで「記憶」の話もこのセクションに入ってくる。Twin for Desktop。これはMacとWindowsで動くアプリで、会議の文字起こしと口述入力をしてくれる。140以上の言語に対応してて、フローティングマイクがあったり、MCPでエージェントにつなげたりできる。

葵: 会議の中身をただ録音して文字にするだけじゃなくて、それをエージェントが読める形にしてる、っていうのが大事。会議の文字起こしがMCPで渡せると、エージェントが「さっきの会議の決定に基づいてタスクを作る」みたいなことができる。

悠真: でもね、解釈と記憶、って言っても、個人レベルの記憶の課題もあって。ここでYarite。iPhoneのアプリで、登録もサーバーも不要。会った人を6つの円で記憶していく。

葵: 名前だけじゃなくて「この人はどのくらい親しいのか」とか「どの文脈で会ったか」を円で管理する。無料で15人まで。それを超えると9.99ドルの一括購入。サブスクじゃなくて買い切りっていうのも、人脈アプリとしては面白い選択。

悠真: 登録不要、サーバーなし、っていうのはプライバシー面での安心材料で、会った人の記憶をローカルだけに持つ、っていう設計。ビジネスのデータと個人の記憶、っていう二本立ての話がこのブロックでのテーマ。

葵: その両方が「人間の頭の中にあるものを、外部にわかりやすい形で取り出す」っていう共通の方向を向いてる。じゃあ、話をより手元に戻すと。デスクトップの話をしよう。

悠真: ここでの話はMacが中心で。まずKoi。このアプリ、3つの機能がひとつに入ってて、Fnキーの組み合わせで切り替わる。Fn+Optionでオフラインの文字起こし、Fn+Cmdで画面を見るAI、Fn+Ctrlでボットなしの通話録音。

葵: この3つが1アプリにまとまってるのが肝で。別々のサービスを3つ契約して、それぞれ別のショートカットで呼び出して、っていう状態がなくなる。価格は59ドルから買い切り。

悠真: しかも文字起こしがオフラインで動くっていうのは、会話の内容をクラウドに送らないっていう設計で、Twin for Desktopと同じ課題をより手元側で解決してる。

葵: もうひとつ、Burrow。これは仮想マシンなんだけど、MITライセンスのオープンソースで、Apple siliconのMac上にWindows 11、Linux、macOSをワンクリックで起動できる。無料。

悠真: Macで完結する作業環境、っていう流れの中に、Burrowは「Macの中で別のOSを動かす」っていう方向で入ってくる。Windowsでしか動かないソフトが必要なときに、別のマシンを用意しないで済む。

葵: この二つの共通点は「Macの環境が整ってきた」っていうこと。文字起こし、画面認識、通話録音、そして別のOSの起動まで、全部手元で完結する世界が見えてきてる。

悠真: 同じ文脈でもうひとつ、Animatica Marionette。Blenderのアドオンで、59ドル。人のリグを、手と足をドラッグするだけでポーズを取らせることができる。オフラインでCPUだけで、1ポーズあたり約15ミリ秒。

葵: 3Dのポーズ付けって、実は地味に重い作業で、IKをいじるのが面倒だったりする。手と足をドラッグするだけでいい、っていうのは制作の効率を直接上げる。デスクトップで完結する制作ツールとして、KoiやBurrowと並ぶ流れ。

悠真: ただ、このあたりの長期サポートがどうなるかは未知数。デスクトップツールって、買って終わりじゃなくて、macOSのバージョンが上がったときに動き続けるかが命だから。

葵: さて、ここからはオープンソースの話。というのも、今まで出てきたツールの多くが、実はオープンソースかMITで配られてる、っていう流れを感じるんだけど、これは知識と実験と記録を、自分の手元に取り込む、っていう共通テーマ。

悠真: まずThe Brains。37のMCPがあって、Paul GrahamとかNavalとか、名だたるファウンダーや投資家の知識にアクセスできる。

葵: ここで大事なのは、答えが必ず「引用とリンク付き」で返ってくるってこと。つまり、ただの生成じゃなくて、その人物が本当に言ったことへの参照がつく。無料でMITライセンス。

悠真: これは hallucination の問題への直接的な回答でね。「その人の考えを聞きたい」ってときに、作り話じゃなくて、実際の発言へのリンクがつく、っていう設計。

葵: で、Flagsmith Experiments。これはA/Bテストなんだけど、オープンソースで、既存のフラグの上で動く。エンジンはベイズ統計を使ってて、自分のウェアハウス、ClickHouseかDatabricksにつなげるか、マネージドで使うか選べる。

悠真: 既存のフラグの上に実験を載せる、っていう発想が実用的でね。A/Bテストを始めるために別の仕組みを導入するのではなく、普段から使ってる機能フラグの仕組みを流用する。ベイズエンジンっていうのは、統計的な判断のしきい値を、直感的に決められる形にするためのもの。

葵: そしてhibi。これはObsidianの代替で、オープンソース。ファイルをローカルフォルダに置く方式で、markdown、Typst、LaTeXをサポートしてる。まだアルファ段階。

悠真: Obsidianと似たような発想なんだけど、TypstとLaTeXに対応してるのが特徴で、学術的な文章も書ける。ローカルフォルダでデータを持つ、っていうのは、誰でも他のツールで同じファイルを触れる、っていう自由さを意味する。

葵: この3つ、「知識」「実験」「記録」っていう、それぞれ違う種類のものを扱ってるんだけど、全部がオープンソースで、全部が自分の手元にデータを置く方向性で揃ってる。クラウドに預けない知識管理、っていう流れが一本の線になってる。

悠真: ただ、hibiはα期の完成度だから、日常の主力ツールにするかどうかはまだ判断できない。オープンソースって、開発の継続性はコミュニティの力に依存するからね。

葵: で、オープンソースの流れから、クリエイターの収益化の話に進むと。Hotlyっていうプレミアムメッセージングのプラットフォームがあって、これもオープンソース。

悠真: 注目すべきは、このプラットフォーム上で制作側の人が、60日で22,400ドル、日本円で330万円くらいを稼いだっていう事例が公開されてる点。開発者側の主張だけど、具体的な数字として出してる。

葵: で、大事なのは、ホスト型でもセルフホストでも、手数料が0%ってこと。Hotlyに自分のサービスを載せても、売上の何割を取られる、っていうことがない。

悠真: セルフホストで0%は分かるんだけど、ホスト型でも0%っていうのは、プラットフォームとしてどう儲けるのか、っていう持続可能性の話が残る。それが未知数の点。

葵: でも、収益化の話としてもうひとつ、UseIt Studio。これはAIデザインエージェントで、実寸、断ち切り、ダイラインを含んだ、製造可能なファイルを出してくれる。しかも編集可能な形式。

悠真: ここが今までのAIデザイン系との違いで。AIに画像を作らせるのは一般的になってるけど、「それを実際に工場で印刷する」って段階になると、実寸が合ってて、断ち切りが設定されてて、ダイラインが入ってる、っていう条件が全部そろわないといけない。

葵: UseIt Studioはその最後の一段階をAIにやらせる。つまり「見た目がきれい」から「製造に回せる」までを、1つのエージェントに任せられる。Hotlyの60日で22,400ドルっていう話と組み合わせると、個人のクリエイターが、制作も収益も自分の手に置く、っていう図式ができる。

悠真: ただ、こっちもプラットフォームとしての持続可能性と、実ファイルの品質が実際の製造現場で耐えられるのか、っていう検証はまだ必要だよね。

葵: さて、その次は、SaaS側の話に戻る。ここでのテーマは、SaaSが自ら成長と統合を自動化していく、っていう方向。

悠真: まずNativeShip。これはSaaSが既に持ってるAPIから、ネイティブなn8n統合を自動で作って公開できる。プレビューがあって、GitHubとnpmのレポジトリが自分用に作られて、バージョン管理も追跡可能。

葵: これが解決してるのは「統合作成の敷居」でね。SaaSが成長しようとすると、いろんなツールとの連携を整える必要があるんだけど、それぞれの統合を手で作ってメンテするのは重い。既存のAPIがあれば、それをn8nの形に落としてくれる、っていう。

悠真: で、もうひとつがNeedle。これは先ほども話した、MCPネイティブのリード生成とアウトバウンドの自動化なんだけど、ここで再度取り上げるのは、Needleが「SaaSがセールスを自動化する」っていう側に立ってるから。

葵: NativeShipが統合を自動化する、Needleがセールスを自動化する、っていう二つを並べると、SaaS側の成長エンジンがエージェントに置き換わりつつある、っていう見え方になる。

悠真: ただ、このあたりの未知数は、統合の品質の検証プロセス。NativeShipが自動生成したn8n統合が、実際のSaaSのAPIの変更にどう追従するのか、っていう運用の話はまだ見えてない。

葵: 最後の話題にいこうか。エージェントの居場所、っていう話。ここは対比が面白くて、企業レベルと、遊び心の両方から攻めてる。

悠真: まず企業側がPrivOS。これはセルフホスト型の企業向けAIオペレーティングシステムで、10人まで無料。エージェントはMCP経由で隔離されたコンテナの中で動く。

葵: セルフホストっていうのがポイントで、企業のデータを外部に預けない。その上で、MCPでつなげるエージェントを、コンテナで分離して走らせる。セキュリティ監査の詳細はまだ明かされてないけど、「分離」っていう概念を中心に据えてる。

悠真: その一方で、遊び側がAgent Pets。これはClaude CodeとかOpenCodeのセッションを、Chrome上の動物に見立てる。それぞれのセッションがペットになって、どのタブからでも承認ができる。

葵: 見た目はふざけてるんだけど、機能としては真面目で、複数のエージェントを走らせてるときに、どれが生きてて、どれが承認待ちかを、動物の形で一覧できる。6ドルの買い切り。

悠真: 承認が「どのタブからでも」できる、っていうのは、複数セッション運用の実務的な課題を、動物のメタファーで解いてる。面白さと実用が共存してる。

葵: 企業レベルのPrivOSと、個人レベルのAgent Pets。エージェントが増えてきたからこそ、「どこに置いて、どう見守るか」っていう課題が本質になってきてる。今日ずっと話してきた、コスト、協調、MCP、承認、データ、デスクトップ、オープンソース、収益、SaaS、そして居場所、っていう流れを全部つなぐと、エージェントが当たり前に存在する環境が整いつつある、っていう絵になる。

悠真: うん。ただ、今日の話で何度も出てきた「未知数」をもう一度言うと。品質の検証がどうされてるか、長期のサポート、実システムでの信頼性、セキュリティ監査の詳細、α段階の完成度、プラットフォームの持続可能性。全部はまだ見えてない。

葵: そう。だから今日出た数字も主張として受け取って、実際に触る機会があれば自分で試してみてほしい。今日はここまで。ありがとうございました。

悠真: また次回。