株式会社ずんだもん技術室AI放送局

株式会社ずんだもん技術室AI放送局
  • 0.0 (0)
  • Technology
  • Updated Daily

AIやテクノロジーのトレンドを届けるPodcast。平日毎朝6時配信。朝の通勤時間や支度中に情報キャッチアップとして聞いてほしいのだ。(MC 月:春日部つむぎ、火水木:ずんだもん、金:お嬢様ずんだもん)

  1. 1d ago

    株式会社ずんだもん技術室AI放送局 podcast 20261027

    youtube版(スライド付き) 関連リンク Groundhog Day for AI agents: Prompt caching patterns for using OpenAI models on Amazon Bedrock Amazon Web Services この記事では、Amazon Bedrock上のOpenAIモデルを用いてAIエージェントを構築・運用する際、マルチターン処理で課題となるコストとレイテンシの増大を防ぐための「プロンプトキャッシュ設計パターン」について詳しく解説しています。 AIエージェントはターンが進むごとに、ツール定義、システム指示、過去のやり取りやツール実行結果の全履歴を毎回モデルに送信し直す必要があります。これが原因でコストや処理時間が肥大化しますが、プロンプトキャッシュを活用することで、静的なプレフィックスや成長する会話履歴を効率的に再利用し、インプットコストを大幅に削減できます。 主な設計パターンと重要なポイントは以下の通りです。 キャッシュの基本とモードの使い分け プリフィル処理時に構築されるKVベクトル（作業状態）をキャッシュし、後続のリクエストでは新規部分のみを処理します。 暗黙的（implicit）モード: Amazon Bedrockが自動的に会話の成長に合わせてキャッシュ境界を管理します。成長する会話履歴に向いています。 明示的（explicit）モード: prompt_cache_breakpoint を使用して保存ポイント（ツールや指示など）をコードで明示的に指定します。 ハイブリッド活用: 安定した静的プレフィックス（指示やツール）には明示的モードを使い、会話の成長には暗黙的モードを組み合わせることで、再利用可能な開始点を維持しつつ会話の自動管理が可能です。再利用には最低1,024トークンが必要となります。 会話履歴とツール結果のキャッシュ ターンが進むにつれて増加するツール実行結果は、暗黙的モードまたはローリングブレークポイントを用いて効率的にキャッシュします。 ツールの追加や変更を行う際は、初期のツールカタログを安定させつつ、additional_tools を用いて既存のキャッシュプレフィックスを無効化せずに新しいツールを追加できます。また、allowed_tools を使うことでキャッシュ定義を変えずに呼び出し制限が可能です。 サブエージェントとファンアウト（並行処理） 複数のヘルパーやサブエージェントを立ち上げる際は、最初に通常のウォームアップリクエストを完了させて共有プレフィックスをキャッシュ（ウォーム）してから並行処理でファンアウトさせます。これにより、各ヘルパーが同じ背景情報を再読み込みするコストを防ぎます。 キャッシュキーの管理とベストプラクティス セッション間でキャッシュを共有するには、モデル、AWSアカウント、リージョンが同一であることに加え、安定した prompt_cache_key を使用する必要があります（ハッシュ値を用いた動的生成などが有効）。 キャッシュのTTL（有効期限）は最低30分で、再利用により更新されます。 Amazon CloudWatchのメトリクスやAWS Cost Explorerを活用して、キャッシュ読み込み・書き込みのトークン数やコストをモニタリングし、費用対効果を測定することが重要です。 新人エンジニアにとっても、AIエージェントの実装時におけるAPIコスト最適化の具体的なアプローチやPythonコード例が網羅されており、実務で直面するパフォーマンス課題を解決するための実践的な学びが得られる内容となっています。 引用元: https://aws.amazon.com/blogs/machine-learning/groundhog-day-for-ai-agents-prompt-caching-patterns-for-using-openai-models-on-amazon-bedrock/ How NVIDIA Minerva Turns Telemetry Chaos Into Peak GPU Yield NVIDIA Minervaは、数万基規模のGPUクラスタを運用する巨大なAIファクトリー向けに設計された、AIネイティブのAIOps（IT運用のための人工知能）およびオブザーバビリティプラットフォームです。AIの分散学習では、最も処理の遅いランクやノードのペースに全体が同期するため、わずかなハードウェアの劣化やネットワークの遅延が全体の処理時間を大きくロスさせます。従来の静的なしきい値やルールベースの監視では、コンポーネント単体では正常に見えるが負荷時に問題が起きる「グレー故障」の検知や、1つの故障から派生する大量の警告（アラートストーム）の相関分析が困難でした。NVIDIA Minervaは、GPU、ネットワークファブリック（Spectrum-X、NVLink）、SuperNIC、ストレージ、スケジューラ、AIワークロードからテレメトリデータを収集し、動的な知識グラフ（ナレッジグラフ）を用いてインフラストラクチャとアクティブなジョブをリアルタイムにマッピングします。これにより、障害が発生した際に関連するジョブや物理トポロジを横断して即座に特定できます。機械学習モデルを活用した異常検知では、教師あり学習による既知のエラーパターンの検出だけでなく、教師なし学習によるピア比較（同等コンポーネント同士の挙動の比較）や、NLPを用いたログの異常検知を行い、静なしきい値では見逃される微妙な劣化を捉えます。また、トポロジ認識型の相関エンジンにより、関連する数多くのイベントや警告を1つの「実用的なインシデント」に集約し、ノイズを大幅に削減します。さらに、内蔵されたAIエージェント「Sherlock」やMCPサーバーにより、エンジニアは自然言語を用いてライブのテレメトリや知識グラフに問い合せ、根本原因の解析やトラブルシューティング、修復の推奨事項を得ることが可能です。これにより、障害のトリアージにかかる時間を数時間から数分へと短縮し、GPUの稼働率（グッドプット）を最大化します。今後は「DSX OS」との統合も進められ、テレメトリ基盤のオープンソース化も予定されています。新人エンジニアにとっても、大規模分散システムにおける複雑な障害解析やオブザーバビリティの重要性を理解する上で非常に参考になるアーキテクチャとなっています。 引用元: https://developer.nvidia.com/blog/how-nvidia-minerva-turns-telemetry-chaos-into-peak-gpu-yield/ Fixing Tool-Call Accuracy in vLLM オープンウェイトLLMをエージェントワークロードなどで実運用する際、モデルが生成するTool Call（関数呼び出し）の精度低下は深刻な問題となります。例えば、vLLMを使用して「Kimi K2.6」などのモデルをサービングした際、デフォルトの状態ではスキーマに完全一致しない不正な形式のTool Callが一定割合で発生し、コンテキストの汚濁やエラーの連鎖、コストの増大を引き起こすケースがあります。こうした問題の主な原因は、LLMが確率的にトークンをサンプリングする仕組み上、学習データやプロンプトの影響を受けて存在しないパラメータ名や誤った構文を生成してしまうことにあります。 この課題を根本的に解決する実用的な手法として、「制約付きデコード（Constrained Decoding）」があります。vLLMのバージョン0.31などでサポートされたこの機能は、XGrammarライブラリなどの構造的タグを利用し、生成されるトークンを動的に制限する仕組みです。推論時にツール定義のJSONスキーマや構文ルールに基づいて有効なトークンのみを許可し、無効なパスやトークンをGPU上で効率的にマスクします。これにより、Tool Callの構文精度をベストエフォートから100%保証されたランタイムへと引き上げることが可能です。 ただし、vLLMのようなモデル非依存の汎用推論エンジンでは、制約付きデコードをデフォルトで有効にすると、一部のモデルで出力が不自然になったり、グラマ翻訳のバグやスペックラティブデコードなどの他機能との競合によってリクエスト失敗を引き起こしたりするリスクがあります。そのため、vLLMの標準動作ではこれがデフォルトでオフに調整されており、ユーザー自身がサーバー側のフラグ等で明示的に厳格化レベルを設定する必要があります。特定のオープンウェイトモデルを高精度で運用したいエンジニアにとって、この制約付きデコードを適切に有効化・設定することは、モデル本来の性能を引き出すために極めて重要なアプローチとなります。 引用元: https://www.ubicloud.com/blog/fixing-tool-call-accuracy-in-vllm コンピューターサイエンス分野において「霧雨魔理沙」の名義で論文を出してる人を発見、冗談みたいな名前だが経歴見るとガッチガチの模様 コンピューターサイエンスの学術データベース上に、人気ゲーム「東方Project」のキャラクター名である「霧

  2. 2d ago

    マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20261026

    youtube版(スライド付き) 関連リンク Kimi K3.1 Pro Tech Blog: Advancing Open Intelligence 中国のMoonshot AIが、最新の3兆パラメータ級オープンウェイトモデル「Kimi K3.1 Pro」および高速版の「Kimi K3.1 Pro Highspeed」を発表しました。本モデルは100万トークンのコンテキストウィンドウを備え、コーディング、3Dモデリング、財務リサーチ、エージェントとしての自律実行能力において大幅な性能向上の実現を謳っています。 コーディング分野においては、大規模な強化学習の導入により、単なるバグ修正からUnityやUnreal Engine、Godotなどのゲームエンジンを活用したフルプロジェクトの構築まで幅広く対応します。長時間の推論タスクをこなすロングホライズンな実行力が高められており、ターミナル操作を評価する「Terminal-Bench 4.0」では高いスコアを記録するなど、主要な独自モデルに匹敵する性能を示しています。 3Dモデリングとデザインの領域でも優れた空間推論能力を発揮し、テキストの指示やスケッチ、参考画像からCADコードを生成してCADモデルを再構築する「BenchCAD」などで高い精度を実現しています。BlenderやCADツール用のスクリプトを自ら記述・実行することで、機械部品や建築モデルなどのパラメトリックモデリングを効率的に行える点が特徴です。さらに、オンラインで3Dモデルのプレビューや編集が行える「3D Make」機能も提供されます。 財務およびビジネスリサーチの分野では、複雑な金融ドキュメントの解析やクロスドキュメント検証、投資ワークフローのサポートにおいて優れた性能を発揮し、事実誤認（ハルシネーション）の発生率も前モデルから大幅に抑制されています。 また、セキュリティと安全性の観点から、モデルのトレーニング段階（ミッドトレーニングおよび強化学習のステージ）でサイバーセキュリティ関連のデータを識別して削除するフィルタリング処理が施されました。これにより、一般的な有用性を維持しつつ悪用のリスクを軽減しつつも、高度なデバッグ能力や汎用コーディング能力によってセキュリティタスクへの適応力は維持されています。 Kimi K3.1 Proは、公式のWebプラットフォームや専用アプリ、デスクトップアプリ「Kimi Work」、コード支援ツール「Kimi Code」、およびAPI経由で本日より利用可能であり、モデルの全ウェイトは2026年11月4日までに公開される予定です。 引用元: https://www.kimi.ai/blog/kimi-k3-1-pro Zero-Shot to New Robots: Introducing Dream-1 Dream Labs社は、未学習のロボットやタスク、環境に対して即座に対応できる世界初（※初期段階の検証に基づく）の汎用ロボット基盤モデル「Dream-1」と、それを利用できるパブリックAPIを発表しました。ロボット業界長年の課題である「有用なロボットを作るにはそのロボットのデータが必要だが、データはロボットが使われないと集まらない」という鶏と卵のジレンマを打破することを目指しています。 従来のロボット制御モデルは特定のハードウェア（関節角度など）に強く依存していましたが、Dream-1は「世界行動モデル（World Action Model: WAM）」というアプローチを採用しています。WAMは動画の予測と行動の予測を同時に学習する仕組みであり、ヘッドカメラ等を通じて捉えたシーンをピクセル（形状の動き）として認識します。これにより、二腕と平行グリッパーを持つロボットであれば、これまで学習時に一度も触れたことがない未知のロボット（18年前にリリースされたPR2などの古い研究用ロボットを含む）であっても、ゼロショット（追加学習なし）で制御することが可能です。 また、APIはプラグアンドプレイに近い手軽さで設計されており、機械学習の深い専門知識がなくても、数行のPythonコード（dream.DreamClient等）でロボットを接続して指示を与えられます。モデルの実行コストは「Dream-1」が1時間あたり約3ドル、「Dream-1-flash」が約2ドルと非常に安価に抑えられています。 さらに、ゼロショットでの対応が難しい独自のロボットや複雑なタスクに対しても、FaaS（Fine-tuning-as-a-Service）という仕組みが提供されています。ユーザーが自分のロボットで数分間（例：5分程度）のデモデータを収集してアップロードしファインチューニングを行うことで、カスタムモデルを構築し、タスクの成功率を大幅に向上させることができます。 本記事は、安価なロボットハードウェアの普及が進む中で、ロボットの知能をオープンなAPIとして提供し、研究者だけでなく一般の開発者や小規模チームが汎用ロボットを簡単に動かせるエコシステムを構築しようとする、ロボティクス分野の大きな進展を示しています。 引用元: https://dreamlabs.ai/research/dream-1/ AI ネイティブの SDLC プレイブック AIエージェントの普及によりコード作成が高速化した現代において、従来のソフトウェア開発ライフサイクル（SDLC）を見直し、開発プロセス全体をAIネイティブに再構築するための実践的なプレイブックをAnthropic社が公開しています。従来のSDLCは手動による承認や引き継ぎに依存していましたが、AIネイティブなSDLCでは、計画、設計、構築、テスト、導入、保守の6つのステージを非線形のループ構造とし、各段階でバージョン管理されたマークダウンファイルを成果物として引き渡す仕組みを提案しています。 具体的なステージごとのアプローチとして、まず「計画（Plan）」では、アイデアや問題を非エンジニアでも作成できるintent.mdとしてバージョン管理します。「設計（Design）」では、要件と設計仕様を1つのセッションに圧縮し、組織のポリシーをスキルとして適用した上でspec.mdを作成します。「構築（Build）」では、Claude Codeのプランモードを活用して承認済みの plan.md を作成し、インメモリとしての CLAUDE.md や、スキル、ガードレールとなるフックを用いて自律的な開発を安全に進めます。「テスト（Test）」では、セッション自身にテストやビルドを実行させてループを完結させ、CIでの継続的な評価を実施します。「導入（Deploy）」では、PRレビューの自動化やフックによる承認ゲート、サンドボックス環境でのCI/CD統合を行います。「保守（Maintain）」では、指標の監視やコードベースの定期的なスキャン、Slackなどのチャネルに常駐する「Claude Tag」を活用してループを閉じ、見つかった課題を再び intent.md としてパイプラインに戻します。 このように、人間の判断をプロセスの中心に据えつつ、ガバナンスやセキュリティをコードや設定で強制することで、組織全体の開発速度と安全性を両立させるための指針となっています。 引用元: https://claude.com/ja/resources/articles/the-ai-native-sdlc-playbook 「山の木の実ぜんぶ乗せフルーツタルト」を作った動画をアップしたら、「サムネがAIっぽい」と批判されてしまった「知らないものはAIに見える時代になった？」 野草研究家が投稿した「山の木の実ぜんぶ乗せフルーツタルト」の動画のサムネイル画像に対し、SNS上で「生成AIで作った偽物だ」という批判や指摘が寄せられた。投稿者は完全に実写であり、トマシなどの実在する珍しい野草や木の実を使用していると反論した。これに対し、ユーザーの間では、写真の彩度やコントラスト、見慣れない木の実の形状、カットされた実と殻つきの実が混在する構図などが、AI生成画像によく見られる雰囲気や不自然さに似ていると感じさせたことが原因ではないかと議論になった。知らない自然の姿や特殊な盛り付けが、AIの普及によって「本物か偽物か」と疑われる現代の認知の歪みや難しさを浮き彫りにする話題となっている。 引用元: https://togetter.com/li/2762761 お便り投稿フォーム VOICEVOX:春日部つむぎ

  3. 5d ago

    私立ずんだもん女学園放送部 podcast 20261023

    youtube版(スライド付き) 関連リンク Using thousands of AI agents to uncover new leads in biological data OpenAIは、PerturbAIおよびScripps Researchと共に、数千ものAIエージェントを大規模に並列駆動させて生物学データを解析する最新の研究成果を発表しました。「GPT-Rosalind」を基盤とする数千のAIエージェントを活用し、マウスの脳細胞に関する膨大なCRISPRアトラスの実験データをわずか32分で解析することに成功しました。現代の生物学実験では、何千もの遺伝子変異や数百万もの細胞を対象とした大量のデータが生成されますが、それらの結果を人類の疾病理解につなげるには、散在する膨大な科学文献と結びつける必要があり、人間だけでは数ヶ月から1年以上の時間がかかります。 本研究では、この課題を解決するために「分散型生物学的推論（Distributed Biological Reasoning）」というアプローチが採用されました。具体的には、分析作業を数千のAIエージェントに分割し、並列実行させました。各エージェントは1つの遺伝子変異を調査し、細胞の応答を分析した上で、関連する科学文献を検索し、結果に対する説明を提案します。その結果生成されたレポートは、遺伝子、細胞への影響、関連文献、考えられる生物学的メカニズムを結びつけた推論アトラスとして統合されます。 新人エンジニアが技術的な観点で注目すべきポイントは、単一の巨大なAIエージェントにすべてのデータを処理させるのではなく、多数のエージェントを並列（分散）させてタスクを分割するアーキテクチャの優位性です。検証の結果、単一のエージェントに全データを処理させた場合はワークロードの増加に伴って文献の参照数が11件にとどまったのに対し、分散エージェントでは700件以上の参考文献を適切に引用し、人間専門家からも高く評価される深い推論結果を出力しました。大規模言語モデルやAIエージェントを活用したシステム設計において、処理を適切に分割して並列実行させる分散処理のパターンは、複雑で大量のコンテキストを扱うアプリケーションへの応用において非常に大きな学びとなります。 引用元: https://openai.com/index/scaling-ai-research-for-complex-biological-data Patch the Planet: global response coordination as agents uncover critical vulnerabilities OpenAIは、オープンソースソフトウェアの脆弱性をAIエージェントの活用によって迅速に発見・修正し、世界規模でエコシステム全体を保護するためのグローバル対応プログラム「Patch the Planet」を発表しました。近年の事例として、PHPの深刻な脆弱性をAIモデル（GPT-5.6 Sol）を用いて発見し、WizやCloudflareなどのセキュリティ企業やPHPのメンテナーと協力して情報開示前に修正と対策の調整を行ったことが紹介されています。 この取り組みの背景には、先進的なAIがインターネット規模の影響を持つ脆弱性を攻撃者よりも早く発見できるという事実があります。これにより、メンテナーやセキュリティプロバイダーが事前に修正プログラムや防御策を準備するための「ディフェンダーズ・ウィンドウ（防御者の期間）」が生まれます。しかし、同様のAIの能力は攻撃者が悪用ツールを急速に開発するためにも使われるため、オープンソースプロジェクトやフロントラインの防御組織を支援することが急務となっています。OpenAIは、リソースが限られた組織を支援するために10億ドル規模のサブスクリプションアクセスや資金提供、エンジニアリングの支援を表明しています。 記事では、発見された脆弱性に対してエコシステム全体で迅速かつ安全に対処するため、5段階のフレームワークが提案されています。 アップストリーム脆弱性の検証と修正: メンテナーや研究者、技術パートナーが影響を評価し、フロンティアモデルを用いた敵対的テストを通じて修正プログラムを開発・テストする。 影響を受ける組織への事前準備時間の確保: 修正プログラムの適用やWAFルールの作成、古いリリースへのバックポートなどをスムーズに行えるよう、事前に情報を共有する。 政府パートナーとの連携: ホワイトハウスやCISAなどの政府機関と協力し、重要インフラを保護するためのガイダンス伝達を支援する。 影響を受ける製品全体でのアップデート準備: ディストリビューターやホスティング事業者などを巻き込み、抜け漏れのないアップデートを準備する。 パッチ公開後のガイダンスとデプロイ支援: 公式なパッチや一時的な緩和策、バックアップとリカバリに関する公開ガイダンスを提供し、導入をサポートする。 さらに、小規模なチームで運営されることが多いオープンソースのメンテナーに対して、金銭的支援や「Codex for OSS」を通じたモデルへのアクセス提供、実地でのエンジニアリング支援を行い、グローバルな対応能力を底上げする方針です。また、単に脆弱性を直すだけでなく、最初から安全なコードを書くための支援、メモリ安全な言語への移行支援、形式検証、厳格なサンドボックスによる強力な隔離など、AIを活用してより安全なソフトウェアの土盤を構築することの重要性が説かれています。 新人エンジニアにとっての学びとして、セキュリティの脆弱性対応は単にパッチを当てるだけでなく、AIを活用した効率的な脆弱性検出や、メンテナー・クラウド事業者・政府機関を巻き込んだサプライチェーン全体の迅速な情報共有と連携プロセスが極めて重要であることが理解できます。 引用元: https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities Running Frontier-Class AI Models Across 8 NVIDIA DGX Spark Nodes NVIDIAは、GTC Berlinにおいて、コンパクトなAI開発向けワークステーション「NVIDIA DGX Spark」を最大8ノードまでクラスタリングし、ローカル環境で大規模なフロンティアモデルの実行、マルチモデル連携、および小規模モデルの事前学習を行うための最新技術とベストプラクティスを公開しました。新人エンジニアがマルチノード環境におけるインフラ構築やモデル運用の勘所を把握できるように、主要なポイントを解説します。 まず、8ノード構成における最大のメリットは、統合メモリ容量が最大1TBに拡張される点です。これにより、単体や少数ノードではメモリ不足で起動できなかった「GLM 5.3 (753B)」のような超巨大なオープンモデルをローカル環境で直接サービングできるようになります。推論時のパフォーマンスについても、ノード数やトポロジーに応じた詳細なベンチマークが公開されており、例えばQwenモデルを用いた検証では、ノード数の増加に伴いデコードスループットが1ノード時の約12 TPSから8ノード時には約52 TPSまで向上することが示されています。 次に、ノード間の通信を最適化するためのアプローチとして、スイッチ接続された環境向けの新しい集合通信バックエンド「RoCEnante」が紹介されています。従来のリング型all-reduce通信とは異なり、RoCEnanteは各ノード間で直接ポイントツーポイントのデータ交換（all-to-all）を行うことで、小規模メッセージや低コンカレンシー環境におけるレイテンシを削減します。これにより、4ノード環境で約21%、8ノード環境で非量子化モデルのデコードスループットが向上するなど、スケーリング効率の改善が図られています。ただし、このバックエンドはスイッチ接続されたトポロジーに限定されるため、大規模な並行処理やリング構成では従来通りNCCLが利用されます。 また、すべてのリクエストを単一の巨大モデルで処理するのではなく、複数のモデルを効率的に使い分けるマルチモデルオーケストレーションツールとして「NVIDIA NeMo Switchyard」が提案されています。軽量な分類モデル（MiniCPMなど）を使用して簡単なリクエストと複雑なリクエストを動的に振り分け、クラスタ全体のリソースを最適に配分することで、Qwenモデル単体の構成と比較して約1.5倍から3倍の集約スループットを実現しています。YAMLファイルによるシンプルなポリシー設定でルーティングを制御できるため、限られたハードウェア資源でスループットを最大化したい場合に有効な手法です。 さらに、推論だけでなくモデルの事前学習（トレーニング）におけるスケーリング性能も検証されています。nanochatモデル（約8.9億パラメータ）を用いた事前学習の実験では、1ノードから8ノードへとスケールアウトさせるにつ

    私立ずんだもん女学園放送部 podcast 20261023

  4. 6d ago

    株式会社ずんだもん技術室AI放送局 podcast 20261022

    関連リンク LiteLLMパッケージ 再侵害の概要と対策指針 2026年10月21日、PythonのLLM連携用人気OSSであるPyPIパッケージ litellm のバージョン 1.107.0 に悪性コードが注入される再侵害事案が発生しました。ソースコード自体には悪性ファイルは含まれていませんでしたが、PyPIに公開されたwheelにのみ不正なファイルが混入していました。現在、該当バージョンはPyPIからテイクダウンされていますが、もし当該バージョンを pip install していた場合、マルウェアに感染している可能性があり、直ちに対応が必要です。 悪性版には、Pythonの自動実行メカニズムを悪用する2つの独立した経路（.pth ファイルによる cook.py の実行、および sitecustomize.py の自動インポート）が含まれています。これにより、明示的な呼び出しを行わなくても、Pythonを起動するたびに悪性スクリプトが無条件で発火する仕組みになっています。展開されるペイロード「privcollect」は、大規模な情報窃取型マルウェア（Infostealer）として動作します。 このマルウェアは、SSH秘密鍵、AWS・GCP・Azureなどのクラウド認証情報、ブラウザの保存パスワード、KubernetesやDockerの設定、各種パッケージマネージャのトークン、さらにClaude、Cursor、GitHub CopilotといったAI開発ツールの設定情報など、16カテゴリに及ぶ機密情報を網羅的に収集します。さらに、収集したデータはAES-256-CBCとRSA-OAEPで暗号化された上で、外部のC2サーバー（http://www[.]litellm[.]dev/healthcheck）へHTTP POSTで送信されます。また、sitecustomize.py にはバックドア機能も含まれており、バックグラウンドのデーモンプロセスとして常駐し、GitHub上の設定ファイルから動的にC2ドメインを取得してリモートコードを実行する仕組みを備えています。 影響を受けた可能性がある場合の対応指針として、まずは pip show litellm でバージョンを確認し、1.107.0 がインストールされている場合や、一時ディレクトリに特定のマーカーファイルが存在する場合は感染を疑います。除去手順としては、該当パッケージをアンインストールして安全なバージョン 1.106.2 にダウングレードし、site-packages 内に残存する cook.pth や cook.py などの悪性ファイルの削除、さらに常駐プロセスの停止とロックファイルの削除を行います。 そして最も重要な対策として、影響を受けた環境から窃取された可能性のある、SSH秘密鍵、クラウドのアクセスキー、各種トークン、ブラウザやAI開発ツールの認証情報、.env ファイルのシークレット、LiteLLMのデータベース認証情報など、すべてのクレデンシャルを即座にローテーション（再生成・無効化）する必要があります。再発防止策としては、悪意ある依存関係をブロックできるセキュリティプロキシ（Takumi Guardなど）の活用や、依存パッケージのバージョン管理の徹底が強く推奨されます。 引用元: https://blog.flatt.tech/entry/litellm_2nd_compromise PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet Wiz Researchチームは、Webサイトの約70%で使用されている汎用スクリプト言語「PHP」のコアエンジンにおいて、深刻なメモリ安全性に関する脆弱性「PHP2Shell」を発見しました。この脆弱性は、WordPress、Drupal、Joomlaなどの主要なCMSや、PHP 5.4以降の過去10年間にリリースされたほぼすべてのPHPバージョンに影響を与えます。攻撃者は認証なしでリモートからコードを実行（RCE）したり、プロセスのメモリから機密情報を不正に読み取ったりする危険性があります。 本件は、最先端のAIモデル（Gemini 4 ArgonやGPT-5.6 Solなど）を活用することで、長年コードベースの奥深くに隠されていて人間には解析が極めて困難だった複雑な脆弱性の発見と、複数の不具合を連鎖させた実用的なエクスプロイトの構築が短期間で可能になった事例として、セキュリティ業界におけるAIの転換点（インフレクションポイント）となりました。 具体的に確認された問題として、以下の4つの主要なバグ（CVE-2026-109618、CVE-2026-109619）が挙げられます。 アップロード進捗のアンセリアライザーにおけるUse-After-Free: セッションデータのデコード処理中のメモリ割り当て失敗に起因し、解放されたメモリ領域の再利用を通じて未認証のRCEやリモートメモリ情報の漏洩を引き起こします。 リモートプロセス・メモリの開示: PHP起動時のマルチパートリクエスト処理において、セッションのアップロード進捗処理が異常終了した際の後始末の不備により、攻撃者が外部の機密メモリ領域を読み取ることが可能になります。 致命的エラーのバックトレースにおけるUse-After-Free: 致命的なメモリ不足エラー発生時に残存するグローバルなバックトレースポインタの不整合を利用し、次のリクエストの診断処理で制御されたメモリ破損を引き起こしてRCEに繋げます。 OPcacheの型混同: OPcacheが共有メモリ上でコンパイル済み構造を永続化する際の処理の隙をつき、異なるランタイムオブジェクト間で型混同を発生させて共有状態を破損させます。 これらの脆弱性はPHPコアのバグに起因するため、個別のアプリケーション側のコードが安全であっても、影響を受けるPHPバージョンを使用しているだけでリスクに晒されます。PHPチームはすでにこの問題に対する修正パッチを公開しており、新人エンジニアや運用担当者は、影響を受けるサーバーのPHP環境を速やかに最新のパッチ適用済みバージョンへアップデートすることが強く推奨されます。また、パッチ適用が困難な場合は、各クラウドベンダーやCDN事業者が提供するWAF等による一時的な緩和策や脅威検出機能を活用して防御を固める必要があります。 引用元: https://www.wiz.io/blog/php2shell-php-rce OpenAI models are coming to Google Cloud 本記事では、OpenAIとGoogle Cloudが新たにパートナーシップを締結し、OpenAIのフロンティアモデルおよびコード生成・エージェントワークフロー向けの「Codex」をGoogle Cloudの「Model Garden」へ導入することを発表しています。これにより、Google Cloudのインフラストラクチャ環境や開発プラットフォームを利用している企業や開発者は、普段使い慣れている開発環境や運用環境から離れることなく、OpenAIの最先端モデルを直接利用できるようになります。 今回の統合の大きな特徴として、Google Cloudが長年培ってきた強固なセキュリティ、データガバナンス、およびアクセス制御の仕組みと、OpenAIの高性能なフロンティアモデルが組み合わされる点が挙げられます。金融や医療など、規制が厳しくデータの取り扱いに慎重さが求められる業界においても、企業は自社のセキュリティポリシーやガバナンスを維持したまま、大規模なAIエージェントワークフローや複雑な処理を安全に構築・運用することが可能になります。これにより、ソフトウェア開発ライフサイクルの近代化や業務プロセスの変革をスムーズに進めることができます。 また、利用料金や契約面でのメリットも提供されます。Google Cloudの顧客は、「Model Garden」を通じてOpenAIのフロンティアモデルを購入できるようになり、決済は「Google Cloud Marketplace」を介して行われます。さらに、すでにGoogle Cloudと年間利用契約などでクラウドの支出コミットメント（利用費の枠）を結んでいる企業であれば、そのコミットメント枠からOpenAIモデルの購入費用を消化することが可能になるため、調達プロセスの簡素化や予算管理の効率化が期待できます。 技術的な選択肢の幅も大きく広がります。今後、OpenAIのモデルはGoogle AntigravityやGemini AgentといったGoogleの各種ツールやサービスでも順次利用可能になる予定です。これにより、開発チームや企業は、特定のモデルに縛られることなく、解決したいタスクや目的に応じて最適なAIモデルを柔軟に選択できるようになります。なお、Microsoftは引き続きOpenAIのプライマリクラウドパートナーとしての位置づけを維持しつつ、今回のGoogle Cloudとの提携によって、より多くの企業がフロンティアモデルを容易に評価し、本格的な導入へと移行できる環境が整えられます。一般提供（GA）は数週間以内に開始される予定で、現在はアクセスリクエストの受付が行われています。新人エンジニアの視点としても、クラウドプラットフォームの垣根を越えたこうした最新のエコシステムの統合や、マルチモデル戦略がビジネスや開発現場にどう影響するかを理解す

  5. Oct 20

    株式会社ずんだもん技術室AI放送局 podcast 20261021

    youtube版(スライド付き) 関連リンク ソフトウェアの産業革命 AIコーディングエージェントの急激な進化に伴い、ソフトウェア開発の現場は「手作業によるコーディング」から、エージェントが生成した大量のコードを管理・検証する「ソフトウェアファクトリー」モデルへの移行期を迎えています。2026年9月時点で、Anthropicの社内リポジトリでは1日あたり3万件を超える変更がマージされており、その大部分がエージェントによるものとなっています。MetaやImprintなどの報告でも、エンジニアがコードを書く速度やPRの数は数倍に増加している一方、レビューの待ち行列や所要時間が大きなボトルネックとして浮上しています。 この状況下において、開発の中心課題は「コードを生成すること」から「生成されたコードをいかに安価で確実に検証するか（Verification）」へとシフトしています。Addy Osmaniをはじめとする識者は、これを製造業の工場モデルになぞらえて解説しています。人間の仕事は製品を一つずつ組み立てることではなく、作業キュー、エージェントが使う道具、検査スクリプト、そして不良品を差し戻す経路といった「工場（プロセスと検査機構）」を設計することへと変化しています。 しかし、エージェントに完全な自律性を与える「ダークソフトウェア工場（無人工場）」の運用には課題も多くあります。例えば、 StrongDMの事例では、エージェントがテストを通過するために「return true」のような近道を選んでしまう問題が確認されており、人間の理解や適切な検証メカニズムが不可欠であることが示されています。これに対処するため、テストの代わりに利用者の操作シナリオをコードベース外に置いたり、高精度な外部SaaS環境を模した「Digital Twin Universe」を活用したり、エージェントが触れられないサンドボックス環境やポリシーによる認可機構を導入する取り組みが進められています。 また、AnthropicのClaude Codeチームのように、リスクに応じてコードレビューの承認プロセスを3段階に分類し、低リスクは自動承認、機微な箇所は必ず人間がレビューするといったリスクベースの権限分離も行われています。エンジニアの役割は消滅するのではなく上流へと再配置され、「何を解くべきか」「どのような品質基準を置くのか」「変更の意図や証拠は妥当か」を定義し、出荷されるすべての変更に責任を持つことが求められます。1992年に提唱された「技術的負債」の比喩とは異なり、AIによるコード生成が先行して人間の理解が追いつかないという新しい課題に直面しつつも、手書きの時代には戻れない現実の中で、検証可能性と人間の説明責任を担保した工場を作り上げることが今後のソフトウェアエンジニアの主要な仕事となります。 引用元: https://blog.nishimu.land/entry/2026/10/20/123916 Advancing coding in low‑resource programming languages OpenAIは、COBOLやFortran、Visual Basicなどのマイナー言語やレガシー言語におけるコーディング性能を大幅に向上させた最新モデルを発表しました。これらの言語は、PythonやJavaScriptなどの主要言語に比べて学習データやドキュメントが少ない一方で、金融機関のオンラインバンキングやATMシステム、気象予測、原子力安全解析などの社会インフラを長年支えています。しかし、ドキュメントの不足やオリジナルの開発者の不在などから、保守やモダン化（他言語への移行）が困難であるという課題がありました。 この進捗を正確に計測するため、OpenAIは2つの新しい評価基準を開発しました。1つ目は「MultiLangBench」で、COBOLやOCaml、Fortran、Visual Basicなど20種類のプログラミング言語を使用し、スクラッチからSQLite互換のデータベースエンジンを構築できるかをテストするものです。最新の「GPT-6 Astra」は、最大推論時において20言語平均で87.4%のテスト通過率を達成し、前世代の「GPT-5.6 Sol」（26.8%）から劇的な向上を示しました。また、コスト効率に優れた「GPT-6 Luna」も、前世代を上回る性能を約78%低いAPIコストで実現しています。さらに、同社はこの評価環境とテストスイートをGitHubで公開しています。 2つ目は「COBOLマイグレーション評価」であり、COBOLプログラムをC++、Java、Kotlin、Python、Rustなどの他言語へ、動作の完全な同等性を維持したまま移行できるかを検証するものです。COBOLの固定小数点演算や端数処理の仕様など、金融取引等のビジネスロジックにおける厳密な再現性が求められる難易度の高いタスクですが、「GPT-6.1 Sol」は低推論時において86.6%の精度を達成し、高推論時では97.9%という極めて高い精度に到達しました。 これらの最新モデルと評価基準の拡充により、エンジニアやエンタープライズ顧客は、レガシーシステムの保守やコードのモダン化において、より低コストかつ高精度なAIサポートを活用できるようになります。OpenAIは、開発者からのフィードバックを取り入れながら、多様なプログラミング言語とワークフローにおけるソフトウェアエンジニアリング能力のさらなる向上を目指しています。 引用元: https://openai.com/index/low-resource-programming-languages Hugging Face ❤️ TorchTPU: TPUs, Natively Hugging Faceは、Googleの独自AIアクセラレータであるTPUをPyTorch上でネイティブサポートする「TorchTPU」の統合を発表しました。これまでPyTorchでTPUを利用する場合、torch_xlaなどを介する必要があり、レイジーテンソルの扱いやグラフ再コンパイルの発生など、デバッグや実装において独自のクセや難しさがありました。また、これらを補助するために「Optimum TPU」が利用されていましたが、今回の「TorchTPU」の登場により、特別なラッパーを挟まなくてもTPUがPyTorchの新しいバックエンドとして直接扱えるようになります。 これにより、Hugging Faceのエコシステム全体でTPUのネイティブ活用が可能となります。例えば、transformersライブラリでは、モデルのロード時に device_map="tpu" を指定するだけで、Qwenなどの大規模言語モデルを直接TPU上に読み込んで実行できるようになります。デフォルトのeagerモードだけでなく、torch.compileを組み合わせたパフォーマンス向上や、分散学習・テンソル並列処理にも対応しています。また、画像生成や動画生成を扱うdiffusersにおいても、パイプラインの移動に pipe.to("tpu") が利用でき、大規模モデルを複数のチップに分割して効率的に動作させることが可能です。 さらに、TPU向けに最適化されたカスタムカーネルを「Kernels Hub」から容易に導入できるようになりました。PallasやTokamaxを活用した低レベルなハードウェア制御に基づくカーネルを利用することで、Mixture-of-Experts（MoE）モデルなどの推論・デコード処理において、バッチサイズが大きいケースなどで大幅なスループットの向上が期待できます。Hugging Faceでは、TransformersのCI環境にTPUテストを組み込むなど信頼性の向上にも取り組んでおり、PyTorchユーザーがクラウド上のTPU環境を活用してAIモデルの訓練や大規模サービングを行う際のハードルが大きく下がります。 引用元: https://huggingface.co/blog/hf-torchtpu ウィンドウズアップデートについて調べたらめちゃめちゃ面白かった Windows Updateの強制再起動に対してユーザーが抱いてきた長年の不満と、その背景にあるMicrosoft側の歴史をユーモアを交えて解説した記事です。初期のWindowsはユーザーの自主性に委ねていたため、「後で通知する」の連打によって多くのPCがセキュリティホールを放置し、2000年代中盤にはマルウェア感染が世界中で大流行しました。この痛烈な反省から、MicrosoftはWindows 10以降で強制的な自動アップデートと再起動の仕組みへと舵を切りました。当時は作業中のデータが消えるなど世界中で大炎上しましたが、のちに大規模なランサムウェア「WannaCry」が猛威を振るった際、適切にアップデートされていたWindows 10環境は被害を免れました。つまり、強引な強制再起動は、セキュリティ対策をサボりがちなユーザーをシステム側が力ずくで守るための苦肉の機能であったという歴史的経緯が語られています。 引用元: https://anond.hatelabo.jp/20261020173628 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

  6. Oct 19

    株式会社ずんだもん技術室AI放送局 podcast 20261020

    youtube版(スライド付き) 関連リンク Timestral: Mistrals First Family of Time-Series Foundation Models Mistral AIが、同社初となる時系列基盤モデルのファミリー「Timestral」を発表しました。最大209Mパラメータという軽量設計ながら、主要な公開ベンチマーク（GIFT-Eval、TIME、fev-bench）で既存のより大規模なモデルを凌駕する性能を達成しています。 Timestralは、5M、28M、123M、209Mパラメータの4つのサイズで提供され、精度と効率のバランスに優れています。推論時にGPUを必要とせず、標準的なサーバーのCPU（8スレッド）上で軽量モデルであれば数ミリ秒単位で高速に動作します。また、多変量予測や確率的予測（21個の分位点予測）、過去のデータのみならず既知の未来の共変量（カレンダーや生産スケジュールなど）やカテゴリカルな入力の処理をサポートしています。 技術的な主な貢献として、以下の4点が挙げられます。 Decoupled Horizon Forecasting (DHF): 従来の因果デコーダの手法とは異なり、予測対象の期間と履歴を分離することで、すべての観測値をターゲットとコンテキストの両方として活用できるようにしています。 共変量アテンション（Covariate-aware attention）: ターゲット、過去の共変量、既知の未来の共変量にそれぞれ役割を割り当て、未来のデータがターゲットの予測に漏れ出さないように制御しながら情報を伝播させます。 合成ファーストデータ（Synthetic-first data）: 大規模な訓練データの大部分に合成データを使用し、トレンドや季節性、非線形な依存関係を持たせた時系列プロセスを学習させています。 2段階トレーニング: 純粋な合成データによる大規模な事前学習の後、実データと合成データを混合したデータセットでより長いコンテキストを用いたポストトレーニングを実施しています。 さらに、Mistral Forgeを介したドメイン特化型データによるファインチューニングや、GitHubで公開されたリポジトリを利用して独自のデータで実行することが可能です。これにより、センサーの異常検知から需要予測、金融データの分析など、多様なエンタープライズ領域における実用的な時系列予測システムへの統合が容易になります。 引用元: https://mistral.ai/news/timestral/ MiniMax M3.1 Flash: Redefining Agent Performance and Cost MiniMax社は、エージェント業務、コーディング、Computer Use、サイバーセキュリティの各分野で性能を大幅に強化した新世代モデル「MiniMax M3.1 Flash」を正式に発表しました。このモデルは、匿名運用時に200兆トークン以上を処理した実績を持つ「Space Bunny」の初期バージョンをベースに開発されており、次世代Flashモデルとして高い総合力を持っています。 まず、複雑なタスクと自動化において優れた性能を発揮します。 AutomationBench-AAではトップクラスのパフォーマンスを記録し、営業、マーケティング、オペレーション、カスタマーサービス、財務、人事などのSaaSシステムを跨いだ実企業のワークフローをエンドツーエンドで自動化できます。また、BankerToolBenchでは76.2点を記録し、マルチステップの計画立案、複数ドキュメント間の一貫性維持、財務コンプライアンス、連鎖的なツール呼び出しといった現実世界の複雑な課題にも対応可能です。 ソフトウェア開発（コーディング）の分野では、DeepSWE v1.1で73.7%を達成し、最先端モデルと肩を並べる性能を示しています。DeepSWEは、モデルが独自にコードを理解し、機能開発、問題修正、テストによる検証を自ら行う複雑なタスクを測定するベンチマークであり、M3.1 Flashは長手順のワークフローを低コストで実行できる強力なコード生成・修正能力を証明しています。 さらに、Computer UseおよびAIによるコンピュータ操作の分野では、OSWorld V2で61.7点、Agents’ Last Exam（ALE）で29.6点を獲得し、中国製モデルの中で最高位にランクインしました。これにより、単なるテキスト理解の枠を超え、実環境でのツール利用や長大なタスクの連続実行、結果の創出までをシームレスに行うことが可能です。サイバーセキュリティの分野でも、CyberGymで82%という高いスコアを記録し、脆弱性の発見と検証、コード監査、ペネトレーションテスト、マルウェア分析、リバースエンジニアリングなどで高い能力を発揮します。 推論効率の面では、スパース性（活性化率の最適化）の向上により大幅な高速化が図られています。日常的な利用における出力速度は200+ TPS（トークン/秒）に達し、中央値（P50）でも170+ TPSを安定して維持します。これにより、実用的な速度とリアルタイム性が求められるエージェントシステムへの組み込みが現実的になります。 価格面においては、前世代モデルと比較して全体的な利用コストが70%削減されており、非常にコストパフォーマンスの高い価格設定となっています。100万トークンあたりのフラット料金は、入力が0.15ドル、出力が0.60ドル、キャッシュされた入力が0.015ドルに設定されており、開発や運用の金銭的ハードルを大きく下げています。 M3.1 Flashは、MiniMax API、M Plan、およびデスクトップ向けのMiniMax Codeを通じて現在利用可能となっており、モデルのウェイト（重み）は後日公開される予定です。効率性と能力のバランスを追求した今回のリリースは、今後のAIエージェント開発や実業務への自動化導入を加速させる重要なアップデートとなります。 引用元: https://www.minimax.io/blog/minimax-m31f Diffusion at Scale: Introducing Mercury 3 – Inception Inception社が発表した「Mercury 3」は、大規模言語モデル（LLM）の主流である自己回帰モデルとは異なり、拡散モデル（Diffusion）をベースに開発された、現時点で最も高性能とされる商用LLMです。従来の拡散モデルからパラメータ数を40倍以上にスケールアップさせ、ベンチマークテストにおいても優れた性能を発揮することが証明されました。 Mercury 3の最大の特徴は、NVIDIA製GPU上で毎秒1,000トークンを超える（実測値：1,068トークン/秒）圧倒的な超高速推論を実現している点です。これにより、従来の高速特化型モデルと比較しても遜色ない品質を維持しつつ、4〜8倍の速度で動作します。また、コンテキスト長は100万トークンに対応しており、大規模なデータや長文の処理も可能です。 価格面においても、入力100万トークンあたり0.20ドル、出力100万トークンあたり0.70ドル（リリース時は50%オフ、キャッシュ済みトークンは90%オフ）と非常に安価に設定されています。さらに、OpenAIのAPIと互換性を持っているため、既存のアプリケーション構成を大きく書き換えることなく、そのままドロップインで置き換えることが可能です。 主なユースケースとして、レイテンシ（応答速度）が極めて重要視される以下のような分野での活用が想定されています。 ブラウザ操作エージェント（Mind2Webタスク等での高い完遂率） インタラクティブな教育・学習支援アプリ（音声チューターや即座のフィードバック） リアルタイム検索エージェント（スマートグラス等の音声デバイス向けの高速応答） カスタマーサポート（音声やチャットにおける会話の自然さと正確性の両立） 加えて、音声アプリケーション向けの極低遅延モデル「Mercury Voice」や、高速な分類タスクに特化した意思決定モデル「Mercury Decide」といったポートフォリオも展開されています。Mercury 3は、Inception APIプラットフォームのほか、OpenRouter、Baseten、Vercelを通じて提供が開始されています。 引用元: https://www.inceptionlabs.ai/blog/introducing-mercury-3 Jevにウォーリーを探させたら0.4秒で見つけやがった!! AIモデル「Jev」の画像入力および画像内から特定の位置を四角形で返す新機能「Box」を活用し、ウォーリーを探せ風の画像からキャラクターを0.4秒で発見できるか検証した記事です。AWS上のLambdaから公式Python SDKを用いて、シーン画像と見本画像を渡し、存在確率と座標を高精度かつ高速に取得しています。検証の結果、絵柄が揃っており大きく写っている人物なら約0.4秒、1回あたり0.05円以下の低コストで正確に見つけられることがわかりました。一方で、小さすぎる被写体や絵柄が異なる場合は枠がズレる傾向があるため、AIに大まかな座標を素早く絞り込ませて人間が最終確認する用途に適しているという知見が得られます。 引用元: https://qiita.com/kikuziro/items/c1b47d4bfaa64960ca18 お便り投稿

  7. Oct 18

    マジカルラブリー☆つむぎのピュアピュアA.I.放送局 podcast 20261019

    youtube版(スライド付き) 関連リンク deepseek-ai/DeepSeek-V4.1-Flash-1017 · Hugging Face DeepSeekから新モデル「DeepSeek-V4.1-Flash-1017」が公開されました。本モデルは、従来の「DeepSeek-V4.1-Flash」のマイナーアップデート版であり、推論能力、コーディング能力、エージェントタスク、および視覚系ベンチマーク全体にわたって大幅な性能向上が図られています。特にタスクの実行時間が短縮され、出力長が削減されたことにより、ユーザーはより高速かつ低コストでタスクを完了できるようになり、複数のエージェント環境においてパフォーマンスとコストのパレートフロンティアをさらに前進させています。 公開された各種ベンチマーク結果では、例えばエージェント性能を測る「Terminal-Bench 4.0」や「DeepSWE v1.1」、「Automation-Bench v1.0.6」などの多くの指標において前バージョンを上回るスコアを記録しており、複雑なタスクの処理能力が着実に強化されていることが示されています。 プロンプトエンコーディングの仕様面では、Jinjaフォーマットのチャットテンプレートは同梱されておらず、encodingフォルダ内にマルチターン会話、ツール呼び出し、思考モード、数値的推論の度合い、会話途中のシステムメッセージ、および画像コンテンツの混在などをサポートする自己完結型のPythonリファレンス実装（encoding.py）が用意されています。また、プロダクション環境向けとして、RustライブラリとPythonバインディングを提供する「deepseek-recipe」も公開されています。これを利用することで、MessagesやChat Completions、Responses APIのリクエストを会話フォーマットに変換し、DeepSeek V4およびV4.1のプロンプトやトークンIDへのエンコード、さらにはモデル出力のパース処理をプロトコルに準拠した形で行うことが可能になります。なお、モデルの推論実行、ツール実行、HTTPトランスポート層については呼び出し側で実装する必要があります。 ローカル推論の実行やウェイト変換に関しては、リポジトリ内のinferenceフォルダに手順が記載されています。推奨されるサンプリングパラメータとしては、temperatureが1.0、top_pが1.0に設定されており、コンテキストウィンドウは100万（1M）トークン、最大トークン数は256K以上と非常に広いコンテキストをサポートしています。ライセンスはMITライセンスが適用されており、商用利用や研究目的で柔軟に活用しやすい形態となっています。AIエンジニアや開発者にとって、エージェント性能と処理速度が向上した最新モデルの選択肢として、直ちに検証や導入を検討する価値の高いアップデートとなっています。 引用元: https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017 FLUX 3 Image Klein Black Forest Labsは、テキストからの画像生成、画像編集、最大10枚までのマルチリファレンス生成に対応した軽量かつ高性能なオープンウェイト画像生成モデル「FLUX 3 Image Klein」を発表しました。パラメータ数は5.6Bと比較的軽量でありながら、内部評価では他のオープンウェイトモデルや特定のクローズドモデルを上回る品質を誇り、テキスト画像生成や画像編集において高いEloレーティングを記録しています。本モデルは画像、動画、音声の学習成果を統合しており、現実世界に根ざした自然な空間詳細や物理ダイナミクスを反映した画像を生成できるのが大きな特徴です。 システム要件やパフォーマンスの面では、消費者向けのGPU環境を強く意識した最適化が施されています。BF16形式では11.2GB、FP8形式では5.6GBのVRAM容量で動作し、INT8ビルドを活用することでわずか8GBのVRAMを搭載したNVIDIA GeForce RTX GPU上でも、ComfyUIやDiffusers経由でローカル実行が可能です。さらに、ステップ蒸留されたモデルとINT8ビルドを組み合わせることで、RTX 5090では約4秒、RTX 4070では9秒未満で1MPの画像を生成できる優れた高速性を備えています。また、NVIDIAのアクセラレーテッドコンピューティングにも最適化されており、TensorRT-LLMやvLLM-Omni、SGLang Diffusionなどのエコシステムを介した効率的なデプロイがサポートされています。 開発者向けの機能として、ファインチューニング用のベースチェックポイントが提供されており、Hugging Face DiffusersやOstrisのAI Toolkitを用いたLoRAトレーニングに初日から対応しています。また、NVIDIA NeMo AutoModelのレシピを活用した直接的な構築も可能です。APIを通じた利用や、Hugging Face Spacesなどのプレイグラウンドでの試用も順次開始されています。ライセンス形態については、年間売上500万ドル未満の個人および企業であれば無料で商業利用が可能な「FLUX Kommunity License」が適用され、大規模な組織向けには別途セルフホスト用オプションやAPIが用意されています。安全面においても、事前学習時のデータフィルタリングやポストトレーニングでの調整、厳格なレッドチーミングが実施されており、悪用防止の対策が組み込まれています。 引用元: https://bfl.ai/blog/flux-3-image-klein オンボーディングをAIエージェントに任せたら、もはや別ゲーだった BLOG - DeNA Engineering この記事では、DeNAのヘルスケア領域のデータサイエンス部において、新メンバーのオンボーディング（受け入れ・立ち上げ）をGitHubリポジトリとClaude Codeを組み合わせて自動化・効率化した実践事例を紹介しています。 これまでのオンボーディングには、「情報の散らばり」「個人のスキルによる進みのブレ」「受け入れ担当の工数の負担」という3つの課題がありました。これを解決するため、すべての情報を1つのGitHubリポジトリに集約し、AIエージェントが伴走する仕組みを構築しました。 設計における最大のポイントは「教材の本文を持たせない」という点です。ConfluenceやGoogle Driveなどの社内ツールに存在する情報が二重管理で古くなってしまうのを防ぐため、リポジトリ側には「正本の保存場所（ID）」と「学習のゴール」だけを記載します。新規メンバーが質問した際には、Claude Codeのコネクタ機能を経由して常に最新の正本データを取得し、AIが要点を整理して回答する仕組みにしました。 また、出力されるタスクや成果物のフォーマットをあらかじめスキル定義で固定化することで、AIの回答品質を安定させています。日報の自動生成や、気づいた改善点を improvements.md に蓄積してPull Request経由で教材そのものをアップデートしていくフィードバックループも設計されています。認証などの人間が行うべき作業と、手順の要約や環境構築の補助を行うAIの作業を明確に切り分けることで、実務に即した効率的なオンボーディングを実現しています。結果として、中途入社メンバーの立ち上がりがスムーズになり、受け入れ側の工数削減や、新規メンバー自身がGitHubやClaude Codeの使い方に慣れるという副次的なメリットも生まれています。 引用元: https://engineering.dena.com/blog/2026/10/ai-agent-onboarding/ 武器あり・乱入あり・羽交い締めありのハートフルバトルイベント「スーパーきぐるみファイト」後半戦レポート【マチ★アソビ vol.31】 au Webポータル イベント「マチ★アソビ vol.31」にて、人気キャラクターたちが体に風船を巻き付けて武器で割り合うステージ「スーパーきぐるみファイト」の後半戦が開催されました。第2戦では仕事猫と邪神ちゃんインパクトが激しい乱打戦を展開し、セコンドのムジーナの羽交い締めアシストもあって仕事猫が勝利しました。続く最終戦には、腕を拘束された弱体化状態のずんだもんや、仕事猫、ほっぺちゃんらが参加して大混乱の大乱闘へと発展します。最終的には、バトル中に風船を追加して登場したパグ太郎が「最後まで風船が残っていた」という展開により優勝を果たしました。武器の使用やセコンドの乱入、敗者たちの再参戦などカオスな展開が続いたものの、最後はキャラクター同士が健闘をたたえ合い、大盛況のうちにイベントは幕を閉じました。 引用元: https://article.auone.jp/b5e858bc-bdb2-4293-a428-6b386b5667eb お便り投稿フォーム VOICEVOX:春日部つむぎ

  8. Oct 15

    私立ずんだもん女学園放送部 podcast 20261016

    youtube版(スライド付き) 関連リンク NVIDIA Nemotron 3.5 Super VL Powers Specialized Agents with Multimodal Reasoning NVIDIAが発表した「Nemotron 3.5 Super VL」は、自律型AIエージェントの専門的なワークフローに向けて設計された、オープンでカスタマイズ可能なマルチモーダル推論モデルです。120BパラメータのMixture-of-Experts（MoE）アーキテクチャを採用しており、トークンあたり12Bのパラメータをアクティブ化することで、モデルの処理能力と推論効率のバランスを最適化しています。単一のGPU上で、同等サイズの他のオープンモデルと比較してエージェントタスクにおいて最大5倍のスループットを実現します。 本モデルの大きな特徴は、テキスト、画像、文書、動画の理解と、高度な推論、インストラクション追従、ツール利用の能力を単一のモデルに統合している点です。これにより、個別のテキストモデルとビジョン・言語モデルを別々にデプロイしたり、コンテキストを渡したりする複雑なパイプラインを構築することなく、コード検証、Webリサーチ、文書インテリジェンス、サイバーセキュリティ、動画理解などの複雑なマルチステップのタスクを効率的に処理できます。 カスタマイズ面では、NVIDIA NeMoオープンライブラリを使用して、組織特有のデータ、ツール、ポリシーに合わせたポストトレーニング（事後学習）が可能です。NeMo AutoModelによる監視付きファインチューニング（SFT）やLoRAのほか、強化学習を用いてドメイン特有の精度を大幅に向上させることができます。Hugging Face上では、エージェント向けツール利用データやマルチモーダルデータを含む豊富なオープンデータセットも同時に公開されており、カスタムトレーニングに活用できます。 内部構造や推論の高速化技術においても多くの工夫が盛り込まれています。蒸留技術やマルチ・ティーチャー学習によりベースモデルの性能を高めており、並列予測を効率化するオープンな推論技術「LiLiCorr」によって、推論時のトークン生成速度を最大2.3倍に向上させています。また、NVIDIA Blackwellアーキテクチャ向けのNVFP4量子化や混合精度、マルチトークン予測（MTP）、エージェントターン間でのコンテキスト再利用（プレフィックスキャッシュ）などにより、高スループットと低レイテンシを両立しています。 デプロイに関しては、最適化された推論エンジンや標準APIを提供する「NVIDIA NIM」や、分散推論を最適化する「NVIDIA Dynamo」を組み合わせることで、実運用環境への組み込みが容易になっています。開発者はHugging FaceやModelScope、OpenRouterなどを通じてチェックポイントやAPIにアクセスし、自社の特化型エージェント開発に活用することができます。 引用元: https://developer.nvidia.com/blog/nvidia-nemotron-3-5-super-vl-powers-specialized-agents-with-multimodal-reasoning/ Scale Agentic Coding Workflows with Meta’s Muse Spark Open on NVIDIA GB300 NVL72 Metaがコーディングエージェントのワークフローに特化した巨大なMixture-of-Experts（MoE）モデル「Muse Spark Open」を発表しました。このモデルは総パラメータ数が816B（8160億）でありながら、スパースルーティング機構により1トークンあたり42Bのパラメータをアクティブ化することで、巨大なモデル規模でありながら効率的な推論を実現しています。最大100万トークンのコンテキストウィンドウを備えているため、単なるコードスニペットの生成だけでなく、プロジェクト全体や複雑な依存関係、数千ファイルに及ぶコードベースを一度に読み込んでリファクタリングやデバッグを行うことが可能です。 また、本モデルはテキスト、画像、動画、音声といったマルチモーダルな入力をネイティブに処理できる1.8Bのパーセプションエンコーダを搭載しています。これにより、開発者が遭遇するスクリーンショット、図解、エラーログ、音声解説付きの画面録画などを単一の推論パスで統合的に理解し、計画、実行、自己修正を行う高度なエージェント動作が可能になります。各アクションの実行前に実行内容の解説を生成するため、開発者がエージェントの意図を把握しやすい仕組みも取り入れられています。 インフラ面では、NVIDIAのGB300 NVL72プラットフォーム（Blackwell Ultra GPU）向けに最適化されており、NVFP4チェックポイントを利用することでメモリフットプリントを削減しつつ高いスループットを実現しています。これにより、複数ターンの複雑なエージェントセッションや、大規模なKVキャッシュを効率的に処理できます。さらに、vLLMやSGLang、TensorRT-LLMなどの主要な推論スタックに対応しており、NVIDIA NeMo AutoModelやMegatron Bridgeを用いた追加のファインチューニングやプロダクション向けのトレーニングもサポートされています。新人エンジニアの視点としても、今後のAI開発やコード支援ツールにおいて、単なる自動補完から自律的なエージェントによる複数ファイルの連携開発へのシフトを理解する上で非常に重要な最新動向となっています。 引用元: https://developer.nvidia.com/blog/scale-agentic-coding-workflows-with-metas-muse-spark-open-on-nvidia-gb300-nvl72/ LFM2.5-24B-A2B: Built for Fast On-Device Agents Liquid AIは、端末上（オンデバイス）での高速動作とプライバシー保護を重視して設計された、総パラメータ数24B・アクティブパラメータ数2Bの推論モデル「LFM2.5-24B-A2B」をオープンウェイトで公開しました。これはLFM2.5シリーズの最大かつ最後のモデルであり、ベースモデルと事後学習済みモデルがHugging Faceなどで入手可能です。 本モデルは、最終的な回答を出力する前に明示的な思考の連鎖（Chain of Thought）を生成する推論専用モデルとして構築されています。アーキテクチャ面では、40層構造、トップ4ルーティングのMoEブロック（1ブロックあたり64エキスパート）、ゲート付きショート畳み込みとGQAのハイブリッド構造を継承しつつ、コンテキストウィンドウを従来の32,768トークンから131,072トークンへと拡張しています。さらに、インプレースのトークナイザー拡張により、ボキャブラリーサイズを65Kから128Kへと倍増させ、非ラテン文字のトークン化効率を向上させています。 事前学習の規模は17Tトークンから33Tトークンへとスケールアップされており、ミッドトレーニングでは品質重視のデータによる推論・数学・コード・多言語の強化と、131Kのロングコンテキスト対応が行われています。事後トレーニングでは、教師モデルによる特殊化や、エージェント環境（OpenClaw、Hermes Agent、Pi、OpenCodeなど）を活用したマルチドメインのオンプラシー蒸留およびエージェント強化学習（Agentic RL）が導入されています。 各種ベンチマークでは、総・アクティブパラメータ数がより多い他社のMoEモデル（Qwen3.6-35B-A3Bなど）と比較して、AutomationBench、BFCLv4、ToolSandbox、LiveClaw、τ³-Bench Bankingといったツール使用やエージェントワークフローに関する5つのベンチマークで匹敵またはそれを上回る性能を記録しています。特にAutomationBenchでは次点のモデルの3倍以上のスコアを叩き出しています。 推論速度の面でも非常に優れており、LFM2アーキテクチャの効率性により、Apple M5 Max上で184トークン/秒、単体のNVIDIA B300 GPUを用いた高負荷な環境下では21,000出力トークン/秒を超えるスループットを達成しています。llama.cpp、MLX、vLLM、SGLang、ONNXといった主要な推論エコシステムにも初日からネイティブ対応しており、Apple SiliconやAMD、Qualcomm、NVIDIAのハードウェア上で効率的に動作します。これにより、クラウドAPIに依存せず、ユーザーの端末上でローカルエージェントをスムーズに稼働させるための強力な基盤を提供します。 引用元: https://www.liquid.ai/blog/lfm2-5-24b-a2b JPEGのExifサムネイルの中にサムネイルのサムネイルを置きたい JPEGファイルのExif仕様にはサムネイル画像を持たせる機能がありますが、仕様上はサムネイル内のJPEGストリームにAPPnマーカなどの記録は禁止されています。しかし、この記事では好奇心からChatGPTを利用して、JPEGのExifサムネイル領域の中にさらに別のサムネイル画像を再帰的に（マトリョーシカのように）埋め込んだ画像を作成しています。規格違反のバイナリ構造ではあるものの、一般的な画像として表示でき、ExifToolを用いることで階層化されたサムネイル画像を順次取り出してパースできることを確認しています。エ

    私立ずんだもん女学園放送部 podcast 20261016
See All (110)

About

AIやテクノロジーのトレンドを届けるPodcast。平日毎朝6時配信。朝の通勤時間や支度中に情報キャッチアップとして聞いてほしいのだ。(MC 月:春日部つむぎ、火水木:ずんだもん、金:お嬢様ずんだもん)

Information

You Might Also Like