Scratch への提案

h_team_x

ちょっと却下理由が不足しているとして再々提案
COOKIE実装
実装方法:変数のモードとして
見た目（案）

[ v] を [] にする
[ v] を [] ずつ変える
()

問題点1に対して:それを言うならlogとか他にもわかりにくいブロックってあると思います。
周知（アイデアなどで）しとけばいいと思います。
問題点2に対して:クラウド変数では限界があり、また、全世界が見れる可能性があります。
セーブコードを保存できない端末もあります（メモ帳が使えない、紙に書くには長すぎるなど）
不足点があれば教えてください。

h_team_x

皆さんへ
ポジティブな投稿を心がけてください。
即座に却下などは、建設的な投稿とは言えません。

問題点があったとして、それを解決する案を出したほうがいいです。
代用可能だけで却下することは普通ありません。
却下に十分な理由として一応上げときます。

メリットがない
デメリットをメリットが下回る
それらの解消のしょうがない

Last edited by h_team_x (Aug. 16, 2026 09:46:34)

short-KUSA

#9503
クッキーの却下理由を見ると

5. cookie（使用例：簡易的なオートセーブ等）
作品から直接 Cookie を操作するブロックができたとして
「（名前は違うとしても）Cookie って何？」というところからはじまって
混乱するだけとなる可能性が高い。
クラウド変数である程度のこともできる（今回追記：セーブコード方式も代用手段となる）
→ 却下

となっています(https://scratch.mit.edu/discuss/topic/590645/?page=11#post-9070254)
混乱するのならば拡張機能とするのはどうなのでしょうか？

h_team_x

short-KUSA wrote:
#9503
クッキーの却下理由を見ると
ry
→ 却下
となっています(https://scratch.mit.edu/discuss/topic/590645/?page=11#post-9070254)
混乱するのならば拡張機能とするのはどうなのでしょうか？

一応私が考えてた2種のモデルと比較
1.cookieは一つ→確かに拡張機能でもいいと思います。そこなら使える人が使う感じになりますし…
2.cookieは複数→こちらでは拡張機能よりも変数のオプションのほうがいいでしょう。
一応どちらがいいかはみなさんに委ねます。

inoking

※元の文章が後から編集されて変わっています。

#9504:

h_team_x wrote:
皆さんへ
ポジティブな投稿を心がけてください。
即座に却下など、建設的な投稿とは言えません。

問題点があったとして、それを解決する案を出したほうがいいです。
却下に十分な理由として一応上げときます。
メリットがない
デメリットをメリットが下回る
それらの解消のしょうがない

「ポジティブ」、「建設的」とは何でしょうか？
建設的 - デジタル大辞泉：

ある物事についてその良さを支持し、より良いものに変えていこうとするさま、あるいは積極的に物事を推進しようというさまなどを意味する表現。

どういうものが Scratch への提案としてふさわしいかは
#1 に書かれています↓。

「ここで提案しても却下される」と言う方へ：
#798 および、旧トピックの #3983, #4416, #4971 も読んでみてください。
このエッセイも読んでみてください。

何でも「はいはい、いいですね」と肯定するのが「建設的」とは思えません。
むしろ、
Scratch という事情やトピックでの過去の議論などをちゃんと把握せず提案するほうが「非建設的」だと思います。
※クッキーの再提案がそうだとは言っていません

逆に言うと、Scratch という事情やトピックでの過去の議論などをちゃんと把握することで
はじめて提案の土俵に上がったと言えます。

Last edited by inoking (Aug. 16, 2026 09:56:49)

inoking

#9503:

h_team_x wrote:
問題点1に対して:それを言うならlogとか他にもわかりにくいブロックってあると思います。
周知（アイデアなどで）しとけばいいと思います。

log などは「絶対値」などと同列の選択肢として出てくることから何らかの演算をするものであることは分かります。
今細かい演算内容まで分かる必要はありません。
そして、log などは高校数学で習う一般的な数学関数です。
興味のある人が調べればよいだけです。
事実、sin などはよく質問されています。

それに対し、クッキーは分かりにくいといっても全く異なるブラウザーの実装技術です。

h_team_x wrote:
問題点2に対して:クラウド変数では限界があり、また、全世界が見れる可能性があります。
セーブコードを保存できない端末もあります（メモ帳が使えない、紙に書くには長すぎるなど）

「クラウド変数である程度のこともできる」と書いてあります。
他人に見られても、エンコードデコードの話になるのでこれも工夫次第です。
そもそも、ローカルで完全に秘匿する機能を提供する必然性もありません。
逆にクッキーではプロジェクト間共有できてしまうといった新たな課題も出てきます。

inoking

short-KUSA wrote:
#9503
クッキーの却下理由を見ると
5. cookie（使用例：簡易的なオートセーブ等）
作品から直接 Cookie を操作するブロックができたとして
「（名前は違うとしても）Cookie って何？」というところからはじまって
混乱するだけとなる可能性が高い。
クラウド変数である程度のこともできる（今回追記：セーブコード方式も代用手段となる）
→ 却下
となっています(https://scratch.mit.edu/discuss/topic/590645/?page=11#post-9070254)
混乱するのならば拡張機能とするのはどうなのでしょうか？

拡張機能にすればOKというのも安易な解決策です。
現在拡張機能として用意されているのは以下です。
　音楽、ペン、ビデオモーションセンサー、顔認識、
　音声合成、翻訳、Makey Makey、micro:bit、
　Go Direct Force & Acceleration、LEGO MIND SDTORMS EV3、LEGO BOOST、LEGO Education WeDo 2.0
ここに
　クッキー(Cookie)
が入るのは明らかに異質です。

別のシステムの機能を持ってこようとする前に
それが Scratch の事情（根本理念、ユーザー層などなど）に合うかどうかをよく考える必要があると思います。

short-KUSA

#9512を読んで納得したため返答が来る前に消去

Last edited by short-KUSA (Aug. 16, 2026 07:26:09)

h_team_x

他プロジェクトへの接続がダメな理由がわからない…
一応
仕様として考えてるもの
・1プロジェクトにつきXつ
・他プロジェクトには完全に遮断
・入力可能なものは英数字と記号

また、拡張機能としては確かに異質かもしれませんね…
一応、「わかりにくい機能」の例として挙げただけで、logがわかりにくいとは言ってません。す。
クラウド変数だってその一つに入ると思います。
私としての主張は、

ham wrote:
2.cookieは複数→こちらでは拡張機能よりも変数のオプションのほうがいいでしょう。

に固めます。
追記:指摘を受けて。

Last edited by h_team_x (Aug. 16, 2026 07:58:20)

inoking

途中まで返答を書いていました。

short-KUSA wrote:
#9510
なぜクッキーが入るのは異質だと思うのですか？

↓

short-KUSA wrote:
#9512を読んで納得したため返答が来る前に消去

#9512 には異質な理由は出てきていませんが
それでなぜ納得したのか気になります。
他人が納得したら納得するのでしょうか。
※返答不要です

inoking

h_team_x wrote:
一応、「わかりにくい機能」の例として挙げただけで、logがわかりにくいとは言ってません。
クラウド変数だってその一つに入ると思います。

自分で例として挙げておいて「logがわかりにくいとは言ってません」とは
おかしな話です。
クラウド変数も何か言われると
「わかりにくいとは言ってません」となるのでしょうか。

自分の意見には責任をもってほしいものです。

h_team_x

すいませんでした。
logは(中2の)私が知らないだけでした。
一応、クラウド変数は「初心者は知らない」筈です。
なぜなら、学校では習わない筈だからです。
それを踏まえて2つめの例として挙げました。
ちなみに、何にしろ、チュートリアルなどでの周知の余地はあると考えています。
そのため、わかりにくさは結局、却下理由としては不十分だと考えてます。
そもそもcookieとかって高校や大学で習わなかったっけ？

gccxnondx

Scratchにあるブロックの中で学校では習わないものはたくさんあります。
逆三角関数(atan,acos,atan)(理系の大学の範囲)やe^ (高校生でも文系は習わない数III)もそうです。
「学校で習わない筈」というのは却下理由になりえません。それは「当たり前」と言えるのではないでしょうか。
知らないなら知ってる人から教えてもらえば良いのではないでしょうか?

Last edited by gccxnondx (Aug. 16, 2026 08:36:49)

h_team_x

gccxnondx wrote:
Scratchにあるブロックの中で学校では習わないものはたくさんあります。
逆三角関数(atan,acos,atan)(理系の大学の範囲)やe^ (高校生でも文系は習わない数III)もそうです。
「学校で習わない筈」というのは却下理由になりえません。
知らないなら知ってる人から教えてもらえば良いのではないでしょうか?

どっちにむかっていっているのかわかりませんが確かにそうです。そして、cookieも同じ筈です。

inoking

h_team_x wrote:
一応、クラウド変数は「初心者は知らない」筈です。
なぜなら、学校では習わない筈だからです。
それを踏まえて2つめの例として挙げました。
ちなみに、何にしろ、チュートリアルなどでの周知の余地はあると考えています。
そのため、わかりにくさは結局、却下理由としては不十分だと考えてます。
そもそもcookieとかって高校や大学で習わなかったっけ？

クラウド変数は分かりにくいといっても
作成時の「サーバーに保存する」というだけである程度は分かるでしょう、
オンラインドキュメントに慣れている現在のユーザーが「サーバーが分かりません」とはならないでしょう。
なお、「サーバー」は中学などでも習うようですし
「クラウド」は「クラウドサービス」などもはや一般用語です。

ちなみに、
クッキーは一般的な教育課程では、つまり、Web の専門コースでもないかぎり習わないでしょう。

習う習わないの問題ではありませんが。

Last edited by inoking (Aug. 16, 2026 08:39:52)

inoking

これまでの却下理由にはありませんが、
クッキーは
ブラウザ内部のストレージであり、HTTP の仕組みの範ちゅうです。
また、セキュリティの設定が複雑でブラウザーごとの細かい制御もあります。
さらに、プロジェクト間共有の懸念（悪用されるリスク）もあります（弾けばいいという問題ではない）。
このようなことがある中で機能を入れる必然性もない。
というのが私の意見です。

h_team_x

他プロジェクトへの接続がダメな理由がわからない…
確かに、メリット＜デメリットと成り得りますね。
一応意見を添えます。(赤が私)

inoking wrote:
これまでの却下理由にはありませんが、
クッキーは
ブラウザ内部のストレージであり、HTTP の仕組みの範ちゅうです。

それ自体に問題はない

また、セキュリティの設定が複雑でブラウザーごとの細かい制御もあります。

互換性…一定までなら特に影響が出なさそうですね

さらに、プロジェクト間共有の懸念（悪用されるリスク）もあります（弾けばいいという問題ではない）。

他プロジェクトへの接続がダメな理由がわからない…ここが現状一番の問題?でしょうか…

このようなことがある中で機能を入れる必然性もない。

無いわけじゃない（#9503)
最後の1文は不要と判断し削除

Last edited by h_team_x (Aug. 16, 2026 10:14:40)

inoking

#9520:

h_team_x wrote:
他プロジェクトへの接続がダメな理由がわからない…
確かに、メリット＜デメリットと成り得りますね。
一応意見を添えます。(赤が私)
inoking wrote:
これまでの却下理由にはありませんが、
クッキーは
ブラウザ内部のストレージであり、HTTP の仕組みの範ちゅうです。それ自体に問題はない
また、セキュリティの設定が複雑でブラウザーごとの細かい制御もあります。互換性…一定までなら特に影響が出なさそうですね
さらに、プロジェクト間共有の懸念（悪用されるリスク）もあります（弾けばいいという問題ではない）。他プロジェクトへの接続がダメな理由がわからない…ここが現状一番の問題?でしょうか…
このようなことがある中で機能を入れる必然性もない。無いわけじゃない（#9503)
というのが私の意見です。皆さんご存知の通り必ずしも意見≠事実ではない

quote の中を編集しないでください。
文責があいまいになります。

自分の意見は分けて書いてください。

h_team_x

#9508の確認が遅れました。

inoking wrote:
#9504:
h_team_x wrote:
省略
「ポジティブ」、「建設的」とは何でしょうか？

1一応、ポジティブと言う言葉を出したのは、次の言葉にもある通り提案に対して即消極的なの発言をしないでねと言う意味で出しました。

建設的 - デジタル大辞泉：
ある物事についてその良さを支持し、より良いものに変えていこうとするさま、あるいは積極的に物事を推進しようというさまなどを意味する表現。
どういうものが Scratch への提案としてふさわしいかは
#1 に書かれています↓。

2読んで少し書き換えました。

「ここで提案しても却下される」と言う方へ：
#798 および、旧トピックの #3983, #4416, #4971 も読んでみてください。
このエッセイも読んでみてください。

何でも「はいはい、いいですね」と肯定するのが「建設的」とは思えません。
むしろ、
Scratch という事情やトピックでの過去の議論などをちゃんと把握せず提案するほうが「非建設的」だと思います。
※クッキーの再提案がそうだとは言っていません

逆に言うと、Scratch という事情やトピックでの過去の議論などをちゃんと把握することで
はじめて提案の土俵に上がったと言えます。

私の言いたいことと若干離れてる気がします。

Last edited by h_team_x (Aug. 16, 2026 10:15:44)

1233458

#9518
“Cookie”という言葉が伝わらないのであれば、「セーブ」「一時保存」…のようにわかりやすい表記をするのはどうですか
勿論、語弊はありますが、伝わり方に問題はないような気がします。

Discuss Scratch