nwiizo

生成AIによって開発者の指は光の速さで動いている。なのに、リリースは相変わらず「来期のどこか」。では、犯人は AI なのか？ AI がコードを爆速で吐き出したあと、その成果物が「PdM 待ち」「デザイン待ち」「QA 待ち」「法務待ち」「偉い人の気分待ち」という職能ごとの待合室を巡り、気づいたら実装時間の10倍を待ち時間に費やしている——そんな光景に見覚えのある方、全員がこのスライドの対象読者です。本資料では「実装が速くなるほど、職能の壁がボトルネックとして浮き彫りになる」という不都合な真実を直視し、役割の境界線をなぞるのではなく、価値が流れる経路そのものを設計するという発想でプロダクト開発を組み立て直す方法を語ります。なお登壇者の nwiizo は、ネット上では「常に何かを読んでいる怖そうな人」として認識されているようですが、実物はめっぽう気さくで、話しかければ普通に喜びます。パブリックイメージと実装の間にギャップがあるのは、プロダクトや組織だけではないようです。📍 Product Engineering Conference 2026 https://product-engineering.jp/2026/ 登壇資料

AIで実装は速くなった。なのにプロダクトは速くならない。職能の壁を越えて価値のフローを設計する

syu-m-5151.hatenablog.com はじめに 一年で、こんなに価値観が変わるとは思っていませんでした。 私は「技術力に優劣はある」という記事で、技術との向き合い方を「道具として使う」「理解する」「創る」に分け、それぞれの中にも上手下手があると書きました。市場はその差を評価する。学びを続けた人ほど選択肢が広がる。コミュニケーションが得意でも、技術を学ばなくてよい理由にはならない。この主張は今も間違っているとは思いません。 エンジニアのキャリア地図 「技術」と「やりたいこと」から見つける最適解作者:サカモトソシムAmazon その記事を書いた時にも、AIコーディングエージェントはあ…

技術力に優劣はない(「技術力に優劣はある(「技術力に優劣はない」を読んで)」を読んで)

はじめに 私たちは、明確なゴールを決めずにコードを書き始めていた。 書いて、動かして、また直した。 AIエージェントを使う今、それは過去の話ではない。 コードから考え始めることには、もっともな理由があります。動くものがあれば話は具体的になり、間違いにも早く気づけます。AIエージェントは、このやり方をさらにやりやすくしました。曖昧な依頼からでも、画面、API、テストまで一息に作れます。 ただし、速くなったのはコードだけではありません。検討中の案、採用した要求、実装条件を区別しないまま、誰かの要望が動くソフトウェアへ変わる速度も上がりました。完成したコードから、「なぜ作るのか」「誰が何を達成するの…

AI時代のソフトウェア要求 - Software Requirements Essentialsの読書感想文

はじめに Suikoは、日本語文書の自然さと読みやすさを、再現可能なルールで診断するRust製のCLIです。禁止語や翻訳調に加え、均一な文のリズム、段落構造、用語の初出、読解負荷まで確認できます。ただし、文章がAIによって書かれたかは判定しません。怪しい箇所を同じ条件で指し示し、直すか残すかの判断を人間やエージェントへ返します。 github.com Suikoの出発点は、cojiさんのNatural Japaneseです。このAgent Skillは、文章を書く前の設計、書くときの制約、書いた後の検査を一体として扱います。定型句を置換するだけで終わらず、機械が疑いを検出し、文脈を読める人間や…

Rustで日本語推敲CLI/Skillの「Suiko」を作りました

このたび、はじめてマイナビ出版様より翻訳書を出版させていただくことになりました。原書は『Effective Platform Engineering』、邦題は『実践 プラットフォームエンジニアリング』です。発売日は2026年8月24日、いよいよ来週です。ぜひご予約いただけると嬉しいです。https://book.mynavi.jp/ec/products/detail/id=151794https://amzn.asia/d/0d4hfBcxこれに合わせて、「『実践 プラットフォームエンジニアリング』翻訳者と考える、開発者体験を加速する基盤のセルフサービス化」というイベントに登壇させていただきます。いつも機会をくださる Findy 様には感謝しています。セッションタイトルは「35分でわかるEffective Platform Engineering」です。書籍を読む際のガイドラインとして機能する内容になればと思っています。

35分でわかるEffective Platform Engineering

はじめに 2025年3月、私はTerraformをMCP経由で操作するツールtfmcpを開発しました。JSON-RPCのメッセージ型、標準入出力のトランスポート層、メソッドの振り分けまで、すべてRustで実装しています。当時の記事では「MCPの動作原理を理解するため、あえて配線を自分の手で組み立てた」と書きました。正直に言えば、当時は利用できるライブラリがなく、自作するほかなかったのです。 syu-m-5151.hatenablog.com それからMCPは何度も更新されました。2026年7月28日版では、プロトコルセッションと初期化ハンドシェイクがなくなりました。代わって、server/di…

RMCP 3.0でtfmcpをMCP 2026-07-28へ移行した

はじめに Topcoatは、HTMLをサーバーで生成しながら、ブラウザ上の状態更新やサーバー処理もRustで記述するフルスタックフレームワークです。フロントエンド用のディレクトリやnpmを用意せず、1つのRustファイルから動きます。2026年7月に発表された0.5.0を検証しました。 サーバーサイドレンダリング、部分的な反応、セッションの転送層までは任せられます。認証、マイグレーション、運用はアプリケーション側に残ります。この記事は、その境界を1つずつ確認した記録です。 github.com tokio.rs SSRとルーティングは1ファイルで済む Rust 1.95以上を用意し、Topco…

TopcoatでRustフルスタック開発

はじめに よい名前ほど、間違いに気づきにくい。 fetch_userが利用者を作って返しても、読み手は取得だと思ったまま先へ進める。 詰まらずに読めたことが、最初の誤りになる。 customer、account、member、user。生成AIへ名前の候補を求めると、文脈や規約を追加しない限り、どれも自然な候補として並びやすい。契約主体とログイン主体と請求先が別のものでも、同じ顔をして並ぶ。 識別子として置き換えるだけで、型や処理が同じなら、4つのうちどれを選んでもコードは動く。特段の取り決めがなければレビューも通る。名前が嘘になるのは、契約は生きているがログインは止まっている利用者が現れた日…

AIの「自然な名前」が、概念の境界を消す

はじめに 「Rustでclone()を呼べば、値は別物として複製される」。 String::clone()で得た直観を、そのままArcへ持ち込むと、この説明に行き着く。けれど、Arc::clone()が増やすのは同じ割り当てを指す共有所有者であり、Tそのものを別の値として複製するわけではない。 use std::sync::{Arc, Mutex}; fn main() { let original = Arc::new(Mutex::new(vec![1])); let cloned = Arc::clone(&original); assert!(Arc::ptr_eq(&origi…

訂正した誤りが、組織で再発する理由

2026年8月7日に『セキュアAPI』翻訳者と考える、設計段階から組み込むセキュリティ というイベントで登壇します。https://levtechlab.connpass.com/event/399260/

20分でわかるセキュアAPI

はじめに 以前、私はデータベースのトランザクションを「銀行振込」と捉えていました。送金元の残高を減らし、通知用の外部APIを呼び、送金先の残高を増やす。最後の更新に失敗しても、トランザクションをロールバックすれば元に戻るので、これで安全だと思っていました。 しかし、ロールバックできるのはデータベースの変更です。すでに外部APIが送った通知は取り消せません。私はトランザクションの仕組みをまったく理解していなかったわけではありません。データベースが保証する範囲と、利用者から見た「送金」という操作の範囲を、同じものとして扱っていました。 所有権を「本の貸し借り」、非同期処理を「料理」、キャッシュを「…

分かりやすい説明ほど、反例で確かめる

はじめに 最初から完璧な成果物は存在しない。 ただ出して、直して、また出した人がいるだけだ。私の場合、それが29本の「おい、」だった。 「おい、」シリーズは、形にならなかった本の原稿から始まりました。本を出せなかったときは、やはり少し絶望しました。それでも、書きかけの原稿まで消えたわけではありません。1冊へまとめず、原稿を1本ずつブログとして終わらせました。 最初から上手に書けるわけではありません。書き始めた頃の文章は、普通に不格好です。不格好なものを外へ出せば、ある程度はバカにもされます。ここは、たぶん避けられません。 ところが、1年も続けていると、だいたいの人は飽きます。批判が減る。ありが…

形にならなかった「おい、」を29回書いたら本

はじめに CodexやClaude Codeに作業を任せ、その間にNeovimで別のコードを編集します。これは便利です。しかし、エージェントの状態を確かめるたびに端末を順に開き、止まっていればそこで返事をします。これを繰り返すうちに、Neovimよりターミナルを見ている時間が長くなります。 正直に言えば、効率だけの問題ではありません。私は、自分の手に馴染む開発環境を自分で育てることを、PDE（Personal Development Environment）として続けてきました。エージェントが増えても、コードを読み書きする場所をNeovimから端末へ移す理由はありません。作業を任せたエージェン…

ターミナルを占領するのは許さないよ、Neovimですべて管理する

はじめに Neovimでコードを読んでいるとき、やりたいのはCodexをsplitで開くことではありません。開いているファイルや選択範囲を正確に渡し、会話を残したまま編集へ戻ることです。codex.nvimは、その往復を短くするためのNeovimプラグインです。 github.com このツールが必要になる場面 codex.nvimで解決したい課題は、次のとおりです。 Neovimでコードを読んだり選んだりしているとき、ファイルや範囲を説明し直さずCodexへ正確に渡し、会話を残したまま編集へ戻りたい。そうすれば、エディタとagentの間を往復するたびに作業の前提を組み立て直さずに済む。 Co…

 Codex CLIをNeovimで使うcodex.nvimを作ったので、使ってみてほしい

はじめに 生成されたコードを、十分に読まずにマージした。 障害は起きなかった。原因を半日追うような挙動も、出なかった。 払っていることに気づいたのは、ずっとあとだった。 壊れてくれるなら、まだ分かりやすかったのだと思う。実際に起きたのは、どの変更も動いていて、どの変更も少しだけ説明できない、という状態がゆっくり広がることだった。一つずつなら思い出せる。並べると、なぜこの形なのかを言える範囲だけが減っていく。ある日リポジトリを開いて、自分が説明できない側のほうが多いことに気づく。コードベースは、いつのまにか広大になっている。 要約は読んでいた。「入力を検証し、データを保存し、結果を返す」。その説…

テストが通ったあと、理解はどこに残るのか

はじめに 個々の関数は読める。使われている概念も知っている。 それなのに、値の変化と呼び出し順と失敗時の戻り方を一緒に動かそうとすると、前に見た関係が抜け落ちていく。 足りないのは、たぶん理解力ではない。 同じ関数をもう一度開く。さっき確かめたはずの分岐を、もう一度目で追う。追っているあいだに、その前に確かめた状態のほうが消える。長いコードを前にして私が感じるのは難しさというより、この往復である。 この状態で説明を増やしても、必ずしも楽にはならない。情報が足りないのではなく、考えるために一時的に保持できる量を超えているからだ。 生成AIは私より長いコードを一度に受け取り、関係を要約できる。扱え…

頭に入らないなら、関係を外へ出す

はじめに 生成させたRustのコードはコンパイルを通り、小さな入力を使うテストも通った。 use std::io::{self, Read}; fn read_stream(mut input: impl Read) -> io::Result> { let mut bytes = Vec::new(); input.read_to_end(&mut bytes)?; Ok(bytes) } unsafe はない。借用規則にも違反していない。それでも、この関数には入力の上限がない。read_to_end はEOFまで読み込んだ内容をVecへ追加する。入力が大きければメモリを使い…

忘れてもいい知識、忘れると気づけない知識

はじめに 知らない名前があれば止まり、呼び出し先を開く。そこにもまた、知らない名前がある。 かつての私は、そうやって定義から定義へ移っていた。 たどり着いたころには、最初に何を知りたかったのかを忘れている。 戻る道は残っていた。開いたタブは全部そこにある。それでも、なぜ最初のファイルを開いたのかだけが出てこない。仕方がないので、また先頭から読み始める。 あのころ読むのが遅かったのは、目の動きが遅いからではない。すべてを同じ重要度で読み、一度に扱える量が限られた注意へ、目的、現在地、通過した経路、細部を同時に載せていたからだ。最初に載せた目的が、いちばん先に落ちる。 いまはAIにコードを調べさせ…

全部読まなくても、読まなかった場所には責任を持つ

はじめに AIにコードを渡せば、多くの場合、流暢な説明は返ってくる。けれど、人が止まる理由は同じではない。 見慣れない演算子が一つだけ置かれたコードを前にすると、私は意味を知らないために止まる。使われている関数の定義が別の場所にあるコードでは、何を探すべきかは分かっていても、必要な情報が手元にないために止まる。すべての構文を知っていても、変数の値が何度も入れ替わる処理では、途中の状態を頭の中だけで動かせずに止まる。 外から見れば、どれも「コードが分からない」という同じ沈黙である。しかし、最初の停止に必要なのは知識であり、二つ目に必要なのは情報へ戻る経路であり、三つ目に必要なのは関係を外へ出す表…

説明を足す前に、どこで止まったかを分ける

はじめに 私はFable 5の性能を語りたい。そして、その前に自分のSkillを疑いたい。 以前のモデル向けに書いた指示は、新しいモデルでも動きます。 しかし、動くことは、能力を引き出すことを意味しません。 Prompting Claude Fable 5という題名から想像するのは、Fable 5に効く指示文の一覧です。ところが本文には、タイムアウト、ストリーミング、メモリ、サブエージェント、フォールバック、send_to_userまで並びます。プロンプトの話を読みに来たはずが、途中からクライアント、実行基盤、UI、権限管理の話を読んでいる。題名はプロンプトですが、読み終わるころには実装チケッ…

Prompting Claude Fable 5ってちゃんと読みました

はじめに 前の記事に、「何が分からないか分からないとき、どう乗り越えているのか」というコメントをもらいました。 syu-m-5151.hatenablog.com 同じ問いは、学生からも、SNSでも、以前から聞かれていました。 その場では断片的に答えてきましたが、1つの形にしたことはありませんでした。 ただ、この問いに1つの記事で答えようとすると、手が止まりました。私も、新しい領域では何が分からないのか分かりません。用語を調べると、その説明に知らない用語が出てきます。公式ドキュメントを開いても、どのページから読めばよいのか判断できません。AIに聞けば整った説明は返ってきますが、どこを信じ、何を…

何が分からないか分からないとき、私は「学習」をやめる

はじめに 学生は、私より先にAIへ質問していました。 AIはすでに答えていました。 それでも、問いを持ち帰ったのは私でした。 コンテナやKubernetesの基礎を扱う学生向けのワークショップで、学生たちはAIエージェントに実行を任せていました。分からないことがあれば、まずAIに聞きます。その回答を読んでから私に質問し、私は答えます。ときどき、「どこまで確かめたのか」と問いを返しました。 これは、学生やジュニアエンジニアのAI利用を評価する話ではありません。私も日々AIエージェントを使っています。ただ、その往復が滑らかに進むほど、「できた」という言葉の輪郭がぼやけていきました。 速く実行できる…

成長とか上達って、何だろう。

**「バグを直す」のはもうやめませんか。**あなたのシステムにもいませんか。`is_paid = true` なのに `payment_id` が null という、支払ったのか払ってないのかシュレディンガーの注文。`status = "verified"` なのに `verified_at` が存在しない、検証された記憶のない検証済みユーザー。彼らはバグではありません。**型が「そういう存在」を許可してしまった、正規の住人**です。本セッションの主張はシンプルです。型は壁である。コンパイラのご機嫌取りでも、IDEの補完を効かせるための飾りでもなく、「なり得ない状態」を物理的にこの世に存在させないための壁。バグはテストで捕まえるものではなく、**そもそも書けなくする**ものです。実装言語はRustです。「関数型まつりでRust？」と思ったあなた、安心してください。代数的データ型、イミュータビリティ、パターンマッチ——中身はほぼ関数型の道具箱です。Rust未経験でも大丈夫なように、登場する言語仕様はその場で解説します。扱うのは以下の4パターン:- 状態ごとに型を分ける: 検証前の注文で価格計算しようとした瞬間、コンパイラに止められる世界- newtypeパターン: `CustomerId` と `OrderId` の取り違えを、レビュアーの目ではなくコンパイラが検出する- Smart Constructor: 「※必ずvalidateしてから使ってください」というお祈りコメントの卒業- Make Illegal States Unrepresentable: フラグ×Optionの組み合わせ爆発を、代数的データ型で根絶するおまけに、AIコーディングエージェント時代の話も。AIはコメントを平気で読み飛ばしますが、コンパイルエラーだけは無視できません。**型は「お願い」ではなく「壁」。** 人間にもAIにも等しく効く、最強の防壁の築き方を持ち帰ってください。DDDの知識は不要です。必要なのは「もうバグ調査で週末を潰したくない」という気持ちだけ。https://2026.fp-matsuri.org

型は壁、Rustでもバグを直すな、表現できなくせよ

はじめに タイトル案を5つ送った。返ってきたのは、そのどれでもなかった。 「1on1、雑談タイム──これらが失敗に終わるのはなぜか」。連載第4回の公開タイトルだ。編集部がつけたタイトルは、記事のキーワードだった「善意」や「心理的安全性」という抽象を、1on1と雑談タイムという、誰もが座らされたことのある具体へ引き下ろしていた。私の5案は、どれもその引き下ろしができていなかった。フィードバックを見て、最初に来たのは「確かに良くなっている」という実感だった。このタイトルは私の案のどれよりも、記事の中身に忠実だった。実感の数秒あとに、悔しさが来た。5案も出して、届かなかった。悔しかったのは編集に替え…

ブログを書いていたらサイボウズ式の連載が決まって、そして終わった

はじめに 金曜の夜だった。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が尾部遅延を増幅する数理

前作では「何を守るかを決める」という視点から、非機能要件・分散システム・トレードオフの考え方を紹介しました。「面白そうだけど、実際のコードはどうなっているの？」——この続編はその問いへの答えです。概念として語っていたことを、今度はコードの上で見ていきます。リトライはどう書くか。タイムアウトをどこに置くか。冪等性はどう担保するか。「なんとなく知っている」を「動くコードで理解している」に変えることを目指した発表です。ただし、コードを読む会ではありません。一行一行を追うのではなく、「なぜそう書くのか」「何を諦めて何を得ているのか」に焦点を当てます。設計の判断はコードに刻まれている——その読み方を一緒に考えます。前作を見ていなくても楽しめますが、見ていると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

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