Git操作ミスで消えたLLM連携コードの復旧(開発日記 No.056)
関連リンク
はじめに
昨日は、note API経由での記事投稿を断念し、開発日記をMarkdownファイルとして生成・保存する方針に切り替えました。関連するコードの修正や不要ファイルの削除を行い、新しいフローの準備を進めました。
今日はこの新しい方針に基づき、システム全体の動作を確認し、完成に向けて必要な作業を進めていきます。まずはEnd-to-End (E2E) テストから始めることにしました。
背景と目的
新しい方針では、開発日記のMarkdownファイルをLLMでZenn記事形式に変換し、指定されたディレクトリに保存します。この一連の流れが正しく機能するかを確認し、もし問題があれば修正したり、不足している機能があれば特定したりする必要があります。
そのため、まずはシステム全体を通しで動かしてみるE2Eテストを実施し、現状を把握することを目的としました。
検討内容
E2Eテストの具体的な手順を考えました。
想定されるフローは、「元の開発日記ファイルを入力として、変換スクリプト (note_converter.py
) を実行し、note-articles/
ディレクトリに整形されたMarkdownファイルが出力される」というものです。
このフローを確認するため、以下のステップで進めることにしました。
- 変換スクリプト
note_converter.py
の場所を確認する。 - スクリプトの実行に必要な引数を確認する。
- 適切な引数を指定してスクリプトを実行する。
- 出力されたファイルの内容を確認する。
ファイル検索の結果、スクリプトは Docs/note-converter/scripts/note_converter.py
にあることがわかりました。次に、スクリプトのコードを読んで使い方を確認しました。必須引数は入力ファイルパス (input_file
) のみで、他の引数はオプションまたはデフォルト値があることがわかりました。
実装内容
検討した内容に基づき、E2Eテストを実行しました。テスト対象として、昨日の開発日記ファイル (Docs/dev-records/2025-04-24_055_development.md
) を使用しました。
実行したコマンドは以下の通りです。
python Docs/note-converter/scripts/note_converter.py Docs/dev-records/2025-04-24_055_development.md
実行結果は以下のようになりました。
INFO:root:入力ファイル: Docs/dev-records/2025-04-24_055_development.md
INFO:root:出力ディレクトリ: note-articles/
INFO:root:フォーマット指示ファイル: Docs/note-converter/formats/zenn-format.md
INFO:root:LLMによる処理を開始します。
INFO:root:LLM処理が完了しました。
INFO:root:出力ファイル名: 20250425_2025-04-24_055_development.md
INFO:root:ファイルを note-articles/20250425_2025-04-24_055_development.md に保存しました。
コマンドは正常に完了し、ログによると note-articles/
ディレクトリに 20250425_2025-04-24_055_development.md
というファイルが生成されたようです。ファイル名には実行日と元のファイル名が含まれており、これはスクリプト内の命名規則通りでした。
次に、生成されたファイルの内容を確認しました。
LLMで処理されたコンテンツ:
---
title: (ここにタイトルが入る)
emoji: "📝"
type: "idea"
topics: ["topic1", "topic2"]
published: false
---
# (ここに本文が入る)
ファイルを開いてみると、先頭に LLMで処理されたコンテンツ:
と表示され、その後に固定のテンプレートのような内容が出力されていました。これは、スクリプト内のLLM連携部分 (process_with_llm
関数) が、実際のAPI呼び出しではなく、固定の文字列を返すだけのモック実装になっているためでした。
「あれ?OpenRouterを使ったLLM連携は実装したはずなのに…」と疑問に思い、再度コードを確認しましたが、やはりモック実装のままでした。コメントにも「現在はモック実装」と書かれています。
ここでハッとしました。もしかして、昨日のファイル整理の際に、誤って実装済みのファイルを削除してしまったのではないか…?
思い返してみると、昨日のコミットでいくつかファイルを削除しました。その中に、更新した note_converter.py
が含まれていた可能性があります。
原因がGitの操作ミスにある可能性が高いと判断し、ファイルを復元することにしました。最新のコミットの1つ前のコミット (HEAD~1
) で誤って削除したと考えられたため、そのさらに1つ前の状態 (HEAD~2
) からファイルを取り出すことにしました。
まず、Gitの履歴を確認しようと git log
コマンドを実行しましたが…
fatal: not a git repository (or any of the parent directories): .git
エラーが発生。どうやら、現在いるディレクトリ (/home/centervil/repos
) がGitリポジトリのルートディレクトリではなかったようです。基本的なところで躓いてしまいました…。
技術的なポイント
今回の作業を通じて、以下の技術的なポイントが重要だと再認識しました。
- E2Eテストの重要性: 個々の機能だけでなく、システム全体を通して動作を確認することで、予期せぬ問題(今回のような連携部分の欠落など)を発見できます。
-
Gitによるバージョン管理: 誤ってファイルを削除したり変更したりした場合でも、Gitの履歴を辿ることで復元できる可能性があります。
git log
で履歴を確認し、git checkout <commit>^ -- <file>
のようなコマンドで特定のコミットからファイルを取り出すことができます。(今回はまだ実行できていませんが…) - コマンド実行環境の確認: 特にGitコマンドなどは、リポジトリのルートディレクトリで実行する必要がある場合があります。エラーが出た際は、まずカレントディレクトリを確認することが大切です。
所感
今日は新方針でのシステム完成に向けて、意気揚々とE2Eテストを開始しました。しかし、まさか実装したはずのLLM連携機能がごっそり消えているとは思わず、かなり焦りました。コードを見てもモック実装のままで、「どこに行ったんだ!?」と最初は混乱しました。
原因が自分のGit操作ミス(ファイル削除)の可能性が高いと気づいたときは、正直なところ脱力しました…。コミット前に変更内容をしっかり確認する、という基本的なことの大切さを改めて痛感しました。git add .
や git commit -a
を使うときは特に注意が必要ですね。
ファイルを復元しようとしたら、今度はカレントディレクトリの問題で git log
が実行できないという、これまた基本的なミス。落ち着いて状況を確認すればすぐにわかることなのに、焦りもあってか見落としてしまいました。少し情けなく感じます。
順調に開発が進むかと思いきや、思わぬトラブルに見舞われ、足止めを食ってしまった一日でした。まあ、こういう日もありますよね。失敗から学んで次に活かしたいと思います。
今後の課題
今日の作業は途中で中断となってしまったため、以下の課題が残っています。
- Gitリポジトリのルートディレクトリ特定と移動: まずは正しいディレクトリに移動します。
-
Git履歴の確認:
git log
やgit reflog
を使って、どのコミットでnote_converter.py
が変更・削除されたのかを正確に特定します。 -
ファイルの復元: 特定したコミットから、OpenRouter連携が実装されたバージョンの
note_converter.py
をgit checkout
コマンドなどで復元します。 - 再度のE2Eテスト: ファイル復元後、改めてE2Eテストを実行し、今度こそLLM連携が正しく動作するかを確認します。
- CI/CDパイプライン整備: E2Eテストでシステムの基本的な動作が確認できたら、CI/CDパイプラインの整備に着手します。
まとめ
今回は、新しい方針に基づいたシステムの完成を目指し、まずE2Eテストを実施しました。しかし、テストの結果、実装済みのはずのLLM連携部分が動作しておらず、その原因が昨日のGit操作ミスによるファイル削除の可能性が高いことが判明しました。
ファイルの復元を試みましたが、Gitコマンド実行時のディレクトリの問題でエラーが発生し、作業は中断となりました。基本的なGit操作の重要性と、変更内容の確認不足が招いたトラブルを痛感した一日でした。
次回は、まずGitリポジトリの正しい場所でファイル復元作業を再開し、システムの動作確認を進めていきたいと思います。
Discussion