Blog

ブログ

ラズパイ で電子ロッカーを作る！(IoTネットワーク構成編)

aws 技術

今回の記事を担当するエンジニアの榎本です。
これまでの記事

・電子ロッカー開発始めます　→　電子ロッカー開発に至った経緯など
・ラズパイ で電子ロッカーを作る！(物理構成編)→　機器や配線など物理的な構成に関する記事

・ラズパイ で電子ロッカーを作る！(ソフトウェア編)→プログラムについて

ここでは、AWSのEC2インスタンス上(EC-CUBE)で動いている「ご近所マルシェ Joolen」がどのようにして「電子ロッカーを開ける」という制御を行っているのかを説明していきます。

ネットワーク構成

IoT構成図

このようになっています。AWSとラズパイ 間の通信のプロトコルにはMQTTを採用しました。

MQTTは簡単にいうと、データを配信するためのプロトコルです。
「非力なデバイスやネットワークが不安定な場所でも動作しやすいように、メッセージ通信電文が軽量に設計されていることが特徴(Wikipediaより抜粋)」で、ラズパイ のような小さなコンピュータでも難なく扱えます。
Web socketにも似ていて、メッセージがPublish(送信)されると簡単に受けてはそのメッセージを拾うことができます。

AWSからラズパイ へのメッセージングに Web APIを使うことも検討しましたが、IoT機器にはセキュリテイ上、固定IPを持たせたくないという思いもありましたので今回の構成になりました。

今回のマルシェではEC2インスタンス上で、EC-CUBEは動いていますが「ロッカーの鍵を開けて！」というタイミングで メッセージを 送信(Publish)しています。流れとしては下記の通りで、仕組みとしては非常にシンプルなものです。
・解錠用のメッセージをMQTT Broker に対して 送信 (Publish)
・ロッカー(ラズパイ)は、MQTT Brokerのメッセージを監視(Subscribe)。MQTT BrokerへのPublishを検知したら後続の処理を行う。

AWSからラズパイ への通信

さて、ここからが本題です。
MQTTのやりとりをするためのサーバ(MQTT Broker)はAWS IoT Coreを採用しました。このIoT Coreへの接続は証明書を使う必要があります(ドキュメント)。
ラズパイ に 証明書を保存して接続、ということも当然可能ですが、小さなIoT機器にセキュリティ情報となる証明書を入れておくのは最善手とは言えません。

ということでIoT 専用のデータ転送サービスSORACOM Beamを使っての接続を行うことにしました。(SORACOM を使った双方向通信のデザインパターンはSORACOMさんによってまとまっています。)
このサービスは証明書の管理や脆弱性への対応等の煩雑な処理をクラウドにオフロードすることができるので、ラズパイ に証明書を保存する必要はありません。

 

下記の通り、ラズパイ 側ではAWS IoT Coreの認証情報を意識することなく接続することが可能です。

SORACOM Beamは非常に安価(1 リクエスト(*) あたり 0.00099 円)かつ、 1アカウントあたり月間 100,000 リクエストまでの無料枠もあるのでとても使いやすいサービスだと思います！

IoTは特にセキュアな接続を心がけていきたいですね。

ご近所マルシェ Joolen稼働中です！

※現在、アトレ松戸 3Fでご近所マルシェ ジョーレン で購入したものを受け取り可能です！(アトレ松戸での2021/5/23まで)

ありがとうございました。

ラズパイ で電子ロッカーを作る！(ソフトウェア編)

aws 技術タグ |  

今回の記事を担当するエンジニアの榎本です。

これまでの記事

・電子ロッカー開発始めます　→　電子ロッカー開発に至った経緯など

・ラズパイ で電子ロッカーを作る！(物理構成編)→　機器や配線など物理的な構成に関する記事

ここからは Raspberry Pi上で動くプログラムについて書いていきます。

今回Raspberry Pi側で採用したプログラム言語について

Node-REDというビジュアルプログラミングツールを採用しました。Node-REDとは何かというと。。。

Node-REDはハードウェアデバイス、APIおよびオンラインサービスを新しく興味深い方法で接続するためのツールです。ブラウザベースのエディタによってパレットに並ぶ多種多様なノードを結びつけて用意にフローを作成でき、さらにシングルクリックで実行環境にデプロイすることができます。

Node-RED日本ユーザー会トップページより引用

とのこと。
つまり、ブラウザからノードと呼ばれるブロックを線でつなげて思い通りにデバイスを動かせる素敵な言語になります。名前から推察できる様に、Node.js上で構築されてますので、必要に応じて Javascriptでのコーディングまでできるので、編集が容易かつ柔軟性が高い言語となっています。

コードエディタはこんな感じ

画面上で「再起動」などと書かれているかボックスがノードとなります。各処理をつなげてやりたいことを実現できます。

電子ロッカーを構成する各種ノードの紹介

Injectノード
上記コードエディタ左側の「timestamp」と書かれているノードです。時間を指定して処理を起動することができます。

Execノード
上記コードエディタで「再起動」と書かれているノードです。このノードでコマンドの実行を行うことができます。この場合は下記のコマンドを実行することで再起動を実現しています。

sudo shutdown -r now

つまり上述2つのノードの組み合わせで、「毎朝7時に再起動をする」という命令が組み立てられます。非常に分かりやすくて便利ですね。

MQTTノード
今回の電子ロッカーは

ECサイトからの命令をAWS IoT CoreのMQTTへPublish
↓
ラズパイ 側で該当のTopicをSubscribeしメッセージの受信をきっかけに鍵を操作

することで解錠・施錠の実行を実現しています。Node-REDはMQTT処理に必要なノードが用意されているので非常に簡単にこの処理を実行することができます。
入力側のmqttが Subscribeで 出力側がPublishになります。
ノードには MQTT Broker となるサーバの情報・トピック・QOS(=Quality Of Service)を設定することで簡単にPublish/Subscribeを実現できます。(見落としがちですが、QOSはPublish側と合わせる様にしましょう！私はここの数値が食い違っていたために数時間ハマりました。。。)

ノードの設定画面
↑↑MQTT Brokerの設定画面↑↑

余談ですがMQTT Brokerは AWS IoT Coreを SORACOM Beam経由で使っています。AWS IoT Coreの認証を肩代わりしてくれるので ラズパイ 側に証明書などを持つ必要がないことがメリットになります。(これはまた後日記事にします)

PCA9685ノード

こちらは標準のノードではないので、パレットの管理から自分で追加する必要があります。Node-REDのホームページにサンプルを含め説明が載っています。

ノードの追加はこの画面から可能です。
PCA9685ノードの編集画面

基本的には
1. PCA9685 Deviceで対象のデバイスを選択(デバイスの設定方法は下記に記述)
2. Channelはターゲットになる PCA 9685 の チャネルを選択 (直接指定でも良いし、msg.channel という変数に設定した数値でも良い)
3. Unitはサーボモータを動かしたいときは、「microseconds」 LEDを点灯させたりしたいときは「Percent」を選択しましょう。

デバイスの設定画面

PCA9685を指定する画面です。ラズパイ 側で下記の通りになっていれば特に変更する必要はありません。
※Addressは下記の画面で 0x40(=64)であることが確認できます。

例) 15個の扉の解錠を行い、操作がされた時にLEDを点滅させるためのフローは下記の様になります。
1. open_1_all へのメッセージの Publishをトリガーにしてフローが起動
2-1. サーボモータを動かす
　　2-1-1. サーボモータを140度回転した位置にするためmsg.payloadに値を設定
　　2-1-2. PCA9685 ノードを経由して1〜15チャネルに命令を出す
2-2. LEDを点滅させる
　　2-2-1. 0番のチャネルに接続されたLEDを点滅させる
2-3. MQTTメッセージを受け取ったことを送信元のプログラムへ返却するため、受け取ったランダムな文字列をそのまま返却用のMQTTトピックにPublishする

他に大きなポイントとして、ラズパイ の死活監視に使っているlwm2ノードがあるのですが、これは監視についての記事で触れたいと思います。

次回は電子ロッカーのネットワークや、利用しているSORACOMのサービスについて触れていきたいと思います！

ラズパイ で電子ロッカーを作る！(物理構成編)

aws 技術タグ |  

新規事業を担当している榎本です。
前回の記事で、私たちがなぜ電子ロッカーを作るという決定をしたのか記載しました。では早速、ロッカーを動かすための物理的な構成を書いていきます！

全体図

まずは全体図の写真です。かなりシンプルな構成ですね。基本的にECサイトから受け取った「ロッカーの解錠・施錠」に関する命令をラズパイ が受け取って複数のサーボモータに伝達する形で実現しています。

※見やすくするためにサーボモータ などは外した状態で撮影しています。

機器について一つずつ解説していきます。

機器名称役割
Raspberry Pi Zero WH電子ロッカーの心臓部。
内部のソフトウェアは誰でも扱いやすいようにビジュアルプログラミング言語である
Node-REDを採用しました。美味しいものマルシェ(ECサイト)からのロッカー解錠の
命令に従って周辺危機の操作を行っています。
あまり重たい処理は無いためスペックは重視せず、小さくて安価な Zero WHを採用。
AK-020 (Soracom Air)通信は Soracom Air for セルラーを使っています。通信に必要なモデムとしてAK-020を
利用しています。(このモデムの中に SIMが入っています)
Amazonで販売しているSORACOMスターターキットは通信量1,000円分のクーポンも
ついていてお得でした
PCA9685購入者1人につき、1つずつロッカーの扉を割り当てています。それぞれのロッカーの
扉を個別に操作するためにPCA9685を使ってサーボモータを制御しています。
電池ボックスサーボモータを動かすための電源です。プロトタイプでは電池ボックスを
使っていますが、USBからの給電になる予定です。
TowerPro
SG92R		ロッカーを実際に解錠するためのモーターです。扉1つにつき、1つのモーターが
使われます。写真には載せていませんが、PCA9685につなげています。
高輝度
赤色LEDランプ		ロッカーが実際に施錠・解錠されたことをユーザーが認識できるように、操作された
タイミングでLEDを点滅させます。これも写真には載せていませんが、PCA9685に
つなげてます。

配線について

ラズパイ とPCA 9685の配線図です。GPIOは 1,3,5,6 (青枠で囲った部分)を使っています。

ラズパイ のPIN番号ラズパイ側の名称PCA9685側のピンの名称
15V PowerVCC
3SDASDA
5SCLSCL
6GroundGND

実物の写真はこのようなイメージです。PCA9685は基盤にPINの役割が書いてあるので間違えにくいですね。

Raspberry Pi Zero WH
PCA9685

ちなみに、PCA9685を使うときにはラズパイ 側のコンフィグを変更してI2Cを有効にする必要があります。こちらの手順についての記事は多いので調べればすぐに分かると思いますが、こちらにも掲載しておきます。

sudo raspi-config

こちらを実行すると表示される画面がこちら。ここで５番の Interfacing Optionsを選択して

I2Cを選択

「はい」を選択して I2C interfaceを有効にしておきましょう！

これでラズパイ を通して複数のサーボモータの制御をするための準備は完了です。サーボモーター はこの様な形で扉に取り付けられています。サーボモータが約140°動くことでギアを経由して鍵が閉まり、ロッカーが施錠されている様子がご覧いただけます。

次回はラズパイ の操作に利用しているプログラム言語、Node-REDについてご紹介していきます！

電子ロッカー開発はじめます

aws 技術

今回の記事を担当するエンジニアの榎本です。
トップページにも記載されていますが、松戸の美味しいものマルシェを開催中です！(2021/3/31まで)
ありがたいことに多くのお客様にご利用いただき、めでたく4/23より第２回目の開催も決定しました。

さて、第１回目ではお客様への商品受け渡しを人の手で行っていました。しかし、下記の理由により次回のイベント以降の受け渡しは無人で行うことになっています。理由としては。。。

  1. 1. 購入いただいたお客様にできるだけ幅広い時間でのお受取りをしてもらうため
  2. 2. 受け渡しにかかるコストを削減するため
  3. 3. 受け渡し担当が長時間座ることにより発生する腰痛への対策

3つ目は冗談として…お客様の利便性と当社としての収益性を保つためにロッカーを使った受け渡しを行うことにしたのです。このロッカーの実現にあたっては下記の４案が検討されました。
大雑把に分けると、

  • ・アナログにダイヤル錠を使った運用をするか、電子キーを実装するか。
  • ・扉を共通化するか、受取人毎に別々にするか

です。これらのメリット・デメリットを大きく下記の様に分類しました。

方式メリットデメリット
1. ダイアル錠(共通扉)開発コストが小さい
運用が最も簡単		運用の負荷が大きい
セキュリティの不安が大きい
2. ダイアル錠(個別扉)開発コストが小さい
共有扉よりセキュリティが保たれ易い		運用負荷が大きい
ミスが発生しやすい
3. 電子キー(共通扉)後述の個別扉よりメンテナンスは容易開発コストが発生する
セキュリティの不安が大きい
4. 電子キー(個別扉)運用の
セキュリティ面で安全性が高い		物理面を含めると開発コストが最も大きい。
システムのメンテナンスコストも高い

私たちは上記を検討した結果、セキュリティ面での安全性と確実にお客様が商品を受け取れることを重視して案四の電子キー(個別扉)を採用することに決めました。
まぁ、開発者としては茨の道っぽいのですが… IoTは弊社としては初挑戦で、楽しそうなので良しとしましょう！構成はざっくりとこんな感じ。
ラズパイ 、SORACOM 、AWSを組み合わせた構成でラズパイ 上の言語は Node-REDを使っています。

次回からは、システム的な観点からどの様に私たちがこの電子ロッカーを構築しているのかを公開していきます！

オンライン社内勉強会のノウハウを公開！

技術 雑談タグ |   

オンライン社内勉強会はじめました！

社内のエンジニアのスキル向上を目的として勉強会を定期的に実施することになりました！完全フルリモートとなった当社で、オンライン勉強会の開催は初めてだったのですが、社員の皆さんからご好評を頂けましたので、そのノウハウを公開します！

オンライン社内勉強会のシステム構成

zoomとsli.doを使って下記の構成で実施しました。１回あたりの時間は60分(厳守！)です。

スピーカーが一方的に話すばかりだと、聞いている方も辛いと思ったので双方向がやりとりできる構成にしています。sli.doを使っているのは、zoomだけだと話づらい上に、複数人同時に発言をしてしまうと話がまとまらなくなってしまうためです。

オンライン勉強会で社員間コミュニケーションを演出するために

メインスピーカーからお題を出す

こんな形でメインスピーカーからお題を出して3分間の間に色々な意見を出してもらっています。

sli.doの活用を活用する

sli.doでは色々な意見が出てくるので、メインスピーカーはそれを読み上げながら、社員同士の情報交換を促していきます。

活発な社員間のやりとり

盛り上げるためのちょっとした演出をする

また、勉強会の冒頭では下記のようなスライドを出して、できるだけ「賑やかしてもらう」ことを意識しています。

社員の皆さんからのフィードバック

勉強会終了後のアンケートでは、このような意見を頂きました！

  • シンキングタイムがリアルタイムで書き込めて面白かった
  • 盛り上げようという意識が非常に良かったです。全員でやっている感、全員が主役感を出そうとしていたと感じました。
  • たまに回答コーナーがあるので、リモートでも、参加している感が出て、集中しやすい。sli.doでみなさんのご意見が見れて参考になりました。
  • 途中途中でみんなのコメントを拾ってくれたので、人がどう考えてコーディングしているかが伝わってきた。とても興味深いし、勉強になると思う。本には載っていない、各々が経験した事例を知ることができるのがとても良い。

やはり、集中力の維持や一体感を演出する上で今回のスキームは良かったのかな、と感じています。

オンラインならではの課題

やはりネットワーク系の課題が大きかった気がします。在宅ですとスピーカーも聞くひとも使える帯域も限られるので、難しいところです。

  • 録画の影響なのかスピーカーの声がたまにロボ化してた

オンラインならでは、というわけではないのですが、

  • sil.doの最初に入れる番号をあらかじめslackとかで共有していただけると助かります！！スタート、入れてませんでした。。。

ということもあるので、sli.doを使う時には予め、イベントの番号やURLを伝えておくようにしましょう！

最後に

オンラインの開催なので盛り上がるかどうか最初はとても不安だったのですが、社員の皆さんからの温かいリアクションもあり、非常に有意義な勉強会になっていると感じています。(本当に感謝です。。。)

「松戸のwebシステム開発会社といえばジョーレン」と広く認知して頂くために、これからも社員一体となってスキルの向上に努めていきます！

English Only のミートアップに参加！

お知らせ 技術 雑談タグ |   

エンジニアをやっていると、なかなか避けて通ることが出来ないのが英語。GithubのIssueだったりStack Overflowだったり、はたまたOSSの公式のドキュメントだったりと、何かと触れる機会は多いと思います。しかし、正直言って英語に対する苦手意識というのもぬぐいきれなかったりして、、、でも、やらないといつまでたっても出来ないというのもまた事実！ということで、弊社の社員である石澤さんが、全て英語で進行する日本人コミュニティでの登壇に挑戦しました。(MeetUpの案内サイトはこちら)

当日使用した資料

ちなみに、きっかけはこの様なやりとりw（一部抜粋)石澤さんの悲痛な叫びがジョーレン に響き渡りましたが、ここで断らずにやり切るあたりは、流石です。

当日の発表テーマは当社で取り組んでいる Call for Code  ! この様なグローバルなハッカソンに挑戦する、ということはコミュニケーションも当然ながら英語がメイン。挑戦することでビジネススキルだけではなく、英語のスキルも学ぶことができる様になる、という話でした。

余談ですが、当社の石澤さんは(自称)ハイパーSlack絵文字クリエイターということで、自己紹介でも様々なSlack用の絵文字を発表して大いに場を盛り上げていました！

技術のスキルと共に英語のスキルも伸ばして、より良い開発ライフを送っていきましょうね！

English Meetup参加中
English Meetup参加中の様子

 

↓↓せっかくなので上記を英訳↓↓

If you are an engineer, you can’t avoid English, and you have many opportunities to come into contact with Github’s Issue, Stack Overflow, or official OSS documents.
Actually, many engineers couldn’t get rid of weakness for English…But it’s also true that if we do nothing, we won’t be able to talk English !
One of member of Joolen Inc., Mr. Ishizawa, took on the challenge of speaking at a Japanese community, which was conducted entirely in English.

By the way, the trigger is shown below. Mr. Ishizawa’s sorrowful cry echoed through Joolen, but he earned high acclaim that he did not refuse to go through with spoke at meetup.

The theme of the hackathon was Call for Code, which we are working on our company. As we are challenging such a global hackathon, we have to communicate in English. He spoke that by taking on the challenge, you can learn not only business skills but also English skills.

As a side note, Mr. Ishizawa is a (self-proclaimed) Hyper Slack emoji creator. And even during his self-introduction, he announced a variety of Slack emoji to get the place excited!

Let’s improve our English skills as well as our technical skills and live a better development life!

Docker入門勉強会を実施しました！

技術タグ |

少し前の話になってしまいますが、Dockerに関する社内勉強会を開催しました！(現在、当社はリモート勤務中心です)

時間は12:00〜13:00で、みんなでお昼ご飯を食べながらの勉強会です。

勉強会の様子
勉強会の様子。畳スペースが有効活用されています。

Dockerは社内の開発でも使われているのですが、今までは体系的に学ぶ機会も無く何となく使っているケースもあったようなので、そもそも「Dockerとは何なのか？ 」から情報を共有しました。ざっくりとした内容としては、、、

  1. コンテナと仮想マシンの違い
  2. コンテナの歴史
  3. Dockerの仕組み(どのようなフローでDockerを使った開発をするのか)
  4. Dockerでインフラをコード化することのメリット
  5. コンテナとセキュリティ

という内容です。

コードベースでの勉強会というよりも概念的な部分から皆で理解を深めました！「DockerコンテナとDockerイメージの違いって何だっけ？」や「Dockerのイメージはこうやって開発するんだ〜」といった話を和気藹々とできました。Dockerについては、意外とわかっているようで分かっていなかった部分が多いですし、基礎からじっくり学習する時間も取りづらい箇所でもあるので、社内のエンジニアにとって良い振り返りの機会になったのかな？と思います。

弊社では引続きエンジニアの生産性向上施策を行っていきます！

IBM Champion for Cloud 2020に認定されました!

技術 雑談

昨年よりジョーレンの一員となりました榎本です。

弊社自体はIBMとの直接の関わりはないのですが、個人的な活動として続けてきたIBM Cloudに関連したコミュニティの活動が認められ、2019年に引き続き、今年もIBM Championとして認定いただきました！

※IBM Championとは、、、
IBMが公式に認定した外部エバンジェリスト(社員ではない)です。認定にはIBM製品に関する専門知識や、コミュニティやブログなどを通じて外部へ発信するインフルエンス力が必要とされる上、１年単位での更新(審査あり)が必要なため、割とタフ(笑)な認定になります。(詳細はこちら(英文))
ただ、他の非常に優秀なエンジニアの方々と会社という垣根を越えて繋がることができる上、様々な場所での登壇や勉強の機会が頂けるので、非常に魅力的な認定となっています！

2019年の私自身の活動として振り返ると、、、

  • 各種コミュニティでの登壇(写真はDISTさんでお話させて頂いた時のもの)

など、色々とありました！

他にもQiitaへの投稿を通じた情報発信など、色々と自由にやらせて頂いております！(2019は会社でQiitaアドベントカレンダーにも挑戦しました)

会社には技術に関連した活動に対するご理解や、サポートを頂き本当に感謝しています。これからも松戸発エンジニアの幸せを目指すジョーレン、そして松戸をテクノロジーで盛り上げていける様に頑張っていこうと思います。

開発が好きな人、新しい技術に触れたい人、一緒にこの素敵な会社で働きませんか？
こちらもお待ちしていまーす！

人の意見を聞くことの大切さ

mysql 技術

どうも、モリタです。
こんにちは。

意味をちゃんと調べることなく、生きていく中でなんとなく覚え、なんとなく使っている言葉は結構多いのではないでしょうか。

今日はそんなお話です。

先日、MySQLでテキストが保存されたカラムに対してLike検索することを「全文検索」と呼んでいたら、複数の人から「それは違う」と指摘されて、エンジニア生活10年間、ずっと間違えて使っていたことにショックを受けました。

私はいままで、全文検索の手段としてLike検索を使うのか、全文検索エンジンを使うのか、はたまた転置インデックスを自作するのか、と思っていたのですが、どうやらRDBMSでは転置インデックスを使った検索のことを「全文検索」と言うらしいのです。

（ここで納得してしまった人は最後まで読まないと危険です）

これまで、「全文検索」についてしっかり調べたわけでもなく、エンジニアになって会話の文脈からなんとなく意味を把握し、特に疑問を持たないまま使っていたので、「あー、そーだったのかー」とその時は納得しました。

だがしかし、「全文検索」という日本語からしてLike検索が全文検索ではない、というのがどうもしっくりこなくてモヤモヤが膨らんでいきました。

なのでちゃんと調べてみることにしました。こういうときはウィキペディアが頼りになります。

 

全文検索（ぜんぶんけんさく、英: Full text search）とは、コンピュータにおいて、複数の文書（ファイル）から特定の文字列を検索すること。「ファイル名検索」や「単一ファイル内の文字列検索」と異なり、「複数文書にまたがって、文書に含まれる全文を対象とした検索」という意味で使用される。

 

ん？ちょっとまてよ？

私の認識は間違ってないんじゃないか？

ウィキペディアをもう少し見てみます。

 

全文検索技術
grep型
・・・中略・・・
索引（インデックス）型
・・・中略・・・

 

Likeはgrep型だろうなあ。

 

・・・

 

確信しました。

私の認識は間違っていなかった！！

結局、Likeだろうがインデックス使おうが、全文に対して行う検索は全文検索なんですね！！

ちゃんと調べて良かったー。

 

調べていく中で、「全文検索=インデックス型の全文検索」として扱っている記事が沢山ありました。

言葉は、勘違いや間違いが元で変化していくものだと思うので、多くの人の認識を正とすれば良いと思いますし、日常生活におけるコミュニケーションでは、話が噛み合っていなくてもそれほど大問題になることはないでしょう。（男女関係は別として）

しかしそれがシステム構築となると話は別です。（ビジネスなら何でもそうだと思いますが）

認識の齟齬が重大なバグを生み出すことになるかもしれません。

プロジェクトの全員が同じ認識でいるかどうかを把握するのは難しいと思います。

ただ、少しでもおかしいと思ったら迷わず確認するのが大事だなーと改めて感じました。

そして伝える時は「全文検索」と言う漠然とした言い方ではなく、「likeを使った全文検索」などと具体的に言うように心がけようとも思いました。

 

若い時は人の意見はあまり聞き入れず、自分が正しいと思ったことは貫き通していましたが、年を重ねるごとに、なるべく人の意見を聞くように心がけていました。

それが災いした今回の事件でした。

これからは人の意見を聞かないようにしたいと思います！！！（嘘）