業務の自動化

情シスの仕事には、入退社の処理・アカウントの棚卸し・定期の報告など、同じ手順のくり返しが多くあります。自動化の道具は、何と何をつなぐかと、誰が保守するかで選びます。

選び方の目安：会社がふだん使っている基盤（Google 中心か Microsoft 中心か）の道具を優先し、ほかの人も読めて直せるものにします。権限の強い処理（ユーザーの作成・削除）は、個人ではなく専用のサービスアカウントで、必要な権限だけを付けて動かします。

ノーコード・ローコード（n8n・Dify・Zapier・Power Automate）

自動化は、作る時間と保守の手間がかかります。件数が多いものと、漏れたときの危険が大きいものから始めると、効果が大きくなります。

最初から全部をつなごうとせず、件数が多いもの・漏れると危ないもの（退職時の停止）から始め、手作業の時間がどれだけ減ったかを測ります。

入社と退職は件数が多く、漏れると危ないので、自動化の効果がいちばん大きい手続きです。人事システムへの登録をきっかけに、IdP・SaaS・ヘルプデスク・端末の手配までをつなぐ例です。

1. 人事システムに入社予定者が登録される。
2. IdP にアカウントができ、部署のグループに入る → SCIM で Slack・各 SaaS のアカウントができる。
3. ワークフローがヘルプデスクにチケットを作り、PC の発送（ゼロタッチ）を手配する。
4. 入社日の前日に、上長と本人にログインの案内をメールする。
5. 退職日には IdP を止め、SCIM の非対応の SaaS は担当者へのチケットを自動で作り、完了をチケットで記録する。

ノーコード・ローコードの道具を使うと、画面で部品をつなぐだけで「フォームに入力されたら Slack に通知して、スプレッドシートに追記」のような自動化や、社内の文書を答える AI チャットを作れます。情シスは、自分で作るだけでなく、各部署が作るもののルールづくりも担います。

情シスとして決めること：

• 認証情報：連携に使う API キー・OAuth の権限は誰のアカウントか。作った人が退職すると止まるので、部署のサービスアカウントで。権限は最小限に
• データの行き先：顧客情報・個人情報をどの SaaS・どの LLM に送ってよいか。セルフホストの n8n・Dify なら社外に出ない構成にもできる
• 台帳と持ち主：何が動いているか、誰が直すか。止まったときに業務が止まるものは、手順書と監視を
• セルフホストの運用：n8n・Dify を自社で動かすなら、更新（脆弱性）・バックアップ・ログイン（SSO）・外部公開の制限は情シスの仕事になる

自動化は作って終わりではありません。作った人が異動・退職すると、誰も直せない「ブラックボックス」になり、止まったときに業務が止まります。

• 属人化を防ぐ：コードは Git（GitHub など）で管理し、何をするか・どこで動くか・止まったときの手作業の手順を README に書く。個人のアカウントではなく、部署のサービスアカウント・共有の環境で動かす。作ったものは台帳（名前・目的・持ち主・使っている権限）に載せる。
• 失敗に気づく仕組み：失敗したらチャットやメールに通知する。何も起きない「静かな失敗」に備えて、「今日の処理が終わった」という成功の通知や、件数の記録も残す。API キーや証明書の期限切れ、連携先の SaaS の仕様の変更はよくある原因なので、期限を台帳に書いておきます。