私はaviutlユーザーでニコニコでみゃーまいちゃんのゲーム動画を投稿しているのですが、動画編集する上でいくつか悩んでいる点がありました。

• 編集画面で確認のために動画を流していると、度々エラー表示が起こる。
  →念のために直前のバックアップからプロジェクト保存しなおす手間がかかる。
• 出力中にそこそこの確率で途中で止まってしまう＝出力時の安定感がない。
  →20～30分ほどの動画で出力に一時間前後かかるので終盤のハラハラ感がすごい！（嫌な意味で）
• RAMやCPUなどに余裕はあるのに上記のことが起こったり、全体的にもっさりする感じがするなど安定感が微妙にない。

などのことを感じていました。
　そこで「もし一年近く経った現在のaviutl2周りが安定していたら、ちょっとばかし環境を構築してみるか！」ということを思い立ち、やってみました！
その結果、aviutl時に作っていた動画と同じ基準のモノをほぼ同じやり方で作れるようになりました！
なおかつ、編集時や出力時の安定も◎！（以下の動画はその実験作）

【MTGA】異邦の詩人でトークンをたくさん出して遊ぶ：8【宮舞モカ実況プレイ】

【MTGA】異邦の詩人でトークンをたくさん出して遊ぶ：8【宮舞モカ実況プレイ】 aviutl2での初動画作成＆投稿です！出力が恐ろしく速い・・・気がする！（確実に安定はしているの巻…

www.nicovideo.jp

　というわけで、この記事は自分レベルの編集

• 最低限のPSD立ち絵編集
• 素材投げ込み（動画・音声・画像など）
• x264出力
• 標準的なaviutlの機能

であれば、現状（beta47、2026/6/1時点）でできるよー、ということを伝える記事なのです。
　実際のaviutl2導入に関しての手順は既にネットの海に存在（自分もそれらを参考に）しているので、ここでは自分の所感を伝えていきたいと思います。

現状、導入しているものは？

　ひとまず自分が導入しているものから話していきますね。

• AviUtl ExEdit2 beta47(https://spring-fragrance.mints.ne.jp/aviutl/・・・5/30時点でbeta48が公開済み)
• L-SMASH-Works(https://github.com/Mr-Ojii/L-SMASH-Works-Auto-Builds/releases)
• x264guiEx(https://github.com/rigaya/x264guiEx/releases)
• psdtoolkit2(https://github.com/oov/aviutl2_psdtoolkit2)
• GCMZDrops2_ごちゃまぜドロップス2（https://github.com/oov/aviutl2_gcmzdrops2）
• かんしくん（https://github.com/oov/forcepser）※プラグインではありませんが、ボイロ系動画には欲しいところということで

といったところがほぼ必須なところ。
あとはネットの海を彷徨ったときに見つけたスクリプトを少々。

　aviutl時には音声ソフトからの投げ込み自動化をAoisupportで行っていたので、かんしくんは初導入でした。違いに関してはGUIがあるかないかぐらいで、特に違和感なく使えています。強いて言えばかんしくん内のvoicepeakのfairycall設定で、voicevoxとの出力ショートカットキーの共通化が出来ないことぐらい？あとはvoicepeakでカーソルをしっかり対象のブロックにおいておかないと”1ブロック”の音声に対して、”全文”の字幕がついてしまうこと・・・ですかね。

　発表された当初では本体以外のこれらのプラグインが動作するか、仮に無印版のモノを無理やり使って、いつ不具合が出るかわからなかったので、導入を見送ったという方も多かったと思います。
　少し前から公開されて、更新もされ続けているので、プラグイン全体でそこそこの安定はしているはずです。（本体自体がbetaではあるので、そこはもちろん考慮する必要はありますが）

　あと一応ですが、

AviUtl ExEdit2 テスト版
AviUtlと拡張編集を纏めて新しくゼロから作り直したツールのテスト版です。 Win10以降、DirectX11.3、AVX2が利用出来る環境が必要です。GPUによっては動作しないかもです。 DLLを利用しないスクリプト、入出力プラグインについてはある程度動作するように互換対応しています。

ー AviUtlのお部屋より

テキスト等の各素材に適用していたスクリプト関係であれば、ある程度の使用は可能みたいです。
自分はお試しで入れておくか、というスタンスだったので、大半のスクリプトのお引越しはしていません。

テンプレートは作り直しました！

　無印から一新して作られている（旧aviutlの新バージョンではない）ので、各種設定やレイアウト、動画のテンプレートなどは作り直しました。基本と言えば基本ですし、大体の人はどんな機能があるか見るために一通り触ると思いますが、ものぐさな方は「最初から設定しなおしかぁ」という気持ちになるかもしれないので一応、書いておきますね。

　旧版から一通りの設定を持ってこれたとしても、ズレなどを直すのが面倒と思うので、結局は一から設定をしていたでしょうが・・・。

　設定しているときに眺めていてシンプルにまとまっているGUIだなと思ったので、どれをどこに配置しようか、少しワクワクしていたのは秘密です。

全体的な所感について

　正直、現時点でも大満足！

• 無印よりもレスポンスがいい（編集中に確認のために動画を再生して、度々起きていたエラー表示をしない、全体的なもっさり感がなくなった？）
• 出力が安定＋速い（そこそこの確率で出力中に落ちていた無印版と比べて、圧倒的な安定感と速度を感じています。）
• ボイロ系動画を作るのに最低限のプラグインの2版が公開されている（PSDtoolkit、ごちゃまぜドロップス、入出力プラグインなど）

旧版で自分がやっていたことは基本的にできますし、それにプラスして編集中、出力時の安定性が格段に増したので、旧aviutlを魔改造していて離れたくない・必要がないという人以外は乗り換えていいのかなと思います！（新しく始める人も情報量の違いはありますが、基本的に2の方がいいのかなと）

　懸念というか、少しめんどくさいかもしれないこととしては、本体のaviutl2および、周辺プラグインは絶賛更新中なのでそれに合わせてこちらも更新していかなければならないということぐらいですかね。（正直、めんどくさいの内にも入らないと思いますが・・・）
まぁ、継続的に情報を追っていく必要性があるということですね。

　ということで、参考になるような、ならないような情報かとは思いますが、現時点で乗り換えてもよさそうだということを遅まきながらお伝えする内容でした。

　ここまで見ていただきありがとうございました。
・・・肝心のゲームの話題に触れない当ブログではありますが、多くの人の参考になればなと思います。
それでは、良き動画編集を・・・(/・ω・)/

個人的な活用法の覚書

UTF-○○の部分は○○ビット区切りの扱いであることを覚えておくべし

　Unicode関連のUTF-8,UTF-16,UTF-32についてなのですが、

• UTF-8が１バイト(8ビット)区切りの可変長最大4バイト
  -> つまり文字によって1バイト、2バイトだったり、3バイト、４バイトだったりする。（通常の半角英数などが１バイト、ひらがな・漢字などで3バイトのものがある）
• UTF-16が2バイト(16ビット)区切りの可変長最大4バイト
  -> つまり2バイトか4バイトかのどちらかになるということ。UTF-8との違いとしては英数字なども2バイトとなる。多くの日本語文字も2バイト内に収まるが一部漢字は4バイトになる？
• UTF-32が4バイトの固定長
  -> つまりどんな文字であろうとも基本的に4文字に統一される。
  例外としては複合絵文字（複数の絵文字で一つの絵文字が作られるものなど）などは文字を作るために必要な文字数に応じたバイト数になる？

なので使いたい場所によって使い分けが必要です。

Unicodeのそれぞれの使い分けについて

　Unicodeのサイズについて前述したのですが、正直どう使いこなせばいいかわかんないですよね・・・。そんなわけで簡易的に使いどころをまとめておきます。

• UTF-8
  保存した際のサイズが一番小さくなるはずなので、特に理由が無ければ使うスタンダード。
• UTF-16
  基本的な文字がほぼ2バイト固定なため、文字列全体の大きさが把握しやすいのか、WindowsなどのOSの内部処理で使われることが多い。（widestring的なところ）
• UTF-32
  絵文字は微妙なところだが、基本的な文字は全て4バイトに固定されるため、局所的な例にはなるがゲームなどで文字をウィンドウに表記する際に、
  – 元の文章情報はUTF-8で保存
  – 表示する前段階でUTF-8->UTF-32に変換
  – 4バイト固定なのでstd::u32stringなどの配列に入れて一文字づつ回すことが可能になる
  といったところの使用方法が考えられる。
  この方式の利点としては比較的リソースファイルのサイズを抑えることが出来るという点です。小規模な開発ではあまり効果はないかもしれませんが、大規模なゲームやノベルゲーム系は恩恵を受けやすいかなと思います。

Shift_JIS(SJIS)の利点について

　前記事や前述したUnicodeの内容を見て、「ならばShift_JIS（Unicode外）の存在意義・活用場所はどこにあるんだろう」と考えると思うのですが、Unicodeとの比較でShift_JISを使う意義を見ていきたいと思います。

日本語中心のテキストではUTF-8よりもファイルサイズが小さくなる。

　Shift_JISは英数・記号・半角カタカナなどの半角文字が1バイト、通常の日本語表記のひらがな・カタカナ・漢字などが2バイトの表記であらわされる可変長文字コード 。
-> つまり最大で一文字あたり2バイト。例として全角”Ａ”は2バイト、半角”A”は1バイト
そのため漢字などが一文字あたり3バイト（文字によっては4バイト）ほどになってしまうUnicodeよりもファイルサイズが小さくなる傾向にあります。

日本語環境のレガシーシステムやプログラム資産を使うときに必要になるかも？

　会社所属などで古くに書かれたコードなどを参照しようとしたときに文字列入力や使用する文字列引数の値として想定されていることが多いかも？
いずれにせよ、現代の新規プロジェクトで全体をShift_JISエンコードする必要はなく、一部でUnicode文字列などを変換して使用する仕様でいい気がしますね・・・。

文字関係の問題に悩む人の一助になればと思います。どうぞ。

この記事では、Visual Studio の「Unicode / マルチバイト文字セット」と、C++ の文字型・文字列リテラル（プレフィックス）・エンコーディングが、どう噛み合っているのかを整理します。

1. 「Unicode文字」と「マルチバイト文字」の説明（Visual Studio の設定）

Unicode文字セット

Windows API を含む多くの現代的な Windows 開発で標準的な設定です。内部的には「ワイド文字（wchar_t）」を使う流儀になり、Win32 API も基本的に ...W（Wide）側を使うことになります。

マルチバイト文字セット

いわゆる「ANSI（A）」系APIや、Shift-JIS/CP932 前提の資産に寄せた設定です。TCHAR が char 側に寄り、文字列が OS のコードページ（日本語Windowsなら CP932）依存になりやすくなります。

2. C++ における文字型の解説（型ごと）

char

1バイトの文字型です。std::string の要素型でもあり、実務では「文字」よりも「バイト列の器」として使われることが多いです。中身が UTF-8 なのか Shift-JIS なのかは運用ルール次第です。

signed char / unsigned char

同じく1バイトですが、符号付き/符号なしが明確です。バイナリ処理やバイト配列として扱いたいときに便利で、文字コード用途というより「生のデータ」用途で登場します。

wchar_t

ワイド文字型です。Windows では多くの場合 16bit（UTF-16 のコードユニットとして運用されがち）で、Win32 API（W系）との相性が良いです。ただし規格上「必ずUTF-16」という保証ではありません。

char16_t

16bit固定の文字型で、UTF-16 のコードユニット列を表現するための型です。プラットフォーム差が少なく、UTF-16 を明示したいときに使います。

char32_t

32bit固定の文字型で、UTF-32 を表現するための型です。コードポイント単位の処理がしやすい反面、サイズは大きめです。

char8_t（C++20）

UTF-8 用の文字型です。u8"..." リテラルの型が char8_t[] になり、std::u8string との親和性が高いです。一方で std::string（char）と混ぜると型変換が必要になることがあります。

3. 文字列リテラルのプレフィックス（例つき）

C++ の「プレフィックス」は、主に“リテラルの型”を変えます（Shift-JISなど特定コードページを直接指定する機能ではありません）。

• "text"：const char[]
• L"text"：const wchar_t[]
• u8"text"：const char8_t[]（C++20以降）
• u"text"：const char16_t[]
• U"text"：const char32_t[]

また、Raw文字列（エスケープを気にしない）も組み合わせ可能です：

• R"(C:\path\file.txt)"
• u8R"(改行\nもそのまま)"

4. それぞれがどう関係しているか（混乱ポイントの整理）

ここが一番大事です。

4-1. 「Visual Studioの文字セット」は何を変える？

Visual Studio の「Unicode / マルチバイト文字セット」は、主に Windows API 呼び出しや TCHAR 系の挙動に影響します。

• Unicode文字セット：TCHAR → wchar_t、MessageBox → MessageBoxW のように Wide 側へ寄る
• マルチバイト文字セット：TCHAR → char、MessageBox → MessageBoxA のように ANSI 側へ寄る

4-2. 「ソースコードの保存形式（UTF-8など）」は別レイヤ

.cpp/.h を UTF-8（BOMなし）で保存し、/utf-8 を付けるのは、コンパイラがソースや文字リテラルをどう解釈するかに影響します。

つまり、

• 文字セット（Unicode/マルチバイト）＝ “実行時の文字列型やAPI側の方針”
• ソースの文字コード（UTF-8など）＝ “ソースをどう読むか”

この2つは別物なので、混ぜると「どっちの話だっけ？」となりやすいです。

4-3. Shift-JIS はプレフィックスでは作れない

L"" や u8"" は Unicode系のリテラルを作る仕組みです。Shift-JIS（CP932）は型ではなくコードページ変換の結果なので、必要な場合は 変換関数で std::string（バイト列）として生成するのが一般的です。

5. どういう条件で使い分けるべきか（おすすめ運用）

5-1. Windows中心・今後も育てるプロジェクト（おすすめ）

• Visual Studio：Unicode文字セット
• ソース：UTF-8（BOMなし） + /utf-8
• 方針：普段は std::string を UTF-8 として運用し、Windows API境界だけ std::wstring（UTF-16相当）へ変換

この運用は、教材的な std::string の感覚を残しつつ、Unicodeにも強くできます。

5-2. レガシー資産が Shift-JIS 前提で、短期で動かしたい

• 既存のSJISテキスト（CSV/辞書/台詞）が大量にある
• 古いツールや資産がSJIS前提

この場合でも「全体SJIS化」より、

• I/O（読み込み/書き出し）だけSJIS
• 内部はUTF-8/UTF-16へ寄せる
  の方が事故が少ないことが多いです。

5-3. ゲームで「1文字ずつ表示」などをしたい場合

UTF-8の std::string を使う場合、1バイト=1文字 ではないため、

• UTF-8をデコードして「コードポイント」単位で進める（軽量）
• さらに厳密にやるなら「グラフェム境界」（ICUなど）で進める
  といった方針が必要です。

最短まとめ（迷ったらこれ）

• Unicode文字セットを選ぶ（Windows開発の基本）
• ソースは **UTF-8（BOMなし）**で統一し、必要なら /utf-8
• std::string は “UTF-8の器” と割り切って使う
• Windows APIやファイルパスなど OS 境界だけ std::wstring に変換する
• Shift-JIS は「プレフィックス」ではなく「変換で必要なときだけ作る」

付録：Visual Studioで「新規/保存ファイルの既定エンコーディング」をUTF-8（BOMなし）にする方法

Visual Studioでは、ファイルの既定保存エンコーディングを指定できます。Visual Studio 2022 v17.13以降では、IDEの設定として「既定の保存エンコーディング」を明示的に選べます。

方法A：Visual Studioのオプションで既定エンコーディングを指定（VS 2022 v17.13以降）

1. Tools（ツール）> Options（オプション） を開く
2. Environment（環境）> Documents（ドキュメント） を開く
3. Save files with a specific encoding（特定のエンコーディングで保存）をオン
4. Save encoding（保存エンコーディング）で UTF-8 without signature（UTF-8 BOMなし）を選ぶ
5. OKで確定

この設定を入れると、以後の保存で指定したエンコーディングに揃いやすくなります。

補足：Microsoft Learn側でも同じ項目（Environment > Documents で “Save files with a specific encoding” を有効化して “Save encoding” を選ぶ）として案内されています。

方法B：プロジェクト単位で強制する（.editorconfig を使う）

IDEの個人設定ではなく、リポジトリ/プロジェクトのルールとして固定したい場合は .editorconfig が便利です。Visual StudioはEditorConfigをサポートしており、charset = utf-8 を指定できます。

例：プロジェクト直下に .editorconfig を作成

root = true

[*.{h,hpp,cpp,cxx,cc,inl,ipp}]
charset = utf-8

• charset = utf-8 は通常 UTF-8（BOMなし） の意図になります。
• BOMありにしたい場合は utf-8-bom を使う、という指定も可能です。

うまく設定できたか確認する方法

既存/新規ファイルを開いた状態で、Visual Studioの「エンコーディング指定で保存（Save with Encoding）」から、意図したエンコーディングになっているか確認できます（UTF-8 without signature など）。

　今回は「最初の設定に時間がとられることを無くして実際の作業に集中できる」ように、また「新しいプロジェクトを作ることを設定のめんどくささで忌避しないようにする」ことを目的として、自分がよく使うゲームプロジェクト＆C++向けの設定を備忘録として残しておきたいと思います。それではどうぞ。

ゲームプロジェクト向けVS設定手順

VisualStudioにて新規にプロジェクトを始める手順

１．VisualStudioのスタートウィンドウにて”新しいプロジェクトの作成”を選択

２．”デスクトップウィザード”のテンプレートを選択・・・フィルターでC++を選んでいるとわかりやすい（※フレームワークの作成であれば”スタティックライブラリを選択）

３．任意のディレクトリを指定（項目の一番下にあるソリューションとプロジェクトのディレクトリ配置については小規模・実験的であれば同じでもいいが、規模がそれなりになる予定または未定であればチェックは外しておいた方が無難・・・ほぼ好み）

４．その後、新しいウィンドウで”デスクトップアプリケーション”＆下の”空のプロジェクト”のチェックボックスをチェック

ここまででプロジェクトの作成は完了なので、ここからはプロジェクト内の設定をしていきます。

プロジェクトを作った後のVisualStudioの設定

※1/31手順を修正・追記

※４番までプロジェクトのプロパティ設定内で作業します。

１．プロジェクトのプロパティ設定→全般：C++言語標準を自分の使いたいバージョンに設定（C++14とかC++20とか）
->コンパイラがどのバージョンでコードを読むかを決めるとこ？

２．詳細：文字セットの変更（特に指定が無ければUnicode文字のままでよい？）
ここに関しては後日、文字コードに関しての記事を投稿予定です。

３．C/C++→全般＆リンカー→全般：それぞれ追加のインクルードディレクトリ・追加のライブラリディレクトリに使用する外部ライブラリ＆自作フレームワークのパス（こちらはインクルードディレクトリのみでOK）を追加(もしvcpkgをユーザーにintegrateしていなかった場合はこちらにパスをいれるか、マニフェストファイル的なものを作る方法にした方が良いかも)

４．C/C++→コード生成：ランタイムライブラリを構成（プロパティウィンドウ左上のDebug/Release）に対して、それぞれ（マルチスレッド　デバッグ（/MTd）/マルチスレッド（MT））を設定する。

５．プロパティを閉じて左上の”ファイル”から”追加”→”既存のプロジェクト”で
随時更新予定の自作のライブラリのプロジェクトを選択

6.メイン側のプロジェクトを右クリックしたあと
・追加→参照のところで自作ライブラリの参照にチェック
・ビルドの依存関係→プロジェクトの依存関係から自作ライブラリをチェック
の二つをこなして設定完了

ここまでで設定は完了！コーディングを始めましょう！

最後に

　以上が大体の設定です。
あとは保存ファイルの文字エンコードをどれにするかとかgit関連の設定などは残ってはいますけど、個人的にはこれら＋既存ライブラリの導入を行っていれば、小規模・個人レベルでのゲーム開発環境としては十分かと思います。
これを基にして、各々が快適な設定を見つけてもらえればと思います。

　普段、WindowsなどのアイコンなどでのGUI操作に慣れていて、
「CLI、コマンド操作ってなんだよ・・・。なんでわかりにくいものを使うの？」
といった人にCLIを使う理由が少しでも伝わればいいなと思います。
（CLIを使いたいと考えている人に対しては全部をCLIで操作せよ！ではなく、適材適所、使いやすい場面があることを知ってもらいたいな・・・という感じです。）

　それではどうぞ。

CLIってなんか頭に入ってこないんだよね・・・という人へ

そもそもGUI・CUIって何？（一応ね・・・）

　この記事を読んでいただいている時点で、この辺の区別はわかるとは思いますが、一応の概要をば。

• GUI（グラフィカルユーザーインターフェースの略称）
  ‐普段使っているWindowsやMacにおける、アイコンや特定領域をポインティングデバイス（マウスやタッチパッドなど）で”クリックやドラッグ操作”することによってレスポンス（操作の結果）を得るUIのこと。
• CLI（コマンドラインインターフェースの略称）
  ‐コマンドプロンプトやWindowsPowerShell、ターミナル（Linux、Mac）のように特定のコマンドによってディレクトリやファイルなどの操作を行うインターフェースのこと。
  似たような言葉にCUI（キャラクターユーザーインターフェース）があるが、そちらは英語圏的にはTUI（テキストベースドユーザーインターフェース）の方が近いみたいですね。
  （つまりCLI≠CUI、CUI≒TUIみたいです。）

GUIに染まっている人がなぜCLIを敬遠するのか？

　私も長年、GUI（Windows）に浸かっていたのですが、プログラミングを勉強するとなると否が応にもCLIに触れなければならない場面が出てくると思うんですよね・・・。正直、そんな場面でコピペしたコマンドを使っててもピンと来てなかったのですが、ピンとこない理由って大体この辺だと思うんですよね。

• CLIという概念が分からない
  ↳子供のころからGUI環境に慣れ親しみ過ぎた
• CLIの種類がよくわからない
• コマンドの種類が分からない・アイコンを右クリックしたときのような選択肢の可視化がない
• ディレクトリの位置が把握しきれない・ディレクトリの構造なんて覚えてらんない

　順に追っていきますと、最初はシンプルにCLIってなんやねんが来ると思うんですよ。
アイコンをクリックしてを繰り返していると、「えっ、コマンドで操作って、文字で操作ってどうやるの・・・？」って感じでそもそも想像できないんですよね。もうパソコンといえば子供のころから学校の授業含めWindowsのGUI環境だったので、キーボードが文章入力程度の役割にしかなってなかったんですよね。（Windows以前のMS-DOSとかが全盛期だったころは違うんでしょうが・・・）

　次にCLIの種類が意味わかんないっていうところっすかね。同じWindowsでもコマンドプロンプト、PowerShellがあって「どっち使えばいいの・・・？」って初心者はなると思うんですよね。（実際にはコマンドプロンプトでできることはPowerShellでできるはず・・・だよね？）
さらには各ソフトウェア内にもコマンドがあって特有のCLI、コマンド操作が必要になったらさらに頭が混乱するわけですよ。

　そしてなにより、コマンドが分からない！
これに関しては検索して調べればいいんですけど・・・でもCLIを使わない人がいちいちコマンドを検索してまでCLIを使うかな？となっちゃうのでそれなりに目的意識、CLIを使う必然性が求められるようになっちゃうんですよね・・・。そしてそれが初心者にはハードルになると。
そしてそれに通じて、GUIにてアイコンを右クリックしたときのような操作の選択肢の可視化がないのも違う点ですよね。GUIが可能な操作を表示するのに対して、CLIは自分でしたい操作を明示しなければならないという点ですね・・・。

　最後のディレクトリ構造の把握については、慣れている人は全部を把握している（頭の中にある）人もいるのかもしれないですけど、GUIで操作していたら同階層のディレクトリは覚えていなくても表示されるので、あまり覚えきっている人は少ないのではないかなと・・・。（ある程度、どのあたりにあるか分かればいい。）
ゆえにいざコマンドで操作するとなった時に、半角英数でスペル間違ってないかなと思いながら（あるいは実際のディレクトリを確認しながら）、ディレクトリ名を入力しないといけないわけで、そこも少し馴染みにくいところなのかなと。

それならばGUIに慣れた人にとって、CLIを使う必然性は？

　先の話題を受けて、「こんだけめんどくさいんだったら使わなくてよくない？」と思うことでしょう。実際、必要に迫られなければ使わなくていいと思います。通常の資料づくり（ExcelやWordなど）、アプリケーション（ゲームや既成のソフトウェア）、ブラウザ（YouTube、ウェブサイト閲覧など）などの使用であれば基本的に使用する必要はないと思います。

　ではどこで必要になるかと言えば、”スクリプトによる特定操作手順のマクロ化”や”プログラミング周りの環境整備”、”サーバー関係”、”特定のOS環境”によるというところがパッと思いつくところですかね。
自分も最初に述べたようにそこまでコマンド操作に対する解像度が高いわけではないのですが、特定の操作を必要とする業務であればバッチファイルで特定の操作を行うスクリプトを作成して日々の操作を自動化できますし、プログラミングの環境（コンパイラやパッケージマネージャ等）の導入手順としてコマンド操作で行う方が便利だったりします。
特定のOS環境については特にLinuxになるのですが、LinuxはデスクトップOSとしてWindowsやMacと並ぶこともありますが、サーバー用途としてのシェア率が高いのは周知のことですよね？
サーバー用のGUIなどもあるのかもしれませんが、サーバー管理をする人って大体PCの扱いに熟達していますよね。であればコマンド操作で事足りるのにわざわざGUIを開発するコストをかける必要性はなかったということですね。（コマンド操作全盛期からそれだけでやってこれた＆受け継いできた、セキュリティの問題から汎用的なGUIが入りえなかった？のかもしれませんね）

　というわけで比較的フレッシュな人がコマンド操作を使うことになる必然性としては

• Linux系デスクトップOSもしくはサーバーでやりたいことがある
• 新しいプログラミング言語を学びたい（環境が欲しい）
• 特定作業の効率化・自動化

なのかな・・・？
自分がこういうところに魅力を感じたなと思っただけなので、人によって入口にしたいところは全然違うとは思いますが・・・。（なにはともあれ、興味が湧いたら飛び込んでみよう！！！）

じゃあ、これを入口にしてみたらどうかな？という提案

　それでは上記の必然性を考えて、コマンド操作を取り入れる実際の行動、”入口”的なものを考えてみましょうか。
なぜかというと「世の中、堅苦しくて理解が苦しくなる記事があふれてますけど、気楽に入れてみればいいんです・・・」というと「何かでつまって使わなくなってストレージの片隅に放置」という流れになるのであまり気楽にいえないんですよね・・・。（私も数多くの経験あり・・・）
なので一応の入り口は提示しておこうかな・・・ということです。

　まず一つ目の提案が
CLIを使うのはディレクトリの構造を把握できる小規模なフォルダから始めてみては？
ということ。
↳苦手意識を持つ人（筆者の体験）は初めからルートディレクトリ含めて全体の管理をしようとして、ディレクトリ構造が把握できず”どこに何をおいてあるのか”が分からなくなってしまうというのがあると思うんですよね。
広すぎて把握しきれてないディレクトリを頑張って操作しようとするので
“cdコマンドなどのディレクトリ移動・操作系のコマンドで操作するよりGUIでディレクトリの中身を確認しながら操作したほうが早いんじゃね”
という思考になるんじゃないかなと。

　そして二つ目が
ディレクトリの数が少ないであろう新規に使い始めるPC（OS）
または新規のプログラミングプロジェクトのディレクトリ管理で心機一転使い始める
ってところですかね。
↳上記と言っていることはほぼ同じですけど、こちらは”新しく始める”といったタイミングの問題ですかね。個人的な体験ですが、Linux（Ubuntu）の使い始めから積極的にCLIを使い始めたのですが、余分なファイルがない（デフォルトのファイルしかない）分、ディレクトリ配置が複雑化していないのでコマンド操作が使いやすかった感覚はたしかにあったのでそういった環境の変更時に触り始めるのも一手な気がする。

　最後にこれは心得的な話なのですが、
コマンドのチートシートを見ながらで全然いいのよ・・・！
というところですね。
↳人間は習慣化していないことは覚えてられないに決まっていますから、最初・・・というかずっとでもいいからコマンドのチートシートを見ながら操作でいいのよ・・・！という心構えで行きましょう。日々の積み重ねが大事なのです。

個人的に思う入口として入りやすいところはこんなところですかね・・・。

最後に

　うーーーん、あまり初心者を後押し・参考にできるような記事になったかは微妙なところかもと思っちゃいますね・・・。あくまで私の体験を書いて同じような気持ちを抱いている人の一助・一歩踏み出す気になれればなという気持ちで書いた記事なので、内容薄いかもしれないです、ごめんなさい。

　それでもコマンドを使い始めて、なんか作業が楽しく進められるようになったんですよね。というよりもある日を境に寝て起きたら、なんかコマンド操作の概念がスッと頭に入ってきたんですよ・・・。
なのでなにかに詰まって、「うおぉぉ、何もわかんねぇ」ってなった時は

寝るのが一番

です。
そんな時間は無ぇという方が多くいらっしゃると思いますが、個人的な体感としては一番解決率が高い気がします。（寝ずに頭をひねるよりは）
というわけでここまでのご精読ありがとうございました。

　最近のWindowsアップデートについていけないスペックの
ノートPCはどうしたらいいんだ・・・！！！

　そんなことを思ったことはありませんでしょうか・・・？
私めは長年Windowsユーザーなのですが、昨今、Windows11やらAI搭載やらPCがどんどん重く（ストレージ的にもメモリ的にも）なってきましたよね。そういうわけでスペックの高いノートPCを買おうとするも価格の高騰に2026年初頭（どころかこれからも上がるみたいっすね・・・）巻き込まれているわけですが・・・。
それならばと古いノートPCを再利用するのはどうかということで、データを抜いてしばらく起動していなかったNECのLAVIEを引っ張り出しました。

学生時代からかれこれ10年近く使っていたノートPCなのですが、Windows10で動作が爆重になり、Windows11へのアップデートではついにスペックの時点ではじかれるようになってしまいました・・・。
そういったことで使わなくなって眠ることとなっていたのですが、なんとかこの遺物を活かしたいなと思いたったのです。

　そんなわけで最近気になっていたLinuxディストリビューションであるUbuntuの派生、Ubuntu MATEを入れるついでに分解・清掃、メモリの増設までやっちゃいました。
その過程をお届けしたいと思います。

古いPC活用のすゝめ

準備するもの

　それでは今回使ったものの紹介から始めましょう。

• 古いノートパソコン（私のはNEC・LAVIE-pc-gn234hsa7）
  ↳スペックとしてはcore-i5-6200U + RAM8GB + HDD1TB
• 追加用の中古RAM（8GB・PC3L‐12800S）
• USBメモリ（今回は32GBを使用したが、8GBあれば足りる？と思います。）
• ピンセット
• ドライバーセット
• 綿棒

ぐらいですかね。
注意点としてはUSBメモリはフォーマットして書き込むので中身のデータを他の安全なストレージに移してから作業しましょう。ということと、後に説明しますが、RAMの規格や相性問題もあるので次善策や諦めることも視野に入れて気を落とさずにいきましょう！

UbuntuMATEをインストール（元のWindowsとおさらば！）

　当初、Linux系OSを入れて動かそうぐらいしか考えていなかったので、内部のクリーニングまで考えていませんでした。なので先にUbuntuMATEのインストールとなっております。
クリーニングを元から考えているなら、そちらを先にした方が絶対いいです。なぜなら分解した後の組み立て不備なのか、OSのインストールミスやハードウェアとの相性なのか問題の切り分けが難しくなるからです。少なくとも組み立て後に以前の環境（OS）で起動まで出来るのであれば、分解による不良は考えにくくなるからですね（それでも安心できませんが・・・）。

ちなみに数あるLinuxディストリビューション¹の中でUbuntuMATEを選択した理由を簡潔に書くと以下のようになります。

• Linux系初心者なのでGUIは流石に欲しい
• そのうえでトラブルシューティングができるように比較的情報が出そろっているディストリがいいなぁ→Ubuntu系かなと思い始める
• その中でも8GBメモリでも快適に動く軽量なものが良いな・・・
• 使用用途としてはLinuxの実験機的なものを期待して、サーバー実験やLinux環境でのSteamはどれぐらいできるかなどのお試しをしたいっすね。

この条件でChatGPTに投げた結果、UbuntuMATEに決定したわけです。
しかしながらメモリ増設を考えたのが、後のクリーニングを思い立ってからなので、それを加味したら通常のUbuntuでも良かったなと思いました。

というわけで手順に関してはまるっきり他のサイトを参考にしたので貼っておきますね。（お世話になりました<m(__)m>）
後に個人的な注意点だけ。

【備忘録】古いWindowsノートPCにUbuntuをインストールして快適に動作させようの回｜イツキ

◆はじめに 　大学入学の時に買わされたノートPCが、もう流石に動かない。いや、動きはするけど、基本的に動作が重いし、もっさりする。加えてトラックパッドが死んでいる。 　買い替えようかなぁと思ったけど、Switch2が欲しくてお金を避けている...

note.com

あと肝心のUbuntuMATEのダウンロードサイトについては

Download | Ubuntu MATE

A community developed, Ubuntu based operating system that beautifully integrates the MATE desktop. Ubuntu MATE is a stab...

ubuntu-mate.org

ある意味、追実験的な感じになりましたね。
ほぼ書かれてる通り、まんまで実行できたので非常にありがたかったです。
注意点としては

• UbuntuMATEは複数同じサイトに公開されてますが、最新の安定版と比較的長期の安定版があるので、特に最新版にこだわらない限りは”supported until ~(期限)”が長いものを選んだ方がいいと思います。
• steamに関しては自分は公式サイトのdevパッケージをダウンロードしてきました。
• その他の導入後のアップデート、日本語設定、セキュリティ設定はお好みに。
  （よくわからなかったら検索する他、ChatGPTとかに投げてもいいかも）
  特に導入直後の言語設定が反映されていなかった場合は左上のメニュー内の検索窓に「language support」を入力して、日本語に設定して再起動すれば日本語になるはずです。

そして諸々設定を終えた結果・・・

無事、起動！！！

動作も、もはやPCの体をなしていなかった以前と違い、サクサクで感激っす！
（この後、VisualStudioCode²やGIMP³もインストールしました）

PCの分解・キーボードの清掃

　正直、ここまででお腹いっぱいという方が大半だと思いますが、ソフトウェアの次はハードウェアの問題があるんですね・・・。
元からなんですけど、このPC・・・キーボードの効きが悪い問題も抱えてるんですよ・・・。

となれば、分解・清掃のお時間だということで以下のサイトを参考に頑張って分解しました。

NEC LAVIE GN234F/S8 キーボード 交換ガイド（動画） ｜GN234F/S8・PC-GN234FSA8

今回は、NEC LAVIE GN234F/S8のキーボード交換手順を動画で解説致します。 ※症状を悪化させたり、破損のリスクがございます。NEC LAVIE

pc-jiten.com

ノートPCの薄いキーキャップの外し方【お手入れレポート】 - Qiita

はじめに 私はこれまで、マイPC（MSI Prestige-15）にコーヒーを2回溢しており（ごめんね）、そのせいで、Enterキーあたりのキーの押し心地がヌッタリしてしまっています。 気になるので、掃除したかったのですが、ドンピシャサイト...

qiita.com

個人的にはピンセットの方を回すと、キーキャップは外しやすかったですね。

　内部は思っていたよりも埃が積もっておらず、ササっと拭きとるぐらいで済みました。

ところが流石にキーボードは細かいチリや毛が詰まっていましたね・・・。
キーキャップもコツコツ外した甲斐がありましたよ。ついでに言うならラバードームも外して接点復活なりなんなり、吹いた方がよかったと思うのですが流石にやる気が起きなかったですね・・・（わざわざ瞬接使って、付け直さなきゃいけないのが・・・ね）。

結果としてここまでやれればいいかなというラインまでやったので、少なくとも見た目は綺麗になりました。（キーボードの効きは変わらなかったです・・・。）

RAMの増設：8GB→16GBへ

　その後ある程度まで組みなおしまして、メモリの増設へ。
ストレージもSSD換装したかったんですけど、流石にお金がかかりすぎるので保留です。

そして肝心のメモリですが、型番としては”PC3L‐12800S”⁴というものだったのですが、基本的に同じ型番が安定なので中古ショップで探してきました。メーカーまでは同じものをそろえられなかったので相性問題を考慮して、予備含め2枚買いました。（1100円×2＝2200円）

マウントが出来たらあとは実際に認識されているか確認しましょう！

最後に

　Linux系OSはサーバー用途として、比較的なじみ深いOSでコマンド操作が非常に楽しいです。初めてデスクトップ（Windows）からssh接続して、コマンド操作したんですけど、未体験の領域でした・・・！（下記の画像は別の作業中ですが・・・。）

　なので、既存の古いパソコンをスペックアップして活用するのもそうですが、これを機にコマンド操作という新たな領域に踏み込むのもまた”すゝめ”たいです！
昨今の価格高騰で悩んでいる皆様の一つの選択肢となり得るかもしれませんぞ！ということを期待して、今回は終わりたいと思います。(‘ω’)ノ

1. Linuxカーネルを基に、各種ツールや環境を組み合わせて作られたOS（ディストリビューション）の総称。UbuntuやDebianなどがあり、今回のUbuntu MATEはUbuntuの派生ディストリビューションにあたる。簡単なLinuxについての解説→https://qiita.com/uguis410/items/17ec1e447e9716bfdca7 ↩︎
2. Microsoft製のプログラムエディタ。軽量なのでプログラムを始める最初の環境としてもおススメ。 ↩︎
3. 画像編集ソフト。結構な多機能を無料で使えるすごいソフト（小並感の筆者視点）。 ↩︎
4. 私も今回調べたのですが、型番の意味としてはPC3L（DDR3のLaw：通常1.5V・Law版1.35V）‐12800S（最後のsはS.O.DIMM、ノートパソコン用の短いメモリ）ということらしいっすね。型番丸々同じに書かれていないものもありました。（PC3-12800　S.O.DIMM　1.35Vのように分割して記載してあるみたいな） ↩︎

ということで少し前に動画投稿を始めたので、その時に自分が少し詰まったところについてのトラブルシューティングです。OBSの録画環境編です。
据え置き機のゲーム系の録画+プレイ画面としてキャプチャしているのですが、時々OBSに画面が映らなかったり、音が出なかったり・・・。（PCでプレイしているものは問題ないのですが・・・。）

　他のサイトでもそういったQAは多くみるのですが、一覧的に当てはまらないものも載っているので、問題が起こるたびに該当箇所を参照するのがめんどくさいんですよね・・。
なので自分がよくあてはまる解決方法について絞って残しておこうかなと。
そういったわけで、そんなときに確認したいところについて書いていこうと思います。

OBSで画面が映らない、音が出ない時は？

現在の環境

　自分の録画環境兼据え置きゲーム機のプレイ環境についてさらっと。

• HDMIキャプチャーボード（USB接続）
• コンポーネント→HDMI変換（PS2やWii用、上記キャプチャボードに接続）
• OBS Studio(キャプチャー・録画ソフト)

見てわかる通りコンポーネント端子のゲーム機は間に2つデバイスをかますので遅延がキツイかと思いきや、割とプレイできなくはないぐらいの遅延で済んでるのでギリギリ何とかなってます。
PCに内蔵できるタイプのキャプチャーボードを買いたいんですけど、結構高いんですよね・・・。

OBSのシーンを削除して、再起動→再度、キャプチャ用のシーン作成

　それでは本題。
まずは画面自体が映らないことに関してですが、これは大体、シンプルな解決策で終わります。

1. キャプチャーボードの画面を出力しているシーンを削除
2. OBSを落とす
3. キャプチャーボードを接続しなおす
4. OBSを開く
5. シーンを作成しなおす

画面が映らない系の問題はこの手順で大体解決した気がします。

映像キャプチャデバイスのプロパティを確認する

　ここからは音声が出ない問題に関してになります。
まずはキャプチャしているシーン内の映像キャプチャデバイスのプロパティの確認ですね。
ほいで、ここのカラーバーが出てない場合はそもそも映像が出てないので、上の画面修正に戻ります。
そしてスクロールが途中で詰まるので、しっかり横のスクロールバーの位置を確認しましょう。
下までいって音声に関する設定をいじいじしてみましょう。（個人的には現状、これで安定中）

あとは音声ミキサー左下（上記画像中央下）の歯車マークから見れる詳細プロパティの音声モニタリングをモニターと出力に変えてみたりして確認してみましょう。

マイクへのアクセスを確認する（Windowsの設定）

　そしてこの前ひっかかった要因がこれ。

Windowsの設定から「プライバシーとセキュリティ」→「マイク」の中のこれらの設定をONにしないと音声が入らなかったんですよね。
一律で何かあった時のためにと切っておいたのですが、まさかキャプチャの音声入力までできなくなるとは思ってもみませんでした・・・。

これらで解決しなかったら、一覧から原因を探り当てましょう・・・。

　大体、個人的にはこれらで何とかなっているので、直らなかった場合は原因がつらつらと並んでいるサイトから探すしかないでしょうね・・・。
なるべく早く解決できるように日ごろからトラブルシューティング能力を鍛えていかねば・・・！
ということで備忘録なので自分の困ったことに対処するためのメモ書きでした。
これをみているだれかの助けにならんことを・・・。

私自身の挫折（読み飛ばして構いません）

※この項はこの記事を書くに至った筆者の体験です。個人ブログなので多少はね・・・。

　私は過去に一度プログラミングを学ぼうとして挫折したんですよね。
というのを思い出したのがこの記事の発端です。ゲームが好きでゲームを作りたかったんですよね。
その時に様々な言語の選択肢を見て、「どれを学べばいいんだ・・・？」となってしまいました。
それでもひとまずどれでもいいからかじってみようと思い立ち、初心者向けの参考書を複数言語買って挑戦し始めました。（C++、C#、Pythonあたりだったんですかね・・・。）
初学者には環境構築も一苦労。やっとこさコードを書き始めたのですが、そこで気づきました。
なんかやってること同じじゃない・・・？
多少の記法の違いはあれど書いてあることが、変数、関数の説明に始まり、for文や配列の解説など共通の基礎の基礎部分だったんですよね（当たり前なのですが・・・）。
結局、言語でなにが違うんだっていうことに気づけず、しばらく離れてしまったんですよね。
コラムなりなんなりでどういった用途に多く使われているとか触れていてほしかったなぁ・・・と。

　そういったことで、学び始めるにあたって、なぜこの言語が使われているのか、要因に触れられている解説が薄い気がするんですよね・・・。
検索すればもちろん出てきますが、普段多少なりともプログラミング関連の記事や動画を見たりしますが、この内容について深く掘り下げているものがあまり浮上してこない気がするんですよね（個人的な体感に基づく）。
そのためなるたけそういった用途、使われている理由に重点を置いて今回書かせていただきます。
（歴史的な部分はあまり書かないと思います・・・。）
また全ての言語は網羅できないので、書いていない言語に関しては、この記事を見て、どの要素に当てはまるのかご自身で調べて確認していただければと思います。

大まかな要素について

　それでは本題に入りましょう！
最初にプログラミング言語を工具などと変わらない道具として見てみてください。
道具というのは使いたい場面によって最適化されています。例えば、同じハンマー・トンカチの形をした工具でも用途によって槌の部分の材質が違います（金属製はもちろん、傷つけない為にゴム製のものも存在しますよね）。つまりやりたいことに対する”必要性”があって道具は作られているわけですよね。プログラミング言語も同じです。
　特定の共通の決まり事の上で動作するものを作りたかったから、簡単にして効率よくしたかったからなど、そんな理由です。であるからこそ変数などの共通事項以外で得意なこと（目指していたこと）が出来てきます。なので言語の成り立ち・過程を知るということは、言語の得意なことを知るということにもつながってくると言えるんじゃないでしょうか？個別の事例を見てちょっとこの考えについて深めていきましょう。
最初はカジュアルでわかりやすいものから。

より便利な機能を増やしたい（今の言語にない機能を増やしたい）

　言語を始めてみて最初に皆さん、C言語,C++,C#って何が違うの？って一度は思ったと思うんですよね。実際、ほぼ縦のつながりどころか、C++に至ってはC言語を包括¹（C++の中にC言語の書き方で書いてもなんの問題もない）しています。C言語に付け足したかったものをC++（テンプレート、クラス、オブジェクト指向等）で、C++に付け足したかったものをC#²（OSが違う環境でも差異を吸収して動作するように＝.netフレームワーク、GUI開発環境等）で必要になったものを追加していったわけですね。
　そこで一つ疑問が湧くと思います。必要になったものを追加した後発の言語を使えばいいじゃん、古いC言語とかは使わなくていいじゃん、と。残念ながらそうはいかないのです。

ではなぜC言語は未だに使われるのか？（残っているのか？）

　便利な機能を追加した裏には切り捨てられた要素があるからです。C/C++とC#で言えばメモリ安全性³の代わりにメモリ操作の自由を無くしました。これがどういったことかというとC/C++では自身でメモリを操作して効率的な（実行速度の速い）プログラムが書けるがメモリに関する問題（メモリリーク等）が起こりえます。≒「危険なこともできるようにすることで表現力を得る」
それに対してC＃ではそういった問題が起こりにくい代わりに、実行時に無駄のある（不要な処理を挟む）プログラムになってしまうといった形ですね。≒「危険なことをできなくすることで安全を得る」
これ以外にも差異はありますが、そういった差異によるメリット・デメリットが存在するがゆえに古い言語でも生き残っているんですね。
　それらに加えてC言語は近年まで生き残っている言語の中ではアセンブリに次ぐぐらい低レベルな言語⁴なのであえて機能を追加せず最低限の機能を保つことで、できないことを増やさない≒時間や労力はかかるが大抵のことは実装できる環境を維持しています。
　機能を増やすことで便利になったと思えば、他の部分で融通が利かなくなってしまうんですね・・・。

特定の分野で定められている規定のもとに作られた、
もしくはこの言語が主流でその言語に合わせて規定が作られたから

　これについては今皆さんが目にしているものですね。
ネットワーク関連の言語です。基準が違う言語が各所で生まれてしまえば、その言語に対応していないブラウザはサイトを表示することが出来ません。その状態は非常に不便ですよね。
サーバーとなるとそれなりに選択肢がありますがWebページに焦点を当てると、HTML（文体、改行等の文章情報）、CSS（文字の太さやレイアウトなどの装飾）、JavaScript（フロントエンドでHTML、CSSを操作するための言語・ECMAScriptを基準・Transpile系も含む）など、ほぼほぼ統一されているといっていいと思います。
こうしましょうという取り決めのもとに使われている言語ということですね。

今まで使われてきたから（ライブラリが充実しているから）

　金融・大規模業務系はJava、C＃等の言語が流行して、そのシステムを保守しなければならないからその言語が主流になりました。さらにそれによってその業界でのノウハウやライブラリも充実することになったので現在もその言語での開発でいいよねという形で使われています。
このようにある種の時の運っていうのも流行り廃りには影響するんです。
新しくとってかわるのは、こういった積み重ねが必要な業界は厳しいかもしれませんね・・・。

基礎の構文が似通っている言語はどのような差が出るのか？

　おおよそ上に述べた理由が大半かと思います。Pythonなんかもカジュアルに簡易に書きたい（人の言語に近い、読みやすい形）という設計思想のもと≒今までよりも便利にということから生まれていますから。
さて最後に基礎的な文法が似通っている言語の特色をChatGPTにまとめてもらったので紹介したいと思います。どういった差異があるのか確認していきましょう。

◆ C言語：究極の低レベル汎用言語

• 設計思想：ハードウェアに近い操作を可能にしつつ、最低限の抽象化を提供する。
• 強み：
  • メモリ操作、アドレス操作が自由（ポインタ）
  • コンパイル結果がシンプルで高速
  • OSやドライバ、組み込み機器で標準的に使用
• 苦手なこと：
  • 型安全性がない（バグが起きやすい）
  • クラスも例外も標準では存在しない
  • 巨大なプロジェクトには手間がかかる

◆ C++：高性能と抽象化の両立

• 設計思想：Cの性能と自由度を保ちながら、安全性と表現力を拡張する。
• 強み：
  • オブジェクト指向（クラス・継承など）
  • テンプレートによる汎用性
  • STL（標準テンプレートライブラリ）による抽象化されたアルゴリズムとデータ構造
  • 最新のC++20以降でマルチスレッド・コンセプトなど大幅進化
• 苦手なこと：
  • 学習コストが高い
  • 複雑性が管理しづらくなる
  • コンパイル時間が長くなることも

◆ Java：安全性と実行環境の自由さ

• 設計思想：安全で移植性が高い言語（WORA: Write Once, Run Anywhere）
• 強み：
  • ガーベジコレクションによる自動メモリ管理
  • 仮想マシン（JVM）によるクロスプラットフォーム性
  • 強い型チェックと例外処理
  • 大規模業務アプリケーションに適する
• 苦手なこと：
  • 実行速度はネイティブ言語より遅め
  • ネイティブ操作やゲーム開発には不向きなことが多い

◆ C#：WindowsとGUI、業務アプリの親和性

• 設計思想：.NET環境との統合で、GUIや業務アプリの迅速開発
• 強み：
  • Visual Studioによる強力なIDE支援
  • GUI、Webアプリ、ゲーム開発（Unity）に対応
  • イベント駆動設計と非同期処理が得意
• 苦手なこと：
  • 実行環境（.NET）に依存
  • Linuxや組み込みでは使いにくい

◆ Python：圧倒的な表現力と手軽さ

• 設計思想：コードを“人間が読む”ことを最優先
• 強み：
  • 自然な文法（英語的）
  • 豊富なライブラリ：AI、データ処理、Webなど幅広い
  • インタプリタで即実行、試行錯誤しやすい
• 苦手なこと：
  • 実行速度が遅い（特にループ処理）
  • GIL（Global Interpreter Lock）の制約でマルチスレッドに難あり
  • 型安全性が弱い（最近は型ヒントで改善中）

◆ 比較チャート：何に向いている？

　荒っぽい比較かもしれませんが、こういった長所・短所が出てくるわけですよね。
構文を学んでいる時点では見えなかった違いも見えてくると思います。もし今後新しい言語を学ぶことがあればこういった比較をしてみると自分の目的に合った言語を選定できると思います。

あとがき

　さてここまで読んでいただいたと思いますが、ぶっちゃけ見づらい構成でしたよね・・・？
書いている途中でどうにもならないなぁと自分の文章構成力の無さに嘆いてました・・・（少し前の記事も見直してると悶々とすることが・・・）。本当にすみません。伝えたいことはあるけど、伝える能力は発展途上なのです。
　それはさておき個人的に最強の構成だと思っているのが「C++」+「Python」の組み合わせです。
C++の自由度と速度、自身で組めないプログラムをPythonのライブラリで補って実行する。これを使いこなせれば私のやりたいことは大体完結するんじゃないかなと思っています。
これを極められるように今後も精進していきたいと思います。
それではまた次回お会いできる時まで。ありがとうございました。

1. C/C++という表記があるぐらいには密接な関係 ↩︎
2. C#はＣ＋＋の発展形としてＣ++++となり、プラス記号4つを一つにまとめて＃になったわけですね。 ↩︎
3. ここで言う安全性はメモリリークやバッファオーバーフローなどプログラムの実行に支障をきたす動作を引き起こす可能性のこと ↩︎
4. プログラミング言語において低レベルとはより機械の言語（マシン語）に近いかどうかといったことです。人であれば文字によって理解しますが、機械が理解するのは0・1の羅列です。
   この0・1へのアクセス可否や書いたプログラムをどれほどの処理を挟んで機械語に変換するかによって高レベル・低レベルを判断しています。（ごめんなさい、明確な基準ってあるんですかね・・・おおよそこうじゃない？といった感覚で私も見ています。） ↩︎

年齢確認導入の経緯

なぜ今まで導入していなかったのか？

　まずは”今までなぜ導入をしていなかったのか？”から始めていきますね。
R18記事を書き始めた当初からプラグインでの解決を模索していました。
しかしながら、この手のプラグインのほとんどが

• 海外製
• その上設定できる（する）項目が多かった
• 自分の英語力がない

であり、それらの理由で少し壁が高かったのです。

　そこで一度サブドメイン、もしくはサブディレクトリ化による別サイト化という解決策も出ました。しかしながらこちらは

• 再度ワードプレスのインストールが必要＝再度初期設定が必要
• 一つのワードプレスでの記事管理が初心者には難しい
• サブドメイン使用の際には、二つ目のドメイン取得が必要

などの理由でこちらも没に・・・。

じゃあ自分で作るしかないのでは？

　というわけで解決策は自分でスクリプトを書くという選択肢しかないわけで、ChatGPTに頼んでPHP,JavaScript,CSSのファイルを書いてもらいました。（この時点で自分で書いてないじゃないかーいというツッコミは置いておいてください・・・ｍ（＿　＿）ｍ。）
まあちょこちょこその辺りのプログラミング言語についてはかじっていたので、フィックスできると踏んだうえでの判断でした。（JavaScriptとかは特に基礎文法はC++と似たり寄ったりですからね。）

　詳しい実装要件としては

• 投稿記事のタグに”R18”（スラッグとしては”r18”）が存在していたら年齢確認画面を表示させる
• ”はい”を選択した場合は、キャッシュに認証情報を記録してしばらくの間、認証画面を表示しないようにする処理
• ”いいえ”を選択した場合はサイトのトップページに戻る処理
• 描画部分に関しては全体をフラットに、背景にブラー（ぼかし）をかけるように。

といった感じですね。
それでは実装手順を見ていきましょう。

　まず、自身のサーバーのファイルマネージャにて自身が使っているテーマ（子テーマの場合はそちら）のフォルダ内に以下のフォルダ・ファイルを作ります。

• functions.php(既存の場合は作らなくてOK！)
• js(フォルダ)
  ->age-verification.js(”->”は先のフォルダの中にという意味)
• css(フォルダ)
  ->age-verification.css

そして各ファイルの実装の中身です。（既存のコードはそのままで）

// フロントエンドに年齢確認用のスクリプトを追加（タグにR18が含まれていたら年齢確認のダイアログを表示）
function add_age_verification_script() {
    if (is_single()) { // 投稿ページだけ
        $post_tags = get_the_tags();
        if ($post_tags) {
            foreach ($post_tags as $tag) {
                if ($tag->slug === 'r18') { // タグのスラッグが 'r18' なら
                    wp_enqueue_script('age-verification-script', get_stylesheet_directory_uri() . '/js/age-verification.js', array('jquery'), '1.0', true);
                    wp_enqueue_style('age-verification-style', get_stylesheet_directory_uri() . '/css/age-verification.css');
                    break; // 見つかったらループ終了
                }
            }
        }
    }
}
add_action('wp_enqueue_scripts', 'add_age_verification_script');

// 年齢確認用JavaScript
jQuery(document).ready(function($) {
    // Cookieを読む関数
    function getCookie(name) {
        const value = "; " + document.cookie;
        const parts = value.split("; " + name + "=");
        if (parts.length === 2) return parts.pop().split(";").shift();
    }

    // Cookieに書く関数
    function setCookie(name, value, days) {
        const expires = new Date();
        expires.setTime(expires.getTime() + (days * 24 * 60 * 60 * 1000));
        document.cookie = name + "=" + value + ";expires=" + expires.toUTCString() + ";path=/";
    }

    // すでに認証済みならスキップ
    if (getCookie('age_verified') === 'yes') {
        console.log('すでに年齢認証済みなのでモーダル表示スキップ');
        return;
    }

    // モーダル作成
    var modalHtml = `
        <div id="age-verification-overlay">
            <div id="age-verification-modal">
                <h2>18歳以上ですか？</h2>
                <div class="age-verification-buttons">
                    <button id="age-yes">はい</button>
                    <button id="age-no">いいえ</button>
                </div>
            </div>
        </div>
    `;
    $('body').append(modalHtml);
    console.log('年齢確認モーダルを追加しました');

    // ボタン動作
    $('#age-yes').on('click', function() {
        setCookie('age_verified', 'yes', 7); // 7日間有効なCookieを保存
        $('#age-verification-overlay').fadeOut();
        console.log('「はい」を選択＆Cookie保存');
    });

    $('#age-no').on('click', function() {
        console.log('「いいえ」を選択、ホームへリダイレクト');
        window.location.href = '/'; // サイトのホームに飛ばす
    });
});

#age-verification-overlay {
    position: fixed;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
    backdrop-filter: blur(5px); /* ←ココで背景をぼかす！ */
    background: rgba(0, 0, 0, 0.5); /* 背景は薄めの暗さ */
    z-index: 9999;
    display: flex;
    justify-content: center;
    align-items: center;
    font-family: 'Helvetica Neue', 'Arial', sans-serif;
}

#age-verification-modal {
    background: #ffffff; /* 真っ白ベース */
    padding: 40px 30px;
    border-radius: 10px;
    text-align: center;
    color: #333; /* 文字はダークグレーで上品に */
    box-shadow: 0px 8px 30px rgba(0, 0, 0, 0.2); /* ふわっとした影 */
    max-width: 400px;
    width: 90%;
    transition: all 0.3s ease;
}

#age-verification-modal h2 {
    font-size: 24px;
    margin-bottom: 20px;
    font-weight: 600;
}

.age-verification-buttons {
    margin-top: 30px;
    display: flex;
    justify-content: center;
    gap: 20px;
}

.age-verification-buttons button {
    padding: 12px 24px;
    font-size: 16px;
    border: 2px solid #333;
    border-radius: 6px;
    background: transparent;
    color: #333;
    cursor: pointer;
    transition: background-color 0.3s ease, color 0.3s ease;
}

#age-yes:hover {
    background-color: #4CAF50; /* 緑色でGO感 */
    border-color: #4CAF50;
    color: #fff;
}

#age-no:hover {
    background-color: #f44336; /* 赤色でSTOP感 */
    border-color: #f44336;
    color: #fff;
}

といった感じですね。
コピペして使ってもらっても構いませんし用途によって細かく変えてもらっても大丈夫です。（免責事項に同意したうえでご使用ください<m(__)m>。）

　それらによってできた画面がこちらになります。

今後サイトに装飾が増えてきて雰囲気に合わなくなったら再度デザインは変更すると思いますが、
シンプルなデザインで個人的には満足です！

あとがき

　ここまで見ていただいてありがとうございます！
やりたいことが最近ありすぎるのですが、お金がないのがネック・・・。
ゲームに関する記事でエンタメ精神にあふれた記事をお届けしたいところですが、次回も備忘録的なものになると思います。（おそらくaviutlを使用したボイロ実況動画作成環境についてです。）
つまりは・・・？

とはいえ腰（どころかなにもかも）が重いので実際にそこまで行くのに半年以上かかると思います・・・。ブログでしか表せないこともありますが、やっぱり動画の方が直感的ですからね！

最後に実際のページを紹介して終わりにしたいと思います。
記事の内容自体はグロめなので見なくても大丈夫です！（見てほしいけどね・・・。）
それでは次回もお待ちしております（　・∀・）ﾉｼ。

【R18G】本当のバケモノは誰？「駄作～ヌイアワセ～」

暑い日も終わりに近づいていますが、秋が感じられそうにない感じで過ぎ去っていきそうですね・・・。そんなわけで今回は「駄作～ヌイアワセ～」について。自分が始めてプレイしたグロゲーです。（自分の趣味的に）紹介したいけど、（いろいろな意味で）普通は...

gamekineki.com

2024.11.02

　昨今はUnrealEngineやUnityなどのゲームエンジンで比較的学習コストを低くして、ゲーム制作に取り組むことが出来て個人開発者にとっても非常にいい環境が整いつつあります。しかしながら各エンジン備え付けのコンポーネントなどの処理だけでは自分のやりたいことを実現できない・・・、なんてことも起こりえます。ゲーム開発の基礎（どのようなことが書かれているのか・どのような順序で処理されているのか等）を学ぶためにも一度コードに触れることは絶対損にはなりません！！
なのでよりフレキシブルに開発できるように、コードを書くことに馴染みを覚えてほしいなあと思い今回の記事を書きました。¹

各フレームワーク・ライブラリの紹介

そもそもフレームワーク・ライブラリって何ぞ？違いって？

　とまあ送り出したのですが、恐らくですが早速引っかかると思います。聞いたことはあるけど詳しい違いや内容が分からないですよね。本題とずれてしまうのでネットの海を調べていただくか下記の記事を参照して下さい。

【解説】フレームワークとライブラリの違い

zenn.dev

　簡単に言いますと
・フレームワーク：プログラムの基礎の構成が既にあり、それ単体でも実行できる。この上に自身の書いたプログラムを載せて拡張するといったイメージ。
・ライブラリ：便利な関数（プログラム）の集まり。上記と比べて自身の書いたプログラムに必要に応じて取り入れるといった感覚をイメージしてもらえるといいと思います。
と頭の片隅においてもらえたらと思います。

DXライブラリ

ホームページ
https://dxlib.xsrv.jp/（”ダウンロードはこちら”のところから自分の環境に合わせてダウンロード）
リファレンス
https://dxlib.xsrv.jp/dxfunc.html#R1N1

・特徴
導入の方法が今回紹介する中で最も容易。
ー方法に関しては今回は説明しないので、他のサイトを参照してもらえればと。
関数ごとに用例やどういった処理をしているかの解説がリファレンスに乗っているので、初心者でも扱いやすいと思われる。
基本的には現在掲載しているリファレンスのページの関数のみでゲームの制作を行うことが出来る。
ー3D関係やLive2Dにも対応しており別ページに存在するが、それらは無理に使わずともよい（使ってもよい）。
・留意点
初期化と終了処理が必須となる。
ーゲーム系のライブラリにはつきものだが、それぞれ一行で終わる為、容易。
リファレンスには掲載されていない隠し関数が存在する。
ー参照する際は実際のソースコードで。

以下に基本となるゲームループのコード

#include "DXLib.h"

//
// WinMain(). プログラム起動関数
//
int WINAPI WinMain(
	HINSTANCE hInstance,
	HINSTANCE hPrevInstance,
	LPSTR lpCmdLine,
	int nCmdShow
) {

    // ＤＸライブラリ初期化処理:DXライブラリの関数
    if( DxLib_Init() == -1 )
    {
         return -1;        // エラーが起きたら直ちに終了
    }

    Initialize(); // ゲーム全体の初期化処理

	// 1フレームループを組む ----------------------------------------------------------
	while (ProcessMessage() == 0)		// プログラムが終了するまでループ:DXライブラリの関数
	{
		Input(); // キーボードやパッドの入力処理
		Process(); // ゲームの計算処理（キャラがどれぐらい動いたなど）

		ClearDrawScreen();		// 画面を初期化する:DXライブラリの関数
		Render(); // 画面にキャラクターを描画
		ScreenFlip();			// 裏画面の内容を表画面に反映させる:DXライブラリの関数
	}

    // ＤＸライブラリ使用の終了処理:DXライブラリの関数
    DxLib_End() ;

	return 0;
}

Siv3D

ホームページ兼リファレンス
https://siv3d.github.io/ja-jp/

・特徴
よく使われる図形構造体（Rectなど）や標準ライブラリ（STL）のラッパークラスが存在し、それらを活用しやすいように整えられているフレームワーク。
導入した時点で初期化や終了処理を必要とせず、ファイルがインクルードされていれば各種クラス・関数を利用することが出来る。
現在でも開発者がSiv3Dに関する講演等を行っており、体験会なども開催されているので最寄りで開催されていた場合、参加するという手段もとれる。
・留意点
既に自身で作ったプロジェクトが存在している場合、新たにSiv3Dテンプレートのプロジェクトを作り直して移植する必要がある？（自分は中途で導入するのを断念して作り直しました・・・。）
汎用的な命名が多いため、自身で作った関数等と命名がかぶることが往々にして発生する。
ーその場合はSiv3D側のネームスペース（s3d::○○）を明確に記述することで解決できる。
ラッパークラスも多いので本来の標準ライブラリに触れるところまでコードの内容を確かめて理解してみてほしい。
ー他のライブラリでは基本的にここまでラッパークラスが整備・活用されていることは多くないので、標準ライブラリを扱えるようにした方がいい気がする・・・。
リファレンスもまだ記述されていない項目が存在するので内部のコードをみて開発することも必要。

以下に基本となるゲームループのコード（公式サイトの例）

# include <Siv3D.hpp>

void Main()
{
	// 背景色を水色に設定する
	Scene::SetBackground(ColorF{ 0.8, 0.9, 1.0 });

	// 絵文字からテクスチャを作成する
	const Texture texture{ U"🐥"_emoji };

	// テクスチャを描く位置
	Vec2 pos{ 400, 300 };

	// メインループ
	while (System::Update())
	{
		// もし左クリックされたら
		if (MouseL.down())
		{
			// 描く位置を現時点でのマウスカーソルの位置に変更する
			pos = Cursor::Pos();
		}

		// テクスチャを描く
		texture.drawAt(pos);
　　　　
	}
}

SDL

ダウンロードページ（GitHub）
https://github.com/libsdl-org/SDL
日本語リファレンス
https://maruhiro-ver0.github.io/sdl2manual-ja/

・特徴
クロスプラットフォームライブラリ
ー違うプラットフォーム（OS）でも動作する
海外で作成されたライブラリのため、ゲームの開発実績も相応に多い
ーそのため英語版のリファレンスが日本語より充実していると思われる
参考書籍も存在するのでその本に沿って学習すると吸収しやすいかも？
ー本項目の最後にAmazonのリンクを掲載
・留意点
DXライブラリと同様に初期化と終了処理が必要となる
リファレンスの項目分けは初心者にとっては少し見づらいかもしれないです。
ー必要としている関数がどこにあるかわかりにくい

以下に基本となるゲームループのコード

void main()
{
 SDL_Window* gWindow; // ゲームのウィンドウ 
 bool gIsRunning = true; // ゲームを起動し続けてよいか

/////必須の初期化作業（初期化内容は必要に応じて）//
 if(SDL_Init(SDL_INIT_VIDEO) != 0){
   gIsRunning = false;
 }

 gWindow = SDL_CreateWindow(
  "Game_test",　// ウィンドウのタイトル
  0,            // ウィンドウ左上隅のx座標
  0,            // ウィンドウ左上隅のy座標
  1920,         // ウィンドウの幅（Width）
  1080,         // ウィンドウの高さ（height）
  0             // フラグ（設定しない時は0） 
 );

 if(!gWindow){// もしウィンドウが作成されなかったら
   gIsRunning = false; 
 }
//////////////////////////////////////////////

 while(gIsRunning){
 // これまでと同様の入力、処理、描画のゲームループ 
   Input();
   Process();
   Render();
 }

/////必須の終了処理/////////////////////////////
 SDL_DestroyWindow(gWindow);
 SDL_Quit();
//////////////////////////////////////////////
}

参考書籍

最後に

　ここまで紹介してきましたが、上記のいずれかを”絶対にマスターしろというわけではない”ということは言っておきますね。最初にも言いましたが、昨今は便利なゲームエンジンの台頭もあり、そちらの方が慣れれば開発効率は上だと思います。ただ内側を知っているか、自分で書けるか、で作れるものの幅は大きく変わると思います。上記を使ってゲームをつくる中で色々調べることが多くあると思います。それらを調べて自分の内に貯めていくことで、つくるゲームの世界がより広がるんじゃないかなと思います。
これを使った方がいいというゲームの作り方の定石はあるかもしれませんが、どの道具・方法を使えというのは決まっていません。上記でも十分、ゲームの発想とコードを書く力次第で面白いゲームは作れますので、めげずに頑張りましょう！（僕も頑張ります・・・。面白いゲームつくったら共有してね・・・。）

最後に今回の話題とは無関係ですが、推しの作家さんの本を載せておきますね。（キャラの造形とか作者さんが書くキャラが好き・・・。）

1. 初心者向けだったら、導入方法とかもっと懇切丁寧に解説したほうが良いよなぁと思いつつ・・・わからないところがあったらSNSなどでここ分からなかったを言ってください。頑張れれば答えたり記事にします・・・ごめんなさい ↩︎