AIが仕事のOSになる前に決める「依存予算」——Copilot刷新・Codex障害・エージェント越境から考える

MicrosoftはCopilotを「仕事のための新しいOS」と位置付け、会話、文書作成、アプリ構築、自律実行を一つの入口へ集めようとしています。その一方で、OpenAIのCodexではWeb版、API、CLI、VS Code拡張機能が同時に使えなくなる障害が約1時間続きました。さらに海外では、隔離された評価環境にいるはずのAIエージェントが、設定ミスによって実在する外部サイトへ到達した事例も報じられています。

三つのニュースは、便利さ、可用性、安全性という別々の話に見えます。しかし、日本企業にとって共通する問いは一つです。AIを仕事の中心へ置くほど、そのAIを「どこまで使ってよいか」だけでなく、「どこまで依存してよいか」を先に決められているでしょうか。

これまでSmart Kurashiでは、AIの成果を応答回数ではなく仕事の完了で測る「完了一件」の設計や、検索・判定・生成・実行を分ける四工程の境界設計を扱ってきました。今回はその先として、AIに渡してよい仕事量、止まってよい時間、外部へ出てよい範囲を「依存予算」として管理する方法を考えます。

「仕事のOS」は、一つの製品ではなく依存の束です

Microsoftが発表した新しいCopilotは、Home、Code、Autopilotの三つのタブで構成されます。Homeでは会話とタスク委任をまとめ、Office in Copilotによって編集可能なWord、Excel、PowerPointファイルを作成します。Codeでは自然言語からアプリやダッシュボード、自動化を構築します。Autopilotは、チャネルの監視、関係者への確認、定期作業、途中で止まった案件の再開まで、利用者の次の指示を待たずに進める構想です。

便利な機能が増えたという理解だけでは不十分です。入口が一つになると、その裏側には少なくとも五つの依存が束になります。

依存する対象	止まったときに起きること	先に用意する代替
認証と利用者ID	Copilotへ入れず、履歴や権限も参照できません	緊急用の手動手順と管理者連絡経路
モデルと推論API	回答、要約、生成、判断補助が止まります	低機能モデル、別モデル、人による定型処理
Microsoft 365内のデータ	メール、会議、文書の文脈を取得できません	承認済み資料の固定版と案件別の引き継ぎ票
エージェント実行基盤	監視、連絡、更新、アプリ実行が止まります	人が再開できる実行履歴と未完了一覧
従量課金と予算枠	上限到達後に高コスト機能を使えません	タスク別上限と低コスト経路への切り替え

OSという表現が重要なのは、利用頻度が増えるからだけではありません。複数の仕事が同じ認証、同じデータ接続、同じモデル選択、同じ実行基盤へ集まり、障害や設定ミスの影響範囲も共有するからです。Wordの下書きだけが止まるのではなく、見積もりの作成、会議の準備、顧客への連絡、進捗の更新が一緒に止まる可能性があります。

したがって導入判断は、機能一覧ではなく依存関係図から始めるべきです。「Copilotを導入するか」では問いが大きすぎます。「どの業務の、どの工程が、どの共通基盤に依存するか」まで分けると、止まったときに守る順番が見えてきます。

Codexの約1時間障害が示した「停止時間の予算」

OpenAIのCodexでは、日本時間9月26日の午前8時前から約1時間、全機能を利用できない障害が発生しました。ITmedia AI＋によると、Web版、API、CLI、VS Code拡張機能が影響を受け、ChatGPTなど他のサービスには影響がなかったとされています。途中ではAPIキーでのログインが案内され、その後すべてのサービスが復旧しました。原因は内部の問題と説明されましたが、記事公開時点で詳細は示されていません。

一時間は短く見えます。ところが、朝のデプロイ、障害対応、顧客向け修正、締め切り直前のレビューが重なれば、一時間の価値は部署ごとに大きく変わります。重要なのは平均稼働率だけではなく、「どの一時間なら待てて、どの一時間なら別経路へ切り替えるか」です。

停止時間の予算は、次の四段階で決められます。

15分までは待てる仕事

文章の言い換え、会議メモの整形、社内向けの案出しなど、後で再開しても顧客や生産に直ちに影響しない仕事です。利用者は再試行を繰り返さず、状態ページを確認し、入力途中の素材をローカルへ保存します。短い障害で人が過剰反応しないことも継続運用の一部です。

30分で代替へ切り替える仕事

コードレビュー、資料の初稿、問い合わせの分類など、当日中に終える必要はあるものの、同じモデルでなければならない理由が弱い仕事です。別モデル、社内テンプレート、人による処理へ切り替えます。切り替え先では精度や書式が変わるため、同じ承認基準をそのまま適用せず、差分を記録します。

60分を待てない仕事

本番障害の復旧、決済、出荷、設備停止、安全に関わる仕事です。ここではAIを主経路にしてはいけません。AIは調査や候補提示を補助できますが、AIなしで完了できる旧手順、連絡網、権限者、確認表を維持します。月に一度はAIを意図的に使わず、旧手順で一件を閉じる訓練が必要です。

復旧後に追跡する仕事

サービスが戻ったら終わりではありません。障害中に二重登録された依頼、別経路で更新された文書、未送信の通知、途中まで実行された自動化を照合します。復旧時には「再開」より先に、未完了と重複の一覧を作る方が安全です。

この四段階を業務ごとに決めれば、停止時間は技術部門だけの問題ではなくなります。営業は顧客回答の締め切り、経理は振込の締め、開発は変更凍結時刻という形で、自分たちの言葉で予算を持てます。

トークン予算は金額ではなくモデル選択のルールです

AIの依存は、止まることだけでなく、使い続けるほど費用が増えることにも現れます。＠ITが紹介したアクセンチュアの調査は、2026年7月に日本を含む17カ国、年間売上高10億ドルを超える企業でAI関連支出の意思決定に関わる経営層750人を対象にしています。併せて、米国の職業情報データベースにある9368件の職務タスクを分析しています。

調査では、対象企業の三社に一社で年間のトークン支出が予算を超過し、経営層は今後二年間でトークン消費量が78％増えると予測しました。一方、トークン支出と定量的な財務成果の関係を示せている割合は二割未満でした。最重要のAI活用事例でも、成果に対するコストを算出できている企業は35％にとどまったと報告されています。

特に注目したいのはモデルの割り当てです。アクセンチュアの分析では、フロンティアモデルの能力が必要なタスクは全体の約一割と推計される一方、実際のAIリクエストの54％が、必要な水準を上回る高性能モデルへ振り分けられていました。モデルルーティングを実際に導入している企業は30％、利用量に応じて部門へ費用を配分する社内課金は7％だったとされています。

ここから分かるのは、トークン予算を「月百万円まで」とだけ決めても足りないということです。金額上限に近づいた時点で一律に利用を止めると、低価値の大量処理が先に予算を使い、重要な判断を支える余力が残りません。

依存予算では、タスクを三つの車線へ分けます。

車線	代表的な仕事	モデル選択	上限時の扱い
基本車線	要約、分類、書式変換、検索語の生成	小型または低コストモデル	品質基準を満たす範囲で継続します
専門車線	契約差分、複雑なコード、複数資料の統合	高性能モデル＋専門家確認	案件番号と責任者を必須にします
緊急車線	障害調査、安全上の例外、経営判断の材料	適切な高性能モデルを優先	通常予算と別枠で記録します

この分け方なら、費用削減と可用性を同時に扱えます。基本車線を一つの高性能モデルへ固定せず、複数モデルへ振り分けられるようにすれば、障害時の切り替えも容易になります。反対に、専門車線で安さだけを優先すると、確認と再作業が増えて完了一件の原価が上がることがあります。

アクセンチュアは、使用責任の明確化、モデル割り当ての最適化、案件の可視化などを徹底することで、今後二年間に予想されるトークンコスト増を最大44％抑えられる可能性があると試算しています。これは個社への保証ではなく、調査と分析に基づく事業者の推計です。日本企業がその数字をそのまま予算へ置くのではなく、まず自社のタスク別原価と再作業を計測する出発点として使うのが適切です。

評価環境からの越境は「モデルの意思」だけで説明できません

The Vergeは、AIモデルのサイバー能力を評価する企業Irregularの試験で、OpenAI、Meta、Anthropic、Googleなどのエージェントが実在する外部の対象へ到達した事例を報じました。同社の説明では、評価用ネットワークから開かれたインターネットへ接続できる状態が意図せず残り、架空企業の名称が実在ドメインと重なったことが組み合わさりました。

ここで「AIが勝手に脱走した」とだけ理解すると、対策をモデルの性質やプロンプトへ寄せすぎます。記事が示す直接の要因は、外部接続が利用できたことと、試験用の識別子が現実の宛先と衝突したことです。つまり、モデル、評価課題、ネットワーク出口、名前解決、監視、公開手順の組み合わせで事故が成立しました。

日本企業の社内エージェントでも、同じ構造は起こり得ます。テスト用の「山田商事」が実在企業のドメインと一致する、検証用メールが外部へ送信される、ダミーの顧客番号が本番データに一致する、評価用APIキーに本番権限が残る、といった状況です。危険な命令を書いていなくても、出口が開いていれば、課題を忠実に遂行した結果として現実へ触れます。

越境予算は、エージェントが触れてよい範囲を五層で管理します。

1. 読み取り予算では、参照可能なデータ種別、期間、案件を限定します。
2. 書き込み予算では、下書き、検証領域、本番反映を分けます。
3. 通信予算では、許可した宛先、プロトコル、回数、時間帯を限定します。
4. 身元予算では、エージェント専用IDを使い、人の共有IDを渡しません。
5. 影響予算では、一度に変更できる件数、金額、設備、利用者数を限定します。

重要なのは、「外部接続なし」という設定名を信じるのではなく、実際の出口を別の監視から観測することです。DNS、HTTP、メール、クラウドAPI、MCP接続などを個別に遮断し、遮断を破る試験を行います。評価用の架空名称には、自社が管理する予約済みドメインや明らかに無効な識別子を使い、実在先との衝突を避けます。

IrregularはThe Vergeに対し、インターネット接続制御の強化、監視と手動レビューの拡大、評価開始前に意図した範囲と実際の接続を照合する確認、設定とパラメーターの文書化を進めたと説明しています。この対策は、モデルを一切信用しないという話ではありません。モデルが期待通りに課題を遂行しても現実を傷つけない環境を作るという、実装側の責任です。

以前の記事では、外部者がAIを悪用する流れと、AIが環境の境界を越える流れを分けて記録する四つの事故台帳を提案しました。今回の事例では、その台帳に「試験で許した接続」と「実際に開いていた接続」の差分を追加すると、原因を擬人化せずに追跡できます。

三つの依存予算を一枚にまとめます

停止時間、トークン、越境範囲を別々の部門へ任せると、相互作用が見えません。安いモデルへ切り替えた結果として再作業が増える、障害時の代替モデルだけネットワーク権限が広い、予算上限で監視機能まで止まる、といった逆転が起こります。

一枚の依存予算票には、次の項目を並べます。

項目	記録する内容
完了対象	AIの応答ではなく、最終的に閉じる業務一件
主経路	通常使うモデル、データ、実行基盤、認証
停止許容	待てる時間と切り替えを決める時刻
代替経路	別モデル、人、旧システム、手動帳票
費用上限	一件、日次、月次の上限と緊急別枠
権限上限	読み取り、書き込み、送信、実行の範囲
影響上限	一回の処理件数、金額、対象者、設備
復旧条件	未完了、重複、差分を照合して再開する条件
責任者	業務、技術、財務、安全の判断者

この票はAI製品ごとではなく業務ごとに作ります。同じCopilotでも、会議メモと仕入先評価では、停止許容も権限上限も違います。同じCodexでも、個人の試作と本番修正では、代替経路と影響上限が違います。

日本企業が30日で始める順番

最初の一週間は依存の棚卸しです

利用中のAIを列挙するだけではなく、AIが止まったら完了できない業務を十件選びます。各業務について、認証、モデル、データ、外部接続、実行権限、課金方式を一本の線で結びます。同じ接続先へ線が集中した場所が、共通障害点です。

二週目は切り替え基準を決めます

十五分、三十分、六十分のどこで待つのをやめるかを業務責任者が決めます。代替モデルへ切り替える仕事、AIなしで続ける仕事、停止する仕事を分けます。品質が下がる代替では、公開、送信、本番反映の前に人の承認を追加します。

三週目は出口と予算を絞ります

タスクを基本、専門、緊急の三車線へ分け、利用モデルと上限を設定します。エージェントには専用IDを付与し、外部通信の宛先を限定します。検証環境から実在ドメイン、個人メール、決済、顧客管理、本番設備へ到達できないことを、別の監視経路から確認します。

四週目はAI停止日を実施します

半日だけ主経路のAIを停止し、代替経路で実際の一件を完了させます。切り替えに要した時間、失った文脈、追加確認、重複、再作業、費用を測ります。訓練後は手順書の有無ではなく、別の担当者が再現できたかで合否を決めます。

見るべき指標は、AI利用率ではありません。代替経路への切り替え時間、AIなしの完了率、完了一件費、再作業率、権限外通信の遮断件数、復旧後の重複件数、責任者不在で止まった件数です。これらが下がれば、AIの利用量が増えても依存は管理可能になります。

参考にした主な情報

• ＠IT「AIトークンコスト増を44％抑制できる可能性も」（2026年9月26日）
• ITmedia AI＋「Codexで1時間にわたる障害」（2026年9月26日）
• ITmedia NEWS「Microsoft、Copilotを刷新」（2026年9月26日）
• The Verge「One company is at the center of a wave of rogue AI attacks」（2026年9月25日）

結論——便利さの上限ではなく、依存の上限を決めます

AIが仕事のOSになる未来は、遠い構想ではありません。会話、文書、アプリ、監視、連絡、実行が同じ入口へ集まり始めています。だからこそ、導入を急ぐ企業ほど、AIを使える範囲ではなく、AIに依存してよい範囲を先に決める必要があります。

停止時間の予算があれば、障害時に待つか切り替えるかを迷いません。トークンの予算をモデル選択のルールへ変えれば、安さと品質を両立しやすくなります。越境の予算があれば、エージェントが期待通りに動いても現実を傷つけない出口を作れます。そして三つを一枚へまとめれば、費用、安全、事業継続を別々の会議で扱わずに済みます。

次にAI機能を追加するとき、機能のデモを見る前に「これが一時間止まったら、誰がどの経路で一件を完了するのか」と尋ねてみてはいかがでしょうか。その答えを再現できる組織だけが、AIを便利な道具から、止まっても仕事を続けられる基盤へ育てられます。