Memory Bankの使い分け：大規模コードベースでの考慮点
Clineで開発を行う際、状況に応じてMemory Bankを選択的に活用するアプローチを取っています。特にコードベースが大きい場合は、Memory Bankを使わない方が効果的なケースが多いと実感しています。
Memory Bankはコンテキストを豊富に提供できる強力なツールである一方、大量の情報が与えられることで実際の命令に従う精度が下がることがあります。これはAIの注意が分散してしまうためと考えられます。
使い分けの基準
- 大きなコードベースの一部を正確に変更したい場合：Memory Bankを使わない方が効率的
- Vive Coding的にLLM主導で新規開発する場合：Memory Bankを活用する方が良い
Memory Bankを活用すると、Sonnetの創造力を最大限に引き出し、柔軟な発想で開発を進められます。一方で、大規模なコードベースの修正では、LLMに自由度を与えるよりも、範囲を適切に限定した方がより正確な結果を得られることが多いです。
Memory Bankの代替アプローチ
Memory Bankを選択的に利用する際の、私が実践している効果的な代替手法をいくつか紹介します。
1. clinerules-bankと.clinerules フォルダの活用
真に重要な少量のドキュメントを.clinerulesフォルダに配置します（このフォルダは.gitignoreの対象にするのがおすすめです）。
.clinerulesの容量を最適に保つために、clinerules-bankの中にカテゴリ別の詳細な指示を整理します。例えば：
- ドメイン変更時のルール
- フロントエンド変更時のルール
など
これにより、タスクごとに.clinerulesファイル内のコンテキスト量を最適化できます。
2. VS Codeのルートフォルダを最小化する
複数のソリューションを含む大規模リポジトリを扱う場合、変更対象外のコードが誤って修正されるリスクがあります。
解決策：リポジトリルート全体ではなく、ソリューション単位やプロジェクト単位でVS Codeを開く新しいアプローチを採用します。
これにより、Clineは開いているフォルダ内のコードのみを検索・編集するようになり、スコープが自然と限定されます。
3. tasksフォルダによるタスク管理
Clineとのチャット履歴だけでなく、タスク情報をローカルに体系的に保存することで、過去の経験や制約を効果的に記録・活用できます。
実装方法
- プロジェクトルートに
tasksフォルダを作成 -
001_task_name.mdのような命名規則でタスクファイルを作成 - タスクファイルには以下を詳細に記述：
- 参照すべきファイル
- 必要な変更内容
- 使用すべき言語機能やアプローチ
- 制約条件
タスク例
以下は実際に使用したタスク例です：
005_improve_event_handling.md
AspireEventSample.ApiService/Grains/EventConsumerGrain.cs
をリファクタリングしたい。
OnNextAsync の中で行っていることを、できれば汎用化して純粋関数化したい。
それによって、同じコードを使い回して、Readmodel Updatorを実行できるようにしたい
今やっている、OrleansのイベントストリーミングでRead Model を作成する方法
かつ、コンソールアプリで最初のイベントから今まで、もしくは過去の何処かから今までと実行できるようにしたい。
それを行うための抽象化を行いたいです。
つまり純粋関数を持つクラスを作り、
AspireEventSample.ApiService/Grains/EventConsumerGrain.cs
から呼び出す機能を作る。
ただ、このタスクでは計画するだけです。
このファイルの下部に計画をよく考えて記入してください。必要なファイルの読み込みなど調査を行い、できるだけ具体的に計画してください。
チャットではなく、このファイル
clinerules_bank/tasks/005_improve_event_handling.md
を編集して、下に現在の設計を書いてください。
+++++++++++以下に計画を書く+++++++++++
タスク実行の流れ
-
計画フェーズ：まずタスクファイルに計画を詳細に立てさせる
clinerules_bank/tasks/005_improve_event_handling.md に書かれていることを忠実に実行して -
計画の評価と調整：計画が意図と異なる場合は、新たなタスクファイルで方向性を調整
- タスク5の結果:
- タスク6での調整:
- タスク7での進展:
- タスク8での完成:
-
実装フェーズ：満足できる計画ができたら、実際のコード変更を指示
clinerules_bank/tasks/008_readmodel.md に書き込んだ実装をコードに反映して
ポイント
-
タスクファイルに指示を書く際は、ファイル名を明示的に指定することが効果的
チャットではなく、このファイル clinerules_bank/tasks/005_improve_event_handling.md を編集して、下に現在の設計を書いてください。 +++++++++++以下に計画を書く+++++++++++ -
簡単なタスクは直接指示できますが、複雑なタスクは計画→調整→実装の段階的アプローチが有効
結論：AIとの効果的な協業のために
これらの新しいアプローチを活用することで、大規模な誤修正を防ぎ、品質の高いコード生成が可能になります。Vive Codingのように「動けば良い」という姿勢ではなく、設計の質を保ちながら開発速度を向上させることが重要です。
特にコアなドメインやフレームワーク開発では、コードは開発者の意図を正確に反映し、自分で書いた場合と同等以上の品質であるべきです。漠然とした指示でAIにコードを書かせると、技術的負債を即座に抱えるリスクがあります。
最近のClineとSonnet 3.7を活用した開発では、適切な指示と設計を与えれば、正確なコードを迅速に生成できるようになってきました。そのため、影響範囲の大きいコードに関しては、良い設計を行うことがより一層重要になっています。
AIが一発で正解を出せない場合には、修正方針を示し、正しい方向に導く開発者のスキルがまだ必要です。数年後にはAIの能力がさらに向上し、より大きなコンテキストを理解して正確なコードを生成できるようになるでしょうが、現段階では「開発者が作れるレベルのプログラムをAIと共同で効率的に開発する」という考え方が現実的です。
この記事では、Sonnet 3.7の現在のコーディングスキルを考慮した上で、効率的にコンテキストを提供する新しいアプローチの一例を紹介しました。これらの手法は今後数ヶ月で最適化が進み、さらに良い方法が生まれるでしょうが、現時点での知見として共有させていただきました。
Discussion