計算エンジンは動いた。でも、何を入力する？
これまでの開発日記では、同じ条件なら同じ答えを出すことや、計算条件と実行履歴を記録する仕組みをご紹介してきました。ところが、計算エンジンが動くようになると、次の問題が見えてきました。
「そもそも、計算エンジンに渡す数字は、どうやって決めるのか？」
例えば、橋梁の点検に必要な人数や作業時間を計算するには、その元になる情報が必要です。しかし実際の資料では、その情報が必ずしも分かりやすく整理されているわけではありません。
同じ項目でも、情報の出どころが違う
橋梁のHLRを計算する場合、入力に使う情報としては、次のようなものが考えられます。
| 情報の種類 | 具体例 |
|---|---|
| 既存資料 | 橋梁の設計図、点検記録、工事積算書 |
| データベース | 標準的な作業歩掛、労務係数 |
| ユーザー入力 | 橋長、評価期間、想定する点検頻度 |
| 推定値 | 資料がない場合の作業人数や作業時間 |
どれも計算に使う数字ですが、根拠や信頼性はそれぞれ違います。例えば、実際の点検記録から得た作業時間と、一般的な条件から推定した作業時間を、何の区別もなく扱うわけにはいきません。
計算に使う数字そのものだけでなく、その数字がどこから来たのかも重要になります。
複数の情報から、正式な入力を組み立てる
そこで考えたのが、Input Assembly（入力の組み立て）という工程です。
例えば、橋梁の点検頻度について、ユーザーが入力した条件と、参照資料に書かれた条件が食い違うことがあります。そのとき、どちらを採用するのか。あるいは、計算の目的に応じて条件を選び直すべきなのか。こうした情報を整理し、正式な計算に使う入力条件を確定するまでの工程が、Input Assemblyです。
流れを整理すると、次のようになります。まず、設計図・点検記録、係数データベース、ユーザー入力、推定値や仮定といった情報があります。これらをInput Assemblyで整理・照合し、採用する条件を確定します。確定した入力条件と根拠は、Input Cardに記録します。そのうえで、HLR Calculation Engineが正式な計算を行います。
Input Assemblyは入力条件を組み立てる工程であり、Input Cardは確定した条件を記録するものです。以前ご紹介したInput Cardが「確定した条件をどう記録するか」の話だったのに対し、今回は、その一段前の「条件をどう集め、整理し、確定するか」の話になります。
なお、情報が矛盾している場合や推定が必要な場合に、必ずしも自動的に正解を決められるわけではありません。判断が必要なものについては、その根拠を明確にしておくことが大切です。
AIが得意な仕事と、正式計算の仕事を分ける
大量の仕様書や積算資料を読み、必要な情報を探し出す作業は、人間にとっても大変です。こうした作業には、AIを活用する余地があります。
一方で、AIが読み取った情報を、そのまま無条件に正式な計算へ渡してよいわけではありません。資料の読み違いや、異なる条件の混同が起こる可能性があるからです。
そこで、AIなどを使って情報を整理し、採用する条件とその根拠を確認したうえで、計算エンジンに渡すという役割分担を考えました。以前の記事でご紹介した「AIに正式計算を任せない」という方針とも、つながる考え方です。
正しい計算の前に、正しい入力が必要
どれだけ正確な計算プログラムを作っても、入力条件が間違っていれば、正しい評価結果にはなりません。しかも実際のインフラでは、必要な情報が一つの資料にすべてそろっているとは限りません。だからこそ、さまざまな情報から入力条件を整理し、採用した根拠を残す仕組みが必要になります。
計算式を正しく動かすことと、正しい数字を入力することは、別の問題でした。計算エンジンを作るだけでは、HLRは計算できません。その前に、計算に使う条件を組み立て、確定する仕組みが必要だったのです。
コメント