エンジニア達の「完全に理解した」Talk #74 イベントレポート

• URL: https://zenn.dev/easy_easy/articles/137eb74f6f5996
• 日付: 2026-06-26
• Tier: Tier 3
• 要旨: 第74回イベントレポートで、2026年2月開催。Google開発のTCP BBRはパケットロス発生まで送り続ける従来のロスベース輻輳制御（CUBIC等）に代わり、BDP（帯域幅×遅延の積）を維持しながらキューイング遅延を発生させないよう4モードで探索・推定するアルゴリズムとして解説された。PostgreSQLでは外部参照キーにデフォルトでインデックスが張られないという落とし穴が報告され、MySQLとの設計差異として親テーブルのDELETE/UPDATE時の整合性チェックで子テーブルのシーケンシャルスキャンが発生する問題が具体的に示された。Google Gemma 2ベースのTranslateGemmaは55言語対応・ローカル動作が強みだが英語への変換しかサポートしないという制限と固有名詞翻訳の弱さが検証で確認された。uLoopMCP（現Unity CLI Loop）を用いたAI駆動Unity開発では、Claude Code Plan Modeで仕様策定後に18スクリプトと全シーンを自律的に構築させた事例が報告された。

詳細

LT1: TCP BBR輻輳制御アルゴリズム（Google開発）

• 従来のロスベース制御（CUBIC等）の問題: パケットロス発生までデータを送り続け、バッファブロート（キューイング遅延）が発生
• BBRの目標: バッファを空にして遅延最小 + 送信レートをボトルネックリンク帯域幅に保つ
• BDP（Bandwidth-Delay Product）: 帯域幅と遅延の積をネットワーク中のデータ量の目標値として使用
• ジレンマ: 帯域幅と遅延を同時に正確に測定できない（帯域幅計測のために送信量を増やすと遅延が発生）
• 4モード: STARTUP / DRAIN / PROBE_BW / PROBE_RTT を行き来してネットワーク状況を探索・推定

LT2: PostgreSQLの外部参照キーとインデックスの罠

• MySQL: 外部キー制約作成時にインデックスを自動生成
• PostgreSQL: 外部参照キーにデフォルトでインデックスは作成されない
• 問題: 親テーブルのDELETE / UPDATEで参照整合性チェック時に子テーブルをシーケンシャルスキャン → データ量増加時にパフォーマンス劣化
• 推奨: 基本的に外部参照キーにはインデックスを張る
• 例外: データ量が少ない、検索されない、更新頻度が高い場合は個別検討

LT3: TranslateGemma（Gemma 2ベースの翻訳特化LLM）の検証

• 強み: 55言語対応（サポテク語などマイナー言語を含む）、ローカル動作、データが外部に出ない
• 制限: 基本的に英語への変換のみ対応（日本語に直接変換不可、英語を中継する必要あり）
• 検証結果: 英日間の一般翻訳は問題ないが、固有名詞翻訳に弱い（例：「虎の穴」→「虎の姉」）、マイナー言語の精度はまだ低い
• 評価: 単純翻訳用途ではChatGPT等に劣る

LT4: uLoopMCP × Claude Code によるUnityゲーム開発

• Unity EditorをMCP経由でAIに直接操作させるuLoopMCPを使用
• 作業範囲の自動化: コンパイル、エラー検出、ヒエラルキー把握、スクリーンショット撮影、テスト実行
• 実績: ブロック崩しゲームのプランニング〜実装まで、18スクリプトと全シーンを自律構築
• 2D版完成後に3D版へ移行もスムーズに完了
• 人間の役割: プロンプト指示出し、バグ修正・バランス調整・方向性決定に集中