VPS Caddy Jitsi Meet 設定メモ

Caddy

共通ネットワーク作成
docker network create localproxy

フォルダ準備
cd /home
mkdir caddy
cd caddy

・Caddyfile

vim Caddyfile

・docker-compose.yml

vim docker-compose.yml

・コンテナ起動
docker compose up -d

Jitsi Meet

フォルダ準備
cd /home
mkdir jitsi
cd jitsi

・docker-compose.yml

vim docker-compose.yml

・コンテナ起動
docker compose up -d

・ufw
ufw allow 10000/udp

DNS

jitsi.●●●.comのAレコードをサーバーIPアドレスに向ける。

 

VBA vbac.wsf インストール

https://github.com/vbaidiot/ariawase
からzipをダウンロード、vbac.wsfを取り出す。

という構成にして、
cscript vbac.wsf decombine
を実行する。

インポートは
cscript vbac.wsf combine
を実行する。

AI/LLM Claude Code インストール

インストール

powershell
>npm install -g @anthropic-ai/claude-code
>claude

・テキストスタイル選択

Choose the text style that looks best with your terminal
To change this later, run /theme

❯ 1. Dark mode
2. Light mode
3. Dark mode (colorblind-friendly)
4. Light mode (colorblind-friendly)
5. Dark mode (ANSI colors only)
6. Light mode (ANSI colors only)

・ログイン方法

Claude Code can be used with your Claude subscription or billed based on API usage through your Console account.
Select login method:

❯ 1. Claude account with subscription · Pro, Max, Team, or Enterprise
2. Anthropic Console account · API usage billing
3. 3rd-party platform · Amazon Bedrock, Microsoft Foundry, or Vertex AI

ブラウザが開くので、承認する。

・Claude Codeのターミナル設定

Use Claude Code’s terminal setup?
For the optimal coding experience, enable the recommended settings
for your terminal: Shift+Enter for newlines

❯ 1. Yes, use recommended settings
2. No, maybe later with /terminal-setup

・セキュリティ(信頼できるプロジェクトかどうか)

Quick safety check: Is this a project you created or one you trust? (Like your own code, a well-known open source project, or work
from your team). If not, take a moment to review what’s in this folder first.
Claude Code’ll be able to read, edit, and execute files here.
Security guide

❯ 1. Yes, I trust this folder
2. No, exit

GitHub CLI

powershell
>winget install GitHub.cli
>gh auth login

 

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

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

受注

・受注用の製品マスタはある(得意先、型式、金額)のみ。
・製番管理している。仕入など全て製番管理だが、あまり枝番管理ができていない。複数台受注でも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 ランダム・創造的