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 を使った実験では特にこのプロンプト部分で手こずり、十分な成果が出せないままだった。

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

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

聴講メモ: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


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 は上方向(デフォルトではワールド空間)をそれぞれ取得可能。

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

Reality Composer Pro の Share Graph で使えるノードを眺めてみる(Adjustment 編)

前回の試みの続き:
Reality Composer Pro の Share Graph で使えるノードを眺めてみる(2D/3D Procedural/Texture 編)

  • Adjustment
    • Remap
    • Smooth Step
    • Luminance
    • RGB to HSV
    • HSV to RGB
    • Contrast
    • Range
    • HSV Adjust
    • Saturate
    • Step (RealityKit)

名の通り値や範囲を変換するノードカテゴリ。分からなかったものだけ以下にまとめてみた。


Remap

In を In Low~In Hight の区間に正規化 (clampはしない) した上で、Out Low~Out Hight の区間に線形補間する。以下が参考になった。
ShaderGraphのRemapについて

たとえば

  • InMin = 0
  • InMax = 1
  • OutMin = 0
  • OutMax = 100

の場合、In 0.3 は Out 30 に変換される。

ChatGPT によると以下のような使い所があるらしい。

  • ノイズの出力を別レンジにマッピング
    • 0〜1 → -0.2〜0.8 とか
  • 距離(Position から算出した長さ)を 0〜1 に正規化
  • depth / mask などの 特定範囲だけを抽出して強調
  • テクスチャから取った値を別の物理量レンジに変換
    • 例:0〜1 のテクスチャ → 金属度 0.1〜0.8 に変換

参考:
Remap ノード | Shader Graph | 10.0.0-preview.27

Range

Remap に対し、さらにガンマ補正と clamp を可能にしたもの。といってもイメージがわかないのだが、ChatGPT によると使い所は以下らしい。

  • ノイズのコントラスト調整
    • ガンマで “柔らかい山” や “トゲのある山” を作れる
    • OutLow/High でオフセット付きノイズにできる
  • テクスチャのレベル補正(Photoshop の「レベル」みたいなこと)
    • InLow/High = 0.2〜0.8
    • Gamma = 0.8
    • → 暗部/明部の強調ができる
  • マスクの精密調整
    • Smoothstep より鋭い/柔らかいコントロールが可能
  • エッジ表現
    • Gamma > 1 で “暗い部分を広く、明るい部分を締める” ことができる

Step (RealityKit)

In が Edge よりも大きいか小さいかに従って、0 / 1 に二値化する。

Smooth Step

In が Low~High の区間で clamp し、区間内ではなめらかにS字状で補完 (エルミート補完) する。「これは補間が開始点から徐々に加速し、終了点に向かって減速することを意味します。この補間は、自然なアニメーション、フェード、その他の遷移を作成するのに有用」らしい。
Smoothstep Node | Shader Graph | 14.0.12

Step と Smooth Step の違いは以下がわかりやすかった。
ShaderGraphの頻出ノード!機能別で覚えよう #ポケテク|ポケラボ

Luminance

RGB を人の視覚的特性にあわせたグレースケースに変換する。輝度係数 (Luma coefficients) とカラーベクトルの内積を計算することで画像のグレースケール値を算出する。(ドキュメントにサンプル画像あり)

ChatGPT による用途は以下。

  • テクスチャ/カラー → グレースケール変換
    • 色の情報を無視して「明るさだけ」で処理したいとき。
  • マスク/マットの生成
    • たとえば “明るさが一定以上なら反応” とか、“暗い部分だけにエフェクトをかける” といった用途。
  • フェード、ディゾルブ、ディゾルブマスク
    • カラー画像の輝度差を利用して、部分的に透明/不透明を切り替えるような表現。
  • ポストプロセス/エフェクトの輝度依存処理
    • 明るさに応じてぼかし/エッジ/グローを変えるなど。
  • ライティングや雰囲気の制御
    • 色ではなく「明るさ」を元に音、パーティクル、光量の変化を制御する場合など。