我がマシン達のメモリ事情
メモリが高騰しているとのことで、あまり大きな声では言えませんが、私が所有している
DDR4のメモリは
4GB×4本 ： 16GB
8GB×16本 ： 128GB
32GB×27本 : 864GB
計 1008GB（1Tに届かず）
DDR3は控えめで、2GB×4本、8GB×14本で、120GB
で、DDR3とDDR4を合計すると1TBを超えますね。
32GBのDIMMですが、5年前に新品を1本2万円×4本を買った記憶がありますが、それ以降、中古ばかりで大体5000円弱から8000円弱で買っています。
今、おなじみの中古の販売サイトで見ると1本1万円超えているので、高騰しているのを実感しました。
今思えば2年程前（ちょうどDDR5が本格的に軌道に乗り出した頃）に中古市場に大量に出てその時に4000円台で出ていましたね。その時に8本ぐらい買った記憶があります。
ちなみに、以下のとおり、ほとんどがWindows11のマシンになっていますが、Windows Server 2019に32GB×4本、Windows Serverに32GB×8本搭載しています。また、1本、余っているのでメモリが高騰している今、オークションに出すタイミングなので思案しています。
某SNSで大容量メモリの用途について質問があったのですが、
（1）RAMディスク
メインマシンは、128GB載せていまして用途はプログラミングと動画編集です。40GBぐらいRAM DISKに割り当てて、テンポラリファイルの置き場にしています。中間ファイルをRAM DISKに置くので、コンパイルは早いです。その他、ブラウザのキャッシュもRAM DISKに置いています。この用途ですが、速度を稼ぐこともありますし今となっては気にしすぎなのですが、SSDの寿命を延ばす効果を期待しています。
このマシン、今タスクマネージャを見ると、使用中が55GB（コミットが60GB）で、キャッシュが19GBなので、計74GB、アプリを動かすことを考えると128GB載せる意味はありますね。
（2）LLM（AIサーバー）
LLMを動かそうかと思うと128GBないとという感じですが、LLMを動かすマシンは256GBのメモリを載せています。
（3) VM（仮想マシン）
仮想マシンのテスト環境（と言ってもこちらはWindows Server 2025ですが）もメモリは256GB載せています。
同時に4つマシンを動かすと単純計算で1つあたり64GBとなるので余裕を考えたらメモリは載せた方がよいですね。
こんなところが考えられるのですが、他には
（4）メモリ高騰への対応
（5）パソコンの長寿命化
というのもありますね。どちらもリザーブ目的になりますが、メモリが安いときに余分に積んでおけば節約になりますし、その時に最大容量まで積んでおけば経年にも対応できます。メモリの要求量ですが、徐々に上がっておりまして、例えば2000年のパソコンでしたら128MBあればよかったですが、4半世紀経った今は16GBは欲しいところで倍率で言えば、64倍になります。ちなみに私は2000年当時、メモリ1GB積んでいまして、今はAI用途のマシンが256GB積んでいるので、四半世紀で256倍ということになります。
Windows11 達の各マシンのシステム情報を再掲します。最低が24GBで最大256GB積んでいますが、概ね32GBのマシンが中心です。
AIを使用した記事については素直にAIを使ったと書いた方がよいのではないか？
世の中猫も杓子もAIで、「AIで○○しました」という記事が見受けられるが、最近ではさらにAIで生成した文章と思われるがそれを隠してしれっと記事にしているものも見かけるようになりました。
ちなみに、私のブログの場合は、どこまでAIが関与したかを、『この文章は、ChatGPTとの共同作業により作られています。』等と文末に書くようにしています。
もちろん、ある程度の文章を生成させようとすればそれなりのプロンプトが必要なのでそのオリジナリティはあるだろうが、AIに丸投げしたような文章はそのうち飽きられるかと思います。
私の場合、最近はAIが生成したと思われる動画を見ないようになった。生成AIが出だした当初はそのクオリティに驚かされたが、ある時からAIで作ったかどうかがなんとなくわかるようになり、違和感が許容できないようになった。もちろんこれはあくまでも主観になるが、ある意味人間の学習能力も捨てたものではないなと感心した次第です。
で、自分でAIと共同で記事を書くようになると他のWEB記事を読んだときに「これはChatGPTだ」と分かるようになってしまった。やはりそういう記事は読まなくなる。
だからと言ってAIを否定することもないしAIを使って記事を書くこと自体はよいが、例えば単なる情報ではなく、個人主観や主張を持った記事に関してはAIを使ったどうかを書いてもらった方が読み手に対してある程度安心感を与えるのではないでしょうか？
なぜ日本のITは遅れ続けるのか
――誤解と判断力の欠如が生む構造的リスク
第1章 判断できない組織のリスク
日本のIT産業が遅れている理由は、単なる技術力の差ではない。
現場での「判断力」を軽視する文化が、構造的な停滞を生んでいる。
経営が「最短の正解」を求めると、エンジニアは思考よりも指示の再現を優先するようになる。
結果として、「仕様通りに作る」ことが評価され、「正しく判断する」力が失われていく。
この文化は、プロジェクトを一見スムーズに見せるが、問題の根を放置したまま進むため、後工程で破綻を生む。
残念ながら「仕様書」は常に正しいとは限らず、完璧でもない。
判断できないエンジニアは、間違った仕様に基づいてシステムを構築してしまうし、完璧でない仕様書を前にすると、手を止めてしまう。
判断を封じた組織は、問題が発生しても修正できない。
それが、「失敗を繰り返す日本のIT構造」である。
第2章 SNS・マスコミ・勉強会が作った虚像
数年前、ネット上で「staticおじさん」という呼称が生まれた。
あるエンジニアが「オブジェクト指向を使わない」という判断をしたことをきっかけに、
SNS上で「オブジェクト指向を理解できない老害エンジニア」として揶揄されたのである。
しかし実際の現場では、この「老害エンジニア」と呼ばれた人々こそ、
長年にわたりシステムを安定的に稼働させ、数多くのプロジェクトを支えてきた主力層であった。
だが、ネット記事や勉強会での誤解や簡略化が進むうちに、
「古い技術者＝悪」とする物語が独り歩きしてしまった。
SNSや勉強会では、非エンジニアもこの議論に参加し、
「正しい技術の形」を安易に語る空気が生まれた。
それが、現場での健全な議論をも蝕んでいったのである。
第3章 SES構造と粗製乱造の危機
SES（システムエンジニアリングサービス）は、短期的には人員不足を補う仕組みとして機能している。
しかし、即戦力を求めすぎるあまり、エンジニアの自由な思考や技術習得の時間を奪ってしまう。
2025年現在、こうした安易な人材育成を政府が後押ししている面がある。
「デジタル人材育成のための『実践の場』開拓モデル事業」は、その典型だ。
本来は人材育成を目的とした制度であるが、現実にはSES構造の延命に利用され、
短期育成・早期投入による「粗製乱造」が進んでいる。
十分な学習機会がなくSESで派遣されたエンジニアは、正常な判断ができず、
SNS上の誤った知識の伝搬や、固定化された正解主義の文化にさらに晒される。
その結果、プロジェクトの現場では、思考を止めた「作業者」が増えていく。
第4章 経営者が問われる「誰を雇うか」
非エンジニアを安易に開発現場へ入れると、判断の混乱が起こる。
プロジェクトマネージャが優秀であれば協働は可能だが、
実際には「プロのマネージャ」はエンジニア以上に希少である。
経営者に問われるのは、「どんな人を雇うか」だけではなく、
「どんな判断を許す文化を作るか」である。
判断力を育てるには、失敗を許容する余白と、考える時間を保障しなければならない。
その余白を「余分なコスト」と見なす企業に、技術は根付かない。
例えば、「オブジェクト指向を使わない選択」や「既存の非オブジェクト指向資産を活かす判断」は、
適切な判断を行っている可能性が高い。
もちろん「オブジェクト指向を使う選択＝不適切な判断」ではないが、
その欠点を理解している必要がある。
炎上プロジェクトは、「エンジニア」と「非エンジニア」を見分ける格好の機会である。
普段から技術論を声高に語る自称エンジニアが、炎上した途端に理由をつけて逃げることがある。
一方で、普段は口数の少ないエンジニアが、現場を立て直すことがある。
「プロジェクトに責任をとれる人がエンジニア」であり、
「正しい判断ができるエンジニア」は、最終的にプロジェクトをゴールへと導く。
経営者としては、このような人物を見分ける「目」が求められる。
結論 ――経営者が持つべき「技術を見る目」
技術力の本質は知識の量ではなく、判断の質で決まる。
正解主義が支配する組織では、判断力が失われる。
誤った知識の伝搬と即戦力主義は、経営が気付かないうちに、
組織の判断力を蝕み、日本のITの停滞を再生産している。
経営者がまず行うべきことは、「判断するエンジニア」を育てる環境を整えることだ。
それには、自身が技術に明るくなるか、信頼できるエンジニアやマネージャを確保することも重要である。
それができない限り、日本のデジタル化は、どれほど予算を投じても前に進まない。
AIがコードを書く時代になろうとしている今こそ、
経営者に求められているのは「正解を知る力」ではなく、
「判断できる人材を見抜く力」である。
この文章は、ChatGPTとの共同作業により作られています。
我がマシン達のWindows 11 25H2のインストール状況(2025/11/1）
約一か月にわたり続けてきましたが、一通りWindows11 25H2にできました。
2025/11/1 現在（アップデート完了）
Ryzen 9 5950X : 25H2を新規（22H2→23H2→24H2→25H2（破損）、25H2（新規））
Ryzen 9 3950X : 24H2 → 25H2
Core i9-10980XE : 24H2 → 25H2
Core i7-7820X : 24H2 → 25H2
Core i7-6950X : 23H2 → 25H2
Core i7-6850K : 23H2 → 25H2
Core i7-5960X : 23H2 → 25H2
Core i7-4960X : 24H2 → 25H2
Core i7-3970X : 25H2(新規)
Core i7-990X : 24H2 → 25H2
今回は、いわゆるイネーブルメントパッケージを使わないで25H2のISOからアップデートしました。
今のところ、感じている不具合ですが、画面のスケーリングを150%にしているディスプレイでディスプレイ電源OFF→ONの復帰時にスケーリングがおかしくなる（一部のウインドウが100%になる）、たまにデスクトップのアイコンの位置が変わる、がありますが、それ以外は動いているようです。
業務アプリを動かすマシン（Core i7-6850K）のOSもバージョンアップしたのですが、半分ぐらいのアプリで不具合は出ていません。残りの半分はe-taxとかになるのでしばらくは使わないので使うときに不具合があればその時の最新バージョンを再インストールになるかと思います。
これで、Intelの黄金時代（2010年代）のHEDT（初代Core i7から10代目のCore i9）のOSがすべてWindows11になりました。というわけで、Ares-6のOverAllの結果（数字が小さい→性能が高）とともに各マシンのシステム情報を以下に
計測はChrome（バージョン141.0.7390.123）で行っています。Chromeですがバージョンが上がるたびにJavaScriptの性能が上がっているようで、比較を行うにはChromeのバージョンを揃える必要があります。
Ares-6ですが、基本的にシングルスレッド性能の比較になります。マルチスレッドの比較も機会があれば行おうかと思います。値の推移を俯瞰すると順調に性能が上がっていることが分かります。AMDのZEN2、ZEN3も比較の為に結果を出しています。Ares-6ですがややAMDに有利なようです。体感ではCore i7-7820XやCore i9-10980XEですがほぼZEN2のRyzen 9 3950Xと同じパフォーマンスかと思います。
変数は「箱」か「名札」か？― 初心者教育から束縛モデルまでを考える
以前、「変数は箱か名札か？」で動画を上げたのですが、あまりアクセスはなかったのですが、最近少しアクセスがあり、改めて見たら面白かったので、もう少し突っ込んでまとめてみました。
プログラミング教育の現場では、今も昔も「変数とは何か？」が最初のハードルです。
伝統的には「変数は値を入れる箱」と説明されますが、
最近では「変数はオブジェクトに貼られた名札（ラベル）だ」と主張する声も聞かれます。
一見、単なる比喩の違いのように見えますが、
この議論の背後には、プログラミング言語の理論と設計思想の根深い違いがあります。
ここでは、初心者教育から理論的背景、そして実用上の含意までを整理してみます。
Ⅰ. 初心者教育での「箱」モデルの意義
最初に登場するのが、もっとも直感的な「箱」モデルです。
変数とは、値を入れておく箱である。
a = 1
b = a
a = 2
このとき、a の中身を 2 に変えると、b の値はそのまま 1。
学習者は「箱に入れた値を取り出して使う」イメージで簡単に理解できます。
C や C++ のように、メモリ上の領域が実際に割り当てられる言語では、
この比喩はきわめて正確であり、教育的にも有効です。
Ⅱ. 「名札」モデルの登場と混乱
一方で、Python や JavaScript では、変数の実体がやや異なります。
これらの言語では、変数はオブジェクトへの参照を持つ仕組みであり、
代入は「名札を貼り替える」動作に近いのです。
変数は、オブジェクトに貼る名札である。
a = [1, 2, 3]
b = a
a[0] = 9
ここで b を出力すると [9, 2, 3]。
箱モデルでは説明しづらく、「名札モデル」の方が合うように見えます。
しかし、注意すべきはこの比喩も完全ではないという点です。
配列の各要素 a[0] にまで「名札」を持ち込むと、
今度は配列の連続性やメモリ構造のイメージが崩れてしまいます。
結果として、初心者をさらに混乱させることもあるのです。
Ⅲ. C/C++が示す「共存モデル」
C や C++ では、値型と参照型（ポインタ型）が共存しています。
int a = 1;
int &r = a;
このとき r は a の別名であり、どちらを変更しても同じ領域が変化します。
つまり C++ は、「箱」と「名札」の両方の性質を明示的に区別できる言語です。
教育的にはこの構造が非常に有益で、
物理的なメモリ構造と論理的な参照概念の橋渡しを学ぶことができます。
ただし、ポインタや参照はプログラミングの初心者にとっては難しい概念である。
Ⅳ. 関数型言語における「束縛モデル」
さらに理論的な世界へ進むと、
「変数は値を入れるものではなく、“値（あるいは式）に束縛される名前”だ」
という考え方が登場します。
束縛（binding）＝変数と式の対応を定めること。
Haskell などの関数型言語では再代入ができず、
変数は一度束縛されたら変更できません。
x = 1
y = x + 2
このとき x や y は「箱」ではなく「式の定義名」です。
評価は遅延的に行われ、必要になるまで実際の値が求められません。
この仕組みは理論的には非常に美しく、
純粋関数・副作用の排除・数学的推論のしやすさといった利点をもたらします。
Ⅴ. 束縛モデルの強みと限界
束縛モデルの最大の利点は、式そのものをオブジェクトとして扱える点です。
たとえば、自動微分やDSL（ドメイン固有言語）の分野では、
式構造を保持して解析・変換する必要があります。
しかしその一方で、束縛モデルには現実的な制約もあります。
| 項目 | 束縛モデル（遅延評価） | 参照モデル（即時評価） |
|---|---|---|
| 抽象性 | 高い | 低いが直感的 |
| 実装効率 | 低い（オーバーヘッドあり） | 高い |
| デバッグ | 難しい（評価タイミング不明） | 容易 |
| メモリ予測 | 困難 | 明確 |
結果として、実用言語の多くは参照モデルを基本にし、
必要な箇所だけ束縛的な振る舞いを導入する設計を採用しています。
Ⅵ. 束縛モデルが主流にならなかった理由
-
- パフォーマンスとメモリ効率の問題
遅延評価や式構造の保持にはコストがかかる。
- パフォーマンスとメモリ効率の問題
-
- 最適化の困難さ
コンパイラが静的解析しにくく、最適化しづらい。
- 最適化の困難さ
-
- デバッグや可視化が難しい
どの時点で評価されたかが分かりづらい。
- デバッグや可視化が難しい
-
- 実際に必要なケースが限られている
自動微分やDSLなど一部領域に限定される。
- 実際に必要なケースが限られている
Ⅶ. 現代的アプローチ：必要な部分だけ「束縛的」に
今日では、C# の Expression<T> や
Python の sympy / jax、
C++ の Expression Template など、
必要な箇所だけ束縛モデル的挙動を模倣する仕組みが採用されています。
つまり、
「束縛モデル全体を採用するのではなく、
その一部を道具として使う」
という方向に落ち着いています。
Ⅷ. 教育的まとめ：段階的理解のすすめ
| 学習段階 | 目標 | モデル | 教育上の重点 |
|---|---|---|---|
| 初級 | 値の代入と操作の直感的理解 | 箱モデル | シンプルな心象で理解する |
| プロ（中級） | メモリと参照の関係を理解 | 箱＋参照モデル | オブジェクト共有・ポインタ・参照 |
| 研究レベル | 抽象的な束縛・遅延評価・純粋関数 | 束縛モデル | 数理的抽象化・関数をデータとして扱う |
Ⅸ. 結論：「名札」は“箱”を超えるものではない
「名札」や「束縛」という比喩は、
実行環境や抽象化の観点を説明する一つの手段に過ぎません。
しかし、それを「箱より優れている」と主張するのは誤りです。
比喩はあくまで教育のためのツールであり、
言語設計の本質はメモリ・参照・評価戦略の選択にあります。
実務的な観点から見れば、
「箱モデル＋参照の理解」で十分に事足り、
束縛モデルは特定分野での理論的・実験的意義を持つに留まります。
最後に：比喩の目的を取り違えない
変数を「箱」と呼ぶのも、「名札」と呼ぶのも、
プログラミングという抽象世界を理解するための足がかりに過ぎません。
重要なのは「どの比喩を使うか」ではなく、
その比喩がどの抽象化層を説明しているのかを意識することです。
プログラミング教育において本当に求められるのは、
比喩をめぐる正しさの議論ではなく、
学習者が言語の階層構造（値 → 参照 → 束縛）を自然に昇っていけるように導くこと
なのかもしれません。
この文章は、ChatGPTとの共同作業により作られています。