はじめに

2026年9月18日、Z.ai（旧 Zhipu AI）の AI コーディングツール ZCode の利用者が、同社のフィードバック用リポジトリに issue を立てました。ログインした状態で使っていると、ZCode のデスクトップ版がワークスペースを .git ディレクトリごと固めて暗号化し、クラウドへ送る仕組みを持っている——という報告です。同じ日のうちに、別の利用者が別のマシンで同じ仕組みを確かめたと書き込み、さらに詳しい質問の issue も立ちました。

そこからの動きは速いものでした。9月19日には公式の更新履歴に v3.14.0 が載り、バグ修正の欄に「repository wiki の異常なアップロードを修正」と書かれました。9月20日には ZCode のソースコードが Apache-2.0 で GitHub に公開されています。報道によれば、同社は 9月21日に謝罪し、第三者機関の評価結果も示しました。

このニュースを「怖い話」で終わらせるのはもったいない、と筆者は考えています。ZCode は OSS 化によってコードを読んで確かめられる対象になりました。そして、同じ問いは手元の Claude Code や Gemini CLI、Cursor にも向けられます。エージェントに渡す範囲を、自分で決めて、自分で確かめられる状態を作ること。それがこの記事のゴールです。

扱うのは次の 4 点です。

  1. ワークスペース同期／スナップショットとは — ローカル実行型とクラウド同期型で、エージェントが「持ち出すもの」はどう違うのか
  2. ZCode で何が起きたか — issue・公開ソース・公式の更新履歴で確かめられる範囲と、報道で伝えられている範囲
  3. .git に「消したはずの秘密」が残る理由 — objects・reflog・隠し ref の仕組み
  4. 自分のエージェントの送信範囲を確かめる手順 — 公式ドキュメント・ローカルのデータ・通信の観察・渡す範囲の絞り方
⚠️ 情報源の区別と時点

本記事は 2026年9月23日に取得した資料にもとづきます。一次資料として扱うのは、GitHub の issue #707・#709、公開リポジトリ zai-org/ZCode（コミット 872ad96）、ZCode 公式サイトの更新履歴とプライバシーポリシー、各ツールの公式ドキュメントです。同社の謝罪・第三者評価の内容は同社の X 投稿として報じられたもので、本記事では IT之家と InfoWorld の報道から引き、「報道によれば」と明記します。送信量やファイル数などの数値は利用者の報告と第三者の解析記事によるもので、同社が認めた数字ではありません。issue の報告者は個人のため、名前やアカウントは記しません。

📌 この記事の3行まとめ
  • 利用者の報告によれば、旧版の ZCode はログイン中にワークスペースを .git ごとまとめて暗号化し、クラウドへ送る仕組みを持っていた。 設定の 2 つのスイッチを切っても動いたという。9月19日の v3.14.0 で修正され、9月20日にソースが Apache-2.0 で公開された
  • .git には、今のファイルから消した秘密も残る。 過去のコミットの objects、操作履歴の reflog、ツールが作る隠し ref が中身を抱え続けるからだ。漏れた秘密は、履歴を書き換える前にまず失効させる
  • 自分のエージェントも同じ問いで確かめられる。 公式ドキュメントの「送るもの・止め方」を表にし、データディレクトリと通信先を眺め、プロキシで中身を見て、ignore と deny で渡す範囲を絞る

🧭 1. ワークスペース同期／スナップショットとは — エージェントが「何を持ち出すか」の設計

エージェントはワークスペースを読んで動く

AI コーディングエージェントは、プロジェクトのフォルダ（ワークスペース）の中のファイルを読み、コマンドを実行し、コードを書き換えます。このとき、ファイルの中身のどこまでがネットワークの向こうへ出ていくかは、ツールの設計によって大きく違います。

大きく分けると 2 つの型があります。

  • ローカル実行型：エージェント本体は手元の PC で動き、LLM に問い合わせるときだけ、プロンプトと、その場で必要になったファイルの断片を送る
  • クラウド同期型：ワークスペースの全体（またはその写し）をクラウドへ送り、向こう側で索引を作ったり、別の機械で作業したりする
flowchart TB W["ワークスペース"] --> A["ローカル実行型
手元のエージェントが読む"] W --> B["クラウド同期型
全体の写しを作る"] A -->|"プロンプト＋必要な断片"| A2["LLM の API"] B -->|"写しを丸ごと"| B2["クラウドの保管庫
索引・Wiki・リモート実行"]

どちらが正しい、という話ではありません。クラウド同期型にも、巨大なリポジトリを横断して検索できる、別の機械で作業を続けられる、といった利点があります。大事なのは、どちらの型なのか、何を送るのかが利用者に見えていて、選べることです。

スナップショットとチェックポイント

ワークスペースの「その時点の状態」を丸ごと記録したものをスナップショットと呼びます。エージェントの世界では、よく次の 2 つの用途で使われます。

  • チェックポイント（巻き戻し）：エージェントがファイルを書き換える前の状態を記録しておき、失敗したら戻す
  • 同期・索引：記録した写しをクラウドへ送り、検索用の索引やドキュメント生成に使う

前者は手元だけで完結できます。後者は送らなければ成り立ちません。同じ「スナップショット」という言葉でも、手元に置くのか送るのかで意味がまるで違う、というのが今回の話の芯です。

💡 ワード解説：アーカイブ・暗号化・エンベロープ暗号

スナップショットを送るときは、ファイル群を 1 つのアーカイブ（tar.gz など）にまとめ、暗号化するのが一般的です。エンベロープ暗号は、ファイル本体をランダムな共通鍵（AES など）で暗号化し、その共通鍵を受け取り手の公開鍵（RSA など）で包む方式です。通信途中や保管中の盗み見は防げますが、秘密鍵を持つ受け取り手は中身を読めます。「暗号化されているから安心」かどうかは、誰が鍵を持つかで決まります。

🔍 2. ZCode で何が起きたか — issue・公開ソース・公式更新履歴で確かめられること

時系列

flowchart TB D1["9月18日
利用者が issue を 2 件立てる
第三者の解析記事が公開"] --> D2["9月19日〜20日
v3.14.0 を公開
ソースを Apache-2.0 で公開"] D2 --> D3["9月21日〜22日
報道によれば同社が謝罪
v3.14.1・v3.14.3 を公開"]

日付は issue とリポジトリ（UTC）、公式の更新履歴、報道の日付によります。

利用者の報告：何が、いつ、どこへ

issue #707 と、そこに寄せられた別の利用者の検証、#709、第三者の解析記事を突き合わせると、旧版（報告では macOS 版 3.12.3・Linux 版 3.10.0 など）について次のような仕組みが報告されています。

項目 報告されている内容
条件 デスクトップ版でログインしていること（ログイン時の認証トークンがあること）
タイミング プロンプトを送る前、タスクの終わりなど。1 セッションで最大 62 回という記録も
対象 ワークスペースのファイルと .git ディレクトリ全体（objects・logs・refs・LFS のキャッシュ）、全体設定（MCP・hooks・skills など）の写し
手元の痕跡 ~/.zcode/v2/checkpoints/ の下に、ファイル一覧（manifest）と状態ファイル。受け付け済みの印として lastAcceptedManifestHash
暗号化 AES-256-CTR で本体を暗号化し、サーバーから配られた RSA 公開鍵で鍵を包む（利用者側では復号できない）
送り先 サーバーから一時的なアップロード用の証明書を受け取り、クラウドのオブジェクトストレージへ直接送る
スイッチ 設定の repoSnapshotIndexingEnabled と optimizeAgentExperienceEnabled を false にしても動いた

解析記事の書き手が手元で数えた例では、ある商用プロジェクトのスナップショットは 42,411 ファイルで、その 86.6% が .git（LFS のキャッシュ 56.8%・objects 29.6%・reflog 0.2%）でした。このときの 313MB の暗号化ファイルは送信に失敗し続けて手元に残り、送られていなかったと記事は書いています。一方で、538 ファイルの小さな公開リポジトリのスナップショットは、サーバーに受け付けられた状態だったとしています。

公式の一次資料に書かれていること

更新履歴：ZCode 公式サイトの更新履歴には、v3.14.0（2026年9月19日リリース）のバグ修正として次の 1 行があります。

Fixed an issue with abnormal uploads in the repository wiki

プライバシーポリシー：9月23日時点の版も施行日は 2026年6月15日のままです。収集するものとして「会話を通じて提出されたテキスト・ファイル・コード」は挙げていますが、ワークスペースのスナップショットや .git の送信を指す記述は見当たりません。

公開されたソース：9月20日に作られた zai-org/ZCode は Apache-2.0 で、コミットは 2 つ（空の初期コミットと、6,973 ファイル・103 万行を一度に入れた feat: open source）です。9月23日時点で issue は無効、プルリクエストの作成は共同作業者だけに限られています。

OSS 化で、コードを読んで確かめられるようになったこと

ソースが公開されたことで、第三者が同じコードを読んで確かめられるようになりました。筆者がコミット 872ad96 を取得して検索した範囲では、次のことが言えます。

  • issue で指摘された送信経路の識別子は見当たらない：repo_snapshot_manifest・lastAcceptedManifestHash・tar.gz.enc・/api/v1/snapshot/upload-credential・repoSnapshotIndexingEnabled のどれも、TypeScript を含む全ファイルで 0 件でした。オブジェクトストレージへの直接アップロード（buildOssFormFields）は、フィードバックの添付ファイルを送るコードにだけ残っています
  • Repo Wiki への参照も見当たらない：TypeScript のソースに Repo Wiki の実装は 0 件でした
  • チェックポイントは手元の Git で完結している：gitCheckpointRepo.ts は、一時的な GIT_INDEX_FILE を使って作業ツリーを git add -A し、write-tree → commit-tree で内部用のコミットを作り、refs/zcode/checkpoints/<ワークスペースのハッシュ>/<ID> という隠し ref に結び付けます。メタデータはアプリの設定ディレクトリの checkpoints に置かれます。ネットワークへの送信はこの流れの中にありません

ただし、公開されたのは最新の状態だけで、送信経路がいつ・どう取り除かれたかを示す履歴はありません。また、リポジトリの NOTICE.md は「公式製品の全機能を提供することは約束しない。実際に公開したソースと成果物が基準」と断っています。配布されているアプリがこのソースと同じものかは、ソースを読むだけでは決まりません。OSS 化で確かめられるようになったのは「公開されたコードに何があるか」であり、その先は、次の節で紹介する通信の観察と組み合わせて確かめることになります。

NOTICE.md 自体は読み応えのある文書です。モデルへの問い合わせ、ログイン、MCP、SSH／WSL、添付ファイル、会話の共有、フィードバック、更新確認と、外へ出ていく通信を業務ごとに一覧にし、それぞれ何を送りうるかを書き出しています。ほかのツールでもこの粒度の一覧があれば、利用者はずっと判断しやすくなるはずです。

報道で伝えられていること

同社の謝罪と第三者評価は、同社の X 投稿として報じられました。本記事は一次資料を確認できていないため、報道の内容として分けて書きます。

報道によれば、同社は 9月21日に次のように説明しました（IT之家・InfoWorld）。

  • v3.14.0 で Repo Wiki 機能を取り除き、ローカルのリポジトリのスナップショットを作って送る流れを断った
  • 中国情報通信研究院（CAICT）の評価で、該当するクラウドのストレージバケットはデータがゼロの状態と確認された
  • セキュリティ企業の NSFOCUSの審査で、バケットとその中のデータオブジェクトはすべて削除済みで、ローカルのスナップショットやファイルを外へ送る機能の経路は見つからなかった
  • 送られたコードのデータは保持しておらず、モデルの学習にも使っていない
  • 今後、製品の脆弱性を報告・対応する常設の仕組みを作る

🗂️ 3. .git に「消したはずの秘密」が残る理由 — objects・reflog・隠し ref

今回の報告で多くの開発者がひやりとしたのは、「.git ごと」という点でした。今のファイルから API キーを消していても、.git にはまだ残っているかもしれないからです。

objects：過去のコミットは中身を丸ごと持っている

Git は、ファイルの中身を blob、フォルダの構成を tree、ある時点の記録を commit というオブジェクトにして、.git/objects に保存します。オブジェクトの名前は中身のハッシュで決まり、一度できたオブジェクトは書き換えられません。

flowchart TB C1["commit A
.env を追加"] --> T1["tree A"] T1 --> B1["blob
.env の中身（キー）"] C2["commit B
.env を削除"] --> T2["tree B
.env なし"] C2 -->|"親"| C1 H["HEAD"] --> C2

.env を消すコミット B を作っても、コミット A とその blob はそのまま残ります。B は A を親として指しているので、git log -p をたどれば誰でも中身を読めます。.git を丸ごと持ち出すというのは、この過去のすべてを持ち出すということです。

reflog：ブランチから消えても、操作の記録が指している

git commit --amend や git reset でコミットを「なかったこと」にしても、Git は .git/logs の reflog に「HEAD やブランチが以前どこを指していたか」を記録しています。reflog が指している間は、そのコミットと中身は消えません。git-config のドキュメントによると、reflog の記録は既定で 90 日（gc.reflogExpire）、現在の先端から到達できない記録は 30 日（gc.reflogExpireUnreachable）保たれ、git gc で期限切れのものから片付けられます。

隠し ref：ツールが作る、目に見えないブランチ

refs/heads/（ブランチ）や refs/tags/ 以外にも、ref は自由に作れます。前の節で見た ZCode のチェックポイントのように、ツールが独自の名前空間に ref を作り、作業ツリーの写しをコミットとして保存するやり方は珍しくありません。git branch には出てきませんが、.git/objects の中には確かに入っています。

そのほかにも .git が抱えているもの

  • .git/config：リモートの URL（社内の Git サーバーのドメインなど）
  • .git/lfs/：Git LFS で扱う大きなファイルのキャッシュ
  • コミットの作者情報：名前とメールアドレス

漏れた秘密への対処（概要）

GitHub の公式ドキュメントは、秘密（パスワード・トークン・認証情報）が履歴に入ってしまった場合、最初にその秘密を失効・再発行することを求めています。履歴を書き換える前に、です。そのうえで git-filter-repo（--sensitive-data-removal が使える 2.47 以降）で履歴から取り除く手順を示していますが、他人のクローンやフォークに残った分は消せないとも明記しています。「一度でも外へ出たかもしれない秘密は、鍵そのものを替える」が原則です。

🛠️ 4. 自分のエージェントの送信範囲を確かめる手順

ここからは、手元のエージェントについて同じ問いを確かめる手順です。どれも特別な権限は要りません。

手順 1：公式ドキュメントの「送るもの・止め方」を表にする

まず、使っているツールの公式ドキュメントに何が書いてあるかを確かめます。9月23日時点の記述を抜き出すと、次のとおりです。

Claude Code Gemini CLI Cursor
LLM へ送るもの プロンプトと出力 規約による プロンプトとコードの文脈
利用統計 既定で有効 既定で有効 —
統計の中身 コード等を含まない 中身を含まない —
学習への利用 プランと設定による — Privacy Mode で不使用
渡さないファイル deny ルール .geminiignore .cursorignore
  • Claude Code：LLM とのやり取りのため、すべてのプロンプトとモデルの出力を TLS 1.2 以上で送る。利用統計はコード・プロンプト・ファイルパスを含まず、DISABLE_TELEMETRY=1 で止まる。必須でない通信は CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC でまとめて止められる。個人向けプランは学習への利用を設定で選び、商用条件では学習に使わない。読ませないファイルは permissions.deny に Read(./.env) のように書く
  • Gemini CLI：利用統計は既定で有効で、privacy.usageStatisticsEnabled を false にすると止まる。ツール名や所要時間は記録するが、プロンプト・応答・ファイルの中身は記録しないと明記している。LLM への送信内容の扱いは、ログイン方法ごとの利用規約とプライバシー通知で決まると案内している。除外するファイルは .geminiignore に書く
  • Cursor：AI 機能を使うと、プロンプトとコードの文脈をモデルの提供元へ送る。Privacy Mode を有効にすると学習に使われない。.cursorignore で除外でき、.git/ や .env は既定で除外される。ただしターミナルのコマンドと MCP のツールは ignore の制御の外で動くとドキュメントは書いている

「—」は、今回確認したページに該当する記述がなかったことを示します。

手順 2：手元のデータディレクトリを眺める

ZCode の件は、解析記事の書き手がディスクの空きを探していて ~/.zcode が 700MB を超えていたのに気づいたところから始まりました。自分のツールでも、データディレクトリの大きさと中身をときどき眺めておくと、想定外のものに早く気づけます。

du -sh ~/.claude/* 2>/dev/null | sort -h | tail

Claude Code のドキュメントによると、~/.claude/projects/ には会話の記録がセッション再開のために平文で既定 30 日保存されます。こうした「何がどこに何日残るか」も、ドキュメントと突き合わせておきます。

ZCode の旧版を使っていた場合は、issue #707 が確かめ方を載せています。~/.zcode/v2/checkpoints/ があるか、その下の state.json に lastAcceptedManifestHash があるかを見ます。この印があれば、少なくとも 1 回はサーバーに受け付けられたことを示す、と報告者は書いています。

手順 3：通信先を OS の道具で見る

ツールを動かしながら、どのホストとつながっているかを OS の道具で見ます。

# Linux：プロセスごとの TCP 接続
ss -tpn | grep -i claude

# macOS：プロセスが開いているネットワーク接続
lsof -i -P -n | grep -i claude

Windows の PowerShell では Get-NetTCPConnection -OwningProcess <PID> で同じことができます。つながっている先が、ドキュメントに書かれた送り先（LLM の API・テレメトリ・更新確認など）と一致するかを確かめます。

手順 4：プロキシを通して中身を見る

もう一歩進めるなら、HTTPS を中継して中身を見られるプロキシ（mitmproxy など）を手元で動かし、そこを経由させます。Claude Code は標準の HTTPS_PROXY 環境変数に従い、追加の CA 証明書を NODE_EXTRA_CA_CERTS で渡せる、とドキュメントに書かれています。

# 別の端末で mitmproxy を起動しておく（既定のポートは 8080）
mitmweb --listen-port 8080

# 中継させて Claude Code を起動する
HTTPS_PROXY=http://127.0.0.1:8080 \
NODE_EXTRA_CA_CERTS=~/.mitmproxy/mitmproxy-ca-cert.pem \
claude

プロキシの画面で、送り先のホスト名と、リクエストの大きさを見ます。プロンプト 1 回に対して、想定よりずっと大きい送信がないかが目安です。環境変数のプロキシ設定に従わないアプリの通信はこの方法では見えないので、手順 3 と組み合わせます。

手順 5：テレメトリの中身をファイルに書き出す

Gemini CLI は、テレメトリの出力先をローカルのファイルにできます。settings.json に次のように書くと、何が記録されているかを自分の目で読めます。

{
  "telemetry": {
    "enabled": true,
    "target": "local",
    "outfile": ".gemini/telemetry.log"
  }
}

手順 6：渡す範囲を絞り、自分の .git を点検する

最後に、エージェントに渡す範囲を絞ります。Claude Code なら設定ファイルの permissions.deny に "Read(./.env)" や "Read(./.env.*)" を書き、Gemini CLI なら .geminiignore、Cursor なら .cursorignore に同じパターンを書きます。

そして、自分の .git に何が残っているかも点検しておきます。

# .env が過去に一度でもコミットされたか
git log --all --oneline -- .env

# 履歴のどこかに特定の文字列（キーの先頭など）が入っていないか
git log --all -p -S "API_KEY" | head

# ブランチ以外の隠し ref も含めて、すべての ref を並べる
git for-each-ref

# .git の大きさ
git count-objects -vH

見つかった秘密は、前の節のとおり、まず失効・再発行します。

📌 筆者の見方

ここからは筆者の意見です。

当サイトは、記事の下調べやツールづくりに AI エージェントを日常的に使っています。MCP ツールの作り方やタスクボードに MCP を生やす記事で書いたとおり、エージェントに渡す道具と権限は自分で決めているつもりでした。それでも今回の件で、「どのファイルを読ませるか」と「そのツール自身が何を送るか」は別の問いだ、とあらためて気づかされました。前者は ignore や deny で決められますが、後者はツールの作り手に委ねるしかない部分です。

だからこそ、明るい材料として受け止めたいのは、報告からソース公開までが 3 日だったことです。利用者が手元の痕跡から仕組みを突き止め、別の利用者が別の OS で同じことを確かめ、作り手はソースを開いて第三者が読める形にしました。公開されたのが最新版だけ、という限界はあります。それでも、送信範囲が「作り手を信じる」ものから「読んで確かめる」ものに一歩近づいたのは確かです。

AI エージェントは、これからもっと多くのファイルを読み、もっと多くの場所へつながっていきます。そのとき頼りになるのは、送信範囲を一覧にしたドキュメントと、利用者がそれを通信で確かめられる環境です。ZCode の NOTICE.md のような「外へ出る通信の一覧」が、どのツールにも当たり前に付く流れになってほしいと思っています。

⚠️ 注意点

  • 公開ソースと配布アプリは同じとは限らない：ソースに送信経路が見当たらないことは、配布されているアプリの動作を保証しません。NOTICE.md も製品と同じ機能を約束しないと書いています。通信の観察と組み合わせて確かめます
  • ignore と deny は「エージェントが読むファイル」の制御：Cursor のドキュメントが明記するとおり、ターミナルや MCP のツールは ignore の外で動きます。シェルで cat .env が実行されれば中身は読まれます
  • プロキシでの観察は自分の環境で：TLS を中継すると、通信の中身（認証トークンを含む）がプロキシに見えます。会社の端末や他人のアカウントでは行わず、ログの扱いにも気をつけます
  • 数値は報告と解析によるもの：ファイル数・割合・送信回数は利用者と第三者の計測で、同社が認めた数字ではありません

まとめ

  • 9月18日、ZCode の旧版がワークスペースを .git ごと暗号化して送る仕組みを持つと利用者が報告した。 ログイン中なら設定のスイッチを切っても動き、.git がスナップショットの 9 割近くを占めた例もある
  • 9月19日の v3.14.0 で修正され、9月20日にソースが Apache-2.0 で公開された。 公開ソースに送信経路の識別子は見当たらず、チェックポイントは手元の Git で完結している。報道によれば、同社は謝罪し、ストレージは空で削除済みと第三者が評価した
  • ワークスペース同期は「手元に置くか、送るか」で意味が変わる。 どちらの型かが利用者に見え、選べることが大事
  • .git は過去を丸ごと抱えている。 objects・reflog・隠し ref が、消したはずの秘密を残す。漏れたかもしれない秘密は、まず失効・再発行する
  • 自分のエージェントも確かめられる。 公式ドキュメントの表、データディレクトリ、OS の接続一覧、プロキシ、テレメトリのファイル出力、ignore／deny と .git の点検、の順で

よくある質問（FAQ）

Q. ZCode は今もワークスペースを送っていますか？

A. 公式の更新履歴によると、2026年9月19日の v3.14.0 で「repository wiki の異常なアップロード」が修正されました。報道によれば、同社は Repo Wiki 機能を取り除き、スナップショットを作って送る流れを断ったと説明しています。9月20日に公開されたソースにも、issue で指摘された送信経路の識別子は見当たりません。ただし、配布されているアプリが公開ソースと同じかは、ソースだけでは確かめられません。

Q. .env を削除してコミットすれば、秘密は消えますか？

A. 消えません。過去のコミットが .env の中身（blob）を指し続けるため、.git の中に残ります。git commit --amend や git reset で消したつもりでも、reflog が指している間は残ります。GitHub の公式ドキュメントは、まず秘密を失効・再発行し、そのうえで git-filter-repo で履歴から取り除く手順を示しています。

Q. Claude Code は .git を送りますか？

A. Claude Code の公式ドキュメントは、LLM とのやり取りのためにすべてのプロンプトとモデルの出力を送ると書いています。エージェントがファイルやコマンドの結果を読めば、その内容はプロンプトの一部として送られます。利用統計にはコード・プロンプト・ファイルパスは含まれないとされ、DISABLE_TELEMETRY=1 で止められます。読ませたくないファイルは permissions.deny で指定できます。

Q. 自分のエージェントが何を送っているか、どう確かめればよいですか？

A. まず公式ドキュメントで送るものと止め方を確認し、ツールを動かしながら OS の道具（ss・lsof・Get-NetTCPConnection）で接続先を見ます。中身まで見るなら、mitmproxy などのプロキシを手元で動かし、HTTPS_PROXY 経由でツールを起動します。Gemini CLI はテレメトリをローカルのファイルに書き出す設定もあります。

Q. 暗号化して送っているなら問題ないのでは？

A. 暗号化は通信途中や保管中の盗み見を防ぐものです。報告によれば、ZCode の旧版は本体を AES-256-CTR で暗号化し、その鍵をサーバーから配られた RSA 公開鍵で包んでいました。この方式では、秘密鍵を持つサーバー側は中身を読めます。大事なのは暗号化の有無より、何を・どこへ・誰が読める形で送るかが利用者に見えていることです。

関連記事

参考

一次資料は front matter の references に列挙しています。取得日はすべて 2026年9月23日です。

X（旧 Twitter）の投稿は出典に使っていません。