株式会社テイクアステップ 代表取締役社長 兼 一般社団法人BizOps協会 代表理事の祖川慎治です。
この記事の要点（3行サマリ）
- AIエージェントに業務を任せる指示書（Skill）には、人間向けマニュアルの定番である「状況に応じて判断してください」が書けません。曖昧なまま渡すと、AIは止まるか、誤った解釈のまま進みます
- Skill設計で先に決めるのは3つです。条件分岐と例外（どの場合にどうするか）、エラー時の行き先（再実行か、人に戻すか）、操作権限（どこまで任せ、どこから人が承認するか）
- この3つは技術の話ではなく業務設計の話です。BizOpsの一気通貫は「現場教育・定着支援」から「AIへの配布・実行監視」へ形を変え、仕事の抽象度が一段上がります
「AIに業務を任せてみたけれど、思ったとおりに動かない」。こうした相談を受けることが増えました。話を聞くと、原因はAIの性能より、渡している指示書の側にあることがほとんどです。
この記事は、社内でAIエージェントの活用を任された方、業務の自動化を進めたいBizOps・業務改善の担当者、そしてその取り組みを判断する経営者の方に向けて書いています。
Skill（AIが読める業務マニュアル）とは何か、私が実際にどんなSkillを使っているかは「「シートを何人分買うか」から「AIが読めるか」へ ── SaaSの評価軸とBizOpsの仕事が同時に変わる」で書きました。この記事はその続きとして、Skillを書くときに何が難しいのかに絞ってお話しします。
目次
- AIに業務を任せるとき、一番難しいのは何か
- なぜ人間向けのマニュアルは曖昧でも回ってきたのか
- Skill設計で先に決めることは何か
- BizOpsの一気通貫はどう変わるのか
- Skill設計は技術者の仕事ではないのか
- AIに任せる前に、業務マニュアルの何を確認すればよいか
- よくある質問
1. AIに業務を任せるとき、一番難しいのは何か
一番難しいのは、曖昧さを残せないことです。
人間向けの業務マニュアルには、「状況に応じて判断してください」「必要に応じて上長に確認」「適宜対応」と書けます。読んだ人が、経験と空気で補ってくれるからです。
Skillには、これが書けません。AIエージェントに「状況に応じて」と渡しても、どの状況でどう判断すべきかの基準がなければ、AIは処理を止めるか、もっともらしい解釈で先へ進みます。後者のほうが厄介です。誤ったまま、きれいな形で結果が出てくるからです。
だからSkillを書くときは、マニュアルでは省略してきた判断の中身を、すべて言葉にする必要があります。
2. なぜ人間向けのマニュアルは曖昧でも回ってきたのか
人間向けのマニュアルでは、設計と実行の間に「人間の解釈と操作」が挟まっています。
| 人間向けマニュアル | Skill | |
|---|---|---|
| 読み手 | 担当者 | AIエージェント |
| 曖昧な箇所 | 担当者が経験で補う | 補われない |
| 設計と実行の間 | 人の解釈が入る | 直結する |
| ズレの出方 | 人によって結果がぶれる | 設計の穴がそのまま結果に出る |
この「人の解釈」は、曖昧さを吸収するクッションでした。その代わりに、担当者によって判断がぶれ、操作ミスも起きていました。
Skillはこのクッションを外します。設計したとおりに実行されるので、「設計したとおりに動かない」という問題は構造的に起きにくくなります。一方で、設計に穴があれば、その穴もそのまま実行されます。解釈のブレが消える代わりに、曖昧さはすべて設計者に返ってくる。これがSkillベースの業務設計の性質です。
3. Skill設計で先に決めることは何か
私自身、月次の請求書作成などをSkillにしてAIエージェントに任せています。運用してみて分かったのは、Skillの手順そのものより、次の3つを決めるほうに時間がかかるということでした。
| 決めること | 人間向けマニュアルでの書き方 | Skillで書くこと |
|---|---|---|
| 条件分岐と例外 | 状況に応じて判断 | どの条件のときに、どうするか |
| エラー時の行き先 | うまくいかなければ担当者が対処 | 再実行するか、人に戻すか、別の手順に切り替えるか |
| 操作権限 | 担当者の裁量で | AIに任せる操作と、人が承認する操作の線引き |
条件分岐と例外を書き切る
たとえば請求書の作成なら、「金額が一定額を超えるものは上長の承認を挟む」「新規の取引先なら、作成の前に与信の確認をする」といった条件を、例外まで含めて書いておく必要があります。
私の月次請求書Skillも、最初から書き切れていたわけではありません。運用の中で、同じ取引先の行が請求管理シートに複数あるときの扱いを決めていなかったことに気付き、「同一取引先の複数行は1件の請求書にまとめる」というルールを書き足しました。人が手でやっていたときは、無意識にまとめていた判断です。無意識にやっていた判断ほど、マニュアルに書かれていません。
エラー時の行き先を決める
AIエージェントが外部のサービスを呼び出して、エラーが返ってきたときにどうするか。ここを決めていないと、「うまくいかなかったら人が対処する」状態に戻り、任せた意味が薄れます。
私の運用では、記録用のシートに1行書き込む処理で、応答が返ってこないことがありました。失敗だと判断して再実行したところ、実は1回目の書き込みは成功していて、同じ行が2回記録されていました。それ以来、「応答がなかったときは、まず書き込まれているかを読み戻して確かめ、入っていなければ再実行する」という手順をSkillの側に組み込んでいます。
エラーには、再実行してよいもの、人に戻すべきもの、別のルートに切り替えるべきものがあります。どれに当たるかを先に決めておくのが、Skill設計の仕事です。
操作権限の線を引く
AIエージェントにどこまでの操作を許すかも、先に決めておきます。私の請求書Skillでは、請求書の「作成」まではAIに任せていますが、取引先への「送付」はしません。作成された内容を私が確認してから送ります。
作成と送付のように、取り消しやすい操作と取り消しにくい操作を分けて、取り消しにくい側に人の承認を置く。この粒度で権限を設計しておくと、AIに任せる範囲を安心して広げられます。
4. BizOpsの一気通貫はどう変わるのか
BizOpsの特徴は、構想から実行・定着までを同じ人が一気通貫で持つことです（経営企画・情シス・PMOとの違いは「BizOpsは経営企画・情シス・PMOと何が違うのか」で書きました）。Skillという考え方が入ってくると、この一気通貫の形が変わります。
| これまでの一気通貫 | これからの一気通貫 | |
|---|---|---|
| 1 | 構想 | 構想 |
| 2 | 業務設計 | Skill設計 |
| 3 | ツール導入 | AIエージェントへの配布 |
| 4 | 現場教育 | （不要になる部分が増える） |
| 5 | 定着支援 | 実行の監視 |
| 6 | 改善 | Skillの改善 |
人に使い方を教える代わりに、AIに正確な指示書を渡す。定着を見に行く代わりに、実行の記録を見て、Skillの精度を上げる。
Skill設計で先に決める3つ（条件分岐・エラー時の行き先・操作権限）は、実行の監視とSkillの改善を回すほど見つかります。私の請求書Skillに書き足したルールも、実行の記録を見ていて見つけたものです。一気通貫の最後の工程は、なくなるのではなく「人を見る」から「記録を見る」に変わると考えています。
5. Skill設計は技術者の仕事ではないのか
Skillを書くには、呼び出すサービスの仕様をある程度は理解しておく必要があります。ただ、核心は「この業務を、どういう条件で、どういう順序で、どういう例外処理で実行すべきか」を決めることです。これは業務設計の仕事です。
条件分岐を書くには、その業務で起きる例外を知っていなければなりません。エラー時の行き先を決めるには、どこで止まると誰が困るかを知っていなければなりません。権限の線を引くには、どの操作が取り消せないかを知っていなければなりません。どれも、現場に入って業務を見てきた人が一番よく分かっていることです。
BizOpsの仕事は、AIによって消えるのではなく、抽象度が一段上がります。
- 手を動かす仕事 → 手を動かすAIを設計する仕事
- 「どうやるか」を自分で実行する立場 → 「何をすべきか」「なぜそうすべきか」を決める立場
- 業務の実行者 → 業務の設計者・監督者
6. AIに任せる前に、業務マニュアルの何を確認すればよいか
Skillを書く前に、手元の業務マニュアルで次の3つを試してみてください。
- 曖昧な言葉を数える: 「状況に応じて」「適宜」「必要に応じて」「担当者判断」が何か所あるかを数えます。それぞれについて、実際には何を見て判断しているのかを書き出します
- 止まったときの行き先を書く: 各手順で処理が失敗したら、やり直すのか、誰に連絡するのかを1行ずつ書き足します
- 取り消せない操作に印をつける: 送付・支払い・削除のように、後から取り消しにくい操作を洗い出し、そこに人の承認を置きます
この3つが書けた業務から、AIに任せられます。書けなかった業務は、まだ人の判断に頼っている業務です。
7. よくある質問
Q. 曖昧さを全部なくさないと、AIに任せられないのですか？
全部をなくす必要はありません。判断が難しいところは「この条件に当てはまらないものは人に戻す」と書いておけば十分です。曖昧な部分を人に戻すルートを明示しておくことも、曖昧さをなくす方法の一つです。
Q. 例外を書き出しきれる自信がありません。
最初から書き切れる人はいません。私も運用しながら書き足しています。大事なのは、実行の記録を見て、想定していなかったケースを見つけたらSkillに戻す習慣を持つことです。
Q. どの業務からSkillにすればよいですか？
ルールが明確で、例外のパターンが限られていて、AIの出力を人が確認できる定型業務からがお勧めです。確認できる業務なら、ミスに気付いて直しながら範囲を広げられます。
お知らせ
「AIに業務を任せたいが、どこから手をつければいいか分からない」「業務マニュアルが担当者の判断頼みになっている」。そんな経営者・責任者の方は、お気軽にご相談ください。
現場に入って、今の業務のどこに曖昧な判断が残っているかを洗い出し、AIに任せられる形に一緒に整理するところから始めます。初回のご相談は無料です。
参考文献・出典
- 本記事は、筆者が執筆中の書籍『BizOps本(仮題)』第9章「これからのBizOps ── AI時代の全体最適」の議論を、筆者自身の実体験を中心に再構成したものです
- 月次請求書Skillの運用、記録用シートへの二重書き込みの経緯は、いずれも筆者自身の業務での実体験に基づきます
- 請求書の承認条件・与信確認の例は、Skillに書く条件分岐を説明するための例示です
この記事を書いた人
祖川 慎治(そがわ・しんじ)
株式会社テイクアステップ 代表取締役／一般社団法人BizOps協会 代表理事。大手メーカー・大手SIerを経て、HR Techベンチャーで全社の業務改善を担うBPR部署の責任者として社内IT戦略の立案から実行・定着化までを担当。5年で300名から1,400名へ成長する組織とIPO実現を業務基盤の面から下支えした。2021年に株式会社テイクアステップを設立し、BizOps・業務プロセス設計の実行支援を行う。ポッドキャスト「どうする?BizOps」配信中。