例外が多いシステムは、
「未完成」「不安定」「設計が甘い」
と思われがちだ。
だから多くのAI・業務システムでは、
例外を減らそうとする。
-
ルールを増やす
-
条件を網羅する
-
ケースを潰す
だが、この発想こそが、
システムを壊す。
例外をなくそうとした瞬間、何が起きるか
例外を減らす設計は、
一見すると“賢く”見える。
-
自動化率が上がる
-
人手が減る
-
判断が速くなる
だが現場では、
次の現象が必ず起きる。
-
ルールが肥大化する
-
説明不能な分岐が増える
-
「想定外」がより深刻になる
これは偶然ではない。
例外とは「世界の歪み」ではない
まず、前提をひっくり返そう。
例外とは、
現実が複雑であることの証拠
だ。
-
人が想定どおり動かない
-
状況が重なり合う
-
文脈が変化する
世界が生きている限り、
例外は必ず生まれる。
例外が多いのは、
世界が壊れているからではない。
モデルが世界に追いついていないだけだ。
「例外＝失敗」という誤解
例外が起きたとき、
システムはこう扱いがちだ。
-
エラー
-
異常
-
フォールバック
つまり、
本流から外れたもの
として隔離する。
だが実際には、
例外こそが判断が必要な瞬間である。
判断が必要な場所は、必ず例外として現れる
これまでの書いたものを思い出してほしい。
-
判断は計算では完結しない
-
確率は曖昧さを保持する
-
責任は人が引き受ける
この3つが同時に現れる場所はどこか。
それが、
例外処理
だ。
例外は、
「人が介在すべき境界点」を
正確に指し示している。
例外を減らすほど、判断は不可視化される
例外をロジックで潰すと、
何が起きるか。
-
判断がコードの奥に隠れる
-
誰が決めたのか分からなくなる
-
責任の所在が曖昧になる
つまり、
例外を減らす設計は、
判断を隠す設計
なのだ。
健全なシステムほど、例外が“表に出る”
逆に、健全なシステムではどうなるか。
-
例外が明示される
-
境界条件が見える
-
人の介入点がはっきりする
例外は、
システムが世界と接している場所
であり、
その数が多いほど、
世界を誠実に扱っていると言える。
例外処理を「設計」に組み込むとはどういうことか
例外を潰すのではなく、
居場所を与える。
そのための設計視点は、
次のようになる。
1. 例外は「エラー」ではなく「状態」として扱う
-
failure ではなく state
-
異常系ではなく判断待ち
-
自動停止ではなく保留
例外＝人の判断が必要な状態。
2. 例外は必ず「理由付き」で表に出す
-
なぜ例外になったのか
-
どの前提が外れたのか
-
何が足りなかったのか
例外は、
設計のフィードバックでもある。
3. 例外はログではなく「対話」に渡す
-
ダッシュボードに出す
-
判断者に説明する
-
次の設計に反映する
例外は、
学習データ以前に
思考の材料だ。
例外が多いほど、AIは賢く“ならない”
重要なので、あえて逆を言う。
例外が多いからといって、
AIが賢くなるわけではない。
だが、
人間が、どこで考えているかは明確になる。
それこそが健全さだ。
例外は、設計者への問いである
例外が現れたとき、
問われているのはAIではない。
-
なぜこの判断を自動化したのか
-
なぜこの境界を選んだのか
-
なぜ人を外したのか
例外は、
設計者に返ってくる問い
だ。
まとめ
-
例外は失敗ではない
-
例外は世界の複雑さの証拠
-
例外は判断が必要な場所を示す
-
例外を潰すと責任が消える
-
例外が多いほど、システムは誠実である
AI時代の設計とは、
例外をなくすことではない。
例外に、人が立つ場所を用意すること
それが、
PoCで終わらないシステムの条件だ。
コメント