なぜClaude Codeは幾何学設計に弱いのか。AIと専門ツールを使い分ける開発者必須のハイブリッド戦略

AIが描く「それっぽさ」と「正確さ」の深い溝

AIは万能ではない。特に幾何学的な正確さが求められる領域で、AIは脆さを露呈する。

Claude Codeでコードを書く際も、この限界に直面する。

「それっぽい」コードを出すのは得意だ。

だが、1ミリの狂いも許されない構造体を作るのは苦手だ。

この境界線を理解していないと、修正で数時間を溶かすことになる。

AIの弱点を逆手に取ったハイブリッドな開発戦略を解説する。

構造的精度を求めるAIの試行錯誤

画像からCADデータを予測したり、UIデザインをベクター化したりする試みが加速している。

単純な画像入力ではなく、STLファイルなどの3Dデータを入力し、レンダリングした上で構造を予測させるアプローチが登場した。

デザインツールの現場でも変化が起きている。

生成AI機能を活用して、プロンプトからイラストを生成し、ベクターパスに変換する機能が注目されている。

プロンプトに「isometric」や「flat design」といったキーワードを添え、背景を白に固定することで、後工程のベクター化精度を上げる手法が一般的だ。

しかし、AIが生成したベクターデータは、拡大すると線が歪んでいたり、不要なパスが大量に含まれていたりする。

特に、建物やデバイスのような直線的な幾何学オブジェクトにおいて、AIの精度は低い。

しんたろー：
AIが作ったベクターデータを見ると、パスがガタガタでアンカーポイントが100個ほど無駄に並んでいることが気になる。
これを直す手間を考えると、最初からペンツールを使ったほうが早いと感じる。
AIは有機的な形には強いが、数学的な正解にはまだ届いていない。

統計的予測と論理的制約の衝突

AIが幾何学に弱い理由は、その仕組みにある。

Claude Codeを含む現在のLLMや画像生成AIは、統計的なもっともらしさを予測しているに過ぎない。

次にくる単語や、隣り合うピクセルの色を確率的に選んでいる。

一方で、幾何学やCAD、厳密なUI設計は、論理的な制約と数学的なルールに基づいている。

「この線とこの線は完全に平行である」というルールは、統計的な予測とは相性が悪い。

ThreadPostのUIを組む際も、同じ現象が起きる。

複雑なグリッドレイアウトをClaude Codeに丸投げすると、パッと見は完璧なコードが出る。

しかし、ブラウザで確認すると、1ピクセルだけズレていたり、レスポンシブ時に構造が破綻したりする。

AIは構造の美しさを理解しているのではなく、構造っぽく見えるパターンを再現しているだけだ。

この統計と論理のギャップを埋めるのが、開発者の役割だ。

AIを万能な生成器として扱うのは避ける。

AIが得意な非定型な生成と、専門ツールが得意な定型・制約処理を明確に切り分ける。

複雑なキャラクターのイラストはAIに生成させ、それを配置する幾何学的なUI枠は、既存のツールやプラグインで作成する。

AIの出力を中間生成物として扱い、最後は人間が専門ツールで型に嵌めるワークフローが有効だ。

しんたろー：
AIに全部やらせようとすると失敗する。
最近はClaude Codeにはロジックの骨組みだけ書かせ、スタイリングの微調整は自分で行っている。
全部任せると、後でマージンが奇数になっていることに気づき修正する羽目になる。
AIは下書き担当としては優秀だが、清書担当としてはまだ信用できない。

開発者が構築すべきハイブリッドなパイプライン

これからの開発者には、AIと専門ツールを組み合わせるアーキテクチャ設計能力が求められる。

以下のハイブリッドなパイプラインを構築する。

* 非定型要素の生成: キャラクター、テクスチャ、文章はAIに任せる

* 構造的制約の適用: 幾何学図形、グリッド、寸法精度が必要なパーツは、専用プラグインやCADツールを使用する

* パーツ単位の処理: 全体を一気に生成させず、要素を分解してAIに処理させ、後で合成する

* 自動チェックツールの併用: AIが書いたコードに対して、Lintツールや型チェックを厳格に行う

Figmaでアイソメトリックなイラストを作る場合、AIに直接完成図を描かせるのではなく、パーツごとに生成させてから、Isometric Proのような専用プラグインで角度を揃えるほうが効率的だ。

AIが苦手な角度の計算や直線の維持をツールにオフロードする。

コーディングでも同様に、Claude Codeに複雑なアルゴリズムを書かせる際は、同時にそのコードを検証するためのユニットテストも生成させ、厳密な型定義を強制する。

ベクター化のプロセスにおいても工夫が必要だ。

AIが生成した画像をそのままベクター化するのではなく、一度パーツごとに切り分け、高画質化処理を挟んでからベクター化することで、パスの歪みを最小限に抑えられる。

AIで8割を作り、残りの2割を専門ツールと自分の手で仕上げる8:2の法則が、現在のAI活用における黄金比だ。

しんたろー：
1人で開発していると、この2割の仕上げがいかに重要か身に染みる。
AIが作ったコードをそのままデプロイするのは、ノーヘルでバイクに乗るようなものだ。
専門ツールをAIの暴走を止めるガードレールとして使う感覚を持つ。
これができるようになると、開発スピードは3倍、バグは半分になる。

実務への影響と具体的なアクションアイテム

このハイブリッド戦略を実務に取り入れる。

まず、AIの限界を数値で把握する。

自分のプロジェクトにおいて、AIが生成したコードの何パーセントがそのまま動いたか、デザインの修正にどれだけの時間を費やしたかを記録する。

事実と数字を直視することで、どこをAIに任せ、どこを自分でやるべきかの境界線が見えてくる。

次に、専門ツールの再評価を行う。

AIが進化するほど、既存のプラグインやライブラリの価値が高まる。

AIにはできない厳密なルール設定を肩代わりしてくれるからだ。

CSSのレイアウトで苦労しているなら、AIにプロンプトを投げる前に、Tailwind CSSのような制約の強いフレームワークを導入する。

制約があるからこそ、AIは正しいコードを出力できる。

最後に、AI出力をパーツとして扱う癖をつける。

巨大なファイルを一つのプロンプトで作らせるのではなく、小さな関数、コンポーネント、パーツ単位で生成させる。

それらを人間が結合テストを行う。

このマイクロ生成の積み重ねが、大規模なシステムをAIで構築する道だ。

Claude CodeのようなCLIツールは、この小さな対話を繰り返すために最適化されている。

* AIが得意なこと: パターンの提案、ボイラープレートの生成、有機的な表現

* AIが苦手なこと: 数学的な精度、長距離の依存関係の維持、厳密な幾何学構造

* 人間がすべきこと: 境界線の定義、最終的な品質保証、ツールの組み合わせ設計

FAQ

Q1: AI生成したデザインやCADデータをそのまま製品に使えますか？

そのまま使うのはリスクが高い。AIは視覚的な「それっぽさ」を生成するのは得意だが、CADにおける寸法精度や、ベクターデータにおけるパスの最適化は不完全だ。現状では、AIをドラフト生成ツールと位置づけ、最終的な精度が必要な部分は、FigmaのプラグインやCADソフトの機能を使って人間が調整するAI＋専門ツールのハイブリッド運用が現実的だ。

Q2: 幾何学的なデザインや構造物をAIで作るコツはありますか？

AIに全体を生成させないことだ。AIには人物や有機的な装飾などの非定型部分を生成させ、建物やデバイスなどの幾何学的なパーツは、専用のプラグインやCADツールで作成し、最後にそれらを合成する。また、AIの出力をパーツ単位で切り分けてからベクター化するのも、精度を向上させるための有効な手段だ。

Q3: Claude Codeのようなツールで構造的整合性を保つにはどうすればいい？

既存の検証エコシステムと連携させる。TypeScriptのような静的型付け言語を採用し、AIが生成したコードに対して即座にLintツールや型チェックが走る環境を構築する。また、AIにコードを書かせる前に、まずインターフェース（型）を定義させ、その制約の中でロジックを実装させる手順を踏むと、構造的な破綻を防ぎやすい。

道具を使い分ける者が最後に勝つ

AIは強力な武器だが、万能ではない。

幾何学的な弱点を知ることは、AIを使いこなすための第一歩だ。

統計的な予測に頼るAIと、論理的なルールを守る専門ツール。

この二つを高い次元で融合させられる開発者だけが生き残る。

僕もClaude Codeと格闘しながら、日々その最適なバランスを探っている。

最高のプロダクトは、AIのスピードと人間のこだわりが交差する場所に生まれる。

👉 ThreadPostでSNS運用を自動化する