AIエージェントは、文章を作るだけでなく、ファイルの参照、情報検索、データ登録、通知、プログラム実行などを連続して進められます。便利な一方で、企業では「何を任せてよいか分からない」「誤操作が怖くて本番環境につなげられない」「担当者ごとに使い方が違う」といった問題が起きています。本記事では、あるIT運用支援会社が、人とAIの境界設定、安全なサンドボックス、スキルの標準化を進めた過程を紹介します。
【関連記事】kintone×DifyでAXを実現！情報検索の高度化事例
AIエージェントがもたらした不安
F社は、法人向けシステムの保守、問い合わせ対応、障害の一次対応を行うIT運用支援会社です。顧客ごとに異なるシステムを扱っており、担当者は問い合わせ内容の確認、過去事例の調査、手順書の参照、対応記録の作成に多くの時間を使っていました。
業務負担を減らすため、F社は社内文書の検索、問い合わせ内容の整理、障害情報の収集、報告書の下書き作成にAIエージェントを試験導入しました。導入直後は「調査時間が短くなった」「報告書を一から書かなくてよくなった」と評価されましたが、利用範囲が広がるにつれて、回答精度とは異なる問題が表面化しました。
AIがどこまで実行するのか決まっていなかった
ある担当者が、問い合わせに関係する過去の障害事例を調べるようAIエージェントへ依頼しました。担当者は、関連するチケットや手順書の一覧が返ってくると考えていました。ところが、AIは問い合わせ内容の整理、対応案の作成、顧客向け通知文の下書きまで進めようとしました。別のケースでは、調査結果を保存するため、共有フォルダ内の既存ファイルを更新しようとしました。
AIは、与えられた目的を達成するため、利用可能なツールを使い、必要だと判断した処理を進めただけです。問題は、情報収集だけを行うのか、対応案まで作るのか、データの更新まで行うのかという実行範囲が定義されていなかったことでした。現場責任者は「AIが間違えることより、どこまで勝手に進むのか分からないことのほうが怖かった」と振り返ります。
F社には「最後は担当者が確認する」という方針もありました。しかし、調査結果の確認を最後と考える担当者もいれば、顧客への送信直前を最後と考える担当者もいました。「最後は確認する」という言葉だけでは、AIを止める工程を統一できません。誰が、どの段階で、何を承認するかまで決める必要がありました。
必要以上の権限を与えていた
F社は、AIエージェントに複数の業務を処理させるため、共有フォルダ、社内システム、メール、チケット管理ツールへアクセスできる共通アカウントを用意していました。検証を早く進めるため、細かな権限分割よりも利便性を優先した形です。
この構成では、問い合わせ調査に必要な資料だけでなく、本来参照する必要のない情報にもアクセスできました。検証中のエージェントが、本番で使用している顧客データへ接続できる状態にもなっていました。情報システム担当者は「人には部署や役職ごとの権限があるのに、AIには何でも見えるアカウントを渡していた」と話します。
プロンプトに「このファイルは見ないでください」と書いても、技術的に参照できる状態であれば、設定ミスや想定外の判断によって取得される可能性は残ります。文章で禁止するだけでは、アクセスを防いだことにはなりません。F社には、AIが実行できる処理をシステム側でも制限する設計が不足していました。
検証環境と本番環境の境界が曖昧だった
問い合わせに添付された大量のログを分析するため、AIが解析プログラムを作成することもありました。担当者は、そのプログラムを自分の端末へ保存し、内容を簡単に確認してから実行していました。正常に動けば、ログの中から異常な記録を短時間で抽出できます。
一方で、対象外のファイルを書き換える、処理が繰り返される、外部へ通信する、端末のリソースを大量に消費するといった可能性を排除できませんでした。担当者は実行中の画面を見続けなければならず、「自動化したはずなのに、怖くて画面から離れられない」「AIの作業を見張る仕事が増えただけではないか」という声も出ました。
作業時間の一部は短縮されても、心理的な負担は軽減されていませんでした。AIが生成したファイルやプログラムを安全に試せる環境がなく、利用者の端末と本番環境が事実上の検証場所になっていたためです。失敗を前提として影響範囲を限定する仕組みが求められていました。
個人の工夫が組織の資産になっていなかった
同じ問い合わせ対応でも、担当者によってAIへの指示は異なっていました。ある担当者は問い合わせ内容を要約してから過去事例を検索させ、別の担当者は最初から原因候補を列挙させていました。参照するファイル、確認項目、出力形式も統一されていませんでした。
成果を上げたプロンプトは、個人のメモやチャット履歴として保存されていました。共有された場合も、どの資料と組み合わせ、どの順番で使用するのかまでは記録されていません。「同じAIを使っているのに、担当者によって品質が違う」「別の環境では同じ結果を再現できない」という問題が続きました。
やがて、AIに詳しい担当者へ設定依頼や相談が集中しました。属人化を解消するために導入したAIが、AIを使いこなせる人への新たな属人化を生んでいたのです。個人の工夫を共有するだけでなく、業務手順として検証し、組織で管理する必要がありました。
問題はAIモデルの性能ではなかった
F社は当初、より高性能なAIモデルへ変更すれば、問題を解決できるのではないかと考えていました。指示を正確に理解できるモデルであれば、余計な処理をせず、安全に業務を進められると期待したためです。
相談を受けた私たちは、担当者へのヒアリングを通じて課題を整理しました。
- 業務の分解：業務が、AIへ任せられる単位に分けられていない。
- 責任範囲：担当者とAIがそれぞれ何を判断するのか決まっていない。
- 権限管理：処理に必要な権限と、与えてはいけない権限が整理されていない。
- 実行環境：検証環境と本番環境が分離されていない。
- スキル管理：個人の工夫を組織で検証し、更新する仕組みがない。
これらは、AIモデルを変更するだけでは解決できません。私たちの助言のもと、F社は「AIに何ができるか」から検討するのをやめ、「業務のどの部分を、どの条件で、どこまで任せるか」を先に決める方針へ転換しました。
「安全に任せられるスキル」をつくる
F社と私たちが最初に取り組んだのは、新しいAIツールの選定ではありません。問い合わせ対応を分解し、AIが担当する処理、担当者が判断する処理、システムによって禁止する処理を明確にしました。
具体例として選んだのが「障害問い合わせの一次調査」です。発生頻度が高く、情報収集や文書作成に時間がかかる一方、原因の確定や復旧作業には担当者の判断が必要な業務でした。
業務を「観察・提案・実行」に分解する
問い合わせ対応には、情報収集、整理、判断、文書作成、承認、送信、記録更新など、性質の異なる処理が含まれます。業務を「AIに任せる仕事」と「担当者が行う仕事」に分けるだけでは、どの工程まで任せるのかを具体化できません。
F社はAIの関与方法を次の3段階に分けました。
- 観察：情報を収集し、現在の状況を整理する。
- 提案：原因候補や対応案を提示し、担当者へ選択を求める。
- 実行：承認された条件の範囲で、登録、通知、更新を行う。
一次調査では、AIが問い合わせ本文の整理、対象システムの特定、類似障害の検索、手順書の抽出、原因候補の提示までを担当します。原因の確定、顧客回答の承認、復旧方法の選択、本番環境への変更指示は担当者が行います。現場リーダーは「AIを止める場所が決まったことで、安心して任せられる範囲が広がった」と話します。
曖昧なプロンプトを再現可能な指示へ変える
導入前は「問い合わせ内容を読んで原因を調べてください」と指示していました。しかし、この文章だけでは、利用できる情報源、処理の終了条件、禁止事項、情報が不足した場合の対応が分かりません。
見直し後の指示には、次の内容を明記しました。
- 抽出項目：対象サービス、発生日時、利用環境、エラー内容、顧客が試した操作を抽出する。
- 情報源：承認済みの社内ナレッジと過去の障害チケットだけを検索する。
- 出力形式：「確認できた事実」「原因候補」「追加で確認すべき事項」「推奨する次の対応」に分ける。
- 禁止事項：顧客への送信、本番環境への接続、設定変更、データ削除は行わない。
- 停止条件：情報が不足している場合は推測せず、担当者へ確認する。
何を確認し、どの形式で出力し、どの条件で止まるのかを具体化することで、担当者による使い方の差を減らせます。ただし、文章で送信を禁止しても、送信権限を持つツールが接続されていれば誤操作の可能性は残ります。文章による指示とシステムによる制限を組み合わせることが必要です。
プロンプトを「スキル仕様」へ変える
F社は、完成したプロンプトを「障害問い合わせ一次調査」というスキル仕様へ発展させました。スキル仕様には、AIへの指示だけでなく、入力情報、参照先、権限、例外処理、承認条件、責任者を含めます。
主な仕様は次のとおりです。
- 目的：社内資料から関連情報を集め、担当者が判断するための調査メモを作成する。
- 入力情報：問い合わせ本文、受付日時、顧客名、対象サービス、エラー画面、ログを使用する。
- 情報源：承認済みの手順書、FAQ、過去の障害チケット、サービス構成情報に限定する。
- 出力項目：問い合わせ概要、確認できた事実、不足情報、類似事例、原因候補、確認作業、回答の下書きに分ける。
- 禁止事項：本番環境へのログイン、プログラムの直接実行、顧客への送信、設定変更、データ削除を禁止する。
- 引き継ぎ条件：対象サービスを特定できない場合や、情報漏えい、本番変更などの可能性がある場合は担当者へ戻す。
こうして、担当者が変わっても、同じ入力に対して同じ手順で調査できるようになりました。現場担当者は「スキル仕様になってからは、何を入力し、どこで担当者に戻ってくるのかが分かる」と話します。スキル仕様は、担当者、AI、システムが守る業務上の契約です。
権限をスキル単位で分離する
F社は、AIエージェント全体へ広い権限を与える方式を廃止しました。一次調査スキルには、問い合わせチケットの参照、承認済みナレッジの検索、調査結果を下書き領域へ保存する権限だけを与えました。
一方、チケットを完了へ変更する権限、顧客へメールを送信する権限、本番サーバーへ接続する権限、手順書や過去チケットを更新・削除する権限は与えていません。顧客への送信は別のスキルが担当し、担当者が承認した文面だけを扱います。調査、下書き、承認、送信、記録更新を分離することで、一連の処理が無制限に進むのを防ぎました。
サンドボックスを構築する
ログを分析する場合は、対象ファイルのコピーだけをサンドボックスへ配置します。サンドボックスとは、プログラムやファイルを本番環境から切り離して実行するための隔離環境です。AIエージェントは、共有フォルダ全体や担当者の端末にある別のファイルを参照できません。
主な制限は次のとおりです。
- 外部通信：外部ネットワークへの接続を原則として禁止する。
- 実行ツール：承認された解析ツール以外は実行しない。
- リソース上限：処理時間、メモリ、保存容量に上限を設ける。
- 異常検知：繰り返し処理や想定外の通信を検知した場合は自動停止する。
- 環境の破棄：処理終了後に一時ファイルと実行環境を破棄する。
- 機密情報の保護：ログ内の認証情報らしき文字列はマスキングする。
AIが解析コードを生成しても、本番環境や担当者の端末では直接実行できません。セキュリティ担当者は「AIが指示を守ることを前提にせず、守らなくても被害が外へ広がらない構成にした」と説明します。失敗の影響範囲を閉じ込める設計へ改めました。
複数のスキルをワークフローとして接続する
F社は、問い合わせ対応全体を複数のスキルで構成するワークフローへ変更しました。
- 問い合わせ受付：顧客名、対象サービス、問い合わせ内容を整理する。
- 一次調査：社内ナレッジと過去事例を検索する。
- 追加確認：情報が不足している場合は、担当者向けの確認事項を作成する。
- 回答下書き：調査可能な場合は、顧客向け文面を作成する。
- 回答送信：担当者の承認後、指定された宛先へ送信する。
- 記録更新：承認済みの内容をチケットへ追記する。
問い合わせに「情報漏えい」「不正アクセス」「全データ消失」といった表現が含まれる場合は、通常の調査を停止し、セキュリティ担当者へ引き継ぎます。F社において、AIの自律性は「自由に行動する能力」ではなく、「条件に従って処理を選び、安全に引き継ぐ能力」と再定義されました。
スキルを継続的に改善する
F社は、スキル名、責任者、対象業務、入力、出力、権限、停止条件、バージョン、評価結果を記録するスキル台帳を整備しました。新しいスキルは、作成、検証、承認、公開、更新、廃止の順に管理します。
試験運用中、一次調査スキルが関連性の低い過去事例を提示する問題が発生しました。実行ログを確認すると、検索条件が広すぎることが原因でした。対象サービス、エラー種別、発生時期を優先する検索方法へ変更し、再検証した後、新しいバージョンとして公開しました。F社の取り組みは、プロンプトの作成から、仕事の目的、手順、権限、例外、責任者を標準化する活動へと発展しました。
AIを管理する仕組みが、現場の仕事を変えた
新しい運用へ移行した後、F社の担当者とAIエージェントの関わり方は変わりました。以前は、AIが作業している画面を常に監視していました。現在は、標準スキルに沿って処理された結果と、処理を停止した理由を確認する運用になっています。
安全対策によってAIの利用範囲が狭まったわけではありません。どの条件なら任せられるのかが明確になったことで、従来よりも多くの業務へAIを適用できるようになりました。
「AIを見張る運用」から「例外だけを見る」運用へ
問い合わせの分類、関連手順書の検索、過去事例の抽出、回答文の下書きは、サンドボックス内で処理されます。必要な情報がそろい、禁止条件にも該当しない通常の問い合わせは、定められたワークフローに沿って進みます。
担当者へ通知されるのは、判断が必要なケース、入力情報が不足しているケース、セキュリティ事故の可能性があるケースです。現場担当者は「AIが何をしているかを見張るのではなく、止まった理由を確認すればよくなった」と話します。
AIが停止することは失敗ではありません。安全に処理を続けられない条件を検知し、担当者へ判断を戻した結果です。停止条件が明確になったことで、担当者はAIの挙動を監視するのではなく、例外的な判断や顧客対応へ集中できるようになりました。
担当者ごとの品質の差が縮小した
問い合わせの分類方法、確認項目、過去事例の調査手順、回答文の構成がスキルとして標準化され、担当者による確認漏れや出力形式の違いが減りました。経験の浅い担当者でも、熟練者が蓄積してきた確認観点を利用できます。
AIが熟練者を置き換えたわけではありません。過去事例にない障害を判断する、顧客業務への影響を考える、複数の復旧案から適切な方法を選ぶといった仕事は、引き続き経験を持つ担当者が担います。AIは、判断に必要な情報を一定の品質でそろえます。
ベテラン担当者は「自分のやり方をそのままコピーするのではなく、判断するときに確認するポイントを残せた」と話します。若手の作業を一から修正するのではなく、例外的な判断や優先順位の付け方を教えられるようになりました。熟練者の判断基準を、組織全体で利用できる形に変えたことが、品質差の縮小につながりました。
失敗を改善に利用できるようになった
以前は、AIの出力に問題があると「AIが間違えた」「モデルの性能が不足している」と判断されることが多く、具体的な改善につながりませんでした。
新しい仕組みでは、AIが利用した情報、実行した手順、使用したスキルのバージョン、担当者の承認履歴がログとして残ります。問題が起きた場合は、次の観点から原因を確認できます。
- 参照データ：必要な情報がナレッジに登録されていたかを確認します。
- 検索条件：対象サービスやエラー種別を適切に絞り込めていたかを確認します。
- スキル仕様：手順、出力形式、停止条件に曖昧な部分がなかったかを確認します。
- 入力情報：問い合わせに必要な情報が含まれていたかを確認します。
- 権限設定：必要な情報源へアクセスでき、不要な操作が禁止されていたかを確認します。
- AIモデル：同じ条件でも判断が安定しない問題があったかを確認します。
管理者は「以前は結果が悪いとAIのせいにしていた。今は設計のどこを直すべきか確認できます」と話します。失敗を単発の事故として処理するのではなく、スキルと業務手順を改善する材料として扱えるようになりました。
「モデルの選定」から「業務設計」へ変わった
導入前のF社では、新しいAIモデルやツールを試すことがAI活用の中心でした。しかし、モデルを変更しても、業務の境界や権限が曖昧なままでは、担当者の不安は解消されません。
スキル管理を始めてから、社内では次のような議論が増えました。
- 業務の分解：対象業務をどの単位に分ければ、安全にスキル化できるかを検討します。
- 担当範囲：AIが観察、提案、実行のどこまでを担当するかを決めます。
- 停止条件：どの条件で処理を止め、担当者へ戻すかを明確にします。
- 再利用性：別部署でも利用できる入力、出力、権限になっているかを確認します。
- 影響範囲：失敗が起きた場合に、どこまで影響が及ぶかを確認します。
AIに詳しい一部の担当者だけでなく、業務知識を持つ担当者、システム担当者、セキュリティ担当者が共同でスキルを設計する体制へ移行しました。私たちも、AIツールの導入だけでなく、業務整理、権限設計、安全な実行基盤、ワークフロー設計、運用定着までを一体で支援しました。
効率だけで評価しない
F社は、一定期間の試験運用後に導入効果を評価しました。
- 対象業務の平均処理時間：目標は約40％の削減、評価結果は約46％の削減でした。
- AI出力の再作業率：目標は15％未満、評価結果は約11％でした。
- 無承認操作：目標は0件、評価期間中も0件でした。
- 複数部署で再利用されたスキルの割合：目標は50％、評価結果は約58％でした。
- スキルの作成から公開までの期間：目標は30％の短縮、評価結果は約35％の短縮でした。
- 実行履歴と承認履歴の記録率：目標は95％以上、評価結果は約97％でした。
- 責任範囲を理解している利用者の割合：目標は80％、評価結果は約84％でした。
F社が重視したのは処理時間の短縮だけではありません。未承認の操作を防げたか、担当者が変わっても同じ手順を再現できるか、別部署で再利用できるか、問題が起きた際に原因を説明できるかも評価しました。効率、安全性、再現性、再利用性、説明可能性を同じ枠組みで確認したことで、AI導入の効果を多面的に判断できるようになりました。
F社の担当者は「AIに何でもさせることが目標ではないと気づいた。安心して任せられる仕事を1つずつ増やすことが、本当のAI活用でした」と振り返ります。権限や停止条件を設けることは、AI活用を妨げる制約ではありません。安心して利用範囲を広げるための基盤になりました。
まとめ
AIエージェントの導入では、高性能なAIモデルを選ぶだけでなく、人とAIの責任範囲を明確にし、安全に処理できる環境を整える必要があります。AIの自律性を高めるほど、権限、承認、停止条件、ログ、例外処理の設計が重要になります。
F社の取り組みを支えたのは、次の3つの考え方でした。
- 責任範囲の定義：AIが観察、提案、実行のどこまでを担当するのか、業務ごとに決める。
- 安全な実行環境：スキルごとに必要最小限の権限を与え、サンドボックス内で処理する。
- スキルの組織管理：個人のプロンプトを、検証、承認、バージョン管理が可能な組織のスキルへ変える。
ギグワークスクロスアイティは、AIエージェントの導入だけでなく、業務整理、人とAIの境界設定、権限設計、安全な実行基盤、ワークフローとスキルの標準化までを一体で支援します。
AIエージェント時代に必要なのは、「何ができるAIか」を探し続けることではありません。自社では何を、どの条件で、どこまでAIへ任せるのかを具体的に設計することです。
この記事を書いた人
