Claudeに吐かせた原始スライド（参考用）

VRChatの個人開発集会で下書きとしてClaudeに吐いてもらった奴

Transcript

1. 個人開発集会 / 30分枠 [図 プレースホルダー ] Waterman Cometh タイトル用ビジュアル （水を運ぶ人 / 治水のモ チーフ、任意） Research → Spec → Oracle で Unity 開発を回してみた話 Unity 個人開発「ShapeSync」で、LLM エージェントを「速いコーダー」ではなく「開発チーム」として運用した記録 完成した方法論の宣伝ではありません。効いた範囲と弱点をそのまま話します。 発表者: zgock / 2026-xx-xx / ※ロゴ等の商標画像は使用していません
2. 02 題材の説明は最小限に 目安 1.5分 ShapeSync とは何か — 題材 Unity 用のキャラクター体型・衣装同期アセット（個人開 発） — 扱うもの Mesh / BlendShape / bindpose / Humanoid Avatar / Material / Texture — 厄介さ Editor と Runtime、生成物の所有権、非破壊性が絡 み合う [スクショ プレースホルダー ] ShapeSync の実行結果スクリーンショット （Figure + Outfit が体型追従している画面） — 規模感 Spec1〜Spec19 まで積み上がった継続プロジェクト 「1機能1ファイル」では終わらない、契約が多い領域 → だから手順の話が意味を持つ Waterman Cometh — 実験的方法論としての報告 2 / 16
3. 03 出発点の失敗 目安 1.5分 なぜ従来の「実装して」では足りなかったか — 速いのは本当 コードは驚くほど速く出てくる。動くものも出る — 壊れるのは静かに 既存の所有権・非破壊契約が黙って緩む — レビューが破綻 差分は読めても「なぜこの設計か」が残らな い [図 プレースホルダー ] — 同じ矯正の反復 毎回プロンプトで直す。次のセッションで再 発する 図: 「実装して」ループ 指示 → 実装 → 気づく → 矯正 → 再発 （矯正が資産に還元されず消えていく様子） 問題は「モデルが下手」ではなく「矯正の置き場所が無い」ことだった Waterman Cometh — 実験的方法論としての報告 3 / 16
4. 04 設計したのではなく、堆積した 目安 1.0分 Waterman が生まれた経緯 — 最初 調査メモを別ファイルに切り出した（会話に置くと消え るから） — 次に 仕様を凍結してから実装させた（途中で仕様が揺れる から） [図 プレースホルダー ] — 次に 判定基準を先に書いた（レビューが感想になるから） — 結果 Research / Spec / Oracle という3つの文書層が残っ 図: 堆積の時系列 Spec9 → Spec13 → Spec17 → Spec18 （文書層が1つずつ増えていく帯グラフ） た 「ウォーターフォールの理想」だけを LLM前提で拾い直した仮呼称 = Waterman Waterman Cometh — 実験的方法論としての報告 4 / 16
5. 05 7段。ただし直線ではない 目安 2.5分 基本フロー Research Spec Implement IR Implement Self Review Oracle Test Human Test 調べる・反証する 凍結した要件 実装計画（中間表現） コードを書く 契約観点の自己審査 機械が判定できる正解 人間が見て決める ↑ 各段は「文書」として残る。会話は残らない。 — 戻る前提 Oracle が設計できない → Research へ戻す。実装で矛盾 → Spec へ戻す — 人間の役割 各段の採否を決めるディレクター。書くのは主にエージェント — 成果物主義 会話コンテキストではなく、リポジトリの文書が正となる 重要なのは順番ではなく「矯正をどの段へ還元するか」の判断 Waterman Cometh — 実験的方法論としての報告 5 / 16
6. 06 混ぜると両方死ぬ 目安 2.0分 Research と Spec の役割分離 Research Spec ・目的: 事実と反証を集める ・目的: 実装可能な要件に閉じる ・実装は禁止 ・凍結（Frozen）する ・「未確定事項」を明示的に残す ・未確定を残さない ・実測値・失敗例・却下案も保存 ・保護する既存契約を列挙する ・更新履歴が積み上がる生き物 ・凍結後の変更は差分として扱う Research に結論を書かせない / Spec に迷いを残さない。この一線だけで手戻りが減った Waterman Cometh — 実験的方法論としての報告 6 / 16
7. 07 レビューを感想から救い出す装置 目安 2.0分 Oracle とは何か — 定義 実装とは独立に「正しい出力」を機械が判定できる基準 — 例1 変換式を共有実装にして完全一致で比較する層 — 例2 入力を変形しても不変な性質を検査する層 [図 プレースホルダー ] （metamorphic） 図: Oracle の層構造 Layer1 入力検証 / Layer2 完全一致 / Layer3 誤差許 — 例3 画素比較のように誤差許容を明示する層 容 + metamorphic 検査 — 効能 「たぶん動いてる」を「この条件で一致した」に変換する （Spec18 Atlas の実例で置換） Oracle が設計できない課題は、まだ Spec にしてはいけない課題 Waterman Cometh — 実験的方法論としての報告 7 / 16
8. 08 Humanoid Compiler 目安 2.0分 ケーススタディ : Spec17 — 課題 n個の Renderer を1つに統合し、Runtime 依存のない 出力を作る — 性質 単一化された課題。Oracle が最初から見えていた [実測値 プレースホルダー ] — 進め方 前方 Research → Spec 凍結 → IR → 実装。戻りは Spec 差分で処理 実測値の表（後で差し替え） ・Research 所要 / Spec 所要 / 実装所要 ・Spec へ戻した回数 — 効いた点 「奪わない責務」を Spec に列挙したことで越境実 装が消えた ・Self Review 指摘数と種別 ・Oracle 検出バグ数 出力が一意に決まる課題では、前方 Research が最も効く Waterman Cometh — 実験的方法論としての報告 8 / 16
9. 09 文書だけで実装できるか 目安 2.0分 再現性試験 : Spec18 — 問い 会話コンテキストを持たないエージェントが、Research と Spec だけで実装できるか — 条件 口頭の前提・過去ログを渡さない。リポジトリの文書の み [ログ プレースホルダー ] — 見るもの 実装が始まるか / 契約を越えないか / 質問が要件 図 or ログ抜粋 コンテキスト無しエージェントの初動 の穴を指すか （最初に何を読み、何を質問したか） — 結果 （実測を後で差し替え）成功した範囲と、詰まった箇所 文書が正しく書けているかは、人間ではなく「文脈を持たない読者」が測ってくれる Waterman Cometh — 実験的方法論としての報告 9 / 16
10. 10 どこで時間が溶けているか 目安 1.0分 価値は「 30分でテトリス」ではない よく語られる価値 実際に効いた価値 ・30分でテトリスが動く ・1時間迷う裁定を5分にする ・ボイラープレートが一瞬 ・却下理由を後から掘り出せる ・書ける量が増える ・「どちらでもよい」を潰してくれる 個人開発のボトルネックはタイプ速度ではなく、決めきれない裁定の滞留だった Waterman Cometh — 実験的方法論としての報告 10 / 16
11. 11 使い分けが本題 目安 1.5分 前方 Research と後方 Research 前方 Research 後方 Research 実装の前に調べる 作ってから調べる ・課題が単一化されている ・複合課題で切り分けが不明 ・Oracle が見えている ・Oracle が未発見 ・出力の正解が定義できる ・まず挙動を観測したい ・→ Spec を凍結して一気に実装 ・→ Prototype / TDD で事実を作る 前方 Research は万能ではない。 Oracle が見えているかどうかが分岐点 Waterman Cometh — 実験的方法論としての報告 11 / 16
12. 12 優先順位ではなく成熟度 目安 1.0分 Spec X から番号付き Spec への昇格 Spec X まだ仕様問題として閉じていない研究 課題 ▶ 昇格の条件 責務境界が引ける / Oracle の見通し が立つ ▶ 番号付き Spec 凍結して実装に渡せる課題 — 誤解しやすい点 Spec X は「後回し」ではない。まだ問いが定まっていない状態 — 運用上の効能 「やらない」ではなく「まだ閉じていない」と言えるようになる 番号が付く = 責務境界と Oracle の見通しが立った、という宣言 Waterman Cometh — 実験的方法論としての報告 12 / 16
13. 13 対立させない 目安 1.0分 TDD / Prototype との使い分け 状況 取るべき手 理由 正解が定義できる Waterman（前方 Research） Oracle を先に置ける 正解が未発見 Prototype → 後方 Research 事実を作らないと定義できない 回帰を守りたい TDD / Oracle Test 境界を機械が見張る 複合課題 分解してから判定 分解できるまで Spec 化しない Waterman は TDD の置き換えではない。 Oracle という形で TDD を内側に含む Waterman Cometh — 実験的方法論としての報告 13 / 16
14. 14 ここを話さないと誇大宣伝になる 目安 2.0分 弱点 複合課題に弱い 責務が絡み合うと Spec が肥大し、凍結できない 文書作成コストが重い 小さな修正に対して手続きが過剰になる Oracle 設計が発散する 厳密さを求めるほど設計コストが実装を超える モデル利用上限に当たる 長文 Research / Spec は消費が大きく、進行が止まる 小さな課題に Waterman を適用すると、手続きだけが増えて遅くなる Waterman Cometh — 実験的方法論としての報告 14 / 16
15. 15 実験の中間報告として 目安 1.0分 現時点での結論 — 有効だった範囲 課題が単一化され、Oracle が見えている領域 — 向かない範囲 複合課題、Oracle 未発見、小さな修正 — 再現性 文脈を持たないエージェントが文書だけで動けた範囲までは再現した — 運用の芯 モデルの失敗をプロンプトで矯正せず、Research / Spec / Oracle へ還元する — 責任 採否と最終責任は人間のディレクターが持つ。委譲していない Waterman は魔法のハンマーではない。 ShapeSync では有効だった実験的方法論である Waterman Cometh — 実験的方法論としての報告 15 / 16
16. 16 目安 5分 質疑 Questions & Discussion 想定される論点 — 自分の領域では Oracle をどう定義するか — 文書コストが見合う規模の下限はどこか — チーム開発（複数人）へ持ち込めるか — モデル / ツールを変えても成立するか 関連文書: Docs/Waterman/ 以下 / ご意見・反証は歓迎します Waterman Cometh — 実験的方法論としての報告 16 / 16