AIに「業務改善」を頼む前に② ～ 判断プロセスをSkillにしてみた

🔶はじめに

前回の記事では、AIで業務改善を考える場合、
「作る手段」と「動かす手段」を分けて考える、という話をしました。

今回は、
「業務改善・自動化・技術選定」の判断プロセスを汎用Skillとして作成した話です。

このSkillを使う場面は、このような時です。

✅ なぜ、業務改善の仕組みをSkillにしたのか

AIに業務改善を相談すると、方法がいくつも出てきます。
Skill、スクリプト、VBA、Power Query、Power Automate、自作プログラムなど…

今ではAIに「こうしてほしい」と依頼すれば、
その場でファイルを操作して、自動処理まで行える場面もあります。

ただ、それは「今回、その場で動いた」という話です。

業務として自動化するには、
その作業をおこなう流れ全体で成り立つかという視点が入ります。

例えば、

といった条件によって、選べる方法は変わります。

業務を整理し、その業務を実行する環境を確認し、その条件の中で方法を比較する。

これまで資料に整理しながら積み上げてきた判断基準をSkillにして育てていけば、今後の業務に活かせると思って作りました。
一部抜粋して、全体構成を整理してみます。

✅ 業務改善Skillの全体構成

このSkillは、『 business-automation-advisor 』です。
仕組みは、「SKILL.md」と「references」に分けて構成しています。

Skill本体にすべてを書き込むのではなく、
判断プロセスと具体的な確認項目を分離することで、後から見直すときにも役割が分かりやすくなります。

---
name: business-automation-advisor
description: >
  事前設定された利用環境と制約を前提に、業務課題を整理し、改善方式、
  自動化の実行手段、作成手段、テスト計画を比較・設計する。
　既存資料の確認を伴う業務改善相談に使い、具体的な実装は確認済み条件の範囲で行う。
metadata:
  short-description: 業務改善・自動化・技術選定を支援
---

📂 SKILL.mdには、判断プロセスをまとめた

Skillの中心になるSKILL.mdには、
”業務改善を進める際の判断プロセス”をまとめています。

業務をどう確認し、どの順番で判断していくか。
①～⑩は、その流れを共通化して要約したものです。

📂 Skillの構造を役割ごとに分けた

referencesには、
”判断基準・資料や既存処理の解析・技術候補・検討結果を残すための情報”を置いています。

4つのreferencesは、それぞれ役割を分けています。

基本となるSKILL.md で「何をどの順番で判断をするか」
組み合わせた各references で「判断するときに何を確認するか」
を設定しています。

✅ 職場環境は「事前設定」として汎用的にした

もう一つ、
Skillを汎用化するときに考えたのが、職場環境の扱いです。

例えば、利用できる技術や権限が違えば、同じ業務でも候補になる方法は変わります。
そして、その条件にも変動があります。
この「事前設定」を、5つの区分に分けています。

初回設定時にSkill内の  [記入] 欄に設定し、AI側でその環境を確認して、その条件の中で判断する構造にしています。
変動があれば、更新します。

【例】

### 実行者の環境

- OS・端末：［記入］
- 利用アプリ・サービス：［記入］
- マクロ・スクリプト・ローカル実行の可否：［記入］
- ソフトウェアのインストール可否：［記入］

### 設計者の環境・権限

- 利用できる開発環境：［記入］
- 利用できるAI：［記入］
- 権限の制約・利用できない製品：［記入］
- AI実行環境の制約：［記入］

### データ・セキュリティ

- データの保存場所：［記入］
- 社内ネットワーク限定の要否：［記入］
- 外部Web通信・外部API連携の可否：［記入］
- 外部サービス・プラグインの承認条件：［記入］
- 配布、共有、ログ保存、個人情報の制約：［記入］

### 利用可能な技術

- 表計算・文書・メール等の標準機能：［記入］
- スクリプト・マクロ・データ変換：［記入］
- ワークフロー・通知・承認：［記入］
- AIエージェント：［利用条件を記入］
- Python等の実行環境・追加ライブラリ：［記入］
- データベース・社内API・RPA：［記入］

### 判断の優先順位

- セキュリティ・権限・監査：［記入］
- 正確性・再現性：［記入］
- 実行者の使いやすさ：［記入］
- 導入・保守の負担：［記入］

また、「設計者」と「実行者」は
同じ人が両方を担当する場合もありますが、役割としては分けて考えます。

案件ごとの条件については、会話の中で確認します。

🔷まとめ

このSkillは、いきなり改善案を出すのではなく、
まず業務内容や必要に応じて既存資料・既存処理を確認します。

業務を工程と課題の型から見て、実行者の環境と照らし合わせ、実行手段と作成手段を分けて改善案を比較します。

判断の仕組みは共通にして、環境は「事前設定」として切り出しています。

この記事では、業務改善をAIに相談する前の「Skillの設計」までをまとめてみました。

次回の記事では、
実際にこのSkill が、どのように業務を分解するのか、課題をどう分類するのか、候補をどう比較するのかについて、具体的に整理してみます。