実行制御とは、許可された操作をどう実行するかを決める仕組みのことです。
顧問先の資料にAIエージェントを触らせてよいか。この問いに事務所として答えを持っているでしょうか。2026年9月に東京で開かれた日本初のAIエージェント関連カンファレンスでは、企業がMCPを本番運用へ移すとき、何にアクセスできるかを制御するだけでは足りず、許可された操作をどう実行するかまで設計する必要がある、という論点が正面から取り上げられました(出典: AGNTCon + MCPCon Japan 2026 Schedule)。この記事では、その考え方を士業事務所のAIエージェント運用に落とし込み、権限設計の先に置く7つの設計項目を整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で確認しています。
つなげるから実行させるへ 論点が移った2026年のAIエージェント
先に結論を書くと、2026年の論点は、AIをどう業務システムにつなぐかではなく、つないだ先で何を起こしてよいかに移っています。接続の技術的な難しさが下がったぶん、残るのは運用設計の問題です。
その象徴が、2026年9月10日と11日に東京で開かれた日本初のMCP/Agentic AIカンファレンスです(出典: AGNTCon + MCPCon Japan)。このイベントで設けられたセッションのひとつは、企業向けMCPにおいてアクセス制御から実行制御へ、という主題を掲げ、アクセス制御が何にアクセスし何を実行できるかを扱うのに対し、実行制御は許可されたリクエストをどのように実行するかを扱う、という区別を提示しています(出典: AGNTCon + MCPCon Japan 2026 Schedule)。同セッションの説明では、AIエージェントが顧客データを更新する権限を持っていても、すべての更新が同じように実行されてよいわけではなく、業務ロジック、人の確認、監査可能性をツール側に組み込む必要がある、という趣旨が示されています。
この区別は、士業事務所の現場にそのまま当てはまります。事務所でAIエージェントに会計データや案件管理を触らせる場合、アクセス権限の設定だけを見ていると、読めるか書けるかの二択で判断してしまいます。しかし実務で問題になるのは、書けるかどうかではなく、どういう手順で書くかです。金額の桁が1つ違う仕訳を、確認なしに登録してよいのか。顧問先へのメール下書きを、送信まで進めてよいのか。同じ書き込み権限でも、実行のさせ方で結果はまったく変わります。
MCPそのものの安全性については、実装側の責任範囲という整理が先に議論されてきました。接続の入口を固める話はMCPのセキュリティは実装側の責任 事務所が接続前に潰す7点検で扱っています。本記事が扱うのは、入口を通した後、事務所の業務ロジックをどこに置くかという話です。
行政の側でも、AIを利用する事業者に対して、リスクに応じた管理と説明可能性を求める方向の整理が進んでいます。総務省と経済産業省が公表しているAI事業者ガイドラインは、AIを開発・提供・利用する各主体が取るべき考え方を示した文書です(出典: 総務省 AI事業者ガイドライン掲載ページ)。事務所が実行制御を設計することは、この方向と矛盾しません。
アクセス権限の先に置く7つの実行制御の設計
結論として、実行制御の設計は7つの項目に分解できます。どれも技術ではなく、事務所の業務ルールをどこに書くかという話です。
第1は、操作の分類です。AIエージェントに触らせる操作を、読み取り、下書きの作成、内部データの更新、外部への送信の4つに分けます。この4区分は、確認の重さを決めるための軸で、読み取りと下書きは自動で回し、更新と送信は人の確認を挟む、という既定を置きやすくなります。
区分を決めるときに迷いやすいのが、下書きの扱いです。下書きを作るだけなら影響はないように見えますが、下書きが共有フォルダに保存され、別の担当者がそのまま提出してしまう経路があると、実質的には確定と変わりません。区分は操作そのものではなく、その操作の後に何が起こりうるかで決めます。
第2は、閾値の設定です。同じ更新でも、金額や件数によって扱いを変えます。たとえば一定金額を超える仕訳、10件を超える一括更新、過去の確定済み期間へのさかのぼり修正は、自動実行の対象から外すという線の引き方があります。閾値は事務所の実態に合わせて決め、参考値として最初は厳しめに置き、運用しながら緩める順序にすると事故が起きにくくなります。
第3は、人の確認を差し込む位置です。実行の直前に確認を置くか、実行後に一覧で確認するかで、担当者の負担がまったく違います。件数が多く個々の影響が小さい処理は事後の一覧確認、件数が少なく影響が大きい処理は事前確認、という割り当てが現実的です。
第4は、実行の記録です。誰の指示で、どのツールが、いつ、何に対して、どんな操作をしたかを残します。AIエージェントの場合、指示した人と実際に操作した主体が分かれるため、この2つを別々に記録しておかないと、後から経緯を追えません。記録の設計はAIエージェントを事務所に入れる前に決める権限とログの7チェックで詳しく扱っています。
第5は、取り消しの手順です。誤った実行が起きたとき、どこまで戻せるかを先に確認します。会計ソフトの仕訳は取り消せても、送信済みのメールは戻せません。戻せない操作は、そもそも自動実行の対象から外す、という判断につながります。
第6は、失敗時の停止条件です。同じ処理が連続して失敗したとき、エージェントを止めるか、続行するかを決めておきます。止まらない設計にしていると、ひとつの誤りが数十件に増えてから気づくことになります。
第6の停止条件と合わせて決めておきたいのが、停止したことを誰にどう知らせるかです。止まった事実が担当者に届かなければ、処理が滞ったまま翌日を迎えます。通知先は個人のメールではなく、事務所の共有チャネルに出す形にしておくと、担当者が不在の日でも誰かが気づきます。
第7は、権限の棚卸しです。一度与えた接続権限は、担当者の異動や案件の終了後も残りがちです。四半期ごとに、接続しているツールと、そこに与えている操作範囲を一覧で見直す日を決めます。
7項目を一度に整えようとすると止まります。順番としては、第1の区分と第4の記録を先に置き、動かしながら第2の閾値と第3の確認位置を詰め、最後に第5から第7を足す進め方が現実的です。第5の取り消し手順だけは例外で、外部への送信をエージェントに任せる前に確認しておきます。戻せない操作を動かしてから設計しても間に合わないからです。
この7項目を事務所の業務に当てはめるとき、最初に作るのは操作の一覧表です。次のプロンプトは、その一覧を作るためのものです。
あなたは士業事務所の業務設計担当です。以下の業務について、AIエージェントに
実行させうる操作を洗い出し、4分類に割り当ててください。
【分類】
R 読み取りのみ
D 下書きの作成(保存はするが確定しない)
U 内部データの更新(確定する)
S 外部への送信・提出
【出力形式】
操作名 / 分類 / 取り消し可否 / 想定される誤りの内容 / 人の確認を置く位置(事前/事後/不要)
【条件】
- 法的な可否の断定はしないこと。運用設計の材料として整理すること
- 取り消し可否が判断できない操作は「要確認」と書くこと
【業務】
(ここに対象業務を書く。例: 月次の記帳代行、給与計算、登記申請書類の作成)
第2のプロンプトは、閾値と停止条件を文章に落とすためのものです。作った一覧を貼り付けて、事務所の運用ルール案として整形させます。
先ほどの操作一覧をもとに、AIエージェントの実行ルール案を作成してください。
【含める項目】
1 自動実行を認める操作(分類R・Dのうち対象とするもの)
2 人の事前確認を必須とする操作と、その判定条件(金額・件数・対象期間)
3 自動実行を認めない操作とその理由
4 連続失敗時の停止条件(何回失敗したら止めるか)
5 実行記録に残す項目(指示者・実行主体・対象・日時・結果)
6 権限棚卸しの頻度と担当
【条件】
- 各項目は3文以内
- 「違法」「適法」などの法的評価は書かないこと
- 事務所が後から数値を差し替えられるよう、閾値は[ ]で空欄にすること
7項目のうち、事務所が最も手を抜きやすいのが第4の実行記録です。動いている間は記録の必要性を感じないため、後回しになります。ただし記録がない状態では、顧問先から問い合わせが来たときに、その処理を人がやったのかエージェントがやったのかさえ説明できません。最初に作るのは第1の一覧表ですが、最初に動かすのは第4の記録です。
そして、どの操作を自動化するかの最終判断は有資格者が持ちます。業務設計担当が一覧と案を作り、担当有資格者が分類ごとに可否を決め、所長が全体を承認する。この三段にしておくと、担当者が個別に判断を迫られる場面が減ります。
顧問先データにエージェントを触らせる前に決めておくこと
ここまでは事務所の内側の設計でしたが、顧問先の情報を扱う以上、外に説明できるかどうかが最後に効いてきます。
実行制御を設計する理由は、効率ではなく説明責任です。事故が起きたときに、何が起きたかを説明できる状態を作っておく、という話になります。
士業の守秘義務は職種ごとに条文が置かれています。税理士については税理士法第38条が本人の義務を、税理士法第54条が使用人その他の従業者の義務を定めています。弁理士については弁理士法第30条が秘密を守る義務を置いています。AIエージェントは従業者ではないため、これらの条文が直接エージェントに向くわけではありません。だからこそ、エージェントを動かした人と事務所の側に、説明できる材料を用意しておく設計が要ります。
個人データの安全管理という観点では、個人情報保護法第23条が個人情報取扱事業者に必要かつ適切な措置を求め、個人情報保護法第25条が委託先の監督について定めています。外部のAIサービスに処理をさせる形が委託に当たるのかどうか、当たるとして何をもって適切な監督といえるのかは事案ごとに異なるため、ここで断定的な評価は書きません。事務所として現実的なのは、監督の実態を示せる記録を残しておくことです。実行記録は、その材料になります。
漏えい等が起きた場合の対応については、個人情報保護法第26条が個人情報保護委員会規則で定める事態が生じたときの報告等について規定しています。エージェントの誤動作でデータが外部に出た場面を想定するなら、誰がいつ気づき、どこまで影響が及んだかを短時間で確定できるかどうかが分かれ目になります。第4の実行記録と第6の停止条件は、この場面のために置いています。
規程に落とすなら、次の6項目を1枚にまとめる形が扱いやすくなります。対象ツールと接続先システム、操作の4区分ごとの可否、人の確認を置く位置、実行記録の保存先と保存期間、停止条件、権限棚卸しの頻度と担当です。個別のツール名は別紙に置き、本文は分類と条件で書いておくと、ツールが入れ替わっても改定の手間が小さく済みます。
案件管理の側に実行記録を集約しておくと、顧問先ごとの照会にそのまま答えられます。案件単位でAIの利用履歴を持たせる組み立て方はkintone AIを士業事務所の案件管理に入れる7工程と守秘の線で扱っています。記録の置き場所が業務システムの外に散らばると、照会のたびに複数の画面を見に行くことになり、結局は記録を取っていないのと変わらない状態に近づきます。
顧問先への説明については、業務にAIを使う場合があること、確定を伴う操作には人の確認を置いていること、実行の記録を残していることを、契約書面や説明資料に書いておく方法があります。効率化のために使っている、とだけ伝えるより、どう制御しているかまで書いてあるほうが、顧問先の側も判断しやすくなります。
実行制御を置かなかった事務所で起きやすい3つの失敗
1つ目は、下書きのつもりが確定していた、というケースです。会計ソフトや案件管理では、下書き保存と確定登録の区別がAPI経由だと曖昧になることがあります。エージェントに「登録して」と指示した結果、人の目を通らないまま確定処理まで進む構成になっていた、という事故が起きえます。第1の操作区分で、下書きと確定を別の区分に置く理由はここにあります。
2つ目は、送信系の操作を許可したまま放置するケースです。メールやチャットの送信は取り消しが効かず、相手の受信箱に残ります。顧問先向けの案内を自動送信する設定にしていて、テンプレートの差し替えミスが全件に配られる、という形の失敗は、実行制御を置いていない事務所で起きやすい型です。取り消せない操作は自動実行から外すという第5の判断が効きます。
3つ目は、止まらない設計です。エラーが出ても次の処理に進む構成にしていると、原因が解消されないまま同じ誤りが積み上がります。夜間に回している処理ほど、翌朝に発見したときには件数が膨らんでいます。連続失敗で停止する条件を置き、停止したことを担当者に通知するところまでを設計に含めます。
3つの失敗に共通する予兆もあります。担当者が、エージェントの動きを毎回目で追っている状態です。目で追わないと不安だという状態は、実行のさせ方が設計されていないことの裏返しで、監視の手間が自動化の効果を打ち消します。設計が効いていれば、担当者は確認すべき対象だけを見て、それ以外は結果の一覧で足りるようになります。
いずれの失敗も、権限設定そのものは正しかった、という点が共通しています。アクセス制御は通っていて、実行のさせ方だけが設計されていなかった。この記事の主題は、そこに手当てを置く話です。
設計と運用にかかる工数と担当の置き方
工数は、対象とする業務の数で決まります。参考値として、業務1つあたり、操作の洗い出しに2時間、分類と閾値の決定に有資格者を交えて2時間、記録の設定と動作確認に半日という組み立て方があります。最初の1業務に時間がかかり、2業務目からは半分程度に収まる形が一般的です。
担当は、業務設計担当が一覧と案の作成、担当有資格者が区分ごとの可否判断、所長が承認という三段が回しやすい形です。記録の保存先と保存期間は、事務所の文書管理規程と揃えておくと、別の運用を増やさずに済みます。
費用面では、実行制御のために新しい製品を買うとは限りません。多くの業務システムには承認フローや下書き状態が既にあり、それを使う設計にできるかどうかが先です。既存の機能で足りない部分だけを、後から補う順序にしたほうが、投資の判断がしやすくなります。
見落とされやすいのが、運用開始後の見直し工数です。閾値は最初から適切な値にはなりません。事前確認に回る件数が多すぎて担当者が形式的に承認し始めたら、その閾値は機能していません。四半期ごとに、事前確認に回った件数と、そのうち差し戻した件数を見て、閾値を調整する時間を確保しておきます。
実行制御の議論が事務所に残す論点
ここから先に残る論点は3つです。1つ目は、業務ロジックをどこに置くかという問題です。事務所のルールをプロンプトに書くか、接続するツール側に組み込むかで、可搬性と確実性のどちらを取るかが変わります。前出のセッションが提示していたのは、ツール側に業務ロジックと人の確認と監査可能性を組み込むという方向でした(出典: AGNTCon + MCPCon Japan 2026 Schedule)。プロンプトに書いたルールは、モデルが従わなかったときに止まりません。
業務ロジックの置き場所は、事務所の規模によっても変わります。接続するツールを自前で用意できる事務所はツール側に寄せられますが、市販のサービスを組み合わせて使う事務所は、サービスが用意している承認フローの範囲で組むことになります。その場合、承認フローで表現できないルールは運用の約束事として残るため、どこまでが仕組みで止まり、どこからが人の記憶に依存しているのかを書き出しておく価値があります。
2つ目は、確認する人の役割です。事前確認の件数が増えるほど、担当者は内容を見ずに承認するようになります。確認を形だけにしないためには、確認する対象を絞り込む設計が要ります。すべてを確認する設計は、何も確認しない設計に近づきます。
3つ目は、顧問先との責任分担です。事務所がエージェントを使って処理し、その結果に誤りがあった場合、どこまでが事務所の責任として整理されるのかは、契約の書き方によって変わります。この点をどう扱うかは有資格者の判断領域ですが、契約の更新時期に合わせて論点として上げておく価値があります。予測ではなく、これらが論点になります。
よくある質問
実行制御とアクセス制御は何が違いますか
アクセス制御は何にアクセスし何を実行できるかを扱い、実行制御は許可されたリクエストをどのように実行するかを扱う、という区別が示されています(出典: AGNTCon + MCPCon Japan 2026 Schedule)。権限の有無を決めるのが前者、権限がある操作の手順と確認を決めるのが後者です。
小規模な事務所でもここまで設計する必要がありますか
規模よりも、扱う操作の種類で決まります。読み取りと下書きだけに使っている段階では、記録を残すことから始めれば十分です。確定を伴う更新や外部への送信をエージェントにさせる段になったときに、7項目のうち第1、第3、第4、第5を先に埋めるという進め方ができます。
人の確認を挟むと効率化にならないのではないですか
確認の対象を絞れば、効率は残ります。件数の多い読み取りと下書きを自動で回し、確定と送信だけを人が見る構成なら、作業時間の大半は自動化されたままです。効率が失われるのは、すべての操作に一律で事前確認を置いた場合です。
エージェントが起こした誤りは誰の責任になりますか
責任の所在は契約と事実関係によって変わるため、一般化した回答はできません。事務所として準備できるのは、誰の指示で何が実行されたかを示せる記録です。個人データの安全管理については個人情報保護法第23条が必要かつ適切な措置を求めており、記録はその説明材料になります。個別の評価は有資格者の判断領域です。
実行記録には何を残せばよいですか
指示した人、実行した主体、対象となったデータ、日時、操作の内容、結果の6項目が基本です。AIエージェントの場合、指示者と実行主体が分かれる点が通常のシステム操作と違うため、この2つを別項目にしておきます。保存期間は事務所の文書管理規程と揃えます。
MCPを使っていない事務所にも関係がありますか
関係します。実行制御は特定のプロトコルの話ではなく、AIに業務システムを操作させるときの設計の話です。ノーコードツールの自動化や、業務ソフトのAI機能を使う場合でも、確定を伴う操作をどう扱うかという論点は同じ形で出てきます。
閾値はどのくらいの数値から始めればよいですか
事務所の実績値から逆算する方法が取りやすい形です。過去の処理を振り返り、金額や件数の分布を見て、影響の大きい上位層にあたる水準を事前確認の対象に置くところから始める方法があります。最初から広く自動化すると差し戻しの手間が増え、狭すぎると確認が形骸化します。数値は固定せず、四半期ごとに見直す前提で置きます。
顧問先にはどこまで説明すべきでしょうか
説明の範囲は事務所ごとの方針によりますが、AIを業務に使う場合があること、確定を伴う操作には人の確認を置いていること、実行の記録を残していることの3点を書面に書いておく方法があります。質問を受けてから説明するより、契約時に書いておくほうが、事務所側の運用も締まります。
実行制御という言葉自体は企業向けMCPの文脈から出てきたものですが、中身は士業事務所が以前から紙の業務で持っていた考え方に近いところがあります。誰が起案し、誰が確認し、誰が決裁するか。その順序を書面の回付で担保してきた事務所であれば、同じ構造をエージェントの実行手順に移すだけで、設計の骨格は揃います。新しく覚えることが多いように見えて、実際には既にある業務の型を、機械が動く場所に置き直す作業です。
参考文献
- AGNTCon + MCPCon Japan 2026 Schedule & Directory
- AGNTCon + MCPCon Japan(Linux Foundation Events)
- 総務省 AI事業者ガイドライン掲載ページ
- e-Gov法令検索 個人情報の保護に関する法律
- e-Gov法令検索 税理士法
- e-Gov法令検索 弁理士法
- 個人情報保護委員会
※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/
本記事の作成体制について
本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で、それぞれ確認したうえで記載しています。引用元は本文中および参考文献にすべて明示しています。
本記事には特定の資格者による監修は入っていません。個別の事案について法令の当てはめや手続の可否を判断する必要がある場合は、当該分野の有資格者にご相談ください。本記事は一般的な情報提供を目的としたものであり、個別具体的な法律判断・税務判断・労務判断を提供するものではありません。
記載内容に誤りを見つけられた場合は、お問い合わせよりご指摘ください。確認のうえ速やかに訂正し、訂正履歴を記事内に残します。編集方針の詳細は運営者情報をご覧ください。