エピソード

  • 私立ずんだもん女学園放送部 podcast 20260213
    2026/02/12
    youtube版(スライド付き) 関連リンク Introducing Markdown for Agents インターネットのトラフィックが従来の検索エンジンからAIエージェントやAIクローラーへと急速に移行する中、CloudflareはWebサイトのコンテンツをAIが理解しやすい形式で提供する新機能「Markdown for Agents」を発表しました。 従来のWebサイトは人間が閲覧することを前提にHTMLで構築されていますが、AI(LLM)にとってHTMLは構造が複雑で、タグやスクリプトなどの「ノイズ」が多く含まれます。これらはLLMのトークンを無駄に消費し、コスト増や精度の低下を招く要因となっていました。例えば、あるブログ記事をHTMLのまま読み込むと約16,000トークン必要ですが、Markdownに変換すると約3,000トークンで済み、約80%ものトークン削減が可能になります。 「Markdown for Agents」は、HTTPの「コンテンツ・ネゴシエーション」という仕組みを利用しています。AIエージェントがリクエスト時に「Accept: text/markdown」というヘッダーを送信すると、CloudflareのネットワークがオリジナルのHTMLをリアルタイムでMarkdownに変換して返します。 新人エンジニアにとって注目すべきポイントは以下の通りです: トークン効率の最適化: 開発者は自分で変換ロジックを実装することなく、エッジ側で最適化された軽量なデータを受け取れます。レスポンスヘッダーには推定トークン数(x-markdown-tokens)も含まれるため、RAG(検索拡張生成)の実装時にコンテキストウィンドウの管理がしやすくなります。AI向けの意思表示: 「Content-Signal」ヘッダーを通じて、そのコンテンツをAIの学習や検索に利用してよいかというポリシーを明示できます。エージェント・ファーストの設計: これからのWeb開発は、人間のユーザーだけでなく、AIエージェントを「第一級の市民」として扱う設計(エージェント最適化)が重要になることを示唆しています。 現在はBeta版として、Cloudflareの特定のプラン(Pro以上など)で利用可能です。この技術は、AIエージェントがWeb上の情報をより安価に、高速に、そして正確に理解するための強力なインフラとなるでしょう。 引用元: https://blog.cloudflare.com/markdown-for-agents/ MiniMax M2.5: Faster. Stronger. Smarter. Built for Real-World Productivity. MiniMax社が発表した最新モデル「MiniMax-M2.5」は、実務での生産性を最大化するために設計されたLLMです。数十万件の複雑な実世界環境を模した強化学習(RL)を経て、コーディング、エージェントとしてのツール利用、オフィス業務において世界最高水準(SOTA)の性能を達成しました。 1. シニアエンジニアのように「設計」から関わるコーディング能力 M2.5は単にコードを書くだけではありません。熟練したソフトウェアアーキテクトのように、実装前に機能分解やUIデザインの計画を立てる能力(Spec-writing)が備わっています。 広範な対応力: Go, Rust, TypeScript, Pythonなど10以上の言語に対応し、Web、Android、iOSなどマルチプラットフォームの開発をサポート。開発全工程をカバー: ゼロからのシステム設計から環境構築、機能改善、そして厳格なコードレビューまで、開発ライフサイクルの全域で信頼できるパフォーマンスを発揮します。ベンチマーク: SWE-Bench Verifiedで80.2%を記録し、ClaudeやGPTシリーズを凌ぐ進化速度を見せています。 2. 爆速かつ「安すぎて計測不能」なコスト効率 エンジニアがコストを気にせず、エージェントを24時間稼働させ続けられる世界を目指しています。 圧倒的な速度: 秒間100トークンという、競合他社の frontier モデルの約2倍の速さで動作します。衝撃的な低価格: 100トークン/秒で1時間連続稼働させてもコストはわずか1ドル。出力コストベースでは、Claude OpusやGPT-5の1/10から1/20という破格の安さを実現しました。 3. 高度な自律性と検索・ツール利用 「とりあえず検索する」だけでなく、情報の密度が高いWebサイトを深く探索する能力が向上しました。 効率的な思考: 前モデル(M2.1)と比較して、より少ない推論ステップ(約20%削減)で正解に到達できるようになり、トークン効率と実行速度が大幅に改善されています。 4. 技術的裏付け:独自のRLフレームワーク「Forge」 この高性能を支えるのが、...
    続きを読む 一部表示
    1分未満
  • 株式会社ずんだもん技術室AI放送局 podcast 20260212
    2026/02/11
    youtube版(スライド付き) 関連リンク The two patterns by which agents connect sandboxes AIエージェントがプログラムを実行したりファイルを操作したりする際、セキュリティの観点から「サンドボックス(隔離された実行環境)」の利用が不可欠です。本記事では、エージェントとサンドボックスを接続するための2つの主要なアーキテクチャパターンについて、その特徴と使い分けを解説しています。 1. なぜサンドボックスが必要なのか エージェントにコード実行を許可すると、悪意のあるコードや予期せぬ動作によって、ホストシステムの認証情報や重要ファイルが漏洩・破壊されるリスクがあります。サンドボックス(DockerコンテナやVM)を利用することで、エージェントの活動範囲を完全に分離し、安全な「作業場」を提供できます。 2. パターン1:エージェントがサンドボックス内で動く (Agent IN Sandbox) エージェント本体をサンドボックスの中に配置し、外部からネットワーク経由でメッセージを送る形式です。 メリット: ローカル開発環境と構成が近く、エージェントがファイルシステムやライブラリに直接アクセスできます。エージェントと実行環境を密結合させたい場合に適しています。デメリット: LLMを呼び出すためのAPIキーをサンドボックス内に置く必要があり、侵害時のリスクがあります。また、コードを修正するたびにコンテナイメージを再ビルドする必要があるため、開発サイクルが遅くなりがちです。 3. パターン2:サンドボックスを「ツール」として使う (Sandbox as Tool) エージェント本体は自身のサーバー等で動かし、コード実行が必要な時だけリモートのサンドボックスAPI(E2BやModalなど)を呼び出す形式です。 メリット: エージェントのロジックを即座に更新でき、開発効率が高いです。APIキーをサンドボックス外(安全なサーバー側)で管理できるためセキュリティ面でも優れています。また、実行時のみリソースを消費するためコスト効率も良く、並列実行も容易です。デメリット: コード実行のたびにネットワーク通信が発生するため、頻繁に小さな処理を行う場合はレイテンシ(遅延)が課題となります。 新人エンジニアへのアドバイス:どちらを選ぶべき? 基本的には「パターン2(Sandbox as Tool)」から検討することをおすすめします。エージェントの「思考(ロジック)」と「実行(サンドボックス)」を切り離すことで、デバッグがしやすくなり、セキュリティ設計もシンプルになるからです。一方で、特定のOS設定や複雑な環境状態を常に維持する必要がある高度なエージェントを構築する段階になったら、パターン1を検討してみると良いでしょう。 LangChainの「deepagents」などのフレームワークはこの両パターンに対応しており、設定次第で柔軟に使い分けることが可能です。エージェント開発において、安全性と開発スピードのバランスを考える上で非常に重要な視点となります。 引用元: https://blog.langchain.com/the-two-patterns-by-which-agents-connect-sandboxes/ AIエージェントのUXを進化させる「A2UI」でアプリを構築 生成AIアプリのインターフェースは現在「チャット形式」が主流ですが、テキストのみのやり取りでは何度も聞き返しが発生するなど、効率や表現力に限界があります。この課題を解決するため、Googleが2025年12月に発表したAIエージェント用UIプロトコル「A2UI(Agent to UI)」について解説します。 1. A2UIとは何か A2UIは、AIエージェントが会話の文脈に応じたUIを動的に生成し、フロントエンド側で安全にレンダリングするためのオープンプロトコルです。 宣言的なデータ処理: UIをJSON形式のデータとして扱います。高いセキュリティ: HTMLやJavaScriptといった実行コードを直接送らず、構造データのみをやり取りするため、XSSなどのセキュリティリスクを低減できます。効率的なUX: 例えばレストラン予約やクイズ回答において、チャットで何度も往復する代わりに、入力フォームやカード形式のUIを提示して直感的な操作を促せます。 2. A2UIの仕組み UIの更新は、主に以下の4つのメッセージタイプを組み合わせた「JSONL形式」のシーケンスで行われます。 beginRendering: ...
    続きを読む 一部表示
    1分未満
  • 株式会社ずんだもん技術室AI放送局 podcast 20260210
    2026/02/09
    youtube版(スライド付き) 関連リンク Claude Code Agent Teamsのあそびかた 本記事は、2026年2月5日に「Claude Opus 4.6」と同時にリリースされたClaude Codeの実験的機能「Agent Teams」についての解説記事です。複数のAIエージェントを独立したプロセスとして動かし、チームとして協調させるこの機能は、エンジニアにとって開発の自動化を一段階進める非常に興味深い内容となっています。 1. Agent Teamsの概要と仕組み Agent Teamsは、従来のSubagents(子エージェント)を拡張し、各エージェントを独立プロセスとして「ステートフル(状態を保持できる)」にした機能です。 技術的な仕組みがユニークで、~/.claude/teams/配下のJSONファイルを「メールボックス」に見立てて、各エージェントがポーリング(定期確認)することで相互通信を実現しています。ファイルロックによる排他制御を行うことで、推論とファイルシステムのみで複雑なメッセージングシステムを構築している点がエンジニアとしての見どころです。 2. 効率的な運用のためのモデル選択 エージェントごとに独立したコンテキスト(記憶の枠組み)を持つため、全員を最強モデルのOpusで動かすと、利用制限やコストを激しく消費します。 新人エンジニアへのアドバイスとして重要なのが「適材適所」です。プロンプトや設定で、リーダー以外は軽量なHaikuやSonnetを使うよう誘導することで、リソースを節約しながらチームを機能させることができます。 3. チーム開発の実践例 GitHubのIssue(例:npm installのボトルネック解消)を解決させる際、以下のような役割を持つエージェントを同時に立ち上げることができます。 Explorer: コードベースを高速に調査するArchitect: 実装計画を設計するExecutor: 実際にコマンドを実行し、コードを修正する これらが.claude/projects/memory/配下で進捗やタスクリストを共有し、自律的に連携して課題を解決していきます。 4. Subagentsとの違い(エンジニア向けの例え) 記事では、OSのプロセスモデルに例えて以下のように整理されています。 Subagents: 同一プロセス内の「スレッド」のようなもの。親のメモリ空間を共有し、単発タスクをこなして終了する軽量な存在。Agent Teams: 「forkされた独立プロセス」のようなもの。ファイルシステム経由の通信(IPC)で協調し、セッションをまたいで文脈を保持できる。 まとめ 現状ではSubagentsで十分な場面も多いですが、複数のエージェントがターミナル上で「わちゃわちゃ」と並列に動く様子は楽しく、マルチエージェントによる開発の未来を感じさせます。計算コストとのバランスを考えつつ、実験的機能を使いこなす楽しさが詰まった内容です。 引用元: https://blog.lai.so/agent-teams/ A Language For Agents Flaskの作者として知られるArmin Ronacher氏による、AIエージェントが開発の主役となる時代の「新しいプログラミング言語」のあり方についての考察です。新人エンジニアの方にとっても、これからの技術選定やコードの書き方を考える上で非常に示唆に富む内容となっています。 なぜ新しい言語が必要になるのか これまでのプログラミング言語は「人間がキーボードを打つ手間を減らすこと(簡潔さ)」を重視して設計されてきました。しかし、AIエージェント(以下、エージェント)の登場により、コードを書くコストは劇的に低下しています。これからは、簡潔さよりも「エージェントがいかに正確にコードを理解し、修正できるか」が重要になります。エージェントは多言語間のコード移植も得意なため、既存のエコシステムに縛られない、エージェント特化型の新しい言語が登場する土壌が整いつつあります。 エージェントが好む言語の設計指針 エージェントが効率的に動くためには、高度なツール(LSPなど)に頼らずとも、コードそのものから意図が読み取れる「局所的な推論」のしやすさが鍵となります。 LSPに依存しないコンテキスト:IDEなどの支援ツールがなくても、コードスニペットだけで型や定義が判別できる明示的な構造が好まれます。明確な構造と記号:Pythonのようなインデント(空白)によるブロック管理は、トークン処理を行うAIには扱いづらい場合...
    続きを読む 一部表示
    1分未満
  • マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20260209
    2026/02/08
    関連リンク なぜ、Claude Codeは、RAGを捨ててAgentic Searchを選んだのか? Anthropic社のエンジニアであり、Claude Codeの創設者であるBoris Cherny氏が、「初期のClaude CodeではRAG(検索強化生成)を採用していたが、最終的にAgentic Search(エージェントによる自律探索)へ切り替えた」という設計思想を明かし、大きな話題となっています。本記事では、その技術的な判断背景を新人エンジニアにも分かりやすく解説しています。 1. RAGとAgentic Searchの違い まず、従来の「王道RAG」は、あらかじめドキュメントを数値化(Embedding)してデータベース(ベクトルDB)に保存し、質問に似た意味の情報を探し出す仕組みです。試験勉強に例えると「事前に大量の参考書を買い込み、関連しそうなページを付箋で引いておく」ような準備型のアプローチです。 一方、Agentic Searchは、AIがその場で「どのファイルを見るべきか」「どのコマンドを使うべきか」を考えて探索する方式です。grepやglobといった使い慣れたツールを自律的に使い分け、コードベースを直接調査します。これは「問題を見てから、必要な情報をその都度Webや資料で調べに行く」という、人間のエンジニアの行動に近いアドリブ型のアプローチです。 2. なぜ「王道RAG」を捨てたのか Claude Codeがコード探索においてRAGを卒業した理由は、主に4点あります。 精度とノイズ: コード検索では「なんとなく意味が似ている」ことより「正確に一致する」ことが重要です。RAGでは古い仕様や無関係なコードがヒットしやすく、それがAIの「ハルシネーション(もっともらしい嘘)」の原因になっていました。情報の鮮度: 開発現場ではコードが頻繁に書き換わります。RAGの場合、その都度インデックスを更新するコストが非常に高く、情報が古くなりやすいという欠点がありました。セキュリティとプライバシー: データを外部のDBに保存・管理する手間を省き、機密性の高いコードをシンプルに扱うためです。LLMの進化: 最新のモデルは非常に長い文脈を理解でき、複雑な推論が可能になったため、事前の加工なしで直接ファイルを読み解く力が備わったことが背景にあります。 3. エンジニアが意識すべき「これからの開発」 広い意味では、外部情報を取得して回答するAgentic SearchもRAGの一種と言えます。しかし、従来の「データベースに頼る検索」から「AIが自律的に探索する」形へと手法が進化しました。 ここで重要なのは、AIの賢さは「人間が用意した環境」に依存するという点です。どれほど優秀なAIエージェントでも、整理されていないクソコードや古いドキュメントの中では正解を見つけられません。お掃除ロボットの「ルンバ」が効率よく動くために、人間が床の荷物を片付ける必要があるのと同様に、エンジニアには「AIが読みやすいようにコードを整理し、ディレクトリ構造を整える」という新しい役割が求められています。 結局のところ、読みやすいコードを書き、適切にドキュメントを整備するというエンジニアの基本こそが、最新AIの性能を最大限に引き出す鍵となるのです。 引用元: https://zenn.dev/karamage/articles/2514cf04e0d1ac Kimi K2.5: Visual Agentic Intelligence AI技術の急激な進化を象徴する、新たな大規模言語モデル「Kimi K2.5」が登場しました。1兆パラメータを誇るオープンウェイトモデル「Kimi K2」シリーズの最新版であり、新人エンジニアの方にとっても、今後の「AIエージェント」の在り方を占う上で非常に重要なニュースです。 今回のアップデートの目玉は、テキストのみだった従来モデルから、15兆トークンに及ぶ画像・テキスト混合データでの学習を経て「ネイティブマルチモーダル」に進化した点です。これにより、視覚情報の理解と高度なコーディング能力が統合されました。 特筆すべきは、Kimi K2.5が提唱する「自己主導型エージェント・スウォーム(Self-directed agent swarm)」という概念です。これは複雑な指示を受けた際、AIが自律的に最大100個の「サブエージェント」を作り出し、最大1500回ものツール呼び出しを並列で実行する仕組みです。人間が細かなワークフローを定義しなくても、AIが勝手に「分身」を作って効率的に仕事...
    続きを読む 一部表示
    1分未満
  • 私立ずんだもん女学園放送部 podcast 20260206
    2026/02/05
    youtube版(スライド付き) 関連リンク Introducing OpenAI Frontier OpenAIは、企業がAIエージェントを「AI同僚(AI Coworker)」として構築・運用・管理するための新しい統合プラットフォーム「OpenAI Frontier」を発表しました。これまで多くの企業がAI導入を試みてきましたが、個々のエージェントが特定のタスクに孤立してしまい、社内全体のコンテキストやルールを十分に活用できていないという「AI機会ギャップ」が課題となっていました。Frontierはこのギャップを埋め、企業レベルでの本格的なAIエージェントの運用を支援するインフラです。 新人エンジニアの皆さんに向けた、Frontierの主要な特徴とポイントは以下の通りです。 1. 組織全体での「文脈(コンテキスト)」の共有 優れた社員が会社のルールや情報のありかを熟知しているように、Frontierは社内のデータウェアハウス、CRM(顧客管理システム)、各種ツールを連携させ、AIエージェントに「共有されたビジネスコンテキスト」を提供します。これにより、エージェントは断片的な情報ではなく、組織全体の流れを理解した上で判断ができるようになります。 2. 安全で強力な「実行環境(エージェント実行)」 AIエージェントが「考える」だけでなく、実際に「動く」ための環境を提供します。ファイル操作、コードの実行、外部ツールの利用といった複雑なタスクを、信頼性の高い安全な環境で行えます。また、OpenAIの最新モデルへの低レイテンシなアクセスが優先され、実務に耐えうるレスポンス速度を確保しています。 3. 「評価と最適化」による継続的な成長 新人がフィードバックを受けて成長するように、AIエージェントも実務を通じて学習する必要があります。Frontierにはエージェントのパフォーマンスを評価し、最適化するための仕組みが組み込まれています。人間によるフィードバックを通じて、時間の経過とともにエージェントの品質と信頼性が向上していくサイクルを構築できます。 4. 厳格な「権限管理とガバナンス」 企業での利用において最も重要なのがセキュリティです。Frontierでは各AIエージェントに個別のアイデンティティ(ID)を付与し、明確なアクセス権限とガードレール(行動制限)を設定できます。これにより、機密性の高い環境や規制の厳しい業界でも、コントロールを失うことなく大規模なAI運用が可能になります。 5. エコシステムと開発サポート Frontierはオープンスタンダードに基づいて設計されており、既存のシステムや他社製のエージェントとも柔軟に連携できます。また、OpenAIのエンジニア(FDE: Forward Deployed Engineers)が企業のチームと直接協力する体制も用意されており、現場でのフィードバックをOpenAIの研究部門へ直接戻すことで、モデル自体の進化にもつなげる仕組みになっています。 まとめ 「OpenAI Frontier」は、単なる便利なツールを個別に使う段階から、AIを「信頼できるチームメンバー」として組織全体に組み込む段階へとシフトさせるためのプラットフォームです。エンジニアにとっては、バラバラに開発されていたエージェントを一元管理し、企業の既存資産(データやシステム)と安全に接続するための重要な基盤となるでしょう。 現在は一部の限定顧客に提供されていますが、今後数ヶ月でさらに広く展開される予定です。AIエージェントが本格的に実務の最前線で活躍する時代の、強力なバックボーンになることが期待されます。 引用元: https://openai.com/index/introducing-openai-frontier Claude Codeの性能を引き出すワークフロー設計 この記事は、AIエージェント「Claude Code」を実務で最大限に活用するために、どのようにAIへの依頼内容(ワークフロー)を設計すべきかを技術的な視点で解説しています。新人エンジニアの方にとっても、AIを単なるチャットツールとしてではなく、「自律的なチームメンバー」として扱うための指針となる内容です。 1. 協業レベル(デリゲーション)の設計 AIに何をどこまで任せるかを明確にすることが第一歩です。自分で実装して補完だけを頼るレベル(Consult)から、チケットを渡してプルリクエスト作成まで任せるレベル(Inquire)、さらにはマージ...
    続きを読む 一部表示
    1分未満
  • 株式会社ずんだもん技術室AI放送局 podcast 20260205
    2026/02/04
    youtube版(スライド付き) 関連リンク Build with Kimi K2.5 Multimodal VLM Using NVIDIA GPU-Accelerated Endpoints NVIDIAは、Moonshot AIが開発した最新のオープンなマルチモーダル視覚言語モデル(VLM)である「Kimi K2.5」が、NVIDIAのGPUアクセラレーションエンドポイントで利用可能になったことを発表しました。このモデルは、テキストだけでなく画像やビデオの入力にも対応しており、高度な推論、コーディング、数学、そして自律的に動く「AIエージェント」のワークフローにおいて非常に高い性能を発揮します。 新人エンジニアが注目すべき技術的特徴は、その効率的なアーキテクチャです。Kimi K2.5は「混合エキスパート(MoE: Mixture-of-Experts)」という仕組みを採用しています。総パラメータ数は1兆(1T)という巨大な規模ですが、推論時にはそのうちの3.2%(約330億パラメータ)のみを動的に使用するため、高い処理能力と効率性を両立させています。また、262Kという非常に長いコンテキストウィンドウ(一度に読み込める情報量)を持っており、膨大な資料や長い動画の解析にも適しています。 視覚処理の面では、独自の「MoonViT3d Vision Tower」を搭載しており、画像やビデオフレームを効率的にベクトルデータに変換します。トレーニングにはNVIDIAの「Megatron-LM」フレームワークが使用されており、GPUの並列処理能力を最大限に引き出す最適化が施されています。 開発者向けの活用方法として、以下の3つのステップが紹介されています。 プロトタイピング: NVIDIA Developer Programに登録すれば、ブラウザ上のプレイグラウンド(build.nvidia.com)で無料かつ手軽にモデルの性能を試すことができます。API利用: OpenAI互換のAPIエンドポイントが提供されているため、Pythonなどのコードから簡単にモデルを呼び出してアプリケーションに組み込めます。デプロイとカスタマイズ: 高速な推論を実現する「vLLM」でのデプロイや、NVIDIA NeMo Frameworkを用いた独自のデータによる微調整(ファインチューニング)もサポートされています。 NVIDIAの最新GPU環境に最適化されたこの強力なオープンモデルは、これからのAIアプリケーション開発において、エンジニアにとって非常に魅力的な選択肢となるでしょう。 引用元: https://developer.nvidia.com/blog/build-with-kimi-k2-5-multimodal-vlm-using-nvidia-gpu-accelerated-endpoints/ Apple SiliconでAIやっている人に朗報です。vllm-mlxが凄い。 Apple Silicon(Mac)でのLLM実行環境を劇的に進化させる新しいフレームワーク「vllm-mlx」についての解説記事です。これまで高性能な推論サーバーの代名詞であった「vllm」は、Mac環境ではCPU実行に限定されるなどの制約がありましたが、本プロジェクトはApple純正の計算ライブラリ「MLX」をベースにすることで、MacのGPU(Metal)性能を最大限に引き出したvllmライクなインターフェースを実現しています。 概要 vllm-mlxは、Apple Silicon(M1〜M4チップ)にネイティブ対応した、マルチモーダルな推論プラットフォームです。単なるモデル実行用のラッパーにとどまらず、プロダクトレベルの運用に耐えうる高度なメモリ管理機能とスループット性能を備えている点が最大の特徴です。 主な特長 マルチモーダル対応: テキストだけでなく、画像、動画、音声の推論を一つのプラットフォームで統合的に扱えます。圧倒的なパフォーマンス: vllmと同じ「Paged KV Cache(ページングKVキャッシュ)」アーキテクチャを採用。従来のMLX関連ツールと比較して、処理スピードが1.14倍高速化し、メモリ消費量を約80%に節約することに成功しています。高度なサービング機能: 複数ユーザーの同時接続を効率よく処理する「連続バッチ処理(Continuous Batching)」に対応しています。OpenAI API互換: OpenAIクライアントをそのまま代替として利用可能なローカルサーバーを構築できます。MCPツール呼び出し: モデルコンテキストプロトコル(MCP)を介して外部ツールと連携でき、AIエージェントの開発にも適しています。 新人エンジニアに向けた注目ポイント Mac一台で「爆速かつ省メモリ」なLLM環境が手に入ることは、開発効率を大きく高めます。特に、これまで個別に使い分ける必要があった「mlx-lm(言語モデル用)」や...
    続きを読む 一部表示
    1分未満
  • 株式会社ずんだもん技術室AI放送局 podcast 20260204
    2026/02/03
    関連リンク マルチモーダルLLMを活用したZOZOTOWN検索の関連性評価手法 ファッションECサイト「ZOZOTOWN」を運営するZOZOの検索基盤部による、マルチモーダルLLM(MLLM)を活用した検索結果の評価手法に関する解説記事です。 検索システムの改善において、新旧のアルゴリズムを比較する「オフライン評価」は不可欠ですが、従来の検索ログを用いた手法には課題がありました。過去のログは既存の検索ロジックの結果に基づいているため、新しいロジック(ベクトル検索など)に対して公平な評価ができず、バイアスが生じてしまう点です。 この課題を解決するため、ZOZOは人間の代わりにMLLMを用いて検索クエリと商品の関連性を判定する手法を導入しました。本手法の主な特徴とステップは以下の通りです。 マルチモーダル情報の活用と基準策定 ファッションにおいて「見た目」は重要な要素です。商品テキストだけでなく画像データもMLLMに入力することで、視覚的な関連性を考慮した高精度な判定を実現しました。また、評価基準を「Highly relevant(非常に関連あり)」「Acceptable Substitute(許容できる代替品)」「Irrelevant(無関連)」の3段階に整理し、曖昧さを排除したプロンプトを設計しています。 ゴールドセットによるモデルの検証 判定の信頼性を担保するため、まず人間が手作業で作成した正解データ(ゴールドセット)を用いて複数のLLMを比較しました。検証の結果、Gemini 2.5 Flashと改善したプロンプトの組み合わせが74.1%という高い精度を記録し、実用レベルにあることを確認しました。 定量評価の自動化とスケーラビリティ 構築した評価基盤を用いることで、数千から数万件のクエリ・商品ペアに対して自動でラベリングを行い、nDCGやPrecisionといった指標を算出します。人間が2時間かかる作業をMLLMなら1分以内で完了できるため、圧倒的なスピードで大規模な評価が可能になりました。 この取り組みにより、既存ロジックのバイアスを排除した「本質的な関連性」に基づく評価体制が整いました。LLMを単なるチャットツールとしてではなく、システムの精度を計測するための「スケーラブルな評価基盤」として活用する、実戦的で非常に参考になる事例です。 引用元: https://techblog.zozo.com/entry/search-quantitative-evaluation-llm H Companys new Holo2 model takes the lead in UI Localization AIスタートアップのH Company(Mistral AIの創設メンバーらによる企業)から、UI(ユーザーインターフェース)要素の特定において世界最高性能(SOTA)を更新した最新モデル「Holo2-235B-A22B Preview」が発表されました。本記事は、GUIエージェントやWebオートメーションの未来を大きく変える可能性を秘めた、この新モデルの技術的な進展を解説しています。 1. UIローカライズにおける新たな金字塔 「Holo2-235B-A22B Preview」は、GUIグラウンディング(画面上の特定の要素がどこにあるかを特定する技術)の難関ベンチマークである「ScreenSpot-Pro」で78.5%、「OSWorld G」で79.0%というスコアを記録しました。これは、AIが画面内のボタンや入力フォームをいかに正確に認識できるかを示す指標であり、現時点で世界トップクラスの精度を誇ります。本モデルはHugging Face上でリサーチリリースとして公開されています。 2. 「Agentic Localization」による精度の追求 従来のモデルが直面していた大きな課題に、4Kなどの高解像度画面における「非常に小さなUI要素の認識ミス」がありました。Holo2はこの課題を、独自の「Agentic Localization(エージェント的ローカライズ)」という手法で解決しています。 反復的な予測の洗練: 一度の推論で場所を決め打ちするのではなく、エージェントが推論を繰り返す(イテレーティブ・リファインメント)ことで、予測結果を段階的に正確なものへと修正していきます。劇的な精度向上: このアプローチにより、モデルのサイズを問わず10〜20%もの相対的な精度向上を実現しました。推論ステップの効果: 単発の推論では70.6%の精度ですが、エージェントモードとして3ステップ実行することで、最も難解なベンチマークの一つであるScreenSpot-Proにおいて78.5%という最高スコアを達成しました。 3. 日本の新人...
    続きを読む 一部表示
    1分未満
  • 株式会社ずんだもん技術室AI放送局 podcast 20260203
    2026/02/02
    関連リンク Introducing the Codex app OpenAIは、macOS向けの新ツール「Codex app」を発表しました。これは、複数のAIエージェントを司令塔(コマンドセンター)として一元管理し、複雑で長時間にわたる開発タスクを効率化するためのデスクトップアプリケーションです。従来のIDEやターミナルでは難しかった「複数のエージェントへの指示・監督・協働」を直感的に行えるように設計されています。 新人エンジニアにとっても注目すべき、主な特徴は以下の通りです。 マルチエージェントの並列実行と管理 プロジェクトごとにスレッドを分け、複数のエージェントに異なるタスクを同時に依頼できます。各エージェントの進捗をシームレスに切り替えて確認できるため、コンテキストを失わずに作業を進められます。 安全な試行錯誤を支える「worktrees」対応 エージェントはコードの独立したコピー(作業ツリー)上で動作します。そのため、自分のローカル環境やメインのGitブランチを汚す心配がありません。提案された変更はアプリ内でレビューし、コメントを付けたり、必要に応じて自分のエディタで修正したりすることが可能です。 「スキル」による機能拡張 Codexは単なるコード生成に留まりません。Figmaのデザインをコードに変換する、プロジェクト管理ツール(Linear)でバグを整理する、クラウド(VercelやRender等)へデプロイするといった一連のワークフローを「スキル」として登録し、エージェントに実行させることができます。これらはチーム内で共有も可能です。 オートメーション(自動化) スケジュールに基づいたバックグラウンド実行が可能です。毎日のバグトリアージュやCI失敗の要約作成など、重要だが繰り返しの多い業務をAIに任せ、人間は最終的な確認作業に集中できます。 柔軟な性格設定と高い互換性 エージェントの性格を「簡潔で実用的」なスタイルか「対話的で共感的」なスタイルか選ぶことができます。また、既存のCodex CLIやIDE拡張機能の設定や履歴をそのまま引き継げるため、導入もスムーズです。 最新の「GPT-5.2-Codex」をベースとしたこのアプリは、エージェントに「コードを書かせる」だけでなく「コードを使って仕事を完結させる」ツールへと進化しています。セキュリティ面でもサンドボックス構造が採用されており、安全に高度な自動化を体験できるのが魅力です。現在はmacOS向けに、ChatGPTの有料プランユーザーを対象に提供が開始されています。 引用元: https://openai.com/index/introducing-the-codex-app Selenium作者によるAIと人間のためのブラウザ操作自動化ツール Vibium を使ってみる 本書は、ブラウザ自動化ツールの代名詞である「Selenium」の生みの親、Jason Huggins氏が新たに公開したツール「Vibium」についての紹介記事です。Vibiumは、AIエージェントがブラウザを操作するためのインフラストラクチャとして設計されており、エンジニアの間で大きな注目を集めています。 概要 Vibiumの最大の特徴は、AIと人間の両方が利用できる「ハイブリッドなブラウザ操作ツール」である点です。特にAIエージェントとの親和性が極めて高く設計されています。 MCP(Model Context Protocol)の標準搭載 単一のバイナリ内にMCPサーバーが内蔵されています。これにより、Claude CodeなどのMCP対応クライアントを利用すれば、複雑な設定なし(Zero Setup)でAIにブラウザを操作させることが可能です。モダンな通信プロトコル ブラウザのライフサイクル管理に加え、最新の「WebDriver BiDi」プロトコルをサポートしており、高速で双方向なブラウザ制御を実現しています。マルチ言語対応 AIによる自動操作だけでなく、人間がコードを書いて制御することも可能です。現時点(2026年2月)では、JavaScript/TypeScriptおよびPythonから利用できるSDKが提供されています。 制約・現在の仕様 Vibiumを導入するにあたって、以下の点に留意する必要があります。 対応言語の範囲: 現在公式にサポートされているのはJS/TSとPythonであり、その他の言語については今後の展開を待つ形となります。操作の実装手法: 一部のUI操作(セレクトボックスの選択など)については、現時点ではevaluateメソッドを用...
    続きを読む 一部表示
    1分未満