予告なしの破壊的変更。翌朝、担当者の机には何が載っているか

GembaOS は、AI エージェントを職務権限規程・稟議・監査のもとで運用するための実行基盤です。ポリシーによる権限判定、パラメータに紐づくワンタイム許可証、人の承認記録を、オンプレミスまたはプライベート VPC 上で提供します。

この記事で扱うのは、企業の現場で最も頻発し、かつ発見が遅れやすいサイレントな障害です。外部 SaaS ベンダーが深夜に API の仕様を変更し、更新履歴は読まれず、基幹業務の安全装置が火曜の未明から静かに機能停止していた、というケースです。

最も深刻な障害は、クラッシュせずに発生する

火曜日の未明、利用している CRM ベンダーが IsEscalated（エスカレーション済みか否か）という真偽値項目の返却を突然停止したとします。

このとき、社内のバックエンドコードがエラーで落ちることはまずありません。多くのプログラミング言語では、存在しない項目を読み込むとデフォルト値（真偽値なら false）として処理されるためです。

その結果何が起きるか。顧客から「至急対応」としてエスカレーションされたはずの重要インシデントが、すべてシステム上「通常案件」として扱われるようになります。500 エラーも出ず、監視アラートでエンジニアが叩き起こされることもありません。表面的には完全に平穏なまま、企業の最も重要な安全ガードレールだけが静かに骨抜きにされます。

これが最も高くつく障害の正体です。システムは落ちていません。すべての判断に対して、ただ静かに誤った結論を出し続けているのです。

ドキュメントを待つのではなく、実環境をプローブする

ベンダーからの通知メールを待っていては手遅れになります。GembaOS のアプローチは極めてシンプルです。毎晩、ベンダーのサンドボックス（検証環境）に対して自動で「健康診断」を行います。

GembaOS では、連携する外部インターフェース（ケイパビリティパック）ごとに、期待するデータ構造があらかじめ宣言されています（項目名、型、取りうる enum、null 許容性）。

夜間の定期チェックが実行されると、検証用リクエストをベンダーのサンドボックスへ送信し、返ってきた実レスポンスと宣言された契約を 1 行ずつ突き合わせます。ベンダーが項目の返却をやめた場合、GembaOS はその夜のうちに「ドリフト（乖離）」を検知します。

Contract check: crm   2026-09-23T12:13:59+09:00

CHECKED (1): get_case

DRIFT (5)
  FIELD_ABSENT       get_case.IsEscalated    declared boolean, not in the answer
  FIELD_UNDECLARED   get_case.riskScore      the answer carries a field the pack does not
                                             declare (number): a quiet addition

検知エンジンは 7 種類の乖離を識別します。ドキュメントには決して載らない「名前はそのままでデータ型が変わった」「想定外の enum 値が返ってきた」「null 非許容の項目に null が入ってきた」といった異常も網羅します。もしベンダーが HTTP レスポンスヘッダーに Sunset（廃止日）を記載していれば、その日付も即座に監査ログへ記録されます。

単なる通知ではなく、業務への影響範囲を算出する

API の変更を検知した際、一般的な監視ツールは「API changed」というメールを飛ばすだけで、受信トレイに埋もれてしまいがちです。

GembaOS は単なるアラートにとどまりません。社内で定義されている業務フロー（プレイブック）や承認条件を即座にスキャンし、具体的な業務影響範囲（ブラスト・ラディウス）を自動算出します。

1. どの業務の前提チェックが、この消失した項目に依存しているか。
2. どの自動処理が安全性を失うことになるか。
3. 影響度に応じた重大度分類：
   • BREAKING（致命的）：必須の照合項目が消失または型変更され、業務ルールが無力化される $\rightarrow$ 連携責任者とセキュリティ審査の 2 名による承認が必須；
   • DEGRADED（機能低下）：enum の追加や予期せぬ null の発生など、動作は継続できるが潜在的リスクがある $\rightarrow$ 連携責任者とプラットフォーム責任者の承認が必須；
   • COSMETIC（軽微）：未宣言の項目が追加されたが、自社のどの業務もそれに依存していない $\rightarrow$ 連携責任者 1 名の確認のみ。

外部の破壊的変更が「自動承認」されることはありません。影響を受ける業務の責任者が状況を把握し、署名（押印）することが必須となります。

人間がリスクを承認し、エンジニアへタスクを起票する

翌朝、責任者の管理画面に届くのは生の障害ログではなく、整理された「業務影響レポート」です。

• ベンダーの応答の何が変わったか。
• 自社のどの業務・ルールが影響を受けるか。
• 調査エージェントがまとめた要約と推奨アクション。

責任者が開くのは、たとえばこの画面です（この記事の最後で紹介するデモを実際に動かしたもの）。要旨の数字一つひとつにホストの照合結果が付き、押印はまだ二つとも残っています。

責任者がこれを確認して承認すると、「企業としてこの外部変更を認識し、リスクを受理した」という正式な記録がハッシュ付きで監査チェーンに刻まれます。システムはこの承認を受けて、担当エンジニアへ向けた修正タスクを自動起票します。

審査自身のタイムラインでは、二つの押印と再照合のあと、修正タスクの起票が最後の一行になります。タスクの側では、依頼文はホストが組み立てたもので、ペンはエンジニアが握っています。

AI が修正コードを書き、人間がマージする

コードの修正フェーズでは、AI の開発生産性を最大限に活かしつつ、権限の統制を維持します。

1. AI は安全なサンドボックス内で作業：エンジニア専属のコーディングエージェントが隔離サンドボックス内でコードを読み込み、ロジックを修正（例：消失した項目を既定値 false で受け流すのをやめ、新しい代替エンドポイントを参照するよう変更）。テストや CI を実行します。
2. Pull Request を作るのは AI ではなくホスト：エージェントの仕事は変更セットの提出までです。CI を通過し、コードオーナーが押印した後、ホストが押印済みのパッチそのものを GitHub/GitLab 等にプッシュし、案件 ID と検証先を記した Pull Request を作成します。コード管理基盤の資格情報はエージェントには渡らず、御社のネットワーク内で動くワーカーの中にだけ置かれます。
3. 人間が最終マージを実行：AI に本番ブランチへのマージ権限は一切与えられません。 必ず人間のエンジニアが差分をレビューし、自らのアカウントと権限で Merge ボタンを押します。

デモにはコード管理基盤がつながっていないため、最後の関門はこの稟議書です。スタブのエージェントが出す変更セットは二つのファイルで、項目が無いときは読み手がエラーを返すようにし、そのことをテストで確かめます。このファイルはベンダーの応答を読むので、コードオーナーの押印があって初めて、ホストがテナント自身のリポジトリに取り込みます。

深夜の API 変更検知から、翌朝の影響特定、責任者によるリスク承認、AI によるパッチ作成、そしてエンジニア自身によるマージまで、一連の統制ループが完成します。

• AI の役割：問題の能動的検知、影響範囲の計算、修正パッチの起草
• 人間の役割：リスクの判断と承認、最終的なコード変更の責任と本番マージ

AI が勝手に本番コードを書き換えることも、外部 API の仕様変更が放置されて業務が沈黙することもありません。

---

アーキテクト向け技術保証

• 候補パック（Candidate Pack）の隔離：検知された新しいスキーマは候補として隔離台帳に保管され、正式承認を受けるまで本番のランタイムには一切反映されません。
• 実行直前の再検証（Preflight Check）：承認待ちの間にベンダーの仕様がさらに変化した場合、承認された影響表のハッシュと不整合が発生し、システムは自動で差し戻しを行います（古い前提による誤実行を防止）。
• プロンプトインジェクション防御：ベンダーが公開するリリースノート等の自然文は未検証データ（trust: DATA）としてのみ扱われ、AI や評価ロジックに対する指示文として直接解釈されることはありません。
• デモ環境での再現：ローカル環境で gemba demo vendor --drift を実行することで、外部 API ドリフトの発生から影響特定までのガバナンスフローを体験できます。