前回の記事に引き続き、今回も仮想通貨botの開発状況をまとめていきます。
本日取り組んだ「bybitテストネットで動かす際のデータ通信周りのトラブル」と、その失敗→原因分析→修正フロー→最終対応を整理します。最後に、Testnet の設計構造について考察します。
1. 発生した問題と経緯
| 番号 | 現象 | エラー内容／挙動 |
|---|---|---|
| ① | 約定状況取得で KeyError: 'data' | d["result"]["data"][0] へアクセス中に data キーが存在せず落ちる |
| ② | /v5/order/realtime 呼び出し時に “Illegal category” 警告連発 | retCode=10001, retMsg="Illegal category" |
| ③ | ①②への対処を入れた後も、テスト板は約定せずキャンセルを繰り返す | レスポンスはエラーのみ、埋まらない |
🧯 1. 発生した問題と経緯（初心者向け解説付き）
Botをテストネットで動かしてみたところ、いくつかのエラーや想定外の挙動に遭遇しました。ここでは、それぞれの現象とその意味を解説していきます。
| 番号 | 現象 | エラー内容／挙動 | 初心者向けの解説 |
|---|---|---|---|
| ① | 約定状況取得で KeyError: 'data' | d["result"]["data"][0] にアクセスしようとしたときに、data という情報が存在しないためにプログラムが落ちた | 🔰**「欲しい情報が届いてないのに、あると思って触ってしまった」**という状態。 たとえば「郵便物に住所がないのに中身を見ようとした」ようなものです。APIからの応答をちゃんと確認してから処理する必要があります。 |
| ② | /v5/order/realtime 呼び出し時に "Illegal category" 警告が連発 | APIの呼び出し時に category という項目が不正、あるいは未サポートであるというエラーが返ってきた | 🔰**「APIに聞き方が間違ってる」**という状態。 本番用のAPIとテスト用のAPIでは仕様が違うことがあり、今回は「categoryパラメータ」がTestnetでは通用しなかったのが原因です。 |
| ③ | ①②を修正した後も、約定が発生せず注文がキャンセルされ続ける | Botは動くが、板に注文が通らず毎回キャンセル処理になる | 🔰**「注文は出してるけど誰も買ってくれない」**という状況です。 テストネットは板が非常に薄く（取引量が少ない）、注文しても相手がいないため約定しづらい。これにより、注文が約定せず毎回タイムアウトしてキャンセルされるという流れになっています。 |
📝 補足
この3つの問題は、「実際にBotを動かしてみて初めてわかる落とし穴」です。
特に初心者がつまずきやすいのは、
- APIのエラーレスポンスを甘く見ている（KeyError）
- 本番とTestnetの仕様の違いに気づかない（Illegal category）
- テスト板での約定検証を甘く見ている（板が薄すぎる）
といった点。今回の経験を通じて、「動作確認だけで満足せず、Botがどんな状況でもちゃんと動き続けられるか？」という視点の大切さを再認識しました。
2. 原因分析
① KeyError: 'data'
- 原因：API 呼び出しがエラー時（retCode≠0）の JSON を返すと、
resultの中にdataキー自体が存在しない - 分析：
await res.json()後に即座に["data"][0]を参照してしまい、エラー応答ケースを考慮していなかった
② Illegal category
- 原因：Testnet の
/v5/order/realtime（リアルタイム注文照会）エンドポイントはcategory（例:"linear"）を URL パラメータに要求していない・実装されていない - 分析：本番同様の呼び出しをテスト環境にそのまま流すと「どのマーケットカテゴリか指定が不明／未サポートだ」とはじかれる
🔍 2. 原因分析（初心者向け解説つき）
ここでは、前項で紹介したエラーの**原因がなぜ起きたのか？**を技術的な視点でひもときながら、初心者の方向けにわかりやすく解説していきます。
① KeyError: 'data' の原因
- 原文：
API呼び出しがエラー時（retCode≠0）のJSONを返すと、resultの中にdataキー自体が存在しない。 - 分析：
await res.json()のあとにすぐ["data"][0]を参照してしまい、エラー応答だった場合に存在しないキーにアクセスして落ちていた。 - 初心者向け解説：
📦 APIから返ってくる情報は「うまくいったとき」と「エラーのとき」で中身の形が違うことがあります。
たとえば、「OK！」って返してくるときにはdataという箱があるのに、エラーのときにはその箱がごっそり抜けていて空っぽ。
なのに、プログラムが「いつもあるはず！」と思って中を開けにいったせいで、「そんな箱ないよ！」＝KeyError になってしまいました。
🛠 対策としては、「箱があるかちゃんと確認してから開ける」という一手間を加えることが大切です。
② Illegal category エラーの原因
- 原文：
Testnetの/v5/order/realtime（リアルタイム注文照会）エンドポイントはcategory（例:"linear"）をURLパラメータに要求していない・実装されていない。 - 分析：
本番と同じ呼び出しをテスト環境に流した結果、**Testnetではそのパラメータが通用せずエラー（retCode=10001）**になっていた。 - 初心者向け解説：
🌐 本番環境とテスト環境では、APIの使い方（ルール）が微妙に違うことがあります。
たとえば「本番では“どの市場カテゴリなの？”と聞かれるけど、テスト環境ではそれを聞かれない（あるいは聞かれても答えられない）」みたいなことです。
今回は、本番用の設定そのままでテストネットにアクセスしたため、「そんなカテゴリ指定いらんし、むしろ困るよ」という感じで拒否されてしまったのが Illegal category というエラーの正体です。
📚 教訓としては、TestnetにはTestnet専用のAPI仕様がある可能性を念頭に、呼び出し方を柔軟に変えられるようにしておくと安心です。
✅ 総まとめ
| エラー名 | 原因の本質 | 初心者向けまとめ |
|---|---|---|
KeyError: 'data' | エラー時にdataが無い | 「箱（dataキー）が無いのに開けようとした」 |
Illegal category | テストネットがそのカテゴリ未対応 | 「聞かれてもいない質問を勝手に送った」 |
3. 修正フロー
- エラーのロギング追加
wait_for_fill()内で例外キャッチし、logger.warningでエラー内容を出力
- data キーの有無チェック
d.get("result", {}).get("data")が真であれば中身を処理、なければ次ループへ
- Illegal category のスキップ
- retCode≠0 の場合はポーリングを継続し、30秒後に自動キャンセルへ
- キャンセル後の処理整備
- タイムアウト時に
cancel_order()を呼び、キャンセル成功 or 失敗のログを確認
- タイムアウト時に
- 最終手段：Market 注文 or 攻撃的な Limit 価格設定
- テスト板の板厚が極薄なため、確実に埋まるよう「Market 注文」への切り替え検討
- もしくは
limit_price = current_ask／limit_price = current_bidにして即約定を狙う
🔧 3. 修正フロー（初心者向け解説つき）
ここでは、前のセクションで明らかになった問題に対して、**どのように修正を加えたのか？**を一つずつ丁寧に見ていきます。
✅ エラーのロギング追加
- やったこと：
wait_for_fill()関数内でエラーが起きたときに例外（エラー）をキャッチして、logger.warningを使って詳細を記録。 - 初心者向け解説：
💡プログラムで何かトラブルが起きたとき、「何が起きたのか」「いつ起きたのか」が記録されていないと、原因を特定するのが難しくなります。
そこで、「エラーが出たらちゃんと記録する」という**ログを残す仕組み（ロギング）**を強化しました。
logger.warning は、「注意が必要なエラーだったよ」というレベルで出力されるので、あとで見返すときに便利です。
✅ dataキーの有無チェック
- やったこと：
d.get("result", {}).get("data")という書き方で、dataが存在するかどうかを確認してから中身にアクセス。 - 初心者向け解説：
🥣さっきの「箱（data）が無いのに開けようとして怒られる問題」への対処です。
dict.get() というメソッドを使うと、「この中にdataっていう名前のものがあるかな？」とそっと確かめてから処理することができます。
つまり「壊れた箱があるかもしれないから、そっと開けるようにした」という安全対策です。
✅ Illegal category のスキップ処理
- やったこと：
API の返答にretCode ≠ 0（つまりエラー）が返ってきたら、処理を続けるだけにして、無理に中を見に行かないように変更。30秒でタイムアウト → キャンセル。 - 初心者向け解説：
🙅エラーが出てるのに無理やり次の処理をしようとすると、また落ちますよね。
なので今回は、「APIがエラー返してきたら、何もせずにそのまま待つ」ようにしました。そして30秒待っても約定しなかったら注文をキャンセルする、という流れにしています。
Botに「もうちょっと様子見てダメなら諦めて」という判断力を持たせた感じです。
✅ キャンセル後の処理整備
- やったこと：
cancel_order()を呼び出したあとの成否をログに記録。キャンセルが成功したかどうか確認できるように。 - 初心者向け解説：
📄注文を取り消す「キャンセル」処理も、成功したかどうか分からないと不安ですよね。
だから、今回は**「ちゃんとキャンセルできたか？」もログに残す**ようにしました。これで「本当にBotが安全に止められたか？」を後から確実に確認できます。
✅ 最終手段：Market注文 or 攻撃的なLimit価格
- やったこと：
テストネットの板が薄すぎて注文が通らない問題に対して、「すぐに約定する」ように注文価格を攻めた設定にするか、またはマーケット注文に切り替える提案。 - 初心者向け解説：
🏛 テストネットは本番と違って人があまりいない市場なので、出した注文がなかなか「約定（＝成立）」しません。
そんなときに有効なのが以下の2つ：
- 攻めた価格設定：
買い注文なら「今の売値（ask）」と同じ価格、売り注文なら「今の買値（bid）」と同じ価格で出せば、目の前にいる誰かと即マッチングして成立しやすくなります。
- マーケット注文：
価格を指定しないで「今すぐ一番近くの相手と取引してください！」という注文方法。テスト用としては最も確実に成立する手段です。
🧠 おさらい：修正フローの本質
| 修正項目 | 目的 | 一言で言うと… |
|---|---|---|
| ログ追加 | エラーの記録を残す | 「何が起きたか」をちゃんとメモ |
| data存在チェック | 存在しないキーへのアクセス防止 | 「箱があるか確認してから開ける」 |
| Illegal category スキップ | 不要なエラーで止まらないようにする | 「無理しないで回避」 |
| キャンセルログ記録 | キャンセル結果を確認できるようにする | 「止めた結果も見える化」 |
| マーケット注文 or 攻め価格 | 約定しない問題の解決 | 「強気で攻めるか、安全に即決」 |
何かひとつでも「へぇ〜そういうことか」と思ってもらえたら嬉しいです！
4. 最終的に取った手段
- エラー耐性強化：
wait_for_fill()で data キーの存在をチェックし、API エラーの場合は warning 出力 → ポーリング継続 → タイムアウト後キャンセル - テスト板埋め検証：
- 数値をより小さいロット(0.0001)まで下げ
- 攻撃的に
bid→sell,ask→buy価格を設定 - 必要に応じて Market 注文を利用
- こうして「Filled を返す」ケースを作り出し、trade→record→pnl→Slack 通知までの一連フローを動作確認
✅ 4. 最終的に取った手段（初心者向けの解説付き）
ここからは、前回のトラブルやエラーに対応したあと、最終的にどんな手を打って、Botが正常に動作するように仕上げたかをまとめたパートです。
🛡️ エラー耐性の強化
- やったこと：
wait_for_fill()関数の中で、APIの応答にdataキーがあるかどうかをチェック。 なかったら警告（logger.warning）を出して、次のループで再度確認。 それでも約定しない場合は、30秒後に注文をキャンセル。 - 初心者向け解説： 👀 これは「Botが壊れずに最後までちゃんと動き続けられるようにする工夫」です。 エラーが出たらすぐ止まってしまうのではなく、一旦警告を出して様子を見つつ、時間切れになったら自動で注文をキャンセルする仕組みを整えました。 これにより、「Botが無限に固まる」とか「いきなりクラッシュする」といった問題を回避できるようになっています。
🧪 テストネットの板埋め検証
テストネットは本番に比べて人が少なく、流動性が低いので、注文がなかなか「約定」しません。
それに対して以下の工夫をしました。
① 数値をより小さいロット（0.0001）まで下げた
① 数値をより小さいロット（0.0001）まで下げた
- なぜ？
取引量が大きすぎると、板が薄いテストネットでは「相手がいなくて注文が通らない」ことがあるから。 - どうする？
最小単位まで注文量（lot）を下げて、埋まりやすく＝成立しやすくする工夫をしました。
② 攻撃的な価格設定（bidでsell、askでbuy）
- なぜ？
通常は「bid - 1」や「ask + 1」のように価格を調整して出すけど、これだとテストネットでは永遠に埋まらないことが多い。 - どうする？
今ある板（bid/ask）にピッタリかぶせるようにして出すことで、即座に約定しやすくする。
たとえば： pythonコピーする編集するbuy_price = int(orderbook["ask"]) # 買いは ask で出す sell_price = int(orderbook["bid"]) # 売りは bid で出す
③ 必要に応じてマーケット注文に切り替え
- なぜ？
もう絶対に約定させたい！という時は、価格を指定しない「マーケット注文（Market）」が一番確実。 - どうする？
テスト用だけでもMarketを使えば、「今すぐに一番近くの注文とマッチ」して即成立します。
🔄 結果：一連のフローを動作確認！
以上の工夫によって、ついに「Filled（注文が通る）」を返すケースを作り出すことに成功！
その結果：
- 注文（trade）
- 約定記録（record）
- 損益計算（pnl）
- Slack通知（report）
という一連の処理がすべて通って、Botの基本的な動きがテストネット上でもしっかり確認できました！
✅ まとめ（初心者向け）
| 対応項目 | 内容 | なぜ重要？ |
|---|---|---|
| エラー耐性 | data チェックと警告出力 | 落ちないBotを作るため |
| ロット調整 | 0.0001 まで下げた | 薄い板でも埋まりやすくする |
| 攻め価格設定 | bidやaskそのままで発注 | 約定率を高めるため |
| Market注文導入 | 即時約定できる手段を確保 | テスト検証の確実性アップ |
このように「テストでうまく動かないな…」という時でも、Bot側の発注条件やAPI処理を細かく調整することで、ちゃんと動作確認まで持っていくことができるんです。
Bot開発は、地味なエラー対応と観察力の積み重ね。
でもそこに一つずつ理解と対策を積んでいくと、確実に“堅牢なBot”へと育っていきます。
5. Testnet 設計構造の考察
- リアルタイム REST API の未整備
/v5/order/realtimeが Testnet では本番と乖離し、Illegal categoryエラーを返す例から、機能未完の可能性大
- ドキュメントと実装のズレ
- 公開ドキュメントには対応が記載されるが、Testnet 側で未実装・仕様変更されたまま放置されている
- 板情報の薄さ
- Testnet 板は流動性シミュレートが粗いため、実運用想定のテストとしてはLIMIT注文では不十分
- API エラー時の一貫性欠如
- エラー時 JSON のフォーマットが揃っておらず、
data欄の有無もランダム。堅牢に扱うには細やかなチェックが必須
- エラー時 JSON のフォーマットが揃っておらず、
✏️ 今後の対応提案
- REST ポーリングへのフォールバック：リアルタイム API が不安定な場合、
/v5/order/listや/v5/order/historyを使った周期的チェックを検討 - Market 注文オプションの実装：パラメータ切り替えで Market/Limit 両対応にすると、Testnet／本番での検証がスムーズ
- 共通エラーハンドリングモジュールの整備：retCode チェック → 必要パラメータの有無検証 → キーエラーケア をまとめて管理
- Testnet 独自のドキュメント化：Testnet 独自の挙動やエラー条件をチーム内 Wiki 等に蓄積し、次回以降の試行錯誤を減らす
✅ 5. Testnet 設計構造の考察（初心者向け解説）
ここでは、BybitのTestnet環境（テスト用ネット）を実際に使ってみて気づいた「本番環境との違い」や「未整備な点」、そしてそれにどう対応すれば良さそうか？という改善アイデアをまとめています。
🔎 リアルタイム REST API の未整備
- 何が起きている？
/v5/order/realtimeというAPIを使って、リアルタイムで注文の状態（約定したかどうか）をチェックしようとすると、Testnet環境では “Illegal category” というエラーが出てしまう。 - なぜそれが問題？
本番環境ではちゃんと動くAPIが、Testnetではまだ完成していない可能性がある。つまり、テストしようとしても機能自体が動いていない可能性があるということです。 - 初心者向け補足：
APIとは「Botと取引所のやり取りルール」のようなもの。このエラーは「ルール自体がTestnetでうまく通用していないよ」というサイン。
📄 ドキュメントと実装のズレ
- どんな問題？
公開されているBybitのAPIドキュメントでは「このエンドポイントは使えますよ」と書いてあるのに、Testnet側では未対応だったり、仕様が途中で変わっていたりすることがあります。 - どう困る？
書かれている通りにBotを組んでも、「実際には使えない」「挙動が違う」という落とし穴にハマるリスクがある。 - 初心者向け補足：
マニュアルと実物がズレていると思えばOK。ドキュメントを読んだだけでは安心できず、「実際に動かして確かめる」が重要ということです。
📉 板情報の薄さ
- 意味すること：
Testnetの注文板（オーダーブック）は、本番よりずっと取引量が少なくて、流動性がありません。 - 何が起きる？
LIMIT注文（「この価格で買いたい」と指定する注文）を出しても、相手がいないため約定（取引成立）しないことが多いです。 - 初心者向け補足：
たとえると、人気のないフリーマーケットで「この値段じゃないと売らない」と言ってるようなもの。誰も買ってくれない＝取引が成立しない。
⚠️ APIエラー時の一貫性欠如
- どんな不具合？
APIからエラーが返ってきたとき、そのフォーマット（書式）がバラバラ。
たとえばdataキーがあったりなかったりする。 - なぜ困る？
Botは返ってきたデータの形をもとに判断しているので、「あるはずのものがない」＝プログラムが落ちる原因になります。 - 初心者向け補足：
エラーの“言い方”が毎回違うと、Botも「え？どういうこと？」って混乱しやすい。なので、Botのほうで「どの形でも対応できるようにしておく」工夫が必要になります。
✏️ 今後の対応提案（こうすれば良さそう！）
🌀 RESTポーリングへのフォールバック
- 何？
「リアルタイムに注文をチェックするのが不安定なら、少し間隔をあけて繰り返しチェックする方法（＝ポーリング）に切り替えよう」という案です。 - どのAPIを使う？
/v5/order/listや/v5/order/historyなど、安定して使えるAPIに切り替えるのがよさそう。
⚡ Market注文オプションの実装
- どんな工夫？
Market注文（価格を指定しない注文）を切り替え可能にしておくことで、「必ず約定させたいとき」に対応しやすくする。 - どうする？
--order-type marketのようなパラメータで選べるようにすれば、Testnetでも本番でもスムーズに動作確認できる。
🧱 共通エラーハンドリングモジュールの整備
- 目的：
APIから返ってきたエラーを「一括で安全に処理できる共通の関数」にまとめておくこと。 - やること：
retCodeのチェックdataキーがあるか確認- 必要なパラメータがあるか検証
- エラー時はロギングして処理をスキップ or リトライ
- メリット：
どんなエラーが来ても慌てず対応できる、Botが止まらない＝安定稼働のカギ。
🗂 Testnet独自のドキュメント化
- なぜ必要？
Testnet特有のエラーや仕様違いは、開発者が「個別に気づいては忘れる」パターンが多い。なので、**自分たち用のメモを作っておこう！**という発想。 - どこにまとめる？
チームのWikiやNotion、GitHubのREADME、Slackチャンネルのピン止めなど。 - メリット：
**「あれ？これ前もあったな」→「すぐ確認して再発防止」**ができるようになります。
✅ 総まとめ（初心者向け）
| 問題 | 意味すること | 対策の方向 |
|---|---|---|
| realtime APIが動かない | Testnetは未実装の可能性あり | RESTで代替ポーリング |
| ドキュメントがズレてる | 書いてあるけど動かない | 実際に動かして検証 |
| 板が薄い | LIMIT注文が通らない | Market注文や価格の攻め |
| エラーの形が毎回違う | Botが混乱して落ちる | エラー処理の共通化 |
このセクションでは、テスト環境での落とし穴にどう気づき、どうやって地道に修正していくか、がよくわかると思います。
仮想通貨Bot開発は、ただコードを書く以上に、「観察して、ズレを発見して、修正する」という地味で強い力が問われます。
この積み重ねこそが、本番で壊れない強いBotを作る土台になるんですよね。
次のステップに進む前に、Testnetの特性をしっかり押さえておくことは、とても大事な基礎固めになります。自分のメモとしても、ぜひ活用してみてください！
以上、本日の「データ通信まわりのつまずきと学び」を整理しました。Testnet 特有の仕様未整備を理解しつつ、本番との差分を吸収していきます！
👇ラジオで話したこと
🎙️ 開発記録#189「MM bot開発ログ6：テストネット通信トラブルと設計の壁」
こんにちは、よだかです。
今回も仮想通貨Botの開発ログをお届けします。
この収録では、Bybitのテストネット上で起きた一連の通信トラブルとその修正対応について、なるべく初心者にもわかるように、かみ砕いてお話ししていきます。
実際に私がつまずいたところ、調べたこと、修正して学んだこと──それをすべて言葉にして記録しておくことで、「未来の自分」が同じ失敗をしないように。そして、同じようにBotを作っている誰かの役に立てばと思っています。
🧯 第一章：何が起きたのか？──現象の整理
今回テストネットで動かした際、主に3つのトラブルにぶつかりました。
1つ目は KeyError: 'data'。
これは「APIの応答にあるはずの data という情報が存在しないままアクセスしようとして、エラーで落ちた」ものです。
2つ目は /v5/order/realtime を叩いたときに "Illegal category" というエラーが連発したこと。
つまり「そのAPIに指定してる 'category' が、そもそもTestnetじゃ未対応なんじゃない？」という事態でした。
3つ目は、上の問題を回避しても注文がまったく約定せず、キャンセルばかり繰り返すという症状。
つまり、「注文は出せてる。でも通らない」という詰まり感でした。
🔍 第二章：なぜ起きたのか？──原因分析と気づき
まず1つ目の KeyError: 'data'。
これはAPIの返答に data というキーがある前提でコードを書いていたことが問題。
でも、実際にはエラー時のレスポンスには data 自体が含まれていないケースがある。
その想定抜けが原因でした。
次の "Illegal category" については、これはBybit Testnetの仕様問題。
本番では category パラメータが必要なのに、Testnetでは未対応だったようです。
「ドキュメントに書いてあるから正しい」と信じすぎると、こういうズレにやられるといういい教訓になりました。
最後の「埋まらない注文」──これはテストネットの流動性の問題。
取引量が少ない板なので、注文があってもマッチする相手がいない＝約定しない、ということです。
🛠️ 第三章：修正フローの組み立て
ここからが本番。
それぞれの問題に対してどう手を打ったのか。
✅ まず、KeyError対策として data の存在をチェックするようにしました。d.get("result", {}).get("data") と書けば、安全に中身を探せます。
✅ 次に、Illegal categoryエラーへの対処。
これはエラーコード retCode ≠ 0 が返ってきたらそのままスキップし、次のループへ──という実装にしました。
✅ そして、注文が約定しない問題への対策。
これは最終的に以下のような工夫を入れました：
- ロットを極小（0.0001）にする
- 価格設定を「bidそのまま」「askそのまま」にして即約定狙い
- 必要に応じてマーケット注文も選べるようにオプションを追加
🔄 第四章：やってみた結果と得られた手応え
上記の修正を入れてBotを動かしたところ…
見事に「Filled（約定）」を拾うことができました。
Slack通知も流れ、PnL（損益）も計算され、SQLiteに記録もされました。
これでテストネット上での基本フローはすべて一通り確認できた、という手応えがありました。
しかも、重要なポイントは「クラッシュせずにBotが動き続けた」こと。
エラー処理の精度が上がったということですね。
🧠 第五章：Testnetという環境の設計的な問題
ここからは少し俯瞰して考えたこと。
BybitのTestnet環境って、正直「未整備な点が多い」です。
- 本番用のAPIがTestnetでは未対応
- ドキュメントと挙動がズレてる
- 板が薄すぎてLIMIT注文が通らない
- エラー時のJSONの形式が揃っていない
こういうの、初心者にはかなり厳しい。
✏️ 第六章：今後の改善方針
じゃあ、どうすれば良いか？
✅ REST APIによるポーリングに切り替え
リアルタイムAPIが不安定なら、注文一覧などを定期的に確認する方式へ。
✅ Market注文とのハイブリッド化
注文種別を切り替え可能にしておけば、検証の幅が広がる。
✅ 共通エラーハンドリングの実装
retCode や data の存在を毎回チェックする仕組みを一元化して、Botが落ちないようにする。
✅ Testnetの挙動メモを残す
「このAPIは使えなかった」など、実験ログをまとめて、次に活かせるようにする。
🔚 終わりに：この失敗は大きな“資産”
Bot開発って、こういう「わからないこととの出会い」と「小さなトライ＆エラーの繰り返し」でできてると思います。
「コードを書く」だけじゃなくて、 「観察する」「ずれを発見する」「丁寧に直す」この一連のプロセスが、Botを強くしていく。
そして、それを言語化して残しておくと、何かが見えてくる。
今回のラジオも、自分の頭の整理と再学習のために残しました。
みなさんの開発にも、何かヒントになれば嬉しいです。
では、また次回の開発ログでお会いしましょう。
仮想通貨Bot開発者、よだかでした。