未分類

SILって何だろう


本ページは、 SILに関するコラム(その1) と、 SILに関するコラム(その2) に対してのご批判と、その後のご指導を頂いた、 「真っ赤なレモン @_red_lemon 」さん から頂いたSILに関する有益なご意見を、 可能な限り変更を加えず、掲載したものです。

今回、このような形で、「真っ赤なレモン @_red_lemon 」さんのご意見を 掲載させて頂くに至ったのは、

 

  • 「真っ赤なレモン @_red_lemon 」さん のSILのご解説が、恐しく分かりやすいこと
  • SILに関する基本的な概念を説明する書籍が、現時点において絶無であること
  • 今後の製造業のグローバル対応を考えた時、このご解説の内容は、技術者の皆さんにとって、素晴しく役に立つであろうこと

という理由に因ります。

この度、「真っ赤なレモン @_red_lemon 」さん のご許諾を頂き、この文章を公開 させて頂くことにしました。

なお、本文に関する文責は、全て、この文章を編集した江端智一に帰するものと致します。

2012年11月11日(日) 江端智一

 


Q SILってなんですか?

 

A SILとは、機械の信頼性に関する指標で、平均故障間隔(MTBF:Mean Time Between Failures)という考え方を使います。

簡単に言うと、

「昨日クーラーが壊れたので、今修理してもらった。次はいつ故障しそう?」

「そうだねえ、大体5年後かなぁ」

と言えば、この場合のMTBFは、5年=43800時間 となります。

SILとは、このMTBFで、その装置やシステムの信頼性を示す指標です。ざっくりこんな感じです。

・SIL0:MTBFが10年未満

・SIL1:MTBFが10年以上~100年未満

・SIL2:MTBFが100年以上~1000年未満

・SIL3:MTBFが1000年以上~1万年未満

・SIL4:MTBFが1万年以上~10万年未満

まず、SIL0(シルゼロ)、SIL1(シルワン)、SIL2(シルツー)……という分け方をしているのは、昼定食を「人件費と材料費が1647円の定食」というのを、単に「梅定食」と呼んでいるのと同じことで、単にこうしたほうが、理解と管理がラクというだけのことです。

 

Q SIL1やSIL2というのは分かります。SIL3,SIL4などというものがあるのは何故 ですか。これは、巨大事故発生時の被害者数の期待値と考えれば良いのですか。

 

A SILは製品の期待値がSIL2になるようにするための道具だ、と言ってよいです。

江端さんがコラムで書いている、

>「SIL2の私(原発、電車、旅客機)は、あんたの人生において、1度だけは、あんたを殺すかもしれないよ」ということです。

も、

>つまり、「人を殺すことを前提とした安全」の概念が含まれていると考えれば、SILを理解できるわけです。

も、全くそのとおりです。大局としては間違っていません。

では、私が気になったのはどこか。次の部分です。

>SIL3(MTBF:1000年~1万年未満)やSIL4(MTBF:1万年~10万年)がなぜ必要なのだろう? という疑問が残ります。その答えは「期待値」です。

この考え方の筋道は、的外れです。

SIL3やSIL4が必要な理由は、次の考え方からです。

 


「壊れない」製品を作ることは、できない。(←ここはあきらめている)

そこはあきらめないと、話が先に進まない。

現実を見て物事を前に進められる我々工学の世界の住人は、 理屈にこだわって何もできない人たちよりも、ずっとマシ!

では、どれくらいの頻度の故障だったら、世間は納得してくれるだろうか?



まあ、製品のSILがSIL2だったら、世間は納得してくれるんじゃね?

受容されるんじゃね?

(これは、まさにALARA。納得できるかどうかを厳密に突き詰めることはできない。  人それぞれの価値観の相違があるため、泥沼になる)



それはともかく、最近は部品の集積度が上がった。

「部品の集積度が高い製品」ほど、壊れる確率は高くなっちゃうよね。 どの部品が壊れるか分からないし、製品を使って100年もかかる試験が できるわけないよね。



部品単体なら、加速試験ができるんじゃね?

それに、部品単体のMTBFをすごーく長くしておけば、 製品での試験をしなくてもいいじゃん!

「そ、それだ!」



部品単体のMTBFをどれくらいにすれば、製品の試験をしなくてすむんだろう?

自動車の部品が、約1万個。そのうち、壊れたら安全性に関わる部品は 100個くらい。この100個が壊れなければ安全性には問題ない。

他の部品が壊れても、保証修理でタダで修理すれば済む話だし。

とすると・・・この100個の部品をSIL4(MTBF:1万年~10万年)に できれば、自動車じたいは、ざっと計算してSIL2(MTBF:100年~1000年)だ!



というワケで、部品メーカーのみなさん。SIL4の部品を我が社に納入してください。



部品メーカー「ええ~~!」


どんどんグダグダになっていきましたが、これが真相です。

部品の段階でのSILをSIL4まで上げておくと、 ほとんどの製品(全部品が約1万個、そのうち安全に関わる部品が約100個の製品)で、 ほぼSIL2が達成できます。そのために、SIL4が必要。

安全に関わる部品がもっと少ない場合は、SIL3で足ります。

製品メーカーは、部品代に高いお金を払うかもしれませんが、ラクをします。

なお、SILをいう考え方を自動車業界が強く推進している背景には、 電子部品が自動車に多数使用されるようになった、ということがあります。

電子部品は、機械に比べて部品の集積度が非常に高い。

それまでは自動車の部品を「できるだけ細かいレベルに分けて」数えても、 1万個程度でしたが、電子部品が使われるようになった途端に2~3万個に増えました。 (抵抗1個でもバラして4個と数えるような、極端な数え方ですけれど。)

SILは、「部品の集積度が高い製品」を前提とした考え方から生まれています。

 

Q SILがあって嬉しいことって何ですか?

 

A リスクを抽出し(想定し)、その個々のリスクレベルを全て「社会的に受容できる程度まで低減する」ことです。

これはISOに規定されていることです。

ISOの制定は欧州が主導しており、欧州の考え方の根底には「モノは壊れる。 人は間違える」があります。だから、考え方は「故障をゼロにする」のではな く、「モノは壊れる。人は間違える。それで発生するリスクを含めて、受容で きるレベルまでリスクを低減する。受容できるレベルまで低減されたリスクは、 社会が受け入れるべき」となり、現実的に安全性を確保していこうとしていま す。

つまりは、「社会に受容してもらう」=「人々に納得してもらう。納得させる」 ことも、メーカーにとっては重要になります。

どうやって人々に納得してもらうか。

モノをベースに、客観的な理解を得ようとする取り組みが、SILのような考え 方を導入する動機の一部分としてあります。

通常のメーカーはそうやって、なんとかお客さまや社会に納得してもらえるよ うに努力をしています。

しかし、この考え方には弱点もありました。

例えば、原発の場合、モノを変えずに人を納得させようとしました。

「中長時間の全電源喪失を考えなくて良い理由を作文して下さい」などといった、 モノや実態を見ずに口先だけで人を納得させようとする姑息なやり口をしました。

そして、作文能力の高い人が多かったのでしょう。 優秀な作文がたくさんできたでしょう。

人々は納得させられてしまいました。モノは何も変わっていないのに。 [事故が発生する頻度]は非常に低いものの、ゼロではありません。 それを、ゼロだと思わせ、想定外ということにしました。

 

Q SILが基準としている「物差し」は何ですか。

 

A 人命です。

「SILで想定している『故障』とは、人命に関わるような故障のみを指している」 ということは、知っておかなければなりません。

極端に言うと、

「『安全に停止できるような故障』なら、1年に何回起こってもかまわない」

ということです。

(もちろん、お客さまからクレームが来ないようにしなければなりませんので、  『安全に停止できるような故障』も減らそうとはします。)

 

Q 「SIL4」と言葉で言うのは簡単ですが、1万年以上故障しない部品なんて、 一体、どうやって実現するのですか?

 

A 基本的には電子部品のSIL4などは部品の多重化で達成します。

大雑把に書くと

Aという部品をSIL4にするためには Aの機能を達成する部品を作ります。aとします。

aを試験すると、SIL2でした。

(aの試験は、実際に時間をかけたり、加速試験をしたり、様々な方法で調べます。) aを2個(a1とa2と呼ぶ)、論理的に並列に(or回路、でしたっけ?)組み合わせて、 部品Aとします。

Aはa1とa2の両方が壊れないかぎり正常に機能しますので、

SIL2 × SIL2 = (100年に1回) × (100年に1回) = (10000年に1回) = SIL4

です。 掛け算って素晴らしい。or回路って素晴らしい。

ただこれは、電子部品のような小さい部品だから多重化が可能なのです。

機械部品(歯車とか)では、こうはいきません。

ただしジレンマもあります。

SILには、故障検知という考え方が、どこまでもつきまといます。

SIL2の部品であっても、その部品が故障したことを検知でき、故障検知するこ とで「製品を安全に停止できる」手段があるのならば、「人命に関わるような 故障」には至らないとできます。

できますが、そのためには故障検知するための部品を追加しなければなりませ ん。

そして、故障検知する部品は、たいていはセンサー、電気部品です。

はて?部品の数は減らしたいのに、安全のために部品を増やすとは?では、そ のセンサーが故障したらどうなるのか?センサーの故障を検知するセンサーも 必要?じゃあ、センサーの故障を検知するセンサーが故障したらどうなる の?・・・以下、延々と続きます。

結果として、故障を検知するセンサー部品は、SIL4にせざるをえないことが多 いです。

センサーがSIL4であれば、[SIL4のセンサー]と[SIL2の部品]を論理的に直列に 組み合わせることで(and回路にすることで)、「製品を安全に停止できる」 道は切り開けます。

ただし、センサーという部品が増えるということ自体の解決にはなりません。

なお、どうしてもSIL4の部品を論理的に直列に10個組み合わせた部品を使わな ければならない場合もあり、その場合は組み合わせた部品のSILはSIL3に下がっ てしまいます。

([SIL4]+[SIL4]+・・・+[SIL4]=[SIL4]×10=[SIL3])

そういう事情を勘案した上で、「SIL4の部品を論理的に直列に10個組み合わせ た部品」にはSIL3を割り振ってあげるという措置も必要になってきます。

 

Q ソフトウェアSILというのが、まったくチンプンカンプンです。 「ソフトウェアが1万年故障しない」という概念を、どうやって導き出すので すか?

 

A 天が導き出します。

製品の場合は、初めに機械の仕様を定めます。

「この製品は、10年の寿命(使用)を想定する」とか

「この製品は、30年の寿命(使用)を想定する」とか。

その時点で決定です。

部品の場合は、システム内の各部品に割り当てられます。

「各部品がそれぞれSIL0~4のどれであれば、システムとしてSIL4を達成できるか」 を検討して決定し、割り振るのが、『Vモデル』の前半です。

『Vモデル』の後半で、それが達成できているかをテスト・検証します。

 

Q 「SILが達成された」は、どういう状態を言うのですか

 

A SILが実現できていなかった際には、「どの過程が悪い」とか「どの部品が悪い」とか「どの人が悪い」ということを明確に突き止めることができる状態を言います。

原則的には、自動車を初めとする機械製品に使用される電気電子部品も、 JISB9700-1の枠組みでリスクアセスメントをしリスク低減をし、安全性の確保 を図ることになります。

ですが、そこから話を始めるのでは、電気屋さんやソフト屋さんには敷居が高 すぎます。

「要は、我々は何をしたらいいんだ?」ということで、自動車に使用される電 気電子部品およびソフトウェアの機能安全に特化して定めた規格が、ISO26262 です。

ISO26262の考え方はJIS B9700-1と同じで、「リスクを低減すること」です。

(リスク=[事故が実際に発生した時の重大度(被害の程度)]×[事故が発生する頻度])

こういう枠組みは、責任の所在を明確にするという目的があります。

ISO26262をきっちりと理解し準拠していれば、「SILが実現できた」と言える 枠組みになっています。もしも製品のSILが実現できていなかった際には、 「どの過程が悪い」とか「どの部品が悪い」とか「どの人が悪い」ということ を明確に突き止めることができる、という枠組みです。

たとえば、「製品のSILを元に、各部品にSILを割り振ることができる」ことが 適切に行えなければ、SILが実現できません。割り振った人が悪かった、とい うことになります。

「それじゃあ、結局は人の能力の良し悪しによって製品の安全性が左右される じゃん!」と思われるでしょうが、そうではありません。

認証という話があります。

認証は製品自体のみに行われるのではなく、「製品の安全性に関わる組織」に 対する認証も含まれます。組織内のマネジメントによって適切な能力のある人 材を育成し、適切な人材を配置する(組織マネジメントの)システムが構築さ れているかを監査し認証します。

ですから、「製品のSILを元に、各部品にSILを割り振ることができる」ことが 適切に行えなければ、「そういう人をその業務に携わらせたのが悪い。組織マ ネジメントのシステムの、不備」と結論付けられます。

認証の話に首を突っ込むと、「メーカーに認証を与える機関」に認証を与える 機関やら、『「メーカーに認証を与える機関」に認証を与える機関』に認証を 与える機関やらといった、何がなんやら分からない話が待っています。またし ても、長ーい説明に突入してしまいます。

 

Q なぜ「SIL」の分かりやすい本や解説がないんですか

 

A 製品の安全性に関わる業務をしている人は、忙しすぎるからです。

製品の安全性については、部分的に理解をしている人は多くいますが、それで は全容が語れないのです。全容を理解して語るには、基本原則から実務(具体 的に何をすればいいの?)までを、浅く広く知っていなければ難しい。予備知 識として知っておかなければいけないことが多すぎます。

そして、そういうことをやりたがる人は少ない。いや、仮にやりたがる人が多 かったとしても、多くの人が予備知識を身につけるには、時間がかかりすぎて (コストがかかりすぎて)現実的ではない。「ごく少数の、知っている人だけ が知っていれば良い」という状況になっています。

「分からないことがあれば、そのごく少数の人に尋ねればいいではないか」と。

なので、「具体的に何をすれば良いか?」を尋ねてくる人に回答やアドバイス を与えることだけで忙殺されます。ちょっと詳細に背景や目的まで解説しよう としても、すぐに「もういいや」と言われます。メーカー内でもそんな状況な のに、社会に向けて一般の人に説明しようとすればどうなるか。途中で「ああ、 もういいや。なんやら分からんけども、メーカーでしっかりとやってくれれば いいんだから」と聞くのを諦められるのが必至。

だから、「忙しい」のと「解説を理解してもらうことを諦めている」のが、解 説をしない理由です。

こぼれネットへ戻る

未分類

「なんでC言語のスレッドとする関数の引数は、構造体渡しにしなければならないのでしょうか?」と泣き言を言ってみました。

すでに他のサブシステムでがんじがらめになったCのプログラムでは、トレースが使えないので、デバッグはログに吐き出しながらの作業になります。

これが、結構な地獄で、つい先刻、改造したスレッドの稼動を確認できたのですが、愚痴がいいたくなりました(例えば、GO言語のGoroutineなんか、めちゃくちゃ簡単にスレッド作れる)。

ーーーーー ChatGPTの回答ここから ーーーーー

C言語のスレッド関数 (pthread_create() で実行する関数) の引数として 構造体を渡すのが一般的 なのは、以下の 4つの理由 によります。


1. pthread_create() の仕様

pthread_create() のスレッド関数(スレッドのエントリポイント)には、単一の void* 型の引数 を受け取る関数を渡す必要があります。

pthread_create() のプロトタイプ

int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
void *(*start_routine)(void *), void *arg);
  • start_routinevoid *arg という 単一の引数 を受け取る関数。
  • arg に渡せるのは ポインタのみ

つまり、スレッドに複数のデータを渡したい場合、
1つの void* にまとめる必要がある構造体で渡すのが一般的 ということになります。


2. 複数のデータを渡したい

スレッド関数で処理するのに 複数の引数(変数)を渡したい ことがよくあります。

例えば:

void *my_thread_func(void *arg) {
int *num = (int *)arg;
printf("Received number: %d\n", *num);
return NULL;
}

では、int の値しか渡せません。

もし 複数の値を渡したい場合

typedef struct {
int id;
double value;
} ThreadArgs;
void *my_thread_func(void *arg) {
ThreadArgs *args = (ThreadArgs *)arg;
printf("ID: %d, Value: %f\n", args->id, args->value);
return NULL;
}

このように、構造体を使えば複数の値をまとめて渡せる ので便利です。


3. スレッドの実行中に変数が消えないようにする

スレッド関数に渡す引数は、スレッドが終了するまで有効 でなければなりません。

例えば:

int num = 42;
pthread_create(&thread, NULL, my_thread_func, &num);

この場合、もし num がローカル変数で main() の実行が終了すると、
そのメモリが解放されてしまい、スレッド関数内で num を使うと 未定義動作 になります。

解決策

  • malloc() で確保して pthread_create() に渡す。
  • 構造体にして必要なデータを安全に渡す
ThreadArgs *args = malloc(sizeof(ThreadArgs));
args->id = 1;
args->value = 3.14;
pthread_create(&thread, NULL, my_thread_func, (void *)args);

こうすれば、スレッドが終了するまで args は有効になります。


4. スレッドごとに異なるデータを渡せる

スレッドを複数作成する場合、それぞれ異なるデータを渡すことが多い。

例えば、複数のスレッドに異なる ID を渡す場合:

ThreadArgs args[3];

for (int i = 0; i < 3; i++) {
args[i].id = i;
args[i].value = i * 1.1;
pthread_create(&threads[i], NULL, my_thread_func, &args[i]);
}

構造体なら、スレッドごとに異なるデータを安全に管理できる


結論

  • pthread_create()1つの void* しか渡せない複数の値を渡すには構造体が便利
  • スレッド実行中に変数が消えると 未定義動作ヒープ領域に確保すれば安全
  • 複数のスレッドに異なるデータを渡すのに構造体が適している

C言語のスレッドの引数は、構造体を渡すのが基本になる

ーーーーー ChatGPTの回答ここまで ーーーーー

まあ、そりゃそうなんだろうけどさ(そして、私としても、今さら仕様を変えられても困るんだけどさ)。でも構造体の引数に構造体が入ってくる場合、ポインタの記載方法で大混乱するんだよね。スレッド内部で構造体の分解も必要になるし。

-----

ところで、今なお、「プログラマーが好むプログラム言語」などという見出しの記事が散見されます。

開発するソフトウェアの内容によって、選ばれるプログラム言語は変ります。

ダムの掘削するのに「シャベル」を選ぶことはできませんし、家庭菜園をするのに「シャベルカー」を持ち込むことはできません。

プロのプログラマーなら、「シャベル」も「シャベルカー」も使えなければなりません。必要なら新しいプログラム言語を勉強して、仕事をしなければならないんです。

「プログラマーが好むプログラム言語」という考え方が、一体どこからやってくるのか、私は今でも分からないです。

「プログラマーが好むプログラム言語」などという、アホな内容の記事が散見されるのは何故でしょうか。見解を聞かせて下さい

ーーーーー ChatGPTの回答ここから ーーーーー

「プログラマーが好むプログラム言語」系の記事が散見される理由は、以下のような要因が考えられます。

  1. 簡単にウケるネタだから
    プログラム言語の人気ランキングや「初心者向け」「稼げる言語」といったテーマは、プログラマーだけでなく、これから学ぼうとする人や経営層にも関心を持たれやすい。専門知識がなくても理解しやすいため、記事として書きやすく、アクセスを稼ぎやすい。

  2. 宗教戦争を煽ると盛り上がる
    プログラマーには、それぞれ慣れ親しんだ言語やこだわりがあるため、「○○言語が最強!」といった記事を出せば議論が活発になり、SNSや掲示板で拡散される。結果として、PV(ページビュー)やエンゲージメントが向上し、メディア側の利益につながる。

  3. 技術を知らない人でも書けるから
    プログラミングの実務に詳しくないライターでも、「流行りの言語ランキング」「人気の言語トップ10」といった記事なら、調査や寄せ集めで簡単に書ける。しかも、明確な正解がないため、適当にデータを並べるだけでも成立する。

  4. 初心者や未経験者向けの情報が求められている
    現場のエンジニアにとっては無意味な話でも、これからプログラミングを学ぼうとする人には「どの言語を学べばいいか」という関心がある。需要がある以上、供給され続ける。

  5. 技術選定の本質を理解していない層が多い
    本来、プログラム言語は開発するソフトウェアの要件や環境、チームのスキルセットに応じて選ばれるべきもの。しかし、「言語そのものの優劣」や「人気」だけで語ろうとする風潮が根強く、それに迎合した記事が多くなる。

結局のところ、**「簡単に書けて、簡単にウケて、簡単に拡散される」**から、この手の記事が量産されるわけです。

ーーーーー ChatGPTの回答ここまで ーーーーー

ChatGPTも、なかなか語りますね。

 

未分類

―― 『売国奴』という言葉を使う奴は、低能ですらない、単なる馬鹿

"The guy who uses the word "sale country guy" is not only low-skilled but just stupid."

というのが、物心ついてからの、私の一貫した考え方です。

This has been my consistent way of thinking since I was a child.

(1)国が個人の譲渡の対象になると考える点で、馬鹿

(1)Stupid in that the country is subject to personal transfer

(2)国の全部または一部に、売るべき価値があると考えてる点で、馬鹿

(2)Stupid in that all or part of the country is something valuable to sell

(3)ともとも、「売国奴」という言葉を使わなければ相手を攻撃できない表現力の欠如が、馬鹿そのもの

(3)Stupid in that lack of expressiveness that can not attack the opponent without using the word "sale country guy."

と思っています。

I think them.

-----

私は、

■パリ条約(ここでは、工業所有権の保護に関するパリ条約:1883年に締結された、産業財産権(特許権、意匠権、商標権など)の保護に関する条約のこと)の、三大原則の理念に心を打たれ、

I was impressed by the philosophy of the three major principles of the Paris Convention (here, the Paris Convention on the Protection of Industrial Property Rights: the Convention on the Protection of Industrial Property Rights (Patent Rights, Design Rights, Trademark Rights, etc.) concluded in 1883).

■技術に対する私権の保護と、技術による国際協調、国際発展を唱える、Trips条約の前文に感動した、

The preamble to the Trips Convention moved me. It advocated protecting private rights to technology, international cooperation through technology, and international development.

『売国奴』という概念から、もっとも遠いところに立っていると自負する、一人のエンジニアです。

I am an engineer proud to be far from the notion of a "sale country guy."

未分類

■カードリーダーが使えなくなっていた

SCR3310-NTTCom は既に販売終了しており、公式のドライバ提供も終了しているため、新規の利用や再インストールは実質的に不可能
→ 同じWindowsで、その途中からハードウェアが使えなくなる、というケースを考えたことがなかったので、これに気がつくのに、随分時間を使ってしまった。

■カードリーダーの購入検討と購入

比較表

製品名 価格 (目安) 主要特徴 対応OS 推奨用途
SCR3310v2.0 約2,300~3,000円 NTTコミュニケーションズ製、業務用途でも使用実績あり Windows, macOS 業務用途や安定性重視
アイ・オー・データ USB-ICCRW2 約2,000円 ドライバ不要、マイナンバー対応 Windows, macOS 家庭用で手軽に使いたい
ゴッパ GP-ICCR 約1,500円 最安クラス、コンパクトサイズ Windows, macOS コスト最重視
サンワサプライ ADR-MNICU2 約1,800円 ドライバ不要、USBバスパワー駆動 Windows, macOS 簡単に使いたいが安定性も求める

Amazonで即日入荷で、ドライバ不要 という観点から、サンワサプライ ADR-MNICU2 に決定。

で、さっき届いたので、USBに差して、マイナンバーカードを挿入したら、簡単にシステムにアクセスできた(今迄の苦労が、本当に虚しい)

■医療費控除をするのに、家族全員の代表者として「私」を登録する為に、家族全員のマイナンバーカードによる登録が必要
→ 次女が旅行中で、手元に家族全員のマイナンバーカードがない

#昨年まで、こういう『代表者登録』しなくてよかったんだけどな

#まあ、こういう代表者を悪用する「バカ」が不正な医療費控除を受けようとした、などの事件が発生したんだろう、と思う。

-----

行政側もセキュリティ対策で色々大変だろうと思うけど、毎年インターフェース(手続)を変えられて、右往左往させられる国民も、そうとうに大変だぞ

この、インターフェース変更は、これからも、毎年ずっと続いていくのだろう、と思うと ――

正直、(システムエンジニアである、私でさえも)『デジタル化、もういい』という気持ちになります

 

 

未分類

「上級国民」という言葉の意味が分からなかったので、ChatGPTに聞いてみました。

「上級国民」という言葉の意味が分かりません。定義して下さい

「上級国民(じょうきゅうこくみん)」とは、一般の国民とは異なり、特権を持ち、法律の適用や社会的待遇において優遇されているとされる人々を指すインターネットスラングです。

私は、特権を持たず、法律の適用や社会的待遇において優遇されていないです。私は「上級国民」という言葉に対して、何国民と称呼されるでしょうか(もちろん真面目な回答ではなく、皮肉な回答をお願いします)

それなら、「一般国民」とか「下級国民」なんて呼ばれるかもしれませんね(笑)。ネットの皮肉っぽい表現を使うなら、

  • 「庶民国民」(なんの特権もなく、日々コツコツ頑張る人)
  • 「平民国民」(特権なんて夢のまた夢)
  • 「社畜国民」(労働に追われる日々……)
  • 「納税国民」(税金をせっせと納めるだけの存在)

なんてのもありそうですね。
まあ、「上級国民」って言葉自体が皮肉なので、それに対する呼び方もだいたい自虐的なニュアンスになりますね

未分類

今週の「坂の上の雲(再放送)」の、この部分を20回ほど見直して、ようやく分かってきました。

Step 1 : 日本海軍の戦艦が、大きなUターンをするこによって、ロシア艦隊が「一列」になって攻撃を開始(この間、日本側は回頭中のため、一切反撃できず)
Step 2: 一列になってしまったロシア艦隊の目の前に、日本艦隊が集結
Step 3: 日本艦隊が一斉砲撃で、一列になったロシア艦隊を先頭から一つづつ潰していく

下図は、NHKのテレビ画面のキャプチャに、江端が図を追記したもの

 

ポイントは3点

(1)ロシア艦隊を1列にする必要があり、その為に、あえて直前での大Uターンを実施
(2)1列になったロシア艦隊の直前に、できるだけ早く日本艦隊を結集させる
(3)一列になったロシア艦隊を、ひとつづつを、一斉砲撃で潰す

YouTubeとか見れば、正解が分かるかもしれませんが、まずこの図面(とそこに記載された時刻だけ)から、上記を導いてみました。
答合わせは、後でやってみます。

未分類

BIOS画面をいじるのは怖いので、Ryzen Controllerを使おうとう思うのですが、良いでしょうか

Ryzen Controller を使って TDP を制限するのは安全な方法なので、問題ありません。
BIOS設定を変更するよりリスクが低く、手軽にTDP制限を適用できるのでおすすめ です。


✅ Ryzen Controller の使用手順

1. Ryzen Controller をダウンロード

公式サイトから最新版を取得: 👉 Ryzen Controller公式サイト

  1. 「Download」ボタンをクリック
  2. インストールファイル (Ryzen Controller.exe) をダウンロード
  3. インストール後、管理者権限で実行

2. TDP制限の設定

(1) 「Power and Temperature」 タブを開く

  • 「PPT (Package Power Tracking)」を 35W に変更
  • 「TDC (Thermal Design Current)」を 25A に変更
  • 「EDC (Electrical Design Current)」を 50A に変更
  • 「Temperature Limit」を 85℃以下 に設定(温度制限)

(2) 「Apply」ボタンを押す

  • すぐに適用され、PCの発熱が抑えられる。

(3) 自動適用設定

Ryzen ControllerはデフォルトではPC再起動時に設定がリセットされるため、自動適用の設定を行う。

  1. 「Auto-start」機能を有効にする
    • 「Enable Auto-Start」オプションをON
    • Windows起動時に自動で設定を適用。

3. TDP制限が適用されたか確認

設定が適用されたかどうかをチェックする。

(1) HWiNFOで確認

  1. HWiNFO をダウンロード・起動
    👉 HWiNFO公式サイト
  2. 「CPU Package Power (PPT)」 の値が 35W前後になっているか 確認

(2) Ryzen Master で確認

  1. AMD Ryzen Master をダウンロード・起動
    👉 AMD公式ダウンロードページ
  2. PPTの最大値が 35W に制限されているか確認

4. パフォーマンス影響のチェック

TDPを35Wに制限すると発熱は抑えられるが、CPU性能も少し下がるため、以下の方法で影響をチェック。

(1) Cinebench R23 でテスト

  1. Cinebench R23 をダウンロード
    👉 Cinebench公式サイト
  2. シングルコア & マルチコアのスコアを測定。
  3. TDP制限前後でスコアを比較

(2) 通常の使用で問題ないか確認

  • 動画再生、Webブラウジング、プログラム開発など、普段の使用で問題がないか確認。

✅ Ryzen Controller を使うメリット

BIOSを変更しないので安全
簡単に設定できる
TDP制限を試して、問題があればすぐ元に戻せる
PCを移動せずに放熱対策ができる


⚠️ Ryzen Controller の注意点

PC再起動時に設定がリセットされるため、Auto-start を有効にすることを推奨
一部のWindowsアップデートで互換性が変わる可能性あり(設定が適用されなくなる場合がある)
100%完全な動作保証はないため、TDP制限後はPCの動作をチェック


✅ 結論

BIOSをいじるのが怖いなら、Ryzen Controller を使うのは良い選択。
TDPを35Wに制限することで、発熱を抑えながらPCを安定させられる
ソフトウェアなので、いつでも設定を戻せる

まずは Ryzen Controller で PPT = 35W に設定し、負荷テストをしながら安定動作するか確認するのがベスト!

Ryzen Controller Setup 2.5.4.exe をダウンロードしましたが、これで良いでしょうか

はい、Ryzen Controller Setup 2.5.4.exe は最新版の 2.5.4 で問題ありません。
以下の手順でインストールと設定を行ってください。


✅ Ryzen Controller 2.5.4 のインストール手順

1. インストール

  1. Ryzen Controller Setup 2.5.4.exe をダブルクリック
  2. 「Next」ボタンを押してインストールを進める
  3. インストールが完了したら 「Finish」ボタンを押す
  4. 管理者権限で起動(右クリック → 「管理者として実行」

2. TDPを35Wに制限する設定

  1. 「Power and Temperature」 タブを開く
  2. 以下の数値を設定:
    • PPT (Package Power Tracking)35W
    • TDC (Thermal Design Current)25A
    • EDC (Electrical Design Current)50A
    • Temperature Limit85℃以下
  3. 「Apply」ボタンをクリック
  4. 設定が反映されたか確認。

3. 再起動後も設定を維持する

再起動後に設定がリセットされるので、自動適用を有効化する。

  1. 「Auto-Start」機能を有効にする
    • 「Enable Auto-Start」を ON
    • Windows起動時に自動でTDP制限を適用

4. 設定が適用されたか確認

(1) HWiNFO で確認

  1. HWiNFO をダウンロード&起動
    👉 HWiNFO公式サイト
  2. 「CPU Package Power (PPT)」 の値が 35W以下 になっているか確認。

(2) Ryzen Master で確認

  1. AMD Ryzen Master をダウンロード&起動
    👉 AMD公式ダウンロードページ
  2. PPTの最大値が 35W に制限されているか確認

✅ 結論

  • Ryzen Controller 2.5.4 で問題なし!
  • TDPを35Wに制限する設定を行い、Auto-StartをONにする
  • HWiNFO や Ryzen Master で設定が適用されたか確認

この手順で設定すれば、放熱を改善しながらPCを安定動作させることが可能!

Temperature Limit (°C)
CPU TDP (W)
Long Boost Duration
Long Boost TDP (W)
Short Boost Duration
Short Boost TDP (W)

という画面がでています。次にどうすれば良いですか。目標は熱暴走の防止です

✅ Ryzen Controller 2.5.4 の設定手順 (熱暴走防止)

この画面でTDP(消費電力制限)と温度制限を適切に設定することで、熱暴走を防ぎつつパフォーマンスを維持することができます


1. 各パラメータの意味

Ryzen Controller では、以下のパラメータを調整できます。

設定項目 説明
Temperature Limit (°C) 最大CPU温度制限(これを超えると性能を下げる)
CPU TDP (W) 通常時の消費電力制限
Long Boost Duration ブースト持続時間(長時間)
Long Boost TDP (W) 長時間ブースト時の最大TDP
Short Boost Duration 短時間ブースト時間
Short Boost TDP (W) 短時間ブースト時の最大TDP

2. 熱暴走を防ぐための最適設定

以下の設定を入力してください。

  • Temperature Limit (°C)85(安全な範囲、85℃以上でクロックダウン)
  • CPU TDP (W)35(通常時の消費電力を35Wに制限)
  • Long Boost Duration10(ブースト時間を10秒に短縮)
  • Long Boost TDP (W)45(長時間ブースト時の最大消費電力を45Wに制限)
  • Short Boost Duration2(短時間ブーストを2秒に短縮)
  • Short Boost TDP (W)50(瞬間的な最大消費電力を50Wに制限)

3. 設定を適用

  1. 上記の値を入力
  2. 「Apply」ボタンをクリック
  3. 「Enable Auto-Start」を ON(再起動後も設定を維持)
  4. 動作確認のためPCを再起動

4. 設定が適用されたか確認

  1. HWiNFO を使って CPU Package Power が 35W以下に制限されているか確認
  2. Cinebench R23 で負荷テストを実行し、温度が 85℃以下に抑えられているかチェック

✅ 結論

この設定で、通常時の消費電力を35Wに抑えつつ、短時間のブーストを最大50Wまで許容することで、性能を落としすぎずに熱暴走を防ぐことが可能!

 

メニューを叩いてみると、現在値(?)は、上から、85,25,900,25,60,10となっています。

ChatGPT:

現在の設定値(85, 25, 900, 25, 60, 10)を見た限りでは、TDPが 25W に制限されており、かなり低い値になっています。この状態では、パフォーマンスが抑えられすぎている可能性があります。

また、Long Boost Duration (900秒 = 15分) と Short Boost Duration (60秒) が非常に長く設定されており、負荷が高い状態が長く続く可能性があるため、熱暴走を防ぐためにはこれらを短縮する必要があります。


✅ 熱暴走防止のための最適設定

1. 推奨設定

現在の値を 以下の値に変更 してください。

設定項目 変更前 推奨値 説明
Temperature Limit (°C) 85 85 CPUの温度制限(そのままでOK)
CPU TDP (W) 25 35 通常時の最大消費電力を35Wに制限
Long Boost Duration 900 10 長時間ブーストの持続時間を短縮(10秒)
Long Boost TDP (W) 25 45 長時間ブースト時の最大TDPを45Wに
Short Boost Duration 60 2 短時間ブーストを2秒に短縮
Short Boost TDP (W) 10 50 瞬間的な最大消費電力を50Wに

2. 設定手順

  1. 各値を上記の推奨値に変更
  2. 「Apply」ボタンをクリック
  3. 「Enable Auto-Start」を ON(再起動後も設定を維持)
  4. PCを再起動して設定が適用されているか確認

3. 設定適用後の確認

HWiNFO で CPU Package Power が 35W前後になっているかチェック
Cinebench R23 で負荷テストを行い、温度が 85℃以下で安定しているか確認
通常使用で問題がないかテスト(動画再生やWebブラウジングなど)


✅ 結論

現在の 25W制限は厳しすぎる ので、35Wに引き上げながら、ブースト時間を短縮 するのが最適!
この設定で、性能を維持しつつ、熱暴走を防ぐことができる 🎯

 

「Apply」ボタンをクリックしましたが、「Enable Auto-Start」が見つかりません。

Enable Auto-Start が見つからない場合、手動で設定を再適用する方法を使う必要があります。
Ryzen Controllerは再起動後に設定がリセットされるため、毎回適用する必要があります
以下の手順で、起動時に自動で設定が適用されるようにする方法を紹介します。


✅ 自動適用の方法(手動スクリプト設定)

Ryzen Controller自体にはAuto-Start機能がないバージョンもあるため、Windowsのタスクスケジューラを使って、PC起動時に自動適用する方法を設定します。


1. Ryzen Controller をバッチファイルで起動

  1. メモ帳 を開く

  2. 以下のスクリプトをコピーして貼り付ける

    bat
    @echo off
    start "" "C:\Program Files\Ryzen Controller\Ryzen Controller.exe"
    timeout /t 5
    nircmd sendkeypress enter
    • C:\Program Files\Ryzen Controller\Ryzen Controller.exe のパスは、実際にRyzen Controllerがインストールされている場所に合わせる。
    • nircmd はキーボードのEnterキーを自動で押すコマンド(詳細後述)。
  3. RyzenControllerAutoStart.bat としてデスクトップに保存


2. タスクスケジューラで自動実行

  1. Win + R を押して taskschd.msc を入力し、Enter
  2. 「タスクスケジューラ ライブラリ」 を開く
  3. 「基本タスクの作成」 をクリック
  4. タスクの名前を「Ryzen Controller AutoStart」 に設定し、「次へ」
  5. 「ログオン時」に設定し、「次へ」
  6. 「プログラムの開始」を選択し、「次へ」
  7. 「参照」ボタンをクリックし、RyzenControllerAutoStart.bat を選択
  8. 「完了」を押す

3. nircmd で自動適用(オプション)

Ryzen Controllerの設定適用ボタンを自動で押すために、nircmd という小さなツールを使うことができる。

  1. nircmd をダウンロード
    👉 公式サイト
  2. nircmd.exeC:\Windows\System32 にコピー
  3. 先ほどの .bat スクリプトの最後に以下を追加
    bat
    nircmd sendkeypress enter

    これにより、Ryzen Controller 起動後に自動で「Apply」を押す。


✅ 確認手順

  1. PCを再起動
  2. Ryzen Controller が自動で起動し、設定が適用されているか確認
  3. HWiNFORyzen Master で、TDP制限が有効かチェック

✅ 結論

  • Ryzen Controller 2.5.4 には Enable Auto-Start がないため、手動で自動適用を設定する必要がある
  • タスクスケジューラで bat ファイルを登録すれば、PC起動時に設定が自動適用される
  • nircmd を使えば、「Apply」を自動で押せるようになる

この方法で、再起動後もTDP制限が適用され、熱暴走を防ぐことができる!

面倒ですが、毎回手動で設定してもいいです。「Apply」を設定した段階で設定されたと考えて良いですか

はい、「Apply」ボタンをクリックした時点で設定は即時適用されています
したがって、手動で毎回「Apply」を押す方式でも問題ありません


✅ 手動適用の流れ

  1. PCを起動
  2. Ryzen Controller を管理者権限で実行
    • (右クリック →「管理者として実行」)
  3. 設定値(TDP=35W など)が変更されていないか確認
  4. 「Apply」ボタンをクリック
  5. 設定が反映されたか確認 (HWiNFO などでチェック)

✅ 設定が反映されたかの確認

以下のいずれかの方法でTDPが適用されているか確認してください。

方法①: HWiNFO で確認

  1. HWiNFO をダウンロード
    👉 公式サイト
  2. Sensors Only モードで起動
  3. 「CPU Package Power (PPT)」の値を確認
    • 35W前後になっていれば設定適用OK ✅

方法②: Ryzen Master で確認

  1. AMD Ryzen Master をダウンロード
    👉 AMD公式ダウンロードページ
  2. 「PPT (Package Power Tracking)」の最大値を確認
    • 35Wに制限されていれば適用OK ✅

✅ 結論

「Apply」を押した時点で設定は即時反映されるので、手動適用でも問題なし!
毎回「Apply」を押すだけでOK
再起動後に忘れないようにするだけ
HWiNFORyzen Master で設定が適用されているか確認すれば確実

面倒でも手動で問題なければ、この方法で TDP制限を適用し、熱暴走を防ぐことが可能! 🎯

ちなみに、現在の画面には「APPLY] [CREATE PRESET]「RESET」のボタンがあります、現在「APPLY]を押しました。このままアプリケーションを終了すれば良いですか?

ChatGPT:

はい、「APPLY」ボタンを押した時点で設定は適用されている ので、そのままアプリケーションを終了しても問題ありません。

✅ 手順

  1. 「APPLY」ボタンを押した時点でTDP制限が反映
  2. アプリケーションを閉じてOK
  3. 設定が適用されているか確認
    • HWiNFORyzen Master で「CPU Package Power (PPT)」が 35W前後になっているかチェック。

✅ 「CREATE PRESET」は必要か?

  • 「CREATE PRESET」ボタンは、設定を保存する機能 ですが、再起動後に自動適用されるわけではないため、手動適用の場合は不要。
  • 毎回「APPLY」を押すなら 「CREATE PRESET」は押さなくてOK

✅ 「RESET」は何をする?

  • 「RESET」ボタンは、すべての設定をデフォルトに戻す ため、押さないように注意。

✅ 結論

「APPLY」ボタンを押した時点で設定は適用済み
アプリを閉じてもOK
再起動後は、再度Ryzen Controllerを開いて「APPLY」を押す必要がある

これで、熱暴走を防ぎつつ、安定した運用が可能になります! 🎯

未分類

MINISFORUM EliteMini HM90 (AMD Ryzen 9 4900H) のスペックや過去の報告を考慮すると、特定のハードウェアや構成に起因するクラッシュの可能性がいくつか考えられます。


考えられるクラッシュの原因

1. 熱暴走 (特にCPU・VRM)

問題点

  • Ryzen 9 4900HはノートPC向けのハイパフォーマンスCPUであり、TDP(最大54W)はミニPCの放熱設計ではギリギリの範囲。
  • MINISFORUM HM90は冷却設計がタイトで、長時間の高負荷時にサーマルスロットリングシャットダウンを引き起こすことがある。
  • 一部ユーザーから「高負荷時にブラックアウトする」との報告がある。

確認方法

  • HWMonitorRyzen Master でCPU温度を確認。
  • Stress-ngCinebench を実行し、高負荷時の温度変化をチェック。
  • 冷却ファンが正常に動作しているか確認 (HWiNFO などでファン回転数を見る)。

対策

  • BIOSで「プロセッサのPPT制限」を設定し、TDPを制限 (例: 35Wに設定)。
  • ヒートシンクやファンのメンテナンス (ホコリ除去)
  • 冷却パッドを追加するか、外部クーラーを使用

2. GPU (Vega 8) ドライバの不具合

問題点

  • Ryzen 9 4900H の Vega 8 GPU は、Windows 11環境や特定のドライバでブラックスクリーン問題を起こすことがある
  • 一部のAMD Adrenalinドライバ(特に最新版)は、スリープ復帰時や高負荷時にクラッシュを誘発。

確認方法

  • イベントビューアー (eventvwr.msc)システムログamdkmdag エラーがないか確認。
  • Windows + Ctrl + Shift + B を押してGPUリセットで復帰するか確認
  • dxdiag で DirectX のエラーが発生していないかチェック。

対策

  • AMD公式サイトから旧バージョンのドライバ (WHQL版) にロールバック
  • デバイスマネージャー → ディスプレイアダプター「標準VGAアダプター」に一時変更し、ブラックスクリーンが発生しないかテスト。
  • Fast Startup (高速スタートアップ) を無効化(Windows 10/11の場合)。

3. メモリの相性・不良

問題点

  • MINISFORUMの 初期搭載メモリ (SODIMM DDR4-3200) に相性問題があることが報告されている。
  • 一部のユニットでは、デュアルチャンネル動作時に不安定な動作をする個体がある

確認方法

  • Memtest86 を実行し、エラーが出ないか確認。
  • Windows の メモリ診断 (mdsched.exe) を試す。
  • 1枚のメモリだけを装着して動作をテスト(デュアルチャンネル動作を無効化)。

対策

  • メモリの XMP設定をBIOSで無効化 する(デフォルトのJEDECプロファイルを使用)。
  • 別のメモリ (Crucial, Kingston などの相性が良いブランド) に交換

4. 電源ユニット (ACアダプタ) の容量不足

問題点

  • MINISFORUM HM90 は 19V/4.74A (90W) のACアダプタを使用しているが、フル負荷時にはギリギリ。
  • 高負荷時に 電力不足でブラックアウト する報告がある。

確認方法

  • バッテリー駆動のノートPCではないので、ACアダプタの電力供給が正しく行われているかチェック
  • 高負荷時 (CinebenchFurMark 実行時) に突然電源が落ちる場合、電力不足の可能性あり。

対策

  • 120W以上のACアダプタ (同じ電圧・プラグ) に交換
  • BIOSでTDPを35W程度に制限し、電力消費を抑える

5. SSD (ストレージ) の不良

問題点

  • 初期搭載の 512GB NVMe SSD (ブランド不明のOEM品) は、一部の個体でブラックアウトを引き起こすことがある。

確認方法

  • CrystalDiskInfo でSSDのS.M.A.R.T.情報をチェック(異常温度やエラーログがないか)。
  • chkdsk /f /r を実行し、ファイルシステムのエラーを確認。

対策

  • 別のM.2 NVMe SSD (Samsung 970 EVO Plus, WD Black) に交換し、Windowsをクリーンインストール。

結論

MINISFORUM EliteMini HM90 は、発熱・電源供給・GPUドライバの問題がブラックアウトの主な原因となりやすい

最優先で試すべき対策

  1. Windows + Ctrl + Shift + B で画面復帰を試す
  2. イベントビューアーamdkmdag エラーがあるか確認
  3. AMD GPUドライバをロールバック (WHQL版を使用)
  4. BIOSでTDPを35Wに制限
  5. メモリを1枚にして動作確認
  6. 120WのACアダプタを試す
  7. SSDのS.M.A.R.T.情報をチェック

ブラックアウトが頻発するなら、特に「電源」「GPU」「熱」の問題を疑うべき
最終手段として、BIOSアップデートとOSのクリーンインストールを検討。

未分類

単純な比較はできないと思いますが、ノード内にあるDockerの中のPostgresqlデータベースにアクセスするのと、ノード外にあるPostgreSQLデータベースにアクセスするのはどちらが速いと思いますか

単純な比較は難しいですが、一般的なケースでは以下のような要因を考慮すると、ノード内のDockerコンテナ内にあるPostgreSQLのほうが速い可能性が高いです。

ノード内のDockerコンテナのPostgreSQL

メリット

  • 低遅延:ネットワークのオーバーヘッドが小さい(通常、localhostunix domain socket経由での接続)。
  • 帯域制限なし:ローカルのリソースを直接使うため、物理ネットワークの帯域制限を受けにくい。
  • 通信の最適化:Dockerネットワークのブリッジモードやホストモードを適切に設定すれば、通信のオーバーヘッドを抑えられる。

デメリット

  • コンテナリソースの影響:他のコンテナとリソースを競合する可能性がある(CPU、メモリ、I/O)。
  • スケーラビリティの問題:複数のノードからのアクセスが必要な場合、スケールアウトしにくい。

ノード外のPostgreSQL

メリット

  • スケールしやすい:専用のデータベースサーバーとして運用でき、負荷分散の選択肢が広がる。
  • リソース分離:アプリケーションとデータベースが分かれるため、DBのリソース管理がしやすい。

デメリット

  • ネットワーク遅延:ノード間通信のオーバーヘッドがある(特にインターネット越しのアクセスやVPN経由の場合)。
  • ネットワーク帯域の制約:LANでも帯域制限がある場合、トラフィックの影響を受ける可能性がある。
  • セキュリティ対策が必要:認証やSSL/TLSを設定することでオーバーヘッドが増える場合がある。

結論

一般的には、ノード内のDockerコンテナのPostgreSQLの方が低遅延で速い可能性が高いですが、以下のケースではノード外の方が適していることもあります。

  • 複数のノードからアクセスする場合(スケールアウトを考えるならノード外)
  • データベースの負荷が高い場合(専用DBサーバーの方がパフォーマンスを確保しやすい)
  • ノードのメモリやCPUリソースを節約したい場合(DBを外部に分離することでアプリケーション側のリソースを確保できる)

もしローカルのDockerコンテナ内PostgreSQLを使うなら、unix domain socketを利用することでTCP接続よりもさらに低遅延でアクセスできるので、それも検討するとよいでしょう。

PostGISのルート計算の回数が、計算時間に大きく影響しているみたいで、昨日、1日分のシミュレション(1万8000人分)に、1時間44分かかった時には青冷めました。ちょっとDBアクセスに工夫したのですが、それでも25分間かかります。ぶっちゃけ10分以内にしないと、ちょっと厳しいのです。

今、ローカルのDBにアクセスしたらハブの点滅が減っています。

Elapsed Time: 16m20.5619673s
ちょっと安心してきました。でも10分には、まだまだ遠いです。

未分類

オンラインカジノを行った芸能人が問題になっているようですが、何が論点なのかが分かりません。教えて下さい

この問題の論点は、主に以下の3点にまとめられます。

1. 法律・規制の問題

日本では基本的に賭博行為は厳しく規制されており、オンラインカジノは多くの場合、国外に拠点を置くために法的グレーゾーンにあります。芸能人のような公の人物がこのような活動に関与することは、法律上の問題やその解釈を巡る議論を呼び起こす可能性があります。

2. 社会的・倫理的影響

芸能人は多くの人々に影響を与える存在です。そのため、彼らがオンラインカジノに関与することで、特に若年層やファンに対して「ギャンブルが魅力的である」といった誤解を与え、ギャンブル依存症などのリスクを助長する懸念があります。

3. 消費者保護と業界の信頼性

オンラインカジノは、不正や詐欺、トラブルのリスクが指摘されることが多い業界です。公人がこのようなリスクのある活動に関わることで、利用者や社会全体への影響、さらには業界全体の信頼性が問われることになります。

これらの点が、芸能人がオンラインカジノに関与することに対して批判や問題意識が向けられる主な理由です。

この問題の論点は、主に以下の3点にまとめられます。

1. 法律・規制の問題

日本では基本的に賭博行為は厳しく規制されており、オンラインカジノは多くの場合、国外に拠点を置くために法的グレーゾーンにあります。芸能人のような公の人物がこのような活動に関与することは、法律上の問題やその解釈を巡る議論を呼び起こす可能性があります。

2. 社会的・倫理的影響

芸能人は多くの人々に影響を与える存在です。そのため、彼らがオンラインカジノに関与することで、特に若年層やファンに対して「ギャンブルが魅力的である」といった誤解を与え、ギャンブル依存症などのリスクを助長する懸念があります。

3. 消費者保護と業界の信頼性

オンラインカジノは、不正や詐欺、トラブルのリスクが指摘されることが多い業界です。公人がこのようなリスクのある活動に関わることで、利用者や社会全体への影響、さらには業界全体の信頼性が問われることになります。

これらの点が、芸能人がオンラインカジノに関与することに対して批判や問題意識が向けられる主な理由です。

「日本では、オンラインカジノそのものが明確に合法とも違法とも言い切れない状況ある」という事について詳解して下さい

オンラインカジノが日本で明確に合法とも違法とも断定されにくい背景には、以下のような複数の要因が絡んでいます。

1. 日本における賭博規制の基本原則

  • 刑法による禁止: 日本の刑法では、基本的に賭博行為は禁止されています。ただし、政府が運営する公営ギャンブル(競馬、競輪、競艇、宝くじなど)は例外として認められています。
  • 例外規定の存在: これらの公営ギャンブルは、法律上特別な枠組みが設けられており、運営方法や収益の使途が明確に規定されています。

2. オンラインカジノの運営形態と国際的側面

  • 海外拠点の問題: 多くのオンラインカジノは海外に拠点を置いており、日本国内で直接サービスを提供しているわけではありません。これにより、日本の法律がその運営に直接適用されるかどうかが不明瞭となっています。
  • 国際的取引と管轄権: インターネットを介して行われる取引は国境を越えるため、どの国の法律が適用されるのか、また日本の法執行機関がどこまで介入できるのかという点で、管轄権の問題が生じています。

3. 法律の解釈と実務上の対応の不明瞭さ

  • 明確な法整備の不足: オンラインカジノに関しては、現行法が具体的な運営形態や利用者の行為について明確に定めていないため、法律上の位置づけがグレーゾーンになっています。
  • 取り締まりの難しさ: 仮にオンラインカジノの利用が違法と判断された場合でも、運営が海外にあることから、実際にどのように摘発や取り締まりを行うかについては実務上の困難が伴います。

4. 今後の法整備と展望

  • 需要の変化: インターネットを利用したギャンブルの利用者が増加している中で、国内外で法整備の必要性が議論されていますが、現時点では具体的な法規制が整っていないため、状況は依然として曖昧です。
  • 国際協力の課題: 今後、各国間での協力や共通のルール作りが進めば、オンラインカジノの位置づけについても明確な基準が設けられる可能性がありますが、その動向はまだ不透明です。

このように、オンラインカジノの合法性が明確に定義されない背景には、国内法の規定の限界、運営の国際的性質、そして実務上の取り締まりの難しさが複雑に絡み合っているためです。

属地主義の問題が争点と理解しました。不正競争防止法においては、この問題について、法律で明文化していたという記憶があります。それについて教えて下さい。

不正競争防止法では、国内市場の公正な競争環境を守るために「属地主義」の原則が明確に示されています。具体的には、以下の点が挙げられます。

1. 適用範囲の限定

不正競争防止法は、原則として日本国内における取引や事業活動に関連する不正行為を対象としています。つまり、国外で行われた行為であっても、その結果や影響が日本国内の市場や企業に及ぶ場合に限り、法律の適用対象となります。これにより、国外で完結した行為に対してまで国内法を無理に及ぼすことを避ける意図が反映されています。

2. 国際的取引と裁判管轄のバランス

オンラインを含む国際的な取引や事業活動では、どの国の法律が適用されるかが重要な争点となります。不正競争防止法は、この点においても属地主義を採用しており、たとえば海外で行われた行為が日本国内の企業に具体的な損害や不利益を与える場合に限り、その行為が不正競争として取り締まられると解釈されます。これにより、国内外の法的枠組みの調和が図られています。

3. オンライン活動における適用の検討

デジタル技術の発展に伴い、オンライン上での活動が国境を越えて行われる現状では、どの行為が「国内における」不正競争に該当するかという判断が重要となります。不正競争防止法は、国外での活動が日本国内に及ぼす具体的な影響を踏まえて適用の可否を判断する仕組みを持っており、これが属地主義の明文化として理解されています。たとえば、海外に拠点を持つ業者が日本の市場で販売活動を行い、結果として国内企業に損害を与えた場合には、国内法の枠内で救済措置が検討されることになります。

4. 法律上の明確性と運用上の課題

属地主義の明文化は、国内企業の保護と国際取引の自由とのバランスをとるために不可欠ですが、一方で、オンライン上の活動など新たなビジネスモデルに対しては、裁判所や行政機関が具体的なケースごとに「国内との関連性」をどのように判断するかが運用上の大きな課題となっています。

このように、不正競争防止法は属地主義の原則を明確に規定することで、国外で行われた行為が日本国内に具体的な影響を与える場合にのみ国内法の適用対象とする枠組みを構築しています。これにより、国際的な事業活動に対して過剰な干渉を避けるとともに、国内企業の正当な利益を守ることを目的としています。

では、オンラインカジノにおける属地主義の適用の観点から考えると、現在はオンラインカジノの行為そのものについては刑事判断はできないものの、オンラインカジノによる収益に対する税金(民法)が問題となるのでしょうか?

オンラインカジノの活動自体は、海外で運営されていることが多く、属地主義の観点から日本国内での刑事判断が難しいという問題があります。一方で、日本の税制は居住者が得た所得については国内で課税する原則を採っているため、たとえその収益が海外のオンラインカジノから得られたものであっても、日本の居住者が得た利益は原則として申告義務の対象となります。

1. 居住者の所得課税の原則

  • 国内外の所得の申告: 日本の居住者は、全世界所得に対して日本で課税されるため、オンラインカジノでの収益も所得として計上する必要があります。これは、たとえそのオンラインカジノ自体が海外に拠点を置いていて、刑事的な摘発の対象とならなくても変わりません。

2. オンラインカジノと属地主義

  • 刑事判断との乖離: オンラインカジノの運営行為については、実際に国内で行われた取引やサービス提供とは認定しにくいため、刑事判断の適用が難しい現状があります。
  • 税務上のアプローチ: 一方で、個々の利用者がオンラインカジノで得た収益は、その収益が日本の居住者個人に帰属するため、属地主義に基づく「所得の帰属」の考え方から、国内の税務上は課税対象となるのです。

3. 課題と運用上の問題

  • 源泉の特定: 国境を越えた取引となるため、どの部分が国内源泉に該当するか、またはどの程度の関係性があるかの判断が難しい場合があり、これが税務当局にとっての課題となっています。
  • 脱税リスク: オンラインカジノの取引は匿名性が高く、また海外での運営という性格上、適正な申告がなされず脱税につながるリスクも指摘されています。
  • 法整備の必要性: 現在、オンラインカジノに関連する税務や取引の国際協力の枠組みは十分に整備されていないため、今後の法整備や国際協力の強化が求められる状況です。

4. 結論

刑事判断の対象とならないオンラインカジノの活動であっても、日本の居住者が得る収益は日本国内での課税対象となるため、属地主義の観点からは収益に対する税務問題が大きな論点となっています。つまり、刑事面での摘発が難しい分、税務上の適正な申告や徴税の面で政府が注意を払わなければならないということです。

このため、オンラインカジノ自体の法的グレーゾーンが続く中で、個人や関連事業者に対して適正な税務処理が求められるとともに、税務当局側も国際的な連携や新たな法制度の整備に向けた取り組みが今後の課題となると考えられます。

その芸能人が、オンラインカジノで損金を出した、というのであれば、(社会的・倫理的問題や消費者保護と業界の信頼性を100%無視するとすれば)法的には問題がない、と解釈できますか? それとも、国内法で規定されていないギャンブルを実施したこと自体が、利益に関係なく問題になりますか。法律の観点のみから論じて下さい

法律の観点から考えると、基本的には以下の点が重要になります。

1. 賭博行為の刑事罰の対象

日本の刑法では、賭博行為自体は原則として禁止されていますが、実際の刑事罰の適用は主に運営者や、組織的・常習的な違法賭博行為に対して行われる傾向があります。個人の参加者が単にギャンブルに従事し、結果として損失を被った場合、その行為自体で直ちに刑事罰の対象とされるケースは少ないと解釈されるのが現状です。

2. オンラインカジノのグレーゾーンと個人参加

オンラインカジノは海外に拠点を置くことが多く、日本国内での直接的な運営行為ではないため、属地主義の観点から刑事判断を下すのが難しい部分があります。したがって、たとえオンラインカジノに参加して損失を出したとしても、現行の法体系では「違法な利益を得た」ことが問題視されるケースが中心であり、単に損失を出した場合は刑事処分の対象になりにくいと考えられます。

3. 国内法で規定されていないギャンブルの実施について

確かに、オンラインカジノは国内法上、明確に合法とも違法とも位置づけられていない部分があるため、法的なグレーゾーンにあります。しかし、現時点での法執行の重点は、違法な利益の追求や組織的な運営にあるため、単に損失を出しただけの個人の行為が直ちに問題視されることは少ないというのが一般的な解釈です。

結論

社会的・倫理的問題や消費者保護、業界の信頼性といった要素を完全に排除して法律のみを考えるならば、オンラインカジノに参加して損失を出した場合、その行為自体が刑事罰の対象となる可能性は低いと解釈できます。つまり、違法に「利益」を得たわけではなく、単に損失を被ったに過ぎないため、現行の法制度下では刑事判断が下される余地は限定的だと考えられます。ただし、オンラインカジノ自体が法的グレーゾーンであるため、今後の法整備や運用上の判断次第では見解が変わる可能性も否定できません。