この記事はLLMによるADRの自動更新：設計知識の継続的な記録と活用の内容を再構築したものです。より詳しい技術的な解説や研究的な内容については、元記事をご参照ください。

GitHub Copilotなどのコード生成AI（LLM）は、コードの理解力が飛躍的に向上し、開発現場での活用が広がっています。しかし、実際にコーディングを任せてみると、思わぬ困難に直面することが多いのではないでしょうか。

例えば：

これらの問題の多くは、LLMが「プロジェクトの文脈」を十分に理解できていないことに起因します。では、どうすればLLMにプロジェクトの設計意図を効果的に伝えられるのでしょうか？

この記事では、LLMとの効果的な協業を実現するために、ADR（Architecture Decision Records）を活用する方法を紹介します。

TL;DR

LLMの課題：なぜコンテキストを忘れるのか

最近のLLMは非常に優秀で、コード生成やレビュー、バグ修正などで大きな支援になります。しかし、研究によれば、LLMの長期的な対話能力は非常に限定的だとされています。

実際の開発でこんな経験はありませんか？

これらの問題は、LLMが本質的にステートレス（状態を持たない）であることに起因します。では、どうすれば解決できるのでしょうか？

ここで注目したいのが、ADR（Architecture Decision Records）です。ADRは2011年にMichael Nygardによって提案された、設計上の意思決定を記録する手法です。

基本的なADRテンプレートはこんな感じです：

# ADR-0001: ［決定のタイトル］

## ステータス
［提案済み/承認済み/破棄/更新済み］

## 背景
［この決定が必要になった背景・課題］

## 決定
［具体的に何を決定したか］

## 結果
［この決定による影響・期待される効果］

## 注意点
［実装時の注意点・制約事項］

ADRをLLMに提供する方法：

関連ADRの参照

ここからはADR-0001で定義した認証フローに従って
実装を進めていきます：
[ADRの内容をペースト]

制約条件の説明

このプロジェクトでは以下のADRで定義された
技術スタックを使用します：
[ADRの内容をペースト]

設計方針の共有

ADR-0003で決定したように、このマイクロサービスは
以下の責務を持ちます：
[ADRの内容をペースト]

LLMとの協業において、ADRは「プロジェクトの記憶装置」として機能します。適切に管理されたADRがあれば、LLMはプロジェクトの文脈を理解し、一貫性のある支援を提供できます。

まずは小さく始めて、チームに合った活用方法を見つけていくことをお勧めします。