SM1: Mamba1のd_state=1閉形式解がBlackwellで動作
RedditのMachineLearningコミュニティで、Mamba1アーキテクチャの興味深いバリアント「SM1（Scalar Mamba1）」が発表された。d_state=1という条件に特化することで、セレクティブスキャン全体を2つのネイティブPyTorch演算に置き換えるというアイデアだ。
具体的には、torch.cumprodとtorch.cumsumを組み合わせた閉形式解により、逐次計算と浮動小数点精度で完全に同一の結果を得られるという。近似ではなく、d_state=1という境界条件の下での厳密な解だ。d_state=2以上ではこの閉形式は成立しない。
実用的なメリットも大きい。Mamba1のスキャン中間表現は(B, T, F, S)の4次元だが、SM1はS次元を完全に排除する。d_state=16のMamba1と比較してスキャンメモリが16分の1になる。130Mパラメータモデルの推論状態は約14,080個のfloat（56KB）に収まり、KVキャッシュ不要でO(1)のトークン単位コストを実現する。
RTX 5060 Ti（16GB）上で130Mパラメータモデルの学習が可能で、作者は163KのMIDIファイル（約25億トークン）での学習を進めている。トークン化で構造をエンコードすれば、d_stateはスカラーで十分という主張は興味深い。
ただしGoogleの公式推奨ではなく、コミュニティの実験的実装である点には注意が必要だ。
Spice: AIエージェントの「意思決定」を司るOSSレイヤー
「Spice」というオープンソースプロジェクトが、AIエージェントの実行レイヤーの上に位置する決定レイヤーの構築を目指している。
Claude Code、Codex、Hermesなどの実行エージェントは「何かをする」ことには優れているが、「何をすべきか」「いつすべきか」の判断は現在ユーザーのプロンプトに依存している。Spiceはこの判断部分を構造化しようとする試みだ。
コアループは「知覚→状態モデル→シミュレーション→決定→実行→振り返り」。コンテキストを理解し、複数の将来をシミュレーションし、構造化された決定を行い、適切なエージェントにタスクを委譲するという流れだ。監査可能性とトレーサビリティも謳っている。
既存のエージェントを置き換えるものではなく、その上に位置する「脳」として設計されている。アイデアとしては面白いが、プロジェクトはまだ初期段階であり、実際の有効性はこれからの検証を待つ必要がある。
Claude Codeの/workflows機能がchangelogに載った翌日に削除される
Qiitaで興味深い検証記事が掲載された。Claude Code v2.1.147（2026年5月20日公開）のchangelogに「Workflow tool」という新機能の追加が記載されていた。マルチエージェントの直列連鎖をLLMの判断ではなく決定論的コードで制御する機能だったが、翌日にはGitHub Actionsのコミットでこの記述が削除されたという。
公式ドキュメントと実際の実装の間に乖離がある事例として、開発者の間で議論を呼んでいる。changelogに一度記載された機能が、アナウンスなしに削除されるのは、APIやツールの安定性を重視する開発者にとって懸念材料だ。
この一件は、AI開発ツールの急速な反復がもたらす「ドキュメントの信頼性」問題の一例と言える。
RAGのチャンキング品質を可視化する実践ベンチマーク
Redditで、3つのプロダクションサイト（Intercom、HubSpot、KPMG）のコンテンツを使ったRAGチャンキングと埋め込みの比較実験が共有された。
各サイトのコンテンツを階層化（HIGH/MEDIUM/LOW/REJECTED）し、検索品質を評価した結果、コンテンツ密度によってRAGの効果が大きく異なることが示された。IntercomのHIGHチャンクの96%はヘルプセンター記事、HubSpotのHIGHは具体的なケーススタディ、KPMGはコンテンツ全体がポジショニングの文章であり、HIGHチャンクがほぼ存在しなかった。
面白いのは「yield score」（HIGH+MEDIUMチャンクの比率）という指標で、これがRAG生成前のコーパス品質の予測に使えるという発見だ。Intercomが31%、HubSpotが32%、KPMGが8%であり、この数字が低いブランドほど、より慎重な表現とロバストなフォールバックが必要になるという。
RAGのベンチマークはソースの品質が均質であると仮定しがちだが、現実のコンテンツは非常に不均質であることを示した実用的な研究だ。