詳細は Zenn をどうぞ:
リサーチ

詳細は Zenn をどうぞ:
https://zenn.dev/shinta0806/articles/hevc-support
2019 年に購入した現行パソコンも十分な性能を持っているものの、次は AI / VR ready PC にしたいな、ということで、次をイメージしてみる。来年くらいに買えたらいいな。
本体
パーツ | 型番 | 想定価格(税込) |
---|---|---|
名称 | 次期メインマシンイメージ(2024/06) | 360,000 円 |
マザーボード | ASUS | 20,000 円 |
CPU | Intel Arrow Lake | 50,000 円 |
GPU | GeForce RTX 4070 Ti SUPER 16GB | 140,000 円 |
メモリ | 128GB | 50,000 円 |
システム SSD | NVMe PCIe 4.0 7,000MB/s 級 1TB | 10,000 円 |
データ SSD | SATA 8TB (4TB × 2) | 60,000 円 |
光学ドライブ | 現行 PC 流用 | 0 円 |
ケース | 未選定 | 15,000 円 |
電源 | 未選定 | 15,000 円 |
CPU:長らく停滞していた Intel が再起動したので、Intel 製 CPU にしようかな。とはいえ、ノート PC 向け Core Ultra (Meteor Lake) は面白いものの、デスクトップ向け (Arrow Lake) はどうなるか不透明。
GPU:今までは消費電力の低いものを選んでいたが、今回はそうもいかない。AI モデル格納用に VRAM は多めが良いが、4060 Ti 16GB は性能が微妙らしいので、1 つ上で。
メモリ:VRAM に格納できないモデルデータをメインメモリに置けるようになってきているので、メインメモリは多めに。
価格がかなり高くなってしまうので、GPU を格下げして、データ SSD も現行 PC 流用するなどして、25 万円くらいまで抑える必要があるかもしれない。
周辺機器として VR 機器も必要だし……。
WinUI 3(Windows App SDK)公式 issue のうち、気になる issue のメモ(随時更新)。
未解決
- ComboBox が enum で動かない 2021/01/04
- ComboBox が enum で動かない(包括) 2023/03/30
- Ctrl+S で FilePicker を開くとキー入力を受け付けない 2024/03/03(自分)
- FileSavePicker.FileTypeChoices.Add() で実行時例外 2024/09/24
- 管理者権限で実行すると FilePicker が開かない 2022/05/13
- 管理者権限で実行するとドラッグ&ドロップできない 2022/09/06
- 非管理者の時だけ Microsoft Store アプリで昇格できない 2024/04/24(自分)
- TabItemTemplate の挙動が変 2023/06/03(自分)
- ItemsView 例外 2023/08/31
- XAML でジェネリックを使いたい 2019/07/23
- SetPresenter() でウィンドウが変になる 2025/04/12(自分)
解決済
- サブメニューが更新されない 2019/11/21
- WinForms と共存できない 2022/12/04(自分)
- AccessKey で落ちる 2023/07/15(自分)
- RelativePanel の中で Button が広がらない 2024/05/07(自分)
- 複数回 Name に x:Bind するとビルドできない 2024/05/17(自分)
プレビュー速度
プレビュー 1 フレーム当たりの処理に要する時間の比較です(1 スレッドの場合)。
ニコカラメーカー 2 | ニコカラメーカー 3 | 速度向上率 |
---|---|---|
15.68 ms | 8.07 ms | 94% up |
MP4 出力速度
MP4 動画出力に要する時間の比較です。
ニコカラメーカー 2 には MP4 出力機能はないので、無圧縮 AVI で出力し、HandBrake でエンコードしています。
ニコカラメーカー 3 は直接 MP4 出力しています。
いずれも、H.264 (AVC) CRF 18 でエンコードしています。
ニコカラメーカー 2 | ニコカラメーカー 3 | 速度向上率 |
---|---|---|
無圧縮 AVI 出力:0 分 39 秒 MP4 エンコード:0 分 23 秒 合計:1 分 2 秒 | 0 分 36 秒 | 75% up |
無圧縮 AVI 出力速度
無圧縮 AVI 動画出力に要する時間の比較です。
ニコカラメーカー 2 | ニコカラメーカー 3 | 速度向上率 |
---|---|---|
0 分 39 秒 | 0 分 31 秒 | 26% up |
まとめ
ニコカラメーカー 3 は様々な場面で処理速度が向上しており、効率的にカラオケ字幕付き動画を作成できるようになります。
補足
- 測定は開発者環境で行っています。
- 素材動画は 1 分 00 秒、FHD、30 fps です。
- ニコカラメーカー 2 には処理速度測定機能がないため、ニコカラメーカー 3 でニコカラメーカー 2 Ver 13.00 相当の処理を再現した上で測定しています。このため、厳密にはニコカラメーカー 2 の速度ではなく、参考数値となります。
- ニコカラメーカー 3 は Ver 1.01 相当の処理速度計測用開発バージョンを使用しています。
みなさんのカラオケ字幕動画(ニコカラ)作成環境(パソコン性能など)について、アンケートに回答いただきありがとうございます。
現時点でいただいた 50 件の回答について、特徴的なところをご紹介したいと思います。
PC 本体について
デスクトップ or ノート
日本の PC 出荷台数(2022 年)を見てみると 8 割以上がノートなので、今回の結果は真逆です。
動画を扱うクリエイティブ領域ではデスクトップが便利だということかと思います。
PC メーカー
メーカー製では僅差でサードウェーブ(ドスパラ)がトップ、続いて DELL とマウスコンピューターでした。
メモリ容量

ちなみに私も、主に開発がやりやすいという理由でメモリは 32 GB にしています。
しかし、こんなことになるなら「32 GB」と「64 GB 以上」で選択肢を分けておいた方が良かったですね……。
動画出力先ディスク
恐らく C ドライブは SSD の方も多いのではないかと想像していますが、動画出力用ともなると大容量が必要になりますので、HDD の出番ということなのでしょう。
HDD に無圧縮 AVI を出力するのはかなり時間がかかりますので、ニコカラメーカー 3 では是非とも MP4 出力を実装したいと改めて思いました。
ソフトウェアについて
OS
ただ、マルチディスプレイをお使いの方は Windows 11 にアップグレードしたほうが便利なのではと思います。Windows 11 の場合、ディスプレイのみ電源 OFF にしたり一時的に切り離したりした後、マルチディスプレイに復活させた際、アプリのウィンドウ位置が自動的に復元されます。私の環境では、ということなので、全部の環境でそうなるのかは分かりませんが。
字幕作成アプリ
その他、初代ニコカラメーカー、Aegisub などです(txt2ass と Aegisub を併用されている方は Aegisub でカウントしました)。
パート分け表示用アイコン作成アプリ
過半数の方はパート分けアイコンを作成しないということでした。
作成される方のアプリは様々で、特にこれが人気というのはなかったのですが、ペイントや Office などのプリインストールアプリで作成されている方もいらっしゃいました。
歌詞ファイルは
<M>[00:03:00]あいうえお[00:09:00] @Emoji=<M>,ミク.png
のように、アイコンを入れたい箇所に目印(この例では"<M>")を入れ、@Emoji タグで目印に画像ファイルを割り当てます。
パート分けアイコンを付けることで、歌詞の色分けを自動的に行うことも可能となり、ニコカラメーカー 2 での作業が楽になります。詳しくはニコカラメーカー 2 ヘルプをご覧ください。
(追記)本記事公開後のアンケート回答にて、匿名で「動画について指摘するのとコキおろすのは違うと思いますよ?」とのご意見をいただきました。匿名のため詳細は不明ですが、もし、パート分けアイコン動画について知らないことをコキおろしていると誤解させてしまったのだとすれば申し訳ありませんでしたが、パート分けアイコンについて記載したのは情報提供のためで、コキおろす意図は無いことを申し添えておきます。なお、今後は連絡先未記載回答へのご案内は差し控えさせていただきます。
その他
ニコカラメーカー 3 へのリクエスト
たくさんのリクエストをいただきありがとうございました。とても参考になります。
やはり MP4 出力のリクエストは多く、是非とも実装したいと思っています。
ニコカラメーカー 2 で既に実現している機能をお書きいただいた方も複数いらっしゃいました。今回のアンケートでは、9 割の方は連絡先を書いてくださっていたので、その方々には個別にやり方をご連絡いたしました。
エピソード
歌えて良かった、本家様から反応をいただけた等、何かしらの反応をいただいたというお声が比較的多かったように思います。やはりそういうのがあると作って良かったと思えますよね。
中には、ニコカラ作りがきっかけでお付き合いが始まったり、ゴールインされたかたもいらっしゃって、末永くお幸せに。
なお、アンケート回答は引き続き募集しております。ニコカラを作成されている方でご回答がまだの方は、是非ご協力よろしくお願いします。

CrystalDiskInfo によれば、搭載されている SSD は Intel(現ソリダイム)SSDPEKNU512GZ。製品名的には 670p に該当。
M.2 NVMe PCIe 3.0 x 4、QLC。
- シーケンシャルリード:3,059 MB/s
- シーケンシャルライト:1,651 MB/s
- ランダムリード:47 MB/s
- ランダムライト:84 MB/s
となった。
メインマシンの SSD も PCIe 3.0 だが、それと比べると特にライトが遅く、シーケンシャルライトは△34% の性能悪化、ランダムライトに至っては△61% と半分以下の性能である。
とはいえ、モバイルノートとして出先で使う分には十分すぎる性能。
日本製のノーパソ(というのも今や少ないが)はアプリがわんさかインストールされているなどと批判が多いが、海外のものも、アプリという目に見える形ではなく、むしろステルスでいろいろインストールされているようだ。
購入価格はお正月特価で 99,800 円。
パーツ | 型番 |
---|---|
名称 | ASUS Vivobook 14 (M1402IA-EK127WS) |
ディスプレイ | 14.0 型液晶(ノングレア、TFT、タッチパネル非対応) 1920 x 1080(フル HD) |
CPU | AMD Ryzen 5 4600H (Renoir) (6 コア 12 スレッド、基本クロック 3.0 GHz(ブースト 4.0 GHz)、cTDP 35W、7nm プロセス) |
メモリ | 8GB (DDR4-3200?(PC4-25600?)、8GB x 1) |
SSD | 512GB (Intel (Solidigm) 670p SSDPEKNU512GZ M.2 NVMe PCIe 3.0、QLC) |
光学ドライブ | なし |
ビデオカード | オンボード (Radeon RX Vega 6) |
サウンドカード | オンボード |
有線 LAN | なし |
無線 LAN | IEEE802.11ax/ac/a/b/g/n 準拠 (Wi-Fi 6 2x2、最大 1.2 Gbps?) |
Bluetooth | Bluetooth 5.1? 5? |
WAN | なし |
インカメラ | 720p |
外部インターフェース | HDMI 1.4 x 1 USB 2.0 x 1(本体左側) USB 3.2 Gen1 Type-A x 2(本体右側) USB 3.2 Gen1 Type-C x 1 マイク・ヘッドフォン出力端子 電源入力 |
バッテリー | 約 9.4 時間駆動 |
質量 | 本体 1.5kg + AC アダプタ |
OS | Windows 11 Home |
Office | Microsoft Office Home & Business 2021 |
ASUS 公式サイトに正確なスペック情報が記載されていないのが驚きだが、型番のうち M1402IA までのスペックシートはある。並列記載ばかりであまり役に立たないが……。
Vivobook 14 の第 2 世代の何か、ということなのかもしれない。
詳細なスペックはヨドバシのサイトに記載がある。さすがヨドバシ。

MS Office 込みでこの価格。Office 単体だと定価 38,284 円だが、PC とセットだとだいたい 3 万円くらいなので、Office なし版がもしあるとすれば本体価格は 7 万円くらいだろうか。
本当は防水ノート PC が欲しかったのだが、これといったのが見当たらなかったので、防水は諦めて適当なのを買った感じ。AC アダプタ込みで恐らく 1.8kg くらいある(物理的に)重いノート PC だが、この価格で普通に使えるモバイル(?)パソコンとしては悪くない選択肢だと思う。
防水で LTE 付きの良い感じのパソコンなり Windows タブレットなりが登場したら買い直したい。
使い勝手
逆にしたい場合は、MyASUS アプリ(ユーザー登録を促されるが未登録でも使える)の「カスタマイゼーション」のところで変更できる。
はじめに
C# では、WinForms(フォーム)や WPF なら、ウィンドウプロシージャーをカスタムする仕組みが用意されている(HwndSource)ので簡単なのですが、WinUI 3(Windows App SDK)には残念ながら今のところそのような仕組みはないようです。
結局ネイティブ Windows API を使うしかないようですので、その方法をまとめました。Windows API なので WinUI 3 専用ではありませんが、出番としては WinUI 3 で開発するときくらいかと思います。
はやいとこ WinUI 3 にも簡単な仕組みが用意されることを祈っています……。
サンプルプログラムのソースコードは GitHub に上げてあります。
使用する API
旧バージョンでは SetWindowLong() or SetWindowLongPtr() と CallWindowProc() を使います。欠点は先のドキュメントにいろいろ書いてありますが、個人的にはそれよりも、元のウィンドウプロシージャーを自前で管理する分、手間が増えるのかなと思います。
新バージョンでは SetWindowSubclass() と DefSubclassProc() を使用します。元のウィンドウプロシージャーは気にしなくて済みます。
ここでは新バージョンを使います。
というか、新バージョンの情報が少なくて苦労したというのもあってここにまとめたというのもあります。
やりかた
ウィンドウメッセージを扱うので、NuGet で PInvoke.User32 を入れておきます。
カスタムウィンドウプロシージャーの型(SUBCLASSPROC コールバック関数)をデリゲートとして宣言しておきます。型の詳細はこちらに書いてあります。
internal delegate IntPtr SubclassProc(IntPtr hWnd, User32.WindowMessage msg, IntPtr wPalam, IntPtr lParam, IntPtr idSubclass, IntPtr refData);
カスタムウィンドウプロシージャーを作成します。
自分が処理したいメッセージの部分だけ書いて、あとは元のウィンドウプロシージャーに丸投げします。
private IntPtr CustomSubclassProc(IntPtr hWnd, User32.WindowMessage msg, IntPtr wPalam, IntPtr lParam, IntPtr idSubclass, IntPtr refData)
{
switch (msg)
{
case User32.WindowMessage.WM_HogeHoge:
(処理)
return IntPtr.Zero;
default:
// 関心のあるメッセージ以外は次のウィンドウプロシージャーにお任せ
return DefSubclassProc(hWnd, msg, wPalam, lParam);
}
}
カスタムウィンドウプロシージャーを登録します。
_subclassProc = new SubclassProc(CustomSubclassProc);
SetWindowSubclass(hWnd, _subclassProc, IntPtr.Zero, IntPtr.Zero);
注意点の 1 つめは、SetWindowSubclass() に渡すのはカスタムウィンドウプロシージャー本体を「インスタンス化」したもの、ということです。インスタンス化していない CustomSubclassProc も SetWindowSubclass() に渡せてしまいますが罠です。
注意点の 2 つめは、そのインスタンスをずっと(カスタムウィンドウプロシージャーが不要となるまで)持ち続ける、ということです。
これらを守らないと、特に 64 ビットバイナリ(x64)において、一見うまく動くようですが、メッセージ処理をこなしているうちにアプリが強制終了します。私はこれでハマりました。

強制終了時は集約エラーハンドラーにすら引っかかりませんでした。デバッガーでは以下の箇所で落ちていました。
global::Microsoft.UI.Xaml.Application.Start((p) => {
var context = new global::Microsoft.UI.Dispatching.DispatcherQueueSynchronizationContext(global::Microsoft.UI.Dispatching.DispatcherQueue.GetForCurrentThread());
global::System.Threading.SynchronizationContext.SetSynchronizationContext(context);
new App();
});
サンプルプログラム

このコンテキストヘルプは WinUI 3 標準ではハンドルできないため、カスタムウィンドウプロシージャーで処理しています。
ヘルプボタンをクリックする度に、ウィンドウのサイズが変化します(アプリとしてはありえない動きですが……)。
ちなみに、SetWindowSubclass() にインスタンス化していない CustomSubclassProc を直接渡すようにコードを変更すると、うちの環境で x64 バイナリを実行すると、チェックボックス連打で 1 分もしないうちにアプリが落ちました。
【追記】
Zenn をはじめてみました。試しにこの記事を Zenn に再掲してみました。
アーキテクチャー的に? 構造的に? 階層的に? WinUI 3 がどのへんにいるのかがよく分からないので、調べてみた。
※情報をご存じの方はご教示いただけると幸いです!
今のところの想像はこんな感じ。

以下元ネタ。
- Windows App SDK の Windows UI ライブラリ(WinUI 3 はネイティブ UI プラットフォーム コンポーネント)
- WinUI 3 と WinUI 2 の比較(WinUI 3 は Windows App SDK の一部、WinUI 2 は Windows SDK の一部)
- Windows App SDK(Windows App SDK は Windows SDK / フォームや WPF を含む .NET / C++ Win32 を置き換えるものではなく、補完するもの)
- .NET MAUI とは
- .NET Framework 3.0 の構成の図
まだまだ先の話だけど、ニコカラメーカー 3 はこんな感じにしたいかも、というのを。
mp4 出力
AVI と連番 PNG に加え、MP4 も出力できるようにしたい。映像は H.264 (AVC) と H.265 (HEVC) の両方に対応できればベター。
基礎実験はうまくいったので、研究を重ねていけば実現できる……かもしれない。
さらなるマルチスレッド化
ニコカラメーカー 2 は字幕処理をマルチスレッドで高速化しているが、最大 8 スレッドまでしか対応していない。Ryzen 9 5950X が 32 スレッドの時代、より多くのスレッドに対応したい。
とはいえ、実現の目処はまったく立っていない。まぁ、字幕処理 8 スレッド、mp4 エンコードで残りのスレッド、という分担でも悪くはないのかもしれない。
ハードウェアブラー
ニコカラメーカー 2 ではブラー処理が遅い気がしていて、ソフトウェアでブラー処理されている気がしなくもない(未確認)。ハードウェアで処理できれば速くなるのではないか。
Fluent UI
ニコカラメーカー 2 は UI にマテリアルデザインを採用しているが、時代は進み、Fluent UI の時代になりつつあるかもしれない。
とはいえ Fluent UI は発展途上なので、いつまともに使えるようになるのかは不明。
動画(の映像部分)をエンコードする際、「1-pass」「2-pass」「VBR」「CRF」などいくつかのモードを選べますが、どれを選べばいいのでしょうか?
Understanding Rate Control Modes (x264, x265, vpx)(英語記事)によれば、使用目的によって選ぶべきモードが異なり、
- 保存用(HDD・SSD から再生する動画)……CRF でエンコード
- ストリーミング(YouTube・ニコニコ動画などのサーバー側)……2-pass VBR 等でエンコード
とのことです。
YouTube などにアップロードする際はサーバー側で再エンコードされますので、アップロード前の動画は CRF でエンコードしてあっても問題なく、結局のところ、個人でエンコードする場合はすべて CRF でエンコードすれば問題ないでしょう。
英語記事にはその他のモードについても解説されていますので、詳しく知りたい方はどうぞ。
本記事では、保存用に動画をエンコードする場合として、CRF に焦点を当てます。
目次
CRF とは?
CRF(Constant Rate Factor:固定品質)を聞き慣れない方もいらっしゃるかもしれませんが、CRF は「映像を一定のきれいさでエンコードする」モードです。「とてもきれいにしてね」と言えばどんな動画でもとてもきれいにしてくれますし、「まぁまぁきれいにしてね」と言えばどんな動画でもまぁまぁきれいにしてくれます。
映像をきれいにエンコードするのに必要なビットレートは、映像の内容によって異なります。動きの激しい部分、テクスチャーが細かい部分には多くのビットレートが必要です。
CRF は、指定されたきれいさを達成するためにはどのくらいビットレートが必要なのかを自動計算し、激しい部分には多めのビットレート、動きの少ないのほほんとした部分には少なめのビットレートを割り当てます。
裏を返すと、CRF は「どんな動画でも一定のきれいさ」になる反面、「動画によりビットレート(ファイルサイズ)が異なる」ということになります。激しい場面が多い動画はファイルサイズが大きくなり、のほほんとした場面が多い動画はファイルサイズが小さくなります。
CRF と VBR の違い

つまり VBR は「どんな動画でも一定のファイルサイズ」(ある程度の調整が入ることがあります)になる反面、「動画によりきれいさは異なる」ということになります。激しい場面が多い動画は汚くなり、のほほんとした場面が多い動画はきれいになります。
VBR には 1-pass と 2-pass がありますが、1-pass VBR ではビットレートの割り当てが割と適当です。2-pass VBR は動画全体を確認してからビットレートの割り当てを行うので、最適な配分を行うことができます。VBR といえば実際には 2-pass VBR でエンコードすることが多いのではないでしょうか。
CRF と 2-pass VBR では、結果的に平均ビットレートが同程度になった場合、映像のきれいさも同程度になります。
CRF は 1-pass ですので、エンコードに要する時間は 2-pass VBR の半分程度で済みます。
まとめると、保存用動画を CRF でエンコードするメリットは、
- いろんな動画をきれいにエンコードできる
- VBR の半分の時間でエンコードできる
となります。
(補足)たまに 2-pass CRF という表現を見ることがありますが、私はまだそれを知りません。2-pass CRF について詳しい方がいらっしゃいましたら、コメントで教えていただけると助かります。
HandBrake で CRF

HandBrake は本家サイトからダウンロードしてください。サイトは英語ですが、ソフトは日本語対応しています。2022 年 7 月現在の最新バージョンは 1.5.1 です。日本語版というサイトがありますが、日本語版はバージョンが古いので注意してください。
インストール後に起動した際、「.NET が見当たらない」的なエラーが表示される場合は、メッセージをクリックすると表示されるサイトから .NET をダウンロードしてインストールします。
必要なのは「.NET Desktop Runtime」です。名前の似ている「.NET Runtime」ではないので注意してください。Desktop の付かないほうをインストールしてもエラーは改善されません。
エクスプローラーから動画をドラッグ&ドロップすれば OK です。
- 動画エンコーダー ➡ H.265 (x265)
- フレームレート ➡ Same as source
- 品質 ➡ 固定品質 24 RF
- 保存先ファイル ➡ 拡張子を mp4 に変更
動画エンコーダーは H.265 の種類がいくつかありますが、特別な理由が無い限り「H.265 (x265)」が良いです。
フレームレートはいじると映像がぼやけたりするので、「Same as source(元動画と同じ)」にします。元動画のフレームレートによって、自動的に固定になったり可変になったりするようです。
CRF(固定品質)は数値できれいさを指定します。0~51 で指定し、「小さい方がきれい」です。H.265 の場合はデフォルトが 28 です。実質的な最小値は 24 で、それよりも小さくしてもファイルサイズが無駄に大きくなるだけとのことです。一般的な人間では見た目的に 24 未満のきれいさを見分けられないということなのでしょう。
個人的には、いくつかの動画できれいさを試した結果、CRF 24 を使用しています。
保存先ファイルで、デフォルトでは拡張子が .m4v になっています。m4v でも問題はありませんが、mp4 のほうが一般的だと思いますので、拡張子は .mp4 にしたほうが良いかと思います。
設定を終えたら「エンコード開始」ボタンをクリックすると、エンコードできます。
(補足)プリセットについて画面下の方にプリセットがあり、HandBrake のデフォルトでは Fast になっています。ここをいじると、エンコードのスピードと画質が変わります。詳しく調べていませんが、HandBrake のデフォルトの Fast か、H.265 のデフォルトの Medium あたりが無難なのではないでしょうか。プリセットの詳細については x265 本家サイト(英語)に説明があります。
TMPGEnc で CRF
有料ソフトの TMPGEnc Video Mastering Works も CRF でエンコードできます。2022 年 7 月現在の最新版は 7 です。
- フォーマット別出力 ➡ MP4 ファイル出力
- 映像ストリーム形式 ➡ H.265/HEVC
- 映像エンコーダー ➡ x265
を指定します。
- フレームレート ➡ (元動画と同じものを指定)
- レート調整モード ➡ VBR(固定品質)
- 品質 ➡ 54
を指定します。
フレームレートはデフォルトで元動画と同じものが指定されているはずですが、念のため確認したほうが良いでしょう。
レート調整モードは「VBR(固定品質)」にします。VBR が 2 種類あるので、間違って平均ビットレートを選ばないように注意しましょう。
品質できれいさを指定します。HandBrake と異なり、「大きいほうがきれい」なので注意が必要です。HandBrake と TMPGEnc の数値の対応は以下の計算式で求められます。
[TMPGEnc 7 品質] = 102 - [HandBrake 品質] × 2[HandBrake 品質] = 51 - [TMPGEnc 7 品質] ÷ 2
HandBrake で 24 に相当するのは TMPGEnc では 54 なので、個人的には 54 を使用しています。
ニコカラメーカー 3 で CRF
カラオケ字幕付き動画作成ソフト「ニコカラメーカー 3」(無料ソフト)も CRF でエンコードします。
ニコカラメーカー 3 はエンコード時に FFmpeg を利用しますので、予め FFmpeg をインストールしたうえで、FFmpeg の場所を指定します。
ニコカラメーカー 3 はエンコード設定をタブごとに複数保持しておくことができ、デフォルトで「高品質」タブが H.265 でのエンコードになっています。
映像エンコードデバイスは「ソフトウェア」のままにしておきます。
映像エンコードデバイスがソフトウェアの場合、「画質」は CRF 画質になります。数値は HandBrake と同じです。個人的には 24 を使用しています。
「出力形式」を MP4 にして、さらに「高画質」を選択すると、先ほど設定した高画質タブの内容でエンコードできます。
おまけ:H.265 と H.264
H.264 でも CRF モードエンコードができますが、数値が異なるので注意してください。
H.265 | H.264 | |
---|---|---|
デフォルト | 28 | 23 |
実質的な最小値 (一番きれいな中でファイルサイズ小) | 24 | 18 |
一般的に、H.265 のほうがきれいでファイルサイズが小さくなりますので、通常は H.265 でエンコードすれば良いかと思います(ニコニコ動画は H.264 のみ対応のため、ニコニコ動画にアップロードする時だけ H.264)。
H.265 のほうが多少エンコードに時間がかかりますが、私の環境で、フル HD 30 fps の 3 分 11 秒の動画を HandBrake でエンコードした場合の所要時間は、
- H.265 CRF 24 ➡ 2 分 06 秒
- H.264 CRF 20 ➡ 1 分 41 秒
となりました。
H.265 のほうが 20% 程度多く時間がかかっていますが、目くじらを立てるほどではないかと思っています。
更新履歴
- 2022/07/24 初版。
- 2022/09/03 .NET Desktop Runtime について記載。
- 2023/05/14 フレームレートについて追記。
- 2024/03/22 ニコカラメーカー 3 について記載。
- 2024/03/22 CRF と VBR の比較図を掲載。
- 2024/10/25 H.265 と H.264 の比較表を掲載。
DirectX や Media Foundation 周りの関係性がいつも分からなくなってしまうので整理して系譜図にまとめた。
メモ
- DirectX には基本ランタイム(Windows プリインストールや Windows Update で入る)と追加ランタイム(Windows 8.x 以降で特定のバージョンがプリインストール)がある。
- DirectX 1.0 は Game SDK として発表された。
- DicrectInput は DirectX 1 から存在していたという記述もあるし、DirectX 3 で統合されたという記述もある。
- DirectX 4 は欠番。
- XACT 終了時の DirectX バージョンは不明だが、Windows 8 で廃止。
- XAudio は Xbox 専用で、PC で使えるのは XAudio2。
- D3D は 11 からビデオ再生ができる。
参考資料
馴染みのグラフィックスソフトがある方はそれを使えばいいのですが、普段グラフィックスソフトを使っていない方はエクセルで飾り枠を作ることもできますので、その作り方を整理してまとめました。
縮小されている画像はクリックで拡大できます。
目次
飾り無し
エクセルによる飾り枠の話の前に、飾り枠無しの状況もまとめておきます。
ニコカラメーカー 2 の @Emoji タグを使う際、NoDecor オプションを付けます。
@Emoji=【飾り無し】,アイコン_飾り無し.png,,NoDecor,MarginRight=7
@Emoji タグの詳細についてはニコカラメーカー 2 のヘルプ「インライングラフィックス」をご覧ください。
ブラー
ニコカラメーカー 2 の @Emoji タグを使う際、NoDecor オプションを付けません。
@Emoji=【ブラー】,アイコン_飾り無し.png,,MarginRight=7
凸枠

まず、少し立体的に盛り上がっているような飾り枠をエクセルで付けるやり方です。
外枠
作成時、必ず「Shift キーを押しながら」ドラッグして作成することにより、縦と横のサイズを同じ(正方形)にします。
ある程度大きめ(ニコカラメーカー 2 のフォントサイズ指定よりも大きめ)のほうが最終的にきれいになります。筆者環境では、エクセルシート 10 行くらいのサイズにすると、最終的なアイコンサイズが 200 ピクセル程度になりました。

線は「線なし」にします。

幅と高さは枠のサイズに合わせますが、枠を 10 行くらいで作成している場合、10 pt 程度で良いかと思います。
背景枠
次に、背景枠を作成します。この作業は、キャラクター画像が透過 PNG になっていて背景色が付いていない場合のみ行います。キャラクター画像に背景色が付いている場合は不要です。
外枠よりも一回り小さい枠にします。
位置合わせがやりづらい場合は、エクセル右下の拡大率をアップさせるとやりやすくなります。また、細かな位置調整はマウスよりもカーソルキーのほうがやりやすいです。
[図形の書式設定 → 図形のオプション → 塗りつぶしと線]で、塗りつぶしの色を指定します。白が使いやすいかと思います。
線は「線なし」にします。
キャラクター枠
[挿入 → 図形 → 四角形]にある「四角形:角を丸くする」で角丸四角形を作成します。今回も Shift キーで正方形にします。
[図形の書式設定 → 図形のオプション → 塗りつぶしと線]で塗りつぶしを「図またはテクスチャ」にして、画像ソースの「挿入する」ボタンをクリックすると、ダイアログが表示されます。「ファイルから」を選び、キャラクター画像を指定すると、角丸四角形がキャラクター画像になります。
個人的には、頭の上に少し余白があるほうが見やすいかなと思います。
画像出力
ここまでできたら、いったんエクセルを(通常の xlsx 形式で)保存します。

通常は、最も番号の大きい画像ファイル(例:image004.png)が凸枠アイコンになっているかと思います。
画像自体に飾り枠が付いているので、@Emoji タグには NoDecor オプションを付け、ニコカラメーカー 2 による飾りは付けないようにします。
また、MarginRight オプションでアイコンと歌詞の間に隙間を多少空けておくと、字幕が読みやすくなると思います。
@Emoji=【凸枠】,アイコン_凸枠.png,,NoDecor,MarginRight=7

半透明ダブル枠

背景枠
最初に、背景枠を作成します。凸枠の時と同様、この作業は、キャラクター画像が透過 PNG になっていて背景色が付いていない場合のみ行います。キャラクター画像に背景色が付いている場合は不要です。
[図形の書式設定 → 図形のオプション → 塗りつぶしと線]で、塗りつぶしの色を指定します。今回はエンジにしてみました。
線は「線なし」にします。
キャラクター枠
背景枠とキャラクター枠はぴったり同じ大きさにしたいので、背景枠をコピー&貼り付けして、新しく同じ大きさの正方形を作成します。
[図形の書式設定 → 図形のオプション → 塗りつぶしと線]で塗りつぶしを「図またはテクスチャ」にして、キャラクター画像を指定します(凸枠の時とやり方は同じです)。
背景枠とキャラクター枠がぴったり重なるように位置を調整します。

背景枠とキャラクター枠がぴったり重なるように位置を調整します。
半透明外枠
[図形の書式設定 → 図形のオプション → 塗りつぶしと線]で、塗りつぶしを「なし」にします。
線を「単色」の「黒」にして、透明度を「50%」にします。
線の幅は適宜調整ですが、背景枠をエクセル 10 行分くらいで作成している場合、「10 pt」程度で良いかと思います。
半透明内枠
半透明内枠は、半透明外枠よりも 1 周り小さくします。
また、線の色は「白」、線の幅は外枠の半分「5 pt」にします。
画像出力
凸枠の時と同様にして PNG 画像を出力します。
背景枠・キャラクター枠・半透明外枠がぴったり重なっていれば PNG 画像は正方形になりますが、微妙にずれていると正方形の画像になりません。多少長方形になるのを許容するのも 1 つの手ですし、気になるようであれば、ペイントなどで正方形に切り取って保存し直しても良いでしょう。
@Emoji=【半透明ダブル枠】,アイコン_半透明ダブル枠.png,,NoDecor,MarginRight=7
A列車で行こう はじまる観光計画(はじまるA列車)(Steam 版)のセーブデータを他のプレイヤーとやり取りするための方法をまとめて整理しました。
シナリオアップロード・ダウンロード機能があるのになぜそんなことをするのかというと、以下のように、はじまるA列車がもっともっと面白くなるのではないかと思うからです。はじまるA列車がさらに盛り上がると楽しいなと思います。
メリット
1. 自分の街を丸ごと紹介できる
自分が作った街を紹介したい時、ニコニコ動画などの動画サイトで紹介するのがメインです。
もちろんこれはこれで楽しくて、誰でも(はじまるA列車を持ってない人でも)手軽に見られるというメリットがあります。
一方で、
- 録画にはハイスペック PC が必要
- 動画編集スキルが必要
- 動画の録画・編集に時間がかかる
- 街の全てを紹介するのは事実上不可能
などのデメリットもあります。
セーブデータ配布は動画作成よりもはるかに簡単ですし、街を丸ごと見てもらうことができます。
動画では紹介しきれなかった細かい部分などを見てもらえて、Twitter などでコメントをもらえたりしたら嬉しいですね。
しかも、これはコンストラクションモードに限らずです。公式シナリオや他のプレイヤーの自作シナリオでの街づくりも紹介できます。
2. 他の人の街づくりを参考にできる
他のプレイヤーが作った街を丸ごと見ることができるので、動画では分からないような細かい工夫や、鉄道や子会社がどのくらい儲かるかなど、より詳細に学ぶことができます。
次回からの自分の街づくりに、大いに参考になるのではないでしょうか。
3. 攻略途中や攻略完了後のデータを披露できる
公式シナリオや、他の人が作成した自作シナリオなどを攻略している途中、あるいは、クリア後のデータを披露することができます。
攻略方法が同じだったとしても、実際の街づくりは他の人とは少しずつ違う形になると思います。そういう部分を比べてみるのも面白いのではないでしょうか。
「もうちょっと早くクリアできたかも」「この部分の街づくりはイマイチだったかなぁ」などの反省ポイントも含めて、お互い切磋琢磨できるかもしれません。
4. チームで自作シナリオを作れる
自作シナリオを作成するには数多くのステップがありますが、その全てが得意な人というのもなかなかいないのではないでしょうか。「会話シーン作るの苦手だから誰か作ってくれないかなぁ」とか。
「街づくり」「列車開発」「会話作成」などのステップを複数名で分担することで、それぞれの得意分野を持ち寄り、ハイクオリティーな自作シナリオを作ることができるかもしれません。
そういうハイクオリティーシナリオがたくさん登場すると、プレイする側も楽しいですね。
……というように、ぱっと思いつくだけでも、セーブデータ配布には多くのメリットがあります。これ以外にも、もっと可能性が広がるのではないでしょうか。
重要な注意事項
Build 30257.629 現在、公式ではセーブデータ配布はサポートされていません。
セーブデータを上書きすることになりますので、最悪の場合、はじまるA列車が起動しなくなるなどのリスクがある恐れがあります。
誰もサポートしてくれませんので、実施する場合は、自己責任で実施してください。
……シナリオアップロード・ダウンロードみたいに、ゲーム内機能でセーブデータのアップロード・ダウンロードできるようにバージョンアップしてくれないかなー(チラッ
セーブデータ配布方法
1. セーブデータ番号確認
確認後、はじまるA列車を終了します。
2. セーブデータコピー
C:\Program Files (x86)\Steam\userdata\数字\1685460\remote
配下に「slotXX」というフォルダー名で保存されています。
先ほど確認したセーブ番号のフォルダー(セーブ番号が 61 なら slot61)を、作業用の適当なフォルダーに丸ごとコピーします。
3. リネーム
コピーした「slotXX」フォルダーの名前を、「slot0」(ゼロ)にリネームします(Steam 配下のフォルダーはいじらずに、コピーしたほうをいじります)。
slot0 はオートセーブ用で、このスロットだとうまく読み込んでくれるのでリネームします。
4. zip 圧縮
5. 配布
zip ファイルを自分のホームページや Dropbox などにアップロードします。
Twitter ハッシュタグ「#はじまるA列車」で URL をつぶやくと見つけてもらいやすくなるのではないでしょうか。
セーブデータ読み込み方法
1. バックアップ
Steam が起動している場合は終了します。
念のため、はじまるA列車のセーブデータを全てバックアップとして取っておきます。
C:\Program Files (x86)\Steam\userdata\数字\1685460\remote
配下のデータをすべて、他の適当なフォルダーにコピーします。
2. ダウンロード
他のプレイヤーが配布してくれているセーブデータをダウンロードします。
zip になっているので、すべて展開すると、slot0 フォルダーがあると思います。
3. セーブデータ入れ替え
C:\Program Files (x86)\Steam\userdata\数字\1685460\remote
の中にある「slot0」フォルダーをフォルダーごと削除し、代わりに、ダウンロードした「slot0」フォルダーを配置します。
4. 読み込み
はじまるA列車を起動します。
起動時、Steam から「クラウドのデータを使うか、ローカルのデータを使うか」聞かれた場合は、必ず「ローカル」を選択してください。
ゲームロード画面で、一番上のオートセーブをロードすると、ダウンロードしたセーブデータをプレイすることができます。
ロード時、サムネイル(スクリーンショット)はセーブデータとは異なったものになっているようです。ロード後、上書き保存することで、サムネイルも正常になるようです。
サンプルセーブデータ

前回、テストプレイを終えてゲームとして成り立っていることを確認できたので、いよいよ公開です。
アップロード
右上のアップロードボタン(上向き矢印のボタン)をクリックすることでアップロードできます。
Steam 版の場合、自作シナリオのアップロードは無料で行えます。Nintendo Switch 版の場合は月額課金が必要なようです。
公開設定
アップロードすると Steam の画面になります。
画面に表示されている注記書きの通り、アップロードしたシナリオはデフォルトでは非公開になっています。つまり、他のプレイヤーからは見えていません。
併せて、「画像&動画の追加/編集」でシナリオのスクリーンショットをアップロードしておくと、他のプレイヤーに内容が伝わりやすくなると思います。
Twitter で自作シナリオ公開報告をする際は、ハッシュタグ「#はじまるA列車」「#はじまるA列車自作シナリオPC」を付けると分かりやすくなると思います。
補足
クリアしたか否かは、「Completion Status」で分かります。
- Scenario Completed on Expert……難易度達人でクリア済
- Scenario Completed on Standard……難易度標準でクリア済
- Scenario Completed on Easy……難易度やさしいでクリア済
- Not Yet Completed……クリアしていない
自分がプレイヤーとして他の人の自作シナリオをダウンロードする際は、「Not Yet Completed」のものはクリアできない可能性があるので注意しましょう。
おしまい
以上で、マップ作成から公開まで、一通り完了しました。
はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)
参考リンク
- 公式ヘルプ
- 公式解説動画(キャラクター呼称表もあり)
- シナリオ台詞スタイルタグ・変数チートシート
- 渓谷の琵城
更新履歴
- 2022/05/05 初版。
- 2022/05/07 シリーズインデックス作成。
前回までで一通りの作成が完了しました。
しかし、それで終わりではありません。
テストプレイで確認すべき項目は大きく分けて 2 つです。
- シナリオパラメータ分岐が意図通りに動作するか(シナリオパラメータを使用している場合)
- クリアできるか
テストプレイ前の確認
テストプレイを始める前に、特に以下をもう一度確認しておくと良いのではないでしょうか。
- 駅や停留所の名前を付け忘れていないか
- 列車やバスがきちんと配置されているか(いつの間にか撤去されている場合があります)
- 余計な子会社が無いか(即時処分し忘れていないか)
- ゲーム設定の基本設定に問題は無いか(社員状況は変動している場合があります)
- 助成金案件、資源売買案件は十分なラインナップがあるか
シナリオ登録
[ゲーム設定]メニューにシナリオ登録があるので、クリックします。
シナリオ登録ボタンが無効化されている場合は、感嘆符の出ている項目が正しく設定されていないので、見直し・修正します。
シナリオ登録は、あくまでもあなたのパソコンでプレイできるようにするためのものであり、まだインターネットには公開されません。
公式シナリオの下側に自作シナリオが並びます。
シナリオパラメータ分岐確認(ノーマル版)
登録した自作シナリオを選択してプレイ開始します。
シナリオパラメータを使用している場合は、街づくりは後回しにして、まずは選択肢に応じた結果になるかを確認します。
原則としては、すべての選択肢のパターンで正常に動作するかを確認することになります。
前回のラーメン屋の例で言うと、ラーメンが好きか嫌いか、ラーメン屋と牛丼屋どちらに行くか、2×2=4 パターンすべてです。質問の数が 3 つ、4 つ、と増えていくと、パターン数は 8、16 と増えていきます。
質問が 4 つで、4 つめの質問がプレイ開始から 2 年後の場合、2 年間の早送りを 16 回することになり、かなり大変です。
主要なパターン(特に、クリア条件を変更するようなパターンでは確認必須)に絞って確認するというのも 1 つの手です。
シナリオパラメータ分岐確認(イベント日付変更版)
2 年間の早送りを 16 回するのは大変でも、4 日間の早送りを 16 回なら現実的です。
というわけで、動作確認用にイベント日付を短期集中型にする「テスト用シナリオ」を作成するという方法もあります。
(プレイ用ではなく)コンストラクションモードのデータを読み込んだ後、「新しく保存」で別データを作り、シナリオ名を「テスト用」などと見分けが付くようにします。
質問と結果発表のイベント条件を、4/1、4/2、4/3……と 1 日ごとに発生するようにします。そのシナリオを登録・プレイすることで、手早く動作確認をすることが可能になります。
注意点としては、
- 新しく保存した別データで日付をいじる
- 間違いが見つかった時は、オリジナルを直した上で、再度新しくテスト用シナリオを作る
が挙げられます。特に、間違いが見つかった時、きちんとオリジナルを直すことと、オリジナルにテスト日付を入れてしまわないように注意が必要です。
コンストラクションモードのゲーム設定画面でシナリオパラメータが記憶されていればこんな面倒は不要なのですが……。
クリアできるかの確認
ゲームとしてクリアできるかを確認します。
登録した自作シナリオを選択し、難易度は達人が望ましいでしょう。
クリアし、シナリオクリアのカップが付与されることを確認します。
次:公開編
はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)
更新履歴
- 2022/05/05 初版。
- 2022/05/07 シリーズインデックス作成。

シナリオ解説
一番上、0 番は「シナリオ解説」となっており、シナリオ選択画面に表示されるシナリオ解説を設定します。

会話シーンの概要
決められた日付(条件は色々な方法で指定できます)になるとキャラクター同士の会話がはじまり、場合によってはプレイヤーに選択肢を出したり、何らかのアクション(資金が減るなど)を起こしたりします。
公式シナリオでは、
- ゲーム開始初日に街を見回ることを促す
- その後数日かけてシナリオの背景や目標などを示す
- 併せて攻略のヒントも示す
- たまにキャラクター同士が雑談などをする
- クリア条件を 1 つ満たす(もしくは目標の半分に達する)ごとに盛り上げる

- ゲーム開始初日:街を見回ることを促す
- 2 日目:シナリオの背景と目標を提示
- 3 日目:攻略の基本方針を提示
- その後 1 年間は月に 1 回程度のペースで
- 琵城小噺集
- 傾国の美女イベント進行
- 攻略のヒント
- 雑談
- 目標半分&全クリ時にコメント
という流れにしています。
編集
文章の中には HTML タグのようなものを埋め込むことができます。例えば、
あいうえお<color=green>かきくけこ</color>
とすると、「かきくけこ」だけ文字が緑色になります。
目標指標(人口 5 万人など)は文字を黄色(color=yellow)、地名は文字を水色(color=#00FFFF)にしておきましょう。
右の図は公式シナリオのセリフですが、そのままでは「鉄道総延長」あたりまでが 1 行目で、「20km」あたりが 2 行目になり、目標指標が行分割されて読みづらくなってしまいます。
1 行目にまだ余裕があるにもかかわらず、「鉄道総延長」の前に改行を入れることで、「鉄道総延長 20km」がまとまって表示され、読みやすくなっています。

「コマンド」で様々なアクションを起こせます。コマンドについては、後ほど説明します。
「コピー」「カット」「貼り付け」で台詞のコピーや順番入れ替えができます。ドラッグ&ドロップでは順番を入れ替えられません。
「セリフ追加」で、現在のセリフの「前」にセリフが追加されます。個人的には、最初にセリフ追加でたくさんセリフ枠を追加しておいて、余ったらカットで削除するのがやりやすいです。
コマンド
コマンドで様々なアクションを起こすことができ、「マップ移動」「資本金増加」などたくさんのコマンドが用意されています。
用意されているコマンドの一覧は公式ヘルプにあります。
ほとんどのシーンで、種類「がんばるぞっ!」の BGM を使うことになるでしょう。
条件
条件ボタンで、どのような時に会話シーンを再生するかを指定できます。
画面下から条件を選びます。条件の一覧は公式ヘルプにあります。
その名の通り、指定した日付(の午前 9 時)になると会話シーンが再生されます。
個人的には、毎月「1 日、15 日、末日」を指定するのはなるべく避ける方が良いかなと思っています。1 日や末日はレポート確認などでプレイヤーが忙しく、15 日は助成金支給日なのでカレンダー上でアイコンが被ってしまいます。
強制発動を「オン」にすると、指定日付(の午前 9 時)に必ず再生されます。「オフ」にすると、指定日付(の午前 9 時)になると画面右上にベルマークが表示され、プレイヤーがベルマークをクリックしたタイミングで再生されます。
プレイヤー側からすると、街づくりしている途中で強制的に会話が始まるのはうざいので、余程の事情が無い限り(そのタイミングで発動しないとシナリオに支障が出る場合など)、強制発動はオフにしておくほうが良いでしょう。
渓谷の琵城では、初日の導入メッセージ以外はすべて強制発動オフにしてあります。
例えば、クリア条件が「年間観光客数 10 万人」だった場合、5 万人になった時点で再生されますので、「残り半分も頑張りましょう」的な会話を入れておくと良いでしょう。
こうすると、単独では再生されない会話シーンになります。
他の会話シーンからコマンド「シーンジャンプ」などでジャンプしてくる場合にこれを使います。
シーン名変更
プレイヤーには表示されないため、シーン名がネタバレになることはありません。自分が分かりやすい名前を付けておきましょう。
再生
会話シーンを作り終えたら、「再生」ボタンをクリックし、きちんと再生できることを確認します。
特に、選択肢コマンドを使った場合は、それぞれの選択肢が正しく動作するかの確認が必要です。
シーンの順番
残念ながら、シーンの順番は入れ替えられません。
シーンを作り込んでいるうちに、順番がばらばらになって分かりづらくなってもどうしようもありません。ドラッグ&ドロップなどで入れ替えられると良かったのですが……。
ストーリー分岐
プレイヤーの選択によってストーリーを分岐させたい場合は、コマンドを利用します。
その場合、必ず使うコマンドは「選択肢」です。
複数の会話シーンでの選択肢を組み合わせて分岐させる場合は「シナリオパラメータ計算」「シナリオパラメータ分岐」コマンドも使います。
場合によっては「シーンジャンプ」も併せて使います。
ストーリー分岐例:ラーメン好き
2 回の質問の結果、ラーメン好きであれば建設資金をもらえることにします。
シナリオパラメータを「ラーメン好き度」とし、初期値を 50 点にします。
【会話シーン 1】
質問 1 つめを行う会話シーンです。
ラーメン好きか、という文章の次に、選択肢コマンドで「はい」「いいえ」を用意します。「はい」の場合はシーン 2 にジャンプするようにします。
「いいえ」が選ばれた場合はシーン 1 の会話が続くので、シナリオパラメータ計算コマンドでシナリオパラメータ(ラーメン好き度)をマイナス 10 します。
【会話シーン 2】
BGM の設定は不要です(シーン 1 で設定した BGM が流れ続けるため)。
シナリオパラメータ計算コマンドでシナリオパラメータ(ラーメン好き度)をプラス 10 します。
【会話シーン 3】
質問 2 つめを行う会話シーンです。
どちらに行くか、という文章の次に、選択肢コマンドで「ラーメン屋」「牛丼屋」を用意します。「ラーメン屋」の場合はシーン 4 にジャンプするようにします。
「牛丼屋」が選ばれた場合はシーン 3 の会話が続くので、シナリオパラメータ計算コマンドでシナリオパラメータ(ラーメン好き度)をマイナス 10 します。
【会話シーン 4】

BGM の設定は不要です(シーン 3 で設定した BGM が流れ続けるため)。
シナリオパラメータ計算コマンドでシナリオパラメータ(ラーメン好き度)をプラス 10 します。
【会話シーン 5】
前の 2 つの質問の結果、ラーメン好きかどうかによって分岐します。
シナリオパラメータ分岐コマンドで、シナリオパラメータ(ラーメン好き度)が 50 より大きい場合はシーン 6 にジャンプします。
50 以下の場合はシーン 5 が続くので、ラーメンはお好きではないようですね、という会話にしておきます。
【会話シーン 6】
BGM の設定は不要です(シーン 5 で設定した BGM が流れ続けるため)。
資金をプレゼントします、という文章の次に、資本金増加コマンドでプラス 10 億円します。実質的に資金が 10 億円増えます。
以上のように、選択肢の度にシナリオパラメータを増減させ、最後にシナリオパラメータ分岐でストーリーを分岐させることができます。
分岐させる前の質問の回数をもっと増やすことは可能ですが、シナリオパラメータの下限値が 0、上限値が 100 であることには注意が必要です。
また、選択肢 1 つごとに 2 つの会話シーンを使います(今回のようなシンプルなケースだとシーン 2 と 4 を統合することも可能ですが)。全部で会話シーンは 40 しか設定できないことにも注意が必要です。
【ストーリー分岐コンストラクションモードデータ】
読み込み方法や注意事項などはこちらの記事をお読み下さい。
- セーブデータ(自己責任でどうぞ)
ストーリー分岐例:フラグ方式
先の例ではシナリオパラメータの大小でストーリーを分岐させました。
大小ではなく、シナリオパラメータをフラグとして使うことで、選択肢の組み合わせによってストーリーを分岐させることもできます。
質問 1 が行き先についての質問で、「北海道 or 九州」とする場合、九州と答えたらフラグをプラス 1 します。
質問 2 が交通手段についての質問で、「新幹線 or 飛行機」とする場合、飛行機と答えたらフラグをプラス 2 します。
すると、最終的にフラグの値が
- 0……北海道へ新幹線で行く
- 1……九州へ新幹線で行く
- 2……北海道へ飛行機で行く
- 3……九州へ飛行機で行く
というように、すべてのパターンを判定できます。
質問が多い場合は、プラスするフラグの値を 1、2、4、8……のように倍々にしていきます。
ただし、質問が多くなってくると、すべてのパターンを判定するには会話シーンが足りなくなってしまいます。実用上は、特定のパターンだけ判定して、残りはその他的な扱いをすることになるでしょう。
渓谷の琵城はフラグ方式で、誰を傾国の美女と思ったかを記録しています。
- 1=観光課長
- 2=証券会社員
- 4=秘書
- 8=都市計画担当
シナリオパラメータ分岐の動作確認
ラーメン屋の例で言えば、会話シーン 1 を再生してラーメン好きを選んだ場合、「ラーメン好き度が上がりました」と表示されるにもかかわらず、実際には上がっておらず、50 点のままです。
そのため、その後会話シーン 5 を再生しても、資金プレゼントには進みません。
ゲーム設定中にシナリオパラメータ分岐の動作確認はできないことになります。ゲーム設定中もシナリオパラメータを実際に増減させてくれると良かったのですが……。
この辺りの対策については、次のテストプレイで説明します。
機能制限
使わせたくない機能をオフにします。
シナリオコマンドの「機能制限」コマンドでオン・オフすることも可能です。
次:テストプレイ編
はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)
更新履歴
- 2022/05/04 初版。
- 2022/05/05 機能制限を記載。
- 2022/05/06 ストーリー分岐セーブデータ公開。

当然ながら、クリア可能になるように条件を設定する必要があります。
指標
「人口」、「年間売上高」、部門別の利益系(「年間鉄道利益」など)、会社格付けなど、さまざまな指標を設定することができます。
条件 1(数値など)
例えば人口なら「人口 10 万人以上」のような設定が可能です。
指標によっては「以上」か「以下」かを選択できるものもあります。
例えば、鉄道総延長は通常は「20km 以上」のように発展させる方向で条件を設定しますが、鉄道に代わる交通手段を育成するシナリオであれば「20km 以下」のような設定をすることもあるかもしれません。
「人口」は「以下」を選択できません。立ち退きシナリオを作りたい場合は、代わりに「住宅経済規模」を用いることになるのではないでしょうか。
指標が「会社格付け」の場合は「AAA」などのランクを設定します。
指標によっては、条件 1 を設定できないものもあります。
条件 2(地域など)
街全体にすることもできますし、特定の地域だけで達成しなければならないようにすることもできます。「品川地域で鉄道総延長 20km 以上」のような設定が可能です。
「駅の年間利用者数」の場合は地域ではなく具体的な駅、「業種別子会社」の場合は業種を設定します。
指標によっては、条件 2 を設定できないものもあります。
期限
有効/無効
削除
間違って作成したクリア条件を削除できます。
次:シナリオ編
はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)
更新履歴
- 2022/05/03 初版。
- 2022/05/07 シリーズインデックス作成。
前回、基本設定のうち、少なくとも取り扱い資源は設定したと思います。
メニューの順番では次は「クリア条件設定」ですが、先に「地域設定」を行います。クリア条件設定に地域が必要になる場合があるためです。
合併
マップサイズにより、最大 16(4×4)の地域があります。シナリオの内容にもよりますが、地域の数が多すぎると分かりづらいので、合併して少数の地域にすることが多いでしょう。
画面左側に地域一覧が並んでいます。例では名前変更済で県内の位置を表す名前にしていますが、デフォルトではランダムで地域の名前が決まっています。
とはいえ、実際には十字型の地域を作りたい場合はあまりないかと思います。
旧「上」で東を合併することにより、「右」も合併されて正方形になります。
かなり使いづらい操作性だと思います。
境界線
合併後、各地域の境界線を設定します。
地図の内側にある交点だけではなく、辺上にある交点も動かせます。
ただし、四隅でも黄色い丸は表示されるものの、四隅は動かせません。
個別設定
「名前変更」で地域の名前を設定できます。地域の規模に応じて「村」「町」などは自動的に付加されるため、それらは付けないでおきます。
ゲーム開始時の用途地域を指定することもできます。永久的にその用途地域にしたい場合は「用途地域固定」をオンにします。
「助成金傾向」でどの助成金を出すか設定します。出したくない助成金がある場合はオフにします。
逆に、なるべく出したい助成金がある場合は、他の助成金をオフにするというのもアリなのではないかと思います。例えば、住宅に集中して出したい場合は、「工業系建物」「商業系建物」「娯楽系建物」をオフにすると、住宅系建物の助成金が出る確率が上がるのではないでしょうか(未検証ですが……)。
隣接地域・海外設定
「名前変更」で隣接地域の名前を設定できます。
「都市規模」で隣接地域の規模を設定できます。隣接していない設定にしたい場合は「なし」を選びます。
「資源の扱い」で隣接都市・海外の資源案件が決まります。例えば、「農産物」を「生産」、「水産物」を「消費」にすると、農産物の購入と水産物の売却ができるようになります。
基本設定でオフにした資源は選択肢に出てきません。
地価補正
マップ全体の基本となる地価を設定します。
発展しやすさ
発展による建物の建ちやすさを設定します。
次:クリア条件設定編
はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)
更新履歴
- 2022/05/01 初版。
- 2022/05/07 シリーズインデックス作成。
前回街づくりを終えたので、いよいよゲーム作りを始めていきます。
基本設定はゲームの根幹となる重要な設定ですが、最初に設定すべきは「取り扱い資源」と、必要に応じて「シナリオパラメータ」のみです。取り扱い資源は、後ほど地域設定を行う際に影響します。シナリオパラメータは、後ほどシナリオを作成する際に使う場合があります。
残りは、シナリオ完成直前、もしくは、必要が生じた時に設定する、で構いません。
シナリオ名
シナリオ名を設定します。
完成後に他のプレイヤーに公開する際、最初に見られる部分ですので、分かりやすい名前にしましょう。
作者名
作者名を設定します。
従業員充足率
ゲーム開始時に、運営必要人数に対して従業員数がどのくらい足りているかを設定します。

コンストラクションの時に業務効率化しておけば改善されるのかというとそうでもありません。
設定が正しく反映されるようにして欲しいものです。
なお、難易度やさしいでゲーム開始する際は従業員充足率の概念はなくなります。
社員状況
社員の仕事に対するやる気を設定します。
難易度標準でも達人でも設定は反映され、100% にすると「活気に溢れている」になります。
ここで設定しても、コンストラクション中に子会社を売却するとゲーム内時間が進んでなくても変動するため注意しましょう。
ブランド力
難易度標準における会社の知名度を設定します。駅や子会社の売上に影響する他、人員増強で集まる人数にも影響するのではないかという気がしています。
難易度やさしいだと強制的に最大、達人だと強制的にゼロになります。
公共交通利用率
公共交通利用率を設定します。
住民が鉄道やバスなどの公共交通機関を利用する割合です。乗客数に影響します。
株主信頼度
難易度標準、難易度達人における株主からの信頼度を設定します。株式公開時の資金調達に大きく影響します。
0 まで下がるとゲームオーバーになるため、慎重な設定が必要です。特に、借金シナリオなどで利益剰余金がマイナスの場合、シナリオ開始後に配当金を払えず株主信頼度が下がることが想定されます。
難易度やさしいだと強制的に最大になります。
銀行信頼度
難易度標準における銀行からの信頼度を設定します。銀行からの融資限度額に影響します。
難易度やさしいだと強制的に最大、達人だと強制的にゼロになります。
シナリオパラメータ

公式ヘルプで「キャラクターの好感度として使います。会話シーンの選択肢によって値を変え、その値によって会話シーンを分岐させます」とあるように、シナリオを作成する際に様々なことができるようになります。
西暦上限
時代の進行が止まる年を設定します。
時代を固定して遊びたい場合に設定してください。
時代を固定して遊びたい場合に設定してください。
開始年
シナリオを開始する年を設定します。マップ生成時に設定した開始年を、プラスマイナス 10 年の範囲でずらせます。
ボーナス設計図
シナリオ開始時、プレイヤーが過去に別のマップで開発した車両の設計図を持っているかどうかを設定します。
「少ない」を選んだ場合、ボーナス設計図をいくつかランダムで持っている状態でシナリオを開始します。「全て」にしても、プレイしたマップとの年代の関係によって持って行けない設計図もあります。
「少ない」を選んだ場合、ボーナス設計図をいくつかランダムで持っている状態でシナリオを開始します。「全て」にしても、プレイしたマップとの年代の関係によって持って行けない設計図もあります。
資本金
シナリオ開始時の会社の資本金を設定します。
初期資金がマイナスになる設定では、シナリオ登録できません。
初期資金がマイナスになる設定では、シナリオ登録できません。
やさしい補正
難易度やさしいを選んだ時の、シナリオ開始時の資本金に対する補正度合いを設定します。
達人補正
難易度達人を選んだ時の、シナリオ開始時の資本金に対する補正度合いを設定します。

また、補正設定は「資本金」に対するもので、「資金」ではないことに注意してください。
例えば、線路・駅・子会社などの資産を 250 億円保有している状態では、資金が差し引かれますので、やさしい資金は 750 億円、標準資金は 250 億円、達人資金は 100 億円となり、やさしいと達人では資金に 7.5 倍の差が生じます。
欠損金
会社の累積赤字を設定します。
赤字状態から始めるシナリオにしたい時に設定してください。
大きすぎると資金がマイナスになってしまうので、シナリオ登録できません。
赤字状態から始めるシナリオにしたい時に設定してください。
大きすぎると資金がマイナスになってしまうので、シナリオ登録できません。
取り扱い資源
例えば木材をオフにすると、木材集積場を建設できなくなる他、売買案件にも木材が登場しなくなります。
ただし、コンストラクションモードで既に建設済の貯蔵場(木材集積所など)は破壊されるわけではなくそのまま残ります。
次:地域設定編
はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)
更新履歴
- 2022/05/01 初版。
- 2022/05/07 シリーズインデックス作成。

街づくりのやり方は大きく 2 種類あります。1 つは通常のゲームモードと同じ操作での街づくり、もう 1 つがマップコンストラクション専用メニュー「個別編集」での街づくりです。
地形に準ずる建造物(湖や川など)も個別編集です。
一方で、鉄道やバスに関すること(線路敷設等)は通常のゲームモードと同じ操作で行います。
本記事では、主に個別編集について説明します。
河川と湖
街づくりで一番最初にやるべきことは、河川と湖の作成だと思います。河川等を最初につくったほうが住宅等もイメージしやすくなるというのもありますが、特に河川は思いも寄らないマスに生成されて付近の住宅等を破壊してしまうので、後から作るとかなり手間が増えてしまいます。
[個別編集 → 自然 → 加工]メニューに河川があります。
マップコンストラクションの操作性は全体的に悪いのですが、中でも河川敷設は筆頭クラスと言えるでしょう。
湖については素直に配置していくだけで自動的に接続されます。
ランダム配置
河川を筆頭にイラッとする操作性のマップコンストラクションですが、もちろん良いところもあります。
山などに範囲指定でランダム森林を配置すると、さまざまな森林を一瞬で植えることができます。同じ位置に何度も配置すると、森林の成長度合いが変化します。
[個別編集 → 住宅 →一般住宅3]にある住宅のランダムは道の両側に家を配置するときに便利です。
その他の施設
建造物がジャンル毎に分かれているのは便利です。例えば、娯楽は「海浜系」「市街系」「自然系」などと分かれていて、自然系からキャンプ場やバーベキュー場などが配置できます。

建物の回転は、右上の回転ボタンで行います。また、タイプ(建物の色や看板)は一定時間ごとにローテーションしますので、目的のタイプが表示されたタイミングでクリックするとそのタイプが配置されます。
操作に慣れない場合は、一般の子会社であれば通常のゲームモードの子会社建設で行うこともできます。ただし、自社子会社になってしまうので、他社にしたい場合は、後ほど売却(即時処分)が必要です。
観光碑

観光碑は 1~3 まであり、それぞれ集客力が 2、3、5 となっていますが、実際に配置すると、集客力が下回る場合もあります。周囲との関係性によって、最大で 2、3、5 ということのようです。
観光碑または、観光地になる子会社(スタジアムなど)を 1 つ以上作成しておくのがセオリーと言えるでしょう。どの子会社が観光地になるのかは、wiki にまとめられています。観光地子会社は、自社子会社であれば、子会社メニューから名前を付けることができます。他社子会社の場合は名前を付けられません(自社子会社で名前を付けてから売却しても「スタジアム1」とかに戻ってしまいます)。
駅名など
公式シナリオでは、
- 駅 → 末尾に「駅」を付ける(例:奈桜駅)
- バス停留所 → 末尾に「停留所」は付けない(例:奈桜駅前)
- トラック駐車場 → 末尾に「駐車場」を付ける(例:瀬塚駐車場)
となっているようです(例外もあります)。公式シナリオの命名規則に合わせておくほうが自然な感じになるかと思います。
列車など
最初にプランの列車開発などで開発します(通常のゲームモードとは異なり、即時に開発完了します)。
開発後に購入・配置します。
次:ゲーム基本設定編
はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)
更新履歴
- 2022/04/30 初版。
- 2022/05/04 駅名などを記載。
- 2022/05/05 列車などを記載。
- 2022/05/07 シリーズインデックス作成。

マップ生成でおおまかな地形ができたので、今回の土地造成では、土地の高低(平地、山、海)について完成形を目指します。
盛ると削る
盛る・削る部分とその周囲の傾斜がどの程度急峻になるかを、傾斜の補完で指定できます。険しいにすると、傾斜が急になり、岩肌になります。

直前にクリックした地点もスライダー上下でリアルタイムに盛り上がり具合が変われば、画面を見ながら良い感じに調整できたのではないかと思います。
公式ヘルプにある通り、削るで B1 以下になった地形は自動的に海となります(土地造成中は明るい茶色で表示されます)。湖を作りたい場合は、後ほど個別編集で作成します。
平ら
クリックした地点の標高に、周囲の標高を合わせます。希望の標高になっている地点をクリックしてから、徐々に塗り広げていくイメージで次々と付近をクリックしていく感じで操作すると、希望の高さに揃えられるのではないかと思います。
なお、結果的に周囲の標高が変わらない場合でも、周囲の田畑等は破壊されて草原になってしまいます。この辺りも使いづらい仕様です。
次は街づくり
土地の高低が完成したら、次のステップとして街づくりに進みます。
街づくりをしている途中でも土地造成の修正は可能ですが、何かしらの建造物がある地点の土地造成はできないため、いったん建造物を撤去してから土地を修正し、土地修正後に再度建造物を作る、という手間が発生します。
できる限りの土地造成はこの段階で済ませておく方が効率的です。
次:街づくり編
はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)
更新履歴
- 2022/04/30 初版。
- 2022/04/30 細かな補足を追記。
- 2022/05/07 シリーズインデックス作成。
Steam 版(Build 30257.629)をもとにしていますが、Nintendo Switch 版でも似たような感じなのではないかと思います。
なお、縮小表示されている画像はクリックで拡大できます。
基本的な流れ
基本的な流れは公式ヘルプに準じます(公式ヘルプが用意されていること自体は大変ありがたいのですが、フレーム使用なのでリンクを貼りたいときは不便ですね……)。
- 構想
- マップ生成
- 土地造成
- 街づくり(個別編集など)
- ゲーム設定(地域設定、シナリオ作成など)
- テストプレイ
- シナリオ登録・公開
構想
公式解説動画には、
- シナリオの見どころを作る(複雑な路線網、優雅な観光地、ストーリー etc)
- 目的を作る(路線拡張、観光客増加、トゥルーエンド etc)
とあります。
例えば公式シナリオ「転換する都市」では、
- 見どころ:臨海地区の夜景
- 目的:工業を衰退させて商業などを発展させる
というあたりになろうかと思います。

- 見どころ
- 観光地:渓谷と城(琵城)
- ストーリー:琵城にまつわる伝承(琵城小噺集)
- イベント:傾国の美女(誰を選ぶかで結果が変わる)
- 目的:琵城への観光客誘客
としています。
構想がブレると実作業が大幅にやり直しとなることもあります。最初の段階でしっかりと構想を固めておきましょう。
サイズ
SS は縦横 80 マス、L は 320 マス(縦横 4 倍で面積 16 倍)です。ヘルプには 1 マスのサイズについて記載がありませんが、行政受託から計算すると 1 マス 50m なので、L サイズマップは 16km × 16km ということになります。
開始年
年代によって、使える列車や建物が異なります。
標高と平地

- 平地:1F 平地の割合(残りは海か高地)
- 標高:MAX の標高(ランダムで必ずしもその標高の地形ができるとは限らない)
くらいのものではないかと思います。平地を 100% にした時点で、標高に関係なくすべてが 1F 平地になります。逆に、平地を 0% にしても多少は 1F 平地が生成されます。
平地ではない部分が海になるか高地になるか(ランダム)で、開発できる面積は変わってきます。例えば、平地 25% にした場合、残りの 75% が海だと、開発面積は 25% です。一方で、高地になった場合、高地が全て斜面だと開発しづらいですが、高地の平地(高台)になれば、そこも開発できるので、開発面積は 25% よりも多くなります。
川と湖
森林と田畑と住宅
が、恐らくもう 1 つ重要な要素があって、草原の割合もこれで決まるようです。推測ですが、
- 100-(森林・田畑・住宅の最大値):草原の割合
- 草原以外の部分を、森林・田畑・住宅でポイント比率計算
なのではないかと思います。
石油と石炭
生成
公式ヘルプに記載の通り、「おおまかな地形ができたら」それでよしとすべきです。細かい調整は、次以降のステップである土地造成・個別編集で作業をしていきます。
とはいえ、
- 手動の土地造成・個別編集はなかなか思い通りにいかない(操作が難しい)
- 一括編集もできるとはいえ、基本的には 1 マスずつの編集なので時間がかかる(L サイズだと 10 万マスを編集することになる)
- 自動生成の森林・田畑の入り交じり具合を手動で再現するのは困難
という懸念点があります。自動生成は L サイズマップでも 10 秒程度でできますが(PC の性能によります)、手動での土地造成・個別編集は数時間~数十時間にも及びます。はっきりと土地の完成形がイメージできている場合は、なるべく近い形の土地ができるまで繰り返し生成を試みる方が、結果的には時間の節約になるのではと思います。
完成
希望の地形が生成されたら、完成ボタンをクリックします。
全面更地から始めたい場合は生成ボタンをクリックせず、いきなり完成ボタンをクリックします。
次:土地造成編
はじまるA列車 自作シナリオ作成方法 まとめ(全 9 回)
更新履歴
- 2022/04/29 初版。
- 2022/04/29 細かな補足を追記。
- 2022/05/04 構想を記載。
- 2022/05/07 シリーズインデックス作成。
持ちカラ(動画持ち込みカラオケ)をしている際に講習会の話が出ましたので、まずはどんな講習会が求められているのか、アンケートを作ってみました。
【アンケート】興味ある持ちカラ講習会/勉強会
https://docs.google.com/forms/d/e/1FAIpQLSfDp5axpvr40PgzG2g79UML54j7_sAnv_SFn9AfWl7u27XdxA/viewform
【アンケート】興味ある持ちカラ講習会/勉強会
https://docs.google.com/forms/d/e/1FAIpQLSfDp5axpvr40PgzG2g79UML54j7_sAnv_SFn9AfWl7u27XdxA/viewform
- 参加者(歌う人)向け
- 動画職人向け
- 機材係向け
- 幹事向け
さまざまありますので、まずは上記リンクを見てみて、興味があったらポチってください。ニーズが多ければ開催されるかもしれません!?
締切:4/30
なぜストアで配布することにしたのかというと、以下のような様々なメリットがあるためです。
インストールがさらに簡単に
これまでもインストールは簡単でしたが、ストア配布によりさらにインストールが簡単になりました。
ストアの「入手」または「インストール」ボタンをクリックするだけでインストールが完了します。
ストアの「入手」または「インストール」ボタンをクリックするだけでインストールが完了します。
スタートメニュー自動登録
インストールすると、スタートメニューにも自動的に登録されます。
(補足)
起動時はスタートメニューから起動してください。
旧 zip バージョンの時に作成したショートカットから起動すると旧バージョンが起動してしまいます。
SmartScreen による妨害がない
これまでは、アプリを起動しようとすると SmartScreen の画面が表示されて、いくつか画面をクリックしないと起動できない場合がありました。
ストア配布により SmartScreen が表示されなくなるため、起動が簡単になります。
ストア配布により SmartScreen が表示されなくなるため、起動が簡単になります。
更新がさらに簡単に
これまでも更新(バージョンアップ)は簡単でしたが、ストア配布によりさらに更新が簡単になりました。
更新版が公開されると、自動的に更新版がインストールされますので、何ら画面で操作する必要はありません。
更新版が公開されると、自動的に更新版がインストールされますので、何ら画面で操作する必要はありません。
(補足)
旧 zip 版からストア配布版への自動更新は行われません。
ストア配布のアプリを最初の 1 回はストアで入手する必要があります。
PC 買い換え時に楽
パソコンを買い換えた時や、あるいは Windows をクリーンインストールした時など、他のストアアプリと一緒にまとめてインストールすることができます。個別にインストールする必要がないので手間がかかりません。
ストア配布リンク
ゆかりすたー NEBULA が正式版となったので、前世代 METEOR と処理速度を比較してみた。USB 接続ポータブル HDD に入っている約 32,000 曲を整理するのに要した時間を測定。測定環境はこちら。
フォルダー追加時の処理時間
前世代 METEOR | 新世代 NEBULA 初回 | 新世代 NEBULA 2 回目 | 差異 | NEBULA が 何倍高速か | |
---|---|---|---|---|---|
ファイル名検索 が可能になるまで | 22 秒 | 32 秒 | 6 秒 | - 16 秒 | 3.7 倍高速 |
ファイル名検索 +属性検索 が可能になるまで | 5 分 45 秒 | 4 分 30 秒 | 6 秒 | - 5 分 39 秒 | 57.5 倍高速 |
ゆかり用リスト作成の処理時間
前世代 METEOR | 新世代 NEBULA | 差異 | NEBULA が 何倍高速か | |
---|---|---|---|---|
リスト作成時間 | 14 秒 | 21 秒 | + 7 秒 | 0.7 倍(遅い) |
フォルダー除外時の処理時間
前世代 METEOR | 新世代 NEBULA | 差異 | NEBULA が 何倍高速か | |
---|---|---|---|---|
フォルダー除外時間 | 1 分 3 秒 | 7 秒 | - 56 秒 | 9.0 倍高速 |
最も処理時間を要する、フォルダー追加時の属性検索処理時間について、NEBULA の 2 回目はキャッシュを活用したことにより、57.5 倍という圧倒的な高速さで処理を終えた。
フォルダー除外時の速度もかなり高速化されている。
一方でリスト作成の処理速度は旧世代 METEOR よりも遅くなったが、時間にすると 7 秒であり、トータルでは NEBULA が圧倒的に速い。
ゆかりすたー NEBULA は、前世代 METEOR と比べてこちらにまとめたようなメリットを備えたうえで、前世代 METEOR の機能も網羅するに至った。
また、目には見えない内部的なところでも大幅に変更が行われており、内部の主な変更点としては、
- プラットフォーム最新化(.NET 5 + EF Core)
- MVVM 適応度向上
- マイクロコア化による安定性・応答性向上
が挙げられる。
見た目はさほど変わらない NEBULA と前世代 METEOR で、ソースコードはどのくらい変化したのか、少し調べてみた。
まず、ソースコード全体の量は、以下のように変化した(行数:空行を除く)。
前世代 METEOR | NEBULA | 増加率 | |
---|---|---|---|
*.cs | 36,541 行 | 41,512 行 | + 13.6 % |
*.xaml | 1,998 行 | 1,919 行 | -4.0 % |
見た目を決める *.xaml の量はほぼ変化していないが、内部の *.cs の量は 14% 程度増加している。内部的な変更により効率よく記述して量が減っている側面もあるのだが、機能増により全体としての量は増えたようだ。
次に、変化の内訳を調べてみた。本当はすべてのソースコードについて調べたかったが、大変すぎたので、データベースを扱う 1 ファイルだけ見てみた。
行数 | |
---|---|
前世代 METEOR 行数 | 271 行 |
NEBULA でも記述が変わらない行数 | 121 行 |
記述を変更した行数 | 96 行 |
削除した行数 | 54 行 |
追加した行数 | 99 行 |
変更・削除率 | 55.4 % |
追加率 | 36.5 % |
変更・削除率は 55.4% で、ソースコードは半分以上書き換わっていた。
変更・削除率と追加率を単純に足し算するのも何か違う気はするが、単純に足し算してみると 91.9% となり、全面書き換えに近い数値となった。
というわけで、見た目はあまり変わらなくても、内部はかなり変わっていた。
GitHub のリポジトリにドキュメントを入れる場合、大きく分けて
- README.md(および必要に応じてその他のドキュメント)をリポジトリに直接配置
- Wiki を使う
の 2 つのやり方があるが、基本的な機能(Markdown で書けて、GitHub サイト上での表示・編集が可能で、変更履歴も管理される)が同じだけに、どう使い分ければ良いのかというハテナが出て来たので、調べてみた。
機能的な違い
README.md と Wiki は基本的な機能は同じであるものの、確認できた範囲では以下のような違いがあった。
README.md | Wiki | |
---|---|---|
記述方法の簡単変更 | × | ○ |
ページ一覧の自動作成 | × | ○ |
サイドバー | × | ○ |
フッター | × | ○ |
ページの階層化 | ○ | × |
変更履歴管理 | リポジトリで管理 (全体+ファイル別) | ファイル別のみ |
根本的には「README.md はリポジトリそのものの 1 ファイルにすぎない」という位置づけになっていて、ドキュメントに特化した Wiki との違いが生じているということだと思う。
「記述方法の簡単変更」というのは、「最初は Markdown で書いていたけど、途中で Textile に切り替えたくなった」という場合に、簡単に変更できるかという観点。
README.md の場合は、いったん README.md を削除してから新たに README.textile を作成すれば変更は可能(Code ページできちんとフォーマットして表示される)だが、Wiki と比べると一手間余計にかかる。
「ページ一覧の自動作成」は、Wiki の場合、特に何もしなくても、Wiki の右側に「Pages」という欄が表示されるようになる。逆に、これを消すことはできず、強制表示となる。
「サイドバー」「フッター」については、Wiki の場合、「_Sidebar」「_Footer」というページを作ることにより、常に Wiki の右側・下側にそのコンテンツを表示できる。
README.md の場合は、試しに _Sidebar.md _Footer.md というファイルをリポジトリに配置してみたが、README.md 表示の際にこれらのファイルは表示されなかった。
以上のように、Wiki にはドキュメントに特化したお手軽機能が備わっている。
一方で残念なのは、Wiki はページの階層化ができない点。ページ作成時に「A/B」のような命名をしてみても階層化されなかった。
README.md の場合はリポジトリそのものなので、リポジトリにフォルダーを作って新たな *.md(なり他のフォーマットのドキュメントなり)を配置すれば、ドキュメントも階層化できる。
「変更履歴管理」については、README.md はリポジトリそのものなので、リポジトリの変更履歴を見れば内容は一目瞭然。ドキュメントファイルを新規作成したり削除した場合も、リポジトリの変更履歴で確認できる。
Wiki の場合は変更履歴管理がページごとになっているので、それぞれのページの変更履歴は確認できるが、そもそもファイルが増えたり減ったりしたことを分かりやすく確認する手段は無い模様。
使い分け
機能的な違いを踏まえた上で、README.md(+リポジトリ内ドキュメント)と Wiki をどのように使い分けるか?
正直なところ、決定的な方法は思いつかない。
1 ページで済む簡単なドキュメントならば、README.md だけで事足りるのは間違いない。
ではファイルが増えてきたら Wiki かというと、個人的にはそうでもないかなと思う。理由は、Wiki だとデザインが変更できないから。ファイルが増えるような本格的なドキュメントということであれば、Markdown お仕着せのデザインではなく、自分なりのデザインにしたい。
となると、HTML でちゃんとドキュメントを作ってリポジトリで管理、ということになる。README.md はごく簡単にして、詳しくは HTML ドキュメントをご覧ください、という誘導。
つまり、README.md(+リポジトリ内ドキュメント)陣営オンリーになり、Wiki の出番は無い。
ただ、HTML ドキュメントの欠点は、GitHub サイト上で表示されないこと。http://htmlpreview.github.io/ で表示するか(現時点で CSS は反映されない)、あるいはリポジトリをいったんダウンロードしてもらうという手間が発生する。
その点 Wiki(でもリポジトリ上の *.md でもいいけど)はお手軽で良い。しかし、デザインを変更できないという他にも、ソフトウェア配布時にローカルで読めないという欠点もある。ネットに繋がっていないとドキュメントが読めないというのは困るシチュエーションがあるし、GitHub の都合で URL が変更されたりしたらリンク切れになってしまう。また、Wiki には「リンク先を別タブで開く」といった基本的な機能が備わっていなかったりする。
というわけで、暫定方針としては
- 簡単なドキュメント……README.md
- 本格的なドキュメント……HTML ドキュメントをリポジトリで管理
- Wiki は使わない
としようと思うが、課題はある、といった感じ。
他の人はどうしているか
使い分けを明確に示しているサイトが意外と無いのだが、
というような事例はあった。
ニコカラメーカー 2 は Windows 10 専用ソフトであるが、M 氏は Mac 上でニコカラメーカー 2 を使用しているとのことなので、動作する様子を見せていただいた。
動作方法
Mac で Windows 用ソフトを動かすには大きく 2 種類の方法がある。
- Boot Camp により、独立した Windows をインストール
- 仮想化ソフトにより、Mac OS の上で Windows 環境を再現
M 氏は前者の Boot Camp 方式でニコカラメーカー 2 を動かしていた。
Mac のスペック
- CPU:Intel Core i5-7267U(2 コア 4 スレッド、3.10 GHz)
- メモリ:8GB
というスペック。
Apple のホームページは過去の製品情報がとても探しづらいのだが、こちらの Mac Book Pro 2017 かな? 巷では MPXV2J/A とか A1706 の型番で認識されているようだ(公式サイトに型番表記が無いとかダメすぎ)。だとすると、他のスペックは
- 13.3 インチ 2,560 x 1,600 ピクセル IPS 液晶ディスプレイ
- メモリ:8GB(LPDDR3-2133)
- 内蔵 GPU:Intel Iris Plus Graphics 650
となる。
ニコカラメーカー 2 動作
Thank you!
M 氏、貴重なものを見せていただきありがとうございました。
なお、本レポートは M 氏の環境で動作していたという事実のみであり、すべての Mac で動作するかどうかは不明です。
ニコカラメーカー 2 に限らず、私が開発している Windows 用ソフトすべてにおいて、Mac 上での動作は公式には動作対象外です。
今代のメインマシン(Ryzen 7 3700X)を使い始めてから、今日でちょうど丸一年。
起動に時間がかかるのと、アイドル時の消費電力が高めなのが不満点ではあるもの、全体的には快適に使えてる。
各 SSD の現時点での総書込量を記録しておく。ちなみに 3 ヶ月時点のはこちら。
300 TBW のディスクなので、42 年使える計算。
400 TBW のディスクなので、141 年使える計算。
400 TBW のディスクなので、122 年使える計算。
いずれのディスクも TBW 的にはまったく問題がないが、D / E ドライブはパーセンテージが 99% に減ったのが少し気になるところ。
ついでに、USB 外付け HDD も CrystalDiskInfo しておく。

およそ 110 日経過しており、使用時間としては 2,640 時間ほどになる計算だが、実際にはたったの 248 時間というのは、省電力で自動 OFF になっているからだろう。代わりに、電源投入回数が 437 回になっている。

ファンクラブ名の五十音順にリストアップ。
ツールなど
- UTALOADER公式ファンクラブ:デルタさんの音楽アップローダー。
- カラオケツール & UTAU 支援ツール:唄詠、すっぴんプラグイン、うたりすなど。
音源、音楽など
- うちとま!ファンクラブ:?
- おふとんPの直売所:薪宮風季
- 倶楽部ちよじ:奏音トモ
- ここではメタルしかやらんぞ:破壊音マイコ
- The Schizanthus:?
- Hearts (心汰(m):右心フルアラ、行方杠など
他にもご存じでしたら教えてください。
pixivFANBOX も今度探してみようかしら。
初代ニコカラメーカー(Ver 7.91 β)とニコカラメーカー 2(Ver 3.21 β)で、動画出力時の速度を比較した。
マシンスペック
速度比較を実施した PC の主な環境(構成)は、
- CPU:AMD Ryzen 7 3700X(8 コア 16 スレッド)
- GPU:GIGABYTE GV-N1650IXOC-4GD(GeForce GTX1650)
となっている。詳細についてはこちらの記事参照。
対象動画
- お願い☆EternalSummer! / 初音ミク(ダブルレンP)
- フル HD(1920 x 1080)、30 fps、4 分 22 秒

AVI 出力時間
無圧縮 AVI を、初代ニコカラメーカーとニコカラメーカー 2 でそれぞれ 2 回ずつ動画出力し、平均動画出力時間を比較した。結果は以下の通り。
初代ニコカラメーカー | ニコカラメーカー 2 | |
---|---|---|
1 回目 | 7 分 46 秒 | 2 分 10 秒 |
2 回目 | 7 分 34 秒 | 2 分 11 秒 |
平均 | 7 分 40 秒 | 2 分 11 秒 |
ニコカラメーカー 2 のほうが、初代ニコカラメーカーより 3.5 倍高速に出力された。
初代ニコカラメーカーはほぼ CPU 1 スレッドで作業しているが、ニコカラメーカー 2 では 9 スレッドで作業しているのと、GPU も活用して作業しているため、高速化されている。

連番 PNG 出力時間
連番 PNG を、初代ニコカラメーカーとニコカラメーカー 2 でそれぞれ 2 回ずつ動画出力し、平均動画出力時間を比較した。結果は以下の通り。
初代ニコカラメーカー | ニコカラメーカー 2 | |
---|---|---|
1 回目 | 16 分 38 秒 | 2 分 27 秒 |
2 回目 | 16 分 04 秒 | 2 分 23 秒 |
平均 | 16 分 21 秒 | 2 分 25 秒 |
ニコカラメーカー 2 のほうが、初代ニコカラメーカーより 6.8 倍高速に出力された。
連番 PNG(字幕のみ)出力時間
連番 PNG(字幕のみを透過で)を、初代ニコカラメーカーとニコカラメーカー 2 でそれぞれ 2 回ずつ動画出力し、平均動画出力時間を比較した。結果は以下の通り。
初代ニコカラメーカー | ニコカラメーカー 2 | |
---|---|---|
1 回目 | 7 分 05 秒 | 1 分 48 秒 |
2 回目 | 7 分 00 秒 | 1 分 47 秒 |
平均 | 7 分 03 秒 | 1 分 48 秒 |
ニコカラメーカー 2 のほうが、初代ニコカラメーカーより 3.9 倍高速に出力された。
出力時間まとめ
初代ニコカラメーカー | ニコカラメーカー 2 | 倍率 | |
---|---|---|---|
無圧縮 AVI | 7 分 40 秒 | 2 分 11 秒 | 3.5 倍 |
連番 PNG | 16 分 21 秒 | 2 分 25 秒 | 6.8 倍 |
連番 PNG(字幕のみ) | 7 分 03 秒 | 1 分 48 秒 | 3.9 倍 |
関連リンク
メインマシンの UEFI を安定の AGESA 1.0.0.4 B に上げたので、消費電力を簡単に測定してみた。
電源投入後、Windows 10 起動時はかなり上下があるが、最大で 134W。
アイドル時は基本的に 64W。先代の Core i7 マシンは 49W だったので 31% 増加。やはり AMD 系のシステムはアイドル時の消費電力が高いようだ。
ソフトのバージョンも違うので目安だが、先代のマシンの 3 分の 1 の時間でトランスコードできる計算だ。コア数が多いので消費電力は 1.5 倍程になっているが、トランスコードにかかる全体の消費電力は半分程に抑えられる計算。
トランスコードしながら CrystalDiskMark してみると、消費電力は 165W まで増加。

しかし、最高でも 221W なら、電源は 650W も要らなかったよね……。本当はもっと低い電源容量が良かったのだけど、選択肢に良いのがなく仕方なしに 650W にしたのだが、改めて、より低い電源容量をラインナップしておいて欲しかったと思った。
CPU のコア数が増えすぎて訳が分からなくなってきたので、デスクトップ向け CPU について少し整理してみたメモ。8 コア以上の CPU を整理。サーバー向け(Xeon/EPYC)や数量限定品(9900KS)は除外している。
価格については、相場月報 2019/10 版を参照している(記載の無いものは初出価格)。
HEDT(ハイエンドデスクトップ)向け

HEDT 向けは AMD の圧勝。
24 コア以上は Intel のラインナップが無い。14 コア以下は AMD はメインストリーム向けで十分にカバーできてしまっている。
HEDT 向けで Intel の唯一の存在感は、AMD のラインナップの隙間となっている 18 コア品。
メインストリーム向け

メインストリーム向けのうち、上位の布陣も AMD の勝利。
12 コア以上について AMD がしっかりラインナップしているのに対し、Intel は HEDT 向けのラインナップになってしまっているので、マザーボード等を含め価格がかなり高く付く。
メインストリーム向けのうち、8 コアは良い勝負。
8 コア 16 スレッド品は、価格の絶対値では AMD が安いが、Intel はオンボードグラフィックスを搭載している。Intel のオンボードグラフィックスに相当する外付けグラフィックスは数千円程度のため、グラフィックス込みでも価格面では AMD が優位だが、Intel のほうが TDP を抑えられる。
また、どうせグラフィックスを外付けするならある程度の性能を持つものを、と考えると、価格が 1 万円以上上乗せとなるので(もちろん性能も圧倒的だが)、悩ましい選択となる。
8 コア 8 スレッドについては Intel のみのラインナップとなる。AMD は、6 コア 12 スレッドの Ryzen 5 がカバーする領域となる。
null 安全とは
「イマドキのプログラミングは null 安全がトレンドらしい」(参考記事:null 安全でない言語は、もはやレガシー言語だ)ということで、null 安全初心者が null 安全なコードを書いてみた。
そもそも null 安全とは、「null 参照例外(NullReferenceException)が発生しえるコードをコンパイル時にエラーにしてくれる」仕組み。つまり、コンパイルが通った時点で null 参照例外は起こりえないということになる。革命的に素晴らしいのでは?
C# においては、最新の言語バージョン 8.0 で「null 許容参照型」が導入され、これを使うと null 安全になる。
「null 許容参照型」という名前を聞いて、「参照型なんだから null が許容されるのは当たり前じゃないか」と思ったのだが、その常識が覆る。null 許容参照型を導入することにより、「普通の参照型には null を代入できなくなる」。つまり、C# という言語レベルで過去との互換性が失われる! 革命的に影響が大きい。
あまりにも影響が大きいので C# 8.0 では null 許容参照型はオプション扱いとなり、かなり限定的な環境でないと有効にならない。Visual Studio 16.3 の時点では、プラットフォームを .NET Core にしたうえで(.NET Framework でも一部機能は使えるらしい)、プロジェクトファイルを直接編集して null 許容参照型(Nullable)を有効にして、かつ、関連する警告をエラー扱いにする(参考記事:null 許容参照型)。
コード例
今までの C# のコード
String str = null;
String low = str.ToLower();
があったとして、ここまでシンプルであれば NullReferenceException を予見してコードを修正できるが、str の初期化がどこでされてるか分かりづらい場合は見逃してしまって NullReferenceException が発生するという事態に陥る。
しかし、null 許容参照型を有効にすると「普通の参照型には null を代入できなくなる」ので、str = null の時点でコンパイルエラーとなる。従って、
String str = "HOGE";
String low = str.ToLower();
のようなコードに修正せざるを得なくなり、NullReferenceException が発生しない安全なコードになる。これが null 安全か!
とはいえ、「str が null になることもある」という場合に、null 許容参照型を使う。型名の後ろに「?」を付けるだけだ(null 許容値型と使い勝手は似ている)。
String? str = null;
String? low = str?.ToLower();
str?.ToLower() の部分は、str が null であれば null が返り、null でない場合のみ ToLower() が実行されるので、NullReferenceException が発生しない。str が null の時は low も null になるので、low も null 許容参照型にする必要がある。? を忘れるコンパイルエラーになるので、やはり NullReferenceException は発生しない。null 安全すごい。
いくつかコードを書いてみた感想
null 許容参照型を有効にすると、変数が null になり得るのか否かを常に意識するようになる(というか、不適切なコードはコンパイルエラーになるので意識せざるを得ない)。
特にクラスメンバーを null 許容にしなかった場合は、コンストラクターでの初期化が必要となるので、「null 許容があるべき姿なのかどうか」をしっかり考えて選択するようになった。
関数の書き方も変わってくる。
Boolean TryParse (String s, out Hoge? result) のような関数は、返値が true の場合は result は null にはならず、それをコンパイラに教えるためには [NotNullWhen(true)] のように属性を指定する。が、そんな面倒なことをするくらいなら Hoge? TryParse(String s) のような形式に変更するほうがいいと思う。
また、型キャストの際に as 演算子を使うとキャストできなかった場合に null が返ってきてしまうので、if 文の中で is 演算子を使うスタイルに変わってきた。
private void Func(Object? sender)
{
if (sender is UIElement element)
{
element.AllowDrop = true;
}
}
sender が null ではなく、かつキャストできる場合のみ element に代入されるため、element は null 非許容となり、element のプロパティーにアクセスする際に ? は不要。
一方で、NullReferenceException にならない安全な世界ではあるものの、使い方を間違えるとエラーが埋もれるだけのより深刻な状況にもなりかねない。
呼ばれること自体に意味があるような関数、例えばユーザーへの警告表示で、null 安全ではない世界であれば、
hoge.ShowWarning();
で hoge が null の場合は例外が発生してマズいことになったのが表面化するが、null 安全な世界だと
hoge?.ShowWarning();
のようなコードとなり、例外は発生しないが、ユーザーに警告が表示されず、しかも表示されないままスルーされて問題が埋もれてしまう。
革命は 1 日にして成らず
null 安全は C# にとってあまりにも影響が大きく、ライブラリやコンパイラの対応もまだ発展途上のようだ。
例えば、メンバー変数をコンストラクターで初期化する際、コンストラクターから関数を呼びだしてそこで初期化していても、初期化していないと判定されてしまう。
また、
String[] strs = new String[3];
はコンパイルが通ってしまうが、実際には String[0] などは null であり、本来であればコンパイルエラーにしなければならないコードだ。
環境が整うまでにはまだまだ時間がかかりそうである。
とはいえ、null 安全は非常に素晴らしい仕組みだと思うので、少なくとも今後新規作成するプロジェクトでは積極的に使っていきたいと思う。
気になったこと
マルチスレッドで null 許容参照型にアクセスするとどうなるんだろうか。
想像だが、str?.ToLower() のようなコードはコンパイル時に
if (str != null)
{
str.ToLower();
}
のように解釈されるのではないだろうか。だとすると、str が null ではないと判定した直後に別のスレッドが str を null にしたら、ToLower() 呼出の際に NullReferenceException が発生してしまわないだろうか。
ところで、Nullable の読み方って「ぬらぶる」?
新パソコンを使い始めて 1 ヶ月。各 SSD の現時点での総書込量を記録しておく。
300 TBW のディスクなので、15 年使える計算。
400 TBW のディスクなので、18 年使える計算。
いずれもパソコン買い換えサイクルよりも長かったので一安心。
ついでに、USB 外付け HDD も CrystalDiskInfo しておく。
C# 動画プログラミングの 1 つです。
WPF の MediaElement や MediaPlayer で動画を再生する方法を紹介したページはいくつか見たのですが、通常再生のみが紹介されており、加工しながらの再生について言及されているページが見当たらなかったので、ここにまとめてみます。
目次
やりたいこと
例として、映像の左上に灰色の長方形を描き、フレームレートや動画再生位置(秒数)といった文字を重ねてみます。
サンプルコード
GitHub にアップしてありますので、そちらからダウンロードしてください。
動作環境については GitHub リポジトリ内のヘルプファイルを参照して下さい。
実装の基本方針
WPF には、(動画に限らず)表示の更新を行うタイミング(つまりフレームごと)で発生するイベントがあり、それが CompositionTarget.Rendering イベントです。
このイベント内で再生中の動画をキャプチャした上で、テキスト等を書き込んでいく、というのが基本的な考え方です。
プログラムの大まかな動作としては、ドラッグ&ドロップされた動画を再生(もちろん音声も)しつつ、上記の方法で映像にテキスト等を重ねています。
プログラムの解説
MainWindow.xaml.cs の解説です。
ファイルをドロップされた際に発生するイベント Window_Drop() において、動画の再生 Play() と、重ね合わせの準備 PrepareOverlay() を行っています。
Play() は単純に、ドロップされたファイルを MediaPlayer で再生しているだけです。
今回の 1 つのポイントは PrepareOverlay() で、ここでフレーム描画イベントハンドラー CompositionTarget.Rendering の設定を行っています。
ここで設定されたイベントハンドラーは WPF での描画が必要なタイミングで常に呼びだされるため、仮に動画が再生されていなくても定期的に呼びだされます。呼びだされる頻度は環境によって異なるとのことで、私の環境では通常 60 fps 程度で呼びだされていますが、100 fps 程度に上がることもあります。あくまでも「WPF 描画のフレームレート」であって、動画のフレームレートではないことに留意してください。
イベントハンドラーとして設定された CompositionTargetRendering() の後半部分で合成を行っています。
DrawingVisual の DrawingContext に対して、動画、図形(背景の灰色四角形)、テキスト(フレームレートや再生位置)を書き込み、最後にそれらを表示用のビットマップ(mBmp)に書き込みます。
WPF で動画を扱うメリット
WPF で動画を扱うメリットは、なんといっても手軽なことです。
加工しない再生だけなら MediaElement コントロール 1 つで簡単に動画を再生できますし、加工しても今回のサンプルコードのようにわずかなコード量で実現できます。
標準の C# 開発環境のみで実現できるため、追加のサードパーティーライブラリを用意したり、それをユーザーにインストールしてもらう(または一緒に配布する)という手間もありません。
また、詳しくは未検証ですが、インストールされているコーデックライブラリ(K-Lite 等)も WPF 側で自動的に利用してくれているようで、扱える動画の形式も無限に広がっていきます。
WPF で動画を扱うデメリット
WPF で動画を扱うデメリットは、(動画の)フレームを厳密に扱えないのではないかということです(扱える方法をご存じの方は教えてください)。
まず、根本的な課題として、動画のフレームレートが取得できません。動画の縦横サイズ等はプロパティーで取得できるのですが、フレームレートを取得するプロパティーはありません。
また、WPF で動きのあるものを処理する際はアニメーションという仕組み(Animatable クラスないしは IAnimatable インターフェース)に則っており、動画(MediaElement / MediaPlayer)も例外ではありませんが、動きの管理が時間単位で行われています。
何らかの方法で動画のフレームレートを取得できたとしても、厳密な意味でのフレーム送りはできず、1 フレームは○○ミリ秒だから○○ミリ秒進める、というような形でのフレーム送りになるのではないかと思います(この辺りは未検証ですが)。30 fps だと 1 フレーム当たり 33.3333.... ミリ秒ですが、小数点の丸めによって微妙に進まない(または 2 フレーム進んでしまう)瞬間が発生したり、そもそも可変フレームレートだとどうしようもないのではないかと思います。
スクリーンショットの動画
このページ冒頭のスクリーンショットに映っている動画は、ダブルレンさんの「お願い☆EternalSummer!」という曲です。素敵な曲なので、是非聴いてみて下さい!
歌いたい時はニコカラバージョンでどうぞ。
新しい Ryzen 7 3700X マシン(詳細スペックはこちら)のストレージ性能を CrystalDiskMark で見てみた。
C ドライブ(NVMe SSD)
シーケンシャルリード 3475MB/s とカタログスペック(3470MB/s)通りの性能が出ている。
シーケンシャルライトは 2585MB/s とカタログスペック(2600MB/s)に僅かに及ばないが十分な性能。
ランダムリードは 50MB/s 越え。
ランダムライトはなんと 200MB/s 越えで、HDD のシーケンシャルライトより速いのではないか。
D ドライブ(SATA SSD No.1)
SATA SSD としては十分な性能(というか SATA 規格の限界でこれ以上の性能が出ない)で、シーケンシャルリード・シーケンシャルライト共に 530MB/s 越え。カタログスペックは 530MB/s と 520MB/s なので、シーケンシャルライトはカタログスペックを上回っている。
ランダムリードは約 40MB/s と、SATA SSD としては最速クラスではないだろうか。
E ドライブ(SATA SSD No.2)
当然ながら、性能は D ドライブと同等。
当初はシーケンシャルリードが約 400MB/s と微妙に遅かったが、これはどうやら SATA ケーブルが古かったのが悪さをしていたようだ。新しいケーブルと交換したことで、本来の性能を発揮できるようになった。
F ドライブ(外付け HDD)
USB 3.0 接続の外付け RAID HDD ユニット、Western Digital My Book Duo WDBLWE0080JCH-JESN。
HDD ということで途端に性能が悪くなっている。加えて、4 年越しの使い古し品であることも悪条件。
新品の時に測定したデータと比べると、シーケンシャルは約 2/3、ランダムは約半分に性能が落ち込んでいる。
ポータブル 2.5 インチ HDD
2.5 インチなのでさらに性能が低い。
補足
ウィルス対策ソフトはインストールしただけでもストレージ性能下がるかなと思っていたが、実際はそうでもなかった。
インストール前と、インストール後に保護停止にした状態でそれぞれ SSD の性能を測定したが、有意な差は見られなかった。
なお、ウィルス対策ソフトは Kaspersky を使用している。
メインマシンの消費電力をごく簡単に測定した結果、49~104W 程度の消費電力だった。
電源投入後はかなり上下があるものの、90W くらい。
CrystalDiskMark してる時のも測定すればよかったな。
次のパソコンのマザーボードを何にするか検討中。
メーカー | ASUS | ASUS | ASRock | MSI |
---|---|---|---|---|
型番 | ROG Strix X570-F Gaming | TUF GAMING X570-PLUS | B450 Steel Legend | B450 TOMAHAWK MAX |
価格 | 34,000 円 | 24,000 円 | 13,000 円 | 14,000 円 |
チップセット | X570 | X570 | B450 | B450 |
メモリクロック | 4400~2133 | 4400~2133 | 3200~2133 | 4133~2667 |
VRM フェーズ | 12+2 | 12+2 | 4+2 | ? |
M.2 | PCIE 4.0 x4 | PCIE 4.0 x4 | PCIE 3.0 x4 | PCIE 3.0 x4 |
巷で評判の良いマザボと、いくつかの BTO ショップ推奨のマザボを比較。
ROG Strix X570-F Gaming
ROG Strix は Wi-Fi やカスタマイズオプション満載のシリーズとのこと。オーバースペックな気がする。チップセットファンも気になる。
VRM 周りは下位とシリーズと同レベルらしい。AGESA 1.0.0.3 ABB でも WHEA が発生するという話もある。
TUF GAMING X570-PLUS
TUF GAMING は耐久性重視のシリーズとのこと。高耐久の安心感は欲しい。価格も許容範囲。チップセットファンは気になる。
スリープ後にクロックが下がらなくなる事象が発生する環境があるらしい。
B450 Steel Legend
公式に DDR4-3200 をサポートしており、実例もあるマザボ。X570 と比べるとスペックは見劣りするが、これで十分な気もする。
しかし消費電力は他の B450 と比較して高いらしい。
MicroATX の B450M は、チップセットヒートシンクが無くなり、拡張スロットとストレージスロットが減る。
B450 TOMAHAWK MAX
B450 の中でも Zen2 に合わせてきたマザボということで安心感があるが、いかんせん情報が少ない。
お見積もり。いくつかの BTO ショップで見積もってみた。データ SSD は無しにしているので、これにプラス 56,000 円くらいかかる。OS も付けるならさらにプラス 20,000 円くらい。
サイコム
使いやすいウェブサイト。やや文字が小さい。
145,810 円……Ryzen 3000 シリーズのページにある B450 チップセットのスタンダードモデル(Radiant VX2800B450A)をカスタマイズ。MicroATX の Steel Legend。メモリ DDR4-3200、2 万円引き。ケース品切れ中。電源は Antec NeoECO 650W GOLD。
146,030 円……Ryzen 3000 シリーズのページにある X570 チップセットのスタンダードモデル(Radiant GZ2800X570A)をカスタマイズ。ATX の Steel Legend。メモリ DDR4-3200、2 万円引き。電源は Antec NeoECO 650W GOLD。
159,180 円……Ryzen 3000 シリーズのページにある B450 チップセットの静音 PC(Silent-Master Pro B450A II)をカスタマイズ。ATX の Steel Legend。メモリ DDR4-3200、2 万円引き。電源は Antec NeoECO 650W GOLD。
159,180 円……Ryzen 3000 シリーズのページにある B450 チップセットの静音 PC(Silent-Master Pro B450A II)をカスタマイズ。ATX の Steel Legend。メモリ DDR4-3200、2 万円引き。電源は Antec NeoECO 650W GOLD。
パソコンショップ SEVEN
172,244 円……CPU 別の Ryzen 3700X から、ZEFT R7K02 の OS 無しモデルをカスタマイズ。キャンペーン 15,000 円引き。ATX の Steel Legend。メモリは DDR4-3200 が品切れで 2400。電源は Antec NeoECO 650W GOLD。Blu-ray は BH16NS58。
見やすいウェブサイト。オプションが全て全開のためやたら縦に長くスクロールが大変。
VSPEC
191,860 円……特集コーナー AMD Ryzen 対応モデルから第 3 世代 Ryzen スタンダードをカスタマイズ(AMD ハイエンドモデルから行くと第 2 世代になってしまうので注意)。SL が選べず TUF GAMING X570-PLUS。メモリは DDR4-2666。
PC ワンズ
137,159 円……フルカスタマイズ PC のメニューから BTO できる。ATX の Steel Legend。メモリは DDR4-3200。電源は NeoECO 550W。
パーツを 1 つ 1 つ指定していくのが大変なだけではなく、ブラウザを閉じるとカートの中身が失われてしまうという恐ろ仕様。心折れそう(最初折れた)。
Ryzen 3000 シリーズが発売されたので、その 2 から修正。
本体
パーツ | 型番 | 想定価格(税込み) |
---|---|---|
名称 | 次期メインマシンイメージ その 3(2019 年 7 月) | 202,000 円 ~252,000 円 |
マザーボード | 未選定 | 11,000 円 |
CPU | AMD Ryzen 3700X ※8 コア 16 スレッド、定格クロック 3.6GHz(ブースト 4.4GHz)、TDP 65W、7nm プロセス | 43,000 円 |
CPU クーラー | CPU 付属品 | 0 円 |
セラミックグリス | CPU 付属品 | 0 円 |
メモリ | 32 GB ※DDR4-3200(PC4-25600)DIMM 16GB×2 | 25,000 円 |
システム SSD | Western Digital WD Black SN750 NVMe WDS500G3XHC ※500GB、PCIe Gen3 x4、M.2 2280 【または】 Intel Optane SSD 905P 380GB M.2 ※380GB、PCIe Gen3 x4、M.2 22110 | 17,000 円 【または】 67,000 円 |
データ SSD | 4TB ※SATA 2TB×2 | 56,000 円 |
マウンタ | SSD 付属品 | 0 円 |
光学ドライブ (Blu-ray) | LG BH14NS58 | 8,000 円 |
ビデオカード | Palit NE51650S06G1-1170F ※GeForce GTX1650 STORMX OC 4GB、TDP 75W、12nm プロセス | 17,000 円 |
LAN | オンボード | - 円 |
ケース | 未選定 | 15,000 円 |
電源 | 500W | 10,000 円 |
CPU は Ryzen 3000 シリーズが発売となったので、8 コアの 3700X をチョイス。8 コア APU を希望していたが、残念ながら発売に至らなかったので、グラボは別途とする。APU の i9-9900K という選択肢もあるが、3 年停滞しているインテルはどうもねぇ、という気分的な問題。
PCIe Gen4 を使う予定はないので、マザーボードは X570 でなくて良い。価格は仮置きで ASRock B450M Steel Legend の価格にしている。
メモリは現行パソコンと同様の 32GB で据え置き。
システム用 SSD は安価に NVMe で済ませる気がしている。Optane SSD の新しいのがもし出ればそちらもよいかもしれないが……。
データ SSD は本当は 4TB×1 が良いが、まだ高いので、2TB×2 で妥協。
Blu-ray ドライブは適当なので良い。
ビデオカードは、Ryzen APU よりはマシな程度で、かつ、消費電力がなるべく小さめということで、補助電源不要の TDP 75W クラス。
PCIe Gen4 を使う予定はないので、マザーボードは X570 でなくて良い。価格は仮置きで ASRock B450M Steel Legend の価格にしている。
メモリは現行パソコンと同様の 32GB で据え置き。
システム用 SSD は安価に NVMe で済ませる気がしている。Optane SSD の新しいのがもし出ればそちらもよいかもしれないが……。
データ SSD は本当は 4TB×1 が良いが、まだ高いので、2TB×2 で妥協。
Blu-ray ドライブは適当なので良い。
ビデオカードは、Ryzen APU よりはマシな程度で、かつ、消費電力がなるべく小さめということで、補助電源不要の TDP 75W クラス。
周辺機器
サウンドカードを更新。
パーツ | 型番 | 想定価格(税込み) |
---|---|---|
RAID ユニット | Western Digital My Book Duo WDBLWE0080JCH-JESN(流用) ※8TB、RAID 1 の運用で実効 4TB ※USB 3.0 接続 | 0 円 |
サウンドカード | Creative Sound BlasterX G5(流用) ※USB 接続 | 0 円 |
スピーカー | ONKYO WAVIO GX-70HD(流用) | 0 円 |
オーディオレシーバー | ONKYO WR-BT300(流用) ※Bluetooth で音声を受信してスピーカーに流す | 0 円 |
ディスプレイ | 21.5 インチワイド液晶、IO DATA LCD-MF223XS(流用) ※HDMI 接続 | 0 円 |
ゲームコントローラー | Logicool F310r(流用) | 0 円 |
次期パソコンの C ドライブ用ストレージ、Optane がいいなと思っていたけど、NVMe SSD でもまぁいいかもと思い始めたので、512GB クラスのカタログスペックを整理。価格は相場月報 6 月号の平均価格。

現行マシンの C ドライブは 6 年間で 40TB 近くの書込になっていて、次期マシンは RAM ディスクを使わないことや動画出力が多そうなことを考えると、10 倍の 400TBW くらい欲しいけど、一覧を見ると 300TBW で妥協するほうがいいのかもしれない。
体感速度に影響するであろうランダムリードと、動画出力用にシーケンシャルライトが速いのがいいなと思うと、WD、SanDisk、ADATA の順に有力。ADATA だけずいぶん安い。
Western Digital WD Black SN750 NVMe WDS500G3XHC……ヒートシンク無し版(型番末尾 X0C)もあるので注意。1TB 版のレビュー記事。
SanDisk Extreme Pro M.2 NVMe 3D SSD SDSSDXPM2-500G-J25……レビュー記事。
ADATA XPG SX8200 Pro ASX8200PNP-512GT-C……レビュー記事。
PetitKara にいくつか USB メモリや HDD を繋げた際の挙動をまとめてメモ。記憶を頼りにしている部分もあり、もしかしたら間違っている部分もあるかもしれない。
使用した PetitKara のバージョンは 1.4.19 で、WAN 側はインターネットに接続していない。
相性の悪い USB メモリ

Debian は USB メモリ A を認識していて、デスクトップに USB メモリ A のアイコンが表示されていた。
動画情報更新で読めない HDD
PetitKara が起動した状態で HDD E(Western Digital My Passport 4TB、青色、NTFS、動画ファイル 4 万個)を本体に直接挿し、動画情報更新をしたところ、10 分以上経っても動画情報更新が終わらない。HDD のアクセスランプが点滅しておらず、HDD にアクセスしている気配が無い。
セルフパワー型ハブ(Anker 10-Port USB 3.0 Hub)に HDD E を挿して動画情報更新をしても終わらない。なお、以降はすべてハブ経由の接続。
HDD F(4TB、黒色)についても同様で、起動後の動画情報更新で認識してくれない。
動画情報更新可能な USB メモリ
ストレージ 5 本挿し
USB メモリ B、USB メモリ C(水色)、HDD E、HDD F、HDD G(Buffalo HD-PNFU3、1TB、黄色、動画ファイル 1.3 万個)の 5 つを接続した状態で起動すると、Debian のデスクトップにすべてのストレージのアイコンが表示された。
この状態でしばらく運用していたところ、2 回ほど、曲が途中で終了してしまう状況が発生した。
Debian では認識されているが PetitKara からは認識されていない HDD E が何らか影響しているのかと思い、HDD E を外してみた。本来は外した後で動画情報更新を行うべきであるが、動画情報更新はうまくいかないことが分かっているので、動画情報更新はしていない。
USB メモリ B の中には、HDD E と同じファイルの一部が入っている形になっており、ファイル名だけで見れば HDD E と重複しているが、それが何か関係しているのであろうか。
別の組み合わせでストレージ 5 本挿し
USB メモリ B、HDD E、HDD F、HDD G、HDD H(Western Digital My Passport 4TB、黄色)の 5 つのストレージを起動時から接続しておいたところ、先ほど認識されなかった HDD E も含めて 5 つすべてのストレージが認識されたのではないかと思うが、ファイル数が多すぎて今ひとつ自信が無い。HDD E のパスをキーワードにして検索した結果の数から見て、HDD E はたぶん認識されたと思う。
生産物流箱庭ゲーム「Factory Town」において、マインカート(鉄道)は直進しかできない猪突猛進型のユニットですが、計算ブロックを使うことで、マインカートに様々な振る舞いをさせられるようになります。
以下の記事の内容は把握済みである前提でまとめています。
なお、Factory Town Ver 0.108m 時点(Windows 版)での情報です。画像はクリックすると拡大します。
やりたいこと
マインカートの積み荷によって、行き先を分岐させたいと思います。また、積み荷を降ろして空になったマインカートに対しては、1 台ごとに別の荷物を積むようにします。
カートは青白い矢印の向きに時計回りに走るものとします。
①のサイロには木材があり、②の井戸からは水が出てきます。従って、カートは木材か水のどちらかを積んだ状態で、(B) の分岐点に来ます。
木材を積んだカートは (B) を上方向に、水を積んだカートは (B) を右方向に進むようにします。
これにより、③の倉庫には木材だけが、④の倉庫には水だけが溜まっていきます。同じ線路を使用していても、積み荷の振り分けが可能となります。
積み荷を倉庫で降ろして空になったカートは、(A) の分岐点に来ます。
(A) では、上方向と右方向を交互に進ませます。これにより、1 台目のカートが木材を積んだら、2 台目のカートは水を積む、というように、2 種類の積み荷を運ぶことができます。
(補足)積み荷の振り分けは、計算ブロックを使わずとも、ソーターやプッシャーでマインカートを押し出すことにより行えます。本記事は計算ブロックの勉強用としてご覧ください。
施設の配置
バリアゲートは物流ブロックの中にあり、設置時は「オフ」になっていて遮断機がおりた状態で通行できませんが、「オン」にすると遮断機が上がって通行できるようになるというブロックです。
サイロと井戸のレールストップは出力、倉庫のレールストップは入力に設定します。
レールの敷設についてですが、(1)-(2)-(3) の分岐部分は、(1)-(2) を先に敷いてから最後に (3) をつなぐようにします。詳しくは、マインカートの記事の「単線運用」節を参考にしてください。
同様に、(1)-(4)-(5) は (4)-(5) が先、(5)-(6)-(7) は (5)-(6) が先、(7)-(8)-(9) は (7)-(9) が先です。
カートは適当な台数(私は 3 台にしました)を、時計回りに走るように配置します。手動でバリアゲートをオンオフして、それぞれの場合でカートが詰まらずに走れるか確認すると良いと思います。
計算ブロックの配置と設定(右側の分岐)
カートの積み荷による分岐を行うには、計算ブロックであるエージェントトリガーを使います。エージェントトリガーは、通過したアイテムによってオンオフを出力するブロックです。
エージェントトリガーを分岐点に上乗せして配置します。簡単のために分岐点に重ねていますが、重ねたくない場合は他の場所に配置しても構いません。ただし、他の場所に配置した場合は、オフセット指定で分岐点を必ず指定して下さい。
エージェントトリガーのアイテムフィルタを「水」にします。
ここまでの設定により、「エージェントトリガーを通過したアイテムが水の場合はオン、そうでないならオフ」という設定がバリアゲートに送られます。バリアゲートはオンの時は通行可能となりますから、結果として、水を積んでいる場合に通行可能となります。カートは直進と左折のどちらもできる分岐に来た場合は直進しますので、直進して (7) の右方向に進みます。
一方で、水を積んでいない場合(木を積んでいるか、または空の場合)はエージェントトリガーがオフになります。バリアゲートはオフの時は通行不可ですから、カートは左折せざるを得ず、(6) の方向に進みます。
結果として、木は上の倉庫に、水は下の倉庫に入ります。
計算ブロックの配置と設定(左側の分岐)
次に左側の分岐(交互に振り分け)の制御を行う計算ブロックの説明をします。(2) から来たカートが (1) か (3) かのどちらかに進む分岐です。

さらに、トグルを付近の適当な場所に設置します。
計算ブロックの設定ですが、左側の分岐では、エージェントトリガーのアイテムフィルタは無しのままにしておきます。こうすると、エージェントトリガーと何かが通過したときに常に信号が発生するようになります。
そして、エージェントトリガーからトグルへ信号を伝送するためにリンクします(エージェントトリガーが送信元、トグルが受け取り先)。
トグルは、何らかの信号が届くたびに、オンとオフが切り替わります。つまり、エージェントトリガーをトロッコが通過する度に、交互にオンとオフになります。
トグルの設定をバリアゲートへ伝送するために、トグルからバリアゲートへリンクします(トグルが送信元、バリアゲートが受け取り先)。
交互にオンオフが送られてくるので、バリアゲートは開いたり閉じたりを繰り返します。
動作結果
ゲーム時間を再開すると、カートが走り出します。
カートが動く様子を動画にしましたので、以下の動画を参照してください。
以上により、マインカートを制御して積み荷を振り分けることができました。
単に積み荷の振り分けということでいえば、計算ブロックに限らずやり方はいくつもあり、先の補足に記したようにソーターなどでも実現可能です。
しかし、計算ブロックでマインカートの制御ができるようになることで、いろいろな夢が広がっていくのではないでしょうか。
生産物流箱庭ゲーム「Factory Town」における計算ブロックの使い方を整理しておきます。前回はごく基礎的な操作方法のまとめでしたが、今回は実用のイメージが湧くかと思います。
次に、センサーの結果を数学ブロックに伝達したいので、センサーと数学ブロックをリンクします。センサーが送信元、数学ブロックが受け取り先なので、インベントリセンサーで左クリックし、数学ブロックで右クリックです(詳しいリンクのやり方は前回を参照して下さい)。
なお、Factory Town Ver 0.108m 時点(Windows 版)での情報です。画像はクリックすると拡大します。
やりたいこと
牧場が肥料を生産してベルトコンベアで流してそれを農場が受け取っている場合、農場であまり肥料が消費されないと、肥料が余ってしまってベルトコンベアが渋滞してしまいます。
ベルトコンベアが渋滞しないようにする方法はいくつかありますが、そのうちの 1 つが、「農場の入力用ストレージにある程度肥料が溜まってきたら、牧場側は肥料を送らないようにする」です。これは計算ブロックで実現できます。
サイロに溜まっている水が 10 個未満の場合のみ、井戸はベルトコンベアに水を放出します。サイロに溜まっている水が 10 個以上になったら、井戸は放出をやめます。
余談ですが、今回もマインカートの時も井戸とサイロを例にしているのは、単に供給が楽というだけで、深い意味はありません。
施設の配置
井戸とサイロをベルトコンベアで結んでいます。井戸からはグラバーで水を引き出し、サイロへはプッシャーで水を押し込みます。サイロの向きはベルトコンベアに向かないようにして下さい。
計算ブロックの配置
建設メニューの計算ブロックの中に、その名も「インベントリセンサー」というセンサーブロックがありますので、それを配置します。
建設メニューの計算ブロックの中に「数学ブロック」という名前のブロックがあるので、それを配置します。ちなみに、数学というほど仰々しいものではありません。ごく簡単に数字を扱うだけのブロックです。
これで役者が出そろいました。
インベントリセンサーで読み取った「サイロにある水の数」という状況を入力として、数学ブロックで「10 個未満かどうか」という判断をしたうえで、井戸のグラバーのオンオフを切り替えるという出力を行います。
計算ブロックの設定
これは、インベントリセンサーが「どこの」在庫の数を調べるかを指定するものです。
アイテムフィルタも設定して明示的に測定対象を指定することも可能ですが、今回は設定しなくても構いません。

数学関数ウィンドウが開き、数学ブロックで行う処理の種類を選べます。今回は「10 個未満かどうか」を判定したいので、「未満」を選びます。
数ウィンドウが開くので、10 を入力します。
今回の設定が表す意味は、「送信元の数値が 10 未満かどうか」ということになります。先ほどのリンクによりサイロの水の数が送信元になっていますので、「サイロの水の数が 10 未満かどうか」を判定できることになります。
条件を満たせば数学ブロックの出力はオン、満たさなければオフになりますので、「サイロの水の数が 10 未満の場合だけオン」が出力されます。
以上により、センサーブロックで測定した「サイロにある水の数」を、数学ブロックで「10 個未満かどうか」判定し、結果を井戸のグラバーに送る、という一連の流れが完成しました。
動作結果
最初はサイロにある水の数はゼロ、つまり 10 個みまんなので、判定結果はオンであり、グラバーが有効な状態になっています。
水が入る度に数学ブロックで 10 個未満かを判定し、結果をグラバーに送るので、伝達を示す青い線が一定間隔で表示されます。
10 個未満の場合は結果は「オン」のままなので、引き続き水は流れていきます。
以降、水が止まります。
以上により、サイロの在庫数に応じた、井戸からの発送調整が実現できました。発送をやめてもベルトコンベアに流れている分があるため、多少のタイムラグがあるので、実際にはこのあたりを工夫する必要が出てくる場合もあるかもしれません。
翔星グループ
月別アーカイブ
記事検索
最新記事
最新コメント
タグクラウド
- ACF
- Android
- AOT
- AQUOSPAD
- ArtisanTD
- ASPNET
- Blazor
- CBuilder
- CSharp
- csv2resw
- FactoryTown
- Fantia
- GPS
- H264
- H265
- HaikuOS
- HANASU
- HDD
- IIJ
- LTE
- MicrosoftStore
- MVNO
- MVVM
- NAS
- Nexus7
- OfLifeAndLand
- PetitKara
- PHP
- RaspberryPi
- SQLite
- SSD
- SymphonyOfWar
- TYPINGMANIA
- USB3
- UTAU
- Vegas
- VisualStudio
- Vue
- Wi-Fi
- WiMAX
- Windows
- Windows10
- Windows10Mobile
- Windows11
- WinUI3
- WPF
- うたりす
- お知らせ
- しゃべって唄詠
- その他無線
- ちょちょいとファイル合併2
- ちょちょいと自動更新
- ちょちょいと自動更新2
- はじまるA列車
- ゆかり
- ゆかりすたー
- ゆかりすたー4
- ゆっこビュー
- ゆっこビュー2
- アニメ
- アンケート
- イベント
- オーディオ
- カラオケ
- カラオケ動画
- ゲーム
- サンプルコード
- サービス
- スピード測定
- セキュリティ
- ソフトウェア
- タブレット
- ニコカラ
- ニコカラりすたー
- ニコカラメーカー
- ニコカラメーカー2
- ニコカラメーカー3
- ネットワーク
- ハードウェア
- プラグイン
- プログラミング
- プログレスバー素材メーカー
- ヘッドセット
- ボーカルカット
- マシンスペックまとめ
- マシンベンチマークまとめ
- ラングリッサー
- ルフランの地下迷宮と魔女ノ旅団
- ルルアのアトリエ
- 動画
- 募集
- 唄詠
- 唄詠2
- 唄詠利用
- 挨拶
- 簡易キーチェンジャー
- 考察
- 開発
- 鼻歌採譜プラグイン