nwiizo

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業界に来るな。」を読んで

Ory Kratosで認証を委譲する

おい、辞めないなら頑張れ

OAuth2認証をE2Eテストしたら、5つのバグが出てきた話

Next.jsでOry Hydra認証を実装する ― マルチテナントSaaSでの実践

はじめにあるプロジェクトで、電話番号が未登録のユーザーを検索するコードをレビューしていた。WHERE phone = NULL——一見正しく見えるこのクエリは、常に0件を返していた。データは確実に存在する。クエリもシンプル。では何が問題なのか。答えはSQLの3値論理にあった。通常の比較演算はTRUEかFALSEを返すが、SQLにはUNKNOWN（不明）という第3の真偽値がある。NULLは「値が不明」を意味するため、NULL = NULLは「不明 = 不明」となり、結果もUNKNOWNになる。WHERE句はTRUEの行しか返さないから、UNKNOWNは暗黙にFALSE扱いされ、結果は常に0件になる。この問題は『SQLアンチパターン』で「Fear of the Unknown」として解説されている。本記事ではRust + sqlxでの実装パターンに焦点を当てる。SQLアンチパターン 第2版 ―データベースプログラミングで陥りがちな失敗とその対策作者:Bill Karwinオーム社Amazonこういう妄想の仕様と実際の仕様には違いがある。「おい、類推するな」というブログで書いたので時間がある時に読んでほしい。syu-m-5151.hatenablog.comsqlxの型マッピングRustにはOption<T>という型がある。これは「値があるかもしれないし、ないかもしれない」を表現する型だ。Some(値)が「値あり」、Noneが「値なし」を意味する。SQLのNULLに相当するのがこのNoneだ。let phone: Option<String> = Some("090-1234-5678".to_string());  // 値ありlet phone: Option<String> = None;                                // 値なし（NULL相当）sqlxはPostgreSQLのNULLをこのOption<T>に自動マッピングする。 PostgreSQL  Rust (NULLable)  Rust (NOT NULL)  VARCHAR, TEXT  Option\<String>  String  INTEGER  Option\<i32>  i32  BIGINT  Option\<i64>  i64  UUID  Option\<Uuid>  Uuid  DECIMAL  Option\<Decimal>  Decimal  TIMESTAMPTZ  Option\<DateTime\<Utc>>  DateTime\<Utc> NULLableカラムをOption<T>以外にマッピングすると、NULLが返された時点で実行時エラーになる。私も一度やった。「NULLなんて来ないだろう」と思っていたカラムが、特定の条件でNULLを返し、深夜にSlackが鳴った。#[derive(Debug, sqlx::FromRow)]struct User {    id: Uuid,    email: String,              // NOT NULL → 必ず値がある    name: String,               // NOT NULL → 必ず値がある    phone: Option<String>,      // NULLable → Option型で「値があるかもしれないし、ないかもしれない」を表現    bio: Option<String>,        // NULLable → Noneが「値なし」、Some("値")が「値あり」    created_at: DateTime<Utc>,  // NOT NULL → 必ず値がある}パターン1：検索フィルターでのNULL// NG: NoneがNULLにバインドされ、phone = NULLは常にUNKNOWN// query_as::<_, User>の説明://   ::<_, User> は戻り値の型を指定するRustの記法（turbofish構文）//   _ はデータベースの種類をコンパイラに推論させる部分//   User は「検索結果をUser構造体に変換して」という指定let users = sqlx::query_as::<_, User>(    "SELECT * FROM users WHERE phone = $1"  // $1はプレースホルダ（SQLインジェクション対策）).bind(&params.phone)  // bind()で$1に値を埋め込む。NoneはNULLになる.fetch_all(&pool)     // 全件取得.await?;              // 非同期処理の完了を待つ。?はエラー時に早期リターン// OK: 条件分岐でクエリを切り替える// match式: Option型の中身に応じて処理を分岐（switch文のようなもの）let users = match &params.phone {    Some(phone) => {  // Some(値): 値がある場合        sqlx::query_as::<_, User>("SELECT * FROM users WHERE phone = $1")            .bind(phone)            .fetch_all(&pool)            .await?    }    None => {  // None: 値がない場合 → IS NULLを使う        sqlx::query_as::<_, User>("SELECT * FROM users WHERE phone IS NULL")            .fetch_all(&pool)            .await?    }};// OK: IS NOT DISTINCT FROMで1クエリにまとめる（PostgreSQL固有）// NULLを普通の値として比較できる（NULL同士も「等しい」と判定）let users = sqlx::query_as::<_, User>(    "SELECT * FROM users WHERE phone IS NOT DISTINCT FROM $1").bind(&params.phone).fetch_all(&pool).await?;パターン2：COUNTの挙動// r#"..."# は生文字列リテラル（raw string literal）// 複数行のSQLを書きやすく、エスケープも不要な記法sqlx::query_as(    r#"    SELECT        COUNT(*) as total_users,                           -- 全行数（NULLを含む）        COUNT(coupon_code) as users_with_coupon,           -- NULLでない行数        COUNT(*) - COUNT(coupon_code) as users_without_coupon    FROM users    "#)空文字列とNULLが混在している場合は注意が必要。// NG: 空文字列のみマッチ、NULLはマッチしない"SELECT * FROM users WHERE coupon_code = ''"// OK: 両方を考慮"SELECT * FROM users WHERE coupon_code IS NULL OR coupon_code = ''"// OK: NULLIFで正規化"SELECT * FROM users WHERE NULLIF(coupon_code, '') IS NULL"パターン3：フォーム送信での空文字列フロントエンドから{ "phone": "" }が送られると、Option<String>ではSome("")になる。データベースには空文字列が保存され、NULLにはならない。// Rustレイヤーで正規化// filter(): 条件を満たさない場合はNoneに変換するメソッド// |s| !s.is_empty() はクロージャ（無名関数）: sが空でなければtruelet phone = req.phone.filter(|s| !s.is_empty());  // Some("") → None, Some("090") → Some("090")let bio = req.bio.filter(|s| !s.is_empty());sqlx::query("UPDATE users SET phone = $1, bio = $2 WHERE id = $3")    .bind(&phone)  // NoneはNULLとしてバインドされる    .bind(&bio)    .bind(user_id)    .execute(&pool)  // execute(): SELECT以外のクエリ実行    .await?;// SQLレイヤーで正規化sqlx::query(    r#"    UPDATE users    SET phone = NULLIF(TRIM($1), ''),  -- TRIM: 空白除去, NULLIF: ''ならNULLに        bio = NULLIF(TRIM($2), '')    WHERE id = $3    "#)パターン4：LEFT JOINでのOption必須LEFT JOINは左側のテーブル（例: users）の全行を返す。右側のテーブル（例: orders）に一致する行がない場合、右側のカラムはすべてNULLで埋められる。だから注文がないユーザーの場合、o.created_atはNULLになり、MAX(o.created_at)の結果もNULLになる。// NG: 注文がないユーザーでMAX(o.created_at)がNULLになり、実行時エラーstruct UserWithLastOrder {    last_order_date: DateTime<Utc>,  // NULLを受け付けない型}// OK: Option<T>でNULLを許容するstruct UserWithLastOrder {    last_order_date: Option<DateTime<Utc>>,  // NULLならNone、値があればSome(値)}LEFT JOINや集約関数（MAX, AVG, SUM等）の結果は常にNULLになりうる。迷ったらOption<T>を使う。パターン5：NOT INの罠// NG: category_idがNULLの行は削除されないsqlx::query(    r#"    DELETE FROM products    WHERE category_id NOT IN (        SELECT id FROM categories WHERE active = true    )    "#)なぜNULLの行が削除されないのか。NOT INは内部でx <> 1 AND x <> 2 AND ...に展開される。ここでcategory_idがNULLだとどうなるか。NULL <> 1はUNKNOWNを返す。NULL <> 2もUNKNOWN。ANDの3値論理ではTRUE AND UNKNOWN = UNKNOWNだから、条件全体がUNKNOWNになる。WHERE句はTRUEの行しか処理しないため、NULLを含む行は削除対象から外れてしまう。// OK: NOT EXISTSを使う// NULLの行も正しく処理される（サブクエリが0行ならTRUE）sqlx::query(    r#"    DELETE FROM products p    WHERE NOT EXISTS (        SELECT 1 FROM categories c        WHERE c.id = p.category_id AND c.active = true    )    "#)パターン6：query_as!マクロこれまでのパターンで使っていたquery_as()は実行時に型チェックを行う。一方query_as!()はマクロで、コンパイル時にデータベースへ接続してスキーマを確認し、型の不整合をビルドエラーとして検出する。NULLになりうるカラムをOption<T>以外でマッピングしようとすると、実行前にエラーを発見できる。// NG: AVG(rating)はNULLを返す可能性があり、コンパイルエラーstruct ProductSummary {    average_rating: f64,  // f64はNULLを受け付けない}sqlx::query_as!(    ProductSummary,    "SELECT name, AVG(rating) as average_rating FROM products GROUP BY name")// コンパイルエラー: AVGの結果がNULLになりうるのにOption<f64>ではない// OK: Option<T>を使うstruct ProductSummary {    average_rating: Option<f64>,}// OK: COALESCEと"!"サフィックスでNOT NULLを保証sqlx::query_as!(    ProductSummary,    r#"    SELECT name,           COALESCE(AVG(rating), 0)::FLOAT8  -- NULLなら0、FLOAT8にキャスト           as "average_rating!"              -- "!"でNOT NULLを宣言    FROM products GROUP BY name    "#) サフィックス  意味  !  NOT NULLを強制（Option\<T>ではなくT）  ?  NULLを許容（TではなくOption\<T>） まとめ冒頭のWHERE phone = NULLは、WHERE phone IS NULLに書き換えて5分で解決した。3値論理を知っているかどうか——それだけの差だった。NULLの問題はバグではなく、SQLの仕様だ。Rust/sqlxでは以下を守れば大半の問題は防げる。NULLableカラムはOption<T>にマッピング= NULLではなくIS NULLを使うNOT INではなくNOT EXISTSを使う空文字列とNULLを混在させない迷ったらOption<T>を使う。後からOptionを外すのは簡単だが、NULLが返ってきたときのパニックを本番で見るのは心臓に悪い。そもそもNULLableカラムを減らす設計（NOT NULL制約のデフォルト化、別テーブルへの分離）も検討に値する。3値論理の詳細は『SQLアンチパターン』の「Fear of the Unknown」章を参照してほしいです。このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。参考資料SQL Antipatterns - Fear of the UnknownPostgreSQL - Comparison Functionssqlx - Compile-time checked queries

Fear of the Unknown：Rust/sqlxでNULLを制する6つのパターン

AI時代に今からITエンジニアを目指す若者にオススメする10冊の本  2026年版

はじめに年が明けた。月曜日。エディタを開いている。認証プロバイダーを自分で実装できるか、と聞かれたら、たぶん「できる」と答える。OAuth2のRFCは読んだ。フローも理解している、と思う。ただ、「じゃあ書いて」と言われたとき、キーボードに手を置いたまま止まってしまうことがある。頭では分かっている。手が動かない。10年近くインフラやプラットフォームを触ってきた。認可の仕組みは何度も設計した。Kubernetesの認証、サービスメッシュの認可、アクセストークンの検証。それでも「Login Providerをゼロから書け」と言われると、急に自信がなくなる。分かっているはずなのに、分かっていない気がする。知ってるつもり　無知の科学 (ハヤカワ文庫NF)作者:スティーブン スローマン,フィリップ ファーンバック早川書房Amazon知ってるつもり～「問題発見力」を高める「知識システム」の作り方～ (光文社新書)作者:西林 克彦光文社AmazonOry Hydraのドキュメントを開く。Login ProviderとConsent Providerを自分で実装しろ、と書いてある。Node.jsのサンプルがある。Goのサンプルもある。どちらも動く。でも私はRustで書きたかった。年末年始、ぼんやり考えていて気づいたことがある。止まっているのは、技術的に難しいからではない気がする。「何をどの順番で実装すればいいのか」が見えていないのだ。全体像が掴めないまま、最初の一歩が踏み出せずにいる。だからこの記事を書くことにした。過去の自分に向けて。最初の一歩を、順番に。前提知識: この記事は前回の記事の続編です。OAuth2認可コードフローの基礎知識と、Ory Hydraのアーキテクチャ（Login/Consent Providerの役割）を理解している前提で進めます。syu-m-5151.hatenablog.com作るものLogin/Consent Providerとは、Ory Hydraと連携してOAuth2認証フローを処理するWebアプリケーションだ。以下の5つのエンドポイントを実装する。 エンドポイント  役割  GET /login  ログインフォームを表示する  POST /login  認証処理を行い、Hydraに結果を通知する  GET /consent  スコープ承認画面を表示する  POST /consent  承認結果をHydraに通知し、トークン発行へ進む  GET /logout  ログアウト処理を行い、セッションを破棄する 全体の流れOAuth2認可コードフローの中で、Login/Consent Providerがどう動くかを示す。1. ユーザーがクライアントアプリで「ログイン」をクリック2. クライアントがHydraの /oauth2/auth にリダイレクト3. Hydra が Login Provider の GET /login にリダイレクト（login_challenge付き）4. Login Provider がログインフォームを表示5. ユーザーがメール・パスワードを入力して送信6. Login Provider が認証し、Hydra に accept_login を送信7. Hydra が Consent Provider の GET /consent にリダイレクト（consent_challenge付き）8. Consent Provider がスコープ承認画面を表示9. ユーザーが承認10. Consent Provider が Hydra に accept_consent を送信11. Hydra がクライアントにリダイレクト（認可コード付き）12. クライアントが認可コードをトークンに交換Login/Consent Providerが担当するのは3〜10だ。Hydraとの通信には6つのAPIを使う。 API  役割  GET /admin/oauth2/auth/requests/login  login_challengeからリクエスト情報を取得  PUT /admin/oauth2/auth/requests/login/accept  認証成功をHydraに通知  GET /admin/oauth2/auth/requests/consent  consent_challengeからリクエスト情報を取得  PUT /admin/oauth2/auth/requests/consent/accept  承認結果をHydraに通知  GET /admin/oauth2/auth/requests/logout  logout_challengeからリクエスト情報を取得  PUT /admin/oauth2/auth/requests/logout/accept  ログアウトをHydraに通知 www.ory.comLogin HandlerLogin Handlerは2つのエンドポイントで構成される。GET /loginクエリパラメータからlogin_challengeを取得するHydra APIでlogin_challengeを検証し、リクエスト情報を取得するskipフラグが立っていれば（既にセッションがあれば）、フォームを表示せず即座にaccept_loginそうでなければログインフォームを表示するPOST /loginフォームからemail、password、login_challengeを受け取る認証サービスでパスワードを検証する認証成功なら、ユーザー情報をcontextに詰めてaccept_loginを呼ぶHydraが返すリダイレクトURLへ転送するpub async fn login_submit(    State(state): State<AppState>,    Form(form): Form<LoginForm>,) -> Result<Redirect, AppError> {    // 1. 認証処理    let user = state.auth.authenticate(&form.email, &form.password).await?;    // 2. ユーザー情報をcontextに保存（Consent時にDBルックアップ不要）    let user_context = UserContext {        email: user.email.clone(),        role: "customer".to_string(),        tenant_id: None,    };    // 3. Hydraに認証成功を通知    let completed = state        .hydra        .accept_login(            &form.login_challenge,            &user.id.to_string(),            false,            Some(serde_json::to_value(&user_context)?),        )        .await?;    // 4. Consent画面へリダイレクト    Ok(Redirect::to(&completed.redirect_to))}ポイントはcontextだ。Login時に認証したユーザー情報（email、role、tenant_id）をJSON形式で保存し、Consent Providerへ受け渡す。これにより、Consent処理でDBルックアップが不要になる。Consent HandlerConsent Handlerも2つのエンドポイントで構成される。GET /consentクエリパラメータからconsent_challengeを取得するHydra APIでリクエスト情報（要求されたスコープ、クライアント情報）を取得するskipフラグが立っていれば（既に承認済みなら）、即座にaccept_consentそうでなければスコープ承認画面を表示するPOST /consentフォームからconsent_challengeと承認するスコープを受け取るLogin時に保存したcontextからユーザー情報を取得するIDトークンにカスタムクレーム（email、role、tenant_id）を追加するaccept_consentを呼び、Hydraが返すリダイレクトURLへ転送するIDトークンにクレームを追加することで、クライアントアプリケーションはトークンをデコードするだけでユーザー情報を取得できる。Logout HandlerLogout Handlerは1つのエンドポイントで構成される。Login/Consentと比べてシンプルだ。GET /logoutクエリパラメータからlogout_challengeを取得するHydra APIでaccept_logoutを呼び出すHydraが返すリダイレクトURLへ転送するpub async fn logout_handler(    State(state): State<AppState>,    Query(query): Query<LogoutQuery>,) -> Result<Redirect, AppError> {    let completed = state.hydra.accept_logout(&query.logout_challenge).await?;    Ok(Redirect::to(&completed.redirect_to))}ログアウトフローはLogin/Consentと異なり、確認画面を表示せずに即座にaccept_logoutを呼んでいる。本番環境では「本当にログアウトしますか？」という確認画面を挟むことを検討してもよい。動作確認docker compose up -d./scripts/e2e-test.shIDトークンにemail、role、subが含まれていれば成功だ。ここまでが「何を作るか」「どう動くか」の説明だ。以降は実装の詳細に入る。認証サービスの実装Login Handlerから呼び出される認証サービスの実装に入る。パスワード認証にはOWASPのガイドラインに従い、Argon2idを採用した。cheatsheetseries.owasp.orgArgon2::default()を使っているが、これは意図的だ。argon2クレートのデフォルト値はOWASP推奨設定に準拠している。「専門家が作ったものを信頼する方が合理的」という前回の記事と同じ論理だ。認証部分で見落としがちなのが次の点だ。pub async fn authenticate(&self, email: &str, password: &str) -> Result<User, AppError> {    let users = self.users.read().await;    let user = users.get(email).ok_or(AppError::InvalidCredentials)?;    Argon2::default()        .verify_password(password.as_bytes(), &parsed_hash)        .map_err(|_| AppError::InvalidCredentials)?;    Ok(user.clone())}ユーザーが存在しない場合も、パスワードが間違っている場合も、返すエラーは同じInvalidCredentialsだ。「ユーザーが見つかりません」というエラーを返したくなるが、それは攻撃者に情報を与えてしまう。これはユーザー列挙攻撃（User Enumeration Attack）への対策だ。攻撃者はまず有効なメールアドレスを特定しようとする。エラーメッセージが違えば、登録済みかどうかが分かってしまう。なお、完全な対策にはタイミング攻撃への考慮も必要だ。ユーザーが存在しない場合はArgon2の検証が走らないため、レスポンス時間の差で存在を推測される可能性がある。本番環境では、ユーザー不在時もダミーハッシュを検証することを検討してほしい。owasp.orgテスト設計認証システムのバグは「静かに」起きる。だからテストの考え方も変わる。普通の機能開発では「この操作をしたらこうなる」というテストを書く。でも認証システムでは「この操作をしてもこうならない」というテストの方に価値がある。#[tokio::test]async fn test_login_does_not_reveal_user_existence() {    let service = AuthService::new();    service.register("exists@example.com", "password").await.unwrap();    let err1 = service.authenticate("exists@example.com", "wrong").await.unwrap_err();    let err2 = service.authenticate("nobody@example.com", "password").await.unwrap_err();    assert_eq!(err1.to_string(), err2.to_string());}このテストは「エラーメッセージが同じ」という実装の意図を明示化している。将来誰かが「親切なエラーメッセージにしよう」と思って変更しても、このテストが警告を出す。責任分界点全ての攻撃をアプリケーション層で防ぐ必要はない。何を守り、何をインフラに任せるかを明確にする。ブルートフォース対策: Nginxのrate limitで弾くセッション固定化攻撃: フレームワーク（Axum + tower-sessions）に委譲HTTPS強制: インフラ設定の問題プロジェクト構成今回はAxumを使った。github.comsrc/├── main.rs          # サーバーエントリーポイント├── auth.rs          # 認証サービス├── handlers.rs      # Login/Consent/Logoutハンドラー├── hydra.rs         # Hydra Admin APIクライアント├── models.rs        # Hydra API型定義└── error.rs         # エラー型定義ハンドラー層とサービス層を分離している。認証ロジックはauth.rsに置き、ハンドラーはHTTPリクエストの受け取りとレスポンスの返却だけを担う。フルコードはGitHubリポジトリを参照してほしい。github.com実装チェックリスト必須の実装[ ] Hydra APIクライアント - 6つのAPI呼び出し[ ] GET /login - login_challenge検証、skipフラグ確認、フォーム表示[ ] POST /login - 認証、contextにユーザー情報、accept_login[ ] GET /consent - consent_challenge検証、skipフラグ確認、承認画面表示[ ] POST /consent - context取得、IDトークンにクレーム追加、accept_consent[ ] GET /logout - logout_challenge取得、accept_logout[ ] 認証サービス - Argon2id、ユーザー列挙攻撃対策忘れがちなポイントlogin_challengeとconsent_challengeはhiddenフィールドでフォームに埋め込むskipフラグが立っている場合は画面を表示せず即座にacceptするcontextでLogin→Consent間のユーザー情報受け渡しエラーメッセージはユーザーの存在を漏らさないおわりにこの文章を書き終えて、ターミナルに戻った。docker compose up -dを叩く。コンテナが立ち上がる。E2Eテストを走らせる。グリーン。IDトークンにemailとroleが入っている。動いた。正直に言うと、書いている途中で何度か不安になった。これで説明になっているのか。Login HandlerとConsent Handlerの違いが曖昧になっていないか。contextの使い方は2回書き直した。それでも、動いた。冒頭で書いた「キーボードに手を置いたまま止まってしまう」感覚は、たぶん、また来る。次に認証システムを書くときも、OAuth2のフローを思い出すところから始めるだろう。login_challengeって何だっけ、と調べ直すかもしれない。それでいいのだと思う。認証は「一度理解したら終わり」という領域ではない気がする。毎回、RFCを確認しながら、慎重に実装する。ユーザー列挙攻撃のテストを書いたのも、将来の自分が「親切なエラーメッセージ」を入れようとしたときに止めるためだ。年が明けて、また仕事が始まる。本番の認証システムはOry Hydraに任せる。Login Providerは自分で書く。その境界線が、今の私には見えている気がする。

RustでOry Hydra用認証プロバイダーを実装する

おい、辞めるな

はじめにHacker News の「Show HN」は、自分が作ったものを開発者コミュニティに紹介できる場だ。しかし、ただ URL を貼れば良いわけではない。明確なルールがあり、それを守らないと投稿が埋もれたり、他のユーザーから通報されて非表示になることもある。この記事では、Show HN のルールを読み解き、効果的な投稿を作成するまでのプロセスを解説する。Show HN とは何かShow HN は Hacker News 内の特別なカテゴリで、自分が作ったものを他の人が試せる形で共有する場所だ。通常の HN 投稿がニュースや記事のシェアであるのに対し、Show HN は「触れるもの」を紹介する。投稿が一定のポイントを獲得すると、トップバーの "show" ページに表示され、より多くの人の目に触れる。ルールを正確に理解するShow HN には明確なルールがある。公式ガイドラインから重要なポイントを抜粋する。news.ycombinator.com投稿できるものユーザーが実際に試せるもの（run on their computers or hold in their hands）ハードウェアの場合は動画や詳細な記事でも可書籍の場合はサンプルチャプターでも可投稿できないものブログ記事サインアップページニュースレターリスト記事その他「読むだけ」のコンテンツこれらは「試せない」ため Show HN の対象外だ。通常の投稿として submit すべき。その他の重要なルール自分が関わったプロジェクトであること議論に参加できる状態であることサインアップやメール登録なしで試せるのが理想準備ができていないなら投稿しない（ready になってから来い）ランディングページや資金調達ページは NG友人に upvote や comment を頼むのは禁止（組織的な票操作とみなされる）マイナーアップデート（Foo 1.3.1 is out）は NG、メジャーオーバーホールなら可投稿フォームの構成Show HN の投稿は3つの要素で構成される。1. Title（タイトル）Show HN: で始める必要がある80文字制限がある（超過するとエラー）プロジェクト名と一言説明を入れる2. URLプロジェクトのリポジトリ、デモサイト、またはドキュメントページユーザーがすぐに試せる URL が理想3. Text（オプション）URL を補足する説明文何を作ったか、なぜ作ったか、どう使うかフィードバックを求めるポイントを明示すると反応が得やすい効果的なタイトルの作り方80文字という制限の中で、以下を伝える必要がある。プロジェクト名 — 何と呼ばれているか何をするものか — 一言で説明差別化ポイント（余裕があれば） — なぜこれが面白いかタイトルのパターンShow HN: [プロジェクト名] – [一言説明]文字数を削るテクニック：- 冠詞（a, an, the）を省略- "for" を "–" に置き換え- 形容詞を削る- 技術用語は略称を使う（もし一般的なら）良いタイトルの例Show HN: Helix – A post-modern text editor written in RustShow HN: Zed – A high-performance code editor from the creators of AtomShow HN: DuckDB – An embeddable SQL OLAP database management system避けるべきタイトルShow HN: My new project that I've been working on for 6 months  ← 情報がないShow HN: Check this out!  ← 何かわからないShow HN: Tool v1.3.2 released  ← マイナーアップデートは NGText（説明文）の書き方Text は任意だが、書いた方が反応は良くなる。以下の構成が効果的：1. 何を作ったか（1-2文）I built a [種類] that [主要機能].2. なぜ作ったか / 何が新しいか（2-3文）既存ツールとの違い、解決した課題、採用した理論やアプローチ。3. 使い方（1-3行）Quick start:  npm install -g mytool  mytool initワンライナーで試せると理想的。4. 主要機能（箇条書き、3-5個）Features:- Feature A- Feature B- Feature C5. フィードバックの呼びかけ（1文）Would love feedback on [具体的なポイント].「フィードバックください」だけでなく、何について聞きたいかを明示すると、具体的なコメントが得やすい。実際の投稿準備プロセスStep 1: ルールの確認まず公式ガイドラインを読む。ルールは時々更新されるため、投稿前に毎回確認するのが安全。news.ycombinator.comStep 2: 素材の整理プロジェクトの URLREADME や説明文主要機能のリストインストール方法Step 3: タイトルの作成80文字制限を意識しながら複数案を作成。文字数カウンターを使って確認する。Step 4: Text の作成上記の構成に沿って簡潔に。長すぎると読まれない。Step 5: 投稿タイミングHN のトラフィックは米国時間の午前中（太平洋時間 6-10 AM）がピーク。日本時間だと夜〜深夜にあたる。AI を活用した投稿準備Show HN の投稿準備は、AI アシスタントとの相性が良い。依頼の例https://news.ycombinator.com/showhn.html のルールに沿って、https://github.com/username/project を Show HN に投稿したい。タイトル、URL、テキストを作成してほしい。AI に依頼する際のポイント：ルールの URL を渡す — AI が最新のルールを参照できるプロジェクトの URL を渡す — README から情報を抽出してもらえる文字数制限を伝える — 80文字制限など、具体的な制約を共有AI が生成した案をそのまま使うのではなく、自分の言葉で調整することで、より自然な投稿になる。投稿後の対応Show HN では投稿者がコメントに返信することが期待されている。質問には丁寧に回答批判的なコメントにも建設的に対応バグ報告には感謝を伝え、対応する姿勢を見せる投稿して放置するのは印象が悪い。数時間はコメントを監視できるタイミングで投稿しよう。まとめShow HN への投稿は、単なる宣伝ではなく、開発者コミュニティとの対話の始まりだと思います。ルールを守る — 「試せるもの」を投稿するタイトルは80文字以内 — プロジェクト名 + 一言説明Text で文脈を与える — 何を、なぜ、どう使うかフィードバックポイントを明示 — 具体的な質問を投げかける投稿後は対話する — コメントに返信する

Hacker NewsのShow HN に自作ツールを投稿する方法 

はじめに認可サーバーを構築するタスクがアサインされた。技術選定の裁量はある。仕事の合間にRFC 6749や技術書をいくつか読み始めた。datatracker.ietf.org帰宅後の深夜、週末の空き時間。3日目の深夜2時、私は確信した。これは自前で作るべきではない。認可コードフロー、インプリシットフロー、リソースオーナーパスワードクレデンシャル、クライアントクレデンシャル。4つのグラントタイプ。それぞれにセキュリティ要件がある。PKCEも必要だ。OpenID Connectも。IDトークンのクレーム設計。JWKSエンドポイント。セッション管理。トークン失効。リフレッシュトークンのローテーション。仕様を読めば理解できる。実装もできる。でも、これをプロダクション品質で検証し続けるのは、私たちの仕事ではない。3日間RFCを読んで分かったのは、「自前で作ることの非合理性」だった。調べていく中で、OpenAIがOryを採用していることを知った。www.ory.com彼らは認可サーバーの実装に時間を使わないことを選んだ。彼らの本業はAIモデルの開発だ。認証認可は重要だが、「解くべき問題」ではなく「解決済みの問題を使う」領域として扱っている。妥当な判断だと思う。Ory Hydraを採用することにした。www.ory.shgithub.comこの記事では、Hydraのアーキテクチャを解説し、Docker Composeで実際に動かすところまでやる。OAuth2/OIDCの基本概念は知っている前提で進める。OAuth徹底入門 セキュアな認可システムを適用するための原則と実践作者:Justin Riche,Antonio Sanso翔泳社AmazonOAuth 2 in Action (English Edition)作者:Richer, Justin,Sanso, AntonioManningAmazonこのブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。「認証をしない認可サーバー」という話www.ory.comHydraのドキュメントを読んでいて、ある一文で手が止まった。「Hydraは認証をしません」認可サーバーなのに認証しない。最初は設計の欠落かと思った。Auth0やKeycloakは全部やってくれるのに。だが、ドキュメントを読み進めるうちに意図が見えてきた。これは欠陥ではない。これこそが設計の核心だ。考えてみてください。あなたの会社には、おそらく既にユーザーデータベースがある。10年使ってきた認証システムがある。LDAPで認証している。多要素認証は自前のものを使っている。パスキー対応も進めている。一般的なIdP——Auth0やKeycloak——を導入すると、これらを全部IdP側に合わせなければなりません。データ移行。認証フローの再設計。既存システムとの複雑な連携。Hydraは違うアプローチを取ります。「認証はあなたたちでやってください。終わったら教えてくれれば、あとはこちらでOAuth2/OIDCの面倒なことは全部やります」この瞬間、私の中で何かがカチッとはまりました。既存の認証システムはそのまま。ユーザーDBもいじらない。ただ、OAuth2/OIDCのプロトコル層だけをHydraに任せる。認証と認可の責務が完全に分離される。これが「ヘッドレス」な認可サーバーというコンセプトです。具体的には以下のメリットがあります。既存システムはそのまま使える: ユーザーDB・認証ロジックをいじらなくていい認証方法は完全に自由: パスワード、パスキー、生体認証、なんでもHydraが担保するのはプロトコル準拠: OpenID Connect Certificationを取得済みhttps://openid.net/certification/openid.netアーキテクチャの全体像www.ory.comHydraを使ったシステムは、3つのコンポーネントで構成されます。Hydra Public API（ポート4444）はOAuth2/OIDCの「顔」です。クライアントアプリケーションが/oauth2/authに認可リクエストを投げ、/oauth2/tokenでトークンを受け取る。ここはHydraが全部やってくれます。Login/Consent Provider（ポート3000）が私たちの実装領域です。Hydraからリダイレクトされてきたユーザーに対して、/loginで認証画面を、/consentで同意画面を表示します。「このユーザーは本人か？」「このスコープを許可するか？」という判断を担う。ここに既存の認証ロジックを組み込みます。Hydra Admin API（ポート4445）は裏方です。Login/Consent Providerが認証・同意の結果をHydraに通知するために使います。チャレンジの検証、承認の通知、セッション管理を担当します。外部には公開せず、内部ネットワークからのみアクセスさせます。この構成を理解したとき、肩の荷が下りた気がしました。OAuth2/OIDCの複雑な部分はHydraに任せて、自分たちは「認証」という本質的な部分だけに集中できる。これなら、やれそうだ。チャレンジベースのフローwww.ory.comHydraとProviderの連携には「チャレンジ」という仕組みが使われます。最初は「なんで直接やり取りしないんだろう」と思いました。でも、この設計にはちゃんと理由があります。クライアントがHydraの/oauth2/authにリダイレクトHydraがlogin_challengeを生成し、Login ProviderにリダイレクトLogin Providerはlogin_challengeを検証し、ユーザーを認証認証成功後、Admin APIで承認を通知し、Hydraに戻るHydraがconsent_challengeを生成し、Consent ProviderにリダイレクトConsent Providerはスコープを確認し、Admin APIで承認クライアントに認可コードが返されるチャレンジは一度きりの使い捨てトークンです。傍受されても再利用できない。リプレイ攻撃やセッションハイジャックを構造的に防ぎます。この手のセキュリティ上の細かい配慮——正直、自前実装だと見落としがちだ。PKCEのcode_verifierの長さ制限（43-128文字）。stateパラメータに暗号学的に安全な乱数を使うべきこと。RFCを読んでいたあの3日間で、攻撃ベクトルをどれだけ考慮できていたか。Hydraはこれらをすべて内包しています。OpenID Connect Certificationを取得しているということは、私が見落としていたであろう細部まで検証されているということです。Docker Compose環境の構築www.ory.com理論は十分。実際に動かしてみましょう。OAuth2/OIDCの仕様は複雑です。RFC 6749を読んでも、認可コードフローの全体像が頭に入らなかった。実際にcurlでリクエストを投げ、リダイレクトを追いかけることで、初めて仕様書の抽象的な記述が腑に落ちました。開発環境は4つのサービスで構成されます。HydraのDockerイメージは公式で提供されています。hub.docker.comservices:  postgres:    image: postgres:16-alpine    environment:      POSTGRES_USER: hydra      POSTGRES_PASSWORD: secret      POSTGRES_DB: hydra    volumes:      - postgres_data:/var/lib/postgresql/data    healthcheck:      test: ["CMD-SHELL", "pg_isready -U hydra -d hydra"]      interval: 5s      timeout: 5s      retries: 5  hydra-migrate:    image: oryd/hydra:v2.2    environment:      DSN: postgres://hydra:secret@postgres:5432/hydra?sslmode=disable    command: migrate sql -e --yes    depends_on:      postgres:        condition: service_healthy  hydra:    image: oryd/hydra:v2.2    environment:      DSN: postgres://hydra:secret@postgres:5432/hydra?sslmode=disable      SECRETS_SYSTEM: super-secret-system-secret-at-least-32-chars      URLS_SELF_ISSUER: http://localhost:4444      URLS_CONSENT: http://localhost:3000/consent      URLS_LOGIN: http://localhost:3000/login      URLS_LOGOUT: http://localhost:3000/logout      LOG_LEVEL: debug    command: serve all --dev    ports:      - "4444:4444"      - "4445:4445"    depends_on:      hydra-migrate:        condition: service_completed_successfully    healthcheck:      test: ["CMD", "wget", "-q", "--spider", "http://localhost:4444/health/ready"]      interval: 10s      timeout: 5s      retries: 5  auth-provider:    build: .    environment:      HOST: 0.0.0.0      PORT: 3000      HYDRA_ADMIN_URL: http://hydra:4445      RUST_LOG: ory_hydra_rust=debug,tower_http=debug    ports:      - "3000:3000"    depends_on:      hydra:        condition: service_healthyvolumes:  postgres_data:注意: 上記の設定は開発環境用です。本番環境ではSECRETS_SYSTEMに32文字以上の暗号学的に安全な値を設定し、sslmode=disableはrequireに変更してください。docs.docker.comauth-providerサービスのbuild: .は、Login/Consent ProviderのDockerfileを参照しています。このDockerfileとRust実装は次回の記事で解説します。今回はHydraのアーキテクチャ理解に集中しましょう。サンプルコードは以下のリポジトリで公開しています。https://github.com/nwiizo/workspace_2026/tree/main/samples/ory-hydra-rustgithub.comdepends_onとhealthcheckの組み合わせがポイントです。PostgreSQL → マイグレーション → Hydra → auth-providerという起動順序が保証されます。私は最初これを書かずに「DBがない」エラーで30分悩みました。環境の起動と動作確認docker compose up -d --builddocker compose logs -f auth-providerヘルスチェック用エンドポイントにアクセスしてみます。curl http://localhost:3000/health# {"status":"healthy"}{"status":"healthy"}が返ってきた。たった数十行のdocker-compose.ymlで、OAuth2認可サーバーの基盤が動いている。RFCを読んでいたあの3日間で見えた複雑さが、Hydraの中に隠蔽されている。OAuth2クライアントの登録OAuth2フローをテストするには、まずクライアントを登録します。www.ory.shdocker compose exec hydra hydra create oauth2-client \  --endpoint http://localhost:4445 \  --grant-type authorization_code \  --response-type code \  --scope openid,offline_access,profile,email \  --redirect-uri http://localhost:8080/callback \  --name "Test Client"クライアントIDとシークレットが出力されるので控えておきます。OAuth2フローのテストテストユーザーを作成します。curl -X POST http://localhost:3000/api/auth/register \  -H "Content-Type: application/json" \  -d '{"email": "test@example.com", "password": "password123"}'ブラウザで認可エンドポイントにアクセスします（<CLIENT_ID>は先ほど取得したもの）。http://localhost:4444/oauth2/auth?client_id=<CLIENT_ID>&response_type=code&scope=openid+profile+email&redirect_uri=http://localhost:8080/callback&state=random_stateフローは以下のように進みます。Hydraがログイン画面にリダイレクトメールアドレスとパスワードを入力してログインHydraが同意画面にリダイレクトスコープを確認して同意http://localhost:8080/callback?code=...にリダイレクトリダイレクト先（8080）は存在しなくても構いません。URLから認可コードを取得できれば成功です。おわりにこの記事を書き終えて、時計を見た。深夜1時だ。正直に言うと、書いている途中で何度かRFCのタブを開いてしまった。「この説明で合ってるかな」と不安になって。私はこの記事を書いたからといって、OAuth2/OIDCを完全に理解したわけではない。たぶん来週も、仕様書の細部で「あれ？」となる瞬間がある。でも、少しだけ違うことがある。3日目の深夜2時、RFCのタブを20個開いて、私は判断した。これは自前で作るべきではない、と。仕様は理解できる。実装もできる。でも、プロダクション品質で検証し続けることは、私たちの仕事ではない。Hydraのアーキテクチャを理解して、Docker Composeで動かしてみて、その判断が正しかったと確信した。認証と認可は分離できる。複雑なプロトコル層は、検証済みの実装に任せていい。私が書くべきコードは、真ん中の「Login/Consent Provider」だけだ。「認可サーバーを自前で作ってくれ」もしあなたが今、この言葉を受けてRFCを読んでいるなら。3日読めば分かる。作れるかどうかではない。作るべきかどうかだ。RFCを読むことには意味がある。私もあの3日間があったから、Hydraの設計思想が腑に落ちた。でも、プロダクション品質の認可サーバーを一人で検証し続ける必要はない。検証済みの実装がある。明日の朝、目覚ましが鳴る。また仕事が始まる。おい、RFCのタブを閉じろ。Hydraのドキュメントを開け。何度でも思い出せることの方が大事だ。次の記事では、RustでLogin/Consent Providerを実装する。一緒に認証画面を作ろう。

Ory HydraでOAuth2認可サーバーを構築する

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 の現在地

こんにちは、花粉症が辛いです。登壇する時にくしゃみしないために朝から外出を自粛してます。15分なのにスライドが40枚あります。本日、「信頼性向上の第一歩！～SLI/SLO策定までの取り組みと運用事例～」というイベントで「SLI/SLO・ラプソディあるいは組織への適用の旅」🎵🧭 というタイトルで登壇しました！🔍 イベント詳細:- イベント名: 信頼性向上の第一歩！～SLI/SLO策定までの取り組みと運用事例～- 公式URL: https://findy.connpass.com/event/345990/📚 さらに！4日後の3月25日には翻訳した書籍に関する登壇する別イベントもあります！😲「Kubernetesで実践する Platform Engineering - FL#88」🐳⚙️興味がある方はぜひ参加してください！👨‍💻👩‍💻👉 https://forkwell.connpass.com/event/348104/お見逃しなく！🗓️✨

SLI/SLO・ラプソディあるいは組織への適用の旅

2025年02月13日 Developers Summit 2025 13-E-4 にて「インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて - Platform Engineeringの効果的な基盤構築のアプローチ」というタイトルで登壇します。同日にPFEM特別回 でも登壇するのですが資料頑張って作ったのでそっちも読んでください。完全版は機会があればお話するので依頼してください。イベント名:  Developers Summit 2025公式URL: https://event.shoeisha.jp/devsumi/20250213セッションURL: https://event.shoeisha.jp/devsumi/20250213/session/5546登壇ブログ: https://syu-m-5151.hatenablog.com/entry/2025/02/14/071127

インフラをつくるとはどういうことなのか、 あるいはPlatform Engineeringについて

2025年02月13日 Kubernetesで実践するPlatform Engineering発売記念！ PFEM特別回にて「Platform Engineeringは自由のめまい - 技術の選択における不確実性と向き合う」というタイトルで登壇します。同日にDevelopers Summit 2025 でも登壇したのですが資料頑張って作ったのでそっちも読んでください。イベント名: Kubernetesで実践するPlatform Engineering発売記念！ PFEM特別回公式URL: https://platformengineering.connpass.com/event/342670/登壇ブログ: https://syu-m-5151.hatenablog.com/entry/2025/02/14/071127

Platform Engineeringは自由のめまい 

2025年01月26日 10:35-11:05（ルーム A）にて「Site Reliability Engineering on Kubernetes」というタイトルで登壇します。イベント名: SRE Kaigi 2025公式URL: https://2025.srekaigi.net/セッションURL: https://fortee.jp/sre-kaigi-2025/proposal/a75769d1-7835-4762-a1f6-508e714c8c8e登壇ブログ: https://syu-m-5151.hatenablog.com/entry/2025/01/26/005033

Site Reliability Engineering on Kubernetes

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