2021年12月16日、第6回目となるAIQVE ONE主催の品質管理をテーマにしたセミナー、QA Tech Nightを開催いたしました。この記事では、株式会社ボルテージの髙橋貞治氏、AIQVE ONE株式会社の仲、桑野による『自動化導入でバグがゼロに！？どこまでできる？自動化テスト』というテーマでのパネルディスカッションの模様をお届けいたします。

＜関連記事＞
【QA Tech Nightレポート】ボル恋を支えるQAとテスト自動化への挑戦【前編】（株式会社ボルテージ　高橋様）
【QA Tech Nightレポート】ボル恋を支えるQAとテスト自動化への挑戦【後編】（株式会社ボルテージ　高橋様）

自動化導入でバグがゼロに！？どこまでできる？自動化テスト

桑野：
今回のパネルディスカッションのテーマは、『自動化導入でバグがゼロに!? どこまでできる？自動化テスト』です。

今、ボルテージの高橋さんにお話しいただきましたが、今後の展開や、最近はここまで進んでいるという話も交えてお話できればと思っています。はじめに自己紹介というところで、私は、AIQVE ONE株式会社 セールス&マーケティング部 部長の桑野と申します。

高橋さんは、先程のご登壇でお話いただいたので画面で共有いたします。

仲さんの方から自己紹介お願いできますでしょうか。

仲：
AIQVE ONE株式会社 第一QA部 部長をしております、仲と申します。

もともとは人材派遣会社でエリアマネージャーとして、いわゆる営業職に近い仕事をしていたのですが、そこでゲームデバッグを知る機会があり、興味を持ちまして、テスターからこの業界に入ってきました。

もともと営業職をしており、他社との折衝力を買われて割と早い段階からリーダー業務をしていたことから、提案、現場の改善、いわゆるテコ入れといった部分が主業務になっていきましたので、テストの現場からは割と早い段階で離れております。

その後、今所属しておりますAIQVE ONEには、前身のモリカトロンの頃から所属しているのですが、その中でも、テストの効率化や、今お話しいただいた自動化といった部分も日常に取り入れていけないかということを目指して拠点運営を行っております。本日はよろしくお願いいたします。

桑野：
今日は自動化をお願いする側のボルテージの高橋さんと、それを受けて実際に構築していく仲さん2人いらっしゃいますので、そのあたりを深掘りしていければと思います。

自動化導入に向けての準備について

桑野：
自動化導入に向けての準備について、というテーマですが、お互いにどういった準備をし、どういう役割分担で、どういうフローで導入を進めたかというところを深掘りして聞いていきたいと思います。高橋さんのスライドでも役割分担の話が出てきましたが、いろいろ取り組まれて、さぁやろうというときに、まず何をどこからやるかとか、共通の文脈を整理するなど、いろいろ御苦労されたと思うのですが、そのあたりで何かエピソードはありますか。

高橋さんからすると、どこまでやってくれるのかという疑問があったかと思いますし、こちらは、まだこれくらいしかできないというのがあったと思うのですが。

高橋様：
そうですね、最初は全然わからなかったので、先ほどいくつか出てきたと思いますが、ある程度定型的なところ、ここはできるのではないかというところを洗い出して案を出させていただいたという感じですね。そこが最初の一歩だと思います。

桑野：
過去に1回やられているというのもあったから、このあたりは動かしやすいのではないかというのを逆にこちらが教えていただいたような感じですよね。

高橋様：
そうですね、最初はそうでした。ただ当時のテストリーダーの方に実際に入っていただいて、テスト業務もやってもらいつつ、まずある程度コンテンツを知ってもらうという期間もあったかと思います。

桑野：
なるほど。仲さんの方で何か思い出すことはありますか。

仲：
そうですね。会社として自動化を売っていこうと動いてはいたので、まず現場メンバーに対しての自動化への理解の促進を行いました。
自動券売機とか自動販売機とか、「自動」とつくものって世の中に割といろいろあるのですが、買う側は全然自動ではなく、売る側だけが自動なのに、自動って聞くと自分達は何もしなくてもテストできるのではないかというイメージをまずテスターが持ってしまっていたので、その部分を払拭するところから開始しました。

桑野：
なるほど。お客様の中にも『自動化』というのがマジックワードになっていて、「すごいことをやってくれる」という先入観があると思うのですが、社内でもあったんですね。

仲：
そうですね。社内の方が強かったかもしれません。

桑野：
弊社も自動化ツールを開発して動くところまでは割と行きましたが、そのあとどう落とし込んでいくのかというところは、最初答えがあったわけではないですよね。まさに、恐らくテスターへの啓もうから入ったと思うのですが、その意味でもいい機会を頂いたと思います。両者が歩み寄ったと先ほど書いてありましたが、その心意気がないと進まなかったのではないかと思います。

たとえば、丸投げするのではなく、お互いに一緒にやっていきましょうというのがあったからできたのではないかと思うのですがいかがですか？

高橋様：
弊社側もテスト自動化がどのくらいのスケジュールでできるのかというのが全く分からなかったので、最初はある程度スケジュールを提案していただいて、そこを目標にして進んでいく中で、実は最初からは歩み寄ってはいなかったかもしれません。いろいろ問題が起きて大変になり、こちらも本腰というか、何かしら問題を解決しなければならないということに途中で気付いたというところですね。

桑野：
自動化はやってみないとわからない部分もあるので、絶対できるという前提で入るよりは、一回テストで動かしてみたりしながら導入していくのですが、御社との取り組みの最初の頃は弊社も出来立ての頃でしたので、すんなりいかなかった部分もあったんだなと今聞いて思いました。逆に助けていただいた部分もたくさんあったのだろうな、と。

高橋様：
いえいえ。

自動化導入でつまずいた部分

桑野：
これは想定外だったとか、すんなりいくと思ったけれどここでつまずいたとか、そのほかに面白い話があれば、仲さんいかがでしょうか。

仲：
これは、テクニカルな話ではないのですが、先ほどの妥協していただいたという部分で、目線がまず高過ぎたというのがつまずいた原因かなというのはありました。やはり頂いた要望に対して、その通りにできなければいけない、1か0かみたいな考え方でずっと取り組んでいたので、結果的にそれによって進めないことが多々続いてしまっていました。

先ほど高橋さんのパネルの中でもお話があったように、たとえば端末を絞らせていただくとか、できなかったときの判定をこちら側に一回いただいてこちらで改修をするとか、こちら側にボールを預けてもらう範囲を徐々に広げていただけたので、そういった部分で最終的に運用までもっていくことができたのかなというのがありました。その意味では、こちら側も早い段階で妥協案を出すなどしていれば、さらに早い段階で提案のレベルで運用ができたかもしれません。そのようなこともあって、まず目線の変更をし間違えたのが大きな原因かなと思います。

桑野：
なるほど、高橋さんいかがですか？

高橋様：
そうですね。やはりテスト自動化は画像を認識して動かしていくというものだと思うのですが、テクニカルなところはあまり分からないのですが、コンテンツによって解像度が違うとか、画面の鮮明さが違うとか、このコンテンツだと認識しないということなどが結構ありました。そこで、画像認識の仕方を変えてもらうとか、モノクロか何かで見ていたのをカラー判定するなどの細かい調整に、開発者の方はかなり試行錯誤されたのではないかと思います。

桑野：
なるほど、そういったつまずきだとか動かないってなったときに、持ち帰らせていただいて弊社の方でもいろいろ改修すると思うのですが、ツール自体をさらにグレートアップする改修だったり、少しやり方を変えてみたりするということが裏では起きていたという感じでしょうか。

仲：
そうですね。それこそスタートさせていただいたときに比べ、今のツールは精度も上がっていますし、組みやすくもなっているので、当時同じものがあればもっと速くなってはいるのですが、当時の状況ではできないものが結構ありました。たとえばアップデートで実装される画像を先にデータとしてうちにいただくことはできないかとか、そういった部分も相談しながら手探りで、実際にテストバイナリが来る前に組み上がっている状況を作らなければならないというのを整備したというのはありますね。

桑野：
今回、その取り組みの中で出てきた課題で、ツール自体も良くなっていっているというのがあるということですね。そうしていかないとできなかったから、そこまでは直していこうとか、追加機能を入れていこうというのが裏であったのですね。

仲：
そうですね。お客様の前で言うのは絶対ダメなのですが、実際にいただいたテストでトライ＆エラーをしていたというのがあるので。

桑野：
なるほど、ツール自体もそれで結構精度が上がり、当初はPythonで普通にコードを書いていたものが、今はより簡易化されてある程度誰でも書けるようになるなど成長していると思うのですが。

仲：
そうですね。今お話があった通りPythonの知識がないと本来は組めないツールだったのですが、パネルを合わせる、いわゆるコマを合わせるような状態である程度おおまかな挙動は作れるようになったので、今弊社のツールはコードを知らないテスターでも組めるような状態にまでは成長しています。

桑野：
なるほど、これは生みの苦しみではないですが、結果的にいい方向に進んでよかったです。

自動化を導入してよかったこと

桑野：
少しずつ進んでいく中で、安定化してきたとおっしゃっていただいていますが、一言でここはよかったなとか、やったからよくなっていくだろうなっていう未来予想図って高橋さんの方でありますか？

高橋様：
そうですね、テスト自動化は、もちろんある程度計算ができるようになって工数削減が実際にできているので、実際に活かしていけることは大きいですし、退路を断つではないですが、最初運用していくときに、先にテスターさんの人数を旧体制から減らしちゃったんです。
ですので、「オフサイトテストは1～2ヵ月分くらい出ても仕方ないよね」というところでスタートしたのですが、今は実際にオフサイトも出すときは出しますが、ある程度昔の状態に戻ったといいますか、テスト自動化を導入して、しっかり削減効果ができて余計なコストを抑えられるようになったのはとても良かったなと思っています。

桑野：
素晴らしい。ありがとうございます。一応弊社の中で言うと、もともと自動化は導入するという形で入らせていただいたのですが、導入するにあたってテスト項目を整備したりというところから着手したと思うんです。

そこから結果的に自動化でここまで動くようになって、弊社の中でも効率化というのがテスターさんにも目に見えてわかってきているというのは、仲さんから見て実感としてありますか？

仲：
ありますね。自動化を導入した一番のメリットというのは、実際案件に自動化が1テスターのような工数で入っている状態なので、しっかり目の前で成果を出しているのが見えるということです。入社したときに自動化に興味がない、純粋にただゲームが好きというテスターも多いのですが、そういったメンバーに知識欲や好奇心を持ってもらえたというのも現場にかなりいい影響を与えているということを実感しています。

桑野：
僕も自動化をずっと見てきて、ツールを使用して動きましたっていうところまでは割と行くのだけれど、どんな人でも使えるツールになるまでには全然行っていないケースの方が多かったのをずっと見てきたので、今のお話には感慨深いものがありますね。

高橋様：
テスターさんが使えているというのがすごいですね。失敗したときに調整もしていただいているので。

桑野：
そうですよね。お客様の中で、少し自動化を知っている方というのは過去に一回やって失敗されているというケースがよくあるんです。お話をしていくと「でも、仕様が変わったり画像が変わったりすると毎回書き換えてメンテナンスが大変でコストがかかるんですよね」みたいなことをよく言われるのですが、そのあたりも割と込み込みで運用できるようになっているということでしょうか。メンテナンスコストを含めても削減できているみたいな。

仲：
そうですね。これは恐らく弊社側の工数になると思うのですが、スクリプターが動くのははじめに大元の根幹の部分を作るところだけですね。あとはバージョンアップのチューニングや、若干のコード修正に関しては、テスター側で行ってしまえるため、一部のスクリプト知識があるレベルのテスターが今増えてきていて、そういう部分だけで全て完結できるような状態にはなっています。

桑野：
そこが本当は理想で、結局、特殊なハイレベルなエンジニアさんに集中して、それ以外の人はできないという状態が続いていたので、いい流れになってきているというのを感じています。

自動化導入の上で注意しておくべきポイント

桑野：
聴いていただいている方も自動化に興味を持っていただいていると思うので、自社でこれから取り組もうとか取り組んでいるという方々向けに、注意しておくべきポイントがありましたらお願いします。

高橋：
そうですね。資料にもありましたけれど、さきほどテスト自動化を入れて良かったポイントの1つに、仕様の網羅ができたということがあるので、ある程度仕様の網羅をしておくと調整期間は短くなるのではないかと思います。

あとは、作って運用していかないと効果が得られないので、運用していくっていうところをルールだとか、自動化テストと手動テストをどう組み合わせてスケジュールを組んでいくかというところですね。たとえば、1つのテストの中で、自動化と手動でそれぞれどのくらいかかるかは、ある程度本運用に入って慣れてきて、初めて匙加減がわかってくるのではないかと思います。

桑野：
ありがとうございます。仲さんからはありますか。

仲：
はい、これから自動化を行うとなった場合に、先ほどの話にもつながるのですが、自動化をお願いした場合、自動化を動かすソフトと仕様書などを共有いただいたら、あとはこちらが自動化組んでくれるみたいなイメージがどうしてもあると思います。ただ、弊社とタッグでやっていただく場合は、自動化を行うための手動が発生するという別作業がどうしても出てきます。自動化で動かすときにどういう動かし方をするのが意図なのかとか、手動でやっているときは流してやっていたものが自動化だとひっかかる原因は何かとか、そういう検知をしたときにそれが必要なのか必要ではないのか、流してしまっていいものなのかとか、今まで確認してこなかったものの確認が発生してくるので、そういった意味で完全に自動化した部分がゼロになるというよりは、1が0.5になるけど、0.2くらい考えていなかったことが発生するというイメージを持っていると、ギャップを感じずに導入していけるのではないかと思います。

桑野：
なるほど。そこは心構えとしてわかっていた方が、そこでつまずいたりとか諦めたりせずに済みますよね。簡単にはいかないですものね。

自動化人員についての取り組み

桑野：
僕も、注意したほうがいいポイントで、いろいろなお客様に言っているネタがあるので、少しだけ紹介します。

自動化人員の取り組みというところで、今もいろいろな話で出てきましたが、ツールの開発、コンテンツ自体の開発、テスターさん、スクリプトを書く人など、自動化っていろいろな人が出てくるんですよ。

そこを整理していないと大変になってしまうので、これからやる方に向けてこうしたらいいのではないかというお話です。

先ほど高橋さんにも少し話していただきましたが、工数削減、品質向上、検証期間圧縮など、目的をしっかり決めることが大切です。それに見合わなければ手動でやった方が早いということもあるので、全体の品質を上げるための手段でしかないというのを決めることと、全自動は無理なので、それはわきまえてやりましょうということです。

自動化に関わる人は、QAエンジニア、テスト自動化エンジニア、ツール開発プログラマーなど、いろいろな人が出てきて、それが1人のときもあればQAエンジニアと呼ばれる人が全部やっている場合もあるし、“ツールは他のところからもってくるけれど、そのスクリプトを考える人”をエンジニアと言っている場合もあったりします。

コンソールのゲーム業界では、開発側のプログラマーさんがQAエンジニアとして下支えしてやるということで、品管側ではなく開発側にいることが多く、少人数でやっているので、その人のタスクがオーバーするとなかなか進まないというケースもあったりします。

QAエンジニアとテスト自動化エンジニアの業務領域は不明確で、品管やテストチームからアサインされる人にテスト設計者やテスト実行者がいて、では自動化を作る人はどこからアサインされるのかという疑問があると思います。開発側なのか、とか。

自動化できる部分をちゃんと仕分けしてコントロールできる人と、実際そのスクリプトを組んでくれる人、そのツール自体を改修する人、ツールのプログラマーっていうのも実は全部ばらばらなんです。

そのあたりの役割を整理し、分けることで、ツール開発する人はツール開発に専念し、テスト自動化を考える人は考えることに専念し、スクリプトを書く人は書くことに専念し、実際スクリプトをメンテナンスしたいとか実際に使う人は、うちの実行者が行うという風に分けました。

ですので全体を考える部分と、テスト設計できる人、自動で仕分けする人、開発に携わる人と、この画像の真ん中の赤い枠の中の人が、弊社の場合1テスターさんが今ここの人材になりつつあると思っています。ここのグレーなゾーンの人がいな過ぎて、いろいろ進まなかったのではないかと思っています。QAエンジニアと呼ばれる人に全部やらせてしまうと、絶対に進まないと思います。分けた方がいいと思うのですが、仲さん、この赤枠の部分の人が結構増えてきている印象があるのですが、いかがでしょうか。

仲：
そうですね。スクリプト作成は、当然、もともと開発者として動いているスタッフがやっているのですが、テスト実行者が開発側と話せるという状況になってきているので、そういった意味で浸透が早くなったっていうのはかなり効果が大きいと思います。

桑野：
わかりました。高橋さんが直接うちの自動化ツール（オートテスター）を使っている開発者と話すことはありましたか？

高橋様：
直接はなかったです。実際のメンバーは開発者の方と課題会などのミーティングで数回お話しさせていただきました。

桑野：
基本、テストの方に入ったらツール開発した部分は入ってこないで普段のテスト業務の人たちとしか会話していないけれど、テスト自動化が進むようになっていくようになったということですよね。ツール開発の人は改修のときだけ出てきて。

高橋様：
そうですね。

桑野：
なるほど。ある程度仕上がってきたら、今まで通りのデバッグ会社に発注して、デバッグ会社のテスターさんのような感じで自動化まで進めるようになっているから、新たな人が出てくるということもなくなって普段の日常会話のなかで自動化が進むようになったということで合っていますか？

高橋様：
その通りです。

桑野：
そうですね、今お話にありましたように、ここを分離してやっていただけるといいと思いますし、結構よく聞くのが、社内で自動化を進めているけど、「メンテナンスする人材がいなくて止まっちゃって」とか、「いろいろやれていたんだけど、ここの人材いないんだよね」みたいな話です。

僕らは、スクリプトを書ける人とか、QAエンジニアや自動化テストやっていこうという人たち-プログラマーではないけれど、テスト側から開発の方へ寄っていくような人材をこれから増やしていきたいなと思っています。

質疑応答

桑野：
では最後に、参加されている皆さんからの質問に答えていきたいと思います。

質問①

『自動化して失敗して辛い点がありましたか。自動化によって増えるコストって無視できないと思いますがいかがですか』

仲：
まず自動化を導入するにあたって必要なコストは、スクリプトを組むためのスクリプターというコスト、これはスクリプターが1名つくイメージで、スタート時点では1名増になります。

今回試しながらだったので導入にお時間とられてしまったのですが、弊社としては、通常は1名のスクリプターが組んだ自動化で、1.5～2名は削れるくらいを目指して進めていくので、たとえば半年間スクリプターがついて、だいたいの検証のスクリプト、自動化を組み上げたあとは、1.5～2人分、自動化のスクリプトが動く想定になりますので、そこからはその分が減っていくという計算になります。

弊社側からも高橋さんにお伺いしたいのですが、導入して失敗したなと思ったことはございますか？

高橋：
導入して失敗した点は特にないですね。もちろん運用に乗せるのは結構大変だと思いましたけれど、慣れてくれば、テストは成功していますし、失敗したなということはないですね。ただ、運用までいくのが大変だとは思います。

質問②

『自動化とは関係ないのですが、仕様の洗い出しについてお聞きしたいです。ざっくりとした仕様でつくられた部分が不安定で早期にテスト導入しないとまずいとなった場合に、急がば回れで仕様を固めてからテストをしたほうがいいのでしょうか？』

桑野
そうですね、ゲームのテストだとなかなか仕様が固まらないけどある程度機能ができたところからテストを走らせたりするじゃないですか。そういうことだと思うのですが、これはやはりケースバイケースでしょうか。ボルテージさんの場合はいかがですか？仕様が固まってからテストに入ることが多いですか？

高橋様：
いや、そんなこともないかもしれないですね。ある程度ざっくりした仕様がきてというのがほとんどのケースなので、そこからあらかじめテスト設計しだすこともあると思います。

大きな機能を作るとき、弊社だとアジャイル開発といいまして少しずつ少しずつ作っていくというのがありますので、ざっくりとした仕様の部分を、まずは大きな機能を作って少しテストして、だんだん雪だるま式に増やしていって、最後完璧なテストをするみたいな。テストをちょくちょく入れていくことはあると思います。

桑野：
ありがとうございます。仲さんにも伺いたいのですが、ゲームのテストの場合、がっちり仕様があって全部最初からテスト仕様書を作れてそのままきれいにいくってないと思うんですよ。やはり、できているところから触っていきましょうとなるので、いきなり全部テスト項目を作れるかというと、そうではないケースの方が多いですよね。

仲：
はい。今に近い相談を受けることもあって、仕様は決まっていないけれど時間は迫ってきているので、とりあえず根幹の部分、いわゆるシステムに関わる部分や、クライアントシステムに関わる部分は検証してほしいというのと、あわせて決まっていない部分を1回見て欲しいというお話が来るので。

弊社のテスターが通常のテスト以外にレビュー観点でテストも行うので、テスター目線でこういう仕様になっていたけどこうじゃない方がいいかもしれないという提案ベースの成果物も提出するような形もできるので、後ろのスケジュールに合わせて変わってくるかなと思います。

桑野：
なるほど。やはり状況に合わせて柔軟に対応できるようにはなっているということですよね。

仲：
そうですね。今の状態だとこういう状態でしたという報告と、それに対してのテスター側の所感みたいなものをつけて報告をして、後ろのスケジュールと合わせてどうするか決めていただくという提案はできるかと思います。

桑野：
ボルテージさんもそういう思想で、ソフトウェアテストのノウハウを用いてやられていますが、ソフトウェアテストのノウハウに忠実にやると、しっかり最初の仕様書があってそこからドキュメントを作ってそこから実行してというのが本来の流れじゃないですか。

それ通りにやっていると、いつまで経ってもできなくて、お客様から「ずっとテスト項目を作っているけどいつテストが始まるの」みたいなことを言われることも結構ありました。

この3年やらせていただく中でどんどん変わってきていて、試行錯誤して結構柔軟に対応できるようになってきたのかなというのを今の話を聞いて思いました。

質問③

『自動化の提案をエンジニアさんへ行う際、自動化の開発工数と削減効果が見合わなさそうで提案止まりになってしまうことがあるのですが、そういう場合もありますか。そういう場合はやはり開発を行うような結論になりますか』

桑野：
これは見極めが非常に難しいですよね。やってみないとわからないじゃないですか。高橋さんは撤退ラインって決めていたのでしょうか。

高橋様：
撤退ラインはある程度決めていました。ここまでいって削減できなくてコストに見合わなかったら、あくまで検証導入っていう形も、本導入に向けていくのは当然だったのですが、コストに見合うかどうかを判断するためにある程度スケジュールは見ていました。

桑野：
そうですよね。実際テスト自動化から入ると、やってみないと分からないので、コストをかけてやってダメだったら、それでできないという決断になってその会社では先に進まないということになったりするので、実は弊社はそういったことを防ぐために、最初に自動化を提案することはしないんですよね。普通にテストを依頼していただいて人力でやり、その中からテストできそうなことを試しに動かしてみて、いけそうだったら提案するというやり方をしています。割と弊社の中でコストを持つので、お客様からするとゼロは言い過ぎなのですが、通常のテストの人員分だけでおまけで自動化がついてくるという感覚でできるので、失敗しにくいやり方をしています。ハードルを下げているということですね。

やろうとしたけど、実際に難しくてできなかったこともありますよね、仲さん。

仲：
はい、恐らくそちらの方が多かったです。できてはいるのですが、お客様の求めるクオリティに達してないとか、思った以上にお客様側がもっとコスト削減を狙っていたとか、そういった意味で導入見送りとなったケースは結構多いですね。

桑野：
ありますよね、期待値が高過ぎてしまって合わない場合もあるし、コンテンツ自体がアクション性が高くて自動化に向いてない、そもそも人でやった方が早い場合もありますよね。

ですので弊社では、ずっと繰り返し長いことやっていて、人じゃなくてもいい部分をなるべく自動化にして、通常は人でやるということで、『人が主導してAIが補う』という言い方をしているんですけど、いきなりハードルを上げて『できませんでした』ではなく、じわじわ攻めていくというアプローチを普段はしています。

ご質問ありがとうございました。
では、最後に一言ずつお願いします。

仲：
今自動化のお話させていただいて、現状メインで対応できているのがスマートフォンアプリになっていまして、とはいえコンシューマーが徐々に元気になってきているので、そういった部分にも広げていきたいと思っています。近々恐らくSwitchに対応できるようになるのではないかと思います。そういった形でゲーム全般、ゆくゆくは自動化を自動で作れるみたいなところまでいけたら、もう少しいろいろなことができるのではないかと思っているので、これから先もそういった部分を追求していけたらと思っております。

桑野：
乞うご期待ですね。ありがとうございます。高橋さんも最後にお願いします。

高橋様：
今回の発表が、こういうところに自動化テスト入れられるという契機に少しでもなるといいなと思います。テスト自動化っていうのはどんどん広まっていくと思いますので、そのあたりもAIQVE ONEさんと一緒にいろいろなところに入れていけたらなと思っております。本日はありがとうございました。

桑野：
ありがとうございました。それでは高橋さん、長い時間お話いただいてありがとうございました。仲さんもありがとうございました。みなさんも今日聞いていただきありがとうございました。