ケーススタディ: 社内 IT ヘルプデスク Agent(実行系の段階導入)

注記: 本記事は、本ライブラリの設計判断を 1 つの物語で通すために構成した**架空の事例(構成事例)**です。登場する組織・数値は実在のものではありませんが、各段階の判断と失敗は実際のプロジェクトで広く観察されるものに基づいています。

この記事の目的

「パスワードリセット・アカウント申請・ソフト配布」という書き込み(実行)を伴う社内 IT ヘルプデスクを題材に、実行権限をどう段階的に開放し、承認と監査で安全を担保したかを追います。「照会は自律・実行は承認付き」を、権限の最小化と実行の記録という観点から設計判断として持ち帰れる状態を目指します。

対象読者

実行(書き込み)を伴うエージェントを、権限・承認・監査を設計しながら導入したいエンジニア・情シス担当
照会系の Agent は作れたが、「実際に操作する」段階に進む判断がほしい人

前提知識

経費精算アシスタントの段階的 Agent 化 — 段階導入の背骨(本記事は実行権限の運用に重心)
Human-in-the-Loop 設計 — 実行の承認ゲート

本文

概要: 題材と「実行して初めて価値が出る」性質

題材は社内 IT ヘルプデスクです。要件は段階的に増えます — (1) FAQ・手順の照会、(2) 申請状況・資産の照会、(3) パスワードリセット・アカウント申請・ソフト配布の実行。前 2 つは読み取りですが、(3) は「実際にやってくれないと意味がない」実行系です。この事例の要点は、照会と実行を別の速度で開放したことにあります。経費精算の事例(経費精算アシスタントの段階的 Agent 化)が「自律性の段階」を描いたのに対し、本事例は「実行権限の段階」を描きます。

詳細: v0〜v1 — 照会から始める

最初は FAQ 照会と、申請状況・資産情報の照会だけを提供しました。ここは読み取りのみで失敗コストが低く、有用性(一次対応の削減)を測りやすい段階です。

この段階の学び: 照会だけでも、問い合わせの多くが「手順を教えてほしい」「今どうなっているか知りたい」であることが分かりました。実行に進む前に、どの操作が本当に頻出かをログで把握できたのが後で効きました

詳細: v2 — 実行の開放は「1 操作ずつ・承認付き」で

実行系の要望が集まった順に、リスクの低い操作から 1 つずつ開放しました。全部を一度に実行可能にしないのが最初の判断です。

操作	リスク	開放時の設計
パスワードリセット	中(本人確認が要)	本人確認の成立を条件に、承認付きで実行
ソフト配布(許可済みリスト)	低(可逆・影響限定)	許可リスト内なら承認なしの限定自動化
アカウント申請(新規権限付与)	高(不可逆・影響大)	申請の下書きまで Agent、付与は人が承認

リスクで自律度を変える: 可逆で影響の小さい操作(許可リスト内のソフト配布)は承認なしの限定自動化に、不可逆で影響の大きい操作(権限付与)は人の承認を必須にしました(Human-in-the-Loop 設計)。一律に承認を付けると承認疲れを招き、一律に自動化すると事故が起きるため、操作ごとに判断しました
承認対象は「これから何をするか」を見せる: 承認画面には、対象ユーザー・操作内容・影響範囲を要約して示しました。承認者が中身を見ずに押す「素通り承認」を避けるためです

詳細: v2 — 権限は「エージェント本人」に絞る

実行系で最も注意したのが、誰の権限でその操作が行われるかでした。

広すぎるサービスアカウントを避ける: ヘルプデスク Agent に「何でもできる管理者権限」を与えるのは最悪の設計です。操作ごとに必要最小限の権限だけを持つように分け、エージェントの行為として帰属できるようにしました(エージェントの認証・認可)
ツール側で認可を強制する: 「本人のパスワードのみリセット可」「許可リスト外のソフトは配布不可」といった制約は、プロンプトのお願いではなく、ツールの実装側で強制しました(ツール権限設計とサンドボックス)。モデルが指示を無視しても、経路が塞がっている状態にします

詳細: 実行の監査証跡

実行系は「誰が・いつ・何を・誰の承認で実行したか」を後から説明できることが必須です。

全実行をトレースする: どの入力に・どう判断し・どのツールを・どの承認で実行したかを構造化して記録しました(可観測性とトレーシング)。従来の IT 運用が持っていた操作ログの粒度に合わせ、監査要件を満たしました
承認の記録が説明責任の実体: 「この権限付与は誰が承認したか」が記録されていることが、事故時の説明の裏付けになりました(エージェントの責任と説明責任)

設計判断: この事例の教訓

照会と実行を別の速度で開放する — 読み取りは早く広げ、書き込みは 1 操作ずつ慎重に開放しました。両方を同時に広げると、リスクが一気に積み上がります
リスクで自律度を変える — 可逆・影響小は限定自動化、不可逆・影響大は承認必須と、操作ごとに判断しました。一律の承認も一律の自動化も、どちらも失敗します
認可はツール側で強制する — 「本人のみ」「許可リスト内のみ」をモデルの良識に委ねず、実装で塞ぎました。実行系では、指示ではなく経路で守ります
効果測定を伴う — セルフサービス化による一次対応の削減を測り、投資対効果を確認しました(ROI とビジネスケース)

実務での注意点

アンチパターン

実行系を一度に全部開放する → リスクが一気に積み上がり事故時の影響が大きい → リスクの低い操作から 1 つずつ、承認付きで開放する
ヘルプデスク Agent に管理者権限を与える → 乗っ取り・誤操作の被害が全域に及ぶ → 操作ごとに最小権限を分け、エージェントの行為として帰属できるようにする
「本人のみ」等の制約をプロンプトで守らせる → 回避されうる → ツールの実装側で認可を強制する
一律に承認を付ける / 一律に自動化する → 承認疲れ、または事故 → 操作の可逆性・影響でリスク評価し、自律度を変える
架空事例のリスク区分をそのまま自組織に当てはめる → 組織で許容リスクは異なる → 判断軸(可逆性・影響・本人確認)を持ち帰り、自組織で評価し直す

チェックリスト

照会(読み取り)と実行(書き込み)を別の速度で開放したか
実行操作を、可逆性・影響でリスク評価し、自律度(承認要否)を分けたか
エージェントに最小権限を与え、行為を帰属できるようにしたか
「本人のみ」等の認可をツール実装側で強制しているか
承認画面が操作内容・影響範囲を示し、素通り承認を防いでいるか
全実行の監査証跡(入力・判断・ツール・承認)を残しているか

参考資料

Building Effective Agents(Anthropic) — 段階的に複雑さ・権限を足す進め方の原典(アクセス日: 2026-07-09)

TODO・未確認事項

なし