全アーキテクチャ
カテゴリ別に整理されたネットワーク通信構造
⚡ リアルタイム / 持続接続
WebSocket
双方向リアルタイム通信
HTTPハンドシェイク後にTCP接続を維持し、サーバーとクライアントが自由にメッセージをやり取りする全二重（full-duplex）通信プロトコル
SSE（Server-Sent Events）
サーバー→クライアント単方向ストリーム
HTTP接続を維持しながらサーバーがクライアントにイベントを単方向でストリーミングする方式。text/event-stream形式を使用
GraphQL Subscription
GraphQLスキーマベースのリアルタイムイベント
GraphQLのsubscriptionタイプを通じてクライアントが特定イベントを購読し、サーバーがデータ変更時に自動的にアップデートを配信する方式
🔔 イベント駆動
📡 センシング / IoT
WiFi CSIによる位置分析はどう動くのか？
単一WiFi信号の物理層データをレーダーのように活用
WiFi信号のCSI（Channel State Information）を分析し、カメラなしで人の位置・動き・呼吸・心拍まで検知する技術。各サブキャリアの振幅と位相の変化からミリメートル級の空間情報を抽出
Bluetoothが暴露するあなたの情報
BLE信号だけで生活パターン・位置・行動が追跡される原理
BluetoothをオンにしているだけでもMACアドレス、デバイス名、製造元、BLEサービスUUIDなどが絶えずブロードキャストされる。ラズベリーパイ1台で周辺の人の通勤パターン、宅配到着時点、家が空く時間帯まで把握可能
🧩 ランタイム / 実行
WebAssembly（WASM）はどう動くのか？
C++/Rust/Zigコードをブラウザでネイティブ速度で実行
WebAssembly（WASM）はC++、Rust、Zigなどで書かれたコードをバイトコードにコンパイルし、ブラウザでネイティブに近い速度で実行する技術。JavaScriptでは不可能な高性能演算（画像/動画処理、3Dレンダリング、ターミナルパーサーなど）をWebで実現可能
WASMをWebの第一級言語にする
JS glueなしでWeb APIを直接呼び出すComponent Model
2017年の登場以来、WASMはWebで「2級市民」— DOM/consoleなどのWeb APIに直接アクセスできず、必ずJS glue codeを経由する必要があった。Mozillaが提案したComponent ModelはWITでAPIを宣言しJSなしで直接呼び出しを可能にし、WASMをブラウザの第一級実行環境に格上げしようとする試み
WebGPU — ブラウザがローカルGPUを直接使う仕組み
WebGLの後継、Vulkan/Metal/DX12レベルの低レベルGPU APIがブラウザに
WebGPUはブラウザ内蔵のJavaScript APIで、WebページからローカルGPUハードウェアに直接アクセスできる。WebGLの後継であり、OS別にVulkan/Metal/DirectX 12にマッピングされる。
🌐 DNS / ドメイン
DNSドメイン設定はどう反映されるのか？
onamae.comのようなサイトでドメインを設定すると実際に何が起こるのか
DNS（Domain Name System）はドメイン名（例: example.com）をIPアドレス（例: 93.184.216.34）に変換するインターネットの電話帳。onamae.comのようなレジストラでドメインを設定するとルートサーバー → TLDサーバー → 権威ネームサーバーの順で階層的に伝播し、世界中からアクセス可能になる
ネームサーバー変更はなぜ24〜72時間かかるのか？
ネームサーバー(NS)変更時に伝播が遅い本当の理由と各段階のキャッシュ構造
ネームサーバー変更は単純なDNSレコード変更と異なりTLD(.com/.net)レベルのキャッシュ更新が必要。TLD NSレコードのTTLが通常48時間で、ISPリゾルバがこれをキャッシュするため、世界中に反映されるまで24〜72時間かかる
DNS-PERSIST-01はどう動くのか？
Let's Encryptの持続的DNS認証レコードで繰り返し検証を排除
Let's Encrypt証明書発行時に毎回DNS TXTレコードを変更する必要があるDNS-01の限界を解決。_validation-persist. TXTレコードにCA アカウント情報を一度だけ設定すれば以降の発行/更新に再利用
onamae.comのようなDNSプロバイダーになるには？
ICANN認定からAnycastインフラまで、ドメインレジストラの裏側
onamae.comのようなDNSプロバイダー（レジストラ）になるにはICANN認定、Anycast DNSネットワーク、EPPプロトコル実装、WHOIS/RDAPデータベース、DDoS防御など大規模インフラと規制遵守が必要
ドメイン購入の流れ
TLD選択から更新管理まで、ドメイン購入の全ステップ
ドメイン購入はTLD選択、WHOIS可用性確認、レジストラ選択、登録（連絡先情報 + WHOISプライバシー）、DNS初期設定、更新管理の順で進む。ドメインライフサイクル、プレミアムドメイン市場、ドメイン盗難防止まで包括的に解説
無料HTTPSサービスの仕組み
Let's Encrypt、Cloudflare、ACMが無料証明書を提供する仕組み
ACMEプロトコル、ドメイン検証、CA信頼チェーン、TLSハンドシェイクなど、無料HTTPSサービスの核心原理を解剖します
DNS障害事例集
インターネットを止めた大規模DNS障害と教訓
Dyn DDoS、Facebook BGP事故、Fastly障害など主要DNS関連障害事例を分析し、単一障害点防止のための実務的教訓をまとめます
🔍 仕組み解説
ngrokはどう動くのか？
リバーストンネルでローカルサーバーをインターネットに公開
ngrokはローカル開発サーバーを公開URLで公開するトンネリングサービス。PC上のngrokクライアントがngrokクラウドにアウトバウンド接続を開き、外部トラフィックがそのトンネルを通じてローカルに転送される
Slack Socket Modeはどう動くのか？
WebhookなしでアウトバウンドWebSocketによるイベント受信
Slack Botが公開URLなしでイベントを受信する方式。BotサーバーがSlackにWebSocket接続を先に開き、Slackがその接続を通じてイベントをpush。ファイアウォール背後でも動作
ChatGPTストリーミングはどう動くのか？
SSEによるトークン単位のリアルタイム応答配信
ChatGPTが回答を一文字ずつ表示する秘密。OpenAI APIがSSE（Server-Sent Events）で生成されたトークンを即座にストリーミング送信し、クライアントが1つずつ受け取って画面にレンダリング
GitHub Webhookはどう動くのか？
git push → HTTP POST → CI/CDトリガー
GitHubでコードpush、PR作成などのイベント発生時に、事前登録したURLにHTTP POSTを送信して外部システム（CI/CD、Slack通知など）を自動的にトリガーする方式
Sidekiqはどう動くのか？
Redisベースのバックグラウンドジョブキューシステム
Railsで重いタスク（メール送信、画像処理など）をバックグラウンドに委譲するシステム。WebプロセスがRedisキューにジョブを入れると、Sidekiqワーカープロセスが取り出して非同期処理
WebRTCはどう動くのか？
ブラウザ間の直接映像/音声/データ転送
ブラウザ同士が中央サーバーなしでビデオ通話、画面共有、ファイル転送を行う技術。シグナリングサーバーで接続情報を交換後、STUN/TURNでNATを通過してP2P直接接続
MCPはどう動くのか？
AIモデルと外部ツールを標準方式で接続するオープンプロトコル
MCP（Model Context Protocol）はAIモデル（LLM）と外部ツール・データソースを標準化された方式で接続するオープンプロトコル。Host（Claudeなど）がClientを通じてMCP Serverに接続すると、ServerがDB・ファイル・APIなど外部システムをAIに公開
MCP Transport: stdio vs Streamable HTTP
ローカル開発とクラウドSaaSデプロイの違い
MCPは2つの公式transportをサポート：stdio（ローカル）とStreamable HTTP（リモート/SaaS）。2025年3月導入のStreamable HTTPでSaaSベンダーがMCPサーバーをクラウドにデプロイし多数のクライアントがアクセス可能
tmuxはどう動くのか？
ターミナルマルチプレクサでセッション維持＆分割
tmuxは1つのターミナルで複数セッションを管理するターミナルマルチプレクサ。サーバー-クライアント構造で、SSH接続が切れてもセッションが維持され、後から再attachが可能
Vercel Subdirectory Reverse Proxyはどう動くのか？
Next.jsドメイン配下のサブディレクトリで外部サーバーのコンテンツを統合しSEO権威を集中
negabaro.com（Vercel/Next.js）から/blog/*パスをRails（DigitalOcean）やJekyll（GitHub Pages）など外部サーバーにリバースプロキシ。ユーザーには単一ドメインに見えるが、実際のコンテンツは別サーバーでレンダリング。バックエンド技術スタックに関係なくcanonical/robots.txt/アセット絶対URL設定でSEO権威をメインドメインに集中する構造
Dockerコンテナの内部構造
Linuxネームスペースからmacos対応、GPUまで — 10年間の技術的進化
2013年に登場したDockerは、LinuxネームスペースでVM無しにプロセスを分離する。CLIの裏には数十年のシステム研究が隠れており、macOS/Windows対応のためにライブラリVMMという逆転の発想を採用した。
Keploy — eBPFでトラフィックを傍受しAPIテストを自動生成する仕組み
eBPFがカーネルでconnect()の宛先をこっそり書き換える透過プロキシパターン
keploy recordでアプリをラップすると、eBPFがカーネルレベルで全アウトバウンド接続の宛先をローカルプロキシにリダイレクトする。アプリは知らない。プロキシがプロトコル別にトラフィックを解析し、テストケース+MockをYAMLとして抽出する。
🏗️ システム設計
良いシステム設計とは — 目立たない設計こそ最高の設計
状態管理、DB設計、キャッシュ、イベント処理、障害復旧まで — 実証済みのシンプルさの力
良いシステム設計は複雑に見えない。長期間問題が起きず、「この部分は気にしなくていい」という反応が出れば成功だ。状態を保持するコンポーネント数を減らし、実証済みのシンプルな構造を使うことが核心。
コラボレーションは嘘だ — 少数が作り、多数が会議する
Brooksの法則、リンゲルマン効果、そしてコラボレーションツールが隠す責任拡散の構造
組織の実質的成果は少数が生み出す。テック業界はこの問題に「コラボレーション」を処方したが、実際に増えたのは調整ツールだけで成果物は出ない構造が固定化した。本当に必要なのはコラボレーション基盤ではなく、個人の主体的判断と責任（ownership）だ。
テストコードが新しい堀(Moat)になる時代
AI時代の本当の資産はコードではなくテストスイートだ
AIがコードを一行も見ずにドキュメントとテストだけを学習し、競合製品を1週間で作り出す時代だ。 コードはもう堀ではない。本当の資産は数万のエッジケースをカバーするテストスイートだ。
🎬 FFmpeg
FFmpeg — 25年間メディア世界を支えてきたスイスアーミーナイフ
アーキテクチャ、コーデック抽象化、フィルターチェーン、ハードウェアアクセラレーションまで — FFmpeg内部構造の解剖
FFmpegはほぼすべてのメディアフォーマットをデコード・エンコード・変換・ストリーミングできるオープンソースマルチメディアフレームワークだ。2000年にFabrice Bellardが開始し、25年以上開発が続いている。YouTube、Netflix、Meta、VLC、OBS — メディアを扱うほぼすべての場所でFFmpegが動いている。
MetaのFFmpeg活用 — 1日数百億回、大規模メディア処理の秘密
内部フォーク廃止、マルチレーン並列エンコード、リアルタイム品質メトリクス、自社ASIC
Metaは1日数百億回FFmpegを実行する。長年内部フォークに依存していたが、FFmpegコミュニティと協力してマルチレーン並列エンコードとリアルタイム品質メトリクスをアップストリームに実装し、内部フォークを完全に廃止した。自社ASICのMSVPもFFmpeg標準APIで統合した。
FFmpegバージョン別変化 — 6.0から8.1まで、何が変わったか
マルチスレッディングリファクタリング、Vulkanコーデック、ハードウェアアクセラレーション拡大、そして8.1 "Hoare"まで
FFmpeg 6.0から8.1までのメジャー変更を整理する。Metaベースのマルチスレッディングリファクタリング（6.0〜8.0）、Vulkanハードウェアコーデック、インループデコード、そして最新8.1「Hoare」のxHE-AAC、D3D12、Rockchipエンコードまで。
📱 クロスプラットフォーム
Sparkling — TikTokのクロスプラットフォームインフラ
Lynxエンジン上で実際のアプリを動かすためのプロダクションフレームワーク
TikTokが自社アプリでLynxエンジンをプロダクション規模で運用するために構築したインフラレイヤーをオープンソースで公開した。 React NativeにExpoが必要なように、Lynxエンジン上で実際のアプリを運用するにはビルドパイプライン、ネイティブブリッジ、ナビゲーションなどのインフラが必要だ。Sparklingがそのギャップを埋める。
Lynx — TikTokのクロスプラットフォームUIエンジン
Reactのように書いて、ネイティブでレンダリング
LynxはTikTokが公開したクロスプラットフォームUIレンダリングエンジンだ。ウェブ技術（React類似の文法）でコードを書けば、ネイティブレンダリングでAndroid/iOS画面を描画する。 React Nativeと似たポジションだが、TikTokのプロダクションで検証された独自のレンダリングパイプラインを持つのが差別点。
🤖 エージェンティックAI
エージェンティックAI — 自律エージェントの基本構造
LLMがツールを使い、判断し、反復する構造
エージェンティックAIは、LLMが単にテキストを生成するのを超えて、自ら計画を立て、ツールを呼び出し、目標に向かって反復実行するシステムだ。 「チャットボット」と「エージェント」の違いは自律性。チャットボットは質問に答え、エージェントは目標に向かって自ら行動する。
エージェントループ — 実行ループの解剖
whileループ1つがエージェントの全て
エージェントの核心は「LLMをループの中で回すこと」だ。一度呼んで終わりではなく、ツール呼び出しの結果を受けて再びLLMに渡し、LLMが次の行動を決定するサイクル。 このループをどう設計するかがエージェントの品質を決める。
ツール使用パターン — LLMに手足をつける
関数呼び出しでLLMが外部世界と相互作用する構造
LLMはテキストしか生成できない。ファイルを読んだり、APIを呼んだり、DBを照会するには「ツール」が必要だ。 ツール使用はLLMに利用可能な関数リストを伝え、LLMが必要な時に関数を呼び出させるパターンだ。
ラルフ・ウィガムループ — エージェントが同じ失敗を繰り返す時
「I'm in danger」— エージェントが抜け出せないループの原因と対策
エージェントが同じエラーに同じ修正を繰り返し、進展なくトークンだけ消費する状態。シンプソンズのRalph Wiggumが「I'm in danger」と言いながらぼーっと座っているミームから名前がついた。 AIエージェント開発で最も一般的でコストの高いアンチパターンだ。
ヒューマン・イン・ザ・ループ — 人間が介入するタイミング
完全自律 vs 適切な介入、そのバランス
エージェントが全て自動でやれば楽だが、取り消し不能な行動（データ削除、本番デプロイ、決済）は人間が確認すべきだ。 ヒューマン・イン・ザ・ループは「いつ人間に聞くか」を設計するパターンだ。
🔧 ハーネスエンジニアリング
ハーネス（Harness）とは何か
テスト実行環境からAIエージェントまで、対象を包んで制御するシステム
ハーネスはAI固有の概念ではない。元はソフトウェア工学のTest Harnessから来たもので、「対象を包んで制御する実行環境」全体を意味する。 AIハーネスでもテストハーネスでも、核心は同じだ — 対象自体よりも対象を包むシステムの設計が結果を左右する。
ハーネスエンジニアリング vs プロンプトエンジニアリング
プロンプトを上手く書くことと実行環境を上手く設計することは別物だ
プロンプトエンジニアリングはモデルに「何をしろ」を上手く伝える技術だ。ハーネスエンジニアリングはモデルが「どんな環境で実行されるか」を設計する技術だ。 同じプロンプトでもハーネスが違えば結果が全く変わる。
ガードレール設計 — モデルが暴走する前に止める方法
入力フィルタ、出力検証、行動制限で安全なハーネスを作る
モデルは確率的に出力する。10回中9回正しくても1回は間違う。ガードレールはその1回が本番で爆発しないようにする安全装置だ。 入力段階、実行段階、出力段階それぞれにガードレールを置く。
評価パイプライン — ハーネス品質を測定する方法
勘で判断すると負ける、自動化された評価体系が必須だ
ハーネスを変えて良くなったか悪くなったか分からなければ意味がない。評価パイプラインはハーネス変更の効果を定量的に測定するシステムだ。 SWE-bench、HumanEvalのようなベンチマークも結局は評価パイプラインの一種だ。
コンテキストウィンドウ管理 — 有限な記憶の戦略
100万トークンでも入れ方が重要だ
コンテキストウィンドウはモデルの「作業記憶」だ。サイズが大きくなっても無限ではなく、入れる順序と内容によって性能が変わる。 ハーネスの核心的な役割の一つがこの限られた空間を効率的に管理することだ。
オーケストレーションパターン — モデル呼び出しを組み合わせる方法
一回の呼び出しで足りなければ、複数回をどう組み合わせるか
複雑なタスクはモデル一回の呼び出しで終わらない。複数のモデル呼び出しをどの順序で、どの条件で実行するかがオーケストレーションだ。 エージェンティックAIのエージェントループも、RAGも、コード生成パイプラインも全てオーケストレーションパターンだ。
gstack解剖 — ハーネスエンジニアリング実践事例
Garry TanがClaude Codeで60日間60万行を書けた構造
gstackはY Combinator CEOのGarry Tanが公開したClaude Codeスキルパックだ。23個のスラッシュコマンドで一つのモデルを役割別の専門家チームに分離する。 同じClaudeなのにハーネスを変えただけ。これがハーネスエンジニアリングの威力だ。
🔀 Git
Gitは内部的にどう動くのか？
Blob, Tree, Commit — Gitの3つのオブジェクト
Gitはcontent-addressableなファイルシステムだ。すべてのファイル、ディレクトリ、コミットはSHA-1ハッシュで識別されるオブジェクトとして保存される。Blob（ファイル）、Tree（ディレクトリ）、Commit（スナップショット）の3つで大部分が説明できる。
rebase vs merge、いつ何を使うか
履歴保存と線形化のトレードオフ
mergeは2つのブランチをマージコミットで結合する。rebaseはコミットを別のベースの上に再度積み直す。mergeは履歴をそのまま残し、rebaseは線形に整える。共有ブランチにはmerge、個人ブランチにはrebaseが原則。
reset vs revert、何をいつ使うか
履歴を書き換える vs 打ち消しコミットを追加する
resetはブランチポインタを過去のコミットに戻す。revertは逆の変更を含む新しいコミットを追加する。ローカル作業ならreset、既にpushしたコミットにはrevertが安全。
git stashを正しく使う
作業中にブランチ切替が必要なとき
stashは未コミットの変更を一時スタックに退避し、working treeを綺麗にする。ブランチ切替、cherry-pick、緊急bugfix対応に使う。`checkout -- .`や`reset --hard`の代わりにstashを使えば、うっかり変更を失うことがない。
worktreeで複数ブランチを同時にチェックアウト
何度もcloneしなくていい
git worktreeは同じリポジトリを複数ディレクトリに異なるブランチでチェックアウトできる。何度もcloneする必要がなく、.gitディレクトリは共有なのでディスク容量も節約。長いビルドが回っている間に別ブランチ作業を並行したいときに真価を発揮する。