docs: update README background section

README.ja.md

@@ -44,7 +44,25 @@
 
 ## 背景
 
-.NET アプリケーションには、スレッドセーフ性、インフラ境界、副作用制約のように型システムだけでは表現しにくい設計前提が存在します。この Analyzer はそうした前提を属性で明示し、実際の型依存に対して機械的に検証できるようにします。
+.NET アプリケーションの設計では、スレッドセーフ性やライフサイクルといった重要な前提が、コードではなく暗黙の了解として扱われることが少なくありません。
+
+実際の開発において、DI でシングルトンとして管理されるクラスが、シングルトンとして設計されていない依存オブジェクトをコンストラクタ経由で保持してしまうケースに直面しました。
+
+その結果、本来は短命であるべきオブジェクトが事実上シングルトンとして扱われ、長時間の動作によりメモリが肥大化する問題が発生しました。
+
+この問題はコンパイルエラーにも警告にもならず、コード上にも設計意図が明示されていないため、レビューでも見落とされやすく、問題が顕在化するまで検知できませんでした。
+
+また、DI ベースの確認は実行構成に依存するため、「コード上の依存関係そのもの」が設計意図を満たしているかを静的に検証することは困難です。
+
+つまり、「依存関係の正しさ」は人間の注意と経験に依存しており、機械的に保証する手段が存在しない状態でした。
+
+この経験から、「依存関係に対する設計意図を契約としてコード上に明示し、それを静的に検証する」仕組みの必要性を強く感じ、本ツールを開発しました。
+
+`DependencyContractAnalyzer` は、型間の依存関係に対して契約を宣言的に付与し、その契約が満たされているかを静的解析によって検証します。
+
+これにより、これまで暗黙的に扱われていた設計前提をコード上に表現できるようになり、レビュー・自動解析・AI 支援のいずれにおいても一貫した検証が可能になります。
+
+さらに、ビルド時に依存関係が設計意図を満たしているかを機械的に判別できるため、「気づけない設計ミス」を早期に検出し、コードの安全性と保守性の向上に寄与します。
 
 ## 依存抽出スコープ
 

README.md

@@ -44,7 +44,25 @@ Technically, the current implementation is expected to work on `.NET 5` and late
 
 ## Why
 
-Modern .NET codebases often depend on design assumptions that are not visible in the type system alone, such as thread safety, side-effect constraints, or infrastructure boundaries. This analyzer makes those assumptions explicit and verifies them against actual type dependencies.
+In .NET application design, important assumptions such as thread safety and object lifetime are often treated as implicit understanding rather than something made explicit in code.
+
+In real development work, I ran into a case where a class managed as a singleton through DI ended up holding, through its constructor, a dependency object that had not been designed to live as a singleton.
+
+As a result, an object that should have been short-lived was effectively treated as a singleton, which caused memory growth over long-running execution.
+
+This problem produced neither a compiler error nor a warning, and because the design intent was not expressed in the code, it was easy to miss in review and difficult to detect until the issue had already surfaced.
+
+Also, because DI-based validation depends on the runtime configuration, it is difficult to statically verify whether the dependency relationships in the code itself satisfy the intended design.
+
+In other words, dependency correctness was left to human attention and experience, without any mechanical way to guarantee it.
+
+That experience made me strongly feel the need for a mechanism that makes design intent for dependencies explicit in code as contracts and verifies them statically, which is why I built this tool.
+
+`DependencyContractAnalyzer` declaratively attaches contracts to dependencies between types and verifies through static analysis whether those contracts are satisfied.
+
+This makes it possible to represent design assumptions that were previously handled implicitly directly in code, enabling consistent validation in reviews, automated analysis, and AI-assisted development.
+
+Because the build can mechanically determine whether dependency relationships satisfy the intended design, the tool helps detect design mistakes that would otherwise go unnoticed and improves both code safety and maintainability.
 
 ## Dependency extraction scope