Upgrade to Pro — share decks privately, control downloads, hide ads and more …

暗黙知を共有するプラットフォーム 「健常者エミュレータ事例集の取り組み」

暗黙知を共有するプラットフォーム 「健常者エミュレータ事例集の取り組み」

2024-05-09 個人開発集会@VRChat

contradiction29

May 09, 2024
Tweet

More Decks by contradiction29

Other Decks in Technology

Transcript

  1. 知識の種類その2:暗黙の知識 • すべての知識が明⽂化されているわけではない ◦ 明⽂化:法律や政令、ルールなどとして書き下されており、なおかつその⽂章にアクセスできる状態 が保証されていること ◦ 例)法律、政令、ゲームのルール • 明⽂化されることがない知識は多い

    ◦ ⽂化的なコンテキスト、あるいは「常識」や「良識」に収まるため、⾔語化する必要性が低い ◦ (とみなされている) • 通常、こういった「暗黙の知識」は情緒的な発達やコミュニティ内部の情報交換で 培われる ◦ 注意:誰もが情緒的な発達の過程を経られるわけではない ◦ 注意:誰もがコミュニティに所属できるわけではない
  2. 暗黙知を知らないとどうなる? • 暗黙知を知らない結果として⽣じうるもの ◦ 他者に対する損害:不快感を与える、⼈間関係が悪化する、場の空気を悪くする ◦ ⾃分に対する損害:集団からの阻害、機会損失 ◦ 実害:訴訟沙汰、実刑など •

    暗黙知にアクセス可能かどうかはQOLに影響する ◦ 暗黙知にアクセスできないことは⼈⽣にマイナスの影響をもたらす ◦ 逆に、暗黙知にアクセスできることはQOLにプラスの影響をもたらす ◦ QOL : Quality of Life • 暗黙知は個⼈のQOLを考えるうえで重要である
  3. 暗黙知を共有する場所を作るうえで解くべき課題と解決策 1. 「暗黙知」を⾔葉にできない ◦ なぜ? ▪ 経験に対して⼼理的な距離を⼗分にとることができず、客観的に説明できない場合がある ▪ 暗黙知は状況依存性が⾼く、知識の発⽣したコンテキストを明確にできない ◦

    どうする? ▪ 以下の⼆つを実装する 1. 暗黙知の発⽣したコンテキストを明確にしながら、可能な限り客観的な内省を⾏いつつ知識を整 理し、記事を作成できるようにするopinionedなテンプレート 2. そのテンプレートに沿う投稿システム 2. 仮に暗黙知を記事にできたとしても、それを共有する場所がない ◦ どうする? ▪ ⾃分で作って解消できる ▪ ないものは⾃分で作るしかない
  4. ⾃⼰紹介 • ⾃⼰紹介に興味がない⽅のために、 左半分は柴⽝の画像にしています • 関⼼領域 ◦ データエンジニアリング、データマネジメ ント(本業) ◦

    TypeScript, React, Remix, Supabaseなど • VRChatプレイ時間数 : 70時間 ◦ まだUser、伸び盛りがある ◦ 美少⼥アバターを纏いたくてVRChat始め た https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Shiba_inu_taiki.jpg
  5. 健常者エミュレータ事例集が⽬指す世界 • 個⼈の属性に寄らず、誰もが暗黙知にアクセスできる世界を⽬指す • 「個⼈の属性に寄らず」 ◦ 「健常さ」は前提条件が共有されているかどうかで決まる。絶対はない ▪ 今⽇の健常者は明⽇の⾮健常者かもしれない。運命は理不尽 ▪

    同じ⼈間でもTPOによって健常者か⾮健常者は変わる ▪ 「スペクトラムとしての健常さ」がある ◦ 暗黙知へのアクセスは尊厳の問題であり、誰もがアクセスできる環境があるべき • 「暗黙知」 ◦ ⾔葉にされない知識のこと • 「アクセスできる」 ◦ 閲覧‧評価し、場合に応じて修正できる状態が担保されていること ◦ アクセシビリティは重要視している
  6. 3つのコンポーネントから構築 Webアプリ本体 自動化システム データパイプライン メイン言語 TypeScript Python SQL フレームワーク Remix

    Serverless Framework dbt インフラ Vercel, Cloudflare AWS Lambda dbt Cloud そのほか Supabase, New Relic, Playwright, Google Analytics 4, daisy UI, Open AI API Amazon SNS, dlt, New Relic Google BigQuery, Looker Studio 役割 Webアプリケーションの構築 ①X, Misskey.io, Blueskyへ のSNS連携 ②データに基づくリバース ETL処理の実施 ③BigQueryへのデータ連携 ①データ分析環境の提供 ②データに基づくリバース ETL処理の実施
  7. 技術構成の特徴 個⼈開発で重要なものは「コストパフォーマンス」「メンテナンスコストの低さ」「開発者体験」の3つ 1. コストパフォーマンス ◦ AWS Lambda、dbt Cloud, Google Analytics

    4, New Relic, Cloudflareに関しては無料枠 ◦ Vercel, Supabase, ドメイン代, BigQuery, OpenAI APIのみが課⾦要素 ◦ ⾦をかけすぎると変なモチベーションが⽣まれるので、⽣活を圧迫しない程度の⽀出に抑える 2. メンテナンスコストの低さ ◦ サーバーレスなサービスを多⽤し、メンテナンスコストを削減 ◦ ⾦さえ続くのならたとえ⼀⼈でも維持可能な仕組みを作る ◦ インフラに関して⼀⼈ですべてを⾒る必要があるので、保守にかかる⼿間を上げすぎないのが⼤事に なる 3. 開発者体験 ◦ 素早く変更を加えられるフローを構築して、機能実装のスピードを⾼める
  8. 健常者エミュレータ事例集の発展の過程 • 2022-03:Seesaa Wikiにて公開開始 ◦ Seesaa Wiki : 外部のCMSサービス •

    2022-07 : Next.jsで投稿フォームを作成 ◦ 投稿数が増え始める • 2023-01 : 投稿通知Botに画像投稿機能を追加 ◦ 投稿数が急増 ◦ 累計投稿数が4000を突破 • 2023-02 : Seesaa WikiからWordpress体制に移⾏ ◦ コメント/記事に対する評価機能が追加 • 2024-04 : Remixをベースにする現在の体制に移⾏
  9. これからの展望 1. インフラ改善 ◦ Vercelよりコストパフォーマンスの⾼いCloudflare Workersへの移⾏ 2. 閲覧機能の改善 ◦ 「関連する記事」推薦アルゴリズムの改善

    ◦ 匿名掲⽰板機能の実装 ◦ SupabaseのAnonymous Login機能を利⽤したいいねした記事の保存機能 3. 拡散機能の改善 ◦ 記事内容からのmeta:descriptionの⽣成(SEO対策) ◦ Twitter(現X)以外のSNSへのシェア機能強化 4. 記事作成機能の改善 ◦ Copilot機能付き投稿フォームにおいて、複数選択肢を選べるように実装を変更 ◦ 精度‧コストともに微妙なため、プロンプトを改善しつつモデルをGPT-3.5から 変更 ▪ 精度を重視する場合:xai-org/grok-1 on Hugging Face API ▪ コストを重視する場合:llama 3-8b on Groq ↑精度が微妙な補完機能
  10. おわりに • 投稿してみよう ◦ 「やっちまったな...」と思うことがあるとき ◦ 「これやってよかったな」と思うことがあるとき ◦ 以下のリンクから投稿できます ◦

    https://healthy-person-emulator.org/post ◦ もしくは「健エミュ 投稿する」で検索 • コードは公開しているので良かったら⾒てみてね ◦ https://github.com/sora32127/healthy-person-emulator-dotorg • Pixiv Fanboxもやっています ◦ 鯖代が賄えるくらいになりたい ◦ https://contradiction29.fanbox.cc/