nwiizo

おい、要件を言葉にしろ

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 のスキルとして動作する日報自動生成ツールを作った

SREはAgentic Engineering時代のHarnessになれるのか？

move || を200回書いて考えた、Rust とフロントエンドの距離

 アーキテクチャモダナイゼーションの帯に「何度書き直しても、また遅くなる」と書いた理由 #devsumi #SRETT_Special #emconf_jp

PostgreSQL の型を信じろ — CIDR/ENUM 型と SQLx の格闘記録

 Leptos 0.8 でフルスタック Rust を始める

かつて、ある愚かなエンジニアがいた。彼は意気揚々とマイクロサービス移行という壮大な計画を立ち上げ、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つの転換点

おい、方法を捨てろ

AIのやりすぎで頭がおかしくなることにすら慣れた - 『AIのやりすぎで頭がおかしくなっている』を読んで

はじめにGhosttyをtipチャンネルで追いかけている。メモリリーク修正が早く降ってくるからだ。ある日アップデートしたら、フルスクリーンで起動しなくなった。fullscreen = trueは書いてある。設定は一行も変えていない。ghostty.orgCmd+Tでタブを開こうとしたら「Cannot Create New Tab — New tabs are unsupported while in non-native fullscreen」というダイアログが出た。設定が壊れたのではない。変わったのはGhosttyの方だ。このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。何が起きたか私のGhostty設定には、以下の2行がありました。macos-non-native-fullscreen = visible-menufullscreen = truemacos-non-native-fullscreen = visible-menuは、macOSネイティブのフルスクリーンアニメーションを使わず、メニューバーを表示したままフルスクリーン化するオプションです。ネイティブフルスクリーンの「ヌルッ」としたアニメーションが嫌いで、この設定にしていました。1.3.0（tip）にアップデートした後、2つの問題が同時に発生しました。起動時にフルスクリーンで開かない。Cmd+Tでタブが作れず、「non-native fullscreenではタブは非対応」というエラーダイアログが表示される。最大化ボタンも見えない状態でした。原因の特定根本原因は1つでした。ただし、切り分けに至るまでに寄り道をしている。その過程も書いておく。根本原因: non-native fullscreenでタブが非対応にGhostty 1.3.0で、non-native fullscreenモード（visible-menu含む）ではタブがサポートされなくなりました。これは意図的な変更です。non-native fullscreenはmacOSのウィンドウ管理を迂回する実装のため、タブバーとの整合性を保証できないという判断でしょう。fullscreen = trueとmacos-non-native-fullscreen = visible-menuの組み合わせが、1.2.xでは動いていたものが1.3.0で破綻した形です。問題なのは、この組み合わせで起動してもエラーや警告が一切出ないことです。フルスクリーンにならず、最大化ボタンも見えず、タブを開こうとして初めてダイアログが出る。設定の検証時点で警告を出してくれれば、すぐに気づけます。この点はIssue #10894として報告しました。github.com疑った原因: window-save-stateによるfullscreen設定の上書き最初に疑ったのはwindow-save-state = alwaysでした。この設定は前回のウィンドウ状態を保存・復元します。一度でもフルスクリーンを解除して閉じると、その「非フルスクリーン」状態が保存され、次回起動時にfullscreen = trueより優先される——という仮説です。実際にwindow-save-state = neverに変更してみましたが、フルスクリーン問題は解消しませんでした。ここでwindow-save-stateは犯人ではないとわかりました。ただし、neverにしたことでタブの保存・復元まで消えてしまい、別の問題を踏むことになりました。結局alwaysに戻しています。原因の切り分けで設定を変えるときは、副作用に注意が必要です。修正内容修正は1箇所です。- macos-non-native-fullscreen = visible-menu+ # 1.3.0 で non-native fullscreen はタブ非対応になったため無効化+ macos-non-native-fullscreen = falsemacos-non-native-fullscreen = falseでmacOSネイティブフルスクリーンに切り替えます。メニューバーの常時表示はできなくなりますが、画面上部にマウスを持っていけば表示されるので実用上の問題はありません。タブとフルスクリーンの両方が使えることの方が重要です。window-save-state = alwaysはそのまま維持します。ネイティブフルスクリーンであれば、タブ・フルスクリーン状態ともに正しく保存・復元されます。Cmd+Qで正常終了すれば、次回起動時にタブが復元されることを確認済みです。1.3.0の新設定オプションを取り込むせっかくtipチャンネルで最新を追いかけているので、1.3.0で追加された新しい設定オプションも調査して取り込みました。Ghostty 1.3.0マイルストーンには597件のクローズ済みissueがあり、設定周りだけでもかなりの変更が入っています。github.com以下、実際に採用したものとその理由です。scrollbar = never# 1.3.0: スクロールバー非表示（キーボードナビゲーション主体のため）scrollbar = never1.3.0でmacOSとGTKの両方にネイティブスクロールバーが実装されました。デフォルトはsystem（OS設定に従う）です。私はCtrl+U、Alt+B、Alt+Gなど、Vim式のキーボードナビゲーションでスクロールしているので、スクロールバーは不要です。描画領域も広がるため、neverにしています。split-preserve-zoom = navigation# 1.3.0: ズーム中のスプリット移動でズーム状態を維持split-preserve-zoom = navigationスプリットをCmd+Shift+Enterでズームした状態で、Ctrl+H/J/K/Lで隣のスプリットに移動すると、従来はズームが解除されていました。navigationフラグを有効にすると、スプリット間の移動でもズーム状態が維持されます。ズームしたまま「隣のペインの出力をちょっと確認」ができるようになるので、地味に便利です。tab-inherit-working-directory / split-inherit-working-directory# 1.3.0: タブ・スプリットも作業ディレクトリを継承tab-inherit-working-directory = truesplit-inherit-working-directory = true従来はwindow-inherit-working-directoryしかなく、新規ウィンドウのみが作業ディレクトリを継承していました。1.3.0で新規タブと新規スプリットにも個別に設定できるようになりました。デフォルトでtrueですが、明示的に書いておくことで意図を残しています。~/projects/my-appで作業中にCmd+Tで新しいタブを開いたら、そのタブも~/projects/my-appで始まる。当然の挙動ですが、以前は必ずしもそうならないケースがありました。notify-on-command-finish# 1.3.0: コマンド完了通知（非フォーカス時、5秒以上のコマンド）notify-on-command-finish = unfocusednotify-on-command-finish-after = 5s長時間コマンドの完了通知です。cargo testやdocker buildを走らせて別のタブで作業しているとき、完了したらmacOSの通知が飛んできます。unfocusedはGhosttyウィンドウが非フォーカスのときのみ通知するモードです。5秒未満で終わるコマンドは通知されません。前提としてシェルインテグレーション（OSC 133）が必要です。Fish shellではshell-integration = fishを設定していればそのまま動きます。検索ハイライトのカスタマイズ# 1.3.0: 検索ハイライト（Tokyo Night に合わせた配色）search-foreground = #1a1b26search-background = #e0af68search-selected-foreground = #1a1b26search-selected-background = #ff9e641.3.0でターミナル内検索がネイティブGUIとして実装されました。検索マッチのハイライト色をカスタマイズできます。Tokyo Nightテーマに合わせて、候補はイエロー（#e0af68）、選択中はオレンジ（#ff9e64）にしました。テーマのパレットから色を取っているので違和感なく馴染みます。palette-generate = false# 1.3.0: カスタムパレット指定時の自動生成を無効化（正確な色を維持）palette-generate = false1.3.0では、ベースの16色ANSIパレットをカスタマイズしている場合、拡張256色パレット（インデックス16〜255）を自動的に再生成する機能が追加されました。Tokyo Nightのパレットを正確に維持したいので、この自動生成は無効化しています。採用しなかった新機能調査した結果、以下の機能は今回採用しませんでした。判断の根拠も書いておきます。key-remap（修飾キーのリマッピング）: Ghosttyアプリケーション内でCtrlとCmdを入れ替えるなどの用途です。Karabiner-Elementsでシステムレベルでやっているので不要でした。Key Tables / Key Sequences（モーダルキーバインド）: ctrl+wでペイン操作モードに入り、h/j/k/lで移動、escapeで抜ける——tmuxのprefix keyに近い仕組みです。面白いですが、現在のperformable:ベースのスプリット操作で不満がないので見送りました。tmuxから移行する人には嬉しい機能でしょう。mouse-reporting = false（マウスレポート無効化）: Neovimでのマウス操作を無効にしたい場合に使えます。私はNeovim側でマウスを有効にしているので不要です。ランタイムでtoggle_mouse_reportingアクションで切り替えられるので、必要になったらキーバインドを追加する方が柔軟です。selection-word-chars（ダブルクリック選択の単語境界）: デフォルトの単語境界文字セットで不便を感じていないので、カスタマイズ不要でした。1.3.0のその他の注目機能設定に直接関係しないものの、知っておくと便利な1.3.0の変更点も書いておきます。ターミナル内検索: macOSとGTKの両方でネイティブ検索UIが実装されました。Cmd+Fで検索バーが出ます。マッチ間のナビゲーション、ハイライト色のカスタマイズに対応しています。これまでscrollback-limitを大きくしても検索手段がなかったので、ようやくです。スプリットのドラッグ&ドロップ（macOS）: スプリットをドラッグして別のウィンドウに移動したり、ウィンドウ外にドラッグして新しいウィンドウを作ったりできます。タブのカラーピッカー（macOS）: タブを右クリックして色を付けられます。プロジェクトごとにタブの色を変えると視認性が上がります。ダブルクリックでURL全選択: URL上でダブルクリックすると、単語ではなくURL全体が選択されるようになりました。ペースト安全性の向上: ペースト時に危険な制御文字がスペースに置換されるようになりました。xtermと同じ挙動です。Nushell対応: shell-integration = detectでNushellの自動検出・設定が動くようになりました。最終的な設定ファイル修正と新機能の追加を反映した設定ファイルの全体を載せておきます。各設定項目の詳細は公式のConfiguration Referenceを参照してください。ghostty.orggithub.comまとめtipチャンネルで最新ビルドを追いかけるということは、こういう破壊的変更に当たるということです。macos-non-native-fullscreen = visible-menuが1.3.0でタブと共存できなくなったのは、Release Notesに書かれる前に体験で知ることになりました。トラブルシュートの過程でwindow-save-stateをneverに変えてみたり、macOSのdefaultsを削除してみたりと、関係ない設定まで触ってしまいました。結局、根本原因はmacos-non-native-fullscreenの1箇所だけだった。原因を切り分けるとき、変更は1つずつ試して戻す。当たり前のことを、自分の設定ファイル相手だと雑にやってしまう。一方で、1.3.0には良い変更も多く入っています。ターミナル内検索、コマンド完了通知、split-preserve-zoom、作業ディレクトリの継承強化。どれもターミナルヘビーユーザーにとって実用的な改善です。特にコマンド完了通知は、cargo testを走らせて別作業をしている間に完了を見逃す——という日常的なストレスを解消してくれます。Ghostty 1.3.0の正式リリースは2026年3月の予定です。tipチャンネルで先行して使いたい方は、この記事の設定変更が参考になるはずです。正式リリースを待つ方も、macos-non-native-fullscreenの挙動変更は覚えておいて損はないはずです。ghostty.org参考Issue #10894: fullscreen=true + macos-non-native-fullscreen=visible-menu が 1.3.0 で無警告に壊れるGhostty 1.3.0 MilestoneGhostty Release NotesGhostty Configuration Reference

Ghostty 1.3.0（tip）にアップグレードしたらフルスクリーンが壊れた——原因と新設定の全記録

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

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

おい、方法を選べ

Claude CodeのPLAN MODEは使ったほうがいい

おい、方法を学べ

ある日の終電後。オフィスには私しかいなかった。蛍光灯は半分消えている。デスクのモニターだけが、青白い光を放っている。IRCの通知は止まっている。誰も見ていない。誰も知らない。今、私がここで何をしても、誰にも分からない。三時間前、本番環境で障害が発生した。顧客からの問い合わせが殺到した。Nagiosのアラートチャンネルが真っ赤に染まった。私はオンコール担当だった。原因を調査した。特定した。十五年前に書かれたコードの中に、バグがあった。なぜ今頃発火したのか。おそらく、長らく使っていたNFSの性能が落ちていたからだ。十五年間、たまたま踏まなかった地雷を、今夜ついに踏んだ。バグは十五年前からそこにあった。ただ、表に出てこなかっただけだ。障害は収束した。暫定対応でサービスは復旧した。しかし、根本原因を修正しなければ、また同じ障害が起きる。明日の朝までに、修正をリリースしなければならない。画面には、十五年前に書かれたコードが映っていた。変数名は tmp と data と result の三種類しかない。コメントは一行もない。テストは存在しない。一つの関数が八百行ある。その関数の中に、さらに三重のネストしたif文がある。読んでいると、頭が痛くなる。しかし、このコードは動いてきた。十五年間、今夜まで、一度も止まることなく、毎日数万件のトランザクションを処理してきた。私は、二つの選択肢の前で立ち尽くしていた。正しいやり方——リファクタリングする。テストを書く。変数名を直す。関数を分割する。その上で、バグを修正する。それには、最低でも三週間かかる。明日の朝には間に合わない。その間、同じ障害が再発するリスクを抱え続ける。間違ったやり方——このコードの該当箇所に、場当たり的なパッチを当てる。動けばいい。テストは書かない。後で直す。いつか直す。たぶん、直さない。私は知っていた。後者を選べば、このコードはさらに腐る。次にこのコードを触る人は、私を呪うだろう。しかし、その「次の人」は、私ではない。——と書いて、立ち止まる。本当にそうか。「次の人」は、来年の私かもしれない。それでも、私は迷っていた。「正しいコードを書け」。私は、何度もこの言葉を聞いてきた。本で読んだ。カンファレンスで聞いた。先輩に言われた。自分でも言ってきた。SOLID原則。DRY原則。クリーンアーキテクチャ。テスト駆動開発。私は、これらの「正しさ」を信じてきた。信じていた、と思っていた。しかし、終電後のオフィスで、十五年物のレガシーコードを前にして、障害の再発リスクを抱えながら、私は気づいた。「正しさ」は、昼間の言葉だ。昼間は、みんながいる。コードレビューがある。品質基準がある。「正しさ」を語ることで、評価される。「リファクタリングしましょう」と言えば、「意識が高い」と思われる。しかし、夜になると、誰もいない。誰も見ていない。「正しさ」を語る相手がいない。残っているのは、障害の再発リスクと、明日の朝というデッドラインだけだ。私は思い出した。以前、ある先輩が言っていた言葉を。「コードの美しさなんて、障害対応の現場には関係ない。止血が先だ」当時の私は、反発した。「技術的負債がたまる」「保守性が下がる」「長期的に見れば損だ」。正論を並べた。先輩は笑って聞いていた。今になって分かる。あの笑いの意味が。先輩は、私の「正しさ」が、まだ試されていないことを知っていた。本番障害の修羅場を経験したことがない。顧客からのクレームの電話を受けたことがない。自分の判断で、会社の信用が左右される経験をしたことがない。そういう人間が語る「正しさ」は、空論だ。——と書いて、自分の中にある別の声が聞こえる。それは、本当にそうか。「試されていない」ことが、「正しくない」ことの証明になるのか。試されていなくても、正しいものは正しいのではないか。しかし、その夜の私には、その声は届かなかった。私は、キーボードに手を置いた。そのとき、ふと考えた。十五年前、このコードを書いた人は、何を考えていたのだろうか。きっと、同じような状況だったのではないか。締め切りに追われていた。リソースが足りなかった。「後で直す」と自分に言い聞かせて、このコードを書いた。その人も、テストを書かなかった。変数名を直さなかった。コメントを書かなかった。なぜか。時間がなかったからだ。その人の後に来た人も、同じだったのではないか。このコードを見て、顔をしかめた。しかし、直さなかった。なぜか。時間がなかったからだ。そして今、私がここにいる。同じ選択を迫られている。「時間がなかった」。この言葉が、十五年間、このコードを腐らせ続けてきた。そして今、私も同じ言葉を使おうとしている。これは、正当化の連鎖だ。「前の人も時間がなかった。だから、自分も許される」。前例が、免罪符になる。私は、その連鎖の中に自分を位置づけようとしていた。連鎖の一部になれば、責任は薄まる。「自分だけが悪いわけではない」と言える。責任を、過去に分散させることができる。——と書いて、その論理の欺瞞に気づく。責任を分散させても、コードは腐ったままだ。連鎖に加わることで、私が得るのは心理的な安心だけだ。コードは何も改善しない。しかし、その夜の私には、心理的な安心が必要だった。私は、自分を正当化する論理を組み立て始めた。この会社は、このプロダクトで売上を立てている。プロダクトが止まれば、顧客は離れる。顧客が離れれば、売上は下がる。売上が下がれば、会社は傾く。会社が傾けば、私は職を失う。正しいコードを書いている間に、サービスが止まり続けたら、何の意味がある？障害を早く直すことは、顧客のためだ。会社のためだ。同僚のためだ。そして、自分のためだ。みんなのためにやっている。だから、許される。この論理は、強力だ。「自分のため」だけなら、罪悪感がある。しかし、「みんなのため」なら、むしろ正義になる。利他的な動機があれば、手段は正当化される。私は、この論理に身を委ねようとしていた。しかし、ふと気づいた。十五年前の人も、同じ論理を使ったのではないか。「顧客のために、早くリリースしなければ」「会社のために、間に合わせなければ」。そう言い聞かせて、このコードを書いた。その結果が、今夜の障害だ。「みんなのため」という論理で書かれたコードが、十五年後に「みんな」を苦しめている。私は、同じことをしようとしている。今夜、「みんなのため」にパッチを当てる。そのパッチが、十五年後に誰かを苦しめる。正当化の論理は、短期的には機能する。しかし、長期的には破綻する。「みんなのため」は、「将来のみんな」を含んでいない。——と書いて、また立ち止まる。では、どうすればいいのか。障害を放置して、明日も明後日も顧客を苦しめることが、「将来のみんな」のためになるのか。どちらを選んでも、誰かを苦しめる。それが、この状況の本質だ。コードを書いている途中で、手が止まった。私は、自分が何をしているのか、急に分からなくなった。画面には、私が追加したパッチがある。八行。たった八行の条件分岐だ。バグの原因となっていたエッジケースを、特別扱いする。根本的な解決ではない。しかし、これで障害は再発しなくなる。たぶん。私は、自分のコードを見つめた。そして、気づいた。私は、このコードを十五年後に見る誰かを、呪っている。私は、十五年前にこのコードを書いた誰かを呪った。「なぜこんなコードを書いたのか」「なぜテストを書かなかったのか」「なぜリファクタリングしなかったのか」。呪いながら、同じことをしている。十五年後の誰かは、私を呪うだろう。同じ言葉で。同じ怒りで。そして、同じように、さらに八行のパッチを追加するだろう。呪いの連鎖だ。私は、その連鎖の一部になろうとしている。連鎖を断ち切ることもできる。リファクタリングすればいい。テストを書けばいい。しかし、それには三週間かかる。明日の朝には間に合わない。連鎖を断ち切るコストを、私は払えない。いや、払う気がない。コストを払う気がないのは、なぜか。それは、連鎖を断ち切る恩恵を受けるのが、私ではないからだ。リファクタリングの恩恵を受けるのは、十五年後の誰かだ。その誰かは、私ではないかもしれない。私は、十五年後にはこの会社にいないかもしれない。別のプロジェクトにいるかもしれない。そもそも、このプロダクト自体が、十五年後には存在しないかもしれない。コストは今の私が払い、恩恵は未来の誰かが受ける。それなら、コストを払わない方が、合理的だ。私は、その論理に抗えなかった。気がつくと、窓の外が明るくなっていた。目が痛い。徹夜明けの頭が、鈍く重い。始発の電車が走る音が聞こえる。オフィスのエアコンが、タイマーで動き始めた。私の目の前には、完成したパッチがあった。テストはない。コメントは一行だけ。「障害対応: エッジケースの特別処理を追加」。それだけだ。なぜそう書いたのか。どんな判断をしたのか。何も書かない。書けない。いや、違う。書かないのだ。書くと、自分がやったことを認めることになる。認めたくない。だから、曖昧にする。ステージング環境でテストした。動いた。本番環境にデプロイした。障害は再発しなかった。アラートは鳴らなかった。IRCに報告を書いた。「根本原因を修正しました。再発防止策は別途検討します」。「別途検討します」。この言葉が、どれほどの問題を先送りしてきたか。私は知っている。知っていて、使っている。私は、椅子にもたれかかった。疲れていた。しかし、安堵もあった。終わった。障害は収束した。顧客は救われた。私の仕事は終わった。そして、私は立ち上がって、オフィスを出た。朝の光が、眩しかった。夜の間に考えていたことが、すべて嘘のように思えた。「正しさ」も「正当化の連鎖」も「呪いの連鎖」も、夜の闘いの産物だ。朝になれば、消える。いや、消えるのではない。見えなくなるだけだ。朝の光の中で、私は「普通のエンジニア」に戻る。「正しいコードを書くべきだ」と語る。「技術的負債は早めに返すべきだ」と主張する。昼間の私は、そう言う。しかし、また夜が来る。また障害が来る。誰もいないオフィスで、同じ選択を迫られる。そのとき、私は何を選ぶか。私は、自分が何を選ぶか、もう知っている。この文章を読んでいるあなたは、どうだろうか。「私は違う」と思っているかもしれない。「私は正しいコードを書いている」「私はリファクタリングをしている」「私は技術的負債を返している」。そう思っているかもしれない。本当にそうだろうか。あなたは、一度も「後で直す」と言ったことがないか。一度も、テストを書かずにコミットしたことがないか。一度も、分かりにくいコードをそのまま追加したことがないか。一度も、「別途検討します」と書いたことがないか。ないはずがない。私たちは、みな同じ箱の中にいる。状況が許せば、正しいことをする。しかし、状況が許さなければ、正しさを捨てる。そして、「仕方なかった」と自分を正当化する。これは、個人の問題ではない。箱の問題だ。締め切りがある。障害対応の緊急性がある。リソースが足りない。時間が足りない。この箱の中で、「正しさ」を貫くことは、英雄的な行為だ。普通の人間には、できない。——と書いて、自分でも分かっている。「箱を変える」と言うのは簡単だ。実際に変えるのは、難しい。私自身、何度も挫折してきた。しかし、箱を変えようとしなければ、私たちは永遠に同じ場所にいる。夜ごとに「正しさ」を捨て、朝になると何事もなかったかのように振る舞う。その繰り返しだ。私は、その繰り返しから抜け出したい。しかし、抜け出せることを、確信できない。この矛盾を抱えたまま、私は今日もコードを書いている。あの夜から、三ヶ月が経った。私が当てたパッチは、まだ動いている。障害は再発していない。顧客からのクレームもない。障害対応は成功した。誰も、あのコードの中身を知らない。しかし、私は知っている。あのコードの中に、たった八行のパッチがあることを。テストがないことを。コメントが一行しかないことを。「別途検討します」と書いた根本対応が、まだ検討されていないことを。そして、いつか誰かが、あのコードを触ることになる。そのとき、その人は私を呪うだろう。「なぜこんなパッチを当てたのか」「なぜ根本対応をしなかったのか」と。私は、その呪いを受け入れる準備ができている。いや、できていない。受け入れなければならないと分かっているだけだ。次の障害が来たとき、私は何を選ぶか。「正しさ」を選ぶか。また同じ論理に堕ちるか。私自身にも、分からない。分からないまま、今日も私はオフィスに向かう。昼間は「正しさ」を語り、夜になれば「正しさ」を捨てる。その繰り返しの中で、私は何者になっていくのか。十五年前の人は、一度だけ選択した。その選択の結果が、今夜の障害だった。しかし、エンジニアは、毎日選択を迫られる。毎日、小さな「正しさ」を捨てるか、守るかを選ぶ。その積み重ねが、私たちを作る。そして、十五年後のコードを作る。私は、どんなエンジニアになりたいのか。どんなコードを残したいのか。その問いに、まだ答えられない。答えられないまま、今日も私は、コードを書く。十五年前の人の行方は、誰も知らない。私の行方も、私自身が知らない。

正しさは、昼間の言葉

おい、分けて語るな

 2026年1月 Neovim の Rust 環境を見直した

ZellijのRust実装パターン徹底解説（後編）

ZellijのRust実装パターン徹底解説（前編）

おい、あまりAIに褒めさせるな

Rust でも学べる関数型ドメイン駆動設計 - Domain Modeling Made Functional の読書感想文

おい、頑張るなら組織と踊れ

プログラミングが好きな人こそ今の時代、プログラマーになる方がいいと思う。- 「プログラミングが好きな人は、もうIT業界に来るな。」を読んで

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

おい、要件を言葉にしろ

おい、要件を言葉にしろ

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

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

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

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

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

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

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

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

Neovim 0.12 リリース内容まとめ

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

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

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

SREはAgentic Engineering時代のHarnessになれるのか？

move || を200回書いて考えた、Rust とフロントエンドの距離

アーキテクチャモダナイゼーションの帯に「何度書き直しても、また遅くなる」と書いた理由 #devsumi #SRETT_Special #emconf_jp

PostgreSQL の型を信じろ — CIDR/ENUM 型と SQLx の格闘記録

Leptos 0.8 でフルスタック Rust を始める

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

おい、方法を捨てろ

AIのやりすぎで頭がおかしくなることにすら慣れた - 『AIのやりすぎで頭がおかしくなっている』を読んで

Ghostty 1.3.0（tip）にアップグレードしたらフルスクリーンが壊れた——原因と新設定の全記録

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

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

おい、方法を選べ

Claude CodeのPLAN MODEは使ったほうがいい

おい、方法を学べ

正しさは、昼間の言葉

おい、分けて語るな

2026年1月 Neovim の Rust 環境を見直した

ZellijのRust実装パターン徹底解説（後編）

おい、要件を言葉にしろ

おい、要件を言葉にしろ

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

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

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

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

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

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

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

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

Neovim 0.12 リリース内容まとめ

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

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

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

SREはAgentic Engineering時代のHarnessになれるのか？

move || を200回書いて考えた、Rust とフロントエンドの距離

アーキテクチャモダナイゼーションの帯に「何度書き直しても、また遅くなる」と書いた理由 #devsumi #SRETT_Special #emconf_jp

PostgreSQL の型を信じろ — CIDR/ENUM 型と SQLx の格闘記録

Leptos 0.8 でフルスタック Rust を始める

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

おい、方法を捨てろ

AIのやりすぎで頭がおかしくなることにすら慣れた - 『AIのやりすぎで頭がおかしくなっている』を読んで

Ghostty 1.3.0（tip）にアップグレードしたらフルスクリーンが壊れた——原因と新設定の全記録

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

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

おい、方法を選べ

Claude CodeのPLAN MODEは使ったほうがいい

おい、方法を学べ

正しさは、昼間の言葉

おい、分けて語るな

2026年1月 Neovim の Rust 環境を見直した

ZellijのRust実装パターン徹底解説（後編）

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

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