AI Session Notes - 2026-02-11

情報の重複を認識して記録システムを統廃合する

学んだこと

複数の記録先（例: 詳細な学習ノートと日次サマリ）が同じ情報源を参照している場合、サマリ側は「元の情報の劣化コピー」になりがち
結局詳細を見たいときは元の情報源に戻るため、中間的な要約レイヤーは情報の圧縮率が中途半端で価値が薄い
「同じことを2回書かない」は DRY 原則そのものであり、ドキュメント・記録運用にも適用すべき
廃止を判断する基準: 「この記録を見て、元の情報源を見に行かずに済むか？」— No なら不要

マルチリポ構成における自動化ロジックの配置戦略

学んだこと

中央リポ（集約所）に外部リポの収集ロジックを置くと、中央が外部の内部構造に依存するという逆方向の結合が生まれる
外部リポの構造変更（ディレクトリ名変更、管理方法の変更など）のたびに中央リポ側の修正が必要になり、外部リポの自由度が制約される
「情報を発信する側がフォーマットと記録ロジックを持つ」方が依存の方向が自然
各リポが自分の構造を最もよく知っている
テンプレートやフォーマットをリポごとに最適化できる
リポの構造変更とロジック変更が同じリポ内で完結する

詳細

# アンチパターン: 中央集約型
中央リポ → gh api で外部リポのコミット取得
中央リポ → 外部リポの logs/ ディレクトリ構造を知っている
中央リポ → 外部リポの issue 管理方法を知っている
→ 外部リポの構造変更 = 中央リポも修正が必要

# 推奨パターン: 各リポ責務型
外部リポ → 自分のコミット/変更を分析
外部リポ → 自分が決めたフォーマットで記録を生成
外部リポ → 中央リポに直接書き込み
→ 外部リポの構造変更 = そのリポ内で完結

これはマイクロサービスの「各サービスが自分のデータを所有する」原則と同じ考え方。

Claude Code スキルの配置パターン: リポ固有 vs グローバル

学んだこと

.claude/skills/ はプロジェクトローカル（リポ固有）と ~/.claude/skills/（グローバル）の2箇所に配置可能
リポ固有のスキルは、そのリポの構造やコンテキストに密結合したロジックに適している
グローバルスキルは、リポに依存しない汎用的な処理（例: 共通のコミットルール）に適している
「ロジックの分散」は一般にデメリットとされるが、各リポの記録粒度やフォーマットが異なる場合はむしろメリットになる
テンプレートが異なる → ロジックも異なるべき
粒度の調整が自由 → リポごとに最適化できる

マルチリポ間の移行ハンドオフパターン

学んだこと

あるリポから別のリポへ責務を移行する際、移行先リポに「TODO ファイル」を置く方法が有効
TODO ファイルに含めるべき情報:
移行の背景・理由（なぜ変わるのか）
具体的なタスク（何を作るか）
現行のロジック全文（参考として。ただし「そのまま使う必要はない」と明記）
状態管理ファイルの移行方法
各リポで独立して作業を進められる形にしておけば、移行を段階的に実行できる
現行ロジックを「参考」として渡しつつ「再設計OK」と明記することで、移行先が最適な形を選べる

静的サイトホスティングサービスの選び方

学んだこと

静的HTML/CSS/JSの配信だけなら、BaaS（Firebase/Amplify）ではなくホスティング特化サービス（Cloudflare Pages等）の方がシンプルで制限も緩い
GitHub Pagesは無料プランだとPublicリポジトリのみ対応。Privateリポジトリで使うにはPro以上が必要、かつサイト自体は公開される
Cloudflare Pagesは無料でPrivateリポジトリ対応・帯域無制限。git pushで自動デプロイされる
Firebase HostingはGoogleエコシステムに属するが、無料プランは帯域360MB/日と制限が厳しい
サービス選定は「何を配信するか」だけでなく「リポジトリの公開範囲」「運用の手軽さ」も考慮する

BaaS（Firebase/Amplify）の位置づけと制約

学んだこと

Firebase（Google）とAmplify（AWS）は同じポジションのサービス。ホスティング・認証・DB・サーバーレス関数をワンパッケージで提供するバックエンド丸ごとプラットフォーム
抽象化の層が厚く手軽だが、裏側のサービス（特にDB）に縛られるトレードオフがある
Amplify → DynamoDB（KV型NoSQL）
Firebase → Firestore（ドキュメント型NoSQL）
どちらもNoSQL前提のため、アクセスパターンを事前に設計する必要がある。後から「別の切り口で取得したい」が出てくると苦しい
向いているケース: 要件がシンプルで明確、素早くプロトタイプを作りたい、インフラを気にしたくない
向いていないケース: クエリパターンが複雑/変わりうる、インフラの細かい制御が必要、コスト最適化をしたい

RDB vs NoSQL の選定基準

学んだこと

RDB が向くケース: エンティティ間の関係が複雑、集計・分析が必須、アクセスパターンが多様（業務システムに多い）
NoSQL が向くケース: ユーザー単位で独立したデータ、最新データの表示が中心、アクセスパターンが限定的（コンシューマ向けアプリに多い）
判断基準を一言で言えば「キーで引いてそのまま画面に出すのがメインか、色んな切り口でJOIN・集計するか」
NoSQL向きの典型例: チャットアプリ、SNS、モバイルゲームのバックエンド、リアルタイムコラボツール

詳細

NoSQLにもいくつか種類がある:

種類	特徴	代表例
KV型	キーで1件引く	Redis, DynamoDB
ドキュメント型	JSONのような構造を格納	Firestore, MongoDB
カラム型	大量データの集計に強い	Cassandra, HBase
グラフ型	関係性の探索に強い	Neo4j

OLTP/OLAP 分離パターン

学んだこと

OLTP（Online Transaction Processing）: 1件ずつ高速に読み書きする処理（日々の受注入力、ユーザー操作など）
OLAP（Online Analytical Processing）: 大量データをまとめて集計・分析する処理（月次レポート、KPI集計など）
NoSQLをアプリのDBに採用しても、分析が不要になるわけではない。アプリ用DBと分析用DBを分離するのが一般的
Firebase → BigQuery にイベントデータを流してSQLで分析
Amplify → DynamoDB Streams → S3 → Athena/Redshift で集計
業務システムでは1台のRDBがOLTPとOLAPを兼ねることが多いが、規模が大きくなると互いに影響し合うため分離が有効
分離の判断基準: 分析クエリの重さがトランザクション処理に影響を与え始めたら分けるタイミング

クラウドサービスのフリーミアムモデル

学んだこと

Cloudflareのような企業が静的サイトホスティングを無料で提供する理由はフリーミアム戦略
個人開発者を無料で大量に集め、ビジネス成長時に有料プランへ移行してもらう
多くのサイトを保護することで攻撃パターンのデータが集まり、セキュリティ製品の品質が向上する
本業である企業向けCDN・セキュリティが収益の柱
個人の静的サイト配信コストはプラットフォーム側にとって非常に小さく、エコシステム拡大のメリットの方が大きい

メタ情報

ツール: Claude Code
関連技術: Claude Code Skills, マルチリポ構成, DRY 原則, 依存関係の方向, マイクロサービスパターン, 自動化設計, Cloudflare Pages, Firebase, AWS Amplify, NoSQL, RDB, OLTP/OLAP, DynamoDB, Firestore, BigQuery, 静的サイトホスティング