アンチパターン④「コンテキスト喪失」

AIは「忘れる」

AIとの会話には、重要な制約があります。

AIは過去のコンテキストを「忘れる」。

新しいセッションを開始すると、以前の会話は失われます。コンテキストウィンドウの限界を超えると、古い情報は切り捨てられます。

この「忘却」が、深刻な問題を引き起こします。

忘却による矛盾

ある開発者の証言があります。

「最初は綺麗に動いていた。でも崩壊した。何が何に接続されているか、誰も追跡できなかった。ミドルウェアが6つのファイルに散らばっていた。メンタルモデルがなく、ただバイブスだけ。デバッグは考古学のようだった。結局、ゼロから書き直すしかなかった」

なぜこうなったか:

セッション1で認証システムを設計
セッション2でAPIを追加（認証の詳細を忘れている）
セッション3でフロントエンドを作成（全体像を忘れている）
セッション4で統合（過去の決定を忘れている）

各セッションで、AIは以前の決定を「忘れて」いました。結果として、矛盾したコードが生成されました。

矛盾の例

コンテキスト喪失による矛盾の典型例を見てみましょう。

例1: 認証方式の混在

セッション1:
「認証にはJWTを使ってください」
→ JWT認証を実装

セッション2:
（コンテキスト喪失）
「ログイン機能を追加して」
→ セッションベース認証を実装

結果:
- 2つの認証システムが混在
- 一部のエンドポイントはJWT、一部はセッション
- どちらを使うべきか不明

例2: 命名規則の不一致

セッション1:
「ユーザー関連の関数はuserXxxで命名」
→ getUserById, updateUser, deleteUser

セッション2:
（コンテキスト喪失）
「ユーザープロフィール機能を追加」
→ fetchProfile, saveProfileData, removeProfile

結果:
- 命名規則が混在
- コードの一貫性がない
- どちらのパターンに従うべきか不明

AI生成コードの「ブラックボックス」問題

コンテキスト喪失の最終的な結果は、ブラックボックス の誕生です。

「将来のメンテナーは、明確な設計がなく、コメントも最小限で、ランダムな再生成で構築されたロジックを持つブラックボックスを引き継ぐことになる」

ブラックボックスの特徴:

設計意図が不明
ドキュメントがない
コメントがない
一貫性がない
修正すると他が壊れる

このようなコードベースのメンテナンスは、悪夢です。

AI開発でコンテキストを維持する方法

コンテキスト喪失を防ぐための方法があります。

方法1: CLAUDE.mdの活用

プロジェクトのルートに CLAUDE.md や CONTEXT.md を作成し、重要な決定を記録。

# プロジェクトコンテキスト

## 推奨される技術スタックと構成
- フロントエンド: React + TypeScript
- バックエンド: Node.js + Express
- データベース: PostgreSQL
- 認証: JWT

## 命名規則
- 関数: camelCase
- コンポーネント: PascalCase
- ファイル: kebab-case

## 認証機能の実装ポイント
- JWTを使用
- トークンはlocalStorageに保存
- リフレッシュトークンは使用しない

各セッションの開始時にこのファイルを読み込ませることで、コンテキストを維持できます。

方法2: ADR（Architecture Decision Records）

重要な技術的決定を記録。

# ADR-001: 認証方式

## ステータス
決定済み

## AIに伝えるべきコンテキスト情報
ユーザー認証の方式を決める必要がある

## 決定
JWTを採用する

## 理由
- ステートレス
- スケーラブル
- マイクロサービスに適合

## 結果
- すべてのAPIでJWT認証を使用
- セッションベース認証は使用しない

セッション間の引き継ぎ

新しいセッションを開始するときは、コンテキストを引き継ぐ必要があります。

引き継ぎテンプレート:

前回のセッションで以下を実装しました:
- ユーザー認証（JWT）
- 商品一覧API

今日は以下を実装します:
- 商品詳細API
- カート機能

以下の規則に従ってください:
- 認証にはJWTを使用
- 関数名はcamelCase
- エラーはAppErrorクラスを使用

このように、明示的にコンテキストを渡す ことで、矛盾を防げます。

コードコメントの重要性

AIが生成したコードには、コメントを追加 しましょう。

追加すべきコメント:

なぜこのアプローチを選んだか
- 将来の自分（とAI）のため
他のコードとの関連
- どこと接続しているか
注意事項
- 変更時に気をつけること

例:

// JWT認証を使用（ADR-001参照）
// セッション認証は使用しない
// トークンはAuthorizationヘッダーで送信
function authenticateRequest(req, res, next) {
  // ...
}

ドキュメントの維持

コードだけでなく、ドキュメントも維持 しましょう。

維持すべきドキュメント:

README.md
- プロジェクト概要
- セットアップ手順
- アーキテクチャ概要
API仕様
- エンドポイント一覧
- リクエスト/レスポンス形式
データモデル
- テーブル構造
- リレーション
デプロイ手順
- 環境変数
- デプロイフロー

これらのドキュメントは、AIにコンテキストを渡すためにも使えます。

「1ファイル1責務」の原則

コンテキスト喪失の影響を最小化するために、1ファイル1責務 を守りましょう。

悪い例:

src/
  utils.js      # 500行、雑多な関数の寄せ集め
  helpers.js    # 300行、utilsと重複あり

良い例:

src/
  auth/
    jwt.js        # JWT関連の関数のみ
    middleware.js # 認証ミドルウェアのみ
  api/
    users.js      # ユーザーAPI
    products.js   # 商品API

ファイルが明確に分割されていれば、AIがコンテキストを失っても、影響範囲を限定できます。

この事例から学ぶべき教訓

「コンテキスト喪失」から学ぶべきことは以下の通りです。

AIは過去のコンテキストを忘れる
- セッションをまたぐと矛盾が生じる
コンテキストを明示的に維持せよ
- CLAUDE.md、ADR、ドキュメント
セッション間で引き継ぎを行う
- 前回の実装、今回のタスク、規則を明示
コメントとドキュメントを書く
- 将来の自分とAIのため
1ファイル1責務を守る
- 影響範囲を限定する

まとめ：重要ポイントの振り返り

AIは過去のコンテキストを 忘れる
結果として 矛盾したコード が生成される
最終的には誰も理解できない ブラックボックス になる
CLAUDE.md、ADR、ドキュメント でコンテキストを維持
セッション開始時に コンテキストを明示的に渡す
教訓：AIは忘れる。あなたが覚えておけ

コンテキスト喪失：AIが設計を忘れる問題と対策