3行でいうと

  • AIの呼び出しの記録は、標準で「本文まで」残る設定のものがあります。OpenAIのAgents SDKのトレースは、入力と出力を保存するのが既定です。AmazonのBedrockは、記録の機能が標準ではオフですが、オンにすると依頼と返事の本文が残ります。
  • 個人情報を伏せる仕組みは、公式が「確率的」「全部は見つけられない」と書いています。AmazonのフィルターはAIに入力した文章を伏せても、自分の記録（ログ）の本文までは伏せない、と明記されています。
  • 設計の基本は、記録を「誰が・いつ・どのモデルで・どれだけ使ったか」の部分と、「本文」の部分に分けることです。本文は、残す必要があるときだけ、伏せたうえで、期限を決めて残します。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。情報は2026年10月16日に確認しました。変わることがあります。法律や契約の助言ではありません。

先に結論

②自分のアプリが残す記録

Amazon Bedrock：モデル呼び出しの記録

AWSの文書によると、Bedrockの「モデル呼び出しの記録」は、標準では無効です。有効にすると、Converseなどの呼び出しについて、依頼の本文と返事の本文、それにメタデータが、S3やCloudWatch Logsに保存されます。

記録には、呼び出した人のIAMの識別情報（identity.arn）、モデルID、入力と出力のトークン数なども入ります。自分で付けられる任意のタグとして、requestMetadataがあります。有効にした記録は、記録の設定を消すまで残る、と書かれています。保存期間そのものは、このページには書かれていませんでした。

つまり、この機能は「誰が・いつ・どのモデルで・どれだけ」という監査に必要な情報と、「本文」という、個人情報が入りうる情報を、同じ記録の中に入れます。

OpenAI Agents SDK：トレース

OpenAIのAgents SDKの文書によると、トレース（処理の流れの記録）は、既定でオンです。モデルの呼び出し（生成）や関数の呼び出しの記録には、入力と出力が入り、trace_include_sensitive_dataの既定はTrueです。オフにする場合は、実行ごとの設定か、環境変数で指定します。トレース自体を止める方法もあります。なお、OpenAIのAPIをゼロデータ保持の方針で使う組織では、トレースは使えない、とも書かれています。

記録を外に出す前に伏せたい場合のために、独自の処理（trace processor）を差し込む仕組みがあります。ここに、注意が書かれています。処理の中で例外が出ても、ほかの処理は続けて動きます。そのため、「伏せる処理を先に置けば、あとの出力先には伏せたものだけが行く」とは限りません。文書は、伏せる処理を、出力先の中に持つ方法を勧めています。伏せるのは写しに対して行い、伏せるのに失敗したら、その分を捨てる、という書き方です。

Bedrockのモデル呼び出しの記録の仕様（公式の記載）

AWSの文書（2026年10月16日に読んだ時点）によると、次のとおりです。

  • 対象は、bedrock-runtimeのエンドポイントのConverseなど4つの操作です（一覧は公式ページで確認してください）。同じ文書は、別のエンドポイント（bedrock-mantle）経由の呼び出しは記録されない、と書いています。
  • 保存先は、S3とCloudWatch Logs。保存先は、同じアカウント、同じリージョンの中に限られます。
  • 本文は、100KBまではそのまま記録に入ります。それを超える分や、画像などのバイナリは、S3に置かれます。
  • 暗号化：S3は、KMSの鍵（SSE-KMS）を使うことができます。CloudWatch Logsについては、AWS KMSで暗号化できると書かれ、詳しくは別のページを見るように、とあります。
  • この文書は、機微な情報についての明確な警告は書いていません。本文が全部入ることから、保存先へのアクセス権を絞ることが必要だ、というのは僕らの推測です。

③個人情報を伏せる

Amazon Bedrock：機微情報のフィルター

AWSの機微情報フィルターは、依頼や返事の中の個人情報を見つけて、止める（ブロック）か、置き換える（マスク）か、見つけるだけにする（検出）かを選べます。検出は確率的なもので、前後の文脈に左右される、と書かれています。

公式の文書が、はっきり書いている限界は次のとおりです。

つまり、「AIに渡す文章」を伏せても、「自分の記録」は、別に守らなければなりません。

Presidio：オープンソースの個人情報の検出と伏せ字

Presidioは、文章や画像の中の個人情報を見つけて、伏せるためのオープンソースのツールです。公式のサイトによると、検出は、固有表現抽出（NER）、正規表現、ルール、チェックサムなどを組み合わせて行い、見つける部分（analyzer）と、伏せる部分（anonymizer）に分かれています。

サイトのトップは、自動の検出なので、すべての機微な情報が見つかる保証はなく、追加の仕組みや保護と組み合わせるように、と明記しています。

伏せ方の演算子は、置き換え（replace）、削除（redact）、一部を伏せ字に（mask）、ハッシュ（hash）、暗号化（encrypt）、自作（custom）、そのまま（keep）です。このうち、元に戻せるのは、暗号化を復号する場合だけで、ほかは戻す方法が書かれていません。ハッシュの塩（salt）は、既定でエンティティごとにランダムになります。Presidioは状態を持たないので、同じ値に同じ結果が欲しいときの塩の管理は、利用者側の仕事だと僕らは読みました。

Bedrockの個人情報の種類とPresidioの演算子（公式の記載）

Bedrockの機微情報フィルター（2026年10月16日に読んだ時点）

  • 定義済みの種類は31です（WebFetchの要約が一覧を数えた数で、公式の文書に数は書かれていません。内訳は確認できていません）。日本固有の番号（マイナンバーなど）は、一覧にありませんでした。
  • 自分で正規表現も定義できます。名前は1〜100文字、パターンは1〜500文字、説明は1,000文字まで。先読み・後読み（lookaround）は使えません。
  • APIの動作はBLOCK、ANONYMIZE、NONE。入力と返事で、別々に動作を決められます。

Presidio（2026年10月16日に読んだ時点）

  • replace：置き換え。redact：消す。mask：一部を伏せ字に。hash：sha256（既定）かsha512。塩は16バイト以上が必要。
  • encrypt：鍵で暗号化。戻すのはdecryptだけ。
  • 範囲が重なったときの扱いも決まっています（細目は公式ページで確認してください）。
  • 2.2.361以降、ハッシュの塩は、既定でエンティティごとにランダムになりました。

何を残し、何を消すか（見立て）

ここからは僕らの見立てです。公式の文書の記載を踏まえて、整理しました。

項目 見立て 理由
日時、リクエストID、呼び出した人（IDなど）、モデルID・版、入力と出力のトークン数 残す 費用の配分、障害の調査、後からの確認に必要で、個人情報の可能性が低い（ただし、識別子が個人を指すなら、それ自体が個人情報になりうる）
検査の結果（どの検査で、止めたか通したか） 残す ガードレールの見直しの材料になる
依頼と返事の本文 原則、残さない。残すなら、伏せたうえで、期限つき 個人情報や秘密が入りうる。OWASPも、入力の検証と、検出した機微な内容の伏せ字を、対策に挙げている
道具の引数と結果 残すなら、本文と同じ扱い Bedrockの機微情報フィルターは、ここを調べないと明記している
誤りの再現に必要な本文 一時的に、アクセスを絞って 調査用と、通常の運用の記録を、分ける

OWASPのLLM02の文書は、データの掃除（原文では主に学習に使う前の処理として書かれています。スクラブ、マスク）、入力の検証、権限の最小化、保存と削除の方針の公開などを対策に挙げています。また、システムの指示で「このデータは扱うな」と書くだけでは、守られない場合がある、とも書かれています。伏せる処理は、AIの外に置く、という考え方につながります。

①AIの提供元の側に残るもの

別の記事で詳しく扱っているので、ここでは、読んだ範囲の数字だけを書きます。

OpenAIの文書は、API利用で不正利用の監視のための記録が、標準では最長30日残ると書いています。ゼロデータ保持（ZDR）やModified Abuse Monitoringは、事前の承認が必要です。Anthropicの案内（2026年7月1日付）は、APIの入力と出力を、30日以内に自動で削除すると書いています。ただし、自動の安全システムにフラグされた入力と出力は最長2年、分類の点数は最長7年、など例外があります。

提供元の保存期間の数字（公式の記載）

OpenAI（2026年10月16日に読んだ時点。ページの末尾約1万字は読めていません）

  • 2023年3月1日以降、APIのデータは、利用者が共有を選ばない限り、学習に使われません。
  • chat/completionsとresponsesは、不正利用の監視の記録が最長30日。
  • files、batches、fine_tuningなどは、削除するまで残るものがあり、ZDRの対象外です。
  • ZDRは、storeを強制的にfalseにします。ただし、ZDRの対象でない機能は、ZDRが有効でも状態を保存することがあります。
  • 米国以外のリージョンでデータの所在地を指定するには、不正利用監視の制御（MAM）などの承認が必要で、ZDRも条件の一つとされています。

Anthropic（2026年7月1日付の案内を、2026年10月16日に読みました）

  • API：30日以内に削除。ただし例外があります（下の2つを含みます。細目は公式ページで確認してください）。
  • 自動の安全システムにフラグされた入力と出力：最長2年。分類の点数：最長7年。
  • フィードバックのデータ：5年。

よくある落とし穴

気をつけること

出典

更新履歴