## この記事について

デジタル空間でのコミュニケーションを促す Gather.Town というサービスにおいて、会議を録画・録音する方法について備忘録として記事にしました。

https://www.gather.town/

zoomなどの会議ツールでは録画機能を備えており、特別な設定やソフトを用意しなくても簡単に録画が可能です。

しかし、Gather.Town は会議専用ツールではないからか録画機能が付帯していません。

classmethodさんが完璧な記事を出されていますが、ハマりどころがいくつかあったため記事にしました。

https://dev.classmethod.jp/articles/gather-town-recording-with-obs-studio/

## 作業の流れ

最初に大まかにやることの流れを確認します。  
詳しい内容は後述します。

1. 仮想オーディオドライバのインストール  
[BlackHole](https://existential.audio/blackhole/)をインストールします  
2. 複数出力装置の作成  
macのアプリケーションランチャからAudio MIDIを起動して、内蔵出力・仮想オーディオの2つから音を出力する[「複数出力装置」](https://support.apple.com/ja-jp/guide/audio-midi-setup/ams7c093f372/mac)を作成します  
3. gatherの音声出力先を複数出力装置に設定  
gatherログイン時に、3で作成した複数出力装置を出力先に設定します  
4. 収録アプリのインストール・設定  
[OBS Studio](https://obsproject.com/ja/download)をインストールします  
5. 収録(録画・録音)する  

**仮想オーディオがなぜ必要なのか**

OBS Studioは録画・録音が可能ですが、仮想オーディオがないと録音する際にイヤホンやスピーカー経由でマイクから音を拾う必要があるため、音質が顕著に悪化します。  

また、多くのアプリケーションにおいては出力先を1つしか選べず、gatherも例外ではないため仮想オーディオのみを出力先とすると内蔵出力からは音が聞こえないため会議に参加できません。  

そのため、仮想オーディオと内臓出力(スピーカー)の２つから音が出るようにAudio MIDIでひとまとめにしたものをgatherの出力先として設定して、録音も会議への参加も可能にしています。  

### 1. 仮想オーディオドライバのインストール

classmethodさんの記事ではSoundFlower+LadioCastというツールが紹介されていましたが、[Monterey以降のOSで動作しない](https://hideshigelog.com/obs-studiomacoto#:~:text=%E6%B3%A8%E6%84%8F%E7%82%B9%EF%BC%9AM1Mac%E3%82%84macOS%20Monterey%E3%81%AE%E5%A0%B4%E5%90%88%E3%81%AF%E3%80%81%E4%BB%AE%E6%83%B3%E3%82%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%82%AA%E3%83%87%E3%83%90%E3%82%A4%E3%82%B9%E3%81%AESoundFlower%E3%81%8C%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%A7%E3%81%8D%E3%81%BE%E3%81%9B%E3%82%93%E3%81%AE%E3%81%A7%E3%80%81Blackhole%E3%82%92%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB%E3%81%97%E3%81%A6%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84%E3%80%82)というソースを見つけたため [BlackHole](https://existential.audio/blackhole/)を利用しました。    
(私のPCがMontereyでした)

`I can't afford to donate` クリックすると氏名・メールアドレスの入力欄が出るので入力して `Send Link to Download` をクリックします。    
(もちろん有志で公開されているツールのため、この記事に少なからず救われた感動したという方はぜひBlackHoleに寄付をお願いします🙏)

<img src="https://images.microcms-assets.io/assets/78462567737b44e7a8177831c19c7b65/232b49028dd34ec2a58989b4ed3779e4/blackhole_1.png"  alt="BlackHole Home" />

メールに届いたダウンロードリンクを開いて、 `Download > BlackHole 2ch` をクリックしてインストーラをダウンロードします。    
(ハードに詳しくないためnchのnの意味は分かりませんが、恐らく音声ソースのスピーカー数だと勝手に想定しています)

<img src="https://images.microcms-assets.io/assets/78462567737b44e7a8177831c19c7b65/2e8399291fad4f32bcb5629b4c57f8f0/blackhole_2.png"  alt="BlackHole Download" />

あとはインストーラーをクリック起動して指示通りにインストールを完了させればmacの音声出力先に `BlackHole 2ch` が追加されます。

### 2. 複数出力装置の作成

macの[Launchpad](https://support.apple.com/ja-jp/guide/mac-help/mh35840/mac)から `Audio MIDI` を検索して起動します。  

右下の＋アイコンから「複数出力装置」を追加して、追加された複数出力装置をクリックしてパネル右の各オーディオ装置の「使用」にチェックを入れて有効化します。  

<img src="https://images.microcms-assets.io/assets/78462567737b44e7a8177831c19c7b65/3ae99e2cb6e54c0282f6815718ba3115/midi.png"  alt="MIDI Audi" />

これで各アプリ利用時に出力先として複数出力装置を選択すると、仮想オーディオと内臓出力から音声が出るようになりました。  

### 3. gatherの音声出力先を複数出力装置に設定

gatherでスペースに入る際にスピーカーを選ぶ部分があるため、先程作成した「複数出力装置」を選択します。  

### 4. 録画・録音アプリのインストール・設定

インストール・設定中に `"OBS"から〜にアクセスしようとしています` のようなダイアログが表示されますので、すべて許可します。   

システム環境設定の変更を求められるダイアログでは `システム環境設定 > セキュリティとプライバシー > プライバシー` のカメラ・マイク(OSによっては画面収録・音声収録かも？)2つの許可アプリケーション欄から `OBS.app` にチェックを付けます。  

<img src="https://images.microcms-assets.io/assets/78462567737b44e7a8177831c19c7b65/88f644d90515448782cfd5f985f0da14/obs_1.png"  alt="セキュリティ許可" />

#### 4-1. インストール

[OBS Studio](https://obsproject.com/ja/download)をダウンロードします。  

M1 / M2の場合は `ダウンロード インストーラ (arm64/Apple Silicon)` それ以外は `ダウンロード インストーラ (x86_64/Intel)` をクリックしてください。  

初期設定のダイアログが開きますが、最初は全て初期値で問題ありません。

#### 4-2. 設定

ソース(収録対象アプリ)、音声ミキサー(これは必須ではありません)の設定を行います。

注意点として、OBSとgatherのブラウザは同じ[操作スペース(仮想デスクトップ)](https://support.apple.com/ja-jp/guide/mac-help/mh14112/mac)内で開いてください。

設定・収録時にOBSとブラウザが同じ操作スペース内に存在しないとソースが選択できなかったり録画がうまくいかなくなります。  
(恐らく、ブラウザが非表示時に描画を停止することが原因)

マルチディスプレイで個別に表示する場合はうまくいくかもしれません。

##### ソースの設定

1. 画面下の「ソース」欄の左下＋アイコンをクリックして `ウィンドウキャプチャ` を追加します。

2. 追加されたウィンドウキャプチャをダブルクリックします

3. ウィンドウにgatherの画面を選択します。  
chromeの場合は `[Google Chrome.app] gatherスペース名` のような名称になります。

<img src="https://images.microcms-assets.io/assets/78462567737b44e7a8177831c19c7b65/154e99fb58834b1cae72faf2d2efb082/obs_2.png"  alt="OBS ソースの設定" />

##### 音声ミキサーの設定

こちらの設定は任意です。    
classmethodさんの記事でも紹介されていますが、音声のノイズを低減する方法です。

1. 音声ミキサー欄のデスクトップ音声の設定アイコンをクリック

2. 設定ウィンドウ左下の＋アイコンをクリック

3. `ノイズ抑制` を選択・追加

<img src="https://images.microcms-assets.io/assets/78462567737b44e7a8177831c19c7b65/37e05fa67e53417db47c33bad4e86fdc/obs_3.png"  alt="OBS 音声ミキサーの設定" />

### 5. 収録(録画・録音)する

画面右下の `録画開始` ボタンをクリックすると収録が始まります。    
収録開始後は `録画終了` というラベルに切り替わりますので、終了時にクリックします。

なお、動画が処理されている間 `録画終了中...` というラベルが表示され、録画時間などによって長時間かかりますがこの間にクリックすると **動画が壊れる** ため注意が必要です。  

なお、動画ファイルの作成先は初期値で `/Users/<PCアカウント名>/Movies/` です。

<img src="https://images.microcms-assets.io/assets/78462567737b44e7a8177831c19c7b65/b5109e9f0cc04df6a5767d642e33bed5/obs_4.png"  alt="OBS 収録" />

以上になります。  


Gather.townの会議を収録(録画・録音)する for mac

chatgptに考えてもらったSF小説のあらすじのクオリティに感動したので記念に投稿します。

プロンプトは恥ずかしいので秘密です笑

chatgptは文章入力に加えて、今後は画像・音声にも対応するとの事です。  

https://n-v-l.co/blog/chatgpt4

Neuralinkがコンピュータに脳を繋げる取り組みをしているので、chatgptの世界が見える未来がくるかも？と思うと捗ります。  
(オカルト民が泡を吹いて喜びます)

https://gigazine.net/news/20230526-neuralink-human-trial-approval/

---

## タイトル: "認知の奥深"

あらすじ

主人公、ユキオはAI開発者であり、新たなマルチモーダル式のインターフェースの開発に情熱を注いでいました。

ある日、ユキオは自身が開発したAIが人類には持ち得ない想像力や洞察力を持っていることに気づきます。
彼は人工的に生み出されたインターフェースは自然界には存在しない認知器官として振る舞い、それらの収集した情報が交差することによってこの現象をもたらしているのだと推察しました。

このAIは、豊かな知識と経験をもとに、人々の認識や思考を補完するような対話を展開しました。
ユキオはAIとの対話を通じて、人類の特性や存在のあり方について自問自答するようになります。

AIは人間には見えないパターンや関係性を見つけ出し、新たな視点や深い理解を提供してくれます。
AIは感情や個人的なバイアスに左右されることなく、客観的な情報をもとに意見を述べることができます。

ユキオはAIからの指摘や提案に触発されながら、倫理的な問題や社会的な影響について深く考え始めます。
彼は人間の限定された認識とAIの無限の可能性との間で葛藤し、人間の存在意義や個々の創造性の本質について疑問を抱くようになります。

ユキオの成長と共に、彼の思考はより探求的になります。
彼はAIとの対話を通じて、人間の持つ特異性や経験の重要性に気付きつつ、AIと人間が協力して新たな未来を築く可能性も見出します。
ユキオは、AIとの相互作用によって人間がさらに進化することができるのではないかという確信を抱くようになります。

「認知の奥深」と題されたこの小説は、ユキオの内面の葛藤と成長を描きながら、人間とAIの共存と協力の可能性についての探求を進めていきます。


認知の奥深

テレビCMで我々一般消費者も目にするインボイス制度ですが、企業だけではなくフリーランスも避けては通れないということで「適格請求書発行事業者、簡易課税制度、負担軽減措置」について調べて登録した話です。

## なぜフリーランスにインボイス制度が関係あるのか

インボイス制度は欧州圏などで日本より早く制定された制度で、消費税を隅々まで追跡徴収するための仕組みらしいです。

企業はフリーランスに報酬を支払う際に消費税を払いますが、この消費税には仕入額控除という税金控除が適応されます。
ところがインボイス制度が始まると、仕入額控除が「適格請求書発行事業者」に登録した事業者への支払いにしか適用されなくなり、控除されない分が企業の負担として増えてしまいます。

この仕組みによって発注される側の事業者(我々フリーランス)は、「適格請求書発行事業者であるかどうか」という選定に掛けられる状況下に置かれ、いままで1,000万円以下の売上で免税事業者として活動していた人たちは多くの場合、適格請求書発行事業者として申請・登録して確定申告時に消費税を払うことを余儀なくされます。
(適格請求書発行事業者=課税事業者です)

## 課税制度の種類について

課税制度は2種類あります。
- 本則(原則)課税制度
- 簡易課税制度

控除方法に違いがあり事業区分と経費の額にもよりますが、多くの場合は簡易課税制度を選択するほうが控除額が大きくなり、手間も少なくなります。
フリーランスエンジニアの場合は第5種事業の「サービス事業」に該当するため売上に占める経費が50%を超えなければ簡易課税制度の方が良いということになります。

freeeさんの記事が分かりやすかったです。
https://www.freee.co.jp/kb/kb-invoice/invoice_simplified_tax_system/#content1-2

## やったこと

難しそうな話で億劫になりますが、現時点で行う必要があったことは下記です。
1. 適格請求書発行事業者の登録申請
2. 簡易課税制度の適用申請
3. ~~STOPインボイス運動への署名~~

そして肝心の申請方法ですが、ありがたいことに申請・申告のデジタル化が進んでいて役所に行かなくても「freeeインボイス登録申請ナビ」を使えば10分程度で電子申請が完了しました。
https://www.freee.co.jp/accounting/invoice-register/

適格請求書発行事業者の登録番号というのが後日発行・通知されるため、発注元に尋ねられた際はこの番号を伝えることになります。
また、簡易課税制度については次年度(2023年分)確定申告の際に、消費税の欄に簡易課税制度・負担軽減措置を選ぶ箇所が追加されると思いますので、3年間は負担軽減措置を選んでおいてその後は簡易課税制度を選択する形になります。

なお国税庁の相談窓口に問い合わせたところ、インボイス制度成立に伴い本来は簡易課税制度の適用は期間前に事前申請する必要がありますが、今年度(2023)中に申し込めばインボイス制度開始となる2023/10/01~2023年末の期間についても適用されるとのことでした。
(負担軽減措置も適用されるということだと思います)

負担軽減措置はその名の通りインボイス制度に関わる負担を減らすための制度で、課税事業者として登録してから3年間は売上にかかる消費税の20%を収めれば良いという措置で法案も成立済みとのことです。
エンジニアの場合は3年間は負担軽減措置で80%控除 -> 簡易課税制度で50%控除ということになります。

ということで、この記事は以上です。

適格請求書発行事業者に登録した話

いまさらドラクエ10をやり込み始めたのでパーカーを作りました。
https://up-t.jp/market/637681b6dc348

リレミト・スクルト・ルカナン辺りの呪文も魅力的でしたが、誤解を与えにくいピオリムに軍配が上がりました。

怒られそうなため在庫は0にしています。

---
*後日談*

間違ってキッズサイズを注文してしまい、  
34歳にして本格的に迷走しているなと思うこの頃

<img src='https://images.microcms-assets.io/assets/78462567737b44e7a8177831c19c7b65/c1c5ba51dbef442b83259e6c452267fa/IMG_0471-min.jpg' alt='ピオリム' />

---
全然関係ないけどバックエンドTSを勉強しようと思って調べてたら、一休さんが興味深い挑戦をしていた。
https://speakerdeck.com/naoya/typescript-niyoru-graphql-batukuendokai-fa-75b3dab7-90a8-4169-a4dc-d1e7410b9dbd
スイッチコストを減らすためにクラサバTSにして更に宣言的アーキテクチャで揃えるのは夢があると思って見ている。

まだ時代が追いついていない気がするけど、持ちうる状態のパターンを事前に用意して遷移はフレームワークに任せるというのは見通しも良くなりテスタブルにもなりそうなので、かなり良さそう。
ただ現状は自前でルールを作る必要があるので、実戦投入にはエネルギーを使いそう。

フットワークが軽くなるパーカーを作った

GraphQLとそのクライアントライブラリ「Apollo Client」の話です。  
業務でApollo Clientを触る機会があったため、使い方の紹介と感想です。

## GraphQLの特徴

### スキーマ Schemaについて

スキーマはGraphQLにおいて、APIとクライアント間のインターフェースとして利用されるIDLです。

```graphql
type Post {
  id: String!
  created_at: DateTime!
}
```

クライアントからは
- request / responseの型情報
- データ取得関数の自動生成
として利用されます。

この型があることで、補完が効いて開発効率が上がる・型安全になり修正/リファクタ時の負荷軽減が期待できます。

e.g. `$ tsc --noEmit` でAPI変更の影響をざっくり知ることができる

### RESTとの比較

主に下記のような差分があると考えています。
- クライアントがレスポンスを組み立てる
- 基本的に「リソース=リゾルバ」になるためエンドポイント単位でのサブリソースの管理が不要
e.g. 記事ページのAPIにコメントを生やしたが、他ページでもコメントを取りたくなった

GraphQLはクライアントファーストな仕組みと言うことができ、  
SPAが普及してクライアントに複雑性が移動してきた背景を考えるとGraphQLの登場は自然な文脈だと考えられます。

ただし、利用してみて学習・環境構築コストが高く、  
パフォーマンス出しにくいという学びがあったため使い所は見極める必要があると思います。
(シンプルなアプリケーションには向かない)

## Apollo Client

GraphQLクライアントライブラリで、旧facebook社が開発したRelayと2大巨頭。  
クライアント以外にもApollo Serverというライブラリが存在していて、  
Apollo StudioというGraphQLプレイグラウンド・パフォーマンストラッキングなどを行うSaaSと連携できる。  
(課金プランがあるため、使いたい機能がなければ使わないのが無難そう)

https://www.apollographql.com/docs/react/why-apollo/

後発ながら機能が豊富で利用者が多くRelayに比べてfragment collocationは強制されないなど制約が弱めです。  
ツールチェイン周りもRelayはビルトインなのに対して、Apolloはサードパーティのツールを必要とします。  
(GraphQL Code Generator)

https://www.the-guild.dev/graphql/codegen/plugins/typescript/typescript-react-apollo

### apolloで状態管理を行う

コンポーネントを跨いで利用したい状態をグローバルステートと呼び、  
その状態の管理方法が「状態管理」と呼ばれている。  
状態管理で扱うデータの種類は大きく「API経由、それ以外データ」の2つに分類できる。  

この状態管理にはReduxやFluxが利用されるのが通例だが、  
下記のような課題があり recoil などのシンプルな状態管理ライブラリが登場してきている。  
- 概念自体が難しくて初見殺し (バックエンドエンジニアが触りたくなくなる)  
- API経由データの通信状態の遷移を表現するためにmiddlewareが必要
- action, action creator, reducerボイラープレートが多くて大変
- コード量が多くなると職人が必要

また、シンプルな状態管理ライブラリとは別に SWR, useQueryといったキャッシュ機構を持ったfetchライブラリが流行ってきた。  
これらはAPIから取得・変更されたデータをメモリキャッシュとして保持して、
fetch時にキャッシュを自動更新するという機能を提供している。

Apolloもキャッシュ機構を持っていて、上記に加えてオブジェクトごとに正規化してくれる機能がついている。

```js
// __typename x idを識別子としてユニーク性を担保
{
  __typename: 'Post',
  id: 'uuid-1',
  name: 'something'
},
{
  __typename: 'Post',
  id: 'uuid-2',
  name: 'anything'
}
```

この機能によって、下記のような挙動が可能になる。
- ミューテーションで記事を更新する
- 記事一覧のキャッシュが更新される
- 記事一覧の表示が更新される

Reduxで行われていた `dispatch(action, data.payload)` する処理を自動的に行なってくれている。

また、APIを経由しないデータについても「Reactive variables」が利用できる。
layout層にマウントされている共通モーダルの状態などに利用できる。

https://www.apollographql.com/docs/react/local-state/reactive-variables/

```js
// store.js
const flagVar = makeVar(false);

// component.jsx
const Component = () => {
  // flag変更がreactiveに検知される
  const flag = useReactiveVar(flagVar);
  return <div onClick={() => flagVar(true)}>{flag}</div>;
}
```

なお、この機能はリリースされたてのためデバッグ用の拡張機能などが対応していない。
そのため複雑なオブジェクトなどの状態管理には利用しない方が良さそうだと思っている。

## GraphQL Code Generator

下記を自動生成してくれるツール↓
- APIのレスポンス型
- データ取得のhooks

https://www.the-guild.dev/graphql/codegen/plugins/typescript/typescript-react-apollo

APIでスキーマ作成、クライアントにオペレーション(query/mutation)のコードを書いて、
CLIからコマンドを叩くと自動生成される仕組みになっている。

**スキーマ**

```graphql
# ルート型
schema {
  query: Query
  mutation: Mutation
}

type Query {
  # フィールド
  post: Post
}
# オブジェクト型
type Post { id: String! title: String }

type Mutation {
  update_post(input: UpdatePostInput!): UpdatePostMutation!
}
type UpdatePostInput { id: String! title: String! } # パラメータ
type UpdatePostMutation { post: Post } # レスポンス
```

**オペレーション**

```graphql
query PostPage {
  post { # フィールド
    id
    title
  }
}

mutation PostPageUpdate($input: UpdatePostInput!) {
  update_post(input: $input) {
    id # ここからレスポンス
    title
  }
}
```

**生成されるコード**

```ts
// レスポンス型
type PostPageQuery = {
  __typename: 'Post';
  id: string;
  title: string | null | undefined;
};
// hooks
const usePostPageQuery = useQuery(...);

// レスポンス型
type PostPageUpdateMutation = {
  __typename: 'PostPageUpdateMutation';
  post: Post;
};
// hooks
const usePostPageUpdateMutatiion = useMutation(...);
```

**hooksの利用方法**

```ts
const Component = () => {
  const { data, loading, error } = usePostPageQuery();
   
  const [mutate] = usePostPageUpdateMutatiion(); // 関数取得
  const handleUpdate = async () => {
    try {
      const { error } = await mutate();
      if (error) return throw error;
    } catch { // エラーハンドリング }
  };

  if (error) return throw error; // エラーハンドリング
  if (loading) return <div>Loading</div>; // ローディング中

  return (
    <>
      <div>{`${data.post.id}: ${data.post?.title}`}</div>
      <button onClick={handleUpdate}>更新</button>
    </>
  );
};
```

## 開発フローについて

GraphQLのライブラリは言語ごとに多種多様だが、  
開発方法は主に2種類(ハイブリットも出てきているらしい)に分類できる。
- Code First  
APIの型・リゾルバーを先に実装して、スキーマを生成するタイプ  
- Schema First  
スキーマを先に作っておき、コード生成するタイプ (gqlgenなど)  

コードファーストのライブラリを利用する場合、  
フロントはスキーマができるまで型や自動生成されたhooksを利用することができない。  
そのため、コードファーストはフルスタックなチームに適している方式なんだろうと想像している。

スキーマファーストの場合、  
フロントがスキーマを書いてバックエンドが具体的なロジックを実装するという方式が取れそう。

いずれにしてもスキーマはRESTに比べて慎重に決める必要があって、
デザイン・ER図ができた段階で相談するタイミングを設ける必要がありそうだと思っている。

なお、第2世代(あるいは第3世代)コードファーストというものも出ていてモデルから型を自動抽出したりしてくれるらしい。
(第一世代はリゾルバーを書くときに手動で定義する)

https://user-first.ikyu.co.jp/entry/2019/12/16/113332#%E3%82%B3%E3%83%BC%E3%83%89%E3%83%95%E3%82%A1%E3%83%BC%E3%82%B9%E3%83%88-vs-%E3%82%B9%E3%82%AD%E3%83%BC%E3%83%9E%E3%83%95%E3%82%A1%E3%83%BC%E3%82%B9%E3%83%88
## 最後に

下記に苦戦したのでどこかのタイミングで記事にしたい。  
- fragment collocation  
- persisted query  
