コンテンツにスキップ

speech-coach X アカウント 200 post 計画（2026-07-19）

x_post.md のドラフト24本を起点に、200投稿分を型×テーマで設計する。 パクり元の実績（subagent 調査）: 連載+図解=表示、演習質問=返信、リスト=RT/保存、の3シグナルを混ぜて回す。

全体配分（200本）

記号 型 本数 画像 狙うシグナル パクり元
A ナンバリング連載+図解1枚 60（30×2シーズン。シーズン候補は7つ、実績で選ぶ。うち設計系は「設計100本ノック」として連結運用可） 有 表示・フォロー @SidJain_80
B 面接演習（質問→翌日リプで一人称回答） 60 質問は無/回答リプに図 返信 @Sarthak4Alpha
C MUST know リスト（CTA なし） 20 半分 有（チートシート画像） RT・保存 Sarthak RT51 投稿
D 深掘りツリー図解（行動面接・看板） 20 有 保存・独自性 うち（/fukabori-tree）
E 行動面接シナリオ・二択 20 無 返信 @devXritesh 二択型
F 実況・エンゲージ質問・アンケート 20 無 リプ・共感 Sarthak 問いかけ型

※ B の「翌日リプ回答」は投稿数にカウントしない（+60本ぶんの露出がおまけで付く）

ペース: 平日2本・土日3本 = 週16本 → 200本を約13週（3ヶ月）で消化

曜日 1本目 2本目 3本目
月 A（連載） B質問 —
火 A G比較表 —
水 A B質問 —
木 A I 障害推理 —
金 A E 二択・シナリオ —
土 A C リスト F 実況・エンゲージ
日 A D 深掘りツリー F（build in public）

週の内訳: A×7 / B×2 / C×1 / D×1 / E×1 / F×2 / G×1 / I×1 = 16本（B の翌日リプ回答は本数外で+2露出）

  • 時間帯の目安: 1本目=朝（通勤帯）、2本目=夜（21時前後）、土日の3本目=昼。同時連投はしない
  • フェーズ切替（時期で固定）:
  • 解説期（開始〜2026年8月末）: 「◯◯とは?+図解1枚」の解説型だけで回す。使う型は A 連載・C リスト・D ツリー・G 比較表・J 数字・F。B/E/I の質問形式は出さない（フォロワーが少ないうちはリプ0が並んで逆効果）。B のネタは「〜とは?」の解説型に変換して先に消費してよい（同じネタは9月に質問形式で2度目の出番が作れる）
  • 質問形式期(2026年9月〜): B/E/I を解禁。最初は①質問+1〜2時間後に自分でリプ回答の「演習ログ」形式（単独完結）、②二択はアンケート機能、③「皆さんは?」は「あなたも1分で答えてみて」に置換。リプが自然に付き始めたら「明日回答します」の引き型に切替
  • 返信シグナルは解説期の間ずっとリプ営業（/reply-draft）側で稼ぐ
  • 解説期の曜日割: 平日 = 朝 A + 夜 G/C/J のローテ、土日 = A + C or D + F。9月以降は元の割（B/E/I 入り）に移行
  • リプ営業（/reply-draft・毎日15分）は別枠で継続
  • 週16本は制作負荷が高い。日曜に翌週分をバッチ作成（本文は在庫から転記、図解はテンプレ複製で1枚15分以内）。バッチが3hを超える週は 火/木 の2本目を削って週14→12に落とす。連載は「Day N」なので空いても破綻しない
  • 最大リスクは開発時間を食うこと。speech-coach の実装が止まった週はマーケを週8本（A×5+B×2+C×1）に半減してよい

マイルストーン・計測（/marketing-weekly で追う）

時点 本数目安 判断
2週目（〜32本） 初期セット3本 + A Day1-14 + B/C/D/E/F/G/I 一巡 表示/フォロワー比を SidJain 基準（2〜3倍）と比較。型別の初速も見える
4週目（A シーズン1完走・〜64本） A Day30 まで到達 型別の伸び比較 → 配分再調整。伸びない型は捨てる。シーズン2を実績で選ぶ
8週目（〜128本） シーズン2 折り返し フォロワー数で仮説3（Issue #12）を判定
13週目（200本・約3ヶ月） 完走 ローンチ時期と接続（プロフィール→LP 導線の整備はこれより前に）。在庫450あるので継続も可

テーマバンク

シーズン順（2026-07-19 決定）: シーズン1 = A-6（AI/LLM 基礎）でスタート。 理由: 投稿0 の宣言「AI 時代に人間に残るのは設計を語ること」と直結する / AI×面接が調査で最も会話が生まれた交差点 / speech-coach 開発の一次情報で差別化できる / 関心が伸びている領域で初速がつきやすい。 インフラ/バックエンド基礎（A-1、Day 1〜20 本文・画像プロンプト作成済み）はシーズン2 に回す。以降は実績で選ぶ。 注意: AI 解説は競合が多いため、毎回「面接でどう聞かれるか」の切り口を必ず入れる（うちの独自性）。

A-1: 連載シーズン候補①「面接で聞かれるインフラ/バックエンド基礎 Day N/30」（シーズン2 予定）

Day 1〜20 は x_post.md に本文+画像プロンプトまでドラフト済み。

  1. ロードバランサー（ALB/NLB） ✔︎
  2. Redis ✔︎
  3. SQL インデックス ✔︎
  4. コンテナ ✔︎
  5. Kubernetes ✔︎
  6. CI/CD ✔︎
  7. REST API ✔︎
  8. DNS（名前解決の流れ）
  9. HTTPS/TLS（ハンドシェイク）
  10. HTTP/1.1 → 2 → 3 の進化
  11. Cookie / セッション / JWT
  12. キャッシュ戦略（TTL・stampede・配置場所）
  13. DB レプリケーション（同期/非同期・遅延）
  14. メッセージキュー（SQS・非同期化の理由）
  15. トランザクションと ACID
  16. 分離レベル（ダーティリード〜ファントム）
  17. N+1 問題
  18. コネクションプール
  19. VPC とルートテーブル
  20. IAM / AssumeRole
  21. フェデレーション / STS
  22. S3 セキュリティと presigned URL
  23. サーバーレス（Lambda・コールドスタート）
  24. モニタリング（メトリクス/ログ/トレース）
  25. スケーリング（垂直/水平・ステートレス化）
  26. シャーディング
  27. CAP 定理
  28. 冪等性（リトライ設計）
  29. レートリミット
  30. 総集編（Day1-29 の1枚マップ・保存推奨・固定ポスト差し替え）

A-2: 連載シーズン候補②「面接で出るシステム設計 Day N/30」（Day30 時点の実績で取捨）

URL 短縮 / チャット / タイムラインフィード / レコメンド（億件の動画から数百msで「おすすめ」を返す2段ファネル。YouTube お題の4点目） / Google Maps（地図表示・近傍検索・経路探索の3機能に分解） / 通知システム / 画像アップロード(presigned+CDN) / 決済の冪等性 / 在庫の排他制御 / ジョブキューとリトライ / サーキットブレーカー / ブルーグリーン・カナリア / feature flag / 分散ロック / イベント駆動 / 無停止 DB マイグレーション / ページネーション設計 / 全文検索 / XSS・CSRF / SQL インジェクション / パスワードの保存 / OAuth 2.0 / WebSocket と SSE / gRPC / GraphQL vs REST / セキュリティヘッダ / タイムゾーン設計 / Direct Connect と閉域接続（VPN との使い分け） / 障害対応プロセス / SLI・SLO / 負荷試験 / 技術選定の語り方 / 総集編

※ レコメンド回の骨子（B 演習「億本からおすすめをどう数百msで出す?」としても使える）: - 全件は見ないが答えの核。億件を毎回スコアリングするのは不可能で、「候補生成→ランキング」の2段ファネルで絞る - ① 候補生成: ユーザーと動画を同じベクトル空間に埋め込み（two-tower モデル）、近似最近傍検索（ANN インデックス）で億→数百件に絞る。登録チャンネル・急上昇・協調フィルタリングなど複数ソースの候補を合流させる - ② ランキング: 残った数百件だけに重いモデルで精密なスコアリング（視聴確率など）→ 多様性の調整をして返す - ③ 耐えている仕組みの本体はオフライン: embedding や ANN インデックスは事前計算してメモリに載せておき、リクエスト時は「引くだけ」。リアルタイムに計算しているのは最後の数百件だけ - 面接での一言: 「億件に耐える設計とは、億件を触らない設計」

※ Google Maps 回の骨子（機能ごとに設計原則が違うのが面接映えポイント）: - 地図表示: 世界地図を毎回描画しない。ズームレベル×座標でタイル画像に事前分割して CDN 配信（ここでも「事前計算に逃がす」） - 近傍検索（「近くのカフェ」）: 緯度経度への単純なインデックスでは範囲検索が効かない → ジオハッシュ / クアッドツリーで2次元を1次元のキーに畳み、「同じ・隣のセル」だけ探す - 経路探索: 道路網は巨大グラフ。素の Dijkstra では大陸横断に耐えない → 幹線道路で階層化し、主要区間の最短路を事前計算して組み合わせる。渋滞は辺の重みをリアルタイム更新 - ETA（到着予測）: 現在の渋滞 + 過去の時間帯別履歴の合成 - 面接での一言: 「Maps は1つのシステムではなく、性質の違う3つの検索(タイル・近傍・経路)の集合」 - A-5 API 設計 Day20（地図・位置情報 API）・A-4 DB Day9（Uber の位置情報）と連動 → 位置情報も3点セットお題にできる

A-3: 連載シーズン候補③「Go言語 100Tips から面接に出る30選 Day N/30」

『Go言語 100Tips（100 Go Mistakes）』から、面接・コードレビューで問われやすいものを30本選抜。 形式は A と B のハイブリッド: コード片の画像1枚 +「このコード、期待通り動きますか?」→ 翌日リプで解説（= Go 学習の言語化とクイズ型の相性が最も良い枠。シーズン2はこれを優先候補にする）

コーディング・設計 1. 変数シャドーイングによるバグ 2. init 関数を乱用しない 3. interface は使う側で定義する（interface 汚染） 4. 「interface を受け取り、具象型を返す」 5. any の乱用 6. 埋め込み（embedding）の落とし穴 7. functional options パターン

データ構造 8. slice の len と cap の混同 9. nil スライスと空スライスの違い 10. append の共有バッファ副作用 11. スライスの capacity 起因のメモリリーク 12. map は縮まない（メモリリーク） 13. map の反復順序に依存しない 14. range は要素のコピーを回す 15. ループ変数と goroutine（Go 1.22 での挙動変更込み）

文字列 16. len(str) はバイト数（rune との違い） 17. 文字列連結は strings.Builder 18. []byte ↔ string 変換のコスト

関数・エラー処理 19. defer をループ内で使わない 20. defer の引数は即時評価される 21. panic は例外機構ではない 22. %w でラップし errors.Is / errors.As で判定 23. エラーは一度だけ処理する（ログして return しない） 24. typed nil の罠（nil でない nil エラー）

並行処理 25. 「並行にすれば速い」ではない 26. 停止計画のない goroutine を起動しない（リーク） 27. channel を close するのは送信側 28. mutex と channel の使い分け 29. context によるキャンセル伝播 30. -race を常に回す / sync.WaitGroup.Add は起動前に

※ 選抜・言い回しは投稿前に書籍の該当 Tips を確認して調整する（番号は書かず内容で言及。書籍名のクレジットは入れる=引用元明示でリプも湧きやすい）

設計100本ノック = A-4 DB 設計40 + A-5 API 設計30 + A-7 クラウド構成設計30。 「設計100本ノック Day N/100」として通しナンバーで走らせてもよい（連載の看板が強くなり、完走自体が実績投稿になる）。

A-4: 連載シーズン候補④「みんなが知ってるあのサービスの DB 設計 Day N/40」

形式: お題サービスの最小 ER 図1枚（Excalidraw 手描き風）+ 設計の急所3つ +「あなたならテーブルどう切る?」で締め（図解の A × 問いかけの B のハイブリッド。題材が身近なので非エンジニア転職層にも届く枠）

Day お題 面接で問われる急所
1 X（Twitter） フォロー関係（自己参照多対多）/ タイムラインは read 時に組むか write 時に配るか（ファンアウト）
2 Instagram いいねの億単位スケール / フィードとストーリーズの有効期限 / メディアは DB に置かない
3 EC サイト 注文時の価格スナップショット（商品テーブル参照だけでは事故る）/ 在庫の排他制御 / カートの寿命
4 GitHub リポジトリ・PR・レビューの関係 / Org・チーム・権限の多層構造 / フォーク元の参照
5 YouTube 動画とメタデータの分離 / 視聴履歴の書き込み量 / コメントのツリー構造
6 Slack ワークスペース×チャンネル×スレッド / 未読管理（メンバー×チャンネルの読了位置）
7 メルカリ 商品の状態遷移（出品→取引中→完了）/ 取引と評価の分離 / 論理削除
8 Airbnb 予約の空き管理（期間の重複判定）/ ダブルブッキング防止 / 料金の日別変動
9 Uber 位置情報の頻繁な更新 / 配車マッチングの状態遷移 / 履歴とリアルタイムの分離
10 食べログ 店舗×レビュー×評価集計（都度 AVG するか非正規化するか）/ ランキングの更新頻度
11 銀行 残高は持たず台帳（仕訳）から導出 / 二重記帳 / UPDATE しない設計（イベントソーシングの入口）
12 美容室予約 スタッフ×メニュー×時間枠 / 所要時間が異なる予約の空き計算 / キャンセル待ち
13 カレンダー 繰り返し予定を全件展開せずに持つ方法（RRULE）/ 例外日 / タイムゾーン
14 マッチングアプリ スワイプの書き込み量 / 相互いいねの検出 / ブロックの非対称関係
15 Netflix プロフィール分離（1契約N人）/ 視聴進捗の保存粒度 / レコメンド用の視聴イベント
16 Spotify プレイリスト（並び順の持ち方）/ コラボ編集の競合 / 再生履歴の書き込み量
17 LINE 既読管理（誰がどこまで読んだか）/ メッセージの送信取消 / グループの招待と退出履歴
18 Uber Eats 注文×店×配達員の3者の状態遷移 / 品切れ時の部分キャンセル / メニューの時間帯変動
19 求人サイト 求人×応募×選考ステータス遷移 / 応募後に求人が編集された場合のスナップショット
20 航空券予約 座席の同時確保（仮押さえと期限）/ 運賃クラス / オーバーブッキングの設計判断
21 映画館チケット 座席ロックの実装（DB ロック? TTL 付き仮予約?）/ 同時購入の競合 / 回・スクリーン・座席の階層
22 ソシャゲのガチャ 排出率テーブルと監査ログ / 天井カウンタ / インベントリの上限
23 オークション 入札の競合（最高額更新の原子性）/ 自動入札 / 終了間際の延長ルール
24 サブスク課金 プラン変更の日割り / 請求サイクルと失敗リトライ / 解約予約（期末まで有効）
25 Notion ブロックの木構造（親子と並び順）/ ページ共有の権限継承 / 履歴・復元
26 Dropbox フォルダ階層の持ち方（閉包テーブル? パス?）/ 共有リンクの権限 / ファイルのバージョン管理
27 勤怠管理 打刻の訂正を UPDATE せず履歴で持つ / 日跨ぎ勤務 / 承認フロー
28 ポイント・クーポン 有効期限つき残高（先入れ先出し消費）/ 付与と利用の台帳 / 併用ルール
29 アンケートフォーム 動的スキーマ（質問が可変）を RDB でどう持つか / EAV の是非 / 回答の途中保存
30 通知システム 通知の集約（「3人がいいねしました」）/ 既読・アーカイブ / チャネル別配信設定
31 図書館 貸出と予約の競合 / 延滞の扱い / 同一書籍の複本管理
32 家計簿 カテゴリの階層構造 / 定期取引の展開 / 月跨ぎの集計
33 投票システム 匿名性と重複防止の両立（投票済みフラグと票を紐付けない）/ 集計の整合性
34 Wiki 版管理（全文スナップショット? 差分?）/ 同時編集の競合 / ページ間リンクの整合
35 学習アプリ レッスン×進捗 / ストリーク（連続記録）の計算 / 途中でカリキュラムが改訂されたら
36 在庫・倉庫管理 ロット管理と先入れ先出し / 引当と実在庫の分離 / 棚卸しの差異処理
37 ホテル予約 部屋「タイプ」在庫と個室割当の分離 / 連泊の空き判定 / 料金プランの多対多
38 ブログ CMS 下書きと公開版の共存（同一記事の2状態）/ 予約公開 / タグの多対多
39 電子カルテ 追記のみ（訂正も履歴で積む）/ 厳格なアクセス制御ログ / 患者マージ
40 AI チャットの会話ログ スレッド×メッセージ×ロール / トークン数・コストの記録 / フィードバック（👍👎）の紐付け（speech-coach の一次情報で語れる）

A-5: 連載シーズン候補⑤「あのサービスの API 設計 Day N/30」

形式: 主要エンドポイント一覧 or シーケンス図1枚 + 設計の急所3つ +「あなたならどう設計する?」で締め（A-4 の API 版。DB 設計と同じお題を使う回は1テーマ2露出になる）

Day お題 面接で問われる急所
1 X（Twitter） タイムラインは cursor ページネーション一択（offset だと投稿でズレる）/ いいねの冪等性（2回叩いても1いいね）/ レートリミットの返し方
2 Google Drive 大容量ファイルの再開可能アップロード（チャンク分割）/ フォルダ階層と権限の API 表現 / 差分同期（changes API 方式）
3 Notion ネストしたブロックの取得（depth をどこまで返す?）/ 部分更新の PATCH 設計 / 並び順の変更 API
4 決済（Stripe 風） 冪等キー（Idempotency-Key ヘッダ）/ 金額は整数（浮動小数点を使わない）/ Webhook の署名検証
5 GitHub REST と GraphQL の併存理由 / 条件付きリクエスト（ETag と 304）/ レートリミットヘッダの設計
6 Slack イベント API と Webhook / 3秒以内に 200 を返してから非同期処理 / リトライへの冪等対応
7 EC の注文 API 注文作成の冪等性（二重注文防止）/ 在庫確保のタイミング / 202 Accepted と非同期処理
8 検索 API 検索条件が複雑で GET の URL 長を超える問題 / ファセット（絞り込み件数）の返し方 / limit/offset か cursor か
9 画像アップロード presigned URL で S3 直 PUT / アップロード完了をどう知るか（ポーリング vs Webhook）/ サムネイル生成の非同期化
10 ログイン・認証 トークンの発行と有効期限 / リフレッシュトークンのローテーション / ログアウト=トークン失効の実装
11 OAuth プロバイダ 認可コードフロー / スコープの粒度設計 / redirect_uri の検証
12 通知 API 未読数の取得（毎回 COUNT しない）/ 既読の一括更新（バルク操作）/ 通知設定のリソース設計
13 チャット送信 メッセージ順序の保証（クライアント採番? サーバー採番?）/ 送信取消と編集 / 配信確認
14 予約 API 仮押さえ（期限付きリソース）の表現 / 競合時は 409 で何を返すか / 空き照会と予約の分離
15 送金 API 冪等キー必須 / 非同期処理（202 + ステータス取得 URL）/ 失敗の種類をエラーコードで区別
16 公開データ API（天気など） Cache-Control で CDN に乗せる / API キーと無料枠のレート制限 / 後方互換の維持
17 動画アップロード（YouTube 風） チャンク分割と再開 / 処理ステータスの状態遷移（uploaded→processing→ready）/ 字幕などサブリソースの設計
18 カレンダー 繰り返し予定の展開（マスタと instances の2系統）/ タイムゾーンの受け渡し / 出欠（RSVP）の更新
19 求人検索 保存済み検索条件のリソース化 / 新着通知との接続 / 応募 API の冪等性
20 地図・位置情報 近傍検索のパラメータ設計（半径? 矩形?）/ 大量ピンの間引き / 位置更新の頻度制御
21 LLM API ストリーミング応答（SSE）/ トークン課金と usage の返し方 / 長い生成の途中キャンセル
22 Webhook（汎用設計） 署名で送信元を検証 / リトライは指数バックオフ・順序保証しない前提 / 受信側は即 200 + 非同期処理
23 一括（バルク）API 部分成功をどう返すか（全体 200 + 個別結果の配列）/ 件数上限 / 全件失敗との区別
24 ファイル共有リンク 権限付き URL の発行と失効 / パスワード・期限の付与 / リンクを知っている人=認可の是非
25 フィード配信 差分取得（since パラメータ）/ ETag と 304 でポーリングを軽くする / ページングの終端表現
26 管理者 API 一般 API と分離する理由 / 破壊的操作の確認（dry-run）/ 監査ログを必ず残す
27 レートリミット設計 429 + Retry-After / X-RateLimit-* ヘッダ / キー単位・IP 単位・ユーザー単位の使い分け
28 バージョニング URL(/v1/) か ヘッダか / 破壊的変更の定義 / Deprecation・Sunset ヘッダでの廃止予告
29 エラーレスポンス設計 4xx と 5xx の使い分け / エラーコード体系（機械可読 + 人間可読）/ problem+json
30 総集編: API 設計チェックリスト 冪等性・ページネーション・レート・バージョン・エラーの5点セット1枚図（保存推奨・C 型と兼用）

※ Day 27〜29 は特定サービスでなく横断テーマ。B 演習・G 比較表への型替え素材としても使える

A-7: 連載シーズン候補⑦「クラウド構成図で学ぶ設計 Day N/30」（設計100本ノックの3本目）

形式: AWS 構成図1枚（Excalidraw）+「なぜこの構成か」急所3つ +「あなたなら何を変える?」で締め。要件→構成の変換を見せる

定番構成（Day 1〜10）: 静的サイト+CDN（S3+CloudFront） / Web 3層（ALB+ECS+RDS） / サーバーレス API（API GW+Lambda+DynamoDB） / 画像アップロード・変換パイプライン / 動画配信（YouTube 風: アップロード→トランスコード→CDN 配信。DB Day5・API Day17 との3点セットお題） / リアルタイムチャット（WebSocket） / バッチ基盤（EventBridge+Step Functions） / ジョブキュー（SQS+ワーカー） / 通知基盤（SNS/SES/Push） / 検索基盤（OpenSearch）

非機能で差がつく（Day 11〜20): マルチ AZ と DR（RTO/RPO） / オートスケーリング / VPC 設計（サブネット分割） / 閉域接続（Direct Connect/VPN） / 秘密情報管理（KMS/Secrets Manager） / WAF と DDoS 対策 / 監視・アラート設計 / ログ収集基盤 / RDS の冗長化（レプリカ/Aurora） / ゼロダウンタイムデプロイ（Blue/Green）

応用（Day 21〜30): マルチテナント SaaS / 認証基盤（Cognito vs 自前） / CDN キャッシュ戦略 / コスト最適化の定石 / スケジュール処理 / データ分析基盤（S3+Athena） / LLM 推論 API 構成（A-6 と連動） / カナリアリリース / 障害を想定した構成レビューの観点 / 総集編: 構成パターン地図（保存推奨）

A-6: 連載シーズン候補⑥「面接で聞かれる AI/LLM 基礎 Day N/30」

根拠: 調査で Sarthak の「AI がコードの9割を書けるのになぜ君を雇う?」が返信数トップ（42）。AI×面接は今いちばん会話が生まれる交差点。 独自性: speech-coach 自体が AI プロダクト（Anthropic API・質問=Haiku/深掘り=Sonnet の使い分け）なので、一次情報の開発知見として語れる=他の解説アカウントと差別化できる。後半 Day はそのまま build in public・ローンチ布石になる。

基礎（Day 1〜10） 1. LLM は何をしているのか（次トークン予測） 2. トークンとは（料金と文字数の単位） 3. コンテキストウィンドウ（なぜ長い会話で忘れるのか） 4. temperature は何を変えるのか 5. なぜハルシネーションが起きるのか 6. embedding とは（意味を数値にする） 7. ベクトル検索と類似度 8. RAG の全体像 9. チャンク分割の設計 10. RAG vs ファインチューニング（G 比較表と兼用）

アプリに組み込む（Day 11〜20） 11. システムプロンプト設計 12. few-shot（例を見せると精度が上がる理由） 13. function calling / tool use 14. エージェントとは（LLM をループで回す=ループエンジニアリング: 「LLM に道具を渡して、目標達成まで 観察→思考→行動 を繰り返させる while ループ」。設計の急所は 終了条件 / ツール結果をどうコンテキストに詰めるか / 暴走・無限ループのガード / 何ステップ分の履歴を残すか） 15. MCP とは 16. ストリーミング応答（SSE。A-5 Day21 と連動） 17. 構造化出力（JSON で返させる） 18. 会話履歴の管理（何をどこまで送るか） 19. マルチモーダル（画像・音声入力） 20. 音声パイプライン（STT→LLM→TTS。speech-coach の一次情報）

運用・本番（Day 21〜30） 21. プロンプトインジェクション 22. ガードレール設計（人間の関与モデル込み: HITL=Human-in-the-Loop「人間が承認しないと実行されない」/ HOTL=Human-on-the-Loop「AI は自走、人間は監視して必要時に介入」/ 完全自律。破壊的操作は HITL・可逆な操作は HOTL、という切り分けが設計の答え。Day 14 ループエンジニアリングと連動） 23. LLM 出力の評価（evals） 24. LLM-as-judge 25. コスト設計（小さいモデルに逃がす。Haiku/Sonnet 使い分けの実例=一次情報） 26. プロンプトキャッシュ 27. レイテンシ改善 28. AI 機能のテスト戦略（非決定的な出力をどうテストする?） 29. プロンプトのバージョン管理 30. 総集編: AI 機能開発チェックリスト（保存推奨）

B 質問バンク追加（AI・10）

「AI がコードの9割を書けるなら、なぜ会社はあなたを雇うのか?」（Sarthak 返信42 の実績投稿の日本語再現・最優先で投入）/ Copilot が書いたコードのバグは誰の責任? / LLM の出力が正しいか、どう検証する? / RAG を一言で説明できますか / ハルシネーションを仕様としてどう扱う? / 面接で「AI をどう使っていますか」と聞かれたら何と答える? / AI 時代に若手は何から学ぶべき? / プロンプトエンジニアリングはスキルとして残る? / 社内データを LLM に渡してよいか、何を確認する? / コーディングテストで AI 使用可と言われたらどう振る舞う? / AI エージェントの「ループ」を設計するとき何を決める必要がある?（終了条件・ツール定義・コンテキスト管理・失敗時のリトライ=ループエンジニアリング） / AI に任せる業務で、人間はどこに立つ?（HITL=承認者 / HOTL=監視者 の使い分け。「どの操作なら承認なしで許すか」を語れると強い）

※ 「AI 時代の面接・キャリア」系は E/F 枠とも相性が良い（議論が割れる=リプが伸びる）。F の build in public 枠は「AI 面接コーチを Go で作って学んだこと」に寄せ、A-6 後半と連動させる

※ どの回も「正解の ER 図」ではなく「急所をどう捌くか」を見せる。締めの問いかけでリプを回収し、翌日リプで自分の答えを補足（B 型の運用を流用）

B: 面接演習 質問バンク（60）

B-1〜B-12 は x_post.md にドラフト済み（ALB vs ELB / HTTP ステートレス / Go main / println / フェデレーション / AssumeRole / S3 安全化 / presigned URL / CDN / ルートテーブル / セッション / localStorage と IndexedDB）。残り48の候補:

Go（Go 学習の言語化を兼ねる・優先） goroutine とスレッドの違い / channel は何を解決する / defer の実行順 / slice の内部構造（len と cap） / map は並行安全か / interface の暗黙実装 / error を値で返す思想 / context は何のため / GC はいつ動く / ポインタレシーバとの使い分け / sync.Mutex と channel の使い分け / go test -race は何を見ている

Web/ネットワーク CORS とは・プリフライトはなぜ飛ぶ / TCP vs UDP / 3ウェイハンドシェイク / URL を打ってから表示までに起きること / ETag と 304 / keep-alive / GET に body を持たせてよいか / 401 と 403 / DNS の TTL を短くする弊害 / WebSocket はどう繋がる

DB インデックスが効かないケース / EXPLAIN の見方 / デッドロックはなぜ起きる / 楽観ロックと悲観ロック / 正規化しすぎの弊害 / COUNT(*) はなぜ遅い / トランザクション内で外部 API を呼んではいけない理由

AWS/インフラ セキュリティグループと NACL の違い / SQS と SNS の使い分け / Lambda のコールドスタート対策 / CloudFront + S3 の定番構成 / ECS と EKS の選び方 / スポットインスタンスはどこで使う / IaC はなぜ必要 / Direct Connect と Site-to-Site VPN の使い分け（帯域・安定性・コスト・リードタイム）

セキュリティ CSRF トークンの仕組み / JWT はどう失効させる / セッション固定攻撃 / bcrypt はなぜわざと遅い / 秘密情報をコードに置かない方法 / XSS の3種類

ふるまい系（軽め・F と兼用可） 「分かりません」と言ってよいか / 逆質問で何を聞く / コードテスト中に詰まったら

C: MUST know リスト（20）

深掘り質問リスト ✔︎（初期投稿セット案 投稿1） / 逆質問リスト ✔︎（同 投稿2） / HTTP ステータスコード / SQL チューニングチェックリスト / Linux コマンド（障害調査系） / git コマンド（現場で使う順） / docker コマンド / kubectl コマンド / 面接前日チェックリスト / システムデザイン頻出パターン / AWS サービス選定チートシート / Go 面接頻出質問 / API 設計チェックリスト / 認証方式の比較表 / キャッシュをどこに置くか地図 / 計算量チートシート / 障害対応の初動チェックリスト / ネットワーク層の整理 / セキュリティ最低ライン / 転職ドキュメント準備リスト

D: 深掘りツリー図解（20・/fukabori-tree で量産）

業務改善 ✔︎（初期投稿セット案 投稿3） / 障害対応経験 / 技術選定 / リーダー経験 / 失敗経験 / 転職理由 / 自己紹介 / 強み・弱み / チーム内の対立 / 期限に間に合わない時 / 未経験技術のキャッチアップ / コードレビュー文化 / 上司と意見が割れた時 / 顧客折衝 / 成果の数値化 / 5年後のキャリア / なぜ弊社? / 年収の希望 / 現職に残る選択肢 / 逆質問

E: 行動面接シナリオ・二択（20）

「体感ですが、かなり」✔︎ / 失敗談 A or B ✔︎ / 「なぜあなたが?」に「たまたま担当で」/ 転職理由がネガティブしか出ない / 深掘り3段目で前の回答と矛盾 / 「他に選択肢は?」に沈黙 / 成果がチームのもので自分の貢献が言えない / 「今ならどう作る?」に現行構成をなぞるだけ / 逆質問が出ない / 想定外の質問で頭が真っ白 …等、初期投稿セット案.md の「実況・あるある」枠と連動で残りを埋める

F: 実況・エンゲージ質問（20）

「この深掘り、即答できる?」アンケート / 「今週なにを作ってる?」 / 転職・開発実況（企業特定情報は書かない） / speech-coach 開発ログ（build in public。ローンチ布石） / 「面接で一番困った質問は?」募集 …等。F の開発ログ枠は後半に増やし、ローンチ告知への助走にする

F+: 作り込まないポスト（制作ゼロ・人間味担当。ネタ切れ時と隙間時間はここから）

図解も下書きも要らない、その場で打てるポスト。「コンテンツ配信 bot」に見えるのを防ぎ、アカウントに体温を通す役。1日の2本目・3本目や、制作が間に合わない日の代打に使う。

  1. 進捗実況: 「Day 7 まで続いた。三日坊主の壁は越えた」
  2. 今日の学び1行: 「今日知ったこと: ◯◯。図にするほどじゃないけどメモ」
  3. 制作の裏側: 「Gemini に図を12回作り直させた。『手描き風』が伝わらない」
  4. 開発ログ: 「面接練習アプリ、AI 面接官が優しすぎる問題に直面してる」
  5. 自己訂正: 「昨日の図、◯◯が間違ってた。直したものをリプに」（誠実さ=信頼。実は伸びる）
  6. マイルストーン御礼: 「初めてブックマークされた。誰か知らないけどありがとう」
  7. 引用RT: 他人の良い投稿に自分の経験を一言添える（空リプ的な「勉強になります」はしない。必ず自分の情報を足す）
  8. 時事への一言: 新モデル・AI ニュースに自分の目線で一言（トレンドタブに乗るチャンス枠）
  9. 質問募集: 「次の図解、どのテーマが見たい?」（フォロワーが増えてから）
  10. ビフォーアフター: 「1ヶ月前の自分は Redis を『速いキャッシュ』としか説明できなかった」
  11. 作業風景: Excalidraw 制作中のスクショ1枚「今日の分を作ってる」
  12. 面接あるある1行: 「『最後に質問は?』で頭が真っ白になるの、あれ何なんだろうな」
  13. 週末の問いかけ: 「今週末、何を勉強する予定?」
  14. 弱音→回復: 「今日は疲れて図が描けない。明日2枚にします」（宣言型は継続の証明になる）

※ 5 と 8 は特に費用対効果が高い。5 は信頼、8 は既存のトレンド波に乗れる唯一の枠

拡張パック（在庫を300超にする追加の型とテーマ）

200本は以下も含めた在庫から「伸びた型を優先」で埋める。A〜F に加えて4つの型を追加する。

追加の型 G〜J

記号 型 画像 狙い 説明
G 比較表1枚「A と B の違い」 有 保存・RT 表画像1枚で完結。制作コスト最小で保存率が高い定番形式
H コードレビュークイズ「どこを指摘する?」 有（コード画像） 返信 A-3(Go 100Tips) と連動。翌日リプで解説
I 障害ポストモーテム推理「原因は?」 無 返信 Sarthak の障害シナリオ型を独立させて量産
J 数字ネタ「知っておくべき数字」 有 保存 レイテンシの目安など。少数精鋭

G: 比較表バンク（20）

401 vs 403 / PUT vs PATCH / ALB vs NLB / SQL vs NoSQL / JWT vs セッション / TCP vs UDP / ECS vs EKS / SQS vs SNS / 楽観ロック vs 悲観ロック / プロセス vs スレッド / 認証 vs 認可 / モノリス vs マイクロサービス / GraphQL vs REST / Cookie vs localStorage / コンテナ vs VM / CSR vs SSR / 冗長化 vs スケールアウト / フェイルオーバー vs フェイルバック / 論理削除 vs 物理削除 / Direct Connect vs VPN / FIFO vs LIFO（キュー vs スタック。実世界の対応表: SQS・レジ待ち行列 vs コールスタック・undo） / HITL vs HOTL（人間が承認して進める vs AI が自走し人間は監視。例: 本番デプロイの承認ボタン vs 異常検知アラート。AI 時代の旬ネタで議論も湧く）

※ B 演習で出した質問の「回答リプに付けた表」をそのまま単独投稿化してよい（1コンテンツ2露出）

H: コードレビュークイズバンク（15）

Go（A-3 と連動・コード5〜10行の画像）: ループ内 defer / goroutine とループ変数 / エラーをログして return もする / typed nil を返す / slice の共有バッファ / map の並行書き込み / channel close 忘れ / context 無視のブロッキング呼び出し

SQL: インデックスが効かない WHERE（関数・暗黙型変換） / SELECT * で N+1 / OFFSET 深掘りページネーション

API 設計: GET で副作用 / パスワードをクエリパラメータ / エラーで常に 200 / レスポンスに内部 ID・スタックトレース

I: 障害ポストモーテム推理バンク（15）

深夜に CPU 100%（暴走リトライ） / じわじわ増えるメモリ（リーク） / 月初だけ落ちる（バッチ集中） / 突然の 502 多発（コネクション枯渇） / 特定ユーザーだけ遅い（データ偏り） / デプロイ直後だけ遅い（キャッシュ空） / ある日突然外部連携が全滅（証明書期限切れ） / DNS 切り替えたのに旧サーバーへ（TTL） / 深夜バッチが朝まで終わらない（統計情報の劣化） / 二重決済が発生（リトライと冪等性） / キャンペーン開始直後にダウン（thundering herd） / ディスクフル（ログローテーション忘れ） / 3月と10月だけ時刻がずれる（タイムゾーン/DST） / デッドロック多発（ロック順序） / 全 Pod 同時再起動（liveness probe 設定ミス）

※ 形式: 症状だけ書いて「まず何を見る?」で締める。翌日リプで原因と調査手順を後出し

J: 数字ネタバンク（5）

レイテンシの目安（メモリ→SSD→ネットワークの桁感） / 1日は86,400秒（TTL・レート設計の暗算） / int の上限と ID 枯渇 / 可用性 99.9% と 99.99% の年間停止時間 / 1リクエスト1ms 改善が月間でいくらになるか

面接官視点シリーズ（D の拡張・10）

「なぜその質問をするのか」の裏側解説。深掘りツリーの各テーマと1対1で連動させる: なぜ転職理由を聞くのか / なぜ失敗経験を聞くのか / なぜ「他に選択肢は?」と聞くのか / 自己紹介で見ているポイント / 逆質問で評価が動く理由 / 「わかりません」の正しい言い方 / 面接官が沈黙する理由 / 一次と最終で見られる点の違い / カジュアル面談は選考か / お見送り理由の定番

B 質問バンク追加（OS/Linux・フロントエンド）

OS/Linux・CS 基礎: プロセスとスレッドの違い / スタックとヒープ / ファイルディスクリプタとは / ゾンビプロセス / シグナル（kill -9 は何が乱暴か） / top で最初に見る場所 / ロードアベレージとは / FIFO と LIFO、実務のどこに現れる?（SQS FIFO キュー・コールスタック・undo・ポイントの先入れ先出し消費=DB 設計 Day28 と連動） / なぜ標準キューは順序保証しないのか（FIFO キューとのスループット差）

フロントエンド: 仮想 DOM は何を解決した / CSR と SSR の使い分け / バンドルサイズがなぜ問題 / Core Web Vitals とは / debounce と throttle

1テーマ多重露出マトリクス（在庫の掛け算）

同じテーマを型を変えて複数回出す。例: Redis → A(連載 Day2 図解) → B(ヒット率急落、まず何を見る?) → G(Redis vs Memcached 表) → H(並行アクセスのコードクイズ) → I(キャッシュ空で thundering herd) → C(Redis 面接質問リスト) = 1テーマで最大6露出。主要テーマ15個 × 平均4型 = それだけで60本。テーマを新しく探すより、伸びたテーマの型替えを優先する（Sarthak も REST を リスト/質問/シナリオで使い回している）

在庫合計

出どころ 本数
A 連載候補①〜⑦ 30+30+30+40+30+30+30 = 220（うち設計100本ノック=100）
B 演習質問（拡張込み） 82
C リスト 20
D 深掘りツリー + 面接官視点 30
E シナリオ・二択 20
F 実況・エンゲージ 20
G〜J 55
合計 約450

200本に対して在庫450 → 6ヶ月間、伸びた型だけ選んで出せる余裕がある状態。

設計100本ノック（A-4 DB 設計40 + A-5 API 設計30 + A-7 クラウド構成30）のセット運用: X・Notion・EC・予約・カレンダーなど共通お題は「DB 編 → API 編 → 構成編」と続けて出すと、1お題で最大3露出+前回参照の自リプでアカウント内回遊が作れる。「設計100本ノック Day N/100」の通しナンバーにすれば看板が立ち、完走報告自体が実績投稿になる。

運用メモ

  • アカウントの人格（投稿0で宣言・全投稿で一貫させる）: 「技術面接でボコボコにされたのをきっかけに学び直しを始めた当事者」。教える先生ではなく、学び直しの過程を公開している人。ミッションは「AI がコードを書く時代に、設計など人間に余地が残る部分を明確にして伝える」。開設ポスト（x_post.md 投稿0）を最初に出して固定ポストにする。この人格は speech-coach ローンチ時の「悔しさを構造化したアプリを作った」に直結する
  • 140字制約と X 課金の方針: 無課金の間は本文全角140字以内。「本文=人間味フック、図解=情報の本体」で回す（x_post.md の140字テンプレ参照）。課金するならプレミアム（月1,000円前後・要最新価格確認）を、リプ営業を本格化するタイミングで。狙いは①認証マークでリプ欄の上位表示（毎日のリプ営業の露出に直結、費用対効果が最も明確）②長文解禁で C 型（保存型リスト）をテキスト投稿にできる ③収益化条件（フォロワー500+一定インプ）への布石。ただし A 連載の140字+図解の型は課金後も維持する（制約として優秀。フックが締まり、情報が図に寄る=保存が伸びる）
  • テーマ外投稿のルール: テーマ内 9:自由 1 の目安。AI ツールの実用 Tips（Codex のよく使うコマンド等）はテーマ内扱いで OK（F/C 枠のネタになる）。裸の外部リンク投稿（「あとで見る」型）はしない——X はリンク付き投稿のリーチを下げるため。記事を共有するなら「一言の学び・感想を本文に、URL は1リプ目に」の形式。自分用の「あとで見る」は X でなく inbox/クリップ/（/x-bookmark-inbox）へ。完全な雑談は週1程度なら人間味としてプラス
  • 在庫置き場: ドラフトは x_post.md に型別で追記。投稿済みは日付を付けて末尾の「投稿済み」節へ移す（次回作成時に節を追加）
  • 図解: Excalidraw の手描き風テンプレを1つ作り、全 A/C/D で使い回す（見た目の統一=アカウントの型）
  • 「面接で実際にあった質問」の表記は実体験と合うものだけ。それ以外は「面接でよく聞かれる」
  • 週次: /marketing-weekly で型別の表示・返信・保存を記録し、この計画の配分を月1で見直す
  • この計画は Issue #6（ビジネス・マーケ）に要約をコメントして正とする（gh CLI・要指示）