APIキーをソースコードから外し、安全な保管先へ移す。これは必要な対策ですが、そこで点検を終えると、取り出した後の値が例外やデバッグログに残る問題を見落とします。保管先だけでなく、秘密が通る場所と、通してはいけない場所を一枚の図にすることが大切です。

今回は、金融データを一日単位で取得するPython CLIの実装記録から、macOSのキーチェーン、子プロセス、HTTP送信の境界を取り上げます。対象はソフトウェアとデータ運用であり、投資助言ではありません。既存の秘密情報管理の記事が保存先と権限の原則を扱ったのに対し、本稿は「読み出しに成功した後、失敗経路を含めて値を外へ出さない」検査に絞ります。

最近の取り組みで確認できたこと

記事作成の根拠にしたのは、10月5日に保存された9月28日〜10月4日のローカル週次記録です。そこには10月1日の作業として、対象コードと日付を指定する取得CLI、キーチェーンからのAPIキー読み込み、登録手順の整備が記されています。入力検査、読み出し、API呼び出し、CLIなどを段階的に実装した記録であり、単なる予定ではありません。

特に参考になったのは、秘密値の流れを追った点検です。記録上は、値が子プロセスの取得結果とリクエストヘッダーを通り、ログ・例外メッセージ・URLには現れないことを確認しています。また、`security`の呼び出しを引数リストにし、識別用の名前をフラグの値として渡す構造も点検されています。

ただし、本稿の制作時に元の取得CLIを再実行したわけではありません。実APIの応答が今後も秘密を含まないことや、すべての例外経路の安全性を保証する記録ではなく、当時の点検結果として扱います。以下の小さな再現例は記事用に用意した別実装であり、本番コードのテスト件数へ加算しません。

仕組みを分解する

境界は四つに分けると追いやすくなります。

1. **保存する境界。** 秘密値と、項目を探すための識別情報を分離します。Appleの公式資料は、Keychain servicesが小さな秘密情報を暗号化されたデータベースへ保存する仕組みだと説明しています。ただし、保存済みだから取得後のメモリやログまで守られるわけではありません。
2. **取り出す境界。** 必要な処理だけが値を受け取ります。子プロセスが秘密を標準出力に返す方式でも、親側で捕捉した値を画面へ転送しない設計が必要です。取得結果オブジェクト全体をログへ出すと、捕捉した意味がなくなります。
3. **送る境界。** APIの認証仕様に従った場所だけへ渡します。今回の記録はヘッダー経由ですが、サービスごとの指定を確認せず、どのAPIでも同じ形式だと決めつけてはいけません。URLや一般の進捗通知へ値を混ぜないことは別途確認します。
4. **失敗を知らせる境界。** 利用者へ返す状態と、内部の例外内容を分けます。「取得できなかった」「通信に失敗した」といった固定の状態コードなら、秘密を含み得る例外文字列を公開する必要がありません。

Python公式資料によれば、`subprocess.run`は出力を捕捉でき、`check=True`で起きる例外も、捕捉された標準出力・標準エラーを保持し得ます。したがって「例外になったから秘密は消えた」とは考えず、例外の表示側まで点検対象にします。

小さく再現する手順

最初は本物のキーチェーンもネットワークも使いません。読み出し関数と送信関数を外から渡し、失敗を意図的に起こせる形にします。次は秘密の取得と送信を分離する教育用の例です。

“`python
def execute(read_key, send):
try:
key = read_key()
except Exception:
return {"status": "credential_unavailable"}
if not isinstance(key, str) or not key.strip():
return {"status": "credential_unavailable"}
try:
send(key)
except Exception:
return {"status": "request_failed"}
return {"status": "ok"}
“`

読み出し役は架空の文字列を返し、送信役は受け取った値がそれと一致することだけを確認します。次に、読み出し役の例外、空文字、送信役の例外へ切り替えます。さらに、例外メッセージにわざと同じ架空文字列を埋め、それでも公開結果へ出ないかを検査します。実キーを使って漏えいテストをする必要はありません。

この関数は通信ライブラリではなく、公開結果の境界を示すものです。`send`がHTTPの失敗応答を例外にするかなどは、実際のアダプター側で契約を決めてください。何も例外を出さずに戻ったというだけでは、実サービスの処理成功を保証できません。

実装へ移す段階では、取得側の待ち時間、アクセス拒否、項目未登録を区別します。子プロセスの起動は文字列連結とシェル解釈に頼らず、引数リストを使う方針にします。ただし、引数リストは秘密値を引数へ置いてよいという意味ではありません。登録時の秘密の渡し方も別途点検し、本稿では実キーを登録・表示するコマンドを掲載しません。

確認指標

**当時の観測**は、週次記録にある読み出し方式と秘密の通過先の点検です。本記事では、本番CLIの網羅率や検査件数を新たに測定していません。差分レビューで問題が見つからなかったことを、将来の漏えい確率がゼロという数値へ読み替えないようにします。

**記事用の実行結果**として、上の関数を使い、正常、空文字、読み出し例外、送信例外の四ケースを検査しました。送信例外と読み出し例外には架空の秘密を混ぜ、返却値と捕捉した標準出力・標準エラーに現れないことを確認しました。外部APIへの接続も実資格情報の読み出しも行っていません。

**実運用へ進む際の推奨基準**は、公開ログへの秘密混入なし、取得失敗時の送信なし、異常時の状態判定が可能、という三点です。この再現例はロガーやHTTPライブラリを使わないため、それらの詳細ログについては実システムの結合テストが別に必要です。

失敗しやすい点と安全策

• **取得結果を丸ごと表示する。** 子プロセスの標準出力を捕捉しても、結果オブジェクトをデバッグ表示すると値を広げます。記録するのは終了状態など、必要最小限にします。
• **例外本文を通知へ貼る。** 例外や応答本文には、外部システムが返した予想外の情報が含まれ得ます。公開経路は固定の状態を基本とし、詳細診断が必要ならアクセス制限した別経路を設計します。
• **空のキーでも送信する。** 空文字や取得失敗を早い段階で止め、認証失敗リクエストを繰り返さないようにします。別の平文ファイルへ自動で切り替える回避策は、保管方針を崩すため避けます。
• **対話実行の成功を定期実行へ一般化する。** 実行ユーザーや権限、ロック状態によって結果が変わる可能性があります。確認画面待ちを放置せず、対象環境で失敗時の終了も確認します。
• **ヘッダーなら常に安全だと思う。** 送信先の検証や通信ログの設定も必要です。メモリからの完全消去や、権限を持つ別プロセスからの保護まで、この小さな関数が保証するわけではありません。

再現チェックリスト

• [ ] 保存先と読み出し後の通過先を分けて図にした
• [ ] 子プロセスの取得結果を丸ごと表示していない
• [ ] 空文字・未登録・取得失敗では送信しない
• [ ] 架空の秘密を例外へ混ぜて公開結果を検査した
• [ ] 標準出力だけでなく標準エラーと通知も確認した
• [ ] 実APIの成功と、ダミーによる境界テストを区別した
• [ ] 定期実行での権限と待ち時間を別に確認した

次に改善するなら

残る改善案は、実際の読み出しアダプターとHTTPクライアントを組み合わせた異常系テストです。取得拒否、タイムアウト、応答本文への架空値の混入を試し、通知・ログまで追う必要があります。また、固定の状態コードだけでは原因調査が難しい場合に、秘密を含まない診断項目を定義する作業も残ります。これらは本稿で完了した対策ではありません。

参考情報

• 記事作成の根拠にしたローカル資料：9月28日〜10月4日の週次活動記録（10月5日保存）、その中の10月1日の取得CLI実装と秘密情報の流れに関する点検。非公開資料のため公開リンクは掲載しません。
• Apple：[Keychain services](https://developer.apple.com/documentation/security/keychain-services) — 暗号化されたキーチェーンへの秘密情報保存。2026年10月6日確認。
• Python：[subprocess — Subprocess management](https://docs.python.org/3/library/subprocess.html) — 出力捕捉、引数、例外とタイムアウトの説明。2026年10月6日確認。