事例

「動きません」で止まる人と、「更新の入れ替えが失敗したようだ」と言える人

泉水亮介2026年7月17日

受講を始めて3週間の受講生から、こんな投稿があった。もともと非エンジニアの人だ。

「Cursorのアイコンを押しても起動しません。本体のCursor.exeごと消えているみたいです」

ここまでなら、よくあるトラブル報告で終わる。でもその投稿には続きがあって、原因の見当まで自分で書いてあった。僕が価値を感じたのは、消えたアプリが直ったことではない。この人の頭の中で起きていた変換のほうだ。

症状の裏側を、自分で言い当てていた

その受講生の見立てはこうだった。自動更新が新しいバージョンを一時的な展開フォルダにいったん置き、そこから本来の場所へ引っ越して、古い自分を消す。その「引っ越し→自分を消す」の途中で失敗すると、新版も旧版も無い、本体だけが消えた状態が残るのではないか。

念のためCursorのコミュニティフォーラム（forum.cursor.com）を当たってみた。僕が確認した範囲では、同じ症状の報告がいくつか見つかり、その原因として「更新時にアプリのプロセスがファイルをつかんだままで、置き換えに失敗する」「プロセスが大量に残っていた」「更新の途中プロセスが残って再試行までブロックされる」といった説明が利用者どうしで共有されている、というところまでだ。ベンダーの公式な原因説明を読んだわけではないので、断定はしない。それでも、受講生の見立てと、フォーラムで語られている構造は、きれいに重なっていた。

今回のケースでは、本人が残っていたプロセスを終了させたうえで入れ直し、それで復旧できたと報告があった。あらゆる同種の症状がこの手順で直る、という話ではない。そもそも復旧手順そのものは、この記事の主題ではない。この種のツールの操作手順は、僕の実感では驚くほど短い周期で古くなる。

起きていたのは「症状」から「構造」への翻訳だ

注目すべきは、この人が非エンジニアとして受講を始めて、まだ3週間だという一点だ。

「アイコンが反応しない」は症状だ。目に見えているものをそのまま言っただけの状態で、ここには原因の仮説が一つも入っていない。一方「更新の入れ替えが途中で失敗した状態」は構造だ。目の前で起きている現象を、その裏で動いている仕組みの言葉に置き換えている。

この翻訳ができるかどうかで、AIに投げる問いの中身が変わる。ここからは僕の見立てだが、それが出力の差になって返ってくる。

「起動しません、直して」と聞くのと、「更新の入れ替えが失敗して本体が消えたようだ、どのフォルダを消して入れ直せばいい？」と聞くのとでは、前提として渡している情報量が違う。前者にはアプリ名と症状しかないが、後者には原因の仮説と、聞きたいことの範囲まで入っている。この受講生は後者の形で問いを立てており、本人の報告によれば、そこから残ったプロセスを止めて入れ直すという手当てまで自力でたどり着いている。僕の経験上、こうして構造を含んだ問いを投げたときのほうが、返ってくる答えは自分の状況に噛み合いやすい。AIが賢くなったのではなく、渡した前提が変わっただけだ。

そしてこの力は、特定のツールの操作手順とは違って、初めて見るエラーや初めて触るサービスにも持ち出せる種類のものだと思う。

導入責任者が本当に見るべき指標

ここからが、経営の話になる。

僕が相談を受けてきた範囲では、社内のAI活用の評価は「ツールを操作できるようになったか」に寄りがちだ。効果測定の話になると、まず操作の習熟度や利用率が出てくる。だが操作は覚えられるし、覚えたそばから古くなる。ツールが変われば、その指標はほとんどリセットされてしまう。

僕が見るべきだと思うのは、詰まったときの言語化だ。同じトラブルを前にして、「動きません」で止まる人と、「たぶんこの処理の途中で失敗している」まで書ける人がいる。この差は、AIを渡したときに成果の差として増幅されうると僕は考えている。前者はAIを持っていても止まったままになりがちだが、後者はAIを使って自力で抜けていく場面を、僕は何度か見てきた。

だから僕は、AI活用が組織に根づいたかどうかを、ツールの利用率だけで見るのは危ういと考えている。詰まったときに投げられる質問の質を併せて見るほうが、先行指標としては筋がいいのではないか。

自分の組織で試せる、最小のレシピ

大がかりな仕組みは要らない。詰まった人が助けを求めるときのテンプレを、4行だけ決めておけばいい。

症状（何が起きたか、見たままを書く）
期待（本当はどうなるはずだったか）
直前の変化（更新した、設定を触った、初めて使った、など）
仮説（自分は何が起きていると思うか。外れていてよい）

このまま人に聞いてもいいし、そのままAIに投げてもいい。狙いは正解を書かせることではなく、4行目を書く習慣をつけることだ。仮説を一言でも書こうとすると、人は「見えている現象」から「裏で動いている仕組み」へ、一歩踏み込むことになる。外れた仮説でも構わない。外れていても、それが議論の取っかかりになり、人からもAIからも訂正の手がかりが返ってきやすくなる（もちろんAIの訂正が常に正しいとは限らないので、鵜呑みにはしない）。仮説が何もない質問は、訂正や切り分けの手がかりが少ないぶん、やりとりが遠回りになりやすい。

冒頭の受講生がやっていたのは、まさにこの4行目だった。僕にはそう見えた、という以上のことは言えない。ただ、この3週間、AIと詰まりながら手を動かし続けた時間のなかで、症状を構造に言い換える癖のほうが先に身についたのではないか、と僕は思っている。

トラブルは避けたいものだが、同時にいちばん学びが濃い教材でもある。組織にAIを入れるなら、トラブルを取り除くことだけでなく、トラブルを構造で語れる人を増やすことにも投資しておきたい。ツールが入れ替わっても、その力は比較的長持ちするのではないか — 少なくとも僕は、そこに賭けている。