llm-architecture

llm-architecture

SIの立場で、生成AI活用をどう設計して売るのが「誠実」なのか整理してみた

導入:売りやすさと構造的正解の乖離 前稿では、文字通り業務ロジックを確率モデルに預けるなという原則を提示しました。しかし現実のSI案件では、この原則を守ることが必ずしも容易ではありません。 人材の制約、納期の制約、営業資料的見栄え、そして何より「AIが判断します」という訴求の強さ——これらの要因が、構造的に健全とは言いづらい設計を選択させる圧力として働くこともあると思います。 本稿では、現実的な制約の中でSIが取りうる「誠実なライン」を構造的に考察します。 誠実なライン:判断UIとしてのAI 基本構成 SIにおける生成AI活用の最も誠実な構成は、次のような流れになります: 人間の曖昧な入力 ↓ LLM(意味解釈・正規化) ↓ 既存 or 新規の業務ロジック(決定論的処理) ↓ 確定結果 ↓ LLM(説明・要約・自然言語化) ↓ 人間 この構成では、生成AIを"判断エンジン"として売らず、"判断UI"として売ることになります。 構造的特性 この設計が持つ特性: 決定性の保証:

llm-architecture

業務ロジックをLLMに預けてはいけない

——生成AI時代のSI設計パターン観測 導入:設計パターンで読むという視点 生成AIの業務活用を考える時、「何をAIにやらせているか」ではなく「判断をどこに置いているか」を見る必要があるような気がしてきています。 これをSIプロジェクトでやる場合は構造的な制約があります——営業資料の見栄え、短い納期、限られた人材、明確なROI要求。これらの制約の中で、生成AIをどう組み込むかという設計判断が行われます。 その結果として、いくつかの典型的な設計パターンが繰り返し現れています。本稿では、SI案件でよく見られる(ような気がする)2つの設計パターンを観察し、Deterministic Core型のアプローチとの構造的な違いを分析します。 個別の実装の良し悪しではなく、どのような設計圧力がどのような構造を生むかという観点で整理してみます。 パターンA:静的RAG型(営業メール系事例) よく見られる構成 SI案件でよく見られる構成の一つに、「過去データをRAGで検索可能にする」というパターンがあります。営業メールを構造化してBigQueryに保存し、必要に応じてAI検索で引き