コンテンツにスキップ

X 投稿ドラフト（2026-07-19・徹底パクり版 v2）

パクり元の型（subagent ブラウザ調査より）:

型 パクり元 実績
A. ナンバリング連載 + 手描き風図解1枚 + 面接ポイント箇条書き @SidJain_80「Day N/60 System Design Series」 フォロワー3.3Kで表示4〜10K、連載開始宣言はいいね660/表示33K
B. 面接質問を投稿 → リプ欄で自分が本番のつもりで回答 @Sarthak4Alpha「Senior backend interview question:」+ 回答後出し 安定して返信10〜25。自リプで2度目の露出

共通ルール: - 1投目完結。スレッドにしない（SidJain のスレッド2投目以降は表示が1/10に落ちていた） - 本文に CTA・リンクなし - リプ回答は投稿から半日〜1日後（他人のリプが付いてから）

投稿0: 開設ポスト（自己紹介・連載開始宣言）

一番最初に投稿し、当面の固定ポストにする。 パクり元は SidJain の連載開始宣言（本人の最高実績: いいね660/表示33K）。 「誰が・なぜ・何をやるか」を1投で言い切る。ストーリーは実体験なので脚色しないこと。

postの内容

技術面接でボコボコにされた。 「その設計にした理由は?」に何も返せず沈黙。

悔しいので基礎から学び直します。 AIがコードを書く時代、人間に残るのは設計を語ることだと思う。

毎日、図解1枚で学び直しを公開します。 同じ悔しさを知ってる人に届きますように。Day1は明日から。

（139字）

※ シーズン1は AI/LLM 基礎に決定（2026-07-19）。最初の連載は「面接で聞かれる AI/LLM 基礎 Day 1/30」から始める。インフラ基礎（下の A Day 1〜20）はシーズン2 で使う

画像生成有無

無（テキストで語る回。プロフィール文・ヘッダー整備とセットで出す）

  • 固定ポストは後日、Day 30 総集編 or 深掘りツリーが伸びたタイミングで差し替え
  • プロフィール文もこのストーリーと揃える（例:「技術面接でボコボコにされて学び直し中。設計を語れる人間になる。図解で毎日1枚」）

トーンと140字制約

  • 連載（A）や解説系は元の解説調のままでよい。人間味を出すのは 投稿0 と F 枠（実況・build in public）に限定。連載にたまに「今日これを人に説明できなくて詰まった」を混ぜる程度で十分
  • 無課金の間は本文全角140字以内が上限。以下のドラフトは字数を気にせず書いてあるので、投稿時にどちらかで対応する:
  • 課金（プレミアム）して長文のまま出す
  • 無課金のまま出すなら「タイトル行+一言の答え+『深掘りは図で』」に圧縮し、深掘りポイントの箇条書きは図解の右下に「深掘りされるポイント」枠として移す（画像プロンプトの「内容:」末尾に枠の指示を1行足す）+ あふれた分は自リプへ

A-6. AI/LLM 基礎シリーズ【シーズン1・ここから投稿する】

連載名: 「面接で聞かれる AI/LLM 基礎 Day N/30」。毎回「面接でどう聞かれるか」の切り口を必ず入れる（競合の AI 解説アカウントとの差別化）。全体の Day 構成は 200post計画.md A-6 を参照。

AI Day 1: LLM は何をしているのか

postの内容

面接で聞かれる AI/LLM 基礎 Day 1/30 — LLM の正体

「LLM って結局何をしてるんですか?」に一言で: 「次に来る確率が高い単語」をひたすら予測して繋げている。それだけ。

面接で深掘りされるポイント: ・それだけなのになぜ会話が成立する?（大量の文章で「続き」を学習済み） ・なぜ流暢なのに間違える?（正しさではなく「もっともらしさ」を選ぶ仕組み） ・同じ質問で毎回答えが違うのはなぜ?（確率からのサンプリング）

図に「次の単語予測」の様子をまとめた。

明日は Day 2: トークン。AI の料金と長さの単位。

画像生成有無

有

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 上に文章「明日の天気は」と書かれた吹き出し。その下にLLMの箱、そこから候補の単語が確率バー付きで並ぶ:「晴れ 45%」（青で最大のバー）「雨 30%」「くもり 20%」「カレー 0.1%」（赤で極小のバー）。下に注記「一番もっともらしい続きを選んでいるだけ」。

AI Day 2: トークン

postの内容

面接で聞かれる AI/LLM 基礎 Day 2/30 — トークン

「トークンって何ですか?」に一言で: LLM が文章を扱う最小単位。料金も、入力の上限も、全部この単位で数える。

面接で深掘りされるポイント: ・なぜ文字数じゃなくトークン数?（モデルは単語の断片で処理している） ・日本語は英語より割高になりがち、はなぜ? ・「コンテキスト上限」もトークンで数える（明日のテーマ） ・API のコスト見積もりはトークン数 × 単価

図に「文章がトークンに割れる様子」をまとめた。

明日は Day 3: コンテキストウィンドウ。AI が会話を忘れる理由。

画像生成有無

有

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 上に1つの文「面接の練習をしたい」。ハサミのアイコンで切られて、下にブロック片「面接」「の」「練習」「を」「したい」が並ぶ（各ブロックに青枠）。右側に電卓のアイコンと「料金 = トークン数 × 単価」「入力の上限もトークンで数える」の注記。

AI Day 3: コンテキストウィンドウ

postの内容

面接で聞かれる AI/LLM 基礎 Day 3/30 — コンテキストウィンドウ

「AI が前の話を忘れるのはなぜ?」に一言で: 一度に読める量（コンテキストウィンドウ）に上限があり、溢れた分は存在しないのと同じだから。

面接で深掘りされるポイント: ・チャットの「記憶」の正体は?（毎回、履歴を全部送り直しているだけ） ・上限を超えたらどうする?（古い分を要約する / 削る / 外部に逃がす） ・「長く読める=賢い」ではない理由 ・この制約が RAG（Day 7）に繋がる

図に「窓からはみ出す会話」をまとめた。

明日は Day 4: ハルシネーション。AI が堂々と嘘をつく理由。

画像生成有無

有

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 中央に大きな窓枠（青）「コンテキストウィンドウ=一度に読める量」。窓の中に会話の吹き出しが数個。窓の左外に、はみ出した古い吹き出きがグレーでフェードアウトし赤注記「ここはもう見えていない」。下に注記「チャットの記憶=毎回履歴を送り直しているだけ」。

AI Day 4: ハルシネーション

postの内容

面接で聞かれる AI/LLM 基礎 Day 4/30 — ハルシネーション

「AI はなぜ堂々と嘘をつくんですか?」に一言で: 「正しい答え」ではなく「もっともらしい続き」を出す仕組みだから。知らなくても、それらしく埋める。

面接で深掘りされるポイント: ・バグではなく仕組み上の性質、と言えるか ・対策は?（RAG で根拠を渡す / 出典を出させる / 「分からない」と言わせる設計） ・ゼロにはできない前提で、どこに人間のチェックを置くか ・「仕様としてどう扱うか」を語れると実務経験者に聞こえる

図に「知ったかぶりが生まれる仕組み」をまとめた。

明日は Day 5: embedding。意味を数値にする技術。

画像生成有無

有

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左に質問の吹き出し「◯◯法の第12条は?」。中央のLLMの箱の中に天秤のイラスト:「正しさ」の皿は空っぽ（グレー）、「もっともらしさ」の皿が重く傾く（青）。右に自信満々の回答吹き出し（もっともらしい嘘）に赤注記「知らなくても、それらしく埋める」。

AI Day 5: embedding

postの内容

面接で聞かれる AI/LLM 基礎 Day 5/30 — embedding

「embedding って何ですか?」に一言で: 文章の「意味」を数値の座標に変換したもの。意味が近い文章は、座標も近くなる。

面接で深掘りされるポイント: ・何が嬉しい?（「意味で探す」検索ができるようになる） ・キーワード検索と何が違う?（「賃金」と「給料」を同じ意味と扱える） ・座標同士の「近さ」はどう測る?（類似度） ・これが明日のベクトル検索、その先の RAG の土台

図に「意味の地図」をまとめた。

明日は Day 6: ベクトル検索。億件から意味で探す。

画像生成有無

有

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 2次元の座標平面（軸はラベルなしの矢印のみ）。「給料」「賃金」「年収」が近くに固まって青い丸で囲まれ「意味が近い=座標が近い」。遠く離れた場所に「カレー」（グレー）。左端に変換の流れ:「文章」→箱「embeddingモデル」→「座標の数値 [0.2, -0.8, …]」。

AI Day 6: ベクトル検索

postの内容

面接で聞かれる AI/LLM 基礎 Day 6/30 — ベクトル検索

「ベクトル検索は普通の検索と何が違う?」に一言で: キーワードの一致ではなく、embedding の座標が「近い」文書を探す。言い回しが違っても意味で当たる。

面接で深掘りされるポイント: ・億件の中からどう速く探す?（全件比較はしない。近似最近傍=ANN で「だいたい近い」を高速に引く） ・精度と速度のトレードオフを説明できるか ・キーワード検索と併用する場面は?（型番・固有名詞は完全一致が強い） ・「億件に耐える設計とは、億件を触らない設計」

図に探し方の違いをまとめた。

明日は Day 7: RAG。AI に「調べてから答えさせる」仕組み。

画像生成有無

有

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左右対比。左「キーワード検索」: 検索窓「賃金」→文書の山から「賃金」の文字が一致した1枚だけ釣り上げる、「給料」の文書は素通り（赤で「見つからない」）。右「ベクトル検索」: 座標平面上で質問の点の周りに円を描き、近くの「給料」「賃金」「年収」の文書点をまとめて拾う（青）。

AI Day 7: RAG

postの内容

面接で聞かれる AI/LLM 基礎 Day 7/30 — RAG

「RAG って何ですか?」に一言で: 質問が来たらまず社内文書などを検索し、見つかった根拠を LLM に渡してから答えさせる仕組み。

面接で深掘りされるポイント: ・何を解決する?（LLM が知らないこと・ハルシネーション・情報の鮮度） ・ファインチューニングとの使い分けは?（知識の追加は RAG が第一候補） ・精度を決めるのはどこ?（検索の質とチャンク分割。生成より検索がボトルネック） ・「根拠も一緒に表示する」とハルシネーション対策になる理由

図に全体の流れをまとめた。

明日は Day 8: チャンク分割。RAG の精度はここで決まる。

画像生成有無

有

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左から右へ番号付きフロー: ①質問の吹き出し→②「検索」（文書の山からベクトル検索で2枚釣り上げる、青）→③封筒に「質問+根拠の文書」を同封→④LLMの箱→⑤回答の吹き出し「根拠: 文書A」付き。下に注記「知らないことは、調べてから答えさせる」。

AI Day 14: エージェントとループエンジニアリング

postの内容

面接で聞かれる AI/LLM 基礎 Day 14/30 — AI エージェント

「エージェントって何が新しいんですか?」に一言で: LLM に道具を渡し、目標を達成するまで「観察→考える→行動」を繰り返させる while ループ。この設計がループエンジニアリング。

面接で深掘りされるポイント: ・チャットとの違いは?（1問1答で終わらず、自分で次の行動を決めて回り続ける） ・ループはいつ止める?（終了条件・最大ステップ数・コスト上限） ・暴走はどう防ぐ?（危険な操作だけ人間の承認を挟む=HITL） ・ツールの実行結果をどうループに戻すかで精度が決まる

図にループの全体像をまとめた。

明日は Day 15: MCP。エージェントに道具を繋ぐ規格。

画像生成有無

有

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 中央に大きな円形のループ矢印（青）。ループ上に3つのノード:「観察」「考える(LLM)」「行動(ツール実行: 検索・コード・ファイル)」。ループの出口が2つ:「目標達成→終了」（青のゴール旗）と「最大ステップ/コスト上限→強制停止」（赤）。ループの脇に人間のアイコン「危険な操作だけ承認(HITL)」。見出し「エージェント = LLMのwhileループ」。

A. 図解あり解説シリーズ（7テーマ・画像生成すべて有）【シーズン2 に回す】

連載名: 「面接で聞かれるインフラ/バックエンド基礎 Day N/30」 構成の完コピ: フック（面接での問われ方）→ 一言の答え → 深掘りポイント箇条書き → 図解1枚 → 次回予告

Day 1: Redis

postの内容

面接で聞かれるバックエンド基礎 Day 1/30 — Redis

「Redis はなぜ速いんですか?」に一言で: 全データをメモリに置き、シングルスレッドのイベントループで捌くから。

面接で深掘りされるポイント: ・「シングルスレッドなのになぜ速い?」（コンテキストスイッチとロックが無い） ・メモリが溢れたらどうなる?（eviction ポリシー） ・再起動したらデータは?（RDB / AOF） ・キャッシュが一斉に切れたら?（cache stampede 対策）

図に全体像をまとめた。

明日は Day 2: SQL のインデックスはなぜ速いのか。

画像生成有無

有（図解: クライアント→イベントループ→メモリ上のデータ構造の1枚図。eviction / 永続化を端に添える。手描き風）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左にクライアント3台。中央に「イベントループ（シングルスレッド）」と書いた1本の輪。右に「メモリ」の大きな箱、中にハッシュ・リスト・セットの小箱。下端に注記2つ「メモリ溢れ→eviction」「再起動→RDB/AOFで復元」。

Day 2: SQL（インデックス）

postの内容

面接で聞かれるバックエンド基礎 Day 2/30 — SQL インデックス

「インデックスを張るとなぜ速くなるんですか?」に一言で: 全行を舐める代わりに、B-tree を数段辿るだけで行に届くから。

面接で深掘りされるポイント: ・インデックスが「効かない」ケースは?（カラムに関数、前方一致でない LIKE） ・複合インデックスの順序はなぜ重要? ・インデックスを増やすデメリットは?（書き込みが遅くなる） ・実行計画はどう確認する?（EXPLAIN）

図で B-tree の辿り方を描いた。

明日は Day 3: ALB。ロードバランサーの L7 と L4。

画像生成有無

有（図解: フルスキャン vs B-tree 探索の対比図。100万行→3ステップ、のような数字を入れる）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左右対比。左「フルスキャン」=100万行の長い表を上から下まで赤い矢印がなぞり「100万回」。右「B-tree インデックス」=3段のツリーを根→葉へ青い矢印が3ステップで辿り「3回で到達」。

Day 3: ALB（ロードバランサー）

postの内容

面接で聞かれるインフラ基礎 Day 3/30 — ALB

「ALB と NLB の違いは?」に一言で: ALB は L7（HTTP の中身を見て振り分ける）、NLB は L4（TCP をそのまま高速に流す）。

面接で深掘りされるポイント: ・パスベースルーティングができるのは ALB だけ ・固定 IP が必要なら NLB ・gRPC(HTTP/2) を通すなら? ・ヘルスチェックで unhealthy になった後の挙動は?

図で「どのレイヤーで何を見ているか」をまとめた。

明日は Day 4: コンテナはなぜ VM より軽いのか。

画像生成有無

有（図解: リクエストが ALB で URL パスにより振り分けられる図 + L4/L7 の位置づけ。手描き風）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左からリクエストの矢印→中央「ALB」→右へ2分岐。「/api →」でAPIサーバー群、「/img →」で画像サーバー群。下に横帯で「L7: HTTPの中身を見る=ALB」「L4: TCPをそのまま流す=NLB」の位置づけ。

Day 4: コンテナ

postの内容

面接で聞かれるインフラ基礎 Day 4/30 — コンテナ

「コンテナはなぜ VM より軽いんですか?」に一言で: ゲスト OS を持たず、ホストのカーネルを共有して「プロセス」として動くから。

面接で深掘りされるポイント: ・では何を「隔離」している?（namespace: プロセス・ネットワーク・ファイルシステム） ・リソース制限はどうやる?（cgroup） ・イメージがレイヤー構造なのはなぜ? ・「コンテナは軽い VM」という説明はどこが不正確?

図で VM とコンテナのレイヤーを並べた。

明日は Day 5: Kubernetes。Pod と Service の関係。

画像生成有無

有（図解: VM スタック（HW→ホストOS→ハイパーバイザ→ゲストOS→アプリ）vs コンテナスタックの定番対比図）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左右対比の積み木図。左「VM」: 下からハードウェア/ホストOS/ハイパーバイザ/ゲストOS×2/アプリ。右「コンテナ」: 下からハードウェア/ホストOS/コンテナランタイム/コンテナ×3。左のゲストOS層だけ赤で囲み「ここが無いから軽い」。

Day 5: Kubernetes

postの内容

面接で聞かれるインフラ基礎 Day 5/30 — Kubernetes

「Kubernetes は結局何をしてくれるんですか?」に一言で: 「あるべき状態」を宣言すると、現実をそこに合わせ続けてくれる仕組み。

面接で深掘りされるポイント: ・Pod / Deployment / Service の役割の違いは? ・Pod が死んだら誰が復活させる?（self-healing の仕組み） ・ローリングアップデートはどう動く? ・Service はなぜ必要?（Pod の IP は変わる）

図に3つの関係をまとめた。

明日は Day 6: CI/CD。「CD」の2つの意味。

画像生成有無

有（図解: Deployment → ReplicaSet → Pod ×3、その前段に Service が立つ関係図。手描き風）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 上から「Deployment」→「ReplicaSet」→「Pod×3」の階層図。左からユーザー→「Service」→Pod群への矢印。Podの1つに×印、その横に新しいPodが生える矢印と「自動で復活」の注記（青）。

Day 6: CI/CD

postの内容

面接で聞かれる開発基礎 Day 6/30 — CI/CD

「CI と CD の違いは?」に一言で: CI はマージのたびにビルドとテストを回すこと。 CD は「いつでも出せる状態を保つ」（Delivery）か「そのまま自動で出す」（Deployment）かの2つの意味がある。

面接で深掘りされるポイント: ・Delivery と Deployment、あなたのチームはどっち? なぜ? ・デプロイが失敗したらどう戻す?（ロールバック戦略） ・本番だけ壊れるのを防ぐには?（カナリア・feature flag） ・パイプラインのどこで何をテストする?

図でパイプライン全体を描いた。

明日は Day 7: REST API。401 と 403 の違い、言えますか。

画像生成有無

有（図解: push → build → test → staging → 本番 のパイプライン図。Delivery/Deployment の分岐点に印）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左から右へパイプライン: push → build → test → ステージング → 分岐点 → 本番。分岐点を青で強調し、上ルート「人が承認ボタン=Delivery」（人のアイコン）、下ルート「そのまま自動=Deployment」。

Day 7: REST API

postの内容

面接で聞かれるバックエンド基礎 Day 7/30 — REST API

「REST らしい API とは?」に一言で: リソースを URL で表し、操作は HTTP メソッドに任せ、サーバーが状態を持たない設計。

面接で深掘りされるポイント: ・GET と POST の違い（冪等性まで言えるか） ・PUT と PATCH の違い ・401 と 403 の違い ・ページネーションは offset と cursor どっち? なぜ? ・レートリミット超過時は何を返す?（429 + Retry-After）

図にメソッド × ステータスコードの地図をまとめた。 面接前に見返せるよう保存推奨。

画像生成有無

有（図解: HTTP メソッド一覧 × 冪等性の表 + 主要ステータスコードのマップ。保存されやすい「チートシート」寄せ）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: チートシート風の2枠構成。左枠にメソッド表: GET/POST/PUT/PATCH/DELETE×「冪等?」の○×。右枠にステータスコード地図: 「2xx 成功 / 3xx 移動 / 4xx あなたのせい / 5xx サーバーのせい」と代表コード（200,201,301,304,401,403,404,429,500,503）。

Day 8: DNS

postの内容

面接で聞かれるインフラ基礎 Day 8/30 — DNS

「URL を打ってから IP が分かるまでに何が起きる?」に一言で: ブラウザ→OS→フルリゾルバが、ルート→TLD→権威サーバーの順に聞いて回り、答えを TTL の間キャッシュする。

面接で深掘りされるポイント: ・DNS を切り替えたのに旧サーバーに飛ぶのはなぜ?（TTL） ・A レコードと CNAME の違いは? ・キャッシュはどこに何段ある? ・存在しないドメインもキャッシュされる?（ネガティブキャッシュ）

図に解決の流れをまとめた。

明日は Day 9: HTTPS。なぜ通信は盗み見られないのか。

画像生成有無

有（図解: ブラウザ→フルリゾルバ→ルート/TLD/権威 の問い合わせフロー。キャッシュ位置に印）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左にブラウザ→「フルリゾルバ」。リゾルバから右の3つのサーバー（①ルート ②TLD(.com) ③権威サーバー）へ番号付きの往復矢印、最後に「IP」を持ち帰る矢印。ブラウザ・OS・リゾルバの3箇所に星マークと「TTLの間おぼえる」の注記。

Day 9: HTTPS / TLS

postの内容

面接で聞かれるインフラ基礎 Day 9/30 — HTTPS

「なぜ HTTPS だと安全なんですか?」に一言で: 公開鍵暗号で「共通鍵」を安全に交換し、以降は高速な共通鍵で暗号化するから。

面接で深掘りされるポイント: ・証明書は何を保証している?（暗号化ではなく「相手が本物」の保証） ・なぜ全部公開鍵暗号でやらない?（遅いから） ・ハンドシェイクで何をやり取りしている? ・オレオレ証明書の警告は何を意味する?

図にハンドシェイクの流れをまとめた。

明日は Day 10: HTTP/1.1 → 2 → 3 は何が進化したのか。

画像生成有無

有（図解: TLS ハンドシェイク（証明書検証→鍵交換→共通鍵通信）のシーケンス。手描き風）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左「クライアント」右「サーバー」の縦シーケンス図。①サーバーが証明書を提示 ②クライアントがCAで検証（✓マーク）③公開鍵で共通鍵を交換（鍵アイコン）④以降は共通鍵で高速通信（南京錠付きのトンネル、青）。

Day 10: HTTP/1.1 → 2 → 3

postの内容

面接で聞かれるインフラ基礎 Day 10/30 — HTTP の進化

「HTTP/2 で何が変わった?」に一言で: 1本の TCP 接続の中に複数のリクエストを多重化して、順番待ちをなくした。

面接で深掘りされるポイント: ・1.1 の keep-alive でも何が詰まる?（先頭の応答待ち） ・2 でも残った詰まりは?（TCP レイヤーのパケットロス） ・3 が UDP(QUIC) を選んだ理由 ・自分のサイトがどれで喋ってるか確認する方法（DevTools）

図に3世代の違いをまとめた。

明日は Day 11: Cookie・セッション・JWT の使い分け。

画像生成有無

有（図解: 1.1 の直列 → 2 の多重化 → 3 の QUIC を3段で並べる図）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 3段積みの比較図。上段「HTTP/1.1」: 1本のパイプにリクエストが1列で順番待ち、先頭に赤で「詰まる」。中段「HTTP/2」: 1本のTCPパイプの中を模様違いのストリーム3本が並走。下段「HTTP/3 (QUIC/UDP)」: 同様の並走+「TCPの詰まりも解消」（青）。

postの内容

面接で聞かれるバックエンド基礎 Day 11/30 — ログイン状態の持ち方

「セッション方式と JWT の違いは?」に一言で: 状態の置き場所が違う。セッションは「鍵だけ」をクライアントに、中身はサーバーに。JWT は「中身ごと」署名してクライアントに持たせる。

面接で深掘りされるポイント: ・JWT はどうやって失効させる?（これが最頻出） ・サーバーを複数台にした時に楽なのはどっち? ・localStorage に JWT を置くリスク（XSS） ・Cookie の HttpOnly / Secure / SameSite は何を防ぐ?

図に2方式の対比をまとめた。

明日は Day 12: キャッシュ戦略。どこに置いて、いつ捨てるか。

画像生成有無

有（図解: セッション方式と JWT 方式の対比図。「状態がどこにあるか」を色で示す）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 見出し「状態はどこにある?」で左右対比。左「セッション方式」: クライアントはCookieに鍵アイコンだけ、サーバー側の箱に「状態（ログイン情報）」を青塗り。右「JWT方式」: クライアントの封筒に「中身+署名」を青塗り、サーバーには「検証だけ」。

Day 12: キャッシュ戦略

postの内容

面接で聞かれるバックエンド基礎 Day 12/30 — キャッシュ戦略

「キャッシュ設計で何を考える?」に一言で: 「どこに置くか」（ブラウザ/CDN/アプリ/DB の手前）と「いつ捨てるか」（TTL か明示パージか）の2軸。

面接で深掘りされるポイント: ・キャッシュが一斉に切れたら?（stampede。Day 1 の Redis と接続） ・cache-aside と write-through の違い ・「更新したのに古いのが見える」問題への答え方 ・キャッシュしてはいけないデータは?

図に「キャッシュの置き場所マップ」をまとめた。保存推奨。

明日は Day 13: DB レプリケーション。読み取りをスケールさせる。

画像生成有無

有（図解: ブラウザ→CDN→アプリ→Redis→DB の経路上にキャッシュ位置を4つマーク。チートシート寄せ）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 見出し「キャッシュはどこに置く?」。左から右へ一直線の経路: ブラウザ→CDN→アプリサーバー→Redis→DB。経路上の4箇所に青い貯金箱マークと一言注記: ブラウザ「本人だけ速い」/ CDN「みんなで共有」/ Redis「アプリ共通」/ DBの手前「最後の砦」。

Day 13: DB レプリケーション

postの内容

面接で聞かれるバックエンド基礎 Day 13/30 — DB レプリケーション

「レプリケーションは何のため?」に一言で: 書き込みはプライマリ1台に、読み取りはコピー（レプリカ）に散らして、読みをスケールさせるため。

面接で深掘りされるポイント: ・同期レプリケーションと非同期の違い（速度と欠損リスクのトレードオフ） ・「書き込んだ直後に読むと古い」問題にどう対処する? ・レプリカ遅延はどう監視する? ・プライマリが死んだら?（フェイルオーバー）

図に構成と遅延の起きる場所をまとめた。

明日は Day 14: メッセージキュー。「あとでやる」の安全な預け方。

画像生成有無

有（図解: プライマリ→レプリカ×2 の複製フロー。「ここに遅延」の注記付き）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 中央左に「プライマリ」のDB。左からペンのアイコン付き矢印「書き込みはここだけ」。プライマリから右の「レプリカ」DB×2へ複製の矢印、矢印の途中に赤で「ここに遅延」。左から目のアイコン付き矢印「読み取り」がレプリカへ。

Day 14: メッセージキュー

postの内容

面接で聞かれるバックエンド基礎 Day 14/30 — メッセージキュー

「なぜキューを挟むんですか?」に一言で: すぐ返事が要らない処理を「あとでやるリスト」に預けて、リクエストを速く返し、負荷の波を平らにするため。

面接で深掘りされるポイント: ・同じメッセージが2回届いたら?（at-least-once と冪等性） ・処理に失敗し続けるメッセージは?（DLQ） ・順序は保証される?（標準キューと FIFO キュー） ・キューが詰まったことにどう気づく?（滞留数の監視）

図に全体像をまとめた。

明日は Day 15: トランザクションと ACID。

画像生成有無

有（図解: API→キュー→ワーカー→DB の非同期フロー。DLQ への分岐も描く）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左から右へ: API →「キュー」（封筒が並んだベルトコンベア風の箱）→ ワーカー×2 → DB。APIの横に青注記「すぐ200を返す」。ワーカーから下向きの赤い失敗矢印が「DLQ（失敗置き場）」の箱へ。

Day 15: トランザクションと ACID

postの内容

面接で聞かれるバックエンド基礎 Day 15/30 — ACID

「トランザクションとは?」に一言で: 複数の処理を「全部成功」か「全部なかったこと」のどちらかにする仕組み。送金で片方だけ減る、を防ぐ。

面接で深掘りされるポイント: ・A/C/I/D をそれぞれ1行で言えるか ・ロールバックは何が起きている? ・トランザクションはどこからどこまでに張る?（外部 API 呼び出しを入れてはいけない理由） ・「I（分離性）」の妥協が明日のテーマ

図に送金の例でまとめた。

明日は Day 16: 分離レベル。「混ざらない」をどこまで妥協するか。

画像生成有無

有（図解: 送金トランザクションの成功パターンと途中失敗→ロールバックの2コース図）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 中央に大きな枠「トランザクション」、中に2操作「A口座 −1万円」「B口座 +1万円」。枠の出口が2ルート: 上ルート（青）「両方成功→確定(COMMIT)」、下ルート（赤）「途中で失敗→全部なかったことに(ROLLBACK)」で巻き戻し矢印が枠の入口へ戻る。

Day 16: トランザクション分離レベル

postの内容

面接で聞かれるバックエンド基礎 Day 16/30 — 分離レベル

「分離レベルとは?」に一言で: 同時に走るトランザクション同士を「どこまで混ざって見えてよいか」の4段階。厳しくするほど安全で遅い。

面接で深掘りされるポイント: ・ダーティリード / ノンリピータブルリード / ファントムリードを現象で説明できるか ・PostgreSQL / MySQL のデフォルトはどれ? ・レベルを上げると何が起きる?（性能低下・デッドロック増） ・実務でデフォルトから変えた経験は?（これが本命の質問）

図に4レベル×3現象の対応表をまとめた。保存推奨。

明日は Day 17: N+1 問題。気づかないうちに1000回クエリ。

画像生成有無

有（図解: 4分離レベル × 起きる/起きない現象のマトリクス表。チートシート寄せ）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 手描き風の表1枚。行=Read Uncommitted / Read Committed / Repeatable Read / Serializable。列=ダーティリード / ノンリピータブルリード / ファントムリード。セルに「起きる」（赤×）「起きない」（青○）。下端に注記「PostgreSQLのデフォルトはRead Committed」。表の下に「↓厳しいほど安全で遅い」の矢印。

Day 17: N+1 問題

postの内容

面接で聞かれるバックエンド基礎 Day 17/30 — N+1 問題

「N+1 問題とは?」に一言で: 一覧を1回で取ったあと、行ごとに関連データを1回ずつ取りにいって、合計 N+1 回クエリが走る事故。

面接で深掘りされるポイント: ・なぜ本番まで気づきにくい?（開発環境はデータが少ない） ・どう直す?（JOIN / IN でまとめ取り、ORM の preload） ・どう検知する?（クエリログ・APM） ・ORM を使うと起きやすいのはなぜ?

図に「20行の一覧で21回クエリ」の実例をまとめた。

明日は Day 18: コネクションプール。接続は使い回すもの。

画像生成有無

有（図解: ループ内クエリが行数ぶん飛ぶ図 vs JOIN 1発の対比。クエリ数を赤字で）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左右対比。左「N+1」: アプリからDBへ「一覧を1回」の矢印+ループ記号から細い矢印が20本束になってDBへ殺到、赤で大きく「計21回」。右「JOINでまとめ取り」: 太い矢印1本、青で大きく「計1回」。

Day 18: コネクションプール

postの内容

面接で聞かれるバックエンド基礎 Day 18/30 — コネクションプール

「なぜ接続を使い回すんですか?」に一言で: DB 接続の確立は TCP + 認証で高コストだから、作り置きして貸し出す。

面接で深掘りされるポイント: ・プールサイズはどう決める?（大きいほど良い、ではない） ・枯渇するとどんな症状が出る?（Day 8 の障害シナリオと接続） ・接続を返し忘れるとどうなる?（リーク） ・Lambda など大量インスタンスとの相性問題

図に仕組みをまとめた。

明日は Day 19: VPC。クラウドの中に自分のネットワークを作る。

画像生成有無

有（図解: アプリ複数→プール（貸出中/待機）→DB の貸し借り図）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左にアプリ×3。中央に「コネクションプール」の箱、中にケーブルのアイコン5本（「貸出中」2本は青、「待機」3本はグレー）。右にDB。アプリとプールの間に「借りる/返す」の往復矢印。下端に赤注記「毎回新規接続=TCP+認証で高コスト」。

Day 19: VPC とサブネット

postの内容

面接で聞かれるインフラ基礎 Day 19/30 — VPC

「パブリックサブネットとプライベートサブネットの違いは?」に一言で: サブネット自体は同じ。ルートテーブルの 0.0.0.0/0 が IGW を向いていればパブリック、NAT を向いていればプライベート。

面接で深掘りされるポイント: ・DB はどちらに置く? なぜ? ・プライベートから外に出たい時は?（NAT GW とそのコスト） ・セキュリティグループと NACL の違い ・マルチ AZ でサブネットをどう切る?

図に典型的な2層 VPC をまとめた。

明日は Day 20: IAM。権限設計の基本。

画像生成有無

有（図解: VPC 内の public/private サブネット×2AZ、IGW/NAT/ALB/DB の配置図）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 大きな「VPC」枠の中にAZ-a/AZ-cの2列。各AZに上下2段: 上「publicサブネット」（ALB）、下「privateサブネット」（アプリとDB）。VPC枠の上端に「IGW（インターネットへの門）」、publicサブネット内に「NAT GW」。吹き出しで「0.0.0.0/0→IGWならpublic / →NATならprivate」（青）。

Day 20: IAM と AssumeRole

postの内容

面接で聞かれるインフラ基礎 Day 20/30 — IAM

「IAM 設計で一番大事なことは?」に一言で: 最小権限。「誰が・何に・何をできるか」を必要な分だけ与え、長期キーではなく一時権限（AssumeRole）で渡す。

面接で深掘りされるポイント: ・ユーザーにキーを配る方式の何が危険? ・AssumeRole の一時クレデンシャルはなぜ安全? ・ポリシーの Allow と Deny、勝つのはどっち? ・CI/CD にはどう権限を渡す?

図に AssumeRole の流れをまとめた。

明日は Day 21: フェデレーション。社員1000人分の IAM ユーザーを作らない方法。

画像生成有無

有（図解: 利用者→STS→一時クレデンシャル→リソースの流れ。長期キー方式に×印の対比）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 上段（青ルート）: 「利用者/CI」→「STS: AssumeRole」→時計アイコン付きの鍵「一時クレデンシャル（数時間で失効）」→S3・DBのアイコンへ。下段（対比）: 「長期アクセスキーを配って永続利用」の構図に赤の大きな×。

B. 面接演習型（質問を投稿 → リプ欄で自分が本番のつもりで回答）

フェーズ運用（重要）: 質問形式は2026年9月から。8月末までは解説型だけで回す

  • 解説期（〜2026年8月末）: B の質問ドラフトはこの期間は投稿しない。代わりに同じネタを「◯◯とは?+図解1枚」の解説型（A の単発版）に変換して出してよい（例: B-9 CDN → 「CDNとは?」図解解説）。同じネタは9月に質問形式でもう一度使える（1ネタ2露出）
  • 質問形式期（2026年9月〜）: 最初は「面接演習ログ」として出す。締めの文は 「明日リプ欄で回答します。皆さんならどう答えますか?」ではなく 「面接本番のつもりで1分で答える練習。私の回答はリプ欄に。」 に差し替え、投稿の1〜2時間後に自分でリプ回答を付ける（誰も待っていないので翌日まで引っ張らない）。 読者への CTA は「あなたも声に出して1分」= 練習の促しにする（リプ乞いにしない）
  • リプが数件つくのが普通になったら: Sarthak 方式に切替。「明日リプ欄で回答します」で引きを作り、半日〜1日後に回答。他人のリプが付いてから自リプ
  • 以下のドラフトの締め文は最終形（引き型）で書いてあるので、投稿時にフェーズに合わせて差し替えること
  • E の二択型も同様: 初期は X のアンケート機能を使う（リプより投票のほうが圧倒的にハードルが低く、0件が目立たない）

B-1: ALB vs ELB

postの内容

面接で実際に聞かれた質問:

「ALB と ELB の違いを説明してください」

明日リプ欄で、面接本番のつもりで回答します。 皆さんならどう答えますか?

画像生成有無

無

リプ回答ドラフト（面接演習・一人称）

【回答】 ELB は AWS のロードバランサーの総称で、その中に CLB(旧世代)・ALB・NLB があります。 比較で聞かれているのは実質 ALB と CLB の違いだと理解して答えると: ALB は L7 で動き、HTTP の中身（パスやホスト名）を見てターゲットグループに振り分けられます。 CLB は L4/L7 混在の旧世代で、パスベースルーティングや HTTP/2 対応がなく、今あえて選ぶ理由はほぼありません。 実務では「HTTP なら ALB、固定 IP や超低レイテンシの TCP なら NLB」で選んでいます。

B-2: HTTP はステートレスなのになぜログイン情報が残るのか

postの内容

面接で実際に聞かれた質問:

「HTTP はステートレスですよね。 では、なぜログインした状態が維持されるんですか?」

明日リプ欄で、面接本番のつもりで回答します。 皆さんならどう答えますか?

画像生成有無

無（回答リプ側に Cookie/セッションのやり取り図を付けるのは有り）

リプ回答ドラフト（面接演習・一人称）

【回答】 ステートレスなのはプロトコルであって、アプリが状態を持てないわけではありません。 ログイン成功時にサーバーがセッション ID を発行して Cookie で渡し、 以降のリクエストではクライアントが毎回その Cookie を自分で持参します。 つまり「サーバーが覚えている」のではなく「クライアントが毎回名乗っている」構造です。 セッション ID の代わりに署名付きトークン(JWT)を持たせれば、 サーバー側にセッションストアを持たない構成もできます。使い分けは〜（面接官の反応を見て展開）

B-3: Go の main 関数は誰が呼ぶのか

postの内容

Go の面接で実際にある質問:

「main 関数って、誰がどこから呼んでいるんですか?」

「エントリポイントだから最初に動く」で止まらずに説明できますか?

明日リプ欄で、面接本番のつもりで回答します。

画像生成有無

無（回答リプ側に OS → ランタイム → main.main の流れ図を付けるのは有り）

リプ回答ドラフト（面接演習・一人称）

【回答】 OS が実行ファイルのエントリポイントを叩きますが、そこにあるのは main 関数ではなく Go のランタイムです。 ランタイムがスケジューラや GC を初期化し、import されたパッケージの init 関数群を実行し終えたあとで、 runtime.main が私たちの書いた main.main を呼び出します。 だから「main より先に init が動く」「goroutine が main 開始時点で既に動ける」わけです。

B-4: println の「ln」とは

postの内容

新人に聞かれて詰まりがちな質問:

「Println の『ln』って何の略ですか?」

ついでに、Go の組み込み println と fmt.Println の違いも言えますか?

明日リプ欄で回答します。

画像生成有無

無

リプ回答ドラフト（面接演習・一人称）

【回答】 ln は line の略で、「出力の最後に改行を付ける print」という意味です（print line）。 Go には組み込みの println と fmt.Println の2つがあり、 組み込み println は stderr に出力され、言語仕様上「将来も残る保証がない」デバッグ用です。 アプリのコードで使うのは fmt.Println（stdout・フォーマット制御あり）。使い分けを聞かれたらここまで答えます。

B-5: フェデレーションとは

postの内容

AWS の面接で実際にある質問:

「ID フェデレーションとは何か、説明してください」

SSO と何が違うのか、まで言えると強いです。

明日リプ欄で、面接本番のつもりで回答します。

画像生成有無

有（回答リプに付ける想定: IdP → 認証 → AWS STS → 一時クレデンシャル の流れ図。手描き風）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左から右へ: 「社員」→「IdP（社内の認証基盤）」でログイン✓ → 橋のイラストに「信頼関係(SAML/OIDC)」→「AWS STS」→時計アイコン付きの鍵「一時クレデンシャル」→AWSリソース。下端に青注記「IAMユーザーは作らない」。

リプ回答ドラフト（面接演習・一人称）

【回答】 フェデレーションは「外部の ID 基盤（IdP）の認証結果を信頼して、自分のシステムへのアクセスを許す仕組み」です。 AWS なら、Google Workspace や Entra ID で認証したユーザーに、IAM ユーザーを作らずに STS 経由で一時クレデンシャルを渡してアクセスさせる、という形になります（SAML / OIDC）。 SSO は「1回のログインで複数サービスに入れる」という体験の話で、 フェデレーションはそれを実現する信頼関係の仕組み、と整理しています。

B-6: AssumeRole

postの内容

AWS の面接定番:

「AssumeRole は何をしているのか説明してください」

「ロールを引き受ける」の一歩先、 なぜアクセスキーを配るよりも安全なのかまで言えますか?

明日リプ欄で回答します。

画像生成有無

有（回答リプに付ける想定: 利用者 → STS AssumeRole → 一時クレデンシャル → 対象アカウントのリソース、の図）

※ プロンプトは A 連載 Day 20 と同一。Day 20 で生成した画像を流用する。

リプ回答ドラフト（面接演習・一人称）

【回答】 AssumeRole は STS の API で、「ロールを一時的に引き受けて、期限付きの認証情報をもらう」操作です。 返ってくるのはアクセスキー・シークレット・セッショントークンの3点セットで、数時間で失効します。 長期のアクセスキーを配る方式と違って、漏れても期限で死ぬ・権限をロール側で絞れる・ 信頼ポリシーで「誰が引き受けられるか」を制御できるのが利点です。 クロスアカウントアクセスや CI からのデプロイは基本これで組みます。

B-7: S3 バケットを安全に保つには

postの内容

AWS の面接で実際にある質問:

「S3 バケットに機密データを置きます。 安全に保つために何を設定しますか?」

思いつく順ではなく、優先順位を付けて答えられますか?

明日リプ欄で、面接本番のつもりで回答します。

画像生成有無

有（回答リプに付ける想定: バケットを囲む防御レイヤー図 — 公開ブロック / ポリシー / 暗号化 / バージョニング / ログ）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 中央にバケツのアイコン「S3バケット」。それを囲む同心円5層、外側から順に番号付きで: ①公開ブロック（赤の盾）②最小権限ポリシー ③KMS暗号化（鍵）④バージョニング（巻き戻し矢印）⑤監査ログ（虫めがね）。見出し「守る順番」。

リプ回答ドラフト（面接演習・一人称）

【回答】 まず事故の最大要因である公開設定から潰します。 ① ブロックパブリックアクセスを有効化（アカウント単位で） ② バケットポリシーと IAM で最小権限に絞る ③ 暗号化（SSE-KMS。キーの権限も分離できる） ④ バージョニング + オブジェクトロックで改ざん・誤削除対策 ⑤ アクセスログ / CloudTrail データイベントで監査 の順で答えます。「まず公開事故を防ぐ、次に権限、その後で暗号化と監査」という優先順位ごと伝えるのがポイントです。

B-8: S3 への PUT はなぜ安全にできるのか（presigned URL）

postの内容

面接で実際にあった質問:

「クライアントアプリから S3 に直接ファイルをアップロードさせたい。 認証情報をアプリに埋め込まずに、どう安全に PUT させますか?」

これ、答えは1つに絞れます。

明日リプ欄で、面接本番のつもりで回答します。

画像生成有無

有（回答リプに付ける想定: クライアント → API サーバー（URL 発行）→ S3 直 PUT の3者シーケンス図。手描き風）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 3者（クライアント / APIサーバー / S3）のシーケンス図。①クライアント→APIサーバー「アップロードしたい」②APIサーバー→クライアント「このURLにPUTだけ・10分だけOK」（署名付きURL、時計アイコン）③クライアント→S3へ直接PUTの太い青矢印。注記2つ「認証情報は渡さない」「ファイルはサーバーを通らない」。

リプ回答ドラフト（面接演習・一人称）

【回答】 presigned URL を使います。 サーバー側が自分の IAM 権限で「このバケットのこのキーに、PUT だけ、○分間だけ」という署名を URL に埋め込んで発行し、 クライアントはその URL に PUT するだけ。認証情報は一切渡りません。 安全な理由は、署名が サーバーの権限・操作・対象キー・期限 に紐づいていて、 改ざんすれば署名検証で弾かれ、期限が切れれば無効になるからです。 ファイルがサーバーを経由しないので、アップロード帯域をサーバーが負担しない利点もあります。

B-9: CDN とは

postの内容

面接で聞かれるインフラ基礎:

「CDN とは何か、なぜ使うのか説明してください」

「キャッシュして速くする」で止まらずに、 オリジン保護・キャッシュヒットしなかった時の動きまで言えますか?

明日リプ欄で、面接本番のつもりで回答します。

画像生成有無

有（回答リプに付ける想定: ユーザー → 最寄りエッジ → (miss 時のみ) オリジン、の流れ図。手描き風）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 簡略化した世界地図風の背景。左に「ユーザー（東京）」→すぐ隣の「エッジサーバー（東京）」へ短い青矢印「ヒット: ここから返す（速い）」。エッジから遠く右の「オリジン（アメリカ）」へ長い点線矢印「ミスの時だけ取りに行き、TTLの間おぼえる」。

リプ回答ドラフト（面接演習・一人称）

【回答】 CDN は、世界中に置かれたエッジサーバーにコンテンツをキャッシュし、 ユーザーに一番近い場所から配信する仕組みです。目的は2つで、 ① 物理的な距離を縮めてレイテンシを下げる ② オリジンへのリクエストを減らして守る、です。 エッジにキャッシュがなければ（miss）オリジンまで取りに行き、TTL の間エッジに保持します。 深掘りで来るのは「更新したのに古いのが見える」→ パージ / キャッシュキー設計 / Cache-Control の話。動的 API に CDN を挟む場合の考え方まで話せると強いです。

B-10: ルートテーブル

postの内容

AWS の面接で実際にある質問:

「パブリックサブネットとプライベートサブネットの違いは何ですか?」

答えの核心はルートテーブルです。 「0.0.0.0/0 の向き先」で説明できますか?

明日リプ欄で回答します。

画像生成有無

有（回答リプに付ける想定: VPC 内の2つのサブネットとルートテーブル、IGW / NAT GW への矢印の図）

※ プロンプトは A 連載 Day 19 と同一。Day 19 で生成した画像を流用する。

リプ回答ドラフト（面接演習・一人称）

【回答】 ルートテーブルは「宛先 CIDR → 次に送る先(ターゲット)」の表で、サブネットごとに紐づきます。 0.0.0.0/0（デフォルトルート）がインターネットゲートウェイに向いていればパブリックサブネット、 NAT ゲートウェイに向いていれば「外には出られるが入られない」プライベートサブネットです。 つまり両者の違いはサブネット自体の属性ではなく、ルートテーブルの1行の差です。 経路が複数マッチする場合はロンゲストマッチ（最も具体的な CIDR が勝つ）で決まります。

B-11: セッションとは

postの内容

面接で新人によく聞く質問:

「セッションとは何ですか? Cookie と何が違いますか?」

混同したまま使っている人が多いこの2つ、 一言で区別できますか?

明日リプ欄で、面接本番のつもりで回答します。

画像生成有無

無（B-2「HTTP ステートレス」の回答図と共通化できる）

リプ回答ドラフト（面接演習・一人称）

【回答】 セッションは「ステートレスな HTTP の上で、一連のやり取りを同一ユーザーのものとして扱うための状態」で、 実体はサーバー側に保存されたデータ（ログイン情報など）です。 Cookie はそのセッションを引くための「鍵（セッション ID）を運ぶ入れ物」で、状態そのものではありません。 つまり、状態はサーバーのセッションストアに、鍵はクライアントの Cookie に、という分担です。 深掘りで来るのは「サーバーを複数台にしたらセッションはどうする?」→ Redis 等の外部ストア か JWT で クライアント側に持たせる、という展開です。

B-12: localStorage と IndexedDB

postの内容

フロントエンドの面接で実際にある質問:

「localStorage と IndexedDB、どう使い分けますか?」

ついでに「アクセストークンを localStorage に置くのはなぜ危険?」 まで答えられると一段上です。

明日リプ欄で回答します。

画像生成有無

有（回答リプに付ける想定: 同期/非同期・型・容量・向き不向きの比較表1枚。チートシート寄せで保存狙い）

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 手描き風の比較表。列=localStorage / IndexedDB。行=読み書き（同期・メインスレッドを止める / 非同期）、入れられる物（文字列のみ / オブジェクトもバイナリも）、容量（〜5MB / 大容量）、向いている用途（小さな設定値 / オフラインデータ・大きなデータ）。下端に赤注記「トークンをlocalStorageに置くとXSSで丸見え」。

リプ回答ドラフト（面接演習・一人称）

【回答】 localStorage は同期 API の文字列専用 key-value で、容量は 5MB 程度。 設定値のような小さなデータ向きですが、同期なのでメインスレッドをブロックします。 IndexedDB は非同期でオブジェクトやバイナリをそのまま保存でき、大容量・インデックス・トランザクションを 持つ「ブラウザ内 DB」。オフラインキャッシュや大きなデータはこちらです。 トークンを localStorage に置くのが危険なのは、XSS が成立すると JS から丸ごと読めるからで、 HttpOnly Cookie なら JS から触れない、という対比まで話します。

F枠: 記事紹介型のサンプル（「一言の学び+リンクはリプ」形式）

ルール: 全文翻訳は著作権 NG。自分の言葉での要約+考察のみ。URL と出典は1リプ目。 サンプル（Itamar Gilad「How to Measure Dev Productivity in the Age of AI」より）:

postの内容

AI がコードを量産する時代、 コミット数・行数・PR 数はもう生産性じゃない、 という記事が刺さった。

曰く、A/B テストの成功率は33%以下。 「作った量」の大半は価値になっていない。 だから測るのは成果（outcome）だけでいい。

面接で「成果を数字で」と聞かれるのは、まさにこの文脈。

要点を図にした。記事リンクはリプに。

1リプ目

元記事: How to Measure Dev Productivity in the Age of AI（Itamar Gilad） https://itamargilad.com/how-dev-productivity/ 図は記事の主張を自分なりに整理したものです。

画像生成有無

有

横長16:9の技術図解イラストを生成してください。Excalidrawのような手描き風スタイル。白背景、黒のややラフな太線、アクセントカラーは青1色（強調したい箇所のみ赤）。影・グラデーション・写実表現なし、フラットで余白広め。ラベルはすべて日本語、文字は最小限で大きく、スマホの縮小表示でも読めること。ロゴ・実在ブランドの意匠は使わない。
内容: 左右対比。左「活動を測る」（赤の斜線で打ち消し）: コミット数・コード行数・PR数・トークン消費量のメーターが並ぶ、注記「量は価値じゃない」。右「成果を測る」（青）: ユーザーの笑顔とグラフ上昇のアイコン、「ビジネス価値・ユーザー価値」。中央下に矢印と一言「作った量→動いた成果へ」。

週への配置

ペース: 平日2本・土日3本 = 週16本（詳細な曜日割は 200post計画.md を参照）

  • 1本目=朝（A 連載・図解あり）、2本目=夜（B/E/G/I など会話型）、土日3本目=昼（C/D/F）
  • B 演習型は質問投稿 → 翌日リプ回答のリズム（リプは本数外）
  • 保存型リスト・深掘りツリー・行動面接ネタは 初期投稿セット案.md の3本を併用
  • 計測は /marketing-weekly。連載は Day 7 時点で表示数の傾向を見て継続判断

旧ドラフト（行動面接・会話型）※保持

旧主案【シナリオ + 開いた質問型】

postの内容

面接でよくある詰み方:

「チームの開発効率を改善しました」 面接官「数字でどれくらい変わりました?」 「……体感ですが、かなり」

ここで沈黙が生まれて、終わる。

数字を取っていなかった過去はもう変えられない。 でもこの場面、まだ返しようがある。

あなたなら、まずどう返しますか?

画像生成有無

無

旧予備案【二択 + なぜ?型】

postの内容

面接で「失敗経験を教えてください」と聞かれたら、どっちを話しますか?

A: 技術選定をミスして、後から作り直しになった話 B: 見積もりが甘くて、リリース直前に炎上した話

どちらを選ぶかより「なぜそっちを選んだか」に、面接の通過率の差が出ます。

理由も添えて教えてください。

画像生成有無

無