AWS CDK issue 34892 テレメトリ収集機能の動向 (memo)
hassaku63
免責
ここに書くすべての内容は、2025-07-22 時点までに CDK の中の人が表明したと思われる情報・スタンスを拾ったものと、CDK (or CLI) の実装について私が握している内容を合わせて構成したもの。
ここに書く内容の正確性は一切保証しかねるので、疑いがある場所については各自で issue の議論や、RFC 等の一次情報を参照のこと。
あと、これを書いてる人は GDPR には特に詳しくなく、あまり正しいこと・詳しいことを語れないのであしからず。読む人はゴシップ記事程度に受け止めてもらえるとありがたい。
私が把握している限りの補足や解説も適宜挟むが、それは実際のやり取りや文書に明示されているものと区別できる必要がある。なので、issue コメントや RFC などの事実の説明を含んでいる文脈において、私が独自につけくわえた解釈や意見の記述がある場合、文頭に ★ を記載することで区別する。
また、観測事実ではない、私の個人的な雑感だけを書くコメントもちょいちょいする予定だが、そのようなコメントは冒頭で雑感であることを明言する。
(ref)
条文の翻訳版のほか、以下のあたりも今回のポイントを読み解く根拠として参照できそう
- 自動化された個人に対する意思決定とプロファイリングに関するガイドライン
- 同意に関するガイドライン
- 透明性に関するガイドライン
hassaku63このコメントを書く約2週間前くらいまでは私もコメントをウォッチしていたので、その時点までの、issue コメントに対する私の雑感・印象。
issue についたコメントの傾向をざっとみ
- コアメンテナを除くコントリビューターは、テレメトリ自体には賛同するが、条件付きであったり慎重なスタンスが多め
- 懸念や反発の意見は、Opt-out と扱う情報の透明性に関するものがほとんど
- Opt-out であることに対する意見
- 中の人としては、事前に猶予期限を設けたうえでの告知を行い、事前に拒否する方法も用意している、と説明
- GDPR 違反を指摘する声が複数挙がっている
- CDK 側の具体的な実装や告知方法、実際の手順にまで言及したうえで、具体的な条項に対応付けて指摘をしているコメントは見当たらない。よって、GDPR 違反を指摘するコメントはあくまで懸念や反発意思の表明であって、明確な根拠に基づく「指摘」や「議論」ではない、という認識
- GDPR 関係だと第7条、特に「明示的な同意」に関する話題が最も注目されている、かつ反発を呼んでいる印象
- 現在 CDK チームが提示しているやり方が「有効な同意」たりえるのか？という指摘、懸念
- テレメトリの詳細に関する意見
- 実際になにが送信されるのか、その詳細を開示するように表明している意見が複数
- 単にハッシュ化した ID では匿名化の方法として不十分ではないか、とする指摘
- 他のイベントやデータソースと突合すれば、その ID は具体的に紐づく人の氏名がわからないだけで、特定のプロファイルや行動ログが紐づく「識別子 Hoge さん」として認識できてしまう、という話
私の個人的な立場
CDK の利用は完全な社内システムの開発用途であり、EU とは直接関係のない仕事をしている。正直あまり本件は強く反発する理由がない。無償で提供される任意のモノにきちんとフィードバック送ってくれる人がどれほど希少かは私なりに理解しているつもりだし、開発寄りの立場としてテレメトリ収集したい都合も、理解はできる（ましてや CDK は明確に AWS が出してる特定ベンダーのためのツールなので）。
きちんと情報をハッシュ化するなり drop するなりしてくれる限り、そして明確な拒否の方法が提示される限りにおいて好きに収集してくれていい、というスタンス。
既存で構築済みのプロジェクトが、CLI or lib のバージョンを更新することでテレメトリ送信を始めてしまうのだけはネガティブ。既存プロジェクトには影響がないように...要するに実質的な Ops-In になるよう開始してもらえるなら、なんの不満もない。
Context の値によってテレメトリを無効化できることはすでにアナウンスされているので、CDK で使われている他の多くの Feature flag と同じく、プロジェクトの Context にテレメトリ収集のキー (cli-telemetry または環境変数 CDK_DISABLE_CLI_TELEMETRY) 自体が未定義の場合は「収集無効」と判定してもらうようにしてもらえたらいいと思っている。こうすれば、既存プロジェクトが依存関係更新の影響を受けることはない。
...というような意見を、当時見えてる範囲で簡単に issue にコメントした。
(参考) GDPR における「同意」について
以下は「同意に関するガイドライン」より引用。
一般的に、同意は、データ主体が自分の同意を制御でき、提示された条件を承諾するか拒否するかの純粋な選択肢が示され、又は不利益を被らずに拒否できる場合にのみ、適切な法的根拠となりうる
ここで「純粋な選択肢」と言っているモノが、一般的にイメージする yes/no のプロンプトの提示以外の手段でも、要件を満たしうるのか？は争点になりそうな印象を持っている。
CDK CLI は最近になって以下のような形式で、コマンドライン使用時にログを出すようになっている。
NOTICES (What's this? https://github.com/aws/aws-cdk/wiki/CLI-Notices)
34892 CDK CLI will collect telemetry data on command usage starting at version 2.1100.0 (unless opted out)
Overview: We do not collect customer content and we anonymize the telemetry we do collect. See the attached issue for more information on what data is collected, why, and how to opt-out. Telemetry will NOT be collected for any CDK CLI version prior to version 2.1100.0 - regardless of opt-in/out. Affected versions: cli: ^2.0.0 More information at: https://github.com/aws/aws-cdk/issues/34892
猶予期限付きで告知され、CLI の適用バージョンが示され、拒否する選択肢があることも示されている。
この通知単体では「選択肢」の要件を満たすとは考えにくいが、「同意を制御できる」や「不利益を被らずに拒否できる」については、もう少し明確な（十分な猶予期間を設けたうえでの）事前告知がなされるのなら...？という印象もある
完全なる余談: テレメトリの notice が出た時期と、notice 自体の仕組みについての小ネタ
上述の notice が出始めた正確な時期は、ぱっと出てこない & 確認してない。
ただし、notice のリスト自体は https://cli.cdk.dev-tools.aws.dev/notices.json で提供されており、この JSON は 2025-07-23 未明時点に Get したところ Tue, 22 Jul 2025 19:19:57 GMT 時点のキャッシュを返している様子なので、少なくともこの時点以降の（ほぼすべての）CDK CLI でこれがで始めている、はず。
※上記 URL はあくまで CDK が内部的に使いたいだけの API であるはずなので、（おそらく CDN が効いているはずとは思うが）本来の CLI 経由のルート以外でむやみに悪用・乱用しようと思わないこと
notice の表示コンテンツは CDK CLI のバージョンに依らず、いつでも最新情報が出せるようになっている（notice 機能自体が入ってないバージョンは別だが、多分そんなバージョンはもう outdated してるはず...）。その仕組みの裏側が、JSON 配信用の HTTP(s) API で情報提供するやり方で実現されている
hassaku63issue 作成者の kaizencc のコメントを引用。
※このコメントを書く約 2h 前にタイトルが修正され、適用日が 2025/09/01 に延期になっている
Last communication as of 7/10/25 5:00PM ET:
Thanks for all the feedback. We understand that this is a sensitive change and we have considered the comments here, as well as conversations with multiple customers. In response to your concerns, we have made a few changes to the original proposal which tries to strike a balance between having valuable data that identifies regressions and usage patterns to help us improve our product, while respecting your privacy concerns and providing better options that can support your requirements.
Here is a summary of the changes we are making to the RFC proposal:
- We will not collect anonymized account Id, error logs, error messages and traces without explicit opt-in.
- As an additional measure for high governance enterprises, to enforce opt-out across your organization, we will clearly document how you can block calls to the CDK telemetry domain (we will publish the final url prior to launch).
- We are improving the opt-out experience with a global
--no-telemetryflag and adding acdk cli-telemetry --statuscommand to show your current opt-out status (The old--no-version-reportingflag is no longer recommended, but will also disable both library and CLI telemetry).- We will pre-launch with a version of telemetry that writes to a local file that you can use to evaluate the feature and the data to be sent. In aws-cdk v2.1021.0+, you can run
cdk [command] --unstable=telemetry --telemetry-file=my/local/filepathto save telemetry data to a local file.- We are moving the launch date to September (v2.1100.0) to give you time to review the generated telemetry, prepare your opt-out configuration, and give us more feedback. We will be announcing the exact date at least 4 weeks prior to launch.
The RFC will be updated to reflect these changes. Please continue to provide your feedback on this issue.
ざっと要約。当初の RFC からの計画変更が明示された。
- 明示的なオプトインなしには、以下の情報を収集しない
- 匿名化されたアカウントID（ハッシュ化のことを指している？）
- エラーログ、エラーメッセージ
- トレース
- （これ以外の情報に、この例外として収集対象となるものは含まれるかも）
- ガバナンス要件の高い企業に向けた対策
- 組織全体でオプトアウトを強制する方法を文書化する。具体的にはテレメトリ送信先となるドメイン (URL) への通信遮断の方法
- オプトアウト操作を改善する
- グローバルな
--no-telemetryフラグの追加 - 現在の状態を確認する
cdk cli-telemetry --statusを追加する
- グローバルな
- リリース前の特定バージョンで、実際に送信されるテレメトリをローカルファイルで確認できる方法を提供する
- 日程の延期。リリース日は少なくとも4週間前に告知
以下、kaizencc が issue に記載した他の記述から、主要そうなものを私見でピックアップする。
私が把握している限りの補足も挟むが、私の補足であることを明示するために、その場合は文頭に ★ を記載する
2025/08/08 以前にリリースされた CLI バージョンでは、opt-in/out の状況に関係なくテレメトリは収集されない。
ただし、事前にテレメトリ収集設定の有効 or 無効を制御する手段は、CLI で先行リリースされている。
★この時点では実効的な収集ロジックはなにも入ってなくて、ON/OFF の制御スイッチが渡されている、と解釈すればOK。
cdk cli-telemetry --disable
実態としては、プロジェクトの cdk.context.json に以下の値が追加される。
{ 'cli-telemetry': false }
★テレメトリ収集の有効／無効は、Context で制御可能、ということ。つまり、CDK の Context ソースとして宣言できる任意の場所で無効化できる。詳しくは CDK Concepts の文書を参照。
開発マシン（のOSユーザー）のスコープ全体で無効化したいなら（その OS ユーザー全体に作用する）~/.cdk.json に同様の値をセットしておくことで、その開発マシンのすべての CDK プロジェクトはテレメトリ収集を拒否できる。
★要するに、Context で所定のフラグを立てておけば、今後 CLI or lib を任意バージョンに上げたとしても、テレメトリ収集は事前に拒否できている状況が作れるということ。そして、CDK における Context はプロジェクトローカルだけではなく開発マシンのユーザー空間でグローバルに作用させることができるし、環境変数からも反映可能。
環境変数から制御するのであれば、CDK_DISABLE_CLI_TELEMETRY を true にしておくことでも拒否が可能。
hassaku63↑の kaizenncc のコメントの要約をしたうえでの、私の雑感。
これ書いてる時点での RFC の最新版は、まだ読めてない。なので以降のコメントで解釈変わるかも。
上記のような「拒否」の方法を、CDK CLI の notice でぜひ改めて告知してくれたらいいなぁ、と思った。（RFC 読もうぜという話ではあるが）
「明示的な同意」の要件を満たすうえで、この辺の説明があることは（notice のアプローチで選択肢要件を満たせるかはさておき）私の目からは必須に見えた。
多分、issue に参加している人の何割かは当初の話だけ見て反射で反応していて、「期日が来たら問答無用で送信する仕様なのか！？けしからん！！！」とか思っていそうな人が一定数いる印象。
実際には情報提示の方法とか、拒否の方法とか、そういうのは（妥当な方法であるかは別として）アナウンスされているわけで、もっとディテールがある。そういうのを踏まえたうえでの有意義な議論だけコメントに残したいよね、と思う次第。
今の CDK の仕組みからしてしょうがないとはいえ、各自の開発マシンでもれなく Deny させるのは少々めんどくさそうだな、、、と思った。テレメトリ収集のエンドポイントを N/W レイヤーで遮断するしかないとすると結構苦しく、ガバナンス要件が厳しい企業だと相当ネガティブに見えてもおかしくはない...気もする。いずれにせよ、イメージだけで議論せず、実態をちゃんと把握したうえでの判断は必要と思う。
既存の CDK Context の枠組みに乗っかった制御方法にした点と、この on/off スイッチを事前提供していた点は非常に good だと思っている。
これにより、企業ポリシーとしてテレメトリを拒否したい場合は ~/.cdk.json の設定や bashrc/zshrc での環境変数宣言によってテレメトリが一律無効化可能になっている。
あるいは、対象プロジェクトで無効化フラグの context key/value を事前にコミットしておけばよい。
とはいえ、一般的には CIOps 的なやり方でプロジェクトごとに個別にデプロイが設定されているユースケースがほとんどであろうとも思うし、そうだとすると個別のプロジェクトごとに本件のチェックをしに行くのは（確認込みで）しんどい。
「企業」や「組織」のスコープで機能するグローバルフラグはそれこそ Terraform Cloud のような仕組みでもないと原理上不可能なので、CDK に同じことはできなさそう。
ならばせめて、bootstrap の方でこのフラグを持っておけたらもう少し「組織」単位での適用が簡単になるのではなかろうか・・・と思った。
プロジェクトや開発マシンという単位はかなり限定的なスコープなので、bootstrap の単位 (account/region のペア) でテレメトリ収集の on/off を制御できるようになるなら、まだテレメトリが絶対 NG な組織への措置としては効力ありそうな気がする。
hassaku63CDK Chatting #7 で挙がった質問への回答コメント
以下は質問文の引用。
25/8/8以降、CDK CLIがanonymous telemetry data を収集するようになる件RFCの最後のコメント7/15を見る限り、opt outしないかぎり、収集されるものでしょうか。https://github.com/aws/aws-cdk/issues/34892
2025-07-23 時点で私が把握している限りだと、特に重要そうな話は以下の3点。
- 「ユーザーが Opt-out しない限りは収集される」のスタンスは変わらず
- 開始日は本日時点で 2025-09-01 に延期されている (
v2.1100.0から開始予定) -
v2.1021.0+でプレビュー機能が使用可能になった。これによりcdk [command] --unstable=telemetry --telemetry-file=my/local/filepathのコマンドで、ローカルファイルで実際にどのようなテレメトリデータが送信されるかを確認可能
プレビュー機能を使わずとも、RFC である程度サンプルは示されているのでそちらも参考にするとよい。
現時点では RFC も再検討しているっぽく、少なくとも「もう確定！」って雰囲気ではなさそうに見える。あと、具体的な実装や各種手順・ガイダンスもまだ出揃っていないように見えるので、9/1 の日付もまだ暫定であってスライドする可能性はありそうに思える。
Opt-out の方法については、CLI や lib のどのバージョンを使っていようが、事前に拒否しておく対応が可能。issue やここまでのコメントにも書いているように、Context に対応する値を入れておけばよい（変更される可能性もあるので、あくまで今日時点での情報であることに留意）。
（方法1） ~/.cdk.json や <project_root>/cdk.context.json などの Context source に以下の値を追加する。
// Context source となるファイルのいずれかにこの key/value を記述
{ 'cli-telemetry': false }
開発機で使っている OS ユーザー全体に設定を波及させたいなら、前者のファイル ~/.cdk.json に書き込むとよい。
後者の <project_root>/cdk.context.json に関しては、CLI v2.1020.0 から cli-telemetry サブコマンドで on/offf 制御ができるので、このコマンドを実行することでも同等の操作になる。
# `<project_root>/cdk.context.json` に上記の値を書き込むのと等価なコマンド
# CLI v2.1020.0 以降で実行可能
$ cdk cli-telemetry --disable
（方法2） 環境変数 CDK_DISABLE_CLI_TELEMETRY に "true" か "1" を指定しておくことでも同等の対応になる。
基本はプロジェクトの cdk.context.json にコミットしておく方がよいと思うのでそちらが推奨だが、念を入れたいなら手元の bashrc/zshrc なりに書いておくとよい。
pr#697 では cli-telemetry コマンドに --status オプションが追加されており、自分のローカルプロジェクトや CI 環境上でテレメトリが無効化されていることを確認する手段が実装された。2025-07-23 時点の最新版である v2.1021.0 のリリースには含まれていないが、マージはされているのでおそらく直近のうちに --status も使えるようになるはず。
ユーザー固有の情報がマスクされるかどうか？どうマスクされるのか？については、RFC の Error Messages, Stack Traces, & Logs を参照。
ARN やアカウントID、ファイルパス、Stack name、論理ID などなど主要そうなものについては言及されている。
（参考）テレメトリ収集を許可しているかどうかの判定ロジックはこちら。めっちゃシンプル