📚 すべての記事
全 102 件 ／ 3 ページ目（全 9 ページ）
クロスファミリー検証の最終型 —「正しく作る」から「自分で正しさを測り直す」へ【終章】
ステアリング駆動開発（応用編）の本編終章。検証を強制するハーネスに欠けていた「計測」の層を、独立に同じ思想へ到達していた個人開発ハーネスとの相互レビューから取り込む。finding-level 台帳・モデルドリフト検知・実痛駆動の剪定 —「完成」とは終わることではなく、自分の劣化を自分のデータで検出するループが閉じることである。
Claude Code の中から Codex を動かす — MCP を使わない判断と sandbox の地雷【クロスファミリー検証 第5回】
クロスファミリー検証で最も泥臭かった実装の記録。MCP でなく codex exec + シェルを選んだ積極的理由、Dev Container で bwrap sandbox を成立させる 3 条件、「sandbox 全滅でも exit 0」という最大の地雷、sudo で逆に壊れる罠、そして運用判断を埋め込んだ exit code 意味論まで。
Fable 5・Sonnet 5・Opus 4.8 の使い分けと golden set 実測 —「買うか、組むか」【クロスファミリー検証 第6回・最終回】
クロスファミリー検証パイプラインのモデル戦略編。Claude 5 ファミリー（Fable 5 / Sonnet 5）と Opus 4.8 のティア割当、effort 運用（xhigh 下限の構造的保証）、Fable 5 をサブエージェントに使わない理由、golden set v1 の自環境実測、承認と実証の分離、Sakana Fugu 時代の「買うか組むか」の判断軸で締める。
マルチ LLM オーケストレーションの台頭とクロスファミリー検証 — Sakana Fugu から Codex×Claude まで【シリーズ総論】
複数の AI モデルを束ねる動きが 2026 年に一気に加速した。Sakana Fugu のような「学習されたオーケストレーション」製品の登場と、Codex×Claude のクロスファミリー検証運用。マルチ LLM の 2 つの系統（オーケストラ型とチェック・アンド・バランス型)を整理し、実プロジェクトで標準運用に至った全 6 回シリーズの見取り図を示す。
「Codex 実装 → Claude レビュー」+18.1pt 論文を裏取りする — 両者のレビューは何が違うのか【クロスファミリー検証 第2回】
「Codex 実装 → Claude レビューが最良（+18.1pt）、逆方向は有害（−8.6pt）」という KDD '26 論文の数値を一次ソースで照合し、桁まで一致することを確認した記録。Claude と Codex のレビュー観の違い（自己検証の重さ・high-recall と precision・自己レビューの非対称）を、論文と自環境実測の両面から整理する。
指示書からパイプラインへ — finder/verifier 分業・二層の網・逆順の構造的禁止【クロスファミリー検証 第3回】
「Codex 実装 → Claude レビュー」を実運用に落とす設計編。4 つの原則、役割分担、TDD+DDD ワークフロー、コンテキストエンジニアリング規約、決定論ゲート＋特性化テスト＋golden set の防御網、Definition of Done、そして汎用指示書を自プロジェクトに翻案するときに変えた点・変えなかった点を全て記す。
Red テストは verifier 家族の資産 — テスト改ざんガード・レビュー漏れの機械クローズ・自己評価遮蔽【クロスファミリー検証 第4回】
クロスファミリー検証の威力を底上げする、見落とされがちな層 — ハーネスとステアリング。TDD の Red テストを Claude（verifier 家族）の資産として Codex から checksum で機械保護し、レビュー漏れを三層ゲートで構造的に塞ぎ、handoff から実装者の自己評価を遮蔽する設計を詳解する。
Atomic Design リファクタ編 — 47 page を「新規移植アプローチ」で 5 日で分離し、負債 43,500 行を消すまで【実践編 第5章】
動いているフロントエンド 45+ page を Smart/Dumb 分離へ移行した実録。「既存をリファクタしない。退避 → generator → 写経で新規に作る」アプローチで工数 40% 削減、legacy 約 43,500 行削除・正味 −12,000 行。完了基準を grep 機械検証 9 ゲートで固定し、State 二重保持や as unknown as キャストなど移植で得た教訓まで全て公開する。
DDD/SOLID/BC 編 — god class 1,545 行の解体と「allowlist で逃がすな」【実践編 第3章】
本番前の .NET バックエンド総リファクタの実録。互換コードを一切残さない決断、god class 5 件を「200 行物理ゲート + Coordinator/Strategy」で解体、旧テスト 4,564 行の削除、BC 越境を Read 専用 Port で断ち切り default-deny の越境テストで固定するまで。オーナーの一言「allowlist で逃がすな」が設計を変えた瞬間と、実践編全体を貫く 4 つの型を宣言する。
パフォーマンス編 — 「数えるだけ」が 52.7 秒かかり SAGA を止めた。そして最適化が障害の元凶になった【実践編 第9章】
件数カウントが全件マテリアライズで statement_timeout を踏み、リトライ経由で SAGA 全体を止めた障害の解剖（COUNT 化で 500 倍改善）。5 属性完全一致キャッシュをコサイン類似度キャッシュ（閾値 0.95・pgvector）へ刷新した設計と、その最適化が後に「Create Chunk 重量化の元凶」と名指しされ契約 C-1/C-8 で正しい置き場所に戻されるまで — 性能改善も、アーキテクチャ契約の中でやる。