1015 | AIニュース速報：ベンチマークからエージェント記憶まで

葵: 皆さんこんにちは、葵です。

悠真: 悠真です。今日も一日のプロダクト情報をギュッとまとめてお届けします。今回持ってきたのは、ベンチマークで戦う新しいモデルたち、エージェントの「記憶」をめぐる基盤、そして開発ツールからマーケティング、ハードウェア、生活アプリまで、幅広いラインナップなんですが。

葵: 共通して言えるのは、AIが「デモ段階」から「実際に使える段階」へ移ろうとしている、っていう空気感ですよね。性能の数字が出て、その数字が実運用でどう生きるか、という話が各所で進んでいる。

悠真: じゃあ、まずは性能の競争から始めましょう。

葵: はい。まず取り上げるのは、Nimble-v4とv4-maxという意思決定モデルです。Decision Indexという指標で、これまでのJev 1.13を上回りました。特にv4-maxはトップスコアが68.46で、パラメータ数は27Bとされています。

悠真: 意思決定モデルというのは、コードを書くとか文章を書くというより、選択肢から判断するタスクに強みを出すタイプのモデルですね。Decision Indexで首位というのは、そういう判断タスクの評価で追い抜いた、ということです。

葵: ここで大事なのは、これはベンチマーク上の話だ、という点です。ベンチマークのスコアと、実際の運用で感じる性能は、必ずしも一致しない。これまでにも、テストでは強いのに現場では違和感がある、という話はいろいろなモデルで見てきました。

悠真: そうなんですよね。「次はこれらの実用性能が実運用でどう評価されるかが鍵」というのが正直なところで、スコアの首位は出発点であってゴールじゃない。

葵: では、コーディングエージェントの話に移りましょう。こちらも同様に、ベンチマークの数字が出ています。Reasonというエージェントが、Coding Agent Indexで65.1を記録して、Codexの62.5を上回りました。

悠真: Codexというのは、長らくコーディングエージェントの代表的な存在だったわけで、そこを0.6ポイントではあるけど上回った、というのは意味のあるシグナルです。しかも、キャッシュの最適化によって22%安く動かせる、とされています。

葵: この22%安い、というのが面白いポイントで。コーディングエージェントというのは、長時間動かすのでランニングコストが馬鹿にならない。性能が同じでもコストが2割下がるなら、実際に使う側にとっては大きな違いです。

悠真: 性能の数字とコストの数字、両方揃っているところが、実運用を意識した訴え方だなと。ただ、ここでも「65.1」という数字が何の条件で計測されたものか、自分の使うコードベースで再現できるかは、使ってみないと分からない。

葵: そうですね。スコアの競争は激化していますが、自分の環境で同じことが起きるかは別問題。これはNimble-v4の話と同じで、ベンチマークの首位と実運用の評価の間にはギャップがありうる、という前提で見ておくべきです。

悠真: そして、同じく性能の話で、もうひとつ別のカテゴリーのものを。TTS、つまり音声合成です。Kugel 3.5というTTSが、9つのテストのうち8つで、4社の競合を上回ったとされています。

葵: TTSの競争も面白いですよ。特に注目したいのは「長い数字の読み上げが97.1%正確」という点です。長い数字というのは、音声合成が昔から苦としてきた領域で。電話番号や金額、注文番号のようなものを読むときに、桁を飛ばしたり読み方を間違えたりする。

悠真: それが97.1%という数字で信頼性を主張している。あと、IPA対応も書かれていますね。これは発音記号で読み方を細かく指定できる、ということです。固有名詞や専門用語の読みを制御したい人には大事な機能です。

葵: 価格は5.25¢/分。ミニット単位の課金なので、使った分だけ、というシンプルな設定です。音声エージェントや自動応答システムを作る人にとっては、ここが直接コストに響く。

悠真: ここで一つの構造が見えてきます。Nimble-v4も、Reasonも、Kugel 3.5も、全部「競合と比べてこう上回った」という数字で語られている。つまり業界全体が、性能の比較を公然と行うフェーズに入っている。

葵: そして面白いのは、その比較の領域がバラバラだということです。意思決定、コーディング、音声。共通しているのは「何かのタスクにおける性能を、数字で示して勝負する」という流れです。ただし数字は主張であって、検証結果がすぐに追従するとは限らない。これが次のフェーズでどう検証されていくかが見どころです。

悠真: そして、性能競争がここまで進んだ結果、次の課題がはっきりしてきました。エージェントを支える「記憶」の基盤です。

葵: これが今日の二つ目の大きなテーマです。まずHindsight 1.0から。これはオープンソースでMITライセンスのエージェント記憶システムで、Agent Memory Benchmarkで1位を取ったとされています。

悠真: 1億件の記憶をp99で100ミリ秒未満で処理できる、と主張しています。この数字はなかなか大胆です。1億件って、個人ユーザーの規模を全然超えている。エンタープライズ規模での利用を想定したアーキテクチャだということが伝わってきます。

葵: その裏側にはMemlakeというRust製のエンジンがある、とされています。Rustで書かれているのは、速度とメモリ効率を重視している、という技術選択の表れでしょう。

悠真: MITライセンスのオープンソースという点も大事です。誰でもソースを見て、自分の環境に組み込める。閉じた商用サービスではなく、インフラとして普及させる狙いが見えます。

葵: 一方で、「Agent Memory Benchmarkで1位」というのも、先ほどのモデルの話と同じく、ベンチマーク上の主張です。実際に自分のエージェントに組み込んだときに、記憶の精度や検索の質がどうなるかは、別に確認が必要です。ベンチマークが測るものと、実運用で大切なものが完全に一致するとは限らない。

悠真: そう。そして、Hindsightのような「記憶の基盤」が出てきた背景には、別の問題意識があります。それは、記憶がツールごとに分断されている、ということです。

葵: そこで登場するのがMake0 Brainです。これはChatGPT、Claude、Cursorといった、複数のツールの間で記憶を共有するためのものです。MCP、つまりModel Context Protocolを経由して記憶をつなぎます。

悠真: 会話の取り込みが約2分でできる、とされていて、オープンベータで無料とされています。つまり「今使っている各ツールがそれぞれ別々の記憶を持っていて、そのたびに同じことを説明し直す」というストレスを、一つの記憶層で解消しよう、という発想です。

葵: これはなかなか実用的な問題への答えです。今、多くの人が、作業によってClaudeを使ったり、ChatGPTを使ったり、Cursorでコードを書いたり、と使い分けている。でも、それぞれのツールは独立していて、一つで会話した内容が別のツールには引き継がれない。

悠真: MCPがこのあたりの標準になりつつある、という流れを感じます。MCP経由で記憶がつながれば、ツールを乗り換えるコストも下がるし、エージェント間の連携も進む。記憶の共有が次の競争軸になりつつある、というのは説得力のある見立てです。

葵: ここで、周辺のツールも見ておきたいです。daily.dev for agentsというのも出ています。これはMCPでClaude、Cursor、Codexに、フィードや検索、ブックマークへのアクセスを提供するものです。プラグインマーケットプレイスとAPIもある、とされています。

悠真: ニュースフィードやブックマークというのは、個人の知的なコンテキストですね。エージェントがそれにアクセスできると、単なる質問応答ツールから「自分の関心を理解している相棒」に近づく。これも記憶と文脈を共有する流れの一環です。

葵: あと、InferockというLLM推論のプロキシも、この文脈で出てきます。これは推論への呼び出しを仲介して、失敗した呼び出しに対して「レシート」を発行するというものです。検証済みの失敗に対しては、クレジットを返すとされています。Watchという機能は、自分のキーを使って無料で使える。

悠真: これは推論の失敗という、通常は黙って損をする出来事を、明示的で検証可能な形にする、という発想ですね。エージェントが大量のAPI呼び出しをすると、失敗が頻繁に起こる。それがどこで、なぜ失敗したのか、そして補償されるのか、というのを可視化する仕組みです。

葵: Pancakeという「GTMのためのVercel」と称するものも、MCPでエージェントにGTM Brain、つまりGTMのための知識層を与える、40以上のデータプロバイダ、送信インフラを提供する、とされています。5月に1位を取って、再構築されたとされています。

悠真: Pancakeはマーケティングの話で後でまた触れますが、ここで言いたいのは、MCPという仕組みが、単なる技術仕様を超えて、エージェントに外の世界への接続口を与える共通言語になりつつある、ということです。記憶、フィード、GTMの知識、推論の呼び出し。全部MCPでつながる。

葵: そう、記憶の共有、データの共有、ツールの共有。MCPを軸にして、エージェントの周辺に共通の基盤ができつつある。これは数ヶ月前までは、各ベンダーが独自にやっていてバラバラだったことです。

悠真: そして、この基盤を実際に使うのはエージェントたちです。その開発環境がどう強化されているか、というのが三つ目のテーマです。

葵: はい。開発ツールの話です。まずExodusから。これは無料のオープンソースツールで、コーディングエージェントがアプリをCloud Runに移行するのを助けるものです。50以上のプレイブックが用意されていて、コストレポートも出せるとされています。

悠真: プレイブックというのは、移行手順をあらかじめ定義しておく、というものです。レガシーな環境からCloud Runへの移行は、一つ一つのアプリで手順が違うから難しい。50以上のプレイブックがあるということは、よくあるパターンは既に網羅されている、という主張です。

葵: そして、コストレポートも出せる。これは実運用を意識している証拠です。移行しただけでなく、そのあとどれくらいコストがかかるか、というのが見える化される。

悠真: 次にEditUI。これはChromeの拡張で、UIの要素を指差して、Claude CodeやCursorに対して一括で指示を出せる、というものです。無料で、サインアップも不要とされています。

葵: これはちょっと体験として面白いですよ。普段、UIを直したいときに、「あのボタンをもうちょっと大きくして」とか「ここのラベルを変えて」とか、言葉で説明するしかなかった。でも、Chrome拡張で要素を直接指差せるなら、指示の曖昧さが減る。

悠真: 一括で指示できる、というのもポイントです。複数の修正を一度に投げられるのは、開発の流れを止めないという意味で効率的です。無料でサインアップ不要というのも、ハードルの低さが特徴的ですね。

葵: ここから、開発者体験を自動化する関連ツールが一気に出てきます。Epheremというのは、AIで作られたアプリを対象とした無料のセキュリティスキャナです。ZIPやGitHubからスキャンできて、Claude Code、Cursor、Lovableに向けた修正プロンプトを生成してくれます。

悠真: これが面白いのは、セキュリティスキャンの結果を、そのままコーディングエージェントに食わせるプロンプトに変換する、というところです。脆弱性を「見つける」だけじゃなくて、「直す」ための流れに接続している。

葵: LegacyFixerは、GitHubのアプリで、Pythonの依存関係をスキャンして脆弱性を見つけ、自分の検証を通った場合にのみPRを自動で開きます。

悠真: 「自分の検証を通った場合にのみ」というのが重要です。単にPRを乱発するのではなく、検証をクリアしたものだけを出す。これは自動化の乱暴さを制御しようという意図が見えます。

葵: Tidenは、コードエージェントのための「意図の検証」ツールです。スペックをバージョン管理して、実際のテストの結果から検証を下す。AIが判断するのではなく、実テストで判断する、とされています。

悠真: これはかなり本質的な話です。エージェントがコードを書いたときに、「ちゃんと意図したとおりに動いているか」をどう確認するか。AIに「これで大丈夫?」と聞くのは信用できない。実テストが通るかどうかで判定する、というのは、より客観的な検証方法です。

葵: WriterzRoomは、LangGraphの8つのエージェントとQuality Gateを使ったマルチエージェントプラットフォームで、Cloud Runの9つのサービスで100%サーバーレスで動く、とされています。

悠真: マルチエージェントをLangGraphで組んで、Quality Gateで品質を担保する。そしてインフラとしては完全にサーバーレス、という構成ですね。Cloud Runで9つのサービスというのは、わりと具体的なアーキテクチャです。

葵: Specreelは、Playwrightのトレースから、あるいはURLクロールからデモを作って、緑のビルド、つまり成功したビルドのときに再公開する、というものです。これによってデモが古くなってしまう問題を防ぐ、とされています。

悠真: デモが古くなる、というのはデベロッパー全員が経験したことのある痛みです。プロダクトが更新されてもデモが放置される。Specreelは、デモを「静的な映像」ではなく「ビルドの結果から自動生成されるもの」に変える発想です。

葵: Retriever AIは、無料のブラウザエージェントで、リード獲得やアウトリーチ、求人応募などができる、とされています。Web Benchで81.4%というスコアを主張していて、競合より5倍速くて300倍安い、とされています。

悠真: 300倍安い、という数字はかなり大胆ですね。これは主張であって、どういう条件で比較したのかは分からない。ただ、ブラウザを操作するエージェントがコストと速度で競うようになった、というのは、この分野が実用化フェーズに入っている証拠です。

葵: そしてAirJelly。これはデスクトップのAIエージェントで、画面の文脈を見ていて、自動的にタスクを作成したり、リマインダーを送ったりするものです。MacとWindowsで無料とされています。

悠真: 画面の文脈を見る、というのは、プライバシー的には要注意な領域です。何を見ているかをエージェントに見せる、ということになるから。そのうえで、自動でタスクを作る、というのは、デスクトップ作業の傍らで常に動いている相棒、という感じですね。

葵: この一連のツールを見ると、開発者体験の自動化が急速に成熟していることが分かります。セキュリティスキャン、依存関係の修正、テストによる検証、マルチエージェントのオーケストレーション、デモの自動更新、画面文脈の監視。それぞれが開発ライフサイクルの異なる部分をカバーしています。

悠真: しかも、無料やオープンソースのものが多い。Exodus、EditUI、Epherem、AirJelly、Retriever AI。ここでコストをかけて勝負するよりも、まず普及させて、周辺にエコシステムを作ろう、という動きに見えます。

葵: そして、開発が自動化されてくると、次はその成果物をどう「売る」か、つまりビジネス側の自動化に話が進みます。

悠真: 四つ目のテーマです。AdAnt 2.0から。これは24時間体制のAIマーケティングチームを提供するもので、Strategist、Creator、Analyst、Managerの4つのエージェントでSNSのマーケティングをするとされています。40の無料クレジットがあります。

葵: 4つの役割が揃っているのがポイントですね。戦略を立てる人、コンテンツを作る人、効果を分析する人、実際に運営する人。人間のマーケティングチームの構造をそのままエージェントに写している。つまり、「AIが一つのタスクを代行する」から「AIがチームとして動く」へ、という進化を意識している。

悠真: 40の無料クレジットは、試しやすい設定です。マーケティングというのは、成果が出るまで時間がかかる領域なので、まず試してみて、その質が見えるかどうかが採用の分かれ目になるでしょう。

葵: 一方でBladeというのは、ちょっと発想が違うアプローチです。これはメールから連絡先をマイニングするもので、しかも本文ではなくヘッダーだけを見る、とされています。KAYAKの共同創業者が手がけていて、30日無料とされています。

悠真: ヘッダーだけを見る、というのが知的な点です。メールの本文を読むと、プライバシーと機密の問題が大きい。でもヘッダー、つまり誰が誰に送ったか、というメタデータだけなら、連絡先ネットワークが分かってプライバシーのリスクは少ない。

葵: ローンチ、つまり新製品の告知のために連絡先を集める、というユースケースです。KAYAKの共同創業者ということで、トラベルの巨大サービスを立ち上げた経験がある人の、リリース時の連絡先収集の痛みから生まれたものなのでしょう。これは推測ですが。

悠真: そして、Pancakeに戻ります。さっきMCPの話で触れたんですが、これは「GTMのためのVercel」という位置づけで、エージェントにGTM Brainを与え、40以上のデータプロバイダと送信インフラをMCP経由で提供します。

葵: Vercelに例えるのが面白いところです。Vercelが開発者のデプロイを楽にしたように、PancakeはGTM、つまりGo-to-Market、市場に出るまでのプロセスを楽にしようとしている。GTM Brainというのは、GTMのための知識と文脈の層でしょう。

悠真: Confidence by Spotifyも、この流れで重要です。これはwarehouseネイティブの実験プラットフォームで、A/Bテスト、フィーチャーフラグ、セッションリプレイを提供します。無料で始められるとされています。

葵: warehouseネイティブというのが肝です。A/Bテストのデータを、別の分析環境にコピーせず、データウェアハウスの中で直接扱う。つまり、実験のデータと、普段の分析データが同じ場所にある。これによって、分析の文脈が途切れない。

悠真: Spotify自身が大規模な実験をしている会社ですから、そのノウハウが反映されたプラットフォーム、という位置づけですね。無料で始められるのは、Spotifyがこの分野に普及させたい、という意図の表れでしょう。

葵: これらのツールを見ると、マーケティングとGTMも、開発と同じように「エージェントが作業を引き受ける」フェーズに入りつつあります。開発ではエージェントがコードを書く。マーケティングでは、エージェントが戦略を立ててコンテンツを作って分析する。同じ構造の変化が、別の領域で起きている。

悠真: そして、これらのソフトウェア的な進化の下にあって、それを支えるハードウェアの進化がある、というのが五つ目のテーマです。

葵: まずMicrosoft Ma 300から。これは次世代のAI推論チップで、2027年に量産予定とされています。トークン/MW、つまり電力1メガワットあたりで処理できるトークン数が40%増えると主張しています。96個のアクセラレータをラックに組み込む構成です。

悠真: トークン/MWという指標が鍵です。AI推論の運用コストの大部分は電力です。同じ電力で40%多くのトークンを処理できるなら、推論コストが実質的に下がる、ということです。先ほどReasonが「キャッシュ最適化で22%安い」という話がありましたが、ハード側でも効率の競争が進んでいる。

葵: 2027年量産というのは、まだ先の話です。つまり、これは現在の推論コスト問題を、2年後ぐらいに解決しようという計画です。それまでの間は、ソフトウェア側、つまりキャッシュやモデルの選択で効率化するしかない。だからReasonのようなソフト側の工夫が今重要なわけです。

悠真: 96アクセラレータのラック構成というのは、データセンター単位での設計ですね。単体のチップ性能だけでなく、ラックとしてどう電力効率を出すか、というレベルでの最適化です。

葵: 一方でAppleの話。HomePod mini 2です。149ドルで、Sound Glowという光の演出機能を搭載して、MacやApple TVとの統合が強化されています。

悠真: 149ドルというのは、前のモデルと同水準か近い価格帯でしょう。HomePod miniは、手軽にAppleのスマートスピーカー体験に入れる、というのが存在意義です。

葵: ただ、重要な留保があります。Siri AI、つまりAIが強化されたSiriは、出荷時には入っていない。将来のアップデートで提供される、とされています。

悠真: これは正直な情報公開ですが、買い手としては悩ましいところです。「AIスピーカーとして買うけど、AIの部分はまだ来ない」ということだから。ハードを先に出して、ソフトのアップデートで引き上げる、というAppleの戦略が見えます。

葵: 先ほどのMicrosoftの2027年量産と似た構造です。ハードとソフトの進化のタイミングは必ずしも一致しない。でも、長い目で見ると、ハードの進化がアプリ体験を引き上げる方向に進んでいる、というのが大局的な読みです。

悠真: 周辺のものも触れておきましょう。Winqというのは、macOSでカメラを使ったハンズフリー操作を可能にするものです。注視でフォーカスを合わせて、片目のウィンクでクリック、11種類のジェスチャーに対応して、プライバシーはオンデバイスで処理されるとされています。

葵: オンデバイス処理というのがポイントですね。カメラの映像をクラウドに送らずにローカルで処理する、というのは、手や顔の動きというセンシティブなデータを扱うからこそ大事な設計です。

悠真: Ramboxの再設計も、デスクトップの作業環境の話です。Command Center、Unified Search、内部タブ、そしてアカウントとコンテキストを分けるワークスペース、という機能が加わっています。

葵: Ramboxは複数のアプリを一つの窓にまとめるタイプのツールですから、アカウントの管理や検索の体験が使い勝手を決めます。ワークスペースでコンテキストを分けられる、というのは、仕事とプライベートを切り替えたい人には効く機能でしょう。

悠真: ハードとデスクトップ体験の話が出たので、最後に、毎日の暮らしに直接入ってくるAIアプリの話をしましょう。

葵: 六つ目のテーマです。まずMira Tours。これはAIの徒歩音声ガイドアプリです。チャットでツアーを作ったり、自動生成のツアーを使ったりできて、23の言語に対応しています。無料の30分があり、そのあとは従量課金です。

悠真: チャットでツアーを作れる、というのが新しい点です。「この街の美術館を巡りたい」とか「食べ物屋台の历史を知りたい」とか、その場でリクエストすると、ツアーが作られる。従来のガイドアプリは、あらかじめ用意されたコースから選ぶ形でした。

葵: 23言語というのは、観光客の多様性に対応していますね。無料の30分で試して、そのあと従量課金、というのは、旅行という「たまにしか使わない」ユースケースに合った課金設計です。月額制だと、旅行のたびに契約するのは割に合わない。

悠真: 一方でScreenwellというのは、採用の話です。LunaというAIの面接官が、Google MeetやTeamsで一次面接を行い、ランキング付きのスコアカードを生成します。30以上の言語に対応して、14日間無料とされています。

葵: 一次面接をAIに任せる、というのは、採用の初期段階のボトルネックを解消する発想です。応募者の数が多いとき、一次面接だけで膨大な時間がかかる。Lunaがそれを担って、スコアカードで候補者をランキングする、とされています。

悠真: ただ、ここには考えなければいけない点もあります。AIが人の採用の第一関門を判断する、というのは、応募者側から見ると、自分のキャリアの可能性をAIに委ねる、ということでもある。 MeetやTeamsという既存のビデオツールで動く、というのは、応募者には新しいツールをインストールさせない配慮とも取れますが、AI面接そのものへの心理的な受け止め方は人によって分かれるでしょう。

葵: それはこの種のサービスが今後、社会的な議論を経て広がっていく領域だと思います。30言語対応は、グローバルな採用での言語の壁を下げるという実用的な利点です。

悠真: そしてTable Canon。これはTTRPG、テーブルトークRPGのゲーム夜の音声を処理するものです。リキャップと、エンティティの資料を作って、検索可能な履歴にしてくれます。6時間無料とされています。

葵: TTRPGというのは、セッションが長くて、登場人物や出来事が複雑になる趣味です。前回のセッションで何があったか、あのNPCの名前は何だったか、というのを毎回思い出すのが大変。それを自動でリキャップして、キャラクターや場所の資料にまとめて、検索できるようにする。

悠真: これは趣味の領域のニッチなツールですが、ニッチなほど「これがなかったら困る」度合いが強い。コミュニティへの刺さり方が鋭いでしょう。6時間無料というのは、複数回のセッションを試せるくらいの余裕です。

葵: この周辺にも、日常や仕事のツールの刷新があります。Cloud Releasesというのは、AWS、Azure、GCP、Cloudflareの更新をまとめた一つのフィードです。700以上のサービスをカバーして、廃止予定のものを目立たせて、無料とされています。

悠真: これは、複数のクラウドを使っているチームには実用的なものです。各クラウドの更新情報は、それぞれ別の場所にあって、しかも大量にある。それを一つのフィードにまとめて、しかも廃止予定を見える化する、というのは、インフラのチームにとっては地味に重要なことです。

葵: NoteHouseは、プライベートローンのためのソフトウェアです。貸借の内容から、法定文書である貸借証書的なものを作り、電子署名ができて、複数人で共有できる会計も持っています。

悠真: これは、個人の貸し借りの記録を「あいまいな約束」から「文書化されたもの」に変える、というものですね。親族間や友人間の貸し借りは、トラブルになりやすい。文書化と電子署名で、両者が同意した内容を残せる。

葵: これらのツールを通して見えるのは、AIが実用と娯楽の両面で日常に入り込んできている、ということです。観光のガイド、採用の面接、ゲームの記録、貸し借りの管理、クラウドの更新情報の追跡。どれも「毎日使うものではないかもしれないけど、必要なときに強く効く」タイプのものです。

悠真: 今日の全体を振り返ると、一つの流れが見えます。まず、Nimble-v4、Reason、Kugel 3.5のようなモデルの性能競争が進んだ。その結果、エージェントがより実用的になって、記憶を持ちたい、という要求が生まれた。HindsightやMake0 Brainがそれに応えた。

葵: そして、エージェントを支える開発ツールが整備されて、ExodusやEditUI、Epherem、Tidenのようなものが開発ライフサイクルの各段階を自動化した。開発が速くなると、次はマーケティングやGTMが自動化の対象になり、AdAntやBlade、Pancakeがそこに入ってきた。

悠真: そして全部を支えるのが、Ma 300のようなハードウェアの進化と、HomePod mini 2のような身近なデバイスの進化。そして最後に、Mira Tours、Screenwell、Table Canonのような、生活の具体的な場面に入っていくアプリ。

葵: 一つの縦の流れとして、モデルから基盤、開発、ビジネス、ハード、生活まで、AIが階層的に広がっている、という構図です。まだ各段階で「主張」と「実証」の間にはギャップがあります。ベンチマークのスコアや、コスト削減の数字は、あくまで提供側の主張です。それが実際の運用でどう評価されるか、というのが今後の見どころです。

悠真: はい。では今日はこの辺で。聞いてくれてありがとうございました。

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