コードをそのまま追うより、まずは“設計の見出し”で整理するのがおすすめ
前回は、Lambdaのコードは一行ずつ細かく読むよりも、
全体の流れで見るとわかりやすい という話を書きました。
では実際に、アービトラージ用のLambdaを作るときは、
どんな章立てで設計すると理解しやすいのでしょうか。
ここでは、添付資料の流れをもとに、
「こういう順番で章立てすると、書く側も読む側もわかりやすい」
という形で整理します。
ポイントは、最初からコードの文法で考えるのではなく、
このLambdaは何を順番にやるのか を見出しレベルで分けることです。
結論
アービトラージ用Lambdaは「準備 → データ更新 → 判定 → 通知 → 終了」の章立てがわかりやすい
アービトラージ用Lambdaは、ざっくり言うと次の流れで組むと見通しがよくなります。
- このLambdaの目的を書く
- 設定をまとめる
- 必要な共通機能をまとめる
- データをそろえる
- 監視対象ごとに判定する
- 通知するか決める
- 結果を返して終わる
この順番になっていると、コードが読めない人でも
「今このLambdaは何をしている段階なのか」
がつかみやすくなります。
1章 このLambdaは何をするものなのかを書く
最初に“役割”を明確にする
最初にあるとわかりやすいのが、
このLambdaは何のためのものか をはっきりさせる章です。
アービトラージ用Lambdaは、ただ価格を取ってくるだけではありません。
多くの場合は、
- 相場データを集める
- 複数の通貨やペアを比べる
- 乖離やズレを確認する
- 条件に合ったら通知する
という役割を持っています。
この「目的」が先に見えるだけで、その後のコード全体がかなり読みやすくなります。
2章 設定をまとめる
しきい値や通知先は最初にまとめて置く
次にわかりやすいのが、
このLambdaで使うルールや設定を先にまとめる章 です。
アービトラージ系のLambdaでは、後ろの処理の途中に設定が散らばっていると、とても読みにくくなります。
そのため、最初のほうで
- 何日分のデータを見るのか
- どれくらいの差をシグナルとするのか
- 相関の基準はどこにするのか
- どこへ通知するのか
といったルールをまとめて置く設計がわかりやすいです。
添付資料の流れでも、まず環境変数やエントリー基準、相関の基準がまとまっていて、
「このLambdaはどんなルールで動くのか」が先に見える形になっています。
ここはブログでは、
“このLambdaのルールブック”
として説明すると理解されやすいです。
3章 共通で使う道具をまとめる
データ取得や保存のための下請け役を先に置く
その次にあると見やすいのが、
本体処理の前に、必要な道具をそろえておく章 です。
アービトラージ用Lambdaは、いきなり判定に入るのではなく、その前にいろいろな下準備が必要です。
たとえば、
- 外部サイトからデータを取りに行く
- CSVを読み取る
- 値を数字として扱えるようにする
- S3へ保存する
- S3から読み出す
- 平均や標準偏差を計算する
- 相関を見る
といった役割です。
ここを先にまとめておくと、本体側では
「今は何をしたいか」だけに集中して書けるので、設計がすっきりします。
たとえるなら、これは厨房でいう
包丁・まな板・鍋を先にそろえておく部分 です。
料理本編の途中で毎回道具を探し始めると読みにくいのと同じで、
Lambdaも共通で使う機能は前半にまとめておくとわかりやすくなります。
4章 データをそろえる
まず“判断できる状態”を作る
ここからが本体に入ります。
最初の本体章としてわかりやすいのは、
データをそろえる章 です。
アービトラージは、材料となる価格データがないと判断できません。
そのため最初にやるべきなのは、「今判定できるだけの材料を整えること」です。
添付資料の流れでは、ここがかなりきれいに分かれていて、
- まず初回の不足分を補完する
- 次に当月データを更新する
- そのあと直近期間の系列データを読み込む
という順番になっています。
つまり設計としては、
まず土台データを欠けなくそろえてから、判定へ進む
という形です。
これはとても大事で、アービトラージ系のLambdaは
「判定ロジックそのもの」より先に、
ちゃんと比較できる状態までデータを整えること が重要です。
5章 監視対象ごとに判定する
“ペアごとの判定章”を分けると一気に見やすくなる
次に来るのが、
どのペアをどう見るか という判定章です。
ここがアービトラージLambdaの中心ですが、
ここをひとまとめにすると急に読みにくくなります。
わかりやすくするコツは、
監視対象ごとに章を分けること です。
たとえば添付資料では、
- 順相関ペアを見る章
- 逆相関ペアを見る章
というように、考え方が違うペアを分けて判定しています。
これはとても読みやすい設計です。
なぜなら、
- 何を比べているのか
- どんな基準で見ているのか
- 条件を満たしたらどんな戦略になるのか
が、ひとつのまとまりで見えるからです。
ブログ用に書くなら、ここは次のように章立てするとわかりやすいです。
5-1. 順相関ペアの監視
動きが似やすい2つを比べて、ズレが大きくなったかを見る
5-2. 逆相関ペアの監視
反対方向に動きやすい2つを見て、関係が崩れていないか確認する
このように分けるだけで、読者は
「同じ判定ではなく、ペアの性質に合わせて見方を変えているんだな」
と理解しやすくなります。
6章 通知しない理由も残す
“通知した時”だけでなく“通知しなかった時”も設計に入れる
アービトラージ用Lambdaで意外と大事なのが、
通知しなかった理由をどう扱うか です。
単純な設計だと、
- 条件に合えば通知する
- 合わなければ何もしない
で終わってしまいます。
でも実運用では、それだと後から見たときに
「なぜ今日は通知がなかったのか」
がわかりにくくなります。
添付資料の流れでは、条件に合わなかったものを
抑制情報として別に持っておく考え方が入っています。
これは設計としてとてもわかりやすく、実務向きです。
つまりこの章では、
- シグナルが出たもの
- 今回は通知しないもの
- 通知しない理由
を分けて整理します。
7章 通知メッセージを作る
判定結果を“人が読める文章”へ変える
判定が終わったら、次は
人が読める形にする章 があるとわかりやすいです。
コードの中では数字や内部データで持っていても、
通知ではそのまま送るより、文章として整えたほうが見やすいです。
たとえば、
- 対象期間
- どのペアで
- どんな乖離が起きて
- どんな戦略を想定して
- 相関やZスコアがどうだったか
を順番に並べて通知文にします。
この章が独立していると、
「判定する部分」と「見せる部分」が分かれるので、設計がかなりきれいになります。
たとえるなら、これは
社内メモをそのまま送るのではなく、報告文に整える工程 です。
8章 通知するか、何もせず終わるかを決める
最後の分岐はシンプルにしておく
アービトラージ用Lambdaの最後は、
通知するかしないかを決める章 があると見やすくなります。
ここでは基本的に次の2つです。
- シグナルがなければ、そのまま正常終了
- シグナルがあれば、SNSなどで通知して終了
この分岐は、なるべく最後のほうにまとめるとわかりやすいです。
添付のLambda画面でも、コード・テスト・設定という流れで確認していく構成になっており、
実際の運用でも「書く」「試す」「動かす」の段階が分かれているほうが理解しやすいです。
9章 最後に実行結果を返す
人にもシステムにも“今回どうだったか”を残す
最後にあるとよいのが、
今回の実行結果を返す章 です。
ここでは、
- 正常終了したか
- シグナルがあったか
- 主要な判定値はどうだったか
- 抑制情報はあったか
といった結果を残します。
これは通知とは少し違います。
通知は人に知らせるためのものですが、こちらは
実行した記録として残すための出口 です。
この出口がきれいだと、あとからテストや運用をするときにも見やすくなります。
まとめ
アービトラージ用Lambdaをわかりやすく作るコツは、
コードを長く書くことではなく、
役割ごとに章立てして、流れを自然にすること です。
特に見やすい設計は、
- まずルールを決める
- 次に道具を用意する
- そのあとデータをそろえる
- ペアごとに判定する
- 通知するか決める
- 最後に結果を返す
という順番になっています。
この流れにしておくと、コードが読めない人でも
「このLambdaは今どの段階をしているのか」
がわかりやすくなります。
つまり、アービトラージ用Lambdaは
“計算ロジックの集まり”として作るより、“自動業務の流れ”として章立てするほうが圧倒的に理解しやすい
ということです。