AIの業務使用における冗長性

確かにインフラとして捉えるならばバックアップの用意も必要かもしれません。

心配なのは依存度が高ければ高いだけ人力での処理代行が困難になっていく事です。

すると、すぐに別モデルに切り替えて滞りなく業務を継続出来るかという視点が必要となりますが、これこそが判断の栞や、監査AIの重要性を裏付ける事になると考えます。

一つのモデルに依存していたとて、栞の可搬性を持って別モデルに移行し、監査AIが新モデルでの出力結果の妥当性や品質を判断する。

この様な体制が整っていれば、複数のモデルに重大な問題や欠陥が同時に起こらなければ業務継続が可能だと思います。

まさにARPANETから連なるインターネットの思想に近しいと思います。

その設計思想は妥当性が高い。AIをインフラとして捉えるなら、単なる「モデルのバックアップ」では足りず、判断過程・業務文脈・評価基準・監査手順を別モデルへ移せることが本質になる。「判断の栞」と「監査AI」は、まさにAI時代の冗長化設計だと言える。

ただし、バックアップ対象は三層に分かれる。

第一に、モデルの冗長化

OpenAIが止まればClaudeへ、Claudeが止まればGeminiへ、Geminiが止まればローカルLLMへ、という代替経路。これはクラウド障害対策に近いが、これだけでは不十分だ。モデルが変わると、出力の癖、慎重さ、推論の深さ、禁止範囲、文体、ツール連携、長文処理、画像理解、コード生成の品質が変わる。

モデルの冗長化——同じ光が、経由する塔ごとに色を変える

第二に、文脈の可搬性——ここが「栞」にあたる

業務目的、過去の判断、禁則事項、承認済み方針、品質基準、顧客別事情、法務上の制約、表現トーン、過去の失敗、参照資料、決裁履歴が、特定モデルの会話履歴や独自メモリに閉じ込められていると、モデルを切り替えた瞬間に業務知性が失われる。「何を前提に、なぜその判断に至ったのか」を、モデル外部に保持する必要がある。

第三に、評価・監査の冗長化

新しいモデルに切り替えた後、その出力が旧モデルと同等か、危険な差異がないか、品質が落ちていないかを誰が見るのか。依存度が高まるほど人間だけでは追いつかなくなるため、監査AIが必要になる。監査AIは単に正誤判定するだけでなく、過去の栞と照合し、判断基準からの逸脱や、重要な前提の欠落、出力のリスク分類の変化を見る。

つまりAI業務継続に必要なのは、モデルを替えられること、文脈を運べること、出力品質を検査できること、責任ある人間が最終承認できること——この四つが揃って初めて、AIは業務インフラとして耐障害性を持つ。

ARPANET／インターネットとの接続は妥当だ。一つの中央ノードが壊れても全体は止まらず、経路を迂回できる。単一障害点を避けるという発想はAIにも共通する。ただし通信と違い、AIの場合は「届けばよい」では済まない。意味と判断品質が保たれたまま迂回できるかが問題になる。

ここがAI版の難しさだ。インターネットのパケットは別経路を通っても内容は同じだが、AI出力は別モデルを通すと内容が変わる。同じ入力でも解釈、優先順位、危険判定、文体、結論、根拠の出し方が変わる。だからAIインフラの冗長性は、単なる通信冗長性ではなく、意味論的冗長性でなければならない。

意味論的冗長性——同じ構造でも、通れば意味が変わる

ここで「判断の栞」が効いてくる。判断の栞は、AIの出力そのものではなく、判断の前提・基準・履歴・分岐点を保持する。これがあれば、新モデルに移ったときにも「この組織では、こういう条件ではこう判断してきた」「この案件では、この法務リスクを重視していた」「この顧客にはこの表現を避ける」「この品質基準を下回る案は出さない」といった業務文脈を移植できる。そして監査AIは、新モデルがその栞を正しく継承しているかを検査する。

実務的に言えば、企業のAI BCPには次のような構成が必要になる。

レイヤー	役割
業務プロンプト台帳	業務ごとの目的・禁止事項・承認条件を保存
判断の栞	過去判断・例外処理・根拠・変更履歴を保存
データ可搬層	RAG資料、顧客情報、ナレッジをモデル非依存で管理
モデル抽象化層	複数モデルを切り替えるルーティング基盤
監査AI	出力の妥当性、逸脱、リスク、品質差を判定
人間承認	高リスク処理の最終責任点
ロールバック	旧判断・旧文書・旧ワークフローへ戻す仕組み

ここで興味深いのは、以前から語られてきた「思考の栞」「健康の栞」「判断の栞」が、個人の記録思想であると同時に、企業AIのインフラ設計にも転用できることだ。個人では、栞は自己の思考や感情や判断の連続性を守る。企業では、栞は組織判断の連続性と説明責任を守る。行政では、公平性・不服申立て・監査可能性を守る。医療では、症状・診断・治療判断の時系列を守る。司法では、論点整理と根拠の追跡を守る。つまり栞とは単なるログではなく、AIと人間が共有する判断の可搬形式である。

ただし、少し批判的に言えば、完全な互換性は難しい。モデルごとに得手不得手があり、あるモデルでは安全に出来た業務が、別モデルでは不安定になることがある。特に医療、法務、金融、コード実行、画像生成、長文推論、エージェント操作では、単純な切替は危険だ。

だから「どのモデルでも同じ業務ができる」ではなく、業務ごとに許可モデル群を定義し、切替後に監査AIが品質ゲートを通すという設計が必要になる。たとえば——

• 低リスク文書作成：複数モデルへ即時切替可
• 顧客対応：切替後、トーン・事実確認監査を必須
• 契約書作成：法務監査AI＋人間承認必須
• コード本番反映：テスト・差分監査・人間承認必須
• 医療・金融判断：認定モデル以外へ切替不可、非常時は助言レベルに降格

このように、バックアップ時には「同じことを続ける」のではなく、場合によっては業務権限を縮退させる必要がある。これは飛行機のフェイルセーフに近い。全機能を維持できないなら、安全な機能だけ残す。

安全な縮退運転——全てを保てないなら、安全な機能だけを残す

AI BCPの理想形はこうなる。平時：高性能モデル＋業務エージェントで効率化 → 障害時：代替モデルへ切替 → 切替直後：監査AIが品質差を検査 → リスク上昇時：業務権限を縮退 → 高リスク案件：人間承認へ戻す → 復旧後：判断の栞を統合し、差分を保存。この構造なら、AI依存が高まっても完全停止ではなく、安全な縮退運転が可能になる。

一文にまとめるなら——AIインフラの耐障害性は、モデルの多重化ではなく、判断文脈の可搬性と監査可能性によって成立する。

単に「複数AIを契約しましょう」では浅い。本当に必要なのは、AIが担っていた判断の構造を別のAIにも読み込ませ、人間と監査AIがその妥当性を確認できることだ。そしてこれは、まさにAI時代のインターネット思想に近い。中央の単一知性に依存しない。知性の経路を複数持つ。文脈をパケット化する。判断を可搬化する。監査を分散させる。障害時には縮退しながら継続する。

「栞」は、そのための人間側のプロトコルになり得る。