不可解な失敗の常態化

元記事: 2026年9月28日原文(ihatethefuture.com)

概要

President Curtis のエピソードで、ドアが開かない場面が繰り返されるユーモア
AIモデル Jev の「自信スコア」や透明性の問題提起
ソフトウェアの失敗時に責任や原因追求が曖昧になる現状
「仕方ない」「よく分からないけど壊れた」で済ませる風潮への懸念
LLM活用による品質向上の可能性と、それを活かしきれていない現状

ドアが「ダメ」な理由と笑い

President Curtis の一幕で、ドアを開けようとするが障害物（死体や金塊）が邪魔で開かない展開
どちらの場面でも「 stupid thing sucks （このバカなものめ）」と呟く大統領
ドアの失敗を「説明不能な運の悪さ」で済ませる演出
視聴者としてはその 理不尽さ が滑稽に感じる
だが、これは「ドアの設計」としては全く合理的でないという指摘

Jev: 「ダメなドア」を増やすAI

TypeSafe AI が開発したAIモデル Jev が話題
Jevの特徴
- 高速かつ低コスト
- 開発が容易
技術の採用基準や本質的価値の見極めが難しい現状
Slackのようなプロダクトが普及する理由も未だに納得できない困惑

プロダクトに期待しすぎ？

「動くはず」と思い込むユーザー心理
多くの利用者は Jev にブラックボックス的な質問を投げ、ブラックボックスな回答を受け取るだけ
「AI搭載済み」という チェックボックス消化 のために導入されるケース
問題が起きても「AIは間違えるもの」として 責任回避 が容易
エラーバジェットや失敗モード、テストセットの軽視
実際の失敗率はユーザーが身をもって体験することに

自信スコアの誤用と危険性

「 Jevは自信スコアを返すから大丈夫」という反論
だが、自信スコアを有効活用するには
- スコアのキャリブレーション （信頼性評価）
- 不確実性のコストモデル
Jevの宣伝はベンチマークスコアが中心で、自信スコアの精度や意味は曖昧
多くは「儀式的」「言い訳的」にスコアを使い、失敗の原因説明に使われがち

責任と説明責任の希薄化

サイトのボタンが壊れた時、何が起きたかの 因果モデル を想定
バグやサーバーエラーには 所有者 がいるという暗黙の期待
しかし、ユーザー体験としては「 stupid thing sucks」で済まされがち
ソフトウェアの不可解な失敗が日常化し、「なぜ？」の追及が減少
LLMやAIによる加速で、さらに「仕方ない」で終わる事例が増加

LLM開発加速の光と影

LLM活用で QA自動化 や 評価プロンプト の導入が容易に
しかし、現場では 検証や品質管理 よりも「とりあえず出荷」が優先
結果として、利用者も開発者も「原因追及」や「改善」への興味が薄れる
「ドアの向こうに死体があるかどうか」すら確かめずに進めてしまう構造
結論として「 stupid thing sucks」で済ませる風潮への警鐘

補足：エレベーターやSlackの例

「エレベーターに乗れる時もあれば、シャフトに落ちる時もある」的なブラックユーモア
Slackのような 信頼性の低いツール が標準化した謎
Bill GatesのMovie Maker失敗事件のように、誰の責任か曖昧なまま放置される現実
顧客がBill Gatesでなくても、最低限の説明責任は担保されるべきとの主張

提供: ハクソク · 要約更新: 2026年9月28日

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

製品に多くの時間を費やすほど、失敗やイライラがあっても再び選ぶ可能性が高くなるんだよね。なんだか理由をつけて正当化すると思う（「今はちょっと有利だし」とか）。これって、物を見ることにも当てはまるんだ。スーパーの棚にあるカラフルな箱は、まず目に入って長く見られるから、選ばれる可能性が高いんだよね。時間やリソースを無駄にすることは力の象徴だけど、自分自身の時間やリソースを無駄にさせるのはヘゲモニーだよ。

└

意図的に失敗率を上げることでユーザーの定着率が改善するなんてことはないよね…？そうじゃないって言ってよ。

ウェブサイトでボタンが壊れると、何が起こるべきだったかのモデルが頭にあるんだ。どこかで契約が破られたんだろうね。 [...] HTTPステータス500だけじゃデバッグできないかもしれないけど、なぜエンドポイントが500になってるのかを理解するのが仕事の人がいるはずだと思ってる。所有権は明確だけど、ちょっと不透明だね。 > でも多くのユーザーにとって、実際の体験は「バカなものがクソだ」って感じなんだ。ソフトウェアはすでに気まぐれに感じるし、失敗が増えるとイライラの度合いが変わるだけ。著者はクラウドサービスをあまり使ってないんじゃないかな。ユーザーだけじゃなくて、開発者もそうなんだ。Githubが5xxを返してる？AWSサービスが動かない？メールが届いてない？私たち（開発者）にはどうしようもない、「バカなものがクソだ」。

└

「ユーザー」だけじゃなくて、開発者も関わってるんだよね。開発者とユーザーは同時に存在することもあるし。分散システム[0]は、5年前に発明されたわけじゃないからね。 ;) 「Githubは、私たちが正しく動作するために頼っている部分を所有していて、失敗したときには何もできない。」っていうのは、しっかりした所有権モデルだよね。[0] ...独立して開発され、独立して失敗することができる異なる部分が存在することを示唆してる...

└

ソフトウェアではこの運命論的な態度をよく見る。「バグは避けられない。」いや、そんなことない！バグは選択なんだ。ほとんどの企業は「バグなし」は高すぎるからバグを選んでる。時にはそれが正しい選択だけど、それが選択であって、ソフトウェアの自然な特性ではないことを認める必要がある。もし橋や飛行機を作る人たちが「橋の崩壊や飛行機の墜落は避けられない、解決方法はない」なんて思ってたらどうなるだろう。

「説明できないことの正常化」は本当にイライラするよね。コンピュータソフトウェアに関してはずっと悪かったけど、最近は埋め込まれたソフトウェアに依存する他の消費者製品にも広がってきてる。最近新しい電気自動車を買ったんだけど、ほとんど満足してるんだ。買った直後から「EVシステムをチェックして」って警告メッセージが出るようになった。ディーラーに持って行く頃には警告は消えてて、技術者は「うーん、たまにそうなるみたいだね。また起こったら教えて」って感じで言ってた。ハードウェアの故障？ソフトウェアのバグ？誰にもわからないよね。最近の車はほとんどが接続性やGoogleマップをインフォテインメントシステムに組み込んでるけど、大抵の時間は問題なく動くんだ。でも時々、接続がないって言って、交通データも最適じゃないルートも表示されないことがある。強い電波がある場所でもそうなることがあるし。時には車が接続されてるって言っても、Googleマップはオフラインだと思ってることもある。マップがルートを表示することもあるけど、「ナビ開始」ボタンが永遠に回ってるだけで、何かを待ってるみたい。これらは関連してる問題なのかな？共通の原因があって修正できるのかな？誰にもわからないよね。（便利なことに、保証はソフトウェアやファームウェアの正常な動作の失敗をカバーしてないんだ。）

└

自分のKia Niro EVは、他には結構満足してるんだけど、時々イグニッションが無効になることがあって、無作為に15分くらいロックされることがあるんだ。たまに、でも必ずしも、予定出発でACをオンにするとトリガーされることがある。Kiaの反応は、ただの大きな肩をすくめるだけ...

└

これは、80年代や90年代のソフトウェアに対する悪いエラーダイアログボックスへの反発の意図しない結果かもしれない。多くの人が、エラーレポートの課題に対する簡単な解決策は、黙って失敗することだと結論づけたように見える。roll_safe.jpg

└

「EVシステムをチェックしてください」という警告メッセージこれは、ソフトウェアが表示できる最もイライラするメッセージの一つで、心底嫌いだ！商業ソフトウェアの多くがこうで、デザイナーは複雑（でも役に立つ）なエラーメッセージでユーザーを怖がらせたくないから、「おっと！何かがうまくいかなかった」としか言わない。理解できないエラーメッセージよりも、理解できるエラーメッセージが欲しい。車の場合、昔はダッシュボードに「エンジンチェック」の一般的なランプが点灯して、何が原因で点灯したのかを知るために外部ツールが必要だったけど、現代の車でそれが必要なのはなぜ？CANバスには大きくて高解像度のディスプレイがあるんだから、なぜ問題をフルに表示して、発生した瞬間に写真を撮ってディーラーに送って即診断してもらえないの？

└

20年前、父のインターネット接続のトラブルシューティングをして、設定ミスを見つけられなかったのを思い出す。技術者に電話したら、「このダイアログまで進んで、'リセット'を選んで」って言われたけど、それもダメだった。あの時、インターネットやソフトウェアが不透明になっていくのを感じた瞬間だったんだ。時にはその不透明な失敗は一時的だけど、時には無期限に続くこともある。今、私のAndroidフォンはiPhoneが作ったグループテキストを見られない。幸い、私は半引退状態だからこれはありがたいけど、他の人にとっては危機的な状況かもしれない（問題を一時的に解決するカップルを知ってるけど、テキストを必要な時に何時間もデバッグするのは避けたいよね）。要するに、こういうことがずっと増えてきてて、「ただ動く」デザインの悪い双子みたいな感じ。デフォルトの期待が「ただ動く」だと、失敗のモードは「ただ動かない」になっちゃう。ユーザーが馬鹿だっていう前提があるから、結局みんな馬鹿になっちゃって、「馬鹿のためのインターフェース」しか扱えなくなって、失敗が不透明な失敗になってる。開発者は「すべての抽象は漏れやすい抽象だ」って知ってるけど、開発者はユーザー（や下流の開発者）にその漏れを扱うためのツールを与えない。だって、単純なインターフェースの方が大事だから。「非常口がなければ、非常事態もないよね？」

これが「説明できないことの正常化」につながるんだ。責任の欠如の正常化とも密接に関係してる。 > これは「FTPアカウントを取得して、curlftpfsでローカルにマウントしてから、マウントしたファイルシステムでSVNやCVSを使う」ってわけじゃない。まだ難しい部分をやらなきゃいけないんだ。これで若い層のオーディエンスを失ってるかもね。 ;)

└

責任があるのは、アルゴリズムをホストして書いている人たち、例えばTherac-25みたいな。

Hacker Newsで議論の続きを見る