例として、営業担当者が生成AIを使い、見積の例外承認を確認する社内アプリを作った状況を考えます。最初は手元のサンプル表計算を読むだけだったアプリが、部内で共有され、顧客管理システムを参照し、承認結果を保存するようになりました。IT部門はこのアプリを、どの時点から、どの深さで管理するべきでしょうか。
IT部門の初動は、実物を見つけて登録し、業務への影響とデータ、接続を確かめ、運用レーンへ分類することです。作成者の異動やアプリの廃止まで状態を更新できれば、現場の速さを保ちながら責任の空白を減らせます。
業務部門は、業務目的、利用者、例外時の代替手順を記録します。IT部門は、データ接続、権限、構成、運用条件を精査します。正式運用へ移す場合は、業務責任者、保守責任者、公開を承認する人を決めます。
- 実際に使われているアプリを見つけ、一件ずつ登録する
- 業務影響と技術的な露出を見て三つの運用レーンを決め、停止・隔離条件をすべてのレーンに照らす
- 変更、障害、所有者の異動、廃止まで状態を更新する
ここでは、生成AIを使って作られた社内向け業務アプリを「AI製アプリ」と呼びます。実行時のAI利用の有無は登録票へ分けて記録します。
管理の流れ
シャドーAI（Shadow AI）とAI製アプリを分けて捉える
生成AIに関する社内管理では、利用するサービス、作られたソフトウェア、実行時にAIを使うシステムが一緒に語られがちです。三者は重なることがあります。それぞれで残る資産、発見経路、運用責任が変わるため、シャドーAIとAI製アプリを分けたうえで、実行時にもAIを使うものは第三の管理対象にします。
| 対象 | 何を指すか | IT部門が把握するもの |
|---|---|---|
| シャドーAI（Shadow AI） | 承認されていないAIサービスや機能の利用 | 利用サービス、投入情報、契約、アカウント、外部送信 |
| AI製アプリ | 生成AIを使って作られ、業務で利用されるソフトウェア | 所有者、ソース、データ、接続、変更、障害、廃止 |
| AIを組み込んだ業務システム | 実行時にもモデルやAI機能を利用するシステム | AI製アプリの管理項目に加え、モデル、入力と出力、出力品質の評価、継続監視 |
AI製アプリが、未承認のAIサービスで作られ、実行時にもAIを呼び出すことはあります。その場合は三つの観点を重ねます。一方、生成AIでコードを書いた後は通常のアプリとして動くものもあります。後者をAIサービス利用の申告だけで扱うと、ソースやデータ接続、保守責任が抜けます。ここで防ぎたい、いわゆる「野良アプリ」は、作成手段ではなく、所有者、接続、変更、復旧を追えない状態です。
最初にアプリごとの登録票を作る
申告窓口だけでは、すでに使われているアプリを把握しきれません。発見経路を複数用意します。
- 業務部門への定期的な聞き取りと申告窓口
- SSO、SaaS、調達の台帳
- ソースリポジトリと社内外の公開先
- 業務データ、API、認証情報への接続
複数経路で同じアプリが見つかるため、名称、URL、所有者、利用部門を照合して同じ実物をまとめます。
MicrosoftのPower Platform inventoryは、組織内のアプリ、エージェント、フローを一覧化し、所有者や退職予定者が持つ資産を把握する機能を説明しています。接続先の表示は、同資料でプレビュー機能として案内されています。Power Platformのセキュリティ推奨事項では、管理対象の環境について、所有者不在のアプリを事業継続リスクとして扱い、新しい所有者を割り当てる手順を示しています。これはPower Platformの運用例ですが、実物、接続、所有者を一緒に記録する考え方は、他の社内アプリを整理するときにも参考になります。[1][2]
見積承認アプリの登録票は、次のようになります。未確認項目は空欄にせず「未確認」と記録し、何が分かっていないかを残します。
| 項目群 | 記録する内容 | 見積承認アプリの記入例 |
|---|---|---|
| 目的、所有者 | 業務目的、利用部門、業務責任者、作成担当、保守担当 | 例外見積の確認。営業企画が業務責任者。保守担当は未確認 |
| 利用状況 | 利用者、停止時の影響、代替手段 | 営業部内で利用。停止時は表計算とメール承認へ戻す |
| データ、接続 | 扱うデータ、読み取り、更新、API、外部公開、認証情報 | 商品単価と顧客区分を参照。顧客管理システムは読み取り。承認結果の保存先は未確認 |
| 実体 | 実行場所、ソース、設定、依存ライブラリ、仕様、テスト | 社内クラウドで実行。個人リポジトリにソース。テスト手順と実施記録は未確認 |
| 運用 | 変更方法、監視、障害連絡、復旧、見直し条件、廃止条件 | 作成者が随時変更。障害連絡先と廃止条件は未確認 |
三つの運用レーンと停止・隔離条件を分ける
登録後は、作成ツールの名前に加えて、業務影響と技術的な露出を評価します。業務影響では、個人の補助か、部門の判断か、顧客、会計、全社業務へ影響するかを見ます。技術的な露出では、機密データ、外部公開、業務システムの更新、個人の認証情報、復旧の難しさを見ます。
組織に既存のリスク区分や市民開発ルールがある場合は、次の三つの運用レーンと、全レーンに共通する停止・隔離条件を対応付けます。
| 運用レーン | 対象となる状態 | 次に行う管理 |
|---|---|---|
| 1 個人の試行 | 本人だけが試し、実データ、外部公開、業務システム更新を伴わない | 許可された環境とデータで期限を決めて試す |
| 2 登録された部門ツール | 共有、反復利用、業務判断への利用が始まる | 業務責任者、変更担当、代替手段、見直し日を決めて登録票へ記録する |
| 3 正式な業務システム | 顧客、会計、全社業務への影響、データ更新、外部公開、停止時の大きな影響がある | 本番権限、変更管理、テスト、監視、障害対応、復旧を管理する |
所有者が分からない、秘密情報の外部流出が確認された、承認のない外部公開またはデータ更新が見つかった場合は、IT部門が業務責任者へ通知します。代替手順を確保したうえで、現在の運用レーンにかかわらずアプリを一時停止し、必要に応じて接続や公開を隔離します。是正後に運用レーンを再判定します。
OWASP Citizen Development Top 10は、AI支援やローコード、ノーコードによる開発で、生成物への盲信と設定不備をリスクとして挙げています。この指摘を踏まえ、作成手段に加えて、実際の設定、権限、接続、テストを確かめます。[3]
見積承認アプリのレーンと停止条件を判断する
同じアプリでも、使われ方が変われば必要な管理は変わります。移動の契機を先に決めると、部門共有が始まった後も個人試行の扱いを続ける状態を防げます。
- 01本人がサンプル表計算だけを読む
個人の試行として扱う。試行期限と、実データへ切り替える前の相談先を決める。 - 02部内で繰り返し使う
登録された部門ツールへ移す。業務責任者、変更担当、停止時の代替手段を記録する。 - 03顧客管理システムを読み承認結果を保存する
正式な業務システムへ移す。接続権限、データ更新、テスト、監視、復旧を管理する。 - 04個人の認証情報で外部公開され所有者も不明になる
代替手順を確保して停止・隔離する。所有者と認証を是正した後に運用レーンを決め直す。
正式運用へ移す前にそろえる事項
正式運用へ移す前に、登録票にある運用項目を掘り下げます。必要な情報と、未確認だった場合の対応を並べ、次の担当者が判断を引き継げる形にします。
| 観点 | そろえる情報 | 不足時の対応 |
|---|---|---|
| 責任 | 業務責任者、保守責任者、公開を承認する人 | 責任者と決定期限を登録票へ戻す |
| 業務 | 対象業務、例外、手作業へ戻す手順、停止時の影響 | 代替できない範囲を公開判断へ渡す |
| データ、権限 | データ分類、認証、最小権限、外部接続、秘密情報 | 接続を止め、必要な権限を再設計する |
| 構成 | ソース、設定、依存先、実行環境、保管場所 | 引き継げない構成を正式運用へ移さない |
| 変更 | 変更要求、レビュー、テスト、公開と切り戻しの手順 | 合格条件と公開を止める条件を決める |
| 運用 | 監視、障害連絡、ログ、復旧、連絡先 | 検知できない障害と復旧責任を明記する |
| 見直し、廃止 | 所有者の異動、定期見直し、廃止、データ処理 | 見直し日と廃止を判断する人を決める |
NIST AI RMF Coreは、実行時にAIを使うシステムについて、棚卸し、廃止、役割と責任をガバナンス項目に置いています。この表では「責任」と「見直し、廃止」の行に対応します。[4]
生成後に通常のソフトウェアとして動くアプリには、NIST SSDFの安全な開発慣行を既存の開発、運用ルールへ組み込みます。この表では「構成」「変更」「運用」の行に対応します。[5]
作成者の異動と廃止までを管理する
管理を本番公開から始めると、部門内で使われ始めた時期と責任の移行が記録に残りません。発見した時点から状態を持ち、次の六段階で更新します。
- 01発見
申告、台帳、リポジトリ、データ、API接続から実物を特定する。 - 02登録
目的、所有者、利用状況、接続、実体、運用を一件の登録票へ記録する。 - 03分類
業務影響と技術的な露出を評価し、次の運用レーンを決める。 - 04是正、正式運用への移行
権限、構成、テスト、監視、復旧を整え、責任を移す。 - 05運用、見直し
変更、障害、APIや依存先の更新、業務ルール変更を登録票へ反映する。 - 06廃止
利用を止め、接続と認証情報を無効化する。保存条件に従って記録を残し、不要なデータを削除する。
作成者が異動するときは、ファイルを渡すだけでは足りません。業務責任者と保守担当の役割を引き継ぎ、アカウント、秘密情報、ソース、設定、復旧手順の受け渡し先を記録します。引き継ぎ先が決まらない場合は、利用継続の判断を業務責任者へ戻します。
Formula AIで仕様と実装と検証をつなぐ
登録票は、AI製アプリを見つけて責任を割り当てる入口です。正式な業務システムとして運用を続ける段階では、業務ルールの変更がどの画面、API、データ、権限、テストへ影響するかも追う必要があります。
見積承認アプリなら、例外条件をルール、顧客管理システムの参照をAPI、承認結果の保存をデータ定義として整理し、画面、権限、テストとIDで関連付けます。
Formula AIの公開ページでは、業務資料と現行システム資産の読み解き結果を起点に、仕様、実装、検証を対応付けて更新する構造を説明し、画面、API、DB、権限、テスト、各種設計書、検証証跡を成果物として掲載しています。正式な業務システムへ移した後に、仕様、実装、検証の関係を変更後も保つ場面で使えます。[6][7]
この記事では、Formula AIを登録後の仕様、実装、検証を管理する場面に限定して扱います。AI製アプリの発見と全社台帳の管理は、ここまで述べた登録工程で行います。
Formula AIの製品構造と生成される成果物で、現在公開している範囲を参照できます。AIを使う開発工程の権限、独立検証、変更記録を調べる場合は、AI駆動開発の統制チェックリストを使います。
まず一部門の実物を一件ずつ登録する
一部門で実際に使われているアプリを集め、一件ずつ登録票へ書きます。最も業務影響が大きい一件を三つの運用レーンへ分類し、停止・隔離条件をすべてのレーンに照らします。不足項目の担当と次の更新日を決めたら、対象部門と発見経路を広げます。
一件を最後までたどると、申告だけでは見えなかった所有者、接続、変更、復旧の空欄が分かります。その空欄を次の登録票と部門への聞き方へ反映する方が、最初から完璧な全社台帳を作るより現場に合った管理へ近づきます。
よくある質問
- すべてのAI製アプリをIT部門が審査すべきですか
- 見つけたアプリは審査前に登録し、業務影響と技術的な露出に応じて管理を変えます。本人だけの試行と、顧客データを更新する部門アプリを同じ手続きにすると、軽い試行には重すぎ、本番影響のあるアプリには管理が浅くなります。
- Power Appsやkintoneや表計算マクロも対象ですか
- 生成AIで作られたかにかかわらず、同じ管理上の問いを使えます。ここでいうAI製アプリには生成AIを使って作ったものを含めますが、登録票、三つの運用レーン、停止条件はローコード、ノーコード、マクロなどの市民開発にも応用できます。
- 発見のための聞き取りが業務部門への監視になりませんか
- 目的は個人の操作を監視することではなく、業務で使われるアプリの所有者、接続先、停止時の影響を把握することです。対象範囲と利用目的を先に示し、登録に必要な情報だけを集めます。
- どの時点で正式な業務システムへ移しますか
- 顧客、会計、全社業務へ影響する、業務システムのデータを更新する、外部公開する、止まったときの影響が大きい、といった変化を見直しの契機にします。人数だけで一律に決めず、業務影響と接続範囲を見て判断します。