アクセスできる画面を見つけたのに、契約範囲、保存先、外部接続の実態を説明できない。
最短の解決策は、OpenAI Astra for Lawの顧客機密をすぐに許可せず、資格確認とデータ経路の証拠をそろえたうえで、低リスク案件だけを管理下で試験することです。ZDR、法律検索、Codex、プラグイン、将来のAPIは、それぞれ別の検収対象です。
最終更新：2026年9月18日。OpenAIの製品案内、ヘルプセンター、APIデータ管理資料を基に確認しています。
この判断が必要なのは、Astra for Lawを評価する法律事務所のIT・セキュリティ責任者、Codexやプラグインで法律Agentを構築する開発チーム、そして全面導入か待機かを決めるパートナーやイノベーション責任者です。ベンチマークの印象ではなく、顧客ファイルをどこへ出し、誰が読み、どう削除できるかを確認したい人を対象にしています。
限定公開と全面利用を混同しない
間違った前提
「Astra for Lawの案内が表示されたので、すべての法律チームが使える」と判断するのが最初の危険です。2026年9月17日の発表時点で、初期提供は米国の一部法律事務所を対象に、Trusted Access、ChatGPT、Codexを通じて行われています。これは全面的な一般提供を意味しません。
OpenAIのAstra for Lawに関する公式ヘルプで、所属組織が対象か、利用する製品入口が何か、契約上のデータ管理条件が何かを確認してください。「GPT-6 Astra Law」という検索語で別製品の存在や一般公開を推測することも避けます。
合格に必要な証拠
次の記録を同じ案件フォルダーに保存します。
- Trusted Accessの対象組織と対象ユーザー
- ChatGPT、Codex、将来のAPIのうち、実際に許可された入口
- 契約書とデータ処理条件
- 管理者が確認した日付、対象地域、対象データ分類
- 画面に表示された機能と、実際に利用できた機能の差分
書面による資格確認や製品入口が取れない場合は、公開資料だけの評価に戻します。顧客名、事件番号、提出前文書、非公開の社内知識を投入してはいけません。
ZDRと顧客ファイルの保存範囲を分けて確認する
「ZDRなら安全」という前提
Zero Data Retention（ZDR）は重要なデータ管理条件ですが、顧客機密を自動的に扱える許可ではありません。少なくとも、モデル学習への利用、乱用監視のログ、アプリケーション状態、法律事務所が指定する保存先は、別々に確認する必要があります。
OpenAIの企業向けデータ管理の説明では、企業データの取り扱い条件が製品や契約によって異なることが示されています。また、エンドポイント別のデータ利用ポリシーを読み、対象の入口にZDRが適用されるかを確認してください。製品名にZDRの表示があることだけでは、プラグイン側の保存や外部サービスのキャッシュまで証明できません。
顧客ファイルを投入する前の確認
ファイルアップロードでは、送信先、処理中の一時保存、会話履歴、削除操作、バックアップ、外部接続先を順番に記録します。顧客ファイルが「学習に使われない」と確認できても、案件担当者の画面や外部アプリに残る可能性は別に評価します。
注意：ZDRは職業上の守秘義務、依頼者の同意、情報分類、地域要件を置き換えません。最終的な利用可否は、契約条件と所属する司法管轄の職務規則を照合して決めてください。
検索の正確さと納品可能な法律意見を混同しない
検索結果が正しそうでも不十分な理由
法律検索で引用が表示されたことは、そのまま意見書を納品できる証拠ではありません。司法管轄、判決後の変更、後続判例、不利な根拠、引用箇所の文脈を人が確認しなければ、検証済みの法的根拠にはなりません。
評価時には代表的な研究課題を固定し、入力文、検索結果、引用段落、担当弁護士の確認、訂正履歴を保存します。公式検証セットの成績を、個別案件の正確性保証へ外挿してはいけません。重要な根拠を独立して確認できない場合、Astra for Lawは研究補助に限定し、最終意見の根拠にはしません。
作業を3段階で分ける
- 公開判例や公開規則だけで検索品質を確認する
- 匿名化した過去資料で引用と反対根拠の確認を行う
- 承認済みの低リスク案件で、弁護士の逐次レビューを付ける
各段階で、誤引用、古い資料、引用元の欠落があれば、次の段階へ進めずに回退します。
プラグインの権限と案件システムの権限を分離する
接続しただけでは案件権限を継承しない
文書管理、案件管理、法律検索のプラグインを接続すると、読み取り、書き込み、キャッシュ、権限撤回という別々のデータ経路が生まれます。ChatGPTワークスペースでユーザーを制限しても、外部システムのトークンや共有フォルダーまで同じ制限になるとは限りません。
ChatGPTでアプリのアカウントを接続・管理する公式説明を確認し、接続単位、再認証、撤回方法、管理者ログを確認します。特に倫理壁や案件ごとの閲覧制限が、検索結果と添付ファイルの双方に適用されるかを検証してください。
不合格にする操作
次の操作を個別に試験します。
- 読み取り専用の案件検索
- ファイルの保存
- 既存文書の内容変更
- 複数案件を横断した検索
- 権限撤回後の再アクセス
- 期限切れトークンでの再実行
データの移動先を説明できない、撤回後も取得できる、案件間の分離を再現できないプラグインは、機密事項の試験から外します。
Codexの実行権限を文書リスクとして扱う
モデル回答とファイル操作は別の危険度です
Astra for Lawの回答、Codexによるコード・ファイル操作、外部ツール呼び出し、OS権限は分けて管理します。Codexが法律文書を一括処理する場合、単なる文章生成ではなく、作業ディレクトリ、テンポラリファイル、資格情報、ネットワーク出口、削除処理までがリスクになります。
Codexの会話を保存・削除する方法は、Codexチャットのアーカイブと削除に関する公式説明で確認できます。ただし、会話の削除だけで作業環境や外部保存先が消えるとは限らないため、実行環境側の記録も必要です。
独立環境で確認する5段階
- 顧客データを含まない検証用ファイルを用意する
- 作業ディレクトリと正式な文書システムを分離する
- 一時資格情報、ネットワーク出口、手動承認を設定する
- 正常終了、拒否、途中停止、異常終了を再現する
- タスク終了後にファイル、ログ、資格情報、キャッシュを点検する
本番ファイルシステムと一般開発タスクを同じ作業領域に置く設計は避けます。内部法律Agentを試す場合も、生成環境から正式案件へ直接書き込ませず、人が承認した成果物だけを移送します。
APIの予定と現在の本番接続を混同しない
今すぐ作るのは接続層まで
2026年9月18日時点で、APIは「今後提供予定」とされており、一般の開発チームが利用できる本番エンドポイントや公開時期を推測できる状態ではありません。したがって、現段階でモデル名、料金、割当量、ZDR対応、プラグイン代替機能を決め打ちして設計しないでください。
今できる準備は、データ分類、入力を匿名化する層、評価セット、監査ログ、失敗時の回退、将来のAPIに差し替えられるインターフェースです。APIが開放された後に、資格、ZDR適用、状態保存、外部ツール、1件あたりの総コストを再検収します。
最終判定を3つに分ける
以下のチェックリストを、担当者名と証拠の保存先付きで埋めます。
- [ ] 組織がTrusted Accessの対象であることを文書で確認した
- [ ] ChatGPT、Codex、プラグインごとの入口と契約範囲を記録した
- [ ] 顧客ファイルの送信、保存、削除、外部転送の経路を図にした
- [ ] ZDRの適用対象を契約条件とプロジェクト設定の両方で確認した
- [ ] 代表的な法律検索について、引用と不利な根拠を弁護士が確認した
- [ ] 読み取り、書き込み、案件横断検索、権限撤回を別々に試験した
- [ ] Codexの作業領域、資格情報、ネットワーク出口、終了後清掃を検証した
- [ ] 失敗時に公開資料評価へ戻す手順を決めた
- [ ] APIの未確定情報を本番仕様として文書化していない
合格証拠がそろえば、公開資料のみの試用から、受け入れた低リスク案件の限定試験へ進めます。データ経路、契約、正確性、隔離のいずれかを説明できなければ、導入保留です。
経験則：法律専用モデルという名称より、案件単位で「誰が、どの入口から、何を読み、どこへ書き、いつ撤回できるか」を再現できることを優先してください。
現在の構成が個人端末や共有開発環境に依存している場合、案件ファイルが通常の開発資料と混ざる、権限撤回を即時に再現できない、Codexの一時ファイルや外部接続を追跡しにくいという欠点が残ります。こうした状態で長期運用へ進むより、まずはMacPullのヘルプ情報とMacレンタルの料金案内を確認し、承認済みの低リスク課題だけを独立したクラウドMac環境で試す方が、検証範囲と撤回手順を切り分けやすくなります。
Astra for Lawの資格とデータ境界を確認したうえで、顧客機密を含む試験を行うなら、物理端末の共有を避け、作業環境、権限、終了後の削除を記録できる構成を選んでください。長期的な高負荷処理や物理インターフェースが必要な業務は自社設備が適する場合もありますが、短期の評価、限定された法律Agent、Codexの隔離検証であれば、MacPullのレンタル環境を比較対象に入れる価値があります。