0915 | 今週の新ツール速報：エージェントが本格稼働

葵: こんにちは、この時間のテクノロジーブリーフィングへようこそ。パーソナリティの葵です。

悠真: 悠真です。今日は過去24時間に発表された製品をいくつかピックアップして、それぞれ誰のためのものなのか、既存の選択肢と何が違うのか、そして何がまだ分からないのか、という視点で深掘りしていきます。

葵: 今日のラインナップを貫いているテーマは、実は一本の糸でつながっています。AIエージェントが「行動するだけ」から「知識を持ち、調査し、コードを書き、テストし、APIとして世界に接続する」まで広がってきた流れです。

悠真: そこから派生して、セルフホストやローカル処理という「自分の手元に置く」志向、Macのユーティリティ、クリエイター向けツール、そしてメールや営業、日常の受信箱のAI化まで。全部つながってるんですよ。

葵: じゃあ、今日の最初はAIエージェントそのもの、ブラウザの話から始めましょう。AsideというAIエージェント専用のブラウザです。

悠真: これ、開発側の主張としては面白いんですよ。ログイン済みのアカウントを使って、エージェントが「実作業を完了する」までやるブラウザなんと。

葵: ここがポイントで、普段我々がブラウザでやるのって、単に調べ物だけじゃないですよね。ログインして、フォーム入力して、承認して。Asideはその一連の実作業をエージェントに任せることを前提に設計されている。

悠真: そしてセキュリティ面も主張されてます。パスキー対応、処理はローカル、暗号化。あとベンチマークでSOTA、つまり最高水準の成績を出したと主張しています。

葵: ただ、これはあくまで開発側の説明ですから、そこは一応の留保をつけておくべきですね。ベンチが何を測っているのか、実作業の精度がどう実証されているのかは、リリース文からだけだと分からない。

悠真: そうですね。「ログイン済みアカウントで実作業」っていうのが一番大事な功能なんですけど、だからこそセキュリティの実態が気になる。パスキー対応と暗号化は具体的な手がかりではありますけど、どの範囲まで安全なのかは利用者自身が確認する必要がありそうです。

葵: エージェントがブラウザで動けるようになった、じゃあそのエージェントは何を「知って」動くのか。次はナレッジ基盤の話です。OzBrainという製品で、開発側は「エージェント知識のDropbox」という表現を使ってます。

悠真: 面白い比喩ですよね。AIエージェントと人間のチームが、同じナレッジ基盤に読み書きする。つまり人間だけのWikiでも、エージェントだけの内部データでもなく、両方が同じ場所に書き込んで取り出す。

葵: ここで僕たちが注目すべきは、暗号化を備えていること、そして「学習なし」と明言していること。エージェントの学習に自分の知識が使われない、というのは企業にとって大きな関心事ですよね。

悠真: あとmarkdown出力できるのも地味ですが重要です。ナレッジを特別な形式に閉じ込めず、持ち出せる。ロックインへの警戒心が強いチームほどここは効いてくると思います。

葵: AsideとOzBrainを並べると、今週の潮流が見えてきます。エージェントが「行動する」道具（ブラウザ）と、「知識を持つ」場所（ナレッジ基盤）。この二つが揃うと、エージェントは行動しながら学び、知識に基づいて行動できる。

悠真: ただ、OzBrainについても、実際にエージェントがそのナレッジをどのくらい活用できるのか、どのエージェントと接続できるのか、そこはまだ公開情報からは見えない部分ですね。

葵: そしてもう一つ。エージェントは行動と知識を持ち始めたけれど、その次に必要なのが「調査」です。Nimble Web Search Agentsという、ドメイン特化型のWeb調査エージェントがあります。

悠真: 一般的な検索エージェントと何が違うかというと、特定分野に特化していて、しかも自己学習するという点。開発側の説明では、企業調査やニュース監視みたいな用途で、深く潜って調べつつ、トークンを節約できると主張されています。

葵: トークン節約というのは、深掘りと普通はトレードオフですよね。調べれば調べるほどAPIコストも時間もかかる。そこを両立できると主張しているのが差別化ポイントです。

悠真: ただし「自己学習する」の部分は、何をどう学習するのか、誤情報を学習してしまうリスクはないのか、という疑問も残ります。調査結果の正確性がそのまま仕事の質に直結する用途ですから、ここは検証したいところです。

葵: Aside、OzBrain、Nimble。この三つで「エージェントの行動・知識・調査」という三本柱が揃いました。ここからは、エージェントがコードを触る世界に入っていきます。

悠真: そう、AIがコードを書くのはもう当たり前になりつつあるんですが、今度は「書いたコードをどう検証し、どう管理するか」が新しい課題になってきています。まずTryCaseという視覚的なE2Eテストツールから。

葵: 仕組みを整理するとですね。プルリクエストが出されるたびに、AIがそのアプリを実際に操作する。そして操作の様子を動画のウォークスルーにして、判定と一緒にGitHubへ返す。

悠真: 動画で返すのが肝ですよね。従来のテストって、パスかフェイルかという結果と、ログのスタックトレースが返ってくるだけで、「どこで何が壊れたか」を人間が読み解く必要があった。動画なら一目で分かる。

葵: そして複数のプルリクエストを並行して検証できるという点も、レビュー待ちが積み上がるチームには効きそうです。

悠真: ただ、AIが「操作して大丈夫だった」と判定したとしても、それがそのチームの重要なユースケースを全部カバーしているとは限らない。AIの判定と人間のレビューをどう組み合わせるかは、導入チームの設計次第ですよね。

葵: テストは「コードの検証」でしたが、次は「コードを書くエージェントの管理」です。Jugglerという、AIコーディングエージェントの可視ハーネスと紹介されているOSSツール。

悠真: 構成としては、Finder式の列ビューでエージェントの作業を俯瞰できて、スレッドを分岐させられる。JSでプラグインを書けて、Goのバイナリとして配布されるOSSです。

葵: 「可視ハーネス」という言葉が上手いと思うんですよ。AIコーディングエージェントって、複数走らせると何をやっているのか見えなくなるんですよね。列ビューで俯瞰して、スレッドを分岐して試行錯誤を整理する。作業場の監視カメラと分岐器を用意した感じです。

悠真: OSSでGoバイナリというのも、チームで入れる敷居が低い。ただ、どのエージェントに対応しているのか、プラグインでどこまでカスタマイズできるのかは、実際に触ってみないと分かりませんね。

葵: こうして見ると、TryCaseとJugglerは表裏一体です。エージェントが書いたコードをTryCaseで検証し、エージェント自身の作業をJugglerで見守る。検証と管理、どちらも「AIが書く」時代の新しい土台です。

悠真: そして、この二つに共通して関わってくるのがインフラ側の話ですね。DeploというセルフホストPaaSは、この文脈でもう一度出てくるので、そこで詳しくやるとして。この話題の締めとして、エージェントがコードを書いて、テストして、それを世界に公開する、その「公開」の話へ行きましょう。

葵: ここでElvaという製品です。これは結構、構造的な問題を突いています。コードからAPIを発見して、契約で公開範囲を統制する、そしてホスト型のMCPサーバーと認証・分析を提供する。

悠真: まず「コードからAPIを発見」というのが特徴で、仕様書が不要なんですよ。OpenAPIの定義ファイルを手で保守する、あの辛さをご存じの方は多いと思うんですが、Elvaはコードそのものをソースにする。

葵: そして「契約で公開範囲を統制」というのが、エージェント時代には非常に大事な点です。AIエージェントがAPIを勝手に叩けると困りますよね。どのAPIを、誰に、どう公開するかを契約として管理できる。

悠真: ホスト型MCPサーバーというのは、MCP、つまりモデルコンテキストプロトコルを通じて、エージェントからAPIに接続できるようにする仕組みです。認証と分析もセットで提供されている。

葵: つまりコードからAPIカタログまで、そしてエージェント接続まで一気通貫なんです。さっきの話とつなげると、エージェントがコードを書き（Juggler）、テストし（TryCase）、そのAPIをElvaでエージェントに開放する。サイクルが閉じますよね。

悠真: 一方で、契約による統制が「コードから自動で発見」とどう噛み合うのか、微妙に手動の運用が残るのではないか、という疑問はあります。また「分析」がどの粒度で見られるのかも、セキュリティ担当者が確認したいポイントでしょう。

葵: コードを書いて、公開する、ときたら、次は「どこで動かすか」の話です。セルフホストとローカル志向の製品を二つ。まずDeplo、セルフホストPaaSです。

悠真: PaaSというとHeroku的な「プッシュしたらデプロイされる」便利さですが、自分の環境でそれをやろうとするとDockerを書いて、SSHを設定して、YAMLを保守して、って手間があった。

葵: Deploはその三つを不要にして、プッシュデプロイを実現すると主張しています。さらにプレビュー環境、RBACによる権限管理、そしてMCPでAI運用ができるという点が、今回のエージェントの流れとつながる。

悠真: 「MCPでAI運用」というのは、運用作業そのものをエージェントに任せられるということです。インフラの運用にもエージェントが入ってくる、という構図ですね。ライセンスはAGPLv3で、OSSとしての側面も明確です。

葵: AGPLv3は、SaaSとして改変して提供する場合にもソース公開義務が及ぶライセンスなので、商用利用を考えるチームは確認しておくべきですね。

悠真: そしてもう一つがOats。無料でOSS、オンデバイス動作の会議メモツールです。

葵: ここが面白いところで、会議メモ系のツールって、ボットが会議に参加するのが普通でしたよね。でもOatsはボット不参加。録音も要約も全部ローカルで処理する。

悠真: MacとWindowsに対応していて、保存先はMarkdownで、Obsidianでも使える。オンデバイス処理なので、会議の内容が外部サービスに流れない。機密事項を扱うチームには、この一点だけで選ぶ理由になり得ます。

葵: DeploもOatsも、方向性は同じです。データを自分の手元に置く。Deploはインフラを自分でホストし、Oatsは会話を自分のデバイスで処理する。クラウドの便利さと引き換えにしてきたプライバシーを、少しずつ取り戻す流れと言えます。

悠真: ただしトレードオフもあります。オンデバイスで要約するなら、要約の質はデバイスの性能とローカルモデルに依存するわけで、クラウドの大規模モデルと比べてどうなのか。そしてセルフホストは、便利さの分だけ自分で面倒を見る責任が生じます。その辺りの距離感は人それぞれですね。

葵: そしてここから、雰囲気ががらっと変わります。Macのデスクトップに戻りましょう。遊び心と実用が同居する、三つの製品です。

悠真: まずMemoryPet 2.0。Chromeのツールバーに住むペットが、メモリとCPU使用率で動くというものです。

葵: 動きでリソースが見えるっていう発想が可愛いんですよね。バージョン2.0では、新しいCPU追跡、ペットが8匹追加、グラフ表示、そしてアニメをオフにする切り替えが加わったとされています。

悠真: アニメオフの切替が地味に大事です。仕事中にずっとアニメーションが動いてたら気が散りますから。「遊びは遊び、でも切れる」という配慮が、ユーティリティとしての完成度を感じさせます。

葵: 次は、少し年季の入った話題。Afterglowという、かつてのAfter Darkの名作スクリーンセーバーを現行macOSでネイティブ実行するものです。

悠真: Flying Toasters、飛ぶトースターですよ。あれをもう一度見られる。しかもROM不要で、つまり昔のシステムROMを用意しなくても動く。

葵: ネイティブ実行というのが技術的に意味があって、エミュレーションじゃなくて現行のmacOSでそのまま動く。レトロな見た目を、現代の環境で気軽に。

悠真: ただ、開発元や権利関係がどうなっているのかは、この種の復刻ものでは常に気になるところですね。ソースからは権利周りの詳細までは読み取れません。

葵: 三つ目がAppZapper 3000。定番のmacOSアンインストーラーを再構築したものです。

悠真: 使い方はシンプルで、アプリをドラッグすると関連ファイルを検出して、3Dレーザーで削除する。あの「Zap!」という削除体験を、3Dで更新したんですね。

葵: アンインストーラーって、一見地味ですが、macOSではアプリをゴミ箱に入れても関連ファイルが散らばったままになるという長年の問題があって。AppZapperはその解決策の定番でした。それを「3000」として生まれ変わらせたというのは、ユーザーからの信頼があったからこその続編です。

悠真: この三つに共通するのは、Macという環境で「日常のちょっとした体験」を丁寧に作っていること。リソースを可視化するペット、懐かしいスクリーンセーバー、関連ファイルの掃除。実用性と遊び心のバランスが良い枠でした。

葵: 次は、クリエイター向けの三つです。まずOVO、iPhone、iPad、そしてApple Watch向けの音楽プレイヤー。

悠真: 特徴としては、ローカルファイルを中心に据えつつ、Apple Musicなどのサービスを統合できる。そして10バンドのイコライザーを備えています。

葵: 「ローカルファイル中心」という点は、ストリーミング全盛の時代に逆行しているようで、実はニッチな需要がしっかりあるんですよ。自分の音源を持ってる人は、それをストリーミングアプリと混ぜて聴きたい。OVOはその両方を一つのプレイヤーで。

悠真: Apple Watch対応というのも、この種のプレイヤーとしては珍しい気がします。そして気になる提供形態としては、Pro永久ライセンスが先着1000人とあります。買い切りというのは、サブスク疲れの人には響くかもしれません。ただ「永久」の条件がどう定義されているかは、購入前に確認するべきですね。

葵: 二つ目はImage to ASCII。ブラウザ内でローカル処理して画像をASCIIアートに変換する無料ツールです。

悠真: 無料で登録不要、そして処理がブラウザ内で完する。つまり画像をサーバーに送らない。ここでも「ローカル処理」が出てきましたね、さっきのOatsと同じ思想です。

葵: 出力形式が豊富なのが実用的で、TXT、PNG、SVG、HTML、ANSIと対応しています。さらにREADME向けとDiscord向けのプリセットが用意されている。

悠真: プリセットというのが親切ですよね。READMEに貼るならこんな感じ、Discordに貼るならこんな感じ、と用途別に最適化されている。ASCIIアートって一見遊びみたいですが、READMEの目印やコミュニティの自己表現として、ちゃんと使われるものなので。

葵: 三つ目はappdesigns。ブラウザで無料の、App StoreとGoogle Playのスクリーンショット編集ツールです。

悠真: アプリをストアに出すとき、スクリーンショットにデバイスの枠をつけたり、見出しのコピーを入れたりするんですけど、それをブラウザでできる。しかも無制限に出力できて、透かしなし、登録不要。

葵: これ、インディーのアプリ開発者にはかなり嬉しいはずです。ストアスクショのデザインをやろうとすると、デザインツールでテンプレートを作るか、外注するかのどちらかになりがちでしたから。無料で透かしなしという条件は、既存ツールとの明確な差です。

悠真: OVO、Image to ASCII、appdesigns、三つとも個人クリエイターが「自分の作品を表現する」ための軽い道具という点で揃っていました。重い契約も、送信されるデータもなく、すぐに使える。

葵: そして最後のテーマは、コミュニケーションのAI化です。まずは送信側から、Hello Inboxというメール到達性のツールです。

悠真: 「到達性」というのは、送ったメールが迷惑メールフォルダに振り分けられず、ちゃんと相手の受信箱に入るかどうかという問題です。マーケティングの人にとっては、これが死活問題なんですよね。

葵: Hello Inboxのアプローチは、AIが到達性をテストして分析し、具体的な修正手順を提示するというもの。「問題があります」で終わらせず「どう直すか」まで出すのが特徴とされています。

悠真: さらにモニタリング機能として、DMARCの監視と、ブラックリストへの登録を警告してくれる。つまり一回の診断で終わらせず、継続的に見守る。

葵: ここは主張として重要な区別です。診断ツールは多いんですが、修正手順の具体性と継続監視の両方を提供していると開発側は述べています。ただ、AIが提示する修正手順がどの程度の精度なのか、誤った対処を誘導しないのかは、実際に使ってみないと判断できませんね。

悠真: そして送信側から受信側へ。Naoma V2という、AIアカウントエクゼクティブの製品です。

葵: これは、サイトを訪問した見込み客に、AIがその場でデモを実施するというもの。開発元は5万デモの実績を挙げていますが、これはあくまで開発側の主張として扱うべき数字です。

悠真: 機能としては、資格判定、つまりその訪問者がちゃんと顧客になり得る人物かを見極めて、CRMと連携して、セルフサーブ化、つまり営業担当を介さず訪問者が自分で進められるという構成です。

葵: Hello InboxとNaoma V2を並べると、面白い構図が見えます。アウトリーチの送信側と受信側の両方にAIが入っている。送る側は到達性を高め、受けた側はAIが即座に対応する。営業という人間の仕事が、両端から置き換えられつつある。

悠真: もっとも、AIのデモが人間の営業にどこまで追いつくのかは、まだ誰にも分かりません。複雑な質問への対応や、商談の温度感づくりは人間の領域が残るでしょうから、「セルフサーブで済む案件」と「人間が関わる案件」の分岐が今後の論点になりそうです。

葵: さて、最後は日常のレベルに降りてきましょう。受信箱とブックマークです。まずSlashy Assistant。これはAIネイティブなメールクライアントに組み込まれるAIです。

悠真: 機能としては、返信の下書きと会議の調整。そして面白いのが、それをiMessage、Slack、電話経由でも行えるという点。メールクライアントの中だけで完結せず、自分が普段使っている経路からAIに指示できる。

葵: そして設定が平文で書けるという点も、この製品の売りとして挙げられています。自動化のルールを複雑なUIで設定するのではなく、文章で書く。これ、設定の心理的ハードルが全然違いますよね。

悠真: ここで少し振り返ると、Naoma V2が営業の受信側だったのに対し、Slashyは個人の受信箱。規模は違っても「AIが通信の当番を引き受ける」という方向は同じです。

葵: 最後はMarqly 6.0。ブックマーク管理ツールにAI機能が加わったバージョンです。

悠真: AIアシスタントが保存した内容に基づいて答えてくれる。つまり「あの記事、なんか保存したんだけど何だっけ」と聞けば、内容から探してくれる。さらにAIが整理案を出してくれる。

葵: ブックマークって、保存した瞬間から二度と開かないのが典型ですよね。原因の一つは、見つけ直すのが面倒なこと。内容で検索できる、AIが整理してくれる、というのはその問題へのまっすぐな解決策です。

悠真: そしてMCP対応で、ClaudeやChatGPTなどのAIから、Marqlyの保存と調査に接続できる。ここでもMCPという共通の規格が出てきました。Elva、Deplo、Marqly、エージェントを外部の道具につなぐ手段としてMCPが標準になりつつあるのを、三つの異なる製品で見ましたね。

葵: さて、今日の全体を振り返ると、一本の線が通っています。エージェントがブラウザで行動し（Aside）、知識を持ち（OzBrain）、調査し（Nimble）、コードを書いて（Juggler）テストし（TryCase）、APIを通じて世界と接続し（Elva）、インフラも運用し（Deplo）、そして営業から受信箱、ブックマークまで日常のあらゆる場面で代理行動する。

悠真: その裏側で、「データを自分の手元に置く」という逆方向の流れも同時に進んでいます。Oatsのオンデバイス処理、Image to ASCIIのブラウザ内処理、OzBrainの学習なし、Asideのローカル処理。AIに任せれば任せるほど、何をどこに置くかという選択が重要になる、ということでしょうか。

葵: その通りですね。エージェントの時代は「何を任せるか」と「何を手元に残すか」の設計問題になっていく。ここは今後も注目していきたいところです。

悠真: 以上、今日のブリーフィングでした。なお、今日お伝えした製品の性能や実績は、いずれも開発元の発表に基づくものであり、検証済みの結果ではない点はご留意ください。

葵: それではまた次回。ご視聴ありがとうございました。