個人のAIハックは、これから2つの形で「静かに死にます」

会社のなかで、誰かが個人的にAIを使った便利な仕組みを作っている。気がついたら、それが業務の流れにそっと組み込まれている。最近、こういう光景をよく見かけませんか？

これは止めなくていい現象だと思っています。むしろ素敵な動きで、社内のAI活用が現場から立ち上がっている証拠です。

ただ、ここからが本題です。

放っておくと、これから2つの形で「静かに死ぬ」事故が増えてくると、予測しています。前回までは3回にわたって「AIエージェントの暴走」をどう防ぐかを書いてきましたが、今回はAIを使う人間側の運用に視点が移ります。

自分が作っている側として、気づきました

自社のAI化を進めているとき、ある瞬間に手が止まりました。

「あれ、この仕組み、自分がいなくなったらどうしようもなくなるな」

便利だから作りました。動いているので業務に使っています。チームメンバーも普通に頼り始めています。
ところがその仕組みは、私の頭の中の前提と、私のローカルにあるファイルと、私のアカウント権限の上で、かろうじて成り立っているだけ。私がいなくなった瞬間、あるいは長期不在になった瞬間、それは突然動かなくなる。しかも、中身を理解できる人が社内に一人もいない。

ヒヤッとしました。自分はまさにロストテクノロジーを生み出している側の人間だ、と気づきました。

これは私だけの話ではないはずです。社内のあちこちで、似た仕組みが、誰かのローカルで動いていると思います。今回はそれを2つの軸で書きます。

1つ目: 静かに死ぬ——「ロストテクノロジー化」

1つ目の事故は、人がいなくなった瞬間に止まるパターンです。

個人がAIで作ったハックは、最初は本人だけの便利道具です。ところが効果があると、自然に周りも頼り始めます。「あの自動化、便利だからうちのチームでも使いたい」と、いつの間にか業務に組み込まれる。ここまでは健全です。

問題はその後で、作った人だけが中身を理解している状態のまま、仕組みが社内資産になっていきます。ドキュメントはありません。スクリプトはローカルです。クラウドの権限は作った本人にしか付いていません。バージョン管理は使っていないので、過去の変更履歴もありません。

この状態で、作った人が転職、休職、長期離脱したら、何が起きるか。

仕組みは動きません。動かなくても、すぐにはエラーが画面に出ません。ある日「あれ、最近あの自動化、来てない？」と誰かが気づきます。慌てて中身を見にいくと、何が書いてあるのか分からない。直そうにも、権限がない。作り直すには、業務フローを全部聞き取り直すところからになります。

物理世界でいうと、長年使っていた機械の図面が、設計者と一緒に消えていたような事故です。動いている間は誰も気にしませんが、止まった瞬間に取り返しがつかなくなります。

「これは将来の懸念ですね」と感じる方がいるかもしれません。私はそう思っていません。もう各社で、それになりかけている資産が動いていると感じています。今、たまたま止まっていないだけです。

2つ目: 静かに漏れる——「サイレントインシデント」

2つ目は、気づかないうちに、機密や秘密鍵が漏れていくパターンです。

個人で動かすAIハックには、しばしば認証情報や顧客の機密データが、ベタ書きで載っていることがあります。本人は「自分しか触らないから」と思って書いている。気持ちは分かります。ただ、その仕組みが業務に組み込まれた瞬間、状況が変わります。

社内のファイル共有に置かれる。引き継ぎのためにチャットで送られる。便利ツールにアップされる。そのたびに、書き込まれた秘密鍵や認証情報が、本人の手の届かないところに広がっていきます。

漏れても、エラーは出ません。前回も書いたように、AIや自動化が絡む事故は、静かに進行します。漏れている事実が誰かに知られるのは、たまたま外部から指摘された時、あるいはもっと悪いケースだと、すでに悪用されたあと、になります。

ルールがない状態で個人ハックが社内に広がっていくと、こういうサイレントインシデントが、これから次々と顕在化してくると思っています。「自分しか触らないから」が「自分以外も触っている」に変わる瞬間が、いつ来るか管理しきれないからです。

前回記事：AIの事故は、静かに進む

ハックを止めるのは、間違いです

ここまでで、「じゃあ個人のAIハックは禁止したほうがいいですね」と感じる方もいると思います。

ただ、これは止めるべきではありません。個人ハックを禁止すると、社内のAI活用は一気に死にます。一番ボトムアップで動いている領域を潰すことになります。AIで先に進みたい会社にとって、これは最大の損失です。

必要なのは、止めることではなく、ハックを安全な形で社内資産に引き上げる枠を作ることです。

必要なのは、両輪

これから個人ハックを「資産」に変えていくために、2つの輪をセットで回す必要があると考えています。

1. 作った人の責任

個人で楽しく作ったものでも、業務に組み込んだ瞬間、それは「自分の趣味」ではなくなります。同僚と顧客の業務が、その上に乗ります。

そうなった時点で、作った人には引き継げる状態にしておく責任が乗ります。
動いていればOK、ではなく、自分以外の誰かが触れる状態を維持する義務です。

私は、自社の仕組みについて意識的にやっていることが、3つあります。

• ワークフローツールに乗せ替えて、可視化された形にする

• マニュアルとドキュメントを整備する

• クラウド環境やバージョン管理を整えて、他のメンバーも触れる状態にする

完璧にできているとは言いません。手が回っていない場所もまだあります。
それでも、「自分しか触れない」を一段ずつ減らす作業を、業務の一部として組み込んでいます。

2. 会社が引き上げる枠

一方で、作った本人だけに責任を押し付けるのは違います。

個人がハックを作ってくれた。それは会社にとっての貢献です。管理する側は、その貢献を仕組みに引き上げられる準備を整えておく必要があります。

具体的には、以下を想定しています（会社の規模やフェーズによって、力を入れる場所は変わります）。

• 個人で作ったハックを、社内の正規ルートに乗せる入り口を設計しておく

• ワークフローツール、クラウド環境、バージョン管理のテンプレを用意して、移行コストを最小化する

• 機密情報の扱いについて、最低限のルールと相談先を整える

• ハックを作った人に「いいですね、次はこういう形にしておきましょうか」と助言できる人が、社内にいる状態を作る

止めるのではなく、受け止める。禁止するのではなく、助言する。
これが、管理する側の役割だと、私は思っています。

3部作の続きとして

前回まで、3回続けて「AIエージェントの暴走」をどう防ぐかを書いてきました。
事故ります、禁止リスト、観測の仕組み。これらは全部、AIそのものが起こす事故の話でした。

今回はそこから視点を少しずらして、AIを使う人間側の運用の話です。
ロストテクノロジー化もサイレントインシデントも、AI自体が起こす事故ではなく、人間の運用設計の不足が静かに事故を育てていく構造です。

個人ハックの時代が、やっと来ています。
これを最大限活かすために、責任と枠の両輪を、今から少しずつ整えていきませんか。

「うちの社内ハック、これで大丈夫かな」と気になる方がいたら、Xでもnoteのコメントでも、気軽に話しかけてください。一緒に整理しましょう。

deflagをもっと知りたい方へ

AIエージェントで少人数経営を実践するdeflagの取り組みを、複数のチャネルで発信しています。

🌐 コーポレートサイト → https://deflag.net
𝕏 X（Twitter） AI・業務自動化の実践情報を配信中 → https://x.com/nakamae__deflag
💼 LinkedIn → https://www.linkedin.com/in/shuta-nakamae-18392828a