未分類

"分析"と"解析"は何が違いますか?

「分析」と「解析」は似ていますが、ニュアンスと使い方に明確な違いがあります。以下にその違いを整理します。


■ 意味と使い分けの違い

 

項目 分析(Analysis) 解析(Analytical computation / Analysis)
意味 物事を構成要素に分解して意味や原因を明らかにすること 現象やデータを数理的・論理的手法で解き明かすこと
主な対象 状況、文章、社会現象、行動など 数式、物理現象、シミュレーション結果、時系列データなど
方法 比較、分類、意味付け、構造把握 数値計算、ロジックモデル、アルゴリズムなど
使用例 行動パターンの分析、世論の分析、原因分析 時系列データの解析、クラスタ解析、接触頻度の解析
ニュアンス 一般的/やや抽象的 技術的/定量的/科学的な印象

■ あなたの研究に即した例

  • 「分析」 → 「住民の接触行動の傾向を分析する」
    (なぜこのような行動をしたのか、どう分類できるか)

  • 「解析」 → 「共時空間やRCMをシミュレーションから解析する」
    (DBSCANや空間キューブ分割を使って数理的に抽出する)


■ 使い分けの指針(実務・論文向け)

  • “結果を見る” → 分析

  • “数値から導く” → 解析


■ 結論(あなたの論文において)

  • 第3章~4章:解析
    (設計・構築し、数値やロジックで実行)

  • 第5章:分析
    (その結果を社会的・空間的観点から解釈)

未分類

「江端さんって、つまるところ『小市民』ですよね」

「昔っから、私は、ずっとそう言っとろーが!」

という会話を思い出しました。なので、なんとなく書き残しました。

―― 国家権力に目をつけられない様な『小市民』であり続けること

私のサイトで「小市民」が出てくるページ一覧

2025,江端さんの忘備録

私が学生のころ、PC-9801シリーズやエプソンの互換PCを使っていた時代、16ビット実数を使った2次元配列計算の限界は「89」でした。

When I was a student, during the era of the PC-9801 series and Epson-compatible PCs, the limit for 2D array calculations using 16-bit floating-point numbers was "89".

つまり、89×89の"2次元"配列が扱える最大サイズだった、ということです。

In other words, the maximum size of a two-dimensional array that could be handled was 89×89.

なぜこの「89」という数字を今でも覚えているのかといえば、「90」にするとTurbo Pascalがメモリエラーを起こし、計算不能になったからです。

The reason I still remember the number "89" is that setting it to "90" caused a memory error in Turbo Pascal, rendering the calculation impossible.

---

それが今では、「430,328」ポイントの"3次元"座標データをDBSCANでクラスタリングする処理を、64GBメモリを積んだゲーミングPCで、Go言語を使って行っています。

Now, I’m performing DBSCAN clustering on a three-dimensional dataset with 430,328 points using Go, on a gaming PC equipped with 64 GB of memory.

30くらいのプロジェクトをゲーミングマシンに移して、そこで、手動を変えながら、計算を実行しています。

I’ve migrated around 30 projects to the gaming machine and am running computations there while manually adjusting parameters.

一つのプロジェクトの計算に、約1,400秒かかっていますが、ちゃんと終わります。

Each project takes about 1,400 seconds to process, but it completes successfully.

---

以前、「PCの性能は20年後のスーパーコンピュータに追いつく」という検証をしたことがありますが、理屈の上では、私は今、2005年のスパコンと同じことを自宅で実行していることになります。

I once examined the claim that “PCs will catch up to supercomputers from 20 years ago,” and in theory, I am now doing at home what a 2005 supercomputer could do.

ただ、いつも思うのです。これだけ計算性能が向上しているのに、なぜ私たちの人生は、楽にならないのでしょうか?

But I can’t help wondering: despite such a dramatic increase in computing power, why hasn’t our daily life become any easier?

もし、生成AIで20年前の仕事が5分間で片付くのなら、勤務時間も5分間で終わるべきです。

If generative AI can finish the work of 20 years ago in five minutes, then our working hours should also end in five minutes.

なのに、そうはならない。

And yet, that’s not what happens.

---

もしかすると、人類には「幸福を回避するDNA」が埋め込まれているのかもしれません。

Perhaps humanity is encoded with DNA that avoids happiness.

そう考えると、私たち人間には「幸せになるために努力すること」そのものが"無効"となるプログラミングされている、と考えるのが自然です。

If that's the case, then maybe we humans are programmed so that any effort to attain happiness is rendered ineffective from the start.

---

最近ふと気づいたのですが、私たちは、性能が上がったPCには「休ませよう」なんて思いません。

I recently realized something: we never think of “giving a break” to a PC that has improved in performance.

ならば、性能が上がった私(たち)に、誰も休みを与えようとしないのは当然かもしれません。

So it may be only natural that no one offers us rest when our performance improves.

進化が、「休めなくなること」なのだとすれば、私たちの人生のゴールって、一体何なのでしょう?

If evolution means “becoming unable to rest,” then what exactly is the goal of our lives?

なるほど、『私たちは、みんな、20年前のスパコンを使っている』ことになる訳です。

 

2025,江端さんの忘備録

ちょっと前までは、知っていた芸能人や政治家が、どんどん亡くなっていくなぁ、と感じていました。

Not long ago, I felt that celebrities and politicians I knew were passing away one after another.

最近では、顔見知りで、昔お世話になっていた、20歳ほど年上の方々が、次々と死去されていきます。

Recently, people I knew personally, about 20 years my senior, have also started passing away in succession.

「加速度的」、あるいは「指数関数的」とでも言うのでしょうか。

It feels almost accelerated, or perhaps even exponential.

あまりにも数が多くなって、最近では、すっかり慣れてきた気がします。

There have been so many that I've grown accustomed to them lately.

これから、さらにこの数は増えていき、なんだか分からないうちに、その中の一人になるんだろうなぁ、と、ぼんやり考えるようになってきています。

I have begun to vaguely think that the number will only increase and that I'll eventually become one of them without even realizing it.

-----

4月にラッシュで開催される、期首朝礼やら、キックオフやらに参加していると、

Whenever attending the rush of kick-off meetings and opening ceremonies in April,

―― 何を、そんなに一生懸命になっているんだ?

―― Why is everyone getting so worked up?

と思ってしまうことが、たびたびあります。

I often find myself thinking that.

いや、"一生懸命"を茶化すつもりはないですし、それをニヒルに笑えるほど、悟っているわけでも、ひねくれているわけでもないのです。

I'm not trying to mock earnestness, nor am I enlightened or cynical enough to laugh at it nihilistically.

『一生懸命』とは、『一生懸命やったことそのものが、ご褒美』である ―― というか、それだけの価値しかないけれど、それでも立派な『ご褒美』だと、私は思っています。

I believe that "working hard" itself is the reward — it may only be worth that much, but it's still a splendid reward.

これは、「人生、狂った奴が勝ち」という、私の価値観とも一致しています。

This aligns with my belief that "in life, the crazy ones win."

『人生をどう生きたところで、大して変わりはない。ただ、狂えるものがあれば、ちょっとだけ"おトク"かもしれない』

ただ、私がいつもひっかかるのは、期首朝礼やらキックオフで、必ず登場する「スピード感を持って取り組む」というフレーズです。

However, what always catches me is the phrase "work with a sense of speed," which inevitably appears at these kick-off meetings.

-----

スピード感は、競争原理の資本主義社会においては、必須要素の一つなのですが――

Speed is indeed an essential factor in the competitive principles of capitalist society —

『半分の時間でやる』とか『スケールを2倍にする』といった努力は、時間を遡って顧みると、かなり虚しく感じるものです。

But looking back over time, efforts like "doing it in half the time" or "doubling the scale" often feel somewhat hollow.

特に技術の世界においては、「半分の時間」とか「スケール倍増」なんて、ちょっとした小規模なイノベーションで、サクっと解決してしまうことが、ままあります。

Especially in the world of technology, small innovations can easily achieve goals like halving time or doubling scale.

私は、そういうモノを、軽く10個くらい挙げることができます。やってみましょうか?

I can casually list about ten such examples. Shall I?

(1) インターネットの普及

(1) Spread of the Internet

郵便で1週間かかっていた情報伝達が、メール一通で一瞬。努力やスピード感以前の問題。

Information that used to take a week by mail can now be sent instantly by email — speed is no longer even an issue.

(2) Google検索の登場

(2) Emergence of Google Search

図書館で何時間もかけて調べていた資料探しが、検索窓に数単語入力するだけ。もはや努力する前に答えが出る。

Research that took hours at the library now takes just a few words typed into a search bar — answers come before effort even begins.

(3) コンテナ仮想化(Docker)

(3) Container Virtualization (Docker)

開発環境構築に3日かかっていたのが、docker pullで5分。スピード感?笑わせるな、という世界。

What once took three days to set up a development environment now takes five minutes with docker pull. "Sense of speed"? Don't make me laugh.

(4) クラウドコンピューティング(AWS, Azure)

(4) Cloud Computing (AWS, Azure)

物理サーバー発注して納品待ちしていたあの頃は何だったのか。今や数クリックで巨大サーバー群を即時起動。

Ordering and waiting for physical servers is a thing of the past — today, a few clicks instantly launch massive server clusters.

(5) オープンソースソフトウェア

(5) Open Source Software

昔は1から全部作っていた機能も、今はGitHubでcloneして数分で実装完了。時間短縮どころの話ではない。

What once required building everything from scratch can now be cloned from GitHub and implemented in minutes — it's beyond time-saving.

(6) 3Dプリンター

(6) 3D Printers

試作品を外注して1か月待っていたのが、社内で半日で完成。スピード感を語るなら、機械に語らせるべき。

Prototypes that once took a month via outsourcing can now be created in-house in half a day — let machines talk about speed.

(7) AIによるドキュメント自動生成

(7) AI-based Document Generation

昔は資料作りに2週間かかっていたのに、今やChatGPTに「パワポ作って」と頼めば30秒でドラフト完成。

Document creation that once took two weeks can now be completed in 30 seconds by asking ChatGPT to "create a PowerPoint."

(8) 自動翻訳(DeepLなど)

(8) Automatic Translation (e.g., DeepL)

英語の技術論文を辞書片手に数日かけて読んでいたのが、今やコピペ一発。努力の余地がない。

Reading technical papers with a dictionary used to take days; now, it's a single copy-paste — no room for effort.

(9) 決済・契約の電子化(DocuSignなど)

(9) Digitalization of Payments and Contracts (DocuSign, etc.)

ハンコをもらうためだけに出社していたあの頃がバカバカしくなる。ワンクリックで法的拘束力が発生。

The days of commuting to get a stamp now seem ridiculous — one click legally seals the deal.

(10) 物流自動化(Amazon Robotics)

(10) Logistics Automation (Amazon Robotics)

倉庫内ピッキングを人間が汗水垂らしてやっていたのが、ロボットに置き換わり、24時間無休で稼働。人間のスピード感など無意味。

Picking in warehouses, once done by humans sweating profusely, is now handled by robots operating 24/7 — human "speed" is meaningless.

まあ、こんな感じです。

Well, that's about how it is.

-----

なんかね、『スピード感を持って取り組め!』と言っていた上司や幹部に対して、

You know, to those bosses and executives who kept telling us to "work with a sense of speed,"

「一度くらい、私に謝罪してくれないかな」と思うことはあります。

Sometimes I wish they'd apologize to me just once.

ただ、その上司や幹部の中には、“私”自身も含まれていて、

However, among those bosses and executives, I realize I am included as well.

謝罪を要求される側としても、そこに立っていることは、ちゃんと分かっているんですけどね。

I understand that I also stand on the side expected to apologize.

-----

私たちは、これからも自己批判することなく、「スピード感を持って取り組む」と言い、または言われ続け、

We will continue, without self-criticism, to repeat the mantra "work with a sense of speed,"

そして、「スピード感を持って取り組む」最中に、気づかないうちに、この世から消えてしまうんです――スピード感を持ったまま。

And, while still working with that "sense of speed," we will eventually vanish from this world, still full of speed.

未分類

以前、MASの"アクティブエージェント"を調べて貰ったのですが、本日、大学の先生から"アクティビティエージェント"と違いを指摘されました。"アクティビティエージェント"とは何ですか?

「アクティビティエージェント」とは?

アクティビティエージェントとは、
「あらかじめ与えられた活動スケジュール(アクティビティプラン)に従って行動するエージェント」
を指します。

つまり、

  • 何時に

  • どこで

  • 何をするか
    事前に決まっている エージェントです。

例えば、

朝8時に自宅を出発し、駅まで歩き、電車で会社に行き、17時に退社してスーパーに寄り、帰宅する
というような「一日の予定表=アクティビティプラン」を持ち、これに沿って動くだけです。


対比:「アクティブエージェント」とは?

以前話題にした「アクティブエージェント」は、

  • 状況に応じて

  • 自律的に意思決定して

  • プランをその場で変更したり、行動を選択する
    エージェントです。

要するに、
受け身にスケジュールをなぞるだけ」のがアクティビティエージェント
自分で考えて臨機応変に動く」のがアクティブエージェントです。


まとめ表

 

項目 アクティビティエージェント アクティブエージェント
行動決定 事前に決められたスケジュールに従う 状況に応じて自律的に判断・行動
柔軟性 なし(スケジュール通り) あり(プラン変更可能)
典型例 通勤・通学のシミュレーション 災害時の避難行動シミュレーション
目的 交通量や移動需要の再現 状況適応や個別行動の再現

関連する有名な例

  • MATSim(Multi-Agent Transport Simulation)などは、アクティビティエージェントを使っています。

  • BDIモデル(Belief-Desire-Intention Model)などは、アクティブエージェント的な動きをさせるときに使われます。


つまり

今回教授が訂正されたのは、

「自律判断型エージェント(アクティブエージェント)じゃなくて、予定通り動く型(アクティビティエージェント)なんだよ」
という意味です。

この違いをわきまえておくと、研究の方向性や議論の立て方が大きく変わります。

 

2025,江端さんの忘備録

以前、私のコラムの読者の方から「江端さんは、その膨大な知識をどうやって得ているのですか」という質問を受けたことがあります。

A reader once asked me about my column, "Mr. Ebata, how did you acquire such vast knowledge?"

(現在は休止中ですが)私は、これまでに100本以上の技術コラムを寄稿してきました。そのため、そう思われたのだろうと思います。

(Although currently on hiatus,) I have contributed over 100 technical columns, which likely gave that impression.

しかし、上記の質問をされた方は、私について『大変な勘違い』をされています。

However, the person who asked that question has made a significant misunderstanding about me.

-----

私のコラム作成プロセスは、以下の通りです。

My column creation process is as follows.

(Step 1) コラムの依頼(テーマ)を受ける

(Step 1) Receive a request (theme) for a column.

(Step 2) ざっくりとしたマイルストーン(連載内容と回数)を決める(だいたい月一回)

(Step 2) Roughly set milestones (series content and number of installments), usually about once a month.

(Step 3) 必要に応じて、狂ったように文献を調査し、どこにでもインタビューに出かける

(Step 3) Conduct frenzied literature research and, if necessary, go anywhere for interviews.

(Step 4) 『自分なりの"話の仕方"と"感想"を持てる』ようになるまで、徹底的に調べ尽くす

(Step 4) Investigate thoroughly until I can form my way of telling the story and my impressions.

(Step 5) 上記(Step 4)を、WordとPowerPointの上にぶちまける

(Step 5) Copy the content from Step 4 into Word and PowerPoint.

(Step 6) (Step 3)に戻る

(Step 6) Return to Step 3.

ーー この繰り返しです。

ーー This cycle repeats endlessly.

-----

つまり、私は壮大な自転車操業をしているだけであり、私の頭の中に"膨大な知識"などというものは、まったく存在しません。

In short, I am merely engaged in a grand-scale bicycle operation, and there is no such thing as "vast knowledge" stored in my head.

私の人生において言えることは、「自分の意思で獲得した」と自信を持って言えるものは、一つもない、ということです。

What I can say about my life is that there is nothing I can confidently claim to have "acquired by my own will."

私の知識のすべては、「他人から与えられたタスク」によって動かされた結果に過ぎません。

All of my knowledge is merely the result of being driven by "tasks assigned by others."

「自分のやりたいこと」ーーそんなもの、私には存在しません。

"My own desires"—such things do not exist within me.

他人から与えられたタスクを、自分のやり方でやる ーー これが、私に許された唯一の裁量です。

Doing tasks assigned by others in my way—that is the only discretion I have been allowed.

-----

だから、私はずっと思っていました。

That’s why I have always thought:

『生成AI』に関してだけは、完全なお客さま(エンドユーザ)として利用のみに徹し、この分野にだけは絶対に手を出すまい、と。

When it comes to "generative AI," I will remain a complete customer (end-user) and never get involved in the development side.

しかし、どうやら世界は、この私に、そんな"日和見"を許してくれないようです。

However, it seems the world will not permit me such opportunistic neutrality.

『業務命令』ーー いつだって、これが私を動かす唯一のトリガーであり、これからもそうあり続けるのでしょう。

"Work orders"—they have always been the only trigger that moves me, and likely always will be.

-----

という訳で、私、連休で賑わう観光地とか空港とかのニュース(の録画)は、飛ばして見ています。

Therefore, I fast-forward through news recordings about tourist spots and airports bustling during the holidays.

私は、楽しそうにインタビューに応じている人に、呪いのオーラを出したくないんです。

I don't want to emit a negative aura toward people who cheerfully respond to interviews.

『自分のやりたいことが分からない』という方は、多分、ご自分のことを「不幸な人間」と思っているかもしれませんが ―― 『意外に、それは最高の人生なのかもしれないですよ』ということを、お伝えしたくて。

 

未分類

chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://www.city.yokohama.lg.jp/city-info/yokohamashi/tokei-chosa/portal/kankobutsu/index-j.files/honbun.pdf?utm_source=chatgpt.com

 

chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/https://businessyokohama.com/wp-content/uploads/2022/02/2021CityofYokohama_Statistics.pdf

https://jmap.jp/cities/detail/city/14108?utm_source=chatgpt.com

[1] 総務省統計局, "国勢調査報告(昭和35年)," 総務省統計局, 1960年.https://www.e-stat.go.jp/stat-search/files?page=1&toukei=00200521&tstat=000001036867
(英語表記例: Statistics Bureau of Japan, "Population Census Report (1960)," Statistics Bureau of Japan, 1960.)

2025,江端さんの忘備録

私が学生のころ、第二次AIブームのまっただなかで、その中で大いに流行ったのが「ファジイ推論」です。

When I was a student, we were in the midst of the second AI boom, and one of the major trends at that time was "fuzzy reasoning."

(これについては、こちら↓のコラムが詳しいのでご参照ください)。

(For more details on this, please refer to the column linked below.)

当時(たぶん今も)、コンピュータとは0/1だけで判断する計算機と考えられていたのですが、ファジイ推論は、「ものごとを白黒つけない」という考え方を拡張したものでした。

At the time (and probably even now), computers were considered machines that made decisions based solely on 0s and 1s, but fuzzy inference extended the idea of "not forcing things into black and white."

さらに、この「ものごとを白黒つけない」という考え方を、コンピュータのAND/OR/XOR/NANDの論理演算にも拡張させる「ファジイ論理」という概念まで導入できました。

Furthermore, this idea of "not forcing things into black and white" was expanded into computer logic operations, such as AND, OR, XOR, and NAND, introducing the concept of "fuzzy logic."

当時、私はそういう考え方があることは知っていたし、興味もありましたが、自分が当時取り組んでいた研究(ロボットの制御)とは、それほど関連性はありませんでした。

At that time, I was aware of such ideas and interested in them, but they were not particularly relevant to the research I was engaged in (robot control).

しかし、そんな私に「GOサイン」を出してくれたのが、石原好之教授でした。

However, it was Professor Yoshiyuki Ishihara who gave me the "green light."

教授は、ある会社から依頼されたパン焼き製造の制御案件を私にもってきて、その温度制御を、私にファジイ推論を使ってやってみることを勧められました。

The professor brought me a control project for bread baking, requested by a company, and encouraged me to try using fuzzy inference for temperature control.

私は早速シミュレーションに取りかかったのですが、それに要した時間が、"3日間"という超短期間だったことに、自分自身が衝撃を受けました。

I immediately started the simulation, and I was surprised that it only took me three days to complete.

―― システム構築、めちゃくちゃラク。

"Building the system was unbelievably easy."

なにしろ、数値パラメータを細かく調整する必要もなく、「庫内温度が急上昇したらスイッチを切れ」という自然言語の制御命令を追加するだけで、制御ができてしまう ―― ということに、衝撃を受けたのです。

After all, I was amazed that I could add a natural-language control command, such as "turn off the switch if the oven temperature rises sharply," without fine-tuning numerical parameters.

庫内の物理的環境も深く考慮することなく、「現場でパンを焼く人ならこうするだろうなぁ」と思える制御を、必要に応じてルールとして追加するだけで、それなりの制御ができてしまう。この事実に、本当に驚かされました。

Without thoroughly considering the physical environment inside the oven, can I create adequate control by simply adding rules based on what a baker at the scene would likely do? This truly astonished me.

そして、最大の衝撃は、「ルール同士が矛盾していても、かまわない」という、恐るべきアバウトさでした。

And the biggest shock was the incredible leniency; it didn’t matter even if the rules conflicted with each other.

これは、工学研究者(ただし学生)として、既存の制御概念が吹き飛ぶほどのパラダイムシフトでした。

For me, as an engineering researcher (albeit a student), it was a paradigm shift that shattered existing control concepts.

その辺りの話は、このコラムのページが詳しいです。

For more details on this point, please see the page linked in the column.

イラスト

-----

―― もしかしたら、物事は「白黒つけない」ほうが上手くいくのか?

Perhaps things work better if we don't try to force black-and-white judgments?

この発想を、私の人生の基本理念として植え付けたのが、「ファジィ制御」であり、「パン焼き装置」であり、そして「石原好之教授」であったと言っても、決して過言ではないと思います。

It would not be an exaggeration to say that this idea, planted as a fundamental principle of my life, was thanks to "fuzzy control," the "bread-baking device," and Professor Yoshiyuki Ishihara.

私は今でも、マルチエージェントシミュレーションのエージェントの自律判断ロジックに「ファジィ推論」を使い倒しています。

Even today, I extensively use "fuzzy inference" in the decision logic of agents in multi-agent simulations.

理由は「上手い、安い、早い」の三拍子が揃っているからです。

The reason is that it hits all three: "effective, inexpensive, and fast."

今でも、1日もらえれば、大抵のエージェントの心理モデル(正しく振る舞うかどうかはさておき)を作れる、という自信があります。

Even now, if given a day, I am confident that I can build a psychological model for most agents (whether they behave perfectly or not is another story).

というか、先日、大学の新人歓迎会で学生さんと話していたとき、「人間のように振る舞うアルゴリズム」の作り方について、パラメータのしきい値設定に苦慮している、という話を聞きました。

Actually, at a recent university welcome party, I spoke with a student who was struggling with setting threshold parameters to create "human-like behavior" algorithms.

江端:「なんでファジィ使わないの?」

Ebata: "Why don't you use fuzzy logic?"

と尋ねたら、

When I asked that,

学生さん:「"ファジィ"って何ですか?」

The student replied, "What does 'fuzzy' mean?"

と言われました。

That’s what he said.

私は多くは語りませんでしたが、「手を抜けるところは、できるだけ手を抜いた方がいい」と考えている私のような怠け者からすると、『もったいないなぁ』とは思いました。

I didn’t say much, but as someone who believes "you should cut corners where you can," I couldn't help but think, "what a waste."

-----

ということで、先生との思い出を記載させていただきました。

Thus, I have shared my memories related to the professor.

私は、5月の連休明けの博論審査の準備で、毎日ゾンビのように、計算と論文執筆に追われ、今回の祝賀会には出席できず誠に残念です。

Currently, I am preparing for my doctoral dissertation review right after the May holidays, spending every day like a zombie, overwhelmed with calculations and thesis writing, and I deeply regret that I cannot attend the celebration.

正直、5月に大量の核ミサイルが関東を襲来してくれないかな、と思うくらいの破壊的な精神状態になっております。

I am in such a destructive mental state that I almost wish a barrage of nuclear missiles would hit the Kanto region in May.

ともあれ、「石原好之先生祝賀OB会」にて、このページのURLを先生にお伝えいただければ幸いに存じます。

Nevertheless, I would be most grateful if you could share the URL of this page with Professor Ishihara at the "Professor Yoshiyuki Ishihara Celebration Alumni Meeting."

きっと、石原先生は笑ってくださることと思います――もし万が一、先生がお怒りになられた場合でも、そのご連絡は無用です。

I am sure Professor Ishihara will smile -- and even if, by some chance, he is upset, there is no need to inform me.

改めまして、石原好之先生の瑞宝中綬章受章、心よりお祝い申し上げます。

Once again, I sincerely congratulate Professor Yoshiyuki Ishihara on his conferment of the Order of the Sacred Treasure, Gold and Silver Rays.

江端智一

Tomoichi Ebata

ファジィカー

2025,江端さんの忘備録

先日テレビで、「スマホの利用で語彙力が落ちる」という話を耳にしました。

The other day, I heard on TV that "using smartphones reduces vocabulary skills."

こういう話は枚挙に暇がなく、新しい技術や文化の出現に対する漠然とした不安が源になっているようですが、すべてを無視するわけにもいきません。

These kinds of claims are endless and often stem from vague anxieties about new technologies or cultures, but we can’t ignore them entirely.

■「テレビを見るとバカになる」──これは、まずデタラメでしょう。

■ "Watching TV makes you stupid"? This is nonsense.

そもそも「バカ」の定義が不明確です。

To begin with, the term "stupid" is not clearly defined.

■「マンガを読むと知能が落ちる」──証拠はありませんし、読解力向上を示す研究も存在します。

■ "Reading manga lowers intelligence" ー There’s no evidence for this, and some studies even show it can improve reading comprehension.

■「YouTubeばかり見ていると集中力が落ちる」──統計的な裏付けは不十分です。

■ "Watching too much YouTube reduces concentration" ー There's insufficient statistical backing for this claim.

というか、YouTube視聴中はそれなりに集中していると思います。

If anything, people seem quite focused while watching YouTube.

■「電子辞書は紙の辞書より劣る」──学習効率に明確な差はないという研究が多く、私個人は電子辞書の方が圧倒的に優れていると思っています。

■ "Electronic dictionaries are inferior to paper ones" ー Many studies show no significant difference in learning efficiency, and I find electronic dictionaries vastly superior.

辞書で1語を探す間に、電子なら10語は調べられる。

With a paper dictionary, you find one word in the time it takes an electronic one to find ten.

そして、英語習得は「接触回数」が命だと信じています。

I believe that repeated exposure is key to mastering the English language.

■「AIに頼ると考える力が衰える」──これについては結論が出ていませんが、「AIに頼るとラクできる」ことには100%同意します。

■ "Relying on AI weakens your thinking ability" ー no conclusive evidence yet, but I 100% agree that "relying on AI makes life easier."

このあたりまでは、いずれもエビデンスに乏しい風評といえるでしょう。

Up to this point, most of these are unfounded rumors lacking solid evidence.

---

では、ここからは論文などで一定の裏付けがあるものをご紹介します。私のコメントも併せて記します。

Now, let’s look at topics that have some support in academic literature, along with my commentary.

■「スマホの利用で語彙力が落ちる」── 一部の研究で支持されていますが、私は懐疑的です。

■ "Using smartphones reduces vocabulary" ー some studies support this, but I’m skeptical.

わからない語彙をスマホで“秒で”調べられるのは、むしろ語彙力強化につながると思うのです。

Being able to look up unfamiliar words in seconds should help increase vocabulary.

ただし、そもそも調べる気がない人にとっては、確かに語彙力は落ちるかもしれません。

That said, if someone doesn’t bother to look things up, their vocabulary might indeed suffer.

■「SNSを使いすぎるとコミュニケーション能力が低下する」──一部の研究がこれを支持しているようです。

■ "Overuse of social media lowers communication skills" ー some studies seem to support this.

ただ、私はSNSを使っていないのに、コミュニケーションが得意ではないので何とも言えません(得意そうに見られていることは自覚していますが)。

However, I don’t use social media and still struggle with communication, so I wouldn’t say that ー though I know people often think otherwise.

■「ネット検索ばかりしていると記憶力が落ちる」──これは、かなりの研究で支持されているようです。

■ "Constant internet searching reduces memory retention" ー this is supported by a considerable amount of research.

■「ゲームばかりやっていると暴力的になる」──肯定・否定ともに多様な研究があります。

■ "Playing too many games makes you violent" ー there are studies both supporting and refuting this claim.

私はアナログ・デジタル問わずゲーム全般に弱く、やりません(勝てないからです)。

I’m terrible at games, both analog and digital, and don’t play them because I always lose.

それでも私のコラムには、ときどきオフェンシブな発言が出てきます。

Yet, my columns still occasionally feature offensive remarks.

ちなみに、ゲームはeスポーツとして公式に認められた現在、「ゲーム=暴力的」という論理は、「スポーツやってる奴は暴力的だ」という主張と同レベルでして、私は個人的にこれを肯定します。

Now that gaming is officially recognized as an e-sport, saying "games cause violence" is as logical as saying "sports players are violent," ー And I support that logic (as my own opinion).

■「写真を撮りすぎると記憶に残らない」──これは、多くの研究で支持されています。

■ "Taking too many photos diminishes memory" ー This is widely supported by research.

私は旅行先でもほとんど写真を撮りません。

I rarely take photos, even when traveling.

なぜなら、見返す機会がほぼないからです。

Because I hardly ever look at them afterward.

だったら、ライブの風景を目に焼きつけた方がマシだと思っています。

In that case, it’s better to imprint the live scenery in my mind.

---

人類は、新しいメディアが出るたびに「知能が下がる」「記憶が減る」と騒ぎ立ててきました。

Humanity has always panicked about "declining intelligence" or "weakened memory" every time a new medium appears.

でも今のところ、滅んではいません ーー 不思議ですね。

But so far, we haven’t gone extinct ー curious.

ChatGPTは怖くない ~使い倒してラクをせよ

2024,江端さんの技術メモ

仮想RTSPカメラの作り方と使い方のメモ

2024/11/21
江端
この仮想RTSPカメラは、クライアント(受信側)の接続を止めて、再度接続しようとするとクライアント(受信側)に動画が表示されなくなる、という欠点が発覚しております(2024/11/26) 
をお勧めします。
https://wp.kobore.net/2024/12/06/18206/

1. 背景と要件

1.1. 背景

  1. 地車間実験において複数カメラを準備する為、複数の仮想のRTSPカメラが必要となったため、これに対応する

1.2. 仮想RTSPカメラの要件

  1. 1台のWindowsPCにて最大4台程度の仮想RTSPカメラが実現できること
  2. 仮想カメラは指定したmp4ファイルの映像を配送する
  3. 上記のmp4ファイルは繰り返し再生できることが望ましい
  4. 仮想RTSPカメラは、通常のRTSPカメラと同様にrtsp://127.0.0.1:8554/testという形式で指定できること
  5. できるだけ簡易かつ汎用的なコマンドで実現できることが望ましい。

1.3. 事前検討

  1. 仮想RTSPカメラの実現方法としては、(1)ffmpeg, (2)Gstreamer, (3)VLC(VideoLAN Client), (4)C言語(Gstreamerライブラリ)が挙げられている。
  2. 検討の結果、mp4ファイルを繰り返し再生できる方法は指定されているが、試したところ実際に動いたのはVLCのみだったの、VLCで実現することにした。
  3. vlcのバージョンは、3.0.20以上であること(3.0.14では稼動しないことを確認済)。

2. 説明用の設定

  • 仮想RTSPカメラを設定するWindows10パソコンのIPアドレスを、便宜的に、192.168.0.3として取り扱うこととする。
  • 仮想RTSPカメラを再生するWindows10パソコンのIPアドレスを、便宜的に、192.168.0.25として取り扱うこととする。

3. VLCによる仮想カメラの作り方

3.1. 事前準備: 送信側(192.168.0.3)のファイアウォール設定設定

本節の設定は、設定しなくても動くこともあるので、動かなくなった場合のみに対応する。

送信側のVLCは、RTSP制御パケット(TCP:8554)とRTPデータストリーム(UDPポート)を送信する。これらがブロックされないようにする。

3.1.1. 受信規則の設定(クライアントからのRTSP制御パケットを許可)を許可)

  1. 「Windowsセキュリティ」懼「ファイアウォールとネットワーク保護」懼「詳細設定」を開きます。
  2. 左側の「受信規則」を右クリックして「新しい規則」を選択。
  3. **「ポート」**を選択して「次へ」。
  4. TCPを選択し、「特定のローカルポート」に8554を入力して「次へ」。
  5. 「接続を許可する」を選択し「次へ」。
  6. プロファイルを選択(プライベートにチェックを入れる)し「次へ」。
  7. 名前を設定(例: VLC RTSP TCP)して「完了」をクリック。

3.1.2. 送信規則の設定(RTP/RTCPデータを送信)を送信)

  1. 同様に「送信規則」を右クリックして「新しい規則」を選択。
  2. **「ポート」**を選択して「次へ」。
  3. UDPを選択し、「特定のローカルポート」に5000-5500を入力して「次へ」。
  4. 「接続を許可する」を選択し「次へ」。
  5. プロファイルを選択(プライベートにチェックを入れる)し「次へ」。
  6. 名前を設定(例: VLC RTP UDP)して「完了」をクリック。

3.2. 事前準備: 受信側(192.168.0.25)のファイアウォール設定設定

受信側が、Windows10でない場合は、本節は無視して下さい。

受信側のGStreamerは、RTSP制御パケット(TCP:8554)とRTPデータストリーム(UDPポート)を受信します。これらを許可します。

3.2.1. 受信規則の設定(RTSPとRTPストリームの受信を許可)を許可)

  1. 「Windowsセキュリティ」懼「ファイアウォールとネットワーク保護」懼「詳細設定」を開きます。
  2. 左側の「受信規則」を右クリックして「新しい規則」を選択。
  3. **「ポート」**を選択して「次へ」。
  4. TCPを選択し、「特定のローカルポート」に8554を入力して「次へ」。
  5. 「接続を許可する」を選択し「次へ」。
  6. プロファイルを選択(プライベートにチェックを入れる)し「次へ」。
  7. 名前を設定(例: GStreamer RTSP TCP)して「完了」をクリック。

3.2.1.1. RTPストリームのポート設定設定**

  1. 再度「受信規則」を右クリックして「新しい規則」を選択。
  2. **「ポート」**を選択して「次へ」。
  3. UDPを選択し、「特定のローカルポート」に5000-5500を入力して「次へ」。
  4. 「接続を許可する」を選択し「次へ」。
  5. プロファイルを選択(プライベートにチェックを入れる)し「次へ」。
  6. 名前を設定(例: GStreamer RTP UDP)して「完了」をクリック。

3.2.2. アプリケーション許可(必要に応じて)応じて)

GStreamerがファイアウォールでブロックされている場合、gst-launch-1.0の実行ファイルを許可します。

  1. 「Windows Defender ファイアウォールを介したアプリまたは機能を許可する」をクリック。
  2. 「別のアプリを許可する」をクリックし、GStreamerの実行ファイル(例: C:\msys64\mingw64\bin\gst-launch-1.0.exe)を指定して追加。
  3. 「プライベート」にチェックを入れて「OK」をクリック。

3.3. 仮想RTSPカメラの起動方法

以下のコマンド(例示)で起動する。

$ "C:\Program Files\VideoLAN\VLC\vlc.exe" -vvv "0326_JP.mp4" --sout="#rtp{sdp=rtsp://0.0.0.0:8554/test}" --loop

コマンドの内容は、以下の通りである。

  • "C:\Program Files\VideoLAN\VLC\vlc.exe": vlc.exeを起動するコマンドをフルパスで指定。
  • vvv: デバッグ情報を詳細に出力する。問題発生時のトラブルシューティングに役立つ。
  • "0326_JP.mp4": 再生するmp4のファイル名(このファイル名は例示であるので、使用時のファイル名を使用する)
  • rtsp://0.0.0.0:8554/test: RTSPアドレス名。0.0.0.0は特殊なアドレスで、「すべてのネットワークインターフェース」を意味する。サーバーがリッスンする対象が、特定のIPアドレスではなく、すべての有効なインターフェースで接続を受け付ける設定である。8554は、ポート番号である。RTSPのデフォルトポート番号は554であるが、アプリケーションによって異なるポート番号が指定されることがある。この例では8554を使用している。/testは、ストリームのパス名を示す。サーバー内でストリームを識別するための名前である。
  • loop: ファイルの繰り返し再生を指定する。

なお、上記のコマンドを投入すると、以下の黒い画面が立ち上がり、コマンドは直ちにリターンする。矢印は再生している位置を示している。

このコマンドを停止するには、この画面を右上の『・』を押下する。

3.4. 仮想RTSPカメラのフレームレート/画像サイズの変更方法

VLCを使って仮想RTSPカメラを実現した際に、送信するフレームレートや画像サイズ(解像度)を変更することは可能である。以下の方法で設定を変更する。

$ "C:\Program Files\VideoLAN\VLC\vlc.exe" -vvv "0326_JP.mp4" --sout="#transcode{vcodec=h264,fps=15,width=640,height=360}:rtp{sdp=rtsp://0.0.0.0:8554/test}" --loop

  • fps=15:
    • 送信するフレームレートを15fpsに設定する。
    • 必要に応じて、他の値(例: 3060)に変更可能。
  • width=640,height=360:
    • 解像度を640x360に設定しています。
    • 必要に応じて、他の解像度(例: 1920x1080640x480)に変更可能。

3.5. 複数の仮想RTSPカメラの起動方法

今回のケースでは、1台のPCで複数のカメラを実現するので、IPアドレスを固定として、異なるポート番号を使って、複数のカメラを実現することとする。

具体的には、以下のポート番号(8554, 8555, 8556)を変えて、それぞれコマンドを押下することで、同じmp4ファイルで3台のカメラが実現できる(もちろん、mp4ファイルを変えても良い)。

$ "C:\Program Files\VideoLAN\VLC\vlc.exe" -vvv "0326_JP.mp4" --sout="#rtp{sdp=rtsp://0.0.0.0:8554/test}" --loop

$ "C:\Program Files\VideoLAN\VLC\vlc.exe" -vvv "0326_JP.mp4" --sout="#rtp{sdp=rtsp://0.0.0.0:8555/test}" --loop

$ "C:\Program Files\VideoLAN\VLC\vlc.exe" -vvv "0326_JP.mp4" --sout="#rtp{sdp=rtsp://0.0.0.0:8556/test}" --loop

4. 仮想RTSPカメラの起動確認方法

4.1. VLCを使った起動確認方法

簡易な確認方法として、画像受信もVLCを使用する方法を提示する。

受信側Windows10(192.168.0.25)のVLCを立ち上げて、以下の操作を行う。

ネットワークURLに、rtsp://192.168.0.3:8554/testと入力する。

これで映像が表示されれば成功である。

4.2. GStreamerを使った起動確認方法

以下のコマンドを投入して下さい。

$ gst-launch-1.0 -v rtspsrc location=rtsp://192.168.0.3:8554/test latency=0 ! rtph264depay ! h264parse ! avdec_h264 ! videoconvert ! glimagesink

(Windows10の場合は、autovideosinkでは動かないことが多い)

4.3. 注意点

仮想RTSPカメラはmp4ファイルを繰り返し再生するが、ファイル終了時にVLC(および殆どのクライアント)は、映像が停止したものと判断して再生を終了する。

現時点で、この対応方法は不明である。

以上