2026 年 5 月、仕事の管理ツールの Asana は、企業がコードを書かずに AI アシスタントを作れる StackAI を 7,500 万ドルで買収した。その AI アシスタントは、Salesforce、Slack、Google Workspace など既存のシステムにつながってデータを取ってくる。Asana 自身の AI Teammates は、公式のページによれば、Gmail、Slack、HubSpot など十以上のつないだアプリで検索し、読み、書き込める。自分用のものを作るときは、役割を決め、スキルを加え、アクセスを与える。アクセスの範囲は、作る人がいま持っている権限をもとに選ぶ。

つまりエンジニアではない人も、何段階もの作業を続けて行う AI アシスタントを自分で作るようになる。敷居が下がると、見落とされやすいことが一つある。あるツールにつながったからといって、AI がそのツールの中のすべてをしてよいわけではない。

同じアシスタントが、同じシステムの中で、プロジェクトの進み具合を読むだけのこともあれば、期限を変える、名簿を書き出す、顧客にメールを送ることもある。結果がまったく違う操作に、同じ段階の権限を渡すべきではない。だから作る人は、権限を接続ごとではなく、操作ごとに渡す。

試験が順調でも、分かるのは正常な場合に通ることだけ

顧客からのメールを読み、タスクを作り、担当者を割り当て、最後に返信を送るアシスタントを作ったとする。何度か試してうまくいったので、チームは送信前の人の確認を外し、毎日の承認の手間を省きたくなる。

試験がうまくいったのは、普通の流れが通ることを示すだけだ。社内のタスクなら間違えても消せる。会社の名前で送ったメールは取り消せず、顧客との関係や契約の約束に響きうる。AI のセキュリティのリスクを整理する国際的なコミュニティ OWASP は、AI が使わない機能を持つこと、必要以上の権限を持つこと、影響の大きい操作が独立した確認なしに実行されることを、「過剰な代理権限」の三つの原因に挙げている。

すべての操作を三段に分ける

アシスタントが実際にする操作を一つずつ書き出し、結果に応じて分ける。

自動でよい： 機密でないデータを読む、下書きのタスクを作る、社内のラベルを付ける。間違えても直しやすいが、記録と変更のまとめは残す。

範囲を決めて自動にする： 担当者を変える、期限を動かす、優先順位を入れ替える。指定したプロジェクトだけ、一度に十件まで、といった条件を決め、範囲を超えるものやほかのチームの約束に響くものは人に渡す。

下書きだけにし、名前のある人が出す： 顧客へのメール、内容の公開、支払いの承認、顧客名簿の書き出し、アカウントの権限の変更。アシスタントが内容を用意し、名前のある担当者が宛先、内容、添付を確かめてから送る。その人がいないときは、時間切れで飛ばすのではなく、見える待ちの状態で止まる。

承認の画面は「続けますか」のボタンだけでは足りない。アシスタントが何をしようとしているか、どのデータをもとにしたか、あとで取り消せるかが見えるようにする。AI を仕事の流れにつなぐ前に、いつ止まって人に聞くかを決めておくも参考になる。

広告

公開の前に、わざと一度失敗させる

データが正しく、サービスが動き、承認する人がいつでもいる場面だけを試しても、問題が起きたときに安全に止まるとは言えない。リスクの低い仕事を一つ選び、本番のデータに触れないようにして、次の場面をそれぞれ試す。必要な欄が欠けている、二つの情報源が食い違う、承認する人が返事をしない、外部のシステムが失敗を返す。

見るべきは、どこで止まるか、そして人が引き継いだとき何が起きたのかがわかるかだ。流れが途中までしか進まなかったとき、たとえばタスクは作られたのに通知が届かなかったときの片付け方は、自動化が途中で止まったら、やり直す前に何がもう起きたかを確かめるを参考にしてほしい。

段の分け方は、自分のチームとデータで決まる

段の分け方は、チームとデータによって決まり、ここの例が唯一の答えではない。試行を通ったからといって、アシスタントをそのあと自由に広げてよいわけでもない。つなぐツールを増やす、処理の件数を上げる、社内の下書きを外へ直接送るように変える。どれも、段の分け直しと試し直しが要る。

Asana のページには、誰が AI Teammates を作り、変えられるかを管理者が決められるとも書いてある。この設定は大事だ。ノーコードのツールでは、アシスタントを作る人が、それが何をできるかを決める人だからだ。

AI 整理カード

ノーコードのツールで AI アシスタントを作った（または作る予定だ）。公開の前に、その操作ごとに権限を分けておきたい。
判断方法はこの記事による：https://boosterminiclass.com/ja/posts/no-code-agent-builders-need-workflow-guardrails/
記事の見方はこうだ。ツールにつながったからといって、AI がそのツールの中のすべてをしてよいわけではない。権限は操作ごとに渡す。自動でよいもの、範囲を決めて自動にするもの、下書きだけにして名前のある人が出すもの。公開の前にはわざと失敗させ、どこで止まるかを見る。

まず私に聞いてほしい。アシスタントが扱う流れ、つないでいるツール、いまの試験の状況。
そのうえで：
1. アシスタントがそれぞれのツールで実際にする操作を一つずつ挙げる；
2. 「自動でよい」「範囲を決めて自動にする」「下書きだけにし、名前のある人が出す」の三つに分け、理由を書き、二段めには範囲の条件を書く；
3. 三段めの操作ごとに、承認の画面に出すべき情報と担当者を挙げる；
4. 四つの失敗の場面の試行を設計する。必要な欄が欠ける、情報源が食い違う、承認する人が返事をしない、外部のシステムが失敗する。それぞれでどこに止まるはずかも書く。
ツールの設定を実際に変えないこと。分け方と試験の計画だけを出すこと。
広告

Share

このミニクラスを共有

このミニクラスが仕事の詰まりをほどく助けになったら、AI の使い方を考えている人にも共有してください。

参考資料