
Claude Code、Codex、Antigravityなどの“エージェント型”サービスの登場により、AIは外部ツールを呼び出して処理を実行するフェーズに入りました。その流れを受け、2026年の情シス界隈で注目されているのがAIエージェントによるSaaS運用です。
ポイントは、SaaSがAIに置き換わるのではなく、SaaSの上に“AIエージェント層”が乗り、複数ツールをまたいだ処理が「標準の運用」になっていくことです。業務システム側もエージェントの活用を前提に拡張が進み、情シスの論点は“導入するか”から“どう統制するか”へと移り始めています。
本記事では、AI×SaaSが一般化する中で生じる変化を整理し、そこで求められる情シスの役割について解説します。
【関連記事】ABCI 3.0稼働開始で国内AI環境はどう変わる?──料金や活用事例、利用手順を解説
2026年、コアユーザーにとってAIは「質問に答える」だけでなく、「外部ツールを呼び出して処理を“実行する”」ことが当たり前となっています。現場で起きているのは、SaaSの上に“AIエージェント層”が乗り、複数ツールを横断して仕事が加速する、という状況です。
2010年代後半~2020年代前半のDXで推進されていた自動化(iPaaS/RPA/ワークフロー)は、あらかじめ決めた手順を正確に回すことに特化していました。一方、AIエージェントは、会話の意図を受け取りながら「次に何を呼ぶべきか」を選び、複数SaaSをまたいだ実行を組み立てます。そうして、運用の中心は「アプリの画面」から「AIエージェントが呼び出すアクション」に移ってきています。
AIエージェントがSaaSを横断して動くとは、具体的にどのような状況を指すのでしょうか。
典型的な例として、社内IT運用の一連の処理を考えてみましょう。
従来であれば、こうしたケースでは以下のような作業を手動で実施する必要がありました。
一方で、AIエージェントが導入されている環境では、一連の流れを次のような形で自動化できます。
ここで重要なのは、AIが単独で処理を行っているわけではないという点です。実際には、各SaaSのAPIやワークフローを順番に呼び出しながら業務を進めています。AIエージェントはその「オーケストレーター」として機能し、複数のツールを組み合わせて一つの業務を完結させているのです。
【関連記事】オーケストレーションとは? 単なる自動化と何が違うのか
こうした変化により、SaaSは、AIエージェントが業務の途中で呼び出す「実行コンポーネント」としての性格が強まっていきます。
その背景にあるのは、企業で使われるSaaSの数そのものが増え続けているという事情です。企業が利用するアプリ数は今や数十種類におよぶことも珍しくありません。SaaSが増えるほど、個別の画面を人が順番に操作してつなぐ運用は限界に近付きます。
加えて、AI活用そのものも急速に日常業務へ入り込んでいます。『令和7年版情報通信白書』(総務省)によると、日本において、生成AIサービスを「使っている(過去使ったことがある)」と回答した人は2024年度で26.7%と2023年度(9.1%)の3倍近く。昨今のAIの普及ぶりから、2026年度にはその割合はさらに急増していると見込まれます。
この変化の中では、SaaSに求められる要件も変わります。重要なのは、画面が使いやすいかだけではなく、APIが整備されているか、自動化しやすいか、外部から安全に呼び出せるか、実行結果を記録できるかといった点です。
SaaSは、これまで以上に「人のためのUI」と「エージェントのための接続点」の両方を備えた存在として評価されるようになっています。
こうした変化は、情シスの役割にもおよびつつあります。従来のSaaS運用では、アカウント発行、アクセス権設定、ワークフロー整備、利用部門からの問い合わせ対応など、「個別アプリを安定運用すること」が主な役割でした。
しかし、AIエージェントが複数SaaSをまたいで業務を実行する環境では、それだけでは足りません。情シスに求められるのは、SaaS同士の接続関係を設計し、どこまでをAIに任せ、どこで人が確認し、どのように証跡を残すかまで含めて全体を統制することです。
ここで重要なのは、AIエージェントの登場でSaaSが不要になるわけではないということです。むしろSaaSは、これまで以上に「業務機能を提供する部品」として重要になります。違うのは、その価値が単体機能ではなく、接続性や統制しやすさまで含めて評価されるようになる点です。
AIの普及を受けて、「エンジニアの仕事は減るのではないか」という見方もあります。しかし、少なくとも足元の統計を見る限り、IT人材需要が一律にしぼむとは言いにくい状況です。
米国労働統計局(BLS)は、ソフトウェア開発者・QAアナリスト・テスターの雇用が2024〜2034年に15%増加し、年平均で約12万9,200件の求人機会が生じると見込んでいます(※1)。これは全職種平均を上回る伸びであり、AI活用が進んでも、システム設計や実装、運用を担う人材需要は引き続き強いことがうかがえます。
日本国内に目を向けると、IPAの「DX動向2025」でも、日本企業ではAI関連人材が人材種別を問わず不足していると整理されており、不足感がなお続いていることが示されています。特にAI、ビッグデータ、サイバーセキュリティといった分野は、今後も重要性が高いとみられます。
※1:出典:Bureau of Labor Statistics, U.S. Department of Labor, Occupational Outlook Handbook, Software Developers, Quality Assurance Analysts, and Testers (visited March 8, 2026).
AI時代のIT人材需要を考えるとき、重要なのは前述の通り、情シスの役割が変化しつつあるということです。AIエージェントがSaaSを横断して業務を実行する環境では、次のような領域で新しい役割が生まれています。
これらは、いわば「業務システムのオーケストレーション基盤」を設計・運用する仕事です。従来であれば個別アプリケーションの導入や設定が中心だった情シスの役割は、より広い視点でシステム全体の連携を設計する方向へシフトしています。
もう一つ見逃せないのは、AIの導入が進むほどシステム運用の難易度が高まるという点です。
AIエージェントが複数のSaaSを操作する環境では、以下のような課題が新たに生まれます。
こうした課題は、単にAIモデルを導入するだけでは解決できません。つまりAI時代には、「AIが安全に働けるシステム環境を設計できる人材」を多くの企業が必要とすると見込まれます。
次章では、このAI時代のIT運用を支えるために、企業がどのような体制やスキルを整備すべきかを詳しく見ていきます。
AIエージェントがSaaSを横断して業務を実行する環境において重要なのは、「どこまでAIに任せられるのか」を以下の三つの視点で設計することです。
これらを実務レベルで整理すると、AIエージェント運用の統制は次の6つのレイヤに分解できます。
最初に整備すべきなのがID管理です。AIエージェントを単なる共有アカウントとして扱うと、後から「誰が何をしたのか」が追跡できなくなります。
そのため、AIエージェントは人のユーザーIDとは別に、非人間ID(NHI:Non-Human Identity)として管理することが重要です。具体的には以下のような資産を棚卸しします。
そして、「どのAIエージェントが、どのSaaSに、どの権限でアクセスするのか」を台帳化します。これはAIエージェント時代のIAM(Identity and Access Management)の基盤になります。
AIエージェントに権限を与える際は、「必要なことだけを、必要な範囲で許可する」という考え方がこれまで以上に重要になります。 なぜなら、AIは一度操作権限を持つと、人が想定していなかった手順や組み合わせで処理を進めてしまう可能性があるからです。
例えば、「従業員情報を参照する権限」と「アカウントを発行する権限」と「支払い情報を更新する権限」を、一つのエージェントに一括で持たせるのは危険です。どこまで見てよいのか、どこから先は承認が必要かを区切り、途中で止められるようにしておくことが大切です。
また、AI操作は読み取り系(検索、参照、要約など)と書き込み系(作成・更新・削除など)に分類し、まずは読み取り系からAIエージェント導入を段階的に広げていくことをおすすめします。
AIエージェント活用の重大な争点が「どこで人が関与するか」です。
一般的には次のような操作は承認を必須とするケースが多いでしょう。
例えば、AIが「申請内容を確認し、必要な情報を整理する」ところまでは自動で行えても、「管理者権限を付与する」「社外にファイルを共有する」「支払処理を確定する」といった判断は、人が承認してから進める形にしておくほうが安全です。一方、申請内容の受付、情報の突合、定型チェック、履歴記録、関係者への通知などの定型業務は、多くがAIに任せられる領域となるでしょう。
AIエージェントが複数SaaSを横断する場合、「どのデータをAIが扱えるか」を統一しておく必要があります。
例えば、あるSaaSでは個人情報の閲覧が厳しく制限されているのに、別のSaaSでは同じ情報が緩く扱われているとします。すると、AIエージェントがその差をまたいで情報を取得・要約・転記してしまい、意図しない情報漏えいや統制崩れが起こりやすくなります。
こうした情報を安全に扱うために、まず必要なのが機密区分ルールの統一です。例えば「公開可」「社内限定」「部門限定」「機密」など、データの重要度を共通の基準で分類し、どの区分の情報までAIエージェントが扱ってよいのかを明確にします。
その上で、DLP(Data Loss Prevention)ポリシーを設定しましょう。これは、マイナンバーや顧客情報を含む文書はAIへの入力をブロックする、社外共有を自動で止めるなど、機密情報や個人情報が不用意に外部へ送信されたり、許可のない場所へコピーされたりするのを防ぐ仕組みを指します。
AIエージェントが業務を実行する環境では、チャットログの管理だけでは監査になりません。例えば、次の記録が残っていることがAI時代のガバナンスでは重要です。
AIとのやり取りを残すだけでは、実際にどのSaaSで何が実行されたのか、どのデータが動いたのかまで十分には分かりません。そのため、チャットやプロンプトの記録だけでなく、API実行ログ、SaaS側の監査ログ、承認履歴、チケット履歴などを連携して見られるようにしておく必要があります。
AIエージェントの導入は、一気に全社展開するのではなく段階的に進めるのが基本です。なぜなら、実際の現場では、想定どおりに処理できるケースばかりではなく、判断材料が足りない申請、ルールに当てはまらない依頼、複数部門にまたがる例外処理などが必ず発生するからです。
まず必要になるのが、例外処理のルール化です。例えば次のような場合は、自動処理を止めて人に引き継ぐ、とあらかじめ決めておきます。
このとき重要なのは、単に「エラーにする」のではなく、チケット化して担当者に引き継げるようにすることです。AIが処理途中で止まった場合でも、申請内容、止まった理由、必要な確認事項が整理された状態で人に渡れば、現場の負担は大きく減ります。
これにより、AIは最後まで自動化できない場面でも、人が判断しやすいところまで仕事を前に進める役割を持てるのです。
AIエージェントの普及によって変わるSaaSの役割と、情シスのすべきことについて解説しました。AI時代にSaaSはよりツールの垣根を超えて統合されるコンポーネントとしての性格を強めます。だからこそ、情シスは個別のアプリではなく全体の設計に目を向けることが求められるのです。
これまでも必要とされてきた統合的な設計の視点をさらに一段階引き上げる手段として、AIエージェント×SaaSを捉え、一層企業に求められる人材を目指していきましょう。