NVIDIAが「cuFile API」をオープンソース化／キオクシアとSandiskがQLC技術と332積層を用いた第10世代3Dフラッシュメモリを開発

　うっかり見逃していたけれど、ちょっと気になる――そんなニュースを週末に“一気読み”する連載。今回は、8月2日週を中心に公開された主なニュースを一気にチェックしましょう！

【その他の画像】

●NVIDIAが「cuFile API」をオープンソース化

　NVIDIAは8月4日、米カリフォルニア州サンタクララで開催中のストレージ関連イベント「FMS：The Future of Memory and Storage」（8月4日〜6日）に合わせ、AI向けストレージ技術に関する取り組みを発表した。

　注目ポイントは、GPUがストレージに直接読み書きするためのAPI「cuFile」のオープンソース化と、業界横断の規格作りイニシアチブ「Storage-Next」の2つだ。

　cuFileはGPUDirect Storageの構成要素で、CPUを介さずGPUからストレージへ直接アクセスするためのAPIだ。今回、このAPIと、その下位にあるストレージソフトウェアスタックがオープンソース化された。公開先はGitHub上の「xio-sig」で、初期メンテナーとしてGoogle、Intel、NVIDIA、Metaの4社が名を連ねる。数十万規模のGPUスレッドと広帯域メモリを使い、マイクロ秒単位でストレージ上のデータにアクセスできるとのことだ。

　Storage-Nextは、ストレージメーカー、コントローラーベンダー、冷却／熱設計、標準化団体などを集め、GPU起点のストレージがどう振る舞うべきかを共通仕様としてまとめる取り組みだ。DDN、キオクシア、Micron Technologyを含む40社以上が参加する。

　その基盤技術として、GPUが必要なデータだけをストレージから自身の高速メモリへ直接読み込む「SCADA（scaled, accelerated data access）」を提供する。

　SCADAは速度を優先して他プロセスのメモリを侵すことがないよう、速度が必要なユーザー側の処理を信頼境界の外に置き、権限を持つ別コンポーネントがアクセス経路を設定する二段構えを採る。

●キオクシアとSandiskがQLC技術と332積層を用いた第10世代3Dフラッシュメモリを開発

　キオクシアとSandiskは8月4日、QLC（4ビット／セル）技術を用いた第10世代の3次元フラッシュメモリ技術を発表した。332層の積層技術と設計上の工夫により、第8世代の3次元フラッシュメモリと比べてビット密度を最大60％高めたという。

　回路の作り方も変えている。CMOSロジック回路とメモリアレイを別々のウエハーに形成し、後から高精度に貼り合わせる「CBA（CMOS directly Bonded to Array）」技術を採用した。

　これにより読み出し／書き込みの帯域幅を第8世代より高め、QLC方式の3次元フラッシュメモリとしては業界で初めて毎秒4.8Gbのインタフェース速度を実現したとのことだ。インタフェースにはToggle DDR6.0とSeparate Command Address（SCA）プロトコルを用いる。

　加えて、「PI-LTT（Power-Isolated Low-Tapped Termination）」技術によってデータ出力転送時の電力効率を改善した。AIやクラウドインフラで問題になる消費電力と冷却への対応を狙ったものだという。

　キオクシアの技術統括責任者である宮島秀史氏は、QLC技術を用いた第10世代フラッシュメモリの製品化に向けて開発を加速させるとコメントしている。現時点では技術の発表にとどまり、製品化の時期は示されていない。

●キオクシアがAIアプリケーション向けの高速SSD「KIOXIA GP1」シリーズを発表

　キオクシアは8月4日、AIアプリケーション向けSSD「KIOXIA GP1シリーズ」を開発したと発表した。GPUからの直接アクセスに対応し、512Byte単位で最大1000万のランダムリードIOPSを実現するという。同社が「Super High IOPS SSD」と位置付ける製品だ。2026年3月に開発を発表したGPシリーズの第1弾にあたる。

　狙いは、GPUの高帯域幅メモリ（HBM）をフラッシュメモリの階層で補うことにある。HBMそのものを増設するよりも大幅に低いコストで、より大規模なデータセットを扱えるようにするというのが同社の説明だ。

　インタフェースはPCIe 6.0で、NVMe 2.2規格に対応する。フラッシュメモリには低遅延をうたう第2世代のKIOXIA XL-FLASHを採用した。従来のTLCベースのSSDと比べ、IOPS性能が高く、512バイトという細かい単位でアクセスでき、I/O当たりの消費電力も低いとのことだ。

　同社によれば、このアーキテクチャは現在の1000万IOPSから将来的に最大1億IOPSまで拡張することを視野に設計されている。

　フォームファクターはE3.SとE1.Sの9.5mm／15mmを用意する。E3.SとE1.Sの9.5mmは液冷にも対応し、全形態が従来の空冷環境で使える。耐久性は最大50 DWPDとなる。

●Google パスワード マネージャーに脆弱性

　Palo Alto Networksの脅威研究チーム「Unit 42」は8月3日、パスワードレス認証に対する新しい攻撃手法をまとめたレポートを公開した。対象はGoogleの同期型パスキーと、デスクトップ環境で使われるクラウド認証器だ。検証はWindows上のChromeとTPM搭載機に絞っている。

　前提として、いずれの手法も攻撃者のマルウェアが既に端末上で動いていることを条件とする。ただし、管理者権限への昇格は必要ない。同チームは3種類の手法を「Pass-ta-key」と総称し、それぞれ異なる前提を突くと説明している。

　1つ目の「Pass-ta-key attack」は端末の識別鍵を悪用するもので、ユーザーの操作も画面ロック解除も生体認証もないままログインが成立する。

　2つ目の「Silver Pass-ta-key attack」はクラウド認証器に攻撃者が用意した鍵を登録させ、生体認証を済ませたと誤認させる手法だ。

　この場合、以降は被害者の端末がオフラインでも認証できるようになる。

　3つ目の「Golden Pass-ta-key attack」はパスキーを復号するマスターキーそのものを取り出すもので、成立すればアカウントに登録された全てのパスキーが取り出せる。

　サービス側の実装にも問題が見つかった。WebAuthnには、ユーザー本人の検証が済んだかどうかを示す「UVフラグ」がある。多くのサービスはこの検証を必須にせず「望ましい」設定に留めており、さらに必須に設定しながらフラグを正しく検証していないサービスも確認されたという。

　この場合、多要素認証を求めていても実質的に1要素になる。Unit 42はeBayでこの状態を確認したとしており、報告を受けたeBayは既に修正済みだ。GitHubでは正しく拒否されたとしている。

　マスターキーについては、Chromeのログに平文で出力されていた問題をGoogleが修正した。ただし鍵自体は今もクライアント側に送られており、メモリ上からは取得し得る状態だという。加えて、現在の実装ではこの鍵を無効化したり入れ替えたりする手段がない。

　なお、Unit 42は暗号方式そのものが破られたわけではなく、設計上の前提と実際の実装との間にできた隙間を突いたものだとしている。脆弱（ぜいじゃく）性は責任ある開示の手順を踏んで報告済みだ。同チームは、サービス提供者に対してUVフラグの厳格な検証を、利用者に対しては端末のマルウェア対策を引き続き重視するよう求めている。

●Sakana AIがLLM APIサービス 「Sakana Namazu」の提供を開始

　Sakana AIは8月3日、日本語に特化した大規模言語モデル（LLM）のAPI「Sakana Namazu（サカナ・ナマズ）」の提供を開始した。

　同社のチャットサービス「Sakana Chat」に搭載してきたLLM「Namazu」を更新し、API経由で使えるようにしたものだ。Web検索とコード実行がビルトインのツールとして用意されている。APIはOpenAI互換で、既にOpenAIのAPIを使っているコードであれば、base_urlの書き換えとAPIキーの設定だけで移行できるとのことだ。

　ベースになっているのは、中国のMoonshot AIが公開するオープンモデル「Kimi K2.6」だ。同社はこれに社内の独自データを使い、日本語と日本の業務文脈に合わせる調整を加えた。あわせて、特定の話題で応答を避ける挙動や出力の偏りを抑えるチューニングも施したという。

　ベンチマークについては、数学的推論のAIME26、知識と推論のMMLU-Pro、コーディングのLiveCodeBench v6でベースモデルの性能を維持したとしている。

　日本語側では、Preferred Networksが開発した指示追従性能のJFBench、社内で構築した日英翻訳タスクと回答の中立性を測るFairPoliticsQAのいずれでも、ベースモデルを上回った。FairPoliticsQAのスコアは34.10％から56.30％に上がっている。

　料金は従量課金のみで、月額プランはない。100万トークンあたり入力0.95ドル、出力4.00ドル、キャッシュされた入力0.15ドルだ。

　思考トークンは出力と同じ単価になる。ビルトインツールは別課金で、Web検索が1000回あたり7.00ドル、コード実行が1時間あたり0.12ドルとなっている。

　なお、同社は開発の背景として、日本語で業務に使えるLLM APIの選択肢がまだ限られている点を挙げている。フロンティアモデルはコストが高く、オープンモデルをそのまま使うと品質やデータの扱いに不安が残るため、その中間を埋める選択肢として開発したという。エンタープライズ向けの展開も視野に入れているとのことだ。

●Gensparkがローカルで動作する統合オフィス環境「GenOffice」をリリース

　Gensparkは8月3日、AI機能を組み込んだオフィススイート「GenOffice」をオープンソースとして公開した。同社は「世界初のフル機能オープンソースAIオフィススイート」とうたっている。

　構成は文書作成のDocs、表計算のSheets、プレゼンテーションのSlides、PDFの4つと、それらをタブでまとめるシェルだ。

　5つのElectronアプリが共通のエンジン層を使う設計になっている。扱えるファイル形式はWord（.docx）、Excel（.xlsx）、PowerPoint（.pptx）とPDFで、対応OSはmacOS（Apple Silicon）、Windows、Linuxとなっている。

　各アプリには同じAIパネルが組み込まれている。同社の「Genspark Super Agent」を内蔵し、調査やデータ処理、文書やスライドの作成まで扱えるとしている。Docsではブロック単位でのAI編集にバージョンの記録と差分表示が付き、他のアプリではワークブックやスライド、PDFの状態に対してツール呼び出し型のエージェントが動く。

　実装面では、docxの読み書きで変更のあった段落だけを作り直し、触っていない部分は元ファイルのバイト列をそのまま保持する方式を採る。Word側でレイアウトが崩れるのを避ける狙いだ。Sheetsはオープンソースの表計算エンジン「Univer」をベースに独自の拡張を重ね、xlsxの入出力は自社製のRustコンポーネントが担う。

　ライセンスはApache License 2.0だ。ただし将来のエンタープライズ機能向けに用意されたeeディレクトリだけは別のライセンスが適用される。またGenOfficeとGensparkの名称・ロゴはMainfuncの商標で、Apache-2.0は商標の使用までは許諾しないため、フォークする場合は独自のブランドを使うよう求めている。

　同社によると、GenOfficeを作るのに要したのはエンジニア1人と1週間、そしてトークン代1万ドルだったとのことだ。現時点ではα版だと明言しており、フィードバックを寄せた人には1000以上のGensparkクレジットを提供するという。