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”
        }
    ]
}

起動が遅くなったプログラムの調査(.NET/SQLServer)

社内で利用しているのソフトの起動が遅くなった。ソースや詳細な仕様は手元になくSQLServer+.NETということと、サーバーへのアクセス情報だけ。

最初に表示される軽量なログイン画面の表示が遅い。ただ、ソフトを終了後、すぐに起動すると遅くならなかったりもする、維持が数秒と短いのでDBではなく、SMB+NTLMあたりが怪しい。

Process Monitor

https://learn.microsoft.com/ja-jp/sysinternals/downloads/procmon

Filter>Filter
ProcessName | Contains | xxx | Include
Add>OK

これでどのIOが遅いか明確につかめる場合もあるけど、今回はプログラムの中の処理で時間がかかっているようだった。

ILSpy

https://github.com/icsharpcode/ILSpy/releases

プログラムを開いたらエントリポイントを探す。
起動プロセスの中で、社内共有フォルダ(IPアドレス指定)にアクセス、SQLServerに接続をしていることがわかった。

これで名前解決は関係ないと分かる。

TCPView

https://learn.microsoft.com/ja-jp/sysinternals/downloads/tcpview

検索ボックスにプログラム名(または接続先IPアドレス)を入力し、プログラムを起動。接続が確立されるのはDBのみ。またタイミングからやはり共有フォルダが怪しいとなる。

どのタイミングで時間がかかっているか見づらいのでWiresharkを利用。

Wireshark

https://www.wireshark.org/

キャプチャ>開始
フィルタに
ip.src==192.168.1.xxx && ip.dst==192.168.2.xxx || ip.dst==192.168.1.xxx
このように入力した。

これで共有フォルダにアクセスにしているときが遅いことが分かった。

その他

その他に実施したこと。

・クライアント/サーバーのFirewall停止→効果無し。
・クライアント/サーバーで修復系コマンド実施→効果無し。
・該当のアドレスにpingを送信して時間確認。
・該当のアドレスのSQLSserverに接続して時間確認。
・該当のアドレスへの送信をFirewallでふさぐ→効果無し。
・ネットワーク系のキャッシュリセット→効果無し。
・ネットワーク セキュリティ: LAN Manager 認証レベルを変更→効果無し。
・ログ確認(eventvwr)
アプリケーションとサービスログ>Microsoft>Windows>SMBClient
アプリケーションとサービスログ>Microsoft>Windows>NTLM

最終的に、

gpedit.msc>コンピュータの構成>管理用テンプレート>ネットワーク>Lanmanワークステーション>暗号化が必要:無効

で解決することが判明した。

※追記

起動プロセスの中で存在しないIPアドレスへのアクセスがあり、こちらもボトルネックになっているようなので遮断することに。

Win+R>hdwwiz
一覧からインストール
ネットワークアダプター
Microsoft / Microsoft KM-TEST Loopback Adapter
Win+R>ncpa.cpl
IPv4>プロパティ
192.168.x.x / 255.255.255.255

 

YAMAHA RTX1210 拠点間接続

A拠点が固定IP、B拠点が動的環境。

B拠点(動的側)

実行前

IPsecに関する設定

GUI>簡単設定>VPN>拠点間接続>新規>IPSec
次へ

●ネットワーク環境:
接続先のみ固定のグローバルアドレスまたはネットボランチDNSホスト名を持っている

●自分側の設定
・設定名:任意
・自分側のID:test-branch(管理しやすい文字列)

●接続先の情報
・接続先のホスト名またはIPアドレス:A拠点のIPアドレス

●接続先と合わせる設定
・認証鍵:任意(大小英数字で20文字程度)
・認証アルゴリズム:HMAC-SHA(初期値そのまま)
・暗号アルゴリズム:AES-CBC(初期値そのまま)
次へ

経路に関する設定

・接続先のLAN側アドレス
192.168.1.0/255.255.255.0
次へ

実行後

A拠点(固定IP側)

IPsecに関する設定

GUI>簡単設定>VPN>拠点間接続>新規>IPSec
次へ

●ネットワーク環境:
自分側のみ固定のグローバルアドレスまたはネットボランチDNSホスト名を持っている

●自分側の設定
・設定名:任意

●接続先の情報
・接続先のID:test-branch(管理しやすい文字列)

●接続先と合わせる設定
・認証鍵:任意(大小英数字で20文字程度)
・認証アルゴリズム:HMAC-SHA(初期値そのまま)
・暗号アルゴリズム:AES-CBC(初期値そのまま)
次へ

経路に関する設定

経路を設定しない
次へ

PPPoE/CGNAT

・PPPoE(従来IPv4)

CPEにグローバルのIPv4が割り当てられる。CPEでNAPT44を行う。
任意ポート解放、着信が可能。

※NAPT44
IPv4アドレスとTCP/UDPのポート番号の両方を変換して、複数の内部IPv4ホストが1つの外部IPv4アドレスを同時共有できるようにするアドレス・ポート変換方式

・MAP‑E(v6プラス等)

CPEでNAPT44を行い、そのIPv4パケットをIPv6でカプセル化して事業者網へ送る。(IPv4overIPv6)
契約者ごとに割り当てられたIPv4アドレス+固定ポート範囲を加入者にマッピングして分離する。
理論上、任意ポートの解放、着信は可能だけど実装上は不可能。
※NUROはこの方式に移行中。

・DS‑Lite(transix等)

CPEからIPv4をIPv6にカプセル化してAFTRへ運び、AFTRでCGNAT(NAT44)する。(二重NATではない)
任意ポート解放、着信は不可。
※AFTRはISPのトンネル終端兼NAT装置。

・CGNAT

CPEの外側にISPでもう一度NATが入りIPv4を共有する(NAT444)
任意ポート解放、着信は不可。
※一般的なモバイル回線。