INSIGHT
部門ごとに増えたAI——まとめるもの、別に残すもの、終えるもの
道具が似ていること以外に、何を基準にまとめるか。
営業には提案資料を探すAI、総務には規程を案内するAI、開発には設計文書を探すAIがある。画面はどれも質問欄と回答欄で、契約費も三つかかっている。「一つにまとめればよい」と見えますが、検索する資料、閲覧できる人、誤回答したときの影響が違えば、統合によって守るべき境界を壊すことがあります。
反対に、同じ公開資料を三部門が別々に登録し、同じ問い合わせへ同じ回答を返し、同じ更新を三回しているなら、別々に維持する理由は弱くなります。統合、分離、終了は、作った部門の評価でも、画面の似方でもなく、業務条件で選びます。
AIの数を減らす会議ではなく、どの業務条件を共通にし、どの境界を残すかを決める会議にします。
最初に比べるのは、機能名より「誰の何の仕事か」
一覧には製品名や作成部署だけでなく、実際の一週間または一か月を基に、次の欄を並べます。
- 利用者と、完了したい仕事
- 参照資料と、その資料を更新する人
- 入力する情報と、回答が届く範囲
- 利用・管理・設定変更の権限
- 連携先と、止まったときの代替手順
- 問い合わせ、誤回答、障害を引き受ける人
- 利用回数だけでなく、重要な少数利用の有無
同じ「社内検索」でも、営業用は全社員に公開された商品資料を探し、総務用は個別の人事情報を扱うかもしれません。逆に、名称が違う二つのAIでも、利用者、情報、更新者、目的が同じなら重複候補です。まず確認済み、推測、未確認を分け、部門の自己申告だけで実態を確定しません。
一つにするのは、画面とは限らない
統合には複数の層があります。入口の画面だけを共通にし、検索対象と権限は部門別に保つこともできます。アカウント管理や監視、問い合わせ窓口だけを共通化し、参照資料と回答手順は分ける選択もあります。反対に、一つの実行環境へ集めても、資料の更新担当や例外判断が部門ごとに残れば、運用は一つになりません。
共通にする候補は、認証、利用申請、監視、費用集計、共通の公開資料、重複する接続部品です。分けて残す候補は、機微な資料、異なる承認手順、異なる停止基準、部門固有の正本、障害影響が大きく異なる業務です。
共通化すると、一つの変更や障害が複数部門へ同時に届くようにもなります。共通の検索設定を更新するとき、営業の質問は改善しても総務の質問が悪化するかもしれません。影響する部門の代表例で確認し、一部の不具合を理由に全社を止める必要があるか、部門単位で戻せるかまで決めます。
AWSのManaging AI agent sprawl across business units は、2026年7月17日付のAWS執筆記事で、部門をまたぐAIの一覧、所有者、重複の発見、共同利用、廃止を含む管理案を示しています。独立した効果検証ではなく、すべてを統合すべきだと証明する資料でもありません。自社で何を共通化するかは、情報と責任の境界から決めます。
共通の入口を持つことと、すべての資料・権限・障害影響を一つにすることは別です。
統合・分離・終了を三つの条件で選ぶ
判断は、統合か現状維持かの二択にしません。各AIを次の条件へ当てます。
統合する候補は、利用者、仕事、参照情報、更新責任、必要な稼働条件がほぼ同じで、共通化しても権限や確認手順を保てるものです。同じ商品資料を二つの営業AIへ重複登録しているなら、資料や検索機能を共通にできる可能性があります。
別に残す候補は、情報の機密性、利用権限、回答の承認、障害時の影響が明確に異なるものです。人事情報を扱う総務用と、公開情報を扱う営業用は、画面が似ていても同じ検索範囲にする理由はありません。ただし、監視や利用申請など共通部品を使える場合はあります。
終了する候補は、使われていないだけでなく、重要業務が依存しておらず、代替手段が確認でき、記録・接続・利用者を安全に移せるものです。月に一度しか使わなくても決算作業に不可欠なら、利用回数だけでは終了できません。誰も所有しておらず、資料更新も止まり、別の窓口へ移せるなら終了理由が明確になります。
統合と終了では、利用者の引越しまで設計する
統合を決めても、旧AIの利用者を新しい入口へ移すだけでは足りません。資料ごとの移行責任者、権限の対応、新旧回答の差、連携先、未完了の問い合わせ、旧リンク、利用者への案内、切戻しを決めます。通常質問だけでなく、権限が必要な質問、回答できない質問、緊急時の質問で試します。
終了では、入力履歴や評価記録を保存するか削除するか、接続キーを誰が無効にするか、契約をいつ止めるか、過去回答へのリンクをどう扱うかを決めます。「使わないでください」という周知だけでは、古いURLや連携処理が残ります。
AWSのAdopting a layered approach for generative AI development は、AWS上の生成AI基盤を層に分け、共通機能を再利用する構成案を説明しています。特定のクラウド構成に関する指針であり、自社での統合効果や、一つの構成が常に優れることを示すものではありません。ここでは「全部を一体化せず、共通部品を選べる」という整理の参考に限ります。
終了とは画面を閉じることではなく、利用者、記録、権限、接続、問い合わせ先を次の状態へ移すことです。
会議で合意するのは、結論と次の見直し時点です
各AIについて一枚の判断カードを作ります。記載するのは、統合・分離・終了の結論、守る業務条件、決定理由、所有者、移行担当、期限、完了条件、次の見直し日です。別に残す場合も「当面維持」で終えず、何が変われば統合を再検討するかを書きます。統合する場合は、共通にする層と分ける層を明記します。
上司や関係者へは、費用の合計だけでなく、統合で変わる権限、停止時の影響、移行に必要な作業を示します。その場で合意するのは、数を減らす目標ではありません。どの境界を守り、誰が新しい状態を維持し、何をもって移行完了とするかです。
AIの数を減らすことより、統合・分離・終了後も維持できる体制を選ぶ
部門ごとに増えたAIには、試行錯誤の結果が含まれています。作成部門を責めても、重複や責任の空白は解消しません。用途と情報、権限、所有者、障害影響を同じ欄で比べれば、共通化できる部分と、分けて守る部分が見えます。
統合、分離、終了のどれを選んでも、利用者と記録を次の状態へ移し、所有者と見直し時点を残します。そうすれば、単なる棚卸しを、会社が維持できるAIの組合せを選ぶ判断へ変えられます。