2026-06-03

EVEN G2を体験してきた——ARメガネが"実用"に届く日と、その先にある壁

概要

ARメガネ型スマートグラス「EVEN G2」を体験してきました。過去のARデバイスと比べて何が変わったのか、翻訳・文字起こし機能の実力はどうか、そしてデバイスが進化しても残る「人間側の壁」について、体験ベースで書いていきます。 ※しゃべった内容をまとめてもらう事をAIに任せていますが、最終的な出力した文章には、人の確認等はして、修正しております。

時間ない人向け要約

EVEN G2はメガネ単体で動作するARスマートグラス。有線接続もスマホ必須もなく、過去のデバイスから大きく進化している
文字起こし精度はPixcelスマホのレコーダーとほぼ同等。翻訳もリアルタイムに近いが、会話のテンポには追いつかない
表示色は緑系統のみ。エンタメ用途には不向きだが、プレゼンのカンペやビジネス補助には十分実用的
AI時代の「判断を外部に任せる」流れとARメガネは相性が良く、カンニングペーパー的な使い方は近い将来普及しそう
デバイスがどれだけ進化しても、人間側のマルチタスク能力や認知速度に限界があり、そこが次の格差になる

過去のARメガネとの比較——EVEN G2で何が変わったか

大阪にあるメガネ・サングラス専門店に体験できる場所があったので、実際に触ってきました。

率直な感想として、「ようやく理想に近い形のARメガネになったな」というのが第一印象です。

過去に体験した装着型のARデバイスを振り返ると、ゴーグル型のものはデカくて重くてVRヘッドセットとあまり変わらない見た目だったし、メガネ型になったものもスマホとの有線接続やコントローラーが必須で、使い勝手にかなり制限がありました。

EVEN G2はそのあたりが一気に解消されています。メガネ単体で独立して動作し、操作はツルの先端部分で行える。スマホはあくまで補助的な位置づけです。日常的にかけていても違和感の少ない見た目で、文字もはっきり読める。「電脳コイル」に出てくるARグラスの世界観にかなり近づいたなと感じました。

体験した機能：文字起こしと翻訳

今回体験したのは、文字起こし機能と翻訳機能の2つです。

文字起こしについては、Pixcelに搭載されているレコーダー機能とほぼ同等の精度でした。一部、文字の認識がうまくいっていない箇所はあったものの、意味は通じるレベルでした。アイデアをパッとメモしておきたいときには、スマホより手軽に使える場面が出てきそうです。

翻訳機能については、翻訳アプリ相当の精度で、リアルタイムに近い簡易翻訳ができていました。翻訳者を入れるよりちょっと早いくらいのスピード感で、英語が読める人にとっては実用的な水準に感じます。

ただし、リアルタイムの会話に使えるかというと、まだ厳しいというのが正直な感想です。理由は3つの時間の壁があるためどうしても会話のテンポ感としては落ちてしまうためです。

機械側の壁：翻訳処理そのものにかかる時間
表示側の壁：翻訳結果がメガネに表示されるまでの時間
人間側の壁：表示された文字を読んで内容を理解し、それを言葉にして返すまでの認知プロセスにかかる時間

自然な会話は1秒未満のテンポで進行します。この3つの壁の遅延が重なることで、そのテンポを維持するのは現時点ではかなり難しいように感じました。翻訳アプリを手で操作するよりは確実に速いけれど、「ARメガネをかけていれば外国語の会話がスムーズにできる」という段階にはまだ到達していないように感じています。

表示の制約とその中で出来る事

技術的な制約だと思うのですが、表示色が明るい緑しか表示できませんでした。色の幅も限られていて、イメージとしてはゲームボーイ時代の液晶に近い出力です。

この制約があるため、映像コンテンツやゲームのような体験型の用途には現状では向いていません。

また、視界にコンテンツを表示し続ける使い方は「歩きスマホ」と同じ問題を引き起こす可能性もあります。逆に言えば、テキストベースの情報を表示する用途——プレゼンのカンペ、会議中のメモ、ちょっとした翻訳——にはすでに十分な実用性があります。必要な情報を、必要なタイミングで、周囲にバレずに確認できる。メガネ型デバイスの最大の強みはまさにこの「さりげない情報拡張」にあり、そこに関してはもう望ましいレベルに到達していると感じました。

サポートが手軽に行われている日常

体験していて、思い出したのが、「世にも奇妙な物語」で放送されていた、スマートグラスを使って恋愛を最適解で進めていくというエピソードです。

正直、あれに近いことはもうできるんじゃないかと感じています。テンポの速い会話ではまだ厳しいけれど、選択を迫られる場面や、少し考える時間がある場面であれば、メガネに表示されたカンニングペーパーを見ながら最適解を選ぶためのサポートがされ続けることは技術的に可能なように思えました。

そして、以前AIとの付き合い方について考えたこととも重なるのですが、今のAI時代において判断をAIに任せる人は確実に増えていくと私は考えています。 ARメガネによる「リアルタイムの判断補助」は、その延長線上にある技術です。判断を外部にゆだねるというハードルは、今の時点で下がっている以上、こうしたデバイスの受け入れもすんなり進むのではないかと思っています。

デバイスが進化しても、人間側にあるボトルネック

仮にEVEN G2の後継機が出て、色の制約がなくなり、翻訳の精度もさらに上がったとしましょう。それでも残るボトルネックがあります。それは、人間側の認知処理の限界です。

ARメガネを使いこなすには、かなり高度なマルチタスクが求めるのではないか？と私は想像しています。例えば、恋愛を補助するためのものを使用しようとすると、

メガネに表示された文字を見る。
内容を確認する。
話す内容を決める。
実際に言葉として発する。

といった事をこれらをほぼ同時に、そして会話の流れを止めずにやらなければならない。それらが出来れば問題はないですが、使いこなす上では、どうしても人間側のボトルネックがあるように感じます。

こうしたデバイスが普及したとき、使いこなせる人と使いこなせない人の間に格差が生まれるのは避けられません。それは、ChatGPTを単純に使っている人と、カスタマイズして拡張的に使っている人の間にすでに大きな差がある構造と同じです。 ARメガネ、AI、その他の新しいツール——それぞれの領域で格差が積み重なっていく。これは今回のARメガネに限った話ではなく、新しい技術が登場するたびに繰り返されてきたことでもあるように感じます。

まとめ：夢はあるが、人に求められるハードルも上がっていく

EVEN G2は、ARメガネが「未来のガジェット」から「実用的な道具」に一歩踏み出したデバイスだと感じました。日常的な見た目で、さりげなく情報を拡張できる。その体験には確かに夢があります。

ただ、技術の恩恵とともに、新たな制約や危険性は必ず生まれる。便利になった分だけ、それを前提とした基準が新しい「普通」になり、求められるハードルは静かに上がっていきます。変化のスピードが速くなっている分、適応の猶予も短い。だからこそ、どの技術をどこまで取り入れ、どこは自分の力で踏ん張るのか——その線引きを意識的に持ち続けることが、これからますます大事になるのだろうなと思います。

2026-05-23

AIで何でも作れる時代に、どのようにふるまっていくのが良いのか？

AI 考察技術

概要

AIを使えば、プログラミングもデザインも詳しくなくても「それっぽいもの」が作れてしまう時代になりました。個人開発者やクリエイターにとって、これは間違いなく追い風です。でも、その便利さに身を任せ続けた先で、自分の中から何が失われていくのか——この記事では、AIとの付き合い方について、実感ベースで考えたことを書いていきます。 ※しゃべった内容をまとめてもらう事をAIに任せていますが、最終的な出力した文章には、人の確認等はして、修正しております。

時間ない人向け要約

AIによる「プロトタイプの民主化」は確実に起きている。誰でも簡単にそれっぽいものが作れる
一方で、経験がないと「何がリスクか」を認知できないまま成果物を出してしまう問題がある
AIの出力を確認する作業は、プログラマーが行っている仕事のコードレビューに似ている。ただ、認知コストが高く、「動いてるからよし」となる事が多いように、それと似たことは起きている。
AI出力に責任を持たない振る舞いは、チームや買い手からの信頼を確実に削る
AIが中間レベルの成果物を出せるようになったことで、そこに至るまでの「学習の過程」を人間が経験しずらくなる
どこをAIに任せ、どこを自分でやるかの線引きを、意識的に持ち続けることが大事

「誰でも作れる」は本当に起きている

「こういうアプリが欲しい」「こんなギミックを作りたい」——そう思ったときに、プログラミングの深い知識がなくても、AIに指示を出せばそれなりのものが出てくる。これはもう現実の話です。

個人開発者やVRChatのワールド制作者、Boothで商品を出しているクリエイターにとって、この変化は大きな恩恵です。プロトタイプを作るハードルが劇的に下がり、「何か始める」ことがかつてないほど簡単になりました。

ただし、ここで1つ見落としやすいことがあります。簡単に作れるようになったことと、そこに潜むリスクを見抜けるようになったことは、まったく別の話だということです。開発経験のある人なら「ここは気をつけなきゃ」と自然に感じるポイントを、経験がなければそもそも認知すらできない。リスクの存在に気づかないまま、結果だけを世に出してしまう。これが、民主化の裏側で静かに広がっている問題です。

便利さの裏で起きている「判断の外注」

AIを使って開発していると、ある種の「判断疲れ」に直面します。

AIは大量のコードや成果物を一気に出力してくれます。でも、それを確認する作業は、かなりの認知コストを伴います。自分でゼロから書いている場合は、思考の流れが連続しているので、コードの意図や構造が頭に入っています。しかしAIの出力を見るときは、他人が書いたコードをレビューするのと同じ負荷がかかる。量も多いし、文脈を把握するところから始めなければならない。

結果として「まあ、動いてるからいいか」という判断に流されやすくなります。

さらに厄介なのが、許可の反復による感覚の麻痺です。AIに何かを任せるとき、最初は「本当に大丈夫かな」と慎重に確認します。でも、何度もやっていると「前も大丈夫だったし」と、だんだんチェックが雑になる。心理学でいう「フット・イン・ザ・ドア」に近い現象で、一度OKを出したものに対して、次も深く考えずにOKを出してしまう。気づいたら、渡してはいけない権限や情報まで渡していた、ということが起こりえます。

個人で使う分にはリスクの範囲も限定的です。でも、この感覚のまま商品として世に出したり、チームの成果物として提出したりすると、話は変わってきます。

作れることと、責任を持てることは違う

AIが出力したものを自分の成果物としてチームに持ち込んだり、商品として販売したりする。その行為自体は問題ありません。問題になるのは、そこに責任を持たない姿勢です。

たとえば、AIが生成したコードにバグがあったとき、「AIが作ったものだから」と開き直るような振る舞いをしたらどうでしょう？チームメンバーやお客さんからの信頼は確実に下がります。ツールが何であれ、自分の名前で出したものには自分が責任を持つ。これは、AIが登場する前から変わらない原則です。

逆にいえば、今後ますます価値を持つのは「誠実さに基づいた振る舞い」だと感じています。 AIによってアウトプットの質が均質化していく中で、差がつくのは成果物そのものよりも、その裏にある姿勢や信頼性の部分です。自分が出したものの品質に対して、きちんと向き合えるかどうか。ここが、個人開発者やクリエイターとしての価値を左右するポイントになっていくはずです。

AIが奪う「中間の学習機会」

もう1つ、じわじわと効いてくる問題があります。それは、学習機会の喪失です。

AIは、ある程度のレベルの成果物をいきなり出力できます。これは便利ですが、裏を返せば「そのレベルに到達するまでの試行錯誤を、人間が経験しなくなる」ということでもあります。

プログラミングにしろデザインにしろ、中間レベルの技術は、失敗と改善を繰り返す中で身につくものです。でもAIが最初からそのレベルを出してしまうと、そこに至るプロセスを通らずに結果だけを手にすることになる。下駄を履いた状態でスタート地点に立っているようなもので、下駄を外されたときに自分の足で立てるかどうかが怪しくなります。

加えて、現代はYouTubeのショート動画のように、努力なしでドーパミンが得られるコンテンツが溢れています。そんな環境の中で、地道に学習を継続する力を保つのは、以前よりずっと大変になっています。

20年後には「AIネイティブ」と呼べる世代が出てくるでしょう。小学生の頃からAIを道具として使うのが当たり前の世代です。そのとき、自分の努力で継続して学べる力を持っているかどうか。そして、その重要性を伝えられる指導者がどれだけいるか。これは、個人のスキルの問題であると同時に、社会全体の課題でもあります。

どこをAIに任せ、どこを自分でやるか

ここまでリスクばかり書いてきましたが、AI自体が悪いわけではありません。補助的に使う分には非常に強力なツールです。文章の誤字脱字チェック、簡単なコードの雛形生成、アイデアの壁打ち——こういった用途では、AIの精度は十分に高く、積極的に頼るべきです。

大事なのは、「どこを任せて、どこを自分でやるか」の線引きを意識的に持つことです。

その線引きの精度を上げるために重要になるのが、プロンプトの言語化能力とAI出力の評価力です。どんな出力を求めているのか、入力に不足があるとしたら何か、AIに聞き返させるべきポイントはどこか——こうした定義をしっかり行えるかどうかで、AIの出力品質は大きく変わります。これは今後、クリエイターにとってのベーシックスキルになっていくでしょう。

そしてもう1つ。AIに任せる領域を増やすほど、判断をする「筋肉」は使われなくなります。楽ができる分、その筋肉は衰えていく。だからこそ、定期的に「今の自分はどういう状態か」を振り返る習慣が必要です。AIがいないと判断できない、という状態にならないために。

結論：10年後の自分を想像して付き合う

AIとの付き合い方のベストプラクティスは、まだ誰にもわかりません。おそらく、今の施策の結果が見えてくるのが5年後、本当の意味での最適解が見つかるのは10〜15年後ではないかと思っています。

だからこそ、今の時点でできることは、長期的な視点を持つことです。目の前の便利さだけに飛びつくのではなく、「これを続けた先で、自分はどういう状態になっているか」を想像する。AIに任せた分だけ、自分のどの筋肉が衰えていくのかを意識する。

AIは、使い方次第で最高の道具にも、静かな毒にもなります。その境界線を自分で引き続けること。それが、個人開発者やクリエイターとしてAI時代を生き抜くための、大事なことだと考えています。

2024-01-07

VRChatでコントローラーのスティック入力を取得する方法

VRC VRC Udon + U# VRChat

対象

コントローラーのスティック入力を取得して色々したいなと思った人

例えば、移動の入力をドローンなどの操作の移動に変更するといったもの

検証環境

Unity2019.4.31f1 VRChatSDK-World　3.4.0 VRChatSDK-Base　3.4.0

やり方

UdonSharpBehaviorを継承して、以下のメソッドを追加する

InputMoveHorizontal
InputMoveVertical

具体的には以下の通り

public class VRCSample : UdonSharpBehaviour
{
       //水平方向の入力を受け取る
       public override void InputMoveHorizontal(float value, VRC.Udon.Common.UdonInputEventArgs args)
       {
  　  }
        
        //垂直方向の入力を受け取る
        public override void InputMoveVertical(float value, VRC.Udon.Common.UdonInputEventArgs args)
        {
        
        }
}

これらのメソッドに関しては、DeskTop、VR共にさほど変化はなく Horizontalの場合は、左移動の時は、負の数値、右移動の時は、正の数値が入力される Desktopの際は、-1,0,1と入力が返されるが、VRの場合は-0.99 ~ ,0,~0.99が返却される。

Verticalは前後移動の際に同様の数値が返却され、前方向は正の数値、後ろ方向は負の数値が返却される。

参考

udonsharp.docs.vrchat.com

2022-11-01

プレイヤーの中から、誰か一人を対象とした処理を行うやり方

VRC

概要

この記事は、Prestoniaさんが作ったワールドで使われている誰か一人のユーザーを取得する方法についての記事です。

ワールドはこちらからホラワホームワールド -Japanese horror house- by Prestonia #VRChat #MadeWithVRChat

vrchat.com

この記事を読む事で、以下の内容を知る事が出来ます。 - 全員のプレイヤーの中から、一人を抽出する方法 - その対象の人に対して何かを行う方法

開発環境

Unity2019.4.31f1 VRCSDK3-WORLD-2022.04.20 16.26 U# v0.20

実際に行う事

ざっくり行う事としては、2つです。

プレイヤーIdの保持
プレイヤーIdから、特定のプレイヤーのみの処理を行う。

プレイヤーIdの保持

VRCではプレイヤーにプレイヤーIdが存在しています。このプレイヤーIdはVRCPlayerApiから取得できます。

OnPlayerJoinと、OnPlayerLeftという関数がVRC側から提供されておりPlayerがJoin/Leftのタイミングで、以下のようなコードでVRCPlayerApi取得する事が出来ます。

public override void OnPlayerJoined(VRCPlayerApi player)
{
    //ここに処理を記述する
}


public override void OnPlayerLeft(VRCPlayerApi player)
{
    //ここに処理を記述する。
}

この時に、このIdを情報として保持しておく事で、現在存在するプレイヤーの一覧が事実上取得が可能になります。

プレイヤーIdから、特定のプレイヤーのみの処理を行う。

保持さえすれば、あとはやる事としては3つです。 1. ランダムで対象を選ぶ 2. したい処理を全体で行う 3. 選ばれたプレイヤー以外は処理しないようにする

1 ランダムで対象を選ぶ

UnityEngine.Random.Rangeで保存しているプレイヤーIdから、どれかを選択します。この時、選ばれたものをUdonSync属性のついた変数に保存します。

2 したい処理を全体で行う

全体を行うというのは、SendCustomNetworkEventで、共通の引数なしの関数を呼び出しの事を指します。

3 選ばれたプレイヤー以外は処理しないようにする

2で呼びだした関数の処理内で、Networking.LocalPlayerでその選ばれたプレイヤーのIdの人かどうかを判断して、同じ人物だった場合処理を行い、そうでない場合は処理をしないようにします。

2022-06-18

VRCSDK3　同期周りを調べてみた

VRC Udon VRC Udon + U#

概要

VRCSDK3とU#を使用した同期関係をまとめた記事です。

主に以下の内容について、本記事では記述しています。 - 同期のタイミング - UdonBehaviorのSynchronizationMethodの設定によるそれぞれの影響 - 設定による[UdonSync]の変数の挙動 - 違う設定のGameObject間での同期の影響について - Joinなどの挙動

確認環境

Unity2019.4.31f1
VRCSDK 2022.04.20.16.26
U# v0.20.3

必要な知識

関数がわかる人
同期の仕組みが、基本的にはOwner基準で同期されるという事がわかっている事。

同期とは？

同期とは？そもそもなんなのでしょうか？同期は、簡単にいうと、他の人と同じ状況にする事です。

VRC内であるのはPickUpのObjectは、同期されているものため、みなさんと同じ位置に持っている物が見えている状態になっています。

そして、同期を行う際に、基本的にはGameObject単位で保持されているOwnerの環境下での状態が同期されます。そのため、対象のGameObjectのOwnerがどの人なのかを把握しておく事が重要です。

同期されるタイミング

同期の形式は大きく分けて2種類の同期があります。 - 変数の同期 - [UdonSync]の同期 - UdonBehavior側のSynchronizationMethod設定に依存 - Continous - オーナーの値を常に同期して他の人とほぼ同じ値を共有する - Manual - RequestSerializeを呼び出した際に値が共有する。 - 関数の同期 - SendCustomNetworkEventによる「動作」が同期

[変数の同期]

変数の同期は、状態を他の人と同様にする際使用します。たとえば、スコアや、ミラーのOnOffなどの状態です。

同期のしたい変数は[UdonSync]をつける事で同期され、インスタンスに途中から入ってきた人に対して同様の値を通知します。

同期されるタイミングは、基本的には、UdonBehavior側のSynchronizationMethodの設定によって変化します。

Continuousは、[UdonSync] がついた変数が常に同期されます。正しい値がほぼ確実に入る一方で、常に通信を行っている事になります。

通信が多くなるため、それによる不具合などが発生した際に大幅な改修が要求されます。

Manualは、RequestSerializeを呼び出した任意のタイミングに同期を行います。

常に送るわけではないので、同期頻度によっては、通信を減らす事ができます。

一方で、同期を行うタイミングの管理を行わなければいけないため、工夫が必要です。

[関数の同期]

関数の同期は、全ての人が一緒のタイミングで始める場合に使用します。

SendNetworkCustomEvent（対象、メソッド名）で実行をします。

変数の同期と違って、その場、その時にいる人に対してのみ行われるものです。

なので、これを使ってゲームがスタートしていて、途中から入られたくない場合は、変数の同期と合わせておく必要があります。

同期のパターン

今回調べたパターンと結果はは以下の通りです。 - SynchronizationMethodの設定がContinuousの場合 - 値が常に更新される - SynchronizationMethodの設定がManualの場合 - 呼び出されたタイミングのみ更新される - ContinuousのUdonBehaviorからManualのUdonBehaviorに定義されている関数を直接呼び出す。 - 値が更新されない - ManualのUdonBehaviorから、ContinuousのUdonBehaviorに定義されている関数を直接呼び出す。 - 値が更新される。

ContinuousのUdonBehaviorからManualのUdonBehaviorに定義されている関数をSendCustomEventで呼び出す
- 値が更新されない
ManualのUdonBehaviorから、ContinuousのUdonBehaviorに定義されている関数をSendCustomEventで呼び出す。
- 値が更新される。
ContinuousのUdonBehaviorからManualのUdonBehaviorに定義されている関数をSendCustomNetWorkEventで呼び出す
- 値が更新される
ManualのUdonBehaviorから、ContinuousのUdonBehaviorに定義されている関数をSendCustomEventで呼び出す。
- 値が更新される

- ContinuousのUdonBehaviorDesirializeの挙動

Manual時のRequestSerializeからどれくらいの遅延が起きるものなのか？

まとめ

基本的には、[UdonSync]属性のついている変数が同期対象です。

同期タイミングが、UdonBehaviorのSynchronizationMethodの設定が

Continueの時は常に同期されます。

Manualの時は、RequestSerializeが呼ばれた時に同期されます。

またPlayerJoin時はどちらの設定にも関わらず、[UdonSync]属性がついている変数が同期されます。

2022-02-27

カレイドスペース行ってきたので、ひとまず簡易的なレビューとか

あなた is 誰？

普段とかは、LaMerとかXOasisに行きつつ、VRCとかやりながら色々作ってたり、書いたりする人。基本的には、騒がしいのは苦手なので、1:1とかでのコミュニケーションを好むコミュニケーション苦手勢です。かといって、1:1だからって饒舌になるわけではないので、あくまで多数よりは少数の方が好みだよくらいの認識に思ってもらえるとです。

カレイドスペースis何？どんなサービス

以下HPから引用

カレイドスペースとはバーチャル店舗「カレイドスペース」に所属するキャストと会話を中心としたコミュニケーションが楽しめます。キャストとの対話は2人きりの空間で。ちょっとした雑談から秘密の相談まで、どんなことを話すかはゲストのあなた次第。

あなたとキャストの組み合わせの数だけ生まれ、何度も会いに来ることで積み重なっていく関係性。自分だけの大切な場所をつくりませんか？

使用環境はZoomを使用します。

ゲスト（お客側）は、リアルを表示、非表示、アバターで表示の3つの方法のうち1つの方法で、キャストさんと対面する形になります。表示、非表示に関しては、Zoomの機能として、使う事が出来ます。アバターに関しては、別途ツールなどの使用を行う事で出来ます。

カレイドスペース全体的なざっくりな印象

予約を行う際に、ハンドルネーム＋メールアドレス＋TwitterIdを入力する必要があるのですが TwitterIdを入力を行うだけあって、キャストさん自身が入力したTwietterIdの内容とかを事前に見に来てくれてたりします。ただ、この辺はキャストさんの裁量による部分なので、全体を通してみているというよりは、だいたい今回きてくれるお客さんはどんな人かなの把握とかを軽くやっているような感じの印象です。 30分程度だったら自己紹介とか＋話題ふりとかをお互いにやったら一瞬で時間が過ぎていくので、慣れていない人も恐らく問題がない感じです。

あと個人的に思っていたのが、視線が常に絶妙に合わない問題があると思いました。例えば、Webカメラを見ると映っている自分の視点とかは正しいのだけど、こちらから相手が見えない。これはWebカメラが、画面より外側に配置されているため、起きる問題です。逆に画面をみるとカメラから見た時のこちらの視点が正面見ている感じにはならない。

セッション

1.Zoomで待機（ビデオOnOffでも良い、アバターで動作する人もいる。） 2.時間になったら、相手側から参加が許可されるのでそこからビデオ通話が開始されます。 3.時間いっぱいしゃべります。 4.いい感じの区切りとかのタイミングで、キャスト側からそろそろ時間ですねーみたいな事言われるか何かするので、最終的にゲスト側がZoomの退出ボタンを押して退出するスタイル。

Zoomとかを使用する上での良さ

良さ

個人的には、チャットとかを使えるとかが結構使おうと思えば使える感じのイメージがある。例えば、動画のURLも共有できるし、なんなら画面共有とかで何かを一緒にみるっていうのはすごく楽にできるので、その辺の使い道とかをもうちょっと活用する手はあるんじゃないかな？と思った。

特にYouTubeで～～見ているとかおすすめとかの場合は、URLを貼るとかを行えて、共有を容易に行いやすい。ただ、この辺のやり取りを行う時に、チャットをみるとかを慣れていない場合もあるので、一言を付け加えたりすると対応してくれたりします。

Zoomでの対面とかで感じたこと

Zoomの参加方法として 1. リアルアバターで参加 2. こちらの映像なしで参加 3. ツールなどを使用して、参加の3種類存在していますが、個人的な感想としては、2が基本的な選択肢になるのかな？って思いました。

1の場合は、容姿のコンプレックスによる抵抗や最低限の身支度などが必要が出てきたりするし 3の場合は、ツールの使用が必須なわけですから、よほどZoomをアバターで普段から使っているとかでない限りは、ツールを使用するためのの学習コストが大なり小なりはあるわけです。

今回私は、1のリアルアバターによる参加を2回行ってきましたが、会話開始するまでちょっとした心理的な負担はありましたし、身なり面で、髭を沿ったり、髪を手でとかすくらいには身支度をしたりはしました。結構自分自身がめんどくさがり屋なので、この辺はすごく大きなハードルの一種です。それに世間的にもコロナで外に出ない人も多くはなってきているので、この辺はハードルがこれまでより高いイメージです。それもあってか、キャストさんによるとリアルのアバターで対面するのは基本的には少ないそうです。実際聞いた話だと、ビデオオフの状態と、アバターでの参加が割合的に多いそうです。

ただ、その中でどうしてリアルアバター選んだかというと、理由は単純な事でキャストさんとのコミュニケーションのしやすさを重視しました。 VRの場合だと手振りとか、首の動きとかで会話以外の部分などで、相手の反応を見る機会が存在します。しかしながらZoomの場合だと、ビデオがない場合は声だけの場合相手の声色だけで判断せねばならないため、その辺の負担を減らすために行いました。アバターという選択肢もあったのですが、それは今回学習コストの面で選択肢としてはなかったです。あと単純にどれくらいの負担と感じるかとかも興味あったのもあります。

　キャストさんについて

一応どちらも30分程度の短い時間での中での感想なので、推測などが入っている部分もあります。というか30分程度だとぼんやり像がわかるかわからないかくらいですかね？

小紫ふうさん

以下自己紹介動画 https://youtu.be/5BzkCMQQWgQ

30分での印象

結構おっとりな感じの印象。緊張していたからかはわからないが、ドジっ子の属性とかある？っていうそんな感じあぶなっかしさはある感じがかわいいのかなと思いました。

塩見らいちさん

以下自己紹介動画 https://youtu.be/5jY_KaI_KW0

30分での印象

そこそこに落ち着いている印象の中に、ちゃんと相手の事を気にかけて会話とかを投げてくれる感じの気回しがうまい感じなのかなと思いました。

2022-01-22

期間限定"お砂糖"「錯花林」を体験してきた

VRC 体験談

錯花林とは

らいずさん(@_mumumu)が行っている期間限定でお砂糖っぽい事を行おうといったもの。日付を決めて、その期間を一時的なお砂糖相手として、過ごすといったもの。 1日or3日の日程を、ある程度まとまった期間の日程に調整して、その期間を過ごすもの。

詳細は以下のTweetから https://twitter.com/_mumumu/status/1455417334445731843?s=20

今回偽糖してもらった相手

今回相手してもらったのは、Lminaさん。相手をお願いした理由というのはいくつかあって

話のテンポ感が比較的にゆっくりだった。（テンポが早すぎると、私があわあわしちゃうので）
落ち着いた声だった。（声大事！）
話のキャッチボールがしやすい相手だと思った。（私もときどきはしゃべりたいので）

実際体験した感じどうだったか？

すっごく良い3日間を過ごす事ができました。

これの一言に本当に尽きている感じで、相手にも伝えたのですが、本当に最初の偽糖の相手でよかったなっていう感じです。

あくまでも個人談ですが、恋人っぽい事をたくさんした気がするし、お互いに好意的な気持ちを、何かしらの表現で送りあっている状態ってすっごく心地いいなっていう感じです。

すっごいほわほわする感じだし、精神的な満たされはありました。

準備期間でのやりとりとかで感じた事とか。

私の場合、偽糖を決めた時期が、12月の末でした。決めた相手と3日間の予定を合わせた結果、決まってから始まるまで、1か月ほどの期間がありました。

会話の中身とかは見せられないので、具体的な想像とかはすごくしずらいかもしれないですが、

定期的なあいさつとかを送ってくれる
提案した事に対して、ちゃんと返信をくれる

この辺とかが、私にとってはすごく嬉しくて、楽しい部分とかでもありました。定期的なおはよーとかは意外とそこからの会話のきっかけになってたりしてました。たとえば、天気の話、気温の話とか、今どうしてるみたいな感じから始まって、さらにそこから深堀りした感じとかをとてもしやすかったです。

Discordなどのテキストベースの会話においては、私の価値観が「何か用事がないと相手に迷惑をかけてしまう」っていうのが常に頭の中にあって、本当に送って大丈夫かな？めんどくさくない？みたいな事がどうしても考えてしまって、自分からメッセージとか書けないので、こういった相手から定期的なものとしても送られてくるのはすごく会話しやすかったです。数日もそれらの日々が過ぎる頃には、相手からメッセージが届くのを楽しみになっていたりしました。

準備期間中もなんだかんだで、年明けに私が寂しくなっているタイミングで、相手が起きていたので、ちょっと通話してもらったり。

なんだかんだで総じて、偽糖みたいな感じのやりとりとかを行っているような感じがして、少しこうむずむずーみたいな感じながらやり取りしてたりしてました。

準備期間にやっておいてよかった・やっておけばよかったとか

やっておいてよかった

あくまで、個人的な感想ではあるものの、やっておいてよかったなぁと思った内容ですが - 偽糖プロフィール帳

偽糖プロフィール帳

みなさんは小学生の時に、プロフィール帳なるものに触れたことはありますか？プロフィールを埋めて、相手の意外な一面をしったり、秘密とか書いたりするあれです。すごく知れるきっかけ作りにも使えるし、振り返りの際に、後から見れるのもいいですよね。なお、私は、書いたことも触れたこともありませんでしたが、楽しいものだったんですよね？その辺の雰囲気も知りたかったので、相手の方にお願いして書いてもらったりしてました。

もちろん自分も書いて、どんな事書くのかな？みたいな事思いながら結構楽しかったです。

実際に使ったプロフィール帳っぽい項目とかは以下の通りです

名前：
職業（専攻）：
好きな食べ物：
嫌いな食べ物：
趣味：
寒いのと暑いのどっちが好き？：
休みの日何してる？：
得意な事（好きな事）：
苦手な事（嫌いな事）：
人におすすめしたい事：
こだわりのある事：
実はこう見えて、、、：
甘えたい時：
どんな甘やされ方が好き？：
偽糖中にしてみたい事（3つくらい）：
・
・
・

序盤とかは、適当に「プロフィール帳　項目」とかで検索してでてきたものを使いました。後半3つくらいは、この偽糖のために合わせてどんな感じとかしたいのか？されたいのかを知る為に作った個人的に作った項目です。

実際に、期間中に過ごす方針とか、どんな過ごし方、ワールドの巡り方とかを決める時には、便利な項目だったように感じました。人によっては、行ってみたいワールドとかの項目とかはあったらなおいい感じになったりはしたかもしれませんね。

また甘えたい時とかは、自分・相手がどちらも甘えたい感じの雰囲気があったので、それらをしてほしい素振りをわかるように補助する形であったのはよかったんじゃないかなと思いました。