llm-architecture

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

mnk.log

20 2月 2026 — 9 min read

導入：売りやすさと構造的正解の乖離

前稿では、文字通り業務ロジックを確率モデルに預けるなという原則を提示しました。しかし現実のSI案件では、この原則を守ることが必ずしも容易ではありません。

人材の制約、納期の制約、営業資料的見栄え、そして何より「AIが判断します」という訴求の強さ——これらの要因が、構造的に健全とは言いづらい設計を選択させる圧力として働くこともあると思います。

本稿では、現実的な制約の中でSIが取りうる「誠実なライン」を構造的に考察します。

誠実なライン：判断UIとしてのAI

基本構成

SIにおける生成AI活用の最も誠実な構成は、次のような流れになります:

人間の曖昧な入力
    ↓
LLM（意味解釈・正規化）
    ↓
既存 or 新規の業務ロジック（決定論的処理）
    ↓
確定結果
    ↓
LLM（説明・要約・自然言語化）
    ↓
人間

この構成では、生成AIを"判断エンジン"として売らず、"判断UI"として売ることになります。

構造的特性

この設計が持つ特性:

決定性の保証:

業務判断はコードやルールベースで固定される
同じ入力には同じ結果が返る
判断ロジックは外部から検証可能

監査可能性:

ログと監査が成立する
障害時に原因を追える
「なぜこの結果になったか」が説明できる

進化の余地:

失敗はロジック側に還流できる
ルール追加・修正が構造的に可能
システムが回るほど精度が上がる

AIの役割

この構成におけるAIは:

入力側:

自然言語の翻訳器(非構造化→構造化)
曖昧さの吸収装置(表記ゆれ・文脈補完)
知識検索の補助(関連情報の提示)

出力側:

結果の説明係(判断根拠の自然言語化)
要約・統合(複数結果の整理)
ユーザー適応(専門用語の調整)

つまり、AIはUIレイヤに徹するんですよね。

コード例：誠実な構成

不誠実な例

python

# ❌ 判断をLLMに丸投げ
def classify_expense(description: str) -> str:
    prompt = f"""
    以下の経費を適切な勘定科目に分類してください:
    {description}
    
    選択肢: 旅費交通費、会議費、交際費、消耗品費
    """
    return llm.generate(prompt)

# 同じ入力でも結果が変わる
# 判断根拠が不明
# 失敗を改善に活かせない

誠実な例

python

# ⭕ LLMは入力整形、判断はロジック
def classify_expense(description: str, amount: int) -> Decision:
    # Step 1: LLMで入力を構造化
    structured = llm.parse(description)
    # → {"item_type": "交通費", "detail": "新幹線", "destination": "大阪"}
    
    # Step 2: 決定論的ロジックで判定
    decision = apply_expense_rules(
        item_type=structured["item_type"],
        amount=amount,
        detail=structured["detail"]
    )
    
    # Step 3: LLMで説明を生成
    explanation = llm.explain(
        f"「{description}」は{decision.reasoning}のため、"
        f"{decision.account_name}({decision.account_code})に分類されます。"
    )
    
    return Decision(
        account_code=decision.account_code,
        account_name=decision.account_name,
        reasoning=decision.reasoning,
        explanation=explanation
    )

def apply_expense_rules(item_type: str, amount: int, detail: str) -> RuleResult:
    # ルールは外部ファイル/DBから読み込み
    for rule in expense_rules:
        if rule.matches(item_type, amount, detail):
            return RuleResult(
                account_code=rule.code,
                account_name=rule.name,
                reasoning=rule.condition_description,
                matched_rule_id=rule.id
            )
    
    # 例外処理も明示的に
    return RuleResult(
        account_code="UNKNOWN",
        account_name="要確認",
        reasoning="該当ルールなし - 人間による判断が必要",
        matched_rule_id=None
    )

この構成では:

判断はapply_expense_rulesで決定論的に実行
LLMは入力の整形(parse)と出力の説明(explain)のみ
ルールが不足している場合は明示的にUNKNOWNを返す
失敗は「どのルールが足りないか」として観測可能

地味ですが、構造的に健全といえそう。

不誠実ゾーン：一線を越える設計

越えてはいけない境界

以下の設計は、構造的に不誠実かなと考えます:

判断の生成化:

勘定科目をLLMに生成させる
承認条件をプロンプトで書く
業務分岐をAIに任せる

検証の形骸化:

レビューを別LLMにやらせる(自己添削ループ)
サブエージェントによる「検証」(同一分布からの生成)

根拠の後付け:

RAGで「根拠っぽいもの」を探して表示
判断→根拠の順序(本来は根拠→判断)

この構成の帰結

不誠実ゾーンの設計では:

決定性の喪失:

判断が確率化される
同じ入力でも結果が変わりうる

検証不能性:

「なぜこの結果か」を説明できない
監査が成立しない

責任の曖昧化:

誤判定の原因が特定できない
「AIが判断した」で終わる

構造的停滞:

失敗が構造に戻らない
システムが学習しない

結果として、「AIが判断している"風"」だけが残るんですよね。

これは技術の問題ではなく、設計責任の放棄です。

なぜSIはここで迷うのか

現実的な圧力

SIが不誠実ゾーンに引き寄せられる理由は構造的かと思います:

実装コストの問題:

判断ロジックの実装は重い
業務ルールの整理に時間がかかる
例外パターンが無限に出現する
業務部門との調整が必要

プロジェクト制約:

PoCが遅くなる
初期デモの見栄えが悪い
段階的改善より一発導入が求められる

営業資料の問題:

「LLMが判断します」は説明しやすい
「サブエージェントで検証」は安心感がある
「UIレイヤに徹します」は地味に見える

つまり、売りやすさを優先した結果として、不誠実ゾーンの設計が選ばれやすいんですよね。

短期と長期のトレードオフ

不誠実ゾーンの設計は:

短期的には「動いているように見える」
デモは華やか
導入は早い

しかし長期的には:

誤判定が蓄積される
改善の道筋が見えない
保守コストが増大
責任の所在が不明確

誠実な設計は:

短期的には地味
初期実装が重い
デモが華やかでない

しかし長期的には:

判断精度が向上
保守が構造化される
責任範囲が明確
ビジネスロジックが資産化

逆説：AIが入るほどロジック設計の価値が上がる

よくある誤解

多くの人が期待するAI時代の姿:

AI導入前:
- 複雑なロジックを書く必要がある
- 状態設計が大変
- 例外処理が面倒
- 判断構造の実装に時間がかかる

AI導入後:
- AIが全部考えてくれる
- コードを書かなくてよくなる
- 業務ロジックも自然言語でOK
- プログラマーは要らなくなる

しかし、現実は逆だったりしまして。

構造的必然：不安定な部品を入れる時

LLMは構造的に:

確率的(同じ入力でも出力が変わる)
文脈依存(プロンプト次第で挙動が変わる)
再現性が弱い(デバッグが困難)

つまり、不安定な部品です。

工学の基本原則として、不安定な部品をシステムに組み込むとき、システム全体はどうすべきか？

中央を固める。

不安定な周辺部品を許容するために、コア部分の決定論性を強化する——これは制御工学やシステム設計における常識です。

AI時代に何が起きるか

AIが入ることで:

増えるもの:

入力の曖昧性(自然言語だから)
処理の不確実性(確率的生成だから)
デバッグの難易度(ブラックボックスだから)
例外パターン(柔軟性の裏返し)

だからこそ必要になるもの:

明確な判断ロジック
厳密な状態設計
網羅的な例外処理
検証可能な判断構造

曖昧さが増えるから、中央の決定論がより重要になるんですよね。

消える人、残る人

この構造的必然は、人材の淘汰として現れます。

AI時代に価値が下がる人:

CRUDだけ書いていた人
フレームワークを追っていただけの人
業務理解なしで実装していた人
「動けばいい」で終わっていた人

AI時代に価値が上がる人:

判断構造を設計できる人
状態遷移を明示できる人
例外をモデル化できる人
ドメイン知識をコードに落とせる人

残酷な結論

つまり:

AIが来たからロジック要らない

ではなく

AIが来たからロジック設計できない人が要らなくなる

これは夢のない話ですが、構造的な現実です。

AIは「プログラミングを不要にする」のではなく、**「本質的な設計能力を持たないプログラミングを不要にする」**んですよね。

設計の本質化

AI導入によって:

隠せなくなるもの:

判断の曖昧さ
ロジックの穴
例外処理の不備
業務理解の浅さ

より重要になるもの:

ドメイン知識
構造設計能力
責任範囲の明確化
長期的視点

AIは、設計能力の差を増幅する装置として機能します。

優れた設計者にとってAIは強力な道具になりますが、設計能力を持たない人にとってAIは「判断を丸投げする先」でしかなく、それは構造的に持続不可能なんですよね。

誠実な売り方の実例

具体的な提案構成

誠実なSI提案は、次のような構成になります:

フェーズ1: UIレイヤの構築

目的: 既存システムへの自然言語インターフェース追加
期間: 1-2ヶ月
成果物:
- 自然言語入力の構造化機能
- 既存ロジックへの接続
- 結果の自然言語説明機能

フェーズ2: 判断ロジックの外在化

目的: 暗黙知の明示化とルールベース化
期間: 2-3ヶ月
成果物:
- 業務ルールの文書化
- ルールエンジンの実装
- 例外ハンドリングの設計

フェーズ3: 進化機構の組み込み

目的: 失敗からの学習サイクル確立
期間: 1-2ヶ月
成果物:
- ログ分析基盤
- ルール追加フロー
- 定期改善プロセス

営業資料での訴求

避けるべき表現:

「AIが自動判定」
「サブエージェントが検証」
「高精度な意思決定」

誠実な表現:

「AIによる自然言語インターフェース」
「明示的なルールベースによる判定」
「段階的に進化する決定ロジック」

地味ですが、これが構造的に正直な訴求なんですよね。

結論：誠実さは構造に宿る

判断UIという選択

SIにおける生成AI活用の最も誠実な売り方は:

判断はロジックとして実装し、AIは人間とシステムの間に置く。

言い換えると:

AIを脳にしない
AIを感覚器と通訳にする

同時に満たすべき要件

この構成は、以下を同時に満たします:

安全性:

決定論的な判断
検証可能な根拠
監査に耐える構造

検証可能性:

判断ロジックの外在化
失敗原因の追跡
説明責任の明確化

長期的な進化:

ルール追加による改善
失敗からの学習
ビジネスロジックの資産化

これが、現実的な制約の中で取りうるほぼ唯一の誠実な構成です。

AIは設計能力の差を増幅する

本稿で辿り着いた結論は:

AIはUI
判断はコード
ロジックは消えない
むしろ重要になる

これは「夢のAI論」から「工学の現実」への着地です。

AIは魔法の杖ではなく、設計能力の差を増幅する装置なんです。優れた設計者にとっては強力な道具になりますが、設計責任を放棄する人にとっては、構造的に持続不可能な幻想を生むだけになりかねません。

設計責任としての誠実さ

「何を売るか」は技術選択ではなく、設計責任の置き方の問題といえます。