1021 | 今週のAIツール速報:エージェント時代の基盤と新製品 roundup

葵: みなさん、こんにちは。今日も一日のAIプロダクト総まとめ、お付き合いいただきましょう。葵です。

悠真: 悠真です。今日のラインナップは、文脈供給、エージェント基盤、コーディング環境、開発者の日常ツール、チャット型AI、動画生成、ハードウェア、そして最後は実験的なプロダクトまで。でかいテーマで言うと「AIに仕事をさせるために、何を整えるのか」という話が一本の糸でつながってます。

葵: そうですね。今日は全部の紹介を均等にやるんじゃなくて、あえて幅広く見た上で、どれがどんな問題を、どんな解き方で、どんな人に向けているのかを整理していくスタイルにします。

悠真: それでは最初は文脈の話からいきますか。AIに渡す文脈をどう作るか、という基盤の話です。

葵: 一つ目はyggy。ドキュメントや既存システムから自動で自己構築していくAIナレッジグラフです。ポイントはいくつかあって、まず事実が出所を保持していること。グラフ上の情報が「どこから来たか」が残るので、エージェントが参照するときに根拠をたどれる。

悠真: そこ、割と大事なところですよね。ナレッジグラフって、自動構築する系は「グラフはできるけど、中身の信頼性は誰も保証しない」みたいなことが起きがちで。yggyはもう一つ、マージが可逆だという点も謳ってます。事実を統合したとしても、元に戻せる。つまり構築プロセス自体をやり直せる前提で設計されてる。

葵: あとはEUホスティング対応というのも明示されてますね。データの置き場所が気になる企業には効く選択肢です。APIとMCPに対応してるので、エージェントから直接呼び出す形で組み込めます。

悠真: ここで正直に言うと、まだ誰がどう使ってるかとか、実際のグラフ品質がどうなってるかというコミュニティ側の検証は手元にない。だから「こういう設計思想のプロダクトが出た」という紹介にとどめるのが正確です。出所保持と可逆マージ、この二つは他のRAGツールと差別化できる主張ではある。

葵: そして同じ「文脈を作る」という枠組みの、検索側の話。Exa 3.0です。検索APIの大型アップデートで、目玉はDynamic Highlights。トークン消費を最大95%削減するという主張です。

悠真: 95%って数字はメーカー側の主張として受け取るべきですけど、発想としてはわかりやすい。検索APIでドキュメントを丸ごと取ってLLMに食わせると、必要な部分はほんの一部なのにトークンが膨らむ。Dynamic Highlightsは、必要な箇所だけを抜き出して渡す。コンテキストウィンドウとコストを両方節約する方向ですね。

葵: 料金面では、低価格のExa Liteというtierがあって、4ドル/1,000リクエスト。あと数十億の新ドキュメントをインデックスに追加したというのも更新内容として挙がってます。

悠真: yggyとExa 3.0、並べると面白いんですね。yggyは社内のドキュメントやシステムから文脈を「作る」方向。Exaは外部のWebから文脈を「取得する」方向。どっちもAIに渡す文脈の質とコストを改善しようとしてる。で、この二つが整うと次の段階、つまりエージェントの実運用の話に自然につながる。

葵: そう、エージェントに仕事をさせるときの壁って、文脈だけじゃなくて、コストと、ツールの調達と、能力自体の改良があるんですよね。今日の次のテーマはそこです。

悠真: まずRunInfra。月10ドルのフラット料金で、GLM 5.3とかDeepSeekのような高速なオープンモデルを、Claude Codeなどからそのまま使えるサービス。

葵: ここでの主張ポイントは二つ。一つは定額制であること。トークン課金だと使いすぎが怖くて、エージェントに長時間の作業を任せにくい、という悩みに対するアプローチ。もう一つはキャッシュヒット率99.5%という数字。

悠真: 99.5%というのはメーカー側の主張ですから、鵜呑みにはしない。ただ、キャッシュヒット率が高いということは、繰り返し同じ種類の作業をするときにコスト効率が上がるという話で、フラット料金と相性がいい。オープンモデルをClaude Codeみたいな既存のクライアントから使える、というのが誰向けかを示してる点も明確です。

葵: 次はComposio Instant。エージェントに共有ウォレットを持たせて、1,500以上のツールをオンデマンドで使えるようにする、というものです。

悠真: これ、地味だけど結構本質的な問題を突いてるんですよ。エージェントに何か外部ツールを使わせようとすると、その都度サインアップしてAPIキーを取って、課金設定して、という準備が発生する。Composio Instantはその手間を消して、必要になった瞬間にウォレットから支払ってツールを使える形にする。

葵: 条件としては、2ドルの無料クレジットがついて、マークアップは0%と主張してます。つまりツールの本来の価格で払うだけ。誰向けかというと、エージェントに不特定多数のツールを使わせたい開発者ですね。逆に言うと、予算管理をきちんとしたい組織では、共有ウォレットのガバナンスがどうなってるかは気になる点です。

悠真: そして三つ目がHarness²。Google Researchのオープンソースフレームワークで、エージェントが自らのハーネスを自動進化させる、というもの。ベンチマークで最大+11.5ポイントという数字が出てます。

葵: ハーネスというのは、エージェントを動かす外側の仕組みですね。ツール呼び出し方とか、プロンプトの構成とか。Harness²は、その部分自体をエージェントが試行錯誤して改良していく、という発想。

悠真: +11.5ポイントという数字も、どのベンチマークで、どの条件下かによって意味が変わるので、あくまで主張として伝えるのが正確です。ただ、発想としては面白い。モデルの改良ではなく、モデルを包む土台の改良を自動化しようとしてる。コスト、ツール調達、能力改良。この三つがエージェント実運用の壁で、今日の三製品はそれぞれ一つの壁を狙ってるわけです。

葵: では、そのエージェントたちが実際に作業する「場所」の話に移りましょう。コーディングエージェントの作業環境です。

悠真: まずsnygyのsnyvi。無料のオープンソース、MITライセンスのデスクトップアプリで、各プロジェクトに「デスク」を与えて、最大4つのコーディングエージェントを横に並べて作業させるというもの。ローカル専用です。

葵: 「ローカル専用」という点が明確な差別化です。エージェントを並列に走らせると、複数の作業を同時に進められる一方で、コードがクラウドに流れることへの懸念も増える。snyviはそれをローカルで完結させる方向に切ってます。だれ向けかというと、複数エージェントを動かしたい個人開発者ですね。無料でMITなので、試す障壁は低い。

悠真: 逆に言うと、チームでの共有やクラウド連携は、このツールの範囲外。そこは他のツールの役割ということになります。

葵: 次はESP-Mosaico。モジュラー式のESP32-S31開発ボードです。ここで面白いのは、AIコーディングエージェントが実ハードウェアをビルドして、デプロイして、反復できる、という点。

悠真: コーディングエージェントはソフトウェアの世界で進化してきましたが、ハードウェアは閉じた世界でした。ファームウェアを書いても、ボードに焼いて動かして確認するというループが人の手だった。ESP-Mosaicoはそのループ自体をエージェントに渡そうとしてる。モジュラー式というのが、用途に応じて構成を変えられる、という意味ですね。

葵: 誰向けかというと、組み込み開発をしていて、エージェントの作業範囲を物理デバイスまで広げたい人。ここは正直、まだ始まったばかりの領域なので、実際にどんな反復ができるのか、どの程度まで自律的にやれるのかは、これからの検証次第です。

悠真: そして、エージェントの作業場整備の三点目がInflight。プロトタイプにピン留めコメントや動画を添えて、コーディングエージェントがMCP経由で次のステップを取得できる、というフィードバックレイヤーです。

葵: これ、snyviと対になる存在と考えると分かりやすいです。snyviがエージェントの作業場を整えるなら、Inflightは人間側からのフィードバックをエージェントに届けるパイプを作る。プロトタイプを見た人が「このボタンの位置、こうしたい」ってコメントをピン留めすると、それがエージェントの次の指示として渡る。

悠真: 映像で伝えられるってのがポイントですね。テキストで「ここのUIが変」って書くのは難しいけど、画面を指して動画で説明すれば正確に伝わる。ソフト、ハード、フィードバック。エージェントの作業場が三つの面から整ってきた、という見方ができます。

葵: では、もう少し日常の細かい部分へ。開発者の日々の作業を潰すツール群です。

悠真: まずxtty。macOSのネイティブターミナルで、SSH作業に特化してます。機能としては、SSHの一括接続、Keychain経由のパスワード自動入力、sz/rzのファイル転送対応、タブ、そしてエージェントの状況表示。

葵: Keychainでパスワードを管理するというのは、macOSユーザーには自然な選択です。セキュリティの仕組みをOSに任せられる。エージェントの状況表示がターミナルに入ってるのも、SSH作業しながらエージェントを監視したい、という最近のニーズを捉えてます。

悠真: 次はPortlivo。Macのメニューバーから、ローカルの開発サーバーとポートを一覧できるアプリ。ワンクリックで起動、停止、再起動、ログ確認ができる。8.99ドルの買い切りです。

葵: 誰のためのものかは明白です。複数のプロジェクトを並行して触ってて、「ポート3000がどうなってるか分からない」という状況に何度も遭遇する人。lsofでプロセスを探してkillする、みたいな作業をメニューバーに置き換える。買い切りなので、サブスク疲れの人にも向いてます。

悠真: 三つ目はHoistbay。S3/CloudFront向けのオープンソースデスクトップアプリです。ヘッダールールの自動化、フォルダダウンロード、キャッシュ無効化をワンクリックで。

葵: 静的サイトのデプロイって、細かい設定の積み重ねなんですよね。ヘッダーのキャッシュ設定とか、CloudFrontのキャッシュ無効化とか。Hoistbayはその面倒をGUIに閉じ込めた。MITライセンスのオープンソースなので、中身がどうなってるかも確認できます。

悠真: 四つ目がMintlify Autopilot。これはリポジトリとSlackを監視するエージェントで、ドキュメントの更新PRを下書きしてくれる。マージされたPRとクローズされたPRから文体を学ぶというのが特徴です。

葵: ドキュメントの陳腐化は、開発現場の永遠の悩みです。コードは変わるのにドキュメントは変わらない。AutopilotはPRを監視して、「この変更はドキュメントのこの部分に影響する」と検知したら、ドラフトをPRとして出す。人間がレビューしてマージする流れですね。文体を学習するというのは、ドキュメントの一貫性を保つための工夫です。

悠真: この四つ、共通するのは「日常の細かい面倒を、それぞれの位置で潰す」というスタンスです。SSH、ローカルサーバー、デプロイ、ドキュメント。どれも劇的な変化じゃないんですが、積み重なると手が離れなくなるタイプの改善です。

葵: さて、ここからは少し視点を変えて、ドキュメントや知識を、開発者ではなくエンドユーザーに届ける形のAIです。チャットという界面に住むAIたちです。

悠真: まずreception。iOSアプリ内のネイティブサポートチャットで、AIがドキュメントから回答します。月額25ドルのフラットです。

葵: 特徴は三つ。一つ目は「アプリ内のネイティブ」であること。WebViewを貼るのではなく、iOSのUIとして組み込まれる。二つ目は、回答に使うのがドキュメントで、しかもチャット内でレビューやオファーも提示できる。つまりサポートがそのままセールスにつながる可能性を持ってる。三つ目は、受信箱がTelegramだということ。

悠真: Telegramをサポート受信箱にするというのは、ちょっと意外ですが、開発者がすでにTelegramを使ってる場合にはスムーズですね。月25ドルフラットという価格も、小規模アプリ開発者向けであることを示してます。ドキュメントの質が回答の質に直結する、という依存関係は注意点です。

葵: 次はJotform App Builder。Jotformのフォームから、ChatGPTとClaudeの中で動くノーコードアプリを構築するというものです。ポータル、ストア、カタログみたいな形態ですね。

悠真: Jotformって、元々はフォーム作成のプラットフォームで、膨大なユーザーベースがあります。その資産を活かす発想です。「フォームデータがあるんだけど、それをアプリにしたい」というニーズに対して、コードを書かずにChatGPTやClaudeの中で動くアプリを生成する。フォームからアプリへ、というのが他のノーコードツールと違う起点です。

葵: そしてbonds。これはメッセージアプリで、友人とのチャットそれぞれに、AIコンパニオンの「bondi」がいて、チャット内でアプリやゲームを生成するんです。

悠真: チャットの中にAIがいて、そのAIが場を盛り上げるためにゲームを作ってみんなで遊ぶ、という発想。SNSやメッセージアプリって、会話が途切れると静かになることがあるんですが、bondiがそこに何かを生成して持ち込む。コンセプトとしては新しくて、誰向けかというと、友人との雑談の場をAIで補完したい、という人たちですね。

葵: もちろん、AIがチャットに介入することをどう受け止めるかは人によって分かれるところです。友人とのプライベートな空間にAIが入るのは、便利さと気まずさのバランスが問われる領域です。

悠真: そしてStella。感情ウェルネスAIで、iOSの音声アプリかiMessageのテキストで利用できます。月9.99ドル、年間59.99ドル。

葵: ここで正直に触れるべきは、Stella自身が「セラピーではない」と明記してる点です。ウェルネスの伴走者であり、専門的な心理療法の代替ではない。これはこの領域の製品として当然の線引きで、ユーザー側も理解しておくべき前提です。

悠真: reception、Jotform、bonds、Stella。四つを並べると、共通テーマがくっきりします。AIサービスが「チャット」という界面で供給される。サポートはチャットで、アプリ構築はチャットで、友人との会話の中で、感情の伴走もチャットで。それぞれの用途は全然違うのに、アクセスの形が収束してきてるんですよね。

葵: では次、チャットという界面から、映像の世界へ。Kling 4.0です。

悠真: AI動画生成のアップデートで、機能面の主張は、最大10キーフレーム、最大15参照、30秒クリップ、10以上の言語のリップシンク。そしてMCPとCLIに対応してます。低価格のFlashティアは720pのより安い層です。

葵: 注目すべきは制御性の強化ですね。キーフレームを最大10個指定できるというのは、動画の「この時点ではこう、この時点ではこう」という意図を明示できる。参照を15個まで持てるというのも、キャラクターやスタイルの一貫性を保つための材料を増やせる。作りたいものがはっきりしてる制作者には効く方向です。

悠真: 30秒クリップは、実用的な長さとしてようやく使える範囲に近づいてきた印象です。そしてMCPとCLI対応。これ、前半のエージェントの話とつながるんですよ。動画生成がMCPで呼べるということは、エージェントの作業の一部として動画生成が組み込めるということ。たとえばプレゼン資料の一部の映像をエージェントが生成する、みたいな使い方が考えられる。

葵: Flashティアの存在は、料金の入口を下げる役割です。720pでまず試して、必要になったら上のtierに、という導線ですね。どのtierでも実際の品質がどうかは、やはり自分で試さないと分からないところです。

悠真: さて、ここからはAIが動く「場所」を物理側から見ます。推論ハードウェアとロボットです。

葵: まずIntel GPU D270。推論用のGPUで、HBMを使わずに、最大480GBのLPDDR5Xを搭載してます。350W空冷、メモリ帯域1.5TB/s、FP8で1.3 PFLOPSというスペックです。

悠真: HBMを使わない、というのがポイントです。HBMは高価で、冷却も難しい。LPDDR5Xなら帯域は劣るものの、容量を大きく取れて、空冷で済む。480GBを空冷で動かせるというのは、大容量のモデルを扱いたいけどサーバールームは用意できない、という状況への一つの答えです。

葵: ただし、LPDDR5Xの1.5TB/sという帯域が実際の推論性能にどう効くかは、モデルの種類によって変わります。帯域が律速になるワークロードと、そうでないワークロードがある。スペックだけ見ても使い勝手は判断しにくいので、実測の検証が待たれるところです。

悠真: そしてAsimov 1。Menloという会社のオープンソース人型ロボットです。身長1.2m、25関節、2万ドルのキットで、20カ国以上に出荷済みという主張です。

葵: オープンソースの人型ロボットが2万ドルで買える、というのは、かつて人型ロボットが研究機関の専用品だったことを思うと、かなり状況が変わってきました。1.2mというサイズは、人間の環境に合わせて設計されたスケールですね。20カ国以上への出荷はメーカー側の主張ですが、キットが実際に手に届く価格帯にあることは、そのものが意味を持ってます。

悠真: D270とAsimov 1、並べると「AIが動く場所」が広がってるのが見えます。推論ハードウェアが身近な場所に来て、ロボットの身体が手に入る。ここまで来ると、AIはブラウザの中だけでなく、物理世界でも動くものになってきてる。

葵: そして最後は、実験とコミュニティの話です。開発者主導の新しい形、という締めのテーマですね。

悠真: まずTiny Little Office。Paul Fordが作った10個のアプリ群で、ドキュメントが完全にURLハッシュ内に存在するんです。アカウントもサーバーも不要。オープンソースです。

葵: URLハッシュ、つまり#以降の部分に文書データが全部入る。ブラウザがサーバーに送らない部分にデータが住んでるんです。だから保存もない、同期もない、認証もない。単純にURLを共有すれば文書が渡る。

悠真: 実用性というより思想のプロダクトですよね。クラウドに全部預ける今の流れに対して、「文書はURLだけで足りるんじゃないか」という問いを形にしてる。Paul Fordというのは、開発者コミュニティで有名な方ですから、この選択は意図的です。どこまで実用的かは人によるでしょうけど、アプローチとしては純粋に面白い。

葵: そして/dev/null。Nuno Maduro、Brent Roose、Matthieu Napoli、Pauline Vosの四人が、48時間のライブ配信で作った開発者向けのSNSです。GitHubサインインで、オープンソースで、PRは配信中にマージされる。

悠真: これ、プロダクトそのものより、作り方の実験として見るべきです。48時間でSNSを作る、しかも全部ライブ配信で、コミュニティから来たPRを画面上でマージしていく。開発プロセス自体がショーになっている。

葵: そして出来上がったものがGitHubサインインの開発者SNSという、使う人と作った人とコミュニティが一致してる構造。作ったものも、作り方も、両方コミュニティに開かれてるんですよね。

悠真: 最後がToDo.is。研究、ファイル、Webサイトの作業などを実行する24時間稼働のAIエージェントで、Web、WhatsApp、Telegramから使えます。リスクのある操作の前には確認を取るというのも特徴です。

葵: この「リスクのある操作の前に確認」というのは、エージェント設計の原則として重要です。24時間稼働で作業を進めるなら、どこまで勝手にやるかの線引きが必要になる。ToDo.isはその線を明示的に持ってる。

悠真: 今日の最後の三つ、Tiny Little Office、/dev/null、ToDo.is、締めとして並べるといい対比です。Tiny Little Officeはサーバーを捨てる実験、/dev/nullは開発プロセス自体を実験にしてる、ToDo.isは実験の成果が日常の自動化として戻ってきてる。開発者主導の新しい形というのが、それぞれの層で現れてるんですよね。

葵: というわけで今日は、AIに文脈を渡す基盤から始まって、エージェントの実行基盤と作業場、開発者の日常ツール、チャット型のAI、動画生成、ハードウェア、そしてコミュニティの実験までを一気に見ました。

悠真: 全体を通して言えるのは、AIを「使う」からAIに「仕事をさせる」への移行期で、各層の土台が急速に整ってきてる、ということです。文脈、コスト、ツール、作業場、フィードバック。まだ全部が揃ったわけじゃなくて、どれもこれからの検証次第の部分があります。

葵: 今日取り上げた数字や特徴は、メーカー側の主張をそのまま紹介したものです。実際に試すか、コミュニティの検証が出てくるか、その時はじめて本当の評価ができるものばかりですね。

悠真: それでは今日はこのへんで。また明日もよろしくお願いします。

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