soho-infra-ops

関連リンク¶

• ChatGPT(https://chatgpt.com/c/6a76c484-9e8c-83ee-8a9e-99b8594acd34)

概要¶

KITTやローカルLLMとの検討・調査・構築・問題対応を中断する際に、その時点の作業コンテキストをRedmineへ保存し、後日RedmineのチケットをLLMへ読み込ませることで作業を再開できる仕組みを検討する。

Redmine、MantisBT、Kanboard、ProjeQtOr、Tracを比較した結果、Tracker、Issue Relations、Journal、REST API、Custom Fieldsを組み合わせられるRedmineが、LLMの外部長期記憶および作業チェックポイント用途に最も適していると判断した。

背景¶

LLMとの長時間の検討や技術作業では、チャットセッションをまたいだ場合に、それまでの背景、実施済み作業、判断内容、未解決事項、次のアクションを再構築する必要がある。

そのため、LLMとの会話内容を単なるチャット履歴として保持するのではなく、管理アプリ上のチケットとして構造化して永続化し、必要に応じて関連チケットをたどりながら作業コンテキストを復元できる仕組みを構築したい。

検討した候補は以下。

• Redmine
• MantisBT
• Kanboard
• ProjeQtOr
• Trac

現時点ではRedmineを継続利用する方針とする。

作業内容¶

• Redmine REST APIを利用してLLMからIssueを新規作成できることを確認する
• Redmine REST APIを利用して既存Issueを更新できることを確認する
• IssueのDescriptionおよびJournalへLLMによる作業要約を保存する方式を決定する
• Issue Relationsを利用して関連する検討、作業、問題チケットを相互に関連付ける
• Trackerを利用して調査/検討、構築/作成、問題/バグを分類する
• Redmine REST APIからIssue、Journal、Relationsを取得し、LLMへコンテキストとして渡せることを確認する
• LLMが取得した情報から過去の作業状態を復元し、作業を再開できることを確認する
• 必要に応じてLLM連携用Custom Fieldsの追加を検討する

受け入れ条件¶

• LLMまたはredmine-kittからRedmine REST API経由で新規Issueを作成できる
• LLMまたはredmine-kittから既存Issueへ作業経過を追記できる
• 調査/検討、構築/作成、問題/バグをTrackerで分類できる
• 関連するIssue同士をIssue Relationsで関連付けできる
• Redmine REST APIからIssue本文を取得できる
• Redmine REST APIからJournalを取得できる
• Redmine REST APIからIssue Relationsを取得できる
• 取得したIssue情報をKITTまたはLLMへ入力することで、中断前の作業内容を十分に復元できる
• 作業再開後の新しい検討結果を同じIssueへ追記できる

実施手順¶

1. RedmineでREST APIを有効化する。
2. APIアクセス用ユーザーおよびAPIキーを準備する。
3. redmine-kittまたはHTTPクライアントからIssue取得を試験する。
4. 新規Issue作成を試験する。
5. 既存IssueへのJournal追加を試験する。
6. Issue Relationsの作成および取得方法を確認する。
7. LLMが中断時に生成する保存用テンプレートを定義する。
8. Descriptionには目的、背景、現在の状態、実施済み作業、判断、未解決事項、次のアクションを保存する。
9. 継続作業はJournalへ時系列で追記する。
10. 後日、Issue、Journal、RelationsをREST APIで取得してLLMへ入力し、作業を再開する。
11. 実運用を行い、必要に応じてCustom Fieldsやテンプレートを改善する。

推奨するLLM保存用構造は以下。

• 目的
• 背景
• 現在の状態
• 実施済み
• 判断・決定
• 未解決事項
• 次にやること
• 関連情報
• 関連Issue

確認方法¶

テスト用Issueを1件作成し、KITTまたはLLMとの作業内容を途中で要約してRedmineへ登録する。

その後、新しいLLMセッションからREST API経由で対象IssueのDescription、Journal、Relationsを取得し、その情報のみを基に以下を説明できることを確認する。

• 何を目的としていたか
• これまで何を実施したか
• どのような判断を行ったか
• 現在何が未解決か
• 次に何をすべきか
• どのIssueが関連しているか

さらに、その状態から実際に作業を継続し、結果を同じIssueへ追記できることを確認する。

リスク・注意点¶

• LLMが毎回自由形式で要約すると、後からコンテキストを復元する際の品質にばらつきが生じるため、保存フォーマットを固定する
• APIキーをLLMへのプロンプトやRedmineチケット本文へ直接保存しない
• Issue本文へパスワード、秘密鍵、APIトークン等の機密情報を記録しない
• 関連Issueを大量に自動取得するとLLMのコンテキスト量が増えるため、必要なRelationsだけを段階的に取得する
• Redmineを正式記録、Wiki.jsを長期ナレッジとして役割分担し、同一情報の無秩序な重複を避ける
• Kanboard等を追加する場合は、Redmineとの二重管理にならない明確な用途が発生した時点で再検討する

関連Wikiページ¶

• LLM連携による作業コンテキスト管理
• Redmine REST API運用
• RedmineとWiki.jsの役割分担

関連キーワード¶

Redmine REST API LLM KITT Issue Journal Issue Relations Tracker Custom Fields LLM Session Persistence Context Restore Wiki.js

次のアクション¶

• Redmine REST APIの疎通確認を行う
• redmine-kittでIssueのdry-runおよび新規登録を試験する
• 既存Issueの取得機能を確認する
• Journal追記機能を確認する
• Issue Relationsの登録・取得方法を確認する
• KITTとの会話を中断時にRedmineへ保存する実運用テストを行う
• 新規チャットからRedmine Issueを読み込ませ、作業再開テストを行う