Codexを使ったからこそ見えてきた、設計の問題と改善
前回のストーリーでは、Codexを活用してMinecraftサーバーの構築や、バックアップ・アップデートBotの作成を行いました。
今回は、その続きとして、Minecraftサーバーのログ監視Botを作成した際に気付いた、「AIにコードを書いてもらうだけでは見えてこない設計の問題」について紹介します。
目的は「Discordをログ置き場にすること」
今回作りたかったのは、Minecraftサーバーの入室・退出をDiscordへ通知するBotです。
目的はとてもシンプルでした。
サーバー上へログファイルを蓄積しないことです。
一般的にはログファイルを保存して管理しますが、ログは少しずつ増え続けます。
今回は、自宅で運用しているMinecraftサーバーということもあり、不要なログファイルをできるだけ増やしたくありませんでした。
そこで、
「Discordのチャンネル履歴そのものをログとして利用しよう」
という方針で開発を始めました。
Discordへ通知できれば、サーバー側にログを保存する必要はありません。
Codexに任せてみたら、思わぬ設計になった
今回も前回と同じように、Codexへかなり任せる形で実装を進めました。
完成したBotは問題なく動きます。
しかし、コードを読んでいると少し違和感がありました。
ログを取得すると、
- 一度
tempfileへ保存する - その内容をDiscordへ送信する
という流れになっていたのです。
さらに問題だったのは、そのtempfileが削除されずに残り続ける設計になっていたことでした。
今回の目的は、「ログファイルをサーバーへ蓄積しないこと」です。
それにもかかわらず、一時ファイルとはいえ、実際にはサーバー上へログファイルが増え続ける構成になっていました。
そこでまずはCodexへ改善を依頼し、処理が終わるたびにtempfileを削除するよう修正しました。
これで不要なファイルは残らなくなりました。
しかし、それでも違和感は消えませんでした。
「そもそも、なぜ一度テキストファイルへ書き出す必要があるんだろう？」
ここで初めて、コードではなく、ログの取得方法そのものを調べ始めました。
問題はBotではなく、screenだった
調べてみると、原因はBotではありませんでした。
Minecraftサーバーを管理していたscreenでした。
私はMinecraftサーバーをscreen上で起動・管理していました。
しかし、screenでは、表示されている内容をそのまま取得することができません。
ログを取得するには、一度hardcopyでファイルへ書き出し、その内容を読み込む必要があります。
つまり、
screen
↓
hardcopy
↓
tempfile
↓
Discordscreen
↓
hardcopy
↓
tempfile
↓
Discord
という流れになるのは、screenを使っている以上、ある意味当然だったのです。
ここでようやく気付きました。
問題はBotではなく、最初に選んだ仕組みそのものだったのです。
根本から見直して、tmuxへ変更
さらに調べてみると、tmuxにはペインの内容を直接取得できる機能がありました。
つまり、一時ファイルを経由する必要がありません。
そこで、Minecraftサーバーの管理方法そのものをscreenからtmuxへ変更しました。
すると、Botの処理はとてもシンプルになりました。
SSH接続
↓
tmuxの内容を取得
↓
ログを解析
↓
Discordへ通知SSH接続
↓
tmuxの内容を取得
↓
ログを解析
↓
Discordへ通知
これで、
hardcopytempfile- 一時ファイルの削除処理
といった処理がすべて不要になりました。
「最初からtmuxで管理していれば、この問題は起きなかった。」
そんなことにも気付きました。
AIに任せるだけでは見えてこなかった
今回、一番印象に残ったのはここでした。
Codexは、ちゃんと動くコードを作ってくれます。
実際、最初に作成されたBotも正常に動作していました。
だからこそ、最初は「これで完成だ」と思っていました。
しかし、目的まで含めて考えてみると違いました。
最初は、
- tempfileを削除する
という改善を行いました。
ですが、それは根本的な解決ではありませんでした。
「なぜtempfileが必要なのか」
そこまで考えたことで、本当の原因がscreenにあることへ気付けました。
もし生成されたコードだけを見ていたら、おそらく気付かなかったと思います。
Codexを使ったからこそ学べたこと
今回の経験を通して感じたのは、
AIはコードを書いてくれる。
でも、
設計を考えるのは、自分の役割だ。
ということです。
最初はCodexへかなり任せていました。
しかし、出来上がったコードを読み返し、
「この処理は本当に必要なのか」
「もっとシンプルな方法はないのか」
と考え直したことで、最終的にはBotだけでなく、Minecraftサーバーの管理方法そのものまで見直すことになりました。
結果として、コード量も減り、目的にも合った構成になりました。
まとめ
今回のログ監視Bot開発では、最初から理想的な設計ができていたわけではありません。
むしろ、Codexに実装を任せて動かしてみたからこそ、
「この処理、本当に必要だろうか」
という疑問を持つことができました。
その疑問をきっかけに調べていくと、問題はBotではなく、screenという管理方法そのものにあることが分かりました。
最終的には、Minecraftサーバーをtmuxで管理する構成へ変更し、一時ファイルを経由しない、よりシンプルな仕組みに改善できました。
今回の開発を通して学んだのは、
AIが作ったコードをそのまま採用するのではなく、「なぜその設計なのか」を理解することの大切さです。
Codexは非常に強力な開発支援ツールでした。
しかし、本当に良いシステムを作るためには、AIが提案した実装を一度立ち止まって見直し、目的に合った設計になっているかを自分で考えることが重要だと感じました。
