nwiizo

はじめに 金曜の夜だった。10個のコミットを git rebase -i で並べ替えていた。4個目で衝突した。慌てて解決したが、解決を間違えた。git rebase --abort で巻き戻し、最初からやり直す。2回目はもっと雑になり、3回目で reflog を漁ってコミットを拾い直した。本番でもチームのリポジトリでもない。自分のローカルブランチを、自分一人で壊していた。 この冷や汗には覚えがある。git を10年触っていても消えない。いつ上達するんだ。毎回調べている気がするし雰囲気で触っている。怖いのは衝突そのものではない。衝突が起きた瞬間、リポジトリが「途中の状態」で固まり、間違えるとやり…

git を捨てずに、git の手前に立つ - Jujutsu (jj) の概念と、乗り換えの損益分岐点

はじめに またバズワードが来たな。 2026年6月、「ループエンジニアリング」という言葉でタイムラインが埋まった。 プロンプト、コンテキスト、ハーネス。半年ごとに、新しい看板が立つ。 号令はこうだ。Peter Steinbergerが「コーディングエージェントにプロンプトを書くのはもうやめろ。エージェントにプロンプトを書くループを設計しろ」と書いた。Claude Codeを率いるBoris Chernyも、「私はもうClaudeにプロンプトを書かない。ループが走っていて、それがClaudeにプロンプトを書く」と続けた。 ところが、その号令が流れてきた朝、私はちょうどKubernetesのコント…

ループエンジニアリングは、サイバネティクスの再発見だ

作れる。速く作れる。だが、作るとは、未来へ債務を発行することだ。 読み終えてから、1つの言い換えが頭から離れませんでした。作ることは、完了する動詞ではない。作った瞬間に「維持する・確認し続ける・説明し続ける・責任を取り続ける」という義務を、未来に対して発行している。リリースは一瞬で、支払いはそのあとずっと続く。私はキャリアのほとんどを「作れるか」「速く作れるか」に注ぎ、その発行し続けた債務を、同じ熱量で見積もってはきませんでした。胃のあたりは、いまも少し重い。 Susanne Kaiser 著『Architecture for Flow: Adaptive Systems with Domai…

創造は、未来への債務の発行である - Architecture for Flow の読書感想文

はじめに 手を貸した相手から、礼の一言もなかった。挨拶も、なかった。 腹は立たなかった。立たなかったことのほうが、あとから効いた。 困ったらAIに任せればいい。あの人とやり直さなくても、仕事は回る。 そう思った瞬間は、合理的な判断のつもりだった。本人には言わない。優しくないし、自分が可愛い。怒るほど子供ではないが、聞き流せるほど器も大きくない。残ったのは、小さな違和感だけだった。 その違和感を持て余しているうちに、嫌な予感がした。これ、自分も誰かにやっているんじゃないか。それより怖いのは——自分には、もう誰も注意してくれないんじゃないか、ということだ。 この話は、結論だけなら一行で済みます。で…

おい、挨拶をしろ

はじめに この記事では、avante.nvim の ACP 実装を読んでいきます。 github.com 結論から言うと、avante.nvim の ACP 実装は「stdio JSON-RPC client」です。Agent 固有の provider 実装ではありません。 provider 名で acp_providers を引き、adapter process を起動します。その後に ACP の initialize、session/new、session/load、session/prompt を送ります。返ってきた session/update は avante の history と…

avante.nvim は ACP Client として何をしているのか

はじめに avante.nvim を Copilot 経由で使っていた。 github.com avante.nvim は、Neovim の中に AI チャットとコード編集の UI を足す plugin だ。どの AI につなぐかは provider という設定で選ぶ。 それはそれで動きます。GitHub Copilot の認証に乗れるし、Neovim の中から質問や編集を投げられる。けれど、Claude Code や Codex CLI を日常的に使っていると、少しずつ違和感が出てきました。 syu-m-5151.hatenablog.com ターミナルでは Claude Code や Co…

ACP は provider ではなく、エディタと Agent の境界である

はじめに AIに雛形を頼んだら、数秒で、過不足のないコードが返ってきた。 助かったはずなのに、手が止まった。 何かを、取り上げられた気がした。 このコードは、僕が書くはずだった。書かなくてよくなった。それの何が不満なんだ、と自分でも思う。雛形も、調査も、よくあるバグ取りも、頼めば一瞬で返ってくる。口では「助かる」と言う。なのに、好きだったはずの何かが、静かに手元からこぼれていく。たぶん、僕だけではない。 「プログラミングを愛する」とは、これからどういう意味になるのか。 意外かもしれないが、この問いには國分功一郎氏『暇と退屈の倫理学』がよく効く。退屈と暇をめぐるこの本は、突き詰めれば「人は何を愛…

私がAI時代に「プログラミングを愛する」ということ

はじめに 決済APIにリクエストを投げた。3秒待っても応答がない。タイムアウト。 クライアントがリトライした。結果、数十件の二重課金が起きた。 発覚したのは、翌朝のカスタマーサポートへの問い合わせラッシュだった。 ネットワークタイムアウトの曖昧さ ログを突き合わせ、同一注文IDに対する重複トランザクションを洗い出す作業に半日かかった。決済APIでこの状況に遭遇すると、胃が痛くなる。 サーバー側で処理が完了しているなら、リトライは二重課金を引き起こす。完了していないなら、リトライしなければ注文が宙に浮く。タイムアウトは成功とも失敗とも言えない。この曖昧さこそ、分散システムにおける厄介な問題だ。 …

冪等性キー: リトライで二重処理を防ぐ仕組み

はじめに コンシューマを再起動した翌朝、ダッシュボードの数値が跳ね上がっていた。 バグを疑った。半日追ってから、processing time集計がバックログの再処理で壊れただけだとわかった。 event timeとprocessing time。同じ時刻ではない。 2つの時刻 ストリーム処理で最初にぶつかる壁は、「時間」が1つではないという事実だ。 イベントが実際に発生した時刻（event time）と、システムがそれを受信した時刻（processing time）。この2つは一致しない。ネットワークに遅延がある限り、processing timeはevent timeより後になる。問題は、…

Watermark: ストリーム処理における時間の扱い方

はじめに 個々のバックエンドのp99は10msで安定していた。 APIゲートウェイのp99だけが、それを大きく超えていた。 計測はできていた。fan-outの確率的増幅が原因だと気づくまでに、数週間かかった。 「p99が10msだから大丈夫」という誤解 レイテンシの議論で「p99は10msです」と言われると、ほとんどの人が安心する。99%のリクエストが10ms以内に返ってくるなら十分に高速だ、と。p50は中央値、p99は遅い側から1%の位置、p99.9はさらに尾の0.1%の位置、というパーセンタイル表記だ。 この認識は、1台のサーバーに1つのリクエストを投げて1つのレスポンスを待つモデルでは正…

Tail Latency: fan-outが尾部遅延を増幅する数理

はじめに ノードAとBのログを、タイムスタンプでソートした。 因果関係が、平然と逆転していた。 50msのNTPずれで、秒間数千リクエストのシステムでは数百のイベントが入れ替わる。物理時計は嘘をつく。 物理時計は嘘をつく ここでいう「時計」は、腕時計やサーバーの現在時刻だけを指していない。分散システムでは、イベントの前後関係を記録するための番号も「時計」として扱う。人間に見せる時刻ではなく、システムが「どちらが先に起きたか」を判断するための道具だ。 分散システムの時刻同期にNTPを使うのは当たり前だが、NTPが保証するのは「だいたい合っている」程度の精度だ。LAN内でも数ミリ秒、WAN越しなら…

論理時計: Lamport Clock, Vector Clock, HLC の比較実装

はじめに 「このロック、リースが切れたらどうなるんですか？」 デザインレビューで聞いた。分散ロックを取った後、リモートAPIを叩いてからリソースに書き込むジョブスケジューラの設計だった。 設計者と自分は、その先の答えを持っていなかった。 死んでいるのにリーダーだと思い込む 分散システムでリーダー選出やリソース排他制御にリース（有効期限付きロック）を使うのは一般的だ。「N秒だけロックを保持できる」「期限が来たら他のノードが取り直せる」というのが基本動作で、ZooKeeperやetcdが提供している。問題は、リースを取得したノードがGCポーズ（JVMなどで数百msから秒単位の処理停止が起きる現象）…

Fencing Token: 分散リースの安全な失効と防御

はじめに シェルスクリプト2行で、データベースが書ける。書き込みはO(1)、これ以上速くならない。 10億行になった瞬間、読み取りが破綻する。grepが全行を舐めて死ぬ。 RocksDBのソースには、Memtable、SSTable、Compactionが並ぶ。読むより、書いて確かめる方が早かった。 github.com Append-onlyログの限界 最も素朴なデータベースはシェルスクリプト2行で書ける。 db_set() { echo "$1,$2" >> database; } db_get() { grep "^$1," database | tail -1 | sed 's/^[^…

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

はじめに PostgreSQLのREPEATABLE READは、Snapshot Isolationだ。 MySQLのREPEATABLE READは、それと違う何かだ。同じ言葉が、異なる挙動を指す。 ドキュメントを読むのをやめた。自分でMVCCストアを書き、各異常を手で再現することにした。 www.cockroachlabs.com ACIDのCは「マーケティング用語」 ACIDは、データベースのトランザクションを説明するときによく出てくる4文字の略語だ。Atomicity、Consistency、Isolation、Durabilityの頭文字を取っている。 ACID特性の中で、Cons…

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

はじめに マルチリーダーで、同じキーに同時書き込みが起きた。どちらの値が「正しい」のか。 「コンフリクトが起き得ないデータ構造」という言葉を、最初に読んだとき魔法に聞こえた。 実装した。魔法ではなく、数学だった。そしてそれには代償があった。 en.wikipedia.org コンフリクトという根本問題 分散システムでデータを複数ノードへ書き込めるようにすると、コンフリクトが起きる。マルチリーダーレプリケーションでも、リーダーレスレプリケーションでも、同じキーへ異なる値を書き込む瞬間は避けられない。ネットワーク分断の最中に2つのノードが同じドキュメントを編集した。分断が解消されたとき、どちらの値…

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

はじめに キャッシュクラスタへノードを足すたびにヒット率が壊滅する。最初にこの問題へ出会ったのは、memcachedクラスタのスケーリングを調べていたときだった。hash(key) % Nの何が悪いのか、当時は正直よくわからなかった。実装して計測してみると、問題の大きさが数字で見える。 hash(key) % N の問題 分散システムでデータを複数ノードに振り分ける最も素朴な方法は hash(key) % N だ。Nノードに対してキーが一様に分散し、実装も簡単。 だが、ノードを1つ追加すると何が起きるか。N=4からN=5に変えると、hash(key) % 4 と hash(key) % 5 は…

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

はじめに 書き終えた要件は、書き終えた瞬間から古び始める。 古びた要件と新しい要件を、AIは同列に扱う。「置き換え済み」と書いた印は、AIにとってはただの文字列でしかない。 要件を言葉にする話を第1部で、要件を動くものに散らす話を第2部で書いてきました。発見し、言葉にし、コードと型とテストに焼き込む。ここまでで、要件はようやく実装の現場で動き始めます。 第1部で扱ったのは「書かれずに死ぬ要件」、第2部で扱ったのは「書かれたまま読まれずに死ぬ要件」でした。第3部で扱うのは、最後の死、書かれて動いていたのに時間に殺される要件です。 syu-m-5151.hatenablog.com syu-m-5…

おい、要件を殺すな

はじめに RocksDBのソースを読んでいて、SSTableごとにBloom filterが挟まっている箇所に出くわした。概念は知っていたが、パラメータの導出を自分で追ったことはなかった。数式を眺めるだけでは全然理解できない悲しい子なので、Rustでゼロから書いて理論値と実測値を突き合わせることにした。結果として、ハッシュ関数の設計で半日つまずくことになる。 「ないもの」を探すコスト データベースに対する読み取りの大半は、存在しないキーへのアクセスだったりする。LSM-treeベースのストレージエンジンでは、この問題が顕著になる。Memtableにない、最新のSSTableにない、その前のSS…

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

はじめに 「Rust はコンパイルが遅いから」。技術選定の議論で、私はこの一言で打ち切られたことが何度かある。性能でも安全性でもなく、開発時のフィードバックループの遅さだ。コードを書いて保存したら画面に反映される、というサイクルが Rust にはない、と。 数年前ならその通りだと頷いていた。2026年5月現在、それはもう正確ではない。少なくとも、そう反論できる材料が3つは揃っている。 hot-lib-reloader (v0.8.2) — 動的ライブラリ（dylib）を実行中のプロセスに差し替える汎用的なアプローチ Dioxus (v0.7.4) — RSX テンプレートのパッチ＋ Subse…

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

はじめに 長年、動いた DB を覗くと、たいていこういうレコードが眠っています。 { "order_id": 12345, "is_paid": true, "payment_id": null } is_paid = true なのに payment_id は null。 ドメイン上、 同時に成立してはいけない組み合わせ が静かに残り、数ヶ月後の返金処理で例外を出します。 今後 「型で illegal state を表現不能にする」みたいな発表をします 。 そしてその前の記事で書いた 「rowan で自家製 lint を書く」 は、 cargo check に乗らない規約をコードで強制する話…

ドメイン規約を 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 には #…

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

はじめに ※この筋肉はイメージであり現実の肉体とは乖離がある場合があります。 ある誕生日の朝、通知が、なかった。 母親からだけ、メッセージが来ていた気がする。 俺の人生はLINEの量で決まるかと嘯きながら、LINEの誕生日表示を非公開にした。20代の、どこかの誕生日だったと思う。 そして、31歳になった。独身。家族と住んでもいない。そういう男を、誰も守ってはくれない。LINEはくれないが友人のような人たちも、給料はくれるが人生の責任は取らない会社も、ドラフトはくれるが長期の成長までは背負わないAIも、最後のところでは助けに来ない。自分ぐらいは、自分で守る。残された守り方は、筋肉だった。 念のた…

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

はじめに Builder パターンで「url を設定する前に build() を呼んでしまった」事故を、 コンパイルエラーで止める 書き方があります。type-state pattern と呼ばれています。PhantomData を使って builder の進捗状態を型に乗せる、 Rust 固有の idiom です。 ランタイムオーバーヘッドはゼロ。PhantomData はサイズ 0 で、コンパイル時にしか存在しません。 まず動くコード use std::marker::PhantomData; #[derive(Debug)] pub struct Missing; #[derive…

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

はじめに 「String に独自メソッドを追加したい」「外部クレートの型に1メソッドだけ生やしたい」場面があります。Rust の orphan rule のせいで、外部クレートの型に外部クレートのトレイトを直接実装するのは無理です。代わりに 自分のトレイトを定義して、その型に対する impl を書く のが extension trait パターンです。 doc.rust-lang.org さらに sealed trait pattern を組み合わせると、「このトレイトは外部から実装できない」ことを保証できます。公開 API の進化を破壊的変更にしないための小技です。 まず動くコード Stri…

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

はじめに Rust で「グローバル変数を遅延初期化したい」となったとき、長らく lazy_static! クレートが定番でした。今 (2026年) はもう不要です。標準ライブラリの LazyLock (1.80+) と OnceLock (1.70+) で全部書けます。マクロや外部依存も要りません。 ただし MSRV (最小サポート Rust バージョン) を 1.80 未満で固定しているプロジェクトは、当面 lazy_static! のままでよいです。本記事は新規プロジェクトと、MSRV を引き上げる余地のあるコードベースを対象にしています。 両者は似ていますが用途が違います。この記事ではど…

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

はじめに 入力をそのまま返すか、一部書き換えてから返すか、関数の中で判定する場面があります。素直に書くと「変更しない場合も無駄に String::clone() してしまう」、または「&str を返したいが、変更があった時は所有データを返したい」というジレンマに陥ります。 std::borrow::Cow (Clone-On-Write) はこのジレンマを解きます。借用 (Borrowed) と所有 (Owned) のどちらかを選んで返せる enum で、「必要になるまで allocate しない」が型で表現できます。 doc.rust-lang.org まず動くコード 「すでに…

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

はじめに UserId と OrderId を取り違えてバグを生み出す経験は、String で識別子を扱っていれば誰しもあります。Rust では newtype で別の型に分けるだけで、コンパイラに止めてもらえます。さらに PhantomData を組み合わせれば、「JPY と USD を足し算する」のような単位ミスも型エラーにできます。 ランタイムコストはゼロ。型情報はコンパイル後に消えます。 newtype の基本 newtype は「struct でラップして、別の型として扱う」だけのパターンです。 #[derive(Debug, Clone, PartialEq, Eq, Hash)]…

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

はじめに ドキュメントは、書いた瞬間から腐っていく。 読まれない。検証されない。更新されない。それでも、要件と呼ばれ続けている。 第1部では、要件を言葉にする規律について書きました。引き出し、観察し、ジョブを見極めながら、業務領域の言葉で書く。6つの特性を満たし、検証可能な形にする。揺らぎと固執を組み込んで、自分たちの色を要件に乗せる。 そこまでやって、初めて要件文が立ち上がります。ただ、立ち上がっただけでは足りないのだと、最近は思うようになりました。 第1部で扱ったのは「書かれずに死ぬ要件」でした。第2部で扱うのは、もう一段先の死、書かれたのに読まれずに死ぬ要件です。気づいたときには、ドキュ…

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

はじめに ゼロ割り、ゼロサイズ確保、ゼロインデックス。「ゼロでない数値」を期待する場面はあちこちにあります。これを runtime チェックではなく 型 で保証できる仕組みが NonZero です。 Rust 2024 edition で書き味がさらに素直になりました。これまでは NonZeroUsize, NonZeroU32 のように個別の型名を使っていました。それがジェネリック表記の NonZero, NonZero に統一されています。Rust 1.79 で NonZero が安定化し、2024 edition では標準的な書き方になりました。 まず…

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

はじめに Rust で「ライブラリのエラー型をどう設計するか」は永遠のテーマです。素朴な答えは2つあります。 アプリケーションなら anyhow で済ませる ライブラリなら thiserror で型付きエラーを返す これは2026年でも変わりません。この記事は「ライブラリ向け」のほうの設計を、 #[non_exhaustive] を組み合わせて SemVer 互換を壊さない形で書く方法を扱います。 まず動くコード use std::num::ParseIntError; #[derive(Debug, thiserror::Error)] #[non_exhaustive] pub enum …

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

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

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

ソフトウェアエンジニアの仕事を、「コードを書く人」ではなく「何を守るかを決める人」の部分を紹介した発表です。非機能要件、分散システム、トレードオフを題材に、速さ、正しさ、止まりにくさが引っ張り合うなかで、日々どう判断しているのかをできるだけ身近な例で話しました。技術の基礎を知るための資料でありながら、この仕事そのものの面白さに触れてもらうための発表でもあります。唯一の問題は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

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

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

【社内勉強会】新年度からコーディングエージェントを使いこなす - 構造と制約で引き出す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

git を捨てずに、git の手前に立つ - Jujutsu (jj) の概念と、乗り換えの損益分岐点

ループエンジニアリングは、サイバネティクスの再発見だ

創造は、未来への債務の発行である - Architecture for Flow の読書感想文

おい、挨拶をしろ

avante.nvim は ACP Client として何をしているのか

ACP は provider ではなく、エディタと Agent の境界である

私がAI時代に「プログラミングを愛する」ということ

冪等性キー: リトライで二重処理を防ぐ仕組み

Watermark: ストリーム処理における時間の扱い方

Tail Latency: fan-outが尾部遅延を増幅する数理

論理時計: Lamport Clock, Vector Clock, HLC の比較実装

Fencing Token: 分散リースの安全な失効と防御

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 に強いエラー型を作る

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

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

git を捨てずに、git の手前に立つ - Jujutsu (jj) の概念と、乗り換えの損益分岐点

ループエンジニアリングは、サイバネティクスの再発見だ

創造は、未来への債務の発行である - Architecture for Flow の読書感想文

おい、挨拶をしろ

avante.nvim は ACP Client として何をしているのか

ACP は provider ではなく、エディタと Agent の境界である

私がAI時代に「プログラミングを愛する」ということ

冪等性キー: リトライで二重処理を防ぐ仕組み

Watermark: ストリーム処理における時間の扱い方

Tail Latency: fan-outが尾部遅延を増幅する数理

論理時計: Lamport Clock, Vector Clock, HLC の比較実装

Fencing Token: 分散リースの安全な失効と防御

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 に強いエラー型を作る

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

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

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

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