「同期しているはず」だった
設定はした。動いていた。確認もしたつもりだった。それなのに、止まっていた。
と言うのは、Mac間の自動同期スクリプトのことです。2台のMacが30分おきに裏側で最新の状態を取りに行く——そういう仕組みを組んでいました。組んだのは私自身ですが、書いたのは私の手ではありません。Claude Codeに対話で指示を出し、組み上げてもらった仕組みです。
気づいたのは、動かなくなってから3日後の朝です。片方のMacで編集したファイルが、もう片方に届いていない。記録を見ると、停止していたのは3日前からでした。
止まっていたこと自体より、3日経つまで気づけなかったことの方が、私にはショックでした。「動いている」という前提を、検証していませんでした。設定した本人である私自身が、その前提を疑わなくなっていたのです。
念のため、これは私の手元の作業環境を整えるための、個人的な自動化です。業務クリティカルな仕組みではなく、止まっていても顧客や案件に影響は出ていません。ただ、AIに仕事の一部を任せ始めた人間としては、止まっていることに3日気づけなかった事実そのものが、見過ごせないと感じました。
私は、AIを業務に積極的に取り入れています。Claude Codeも毎日使っています。だからこそ、記録として残しておこうと思いました。
AIに組ませた仕組みは、組んだ過程が薄い
なぜ、3日も気づけなかったのか。
技術的に言えば答えは単純です。死活監視を仕込んでいなかったから。それだけです。停止を通知する仕組みを最初から組み込んでおけば、3日も放置されることはありませんでした。
ただ、私がこの記録で本当に問いたいのは、なぜ私は、監視を仕込もうとさえ思わなかったのか。
振り返って気づいたのは、自分の手で書かなかった仕組みは、組んだ過程が薄いということでした。
自分でコードを書くとき、人は書きながら何度も「これは何のための処理か」を考えます。動作確認の手順を考え、失敗したときの挙動を想像し、止まったときに自分が困る場面を頭の中で何度も想像します。その過程で、自然と「止まったら困るから、通知を入れておこう」という発想が立ち上がります。コードを書く時間そのものが、目的を体に染み込ませる時間です。
AIに組ませると、その時間が抜けます。
「2台のMacを同期したい」と指示を出すと、Claude Codeは数分でコードを書き上げます。動作確認を通せば、それで完成。早い、便利、たいてい動く。けれど、書きながら何度も問い直す時間はありません。私の指示は「同期したい」までで、「何のために同期したいのか」「止まったらどう困るのか」を、私自身がよく考えていませんでした。だから、止まったときに通知を受け取る仕組みを足すという発想に至りませんでした。
動いていることが、目的にすり替わる
仕組みは動いている。動いていることが確認できる。すると次第に、動いていること自体が目的になっていきます。本来の目的——「2台のMacの間で迷わず作業を続けるため」——が、意識の表に上がってこなくなる。仕組みが目的を覆い隠していく、と言ってもよいかもしれません。
そうなると、例外が起きても気づきにくくなります。「動いているはず」という前提に意識が貼りついていて、「そもそも何のための仕組みだったか」が薄れているからです。
AIに任せる範囲が広がるほど、この距離は伸びていきます。コードを自分で書かないから過程が薄れ、過程が薄いから目的が薄れ、目的が薄れているから止まっても気づかない——順番に並べると、別々の出来事に見えて、実は1本の線で繋がっています。
AI導入の現場で、同じ構造を何度も見ている
私個人の話として書いてきましたが、PMO支援の現場でも、規模は違えど同じような構造を見ることがあります。匿名化したうえで、2つのパターンを挙げます。
1つ目は、判断をAIに委ねた結果、判断基準そのものが現場から消えたケース。最初は人が判断していた領域に、AIの提案を補助として入れる。便利だから、次第にAIの提案がそのまま採用されるようになる。やがて、人は「なぜその判断が正しいのか」を説明できなくなる。
2つ目は、自動化のための自動化が走り始めたケース。本来は業務効率化が目的だったのに、いつの間にか「自動化された範囲を増やすこと」が目的にすり替わる。目的が不明確な、止まっても気づかない仕組みだけが、静かに量産されていきます。
これは私の現場感覚だけの話ではありません。米国のITリサーチ会社Gartnerは、2025年6月のプレスリリースで、企業のagentic AI（自律型AI）プロジェクトのうち約40%が2027年末までにキャンセルされると予測しています。主因として挙げられているのは、コストでも技術でもなく、「不明確なビジネス価値」——つまり、何のために導入したかが現場で答えられなくなる状態です。AIプロジェクトの主要なつまずきの場所は、技術ではなく目的の漂流に移りつつあります。
これらの事例で、AIの導入そのものは原因ではありません。トリガーにすぎません。問題は最初から内包されていて、引き金が引かれるのを待っていただけです。
そして、いずれの現場にも共通していたのは、「そもそも何のためにこの仕組みを作るのか、使うのか」が、現場の意識から消えていたことでした。動かすこと、入れること、進めることに精一杯で、目的を問い直す余白がなかった——そういう順番でした。
AI時代の凡事徹底とは、目的を問い続けること
今回の出来事から得た学びを1行で言うと、AIに任せても、目的を持つのは人だということです。
AIは早く、正確で、たいてい疲れません。ただ、AIは今のところ「何のために」を問いません。私の指示通りにコードを書き、私の指示通りに同期し、私の指示通りに動き続けます。目的を持つのは、依頼した側の人間だけです。
私が大切にしている言葉に「凡事徹底」があります。あたりまえのことを、あたりまえに、徹底してやり続ける。AIに任せる範囲が広がる時代の凡事徹底とは、AIに任せた後も、何のためにそれを動かしているのかを、定期的に問い直し続けることだと、私は捉えています。
具体的には、次の3つを置くと効きます。
第一に、任せる前に、何のために任せるのかを1行で書く。 指示を出す前に、紙に書くか、メモに残す。「効率化のため」では曖昧すぎます。「誰のどんな状態を、どう変えたいのか」まで言葉にする。先ほどの私のMac同期で言えば、「同期したい」ではなく「2台のMacの間で迷わず作業を続けるため」と書く。前者は手段、後者が目的です。この1行があれば、止まったときに「届かなくなったのは何か」が見えます。「同期が止まった」ではなく、「迷わない作業が壊れた」と気づける。
第二に、任せた後も、定期的に立ち返る仕組みを作る。 例えば、週に1回、定例会議の冒頭5分でかまいません。上で書いた1行を読み返し、「この目的は今も生きているか」「この目的を果たすために、止まっていたら困ることは何か」を確認します。「このAI活用は、当初の目的を果たしているか」——この点だけを問います。意図を問い直すのは、人の側に残る仕事です。
第三に、AI自身に、AIを点検させる。 ここで一つ、書きながら痛感したことがあります。そもそも私が死活監視を仕込まなかった理由のひとつは、「個人の仕組みにそこまでの開発コストはかけられない」という、過去のエンジニアリングの常識に縛られていたからでした。しかし、組んでくれるのがAIなら、死活監視を1本足すコストは対話で数分です。技術のコストは下がったのに、私自身の判断基準だけが昔のまま残っていたのです。長年ITの現場にいる人間ほど、こうした「無自覚な常識の引きずり」には注意が必要です。
コストの常識が変わったからこそ、AIに点検させるという発想が成立します。もう一歩進めるなら、定例の問い直しの場に、AIを同席させる設計もあります。具体的には、「週に一度、AIに過去の稼働ログや利用状況を解析させ、『当初の目的から逸脱していないか』『放置されているエラーの兆候はないか』をレポートさせるプロンプト」を定期実行する仕組みです。AIを使う側の人間が、AIを使ってAIを問い直す——これがAI時代の凡事徹底の、もう一段進んだ形ではないかと考えています。
まず、自分のプロジェクトに「目的の見える目」を1つ足してみる
自分の関わるプロジェクトに、AIに任せている範囲があるか。 任せた後も、「何のために任せたか」を問い直す目があるか。 そして、止まったときに、気づける仕組みがあるか。
まずはそこから、と私は考えています。
AIを導入したその先に、目的を見失わないための「問い」を設計できているでしょうか。もし、そこに少しでも死角を感じるのなら、プロフェッショナルな外部の目——例えばPMO——を入れてみることも、プロジェクトを正しい軌道に保つための一つの「凡事徹底」です。
