【生成AIコンテンツ】暴力のゆくえ:スーツを着た極道から、アルゴリズムが支配する未来まで

現代社会において、かつて「暴力」を象徴した存在は形を変え、私たちの目に見えにくい場所へと溶け込みつつあります。ヤクザがなぜスーツを着るのか。この素朴な疑問から出発し、私たちが生きる「白黒はっきりさせる社会」の正体に迫ります。

1. 矛盾のなかの合理性:なぜ伝統を重んじる者が「洋装」を選ぶのか

ヤクザが伝統的な和装ではなく、ビジネスマンと同じ「スーツ」を着用するのは、単なるファッションではありません。そこには、組織の存続をかけた高度な戦略と、日本社会特有の「形式への執着」が隠されています。

彼らにとっての「伝統」とは、着物という物ではなく、「序列」や「儀式」というシステムそのものです。明治維新以降、日本の権威が洋装化したのと同様、彼らもまた「その時代で最も格が高いとされる格好」を模倣することで、社会的な威圧感と信用を同時に得ようとしました。

しかし、これは同時に自前の文化を持たない「権威のパロディ」という限界も示しています。彼らは常に、社会のメインストリームを鏡のように映し出す存在だったのです。

2. 組織の相似形:ヤクザとサラリーマンを分かつ「一枚の壁」

スーツを纏い、組織(社紋や代紋)に忠誠を誓い、出世競争に身を投じる。その構造だけを見れば、ヤクザとサラリーマンの本質は驚くほど似通っています。かつての日本企業が持っていた「家族的経営」の究極形が、暴力団という疑似家族システムだったとも言えるでしょう。

しかし、決定的な違いはその「裏側」にあります。サラリーマンの経済活動が「法と契約」に基づいているのに対し、彼らの本質は「暴力という実力を背景にした法外の調整」にあります。スーツの裏に隠されているのが「契約書」か「刺青」か。この違いが、生存をかけたリスクの性質を根本から分断しています。

3. グレーゾーンの消失:整備された社会がもたらす「息苦しさ」の正体

近年、暴力団排除条例や暴対法の強化により、ヤクザはかつてないほど「食えない」職業となりました。社会が透明化され、あらゆる決済や契約が監視される中、法の間で生きる「グレーゾーン」の人々はシステムから拒絶されています。

これは一見、社会の浄化に見えますが、同時に「わずかな失敗も許されない不寛容な社会」への変質でもあります。行き場を失った「度胸と知能」を持つ人間は、ヤクザという看板を捨て、より洗練されたスーツを着て表社会の隙間に潜り込んでいます。悪が消えたのではなく、ただ「不可視化」されたのです。

4. 文明のジレンマ:人間から「暴力」を奪うことは可能なのか

歴史を振り返れば、人間と暴力は切り離せません。ルールをどれほど精緻に整備しても、集団心理や差別、そして国家間の戦争といった形で、暴力の本能は常に噴出します。

日本人はこの「理性のルール」に極めて順応していると言われますが、それは暴力性が消滅したことを意味しません。物理的な暴力が禁じられた代償として、現代では「同調圧力」や「SNSでの私的制裁」といった、精神的な暴力へと形を変えて発現しています。ルールによる締め付けが強まるほど、内面化された抑圧が別の形で爆発するリスクを孕んでいるのです。

5. 終着点としてのSF:AIが警察と司法を管理する時代へ

もし、この「白黒つける社会」を究極まで突き詰めれば、行き着く先は「AIによる統治」かもしれません。AIが過去のデータに基づき、感情を排して公平に判決を下し、犯罪を予測する。それは低コストで安全な、完璧な秩序をもたらすでしょう。

しかし、そこには「情状酌量」も「再起のチャンス」も存在しない、アルゴリズムの牢獄という側面があります。私たちは安全と引き換えに、人間が人間を許すという「不完全な慈悲」を捨て去ることになるのかもしれません。

スーツを着たヤクザという奇妙な存在は、私たちが「野性」を捨て「理性」へと移行する過程で生み出した、文明の過渡期の象徴だったのかもしれません。そして今、社会はさらにその先、人間的な揺らぎすら許さない「透明な未来」へと向かおうとしています。

製造ドメイン整理・改善点

製造ドメインの整理、改善を考えるメモです。
前提の環境は、中小企業、受注生産・多品種少量としています。
特定の一社ではなくを複数の会社の状態を混ぜています。

受注

・受注用の製品マスタはある(得意先、型式、金額)のみ。
・製番管理している。仕入など全て製番管理だが、あまり枝番管理ができていない。複数台受注でも1製番のため、それぞれの原価の数量との突合ができないなど。

仕入/発注

・E-BOM/M-BOM無し。
・材料発注履歴は保存しており、model nameをキーとして簡易M-BOM(表記ゆれあり)はある。
・製品を構成する部材のほとんどが定尺購入で、現場が必要に応じて発注する発注点方式の部材で製品のほとんどを構成している。一部の特殊な材料は製番に紐づけして仕入れており、そこではM-BOMあるいは図面を見て都度発注となる。

個別原価

・製番に紐づけた実際の仕入と、積算データからの工数などで計算。作業者の工数は蓄積されており、積算時に利用し積算精度をあげている。

在庫

・ほとんど受注生産のため、在庫は管理会計で利益として計算し、BSはほとんど意識しない。
・入庫処理なし。買った分は全て仕入計上。管理会計上ではキャッシュフローの安全面重視。ただ、ほとんど当月の仕入・売りなので現状あまり問題にならない。
・当然、期末決算だけ実棚集計。

生産スケジュール

・ポイントスケジューリング方式採用(ドラム・バッファ・ロープ)

・工程の実績のデータ化はなし。
・製品/工程マスタ無し。
・現状、生産スケジュールが手作業エクセル管理で、今は単価ベースでスケジュールしている。

改善点

・必要に応じて必要な工程の通過時の記録を取る方向へ。バーコードなど簡易な方法で。
・工程スケジュールの履歴から、model nameをキーとした簡易工程マスタを作成する予定。
・ポイント以外の工程での負荷の状態が作業者任せになってしまう。

作業性

・全体的にコピペやマクロなど利用した作業速度を重視した業務フローになっており、個別の手入力など採用不可。

課題

・属人化ノウハウ喪失。
・トレーサビリティの要求に答えられるか。

エクセルデータとDBデータの同期

エクセルをUIとした場合DBにどうやってデータを登録するかが難しい。バックグラウンドでエクセルファイルから自動で同期はファイルの状態により難しい。都度手動登録はデータ重複や登録忘れの恐れがある。

改善案

CSVデータを正とする方向。

RTX1210 MTU未設定でERR_CONNECTION_RESET

NSD-G1000T — RTX1210 — PC
という構成になっているテスト環境でERR_CONNECTION_RESETが発生した。
MTUサイズを調べると以下の通り。

ping -f -l 1433 170.114.52.2
NG(要求がタイムアウト)

ping -f -l 1432 170.114.52.2
OK

※通ったサイズ+28-1にて設定。

ip lan2 mtu 1459 # no ip lan2 mtu
ip lan1 tcp mss limit auto # no ip lan1 tcp mss limit

カーソル下のウィンドウをアクティブ

control>コンピュータの簡単操作センター>マウスを使いやすくします
マウスポインターをウィンドウ上に合わせたときにウィンドウを選択します
にチェックをつける。

・タイミングを変更する方法

regedit>HKEY_CURRENT_USER\Control Panel\Desktop\ActiveWndTrkTimeout
10進数で500から好きな数字に変更

PowerShell NASバックアップスクリプト

新しいNAS(Windows Server IoT)を導入した。バックアップに専用のソフトを導入するほどの規模でもないのでPowerShell+タスクスケジューラにて設定。

-日次ミラーリングデータ*2
-1週間分の差分データ
-月次のミラーリングデータ

 

AIをどう利用するかメモ

変化の前提:AIはパラダイムシフト

AIに実装を任せる方向は今後さらに拡大していく。これは単なる効率化ではなくパラダイムシフトであり、これまでと違う考え方が必要になる。

人間側で重要になる能力

AIが基礎的な能力を身につける機会を奪う面がある一方で、人間に残る重要領域はより上流に寄っていく。今後重要になるのは、問題分解能力、意図の言語化、アーキテクチャ設計、ドメイン知識、そしてAI出力の検証である。

「全部読む」前提は破綻する

AI特有の不安定さに対して、現状では「人間が全て読んで最終判断する(経験が重要)」「責任は人間がとる」という意見がある。しかし、今後AIが生成する膨大な実装をすべて人間が理解する方法では破綻する。

本質:確定的な世界に確率的な知能を組み込む

問題の本質は、確定的なものから確率的なものへの変化にある。不安定さを前提に、それを制御するエンジニアリングが必要になる。重要なのは、確定的な世界に確率的な知能をどう組み込むかである。

解き方:ガードレールと統計的テスト

制御の具体策として、ガードレールを設けること、統計的なテストを実施することが重要になる。考え方としては、現在の工学における安全率にも近い。

実務の要:自動テストとCI/CDが競争力になる

膨大な実装を前提にするなら、自動的にテストし、継続的に検証して流せるCI/CDの仕組みが重要になる。テスト無し+ZIPで履歴管理のような従来スタイルでは競争力を完全に失う。

アーキテクチャの役割が変わる

アーキテクチャのような知識はより重要になるが、目的が変化している。これまでは「人間が修正しやすいように」だったのが、今後は「AIに作業範囲を指示できるように」という意味合いが強くなる。

目的最適化DSL:ブレを消すための“厳格な指示”

目的ごとに最適化されたDSLが重要になってくる。DSLとは厳格で再利用可能な指示のことで、プロンプトの中で定義して利用できる。狙いは結果のブレをなくすことであり、DSLの源泉はドメイン知識である。これはAIが理解するための表現であり、DSLから汎用言語への進化に逆行しているわけではない。

近い未来像:人間が指示し、実装はAIが担う

一部の最先端を除いて、「AIに何をさせるかだけ人間が決め、実装はAI」という未来は確実に近い。したがって競争力は、実装速度そのものよりも、指示の質と検証・運用の仕組みに移っていく。

現時点のボトルネック:OS操作はまだ難しい

現時点では、副作用や人間に最適化されたOS設計のため、自動でOSを操作するのは難しい領域である。今後、OSがAIに最適化されたり、副作用を理解するアプローチが進む可能性はあるが、まだ時間がかかる。

DSL

AIにDSLを書かせる

※こちらがメイン

AIが直接実行可能なコードを書くとセキュリティリスクがある。
DSLならサンドボックス化できる。

AIの暴走を防ぐという意味でこちらもガードレールの1つ。
従来のガードレールと併用。

その他にも、
インターフェースの固定(出力が安定)
ドメイン知識の注入
コマンド化することで分岐などを意識させる

DSLでAIを制御する

Guidanceなど。

 

NotebookLM

スレッドのmdを投げて、個人的な話題を消してもらう指示。

プロンプト手法

主語を省略しない。指示語(こそあど)、程度語は具体的に。
指示と素材のセクションを分ける。タスクは分割する。

推論・思考の構造化

LLMの内部推論を制御し論理的飛躍を防ぐ手法。

Chain-of-Thought (CoT)

ステップバイステップで中間的な推論を出力させる 。より複雑な思考が必要な場合、答えに至る思考プロセスを1〜2個例示としてプロンプトに含める。
弱点として間違った方向に進むと修正できない。

※プロンプト
ステップバイステップで考えてください。
論理的に一歩ずつ順を追って説明してください​。

Tree-of-Thoughts (ToT)

複数の解決策を出し、それらを自己評価・選別し、最善の道筋を絞り込む手法。

プロンプト
1.複数の案を出させて思考を枝分かれさせる。
2.各案の欠点や利点を評価させる。
3.評価の高い案での思考を前進させる。
​4.全ての案を俯瞰して合理的な結論をださせる。

Graph-of-Thoughts (GoT)

思考をノード、関係性をエッジとしてグラフ構造化。複数の思考を統合したり再利用したりする 。ToTの進化版。

※プロンプト
1.複数の案を出させて思考を枝分かれさせる。
2.各案の欠点や利点を評価させる。
3.各案を相互の関係性(トレードオフや依存関係)を評価させる。
4.統合した案はステップ2から欠点や利点を評価させる。
5.評価の高い案での思考を前進させる。
​6.全ての案を俯瞰して合理的な結論をださせる。

​終了条件

※反復回数の明示
このプロセス(統合と再評価)は最大2回まで繰り返してください
※収束条件の設定(理論的なBreak)

評価スコアが全ての項目で4以上になったら終了してください
前回案と比較して改善点が見当たらない場合は結論を出してください
※ステップの直列化(Sequential Pipeline)
ステップをあらかじめ分散→統合→最終修正のように固定する。

Skeleton-of-Thought (SoT)

回答の骨組みを先に作らせ、その各項目を並列で埋めさせることで生成速度と構造化を両立する 。

※プロンプト​
まずアウトラインや箇条書きのポイントなどを生成。
それぞれを別のプロンプトで並列に実行。

Step-Back Prompting

具体的な問題から一歩引いて背後にある一般原理や概念を先に特定させてから回答させる 。そもそも何を目指しているのかという原則に立ち返ることで、ハルシネーションを抑制し精度を大幅に高めることができます

※プロンプト
​いきなりどうすればいい。ではなく基本的な仕組みは?原則は?と質問し、その答えを踏まえてどうすればいいか確認する。

精度の自己向上・検証

AIに自身の出力を検証・修正させ、回答の信頼性を高める手法。

Self-Consistency

同じ問題に対して複数の推論パスを実行し、最も多い回答を最終解とする(多数決)。複数の異なる推論をさせると、正しい答えは一致しやすく、間違いはバラバラになりやすいという特徴がある。

Chain-of-Verification (CoVe)

回答を生成した後、その回答に含まれる事実を確認するための質問を自ら作成し、検証した上で最終回答を修正する 。
1.回答を生成させる。
2.最初の回答が正しいか​確認するために検証用に自問自答させる。
3.最初の回答と自問自答を照合し、最終的な回答にする。

Self-Ask

複雑な質問に対し自分への追加の質問を繰り返し行い、その答えを積み上げて最終回答を導く 。

Reflexion

失敗やエラー結果をフィードバックとして受け取り、次の試行で修正する反復プロセス 。

動的コンテキストと外部連携

静的なプロンプトではなく、外部情報やツールと動的にやり取りする手法。

ReAct (Reason + Act)

思考と行動のループ。外部ツールの結果を観察して次の思考へ繋げる 。

RAG (Retrieval-Augmented Generation)

外部知識を検索し、プロンプトのコンテキストとして注入する 。

Automatic Reasoning and Tool-use (ART)

タスクに最適なツールを自動的に選択し、推論プロセスに組み込む 。

Prompt Chaining

タスクをサブタスクに分割し、Aの出力をBの入力にするパイプラインを組む 。

プロンプトのメタ最適化

プロンプトそのものを生成・評価・最適化するための手法。

Meta-Prompting

プロンプトの書き方や構造そのものをAIに定義させる、あるいはプロンプトを生成するためのプロンプト 。

APE (Automatic Prompt Engineer)

多数のプロンプト候補をAIに生成させ、テストデータに対するスコアが最も高いものを自動選択する 。

DSPy (Declarative Self-improving Language Programs)

プロンプトを文字列ではなく、最適化可能なプログラムのシグネチャとして記述し、自動で最適なプロンプトやデモンストレーション(Few-shot例)をコンパイルする 。

制御とフォーマット

出力の質や形式を厳密に制御する手法。

Few-shot / One-shot / Zero-shot

例示の数による学習制御 。

Rephrase and Respond (RaR)

AIにユーザーの質問をより理解しやすい形に「言い換え」させてから回答させる 。

Flipped Interaction

AIに先に質問をさせ、ユーザーがそれに答えることで必要な情報を揃えてからタスクを実行する 。

Temperature

0.0-0.3 決定的(正確性重視)
0.7-1.0 標準
1.2-1.5 ランダム・創造的

DockerDesktop + Dify

今回はローカルにDify環境を構築

インストール

DockerDesktopインストール
https://www.docker.com/ja-jp/get-started/

クローン
git clone –branch 1.11.1 https://github.com/langgenius/dify.git

cd dify\docker

環境設定
copy .env.example .env

起動
docker compose up -d

※ここまで実行して、アクセスできなかった。

トラブルシューティング

docker compose ps
全てのコンテナがupかどうか。

ポート競合しているようだった。
.env
を編集し、
EXPOSE_NGINX_PORT=8080
と変更する。

再起動
docker compose down
docker compose up -d

アクセス
http://localhost:8080/

これでOK

GeminiCLI インストール

今回はVSCodeのターミナルで利用予定

Node バージョンアップ

node -v
npm -v

https://nodejs.org/ja/download
からダウンロード、インストールする。

npmバージョンアップ
npm install -g npm@latest
※nodeのインストールでもnpmは更新されるが最新にはならない。

GeminiCLIインストール

npm install -g @google/gemini-cli

gemini -v

初期設定

gemini

・Do you want to connect VS Code to GeminiCLI?
>1. Yes

※Failed to install VS Code companion extension. Please try installing ‘GeminiCLI Companion’ manually from the VS Code extension marketplace.
となったので後ほど個別でインストール

・How would you like to authenticate for this project?
>1. Login with Google

※ChromeからGoogleアカウントでログインして完了

GeminiCLI Companion

VSCodeにインストールすることで、開いているファイルや選択範囲を自動認識。VS Codeネイティブの差分ビューで確認・承認。コマンドパレットからGeminCLIを起動可能。IDE経由で直感的にファイル編集を提案。など可能になる。