投稿者: p0dee

聴講メモ：YapTech Playground #3　PdM編

Yappli さん本社に遊びに行きたい！という一心で PdM という畑違いの勉強会に参加してきた。

イベントページ：https://yappli.connpass.com/event/373235/

畑違いとはいえ、いちサービス開発に関わる身としては頭にいれておくべき内容で良かった。特に、AI 活用してリーンに MVP 開発するというプロトタイプ思考は、Vibe Coding 時代だからこそあらためて実践したいと思った。

素敵すぎるボトル。

元起業家PdM、AIで”爆速MVP検証”を実現した話

リャオス さん

  • クロスセル、価値拡大は 0→1
    • エンジニアリソースを使って検証する余力なく、一発で当てたいが、検証なしで始めるリスクは大きい
    • 小さく始めてしまう
  • 1週間でMVPプロトタイプ
    • 競合調査：DeepResearch
    • (MAツールの)代表的な機能リストを作成：Cursor
      • 機能イメージができてくる
    • プロトタイプ構築：v0
    • MVP検証
    • ユースケース検証
  • 0→1の壁が消えた
    • リーン：顧客に聞け、正解は顧客が知っている（マーケットイン）
    • 0 to 1：顧客に聞くな、競合せず独占しろ（プロダクトアウト）
    • AI エンジニアを使って、エンジニアが作ったのと同等の精度で検証可能
  • 顧客の優しい嘘
    • アイデアに対して「ぜひ欲しい！」と、使う立場としてのニーズは違う
    • MVP いきなり作って渡すことができる
    • 顧客ヒアリングの時間が取れない問題
    • 「リアルな拒絶」を早めに引き出す
  • 開発フローの再定義
    • リーンスタートアップにおけるBMLループのどれもはしょれず、ただ爆速になっただけ
    • 「学習」もサボれない：なおいっそう頑張るポイント

Yappli流！「プロダクト改善」の進化といま

仲道 さん

  • プロダクト改善の推進
    • 要望、アイデア、技術負債の解消
  • 改善がなかなか進まない
    • チケットが減らず増える
    • 工程が進まないチケット
    • プラットフォームごとのリリースがばらける
    • 問い合わせに追いつかない
  • チケットが進まない原因：量、優先度、担当者不在、何度、リソース不足
    • 改善要望がリリースよりも多くなりやすく、避けにくい。この溝が深くなると、
    • 改善されていないことでチャーンする
    • 多部署からの信頼低下
    • 開発チームのモチベ低下
  • 解決方法
    • チケット残数の把握、認識を揃える、担当者を把握するなど、PdMがチケット診断者になる
    • チケット状況を把握する
      • PdM内で対話型の確認会（一人では無理）、判断軸をログとして記録して残す
    • やらないものを決める
      • 一定期間経っている、要望の熱が冷めている（要望が出続けているものはニーズ高いと判断）
      • 呼応数見積により区分分け、大規模開発は「改善」から移動。アサイン待ちになってしまうため
  • ブラックボックス化していたチケットボードをPdMがハブになり要望の集約、状況確認、共有
    • 優先順位、増減傾向が明確
    • やるべき　のみがあるチケットボードの健全化
    • 他部署連携がスムーズになり、調整コストを減らせた
  • フロー整備だけでなく、社内周知でメンバーへの浸透も

Prompting an on device foundation model を読んだ

Apple 武石さんのポストで知った、Apple が Foundation Model について提供した新たなドキュメント。

Prompting an on-device foundation model | Apple Developer Documentation

多くのプロンプトテクニックがサーバーベースの基盤モデル向けに設計されているのに対して、コンテクストウィンドウが限られたオンデバイスならではの手法を紹介したもの。各テクニックに対してそれぞれ、Do/Dont’s の具体例を交えながらどうプロンプト設計するべきかを紹介している。

読んだので以下にまとめてみた。

  • 簡潔明快に指示する (Use simple, clear instructions)
    • プロンプトが人間にとって素早く読めるかを自分自身に問い、トーンや文体の調整に対する追加戦略を検討する（使うべき／避けるべきプロンプト戦略を例示）
    • 長く間接的指示には、価値のない不要な言葉が含まれているため精度が落ちる。明快なプロンプトとして、直接的命令で記載するべき
  • ロールやペルソナ、トーンの指示を与える
    • 専門家 (expert) というフレーズによって、よりトピックに対して権威的で詳細な回答をする
    • オンデバイスモデルは人に語るように考えるため、モデルにその相手のペルソナ像を与える（e.g. 1年生の英語の生徒、あなたの魔法ショップに来た客）
  • テストを通じて得られた結果をもとにプロンプトの改善を繰り返す (Iterate and improve your prompt based on the output you receive in testing)
    • 改善の戦略
      • 明快さの改善：直接的、簡潔かつ読みやすく
      • 強調の使用：重要な命令に “must” “should” “do not” “avoid” といった言葉を用いる
      • くりかえし：重要な命令は指示の最後に繰り返し強調する
    • 信頼度の低いプロンプトはわずかな状況変化で簡単に崩壊する
  • プロンプトに回答する前に、モデルに推論フィールド (reasoning field) を提供する (Povide the model with a reasoning field before answering a prompt)
    • 推論の説明を構造から話すために、モデルに推論用のフィールドを設ける (e.g. var reasoningSteps: String // A property the model uses for reasoning)
    • その推論用のフィールドは先頭のプロパティとし、モデルがプロンプトに答える前にモデルに提供するようにする
  • モデルが思考すべきことを減らす (Reduce the thinking the model needs to do)
    • 複雑なタスクはシンプルなプロンプトで説明しきれない
    • 代わりに step-by-step により推論負荷を下げる（例あり）
  • 複雑なプロンプトを単純なリクエストに分割する (Split complex prompts into a series of simpler requests)
    • （↑の続き）ひとつの部分にフォーカスするリクエストごとに LanguageModelSession を複数に分け、都度新しいコンテクストウィンドウで推論させるのもあり
    • まずは単一のリクエストで試すべき（分割すると推論時間が伸びる）、結果次第でリクエストを分割する
  • “if-else” 文により条件付きプロンプトにロジックを追加する (Add “logic” to conditional prompts with “if-else” statements)
    • 多すぎる条件はモデルの能力に影響を及ぼす可能性あり
    • 結果が要求に見合わなかった場合、条件付きプロンプトを実装でカスタマイズする（条件にあたる部分をプロンプト文に実装上で挿入する）
  • ショットベース・プロンプティング(one-shot, few-shot, zero-shot など)を活用し、モデルに求める回答の具体例を提供する (Leverage shot-based prompting — such as one-shot, few-shot, or zero-shot prompts — to provide the model with specific examples of what you need)
    • Few-shot プロンプティングは、プロンプトでいくつかの例を与えるもの。Guided generation でも効果あり
    • オンデバイスモデルにはシンプルな例が好ましい、2-15 の例を用意し、それぞれをできる限り単純に保つ
    • 長く複雑な例を与えると、それをそのまま回答内で繰り返すハルシネーションに繋がる

過去、Foundation Model を使った実験では特にこのプロンプト部分で手こずり、十分な成果が出せないままだった。

登壇メモ：extension DC 2025 Day1 @DeNA

“must” 表現や few-shot などは試し済みだったが、他にまだまだ心当たる部分があったので試してみたい。あと、モデルの推論用フィールドを定義するというアイデアは、いまいちイメージ湧いていないが面白そう。

最後に Apple でのワークショップで教えていただいたプロンプトテクニックの記事。

参加メモ：新しいFoundation Modelフレームワークのアプリへの導入（ワークショップ）@Apple Japan

聴講メモ：LODGE XR “Tech” Talk #2 – visionOS

先日の visionOS TC でお話しくださった方がXで登壇を宣言されており、存在を知った本イベント。これは行かねばと突発的に参加してきた。初手からシホさんの「喋る胸像」プレゼンが面白すぎた。visionOS TC でも感じたことだが、映像系の発表が充実していたり、ハッカソン成果物の体験づくりや、作りかけの進捗報告もあり、幅があって楽しかった。

懇親会で、例の喋る胸像を実際に動かしているところを見させていただいたが、アイデアが個人的に刺さりまくった。物理オブジェクトのツインを作ってまるっきり重ねることで、現実と仮想を行き来しても、オブジェクトを起点に連続性が担保されたり、オブジェクトに魂が吹き込まれるような感覚があって、色々と考えさせらる作品だった。

LODGE XR でも特に Tech に焦点を当て、非定期に開催しているとのこと。比較的小規模で（visionOS TC 参加者に限らずXR界隈の常連が集っている感じ）和気藹々とし、次回は筆者も登壇してみたいと思った。

イベントページ：https://vrtokyo.connpass.com/event/376905/

喋る胸像体験「AlbusTalk」の作り方

@41h01 さん

  • アルバートくん
  • 現実の鏡像が動き出して会話を始めるMRタイプ
  • Unity 6.2 + Polyspatial
  • ObjectTrackingで3Dプリント胸像に3D鏡像モデルを被せる
    • 公開モデルをBlenderで編集
    • FlashPrint にデータ取り込み、プリント中に崩壊しないよう支柱を設定
    • Avatar maker Pro 利用してリップシンク対応モデル作成
      • BlendShape が自動で作られる
    • 瞳孔用テクスチャを当てて目を作成
      • BlendShape でランダムに瞬き
    • uLipSync + BlenderShape で口パク
  • トラッキング
    • KiriEngine で胸像3Dスキャン、Core ML で学習、Refarence Object Library に設定
    • ARTrackedObjectManager 経由で、認識タイミング、位置、角度が取得可能
      • 動きに対してはトラッキング遅延あり
  • OpenAI Realtime API (gpt-realtime)
    • 入力音声をbase64stringに変換、API連携
      • uLipSync 月の AudioSource に流して口パク
    • Instruction で人格定義
  • 体験の流れ
    • タイトルロゴ〜目覚め〜会話〜就寝〜エンドクレジット
    • しゃべりっぱなしでない
    • 胸像を触り目覚めをトリガー
      • 現実の鏡像位置に3Dモデルを配置しているので、コライダー設定して接触判定
    • ユーザー起因でないスクリプトは固定テクストプロンプトを OpenAI に流す
      • 流れを指定することで、そのままでなくとも守ったセリフを喋ってくれる

360°動画をVision Proで没入再生する新フォーマット実装 — Good Sleeperアプリの移行事例

@tochi_jp さん

“聴講メモ：LODGE XR “Tech” Talk #2 – visionOS” の続きを読む

聴講メモ：visionOS TC 2025 – 備忘録編

昨日感想を投稿した visionOS TC 2025 の、手元でガーっとメモしたものを備忘録がてら整理してみた。聴くのに集中してメモしていないものもあり。アーカイブ動画配信いただけるようなので楽しみ。

イベントページ：https://visionos-tc.com

参加メモ：visionOS TC 2025 – 感想編

Transform your iOS app into an Immersive Experience

Masakaz Ozaki さん

  • iOSの既存アプリをどうイマーシブに落とし込んでいくか？
  • visionOS 開発では既存コードベースをほぼそのまま利用できる、せっかくvisionOS に対応するならイマーシブな体験を追加しよう
  • イマーシブとは？
    • Part of the content
    • Makes you want to reach out instinctively
    • Seamless transition
    • Experience that moves you
  • 東京「舞浜」
    • 流動的な体験フロー：京王線のドアが開いて、アトラクションに向かうまでの体験
  • どのように iOS アプリをいまー支部な体験に落とし込むか
    • iOSの複雑な画面遷移の構造を乗り越える：シーンの概念を使う
      • コアな機能だけを持って行って、そこから広げていくことも可能
    • Step 1：iPhoneのスクリーンを7台並べる（マルチウインドウ）
      • 横に並べるだけではなく、扇形に。眼精疲労を防止
    • Step 2：iPhone のかたちにとらわれないものを並べる（紙面をグリッド状に並べる）
      • iOS で使っている技術、SwiftUI の modifier だけで実現できる、RealityKit 使わなくて良い
    • Step 3：（震源地図）
    • Step 4：Metal を使ったビジュアライゼーション（衛星のリアルタイムレンダリング）
      • イマーシブっぽく見せる工夫、ウィンドウを斜めに表示する
  • ウィンドウの工夫、手を上げて操作する（ゴリラ腕問題）を解消するために、自動スクロールさせる
  • コンテンツの文字部分と大きな背景画像は分離、いっぱい動かすと画面酔いを引き起こすため

様々なジャンルの Apple Vision Pro 専用ゲームタイトル制作で直面した技術的課題と解決方法の紹介

Graffity株式会社 cova さん

“聴講メモ：visionOS TC 2025 – 備忘録編” の続きを読む

参加メモ：visionOS TC 2025 – 感想編

国内初の visionOS テックカンファレンス、visionOS TC がこの土日で開催されたので参加した。過去にプロポーザル提出したと書いたが採択にはならず、純粋にオーディエンスとして二日間楽しんだ。

イベントページ：https://visionos-tc.com

会場はアベマタワー。個人的に昼開始というのがとてもありがたく、休日午前のルーチンを崩さず余裕を持って会場に向かうことができた。

ビル入り口や会場フロアに、visionOS TC のパネルが掲げられていてテンションが上がった。ノベルティに肩掛けポーチをいただき、Vision Pro のバッテリー入れ説が会場では囁かれていた。

セッションのトークテーマのラインナップが素晴らしく、Vision Pro 向けのプロダクト開発から得られた超実践的な知見から、空間ビデオ撮影の心動かされるエピソードまで幅広く、加えて海外のゲストスピーカーからは体験設計のノウハウ、空間体験制作のワークフローにAIをフル活用するナレッジがそれぞれ講演された。さらに8人による LT では、開発にとどまらなない変化球的側面からも visionOS が考察され、こう列挙するだけでも半日とは思えないほど、死角なしの充実さだった。

クロージングトークでは、主催服部さんから「Apple Vision Proに未来はあるのか？」というドキッとする投げかけがありながらも、こうしたきっかけを起点に、日本から空間コンピューティングの面白い事例が創出されているという未来を作りたいというカンファレンスに掛ける想いを語られ、強く感銘を受けた。そしてその未来に向けて、微力ながらも加勢したいと刺激を受けたのだった。

懇親会では豪華な食事も。visionOS アプリのデモを見せていただいたり、空間ビデオの活用方法から日常業務の悩みにいたるまで、たくさんのトピックで会話できた。

また Day 2 は Apple Japan での開催で、パネルトークとネットワーキングが中心。visionOS の2025年を総括したり、2026年の展望を語ったり、会場からのQ&A含めてさまざまな切り口から国内外屈指のトップクリエイターたちの声が聞けたのは非常に貴重だった。

ネットワーキングでは、昨日に続いて、空間ビデオの意義や現状の性能限界についてや、3Dプリンタを用いた Vision Pro アクセサリーの制作について実体験を聞いたりし、つい先日購入した3Dプリンタの活用を見出す良い機会となった。

実はこのカンファレンスでは visionOS アプリ開発のモチベーションを超えて、手元にある GoPro で撮りためた180°/360°動画をどう活用していくかであったり、3Dプリンタの活用や、そのためのモデリングをどう学んでいこうか、といった新たな興味関心を、他の参加者の方々と話す中で掘り起こされたのが面白かった。こうした、思ってもみなかった方向に発見があるのは、リアルな場こそのセレンディピティだと実感した。

またゲストスピーカーで来日されたTomさん、Oliverさんに話しかけるチャンスがあり、直接 Day 1 のセッションについて質問できたり、今自分がやっていることの展望をシェアすることができたのも嬉しいできごとだった。

この二日間で、たくさんの知見や発見、出会い、そして未来に向けた創造のモチベーションが得られたことはひとえに、素晴らしく設計運営された場があってのもの、、会場オペレーションは死角なしに素晴らしく、学びに交流にその時その時を楽しめた。主催の服部さんはじめ運営、スタッフ、サポーター、全ての関係者のみなさまに感謝！

来年開催を信じ、登壇か、サポーターか、あるいはスタッフか、どんな形であっても、国内 visionOS コミュニティを盛り上げる一助になりたいと、すでにワクワクが止まらない。

Day 2 会場を出た後の、ヒルズのイルミネーション

Reality Composer Pro の Share Graph で使えるノードを眺めてみる（Data 編）

続き：
Reality Composer Pro の Share Graph で使えるノードを眺めてみる（2D/3D Procedural/Texture 編）
Reality Composer Pro の Share Graph で使えるノードを眺めてみる（Adjustment 編）
Reality Composer Pro の Share Graph で使えるノードを眺めてみる（Application 編）
Reality Composer Pro の Share Graph で使えるノードを眺めてみる（Compositing 編）

Data は、あるデータを異なる形式に変換したり、データ構造内の個々の値を操作するもの。

  • Data
    • Convert
    • Swizzle
    • Combine 2 / 3 / 4
    • Extract
    • Separate 2 / 3 / 4
    • Primver Reader

Convert

入力ストリームに流れる値を異なるデータ形式に変換するノード。変換のパターンは、単一の値(数値、Bool) からベクトル(vector, color) に変換したり、その逆も然りだが、各パターンで過不足するデータの埋め方／引き方は、ドキュメントに網羅的に記されている。

Swizzle

入力ストリームの値を指定したチャネルの順序に並び替えて出力するノード。チャネルは “r”, “g”, “b”, “a” や、”x”, “y”, “z”, “w” を使って、”xxx”, “abgr” のような文字列で指定する。具体例がドキュメントにあり一目瞭然。

Extract

マルチチャネルの入力ストリームから、指定インデックスに対応するひとつのチャネルを抽出し、出力する。

Combine / Separate

文字通り、複数の値をひとつのベクトル(vector, color) にまとめたり、逆にひとつのベクトル(vector, color) をそれぞれのチャネルに分離する。Separate 4 に関しては、(r, g, b, a) -> (r, g, b), a のように分離できるっぽい。

Primvar Reader

ChatGPT によると、

お、Primvar Reader 来た！ここは USD／MaterialX っぽさが一番強く出るところですね 🧱

ざっくり言うと：

「ジオメトリ側に埋め込まれたカスタム属性（primvar）を、シェーダー側から読むためのノード」

です。

ということだが、意味不明だし今は必要なさそうなので、その時が来たら学習する。

一応、どんなときに使うのかも ChatGPT に教えてもらった。

  • 例1: 頂点マスクで「塗り分け」したい
  • 例2: 頂点カラーをそのまま Albedo に使う
  • 例3: UV セットの切り替え
  • 例4: string primvar でテクスチャやバリアントを変える

冬の野辺山旅

前回言及した、長野県・野辺山旅の記録。

野辺山といえば、JR最高標高駅で、野辺山天文台もあり（今年某作品の舞台ともなった）星の美しいスポットで有名。例年夏に訪れていたのだが、夏山の天気は崩れやすく星が見られるかは運次第だった（というか一度も見えたことはなかった）。宿のご主人に、いつなら晴れるのか尋ねたら一言「冬ですね」と返され、それ以降いつか冬の野辺山で満天の星空を見上げるのが夢だった。

ようやくその機会が巡ってきた今回の旅、天気予報の通りにからっと晴れたのは良かったが、月が明るすぎて星々は見事にかき消されてしまっていた。残念。仕方がないのでナイトモードで強引に写真におさめてみた。

ユリイカ2025年12月臨時増刊号　総特集＝大貫妙子

先日、昭和女子大学 人見記念講堂で行われた「大貫妙子 コンサート 2025 【Celebrating 50 Years】」にて、青葉市子との共演時だったと思うが、「ユリイカ」の増刊号で大貫妙子特集をしていると、それが発売されると、トーク内で宣伝があった。

青土社 ||ユリイカ：ユリイカ2025年12月臨時増刊号　総特集＝大貫妙子

大貫妙子は10年以上前から、毎年追いかけしているくらいにはファンだし、CDもすべて持っているが、書籍にまではアンテナを張っておらず、このことも知らなかった。しかし50周年の記念に買っておくか、、とコンサート後に予約注文し、それが先週届いていた。

そもそもユリイカという雑誌を知らず、いちセクションで特集されるんだろうか、程度で想定していた。しかし届いてみるとそれは雑誌ほどの大判ではなく旅行ガイドブック程度のサイズで拍子抜けした。さらに230頁もあるそれは、手に取ると分厚くずっしりと重量がある。この隅から隅までが「大貫妙子特集」なのだと気がついて驚いた。前述青葉さんとの対談を含め、総勢26名の、大貫さんとゆかりある関係者・著名人がエッセイを寄せている。

表紙や裏表紙には金の箔押しのような印刷が施されていて手が込んでいるし、見返しも凝った作りになっている。

筆者は先週末、長野県野辺山に泊まりで出かけた。愛用のウォークマンに大貫妙子作品をすべて入れているのだが、そのウォークマンと、このユリイカだけを娯楽に携えた。

軽い気持ちで手にしたこのユリイカが、読み進めれば進めるほどに、大なり小なり大貫妙子ファンを自称する方すべてにとっての必読書であるという確信を深めている。

大貫妙子の、デビュー前から今に至るまで、寄稿者それぞれの持つエピソードから、音楽家としての苦悩や、音楽との向き合い方を紐解く。あるいは1曲1曲取り上げて、彼女の詩世界やアレンジの特色を分析するコラムもあれば、「シティポップ」の再評価へと踏み込む難解な解釈も、、とにかく、その切り口の多様さ驚く。まるで万華鏡越しに彼女の音楽人生を俯瞰しているようだ。

また、それぞれのコラムもただ、たとえば単純に「あいうえお順」や「大物順」に並べてあるのではない（先頭が山下達郎なのは納得）。エッセイに登場するエピソードや作品同士がまるで数珠つなぎのように、以降のエッセイにバトンタッチするよう注意深く配置されているように思える。そのお陰で、50年という時間軸がすっと頭に入ってくるのだ。

車窓を流れる晴れ渡った長野の風景を脇に、ページをめくりながらその時々に登場する曲をウォークマンで再生する。ただそれだけの手順の中に、これまで親しみ尽くした音楽を、再び噛み締めるように味わえている実感があり、旅路はこの上なく贅沢な時間であった。

宿の猫

Reality Composer Pro の Share Graph で使えるノードを眺めてみる（Compositing 編）

続き：
Reality Composer Pro の Share Graph で使えるノードを眺めてみる（2D/3D Procedural/Texture 編）
Reality Composer Pro の Share Graph で使えるノードを眺めてみる（Adjustment 編）
Reality Composer Pro の Share Graph で使えるノードを眺めてみる（Application 編）

Compositing は、複数の値をもとにひとつの値を生成するノードカテゴリ。

  • Compositing
    • Premultiply
    • Unpremultiply
    • Additive Mix
    • Subtractive Mix
    • Difference
    • Burn
    • Dodge
    • Screen
    • Overlay
    • Disjoint Over
    • In
    • Mask
    • Matte
    • Out
    • Over
    • Inside
    • Outside
    • Mix

膨大にあるが、Input / Output は共通しているものが多いので分類して見てみる。
Premultiply, Unpremultiply を除くすべてのドキュメントにサンプル画像あるので理解しやすい。2枚のテクスチャの合成に使うっぽいが、具体的にどういったケースで使いたくなるかはイメージできていない。

In: Color4 → Out: Color4

Premultiply, Unpremultiply

Premultiply は、ストレート（RGB画像+透明度を示すアルファチャンネルの画像）に対して透明度を乗算し、アルファが高いほど暗くしたもの。
Unmultiply はその逆で、プリマルチ処理を逆算し、ストレートを復元するもの、と理解した。

以下記事が画像付きで解説しており参考になった。

コンポジターに必要なアルファチャンネルの知識（後編） – コンポジゴク

(Foreground: Float, Background: Float, Mix: Float) → Out: Float

Mix, Additive Mix, Subtractive Mix, Burn, Dodge, Screen, Overlay

Background, Foreground の2色を、それぞれのノードごとに定義された数式（各ドキュメントに記載あり）で計算し、アウトプットの色を生成するもの。

Mix 値は基本的にブレンドのウェイトであると説明されているが、Mix ノードに限っては数式内の係数として明示されている。

Over, Disjoint Over, Matte

Foreground, Background それぞれのアルファチャンネルを用いた合成処理。Over が単純な合成で、Foreground のアルファに応じて合成される。

一方 Disjoint Over は、説明読むところ、Foreground のアルファと Background のアルファの合算値によって処理が変わるようで、1を超えない場合は単純な合成、ただし1を超えると Background 側の重みが下がるっぽい（ドキュメントの数式が F+b(1-f)/b となっていたが、F+B(1-f)/b の間違いでは？）。これにより、Output のアルファは 1 よりも常に小さくなる。

Matte は、RGB チャンネルが Ff+B(1-f)、アルファチャンネルが f+b(1-f) によって計算され、つまり Foreground 側のアルファチャンネルの反転で Background をマスクしている？

In, Out, Mask

In は Background アルファと重なる Foreground を残し、
Out は Background アルファと重ならない Foreground を残す。
（Background はアルファチャンネルのみを利用するため、Background テクスチャ画像は描画されない）

Matte は In の逆で、Foreground アルファをもとに Background を残す。
（Foreground はアルファチャンネルのみを利用するため、Foreground テクスチャ画像は描画されない）

(In: Float, Mask: Float) → Out: Float

Inside, Outside

いわゆるマスク画像をバイパスしてマスキングする、っぽい。（ドキュメントのサンプルを見れば一目瞭然）

Reality Composer Pro の Share Graph で使えるノードを眺めてみる（Application 編）

続き：
Reality Composer Pro の Share Graph で使えるノードを眺めてみる（2D/3D Procedural/Texture 編）
Reality Composer Pro の Share Graph で使えるノードを眺めてみる（Adjustment 編）

Application はシステムの値を取得するノードカテゴリで、Time は現在時刻（秒）、Up Direction は上方向（デフォルトではワールド空間）をそれぞれ取得可能。

システム時間は他のノードと接続することで継続的に変化し、時間に応じたダイナミックなマテリアルが実現できる。（ドキュメントにサンプル動画あり）