W EC AI WorksECの仕事を、AIで減らす。

読み物

AIが止まったら会社も止まる!
自動化が進むほど深刻になるAI障害対策

AIに仕事を任せれば任せるほど、AIに依存しない仕組みも同時に作る。

会社のAI自動化を進めていく中で、ずっと気になっていたことがあります。

AIのサーバーが止まったら、業務まで止まるのではないか?

実際、ClaudeなどのAIサービスは、まれに障害やアクセス制限で利用できなくなることがあります。

AIを相談相手として使っているだけなら、

「今日は使えないから、あとでやろう」

で済みます。

しかし、AIが受注処理、集計、広告運用、経理処理などの業務を自動で動かしている会社では話が違います。

AIが止まる=会社の業務が止まる

という問題が起こります。

自動化すればするほど、この問題は深刻になります。

このリスクをずっと懸念していましたが、ようやく対策の方向性が固まってきました。

方法1 そもそもAIがなくても動くようにする

まず大事なのは、

「AI自動化」といっても、すべてをAIが考えて処理しているわけではない

ということです。

実際には、

  1. データを取得する
  2. ファイルを変換する
  3. 集計する
  4. システムに登録する
  5. 結果を保存する

といった各工程のプログラムをAIが作り、

普段のAIは、

「次はこのプログラムを動かす」

という指揮役をしているだけ、というケースも多くあります。

いわゆるAIによるオーケストレーションです。

しかし、毎回やることが決まっている処理なら、そもそもAIに指揮させる必要はありません。

各プログラムを順番に実行する仕組みにしておけば、

Claudeが止まっていても、プログラムだけで業務を最後まで実行できます。

AIが指揮役 AI 指揮役 データを取得する ファイルを変換する 集計する システムに登録する 結果を保存する 「次はこのプログラムを動かす」 順番に実行する仕組み データを取得する ファイルを変換する 集計する システムに登録する 結果を保存する プログラムだけで最後まで実行できる
毎回やることが決まっている処理なら、AIに指揮させる必要はない。各プログラムを順番に実行する仕組みにしておく。

つまり、

AIが必要な仕事と、AIがなくてもできる仕事を分離する

ということです。

これはAI障害対策としてかなり重要だと思っています。

方法2 AIの判断が必要な仕事は別のAIに振り替える

問題は、

本当にAIの判断が必要な自動化

です。

たとえば、

  • 内容を読んで分類する
  • 異常かどうか判断する
  • 広告データを分析する
  • 問い合わせ内容から回答を考える
  • 状況によって次に行う処理を変える

こういった仕事は、普通のプログラムだけでは対応しにくく、AIが必要になります。

そこで、

Claudeが止まったらCodexに切り替える

という仕組みにします。

Claude Codeで作ったものはCodexでも動かせる

これは最初かなり大掛かりな作り直しになると思っていました。

しかし実際には、

Claude Codeである程度システムが完成したあとでも、Codexで動かせるように後から対応できます。

Claude CodeもCodexも、

  • ファイルを読む
  • プログラムを理解する
  • 指示書を読む
  • プログラムを実行する
  • 結果を確認する

といった基本的な作業は共通しています。

もちろん細かな違いはあります。

しかし、

「Claude専用のシステム」ではなく、「AIが操作する業務システム」として作っておけば、複数のAIから利用できます。

ただし、最初の設計がかなり重要

ここで重要なのが、

ファイルやルールをきちんと整理しておくことです。

Claude Codeだけで使うからといって、

  • フォルダ構成がバラバラ
  • ファイル名のルールがない
  • 指示がClaudeとの会話の中にしか残っていない
  • どのプログラムをいつ使うのか分からない
  • 処理の前提条件が書かれていない

という状態になっていると、Codexに切り替えたときに非常に苦労します。

逆に、

  • フォルダ構成
  • ファイルの役割
  • 業務ルール
  • 実行条件
  • 完了条件
  • エラー時の対応

などをきちんと整理しておけば、別のAIでもかなり理解しやすくなります。

つまり、

複数AI対応で一番重要なのは、AIそのものより「整理された業務設計」です。

複数のAIから利用できる Claude Code Codex AIが操作する業務システム 整理された業務設計 フォルダ構成 ファイルの役割 業務ルール 実行条件 完了条件 エラー時の対応
「Claude専用のシステム」ではなく、「AIが操作する業務システム」として作っておく。一番重要なのは、AIそのものより「整理された業務設計」。

理想は3段構え

現在考えている構成は、次の3段階です。

第1段階AIが不要な仕事
→ 普通のプログラムだけで動かす
↓
第2段階AIの判断が必要な仕事
→ Claudeで処理する
↓
第3段階Claudeが使えない
→ Codexなど別のAIに切り替える

こうしておけば、Claudeに障害が起きただけで会社の業務全体が止まる可能性はかなり下げられます。

これでAI障害は怖くない……とは言い切れない

ただし、これですべて解決したわけではありません。

複数のAIサービスを用意していても、

AIサービス全体で同時に障害が起きる可能性はゼロではありません。

Claudeが止まったらChatGPT。

ChatGPTも止まったらGemini。

というように切り替えても、

複数サービスが同時に利用できなければ、AIが必要な業務は止まります。

クラウドAIに依存している以上、このリスクを完全になくすことはできません。

最終的には自社LLMも必要になるかもしれない

そこで将来的に考えているのが、

自社環境で動かすローカルLLM

です。

社内PCや自社サーバーでAIを動かせれば、外部AIサービスがすべて止まっても最低限のAI処理を続けられる可能性があります。

今のところ、ClaudeやChatGPTクラスのAIを完全に置き換えるのは現実的ではありません。

しかし、

「普段はClaudeやCodexを使う」

「非常時だけローカルAIで最低限の業務を続ける」

という非常用システムであれば、今後十分検討する価値があると思っています。

AI自動化は「止まる前提」で作る

AI自動化を始めた頃は、

どうやってAIに仕事をさせるか

ばかり考えていました。

しかし、自動化が増えてくると次に必要になるのは、

AIが止まったとき、どうやって業務を続けるか

です。

これからAIを本格的に業務へ組み込む会社では、

AI障害も、サーバー障害や停電と同じ「事業継続リスク」

として考える必要があると思います。

AIに仕事を任せれば任せるほど、

AIに依存しない仕組みも同時に作る。

少し矛盾しているようですが、これがAI自動化を本当の意味で会社のインフラにするために必要なことだと思います。

そのAI自動化、パソコンが1台壊れたら止まりませんか コンテンツ一覧へ

この記事は、いまのあなたに合っていましたか

ボタンについては、お名前を取っていません。同じ方が二重に数えられないようにするためだけに記録が残ります。

この記事について質問・感想を送る

いただいた内容は、確認したうえで記事の下に載せることがあります。お名前は取っていません。