AIハーネスはどこで壊れるのか

AIハーネス設計 実装編 #7 アンチパターン

AIハーネスの失敗は、しばしばモデルのせいにされる。

精度が足りない。
文脈が長すぎた。
推論が浅い。
もっと強いモデルに替えればよくなるのではないか。

もちろん、モデル差はある。
だが、現場で本当に多い失敗はそこではない。
壊れているのは、たいていもっと手前だ。

状態が残っていない。
評価条件が曖昧だ。
承認が記録されていない。
接続が広すぎる。
人間の役割が「全部見る人」に戻っている。

つまり、AIハーネスの失敗は、精度不足より 設計不足 で起きる。
しかも厄介なのは、こうした失敗の多くが、最初はかなり合理的に見えることだ。

1プロンプト全部入りは、最初は速い。
評価なし自動化は、最初は軽い。
人間が全部見る設計は、最初は安全に見える。
接続全面開放は、最初は強そうに見える。

だから壊れ方を知らないまま進むと、現場はこう解釈しやすい。

「やっぱりAIは不安定だ」
「現場では使えない」
「最後は人が全部見るしかない」

だが、その結論は少し雑だ。
正確には、その設計では回らない のである。
今回やりたいのは、恐怖喚起ではない。
壊れ方の地図を、先に持つことだ。

壊れ方が見えてくると、
どこに state を置くべきか、
どこに gate を置くべきか、
どこで人間を裁定者として入れるべきかが見えてくる。

アンチパターンは、脅しではない。
設計の優先順位を決めるための反面教師 である。

まず、1本の仕事で考える

不具合修正フローは、なぜ壊れやすいのか

ここでは、社内の不具合修正フローをひとつの例として通す。
想定する流れはシンプルだ。

不具合票を受け取る。
再現条件を整理する。
原因候補を洗う。
修正案を作る。
テストで確かめる。
承認して、本番へ出す。

この流れは、AIハーネスと相性がよいように見える。

要約できる。
分類できる。
差分を出せる。
テスト結果も読める。
承認前の説明文も作れる。

だから多くの現場が、ここから AI を入れたくなる。
そして、ここで多くの現場が壊れる。

なぜか。

不具合修正フローは、保存・制御・判定・接続 の全部を踏むからだ。
つまり、どこかひとつでも曖昧だと、その曖昧さが後段で増幅される。

今回のアンチパターンは、
この不具合修正フローに沿って見ると分かりやすい。

A. 保存と状態の故障

ここで壊れると、
仕事は前に進んでいるように見えて、途中から再開できなくなる。

アンチパターン1

1プロンプト全部入り

これは最も多い。
しかも、最も最初に成功してしまいやすい。

不具合票の要約も、
再現条件の整理も、
修正案の提案も、
レビューも、
テスト結果の解釈も、
承認コメントの下書きも、
全部ひとつの会話でやる。

最初は速い。
前提説明も一度で済む。
「文脈を全部持っているから強い」とすら見える。

だが、この設計は、
仕事が短いうちは回っても、仕事が長くなると壊れる。
理由は3つある。

第一に、関心事が混ざる。
再現条件を整理する段階で出た仮説が、
修正案の前提になり、
そのままレビュー観点に混ざる。

第二に、役割ごとの独立性が消える。
実装担当がテスト意図を見すぎる。
レビュー担当が実装中の迷いを見すぎる。
後段のはずの worker が、
前段の流れを補強するだけになる。

第三に、責任境界が消える。
どこで要件判断をしたのか。
どこで設計判断をしたのか。
どこで「これで通す」と決めたのか。
それが会話の流れに溶ける。

不具合修正フローでこれが起きると、
ある不具合についての「たぶんここが原因だろう」が、
後半では「すでに確定した原因」のように振る舞い始める。
すると、実装も検証も、その仮説の補強に引っ張られる。

1プロンプト全部入りは、文脈が豊かな設計に見える。
しかし実際には、

状態を曖昧にし、
接続を曖昧にし、
評価を曖昧にする設計

である。

最小修正

会話をむやみに増やすことではない。
観測範囲を役割ごとに切ること だ。

要件 worker には不具合票と完成条件だけ。
実装 worker には spec と制約だけ。
検証 worker には差分とテスト結果だけ。
承認者には要約と証跡だけ。

重要なのは会話数ではない。誰に何を見せないか である。

アンチパターン2

状態が会話の中にしかない

次に多いのが、状態が会話履歴にしか存在しない設計だ。

いま何の段階にいるのか。
再現中なのか。
修正案作成中なのか。
テスト待ちなのか。
差し戻しなのか。
本番反映承認待ちなのか。

これがチャットの流れにしか残っていないと、
止まった瞬間にすべてが弱くなる。

担当者が変わる。
数日止まる。
別案件が挟まる。
会話が長くなる。
それだけで再開コストが急増する。

不具合修正フローでは、これがかなり痛い。

たとえば、
修正案は出た。
テストも一度は走った。
だが本番反映の承認待ちで二日止まった。

その間に別案件が挟まり、担当者も交代した。
さて、いまどこから再開するのか。
会話だけに状態がある設計では、この問いに答えにくい。

最後のメッセージを読み返せば分かる、
という反論は成り立たない。
なぜなら、読み返して分かることと、
状態として再開できること は別だからだ。

必要なのは、
「たぶんここから再開だろう」ではない。
state が明示され、次の遷移条件が見えること だ。

最小修正

state を会話の外へ出す。

少なくとも、
現在状態、直前の verdict、差し戻し理由、再開地点は、
チケットやDBやワークフローの状態として残す。

AIハーネスで state をモデルの記憶に預けると、
便利さは出ても持続性が出ない。

B. 判定と制御の故障

ここで壊れると、
仕事は自動で流れるように見えて、
実際には止まるべきところで止まれなくなる。

アンチパターン3

評価なし自動化

AI運用が壊れる典型は、「自動化したこと」そのものではない。
判定を置かずに自動化したこと にある。
この失敗が起きやすいのは、導入初期だ。

まず、不具合票を要約する。
次に、原因候補を並べる。
さらに、修正案を生成する。
ここまではうまく見える。

すると次に、
「このまま自動で次へ流してもよいのではないか」
と考え始める。
ここで gate を置かないと、問題が始まる。

何を根拠に通したのかが残らない。
通すべきでない修正案が通る。
テスト不通過なのに、要約文だけは整っていて進んでしまう。
retry と escalate が分かれない。

最終的に、人間が最後に全部読む設計へ逆戻りする。

評価なし自動化が危険なのは、精度が低いからではない。
進行権を配る回路が存在しない からだ。

AIハーネスにおける評価は、
「今回はよかった」という感想では足りない。
必要なのは、少なくとも次の3つである。

• 何を evidence として返すか

• 何をもって pass とするか

• pass しなかったとき、それは retry なのか、stop なのか、escalate なのか

不具合修正フローで言えば、
テスト結果、差分、影響範囲、既知の制約が evidence になる。
そして、どの条件で本番反映候補へ進めるかを gate にする。

最小修正

小さくてよいので、
pass / retry / escalate / stop を必ず分ける。

ここが決まると、自動化は初めて制御可能になる。
ここが決まらないと、自動化は「速く流れていく不確実な処理」
でしかない。

アンチパターン4

承認がチャットの空気

「これで行きましょう」
「大丈夫そうです」
「お願いします」

こうした一言が、承認の代わりになっている。
現場では本当に多い。
だが、これは承認ではない。
単なる会話である。

不具合修正フローでこれが起きると、
本番反映の判断が非常に危うくなる。

誰が通したのか。
何を根拠に通したのか。
どの状態から、どの状態へ遷移させたのか。
これが残らない。

しかも厄介なのは、こうした空気承認が、
少人数チームやスピード重視の現場ほど起こりやすいことだ。

フローが軽い。
会話も早い。
信頼関係もある。
だから、その場では合理的に見える。

だが、
障害が起きたとき、
担当が変わったとき、
後から説明が必要になったとき、
この軽さがそのまま弱さになる。

承認は感想ではない。裁定 である。

裁定である以上、最低限必要なのは、
承認主体、承認対象、承認時点、承認根拠だ。

最小修正

承認を、会話ではなく 状態遷移 として残す。

誰が。
何を見て。
何を根拠に。
どの状態へ進めたか。

この4つが残れば、承認はようやく gate になる。

アンチパターン5

人間が全部見る設計

AIを入れたのに、最後は人が全部読んでいる。
これも典型的だ。

安全に見える。
慎重にも見える。
だが、長くは続かない。

理由は単純で、人間の確認コストが減っていないからだ。

しかも、
AIが作ったものを人間が全部読む設計では、
どこを重点的に見ればよいかも曖昧なままになる。
結局、読む量だけが増える。

不具合修正フローでは、この失敗はかなり起きやすい。

AIが不具合票を要約する。
AIが原因候補を出す。
AIが修正案を書く。
AIがテスト結果を要約する。
最後に人が全部を読む。

この構造だと、
AI導入で増えた出力を、人間がただ受け止め続けるだけになる。

問題は、人間が真面目に読みきれなかったことではない。
壊れているのは、人間の置き場所 である。

人間は、全部を見る人として置かない。
全部を補う人としても置かない。
人間は、例外を裁定する人 として置く。

最小修正

人間の仕事を、確認ではなく 裁定 に寄せる。

自動評価で決まらないとき。
高リスクの外部反映直前。
ポリシー例外が出たとき。
部門横断の責任判断が必要なとき。

ここに人を置く。
すると、人の仕事は読むことから、決めることへ移る。

C. 接続と境界の故障

ここで壊れると、
AIは強くなるどころか、責任線と露出範囲が溶け始める。

アンチパターン6

接続全面開放

つながるなら全部つなぐ。
使えるなら全部使わせる。
検索も、ファイルも、ブラウザも、社内ツールも、通知も、書き込みも、最初から全部開く。

これも、かなりよくある失敗だ。

気持ちは分かる。
AIの能力は、接続先が増えるほど伸びそうに見える。
だが、実務で問題になるのは能力不足より 露出過多 である。

全部見える worker は、強い worker ではない。
何を見て、何を見ていないかが曖昧な worker である。
全部触れる worker も同じだ。
柔軟なのではない。
責任境界が溶けているだけだ。

不具合修正フローでも、
修正 worker に不要なログ閲覧権限や、
検証 worker に不要な外部通知権限を渡してしまうと、
出力の責任線が急に曖昧になる。

「なぜその情報に触れたのか」
「どの道具でその結果を出したのか」
「その副作用は必要だったのか」
これが追えなくなる。

接続全面開放が危ないのは、セキュリティだけの問題ではない。
設計品質の問題 でもある。

最小修正

接続を session 全体で配らず、worker ごとに局所配布 する。

要件 worker には読む権限だけ。
実装 worker には限定された変更権限だけ。
検証 worker にはテストと参照権限だけ。
承認者には要約と証跡だけ。

接続面設計の本質は統合ではない。局所化 である。

アンチパターン7

ベンダ機能を原理と取り違える

もうひとつ厄介なのが、
特定ツールの機能名を、そのまま設計原理だと思ってしまうことだ。

ある製品の skill。
ある製品の workflow。
ある製品の memory。
ある製品の agent。

こうした機能は、確かに便利だ。だが、本質は機能名ではない。
本当に見るべきなのは、

• 状態をどこに置くか

• 何をもって通すか

• 誰に何だけ見せるか

• どこで人間が裁定するか

• 何を証跡として残すか

この設計原理の方だ。

ここを取り違えると、ツールを乗り換えた瞬間に設計まで失う。
新しい製品が出るたびに、毎回ゼロから考え直すことになる。

不具合修正フローでも、
ある製品の便利機能でうまく回っていたとして、
それをそのまま本質だと思うと、
閉域環境や別ベンダへ移った途端に崩れる。

最小修正

機能名を覚える前に、
その機能が どの設計問題を解いているか を言葉にする。

たとえば、
これは state の置き場所の問題なのか。
gate の問題なのか。
worker 分離の問題なのか。
証跡の問題なのか。

そう整理できると、製品が変わっても骨格は残る。

故障マップ

どのアンチパターンが、どの回路を壊すのか

ここまでの失敗を並べると、ばらばらの注意点に見えるかもしれない。
しかし実際には、壊れている場所はかなりはっきりしている。

1プロンプト全部入りは、
状態回路、接続回路、評価回路 を同時に曖昧にする。

状態が会話の中にしかない設計は、
状態回路と証跡基盤 を壊す。

評価なし自動化は、
評価回路と制御回路 を壊す。

承認がチャットの空気になっている設計は、
制御回路と証跡基盤 を壊す。

人間が全部見る設計は、
制御回路と評価回路 を人間へ押し戻す。

接続全面開放は、
接続回路と証跡基盤 を壊す。

ベンダ機能を原理と取り違える設計は、
4回路全体の移植性 を壊す。

こうして見ると、アンチパターンは単なる失敗談ではない。
どの回路を守るべきかを逆から教えてくれる地図 である。