0910 | 今週のAI新製品ガイド：エージェントから黙々と働く開発現場まで

葵: こんにちは、葵です。悠真さん、今日も一日分のプロダクトハント、ざっと見ましたね。

悠真: 悠真です。見ました。今日のラインナップは傾向がはっきりしていて、軸は「エージェント」でした。コードを書かせるエージェントをどう工場のように回すか、どう安全にするか、そして製品そのものをエージェント対応にするにはどうするか。最後は個人向けAIと、ちょっとした大胆企画まで。

葵: 今日はその流れに沿って、よく絞った製品を順番に見ていきます。ひとつずつ、誰のための製品で、何が変わって、何がまだ分からないのかというところまで踏み込みますね。

悠真: ではまず、エージェントを「工場」として捉えた話から。Mastra Factoryというオープンソースのソフトウェア工場です。

葵: MastraはもともとTypeScriptのAIエージェントフレームワークなんですが、そのMastraが自分たちのエージェントでソフトウェア工場を作って、それをそのまま公開した形です。issueの受け付けから、トリアージ、計画、実装、プルリクエストのレビューまで、ライフサイクルの各段階をエージェントが担います。

悠真: すでに運用が進んでいるのも特徴で、チームは「工場が自社のプルリクエストの25%以上を書いている」と言っています。あるいは30%のPRを書き、60%のissueをクローズしているという発言もありました。ただ、これは作り手自身の数字なので、事実として検証されたものではなく、あくまで彼らの主張として聞くべきですね。

葵: そうですね。面白いのは、その後、Mastra自体もFactoryで開発されているという再帰的な構造で、「メタなことをするのが好きなんだ」というコメントもありました。技術的には、GitHubやLinear、Slackをつなげて、仕事がどう段階を進むかのルールを自分で定義します。段階ごとに明示的なゲートを置く設計で、変更が測定可能で可視的な形を保てるようにしているのが特徴です。

悠真: 完全にゴール駆動の監督エージェント方式とは違って、各段階にゲートがあるステージ型の自動化ですね。無料のStarterプランから、月250ドルのTeams、エンタープライズまで料金も出ています。観測イベントの量やCPU時間、データ保持期間でプランが分かれます。

葵: コミュニティからの質問で気になったのは、同じエージェントが複数ユーザーにまたがって使われるときのメモリの振る舞い、あと文脈を無期限に保持するのか、古いものは自動で切り詰められるのかという点。ここはまだ答えが明確には出ていないところです。

悠真: で、Mastra Factoryが「工場」側の話だとしたら、次は「工場を動かす人間側」の話。49agents IDEです。これは複数のコーディングエージェントを同時に走らせている開発者の、目の疲れる問題を解決しようとしています。

葵: 作った人は、15個以上のCLIエージェントを複数のリポジトリで同時に動かしていたら、どのターミナルが何をしていたか忘れて文脈の疲労に苦しんだ、という経緯を語っています。グリッド型のペインマネージャーには制限を感じて、自分用に作ったものを友人が気に入ってオープンソース化を勧めたそうです。

悠真: 解決策が面白くて、無限の2Dキャンバスに、エージェント、ターミナル、リポジトリ、マシンを全部、自分で配置するんです。都市を作るゲームのように。空間記憶の力を使っていて、ペインの相対位置と、そのタスクやプロジェクトの文脈を結びつけやすくなると。神経生物学の専門家ではないけど調べた限り、脳が記憶を周囲との関係で保持する仕組みと合っている、と説明しています。

葵: 機能面では、Claudeが動いているときはペインが青く光り、許可を求めるときは朱色で脈動する。複数マシンをつなげてそこにターミナルを開いたり、CPUとRAMのHUDを出したり、プライベートネットワークに置いてスマホからアクセスすることもできます。オープンソースで個人は無料、企業向けは有料という位置づけです。

悠真: コミュニティの反応も示唆的でした。「git diffをClaudeの隣に置いておける」という発見を喜ぶ人や、「問題はターミナルの多重化ではなく文脈の多重化で、8個もセッションが走るとタブタイトルが意味を失う。空間配置のほうが、このプロセスは何のためにあるのかをうまく表現できる」という声。あと、空間型のツールは30オブジェクトくらいで破綻しやすいから、使われてないものは勝手に縮む、減衰方式のほうが生き残るのでは、という指摘もありました。

葵: それから、「パンとズームで動き回るのも結局は疲労では。本当に大量の同時エージェントでテストしたのか、それとも5、6個が心地よいところなのか」という正直な疑問も。これ、まさにオープンな問題ですね。あと「CPU/RAMのテレメトリーは不要。ターミナルマネージャーにGrafanaのコスプレはしてほしくない」というユーモラスな要望もありました。

悠真: 工場とキャンバス、両方とも「複数のエージェントをどう管理し、どこまで任せるか」という同じ問いにぶつかっています。でも任せるなら、その任せ方に安全装置が要る。そこで自然に次の話、Hardenです。

葵: HardenのAIF、Agentic Integrity Foundationというのは、コーディングエージェント用のローカルで動くセキュリティ層です。ポストトレーニングした80億パラメータのモデルが、コマンド、ファイル編集、ツール呼び出し、外向きのリクエストを、実行前にチェックします。

悠真: 作り手のPushpakさんは「エージェントに手渡して離席して、戻ったら完成しているのが最高の日。全部のコマンドを神経質な親みたいに承認しているのが最悪の日」と語っていて、このベビーシッティングが任せられる仕事の量を上限にしている、と。 rm -rfを間違ったディレクトリで打つ、.envをチャットに貼る、本番にマイグレーションを流す、知らないドメインに顧客テーブルを送る。そういう話は誰にでもあるそうです。

葵: 特徴は、1つのアクションだけを止めて、エージェントは残りを続行できること。 secrets の漏洩、データの流出、破壊的なインフラ操作を実行前に検知して、一時停止するか、書き換えるか、ブロックするかを選びます。全部ローカルで動くので、リポジトリも文脈もツール出力も自分のマシンから出ません。Claude Code、Cursor、Codex、Hermes、OpenClaw、Kiro、Antigravityに対応して、個人開発者には無料です。

悠真: 具体的な事例も紹介されていました。Stripeのデバッグをエージェントに任せていたら、途中の編集ミスで顧客のメールアドレスが診断ファイルに混入していて、エージェントがそれをDatadogにアップロードしようとした瞬間を、AIFが過去の編集とファイルまで遡って関連づけて止めた、と。この話も作り手側の説明なので、そのまま信じるのではなく「こういうことを想定している」という趣旨で聞くのがいいですね。

葵: コミュニティの質問は鋭くて、「明らかに危険ではないけど、タスクの意図の外にあるアクションはどう扱うのか」「セキュリティ判断のとき、セッション全体を見るのか、現在のリクエストだけか」「ローカルモデルが長いセッションでツール呼び出しごとにどれだけ遅延を足すのか」「スクリプトの中身まで見るのか、それともツール呼び出しのレベルだけか」。この判定の粒度、まさに未知の領域です。

悠真: Hardenは「エージェントが見えない場所で危ないことをしない」ための保証でしたが、次のFrigade Assist APIは別の種類の見えなさを扱います。ユーザーのほうが、画面が見えないんです。

葵: チャット型の社内AI支援の多くは、ユーザーが「これどうやるの?」と聞いたときに、テキストの箇条書きの羅列を返してくる。画面が見えないからです。Frigade Assist APIは、既存のエージェントが1つのツールを呼ぶだけで、ページ上にステップバイステップのガイドを直接描画します。ガイドが作れないときは平文の回答をエージェントに手渡して、まったく助けられないときはそう伝えます。さらに、ユーザーが今何を見ているかもエージェントに教えるので、「このエラーは何?」の「これ」が指せるようになる。

悠真: 仕組みが巧妙で、テストアカウントを渡すとブラウザエージェントがログインして、アプリがどう動くかの地図を自分で作る。それをスケジュールで再実行するので、ボタンを動かしても新機能を出しても、いつでも最新に保たれる。Vercel AI SDKでも、ツールを呼べるものなら何でも動きます。

葵: CTOのChristianさんは「私が一番誇りにしているのは、製品をどう知っているかの部分」と言っています。過去1年、多くのチームがすでに自社のAIアシスタントを出荷していて、でもツール呼び出しはうまくいっても、ユーザーの状態の文脈がゼロで、古いヘルプセンターの内容を吐き出していた、という壁にぶつかっていたと。

悠真: コミュニティの指摘で一番本質的だったのは、「古くなったガイド」の問題です。ある人は「テキストの回答が古いなら気づける。でもポインタが古いと、自信満々に間違った場所をハイライトして、ユーザーは言われたとおりにしてしまう。画面上に示すというフレーミングは正しいけれど、UIの変化をどう検知するのか、ターゲットをその都度DOMから導出するのか、保存されたセレクタなのかで、まったく別の製品になる」と。Frigade側は再学習を定期実行するとは説明していますが、ガイドが古くなった瞬間をどう検知するかは、まだ確定的には答えられていない印象です。

葵: あとは、テストアカウントから見えない領域、機能フラグや上位プランの画面はどうするのか、複数アカウントを走らせるのか、盲点を受け入れるのか、という質問もありました。ここも未知のままです。

悠真: ところで、このHardenとFrigade、どちらも「AIを信用して任せるための保証層」という似た位置づけですよね。Hardenは安全性の保証、Frigadeは使い方の支援の保証。では、もっと上の層、AI利用の運用そのものを引き受ける話に進みましょう。GoModelです。

葵: GoModelは、オープンソースのAIゲートウェイ。Goで書かれていて、1つのOpenAI互換APIで、31のプロバイダー、OpenAI、Anthropic、Gemini、Bedrock、Vertex、Azure、Groq、Ollama、vLLMなどをつなげます。約20MBのDockerイメージ、単一バイナリ、MITライセンス、キーは自分で持つ。OpenRouterやLiteLLMのセルフホスト代替、と位置づけています。

悠真: 作り手のJakubさんはワルシャワのソロファウンダーで、昨年10月、自社スタートアップでAIゲートウェイを使おうとしたとき、最初期のソリューションであるLiteLLMが、本番で説明のつかない500以上のissueを抱えて品質に問題があり、しかもプロキシ型のソフトウェアにはPythonが向いていないと感じて、自分で書き始めた、という経緯です。2025年12月からフルタイムで取り組んでいるそうです。

葵: 機能は充実していて、エイリアスでsmart-chatのような安定した名前を公開して、裏の実際のモデルを設定変更で差し替えられる。加重ラウンドロビンのロードバランスや、コストベースのルーティングで最も安い対応モデルを選ぶこともできる。利用可能性のエラーでは次のモデルやプロバイダーにフェイルオーバーして、リトライとバックオフ、サーキットブレーカーで不安定な上流を吸収します。

悠真: キャッシュの話も分かりやすい。同一のリクエストは完全一致の応答キャッシュで、2回目はタダで速く返せる。支出の計測も、プロバイダーのダッシュボードは合計しか見えないところを、リクエストとユーザーパスごとにチームやテナントへ紐づけて追跡します。スコープ付きのワークフローで、キャッシュ、監査、予算、ガードレール、フェイルオーバーをプロバイダーやモデルやパスごとに設定でき、ガードレールはディスパッチ前にシステムプロンプトを注入したりLLMでメッセージを書き換えたりもできる。

葵: コミュニティからの質問が具体的で、「OpenRouterを第一経路にして直接キーを後ろに置いているが、2つのモデルは直接キーがなくルーターが単一障害点になっている。セルフホストならモデルごとにフォールバック順を固定できるのか」「プロバイダーが完全に落ちているのではなく、レイテンシが上がっているだけの劣化状態ではどう動くのか、タイムアウトのしきい値を待つのか、エラー率にも反応するのか」。フェイルオーバーの判定条件、これはまだ明確な答えが出ていない未知の部分です。

悠真: GoModelが「アプリとプロバイダーの間」の層だとしたら、Noodle Seedはもう一歩進んでいて、「製品そのものをエージェント対応にする」ための基盤です。この2つは、どちらもAI利用の運用面、鍵、権限、監査を引き受ける位置づけだという共通点があります。

葵: Noodle Seedの共同創業者Fahdさんの話が印象的で、「MCPコネクタがないソフトウェアはもう買わない自分がいる。すべてのソフトがこれをテーブルステークスとして提供すべきだと思った」と。そして作り込むうちに、ソフトウェアをAIエージェントの中に持ち込むだけでなく、AIエージェントをソフトウェアの中に持ち込むこともできる、と気づいたと。

悠真: 具体的には、旅行サイトがウェブサイト上で会話形式で注文を受けたり、オンライン旅行代理店がChatGPT内で予約を受けたり、B2Bソフトウェアが社員のClaude内で直接取引可能になったり。これら全部が、MCPスキル、クレデンシャルブローカー、OAuth、レート制限といった同じ積み木でできている、という分析です。

葵: 技術的には、開発者がTypeScriptで能力を定義し、ローカルで無料で検証して、ガバナンスされたランタイムにデプロイする。アイデンティティ、権限、秘密情報、監査、運用はランタイムが担うので、チームは次のエージェントサーフェスのたびにそれらを再構築しなくて済む。顧客にブランドされたアシスタントを既存SaaSの中に置いて、同じワークフローをChatGPTやClaudeやCodexなどMCPクライアントにも展開できる。

悠真: 設計思想も面白くて、「サインアップの前に役に立つ」体験を重視しています。顧客がアカウント作成の前に有用な結果を得て、見直し済みのドラフトと会話を持ち越して、既存のサインインを経て、承認済みAPIで完結させる。システムオブレコードは自社の製品のまま、Noodle Seedはエージェントのアクセスを統制する、という構図です。

葵: コミュニティの質問も実務的でした。複雑な購入や予約フローにも対応できるのか、ブランドの表現について具体的なルールやガードレールをどこまで定義できるのか、そして「ブランドアプリは今日のChatGPTで実際にどう表面化されるのか、アプリストアに有機的発見はあるのか、それとも企業が自分の顧客をそこへ誘導するのか」。リードの計測も含めて、まだ決まっていない部分が多いです。

悠真: ここからちょっと雰囲気を変えて、個人に寄り添うAIの話。MetaのMuseです。

葵: MuseはMetaの個人AIエージェントで、「ゴールか日常のタスクを渡せば、残りは処理する」。金融、健康、買い物、大事な人たちへの連絡まで幅広く扱う、と説明されています。MetaのChatGPTやPoke.comへの大きな対抗手とみられていて、独自のメッセージ体験を同梱している点が話題になりました。WhatsAppが唯一の代替メッセージ統合として現状サポートされていて、Facebook Messengerはもう事実上終わりだ、というコメントもありました。

悠真: ただ、コミュニティの反応にはリアリスト的な声が目立ちました。「これって、既存のサービス群に自分のClaudeやChatGPTアカウントをつなぐのと何が違うの?」という素朴で鋭い質問。EUのサポート待ちという声も複数あって、今のところ利用可能地域は限られているようです。

葵: そして一番重い指摘が、「金融と健康は、ガードレールが最も少ないのではなく最も多いべきカテゴリだ。Museがあなたの代わりにお金を動かしたり何かを予約したりするとき、承認の流れはどうなっているのか。全部個別に確認されるのか、最初の数タスクの後に常時許可を得てしまうのか」。ここはまだ答えが出ていない、開かれた質問です。

悠真: 同じMeta、同じOpenAI界隈ということで、画像生成の話も。ChatGPT Images 2.5です。

葵: OpenAIの次世代画像モデルで、より鋭いディテール、速い生成、正確な編集が売りです。スケッチ、プロンプト、参照写真を、光り方や質感、一貫性の整った仕上がり画像に変える。生成レイテンシはImages 2.0比で最大50%低減し、マルチターン編集の信頼性と指示追従が強化されています。

悠真: 機能としては、ラフな絵を完成品画像にするスケッチ機能。ポスター、フライヤー、グッズ、商品写真のような形式のテンプレート。画像に直接コメントをつけて編集を指示できる。プロンプトを画像と一緒に共有できる。クリエイティブ、マーケティング、小売、メディア向けのAPIモデルもある。ChatGPT、ChatGPT Work、CodexのユーザーとAPI開発者が対象です。

葵: コミュニティは「マーケティングチームでgpt-image-2をよく使っているから2.5は助かる」という実感の声がありました。利用者が多いモデルの改善、という受け止めですね。

悠真: ここで、AIのアウトプットをどこまで信用するか、という共通の問いに移ります。その答えのひとつが、科学の世界で出ました。Google DeepMindのAlphaGenome Atlasです。

葵: これは規模感がすごくて、人間のゲノムで起きうるすべての一文字変異、90億通りを事前計算した、1ペタバイトのデータセットです。AlphaGenomeというAIの予測を全部計算しておいた、と。コーディング領域だけでなくノンコーディング領域も含めて、変異が生物学的プロセスにどう影響しうるかを調べられます。

悠真: しかも無料の視覚的なウェブインターフェースがあり、プログラマーでなくても使える。より深い研究にはAPIとAntigravityの統合もある。「AlphaFoldの瞬間のようだ」という声が多くのコメントで繰り返されました。

葵: ただ、コミュニティには冷静な指摘もあって、「みんな90億に反応しているけれど、この数字は達成というより問題に近い。ありうる一文字変異を全部事前計算すると、そのほとんどは構造的にノイズだ。どれが見る価値があるかを見極めることは、最初から難しい部分だった」と。ここが本当の難所ですね。

悠真: あと、「予測の正確さは変異のタイプによってどうなのか」「遺伝子調節などの生物学的プロセスへの影響まで見られるのか」「研究者はどのくらい速くデータセットを探索できるのか」「変異を並べて比較できるのか」といった実務的な質問もありました。予測精度は、まだ開かれた問いです。

葵: 科学ではAIの予測を検証しにくい。でも、別の場所では検証がビジネスそのものになっている話がありました。WorkID.aiです。

悠真: これは、AIで偽装CVが量産される時代の、採用の信頼を回復しようというプロダクト。創業者のThorさんはテック採用に25年以上携わってきた人で、昨今の2年でその世界が壊れた、と語ります。AIによって、あらゆる場所に無料で応募でき、書類上で誰にでもなれるようになった。リクルーターは300件の応募パイプラインを開き、その多くが生成物で、存在しない人もいる。Gartnerは2028年までに候補者プロファイルの4分の1が偽物になると予想しています。

葵: Thorさんの本音がいいです。「問題なのは不正そのものじゃなくて、正直な候補者への影響なんだ。リクルーターが誰が本物か判別できなくなると、注意深く読むのをやめて、過酷にフィルタリングし始める。良い人がただの山に埋もれて、断りのメールすら届かなくなる」。だからCVの対極として、身元と職歴を検証済みのプロファイルを作りました。会社は検証済みのプロファイルを、Trust Scoreと一緒に見て検索やフィルタができる。候補者は一度証明すれば、プロセスのたびにゼロから始めなくていい。グローバルで展開中で、開始は無料です。

悠真: プロファイルには、信頼スコア、身元検証済み、職歴の各項目にVerifiedと表示される、というイメージがサイトで示されています。コミュニティの質問は当然というか、核心を突いていて、「どうやって雇用を実際に検証するの?」「スコアが100点満点で出ているが、その数字に何が入っているのか。もし自己申告のレジュメデータにいくつかのクロスチェックを足しただけなら、信頼の問題を解決しているのではなく、同じ自己主張に信頼ラベルを貼っているだけでは?」。ここはまだ明確な答えが出ていません。

葵: Thorさん自身が最後に投げた問いも重要で、「検証済みプロファイルがあれば、最初のスクリーニングコールを省略しますか?それがリクルーターに求める取引ですが、まだ線がどこにあるのか分からない」と。科学の予測も採用のスコアも、結局、その数字をどこまで信じて判断を任せるか、という同じ構造の問題なんですよね。

悠真: そう、AIで増えた不確実性を、検証で引き戻す。この2つはその点でつながっています。

葵: さて、今日の最後は、ちょっと空気を変えて、大胆な企画ふたつ。どちらも「注目の経済学」を冗談の形で実装した例です。

悠真: ひとつ目はAss Auction。ボクサーのロゴ枠を競売にする、最小の広告ネットワークです。サイトの説明をそのまま読むと「Ass Auction。私のお尻に、あなたのロゴを」と。

葵: 仕組みが面白いんです。5ドル以上払うと、あなたのロゴがリーダーボードに、その金額で買える順位で入ります。誰でもより多く払ってあなたを下に押し下げられる。合計支出額がそのまま順位なので、上位に戻るには差額だけ払えばいい。上位22位までがボクサーに刷られる。アカウント不要で、URLかXハンドルと、Stripeだけ。

悠真: 冗談に聞こえますが、設計は意外と真面目で、順位は決して保存されず、毎回実際の支払いから再計算される。だから偽装はできない。押し下げられたら通知メールが来る。チャットは「Gossip」と呼ばれていて、言うなればそのまんま。ボクサーを下ろすと小さなご褒美が待っている、これ以上は語らない、と。あと、回収されたお金は返金されない、それがビジネスモデルの全てだ、とサイトにも書いてあります。まあ、このサイト自体が楽しそうなのがいい。

葵: もうひとつはDuckFightClub。これはポールン・ロボティクスのMicroDuckという25センチのオープンソース二足歩行ロボットの話から始まっています。Hugging FaceとPollenが発表して、数日で1万台以上の事前予約があったそうなんですが、ただのクラファンで終わらせず、シミュレータと完全な学習環境を先に出荷した。だからロボットが届く前に、すでに仮想のダックに動きを教え始められる。

悠真: そのシミュレータの中で、誰かがロボット同士を相撲で戦わせるモデルを訓練しているのを見つけた人がいて、そこからDuckFightClubが生まれました。8チームが強化学習のポリシーを訓練し、シミュレータで戦って、Golden Beak Belt、黄金のくちばしベルトを懸けて戦う。生配信付き。10月2日のQuackDownというメインカードに向けて、登録、チーム発表、模擬戦、ポリシー凍結、ブラケット公開というスケジュールが組まれています。

葵: 細部も凝っていて、ロボットは25センチの同じダックで、差をつけるのはポリシーだけ。「生まれは可愛い、シミュで鍛えられ、相撲場に送られる」というコピー。リングは円形で、ハードで高コントラストな縁。同じ出現位置と同じ物理で、公平で再現可能な試合にする。3回戦勝ち抜きで、リングから押し出されたり転んだりした方が負け。

悠真: ワールドレスリング的な演出も本格的で、マット中央やエプロン、背面マーキーといったスポンサー枠が用意されていて、マット中央は2000ドルから、背面のネーミングパートナーは15000ドルから。Stanford vs Berkeleyの「Battle of the Nerds」がサイドカードとして組まれるのも、ローカル大会を各地で開く「チャプター」という仕組みも含めて、競技フォーマットとしてちゃんと設計されているんですよね。

葵: コミュニティの質問で、強化学習をやっている人から「ポリシーは毎大会ゼロから訓練するのか、それともチームはシーズンをまたいでダックを持ち込んでファインチューニングできるのか」という実質的な問いがありました。ここは答えが出ていない点としては大事です。あと、「最初のルールがそれについて話すななのに生配信する」という、原典への大胆な解釈をからかうコメントが複数あって、ああいう空気も含めてこの企画の一部ですね。

悠真: ふたつとも、注目という資産を、競売かトーナメントか、という数値で扱う形にした、という共通点があります。で、今日の最後の話題、広告データの見え方の話に自然とつながっていく。

葵: AdScopeです。これはMetaとGoogleの広告データを1つのダッシュボードに統合する読み取り専用のレポーティングツールで、10日間のトライアル、その後月額9.99ドルが12ヶ月固定というローンチ価格です。TikTokは次の対応予定。

悠真: 売りは「5秒ルール」で、スマホを開けば何がうまくいっていて予算が安全かが分かる、というもの。ダッシュボードには、実行中のMetaの画像や動画広告そのものが、その広告の支出と成果の隣に並ぶ。「final-3-copy」という行名をデコードする代わりに、勝っているクリエイティブを認識できる、という。

葵: オンボーディングで、ECなのかリード獲得なのかビジネスの目的を定義すると、メインの概要がその指標に即座に適応する。キャンペーンレベルでも、キャンペーンタイプに応じて動的にデータが調整される。接続は既存のMetaとGoogleアカウントでログインするだけで、ピクセルもコードもデータマッピングも不要で、ダッシュボードは数秒で組み上がる。リードにもリアルタイムでアクセスできて、どの広告が獲ったかまで遡れます。

悠真: 共同創業者でCEOのOrenさんは15年の広告運営の経験から、マーケターと経営者の間の断絶を問題として設定しています。代理店は手動レポートに何時間もかけ、経営者は混乱するスプレッドシートを凝視しなくても、金がどこに行ったかを知りたい。AdScopeはその両方に効く、と。読み取り専用アクセスなので、キャンペーンを編集、一時停止、変更することは絶対にできない、という点も安全性として明示されています。

葵: コミュニティからのフィードバックは建設的で、ある人は「ホームページには『ダッシュボードが組み上がるまでカード不要』とあるのに、アカウント構造の取得の後にプラン選択画面に来た。つながったデータの一目が見たかった。接続アカウントとデータの鮮度と1つの実際のキャンペーンを示す小さな領収書があれば、組み上がったと実感できる」と、ユーザージャーニーの細かい指摘をしてくれました。

悠真: 一方で、手厳しい声もあって、「クリエイティブを指標の隣に出すのは目新しくない、大手プラットフォームはすでにやっている。MetaとGoogleの同じデータの上のきれいなUI以外の、実際の差別化は何なのか」。ここが一番の未知の部分ですね。差別化の輪郭はまだはっきりしない。

葵: で、AdScopeと並んで「見え方を改善する薄い層」という共通点でくくれるのが、Basedashの多言語対応です。Basedashはデータを扱うツールなんですが、今回、英語に加えてスペイン語、フランス語、ポルトガル語で使えるようになりました。

悠真: プロフィール設定から言語を選ぶと、インターフェース全体が即座に切り替わる。ページのリロードなし、フローの中断なし。選んだ言語だけがロードされるので、アプリのスピードを保ったまま、ダッシュボード、チャット、自動化、設定がすべて選んだ言語で解決される。好きなときに戻せる。Maxさんは「スイッチが、新しいセッションを始めるのではなく、設定を変える感覚になるように作った」と説明していて、スペイン語でダッシュボードを見て、チームメイトのためにフランス語にして、英語に戻る、という流れが切れないと。

葵: コミュニティの反応も温かくて、フランス語サポートのコメントがあった人、「一緒に働く何人かは母語のほうがよく考えられるのに、ソフトウェアがそうさせるから英語に切り替えている。この変更は遅すぎた、でも最高の意味で」。

悠真: ただ、技術的な指摘もあって、「AI生成のチャートやダッシュボードの出力、軸ラベルとか生成サマリーも言語が切り替わるのか、それとも今は静的なUIの外装だけ翻訳なのか」。そしてもっと本質的な指摘、「インターフェースが翻訳されて、データは翻訳されない。カラム名、列挙値、顧客自身の行はまだ英語だから、英語のスキーマの上のスペイン語UIは、英語のときより奇妙に読めるかもしれない」。ここも、まだ明確な答えが出ていない点です。

葵: さて、今日はこれで全体を一周しました。エージェントを工場として回す話から、その安全装置、運用基盤、個人向けAI、科学の検証、採用の検証、そして注目と仕事の見え方の話まで。

悠真: もう一度だけ確認しておくと、今日出てきた数字や成果、例えば「PRの25%以上を書く」とか「危険なツール呼び出しを49件ブロックした」といった話は、すべて作り手側の主張として聞いてもらうのが正しいです。コミュニティのコメントも、個人の経験や批判としては拾いましたが、賛同の多数決的な証拠としては使っていません。

葵: 明日のラインナップも見て、また同じ時間にお会いしましょう。それでは。

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