【HLR Engine開発日記】④でも、AIの答えをそのまま正式な計算結果にはできない

AIを使えば、一人でもHLR Calculation Engineを作れそうになりました。

しかし、開発を進めるうちに、AIとの会話で得られる「提案・検討」と、正式なHLRを出す「計算」は分けた方がよいと考えるようになりました。理由は、再現性だけではありません。速度やAIリソースの使い方を考えても、その方が合理的だったのです。

今回は、現在の「AI+決定論的なCalculation Engine」という役割分担が、どうして生まれたのかを振り返ります。

目次

1.AIと一緒なら、HLRの計算までできそうだった

前回、AIを開発支援に使い始めました。

計算ロジックを整理する。
条件を整理する。
プログラムを書く。
動作を確認する。

こうした作業をAIと一緒に進めることで、一人会社でもCalculation Engineを形にできる可能性が見えてきました。

そしてAIは、計算そのものについて考えるときにも便利でした。例えば50mの橋について、

「100年間にどんな作業が必要か」
「それぞれ、どれくらいの労働が必要か」
「人年に換算するとどうなるか」

と会話しながら検討できます。ここまでは、非常に便利でした。

2.でも、この答えを「正式なHLR」にしてよいのか?

ところが、開発を進めるうちに疑問が出てきました。

AIとの会話の中で、「この橋のHLRは○○人年です。」という数字が出たとして、それをそのまま正式なHLR値にしてよいのだろうか。

HLRを単なる参考値ではなく、将来的に異なるインフラや選択肢を比較するための指標として使うなら、「それらしい数字が出た」だけでは足りません。

同じ橋、同じ条件、同じルールなら、いつ計算しても同じ結果になってほしい。そして後から、「なぜこの数字になったのか」を確認できなければなりません。

ここで、以前の記事でもご紹介した「再現性」の問題が見えてきました。

3.正式計算は、確定した条件とルールから出したい

そこで、AIとの会話と正式な計算を分けて考えるようになりました。

AIには、

資料を整理する。
条件の候補を考える。
抜けを探す。
計算方法を検討する。
プログラム開発を支援する。

といった仕事をしてもらいます。

しかし、一度、

「この条件を使う」
「このルールで計算する」

と決めた後は、AIにもう一度考えてもらう必要はありません。確定した入力条件と計算ルールを、Calculation Engineが決められた通りに処理します。

こうすれば、同じ条件なら同じ結果を出せます。

4.さらに気づいた。「全部AIで計算するのは、もったいない」

そして開発を進める中で、もう一つ理由が見えてきました。

確定した計算まで、毎回AIにやらせる必要があるのだろうか?

例えば、すでに計算方法が決まっている単純な処理なら、一般的なプログラムは非常に高速に実行できます。一方、それを毎回AIに読み取らせ、考えさせ、計算させれば、その分だけ時間もかかりますし、AIの計算資源も使います。

1本の橋だけなら、大きな違いではないかもしれません。しかし将来、数百の橋、数千の施設、自治体全体、さらに広い地域、を計算するとしたら、この違いは大きくなります。

5.「考えるところ」と「決まったところ」を分ける

ここが、今回の中心メッセージです。

開発を進める中で、少しずつ役割分担が見えてきました。

考える必要があるところにはAIを使う。
考える必要がなくなったところは単純な計算&実行プログラムにする。

AIは、まだ答えが決まっていない問題を整理したり、候補を探したり、設計を支援したりすることが得意です。一方、Calculation Engineは、確定した条件とルールを使って、同じ計算を速く、安定して繰り返します。

どちらか一方を選ぶのではなく、それぞれが得意な仕事を担当させるということです。

6.AIをHLRから外したわけではない

ここは、誤解のないようにお伝えしておきます。

正式なHLRをAIに直接計算させないからといって、AIをHLR開発から外したわけではありません。むしろAIは、Calculation Engineを作るうえで、重要な開発支援の役割を担っています。

変わったのは、「AIを使うかどうか」ではなく、「AIをどこで使うか」でした。

AIの柔軟性と、通常のプログラムの再現性・速度。両方を組み合わせる方が、HLRには向いているのではないか。そう考えるようになりました。

7.「動くエンジン」から「信頼できるエンジン」へ

AIを使うことで、一人でもCalculation Engineを作れる可能性が見えてきました。そして今回、正式計算をAIから切り離すことで、「計算できるエンジン」から「信頼して使えるエンジン」へ進む方向も見えてきました。

ただし、そこで新しい問題が出てきます。同じ結果を出すには、そもそも「同じ条件」とは何なのかを、きちんと固定しなければならない。橋の形式、幅、場所、評価期間、計算範囲……。

ここから、入力条件や計算ルールをどう管理するかという、次の開発課題につながっていきます。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

CAPTCHA


目次