Codex Appshotsは、Macで作業中の前面ウィンドウをCodexスレッドへ渡せる機能です。X/Twitterでも、Codexの画面コンテキスト共有や長い作業の継続に関心が集まっています。ただし、この記事ではSNS上の反応を技術的根拠にはしません。2026年6月17日時点のOpenAI公式ドキュメントを確認し、チーム導入前に決めるべき情報管理とレビュー手順に絞って整理します。
Appshotsは、説明文を長く書かずにエラー画面、APIリファレンス、デザインプレビュー、設定画面をCodexへ見せられる点が便利です。一方で、前面ウィンドウの画像だけでなく、アプリが利用可能にしているテキストも渡る場合があります。チームで使うなら、まず「何を見せてよいか」「誰が許可するか」「後からどう監査できるか」を決める必要があります。
この記事では、Appshotsをすぐ有効化すべきかを煽るのではなく、導入してよい条件、いったん無効化した方がよい条件、最初の2週間で試す範囲を具体化します。Codexの記憶や権限境界も含めて整理したい場合は、先にCodex Memoriesをチームで使う前に：AGENTS.md・Claude Code memory・MCP権限の分け方も参考になります。
3行まとめ
前面ウィンドウの画像と利用可能なテキストを、共有対象として扱います。
Screen & System Audio RecordingとAccessibilityを、個人判断で付与しないようにします。
画面種別、共有理由、機密確認、生成物との対応を残します。
便利さより先に、何を渡し、誰が許可し、どう見直すかを決めます。
- Appshotsは、macOSのCodex appから前面ウィンドウの画像と利用可能なテキストをCodexスレッドへ渡す機能です。
- チーム導入では、便利さより先に、禁止画面、macOS権限、管理設定、レビュー記録を決める必要があります。
- 顧客情報、認証、支払い、社内チャット、個人予定を含む画面は、原則として低リスク検証の対象から外すのが現実的です。
この記事でわかること
AppshotsでCodexに渡り得る情報を、画像とテキストに分けて見ます。
Appshots、Computer Use、内蔵ブラウザを別の権限面として扱います。
macOS権限とmanaged configurationの無効化設定を確認します。
承認ログ、レビュー記録、利用上限、レビュー時間を導入判断に含めます。
使うかどうかの前に、どの画面なら使ってよいかを決めます。
- AppshotsでCodexに渡り得る情報の範囲
- Appshots、Computer Use、内蔵ブラウザを分けて考える理由
Screen & System Audio RecordingとAccessibilityをチームでどう扱うか- managed configurationの
allow_appshots = falseを使う判断軸 - Appshotsを使った依頼で残すべきレビュー記録
- 初回導入で試してよい画面と避けるべき画面
- 料金、利用上限、承認ログを公開前に再確認するポイント
前提知識
- 1前面ウィンドウ
対象はデスクトップ全体ではなく、いま前面にあるウィンドウです。
- 2画像
見えている画面の状態が、Codexに渡す判断材料になります。
- 3利用可能なテキスト
アプリが提供するテキストも含まれ得るため、画像だけの共有とは分けて考えます。
- 4Codexスレッド
追加されたAppshotは、添付画像やファイルと同じように文脈へ入ります。
取得範囲はアプリによって変わり得るため、導入ルールは安全側に寄せます。
Appshotsは「画面共有」ではなく「Codex添付」として見る
根拠
OpenAIのAppshotsドキュメントでは、Appshotsは前面ウィンドウをCodexスレッドへ送る機能として説明されています。重要なのは、単なるスクリーンショット貼り付けではない点です。前面ウィンドウの見えている画像に加えて、そのアプリが利用可能にしているテキストも含まれ得ます。追加されたAppshotは、手動で添付した画像やファイルと同じようにCodexのスレッド文脈に入ります。
この性質は、開発作業にはかなり効きます。エラー画面を言葉で説明する代わりに、今見ている状態をCodexに渡せます。デザインツールやプレビュー画面を見せて、関連コードの修正方針を相談することもできます。APIドキュメントを開いた状態で、該当SDKの使い方を確認させる使い方も考えられます。
注意点
ただし、情報管理の観点では「画面を見せたつもり」より広く扱うべきです。見えている範囲だけでなく、アプリが公開しているテキストが含まれる可能性があるからです。Google Docs、Gmail、Google Sheets、Google Slidesのような一部アプリやWebサイトでは、Codexが可視範囲の画像だけを受け取り、文書全体や画面外テキストを受け取らない場合もあるとされています。つまり、常に多く取れるわけでも、常に少なく取れるわけでもありません。導入ルールは、最も安全な想定に寄せる方が扱いやすくなります。
Xの話題は需要シグナル、技術根拠は公式情報
確認範囲
今回のテーマ選定では、tracked XアカウントでAppshotsやCodexの画面コンテキスト共有が話題になっていることを需要シグナルとして見ました。一方、直近72時間で複数tracked accountにまたがる強い一致までは確認できなかったため、記事はポスト紹介ではなく、公式一次情報に基づく導入判断に寄せています。
技術的な事実は、OpenAI DevelopersのAppshots、Codex changelog、Computer Use、managed configuration、pricing、Agent approvals & securityで確認しました。料金や利用上限、対象プラン、管理設定は変わりやすいため、導入時には必ず公式ページで再確認してください。
Appshotsで何がCodexに渡るのか
- 1前面ウィンドウ
顧客情報、認証、支払い、社内チャットが表示されていないかを見ます。
- 2画像そのもの
その画面を社外AIサービスへ添付してよいかを判断します。
- 3テキスト情報
画面に紐づくテキストが一部渡っても問題ないかを確認します。
- 4迷う画面
判断に迷う場合は、Appshotsではなく伏せ字にしたテキスト説明で渡します。
許可リストはアプリ名ではなく、公開ドキュメントやモック画面など画面種別で書くと運用しやすくなります。
前面ウィンドウだけを切り出す
根拠
Appshotsの対象は前面ウィンドウです。デスクトップ全体や背後のウィンドウすべてをまとめて渡す機能として扱うべきではありません。これは安心材料にもなりますが、油断できる理由にはなりません。前面ウィンドウに顧客情報、未公開仕様、社内チャット、認証情報、支払い画面が表示されていれば、その画面がそのままCodexに渡る可能性があります。
確認項目
チームで最初に決めるべきなのは、アプリ名ではなく画面種別です。たとえば、ブラウザそのものを許可するかどうかだけでは足りません。同じブラウザでも、公開ドキュメント、社内管理画面、顧客CRM、決済ダッシュボード、個人メールではリスクが違います。許可リストは「Chromeは可」ではなく「公開APIドキュメント、ローカル開発画面、モックデータのプレビューは可」のように書く方が実務に合います。
画像と利用可能なテキストを分けて考える
評価基準
Appshotsは、見えている画像と利用可能なテキストをCodexへ渡り得る情報として扱います。画像だけなら問題ないと判断してしまうと、テキスト抽出された画面外情報やアクセシビリティ経由のテキストを見落とします。反対に、全アプリで画面外の全文が必ず渡ると決めつけるのも不正確です。
実務では、次の2段階で評価すると判断しやすくなります。
- その画像自体を、社外AIサービスへ添付してよいか。
- その画面に紐づくテキスト情報が一部追加で渡っても問題ないか。
この2つのどちらかで迷うなら、Appshotsを使わない判断で十分です。代わりに、必要な部分だけをテキスト化し、秘密情報を伏せた上でCodexへ渡してください。再現ログ、エラーメッセージ、UI要件、デザイン差分は、最小化したテキストの方が後から監査しやすいこともあります。
使ってよい画面と避ける画面
条件
初回検証で使いやすいのは、公開情報か、ダミーデータだけを含む画面です。公開APIリファレンス、ローカルのエラー画面、ステージングのモックデータ、デザインプレビュー、一般的な設定パネルは候補になります。Appshotsの強みは、言語化しにくいUI状態を短く伝えられることなので、画像や状態が判断に効く場面を選びます。
注意点
避けるべき画面は、判断を迷わせずに先に列挙しておく方が安全です。顧客名、メールアドレス、住所、契約情報、給与、支払い、認証、シークレット、社内チャット、個人カレンダー、未公開の経営資料、監査対象の管理画面は、少なくとも初回検証から外してください。
例外を認める場合は、担当者の裁量だけにしないことが大切です。責任者、理由、対象画面、期限、削除または保存方針を記録します。例外が常態化するなら、Appshotsよりも専用プラグイン、MCP、エクスポート済みの最小データ、匿名化したスクリーンショットの方が向いている可能性があります。
Appshots、Computer Use、内蔵ブラウザを混同しない
Appshotsの許可は、Computer Useの操作許可やブラウザ利用の許可とは別に扱います。
Appshotsは文脈を渡す機能
根拠
Appshotsは、Codexに画面文脈を渡すための機能です。画面を見せて「このエラーを踏まえて原因候補を出して」「このプレビューに近づけるCSS修正案を出して」「この設定画面の項目名を踏まえて手順書を直して」と依頼する使い方が中心になります。
注意点
つまり、AppshotsだけでCodexが対象アプリを操作するわけではありません。ここを混同すると、レビュー観点がずれます。Appshotsで見るべきリスクは、主に「何を共有したか」「共有した情報を根拠に何を生成したか」です。操作権限やクリックの承認は、Computer Useなど別機能の話になります。
Computer Useは操作まで含む
根拠
Computer Useは、Codexが対象アプリを見たり操作したりするための機能です。OpenAIのComputer Useドキュメントでは、画面内容、スクリーンショット、ウィンドウ、メニュー、キーボード入力、クリップボード状態などを扱う点が説明されています。タスク中にどのアプリを使わせるかの承認も関係します。
注意点
AppshotsとComputer Useを同じ「画面系機能」としてまとめると、許可が広がりすぎます。Appshotsは情報共有、Computer Useは視覚確認と操作を含む自動化、と分けて管理してください。サインイン済みブラウザ、管理画面、支払い、アカウント設定、セキュリティ設定は、Computer Useで特に慎重に扱うべき領域です。
ブラウザや外部サービスとの接続範囲まで整理するなら、Codex Skillsをチームで入れる前に：サードパーティSkill・MCP依存・権限を監査するのように、Skill、MCP、外部通信を別の権限面として棚卸しすると混乱しにくくなります。
内蔵ブラウザはWeb確認の境界を作る
内蔵ブラウザは、Webページを確認するための境界として便利です。公開ページの表示確認、ログイン不要のドキュメント確認、簡単なレスポンステスト、リンク切れ確認のような作業では、普段使いのブラウザよりもリスクを切り分けやすくなります。
一方で、実アカウント、社内管理画面、拡張機能に依存する操作、支払い、権限変更は別扱いにしてください。Appshots、内蔵ブラウザ、Computer Useは、似た名前の周辺機能としてではなく、次のように分けると運用しやすくなります。
| 観点 | Appshots | Computer Use | 内蔵ブラウザ |
|---|---|---|---|
| 主目的 | 前面ウィンドウの文脈共有 | GUIの確認と操作 | Webページ確認 |
| 操作の有無 | 共有だけ | 操作を含む | Web確認が中心 |
| 主なリスク | 画面とテキストの共有 | 誤操作、サインイン状態、クリップボード | ログイン情報、外部ページ |
| 記録すべきこと | 共有した画面種別と理由 | アプリ承認、操作内容、人間確認 | 対象URL、ログイン有無、確認結果 |
チームで決める権限と管理設定
前面ウィンドウの画像取得に関係するため、付与責任者と見直し時期を決めます。
利用可能なテキスト取得に関係するため、付与理由と確認方法を残します。
管理対象ユーザーでAppshotsを無効化する選択肢として確認します。
Computer Use、内蔵ブラウザ、MCP、ネットワークアクセス、承認ポリシーも一緒に見ます。
職種、プロジェクト、端末を絞り、必要なロールから小さく始める方が扱いやすくなります。
macOS権限は個人判断にしない
根拠
Appshotsでは、Codexが権限を求める場合があります。公式ドキュメントでは、画像取得にScreen & System Audio Recording、前面ウィンドウの利用可能なテキスト取得にAccessibilityが関係すると説明されています。どちらも、チーム導入では軽く扱えません。
確認項目
個人の開発端末で「必要そうだから許可した」で済ませると、後から誰が何を許可したのか分からなくなります。少なくとも次の項目は、導入前にチームの運用メモへ入れてください。
- Appshotsを使ってよい職種、プロジェクト、端末
- 許可してよい画面種別
- 禁止画面リスト
- macOS権限を付与する責任者
- 権限付与後の確認方法
- 退職、異動、端末返却時の権限見直し
全員に一律で許可する必要はありません。UIレビュー担当、ドキュメント整備担当、QA担当のように、画面文脈が成果に直結するロールから限定的に始める方が失敗しにくいです。
managed configurationで無効化する選択肢
根拠
OpenAIのmanaged configurationドキュメントでは、管理対象ユーザー向けにallow_appshots = falseを設定するとAppshotsを無効化できると説明されています。この設定は、Appshotsをチームで必ず使うためのものではなく、使わない判断を組織として実装するためにも重要です。
条件
たとえば、顧客データを頻繁に扱う受託開発チーム、金融や医療に近い領域、契約上のAI利用制限が強いプロジェクト、監査準備中の組織では、最初から無効化を検討してよいでしょう。導入検証をする場合も、全組織ではなく、低リスクの検証用ワークスペースだけに絞ります。
管理設定は、Appshotsだけを見ても足りません。Computer Use、内蔵ブラウザ、ブラウザ自動化、MCP、プラグイン、ネットワークアクセス、承認ポリシーを同じ表で棚卸ししてください。Appshotsを止めても、別機能から画面や外部サービスへのアクセスが残る場合があります。
# 管理対象ユーザーでAppshotsを無効化する例
allow_appshots = falseこの例は考え方を示すための最小形です。実際の設定場所、配布方法、他の管理項目との組み合わせは、OpenAIのmanaged configurationドキュメントと自社の端末管理ルールで確認してください。
承認ポリシーとサンドボックスも同時に見る
Appshotsは画面文脈の共有に関わりますが、Codexがコードを編集したりコマンドを実行したりする場面では、承認ポリシーとサンドボックスが別に効きます。OpenAIのAgent approvals & securityでは、サンドボックスはCodexが技術的にできること、approval policyはいつ承認を求めるか、という整理がされています。
Appshotsを許可するなら、次の問いも同時に確認してください。
- Appshotsを根拠にCodexがファイルを書き換える場合、どの範囲まで自動編集を許すか。
- ネットワークアクセスは必要か。必要なら許可先をどう絞るか。
- Appshotsで見せた画面に含まれる情報を、ログやプロンプトに残してよいか。
- 承認が必要な操作を、誰が、どのタイミングで見るか。
- 失敗時に、画面共有、提案、実行、レビューのどこで判断が崩れたか追えるか。
この観点は、AppshotsだけでなくAIエージェント全般に共通します。事故調査に使える形でログを残す考え方は、AIエージェントの実行ログ設計：trace・tool call・承認ログを事故調査に使える形で残すでも詳しく扱っています。
レビュー記録に何を残すか
- 1依頼前
画面種別、共有理由、禁止情報が含まれないことを確認します。
- 2Appshot添付
テキストだけでは伝えにくい状態だった理由を残します。
- 3Codexの提案
提案が画面の事実に対応しているかを見ます。
- 4人間レビュー
変更範囲、承認した操作、テスト、未確認事項を確認します。
- 5反映
差分、実行ログ、レビュー結果を後から追える形にします。
画像そのものを残すかは組織ルール次第でも、共有理由と機密確認は残しておくと説明しやすくなります。
Appshotを使った理由を残す
確認項目
Appshotsを使うたびに画像そのものを長期保存する必要があるかは、組織のルールによります。ですが、少なくとも「なぜAppshotsを使ったか」は残した方がよいです。後から見たときに、画面共有が必要だったのか、単に説明を省略しただけなのかを判断できるからです。
記録は、長い議事録でなくて構いません。次の4点があれば、レビューしやすくなります。
- 画面種別: 公開ドキュメント、ローカルエラー、デザインプレビュー、設定画面など
- 共有理由: テキストだけでは状態を伝えにくかった、UI差分が必要だったなど
- 機密確認: 顧客情報、認証、支払い、社内チャットが含まれていないこと
- 生成物との対応: そのAppshotを根拠に、どの修正や判断をしたか
この記録があると、Appshotsを使った作業が「なんとなく画面を見せた」から「必要な文脈を限定して渡した」に変わります。
承認ログと実行ログを分ける
根拠
Appshotsで共有した情報と、Codexが実行した操作は別の証跡です。Appshotsは、何を文脈として渡したかを示します。承認ログは、Codexが何を実行しようとして、人間がどこまで許可したかを示します。実行ログは、コマンド、テスト、差分、ツール呼び出しの結果を示します。
注意点
この3つを混ぜると、事故調査で詰まります。たとえば、UI画面を見せたこと自体が問題だったのか、見せた画面をもとにCodexが誤った修正を提案したのか、その後のコマンド実行を人間が見逃したのかを分けられません。
チーム運用では、最低限次のように分けて残してください。
| 証跡 | 残す内容 | 目的 |
|---|---|---|
| 共有判断 | Appshotsを使った理由、画面種別、機密確認 | 情報共有の妥当性を見る |
| 承認ログ | 編集、実行、ネットワーク、外部連携の承認 | 人間の関与点を見る |
| 実行ログ | 差分、テスト結果、失敗ログ、再実行結果 | 成果物と再現性を見る |
| レビュー結果 | 受け入れ、差し戻し、追加確認 | 品質判断を残す |
生成物だけでレビューを終えない
Appshotsを使った作業では、最終的なコード差分だけでなく、どの画面を根拠にしたかもレビュー対象です。画面の読み取りが間違っていれば、コードがきれいでも判断は崩れます。逆に、Codexが画面の情報を正しく使えていれば、レビューコメントはかなり短くできます。
レビューでは、次の順番で見ると効率的です。
- Appshotsを使う必要があったか。
- 見せた画面に余計な情報が入っていなかったか。
- Codexの提案が、その画面の事実に対応しているか。
- 実装差分が、画面から読み取れる問題に対して過剰でないか。
- テストや確認手順が残っているか。
Appshotsは、レビューを省くための機能ではありません。レビューの入口に、画面という追加根拠を置ける機能です。
結果：導入判断は共有範囲で決まる
便利な場面でも、共有範囲と証跡が曖昧なら導入を急がない判断で十分です。
使う価値が高い場面
Appshotsの価値が高いのは、言葉で説明しにくい状態を短く伝えたい場面です。UI崩れ、ローカルアプリのエラー、設定画面の項目、デザインプレビュー、公開ドキュメントの該当箇所などは、Appshotsによって説明時間を減らせる可能性があります。
特に、画面の状態とコード修正が一対一でつながるタスクでは相性が良いです。たとえば、フォームのラベルと実装のズレ、ビルド設定画面の項目名、ローカルプレビューで見える余白や順序、公開APIリファレンスのメソッド名などです。テキストで長く説明するより、画面を見せた方が認識合わせが早くなります。
導入を急がない方がよい場面
一方、顧客データや社内情報を頻繁に扱うチームでは、導入を急がない方がよいです。Appshotsは便利ですが、情報共有の面が広がります。画像とテキストの扱い、セッション内での保存、チームのログポリシー、端末権限、契約上のAI利用条件が整理されていない状態で使うと、あとから説明が難しくなります。
開発者個人が「この画面なら大丈夫」と判断する運用も避けたいところです。画面共有の判断は、ソースコードのレビューより曖昧になりやすいからです。禁止画面リストと例外フローを先に用意してから、限定ロールで検証してください。
判断表
| チームの状態 | 推奨判断 | 理由 |
|---|---|---|
| 公開情報やモック画面だけで検証できる | 小さく試す | Appshotsの価値とレビュー負荷を低リスクに測れる |
| 顧客情報や社内管理画面を日常的に扱う | ルール整備が先 | 禁止画面、例外許可、ログ保存方針が必要 |
| 監査、規制、契約上の制約が強い | いったん無効化を検討 | allow_appshots = falseを含む管理設定で止める選択肢がある |
| 画面操作まで任せたい | Computer Useとして別審査 | Appshotsは操作機能ではない |
失敗点とハマりどころ
利用可能なテキストも含み得るため、画像だけの共有として扱わないようにします。
先に禁止画面を決め、許可画面を狭く始める方が運用を続けやすくなります。
Appshotsの共有許可とComputer Useの操作許可を、別の承認として記録します。
利用上限、プラン条件、追加クレジット、レビュー時間を導入前に確認します。
禁止画面、承認範囲、費用確認は、使い始める前に決めておくほど見直しが楽になります。
スクリーンショットだけだと思い込む
最も危ない誤解は、Appshotsを普通のスクリーンショットと同じ扱いにすることです。公式ドキュメントでは、前面ウィンドウの画像に加えて、利用可能なテキストも含まれ得ると説明されています。見えている部分だけを気にしていると、テキスト側のリスクを見落とします。
ルールを書くときは、「画像として見えてよいか」だけではなく、「その画面から取得可能なテキストが一部渡ってもよいか」を入れてください。判断に迷う場合は、Appshotsではなく、伏せ字にしたテキスト説明や再現用スクリーンショットを使います。
禁止画面を後から作る
導入後に問題が起きてから禁止画面を作ると、現場はすでに便利な使い方を覚えています。制限を後から入れるほど反発も増えます。最初に禁止画面を明文化し、許可画面を狭く始める方が、結果的に使い続けやすくなります。
禁止画面は、細かすぎるアプリ単位ではなく情報種別で書きます。顧客情報、認証情報、支払い情報、社内チャット、人事情報、個人予定、監査対象の管理画面のように、見た人が判断しやすい言葉にしてください。
AppshotsとComputer Useの承認を同じにする
Appshotsを許可することと、Computer Useでアプリ操作を許可することは違います。前者は情報共有、後者は操作を含む可能性があります。両方を同じ承認フローにすると、どこまで許可したのかが曖昧になります。
承認画面や設定名が似ていても、運用台帳では分けてください。Appshotsは「共有画面」、Computer Useは「対象アプリ」「許可操作」「人間確認」「停止条件」まで記録します。
料金確認を最後に回す
Appshotsそのものの操作感に注目すると、料金や利用上限の確認が後回しになります。Codexの利用上限やプラン条件は、モデル、ローカル利用、クラウドタスク、追加クレジットなどの条件と絡みます。個人の試用では問題なくても、チームで日常利用すると想定より早く上限に近づく可能性があります。
料金を本文で断定的に覚えるより、導入チェックに「公開前と導入時に公式pricingを見る」を入れる方が安全です。予算管理やCreditsの扱いは、Codexクレジットを使う前に：Students・OSS Fund・追加購入の条件と予算管理のような予算記事と合わせて確認すると判断しやすくなります。
実務で使うなら
- Day 1
許可画面と禁止画面を決め、迷った画面は使わないルールにします。
- Day 3
公開docs、ローカルエラー、モック画面だけで試し、Appshotsを使った理由を毎回残します。
- Week 1
レビュー時に共有判断と生成物を照合し、差分だけで終わらせないようにします。
- Week 2
説明時間、修正精度、レビュー負荷、リスクを比べ、継続、制限、無効化を判断します。
例外が増える場合は、匿名化手順や低権限の検証環境を先に整えます。
2週間だけ低リスクに試す
最初の導入は、2週間の小さな検証で十分です。目的は、Appshotsが本当に説明時間を減らすか、レビューが楽になるか、禁止画面ルールが現場で守れるかを見ることです。いきなり全社展開すると、便利さの評価と情報管理の評価が混ざります。
おすすめの進め方は次の通りです。
| 時期 | やること | 成功条件 |
|---|---|---|
| Day 1 | 許可画面と禁止画面を決める | 迷った画面は使わないルールにできている |
| Day 3 | 公開docs、ローカルエラー、モック画面だけで試す | Appshotsを使った理由を毎回残せている |
| Week 1 | レビュー時に共有判断と生成物を照合する | 差分だけでなく根拠画面を確認できている |
| Week 2 | 継続、制限、無効化の判断をする | 説明時間、修正精度、レビュー負荷、リスクが比較できている |
検証中に「便利だから例外で使いたい」が増えるなら、導入を急がない方がよいサインです。例外が必要な理由を集めて、専用の匿名化手順や低権限の検証環境を先に作ってください。
Appshots依頼テンプレート
チームで使う場合は、依頼文の型を決めておくとログが揃います。たとえば、次のような短いテンプレートで十分です。
Appshotの画面種別: 公開APIドキュメント / ローカルエラー / モックUI / 設定画面
機密確認: 顧客情報、認証、支払い、社内チャット、個人情報は含まれていません
依頼内容: この画面を根拠に、最小の修正案と確認コマンドを提案してください
制約: ファイル編集前に変更対象を列挙してください。外部通信はしないでください
完了条件: 差分、確認結果、残リスクを短く報告してくださいポイントは、Appshotを添付する前に機密確認を文章にすることです。これだけで、なんとなく使う頻度を下げられます。
レビュー担当が見るチェックリスト
レビュー担当は、コード差分だけを見ず、Appshotsの使い方も確認します。
- Appshotsを使う必要があったか
- 画面種別は許可範囲内か
- 禁止情報が含まれていないか
- Codexの提案が画面の事実に対応しているか
- 変更範囲が過剰でないか
- テスト、確認コマンド、未確認事項が残っているか
- 次回からテキスト説明やログ添付で代替できないか
このチェックリストをPRテンプレートや作業完了報告に入れると、Appshotsが「便利なショートカット」ではなく「限定された根拠共有」として定着しやすくなります。
セキュリティ・コスト注意
顧客名、契約条件、社内会話、個人予定は、画面の文脈だけで機密になる場合があります。
セッション、端末バックアップ、ログ保管、端末返却時の削除方針を確認します。
Codexのプラン、モデル、クラウドタスク、追加クレジットの条件を導入時に見直します。
説明時間が減っても、禁止画面チェックや証跡確認が重くなる場合があります。
コストは課金だけでなく、確認に使う人間の時間も含めて判断します。
秘密情報を見せないだけでは足りない
Appshotsで気をつけるべきなのは、APIキーやパスワードだけではありません。顧客名、社内チャット、未公開ロードマップ、営業資料、個人予定、契約条件、障害対応メモも、見せてよいとは限りません。画面に直接秘密情報が出ていなくても、文脈から顧客や案件が推測できることがあります。
そのため、禁止リストには「秘密情報」だけでなく「顧客、契約、認証、支払い、人事、社内会話、個人予定」を入れてください。Appshotsは画面の文脈を渡す機能なので、文脈そのものが機密になる場合があります。
保存とログの扱いを決める
公式ドキュメントでは、Appshotsは手動添付したファイルや画像のように、セッションファイルにローカル保存されると説明されています。ここで大事なのは、ローカルに保存されるから安全、とは言えない点です。チームでは、端末バックアップ、ログ保管、セッション共有、フィードバック送信、端末紛失時の扱いまで含めて考えます。
すべてを厳密に決める必要はありませんが、少なくとも次の質問には答えられる状態にしてください。
- Appshotsを含むセッションを誰が閲覧できるか
- セッションファイルやログをどの期間残すか
- 画像そのものをレビュー記録に残すか、画面種別だけを残すか
- 端末を返却、廃棄、再割り当てするときに何を削除するか
- 問題が起きたとき、共有判断と実行判断を分けて追えるか
コストは「利用上限」と「レビュー時間」で見る
Appshotsのコストは、単純な機能の有無だけでは判断できません。Codexの利用上限、プラン、モデル、ローカル利用、クラウドタスク、追加クレジット、チームのレビュー時間が関係します。公式pricingには、プランごとの利用条件やAPIキー利用の扱いが整理されていますが、条件は変わり得ます。
導入前に見るべきコストは2つです。ひとつはCodex側の利用上限や課金です。もうひとつは、Appshotsを使った作業をレビューする人間の時間です。画面共有によって説明時間が減っても、禁止画面チェックや証跡確認が重くなるなら、チーム全体では安くなっていない可能性があります。
FAQ
同じ扱いにはせず、画像と利用可能なテキストを含み得る共有として見ます。
新しいAppshotはmacOSのCodex appから作る機能として扱います。
別機能として扱い、Appshots自体の許可、権限、禁止画面、共有ログを確認します。
管理対象ユーザーでは、managed configurationでAppshotsを無効化する選択肢があります。
画面種別、共有理由、機密確認、承認した操作、実行結果、人間レビューを分けて残します。
機能の境界と証跡の分け方をそろえると、導入後の説明がしやすくなります。
Appshotsはスクリーンショットと同じ扱いでよいですか？
同じ扱いにはしない方が安全です。Appshotsは前面ウィンドウの画像に加えて、利用可能なテキストも含み得ます。画面外の全文が常に渡ると決めつける必要はありませんが、画像だけより広い情報共有として扱う方が実務では安全です。
CLIでも新しいAppshotを作れますか？
公式ドキュメントでは、AppshotsはmacOSのCodex appから作成する機能として説明されています。Appshotを含むスレッドをCLIで再開した場合、その添付はスレッド履歴に含まれますが、CLIから新しいAppshotを作ることはできないとされています。
Computer Useを無効にすればAppshotsのリスクも消えますか？
別機能として扱ってください。Computer Useはアプリの確認や操作に関わりますが、Appshotsは画面文脈の共有に関わります。Computer Useの許可を絞っても、Appshots自体の許可、macOS権限、禁止画面、共有ログは別に確認が必要です。
管理者はAppshotsを止められますか？
管理対象ユーザー向けには、managed configurationでallow_appshots = falseを設定してAppshotsを無効化できると説明されています。一般ユーザーの手元設定と混同せず、組織で管理しているCodex環境にどう適用するかを確認してください。
どのログを残せばよいですか？
画像そのものを残すかは組織の情報管理ルールによります。最低限、画面種別、Appshotsを使った理由、機密確認、Codexが出した提案、承認した操作、実行結果、人間レビューの判断を分けて残すと、後から追いやすくなります。
次に読むなら
参照した主な情報源
- OpenAI Codex Appshots: https://developers.openai.com/codex/appshots
- OpenAI Codex Changelog: https://developers.openai.com/codex/changelog
- OpenAI Codex Computer Use: https://developers.openai.com/codex/app/computer-use
- OpenAI Codex Managed configuration: https://developers.openai.com/codex/enterprise/managed-configuration
- OpenAI Codex Pricing: https://developers.openai.com/codex/pricing
- OpenAI Codex Agent approvals & security: https://developers.openai.com/codex/agent-approvals-security
更新履歴
- 2026-06-17
OpenAI Codex Appshots、Changelog、Computer Use、Managed configuration、Pricing、Agent approvals & securityを確認して初版を作成しました。
仕様や料金は変わり得るため、導入時は最新の公式情報を再確認します。
- 2026-06-17: OpenAI Codex Appshots、Changelog、Computer Use、Managed configuration、Pricing、Agent approvals & securityを確認し、初版を作成しました。X/Twitterは需要シグナルとしてのみ扱い、技術的な根拠には使っていません。