- はじめに——「AIが止まった朝、業務は回りますか」という第12の壁
- 前提——「便利なツール」が「前提インフラ」になった瞬間、リスクの性質が変わる
- ステップ1：重要業務のAI依存度棚卸し——「どこが止まると何が止まるか」を可視化する
- ステップ2：フォールバック業務設計——「AIなし運転」の手順を作り、訓練する
- ステップ3：集中リスクの分散——障害・値上げ・仕様変更への構造的な耐性を作る
- ステップ4：デスキリング防止——「AIなしで回せる人」を組織に残す技能維持プログラム
- BCPへの組み込み——AI依存を事業継続計画の正式な一章にする
- AIレジリエンス・チェックリスト
- よくある質問（Q&A）
- まとめ——「止まらないAI」ではなく「止まっても回る組織」を作る
- 参考リンク
はじめに——「AIが止まった朝、業務は回りますか」という第12の壁
本連載ではここまで、企業AI導入で多くの組織がつまずく壁を順に越えてきました。第10回で1部門の成功を全社へ横展開し、第11回でユニットエコノミクスとFinOpsによってコストを統制する仕組みを整えました。この2つを乗り越えた組織では、AIは「一部の人が使う便利なツール」ではなく、全社の業務が前提として組み込まれたインフラになっています。
しかし、まさにその「拡大の完成」が、第12の壁を生みます。ある朝、利用しているAIベンダーで大規模障害が発生したとします。問い合わせ対応の一次回答が止まる。営業の提案書ドラフトが作れない。開発チームのコードレビューが滞る。経理の仕訳チェックが手作業に戻る——AIが止まると、全社の業務が一斉に止まる。これが依存リスクの正体です。
しかも、止まるのは障害だけではありません。突然の値上げ、APIの仕様変更、利用していたモデルの提供終了（モデル改廃）。そして最も静かに進行するのが、AIなしでは仕事ができない人材が増えていく「デスキリング」です。障害は復旧しますが、失われた技能は簡単には戻りません。
筆者はネットワークのTAC（テクニカルアシスタンスセンター）とアドバンスドサービスで、長年「止まってはいけないインフラ」の障害対応と冗長化設計に携わってきました。ネットワークの世界では、「単一障害点（SPOF）を作らない」「障害を前提に設計する」は基本中の基本です。AIが業務インフラになった今、同じ設計思想をAI依存に適用する——これが本記事の主題です。
想定読者は、AI活用が全社に浸透した（あるいはしつつある）企業の情シス・DX推進部門・リスク管理部門・経営層の方々です。
前提——「便利なツール」が「前提インフラ」になった瞬間、リスクの性質が変わる
AI導入の初期段階では、AIが止まっても「少し不便になる」だけでした。使う人が一部で、業務手順もAI以前のものが残っていたからです。しかし全社展開が完了した組織では、状況が質的に変わっています。
- 業務手順がAI前提で再設計されている：「AIが一次ドラフトを作り、人がレビューする」フローでは、AIが止まるとドラフト工程そのものが消失する。
- 処理量がAI前提でスケールしている：AIで3倍に増えた処理量を、人手だけで捌くことはもはや物理的にできない。
- AI以前の手順を知る人が減っている：異動・退職・新入社員の増加により、「手作業でのやり方」を知る人材が組織から失われていく。
つまり、依存リスクは「AIの障害率」の問題ではなく、組織側の復元力（レジリエンス）の問題です。整理すると、対処すべきリスクは4つに分かれます。
| リスク | 何が起きるか | 時間軸 | 主な対策の軸 |
|---|---|---|---|
| ベンダー障害 | API停止・性能劣化で業務が即時停止 | 突発（数時間〜数日） | フォールバック業務設計・冗長化 |
| 値上げ・契約条件変更 | 予算が突然崩れる、交渉力がなく飲むしかない | 数週間〜数ヶ月の予告 | 集中リスク分散・移行可能性の確保 |
| 仕様変更・モデル改廃 | プロンプト・ワークフローが動かなくなる、品質が変わる | 数週間〜数ヶ月の予告 | 抽象化レイヤー・回帰テスト |
| デスキリング | AIなしで業務を遂行できる人材が消える | 年単位で静かに進行 | 技能維持プログラム |
なお、本連載第6回で扱った「ベンダーロックイン」と本記事の関係を整理しておきます。第6回は「乗り換えられるか」という出口の話、今回は「止まった日に業務が回るか」という継続の話です。ロックイン対策が万全でも、障害当日に代替ベンダーへ切り替えられるわけではありません。両者は対になる別々の設計課題です。
| 観点 | 第6回（ロックイン） | 第12回（依存リスク・本記事） |
|---|---|---|
| 問い | いざとなれば乗り換えられるか | 止まった日に業務が回るか |
| 時間軸 | 数ヶ月単位の移行 | 数時間〜数日の継続 |
| 主な手段 | データ可搬性・標準化・契約設計 | フォールバック手順・縮退運転・技能維持 |
| 近い概念 | 出口戦略（Exit Strategy） | 事業継続計画（BCP） |
ステップ1：重要業務のAI依存度棚卸し——「どこが止まると何が止まるか」を可視化する
ネットワークの冗長化設計は、必ず「どのリンクが切れると、どの拠点が孤立するか」の把握から始まります。AI依存も同じで、最初にやるべきは対策ではなく棚卸しです。
依存度マップを作る
全社の業務プロセスを対象に、次の4項目を業務単位で洗い出します。第9回で作った業務×KPIの対応表、第11回で作ったコスト配賦の単位（どの部門がどのAIをどれだけ使っているか）がそのまま母集団として流用できます。
| 項目 | 問い | 例 |
|---|---|---|
| 依存度 | AIなしでその業務は成立するか | 高：AIが工程に組み込み済み／中：効率が落ちるが可能／低：補助的利用のみ |
| 停止時影響 | 止まると顧客・売上・法令順守に響くか | 顧客対応の遅延、請求処理の停止、納期遅延など |
| 許容停止時間 | 何時間（何日）までなら耐えられるか | 問い合わせ一次対応：4時間／社内資料作成：3日 |
| フォールバックの有無 | 手動手順書はあるか、実行できる人はいるか | 手順書あり・訓練済み／手順書のみ／なし |
これはBCPで使われるビジネスインパクト分析（BIA）のAI版です。システムのRTO（目標復旧時間）を決めるのと同じ発想で、業務ごとに「AIなし運転」の許容時間を決めることが、後続のすべての対策の優先順位を決めます。
「依存度が高い×フォールバックがない」業務から着手する
棚卸しの結果は、依存度と停止時影響の2軸でマッピングします。右上（依存度高×影響大）にあり、かつフォールバックが「なし」の業務が最優先の対象です。全業務に一律の対策を施す必要はありません。ここでも第11回のFinOpsと同じく、守る価値のあるものに投資を集中するのが原則です。
ステップ2：フォールバック業務設計——「AIなし運転」の手順を作り、訓練する
手動手順書は「あるだけ」では機能しない
優先業務が決まったら、AIが使えない場合の代替手順（フォールバック手順書)を整備します。ポイントは、システムの復旧手順ではなく業務の継続手順を書くことです。「AIが復旧するまで待つ」ではなく、「AIなしで、削減された品質・速度でどう回すか」を定義します。
- 縮退運転の定義：平常時の100%を人手で再現するのは不可能という前提に立ち、「何を止め、何を残すか」を決める。例：問い合わせ対応はテンプレート回答のみに縮退、提案書は既存雛形の流用に限定、社内向け文書作成は停止。
- 優先順位の事前合意：障害当日に「どの業務を優先するか」を議論している余裕はない。顧客影響・法令順守に関わる業務を最優先とする順位を、平時に経営レベルで合意しておく。
- 発動基準と解除基準：「ベンダーのステータスページで障害確認後30分で発動」のように、誰がいつフォールバックを宣言するかを決める。ネットワーク運用の切り戻し判断と同じく、基準が曖昧だと発動が遅れる。
訓練しない手順書は、ないのと同じ
これはBCP・災害復旧の世界で繰り返し実証されてきた教訓です。年1〜2回、「AI停止訓練」を実施します。半日、対象部門でAIツールの利用を止め、フォールバック手順で実際に業務を回してみる。訓練で判明するのは、手順書の不備だけではありません。「この手順を実行できる人が、もう部門に2人しかいない」というデスキリングの実態が可視化されます（ステップ4につながります）。
ステップ3：集中リスクの分散——障害・値上げ・仕様変更への構造的な耐性を作る
単一ベンダー依存は「単一障害点」である
ネットワーク設計でキャリア回線を2系統契約するのと同じ発想が、AIにも必要になります。ただし、すべてを二重化するのはコスト的に非現実的です。ステップ1の棚卸しで特定した最重要業務に限定して、次の選択肢を検討します。
- マルチベンダー構成：重要業務のワークフローを複数ベンダーのモデルで動作確認しておき、切り替え可能な状態を維持する。常時併用でなくても、「切り替え先の検証済み構成がある」だけで障害耐性と価格交渉力の両方が得られる。
- 抽象化レイヤーの導入：アプリケーションから特定ベンダーのAPIを直接呼ばず、ゲートウェイやルーティング層を挟む。仕様変更・モデル改廃の影響を1箇所に閉じ込め、切り替えを設定変更で済ませられるようにする。
- ローカル/オンプレの限定活用：最重要かつ要件が限定的な業務（定型文書の分類・要約など）は、小型のローカルモデルを最後の砦として用意する選択肢もある。フル性能の代替ではなく「縮退運転の受け皿」と位置づけるのが現実的。
値上げ・仕様変更・モデル改廃は「予告された障害」として扱う
突発障害と違い、値上げや仕様変更には通常、数週間〜数ヶ月の予告期間があります。これを「予告された障害」と捉え、平時から次を整備します。
- 変更監視の担当を決める：ベンダーの料金改定・モデル提供終了・API変更のアナウンスを追う担当と、社内への影響評価フローを決めておく。多くの組織では誰の仕事でもないため、気づいたときには猶予が残っていない。
- 回帰テストセットの整備：重要業務のプロンプトと期待出力のペアを評価セットとして保持し、モデル変更時に品質劣化を検知できるようにする。仕様変更対応の工数を大幅に削減できる。
- 契約での手当て：更新時に価格改定の上限・通知期間・旧モデルの提供継続期間を交渉する。マルチベンダーの検証済み構成（前述）が、この交渉の最大の裏付けになる。
ステップ4：デスキリング防止——「AIなしで回せる人」を組織に残す技能維持プログラム
最も静かで、最も不可逆なリスク
障害は復旧し、値上げは交渉できますが、組織から失われた技能は簡単には戻りません。全社がAI前提になって2〜3年経つと、「AIのドラフトをレビューできるが、ゼロから書いたことはない」人材が多数派になります。この状態で長時間の障害が起きると、フォールバック手順書があっても実行できる人がいないという事態に直面します。
さらに深刻なのは、レビュー能力自体の劣化です。AIの出力の妥当性を判断するには、自分でその業務を遂行できるだけの技能が必要です。ゼロから作る経験を失った組織は、やがてAIの間違いに気づけない組織になります。これは障害時だけでなく、平常時の品質リスクでもあります。
技能維持プログラムの設計
- 「AIなし業務」の定期実施：重要業務について、月1回あるいは四半期に1回、AIを使わずに業務を遂行する機会を計画的に設ける。ステップ2のAI停止訓練と統合すると運用負荷を抑えられる。
- 新人教育は「AIなし」から始める：基礎技能を身につける前にAI前提の業務フローに投入すると、レビュー能力が育たない。育成初期は意図的にAIの利用を制限し、土台を作ってから解放する。
- 技能保有者の可視化：フォールバック手順を実行できる人材を業務ごとにリスト化し、最低人数（例：業務あたり3名）を維持する。ネットワーク運用で「この装置を触れるのが1人しかいない」状態を属人化リスクとして管理するのと同じ発想。
- 評価制度との整合：AI活用度だけを評価すると、組織は合理的にデスキリングへ向かう。「AIなしでも遂行できる技能の維持」を評価項目に含め、技能維持が損にならない構造にする。
BCPへの組み込み——AI依存を事業継続計画の正式な一章にする
ここまでのステップ1〜4は、個別に運用すると形骸化します。持続させる仕組みが、既存のBCP（事業継続計画）への組み込みです。多くの企業のBCPは地震・水害・システム障害・パンデミックを想定していますが、「AIベンダーの障害・撤退」を正面から扱っているものはまだ少数です。
- リスクシナリオへの追加：「主要AIベンダーの24時間障害」「主要モデルの提供終了（90日予告）」「主要ベンダーの50%値上げ」を、BCPの想定シナリオに正式に追加する。
- 既存の枠組みを流用する：BIA・RTO・訓練・見直しサイクルというBCPの既存プロセスに、ステップ1の棚卸しとステップ2の訓練を載せる。新しい管理プロセスをゼロから作るより、定着がはるかに速い。
- 年次見直し：AI依存度は毎年変わる。棚卸し（ステップ1）を年次のBCP見直しサイクルに組み込み、依存度マップを最新に保つ。
- 経営報告への接続:第9回で作った経営ダッシュボードに「AI依存リスク指標」（フォールバック整備率・訓練実施率・技能保有者数）を加えると、投資判断の俎上に載る。
AIレジリエンス・チェックリスト
| 領域 | チェック項目 | 主に効くリスク |
|---|---|---|
| 棚卸し | 重要業務のAI依存度・停止時影響・許容停止時間を業務単位で把握している | 全般 |
| 棚卸し | 依存度マップを年次で更新するサイクルがある | 全般 |
| フォールバック | 優先業務に「AIなし運転」の縮退手順書がある | ベンダー障害 |
| フォールバック | 発動基準・解除基準・宣言者が決まっている | ベンダー障害 |
| フォールバック | 年1回以上のAI停止訓練を実施している | 障害・デスキリング |
| 分散 | 最重要業務は複数ベンダーで動作検証済み | 障害・値上げ |
| 分散 | 抽象化レイヤーによりベンダー切り替えが設定変更で可能 | 仕様変更・改廃 |
| 分散 | 料金・仕様変更のアナウンスを監視する担当がいる | 値上げ・改廃 |
| 分散 | 重要業務の回帰テストセットを保持している | 仕様変更・改廃 |
| 技能維持 | フォールバック実行可能な人材を業務ごとに最低人数維持している | デスキリング |
| 技能維持 | 新人育成の初期段階でAIに依存しない基礎訓練を行っている | デスキリング |
| 統合 | AI依存シナリオがBCPに正式に組み込まれている | 全般 |
よくある質問（Q&A）
Q1. ベンダーのSLAがあれば十分ではないですか？
不十分です。SLAは停止時間に応じた返金を約束するもので、あなたの業務の継続を約束するものではありません。返金額は障害で失われる事業価値に比べて通常はるかに小さく、SLAをどれだけ厳格に交渉しても、障害当日に業務を回すのは自社のフォールバック手順です。SLAは「事後の補償」、レジリエンスは「当日の継続」と分けて考えてください。
Q2. マルチベンダー構成はコストが2倍になりませんか？
常時2系統をフル稼働させる必要はありません。現実的なのは、最重要業務に限定して「切り替え先の検証済み構成」を維持する形です。かかるのは検証と回帰テストの工数が中心で、平時の利用料はほぼ片系のみです。それでも増えるコストは、第11回のユニットエコノミクスの枠組みで「保険料」として明示的に予算化することをおすすめします。
Q3. デスキリング防止のためにAI利用を制限すると、生産性が下がりませんか？
短期的には下がります。だからこそ「全面制限」ではなく「計画的な維持」です。月1回・重要業務に限定した「AIなし業務」の実施であれば、生産性への影響は限定的で、障害時の継続能力とレビュー品質という見返りがあります。何もしない場合のコストは、長時間障害の当日に、複利で一括請求されます。
Q4. 連載第6回のロックイン対策をやっていれば、今回の対策は不要では？
別物です。ロックイン対策は「数ヶ月かけて乗り換えられる」状態を作るもので、障害発生から数時間で業務を継続する能力は提供しません。逆に、フォールバック手順が完備でも、値上げに対する交渉力（移行可能性）がなければ飲むしかありません。出口戦略（第6回）と継続戦略（本記事）は、両方あって初めて依存リスク全体をカバーします。
Q5. 何から始めればいいですか？
ステップ1の棚卸しからです。対象は全業務でなくてよく、まず「止まると顧客に影響が出る業務」の上位5〜10個に絞って、依存度・許容停止時間・フォールバックの有無を1〜2週間で洗い出してください。その結果、「依存度が高く、フォールバックがない」業務が1つでも見つかれば、それが経営への報告材料と最初の対策対象になります。
まとめ——「止まらないAI」ではなく「止まっても回る組織」を作る
第12の壁への対処を、3点に要約します。
1. 依存リスクは「AIの障害率」ではなく「組織の復元力」の問題である。ベンダーの信頼性向上を祈ることはできませんが、止まった日に業務を回す準備は自社で完結できます。棚卸し→フォールバック設計→訓練が基本サイクルです。
2. 障害・値上げ・仕様変更・デスキリングは、1つの構造（集中と依存）から生まれる4つの症状である。個別対応ではなく、集中リスクの分散（マルチベンダー・抽象化レイヤー）と技能維持プログラムという構造への対処が効きます。
3. 新しい管理体系を作るのではなく、BCPに組み込む。BIA・RTO・訓練・年次見直しという実績ある枠組みにAI依存シナリオを追加するのが、最も定着しやすい実装です。
ネットワークの世界には「障害は起きるかどうかではなく、いつ起きるかの問題」という格言があります。AIが業務の前提インフラになった今、同じ前提に立てるかどうかが、拡大を完成させた組織の次の分かれ道です。「止まらないAI」は買えませんが、「止まっても回る組織」は作れます。
参考リンク
免責事項：本記事は2026年7月時点の公開情報に基づく一般的な情報提供であり、特定の製品・サービス・構成における可用性や安全性を保証するものではありません。また、法的助言ではありません。実際の事業継続計画・契約交渉・リスク管理は、自社の環境・契約条件・関連法令に照らして検討し、必要に応じて専門家にご相談ください。
コメント