設計をコードで書かせて、確認まで機械に回させる

3Dプリント用の形をコードで書く方法には、他の設計手法にない性質がひとつある。設計がテキストであるということだ。テキストなら、機械が書けるし、機械が読める。差分も取れるし、履歴も残る。AI に設計させる話をするとき、この形式が最も相性がよいのは当然と言えば当然である。

ただし、ここまでは以前から言われてきたことだ。実際にやってみると、人が横で見ていないと進まないという壁に当たる。生成されたコードを自分で実行し、出てきた形を目で見て、寸法を測り、直してもらう。この往復を人が仲介している限り、速くなるのは一行を書く時間だけで、工程全体は人の手番の数で決まってしまう。

コードCAD 自動化という言葉が指すべきなのは、この仲介を外すところである。本記事では、人が見ていないループを回すために何が要るのかを整理する。なお 当サイトは以下の構成を実際に組んでおらず、動作を確認していない。書くのは、開発元が公開している挙動と、ループを成立させるための一般的な条件である。確認はすべて2026年9月6日時点のものだ。

対話で書くことと、ループを回すことは別物である

先に境界を引いておく。人が AI と対話しながらコードで設計を書く方法、つまり指示を出し、出てきたコードを読み、直してもらうという進め方についてはOpenSCAD × LLM 実践 2026 — コードCADを ChatGPT・Claude と書く（2026-07-18 公開）で扱った。立体を足し引きで組み立てる考え方、指示の書き方、変数の設計といった土台はそちらにある。

本記事が扱うのは、その先である。人が読まない前提で、生成と検証を機械が繰り返す構成をどう作るか。必要になるものが根本的に違うので、同じ話の続きではなく別の設計課題として扱ったほうがよい。

違いを一言でいえば、対話では人の目が合否の判定器になっている。形を見て「太い」「入らない」と判断しているのは人である。ループを回すなら、この判定器を機械が読める形で用意しなければならない。

コードCAD のループが回るために本当に要るもの

生成する側の能力は、この構成では主役ではない。主役は合否をどう判定するかである。

判定が用意できないループは、回っているように見えて何も収束しない。生成されたコードが実行できるかどうかしか見ていなければ、実行はできるが寸法が違う形が延々と出てくる。逆に、判定さえ用意できれば、生成の側が多少ぶれても、ぶれた分は次の周回で削られていく。

したがって、着手の順序は次のようになる。先に判定を書き、後から生成させる。この順序は、テスト駆動でプログラムを書くときの考え方とほぼ同じで、理由も同じである。何をもって正しいとするかを決めないまま作り始めると、正しさの基準が作ったものに引きずられる。

設計の場合、この引きずられ方は具体的な形で現れる。生成された形を見てから「まあこれでいいか」と基準を緩めると、次の周回ではその緩めた基準が正解になる。何周か回したあとには、当初の要求とかけ離れたものが「合格」として出てくる。人が見ていないループでは、この漂流に気づく機会がない。

もうひとつ、判定を先に書くことには副次的な効果もある。自分が何を要求しているのかがはっきりするという効果だ。穴の径を書き出そうとして、そもそも何ミリのネジを通すのか決めていなかったことに気づく。設計の曖昧さは、判定を書く段階で炙り出される。ループを組まないと決めた場合でも、この作業自体には価値がある。

何を合否の判定に使えるか

コードCAD で書かれた設計には、機械が読める出力がいくつかある。

上の3つは軽く、下にいくほど重い。実務では、軽い判定から順に並べて、落ちたら次に進まない構成が効率がよい。構文で落ちるものを寸法まで測っても時間の無駄だからだ。

ここで注意したいのは、寸法の判定は自分で書くしかないということである。穴の直径が公差の範囲に入っているか、板の厚みが最低肉厚を下回っていないか、といった条件は、作るものごとに違う。汎用の判定は存在しない。ループを組む労力の大半は、ここに集まる。

判定の作り方には、ひとつ実用的な工夫がある。合格の条件ではなく、不合格の条件を書くという方針だ。「正しい形」を定義しようとすると際限がないが、「これが起きていたら間違い」なら列挙できる。板が薄すぎる、穴が縁に近すぎる、部品同士が干渉している、体積が想定の桁を外れている。こうした条件は数が有限で、しかも一度書けば他の設計にも使い回せる。

もうひとつ、判定は数値で返させるほうが後で効く。合否だけを返す判定は、落ちたときに「どれだけ足りないか」が分からない。0.05ミリ足りないのか2ミリ足りないのかで、次に打つ手はまるで違う。差の大きさが返ってくれば、次の周回で修正すべき方向まで機械に伝えられる。

印刷できるかどうかは、判定で拾いきれない部分が残る

判定を並べていくと、どうしても機械に渡しきれない領域が残る。印刷できる形かどうかの判断である。

寸法や体積は数値なので判定に載せられる。ところが、サポートなしで架かるかどうか、積層方向に対して荷重がどう入るか、反りやすい形状かどうかといった条件は、形そのものだけでは決まらない。使う材料、機械の状態、ノズルの径、室温。同じ形でも条件が変われば結果が変わる。

したがって、ループが出してくるのは寸法として正しい形までである。それが実際に印刷できて、使用に耐えるかどうかは別の工程で確かめることになる。ここを混同すると、判定を全部通ったのに一枚も使えない、という結果になりかねない。

現実的な運用は、判定の網を「明らかに駄目なものを落とす」目的に絞ることだ。通ったものが良いのではなく、落ちたものが悪いと考える。網の目を細かくしていくより、落ちたものを一件ずつ見て網を足すほうが、結果的に早く育つ。

検証を書くほうが、本体を書くより難しいことがある

正直に書いておくと、この構成の面倒さは判定の側に偏っている。

形を作るコードは、うまくいけば数十行で済む。ところが「この形が正しい」を機械が読める形で表現しようとすると、何をもって正しいとするのかを全部言語化しなければならない。穴の位置、はめあいの隙間、逃げの有無、積層方向に対する荷重の向き。人が目で見て一瞬で判断していたことを、条件として書き下す作業になる。

だから、この構成が向くのは同じ種類のものを何度も作る場合に限られる。一点物を作るなら、判定を書く時間で自分で設計したほうが速い。逆に、寸法違いを何十個も作る、条件を変えて比較する、パラメータを振って最適な値を探す、といった用途では、最初に払った労力が回収される。

判断の目安としては、3回以上同じ検証を繰り返すなら書く価値があるあたりが妥当なところだろう。これは経験則であって、測った値ではない。

質問してくる相手と、どう組むか

ここで、今回のモデルの挙動が関わってくる。

開発元によれば、指示に解釈の余地があるとき、文脈から埋められる部分は自分で埋め、結果が変わりうる場合にだけ質問するという挙動になっているという。何でも聞き返してくるわけでも、黙って進むわけでもない、という設計である。

ループを回す立場から見ると、この挙動には両面がある。都合がよいのは、些細な選択でいちいち止まらないことだ。面取りの寸法を指定し忘れた程度のことで人を待つ構成では、無人で回す意味がない。都合が悪いのは、質問が来た地点で止まりうることである。夜間に走らせているつもりのループが、朝に見たら質問のまま止まっている、という事態はありうる。

返事をしないと、どう振る舞うのか

この点については、開発元がさらに踏み込んで書いている。

コード作業を扱う環境では、返答を待たずに進められる作業を続けながら、非同期に質問できるとされている。そして返答がない場合、妥当な仮定を置いて進める場面では進み、影響の大きい判断については待つという。

つまり、止まる箇所は「重要な分かれ道」に絞られる設計になっている。無人で回す構成にとっては望ましい方向だが、裏を返せば、止まったということは重要な判断が残っているということでもある。翌朝に止まっているのを見つけたとき、それは失敗ではなく、判断を求められている状態だと解釈したほうがよい。

運用上の対処は、前もって決めておくことに尽きる。どこまでを仮定で進めてよいか、どこからは必ず人に聞くか。この線を指示の中に書いておけば、止まる場所を自分で選べる。

文脈が尽きたときに、何が失われるか

長いループを回すと、必ず文脈の限界に当たる。従来のやり方では、それまでのやりとりを要約して圧縮し、続きを進めていた。

この方式の弱点を、開発元自身が説明している。圧縮のたびに、なぜその修正が失敗したのか、ある部分がどう振る舞うのかといった細部が落ちうる、というものだ。設計のループでこれは痛い。「この値では薄すぎて割れる」と一度分かったことが、要約から抜けると、数周後に同じ値がまた出てくる。

今回のモデルでは、圧縮のかわりに文脈をまたいでノートを残す方式が導入されたとされている。加えて、前の文脈も検索できるので、ノートに書き残していない情報でも後から探せるという。

実験的な機能を前提に組まない

ただし、この方式には条件がついている。現時点では実験的な機能であり、設定ファイルで有効にする必要がある。開発元は、数週間のうちに既定になる予定だと書いている。

「予定」である以上、これを前提にした構成を今組むのは早い。実験的な機能が既定になるまでの間に、挙動も設定名も変わりうる。変わりうるものの上に自動化を積むと、変わったときに全部を作り直すことになる。

現実的な折衷案としては、ループの一周を短くしておくことだ。一周が短ければ、文脈が尽きる前に区切りがつく。長い設計を一気に回すのではなく、部品ごとに分けて回す。工程を細かく切るのは、この種の制約に対する古典的で確実な対処である。

失敗の履歴は、自分の側にも残す

文脈の中で何が保たれるかは、こちらから制御できない部分がある。だとすれば、失われて困るものは自分の側に書き出しておくのが確実だ。

設計のループで最も価値があるのは、成功したコードではなく失敗した条件の記録である。この値では薄くて割れる、この向きでは印刷できない、この隙間ではきつくて入らない。こうした知見は、そのまま次の設計の判定に使える。逆に、記録せずに捨てていると、同じ失敗を繰り返す。

具体的には、周回ごとに「試した値」と「落ちた理由」を一行ずつ残す形で足りる。凝った仕組みは要らない。重要なのは、ループの外に残ることである。文脈の中だけに存在する知見は、文脈が切れた時点で消える。

この記録には、もうひとつ使い道がある。判定を書き足す材料になることだ。ループを回していると、判定をすり抜けたのに実際には使えない形が必ず出てくる。そのたびに「なぜ通ってしまったのか」を考えて、判定を一本足す。判定は最初に完成させるものではなく、育てるものである。

コーディングの数字をどう読むか

生成能力の側の数字も見ておく。発表本文の表から転記する。

FrontierCode の行には脚注がついている。実行時に、コード作業の環境で使われている開発者向けの指示に近い内容を与えたというものだ。ベンチマーク向けに最適化した指示ではないと明記されている。条件が書かれているのは誠実だが、条件があること自体は覚えておきたい。

差が小さい行を「圧倒」と読まない

上の表で目立つのは Terminal-Bench 4.0 の 57.9% と 37.3% だが、同じ表の DeepSWE では 74.1% と 72.7% で、他社の 73.8% とも一点台の差しかない。

こういう表を見たとき、差が大きい行だけを取り上げれば「圧倒的」と書けるし、差が小さい行だけを取り上げれば「横並び」と書ける。どちらも表の一部を切り出しただけである。

実務的な結論は退屈なものになる。課題の種類によって差の大きさが違うので、自分の用途に近い課題の行を見るしかない。そして、コードで設計を書く作業に近いベンチマークが、この表の中にあるとは限らない。数字はあくまで参考であり、最終的には自分の題材で確かめることになる。

版が動く前提で書いておく

もうひとつ、実務的な注意がある。周辺の道具は頻繁に更新される。

公開後の2日間だけを見ても、コード作業用の道具は4回更新されている。API 経由での設定に対応し、速度の階層の説明を修正し、別のクラウド経由の選択肢を追加し、既定のモデルの扱いを直している。このうち速度の階層の説明については、当初「1.5倍」と書かれていたものが「2倍」に訂正された。開発元自身が一度誤記していたわけだ。

ここから引き出せる教訓はふたつある。ひとつは、版番号を書くなら確認日を添えること。もうひとつは、公開直後の情報は訂正されうるという前提を持っておくことである。とくに数字は、後から静かに直ることがある。

自動化を組む立場からは、もう少し実務的な含意もある。道具が2日で4回変わる環境では、道具の細かい挙動に依存した作りが壊れやすい。設定ファイルの項目名、既定のモデル、選択肢の並び。こうしたものに寄りかかった構成は、更新のたびに手直しが要る。逆に、入力と出力の形式さえ決めておけば、間の道具が変わっても組み替えが利く。

回す回数を、どこで止めるか

最後に、ループを組むときに必ず決めなければならないことがある。いつやめるかである。

判定が通れば止まる、という設計は自然に見えるが、通らなかった場合の扱いが抜けている。判定が厳しすぎれば永遠に通らないし、生成の側が同じ誤りを繰り返すこともある。人が見ていないのだから、止める条件は先に決めておくしかない。

止め方には三通りある。周回数で切るのが最も単純で、10周やって通らなければ人に戻す、という形になる。改善幅で切る方法もあり、判定の差が前の周回から縮まらなくなったら止める。そして費用で切る方法もある。ここまで使ったら止める、という上限を先に置く。

3つめが軽視されがちだが、実際には最も効く。ループは回した回数だけ請求が立つ。しかも、通らないときほど回数が伸びるという性質がある。うまくいかない設計ほど費用がかさむわけで、放っておくと最も価値の低い作業に最も金を使うことになる。

この性質は、自動化を始めるときに見落とされやすい。人が手で回している間は、面倒になった時点で自然に止まる。人の忍耐が上限として働いていたわけだ。その上限を外したなら、代わりの上限を自分で置く必要がある。

当サイトが確認していないこと

範囲を明示しておく。特定のコードCAD 環境で、このループが実際に回るかどうかは確認していない。開発元の文書は、コード作業一般についての挙動を述べたもので、立体を扱う特定のソフトについて述べたものではない。

したがって本記事は、ループを組むために何が必要かという一般的な条件と、開発元が公開した挙動を突き合わせたものである。具体的なソフト名を挙げて「うまくいく」と書くことはしていない。

また、生成された形の妥当性を機械が判定する方法についても、当サイトで実装したものはない。判定に何を使えるかという一覧は、それぞれの出力から原理的に読み取れることを整理したものである。

まとめ

コードCAD で設計を書かせ、機械に確認まで回させるとき、成否を分けるのは生成の能力ではない。

1. 合否の判定を先に用意する。判定のないループは収束しない
2. 軽い判定から順に並べる。構文で落ちるものを寸法まで測らない
3. 止まる場所を自分で決めておく。仮定で進めてよい範囲を指示に書く
4. 一周を短くする。文脈の制約にも、機能の変更にも強くなる
5. 同じ検証を3回以上繰り返すなら書く価値がある。一点物なら自分で設計したほうが速い

写真から輪郭を取り、手持ちの工具に合う受けを作る方法は工具の形に合わせた受けを写真から作る — AIに輪郭を取らせる治具設計（2026-09-04 公開）にまとめてある。あちらは形の入力を機械に任せる話で、本記事は検証を機械に任せる話にあたる。入口と出口の両側から、人が手を動かす範囲を削っていく構図になる。

残る論点は費用である。ループは回した回数だけ請求が立つ。回数を増やすほど良い結果に近づく構成では、どこで止めるかが設計そのものになる。

出典・参考

• OpenAI「GPT-6 Astra: A new generation of intelligence」
• OpenAI「ChatGPT & Codex changelog」

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.