AIを使うと、以前なら「詳しい人に頼まないと作れなかった」社内ツールや自動化を、現場の担当者自身で作れる場面が増えてきました。

毎朝のExcel集計を自動化したり、入力内容から定型メールを作ったり、複数のファイルをまとめたり。

こうした業務改善を現場ですぐ形にできるのは、かなり大きなメリットです。

ただ、便利な仕組みができたときに、もう一つだけ考えておきたいことがあります。

その仕組みを作った人が、来月異動しても使い続けられるでしょうか。

これはAI時代に突然生まれた問題ではありません。

Excelマクロ、VBA、Access、個人で作ったスクリプト、ノーコードツール。

昔から会社では、「すごく便利だけど、作った人しか分からない」という仕組みが生まれてきました。

AIで変わったのは、こうしたツールを作れる人の範囲と、作れるスピードです。

だからこそ、AIで社内ツールを作ること自体を止めるのではなく、作ったあとに最低限の情報を残しておくことが、以前より大切になっています。

先に結論:立派な仕様書はいらない。あとから見つけられる場所に残そう

専任のIT管理者がいない会社で、社内ツールを1つ作るたびに申請書や設計書を何枚も作るのは現実的ではありません。

まずは、次の2つだけ意識すれば十分です。

  1. そのツールについて最低限の情報を残す
  2. 作った本人だけではなく、ほかの人もあとから見つけられる場所へ置く

保存先は、会社ですでに使っているもので構いません。

  • 共有フォルダ
  • Google Drive
  • SharePoint
  • Teams
  • Notion
  • 社内Wiki

大切なのは、ツールを作った本人のPCのデスクトップや、本人しか見られないメモの中だけに置かないことです。

完璧に書けなくても問題ありません。

「何のための仕組みか」「誰が作ったか」「止まったらどうするか」が分かるだけでも、何も残っていない状態とはかなり違います。

AIで増えやすくなっただけで、問題自体は昔からある

「AIで社内ツールを作ると危ない」という話ではありません。

たとえばExcelマクロでも、昔からこんなことがありました。

  • 月次集計を自動化したマクロがある
  • 毎月みんなが当たり前に使っている
  • でも、どう動いているか知っているのは作成者だけ
  • 作成者が異動したあとにエラーが出る
  • 誰も直せず、元の手作業も忘れている

Accessで作った小さな管理システムや、担当者が書いたスクリプトでも同じです。

AIによって、この状態が起きる可能性がなくなったわけではありません。

むしろ、コードを詳しく知らなくても短時間で仕組みを作れるようになったことで、社内に小さなツールが増える速度は上がりやすくなりました。

さらに、誰が何を作ったか共有されていないと、同じような目的のツールを別の人がそれぞれ作り、どれを使えばよいのか分からなくなることもあります。

AIのおかげで業務改善の入口が広がったからこそ、「作ったあと」のことも少しだけ考えておくと安心です。

属人化は、詳しい人がいること自体が問題ではない

専任のIT管理者がいない環境では、Excelに詳しい人、パソコンに詳しい人、AIを使うのが得意な人が中心になって業務改善を進めるのは自然なことです。

すべての社員が同じレベルで仕組みを理解する必要もありません。

問題なのは、その人がいなくなった瞬間に、誰も何も分からなくなることです。

たとえば、

  • どのPCで動いているか分からない
  • どのアカウントを使っているか分からない
  • 何のファイルを読み込んでいるか分からない
  • エラーが出たときの連絡先が分からない
  • 元の手作業が分からない

という状態になると、便利だった仕組みが一気に業務上の弱点になります。

属人化を完全になくすというより、詳しい人がいなくても最低限たどれる状態にしておく、と考える方が、専任のIT管理者がいない環境では現実的です。

最低限これだけ残しておこう

ここからが実用部分です。

社内ツールや自動化を作ったら、次の10項目を1ページに残してみてください。

全部埋めなくても構いません。

分かるところだけでも残しておけば、あとから別の人が調べるための手がかりになります。

社内ツールの簡易メモ テンプレート

  1. 何のために作った? 解決したかった困りごとは?
  2. 何ができる?
  3. どう動いてる?
  4. 何を使ってる?
  5. アカウントは必要?
  6. 作った人は誰?
  7. 止まったらどうする?
  8. 気をつけることは?
  9. どこに置いてある?
  10. いつから使ってる?

これだけです。

コードの詳しい説明や、システム構成図まで必ず作る必要はありません。

まずは「知らない人が読んでも、その仕組みの存在と役割が分かる」ことを目標にしてください。

やさしい言葉でいい。必要ならあとから正式な管理項目へ発展できる

会社によっては、将来的に社内ルールや管理台帳へ発展させたいこともあるでしょう。

その場合は、同じ内容を少し固い言葉へ置き換えられます。

やさしい言い方 固く・正式に言うなら
何のために作った? 解決したかった困りごとは? 目的 / 導入目的 / 背景 / 課題
何ができる? 機能概要 / 提供機能
どう動いてる? 処理概要 / システム概要
何を使ってる? 利用サービス / 構成要素
アカウントは必要? 利用アカウント / 認証情報
作った人は誰? 作成者 / 担当者
止まったらどうする? 障害時対応 / 代替運用
気をつけることは? 運用上の注意事項 / 定期保守
どこに置いてある? 保管場所 / ソース・設定の所在
いつから使ってる? 利用開始日 / 導入日

固い表現の方が正しいわけではありません。

専任のIT管理者がいない会社なら、「止まったらどうする?」と書いてある方が、むしろ現場では意味が伝わりやすいこともあります。

大切なのは、立派な名前を付けることではなく、必要な情報が残ることです。

記入例:毎朝のExcel集計を自動化したツール

テンプレートだけではイメージしにくいので、架空の例を見てみます。

営業部では以前、毎朝3つのExcelファイルを開き、数字を1つの集計表へコピーする作業に約30分かかっていました。

そこで営業部の担当者がAIを使い、指定フォルダに入ったExcelを自動でまとめる小さなツールを作ったとします。

1. 何のために作った?

毎朝、3つのExcelを手作業で1つにまとめるのに約30分かかっていたため。

2. 何ができる?

指定フォルダに入っている3つのExcelを読み込み、1つの「営業日次集計.xlsx」にまとめる。

3. どう動いてる?

平日の朝9時に自動で動く。

共有フォルダの「日次データ」からExcelを読み込み、処理が終わると「集計済み」フォルダに結果を保存する。

4. 何を使ってる?

  • Excel
  • 社内の共有フォルダ
  • AIを使って作成したスクリプト
  • 自動実行のためのWindowsの設定

5. アカウントは必要?

共有フォルダへアクセスできる会社アカウントが必要。

個人のメールアドレスや個人契約サービスは使っていない。

6. 作った人は誰?

営業部 Aさん。

現在の問い合わせ先は営業部の業務改善担当。

7. 止まったらどうする?

ツールが動かない日は、以前と同じように3つのExcelを開き、「営業日次集計.xlsx」へ手動でコピーする。

手動集計の順番は、このメモと同じフォルダにある「手動集計のやり方.pdf」を見る。

8. 気をつけることは?

  • 元Excelの列名を変更すると動かなくなる
  • 「日次データ」フォルダの名前を変更しない
  • 毎年4月に年度フォルダ名を変更する必要がある
  • 担当者変更時は通知先メールアドレスを確認する

9. どこに置いてある?

共有フォルダの「営業部 / 業務改善 / 日次集計ツール」に、ツール本体・設定・この説明メモをまとめている。

10. いつから使ってる?

2026年7月から利用開始。

この程度でも、作成者が突然不在になったときの状況はかなり変わります。

次の担当者は、少なくとも「何をするものか」「どこにあるか」「止まったらどうするか」から調べ始められます。

特に大事:自動化は、手動運用を消してよいという意味ではない

自動化は、うまく動いている間はとても便利です。

毎朝30分かかっていた作業が自動になれば、何か月か経つころには、手作業でやっていたころのことを思い出さなくなります。

ところが、ある日こんなことが起きるかもしれません。

  1. 自動処理が停止する
  2. 作った本人は休み、異動、退職などで不在
  3. ほかの人はツールの仕組みを知らない
  4. 以前どうやって手作業していたのかも分からない
  5. ツールではなく、業務そのものが止まる

ここで覚えておきたいのは、自動化は「手動運用を完全に忘れてよい」という意味ではないことです。

復旧手順を何十ページも作る必要はありません。

最低限、

  • 止まったら何が困るのか
  • 以前はどう処理していたのか
  • 手作業へ戻すなら何をすればよいのか

だけでも残しておく価値があります。

「自動化を直す方法」が分からなくても、「今日は手作業で業務を続ける方法」が分かれば、会社としては助かる場面があります。

「気をつけること」には、未来に踏みそうな地雷を書く

ツールの説明を残すとき、意外と役に立つのが「気をつけること」です。

ここには、正常に動いている今だから分かる、小さな注意点を書いておきます。

たとえば、

  • 1年に1回、年度変更の手作業が必要
  • 元Excelの列名を変えると動かなくなる
  • 特定のフォルダ名を変更しない
  • 担当者が変わったらメールアドレス設定を変更する
  • APIキーや外部サービスの契約期限がある
  • 特定の会社アカウントが削除されると動かなくなる
  • ファイル保存先の容量がいっぱいになると失敗する

といった内容です。

こうした情報は、作った本人には当たり前すぎて、説明として残されないことがあります。

しかし半年後、1年後に別の人が保守するときには、非常に大きな手がかりになります。

パスワードやAPIキーそのものを説明メモへ書く必要はない

最低限のセキュリティも確認しておきましょう。

特にAIでツールを作るときは、「動いたのでそのまま使っている」状態になりやすいため、次の点だけでも見ておくと安心です。

  • 個人アカウントだけに依存していないか
  • 会社を辞めた人のアカウントが消えると止まらないか
  • APIキーやパスワードを作成者だけが管理していないか
  • どんな社内データを読み書きしているか分かるか
  • 誰がそのデータへアクセスできるか分かるか

ここで注意したいのは、説明メモにパスワードやAPIキーそのものを書くことではありません。

「どの会社アカウントを使う」「認証情報は会社の決めた保管場所で管理している」といった、所在と管理方法を残す程度にします。

セキュリティのルールは会社によって違うため、顧客情報や個人情報など重要なデータを扱うツールは、自己判断だけで進めず社内の管理者へ確認してください。

ソースや設定ファイルも「作った人のPCだけ」に置かない

説明メモだけ共有フォルダにあり、肝心のツール本体が作成者のPCにしかない、という状態も避けたいところです。

可能なら、

  • ツール本体
  • ソースコード
  • 設定ファイル
  • 説明メモ
  • 手動運用の手順

を、会社として管理できる場所へまとめます。

さらに重要な仕組みなら、そのデータ自体が失われないようバックアップも考えます。

バックアップの基本的な考え方は、3-2-1バックアップとは?NAS・外付けHDD・クラウドで考えるデータの守り方でも整理しています。

ツールが増えてきたら、次の段階へ進めばいい

社内ツールが1つ、2つの段階なら、共有フォルダに説明メモを残すだけでも十分効果があります。

ただ、会社が大きくなったり、現場で作られたアプリや自動化が増えてきたりすると、「何が存在しているのか」を会社として把握する必要が出てきます。

その段階では、少しずつ管理を発展させます。

たとえば、

申請 → 登録 → 管理者設定 → ドキュメント → 引き継ぎ → 廃止

という流れです。

情シスがいる会社なら、作成者任せにせず、管理者が一覧を持ったり、重要度に応じて確認方法を変えたりすることもできます。

ただし、専任のIT管理者がいない会社が最初からここまでやる必要はありません。

5分で書ける説明メモすらない状態から、いきなり重い申請制度を作っても続かない可能性があります。

まず残す。

増えてきたら一覧にする。

会社の規模や重要度が上がったら、管理方法も少しずつ強くする。

この順番で十分です。

AIで作ったツールは、作成者自身も細部を説明できないことがある

AIへ要望を伝えてコードや自動化を作った場合、ツール自体は動いていても、作成者が内部の細かな処理まで説明しきれないことがあります。

だからといって、AIで作ることをやめる必要はありません。

重要なのは、コードを1行ずつ説明できることより、会社として必要なことが分かる状態です。

  • 何を入力しているか
  • 何が出力されるか
  • どのサービスにつながっているか
  • どのアカウントが必要か
  • エラー時は何をするか
  • 手動へ戻す方法はあるか

これらが分かれば、将来詳しい人へ修正を依頼するときにも話を進めやすくなります。

よくある疑問

小さなExcelマクロでもメモを残した方がいい?

毎月・毎週使っていて、止まると誰かが困るものなら残しておく価値があります。

反対に、自分が1回だけ使う使い捨ての処理まで全部管理する必要はありません。

「ほかの人が使うか」「来月も使うか」「止まったら業務に影響するか」で判断すると分かりやすいでしょう。

AIで作ったものは全部情シスへ申請した方がいい?

会社にルールがある場合は、そのルールに従ってください。

ただ、この記事は専任のIT管理者がいない会社に重い申請制度を作ることを勧めるものではありません。

まずは、会社内で後から見つけられる場所に最低限の情報を残すところから始めます。

誰がメンテナンス担当になるべき?

専任のIT管理者がいない場合は、最初は作成者が担当でも問題ありません。

ただし、作成者以外にも「このツールが存在する」「説明はここにある」と分かる人を1人作っておくと安心です。

仕様書を書く時間がない

10項目を全部きれいに埋める必要はありません。

目的、作成者、保管場所、止まったときの対応だけでも残してください。

ゼロから調査するより、数行のメモがあるだけで次の人の負担は大きく変わります。

まとめ:AIで「作れた」の先を少しだけ考える

AIのおかげで、これまでシステム開発が難しかった会社や現場でも、自分たちで業務改善を形にしやすくなりました。

これは、止めるべき流れではありません。

ExcelマクロやVBAの時代から、現場で作った便利な仕組みは多くの仕事を助けてきました。

一方で、「作った人しか分からない」という問題も昔からありました。

AI時代は、その便利さも、属人化が増えるスピードも大きくなり得ます。

だから、ツールを作ったら5分だけ考えてみてください。

何のために作ったのか。

どこにあるのか。

誰が作ったのか。

止まったらどうするのか。

気をつけることは何か。

これらを、会社のみんながあとから見つけられる場所へ残します。

作れることと、会社として使い続けられることは別です。

AIで業務改善をしやすくなった今だからこそ、「作れた」で終わらせず、作った人がいなくても次の人がたどれる状態まで少しだけ考えておくと、便利な仕組みを長く使いやすくなります。