web6047 - 2026年 1月

▲ AI をいっさい使わずに自分の力で作った人体描画システム

特別な記事へのリンク

ゲームコーナー　

その他 単発のアプリ

2026年1月1日

プログラミング　人体描画システム

1. こんなことができるようになりました。
   　↓
2. 自分の力で作る良さについて
   　↓
3. その他： ベクタ画像貼り付けの便利化を行った
   　↓
4. その他： 萌えの髪飾りを付けた
   　↓
5. それでも至らない点がある
   　↓
6. ところで事業と言えば、、確定申告

1. こんなことができるようになりました。

まだぎこちないですけど、歩くことができるようになりました。

そして吹き出しでしゃべらせることもできるようになりました。

動画に映っている「キャップマスク男」は私です。

2. 自分の力で作る良さについて

もともと有名なライトノベルの一場面、『振り向いて「大好き🩷」と言う』というのをやっていたんですけど、「事業」という位置づけでこれを作っているので「I like you🩷」（好き）にしておきました。

（振り向いて大好きと言うことが事業なのではなく、これは単なるサンプルです）

ふざけすぎても良くないし、人のネタを使うのもなぁと思ったからです。

「歩く」というモーションデータは どこからかコピってくれば、質が高く楽でしょうけど、「自分で作る」というのは大切なんですよね。作品への思い入れとか、私が作りましたと堂々と言えます。

自分の手で自分が歩く姿を撮影し、その動画をコマ割りして、コマごとに自分の姿勢をトレースし 3DCG モデルへ反映させる、という作業を行いました。

それで「3D お姉さん」がヨタヨタと歩いています。

歩く動きを自分で採取するときのそういうノウハウを経験でき、いろいろ得るものがあります。

▼動画のコマと 3DCG モデルを重ねて表示し、角度（rad( 10 ) とか）を調整してコマとモデルを一致させます。（トレース）

また、人は作品を鑑賞するとき、作者の努力で作ったのか、それとも他力本願で作者の努力は小さいのかを、結構よく見てたりします。「トレースだと発覚したとき」とか、「実は3Dデッサン人形を使っていた」とか、「ゴーストライターがいた」とか、発覚するとみんな毎回必ず失望します。

「個人的に得るものが少なくなるから」、「人が失望するのを避けるため」、私は AI を全然使わない、、、と言えるかな。

あと、自分の力で作品を作り上げたときの喜びがとても大きいから、というのもあります。

私なりの魅力を我ながら感じているんですね。

そこに自分だけの良さと言うものが光っていて、ちゃんと引き付けてくれるんです。

画像を大きくすると良さが顕著になると思います。

3. その他： ベクタ画像貼り付けの便利化を行った

それから面に貼り付ける「ベクタ画像」（テクスチャ代わり、今回の顔）ですが、Excel で作図する際に「灰色の点線図形」で囲むとその点線を、貼り付ける面にピタリと合うように調整して描画してくれる、ようにしました。

▼画像左端の灰色の点線図形の領域（赤矢印で示す）が、	▼貼り付ける面にピタリと合う

これで「面から飛び出す図形」とか貼り付け作業がやりやすくなります。

4. その他： 萌えの髪飾りを付けた

あと、「I like you」と言ったときに「萌えッ」とさせるために3Dお姉さんにピンク色の髪飾りを付けてみたんですが、女の子っていうのはたったそれだけのことでこうも変わるものなんだなと思いました。

▼髪飾りなし		▼髪飾りあり

夜空の満月にちょっと月見団子とか、ススキでも添えてみればちょっと違う、というのとたぶん同じでしょうね。（同じなのか？）

5. それでも至らない点がある

で、これで順風満帆というわけではなく、このシステムには不満点がいくつかあり、「１からの作り直し」という案が見え隠れしています。

• 処理が重い（結局 WebGL 使ったほうが良いんじゃないか、、WebGL って透過してページと合成できるのかな）。
• 髪の毛部分のモデルを別のものに切り替えて、突然まったく別の髪型になるというのをやりたいけど、もともとそういうことを想定していなかったので、プログラムをどう変更するか見当がつかない。
• １つのキャラはおなかをルートとしたツリー構造になっているが、おなか（ルート）だけを回転させたいというとき、少し手間がかかる。

でも今から１から作り直すのはあまり現実的じゃないので、、現状で満足しなきゃならないかも。

6. ところで事業と言えば、、確定申告

事業をやっている人は年末年始をタイミングとして「その年いくら もうけたのか」を書類にまとめて国に提出しなければなりません。（確定申告）

報告することで、その人はどれだけ利益を出し、利益に対していくらの税金を徴収する必要があるのか、を国が知ることができるんですね。星の数ほどある各個人の各事業について国が個別に計算するのは無理で、各個人が自分で計算し報告し、それで もうけた額に応じて税金を納めることになります。

私は何も売らなかったので、「電気代がかかりました」という内容の報告をすることになります。

それも立派な申告、必要な申告です。

電気代がかかっただけなのか、数億円 もうけたのかは、その人が申告しない限り国は知ることができないのですから。

国のさまざまなインフラ設備（電気や通信網、道路や信号機など）を利用してそれで得られた利益なので、そこからインフラの利用料として所得税を徴収し、その税金を使ってまたインフラ設備を整えます。…ということで合っているかな。

数億円 もうけたことを隠すと、所得隠しとか脱税のニュースになりますね。

そういうのは全然スジが通らない、分かってない、ということです。

明日、朝のニュース「平行四辺形、電気代だけだったことを隠ぺいか」

平行四辺形「えへへへ、すまねぇ」

代官様「すまねぇだと？！　ひっとらえろ」

2026年1月2日

ゲーム　古代祐三の「Earthion」

ゲームとゲームミュージックの話題です。

2025年7月にセガ メガドライブ向けに今の時代に発売された「Earthion」（アーシオン）というシューティングゲーム。

▼プレイ中のスクリーンショット

30年くらい前、日本ファルコムでゲームの BGM（ゲームミュージック）を作曲していた古代祐三氏。

2年ほどアルバイトで在籍したのち、フリーランスとして独立、そして株式会社エインシャントを設立しました。

そのエインシャントが開発した最も新しいゲームが「Earthion」（アーシオン）です。

古代祐三氏はゲームミュージック界のレジェンドと呼ばれており、30年前当時から同業者に与えた影響は極めて大きく、"ゲームミュージック作曲家" という職種を世間に認知させた第一人者なんだそうです。

「Earthion」（アーシオン）では同氏が BGM の作曲を手掛けています。

Earthion (Original Soundtrack) （リンクは Apple Music プレビューページへ）

私は昔から FM 音源のゲームミュージックを集めており、今回も「同氏の新作はないか」と探したところ、この「Earthion」（アーシオン）のサウンドトラックが目に入り、購入したわけです。

以下は iTunes に投稿した私のレビューです。

STEAM での「Earthion」ゲーム配信ページはこちら

ページに書かれている「推奨パソコン環境」が、

＞64 ビットプロセッサとオペレーティングシステムが必要です

だけなので、高性能なグラフィックボードなどゲーミングPCは不要ということです。

サウンドトラックは 2,444円、

ゲームは 30%オフで、¥ 2,980→¥ 2,086、

合計4,500円程度のお買い物でした。

2026年1月11日

プログラミング　最近

この記事では一貫して JavaScript の型付き配列の話をしています。

1. 型付き配列 Float32Array は難しそう

2. 型付き配列の文化は C 言語の配列の文化と同じ

3. 型付き配列は freeze() できない

たぶんつまらないと思うので、各項１，２，３のあいだに 2 回、ちょっとだけコーヒーブレイクとして市販ゲームソフトの話をしています。

1. 型付き配列 Float32Array は難しそう

最近は JavaScript というプログラミング言語を使って、ブラウザ上で動く「3DCG による人体描画システム」を作っています。

▼現在は、「物体を常に注視する」、みたいなことをやっています。

3DCG（3次元コンピューターグラフィクス）なのでプログラムの高速動作が重要で、その一環として「型なし」の Array ではなく、「型付き」の Float32Array を使うようにしています。

Float32Array も Array、String、Object と並ぶ、JavaScript の標準の型の一つです。あまり見かけないし、使い方も不明ですけどね。

「配列」というのは、変数が複数、ずらりと連なっており、そのうちの一つを番号で指定して取り出すことができるというものです。

b = a[ 0 ];

とすれば、b には配列 a の 0 番の変数（要素）の値が代入されます。

配列の一つの要素のことを「変数」とはあまり言いませんが、要素と変数は同じかと言ったらメモリ上での様子を考えるとたぶんまったく同じです。

ここでは分かりやすくするために配列の一つの要素のことを「変数（要素）」と書きます。

ところで、JavaScript の「変数」には数値とか文字列とかいろいろな種類の値を入れられます。

数値型の変数とか、文字列型の変数とか、変数には「型」というのがそれぞれ決まっています。

（通常、JavaScript ではその辺の型のことをあまり気にしなくても変数は使えます）

よく使う通常の Array である、「型なし配列」とは、１つ１つの変数（要素）について、型はバラバラでいいですよ、というもので、

たとえば１つの配列の中に 6 個の変数（要素）が並んでいて、数値、文字列、真偽値など混在していると、

こんな様子になります。

そしてメモリ上では横一列に並ぶので、

こんな感じになります。

JavaScript ではこれで普通です。

いっぽう、Float32Array などの「型付き配列」とは、すべての変数の型があらかじめ決められているもので、

たとえば、１つの配列の中に 6 個の変数（要素）が並ぶ場合は、

こんな様子になります。

メモリ上では横一列に並ぶので、

こんな感じになります。

まぁ、人間の感覚としてこれまで仕事をいっぱいやってきた、または学校でいろいろ学んできた皆さんにとっても、どちらのほうが作業が早く済みそうか分かると思います。

当然、数値なら数値と、数値だけが並ぶ「型付き配列」のほうがプログラムの高速動作のためには有利なんです。

対する「型なし配列」では、型がバラバラなので、１つを読み取るために、

• 「先頭から見てどの位置にあるのか？」
• 「どれくらいの長さなのか？」

をいちいち調べなくてはなりません。

その点、変数（要素）が等間隔（等幅）に並ぶ「型付き配列」では、たとえば 3 番目なら、「幅 * 3」で位置が分かるし、長さも「幅」だけの長さがある、と最初から分かるので高速なんです。

…で、何の話だっけ、、？（最近ちょっといろいろ忘れますんで）

JavaScript の Array という配列はなじみ深いですが、Array は「型なし」でいろいろ入るタイプなので、3DCG という高度なプログラムから見ると処理が遅いんですよね。

それで Float32Array という型付きの配列を使うことにしています。（正確には使い始めました）

Float32Array の１つ１つの変数（要素）は Float 型（浮動小数点型）であり、データの大きさは 32 ビット（４バイト）、と名前の通り決まっています。

他に、Float64Array とか Int8Array とかもあるようですが、JavaScript の「数値型」はもともと、、、

…64ビット。64ビット？（今調べた）

＞JavaScript では、数値はすべて 64 ビット倍精度浮動小数点数形式である IEEE 754 にしたがって実装されています。

mdn「数値と文字列」 - 数値より

「～もともと 32 ビットの数値を使っているから同じ 32 ビットの Float32Array を選んだんだぜ？」

という話の流れにしたかったのに。。。

たしか、型付きにさえすればいい、という頭だったので、すぐに目に入った Float32Array を手に取った、って感じだったのかな。

ビット数の違いまではその時は気にしてなかったんですね。

うーん、もう仕事で疲れたよ、、って言ってもしょうがないんだけど…

通常の数値を型付き配列に代入したとき、

このように a 配列への代入（32 対 64）と、b 配列への代入（64 対 64）とでどっちのほうが早いのかな？？

a 配列への代入では

数値データである 123 は JavaScript 標準 64 ビットの Float 型（浮動小数点型）であり、

a 配列は 32 ビットの Float 型（浮動小数点型）なので

64 -> 32 の変換が必ず入るはずです。

CPU の中にあるコプロセッサである FPU （Floating-point Processing Unit/Floating-Point Unit）の中でそれをやるはずです。

「コプロセッサ」のコと、AI の「コパイロット」のコは、英語で Co- であり、副とか補助とかの意味があるそうです。

b 配列への代入では

数値データである 123 は JavaScript 標準 64 ビットの Float 型（浮動小数点型）であり、

b 配列は 64 ビットの Float 型（浮動小数点型）で同じなので

変換はいらないはずです。

同じ形式ならば同じ数字（データ）の並びになっているはずで、それを FPU に渡しても「いったい何をするのか」という話になるので、何もしないはずです。

FPU に何かを頼む必要はなく、単に代入処理をするだけのはず。

だから JavaScript で高速化が必要なら、

1. 型付き配列を選ぶ
2. そして、Float64Array を選ぶ

ということになると思うんだけど、、

だとすれば、Float32Array とか Int8Array とかが存在する理由ってなんだろう、、となります。

JavaScript 以外の場所からデータを持ってくるときとか、メモリの節約とか、その辺の理由でしょうか。

とにかく Float64Array を使うよう変更することにします。

コーヒーブレイク１：

2. 型付き配列の文化は C 言語の配列の文化と同じ

題名↑を読んだだけで何を言いたいのか予想がつく人も多いと思いますが、

a = new Float64Array( 3 );

とやると、型付き配列 a を作成できます。要素数は３つ。

そして

このようにするのは当然何も問題ないんですが、

当初の「3つ」という範囲（要素数）を越えて、4 個目を代入してみると、

alert() で数値を表示させると、代入したはずの 1 ではなく undefined となってしまいます。

いろいろ調べたところ、

＞・範囲外のインデックスにアクセスすると、常に undefined が返され、オブジェクト上のプロパティに実際にアクセスすることなく、返値においてそのプロパティがアクセスされたかのように見せかけることができます。

＞・そのような範囲外のプロパティに書き込もうとする試みは、何の効果も持ちません。エラーは発生しませんが、バッファーや型付き配列も変更されません。

mdn「JavaScript の型付き配列」- 型付き配列のビューより

「～できます」と良いことのように書いているのが何でなのか分かりませんが（たぶん高速化の話だとは思う）、

書かれている通りエラーを出さず、暗黙に通り過ぎるという結果になります。

これだと、「代入したと思った数値が知らぬ間に破棄されてるので困る」、ということになりそうです。

C 言語と同じように、範囲を越えていないかチェックするような、注意深い扱い方が必要となります。

なお、プログラムの最初に "use strict"; と書いて、厳格モードにすればエラーを出すかなと思いましたが、出しませんでした。

いっぽう、JavaScript の通常の Array だと、ちゃんと数値を代入できます。

これは日ごろから JavaScript を使っている人にとってはいつもの動きです。

a = new Array( 3 );

とやると、JavaScript の型なし配列 a を作成できます。要素数は３つ。

そして、

このようにするのは当然何も問題ありません。

当初の「3つ」という範囲（要素数）を越えて、4 個目を代入してみると、

alert() で数値を表示させると、1 と表示されます。

Array は自動で範囲（要素数）を広げて、代入した数値はちゃんと使える状態となるので困ることはありません。

ただし、内部的に「手厚い便利な何か」をやっている（要素の場所を調べて、長さを調べている、ほか）ので遅いです。

コーヒーブレイク２：

コーヒーブレイクは2回と先に書きましたが、あれはうそです。

次の 3 の最後にももう一回コーヒーブレイクでゲームの話をします。

3. 型付き配列は freeze() できない

自身も要素も変更できない定数の配列

const a = Object.freeze( new Array( 1, 2, 3 ) );

はできますが、

const a = Object.freeze( new Float64Array( [ 1, 2, 3 ] ) );

はできません。エラーとなります。

（ちなみに、両者のコンストラクタの引数の書き方で、Array は引数として初期化要素を書けますが型付き配列ではそれができません。たぶんできないのが正解。new Array( 10 ) としたとき、「１つの初期化要素 10」ではなく、「配列数 10」となるのが、わからんでもないけど変だから。）

エラーメッセージは、

Uncaught TypeError: can't redefine non-configurable property 0

捕捉されない TypeError: 設定不可能なプロパティ 0 を再定義できません

エラーメッセージというのは時に意味が分かりません。

意訳すると、

型付き配列に対する Object.freeze() にて、

その配列の 0 番目を再定義（configurable、writable を false に設定）しようとしたが、0 番目は「設定不可能」だ。

という意味かなと思います。

つまり、型付き配列は、「ビュー」と「バッファー」に分かれており、ここで freeze() しようとしたのはビューの方。

ビューはいわゆるインデックスであり、実体はバッファーにある。

このような形になるんですね。

変数 a に new Float64Array( 3 ) を代入して、a を操作しているとき、それは a という「ビュー」を使っているんですね。

ビューは複数作成し、それら複数のビューが１つのバッファーを操作することができる。

仮に１つのビューを freeze() したら、そのときバッファーも操作できないように変更不可にならなければならないはずです。

a[ 0 ] = 123; としたとき、freeze されているので変更できません、というエラーが出るはずで、

そのとき変数（要素）の本体であるバッファーも変更されないはずなんですね。

freeze() とはそういう動きを期待するものですからね。

しかし図の通り、ビューは他にも作成可能で、freeze() していないビューでバッファーが操作できてしまうと、矛盾が発生します。

だから「そのような設定はできない」と言っている、、、のかな？

その点、どうして freeze できないのかと調べましたが、

＞・型付き配列の添字は、構成可能なように、また書き込み可能なように見えますが、その属性を変更しようとする試みはすべて失敗します。

mdn「JavaScript の型付き配列」- 型付き配列のビューより

やはり意味の分からない文章で翻訳者は外国の人なのかと思いましたが、、

添え字が構成可能、添え字が書き込み可能、、添え字が？って感じなんですけど、、。

私も日本語は日本人でありながらあまり得意ではないので人のことは言えないけど、、。

Object.freeze() によって、型付き配列の各変数（要素）について configurable = false; writable = false; のような属性変更はできませんよ、と言っているのだと思います。

直接、上図で説明したような理由でできません、という記述は見つかりませんでしたが、とにかく型付き配列の freeze() はできない、というお話でした。

ちなみに、a.buffer を freeze() したらどうかと思ってやってみましたが、a.buffer は実際のバッファ（メモリ）を管理するラッパーであり、実際のバッファ（メモリ）そのものを freeze() はできないんですね。

a = new Float64Array( 3 ); で作成した a で、a[ 0 ] とやってアクセスするときは、どうやら直接メモリを見に行っているみたいで、freeze() した a.buffer は経由しないようです。

a.buffer.b = 123; のように新しいプロパティを作成しようとしたらエラーは出ました。

もうひとつちなみに、型なし配列 Array で freeze() する例です。

"use strict"; のときは 123 の代入の行でエラーとなり、"use strict";をコメントアウトすると、「暗黙、無効」という結果になります。

ももっもうひとつちなみに、

なんで型なしの定数配列が必要だったのかと言うと、3DCG のプログラムでは

[ 0, 0, 0 ] とか、[ 1, 0, 0 ]、[ 0, 1, 0 ]、[ 0, 0, 1 ]、[ -1, 0, 0 ] ... のような決まった配列を何度も使うんですね。

これらは面が向いている方向を示したり、回転の軸を示したりします。

計算の高速化を考えると、これらは、

new Float64Array ( [ 0, 0, 0 ] ) 、new Float64Array ( [ 1, 0, 0 ] ) 、と書かなければなりません。

でも毎回そのように書くのはその配列の生成に時間がかかるので、あらかじめ作っておく、、また、何度も使うなら代入不可にしないといけない、だから定数にしよう…と考えたわけです。それで、

const ZZZ = Object.freeze( new Float64Array ( [ 0, 0, 0 ] ) );

とスクリプトの頭に書いたらエラーした、なんでだ、というわけでした。

ビュー、バッファーというしくみがあるので、凍結できない（←現状個人的見解です）ということでした。

妥協策は、「あらかじめ const で作っておき、要素は変更しないように気を付ける」となっています。

コーヒーブレイク３：

プログラミング　最近２

プログラムの処理の高速化のために、

• 関数呼び出しをしないで、その関数の内容をそこに展開する。（インライン展開）
  → 関数呼び出しは CPU の中をリセットするような動きをするから。
  　
  具体的には、CPU が現在使用中の全レジスタ（CPU直属の高速メモリ、数バイト）の情報をスタック（スタックと名付けたメインメモリの一部分）に退避し、現在実行中のプログラムの位置を示す「プログラムカウンタ」も場所を覚えておき、CPU 内をほとんどまっさらにして（リセット）、それから関数プログラムの場所（関数が置いてあるメモリの場所）を新しいプログラムの場所として読み始め実行開始します。
  それは時間のかかる手続きであり、C 言語などでもコンパイルの際に最適化（高速化）の一環として行われます。
• 型なし配列を使わないで、型付き配列を使う。
  → 型なし配列はアクセスに時間がかかるから。
• 名前配列は使わない。
  → 名前で配列要素を検索する（「名前→番地の早見表」(ハッシュテーブル、ルックアップテーブル) を参照してから飛ぶ）よりは、数値を使って「メモリの何番地先」で飛ぶほうが早いから。

それでどれくらい速くなったのかは、その施工を行う前と後とで、それぞれで「プロファイラ」（デバッガに並ぶプログラミングツール）を使って処理にかかっっている時間を計測しないと分からないんですけど、施工を行う前の状態を用意するのが簡単じゃない気がします。

▼上記高速化の施工を行っての動きだけど、違いが分からない…

青い立方体は地面に静止している状態で、赤い立方体は上下運動しています。

カメラは赤い立方体を周回するように動いています。

また、カメラは赤い立方体を注視するよう設定されているので、周回上のどこにいても赤い立方体を見つめ、見上げる動きを繰り返しています。

回っている小さなオレンジ色の●はカメラの位置を模式的に示したもので、赤い立方体を示す●と青い立方体を示す●は赤い立方体の向こう側に透けて見えています。そのあいだに 2D の原点を示す小さな ■ が見えています。

つまりそれらは上面図であり、状況を 2 次元的にデバッグとして表示しているものです。

オレンジ色の●についている黒い・はカメラの向いている方向を示しており、常に注視先の赤い立方体の●の方向を示しています。

こういうデバッグ表示を行わないと、自分の 3DCG 計算がどんな結果を出しているかがなかなか分からないんですね。

動画を見ると、「たいへん難しい数学に満ちたプログラムではないのか」と思えると思いますが、私が学んだ数学はほとんど中学校数学までで、高校は中退してしまったので、高校数学はちょっとかじっただけです。

私は中学校の教科の中では数学が一番得意で、方程式や図形の計算はわりと意欲的に取り組んでいたと思います。

言いたいのはこれらのプログラムは上級ではなく「中級」であり、中学校数学が分かる人であれば 3DCG プログラミングはできるので、そんなに雲の上の話をしているわけではない、ということです。

ただし、3DCG プログラミングには私が提唱する「原理を用いた方法」と一般的な「行列を用いた方法」の 2 種類があり、ここで言っている 3DCG プログラミングとは行列を全く使わない「原理を用いた方法」です。

世間で説明されている 3DCG は、私が見たところ、9 割が「行列を用いた方法」であり、「原理を用いた方法」は 1 割くらいしか見かけません。

1 割とは言え、3DCG の計算の「原理」であり、「行列を用いた方法」でもその原理計算は見え隠れしていると思います。

原理部分で同じなので「原理を用いた方法」と「行列を用いた方法」の両者は、計算方法は違っていても、計算結果である 3DCG の画面は同じものを出力します。

「原理を用いた方法」の詳しい説明は、このページの上のほうの「Special Documents」のコーナーで「3DCGプログラミングの方法」というリンクを貼ってあるので、できるならやりたい、という方は開いてみてください。

動画を再生すると最初にポーンと音がしますが、動画撮影を始めたときに私のパソコンのセキュリティソフトが「何かのソフトがマイクにアクセスしてます」という警告が表示し、そのときの音を拾ってしまった、というものです。