社内向けに需要予測やスコアリングなど「数値を扱うAI機能」の導入を検討している開発者に向けた内容です。LLM（大規模言語モデル。文章生成や要約が得意なAI）に計算そのものを任せてよいか、判断材料を整理しました。
個人開発者が公開した株式分析ツール「StockAny AI」の設計が、業務システムの実装パターンとして参考になります。GitHub上で公開されているこのツールは、ティッカー（銘柄コード）を入力すると、企業価値の推定や投資判断のたたき台を自動生成します。注目すべきは機能そのものより、LLMに「何をさせて、何をさせないか」を明確に線引きした構成です。
何が話題になっているのか
StockAny AIは、株価を取得するだけのダッシュボードではありません。財務データの取得、企業価値の試算、最新ニュースの調査、投資判断のレポート生成までを一気通貫で行います。
フロントエンドはNext.js 16とReact 19、バックエンドはPythonのFastAPIという構成です。この技術スタック自体は目新しくありません。
本質的な工夫は、LLMであるGemini（Googleが提供する生成AIモデル）に「財務計算をさせていない」点にあります。金額の計算はすべてバックエンドのPythonコードが担い、Geminiは計算結果の解釈と、Web検索を組み合わせた文脈情報の補足にだけ使われています。
仕組みを段階的に見る
まず処理の流れを分解します。ユーザーがティッカーを入力すると、Financial Modeling Prep（財務データを提供するAPIサービス）から株価やPER（株価収益率）、フリーキャッシュフローなどの生データを取得します。
次に、このデータをもとにDCFモデル（Discounted Cash Flow、割引キャッシュフロー法。将来のキャッシュフローを現在価値に割り引いて企業価値を算出する伝統的な財務評価手法）で企業価値を試算します。成長率8%、割引率9%、ターミナル成長率2.5%、予測期間5年というデフォルト値を使い、5年分の将来キャッシュフローを現在価値に割り引き、さらに継続価値（ターミナルバリュー）を加算して株式価値を算出します。
ここまでの計算過程には、LLMが一切関与していません。すべて決定論的な数式による処理です。
続いて、算出した理論株価と現在の市場価格を比較し、「安全余裕率（Margin of Safety）」を計算します。計算式は以下の通りです。
安全余裕率 = (理論株価 - 現在株価) / 現在株価 × 100例えば現在株価が100ドル、理論株価が130ドルなら、(130-100)/100×100で30%となります。この数値もPythonの計算結果であり、LLMが生成した数字ではありません。
最後の段階で初めてGeminiが登場します。バックエンドで計算した数値データを文脈として渡し、Tavily(Web検索を組み合わせたAIエージェント向け検索API)で直近の決算情報や競合動向、材料視されているニュースを調べさせ、強気・弱気それぞれの見方を含む投資判断の文章を生成させています。
なぜこの分離が重要なのか
単純に「NVIDIAは良い投資先か」とLLMに直接尋ねることもできます。しかしこの方法には業務システムとして見過ごせない問題があります。
LLMは学習データやWeb検索の結果から数値を「それらしく」生成することがあり、実際の財務数値と一致する保証がありません。これはハルシネーション（LLMが事実に基づかない内容をもっともらしく出力する現象）と呼ばれる既知の課題です。
金額計算や在庫引当、与信判定のスコアなど、1円のズレも許されない業務ロジックにLLMを直接使うのは、この観点から避けるべき設計です。StockAny AIの構成は、この問題への実践的な回答になっています。
数値計算は決定論的なコード（Pythonの関数)に固定し、LLMは「計算結果の解釈」「非構造化データの要約」「文章生成」という、もともと得意な領域だけに限定して使う。この責務分離の考え方は、業務システムのAI機能設計における基本パターンとして押さえておく価値があります。
既存の業務システムとの比較で見えること
従来型の業務システムでは、計算ロジックはCOBOLやJavaのバッチ処理、あるいはExcelマクロなどに固く実装され、担当者以外は手を出しにくい「ブラックボックス化」がしばしば起きていました。
LLMを導入する際、この計算ロジックそのものをLLMに置き換えてしまう提案を見かけることがあります。しかし精度検証やトレーサビリティ（計算根拠の追跡可能性）の観点で、金融・会計・在庫管理のような監査対象領域には向きません。
StockAny AIの設計は、既存の計算エンジン（この場合はDCFモデルの実装）はそのまま活かし、LLMは「人間向けの説明文を書く担当」として後付けする形になっています。これは、既存の業務システムに手を入れずにAIレイヤーを追加するアプローチとして、レガシーシステムを抱える現場でも応用しやすい形です。
今日確認できること
自社のシステムにLLM機能を追加検討している、あるいは既にPoC（概念実証）を進めている場合、以下の観点で現状を点検してみてください。
- LLMへのプロンプトの中に、金額・数量・日付など「1つでも間違えると業務影響が出る数値」の計算を丸ごと依頼していないか
- 数値計算とLLMによる文章生成が、コード上で明確に別の関数・別のAPIエンドポイントに分離されているか
- LLMの出力に含まれる数値が、実は前段のバックエンド処理で計算済みの値をそのまま埋め込んでいるだけか、それともLLMが自分で計算し直しているか
- 監査ログや処理履歴に、どの数値がどの処理ステップで計算されたか追跡できる情報が残っているか
もし既存のAI機能がLLMに数値計算を任せている場合、GitHubで公開されているStockAny AIのリポジトリ（iPrq/Stock-Market-Analyser）のバックエンド部分の構成が参考になります。DCF計算のロジックとGemini呼び出し部分がファイルレベルで分離されているか、実際のコードで確認してみると設計の切り口が掴みやすくなります。
また、LangChain（LLMを使ったアプリケーション構築を助けるフレームワーク）を使う場合は、Tool呼び出しの設計時に「この関数はLLMに計算させるのか、既存コードの結果を渡すだけなのか」を1つずつ棚卸しすると、責務の混在を防げます。
まとめ
StockAny AIの設計から持ち帰れる実務上のポイントは次の通りです。
- 金額や比率など監査性が求められる数値は、決定論的なコードで計算し、LLMには渡さない
- LLMの役割は「計算結果の解釈」「非構造化情報の要約」「投資判断のような定性的な文章生成」に限定する
- 既存の計算ロジック（レガシーな業務システムの資産)を置き換えるのではなく、その出力をLLMに渡す形で後付けする方が導入コストと検証コストを抑えられる
まずは自社のプロンプト設計を1つ開き、数値計算をLLMに依頼している箇所がないか棚卸しするところから始めてみてください。