MQL5 Algo Forgeへの移行（第3回）：外部コードを自分のプロジェクトに統合する

はじめに

「MQL5 Algo Forgeへの移行（第2回）」では、複数のリポジトリを扱うという重要な課題に焦点を当てました。AdwizardライブラリプロジェクトとSimple Candlesエキスパートアドバイザー(EA)を組み合わせることで、主にファイルのインクルードパスやブランチのマージに関連する問題に直面しましたが、最終的には無事解決することができました。その過程では、可能な限りMetaEditorのツールを活用し、修正用の独立したブランチ作成からpull requestによるマージまで、一連のワークフローを実践しました。ただし、MetaEditorの機能だけでは対応しきれない場面もあり、その際にはMQL5 Algo Forgeのウェブインターフェース、Visual Studio Codeの外部Gitクライアント、あるいはGitコンソールコマンドを活用しました。これにより、個人開発であってもGitのベストプラクティスを適用し、プロジェクトの秩序と明確な変更履歴を維持できることを実証しました。

もっとも、これはあくまで「開発者自身が利用するすべてのリポジトリを所有している」という、いわば「閉じた」エコシステムとしてストレージを利用したにすぎません。次の論理的ステップ、そしてGitへ移行する大きな目的のひとつは、コミュニティの他のメンバーが公開しているリポジトリを積極的に活用できる点にあります。ここにこそ分散型開発の真の可能性があり、サードパーティのコードを容易に接続・更新し、改善に貢献し、信頼性の高い既存コンポーネントを組み合わせて複雑なプロジェクトを構築することが可能になります。 

本記事ではいよいよ、この有望ではあるものの、より複雑な課題に踏み込みます。すなわち、MQL5 Algo Forge内のサードパーティ製リポジトリからライブラリを実際に接続し、活用する方法を解説します。そしてそれは「いつか将来」ではなく、「今」すぐに実践できるのです。MetaEditorのリポジトリ機能の進化を待つ必要はありません。 

道筋の整理

本記事では、引き続きSimple Candlesプロジェクトのリポジトリを使用し、実験の場とします。既存の取引戦略には、標準のATR (Average True Range)インジケーターと機能的に類似したカスタムのボラティリティ計算がすでに組み込まれています。しかし今回は、独自実装のみに依存するのではなく、コミュニティから提供されている専門的かつ実用的なソリューションを取り入れることで、コードの改善を図ります。

具体的には、公開されているSmartATRリポジトリを利用します。このリポジトリには、より高度で最適化されたATRインジケーターの実装が含まれていると仮定します。長期的な実用目標としては、EAを改良し、内部計算を継続して使用するか、外部のSmartATRライブラリアルゴリズムに切り替えるかを選択できるようにすることです。ただし、本記事では完全なEAの構築には焦点を当てず、外部リポジトリを扱う際の重要なポイントを検証します。

そのために必要な手順は以下の通りです。まず、SmartATRライブラリのコードをローカルにダウンロードし、プロジェクトに組み込めるように設定します。次に、外部リポジトリを作業環境に追加し、将来的に新バージョンがリリースされた際に容易に更新できる方法を確認します。その後、Simple Candlesプロジェクトおよび（今回のケースでは必要となるため）SmartATRライブラリのコードに修正を加えます。理想的には外部リポジトリを変更せずに済ませたいところですが、今回は実践的な例として、他人のリポジトリに変更を加える手順も紹介します。最後に、SmartATRライブラリを正常にプロジェクトにインクルードし、コンパイルできるかどうかを検証します。

このアプローチにより、外部コードを統合する一連のプロセスを丁寧に確認することができます。この経験は汎用的であり、一度ライブラリの追加に成功すれば、同じ手法でMQL5 Algo Forgeの任意の公開リポジトリをプロジェクトに取り込むことが可能となります。

外部コードの取得

一見すると、これは問題にならないように思えます。どのGitリポジトリも、標準的なコンソールコマンドを使えばローカルコンピュータにクローンできます。

git clone ...

しかし、私たちは特定の順序を決めて進めることにしました。まずMetaEditorのインターフェースを試し、それがうまくいかない場合はMQL5 Algo Forgeのウェブインターフェースを使い、それでも難しければVisual Studio CodeやGitのコンソールコマンドといった外部ツールに頼る、という流れです。

最初の疑問は、MetaEditorで他人のリポジトリをどのように表示し、クローン対象として選択できるか、という点です。部分的な答えはヘルプドキュメントに記載されていますが、すぐに探し当てられるユーザーはほとんどいないでしょう。実際、私たちもそのページを見つけたのはずっと後のことでした。それまで、MetaEditorのShared Projectsフォルダには自分のリポジトリしか表示されないことに気づいていました。そこでさらに調べるため、MetaEditorのナビゲータでこのフォルダに対して利用できるコンテキストメニューのオプションを試してみました。 

[新しいプロジェクト]オプションはここでは適していません。これは自分が所有する新しいリポジトリを作成するだけだからです。[更新]も外部リポジトリを追加することはありません。[全てのファイルを表示]オプションは挙動が奇妙で、実行するとまだローカルにクローンされていないリポジトリの重複した名前が表示されました。幸いなことに、[更新]を押すとこれらの重複は消えます。最後の望みは[すべての公開プロジェクトを表示]オプションでしたが、これも目に見える変化は生みませんでした。

残念ながら、現時点ではMetaEditorだけに頼って外部リポジトリをクローンすることはできない、という結論に至ります。ここからは、目標を達成するための代替アプローチをいくつか検討していきます。

アプローチ1：直接クローニング

まずは実験から始めましょう。Shared Projects内に任意の名前（例：TestRepo）の空フォルダを作成すると、それがMetaEditorに表示されます。そこからコンテキストメニューを使ってCloneコマンドを実行することも可能です。しかしログを見ると、MetaEditorはその後、同じ名前(TestRepo)のリポジトリを自分の個人ストレージからクローンしようと試みます。当然ながら、そのようなリポジトリは存在しません。

これにより、この方法では他人のリポジトリをクローンすることはできないと確認できました。そこで代わりに、コンソールコマンド「git clone ...」を使ってShared Projectsに直接SmartATRリポジトリをクローンしてみることにします。

クローンが完了すると、Shared Projectsに新しいSmartATRフォルダが現れ、MetaEditorのナビゲータにも表示されます。さらに重要なのは、このリポジトリを単に表示できるだけでなく、リポジトリとして操作できる点です。具体的には、Pullを実行したり、変更履歴（ログ）をMetaEditorから直接確認できるようになります。

つまり、MetaEditorに現在欠けているのは、「Clone from…」のようなコンテキストメニューオプションです。これがあれば、ストレージ内のリポジトリURLを指定したり、MQL5 Algo Forgeのすべての公開リポジトリから検索・選択できるダイアログを開くことができます（ウェブインターフェースのExploreセクションに似た機能です）。別の改善案としては、Shared Projectsに個人リポジトリだけでなく、ウェブインターフェースでスターを付けた公開リポジトリ(Starred Repositories)も表示し、その可視性を切り替えられるようにする方法も考えられます。ただし、MetaEditorに将来どのような変更が導入されるかについて、ここで推測を広げすぎるのは避けましょう。

現時点に戻ると、無事にSmartATRリポジトリをクローンできたことで、当面の目標は達成できたと言えます。プロジェクトのソースコードがローカルで利用可能になったため、自分のプロジェクトに組み込むことが可能です。ただし、注意点があります。SmartATRのコードが修正を必要とせず、そのまま利用できる場合に限り、直接使用可能となります。つまり、新バージョンがリリースされた際に更新する以外、変更の必要がない「そのまま」使えるケースです。次に本当にそれが可能かどうかを確認してみましょう。

機能性のチェック

SmartATRプロジェクト内には、MetaTrader 5用インジケーターのソースコードが含まれたファイルがありました。説明によると、このコードはより高度な手法でATRを計算するものです。早速コンパイルしてみると、すぐにエラーが発生しました。 

エラーの深刻さに関わらず、重要なのは、このプロジェクトは修正を加えなければ利用できないという点です。この段階で決めなければならないのは、修正を自分のローカル環境だけで適用するのか、それとも共有して元のリポジトリに貢献するのかということです。他の開発者もこのコードを使おうとしたときに同じ問題に直面する可能性があるため、後者の選択肢の方が、オープンソース開発の理念に沿っています。

しかし今回は修正を公開しないものと仮定しましょう。まずはエラーを解決する必要があり、それをおこなって初めて公開に値するものが作れます。今回のケースでは、SmartATRプロジェクトにローカルでのみ修正を加える計画であれば、新しいローカルブランチを作成するだけで十分です。 

試してみましょう。元のSmartATRリポジトリにはmainブランチしか存在しないため、MetaEditorのプロジェクトフォルダのコンテキストメニューから新しいdevelopブランチを作成します。そのブランチはMetaEditorに表示されるブランチ一覧に追加されます。[Push]を押すと、ログには操作が成功したことが確認されます。この時点で、新しいブランチが元のリポジトリに作成されたと期待するかもしれません。しかし、MQL5 Algo Forgeのウェブインターフェースを確認すると、何も変化はありませんでした。

次にコードを編集し、MetaEditorからコミットしてみます。エラーを引き起こした各行の前に修正が必要であることを示すコメントを追加し、これをコミットします。MetaEditorのログでは、コミットとプッシュが成功したと表示されます。

ところが再び、MQL5 Algo Forgeのウェブインターフェースで元のリポジトリを確認すると、何も変わっていません。これは少なくとも不自然な挙動です。Visual Studio Codeでプロジェクトを確認し、何が起きているのか理解してみましょう。SmartATRプロジェクトのクローンを含むフォルダを開くと、次のような状況が見られます。

最新のコミットは存在しますが、VS Codeはdevelopブランチを公開するよう促しています。つまり、このブランチもコミットも、まだリモートリポジトリ上には存在していません。ブランチを公開しようとしましたが、エラーが発生しました。

ログを確認して理由を探します。

私たちのユーザーアカウントには元のリポジトリへの書き込み権限がありません。これは理にかなっています。そうでなければ、誰でも自由に編集できてしまい、プロジェクトが無秩序に陥ってしまうからです。つまり、変更はローカルコピーに加えることしかできません。これらの変更はリモートに同期されず、自分のローカルクローンにしか存在しないということです。これは望ましい状況ではありません。共同作業の手段としてだけでなく、外部リポジトリはプロジェクトのバックアップ保存庫としても非常に重要な役割を果たしています。その安全網を放棄するのは賢明ではありません

さらに指摘しておきたいのは、MetaEditorだけで作業している限り、何か問題があることを示す兆候がまったくなかったということです。MetaEditorのログ上ではすべてが正常に見え、エラーもなく、すべての変更が「成功裏に」プッシュされたと表示されていました。存在しないリポジトリに対してです。将来のビルドではこの問題が修正されることを願います。

アプローチ2：フォークのクローン

次に別の方法を試してみましょう。ここでもMetaEditorの現在の機能だけでは対応できないため、今回は追加でMQL5 Algo Forgeのウェブインターフェースを使用します。コマンドラインでのGit操作が難しいと感じる開発者にとって、これは一つの妥当な代替手段となります。MQL5 Algo Forgeのウェブインターフェースでは、目的の元リポジトリをフォークすることができます。 

フォークは、バージョン管理システムやMQL5 Algo Forgeを含む共同開発プラットフォームにおける基本概念です。これは、プラットフォーム内に元のリポジトリの完全で独立したコピーを作成するプロセスを指します。

ユーザーが他人のリポジトリをフォークすると、プラットフォームはそのユーザーのアカウント下に正確なコピーを作成します。このコピーは、フォーク時点でのソースプロジェクトのすべての変更履歴、ブランチ、ファイルを継承しますが、その瞬間からは自律したリポジトリとなります。新しい所有者はオリジナルに影響を与えることなく自由に修正を加えることができます。

したがって、フォークはあらゆるユーザーが既存のプロジェクトを基盤として自分の道に沿って開発を進めることを可能にし、コードの新たな進化の枝を実質的に生み出します。この概念により、オープンソースエコシステム内で派生プロジェクトや代替実装が生まれることになります。

フォークはまた、ユーザーに直接の書き込み権限がないプロジェクトに変更を貢献するための主要な手段でもあります。標準的なワークフローは、まずフォークを作成し、その中で必要な変更を実装してテストし、オリジナルリポジトリのメンテナーにpull requestを通じて改善提案を通知する、という流れです。この手順については第2部で既に扱いました。これこそが分散型共同開発モデルの基盤です。

独立性を持ちながらも、フォークは元のリポジトリとの技術的なリンクを保持します。これにより、オリジナルの変更を追跡し、自分のフォークに同期して、アップストリームプロジェクトからの新しいコミットを自分のフォークにマージすることが可能になります。

ここでフォークと単なるクローンを区別することが重要です。クローンは特定のコンピュータにリポジトリのローカルコピーを作成することを指しますが、フォークはプラットフォーム上での完全なコピーであり、別のユーザーの所有下に新しいリモートリポジトリを作成することになります。

したがって、リポジトリをフォークした時点で、それは自分自身のリポジトリとなります。そしてMetaEditorのShared Projectsリストに表示され、MetaEditorから直接クローンできるようになります。

フォークを使ったテスト作業

Fernando Carreiro氏のご厚意により、この仕組みを実際に試すことができました。彼のリポジトリFMICをフォークし、同時に元のリポジトリをMQL5 Algo ForgeのウェブインターフェースでWatchリストおよびStarredリストに追加しました。

予想どおり、MetaEditorの[Shared Projects]の下に表示されるリポジトリ一覧にフォークが表示されました。

これにより、作成したばかりのFMICリポジトリのフォークをローカルコンピュータに無事クローンできました。

次に、Fernando氏にいくつか変更をコミットしてもらい、その更新がフォークにどのように反映されるかをテストしました。彼は平均足の公開内容を説明するサンプルのREADME.mdファイルを追加し、リポジトリにコミットしました。

その後、ウェブインターフェース上で、新しい変更に関する通知を確かに確認できました。

しかし、これらの通知はまだMQL5 Algo Forge上にある私たちのフォークや、ローカルにあるクローンには反映されていません。そこで、Fernando氏の変更を自分たちのリポジトリにpullしてみます。まず、ローカルクローンに最新の変更が確かに反映されていないことを確認します。

ローカル履歴の最後のコミットは2025年8月27日付であり、Fernando氏の変更はそれ以降におこなわれています。

次に、ウェブインターフェースで自分たちのフォークを確認すると、mainブランチが元のリポジトリに比べて3コミット遅れているというメッセージが表示されます。

また、[Sync]ボタンが表示されており、これを使うと自分たちのmainフォルダをアップストリームブランチと同期できるはずです。その後、コミット履歴を確認すると、以前は存在しなかった2025年9月5日付の新しいコミットが3件追加されていることがわかります。

言い換えると、元のリポジトリでおこなわれたすべてのコミットは、まずMQL5 Algo Forge上の私たちのフォークに正しく反映され、その後そのフォークのローカルクローンにも反映されたことになります。

この仕組みをより詳しく理解したい方には、以下のGitHubドキュメントのセクションを参照することをおすすめします。 

• Fork a repository
• Configuring a remote repository
• Synchronize

これらのドキュメントはMQL5 Algo Forge向けに書かれたものではありませんが、ウェブインターフェースの挙動の多くは類似しており、コンソールGitコマンドはホスティングプラットフォームに関わらず普遍的に適用可能です。もちろん、プラットフォームがGitをベースとしている場合に限ります。

たとえば、アップストリームの設定ガイドラインに従うことで、PullやPushの操作のたびにフォーククローンを元のリポジトリと同期させる設定も可能です。

ただし、MetaEditorおよびMQL5 Algo Forgeのウェブインターフェースだけで作業する場合、この追加の設定手順は必ずしも必要ではありません。

SmartATRのフォーク

それでは、当初使用する予定だったリポジトリに戻ります。同じ手順を繰り返します。すなわち、MQL5 Algo Forgeのウェブインターフェースからフォークを作成し、SmartATRリポジトリをローカルにクローンします。

まず、Exploreセクションで元のリポジトリを名前で検索します。

リポジトリにはすでに他のユーザーが作成したフォークがいくつかあるため、検索結果にもそれらのフォークが表示されます。真のオリジナルをフォークするために、検索結果をさらに下にスクロールし、steverosenstock/SmartATRのページを開きます。

そこで[Fork]ボタンをクリックします。

クリックすると、フォーク作成の設定ページに移動します。ここでは、フォークしたリポジトリの名前（自分のリポジトリ一覧に表示される名前）の変更、元のリポジトリのどのブランチを含めるかの指定、リポジトリ説明の編集などがおこなえます。

デフォルトでは、フォークは元のリポジトリの正確なコピーとして作成されます。私たちはこれで十分なので、[Fork repository]をクリックします。

フォークは正常に作成されました。

次に、このリポジトリをローカルコンピュータにクローンします。その前に、以前にクローンした元のSmartATRフォルダをローカルから削除します。MetaEditorがすでに開いている場合は、Shared Projectsのコンテキストメニューから[更新]を選択して、フォルダリストを更新する必要があります。その後、SmartATRフォルダが表示されます。コンテキストメニューから[Git Clone]を選択します。 

SmartATRプロジェクトは正常にクローンされました。

これで、変更作業を開始する準備が整いました。

変更の追加

今回の目的は、特定のエラーを解決するか、少なくとも中和する修正を導入することです。まず、この目的が明確に分かる名前の新しいブランチを作成します。たとえば、fixes/news-impactとします。

次に、プロジェクトのコンテキストメニューから[Git Branches] → [fixes-news-impact]を選択して、このブランチに切り替えます。

なお、元々ブランチ名にスラッシュ(/)を含めましたが、実際にはMetaEditorによって自動的にハイフン(-)に置き換えられて作成されます。これはMetaEditorの制限で、ブランチ名にはラテン文字とハイフンのみが許可されます。技術的にはGit自体はスラッシュを許容しており、ウェブインターフェースを通じてスラッシュを含むブランチを自由に作成することも可能です。 

この制限の影響を確認してみましょう。今回はMQL5 Algo Forgeのウェブインターフェースで直接別のブランチを作成し、明示的にスラッシュを含む名前(fixes/cast-warning)を付けます。Branchesページで[New branch]を選び、mainブランチをベースにします。

ブランチが正常に作成されました。

しかし、MetaEditorでPullを実行しようとすると、エラーメッセージが表示されます。

それでも、スラッシュを含む新しいブランチはMetaEditorのブランチ一覧に表示され、切り替えも問題なくおこなうことができます。

この特性を確認した後、再びfixes-news-impactブランチに切り替え、コンパイルエラーの原因を取り除く一時的な修正を導入します。

インジケーターがエラーなくコンパイルできるようになったら、コンテキストメニューの[Git Commit]を使って変更をコミットします。 

Commitダイアログでは、変更されたファイルの一覧を確認します。今回は変更が1ファイルのみなのでチェックは簡単です。修正内容を説明するコメントを追加することが強く推奨されます。すべて確認したら[OK]を押します。

これで変更がコミットされ、MQL5 Algo Forge上のSmartATRリポジトリのフォークにプッシュされます。この時点で、修正済みのインジケーターはローカルで使用可能であり、リポジトリには安全なコピーも保存されています。必要に応じて、ウェブインターフェースの[New pull request]を押して元のプロジェクト作者にPull Requestを提出することも可能です。

ただし、今回はコードを改善したわけではなく、一部の機能を無効化しただけなので、Pull Requestを作成するのは時期尚早です。

これでSmartATRインジケーターをSimple Candlesプロジェクトに統合する準備が整いました。

インジケーターの統合

ベストプラクティスに従い、Simple Candlesプロジェクトリポジトリのdevelopブランチを基に、新しいブランチarticle-19436-forge3を作成します。アプローチに変化を持たせるため、このブランチはMQL5 Algo Forgeのウェブインターフェースを使用して作成します。

ブランチをローカルに反映させるため、MetaEditorで「Git Pull」を実行し、新しいブランチarticle-19436-forge3に切り替えます。

今回の目的はインジケーターを取引戦略に組み込むことなので、SimpleCandlesStrategy.mqhの戦略クラス実装内に直接追加します。具体的には、インジケーターのハンドルを保持するためのクラスフィールドを導入します。

//+------------------------------------------------------------------+
//| Trading strategy using unidirectional candlesticks               |
//+------------------------------------------------------------------+
class CSimpleCandlesStrategy : public CVirtualStrategy {
protected:
   //...

   int               m_iATRHandle;        // SmartATR indicator handle

   //...
};

次に、クラスのコンストラクタ内でiCustom()を呼び出し、必要な銘柄、時間足、インジケーターファイルへのパス、およびパラメータを渡します。

//+------------------------------------------------------------------+
//| Constructor                                                      |
//+------------------------------------------------------------------+
CSimpleCandlesStrategy::CSimpleCandlesStrategy(string p_params) {
// Read the parameters from the initialization string
   // ...

   if(IsValid()) {
      // Load the SmartATR indicator
      m_iATRHandle = iCustom(
                        m_symbol, m_timeframe,
                        "Shared Projects/SmartATR/SmartATR.ex5",
                        // Indicator parameters
                        m_periodATR,   // Initial ATR period (used for first calculation, adaptively changes)
                        false,         // Enable adaptive period (dynamic lookback)
                        7,             // Minimum ATR period (adaptive mode)
                        28,            // Maximum ATR period (adaptive mode)
                        false,         // Weight True Range by volume
                        false,         // Weight True Range by economic news events (MT5 Calendar)
                        2.0,           // Multiplier: alert if ATR exceeds this factor of average
                        false          // Enable pop-up & sound alerts on high volatility
                     );

      // ...
   }
}

インジケーターのパスに注意してください。Shared Projectsから始まり、プロジェクトフォルダ名SmartATR、続いてインジケーターファイル名SmartATR.ex5と指定します。.ex5拡張子の記載は任意ですが、記載しておくと混乱を避けやすくなります。

Shared Projectsフォルダで作業する際には、重要な点があります。これは自分のプロジェクトだけでなく、フォークしたプロジェクトにも当てはまります。コンパイル済みの実行ファイルは、リポジトリフォルダに直接置かれるわけではありません。Shared Projectsフォルダはターミナルのデータルートフォルダ、すなわちMQL5/Shared Projectsに存在するためです。一方で、これは利点でもあります。バージョン管理システムが実行ファイルをインデックスしようとしないからです。しかし、最初は少し混乱するかもしれません。では、コンパイルされたエキスパートアドバイザーやインジケーターのファイルはどこに置かれるのでしょうか。

実際には、それぞれの標準フォルダ内に作成されます。EAであればMQL5/Experts、インジケーターであればMQL5/Indicatorsです。その中に自動的にShared Projectsサブディレクトリが生成されます。つまり、コンパイル済みファイルはそのサブフォルダ内に生成されます。たとえば、MQL5/Shared Projects/SmartATR.mq5をコンパイルすると、実行ファイルはMQL5/Indicators/Shared Projects/SmartATR/SmartATR.ex5に生成されます。

したがって、iCustom()を呼び出す際には、MQL5/Indicatorsを基準とした相対パスでインジケーターを指定する必要があります。

最後に、アドバイザーファイルSimpleCandles.mq5をコンパイルし、ストラテジーテスターで実行します。ログには以下の内容が表示されます。

このようにして、SmartATRインジケーターは正常にロードおよび初期化され、使用可能な状態になりました。現時点では統合のデモを示しているに過ぎません。必要に応じて後で戦略ロジック内で実際に使用することも可能です。これらの変更をコミットし、MQL5 Algo Forgeリポジトリにプッシュします。

結論

本記事では、MQL5 Algo Forgeを活用することで、開発者にとって根本的に柔軟なワークフローが可能になることを示しました。これまで私たちは自己完結型のリポジトリのみを扱ってきましたが、今回は外部のサードパーティリポジトリからライブラリをプロジェクトに統合することに成功しました。

重要なポイントは、フォークを活用した正しいワークフローです。外部リポジトリの個人用コピーを作成することで、自由に修正を加えつつ、アップストリームプロジェクトとの同期も維持できます。SmartATRをSimple Candlesに統合できたことは、このアプローチの有効性を裏付けています。リポジトリの検索とフォーク、コードの修正、そしてライブの取引戦略への適用まで、一連の流れがスムーズにおこなうことができました。

重要なのは、このプロセスがすべて現在のMetaEditorの機能だけで達成できた点です。将来のアップデートを待つ必要はありません。MetaEditorの制約（サードパーティリポジトリへの直接アクセス不可やブランチ名の制限など）は、MQL5 Algo Forgeウェブインターフェースや必要に応じて標準的なGitコンソールコマンドを補助的に使うことで簡単に克服できます。要するに、システムはすでに実用的に利用可能であり、残るインターフェースの不便さは障害ではなく、単なる煩わしさにすぎません。

しかし、ここで止まるわけではありません。今後もリポジトリを活用してプロジェクトを分離し、これまでに得た共有経験をさらに積み重ねていきます。

ご精読ありがとうございました。またすぐにお会いしましょう。