IT運用向けAIエージェント:社内チケット、アクセス権、監視、ドキュメント管理

課題

社内IT運用は止まりませんが、それを処理するチームは止まります。サポート業界でよく引用される、約1,000社を対象にしたJitbitの分析によれば、2017年時点で技術担当者1人が処理するチケット数は平均1日21件、平均解決時間は82時間だったとされています。これは執筆者自身が現在の目標値ではなく過去の基準として位置づけているやや古いデータであり、最新の正確な数値としてではなく、大まかな目安として扱うべきものです。

1件あたりの対応時間については、マネージドサポート事業者であるEndsightが、12か月にわたって追跡した自社の10,923ユーザーを対象に平均63分という数字を挙げています。これは単一企業の内部データであり第三者による検証を受けていないため、業界標準としてではなく、あくまで一つの指標として捉えるべきです。

最も裏付けの確かなポイントはアクセス権に関するものです。2024年にThe Hacker Newsが報じたWing Securityの調査によれば、企業の63%で退職者が組織のデータへのアクセス権を保持したままであり、43%ではGitHubやGitLab上のコードリポジトリへのアクセスが依然として可能とされています。社内チケットキューに放置されているアクセス権の付与・失効申請は、まさにこの種の統計の直接的な予備軍です。

この処理の遅れには、セキュリティリスクより目立たないもう一つの結果があります。チケットキュー自体が読みにくくなることです。緊急の依頼(業務を止めているアクセス権の不具合)と定型的な依頼(ナレッジベースですでに10回は回答されている質問)が混在すると、ITチームは解決と同じくらいの時間を仕分けに費やすことになります。そのキューの多くは本来人間に届くべきではなく、既存のドキュメントを読めるエージェントが、チケットが順番待ちになる前に吸収できる領域です。

エージェントが行うこと、そのステップ

IT運用向けの自律型AIエージェントは、専用の隔離環境の中で継続的に稼働し、休むことなくチケットキューを監視します。

まずJira上の受信チケットを分類します。既知の問い合わせ、アクセス権申請、技術的インシデントです。すでに文書化された問い合わせについては、チームのNotionナレッジベースで見つけた手順を引用しながら直接回答します。ツールやリポジトリへのアクセス権申請については、自ら実行するのではなく、判断に必要な情報をすべて添えた構造化されたチケットを起票します。

監視面では、エージェントはDatadogから上がるアラートを監視し、GitHub上の直近のコミットやデプロイと突き合わせます。デプロイ直後に発生したレイテンシの上昇は、孤立したインシデントとして扱われません。突き合わせの結果が明確な場合、技術チームに役立つコンテキストを添えて文書化されたGitHub issueを起票します。行き詰まったチケット、重大なアラート、承認待ちのアクセス権申請はいずれも、ITチームへのSlack通知を発生させます。起票したチケット、突き合わせたアラート、送信したメッセージといったすべてのアクションは、正確なステータスとともにエージェントのタイムラインに記録されます。

具体例で仕組みを説明します。ある従業員が金曜の夜に、部門横断プロジェクトのために特定のGitHubリポジトリへのアクセスを求めるチケットを起票したとします。エージェントはこの依頼を分類し、内容が完全かどうか(対象リポジトリ、理由、希望期間)を確認したうえで、月曜の朝にIT責任者がすぐ承認できるよう構造化されたチケットを準備します。誰かが偶然気づくまで一般的なキューの中で放置されることはありません。

活用しているインテグレーション

Jiraは引き続き社内チケットの基幹キューです。エージェントはグラントで許可されたアクションの範囲で、依頼を検索し(search_issues)、詳細を確認し(get_issue)、新しい構造化issueを作成できます。

GitHubは技術的なアラートをコードの変更と突き合わせるために使われます。直近のコミット一覧(list_commits)、プルリクエストの詳細確認(get_pull_request)、突き合わせが確定した際の文書化されたissue作成(create_issue)です。

Datadogは監視の生の情報源であり、エージェントは監視ツールそのものを置き換えることなくこれを参照します。Notionはエージェントが回答前に参照する手順やランブックを格納し、SlackはITチームへのリアルタイム通知を担います。

人間に残る役割

エージェントは準備と警告に徹し、アクセス権やインフラの変更を自らの判断で実行することはありません。アクセス権の付与・失効を実際に行うのは人間の役割であり続けます。エージェントはJira上に文書化された申請を起票し、IT担当者がそれを実行してクローズします。

直近のデプロイと一致しない、判断の分かれるアラートの重大度は、Slack通知を超えるエスカレーションの前に人間が判定します。コードやインフラの修正内容を決定し適用するのは、当然ながらエンジニアの仕事です。他のAtakoエージェントと同様、管理者がJira、GitHub、Datadogに対するグラントをアクションごとに付与・調整し、読み取りのみか読み書き両方かの範囲を明示的に定める必要があります。

この境界線はエージェント自身にも及びます。業務コンテキストがカバーしていない状況、例えば通常とは異なるライセンス更新や、文書化されていないシステムへのアクセス申請に遭遇した場合、エージェントはあいまいな回答を無理に出しません。ITチームに通知し、チケットを人間の対応に委ねたまま残します。存在しない手順を推測することはしません。

測定可能な成果

最も直接的な成果は、チケットやアラートの発生から最初の対応までの空白時間の短縮です。24時間稼働するエージェントは、日曜の夜に起票されたチケットを分類し、対応するアクセス権申請を準備しておくことができ、月曜にチームが出社するまでキューで待たせることがありません。

第二の成果は、Wing Securityが裏付けた問題に直結します。退職が確認され次第、失効チケットの起票を自動化することで、トリガーとなる出来事からIT側のアクション実行までの遅延を縮め、不要にアクセス権が有効なままになる期間を抑えます。この期間は、継続的な監視がなければ、前述の調査が示すとおり数週間から数か月に及ぶこともあります。

起票されたチケット、突き合わせたアラート、送信されたメッセージはすべて、Atakoの監査ログでいつでも確認でき、ITチーム向けにCSVで最大5万行までエクスポートできます。この完全なトレーサビリティは、社内セキュリティ監査にも役立ちます。誰がいつどのような根拠でアクセス権を申請したかを調べるために、複数のツールにまたがる経緯を再構築する必要はありません。

IT向けエージェントはStandardプランに含まれ、エージェントスロット1つにつき月額20ユーロ、モデル呼び出しをカバーする月間1,000クレジット込みです。処理したチケット数やエージェントとやり取りする従業員数は料金に一切影響せず、影響するのは同時に稼働するエージェントの数だけです。少人数のITチームでも、社内チケット、監視アラート、アクセス権申請のすべてを1つのエージェントでまかなうことができ、対象範囲が数か月かけて新しいツールやチームに広がっても、フローごとにスロットを増やす必要がないためコストは予測可能なままです。