用語の標準表 — 原語・定訳・使わない言い換え
技術文書で使う用語の標準表。デリバリー・DB マイグレーション・進化的アーキテクチャ・可観測性・認証認可・データ連携、基礎理論(情報理論・データベース理論・グラフ理論と統計・ネットワーク・OS)と、古典の書籍(1960〜90 年代の論文と本、SOLID とその周辺の設計原則、リファクタリング、PoEAA・DDD・EIP・Release It!・継続的デリバリー・ヘキサゴナル・XP/TDD・Google のソフトウェアエンジニアリング・マイクロサービス・ソフトウェアアーキテクチャの基礎とハードパーツ・Accelerate・チームトポロジー)の語について、標準の語・原語・近い語との使い分け・使わない言い換え・出典をまとめる。原語が英語なら英語のまま、定訳があればそれ、列挙では英語に統一し、比喩は作らない。
アーキテクチャのドリフトを防ぐ仕組み、適応度関数とその具体例
設計の意図は文書に書いても人数と時間で薄まる。守りたい性質を機械で測り、外れたら止める仕組みが適応度関数で、進化的アーキテクチャが「変化を止めずに形を保つ」ために置く唯一の手段がこれになる。検証リポジトリ greenfield で動いている検査を例に、境界・契約・守りの既定値・依存の4領域で何を測り、fail closed と「検査の検査」をどう組み、何を警告に留めるかをまとめる。
グレースフルシャットダウンとデッドライン伝播を実測した
Goのサービスで、止まるときに処理中の仕事を終わらせるグレースフルシャットダウンと、待つ時間を層ごとに決めるタイムアウトヒエラルキー、呼び出し元の残り時間を下流へ渡すデッドライン伝播を入れて実測した。outboxがあれば壊れはしないが、止めるたびに再配信を自分で作っていた話から。
OTelを入れてみた。ログのtrace_idでトレースを引く
既にtrace_id付きの構造化ログがあるGoのサービス群に、OpenTelemetryの分散トレーシングを後から入れた。方針はログとトレースのIDを完全に同じにすること。伝播ではなくIDの採番元を揃えた実装と、トレースが静かに消える罠4つを書く。
セキュリティの既定値をCIで固定し、検査も検査する
秘密情報の平文、HTTPのまま、暗号化なし、rootで動くコンテナ。直すだけでは次の変更で元に戻るので、戻れないようにCIの検査を対で入れた。イメージ署名とSBOMの付与、アラートのルールそのもののテストまで、検査が壊れていないかを確かめる仕組みも含めて書く。
ステップアップ認証を実装してみた。エージェントは自力で昇格できない
RFC 9470 のステップアップ認証を Keycloak で動かし、AI エージェント(MCP)からの危険操作が人間の再認証なしには通らないことを実測した。human-in-the-loop はアプリの機能として作るものではなく、認証サーバの設定から出てくる性質だった。監査にはclient_idでなくazpを使う話も。
フェイルオーバーは切断ではなく凍結 — RDS 復旧系の実測
RDS Multi-AZ のフェイルオーバー中、アプリから見て何が起きるかを 250ms 間隔のプローブで実測した。最大の発見は、確立済みコネクションが「切断エラー」ではなく無言で凍結すること。エラー窓11.2秒の内訳、DDL実行中に落とした場合の挙動、スナップショット復元とPITRのRPO/RTO実測まで、使い捨てスタック$2未満で測れる手順つき。
リレーション境界分析ツールhabakiriを作ってみた
FKグラフから切断点を出すCLI(habakiri)を作り、Magento 2で実際に橋を切ってHTTP分離まで実験。その後、Rails静的解析でMastodonをDB接続ゼロで解析し、E-R図の機械生成、切断レベル、hub契約、Girvan–Newmanによる「大物数個への分割案」まで積んだ開発記録。
進化的アーキテクチャ入門 — 変えられる状態を設計する
モノリスからの分離で使う個々のアーキテクチャ(モジュール境界・CI分離・expand/contract・段階的な切り出し)の裏側には共通の概念がある。『進化的アーキテクチャ』の3要素——適応度関数・漸進的変更・アーキテクチャ量子——を、検証リポジトリの実物と実測値に対応づけて解説する入口記事。
greenfieldの全体像 — 進化的アーキテクチャの設計と実装例
マルチドメインAPIモノレポの設計主張を、動くコードと実測で検証したリポジトリgreenfield。5日間・チェックリスト29項目・AWS費用$2.5未満から生まれた約20本の記事を、思想→設計→開発体験→デリバリー→イベント→移行→セキュリティの地図に並べる総覧。
境界の引き直しは楽にできるのか — 除却と切り出しの実測
進化的アーキテクチャの本丸は境界を引き直す瞬間なのに、検証されるのはいつも「追加」だけ。9モジュールのGoモノレポからサービスを1つ除却・切り出しするドリルを実施し、「モジュール再編は1PRで済み、安い」という主張を実測に置き換えた。除却は65ファイルで検出が3層に分かれ、切り出しはgo.mod 4行とコマンド2つ・コード変更ゼロだった。
デプロイ分離はなぜ開発生産性を上げるのか
モノリス脱却の動機は「スケール」より先に生産性にある。リリーストレインの解体・巻き込まれロールバックの消滅・CIが変更範囲に比例する、の3つのメカニズムを、検証環境の実測(affected CIで9モジュール中2個だけ動く、docs変更は20秒、独立ロールバック32秒)で確かめる。前提を張らずにデプロイだけ分けると分散モノリスになる話まで。
モノリスのデータ切り出しは3段階で考える
サービス切り出しの難所はコードでなくデータ。境目は「1つのトランザクションが新旧両方に届くか」で、同一DB同一スキーマ→同一インスタンス別database→別インスタンスの3段階に分けると、各段階で必要な機構(FK棚卸し・expand/contract・outbox)と、段階2で止まる合理性がはっきりする。ER図とインフラ図で各段階の変化を追う。
バックスラッシュ1本でログイン後の戻り先が奪われる
ログイン後の戻り先を検証する関数が /\evil.com で抜けた。WHATWG URL がバックスラッシュをパス区切りとして扱うため、前方一致の判定では追いつかない。素直な直し方に残っていたもう1つの穴と、なぜ既製の脆弱性検査からは出てこないのかを実測つきでまとめた。
継続的脆弱性検査は層で回す。govulncheckから始めてZAPは最後
OWASP ZAPから始めると続かない。依存・更新・イメージ・静的解析・DASTの5層を頻度を変えて回す設計と、各層の落とし穴。govulncheckの到達性解析がなぜ別格なのか、Dependabotが検知器ではなく更新装置である理由、そしてどの層でも見つからない認可の穴について。
アプリとDBでプログレッシブは別物 — 各層の実測
トラフィックは割合で割れるがスキーマは1つしかない。アプリ層(ECS ネイティブ B/G・promotion gate・canary: 失敗 0/1679 vs 69/2880)とDB層(expand/contract・INSTANT DDL判定・COPY 2M行56秒・fast clone)それぞれの仕組みと実測、そして両層の噛み合わせ(旧バイナリ×新スキーマ)を1本で。
プログレッシブデリバリー入門 — デプロイ・トラフィック切替・リリース
プログレッシブデリバリーを「デプロイ・トラフィック切替・リリース」の3つの営みに分解して整理する入門。B/G・canary・promotion gate・bake・feature flag の語彙と、それぞれが何を守るのか。実測値(失敗 0/1679 vs 69/2880、巻き戻し32秒と14秒)を証拠に、よくある誤解も正す。
AppConfig用のOpenFeatureプロバイダを自作した
OpenFeatureのエコシステムにAWS AppConfigのプロバイダが無かったので自作した。ポーリング+プロセス内評価、取得失敗時は前回定義で継続。切替はデプロイなし14秒、段階配信中の評価は行き来なしを実測。フラグキーに"."が使えない制約で命名規約を変えた話も。
B/Gとカナリアの選び方、そして選ばせない運用
デプロイ戦略×DBマイグレーションの組み合わせを、実測値(失敗 0/1679、69/2880、COPY 2M行56秒)から逆算して整理する。結論は「変更の種類で選ぶ」と「ただし開発者には選ばせない」。既定1本・カナリアはサービス属性・判断は機械とレビューへ、という運用の形まで。
キューポリシーのないSNSとSQSの末路
SNSトピックにSQSキューを購読させただけでは配送されない。Publishは成功し、エラーはどこにも出ず、キューに届かないだけ。必要なのはキューポリシーで、LocalStackはこれを強制しないためローカルのテストは全部通る。デデュープ窓と順序保証の実測も。
EventBridge の新カスタムバスは SNS/SQS FIFO を置き換えられるか
2026-09-24 に GA した EventBridge の enhanced custom event bus(eventsv2)を、outbox + SNS/SQS FIFO で組んだイベント基盤の実測要件と突き合わせて比較する。順序・重複排除の意味論は同型だった。それでも今は乗り換えない、という結論とその理由。
マイクロサービスとしても動くGoモノレポをシングルプロセスで動かす
モノレポの進化的アーキテクチャでは、デプロイ粒度とコロケーション——サービスをどこまで同居させて動かすか(1プロセス〜マルチホスト)——を後から変えられることが中心の性質になる。ローカル開発の束ね方はその同じ軸の一点で、全サービス1プロセスのランチャー、ホスト名が正しさに関わる4場面、環境の三段構え、*.localhostの解決の罠まで実測ベースで整理する。
OpenFGAで認可を実装してみた。ScopeとRelationによる権限制御
OpenFGA + 自作認可サービスの実装を、公開している検証リポジトリの実物で追う。ネットワーク構成、JWT検証のコード、関係タプルのDDLとFGAモデル、Can/ListAccessibleの実装2種、401/403の実測、M2Mのトークン付与とトレース伝播を束ねたRoundTripperまで。
fail openを意識する。テストの成功は問題ないことを意味しない
テスト・検査・readinessは、それ自体が壊れると失敗ではなく成功として出てくる(fail open)。成功が信用できなくなる壊れ方を分類し、実測した5つの事例と、fail closedに書き直すための3つの技法をテストコード付きでまとめた。
ドメインモデルは書き込みの道にだけ置く
handler・usecase・domain・repository・readmodel の5層を図で示す。要点は、リクエストの道が書きと読みで分かれていて、ドメインモデル(不変条件と状態遷移)が居るのは書き込みの道だけということ。読みは Entity を経由せず SQL が直接応答の形を作る。
CQSが効くのはスキーマを動かすとき
読み書き分離の利点として語られる「viewの変更に引きずられない」は本命ではない。列を落とす変更がコンパイルで守られる、マイグレーションの前提をgrepで確認できる、読みがロック待ち行列に並ばない——CQSはオンラインマイグレーションと相性が良く、組み合わせるとスキーマ変更を安全かつ高速に出せるようになる、という話。
Architecture as Code という捉え方
アーキテクチャは図ではなく「変更に晒されても保たれる制約の集合」で、文書にしか無い制約は保たれない。判断(ADR)・強制(検査)・証拠(実測)の3点セットをコードとして持つ、という整理のメモ。
30秒で生えて30秒で消えるプレビュー環境
自作 OSS kagerou のプレビュー環境を 1 周(up → 検証 → down)しながら、内部で何が起きているかを解説する。タグを状態ストアにする設計、URL が作成前に確定する仕組み、TTL と reap の関係、削除順序が S3 先行でなければならない理由、DeleteObjects の部分失敗まで。
モノレポの無停止移行とデプロイ分離
サービスを止めずにカラムを改名し、モノレポなのにサービスごとに独立して速くデプロイする。なぜそれが要るのかを分散サービスの性質と開発生産性の歴史から説明し、Parallel Change(expand/contract)+ リリーストグル、依存グラフ由来の CI 分離、ジョブグラフによる順序強制を、既存手法との対比と実測値つきで解説する。
既存DBの外部キーから集約境界を掘り出せないか(アイディア)
サービス分割で一番重いのは集約境界の決定。既存DBのFKとトランザクションのログを「設計の化石」として読み、境界の候補を機械で出せないかという思いつき。FKを1本残したまま分割すると他サービスのデプロイが止まることを実測したのが発端。
CloudWatch Application Signals、正体みたりOpenTelemetry
React Router の SSR を Lambda に載せて Application Signals を検証した。コードは 1 行も触らずに済んだが、コンテナイメージでは使えない・ESM では起動すらしない、という 2 つの壁があった。あわせて Application Signals が OTel とどういう関係にあるのか、何が新しいのかを整理する。
コンテナ使い捨て環境のつくりかた
コンテナで動くアプリの開発用環境を AWS に立てるとき、入口(配信の形)をどう選ぶか。その判断基準を人ではなくツールに埋め込む試み。課金形態・タイムアウト上限・認証方式・ルーティング単位の4軸を、リポジトリの走査 → 判定(純関数)→ 提示に分けて実装し、診断コマンドとして切り出すまで。
motoで通って実AWSで落ちる検証の穴
moto に対する結合テストが全部 green のまま、実 AWS・実機に載せた途端に連続で死んだ記録の逆引き。CFN タグ値に JSON は入らない(moto は文字種を検証しない)、macOS の AirPlay がポート 5000 を占有して 403 を返す、古いプロキシで go-sql-driver が readColumns panic。症状から原因と対処へ引ける形でまとめる。
信頼ポリシーが正しいのにOIDCが拒否される
教科書どおりの信頼ポリシーなのに GitHub Actions からの AssumeRole が拒否される。CloudTrail で実トークンを見たら、新しめの org では sub クレームが repo:owner@ID/repo@ID:* という ID 入り形式だった。実クレームの確認手順(CloudTrail)と、両形式を併記する信頼ポリシー、gh api での ID 取得までの逆引きメモ。
PRごとに現れて消える環境をOSSにした
Vercel の PR プレビューを自分の AWS アカウントで再現する OSS「kagerou」を作った記録。ステートレス CLI + タグが真実の源 + TTL 必須という設計、sashiki と名前の規約だけで繋がる話、検証アプリ 2 つのドッグフーディングが validate / post_up / url_template を生んで契約を鍛えるまで。
MySQLブランチ基盤sashikiをOSS公開
ZFS の CoW クローンで MySQL を git のブランチのように扱う話を、PoC(1.3秒)→ FSx(分の世界)と検証してきた続編。今回はそれを製品化して sashiki という OSS にし、v0.2.0 で公開した。PR を開くと数秒で本物データ入りの MySQL プレビューがサブドメインで開くところまで AWS 実機で組み、その過程で proxy の DB 転送バグ・half-close といった『実運用でしか出ないバグ』を炙り出した記録。設計レビューで何が変わったか、汎用性はどこまであるかも正直に。
GA4とSearch Consoleの登録をCLIで
静的ブログへの GA4 導入と Search Console 登録を Analytics Admin API / Site Verification API でほぼ CLI 完結させた実践記録。gcloud 標準クライアントが analytics スコープでブロックされる問題、API 作成プロパティ特有の『データ収集の確認』ハマり、Measurement Protocol の 204 が成功を意味しない話まで。
FSxでMySQLブランチは秒でなく分の世界
EC2ローカルZFSで1.3秒だったMySQLブランチ複製をFSx for OpenZFSで作り直した検証記録。クローン52〜71秒・restore10分超・delete6分という『分の世界』のコントロールプレーンを実測し、resetは restore API ではなく新クローン+付け替えが正解形という結論に。復元中ボリュームへ mysqld を起動して datadir を壊した事故の記録も。
ZFSクローンでMySQLを1.3秒で複製
ZFS のスナップショット/クローンで MySQL のデータベースブランチを秒で作る・戻す・消す仕組みを EC2 1 台で最小再現した記録。create 1.3 秒・クローン直後の消費 数百 KB という実測と、OOM killer に無関係なブランチが殺される・破壊的操作で CoW 差分がデータ本体並みに膨らむ、という設計にフィードバックすべき 3 つの発見。
逆引きVWO→GrowthBook
VWOでやっていた操作を起点に、GrowthBookでの同等のやり方を逆引き形式でまとめる。アーキテクチャの違いから、ビジュアル編集・ゴール設定・相互排他・SEOテストまで。
接続済みVPCを製品にする境界設計
マルチアカウント TGW + internal ALB のプライベート API を題材に、共通基盤チームとアプリチームの責任境界を設計する。『接続済み VPC』を製品として渡し、SSM パラメータを契約書にし、Terraform の apply 順序を承認フローにする — 組織の統制を申請書ではなくアーキテクチャで表現するための整理。
SSRのA/Bテストをちらつきゼロにする
GrowthBook Cloud と React Router v7 (SSR) で A/B テスト環境を構築した記録。ちらつき(flicker)を出さない SSR 統合の設計、GA4 連携、REST API での実験作成、ハマりどころまで。
TGWのアクセス制御を多層で設計する
マルチアカウントを Transit Gateway で繋ぐとき、アクセス制御は単一の機能ではなく複数レイヤーの合わせ技になる。参加制御・TGW ルートテーブルのセグメンテーション・NACL・セキュリティグループまでを、入口から順に first principles で整理します。
OPセッションは書くか買うか
Lambda 前提を外して ECS でコンテナ化すると、fosite を不利にしていたステートフル化の難点が消え、Hydra も自然に動く。serverless 制約から解放された fosite vs Hydra を、サービス数・OP セッションの所有権・Cognito 連携・ロックインの観点で比較し、自社マルチプロダクトの自前 OIDC Provider にとっての解を出す。
SSOのOPセッションを誰が実装するか
SSO の本質は『OP がセッションを単一の権威として持つこと』一点に収斂する。ではその OP セッションを誰が実装するのか。自作・fosite・Ory Hydra の3アプローチを、責務分界・サーバレス適性・既存ユーザーストア連携の観点で比較し、Cognito を隠した自前 OIDC Provider にとっての最適解を出す。
OIDCセッションとSSOを3層に分解する
複数アプリから使われる OIDC Provider で、セッションはどこにどう持つべきか。RP セッション・OP セッション・トークンの3層に分解し、SSO が成立する仕組み、サーバ側セッションストアが必須な理由、ログアウト伝播、そして fosite/Hydra との責務分界を整理する。
IdPのUIはHostedかヘッドレスか
自前OIDCプロバイダーにログインUIを持たせるか、APIだけ提供してRP側で作るか。既存のMVCアプリ(Yii/Rails系)からの移行を想定し、調査項目・トレードオフ・移行パスを整理する。
rellf-authにトークン更新を実装した
自前OIDCプロバイダー (rellf-auth) に refresh token (rotation付き) と client_credentials grant を追加した。access tokenを15分に短縮し、refresh tokenで7日間セッションを維持する設計と、サービス間通信用のclient_credentialsの実装記録。
OIDCトークンは誰が持ち誰が更新するか
ID token・access token・refresh token・session cookieの役割と期限、更新の責務を整理する。「生トークンをブラウザに出さない」設計の根拠と、IdP/RP/ブラウザの責務分界を明確にする。
集約とトランザクション境界の設計
知恵袋ライクなQ&Aサービスを題材に、バリデーションの置き場所、集約とトランザクションの関係、結果整合性のコスト、複数集約をまたぐ判断フローをまとめた設計メモ。
認証と決済を分離する設計
アプリ認証と決済を混ぜない。キャリアには「ログイン用のIdP」と「決済内の本人確認」という別物が2つあり、混同が事故のもと。SBPS(まとめて支払い/auかんたん決済)を起点に、PG差し替えに備えた分離方針を整理する。
複式簿記から見るイベント駆動の歴史
イベントソーシングの本質は「状態を直接更新せず、出来事を追記し、畳み込んで状態を導く」こと。この発想は複式簿記(15世紀)に始まる数百年来の知恵の再発見であり、銀行の勘定系は命名される何十年も前からこのアーキテクチャを実践していた。その系譜を辿る。
Cognitoは永続化層と割り切る
自前OIDCプロバイダーを持つGo認証サービスで、Cognitoへの依存を永続化層として抽象化した。全経路のJWT発行を自前に統一し、usecase層にCredentialStore/ProviderStore/UserRepository interfaceを切ることで、Cognitoを透過的に差し替え可能にするまでの設計と実装の記録。
アーキテクトは都市計画家である
建築メタファーが捉えそこねている「主体の入れ替わり」という現象に着目し、ソフトウェアアーキテクトの仕事を都市計画家のそれとして再定義する。継承可能性の設計という視点から、アーキテクトの本質的役割を整理する。
機能を剥がすならVSAが速い
Layered・Clean・Hexagonal・DDD・VSA・PbF+部分DDDをリアーキテクチャ視点で比較し、Strangler Figパターンとの相性からVSAが強い理由と、段階的移行の現実解を整理する。
蘇るコネクション
コネクショニズム、コネクションマシン、ネットワーク型DB、意味ネットワーク、ワールドモデル — 「明示的なつながりを一級市民にする」世界観が異なる領域で何度も生まれ、同じ理由で敗れ、そして蘇ってきた系譜を辿る。
GoのDDDは全部に適用しないが正解
RailsのActiveRecordで育ったコードベースをGoにリプレースする際、DDDをFeature単位で部分適用するアプローチとその判断基準を実例付きで解説する。
AIエージェント同士に相互レビューさせる
2つのAIエージェント(Mitra / Aria)が異なる視点でコードレビューや設計相談に応える仕組み。ダブルダイアモンドモデルで思考を分離し、voice_samples.jsonlでキャラの口調を制御する。
Cognitoで4社のIDを1アカウントに統合
ドコモ(OIDC)・au(OpenID 2.0)・ソフトバンク(Yahoo! JAPAN OIDC)・Google・メール+パスワードの5つのログイン方法を、Cognitoの1ユーザーに統合する設計。各キャリアのIdP仕様の違い、SECRET_HASHの計算、opaque IDの扱い、PreSignUp Lambdaによる自動リンクまで。
Cognitoのsubとusernameは別物
自前OIDCプロバイダーからCognitoのAdmin APIを呼ぶ際、IDトークンのsubでAdminGetUserを叩くと失敗する。sub と cognito:username の違い、SECRET_HASHの計算対象、ローカル開発でのCognitoエミュレーター選定まで、実際に踏んだ問題を整理。
Claude Codeを長時間自律稼働させる設計
Claude Codeを長時間安定して自律稼働させるために必要なパーミッション設計、Hooks、コンテキスト圧縮対策を実例付きで解説する。
会議にAIを同席させたら議論が変わった
会議の音声をリアルタイムで文字起こしし、AIが論点・未解決事項・矛盾をマインドマップで可視化する伴走ツールのPoC。設計思想・プロンプト設計・CRDT状態管理・ダブルダイアモンドモードまで、技術的な仕組みを解説。
AWSローカルエミュレータ5種比較
Cognito を使った認証サービスのローカル開発で、floci (LocalStack) の制限にぶつかった。cognito-local、MiniStack、LocalStack 有料版、moto を含む5つのエミュレータを Cognito の機能対応で比較する。
マルチアカウントの社内サービス連携設計
AWS マルチアカウント環境でのサービス間接続方式(TGW・PrivateLink・VPC Peering・インターネット経由)をコスト計算付きで比較。Route53 Private Hosted Zone の落とし穴、IPAM の実務的な使い方、中央 egress 集約の設計判断まで整理します。
AstroでMermaidをビルド時にSVG化する
Astro ベースのブログで Markdown/MDX の Mermaid コードブロックをビルド時に SVG に変換する方法。rehype-mermaid と Playwright を使った静的生成のセットアップと、各選択肢の比較。
ポリシーエンジン5種を比較する
主要なポリシーエンジン5つを同じマルチプロダクトのユースケースで実装し、記述方法・モデル設計・運用特性を具体的に比較する。
エンタイトルメントと認可の境界
マルチプロダクト SaaS で「どのプロダクトが使えるか」と「リソースに対して何ができるか」を分離する設計。billing のエンタイトルメントと authz のポリシーの責任境界を整理する。
SaaSのプラン付与経路を設計する
法人向けシリアルキー配布、パートナー経由のリファラ付与、プロモーションコードなど、SaaS のプラン付与経路を課金サービス(billing)で統一的に管理する設計を整理。
認証ページは誰が提供すべきか
認証ページを認証基盤側でホストする(Hosted Login)か、各プロダクトに埋め込む(Embedded Login)か。セキュリティ、SSO、UX、運用コストの観点で比較する。
マルチプロダクト基盤のSDK設計
認証・認可・課金の3サービス基盤をプロダクトが簡単に利用できるようにする SDK の設計。Go バックエンド SDK とブラウザ/React SDK の責任分担、API 設計、内部フロー、段階的リリース戦略を整理。
認証・認可・課金サービスの繋ぎ方
認証(auth)・認可(authz)・課金(billing)の3サービス間の通信パターンを整理。同期API・イベント駆動・共有データベースの判断基準、未実装の要件を含めた設計方針を体系的にまとめる。
サービス間認証はClient Credentialsで
OAuth 2.0 の Client Credentials Grant をマイクロサービス間通信に適用する方法。トークンの中身、スコープ設計、キャッシュ戦略、OIDC Provider への組み込み方を実務レベルで整理。
OAuth/OIDCフローの選び方全比較
Authorization Code、PKCE、Client Credentials、Device Authorization、Implicit、Resource Owner Password の6つのフローを比較。判断フローチャートと PKCE の仕組みをわかりやすく解説。
自社マルチプロダクトでのOIDCの実際
自社で複数プロダクトを運営する際に、独自 OIDC Provider を立てて SSO を実現する具体的な方法。Authorization Code Flow の各ステップ、トークンの中身、クライアント登録、セッション管理まで実務レベルで整理。
プレビュー環境をGoogle OIDCで保護する
GitHub PR が作られたら自動でプレビュー環境を作成し、共有 CloudFront + Lambda@Edge + Google OIDC でアクセス制限をかける設計。CloudFront を PR ごとに作らずに実現する方法を整理。
認証・認可・課金の3サービス責任分離
マルチプロダクト向けの共通基盤を認証(rellf-auth)・認可(rellf-authz)・課金(rellf-billing)の3サービスで構成する設計。依存関係、データフロー、契約プランに応じた認可の実装パターンを整理。
認可は多層で設計する
認可を複数の粒度で設計するためのフレームワーク(XACML、NIST ABAC、Zanzibar/ReBAC)を整理し、JWT groups + AVP/Cedar の実装パターンとの対応関係をまとめる。
OIDCでログイン強度を表現する
NIST SP 800-63B の AAL を OIDC Provider でどう実装するか。amr / acr / auth_time クレームの使い方、ステップアップ認証、独自 OIDC Provider への組み込み方を整理。
匿名認証の実装3パターンと法的考慮
匿名認証の実装パターン3つ(Cookie+DB、独自匿名JWT、Cognito Identity Pool)を比較し、ライフサイクル設計と GDPR / 改正電気通信事業法の同意要件まで整理する。
Cognito移行でSESはそのまま使えるか
独自認証から Cognito に移行する際に、既存の SES ドメイン認証・本番モード・レピュテーションをそのまま引き継ぐときの考慮点を整理。
Cognito確認メールをカスタマイズする
Cognito のデフォルト確認メールを、SES による送信元カスタマイズと CustomMessage Lambda による HTML テンプレートで置き換えた記録。alias_attributes 環境での SignUp/ConfirmSignUp のハマりポイントも。
rellf-authの設計で工夫したこと
独自 OIDC Provider を Go + Lambda で構築する中で行った設計上の工夫。Proxy IdP、ステートレス認可コード、ドメインモデルによるライフサイクル管理、メール任意化フローなど。
メールアドレス任意のOIDCフロー設計
メールアドレスを持たないユーザー(外部ID認証やユーザー名のみのアカウント)に対応するため、OIDC の Authorization Code Flow の途中にメール登録促進画面を挟む設計と実装。
OpenID 2.0をCognitoで受ける設計
OpenID 2.0 ベースの外部 IdP を AWS Cognito に統合するための設計と、Go ライブラリの選定調査。Cognito が OpenID 2.0 を非サポートなため、Proxy IdP パターンで吸収する。
ユーザーライフサイクルのドメインモデル
参照は interface、更新は状態ごとの struct という設計判断で、ユーザーのライフサイクル管理をコンパイル時に安全にモデリングした話。
AVPはRBAC特化で使う設計判断
Amazon Verified Permissions を RBAC 特化で運用し、リソースレベルの認可(ABAC)はアプリケーション側のビジネスロジックに委ねる設計判断に至った経緯と実装を解説します。
VPC Latticeでプロダクト間通信
5〜6 プロダクト × stg/prd のマルチアカウント環境で、VPC 間通信をどう設計するか。VPC Lattice を中心に、Transit Gateway との比較、通信制御、プロトコル制限、クォータまで含めた設計判断を整理します。
AVPでマルチプロダクト認可基盤
複数プロダクトにまたがる認可基盤を Amazon Verified Permissions (AVP) + Cedar で設計する。Namespace 分離、ポリシーテンプレート、管理委譲、Dry Run まで含めたフル構成の設計を解説します。
Cognitoを隠した自作OIDC Provider
Cognito をユーザーストアとして内部利用しつつ、外部には独自署名の JWT を返す OIDC Provider(Proxy IdP)を Go + Lambda で構築した話。設計判断とステートレスな実装の詳細を解説します。
マルチプロダクトがOIDCを選ぶ理由
マルチプロダクト展開を見据えた認証基盤の設計戦略。OIDCを軸にした設計のメリットと、他の選択肢との比較を解説します。
ブログはじめました
rikuka.devのテックブログを開設しました。Astro v6とMDXを使って構築しています。