TOKYO BLOCKCHAIN TECH MEETUP 2022 Part-1

7月12日に開催された「TOKYO BLOCKCHAIN TECH MEETUP 2022」の“ブロックチェーンエンジニア勉強会”について3部に分けてレポートします。

満足亮（まんぞくりょう）氏
double jump.tokyo株式会社 CTO
ソーシャルゲーム会社、EdTechアプリ会社でインフラ、SRE領域を統括した後、2018年6月に入社。2020年7月より現職に。インフラ設計運用、サーバーサイド開発、スマートコントラクト開発、ブロックチェーン技術調査を担当している。

及川駿（おいかわしゅん）氏
InsureDAO Core Developer

谷口英（たにぐちあきら）氏
Digital Entertainment Asset Pte. Ltd. R&D Tech Lead
大阪芸大からなぜかエンジニアの道へ進む。
HRパッケージやレコメンドエンジンの結果計測バックエンド、暗号資産取引所、DeFiなどの実装、運用に携わり、今はGameFiに奮闘中。

佐藤基起（さとうもとき）氏
シビラ株式会社執行役員兼エンジニア
大阪大学及び大阪大学大学院にて機械工学を専攻、卒業後、面白法人カヤックに入社し、ゲーム事業部のチーフエンジニアと所属プロジェクトのリードエンジニアを兼任、2016 年に SIVIRA へ入社し、rollup の前身である Plasma をはじめとした cryptoeconomics に関する R&D を経て、現在は account abstraction を見据えたコントラクトウォレットの設計・開発に取り組む。

1 Web3黎明期にエンジニアに求められること
2 Token Bridge 実装
3 オレオレ Meta Transactionのすゝめ
4 Account Abstraction の今：ERC4337 概要

Web3黎明期にエンジニアに求められること

満足氏：『TOKYO BLOCKCHAIN TECH MEETUP』ということで、久し振りにリアル会場でイベントが開催できました。オンラインの皆様もご覧いただきまして、ありがとうございます。

僕の顔をご存じの方は、2018年ぐらいからブロックチェーンに携わっている方もいらっしゃるかと思いますが、それよりもやはり2021年に大きなNFTやブロックチェーンのブームが来て、エンジニアの数がとても増えたと思います。

本日は私を含め10名の発表ですが、皆さん2018年以前からブロックチェーンに携わっている1線級のエンジニアの方々です。貴重な話を聞けると思いますので、ぜひ最後まで聞いていただければと思います。

まず初めに私はdouble jump.tokyo のCTOをやっております、満足です。『Web3黎明期にエンジニアに求められること』というタイトルで発表させていただきます。よろしくお願いします。

double jump.tokyoは2018年4月創業の会社で、メイン事業はブロックチェーンゲームの開発や運用を行っております。弊社では2018年からNFTに関連した事業をやっていることもあり、NFTの設計や発行、販売やコンサルティングも行っております。

『Re-building the future of gaming with blockchain technology!』つまり、“ブロックチェーンテクノロジーを使ってゲームの未来を再構築すること”をビジョンに掲げております。このように、2018年からブロックチェーンゲームをやっており、『My Crypto Heroes』という、（現在は『My Crypto Heroes』を運営する専門会社に移管済み）、比較的初期からゲームタイトルを作っておりました。double jump.tokyo発のパブリッシングとしては3タイトルあります。昨年よりNFTのお手伝いをさせていただく機会も増え、スクウェア・エニックスさんの『資産性ミリオンアーサー』や、手塚治虫先生のNFT、武田双雲先生の書道のNFTもプロデュースさせていただいております。他にはN Suiteという秘密鍵管理のSaaSを作ったり、最近discord-botというものを作ってNYATというものを用意しています。

「IVS2022 NAHA」（沖縄開催）で盛り上がっていたOasysにも関わっております。Oasys自体はシンガポールの会社でファウンデーションがあるのですが、そちらの開発のリードをdouble jumpで行っております。また、2022年7月11日に発表したばかりなのですが、Oasysというブロックチェーンのレイヤー2として、『HOME verse』というものをdouble jumpで行っています。ここでブロックチェーンのL2を自分たちで運用して、その上でゲームを作って出していくことを始めております。

あとはWeb3スタートアップの支援を行ったり、CVCの事業を行っています。Web3というワードが流行っていると思うのですが、ブロックチェーンに携わっている人は増えてきていてもWeb3までがっつり携わっているという方は少ないのではないかと思います。

一方で、Web3とは何なのかという議論もいろいろありますよね。僕も定義が難しいと思っているのですが、Googleトレンドでも、今年の前半ぐらいから少しずつ上位表示されており、直近の日本国内での人気動向を見ると、4、5月位から一気に来ていることが分かります。

どのような定義があるのかは人それぞれだと思うのですが、よく言われる話としてはWeb1というのが基本的にRead。ユーザーにとってはただ読むだけのメディアでした。Web2というのはReadに加えてWrite。Facebookなどもそうですが、ユーザーが何かしらの投稿・発信をできるようになりました。Web3の思想というのは、Own等で表現されることが多いと思っているのですが、これまでFacebookに投稿した文章は、Facebook上で管理されているものなのですが、Web3時代では“その文章を自分の管理下に置こう”というのが、よく言われる切り口なのかなと思います。

Web1時代はMicrosoftやIBMのような企業が強かった印象があります。Web2時代はGAFAやGAFAMが強かったという印象がありますが、Web3の時代は、いわゆる巨人と呼ばれているような存在の企業はまだ出てきていない状態だと思います。

仮にWeb3にブロックチェーンは不可欠だろうということにしてみましょう。そうすると、Web3にブロックチェーンが不可欠というのはどういうことかというと、プログラマブルなお金と資産を扱うことができるところだと思います。それを根幹にするWeb3というものに関しては、ビジネスの根幹にも当然プログラムが必要になってきますよねと、言えるのではないでしょうか。エンジニアの需要はWeb2時代でも高かったのですが、Web3ではさらに高くなるだろうと言われています。

実際に私が業務をやっている上では、法律や会計、税務や市場の理解、ドメイン知識や業界動向、さらにプログラミング能力が求められています。皆さんはすでにプログラミングという武器を持っていると思います。黎明期の市場においてエンジニアの資質である物事の理解度、問題解決能力はもちろん必要ですが、Web3時代においてはプログラミング以外の領域も武器にできればもっと活躍できると思います。これは私自身がすごく感じている部分であり、プログラムを書いている時間よりも法律を調べている時間のほうが長い状況が起きていることもあります。皆さんもプログラミングだけではなく、いろいろな領域に手を出してみてもらえればさらに活躍の場が拡がるのではと思います。

また、どうすれば業務でブロックチェーンに関われるのかについて、ブロックチェーンのエンジニアといってもいろいろ領域があります。ユーザーがいたところにCentralized Exchangeがあって、Webのページを作らなくてはいけない、ウォレットを作らなくてはいけない、ブロックチェーンノードがあってスマートコントラクトがあって、あとは自分たちのサービスのバックエンドを作らなくてはいけないとか、Web2ナイズされたSaaSと言っていますが、ブロックチェーンに直接つなぐのではなくて、何かしらプロキシとなるAPIを作ることが必要になると思います。

登壇される皆さんの内容ですが、もちろんCentralized Exchangeの発表もあります。ウォレットの部分やブロックチェーンノードの話、スマートコントラクトが多めにはなりますが、Web2ナイズされたSaaSの話などがこのあと聞けると思います。ということでdouble jump.tokyoとしてはWeb3時代を切り開くメンバーを募集しておりますので、よろしくお願いします。ありがとうございました。

Token Bridge 実装

及川氏：こんにちは。初めまして及川駿と申します。僕はスマートコントラクト周りの開発を行っています。最初に自己紹介をします。

今、InsureDAOというプロトコルのCore Devをやっています。InsureDAOというのはDeFiの保険でして、ユーザーがDeFi投資をしていく中で、予測しづらい唐突に起こり得るハッキングに対してのリスクヘッジ手段などを提供しています。最近ではガス代（手数料）高騰の問題も解決されつつある中で、より金融チックな保険、例えばオプション周りを組み合わせてDeFiの投資ヘッジなどへの商品開発に注力しています。

今日はBridgeについてお話したいと思います。Bridgeというのは、まず簡単に言うとチェーン間の情報伝達手段というものです。よくあるものとしてトークンBridgeが一番馴染み深いと思います。例えばビットコイン上にBTCを持っていて、これがイーサリアム上でwBTCとして担保として使える。これはBridgeがあるからこそできることであって、今のDeFiのエコシステムにおける根幹を担うものになっています。今日はトークンBridgeがスマートコントラクトレベルでどう動いているのか、プロトコルは実際にどう実装してインテグレーションしているかなどを簡単にお話したいと思います。

これがよくあるBridgeのアーキテクチャ図ですが、下がL1で上がAlternativeチェーン(L2)とします。L1からL2に送りたい人は、トークンをBridgerのコントラクトにdepositします。そうするとBridgerが勝手にそれを認識し「分かった」ということでL2に対応するトークンをそのユーザーに対してMintします。そして、L2からL1にwithdrawする時は全く逆になります。L2上でトークンをBurnして、それをBridgerが把握して「分かった」ということでL1にロックされているトークンをユーザーに開放するという流れです。Bridgeと言っていますがトークンがチェーンをまたぐというわけではなくて、単純にMintとBurnで成り立っているというのがよくあるトークンBridgeになっております。

実装も非常にシンプルで、これが実際のものになります。L1がGoerliテストネット（イーサリアムのテストネット）で、上がPolygonのMumbaiです。シンプルにPolygonが要求するERC20の規格というものを実装してあげて、Mumbai上にデプロイしてあげます。それをL1トークンのアドレスとMumbai上のアドレスをPolygonのBridgerにマッピングしてくれと依頼を出すと、Polygon側がマニュアルでチェックしてマッピングしてくれて、それでBridgeの経路が完成という形になっているのでとてもシンプルです。

ですが、これをプロダクトレベルで実際にUniswapや、いろいろ他のプロトコルがマルチチェーン展開したいとなったときに問題があります。一番の問題点はこれらに共通規格がないという点で、非常にやりづらくしています。現在、Bridgeは60種類以上あるらしいのですが、例えばCanonical Bridgeといってチェーンが公式に推しているBridgeですね。次に、Arbitrumだと例えばArbitrum上にBridgeしたい場合、そのERC20は『BridgeMint(address_to,uint256_amount)』、これを書けと言われます。Polygonであればdeposit。引数はaddressとbytesを持てと言われます。よくあるHOPやcBridge、サードパーティ系のいろいろなチェーンに展開するようなBridgeプロバイダーであれば、また違っていてMint。わりとこちらはERC20に近いですが、『mint(address_to,uint256_amount)』を持てと言われる形となっています。

やはりプロダクトとしては、どれか1つのBridgeに頼り切りたくないというところで柔軟に複数Bridgeの対応に迫られることになります。しかし、僕自身もリサーチしてMumbaiとGoerliを見つけたのですが、ArbitrumもPolygonもcBridgeも、どれもテスト環境やドキュメントがまだまだ不足していて、その場でリサーチを進めながら自分で開発しなくてはいけない状況になっています。

InsureDAOには、DevアドバイザーでWatch Bugというauditorがいますが、彼らは他プロジェクトも見ています。Gelatoというプロトコルがありまして、マルチチェーン展開をしていますが、彼らもテストインプロットではないですが、Bridgeに対してこれからデプロイするよというコントラクトを見せてOKを貰ったら、そこからメインネットでデプロイして試す状態になっています。

というところで、マルチチェーン時代になってから時間が経ちましたが、まだまだこの辺りの開発者には模索が必要だと思います。そういった中で、今まさにこれから開発するという段階ですが、良い答えになりそうなものがあったので、簡単に紹介できればと思います。

個人的にERC20のUpgradeableは好きではないので、Bridgeのwrapperを置いてあげて、それをトークンに結びつけてどんな関数を要求されても、それをMintに変換してトークンに叩きます。トークン側からはbridge wrapperをホワイトリスト制、つまりMint許可してあげるところがいいのかもしれないと思っています。

しかし、これの問題点として、自分で独自改変を加えてしまうので、さっきもGoerliでやったようなBridgerに対して依頼を出すときにマニュアルの精査をされます。そこで認証されるかまだ分からないという状況になっています。ですので、やったことがある人はぜひ教えてほしいと思います。

最後に、自分がさっきGoerli、Mumbaiでやったレポジトリーのリンク集があるので、ぜひ見てください。ありがとうございました。

【参考URL】
シンプル実装：https://github.com/oishun1112/goeri-mumbai
Multi-bridge ：https://blog.celer.network/2021/12/13/say-no-to-vendor-lock-in-calling-for-an-open-canonical-token-bridge-standard/
https://github.com/celer-network/sgn-v2-contracts/blob/main/contracts/pegged-bridge/tokens/MultiBridgeToken.sol

オレオレ Meta Transactionのすゝめ

谷口氏：お疲れ様です。谷口といいます。簡単な経歴をお話しすると、Zaifという交換業者で働いていました。その後、Dev ProtocolというDeFiを作って、今GameFiに関わっています。Digital Entertainment Assetというところでブロックチェーンエンジニア大募集しているので、GameFi作りたい人はよろしくお願いします。

それでは本題です。Meta Transactionとは何ですか？ということですが、Dappのユーザーがガス代を支払うことなく、トランザクションを発生させる仕組みになります。UXが重要なアプリケーションで、必須のアーキテクチャです。

よく比較されるのがMeta Transactionとガス0設定のAvalanche Subnets。
それぞれメリットデメリットがあります。
Meta Transactionはいろいろなチェーンで使えることや、Avalancheのように2000AVAXを購入してバリデータを運用しなくてもいいです。
ガス0設定のAvalanche Subnetsは、運営側もガス代を払わなくていいです。あとコントラクトに専用ロジックを実装する必要がないです。どちらを使うかは自分の好みで選んでください。

次に、Meta Transactionは4種類あります。
まず『Account Contract Based』で、ユーザーがコンタクトウォレットを使ってトランザクションを発生させる前提のMeta Transactionで、まだそんな時代ではないので、少し早いのではと思っています。
次に『Singleton Proxy』で、Meta Transactionのコアロジックが1つのコントラクトに集約されていて、実装がシンプルなところがいいと思います。
『Token Proxy』は、Meta TransactionのロジックがトークンERC20のコントラクトに書いてあるのですが、用途が限定されるのと、ERC20にいろいろなロジックが入っていたら取引所はあまり好まない可能性があるので、個人的にはよくないのかなと思います。
最後に『No Proxy』というやり方もあります。全部のコントラクトにMeta Transactionのやり方、ロジックが載っています。でも運用コストが高いというデメリットがあります。ですので、僕は『Singleton Proxy』を選択しました。

GitHub^※1があるので、そこで全てのソースを公開しています。細かいところはREADMEを読んでみてください。

次は全体図です。Webブラウザからゲームをやるという前提で描いています。ユーザーがMetaMaskで署名したあと、APIはサーバーにリクエストを飛ばして、そのタイミングでコントラクトをキックします。Forwarderとありますが、これがMeta Transactionを発生させるコントラクトです。このタイミングでガス代が発生します。Forwarder経由でコントラクトが実行されて、あたかもこのユーザーが持っているトークンをガス代なしで他の人に渡すことができるみたいなものが全体の流れです。今回作ったところがForwarderと例で言うとERC20に継承されたコントラクト、この2つになります。

処理の流れをテストケースで説明していきます。まずethersのInterfaceの中に関数のエンコード情報を作る必要がある^※2のでそれを作って、本当に細かいですがmessageという構造体を作る必要があります^※3。 fromというのはこの人が実行したという感じで進めたい人のアドレスで、toが実行したいコントラクトのアドレスです。valueが送りたいETHの量で、gasが使用したいgasの量、nonceというのは処理順で、dataはさっき作ってエンコードした関数の情報を入れて、これで構造体を作ります。

さらにそこでEIP712という形式を作って、構造体を作ったあと、最後に秘密鍵で署名^※4してコントラクトのexecute関数を先程のパラメータとsignatureを使って実行^※5すると、あたかもその人がやったかのようなトランザクションができます。

次はコントラクトの中身です。さっき言ったForwaderの話です。元になるネタがあります。MinimalForwarder^※6というのがOpenZeppelinにありまして、Minimalなので機能を追加する必要があります。Forwaderにパラメータがありますが、こんな感じでEIP1776というMeta TransactionのEIP^※7があり、それを参考にして期限を設定しました。

これ^※8が実行するexecuteというMeta Transactionを実行する関数ですが、Minimalの方は実行権限とかリエントランシー対策などが全く無かったので、それも追加しました。さらにEIP1776を参考にして、1つのトランザクションで複数のコントラクトをキックするbatchの仕組み^※9も作りました。

その他細かなところで言うと、緊急時に停止できるpauseの関数、低レベルのAPIでキックしたあとのイベント作成部分を追加しました。

先程のverifyですが、EIP712で処理してチェックするようにしています。
EIP712というのは何かという話ですが、データ署名の標準仕様です。楕円曲線上の離散対数問題と呼ばれる数学上の問題を安全性の根拠とするデジタル署名方式のECDSAを使っています。ここもOpenZeppelinのdraftですが、EIP712がある^※10ので興味があれば見てください。

次にMeta Transactionされる側のコントラクトにも処理するための特定のロジックが必要になっています。今回で言うとERC20です。これも元ネタがあって、OpenZeppelinのERC2771Context^※11というものがあります。これはMeta Transactionの受信側の標準規格です。具体的に何かというと、Meta Transactionを発生させるコントラクトが実行された場合、実行元のsenderに「ここからデータを取ってこい」という規格があるのです。

これをすることでいい感じにMeta Transactionが発生できますが、今回作り直しました^※12。なぜかというと、機能が少し足りなくてupgradeableのライブラリの中のなぜかconstructorが実装されていることや、Forwaderが1つである前提で細かいところをカバーできないので、それらを実装しなおして先程のGitHubに作りました。

次に問題点を説明します。EIP4337完全無視というところです。これが発表タイトルのオレオレの由来です。EIP4337とは何かというと、Meta Transactionの標準規格化などいろいろやっているものです。それについて次の佐藤さんが説明してくれるそうです。

Account Abstraction の今：ERC4337 概要

佐藤氏：それでは『Account Abstraction の今：ERC4337 概要』というタイトルで発表させていただきます。簡単に自己紹介します。SIVIRAという会社で執行役員兼エンジニアをやっているm0t0k1ch1（もときち）といいます。

今本業で取り組んでいることは、unWalletというコントラクトウォレットの設計開発です。今日お話しするAccount Abstractionというトピックもこのコントラクトウォレットと非常に関連が深い話になっています。

今日お話しする内容は、真剣にやろうと思うととてもボリューミーです。詳細は昨年自分がEthereum Advent Calendarで書いた『Account Abstractionの先にある、コントラクトウォレット中心の世界』にまとめているので、この導入部分に相当するお話をしたいと思います。

ただ記事が有識者の方でも腹筋を要する内容になっているようなので、本当に導入というところをサポートする内容をお伝えできればと思います。

まずERC4337のお話に入る前に、その目的であるAccount Abstractionというものが何なのかというところを簡単に説明します。Account Abstractionはなかなか聞き慣れない言葉だと思います。ですが、数年にわたって議論されている非常に重要なトピックです。

昨年最新の提案であるERC4337が発表されたのですが、そのときにVitalik氏が同時に出した解説記事の冒頭で「Account AbstractionはEthereumディベロッパーコミュニティの長年の夢だ」というような表現がされています。

実際Account Abstractionは2016年頃から議論が始まっていて、Vitalik氏自身が1st authorとしてEIPを3つ出しながら、実現可能性が高い提案にどんどん改善し続けているというトピックになります。Vitalik氏が自分のリソースを割いて推進しようと取り組んでいる、それくらい重要なトピックだと思っておいてください。

Account Abstractionとは何かという話ですが、tx 正当性検証とtx 手数料支払い、この2つを抽象化する取り組みだと思っていただければ良いと思います。それぞれ簡単にどういうことなのかを説明します。

tx正当性検証に関しては皆さんご存じのとおり、Account Abstraction前である現在は、正当なトランザクションを作るには、EOAによるECDSA電子署名が必要です。これがAbstractionされると正当なトランザクションの定義というのはアカウントごとに自由に設定できるようになります。

例えば、楕円曲線暗号ではなくて、量子耐性のあるような暗号技術に基づいた検証ロジックを入れたり、ここに書いてあるようにFIDOなどの生体認証ベースの認証技術と連携させた検証ロジックを入れたりすることで、セキュリティやユーザビリティを上げることに繋がります。

トランザクション手数料支払いに関しては、こちらも皆さんご存じの通り、現状は基本的に支払いはETH1択になっていますが、Abstractionされるとトランザクション手数料の支払い方法もアカウントごとに自由に設定できるようになります。例えば「自分の好きなERC20トークンで払いたい」、「NFTで払いたい」であったり、先程の谷口さんの話の中にありました「他の人に払ってもらう」といったことが可能となり、柔軟に融通が利くようになるので、活用するとクリプトのオンボーディングのハードルを下げることができたりします。
改めて、Account Abstractionというのは、これら2つを抽象化した土台のプロトコルを作ることで、セキュリティやユーザビリティを向上させようという取り組みになります。

本題のERC4337に行きます。中身がどうかというよりも、どういう方向性の提案なのかというところがまず重要です。まずERC4337がERCであるということが非常に重要です。

どういうことかというと、これ以前のAccount Abstractionに関する提案は、EIPのカテゴリーがCoreになっていて、すなわちL1プロトコルレイヤーの改修が必要なカテゴリーだったのですが、そうなってしまうと、現状イーサリアムの開発というのは基本的にイーサリアム2.0関連で手一杯で他のものに取り組む余裕がないので、Account Abstractionするのに時間がかかってしまいます。ですがそれを待っていられないとなったときに、昨年出たERC4337というのは、L1プロトコルレイヤーの改修を必要としないような形式でAccount Abstractionができないかということを考えて着地させたので、カテゴリーがERCになっていて、ERC4337と呼ばれています。これは1つ重要なポイントなので覚えておいてください。

ERC4337の中身はあまり重要ではないですが、L1.5みたいなイメージで捉えてもらうといいのかなと思います。もう少し言葉がわかる人は「L1 meta Transactionの（広義の）rollup」というようなイメージを持っていただくと、これから資料を読んでいただくときに理解がしやすいかと思います。

Vitalik氏のブログによくこの図が載っているので、これに少し手を加えて軽く説明をします。今まで我々ユーザーというこの図で1番右上にいる人たちというのは、L1Transactionの海に直接Transactionを突っ込んできました。しかしERC4337以降の世界ではそうではなくて、Transactionの代わりにUserOperationというほとんどTransactionと同じデータ構造を持ったobjectを、海の1個上のレイヤーにUserOperation mempoolという今のL1のTransaction mempoolと同じようなmempoolを作って、そこに投げます。そして、今のL1のマイナーがやっているのと同じようなことをもう1個上のレイヤーでBundlerというステークホルダーを作って、行います。つまり、BundlerがUserOperationをうまくまとめてL1にMeta Transactionとして流します。これをBundle Transactionと言います。こういう仕組みをやるとAccount AbstractionがL1プロトコルレイヤーの改修なしで実現できますという提案になっています。

先程の2つのこと（tx 正当性検証とtx 手数料支払い）がプロトコルレイヤーで今まで縛られていましたが、これが実現するとコントラクトレイヤーでカスタマイズできるようになります。ですので、スマコンデベロッパーの仕事が増えます。もっと詳しい話が知りたい方は最初に紹介した『Account Abstractionの先にある、コントラクトウォレット中心の世界』の記事を読んでみてください。もっとホットな情報が知りたい方は、つい最近Vitalik氏が具体的な課題や短期中期長期のロードマップを出していますので、そちらを読んでみてください。

最後に弊社の取り組みを紹介します。今紹介させていただいたAccount Abstractionの先にある世界に向けて、unWalletというコントラクトウォレットで下剋上を頑張っています。下剋上の対象はもちろんMetaMaskです。今日はunWallet PassというFull-on-chain NFTを無料でMintできる状態にして持ってきています。これを持っている方はunWallet上であったり、弊社の今後の取り組みの中でいろいろユーティリティを提供させていただこうと思っているので「応援したい」という方がいらっしゃいましたら、是非お話しましょう。ご清聴ありがとうございました。

【参考URL】
登壇資料：https://drive.google.com/file/d/12MJVIJFYaCWBOB0JUXTNhhTMAryCZYbt/view
『Account Abstractionの先にある、コントラクトウォレット中心の世界』:
https://zenn.dev/sivira/articles/d041f1ac44ca1e
Vitalik氏の資料：https://notes.ethereum.org/@vbuterin/account_abstraction_roadmapunWallet: Contract Design：https://sivira.co/assets/pdf/unWallet_Contract_Design.pdf

Web掲載のない非公開求人もございます。詳細は以下の転職相談よりお問い合わせください。

転職相談する