はじめに

「設計段階でちゃんとテストできたらいいのに...」

こんな風に思ったことはありませんか？特に状態管理のような複雑な機能を設計するとき、実装前に動作を確認できないのってすごく不安ですよね。今回は、そんなモヤモヤを解決する方法として、LLMを使った設計アプローチを紹介します。具体的には、Webアプリのデプロイ機能にあるロールバック機能を例に、どんな風にLLMを活用できるのか、実践的に見ていきましょう。

LLMと設計を進める

設計プロセスにおいて、LLMとの対話は大きく3つのフェーズで行いました：

Phase 1: 初期設計の探索

最初の対話では、基本的なデータ構造の設計を探りました：

Input to LLM:

rollbackを実装したいので、状態をjsonで管理したい。
1 -> 2 -> rollback -> 1
1 -> 2 -> 3 -> rollback -> 2 -> 4 -> rollback -> 2
のような操作を実現するデータ構造を提案して。

Phase 2: 設計パターンの検討

初期設計を得た後、既存のベストプラクティスを探るため、以下のような対話を行いました：

Input to LLM:

状態管理とロールバックの実装に関して、一般的なデザインパターンはある？
それぞれの利点と欠点を教えて。

Phase 3: 具体的な実装設計

最後に、選択したパターンに基づいて具体的な実装を検討しました：

Input to LLM:

Mementoパターンを使って、具体的なJSONスキーマを設計したい。
状態履歴とメタデータを含める必要がある。

LLMと一緒に設計を進めてみた

Step 1: まずは基本構造を考えよう

最初は、とにかく「これって実現できるの？」というところから始めました。LLMに投げかけた最初の質問は、こんな感じです：

ねぇ、ロールバック機能を作りたいんだけど、状態をJSONで管理するとしたらどんな感じになると思う？
例えば、こんな感じの操作ができるようにしたいんだけど：
1 -> 2 -> rollback -> 1
1 -> 2 -> 3 -> rollback -> 2 -> 4 -> rollback -> 2

これに対してLLMくん、なかなか良い提案をしてくれました：

class StateManager:
    def __init__(self):
        # 状態の履歴を配列で管理
        self.state_history: List[Dict[str, Any]] = []
        # 現在の状態を指すインデックス
        self.current_index: int = -1

この提案のイイところ：

履歴を配列で管理するのは直感的でシンプル
インデックスで現在位置を管理するのは分かりやすい
拡張性もありそう

Step 2: もっと良いやり方を探ってみよう

「でもさ、こういうの、もっと良いやり方があるんじゃない？」

そう思って、LLMに「この手の実装って、何かベストプラクティスとかないの？」って聞いてみました。すると、興味深い提案が返ってきました。

Commandパターン

interface Command {
  execute(): void;
  undo(): void;
}

このパターンの特徴：

各操作を独立したオブジェクトとして管理
操作の履歴を詳細に記録できる
複雑な操作もサポートできる
ただし、実装が少し複雑になりがち

Mementoパターン

class Memento {
  constructor(private state: any, private timestamp: Date) {}
}

こっちの特徴：

シンプルで分かりやすい
状態のスナップショットを管理しやすい
実装が比較的楽
ただし、細かい操作の制御は難しいかも

正直、どっちにするか迷いました。でも、今回のケースではシンプルさを重視して、Mementoパターンを採用することにしました。

Step 3: 具体的な状態管理を設計してみよう

「じゃあ、具体的にJSONってどんな構造にする？」

この質問に対して、LLMは以下のような構造を提案してきました：

{
  "mementos": [
    {
      "snapshot": {
        "value": 1,
        "data": "initial state",
        "deployInfo": {
          "version": "1.0.0",
          "timestamp": "2024-11-15T10:00:00",
          "deployer": "tanaka"
        }
      },
      "metadata": {
        "version": 1,
        "timestamp": "2024-11-15T10:00:00",
        "description": "初期デプロイ"
      }
    }
  ],
  "currentIndex": 0
}

これ、なかなか良いですよね：

スナップショットとメタデータを分けて管理
デプロイ情報もちゃんと含まれている
タイムスタンプや説明文で追跡可能性も確保

Step 4: 実際の動きを確認してみよう

設計ができたら、次は実際の動きを確認。以下のような操作シーケンスを考えてみました：

Undo操作のケース

// currentIndexを1減らして前の状態に戻る
const undo = () => {
  if (currentIndex > 0) {
    currentIndex--;
    return mementos[currentIndex].snapshot;
  }
  throw new Error("これ以上戻れません！");
};

Redo操作のケース

// currentIndexを1増やして次の状態に進む
const redo = () => {
  if (currentIndex < mementos.length - 1) {
    currentIndex++;
    return mementos[currentIndex].snapshot;
  }
  throw new Error("これ以上進めません！");
};

新しい状態の追加

// 新しい状態を追加する時は、current以降の履歴を消して追加
const addState = (newState) => {
  mementos.splice(currentIndex + 1);
  mementos.push({
    snapshot: newState,
    metadata: {
      version: currentIndex + 2,
      timestamp: new Date().toISOString()
    }
  });
  currentIndex++;
};

エッジケースの確認のため、以下のようなインタラクティブな対話をLLMと行いました：

Input to LLM:

以下の操作シーケンスでどうなる？

1 -> 2 -> 3 (add)
undo
undo
4を追加
redo

LLMの回答:

各ステップでの状態変化を確認します：

1. 初期状態: [1]
   currentIndex: 0

2. 2を追加: [1, 2]
   currentIndex: 1

3. 3を追加: [1, 2, 3]
   currentIndex: 2

4. undo実行: [1, 2, 3]
   currentIndex: 1
   現在の値: 2

5. もう一度undo: [1, 2, 3]
   currentIndex: 0
   現在の値: 1

6. 4を追加: [1, 4]
   // ここで重要: currentIndex以降の履歴(2,3)は削除される
   currentIndex: 1

7. redo実行: redoできる履歴がないためエラー
   // 4の追加時に2,3の履歴が削除されているため

この動的な確認により、以下の重要な点が明確になりました：

undo/redoの状態管理
履歴の分岐処理
エラー発生条件

さらに、エッジケースについても確認を行いました：

Input to LLM:

以下のようなケースで、どのような問題が発生する可能性がある？

1. 最初の状態に戻ろうとした場合
2. 履歴の最後まで進んだ後の操作
3. ロールバック後に新しい状態を追加

LLMの回答:
各ケースについて以下のような問題点と対策が提示されました：

初期状態へのロールバック

// 提案された対策
if (currentIndex <= 0) {
  throw new StateManagementError('INITIAL_STATE_REACHED');
}

最終状態での操作

// 提案された対策
if (currentIndex >= mementos.length - 1) {
  throw new StateManagementError('FINAL_STATE_REACHED');
}

分岐履歴の処理

// 提案された実装
function addStateAfterRollback(newState) {
  // ロールバック後の履歴を適切に管理
  mementos.splice(currentIndex + 1);
  addNewState(newState);
}

Step 5: 仕様書にまとめよう

設計が固まってきたところで、実装のための仕様書を作成しました。

データ構造の定義

// 基本的な状態を表す型
interface State {
  value: number;
  data: string;
  deployInfo: {
    version: string;
    timestamp: string;
    deployer: string;
  };
}

// メタデータの型
interface Metadata {
  version: number;
  timestamp: string;
  description: string;
  tags?: string[];
}

// スナップショット全体の型
interface Snapshot {
  state: State;
  metadata: Metadata;
}

// システム全体の型
interface StateManagement {
  snapshots: Snapshot[];
  currentIndex: number;
  maxHistory: number;
}

主要な操作の仕様

状態の追加

interface AddStateOptions {
  description?: string;
  tags?: string[];
}

function addState(state: State, options?: AddStateOptions): void;

ロールバック操作

interface RollbackOptions {
  preserveHistory?: boolean;
}

function rollback(targetIndex: number, options?: RollbackOptions): void;

状態の取得

interface GetStateOptions {
  includeMetadata?: boolean;
}

function getCurrentState(options?: GetStateOptions): State;

エラーハンドリング

想定されるエラーケース：

無効なインデックスへのロールバック試行
状態データの不整合
メモリ制限の超過

対応方針：

各操作の前に必ず状態の整合性をチェック
エラーは専用の型で定義して明示的に処理
ロギングによる追跡可能性の確保

この設計アプローチの良かったところ

1. 動的な設計検証ができた！

LLMと対話しながら設計を進められた
実装前に問題点を発見できた
設計の改善サイクルが早かった

2. パターンの選択が適切にできた

既存のデザインパターンを活用
プロジェクトに合った実装方法を選択
拡張性と保守性のバランスが取れた

3. 問題点の早期発見

エッジケースを事前に検討できた
実装上の課題が明確になった
設計の妥当性を確認できた

まとめと今後の展望

得られた成果

設計プロセスの改善
- LLMとの対話による設計の検証
- 早期のフィードバック獲得
- 柔軟な設計の改善
技術的な成果
- 堅牢な状態管理システムの設計
- 明確な仕様の策定
- エラーケースへの対応方針の確立
プロジェクト管理面での効果
- 設計段階でのリスク低減
- チーム内での共通理解の促進
- 実装工数の正確な見積もり

今後の可能性

この経験から、以下のような展望が見えてきました：

設計プロセスの進化
- LLMを活用した設計レビュー
- 自動的な設計検証の可能性
- より効率的な設計手法の確立
機能の拡張
- より高度な状態管理機能の追加
- パフォーマンス最適化
- セキュリティ強化
チーム開発への応用
- 設計ドキュメントの自動生成
- コードレビューでの活用
- 知識共有の促進

最後に、この方法は特に以下のようなケースで効果を発揮すると感じました：

複雑な状態管理が必要なプロジェクト
チーム間での設計の共有が重要なケース
早期のフィードバックが求められる開発

みなさんも、ぜひプロジェクトでLLMを活用した設計アプローチを試してみてください！きっと新しい発見があるはずです。