パイプ型リダクションの構造的な上限
一言まとめ
「command | redact」型のマスクは、少数パターンなら sed ワンライナーで代替でき、表示後のデータは消せず、検出漏れも避けられない。専用ツールが勝てるのは多数パターンの自動適用・設定共有・クロスプラットフォーム・低遅延 streaming が揃うときに限られる。
目次 4 sections
調査時点: 2026-04。
上限の 5 点
- sed ワンライナーが無料の代替になる。 単一〜少数パターンの個人ユースなら
command | sed -E 's/AKIA[A-Z0-9]{16}/[AWS]/g'で済む。専用ツールの優位は「多数パターン(Gitleaks 相当で 500 超)の自動適用」「チームでの設定共有・自動更新」「Windows を含むクロスプラットフォーム(sed は非標準)」「tail -fでの低遅延 streaming」が揃うときに限られる。 - sed はバッファリングする。
tail -fと組み合わせるとラグが出る。unbuffered な streaming にはstdbufや PTY 模倣のような非自明な実装が要る。 - 表示後のデータは消せない。 パイプ変換が触れるのは「これから表示する分」だけで、スクロールバックや端末ログに残った分は sed でも専用ツールでも消せない。
- 検出漏れは避けられない。 既知値方式は未設定の値を、パターン方式は変形・分割・動的に構築された値を取りこぼす。
- 同じ要求が各所で独立に再発し、汎用 CLI に収斂しない。 「タスクやサブコマンドの stdout を redact したい」という要望は Airflow・Tekton・kubectl・Grafana Tanka などで繰り返し出るが、各プロジェクトが sed や個別実装で済ませる。スタンドアロンの例は
ThorstenHans/mask(完全一致のみ、休眠)、codeberg.org/msantos/redact、CGI-FR/PIMO(JSON Lines 前提)などが散在する状態にとどまる。
近接ツールと用途のずれ
| ツール | パイプ redact との関係 |
|---|---|
| Teller | cat log | teller redact、tail -f 対応。ただし .teller.yml とバックエンド接続が前提(dotenv ならローカルのみで可) |
| Gitleaks | cat file | gitleaks -v stdin で検出はできる。--redact はレポート中の値を隠すフラグで、入力テキストを変換して stdout に流すものではない |
| PIMO / PyRedactKit / redact-cli / redacter-rs / secrets-masker | JSON Lines 前提・ファイルバッチ・ライブラリ・外部 DLP API 送信など、任意プレーンテキストのリアルタイム変換からはずれる |
Splunk SEDCMD / CrowdStrike Falcon などの DLP・SIEM | 取り込みパイプラインやエンドポイントで動作し、端末の stdout パイプには関与しない |
関連
更新履歴
- 2026-04-16: 初版（ローカル調査ノート）
- 2026-10-17: Wiki へ移植、概念ページとして再構成