nwiizo

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認可サーバーを構築する

私の為のNvChadのキーマッピングガイド 2026年版

テスト,検証してますか: cargo-mutantsによるミューテーションテスト入門

はじめに2025年12月31日の夜、パソコンの前でこの文章を書き始めている。Xのフォロワーが1万人を超えたとき、勢いで「おすすめのグラビアを紹介します」と言ってしまった。忙しさを言い訳にして先延ばしにしていたら、年末年始になってしまった。孤独な独身男性が大晦日に書くブログがこれでいいのか。言ってしまったからには書くしかない。普段は技術ブログを書いている。ソフトウェアエンジニアとして、コードの話や設計の話をするのが本分だ。私はグラビア評論家でもなければ、業界関係者でもない。あるのは、彼女たちの作品を見て感じた個人的な感想だけだ。素人の与太話である。合わない人はブラウザバックしてもらって構わない。2025年、生成AIが生成する画像のクオリティは日に日に上がった。「人間である必要があるのか」という問いが、あらゆる領域に突きつけられている。ソフトウェアエンジニアである私も、その問いと無縁ではいられない。AIがコードを書く。AIが画像を生成する。じゃあ私たちは何をすればいいのか。答えは出ていない。そんな中で、彼女たちは諦めていなかった。生成AIには「物語」がない。挫折も、転機も、覚悟もない。彼女たちには、積み重ねてきた時間と、これから歩む道がある。同志のようなものを感じた。この記事では、そうした「代替不可能な物語」を持つ10名を紹介したい。選考基準は単純だ。心に残ったかどうか。それだけである。紹介順に優劣はない。10名のグラビアアイドル紹介菊地姫奈彼女の眼差しには、刃物のような意志と、硝子細工のような脆さが同居している。その矛盾こそが、菊地姫奈という存在を比類なきものにしている。写真集『memory』は「5年間の集大成」と銘打たれた。五年という歳月を、彼女は一冊の書物に封じ込めた。いま彼女は、女優という新たな領域へと歩を進めている。グラビアで培った肉体の言語が、演技という別の器に注がれようとしている。「集大成」とは、すなわち終焉の美学である。散り際を知る者だけが、満開の美しさを手にする。2025年、私はその花吹雪を目撃した。豊島心桜「グラビア界最強のラスボス」。この異名を耳にしたとき、私は失笑した。誇大な修辞だと高を括った。しかし彼女のグラビアを一瞥した瞬間、その異名が寸分の誇張も含まぬことを悟った。遅れて現れた者には、待たせた分だけの凄みがある。クラシックバレエで鍛えられた四肢は、舞台を離れてなお優雅な弧を描く。その肉体には規律が宿っている。女優としての道も拓きつつある彼女は、どの領域においても王者の風格を崩さぬだろう。ラスボスとは、最後に立ちはだかる者のことだ。私などは、まだその城門にすら辿り着いていない。麻倉瑞季麻倉瑞季において、知性と肉体は対立せず、むしろ共犯関係にある。豊満な曲線を誇示したかと思えば、次の瞬間には電子の戦場で剣を振るう。大学への合格、eスポーツチームへの加入。彼女はグラビアアイドルという一つの器に収まることを拒んだ。「推しのために仕事をしている」と彼女は言う。その言葉には一片の虚飾もない。欲望に忠実であることは、ときに最も誠実な生き方となる。天羽希純天羽希純との邂逅は、アイドルグループ「#2i2」を通じてであった。しかし彼女のソログラビアを目にしたとき、アイドルという名の檻では、この獣を囲い込めぬことを知った。彼女は自らを「モンスター」と称する。「アイドル界のモンスター」なるエッセイを連載し、2025年の目標を「エゴイスティックに」と宣言した。怪物とは、既存の秩序に収まらぬ者のことだ。その自覚こそが、彼女の覚悟である。「#2i2」は2025年12月に解散した。終焉へと向かう船上で、彼女はなお踊り続けた。滅びゆくものだけが放つ光がある。私はその残照に灼かれた。一ノ瀬瑠菜2007年生まれ。この事実を知ったとき、私は時の流れの残酷さを思い知った。2025年春、高校を卒業した彼女は、グラビア誌の表紙を次々と征服した。女優としての活動も始まっている。十八歳にしてこの疾走。若さとは、無限の可能性という名の空白である。まだ何者でもない。ゆえに何者にもなれる。その特権を、彼女は惜しげもなく行使している。翻って私は、何者かになれたのだろうか。その問いに答える勇気を、私はまだ持たない。溝端葵「グラビア界の超新星」。2025年、この称号を戴くに最もふさわしき者が溝端葵であった。TikTokでの舞踊が衆目を集め、スカウトの手が伸びた。2025年3月にグラビアの世界へ足を踏み入れ、わずか三ヶ月で表紙を飾るという離れ業を演じた。彗星の如き上昇である。しかし彼女には前史がある。中学三年時、「ミスセブンティーン」の最終選考に残りながら、栄冠を逃した。約十年の歳月を経て、彼女は別の扉を開いた。一度は閉ざされた道の傍らに、もう一つの道が拓けていた。迂回こそが、ときに最短距離となる。そのような物語に、私は抗えない。七瀬なな七瀬ななという存在には、終焉と黎明が同時に宿っている。レースクイーンとして頂点を極めた彼女は、2024年末にその王座を捨てた。そして2025年、女優という未踏の地へと歩み出した。デジタル写真集のタイトルは「HORIZON」。地平線とは、見えているのに決して辿り着けぬ場所のことだ。しかし彼女は、その不可能に向かって歩を進める。幼少期に習得した器械体操を武器に、アクション女優を志すという。一つの頂を極めた者だけが、別の頂への渇望を知る。終わらせる勇気を持つ者だけが、始める資格を得る。花雨「一般OL/趣味グラビア」。花雨のInstagramにはそう記されている。本業は会社員。グラビアは余技に過ぎぬ。しかしその余技に、十三万を超える眼差しが注がれている。趣味という言葉で片付けるには、あまりに多くの魂を捕らえている。彼女は自らの手で写真集を世に送り出す。五島列島の福江島で撮影された「夕星」、沖縄で撮影された「漣」。「花雨屋」なる店舗で販売されるこれらは、いかなる事務所の介在も経ぬ、純粋なる自己表現である。事務所に属さず、テレビに出ず、雑誌の表紙を飾らず。それでも彼女の作品は確かに人心を揺さぶる。職業と趣味の境界を、彼女は軽やかに踏み越える。好きだから撮る。撮りたいから撮る。その純粋さこそが、逆説的に彼女の武器となる。仕事にせぬから続けられる。仕事にしたら続けられぬ。私にも覚えがある。技術ブログを書き続けているのも、誰に頼まれたわけでもない。髙峰じゅり髙峰じゅりは、己がレズビアンであることを公言している。「十六歳で彼女を紹介したら、祖母が泣いた」と語る彼女の言葉には、幾重もの障壁を越えてきた者だけが持つ静かな強さがある。2025年、芸名を改め、新たな幕を開けた。友人と共に撮影会を興し、運営者としての貌も見せる。「グラビアは男性にしか届かぬものと思い込んでいた」と彼女は述懐する。しかし現実には、女性からの声も多く届くという。グラビアの受け手を限定せず、性を隠さず、己を偽らず。その姿勢が、従来の境界の外にいた者たちにも届いている。道を拓く者がいるから、後に続く者が歩みやすくなる。先駆者とは、常に孤独な存在である。もものすけもものすけという存在は、どこか神話的な響きを帯びている。彼女は自他ともに認める恐竜狂である。「ダイナソー」と「アイドル」を掛け合わせ「ダイナドル」の異名を持つ。グラビア、アイドル、声優。彼女の軌跡は複数の線が並走し、交錯し、ときに融合する。いずれが本業でいずれが余技か、そのような問い自体が無粋である。好むものを好むがままに追求した結果、幾つもの貌を持つに至った。2025年も彼女は止まることを知らなかった。太古の巨獣への愛を語り、信奉者と交わり、新たな地平を切り拓き続けている。「もも」が姓で「のすけ」が名であると、本人は主張している。私も「nw」が姓で「iizo」が名だ。そのような戯れを愛する心性において、私は彼女に親近を覚える。おわりに10名の物語を書き終えて、ふと思う。私は何を見ていたのだろうか。時計を見ると12時を超えていた。1月1日に何を書いているのだろう。グラビアアイドルほど自分の器とシビアに向き合っている存在はいない。年齢、体型、表現力、時代との相性。あらゆる要素が容赦なく評価される世界で、彼女たちは走り続けている。女優になりたい人がいる。声優になりたい人がいる。まだ何になりたいか決まっていない人もいる。グラビアは通過点であり、同時に今この瞬間でもある。完成された何かより、途中経過を見る方が心が動く。たぶん、私もまだ途中だからだ。生成AIがいくら精巧な画像を生成しても、そこに物語はない。挫折も、葛藤も、成長もない。彼女たちが持っているのは、代替不可能な身体と、積み重ねてきた時間と、これから歩む道だ。私も同じだ。AIがコードを書く。私もコードを書く。違いは何か。まだわからない。でも、諦めずに問い続ける人たちを見ていると、自分も諦めなくていいと思える。冒頭で「フォロワー1万人を超えた勢いで言ってしまった」と書いた。結局、年末年始に孤独な独身男性がパソコンに向かって書いている。遅れたけど、約束は守った。彼女たちにも物語があるように、私にも物語がある。技術ブログを書き、コードを書き、たまにグラビアの話をする。そういう人間として見届けてくれる人がいる。心に残ったものを素直に書いた。それでいい。2026年、彼女たちの物語は続く。私の物語も、まだ終わっていない。関連する投稿も置いておく。グラビア写真集といえば単なる視覚的刺激として消費されがちだが、そこには各グラドルの努力や作品性、女優やタレントなどを目指しながら頑張る物語、時代ごとの表現の歴史がある。こうした背景や文脈を知るとより深く面白くなる。そんな作品性と物語性を兼ね備えた魅力的な写真集4冊を紹介します。— nwiizo (@nwiizo) 2025年11月12日

2025年 個人的に心に残ったグラビアアイドル10選

はじめに2025年が終わろうとしている。先日、「なぜ『何でも作れる時代』に私は作れないのか」という記事を書いた。「代表作」がないという焦り、量をやることの重要性、そして引き算の必要性。書きながら、自分の弱さと向き合った。syu-m-5151.hatenablog.comあの記事で「2026年は20個作る」と宣言した。その前に、2025年に何を作ったのか振り返っておきたい。振り返ると、この1年は「自分が欲しいもの」をひたすら作り続けた年だった。誰かに頼まれたわけでもなく、バズを狙ったわけでもなく、ただ「これがあったら便利なのに」という衝動に従って、キーボードを叩き続けた。「3回同じ不便を感じたら作る」というルールを自分に課している。cctxは3回目の設定ファイル書き換えで、cargo-autoddは3回目のCargo.toml編集で生まれた。前回の記事で書いた「隙間家具」を、実際に作っていた1年だった。11個のリポジトリを公開し、合計900以上のスターをいただいた。正直に言えば、通知が来るたびに見てしまう。でも、スターが多くても使われないツールはある。逆に、スター10でも毎日使っているツールがある。自分にとっての成功の定義を「毎日使うか」に変えてから、気持ちが楽になった。Claude Codeと過ごした1年2025年は、Claude Codeと共に過ごした年だった、と言っても過言ではない。cctxClaude Codeを使い込むうちに、設定を切り替えたくなる場面が増えた。仕事では制限をかけたい、個人プロジェクトでは自由にやりたい。kubectxを使ったことがある人なら分かるだろうが、あの「サクッと切り替える」感覚が欲しかった。だからcctxを作った。cctx work と打つだけで、仕事モードに切り替わる。cctx - で前のコンテキストに戻る。それだけのツールだが、毎日使っている。毎日使うから、これは成功だ。github.comclaudelyticsClaude Codeをどれくらい使っているのか、可視化したくなった。トークン消費量、コスト、セッションごとの使用パターン。数字で見えると、自分の開発スタイルが見えてくる。TUIを作り込んで、眺めているだけで楽しいものにした。作っていて気づいたことがある。「正確なデータ」より「見たくなるUI」の方が継続利用に繋がる。最初はCSVエクスポートに注力したが、結局TUIの見た目を磨いた時間の方が長かった。github.comccatCLAUDE.mdというファイルが増えてくると、管理が面倒になる。どこに何を書いたか分からなくなる。インポートチェーンが複雑になる。だから分析ツールを作った。地味だけど、自分には必要だった。github.comccswarmこれは少し野心的なプロジェクトだった。複数のAIエージェントを協調させて、大きなタスクを分割して処理する。Git worktreeで並列開発を実現する。「Sangha」という仏教にインスパイアされた民主的意思決定システムを入れたのは、ちょっとした遊び心だ。正直、まだ実験段階で、自分でも使いこなせていない。でも「AIエージェントの協調」という方向性は間違っていないと思っている。来年、もう少し実用的なものにしたい。github.comRustへの愛なぜRustを選ぶのか。理由はシンプルで、ただ好きだからだ。でも「好き」の中身を分解すると、いくつかの要素がある。まず、型システムがAIと相性が良い。Claude Codeにコードを書かせると、Pythonでは「動くけど大丈夫？」という不安が残る。Rustでは、コンパイラが通ればほぼ安全だという確信がある。AIが生成したコードでも、コンパイラが厳しくチェックしてくれる。この安心感は大きい。そして、丁寧なエラーメッセージ。Rustのコンパイラは「ここが間違っている」だけでなく「こうすれば直る」まで教えてくれる。学習を助けてくれる先生のような存在だ。使うほど信頼が増す。所有権や型システムの「難しさ」は、将来の保守性を高めるための設計だと理解している。大規模・長期運用での事故を防ぐための仕組み。楽ではないが「裏切らない」という安心感がある。だから何度でも選ぶ。cargo-autoddRustを書いていると、Cargo.tomlの依存関係管理が面倒になることがある。ソースコードにuse serde_jsonと書いたら、自動で依存関係に追加してほしい。逆に、使わなくなったcrateは消してほしい。そんな怠惰な願望から生まれたツール。作っていて学んだことがある。ASTパーサーを書いていた。「完璧に解析する」より「80%の精度で10倍速い」方がユーザー体験は良い。完璧主義がUXを損なう好例だった。github.comcargo-couplingVlad Khononovの「Balancing Coupling in Software Design」を読んで感銘を受けた。結合度と凝集度のバランス、距離と変更頻度の関係。これをRustプロジェクトで可視化したら面白いんじゃないか。そう思って作り始めたら、想像以上に深い世界が広がっていた。Web UIを付けて、グラフを眺められるようにした。自分のコードを分析した。予想以上に結合度が高いモジュールを発見した。「ここ、分割した方がいいな」と気づけたのは収穫だった。ツールを作ることで、自分のコードの問題が見えてくる。github.comcargo.nvimNeovimでRustを書いている。:CargoBuildと打つだけでビルドが走り、フローティングウィンドウに結果が表示される。エディタから手を離さずに開発サイクルを回せる。些細なことだけど、この積み重ねが開発体験を変える。github.comTerraformとの格闘インフラをコードで管理するのは素晴らしい。でも、時にはTerraformと格闘することもある。tfmcpAIにインフラを任せるのは危険か。答えは「条件による」だ。tfmcpで設けた制限は3つ。本番環境は読み取り専用。全操作の監査ログを記録。destructiveな変更は人間の承認必須。この制限下なら、AIはterraform planを高速で回す優秀なアシスタントだ。危険なのは「AIに任せること」ではなく、「制限なく任せること」だ。この区別が重要だと、作りながら実感した。github.comtfocusTerraformのリソースターゲティングは麻薬だ。一度使うと「今回も大丈夫」と手が伸びる。状態の不整合が蓄積し、ある日terraform applyが破滅的な差分を出す。それでもtfocusを作ったのは、消防士にも斧が必要なように、障害対応には「禁じ手」が要るからだ。peco風のインタラクティブUIを付けて、素早くリソースを選択できるようにした。READMEに「緊急用ツール」と明記した。日常使いした瞬間、このツールは害になる。github.com開発者のための小さな道具たちvibe-ticketチケット管理システムは世の中に溢れている。Jira、Linear、GitHub Issues。でも、ターミナルで完結する、Git worktreeと統合された、開発者のためのチケット管理が欲しかった。MCPサーバーとしても動くようにした。AIアシスタントに「さっき見つけたバグのチケット作って」と言えば、作ってくれる。github.cominstrument-rsオブザーバビリティは大切だ。でも、どこにトレースを入れるべきか、どこにログを仕込むべきか、判断が難しい。コードを静的解析して、「ここに入れるといいよ」と教えてくれるツールがあれば便利だと思った。HTTPエンドポイントから実行パスをトレースして、クリティカルパスを特定する。まだ実験的なプロジェクトだけど、可能性を感じている。github.com失敗と学び11個公開したが、実は3個はアーカイブした。最初に作ったツールは設計が甘く、2週間で書き直した。公開して反応ゼロだったものもある。前回の記事で「捨てやすく作る」と書いた。アーカイブした3個は、まさにそれを実践した結果だ。状況が変わって不要になったもの、設計を間違えたもの。捨てることに罪悪感はない。役目を終えただけだ。ヒットの予測は難しい。「これは絶対使われる」と思ったものがスター20で止まり、「まあ自分用だし」と思ったcctxが一番使われている。予測できないなら、作りたいものを作るしかない。前回の記事で「量をやることで、初めて見えてくるものがある」と書いた。11個作って、ようやくその意味が分かってきた。最後にccswarmを公開して3日後、見知らぬ人からIssueが来た。「この機能を追加してほしい」と。実装して返信したら「ありがとう」と返ってきた。それだけのやり取りだったが、不思議と孤独じゃなくなった。顔も知らない人と、コードで繋がる感覚。SNSのいいねとは違う何かがあった。前回の記事で「代表作がない」と書いた。11個作っても、まだ「これだ」とは言えない。でも、前より近づいている気がする。2025年の11個は、2026年の20個への助走だ。すべてのプロジェクトはMITライセンスで公開している。もしあなたが「こんなツールがあれば」と思っているなら、まず作ってみてほしい。完璧じゃなくていい。私のツールも初版はバグだらけだった。READMEを書いて、v0.1.0をリリースする。それだけで世界が変わる。使ってくれる人がいるかもしれない。いなくても、自分が使えばいい。2025年、ありがとう。2026年は、もっと狂う。

2025年、nwiizoが作ったソフトウェア

はじめに誰もまとめてくれないので自分でまとめます。こんなに悲しいことはありません。2025年11月から12月にかけて、「おい、〜」というシリーズでブログを15本書きました。登壇もしました。合計16本です。誰かがまとめ記事を書いてくれるかなと思っていました。待っていました。誰も書いてくれませんでした。年末です。仕方がないので自分で書きます。シリーズの始まり今年の8月、本を書かないかという話が来ました。嬉しかったです。企画を練りました。構成を考えました。8月、9月、10月といろいろやり取りをしていたのですが、いろんな諸事情で立ち消えになりました。悔しかったです。本を出せなかったことが悔しかったのではない。結局何にもならなかった自分が悔しかった。もっと準備できたはずだ。もっと詰められたはずだ。その後悔が残りました。でも、本の企画のために書いた下書き原稿が8本くらいありました。本にならないなら、ブログに書けばいい。そう思って始めたのが「おい、〜」シリーズです。30歳になったこともきっかけでした。5月に「20代最後の一週間を生きるエンジニア、あるいは30歳の扉の前でうろたえる男の独白」というとても長いブログを書きました。20代が終わることへの焦り、不安、でも少しの期待。そのときに声かけていただいたのが、「おい、〜」シリーズとして出てきたものです。syu-m-5151.hatenablog.com20代の頃は「なんでもできる」と思っていました。30代になって、「できない」を認められるようになった。それは諦めではなく、等身大の自分を見つめられるようになったということです。15本を通して書いていたのは、結局そのことだったのかもしれません。「おい、部屋を掃除しろ」から始まりました。下書きを消化したあとも、言いたいことが止まらなくなりました。無限に書いても良くないので、週に1回のペースに決めました。自分を律するために「おい、週一で書け」とは書きませんでした。結果、15本になりました。15本の記事は、3つのカテゴリに分かれます。まず生活の基盤を整え、次に思考を鍛え、最後にその思考で仕事や人間関係に臨む。この順番で読む必要はありませんが、私の中ではこの流れがありました。生活習慣編おい、部屋を掃除しろ掃除の話ではありません。自分を大切に扱う習慣の話です。部屋が汚い人間に、コードをきれいに書けるわけがない。因果関係なんてないし、汚い部屋の凄腕エンジニアなんていくらでもいる。でも、知っている人はみんな適当な時期に結婚などしてなんとかなったか、心か身体を壊して生活を改めたか、消えていった。因果はわからないが、意味のわからない経験則としてある。毎日5分の掃除から始める規律の美学について書きました。syu-m-5151.hatenablog.comおい、一つずつやれSlack、メール、GitHub、全部同時に見ていると「忙しいのに何も終わらない」状態になります。これはおそらく忙しいのではなく、大量のタスク切り替えに対してコストを払っているだけです。仕事ができる人のイメージは、勝手に「マルチタスクができる人間」だと思っていました。しかし自分にその力はどうやらなさそうで、実際できていませんでした。ただ能力の限界まで「中途半端を量産する人間」でした。1日25分、1つのことだけに集中することから始めました。タスク切り替えの過払い金を整理した、という表現が正しいかもしれません。syu-m-5151.hatenablog.comおい、スマホを置け技術書が読めない。集中力が続かない。意志が弱いのだと思っていました。違いました。スマホに最適化された脳でした。私たちの世代は高校生の頃からスマホに触れてきた。15秒ごとに報酬をくれるアプリに慣れた脳が、30分かけて一つの概念を理解する作業に耐えられるわけがない。これは人生が壊れるな、という実感がありました。自分より下の世代は、もっと大変だろうなと思いました。syu-m-5151.hatenablog.comおい、本を読め「本を読まない人は生き残れない」という強迫的なメッセージへの違和感があります。いつから読書は「生き残るための手段」になったのか。効率的に知識を得るための読書は続かない。義務感で読む本は頭に入らない。ただ楽しいから読む。それだけでいい。そういう価値観もあるのだと、知ってもらえたらと思っていました。私は今も、子供の頃に初めて図鑑を開いたときと同じ気持ちで本を読んでいます。正直、楽しければなんでもいいと思っています。読者やフォロワーが楽しんで、結果として生き残ってくれれば、それでいい。syu-m-5151.hatenablog.comおい、休め休んでいるのに休めていない、という問題があります。ソファで横になってスマホを見ている。一見すると堕落の象徴のようでもあり、休息のようでもある。しかし残念ながら、これは休息ではありません。低負荷の作業です。脳は休んでいない。判断を続けている。スクロールするかどうか。この動画を見るかどうか。このツイートに反応するかどうか。AI時代は判断を求められる機会が増える一方です。現代では意識的に「何もしない」時間を作らないと、脳が壊れます。「じゃあお前はブログを書き続けて休んでないじゃないか」という指摘があると思いますが、その鋭い刃は収めていただけると助かります。syu-m-5151.hatenablog.com思考法編おい、冷笑すんなインターネットと冷笑は、相性が良すぎます。140字で専門家を論破した気になれる。何年も積み上げてきた人の仕事を、背景も知らずに「それ、意味あるんですか」と切り捨てられる。「専門性なんて要らない」「結局ポジショントークでしょ」——そんな言葉が、何も作ったことのない人から発せられている。私自身、視野を広げすぎて世界の複雑さに圧倒され、冷笑主義に陥った経験があります。何を見ても「まあ、そうなるよね」「どうせ変わらないよ」と思うようになっていた。達観した気になっていた。賢くなった気がしていた。違った。何も生み出さない人間になっていただけでした。冷笑は「どうせ無理」で終わる。批判は「ここがダメ」で終わる。批評は「ここがダメだから、こうすればいい」まで踏み込む。私は冷笑で止まっていた。一番楽で、一番何も残らない場所に。若い頃に冷笑してきたものが、今になって本当に大切だとわかる。それが少し悔しい。syu-m-5151.hatenablog.comおい、内省しろ内省と反省は違います。反省は「悪かった、次は気をつけます」で終わる。そして同じミスを繰り返す。私がそうでした。何度も反省した。何度も同じ失敗をした。反省とは、過去に頭を下げる行為でしかなかった。内省は違う。「なぜそうなったのか」を掘り下げて、構造を理解し、仕組みごと変えるプロセスです。自分を責めるのではなく、自分を観察する。毎日30秒でいい。寝る前に「今日、なぜあの判断をしたのか」を考える。それだけで少しずつ変わります。syu-m-5151.hatenablog.comおい、言語化しろ2025年、言語化神話が爆誕しました。「言語化できれば理解できる」「言語化できないのは思考が浅い証拠」——そんな空気が広がっている。確かに、言葉にできない領域があまりに広い人にとっては、その神を信じることで救われることもあります。言葉にする努力が思考を前に進めることもある。しかし、普通の大人には言語化できないものがあります。「なんとなくこっちの方がいい」という直感。説明できないけど手が動く技術。身体に染み込んだ知識、実践の中で培われた勘、創造的な跳躍、感情ヒューリスティック。これらを全部言葉にしようとすると、かえって嘘になる。言葉にした瞬間、丸められる。削られる。本当はもっと複雑で、矛盾していて、揺らいでいるものが、きれいに整理された途端に別物になる。「完璧に言語化できた」と思ったら、何か大事なものを落としている証拠かもしれない。不完全な変換でいい。「まだ言葉にできない何か」を抱えている感覚こそが、次の成長を生みます。syu-m-5151.hatenablog.comおい、つなげろ問題解決には「つなげること」と「断つこと」の両面があります。知識と知識をつなげて解決策を見つける。異なる領域の経験を結びつけて、新しい発想を得る。しかし、間違ったつながりを断つ勇気も必要です。「前もこうだったから」という過去の成功体験が、今回の失敗を招くことがある。AIに聞けば答えは出る。でも、自分でつなげる経験をしないと、応用が効かない。なぜその答えに至ったのか、プロセスが身につかない。「AIが教えてくれた答え」と「自分で見つけた答え」は、同じ答えでも身につき方が違う。苦労して見つけた答えは、次の問題を解く足場になる。与えられた答えは、その場で消える。syu-m-5151.hatenablog.comおい、類推するな所有権を「本の貸し借り」に例えて理解しました。わかった気になりました。腹落ちした感覚すらあった。しかし実際にコードを書いたら、例えが成立しない場面だらけでした。本は返却されても同じ本だが、所有権はそうではない。そういう経験は意識的にも無意識的にもやってしまうと思います。類推は便利ですが危険です。複雑なものを飲み込みやすくする代わりに、本質からズレた理解を植えつける。入り口としては使える。でも、判断するときは具体に戻る。「本の貸し借りだから...」ではなく「Rustの所有権のルールでは...」で考える。例え話で納得したら、そこで立ち止まって、例えを捨てる勇気を持つ。syu-m-5151.hatenablog.com仕事・対人編おい、対話しろ会議で「話しているが対話していない」場面があります。みんな口だけは喋っている。でも誰も聞いていない。相手の発言が終わるのを待っているだけ。その間に自分の意見を頭の中で整理している。相手の言葉を受けて考えを変える気がない。これは対話ではない。順番にモノローグを発表しているだけです。対話の本質は、相互の世界観を認識し、理解を深めるプロセスにある。相手の言葉を聞いて、自分の考えが変わる余地を残す。論破ではなく理解を目指す。勝ち負けではない。「なるほど、そういう見方もあるのか」が対話の成果です。syu-m-5151.hatenablog.comおい、がんばるな「頑張ること自体が目的化していた」という反省があります。遅くまで残って、休日も働いて、「頑張っている自分」に酔っていた。忙しさを充実感と錯覚していた。成果は出ていなかった。いや、正確には見ていなかった。過程に満足して、結果を直視していなかった。環境とのミスマッチを認識し、持続可能なペースに切り替えたら、むしろ成果が出るようになった。頑張りを減らしたのに成果が増える。皮肉だが、これが現実だった。公開した翌日、「いや、待てよ」と思いました。syu-m-5151.hatenablog.comおい、努力しろ前日の「がんばるな」への自己反論です。24時間で意見が変わりました。というわけではないです。読者は混乱したと思います。「頑張らなくていい」という言葉が、怠惰の免罪符として使われる危険性に気づいた。「無理しなくていい」が「やらなくていい」にすり替わる瞬間がある。量をこなさないと見えない景色がある。苦しみを乗り越えた経験がないと、乗り越え方がわからない。限界を知るには、一度限界まで行く必要がある。矛盾しているように見えますが、矛盾していません。両方本当です。「頑張りすぎるな」と「頑張らないと見えないものがある」は、同時に成り立つ。問題は、今の自分がどちら側にいるかを見極めることです。syu-m-5151.hatenablog.comおい、戦略を語れ「戦略」という言葉が形骸化しています。「戦略的に進めましょう」と言う人に「具体的にどういう戦略ですか」と聞くと、答えられないことが多い。「戦略」が「なんとなく賢そうな進め方」の意味になっている。戦略の本質は「何をやらないかの選択」です。全部やるのは戦略ではない。総花的にリソースを配分するのは、戦略がないことの証明です。限られた時間とエネルギーを、どこに集中させるか。何を意図的に捨てるか。エンジニアも「これは作らない」と言える立場になるべきです。「作れるけど作らない」という判断ができることが、本当の技術力かもしれません。syu-m-5151.hatenablog.comおい、論理で人が動くと思ってるのか論理的に正しい提案でも通らないことがあります。データを揃えた。根拠を示した。反論の余地がないほど完璧な提案書を作った。却下されました。なぜか。人は論理だけでは動かない。正しさだけでは、心が動かない。「このシステムは非効率です」より「先月、この非効率のせいで3時間残業しました」の方が通る。数字より、1人の体験談。グラフより、具体的な苦労話。人は物語で納得し、論理で自分を正当化する。だから、まず物語で心を動かし、その後で論理を添える。順番が逆だった。完璧な論理を用意する前に、「誰の、どんな困りごとを解決するのか」を語るべきでした。syu-m-5151.hatenablog.com登壇12月5日、Forkwell Communityで「おい、テックブログを書け」という登壇をしました。元々文章が苦手でした。今も苦手です。それでも書き続けたら、登壇を頼まれるようになりました。苦手なまま登壇しています。緊張で声が震えます。けれど登壇しています。出発点の低さは到達点を決めない。苦手なまま続けて消えていった人も山ほど見てきた。違いは何か。苦手なことを自覚した上で、苦手なまま出す覚悟をした。完璧を目指していたら続かなかった。syu-m-5151.hatenablog.com何を言いたかったのか15本を書いていて気づいたことがあります。それぞれの記事がつながっていく感覚がありました。「スマホを置け」と「休め」、「内省しろ」と「言語化しろ」。しかし同時に、全く反対のことも言っている。「がんばるな」の翌日に「努力しろ」。一貫性がない。でも、そういうものだと思っています。「おい、〜」シリーズは、飲み屋で語りたいことを適当に語っているような記事です。整合性を気にしていたら書けなかった。完璧を目指してたら書けなかった。矛盾だらけの15本ですが、振り返ると1つだけ共通点がありました。どの記事も「手段が目的化していないか」を問うていた気もする。掃除も、読書も、努力も、論理も、すべて何かのための手段です。その「何か」を見失っていた。効率と最適化に追われて、「なぜそれをやるのか」という問いを忘れていた。タスクをこなすことが目的になり、タスクの先にある価値を見失っていた。15本を通して言いたかったのは、そのことです。スマホで時間を潰すな。マルチタスクで忙しいふりをするな。冷笑で賢いふりをするな。論理だけで人を動かそうとするな。がんばることを目的にするな。でも努力から逃げるな。矛盾だらけです。人間は矛盾しています。それでいいと思っています。おわりに本の企画が立ち消えになったとき、正直落ち込みました。でも結果的に、ブログという形で書きたいことを全部書けた。本になっていたら、編集者に「矛盾してます」と言われて、どちらかを削っていたと思います。ブログでよかった。15本も書いて、誰も読んでいないかもしれません。誰もまとめてくれなかったということは、そういうことなのでしょう。あるいは、みんな忙しいだけかもしれない。そう思うことにしています。それでも書きました。自分のために書きました。30歳の自分から、40歳の自分への手紙です。「おい、お前、ちゃんとやってるか」10年後に読み返して、恥ずかしくなるかもしれません。「やっぱり正しかった」と思うかもしれません。どちらでもいい。でも、同じことを書いていたら。同じ悩みを抱えていたら。40歳の自分がこれを読んで、何も変わっていなかったら。それが一番怖い。来年も書きます。誰かがまとめてくれることを期待しています。でも、たぶんまた自分でまとめることになる。飽きたらやめます。だから普通に褒めてください。人に勧めてください。このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。

おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、

おい、論理で人が動くと思ってるのか

2025年 俺が愛した本たち 非技術書編

2025年、AI時代の要件定義について考える

 Rustにしたのに遅い？─ N+1クエリ問題の発見と解決

はじめにテストを書いていて、奇妙なことに気づいた。合計金額のアサーションが通らない。期待値は10.00なのに、実際の値は9.99999999999983。コードにバグはない。SQLも正しい。では何が問題なのか。調べた結果、犯人は浮動小数点の累積誤差だった。金額カラムにDOUBLE PRECISIONを使っていたのです。これは「浮動小数点の罠」とも呼ばれる、DB設計やアプリケーションの実装で陥りやすい問題だ。RustとPostgreSQLでWebサービスを構築する際に注意すべき点の1つで、金融システムや科学計算、測定データ、座標、パーセンテージなど、正確な数値が必要なあらゆる場面で問題になります。2進数と10進数の不一致コンピュータは2進数で数値を表現します。しかし、私たちが日常使う10進数の多くは2進数で正確に表現できません。0.1 (10進数) = 0.0001100110011... (2進数・無限循環小数)これはPostgreSQLやRustの問題ではなく、IEEE 754（コンピュータが小数を扱う国際標準規格）に基づくすべてのシステムに共通する問題です。fn main() {    let a = 0.1_f64;    let b = 0.2_f64;    let c = a + b;    println!("{} + {} = {}", a, b, c);    // 出力: 0.1 + 0.2 = 0.30000000000000004    println!("0.1 + 0.2 == 0.3 ? {}", c == 0.3);    // 出力: false}PostgreSQLの数値型PostgreSQLには大きく分けて3種類の数値型があります。浮動小数点型（近似値）浮動小数点型は近似値を扱う型で、内部的にはIEEE 754形式（2進数の浮動小数点）で表現されます。REAL（FLOAT4とも呼ばれる）は4バイトのストレージを使用し、有効桁数は6桁です。センサーデータやグラフィックスなど、高い精度を必要としない場面に適しています。DOUBLE PRECISION（FLOAT8とも呼ばれる）は8バイトを使用し、有効桁数は15桁に拡張されます。科学計算や座標データなど、より高い精度が求められる場面で使用します。任意精度型（正確値）NUMERIC（またはDECIMAL）は正確な計算が必要な場面で使用する型です。ストレージは可変長で、4桁ごとに2バイトを消費します。最大131,072桁までの精度をサポートしており、金額計算などで威力を発揮します。なお、PostgreSQLではNUMERICとDECIMALは完全に同一の型として扱われます。整数型整数型は小数を含まない数値を扱います。INTEGERは4バイトで±21億の範囲を扱え、カウンターやIDに適しています。BIGINTは8バイトで±922京という広大な範囲をカバーし、大きな整数やセント単位での金額格納に使用できます。問題が発生する具体的な場面1. 等価比較の失敗-- PostgreSQLで確認SELECT 0.1::float8 + 0.2::float8 = 0.3::float8;-- 結果: falseSELECT 0.1::numeric + 0.2::numeric = 0.3::numeric;-- 結果: trueこれはWHERE句での検索に影響します。-- 見つからない可能性があるSELECT * FROM measurements WHERE value = 0.3;-- 確実に動作SELECT * FROM measurements WHERE ABS(value - 0.3) < 0.0001;2. 累積誤差-- 0.01を1000回加算CREATE TABLE test_float (amount DOUBLE PRECISION);CREATE TABLE test_numeric (amount NUMERIC(10,2));INSERT INTO test_float SELECT 0.01 FROM generate_series(1, 1000);INSERT INTO test_numeric SELECT 0.01 FROM generate_series(1, 1000);SELECT SUM(amount) FROM test_float;-- 結果: 9.99999999999983（期待値: 10.00）SELECT SUM(amount) FROM test_numeric;-- 結果: 10.00（正確）誤差は小さく見えますが、0.00017の誤差でも1000万レコードでは1700の誤差になります。月次決算で170万円ずれる可能性があるのです。3. 丸め方法の違いPostgreSQLのNUMERICとFLOATでは丸め方法が異なります。SELECT x,  round(x::numeric) AS numeric_round,  round(x::double precision) AS float_roundFROM (VALUES (-2.5), (-1.5), (1.5), (2.5)) AS t(x); x  NUMERIC  FLOAT  -2.5  -3  -2  -1.5  -2  -2  1.5  2  2  2.5  3  2 NUMERIC: ゼロから遠い方へ丸める（Midpoint Away From Zero）FLOAT: 最近偶数へ丸める（Banker's Rounding / IEEE 754）この違いは、同じ計算でも型によって結果が異なることを意味します。ドメイン別：FLOATを使えるか使用を避けるべき場面 ドメイン  理由  推奨型  金額・会計  1円/1セントの誤差も許されない  NUMERIC  税率・割引率  正確な計算が必要  NUMERIC  合計が一致すべきパーセンテージ  33.33% × 3 = 100%が必要  NUMERIC  統計的有意性  p値の正確な比較  NUMERIC  監査証跡  再現可能性が必要  NUMERIC FLOATが許容される場面 ドメイン  理由  推奨型  センサーデータ  センサー自体の誤差 > FLOAT誤差  DOUBLE PRECISION  座標（GPS）  15桁精度で十分（1cm精度には7桁で十分）  DOUBLE PRECISION  温度・湿度  測定誤差が大きい  REAL or DOUBLE PRECISION  レーティング平均  表示時に丸める  DOUBLE PRECISION  グラフィックス  視覚的に認識できない  REAL 判断のフローチャート数値型を選択する際は、まず正確な10進数表現が必要かどうかを考えます。金額や税率など、誤差が許されない値を扱う場合は、迷わずNUMERIC/DECIMALを選択してください。正確な10進数表現が不要な場合は、次に必要な精度を検討します。15桁を超える精度が必要であれば、浮動小数点型では対応できないため、やはりNUMERICを使用します。15桁以下の精度で十分な場合は、ストレージ効率を考慮して浮動小数点型を選びます。6桁程度の精度で事足りるなら、4バイトで済むREALが適しています。それ以上の精度が必要であれば、8バイトのDOUBLE PRECISIONを選択してください。解決策1：適切な型の選択スキーマ設計例CREATE TABLE measurements (    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),    -- 正確さが必要な値    price NUMERIC(10, 2) NOT NULL,    tax_rate NUMERIC(5, 4) NOT NULL,    -- 近似値で十分な値    temperature DOUBLE PRECISION,    latitude DOUBLE PRECISION,    longitude DOUBLE PRECISION,    -- 整数で表現できる値    quantity INTEGER NOT NULL,    price_cents BIGINT,  -- 代替：セント単位格納    -- 制約    CONSTRAINT valid_tax_rate CHECK (tax_rate >= 0 AND tax_rate <= 1),    CONSTRAINT valid_latitude CHECK (latitude BETWEEN -90 AND 90),    CONSTRAINT valid_longitude CHECK (longitude BETWEEN -180 AND 180));precision（精度）とscale（スケール）の設計NUMERICはNUMERIC(precision, scale)の形式で定義します。precisionは全体の有効桁数、scaleは小数点以下の桁数を指定します。用途に応じた設定例を紹介します。一般的な金額にはNUMERIC(10, 2)が適しており、-99,999,999.99から99,999,999.99までの範囲を格納できます。税率や割引率にはNUMERIC(5, 4)を使用し、0.0000から0.9999までの値を扱えます。より細かい精度が必要な場面では、暗号通貨なら小数部8桁を確保できるNUMERIC(16, 8)、為替レートなら小数部6桁のNUMERIC(10, 6)が適切です。科学的測定など高精度が求められる場合は、NUMERIC(15, 10)のように大きな精度を確保してください。解決策2：Rustでの適切な型選択f64の限界を理解するfn demonstrate_float_issues() {    // 等価比較の問題    let a = 0.1_f64 + 0.2_f64;    let b = 0.3_f64;    assert!(a != b);  // 等しくない！    // 累積誤差    let mut sum = 0.0_f64;    for _ in 0..1000 {        sum += 0.01;    }    println!("1000 × 0.01 = {}", sum);  // 9.999999999999831    // 大きな値での精度損失    let big = 1_000_000_000_000_000.0_f64;    let next = big + 1.0;    println!("{} + 1 = {}", big, next);  // 変化しない可能性}rust_decimalクレート正確な10進数計算が必要な時は以下を使用します。[dependencies]rust_decimal = { version = "1", features = ["db-postgres"] }rust_decimal_macros = "1"sqlx = { version = "0.8", features = ["postgres", "rust_decimal"] }use rust_decimal::Decimal;use rust_decimal_macros::dec;use std::str::FromStr;// 生成方法let d1 = dec!(19.99);                      // マクロ（推奨）let d2 = Decimal::from_str("19.99")?;      // 文字列からlet d3 = Decimal::new(1999, 2);            // 整数 / 10^scale// f64からの変換は精度損失の可能性あり（避ける）let risky = Decimal::from_f64(19.99);      // Option<Decimal>浮動小数点の比較方法f64を使う場合、等価比較には専用クレートを使用します。use approx::{abs_diff_eq, relative_eq};let a = 0.1_f64 + 0.2_f64;let b = 0.3_f64;// 絶対誤差での比較assert!(abs_diff_eq!(a, b, epsilon = 1e-10));// 相対誤差での比較（大きな値でも適切に動作）assert!(relative_eq!(a, b, epsilon = 1e-10));丸め戦略の選択rust_decimalは複数の丸め戦略をサポートしています。use rust_decimal::prelude::*;use rust_decimal::RoundingStrategy;let value = dec!(2.5);// 各戦略の結果value.round_dp(0)  // MidpointNearestEven: 2（デフォルト）value.round_dp_with_strategy(0, RoundingStrategy::MidpointAwayFromZero)  // 3value.round_dp_with_strategy(0, RoundingStrategy::ToZero)  // 2（切り捨て）value.round_dp_with_strategy(0, RoundingStrategy::AwayFromZero)  // 3（切り上げ） 戦略  説明  2.5  -2.5  用途  MidpointNearestEven  Banker's丸め  2  -2  統計、科学計算  MidpointAwayFromZero  四捨五入  3  -3  一般的な丸め  ToZero  切り捨て  2  -2  税額計算（日本）  AwayFromZero  切り上げ  3  -3  天井関数的  ToPositiveInfinity  正方向へ  3  -2  ceil  ToNegativeInfinity  負方向へ  2  -3  floor 解決策3：sqlxとの連携型マッピング PostgreSQL  Rust  特徴  REAL  f32  近似値、高速  DOUBLE PRECISION  f64  近似値、高速  NUMERIC  Decimal  正確、やや遅い  BIGINT  i64  整数、最速 構造体定義use rust_decimal::Decimal;use sqlx::FromRow;use uuid::Uuid;#[derive(Debug, FromRow)]struct Product {    id: Uuid,    name: String,    price: Decimal,           // NUMERIC → Decimal    weight_kg: f64,           // DOUBLE PRECISION → f64（測定値）}#[derive(Debug, FromRow)]struct SensorReading {    id: Uuid,    temperature: f64,         // センサー誤差 > FLOAT誤差    humidity: f64,    latitude: f64,    longitude: f64,    recorded_at: chrono::DateTime<chrono::Utc>,}クエリ例use rust_decimal_macros::dec;// 正確な計算が必要な場合async fn calculate_total(pool: &PgPool, order_id: Uuid) -> Result<Decimal, sqlx::Error> {    sqlx::query_scalar!(        r#"        SELECT COALESCE(SUM(price * quantity), 0)::NUMERIC as "total!"        FROM order_items        WHERE order_id = $1        "#,        order_id    )    .fetch_one(pool)    .await}// 近似値で十分な場合async fn get_average_temperature(pool: &PgPool) -> Result<f64, sqlx::Error> {    sqlx::query_scalar!(        r#"SELECT AVG(temperature) as "avg!" FROM sensor_readings"#    )    .fetch_one(pool)    .await}解決策4：整数による固定小数点最もシンプルで高速な方法を紹介します。CREATE TABLE products (    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),    name VARCHAR(200) NOT NULL,    price_cents BIGINT NOT NULL,  -- $19.99 → 1999    CONSTRAINT positive_price CHECK (price_cents > 0));/// 型安全な金額ラッパー#[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)]struct Cents(i64);impl Cents {    fn new(cents: i64) -> Self {        Self(cents)    }    fn from_dollars(dollars: i64, cents: i64) -> Self {        Self(dollars * 100 + cents)    }    fn dollars(&self) -> i64 {        self.0 / 100    }    fn cents_part(&self) -> i64 {        self.0.abs() % 100    }}impl std::fmt::Display for Cents {    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {        if self.0 < 0 {            write!(f, "-${}.{:02}", self.dollars().abs(), self.cents_part())        } else {            write!(f, "${}.{:02}", self.dollars(), self.cents_part())        }    }}impl std::ops::Add for Cents {    type Output = Self;    fn add(self, other: Self) -> Self {        Self(self.0 + other.0)    }}impl std::ops::Sub for Cents {    type Output = Self;    fn sub(self, other: Self) -> Self {        Self(self.0 - other.0)    }}利点:- 整数演算は常に正確- 最高のパフォーマンス- ストレージ効率が良い（8バイト固定）欠点:- 小数部の桁数が固定- 乗除算後に桁調整が必要パフォーマンスとストレージの比較 型  ストレージ  演算速度  正確性  REAL  4バイト  最速（FPU）  近似  DOUBLE PRECISION  8バイト  高速（FPU）  近似  BIGINT  8バイト  高速（整数演算）  正確  NUMERIC(10,2)  約9バイト  遅い（ソフトウェア）  正確  NUMERIC(19,4)  約13バイト  遅い  正確 大量データの集計ではFLOATが10〜100倍高速になることもあります。しかし、正確性が必要な時はNUMERICを使用してください。実践例ハイブリッドアプローチ-- 生データはFLOAT、集計結果はNUMERICCREATE TABLE sensor_data (    id BIGSERIAL PRIMARY KEY,    reading DOUBLE PRECISION NOT NULL,    recorded_at TIMESTAMPTZ NOT NULL);CREATE TABLE daily_summary (    date DATE PRIMARY KEY,    avg_reading NUMERIC(10, 4) NOT NULL,  -- 集計は正確に    min_reading NUMERIC(10, 4) NOT NULL,    max_reading NUMERIC(10, 4) NOT NULL);-- 集計時にNUMERICへ変換INSERT INTO daily_summarySELECT    DATE(recorded_at),    AVG(reading)::NUMERIC(10, 4),    MIN(reading)::NUMERIC(10, 4),    MAX(reading)::NUMERIC(10, 4)FROM sensor_dataGROUP BY DATE(recorded_at);生成列で自動計算CREATE TABLE invoices (    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),    subtotal NUMERIC(10, 2) NOT NULL,    tax_rate NUMERIC(5, 4) NOT NULL DEFAULT 0.10,    -- 自動計算される生成列    tax_amount NUMERIC(10, 2) GENERATED ALWAYS AS (        ROUND(subtotal * tax_rate, 2)    ) STORED,    total NUMERIC(10, 2) GENERATED ALWAYS AS (        subtotal + ROUND(subtotal * tax_rate, 2)    ) STORED);座標データの精度CREATE TABLE locations (    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),    name VARCHAR(200) NOT NULL,    -- DOUBLE PRECISIONで十分（15桁 > 必要な7桁）    latitude DOUBLE PRECISION NOT NULL,    longitude DOUBLE PRECISION NOT NULL,    -- 高精度が必要な場合のみNUMERIC    survey_latitude NUMERIC(11, 8),   -- 1mmレベルの精度    survey_longitude NUMERIC(12, 8),    CONSTRAINT valid_coords CHECK (        latitude BETWEEN -90 AND 90 AND        longitude BETWEEN -180 AND 180    ));座標の精度と実距離の対応を以下に示します。 小数点の桁数  精度  2桁  約1.1km  4桁  約11m  6桁  約11cm  8桁  約1.1mm rust_decimalの制限事項 項目  rust_decimal  PostgreSQL NUMERIC  最大値  約7.9×1028  10131072 - 1  最小スケール  10^-28  10^-16383  ストレージ  16バイト固定  可変長 PostgreSQLからの読み込み時に範囲外の値があるとエラーになります。非常に大きな精度が必要な時はbigdecimalクレートを検討してください。チェックリストスキーマ設計時[ ] FLOATを使う前に「近似値で本当に問題ないか」を確認[ ] 金額・税率・割引率にはNUMERIC/DECIMALを使用[ ] precision/scaleは将来の拡張を考慮して設定[ ] 座標データは用途に応じた精度を選択[ ] センサーデータはセンサー精度を考慮して型を選択Rust実装時[ ] 正確な計算にはrust_decimalを使用[ ] f64の等価比較にはapproxクレートを使用[ ] 丸め戦略を明示的に指定[ ] f64からDecimalへの変換は避ける（文字列経由で）おわりに冒頭で触れたテストの失敗は、金額カラムをNUMERIC(10, 2)に変更することで解消した。修正自体は数分で終わった。型の選択を間違えなければ、そもそも起きなかった問題だ。この記事で見てきたように、浮動小数点の誤差はコンピュータの本質的な制約であり、避けることはできない。しかし、対処法はシンプルだ。金額にはNUMERIC、センサーデータにはFLOAT、迷ったらNUMERIC。スキーマ設計の段階でこの判断ができれば、テストで奇妙な小数を見ることはなくなる。このブログが良ければ読者になったり、nwiizoのXやGithubをフォローしてくれると嬉しいです。参考資料PostgreSQL Numeric TypesIEEE 754 Floating-Point StandardThe Floating-Point Guiderust_decimal crateapprox crateWhat Every Programmer Should Know About Floating-PointFloating Point Numbers and Decimal in Go

0.1+0.2=0.30000000000000004 をRust/PostgreSQLで考える

論理削除という技術的負債、それでも僕たちは使い続ける

書評や要約は「圧縮」ではなく「変換」であり、「変換」に価値がある。

なぜ「何でも作れる時代」に私は作れないのか

cargo-coupling Web UI - Self-diagnosis viewIntroduction"I really don't want to touch this module..."If you've been developing software long enough, you know this feeling. Every change breaks something else. Tests are painful to write. Understanding what the code even does feels impossible. These symptoms share a common root cause: modules that depend too heavily on each other—the problem of coupling.Coupling problems are insidious. They're hard to notice while you're writing code, only revealing themselves later when you wonder why changes are so difficult. What makes it worse is that even when you know "coupling is too tight," it's hard to see exactly where and how, or where to start fixing it.Looking back, I realize my understanding of coupling was quite shallow. I was making judgments based on vague feelings—"this seems tightly coupled" or "loose coupling is supposedly better"—but when I tried to articulate why, I couldn't explain it clearly.To address this lack of visibility, we need a way to measure coupling. But the traditional single axis of "strong vs. weak" isn't enough. The same "strong coupling" means different things depending on where it occurs and in what context.This brings us to Vlad Khononov's concept of "Balanced Coupling." It's a framework that evaluates coupling across three dimensions: strength, distance, and volatility, then assesses their balance. cargo-coupling is a tool I developed to implement this framework for Rust projects.Even as AI writes more of our code, this coupling metric becomes increasingly important. Regardless of who or what writes the code, humans still need to understand, maintain, and extend it. In fact, precisely because AI generates code, we need objective measures to evaluate its structure.Let's start with an overview of the tool, then explore the underlying concepts, and finally see how to use it in practice.What is cargo-coupling?cargo-coupling is a coupling analysis tool I developed for Rust projects.The inspiration came from Vlad Khononov's book "Balancing Coupling in Software Design." The challenges I had vaguely sensed about coupling design were systematically organized in this book. I was impressed by the framework that captures coupling through three dimensions—strength, distance, and volatility—and wanted to create a tool that makes this practical for Rust projects. I highly recommend picking up the book.The tool is available on GitHub. If you find it useful, I'd appreciate a star!GitHub:github.comcrates.io: https://crates.io/crates/cargo-couplingNow, let's challenge a common assumption."Coupling should be minimized"—isn't that what you believe?This tool doesn't aim to "reduce coupling." It aims to "design coupling appropriately." Why? Because coupling isn't inherently bad. Related functionality working closely together is natural. The problem is "strong coupling in inappropriate places" or "tight coupling between distant modules." This shift in perspective is at the heart of this tool.# Installationcargo install cargo-coupling# Basic usagecargo coupling ./srcAnalyzing Coupling Across Three DimensionsSo what exactly constitutes "appropriate coupling"?Traditional coupling analysis tends to think in terms of a single "strong/weak" axis. But stop and consider: strong coupling with an adjacent module versus strong coupling with a distant external library—shouldn't these mean different things? And coupling with code unchanged for five years versus coupling with code modified weekly—shouldn't these carry different risks?A single axis can't capture these differences. cargo-coupling measures coupling across three independent dimensions.1. Integration StrengthThe first dimension is "coupling strength"—how much modules know about each other's internals.Have you seen code like user.password_hash that directly accesses struct fields? That's the strongest form of coupling. Meanwhile, code that interacts through impl Trait works without knowing the other's internals. This difference gets quantified as a score. Level  Score  Description  Rust Example  Intrusive  1.00  Direct dependency on internal implementation  struct.field direct access  Functional  0.75  Dependency on function signatures  Method calls  Model  0.50  Dependency on data structures  Type definitions, type parameters  Contract  0.25  Interface/trait only  impl Trait 2. DistanceThe second dimension is "distance"—how far apart coupled modules are in the code's scope hierarchy.Functions within the same file working closely together is natural. But what if src/auth/login.rs directly references src/billing/invoice.rs? Or worse, depends on an external crate's internal structure? The farther the distance, the "heavier" that coupling becomes. Level  Score  Description  SameModule  0.25  Within the same file/module  DifferentModule  0.50  Different module in the same crate  DifferentCrate  1.00  External crate dependency 3. VolatilityThe third dimension is "volatility"—how frequently the code changes.Your project surely has stable modules untouched for over a year alongside modules modified weekly. Depending on stable code versus frequently changing code carries different risks. cargo-coupling automatically calculates this volatility from Git history. Level  Score  Changes in 6-month Git history  Low  0.00  0-2 changes  Medium  0.50  3-10 changes  High  1.00  11+ changes Calculating the Balance ScoreWe've covered the three dimensions. But if you're told "strength is 0.75," "distance is 0.50," "volatility is medium"—how do you judge whether this coupling is actually good or bad?cargo-coupling combines these three dimensions into a balance score. By consolidating three numbers into one score, you can intuitively assess whether coupling is appropriate.The concept is simple: multiply "strength-distance balance" by "volatility risk."ALIGNMENT = 1.0 - |STRENGTH - (1.0 - DISTANCE)|VOLATILITY_IMPACT = 1.0 - (VOLATILITY × STRENGTH)BALANCE_SCORE = ALIGNMENT × VOLATILITY_IMPACTThe first formula measures whether strength and distance are proportionate. Close distance can tolerate strong coupling; far distance should mean weak coupling. The second formula measures the combined risk of change frequency and coupling strength. Strong coupling with frequently changing code means higher risk of being affected by every change.The conclusions this formula leads to:Strong coupling + Close distance → Good: High cohesion with related functionality in one moduleWeak coupling + Far distance → Good: Loose coupling architecture with minimal inter-module dependenciesStrong coupling + Far distance → Bad: Global complexity where changes affect wide areasStrong coupling + High volatility → Bad: Change propagation risk where frequent changes cascadePractical UsageNow that we understand the theory, let's see how to use it on real projects. cargo-coupling offers multiple output formats depending on your needs.Summary Displaycargo coupling --summary ./srcExample output:Coupling Analysis Summary:  Health Grade: B (Good)  Files: 14  Modules: 14  Couplings: 389  Balance Score: 0.83  Issues:    Medium: 2  Top Priority:    - [Medium] cargo-coupling::main → 21 dependencies    - [Medium] 21 dependents → cargo-coupling::cargo_coupling  Breakdown:    Internal: 33    External: 356    Balanced: 33    Needs Review: 0    Needs Refactoring: 0  Connascence:    Total: 807 (avg strength: 0.23)    High-strength: Position=2, Algorithm=2  APOSD Metrics:    Pass-Through Methods: 12 (simple delegation)    High Cognitive Load: 2 modules    Avg Module Depth: 7.9Hotspot AnalysisIdentify high-priority modules that need refactoring.cargo coupling --hotspots ./src#1 my-project::main (Score: 55)   🟡 Medium: High Efferent Coupling   💡 What it means:      This module depends on too many other modules   ⚠️  Why it's a problem:      • Changes elsewhere may break this module      • Testing requires many mocks/stubs      • Hard to understand in isolation   🔧 How to fix:      Split into smaller modules with clear responsibilities      e.g., Split main.rs into cli.rs, config.rs, runner.rsImpact AnalysisExamine the impact scope when changing a specific module.cargo coupling --impact metrics ./srcWeb UI VisualizationVisualize coupling relationships with an interactive graph.cargo coupling --web ./srcA browser opens automatically, displaying an interactive graph using Cytoscape.js. Click nodes to see detailed information; problematic modules are color-coded.CI/CD IntegrationBeyond manual analysis, you can continuously monitor quality. Incorporating cargo-coupling as a quality gate enables early detection of coupling design degradation.cargo coupling --check \  --min-grade=B \  --max-circular=0 \  ./srcGitHub Actions example:- name: Check coupling health  run: |    cargo coupling --check \      --min-grade=B \      --max-critical=0 \      ./srcReturns exit code 1 when the grade falls below the threshold, making it easy to integrate into CI pipelines.AI IntegrationWhen using with Claude Code or GitHub Copilot, the --ai option is convenient.cargo coupling --ai ./srcOutput is formatted in an AI-friendly way, so you can paste it directly into AI tools to get refactoring suggestions.Detected Problem PatternsHaving covered usage, you might wonder what specific problems get detected. Here are the representative patterns cargo-coupling warns about.God ModuleA module with too many functions, types, or impls.Functions: 30+Types: 15+Impls: 20+High Efferent CouplingA module with too many dependencies. Default threshold is 20+ dependencies.High Afferent CouplingA module depended on by too many others. Default threshold is 30+ dependents.Cascading Change RiskThe combination of intrusive coupling and high volatility. A dangerous state where changes propagate across wide areas.Interpreting Health GradesDetection results are ultimately consolidated into a single grade representing overall project health. Grade  Description  S  Over-optimized. Might be over-refactored  A  Well-balanced. Ideal state  B  Healthy. Manageable condition  C  Room for improvement  D  Attention needed  F  Immediate action required Interestingly, S grade is considered "overdone." Why?Reducing coupling too much fragments code excessively, making the big picture harder to see. Have you experienced needing to open 10 files to trace a single operation, or getting lost in abstraction layers so deep you wonder "what does this actually do?"Coupling isn't simply "less is better." Balance is key.Library UsageBeyond the CLI tool, you can embed it in your own tools. cargo-coupling is also published as a library, allowing you to call analysis functions directly from code.use cargo_coupling::{    analyze_workspace,    analyze_project_balance_with_thresholds,    IssueThresholds,    VolatilityAnalyzer,};fn main() -> Result<(), Box<dyn std::error::Error>> {    // AST analysis    let mut metrics = analyze_workspace(Path::new("./src"))?;    // Git volatility analysis    let mut volatility = VolatilityAnalyzer::new(6);    volatility.analyze(Path::new("./src"))?;    metrics.file_changes = volatility.file_changes;    metrics.update_volatility_from_git();    // Balance analysis    let report = analyze_project_balance_with_thresholds(        &metrics,        &IssueThresholds::default()    );    println!("Grade: {}", report.health_grade);    Ok(())}Performancecargo-coupling is designed to run fast even on large projects.Parallel AST analysis with RayonStream processing of Git historyBenchmarks: 655ms on tokio (488 files)Use the --no-git option to skip Git analysis for even faster operation.LimitationsWhile useful, this tool isn't omnipotent. Know these limitations before using it.External crate dependencies aren't analyzed: Dependencies on serde, tokio, etc. aren't analyzed since developers can't control themStatic analysis only: Runtime behavior and macro expansion aren't fully capturedGit history required: Volatility analysis needs Git history. Short history reduces accuracyConclusioncargo-coupling provides a practical approach of "choosing appropriate coupling" rather than the simplistic view that "coupling is bad."3-dimensional analysis: Considers strength, distance, and volatility simultaneouslyGit integration: Reflects actual change frequency as dataActionable suggestions: Presents concrete refactoring actionsMultiple output formats: Text/JSON/Web UI/AI-friendlyCI/CD integration: Automated checks as quality gatesYou don't need perfect design. With a pragmatic attitude that "80% improvement is enough," gradually improve your project's health.# Try it outcargo install cargo-couplingcargo coupling --summary ./srcJust visualizing coupling problems is the first step toward better design.The next time you feel "I really don't want to touch this module..."—that's no longer a vague anxiety. It's a tractable challenge you can analyze across three dimensions of strength, distance, and volatility, and translate into concrete improvement actions. That feeling isn't something to fear; it's the entry point to improvement.A related concept is "Complexity" from John Ousterhout's "A Philosophy of Software Design." It offers another valuable perspective and is well worth reading.

cargo-coupling: Visualizing Coupling in Rust Projects

 おい、休め

cargo-coupling を自己診断した時のweb ui です。はじめに「このモジュール、なんか触りたくないな...」ソフトウェア開発をしていると、こんな感覚を覚えることがあります。変更するたびに他の箇所が壊れる、テストが書きにくい、そもそも何をしているのか把握しづらい。これらの症状には共通点があります。モジュール同士が過剰に依存し合っている、つまり結合（カップリング）の問題です。結合の問題は厄介です。コードを書いているときには気づきにくく、後から「なぜこんなに変更が大変なのか」と悩むことになります。さらに困るのは、「結合が強すぎる」と分かっても、具体的にどこがどう強いのか、どこから手をつければいいのかが見えにくいことです。振り返ってみると、私は結合に対する解像度がかなり低かったのではないでしょうか。「なんとなく密結合っぽい」「疎結合の方がいいらしい」という感覚で良し悪しを判断していた。でも、その感覚を言葉にしようとすると、うまく説明できない。この「見えにくさ」を解消するには、結合を測る物差しが必要です。しかし、従来の「強い/弱い」という1軸だけでは不十分でした。なぜなら、同じ「強い結合」でも、場所や状況によって意味が変わるからです。そこで注目したいのが、Vlad Khononovの「Balanced Coupling」という考え方です。結合を「強度」「距離」「変動性」の3つの軸で捉え、それらのバランスを評価するフレームワークです。今回紹介するcargo-couplingは、このフレームワークをRustプロジェクト向けに実装したツールです。AIがコードを書く時代になっても、この結合度という指標は重要性を増すはずです。なぜなら、コードを書く主体が誰であれ、そのコードを理解し、保守し、拡張するのは人間だからです。むしろAIが生成したコードだからこそ、その構造を客観的に評価できる物差しが必要になります。まずはツールの概要を見てから、その背景にある考え方、そして実際の使い方へと進んでいきましょう。cargo-couplingとはcargo-couplingは、私がRustプロジェクト向けに開発した結合度分析ツールです。このツールを作るきっかけになったのは、Vlad Khononovの著作「Balancing Coupling in Software Design」との出会いでした。結合設計について漠然と感じていた課題が、この本で体系的に整理されていたのです。「強度」「距離」「変動性」という3つの軸で結合を捉えるフレームワークに感銘を受け、これをRustプロジェクトで実際に使えるツールにしたいと考えました。書籍は翻訳も含めて読みやすいので、ぜひ手に取ってみてください。ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則 (impress top gearシリーズ)作者:Vlad KhononovインプレスAmazonツールはGitHubで公開しています。気に入ったらStarしていただけると励みになります。github.comcrates.ioからインストールできます。https://crates.io/crates/cargo-couplingcrates.ioここで、多くの人が持っている常識を一度疑ってみましょう。「結合は減らすべきだ」——そう思っていませんか？このツールは「結合を減らす」ことを目標にしていません。「結合を適切に設計する」ことを目標にしています。なぜなら、結合は本質的に悪ではないからです。関連する機能が密に連携するのは自然なことで、問題になるのは「不適切な場所での強い結合」や「遠く離れたモジュール間の密結合」です。この視点の転換が、このツールの核心です。# インストールcargo install cargo-coupling# 基本的な使い方cargo coupling ./src3つの次元で結合を分析では、「適切な結合」とは具体的に何を指すのでしょうか。従来の結合分析は「強い/弱い」の1軸で考えがちでした。しかし、ここで立ち止まって考えてみてください。同じ「強い結合」でも、すぐ隣のモジュールとの結合と、遠く離れた外部ライブラリとの結合では、意味が違うはずです。また、5年間ほとんど変更されていないコードとの結合と、毎週のように変更されるコードとの結合では、リスクが違うはずです。この違いを捉えるには、1軸では足りません。cargo-couplingは結合を3つの独立した次元で測定します。1. Integration Strength（結合強度）最初の軸は「結合強度」です。モジュール同士が「どれだけ互いの内部を知っているか」を表します。user.password_hashのように構造体のフィールドを直接触っているコード、見覚えがありませんか？これは最も強い結合です。一方、impl Traitを介してやり取りするコードは、相手の内部を知らなくても動作します。この違いをスコア化します。 レベル  スコア  説明  Rust例  Intrusive  1.00  内部実装に直接依存  struct.field 直接アクセス  Functional  0.75  関数シグネチャに依存  メソッド呼び出し  Model  0.50  データ構造に依存  型定義、型パラメータ  Contract  0.25  trait/インターフェースのみ  impl Trait 2. Distance（距離）2つ目の軸は「距離」です。結合されたモジュール同士が、コードのスコープ階層でどれだけ離れているかを表します。同じファイル内の関数同士が密に連携しているのは自然なことです。しかし、src/auth/login.rsがsrc/billing/invoice.rsを直接参照していたらどうでしょう？さらに、外部クレートの内部構造に依存していたら？距離が遠いほど、その結合の「重さ」は増します。 レベル  スコア  説明  SameModule  0.25  同一ファイル/モジュール内  DifferentModule  0.50  同一クレート内の別モジュール  DifferentCrate  1.00  外部クレートへの依存 3. Volatility（変動性）3つ目の軸は「変動性」です。「どれくらい頻繁に変更されるか」を表します。あなたのプロジェクトにも、1年以上触られていない安定したモジュールと、毎週のように修正が入るモジュールがあるはずです。安定したコードに依存するのと、頻繁に変わるコードに依存するのでは、リスクが違います。cargo-couplingはGit履歴からこの変動性を自動で計算します。 レベル  スコア  Git 6ヶ月での変更回数  Low  0.00  0-2回  Medium  0.50  3-10回  High  1.00  11回以上 バランススコアの計算ここまで3つの次元を見てきました。しかし、「強度が0.75」「距離が0.50」「変動性が中程度」とバラバラに言われても、結局この結合は良いのか悪いのか、判断しづらいですよね。そこでcargo-couplingは、これら3つの次元を組み合わせてバランススコアを計算します。3つの数値を1つのスコアにまとめることで、「この結合は適切か」を直感的に判断できるようになります。考え方はシンプルです。「強度と距離のバランス」と「変動性によるリスク」の2つを掛け合わせます。ALIGNMENT = 1.0 - |STRENGTH - (1.0 - DISTANCE)|VOLATILITY_IMPACT = 1.0 - (VOLATILITY × STRENGTH)BALANCE_SCORE = ALIGNMENT × VOLATILITY_IMPACT最初の式は「強度と距離が釣り合っているか」を測ります。距離が近ければ強結合でも問題なく、距離が遠ければ弱結合であるべきです。2番目の式は「変更頻度と結合強度の組み合わせリスク」を測ります。頻繁に変更されるコードと強く結合していると、変更のたびに影響を受けるリスクが高まります。この計算式が導く結論を整理すると、以下のようになります。強結合 + 近距離 → Good：関連機能が1つのモジュールにまとまった高凝集な状態弱結合 + 遠距離 → Good：モジュール間の依存が最小限な疎結合アーキテクチャ強結合 + 遠距離 → Bad：変更影響が広範囲に及ぶグローバル複雑性の状態強結合 + 高変動性 → Bad：頻繁な変更が連鎖的影響を生む変更波及リスク実際に使ってみる理論を理解したところで、実際のプロジェクトでどう使うかを見ていきましょう。cargo-couplingは目的に応じて複数の出力形式を用意しています。サマリー表示cargo coupling --summary ./src出力例は以下のとおりです。Coupling Analysis Summary:  Health Grade: B (Good)  Files: 14  Modules: 14  Couplings: 389  Balance Score: 0.83  Issues:    Medium: 2  Top Priority:    - [Medium] cargo-coupling::main → 21 dependencies    - [Medium] 21 dependents → cargo-coupling::cargo_coupling  Breakdown:    Internal: 33    External: 356    Balanced: 33    Needs Review: 0    Needs Refactoring: 0  Connascence:    Total: 807 (avg strength: 0.23)    High-strength: Position=2, Algorithm=2  APOSD Metrics:    Pass-Through Methods: 12 (simple delegation)    High Cognitive Load: 2 modules    Avg Module Depth: 7.9日本語出力日本語での出力も対応しています。cargo coupling --japanese ./srcカップリング分析: my-project━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━評価: B (Good) | スコア: 0.67/1.00 | モジュール数: 143次元分析:  結合強度: Contract 1% / Model 24% / Functional 66% / Intrusive 8%           (トレイト)   (型)      (関数)        (内部アクセス)  距離:     同一モジュール 6% / 別モジュール 2% / 外部 91%  変更頻度: 低 2% / 中 98% / 高 0%ホットスポット分析リファクタリングすべき優先度の高いモジュールを特定します。cargo coupling --hotspots ./src#1 my-project::main (Score: 55)   🟡 Medium: High Efferent Coupling   💡 What it means:      This module depends on too many other modules   ⚠️  Why it's a problem:      • Changes elsewhere may break this module      • Testing requires many mocks/stubs      • Hard to understand in isolation   🔧 How to fix:      Split into smaller modules with clear responsibilities      e.g., Split main.rs into cli.rs, config.rs, runner.rs影響分析特定のモジュールを変更したときの影響範囲を調べられます。cargo coupling --impact metrics ./srcWeb UIでの可視化インタラクティブなグラフで結合関係を可視化できます。cargo coupling --web ./srcブラウザが自動で開き、Cytoscape.jsを使った対話的なグラフが表示されます。ノードをクリックすると詳細情報が見られ、問題のあるモジュールは色分けされます。CI/CDでの活用手動で分析するだけでなく、継続的に品質を監視することもできます。cargo-couplingを品質ゲートとして組み込むと、結合設計の劣化を早期に検出できます。cargo coupling --check \  --min-grade=B \  --max-circular=0 \  ./srcGitHub Actionsの例は以下のとおりです。- name: Check coupling health  run: |    cargo coupling --check \      --min-grade=B \      --max-critical=0 \      ./srcグレードが基準を下回るとexit code 1を返すため、CIパイプラインに組み込めます。AI連携Claude CodeやGitHub Copilotと組み合わせて使う場合、--aiオプションが便利です。cargo coupling --ai ./srcAIフレンドリーな形式で出力されるので、そのままAIに貼り付けてリファクタリング提案を得られます。検出される問題パターンここまで使い方を見てきましたが、具体的にどんな問題が検出されるのか気になるところでしょう。cargo-couplingが警告する代表的なパターンを紹介します。God Module（神モジュール）関数、型、implが多すぎるモジュールです。関数: 30個以上型: 15個以上impl: 20個以上High Efferent Coupling（外向き結合過多）依存先が多すぎるモジュール。デフォルトでは20以上の依存で警告されます。High Afferent Coupling（内向き結合過多）依存されすぎているモジュール。デフォルトでは30以上の依存元で警告されます。Cascading Change Risk（変更波及リスク）侵入的結合（Intrusive）と高変動性（High Volatility）の組み合わせ。変更のたびに広範囲に影響が及ぶ危険な状態です。ヘルスグレードの解釈問題パターンの検出結果は、最終的に1つのグレードに集約されます。このグレードがプロジェクト全体の健全性を示します。 Grade  説明  S  Over-optimized。リファクタリングしすぎかも  A  Well-balanced。理想的な状態  B  Healthy。管理可能な状態  C  改善の余地あり  D  注意が必要  F  即刻対応が必要 興味深いのは、Sグレードが「やりすぎ」とされている点です。なぜでしょうか？結合を減らしすぎると、コードが細切れになりすぎて、かえって全体像が見えなくなります。1つの処理を追うために10個のファイルを開く必要があったり、抽象化のレイヤーが深すぎて「結局何をしているの？」と迷子になったり。そういう経験はありませんか？結合は「減らせばいい」という単純な話ではありません。バランスが大切なのです。ライブラリとしての利用CLIツールとして使うだけでなく、独自のツールに組み込むこともできます。cargo-couplingはライブラリとしても公開しているので、プログラムから直接分析機能を呼び出せます。use cargo_coupling::{    analyze_workspace,    analyze_project_balance_with_thresholds,    IssueThresholds,    VolatilityAnalyzer,};fn main() -> Result<(), Box<dyn std::error::Error>> {    // AST解析    let mut metrics = analyze_workspace(Path::new("./src"))?;    // Git変動性分析    let mut volatility = VolatilityAnalyzer::new(6);    volatility.analyze(Path::new("./src"))?;    metrics.file_changes = volatility.file_changes;    metrics.update_volatility_from_git();    // バランス分析    let report = analyze_project_balance_with_thresholds(        &metrics,        &IssueThresholds::default()    );    println!("Grade: {}", report.health_grade);    Ok(())}パフォーマンスcargo-couplingは、大規模プロジェクトでも高速に動作するよう設計されています。Rayonによる並列AST解析Git履歴のストリーム処理実績: tokio（488ファイル）で655ms--no-gitオプションを使えば、Git分析をスキップしてより高速に動作します。制限事項便利なツールですが、万能ではありません。使う前に知っておくべき制限があります。外部クレート依存は分析対象外: serde、tokioなどへの依存は分析されない。開発者がコントロールできない部分のため静的解析のみ: ランタイムの動作やマクロ展開は完全には捉えられないGit履歴が必要: Volatility分析にはGit履歴が必要。履歴が短いと精度が下がるまとめcargo-couplingは、「結合は悪」という単純な考え方ではなく、「適切な結合を選ぶ」という実用的なアプローチを提供します。3次元分析: 強度・距離・変動性を同時に考慮Git連携: 実際の変更頻度をデータとして反映実行可能な提案: 具体的なリファクタリングアクションを提示複数の出力形式: テキスト/JSON/Web UI/AIフレンドリーCI/CD統合: 品質ゲートとして自動チェック完璧な設計を目指す必要はありません。「80%の改善で十分」というプラグマティックな姿勢で、少しずつプロジェクトの健全性を高めていきましょう。# まずは試してみてくださいcargo install cargo-couplingcargo coupling --summary ./src結合の問題が可視化されるだけでも、設計改善の第一歩になります。次にあなたが「このモジュール、なんか触りたくないな...」と感じたとき、それはもう漠然とした不安ではありません。強度・距離・変動性という3つの軸で分析でき、具体的な改善アクションに落とし込める、対処可能な課題です。その感覚は、恐れではなく、改善の入り口なのです。似た概念にA Philosophy of Software DesignのComplexity がある。これも良い考え方なので一読をおすすめします。 speakerdeck.comA Philosophy of Software Design, 2nd Edition (English Edition)作者:Ousterhout, John K. ISSVWOAmazon

cargo-coupling: Rustプロジェクトの結合度を可視化する

この記事は、3-shake Advent Calendar 2025 19日目のエントリ記事です。はじめにエンジニアがプレゼン資料を作るとき、PowerPointやKeynoteにもどかしさを感じることがあります。コードを書くようにスライドを作りたい。Gitでバージョン管理したい。テーマを一括で変更したい。Marpはこれらの願望を叶えるマークダウンベースのスライド生成ツールです。marp.appしかし生成AI時代の今、新しい課題が生まれています。AIにスライドの下書きを依頼できるようになった反面、「AIっぽいプレゼン」が量産されるようになりました。整然としすぎて、話者の思考が見えない資料です。この記事では、AIの力を借りつつ「自分のプレゼン」を取り戻す仕組みを紹介します。AIっぽいプレゼンの正体生成AIにプレゼン資料を依頼すると、だいたい同じ構成になります。「まず、次に、最後に」という接続詞。きれいに3項目並んだ箇条書き。当たり障りのない結論。これは決して間違っていません。しかし聴衆の記憶には残りません。なぜでしょうか。聴衆の脳は「予測を裏切られた瞬間」に活性化します。「まず、次に、最後に」という予定調和な構成では、脳は省エネモードで聞き流します。3項目の箇条書きを見た瞬間、聴衆は「ああ、3つあるのね」と思考を止めます。AIが生成するプレゼンは、統計的に最も頻出するパターンの再現です。だから誰が作っても似たような資料になります。Marpを選んだ理由はシンプルです。マークダウンはプレーンテキストなので、AIが直接編集でき、人間がTextlintやカスタムルールで機械的にチェックできます。PowerPointのようなバイナリ形式では「AI生成→ルール検証」の流れが困難です。Gitで差分管理でき、CSSでデザインを一括制御できる点も大きいです。プロジェクト構造実際に運用しているMarpプロジェクトの構造を紹介します。github.com3shake-marp-templates/├── templates/              # 再利用可能なテンプレート├── themes/                 # CSSテーマ├── slides/2025/           # 実際のプレゼンテーション├── assets/images/         # 画像資産└── .claude/               # Claude Code統合    ├── commands/          # スラッシュコマンド    ├── agents/            # 専門家エージェント    └── rules/             # 執筆ルールポイントは.claude/ディレクトリです。Claude Codeと統合することで、スライドのレビューを自動化しています。CommandsやSub-agentsの詳細については、以前の記事で解説しています。syu-m-5151.hatenablog.comMarpの基本設定.marprc.ymlでMarpを設定します。allowLocalFiles: truehtml: truemermaid: truebespoke:  progress: trueoptions:  engine: '@marp-team/marp-core'mermaid: trueでMermaid記法の図表が使えます。しかし正直なところ、PDFエクスポート時に崩れることがあります。重要な図は画像として用意するほうが安全です。package.jsonのスクリプトは以下の通りです。{  "scripts": {    "start": "marp -s . --html --allow-local-files",    "build": "marp --html --allow-local-files"  }}npm startでローカルサーバーが起動し、ファイル保存のたびに自動リロードされます。テーマによるブランディングCSSテーマで全スライドに統一感を持たせます。/* 3shake-theme.css */:root {  --3shake-blue: #4AADDD;  --3shake-blue-dark: #0a1929;  --3shake-yellow: #ECBE30;}section {  background: white;  font-family: 'Noto Sans JP', sans-serif;}/* 全スライドにロゴを自動配置 */section::after {  content: '';  background-image: url('../assets/images/logo.png');  position: absolute;  left: 30px;  bottom: 20px;}ロゴとページ番号が自動配置されます。プレゼン作成者はブランディングを意識する必要がなくなります。AIっぽさを排除するルールここからが本題かもです。.claude/rules/slide-writing.mdに以下の禁止事項を定義しています。箇条書きを3項目で揃えない（2つか4つにする）「まず、次に、最後に」という機械的な接続詞を使わない完全に等分な説明をしない（メリハリをつける）抽象的で当たり障りのない表現を避けるなぜ2つか4つなのか。 聴衆の「3つだろう」という予測を外すためです。2つなら対比が明確になり、4つなら網羅感が出ます。3つは「ちょうどいい」ゆえに印象へ残りません。意図的にパターンを崩すことで、聴衆の能動的な思考を促します。「PowerPointでも同じルールを適用できる」という反論があるでしょう。確かにその通りです。しかしPowerPointでは、このルールを機械的にチェックする手段がありません。Marpならテキストベースなので、「3項目の箇条書きを検出したら警告」というルールを自動実行できます。人間の意志力に頼らず、仕組みで品質を担保します。身体性の供給以前の記事で「AIに記事を書かせるとは何か」について書きました。プレゼンにも同じことが言えます。AIは構造化が得意です。しかし「身体性」は供給できません。ここで言う身体性とは、知識が「情報」から「経験」へと変容する過程で生じる一人称的な認知の軌跡です。たとえば「このツールを導入したら開発効率が上がった」という情報と、「導入時に設定で3時間ハマってドキュメントの不備に気づきPRを送った」という経験は別物です。プレゼンにおける身体性とは、「なぜこのトピックを選んだのか」「どこで躓いたのか」「何に感動したのか」という、話者固有の軌跡です。これはAIには生成できません。私の作業フローはこうです。伝えたいメッセージを箇条書きで書き出す（5-7個）各メッセージに「自分だけが語れる具体例」を追加AIにレビューを依頼し、構成を整える/review-slideで「3項目の箇条書き」「まず・次に」の指摘を確認指摘箇所を修正AIは足す。人間は削る。 AIは情報の網羅性を最適化しますが、プレゼンの核心は何を省くかにあります。「このトピックは聴衆の関心外」と判断するには、聴衆の反応を想像する力が必要です。この能力は現在のLLMには実装されていません。だからアウトラインは自分で考え、AIにはレビューを任せます。おわりにMarpとルールベースのチェック、そしてClaude Codeのエージェント。この組み合わせで実現したのは、「AIの力を借りながら、自分の思考を残す」環境です。完璧に整った資料より、少し不格好でも話者の考えが透けて見える資料のほうが、聴衆の記憶に残ります。AIが生成した「もっともらしい」スライドではなく、自分の経験に根ざした「本物の」スライドを作る。そのための環境がMarp×Claude Codeです。まずは既存のスライドを1枚だけMarkdown化してみてください。それがMarp×AI環境構築の第一歩です。

生成AI時代のMarp によるスライド環境の構築

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

「自分の環境では動く」から解放される Nix Flake 

2025年版 私がAIエージェントと協働しながら学習する方法

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

2024年16:20-17:00（Track A）にて「メインテーマはKubernetes」というタイトルで登壇します。イベント名: Cloud Native Days Winter 2024公式URL:https://event.cloudnativedays.jp/cndw2024/セッションURL:https://event.cloudnativedays.jp/cndw2024/talks/2373

メインテーマはKubernetes

2024年11月06日(水) 18:00～19:00の予定に遅刻してしまい、大変申し訳ございませんでした。お詫びとして、当初非公開予定であった資料を公開させていただきます。元々、公開する予定ではなかったので補足が足りない部分などあると思いますのでご容赦下さい。ブログなどで補足情報出すかもなので気になればフォローしてください- https://syu-m-5151.hatenablog.com/- https://x.com/nwiizoSREの前に - 運用の原理と方法論公式URL: https://talent.supporterz.jp/events/2ed2656a-13ab-409c-a1d9-df8383be25fd/

SREの前に

Cloud Operator Days 2024 クロージングイベントhttps://cloudopsdays.com/closing/とても、端的に言うと「プロンプトエンジニアリングをしよう」って話。この発表資料は、LLM（大規模言語モデル）によるIT運用の可能性と課題を探っています。AIOpsの概念を基に、LLMがインシデント対応、ドキュメンテーション、コード分析などの運用タスクをどのように改善できるかを説明しています。同時に、LLMの「幻覚」や不完全性といった課題も指摘し、適切な利用方法やプロンプトエンジニアリングの重要性を強調しています。登壇時ブログhttps://syu-m-5151.hatenablog.com/entry/2024/09/06/154607

2024年版 運用者たちのLLM

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

nwiizo

Ory Kratosで認証を委譲する

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

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

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

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

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

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

おい、辞めるな

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

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

私の為のNvChadのキーマッピングガイド 2026年版

テスト,検証してますか: cargo-mutantsによるミューテーションテスト入門

2025年個人的に心に残ったグラビアアイドル10選

2025年、nwiizoが作ったソフトウェア

おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、

おい、論理で人が動くと思ってるのか

2025年俺が愛した本たち非技術書編

2025年、AI時代の要件定義について考える

Rustにしたのに遅い？─ N+1クエリ問題の発見と解決

0.1+0.2=0.30000000000000004 をRust/PostgreSQLで考える

論理削除という技術的負債、それでも僕たちは使い続ける

書評や要約は「圧縮」ではなく「変換」であり、「変換」に価値がある。

なぜ「何でも作れる時代」に私は作れないのか

cargo-coupling: Visualizing Coupling in Rust Projects

おい、休め

cargo-coupling: Rustプロジェクトの結合度を可視化する

生成AI時代のMarp によるスライド環境の構築

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

「自分の環境では動く」から解放される Nix Flake

2025年版私がAIエージェントと協働しながら学習する方法

おい、テックブログを書け

バイブコーディングと継続的デプロイメント

Ory Kratosで認証を委譲する

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

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

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

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

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

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

おい、辞めるな

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

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

私の為のNvChadのキーマッピングガイド 2026年版

テスト,検証してますか: cargo-mutantsによるミューテーションテスト入門

2025年 個人的に心に残ったグラビアアイドル10選

2025年、nwiizoが作ったソフトウェア

おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、おい、

おい、論理で人が動くと思ってるのか

2025年 俺が愛した本たち 非技術書編

2025年、AI時代の要件定義について考える

Rustにしたのに遅い？─ N+1クエリ問題の発見と解決

0.1+0.2=0.30000000000000004 をRust/PostgreSQLで考える

論理削除という技術的負債、それでも僕たちは使い続ける

書評や要約は「圧縮」ではなく「変換」であり、「変換」に価値がある。

なぜ「何でも作れる時代」に私は作れないのか

cargo-coupling: Visualizing Coupling in Rust Projects

おい、休め

cargo-coupling: Rustプロジェクトの結合度を可視化する

生成AI時代のMarp によるスライド環境の構築

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

「自分の環境では動く」から解放される Nix Flake

2025年版 私がAIエージェントと協働しながら学習する方法

おい、テックブログを書け

バイブコーディングと継続的デプロイメント

2025年個人的に心に残ったグラビアアイドル10選

2025年俺が愛した本たち非技術書編

2025年版私がAIエージェントと協働しながら学習する方法