nwiizo

LSM-Tree: MemtableからCompactionまで自作する

トランザクション分離レベル: Write Skewを手で再現する

 CRDT -- 結果整合性で「正しい」とは何か

はじめにキャッシュクラスタへノードを足すたびにヒット率が壊滅する。最初にこの問題へ出会ったのは、memcachedクラスタのスケーリングを調べていたときだった。hash(key) % Nの何が悪いのか、当時は正直よくわからなかった。実装して計測してみると、問題の大きさが数字で見える。hash(key) % N の問題分散システムでデータを複数ノードに振り分ける最も素朴な方法は hash(key) % N だ。Nノードに対してキーが一様に分散し、実装も簡単。だが、ノードを1つ追加すると何が起きるか。N=4からN=5に変えると、hash(key) % 4 と hash(key) % 5 はほとんどのキーで異なる値を返す。実測してみると、10万キーのうち約80%が別ノードに再配置される。let num_keys = 100_000;let n_before = 4u64;let n_after = 5u64;let mut moved = 0;for i in 0..num_keys { let hash = compute_hash(&format!("key-{i}")); if hash % n_before != hash % n_after { moved += 1; }}// moved ≈ 79,917 (79.9%)79.9%。キーの8割が別のノードに移動する。キャッシュクラスタであれば、ほぼ全キーがcold startになるのと同じだ。深夜のデプロイでこれが起きたら、背後のDBに全トラフィックが直撃する。ハッシュリングの仕組みConsistent hashingは、ノードとキーを同じハッシュ空間上のリングへ配置する。キーは時計回りで最初に見つかるノードへ割り当てる。ノード追加時に移動するのは、新ノードと反時計回りの隣接ノードに挟まれたキーだけ。理論上は 1/N の移動で済む。use std::collections::BTreeMap;pub struct HashRing { ring: BTreeMap<u64, String>, virtual_nodes: u32, nodes: Vec<String>,}impl HashRing { pub fn get_node<T: Hash>(&self, key: &T) -> Option<&str> { if self.ring.is_empty() { return None; } let hash = compute_hash(key); // 時計回りに最初のノードを探す self.ring .range(hash..) .next() .or_else(|| self.ring.iter().next()) .map(|(_, n)| n.as_str()) }}BTreeMapのrange(hash..)が二分探索でO(log N)のルックアップを実現する。ハッシュ値の上限を超えたらリングの先頭に巻き戻す。仮想ノードが解決するもの物理ノードが3つだけだと、リング上の配置は偏りやすい。あるノードがリングの大きなアークを担当し、他のノードはほとんどキーを受け持たない。そういう状況が容易に起こる。仮想ノードは1つの物理ノードに複数のポイントを割り当てる。仮想ノード数100なら、各物理ノードはリング上に100個の点を持つ。統計的にアークが均等化される。5ノード・10万キーで仮想ノード数を変えて標準偏差を測定した。 仮想ノード数 標準偏差 変動係数(CV) 1 10,396 0.520 10 3,044 0.152 50 2,178 0.109 100 908 0.045 500 749 0.037 仮想ノード1つ（＝物理ノードのみ）ではCV=0.52、つまりノード間の負荷差が平均の52%にもなる。100に増やすとCV=0.045まで改善する。500でさらに下がるが、改善の幅は小さくなる。最初にvirtual_nodes=10で試したとき、5ノードのうち1つはキーの35%を抱えていた。一方、別の1つは11%しか持っていなかった。3倍以上の偏りだ。「10もあれば十分だろう」という見積もりは甘かった。仮想ノード数を100から500に増やしても標準偏差の改善は908から749で、約17%しか縮まらない。一方でメモリ消費とring更新コストは線形に増える。収穫逓減の境目が100〜150あたりにある。この実装で使っているDefaultHasherの分布品質が今回の入力に対して十分であれば、その範囲で止めるのが妥当だろう。ハッシュ関数を変えればこの数字も変わる。代償としてリング上の点が増え、メモリ使用量とルックアップのBTreeMap探索コストが上がる。500ノード × 100仮想ノード = 5万点のBTreeMapは問題にならないが、設計時に意識しておく価値はある。キー移動の最小性4ノードから5ノードへの増設で、キー移動率を計測する。mod N: 79.9% が移動Consistent hashing (100 virtual nodes): 19.9% が移動理想値 (1/5): 20.0%Consistent hashingの移動率は理想値とほぼ一致する。新しいノードが担当する分だけが移動し、既存ノード間の移動は起こらない。ノード削除時も同様だ。削除されたノードが担当していたキーだけが残りのノードに再分配され、それ以外のキーは動かない。Rendezvous HashingConsistent hashingの代替としてRendezvous Hashing（HRW: Highest Random Weight）がある。各キーについて全ノードとの「重み」を計算し、最大重みのノードを選ぶ。pub struct RendezvousHashing { nodes: Vec<String>,}impl RendezvousHashing { pub fn get_node<T: Hash>(&self, key: &T) -> Option<&str> { self.nodes .iter() .map(|node| { let weight = compute_weight(key, node); (weight, node.as_str()) }) .max_by_key(|(w, _)| *w) .map(|(_, n)| n) }}仕組みが単純で、仮想ノードなしで均等な分布を実現する。ノード追加時の移動率も理想値（実測20.2%、理想20.0%）にほぼ一致する。ただし、ルックアップがO(N)だ。全ノードとの重み計算が必要になる。ノード数が数百を超えると、consistent hashingのO(log N)との差が効いてくる。ノード数が少ないシステム（CDNのエッジ選択など）では有力な選択肢。Jump Consistent HashGoogleが2014年に提案したJump Consistent Hashは、メモリゼロ・O(ln N)のルックアップで均等な分布を達成する。pub fn jump_consistent_hash(key: u64, num_buckets: u32) -> u32 { let mut b: i64 = -1; let mut j: i64 = 0; let mut k = key; while j < num_buckets as i64 { b = j; k = k.wrapping_mul(2862933555777941757).wrapping_add(1); j = ((b + 1) as f64 * ((1i64 << 31) as f64 / ((k >> 33) + 1) as f64)) as i64; } b as u32}10バケットへの10万キーの分布を測定すると、最大偏差0.52%という均等性を示す。バケット追加時の移動率も理想値との誤差0.05%以内。制約は、バケットが「末尾にしか追加・削除できない」こと。バケット0〜9があるときにバケット3だけを削除する、といった操作はできない。任意のノード障害がある分散ストレージには使えないが、シャード数を動的に増やすシナリオ（Kafkaパーティションの拡張など）には適合する。Jump以降の系譜 -- AnchorHash, DxHash, MementoHashJumpの制約は実運用では痛い。任意のノードがいつ落ちるかわからない分散ストレージで「末尾しか削除できない」はそのまま使えない。だから2018年以降、Jumpの長所（均等性とメモリ効率）を残したまま任意削除を許す系統が出てきた。AnchorHash（Mendelson et al., IEEE/ACM ToN 2021）は、最大ノード数 a を事前に決め、長さ a の「アンカー配列」を持つ。各位置は active/removed のいずれかを表す。任意のノードを削除できるが、メモリは想定最大ノード数に比例し、a を超えてスケールできない。DxHash（Dong et al., ACM TOIT 2024）は、AnchorHashと同じく事前確保型だが、内部表現を擬似乱数列ベースに変えてメモリを大幅に削減する。論文では同等性能でAnchorHash比メモリ最大98.4%減を主張する。上限 a の制約は残る。https://dl.acm.org/doi/abs/10.1145/3631708dl.acm.orgMementoHash（Coluzzi et al., IEEE Access 2024）はJumpを土台に「削除済みバケットの墓標テーブル」を被せる。ルックアップでJumpの結果が削除済みなら、削除時点の生存バケット数 wb で h mod wb の再ハッシュをかけ、生存側へ転送する。最大容量の事前指定は要らず、メモリは「削除済みノード数」にだけ比例する。arxiv.org// 削除トレース: bucket -> (replacer, prev_removed)replacements: HashMap<u32, (u32, u32)>,pub fn get_bucket<T: Hash>(&self, key: &T) -> u32 { let base = compute_hash(key); let mut b = jump_consistent_hash(base, self.b_array_size); while let Some(&(replacer, _)) = self.replacements.get(&b) { // bが削除済みなら、削除時のworking_set_size-1をmodulusに再ハッシュ let h = rehash_for_bucket(base, b); b = (h % replacer as u64) as u32; // 再ハッシュ先も「より新しい削除」なら置換チェーンを登る while let Some(&(r, _)) = self.replacements.get(&b) { if r < replacer { break; } b = r; } } b}このアプローチの弱点は、削除率が高くなるほど内側ループが伸びることだ。論文はノードの70%以上が同時にdownするような状況を最悪ケースと位置づけており、そこまで壊れていなければAnchor/Dxよりも平均性能で勝る、と主張する。通常運用で同時down率が数%に留まるなら、MementoHashの平均ケースが効く。Dynatraceから出たJumpBackHash（Ertl, SP&E 2024）は方向が違う。任意削除はサポートしない代わりに、Jumpの内部にあった浮動小数点演算とジャンプ計算を整数演算で書き直し、active indices を逆順に生成する形に変えた。期待実行時間がバケット数に依存せず一定で、Jumpより速い。Hash4jにJava実装が入っている。シャード数を動的に増やすだけのワークロード（KafkaのパーティションやKey-Valueキャッシュのシャーディング）では、Jumpの自然な後継として置き換えやすい。https://onlinelibrary.wiley.com/doi/10.1002/spe.3385onlinelibrary.wiley.com5手法の比較 特性 Consistent (リング) Rendezvous Jump JumpBack Memento ルックアップ O(log N) O(N) O(ln N) 期待O(1) O(ln N) ＋ 削除数依存 メモリ O(N × V) O(N) O(1) O(1) O(削除数) 浮動小数演算 不要 不要 必要 不要 必要(Jump呼出) 任意ノード削除 可 可 不可 不可 可 最大ノード数の事前指定 不要 不要 不要 不要 不要 分布均等性 仮想ノード依存 良好 極めて良好 極めて良好 良好（削除多いと劣化） 万能解はない。系統だった性能比較は Coluzzi & Brocco (SEBD 2023) にまとまっており、用途別の選び方の指針は次節で扱う。https://ceur-ws.org/Vol-3478/paper03.pdfceur-ws.org現実のシステムDynamoの2007年の論文（DeCandia et al.）では、consistent hashingを改良した"preference list"を採用している。各キーのレプリカを、リング上の次のN個の異なる物理ノードに配置する。仮想ノードと組み合わせることで、ノード障害時にも負荷が均等に分散される設計だ。単純なconsistent hashingでは、「次のノード」が同じ物理ノードの別の仮想ノードである可能性がある。preference listではそれをスキップする。この工夫がなければ、レプリケーションの意味がない。Cassandraもvnodeを使うが、デフォルト値はバージョンで変わる。Cassandra 3.11系ではnum_tokensのデフォルトが256だったが、4.0以降は16に変更された。これは、vnode数を増やすほど分布は滑らかになるが、repairや範囲操作の管理コストも増えるためだ。公式ドキュメントも、3.0以降のトークン割り当てアルゴリズムでは、より少ないトークン数で負荷分散を改善できると説明している。memcachedクライアント（libmemcached等）やNginxのConsistent Hash Load Balancingモジュールも同じ原理を使っている。ただしレプリケーションを持たない分、設計はずっと単純だ。この実装の限界この記事の実装で使っているDefaultHasherは、Rust公式ドキュメント上は内部アルゴリズムが非公開だ。リリースをまたいで結果に依存してはいけない。本番環境では、xxhash、HighwayHash、AHashなどから、速度・分布・攻撃耐性の優先順位を明示して選ぶ必要がある。consistent hashingではハッシュ値の偏りがそのままノード負荷の偏りになる。また、ホットキー問題（特定のキーへのアクセスが極端に集中する）は、リングの構造では解決できない。リングが保証するのはキーの配置の均等性であって、アクセス頻度の均等性ではない。人気商品のキャッシュキーが1つのノードに集中する問題は、リングの外側で対処することになる。たとえばクライアント側のローカルキャッシュやキー分割（popular_item:shard_0, popular_item:shard_1）を使う。現代のWebサービスでどう考えるかConsistent hashingを使う場面は、キャッシュ、セッションストア、WebSocket接続の配置、ジョブキューのpartition割り当てなどだ。ノード追加・削除のたびに全キーを動かしたくない領域で効く。Kubernetesやオートスケーリングでノードの寿命が短くなるほど、hash(key) % Nの危うさは表に出る。アルゴリズム選定の指針もここ数年でかなり明確になってきた。任意のノードがいつでも落ち得る分散ストレージなら、リング型かMementoHashが第一候補になる。シャード数を末尾追加するだけのKey-Valueキャッシュやストリームのパーティションなら、JumpかJumpBackHashで十分だ。最大ノード数を事前に縛れて、メモリも抑えたいならAnchorHash/DxHash。リング型を選ぶときも、buraksezer/consistent のようにconsistent hashing with bounded loadsを併用してホットノードを抑える運用が広がっている。github.comただし、リングは負荷分散の万能薬ではない。ホットキー、ノード性能差、リージョン間レイテンシ、キャッシュウォームアップは別問題だ。Webサービスで使うなら、仮想ノード数だけでなく、キー移動率、ノード別QPS、キャッシュヒット率、再配置時のバックエンドDB負荷をメトリクスとして見る。Rust実装では、ハッシュ関数を明示的に選び、DefaultHasherのリリース間安定性に依存しない。配置アルゴリズムは一度本番データに乗ると、ハッシュ関数の変更自体が大規模なキー移動になる。おわりにノード追加で80%のデータが動く設計は、ノードを増やせない設計と同義だ。consistent hashingはこの問題を数パーセントの移動に抑える。CV=0.045で満足するか、0.037まで追うか。その判断にかかるコストは、仮想ノード数を5倍にするメモリとルックアップの代償だ。分散システムの設計は、この種のトレードオフの積み重ねでできている。参考文献Karger et al. (1997). Consistent Hashing and Random Trees. STOC '97.Lamping and Veach (2014). A Fast, Minimal Memory, Consistent Hash Algorithm. Jump Consistent Hashの原論文。DeCandia et al. (2007). Dynamo: Amazon's Highly Available Key-value Store. SOSP '07.Mendelson et al. (2020). AnchorHash: A Scalable Consistent Hash. 任意削除＋最大容量固定の系統。Dong et al. (2023). DxHash: A Memory-Saving Consistent Hashing Algorithm. ACM TOIT. 擬似乱数列ベースでAnchorHashのメモリを大幅削減。Coluzzi et al. (2024). MementoHash: A Stateful, Minimal Memory, Best Performing Consistent Hash Algorithm. IEEE Access. Jump＋墓標テーブルで任意削除を実現。Ertl (2024). JumpBackHash: Say Goodbye to the Modulo Operation to Distribute Keys Uniformly to Buckets. SP&E. Jumpの浮動小数除去と高速化。Coluzzi & Brocco (2023). A Survey and Fair Comparison of Consistent Hashing Algorithms. SEBD '23. AnchorHash・DxHash・Jump系の系統的ベンチマーク。Mirrokni, Thorup, Zadimoghaddam (2018). Consistent Hashing with Bounded Loads. SODA '18. ホットノード抑制の理論的下地。

Consistent Hashing -- 仮想ノードとキー分布の均等性

おい、要件を殺すな

はじめにRocksDBのソースを読んでいて、SSTableごとにBloom filterが挟まっている箇所に出くわした。概念は知っていたが、パラメータの導出を自分で追ったことはなかった。数式を眺めるだけでは全然理解できない悲しい子なので、Rustでゼロから書いて理論値と実測値を突き合わせることにした。結果として、ハッシュ関数の設計で半日つまずくことになる。「ないもの」を探すコストデータベースに対する読み取りの大半は、存在しないキーへのアクセスだったりする。LSM-treeベースのストレージエンジンでは、この問題が顕著になる。Memtableにない、最新のSSTableにない、その前のSSTableにもない。最終的にディスク上の全SSTableを走査しなければ「存在しない」と結論づけられない。Bloom filterは「確実にない」を高速に判定する。偽陽性（存在しないのに「ある可能性がある」と答える）は許容するが、偽陰性（存在するのに「ない」と答える）は決して起こさない。この非対称性が、存在しないキーへの無駄なディスクアクセスを防ぐ。ビット配列とハッシュ関数原理は単純だ。m個のビット配列を用意し、すべて0で初期化する。要素を追加するとき、k個の独立なハッシュ関数で位置を計算し、そのビットを1にする。問い合わせ時、k個すべてのビットが1なら「たぶんある」、1つでも0なら「確実にない」。問題はk個の独立なハッシュ関数をどう用意するかだ。実用的には、2つのハッシュ値から残りを導出するdouble hashing技法を使う。Kirsch & Mitzenmacherが2004年に示したように、h_i(x) = h1(x) + i * h2(x) で十分な独立性が得られる。論文名は "Less Hashing, Same Performance: Building a Better Bloom Filter"。use std::collections::hash_map::DefaultHasher;use std::hash::{Hash, Hasher};fn double_hash<T: Hash>(item: &T) -> (u64, u64) { let mut hasher1 = DefaultHasher::new(); item.hash(&mut hasher1); let h1 = hasher1.finish(); let mut hasher2 = DefaultHasher::new(); h1.hash(&mut hasher2); item.hash(&mut hasher2); let h2 = hasher2.finish(); // h2を奇数にしてビット配列全体を均等にカバーする (h1, h2 | 1)}この| 1を最初は書いていなかった。h2が偶数になると、ビット配列のサイズによっては半分のスロットにしか到達しない。n=100程度の小さなフィルタで偽陽性率が理論値の倍近くに膨れ上がり、原因を特定するまでに数時間かかった。ビット演算ひとつで分布が壊れるという、地味だが致命的な罠だ。ここではRust標準ライブラリのDefaultHasherを使っている。ただし、公式ドキュメント上は内部アルゴリズムが安定仕様ではなく、リリースをまたいで同じハッシュ値になる保証もない。教育用の実装なら十分だが、本番のBloom filterではxxhash-rustやahashのように性能と分布特性を明示して選べるハッシュ関数を使う方がよい。最適なパラメータの数学n個の要素を格納するBloom filterで、偽陽性率pを目標にする。このとき、最適なビット数mとハッシュ関数数kは以下で決まる。記号だけ並ぶと悲しい気持ちになるので、先に対応を置く。n: 入れたい要素数p: 許容する偽陽性率m: 必要なビット数k: 使うハッシュ関数の数つまり「何件入れるか」と「どれくらい誤判定を許すか」を決めると、必要なメモリ量とハッシュ回数が決まる。最適ビット数: m = -n * ln(p) / (ln2)^2最適ハッシュ数: k = (m/n) * ln2偽陽性率の理論値: p = (1 - e^(-kn/m))^kこの式は、各ビットが独立に一様な確率でセットされるという仮定に基づく。double hashingでは厳密には独立ではないが、実用上は十分に近い値を示す。fn optimal_num_bits(n: usize, fp_rate: f64) -> usize { let m = -(n as f64) * fp_rate.ln() / (2.0_f64.ln().powi(2)); m.ceil() as usize}fn optimal_num_hashes(m: usize, n: usize) -> u32 { let k = (m as f64 / n as f64) * 2.0_f64.ln(); let k = k.round() as u32; k.max(1)}n=1000、p=0.01で計算すると、m=9586ビット（約1.2KB）、k=7。要素1つあたり約9.6ビットしか使わない。ただし、この計算はnの見積もりが正確であることを前提としている。想定以上に要素を追加するとビットが飽和し、偽陽性率が急激に上昇する。しかもBloom filterは元の要素を保持していないので、リサイズ（全要素の再挿入）は原理的に不可能だ。設計時のn見積もりをどこまで信頼できるかが、Bloom filterを使うかどうかの判断基準になる。Rust実装ビット配列はVec<u64>で手実装する。64ビット単位で管理することで、CPUのワードサイズに合わせた効率的な操作ができる。pub struct BloomFilter { bits: Vec<u64>, num_bits: usize, num_hashes: u32,}impl BloomFilter { pub fn new(expected_items: usize, fp_rate: f64) -> Result<Self, BloomFilterError> { if expected_items == 0 { return Err(BloomFilterError::ZeroItems); } if fp_rate <= 0.0 || fp_rate >= 1.0 { return Err(BloomFilterError::InvalidFpRate(fp_rate)); } let num_bits = optimal_num_bits(expected_items, fp_rate); let num_hashes = optimal_num_hashes(num_bits, expected_items); let words = num_bits.div_ceil(64); Ok(Self { bits: vec![0u64; words], num_bits, num_hashes, }) } pub fn insert<T: Hash>(&mut self, item: &T) { let (h1, h2) = double_hash(item); for i in 0..self.num_hashes { let idx = self.get_index(h1, h2, i); let word = idx / 64; let bit = idx % 64; self.bits[word] |= 1u64 << bit; } } pub fn contains<T: Hash>(&self, item: &T) -> bool { let (h1, h2) = double_hash(item); for i in 0..self.num_hashes { let idx = self.get_index(h1, h2, i); let word = idx / 64; let bit = idx % 64; if self.bits[word] & (1u64 << bit) == 0 { return false; } } true } fn get_index(&self, h1: u64, h2: u64, i: u32) -> usize { let combined = h1.wrapping_add((i as u64).wrapping_mul(h2)); (combined % self.num_bits as u64) as usize }}wrapping_addとwrapping_mulはオーバーフローをラップアラウンドで処理する。ハッシュ計算では意図的な挙動で、modulo演算で範囲内に収めるから問題ない。公開APIとして見ると、エラー型も雑にしたくない。この記事の検証crateはedition = "2024"で、エラー型はthiserrorと#[non_exhaustive]を使う形にした。ライブラリ利用者がmatchを書く余地を残しつつ、後からvariantを追加してもSemVer上の破壊を避けやすい。#[derive(Debug, thiserror::Error)]#[non_exhaustive]pub enum BloomFilterError { #[error("expected_items must be > 0")] ZeroItems, #[error("num_bits must be > 0")] ZeroBits, #[error("num_hashes must be > 0")] ZeroHashes, #[error("fp_rate must be in (0, 1), got {0}")] InvalidFpRate(f64),}この実装にはいくつかの限界がある。insertが&mut selfを要求するため、マルチスレッド環境ではMutexやRwLockで囲む必要がある。ビット単位のアトミック操作でロックフリーにする実装も考えられるが、複雑さが跳ね上がる。また、ビット配列のサイズは構築時に固定されるので、要素数の見積もりを外すと偽陽性率が急激に悪化する。本番環境ではScalable Bloom FilterやPartitioned Bloom Filterの検討が必要になるだろう。理論値 vs 実測値n=1,000 / 10,000 / 100,000で偽陽性率を計測した。各nについて、n個を挿入した後、挿入していないn*10個のキーで偽陽性を数える。 n 理論値 実測値 ビット数 ハッシュ数 メモリ 1,000 0.0100 0.0112 9,586 7 1.2KB 10,000 0.0100 0.0100 95,851 7 11.7KB 100,000 0.0100 0.0100 958,506 7 117KB n=1,000では実測値がわずかに高い。これはサンプル数の少なさによる統計的ばらつきの範囲だ。nが大きくなるにつれて理論値とほぼ一致する。要素あたりのビット数は一定（約9.6bit）で、スケーラビリティは線形だと確認できる。理論値と実測値がここまで一致するとは正直予想していなかった。double hashingは厳密には独立なハッシュ関数ではないから、偽陽性率が理論値の1.5倍程度には膨らむだろうと予想していた。Kirsch & Mitzenmacherの証明が正しいことを自分の手で確認できたのは、論文を読むだけでは得られない納得感がある。HashSetとの比較では、n=10,000の場合にBloom filterは約12KB、HashSetは推定720KBで、約60倍のメモリ効率差がある。もちろん代償として偽陽性を受け入れている。Counting Bloom Filter標準のBloom filterは要素を削除できない。たとえばcompaction後にSSTableが消える場面を考えると、対応するフィルタのエントリも消したくなる。RocksDB自体はSSTable単位でフィルタを再構築するので実際にはCountingが必要になる場面は限られるが、削除可能なフィルタの仕組みを知っておく意味はある。ビットを0に戻すと、同じビットを共有する他の要素まで消えてしまう。格納した要素の列挙もできない。「フィルタに何が入っているか」を知る方法がないので、デバッグ時にこれが地味に困る。削除が必要な場面では、Counting Bloom filterがビットをカウンタに置き換えることで対処する。pub struct CountingBloomFilter { counters: Vec<u8>, num_slots: usize, num_hashes: u32,}impl CountingBloomFilter { pub fn insert<T: Hash>(&mut self, item: &T) { let (h1, h2) = double_hash(item); for i in 0..self.num_hashes { let idx = self.get_index(h1, h2, i); self.counters[idx] = self.counters[idx].saturating_add(1); } } pub fn remove<T: Hash>(&mut self, item: &T) -> bool { let (h1, h2) = double_hash(item); let mut indices = Vec::with_capacity(self.num_hashes as usize); for i in 0..self.num_hashes { let idx = self.get_index(h1, h2, i); if self.counters[idx] == 0 { return false; } indices.push(idx); } for idx in indices { self.counters[idx] = self.counters[idx].saturating_sub(1); } true }}saturating_addでカウンタオーバーフローを防いでいる。u8なので最大255。同じスロットに256個以上の要素がマップされるとカウンタが飽和し、以降の削除で不整合が起きる。実用上は4ビットカウンタ（最大15）でも十分とされるが、u8を使うことでメモリ効率より安全性を取った。代償はメモリだ。標準Bloom filterの8倍（1bitが1byteになる）。削除が必要な場面でのみ使う。Blocked Bloom Filter -- キャッシュラインで戦う通常のBloom filterはk個のハッシュごとに散らばったビットを触る。フィルタのビット配列が大きいほどキャッシュミスが連続し、ルックアップが遅くなる。Blocked Bloom Filter（Putze et al., 2007、現在も実装パターンとして広く使われている）はビット配列を「ブロック」（64バイト＝x86のキャッシュライン1本）に区切り、1要素のk個のビットを同一ブロック内で完結させる。1要素のルックアップが1キャッシュラインアクセスで済むので、特に大きなフィルタで効く。pub struct BlockedBloomFilter { blocks: Vec<[u64; 8]>, // 各ブロック 512bit = 64byte num_blocks: usize, num_hashes: u32,}pub fn contains<T: Hash>(&self, item: &T) -> bool { let (h1, h2) = double_hash(item); let block_idx = (h1 as usize) % self.num_blocks; for i in 0..self.num_hashes { let bit = (h1.wrapping_add((i as u64).wrapping_mul(h2)) as usize) % BLOCK_BITS; let word = bit / 64; let off = bit % 64; if self.blocks[block_idx][word] & (1u64 << off) == 0 { return false; } } true}代償は偽陽性率のわずかな悪化だ。ブロックごとに要素が偏ると、特定ブロックが飽和して偽陽性が増える。検証実装では10,000要素 / 目標fp_rate=1% / 50,000のprobeで実測 fp_rate ≒ 1〜2%程度に収まる（テストでは上限3%を許容している）。「2倍弱の悪化と引き換えにキャッシュ1ライン化」と読める範囲で、ImpalaのBlocked Bloom実装などがこの設計を採用している。発展: Cuckoo Filter, Xor Filter, Ribbon Filter, Binary Fuse FilterBloom filterの後継として、Cuckoo Filter、Xor Filter、Ribbon Filter、Binary Fuse Filterが2014年以降に次々と提案されている。Cuckoo Filter（Fan et al., 2014）は要素の削除をサポートし、Bloom filterより少ないメモリで同等の偽陽性率を達成する。Cuckoo hashingの空きスロット探索を応用した構造で、フィンガープリント（要素のハッシュの一部）をバケットに格納する。Xor Filter（Graf & Lemire, 2020）はさらに激しい。構築時に全要素が既知であれば、Bloom filterの半分以下のメモリで同じ偽陽性率を実現する。構築は遅いが、参照は高速。静的なデータセット（SSTableのインデックスなど）には有力な選択肢だ。Ribbon Filter（Dillinger & Walzer, 2021）はXor Filterの「事前構築の遅さ」と「動的更新のなさ」を緩和した。RocksDB 6.20以降は NewRibbonFilterPolicy として提供されており、同じ偽陽性率（1%）でBloomの10 bits/keyに対して約7 bits/keyで済む。同社のベンチでは100万キーで27%、10万キーで30%程度のメモリ削減が報告されている。CPU使用率の増加はわずかで、特に下位レベルのSSTableのように長期常駐するフィルタほど効きやすい。rocksdb.orgBinary Fuse Filter（Graf & Lemire, 2022）はXor Filterの後継で、「ストレージ下限の8%以内」「Xorより2倍速い構築」を達成する。標準的な圧縮（gzip/zstd）と相性が良く、Cuckooより小さい。静的データに対する事実上の選択肢として置き換わりつつある。arxiv.org選び方の指針として、動的な追加・削除があるならCuckoo、書き込み一度きり・読み取り中心ならRibbonかBinary Fuse、と整理できる。RocksDBの最新versions（2024）ではdefault filter policyとしてRibbonが推奨される構成も増えている。現実のシステムでの使われ方RocksDBはSSTableごとにBloom filterを持ち、キーが含まれないSSTableへのディスクアクセスをスキップする。デフォルトは10 bits/keyで、偽陽性率は約1%。RocksDBのBloom Filter wikiにパラメータ選択の詳細がある。PostgreSQLはbloomインデックスアクセスメソッドを提供している。複数カラムの組み合わせ検索で、個別のB-treeインデックスを作るよりコンパクトになる場面がある。Cassandraはパーティションキーに対するBloom filterを各SSTableに持つ。読み取りパスでの最適化として不可欠な位置づけだ。ChromeのSafe Browsingは、Bloom filterの設計思想がよく表れている事例だ。ユーザーがアクセスする全URLをGoogleのサーバーに送信すれば正確な判定はできる。しかしそれは閲覧履歴の全量送信であり、プライバシーの観点で受け入れがたい。代わりに、既知の悪意あるURLのBloom filterをローカルに持たせる。フィルタを通過したURLだけがサーバーに問い合わせられる。偽陽性があっても、それはサーバーへの余分な問い合わせが少し増えるだけで、偽陰性（危険なURLを見逃す）は起きない。Bloom filterの非対称性がプライバシーとセキュリティの両立を可能にしている。現代のWebサービスでどう考えるかBloom filterをWebサービスに入れるかどうかは、「間違え方」を先に決める判断だ。キャッシュミスの手前、存在しないIDへのAPIアクセス、ログやイベントの重複候補、レコメンド候補の既読判定のように、偽陽性が余分な後段処理で済む場所では強い。一方で、権限チェック、課金可否、在庫確保のように「ある」と誤判定しただけでユーザー影響が出る場所には置かない。Rustで実装するときは、確率パラメータを生のf64で散らさず、構築時に検証してResultで返す。ハッシュ関数もDefaultHasherの偶然の安定性に依存しない。Webサービスの部品として使うなら、メトリクスに偽陽性率、ビット飽和率、想定要素数との差分を出す。Bloom filterは一度作るとリサイズできないので、運用で「想定したnを超えた」ことに気づける設計が必要になる。完璧な答えの代わりに、ほぼ正しい答えを返す。その代償が1要素あたり10ビット。この取引を受け入れられる場面が、システムの中には驚くほど多い。Bloom filterを知っていると、「この検索、本当に全件走査する必要があるのか」と問い直す習慣がつく。その問いかけ自体に価値がある。参考文献Kirsch, A. and Mitzenmacher, M. (2008). Less Hashing, Same Performance: Building a Better Bloom Filter. Random Struct. Algorithms.Putze, F., Sanders, P., and Singler, J. (2007). Cache-, Hash- and Space-Efficient Bloom Filters. WEA 2007 / JEA 2009. Blocked Bloom Filterの原典。Fan, B. et al. (2014). Cuckoo Filter: Practically Better Than Bloom. CoNEXT 2014.Graf, T. and Lemire, D. (2020). Xor Filters: Faster and Smaller Than Bloom and Cuckoo Filters.Dillinger, P. and Walzer, S. (2021). Ribbon filter: practically smaller than Bloom and Xor. RocksDB標準のRibbon Filter。Graf, T. and Lemire, D. (2022). Binary Fuse Filters: Fast and Smaller Than Xor Filters. ACM JEA.RocksDB Blog: Ribbon Filter -- RocksDBでの導入とベンチマーク。

Bloom Filter -- 確率的データ構造の理論と実践

 Rust のホットリロード、2026年の現在地 — hot-lib-reloader / Dioxus / Leptos を実際に動かして比較した

ドメイン規約を lint で表現する — `Order` に `is_paid + payment_id` を共存させない

はじめにエディタで .unwrap() を書いた瞬間、 clippy が黄色い波線を引きます。match で variant が漏れた瞬間、コンパイラが赤い波線を引きます。これは魔法ではなく、 rust-analyzer が rowan で構文木を作り、その上をルールが歩いている というしくみです。github.com/rust-analyzer/rowan は rust-analyzer の心臓部にある、ロスレスな構文木 (concrete syntax tree, CST) ライブラリです。これまでの記事で書いた「.unwrap() を避ける」「pub enum *Error には #[non_exhaustive] を付ける」のような ドメインの規約 は、 cargo check だけでは強制できません。 rowan を直接使えば、自分のコードベース固有のルールも CI で機械的に弾けるようになります。この記事は rowan の何が嬉しいかを整理し、 ra_ap_syntax (rust-analyzer の Rust grammar を rowan に乗せたもの) を使って 既存シリーズで紹介した規約 2 つを自家製 lint にする までを書きます。なぜ rowan か — syn と何が違うかRust で構文を扱うとき、第一候補は syn です。 proc-macro でおなじみの、AST 生成ライブラリ。syn で十分な仕事も多くあります。 では rowan は何が違うのか。 観点 syn rowan 木の種類 抽象構文木 (AST) 具象構文木 (CST, ロスレス) 空白・コメント 落ちる 保持される 構文エラー 取り出した時点で fail エラー含みで木を返す (resilient parsing) 木の表現 所有権ベース 不変共有 (Green/Red tree) 主な用途 proc-macro / コード生成 IDE / lint / フォーマッタ 「lint を書きたい」場面では、ロスレスと resilient が効きます。 // SAFETY: コメントの直前にあるか、を判定したい lint は コメントが残る木 でないと書けない。型注釈が途中で書きかけのファイルでも補完を出したいなら、 構文エラーがあっても部分木で操作できる ことが必要。 rowan はこの 2 つを正面から扱います。syn は「マクロが受け取った正しい構文を、所有権付きで操作する」のが得意。 rowan は「人間が書きかけている構文を、空白を含めて見ながら警告を出す」のが得意です。Green tree / Red tree の二層構造rowan の特徴的な内部設計が 2 層 です。 Green tree は不変・スレッド共有可能な木で、 Arc で参照カウントされた node がノード間で再利用されます。 Red tree (SyntaxNode) は Green tree の上に 親ポインタとオフセット情報 を載せた viewer で、こちらが lint コードから触る側です。何が嬉しいか:ファイル中の同じ識別子 (Foo) は Green node を共有できる → メモリが食わない編集が起きたとき、変わらない部分の Green node はそのまま再利用 → 差分パースが速いRed node は node.parent() / node.children() / node.text_range() といった IDE で必要な操作を全部持っているユーザーとしては「Red 側の SyntaxNode を歩く」だけ理解すればよくて、Green 側は黒箱で構いません。ra_ap_syntax で Rust をパースする最小コードrowan 自体は 言語に依存しないフレームワーク です。Rust を rowan で扱いたいときは、 rust-analyzer がパッケージとして公開している ra_ap_syntax を使います。 rust-analyzer の grammar をそのまま借りられるので、自分でパーサーを書く必要はありません。# Cargo.toml[dependencies]ra_ap_syntax = "0.0.331"rowan = "0.16"最小コード。use ra_ap_syntax::{ast::AstNode, Edition, SourceFile};fn main() { let src = r#" fn run() -> Result<(), std::io::Error> { let s = std::fs::read_to_string("a.txt").unwrap(); Ok(()) } "#; let parse = SourceFile::parse(src, Edition::Edition2021); // 構文エラーがあってもここで panic しない for err in parse.errors() { eprintln!("syntax error: {err}"); } let tree = parse.tree(); for node in tree.syntax().descendants() { if let Some(method) = ra_ap_syntax::ast::MethodCallExpr::cast(node) { if let Some(name) = method.name_ref() { if name.text() == "unwrap" { let range = method.syntax().text_range(); println!("unwrap() at {:?}", range); } } } }}SourceFile::parse は Parse<SourceFile> を返し、 .tree() で SourceFile AST を取れます。 SourceFile::syntax() で SyntaxNode (Red tree) に戻せて、 descendants() で全 node を歩けます。 lint を書くときの基本は descendants でループ → AST cast → 述語チェック → range を診断に乗せる の 4 ステップです。例 1: .unwrap() を検出する lint「unwrap() を書きそうになったときの選択肢8つ」の記事で示した規約「プロダクションコードで .unwrap() を書かない」を機械化します。syu-m-5151.hatenablog.comuse ra_ap_syntax::ast::{self, AstNode};pub struct UnwrapLint;#[derive(Debug)]pub struct Diagnostic { pub message: String, pub start: usize, pub end: usize,}impl UnwrapLint { pub fn check(&self, file: &ast::SourceFile) -> Vec<Diagnostic> { let mut diags = Vec::new(); for node in file.syntax().descendants() { let Some(method) = ast::MethodCallExpr::cast(node) else { continue; }; let Some(name) = method.name_ref() else { continue }; if name.text() != "unwrap" { continue; } // テストコード配下なら飛ばす（後述の補助関数） if is_in_test_context(method.syntax()) { continue; } let range = method.syntax().text_range(); diags.push(Diagnostic { message: "`.unwrap()` is forbidden in production code".into(), start: range.start().into(), end: range.end().into(), }); } diags }}ポイントは is_in_test_context。#[cfg(test)] mod tests { ... } や #[test] fn ... の中なら見逃したい。 SyntaxNode::ancestors() を使えばたどれます。use ra_ap_syntax::ast::{HasAttrs, HasName};fn is_in_test_context(node: &ra_ap_syntax::SyntaxNode) -> bool { for ancestor in node.ancestors() { if let Some(func) = ast::Fn::cast(ancestor.clone()) { if func.attrs().any(|a| { a.path() .map(|p| p.syntax().text().to_string() == "test") .unwrap_or(false) }) { return true; } } if let Some(module) = ast::Module::cast(ancestor.clone()) { if module .name() .map(|n| n.text() == "tests" || n.text() == "test") .unwrap_or(false) { return true; } if module.attrs().any(|a| a.syntax().text().to_string().contains("cfg(test)")) { return true; } } } false}これで cargo test で隔離された .unwrap() は流して、本番コードだけ弾けます。 clippy::unwrap_used よりも 「test 配下を除外」のヒューリスティックが自分で調整できる ところが自家製 lint の利点です。例 2: 公開 enum で #[non_exhaustive] 漏れを検出「thiserror と #[non_exhaustive] で SemVer に強いエラー型を作る」の記事で扱った「pub enum *Error には #[non_exhaustive] を付ける」も、 rowan で書けます。syu-m-5151.hatenablog.comuse ra_ap_syntax::ast::{self, AstNode, HasAttrs, HasName, HasVisibility};pub fn check_non_exhaustive_error(file: &ast::SourceFile) -> Vec<Diagnostic> { let mut diags = Vec::new(); for node in file.syntax().descendants() { let Some(en) = ast::Enum::cast(node) else { continue }; if en.visibility().is_none() { continue; // 非公開はスキップ } let Some(name) = en.name() else { continue }; let name_text = name.text().to_string(); if !name_text.ends_with("Error") { continue; // ヒューリスティックで Error 系のみ } let already_marked = en.attrs().any(|a| { a.path() .map(|p| p.syntax().text().to_string() == "non_exhaustive") .unwrap_or(false) }); if already_marked { continue; } let range = en.syntax().text_range(); diags.push(Diagnostic { message: format!( "`pub enum {name_text}` should be `#[non_exhaustive]` to keep SemVer flexibility" ), start: range.start().into(), end: range.end().into(), }); } diags}clippy にはこのチェックは入っていません。チームのドメイン規約は、 rowan で書いて CI に乗せる のが現実解です。 lint がコードベースに固有なら、 clippy ではなく自家製で持つほうが運用が楽になります。動かす — cargo run -- src/lib.rsCLI に組むのも数行です。fn main() { let path = std::env::args().nth(1).expect("usage: lint <file>"); let src = std::fs::read_to_string(&path).expect("read"); let parse = ra_ap_syntax::SourceFile::parse(&src, ra_ap_syntax::Edition::Edition2021); let tree = parse.tree(); let mut diags = UnwrapLint.check(&tree); diags.extend(check_non_exhaustive_error(&tree)); for d in &diags { println!("{}-{}: {}", d.start, d.end, d.message); } std::process::exit(if diags.is_empty() { 0 } else { 1 });}これで cargo run -- src/lib.rs するだけ。 walkdir でディレクトリを再帰すれば、 prj 全体の検査ツールになります。CI に組み込む — build.rs / xtask / pre-commitCLI で手動実行できても、 誰かが忘れた瞬間にコードベースに違反が混ざります。 lint を機械的に走らせる仕組みは別途用意します。 候補は 4 つ。1. build.rs で cargo build 時に走らせる利用側 crate の build.rs から自家製 lint をライブラリとして呼びます。 違反があれば panic! で cargo build を止めます。# 利用側 Cargo.toml[build-dependencies]my-lint = { path = "../tools/my-lint" }walkdir = "2"// build.rsuse std::path::Path;fn main() { let src = Path::new("src"); println!("cargo:rerun-if-changed=src"); let mut errors = 0; for entry in walkdir::WalkDir::new(src) { let entry = entry.expect("walkdir"); if entry.path().extension().is_some_and(|e| e == "rs") { println!("cargo:rerun-if-changed={}", entry.path().display()); for d in my_lint::lint_file(entry.path()).expect("lint") { println!( "cargo:warning={}:{}: [{}] {}", d.file.display(), d.line, d.rule, d.message ); if matches!(d.severity, my_lint::Severity::Error) { errors += 1; } } } } if errors > 0 { panic!("custom lint: {errors} error-level diagnostic(s); fix them to build"); }}cargo:warning=... は cargo が黄色い警告として表示してくれる行。 panic! を呼ばないと cargo は止まらないので、致命と非致命の境界は自分で決めます。向いている: 「絶対に違反したまま動かしたくない」 lint。 cargo build / check / test 全てで強制される。向いていない: 開発中に何度も cargo check を回すワークフロー。 build script の incremental は rerun-if-changed でしか効かないので、 src/ を再帰させるとファイル追加のたびに走ります。 rust-analyzer のリアルタイム保存ループに lint まで含めると、エディタ側が遅くなる可能性も。2. xtask で cargo xtask lint を作るRust 慣習の xtask パターンは、 workspace に xtask/ バイナリを切って cargo xtask <command> で開発系のタスクを走らせる方式です。 build.rs と違い cargo build には乗らないので、開発の重さに影響しません。# workspace ルートの .cargo/config.toml[alias]xtask = "run --package xtask --"// xtask/src/main.rsfn main() { let cmd = std::env::args().nth(1).unwrap_or_default(); match cmd.as_str() { "lint" => run_lint(), _ => eprintln!("usage: cargo xtask lint"), }}fn run_lint() { // ここで my_lint::lint_file を全 .rs に対して呼ぶ}向いている: 普段は cargo check を軽く回しつつ、 commit 前 / CI で cargo xtask lint を呼ぶ運用。 rust-analyzer / rustfmt / clippy も含めた dev タスクの集約場所として使える。3. pre-commit hookpre-commit や .git/hooks/pre-commit で commit 前に走らせます。# .pre-commit-config.yaml- repo: local hooks: - id: my-lint name: my custom rowan lint entry: cargo run --quiet --release --bin my-lint -- language: system files: \.rs$向いている: ローカル開発で違反コードを commit させない ガード。 CI に出る前の最後の壁。4. CI stepGitHub Actions / GitLab CI で cargo run --bin my-lint -- src/ を 1 ステップ足すだけ。- name: rowan lint run: cargo run --release --bin my-lint -- src/向いている: 公的に強制したい lint。 PR ごとに必ず走る。どれを選ぶか実務での手堅い組み合わせは xtask + CI step。 普段 cargo check は軽いままにしつつ、commit 前後で必ず走るルートを 2 本確保します。 「絶対に違反 commit を許さない」なら + pre-commit hook。 build.rs は IDE のリアルタイムループに lint を混ぜたい強い理由があるとき以外は避けるのが無難。シリーズ末尾でよく書いてきた Cargo.toml の clippy 設定:[lints.clippy]unwrap_used = "deny"manual_let_else = "warn"これと 同じ強制力を、自家製 lint にも持たせる のがこの節の狙いです。いつ rowan を選ぶかrowan が向いている場面と、それ以外で済む場面の境界は明確です。 やりたいこと 第一候補 cargo check 相当の型検査 rustc / rust-analyzer (自分で書かない) 一般的な書き方の修正 clippy マクロでコード生成 syn コードベース固有の規約を CI で機械的に弾く rowan (ra_ap_syntax) コメント・空白を保ったままの書き換え rowan (フォーマッタ系) 自分の DSL のパーサーを書く rowan + 自前 grammar shitamono の grammar 工事までやるのはコストが大きいので、 Rust に対する lint なら ra_ap_syntax 経由で rowan を使う が実務的です。注意点ra_ap_syntax のバージョン: rust-analyzer の内部に追従して頻繁に上がります。0.0.x 表記で minor が動くと API が変わるので、 lint プロジェクトでは Cargo.lock をコミットして固定します。Edition: SourceFile::parse(src, Edition::Edition2021) のように edition を渡します。Edition で grammar が一部変わる (let chain など) ので、 2024 のコードを 2021 でパースすると一部 syntax error になります。検査対象のクレートに合わせて選びます。型情報がないこと: rowan は構文木のみ。 「.clone() の receiver が本当に Arc<T> か」のような 型情報 は判定できません。型情報まで欲しいときは rust-analyzer 内部の HIR を借りるか、別の手段 (rustc_driver プラグインなど) になります。 syntactic でも書ける lint は意外に多いので、まずは rowan で書ける範囲を試すのが速いです。まとめrowan は rust-analyzer の心臓部にある ロスレスな構文木ライブラリsyn と違い、 空白・コメント保持 と resilient parsing ができるRust の grammar は ra_ap_syntax 経由で借りられるドメイン規約 (unwrap 禁止、#[non_exhaustive] 強制、newtype 推奨、lazy_static! 撤去など、シリーズで紹介してきたもの) は、 rowan で書いて CI に乗せると壊れないclippy で済むなら clippy、コードベース固有なら rowan、と使い分けるシリーズで言葉にしてきた「こう書こう」を、 コンパイラに守らせる ところまで連れて行く道具が rowan です。手元の tools/rbp-lint もこの上で書いています。

`rowan` で自家製 lint を書く — rust-analyzer の心臓部を流用する

31歳、もちろん俺らは抵抗するで？筋肉で

はじめにBuilder パターンで「url を設定する前に build() を呼んでしまった」事故を、 コンパイルエラーで止める 書き方があります。type-state pattern と呼ばれています。PhantomData を使って builder の進捗状態を型に乗せる、 Rust 固有の idiom です。ランタイムオーバーヘッドはゼロ。PhantomData<T> はサイズ 0 で、コンパイル時にしか存在しません。まず動くコードuse std::marker::PhantomData;#[derive(Debug)]pub struct Missing;#[derive(Debug)]pub struct Set;#[derive(Debug)]pub struct Request { pub url: String, pub body: String,}#[derive(Debug, Default)]#[must_use = "Builder は最後に build() を呼んで Request を取り出す"]pub struct RequestBuilder<UrlState, BodyState> { url: Option<String>, body: Option<String>, _state: PhantomData<(UrlState, BodyState)>,}impl RequestBuilder<Missing, Missing> { pub const fn new() -> Self { Self { url: None, body: None, _state: PhantomData, } }}impl RequestBuilder<Missing, B> { pub fn url(self, url: impl Into<String>) -> RequestBuilder<Set, B> { RequestBuilder { url: Some(url.into()), body: self.body, _state: PhantomData, } }}impl RequestBuilder<U, Missing> { pub fn body(self, body: impl Into<String>) -> RequestBuilder<U, Set> { RequestBuilder { url: self.url, body: Some(body.into()), _state: PhantomData, } }}impl RequestBuilder<Set, Set> { pub fn build(self) -> Request { Request { url: self.url.expect("type-state guarantees url is Some"), body: self.body.expect("type-state guarantees body is Some"), } }}fn main() { let req = RequestBuilder::new() .url("https://example.com") .body("payload") .build(); println!("{req:?}");}cargo run するとこう出ます。Request { url: "https://example.com", body: "payload" }注目すべきは、最後の build() を呼べるのが RequestBuilder<Set, Set> の場合だけ ということです。なぜコンパイルエラーで止まるのか以下のように url を呼ばずに build() するコードを書くと、コンパイルエラーになります。// ↓ これはコンパイルが通らないlet req = RequestBuilder::new().build();エラーはこうなります。error[E0599]: no method named `build` found for struct `RequestBuilder<Missing, Missing>` in the current scope | | let req = RequestBuilder::new().build(); | ^^^^^ method not found |note: the method `build` is implemented on `RequestBuilder<Set, Set>`build() は RequestBuilder<Set, Set> にしか実装されていないので、Missing 状態の builder からは呼べません。実行する前にコンパイラが弾きます。どう動いているか仕組みは3層です。状態を表す型を定義する: Missing と Set という空の structbuilder にこれらの型を generic で持たせる: RequestBuilder<UrlState, BodyState>メソッドが状態を変える: url() は Missing → Set に状態を進めるurl() の戻り値が RequestBuilder<Set, B> になっているので、呼び出すたびに型が変わります。連鎖呼び出しの形を見ます。RequestBuilder<Missing, Missing> ← new() .url(...) →RequestBuilder<Set, Missing> .body(...) →RequestBuilder<Set, Set> .build()最後の Set, Set でだけ build() が呼べる。 これがコンパイル時の「未設定検出」です。PhantomData の役割_state: PhantomData<(UrlState, BodyState)> は、generic パラメータ2つを struct で「使っている」ことにするためのフィールドです。Rust は generic パラメータを実際に使っていないと「unused type parameter」と怒ります。PhantomData<T> はサイズ 0、ランタイムには何も持ちませんが、型システム上は T を使っていることになります。これで generic パラメータが struct に「乗ります」。PhantomData<(UrlState, BodyState)> のようにタプルにすると、複数の型パラメータをまとめて持てます。どの順で呼ばれてもよい上のコードは url → body の順でも body → url の順でも動きます。それぞれの状態に対して個別に impl ブロックを書いているからです。// どちらでも OKRequestBuilder::new().url("u").body("b").build();RequestBuilder::new().body("b").url("u").build();// 同じメソッドを2回呼ぼうとすると型エラー// .url(...).url(...) ← Set 状態には url() の impl が無い「同じメソッドを二度呼ぶのを防ぐ」もコンパイル時に保証されます。デフォルト値を許す場合「body は省略可能で、省略時は空文字」みたいな仕様を入れたい場合、default を持つ Set 風の状態を別途用意します。impl RequestBuilder<U, Missing> { /// body は明示的に省略する場合、`Set` 状態に進める。 pub fn no_body(self) -> RequestBuilder<U, Set> { RequestBuilder { url: self.url, body: Some(String::new()), _state: PhantomData, } }}build() の前に body() か no_body() のどちらかを必ず呼ぶ必要がある、という設計になります。制限と代替案type-state builder には欠点もあります。コードが長い: 単純な builder より3〜4倍ぐらいに増えるジェネリックパラメータが増える: 状態を3〜4個持つと RequestBuilder<S1, S2, S3, S4> の形になり、エラーメッセージも長くなる動的に builder を持ち回せない: 状態を型に乗せるので、 Vec<RequestBuilder<...>> に詰めるのは現実的でないこれらが嫌な場合の代替を挙げます。必須フィールドはコンストラクタ引数で受ける: Request::new(url) のあとで .with_body(...) で optional を設定する。これでも url 未設定は防げるランタイム validation: build() で Result<Request, BuildError> を返す。テストで担保するderive_builder クレート: マクロで builder を自動生成する。type-state までは行かないが書く量は減る「絶対に未設定で build() させたくない」公開 API、特に外部開発者が触る SDK では type-state を使う価値があります。内部でしか使わない builder なら、ランタイム validation で十分なこともあります。#[must_use] を忘れずにbuilder には #[must_use = "理由"] を付けると、捨てたときに警告が出ます。#[must_use = "Builder は最後に build() を呼んで Request を取り出す"]pub struct RequestBuilder<UrlState, BodyState> { ... }「builder を作ったまま使わない」コードに気付ける小技です。まとめtype-state pattern は PhantomData<T> で builder の進捗状態を型に乗せるMissing / Set のような空 struct を使い、メソッド呼び出しで状態を遷移させるbuild() は完成状態 (Set, Set) でしか呼べないので、未設定の時はコンパイルエラーランタイムオーバーヘッドはゼロ短所は記述量。オープンな SDK 向きで、内部 builder には過剰な場合もある関連std::marker::PhantomData: https://doc.rust-lang.org/std/marker/struct.PhantomData.htmltype-state pattern について: https://cliffle.com/blog/rust-typestate/

コンパイル時に未設定フィールドを禁止する type-state builder

はじめに「String に独自メソッドを追加したい」「外部クレートの型に1メソッドだけ生やしたい」場面があります。Rust の orphan rule のせいで、外部クレートの型に外部クレートのトレイトを直接実装するのは無理です。代わりに 自分のトレイトを定義して、その型に対する impl を書く のが extension trait パターンです。doc.rust-lang.orgさらに sealed trait pattern を組み合わせると、「このトレイトは外部から実装できない」ことを保証できます。公開 API の進化を破壊的変更にしないための小技です。まず動くコードString や &str に「指定文字数で切り詰めて末尾に … を付ける」メソッドを生やす例。mod sealed { pub trait Sealed {}}pub trait StrExt: sealed::Sealed { fn truncate_with_ellipsis(&self, max_chars: usize) -> String;}// 全ての &str / String / Cow<str> 等に対して一気に sealed トレイトを実装するimpl<T: AsRef<str>> sealed::Sealed for T {}// 同じ blanket で extension trait の本体も実装impl<T: AsRef<str>> StrExt for T { fn truncate_with_ellipsis(&self, max_chars: usize) -> String { let s = self.as_ref(); if max_chars == 0 { return String::new(); } let count = s.chars().count(); if count <= max_chars { return s.to_owned(); } let mut out: String = s.chars().take(max_chars - 1).collect(); out.push('…'); out }}fn main() { let title = "rust 2024 edition で書く idiomatic な話"; println!("{}", title.truncate_with_ellipsis(10)); let owned = String::from("hello world"); println!("{}", owned.truncate_with_ellipsis(20));}実行結果は次のようになります。rust 2024…hello worldString でも &str でも、自分が定義したわけではない型に .truncate_with_ellipsis(...) というメソッドが生えました。extension trait の構造extension trait のレシピは3ステップです。公開トレイトを定義する: pub trait StrExt { fn ...; }対象の型に impl する: 単一の型 (impl StrExt for String) でも、blanket impl (impl<T: AsRef<str>> StrExt for T) でも利用側で use する: use crate::StrExt; を書くと型にメソッドが現れる利用側はこう使います。use my_crate::StrExt;fn main() { let s = "hello"; println!("{}", s.truncate_with_ellipsis(3));}メソッド名前空間が trait に紐付くので、use を書かないとメソッドが見えません。これが意図しない名前衝突を防ぐ仕組みです。blanket impl で対象を広げるimpl<T: AsRef<str>> StrExt for T のように generic で書くと、 AsRef<str> を実装する すべての型 が StrExt を持ちます。これに含まれるのは次のとおりです。&str (固定)String (AsRef<str> を実装)Box<str>Cow<'_, str>自作の newtype (pub struct Title(String) で AsRef<str> を実装すれば自動)利用者は意識せずに extension trait の恩恵を受けられます。sealed trait pattern とはextension trait の問題点として、 外部の利用者が自分の型に impl を書ける ことがあります。これは普通良いことなのですが、ときに困ります。たとえば次のような場面です。「このトレイトは将来メソッドを追加する予定」: 利用者が impl していると追加が破壊的変更になる「内部実装の詳細を漏らしたくない」: 利用者の impl で意図しない使われ方をされるsealed trait pattern を使うと、 そのクレート外からはトレイトを impl できない ようにできます。仕組みは「private モジュールに Sealed トレイトを置いて、自分のトレイトの super trait にする」というものです。mod sealed { // pub だが、parent module 経由でしか参照できない private モジュールにある pub trait Sealed {}}pub trait StrExt: sealed::Sealed { // sealed::Sealed が super trait fn truncate_with_ellipsis(&self, max_chars: usize) -> String;}// 自分のクレート内でだけ Sealed を impl できるimpl<T: AsRef<str>> sealed::Sealed for T {}impl<T: AsRef<str>> StrExt for T { ... }外部の利用者は sealed::Sealed にアクセスできません。モジュール sealed を pub にしていないので外から見えないからです。そのため StrExt を impl しようとしても super trait Sealed が満たせません。これにより、次の2つが得られます。メソッド追加が破壊的変更にならない (利用者は impl していないので)自分のクレートだけが「StrExt を実装する型を増やす」権限を持つ公開クレートで extension trait を出すなら、sealed にしておくのが基本姿勢です。いつ extension trait を使うか判断目安を表にしておきます。 使うべき 使わないべき 標準ライブラリ型に1〜2メソッド足す 自前の型に普通のメソッドを足す (素直に impl で OK) 外部クレートの型に独自処理を生やす 全く同じ機能のフリー関数で済む 利用者が use を書いて opt-in する設計 コア機能で常に有効にしたい 「フリー関数 (fn truncate_with_ellipsis(s: &str, ...)) で済まないだろうか」を一度自問するのが良いです。s.truncate(...) のメソッド呼び出しスタイルが UX として明確に勝る場面でだけ extension trait の価値があります。orphan rule との関係ここで「なぜ extension trait が必要か」を一度整理します。Rust の orphan rule は「トレイト or 型のどちらかが自分のクレートに属していなければ impl を書けない」というルールです。これにより次のような制約が生まれます。impl Display for MyType (自分の型) → OKimpl MyTrait for String (自分のトレイト) → OKimpl Display for String (どちらも他人) → コンパイルエラー「外部の String に外部の Serialize を impl する」みたいなことはできません。これは依存関係グラフが入り組んだときの impl 衝突を防ぐための設計です。extension trait は「自分のトレイトを定義して、それを外部の型に impl する」ことで、 orphan rule の制約内で「外部の型に機能を足す」を実現するパターンです。まとめextension trait は「外部の型に自分の機能を足す」 ためのトレイトレシピ: トレイト定義 → 対象型に impl → 利用側で useblanket impl で String / &str / Cow などに一括展開できるsealed pattern で「外部クレートからは impl できない」を保証できる公開クレートの extension trait は基本 sealed にする「フリー関数で済むだろうか」を自問してから extension trait を選ぶ関連Rust API Guidelines / sealed trait: https://rust-lang.github.io/api-guidelines/future-proofing.htmlorphan rule: https://doc.rust-lang.org/reference/items/implementations.html#trait-implementation-coherence

自分のクレート外の型にメソッドを生やす — extension trait と sealed pattern

はじめにRust で「グローバル変数を遅延初期化したい」となったとき、長らく lazy_static! クレートが定番でした。今 (2026年) はもう不要です。標準ライブラリの LazyLock (1.80+) と OnceLock (1.70+) で全部書けます。マクロや外部依存も要りません。ただし MSRV (最小サポート Rust バージョン) を 1.80 未満で固定しているプロジェクトは、当面 lazy_static! のままでよいです。本記事は新規プロジェクトと、MSRV を引き上げる余地のあるコードベースを対象にしています。両者は似ていますが用途が違います。この記事ではどっちを使えばよいかを、実例つきで整理します。lazy_static! で書いていたコードこれまで lazy_static! で書いていた典型的なコードを置きます。// 古いコード (lazy_static = "1")use lazy_static::lazy_static;use regex::Regex;use std::collections::HashMap;lazy_static! { static ref EMAIL_REGEX: Regex = Regex::new(r"^[\w.+-]+@[\w.-]+\.[\w-]+$").unwrap(); static ref DEFAULT_HEADERS: HashMap<&'static str, &'static str> = { let mut m = HashMap::new(); m.insert("Content-Type", "application/json"); m.insert("X-Version", "1"); m };}fn is_email(s: &str) -> bool { EMAIL_REGEX.is_match(s)}これはこれで動きますが、 lazy_static! クレートを依存に入れる必要があり、マクロ独自の構文を覚える必要があります。LazyLock で同じことを書くLazyLock<T> は std にある「初回アクセス時にクロージャを実行して T を生成し、以降はキャッシュする」型です。スレッド安全で、Sync です。use std::collections::HashMap;use std::sync::LazyLock;use regex::Regex;static EMAIL_REGEX: LazyLock<Regex> = LazyLock::new(|| { Regex::new(r"^[\w.+-]+@[\w.-]+\.[\w-]+$").expect("invalid regex literal")});static DEFAULT_HEADERS: LazyLock<HashMap<&'static str, &'static str>> = LazyLock::new(|| { HashMap::from([ ("Content-Type", "application/json"), ("X-Version", "1"), ])});fn is_email(s: &str) -> bool { EMAIL_REGEX.is_match(s)}差分は地味ですが、次のような違いがあります。lazy_static! マクロ不要 (std だけ)static キーワードに加えて型が見える (LazyLock<Regex>)初期化クロージャが普通の Rust 構文特に 「型が static シグネチャに見える」 のが嬉しいポイントです。lazy_static! だと初期化式から型を推測する必要がありました。LazyLock から値を取り出すときは Deref 経由で透過的にアクセスできます。EMAIL_REGEX.is_match(...) のような呼び出しがそのまま書けます。明示的に取り出したいときは &*EMAIL_REGEX か LazyLock::force(&EMAIL_REGEX) でも取得できます。OnceLock は何が違うかOnceLock<T> も似ていますが、初期化のタイミングが違います。LazyLock<T>: 宣言時にクロージャを与える。初回アクセスで実行される。OnceLock<T>: 宣言時には空っぽ。外から set() で1回だけ値を入れる。つまり「初期化ロジックを宣言と一緒に書ける」なら LazyLock、「動的に値を流し込みたい」なら OnceLock です。OnceLock の典型的な例: アプリ起動時にコマンドライン引数や環境変数から構築した設定を、グローバルとして保持する。use std::sync::OnceLock;#[derive(Debug)]pub struct Config { pub api_key: String, pub max_retries: u32,}static CONFIG: OnceLock<Config> = OnceLock::new();pub fn install_config(c: Config) -> Result<(), Config> { CONFIG.set(c) // 2回目の set は Err を返す}pub fn config() -> &'static Config { CONFIG.get().expect("CONFIG not initialized")}fn main() { let _ = install_config(Config { api_key: std::env::var("API_KEY").unwrap_or_default(), max_retries: 3, }); println!("max_retries = {}", config().max_retries);}install_config を main の冒頭で1回呼ぶ。あとは config() でアクセスする。使い分けの判定フロー迷ったら3問の判断フローです。値が コンパイル時に決まっている だろうかはい → const か staticいいえ → 次へ初期化に 副作用や外部入力 が必要だろうかはい → OnceLock (set を呼ぶ)いいえ → LazyLock (クロージャを宣言時に書く)例を挙げます。正規表現リテラル → LazyLock (Regex::new はパースだけで副作用なし)HashMap で固定キーバリュー → LazyLockアプリ起動時に CLI 引数を保持 → OnceLockDB コネクションプールへのハンドル → OnceLock (起動時に接続)デフォルト値とのフォールバックOnceLock で「set されていなければデフォルトを返す」を書きたいなら LazyLock と組み合わせます。use std::sync::{LazyLock, OnceLock};#[derive(Debug)]pub struct Config { pub greeting: String,}static DEFAULT_CONFIG: LazyLock<Config> = LazyLock::new(|| Config { greeting: "hello".into(),});static RUNTIME_CONFIG: OnceLock<Config> = OnceLock::new();pub fn current() -> &'static Config { RUNTIME_CONFIG.get().unwrap_or(&DEFAULT_CONFIG)}fn main() { println!("before: {}", current().greeting); let _ = RUNTIME_CONFIG.set(Config { greeting: "yo".into() }); println!("after: {}", current().greeting);}実行結果は次のようになります。before: helloafter: yoRUNTIME_CONFIG が空のあいだは DEFAULT_CONFIG を返し、set されたら以降そちらを返す、というパターン。設定の上書き機構を std だけで書けます。マルチスレッド安全性両方とも Sync を満たすので、スレッド間で共有できます。LazyLock: 初期化クロージャは複数スレッドが同時にアクセスしても1回だけ実行される (内部で同期される)OnceLock: set() と get() の両方がスレッド安全。set() の成功は1回だけ並行 set() 競合が気になる時は OnceLock::get_or_init(|| ...) が使えます。 LazyLock 風に「未設定なら初期化」を atomic に行います。use std::sync::OnceLock;static SLOT: OnceLock<u32> = OnceLock::new();fn main() { let v = SLOT.get_or_init(|| { println!("computing..."); 42 }); println!("v = {v}"); // 2回目: 計算しない let v2 = SLOT.get_or_init(|| { println!("would compute again"); 99 }); println!("v2 = {v2}");}実行結果は次のとおりです。computing...v = 42v2 = 422回目の get_or_init ではクロージャは実行されません。まとめlazy_static! クレートはもう不要かも⋯。std の LazyLock<T> / OnceLock<T> で書けるLazyLock: 宣言時にクロージャで初期化方法を決める。動的な入力が要らない場合OnceLock: 外から set() で1回だけ値を入れる。アプリ起動時の動的設定など両方ともスレッド安全フォールバックパターンは OnceLock + LazyLock の組み合わせで書ける依存を1つ減らせるのは地味ですが、新規プロジェクトでは何の理由もなく lazy_static! を持ち込まないでください。関連std::sync::LazyLock: https://doc.rust-lang.org/std/sync/struct.LazyLock.htmlstd::sync::OnceLock: https://doc.rust-lang.org/std/sync/struct.OnceLock.html

`lazy_static!` はもういらない — `LazyLock` と `OnceLock` の使い分け

はじめに入力をそのまま返すか、一部書き換えてから返すか、関数の中で判定する場面があります。素直に書くと「変更しない場合も無駄に String::clone() してしまう」、または「&str を返したいが、変更があった時は所有データを返したい」というジレンマに陥ります。std::borrow::Cow<'_, T> (Clone-On-Write) はこのジレンマを解きます。借用 (Borrowed) と所有 (Owned) のどちらかを選んで返せる enum で、「必要になるまで allocate しない」が型で表現できます。doc.rust-lang.orgまず動くコード「すでに全部大文字ならそのまま借用を返し、小文字を含む場合だけ大文字化した所有データを返す」関数。use std::borrow::Cow;fn ensure_uppercase(input: &str) -> Cow<'_, str> { if input.chars().all(|c| !c.is_lowercase()) { Cow::Borrowed(input) // 変更不要 → 借用のまま返す } else { Cow::Owned(input.to_uppercase()) // 変更必要 → 所有データを作って返す }}fn main() { let a = ensure_uppercase("HELLO"); let b = ensure_uppercase("hello"); println!("a = {a}, borrowed? {}", matches!(a, Cow::Borrowed(_))); println!("b = {b}, borrowed? {}", matches!(b, Cow::Borrowed(_)));}実行結果は次のようになります。a = HELLO, borrowed? trueb = HELLO, borrowed? falsea は元の "HELLO" をそのまま借りています (allocate なし)。b は "hello" を大文字化した新しい String を持っています (allocate あり)。同じ "HELLO" という文字列でも、片方は借用、片方は所有。Cow がこの違いを型ひとつで表現できるのがポイントです。Cow の中身Cow の定義はこうです (簡略化)。pub enum Cow<'a, B: ?Sized + ToOwned + 'a> { Borrowed(&'a B), Owned(::Owned),}B は借用形態 (str, [T], ...) 、::Owned がそれを所有する型 (String, Vec<T>) です。Cow<'a, str> なら Borrowed(&'a str) または Owned(String)。利用者は Cow を Deref 経由で透過的に扱えます。&str が必要なメソッドはそのまま呼べます。let s = ensure_uppercase("Hello");println!("len = {}", s.len()); // どちらの variant でも動くprintln!("upper = {}", s.to_uppercase()); // どちらでも動く「allocate されているかどうか」を呼び出し側が気にする必要はありません。to_mut で「必要になったら所有に切り替える」Cow::to_mut(&mut self) を呼ぶと、Borrowed 状態だった場合だけ所有データに切り替えて、&mut Owned を返します。use std::borrow::Cow;fn append_exclamation(input: &str) -> Cow<'_, str> { if input.ends_with('!') { Cow::Borrowed(input) } else { let mut owned = Cow::Owned(input.to_owned()); owned.to_mut().push('!'); owned }}fn main() { println!("{}", append_exclamation("hi")); // hi! println!("{}", append_exclamation("yo!")); // yo!}これは「すでに所有しているなら borrow から脱出して直接書き換える」のではなく、「Borrowed の場合だけ所有版へ変換し書き換え可能にする」という挙動です。関数の戻り値型として使うCow の真価は 戻り値型 で出ます。「入力をそのまま返したい場合もあれば、変更を加えた所有版を返したい場合もある」関数。use std::borrow::Cow;fn resolve_greeting<'a>(default: &'a str, override_with: Option<&str>) -> Cow<'a, str> { override_with.map_or(Cow::Borrowed(default), |s| Cow::Owned(s.to_owned()))}fn main() { let g1 = resolve_greeting("hi", None); let g2 = resolve_greeting("hi", Some("yo")); println!("g1 = {g1}, borrowed? {}", matches!(g1, Cow::Borrowed(_))); println!("g2 = {g2}, borrowed? {}", matches!(g2, Cow::Borrowed(_)));}設定に上書きが指定されていなければ default をそのまま借用、指定されていれば所有データを作る。「上書きされなかった99%のケースで allocate が起きない」 設計が可能になります。いつ Cow を使うか入力データの大半をそのまま使いたいが、まれに変更が必要 な場面で効きます。具体例を挙げます。HTML エスケープ: 危険文字を含まなければ借用のまま、含めばエスケープ後の所有データを返すパスの正規化: すでに正規化されているならそのまま、必要なら正規化後を返す設定の上書き: 上書きされていなければ default を借用、上書きされたら所有テンプレート展開: プレースホルダがなければ借用、あれば展開後の所有データを返す逆に「常に変更する」ような関数では、最初から String を返すほうが素直です。Cow は 「変更しないことが多数派」 な場面で意味があります。Cow<'_, [T]> も同じ仕組みCow は文字列以外でも使えます。Cow<'_, [T]> で「Vec の借用 / 所有」を切り替えられます。use std::borrow::Cow;fn ensure_sorted(input: &[i32]) -> Cow<'_, [i32]> { if input.windows(2).all(|w| w[0] <= w[1]) { Cow::Borrowed(input) } else { let mut owned = input.to_owned(); owned.sort_unstable(); Cow::Owned(owned) }}fn main() { let a = ensure_sorted(&[1, 2, 3]); let b = ensure_sorted(&[3, 1, 2]); println!("{a:?}, borrowed? {}", matches!(a, Cow::Borrowed(_))); println!("{b:?}, borrowed? {}", matches!(b, Cow::Borrowed(_)));}すでに昇順なら借用のまま、そうでなければソートして所有版を返す。まとめCow<'_, T> は Borrowed(&T) と Owned(<T as ToOwned>::Owned) の enum「変更が必要なときだけ allocate する」を型で表現できる戻り値型として使うと「変更しないことが多数派」な関数で allocate を回避できるto_mut() で必要になったタイミングで所有版に切り替えられる&str / &[T] どちらでも同じ仕組みCow を使うべきか迷ったら、 「この関数の戻り値、入力をそのまま返したいケースが半分以上あるだろうか」を考えてみてください。Yes なら Cow の出番です。関連std::borrow::Cow: https://doc.rust-lang.org/std/borrow/enum.Cow.htmlstd::borrow::ToOwned: https://doc.rust-lang.org/std/borrow/trait.ToOwned.html

`Cow<'_, T>` で「変更が必要なときだけ allocate する」

はじめにUserId と OrderId を取り違えてバグを生み出す経験は、String で識別子を扱っていれば誰しもあります。Rust では newtype で別の型に分けるだけで、コンパイラに止めてもらえます。さらに PhantomData を組み合わせれば、「JPY と USD を足し算する」のような単位ミスも型エラーにできます。ランタイムコストはゼロ。型情報はコンパイル後に消えます。newtype の基本newtype は「struct でラップして、別の型として扱う」だけのパターンです。#[derive(Debug, Clone, PartialEq, Eq, Hash)]pub struct UserId(String);#[derive(Debug, Clone, PartialEq, Eq, Hash)]pub struct OrderId(String);impl UserId { pub fn new(s: impl Into<String>) -> Self { Self(s.into()) } pub fn as_str(&self) -> &str { &self.0 }}impl OrderId { pub fn new(s: impl Into<String>) -> Self { Self(s.into()) }}fn lookup_user(id: &UserId) -> String { format!("looking up {}", id.as_str())}fn main() { let u = UserId::new("alice"); let o = OrderId::new("o-1"); println!("{}", lookup_user(&u)); // lookup_user(&o); // ← compile error: 期待型は &UserId, 実際は &OrderId println!("{:?}", o);}UserId の内部表現は String で、OrderId の内部表現も String ですが、型システム上は別物です。lookup_user(&o) を書くと型エラーになります。ergonomics を上げるnewtype はそのままだと使い勝手が悪い (every cast が手書きになる) ので、よく使う変換を From / AsRef / Display で実装します。use std::fmt;#[derive(Debug, Clone, PartialEq, Eq, Hash)]pub struct UserId(String);impl UserId { pub fn new(s: impl Into<String>) -> Self { Self(s.into()) }}// `let id: UserId = "alice".into();` で書けるimpl From<&str> for UserId { fn from(s: &str) -> Self { Self(s.to_owned()) }}// `id.as_ref()` で `&str` を取れるimpl AsRef<str> for UserId { fn as_ref(&self) -> &str { &self.0 }}// 表示は `Debug` と分けて意図的にカスタマイズimpl fmt::Display for UserId { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { write!(f, "user:{}", self.0) }}fn main() { let id: UserId = "alice".into(); println!("{id}"); // user:alice println!("{id:?}"); // UserId("alice")}Display と Debug を分けるのがポイント。Debug は開発者向けの構造表示、Display はユーザー向けの整形です。derive_more で boilerplate を削るFrom / AsRef / Display を毎回手書きしたくない場合、derive_more クレートが使えます。[dependencies]derive_more = { version = "2", features = ["as_ref", "display", "from"] }use derive_more::{AsRef, Display, From};#[derive(Debug, Clone, PartialEq, Eq, Hash, AsRef, Display, From)]#[display("user:{_0}")]pub struct UserId(String);これで From<String>, AsRef<String>, Display が自動生成されます。#[display("...")] 属性で書式を指定。手書きより短く済みます。「単位」を newtype で表すnewtype の真価は「数値に単位を付ける」場面で出ます。PhantomData<T> を使って、内部表現は同じ i64 だけど型レベルで通貨を分けるパターン。use std::marker::PhantomData;use std::ops::Add;#[derive(Debug, Clone, Copy)]pub struct Currency<C> { cents: i64, _tag: PhantomData<C>,}impl<C> Currency<C> { pub const fn new(cents: i64) -> Self { Self { cents, _tag: PhantomData } } pub const fn cents(self) -> i64 { self.cents }}impl<C> Add for Currency<C> { type Output = Self; fn add(self, rhs: Self) -> Self { Self::new(self.cents + rhs.cents) }}#[derive(Debug)]pub struct Jpy;#[derive(Debug)]pub struct Usd;fn main() { let a: Currency<Jpy> = Currency::new(1_000); let b: Currency<Jpy> = Currency::new(500); println!("JPY total = {}", (a + b).cents()); let _u: Currency<Usd> = Currency::new(100); // a + _u; // ← compile error: 通貨が違う}Currency<Jpy> と Currency<Usd> は別の型です。+ は同じ通貨同士でしか定義されていないので、混ぜようとするとコンパイルエラーになります。ランタイムにおける Currency<C> の実体は単なる i64 です (PhantomData<C> のサイズが 0 だから)。型情報はコンパイラだけが知っていて、生成されたバイナリには残りません。安全性を上げてもパフォーマンスは犠牲にならない のが Rust の強みです。いつ newtype を使うか過剰になるケースもあります。判断の目安を表にしておきます。 使う 使わない ID 系 (UserId, OrderId) 一時的な計算用の数値 単位がある値 (距離, 時間, 通貨) プレーンな整数の数え上げ 検証済みの文字列 (EmailAddress) 内部の中間表現 公開 API の引数・戻り値 関数内ローカル変数 「同じ String でも、文脈で意味が違う」場面で newtype が効きます。「同じ i64 を足し引きしているだけ」のローカル計算では、newtype を入れると逆に煩雑です。まとめnewtype = pub struct UserId(String); のラッパ取り違えバグを型エラーで止められるFrom / AsRef / Display を実装して ergonomics を上げるderive_more で boilerplate を削れるPhantomData<T> で「単位」を型に乗せられる (通貨, 距離, 時間)ランタイムコストはゼロ公開 API の ID は最初から newtype にしておくと、後で「どこで String を String に渡してミスっているか」を探すデバッグが要らなくなります。関連std::marker::PhantomData: https://doc.rust-lang.org/std/marker/struct.PhantomData.htmlderive_more クレート: https://docs.rs/derive_more/

newtype と `PhantomData` で「混ぜたら型エラー」を作る

おい、要件を動くものにしろ

はじめにゼロ割り、ゼロサイズ確保、ゼロインデックス。「ゼロでない数値」を期待する場面はあちこちにあります。これを runtime チェックではなく 型 で保証できる仕組みが NonZero<T> です。Rust 2024 edition で書き味がさらに素直になりました。これまでは NonZeroUsize, NonZeroU32 のように個別の型名を使っていました。それがジェネリック表記の NonZero<usize>, NonZero<u32> に統一されています。Rust 1.79 で NonZero<T> が安定化し、2024 edition では標準的な書き方になりました。まず動くコードページング計算で「ページサイズはゼロにできない」を型で保証する例。use std::num::NonZero;fn page_count(total_items: usize, page_size: NonZero<usize>) -> usize { total_items.div_ceil(page_size.get())}fn main() { let page_size = const { NonZero::new(50).expect("50 != 0") }; let pages = page_count(1003, page_size); println!("pages = {pages}");}実行結果は次のとおりです。pages = 21page_count の引数が NonZero<usize> なので、ゼロを渡すコードはそもそも書けません。NonZero::new(0) は None を返し、 0 から NonZero を構築する手段はありません。ゼロ割りは関数まで到達する前にコンパイラが弾きます。NonZero<T> の作り方NonZero<T> を作るには3パターンあります。use std::num::NonZero;// 1. リテラルから const block で構築 (推奨)let n1 = const { NonZero::new(50).expect("50 != 0") };// 2. 動的な値から作る (失敗するかもしれない)fn try_build(x: usize) -> Option<NonZero<usize>> { NonZero::new(x)}// 3. unsafe で「絶対ゼロでない」を契約として宣言let raw: usize = some_runtime_value();let n3 = unsafe { NonZero::new_unchecked(raw) }; // ゼロを渡したら UB通常は (1) か (2)。(3) の new_unchecked は契約違反すると Undefined Behavior なので、本当に必要な性能クリティカルな場面でだけ使います。(1) の const { ... } ブロックは Rust 1.79 で安定化しました。コンパイル時に panic しないことを保証する 構文です。NonZero::new(50) はコンパイル時に評価され、.expect(...) も const context で動くので、もし 0 を書いていたらコンパイルエラーになります。runtime panic にはなりません。ジェネリック表記のメリットこれまで個別の型名 (NonZeroUsize, NonZeroU32, ...) でも NonZero<T> でも同じ機能でしたが、ジェネリック表記のほうが2点で勝ります。コードの一貫性複数の整数型を扱うジェネリック関数で、 NonZero<T> のほうが自然に書けます。use std::num::NonZero;fn safe_div<T>(a: T, b: NonZero<T>) -> Twhere T: std::ops::Div<Output = T> + From<NonZero<T>> // 仮想的な制約。実際にはより複雑になる + Copy,{ a / T::from(b)}ジェネリックパラメータ T をそのまま NonZero<T> に持っていけます。 個別の型名 (NonZeroUsize / NonZeroU32) で書こうとすると、関数を整数型ごとに複製する羽目です。標準ライブラリの構造と一致Option<T>, Result<T, E>, Vec<T> のように、 標準ライブラリの type wrapper はジェネリックです。NonZero<T> も同じ形にしておくほうが頭の整理がつきます。「ゼロでない」以外のバリデーション型NonZero<T> は標準ライブラリだけが提供できる「組込み型に対する制約」です。同じ発想を自分の型に適用したいなら、 newtype でラップして smart constructor を書くのが定石です。#[derive(Debug, Clone, Copy)]pub struct PositiveAmount(u64);#[derive(Debug, thiserror::Error)]#[error("amount must be positive")]pub struct NotPositive;impl PositiveAmount { pub fn new(amount: u64) -> Result<Self, NotPositive> { if amount == 0 { Err(NotPositive) } else { Ok(Self(amount)) } } pub fn get(self) -> u64 { self.0 }}fn charge(account: &mut Account, amount: PositiveAmount) { account.balance += amount.get();}# struct Account { balance: u64 }「同じ u64 だけど、 PositiveAmount を経由しないと charge に渡せない」という制約を型で表現できます。これは NonZero<u64> とほぼ同じ発想ですが、自分のドメインに合わせた型を作れる柔軟性があります。いつ NonZero<T> を使うか「ゼロを許容しない」が引数のセマンティクスとして重要な場面で使います。代表例を挙げます。ページサイズ、バッチサイズ、ロット数配列のインデックス (1-based)アロケーションサイズスレッド数 / ワーカー数逆に「カウンタ」「累積値」のような「ゼロから始まる数値」では NonZero を使う場面ではありません。実用上の覚え方は 「もしこの値がゼロだったら関数の意味が壊れるか」 を考えることです。ゼロで意味が壊れる引数は NonZero<T>、ゼロでも意味のある引数は普通の整数。サイズ最適化地味なメリットですが、Option<NonZero<T>> は T と同じサイズです。None を 0 で表現する最適化が効きます。use std::num::NonZero;use std::mem::size_of;fn main() { println!("{}", size_of::<u32>()); // 4 println!("{}", size_of::<NonZero<u32>>()); // 4 println!("{}", size_of::<Option<u32>>()); // 8 (タグ + 値) println!("{}", size_of::<Option<NonZero<u32>>>()); // 4 (None = 0 で表現)}Option<NonZero<u32>> は Option<u32> より小さい。これは NonZero の値が 0 を取れないので、0 を使って None を表現できるためです。コレクションに大量に詰めるとメモリ効率に効きます。まとめNonZero<T> で「ゼロでない数値」を型で保証できるゼロを渡すコードは関数まで到達する前にコンパイラが弾く2024 edition の慣用句では NonZero<usize> のようなジェネリック表記を使うリテラルから作るときは const { NonZero::new(...).expect(...) } で runtime panic 回避自分のドメイン制約には newtype + smart constructor で同じ発想を適用できるOption<NonZero<T>> はサイズ最適化が効く引数のドキュメントに「page_size must be > 0」と書く代わりに、 NonZero<usize> で受ければそれが型で表現されます。書くドキュメントが減って、 runtime チェックも減って、 ミスも減ります。関連std::num::NonZero: https://doc.rust-lang.org/std/num/struct.NonZero.htmlRust 1.79 release notes (NonZero<T> 安定化): https://blog.rust-lang.org/2024/06/13/Rust-1.79.0/

`NonZero<T>` で「ゼロではない」を型に乗せる

はじめにRust で「ライブラリのエラー型をどう設計するか」は永遠のテーマです。素朴な答えは2つあります。アプリケーションなら anyhow で済ませるライブラリなら thiserror で型付きエラーを返すこれは2026年でも変わりません。この記事は「ライブラリ向け」のほうの設計を、 #[non_exhaustive] を組み合わせて SemVer 互換を壊さない形で書く方法を扱います。まず動くコードuse std::num::ParseIntError;#[derive(Debug, thiserror::Error)]#[non_exhaustive]pub enum LoadError { #[error("io: {0}")] Io(#[from] std::io::Error), #[error("parse: {0}")] Parse(#[from] ParseIntError), #[error("empty input")] Empty,}pub fn parse_first_number(text: &str) -> Result<i64, LoadError> { let line = text.lines().next().ok_or(LoadError::Empty)?; let n = line.trim().parse::<i64>()?; // ParseIntError → LoadError 自動変換 Ok(n)}fn main() -> Result<(), LoadError> { println!("{}", parse_first_number("42\nrest")?); println!("{:?}", parse_first_number("")); println!("{:?}", parse_first_number("not-a-number")); Ok(())}実行結果は次のとおりです。42Err(Empty)Err(Parse(ParseIntError { kind: InvalidDigit }))Cargo.toml に必要なものは1行だけです。[dependencies]thiserror = "2"thiserror 2.0 は 2024年末リリースで、Rust 2021/2024 両方で動きます。thiserror の役割thiserror::Error を #[derive] すると以下が自動で実装されます。std::error::Error (=Rust の標準エラートレイト)std::fmt::Display (#[error("...")] 属性で書式を指定)From<T> (#[from] 属性を付けたフィールドから自動変換)書く側は Debug を #[derive] して、各 variant に #[error("メッセージ")] を付けるだけ。#[derive(Debug, thiserror::Error)]pub enum MyError { #[error("bad request: {reason}")] BadRequest { reason: String },}{reason} のような placeholder には struct のフィールド名や、 タプル variant のインデックス ({0}, {1}) を使えます。#[from] でエラー変換を ? で連鎖させる#[from] は ? 演算子で自動変換するための From 実装 を生成します。これにより、内部エラーを呼び出し側に透過的に伝搬できます。#[derive(Debug, thiserror::Error)]pub enum LoadError { #[error("io: {0}")] Io(#[from] std::io::Error),}fn read() -> Result<String, LoadError> { let s = std::fs::read_to_string("config.toml")?; // io::Error → LoadError::Io Ok(s)}? を書くだけで std::io::Error が LoadError::Io(...) に変換されます。手書きの map_err は要りません。注意点があります。同じ型を #[from] 付きで複数の variant に置くことはできません。「io::Error を Io と Disk の両 variant に入れたい」ならどちらかは手書きの From 実装にします。#[non_exhaustive] で SemVer を守るここが重要です。公開ライブラリのエラー型に #[non_exhaustive] を付けると、利用者の match 文に _ ワイルドカード arm を強制できます。// あなたのライブラリ側#[derive(Debug, thiserror::Error)]#[non_exhaustive]pub enum LoadError { #[error("io: {0}")] Io(#[from] std::io::Error), #[error("empty input")] Empty,}利用者側の match はこうなります。// 利用者側match error { LoadError::Io(_) => println!("io error"), LoadError::Empty => println!("empty"), _ => println!("other"), // ← この `_` がないとコンパイルエラー}_ を強制することで、あなたのライブラリが 将来 variant を追加しても利用者のコードは壊れません。これが #[non_exhaustive] の最大のメリットです。新しい variant の追加は SemVer 上「破壊的変更」になりえますが、#[non_exhaustive] 付きなら minor バージョン (1.0 → 1.1) で追加できます。注意点を2つ挙げます。ライブラリ内部 (同じ crate 内) では _ を強制されない。crate 外からの match だけ制約されるstruct でも使える (新フィールド追加に強くなる)ライブラリ vs アプリの使い分けここで最初の二択に戻ります。 用途 選択 理由 公開ライブラリ thiserror で型付きエラー 利用者がエラー種別ごとにハンドリングできる アプリ (CLI, サーバー) anyhow で型消去 エラーを上位に投げて main で ? するだけで済む 内部 lib (同じ workspace 内) thiserror 推奨 後で公開する可能性 / テストでエラー種別を assert したい 「anyhow を使ったコードを公開ライブラリにする」のが一番こじれます。利用者は anyhow::Error を見せられても何もできません。最初から thiserror で型を切るほうが、後で楽になります。エラー設計のチェックリスト公開ライブラリのエラー enum を書くとき、以下を確認します。[ ] #[derive(Debug, thiserror::Error)] が付いている[ ] #[non_exhaustive] が付いている[ ] 各 variant に #[error("...")] で人間向けメッセージがある[ ] 内部から伝搬したいエラーに #[from] を付けている[ ] エラーメッセージに値が含まれる場合、placeholder で書式指定している[ ] Result<T, MyError> を返す関数のドキュメントに、どの variant がいつ発生するか書いてある最後の項目はドキュメント側ですが、利用者にとっては最も大事です。「Foo::do_it は MyError::Empty を返すことがあります」と書いておくと、利用者は match で網羅できます。まとめライブラリのエラー型は thiserror::Error を #[derive] する#[error("...")] で Display 出力を、#[from] で From 実装を自動生成#[non_exhaustive] を付けると、利用者の match に _ arm が強制され、 minor バージョンで variant を追加できるアプリ層は anyhow で型消去するのが楽。公開ライブラリは thiserrorthiserror + #[non_exhaustive] の2つは、新規ライブラリ初日に入れる組み合わせとしてほぼ正解です。関連thiserror クレート: https://docs.rs/thiserror/#[non_exhaustive] (Rust reference): https://doc.rust-lang.org/reference/attributes/type_system.html#the-non_exhaustive-attribute

`thiserror` と `#[non_exhaustive]` で SemVer に強いエラー型を作る

はじめにRust 1.88 (2025年) で if let chain が安定化されました。2024 edition のコードでは積極的に使えます。 && で if let 条件を連結できるようになり、ネストした if let を平らに書ける構文です。短い変更ですが、効果は大きく出ます。何を解決するかOption が複数あって、すべて Some だったときだけ何かしたい、という場面。素直に書くとネストになります。fn first_premium(items: &[String]) -> Option<&str> { if let Some(first) = items.first() { if let Some(rest) = first.strip_prefix("premium-") { return Some(rest); } } None}「最初の要素を取り出して、それが premium- で始まっていれば残りを返す」という処理ですが、 if let が2段ネストして本筋が見えにくいです。if let chain での書き方2024 edition / Rust 1.88 以降ならこう書けます。fn first_premium(items: &[String]) -> Option<&str> { if let Some(first) = items.first() && let Some(rest) = first.strip_prefix("premium-") { return Some(rest); } None}&& で let パターンを連結します。「最初の let が成功して、かつ次の let も成功する」が満たされたときだけ if 本体に入ります。ポイントを整理します。各 let で取り出した変数 (first, rest) は 後続の条件と if 本体の両方で使える普通の bool 条件と混ぜられる: if let Some(x) = a && x > 0 && let Some(y) = b { ... }失敗したら全体の if は false 扱いネストが消えて、guard 条件が一直線に読めます。let-else との使い分け似た用途で let-else もあります。fn first_premium_letelse(items: &[String]) -> Option<&str> { let Some(first) = items.first() else { return None; }; let Some(rest) = first.strip_prefix("premium-") else { return None; }; Some(rest)}両者は使い分けがあります。 構文 向いている場面 if let chain 「成功したらある処理、失敗したら何もしない」: 条件が満たされた時だけ実行する let-else 「失敗したら関数を抜ける」: ガード句として使い、以降の処理を平らに続ける first_premium の例だと、「失敗時は None を返すだけ」なので let-else のほうが少しシンプルでしょう。一方、「成功したらこの if 本体に入って、入らなければ後続処理に進む」のような continue 的な用途では if let chain が自然です。具体例を見ます。fn process(events: &[Event]) { for event in events { if let Event::Click { target } = event && let Some(url) = target.url() && url.starts_with("http") { println!("opening {url}"); } // 失敗したら次の event に進む }}# enum Event { Click { target: Target } }# struct Target;# impl Target { fn url(&self) -> Option<&str> { None } }ループの中で「3条件すべて満たしたら何かする」を1つの if で書けます。let-else でループから continue するより自然です。bool 条件と混ぜるif let chain は普通の bool 条件と混ぜられます。fn handle(message: &Message, allowlist: &[String]) { if let Some(sender) = &message.sender && allowlist.contains(sender) && let Some(body) = &message.body && !body.is_empty() { println!("ok: {sender} -> {body}"); }}# struct Message { sender: Option<String>, body: Option<String> }let の取り出しと、普通の比較条件 (allowlist.contains, is_empty) が混ざっても、左から右に評価されます。途中で false なら短絡します。何が嬉しいのか主な3点を挙げます。ネスト削減: if let の2段3段ネストが消える意図が線形に読める: 「これとこれが、さらにこれが揃ったら」が左から右に並ぶ副条件を挟みやすい: let の合間に普通の bool 条件を入れられる特に3は地味に便利で、「if let Some(x) と書いてから if x > 0 のために中で if を1個増やす」というパターンが消えます。注意: 安定化は 1.88if let chain が stable になったのは Rust 1.88 です。それより古い rustc ではコンパイルが通りません。Cargo.toml に rust-version = "1.88" 以上を書いていなければ、CI 用に最低でも 1.88 で動かす必要があります。[package]edition = "2024"rust-version = "1.88" # if let chain を使うなら2024 edition そのものは 1.85 から有効ですが、if let chain のために MSRV を 1.88 に上げる、という関係になります。簡単に試すCargo.toml:[package]name = "if-let-chain-demo"version = "0.1.0"edition = "2024"rust-version = "1.88"src/main.rs:fn main() { let items = vec![ "premium-coffee".to_string(), "tea".to_string(), ]; if let Some(first) = items.first() && let Some(rest) = first.strip_prefix("premium-") { println!("found premium: {rest}"); } else { println!("nothing premium"); }}cargo run で found premium: coffee が出ます。まとめif let chain は 2024 edition / Rust 1.88 で実用フェーズに入った&& で let パターンと bool 条件を連結できる取り出した変数は後続の条件と if 本体の両方で使えるlet-else は「失敗したら抜ける」、if let chain は「成功したら何かする」で使い分け使うときは MSRV を 1.88 以上に揃える関連Rust 1.88 release notes (if let chains 安定化): https://blog.rust-lang.org/releases/RFC let_chains: https://rust-lang.github.io/rfcs/2497-if-let-chains.html`let-else` で早期 return を素直に書く - じゃあ、おうちで学べる

`if let` chain — Rust 1.88 / 2024 edition で実用フェーズに入った

はじめにRust の let-else 構文は、Rust 1.65 (2022年) で安定化された機能です。古くからある機能ですが、2024 edition のクリーンなコードベースでは多用されます。clippy の manual_let_else ルールも 2024 では使うことが推奨されます。「Option が None だったら関数を抜ける」「Result が Err だったらエラーで早期 return する」というパターンを、ネストせず書ける構文です。何を解決するかOption<T> から T を取り出して処理を続けたい、という場面はたくさんあります。素直に書くとこうなります。fn label(maybe_name: Option<&str>) -> Option<String> { if let Some(name) = maybe_name { Some(format!("hello, {name}")) } else { None }}これは match でも同じです。fn label(maybe_name: Option<&str>) -> Option<String> { match maybe_name { Some(name) => Some(format!("hello, {name}")), None => None, }}短ければこれで困りませんが、続きの処理が長くなるとネストが深くなります。fn process(maybe_name: Option<&str>, maybe_age: Option<u32>) -> Option<String> { if let Some(name) = maybe_name { if let Some(age) = maybe_age { // 本来やりたい処理がインデントの底に沈む Some(format!("{name} is {age}")) } else { None } } else { None }}ネストが2段、3段と増えると、何を達成したいのかコードからすぐに読み取れなくなります。let-else の書き方let-else は「let で値を取り出すが、失敗したら else ブロックでスコープから抜ける」と書けます。fn label(maybe_name: Option<&str>) -> Option<String> { let Some(name) = maybe_name else { return None; }; Some(format!("hello, {name}"))}ポイントを整理します。let Some(name) = maybe_name で名前を取り出そうとする失敗 (None) なら else ブロックに入るelse ブロックは 必ず関数から抜ける (return, break, continue, panic) 必要がある成功した場合、name は変数として以降のスコープで使えるネストの段数が減って、本来やりたい処理 (=フォーマットして返す) が一直線に書けます。ネスト解消の効果先ほどの2段ネスト版を let-else で書き直してみます。fn process(maybe_name: Option<&str>, maybe_age: Option<u32>) -> Option<String> { let Some(name) = maybe_name else { return None; }; let Some(age) = maybe_age else { return None; }; Some(format!("{name} is {age}"))}3行になりました。「失敗ケースは早めに弾いて、本筋のコードを平らに書く」 という guard pattern が自然に表現できます。Result でも同じResult でも同じ書き方ができます。エラー伝搬は ? のほうが短いですが、エラー型を変換したい時は let-else のほうが明示的です。#[derive(Debug)]enum AppError { InvalidInput(String),}fn parse_pair(s: &str) -> Result<(i32, i32), AppError> { let Some((left, right)) = s.split_once(',') else { return Err(AppError::InvalidInput(format!("missing comma: {s}"))); }; let Ok(left) = left.trim().parse::<i32>() else { return Err(AppError::InvalidInput(format!("not an int: {}", left.trim()))); }; let Ok(right) = right.trim().parse::<i32>() else { return Err(AppError::InvalidInput(format!("not an int: {}", right.trim()))); }; Ok((left, right))}fn main() { println!("{:?}", parse_pair("1, 2")); println!("{:?}", parse_pair("hello")); println!("{:?}", parse_pair("1, x"));}実行結果はこうなります。Ok((1, 2))Err(InvalidInput("missing comma: hello"))Err(InvalidInput("not an int: x"))これを ? で書こうとすると、 String を AppError に変換する From 実装を毎回足す必要が出てきます。let-else ならエラーメッセージを箇所ごとに直接書けるので、テスト書く前のプロトタイプ段階では let-else のほうが速いです。何を else ブロックに書けるかelse ブロックは「never 型を返す」必要があります。具体的には次のような選択肢です。return ...breakcontinuepanic マクロloop で永久ループ上記を返す関数 (例: std::process::exit)普通の値を返すと「else ブロックは関数から抜ける必要があります」とコンパイラに怒られます。else ブロック内で何か値を計算してから抜けるのは OK です。let Some(name) = maybe_name else { eprintln!("name is missing"); return None;};clippy::manual_let_else で機械検出するCargo.toml に1行入れると、let-else で書ける箇所を clippy が指摘してくれます。[lints.clippy]manual_let_else = "warn"新規プロジェクトでは入れておくのを勧めます。if let { ... } else { return ... } を見つけて警告してくれるので、自然に let-else の習慣がつきます。いつ使わないかlet-else がいつでも正解というわけではありません。以下のケースは別の構文のほうが自然です。成功時と失敗時で同じ後処理がある: match のほうが両分岐を並べて書けて読みやすいOption を別の値に置き換えたいだけ: unwrap_or / unwrap_or_else / map_or で十分Result の Err をそのまま伝搬したいだけ: ? で1文字// これは let-else よりシンプルlet port = config.get("port").unwrap_or("8080");// これは let-else より ? が自然fn read() -> Result<String, std::io::Error> { let content = std::fs::read_to_string("config.toml")?; Ok(content)}let-else は 「失敗時は関数から抜けるが、成功時は以降長く処理を続ける」 ときに最も光ります。まとめlet-else はネストを減らして guard pattern を書ける構文else ブロックは return / break / panic! などで必ず抜ける必要があるOption / Result のどちらにも使えるclippy::manual_let_else = "warn" で書き直し候補を機械検出できる失敗パスが短く、成功パスが長い場面で最大の効果関連let-else RFC: https://rust-lang.github.io/rfcs/3137-let-else.htmlclippy manual_let_else: https://rust-lang.github.io/rust-clippy/master/index.html#manual_let_else

`let-else` で早期 return を素直に書く

はじめにRust で Option や Result から値を取り出すとき、つい .unwrap() を書いてしまう場面があります。動くし短い。だから書く。だけどそのコードは、エラー時にスタックトレースなしで panic します。本番で踏むと 「どこで何の理由で死んだのか」 がわからない事故になります。この記事は、.unwrap() を書きたくなった瞬間の代替案を8個並べます。状況に応じて選んでください。前提: なぜ unwrap() は 良くないか.unwrap() の問題は3つです。panic メッセージが「called \Option::unwrap()` on a `None` value`」のような汎用文言で、原因の手がかりがないどんな理由で None / Err が起きたかドキュメントに残らない後で読み返したときに「ここは絶対 None にならないと信じている」のか「面倒で書いた」のか区別がつかないCargo.toml で clippy::unwrap_used = "deny" を入れると unwrap() がコンパイルエラーになります。これを入れたうえで以下の選択肢から選ぶのが、2024 edition のクリーンなコードベースでの基本姿勢です。選択肢 1: ? で伝搬する呼び出し側にエラーを投げ返すのが一番素直です。Result 型を返す関数の中で ? を1文字書くだけ。fn read_config() -> Result<String, std::io::Error> { let s = std::fs::read_to_string("config.toml")?; Ok(s)}この用途で unwrap() を書く理由は基本ありません。? の方が短く、エラー型を保ったまま呼び出し側に渡せます。選択肢 2: expect("理由") で意図を残す「絶対 None にならないと自分は信じているが、もし None になったら panic で気付きたい」時は .expect("理由") を使います。let port = std::env::var("PORT").expect("PORT must be set in environment");panic 時のメッセージが「PORT must be set in environment」になるので、ログを見た人がすぐ原因にたどりつきます。unwrap() で死んだ場合の「called Option::unwrap on a None value」とは情報量が桁違いです。expect_used lint を warn にしておくと、expect を使った箇所が coverage 的に見えます。それでも unwrap よりは1段マシ。選択肢 3: unwrap_or でデフォルト値を返す「None / Err なら fallback 値を使う」だけのケース。unwrap_or 系がきれいに収まります。let port = std::env::var("PORT").unwrap_or_else(|_| "8080".to_string());let first_word = " hello world".split_whitespace().next().unwrap_or("(none)");let count: u32 = config.get("count") .and_then(|s| s.parse().ok()) .unwrap_or(0);unwrap_or (静的なデフォルト) と unwrap_or_else (クロージャで遅延評価するデフォルト) の使い分けがあります。unwrap_or(expensive_call()) だと None じゃなくても evaluate されて重いので、計算が必要な fallback は unwrap_or_else 一択です。選択肢 4: ok_or / ok_or_else で Option を Result に変える「Option<T> を ? で伝搬したい」場面。ok_or で Result<T, E> に持ち上げます。#[derive(Debug)]enum Error { Missing(&'static str),}fn read_port(map: &std::collections::HashMap<&str, String>) -> Result<u16, Error> { let raw = map.get("port").ok_or(Error::Missing("port"))?; raw.parse().map_err(|_| Error::Missing("port"))}unwrap() で「絶対あるはず」と書く代わりに、 ok_or で「無かった場合のエラー」を表明する。読み手にとって意図がはるかに明確です。選択肢 5: let-else でガードを書くOption を ? で投げ返すには大げさだが、ネストはしたくない、という場面。 let-else でガード句を書きます。fn label(maybe_name: Option<&str>) -> Option<String> { let Some(name) = maybe_name else { return None; }; Some(format!("hello, {name}"))}「失敗時は早期 return、成功時は以降長く処理を続ける」スタイルが書けます。unwrap() で取り出してから後続処理を書くより、意図が線形に読めます。選択肢 6: if let chain で複数条件を平らにする複数の Option がすべて Some だったときだけ何かしたい、という場面。 Rust 1.88 / 2024 edition の if let chain。fn first_premium(items: &[String]) -> Option<&str> { if let Some(first) = items.first() && let Some(rest) = first.strip_prefix("premium-") { return Some(rest); } None}「全部 Some なら本体に入る」が一直線で読めます。選択肢 7: match で全 variant を網羅するエラー variant ごとに違う対処をしたい時は、 match で網羅します。match parse_port(input) { Ok(port) => println!("port = {port}"), Err(ParsePortError::TooLarge) => eprintln!("port out of range"), Err(ParsePortError::NotANumber(s)) => eprintln!("not a number: {s}"),}unwrap() でひとまとめに panic させると、原因によって違う出口を作れません。これは エラー variant 単位でログレベルや復旧戦略を変えたい 場合に重要です。選択肢 8: 設計を見直す最も強力な選択肢。「そもそも Option / Result を返す必要があったのか」を問い直すことです。// before: ゼロ割りを runtime で検出fn page_count(total: usize, page_size: usize) -> Option<usize> { if page_size == 0 { None } else { Some(total.div_ceil(page_size)) }}// after: NonZero<usize> でコンパイル時に「ゼロでない」を保証fn page_count(total: usize, page_size: std::num::NonZero<usize>) -> usize { total.div_ceil(page_size.get())}引数の型を絞れば Option を返す必要がそもそもなくなります。unwrap() を書きたくなったら 「型でこの不安を消せないか」 を一度考える価値があります。これが Rust ならではの強み。チェックリストunwrap() を書きそうになったとき、上から順にチェックします。Result を返す関数なら → ?絶対あるはずだが panic で気付きたい → .expect("理由")None / Err なら fallback でよい → unwrap_or / unwrap_or_elseOption を Result に変えたい → ok_or / ok_or_else失敗時は早期 return → let-else複数 Option を AND で扱う → if let chainエラー variant ごとに分岐したい → match「そもそも Option を返す必要があるか」 → 型を絞るCargo.toml に unwrap_used = "deny" を入れて lint を強制すれば、「とりあえず .unwrap()」を CI 段階で止められます。コードレビューの負担も減ります。まとめ.unwrap() は panic 時の情報量が乏しく、意図がコードに残らない antipattern多くの場合 ? / expect / unwrap_or / ok_or / let-else / if let / match のどれかで書ける最終手段は「型を絞って Option を返す必要をなくす」設計の見直しclippy::unwrap_used = "deny" を Cargo.toml に入れて、 CI で強制する関連clippy unwrap_used: https://rust-lang.github.io/rust-clippy/master/index.html#unwrap_usedstd::option::Option API: https://doc.rust-lang.org/std/option/enum.Option.htmlstd::num::NonZero: https://doc.rust-lang.org/std/num/struct.NonZero.html

`unwrap()` を書きそうになったときの選択肢8つ

おい、要件を言葉にしろ

OWASP ZAP の finding を Rust/Axum の handler に戻して直す

おい、夢は持たなくてもよいけど、失敗はしろ

 Argo CD ApplicationSet で PR preview の構成を Kind 上で検証した

前作では「何を守るかを決める」という視点から、非機能要件・分散システム・トレードオフの考え方を紹介しました。「面白そうだけど、実際のコードはどうなっているの？」——この続編はその問いへの答えです。概念として語っていたことを、今度はコードの上で見ていきます。リトライはどう書くか。タイムアウトをどこに置くか。冪等性はどう担保するか。「なんとなく知っている」を「動くコードで理解している」に変えることを目指した発表です。ただし、コードを読む会ではありません。一行一行を追うのではなく、「なぜそう書くのか」「何を諦めて何を得ているのか」に焦点を当てます。設計の判断はコードに刻まれている——その読み方を一緒に考えます。前作を見ていなくても楽しめますが、見ていると2倍楽しめます。知らんけど。そして今作も、20分で終わらせるのはとても難しい。前作https://speakerdeck.com/nwiizo/sisutemuha-dong-ku-dakedeha-zu-rinai-fei-ji-neng-yao-jian-fen-san-sisutemutoredoohunoji-chu

システムは「動く」だけでは足りない 実装編 - 非機能要件・分散システム・トレードオフをコードで見る

翻訳者がいるから、共通言語は整備されない - Architecture for Flow の読書感想文

ソフトウェアエンジニアの仕事を、「コードを書く人」ではなく「何を守るかを決める人」の部分を紹介した発表です。非機能要件、分散システム、トレードオフを題材に、速さ、正しさ、止まりにくさが引っ張り合うなかで、日々どう判断しているのかをできるだけ身近な例で話しました。技術の基礎を知るための資料でありながら、この仕事そのものの面白さに触れてもらうための発表でもあります。唯一の問題は20分で終わらせるのがとても難しい。続編https://speakerdeck.com/nwiizo/sisutemuha-dong-ku-dakedehazu-rinai-shi-zhuang-bian-fei-ji-neng-yao-jian-fen-san-sisutemutoredoohuwokododejian-ru

システムは「動く」だけでは 足りない - 非機能要件・分散システム・トレードオフの基礎

2026年4月10日、「設計ナイト2026」というイベントで「アーキテクチャモダナイゼーションとは何か―技術・事業・組織で大事なこと」というタイトルの登壇をしました。まずお伝えしたいのは、このスライドを20分に収めようとしていた人間がいるということです。私です。前日、翻訳作業をほぼ徹夜で行っていました。朝、体調が完全に崩壊した状態で目を覚まし、それでも資料を修正しようとパソコンを開きました。起き上がったら更に悪化しました。起き上がらなければよかった、という感想だけが残りました。2026年、我々にはAIエージェントという心強い味方がいます。しかし彼らはインターネットがなければ何もできません。体調が崩壊した人間と、Wi-Fiのない空間に置かれたAIエージェント。これは個人の怠慢ではなく、時代とタイミングの悲劇です。資料は中途半端なまま、「会場にWi-Fiがあるから現地で仕上げればいい」という、締切前夜の人間だけが信じられる種類の楽観を胸に家を出ました。仕上がりませんでした。結果として、当日は前日までの暫定版の資料で発表するという形になりました。すべて言い訳です。本当に申し訳ありませんでした。削減途中なスライドもありますがこちらでは完全版の資料を提供いたします。ただ、こちらのほうが良いということでは決してありません。当日あの場で聴いてくださった皆さんの時間のほうが、何倍も価値があります。なお、まったく関係ありませんが、私の誕生日は来月5月10日です。設計ナイト 2026 https://kichijojipm.connpass.com/event/383313/書籍『アーキテクチャモダナイゼーション ―組織とビジネスの未来を設計する』は好評発売中です。https://amzn.to/3ZR5Bgv

アーキテクチャモダナイゼーションとは何か

おい、夢を持たなくても良いぞ

はじめにNeovim 0.12のリリースノートを開いて最初に思ったのは、「これ、lazy.nvim要らなくなるのでは」だった。ビルトインのプラグインマネージャ vim.pack。宣言的なLSP設定 vim.lsp.enable()。ビルトインの :Undotree。ちょうどNvChadからLazyVimに乗り換えたばかりで、ディストリビューションにどこまで頼る必要があるのか考えていたところだった。結論から言えば、lazy.nvimはまだ要る。だが、「何を使うか」ではなく「何を外せるか」に問いが変わった。2026年3月29日リリース。前バージョン0.11から約1年、Neovimの方向性を決定づける転換点です。全項目を網羅するのではなく、「設定を見直す必要がある」「試す価値がある」と判断できる粒度でまとめます。公式の全変更点は :help news で確認できます。github.comこのブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。ビルトインプラグインマネージャ vim.pack今回のリリースで最もインパクトが大きいのは、ビルトインのプラグインマネージャ vim.pack の導入です。これまでNeovimのプラグイン管理は、lazy.nvim、mini.deps、packer.nvimなど外部ツールに完全に依存していました。Vim本体には :packadd と pack/*/start/ ディレクトリによる仕組みがありましたが、インストールや更新の機能はなく、実用的なプラグイン管理には外部ツールが必須でした。vim.pack はシンプルな3つのAPI——add、update、del——でプラグインのライフサイクルを管理します。vim.pack.add({ { src = "https://github.com/lewis6991/gitsigns.nvim" }, { src = "https://github.com/nvim-telescope/telescope.nvim" }, { src = "https://github.com/nvim-treesitter/nvim-treesitter" },})vim.pack.add() でインストール確認のプロンプトが表示され、vim.pack.update() で更新、確認後に :write で反映する流れです。:packadd のキャッシュ更新もインプレースで行われ、複数プラグインのロード時の起動速度も改善されています。ただし、lazy.nvimのような遅延読み込みや依存関係解決の機能はありません。自分の環境を例にとると、LazyVimの上にnoice.nvim、telescope.nvim、Snacks.nvim、blink.cmpが載っていて、それぞれが複数の依存プラグインを持っています。この規模の構成をvim.packだけで管理するのは無理があります。一方で、プラグイン数を絞った構成なら本体の機能だけで完結できるようになりました。約2000行の設定を500行未満に削減した事例も報告されています。自分の設定がどこまで削れるかは、今後の検証次第です。vieitesss.github.ioプラグインマネージャの選定は「何を使うか」から「何を使わずに済むか」に変わりました。LSPの大幅強化vim.lsp.enable() によるサーバー管理LSP設定の仕組みが大きく変わりました。vim.lsp.enable() でサーバーのライフサイクルを宣言的に管理できます。vim.lsp.enable({ "bashls", "gopls", "lua_ls", "rust_analyzer", "ts_ls"})自分の環境ではLazyVimの opts.servers に各サーバーの設定を渡す方式をとっています。LazyVim extrasが各言語のセットアップを担当し、nvim-lspconfigにはまだ依存しています。0.12で追加された lsp/ ディレクトリ構成を使えば、サーバー固有の設定を個別ファイルとして配置できます。たとえば lsp/lua_ls.lua に設定を書けば vim.lsp.enable() がそれを読み込みます。現在LazyVimの opts.servers に書いているlua_ls、gopls、zlsの設定を、そのままファイルに分割できます。この構成が安定すれば、LazyVim extrasを経由せずビルトインAPIだけで賄えるかもしれません。vim.lsp.is_enabled() で有効状態の確認、vim.lsp.get_configs() で設定の取得も可能です。:lsp コマンド対話的なLSP管理コマンド :lsp が追加されました。バッファにアタッチされたサーバーの状態確認や操作がコマンドラインから行えます。:checkhealth vim.lsp もアタッチ状況を表示するようになり、LSPの問題切り分けが容易になりました。新しいLSPケイパビリティ対応するLSPケイパビリティが大幅に追加されました。主要なものを挙げます。textDocument/codeLens — コードレンズが仮想行として表示。grx で実行textDocument/inlineCompletion — インライン補完textDocument/diagnostic — プル型診断（関連ドキュメントの診断も含む）textDocument/semanticTokens/range — ビューポート範囲のみのセマンティックトークン要求（パフォーマンス改善）workspace/diagnostic — ワークスペース診断動的登録（Dynamic Registration）のサポート型定義へのジャンプ grt も追加されました。その他のケイパビリティ（documentLink、linkedEditingRange、onTypeFormatting、selectionRange、colorPresentation）は :help news を参照してください。その他のLSP改善注目度の高い改善をまとめます。vim.lsp.buf.rename() でシンボルが hl-LspReferenceTarget でハイライトされる診断フロートに DiagnosticRelatedInformation が表示、gf で関連箇所にジャンプ可能補完アイテムのカラープレビュー表示vim.lsp.completion.enable() に cmp オプション追加（補完の並び順制御）マルチラインセマンティックトークンのサポートexit_timeout が正式機能に昇格実験的UI: ui2ui2 は、Neovimのメッセージ表示システムを根本から見直す実験的な新機能です。require('vim._core.ui2').enable()最大の変更は、あの「Press ENTER or type command to continue」プロンプトの排除です。長年Neovimユーザーを悩ませてきたこの割り込みが消えます。メッセージはバッファとウィンドウとして表示され、ページャもバッファベースに。コマンドライン入力中のシンタックスハイライトも追加され、: で打つコマンドが構文色分けされます。自分の環境ではnoice.nvimがコマンドライン表示やメッセージ表示を担っています。ui2はnoice.nvimが解決してきた問題の一部をNeovim本体で実現しようとするものです。noice.nvimとui2はおそらく競合するので、試す時はnoice.nvimを無効にする必要があります。LazyVimならdisabled.luaに1行追加するだけです。まだ実験段階ですが、「Press ENTER」が出ない世界に一度慣れると戻れません。何千回Enterを押したか覚えていないが、指は覚えている。その反射が不要になるだけで、0.12に上げる動機になります。新しいビルトインプラグイン:DiffToolディレクトリやファイルを比較するビルトインコマンドです。自分はdiffview.nvimを使っていますが、ちょっとしたファイル比較にはビルトインで十分でしょう。:Undotreeアンドゥツリーを視覚的にナビゲートするビルトインコマンドです。undotree.vimプラグインが不要になります。エディタコマンドの追加・改善地味だが日常的に効くコマンドが追加されました。:uniq — バッファの重複行を除去。:%!sort -u が不要に。ログの重複除去で毎週のように使っていたコマンドがビルトインになったのは地味に嬉しい:retab -indentonly — 行頭のインデントのみタブ/スペース変換。文字列リテラル内のタブを壊さない:wall ++p — 存在しない親ディレクトリを自動作成して保存。新しいモジュールを一気に作る時に便利:source — Treesitterを使ってMarkdown内のLuaコードブロックを検出・実行:help! — DWIM動作。ヘルプバッファ内で K がコード中のヘルプタグを推測'wildchar' — /、?、:g、:v、:vimgrep でも補完を有効化Treesitterインクリメンタルノード選択ビジュアルモードで an（outer node）、in（inner node）、]n/[n（次/前のノード）によるインクリメンタルなノード選択が追加されました。自分の環境ではmini.aiで関数（af/if）、クラス（ac/ic）、パラメータ（aa/ia）などのカスタムテキストオブジェクトを定義しています。ビルトインの an/in はノード単位の汎用選択なので、これらを完全に置き換えるものではありません。ただし「とりあえずこのブロックを選択したい」場面では an で十分なことも多く、設定なしで使えるのは便利です。その他Query:iter_captures() が開始・終了カラムの指定をサポート:EditQuery にタブ補完追加、injected languagesでも動作Markdownのデフォルトハイライトが有効化新しいオプション'autocomplete'挿入モードでの自動補完を有効化するオプションです。blink.cmpを使っている環境では直接の恩恵は薄いですが、外部の補完プラグインなしでもそれなりの補完体験が得られるようになったのは重要です。半年後にblink.cmpを外す実験をする時、このオプションが効いてきます。'pumborder'ポップアップメニューにボーダーを追加するオプションです。自分の環境では winborder = "rounded" を設定済みで、blink.cmpにも個別に border = "rounded" を指定しています。'pumborder' を使えばビルトイン補完でも統一されたボーダーが得られるので、blink.cmpを外す選択肢が出たときに効いてきます。'winborder' にも bold スタイルとカスタムボーダーが追加されています。'diffopt' の拡張'diffopt' に indent-heuristic と inline:char がデフォルトで含まれるようになりました。inline:word でギャップや句読点で区切られた隣接ブロックをマージ。hl-DiffTextAdd ハイライトグループも追加され、変更行内の追加テキストが視覚的に区別されます。diffview.nvimを使っていても、ビルトインdiffの表示品質が上がるのは歓迎です。'exrc' の改善プロジェクトローカル設定（'exrc'）が親ディレクトリからも読み込まれるようになりました。セキュリティ面では (a)llow オプションが削除され、:view 後に :trust で明示的に信頼する流れに変更されています。モノレポで親ディレクトリの .nvim.lua が効くようになったのは、地味だが半年後に効いてくる類の変更です。その他の新オプション'pummaxwidth' — ポップアップメニューの最大幅'complete' の拡張 — F{func} でカスタム関数、o で omnifunc、{flag}^<limit> でソースごとの候補数上限'completeopt' の nearest — カーソルからの距離順ソートLua API の追加vim.net.request()HTTP(S)コンテンツを取得する関数です。plenary.nvimの curl ラッパーや外部コマンドに頼らず、Lua APIだけでHTTPリクエストを発行できます。プラグイン開発でのHTTP通信がシンプルになります。plenary.nvimへの依存を減らしたいプラグイン作者にとっては朗報です。mini.nvimもvim.packへの移行を進めており、mini.depsの廃止を予定しています。nvim-mini.orgvim.json の改善vim.json.encode() に indent オプション（整形出力）と sort_keys（キーのソート）が追加されました。vim.json.decode() には skip_comments オプションが追加され、jsonc形式のファイルも扱えます。その他のLua API主要なものを抜粋します。vim.uv の型注釈が追加vim.tbl_extend() / vim.tbl_deep_extend() の behavior に関数を渡せるようにvim.fs.root() がネストリストで「同一優先度」をサポートvim.list.unique() / Iter:unique() で重複排除Iter:take() / Iter:skip() が述語を受け付ける実験的: vim.pos と vim.range の抽象化パフォーマンス改善vim.glob.to_lpeg() のPeglob実装が約50%高速化i_CTRL-R のレジスタ挿入が10倍高速化（リテラル挿入に変更）LSP textDocument/semanticTokens/range でビューポート範囲のみリクエスト:packadd のキャッシュ更新がインプレースに改善i_CTRL-R の変更は破壊的でもあります。レジスタがユーザー入力ではなくリテラルとして挿入されるようになったため、レジスタ内容にマッピングが適用されていた時は動作が変わります。自分の環境では影響を受けるマッピングはなかったですが、レジスタ挿入をマクロ的に使っている人は確認が必要です。ターミナルサスペンドされたPTYが [Process suspended] と表示、キー入力で再開可能ターミナル終了がステータスラインに終了コード付きの仮想テキストとして表示DEC Private Mode 2026（同期出力）のサポート[Process exited] 表示を terminal-config で無効化可能デフォルトステータスラインの改善デフォルトの 'statusline' が式として公開され、診断情報、進捗状況、ターミナルの終了コードが表示されるようになりました。自分の環境では laststatus = 0 でステータスラインを非表示にし、incline.nvimでファイル名と診断情報を表示しているので直接の恩恵は限定的です。ただし、'statusline' のハイライトグループスタッキング・継承サポートは、カスタムステータスラインの表現力を上げる改善です。破壊的変更設定の見直しが必要になりうる変更をまとめます。診断API: vim.diagnostic.disable()、vim.diagnostic.is_disabled()、vim.diagnostic.enable() のレガシーシグネチャが削除。:sign-define による診断サイン設定も削除LSP: JSON null が vim.NIL で表現。vim.lsp.semantic_tokens の start()/stop() が enable() にリネームLua: vim.diff が vim.text.diff にリネームオプション: 'shelltemp' デフォルトが false に変更プラグイン: shellmenu 削除。package-tohtml が :packadd nvim.tohtml でオプトイン化Treesitter: vim.treesitter.get_parser() が失敗時に nil を返すように変更（エラーをスローしない）URI解析: RFC3986に準拠LazyVimを使っている場合、ディストリビューション側が破壊的変更の多くを吸収してくれます。ただし vim.diff → vim.text.diff のように自前のLuaコードに影響するものは自分で対応が必要です。まとめNeovim 0.12は「外部プラグインへの依存を減らし、本体の機能を充実させる」という方向性を明確にしたリリースです。vim.pack、vim.lsp.enable()、:Undotree、:DiffTool、インクリメンタルノード選択。いずれも、これまで外部プラグインが担っていた機能です。設定を見直す観点では、以下の優先度で進めるつもりです。LSP設定の整理: LazyVim extrasと lsp/ ディレクトリ構成の併用を試すプラグインの棚卸し: :Undotree ビルトイン化でプラグイン1つ削減。:DiffTool とdiffview.nvimの使い分けを検証ui2 の試用: noice.nvimをdisabled.luaで無効化してui2で1週間過ごしてみる破壊的変更の対応: vim.text.diff のリネーム確認ビルトイン補完の検証: 'autocomplete' + vim.lsp.completion.enable() でblink.cmpをどこまで代替できるか冒頭で「lazy.nvim要らなくなるのでは」と書きました。答えは「まだ要る。だが、依存度は確実に下がる」です。「何を使うか」ではなく「何を外せるか」——その問いに対する答えを、0.12は少しずつ用意してくれています。次の0.13のロードマップに「Prepare for 1.0」が掲げられている中で、0.12はその基盤を固めるリリースです。neovim.ioプラグインを1つ外すたびに、起動が速くなり、壊れる箇所が減る。外部プラグインは負債ではないが、ビルトインで代替できるなら、それに越したことはない。参考neovim.iobriandouglas.iegithub.com

Neovim 0.12 リリース内容まとめ

LLM に足りないのは能力ではない。あなたの事情だ

自分の環境やマインドが変わったタイミングで社内で共有会をしています。やる気がある時に不定期で。

【社内勉強会】新年度からコーディングエージェントを使いこなす - 構造と制約で引き出すClaude Codeの実践知

はじめに夕方6時、日報を書こうとしてターミナルを開く。今日何をしたか——思い出せない。Slack を遡り、PR の履歴を見る。20分かけてようやく事実を集め終えたが、「今日の振り返り」の欄がまだ空白のまま残っている。半年前に「Claude Codeのスラッシュコマンドで日報を書く」という記事を書いた。syu-m-5151.hatenablog.comあの仕組みは、それなりに機能していた。だが使い続けるうちに、いくつかの限界が見えてきた。手動でメモを追加する必要がある。Claude Code で作業した記録はすべてログに残っているのに、わざわざ二重に記録している。日報の面倒さの大半は、この「思い出す作業」にあったMCP（Model Context Protocol）サーバーで分析を試みたが、セットアップが重い。Python環境の管理、依存関係の解決、サーバーの起動。日報のために毎回サーバーを立てるのは本末転倒だった振り返りが自動生成されることへの違和感。ツールが「今日の学び」まで書いてくれると、自分で考えた気になって実は何も考えていない3つ目が最も根深い問題だった。思考を外注していた日報ツールに「振り返り」セクションを自動生成させていた。Claude が「今日はXを学びました」「明日はYに取り組みます」と書いてくれる。楽だった。楽すぎた。ある日、自動生成された振り返りを読み返して気づいた。書いてあることが正しいのに、何も残っていない。 事実は合っている。でも「自分が何を感じたか」「なぜあの判断をしたか」は書かれていない。当然だ。それはログには残らない。コルブの経験学習サイクルという理論がある。経験 → 省察 → 概念化 → 実験、の4段階を回すことで経験が学びに変わる。ここでいう「省察」とは、経験を自分の内側から振り返ることだ。「あのとき自分は何を感じ、なぜあの判断をしたか」を言語化するプロセスを指す。自動生成された振り返りは、この省察のステップを丸ごとスキップしている。ログから事実を要約するだけでは、経験は「起きたこと」のまま流れていく。思考・努力・羞恥心まで外注してはいけない。でも正直に言えば、楽さに流されてしばらく気づかなかった。自動生成された振り返りを毎日コピペして「今日も内省した」と思い込んでいた期間がある。この気づきが、nippo を作り直すきっかけになった。スキル + Rust バイナリという構成nippo は Claude Code のスキル（.claude/skills/）と Rust バイナリの組み合わせで動く。Markdown ファイル1つがスキル定義になり、Claude がそれを読んで手順を実行する。以前の MCP サーバーベースのアプローチで必要だった Python 環境の管理やサーバーの起動・停止は、すべて不要になった。cargo install nippo で完結する。syu-m-5151.hatenablog.comデータ収集部分は Rust で書いた。Claude Code が日々の作業で残すログファイルを高速に読み取り、半年分以上のデータ（手元の環境で約1,900ファイル・960MB）でも1秒未満で処理できる。今日分だけなら0.05秒。読まなくていいファイルを更新日時で先に弾き、残ったファイルも最小限だけ読んで判定するからだ。rayon による並列処理で CPU を6コア使い切る。github.com設計思想: 事実と内省を分離するnippo の核心は「何を自動化して、何を自動化しないか」の線引きにある。 自動化する  自動化しない  作業時間・プロジェクト・セッション数の集計  「なぜそう判断したか」の言語化  意思決定ポイントの抽出  判断の振り返り  ツール使用統計  感情の記録  用語・コミュニケーションのレビュー  明日何を変えるかの決定 この線引きを実現するために、9つのコマンドを用意した。日々の記録/nippo              # 事実の自動収集（意思決定・用語レビュー含む）/nippo brief        # 端的なサマリー（Rust バイナリが直接出力）自分で考える/nippo reflection   # 問いだけ提示。回答欄は空白。自分で書く答えを参考にする/nippo guide        # 回答付き + 学ぶべき概念 + 多角的フィードバック/nippo report       # 上司・メンター向けの進捗報告/nippo review       # 評価面談・自己評価用の成果まとめ期間を俯瞰する/nippo insight      # 深い振り返り（ALACTモデル）/nippo trend 90     # 90日間を三分割して変化の推移を分析自分は /nippo を見てから /nippo reflection に5分使う。最初は面倒だった。でも「意地で3時間使った」と書いたあの日から、日報への態度が変わった。ここでは、nippo の思想を最もよく表す2つのモード—— /nippo reflection と /nippo guide ——について詳しく説明する。/nippo reflection — 問いだけを出すreflection モードが nippo の本質だと思っている。Claude はその日の作業データから具体的な問いを生成するが、回答は書かない。回答欄は空白で出力される。## ① 省察的観察 × 感情（コルブ + ギブス）- rayon の lifetime エラーに3時間かかったとき、  どの時点で「別のアプローチを試そう」と思いましたか？  >- 「思考・努力・羞恥心まで外注させない」という設計方針を  言語化したとき、以前の経験で「外注しすぎた」と感じた場面はありましたか？  >「今日何を学びましたか？」のような汎用的な問いではない。その日の作業データに基づく、具体的な問い。コルブの経験学習サイクルとギブスのリフレクティブサイクルの理論に基づいている。答えを書くのは自分だ。5分でもいい。書くことで、自動生成では得られない「自分の言葉」が残る。実際に使ってみた日のことを書く。nippo の開発中、reflection が出した問い——「rayon の lifetime エラーに3時間かかったとき、どの時点で別のアプローチを試そうと思いましたか？」。5分考えて気づいた。3時間粘ったのは技術的な判断ではなく、「ここで諦めたら負けだ」という意地だった。ログにはエラーメッセージと修正のdiffしか残っていない。でも振り返りに書いたのは「意地で3時間使った。次は30分で切り替える」だった。自動生成では絶対に出てこない一行だ。/nippo guide — 初学者に多角的なフィードバックをguide モードはジュニアエンジニアや初学者向けに設計した。初学者がシニアエンジニア以外の視点に触れる機会は少ない。1on1 でメンターの意見は聞けても、CTOがどこを見ているか、ビジネスサイドが何を気にしているかは、普段の業務では見えにくい。guide モードはその疑似体験を提供する。シニアエンジニアだけでなく、スタッフエンジニア・CTO・ビジネスサイドの視点からフィードバックを生成する。### シニアエンジニアの視点- 判断の質: この技術選択は妥当だったか### スタッフエンジニアの視点- アーキテクチャとの整合性: システム全体と整合しているか### CTO / テックリードの視点- ビジネスインパクト: ユーザーや売上にどう影響するか### ビジネスサイドの視点- 数字で語れるか: 「改善した」ではなく「Xms → Yms」と言えるか学ぶべき概念は概念名と検索キーワードだけを示し、書籍やURLは出さない（ハルシネーションのリスクがあるため）。概念の名前を知っていれば、検索でも生成AIへの質問でも、自分でたどり着ける。インストールセットアップは2ステップ。Rust バイナリとスキル定義を別々にインストールする。詳細は README に書いた。1. Rust バイナリcrates.io で公開している。cargo install nippoリポジトリから直接インストールもできる。cargo install --git https://github.com/nwiizo/nippo nippo2. スキル定義Claude Code がレポートを生成するには、SKILL.md とテンプレート群が必要だ。git clone https://github.com/nwiizo/nippo && cd nippoln -s "$(pwd)/.claude/skills/nippo" ~/.claude/skills/nippoシンボリックリンクが重要なポイントだ。スキルディレクトリ内に docs -> ../../../docs のシンボリックリンクが含まれており、これによりどのディレクトリから /nippo を実行してもテンプレートが正しく読み込まれる。git pull でスキルとテンプレートの両方が更新される。これで /nippo が使える。テンプレートをカスタマイズするレポートの形式はすべて docs/templates/ の Markdown テンプレートで定義されている。日報の項目、reflection の問い生成ルール、guide のフィードバック視点——すべて Markdown を書き換えるだけで出力が変わる。Rust バイナリの再ビルドは不要だ。テンプレートの仕組みを少し説明する。SKILL.md は ${CLAUDE_SKILL_DIR}/docs/templates/ というパスでテンプレートを参照する。${CLAUDE_SKILL_DIR} は Claude Code がスキルの実行時に自動で解決する変数で、~/.claude/skills/nippo/ に展開される。そこからシンボリックリンクを辿って docs/templates/ に到達する。だからリポジトリ内のテンプレートを編集すれば、次回の /nippo 実行から即反映される。コルブ+ギブスではなく自社の振り返りフレームワークを使いたければ、テンプレートを差し替えるだけでいい。fork して自分のチーム用にカスタマイズするのも良い。MCP → スラッシュコマンド → スキル の変遷振り返ると、日報ツールの変遷は Claude Code との付き合い方の変遷でもあった。 時期  手法  何が良かったか  何が足りなかったか  2025年6月  スラッシュコマンド (/nippo-add)  シンプル、すぐ使える  手動記録が面倒、振り返りが薄い  2025年後半  MCP サーバー  データ分析が柔軟  セットアップが重い、Python依存  2026年3月  スキル + Rust バイナリ  自己完結、高速、内省を外注しない  ← いまここ スラッシュコマンドは「記録する」ツールだった。MCP は「分析する」ツールだった。スキル版は「考えさせる」ツールを目指している。事実の収集は自動化する。でも、考えるのは自分だ。そして正直なところ、考えた結果が「今日は特に何も学ばなかった」になる日もある。それでいい。空白の振り返りも、自動生成された嘘の振り返りよりはましだ。おわりに日報は面倒だ。でも面倒さの正体は「書くこと」ではなく「思い出すこと」だった。nippo は「思い出す」を自動化する。Claude Code の作業ログには、今日何をしたか、何を判断したか、どんなツールを使ったかがすべて記録されている。それを1秒で収集して構造化する。残るのは「考えること」だけだ。/nippo reflection の問いに答える5分間。それが、自動生成された振り返りの100行分より価値がある。冒頭の「振り返り欄が空白のまま」——今は、あの20分が5分になった。思い出す作業が消えた分、考える時間が増えた。このブログが良ければスターしたり、読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。github.com

Claude Code のスキルとして動作する日報自動生成ツールを作った

かつて、ある愚かなエンジニアがいた。彼は意気揚々とマイクロサービス移行という壮大な計画を立ち上げ、2年という歳月を費やした。しかし完成の暁に彼を待ち受けていたのは、栄光でも賞賛でもなく、すでに陳腐化した設計と、ふたたび着々と積み上がる技術的負債という名の瓦礫の山であった。なんたる業か。なんたる滑稽か。nwiizoによるこのセッション「技術的負債の泥沼から組織を救う3つの転換点」は、そのような哀れな魂たちへの救済の書である。2026年3月4日、Engineering Management Conference Japan 2026のホールBにて、40分間にわたり語られる。氏が説くに、モダナイゼーションの失敗とは技術の失敗にあらず。組織構造を軽視し、意思決定を技術者のみで完結させ、ビッグバン式の大改革に酔いしれた者たちが、コンウェイの法則という冷酷な摂理によって粛清される、それだけのことである。古い組織は、新しいシステムを確実に、かつ静かに、腐らせていく。ならばいかにすべきか。氏はAMETという概念を持ち出す。答えを与えるチームではなく、組織が自ら考えられるよう手助けし、最終的には己の存在意義を消滅させることを目標とするチームである。なんと殊勝な自己犠牲の精神であろうか。EventStormingやWardley Mappingを駆使し、組織の内なる知性を呼び覚ます。また、経営層に「技術的負債がやばい」と訴えても暖簾に腕押しであることは、諸君もよくご存知であろう。Core Domain Chartによって複雑性を可視化し、それを「年間XX億円の機会損失」という経営者の母語に翻訳してこそ、初めて投資という名の援軍を呼び込むことができるのだ。そして何より肝要なのは、壮大な計画を立てないことである。3〜6ヶ月で成果を示せる小さな戦場を選び、勝利を積み重ね、信頼を醸成していく。Team Topologiesを携え、技術・組織・文化を同時に変革していく。レガシーシステムという名の泥沼で溺れかけている諸氏よ、このセッションはあなた方のために存在する。書籍『アーキテクチャモダナイゼーション ―組織とビジネスの未来を設計する』は好評発売中です。https://amzn.to/3ZR5Bgv🔗 https://fortee.jp/emconf-2026/proposal/cd55bd21-d2ef-448c-af5c-e02f0994e4ae🔗 https://x.com/emconf_jp🔗 https://2026.emconf.jp/

技術的負債の泥沼から組織を救う3つの転換点

3-shake SRE Tech Talk 特別回「アーキテクチャモダナイゼーション」にて、「30分でわかるアーキテクチャモダナイゼーション」というタイトルで登壇しました。https://3-shake.connpass.com/event/382086/書籍『アーキテクチャモダナイゼーション ―組織とビジネスの未来を設計する』は好評発売中です。https://amzn.to/3ZR5Bgv同日に発表した「意志を実装するアーキテクチャモダナイゼーション」の資料も公開しています。https://speakerdeck.com/nwiizo/yi-zhi-woshi-zhuang-suruakitekutiyamodanaizesiyon

30分でわかるアーキテクチャモダナイゼーション

Developers Summit 2026（デブサミ2026）にて、「意志を実装するアーキテクチャモダナイゼーション」というタイトルで登壇しました。https://event.shoeisha.jp/devsumi/20260218/session/6454書籍『アーキテクチャモダナイゼーション ―組織とビジネスの未来を設計する』は好評発売中です。https://amzn.to/3ZR5Bgv同日に発表した「30分でわかるアーキテクチャモダナイゼーション」の資料も公開しています。https://speakerdeck.com/nwiizo/30fen-dewakaruakitekutiyamodanaizesiyon

意志を実装するアーキテクチャモダナイゼーション

2025年12月5日に「おい、テックブログを書け」という登壇をした。「おい」である。命令形である。30分間、人前に立って「書け」と言い続けるという、冷静に考えるとなかなか傲慢な振る舞いをしてきたわけだが、登壇資料を作っている最中、ふと気づいてしまった。書けと言っている自分は、なぜ書いているのだろうか、と。技術ブログを書くことについて語ろうとすると、それは私が「書いてきた」ことを晒すことに他ならず、AIとの付き合い方を語ろうとすると、それは私が「どう仕事をしているか」を開陳することと紙一重になる。そうなると聞いている側からすれば、こいつは結局、自分の話がしたいだけなのではないか、登壇という大義名分を得て気持ちよく自分語りをしているだけなのではないか、と思われても仕方がない。いや、実際そうなのかもしれない。そう見られることへの嫌悪感と、そう見られまいと振る舞う自分への嫌悪感が同時に存在していて、どちらに転んでも結局イヤなやつなのである。しかし登壇というのは厄介なもので、「書け」と命令するからには、自分がなぜ書いてきたのかを明かさなければ説得力がない。説得力のない登壇ほど空虚なものはない。空虚な登壇をする自分を想像して、それはそれで耐えられない。結局、自己開示から逃げられない構造になっている。なんという罠だろうか。身体性という言葉を使った。AIに記事を書かせることについて話した。私の答えは明確で、記事はほとんどAIに書かせている、しかし価値の源泉は私にある、と。私が素材を提供し、AIが構造化し、私がレビューして調整する。編集者としてのAI。この協働こそが現代の執筆だと、そう話した。話しながら、これは本当にそうだろうかと自分を疑う自分がいて、でもそういう迷いごと引き受けて喋るしかないのだった。まず自分のために書け、結果として、それが誰かを救う。そう締めくくった。https://forkwell.connpass.com/event/377267/https://syu-m-5151.hatenablog.com/archive/category/%E3%81%8A%E3%81%84%E3%80%81自宅からの昼登壇だったので、終わってから昼飯を食べに外に出た。参考書籍として紹介した本をもう一度読み返そうと思って、鞄に入れてきていた。店に向かう道すがら、本を開く。

おい、テックブログを書け

2025年9月30日（火）、「バイブコーディングもくもく会 #03」というイベントで登壇することになった。https://aimokumoku.connpass.com/event/368935/正直に言うと、このイベントがどんな空気感なのか、まだ全然掴めていない。ゆるい感じなのか、ガチな感じなのか。笑いを取りに行くべきなのか、真面目にやるべきなのか。そういう「場の空気」みたいなものが事前に分からないのは、けっこう怖い。だから、とりあえず色々なパターンを想定して準備している。要するに、どんな状況になっても対応できるように、という保険をかけまくっているのだ。我ながら、慎重すぎるかもしれない。ブログとGithubはこちら。https://syu-m-5151.hatenablog.com/https://github.com/nwiizo一応、置いておく。見られるのは恥ずかしいけど、見られないのも寂しい。そういう矛盾した感情を抱えながら、当日を迎えることになりそうだ。Marp の資料はこちらです。https://github.com/nwiizo/3shake-marp-templates/blob/main/slides/2025/vibe-coding-continuous-deployment.md

バイブコーディングと継続的デプロイメント

2025年9月10日（水）、「Rustの現場に学ぶ〜Webアプリの裏側からOS、人工衛星まで〜」というイベントで登壇させていただきます。https://findy.connpass.com/event/359456/他の登壇者の話が聞きたすぎるけど調整能力の圧倒的な不足で登壇したらすぐに帰らなければなりません。今回の発表内容のベースとなったのはこちらのブログです。- 「RustのWebアプリケーションにオブザーバビリティを実装するインフラエンジニアのための入門ガイド」

Webアプリケーションにオブザーバビリティを実装するRust入門ガイド

2025年9月5日（金）、台風接近という悪天候の中でしたが、「CNCJ: コーディングエージェント × セキュリティ ミートアップ」に登壇させていただきました。天候の影響で現地参加が難しい方も多い中、オンラインでの参加や配信により、多くの方にお聞きいただくことができました。### 📍 イベント情報- 開催日: 2025年9月5日（金）- イベント詳細: CNCFコミュニティページ### 📹 録画・資料公開予定- 録画: CNCJのYouTubeチャンネルにて後日公開予定- 発表資料: Connpassページに掲載予定### 📝 関連ブログ今回の発表内容のベースとなった考え方については、こちらのブログ記事でも詳しく解説しています：- 「2025年夏 AIエージェントシステムに対する考え方」台風の中、ご参加・ご視聴いただいた皆様、ありがとうございました。

2025年夏 コーディングエージェントを統べる者

「 転職したらMCPサーバーだった件」というタイトルで登壇したことがある。本日は「JAWS-UG SRE支部 #13 つよつよSREの秘伝のタレ」というなんとなく強そうなイベントで登壇しました。🔍 イベント詳細:- イベント名: JAWS-UG SRE支部 #13 つよつよSREの秘伝のタレ- 公式URL: https://jawsug-sre.connpass.com/event/358781/- ハッシュタグ: https://x.com/search?q=%23jawsug_sre&f=live- 参考資料①: https://speakerdeck.com/nwiizo/zhuan-zhi-sitaramcpsabadatutajian

転職したらAWS MCPサーバーだった件

諸君、聞かれよ。本日、私は「女オタ生成AIハッカソン2025夏東京」なる前代未聞の催しにて、生まれて初めて登壇することと相成った。かつての私は純朴なプログラマーであり、「変数名を30分悩んだ挙句、結局tmpにする」という、実に平凡な悩みを抱える程度の技術者であったのだ。歳月は容赦なく流れ、今や私はプロンプトエンジニアリングという名の魔境に足を踏み入れた哀れな求道者となり果てた。昨夜も丑三つ時まで、私は薄暗い書斎でディスプレイの冷たき光に照らされながら、「なぜ生成AIは『簡潔に』と百回唱えても、源氏物語の長文を生成するのか」という哲学的難題と格闘していたのである。30分という持ち時間に対し50枚のスライドを用意するという、まるで賽の河原で石を積む如き徒労に及んでいる。そのうち半分は「プロンプトという名の現代呪術における失敗例集」と題した、私の苦悩の結晶である。ああ、AIとの対話とは、かくも人間の正気を奪うものなのか。---ブログも書いた。生成AIで物語を書くためにプロンプトの制約や原則について学ぶ、という話をしてきました #女オタ生成AI部https://syu-m-5151.hatenablog.com/entry/2025/06/30/171149

生成AIで小説を書くためにプロンプトの制約や原則について学ぶ / prompt-engineering-for-ai-fiction 

僕がClaude Codeに初めて触れたのは、2025年の春だった。生成AIにはすでに慣れ親しんでいた。流行に乗り遅れてはいけないと必死に勉強し、エディターの補完機能やコード生成ツールとして日常的に活用していた。ただ、当時の僕にとってそれはまだ「CLIで動く便利なコーディング支援ツール」程度の認識でしかなかった。「AIが90%のコードを自動生成」という謳い文句を見ても、半信半疑でターミナルを開いたのを覚えている。イベント名:【オフライン開催】KAGのLT会 #6 〜御社のエンジニア育成どうしてる!? スペシャル〜公式URL: https://kddi-agile.connpass.com/event/357862/「実装」から「設計」へのパラダイムシフト というより無限に体力が必要という話をした https://syu-m-5151.hatenablog.com/entry/2025/06/19/102529【参考文献】  - 公式ドキュメント    - Claude Code 公式サイト https://www.anthropic.com/claude-code    - Claude Code ドキュメント https://docs.anthropic.com/en/docs/claude-code/overview    - Claude Code Best Practices https://www.anthropic.com/engineering/claude-code-best-practices    - 抽象化をするということ - 具体と抽象の往復を身につける https://speakerdeck.com/soudai/abstraction-and-concretization    - How I Use Claude Code https://spiess.dev/blog/how-i-use-claude-code    - LLMの制約を味方にする開発術 https://zenn.dev/hidenorigoto/articles/38b22a2ccbeac6    - Claude Code版Orchestratorで複雑なタスクをステップ実行する https://zenn.dev/mizchi/articles/claude-code-orchestrator    - Agentic Coding Recommendations https://lucumr.pocoo.org/2025/6/12/agentic-coding/    - Claude Codeに保守しやすいコードを書いてもらうための事前準備 https://www.memory-lovers.blog/entry/2025/06/12/074355    - Claude Codeによる技術的特異点を見届けろ https://zenn.dev/mizchi/articles/claude-code-singularity-point

Claude Code どこまでも/ Claude Code Everywhere

本日、Forkwell さんに悪ふざけに付き合ってもらってイベントやりました。ありがとうございます。「転職したらMCPサーバーだった件」 🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: 転職したらMCPサーバーだった件- 公式URL: https://forkwell.connpass.com/event/354289/- ハッシュタグ: https://x.com/search?q=%23Forkwell_MCP&f=live- 参考資料①: https://speakerdeck.com/nwiizo/kokohamcpnoye-ming-kemae- 参考資料②: https://syu-m-5151.hatenablog.com/entry/2025/03/09/020057- 参考資料③: https://speakerdeck.com/superbrothers/that-time-i-changed-jobs-as-a-kubernetes

転職したらMCPサーバーだった件

本日、「AI駆動開発実践の手引き -これが僕/私のAI（アイ）棒」というイベントで「ここはMCPの夜明けまえ」 🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: 【ハイブリッド開催】AI駆動開発実践の手引き -これが僕/私のAI（アイ）棒-- 公式URL: https://hack-at-delta.connpass.com/event/350588/📝 登壇ブログ- 2025年4月、AIとクラウドネイティブの交差点で語った2日間の記録 #CNDS2025 #hack_at_delta- https://syu-m-5151.hatenablog.com/entry/2025/04/24/113500

ここはMCPの夜明けまえ

こんにちは皆さん！本日はCloud Native Daysのプレイベントで登壇させていただきます。2019年以来の登壇となりますが、当時はまだ肩こりなんて無縁だったんですよね…。時の流れは容赦ないもので、最近の肩こりが辛くて昨日も整骨院に通ってきました。30分の持ち時間に対してスライドが80枚以上という暴挙にも出ています。---本日、「CloudNative Days Summer 2025 プレイベント」というイベントで「生成AIによるCloud Native 基盤構築の可能性と実践的ガードレールの敷設について」 🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: CloudNative Days Summer 2025 プレイベント- 公式URL:https://cloudnativedays.connpass.com/event/351211/ - イベントのURL: https://event.cloudnativedays.jp/cnds2025📝 登壇ブログ- 2025年4月、AIとクラウドネイティブの交差点で語った2日間の記録 #CNDS2025 #hack_at_delta- https://syu-m-5151.hatenablog.com/entry/2025/04/24/113500

生成AIによるCloud Native基盤構築の可能性と実践的ガードレールの敷設について

本日、「Kubernetesで実践する Platform Engineering - FL#88」というイベントで「Kubernetesで実現できるPlatform Engineering の現在地」🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: Kubernetesで実践する Platform Engineering - FL#88- 公式URL: https://forkwell.connpass.com/event/348104/🗣️ 関連スライド- インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて- https://speakerdeck.com/nwiizo/inhurawotukurutohadouiukotonanoka-aruihaplatform-engineeringnituite- Platform Engineeringは自由のめまい- https://speakerdeck.com/nwiizo/platform-engineeringhazi-you-nomemai

Kubernetesで実現できるPlatform Engineering の現在地

「Dapr の概念と実装から学ぶ Observability への招待」 というタイトルで登壇します。https://event.cloudnativedays.jp/o11y2022/talks/1382:embed:cite セッション概要Dapr は CloudNative な技術を背景に持つ分散アプリケーションランタイムです。本セッションでは Dapr の Observability に関する各種機能と、その実装について解説していきます。さらにスリーシェイクの Dapr と Observability への取り組みに関してもご紹介します。Dapr の機能でカバーできる点...

nwiizo

LSM-Tree: MemtableからCompactionまで自作する

トランザクション分離レベル: Write Skewを手で再現する

CRDT -- 結果整合性で「正しい」とは何か

Consistent Hashing -- 仮想ノードとキー分布の均等性

おい、要件を殺すな

Bloom Filter -- 確率的データ構造の理論と実践

Rust のホットリロード、2026年の現在地 — hot-lib-reloader / Dioxus / Leptos を実際に動かして比較した

ドメイン規約を lint で表現する — `Order` に `is_paid + payment_id` を共存させない

`rowan` で自家製 lint を書く — rust-analyzer の心臓部を流用する

31歳、もちろん俺らは抵抗するで？筋肉で

コンパイル時に未設定フィールドを禁止する type-state builder

自分のクレート外の型にメソッドを生やす — extension trait と sealed pattern

`lazy_static!` はもういらない — `LazyLock` と `OnceLock` の使い分け

`Cow<'_, T>` で「変更が必要なときだけ allocate する」

newtype と `PhantomData` で「混ぜたら型エラー」を作る

おい、要件を動くものにしろ

`NonZero<T>` で「ゼロではない」を型に乗せる

`thiserror` と `#[non_exhaustive]` で SemVer に強いエラー型を作る

`if let` chain — Rust 1.88 / 2024 edition で実用フェーズに入った

`let-else` で早期 return を素直に書く

`unwrap()` を書きそうになったときの選択肢8つ

おい、要件を言葉にしろ

OWASP ZAP の finding を Rust/Axum の handler に戻して直す

おい、夢は持たなくてもよいけど、失敗はしろ

Argo CD ApplicationSet で PR preview の構成を Kind 上で検証した

システムは「動く」だけでは足りない実装編 - 非機能要件・分散システム・トレードオフをコードで見る

翻訳者がいるから、共通言語は整備されない - Architecture for Flow の読書感想文

システムは「動く」だけでは足りない - 非機能要件・分散システム・トレードオフの基礎

アーキテクチャモダナイゼーションとは何か

おい、夢を持たなくても良いぞ

Neovim 0.12 リリース内容まとめ

LLM に足りないのは能力ではない。あなたの事情だ

LSM-Tree: MemtableからCompactionまで自作する

トランザクション分離レベル: Write Skewを手で再現する

CRDT -- 結果整合性で「正しい」とは何か

Consistent Hashing -- 仮想ノードとキー分布の均等性

おい、要件を殺すな

Bloom Filter -- 確率的データ構造の理論と実践

Rust のホットリロード、2026年の現在地 — hot-lib-reloader / Dioxus / Leptos を実際に動かして比較した

ドメイン規約を lint で表現する — `Order` に `is_paid + payment_id` を共存させない

`rowan` で自家製 lint を書く — rust-analyzer の心臓部を流用する

31歳、もちろん俺らは抵抗するで？筋肉で

コンパイル時に未設定フィールドを禁止する type-state builder

自分のクレート外の型にメソッドを生やす — extension trait と sealed pattern

`lazy_static!` はもういらない — `LazyLock` と `OnceLock` の使い分け

`Cow<'_, T>` で「変更が必要なときだけ allocate する」

newtype と `PhantomData` で「混ぜたら型エラー」を作る

おい、要件を動くものにしろ

`NonZero<T>` で「ゼロではない」を型に乗せる

`thiserror` と `#[non_exhaustive]` で SemVer に強いエラー型を作る

`if let` chain — Rust 1.88 / 2024 edition で実用フェーズに入った

`let-else` で早期 return を素直に書く

`unwrap()` を書きそうになったときの選択肢8つ

おい、要件を言葉にしろ

OWASP ZAP の finding を Rust/Axum の handler に戻して直す

おい、夢は持たなくてもよいけど、失敗はしろ

Argo CD ApplicationSet で PR preview の構成を Kind 上で検証した

システムは「動く」だけでは足りない 実装編 - 非機能要件・分散システム・トレードオフをコードで見る

翻訳者がいるから、共通言語は整備されない - Architecture for Flow の読書感想文

システムは「動く」だけでは 足りない - 非機能要件・分散システム・トレードオフの基礎

アーキテクチャモダナイゼーションとは何か

おい、夢を持たなくても良いぞ

Neovim 0.12 リリース内容まとめ

LLM に足りないのは能力ではない。あなたの事情だ

システムは「動く」だけでは足りない実装編 - 非機能要件・分散システム・トレードオフをコードで見る

システムは「動く」だけでは足りない - 非機能要件・分散システム・トレードオフの基礎