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

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

受注

・受注用の製品マスタはある(得意先、型式、金額)のみ。
・製番管理している。仕入など全て製番管理だが、あまり枝番管理ができていない。複数台受注でも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は仕組みを知らなくても使える。ただ、なぜこのプロンプトが効くのか、なぜ長い会話の途中で前の話を忘れるのか、RAGはどういう原理で動いているのか——仕組みを少し知っていると、こういった疑問のほとんどに説明がつく。

「ステップバイステップで考えてください」が精度を上げる理由、コンテキストの最初と最後が優先されやすい理由、ハルシネーションを完全に防ぐ方法がない理由。使い方の判断に直結する知識は、思ったより少ない。

この記事はLLMの内部構造とプロンプト技法の整理メモ。深く理解する必要はないが、この程度を知っておくと使い方の引き出しが増える。

データ構造

辞書は概念では2つ、実質1つで管理している。

  • トークナイザ辞書:文字列をトークンに分割するルール集
  • トークンID辞書:トークンと整数IDの対応表

行列は大枠で4つある。

  • エンベディング行列:トークンIDを座標(ベクトル)に変換する
  • アテンション行列:アテンション処理用の行列(Wq・Wk・Wv・Wo)
    • 処理中にアテンションスコア行列(QとKから作られる一時的な行列)が生成される
    • Q・KはWq・Wkから得られる中間結果
  • フィードフォワード行列:文脈を踏まえた上で意味を深掘りする知識の源泉
  • 出力行列:最後のトークンの座標を次のトークンの確率分布に変換する

処理の流れ

(1) トークナイザーで分割

入力テキストをモデルが扱える単位(トークン)に分割する。
「りんごが好き」→「りんご」「が」「好き」

(2) トークンID辞書でトークンを整数に変換

分割されたトークンを整数IDに変換する。
「りんご」→ 12045

(3) エンベディング行列から座標を取得

整数IDに対応する多次元の座標(ベクトル)を取得する。これが以降の計算のスタート地点になる。
12045 → [0.23, -0.87, 0.41, …]

(4) アテンション処理:文脈を取り込んで座標を更新

各トークンは(3)の座標をスタートとして、アテンション行列をかけて座標を移動させる処理を繰り返す。

BERT(双方向)とGPT/Claude(一方向)の違い

BERTはすべてのトークンが互いに参照し合う双方向の設計になっている。

  • 「りんご」は「が」「好き」を吸収して座標が変わる
  • 「が」は「りんご」「好き」を吸収して座標が変わる
  • 「好き」は「りんご」「が」を吸収して座標が変わる

GPT/ClaudeはCausal Masking(一方向)の設計で、前のトークンしか参照できない。

  • 「りんご」は他のトークンを参照しない
  • 「が」は「りんご」だけを参照する
  • 「好き」は「りんご」「が」を参照する

BERTの用途:文章を「理解・分類」するタスク向き

  • Google検索(2019年〜)
  • RAGのベクトル検索部分(BERT系アーキテクチャが使われることが多い)

吸収には重みがある

「どのトークンにどれだけ注目するか」のスコアを計算して重み付きで取り込む。その重みの計算にQuery・Key・Valueという3つの行列を使う。

  • Query:「自分は何を探しているか」
  • Key:「自分は何を持っているか」
  • Value:「実際に渡す情報」

各トークンがQueryを出し、他のトークンのKeyと照合して注目度を決め、Valueを重み付きで集める。この処理が層ごとに繰り返される。層が進むごとに、単語レベルの関係から文レベル、さらに抽象的な意味へと座標が移動していく(大規模モデルだと80〜100層以上)。

KVキャッシュ

過去のトークンが計算した「Key」と「Value」はメモリに保存しておく。新しいトークンが生成されたときはその新トークンの分だけを計算し、過去のキャッシュと合流させる仕組みをKVキャッシュと呼ぶ。

フィードフォワード(知識の源泉)

各層ごとにアテンションの後にフィードフォワード処理がある。1層の中で座標は2回動く。アテンションで他のトークンの情報を取り込み(「りんご」が「好き」の影響を受けて「好意の対象としてのりんご」という文脈上の位置に移動する)、次にフィードフォワードで自分の座標だけを内部変換する。他のトークンとは無関係に、自分が持っている知識(果物、赤い、甘い、食べ物…)の中からその文脈に関連する意味を座標に反映させる。この「自分が持っている知識」がフィードフォワード行列に格納されている。

(5) 最後のトークンの座標から次の単語の確率を生成

プロンプトの最後のトークンの座標だけを使って次の単語を予測する。

  1. 最後のトークンの座標に出力行列をかけて確率分布に変換する
  2. Temperatureの設定に合わせて次のトークンを選ぶ
  3. 選んだトークンを入力に加えて(3)から繰り返す(KVキャッシュにより新トークン分のみ計算)

Temperature

Temperatureはトークン選択の確率分布の広がりを制御するパラメータ。

  • 0.0〜0.3:決定的(正確性重視)
  • 0.7〜1.0:標準
  • 1.0超:ランダム・創造的(モデルによっては1.0が上限。Claude APIなど)

コンテキストの特性

最初と最後のプロンプトが優先される仕組み

コンテキストウィンドウ内の全トークンに対してattentionを計算するため、原理的には古いトークンも新しいトークンも同等に「見える」。ただし実際には位置によるバイアスがある。

  • RLHF:最新の指示に従う挙動が学習で最適化されている
  • Positional Encoding:位置情報の扱い方はモデルによって異なる。原典のTransformerは埋め込みベクトルへの加算方式だったが、現在の主流はRoPE(Rotary Position Embedding)で、各アテンション層でQ・Kに対して回転行列として直接適用する。ALiBiのようにアテンションスコアにバイアスを加える方式も存在する
  • Lost in the Middle問題:コンテキストの中間部分は最初と最後より注目されにくい傾向がある
  • 構造的な理由:早いトークンほどそれ以降のすべてのトークンから参照されるので計算全体への影響が大きくなる

「ここまでの会話は忘れて」はある程度有効だが、影響は残ると考えておくのが妥当と言える。

強調の影響力

最初のプロンプト群はKVアンカーとして強力で、強調ワードや明示的な区切りよりも優先される。強調ワードや区切りはモデルが学習でそれを重要視するよう最適化されているか次第で、構造的な保証はない。ロールの変更はRLHFで最適化されているので途中でも効果が出やすい。

ハルシネーション

現状のLLMにはハルシネーションを確実に検知する方法がない。対策として使えるのは以下の3つ。

  • 確信度を聞く:「この回答の確信度は?」と直接聞く
  • 別の言い方で複数回聞く:ハルシネーションは一貫しないことが多い性質を利用する。ただし学習データに偏りがある場合やもっともらしい答えが1つしかない場合は一貫して同じ嘘をつくこともある。またTemperatureが低い設定だとハルシネーションでも毎回同じ答えが出てくる
  • 具体的な根拠・出典を求める:WebSearchでURLが存在していてその内容が正しいなら正確性は高いと言える

学習データの偏り

AIはインターネット上の公開情報で学習している。ここに構造的な偏りがある。

人間は公開の場では本音を出さない。ブログや論文、フォーラムに書くのは、人に見せられる形に整えた情報だ。実際の現場で起きている泥臭い判断や、理屈では説明しにくい意思決定のプロセスは、ほとんど公開されない。

つまりAIの知識は、人間の「建前」側に偏っている。教科書的に正しい答え、一般論としてもっともらしい回答は得意だが、現場の実態に即した判断は苦手になる。

この偏りを補正できるのが、現場の経験を持つ人間の役割になる。AIが出す「正しいが現実には合わない答え」に対して、「うちの現場ではこうだ」というコンテキストを与えることで、実用的な出力に近づけることができる。AIを道具として使いこなすには、この偏りを前提にしておく必要がある。

ロール

会話には3つのロールがある。

ロール 役割
システム 性格やルールを定義
ユーザ ユーザの発言
アシスタント AIの回答

プロンプトの中では各ロールが制御用マーカーで区切られているが、AIにとってはすべて「入力」として一続きに処理される。「どこまでが自分の過去の発言か」という区別はなく、全部が等しくトークンの列として見える。

RAG

RAGはユーザーが書いたプロンプトと同じ扱いになる。プロンプトに毎回膨大な情報を書けないので、ユーザーのプロンプトから関係ありそうな情報をベクトルデータベースで参照して追加する仕組みになっている。

プロンプト手法

基本の考え方:

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

Chain-of-Thought (CoT)
ステップバイステップで中間的な推論を出力させる。より複雑な思考が必要な場合、答えに至る思考プロセスを1〜2個例示としてプロンプトに含める。弱点として間違った方向に進むと修正できない。
※プロンプト:「ステップバイステップで考えてください。論理的に一歩ずつ順を追って説明してください。」

Tree-of-Thoughts (ToT)
複数の解決策を出し、それらを自己評価・選別し、最善の道筋を絞り込む手法。
※プロンプト:

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

Step-Back Prompting
具体的な問題から一歩引いて、背後にある一般原理や概念を先に特定させてから回答させる手法。原則に立ち返ることでハルシネーションを抑制し精度を高めることができる。
※プロンプト:いきなり「どうすればいい?」ではなく「基本的な仕組みは?原則は?」と質問し、その答えを踏まえてどうすればいいか確認する。

Self-Consistency
同じ問題に対して複数の推論パスを実行し、最も多い回答を最終解とする(多数決)。正しい答えは一致しやすく間違いはバラバラになりやすいという性質を利用している。

Chain-of-Verification (CoVe)
回答に含まれる事実を自ら検証してから最終回答を出す手法。

  1. 回答を生成させる
  2. その回答が正しいか確認するために自問自答させる
  3. 最初の回答と自問自答を照合して最終的な回答にする

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

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

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

Few-shot / One-shot / Zero-shot
例示の数による学習制御。

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

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


LLMと製造業の実務がどうつながるか:

シリーズ記事一覧・著者への相談はこちら →

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経由で直感的にファイル編集を提案。など可能になる。

弥生会計NW バックアップエラー

事業所データの圧縮中にエラーが発生しました。
ユーザー名またはパスワードが正しくありません。
と表示された。

クライアントPCに、SQLServerのバックアップ共有フォルダの認証情報を登録してないのが原因だろうと気付いたが、ホスト名が必要でIPアドレスではダメという部分につまづいた。

Flutter HelloWorld

初回インストール

VSCodeでFlutter拡張機能をインストール。

Ctrl+Shift+P>Flutter: New Project>Download SDK
をクリック。

Add SDK to PATH
をクリック。

使用状況などを送信する旨が表示されるので、
OKをクリック。

※無効化する場合
dart –disable-analytics

通常プロジェクト作成

Ctrl+Shift+P>Flutter: New Project
ここでプロジェクトの種類が選べる。

実行

右下でデバイスを選ぶ。
メニュー>実行>デバックの開始

デプロイ

Chromeで開発用に起動(ホットリロード)
flutter run -d chrome

本番用ビルド
flutter build web –release

WebAssembly(実験的)
flutter run -d chrome –wasm

サーバーのみ起動
flutter run -d web-server

launch.json

version:変更不要
name:任意
request:launch、attach(すでに動いているプロセスに接続)
type:dart、chrome(サーバーは起動しない)など。どのデバッガーを使うか。
deviceId:chrome、windowsなど。どのデバイスを使うか。

{
    “version”: “0.2.0”,
    “configurations”: [
        {
            “name”: “Flutter (Chrome)”,
            “request”: “launch”,
            “type”: “dart”,
            “deviceId”: “chrome”
        }
    ]
}