想定読者
ChatGPTやCodexなどのAIエージェントをすでに社内で使い始めている、あるいは導入を検討している中小企業の経営者やIT担当者で、常時稼働するAIエージェントに社内データへのアクセス権を渡すことに不安を感じている方を想定しています。
要点
- DevDay 2026で発表された常時稼働エージェント「dots」と、企業向けセキュリティ機能（Codex Security Cloud、Private Intelligence、Private Inference）の役割を整理します
- 自律的に動くAIエージェントを社内に迎える前に、アクセス権限・データの扱い・監視体制をどう設計すべきかの判断基準を示します
- 導入前チェックリストで、便利さへの期待と実際に管理すべきリスクを分けて考えられるようにします
DevDay 2026で「AIエージェントが社内に常駐する時代」が始まった
米OpenAIが2026年9月29日に開催した年次開発者会議「OpenAI DevDay 2026」では、AIエージェントに関する発表が相次ぎました。今回のテーマは、AIが「指示に対してその都度答える道具」から「自律的に動き続け、人と協働する同僚」へと役割を広げていく点にあります。
出典：OpenAI DevDay 2026 Recap（OpenAI）
この変化は、社内でAIエージェントを使い始めている、または導入を検討している企業にとって、単なる新機能の追加ではなく、社内のアクセス権限やデータの扱い方そのものを見直す必要があるという意味を持ちます。
常時稼働エージェント「dots」とCodex Cloud・Codex Security Cloudの概要
DevDay 2026で発表された「dots」は、ユーザーが指定した目標やルールに従って、バックグラウンドで自律的に働き続ける専用のAIエージェント機能です。
専用のクラウド環境とブラウザを持ち、数千の外部アプリと連携してタスクを遂行する点が特徴で、Pro、Business、Enterpriseといった各プランで利用できるとされています。
開発者向けには、クラウド上でコード開発の実行環境を提供する「Codex Cloud」に加え、GitHubリポジトリ全体を定期的にスキャンして脆弱性の調査・修正を行う「Codex Security Cloud」も発表されました。
これは、AIエージェントが書いたコードや既存のコードベースを継続的に点検する仕組みで、開発の効率化と安全性の両立を狙ったものです。
なぜ今、社内のセキュリティ設計を見直す必要があるのか
これまでのChatGPTやCodexの使い方は、担当者が都度指示を出し、結果を確認してから次の作業に進む「対話型」が中心でした。
しかし「dots」のような常時稼働エージェントは、人が画面を見ていない時間にも自律的に判断し、外部アプリと連携しながらタスクを進め続けます。
この働き方の変化は、これまで「担当者が確認しながら使うツール」として設計してきた社内のアクセス権限やデータ管理のルールが、そのままでは通用しなくなる可能性を意味します。
エージェントに渡す権限の範囲、扱わせるデータの種類、動作を後から追跡できる仕組みを、あらかじめ整理しておく必要があります。
自律型エージェントを迎える前に整理すべき3つの論点
アクセス権限とデータ範囲の切り分け（数千の外部アプリと連携する前提を踏まえて）
「dots」は数千の外部アプリと連携してタスクを遂行する前提で設計されています。これは裏を返せば、エージェントに与える連携先の数と種類がそのまま「アクセス可能な社内データの範囲」に直結するということです。
導入時にありがちなのは、「便利そうだから」という理由で連携できるアプリを片っ端から許可してしまうことです。
しかし、エージェントが本来の業務に必要な範囲を超えて顧客情報や財務データにアクセスできる状態になっていないか、連携を許可する前に一つずつ確認する姿勢が欠かせません。権限は「使えるようにしてから絞る」のではなく、「必要な範囲だけを先に決めてから広げる」順序で設計するのが安全です。
ゼロデータ保持（ZDR）・Private Intelligence・Private Inferenceの違いを理解する
DevDay 2026では、企業向けのプライバシー機能として「Private Intelligence」と「Private Inference」のプレビュー提供が発表されました。
「Private Intelligence」は、ゼロデータ保持（ZDR、企業が入力したデータをOpenAI側に保持しない仕組み）を維持しながら、OpenAIの従業員がデータの中身を見ずに安全性を自動チェックできる機能です。
「Private Inference」は、コンフィデンシャルコンピューティング（処理中のデータを外部から見えない状態で扱う技術）を用いて、より厳格なプライバシー保証を提供する仕組みとされています。
両者はいずれも、機密データを扱う企業がフロンティアモデル（各時点で最も高性能なAIモデル群を指す言葉）を安心して利用できるようにするための機能ですが、「データを保持しない」ことと「データの中身を人が見ない」こと、「処理環境自体を保護する」ことは、それぞれ異なる保証の階層にあります。
導入を検討する際は、自社が扱うデータの機密度に応じて、どの階層の保証が必要なのかを区別して考えることが重要です。
Codex Security Cloudによる継続的な脆弱性監視を既存の運用体制にどう組み込むか
「Codex Security Cloud」は、リポジトリ全体を定期的にスキャンして脆弱性を調査・修正する機能です。
この仕組みを導入する場合、スキャン結果を「誰が」「いつ」確認し、修正が必要な指摘にどう対応するのかという運用フローを、既存のセキュリティ運用体制の中に組み込んでおく必要があります。
自動で脆弱性を検出できるようになったとしても、検出結果を放置すればリスクは残ったままです。
ツールを導入すること自体をゴールにせず、検出から対応までの一連の流れを社内の誰かが責任を持って回す体制を、導入前に決めておくことが欠かせません。
中小企業向け・導入前チェックリスト
自律型AIエージェントを社内に迎える際は、権限設計・データ・プライバシー・監視・運用の3つの観点を並べて確認すると、抜け漏れに気づきやすくなります。
| 確認する視点 | 権限設計 | データ・プライバシー | 監視・運用 |
|---|---|---|---|
| 主な確認事項 | アクセス範囲の限定 | ZDR適用の有無確認 | 脆弱性スキャン結果 |
| 判断基準 | 業務に必要な最小権限 | 機密データの扱い方針 | 検知後の対応ルール |
| 見直す頻度 | 連携追加時に都度 | 契約・規約更新時 | 定期スキャンの周期 |
| 主な責任者 | 情報システム担当 | 経営層・法務 | 運用・セキュリティ担当 |
権限設計のチェック項目
権限設計では、エージェントが連携するアプリを増やすたびに、その都度アクセス範囲が業務上必要な最小限に収まっているかを確認します。
判断基準は「便利かどうか」ではなく「その権限がなければ業務が回らないか」に置くことが重要です。
データ・プライバシーのチェック項目
データ・プライバシーの観点では、ゼロデータ保持が適用されているか、機密度の高いデータをどこまでエージェントに扱わせてよいかという方針を、経営層や法務も含めて事前に取り決めておきます。
この方針は契約内容やサービス側の規約が更新されるタイミングで見直します。
監視・運用体制のチェック項目
監視・運用の観点では、脆弱性スキャンなどで検出された指摘を誰が確認し、どのルールに従って対応するかをあらかじめ決めておきます。
スキャンの実施周期や、検知後の対応にかかる時間の目安も、運用担当者とセキュリティ担当者の間で共有しておくと、実際に指摘が出たときに対応が滞りません。
よくある誤解と注意点
「自律的に動く＝チェック不要」ではない
常時稼働エージェントは、人が指示を出さなくても自律的にタスクを進められる点が魅力ですが、これは「人による確認が不要になる」ことを意味しません。
エージェントが自律的に動く時間が長くなるほど、動作の結果を後から追跡し、問題があれば早期に気づける仕組みの重要性は高まります。
自律性と監視は反比例するものではなく、自律性を高めるほど監視の仕組みも合わせて強化する必要があります。
外部アプリ連携を広げる前に段階的な導入計画を立てる
「数千の外部アプリと連携できる」という特徴は魅力的ですが、最初から連携先を広げすぎると、権限管理やデータ管理の複雑さが一気に増します。
まずは限られた業務・限られた連携先で運用を始め、権限設計やデータの扱い方に問題がないことを確認したうえで、対象範囲を段階的に広げていく計画を立てることをおすすめします。
まとめ
DevDay 2026で発表された「dots」のような常時稼働エージェントは、AIとの付き合い方を「対話型の道具」から「社内に常駐する同僚」へと変えていく可能性を持っています。
その分、アクセス権限・データの扱い・監視体制という3つの論点を導入前に整理しておくことが、これまで以上に重要になります。
まずは自社の中で、今回のチェックリストに沿って権限設計とデータ・プライバシーの方針を確認する一歩から始めてみてください。
