AIに技術知識を使わせるために、「ルールの信頼度」を分けて考える

AIを土木設計の支援に使おうとすると、あるところで必ず問題になります。

それは、

AIが見つけたルールを、どこまで信用してよいのか

という問題です。

当社では現在、Claude Codeを使いながら、樋門の配筋図や鉄筋加工図を解析し、作図や照査に使えるルールを整理しています。

以前の記事では、配筋図をAIに描かせようとすると、設計者が普段無意識に使っている判断を一つずつ言葉にしなければならない、という話を書きました。

その後も検証を続けたところ、もう一つ重要な問題が見えてきました。

それは、

過去図面から見つかった規則らしきものが、本当に一般的な設計ルールなのか、それともその案件だけの判断なのかを区別しなければならない

ということです。

1案件で一致しても、それが一般ルールとは限らない

配筋図を解析していると、一見するときれいな規則が見つかることがあります。

例えば、

• この寸法なら鉄筋本数はこの数になる
• この位置ではこの長さになる
• この端部ではこのように割り付ける

といった関係です。

実際のDXFデータと計算結果が0mm差で一致すると、「ルールを発見した」と考えたくなります。

しかし、ここには注意が必要です。

同じ案件の図面から逆算して作った式が、その同じ案件で一致するのは当然とも言えます。

別の案件でも同じ式が成立するとは限りません。

今回の検証でも、途中で一度「この寸法は鉄筋の曲げ半径から決まっているのではないか」と考えた数値がありました。

ところが詳しく調べると、それは曲げ半径とは無関係で、標準的な配筋ピッチの端数処理によって生じた数値でした。

数字が一致していたため、もっともらしい理由を後から付けてしまったわけです。

AIを使った解析では、こうしたことが特に起きやすいと感じています。

AIは、与えられたデータの中から整合する説明を作ることが得意です。

だからこそ、

一致したことと、一般化できることを分けて扱う必要があります。

「まだ分からない」と「そもそも正解が一つではない」は違う

もう一つ重要だったのが、この区別です。

設計ルールを調べていると、

「まだロジックが分からない」

という箇所が出てきます。

しかし、それをすべて同じ種類の「未解決問題」として扱うのは危険です。

大きく分けると、少なくとも二種類あります。

一つは、条件や入力情報が不足しているため、まだ計算方法を見つけられていないもの。

もう一つは、設計者の判断によって複数の成立解があり、最初から唯一の正解が存在しないもの。

例えば、配筋ピッチの端数が発生したとき、その端数を構造物のどちら側へ寄せるか。

一定の処理ルールはあっても、「必ずこの側へ寄せる」という一般則が存在しない場合があります。

こうしたものをAIに延々と分析させると、本当は存在しない唯一解を探し続けることになります。

最終的には、

過去図面ではこちら側へ寄せているため、これが一般ルールである

というもっともらしい結論を作ってしまう可能性があります。

ここは今回の検証でかなり重要な境界だと感じました。

技術知識を4種類に分けて考える

現在は、配筋に関する知識を大きく次のように分けて考えています。

A：基準として決まっているもの

設計基準や設計要領などで、比較的一意に決まるものです。

例えば、

• かぶり
• 標準配筋ピッチ
• 定着長
• 重ね継手長
• 曲げ半径

などです。

こうしたものは、複数の資料や実際の図面で確認できれば、AIによる自動チェックにも比較的使いやすいと考えています。

B：条件が揃えば計算できるもの

一見すると案件ごとの判断に見えても、条件を整理すると計算で再現できるものがあります。

例えば、標準ピッチで割り付けた後に小さな端数が残った場合の処理などです。

この層は、別案件でも同じ条件式が成立するかを検証する価値があります。

C1：本当に設計者の判断が残るもの

複数の案が成立し、どれか一つだけが正解とは言えないものです。

例えば、

• 端数をどちら側へ寄せるか
• 複数の成立配置のどれを採用するか
• 図面上でどの断面を代表させるか

といったものです。

ここはAIが自動的に正解を決めるのではなく、

設計意図を確認してください

と人へ返す領域だと考えています。

C2：作ることは難しいが、読むことはできるもの

今回の検証で特に面白かった分類です。

ある鉄筋配置について、構造図だけからその位置をゼロから予測する式はまだ分かっていない。

しかし、完成済みの配筋図があれば、その位置をDXFの座標から正確に抽出することはできる。

つまり、

生成する能力と、既存図面を読む能力は別物

ということです。

この場合、配筋図の自動生成にはまだ使えなくても、照査や図面間の整合確認には使える可能性があります。

「生成できない」からといって「照査できない」わけではない

この違いは、AIを設計業務へ使うときにかなり重要だと思います。

AI活用というと、どうしても、

「ゼロから図面を作れるか」

という話になりがちです。

しかし実務では、既に存在する図面を確認する仕事も非常に多くあります。

例えば、

• 平面図と側面図で寸法が一致しているか
• 同じ鉄筋番号の径が図面間で一致しているか
• 配筋図と加工図の長さが一致しているか
• 鉄筋表の本数と図面上の本数が一致しているか

といった確認です。

これらは必ずしも「正しい配筋図をAIが作れる」必要はありません。

同じ成果品の中で情報が矛盾していないかを確認するだけなら、外部の正解ルールがなくても判定できます。

そのため現在は、

完全自動作図より先に、図面間の整合性チェックから実用化できないか

という方向も検討しています。

ただし「安全」と「簡単」は違う

内部整合だけを見るのであれば、設計ルールの一般化問題を避けられるため、比較的安全です。

しかし、それでも簡単というわけではありません。

そもそもAIやプログラムが図面を正しく読めていなければ、正しい照査はできません。

実際のDXFを解析すると、

• 同じ鉄筋線でも色属性が異なる
• レイヤーだけでは鉄筋と注記を完全に分けられない
• 寸法線が密集すると、どの寸法がどの段に属するかテキストだけでは判断できない
• 鉄筋番号の割当が図面境界付近でずれる

といった問題が出てきました。

つまり、

照査ロジックが正しくても、入力の読み取りが間違っていれば誤判定する

ということです。

そこで現在は、AIに何を判定させるかだけでなく、

そもそも図面を何％正しく読めているのか

を測る必要があると考えています。

開発に使った図面で精度を測らない

ここでもう一つ、AI開発では当たり前ですが、実務の自動化では見落としやすい問題があります。

抽出プログラムを作る途中で、

「この図面では鉄筋を取りこぼした」

と分かれば、当然プログラムを修正します。

その後、同じ図面をもう一度読み込ませて100％抽出できたとしても、それは未知の図面に対する精度ではありません。

その図面は、すでにプログラム改善の材料として使われています。

そのため現在は、図面を大きく、

• 開発に使った図面
• 過去のバグが再発していないか確認する図面
• 一度も開発判断に使っていない未見図面

へ分けて評価する考え方を整理しています。

未知の図面でどこまで読めるのかを確認しなければ、「精度が高い」とは言えません。

これは配筋図に限らず、AIを実務へ持ち込む際には重要な考え方だと思います。

「根拠」を一つの数字にしない

設計知識の信頼度についても、単純に

「信頼度90％」

のような一つの数字へまとめることは考えていません。

例えば、

• 基準書で確認した
• 設計計算例でも確認した
• 実際のDXFでも一致した

というルールは強いように見えます。

しかし、設計計算例がその基準書をそのまま参照しているなら、二つは完全に独立した根拠とは言えません。

また、同じ案件の中で20箇所一致したことと、20案件で一致したことも、意味は全く違います。

そのため、

• どの資料で確認したか
• 何案件で確認したか
• 何図面で確認したか
• どの結果と一致したか

を一次データとして残し、信頼度や分類はそこから判断する方がよいと考えています。

事実は一か所だけに保存する

今回の検証を続ける中で、技術知識を管理するうえで一つの原則にたどり着きました。

事実は一か所だけに保存し、分類・件数・信頼度はそこから派生させる。

例えば、

「このルールは1案件だけでしか確認していない」

という情報を、別途「単一案件ルール」というタグとして保存するとします。

その後、別案件でも確認できて検証件数を2件へ更新したのに、「単一案件ルール」のタグを消し忘れると、データの中に矛盾が生まれます。

それなら、

「どの案件で確認したか」

という事実だけを保存し、

• 1案件のみ
• 2案件以上

という状態は自動的に計算した方が安全です。

これはデータベース設計では基本的な考え方ですが、設計者の暗黙知をAI用のKnowledgeへ変換する場合にも同じことが言えると感じています。

配筋図の実験から、技術Knowledgeの設計へ

もともとは、

「AIに配筋図を描かせられないか」

という比較的単純な実験でした。

ところが進めていくうちに、

• AIは図面をどこまで正しく読めるのか
• そのルールはどこから得たものなのか
• 何案件で再現したのか
• 唯一解なのか、設計者判断なのか
• 生成に使えるのか
• 照査には使えるのか

を分けて管理しなければならないことが分かってきました。

これはもう、配筋図だけの問題ではありません。

構造計算、数量計算、河川構造物の設計、BIM/CIM、設計照査などでも同じだと思います。

技術者の経験をAIへ渡す場合、単に「答え」を保存するだけでは足りません。

その答えが、何を根拠に、どこまで一般化でき、どの用途なら使ってよいのかまで残す必要があります。

配筋図の自動化を試したことで、結果的に当社の技術知識そのものをどう残すかを考えることになりました。

まだ仕組みを作り始めた段階ですが、今後AIを設計実務へ深く使っていくのであれば、モデルの性能以上に、こうしたKnowledge側の設計が重要になるのかもしれません。