MQL5入門（第33回）：MQL5のAPIとWebRequest関数の習得(VII)

はじめに

連載「MQL5入門」の第33回へようこそ。本連載ではこれまで、MQL5がどのようにしてWebRequest関数を用い、外部プラットフォームと通信するかに焦点を当ててきました。HTTPリクエストの送信方法、サーバーからの応答の受信および解析方法、ローソク足データの整理方法、ファイルへの保存方法、そしてカスタムインジケーター内での可視化方法について学んできました。これらのステップにより、MetaTrader 5における外部データ処理の強固な基盤が構築されます。

本記事では、その応用としてMetaTrader 5をGoogle Generative AI APIと連携させ、より実用的なユースケースを解説します。テキストベースのクエリ送信、高度な応答の受信、リクエストボディの適切な構築、サーバー応答の解析、JSONデータから有用な情報の抽出、さらに1分あたりのリクエスト数、1日あたりのリクエスト数、1分あたりのトークン数といったAPI制限の管理についても網羅的に解説します。

本チュートリアルを終える頃には、AI APIがMQL5のWebRequestワークフローにどのように統合されるのかを十分に理解できるようになっているでしょう。さらに重要なのは、この仕組みが従来の取引ロジックに代わる高度な機能追加手段としてどのように活用できるかを理解できる点です。これにより、MetaTrader 5上で取引アシスタント、学習支援ツール、自動解説機能など、より高度な機能を備えたアプリケーションを構築することが可能になります。

API使用におけるレート制限の理解

Google APIをはじめとする各種APIへの呼び出しには、あらかじめ設定されたレート制限が存在します。これらはシステムの安定性を保ち、すべてのユーザーに公平な利用環境を提供するために設けられています。制限がなければ、過剰なリクエストによってサーバーに負荷が集中し、エラーの発生や処理速度の低下を招き、結果として自分のアプリケーションだけでなく他の利用者にも影響が及びます。 レート制限の本質的な目的は、APIトラフィックを適切に制御し、不正利用や過負荷を防ぐことにあります。具体的には、1分あたりや1日あたりといった単位で、リクエスト数やトークン数の上限が定められています。この仕組みによって、すべてのユーザーに対して公平なリソース配分が保証されると同時に、特定のユーザーがサーバー資源を独占することも防がれます。

こうした制約を正しく理解し遵守することで、プログラム全体の安定性と効率は大きく向上します。制限内に収めるための工夫としては、リクエストのバッチ処理、一時的なキャッシュの活用、あるいは呼び出し間隔の調整などが挙げられます。これらの手法により、エラーの発生を抑えつつ、より滑らかで安定した動作を実現でき、結果としてユーザー体験と開発効率の両方が改善されます。

比喩的な説明

図書館に本棚が一つしかなく、多くの利用者が同時に本を借りようとしている状況を想像してみてください。混雑を避けて公平性を保つために、司書は「1分間に5冊まで」といった形で、利用者が一定時間内に借りられる冊数を制限します。この例において、APIサーバーは図書館の窓口、リクエストは借りたい本、そしてルールそのものがレート制限に相当します。一度に多数の利用者が追加のリクエストをおこなおうとした場合、制限により、処理が安全に再開できるまでそれ以上のリクエストを一時的に停止します。これにより窓口の混雑が防がれ、すべての利用者に対して公平なアクセスが保証されます。

同様に、GoogleなどのAPIも、一定以上のリクエストが発生した場合には一時的に制限をかけます。これは、チケットの発行数に上限がある状況で、順番を待つ必要があるのと同じです。制限を超えた場合、待機するか、リクエスト頻度を下げる必要があります。この仕組みにより、サーバーの過負荷を防ぎ、システム全体の安定性が保たれると同時に、すべての利用者に対して公平なアクセスが保証されます。

リクエストには無制限に送信できるわけではないという前提を踏まえた上で、レート制限が実際にどのように機能するかを理解します。RPM (Requests Per Minute)は、その中でも最初にして最も基本的な制約です。RPMとは、プログラムが1分間にサーバーへ送信できる個別のAPIリクエスト数を指します。MQL5プログラムがWebRequestを通じてAPIと通信するたびに、その回数はこの上限に対してカウントされます。リクエストの内容が単純であっても複雑であっても、すべて1回としてカウントされます。たとえば、RPMの上限が60に設定されている場合、1分間に最大60回までリクエストを送信できます。このとき、リクエスト間隔を厳密に1秒空ける必要はありません。短時間にまとめて送信することも可能です。ただし、合計が60回に達した時点で、それ以上のリクエストは拒否されるか、次の1分間まで保留される場合があります。

この制限の目的は、短時間に大量のリクエストがサーバーへ集中することを防ぐことにあります。急激なトラフィック増加は、サーバーの応答遅延やエラー、一時的なリクエスト拒否の原因となる可能性があります。APIプロバイダーはこのような制限を設けることで、すべてのユーザーが安定してサービスを利用できる環境を維持しています。 そのため、MQL5でAPIを利用する際には、リクエストの送信頻度を常に意識することが重要です。RPM制限は、短時間にリクエストを連続送信した場合や、複数の処理が同時に走った場合に容易に超過してしまう可能性があります。

上限に達した場合、次の1分間は追加のリクエストが拒否されることがあり、多くの場合「最大リクエスト数を超過した」といったエラーメッセージが返されます。これを防ぐためには、前回の送信時刻を記録し、次のリクエストまでに適切な遅延を設けることが有効です。また、以前のレスポンスを再利用したり、複数のクエリをまとめて送信することで、無駄なAPI呼び出しそのものを減らすこともできます。こうした工夫によって、レート制限に抵触するリスクを抑えつつ、プログラムを安定して動作させることができます。

1日あたりのリクエスト数

RPD (Requests Per Day)は、もう一つの重要なレート制限です。これは、ソフトウェアが1日に送信できるリクエストの最大数を定義するものであり、1分単位の制限であるRPMとは異なる観点でトラフィックを管理します。頻繁にAPI呼び出しをおこなうMQL5開発者にとっては、日単位でのリクエスト消費量を把握し、監視することが不可欠です。RPDの上限に達した場合、その日中はそれ以上のリクエストが拒否される可能性があります。通常、この制限はUTCの午前0時にリセットされます。 そのため、RPD制限を超えないように設計することが重要です。必要なリクエストのみを送信し、可能な場合は過去に取得したデータを再利用することで、無駄なAPI呼び出しを減らすべきです。さらに、結果をキャッシュしたり、複数の処理を1回のリクエストにまとめたりすることも有効な手段です。

1分あたりのトークン数

APIを利用する上でもう一つ重要な制限が、トークン数に関する制約です。特にGoogle Generative AI APIのようなAIベースのサービスでは、この制限は非常に重要な意味を持ちます。TPM (Tokens Per Minute)は、1分間に処理できるトークン総量を示す指標であり、リクエスト数を制御するRPMやRPDとは異なり、テキストの「量」そのものを基準とした制限です。実際のところ、すべてのリクエストは一定数のトークンを消費します。トークンとは、入力するプロンプトとAPIが生成する応答の両方を構成するテキストの単位を指します。これにより、複雑なリクエストや長文の生成がサーバーに過度な負荷を与えないよう制御されています。たとえRPMやRPDの制限内であっても、長いプロンプトを送信したり、大きな応答を要求した場合には、TPMの上限に早く到達してしまう可能性があります。そのため、トークン使用量の監視は非常に重要です。上限に達すると、追加のリクエストは次の1分間まで拒否または遅延されます。

MQL5においては、プロンプトを簡潔にする、不要な出力を抑える、あるいは過去の応答を再利用して要約することで、トークン消費を効率的に管理できます。こうした工夫により、APIとの安定した通信を維持し、TPM制限を超えるリスクを抑えることができます。TPMは、APIが1分間に処理したすべてのトークンの合計によって計算されます。AI APIにおけるトークンは、単語全体、単語の一部、あるいは句読点などの単位として扱われます。たとえば「Hello, world!」という短いフレーズでも、「Hello」「,」「world」「!」の4つのトークンに分割されます。このカウントには、ユーザーが送信した入力だけでなく、AIが生成した出力も含まれます。

APIは、すべてのリクエストに含まれるトークン量を1分単位で追跡し、合計がTPM上限を超えた場合には、その時点で追加のリクエストを一時的に制限します。これは、単一の長いプロンプトや長文の応答だけでも、割り当ての大部分を消費し得ることを意味します。MQL5アプリケーションでTPMを適切に管理するには、各リクエストとレスポンスで消費されたトークン数を合算し、継続的に監視する必要があります。多くのAPIでは、レスポンス内にトークン使用量を示すフィールドが提供されており、これを活用することで消費状況の追跡が容易になります。トークン使用量を把握することで、プロンプトの最適化、呼び出し頻度の調整、処理の分割などが可能になり、結果としてTPM制限内で安定した動作を維持できます。

TPMには通常、プロンプトとサーバーからの応答の両方に含まれるトークンが含まれますが、HTTPヘッダーやその他のメタデータは一般的に含まれません。長いプロンプトに対して短い応答が返る場合でも、あるいは短いプロンプトに対して長い応答が生成される場合でも、いずれも相当量のトークンが消費される可能性があります。また、トークンのカウント方法はプラットフォームによって異なる場合があるため、TPMがどのように算出されているかについては必ず該当するAPIドキュメントを確認し、プログラムのトークン使用量が正確に追跡されていることを確実にしてください。

APIキーの生成

APIを利用する前に、APIキーの役割と仕組みを理解しておく必要があります。APIキーとは、APIプロバイダーが各アプリケーションを識別するために発行する一意の識別子です。これによりサーバーはリクエストの送信元を確認できるようになり、利用状況の監視や認証をおこなうことが可能になります。通常、APIは有効なキーを含まないリクエストを拒否します。これは、送信元を特定できない場合や、レート制限を正しく適用できないためです。 またAPIキーは、サービス提供側が利用状況を追跡し、レート制限を適用し、不正アクセスを防止するための重要な仕組みでもあります。サーバーは、APIキーを通じて特定のアカウントごとにRPM、RPD、TPMといった制限を適用できます。なぜなら、すべてのリクエストにこのキーが含まれており、それによって「どのユーザーからのリクエストか」を識別できるからです。言い換えれば、APIキーはサーバーに対して「このリクエストは正規のアプリケーションから送られている」という情報を伝え、適切な処理を可能にする役割を持ちます。

これまで述べてきた通り、本記事の例ではGoogleの無料APIを使用します。MQL5からGoogleのGemini APIと連携するためには、まずAPIキーを作成する必要があります。APIの仕様によって、このキーはリクエストボディまたはWebRequestヘッダーのいずれかに含めて送信されます。次のセクションでは、このAPIキーを作成し、MQL5プログラムで利用できる形に準備する手順を段階的に説明します。

比喩的な説明

図書館で本を借りるために、有効な図書館カードの提示が必要だと考えてみてください。このカードは利用者の身元を確認する役割を持つと同時に、司書が貸出履歴や利用頻度を管理するためにも使用されます。カードがなければ本を借りることはできません。この例では、本はAPIが返すレスポンスに相当し、図書館カードはAPIキーに相当します。そして司書はAPIサーバーを表しています。

Google Generative AI APIを使用するには、まずAPIキーを作成する必要があります。このキーによってGoogleのサーバーはアプリケーションを識別し、MQL5からのリクエストを認証できるようになります。まずブラウザを開き、aistudio.google.comにアクセスしてください。ページが表示されたら、[Get API Key]オプションを見つけてクリックします。これにより、GoogleのAIサービス用APIキーの作成および管理画面へ移動します。

次に[Create API Key]を選択します。キー名の入力を求められるので、分かりやすい名前を設定してください。この名前は主に自分用の識別目的であり、複数のキーを管理する場合に特に役立ちます。名前を入力したらキーを生成します。 生成が完了すると、Googleは画面上にAPIキーを表示します。この時点で、キーを必ずコピーし、安全な場所に保存してください。パスワードマネージャーや保護されたテキストファイルなどへの保管が推奨されます。このAPIキーは後でMQL5からWebRequestを使ってAPIを呼び出す際に必要になります。紛失した場合や漏洩した場合は、新しいキーを再生成する必要があります。

MQL5でGoogle AIリクエストを送信する

APIキーを取得したら、次のステップはMQL5からGoogle Generative AI APIへのリクエスト送信を有効化することです。そのためには、MetaTrader 5側で外部APIエンドポイントへのアクセス許可を設定する必要があります。続行する前に、Ctrl + Oを押してオプションウィンドウを開き、[エキスパートアドバイザ]タブを選択します。その中にある[リストされたURLのWebRequestを許可する]セクションに、以下のAPIエンドポイントを追加します。 

https://generativelanguage.googleapis.com

この設定は非常に重要です。MetaTrader 5はセキュリティ上の理由から、外部へのWebリクエストを初期状態では制限しています。このURLを明示的に許可することで、MQL5プログラムがGoogleのAPIサービスへリクエストを送信することをユーザー自身が承認したことになります。設定が完了したら、WebRequest関数を使用してデータの送受信をおこなうMQL5コードを作成します。 これにより、APIキーの付与、リクエストの構築、Google Generative AI APIへのデータ送信、そしてサーバー応答の受信までの一連の処理を実装できます。APIキーの準備とURLの許可設定が完了すれば、あとはMQL5スクリプトを通じて実際のリクエストを送信する段階に進みます。このスクリプトが、APIへの問い合わせ全体（リクエスト生成、認証情報の付与、送信、およびレスポンスの受信）を担当することになります。

例：

string API_KEY = "AbcdefCKJXiFPdvvM6f4ivPZ-zA2Qnoq6gabcde";
//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
//---
   string url =  "https://generativelanguage.googleapis.com/v1beta/models/"
                 "gemini-2.5-flash-lite:generateContent?key=" + API_KEY;

  }

説明

最初のステップは、事前に取得しておいたGoogleの認証情報、つまりAPIキーを定義することです。このキーは、Google Generative AI APIへのすべてのリクエストを認証するために欠かせません。APIキーによってアカウントやプロジェクトが識別されることで、サーバー側は利用状況を把握し、1分あたりのトークン数やリクエスト数、1日あたりのリクエスト数といった制限を適用できます。APIキーを変数として保存しておけば、MQL5プログラムからリクエストを送るたびに簡単に再利用できます。 もうひとつ重要なのが、APIリクエストURLの構造です。URLは「ドメイン」「パス」「クエリ文字列」の3つで構成されています。ドメインは通信先のサーバーを示し、安全な接続(HTTPS)を利用してGoogleの生成AIサーバーへリクエストを送る役割を担います。このサーバーが今回の受信クエリを処理します。

ドメインに続く「パス」は、サーバーにどの処理を実行させるかを具体的に指定する部分です。ここには使用するAIモデルや実行する操作、さらにはAPIのバージョンなどが含まれます。つまり、リクエストを受け取ったサーバーに対して「何をしてほしいのか」を明確に伝える役割があります。 最後の「クエリ文字列」は、リクエストに必要な追加情報を渡すためのものです。ここにAPIキーを含めることで、サーバーはリクエストの正当性を確認できます。また、複数のパラメータを指定してリクエスト内容を細かくカスタマイズすることも可能です。

これらを組み合わせることで、MetaTrader 5からGoogle Generative AI APIへ通信するための完全なURLが構築されます。この、パスが処理内容を示し、クエリ文字列が認証や追加情報を提供し、ドメインが通信先を定義するという仕組みによって、WebRequest関数とAPIの間で正確かつ安全なやり取りが実現されます。

比喩的な説明

APIキーは「図書館カード」のようなものです。このキーはアプリケーションの身元をGoogleサーバーに伝え、AIサービスへのアクセスを許可します。図書館カードがなければ本を借りられないのと同じように、APIキーがなければAPIから応答を得ることはできません。 URLの「パス」は、図書館の中の特定のコーナーに例えられます。例えば特定のテーマの本を探すとき、そのジャンルの棚へ向かいます。それと同様に、パスはリクエストを適切なAIモデルに導き、「どんな処理をしてほしいのか」を指定します。

クエリ文字列とAPIキーの組み合わせは、図書館のカウンターでカードを提示して本を借りる手続きに似ています。司書はカードを確認し、利用者の情報をチェックした上で本を貸し出します。同じように、クエリ文字列にはリクエストに必要な情報が含まれ、サーバーはそれをもとにリクエスト元を確認します。

次におこなうのは、WebRequestに必要なすべてのパラメータを設定することです。具体的には、リクエストボディ、ヘッダー、そしてHTTPメソッド（GETやPOSTなど）を定義します。これらの情報によって、MetaTrader 5は「どんなデータを送るのか」「応答をどう扱うのか」「Google Generative AI APIとどう連携するのか」を理解します。これらのパラメータが正しく設定されていれば、MQL5スクリプトは問題なくリクエストを実行し、APIからの応答を受け取り、そのデータを適切に処理できるようになります。

例：

string API_KEY = "AbcdyCKJXiFPdvvM6f4ivPZ-zA2Qnoq6gabcde";
//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
//---
   string url =  "https://generativelanguage.googleapis.com/v1beta/models/"
                 "gemini-2.5-flash-lite:generateContent?key=" + API_KEY;

   string headers = "Content-Type: application/json\r\n";
   string body = "{"
                 "\"contents\": ["
                 "{"
                 "\"parts\": ["
                 "{"
                 "\"text\": \"Tell me about MQL5\""
                 "}"
                 "]"
                 "}"
                 "]"
                 "}";

   char data[];
   int copied = StringToCharArray(body, data, 0, WHOLE_ARRAY, CP_UTF8);

   if(copied > 0)
      ArrayResize(data, copied - 1);

   char result[];
   string result_headers;
   int timeout = 15000;

   int response = WebRequest("POST",url,headers,timeout,data,result,result_headers);

   if(response == -1)
     {
      Print("WebRequest failed. Error: ", GetLastError());
      return;
     }

   string response_text = CharArrayToString(result);
   Print(response_text);

  }

説明

WebRequestを送信する最初のステップは、リクエストヘッダーを設定することです。ヘッダーでは、送信するデータがJSON形式であることを明示し、サーバーに「どのようにデータを解釈すべきか」を伝えます。この指定により、JSON形式のクエリを前提とするGoogle Generative AI APIが、リクエストを正しく処理できるようになります。つまりヘッダーは、受信データを処理するための指針となるメタデータを提供する役割を持っています。 次に、データはAPIの仕様に従って準備され、リクエストボディに含めて送信されます。ここでは、Gemini AIで使用されるcontents配列を持つJSONオブジェクトを利用します。配列内の各要素にはpartsが含まれており、その中にAIへの入力となるtextフィールドが定義されています。

'{
"contents":
[
   {
 "parts": [
      {
 "text": "How does AI work?"
      }
    ]
  }
]
  }'

この仕組みによって、サーバーはメッセージを正確に解釈し、適切な応答を返すことができます。APIがリクエスト本文を正しく処理するためには、本文が指定されたフォーマットに厳密に従っている必要があります。MQL5のWebRequest関数では、リクエストボディを文字配列として渡す必要があるため、文字列はUTF-8でエンコードされた配列に変換されます。これにより、特殊文字を含め、すべての文字が正しくサーバーに伝わります。 変換後に自動的に付加されるヌル(null)文字は、配列サイズを調整することで削除されます。この処理をおこなうことで、サーバーは不要な文字を含まない正確なJSONデータを受け取り、誤った解釈を防ぐことができます。

サーバーからの応答を受け取るために、いくつかの変数が初期化されます。タイムアウトは応答を待つ最大時間を指定するために設定され、応答ヘッダーとボディはそれぞれ別の変数に保存されます。これにより、サーバーから返された情報を漏れなく正確に記録できます。 WebRequest関数は、設定したヘッダー、ボディ、タイムアウトを用いて指定したURLにリクエストを送信します。その結果として、リクエストの成功または失敗を示すステータスコードが返されます。リクエストが失敗した場合は、処理を停止し、エラーコードを出力します。これはデバッグや誤ったデータ処理を防ぐうえで非常に重要です。

最後に、文字配列として受け取った応答は再び文字列へ変換されます。この変換によって、アプリケーションはAIが生成した内容を読み取り、処理し、表示できるようになります。これで、MQL5におけるWebRequestの送受信プロセスは完了し、指定したプロンプトに基づくAIの応答が取得されます。

比喩的な説明

ヘッダーは、司書に「どの形式で本を受け取りたいか」を伝える指示のようなものです。コンテンツがJSON形式であることを示すことで、「この形式で理解して処理してください」とお願いしているのと同じです。この指定がないと、司書は適切に対応できなかったり、意図と異なる形式で情報を渡してしまうかもしれません。

リクエストの本文は、司書に渡す依頼メモに例えられます。そこには、どんな本や情報が必要なのかを具体的に書きます。Gemini AIの仕様に従い、このメモも決められた形式で記述する必要があります。つまり、求める内容に加えて、各要素の具体的な文言や構成（セクション）まで明確に記述しなければなりません。たとえば「AIはどのように動作するのですか？」と書けば、司書は必要な情報を正確に理解できます。これにより、適切な情報が提供され、リクエストの意図が正しく伝わります。

このメモを文字配列に変換する処理は、図書館のシステムが理解できる形式に書き直すことに似ています。MQL5では、文字列をUTF-8エンコードされた配列に変換し、サーバーが正しく読み取れるようにします。これは、司書が情報をデジタルシステムに入力したりスキャンしたりする作業に近いイメージです。また、終端のヌル文字を取り除く処理は、メモに不要な記号や誤りが含まれていないことを確認する作業に相当します。

応答を受け取るための変数は、図書館で資料を受け取るためのトレイやメモ帳のようなものです。情報をどれくらい待てるかを司書に伝えることは、タイムアウトの設定に似ています。これは、司書にメモを渡して本を探してもらい、その間待つ状況に近いイメージです。メモの内容に不備があった場合などは、司書がエラーメッセージとして知らせてくれます。

文字配列として受け取った応答を文字列に戻す処理は、本を開いたり司書からのメッセージを読むことに例えられます。この変換によって、取得した情報を実際に理解し、活用できるようになります。こうして、リクエストを準備して送信し、処理を待ち、結果を読み取るという一連の流れは、図書館で資料を探して受け取るプロセスとよく似ています。

出力

サーバーデータからAI応答を抽出する

サーバーから返される応答には、AIが生成したテキストだけでなく、さまざまな付加情報も含まれています。たとえば、ヘッダーやメタデータ、使用されたモデル、リクエストに関する詳細情報などです。このセクションでは、そうした付加情報を取り除き、AIが生成した回答のみを抽出することに焦点を当てます。これにより、生成されたテキストをそのまま扱えるようになり、MQL5プログラム内での表示や処理、活用がよりシンプルになります。

例：

string pattern = "\"text\": ";
int pattern_lenght = StringFind(response_text,pattern);
pattern_lenght += StringLen(pattern);

int end = StringFind(response_text,"}",pattern_lenght + 1);
string ai_response = StringSubstr(response_text,pattern_lenght,end - pattern_lenght);

Print(ai_response);

出力

説明

まず、「text」という文字列をパターンとして指定します。これは、JSON応答内でAIが生成したテキストの直前に現れる識別子です。AIの出力はtextというフィールドに格納されているため、このパターンを使うことで、どこからAIの内容が始まるのかを特定できます。 その後、サーバーからの応答全体の中からこのパターンを見つけるための関数を使用します。この関数は、response_textを検索した後、そのパターンが始まる位置のインデックスを返します。このパターンの位置を示すために、そのインデックスは変数に保存されます。次に、そのインデックスにパターン自体の長さが加算されます。これにより、インデックスは「text:」の直後、つまりAIが生成したテキストの先頭へと移動します。この時点で、そのインデックスはAI応答の先頭を指します。

次の段階は、AIテキストの末尾を特定することです。開始インデックスの後に続く最初の閉じ中括弧}を取得するために、別の関数が使用されます。この位置が、JSON構造内のtextフィールドの終了地点を示します。開始位置と終了位置が確定したら、元のレスポンスから部分文字列を抽出します。これは、開始インデックスから終了インデックスまでの範囲を切り出す処理です。これにより、AIが生成したコンテンツのみを正確に取り出すことができます。 抽出されたテキストはai_responseという変数に格納され、Print関数を使って表示されます。この方法により、余分なメタデータやJSON構造をすべて除外し、サーバーから返された応答の中からAIが生成した内容だけを表示できます。

比喩的な説明

サーバーからの応答全体は、探している本のほかに、メモやしおり、領収書などの付属資料も一緒に入っている箱のようなものです。本当に必要なのは、その中にあるAIが生成したテキスト、つまり「本」そのものです。本の背表紙にあるラベルを見つけることは、「text」というパターンを特定する最初のステップに相当します。このラベルは、箱の中でどこから内容を読み始めるべきかを示しています。箱の中を一つひとつ確認しながらラベルを探す作業は、このパターンを見つけることに似ています。

次に、ラベルを見つけた後で開始位置を調整するのは、本の最初のページを開き、包装や余分な部分を取り除くようなものです。一方、閉じ中括弧の位置を見つける作業は、本の終わりを特定することに相当し、不要なメモや領収書が含まれるのを防ぎます。

開始位置と終了位置の間の部分文字列を抽出することは、箱の中から本だけを丁寧に取り出し、他の付属物から分離する作業に似ています。そして最後に、その内容を表示することは、本を取り出して読むイメージです。この時点で、箱の中に入っていた余計なものはすべて取り除かれ、必要なものだけが残っています。

抽出したAI応答を表示した後でも、テキスト全体が画面に収まらない場合があります。これはMetaTrader 5の[エキスパート]ウィンドウにおける表示文字数の制限によるものです。この制限を回避するために、AIの応答をテキストファイルとして保存します。こうすることで、後から評価して分析したり、再利用したりする際にも便利になります。また、表示制限に影響されることなく、全文を確実に確認できます。

例：

string filename = "AI_RESPONSE.txt";
int handle = FileOpen(filename, FILE_WRITE|FILE_TXT|FILE_SHARE_READ|FILE_ANSI);

if(handle != INVALID_HANDLE)
  {

   FileWrite(handle, ai_response);
   FileClose(handle);
   Print("EA successfully wrote the data to " + filename);
  }
else
  {
   Print("Error opening file for writing. Error code: ", + GetLastError());
  }

説明

最初のステップは、AI応答を保存するためのファイル名を選択することです。ファイル名を指定することで、テキストファイルの名前と、MetaTrader 5がそのファイルを保存する場所を決定できます。デフォルトでは、このファイルはターミナルのファイルディレクトリ内に保存されるため、後から簡単に見つけることができます。その後、ファイルは動作を制御するパラメータとともに開かれます。この設定により、他のプログラムからの同時アクセスが許可され、書き込みも有効になります。また、プレーンテキストとして扱われ、適切なテキストエンコーディングによって正しい可読性が保証されます。この処理の中で、ファイルを識別するためのハンドルが生成されます。

アプリケーションはまず、ファイルが正常に開かれたかどうかを確認します。正常に開かれている場合、AIの応答は1行ずつファイルへ書き込まれます。その後すぐにファイルを閉じることでリソースが解放され、すべてのデータが確実に保存されることが保証されます。データの書き込みが成功すると、その旨が[エキスパート]ウィンドウに表示されます。一方でファイルを開けなかった場合には、エラーメッセージとエラーコードが表示され、ファイル設定の誤りやアクセス権限の問題など、考えられる原因が提示されます。

比喩的な説明

この処理は、後で読み返すためのメモをノートに保存する作業に似ています。最初にファイル名を決めることは、新しいノートブックにタイトルを付けることと同じです。タイトルを見れば、そのノートに何が書かれているかを後からすぐに判断できます。ファイルを開く操作は、棚からノートを取り出して机の上で開くことに相当します。このノートは、開くときに設定されたルールに従って使われます。書き込みが許可されていれば内容を書き込むことができ、テキストノートとして指定すれば、イラストや特殊な記号の代わりに、シンプルな単語を書くことになります。

共有閲覧を許可するということは、自分がまだ書いている途中のノートを他の人にも見せることに似ています。テキスト形式を選択することで、そのノートを開いた人が誰でも入力内容を読めることが保証されます。ファイルが正常に開いたことを確認することは、ノートが開ける状態であり、ページが詰まっていたり、表紙が欠けていたりしないことを確認するのと似ています。ノートが問題なく開いたら、そのまま書き始めることができます。しかし、開かない場合は、閉じたままの本に書こうとするのではなく、立ち止まって何が問題だったのかを確認します。

 

結論

本記事では、MQL5を使用してMetaTrader 5をGoogle Generative AI APIに接続する方法を学びました。具体的には、APIのレート制限の理解から始まり、APIキーの生成、環境の準備、WebRequestを使用したリクエストの送信、正しいリクエストボディの構築、サーバーデータからAI応答のみを抽出する方法、そして最終的にその応答をテキストファイルに保存し、エキスパートウィンドウの表示制限を回避する方法までを扱いました。これらの一連の手順は、AI APIをMQL5プログラムに実用的に統合する方法を示しており、たとえばアシスタントや分析ツール、その他のスマート機能といった、従来の取引ロジックを超えたインテリジェントなツールを構築するための強固な基盤となります。