専門性を、
根拠まで辿れる形に。

AI本番化は、精度改善より先に失敗条件・責任境界・Fallbackを設計する。

AIは誤りをゼロにできないため、採用条件と人へ戻す条件が曖昧だと、本番で責任と判断が揺れる。

2 model families

低リスクな社内実験や、誤りが業務影響を持たない用途では、同じ厳密さの運用境界が不要な場合がある。

自動化の信頼性は「止まらないこと」ではなく、異常を検知し、復旧または人間の判断へ戻せることで成立する。

処理が正常終了しても、データ欠損や鮮度劣化が起きれば業務結果は誤るため、実行状態と結果完全性を分けて観測する必要がある。

54 sites / 11 months / 100K+ / month / 0 system stops

単発処理や、失敗時に即座に再実行でき業務影響が小さい処理では、監視・復旧設計を簡素化できる。

曖昧な案件は、情報を増やすだけでは進まない。誰が・何を・どの条件で決めるかを設計すると前進する。

未確定事項と責任境界が混ざった状態では、進捗があっても重要判断が先送りされ、後工程で手戻りになる。

0 system stops / 30 tests / 1,400 lines

要求・責任・受入条件が既に明確な定型案件では、Decision Architectureの介入価値は小さい。

Technical PMは、技術を説明する役ではなく、Business・Technology・Operationsを同じ意思決定面に載せる役割である。

技術的に正しい実装でも、業務責任・運用条件・変更境界が未定義なら、本番では使い続けられない。

54 sites / 2 model families / 30 tests / 1,400 lines / 38 accounts / 1H cadence

仕様と運用が確立済みで、実装範囲だけが明確な案件では、専門エンジニアや実装ベンダーへ直接依頼する方が速い。

製造業DXはツール導入ではなく、工程・データ・責任・現場定着を一体で再設計する。

既存工程のボトルネックや責任分界を変えずにシステムだけ追加すると、二重入力やShadow Workflowが残りやすい。

2 model families

既存業務が標準化済みで、単純な置換導入だけで目的を満たすケースでは、大規模な業務再設計は不要。

営業支援PoCは、データ取得ではなく、取得→検知→分析→配布→判断までの摩擦を減らして初めて運用価値になる。

取得成功だけを完了条件にすると、アポ取りこぼし・集計欠損・保存先誤りが営業判断の前段で残る。

38 accounts / 1H cadence

小規模で担当者が単一、データ量も少なく手動確認コストが無視できる場合は、自動化範囲を広げすぎない方がよい。