AIコーディングエージェントが抱える根本的な課題のひとつに「コンテキスト喪失」があります。LLMはセッションをまたぐと記憶を失い、前回合意した設計方針もライブラリの選定理由もゼロに戻ります。小規模なプロジェクトでは問題になりにくいものの、コードベースが成長するにつれてこの喪失のコストは加速度的に増大します。
この課題に対して、現在いくつかのアプローチが実践されています。それぞれに明確なメリットがある一方、共通する構造的なボトルネックも見えてきました。本記事では、既存アプローチの整理と、sqlewが採用するアーキテクチャについて解説します。
既存アプローチの整理
仕様書ドリブン開発
AWS KiroやGitHub Spec Kitに代表されるアプローチです。事前に仕様書を作成し、AIに「何を作るか（What）」を明確に伝えてからコード生成に入ります。
組織での開発経験がある方には馴染みやすく、要件定義から実装までの流れが構造化されている点が強みです。ただし、仕様書自体の管理コストが発生します。プロジェクトが進むにつれて仕様書間の矛盾や内容の重複が生まれ、AIが古い仕様と新しい仕様の間で混乱するケースがあります。また仕様書をどの粒度で分割するかという設計判断も、チームの負担になります。
CLAUDE.md・AGENTS.mdへのルール記載
もっとも広く実践されているアプローチです。プロジェクトルートにコンテキストファイルを置き、コーディング規約やアーキテクチャ方針を記載しておく。AIが毎セッション読み込むことで文脈を引き継ぎます。
導入の敷居が低く、短期的には効果が高い手法です。しかしプロジェクトの進行とともにドキュメントが肥大化しやすいという課題があります。肥大化するとAIがルールの一部を省略することがあり、研究でもコンテキスト長の増大がLLMの推論精度を低下させることが報告されています。「正しい情報がコンテキストにあるのに活用されない」というコンテキスト汚染が起こりがちです。
ドキュメント化とSkillsでの再利用
特定の手順やパターンをMarkdownで文書化し、Claude CodeのSkillsなどで再利用するアプローチです。AIによる自動化との親和性が高く、パターン化しやすい作業には効果的です。
ただし、プロジェクトの進行に伴ってドキュメントの内容が実態と乖離していく問題は避けられません。古くなったドキュメントの定期的なメンテナンスが必要で、この管理コストは仕様書ドリブンと同様の課題を抱えています。
共通するボトルネック
これらのアプローチはいずれも有効であり、プロジェクトの規模や状況に応じて使い分けるべきものです。しかし共通して見えてくるのは、最終的に人間の管理作業がボトルネックになるという構造です。ドキュメントを書く、更新する、整合性を保つ、不要なものを削除する。こうした管理作業は、プロジェクトが大きくなるほど重くなります。
前回の記事で紹介したVasilopoulos（2026）の論文でも、108,000行のコードに対して26,000行のドキュメントが必要になり、週1〜2時間のメンテナンスコストが発生していました。コンテキストの永続化を実現するほど、その維持管理が「第二の複雑性」として開発を圧迫していく。これが現状のジレンマです。
sqlewのアプローチ
sqlewは、このジレンマに対して「記録と取得の両方をAIに任せる」というアーキテクチャで応えます。
「What」に加えて「Why」を自動記録する
sqlewの核心は、AIエージェントのプランモードと連動した自動ADR（Architecture Decision Record）記録にあります。
Claude CodeやCodexなどのAIコーディングツールには、実装前に計画を立てるプランモードが搭載されています。sqlewはこのプランモードに連動し、AIが計画を立てて人間が承認するたびに、その計画に含まれる設計方針（What）と、なぜその方針にしたか（Why）をSQLデータベースに自動で記録します。
開発者が特別な操作をする必要はありません。普段どおりにプランモードを使って開発を進めるだけで、設計判断とその根拠がバックグラウンドで蓄積されていきます。
必要な文脈だけをJust-in-Timeでサジェスト
記録された情報は、次回以降のプラン作成時に自動でサジェストされます。ここがsqlewのアーキテクチャの要です。
AIが新しいタスクのプランを作成する際、sqlewは過去の記録から類似する内容を検索し、関連する方針や誓約事項だけをコンテキストに注入します。今のタスクに関係のない過去の記録は読み込まれません。
これにより、2つの問題を同時に解決しています。
- コンテキスト汚染の防止：タスクに無関係な情報がコンテキストウィンドウに入らないため、推論精度の低下を防げる
- コンテキストウィンドウの圧迫回避：全量をダンプするのではなく、必要な分だけ取得するため、ウィンドウの容量を効率的に使える
CLAUDE.mdの「全量を毎回読み込む」アプローチとは対照的に、sqlewは「必要なものだけを必要なときに渡す」選択的な取得を行います。
データベースがAI用ナレッジベースに育つ
sqlewの効果は、ナレッジベースの蓄積とともに加速します。
プロジェクトの初期は記録が少なく、サジェストされる情報も限られています。しかしターンを重ねるごとにデータベースに設計判断が蓄積され、AIが参照できる文脈が豊富になっていきます。私たちの対照実験では、過去の設計判断への参照頻度がプロジェクト後半に向けて加速度的に上昇する（+21% → +64% → +137%）という正のフィードバックループが観察されました。
AIの思考の質が変わり、サジェストの効果が増していく。具体的には、プロジェクトが進んだ段階でAIがこのような提案をするようになります。
「過去にこういう理由でこの設計にしている記録が見つかりました。今回の指示の内容を実装するには大幅なリファクタリングが必要になります。一貫性を犠牲にしてバイパスして実装することもできますが、どちらがいいですか？」
「将来的に実装予定と記録されている機能とコンフリクトする可能性があります。優先順位はどちらが高いですか？」
こうした提案は、AIが過去の設計意図を「知っている」からこそ可能になるものです。指示を待つだけの受動的なツールではなく、プロジェクトの文脈を踏まえて先回りできるパートナーとして機能します。ターン数が多い大規模プロジェクトほど、この効果は顕著になります。
人的コスト無しでのコンテキスト永続化
sqlewのアーキテクチャが既存アプローチと根本的に異なるのは、記録と取得の両方をAIが行う点です。
従来のADRは人間が書き、人間が参照するものでした。この「書き手と読み手が同一人物」という負担が、ADRの継続運用を困難にしてきた根本原因です。sqlewでは、書き手も読み手もAI（LLMエージェント）であり、人間の役割はプランの承認のみに限定されます。
ドキュメントを手動でメンテナンスする必要がないため、前述したドキュメント管理の「第二の複雑性」が発生しません。人的コスト無しで、ドキュメントベースのコンテキスト永続化施策と同等以上の効果を実現する。これがsqlewのアーキテクチャが目指すところです。
sqlewの弱点
正直にお伝えするとsqlewは万能ではありません。導入を検討される方に対して、率直に弱点をお伝えします。
途中導入だと効果は限定的
sqlewがもっとも効果を発揮するのは、プロジェクトの初期から設計理由を記録できた場合です。既存のコードベースから仕様を抽出することはAIにも可能ですが、「なぜその仕様になったのか（Why）」を事後的に推論することは困難です。
途中導入時のノウハウ
ただし、既存プロジェクトへの導入が不可能というわけではありません。仕様設計の議事録やGitHubのIssue・PRの議論から、AIに設計理由を推論させて追加する方法は実用的です。私たちの実験でも、途中からADRを導入した条件での実験では、エビデンスの質はやや劣るものの、方針への参照頻度では初期導入に近い効果が見られました。
導入初期のオーバーヘッド
ナレッジベースが育っていない導入初期は、プラン作成のたびにsqlewがサジェストを確認するものの、該当する過去の記録がなく0件が返ってくる場面が続きます。このサジェスト確認自体に数百トークンの消費が発生するため、短期的にはオーバーヘッドのほうが大きく感じる時期があります。
私たちの実験でも、最初の数ターンではsqlewありの条件がやや不利に見える場面がありました。しかしプロジェクトが複雑になるにつれて、蓄積された設計判断の効果がオーバーヘッドを大きく上回っていきます。
まとめ
コンテキスト喪失に対する既存アプローチには、それぞれの強みがあります。仕様書ドリブンの構造化された明確さ、CLAUDE.mdの手軽さ、Skillsの再利用性。sqlewはこれらを置き換えるものではなく、CLAUDE.mdと共存するかたちで、動的に蓄積される設計文脈を補完します。
「何を作るか」だけでなく「なぜそう作るのか」を、人間の手を介さずに蓄積し、必要なときに必要なだけ届ける。sqlewは、AIコーディングにおけるコンテキスト永続化の実用的な選択肢として開発を続けています。
参考文献
- Kitayama, S. (2026). "Rediscovering Architectural Decision Records: How Persistent Design Context Improves LLM Code Generation" — https://doi.org/10.36227/techrxiv.177205025.54351571/v1
- Vasilopoulos, A. (2026). "Codified Context: Infrastructure for AI Agents in a Complex Codebase" — arXiv:2602.20478 — https://doi.org/10.48550/arXiv.2602.20478
- Chroma Research. "Context Rot: How Increasing Input Tokens Impacts LLM Performance" — https://research.trychroma.com/context-rot
- Liu, N. F. et al. (2024). "Lost in the Middle: How Language Models Use Long Contexts" — https://doi.org/10.1162/tacl_a_00638
- Anthropic. (2025). "Effective Context Engineering for AI Agents" — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
