【ITニュース解説】Building an AI project estimator with prices the model cannot invent

ITの世界では、AIがますます身近な存在になり、さまざまなシステムに組み込まれるようになっている。今回取り上げるニュース記事は、「AIプロジェクト見積もりツール」を例に、AIとビジネスの重要な接点について深く掘り下げている。システムエンジニアを目指す皆さんにとって、AIを実用的なシステムに組み込む際の基本的な考え方を学ぶ良い機会となるだろう。

この記事の中心的なテーマは、AIモデルの持つ創造性や柔軟性を活かしつつ、ビジネスにおいて絶対に守るべき正確性や信頼性をどのように両立させるか、という点にある。「Project Blueprint」というAIプロジェクト見積もりツールを開発した際の話を通じて、AIモデルが「発明できない」価格、つまりAIの想像力に任せてはならない部分を、どのようにシステムとして制御するかを解説している。

Blueprintは、製品の簡単な説明から、プロジェクトのアーキテクチャ（システムの骨組み）、開発計画、そして必要なチーム構成までをAIが提案する。これらはプロジェクトを進める上で非常に役立つ情報だが、肝心な「価格範囲」については、AIモデルの提案範囲から意図的に外されている。価格は、別に用意された「計算エンジン」が、事前に定義されたルールに基づいて算出する仕組みになっているのだ。

なぜこのようにAIと価格計算を分離するのか。それは、AIモデルが出力する内容、その出力がどのようにチェックされるか、ユーザーがブラウザで何を入力でき、サーバーに何が保存されるか、といったシステム全体の設計に大きな影響を与えるからである。AIは時に学習データに基づいてもっともらしいが誤った情報を作り出すことがある。特に金銭に関わる部分は、そのような「発明」が許されない領域だ。

具体的に、AIモデルには「決められた語彙」だけを使わせる工夫がされている。AIは、料金カタログに載っているプラットフォーム、機能、その他の選択肢の中からしか提案できないようになっている。そして、AIが提案した選択肢は、価格計算が始まる前に「サニタイザー」と呼ばれるチェック機構を通る。サニタイザーは、カタログにない未知の項目を削除したり、選択が必須な項目が抜け落ちていたらデフォルト値を自動で設定したりする役割を果たす。

この「カタログ」、システムのデータ構造（スキーマ）が許容する値、そしてサニタイザーが許可する値のリストは、すべて同じ「ルールオブジェクト」から生成されている。これにより、製品がサポートする内容に関する定義が、システム内の複数箇所でバラバラに管理され、不整合が生じるリスクを防いでいる。この一貫性のある定義は、システム全体の信頼性を高める上で非常に重要だ。

処理の流れはシンプルだ。まずユーザーが製品の説明を入力する。それに基づいてAIがアーキテクチャとスコープ（プロジェクトの範囲）を提案する。次に、提案された内容がサニタイザーによって検証・整形される。そして、整形された選択肢が計算エンジンに渡され、最終的な見積もりが算出される。このように、AIは提案の一部に影響を与えるものの、見積もりの最終的な数値はAIが直接生成するわけではなく、ルールに基づいた計算エンジンが決定するため、その影響は明示的かつ検証可能になっている。見積もりを確認する際には、AIが選択した機能が適切かどうかも含めてレビューする必要がある。

この「AIの提案」と「ビジネスの決定」を区別する考え方は、ビジネスプロセスにAIを組み込むあらゆる場面で役立つ。AIが制約された選択肢の中から提案したとしても、それが常に最適な推薦であるとは限らない。入力値がシステムによって許可されるかどうかを検証することは、その推薦がユーザーにとって適切かどうかを判断するのとは別の問題なのだ。

また、出力が「有効なJSON形式」であることだけでは不十分な場合がある。Blueprintは、AIからの構造化された出力（JSONなど）を受け取った後、その内容をさらに詳細に検証し、整形する。例えば、グラフ構造のデータであれば、重複する識別子を取り除いたり、存在しないノードへの参照を削除したり、グラフの整合性を保つように修復したりする。これは、たとえJSONとして正しい形式であっても、アプリケーションの表示部分や後続の機能が実際に必要とする要件を満たしているかを確認するためだ。他の製品であれば、レコード間の有効な参照、オプションの組み合わせの妥当性、生成された計画の範囲の制約などがチェックの対象になるかもしれない。重要なのは、「次にこのデータを使う機能が、どんな前提を持っているか」を考えてチェックを行うことである。

さらに、ユーザーがウェブサイトで見積もりを依頼し、その情報が「ビジネス記録」として保存される際には、ブラウザ上で表示されている数値がそのまま使われることはない。サーバー側で、要求内容を再度検証し、選択肢を整形し、見積もりを再計算するのだ。ブラウザから送られてきた数値は、あくまでプレビューのためのものであり、ビジネスレコードとしての権威を持つ値としては扱われない。これにより、保存される見積もりが常に信頼できる計算結果に基づいていることが保証される。割引や利用料金などについても同様に、どこで「表示されている提案」が「権威ある値」に変わるのか、そしてどのコンポーネントがその決定を許可されるのかを明確にすることが重要となる。

最後に、AIによる生成が何らかの理由で利用できない場合の「フォールバック」（代替手段）についても一貫性が保たれている。Blueprintには、手作業で作成された「リファレンスブループリント」が用意されており、これらもAIが生成した場合と同様に、価格計算エンジンを通して見積もりが算出される。これにより、フォールバックのシナリオでも、製品の計画や価格設定の動作を信頼性高く探索できるだけでなく、AIによる見積もりと手動による見積もりとで、ユーザーの期待値に差異が生まれるのを防ぐことができる。

この記事は、AIの能力を最大限に活用しつつ、同時にその限界を理解し、ビジネスの信頼性を確保するためのシステム設計の原則を教えてくれる。AIの「推薦」とアプリケーションの「権威ある決定」との間に、明確な境界線を引くこと。この考え方は、これからのシステムエンジニアにとって不可欠なスキルとなるだろう。