AIエージェントの権限設計｜オントロジーで「やっていい操作」を定める

ツールを絞っても、権限は決まらない

「AIに使わせるツールやAPIを絞れば、権限は管理できる」
多くの方が、そう考えていると思います。

でも、それだけでは足りないと私たちは考えています。
ツールを使えることと、業務として正しいことは、別の話だからです。

AIエージェントの権限設計とは、AIに何をさせてよいかを、AIの外側で決めることです。
その単位は、ツールやAPIではなく業務操作にします。「入金を消し込む」「受注の納期を変更する」のような、記録を変える操作の単位です。
まずは、AIが実行できるのは定義した操作だけ、という状態を作る。安心して任せられるのは、そこからです。

シリーズの他の記事も、この記事で説明する言葉を同じ意味で使います。
では、なぜ今、権限をここまで考える必要があるのでしょうか。

書き換えるAIには、別の問いが要る

社員に配る生成AIの多くは、質問に答え、下書きを作るところまでを担っています。
間違えても、人が読んで直せば済みます。

ところが、業務の工数を本当に減らそうとすると、AIに記録の更新まで任せたくなります。
経理なら、入金明細と売掛金を突き合わせて消し込む。営業なら、取引先の依頼に合わせて見積や受注の数量・納期を変更する。
毎月繰り返されるこうした作業をAIが担えれば、担当者は確認と例外の判断に時間を使えます。

ただ、ここから先は、AIの出力がそのまま会社の記録になります。
問いは、「AIは賢いか」から「AIに何をさせてよいか」に変わります。

この問いへの答えは、業界でも1つの方向に収束しつつあります。
許す操作を、業務の単位で、AIの外であらかじめ定める。
Palantir FoundryやMicrosoft Fabric IQは、業務のもの・関係に加えて「許される操作」を定義します。AIは、その上で動きます。
Palantirは2026年4月28日のブログで、AIが始めた操作は既定ではAIが下書きし、人が最終確認すると説明しています。

では、ツールの単位で絞ると、何が起きるのでしょうか。

「請求書を更新できる」は、広すぎる

よくあるのは、「使えるツール」で権限を決めるやり方です。会計システムのAPIを使える。表計算を書き換えられる。
このやり方には、業務として正しいかどうかを判断する場所がありません。

「請求書を更新できる」権限と、「入金を消し込める」権限を比べてみます。

前者なら、請求書のどの項目も、どんな値にでも書き換えられます。
入金がないまま状態を「消込済」にすることも、請求額を入金額に合わせて減らすこともできてしまいます。

後者なら、できるのは、実際にある入金を未消込の請求書に充てることだけです。
金額が合わないときの扱いも、あらかじめ決まっています。

営業でも同じです。
「受注データを更新できる」権限なら、単価も取引先も書き換えられます。「受注の納期を変更する」という業務操作なら、変えられるのは納期だけ。出荷済みの受注は対象外、といった条件も付けられます。

人の担当者なら、広い権限しかなくても、業務の知識と社内規程で控えめに動きます。
AIに、その「書かれていない範囲」を守らせるのは難しい。
指示を取り違えることも、メールに仕込まれた指示に乗っ取られることもあります（プロンプトインジェクションとは？防げない前提の対策と確認8項目）。

OWASP（国際的なセキュリティ団体）も、同じ見方をしています。
LLM（大規模言語モデル）アプリ向けのリスク一覧（2026年版）は、AIには必要な操作だけを持たせ、許すかどうかはAIの外の仕組みで判定するよう勧めています。
エージェント向けのリスク一覧（2026年版）も、必要のない自律性は持たせないよう勧めています。

では、何の単位で絞ればよいか。
私たちの答えは、業務操作の単位です。その土台になるのが、業務の型です。

業務の型は、今あるルールの書き直し

業務の型（オントロジー）とは、業務に出てくるもの・状態・関係・許される操作を、会社として定めたものです。
「オントロジー」はもともと哲学や情報科学の言葉です。このシリーズでは学術的な意味には立ち入らず、「会社の業務の型」という実務の意味で使います。

型は4つの要素でできています。オブジェクト（業務に出てくる「もの」）、状態、関係、業務操作。
入金消込なら、オブジェクトは取引先・請求書・入金。請求書の状態は「未消込 → 一部消込 → 消込済」。業務操作は「入金を消し込む」「消し込みを取り消す」などです。

請求書の状態の欄を、直接「消込済」に書き換える道はありません。
消込済になるのは、「入金を消し込む」という操作が、条件と承認を通ったときだけです。

業務操作は、「何をしてよいか」を次の5つの項目で定めます（数字は説明のための例です）。

前提条件は、実行してよい状態かを、実行のたびにシステムが確かめる条件です。
承認は、効果を確定させる前の許可。人による承認のほかに、人が確定した自動承認ルールによる承認もあります。

新しい仕組みに聞こえるかもしれません。
でも、この5つは、もともと業務マニュアルや職務権限規程に書かれていることが多い内容です。
業務の型は、それをシステムが実行のたびに確かめる形にしたもの。今あるルールを、機械が守れる形に書き直す作業だと考えると、社内にも説明しやすくなります。

「取り消し」を最初から定めておくことにも、意味があります。
AIに任せる以上、間違いは起きる前提で考えます。戻し方が決まっていれば、影響を小さく収められます。

AIがこの操作を提案・実行するたびに、判断ログが残ります。提案・実行の根拠と、人の承認・却下とその理由の記録です。
この記録が、あとで任せる範囲を広げるときの根拠になります（AIエージェントの承認はどの粒度で？承認疲れと自動承認ルール）。

では、定義した操作の外側は、どう守るのでしょうか。

定義にない操作は、そもそも実行できない

業務の型を使うとき、AIに渡すのは定義された業務操作の一覧だけです。会計システムのAPIそのものは渡しません。
AIがどんな指示を受けても、一覧にない操作は呼び出せません。一覧にある操作も、前提条件・権限・承認を満たさなければ効果が確定しません。

許すかどうかを決めるのは、AI自身ではありません。
「この操作はしないで」とAIへの指示に書くだけでは、乗っ取られたときや誤解したときに破られます。
判定するのは、AIの外にある書き込みの関門です。業務操作の条件を満たした書き込みだけを通す場所で、実行のたびに判定します。

これは、AIに限った話ではありません。
2026年9月末から国内で相次いだ不正アクセスでは、内部のAPIを直接呼ばれ、画面からはできない操作を実行される被害が確認されました。
受け付ける側のAPIが「誰が、どの対象に、何をするか」を確かめていなければ、画面で制限していても、画面を通らない呼び出しは通ってしまいます。

JPCERT/CC（国内のセキュリティ事故への対応を調整する組織）は、サーバー側で操作の対象と内容に応じて認可するよう勧めています。APIの鍵をアプリに埋め込まないことも求めています（注意喚起、JPCERT/CC Eyesの調査）。
「請求書APIを使えるか」ではなく、「この請求書に、この入金を消し込んでよいか」を確かめる。業務操作の考え方は、これとほぼ同じです。
AIには鍵を見せず、操作だけを呼ばせます（AIエージェントは誰の権限で動くのか）。

業務操作で権限を絞る考え方そのものは、昔からあります。
基幹システムが公開する業務APIも、稟議の状態遷移を定めるワークフローも、同じ方向を向いています。
たとえばSAP S/4HANAの仕訳転記のAPIは、「仕訳を転記する」単位で受け付けます。取り消しにも条件があります。

だから、形にする方法は1つに限りません。

統制を置く場所は、組み合わせて選ぶ

業務操作の単位で絞るのは、設計の原則です。統制の層をどこに置くかには、主に次の選択肢があります。

どの形にも得意・不得意があり、実際には組み合わせて使うのが普通です。
たとえば、IDとログは管理製品でそろえ、業務の判断は基幹の業務APIか業務の型で持つ。
どれを選んでも、「許す操作を業務の単位で定め、AIの外で判定する」という原則は変わりません。

もう1つ、よく聞かれることがあります。データが、いくつもの場所に分かれていることです。

データは今の場所のまま、1つのものとして扱う

実際の会社では、一つの「請求書」の情報がいくつもの場所に分かれています。
請求額は会計の基幹システム。入金は銀行から取り込んだ明細。取引先とのやり取りはCRM（顧客管理システム）。

業務の型では、これらをまとめて一つの「請求書」として扱います。
そのとき問題になるのが、「どちらの値が正しいのか」です。だから正本（正しい値の置き場所）を、システム単位ではなく項目単位で決めます。
請求額と消込の状態は基幹。入金の明細は銀行の取込データ。取引先とのやり取りはCRM。差額の判断の根拠は判断ログ。

業務操作の結果は、承認のあと、その項目の正本へ書き戻します。
正本は今ある場所に置いたままでよく、基幹システムを置き換える必要はありません。
稟議でよく聞かれる「既存システムをどうするのか」への答えにもなります。

とはいえ、全部の業務を型にしてから始める必要はありません。

型は、使いながら育てる

「会社の業務をすべて型にしてからAIを入れる」と考えると、いつまでも始まりません。
業務の型は、使いながら育てるものだと私たちは考えています。業務の中心になったものから順に、3つの段階で型を付けていきます。

段階1は、列も値も自由な表やメモ。
AIに任せるのは、読んで要約し、下書きを作るところまで。結果は人が確かめて転記します。
同じ表を複数人が使い始めたら、次へ上げます。

段階2は、名前と項目が決まり、ほかのデータと関係でつながった状態。
AIは正しく探して照合し、候補を出します。書き込みはまだしません。
同じ更新作業が繰り返され、判断の基準を言葉にできたら、次へ上げます。

段階3は、状態と業務操作が定義された状態。
AIは業務操作を提案・実行し、承認を通った結果を正本へ書き戻します。
この先は、判断ログを根拠に承認の範囲を広げていきます。

入金消込なら、最初は「入金明細と売掛金を照合して、候補を一覧にする」ところまでをAIに任せます（段階2）。
人がその候補で消し込むうちに、基準がはっきりしてきます。振込名義の表記ゆれはこう扱う。手数料分の差額はこう処理する。
そこで初めて「入金を消し込む」を業務操作として定義し、書き込みを任せます（段階3）。

営業の受注変更も同じです。
まずは、取引先からの依頼メールを読んで変更内容の案を出すところから始められます。

段階3へ上げるときも、いきなり直接の書き込みを止める必要はありません。
業務操作を通らない書き込みを、書き込みの関門で止めずに記録だけする期間を置きます。
既存の運用で何件が引っかかるかを確かめてから止めれば、導入した日に業務が止まりません。

型のないデータに、AIは書き込めません。だから、守りは初日から最大です。
しかも、実際に繰り返された作業から型を作るので、例外の扱いも含めて現場に合った定義になります。
新人に資料を読ませ、照合を手伝わせ、そのあとで更新を任せる。それと同じ順番です。

最初の1業務は、繰り返しの多いものから

最初に業務操作として定義する業務は、3つを満たすものが進めやすいと考えています。
同じ作業が、月に何度も繰り返される。判断の基準を言葉にできる（担当者が新人に説明できる）。取り消し方がはっきりしていて、誤ったときの影響を金額や件数で測れる。
経理の入金消込や、営業の見積・受注の変更は、この条件に当てはまりやすい業務です。

定義には、4つの立場が関わります。
その業務の担当者は、前提条件と例外。承認者は、承認の基準。情シスは、権限と書き戻し先。内部統制の担当者は、職務権限規程との整合。
監査では、業務操作の定義とその変更履歴、判断ログを見せれば、「誰が何を許し、実際に何が起きたか」を説明できます。

導入がスムーズに進みやすいAIの選び方

次の基準を満たすベンダー・作りなら、情シスへの説明が短く済み、導入がスムーズに進みやすくなります。

1. 権限を業務操作の単位で定義できる：ツールやAPIの単位ではなく、「入金を消し込む」のような業務の言葉で、条件・承認・取り消しを決められる
2. 判定がAIの外で毎回行われる：画面からでもAIからでも、同じ判定の場所を通る
3. 承認と判断ログが残る：任せる範囲を広げる根拠と、監査で見せる記録が同じものになる
4. 既存の業務を止めずに締められる：記録だけの期間を置いてから書き込みを絞れ、基幹システムを置き換えずに書き戻せる

それでも、人に残る仕事がある

業務の型は、「AIが何をしてよいか」をシステムで事前に保証する範囲を広げます。
ただ、それですべてが決まるわけではありません。

1つは、定義と見直し。
前提条件や承認の基準が間違っていれば、システムは間違った基準を正確に守ります。定義を誰が持ち、どう見直すかを決め、定義の変更も承認の対象にします。

もう1つは、定義にない例外への対応。
型に合わない案件は、必ず出ます。AIには「できません」と止まらせ、人が引き取る道を用意します。同じ例外が繰り返されるなら、型の方を直します。

最後は、条件を満たした誤り。
別の取引先の入金を充てるような誤判断は、前提条件だけでは防げません。ここは承認と判断ログで扱います。

書き込みの関門そのものと、正本の基幹システムに残る管理者の権限。これを守るのは、基盤と情シスの役割です（AIエージェントは誰の権限で動くのか）。
推進者が持つのは、業務の定義、例外の判断、承認の基準です。

逆に、この方式が要らない場面もあります。
AIに読み取りだけをさせる場合。書き込んでも影響が小さく、すぐ戻せる業務。
こうした場面なら、読み取り専用など、ツール単位の最小権限で十分です。
業務の型に工数をかけるのは、記録を書き換え、誤りの影響が大きい業務からで足ります。

情シスに説明するときの要点

• AIに渡すのは定義した業務操作だけで、システムのAPIや鍵は渡しません。定義にない操作は実行できません
• 許すかどうかはAIではなく、AIの外の仕組みが実行のたびに判定します
• 業務操作の条件・承認・取り消しは、今ある職務権限規程を機械が守れる形にしたものです
• 最初は照合と候補の提示まで。書き込みは基準がはっきりしてから、記録だけの期間を置いて始めます
• 基幹システムは置き換えず、承認を通った結果だけを書き戻します

型があるから、任せる範囲を広げられる

AIの権限は、ツールやAPIではなく業務操作の単位で決め、AIの外で判定する。
業務操作は、前提条件・権限・承認・効果・取り消しの5つで定める。中身は、今ある社内規程の延長です。
最初から網羅はしない。読む、参照して候補を出す、書き込むの3段階で、繰り返しの多い1業務から育てる。

業務の型は、AIを縛るためのものというより、安心して仕事を任せる範囲を広げるための道具です。
システムが持つ部分と運用に残る部分の全体像は、AIエージェントの責任は誰が負う？システムと運用の責任分界で整理しています。

まずは、毎月繰り返している業務を1つ選び、照合と候補の提示から始めてみてください。
型が育てば、AIに任せる範囲は確実に広げていけると、私たちは確信しています。

関連記事

• AIエージェントの承認はどの粒度で？承認疲れと自動承認ルール：判断ログを根拠に、承認の範囲を段階的に広げる
• AIエージェントは誰の権限で動くのか：鍵の置き場所と、AIの操作を人と区別して記録する方法
• AIエージェントの責任は誰が負う？システムと運用の責任分界：システムが持つ部分と、運用に残る部分
• AIエージェントのセキュリティ全体像：シリーズの全体像と、説明資料を作るときの読み方

参考資料

• JPCERT/CC「直近で相次いでいる国内組織における不正アクセスに関する注意喚起」（2026年10月8日公開、10月23日更新）
• JPCERT/CC Eyes「連続不正アクセス事案の攻撃手法に関する調査」（2026年10月15日）
• OWASP Top 10 for LLM Applications 2026（2026年8月公開）
• OWASP Top 10 for Agentic Applications for 2026（2025年12月9日公開）
• Palantir Foundry：Action types overview
• Palantir「Connecting Agents to Decisions」（2026年4月28日）
• Microsoft Fabric Blog「From Data Platform to Intelligence Platform: Introducing Microsoft Fabric IQ」
• SAP「Guidelines for API Journal Entry Post」

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

本文で並べた統制の層のうち、Askhubは「業務の型を持つ基盤」にあたります。業務の型を決めたデータへの書き込みは、サーバー側の1か所でまとめて判定します。画面から直接直しても、AIが書いても、スクリプトでまとめて書いても、同じ書き込みの関門を通るので、経路を変えても判定は変わりません。判定そのものができなかったときは、書き込みを通さずに止めます。締め方も、まず警告で既存の業務への影響を測ってから確定に進められるので、導入した日に業務を止めずに済みます。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連する機能：承認、データベース・ノート