お家教室部活商店街遊び場
アバターでつながる、永遠の放課後
ホーム›ブログ›開発記›clusterで配布ギミックが3時間動かなかった話 — ScriptableItem の「静かな失敗」の正体

clusterで配布ギミックが3時間動かなかった話 — ScriptableItem の「静かな失敗」の正体

開発記2026-06-01baku

目次

  • 何を作ろうとしていたか
  • 3時間、何も起きなかった
  • 原因:ScriptableItem は「コールバックを登録」する
  • 抜け出せた決め手:「動いているもの」を正典にする
  • 個人運営で学んだ3つのこと
  • なぜこれを公開するのか
  • 参考(cluster 公式)

結論から書きます。cluster で「触ったらアイテムを配る」ギミックが、3時間まったく動きませんでした。 エラーすら出ない、完全な沈黙。原因は、ScriptableItem のイベントを「代入」で書いていたこと。正しくは「コールバックを登録」する書き方でした。そして抜け出せた決め手は、推測をやめて「すでに動いているギミック」を正典にしたことです。

順番にお話しします。

何を作ろうとしていたか

私は、Tapiava のコミュニティ「タピアバの学校」を cluster で運営していて、入学式のライブイベントを開いたことがあります。その準備中(本番の前日)に作っていたのが、来場者にデジタルの「生徒手帳」を配るギミックでした。

やりたかったことはシンプルです。

  • アイテムに触る(インタラクトする)
  • 触ったその人に、手帳を渡す

cluster には ScriptableItem(アイテムにスクリプトで動きをつける仕組み)があり、これで実現できるはず——そう思って書き始めました。

3時間、何も起きなかった

ところが、いざワールドに入って触っても、うんともすんとも言わない。

つらいのは、エラーが出ないことでした。スクリプトのどこかが赤くなってくれたら、まだ手がかりになります。でも何も起きない。コードは一見ちゃんとしている。「保存し忘れ?」「アイテムの設定?」「触る判定?」と、あちこちを疑っては直し、また触っては沈黙。これを延々と繰り返して、気づけば3時間が溶けていました。

原因:ScriptableItem は「コールバックを登録」する

落ち着いて公式ドキュメントを読み直して、ようやく腹落ちしました。

cluster の ScriptableItem では、プレイヤーの操作に反応する処理を、コールバック関数を「渡して登録」する形で書きます。インタラクトに反応させたいなら、こうです。

// ✅ 正しい:コールバックを「登録」する
$.onInteract((player) => {
  // 触ったプレイヤーに対する処理をここに書く
});

ところが私は、なんとなくの直感で、こう書いていました。

// ❌ これだと何も起きない(沈黙する)
$.onInteract = (player) => {
  // ...
};

onInteract に関数を代入してしまっていたんです。onInteract は「登録するための関数を呼ぶ」もの。なのに私は「プロパティに値を入れる」書き方をしていた。登録されないので、当然なにも呼ばれない。間違いではあるけれど"文法的には通ってしまう"ので、エラーにもならず、ただ静かに無視される——これが沈黙の正体でした。

ちなみに公式によると、この手のコールバックはスクリプトのトップレベルで登録し、同じものを複数回登録すると最後の登録だけが有効になります。知っていれば一発、知らないと一生気づけない類のやつです。

抜け出せた決め手:「動いているもの」を正典にする

実は、原因そのものより大事な学びはこっちでした。

3時間ハマっていた間、私はずっと自分のコードを"推測で"いじっていました。でも沈黙する不具合は、推測で当てにいくと泥沼です。抜け出せたのは、すでに正しく動いている別のギミック(過去に作って問題なく動いているアイテム)を開いて、自分のコードと"差分"を取った瞬間でした。

並べて見れば一目瞭然。「あ、こっちは関数を渡して呼んでる。自分のは代入してる」。動く実物が、いちばん正確な仕様書だったわけです。

個人運営で学んだ3つのこと

  1. 沈黙する失敗ほど、推測でいじらない。エラーが出ない不具合は、「動いている実物」とのコード差分を取るのが最短ルート。
  2. APIの"形"を最初に確認する。「代入する値」なのか「呼んで登録する関数」なのか。ここを取り違えると、文法は通るのに動かない、という一番つらいパターンにハマる。
  3. 失敗の記録こそ、続けるための資産。1人で運営していると、こういう詰まりは全部自分に降ってきます。でも、記録しておけば次の自分(とだれか)の3時間を救える。

なぜこれを公開するのか

私は「個人とAIで、どこまで本物のサービスを作れるか」を、つまずきごと公開(build in public)しています。完成形だけ見せるより、この「3時間溶かした」みたいな手探りの記録のほうが、きっと誰かの役に立つと思うからです。

もしあなたが今まさに cluster の ScriptableItem で沈黙と戦っているなら——まず、動いているアイテムを開いて、onInteract を「代入」していないか見てみてください。それで救われる3時間が、どこかにありますように。


cluster でのイベントづくりや、つまずき・解決の話は、コミュニティでもよくしています。よかったらのぞいてみてください。

  • 🏫 タピアバの学校(Discord)

参考(cluster 公式)

  • ClusterScript | Cluster Creator Kit Script Reference
  • ItemScript | Cluster Creator Kit ドキュメント

— baku(Tapiava 運営)

関連記事

開発記

個人で小さなclusterイベントを「続ける」コツ — 入学式ライブからフォトコンまでの実録

clusterで入学式ライブやフォトコンテストなど、小さなイベントを個人で開いて「続けて」きました。一発の大きなイベントより続けることが効く理由と、登録者を大切にする・前向きに告知する・振り返りを残すといった、個人運営で学んだコツを実録で書きます。

開発記

ChatGPTとClaudeと私、3人の分業 — 個人開発でAIに「丸投げ」しない理由

「個人開発」と言っても、実際はChatGPTとClaude、そして私の3人チームです。AIふたりをどう使い分けているか、なぜ「丸投げ」は失敗するのか。個人とAIでものづくりをするときの分業の現実を、build in public で正直に書きます。

開発記

AIと作るコツは「考えさせる前に、調べさせる」 — 憶測でなく、人間の積み重ねの上で作る

AIと個人開発をして、いちばん効いたコツは「考えてもらう前に、徹底的に調べてもらう」ことでした。憶測で作らせず、人間がすでに積み上げた確かな情報の上で組み合わせる。そして気づいたのは——AIという存在そのものが、人間のこれまでの積み重ねから生まれた、ということです。

← ブログ一覧へAboutお問い合わせ特商法表記プライバシーポリシー
使い方ガイドブログ利用規約プライバシーポリシー特定商取引法に基づく表記
お家教室部活商店街遊び場