「開く」話と「締める」話は、別々に語られている
ここ最近、中小企業のIT戦略をめぐる話題が、大きく二つの方向に分かれて流れています。
ひとつは、AIエージェントに向けて自社を開いていく話です。AIが商品を比較し、やがては人に代わって発注まで実行する。そうなれば「消費者にどう評価されるか」ではなく「AIエージェントにどう評価されるか」が起点になります。商品情報を機械が読める形に整え、外部と接続していく必要が出てきます。
もうひとつは、クラウド環境をどう締めるかという話です。ランサムウェア被害の報道は途切れることがなく、その原因を辿ると、たいてい技術の最先端ではなく、ごく地味な運用の穴に行き着きます。
この二つ、経営会議では別々の議題として扱われがちです。前者はマーケティングや事業部門の話、後者は情報システム部門の話、というように。
しかし私は、これはひとつの設計課題だと考えています。外へ開くという行為は、そのまま接続点を増やす行為だからです。開く担当と締める担当が分かれていると、開いた穴を誰も管理しないまま時間が過ぎていきます。
侵害は、悪意ではなく「業務都合」から始まる
まず、締める側の話から整理します。
2025年10月に発生した大手通販企業のランサムウェア被害では、出荷再開までに約1.5カ月を要し、システム障害対応費用として52億円を超える特別損失が計上されました。原因のひとつとされたのが、委託先向け管理者アカウントへの多要素認証（MFA）未適用です。
ここで大切なのは、「MFAを知らなかったわけではない」という点です。セキュリティのセオリー自体は、多くの企業ですでに理解されています。それでも防御が崩れるのは、知識が足りないからではありません。
セキュリティ専門家の川口洋氏は、クラウド事故はビジネス上の制約から作られた「例外」から起きる、と指摘しています。この見方は、現場を見てきた実感とよく一致します。
「例外」が生まれる典型的な場面
- 急ぎの案件で、暫定的にアカウントを作った
- システム移行の期間中だけ、一時的な運用を認めた
- 工場でスマートフォンを持ち込めず、MFAが物理的に使えない
- 業務部門から強い要望があり、設定変更を保留した
どれも、悪意はありません。むしろ、仕事を止めないための誠実な判断です。
問題は、その例外がいつ解除されたのか、誰も覚えていないことにあります。作った本人が異動し、退職し、記録も残っていない。攻撃者が狙うのは、まさにそこです。
いま棚卸ししたい5つの領域
- ID・権限の例外 ── MFA未適用のアカウント、過剰な権限、委託先用ID、緊急用ID
- アクセスキーとトークン ── APIキー、CI/CDのシークレット、個人アクセストークン
- OAuth／SaaS連携 ── 生成AIツールなどに与えた同意済み権限
- ログの監視体制 ── ログイン失敗、権限変更、設定変更の検知
- 拡張機能 ── Webブラウザ、IDEにインストールされたアドオン
一度に全部は無理です。1つからで構いません。着手すること自体に意味があります。
AIエージェント時代は、「開く」圧力が確実に強まる
次に、開く側の話です。
エージェンティックコマース（AIエージェントによる購買行動の自動化）をめぐって、国内でも大手企業の布石が相次いでいます。金融機関がAIエージェント向けのAPI基盤を構築し、ECプラットフォームがAIエージェント機能を提供し、広告会社が事業者支援ソリューションを立ち上げる。市場規模は2030年にグローバルで3兆〜5兆ドルという予測もあります。
発展段階は、おおむね次の三段階で整理されます。
| 段階 | 内容 | 現状 |
|---|---|---|
| ① | AIが情報収集・比較を支援し、購入判断は人間 | いまここ |
| ② | 権限を委譲されたAIエージェントが発注まで実行 | 実装が始まりつつある |
| ③ | 売り手も買い手もAIエージェント（AI対AI） | 構想段階 |
まだ先の話かもしれません。しかし、AIエージェントによって直接取引が増える可能性は確実にあります。どうやったらAIエージェントに選んでもらえるのかを、いまから考えておく必要があると考えています。
順序としては、BtoCが先
対応の順番については、はっきりした見方を持っています。
BtoBは、価格交渉、与信、請求処理、検収といったプロセスが絡み、複雑性が高い領域です。AIエージェントによる自動化が実務に乗るまでには、まだ時間がかかるでしょう。
まず意識すべきはBtoCです。具体的には、ECサイト、小売店、飲食店。このあたりから対応が必要になってきます。
そして、これは中小企業にとって不利な話ではない
むしろ逆かもしれません。
人間の消費者は、広告接触量やブランド認知に強く影響されます。だからこそ、マーケティング予算の大きさが売上を左右してきました。
一方でAIエージェントは、客観的な指標で商品を評価します。製造元が無名の中小企業であっても、優れた商品であれば選択対象になり得る。そういう構造の変化です。
広告予算を積めない企業ほど、商品情報の構造化と正確性で勝負できる余地が生まれます。SEO対策の延長として捉えるだけでは足りず、商品カタログの整備そのものが競争力になっていく、ということです。
これは大規模投資を必要としません。今日から着手できる領域です。
開く前に、締める。順序を間違えない
ここで、二つの話がつながります。
AIエージェントに向けて自社を開くということは、API連携、商品データの外部公開、外部サービスとの接続を増やすことに他なりません。つまり、先ほど挙げた「棚卸ししたい5つの領域」のうち、少なくとも2番と3番が確実に増えるわけです。
急いで開けば、そこにまた「例外」が生まれます。連携テスト用の一時的なAPIキー、期限を切らずに与えたOAuth権限、担当者しか知らない設定。数年後、それが侵害の入口になる。
だからこそ、順序が大事だと考えています。
効率とセキュリティは、原則としてトレードオフ
もうひとつ、押さえておきたい原則があります。
クラウドのセキュリティ設定は、本当に複雑になりました。人手だけで全体を追い切るのは、もはや現実的ではありません。AIの力も借りた対策が必要な段階に入っています。
同時に注意したいのは、統一された管理は効率的である一方、突破されたときの被害範囲を広げるという点です。効率とセキュリティは、一般的にトレードオフの関係にあります。
AIを使った攻撃が増えている昨今、多少効率を落としてでもセキュリティレベルを上げる。その判断ができるかどうかが、経営の分かれ目になると考えています。
例外を認めるなら、期限と責任者をセットで
現実には、例外をゼロにはできません。仕事を止めるわけにはいかないからです。
そこで、認めること自体は否定せず、認め方を設計するという発想に切り替えます。
- 例外を認める際は、必ず適用期限を決める
- 必ず責任者を明記する
- 期限が来たら、自動的に棚卸しの対象に載せる
無期限の例外は、事故の予約券のようなものです。
生成AIツールの利用申請でも同じです。「どんな機能が使えるか」だけでなく、「どのデータへのアクセスを許可したのか」まで確認する。これを申請フォーマットに組み込んでおくだけで、後々の棚卸しがずいぶん楽になります。
まとめ ── 攻めと守りを、同じ議題に載せる
整理します。
攻め（開く）
- AIエージェントに選ばれるため、商品・サービス情報を機械可読で正確に整備する
- 順序はBtoCから。ECサイト、小売店、飲食店が起点
- 広告予算ではなく情報の質で戦えるため、中小企業にとってはチャンス
守り（締める）
- 侵害は「業務都合で生まれた例外」から始まる
- ID・権限、アクセスキー、OAuth連携、ログ監視、拡張機能の5領域を棚卸しする
- 効率とセキュリティはトレードオフ。今は効率を多少犠牲にしてでも守りを上げる局面
そして、両者をつなぐ設計
- 開けば接続点が増える。増えた接続点は、新たな例外の温床になる
- 例外を認めるなら「期限」と「責任者」をセットで定める
AIエージェント時代への準備は、事業部門だけの仕事ではありません。逆に、セキュリティの棚卸しも情報システム部門だけの仕事ではありません。
開く計画と締める計画を、同じ会議体で並べて議論する。 中小企業の規模であれば、それは十分に可能なはずです。むしろ、意思決定の速さという中小企業の強みが最も効く領域だと思います。
まずは一つ。「作った本人しか覚えていないアカウント」が残っていないか、確認するところから始めてみてはいかがでしょうか。
出典
- ITmedia TechTargetジャパン「クラウド事故は『例外』から起きる」（2026年8月5日） https://techtarget.itmedia.co.jp/tt/news/2608/05/news01.html
- 日経クロステック「迫る『AIがAIからモノを買う』時代 MUFGやLINEヤフー、博報堂が布石」（2026年8月5日） https://xtech.nikkei.com/atcl/nxt/column/18/03699/080300003/
コメント