📝

開発記録取得方法の改善 ハイブリッド自動記録方式の導入(開発日記 No.071)

に公開

関連リンク

はじめに

昨日は、品質ダッシュボードのガイドをRule化する作業を完了しました。今日は、最近少し課題を感じている、開発記録の取得方法を改善することに取り組みます。よりスムーズで効率的な記録方法を目指して、色々と試行錯誤していきたいと思います。

背景と目的

最近、開発記録の取得がうまくいかないことが増えてきました。原因は、ワークスペースの容量が肥大化し、LLMが処理するコンテキスト量が増えたことで、会話の最初に指示する開発記録の取得に関するルールをLLMが忘れてしまうことにあると考えています。そこで、この問題を解決するために、いくつかの対応策を検討し、より良い方法を見つけ出すことを目的とします。

検討内容

まず、現状の課題を分析しました。

  1. ワークスペース肥大化によるコンテキスト過多
  2. LLMが開発記録取得ルールを途中で忘れる
  3. 逐次記録方式の負担

これらの課題を踏まえ、以下の対応案を検討しました。

  • 案1: ワークスペース最小化 + 外部記録: ワークスペースをその日の作業対象のプロジェクトのみで開き、開発記録は外部フォルダに保存する。
  • 案2: 対話終了時の一括記録: 対話の最後にまとめて開発記録を残す。
  • 追加案3: 開発記録取得ロジックの分離・単純化: 専用の記録コマンドを作成し、記録専用の軽量テンプレートを使用する。
  • 追加案4: ハイブリッド方式: 短いやり取りは逐次記録し、コード生成など大量出力は要約のみ記録する。

これらの案を比較検討した結果、開発者の負担を最小限にしつつ、コンテキスト量を削減できるハイブリッド自動記録方式が最適であるという結論に至りました。

実装内容

ハイブリッド自動記録方式では、以下の要素を組み合わせます。

  1. 最小限の初期化コマンド: 会話開始時に1回だけ実行し、ファイル作成と基本情報のみ初期化します。
  2. 自動対応型記録方式: 通常の対話は完全自動記録し、大量生成時は要約を自動記録し、定期的なチェックポイントで自動保存します。
  3. 記録コマンドの軽量化: Auto_Logging_Guide.md の必須部分のみ抽出し、重要ルールを短く簡潔に記述します。
  4. コンテキスト最適化: 開発記録専用のプロジェクトフォルダを作成し、不要ファイルを自動で除外します。

具体的な実装イメージとしては、以下のようなコマンドを使用します。

@dev-log-start テーマ="開発テーマ" records_path="/home/centervil/repos/Docs/dev-records"

この方式により、開発対象のみのワークスペースで容量を削減し、記録ディレクトリは絶対パスで参照することで、ファイル管理を整理することができます。

技術的なポイント

今回の実装における技術的なポイントは、MCPサーバーの "fileSystem" 機能、もしくはそれに類似の自作MCPを活用して、外部ファイル操作を行う点です。これにより、開発対象プロジェクトのみのワークスペースで作業しながら、開発記録を別の場所に保存することが可能になります。

所感

今回の開発では、LLMを利用した開発におけるコンテキスト量の重要性を改めて認識しました。ワークスペースの肥大化が、開発効率や品質に悪影響を及ぼす可能性があることを考えると、コンテキスト量を意識した開発が不可欠だと感じました。

また、開発記録の取得方法を改善するにあたり、開発者の負担を最小限に抑えることの重要性も痛感しました。自動化を進めることで、開発者はより創造的な作業に集中できるようになるはずです。

今後の課題

今回の改善で、開発記録の取得はかなりスムーズになるはずですが、まだいくつかの課題が残っています。

  • 記録の精度をさらに向上させるための工夫
  • 様々な開発スタイルに合わせた柔軟な記録方法の提供
  • 記録されたデータの活用方法の検討

これらの課題を解決するために、今後も継続的に改善に取り組んでいきたいと思います。

まとめ

今回の開発では、開発記録の取得方法を改善するために、ハイブリッド自動記録方式を導入しました。この方式により、コンテキスト量の削減と自動化レベルの維持を両立し、より効率的な開発記録の取得が可能になります。今後は、記録の精度向上や活用方法の検討など、さらなる改善に取り組んでいきたいと思います。

GitHubで編集を提案

Discussion