Roblox Studio Luau入門｜最短で動かす

Roblox StudioでLuauを始めるなら、まずは最短で「書いたコードが動いた」と実感できるところまで進むのがいちばんです。
初回授業でも、print がOutputに出た瞬間にふっと表情が変わる場面を何度も見てきたので、この記事もその導線に合わせて、BaseplateにScriptを追加して出力を確認し、続けてPartに触れたらメッセージが出るところまで一気に進めます。
対象は、まったくの初心者と、ScratchやPythonを少し触ったことがある人です。
30〜60分で手を動かしながら、LuauがLua 5.1ベースで型注釈や strict / nonstrict を使えること、そしてScriptLocalScriptModuleScriptの役割の違いまで最初に整理できます。
教室ではLocalScriptの置き場所を間違えて動かないケースが本当に多いので、本文ではStarterPlayerScriptsやStarterGuiなど、どこに入れると動くのかも先回りして具体的に書きます。
遠回りな理屈より先に、まず動かして理解したい人にちょうどいい入門です。

Luauとは？Robloxで使うプログラミング言語をやさしく整理

Luauは、Roblox Studioでゲームや機能を動かすために使うスクリプト言語です。
土台はLua 5.1ですが、そのままのLuaではなく、Roblox向けに拡張された別物として理解したほうが混乱しません。
特に入門段階では、文法そのものよりも「どこで動く言語なのか」と「型注釈や strict がある」という2点を先に押さえると、学習のつまずきが一気に減ります。

Luaとの関係と違い

LuauはLua 5.1をベースにした、Roblox向けの拡張スクリプト言語です。
古い日本語記事では「RobloxはLuaを使う」と書かれていることがありますが、現在の文脈で正確に言うならLuauです。
Luaの文法に近い書き方で始められる一方、Roblox制作に合わせて独自の拡張が入っているので、Luaそのものと全く同一というわけではなく、一部の構文や挙動が異なります。

違いとして最初に知っておきたいのが、Luauは段階的型付けを持っていることです。
変数や関数に型注釈を書けて、書かなかった部分も型推論がある程度補ってくれます。
さらに型チェックのモードとして nonstrict と strict があり、strict では実行前の段階で気づける問題が増えます。
Lua経験者ほど「今まで通りの感覚で全部書けるはず」と入りがちですが、そこで最初に型注釈と strict の存在を伝えておくと、その後に「同じ書き方なのに警告が出る」「補完の出方が違う」と戸惑う場面が減ります。
実際、入門者に説明するときも、ここを先に一言入れるだけで後の混乱が目に見えて少なくなります。

導入時期の流れも押さえておくと位置づけが見えます。
Luauは2019年にRoblox開発者向けに導入され、その後2021年にはMITライセンスでオープンソース化されています。
仕様や実装の最新情報は公式ドキュメント（https://luau-lang.org）やGitHubリポジトリ（https://github.com/Roblox/luau）で確認できます。

Roblox StudioでLuauが使われる場所

LuauはRoblox Studioに統合されていて、ゲーム内の挙動を作る中心にあります。
無料で使えるRoblox Studioの中で、オブジェクトにスクリプトを追加し、プレイテストしながら動作を確認する流れが基本です。
学習の起点としてはRoblox Creator Hub Luauのページがいちばん整理されていて、文法、型、実行の考え方まで一本の流れで追えます。

Studio内で最初に触れることが多いのは、Script、LocalScript、ModuleScript の3つです。
Script はサーバー側で動く基本のスクリプト、LocalScript はプレイヤーごとのクライアント側で動くスクリプト、ModuleScript は共通処理を分けて再利用するための部品です。
たとえばワールド全体の処理は Script、UIや入力は LocalScript、複数の場所から呼ぶ関数群は ModuleScript という形で役割が分かれます。

この区分を知らないまま書き始めると、「コードは正しいのに反応しない」という状態に入りやすくなります。
特に LocalScript は置き場所が大事で、StarterPlayerScriptsやStarterGuiなど、クライアントで実行される場所に入ってはじめて意図通り動きます。
反対にサーバー処理はServerScriptServiceに置くと整理しやすく、クライアントに見せたくない処理も分けられます。
Luauは入門向けに書きやすいだけでなく、実行基盤の改善も継続しています。
たとえば2023年にはネイティブコード生成が追加され、スクリプトの実行効率が向上しました。
教育用途の軽量な言語という印象が強いかもしれませんが、パフォーマンス面の改良が着実に進んでいる点も見逃せません。

他言語との比較

Roblox制作の文脈で見ると、LuauはLua 5.1より一歩先まで含んだ実用言語です。
Lua 5.1は土台としての理解に役立ちますが、Roblox Studioでそのまま使う前提の言語ではありません。
Pythonは汎用プログラミングの学習には向いていても、Studio内で直接ゲーム挙動を書く用途にはつながりません。
Scratchはプログラミングの考え方をつかむ入口としては優秀ですが、Robloxの実制作にそのまま接続するわけではありません。
つまり、Robloxのゲームを作る作業に直結しているのはLuauで、Luaは背景理解、Pythonは比較対象、Scratchは前段の学習経験として捉えると整理しやすくなります。

Luauを始める前の準備｜Roblox Studioのインストールと画面確認

Luauを書き始める前に必要なのは、難しい設定ではなくRoblox Studioを動かせる環境をきちんとそろえることです。
Roblox Studioは無料で始められ、アカウントとPCがあれば制作の入口に立てます。
ここでBaseplateを開き、ExplorerPropertiesOutputの3つを先に見える状態にしておくと、次のスクリプト作成で迷う場面が一気に減ります。

必要なもの

最初にそろえるものは3つです。
Robloxのアカウント、WindowsまたはmacOSのPC、そしてインターネット接続です。
Roblox Studioは無料で使える制作ツールなので、この段階で有料プランを前提にする必要はありません。

PCが必要になるのは、Roblox Studio自体がPC向けの開発環境だからです。
スマホやタブレットでプレイはできても、Studioを起動してスクリプトを書いたり、画面パネルを開いて作業したりする用途には向いていません。
入門でつまずく人の中には「まずスマホで触れないか」と考えるケースがありますが、コードを書く環境づくりはPC前提で考えたほうが早く進みます。

アカウントも最初に用意しておくと、そのままStudioへのサインインに使えます。
ゲームで遊ぶためのアカウントと、制作のためのアカウントは基本的に同じ導線で扱えるので、特別に別の登録が必要になるわけではありません。

Studioのインストールとサインイン

Roblox Studioのセットアップは、流れを順番に追えば迷いません。日本語UIでも英語UIでも、見る場所はほぼ同じです。

1. RobloxのサイトでRoblox Studioの入手ページを開き、Studioをインストールしてください。
2. ダウンロードしたインストーラーを起動して、PCにRoblox Studioを入れておきましょう。
3. インストール後にRoblox Studioを起動することになるでしょう。
4. 起動した画面でRobloxアカウントにサインインします。英語表示なら Sign In、日本語表示ならサインインに相当するボタンを選んでください。
5. サインインが終わると、テンプレートを選んで新しいプロジェクトを作るランディング画面に入ります。

初回起動では「どこから作り始めればいいのか」が見えにくく感じますが、ここで探すものはテンプレート一覧だけです。
余計な設定を先に触るより、まずは新規プロジェクトを開いて作業画面を見たほうが全体像をつかめます。

Baseplateテンプレートを開く

新規プロジェクトでは、テンプレート一覧からBaseplateを選びます。
名前はそのままBaseplateになっていることが多く、バリエーションとしてClassic Baseplateのような表記が見えることもあります。
入門では、いちばんシンプルなベースのテンプレートを開ければ十分です。

Baseplateを選ぶ理由は、余計な仕掛けが少なく、スクリプトの動作確認に集中できるからです。
背景や地形、複雑なオブジェクトが最初から多く入ったテンプレートだと、どこに何があるのか把握する前に画面情報が増えます。
最初の一歩では、広い土台の上でオブジェクトとスクリプトの関係を見たほうが理解が進みます。

この段階では、3Dビューに地面が見えていれば準備は順調です。
次に確認したいのは、見た目の派手さではなく、オブジェクトの階層とプロパティとログを読むためのパネルです。
コードを書き始める前に作業画面を整えるほうが、後で詰まる回数が少なくなります。

Explorer/Properties/Outputを表示する

Roblox Studioで最初に見えるようにしておきたいのが、ExplorerPropertiesOutputです。
上部のViewタブ、日本語UIなら表示タブを開くと、各パネルの表示切り替えがあります。
ここでExplorerPropertiesOutputをオンにすると、必要な情報が一画面にそろいます。

Explorerはゲーム内オブジェクトの階層を見る場所です。
WorkspaceやServerScriptServiceのようなサービスが並び、どこに何を入れたのかを追えます。
オブジェクトを右クリックして Insert Object から Script を追加する場面でも、このパネルが起点になります。

Propertiesは、選択中のオブジェクトの設定値を見る場所です。
たとえばPartを選んだときに、位置、サイズ、色、Anchored などをここで編集できます。
オブジェクトを置いたのに挙動が違うときは、階層をExplorerで確認し、設定をPropertiesで見る流れが基本になります。

Outputは、print の出力やエラーが出る場所です。
次のセクションで最初のスクリプトを書いたときも、結果はここに出ます。
エラーは赤字で表示され、該当行に飛んで修正できるので、入門ではエディタ本体と同じくらい見る回数が増えます。
実際、はじめての受講生はExplorerとOutputを閉じたまま進めてしまい、「何も起きていない」と感じて止まりがちです。
最初にViewタブでこの3つを一緒に表示しておくと、どこを見ればいいかが固定されるので迷子になる人がぐっと減ります。

パネルの配置は画面の右側や下側にまとまることが多く、Outputは下部に置くとログを追いやすくなります。
もし見当たらない場合も、探し回る必要はありません。
Viewタブに戻って対象のボタンが有効になっているかを見るだけで復帰できます。
ここまで整っていれば、次は実際にScriptを追加して、書いたコードがOutputに出るところまで進めます。

最初のLuauコードを書いてみよう｜printで動作確認する

ここでは、実際にLuauのコードを1行動かして、「書いたものが反応した」という最初の成功体験を作ります。
入門でまず触るべきなのは難しい文法ではなく、print でOutputに文字を出す流れです。
これが見えた瞬間に“動いた”という実感が生まれ、この段階で手応えをつかめるかどうかが継続を左右します。

Scriptを追加する

まずExplorerでWorkspaceを見つけ、その上で右クリックして Insert Object から Script を追加します。
上部のHomeタブから Script を追加する方法でも進められますが、最初は「どこに入れたか」を階層で把握できるExplorer経由のほうが迷いません。
今回の流れではWorkspaceを右クリックして追加すると、3Dワールド側にぶら下がる形でScriptが入ったことを確認できます。

Scriptを追加すると、コードエディタが開き、デフォルトで print("Hello world!") が入っている状態になっています。
入門では、この最初から用意されている1行をそのまま使っても動作確認できますが、今回は表記をそろえるために次のように書き換えます。

print("Hello, world!")

やっていることはとてもシンプルで、print はかっこ内の文字をOutputへ表示する命令です。
まだオブジェクトを動かしたり、キャラクターを操作したりはしませんが、コードを書いて実行し、結果をログで読むという開発の基本がこの1行に詰まっています。

この段階では、どこにScriptが入ったかが見える画面を残しておくと後で見返しやすくなります。
ExplorerでWorkspaceの中にScriptが追加されている状態のスクリーンショットを入れておくと、読者が同じ位置に作れているかを確認しやすくなります。

printでOutputに表示する

print("Hello, world!") のように文字列を渡すと、その内容がOutputウィンドウに表示されます。
プログラミングの入門で Hello, world! を出すのは定番ですが、Roblox Studioでもこの1行がきちんと最初の確認ポイントとして機能します。

大切なのは、コードを書いたあとに「どこで結果を見るのか」をはっきりさせることです。
画面上では見た目が変わらなくても、Outputに文字が出ればスクリプトは動いています。
最初のうちは3Dビューばかり見てしまいがちですが、スクリプトの成否はログに出るので、視線の置き場所はOutputになります。

print("Hello, world!")

この1行が出た瞬間に、「ただの文字入力ではなく、命令として実行された」と実感できます。
入門者がここで一度きちんと成功すると、次に変数や条件分岐へ進んだときも「またOutputで確認すればいい」と考えられるようになります。
最初の一歩でつまずかない構成が、その後の理解の速度を大きく変えます。

Outputがまだ見えていない場合は、前の準備で触れた通りViewタブから表示できます。
コードとログを同時に見える配置にしておくと、書く、実行する、結果を見る、直すという流れが切れません。

Playテストと出力確認

コードを書き換えたら、Playボタンでテストを開始します。
HomeタブにPlayが見えている構成ならそこから実行し、テストモードに入ったらOutputを確認します。
そこに Hello, world! と表示されていれば成功です。

この確認は見た目以上に価値があります。
3D空間に派手な変化がなくても、スクリプトが実行され、ログとして結果が残るところまで到達したことで、「Studioでコードを動かす流れ」がひと通りつながったことになるからです。
最初の学習では、このひと巡りを自分の手で通せるかどうかが大きな分かれ目になります。

もし文字が出ない場合は、まずOutputウィンドウ自体が表示されているかを見ます。
そのうえで、編集画面のままではなく、きちんとPlayでテストモードに入っているかを確認します。
ここが揃っていないと、コードを書いたのに何も起きないように見えて止まりやすい場面です。

結果確認の場面では、Hello, world! がOutputに表示されている状態のスクリーンショットも入れておくと、成功状態のイメージが一気に具体的になります。
ExplorerでのScriptの位置と、Outputに出た文字列の2枚がそろうと、このセクションだけで「追加した」「書いた」「動いた」の流れを視覚でも追えます。

初心者が最初に覚えたいLuau文法5つ

LuauはLua 5.1をベースにしたシンプルな文法で書けるので、入門段階では覚える項目を絞るほど前に進みやすくなります。
最初は変数、文字列と数値、if、for、関数の5つだけ押さえれば、print で結果を確かめながら小さな処理を組み立てられます。
とくに local を付ける習慣は早い段階で身につけておくと、その後のバグが目に見えて減ります。
local を付け忘れて意図せずグローバル変数になっていた、というのは最初に何度も出会う典型的なつまずきです。

変数とlocalの意味

変数は、数値や文字列を名前付きで保存しておく箱のようなものです。
Luauではまず local を付けて変数を作る書き方を基準にすると、どこで使う値なのかがはっきりします。
入門の段階では「変数を作るときは基本的に local を付ける」と覚えておくと混乱が減ります。

local がない変数はグローバル変数として扱われます。
最初のうちは1本のスクリプトしか触らないので違いが見えにくいのですが、処理が増えると別の場所から同じ名前を触ってしまい、思わぬ上書きが起きます。
ここを曖昧にしたまま進むと、「なぜ値が変わったのかわからない」という状態に入りやすくなります。

local score = 10
local playerName = "Kou"
print(playerName)
print(score)
-- localでこのスクリプト内の値として扱う基本形

この段階では型注釈まで広げなくて構いません。Luauには型注釈がありますが、入門では「値を入れて名前を付ける」動きが理解できれば十分です。

文字列と数値

文字列は "Hello" のように引用符で囲んだ文字データで、数値は 10 や 3.5 のようにそのまま書きます。
見た目が少し似ていても、"10" は文字列、10 は数値なので、扱いは同じではありません。
ここを早めに区別できると、計算と表示の違いがつかめます。

初心者のコードでよくあるのが、数字を表示したい気持ちのまま "100" と書いてしまい、その後に計算しようとして止まる流れです。
数を増やしたいなら数値、文章として出したいなら文字列、という感覚で切り分けると整理しやすくなります。

local coins = 100
local message = "Coins"
print(message)
print(coins + 50)
-- 文字列は表示用、数値は計算用として使い分ける

Luauは文字列と数値の違いがはっきりしているので、まずはこの2種類を正確に書き分けるだけでコードの意味が読み取りやすくなります。

if文

if 文は、条件によって処理を分ける文法です。
「スコアが一定以上なら表示を変える」「体力が0なら終了する」といったゲームの基本処理は、ほとんどこの形で作れます。
最初は「条件が正しいときだけ中の処理が動く」と理解すれば十分です。

条件分岐で詰まりやすいのは、比較したい値をあいまいに書いてしまう場面です。
if score >= 10 then のように、何と何を比べているかが見える形で書くと、Outputを見ながら動作を追いやすくなります。

local score = 12
if score >= 10 then
	print("Clear")
end
-- 条件がtrueのときだけprintが実行される

この書き方に慣れると、後で else を足して「成功ならA、失敗ならB」という分岐にも自然につなげられます。

forループ

for ループは、同じ処理を決まった回数だけ繰り返す文法です。
たとえばカウント表示、複数回のテスト出力、同じ部品の生成など、ゲーム制作では繰り返し処理が頻繁に出てきます。
入門ではまず、1から5まで順番に表示するような短い例で動きをつかむのが近道です。

繰り返しは手で5回書いても一応動きますが、回数が増えた瞬間に管理が崩れます。
for を覚えると、回数を数字でまとめて扱えるので、コードの見通しが一気に良くなります。

local total = 0
for i = 1, 3 do
	total = total + i
end
print(total)
-- 1から3まで足して合計を出す基本形

i はループごとに変わる一時的な数字です。ここでも local に近い感覚で、その場だけで使う値として読むと理解しやすくなります。

関数

関数は、処理に名前を付けてまとめるための文法です。
同じ処理を何度も書かずに済むので、コードが伸びてきたときに特に効いてきます。
入門段階でも「表示をまとめる」「数値を受け取って返す」といった小さな関数を作れると、文法のつながりが見えてきます。
関数は処理に名前を付けてまとめ、あとで呼び出して再利用する仕組みです。
変数、if、for を覚えたあとに関数を学ぶと、それらを組み合わせてまとまった処理が書けるようになります。

local function greet(name)
	print("Hello, " .. name)
end
greet("Player")
-- 関数を定義してから名前付きで呼び出す

この例では name が関数に渡された値です。
なお、Luauには local function greet(name: string) のような型注釈も書けますが、入門では補足程度にとどめ、まずは「関数を作る」「呼び出す」という流れを手で覚えるほうが前に進みます。

Robloxでよく使う3種類のスクリプトの違い

Script、LocalScript、ModuleScript は名前が似ていますが、役割ははっきり分かれています。
ここを最初に整理しておくと、「コードは合っているのに動かない」という詰まり方が一気に減ります。
特に初心者は置き場所でつまずきやすく、UI用のLocalScriptをWorkspaceに入れてしまって「動かない」と止まる場面を何度も見てきましたが、実際はコードより配置の問題であることが多いです。

Script

Script はサーバー側で実行されるスクリプトです。
ゲーム全体で共有される処理、ワールドのルール、サーバーイベントの管理などは基本的にここで扱います。
たとえばパーツに触れたら何かを起こす、ラウンド進行を管理する、全プレイヤー共通の状態を更新するといった処理は Script の担当です。

置き場所としては、WorkspaceかServerScriptServiceがよく使われます。
ワールド内のオブジェクトに密着した処理ならWorkspace内のパーツに入れる形でも動きますし、ゲーム全体のロジックをまとめるならServerScriptServiceに置くと管理が整理されます。
とくにサーバー専用のコードはServerScriptServiceに集めると、3Dオブジェクトと処理が混ざらず見通しが良くなります。

たとえば、パーツに触れたプレイヤーを判定して何かを配る処理は Script が自然です。
Touched のようなワールド側イベントは、UIではなくゲーム世界の出来事だからです。
こうした処理をLocalScriptで書き始めると、見えている画面の都合とゲーム全体の状態が混ざって、あとで修正箇所が増えます。

LocalScript

LocalScript はクライアント側で実行されるスクリプトです。
プレイヤーごとの画面表示、入力、カメラ制御、ツールの手元演出など、そのプレイヤーにだけ関係する処理を担当します。
ボタンを押したときにGUIを開く、キー入力でエフェクトを出す、視点を切り替えるといった場面では LocalScript を使います。

代表的な置き場所はStarterPlayerScripts、StarterGui、そしてToolの中です。
StarterPlayerScriptsに置いたものはプレイヤー参加時に PlayerScripts にコピーされて動きます。
StarterGui内の ScreenGui と組み合わせれば、UI操作の処理を書けます。
Toolの中に入れたLocalScriptは、プレイヤーのバックパックやキャラクターに入ったタイミングで動く構成が定番です。

UIを動かしたいのに LocalScript をWorkspace直下へ置いてしまうミスがあります。
コードの書き方を何度見直しても反応しないので混乱しやすいのですが、原因は文法ではなく実行場所です。
置き場所を図で整理すると一気に腑に落ちることが多く、Script はサーバーの場所、LocalScript はプレイヤー側の場所と覚えるだけで判断がぶれにくくなります。

creator-docs/content/en-us/reference/engine/classes/StarterPack.yaml at main · Roblox/creator-docs

Open Source Creator Documentation. Contribute to Roblox/creator-docs development by creating an account on GitHub.

github.com

ModuleScript

ModuleScript は単体では実行されない共有用スクリプトです。
require で呼び出して使う前提なので、Script や LocalScript の補助役と考えると整理しやすくなります。
同じ計算処理や共通関数を複数の場所で使いたいときに、コードを1か所へまとめられます。

たとえば、ダメージ計算、アイテム名の一覧、便利関数の集まりなどは ModuleScript に切り出すと重複を減らせます。
ひとつの Script に全部書き込む形でも最初は動きますが、処理が増えると修正のたびに同じコードを何か所も直すことになります。
ModuleScript に分けておけば、変更点が集約されるので保守の手間が小さくなります。

再利用しやすいだけでなく、テストしたい処理を分けやすいのも利点です。
UI処理と計算処理が同じファイルに詰まっていると、どこで壊れたのか追いづらくなりますが、ModuleScript に計算だけ切り出しておけば、呼び出し元と中身を切り分けて確認できます。
入門では補助的な存在に見えても、中規模以上のゲームではコードを増やしすぎないための土台になります。

初心者の置き場所チェックリスト

迷ったときは、「誰のための処理か」で切り分けると判断しやすくなります。
全員に共通するゲームのルールならサーバー、目の前の画面や入力ならクライアント、両方から使いたい共通処理なら共有用です。

初心者向けの使い分け例にすると、コインに触れたら加算する処理は Script、ボタンを押してメニューを開く処理は LocalScript、スコア計算の共通式は ModuleScript です。
この3つを混ぜずに置くだけで、コードが動く理由と動かない理由が追いやすくなります。
特に最初のうちは、「見た目を動かすなら LocalScript、ゲーム全体を動かすなら Script、共通化するなら ModuleScript」という形で覚えると迷走しにくくなります。

1つ作って理解する｜Partに触れたらメッセージを出すサンプル

ここでは、短いLuauコードを実際のゲーム挙動に結びつけます。
キャラクターがパーツに触れた瞬間に反応が返るだけで、「コードが世界を動かしている」という感覚が一気に出てきますし、入門段階では長い処理よりも10行以内の小さなサンプルのほうが、どこで何が起きたのかを追いやすくなります。

Partを置く

まずは触れる対象になるパーツを1つ用意します。
上部のHomeタブからPartを選び、Blockを追加してください。
作成したパーツはWorkspaceに入り、3Dビュー上に見える状態になります。

追加したパーツを選んだら、Propertiesで Anchored を有効にします。
これで重力で落ちなくなり、テスト中に位置がずれません。
名前はExplorerから TouchPart に変更しておくと、あとで何のためのパーツかすぐ判別できます。
最初の学習では、色やサイズを少し変えて「ここに触れる」と見た目でわかるようにしておくと、テスト時の迷いが減ります。

次に、Explorerで TouchPart を右クリックしてInsert Objectから Script を追加します。
今回はワールド内のパーツに触れたことを判定したいので、TouchPart の中に Script を入れる形がいちばん素直です。
前のセクションで整理した通り、こうしたワールド側の反応は Script で扱うと筋が通ります。

Touchedイベントの書き方

Touched は、パーツに何かが接触したときに呼ばれるイベントです。
イベント関数には、ぶつかった相手のパーツが hit として渡されます。
プレイヤーの体の一部が触れたかを見分けるには、hit.Parent からキャラクターをたどり、その中に Humanoid があるかを確認します。

まずこれを書いてみてください。短く保つことが理解の近道なので、入門では print だけで十分です。

script.Parent.Touched:Connect(function(hit)
	local character = hit.Parent
	local humanoid = character and character:FindFirstChildOfClass("Humanoid")
	if humanoid then
		print("TouchPartにプレイヤーが触れました")
	end
end)

このコードでは、script.Parent が TouchPart を指します。
そこに誰かが触れると関数が動き、接触相手の親に Humanoid があれば、プレイヤーのキャラクターが触れたと判断できます。
壁の破片や別のパーツではなく、プレイヤー接触だけを拾えるので、ゲームのスイッチやチェックポイントの最初の形としてそのまま応用できます。

“触れたら反応する”という体験は、ゲーム作りの手応えが一気に増す場面です。
if humanoid then の1行が入るだけで、ただの接触検知が「プレイヤーにだけ反応する仕組み」に変わり、文法がルールとして見えてきます。

Playで動作確認

コードを書いたら、ViewタブでOutputを表示しておきます。
print() の結果はここに出るので、テスト前に開いておくと挙動を追いやすくなります。
エラーが出た場合もこの画面で確認できます。

その状態でPlayを押し、スポーンしたキャラクターを TouchPart まで移動させて接触します。
うまく動けば、Outputに TouchPartにプレイヤーが触れました と表示されます。
見た目には何も起きなくても、まずは文字が出れば成功です。
画面上の変化を作る前に、判定そのものが通っていることを確かめる段階だと考えると整理しやすくなります。

成功した状態は、キャラクターがパーツに触れた直後にOutputへメッセージが1行出る形です。
記事や学習メモに残すなら、このOutput表示の場面をスクリーンショットにしておくと、どこまでできたかが一目でわかります。

反応しないときは、まず Script が TouchPart の中に入っているかを見ます。
次に、編集した対象が本当に TouchPart かを確認します。
名前を変更したつもりで別のパーツを触っているケースはよくあります。
なお、今回のような基本サンプルでは Anchored を入れていること自体が原因とは限りません。
動かないときは、アンカーより先に、スクリプトの置き場所と対象パーツの取り違えを疑ったほうが詰まりにくくなります。

Luauの型注釈とstrictモードはいつ使う？

Luauでは、型注釈とファイル先頭のモード指定を使うことで、書いている途中にミスへ気づける量が増えます。
入門の最初から必須ではありませんが、print や Touched の基本に慣れてきた段階で触れておくと、あとでコード量が増えたときに詰まり方が変わります。
特にRoblox Studioの補完と組み合わさると、タイプミスや予期しない nil を早い段階で見つけやすくなります。

--!strict / --!nonstrict / --!nocheckの違い

Luauでは、ファイルの先頭に書くコメントで型チェックの姿勢を切り替えられます。よく使うのは --!strict と --!nonstrict です。

--!nonstrict は、明らかにおかしい箇所を拾いつつ、まだ書きかけのコードも比較的そのまま進めやすい設定です。
学び始めの段階ではこちらでも十分で、まず「動くものを作る」流れを止めません。

--!strict は、より踏み込んで不整合を見つけます。
変数名の打ち間違い、戻り値の型の食い違い、nil の混入に気づきやすくなるので、スクリプトが長くなるほど効いてきます。
授業やクラス制作の場でも、--!strict に切り替えた瞬間に未定義変数のうっかりバグがまとめて表に出てきて、先に見つかって助かったと感じる場面が何度もありました。
実行してから気づくより、書いた直後に止めてもらえるほうが修正範囲が小さく済みます。

--!nocheck は型チェックをほぼ無効にする方向の指定です。
学習用途では得られる利点が少なく、入力補完の助けも弱くなるため、入門では選ぶ理由がほとんどありません。

感覚としては、次のように捉えると整理しやすくなります。

型注釈の最小サンプル

型注釈は、変数や関数に「この値は何の種類か」を添える書き方です。
最初は string と number だけで十分です。
難しい型を一気に覚えるより、普段の変数名の横に少し情報を足す感覚で使うと入りやすくなります。

まずは変数です。

local playerName: string = "Kou"
local score: number = 100

これだけでも、Roblox Studioの補完が文脈を掴みやすくなりますし、文字列のつもりだった変数に数値を入れてしまうミスも見つけやすくなります。

関数では、引数と戻り値に型を付けられます。

local function add(a: number, b: number): number
	return a + b
end

local function greet(name: string): string
	return "Hello, " .. name
end

こうしておくと、add("10", 20) のようなコードを書いた時点で違和感を出せます。
実行してから崩れるのではなく、編集段階で気づけるのが大きいところです。
入門ではここまでで十分で、RobloxのAPI固有の型やOptional型まで広げなくても、型注釈の価値はすでに体感できます。

初心者はいつstrictに移行するべきか

最初の数本は --!nonstrict で進めても問題ありません。
文法そのもの、if、関数、イベント接続といった基本を覚える段階では、「警告の意味を読むこと」より「何を書いたら何が起きるか」を掴むほうが優先だからです。

移行の目安になるのは、変数が増えてきたときです。
たとえば、1つのスクリプトでプレイヤー名、得点、状態フラグ、参照先のオブジェクトを同時に持ち始めると、うっかり別の名前で書いた変数や、まだ値が入っていないまま使った変数が混ざりやすくなります。
そういう段階で --!strict を入れると、バグが動作確認の前に炙り出されます。
Output にエラーが出てから追いかける回数が減るので、修正の流れも短くなります。

学習の順番としては、短いサンプルを数本作ったあとに --!strict を試すのがちょうどいい位置です。
最初から全ファイルを厳密にするより、新しく作る小さな ModuleScript や計算用の関数から始めると、警告の意味を理解しながら進められます。
Luauの型機能は初心者をふるい落とすためのものではなく、慣れてきた人の手戻りを減らすための道具です。
その感覚で使い始めると、窮屈さより安心感のほうが先に来ます。

つまずきやすいポイントと次のステップ

詰まったときに読む場所は、文法の解説より先に「どこで確認し、どこに置き、どのモードで動かしているか」です。
初心者のエラーはコードそのものより、Output を開いていない、Script の置き場所が違う、LocalScript が動かない場所に置かれている、といった実行条件の取り違えで止まる場面が多くを占めます。
ここを先に整えるだけで、自力で直せる範囲が一気に広がります。

よくあるエラーの原因チェックリスト

まず確認したいのは、実行結果をちゃんと見える状態にしているかです。
print() が出ない、エラーが見当たらないと感じるときは、上部のViewタブからOutputを表示してください。
実行確認は編集画面で眺めるのではなく、必ずPlayのテストモードで行います。
赤字のエラーが出たら、その行を開いてから直す流れにすると、手探りでコード全体を見直す回数が減ります。

次に見直すべきなのは、スクリプトの種類と配置先の組み合わせです。
前述の通り、Script はサーバー側、LocalScript はクライアント側、ModuleScript は単体では実行されません。
ここがずれると、文法が正しくても何も起きません。

特に多いのが、LocalScript をWorkspace直下に置いて「動かない」となるケースです。
相談を受けると、この手の詰まりの大半はコードではなく置き場所で、Explorer の図と具体的なパスを一度示すだけで、その場で解決することが珍しくありません。
たとえば、プレイヤー入力を扱うならStarterPlayer > StarterPlayerScripts、GUI を動かすならStarterGui > ScreenGui > LocalScriptという形まで具体化すると、迷いが消えます。

StudioでのDataStore注意点

DataStore を試したのに保存できない場合は、スクリプトの書き方より先にStudioの設定を疑ってください。
DataStore はStudioテストで最初から使える状態ではなく、保存系のコードを書いただけでは通りません。
テスト時に API へのアクセスを許可していないと、保存や読み込みがブロックされます。

設定まわりでは、Game SettingsのSecurityにある Enable Studio Access to API Services を確認してください。
外部 HTTP 通信を使う処理では Allow HTTP Requests も関わりますが、DataStore の学習でまず意識するのは Studio から API サービスへ触れる許可のほうです。
保存処理は失敗する前提で組む必要があるので、実装時は pcall で包んで成功と失敗を分けて扱う流れにしておくと、原因の切り分けが進みます。

StudioのUI名や配置は更新で変わることがあるため、公開前や作業前に実際の画面で表記を見ておくと食い違いを避けられます。
ViewHomeTestまわりは表示位置が入れ替わることがあるので、ボタン名だけ覚えるより、役割で覚えるほうが詰まりません。

次に学ぶトピック

ここまで進んだら、次は「反応する仕組み」「見える仕組み」「残す仕組み」の順で広げると手が止まりにくくなります。
ひとつ目はイベントです。
Touched に慣れたら、クリック系の反応や、クライアントとサーバーをつなぐ RemoteEvent に進むと、ゲームらしいやり取りが増えてきます。

ふたつ目はGUIです。
StarterGuiに ScreenGui と TextLabel を置き、LocalScript から文字を変えるだけでも、ワールド内の出来事を画面に伝えられるようになります。
3D空間の処理とUIの処理が分かれて見えてくると、スクリプトの役割分担も自然に理解できます。

もうひとつ見逃せないのが保存処理です。
作ったスコアや通貨、進行状況を次回に持ち越したいなら DataStore が必要になります。
イベントで反応し、GUIで表示し、保存処理で状態を残すところまでつながると、練習用のサンプルから「ゲームの仕組み」へ一段進めます。
次にコードを書くなら、この3本柱のどれかを小さく1つ作ると、学習が前に転がり続けます。