序論：単なるアップグレードではない、レガシーシステム移行としてのMQL5化
金融市場におけるアルゴリズム取引の領域では、使用されるプラットフォームが取引戦略の成否を左右する決定的な要因となる。長年にわたり業界標準として君臨してきたMetaTrader 4 (MT4) は、そのエコシステムの成熟度と安定性から今なお多くのトレーダーに支持されている。しかし、技術的進化の潮流は、次世代プラットフォームであるMetaTrader 5 (MT5) へと明確に移行している。
MT5は、64ビット・マルチスレッドアーキテクチャによる高速な処理能力、21種類に及ぶ豊富な時間足（MT4の9種類と比較）、そして開発元であるメタクォーツ社による継続的な機能追加といった点で、アップデートが限定的となったMT4に対して圧倒的な技術的優位性を持つ 1。特に、ミリ秒単位の遅延が収益機会を左右するプロフェッショナルな取引環境において、MT5への移行はもはや単なる選択肢ではなく、競争力を維持・向上させるための戦略的必然であると言える。
しかし、この移行プロセスを単なるソフトウェアの「アップグレード」や、既存MQL4コードの安易な「書き換え」と捉えることは、深刻なリスクを内包する。本稿では、この移行をIT業界で確立された「レガシーシステム移行（Legacy System Migration）」という、より厳格なフレームワークの文脈で捉え直すことを提唱する 5。MQL4は事実上、新規機能開発が停止したレガシーシステムであり、そのコード資産は、今日の技術標準から見れば多くの技術的負債を抱えている可能性があるからである 3。
この移行プロセスにおける計画と管理の欠如が引き起こす「悪夢」は、単なるコンパイルエラーに留まらない。それは、コンパイル時には検知されない「サイレントバグ」による取引ロジックの意図せぬ変質、データアクセス方法の非効率化に起因するパフォーマンスの予期せぬ劣化、そして最悪の場合、直接的な資金損失へと繋がる。これらのリスクは、MQL4とMQL5の表層的な構文の類似性に隠された、両プラットフォーム間の根深いアーキテクチャの違いに起因するものである。
多くの技術解説がMT5の新機能紹介に終始する中で、本稿は、既存の貴重なコード資産をいかに「安全に」次世代プラットフォームへ移管するかという、より地味で、しかし遥かに重要なエンジニアリングの課題に焦点を当てる。本稿の目的は、属人的な試行錯誤や勘に頼るのではなく、体系化されたプロセスマネジメントを通じてこれらのリスクをいかに制御し、移行プロジェクトを成功に導くかの方法論を提示することにある。このアプローチこそが、単なるコード変換作業と、戦略的価値を創出するプロフェッショナルなエンジニアリングサービスとを明確に区別するものである 8。
第1章：「悪夢」の解剖：MQL4とMQL5の間に存在する技術的断絶
MT4からMT5への移行が困難である根源的な理由は、両者の間に存在する4つの主要な「技術的断絶」にある。これらの構造的差異を深く理解することなく、表層的な構文の置換に終始することは、ほぼ確実にプロジェクトの失敗を招く。本章では、これらの断絶を一つずつ解剖し、安易なアプローチが内包する危険性を明らかにする。
1.1 プログラミングパラダイムの変革：手続き型からオブジェクト指向（OOP）へ
第一の断絶は、プログラミング言語の根本的な設計思想の違いである。MQL4がC言語に類似した手続き型言語であるのに対し、MQL5はC++に近いオブジェクト指向プログラミング（Object-Oriented Programming, OOP）モデルを採用している 9。
このパラダイムシフトは、単なる構文の変更以上の意味を持つ。手続き型プログラミングが、一連の関数（手続き）の連続としてプログラムを構築するのに対し、OOPでは、データとそのデータを操作するメソッドを一体化した「オブジェクト」としてシステムをモデル化する。クラス、継承、ポリモーフィズムといったOOPの概念は、コードの再利用性を高め、複雑なロジックをより構造化された形で管理することを可能にする。これにより、MQL5では、より大規模でスケーラブルな取引システムの構築が容易になる。しかし、この変革は、手続き型の思考に慣れた開発者に対して、設計思想そのものの根本的な転換を要求する。MQL4のコードを単純にMQL5に移植するだけでは、MQL5が提供する構造化の恩恵を享受できず、むしろ管理が困難な「手続き型とオブジェクト指向のキメラ」のようなコードを生み出しかねない。
1.2 データアクセスモデルの根本的転換：同期的直接アクセスから非同期的ハンドルベースへ
MQL4とMQL5の間で最も決定的かつ危険な違いは、価格やインジケータといった時系列データへのアクセス方法にある。この違いこそが、多くの「サイレントバグ」の温床となる。
MQL4では、データアクセスは同期的かつ直接的である。例えば、iMA()関数を呼び出すと、その場で移動平均が計算され、その値が直接返される 9。開発者は、関数を呼び出せば常に正しい値が即座に返ってくるという、決定論的な世界観の中でプログラミングを行うことができる。
対照的に、MQL5のデータアクセスモデルは、非同期的かつ間接的である。まずiMA()のような関数を呼び出して、インジケータそのものを指し示す「ハンドル」（一意の識別子）を取得する。次に、CopyBuffer()関数を用いて、そのハンドルが管理するデータバッファから、必要なデータを非同期的に配列へとコピーする 9。
この「ハンドル取得」と「データコピー」の二段階プロセスは、極めて重要な意味を持つ。特に、市場の変動が激しい場面やネットワーク遅延が発生した場合、CopyBuffer()を呼び出した際に、取引サーバーからのデータダウンロードが完了していない可能性がある。その場合、関数はエラーを返すか、不完全なデータを返すことになる 10。この非同期性を考慮せず、MQL4と同じ感覚でデータを取得しようとすると、コンパイルは正常に完了するにもかかわらず、実行時に不正確なデータに基づいた誤った取引判断を下し続けるという、致命的な「サイレントバグ」が発生する。MQL5における堅牢なデータアクセスには、適切なエラーハンドリングと、データが準備できるまで待機するリトライ処理の実装が不可欠となる。
1.3 取引執行モデルの再構築：「注文」「約定(Deal)」「ポジション」の分離
第三の断絶は、取引のライフサイクルを管理するモデルの根本的な変更である。MQL4では、「注文（Order）」という単一の概念が、発注から決済までの取引全体を表現していた 12。
MQL5では、この取引概念が、より現実に即した形で「注文（Order）」「約定（Deal）」「ポジション（Position）」の3つに明確に分離された 13。
- 注文 (Order): ブローカーに対する取引の「依頼」そのもの。市場にまだ出ていない指値注文や逆指値注文を含む。
- 約定 (Deal): 注文が執行された結果として成立した個々の「取引事実」。一つの注文が複数の約定に分割されることもある。
- ポジション (Position): ある金融商品に対する純然たる「保有状況」。すべての約定を合算した結果として形成される。
この洗練されたモデルは、機関投資家レベルの精緻な取引管理を可能にするが、同時にプログラミングの複雑性を増大させる。MQL4の単純なOrderSend()関数に代わり、MQL5ではMqlTradeRequestという詳細な構造体に取引内容をすべて設定し、それをOrderSend()関数に渡す必要がある 9。この変更は、単なる関数名の置換では対応できず、取引執行ロジック全体の完全な再設計を要求する。
1.4 口座タイプの選択：ヘッジングとネッティング
最後に、MT5プラットフォーム自体が提供する2つの異なる口座管理モード、「ヘッジング」と「ネッティング」の存在が挙げられる 18。この選択は、取引戦略の根幹に関わる重大なアーキテクチャ上の決定である。
- ヘッジング (Hedging): MQL4と同様のモデルであり、同一の金融商品に対して複数の買いポジションと売りポジションを同時に保有することができる。各ポジションは独立したエンティティとして管理され、個別に決済することが可能である 18。
- ネッティング (Netting): 同一金融商品のポジションは、常に一つの純（ネット）ポジションに統合される。例えば、1ロットの買いポジションを保有している状態で、新たに0.5ロットの売り注文を出すと、結果として0.5ロットの買いポジションが残る。反対方向の注文は、既存ポジションの決済または縮小として扱われる 18。
両建て戦略、グリッド取引、あるいは複数の戦略を同一銘柄で独立して実行する場合、ヘッジング口座が必須となる。一方で、単一戦略におけるネットエクスポージャーの管理を効率化したい場合は、ネッティング口座が適している 20。移行プロジェクトを開始する前に、自社の取引戦略がどちらの口座モデルを前提としているかを明確に定義しなければ、コードの前提が根底から覆ることになる。
これらの4つの技術的断絶は、MT4からMT5への移行が単なるコード変換作業ではなく、深いシステムレベルの理解を要する複雑なエンジニアリングプロジェクトであることを示している。
| 項目 | MQL4 | MQL5 | 移行における主要な注意点 |
| プログラミングパラダイム | 手続き型 (C言語ライク) | オブジェクト指向 (C++ライク) | コード全体の構造設計と思想の転換が必要 9。 |
| データアクセスモデル | 同期的・直接アクセス (iMA()等) | 非同期的・ハンドルベース (CopyBuffer()等) | 非同期処理とエラーハンドリングが必須。サイレントバグの主因 9。 |
| 取引執行モデル | 「注文 (Order)」のみ | 「注文 (Order)」「約定 (Deal)」「ポジション (Position)」に分離 | 取引管理ロジックの完全な再設計が必要 12。 |
| 口座管理モデル | ヘッジングのみ | ヘッジングまたはネッティングを選択可能 | 戦略の前提となる口座タイプを事前に決定する必要がある 18。 |
| 主要イベント関数 | init(), start(), deinit() | OnInit(), OnTick()/OnCalculate(), OnDeinit() | 関数の役割と名称が変更。start()はEAとインジケータで対応関数が異なる 22。 |
| 主要な事前定義変数 | Ask, Bid, Bars | SymbolInfoDouble(), Bars()等で取得 | 事前定義変数は廃止。関数経由での取得に変更 23。 |
| インジケータバッファ数 | 最大8個 | 制限なし | 制限撤廃により高度なカスタムインジケータ開発が可能に 22。 |
| 実行速度 | – | MQL4より高速 (最大20倍との報告も) | パフォーマンス向上の恩恵を最大限に引き出す設計が求められる 4。 |
第2章：規律ある移行プロセスマネジメント
MQL5移行の「悪夢」を回避する鍵は、個々の開発者の能力に依存する属人的なコード書き換え作業を脱し、ソフトウェア工学の確立された原則に基づいた、体系的でリスク管理を重視したプロセスを導入することにある。真のプロフェッショナリズムは、コードを書く能力そのものよりも、プロジェクトに伴うリスクを予見し、管理する能力に現れる。本章では、AI MQLが実践する、3つのフェーズからなる規律ある移行プロセスを提示する。
2.1 フェーズ1：評価と戦略策定 (Assessment & Planning)
いかなるコード変更にも着手する前に、まず徹底的な現状分析と計画策定を行う。これは、あらゆるレガシーシステム移行プロジェクトにおける標準的な第一歩である 6。このフェーズの目的は、移行の全体像を正確に把握し、技術的・戦略的な意思決定を行うことにある。
具体的なタスクは以下の通りである。
- 既存MQL4コード資産の包括的監査: 移行対象となるすべてのエキスパートアドバイザー（EA）、カスタムインジケータ、スクリプトの棚卸しを行う。コードの行数、複雑度（サイクロマティック複雑度など）、外部ライブラリへの依存関係、そしてドキュメントの有無などを評価し、移行の難易度と工数を客観的に見積もる。
- 要件の再定義: 既存の取引ロジックが持つ機能的要件（エントリー・エグジット条件など）と非機能的要件（実行速度、メモリ使用量など）を改めて文書化する。このプロセスを通じて、現状の仕様が本当にビジネス目標に合致しているかを見直し、不要な機能の削除や、新たな要件の追加を検討する。
- 移行戦略の選択: 監査結果と再定義された要件に基づき、最適な移行戦略を選択する。例えば、既存ロジックが健全であれば、最小限の変更でMT5プラットフォームに対応させる「リプラットフォーミング」を選択する。一方で、コードが複雑化・陳腐化している場合は、内部構造を積極的に改善する「リファクタリング」や、一部機能の「再構築」を選択することもある 5。
- アーキテクチャ上の決定: この段階で、第1章で論じた口座タイプ（ヘッジング／ネッティング）の最終決定や、移行後のシステムが達成すべきパフォーマンス目標（サービスレベル目標、SLO）の初期設定を行う。これらの決定は、後続のすべての作業の前提となるため、極めて重要である。
この評価と計画のフェーズを省略することは、羅針盤と海図を持たずに航海に出るようなものである。時間とコストを要する作業ではあるが、プロジェクト全体のリスクを大幅に低減し、最終的な成功確率を高めるための最も確実な投資となる。
2.2 フェーズ2：リファクタリングとテストハーネス構築 (Refactoring & Testing)
MQL5へのコード移植は、単なる「書き換え」ではなく、ソフトウェア工学の権威であるMartin Fowlerが提唱する「リファクタリング」の規律に則って進められるべきである 26。リファクタリングとは、「外部から見た振る舞いを変えることなく、ソフトウェアの内部構造を改善していくこと」と定義される 26。その本質は、一度に大きな変更を加えるのではなく、検証可能な「小さなステップの連続」として、コードの可読性や保守性を着実に向上させていく点にある。
この安全なリファクタリングを実現するための絶対的な前提条件が、堅牢な自動テスト環境、すなわち「テストハーネス」の構築である 28。テストハーネスは、移行プロジェクトにおけるセーフティネットの役割を果たす。具体的には、移行前のMQL4コードと移行後のMQL5コードが、同一の入力データ（例：特定の期間のヒストリカルデータ）に対して、同一の出力（例：取引シグナルの発生タイミング、インジケータの値）を返すことを自動的に検証する仕組みである。
「テストがなければ、それはリファクタリングではない。単なる危険な書き換えだ」というFowlerの警鐘は、MQL5移行プロジェクトにおいてこそ真に重要となる。コードを一行でも変更する前に、まずそのコードの振る舞いを検証するテストを記述する。「テストファースト」の思想を徹底することで、開発者は自信を持って内部構造の改善に集中でき、意図しないロジックの変更（デグレード）を即座に検知することが可能になる。この規律こそが、技術的な成熟度を決定的に示し、安価なコード変換サービスとの品質の差を明確にするものである 8。
2.3 フェーズ3：段階的移行と並行検証 (Phased Migration & Validation)
すべての機能を一度に新しいシステムに移行する「ビッグバンアプローチ」は、一見すると迅速に見えるが、実際には極めて高リスクな手法である 30。問題が発生した場合、その原因特定が困難になり、プロジェクト全体が停止する可能性がある。
リスクを最小化するためのより優れたアプローチは、「段階的移行（Phased Migration）」である 30。これは、システム全体の機能を論理的なモジュール（例：データ取得部、シグナル生成部、注文執行部）に分割し、一つずつ慎重に移行・検証していく手法である。各ステップが小さいため、問題が発生しても影響範囲が限定され、迅速な対応が可能となる。
さらに、移行した機能の正当性を保証するために、「並行検証（Parallel Migration）」という手法が極めて有効である 30。これは、移行が完了したモジュールを含む新しいMQL5システムを、既存のMQL4システムと並行して（ただし、実際の注文は出さずに）稼働させ、両者の出力をリアルタイムで比較検証するものである。このアプローチにより、過去のデータを用いたバックテストでは発見できない、実環境のライブデータに起因する微妙な差異やバグを特定することができる。
この「評価→テスト構築→リファクタリング→段階的移行」という規律あるプロセスは、ソフトウェア工学の王道であり、これをMQLの世界に適用することこそが、移行プロジェクトを「悪夢」から、管理可能で予測可能なエンジニアリングへと変える鍵なのである。
第3章：移行の先へ：サイト信頼性エンジニアリング（SRE）による運用的卓越性の確保
MQL5へのコード移行完了は、プロジェクトの終わりではない。それは、より高度で複雑なシステムを本番環境で安定稼働させるという、新たな挑戦の始まりである。プロップトレーディングファームのような高度な要求を持つ顧客は、単にEAが「動く」ことだけを求めているのではない。彼らが真に求めるのは、予測可能で、測定可能で、そして継続的に管理可能な「信頼性（Reliability）」である。この要求に応えるため、AI MQLはGoogle社が提唱・実践する「サイト信頼性エンジニアリング（Site Reliability Engineering, SRE）」の原則を導入する。これは、AI MQLが提供する継続的な保守サービス（事業戦略における「盾」）の理論的支柱となるものである 8。
3.1 SREとは何か：ソフトウェアエンジニアリングによる運用課題の解決
SREは、Googleのエンジニアリングチームから生まれ、システムの信頼性を維持・向上させるための体系的なアプローチである 31。その核心は、従来、手作業で行われがちだったシステム運用業務（Googleではこれを「トイル（Toil）」と呼ぶ）を可能な限り自動化し、ソフトウェアエンジニアリングの規律とプラクティスをインフラと運用の領域に適用することにある 33。SREは、「信頼性は最も重要な機能である」という思想に基づき、システムの可用性、レイテンシー、パフォーマンス、効率性を継続的に改善することを目指す。
3.2 SLOとエラーバジェット：信頼性の定量化
SREは、抽象的で定性的な「信頼性」という概念を、客観的かつ定量的な指標に落とし込むための強力なフレームワークを提供する。その中核をなすのが、「サービスレベル目標（Service Level Objective, SLO）」と「エラーバジェット」である 33。
- SLO (サービスレベル目標): ユーザーにとって重要なサービスの品質を定義する具体的な目標値である。100%の信頼性は非現実的かつ非経済的であるという前提に立ち、達成可能で意味のある目標を設定する。取引システムにおけるSLOの具体例としては、以下のようなものが考えられる。
- 「成行注文の執行レイテンシー（注文要求から約定通知まで）の中央値が50ミリ秒未満である」
- 「APIサーバーへのリクエストにおけるエラー率が月間0.01%未満である」
- 「システムの月間稼働率が99.99%以上である」
- エラーバジェット (Error Budget): SLOが許容する「不信頼性」の量である（$100\% – SLO$）。例えば、稼働率のSLOが99.99%の場合、エラーバジェットは0.01%となり、これは月間でおよそ4分23秒のダウンタイムに相当する。このエラーバジェットは、開発チームと運用チームの間の共通言語となる。バジェットが残っている限り、新機能のリリースといったリスクを伴う変更を積極的に行うことができる。逆に、バジェットを使い果たしてしまった場合は、新たな機能開発を凍結し、信頼性向上のための作業にリソースを集中させる。これにより、開発速度と信頼性の間のトレードオフを、データに基づいて合理的に判断することが可能になる。
3.3 4つのゴールデンシグナル：何を監視すべきか
効果的なSLOを設定し、エラーバジェットを管理するためには、システムの健全性を正確に把握するための適切な監視が不可欠である。SREは、あらゆるシステムの健全性を測る上で最も重要な4つの基本的な指標として、「4つのゴールデンシグナル」を提唱している 33。これらのシグナルを取引システムの文脈に翻訳すると、以下のようになる。
- レイテンシー (Latency): リクエストに対する応答時間。取引システムにおいては、注文要求からブローカーのサーバーがそれを受理し、約定通知が返ってくるまでの時間がこれに該当する。レイテンシーの増大は、スリッページの発生に直結する最重要監視項目である。
- トラフィック (Traffic): システムが受けている負荷の量。単位時間あたりの注文数、受信するティックデータの量、APIコール数などがこれにあたる。トラフィックの急増や異常なパターンは、システム障害や市場の異変の兆候となり得る。
- エラー (Errors): 明示的に失敗したリクエストの割合。注文がブローカーに拒否（リジェクト）された回数、API呼び出しが失敗した割合などが該当する。エラー率の上昇は、システムの健全性が損なわれている明確なシグナルである。
- サチュレーション (Saturation): システムリソースがどれだけ「満杯」に近いかを示す指標。CPU使用率、メモリ占有率、ディスクI/O、ネットワーク帯域などがこれに含まれる。サチュレーションは、システムの限界がどこにあるかを示し、障害が発生する前にプロアクティブな対応（例：サーバーのスケールアップ）を可能にするための先行指標として極めて重要である。
これらのゴールデンシグナルを継続的に監視し、SLOと比較することで、システムの信頼性を客観的に評価し、障害の予兆を早期に検知することが可能になる。SREのフレームワークを導入することは、AI MQLが単なる「コードを書く会社」から、顧客のシステムの「信頼性にコミットする戦略的パートナー」へと、その提供価値を昇華させることを意味するのである。
結論：移行を技術的負債の返済から、戦略的優位性の確立へ
MT4からMT5への移行は、多くの開発者や組織にとって、避けては通れない技術的課題である。本稿で詳述したように、このプロセスを安易なアップグレードと見なせば、それは取引ロジックの崩壊と資金損失に繋がりかねない「悪夢」と化す。しかし、本稿で概説したような、ソフトウェア工学の原則に根差した規律あるプロセスマネジメントを適用することで、この移行は単なるプラットフォーム対応という守りの一手ではなく、未来の成長を加速させる攻めの戦略的投資へと昇華される。
この体系的なプロセスを通じて得られる成果は、単にMQL5環境で動作するコード資産だけではない。それは、より本質的で永続的な価値を持つ、以下の3つの戦略的資産である。
- 技術的負債の返済: 規律あるリファクタリングのプロセスを通じて、過去の場当たり的な継ぎ足し開発によって劣化したコードの内部構造が体系的に改善される。これにより、コードの可読性、保守性、拡張性が向上し、将来の変更に対する俊敏性が飛躍的に高まる。
- 品質の可視化と保証: 移行プロセスの一環として構築される包括的な自動テストハーネスは、システムの品質を開発者の主観から解放し、定量的かつ客観的に保証するための恒久的な資産となる。これにより、将来のいかなる変更も、既存のロジックを破壊しないという高い信頼性の下で実施することが可能になる。
- 運用的卓越性の獲得: SREの原則を導入することで、システムの信頼性は「祈り」や「願望」の対象ではなく、SLOやゴールデンシグナルといった具体的な指標を通じて科学的に管理・改善される対象となる。これにより、障害を未然に防ぎ、万一発生した場合でも迅速に復旧できる、プロフェッショナルレベルの運用体制と文化が醸成される。
これら3つの資産は、相互に連携し、将来のアルファ創出と持続的な競争優位性を支える、強固で信頼性の高い技術基盤を形成する。したがって、適切に計画・管理されたMQL5への移行は、過去の負債を清算すると同時に、未来の成長機会を最大化するための、最も確実な投資の一つであると結論付けられる。
このような高度なエンジニアリング・プロジェクトを成功に導くためには、単なるコーディングスキルを超えた、体系化されたプロセス管理能力と、金融システムの信頼性に対する深い洞察力を持つ戦略的パートナーの存在が不可欠である。移行の先にある真の価値を見据え、適切なパートナーと共にこの挑戦に臨むことこそが、次世代のアルゴリズム取引で成功を収めるための第一歩となるであろう。
引用
- MT5とは？MT4との違いと利用者別おすすめポイントを徹底解説！ – Winserver, 10月 29, 2025にアクセス、 https://www.winserver.ne.jp/column/about_%EF%BD%8Detatrader5/
- 【2024年最新版】MT4とMT5の違い15選！どちらがおすすめかなども徹底解説 – HFM, 10月 29, 2025にアクセス、 https://www.hfm.com/int/jp/blog/mt4-mt5-difference/
- MT4とMT5の違い10選！どっちがおすすめ？【利用上の注意点】 – ThreeTrader, 10月 29, 2025にアクセス、 https://www.threetrader.com/jp/blog/difference-between-mt4-and-mt5
- New MQL5 language features – MQL4 Reference, 10月 29, 2025にアクセス、 https://docs.mql4.com/mql5_language
- 5 Phases of Legacy System Migration + Common Strategies – Superblocks, 10月 29, 2025にアクセス、 https://www.superblocks.com/blog/legacy-system-migration
- Learning Legacy Systems Migration Inside and Out – OpenLegacy, 10月 29, 2025にアクセス、 https://www.openlegacy.com/blog/legacy-systems-migration
- Understanding legacy system migration: how does it work? – Alumio, 10月 29, 2025にアクセス、 https://www.alumio.com/blog/legacy-system-migration-how-does-it-work
- AI MQL
- Differences Between MQL4 and MQL5 | by Luka – Medium, 10月 29, 2025にアクセス、 https://lukasavi-34031.medium.com/differences-between-mql4-and-mql5-f07065a0858d
- （備忘録）MQL4⇒MQL5で苦戦したこと。インジケータ関数。｜じゅにこ – note, 10月 29, 2025にアクセス、 https://note.com/junico02_se_blog/n/nb95bec7e0ba1
- How to convert MT4 Expert Advisor into MT5 format in 2017 – Chart Patterns PDF, 10月 29, 2025にアクセス、 https://www.ea-coder.com/convert-mql4-to-mql5/
- Trade Functions – MQL4 Reference, 10月 29, 2025にアクセス、 https://docs.mql4.com/trading
- Trade Functions – MQL5 Reference, 10月 29, 2025にアクセス、 https://www.mql5.com/en/docs/trading
- MetaTrader 5 Orders, Positions, Deals Guide | PDF | Cache (Computing) – Scribd, 10月 29, 2025にアクセス、 https://www.scribd.com/document/100367050/03-Order-Deal-Positions
- Trade Functions – MQL5 features – MQL4 Reference, 10月 29, 2025にアクセス、 https://docs.mql4.com/mql5_language/mql5_functions/mql5_trading
- OrderSend – Trade Functions – MQL5 Reference, 10月 29, 2025にアクセス、 https://www.mql5.com/en/docs/trading/ordersend
- Trade Operation Types – Trade Constants – Constants, Enumerations and Structures – MQL5, 10月 29, 2025にアクセス、 https://www.mql5.com/en/docs/constants/tradingconstants/enum_trade_request_actions
- Trading – Orders: MetaTrader 5 – MT5 – AMP Futures, 10月 29, 2025にアクセス、 https://www.ampfutures.com/metatrader/trading-platform/trading
- The Difference Between Hedging and Netting on MT5 – B2Broker, 10月 29, 2025にアクセス、 https://b2broker.com/news/the-difference-between-hedging-and-netting-on-mt5/
- Comparison between MT5 (Hedged) and MT5 (Netted) position accounting – StrategyQuant, 10月 29, 2025にアクセス、 https://strategyquant.com/forum/topic/comparison-between-mt5-hedged-and-mt5-netted-position-accounting/
- Hedging vs Netting in MT5: Key Differences and Strategies – JustMarkets, 10月 29, 2025にアクセス、 https://justmarkets.com/trading-articles/learning/hedging-vs-netting-in-metatrader-5
- MQL4 からの移行 – MQL5 リファレンス, 10月 29, 2025にアクセス、 https://www.mql5.com/ja/docs/migration
- Moving from MQL4 – MQL5 Reference – Reference on algorithmic/automated trading language for MetaTrader 5, 10月 29, 2025にアクセス、 https://www.mql5.com/en/docs/migration
- Migrating From MQL4 To MQL5 – MQL5 Articles | PDF | Integer (Computer Science) – Scribd, 10月 29, 2025にアクセス、 https://www.scribd.com/document/830354435/Migrating-from-MQL4-to-MQL5-MQL5-Articles
- Legacy System Cloud Migration Process: 5 Stages Explained – Stromasys, 10月 29, 2025にアクセス、 https://www.stromasys.com/resources/five-phases-of-legacy-system-migration-to-cloud/
- Refactoring – Martin Fowler, 10月 29, 2025にアクセス、 https://martinfowler.com/books/refactoring.html
- refactoring – Martin Fowler, 10月 29, 2025にアクセス、 https://martinfowler.com/tags/refactoring.html
- The key points of Refactoring – Understand Legacy Code, 10月 29, 2025にアクセス、 https://understandlegacycode.com/blog/key-points-of-refactoring/
- Martin Fowler, 10月 29, 2025にアクセス、 https://martinfowler.com/
- Why legacy system migration matters and how to do it (7 strategies) – Webflow, 10月 29, 2025にアクセス、 https://webflow.com/blog/legacy-system-migration
- Site reliability engineering – Wikipedia, 10月 29, 2025にアクセス、 https://en.wikipedia.org/wiki/Site_reliability_engineering
- Site Reliability Engineering (SRE) – Google Cloud, 10月 29, 2025にアクセス、 https://cloud.google.com/sre
- The 7 SRE Principles [And How to Put Them Into Practice] – FireHydrant, 10月 29, 2025にアクセス、 https://firehydrant.com/blog/sre-principles/
- Hope Is Not a Strategy: 7 Principles of Site Reliability Engineering …, 10月 29, 2025にアクセス、 https://www.ibm.com/think/insights/sre-principles
- Tenets of SRE. What actually is the philosophy of Site… | by Stephen Thorne | Medium, 10月 29, 2025にアクセス、 https://medium.com/@jerub/tenets-of-sre-8af6238ae8a8