課題: ローカルLLM機能を足したCLIに、レビューで複数の穴が見つかった

自作CLI「wip」に wip init --ai / wip help --ai というローカルLLM連携機能を追加

プロジェクトファイルをAIサーバーへ渡す機能を足すと、送信先・応答・秘密情報まわりの論点が一気に増える

レビューで5件の具体的な穴が見つかり、まとめて塞いだ

wip init --ai はプロジェクトを解析し、ファイルの中身をLM Studio/Ollama等に渡して wip.yml を書かせる

接続先を誤る/書き換えられるリスク、応答が巨大または不正な形のリスク

設定表示・送信対象に秘密情報が紛れ込むリスク

AI連携に限らず「外部通信を足した」タイミングで点検すべき典型的な論点

「送信先の検証」と「送信前の開示」は別の対策として両方実装（片方だけでは想定漏れ or 見落としに頼ることになる）

秘密情報のマスクは「どこにあるか(構造)」と「何という名前か(パターン)」を組み合わせる

通信を検証するだけでなく、相手からの応答をどう制限するかも対になる論点として扱う

AI送信先の二段階検証: ループバック以外はHTTPS必須 + --allow-remote-ai の明示オプトインが無い限り拒否、送信前に宛先とファイル一覧を開示

AI応答にサイズ上限: モデル一覧2MiB・チャット応答4MiBなど、Content-Lengthとストリームの両方をチェック

秘密情報redactionを構造認識型に: dependencies..env/commands..env 配下は変数名に関係なく無条件マスク

コマンド解決をTOCTOUセーフに: 見つけた時点の絶対パスを返し、後続で再解決しない

YAMLパーサーに入力サイズ・ノード数上限: 壊れた/巨大なYAMLによるCPU・メモリ枯渇を防止

「検証」「開示」「応答の上限」「構造認識のマスク」は、AI連携に限らず外部通信を足す変更全般に使えるチェックリストにする

詳しいコードはQiitaの限定共有記事で解説