nwiizo

はじめに Rust Learning Labは、手元のRustコードを題材に、構文や型、所有権を説明してもらうためのCodex・Claude Code向けプラグインです。「この記号は何か」「なぜここで借用するのか」「この変更で何が変わるのか」といった疑問を、具体的なコードに沿って確かめられます。 github.com Rustを書き始めた人にも、コードは読めるけれど型や所有権を選んだ理由までは説明しきれない人にも使ってもらいたいと思っています。私が考えているのは、AIに何を任せ、何を自分で確かめるか、その判断を育てる機会を仕事の中にどう残すかということです。Rust Learning Labは…

AIに実装を任せながら、Rustを学び続けたい。「Rust Learning Lab」を作りました

はじめに 『Building Evolutionary Architectures, 2nd Edition』を読みました。要件や技術が変わり続ける中で、システムの設計をどう変えていくかを扱った本です。部品をどう分け、どうつなぎ、どこへデータを置くか。ここでいうアーキテクチャは、そうした全体の構造を指します。1か所を直すだけで済むか、ほかの部品や担当チームまで巻き込むかにも関わります。 中心となるのは、守りたい性質を確かめる「フィットネス関数」です。新しい機能が動くだけでなく、応答が遅くなっていないか、必要なセキュリティを保てているかも、日々の変更の中で確かめる。本書は、その検査の仕組み、変更…

AIに実装を任せると、設計の仕事はどう変わるか - Building Evolutionary Architectures, 2nd Edition の読書感想文

はじめに Codex CLIには、会話を要約する /recap、出力をコピーする /copy、会話全体を書き出す /export があります。いずれも会話に蓄積された情報を扱う機能ですが、対象と用途が異なります。 この記事では、3つのコマンドの役割と、関連する /compact・/status・/diff との違いを整理します。要約、コピー、保存で何が得られるのか。現在のコードや検証結果は、どこで確かめるのか。この区別を押さえると、作業の再開やPRの説明に必要な情報を選びやすくなります。 会話の要約、出力のコピー、会話全体の保存 3つのコマンドは、扱う情報の範囲で分けられます。 コマンド 扱う…

Codexを使うなら、/recap・/copy・/exportを押さえておきたい

はじめに 誰かの「やってみたい」に加わることは、仕事の中でも外でも、人生を豊かにすると考えています。人の誘いに応じて、自分だけでは選ばなかった場所へ行き、会わなかったはずの人と話す。興味のなかったものを、そこで面白く感じることもある。自分の関心だけで選んでいたら、選ぶものはだんだん似てきます。 それなのに、のる前は面倒です。予定を空け、知らない場所へ行き、慣れない人と話す。楽しめるかは分からないのに、手間は先に見える。今日はやめておこう。次に面白そうなものがあったら。その判断は一度ずつならもっともでも、繰り返していると、自分に何が起きるのでしょうか。 誘いを一度断っても、その日はいつもどおりに…

おい、のっていけ

はじめに Codexが修正している途中で、「なぜ、その判定を変えるのか」と聞きたくなることがあります。理由を知りたいだけなのか、その変更を止めてほしいのか。途中で送る一文にも、別の目的があります。 長い仕事を続ける /goal、途中の質問を分ける /side、実行中の指示変更と予約送信。それぞれ、作業を続ける条件、質問する会話、指示を送るタイミングを指定する操作です。9月のCLI更新では、下書きを残したままCodexからの質問へ答える機能も加わりました。 認証処理を直す仕事で考えてみます。修正は続けてほしい。でも、期限の判定については説明を聞きたい。必要なら仕様を決め直し、Codexへ変更を指…

Codexを使うなら、/goalとサイドチャットを押さえておきたい

はじめに Codexへ同じ種類の依頼を繰り返していると、会話を開いて文章を貼り付ける操作を省きたくなります。変更概要を作る、ログを整理する、確認すべき点を一覧にする。入力と出力が見えている仕事なら、codex execで既存のCLIの流れへ組み込めます。 JSONの形が正しくても、調査が成功したとは限りません。対象を読めなかった結果が「問題なし」の空配列になれば、後の処理は失敗に気づけません。この記事では、実行中のイベント、最後の回答、実行そのものの失敗を分けて受け取ります。 learn.chatgpt.com まず単発の仕事を渡し、次にJSONLのイベントと最終JSONを分けます。その後、保…

Codexを使うなら、codex execと構造化出力を押さえておきたい

はじめに 毎朝、前日に変わったコードを確認したい。レビュー待ちのPRも見に行きたい。繰り返す仕事には、手順が分かっていても、始めるのを忘れる問題があります。Codexの定期タスクを使うと、予定した時刻にその仕事を始められます。 毎朝同じ文章を送っても、前回の会話や対象ファイルがなければ、同じ仕事にはなりません。予定どおり始まっても、必要な情報を読めずに終わることがあります。実行する時刻と一緒に、何を渡して始めるかを決めます。 ここでは、ローカルプロジェクトの変更を朝に確認するタスクを作ります。ChatGPTデスクトップアプリ内のCodexから利用し、管理画面の Scheduled で予定と実行…

 Codexを使うなら、定期タスクを押さえておきたい

はじめに 会話を分岐しただけでは、ファイルは分かれません。修正案を2通り試していても、同じディレクトリを書き換えているなら、片方の変更はもう片方からも見えます。会話の中では別案でも、ディスク上では同じ実装を直している状態です。 Codexでは、会話の分岐にWorktreeを組み合わせ、作業場所も分けられます。共通の調査から別案を試し、それぞれの差分を比較できます。取り込む変更が決まったら、不要になった作業場所も片付けます。 Claude CodeのAgent viewの記事では、並行する仕事の編集場所をWorktreeで分け、最後に変更を統合する話を書きました。今回の主題は、Codexから会話…

Codexを使うなら、Worktreesと会話の分岐を押さえておきたい

はじめに 同じ仕事を頼むたびに、前の会話からうまくいった指示をコピーすることがあります。その手順を残す場所として、Claude Codeの記事ではAgent Skillsを紹介しました。続くPluginsの記事では、社内で共有するSkillをプラグインにまとめる方法を書きました。配布した後も更新が届くところまで管理します。今回はCodexで同じことをするために、Skillを作る基準と、Codex固有の配置・呼び出し方を考えます。 syu-m-5151.hatenablog.com syu-m-5151.hatenablog.com PR説明を頼んだときは使ってほしいけれど、変更方針を相談してい…

Codexを使うなら、SkillsとPluginsを押さえておきたい

はじめに これまで、settings.json、CLAUDE.md、Commands、Hooks、Subagents、Skillsについて書いてきました。それぞれ設定すると、毎回説明することを減らせます。その次に困るのが、直した設定を、使っている環境へ届け続けることです。個人的にPluginsで嬉しいのは、自分のSkillをパッケージとして管理できることです。Skillを配布しても、その後の更新を忘れてしまうので。 たとえば、変更の概要を書くSkillを3つのリポジトリへコピーしたとします。1つで説明を改善したら、残り2つも更新する。Hooksも一緒に渡したいなら、設定ファイルへ追記する場所を…

 Claude Codeの Plugins は設定したほうがいい

はじめに AIを使って仕事が楽になった、という人は定期的に現れます。どこかの偉そうな人から、エージェントに任せれば人は楽になる、と言われる。けれど、複数のエージェントを起動すると、減っているのは考える時間です。 セッションごとの入力待ちに答え、別worktreeの差分を読み、終わった変更を同じ状態で動かす。仕事の量が消えたわけではなく、労働密度が上がっていました。1つのターミナルを見続ける辛さとは、別の辛さがあります。 Agent viewは、この辛さを消す機能ではありません。複数セッションの状態を一覧し、入力を求めている仕事へ移るための機能です。セッション間通信は、決まったことを別のセッショ…

Claude Codeの Agent view とセッション間通信は使ったほうがいい

はじめに Codexにテストを実行してほしいのに、依存パッケージの取得や書き込みで止まることがあります。そこで権限を広げると、今度はどこまで実行できるのかを説明しにくくなります。確認画面の多さだけを見て設定すると、必要な権限も分かりにくいままです。 権限プロファイルでは、ローカルのコマンドが触れるファイルや通信先をまとめます。Rulesでは、コマンドの引数列から許可・確認・禁止の判断を決めます。Claude Codeの権限設定と比べると、「どの操作を許すか」と「どの範囲なら任せるか」を分けて考える意味が見えてきます。この記事では、その設計の違いを押さえてから、テストが止まった場所と直す設定を順…

Codexを使うなら、権限プロファイルとRulesを押さえておきたい

はじめに Codexで設定を残す場所は、主に2つあります。config.tomlは実行環境を、AGENTS.mdは仕事の進め方を決めます。 learn.chatgpt.com config.tomlにはモデルや推論の強さなど、実行時の条件を書きます。AGENTS.mdには検証方法や作業上の制約を書きます。別のファイルの設定が優先されたり、起動場所によって指示が読み込まれなかったりするため、保存した内容と実際の動作を照合します。 設定の優先順位、起動場所、読み込まれる指示を確認して初めて、同じ条件でCodexを使えます。この記事では、まず2つの役割を分け、次に設定の読み込み順とAGENTS.md…

Codexを使うなら、config.tomlとAGENTS.mdを押さえておきたい

はじめに 「今週は検証環境が使えない」と伝えた文が、来月の会話にも残っている。期限のある事情を覚えているだけなのに、いつの間にか恒久的な手順になる。そうなっていたら困ります。覚えてくれることと、今も正しいことは別です。 以前のモデルが何度も間違えたために足した指示も、モデルを替えた後まで同じ書き方で必要とは限りません。消してよいのか、残すべきなのか。その判断をしないまま、設定だけが増えていきます。 昨日の記事では、/skill-doctor でSkillsの使われ方を調べ、モデル更新時に指示を見直す話を書きました。今回は、その続きを .claude/rules/ とAuto memoryで考え…

Claude Codeの Rules と Auto memory は、書きっぱなしにしないほうがいい

はじめに 2025年12月に「Claude Codeの Agent Skills は設定したほうがいい」という記事を書きました。必要な手順を必要なときに読み込ませる仕組みとして、Skillsを紹介した記事です。ただ、後半では設定が増えるほど管理が難しくなる話もしました。どれが使われているのか。似た説明のSkillが、互いの出番を奪っていないか。 syu-m-5151.hatenablog.com 今回は、その続きです。Skillsをいくつも設定した人には、まず /skill-doctor を紹介したいです。設定を増やす前に、今ある設定の使われ方を見られます。 /skill-doctor はv2…

 Claude Codeの Agent Skills は、ときどき見直したほうがいい

Forkwell Library #133。書籍の5ステップを紹介し、AIとともに仕事を終え、次の判断を変える進め方を考える。https://forkwell.connpass.com/event/405587/

おい、エージェントを使って終わらせろ

技術的負債に向き合うConference 2026。AIによって変わる実装の費用、判断の負担、学び方を、オニオンモデルの5層と3つの負債から考える。概念のどこを捉え直し、エージェントとどんな開発へ進むかを語る40分。

AI時代の「技術的負債」の変質ー概念の終焉と再解釈、エージェントと共に向かう先

はじめに 『おい、とりあえず終わらせろ そうすれば「動けない自分」が変わるから』が、ダイヤモンド社から発売されました。 【DL特典付】おい、とりあえず終わらせろ そうすれば「動けない自分」が変わるから（特典：生成AIにおけるSkillとは何か データ配信）作者:nwiizo（ぬうぃぞう）ダイヤモンド社Amazon 初めて商業出版する自分の単著は、技術書になると漠然と思っていました。技術の仕組みや使い方を詳しく書くか、『達人プログラマー』みたいな、プログラマーの判断や仕事の進め方についての本を書く。そういうことに憧れていました。 それが、『おい、とりあえず終わらせろ』になりました。プログラマーに…

本を書きました。本だからできたこと、これからできること

はじめに ディレクトリの中身を一覧にしても、目的のファイルがすぐ分かるとは限りません。似た名前の画像を見比べる、PDFの内容を確かめる、複数の場所からファイルを集める。こうした作業では、名前を検索するだけでなく、中身を見ながら選ぶ画面が役に立ちます。 Yaziは、その画面をターミナルに用意するファイルマネージャーです。Rustで実装され、キーボードを中心にディレクトリ移動、プレビュー、複数選択、コピーや移動を操作できます。文字端末の中で画面を描く、TUIと呼ばれる種類のアプリケーションです。 特徴は画像を表示できることだけではありません。プレビューの準備中にも別のファイルへ移動できるよう、処理…

Yaziとは何か。ファイルを探し、確かめ、操作するTUIの仕組み

はじめに AIにコードを書いてもらうことが増えて、私はコードを書くより、読む時間のほうが多くなりました。生成された変更を開き、何を直そうとしているのか、そのためにどこを変えたのかを追っています。 そのとき素早くつかみたいのは、変更の構造です。どこから呼ばれ、どのデータを受け渡し、どこで判断し、失敗をどう返すのか。変更された行だけを見ていても、このつながりは分かりません。周辺のコードを行き来しながら、何を変えようとしていて、それがどう実現されているのかを理解したいと思っています。 fffは目的のコードを探すために、CodeDiffは変更されたコードを読むために使います。私の環境では、LazyVi…

fffで探し、CodeDiffで読む。私のNeovim設定とソースで見る仕組み

生成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を検証しました。 サーバーサイドレンダリング、画面の一部の更新、Cookieを使ったセッショントークンの受け渡しは任せられます。認証、マイグレーション、運用はアプリケーション側に残ります。この記事は、その分担を1つずつ確認した記録です。 github.com tokio.rs SSRとルーティングは1ファイルで済む Rust 1…

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へ渡し、会話を残したまま編集へ戻りたい。codex.nvimは、対象の受け渡しとウィンドウの切り替えをNeovimから操作するプラグインです。 github.com このツールが必要になる場面 Codex CLIは:terminalから起動するだけでも使えます。しかし、相談するたびにファイルパスをコピーして、行番号を確認する必要があります。選択範囲の貼り付けやterminal modeからの移動も残ります。1回なら小さくても、調査、修正、確認を繰り返すほど集中を切る原因になります。 codex.nvimでは…

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

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

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

**「バグを直す」のはもうやめませんか。**あなたのシステムにもいませんか。`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でもバグを直すな、表現できなくせよ

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

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