「プレーンファイル」戦略とは何だったのか
ここまで説明してきたように、ClineやClaude Code、Kiroといったコーディングエージェントはいずれも「プレーンファイル戦略」を採用しています。各ツールは独自の方式を取っていますが、これらの戦略には共通する構造が見えてきます。
プレーンファイル戦略を採用するどのコーディングエージェントでも、扱うファイルは大きく2つの役割に分けられます。
ひとつはルールファイルです。ルールファイルは、エージェントに常時参照させるための規約や前提、制約を記載したファイルで、Clineでは./clinerules/、Claude Codeでは./CLAUDE.md、Kiroでは.kiro/steering/がこれに当たります。これらは生成時に必ず読み込まれ、プロジェクトや組織、個人ごとの基盤的な方針を定め、生成結果が方針から逸れないようにする役割を担っています。
もうひとつはメモリファイルです。メモリファイルは、開発の進行に応じて更新される作業中の知識や決定事項を扱い、Clineでは./memory-bank/がプロジェクト単位、Kiroでは.kiro/specs/がセッションや機能単位で用いられます。メモリファイルには、要件や設計、タスク、進捗、既知の課題などを記録し、次回以降の作業でも参照できるようにすることで、コーディングエージェントは「どこまで進んでいるか」「どんな方針で進めているか」を毎回明示的に与えられ、一貫性を保ったまま作業を継続できるようになります。
ただし、この2種類のファイルは、数や粒度を増やせば必ずしも性能が向上するとは限りません。読み込ませるファイルが多すぎると、前述した「Lost in the Middle」によるコンテキストの溢れが発生します。また、大量のルールに矛盾する内容や不要な情報が残っていると、正誤を判断できないまま推論が引きずられる「チェーホフの銃の誤謬」（引用：『LLMのプロンプトエンジニアリング』）と呼ばれる現象も起こります。したがって、プレーンファイルを常にクリーンな状態に保つ必要があり、この点では「インデックス化」戦略と大きく変わりません。
さらに、ここで紹介した状況も今後変化していく可能性があります。ルールファイルを標準化する動きとして、OpenAIが2025年8月に公開した「AGENTS.md」には複数の製品や企業が賛同を表明しており、その動向が注目されています。また、これまでMemory Bank戦略を推進していたClineも、Kiroの仕様駆動開発に近い「deep-planning」というコマンドを実装し始めており、今後の発展を継続的に注視していく必要があります。
おわりに
今回はコンテキストエンジニアリングの中の「長期記憶」にフォーカスし、特に実装例の多い「プレーンファイル戦略」を深堀りしました。「インデックス化」も含めて、コンテキストエンジニアリングにおける文脈や立ち位置を理解していくことで、コーディングエージェントをより効率的に扱うことができるでしょう。
