はてなブックマーク

はじめに 認証が動いた。だがそれは始まりに過ぎなかった。 前回の記事では、Next.jsでOry Hydra認証を実装した。OAuth2認可コードフロー、Cookie管理、ID Token署名検証、マルチテナント認証について解説した。 前提知識: この記事は前回の記事の続編です。Next.jsでのOAuth2認証フロー実装を理解している前提で進めます。 Next.jsでOry Hydra認証を実装する ― マルチテナントSaaSでの実践 - じゃあ、おうちで学べる 今回は、実装した認証フローを検証する。Playwright MCPを使ったE2Eテスト、発見した5つのバグ、RBACの検証、そしてベストプラクティスとの比較までを一気に解説する。 Playwright MCPによるE2Eテスト もう本当に10年くらい前は「E2Eテストなんて、デモ前に手動で確認すれば十分でしょ」と思っていた。仕事

はじめに AIは、あなたが聞いたことにしか答えない。 聞かなかったことは、永遠に教えてくれない。あなたが何を知らないのか、AIは知らない。 2026年だ。AIに聞けば何でも教えてくれる。コードを書いてもらい、設計を相談し、ドキュメントを要約させる。便利だ。では、なぜ本を読むのか。300ページもある本を、最初から最後まで読む必要があるのか。 本は違う。本は、聞いていないことを語りかけてくる。知らなかった世界を見せてくる。持っていなかった問いを、手渡してくる。「そんなこと、考えたこともなかった」。そういう瞬間が、本にはある。AIとの対話では、たぶん起きない。 AIは効率的だ。知りたいことに、最短距離でたどり着ける。でも、最短距離で歩いていると、道の脇にあるものが見えない。著者が失敗した話、遠回りした話、「今思えば間違いだった」という告白。そういう「寄り道」が、不思議と頭に残る。正解は忘れる。で

はじめに 年が明けた。月曜日。エディタを開いている。 認証プロバイダーを自分で実装できるか、と聞かれたら、たぶん「できる」と答える。OAuth2のRFCは読んだ。フローも理解している、と思う。ただ、「じゃあ書いて」と言われたとき、キーボードに手を置いたまま止まってしまうことがある。頭では分かっている。手が動かない。 10年近くインフラやプラットフォームを触ってきた。認可の仕組みは何度も設計した。Kubernetesの認証、サービスメッシュの認可、アクセストークンの検証。それでも「Login Providerをゼロから書け」と言われると、急に自信がなくなる。分かっているはずなのに、分かっていない気がする。 知ってるつもり　無知の科学 (ハヤカワ文庫NF) 作者:スティーブン スローマン,フィリップ ファーンバック早川書房Amazon 知ってるつもり～「問題発見力」を高める「知識システム」の作

はじめに かつての私は、深夜2時にベッドの中で転職サイトを開いていた。 開いて、求人を眺めて、閉じて、また開く。そういうことを繰り返していた。辞めたいのか、と聞かれると困った。会社の限界が見えたのか。自分の天井が見えたのか。それとも、隣の芝生の青さに目が眩んでいただけなのか。たぶん、全部だった。たぶん、どれでもなかった。 今は、転職を考えていない。 これは「今の会社が最高だから」という話ではない。どんな会社にも良い面と悪い面がある。不満がゼロになることはない。ただ、深夜に転職サイトを開く衝動は、いつの間にか消えた。何が変わったのか。環境が変わったのか、自分が変わったのか。たぶん、両方だ。 「エンジニアは転職で年収が上がる」「成長できる環境に身を置け」——そんな言葉がタイムラインに流れてくる。転職エージェントからのスカウトメールは週に何通も届く。カジュアル面談のお誘い。年収アップの可能性。も

はじめに 認可サーバーを構築するタスクがアサインされた。技術選定の裁量はある。仕事の合間にRFC 6749や技術書をいくつか読み始めた。 datatracker.ietf.org 帰宅後の深夜、週末の空き時間。3日目の深夜2時、私は確信した。 これは自前で作るべきではない。 認可コードフロー、インプリシットフロー、リソースオーナーパスワードクレデンシャル、クライアントクレデンシャル。4つのグラントタイプ。それぞれにセキュリティ要件がある。PKCEも必要だ。OpenID Connectも。IDトークンのクレーム設計。JWKSエンドポイント。セッション管理。トークン失効。リフレッシュトークンのローテーション。 仕様を読めば理解できる。実装もできる。でも、これをプロダクション品質で検証し続けるのは、私たちの仕事ではない。3日間RFCを読んで分かったのは、「自前で作ることの非合理性」だった。 調べ

はじめに テストは全部通っている。コードカバレッジも90%を超えている。なのに、本番環境でバグが見つかった。 私が実際に経験したことだ。原因を調べると、テストコードにassert（検証）が書かれていなかった。テストは「コードを実行しただけ」で、結果が正しいかどうかを確認していなかったのだ。正直、恥ずかしかった。テストを書いている気になっていただけで、何も守っていなかった。 こういう経験はないだろうか。あるいは、レビューで「このテスト、意味ありますか」と指摘されたことは。 この記事では、こうした「見せかけのテスト」を発見するミューテーションテストという手法と、Rust向けのツールcargo-mutantsを紹介します。 公式ドキュメントを参照する場合は、以下のリンクからどうぞ。 mutants.rs github.com このブログが良ければ読者になったり、nwiizoのXやGithubをフ

はじめに 2025年が終わろうとしている。 先日、「なぜ『何でも作れる時代』に私は作れないのか」という記事を書いた。「代表作」がないという焦り、量をやることの重要性、そして引き算の必要性。書きながら、自分の弱さと向き合った。 syu-m-5151.hatenablog.com あの記事で「2026年は20個作る」と宣言した。その前に、2025年に何を作ったのか振り返っておきたい。 振り返ると、この1年は「自分が欲しいもの」をひたすら作り続けた年だった。誰かに頼まれたわけでもなく、バズを狙ったわけでもなく、ただ「これがあったら便利なのに」という衝動に従って、キーボードを叩き続けた。「3回同じ不便を感じたら作る」というルールを自分に課している。cctxは3回目の設定ファイル書き換えで、cargo-autoddは3回目のCargo.toml編集で生まれた。前回の記事で書いた「隙間家具」を、実際に

はじめに 誰もまとめてくれないので自分でまとめます。こんなに悲しいことはありません。 2025年11月から12月にかけて、「おい、〜」というシリーズでブログを15本書きました。登壇もしました。合計16本です。誰かがまとめ記事を書いてくれるかなと思っていました。待っていました。誰も書いてくれませんでした。年末です。仕方がないので自分で書きます。 シリーズの始まり 今年の8月、本を書かないかという話が来ました。嬉しかったです。企画を練りました。構成を考えました。8月、9月、10月といろいろやり取りをしていたのですが、いろんな諸事情で立ち消えになりました。 悔しかったです。本を出せなかったことが悔しかったのではない。結局何にもならなかった自分が悔しかった。もっと準備できたはずだ。もっと詰められたはずだ。その後悔が残りました。でも、本の企画のために書いた下書き原稿が8本くらいありました。本にならな

はじめに 数年前の、ある金曜日の夜のことだ。会議は完全な失敗に終わった。会議室を出て、エレベーターのボタンを押しながら、私はこの文章を書こうと決めた。書き上げるまでにずいぶん時間がかかってしまったので、当時の思いとは少し違っているかもしれない。 あの会議で「論理的に正しいことを言ったのか」と問われれば、言った。間違いなく言った。データも揃えた。根拠も示した。反論の余地がないほど、正しいことを言ったはずだった。 だが、誰も動かなかった。 私の発言が終わった瞬間、会議室の空気は凍りついた。誰も何も言わない。居心地の悪い沈黙が流れ、やがて別の話題へと移っていった。正しいことを言ったはずなのに、私は敗北感を覚えた。 当時、私はシニアエンジニアになったばかりだった。部下はいない。それでも「組織全体の技術選定に責任を持て」と言われる。命令する権限はない。しかし説得しなければならない。予算を握っているわ

はじめに 技術書編を書き終えて、ふと気づいた。あれだけ書いても、まだ語っていない本がある。仕事に直結しない本。読んでも生産性が上がらない本。キャリアに役立つかどうかわからない本。そういう本たちのことを、どこかで書きたいと思っていた。だから、この記事を書いている。 非技術書を読む時間を、どこか後ろめたく感じていた時期があった。エンジニアなんだから技術書を読むべきだ。限られた時間を、仕事に関係ない本に使っていいのか。そんな自問が、頭の片隅にあった。でも、ある時期から考えが変わった。技術書だけ読んでいると、技術書が読めなくなる。視野が狭くなる。発想が硬くなる。同じ問題を、同じ角度からしか見られなくなる。 なぜそうなるのか。技術書は「答え」を求めて読むからだ。設計パターン、ベストプラクティス、トラブルシューティング。明確な課題があって、その解決策を探している。でも非技術書は違う。何を得られるかわか

——「何を作るべきか」を選び、腹を括ることの価値 この記事の核心：AIがコードを書く時代になっても、「何を作るべきか」を選び、腹を括り、うまくいかなければ別の手を打つのは人間の仕事だ。なぜなら、痛みのない決断は決断ではなく計算だから。本稿では、要件定義を「合意形成」として捉え直し、2025年のAIエージェント元年に人間が担うべき役割を考える。 はじめに AIがコードを書く時代になりました。「ファイル監視ツールを作って」と指示すると、動くコードが出てきます。それだけではありません。2025年現在、AIエージェントはファイルを読み、テストを実行し、エラーを修正し、プルリクエストまで作成できます。 便利になった分、私たちの仕事は減るのでしょうか。「作る」作業は確かに減ります。しかし「何を作らせるか」「どこで人間が介入するか」を決める仕事は増えます。AIが「作る」を担うからこそ、「選ぶ」の重みが増

はじめに Rustは速い。だが、Rustで書けば速くなるわけではない。 ある日、APIのレスポンスが突然5秒を超えた。コードを見直してもバグはない。SQLも正しく書けている。途方に暮れながらログを確認すると、1リクエストで300回以上もクエリが発行されていた。原因は、ループ内で著者情報を1件ずつ取得していたこと。これがN+1クエリ問題だ。 見えないものは、直せない。 本記事では、この見落とされがちなN+1クエリ問題の本質と、RustとPostgreSQLを使った5つの解決策を解説する。正直に言うと、どの解決策がベストかは状況による。だからこそ、複数のアプローチを知っておく価値があると私は考えている。 N+1クエリ問題とは 問題のあるコード 本記事では、RustのSQLクライアントライブラリ「sqlx」を使用します。sqlxは型安全なクエリとasync/awaitをネイティブにサポートするラ

はじめに テストを書いていて、奇妙なことに気づいた。合計金額のアサーションが通らない。期待値は10.00なのに、実際の値は9.99999999999983。コードにバグはない。SQLも正しい。では何が問題なのか。調べた結果、犯人は浮動小数点の累積誤差だった。金額カラムにDOUBLE PRECISIONを使っていたのです。 これは「浮動小数点の罠」とも呼ばれる、DB設計やアプリケーションの実装で陥りやすい問題だ。RustとPostgreSQLでWebサービスを構築する際に注意すべき点の1つで、金融システムや科学計算、測定データ、座標、パーセンテージなど、正確な数値が必要なあらゆる場面で問題になります。 2進数と10進数の不一致 コンピュータは2進数で数値を表現します。しかし、私たちが日常使う10進数の多くは2進数で正確に表現できません。 0.1 (10進数) = 0.000110011001

はじめに 「論理削除？deleted_atカラム追加すればいいでしょ」この一言から始まる地獄を、何度見てきただろうか。 最初は簡単に見える。カラムを1つ追加するだけ。しかし、その「簡単さ」こそが罠だ。 論理削除は技術的負債の温床だ。WHERE句への条件追加忘れ、認知コストの増大、テストの複雑化、パフォーマンス劣化。すべては「最初にドメインを考えなかった」ツケである。 しかし現実として、サービスを運用していくと論理削除が必要になる場面は確実に訪れる。 論理削除の本質は、「このレコードは存在するが、存在しないことにしてほしい」という矛盾だ。この矛盾を解消するか、受け入れて安全に管理するか。本記事ではその両方のアプローチを解説する。 なお、私はDBのスペシャリストではないので、ここで紹介する方法が唯一の正解というわけではない。あくまで一つのアプローチとして参考にしてほしい。データベース設計は文脈

はじめに 年末、2025年を振り返る。フォロワーは7倍になった。副業も順調。書籍の執筆や翻訳にも関わった。登壇の依頼も増えた。どこからどう見ても、良い年だったはずだ。 なのに、胸の奥に澱のようなものが溜まっている。 コードは書いた。山ほど書いた。でもそれは、誰かに頼まれたコードだ。お金になるコード。評価されるコード。「これを作ってください」と言われて、「はい」と答えて、作ったコード。自分のためのOSSも、作った。公開もした。そこそこ使われもした。 でも、そこそこ止まりだ。「これが俺の代表作です」と言えるものが、ない。スターはついた。ダウンロードもされた。いくつかは今でも自分で使っている。完走した。自分なりに頑張った。でも、「代表作」と呼べるインパクトには届かなかった。 厄介なことに、nwiizoというアカウントは大きくなってしまった。フォロワーが増えた分、「代表作」のハードルも上がっている

はじめに 金曜日の夜、ベッドの上でこの文章を書き始めている。 先週の土日は何をしていたかと聞かれたら、たぶん「寝てた」と答える。嘘ではない。ベッドにいた時間は長かった。ただ、眠っていたかというと怪しい。スマホを持ったまま横になって、気づいたら夕方だった。そういう二日間だった。 休んだのか、と聞かれると困る。 体は動かしていない。仕事もしていない。だから休んだと言えば休んだのだろう。でも、回復したかというと、していない。月曜の朝を迎える自分は、金曜の夜の自分より確実に疲れている。 何もしていないのに。何もしていないから、かもしれない。 30歳になった。エンジニアとして働いている。在宅勤務というやつだ。2025年、AIエージェントが当たり前になった時代を生きている。 AIは文句を言わない。疲れたとも言わない。24時間動ける。私にはそれができない。コーヒーがないと朝は動けないし、金曜の午後は集中

この記事は、3-shake Advent Calendar 2025 19日目のエントリ記事です。 はじめに エンジニアがプレゼン資料を作るとき、PowerPointやKeynoteにもどかしさを感じることがあります。コードを書くようにスライドを作りたい。Gitでバージョン管理したい。テーマを一括で変更したい。Marpはこれらの願望を叶えるマークダウンベースのスライド生成ツールです。 marp.app しかし生成AI時代の今、新しい課題が生まれています。AIにスライドの下書きを依頼できるようになった反面、「AIっぽいプレゼン」が量産されるようになりました。整然としすぎて、話者の思考が見えない資料です。この記事では、AIの力を借りつつ「自分のプレゼン」を取り戻す仕組みを紹介します。 AIっぽいプレゼンの正体 生成AIにプレゼン資料を依頼すると、だいたい同じ構成になります。「まず、次に、最後に

Claude Codeを使い始めて、様々な発信をしてきました。今回は「Agent Skills」について。これも設定しておくと、Claude Codeがグッと使いやすくなる機能です。 Claude Code の settings.json は設定した方がいい - じゃあ、おうちで学べる Claude Code の CLAUDE.mdは設定した方がいい - じゃあ、おうちで学べる Claude Code の .claude/commands/**.md は設定した方がいい - じゃあ、おうちで学べる Claude CodeのHooksは設定したほうがいい - じゃあ、おうちで学べる Claude CodeのSubagentsは設定したほうがいい - じゃあ、おうちで学べる はじめに 「このプロジェクトではpython-pptxを使ってスライドを作って」「SQLは必ずこのフォーマットで書いて」

はじめに 「自分の環境では動くんだけど...」という言葉を、何度聞いたことがあるだろうか。開発環境の差異は、これまで「手順書」「Docker」「asdf/anyenv」で解決を試みてきたが、いずれも時間経過で破綻する。手順書は陳腐化し、Dockerfileのベースイメージは変わり、asdfは言語ごとにツールが分散する。問題の本質は「環境の固定」ではなく「依存関係の完全な追跡」にあった。これを根本から解決するのが、純粋関数型パッケージマネージャ「Nix」と、その最新機能「Nix Flake」だ。 これらの課題感については Infrastructure as Code, 3rd Edition が詳しく論じており、参考になる。2025年 俺が愛した本たち 技術書編 に入れれていなくて悲しいほどよい書籍である。オライリー・ジャパンさん 自分は翻訳の準備できてます！！！ Infrastructur

労働こそが最高の学習だった あなたは最近、「成長している」と感じているだろうか。 かつて、プログラマーにとって、労働こそが最高の学習の場だった。なぜか。労働には「摩擦」があったからだ。エラーが出る。原因がわからない。仮説を立てる。試す。失敗する。また試す。この摩擦の中で、経験が意味に変わっていた。労働は、経験を意味に変換する装置だった。 以前の開発を思い出す。新しいフレームワークを覚えなければならない。エラーと格闘して、ドキュメントを読み漁って、やっと動いたとき。あの達成感は、単なる満足ではなかった。「なぜ動かなかったか」「どう直したか」「次に同じ問題が起きたらどうするか」——この因果の記憶が、脳に刻み込まれていた。困難を乗り越えた記録が、自分の中に残っていた。 Claude Codeで開発している今、コードは書ける。動く。レビューも通る。Claude CodeはAnthropicが提供す

はじめに 深夜2時、本番環境のアラートが鳴り響きます。外部APIがタイムアウトを返し始め、リトライが暴発し、システム全体が連鎖的に停止しました。原因を調べると、外部サービスの一時的な遅延でした。たった数秒の遅延が、なぜシステム全体を止めたのか。答えは単純です。「外部APIが遅延したらどうなるか」を、誰もテストしていなかったからです。 私自身、このような障害を何度か経験してきました。コードをマージした翌朝にSlackが炎上していたこともあります。「なぜこのケースを考えなかったのか」と自分を責めながら、ホットフィックスを書いた夜もあります。そのたびに思います。あのとき、たった1つのテストを書いていれば。 これは「異常系テスト」の不足が引き起こした障害です。正常系のテストは比較的書きやすいです。入力があり、期待する出力があり、それを検証します。しかし、プロダクション環境で本当に問題になるのは異常

はじめに 会議室で誰かが「戦略」と言った瞬間、空気が変わる。 みんなの背筋が伸びる。うなずきが深くなる。誰かがおもむろにホワイトボードの前に立ち、矢印を描き始める。私も「なるほど」という顔をしてみる。眉間にしわを寄せ、顎に手を当て、いかにも深く考えているふうを装う。会議室にいる全員が、突然「戦略を理解している側の人間」になる。 ただ、私は知っている。この部屋にいる何人かは、私と同じことを思っているはずだ。 「で、結局、何をするの？」 言えない。絶対に言えない。「戦略」という言葉が持つ重厚感に押しつぶされて、そんな素朴な疑問は喉の奥に引っ込んでしまう。分かっていないことがバレたら終わりだ。「あいつ、戦略を理解していない」というレッテルを貼られたら、もうこの会議室での発言権はない。だから黙る。黙って、賢そうな顔を続ける。 不思議なのは、誰もが同じ演技をしているように見えることだ。部長も、課長も

この記事は、Vim Advent Calendar 2025 13日目のエントリ記事です。 はじめに VSCodeやJetBrains製品は、膨大な開発リソースを投じて作られた最強の武器だ。補完、デバッグ、Git統合、拡張機能——すべてが高度に洗練されている。多くの開発者にとって、これらを選ぶのは賢明な判断だと思う。 それでも、私は自分で刀を打ちたい。 ただし、誤解のないように言っておくと、名刀を打ちたいわけではない。美術館に飾られるような、完璧な一振りを目指しているわけではない。私が欲しいのは、戦場で戦うための道具だ。多少キズがあってもいい。見栄えが悪くてもいい。自分の手に馴染んで、明日の仕事で使えればそれでいい。 では、なぜ自分で作るのか。正直に言えば、効率の問題ではない。もっと根本的な、性分の問題だ。 思い返すと、私は子供の頃から構造や仕組みがどうしても気になって、分解してしまうクセ

はじめに 正直に言う。この文章を書くかどうか、ずいぶん迷った。「専門家はもっと声を上げるべきだ」という意見に対して、「いや、話さないんですよ」と返すのは、なんだか後ろ向きに見えるかもしれない。諦めているように聞こえるかもしれない。そういう風に受け取られるのは、ちょっと嫌だな、と思った。 でも、書くことにした。なぜなら、「話せばいいじゃん」「振りかざせばいいじゃん」という言葉に、ずっと違和感を抱えてきたからだ。その違和感の正体を、自分なりに言葉にしてみたかった。これは、専門家として組織の中で働いてきた、私個人の経験と考えだ。すべての人に当てはまるとは思わない。でも、同じような経験をしている人が、もしかしたらいるかもしれない。そういう人に届いたらいいな、と思いながら書いている。 「専門性の刃で殴りかかってこい」への違和感 「専門家が『力』をセーブせずに全力で専門性を振り回してもリスペクトされる

はじめに 「今年読んで良かった本」という記事を書こうとしている自分に、ふと気づく。また書くのか。毎年書いている。誰に頼まれたわけでもないのに、12月になると決まってこの作業を始めてしまう。習慣なのか、義務感なのか、それとも単なる自己顕示欲なのか。たぶん、全部だ。 100冊近く読んだ、と書こうとして手が止まる。この数字を出した瞬間、どこかで「すごいですね」と言われたい自分がいる。同時に、「いや、冊数なんて意味ないですから」と予防線を張りたがっている自分もいる。めんどくさい人間だ。でも正直に言えば、100冊読んだことより、1冊を血肉にできた人のほうがよほど偉いと本気で思っている。思っているのに、冊数を書いてしまう。そういう矛盾を抱えたまま、この文章を書いている。 AIに聞けば答えは返ってくる。2025年はそういう年だった。コードを書いてもらい、設計を相談し、ドキュメントを要約させた。便利だ。本

集中できなくなった 何かがおかしい。 AIエージェントを使い始めてから、自分が壊れていくのを感じていた。以前は4〜5時間ぶっ通しで集中できた。コードを書き始めたら、気づいたら夕方になっていた。あの没入感。あの充実感。それが、完全に消えた。 30分も持たない。いや、10分だろうか。1つの作業に没頭しようとしても、すぐに別の作業に引き戻される。戻ってきたら、さっき何をしていたか忘れている。頭の中が常にざわついている。自分の脳が、自分のものではなくなっていく感覚があった。 最初は自分を責めた。集中力が落ちたのは、体力のせいか。年齢のせいか。怠けているのか。スマホの見すぎか。でも違った。同じように苦しんでいる人が、周りにもいた。 きっと、最初からうまく馴染める人もいるのだろう。複数のエージェントを同時に回しながら、涼しい顔で成果を出せる人。元々、全体を俯瞰しながら動くのが得意な司令官タイプ。私は違