LLM による機密チェックの構造的限界：自己申告済み情報しか検出できない

LLMに開発を依頼する際、コードに書かれていない「暗黙の意図」は確実に伝わらない。Todoアプリの修正事例を通じ、仕様書・自動テスト・構造的な設計が互いに補完し、運用ルールとして強制することの重要性を検証。単なるセッション会話やドキュメント作成だけでは不十分。

製造現場の日報を Excel マクロで 4 年間運用してきた著者が、自由記述欄における表記ゆれ・誤字による検索漏れ・条件トレーサビリティ喪失といった構造的な問題に直面。人間の記述の多様性は教育では解決不可能であり、Claude による自動解析・補完で新たなアプローチを試みる。

返品ポリシー文書の有無だけで、LLM の出力が「正しい業務回答」から「架空の規定に基づく誤回答」に反転する現象を検証。資料なしの場合、存在しない「8日以内」という返品期限を作り出し、本来は受付可能な10日目の返品を断定的に拒否した。情報の欠落を申告せず推測で埋める構造的な限界と、Projects / Claude Projects など「プロジェクト」機能による人間側の貼り忘れ回避策を解説。

LLM を用いたコードレビューをPR一次チェックとして1年運用した結果、スタイルの不統一と繰り返しパターンの検出には高い効果がある一方、業務ロジックの妥当性判定と複数ファイル・サービス間の整合性チェックは見落とされやすい。人間レビュアーはAIの得意領域に依存せず、ドメイン知識が必要な検証に集中する役割分担へ転換した。