【高いAIを使えば、難しい問題も一発で解決して、かえって安く済む……はずだった話🤣😭】 ― 2026年08月13日 14時00分00秒
開発中のWSJT-X Improved JP1LRT Editionに、限定テスターのJK1BPAさんから、再現性のある不具合報告が届きました。
状況はこうです。
相手局からRレポートを受信
↓
こちらがRR73を送信
↓
相手に届かなかったため、相手が同じRレポートを再送
↓
ところがこちらは、RR73送信直後に交信相手の情報をクリアしてしまい、再送されたRレポートに反応できない
今回は再現確認のため、JK1BPAさんが送信出力を意図的に絞り、最初のRR73を相手へ届かせないという試験まで行い、ALL.TXTも提供してくれました。📡
ログを解析すると、これはAutoSeq2やAutoSeq3ではなく、CQを手動でダブルクリックして呼び出した普通のS&P運用で起きていました。
まずChatGPT側でソースコードを追跡し、原因と修正方針を整理。
次にClaude Sonnet 5へ、先入観を与えすぎない形で独立レビューを依頼しました。
Sonnetの一次解析は概ね妥当でしたが、一部に、
「この大きな処理ブロックも手動運用へ開放した方が安全かもしれない」
という提案がありました。
しかし、そのブロックは約638行。
中には単なるRR73再送処理だけでなく、
・AutoSeq2／3の候補局収集
・Wanted Hunting
・候補局の順位付け
・AS2 late-pick
・Auto Txの自動ON
・別局への自動呼出開始
まで含まれています。
もしここを安易に手動運用へ開放すると、RR73の再送を直した代わりに、操作者が意図していない別局を勝手に呼び始める可能性があります。これは危ない。😱
そこでRound 2。
ClaudeをSonnet 5から最上位のOpus 5へ変更し、エフォートもデフォルトの「高」ではなく「超高」に設定。
さらに、
「前回の自分の結論も、こちらの懸念も、どちらも信用せず、生のソースから実行順序と状態遷移を再導出せよ」
という、かなり厳しいプロンプトを渡しました。
要求したのは、
・最初のRレポート受信
・RR73送信開始
・Terminal Holdのarm
・ログ処理と画面クリア
・物理送信終了
・次の復号処理
・Rレポート再受信
・2回目、3回目のRR73
・相手から73／RR73／RRRを受信した場合
・送信上限とタイムアウト
・AutoSeq2／3やWanted Huntingへの副作用
・最小修正diff
・回帰試験表
まで全部です。
すると、さすがOpus 5・超高。
考える。
ひたすら考える。
そして猛烈に利用枠を食う🤣
現在セッションの消費量が、
52%
↓ 5分後
64%
↓
ついに100% 🔴
途中で、
「Claudeの応答を最後まで生成できませんでした」
げーーーーー🤣😭
再試行すると、
「Claudeの回答が中断されました」
またかよ🤣😭
さらにもう一度走らせると、また失敗表示。
「これはもう、超高＋大規模解析で処理限界に当たっている。分割するしかないか……」
と思ったその直後、なぜか突然、完成した長大なレビュー報告書と提案パッチを吐き出しました（笑）。
そして現在セッションは、きれいに100%使用済み。
まさに、燃料を全部使い切って滑走路へ着陸した大型機状態です✈️🤣
追加クレジットの表示も、最後の解析中に$6.42から$7.08へ増加。
「高いAIを使えば、一発で地雷まで見つけて結局安く済む」
という話を書くつもりだったのに、実際には途中で何度も生成に失敗し、セッション枠を完全に食い尽くすという、予想以上に面白い展開になりました。
しかし、出てきた結果はかなり重要でした。
Opus 5は、一次解析で自分が提案した「大きなAutoSeqブロックの開放」を明確に撤回。
ソースを再追跡した結果、
・RR73再送に巨大なAutoSeqブロックを開放する必要はない
・そこを開放するとWanted Huntingや自動選局が手動運用へ流入する
・RR73再送にはprocessMessage()の再実行すら不要
・交信相手、Tx4、Auto Txを保持すれば、既存の周期送信機構がRR73を再送する
・送信は3回のソフトリミットで止まる
・さらに10回上限、300秒上限、無応答タイムアウトも残る
・相手から73／RR73／RRRを受信した場合も既存の安全処理で終了できる
と結論しました。
つまり必要なのは、大きな自動選局機構を触ることではなく、
「Terminal HoldをAutoSeq2／3など特定モードだけの機能にせず、通常の手動S&Pでも利用できるようにする」
という、ずっと小さな修正でした。
さらに、設定値の異常によってCQ応答モードが空欄になり、その状態が設定ファイルへ再保存され続ける別の問題も発見。
こちらも、無効な値を安全な「CQ: None」へ戻す小さな修正案が出ました。
最終的な提案パッチは、
・変更1ファイル
・4関数
・5ハンク
・危険な638行のAutoSeqブロックは変更ゼロ
という、かなり絞り込まれた内容です。
もちろん、AIがそう言ったから採用するわけではありません。
Opusの報告とパッチをChatGPT側でも、正式なP2ソース、生のALL.TXT、実際の関数呼出順序と突き合わせて再確認しました。
結果、技術的な中核は整合。
パッチも正式ソースへcleanに適用可能。
現時点でブロッキング欠陥は見つかっていません。
ただし、作業はまだこれからです。
現在配布中のP2正式パッケージは変更せず、そのまま観察を継続。
今回の修正は別の隔離テスト版として実装し、
・手動S&P
・FT8／FT4
・RR73再送
・相手の73／RR73／RRR
・AutoSeq2／3
・Max Distance
・Wanted Hunting
・意図しない別局への自動送信が起きないこと
・異常設定値の自動修復
などを改めて実機試験します。
今回改めて感じたのは、AI開発で重要なのは「AIにコードを書かせること」ではなく、
・最初の答えを疑う
・別のAIに独立レビューさせる
・同じAIにも自説を撤回できる条件で再検証させる
・大きな修正より、証明できる最小修正を選ぶ
・最後は人間がログ、ソース、実機で確認する
という使い方なのだと思います。
高性能AIは確かに高い。
超高エフォートは燃料も猛烈に食う。
しかも、ときどき離陸中止や生成中断まで起こす🤣😭
それでも、一見もっともらしい危険な修正を事前に排除し、638行の変更候補を5ハンクまで縮められたなら、再ビルド、再配布、テスター全員の再試験、そして新しい不具合を生むコストを考えれば、結果として安かった可能性はあります。
ただし、まだ「可能性」です。
本当に一発で核心へ到達したのか。
本当に副作用なく直るのか。
答えは、これから作る隔離テスト版と実運用ログが教えてくれます。🔧📡
AIは優秀。
でも燃料計と最終進入は、人間が最後まで監視しないといけませんね🤣👍
でも燃料計と最終進入は、人間が最後まで監視しないといけませんね🤣👍
コメント
トラックバック
このエントリのトラックバックURL: http://jp1lrt.asablo.jp/blog/2026/08/13/9870732/tb
※なお、送られたトラックバックはブログの管理者が確認するまで公開されません。
コメントをどうぞ
※メールアドレスとURLの入力は必須ではありません。 入力されたメールアドレスは記事に反映されず、ブログの管理者のみが参照できます。
※なお、送られたコメントはブログの管理者が確認するまで公開されません。
※投稿には管理者が設定した質問に答える必要があります。