先日ですねAPIを開発することがございましてWeb APIですか?Web APIです基本的にはRESTと呼ばれるスタイルを使ってAPI開発してるんですけどちょっと僕的にはRESTって完全に当てはめきれないなーっていうケースがあるなと思ってるんですよもうクラッと普通のやつ埋まっちゃってるし次どうしようかなみたいな

ことがありましてそんなことを思っている皆さんのためにこんな企画を用意してきましたなんですかWeb APIエンドポイント設計選手権クイズ企画好きですね僕らですよやっぱりじゅんぺいがいるときはねお前なんで上裸なのあれ

言いますそれそうなんですよねなんかエンドポイント選手権だなと思って気合入れてるんだありがとうマジで気合入れる方おかしいだろあんまないぞ気合入れようって冗談になるやつまあこれだけ気合入ってるんできっと今回は全問答えてくれるんじゃない答えてるとか正解してくれるんじゃないかなと期待しております気合の問題なんだすでにドキッとしてますから題名だけでちなみにじゅんぺいくんAPIの設計をどれくらいやったことありますか

いやマジで考えてみたらなくって現場ではなくって研修以来だなと思う1年以上ぶりみたいな感じですねもうそんなに実務経験積んだんだってかちょっとドキッとした確かにいや積んでなくない実務経験で言うと1年ぐらい

困ってねえじゃんさっきとあれもう立ってるそんなの立つかさっきと変わってねえじゃんちょっと違いますけどみたいなテンションで話し始めたさっきと同じこと言ってんじゃねえかすいませんなるほどねまあじゃあこれはちょっといいトレーニングになりそうですねいや本当にちなみに僕も全然ドキドキしてますし僕とのりさんも回答する感じですよねはい怖いなちょっとドキドキしてますそうですね僕とかいちくんがそれぞれ3問ずつ用意してきたのでありがとうございます

ぜひちょっとそれを聞きながらヘンドポイント設計についてのこういうの考えるといいよみたいな情報も小出しにできたらいいねかいちくんはいもちろんですがそれ駆動で問題考えてきたんでありがとうございます僕はそれの駆動せずにあわあわしながら用意しました自分で言ったやろ今いきましょうか早速ここからいきますねお願いしますノリさんとじゅんぺいに答えてもらう感じで

まあまあまあまあそんな肩の力抜いてまず問題の出し方もよく分かってないからね基本的にはユーザーストーリーをぶん投げるので操作するならラガーでこういうウェブAPI動くなみたいな形でURIを言ってくださいURIとあとは必要に応じてクエリとかボディとかぐらいですかねを書いていただければと思いますはいじゃあレベル1レベル1レベル1

ドシンプルのユーザー作成いいですねユーザー作成ですかユーザーを新規作成する考えすぎない方がいいんじゃないユーザーメソッド名とメソッド名とURIあとはクエリーな意思ボディの回答お願いしますはいすいませんポストメソッド名ポストですよね

はいはいはいすいませんでURLがスラッシュユーザースラッシュユーザーはいはいポストユーザーはいであと何でしたっけクエリとかボディとかの話あーそうですねどこに何を入れるんじゃいとどこに何を入れるんじゃいって必要なんでしたっけ何も入れないいやそれもそれでありよえっと必要ないことにします必要ないことにしますはいじゃあのりさんお願いしますはい

まずメソッドがポストURIがスラユーザーズパラメータはリクエストボディでキーバリューの形でユーザーの情報を送ります解説もついでにのりさんお願いしますはい

じゃあまずですねメソッドのポストこれは正解ですね基本的にはリソースを作成する処理なのでポストで良いでしょうとメソッドじゃなくてURIですねじゅんぺくんユーザー僕ユーザーズって答えたんですけどWeb API Good Partsによるとリソース名は基本的には複数形が良いだろうと言われてますただそうじゃないAPIも世の中には多分いっぱいあります

なるほど何ですかWeb API Good Partsオライリーで2番目か3番目に読みやすい本ですねヘビボンあれはねリソースは複数がいいんじゃないって言ってますなんか僕のイメージだとデータベースのテーブル名みたいなもんかなと思ってます複数形ですよね要はあれリソースを表してるから今回のユーザーっていうよりも

もっとデカいものを表してるんじゃないかなって思ってますなるほどポストで送る際はパラメータはリクエストボディに乗るのでクエリじゃなくてねこれはRFCとかに定義されてるのかなどうなんだろうね多分読もうと思えばクエリでも読めるんですけど監修としてボディに乗せることになってますねそうですね何も

ボディに入れないと受け取ったAPA側は何作ればいいんだろうってなっちゃうので適当に作っちゃえすいませんただそのパターンもゼロじゃないと思ってて例えばですよじゅんぺいがそれを考えてたなら正解にしてあげるんですけど初期パスワード勝手に発行されますユーザーIDも勝手に発行されますタイプだったら何も送らなくてもユーザーできそうですね

初期パスワードは初期ログイン時に自動発行されたIDでログインしてその時にちゃんと書いてねみたいなそんなシステムだったら多分何も送らなくてもいいのかもしれないですけどあんまないです見たことないかもしれないゼロじゃない気がするな記憶にないですけど楽天証券とかはIDこっちから指定しないんで自動で出ます最初にメールを送るんじゃないですかメールアドレスかなんか

それはそうだわメラーダを送るわじゃあそうだわという形で一番シンプルなユーザー作成でした学びとしてはリソース名は複数件にしましょうというところですね続いて2問目です若干ここで引っかかるんじゃないかなと思いながら問題を出します次さっきユーザーを登録しましたユーザーの情報を変更したいなと思ったときですね

ユーザー情報をいろいろ入れてましたがその中に住所があります引っ越したんで住所を変更したいです住所を変更するWeb APIのリクエストどうしますかポストでURIスラユーザーズユーザーIDも一緒に送りますクエリになるんですかクエリでいいんじゃない特殊の変えたいユーザーのユーザーIDを

付けて送りますでさっきので言うとボディに変えたい住所変更するしたい住所をキーバリューで送りますうんうんうん変えたい住所ってどういうイメージ住所住所を表すキーと今回変更する住所をバリューに入れて変更後のSL変更後ですね

まとめるとポストでユーザーズクエリにユーザーIDボディに変更後の住所はいノリさん回答お願いしますちょっと待ってこれ質問いいですかどうぞちなみにその画面は住所以外も更新できますかできます電話番号とかいろいろあります分かりましたあともう一個いいですかブラウザから利用するってことは

どっちの考えでいけばいいですかねどっちというと今プットにしようかポストにしようか悩んでるんですけどブラウザの場合ってゲットとポストしかないじゃないですかえ?

そうなの?はいいやいやいやいやWebはそうですよマジですか?だからLaravelとかRuby on Railsとかのフレームワークはポストで送ってるけどリクエストボディにアンスコメソッドみたいな感じでメソッド名入れてそれでプットと見なしてるみたいな感じなんですよへーそうなんだ知らなかったそこは気にしなくていいですか?気にしなくていいですはい

プットスラユーザーズスラパスパラメータでユーザーIDでリクエストボディに変更後のデータを入れる変更後の住所を入れる住所というかそのフォームにあるやつ全部送られてくる想定ですねなるほどありがとうございますノリさんのは正しいです順平のは間違えていますすいませんはい

一旦解説ですねポストはさっき言ったユーザー作成みたいな新規作成するものなので基本的に変更するときはプットかパッチを使いますただのりさんがさっき言ってたのマジですかそうなのマジですバックエンド側であんまり意識したことなかったかもしれないバックエンド側だと確かに意識しないかもしれないじゃあ誰が意識するんですかそれフロントエンド開発してる人が意識するってことどういうことですか

いやバックエンド意識すると思うよだけどフレームワークによって意識しなくて良い感じになってるでPostmanとかからならPutメソッドで送れるPostmanからPutメソッドで送れますねうんAPIだから送れるやんでもブラウザから送れないブラウザからリクエスト送ってることありません?あ待って送れるかもそっかAPIだからJavaScriptから送れるのかJavaScriptから送ってるんじゃないですかわかりました

まずJavaScriptから送る場合はBootで送れますただブラウザのフォームですねHTMLのあのフォームはGetとPostしかないのでララベルとかの場合ですとメソッドを一緒にリクエストボディで送ってます

ララベルとかの場合そうララベルはルーティングのところでプットとか指定できるんですけどフォームで送る場合プットが指定できないんで一緒にメソッドプットみたいなやつを送ることによってプットメソッドと見なしてルーティングが判断してくれてますなるほどなるほどじゃあ一旦置いといてそこはややこしいので忘れといて忘れましたありがとうございますより詳しくなりました

でまあプットカバッジ使いますと次URIですがユーザーズここもいいんですが基本的にというかよくあるパターンだとURIにユーザーIDを含めることが多いですねクエリに含めるというよりはユーザーズの中のユーザーIDでURIで特定のユーザーを特定する絞れるように書くことが多いです

変更後の内容をボディに含めるんですけどここでちょっと僕がお伝えしたかったのはプットとパッチの違い知ってるって話ですのりさんはプットって言っててのりさんの使い方だとプットでも問題なく処理ができますプットとパッチの違いはですね変更後こういう風に変更するよって送るのがプットで送ったとこだけ変更するよがパッチです

ノリさんは変更後のユーザーの情報を全部プットで送ってたので変更後ノリさんが送った形そのままになるっていうのがプットです純平の送り方だとパッチだとそうなんですけどその送り方でプットをやるとユーザー情報が住所以外全部吹っ飛びます危ない普通はね必須のキーないぞとかって弾いてあげるのが優しさですけど確かに

っていうのでプットとパッチ違うから気をつけて使ってねっていうのが第2問の出題意図でしたすいませんそもそもたどり着けなかったまさかねまさかポストで来るとは思ってなかったですけどすいません恥ずかしい第2回必要だなこれ第2回できる気しねえ

今までの学びとしてリソースは複数形プットとパッチの使い分けあとURIには絞れるように書きましょうというのが学びでしたじゃあ第3問ですAmazonじゃあ思い浮かべていただいてAmazonかなAmazonでいいやAmazonで商品検索します商品検索するAPIのみむずい

商品検索ですログインしてした後に商品を検索するパソコンめっちゃすごい検索してすごいパソコン検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検索してすごい検

ズルズルすぎるな斬新だねそれいや全然はいいきますねゲットでURIスラユーザーズスラユーザーIDえ?スラサーチアイテムズですちょっと限界いきましたすいません

限界でしたいいと思う限界ですゲットでユーザーズユーザーIDのサーチアイテムちょっとじゃああえての問いかけなんですけどプロテインって検索するじゃんAPIの気持ちになってみてよサーチアイテムリクエストが来てさどうするプロテインっていう情報なくないかボディに検索キーワードを入れてうんうん

飛ばしてそれに引っかかったやつ持ってきてもらうなるほどじゃあGet Users User ID Search Itemsでボディに検索カードが入っているとはいじゃあのりさんお願いしますこれちょっとねリソース悩みどころなんですけどちなみに僕も正解を知らないのでGetでスラサーチクエリパラメータでQイコール入力フォームに入ってたやつのやつありがとうございます

個人的にはのりさんのが正解なのかなと思っておりますちょっと悩みどころとしてはさあれだよね他のサーチもあるのかなみたいなまあそうですねでもえっとまあでもそっか僕は思ってたのはゲットするアイテムズのすらサーチなのかなと思ってましたいやそうねはい他の検索があるかなと思ってそれこそamazonで言うとねビデオとかねえーなんでしょうね

欲しいものリストの中にないの検索かねヒストリーズの検索かね確かに色々あるかなと思うので確かにな個人的にはリソースの下にサーチ入れてなのかなと思ってたんですが解説するとさっきURLに含めるのがリソース複数形のリソースですみたいなお話をしましたが物によっては動詞が入ります

そうなんですよね今回サーチが入りましたが他の例はよく分かりませんが何?足し算するとか計算するとかカリキュレートクエリーで計算式入れるとかそんなのあるか?あんまないかもサーチぐらいかなメインはサーチはよく出てくるよねなので同時に入ることもあるんやであとゲットの時は基本的にクエリーなのでボディよりもクエリーの方が一般的ですね

ボディもね多分読めないことはないんですけど遅れればするんだ遅れると思いますあんま見たことないです確かに驚き最小の原則ってありますけどAPIリファレンス見ててボディだったらびっくりしたんでクエリでもしボディでやったらその検索したよっていう結果のページを人にシェアできなくなりますねURLに載らなくなるんでなるほど

順平がそのユーザーをURIに含めたのはなんとなく人によってパーソナライズされてるんじゃない検索結果って意図が現れてるのかなという風に捉えたんですけどもなるほどタイムスリップしてるんだと思ってました過去の問題に違うどうなんだろう多分よく知らないけど

トークンとかで取ってんじゃないって思うユーザー情報はログインするときにログインできたってなったときにこいつは本当にログインしてるかどうかっていうのってヘッダーにトークンと言われるめちゃくちゃ長い文字列を含ませてこんな長い文字列知ってるんだったらこいつ多分ログインしたやつだわっていう風に判定してるんですよ多分そのトークンで

こいつが誰かっていうのは分かるので多分URIに含めてるっていうよりはきっとそのトークンでパーソナライズしてでなんかこいつが好きそうな検索結果出してるんじゃないかなと想像しておりますそうですねなんかこう

URIのところに含めてしまうとあれですよねユーザーの中にある商品みたいな見え方しちゃいますよねメルカリでいう自分が出品しているものとかだったらそういうので正しいんだけどAmazonでいうと多分違いますね

はい以上カイチから3問でした1問目普通のやつ2問目プットパッチの違いわかるよね3問目動詞も使うやででしたありがとうございますすごいなちゃんとここ学んでほしいっていうポイントがすごいただ大苦戦だったけどね問題作るのどうやったら難しい問題できるんだってなったんだでも順平が全部引っかかれた引っかかりきれなかったそういう意図なしで作ってしまった感はあるわ

じゃあ次のノリさんですねいきますよレベル1からこれちょっと僕もAmazonを想像してほしいんですけどECサイトでタイムセールの商品一覧を取得するエンドポイントですねこれとは別に普通の商品一覧を取得するページもあると想定しましょうタイムセール商品を取得するYes

整いました整いました伝わらないでそれ音声じゃ本当ねゲットメソッドでURLスラーアイテムズスラーなんか雰囲気で場の空気でタイムセールとして

カテゴリー分けされた値を取ってくるどういうことアイテムズスラアイテムズスラアイテムセールアイテムズセールアイテムズと分類されたIDみたいなのを入れるやつまとめるとゲットでスラアイテムズスラセールアイテムズなるほど

めちゃくちゃ難しいんですけどまず言い訳から入りますタイムセールってどうやって判定してるんだろうなと思って多分アイテムズテーブルの中で1個の商品に対して通常価格とタイムセール絡むみたいなのがあってそこに何か入ってるか入ってないかで判定してると想像していてアイテムズでクエリでタイムセールみたいにするかなって感じです

なるほどねクエリで分けるパターンですねクエリで分けるパターンですでゲットですゲットはいこれ僕も正解分かんないですし多分パターンによると思うんですけど僕はゲットですらアイテムすらタイムセールにしましたねはいはいはいそのパターンありますよねこれは多分クエリでやるかパスパラメーターでやるかに関してはパスパラメーターじゃねえこれパスでやるかに関しては

結構要件によって変わるんじゃないかなとも思うんですけどあんまりセールのパターンないならパスの方が可能性が絞れて見やすいんじゃないかなっていう風にはちょっと思いますねまあそうですねただ一方でクエリだとパラメーターって自由に渡せるんで無限の可能性生まれてしまうんですけど

こういう風にパスにすることによって一通りに絞れるのであんまりパターン分岐しない場合ならパスの方がいいんじゃないかなって個人的には思ってますもうちょっと詳しくいいですかパスだと絞れるっていうのはどういうことですか例えば今回みたいなスラアイテムススラタイムセールって言ったらそれがタイムセールの

アイテム取ってくるんだなっていうのが明確になるじゃないですかなんですけど逆にこのタイムセールの部分をセール例えば何種類もあるとするじゃないですか10種類ぐらいセールのパターンみたいなやつをクエリパラメーターで受け取るようにしますとそうすると入力側ってその10パターン以外にもいろいろ入力できちゃってそれでも送れるじゃないですか入力側送れます送れます

ってなった時にもしセールの種類少ないのであればパスでやってしまった方が使い方が明確になっていいかなっていう送る際に何も考えずに使えるというかなるほど

そうですねただのりさんが言うようにものすごくエンドポイントが増えてとんでもないAPI設計書ができたりするのでそうですなのでセールのパターンが逆にめちゃめちゃ多いと例えばタイムセール特選セールなんちゃらセールなんちゃらセール1月セール2月セールとかなっていくと今度パスが多すぎて意味不明なんでそういう場合はクエリにまとめた方がすっきりしていいのかなっていう風にちょっと思ってますねなるほど

はいという余白のある問題でしたいやいやでもそういうもんですよ設計ってそういうとこありますからねそれゆえ多分デザインって言われるんでしょうね確かに職人技が含まれるというかだいたいAPI設計すると毎回こういう悩みいっぱい出てくるんですよねそうですねレベル21があれだったのかからも怖えわあんまないんだよな差がいきますまず会員登録が必須のニュースサイトです

ニュースピックスニュースピックスを想像してます今こちらのサイトには登録しないと見れないのでまず登録しますとその後に追加でプロフィールを入力しますよくあるやつですねパーソナライズするための追加情報みたいな興味のある分野みたいなねそれを更新するエンドポイント

ただしですねこのエンドポイントはプロフィール情報を更新するエンドポイントもありますが別途でプロフィール画像単体で更新するエンドポイントも存在しています存在していますはいわかりましたこの時のプロフィール情報の部分を更新するエンドポイントを設計せよいいですかはいプットメソッドでURLスラーユーザーズ

ユーザーID特定のユーザーDスラーDプロフィールDプロフィールDプロフィールDプロフィール何だったんだっけDDって言っているDって言っているかプロフィールかそういうことびっくりしたプロフィールでボディでプロフィール画像以外うんうんうん

なるほどプットでスラユーザーズスラユーザーIDスラディープロフィールボディでプロフィール情報画像以外の書いちめ悩ましいこれも悩ましいゲットユーザーズユーザーIDプロファイルでここからですよ多分画像だけ書いてるのはプロファイルスライメージ

プロファイルだけにするかプロファイルすらディテール?インフォ?つけるかなあえて分けるならつけたいなまあいいや一旦ディテールでボディでプットだったら全部だしパッチだったら書いたいところだけです

なるほどごめんget usersput usersuser idプロファイルディテールなるほどねディテールちょっと聞きにくいななんなんだろうインフォかなインフォ確かに以上ですありがとうございます僕はですね事前に書いてたのは

パッチすらユーザーズユーザーIDすらプロファイルはいはいはいそれで終わらせるやつですねはいわかるわかるあとPUTじゃなくてパッチにした理由としては僕の中のPUTとパッチの違いのイメージなんですけどPUTはリソース全を置き換えパッチは一部更新みたいなイメージなんですようんうんわかる今回別でプロフィール画像あるからパッチなのかなと思ってパッチにしてましたああそういうことですかはい

そういうことなのかなあれ違うのかなリクエストの出し方によりますなのでパッチがないAPIも結構あります本当にあまりにもユーザーの情報が多くてリクエストを作るのが重たくなったりとかする場合とかあとプットをする場合は事前にゲットしなきゃいけなくなっちゃうんで大体ゲットしてるんですけどそういうのが億劫な場合はパッチで送った方がいいとかはありますね

ではいじゅんぺいはなんだったんだっけじゅんぺいはput users user idすらプロフィールだからまあまああんまり変わらないですねいいね

この回で成長しました前の情報をすごい使って伸びていったかもユーザーすらプロファイルってやったのは偉いなと思ってて多分このニュースサイトはユーザーズの下にもお気に入りにしたニュース記事とかユーザーズに紐づく情報いっぱいあるだろうっていうのはなんとなく想像できたのでそれは

それを加味した上でプロファイルをユーザーIDの下につけてるのは非常に素晴らしいと思います加味してない感じする加味してたなさすがだなやっぱすごい全く加味してませんでしたありがとうございますではラストレベル3いきますかレベル3って言ってるけどこれ一番簡単かもなレベル1とあんま変わんないかもないきます

これも記事とかがバーって載ってるサイトですキータ的な感じかなキータだと思ってください人気の記事ランキングを取得するエンドポイントですただランキング自体は2種類あって月間ランキングと急上昇ランキングが2つあります急上昇の方を答えよう急上昇ランキングだと最近一気にいいねついてる系ですねはい

Getスラアーティクルズスラアーティクルズスラレイテストランキングレイテストランキング以上ですありがとうございますじゃあ僕ですねめっちゃやだなGetスラアーティクルズスラホットランキング急上昇ランキングで別になんもないもんなそれ以上以上ありがとうございます

僕もキーワードチョイス的にはカイチ君とほぼ同じところでたどり着いてたんですけどゲットでスラアーティクルススラランキングスラホットにしてましたねランキングで分けたのか確かにそっちの方がいいわそっちの方がいいですそっちの方がいいホット

ただこのホットのキーワードが確かにそうだけど日本語英語っぽいなってのはちょっと思いながら考えてたんですよねまあそうですね日本語英語和製英語というか本当に外国で通じる英語なんだろうかみたいなまあまあでも熱狂する的なのはホットではあると思うのでニュアンスちょっと違うのかなどうなんでしょうねどうなんだろうね

ちょっとその辺むずいんですけどレベル1とあんまりレベル感変わらないかもなと思いながらランキングはそうだランキングで分ければよかったくそここから増えるかもしれないですね他のランキングがねウィークリーつけた方がいいわってのがあるかもしれないですねデイリーつけた方がいいわってのがあるかもしれないですねありえますねという感じでAPIエンドポイント設計選手権でしたがじゅんぺんくんどうでした?うわーまじでなんかめちゃめちゃ勉強になった気がします本当に

こんななんかあれだねエピソードの中で成長してるの見るのは久しぶりかもしれない確かにね一問ごとに成長してたわあとなんかちょっと今回出せなかったところのあとは学びの2つ

一つは収録前にもちょっと言ったんですけど世の中にAPIガイドラインを設定している大企業がいっぱいあるのでそういうスタイルガイドみたいなのをぜひ見てから自分でやってみると良いかなというのが一つあとはよくあるのはAPIのURIにAPIのバージョン番号を含めるのがよくあります確かになのでさっきスラユーザーズとかから始まってましたけどよくあるのはV1スラユーザーズみたいな

感じでAPIのバージョンをバージョン番号をURLに含めるのがよくあります特に外向けのAPIだよねそれはい何だろう俺は内向けでもやりますそうなんだAPIの仕様変更することってよくあると思うんですよ仕様変更して例えばキーとかの文字が変わったらフロントエンド側は情報表示できなくなるんですよ

大変なんですよそういうので意図したバージョンを叩かないようにみたいな配慮でURIにバージョン番号を含める

含めるっていうのがツール関連そうですねあと外向けのAPIの場合だと例えば1個のAPIを100万人のユーザーが使ってるとするじゃないですかでその元のAPIの型変わったらその100万個のサイト全部ぶっ壊れるじゃないですかなので基本的にはバージョンで固定しておいて新しいバージョンのAPI出た時はそのバージョンを増やすことによって過去のAPIは活かしとくみたいな感じでやりますよねはいそうですそうです

なるほどっていうのもポイントでした確かに今回出題に出なかったですが学びですフォローもすごいいいですねありがとうございます順平の成長が見えたということで一旦満足ですね終わりましょうか最後に告知をDプロフィール本日の名言Dプロフィール

告知でハッシュタグひまじんプログラマーというのをつけてツイートしていただけると我々ツイッターで見てすごいテンション上がっていいエピソード出ちゃうのでぜひぜひコメントフィードバック等お願いします最近は僕はひまじんプログラマーひまじんひらがなバージョンひまじん漢字バージョンとひまプロで検索してますひまじん漢字バージョンの人がいるんですかたまにいますひらがなやってくれはい

あとはGoogleフォームにお便りというか質問とか募集してますのでそちらもぜひお願いしますでは終わりましょうかまたねバイバイそれではまた次回