AIは、明確な購買、導入、展開のプロセスを経て導入される単体の製品としてのみ提供されるものではなくなった。

　要約、検索、レコメンデーション、自動化などの機能に加え、AIアシスタント、Copilot、AIエージェントが、企業がすでに導入済みのアプリケーションに組み込まれて提供されるケースが増えている。

　1つのSaaSアプリケーションの中に、異なるデータアクセス権や動作パターンを持つ複数のAI機能があることもある。そのため、従来のアプリケーションインベントリ（一覧）から把握できる情報には限界が生じる。

　企業がある人事システムを利用していると知っていても、内部の採用アシスタント機能が有効化されているかどうかまでは分からない。コラボレーションツールが社内で承認されていると知っていても、会議の文字起こしやAI要約、アクションアイテムの自動生成機能が有効になっているかは判断できない。導入しているCRMが分かっていても、自律型のカスタマーサービス機能が実際に稼働しているかどうかは把握できない。

　ソフトウェア自体の存在は見えていても、個々のAI機能は見落とされがちなのだ。

SaaSのアップデートが課題を恒常化させる

　SaaSの継続的なアップデートによって、アプリケーション管理はすでに数年に一度のアップグレードではなく日常的な継続プロセスへと変化している。ベンダーは機能を随時リリースし、企業側はそれを受け入れる必要がある。

　また、日常的なSaaSのアップデートによって、ワークフロー、レポート、権限設定、ユーザー体験が変更される場合がある。　ベンダー側が新機能を配信しても、そのアップデートが自社にとって何を意味するかを判断するのは企業側の責務だ。どの変更が自社業務に影響するか、テストが必要な機能はどれか、誰が評価を担当すべきか、そしてその機能を有効化するか、適用を延期するか、あるいは制限するかを判断する作業は企業側にある。

　AIの登場は、この慣れ親しんだ管理プロセスを複雑化させる。日常的なアップデートによって、新たなデータアクセス権、自動処理機能、追加コスト、ガバナンス要件を伴う機能が突如追加される可能性があるからだ。

　AI製品を個別に購入する場合であれば、明確な審査のタイミングがある。しかし、すでに承認済みのアプリケーションに追加される新しいAI機能は、リリースノートの項目の1つとして見過ごされてしまう恐れがある。

　管理者は影響の大きいアップデートについて、本番環境で広く利用される前にレビューや検証を実施することが望ましい。だが、変化の速い最新のSaaS環境で、全てのアップデートを個別のプロジェクトとして扱うのは現実的ではない。そのため、どの変更点に注視が必要で、どの変更であれば日常の運用で済ませてよいかを正確に見極めることが重要になる。

　単なるボタンの追加であれば気にする必要はない。しかし、新しい機能の追加には細心の注意が必要だ。

アプリケーションインベントリだけでは不十分

　契約、管理責任、セキュリティ、システム連携、ライフサイクル管理から見て、従来のアプリケーションインベントリは引き続き必要だ。アプリケーションポートフォリオ管理（APM）を活用すれば、企業はアプリケーション単位でソフトウェアを棚卸し、評価し、ガバナンスを効かせることができる。

　しかし、AI機能の普及により、機能単位という二つ目の管理レイヤーが必要になった。

　AI機能インベントリを構築すれば、各機能の利用対象者、アクセス可能なデータ、許可された実行アクションなどを個別に追跡できる。さらに、稼働基盤やベンダー名、影響を受けるワークフロー、管理責任者、人間のレビュー要件、コスト、利用状況、リスク、期待される成果なども記録可能だ。

　個別の機能レベルで、企業は以下のような自問で可視性を確保する必要がある。

　その機能は有効化されているか。誰が利用できるのか。どのデータにアクセスできるのか。コンテンツの生成や提案を行うだけなのか、自律的なアクションを実行できるのか。他システムのレコード更新や処理のトリガを引く権限はあるか。結果で事前に人間の承認が必要か。料金体系はどうなっているか。最後にレビューを実施したのはいつか。

　これらの詳細情報は、アプリケーション単位の台帳から常に推測できるとは限らない。つまり企業は、アプリケーションの台帳を見れば必要な情報が全て分かると過信するのではなく、重要なAI機能を個別に追跡管理する必要性が高まっている。

AI機能インベントリに含めるべき項目

　アプリケーションインベントリが示すのは、自社が保有しているソフトウェアの一覧だ。AI機能インベントリは、そこからもう一段深く踏み込む。影響力の大きいAI機能については以下の項目を追跡することが推奨される。

• 対象アプリケーションおよびベンダー
• AIの機能名または処理内容
• ステータス（有効、無効、パイロット運用、利用制限など）
• アクセス権を持つユーザーおよびグループ
• 読み取りまたは生成が可能なデータ
• 更新または呼び出しが可能なシステム
• 実行可能な自律的アクション
• 人間によるレビューや承認の要件
• 技術面および業務面の担当責任者
• 料金体系または従量課金モデル
• 現在の利用実績
• リスク要件またはガバナンス要件
• 想定されるビジネス上の目的や成果
• 最終レビュー日

　全ての機能で同じ粒度の台帳を作成する必要はない。重要なのは、通常の付帯機能と、アクセス権や自律性、コスト、ビジネスリスクに実質的な変化をもたらす機能とを明確に見分けられるだけの可視性を確保することだ。

同一アプリケーション内でも機能によって大きく異なるリスク

　アプリケーション単位の視点だけでは、機能ごとのリスクの違いを見落とす危険がある。同じベンダーから提供され、同一の製品に含まれ、単一の契約下にある機能でも、二つのAI機能の挙動が全く異なる場合がある。

　そのため、どのAI機能を有効化すべきかの判断は、ベンダーが機能を提供しているかどうかではなく、運用上の影響やリスクの度合いに応じて決定する必要がある。

　アプリケーション単位の管理で隠れてしまう要素はリスクだけではない。個々のAI機能によって、発生するコストや料金モデルが異なる場合もある。

　ある機能は既存のサブスクリプション料金に含まれているかもしれないが、別の機能はクレジット、トークン、処理件数などの利用量に応じた従量課金制を採用しているかもしれない。すでに利用しているソフトウェア群の全体にこうした追加の消費モデルが広がると、AI機能が新たなソフトウェアコスト管理の課題を引き起こす原因になる。

　ここでもやはり、アプリケーション名を知っているだけでは不十分だ。どの機能が有効化されており、何ができるのか、そしてどの程度のコストがかかるのかを企業は正確に把握しなければならない。

アプリケーションの枠を超えるAI機能

　AI機能がアプリケーションの外部にまで及ぶ場合、個別の機能管理は一段と重要になる。

　AI機能は、他システムから取得するデータ、ID、アクセス権限、システム連携、ビジネスコンテキストに依存する傾向を強めている。つまり、機能が動作しているアプリケーションだけが管理対象の全てとは限らない。

　CRMの機能として動作しているエージェントが、実際にはERPの情報を利用している場合がある。従業員向けアシスタントが生産性スイート上で動作しながら、人事データを参照しているケースもある。コラボレーションツールのAI機能が、会議やチャットのログをデータ化し、後から検索や分析ツール、他のAIツールで参照できるようにすることもある。

　これこそが、AIエージェントが個別のアプリケーションと一対一で対応しない理由の1つだ。1つのSaaS製品の中に異なるアクセス権を持つ複数のエージェントが存在し得る一方で、アプリケーションインベントリやガバナンスツールでは親となるアプリケーションしか認識できない場合がある。

　そのため、従来のアプリケーション責任者を置くだけでは管理として不十分になる。アプリケーション担当チームは、機能の配置場所や設定内容を把握しているかもしれない。しかしソフトウェア管理チームは、その機能がアプリケーションの枠を超えてどのデータ、システム、ワークフローに依存し、あるいは影響を与えているかまで理解する必要がある。

　こうした広い視野を持つことで、通常のAI機能と、綿密な審査が必要な機能とを正しく区別できるようになる。

　全てのAI機能に画一的なガバナンスプロセスを適用する必要はない。要否を見極め、注視すべき機能を特定できるだけの可視性があれば十分だ。

　情報の要約を行うだけの機能や、少数のユーザーを支援する限定的なAI機能であれば、従来のアプリケーション管理と大差ない運用で済む場合が多い。

　機密データへのアクセス権を拡大する機能、自律的な処理を追加する機能、従業員や顧客に影響を及ぼす機能、業務フローを改変する機能、大幅な追加コストを発生させる機能、あるいは複数の基幹システムと連携する機能については、より厳格な精査が求められる。

　具体的な判断基準は企業によって異なるが、前提として必要なのは可視性の確保だ。

　稼働していることすら把握していないAI機能を評価することはできない。課金体系が不明なままではコスト管理も不可能だ。どのチームが担当しているか分からなければ責任を割り当てることもできず、アプリケーションの内部でAIの存在が不可視化されていれば、利用制限や無効化の判断すら下せない。

ソフトウェア管理に求められるより詳細な視点

　企業向けソフトウェア管理で、アプリケーション単位の視点を完全に捨てるわけではない。今後はアプリケーションの内部にまで目を向ける必要性が高まっているということだ。

　調達、システム管理、アーキテクチャ設計、サポートの観点で、アプリケーションが重要な管理単位であることに変わりはない。しかし、AI機能によって、データアクセス権、自律性、コスト、ガバナンス、ビジネスへの影響が同一アプリケーション内でも大きく異なる機能が次々と追加されている。

　この変化に伴い、管理上の根本的な問いも変わりつつある。自社がどのアプリケーションを保有しているかを把握するだけではもはや十分とは言えない。それらのアプリケーションの内部でどのような機能が稼働し、何を実行することが許可されているのかまで把握することがこれからの企業に強く求められている。