Xリンク記事メモ集：AI、認証、AWS、設計、運用¶
#x#web-clip#ai#aws#security#backend#system-design
Xのポスト本文ではなく、ポストに外部記事やリンクが含まれる場合はリンク先を本筋として整理した。 X Articleなど本文取得が不安定なものは、無理に補完せず partial として残す。
今回の読み方¶
優先順位¶
-
外部記事がある場合は、X本文ではなく外部記事を主対象にする。
-
画像だけのポストは、添付画像や oEmbed で取得できた本文を対象にする。
-
X Articleのように本文取得が安定しないものは、URLと確認観点を残す。
確認済みの本筋リンク¶
-
Zenn: Terraform secret / JWT localStorage
-
カミナシブログ: S3 Tablesログ基盤
-
Qiita: Claude Code人生管理
-
Scrapbox: atoms/hooks分類の問題
tfstateに平文を残さずに秘密情報を管理する article¶
概要¶
TerraformでSOPSなどから復号した秘密情報を扱うと、通常のdata sourceやresource属性ではtfstateや保存済みplanに平文が残る。 記事はTerraformのephemeral resourceとAWS Providerのwrite-only attributeを組み合わせ、Secrets Managerなどへ値を書き込みつつstateに残さない構成を説明している。 ただし、過去のstateやbackupに残った秘密情報は消えないため、移行時はローテーションとセットで考える必要がある。
要点¶
-
sensitive = trueはCLI出力を伏せるだけで、tfstateやplan fileから値を消すものではない。 -
ephemeralはTerraform実行中だけ値を扱い、state/planに永続化しない。 -
secret_string_woのようなwrite-only attributeはAWS APIへ値を送るがstateには保存しない。 -
write-only値は差分検出できないため、
*_wo_versionのような更新トリガーを明示する。 -
既に漏れたstate履歴、S3 versioning、backupは別途削除やsecret rotationが必要。
深掘り問い¶
-
既存tfstateに入ったsecretを検出し、ローテーション対象にする運用をどう作るか。
-
planとapplyを別ジョブに分けるCIで、ephemeral値の再取得前提をどう保証するか。
-
OpenTofuのstate encryptionとTerraformのwrite-only運用をどう比較するか。
Amazon S3 Tablesでつくるログ分析基盤 article¶
概要¶
CloudWatch Logsの取り込みコスト増大に対し、Amazon S3 TablesとApache Icebergを使ってアプリケーションログ分析基盤へ移行した事例。 CloudWatch LogsとS3 Tablesへ並行配信し、Grafanaのクエリ先を切り替えて運用確認した後、エラーログ以外をS3 Tablesへ寄せる段階的移行を採っている。 ログ投入コストは大きく下がる一方、パーティション変更やIntelligent Tieringの設定タイミングなど制約もある。
要点¶
-
CloudWatch Logsの主要コストは、保管よりもログ取り込みに寄りやすい。
-
S3 TablesはIceberg形式をAWSマネージドで扱い、AthenaやSparkからSQLで参照できる。
-
移行時はCloudWatch LogsとS3 Tablesへ二重配信して、クエリ性と運用性を検証する。
-
エラーログなどアラートに直結するログはCloudWatch Logsに残す設計も現実的。
-
S3 Tablesのパーティション変更やIntelligent Tieringには現時点の制約がある。
深掘り問い¶
-
ログの「検索頻度」「鮮度」「アラート用途」で保存先をどう分けるか。
-
CloudWatch Logsを完全に捨てずに残すべきログの条件は何か。
-
Icebergテーブルのスキーマ進化をアプリログ設計にどう組み込むか。
「JWTをlocalStorageに置くな」はなぜ言われるのか article¶
概要¶
CookieセッションからSPA時代のJWT/localStorage、さらにBFFとCookie回帰へ至る流れを、Webアプリ技術とブラウザ制約の変化で整理した記事。 「localStorageが絶対悪」という単純化ではなく、サードパーティCookie規制、CORS、OAuth/OIDC、XSSリスク、BFF普及が設計を押し戻した経緯を説明している。 現代のフルスタックフレームワークでは、トークンをブラウザから隔離し、Cookieとサーバ側境界を使う設計が再び自然になっている。
要点¶
-
サーバサイドレンダリング中心の時代は、HttpOnly Cookieによるセッション管理が自然だった。
-
SPAとAPI分離により、AuthorizationヘッダとlocalStorage保存の設計が広まった。
-
XSSでブラウザ内トークンを盗まれる問題が、BFFやToken-Mediating Backendを後押しした。
-
BFFを置くなら、ブラウザにJWTを持たせる理由は弱くなり、Cookieセッションへ戻りやすい。
-
CookieでもCSRF、SameSite、Origin/Referer検証、XSS対策は別途必要。
深掘り問い¶
-
SPA単体、BFF、SSRのどれを選ぶかを認証設計からどう判断するか。
-
HttpOnly Cookieに戻す場合、CSRFとOAuth callback周辺をどう守るか。
-
既存localStorage JWT構成からBFFへ移行する段階設計はどうするか。
Claude Codeに人生を管理させて3ヶ月、一番効いたのは自動化じゃなかった article¶
概要¶
Claude CodeとGitHubを使って、自分の価値観、目標、日々の記録、知識をAIが参照できる形に整理した実践記録。 SkillsやMCPによる自動化も扱うが、記事の中心は「AIに渡すために自分を言語化する強制力」が最も効いたという内省にある。 AIを人生の意思決定者にするのではなく、方向は人間が握り、実行や振り返りをAIで支援するという距離感が重要。
要点¶
-
AI相談が浅い原因は、AIではなく「入力する自分の文脈」が曖昧なことにある。
-
情報を自己、方向、仕事、日誌、知識のように時制や用途で分けるとAIが参照しやすい。
-
CLAUDE.mdのような運用ルールを書くと、AIが守るべき境界を明示できる。
-
SkillsやMCPは便利だが、本質は自分の価値観や判断基準を言葉にすること。
-
ゴールは人間が決め、AIには整理、実行、振り返りを任せる。
深掘り問い¶
-
自分のノートをAIに読ませるとき、どの情報は渡さないべきか。
-
日次ログ、週次振り返り、月次目標をどの粒度で分けると続くか。
-
AIが提案した人生方針を、人間側でどう検証するか。
atoms/hooksのような分類は「小さく分ける」を妨害する article¶
概要¶
UIやフロントエンドのファイル分類で、atoms、hooks、componentsのような「種類別フォルダ」を先に作ると、機能や責務で小さく分ける判断を邪魔するという論点。 分類のための分類は、変更理由が近いものを近くに置く設計と衝突しやすい。 実務では「何であるか」より「何のために一緒に変わるか」を軸にした方が保守しやすい。
要点¶
-
技術種別フォルダは見た目は整理されるが、機能単位の凝集を壊すことがある。
-
小さく分けるとは、ファイル数を増やすことではなく、変更理由を狭めること。
-
hooksやatomsといった名前は、境界設計ではなく置き場所ルールになりがち。
-
分類規則が強すぎると、関連コードを追う距離が伸びる。
-
プロジェクトではfeature単位、ユースケース単位、境界単位の配置を検討したい。
深掘り問い¶
-
今のコードベースで、同じ変更理由のファイルが何ディレクトリに散っているか。
-
技術種別分類とfeature分類のどちらがレビュー時の認知負荷を下げるか。
-
共通化すべきものと、機能内に閉じるべきものをどう判断するか。
AWSを触り始めて3ヶ月目の若手が頭一つ抜ける方法 post¶
概要¶
AWS SAA取得で終わらせず、VPC、EC2、RDSの基本構成を自分で作り、なぜその構成にしたかを説明できる形にするという実務寄りの学習提案。 構成図とGitHubへのアウトプットまで含めることで、知識を「説明可能な実装経験」に変えるのが主眼。
要点¶
-
資格知識だけでなく、自分で基本構成を作る。
-
構成理由を1分で説明できるようにする。
-
構成図を残し、職務経歴書やポートフォリオに接続する。
-
なぜサブネットを分けるのか、RDSをどこに置くのかなど設計理由を言語化する。
-
学習成果を人に見せられる証跡に変える。
Latency in System Design image/post¶
概要¶
システム設計におけるレイテンシの定義、重要性、構成要素、原因、改善策、スループットとの違いをまとめた図解。 レイテンシは単一リクエスト完了までの時間であり、ネットワーク、処理、DB、レスポンス送信など複数要素の合算として見る。 面接では許容応答時間、ボトルネック、CDN/キャッシュ、DB/API設計、整合性やコストとのトレードオフまで話すとよい。
要点¶
-
レイテンシはリクエスト送信からレスポンス受信までの時間。
-
ネットワーク、アプリ処理、DBアクセス、外部API、ディスクI/Oが主な内訳。
-
キャッシュ、CDN、DBインデックス、ロードバランシング、非同期化、圧縮で改善する。
-
スループットは単位時間あたり処理数で、レイテンシとは別指標。
-
平均だけでなくp95/p99を見ないと体感の遅さを見落とす。
Cookies / Sessions / JWT の違い post¶
概要¶
Cookie、Session、JWTを混同しないためのバックエンド基礎メモ。 Cookieはブラウザに保存されリクエストに同送される小さなデータ、Sessionはサーバ側に状態を持ちブラウザにはIDだけを置く設計、JWTは署名付きトークンとしてクレームを持ち運ぶ形式。 実務では保存場所、失効方法、XSS/CSRF、サーバ側状態の有無を比較して選ぶ。
要点¶
-
Cookieは保存・送信の仕組みであり、認証方式そのものではない。
-
Sessionはサーバ側ストアで即時失効しやすいが、スケール時は共有ストアが必要。
-
JWTはステートレスに見えるが、失効やローテーションを設計しないと危険。
-
localStorage保存はXSS時に盗まれやすい。
-
HttpOnly/Secure/SameSite CookieとBFF設計をセットで考える。
CDNが原因でCORSが突然壊れる理由 post¶
概要¶
コード変更がないのにCORSが壊れた原因として、CDNのキャッシュやヘッダー処理を疑う面接問題。 CDNがOPTIONS preflightをキャッシュしたり、Access-Control-Allow-Origin を落としたり、Vary: Origin 不足で別Origin向けレスポンスを返すとブラウザ側でブロックされる。
要点¶
-
CORSはサーバが許可ヘッダーを返し、ブラウザが強制する仕組み。
-
CDNはOriginサーバとブラウザの間でレスポンスヘッダーを変える可能性がある。
-
Originごとに許可値が変わるなら
Vary: Originが重要。 -
preflightと実リクエストの両方でヘッダーを見る。
-
切り分けではCDN bypass、キャッシュpurge、edgeルール確認を行う。
AIの出力を他人に読ませるなら整える努力が必要 post¶
概要¶
AI出力をそのまま他人に渡すことへのマナーと責任の話。 AIが有用であることと、読み手にそのまま長い出力を読ませてよいことは別問題であり、人間側が目的、前提、判断、要約、レビュー観点を整える必要がある。
要点¶
-
AI出力は下書きであり、完成物ではない。
-
他人に渡す前に、読み手に必要な文脈と目的を補う。
-
長文出力は要約、構造化、根拠確認が必要。
-
レビュー依頼では「何を見てほしいか」を明示する。
-
AIの主張を自分の判断として採用するなら検証責任を持つ。
X Article 2件 partial¶
取得状況¶
どちらも短縮URLはX Articleに展開できたが、本文はローカルcurl、検索、通常openで安定取得できなかった。 ここでは空想で補完せず、元ポストと本筋URLだけを保存する。あとでブラウザで開いて本文確認する対象。
確認する問い¶
-
記事の主張は設計、実装、キャリア、運用のどの領域か。
-
外部記事として保存する価値があるなら、独立したHTMLメモに分割するか。
-
引用ではなく自分の理解として残すべき要点は何か。