もう使っている自作システム、どこから点検する？

小さく作った仕組みが、いつの間にか部署の仕事に欠かせなくなった。利用者は増え、実際の顧客データも入っているらしい。作った担当者は別の仕事を兼任し、止まったときの戻し方は誰も説明できない。「全部止めて調べるのは難しい。でも、どこから見るべきか分からない」。

最初にするのは、大規模な改修でも、全項目の監査でもありません。利用者、実データ、権限、業務への依存を把握し、影響が大きい順に点検します。すでに使っているからこそ、仕事を急に止めず、変更を増やさず、確認できる範囲から順番をつくります。

ただし、情報漏えいや不正アクセス、誤った送信などが現に起きている、またはその疑いがある場合は別です。通常の棚卸しを待たず、社内の事故対応へ連絡し、分かる情報を保全して、影響する接続や操作の制限を担当者の判断へつなぎます。

まず一枚にするのは、システムの構造より利用実態

最初の打合せには、作った人だけでなく、実際に使う人と、その結果を受け取る人を呼びます。一週間または一か月の範囲を決め、次の欄を一枚にします。

• 利用者：どの部署の誰が、どの頻度で使うか
• 実データ：入力する文書・表・会話に何が含まれるか
• 結果：出力をどこへ貼り、誰へ送り、何の判断に使うか
• 権限：利用、管理、設定変更、外部共有ができる人
• 連携：入力元、保存先、メール、他の仕組み
• 依存：止まると困る仕事、期限、代わりの手順

これは、完璧な資産台帳を作る作業ではありません。「誰かが使っている」「たぶん社内だけ」といった推測を、確認済み、未確認、確認する人に分ける作業です。

最初に探すのはコードの欠陥ではなく、誰のどの仕事が、どの情報と権限でその仕組みに依存しているかです。

最優先は、外へ届くものと元に戻しにくいもの

点検項目を、技術的に難しそうな順に並べないでください。誤りや操作が、後から戻しにくい結果へ届くかで優先します。

最初に見るのは、外部公開、顧客への送信、支払い・契約・社内の正本更新へ直接つながる操作です。次に、個人情報や社外秘を含む入力、外部からアクセスできる画面、共有リンク、管理者権限、外部サービスへ渡る認証情報を見ます。確認が終わるまでは、新しい利用者の追加、新しい実データの投入、外部公開、確定処理への接続を増やしません。

米国の政府機関CISAのInternet Exposure Reduction Guidance は、インターネットへの露出を把握し、必要性や依存関係を評価して低減し、継続して確認する考え方を示しています。AI自作システム専用の監査手順ではなく、支払いや正本更新の優先度を示す資料でもありません。ここでは、外から到達できる場所を先に把握し、必要性と影響を見て範囲を狭める参考にします。

「社内向け」という呼び名だけで判断せず、実際の共有設定と到達経路を確認します。分からない間は、結果を下書きに限る、公開情報だけを入力する、担当者が管理権限を必要な役割に絞るなど、業務を続けながら影響を狭くできる場合があります。管理者を一人に集中させるのではなく、不在時にも会社が停止・復旧できる経路は残します。

次に、止まったときの業務と代替手順を見る

毎日使う仕組みだけが重要とは限りません。月末に一度だけ動く集計、特定の担当者しか操作できない仕組み、止まると顧客への期限を守れない処理は、利用回数が少なくても依存が大きい場合があります。

業務依存度は、仕組みが止まる、または誤ると、何人、どの期限、どの判断へ影響するかという見方です。各業務について、次を聞きます。

• 今日止まったら、最初に困る人と期限は何ですか
• 出力が誤っていたら、どこまで届き、後から訂正できますか
• 従来の表、手順、人の窓口へ戻せますか
• 作った人が不在でも、停止と連絡を判断できますか

代替手順がない高依存の仕事は、詳細な点検と戻し方の整備を早めます。代替があり、結果も人が確認する下書きなら、利用を続けながら記録を集められる場合があります。利用回数だけで順位を決めず、停止と誤りの影響を分けて見ます。

優先順位は、直す難しさではなく、止まったときと誤ったときに、仕事へ届く影響で決めます。

その次に、作った人から仕組みを引き離せるかを見る

影響の大きい利用範囲を把握したら、継続に必要なものを確認します。管理アカウントは個人のものか会社のものか。設定、接続先、参照資料、利用料はどこに記録されているか。変更した履歴を追えるか。担当者が異動しても、次の人が管理画面へ入り、停止し、問い合わせ先を探せるか。

ここで作成者を責めても、引継ぎは進みません。試作時には個人のアカウントや手元のメモで始めることがあります。問題は、業務利用へ変わった後も、その状態を誰も把握せず、利用だけが広がることです。

引継ぎ確認では、次の担当候補が、許可されたアカウントと試験環境で一度たどります。本番の資料を試しに更新するのではありません。管理画面へ入る。参照資料を一件更新する。利用者を確認する。変更を記録する。異常時の連絡先を探す。できなかった場所が、次に受け取る手順・権限・記録です。

把握した影響を整理し、点検・利用制限・停止を判断する人へつなぐ

自分が把握した利用者、情報、外部への操作、止まったときの影響を整理して、管理・業務の担当へ渡します。停止や権限変更を独断で行うのではなく、その影響も示して判断を頼みます。担当者は代替手順と合わせ、対応を次の三段階に分けます。

1. 範囲をすぐ狭める：外部公開、確定処理、機密情報、広い管理権限など、影響が大きく未確認のもの
2. 使いながら詳しく確かめる：人が結果を確認でき、代替手順があり、影響を限定できるもの
3. 次の更新時に整える：影響が小さく、利用と担当を把握でき、戻し方もあるもの

変更する前に、現在の入力と出力、設定、連携、利用者を記録し、戻す状態と判断者を決めます。通常の一件と例外の一件で変更後を確かめ、差が出たら設定、データ、手順、業務上の定義のどこに戻るかを分けます。

報告の一枚には、把握できた利用範囲、業務依存度、当面狭めた範囲、詳細確認の担当と期限、次の変更、戻し方を載せます。点検の成果は問題の数ではなく、影響の大きい未確認から、誰が何をするかを決められたことです。

稼働中の影響が大きい未確認から、利用範囲と点検の順番を決める

すでに使っている自作システムの点検は、全面停止や全面改修から始める必要はありません。利用実態を一枚にし、外へ届く操作と情報、業務依存、担当者への依存の順に見ます。

まず、自分が作った、または使っている仕組み一つの利用実態を書いてみてください。見えない設定は未確認のまま担当へ渡し、影響の大きい箇所から相談します。動いている仕事を勝手に止めず、確認担当と当面の利用条件を決める材料をそろえます。

参考資料

• CISA「Internet Exposure Reduction Guidance」