寸法の JSON 1 つから、3D の Web と縦の短い動画まで。継手のショートを仕組みで作る

元大工の私が、日本の木の継手を 3D で回して、ばらして、寸法を変えて見られる Web を作り、同じ寸法から縦の短い動画を毎日書き出している。この記事では、その流れを Claude Code とどう組んだか、どこで壊れ、何を直したかを書く。継手の刻み方や寸法表は書かない。題材は形を見せる仕組みのほうである。

作りたかったもの

継手は、組むと外から見えない。写真や図では、どこがどう噛み合って、なぜ抜けないのかが伝わりにくい。3D なら、ばらして、組んで、抜こうとして止まるところまで見せられる。そこで、継手 1 種ごとに 3D のモデルを用意し、Web ではその場で回して寸法も動かせるようにし、同じものを縦動画にして YouTube と Instagram に出すことにした。

動画は手で作ると 1 本ごとに数時間かかる。毎日出すつもりなので、1 本ずつ編集ソフトで組む方法は最初から外した。形、台本、声、字幕、書き出しを、すべてファイルから機械的に作る方向で考えた。

寸法の JSON が正になる

継手 1 種は、寸法を書いた JSON ファイル 1 つで定義している。Blender の Python も、ブラウザの TypeScript も、同じファイルを読む。コピーは作らない。

{
  "id": "aigaki",
  "name": "相欠き継ぎ",
  "reading": "あいがきつぎ",
  "status": "published",
  "params": { "W": { "value": 0.105, "note": "..." } },
  "pieces": { "A": { "label": "上木" }, "B": { "label": "下木" } },
  "regions": [ ... ],
  "steps": [ ... ],
  "editable": [ ... ],
  "i18n": { ... }
}

形は直方体や円柱の「区画」を重ねて作る。部材 1 つは、自分が持ち主の区画から、あとに置かれた他の部材の区画を引いたものを足し合わせたものと決めた。重なる部分は後から置いたほうが勝つので、欠き取りは区画を重ねるだけで書ける。steps はばらす順序、editable は Web のつまみで動かしてよい寸法の範囲と刻み、i18n は日英の名前と説明である。

形を作ったあとは、5 つの検査を自動で回す。どれも数値で判定する。

最初に作ったのは Blender 側の仕組みと、iPhone の AR アプリである。そのあと Web を先に出す順に組み直し、AR の版は Web のあとに回した。

Web はブラウザの中で形を作り直す

Web では、つまみを動かすたびに、ブラウザの中で形を作り直している。ブール演算（足す・引く・重なりを取る）には manifold-3d という WebAssembly のライブラリを使い、表示は three.js にした。計算は Web Worker に載せて、画面を止めない。Blender の Python で書いた形の組み立てと検査を、TypeScript に移した形になる。

移した計算が元と同じ結果を返すかは、Blender が書き出した照合用の数字と比べて確かめた。部材の体積の差が 1e-9 立方メートル未満という基準で、これを試験に入れている。

つまみで寸法を動かすと、C1、C2、C4、C5 が操作中に走り、成り立たない寸法になると赤くなって理由が出る。C3 だけは重いので、つまみを離したときに走らせる。設計のときの試算では、形の作り直しが 1 ミリ秒ほど、C3 が 60 ミリ秒ほどだった。この赤くなる場面が、そのまま動画の見せ場にもなる。

動画も JSON から作る

動画は Remotion で作った。React でこまを書く動画の道具で、1 こまずつヘッドレスのブラウザで描くので、こま落ちが起きない。3D の絵は Web の描画をそのまま使い、形の計算は先に Node で済ませて JSON にしてある。

動画 1 本は、場面ファイルから作る。場面ごとに、ナレーションの文、画面の文字、見る角度、何を動かすかを書く。そこから台本を組み、声を合成し、書き出す。

tsugite probe <継手>      # 視点の見本を 1 枚に並べる
tsugite meshes <継手>     # 形（寸法を変えた版も）を JSON に
tsugite script <台本>     # 声の長さを測って場面の時刻を決める
tsugite voicecheck        # 日本語の声の読みを辞書と照らす
tsugite draft <台本> ja   # 小さい絵で通しを書き出し、1 秒おきの一覧を出す
tsugite render <台本> en  # 本番の書き出し（音量は -14 LUFS）

声は合成で、英語は Kokoro の男性の声、日本語は AivisSpeech の TANAKA を 1.1 倍にして使っている。音量は ffmpeg の loudnorm で -14 LUFS にそろえる。画面の日本語はすべてルビつきで、辞書に無い字があれば検査が止まる。BGM は規約でクレジット不要・商用可と確かめたものだけにした。

英語版は YouTube、日本語版は Instagram に出す。同じ台本から英日 2 本を作り、アカウントごとに言語を分けている。この道具の一式は tsugite-kit というプラグインにまとめ、手順は SKILL.md に書いた。AI への手順の渡し方は AI に指示ではなく環境を渡すようになるまで に書いたのと同じ考え方である。

最初の撮り方の型を捨てた

最初に作った型は、組んだ角材から始まり、ゆっくり回り続けながら、光らせた所へ自動で寄るものだった。最初の型で何本か作ったところで、私は X で見た Claude 製の動画との間に、言葉にできない差を感じた。質感を足す、見せ場を作る、効果音を足す、と試したが、どれも違った。

実際に Claude 製の動画 6 本を落として、こまの単位で見ると、違いは質感でも場所でもなかった。追掛け大栓継ぎの 1 本を数えると、45 秒のうち 22 秒が、ほぼ動いていないこまだった。場面ごとに組んだ形に戻るので、3D の絵が付いたスライドを順にめくっているのと変わらない。しかも、継手は組むと中が見えないのに、組んだ角材から始めるので、中の形が見えるのは 15 秒め以降になる。Instagram の平均視聴は、最初の 3 本で 13.7 秒、15.3 秒、21.6 秒だった。長さが 40 秒を超える動画で、この秒数である。

なお、この原因の最初の見立ては外れていた。動画を再生せず、最初のこまと説明文だけを見て、場所や重さが無いせいだと書いたのである。動画は実際に再生して、こまの一覧にして見なければ分からなかった。

直した型は、私が試作を見て指摘した 3 点でできている。

• 回し続けない。情報の無いこまが増える
• 寄りを続けない。全体が見える場面を挟む
• 全体を見せるときは、最初の場面と同じ、斜め手前から煽る角度にする

そこで、場面ごとに「何を見せるか」で視点を決め、文ごとに切り替える型にした。開いた継手から始め、組むのは 1 回だけ、寄りは 1 本に 1 〜 2 場面までと決めた。場面ファイルには視点を名前で書く。

"shots": [
  { "at": 0,     "from": "side-wide", "to": "side-wide" },
  { "at": "47%", "from": "front-low", "to": "front-low-near" }
]

視点の名前と、その中身である方位・仰角・距離は、1 か所の表にだけ持つ。試作で測ると、ほぼ動かない秒は 45 秒中 22 秒から、37 秒中 1 秒になった。角度の決め方が人の目に頼るので、1 本あたりの手間は増えた。1 本につき、小さい絵の下見を 1 〜 3 回回して、1 秒おきの一覧を見ながら直す。この型で数字が良くなるかは、出したあとの平均視聴と最後まで見られた割合で見るしかなく、書いた時点ではまだ分かっていない。

声の読みは、字幕とは別に確かめる

日本語の字幕にはルビを振る。そのルビの辞書は Web の画面と共有している。ある日、公開予定の動画に「三手（みて）」「かぎ形（かたち）」というふりがなが付いていた。見つけたのは私で、全部を書き出して確かめると、ほかにも「四手（よて）」「重さ（かささ）」「直角（なおかく）」が出た。

原因は、検査が「辞書に無い漢字が無いか」しか見ていなかったことと、1 字の読みが別の語の中でも使われたことだった。辞書の読みを直し、誤った 6 語を試験に足し、動画と Web の文を読みごと書き出して目で通した。

直したつもりだったが、続けて、比べる型の試作を聞いて「曲げ」が「きょくげ」と読まれているのに気づいた。字幕は直したが、ナレーションは画面に出ないので、検査の外にあった。AivisSpeech が実際に読む仮名を取り出して、辞書の読みと照らす検査を作ったところ、全台本で 15 行の読み違いが出た。

読み違える語は、合成の前に仮名へ置き換える表に入れた。表を空にすると、15 行が赤に戻ることも確かめた。画面の文と声の文は、別のものとして検査する必要があった。

向きを 90° 間違えて、指摘された

いちばん痛かったのは、形そのものの誤りである。追掛け大栓継ぎと金輪継ぎの 2 種を、材の長さの軸のまわりに 90° 回った向きで作っていた。形の寸法は図面で確かめていたが、どの面が上かは、図を見た印象で決めていた。確認の段でも、向きは問いに入っていなかった。

その 2 種を使った動画を出したところ、Instagram に、栓の向きが違う、荷重の向きが違う、という指摘が付いた。いいねが 14 件ついたものもあった。指摘を読んで、何を言われているかはすぐに分かったし、間違っていることにも自分で気づいた。大工の目で見れば分かる誤りだった。それでも出してしまったのは、最初期に上げた動画で、仕組みを回すことと、コンテンツとしての出来ばかりに目が行き、中身が正しいかを見ていなかったからである。試験体の図面、研究報告、現場の記録、標準の納まり図など、独立した資料で向きを確かめ直し、3D を作り直した。古い動画は非公開とアーカイブにして、何も言わずに出し直す扱いにした。作り直しの途中でも、資料の読み違えを 2 回している。試験の目的が違う図を、向きの根拠に数えたのである。

この件のあとで、手順に 1 段を足した。動画ができたら、作った本人ではないサブエージェントに、形の向き、栓の向き、組む向き、名前と読み、説明の中身を、独立した資料 2 件以上で確かめさせる。作ったセッションの結論は渡さない。返ってくるのは、主張・判定・根拠・直し方を並べた表だけで、食い違いが 1 つでもあれば直して最初からやり直す。通っていない動画は私に見せない。まだ出していない 20 本は、6 体のサブエージェントに分けて確かめ直させた。

作った本人の確認では思い込みが残る。それは AI が作っても、私が作っても同じだった。仕組みが回り始めると、目は速さと出来に向き、中身の正しさを確かめる段が抜け落ちる。この件で、ファクトチェックを後から足すものではなく、作る流れの 1 段として置くことにし、確認する役を作る役から切り離した。

このほか、書き出した動画を Google 系の別の AI にそのまま見せる段もある。1 秒おきのこま一覧では、音も動きも間も分からないためである。ナレーションの書き起こしを台本と 1 文ずつ照らし、見づらい場面や音の割れを指摘させている。

数えてみた数字

書いた時点の実物で数えた。

Instagram では、渡り腮、大入れ蟻掛け、腰掛け鎌継ぎが、1 万回を超えて見られた。YouTube は 1 本だけが 1,000 回を超え、ほかは 200 回に届いていない。同じ台本でも、言語と置き場で伸び方がこれだけ違う。動画を続けるかどうかは、開始から 3 か月でどちらかのフォロワーが 300 に届くかで決めてある。

採らなかったもの

• 完全な自動量産は採らなかった。同じ型を大量に出す動画は、YouTube が収益化から外す方針を出している。一言は、その継手の何が驚きか、なぜ見続けたくなるかを、中身から考えて毎回変える。「〜ではなく」のような決まった言い回しには寄せない。AI が下書きし、私が直す
• 動画編集ソフトで 1 本ずつ組む方法は、毎日は続かない。型は固めても、中身は場面ファイルで毎回変える

いまも残る手間

1 本作るのに、まだ人の確認が要る。場面の文と一言の案を私が見て、できた動画を私が見て、1 本ずつ承認を出す。投稿はスマホから手で上げる。Instagram は予約できないので、公開日に手で出す。検査と手順を増やすほど、作る側の手間は減ったが、確かめる側の手間は残った。

書き出しは、計画書に書いた見込みでは 1 言語で 7 分ほどで、下見が 2 分ほどである。1 本を作る全体の時間は、測っていない。

次に見るのは、新しい撮り方で作った動画が、平均視聴と最後まで見られた割合をどれだけ動かすかである。同じ継手を 2 つの型で出して比べることはできないので、切り替えたあとの数本の平均で見ることになる。