AIに配筋図を描かせようとしていた2026年、土木・構造ソフトも変わり始めていた
樋門の配筋図をAIで扱う検証をしていた2026年、RC構造の3D配筋・図面・数量化に加え、ClaudeやCodex、Python、MCPから解析ソフトを操作する取り組みも始まっていました。
配筋図とAIの試行錯誤｜第2回
AIに配筋図を描かせようとしていた2026年、土木・構造ソフトも変わり始めていた
2026年、私はAIに樋門の配筋図を理解させられないか試していました。
ただし、完成した配筋図を自動で出せるところまで来ていたわけではありません。
構造物を部材へ分ける。図面同士の位置関係を整理する。寸法、標高、勾配、かぶり、鉄筋の配置ルールを一つずつ言葉にする。
実際に行っていたのは、AIに図面を描かせることより、人間が図面を作るまでに何を判断しているのかを分解する作業でした。
一方、同じ2026年に、土木・構造分野の大手ソフトウェアでも、3Dモデル、配筋、数量、API、AIをつなぐ動きが見えていました。
将来振り返ったとき、「当時はどこまでできていたのか」が分かるように、この記事では2026年時点の公式情報を残しておきます。
樋門の配筋図に、そのまま使える製品は見つからなかった
最初に書いておくと、公式情報を調べても、樋門の既存二次元図面をAIへ渡し、設計意図を読み取って配筋図を再現する製品は見つかりませんでした。
大手ソフトウェアが扱っているのは、あらかじめ構造化された3Dモデルから、配筋、図面、加工情報、数量などへ展開する仕組みが中心です。
一方、私が試しているのは、既存の構造図、配筋図、鉄筋加工図から、樋門固有の設計ロジックを逆方向に読み解く作業です。
入口が違います。
そのため、大手ソフトウェアの機能を導入すれば、そのまま今回の問題が解決するわけではありません。
ただ、
- 構造物を線ではなくデータとして持つ
- 配筋を形状、間隔、属性、配置ルールとして扱う
- 3Dモデルから図面や数量へ展開する
- 反復操作をAPIやスクリプトへ任せる
- 最後は技術者が確認する
という方向は共通しています。
樋門や不等流計算には、すでに市販ソフトがある
海外の大手製品を見る前に、樋門・河川実務へ、もっと直接近い既存製品があります。
FORUM8の「柔構造樋門の設計・3D配筋」は、樋門本体と門柱、胸壁、翼壁などの設計計算に加え、構造一般図、配筋図、数量計算書を作成できます。ソフト内で3D配筋を表示し、構造と鉄筋の位置関係を確認する機能もあります。
また、「3Dパラメトリックツール水工」には、二次元図面から躯体寸法を取り込んで3Dモデルを生成し、樋門設計ソフトと連携する機能があります。
河川計算では、当社が使用しているヤマソフトプランニングの「奔流」シリーズにも、横断図のDXFを読み込み、断面座標として扱う機能があります。
つまり、
- 樋門の設計計算から二次元図面を作る
- 配筋を三次元で表示する
- 数量計算書を作る
- 二次元図面から躯体寸法を取得して3Dモデルへつなぐ
- DXFから河川断面を読み込んで計算へ使う
という機能自体は、すでに市販ソフトの中にあります。
私が今回試していることを、それらの機能そのものを新しく発明したかのように書くのは正確ではありません。
違いがあるとすれば、既存の構造図、配筋図、鉄筋加工図を出発点に、人間がどのような設計判断をしていたのかをAIと一緒に逆算している点です。
市販ソフトを置き換えたいわけではありません。既存ソフトが担う計算や作図の前後に残っている、自社固有の条件整理、図面間の照合、数量の考え方、検図を、どこまで補助できるかを探っています。
参考：FORUM8「柔構造樋門の設計・3D配筋」、3Dパラメトリックツール水工、ヤマソフトプランニング「奔流」シリーズ
RC構造では、3Dモデルから配筋・図面・数量へ展開している
RC構造に近い例として、BentleyのProConcreteがあります。
ProConcreteでは、鉄筋コンクリート構造物を3Dでモデル化し、そのモデルから配置図、加工詳細、鉄筋加工表、コンクリート数量、材料レポートを作成できます。コンクリート形状を変更すると、関連する鉄筋や図面、数量も更新されます。
対象には建築だけでなく、土木構造物や橋梁も含まれています。
TrimbleのTekla Structuresでも、3Dモデル内の鉄筋はコンクリート形状の変更に追従し、関連する図面や鉄筋表が更新されます。開口や切り欠きを考慮した鉄筋配置、継手、鉄筋番号の管理なども、モデル上の情報として扱われています。
ALLPLAN Civilでは、橋梁のパラメトリックモデルと配筋を連携し、Python Partsを使って3D配筋モデルを生成する流れが示されています。3Dモデルから縦断図、横断図などを作り、配筋テンプレートを別の箇所や案件へ再利用する考え方です。
これらは、AIが図面を見て設計判断をしているわけではありません。
形状とルールを人がモデルへ与え、そのデータから図面や数量を生成する、従来型のBIM・自動化です。
しかし、今回の検証にとっては、この部分が重要でした。
AIから配筋図を作ろうとしても、結局はその前に、部材形状、鉄筋形状、配置範囲、ピッチ、かぶり、継手、番号などをデータとして整理しなければなりません。
大手製品が3Dモデルを入口にしているのは、その土台がなければ図面や数量へ安定して展開できないからだと思います。
参考：Bentley ProConcrete、Teklaの3D配筋、ALLPLAN Civilの橋梁ワークフロー
2026年には、ClaudeやCodexから設計ソフトを動かす話も出てきた
モデルを使った自動化は以前からありましたが、2026年には、その操作方法にも変化が出てきました。
Bentley Systemsは2026年6月、ClaudeやCodexのようなAIコーディングツールから、PythonやOpen APIを介してエンジニアリングソフトを操作する方向を紹介しています。
従来なら、技術者自身がAPIの仕様を調べ、最初からコードを書く必要がありました。
AIコーディングツールを使えば、技術者が行いたい処理を言葉で説明し、コードの作成や修正をAIに補助させることができます。
これは、私が配筋図の検証で行っていることにも近いものがあります。
私はプログラムだけを先に作っているのではありません。
「この断面とこの平面を対応させる」「この範囲に鉄筋を配置する」「この計算結果を既存図面と照合する」という実務上の考え方をAIへ説明し、それを処理へ変えています。
AIが設計者になるのではなく、設計者が持っているルールをソフトウェアへ渡すための翻訳や実装を補助する形です。
MCPからSTAADを自然言語で操作する実験
Bentleyが同じ記事で紹介していた、もう一つ興味深い取り組みがMCPです。
MCPは、AIと外部のソフトウェアやデータを接続するための仕組みです。
Bentleyの実験では、AIエージェントがMCPを介して構造解析ソフトSTAADへ接続し、自然言語による指示からモデルを操作しています。
これは、文章で質問すると解析結果を説明してくれるだけの仕組みではありません。
AIが解析ソフトへ処理を依頼し、結果を受け取り、条件を変えて再計算するところまでをつなぐ考え方です。
もちろん、紹介されている例は樋門の配筋設計ではありません。鋼構造物の解析と最適化に関する実験で、用途は異なります。
それでも、2026年に、
AIとの会話を、実際のエンジニアリングソフトの操作へつなげる。
という方向が公に示されていたことには意味があります。
当社で考えている流れも、考え方としては近いものです。
- 人が構造と設計条件を判断する
- AIが図面やルールを整理する
- スクリプトがCADや計算処理を動かす
- 数量や配筋の候補を出す
- 機械的に整合性を確認する
- 最後に人が照査する
規模も対象もまったく違いますが、人の判断を残したまま、反復的な作業をAIとソフトウェアへ移すという方向は共通しています。
参考：Bentley Systems「From Code to Command」
大手はモデルから展開し、私は二次元図面から逆算している
大手ソフトウェアの事例と、今回の検証には大きな違いがあります。
ProConcrete、Tekla、ALLPLANなどは、構造化された3Dモデルを作り、そこから配筋図や数量へ展開します。
私が今行っているのは、すでにある二次元の構造図、配筋図、鉄筋加工図を照合し、設計者がどのようなルールでその図面を作ったのかを逆算する作業です。
図面には結果が描かれています。しかし、判断の過程がすべて書かれているわけではありません。
なぜこの位置で鉄筋番号を変えたのか。なぜこの範囲ではこの本数なのか。設計数量では何を代表値にしたのか。どこまでが一般的なルールで、どこからが個別判断なのか。
そこを人が言葉にしなければ、AIもスクリプトも安定して再現できません。
つまり、大手ソフトウェアが持っている「構造化されたモデル」を、既存図面から少しずつ作り直しているとも言えます。
この作業が終われば、その知識を3Dモデル、配筋図、数量計算、検図へ共通して使える可能性があります。
2026年には、まだ人を判断から外していなかった
2026年時点の公式情報を確認すると、AIと自動化はかなり進んでいました。
しかし、少なくとも樋門の二次元図面から設計意図を読み、配筋図を完成させるところまでを、そのまま任せられる製品は見つかりませんでした。
大手の取り組みでも、人が構造モデルとルールを与え、AIやソフトウェアが反復処理を行い、人が結果を確認する流れが残っています。
数年後には、ClaudeやCodexからCADや解析ソフトを動かすことが当たり前になり、2026年の記事が古く見えるかもしれません。
逆に、設計条件の個別性、説明責任、最終照査が壁となり、同じ役割分担が残っている可能性もあります。
だからこそ、2026年の時点で、
どこまでAIへ任せられ、どこから人の判断が必要だったのか。
を残しておくことには意味があると思っています。
将来この記事を読み返したとき、変化の速さに驚くのか。それとも、結局同じところで悩んでいるのか。
今の段階では、まだ分かりません。
前の記事： AIに配筋図を描かせようとして、設計の暗黙知を言葉にすることになった