ブログ
Envoy Proxyによるgateway構築のアーキテクチャパターン
Envoy Proxyを中核としたAPI Gateway構築の設計パターンを、制御プレーン・認可実装・OSSゲートウェイとの比較の3部構成で「課題→解決」の形で整理する。
認証認可アーキテクチャの変遷（1）モノリスから認証基盤へ
OAuth/OIDCを「なぜそのアーキテクチャが必要になったか」の文脈から追う5部構成シリーズの第1部。モノリスのセッション認証が抱えた課題と、パスワードアンチパターン、認証基盤（IdP）導入までを整理する。
認証認可アーキテクチャの変遷（2）API Gatewayとマイクロサービス
サービス数が増えると、トークン検証の統制はガバナンス問題になる。API Gatewayによる認証集約、Phantom Token、Token Exchange、そしてその背後にある組織設計のトレードオフを扱う。
認証認可アーキテクチャの変遷（3）クライアント認証の高度化と段階的移行
Bearerトークンの弱さから出発し、PKCE・BFF・DPoP・送信者制約トークンによる盗難耐性の強化と、レガシーからの現実的な段階的移行戦略を解説する。
認証認可アーキテクチャの変遷（4）認可サーバーの内部構造と信頼性設計
認可サーバー（AS）の内部をどう構えるか。ログイン/同意の外部化、フェデレーション分離、認可の吸い込み防止といった分離パターンと、可用性・鍵ライフサイクルを軸にした信頼性設計、そしてフルスクラッチ時の品質の外部物差しを整理する。
認証認可アーキテクチャの変遷（5）自作認可サーバーのデータモデルと運用設計
RFCが規定しないASの裏側——何を記憶し、誰に何を許可し、どう管理させるか。Client・Resource Server・Grant・Tokenの4エンティティを軸に、自作認可サーバーのデータモデルと運用設計を論じる。
認知的技術的負債：チーム間で「毎回すり合わせている」のは負債である
チーム間協業で較正コストを払い続けても、Contract・ADR・共有語彙という「プロトコル変換器」が蓄積しなければ、それは複利の利子がつく負債だ。Team Topologiesの3モードをコスト負担設計として読み直す。
AI時代の「仕様」問題：翻訳方向の非対称性とSSoTの所在
AI開発文脈が「仕様」という言葉を再発明した背景を整理し、意図とImplementationの間にある確定性・反証可能性の非対称性から、SSoTをどこに置くべきかを論じる。
ソフトウェア開発のボトルネック変遷：計算資源から認知資源、そしてこれから
制約理論の視点でソフトウェア開発の歴史を読み直す。計算資源・認知資源・コンテキストウィンドウという3つのボトルネックが持つ同型の構造と、有限リソース管理という不変の問題を論じる。
ソフトウェアの質の上限は何が決めるのか：人間の欲求・AIの知性・共有知の設計
ソフトウェアの質の上限を規定するものは何か。人間の言語化能力、AIの知性、共有知の設計という3つの軸から、人間とAIの関係の段階的進展を論じる。
「仕様」の正体：Requirements・Contract・Implementationによるソフトウェアの理解
「仕様」「機能」という言葉が持つ曖昧さを分解し、Requirements・Contract・Implementationという枠組みでソフトウェアを正確に理解するための語彙を提案する。
構造と振る舞い：型とテストによるアジリティと品質の両立
「早く作る」と「正しく作る」はトレードオフではない。型による構造の表現とテストによる振る舞いの検証という二層戦略で、アジリティと品質を両立させる方法を考察する。
主語の位置：OOPと関数型における関数適用スタイルの違い
shape.area()とarea(shape)の違いは単なる構文ではなく、データと操作の関係性をどう捉えるかというパラダイムの違いを反映している。
ABR-Geocoderを試す
デジタル庁が提供するジオコーディングツールABR-Geocoderの機能検証。住所正規化の精度、セットアップ方法、AWS ECSでの運用方針をまとめました。
仕様駆動開発への懐疑
AIコーディングエージェント時代に「仕様を先にすべて書く」アプローチが復活している。しかしこれはウォーターフォールの焼き直しではないか？歴史とフィードバックループの重要性から検証する。
ECS Fargateで必要なリソースの全体像
ECS Fargateでアプリケーションを構築する際に必要なリソースを3層構造で整理し、自信を持って0から構築できる状態を目指す