Atomicworkで情シス窓口を任せる方法｜実行の範囲と承認の線

「生成AIの利用申請が毎日のように届くのに、承認とライセンスの付与はいまも手作業のまま」「問い合わせ窓口をAIにしたのに、結局は人がチケットを開いて処理している」——生成AIを全社に配り始めた情報システム部門から、2026年に入って増えている声です。米国の Atomicwork は、この「受けたあとの処理」までAIに進めさせる基盤で、2026年6月には、役割・予算・権限・監査記録を一体で持つAIの働き手を、全顧客に向けて提供すると発表しました。ただ、AIが答える範囲と、AIが実行する範囲は、別々に決めるものです。この記事では、Atomicwork がどこまで実行するのか、既存のサービス管理基盤とどう付き合うか、どの依頼から任せるかを、場面ごとに整理します。

Atomicwork は、情シスの窓口をAIコワーカーが受けて処理まで進める基盤

Atomicwork は、AIを前提に作られたITサービス管理（ITSM）の基盤です。2022年に米国で創業し、公式サイトでは自らを「AIコワーカーが動かし、IT部門が統制する」サービス管理の基盤と説明しています。情報システム部門の窓口に加え、人事・経理・法務などの社内窓口にまで広げる全社のサービス管理を対象にしており、資金面では2025年1月に2,500万ドルのシリーズAを公表しています。

中心にあるのは「AIコワーカー」と呼ぶ仕組みです。社員がだれでも話しかけられる汎用のAIコワーカーが、パスワードの再設定やソフトウェアの利用申請を受け、その先に、インシデント管理・セキュリティ・フィッシング対応・入社手続き・福利厚生・経理・法務といった役割ごとのAIコワーカーが並びます。公式の説明では、それぞれが役割・技能・アクセス制御を個別に持つとされ、複雑な依頼はAIコワーカー同士で連携して処理すると打ち出しています。

社員が依頼を出す窓口は、Microsoft Teams、Slack、メール、ブラウザ、社内ポータルのほか、ChatGPT や Claude のような外部のAIアシスタントから MCP 経由で呼び出す形も用意されています。社員にとっては、いつものチャットに話しかければ処理が進むという体験になりますが、判断する側から見ると、社内のチャットから業務システムの書き換えまでが一本の線でつながるということです。この記事では、その線のどこに人を置くかを中心に見ていきます。

2026年の動き：役割・予算・権限を持つ「AIの働き手」として再編

2026年6月、Atomicwork は「統制されたAIの働き手」を掲げる基盤を、全顧客と提携先に向けて提供すると発表しました。海外の技術メディアの報道によると、各AIコワーカーは職務・技能・予算・範囲を絞った権限を持ち、すべての動作が管理画面に記録されます。汎用のAIコワーカーはチャットに加えて音声や画像でのやり取りにも対応し、マイクロソフトの Azure 上のAI基盤で構築されていると伝えられています。

同じ報道は、注意点も併記しています。「最初の統制されたAIの働き手」という表現は提供元自身の位置づけであり、統制の仕組みが企業のセキュリティや監査の要件に照らして第三者に検証されたわけではないこと、顧客数や実際に動いているAIコワーカーの数は公表されていないこと、ServiceNow をはじめとする既存の大手や専業の競合も、エージェントの統制機能を打ち出していることです。導入の判断では、宣伝の言葉より、自社の要件に沿って何ができるかを試験で確かめるほうが確実です。

もう一つの動きは、2025年12月に更新情報として公開された、対話で権限の申請を受けて付与まで進める機能（当時は試験提供）です。公式のアクセス管理のページでは、申請の受け付けから付与、取り消しまでをエージェントが担い、必要な期間だけ権限を与え、状況が変われば即座に取り消すと説明しています。窓口の自動化が、回答から権限の管理へと踏み込んできたことが、2026年の大きな変化です。

「答える」AIと「実行する」AIでは、判断の重さが違う

社内の問い合わせをAIで受ける仕組みそのもの、つまり受け付ける質問の範囲の決め方や、答えの元になる文書の持ち主の決め方には、すでに多くの解説があります。Atomicwork を検討するときに新しく考えなければならないのは、その先です。AIが答えるだけなら、誤りは読んだ人が気づき、人に聞き直せば済みます。AIが実行する場合、誤りは付与された権限や書き換えられた記録として残り、だれも気づかないまま続くことがあります。

たとえば、営業部の社員が「顧客管理の画面が見られない」と依頼したとします。答えるだけのAIなら、申請の手順を案内して終わります。実行するAIは、本人の所属を確かめ、同じ部署の人がどの権限を持っているかを見て、同じ権限を付けるところまで進めるかもしれません。その判断が合っていれば数分で解決しますが、同じ部署の先輩がたまたま兼務で別部署の顧客まで見える権限を持っていた場合、AIは善意で過剰な権限を付けることになります。

だから、Atomicwork の導入を考えるときの問いは「AIの回答精度は十分か」ではなく、どの操作を、だれの承認のもとで、AIに実行させてよいかです。回答の正しさは試験で数えられますが、実行の正しさは、誤ったときに気づける仕組みがあって初めて数えられます。以降の場面ごとの整理も、この問いに沿って進めます。

場面1：パスワードの再設定と、よくある質問への回答

最初に任せやすいのは、パスワードの再設定、多要素認証の再登録、会議室や複合機の使い方といった、件数が多く、手順が決まっていて、間違えても影響が小さい依頼です。Atomicwork の料金表でも、社内の知識をもとに答える「知識の支援」が最も安い成果単価で設定されており、提供元自身がここを入口と位置づけていることが分かります。

ただし、パスワードの再設定は、なりすましの入口にもなります。チャットで「パスワードを忘れた」と言ってきた相手が本人かどうかを、AIがどう確かめるかは必ず確認してください。Teams や Slack に社内の認証で入っていることを本人確認とみなすのか、追加の確認を求めるのかは、AIではなく情報セキュリティの方針で決めることです。チャットのアカウントそのものが乗っ取られている場合まで想定するなら、管理者権限を持つ人のパスワード再設定は、AIの対象から外しておくのが無難です。

回答の側では、AIに根拠を書かせることを条件にします。社内規程やマニュアルのどの文書を元に答えたかを回答に添えさせ、根拠が見つからないときは「分からない」と返して人に回す設定にしておけば、もっともらしい作り話を防げます。根拠の文書が古いまま残っていると、AIは古い手順を自信を持って案内するため、文書の持ち主と見直しの時期も併せて決めておきます。

場面2：生成AIツールの利用申請と、ライセンスの付与

2026年の情報システム部門で特に増えているのが、生成AIツールの利用申請です。「Copilot のライセンスを付けてほしい」「ChatGPT の法人契約のワークスペースに入れてほしい」「新しいAIツールを試したいが使ってよいか」といった依頼は、件数が多いうえに、ライセンスの費用と情報の持ち出しという二つの判断を含みます。Atomicwork のアクセス管理は、Okta や Azure AD（現在の Microsoft Entra）、Google Workspace などから、アプリと権限の一覧を取り込み、それをもとに申請を受け付ける仕組みです。

ここで分けたいのは、会社として承認済みのツールのライセンス付与と、まだ審査していないツールの利用可否の判断です。前者は、所属や役職の条件を満たせば付与してよいという規則が書けるので、AIに実行させやすい領域です。期限付きで付与し、一定期間使われなければ見直す運用にすれば、使われないライセンスの費用も抑えられます。後者は、データの扱い・利用規約・契約条件を確かめる審査であり、AIに可否を判断させてはいけない領域です。AIの役割は、申請の内容を整理して審査の担当に回し、結果を本人に伝えるところまでにとどめます。

承認の経路は、公式の説明では Slack や Teams の上で承認者に回り、複数の承認者やグループの方針を設定して、一人の不在で申請が止まらないようにできるとされています。また、付与した権限はすべて元の申請にさかのぼれると説明しています。監査のときに「なぜこの人がこの権限を持っているか」を答えられることが、AIに実行を任せる最低条件です。よくある失敗は次のとおりです。

• 審査前の新しいAIツールについて、AIが過去の似た申請を参考に「利用できます」と答えてしまう
• 部署単位で一括付与し、異動や退職のときにだれが外すのかが決まっていない
• 承認者を一人に固定し、不在の間に申請がたまって、現場が個人契約のAIツールで代用し始める

場面3：入社・異動・退職のアカウントと端末

役割ごとのAIコワーカーの一つに、入社手続きを担うものがあります。公式サイトでは、入社日に必要なアカウントと道具をそろえる役割として紹介されています。入社・異動・退職は、人事の記録を起点に、複数のシステムの権限を一斉に変える作業で、手作業では漏れが起きやすい場面です。特に退職時の権限の取り消し漏れは、監査で繰り返し指摘される項目です。

この場面は、AIの判断より規則のほうが向いています。「営業部に配属されたら、この権限の組み合わせを付ける」という対応表があれば、AIは対応表に従って処理するだけでよく、判断の余地はほとんどありません。逆に、対応表が無いまま「同じ部署の人と同じ権限」をAIに推測させると、前任者が持っていた古い権限まで引き継がれます。任せる前に、役割ごとの権限の対応表を人が整えることが前提になります。

なお、Okta との連携の全機能を使うには、Okta 側でもライフサイクル管理などの追加の契約が必要だと、提供元のサポート記事で説明されています。Atomicwork の費用だけでなく、連携先の認証基盤の契約が足りているかも、見積もりの段階で確かめておきます。人事の記録がどのシステムに正しく入っているかも、AIに任せる前の確認事項です。人事の記録の更新が遅れる会社では、AIは古い所属のまま権限を付けてしまいます。

場面4：端末の紛失と、遠隔での施錠・消去

端末管理との連携では、マイクロソフトの端末管理サービス（インチューン）から、機種・基本ソフト・準拠状況・利用者の割り当てといった端末の属性を取り込めると、提供元のサポート記事で説明されています。同じ記事では、遠隔での施錠やデータの消去といった端末への操作には、追加の権限が必要とされています。端末の情報を読むことと、端末を操作することは、権限の上でも別物として扱われているわけです。

端末の消去は、取り消しのきかない操作の代表です。「ノートパソコンをなくした」とチャットで連絡があったとき、AIが即座に遠隔消去まで実行すれば、情報漏えいは防げるかもしれません。しかし、実は自宅に置き忘れていただけで、保存前の作業が消えることもあれば、悪意のある第三者が本人を装って他人の端末を消去させることもありえます。取り消せない操作は、AIに実行させず、人の承認を必ず挟むのが原則です。

現実的な分担は、AIが連絡を受けて状況を聞き取り、端末を特定し、施錠の候補として担当者に回すところまでです。施錠は担当者の承認後、消去は責任者の承認後と、操作の重さに応じて承認者を変える設定にしておきます。そもそも端末を操作する権限を Atomicwork に渡すかどうか自体を、最初の導入では見送るという判断も十分にありえます。

実行の範囲を三段階に分けて決める

ここまでの場面を操作の重さで整理すると、次のようになります。区分は、問い合わせの種類ではなく、誤ったときに取り消せるかどうかで分けるのがこつです。

区分	操作の例	AIに任せる範囲	人が持つもの
案内のみ	手順の案内、規程の回答、申請状況の照会	根拠を添えた回答まで	根拠文書の持ち主と見直し
承認後に実行	承認済みツールのライセンス付与、グループへの追加、期限付きの権限	申請の整理、承認者への回付、承認後の付与と記録	承認と、権限の対応表の管理
人が実行	審査前のAIツールの可否、管理者権限の付与、端末の消去、退職者の記録の削除	聞き取りと担当者への回付まで	判断と操作そのもの

最初は「案内のみ」と、二段目のうち件数の多い数種類だけを任せ、記録を見ながら広げていきます。公式の説明では、各AIコワーカーの手順・技能・道具を本番に出す前に試験できるとしているので、新しい操作を任せるたびに試験の結果を残しておきます。試験では、正しく処理できた件数だけでなく、AIが「人に回すべき」と判断できた件数も数えます。

三段階の線は、一度決めたら終わりではありません。AIが実行した結果に誤りが見つかった操作は、一段上の区分に戻します。区分を変える権限は情報システム部門の責任者に集め、AIコワーカーの設定を現場の担当者が自由に変えられない形にしておくと、線が知らないうちに緩むことを防げます。

承認をだれが持つか：既存の権限管理を引き継ぐ前提

Atomicwork の公式の説明では、Okta や Microsoft Entra と連携することで既存の役割・方針・承認の流れを引き継ぎ、多段の承認や理由の記入欄といった承認の条件は Atomicwork の中で調整できるとされています。つまり、AIが勝手に承認の規則を作るのではなく、会社がすでに持っている権限管理の規則の上で動く設計です。

裏を返すと、既存の権限管理が整っていない会社では、その乱れがそのままAIの実行に引き継がれます。役割の定義があいまいで、例外の付与が積み重なっている状態のままAIに実行させると、例外が自動で増えていきます。導入前に主要なシステムの権限の棚卸しを一度行い、承認者を人名ではなく役割で決め直しておくことをおすすめします。

もう一つ確かめたいのが、AIコワーカー自身の権限です。各AIコワーカーは仕事に必要な範囲に絞った権限を持つと説明されていますが、その範囲を決め、定期的に見直すのは人の仕事です。AIコワーカーを一人の社員と同じように扱い、付与されている権限を四半期ごとの棚卸しの対象に含めると、管理の抜けが生じにくくなります。AIコワーカーごとの持ち主を、情報システム部門の中で人名で決めておくことも忘れないでください。

ServiceNow・Jira の上に載せるか、置き換えるか：二重化を避ける判断

Atomicwork は、自社のサービス管理基盤として丸ごと使う形のほかに、ServiceNow や Jira のサービス管理製品の上にAIの働き手だけを載せる形を用意しています。ServiceNow との連携のページでは、ServiceNow が記録の正本のまま残り、既存の手順・対応期限の取り決め・報告は変わらないと説明しています。接続は ServiceNow 側の MCP サーバーを通じた読み書きの接続で、インシデント・申請・ナレッジ・カタログ・構成管理の情報を扱い、AIが解決できない依頼は ServiceNow 上で働く担当者に引き継がれます。

二重化を避けるうえで大事なのは、記録の正本を一つにすることです。上に載せる形なら、チケットの正本は既存の基盤に残り、Atomicwork は窓口と処理を担う位置づけになります。この場合に確かめるべきは、双方向の同期で項目の更新や返信がどこまで正しく行き来するか、Atomicwork の画面と既存の画面のどちらで集計した数字を正式な報告に使うか、です。同じ依頼の件数が二つの画面で食い違う状態は、早めに解消しておかないと、効果の測定そのものが信用されなくなります。

置き換える形は、既存の基盤の更新時期が近く、作り込みが小さい会社では選択肢になります。提供元は、上に載せる形について「まずIT部門で価値を確かめてから、切り替えを決められる」と案内しており、置き換えを最初から前提にしなくてよい作りです。最初は上に載せて試し、効果と運用の負担を見てから置き換えの是非を検討する順番が、無理のない進め方です。

何が社外に出るか：接続先と保存地域

Atomicwork を入れると、社員がチャットに書いた依頼の文面、社員名簿や所属の情報、アプリと権限の一覧、端末の属性、既存基盤のチケットとナレッジが、提供元のクラウドで処理されます。公式サイトでは、SOC2 や ISO 42001 などの認証の取得、欧州の個人データ保護規則への対応をうたい、データの保存地域として米国・欧州・アジア太平洋から選べると説明しています。

日本の個人情報保護法の観点では、外国にある事業者への委託にあたるかどうか、保存地域としてアジア太平洋を選んだ場合に実際にどの国で保存・処理されるのか、AIモデルの処理がどこで行われるのかを、契約前に書面で確認します。特に人事・経理の窓口まで広げる場合は、給与や評価に関わる情報が流れる可能性があるため、窓口を広げる順番と、流してよい情報の範囲を一緒に決めることが必要です。

社員が依頼の文面に、顧客の個人情報やパスワードそのものを書き込んでしまうこともあります。チャットの窓口では避けにくいことなので、次の点を事前に決めておきます。

• 利用案内に「依頼に書いてはいけないもの」（パスワード、顧客の個人情報、未公開の契約情報）を明示する
• 依頼の記録の保存期間と、誤って書き込まれた情報を消す手順を提供元に確認する
• 国内の販売代理店や日本語での支援体制は、公式サイトの範囲では確認できなかったため、問い合わせの際に確かめる

費用の増え方：クレジット型と成果課金型

公式の料金ページでは、二つの課金の考え方が示されています。一つは、基盤の年額に、AIの利用量を表すクレジットを組み合わせる利用量型です。最も小さいプランは年額2万5,000ドルからで、2万5,000クレジットと2人分のAIコワーカーが含まれ、追加のAIコワーカーは1人あたり月額499ドルと公表されています。クレジットはAIコワーカーが仕事をこなすたびに消費され、処理の手順の数、道具の呼び出し、出力の長さ、推論の複雑さに応じて増えると説明されています。

もう一つは、解決した件数に応じて支払う成果課金型です。知識の支援は1件1ドル、権限の自動化は1件2ドル、依頼の解決は1件3ドルからで、それぞれ年間の最低件数が設定されています。ServiceNow や Jira の上に載せる形では、基盤の利用料はかからず成果課金になると案内されています。ここで確かめたいのは、何をもって「成果」と数えるかの定義です。AIが処理したと記録しても、社員が同じ件で再び問い合わせていれば、解決とは言えません。再問い合わせの扱いを契約前に確認しておきます。

利用量型では、AIコワーカーの数と、一件あたりの処理の重さが費用を押し上げます。公式サイトでは、AIコワーカーごとに予算と支出の上限を設定できるとしているので、試験導入の段階から月ごとの上限を決め、上限に近づいたときにだれに通知するかを設定しておきます。成果課金型では最低件数が実質的な年額になるため、現在の窓口の件数を記録から数え、最低件数に届くかを先に確かめます。

止め方・やめ方：AIコワーカーを外しても窓口が回る形に

AIに実行を任せる仕組みでは、止める手段を最初に決めておきます。止めたい場面は、AIが誤った権限付与を繰り返しているとき、連携先のシステムに障害があるとき、大きな組織変更で権限の対応表が古くなったときなどです。止め方は、特定の操作だけを止める、特定のAIコワーカーを止める、窓口全体を人の受付に戻す、の三段階で用意し、それぞれだれが止める判断をしてよいかを決めます。

止めたあとに窓口が回るかも重要です。AIに任せた期間が長くなるほど、人の担当者は手順を忘れ、手作業の受付の型も失われます。上に載せる形であれば、既存の基盤で人が処理する流れが残っているので、AIを外しても窓口は止まりません。置き換えた場合は、AIを止めたときに人が処理する手順書を、導入時に作っておく必要があります。

契約をやめるときには、チケットの記録、AIコワーカーの処理の記録、承認の履歴を、自社の側に取り出せるかを確かめます。連携のページでは、各動作が日時・理由・対象の記録とともに残ると説明されていますが、権限の付与の記録は監査で数年さかのぼって求められることがあるため、取り出せる形式と、提供元での保存期間を契約の時点で書面にしておきます。

試験導入の手順：「実行」を一つ任せるまで

試験導入は、窓口の全部をいきなり任せるのではなく、案内から始めて、実行を一つだけ任せるところまでを区切りにすると判断しやすくなります。

判断の材料は、処理時間の短縮だけではありません。誤った実行の件数と、そのときに気づけたかどうかです。誤りがゼロでも、気づく仕組みが無かったのなら、まだ範囲を広げる段階ではありません。試験の記録は、情報システム部門の責任者と情報セキュリティの担当が一緒に読み、次に任せる操作を決めます。

よくある質問

日本語の依頼にも使えますか。

公式サイトの範囲では、日本語での運用実績や対応の詳しい説明は確認できませんでした。試験導入で、社内の略語・部署名・社内システムの通称を含む依頼を実際に投げ、意図どおりに理解されるか、承認者への通知が自然な日本語になるかを確かめるのが確実です。

ServiceNow 自身のAI機能と、何が違いますか。

既存基盤の提供元もエージェントや統制の機能を強化しており、機能の差は時期によって変わります。比べるべきは機能表より、すでに契約しているライセンスで使える範囲、窓口を Teams や Slack にどこまで寄せたいか、費用の数え方（利用量か成果か）の違いです。上に載せる形は基盤の利用料がかからないため、並べて試す余地があります。

AIコワーカーが誤って権限を付けたら、責任はだれにありますか。

AIに責任は取れません。実行の範囲と承認の規則を決めた部門が責任を持つ前提で設計し、提供元の責任範囲は契約で確認します。誤りを見つけたら、まずその操作を止め、付与した権限を外し、記録から原因をたどってから区分を見直します。

情報システム部門が少人数の会社でも合いますか。

年額や成果課金の最低件数を考えると、窓口の件数が一定以上あることが前提になります。件数が少ない会社では、まずチャットツールの標準機能や既存の認証基盤の申請機能で足りないかを確かめ、足りない部分がはっきりしてから検討するほうが、費用の見通しを立てやすくなります。

まとめ

Atomicwork は、社内の依頼を受けて答えるだけでなく、権限の付与や記録の更新まで実行するAIコワーカーを、統制の仕組みと一緒に提供する基盤です。入れるかどうかの判断は、AIの回答精度より、どの操作をだれの承認のもとで実行させるかで決まります。取り消せる操作から任せ、取り消せない操作には人の承認を残し、ServiceNow や Jira を使っているなら上に載せる形で記録の正本を一つに保つ。費用の数え方と止め方を契約の前に確かめ、気づく仕組みを整えてから範囲を広げていくことが、AIに窓口を任せるときの順番です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。