AI に請求内容を調べてもらい、送付文まで作ってもらう。ここまでは任せたいが、送信ボタンも押してよいのか。AI エージェント（目的に応じて道具を選び、作業を進める AI）を導入する発注側が決めるのは、こうした行為の境目です。文章が正しくても、送信先や実行の時点が違えば業務上の問題になる。経営者・情シス・管理部門が、自社の権限表、承認画面、停止手順に何を書くかを判断できるよう、設計例を整理します。
FDE とは何かをまとめたハブ記事で扱う FDE（Forward Deployed Engineer。顧客の現場に入り、本番で動く仕組みを作るエンジニア）は、業務上の線引きを動作に反映する役割を担います。この記事の対象は、ツール（検索・登録・送信などを実行する道具）の権限、承認、停止、記録です。データの保存先や学習利用はデータの扱いの記事に譲り、ここでは「読める情報を使って、どの操作までしてよいか」に絞ります。
AI に任せる範囲は、閲覧・下書き・確定・外部送信に分けて決める。重要な操作は内容と対象を人が承認し、実行時にも権限と承認内容の一致を確認する。結果が不明なら自動でやり直さず、停止して実行先を調べる。依頼から承認、実行結果、復旧までを同じ作業の記録としてつなげる。
この記事の要約
AI の提案と、会社として許す行為を分ける
発注時に「メール対応を自動化する」とだけ書くと、過去メールの検索、返信案の保存、担当者への回付、外部への送信が同じ仕事に見えます。しかし、検索のやり直しと誤送信への対応では負担が違う。そこで業務を動詞に分け、各動作の直後に何が変わるかを確かめます。この分解は業務責任者と情シスが一緒に行い、動詞と対象を並べた一覧を最初の成果物にします。下書きの保存で別の仕組みが動いて送信されるなら、その保存も外部への影響を持つ操作として扱います。
Anthropic のツール利用の公式文書では、自社側で動かすツールについて、Claude が実行要求を返し、アプリが処理して結果を返す構成を説明しています。AI が要求を出す段階と、業務システムが実行する段階は分けられる。この区別を発注条件にすると、AI が送信を提案しても、承認が済むまで実行を保留する仕組みを求められます。製品内で動くツールもあるため、採用する製品のどこで承認を確認できるかは個別に確かめる事項です。
生成 AI 利用のリスク一覧を公開している OWASP Gen AI Security Project は、AI に過大な行為の権限を与えるリスクを、機能・権限・自律性の過剰という観点で整理しています。必要な機能とアクセス範囲に絞り、影響の大きい操作を人が承認し、操作先のシステムでも許可を確認する対策を挙げています。当社はこの考え方を、発注側が決める行為の一覧と、実装側が設定する権限の対応表に落とすことを勧めます。
以下の表や承認画面は当社の設計提案であり、実顧客の運用や製品の標準機能を示したものではありません。はてなベースには、経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験があります。本記事の AX は、AI を使って業務を組み直すことを指します。その経験を踏まえた当社の見解は、任せる操作を増やす前に、誰が何を確定するかを発注側の言葉で決める、というものです。
権限表は「閲覧・下書き・確定・外部送信」で作る
権限表の行にはサービス名だけを書かず、「未承認の申請を読む」「指定欄に候補を保存する」のように動作と対象を書きます。列には実行名義、対象範囲、人の承認、許可しない操作を置く。実行名義は、システム上で誰の操作として処理するかです。職員全員の情報を読める管理者の名義を便宜的に使うと、利用者本人が見られない対象にも AI の操作が届く構成になり得ます。
| 行為 | 許可する範囲の設計例 | 人の判断 | 同時に付けない権限 |
|---|---|---|---|
| 閲覧 | 依頼者が閲覧できる対象だけ検索 | 対象部門と用途を事前に決定 | 他部門の検索・一括出力 |
| 下書き | 確認用の欄に候補を保存 | 確定前に担当者が原資料と照合 | 確定欄の上書き・後続の自動送信 |
| 確定 | 承認した対象と変更内容だけ反映 | 既存の決裁権限に従って承認 | 承認者変更・承認済み扱いへの自己変更 |
| 外部送信 | 承認済みの宛先・本文・添付を送信 | 送信内容と対象を確認して承認 | 宛先の推測・別宛先への再送 |
この表は、下へ進むほど常に危険だという順位表ではありません。閲覧でも給与情報の一括出力なら影響は大きく、下書きでも共有先が広ければ情報が伝わります。金額、件数、相手先、取り消しやすさ、後続処理を合わせて判定する。単価の低い処理でも、一括実行の対象が広がるなら承認条件を変える、という設計が考えられます。金額だけの線引きでは、情報の送付や権限の変更を評価できません。
たとえば案件管理の更新なら、AI が書けるのは次回対応の候補欄までにし、契約金額や請求先の確定欄は人が更新する案があります。画面上で候補と確定値を並べれば、担当者は変更の意味を見比べられる。既存のアクセス制御で欄ごとに分けられないなら、候補の保存先を分けるか、AI は提案を表示するところまでにとどめます。制限できないまま広い書き込み権限で代用しない判断です。
閲覧用と実行用の接続は分け、実行用も業務に必要な操作に絞ります。依頼者の権限と、接続に使う名義の権限を突き合わせ、どちらかが許可しない対象は扱わない設計です。AI の画面に管理者設定の道具を表示しないことに加え、実行先でも権限の変更や履歴の削除を許さない。画面操作で連携する場合も同じで、ログイン中の人の広い権限をそのまま AI に渡す構成になっていないかを確認します。
権限を追加するときは、追加する動作、必要な理由、終了条件、承認者を記録します。試行のための一時権限は終了時に戻し、担当交代時には名義と対象範囲を見直す。AI が拒否されたから別の接続や画面へ回って実行する、といった迂回も認めない条件に含めます。発注側は「書けました」という実演と同じ場で、「対象外には書けませんでした」という結果も提示してもらうと判断しやすくなります。
承認画面では「何が変わるか」を見せる
承認を挟んでも、画面に「処理してよいですか」としか出なければ、担当者は判断材料を持てません。見せるのは作業名、対象、変更前後、根拠資料、実行名義、外部への影響です。たとえば請求案内なら、本文だけでなく宛先、添付、対象の請求内容を一緒に表示する。承認ボタンの近くに、今回の判断がどの操作までを許すのかを書くと、下書きの確認と送信の承認を区別できます。
| 承認画面の項目 | 担当者が確認する内容 | 不一致や不足がある場合 |
|---|---|---|
| 対象と範囲 | 相手先、対象明細、件数、合計金額 | 対象を修正して出し直す |
| 変更内容 | 現在値と変更後、送信本文と添付 | 修正した版で再承認する |
| 根拠と例外 | 原資料の該当箇所、未確認事項 | 原資料を確認し、保留または差し戻す |
| 実行条件 | 実行名義、予定時点、承認の有効期限 | 権限や期限が合わなければ実行しない |
| 処理後の影響 | 後続の通知・更新、取り消しの可否 | 影響を判断できる承認者に回す |
承認は、その時点の具体的な内容に対して与えます。承認後に宛先や金額、添付が変わったなら、以前の承認を流用しない。担当者が承認待ちの間に元データを更新した場合も、古い案を実行せず差分を見せ直します。これを運用上のお願いで終わらせず、実行直前に承認した版と現在の対象を照合する条件として発注する。承認の有効期限は業務側が決め、期限を過ぎた作業は保留に戻す案です。
承認者が不在なら、登録済みの代理者に回すか、手作業へ切り替えます。返事がないことを承認とみなす設計では、忙しい日に確認が抜けたまま進んでしまう。誰が代理できるかは既存の決裁規程と合わせ、AI 自身に代理者の追加や承認条件の緩和をさせない。経営者の短いチャット返信を承認に使う場合も、何の版に対する返答かを特定できなければ、正式な承認画面へ戻します。
一方、検索のたびに確認を求めると、担当者は承認待ちの処理に追われます。対象を限定した閲覧や外部への影響がない候補生成は事前のルール内で動かし、会社の記録が確定する箇所や社外へ情報が渡る箇所に確認を置く。まとめて承認するなら、対象一覧と除外した例外を表示し、承認後に対象を追加しない設計にします。承認待ちが増えた際は、無条件に承認を省く前に、対象の絞り方や画面の見づらさを見直します。
AI が自分の案を点検する仕組みは、記載漏れを探す補助には使えます。ただし、その点検結果だけで人の承認済みに切り替えると、発注側が決めた確認の意味が変わる。原資料と変更案を担当者が比較できる表示を残し、誤った案を見つけたときには、編集、差し戻し、保留を選べるようにします。承認の件数を減らす工夫と、承認者が判断できる材料を減らすことは区別して設計したいところです。
停止条件は、結果が不明な場面まで決める
Anthropic のエージェント設計の記事は、処理中に道具の実行結果を確認し、人の判断を求める場や繰り返し回数の上限などの停止条件を設ける考え方を示しています。発注側では、上限の数字を入れるだけでなく、どの状態なら続行せずに人へ返すかを決めます。承認期限切れ、許可外の対象、実行結果の不明、記録の保存失敗は、別々の理由として表示する設計です。
特に決めておきたいのが、送信や登録を依頼した後に通信が途切れた場合です。画面がエラーでも、実行先では処理が終わっているかもしれない。その状態で同じ操作を繰り返すと、二重の通知や登録につながります。結果を「成功・失敗」だけで扱わず「結果確認中」を用意し、実行先の履歴と照合するまで再実行を止めます。再実行しても重複を作らない仕組みの有無も、連携先ごとに確認する条件です。
停止の範囲も分けます。承認期限が切れた申請だけを保留するのか、送信連携全体を止めるのか、すべての自動実行を止めるのか。権限外の要求が続く、履歴が残らないなど、対象を特定できない異常では、広い範囲を止める判断もあり得ます。どの管理画面を誰が操作するかを決め、新規の依頼だけでなく、承認済みで実行待ちの作業にも停止が及ぶかを確かめます。
米国国立標準技術研究所 NIST のAI RMF Coreは、AI のリスク管理のための枠組みです。MANAGE 2.4 では意図に合わない動作をする AI を停止・無効化する仕組みと責任の明確化を、MANAGE 4.1 では稼働後の監視や事故対応、復旧、変更管理を扱っています。この記事ではこれを、停止担当と再開判断者を事前に決めるための参考にします。個々の業務の承認金額や停止回数を、この枠組みが定めているわけではありません。
停止ボタンは、すでに送ったメールや登録した取引を元に戻す機能とは限りません。停止した時刻の前後で、完了したもの、未実行のもの、結果不明のものを分ける。復旧担当は実行先と記録を照合し、取消しや訂正を誰が行うかを判断します。作業途中で一部だけ完了した場合も、残りを最初からやり直さず、完了済みを除いた再開対象を確認します。現場が手作業で続ける場合は、自動処理との重複を避ける引き継ぎ方法も決めておく案です。
外部文書やメールに、承認を省略するよう求める文章が含まれる場合も想定します。プロンプトインジェクション（読み込んだ文章などで AI の動作を意図せず変えさせる攻撃）への備えとして、参照資料の記述を会社の権限変更として扱わない設計にする。怪しい文章を AI が見抜くことだけに頼らず、実行時の権限と承認条件を別に確認します。検知できた場合の保留先と、担当者が原文を確認できる範囲も定めます。
記録は依頼・承認・実行・復旧をつなげる
後から確認したいのは、AI がどんな説明を返したかだけではありません。誰の依頼で、誰の権限を使い、何を承認し、実際に何が変わったかです。会話の保存だけでは、処理先の完了状況や承認後の変更が追えない場合がある。作業ごとに共通の管理番号を付け、承認履歴と実行先の結果を結びます。番号の仕様は実装側に任せても、現場が対象の申請から一連の記録を開けることは発注条件にできます。
| 残す記録 | 記録する内容 | 後から答えたい問い |
|---|---|---|
| 依頼と適用ルール | 依頼者、対象、実行名義、権限ルールの版 | 誰の権限で、どこまで頼んだか |
| 提案と判断 | 変更案、根拠の参照先、承認者、日時、承認した版 | どの内容を確認して許可したか |
| 実行と照合 | 操作、開始・終了時刻、対象、実行先の結果 | 何が完了し、何が不明か |
| 拒否と停止 | 拒否理由、停止範囲、通知先、担当の受領 | 何を止め、誰が引き取ったか |
| 訂正と再開 | 訂正対象、対応結果、再開判断者、再開範囲 | 何を直して再開したか |
実行結果は業務システムの返答や履歴から取り、AI の「完了しました」という文章と区別します。候補生成まで済んだ場合は「候補を保存」、送信を受け付けた段階なら「送信受付」のように、確認できた範囲で表示する。承認された事実と実行された事実も別々に残すと、承認済みだが未送信の対象を拾えます。複数システムをまたぐ処理では、どこまで完了したかが見える一覧が現場の再開判断を助けます。
記録には、原文や添付を何でも複製する必要はありません。調査に必要な対象と変更点を残し、元資料へ閲覧権限付きでたどれる構成も選べます。保存期間、閲覧者、削除する担当、改変を検知する方法を決め、認証に使う秘密情報は記録に含めない。詳しい記録が必要な作業と、機密情報を広げない配慮を両立させるため、情シスと業務の持ち主が保存項目を一緒に確認します。
記録を保存できなかった場合の動作も決めます。確定や外部送信は、事前の記録を残せない時点で保留する案が考えられる。一方、実行後の記録に失敗したなら、処理はすでに済んでいる可能性があるので、未実行扱いにせず結果確認中にします。実行先の履歴を確認する担当へ通知し、後から補記した事実と日時を残す。記録の障害まで含めて設計すると、「履歴にないので再送する」という判断を避けやすくなります。
発注時は、止まる実演と社内での運用まで確認する
発注側の分担は、FDE を受け入れる社内体制と合わせます。経営・業務責任者は任せる操作と許容範囲、情シスは実行名義と権限、現場は承認時の確認内容を決める。Echo 役（社内で業務と仕組みを引き継ぐ担当）が判断を一覧にまとめ、FDE は動作へ反映し、確認結果を提示します。Echo 役に決裁権がない項目は、判断できる人と代理者を別に登録します。
生成 AI の評価設計の記事では、出力の正しさ、業務上の受け入れ可否、運用上の安全を分けています。今回の検収（発注したものを受け入れる確認）には、正しく実行する例と、実行してはいけない例の両方を用意します。権限外の対象、承認後の内容変更、不在の承認者、通信断による結果不明、記録の保存失敗を与えたとき、予定した地点で止まり、担当者に理由が見えるかを確認する。試験用の対象を使い、実際の外部送信や取引が発生しない環境で行う条件も付けます。
受け取る成果物は、行為ごとの権限表、承認画面と条件、停止・復旧手順、記録項目の一覧、検証結果です。書類があるだけでは受け入れず、社内担当が画面から停止し、実行済みを特定し、再開対象を選ぶところまで実演する。モデルや接続先、承認ルールを変える際は、影響する操作を同じ条件で確かめ直します。担当交代後にも権限の解除と代理者の変更ができるかが、引き継ぎの確認点になります。
新しいエージェントの開発が必要とは限りません。Anthropic も設計の記事で、単純な解決方法から始め、必要なときに複雑さを増やすことを勧めています。既存システムの承認機能とアクセス制御で線引きでき、現場が停止と照合を担えるなら、その設定と社内手順の見直しで足りる場合があります。手順が固定されている処理は、通常の自動処理にして、AI は候補を作る部分だけに置く選択もあります。
複数システムの権限が食い違う、承認した内容と実行結果を結び付けられない、例外時の担当を決めきれない。こうした課題が残る場合には、FDE 型の伴走で業務の判断と実装を一緒に詰める余地があります。当社は、まず対象業務を一つ選び、任せる操作と任せない操作を一覧にすることを勧めます。その表を既存機能に当て、足りない箇所を確かめてから開発範囲を決める。発注の出発点は、AI の自律性を高めることより、自社が許可した通りに動き、必要なときに止められる状態を定めることです。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
AI に任せる操作と、人が承認する範囲を整理しませんか
権限表、承認時に見せる内容、停止と復旧、実行記録を、貴社の業務と既存システムに合わせて整理します。既存機能や社内対応で足りる部分を確認し、追加の設計が必要な箇所から相談できます。