PCのマザーボードが物理破損して、2営業日のあいだ仕事のパフォーマンスが1/5に落ちました。
VSCodeを3ウィンドウ並べてClaude Codeを走らせていた頃の自分が嘘みたいに、会社スマホ1台で各方面に頭を下げて回るしかなくなったのです。
そこで気づきました。ぼくが恐れるべきはハードの故障そのものではなく、「AIが使える環境ありき」で仕事を組み立ててしまっていた自分の脆弱性のほうだと。
そしてこれは、明日Claudeが落ちても同じ構造で破綻します。
AI時代、PCは仕事の根幹に戻った#
クラウド全盛で「PCなんてブラウザさえあれば」と言われた時代は、AIの登場で静かに終わっています。ぼく自身、PCがなければ何もできない仕事の組み方に、いつの間にか戻っていました。
ブラウザだけで完結できた時代との違い#
少し前まで、仕事のかなりの部分はブラウザだけで完結していました。
Microsoft 365もGoogle Workspaceも、ブラウザさえ立ち上がればだいたいのことはできます。スマホでもタブレットでも、端末と呼べるものが手元にあれば資料は作れるし、メールも会議もこなせました。ローカルにアプリを抱えておく必然性は、どんどん薄れていったはずでした。
ところがAI、それもLLMをワークフローに組み込んだ瞬間、話が変わりました。
ぼくの仕事を例にあげると、Claude Codeでローカルのファイルを編集し、GitHubにコミット・プッシュしながら開発を回しています。資料作成も、まずローカルでAIと壁打ちして粗を出し切ってから、SharePointやBoxの共有フォルダに置いて人にレビューしてもらう、という流れです。
つまり「叩き台を出すレベルまでAIで詰めるのはローカル」「最終形を共有フォルダで人に見てもらう」が当たり前になっています。AIを使い込むほど、ローカル環境＝PCの存在感はむしろ重くなっていきます。
クラウドツールが充実してもPCがなければ始まらない理由#
AIに指示を出して、何らかの動作をキックする「フック」は、結局のところローカルのPCかサーバーに存在します。
VS Codeを開いてプロジェクトをロードする、プロンプトをフォルダ単位で走らせる、CLIから複数のAIエージェントを並列で動かす——これらはどれも、スマホやタブレットでは現実的にできません。
ブラウザ版のチャットUIだけなら確かにスマホでも触れます。でも、自分の手元のコードベース・資料・ローカルナレッジに対してAIを噛ませる作業は、PCが立ち上がってナンボの世界です。
PCが動かない＝AIベースの仕事ができなくなる、という構図が、AI時代になって新しく組み上がってしまったわけです。
PCが壊れて仕事が1/5になった#
AIありきの仕事設計がいかに脆いか、ぼくは身をもって食らいました。実をいうと、ぼく自身もまさか自分のPCが物理破損する側になるとは思っていなかったのです。
マザーボード破損から2営業日間に何が起きたか#
ぼくが使っていたPCは、2021年に払い出された会社支給品です。気づけば5年近く使い続けていた計算になります。
これは会社のエコ方針によるものです。「ハードがまだ生きているなら、パフォーマンス問題が出ない限り使い倒すべき」というコンセプトで、PCのパフォーマンス逼迫状況をリモート監視し、データ上「もう交換しないと仕事が回らない」と判定されたタイミングで初めて新機種の案内が届きます。それが最近のデファクトスタンダードでした。
考え方は理解できます。でもその裏では、ハードウェアの摩耗リスクが当然のように積み上がる一方でした。
そしてある日、何の前触れもなくマザーボードが死にました。
症状はわかりやすく地獄でした。電源を入れてもスプラッシュスクリーンが出てきません。出たとしても数十分後にフリーズして無反応のまま。PC背面の強制リセットスイッチを押しても状況は変わりません。BIOSのファームウェアレベルを超えた、純粋な物理破損です。
こうなるとAIを使った仕事はできません。会社スマホはあります。ただし会社スマホでは、ポリシー上ローカルでAIを動かすことはできず、できるのはWebチャットベースのやり取りだけです。
幸いITサポートチームの動きが早く、2営業日で代替機を貸し出してもらえました。首の皮一枚です。これ以上時間がかかっていたらと想像すると、いまだに青ざめます。
「画面共有して作業してくれない？」に追い込まれるまで#
代替機が届くまでのあいだ、ぼくは会社スマホ1台で各方面に連絡を取り続けました。
「このプロンプトをそっちのフォルダで走らせて、結果を教えてもらえない？」 「資料を最終化したいんだけど、画面共有しながら一緒に作業してくれない？」
VS Codeを3ウィンドウ並べてClaude Codeを走らせ、別画面でドキュメントを書きながら別のAIに壁打ちさせていた、つい先週までの自分。あの時のスイスイ感とのギャップは、控えめに言って崖でした。
体感パフォーマンスは1/5まで落ちました。AIありきで仕事を組み立てていた自分にとっては、ほぼ致命傷です。
なめてました。「AIで仕事が加速している」と言いながら、加速しているのはAIそのものではなく、AIを動かす環境とぼくの手癖が噛み合っているときだけだったのです。
会社が原因で仕事が止まっているのに、なぜ現場が謝るのか#
PCが壊れても、現場が頭を下げるだけで終わっていいのか——セキュリティポリシーで代替手段がすべて封じられ、管理部門への怒りが積み上がっていきました。
セキュリティポリシーで代替手段がすべて封じられる構造#
PCが死んだあと、ぼくが頭の中で並べた対策案はおおむねこうでした。
- DaaS（クラウドデスクトップ） どこからでも入れる仮想デスクトップを確保しておく
- SSHで入れる開発サーバ 自分専用のリモート環境にコードと環境一式を置く
- 手元の私物端末への退避 個人PCに一部の作業を一時的に逃がす
どれも一見筋がいい対策に見えますが、すべて「会社が許せば」という前提がつきます。
セキュリティ観点として理解はできます。社外に業務データを置かない、私物端末を業務に使わせない、AIにアクセスできるサーバを個人裁量で立てさせない——それぞれ会社視点では当然の判断です。
でも結果として、現場の人間に残る選択肢は「会社支給のPCが動くこと」「会社支給のスマホでWebチャット程度のことをすること」のほぼ2つだけになります。AI時代の仕事は前者がないと組めません。つまりPC1台に全リスクが集中する構造を、ポリシー自身が作ってしまっているわけです。
対クライアント説明を現場に丸投げする管理部門への怒り#
セキュリティで縛るのは構いません。ただ、その縛りで仕事が止まったときの後始末まで現場に丸投げするのは、正直に言うと許せないと思っています。
自社のセキュリティ事由で仕事が遅延したのなら、その対クライアント説明は管理部門自身が前に出てやり切るべきです。「弊社のポリシー上こうなっています、ご迷惑をおかけして申し訳ありません」と一次窓口に立つのは、ルールを敷いた側の責任ではないでしょうか。
それを「お客様への説明は現場でお願いします」で済ませて、プロジェクト遅延の責任まで現場管理職に押しつけるのは、制度設計者の責任放棄です。
でも「制度上はそうなっています」「現場の運用でカバーしてください」と言う人もいると思います。ぼくの見方はこうです——ルールで現場の手足を縛った側が説明責任から逃げるのなら、そのルール自体に正統性はありません。
（この話はずっと書きたかったので、PC破損のついでに吐き出させてもらいました。本筋に戻ります）
PC依存と同じ穴にはまるAI依存のリスク#
PC故障という物理レイヤーの話はここまでです。でも今回ぼくが本当に怖くなったのは、その先にあるAIサービス依存の話です。
「明日からClaudeが数日落ちたら？」という問い#
PCの物理破損は、確率は低いけれど起きるときは起きるイベントです。
では、AIサービスの停止はどうでしょうか。Claudeが、ChatGPTが、Geminiが、何かのインシデントで複数日にわたって落ちたとしたら。あるいは仕様変更で、いま使っているプロンプトワークフローが突然動かなくなったら。
ぼくから見ると、PC依存とAIサービス依存は構造的に同じです。
- 依存対象は外部 どちらも自分の意志ではコントロールできない
- 代替手段は限定的 会社のポリシーや契約縛りで簡単には差し替えられない
- 落ちた瞬間にパフォーマンスが急落 ゆるやかな低下ではなく崖型に落ちる
ハードかソフトかの違いはありますが、自分の生産性が外部のなにかに支えられている、という構造は同型です。今回ぼくはたまたまハード側で躓きましたが、明日はサービス側で同じことが起きてもおかしくありません。
AIの力を自分の力と錯覚する危険#
AIで成果物が出続けると、人はそれを「自分が出した成果物」と錯覚します。ぼくも完全にこちら側でした。
実は、AI使用前と後で、ぼくの「ゼロから組み立てる力」は確実に鈍っています。プロンプトを書く力は伸びました。AIの出力を評価する力もそこそこ育ってきました。でも、白紙の状態から構造を立ち上げて、根拠を集めて、論を組む、という素手の筋肉は明らかに弱っています。このスキルの空洞化は、成果物が出ている限り気づきにくいという点が厄介です。
成果物は出ています。だからスキルが空洞化していることに気づけません。これが認知的オフロードの怖さだと、人ごとではなく身をもって理解しました。
「でもAIをツールとして割り切って使えば問題ないのでは」と言う人もいると思います。ぼくの考えでは、ツール側に思考の中核を預けた時点で、それはもうツールではなく依存先です。
AI活用を極めながら、自分の頭も鍛えろ#
依存の話をさんざんしてきましたが、ぼくはAI活用をやめるつもりはまったくありません。やめたら競争から脱落します。
ポイントは、AI活用の深さと、自分の頭の筋力強化を「並行で」進めることです。
AIが考えていることを聞き続ける使い方#
ぼくが最近意識しているのは、AIの出力を受け取って終わりにしない、という一点です。
具体的には、AIが何かを出してきたら、こういう問いを毎回ぶつけるようにしています。
- なぜこの結論になったのか 根拠は何か、どんな前提を置いたのか
- 他に考えうる選択肢は何か 採用しなかった案とその理由
- この結論が間違っていたとしたら、どこから崩れるか 反証可能性の地図
この問い方は、AIの思考プロセスを自分のものにするための実践的な方法です。
これをやると、AIの出力をそのまま貼り付けて納品する、という最短ルートからは外れます。たぶん作業時間は1.3〜1.5倍くらいになっています。
でもそのぶん、AIが組み立てた思考プロセスが自分の脳に転写されていきます。最初は「教えてもらっている」感覚に近いですが、何百回も繰り返すうちに、自分でも同じ筋道を引けるようになります。AIを家庭教師のように使う、と言ってもいいでしょう。
タイパ的には遠回りに見えます。だからやらない人が多いのです。でも、AI時代に本当に効く投資は、ここに時間をかけることなんだと思います。
生き残るのは「AIも使えて、AIなしでも動ける」人間#
これから生き残るのは、AI活用がうまい人間ではありません。AIも使えて、AIなしでも仕事が止まらない人間です。
AI活用だけがうまい人は、ぼくが2営業日で味わったあの惨めさを、いつかどこかで必ず食らいます。サービス停止、ポリシー変更、価格高騰、その他もろもろの外部要因で、依存先は必ず一度は揺らぐものです。そのとき、素手で立てるかどうかが分かれ目になります。
逆に、AI活用に踏み込まずに「自分の頭でやる」だけの人も、生産性で勝てません。これは別の意味で淘汰されます。
両方やる、しかありません。AIをフル活用して仕事のスループットを上げながら、同時にAIの思考プロセスを自分に転写し続けて、いざAIがいなくなっても動ける筋力を残しておくことです。地味で、面倒で、コスパが悪く見える戦略ですが、ぼくはこれしか勝ち筋を見つけられていません。
まとめ：AIが落ちても仕事できる自分を残しておけ#
PCが壊れて仕事が1/5になった2営業日は、ぼくにとって安くない授業料でした。
学んだのは、AIで加速している自分は、AIを動かす環境が無事であることが大前提で、その前提はいつでも崩れうる、という当たり前のことです。そしてこれはハード故障だけでなく、AIサービスの停止・仕様変更・ポリシー変更でも同じ構造で起きます。
AIの力を自分の力と勘違いしたまま走り続けると、依存先が崩れた瞬間に何も残らない人間になります。ぼくはぐうたらなので楽をしたいのは本音ですが、いざというとき素手で殴り合える筋力は残しておきたい——そういう気持ちがあります。だからAIを家庭教師のようにこき使って、出力だけでなくその思考過程を自分の脳に移し続けています。
明日からClaudeが数日落ちたとして、あなたは自分の頭だけで分析・設計・レビューを回せますか。
その問いに即答できない人ほど、今日からAIの「考え方」を盗みにかかったほうがいいと、ぼくは思っています。
