生成AIの中でも特定の分野では、利よりも害が大きいんじゃない？

　昨今、話題になっていますが、
個人的に今の特定の分野においての生成AIの状況は、
とてもよろこべたものじゃないと思っています。

　生成AIで記事を書いたこともある筆者なので、”生成AIという技術”自体を否定するわけではありません。むしろ活かし方によっては、物事のスタート・補助として、これほどまでに活用しがいのある技術はないと思います。

　では、なにを危惧しているのかというと、その懸念している特定の分野の縮小。
極端な話を言えば、ある意味での文化の消滅を意味すると考えているからです。

芸術系（作品を公開して評価してもらう系）は、今の生成AIに緩い状態を何とかしないと新しい表現生まれにくくなるんじゃない？という懸念

　まず、特定の分野というのは上記に述べた
芸術系分野（絵、楽曲、小説、ゲームなど）
でのお話です。
　プログラム（もちろん著作物という面はあるのですが、どちらかと言えば特許法で守られているイメージ）や知識・教育系の活用での懸念はあまり個人的にはしていないということですね。（抜け穴的に上記の分野に干渉する点は見過ごせませんが……）

　そして、肝心の問題点として考えているのが、

• 訴訟の労力と見合わないため、著作権保護が十分にできない・なされない。（特に個人のクリエイター）
  ＝大元（大規模生成AI運営企業）を訴えられないが故、対症療法（著作権侵害された際、個別に対応）をせざるを得ないため、非常に負担がかかる。（都度、弁護士に依頼しなければならない依頼料の金銭的にも、作品に対する時間が取れなくなる時間的な損失的にも）
• 新しい切り口の作品が生まれない・ソフトパワーの枯渇
  ＝絵で例えると、「生成AIでいいや」という思考が増え、新規に自分の手で絵を描く人口が少なくなり、素材となる学習元が枯渇した時、AIで描かれた似通った絵が蔓延、学習も循環するようになり、その分野自体が停滞する。
• なし崩し的に著作権という権利がなくなっていく。
  ＝最初は個人クリエイターから始まって、「好き勝手生成AIに読ませてしまえば、著作権ごまかして、どうにでも扱っていいよね」、という風潮が広まっていった先は既存の企業も大丈夫とかいう甘い考えではいられないのかなと。
  それこそIPを多く抱えている会社系は特に。二番目の問題とつながっている問題かも？

といったことが考えられるのかなと。

　まず、一つ目に関してですが、生成AIに学習させるまでは著作権法第30条の4の二（著作物に表現された思想又は感情の享受を目的としない利用）において合法とされてしまっています。
個人的にはその後、なにがしかを生成して公開した時点で著作者人格権の同一性保持権に引っかかるんじゃね？と思い続けているのですが、そういったことらしいので、ここまでは現状適法の範囲らしいです。（コラージュでの著作権侵害は認められるのに、特例にするのは正直納得できませんが……）

　では、どこを問題にするかというと、”生成される時”、もしくは”その後”になるわけですよね。
個別に生成して公開された作品の類似性¹を認識　→　作品の依拠性²を著作権者側が証明しなければいけないんです。
　絵で例えれば、仮に作品を公開して人気になったとして、続々と似通った絵柄・構図、もしくは特定のキャラクターの出力がなされた結果、著作権侵害は親告罪なわけですから、それらすべてを個別に訴えなければいけないわけです。

　……きつくないですか？

　企業単位の法務部が著作権保護に取り組むのであればともかく、個人で自身の著作物の権利を守るのであれば、そういった著作権侵害を疑う対象を認識するたびに弁護士に相談することになります（基本的に）。そういった権利の行使がしにくい状況を生み出すことが容易に想定される中で、学習を容認する（＝大元の生成AI企業への自身の作品の学習データの削除要求が通らないor完全には消せない、で逃げられてしまう）のは如何なものかなと。

　二つ目、三つ目に関しては、つながっている話ではあるのですが、どちらにせよ絵に限らず、自筆を執るクリエイターの新しい芽が出にくくなる　→　総合的な文化の衰退・発展の阻害になるのではないかなと。大体は上記に書いてある通りのことを懸念しています。

では、そういった分野でどのように生成AIを活用するか

　じゃあ、そういった創作関係で生成AIを使うのはダメなのかよ！！！……という方もいらっしゃるかもしれませんが、そんなことはないと思います。

　あくまで「他人に自身の著作物を学習されたくない人も黙認せざるを得ない状況」というのを問題視しているのであって、”通常の著作権侵害とならない利用範囲”（私的使用範囲での複製＝”外部に出さない”や教育目的など）での利用であればいいと思いますし、それに加えて、個人的な考えとしては以下のような利用範囲で他者の権利を侵害しないような利用をすればいいのではないかなと思います。

• 芸術系の生成AIは個人（もしくは各企業などの枠組みの中）で育てていく。
  ＝本人の著作のみを学習、もしくは汎用データセット（ネットに流されているような無法なものではなく、素材集として作られたもの）含めて学習させて、その人の創作の一助にしてもらう。
• 作る前（いわゆるアイディア段階）や作り上げた後の修正であれば許容？
  ＝例えば文章であれば、設定段階のアイディア出し、言語として間違っている細かい部分の校正の指摘、描写・整合性の矛盾の指摘、書き上げた作品の批評など（あくまで指摘に留めて、変更に関しては任意にする）。
  であれば、「思想又は感情を創作的に表現したもの」という著作物の前提も保たれるはず。

が個人的に思う許容できる使用範囲。
これなら大半のクリエイターの創作意欲を削ぐことなく、生成AIという技術の恩恵も受けることができるのかなと。

法や行政府にやってほしいこと

　一つ目の項で著作権者を十全に守れないのでは？という懸念を示したように、法の整備が追い付いていないことが多いと感じます（この件に限らず）。

　なので、最後に法などで整備してほしい点を挙げておきたいと思います。
（意見を募れば、全然これ以外もあると思いますし、この内容も異議はあると思いますが……）

• 現在の依拠性の判断基準に加えて、モデルの学習に使用した素材の明記の義務付け（単位で言えば、イラスト一枚レベル、もしくはその更に下のレベルからでも徹底的に）
  ＝これにより自身の作品を素材として、使われたくない場合、明確に拒否する意思を示し訴えることが可能になる。ただ、あくまで生成AIモデル作成側の自己申告になるため、現在の依拠性による判断も継続したうえで追加してほしい。
  ネットワーク上から自動収集しているところが多い以上、アドレスなどの情報は確実に記録できるためそこらあたり？
• 生成AIの学習目的であっても、通常の私的使用の範囲でとどめてほしい。
  ＝営利の生成AI企業は、著作権侵害コンテンツを作らせて、クリエイターが負う負担（訴訟含めた対応）を増やしているだけでしょ。仮に学習させるにしても個人で外部には出さない学習モデルに留めるべきでは？
• 学習に使われた重みを消せない、で止めることなく、そのデータを除いて学習させ直し、ぐらいの対応にさせるべき。
  ＝例えば特許侵害した製品がそのままの構造で生産され続けることはないはず（特許料の支払いに応じた場合を除く）。
• NPOなどの団体を税金で支援するなら、海外での著作権訴訟などを国内のクリエイターが行いやすいように支えてくれる団体に税金を使ってくれよ……と思ってしまう。
  （無駄に税金吸ってる団体多すぎだろ……借金だなんだいうなら歳出をもっと整理しろよ……）
• 損害賠償や刑罰を本当に踏みとどまるような相応なものにしてほしい。
  ＝この分野に限らないことだが、違法に得た金額　＞　損害賠償や罰金　のように、やり得な状況を是正してほしい。

ということで、書きたいことはこれぐらいですかね。

詰めに詰めましたっていう内容ではないので、粗は大いにあると思いますが、自分の思ったことの備忘録として残しておきたいと思います。

1. 作品が似ているかどうか、この時点では著作権の侵害とはみなされない。 ↩︎
2. 作品が侵害した著作権元を参照して作られたかどうか。
   SNSなどで公開されている作品の場合、侵害した側がその作品に触れられる可能性があったかなどを検証される。 ↩︎

個人的な活用法の覚書

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を使い始めたのですが、余分なファイルがない（デフォルトのファイルしかない）分、ディレクトリ配置が複雑化していないのでコマンド操作が使いやすかった感覚はたしかにあったのでそういった環境の変更時に触り始めるのも一手な気がする。

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

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

最後に

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

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

寝るのが一番

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

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

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

　私は過去に一度プログラミングを学ぼうとして挫折したんですよね。
というのを思い出したのがこの記事の発端です。ゲームが好きでゲームを作りたかったんですよね。
その時に様々な言語の選択肢を見て、「どれを学べばいいんだ・・・？」となってしまいました。
それでもひとまずどれでもいいからかじってみようと思い立ち、初心者向けの参考書を複数言語買って挑戦し始めました。（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などでここ分からなかったを言ってください。頑張れれば答えたり記事にします・・・ごめんなさい ↩︎

どのような状況だったのか。

　まず今現在自分の状況から書いていきます。
IDE（統合開発環境）としてVisualStudioを用いてC/C++で自身の趣味を含んだ開発を行っております。スキル・技術としては正直3流以下で、ChatGPTの助けを借りながら理想に向けて邁進しておりまます・・・！
そんな中で恒久的にデータを保持する手段としてSQLデータベースの利用をしようと、検討の結果思い立ったのですが、そこが地獄の始まりでした・・・。

SQLiteを使用して導入するまでは順調だったが・・・。

　このSQLデータベースをどういう風な意図で利用しようか¹というと、”SQL文というコマンドによってデータベースを操作してデータベースへのアクセスを一意なものにしちゃおう”ということと”自身でガバガバなデータ管理クラスをつくって無駄なデバッグに労力を割くのをやめよう”ということを考えたわけですね。あまりピンと来てない人向けに言いますと、Excelのような表形式にできる情報²をデータベースで管理しようということです。
ライブラリはsqlite3と呼ばれるライブラリを導入しました。
他のSQLライブラリと比べてサーバーをつくらずとも、ローカルで完結して軽量なため、小規模でもし行くところまで行ったとしても中規模が限界な自分のプロジェクトにはぴったりな選択だったと思います。

SQL自体はそこかしこで使われるようなメジャーなデータベース言語だったので、文献も豊富ですし、GPTの回答も解決策となるようなものも多く実装は順調でした。そんな中で問題が出てきます。
それはINSERTで”文字列”として挿入したはずの要素がBLOB型（バイナリ）として保存されていたということです。（下記はsqlite3の関数ではなくSQL文での表記）

INSERT INTO NounDictionary (Name, Language, PartOfSpeech, Synonyms, Antonyms, RelatedNouns, Reference, Attributes, Description, IsTopicVisible)
VALUES ('犬', 'ja', '名詞', 'ワンコ,ドッグ', '猫', '猫', 'res/images/dog.png', '{"type": "名詞", "category": "動物", "traits": ["忠実", "可愛い"]}', '犬科の哺乳類。', 1);

上記のようなコードにおいて日本語部分のみ挿入前の形を保てませんでした。これを直そうと思って四苦八苦・・・。解決まで2,3日かけてしまいました。（会社だったらクビですね）

結末は単純なことで解決へと・・・。

　そんなこんなでモチベーションも下がりつつあったのですが、ChatGPTの回答に文字コードが悪いんじゃないかという話がちらほら。それらの修正は効果がなかったのですが、そういえばとVisualStudioの標準の日本語文字の文字コードってなんかいろいろ引っかかるみたいな話何だっけ・・・、という朧げな記憶を引っ張りだしたどり着きました。

    std::map<std::string, std::string> newElement = {
       {u8"Name", u8"犬"},
       {u8"Language", u8"ja"},
       {u8"PartOfSpeech", u8"名詞"},
       {u8"Synonyms", u8"ワンコ,ドッグ"},
       {u8"Antonyms", u8"猫"},
       {u8"RelatedNouns", u8"猫"},
       {u8"Reference", u8"res/images/dog.png"},
       {u8"Attributes", u8R"({"type": "名詞", "category": "動物", "traits": ["忠実", "可愛い"]})"},
       {u8"Description", u8"犬科の哺乳類。"},
       {u8"IsTopicVisible", u8"1"}
    };

　上記のような挿入する要素をu8のプレフィックスを接頭に付けて³文字列の扱いを”UTF-8”にすることで、INSERTで挿入しても要素の名前がBLOB型にされることがなくなりました。
結論としてはVisualStudioで標準で扱う文字コードが”Shift-JIS”、SQLデータベースで扱う文字コードが”UTF-8”というだけの話だったんですね・・・。SQLはそりゃそうだって話だったんですけど、VisualStudioが標準そっちだったかというのは完全に抜けていましたね・・・。
そんなこんなでようやく迷宮から抜けられそうなのでここから開発を加速させたいですね・・・！

またプロジェクトやファイルごとに扱う文字コードをUTF-8に変更する方法もありますが、検索した時にたくさん見たのでたぶん自分が書くよりも詳細な説明が載っているでしょう。もしくはChatGPTに聞いてもいいと思います！
余談ですが最近のChatGPT、プロジェクトでやりやすくなりましたよね。・・・ファイル読み込みや古いファイルの参照に弱いのはあいも変わらずですが・・・。

自分が使っているSQL関連のあれこれについて（2つだけですが・・・）

　では最後に今自分が使っているSQL関連の便利なあれこれを２つだけ紹介して終わります。

一つ目はVisualStudioに導入して使っているSQLite。
https://www.sqlite.org/download.html（自分はsqlite-amalgamation-3480000.zipをつかっています。目的ごとに違うので気になる人は調べてみてください。）
C++のコードでSQLを簡易に使えるのでSQLデータベース初心者におススメです。
前述の通り、オフラインでローカルのデータベースとして扱えるので小規模の開発に向いています。
逆にオンラインで多数からの接続を想定している場合には他のSQLライブラリの方が向いているかも・・・？
もう一つはDBファイルの中身を見れるDB Browser for SQLiteです。
https://sqlitebrowser.org/
ローカルにデータベースファイルが生成されるSQLiteではDBファイルを見ることが出来ます。
これを用いることでデバッグや開発がはかどります！
また開いたデータベースファイルに対してSQL文の直接実行もできたりするので、そこもいいですね。
ということでこれを新たな備忘録としたいと思います。
また見に来ていただけたら嬉しいです。それでは。

1. SQLがどういうものかというものを断言してしまうと、いろいろと語弊を生んでしまうので今回は自分が使うに至った理由を書いています。 ↩︎
2. ExcelのようなGUI（グラフィックで操作する）ではなく、CUI（コンソールでコマンドで操作）なので慣れるまで時間が必要でした・・・。 ↩︎
3. 応急処置的な扱いの方がいいのかな・・・とか、思ったり思わなかったり。
   でもファイルやソリューション単位で変更すると今までのコードでエラーを起こすので不用意に全部統一するのはご法度ですわね・・・。 ↩︎

では本題へ・・・。

stdio.hとは何ぞや？

最初に抱くであろう疑問

　プログラミング言語を触る中で比較的ライトな層には最近Pythonが主流であるとは感じていますが、それでも少し深堀してもう少し低レベルな言語¹を学ぶ時の主流としてはやはりC言語系統（C++やC＃を含む）になってくるんじゃないかなと思います。
そんな中でプログラミング初心者が最初に触れるであろうHelloWorldの文字列出力がありますよね。その中で一番上に＜stdio.h＞が見えていると思います。形式的にそうなんだろう²と、ひとまず書かれたこのヘッダーファイルについて何も知らないままを今回で卒業しましょう！

stdio.hについて（本編）

　<stdio.h> は、C言語で標準入出力を扱うためのヘッダーファイルです。名前の由来としては”standard input output”の略です。読んで字のごとくというわけですね。（自分はいろいろ理解するまで字面が似ていたVisualStudioの何かの関連なのかと思っていました・・・。）
このヘッダーファイルには、ファイルやコンソールを使ったデータの入出力を行うための関数が定義されています。

主な特徴と役割

主な役割としては以下。

• 標準入出力機能を提供する。
• C言語の基本機能であり、ほぼすべてのCプログラムで使用されます。
• Standard Input（標準入力）: 通常はキーボードからの入力を指します（例: scanf でユーザーからの入力を受け取る）。
• Standard Output（標準出力）: 通常はコンソールへの出力を指します（例: printf で文字や数値を表示する）。
• Standard Error（標準エラー出力）: エラー情報を表示する出力先。通常コンソールにエラーメッセージを出力します（例: perror）。

printf（）＝画面への文字列出力の関数も当然ながらこの中に含まれているので、これを最初にincludeする必要があったんですね・・・！

主な関数

以下に、<stdio.h> に含まれる代表的な関数について概要だけ示しておきます。

コンソール入出力

1. printf
   • 画面に文字列や数値を表示します。
   • 使用例:
     printf("Hello, World!\n");
2. scanf
   • ユーザーから入力を受け取ります。
   • 使用例:
     int x;
scanf("%d", &x);

ファイル操作

1. fopen / fclose
   • ファイルを開いたり閉じたりします。
   • 使用例:
     FILE *fp = fopen("example.txt", "r");
fclose(fp);
2. fread / fwrite
   • ファイルからのデータ読み書きを行います。
3. fprintf / fscanf
   • ファイルに対して書き込みや読み取りを行います。
4. fseek / ftell
   • ファイル内の位置を操作します。

その他のユーティリティ

1. gets / puts
   • 文字列の入力や出力を行います。（getsは非推奨）
2. perror
   • エラーをコンソールに表示します。

重要な構造体

• FILE
  • ファイルを操作する際に使用する構造体で、fopen などの関数によって管理されます。

終わりに

　本当に何も知らずに使う状態から脱出してほしい、難しいリファレンスを読むことへの足掛かりになってほしい、そんな思いがあり今回の記事を書きました。今後もプログラミングをしている中で自分が”引っかかったこと”、素朴な疑問を記事にして、今回のような備忘録という名の肥やしも当ブログで増やしていきたいと思います。

1. 今回のことで言えば、Pythonより低レベルの階層（ポインタ操作等）にアクセスできる言語という意味 ↩︎
2. 実際、この部分の中身を始めたてで十全に理解するのは難しいので知らないことを減らして知識を増やしてゆくことが大事。 ↩︎