直しても再発する表記の不統一と、安全装置が別の機能を壊した話｜稼働確認の1日目に見つかったこと

開発記録（第8回）。AI に日本株の売買判断をさせる投資システム investTool を個人で開発しています。全体像は目次記事にまとめています。

この記事の要点

仮想売買の仕組みを10営業日続けて動かす稼働確認の、1日目の通知から表記の問題が見つかりました
表記の指摘は5件続き、書式を決める場所を1か所にまとめてようやく収まりました
Bot の二重起動を防ぐ歯止めが、自動再起動を1回空振りさせる、という問題も起きました

やりたかったこと
つまずいた点と解決
実際にどう使っているか

やりたかったこと

前回のレビューの指摘をすべて直した後、仕組みが毎日自動で正しく回るかを確かめる稼働確認に入りました。10営業日、手を入れずに動かし続けることが合格の条件です。途中で仕組みに手を入れた場合は、1日目から数え直す決まりにしています。

つまずいた点と解決

1. 表記の指摘が5件続いた

症状: 通知や画面に、内部の値・英語のキー名・誤った単位の数字が出る。直すたびに別の箇所で似た問題が見つかる
原因: 値の書式を、通知・画面・コマンドの出力がそれぞれ別々に決めていた
対処: 書式を決める処理を1か所にまとめ、すべての表示がそこを通るようにした

稼働確認の1日目（9月18日）の夜、Discord に届いた注文の通知は、判定の内訳が次のようになっていました（値は伏せています）。

B1: {'label': '上昇トレンド（25日 > 75日 > 200日、75日線が上向き）', 'ok': True,
'value': …, 'threshold': …} ／ B2: {'label': '直近3日に25日線の 2% 上
まで下落', 'ok': True, 'value': …, 'threshold': …} ／ …

設計書で決めていた表示は「条件：25日線まで押し ✓ ／ RSI 反発 ✓ …」という形です。夜に通知だけを見て注文するかを決める使い方なので、これでは判断に使えません。

ここから、表記の指摘が次のように続きました。

もっとも悪かったのは3件目（R-26）です。2件目までの修正で、値の単位を「条件の名前に % が含まれるかどうか」で推測するようにしていました。ところが、「52週高値から 25% 以内」のように、名前に % を含みながら値は株価という条件がありました。その結果、株価が 100 倍の % として 285000.00% のように表示されました。

「読めない」より「誤った数字」のほうが悪い

生の辞書が出るのは読みにくいだけですが、誤った数字は判断を誤らせます。この件は優先度を「高」にしました。根本の原因は、条件が値の単位を持っていなかったことです。名前から推測する限り、取り違えはなくせません。条件に単位（株価・割合・倍率・数・真偽）を持たせ、表示はその単位だけを見て書式を決める形に直しました。

その後も、単位の指定の誤り（R-27）や、負号の文字が -（ハイフン）と −（マイナス記号）で混在している問題（R-28）が見つかりました。最後に、書式を決める処理をバックエンドと画面でそれぞれ1か所にまとめ、Discord・日次レポート・警告・コマンドの出力・画面のすべてがそこを通るようにして、ようやく収まりました。

横断的な決まりは、個別に直しても直らない

「負号は − を使う」「DD の段階は日本語で書く」のような決まりは、1か所ずつ直しても、直していない場所で必ず再発しました。決まりを文書に書くだけでなく、コードの中でも1か所に集めるまで収まりませんでした。

2. 二重起動を防ぐ歯止めが、自動再起動を空振りさせた

症状: Bot が異常終了した後の自動再起動が、1回目だけ必ず失敗する
原因: 「2分以内に生存の記録があれば、別の Bot が動作中とみなして起動しない」という歯止めに、再起動した自分自身が引っかかった
対処: 自動再起動を受け持つタスクだけは、確認を飛ばして起動する（--force）

Discord の Bot（通知のボタンに応答する常駐プログラム）を、疎通確認のコマンドで起動したとき、常駐中の Bot と二重に接続してしまうことがありました（R-22）。そこで、起動時に「生存の記録が2分以内に更新されていたら、別の Bot が動いているとみなして起動しない」という歯止めを入れました。

この歯止めが、別の問題を生みました（R-23）。

タスクスケジューラは、Bot が異常終了すると1分後に再起動します（最大3回）。その時点の生存の記録は60〜120秒前のもので、2分以内です。そのため、再起動した Bot が「別の Bot が動作中」と判定して、自分で起動をやめてしまいます。3回の再起動のうち1回が確実に無駄になり、復旧が約1分遅れます。

自動再起動のタスクは Bot のただ1つの担い手で、タスク自身の多重起動はタスクスケジューラの設定で防いでいます。そこで、このタスクだけは確認を飛ばして起動するようにしました。手で起動するときには、引き続き歯止めが効きます。

ポイント

安全装置を足すときは、その装置が「正しく動いている他の仕組み」を止めないかも確かめる必要がありました。第5回の新規停止と同じ種類の失敗です。