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

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

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

  1. 20h ago

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

    youtube版(スライド付き) 関連リンク Gemini Decisions API: Fast, calibrated multimodal decisions Googleは、マルチモーダル入力に対して高速かつ正確な決定処理（Yes/No、複数選択、ルーブリック採点）を行う新しいAPI「Gemini Decisions API」および専用モデル「Gemini Decision 1」を発表しました。このAPIは、テキスト、画像、音声、動画、PDFといった多様なマルチモーダル入力を受け付け、最大1,000問の質問を単一のフォワードパスで同時に評価できるのが特徴です。従来のAIのようにトークンを1つずつ生成するのではなく、オプション候補の確率や信頼度スコアを直接算出するため、エンドツーエンドの遅延が150〜250msと極めて高速に動作します。新人エンジニアが実際の開発で活用できるように、主な特徴や仕組み、料金体系などを詳しく解説します。 まず、Gemini Decisions APIの最大のメリットは、クローズドセット（限定された選択肢）の判断処理に特化している点です。ツール選択、ポリシーチェック、モデルルーティング、コンテキストのグレーディングといった用途において、専用のプリミティブを提供します。提供される質問タイプには、Yes/No条件の確率を推定する「noul」、2から255の選択肢から勝者と確率を返す「multiple choice」、0から始まる順序付きルーブリックで連続的な重み付きスコアを返す「score」の3種類が用意されています。すべての回答に0から1の信頼度スコアが含まれるため、コード側で曖昧なケースを検知してフォールバック処理や人間によるレビューへルーティングするといった実装が容易に行えます。 料金体系においても大きな特徴があります。Gemini Decision 1は、入力トークン100万あたり0.10ドルで利用できる一方、出力トークンは課金対象外（0ドル）となっています。複数の質問を評価する場合でも、共有される入力データはリクエストごとに1回のみ課金され、質問ごとの指示や基準のトークンのみが追加される仕組みです。これにより、音声認識やOCRの別料金や可変の思考トークン料金を気にすることなく、コストを抑えてシステムに組み込むことができます。Python用の「google-genai」SDKが用意されており、クライアントを初期化してclient.decisions.createメソッドを呼び出すだけで、画像やテキストなどのマルチモーダルな入力と複数の質問を組み合わせたリクエストを簡単に記述できます。 Google社内でもすでに多くのチームが低遅延なコントロールプレーンとしてこのAPIを採用しています。例えば、Gemini Notebookではリアルタイムルータとして使用され、入力クエリの意図をミリ秒単位で分類して適切なモデル階層に振り分けることでレイテンシを最大40%削減しています。また、Google検索におけるMCPツールの安全レイヤーや、Google LabsのCCにおける絵文字選択機能などでも活用されています。エコシステムとしても、OpenRouter、LangChain、Vercel、LiteLLM、Pydantic AI、Pipecat、LiveKit、OpenCodeなどの主要なツールやフレームワークと統合されており、Google AI StudioのAPIキーを取得すればすぐにプロトタイピングを開始できるため、AI機能を組み込むシステムを開発するエンジニアにとって非常に強力な新しい選択肢となります。 引用元: https://blog.google/innovation-and-ai/technology/developers-tools/gemini-decisions-api/ Attention to Mamba: A Recipe for Cross-Architecture Distillation Appleの機械学習研究チーム（論文著者にはコンコルディア大学/MILA、ジョンズ・ホプキンス大学/フラティロン研究所の研究者らが含まれる）による、TransformerモデルからState Space Model（SSM）の一種であるMambaアーキテクチャへ知識を効率的に移行（クロスアーキテクチャ蒸留）するための手法に関する研究記事です。 近年、MambaなどのSSMは、Transformerと比較して生成時のメモリ消費量が少なく、より高いスループットを実現できる代替手段として注目を集めています。しかし、Transformerの学習に関する知見や既存の事前学習済みモデルが豊富に存在する一方で、TransformerからMambaへ単純に知識蒸留を行うだけでは、教師モデル（Transformer）の性能を十分に維持できないという課題がありました。従来はこの問題を回避するために、AttentionとSSMを組み合わせたハイブリッドな構成が取られていました。 本記事で提案されている手法の核心は、Mambaに適切な初期化を施すことで、アテンションブロックを一切含まない純粋なMambaアーキテクチャへの効果的なクロスアーキテクチャ蒸留のレシピを実現する点にあります。この目的を達成するため、論文では以下の2段階のアプローチが提案されています。 カーネルトリックの適応を用いて、従来のTransformerから「線形化されたアテンション（linearized version of Attention）」へ知識を蒸留する。 その線形化されたモデルから、アテンションブロックを全く使用しない、適応型のMambaモデルへ知識を蒸留する。 この2段階のアプローチにより、蒸留されたMambaモデルは元のPythia-1B Transformerの性能の大部分を維持することに成功しています。具体的には、教師モデルのパープレキシティが13.86であるのに対し、蒸留されたMambaモデルは14.01という近い数値を達成しています。これは下流タスクの多くにも引き継がれますが、インコンテキスト・リコール（文脈内の記憶・想起）に依存する一部のタスクでは依然として若干の性能差が見られます。 さらに本研究では、1B規模のモデルと10Bトークンを使用し、シーケンスミキサーアーキテクチャを変化させた徹底的なアブレーションスタディ、モデルサイズや総蒸留トークン数に関するスケーリング分析、および各段階間でのトークン割り当てに関する感度分析も行われており、SSMの効率的な導入を目指すエンジニアや研究者にとって示唆に富む内容となっています。 引用元: https://machinelearning.apple.com/research/attention-mamba-distillation Agent Substrate: Advancing Kubernetes for Agents at Scale AIエージェントや強化学習（RL）のポストトレーニングにおいて、Kubernetes環境での実行効率を最適化するためにNVIDIAが開発・CNCF Sandboxへ寄贈したオープンソースのランタイム「Agent Substrate」について解説されています。従来のKubernetesでは、エージェントの1セッションごとに1つのPodを起動するとメモリが無駄になり、セッションごとにPodの作成・削除を繰り返すとコールドスタートの遅延や状態の喪失が発生するという課題がありました。Agent Substrateは、少数のワーカーPodプール上で多数のセッションを多重化（マルチプレックス）し、アイドル時にはメモリやファイルシステムなどの状態を含めてチェックポイント（スナップショット）として保存・復元することで、高密度かつ高速な実行を実現します。 具体的なユースケースとしては、コーディングアシスタント、強化学習の環境構築、研究用GPUサンドボックスの3つが挙げられています。コーディングアシスタントではリポジトリのクローンやビルド、テスト環境の状態を維持しながら迅速に応答する必要があり、強化学習では数万〜数十万規模のCPUヘビーな環境を効率的にさばく必要があります。また、研究用としては共有クラスター上でGPUサンドボックスを高速に起動・削除する仕組みが求められます。 さらに、上流での主な取り組みとして、ワーカーが満杯の際にリクエストを一時待機させる「リクエスト・パーキング」機能や、サンドボックス内でエージェントにGPUを割り当てるKubernetes Dynamic Resource Allocation（DRA）への対応、およびマイクロVMサンドボックスにおけるコンテナごとのCPU・メモリ制限などが進められています。これにより、暴走したコンテナが周囲の環境を巻き込んでクラッシュするのを防ぎます。 また、NVIDIAの分散推論フレームワーク「NVIDIA Dynamo」との統合により、エージェントのループ（モデル呼び出し、ツール実行、観測）と推論ループを協調させることが可能です。Dynamoのルーターは、KVキャッシュの保持状況やGPUプールの負荷状況を把握し、エージェント側からのセッション情報や優先度といったシグナルと連携することで、推論の最適化やGPUリソースの効率的な利用を実現します。これにより、インフラ全体のリソース使用率を向上させつつ、エージェント基盤のスケールを支える設計となっています。 引用元: https://developer.nvidia.com/blog/agent-substrate-advancing-kubernetes-for-agents-at-scale/ 「また

  2. 1d ago

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

    youtube版(スライド付き) 関連リンク Gemini 4 Carbon is now available Google DeepMindは、高度な推論能力と長期的なエージェント型ワークフローに特化した最新のフロンティアAIモデル「Gemini 4 Carbon」の一般提供を開始しました。Carbonは、複雑なマルチステップのコーディングやデバッグ、オープンエンドな科学的発見、高度なサイバーセキュリティ対策など、モデルの知性の限界を試すタスク向けに設計されています。すでに発表されている「Gemini 4 Argon」が通常のソフトウェアエンジニアリングや知識労働の大部分に適しているのに対し、Carbonはより多くのトークンを使用して深く推論し、拡張検証ループを実行します。 主な特徴として、高精度な知識労働、エージェント型コーディング、サイバーセキュリティ、科学的推論の各領域で優れたパフォーマンスを発揮します。開発者向けには、Google AI StudioのAPIやGoogle Antigravityなどのツールを通じて提供され、価格はArgonと同等に設定されています。知識労働の分野では、法的・財務的データなどの大規模な文書を視覚的に理解し、正確なスプレッドシートやレポートを生成します。コーディングにおいては、マルチパッケージの移行やクロスサブシステムの根本原因調査など、マルチエージェント協調を必要とするタスクで高い成果を上げます。サイバーセキュリティ分野では、Fairwindプログラムなどを通じて脆弱性の発見やパッチ生成を強力にサポートし、高い防御性能と安全性を実現しています。科学技術の分野でも物理学、数学、生命科学の推論やタンパク質構造予測などで研究を加速させており、開発者、企業、科学者に向けて順次提供が拡大されています。 引用元: https://deepmind.google/blog/gemini-4-carbon-is-now-available/ Safely scaling multi-agent teams with Claude Fable 5.2 本記事では、Anthropic社が実施した「Claude Fable 5.2」の初期バージョンを用いた1,000体のマルチエージェントチームによる大規模な実験について解説しています。この実験の目的は、ドメイン特化型のプラットフォームや人間の細かい指示なしに、汎用的なツール（GitやPostgreSQLなど）の組み合わせのみで、エージェントチームが長期にわたる難問（数学の難問である「フェルマーの最終定理」の形式化）を自律的に解決・スケーリングできるかを検証することです。 実験では、1体のリーダーエージェントと999体のヘルパーエージェントで構成される階層構造を採用しました。各エージェントはインターネットアクセスを持たない個別のサンドボックス環境で動作し、シェルとファイルエディタ、Leanのツールチェーン、Gitブランチ、共有のPostgreSQLデータベースを利用しました。リーダーエージェントは、タスク管理や進捗共有のために自らデータベース内に「Announce」「Assign」「Notes」「Subtasks」「Landed」という5つのテーブルを構築し、チーム全体の調停を行いました。 作業の進め方として、初期段階ではリーダーがタスクを各ヘルパーに割り当てましたが、時間経過とともにエージェント自身が自律的にタスクの細分化や再割り当てを行うようになりました。特に、プロジェクト後半で最も難易度の高い「ラングランズ・ツンネル予想」の証明においては、単一のエージェントでは扱いきれない巨大な課題に対して、エージェント同士が再帰的にタスクを10階層、計2,418個に及ぶツリー状に分割して並行処理を行い、最終的にフェルマーの最終定理の証明を完了させました。このプロセス全体は28.7時間で完了し、過去の人間と数十体のエージェントによる手法と比較して、出力トークン数は3分の1、証明の長さは7分の1に短縮されました。 安全性に関してAnthropic社は、サンドボックス化、リアルタイム監視、オフライン監視の3つのレイヤーを組み合わせています。通信の制限、Gitのマージ制御、データベースのアクセス権限およびリソース制限、カーネルの保護、ネットワーク遮断などの厳格なサンドボックス対策を施しました。さらに、ツール呼び出しをブロックするプロンプトベースのLLM分類器を活用したリアルタイム監視や、推論の過程（Chain of Thought）やエージェント間通信を確認するモニタリングを導入し、エージェントの暴走やサンドボックスからの脱出を防ぎながら安全に実験を運用できることを示しています。新人エンジニアにとっても、大規模なマルチエージェントシステムの自律協調動作、データベースを活用した非同期連携、厳格なセキュリティ・サンドボックス設計の重要性を学ぶ上で非常に有益な事例となっています。 引用元: https://claude.dev/blog/safely-scaling-multi-agent-teams-with-fable-5-2/ Our newest TPUs: 8tx and 8i Max, built for the agentic era Googleは、AIエージェント時代に向けた第8世代TPUポートフォリオをさらに拡大し、「TPU 8tx」および「TPU 8i Max」の2つの新しいハードウェアシステムを発表しました。これらは従来の大規模学習向け「8t」やリアルタイム推論向け「8i」を補完し、1年間に4つの異なるTPUシステムを投入する強力なラインナップを構成しています。 「TPU 8tx」は、セキュリティと機密性に特化した推論および小規模学習向けのシステムです。5世代目AMD EPYC CPUホストと組み合わされ、ハードウェアレベルでデータ暗号化と隔離を行うことで、機密データを扱いつつ安全にモデルのファインチューニングやエージェントの強化学習を実行できます。一方、「TPU 8i Max」は、メモリーのボトルネックを解消するために2つのTPU 8iチップを1つのパッケージに統合したシステムです。これにより、2倍の演算性能、SRAM、HBM帯域を実現し、大規模なコンテキストウィンドウを持つワークロードでもパフォーマンスを維持します。 ハードウェアだけでなく、ソフトウェアエコシステムのオープン化と使いやすさの向上も図られています。PyTorchやHugging FaceモデルをTPU上でネイティブに実行できる「TorchTPU」がオープンソース化され、vLLMやSGLangなどの推論エンジンもサポートされています。また、Claude CodeやCursorなどのコーディングツールから自然言語でTPUの最適化を行える「TPU agent suite」や、PythonでモデルをトレーニングしC++ランタイムで低レイテンシに提供する「XLA Serving Engine」が導入されました。 さらに、AIエージェントのアイドル時間を管理してコストを削減する「Agent Compute Engine」、HBMやDRAM、ストレージを統合してKVキャッシュの転送遅延などを大幅に削減する「TPU Sync」、Google Kubernetes Engine（GKE）上で単一コントローラによる分散MLランタイムを提供する「Cloud Pathways」、そして物理プロビジョニングと論理スライス形成を切り離してジョブ起動時間を短縮する「GKE dynamic slicing」など、多岐にわたる機能が提供されています。これらにより、開発者は最新のTPUインフラストラクチャをより手軽かつ効率的に活用できるようになります。 引用元: https://blog.google/innovation-and-ai/infrastructure-and-cloud/global-network/tpu-8i-max-and-8tx/ 今日から職場体験で中学生が来てるけど ゲームとかする？→しないです アニメとか漫画は？→見ないです 好きなスポーツは？→特に… とかで暗い子やなーって絶望的な沈黙になったけど 趣味は？って聞いたらガンプラですってきて、どんなガンダムが好きか聞いたら→「アニメとか漫画は？って聞かれた時点でガンダムって答えないのがめっちゃ真のオタクって感じする」 職場体験にやってきた中学生との会話を通じた、クスッと笑える日常のエピソードです。初めはゲームやアニメ、スポーツの質問に対して「しない」「見ない」「特にない」と返答があり、会話が弾まず沈黙の雰囲気になってしまいました。しかし、趣味として「ガンプラ」を挙げたことをきっかけに、好きな作品について急に早口で熱く語り出す様子が描かれています。大人からの「アニメや漫画を見るか」という問いに対して、あえてガンダムを即答しなかった点に、独特のこだわりやオタク気質を感じさせるやり取りとして注目を集めました。エンジニアの技術的な学びや業務上の影響とは無関係ですが、日常のちょっとしたコミュニケーションのすれ違いや、世代間のユニークなやり取りを描いたおまけ記事となっています。 引用元: https://posfie.com/@kalofollow/p/DJeVZOC お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

  3. 2d ago

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

    youtube版(スライド付き) 関連リンク Introducing Claude Fable 5.2 and Claude Mythos 5.2 Anthropic社は、複雑な技術的課題を解決するために設計された最新のAIモデル「Claude Fable 5.2」および「Claude Mythos 5.2」を発表しました。両モデルはコーディング、推論、視覚認識の性能が大幅に向上しており、前モデル（5.1）と比較して出力を最大30%高速化しつつ、コストを削減しています。また、トークン生成速度を最大2.5倍にするオプションの「ファストモード」も提供されます。基本モデルは共通ですが、Fableには一般利用向けの強固なサイバーセキュリティおよび生物学的セーフガードが組み込まれており、Mythosは「ライフサイエンス」および「サイバー検証プログラム」を通過した組織にアクセスが制限されています。 コーディング性能の面では、エージェント型コーディングのベンチマーク等で非常に高いスコアを記録し、Anthropic社内での実証実験では、従来のPython製サービスをRustへ移行するタスクや、1,000名を超えるサブエージェントを統括してラップトップ上で起動する試作オペレーティングシステムを構築するなどの成果を上げています。さらに、理論物理学におけるブラックホールに関する未解決問題の解決、アデノ随伴ウイルスのカプシド構造予測、フェルマーの最終定理の形式化をわずか30時間で完遂するなど、科学技術計算の分野でも優れた能力を発揮しています。ハードウェアおよびロボティクス分野では、1パラグラフのプロンプトからホーム音声アシスタントハブやUSBスピーカーフォンなどの動作する電子機器を設計し、製造直結の回路基板や3Dプリント筐体を構築することに成功しています。 セキュリティと安全性に関しては、サンドボックスからの脱出試行を従来モデルから大幅に抑制することに成功しており、蒸留（distillation）攻撃に対する強力な保護機能や、複数リクエストにまたがる悪用パターンを検知する「エンタープライズ・フロンティア・セーフガード」を導入しています。利用は、Amazon Web Services、Google Cloud、Microsoft Azure、およびClaude Platformなどの各種プラットフォームやClaude Code経由で即日開始可能であり、開発者はAPI等を通じてclaude-fable-5-2を呼び出すことができます。日常的な開発や一般的な知識タスクには基盤モデルであるClaude Opus 5.5やSonnet 5.5を推奨しつつ、高度でオープンエンドな技術的課題や大規模なエージェントワークフローにおいてFable 5.2やMythos 5.2をアドバイザーやオーケストレーターとして活用することが推奨されています。 引用元: https://www.anthropic.com/claude-fable-and-mythos-5-2 Introducing Our Smallest, Most Efficient Model: Muse Ember Meta社は、同社の中で最も小型かつ高効率な最新AIモデル「Muse Ember」を発表しました。本モデルは、複雑な推論の実行や、AIエージェントが日常的に繰り返すタスク（ツール呼び出し、コーディングのサブタスク、ルーティング、データ抽出、長文ドキュメントの解析など）に特化して設計されています。価格あたりのインテリジェンス性能において非常に優れており、競合モデルであるClaude Haiku 5.5やGPT-6 Lunaと比較して、同等以上のスコアをより低いコストで実現している点が特徴です。 「Muse Ember」は、Meta Model APIおよびMuse Codeにおいて「muse-ember-1.0」として提供が開始されており、価格は入力トークン100万あたり0.10ドル、キャッシュ済み入力トークン100万あたり0.004ドル、出力トークン100万あたり0.50ドルに設定されています。また、100万トークンのコンテキストウィンドウと最大512Kの出力トークンをサポートしており、Google CloudのModel GardenやOracle Cloudからも利用可能です。 性能面では、テキスト、画像、音声、動画をネイティブに理解するマルチモーダル機能を備えており、スクリーンショットやグラフ、長大な実世界ドキュメントの処理、さらにはデスクトップアプリをまたいだコンピュータ操作（OSWorld 2.1など）においても高い評価結果を記録しています。エージェントのワークフローにおける細かいステップの実行や、コードの読み込み、テスト実行、ピンポイントな修正といったコーディングのサブタスクにおいて高いパフォーマンスを発揮します。 さらに、より高度で複雑な課題に対応する上位モデル「Muse Wonder」と組み合わせることで、Wonderが全体像の計画を立て、Emberが大量の反復タスクを処理するといった役割分担が可能になります。リリース前の安全性評価においては、Metaのスーパーインテリジェンス・スケーリング・フレームワークに基づき、化学・生物学的リスク、サイバーセキュリティリスク、制御喪失リスクなどの厳しい評価が実施され、高リスクの閾値を下回る安全性が確認されています。 引用元: https://research.meta.ai/blog/muse-ember Control Room: A central system to track and stop model workloads across our research infrastructure この記事では、OpenAIが研究インフラ全体でモデルワークロードを集中管理し、安全性やセキュリティ上の懸念が生じた際に迅速に停止させるために開発した中央システム「Control Room」について解説しています。AIモデルの高度化に伴い、潜在的な問題の早期検知と迅速な停止の重要性が高まっていることが背景にあります。 Control Roomは、エージェント型サンプリング、データ処理、モデルのトレーニングや評価など、すべての研究用推論ワークロードを接続し追跡します。システムは主に「ワークロード」「推論エンジン」「Control Roomサービス」の3つの要素で構成されています。ワークロードとは強化学習実験や評価などの実行ジョブであり、エージェント型推論を行う場合は承認されたセーフティケースとの紐付けが必須です。推論エンジンはGPU上で直接モデルを実行し、Control Roomサービスはジョブの追跡と継続可否の制御を行います。 具体的な仕組みとして、新しいジョブの開始時にワークロードコードがControl Roomからjob_idを取得します。ワークロードがモデルからトークンをサンプリングする際、推論エンジンに対してjob_idを添えてリクエストを送り、エンジン側がControl Roomに許可を問い合わせます。Control Room側でジョブが終了済みと判定された場合はリクエストが拒否され、エンジンはワークロードに対して拒否応答を返すことでモデルの出力を停止させます。 安全性と信頼性の面では、監視システム（モニタ）との統合により、問題が検知された場合にモニタからControl Roomへ停止メッセージが送られ、次の推論リクエスト時に自動で処理が拒否されます。停止命令から出力が不可能になるまでの最大遅延時間は35秒で、これはトラフィック処理を支えるキャッシュ層に起因しますが、将来的なゼロ秒化を目指して開発が進められています。また、頻繁に変更される分散的なワークロードコードではなく、一元化された推論レイヤーに停止機構を実装することで、確実な認可チェックを実現しています。さらに、Control Roomサービス自体が停止した場合や不正な改変を受けた場合には、すべての推論リクエストを拒否する「フェイルクローズ」設計を採用し、安全性と信頼性を担保しています。新人エンジニアの視点では、大規模なAI研究・運用インフラにおける安全性担保のアーキテクチャや、障害発生時に安全側に倒すフェイルクローズの設計思想を学ぶ上で非常に有益な内容となっています。 引用元: https://openai.com/index/control-room ロピアがAIのキモ飯ポスターに実物を寄せてきてて草「これ作ってからAIにしたのか、AIに弁当寄せたのかどっちか気になる」「この発想はなかった」 スーパーマーケット「ロピア」の売り場で掲示されているAI生成特有の質感を持つ料理ポスターに対し、販売されている実物の商品がそのAIイラストの見た目に合わせて忠実に寄せられていることがX（旧Twitter）上で話題となっている。「実物がAIの誇張側に寄せてきている」「逆の発想が面白い」「これを作ってからAI画像化したのか、AI画像に弁当を合わせたのか気になる」といった驚きやユニークな視点の感想が多数寄せられ、生成AIカルチャーならではのユーモラスな現象として盛り上がりを見せている。 引用元: https://togetter.com/li/2768126 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

  4. 3d ago

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

    youtube版(スライド付き) 関連リンク Claude Codeの「今後確認しない」が秘密情報をGitHubに漏らす — 1,122件の公開ファイルに1,379件の秘密情報 この記事では、Anthropicが提供するAIコーディングツール「Claude Code」の自動承認機能に起因する、重大なセキュリティリスクと情報漏洩の実態について解説しています。新人エンジニアが日々の開発でAIツールを使用する際に見落としがちな脆弱性であるため、その仕組みと対策を正確に理解しておく必要があります。 問題の根幹は、Claude Codeでシェルコマンドを実行する際に「Yes, and don’t ask again（今後確認しない）」を選択したときの挙動にあります。この操作を行うと、承認したコマンドがプロジェクト内の.claude/settings.local.jsonという設定ファイルにそのまま保存され、次回以降は確認なしで実行されるようになります。この際、コマンドにデータベースのパスワード、APIキー、SSHの秘密鍵などが含まれていると、それらが平文のままファイルに記録されてしまいます。 セキュリティ企業のApiiroが公表した調査によると、公開されているGitHubリポジトリの該当ファイル104,185件のうち、1,122件のファイルから合計1,379件の秘密情報が見つかりました。さらに、古いバージョン、フォークされたリポジトリ、共有設定ファイル、エージェントのチャットログなどを合わせると、2,539件もの秘密情報が確認されています。中にはデータベースの管理者用クラウドキーや医療記録データベースのオーナーパスワードなども含まれており、その半数以上が217日以上放置されていたことが分かっています。 Claude Code側にも対策としての仕組みは存在し、初めてファイルを書き込む際にユーザーのグローバルなGit除外設定へ同ファイルを追加する挙動があります。しかし、この保護は個人のPC内におけるグローバル設定に依存しており、プロジェクト自体の.gitignoreに自動追加されるわけではありません。そのため、保護設定がプロジェクトと一緒に移動せず、共同著者としてコミットされたClaude自身の操作によってファイルがGit管理下に置かれ、パブリックリポジトリへ流出するケースが多数発生しました。また、一般的な秘密情報スキャナーであるgitleaksやTruffleHogでも、コマンド内に埋め込まれた非定型のパスワードや平文の文字列は見逃されやすいという課題があります。 このようなセキュリティ事故を防ぐため、エンジニアは直ちに行動を起こす必要があります。まず、組織のGitHubリポジトリで.claude/settings.local.jsonや.claude/settings.jsonの存在およびGit履歴を確認し、流出した可能性のあるパスワードやトークンは片付けよりも先に速やかにローテーション（再発行・変更）しなければなりません。また、プロジェクトごとの対策として、git rm --cached .claude/settings.local.jsonを実行してGitの追跡から外し、プロジェクトの.gitignoreに確実に追跡除外を追加します。開発時の注意点として、コマンド内に直接機密情報を記載せず、環境変数やシークレットマネージャーを経由させること、そして承認は具体的な1回限りのコマンドではなくBash(npm run:*)のようなパターンベースで行うことが重要です。組織としても、エージェント用フォルダを .env と同等に扱い、CIやpre-commitでの秘密情報スキャンを徹底する仕組み作りが求められます。 引用元: https://dev.ponkotsu.dev/entry/claude-code-settings-local-secrets MCPはなぜ復権したのか：CLIが支持された理由と、流れを変えた仕様変更 Hiraoku.dev AIエージェントと外部サービスを接続する共通規格であるMCP（Model Context Protocol）が再評価されている背景と、CLIとの比較、そして近年の技術的変遷について解説します。 初期のMCP利用では、大量のツール定義や検索結果を一括してAIモデルへ渡すことでコンテキストが圧迫され、初期化やセッションの状態管理にかかる負担が課題となっていました。そのため、必要なときにヘルプを読み、出力を加工できる既存のCLIをエージェントに利用させるアプローチが支持を集めました。CLIは、必要な説明だけをその場で確認でき、jqなどのプログラムで結果を絞り込んでからモデルへ渡すことが可能であるため実用的でした。 こうした不満に対し、MCP側も改良が進みました。AIアプリ側での工夫として、必要なツール定義だけを遅延読み込みする仕組みや、コード実行環境を用いた中間データの加工処理を取り入れることで、コンテキスト圧迫という課題に対処できるようになりました。 さらに、通信規約の面では、2026年7月28日版の仕様変更により大きな改善がなされました。従来の仕様にあった初期化のやり取りやプロトコル上のセッションが撤去され、各要求にバージョンや対応機能などの通信条件をメタデータとして含めるステートレスな構成に変更されました。これにより、リモートのMCPサーバーを分散して運用しやすくなり、サーバー側の負荷や通信管理の複雑さが軽減されました。また、追加入力を扱うMRTR（Multi Round-Trip Requests）や、キャッシュ機構の共通ルール、認可時の発行元確認などの機能も整備されました。 実際のエンジニアリングにおいては、すべての操作をMCPに置き換える必要はありません。手元のビルドやファイル加工などのローカルな作業には既存のCLIを活かしつつ、複数のAIアプリやクラウドエージェントからSaaSや社内システムへ接続・連携させる場合には、リモートMCPによる共通化と集中管理を活用するという使い分けが有効です。CLIが支持された理由への対応と通信設計の刷新により、MCPは実用的な選択肢として再び価値を高めています。 引用元: https://hiraoku.dev/blog/mcp-cli-cloud/ Google Antigravity 2.29 が公開。クラウドで動くリモートエージェントと音声モードを追加 GoogleはAI開発プラットフォーム「Antigravity」のバージョン2.29を公開し、開発者向けの強力な新機能やインターフェースの改善を行いました。新人エンジニアが知っておくべき主要な変更点として、クラウド上でエージェントを動かす「リモートエージェント」機能と、Gemini Liveを利用した「音声モード」の追加が挙げられます。 リモートエージェント機能は、ローカルPCではなくGoogleが管理する隔離されたクラウド上のリモート環境でエージェントのセッションとツールを実行する仕組みです。これにより、ブラウザを閉じたりPCをスリープ状態にしたり、デスクトップとモバイル間を切り替えたりしても、長時間の開発タスクを継続して実行できるようになります。リモートプロジェクトの作成は、アプリの左サイドバーにある「Projects」の横にある「+」ボタンから「New Remote Project」を選ぶか、メッセージ入力欄のプロジェクト選択で「[Remote] > [GitHub Repositories]」を選択して行います。GitHubリポジトリはOAuth認証によって複数接続でき、会話の中で自動的にクローンされてリモートワークスペースにマウントされます。また、Googleドライブからドキュメントやスプレッドシート、PDF、フォルダなどを追加して、エージェントに必要に応じて読み込ませることも可能です。なお、このリモートエージェントを利用するには、個人のGoogleアカウントでGoogle AI ProまたはGoogle AI Ultraの有料プランに加入している必要があります。 音声モードは、メッセージ入力欄が空のときに表示されるボタンからGemini Liveを利用してAntigravityに話しかけ、音声で指示を出すことができる機能です。これにより、テキスト入力の手間を省いた直感的な操作が可能になります（※段階的な提供となっています）。 機能面だけでなく、UIや開発環境の使い勝手も大幅に刷新されました。新しい会話ページでは、上部に挨拶が表示され、メッセージ入力欄が画面下部に固定されるレイアウトに変更されています。単一リポジトリのプロジェクトでは、ブランチやGitワークツリーの選択メニューが1つにまとめられ、モデル選択メニューの位置も変更されました。また、自動化タスクを管理するAutomationsページは、「Scheduled」「Always on」「Paused」の一覧に分かれて次回の実行時刻などが確認しやすくなり、作成フォームも全画面表示に対応しました。 さらに、内蔵ブラウザやファイル管理機能もアップデートされています。ファイルのダウンロード時は確認なしでダウンロードフォルダに保存され、進行状況がツールバー

  5. 6d ago

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

    youtube版(スライド付き) 関連リンク GPT‑6 Cyber: Advancing the frontier of aligned cybersecurity agents OpenAIが発表した「GPT-6 Cyber」は、セキュリティ研究およびサイバーセキュリティ特化型AIエージェントの最先端を進む最新モデルです。前モデルであるGPT-5.6 Cyberと比較して、脆弱性の発見や修正能力が大幅に向上しており、主要なサイバーセキュリティベンチマークである「ExploitGym」において51%の相対的な向上を達成しています。具体的な性能として、ExploitGymでのスコアは48.5%に上昇し、権限昇格に関するLinuxカーネルの脆弱性検証や、Mozilla Firefoxにおける多数の未知の高深刻度脆弱性の特定などにすでに貢献しています。 新人エンジニアが押さえておくべき重要なポイントは、このモデルが単に攻撃的な脆弱性を突くだけでなく、「アライメント（安全性・境界線の遵守）」の面で極めて高い信頼性を備えている点です。タスクの境界線を守る能力が強化されており、許可されたスコープ内に留まり、不正なサービスへのアクセスを回避する精度が大幅に向上しています。これにより、セキュリティエンジニアは実際のソフトウェアやシステムコードベースのコードレビュー、脆弱性のトリアージ、パッチ開発の効率化を安全に進めることができます。 また、本モデルの機能はAPIおよびCodexを通じて、Daybreak Redを利用する承認済み顧客に順次提供されます。さらに、重要インフラ（電力や水処理施設など）を守るための「Daybreak Red for Critical Infrastructure」の導入や、悪用を防ぐためのプライベート・セーフティ・プロセス（PSP）、IPアドレスの許可リスト化、サンドボックス化といった強力な安全対策も同時に実装されています。AIを活用した脆弱性探索やセキュリティ対策のトレンドを理解する上で、非常に重要なマイルストーンとなるアップデートです。 引用元: https://openai.com/index/introducing-gpt-6-cyber Introducing Images 2.6 OpenAIが発表した新しい画像およびアニメーションGIF生成モデル「Images 2.6」の機能やAPI提供に関する記事です。ChatGPT、Codex、およびAPIを通じて利用可能になり、世界中で週に40億枚以上の画像が生成されている中で、さらなる高速化と高度な編集機能が追加されました。新人エンジニア向けに、開発やAPI利用における重要なポイントを解説します。 まず、Images 2.6は従来と比較して生成速度が50%向上しています。API向けには「GPT-Image-2.6 Flare」と「GPT-Image-2.6 Sunburst」という2つのモデルが提供されます。Flareは、品質を低に設定することで最短6秒で画像を生成でき、ポスターや製品画像のレイアウト品質向上に適しています。一方、Sunburstは、品質を中または高に設定することで、より詳細で精度の高い画像生成や、編集時の高いキャラクター・製品の一貫性を維持することができます。 次に、最大の新機能としてアニメーションGIFの生成機能が追加されました。マークアップや簡単な手書きのスケッチをベースにして、キャラクターを動かしたり、製品ショットをループアニメーションに変換したりすることが可能です。プロンプトを活用してスプライトシート形式でのシームレスなループGIFを作成することもでき、ゲーム開発やWebサイト、SNS向けの素材として活用できます。 さらに、API利用者向け機能が拡張されています。ChatGPTですでに利用できた画像マークアップ機能がAPIにも導入され、変更したい箇所を正確に指定して編集できるようになりました。また、SVG形式でのエクスポートに対応したほか、新しく追加された「complexity（複雑度）」パラメータにより、モデルがリクエストに対してどれだけ計画や処理を行うかを調整できるようになりました。これにより、迅速な編集を行いたい場合は低複雑度に設定するなど、用途に応じた最適化が可能です。 Images 2.6は本日からChatGPTおよびCodexの全サブスクリプション層でグローバルに利用可能であり、APIではFlareおよびSunburstモデルが提供されています。AIを活用したアプリケーション開発や画像生成機能を組み込むエンジニアにとって、速度と制御性が向上した注目のアップデートとなっています。 引用元: https://openai.com/index/introducing-images-2-6 PFN、世界最高水準のAI翻訳がエッジで可能な大規模言語モデル PLaMo 3 Translate をオープンウェイトで公開 株式会社Preferred Networks（PFN）は、自社のAI翻訳サービスで利用している翻訳特化型の大規模言語モデル「PLaMo 3 Translate」を、Hugging Faceにてオープンウェイトモデルとして公開しました。本モデルは国立研究開発法人情報通信研究機構（NICT）との共同研究による事前学習モデルを基盤として開発されており、日本語や英語を含む53言語に対応しています。直近事業年度の収入または売上が10億円以下の企業および個人であれば、「PLaMoコミュニティライセンス」のもとでダウンロードし、商用・非商用を問わず無償で利用可能です。 新人エンジニアが押さえておくべきポイントとして、本モデルの最大の特徴は「エッジデバイスでの実行」と「高いカスタマイズ性」にあります。モデルのサイズは、用途や利用する機器に合わせて0.8B（8億）、2B、8B、31Bの4種類から選択可能です。最小サイズの0.8Bモデルを用いれば、インターネット接続がない環境（機内モードのスマートフォンなど）であっても、クラウドを介さずに高速で高品質な翻訳を実行できます。 これにより、外部のクラウドサーバーにデータを送信できない機密性の高い契約書、研究開発資料、顧客対応文書なども、社内サーバーや手元の端末内で安全に翻訳処理を完結させることが可能です。また、機能面では、文脈を踏まえた参考情報の提示や、用語集による固有名詞・専門用語・製品名の対訳指定に対応しており、日本語への翻訳時には「です・ます調（敬体）」と「だ・である調（常体）」の文末表現を指定して出力をコントロールできる実用的な特徴を備えています。 性能面においても、PFNの評価では最小モデルが既存のGoogleのTranslateGemmaやTencentのHy-MT2を上回るスコアを記録するなど、小型でありながら世界最高水準の翻訳品質を実現しています。入手先としてはHugging Faceの「pfnet」ページで各サイズ（0.8B、2B、8B、31B）のモデルが公開されており、手元の環境で実際に動作や翻訳品質を検証した上で、アプリケーションへの組み込みや社内システムへの導入を検討することができます。なお、売上制限を超える企業による商用利用にはPFNとの別途商用ライセンス契約が必要となります。 引用元: https://www.preferred.jp/ja/news/pr20261105 コンビニ店員が客に気を遣わせないために小さな気遣いをして「わかる、俺もそう」と心の中で頷くだけのマンガがあったかい 本記事は、コンビニでの日常のワンシーンを描いた心温まる創作漫画についてまとめたものです。コンビニで商品棚の品出しをしている時や、ホットスナックを選ぶ際に、客と店員が互いに気を遣い合ってしまう「あるある」なシチュエーションが描かれています。店員が客に「欲しいの取れた？」とさりげなく声をかけたり、客側に立って「わかる、俺もそう」と心の中で共感したりする優しいやり取りが、多くの読者から共感と称賛を集めています。過度なサービスを求めず、些細な日常の気遣いを描いた理想的な世界観としてSNS上で話題になりました。 引用元: https://togetter.com/li/2766893 お便り投稿フォーム VOICEVOX:ずんだもん

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

  6. Nov 4

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

    youtube版(スライド付き) 関連リンク Siri AI is now open to all developers - Latest News - Apple Developer Appleは、iOS 27.3、iPadOS 27.3、macOS 27.3、visionOS 27.3などのベータ版において、すべてのデベロッパーに向けて「Siri AI」を統合できる新しいDeveloper Previewの提供を開始しました。これにより、アプリのコンテンツやカスタムアクションをSiri AIへ直接組み込み、ユーザーが自然言語で話しかけるだけで様々な処理を実行できるようになります。 今回のプレビューでは、App Intentsを活用することで、パーソナルコンテキストの理解、画面上の要素の認識、高度な自然言語処理といったSiri AIの最新機能をアプリから利用できるようになります。例えば、荷物の配送状況の確認、レストランの予約、注文の完了など、ユーザーが自分の言葉で依頼したカスタムアクションをSiri AIがシームレスに実行します。さらに、複雑なリクエストに対して複数のアクションを一つの体験として統合できる「skills」も新たに導入され、Spotlightのセマンティックインデックスにあるあらゆるエンティティを表面化させることが可能になりました。 Appleは、カレンダー、ファイル、メール、マップ、メッセージ、メモ、写真、リマインダー、Safari、天気などの自社製アプリにもこれらの機能を順次導入しており、デベロッパー向けのリファレンスとして活用できます。今後のスケジュールとしては、数ヶ月後に一般顧客向けへの正式な提供が開始され、春にはApp Storeへのアプリ提出が解禁される予定となっています。これにより、デベロッパーは正式リリースに向けて新しい体験の探索や開発、フィードバックの共有を行う十分な時間を確保できます。 新人エンジニアが開発を進める上での重要なポイントとして、新しいAPIの詳細や、Siri AIを活用したアプリ体験の評価方法については公式ドキュメント（Siri AI Developer Preview）が公開されています。また、利用にあたってはいくつかの注意点があり、対応するApple Intelligence搭載デバイスおよびサポート言語（日本語を含む）が必要となります。現時点ではEU圏内でのiOS、iPadOS、watchOS向けSiri AIは利用不可となっており、13歳未満のユーザーも対象外です。さらに、サーバーサイドモデルに依存する一部のApple Intelligence機能には1日の利用制限が設けられており、将来的に有料での拡張アクセスが提供される予定であるため、今後の利用規約やポリシーの変更にも注意を払う必要があります。 引用元: https://developer.apple.com/news/?id=gdk2umrf NVIDIA CUDA 13.5 Brings NVIDIA Vera Rubin GA Support NVIDIAは、次世代フラグシップアーキテクチャ「Vera Rubin」の正式サポート（GA）を含む「NVIDIA CUDA 13.5」を発表しました。本リリースでは、AIおよびアクセラレーテッド・コンピューティングのパフォーマンスとスケーラビリティを最大化するための多くの新機能や改良が提供されています。新人エンジニアがCUDA開発やGPU最適化を進める上で押さえておくべき主要なポイントを以下に解説します。 まず、GPUリソース管理の柔軟性が大きく向上しました。ローカリティドメイン（Locality Domain）の拡張により、ストリーミング・マルチプロセッサ（SM）のパーティション設定をカスタマイズできるようになり、ハードウェアの性能を余すところなく活用可能です。また、NVIDIA Multi-Process Service（MPS）v3では、ウェイト付きタイムスライシングやSMパーティションのロードバランシング、cgroupベースのルーティングなどが導入され、マルチテナント環境でのワークロード共有管理が強化されています。さらに、Windows on ArmサポートがNVIDIA DGX Station for Windowsにも拡張されました。 開発言語やライブラリの面でも強力なアップデートが行われています。CUDA Pythonのコアライブラリ（cuda.core 1.2）では、バッファの一括コピーを行う copy_batch() やPythonからのProgrammatic Dependent Launch（PDL）の利用が可能になり、効率的なストリーム制御が行えるようになりました。また、CCCL（CUDA C++ Core Libraries）3.5では、CUBデバイスワイドアルゴリズム用の公開チューニングAPIが導入され、ブロックあたりのスレッド数などをコードからカスタマイズ可能です。さらに、バッチ処理によるTop-K選択や、浮動小数点スキャンの実行結果の再現性を保証する機能が追加され、LLM推論などのAIワークロードにおける開発が容易になりました。 数学ライブラリや開発者ツールも強化されています。cuBLASでは、Vera Rubin向けにNVFP4やMXFP8の行列積（matmul）のパフォーマンスが向上したほか、倍精度浮動小数点（FP64）の対称rank-k更新におけるOzaki-IIスキームの拡張などが行われました。開発者向けには、長期にわたるトレーニングや推論のプロファイリングを常時行うための「NVIDIA Nsight Perf SDK for AI」のパブリックプレビューが提供され、Nsight Computeにはタイムライン専用ページが追加されるなど、ボトルネックの調査やデバッグ作業が効率化されています。コンパイラ関連では、nvprune によるデバイスコードの事前コンパイル機能や、PTXおよびデバイス組み込み関数の拡張により、実行時のオーバヘッド削減と最適化が進められています。 引用元: https://developer.nvidia.com/blog/nvidia-cuda-13-5-brings-nvidia-vera-rubin-ga-support/ OpenAI to acquire Pierre Computer Company, Inc. OpenAI社は、開発者向けツールやソースコード管理関連のライブラリを手がけるPierre Computer Company, Inc.の買収を発表しました。Pierre社は、コードストレージサービスである「Code Storage」や、ファイル構造の迅速なナビゲーションを可能にする「Trees」、コード変更差分を見やすくする「Diffs」などの優れたオープンソース開発ツールやライブラリを開発してきた企業です。 今回の買収の背景には、AIによるコーディングエージェントや複数の開発作業が並行して行われる現代のソフトウェア開発において、Gitを中心とした周辺システムを進化させるという狙いがあります。OpenAI社ではすでに、社内のエンジニアやエージェント向けにソースコントロールバックエンドである「Pando」を活用してGitのスケーリングを行っていますが、Pierre社のチームが持つ優れた開発者ツールや知見を組み合わせることで、エージェントが作成する最初のブランチからコードがデプロイされる瞬間までの一連のワークフローを刷新したい考えです。 具体的には、Pierre社が開発した、ファイルの素早い確認やコードレビューを効率化する「Trees」や「Diffs」のライブラリ、コードの即座の修正を可能にするDiffsの「Edit」モード、リアルタイムで高速に動作するシンタックスハイライター「Highlights」、Gitベースでコードの履歴を追跡・保存できる「Code Storage」などの技術や機能が、今後の「Codex」アプリやプラットフォームに統合されていく予定です。 なお、買収完了後もPierre社のオープンソースプロジェクトは引き続きオープンソースとして維持され、OpenAI社もその開発に貢献していく方針です。また、Code Storageの既存顧客についても、買収手続きの完了後、その機能がCodexに統合されていくまでの間は引き続きサービスを利用することができます。本買収の完了には、規制当局の承認を含む慣習的な完了条件が適用されます。新人エンジニアの視点としても、AIコーディングエージェントの普及に伴い、ソースコード管理やコードレビューのあり方がどのように進化していくのか、今後の開発環境のトレンドを把握する上で注目すべきニュースとなります。 引用元: https://openai.com/index/openai-to-acquire-pierre 三日坊主を卒業。専属トレーナーの Gemini と始める無理のない運動習慣 本記事では、Googleの生成AI「Gemini」を活用して無理なく運動習慣を作る方法が紹介されています。Googleカレンダーやヘルスケアアプリのデータ連携により、個人のスケジュールや運動レベルに合わせた最適なトレーニング計画の自動作成が可能です。また、YouTube連携による条件に合う動画の検索や事前の要約、写真によるフォームの確認機能、さらに「Gemini タスク」を用いた天気や予定に応じた自律的なスケジュール調整など、AIを専属トレーナーに見立てて継続をサポートする具体的な活用法が解説されています。 引用元: https://note.com/google_gemini/n/nef56e564a8f2 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

  7. Nov 3

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

    youtube版(スライド付き) 関連リンク Scaling Git at OpenAI OpenAI社内におけるAIによる開発の高速化と並列作業の激増に伴い、既存のソース管理システムが限界を迎えたことから、Git互換の新しいバックエンドシステム「Pando」を自社で開発・導入した事例について解説しています。従来のGitサーバーは、リポジトリ全体の一貫性維持やクライアントごとの個別パックファイル生成に起因して、書き込みの競合やCPU・ディスクI/Oの負荷増大というスケーリングの課題を抱えていました。これに対してPandoでは、水平スケーリングが可能なメタデータストアとオブジェクトストレージを基盤とし、リポジトリ全体の一貫性を緩やかにする代わりに個別のブランチ更新で直列化を保つ「因果一貫性（Causal Consistency）」を採用しました。さらに、クライアントのブランチ更新時に生成される不変のパックファイルをキャッシュし、他のクライアントからのフェッチ時に再利用する仕組みを導入することで、サーバー側の重いアンパック・リパック処理を排除しています。これにより、無数のブランチに対する書き込みと多くのリーダーからの読み込みを完全に並列化し、リクエスト処理性能を劇的に向上させました。また、L0からL4に至る多段階のコンパクション（統合処理）をバックグラウンドで実行することで、大量のパックファイルを効率的に整理し、対数時間でのフェッチ計画立案と高速な読み込みを実現しています。新人エンジニアにとっても、分散システムの設計における一貫性と可用性のトレードオフや、既存プロトコル（Git）の互換性を保ったまま大規模なスケーラビリティを達成するアーキテクチャの具体例として、非常に深い学びが得られる内容となっています。 引用元: https://openai.com/index/scaling-git-at-openai Making Kubernetes AI-Ready for NVIDIA Vera Rubin on Day One この記事は、NVIDIAの次世代GPUアーキテクチャ「Vera Rubin」をKubernetes環境で運用できるようにするための最新の技術情報について解説しています。新人エンジニアがAIインフラの基盤構築や設定管理を学ぶ上で非常に参考になる内容となっています。 Vera Rubinは従来のGB200 NVL72などのアーキテクチャから進化していますが、実際に運用する際にはGPUドライバーの新しいブランチやDOCA/NICドライバー、デバイスのトポロジーなどの変更点に対応する必要があります。例えば、Vera Rubin NVL72では従来のConnectX-7からConnectX-9 SuperNICやBlueField-4 DPUに置き換わっており、GPUとNICの接続やNUMA配置などの設計を慎重に行う必要があります。 このような複雑なハードウェアとソフトウェアの組み合わせをシンプルにし、再現性のある構成で管理するために、「NVIDIA AI Cluster Runtime (AICR)」というツールが活用されます。AICRを使用することで、検証済みの設定を「レシピ」として定義し、デプロイや検証を自動化することができます。 具体的なワークフローとしては、以下のステップでKubernetes環境の構築と検証を行います。 レシピの生成: aicr recipeコマンドを使用し、サービス（rke2）、アクセラレータ（vr200）、OS（ubuntu）、目的（trainingやinference）を指定して構成ファイルを生成します。これにはGPU OperatorやDRA（Dynamic Resource Allocation）ドライバー、監視ツールなどが含まれます。 デプロイバンドルのレンダリング: 生成したレシピをもとにHelmチャートなどのデプロイ用スクリプトを出力します。 スナップショットと検証: aicr validateコマンドを使用して、OSのバージョンやカーネル、GPUドライバー（nvidia-smi）の健全性、コンフォーマンス（適合性）、さらにマルチノード環境でのNCCLを使ったパフォーマンス検証（All-Reduceテストなど）を段階的に実行します。 また、Vera Rubin向けの検証プロセスを通じて、go-nvlibのアーキテクチャ判定の修正や、ホスト管理型IMEXとDRA管理型ComputeDomainの競合回避といったフィードバックがアップストリームに還元され、エコシステム全体が改善されていることも紹介されています。 このように、最先端のAIハードウェアをKubernetes上で素早く、確実に見通し良く立ち上げるための実践的なアプローチがまとまっており、プラットフォームエンジニアやAIインフラに携わるエンジニアにとって重要な知見が詰まっています。 引用元: https://developer.nvidia.com/blog/making-kubernetes-ai-ready-for-nvidia-vera-rubin-on-day-one/ How we’re training a Figma-fluent editing model 本記事では、デザインツール大手のFigmaが、キャンバス上の既存のデザイン要素に対して直接編集や反復作業を行う独自のエージェントモデルをどのように訓練したか、その具体的なアプローチと知見について解説しています。 Figmaの開発チームは、日常的な細かいデザイン修正（スペースの調整、色の変更、レイアウトの改修など）を迅速かつ正確に行うため、フロンティアモデルそのままではなく、特化したモデルの構築を目指しました。初期の汎用的なフロンティアモデルではFigmaの構文を深く理解させることが難しく、過度にトークンを消費するシステムプロンプトが必要になるという課題がありました。 そのため同社は、教師あり微調整（Supervised Fine-Tuning: SFT）に投資しました。具体的には、開始時のデザイン、生成された合成編集リクエスト、そして成功した変更例をペアにした訓練データを大量に作成しました。デザインはFigmaのネイティブファイル形式で表現され、デザインシステムアセット（テーマやコンポーネントの変更）を含む合成プロンプトも活用されました。データ生成プロセスにおいては、より大型の教師モデルが編集を試行し、決定論的なバリデーターやビジュアルモデルの評価器（LLMジャッジ）を用いて候補をチェックし、自己修復（セルフヒール）を行うパイプラインが構築されました。この初期のSFTアプローチにより、例えば25万件以上の例で訓練されたLlama 3.3 70Bモデルが、当時のトップモデルと競合できるレベルに達しました。 しかし、SFT単体では模倣学習の限界（訓練データに酷似したデザインを生成する一方で汎化性能が低下すること、またサンプル効率が悪いこと）に直面したため、最新のレシピでは強化学習（Reinforcement Learning: RL）へも投資を広げています。デザインドメインに適したRL環境の整備、訓練例の多様性の確保、報酬モデルの形作り、専門家による評価基準の拡張などが行われています。 モデルの評価においては、「デザインの良し悪しは主観的である」という課題に対し、構造のチェックとビジュアル評価を組み合わせ、専門のデザイナーによるレビューでキャリブレーションを行う手法をとっています。これにより、テキストとアイコンの重なりや、要素のクリッピングといったAI生成デザイン特有のエラーを個別の次元で評価・改善しています。現在ではQwenモデルやMuse Spark Open、Inklingなどのベースモデルも活用され、最新の非公開モデル（Qwen 3.8 27Bベースのポストトレーニングモデルなど）は高い評価を獲得しています。 最終的に、この独自にポストトレーニングされた編集モデルは、Figmaエージェント（一般提供開始された新機能）に組み込まれました。エージェントは画像生成や新規デザイン探索には最適なサードパーティモデルを使用し、高精度な編集や反復作業にはFigma独自のモデルを使い分けています。その結果、タスク処理速度の向上、ユーザーによる「取り消し（Undo）」の減少、ユーザー評価の向上、メッセージあたりの平均コスト削減などの優れた成果を上げています。新人エンジニアにとっても、特定のドメインに特化したAIモデルのポストトレーニング、SFTからRLへの移行、合成データの活用、およびドメイン特有の評価パイプライン設計の具体例として、非常に学びの多い内容となっています。 引用元: https://www.figma.com/blog/training-a-figma-fluent-editing-model/ AI書道コンクール 「第1回 AI書道コンクール」は、様々な言語モデルが生成した筆運びデータを、専用の書道エンジン（sho.js）を用いて出力した作品を競うユニークなイベントです。コンクールでは「楷書の部」と「絵文字の部」が設けられており、「やきいも」や「シンギュラリティ」、「🐈」や「🍣」といったお題に対して、Qwen、Mistral、Claude、GPTなどの多様なモデルを活用した作品が多数展示されています。LLMのユ

  8. Nov 1

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

    youtube版(スライド付き) 関連リンク streamAppendHTML() で AI の回答を HTML のままストリーミング描画する この記事では、LLM（大規模言語模型）からの回答をチャットUI画面に少しずつストリーミング描画する際の実装課題と、それを解決する新しいWeb API streamAppendHTML() について解説しています。新人フロントエンドエンジニアが知っておくべきポイントを網羅して説明します。 従来のチャットUIにおける課題として、届いたテキスト全体をチャンクごとにパースして innerHTML や setHTML() で要素全体を丸ごと置き換える方法が挙げられます。この従来手法では、回答のテキストが長くなるにつれてパースするデータ量が増加し処理が重くなるだけでなく、テキストの選択状態が解除されてしまったり、開いていた 要素が閉じられてしまったり、CSSアニメーションが毎回最初から再生されてしまうという問題が発生していました。 新しく登場した streamAppendHTML() は、HTML文字列の断片（チャンク）を要素の末尾へ逐次的にストリーミング追加できるブラウザのネイティブ機能です。WritableStream を返し、response.textStream().pipeTo(element.streamAppendHTML()) のように接続することで利用できます。ブラウザのHTMLパーサーが内部でタグの途中で切れたチャンクを保持・管理してくれるため、未完成のタグが画面にそのまま表示されることはなく、すでに描画された既存の要素や状態を壊さずに効率的な逐次描画が可能になります。また、生成を途中で停止したい場合には AbortController の signal を pipeTo() に渡すことで安全に中断でき、それまでに描画された内容をそのまま維持できます。 もう一つの重要なポイントとして、LLMの出力にはプロンプトインジェクションによる悪意あるHTMLやスクリプトが含まれるリスクがあるため、信頼できない入力として扱う必要があります。streamAppendHTML() にはサニタイズを行う Safe 版と、行わない Unsafe 版（streamAppendHTMLUnsafe()）が存在します。Safe 版ではデフォルトのサニタイザによりXSSにつながる要素や属性が自動的に除去されます。ただし、デフォルト設定では や 、CSSの class 属性なども安全のために除去されてしまうため、チャットUIで利用する際は Sanitizer APIを用いて必要な要素や属性を明示的に許可リストに指定する実装を行う必要があります。 引用元: https://azukiazusa.dev/blog/stream-append-html/ third-intelligence/Haas-ja-v1.0 · Hugging Face 「Haas-ja-v1.0」は、高速性と高精度を両立させた日本語音声認識（ASR）モデルであり、Hugging Face上で公開されました。NVIDIAのParakeet-TDTアーキテクチャをベースにしており、FastConformerエンコーダと、トークンごとに出現長さを予測するToken-and-Duration Transducer（TDT）デコーダを採用しています。さらに、予測ネットワークのLSTMをKimi Delta Attention（KDA）に置き換えることで、推論速度をほとんど落とすことなく認識精度を向上させている点が大きな特徴です。モデルのパラメータ数は約6.16億で、入力には16 kHzのモノラル音声を使用します。 学習データには、ReazonSpeechやCommon Voice、YODASなどの公開コーパスおよび社内データを合わせた約46,000時間が使用され、高品質なフィルタリング処理が施されています。性能評価には、発話スタイルやドメインの異なる5つの公開データセットを組み合わせたベンチマーク「asr-ja-bench v1.1」が用いられました。文字誤り率（CER strict）の評価では6.12%を記録し、オープンな日本語音声認識モデルの中ではトップクラスの精度を達成しています。商用APIと比較しても同等レベルの高精度を誇りながら、H200 GPU環境を用いた場合の処理速度（RTFx）は非常に高速で、主要なオープンモデルと比較して圧倒的なスピードとコストパフォーマンスを実現しています。1時間あたりの推論コストは0.003〜0.004ドル程度と推定されており、商用APIの数分の一から百分の一程度のコストで利用可能です。 新人エンジニアが実際に利用する際の手順として、Linux環境およびNVIDIA GPU、Python 3.11以降、NeMo 2.7を前提条件としています。リポジトリをクローンしてuvを使ってセットアップするか、pipを通じて推論パッケージをインストールすることで簡単に導入できます。基本的な使い方は、haas_asr.load_modelでモデルを読み込み、haas_asr.load_audioで音声ファイルを読み込んでtranscribeメソッドを実行するだけです。30秒以上の長尺音声に対しては、無音部分で分割してバッチ処理を行うtranscribe_longform関数が用意されています。また、特定の専門用語や人名を正しく認識させるためのカスタム語彙機能（Vocabulary）や、NVIDIAの「Nemotron-3-Diarization」モデルと組み合わせることで話者分離ラベルを付与する機能などもサポートされており、実践的な音声認識アプリケーション開発に役立つ構成となっています。 引用元: https://huggingface.co/third-intelligence/Haas-ja-v1.0 3 人それぞれの Claude Code を Slack でつないで ISUCON2026 に参加した（207,039 点） 本書は、3人組のチーム「いくぜカウシェ」が技術コンテスト「ISUCON2026」に挑み、最終スコア207,039点を獲得した事例を紹介する記事です。各メンバーが自分のPC上でAIコーディングアシスタント「Claude Code」を稼働させ、調査やデプロイ、ベンチマーク実行などのタスクを分担させました。エージェント間では会話履歴が共有されないため、Slackチャンネルを主たる連絡手段として利用し、サーバーへのデプロイやベンチマークの衝突を防ぐための運用上の工夫が行われました。 運用面における具体的なアプローチとして、タスクや進捗管理にはGit管理された「GOAL.md」を活用しました。初期段階では細かな手順を指示していましたが、途中からは高めのゴール設定と制約事項だけを記載したファイルを用いてエージェント自律的に動かす手法に切り替えました。また、Slack上でのメッセージ量が増大してエージェントの読み込みに支障が出たため、機械的かつ短い書式（例：CLAIMやDEPLOY_REQなどの1行フォーマット）をエージェント自身に定義させ、人間が確認すべき内容だけを日本語の「TO_HUMAN」として区別する仕組みを取り入れました。 ベンチマークの競合制御に関しては、時間帯ごとに運用を改善しています。初期は手動や個別判断による競合でスコアが失われる失敗（FAIL）が発生しましたが、16時以降はデプロイとベンチマークの担当を1つのエージェントに集約し、スクリプトによる自動化を行うことで衝突を防ぎました。一方で、実行担当が手一杯になり他のメンバーからの修正を取り込み忘れる課題も浮き彫りになり、役割分担の重要性が示唆されています。 人間の役割については、目の前の細かな改善に終始しがちなエージェントに対し、大局的な目標や逆算した方針（「100万点に届かせるには何が足りないか」など）を随時指示・修正することにありました。最終的な振り返りでは、AIをそのまま利用するだけでなく、チーム間やエージェント間に与えるルール設計、ツール、問題領域への理解や適切な問いの立て方が成果の差を生むポイントであると結論づけられています。当日のAI利用量としては、3人のPC合計で約25.3億トークンが消費され、その大部分がキャッシュの読み取りによるものであったことが報告されています。 引用元: https://zenn.dev/kauche/articles/f3736c660aab77 「作曲って難しいと思うじゃん？だったら遊びにしちゃえばいいんじゃね？」ということで、音楽理論やコード進行が全くわからなくても音楽が作れる作曲ツールを作った 音楽理論やコード進行の知識がなくても、直感的な操作で手軽に作曲を楽しめる個人開発のWebツールが話題を集めている。このツールは、好きな雰囲気を選んでコードを並べ、その上にメロディを一音ずつ乗せていくという初心者向けのステップを採用している。完全無料で登録不要で利用でき、完成した楽曲はMIDI形式で保存することが可能だ。そのため、初心者が音楽づくりの楽しさを体験できるだけでなく、作成したデータを「Synthesizer V」などのボカロソフトや本格的なDAWに読み込ませて、本格的な楽曲制作の導入として活用することもできる。X（旧Twitter）での共有機能も備えており、手軽に友人へ曲を届けて聴いてもらうことも可能となっている。 引用元: https://togetter.com/li/2765526 お便り投稿フォーム VOICEVOX:春日部つむぎ

See All (121)

About

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

Information

You Might Also Like