HashiCorp創業者が語ったAI精神病とは何か。

経営者同士で集まると、「AI導入、うまくいってますか」に即答で「はい」が返ってくる場面が増えました。バグは減った、テストは通っている、開発速度も上がった。その3つが全部本当でも事業としては壊れていく道筋があることを、インフラの世界は一度通って学んでいます。

4ヶ月前の投稿を今あえて読む理由

Superlogical共同創業者でHashiCorp創業者のミッチェル・ハシモトさんが、2026年5月中旬にMastodonへ短い投稿を書いています。書き出しが強烈で、今まさに会社まるごとが重度のAI精神病にかかっていて、その件について理性的な会話をすることが不可能になっている、と。特定の名前は出せない、深く尊敬している個人的な友人が含まれているから、とも添えています。

4ヶ月前の話をなぜ今持ち出すのか。速報として消費すると、この投稿の価値をほぼ全部取り逃すからです。中身は今週のAI業界の出来事ではなく、過去に一度決着した論争が形を変えて戻ってきたという構造の指摘で、4ヶ月経っても状況は何も変わっていません。むしろこの4ヶ月でエージェントに書かせるコードの量が増えた分だけ、話は重くなっています。

ここで注意が1点あります。日本語で「AI精神病」と検索すると、チャットボットとの対話で人が妄想や依存に陥る現象の記事が並びます。ハシモトさんが言っているのはそれではなく、組織がAIに対して抱いている非合理な確信のほうです。主語は人ではなく会社です。

クラウド移行期に一度片がついた議論が、なぜ今また始まったのか

投稿の芯は、刺激的な病名のほうではありません。ハシモトさんは、クラウドとクラウド自動化への移行期に、インフラ業界がMTBF対MTTRで大きな決着をつけた時代を生きてきた、と書いています。そしてあのときの論争がまた頭をもたげている、今度はソフトウェア開発業界の全体で。これがこの投稿の本題です。

MTBF（平均故障間隔）は、そもそも壊れないようにする発想です。堅牢に作り、変更を慎重にし、障害と障害の間隔を伸ばしていく。対するMTTR（平均復旧時間）は、壊れる前提で復旧の速さに賭ける発想です。落ちてもいい、3分で戻せるなら。

クラウド移行期に勝ったのは明らかにMTTR側でした。壊れないサーバーを大事に守るより、壊れたら捨てて作り直すほうが速くて安い。これ自体は正しかったと思ってます。ただし業界はもう1つ学んでいて、ハシモトさんの言葉では、MTTRは素晴らしいが壊れにくく作るという設計まで丸ごと放り投げていいわけではない、となります。

バグを直す速さを誇る会社ほど、壊れやすくなっていないか

今のAI開発で再演されているのは、この「MTTRさえあればいい」という極端のほうです。投稿はその思考様式をこう要約しています。バグを出荷したっていい、エージェントが人間には不可能な速さと規模で直してくれるんだから。

経営の言葉に翻訳すると、かなり見覚えがあるはずです。品質の担保を、作る側の設計から直す側の速度へ付け替える判断ですね。しかも短期の数字はきれいに出ます。リリース頻度は上がり、障害の平均復旧時間も縮み、開発チームの評価も上がる。

面倒なのは、この判断を会議で検証しようとすると会話が成立しないことです。ハシモトさんが一番困っていると書いているのもそこで、話題に出した瞬間に「いや、テストは全部カバーしてる」「バグ報告はむしろ減ってる」と即座に打ち消される。どちらも事実なのに、全体像を写していない。

健全に見える指標の裏で、何が壊れているのか

投稿の最後の段落が、経営者にとって一番使えるところです。インフラで一度学んだはずだと前置きして、自動化を突き詰めた先で、復旧だけはやたら得意な災害製造機を自分で組み上げてしまうことがある、と書いています。皮肉が効いていますが、笑えないくらい正確です。

続く3行は、そのまま自社の診断に使えます。

• 個別の指標では健全に見えるのに、全体としては誰にも理解できないものになっていく
• バグ報告は減っていくのに、潜在的なリスクは膨らんでいく
• テストカバレッジは上がるのに、コードが何をしているのかという意味の理解は落ちていく

そして変化があまりに速いので、土台のアーキテクチャが腐っていくことに誰も気づかない。

3行に共通しているのは、左側が測れる数字で、右側が測れない状態だということです。経営会議に上がってくるのは当然ながら左側だけ。右側は誰も報告しないし、そもそも報告するための指標が存在しません。健全に見えているのは健全だからではなく、不健全さを写す指標を持っていないからです。

トークン消費量や導入本数は、成果を測っているか

AI導入のKPIとして、トークン消費量、導入ツールの本数、社内の利用率あたりを置いている会社は多いはずです。

これらは全部「どれだけ使ったか」の指標であって、成果の指標ではありません。使用量をKPIにすると、組織は素直に使用量を増やしにいきます。増えた数字は会議で順調ですと読み上げられ、右側の劣化は誰の議題にも乗らない。

では何を見ればいいか。成果1件あたりの値段で見るのが一番早いと思ってます。AIに月いくら払って、その結果出荷された機能が何本で、そのうち3ヶ月後も手を入れずに動いているものが何本か。最後の1つを入れると指標の性格が変わります。出荷した時点ではなく時間が経ってから評価するので、右側の劣化がようやく数字に現れてくる。

もう1点、AI導入の成否を誰が測っているかという問いも効きます。導入を推進した本人が効果測定まで持っているなら、それは評価ではなく報告です。測る人を分けるだけで、上がってくる数字の顔つきが変わりますよ。

経営会議でそのまま使える5つの問い

明日の会議で配れる形にしておきます。

1. AIのKPIは、使用量を測っているか成果を測っているか
2. 直近3ヶ月に出荷した機能のうち、今も手を入れずに動いているのは何割か
3. AI導入の効果を測っているのは、導入を決めた本人ではないか
4. 「テストは通っている」以外の言葉で、品質を説明できる人が社内にいるか
5. 今のシステムの全体像を口頭で説明できる人は、何人残っているか

5番目が一番効きます。この人数が減っていること自体は、どのダッシュボードにも出てきません。しかも減っていく過程では、リリース頻度も復旧時間もずっときれいなままです。

ハシモトさんの投稿は「I worry」の1行で終わっています。心配している、と。結論も処方箋も書かれていません。ただ、自社について同じことを心配できているかどうかは、この5つを配れば1回の会議で分かります。まずは2番の数字を出してみるところからどうぞ。