こんにちは！

設計レビューの前に、部品の構成や穴の種類を説明し、確認すべき点を整理する。毎回この準備から始めていませんか。3Dの中から数字を拾う作業と、その数字が何を意味するかを説明する作業を分けると、AIを使う場所がはっきりします。

CADASでは、形状から幾何解析で取り出した数値と構造をAIへ渡します。部品が5つ、歯数が15と30、連動の推定比が−0.5。こうした根拠を先に揃え、AIには部品構成の説明や、設計者に確かめたい点の言語化を任せます。通常のAI所見で外部へ送るのは解析の要約で、元のSTEPファイルはブラウザに残ります。

この記事は「AI × CAD・設計情報」シリーズの第4回です。当社が無料公開している3D CADビューワー兼AI解析ツール「CADAS」のAI所見を、どういう設計思想で作ったかを実装した側から書きます。AIの出力・送信したデータ・所要時間はすべて実物と実測値です。

減速ギアユニットで所見を生成してみる

サンプルギャラリーの減速ギアユニット（5部品）を開き、左のツールパレットからAI所見ツールを選ぶと、フローティングウィンドウが出ます。

初回の検証では、「所見を生成」を押して27秒後に結果が返りました。以下はそのときの出力からの抜粋です。生成時間と文面は実行ごとに変わります。

2枚の歯車で回転を半分の速さに落とす、減速ギアユニット（歯車で回転数を下げる装置）のアセンブリです。部品は5つ：土台の base-plate、入力側の pinion-shaft（軸）、出力側の gear-shaft、そして歯車 pinion-z15（15枚歯）と gear-z30（30枚歯）。（中略）小歯車 pinion-z15 と大歯車 gear-z30 が gear（かみ合い） で連結、比は −0.5。マイナス＝回転の向きが逆（小歯車が右回りなら大歯車は左回り）。0.5＝回転数は半分。15歯 ÷ 30歯 = 1/2 の減速です。（中略）φ9.94 と φ10.14 の 0.2 mm 差は、はめあいの違いを意図した可能性がありますが、公差情報は含まれていません。（中略）base-plate を含め全部品が rotatable: true と記録されていますが、土台が実際に回るかはデータからは断定できません。

このサンプルでは、歯数から求める減速比と回転方向が、生成したモデルの設定と一致しました。いっぽう、土台が実際に回るか、公差をどう指定したかは、この解析要約から確定できません。所見の「可能性があります」「断定できません」は、次に設計者へ確認する点を見つける手がかりになります。

AIに送ったのは、この JSON だけ

このとき、ブラウザからサーバーへ送られたリクエストの中身を、そのまま示します。

{"analysis":{
  "fileName":"gear-unit.stp（サンプル: 減速ギアユニット）",
  "solids":5, "triangles":5908,
  "bbox":{"x":110,"y":64,"z":44},
  "header":{"system":"Open CASCADE 7.9","schema":"AP214"},
  "parts":[
    {"name":"base-plate","teeth":null,"rotatable":true},
    {"name":"pinion-shaft","teeth":null,"rotatable":true},
    {"name":"gear-shaft","teeth":null,"rotatable":true},
    {"name":"pinion-z15","teeth":15,"rotatable":true},
    {"name":"gear-z30","teeth":30,"rotatable":true}],
  "couplings":[
    {"a":"pinion-z15","b":"gear-z30","kind":"gear","ratio":-0.5},
    {"a":"pinion-shaft","b":"pinion-z15","kind":"coax","ratio":1},
    {"a":"gear-shaft","b":"gear-z30","kind":"coax","ratio":1}],
  "holes":[
    {"type":"counterbore","dia":5.46,"depth":8,"count":4,"through":true,"cbDia":8.94,"cbDepth":3},
    {"type":"through","dia":9.94,"depth":12,"count":2,"through":true},
    {"type":"through","dia":10.14,"depth":16,"count":2,"through":true}],
  "fillets":[
    {"r":1.18,"kind":"cylinder","convex":false,"count":30},
    {"r":1.28,"kind":"cylinder","convex":false,"count":15},
    {"r":7.97,"kind":"cylinder","convex":true,"count":4}]
}}

STEPの本文はどこにもありません。三角形も頂点もありません。あるのは、部品名と歯数、連動関係と比、穴とフィレットの集計だけです。1.03MBのSTEPが、1KBほどの構造化データになってからAIに届きます。

この中身は、すべてCADASの幾何解析エンジンが先に作ったものです。歯数・連動・穴・フィレットといった基礎的な幾何解析は、LLMに任せていません。

幾何解析を先に済ませる。LLMには言語化と含意の指摘だけを任せる

ここがこの設計の核心です。

歯数の15と30は、各部品の回転軸まわりで外形半径 r(θ) を512分割で測り、その周期をDFTで解析して出しています。かみ合いの判定は、2部品の軸が平行で、中心距離がピッチ円半径の和（歯先円と歯数からモジュールを推定して算出）に一致し、歯の帯の高さが重なること。同軸の嵌合は、穴の半径と相手の外筒半径のすきまが0.08mm以内であること。比 −0.5 は −15/30 で、幾何から決まります。

穴とフィレットは第2回で書いた分類器の出力そのものです。

つまり、AIが受け取る時点で「何がいくつあり、何と何が連動し、比がいくらか」は、決定論的な幾何解析の結果として出そろっています（メッシュ推定を使った値は近似値で、そのまま渡します）。AIの仕事は、その事実を人に分かる言葉で説明し、事実から読み取れる設計上の含意（0.2mmの径差は意図的か、皿穴がなくザグリに統一されている、など）を指摘することです。

逆にいえば、AIに歯を数えさせたり、かみ合いを推定させたりはさせていません。LLMは数値の推論を間違えますし、間違えたときに自信ありげに書きます。設計の現場でそれをやられると、二度と使ってもらえません。決定論的な幾何解析で構造化結果を先に作り、確率的なLLMには言語化と含意の指摘だけを任せる。役割をここで切ることが、現場に信頼される条件だと考えています。

「データに無い数値は作らない」をプロンプトで縛る

所見の随所にあった「データからは断定できません」は、サーバー側のシステムプロンプトで求めているものです。要点を抜き出すと、こうなります。

与えられた構造化データだけを根拠にする。データに無い数値や事実は作らない。最初に1〜2文で結論を述べ、専門用語には短い言い換えを添える。歯車の連動があれば比の意味（増速か減速か）と回転の向きを日常語で説明する。確証が持てないことは「データからは断定できません」と明示し、断定と推測を混ぜない。

実際の所見で、ザグリ穴の用途を「土台の取付け用と考えるのが自然ですが、断定はできません」と書き、歯元のR1.18について「各歯の根元の丸みと見るのが自然です（確証はデータ上ありません）」と書いているのは、今回の実出力でも、この方針に沿った表現になっています。推測に推測のラベルが付いていれば、読む側は安心して読めます。

業務で使うために、AIへ渡す情報と使用量を揃える

公開版CADASのAI所見は、当社サーバー経由でClaudeを利用しています。モデルから得た解析結果に入力を絞り、送信量と利用回数に上限を設けています。社内へ展開する際にも、どの情報をAIへ渡すか、どの範囲で使うかを定めるための土台になる構成です。

構造化データも、部品名や寸法などの設計情報を含みます。通常の所見を使う前に、この要約を外部サービスへ送れるかを確認します。送信が認められない業務では、後述の社内LLMへの接続を含めて構成を検討します。

STEPを送る「高度な所見」でも、本文はLLMに渡さない

通常の所見とは別に「高度な所見を生成」があります。こちらはSTEPファイルの中身を当社サーバーへ送るので、押すと確認のダイアログが出ます。

サーバーがやるのは、STEPのヘッダ節と、エンティティ種別の集計（円筒面が何枚、円錐面が何枚、自由曲面が何枚）を取り出すことだけです。LLMに渡るのはこの要約で、STEP本文は要約を作ったあとにメモリ上で破棄されます。「AIに設計を見せる」と言っても、形状データが外部のLLMに流れる経路は、通常の所見にも高度な所見にもありません。

AIの所見をどう使うか

所見はMarkdownで描画され、「クリップボードにコピー」でそのまま持ち出せます。当社が想定している使い方は3つです。

ひとつは、3Dを開けない人向けの説明です。調達や品証の担当が減速ギアユニットのSTEPを受け取ったとき、「1段減速、比2、逆回転、取付はザグリ4箇所」と日本語で書いてあれば、CADを開かずに会話が始められます。

もうひとつは、設計レビューの前段です。たとえば径の違う穴が見つかったら、穴テーブルの該当行から3D上の位置を確認し、どの部品の穴かを揃えてから「この径の違いは何のためか」と設計者に尋ねます。AI所見を、モデル上で確かめられる具体的な問いにして持ち込めます。

そして3つめが、次回の主題です。この「事実から問いを立てる」仕組みは、ベテランの頭の中にしかない「なぜ」を引き出す道具になります。

読むだけで終わらせず、確認した形状へ戻れるようにする

レビューの準備として試すなら、所見から確認したい点を一つ選んでください。たとえば穴径についての記述なら、穴テーブルの対象と照らし合わせます。担当者に確かめたいことを、その位置へ付箋として手で残せば、所見の文章と3D上の対象が結び付きます。答えを聞いた後は、判断の理由を付箋に追記できます。

最新のCADASでは、比較画面で変更箇所を見たり、定義した回転機構を動かして干渉を確認したりする手段も揃いました。AI所見は解析要約を読む役割、比較と干渉検査はそれぞれの画面で形状を確かめる役割として使えます。比較と干渉検査は、それぞれの専用画面で人が根拠を確認します。

このように、AIの文章を入口にして人が根拠へ戻れると、レビュー会議に持ち込む確認事項を整理しやすくなります。実際の社内運用では、誰が確認し、どの記録を残すかまで決めることで、毎回の準備に使える道具になります。

まとめ

CADASでは、幾何解析で歯数・連動の推定・穴・フィレットを先に整理し、AIへその要約を渡します。所見から気になる点を選び、3Dや穴テーブルで場所と値を確かめる。設計レビューの準備を、この一連の流れとして進められます。

掲載した初回検証では、通常のAI所見は27秒で返りました。送ったのは解析要約で、STEP本体は手元に残りました。この実例は、形状の解析と文章による説明を分ける設計を示しています。

次回の第5回は、確認して分かった「なぜ、この形にしたのか」を形状と一緒に残す話です。設計知の伝承にローカルLLMをどう位置づけるかも扱います。その後は、設計変更の比較と、組立の動作・干渉確認へ進みます。

まずは所見を1回生成してみてください

CADASは無料・登録不要です。「ファイル > サンプルギャラリー」から減速ギアユニットか時計ムーブメントを開き、左のパレットでAI所見ツールを選んで「所見を生成」を押してください。手元のSTEPで試す場合も、通常の所見では形状データは送信されません。

CADAS（無料・登録不要）をブラウザで開く

社内のLLM基盤（オンプレミスやローカルLLM）と幾何解析を接続する構成、設計レビューにAIを組み込む運用の設計は AI × CAD・設計情報コンサルティング（無料相談） で受け付けています。

それでは、また次回、お会いしましょう！

関連リンク

【AI×CAD 第1回】設計の3Dデータ、設計部門の外で誰も見られない問題を無料＋ブラウザだけで解決する（当ブログ）

【AI×CAD 第2回】見積もりのたびに穴を数えていませんか。STEPのB-Repから穴・ザグリ・皿ザグリを自動で拾う（当ブログ）

【AI×CAD 第3回】「この形、抜けません」を設計中に知る。金型DFM（抜き勾配・アンダーカット・肉厚）をブラウザで自動チェック（当ブログ）

CADAS - 3D CADビューワー兼AI解析ツール（無料・当社開発）

AI × CAD・設計情報コンサルティング | Qualiteg（コンサルティングのご案内）

こんにちはミシェルです！

わたしの手元に、初代のRaspberry Pi Zero Wがあります。

シングルコアのARMv6、メモリ512MB、Wi-Fiは2.4GHzだけ。2017年に出た小さなボードで、いまのRaspberry Pi 5と並べると、まるで世代が違います。

この小さなボードにサーボモーターを1つつないで、Windows PCだけでヘッドレスセットアップし、インターネット越しにcurl一発でサーボを動かすところまでやってみました。

ちなみに、私ひとりの手柄ではなく、当社エンジニアの多大なるサポートでここまでこぎつけました♪

結論から言うと、SDカードの書き込みからインターネット越しにサーボが動くまで、モニターもキーボードもポート開放もなしで完走できました。

途中で1つ、面白い問題にぶつかりました。ソフトウェアPWMで動かしたサーボが、小刻みにぶるぶる震えるのです。ソフトウェアで作るPWMのタイミングの揺れが原因とみられ、SoC内蔵のハードウェアPWMに切り替えたらぴたりと止まりました。今回はこの「震えるPWM」と「震えないPWM」をHTTPのAPIで切り替えられるようにしてあります。震えの差を、インターネット越しにcurlやスマホで確かめられる作りです。

当ブログでは、Raspberry Pi 5をモニターなしでセットアップする記事から始まる三部作と、3,750円のLuckfox Pico Mを外出先から使う記事で、小さなLinuxボードを外から使う手順を書いてきました。今回はその流れで、いちばん古くていちばん非力なボードを現役に戻します。この記事の数字はすべて、2026年9月2日から3日にかけて手元の環境（Zero W Rev 1.1・Raspberry Pi OS Lite 32-bit）で実測した値です。microSDカードやネットワーク環境によって所要時間は変わります。

用意するもの

• Raspberry Pi Zero W（初代・Rev 1.1）。ピンヘッダは別売りなので、今回は40ピン全部ではなく、使うピンのまわりに3ピンのピンヘッダを2か所だけはんだ付けしました。外部電源化した現在の配線で使うのは30番（GND）と32番（GPIO12）の2本だけです

• microSDカード。今回は64GB（初回起動時に全容量まで自動拡張されます）
• micro USBの電源。基板端の「PWR IN」側に挿します
• 小型のホビーサーボ1つ（今回はSG92R）と、ジャンパーワイヤ
• サーボ用の外部電源。5V・2A以上のスイッチング電源と、外部電源の+5VとGNDの間に並列に入れる100µFの電解コンデンサ（定格電圧は5Vを上回るもの。余裕を見て10V以上を選んでもよく、今回使ったのは定格50Vのもの）、0.1µFのセラミックコンデンサ
• Windows 11のPCとUSBカードリーダー
• Git for Windows。同梱のopensslでパスワードのハッシュを作ります

モニターもHDMIケーブルも使いません。作業はすべてWindowsのPowerShellとSSHで進めます。

Zero WはRaspberry Pi 5と何が違うか。先に押さえる5点

手順そのものはRaspberry Pi 5のときとほぼ同じですが、Zero W固有の違いを知らないまま進めると、SDカードを挿しても起動しなかったり、Wi-Fiにつながらなかったりします。先に違いだけまとめます。

動作確認した環境は、書き込みソフトがRaspberry Pi Imager 2.0.8、書き込んだOSがRaspberry Pi OS Lite 32-bit（Debian 13 trixieベース、カーネル6.18）、作業PCがWindows 11 Pro（Git for Windowsを導入済み）です。

手順1: サンプルコードを取得して、32-bit LiteのOSイメージをダウンロードする

この記事で使うスクリプトとコードは、すべてGitHubのリポジトリに置いてあります。まずWindows側で取得します。以降の手順は、このフォルダをカレントディレクトリにして進めます。

mkdir C:\qualiteg_examples -Force
cd C:\qualiteg_examples
git clone https://github.com/qualiteg/wirecanal-iot-demo-raspberry-pi-zero-w-servo.git
cd wirecanal-iot-demo-raspberry-pi-zero-w-servo

Raspberry Pi Imagerがまだ入っていなければwingetで入れます。前回のRaspberry Pi 5の記事と同じです。

winget install --id RaspberryPiFoundation.RaspberryPiImager --silent --accept-package-agreements --accept-source-agreements

OSイメージは公式のダウンロードサイトから取得します。Zero W向けのURLは raspios_lite_armhf_latest です。Raspberry Pi 5のときの raspios_arm64_latest と一文字違いなので、ここを間違えると起動しないSDカードができあがります。

OSイメージは、書き込みスクリプトと同じ setup フォルダに置きます（スクリプトは自分と同じフォルダのイメージを書き込みます）。

curl.exe -L --fail -o setup\raspios-lite-armhf.img.xz https://downloads.raspberrypi.com/raspios_lite_armhf_latest

実体は 2026-06-18-raspios-trixie-armhf-lite.img.xz で、圧縮524MB、展開すると2,552MBでした。ダウンロードは1分ほどです。xz圧縮のまま書き込みに使えるので、自分で展開する必要はありません。

手順2: 設定ファイルを1つ編集して、SDカードに書き込む

Raspberry Pi 5の記事では、firstrun.sh を手で書き、Imagerのコマンドを手で組み立てました。今回は同じことをするPowerShellスクリプトを2本に分けました。設定だけを書く setup/pizero-config.ps1 と、書き込みを実行する setup/flash-pizero.ps1 です。編集するのは設定側だけです。

setup/pizero-config.ps1（全文。SSIDとパスワードはご自身のものに置き換えてください）

# ===== Raspberry Pi Zero W headless setup: settings =====
# Edit this file, then run flash-pizero.ps1.
# NOTE: the Zero W has 2.4 GHz Wi-Fi only. A 5 GHz-only SSID will never connect.

$WifiSsid     = 'YOUR_SSID'
$WifiPassword = 'YOUR_WIFI_PASSWORD'
$WifiCountry  = 'JP'

$Hostname     = 'pizero'             # a name that does not collide with raspberrypi.local
$UserName     = 'pi'
$UserPassword = 'raspberry'          # change it with `passwd` right after the first login

$Timezone     = 'Asia/Tokyo'
$Keymap       = 'jp'

$ImageFile    = 'raspios-lite-armhf.img.xz'   # the Zero W needs the 32-bit (armhf) image

書き込みスクリプトのほうは、やることが4つあります。書き込み先ディスクの安全確認、パスワードのハッシュ化、firstrun.sh の生成、Imager CLIの起動です。Wi-Fiのパスワードにシングルクォートが入っていてもfirstrun.shが壊れないように、値はシェル用にクォートしてから埋め込みます。中身の要点を抜粋します。

setup/flash-pizero.ps1（要点の抜粋。全文はGitHubのリポジトリを見てください）

# Quote a value for a POSIX shell single-quoted string ( ' becomes '\'' )
function Q([string]$v) { "'" + $v.Replace("'", "'\''") + "'" }

# --- 1. Confirm the target disk (NVMe, system/boot disks and anything over 256 GB are refused) ---
$disk = Get-Disk -Number $DiskNumber
if ($disk.BusType -eq 'NVMe' -or $disk.IsSystem -or $disk.IsBoot) {
    throw "Disk $DiskNumber ($($disk.FriendlyName)) is a system disk. Aborting."
}

# --- 2. Hash the password (openssl bundled with Git for Windows) ---
$hash = (& $openssl passwd -6 $UserPassword).Trim()

# --- 3. Generate firstrun.sh (LF line endings, no BOM; CRLF breaks the first boot) ---
$firstrun = $firstrun.Replace("`r`n", "`n")
[IO.File]::WriteAllText("$PSScriptRoot\firstrun.sh", $firstrun, (New-Object System.Text.UTF8Encoding($false)))

# --- 4. Write with Imager CLI, elevated (physical disk = \\.\PhysicalDriveN) ---
$imgArgs = @('--cli', '--debug', '--disable-eject',
             '--first-run-script', "`"$PSScriptRoot\firstrun.sh`"",
             '--log-file', "`"$logFile`"",
             "`"$PSScriptRoot\$ImageFile`"", "\\.\PhysicalDrive$DiskNumber")
Start-Process -FilePath $imager -ArgumentList $imgArgs -Verb RunAs -Wait

生成される firstrun.sh は、Raspberry Pi OSに標準で入っているヘルパーを呼ぶだけの短いものです。ホスト名、SSH、ユーザー、Wi-Fi、キーボード配列、タイムゾーンをまとめて設定し、最後に自分自身を消して通常起動に戻します。

firstrun.sh（スクリプトが生成するもの・全文）

#!/bin/bash
set +e
/usr/lib/raspberrypi-sys-mods/imager_custom set_hostname 'pizero'
/usr/lib/raspberrypi-sys-mods/imager_custom enable_ssh
/usr/lib/userconf-pi/userconf 'pi' '$6$…（openssl passwd -6 で生成したハッシュ）'
/usr/lib/raspberrypi-sys-mods/imager_custom set_wlan 'YOUR_SSID' 'YOUR_WIFI_PASSWORD' 'JP'
/usr/lib/raspberrypi-sys-mods/imager_custom set_keymap 'jp'
/usr/lib/raspberrypi-sys-mods/imager_custom set_timezone 'Asia/Tokyo'
rm -f /boot/firstrun.sh /boot/firmware/firstrun.sh
sed -i 's| systemd.run.*||g' /boot/cmdline.txt /boot/firmware/cmdline.txt 2>/dev/null
exit 0

SDカードをカードリーダーに挿し、ディスク番号を確認してから、setup フォルダで実行します。

cd setup
Get-Disk
# Number FriendlyName           BusType SizeGB
# ------ ------------           ------- ------
#      0 CT4000P3PSSD8          NVMe      3726
#      1 Generic- SD/MMC/MS PRO USB       59.5

.\flash-pizero.ps1 -DiskNumber 1

UACのダイアログが出たら許可します。書き込みは107秒、読み戻しの検証は67秒で、合わせて184秒で終わりました。ログの最後に succeeded が出ていれば成功です。

[DEBUG] Write done in 107 seconds
[DEBUG] Verify hash: "235aae6e32f40eb294b6485f99232d9ea5b6ee0251c8dc40e370177fac4754c2"
[DEBUG] Verify done in 66.945 seconds
[DEBUG] writeFile: updateDirEntry succeeded for "firstrun.sh"
[DEBUG] writeFile: updateDirEntry succeeded for "cmdline.txt"
[DEBUG] PerformanceStats: Cycle ended, state: "succeeded"

ここで1つ、実際に踏んだ罠を書いておきます。最初の書き込みは、ログが「Drive added」の直後で終わり、エラーも出ないまま4秒で終了しました。原因は書き込み先の指定が \.\PhysicalDrive1 とバックスラッシュ1本欠けになっていたことです。Imagerは「Destination drive is not in list of removable volumes」で終了するのですが、このメッセージは標準エラー出力にしか出ず、GUIアプリとしてビルドされているためコンソールにも --log-file にも残りません。書き込み先は \\.\PhysicalDriveN と、バックスラッシュ2本で書いてください。

手順3: 電源を入れて5分待ち、SSHでつなぐ

SDカードをZero Wに挿し、基板端の「PWR IN」側のmicro USBに電源をつなぎます。緑のLEDが不規則に点滅している間は起動処理中です。初回はファイルシステムの拡張と firstrun.sh の実行と自動再起動が走るので、Raspberry Pi 5より長く、5分ほど待ちます。

実測のタイムラインです。18時45分に電源を入れ、18時50分07秒にLAN上へRaspberry Piのアドレスが現れ、18時50分39秒にSSHでログインできました。

ssh pi@pizero.local

ログイン後の状態も確認しました。uname -a、vcgencmd measure_temp、free -m、df -h の出力の抜粋です。

Linux pizero 6.18.34+rpt-rpi-v6 #1 Raspbian 1:6.18.34-1+rpt1 (2026-06-09) armv6l GNU/Linux
temp=40.6'C
               total        used        free      shared  buff/cache   available
Mem:           426Mi       116Mi       244Mi       2.4Mi       116Mi       310Mi
/dev/mmcblk0p2   59G  2.1G   54G   4% /

64GBカードの全域がルートファイルシステムに拡張済みで、メモリは426MBのうち116MBを使用、CPU温度は40.6度でした。pizero.local という名前はmDNSで解決され、Windows 11は標準で対応しているので追加のソフトは要りません。

Zero Wは電源を入れてからLANに出てくるまで5分近くかかるので、名前が引けないときは ping pizero.local を繰り返すより、PC側で arp -a を見てRaspberry PiのMACアドレス（今回の個体では b8-27-eb で始まっていました）を探すほうが早く見つかります。

初期パスワードのままだとログインのたびに警告が出るので、最初のログインで passwd を実行して変えておいてください。

手順4: サーボをGPIO12につないで、まずソフトウェアPWMで動かす

ここからが本題です。まずZero Wのピン配置を図1に載せておきます。実機で pinout コマンド（gpiozero付属）を実行した結果をもとに描いたものです。

サーボ自体は3線です。信号線をGPIO12（物理ピン32）へ、電源とGNDは外部の5V電源（今回は5V・2Aのスイッチング電源）へつなぎます。さらに、PWM信号の基準電位をそろえるため、外部電源のマイナス側をZero Wの物理ピン30のGNDにも接続して共通GNDにします。接続は信号、外部+5V→サーボ、外部GND→サーボ、外部GND→Zero Wの30番の4系統です。外部電源のプラスはZero Wの5Vピン（物理ピン2・4）には接続しません。共通にするのはGNDだけです。サーボが動くたびに電源が揺れるのを抑えるため、外部電源の+5VとGNDの間に100µFの電解コンデンサと0.1µFのセラミックコンデンサを並列に入れました。

電解コンデンサは有極性なので、プラスを+5V、マイナスをGNDへつなぎます（定格電圧は5Vより高いものを使います）。最初はZero Wの5Vピン（物理ピン2）から給電していて、小型のホビーサーボ1つなら実測上は動きましたが、サーボの電源はZero Wと分けたほうが安全なので外部電源に切り替えました。3.3Vのピンからサーボに給電してはいけません。GPIO12を選んだのには理由があって、後でハードウェアPWMに切り替えるときに使えるピンだからです。

今回使った2026-06-18版のRaspberry Pi OS Lite 32-bitには、Pythonの gpiozero と lgpio が最初から入っています。追加インストールなしで、gpiozeroの Servo クラスをlgpioのピンファクトリで使うと、50HzのソフトウェアPWMでサーボが動きます。1.0msと2.0msのパルス幅を2秒ごとに切り替える、往復するだけのスクリプトです。

app/sweep2.py（全文）

#!/usr/bin/env python3
"""Sweep a servo on GPIO12 between two positions every 2 s using SOFTWARE PWM (gpiozero + lgpio, 50 Hz).

Software PWM timing can vary under Linux scheduling; on this single-core Zero W the servo visibly trembled.
Compare with sweep2_hw.py (hardware PWM).
"""
import time, signal, sys
from gpiozero import Servo
from gpiozero.pins.lgpio import LGPIOFactory

PIN = 12
# 1.0 ms / 2.0 ms pulses are the two end positions (the usual range for hobby servos).
# For a wider swing use min_pulse_width=0.5/1000, max_pulse_width=2.5/1000.
servo = Servo(PIN, pin_factory=LGPIOFactory(),
              min_pulse_width=1.0/1000, max_pulse_width=2.0/1000, frame_width=20/1000)

POS_A, POS_B = -1.0, 1.0     # -1 = min_pulse_width, +1 = max_pulse_width
INTERVAL = 2.0

def stop(*_):
    servo.detach()            # stop the signal (servo relaxes)
    sys.exit(0)
signal.signal(signal.SIGTERM, stop)
signal.signal(signal.SIGINT, stop)

print(f"GPIO{PIN}: {POS_A} <-> {POS_B} every {INTERVAL}s  (Ctrl+C / SIGTERM to stop)", flush=True)
pos = POS_A
while True:
    servo.value = pos
    print(time.strftime("%H:%M:%S"), "pos", pos, flush=True)
    time.sleep(INTERVAL)
    pos = POS_B if pos == POS_A else POS_A

Windowsのリポジトリのフォルダから転送して、バックグラウンドで起動します。Zero W側には先に置き場所を作っておきます。

ssh pi@pizero.local "mkdir -p ~/servo"
scp app\sweep2.py app\sweep2_hw.py pi@pizero.local:servo/
ssh pi@pizero.local 'cd servo && (nohup python3 sweep2.py > sweep2.log 2>&1 &)'

サーボは動きました。2秒ごとに右へ、左へ。ただ、止まっている位置で小刻みにぶるぶる震えています。

以下の動画の前半でご確認いただけます。ぶるぶるふるえています。

これがソフトウェアPWMのジッタです。ソフトウェアで作るPWMはCPUがタイミングを刻んでパルスを作るので、Linuxのスケジューリングや他の処理の影響で、パルスの立ち上がりと立ち下がりのタイミングが揺れることがあります。今回のZero Wでは、その影響とみられる小刻みな震えが目視できました。パルス幅の揺れそのものはオシロスコープで測っていないので、ここで数字は出しません。手元の環境ではgpiozeroも起動時に PWMSoftwareFallback という警告を出して、ソフトウェアPWMで動いていることを教えてくれました。

もうひとつ、ここで踏んだ小さな罠を書いておきます。止めるときに pkill -f sweep2.py と書くと、SSH経由で実行しているシェル自身のコマンド列にも sweep2.py が含まれるので自分を殺してしまい、sshが終了コード255で黙って切れます。完全一致の pkill -xf "python3 sweep2.py" にしてください。

手順5: ハードウェアPWMに切り替えて、震えを止める

GPIO12は、SoCのPWM0という回路につながるピンです。デバイスツリーのオーバーレイでこれを有効にすると、パルスをCPUではなくSoC内蔵のPWM回路が作るようになり、CPU負荷やスケジューリングの影響を受けにくくなります。追加パッケージは要らず、設定を1行足して再起動するだけです。pin=12 の12はBCMのGPIO番号で、物理ピン番号（32）ではありません。

echo 'dtoverlay=pwm,pin=12,func=4' | sudo tee -a /boot/firmware/config.txt
sudo reboot

再起動後、今回の環境では /sys/class/pwm/pwmchip0 が現れ、pinctrl get 12 の表示が GPIO12 = PWM0 に変わります。あとはsysfsに数字を書き込むだけでサーボが動きます。piユーザーはgpioグループに入っているので、sudoは要りません。

echo 0        > /sys/class/pwm/pwmchip0/export
sleep 0.3     # pwm0 ディレクトリと gpio グループの権限が付くのを待つ
echo 20000000 > /sys/class/pwm/pwmchip0/pwm0/period       # 20ms = 50Hz
echo 1500000  > /sys/class/pwm/pwmchip0/pwm0/duty_cycle   # 1.5ms = 中央
echo 1        > /sys/class/pwm/pwmchip0/pwm0/enable

往復スクリプトのハードウェアPWM版は、gpiozeroの代わりにこのsysfsを書くだけです。

app/sweep2_hw.py（抜粋。全文はGitHubのリポジトリを見てください）

CHIP = "/sys/class/pwm/pwmchip0"
PERIOD_NS = 20_000_000       # 20ms = 50Hz
PULSE_A_NS = 1_000_000       # 1.0ms
PULSE_B_NS = 2_000_000       # 2.0ms

def w(path, val):
    with open(path, "w") as f:
        f.write(str(val))

w(f"{CHIP}/pwm0/period", PERIOD_NS)
w(f"{CHIP}/pwm0/duty_cycle", PULSE_A_NS)
w(f"{CHIP}/pwm0/enable", 1)
pulse = PULSE_A_NS
while True:
    w(f"{CHIP}/pwm0/duty_cycle", pulse)
    time.sleep(INTERVAL)
    pulse = PULSE_B_NS if pulse == PULSE_A_NS else PULSE_A_NS

手順4と同じ置き場所から、バックグラウンドで起動します。スクリプトは起動時にいったん enable=0 にしてから周期とパルス幅を書き込み、止めるとき（SIGTERM）にも enable=0 にして信号を止めます。

cd ~/servo && (nohup python3 sweep2_hw.py > sweep2_hw.log 2>&1 &)
# 止めるとき（完全一致で指定する。理由は手順4の罠と同じ）
pkill -xf "python3 sweep2_hw.py"

これで震えは止まりました。

先ほどの動画の後半をご覧くださいませ。

2秒ごとにカチッと動いて、ぴたりと止まります。pinctrl get 12 の出力と、sysfsの値を確認したときの実測です。次の手順のAPIサーバーに進む前に、上の pkill で止めておいてください。GPIO12を握ったままのプロセスが残っていると、APIサーバーが同じピンを使えません。

12: a0    -- | lo // GPIO12 = PWM0
period=20000000 duty_cycle=1000000 enable=1

ちなみに、公式のオーバーレイ一覧によると、ハードウェアPWMを出せる代表的なピンはGPIO12とGPIO18（PWM0）、GPIO13とGPIO19（PWM1）です。オンボードのアナログ音声出力も両方のPWMチャンネルを使うので、音声と併用するときは注意が要ります。今回のLite版のヘッドレス構成では関係ありません。それ以外のピンでジッタを抑えてサーボを動かしたいなら、DMAでタイミングを作る pigpio を入れる手があります。今回は追加インストールなしで済ませたかったので、ハードウェアPWMのピンを選びました。

手順6: 「震える」と「震えない」を切り替えるAPIサーバーを立てる

震えの差を、手元のPCやスマホから自分の指で確かめられるようにしたくなりました。そこで、ソフトウェアPWMとハードウェアPWMをHTTPのAPIで切り替える小さなサーバーをZero Wに置きます。HTTPサーバーの部分はPythonの標準ライブラリだけで実装し、GPIOの制御には今回使ったOSイメージに入っているgpiozeroとlgpioを使うので、追加インストールはありません。

APIは2本だけです。

どのモードでも1.0msと2.0msのパルスを2秒ごとに往復するので、動きは同じで、震えの差だけが見えます。第2回では、ここに角度を指定するAPIを足して、最後にはMCPサーバーにしてChatGPTから直接動かすところまでやる予定です。

実装で気をつけたのは、同じGPIO12でモードを往復させる順番です。ソフトウェアPWMに入るとlgpioがピンを普通の出力ピンに変えてしまうので、ハードウェアPWMに戻すときは pinctrl set 12 a0 でピンの機能をPWM0に戻してからsysfsを有効にします。この1行がないと、sysfsに書いても何も出ません。

app/api_server.py（モード切替の部分・抜粋。全文はGitHubのリポジトリを見てください）

def _enter(self, mode):
    if mode == "soft":
        self._factory = LGPIOFactory()
        self._servo = Servo(PIN, pin_factory=self._factory,
                            min_pulse_width=PULSE_A_NS / 1e9, max_pulse_width=PULSE_B_NS / 1e9,
                            frame_width=PERIOD_NS / 1e9)
    elif mode == "hard":
        pinctrl("set", str(PIN), "a0")           # lgpio leaves the pin as input/output: put it back to PWM0
        if not os.path.exists(PWM_DIR):
            sysfs_write(f"{PWM_CHIP}/export", PWM_CH)
            time.sleep(0.3)                      # wait for udev to apply the gpio-group permissions
        sysfs_write(f"{PWM_DIR}/enable", 0)
        sysfs_write(f"{PWM_DIR}/period", PERIOD_NS)
        sysfs_write(f"{PWM_DIR}/duty_cycle", self.pulse_ns)
        sysfs_write(f"{PWM_DIR}/enable", 1)

def _leave(self, mode):
    if mode == "soft":
        self._servo.detach(); self._servo.close(); self._factory.close()
    elif mode == "hard":
        sysfs_write(f"{PWM_DIR}/enable", 0)

GPIOを触るのはワーカースレッド1本だけにして、HTTP側は「次のモードはこれ」と要求を置くだけにしてあります。同時に複数のリクエストが来てもGPIOの操作が交錯しないようにするためです。待ち受けは 127.0.0.1:18080 だけで、LANには直接公開しません。外からのアクセスは次の手順でWireCanalのAgentがこのloopbackへ届けてくれるので、ルーターやファイアウォールでインターネット向けの受信ポートを開ける必要がないのです。

ここでもZero Wならではの罠がありました。最初の版では、ソフトウェアPWMへ切り替えるAPIの応答が古いモードのまま返ってきました。原因はgpiozeroの初回importがZero Wでは数秒かかることで、切り替え完了を待つ時間を超えていたのです。起動時にimportを済ませておくように直して解決しました。

systemdで常駐させます。piユーザーで動かせばgpioグループの権限でsysfsに書けます。

systemd/servo-api.service（全文）

[Unit]
Description=Pi Zero W servo demo API server (127.0.0.1:18080, hosts web UI)
After=network.target

[Service]
User=pi
WorkingDirectory=/home/pi/servo_demo
ExecStart=/usr/bin/python3 /home/pi/servo_demo/api_server.py
Restart=always
RestartSec=3
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=multi-user.target

まずWindowsのリポジトリのフォルダから、app と systemd をZero Wへ転送します。

ssh pi@pizero.local "mkdir -p ~/servo_src"
scp -r app systemd pi@pizero.local:servo_src/

ここからはZero W側です。

cd ~/servo_src
mkdir -p ~/servo_demo && cp -r app/api_server.py app/web ~/servo_demo/
sudo install -m 644 systemd/servo-api.service /etc/systemd/system/servo-api.service
sudo systemctl daemon-reload
sudo systemctl enable --now servo-api
curl -s http://127.0.0.1:18080/healthz   # ok

Zero Wの上で、まずローカルのcurlで叩いてみます。状態の取得はこうです。

curl -s http://127.0.0.1:18080/api/status

{"mode": "off", "requested": "off", "pulse_ms": 1.0, "switches": 0, "since": 1788363789.7433455, "last_error": "", "pin": "12: ip    -- | lo // GPIO12 = input", "board": {"hostname": "pizero", "arch": "armv6l", "model": "Raspberry Pi Zero W Rev 1.1", "cpu_temp_c": 41.2, "uptime_s": 8829}, "server_uptime_s": 103}

モードの切り替えはPOSTです。ハードウェアPWMに切り替えると、応答の pin が GPIO12 = PWM0 になって、サーボが往復を始めます。

curl -s -X POST -H "Content-Type: application/json" -d '{"mode":"hard"}' http://127.0.0.1:18080/api/mode

{"mode": "hard", "requested": "hard", "pulse_ms": 2.0, "switches": 1, "since": 1788364513.3218658, "last_error": "", "pin": "12: a0    -- | lo // GPIO12 = PWM0", "board": {"hostname": "pizero", "arch": "armv6l", "model": "Raspberry Pi Zero W Rev 1.1", "cpu_temp_c": 41.2, "uptime_s": 9464}, "server_uptime_s": 738}

このとき pinctrl get 12 とsysfsの値を見ると、PWM0が有効になって20msの周期で2.0msのパルスが出ています。

$ pinctrl get 12
12: a0    -- | lo // GPIO12 = PWM0
$ cat /sys/class/pwm/pwmchip0/pwm0/period /sys/class/pwm/pwmchip0/pwm0/duty_cycle /sys/class/pwm/pwmchip0/pwm0/enable
20000000 2000000 1

止めるときは {"mode":"off"} を送るだけです。

curl -s -X POST -H "Content-Type: application/json" -d '{"mode":"off"}' http://127.0.0.1:18080/api/mode

おまけとして、同じサーバーがブラウザ向けの小さな画面も返します。画面はJavaScriptからこのAPIをfetchで呼んでいるだけで、GPIOのことは何も知りません。第2回で角度を指定できるようにしたときも、この画面側に触る必要はありません。

手順7: WireCanalのcanalを作って、Zero Wに公開URLをつける

ここからインターネット側に出します。使うのは当社のWireCanalです。Zero Wから外向きの接続を張るだけでHTTPSの公開URLがつく仕組みで、ルーターのポート開放も固定IPも要りません。無料プランで進めます。

app.wirecanal.com にログインして「新しいcanalを作成」を押すと、4ステップのウィザードが始まります。

種類はHTTP、公開アドレスは「おまかせサブドメイン」、転送先にZero WのAPIサーバーの localhost:18080 を入れます。

作成すると、canal詳細に公開URLと接続ファイル wirecanal.json が表示されます。このファイルにはそのcanal用の接続キーが入っているので、「wirecanal.json をダウンロード」で手元に落とし、ダウンロードしたフォルダからZero Wのホームへ運びます。

scp .\wirecanal.json pi@pizero.local:~/

同じ画面の「Linux」タブに、次の手順で使うコマンドがそのまま出ています。

手順8: Zero WにAgentを入れて、systemdで常駐させる

Zero W側の作業は、公式のLinuxセットアップガイドのとおりです。CPUの種類（今回はarmv6l）はインストーラが自動で判定するので、Raspberry Pi 5のときと同じ1行で入ります。

sudo mkdir -p /opt/wirecanal && cd /opt/wirecanal
curl -fsSL https://download.wirecanal.com/install.sh | sudo sh

WireCanal Agent v.0.18.3 をダウンロードしています...
wirecanal v.0.18.3 powered by Qualiteg Inc. https://qualiteg.com

インストール完了: /opt/wirecanal/wirecanal
次の手順:
  1. ダッシュボード（https://app.wirecanal.com）の canal 詳細から wirecanal.json を
     ダウンロードして、wirecanal と同じフォルダに置く
  2. 起動: ./wirecanal -config wirecanal.json

入ったのは、ランタイム不要の静的リンクされた32-bit ARMのバイナリで、9.8MBでした。

$ file /opt/wirecanal/wirecanal
/opt/wirecanal/wirecanal: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked

手順7でホームに運んだ wirecanal.json を同じディレクトリに置き、専用ユーザーとsystemdの雛形を用意します。/opt/wirecanal はroot所有なので、ホームから sudo install でコピーします。雛形は公式ガイドに載っているものをそのまま使いました。

sudo install -m 600 ~/wirecanal.json /opt/wirecanal/wirecanal.json
sudo useradd --system --home /opt/wirecanal --shell /usr/sbin/nologin wirecanal
sudo chown -R wirecanal: /opt/wirecanal

/etc/systemd/system/wirecanal.service（全文）

[Unit]
Description=WireCanal Agent
After=network-online.target
Wants=network-online.target

[Service]
User=wirecanal
WorkingDirectory=/opt/wirecanal
ExecStart=/opt/wirecanal/wirecanal -config /opt/wirecanal/wirecanal.json
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now wirecanal
journalctl -u wirecanal -f

起動ログです。起動から2秒で「届けます」の行が出て、開通しました。

wirecanal v.0.18.3 powered by Qualiteg Inc. https://qualiteg.com
wirecanal: 自動更新が有効です（無効化は wirecanal.json に "auto_update": false）
wirecanal: canal d7t2: https://5jk3hvty.ja000.wirecanal.com へのアクセスをローカルの転送先 localhost:18080 に届けます
wirecanal 0.18.3: connecting tenant=d7t2 mode=http forward_target=localhost:18080

ダッシュボード側も「接続中」に変わります。

インターネットの向こう側からcurlで叩く

はい！ここが今回のゴールです。

Zero Wの上で叩いたのと同じAPIを、手元のWindows PCから公開URLに向けて叩きます。PCはZero Wと同じ家のLANにいますが、公開URLはWireCanalのエッジ（東京）を経由するので、経路はインターネット越しです。URLが変わるだけで、コマンドはほぼそのままです。違いは、Windowsでは curl.exe と拡張子まで書くことです。Windows PowerShell 5.1では curl が Invoke-WebRequest の別名になっていて本物のcurlが隠れるためで、手順1のダウンロードで curl.exe と書いたのも同じ理由です。

curl.exe -s https://5jk3hvty.ja000.wirecanal.com/api/status

{"mode": "off", "requested": "off", "pulse_ms": 1.0, "switches": 0, "since": 1788363789.7433455, "last_error": "", "pin": "12: ip    -- | lo // GPIO12 = input", "board": {"hostname": "pizero", "arch": "armv6l", "model": "Raspberry Pi Zero W Rev 1.1", "cpu_temp_c": 41.2, "uptime_s": 8829}, "server_uptime_s": 103}

モードの切り替えも同じです。手元のPCから、ハードウェアPWMで往復を始めさせます。

curl.exe -s -X POST -H "Content-Type: application/json" -d '{"mode":"hard"}' https://5jk3hvty.ja000.wirecanal.com/api/mode

{"mode": "hard", "requested": "hard", "pulse_ms": 1.0, "switches": 1, "since": 1788364513.3218658, "last_error": "", "pin": "12: a0    -- | hi // GPIO12 = PWM0", "board": {"hostname": "pizero", "arch": "armv6l", "model": "Raspberry Pi Zero W Rev 1.1", "cpu_temp_c": 39.5, "uptime_s": 9449}, "server_uptime_s": 723}

応答の pin が GPIO12 = PWM0 になり、Zero Wの隣でサーボがカチッと動き始めました。ソフトウェアPWMに切り替えると GPIO12 = output になって、震えながら往復します。

curl.exe -s -X POST -H "Content-Type: application/json" -d '{"mode":"soft"}' https://5jk3hvty.ja000.wirecanal.com/api/mode

{"mode": "soft", "requested": "soft", "pulse_ms": 1.0, "switches": 2, "since": 1788364534.6957178, "last_error": "", "pin": "12: op -- -- | lo // GPIO12 = output", "board": {"hostname": "pizero", "arch": "armv6l", "model": "Raspberry Pi Zero W Rev 1.1", "cpu_temp_c": 40.1, "uptime_s": 9470}, "server_uptime_s": 744}

最後に止めます。

curl.exe -s -X POST -H "Content-Type: application/json" -d '{"mode":"off"}' https://5jk3hvty.ja000.wirecanal.com/api/mode

上の書き方はPowerShell 7のものです。Windows PowerShell 5.1では、JSONの中の二重引用符が curl.exe に渡る前に外されてしまうので、-d '{\"mode\":\"hard\"}' のようにバックスラッシュでエスケープしてください。5.1でそのまま渡すと、APIから {"error": "mode must be one of off/soft/hard"} が返ってくるのを実測しました（7では同じ書き方で通ります）。

{"mode": "off", "requested": "off", "pulse_ms": 2.0, "switches": 3, "since": 1788364558.2063227, "last_error": "", "pin": "12: ip    -- | lo // GPIO12 = input", "board": {"hostname": "pizero", "arch": "armv6l", "model": "Raspberry Pi Zero W Rev 1.1", "cpu_temp_c": 39.0, "uptime_s": 9494}, "server_uptime_s": 768}

curlで叩けるということは、スクリプトからでもcronからでもCIからでも叩けるということです。第2回でMCPサーバーにするのも、この延長線上です。

Zero W側のAgentのログには、外からのアクセスがそのまま記録されていました。

wirecanal: access: 2026-09-02 21:23:43 xxx.xxx.xxx.xxx GET / → 200
wirecanal: access: 2026-09-02 21:23:43 xxx.xxx.xxx.xxx GET /api/status → 200
wirecanal: access: 2026-09-02 21:23:44 xxx.xxx.xxx.xxx POST /api/mode → 200

ブラウザで公開URLを開けば、さきほどの画面がそのまま出ます。スマホの画面幅でもボタンが指で押せる大きさになるように作ってあるので、iPhoneから「Software PWM」と「Hardware PWM」を押し比べると、震えの差が指先で分かります。

再起動しても、公開URLまで自動で復帰した

APIサーバーとAgentの両方をsystemdで常駐させたので、再起動すれば何もしなくても戻るはずです。sudo systemctl reboot を実行した瞬間から時間を測りました。

手を触れずに公開URLまで戻りました。電源を抜いて入れ直す場合の時間は今回は測っていませんが、同じsystemdの設定で自動起動する構成なので、目安として電源を入れてから2分ほど待ってからURLを開いてください。

今回の実験の諸元をまとめる

ハマりどころと回避策

2017年のボードでも、外から届くサーボになった

Raspberry Pi Zero Wは、シングルコアでメモリ512MB、Wi-Fiは2.4GHzだけのボードです。それでも、SDカードの書き込みからインターネット越しにサーボが動くまでに必要だったのは、この記事に書いた手順だけでした。ルーターやファイアウォールでインターネット向けの受信ポートは最後まで開けていません（APIサーバーが待ち受けるのはZero W上の 127.0.0.1:18080 だけです）し、WireCanalは無料プランのままです。

Raspberry Pi 5のときと違ったのは、OSを32-bit版にすることと、初回起動を5分待つことと、サーボの震えをハードウェアPWMで止めることでした。逆に言うと、Agentのやること自体は同じで、install.sh がarmv6lを判定してバイナリを置き、wirecanal.jsonを隣に置いて起動する。それだけです。

今回はサーボ1つでしたが、GPIOなどから制御できる機器にも、この構成をそのまま応用できます。

第2回では、角度を指定できるAPIを足してcurlで好きな角度に動かし、最後にこのZero WをMCPサーバーにしてChatGPTから直接動かすところまでやります！

それでは、また次回お会いしましょう！

出典・参考

• Raspberry Pi Imager（公式ダウンロードページ）
• Raspberry Pi OS イメージ一覧（公式ダウンロードサイト。Lite 32-bit版もここ）
• config.txt のリファレンス（Raspberry Pi 公式ドキュメント）
• デバイスツリーオーバーレイの一覧 README（raspberrypi/firmware・GitHub。pwm オーバーレイの pin と func の組み合わせ、音声との併用の注意もここ）
• gpiozero の Servo クラス（公式ドキュメント）
• サンプルコード一式（GitHub: qualiteg/wirecanal-iot-demo-raspberry-pi-zero-w-servo・記事執筆時点のコミット）
• WireCanal Linuxセットアップガイド（Agentのインストールとsystemd常駐の手順）
• WireCanal IoTデバイス対応ページ（対応チップ＋Linuxの組み合わせと、対応チップを搭載したデバイスの例）

関連記事

• Raspberry Pi 5をモニターなしでセットアップする。Windows PCだけでOS書き込みからSSH接続まで
• Raspberry Pi 5を堅牢化する。SSH鍵認証・UFW・fail2banと、再起動でIPv6が復活する罠
• Raspberry Pi 5のWebサーバーをインターネットに公開する。ポートは開けない、WireCanalのトンネルで
• Luckfox Pico Mを外出先から使う。3,750円・64MBのLinuxボードにWireCanalで公開URLをつけるまで

こんにちは！

3Dデータを金型メーカーに渡したあと、こういう連絡が戻ってきたことはないでしょうか。

「この横穴、Z抜きだと抜けません」

「このリブ、勾配が付いていません」

「ここ、肉が厚すぎてヒケます」。

指摘そのものは正しい。ただ、それが返ってくるのは、設計がひととおり終わって図面を出したあとです。直すのはこちらで、直したらまた確認の往復が始まります。

抜き勾配・アンダーカット・局所的な肉厚は、型開き方向を決めると、形状から要注意箇所を一次チェックできます。設計中に候補を見つけておけば、金型メーカーとの打ち合わせを「どこが問題か」から「この箇所をどう直すか」へ進められます。材料や成形条件を踏まえた判断には、その候補と3D形状を持って臨みます。

この記事は「AI × CAD・設計情報」シリーズの第3回です。当社が無料公開している3D CADビューワー兼AI解析ツール「CADAS」に積んだ金型DFM（抜き勾配・アンダーカット・肉厚・リブ／ボス検出）を、正解の分かる樹脂ケースで実走し、その仕組みを実装した側から書きます。数値はすべて実測値です。

勾配のないリブと横穴を持つ樹脂ケースで試す

検証には、答えの分かっているモデルが要ります。CADASのサンプルギャラリーにある「樹脂ケース」は、当社がcadqueryで生成した金型部品風のモデルで、意図的に次の要素を入れてあります。

846三角形の小さなモデルです。読み込みは筆者環境（Windows＋Chrome）で2.4秒でした。

型開き方向を決めて「抜き勾配を解析」を押す

左のツールパレットから金型DFMツール（Dキー）を選ぶと、フローティングウィンドウが開きます。型開き方向（既定はZ）と勾配しきい値（0.5〜5°）を決めて「抜き勾配を解析」を押すだけです。

結果はこうでした。

要勾配（1°未満）が面積の11.8%。黄色に塗られているのはリブ2枚とボス2本の垂直面で、設計で勾配を付けていない場所そのものです。2°の勾配を付けた外壁と内壁は、キャビティ側（緑）とコア側（青）にきれいに分かれました。

アンダーカットは面積の0.2%、111面素。赤く塗られているのは側壁の横穴の内壁だけです。モデルを回して+X側の壁を見ると、穴の縁が赤い輪になっています。

ここまでで、金型メーカーから戻ってくる3つの指摘のうち2つ（勾配なし・抜けない）が、ボタン1回で色になりました。

判定の中身は、面の向きとレイの遮蔽

抜き勾配の分類は単純です。三角形ごとに法線 n と型開き方向 d の内積をとると、それが勾配角の正弦になります。θ = asin(n·d) で、θ がしきい値より大きければキャビティ側で抜ける面、−θ がしきい値より大きければコア側で抜ける面、絶対値がしきい値未満なら垂直に近い「要勾配」です。

アンダーカットは、それだけでは分かりません。面自体は抜ける向きを向いていても、その先に自分の別の部分が被さっていれば抜けないからです。そこで、要勾配以外の全三角形について、重心から「抜ける方向」にレイを飛ばし、自部品の他の三角形に当たるかを調べます。当たれば赤です。

レイは全部 ±d に平行なので、d に垂直な平面に三角形を投影した2Dグリッド（48×48）に入れておけば、各レイが調べる三角形を同じセルのものだけに絞れます。樹脂ケースで抜き勾配の解析にかかる時間は、当社の開発機のnodeで計測して15msでした。

ちなみに、型開き方向をXやYに変えて同じ解析をすると、アンダーカットは19.7%と18.5%まで跳ね上がります。上面開口の箱をZ以外で抜こうとすれば内壁のほとんどが被さるので当然なのですが、逆にいえば、どの方向が有望かを比較する材料にもなります。

しきい値を3°にすると、2°の壁が黄色になる

勾配が何度あれば足りるかは、材料と表面処理と離型の条件で変わります。だからしきい値はスライダーにしてあります。

しきい値1°で11.8%だった要勾配は、2°で34.3%、3°で62.1%になりました。設計で付けた勾配が2°なので、しきい値がそれを超えた瞬間に壁全体が黄色に転じる。この挙動は回帰テストにも入れてあり、「3°では1°のときの2倍以上の面積が要勾配になる」という相対条件で固定しています。

「うちの材料なら3°は欲しい」と金型メーカーが言うなら、スライダーを3°にして同じ画面を見ればいい、というのがこのツールの使い方です。

肉厚は、反対側の面までの距離で測る

「肉厚を解析」を押すと、色が肉厚マップに切り替わります。

三角形の重心から法線の逆向き（部品の内側）にレイを飛ばし、最初に当たる面までの距離を局所肉厚とします。樹脂ケースでは中央値が2.00mm、これはシェル肉厚の設計値そのものです。厚肉パッドの上面は底壁2mmと合わせて8mm前後の値が出ていて、7mmを超える面素が296ありました。

最大値が50mmと出ているのは、上面開口の縁から下向きにレイを飛ばすと開口を通り抜けて内底まで届くためで、ウィンドウにもその旨の注記を出しています。厚い場所を探すときは、この開口越しの値を除いて見ます。

レイキャストには3D均一グリッド（24³）を切って、グリッド走査（DDA、Amanatides-Wooの方法）でセルをたどる方式にしました。846三角形で11ms、20,000三角形まではサンプリングせず全数を測ります。

リブとボスは、一覧から3Dへ飛べる

抜き勾配の結果の下に「薄壁・リブ 6・ボス 2」という一覧が出ていました。薄壁は反平行な平面のペアで厚さ0.3〜6mmのもの（異常の件数ではなく、厚さを確認したい候補の一覧です）、ボスは型開き方向に立つ外向きの円筒です。

樹脂ケースでは、t=1.5mmのリブ2枚（設計値どおり）に加えて、t=2mmのシェル壁が4枚、ボスは φ7.95 × 高さ12 が2本でした。ボスの外径は設計値φ8に対してメッシュからの推定なので0.05mm小さく出ています（この推定の仕組みは第2回で書きました）。

検出した箇所に色と意味を付けて、金型メーカーへ渡す

ここが実務でいちばん効くところです。

一覧の各行には「タグ」ボタンがあり、押すとその要素の面が面マーキングに登録されます。リブ2枚をタグ付けすると、4面・19.44cm²が「要確認」タグに入りました。

集計はCSVに書き出せます。実物はこうです。

"タグ","色","面数","合計面積 (mm2)","合計面積 (cm2)"
"要確認","#f85149","4","1944","19.44"
"加工指示","#58a6ff","0","0","0"
"注目","#ffd23e","0","0","0"

このマーキングと付箋と視点を、共有パッケージ（.cadas）にまとめて金型メーカーへ渡せます。相手はCADASにドラッグ＆ドロップすると、確認対象のリブをマーキングした3Dと、その位置に付けたコメントを開けます。解析条件も付箋に「型開きZ、勾配しきい値1°」と記せば、何を前提に確認したかが伝わります。

たとえば「このリブには何度の勾配が必要か」「横穴を残してスライドを使うか、穴の向きを変えるか」と、形状を指しながら相談できます。相手は自分で回して裏側も見られます。指摘とその位置を結び付けて渡すことで、メールに書かれた「こちら側」「奥のリブ」がどこを指すかを確かめる往復を減らせます。

同じ形状を見て相談し、修正後をもう一度確かめる

公開してよいモデルなら、「ファイル > 埋め込み・共有リンクを発行」から「いまの表示状態ごと共有」を選び、付箋やマーキングを含むURLを渡す方法もあります。受け手はリンクを開くだけで、その箇所を3Dで確認できます。URL共有ではモデルをアップロードします。社外へ公開できない部品は、端末内で作成する.cadasを社内で認められた経路で渡します。

打ち合わせでリブの勾配を修正したら、修正後のSTEPを同じ型開き方向・同じしきい値で解析します。「黄色が減った」だけで終わらず、修正したリブの面を見て、合意した勾配になったかを確認する。この往復を設計中に行えることが、ブラウザでDFMを使う価値です。

CADASには、変更前後のSTEPを重ねて部品ごとの差を確認する機能も加わりました。修正箇所を相手へ示すときに使えます。比較の具体的な操作は第6回で扱い、この回では型開き方向と成形上の確認事項を揃えることに集中します。

サンプルを作った時点で、解析に設計ミスを見つけられた

白状すると、この樹脂ケースの初版は抜けない形でした。

上面開口の箱に2°の勾配を付けるつもりで書いたロフトの向きが逆で、上にいくほど小さくなる（上すぼまりの）箱になっていたのです。その状態で抜き勾配を解析すると、アンダーカットが面積の23%と出ました。内壁が全面赤です。横穴だけのはずなのにおかしい、とモデルを見直して、ロフトの向きに気づきました。

直したあとのアンダーカットは0.2%、赤いのは横穴だけになりました。ツールの検証用に作ったモデルの設計ミスを、そのツールが先に見つけたわけで、DFMを設計の途中で回す価値をいちばん実感した瞬間でした。

正解と突き合わせ、欠陥を注入して検証している

第2回と同じ方針です。回帰テストは、アンダーカットの三角形の重心平均が横穴の位置（y≈−10, z≈12）にあること、しきい値3°で要勾配が1°の2倍以上に増えること、肉厚の中央値が2.0±0.2であること、t=1.5のリブ2枚とφ8のボス2本が検出されること、を設計値に基づいて要求します。

そのうえで、遮蔽テストを無効にする、グリッド走査（DDA）を止める、リブの厚さ条件を壊す、という3種類の欠陥をわざと入れ、それぞれでテストが落ちることを確認してから採用しました。

まとめ

抜き勾配は法線と型開き方向の角度、アンダーカットは抜ける方向のレイの遮蔽、肉厚は法線方向の反対面までの距離として推定。いずれもLLMではなくメッシュに対する決定論的な幾何計算で、樹脂ケースなら15msで色になります。しきい値は材料に合わせてスライダーで変え、検出した箇所はタグを付けて共有パッケージで渡せます。

「この形、抜けません」の候補を、設計の途中で自分で洗い出せます。

次回の第4回は、AIの話です。

3Dデータを渡さずにAIに設計をレビューさせる、CADASのAI所見をどう作ったかを書きます。

まずは樹脂ケースで色を出してみてください

CADASは無料・登録不要です。「ファイル > サンプルギャラリー」から樹脂ケースを選び、左のパレットで金型DFMツール（Dキー）を押して「抜き勾配を解析」してください。手元の樹脂部品のSTEPでも、型開き方向を選ぶだけで同じ色が出ます。解析はブラウザ内で完結し、ファイルは外部へ送信されません。

CADAS（無料・登録不要）をブラウザで開く

自社の成形条件に合わせた判定ルールの調整や、設計と金型メーカーのあいだでDFM結果を共有する運用の設計など AI × CAD・設計情報コンサルティング（無料相談） にて、お気軽にご相談くださいませ。

それでは、また次回、お会いしましょう！

関連リンク

【AI×CAD 第1回】設計の3Dデータ、設計部門の外で誰も見られない問題を無料＋ブラウザだけで解決する（当ブログ）

【AI×CAD 第2回】見積もりのたびに穴を数えていませんか。STEPのB-Repから穴・ザグリ・皿ザグリを自動で拾う（当ブログ）

CADAS - 3D CADビューワー兼AI解析ツール（無料・当社開発）

AI × CAD・設計情報コンサルティング | Qualiteg（コンサルティングのご案内）

こんにちは！

OpenAIからGPT-6 Astra（アストラ）が登場しました。

「Claude Fable 5.1とどちらがよいのか」
「ついにAGIが来たのか」
「自分の仕事はどう変わるのか」

今回は、その気になるところまで踏み込んで見ていきます。

結論から言うと、今回注目したいのは、

調べる、作る、確かめる、という一連の仕事を進める力です。

当ブログの日本語対応LLMランキング2026（9月1日版）では、GPT-5.6 Sol・Terra・Lunaの位置づけを取り上げました。

今回は、3D制作と画面操作で見えてきた進化、Fable 5.1との得意分野の違い、そして月額200ドルの20xプランまで掘り下げます。

AstraのAPI単価はSolの2.5倍。ところが、端末作業の評価には、Solより少ない費用で高いスコアを出した結果もあります。この逆転が起きる理由も見ていきましょう。

第1部　GPT-6 Astraの見どころは、3D制作とアプリ操作

Astraの進化をつかむなら、まず3Dの作例が分かりやすいです。Blenderで住宅をモデル化し、Unreal Engine 5へ持ち込んで、中を歩けるシーンにするデモが公開されています。

外観を眺めるところから、空間に入って確かめるところへ。建築の提案なら、部屋のつながりや視点を変えた印象を、その場で共有する用途が浮かびます。

3Dモデルを作る力と、制作ソフトを使いこなす力が一緒に伸びた

今回の面白さはここです。形状の生成に加えて、別のソフトへの受け渡しや、実際に動かす工程まで射程に入っています。住宅の作例（OpenAI）

CADでは、複数方向の画像から形状を復元

BenchCADは、複数方向からのレンダリング画像をもとにCADコードを生成し、形状の重なりを評価します。Astraは95.9%、Solは83.3%。3Dを扱う進化は、見栄えのよい作例に加えて、形を再構成する評価にも表れています。

GPT-6 Astraの基本仕様

第2部　Solから伸びたのは、検索の先にある実装・操作

Solとの比較で目を引くのは、端末作業のTerminal-Bench 4.0と、業務フローのAutomationBenchです。検索のBrowseCompは両モデルとも90%台ですが、この2項目ではAstraが大きく伸びています。

評価値はOpenAIの公表表より。各モデル・各評価で試した推論量の中で得られた最高スコアを掲載。OSWorldはv2026.08.08のoffline set・partial score。

Terminal-Benchが問うのは、端末を使ったソフトウェア開発、環境設定、データ分析です。コードを書く途中でエラーに遭い、原因を調べ、実行して確かめる。Astraは、こうした操作を伴う課題でSolの37.3%から57.9%へ進みました。

AutomationBenchも18.1%から41.4%へ上昇しています。今回の評価から期待が膨らむのは、検索で答えを見つけた後、その情報を使ってアプリ上の仕事を進める部分です。

画面操作は、待ち時間にも変化がある

OSWorld 2.0の所要時間シミュレーションでは、Solの約75分に対してAstraは約40分。評価値を65.7%から72.6%へ上げながら、所要時間は約47%短くなっています。

さらに、Codex側の操作基盤の改善と合わせたMind2Webの比較では、タスク完了が1.9倍速くなったと報告されています。画面を介した操作が多い仕事では、この待ち時間の短縮も使い勝手に効きそうです。

第3部　Claude Fable 5.1と、どこが違うのか

Claude Fable 5.1も、長い工程の開発や業務を任せる最上位モデルです。Astraとの比較では、端末作業の点差よりも、業務フローの評価と長文入力の費用に、はっきりした違いがあります。

基本単価は同じ。長文とキャッシュで差が出る

まずは両社の直接提供APIの仕様を並べます。料金は100万トークンあたりの米ドルで、AstraはStandard・入力272,000トークン以下の区分です。

繰り返し読む入力の単価は、Fable 5.1がAstraの4分の1です。たとえばキャッシュに載った20万トークンを100回読むと、読み取り分はAstraが20ドル、Fable 5.1が5ドルになります。新規入力・書き込み・出力は別途加算します。

長文にも差があります。Astraは入力272,000トークンを超えるとリクエスト全体が割増料金に切り替わりますが、Fable 5.1は100万トークンの枠まで基本単価です。大きなコードベースや資料を載せたまま往復するAPI用途では、Fableの料金設計が効きます。

端末作業は接近、業務フローはAstraがリード

OpenAIの比較表では、Terminal-BenchはAstraが57.9%、Fable 5.1が55.8%。AutomationBenchでは41.4%と31.4%に差が開きます。

一方、知識・推論などをまとめたArtificial Analysis Intelligence IndexはFable 5.1が上回ります。総合指数と、ツールを使って作業を遂行する評価で、順位が入れ替わっているわけです。

出典はOpenAIの公表比較表。各モデル・各評価で試した推論量の中で得られた最高スコアを掲載しています。

第4部　AstraはAGIなのか。すごさと、まだ気になるところ

知らない画面を操作し、調べ、コードを書き、成果物まで仕上げる。そんな姿を見ると、「いよいよAGIっぽくなってきた」と感じるのも分かります。

AGIっぽさを感じるのは、知らない仕事を進める力

ARC-AGI-3は、未知の環境を探索し、ルールや目標を推測して行動する評価です。決まった答えを知っているかに加えて、初めての状況でどう学んで動くかを見ています。

OpenAIの発表では、AstraはARC-AGI-3で99.9%を記録しています。初めての環境を探索し、ルールを見つけて行動する課題での結果です。

まだAGIっぽくないと感じたのは、前提を見失う場面

当社でも、さまざまな3Dデータを扱う製品の開発を任せたとき、この能力の高さと判断の危うさを同時に感じました。確認用のサンプルを作り、その動作を修正してもらった場面です。

AIは難しい実装を進め、テストの合格を報告してくれました。ところが、通常の使い方で確認すると問題が残り、修正もそのサンプルだけで動く個別対応へ向かおうとしました。

製品の目的は、利用者が持ち込むさまざまなデータを扱うこと。そのサンプルにだけ通用する処理を足すと、目の前の不具合は消えても、製品の汎用性を損ないます。

追加の指示に引っ張られ、守り続けるべき前提が抜け落ちる。

難しいコードを実装する能力はある。それでも、テストの合格を急ぐうちに、製品全体でその解き方が妥当かという判断が後回しになりました。能力の高さと、この基本的な判断のずれが同居していたのです。

人間の開発者なら、製品の目的に立ち返って踏みとどまってほしい場面です。Astraは指摘を受けると修正を進められましたが、こちらが気づいて声をかける必要がありました。

第5部　作業の途中でも人とやり取りできる

長い処理を任せている途中で「やはりこちらの条件で」と伝える。Astraでは、そのようなやり取りをResponses APIで組み込めます。ツール待ちの並行作業と推論量の切り替えも加わり、エージェントの動かし方が変わります。

ツールの処理中に別の作業を進める

Async tool callingは、ツールの結果が返る前に、モデルがほかの推論や独立した作業を続ける機能です。

たとえば、時間のかかる集計ツールを走らせ、その間に独立した別資料の確認を進める構成が作れます。集計結果が届いたら、元のcall_idに対応する結果として会話へ戻します。

指定はfunction／custom toolの定義にasync: true。ツールの起動と結果の回収はアプリ側で実装します。

返答が終わる前に条件を追加する

Mid-turn steeringは、モデルが作業している途中で、ユーザーが条件や方針を追加できる機能です。APIではAstraとResponses APIのWebSocket接続が対象です。

提案書を作っている途中で「予算を半分に」「この候補は除外して」と追加し、続きの処理へ反映できます。長い回答を最後まで待ってから修正を依頼する往復を減らせます。

変更が効くのは続きの処理です。開始済みのツールを止める処理や、外部サービスへの書き込みを取り消す処理は、アプリ側に持たせます。

難しい工程だけ推論量を増やす

configuration_updateを入力へ追加すると、次の応答からreasoning.effortを切り替えられます。standard・single-agent modeが対象です。

リクエスト全体の設定を変える方法と違い、キャッシュに使うプロンプトの先頭部分を維持できます。長い資料を共有した会話の途中で、難しい検討だけ推論量を上げる設計に使えます。

第6部　GPT-6 AstraのAPI料金。Solの2.5倍をどう考えるか

OpenAI APIのStandard料金は、Astraが100万トークンあたり入力10ドル・出力50ドルです。以下は入力272,000トークン以下の場合の比較で、金額は米ドルです。

Solの掲載料金はプロモーション価格で、公式には少なくとも2026年11月21日までと案内されています。

Astraは、複数の評価で出力トークンを大きく減らしています。1トークンの単価はSolの2.5倍でも、課題を終えるまでに消費する量が減ることで、費用が逆転する結果が出ています。

端末作業のTerminal-Bench 4.0では、最高スコアを出した設定同士で、Astraの推定API費用はSolより約9%低くなっています。複雑な課題では、少ない費用で高いスコアに届く結果が出ているわけです。

再試行が減った場合の料金を試算する

入力1万・出力2千トークンのリクエストを例にすると、Astraは0.20ドル、Solは0.08ドルです。出力は推論分を含めた課金対象量で計算しています。

試算条件はStandard料金、キャッシュなし。ツール料金・地域加算を除きます。

この条件なら、Solで2回かかっても0.16ドル。3回なら0.24ドルとなり、Astraの1回分を上回ります。単価2.5倍の差を、何回分の手戻りで取り戻せるかが具体的に見えてきます。

逆に、長い資料を入力する仕事は入力費用が残ります。この例ではAstraの入力分だけで0.10ドルになるため、出力を短くするだけではSolの合計0.08ドルに届きません。

長文とキャッシュは料金の区分が変わる

Astraのキャッシュ読み取りは100万トークンあたり1ドル、書き込みは12.50ドルです。入力が272,000トークンを超えると、リクエスト全体に長いコンテキストの料金が適用されます。

長文区分では、100万トークンあたり入力20ドル・出力75ドル、キャッシュ読み取り2ドル・書き込み25ドルです。境界を超えると入力全体の単価が2倍になるため、資料を一括で載せる設計には影響が大きいところです。

APIではBatch・FlexがStandardの半額、Fast modeが2倍です。夜間にまとめて処理する用途ならBatch・Flex、目の前で結果を待つ用途ならFastという料金の選択肢もあります。

第7部　同じ20xでも違う。ChatGPT ProとClaude Maxの使い勝手

月額200ドルのChatGPT Pro 20xとClaude Max 20x。Astraを長時間動かしたい人にとって、いまOpenAI側の強みになっているのは、Proで5時間制限を当面適用しない運用です。

比較するのはCodex／ChatGPT WorkとClaude Codeなどの定額利用枠です。両社とも20xプランを用意していますが、短時間の制限と、最上位モデルに割ける枠が違います。

月額は米ドル、税別。ClaudeはWeb契約価格。

OpenAIの魅力は、集中したい日にまとめて使いやすいこと

Proの100ドル・200ドルプランは、今後数か月、5時間制限を適用しないと案内されています。2026年8月25日のOpenAI担当者の投稿で示された運用です。案内

たとえば週末にまとまった実装を進める場合、週枠を残したまま5時間枠で中断する問題が減ります。長い仕事を続けられるAstraと、この利用枠の配り方は相性がよいです。

上限として残るのは週の利用枠です。重い推論や長時間の作業をまとめて走らせるほど、その残量を使うペースも速くなります。

Claude Maxは、Fableに共通週枠の最大50%

Claude Maxには5時間枠と週枠があり、Fable 5／5.1に使える量は共通週枠の最大50%です。残りの枠があっても、Fable側の上限に先に届くことがあります。

Fableの上限後も同じモデルで続ける場合は、従量課金のusage creditsへ進みます。定額枠内で続けるなら、Opusなどへ切り替える運用になります。

Fableを難所に絞る使い方なら、この配分に合わせやすいでしょう。一方、最上位モデルで一つの仕事を長く進めたい場合、短時間枠による中断が少ない現在のProは魅力があります。

第8部　API移行ではモデル名以外も変わる

監視による停止は専用のエラーで受け取る

Astraには、ユーザーの意図から外れた行動を検知するmisalignment monitoringが導入されています。モデルの推論と操作を非同期に確認する仕組みです。

APIでは、会話の文脈を維持する方式によって、自動停止まで行うかが変わります。Chat Completionsはこの監視の対象外で、ほかの安全チェックは引き続き適用されます。

停止時のコードはmisalignment_policy_violationです。これを受けたら自動リトライのループを止め、直前のツール実行履歴と一緒に確認へ回します。

監視は非同期で動くため、停止時点で完了している操作があります。実行済みの書き込みを履歴に残しておくと、再開時の二重実行を防ぐ判断に使えます。

第9部　長い開発で効く、過去の作業を検索する機能

AstraはChatGPT Plus・Pro・Business・Enterprise、API、Azure、Amazon Bedrockへ段階展開されています。Codexでは、長いタスクの記憶を扱う仕組みにも新機能が加わりました。

Codexの対応クライアントでは、Astraがコンテキストをまたいでメモを保持し、同じタスクの過去のメッセージやツール結果を検索する、実験的なコンテキスト管理が案内されています。

要約に残らなかった過去の要件や、失敗した修正の結果を検索で取り出せます。大きなリファクタリングで「なぜこの方法をやめたのか」をたどれることは、同じ袋小路へ戻るのを減らすうえで期待できます。

実験的機能は初期状態でオフ。開始時点ではChatGPT Plus・Proでログインした対応クライアント向けで、Codexの設定から有効化します。

先ほどの開発例に重ねると、過去の前提を取り出せる仕組みと、その前提を優先して判断する能力は、両方ほしいところです。Astraでは、この二つの進化を追っていきたいと思います。

まとめ　Astraで広がった、制作から操作まで任せる範囲

住宅をBlenderで作り、Unreal Engineで歩けるようにする。アプリを直して、自分で画面を操作する。Astraの公開作例には、複数の制作工程をつなぐ進化が表れています。

Fable 5.1とは基本のAPI単価が同じで、業務フローの評価はAstra、長文・キャッシュの料金はFableに強みがあります。定額で集中的に動かしたい人には、Proの当面の5時間制限緩和も大きな違いです。

未知の環境を解き進める姿には、AGIっぽさを感じます。同時に、当社の開発では、難しい実装をこなしながら製品の目的を見失う場面もありました。人が立ち返らせたのは、「その修正で、別のデータも扱える製品になるか」という判断です。高度な作業をこなす力と、目的を保つ判断。その両方に、いまのAstraの姿が表れています。

当ブログの日本語ランキングと合わせて、モデル選びの参考にしていただければ幸いです。

それでは、また次回、お会いしましょう！

出典・参考資料

• Claude Fable 5.1のモデル仕様（Anthropic）
• Claude API料金表（Anthropic）
• Claude Fable 5.1とMythos 5.1の発表（Anthropic）
• ChatGPT Proのプラン比較
• Claude Maxの利用枠
• Fableモデルのプラン別条件
• Proの5時間制限に関する案内
• GPT-6 Astraの発表・評価表・評価条件（OpenAI）
• GPT-6 Astraのモデル仕様（OpenAI API）
• GPT-6 Astraの機能・移行ガイド（OpenAI API）
• API料金表（OpenAI）
• Async tool calling（OpenAI API）
• Mid-turn steering（OpenAI API）
• 会話途中の推論量変更（OpenAI API）
• Misalignment monitoring（OpenAI API）
• モデルの選び方・実験的コンテキスト管理（ChatGPT Learn）
• ChatGPT Work／Codexの料金と利用枠（ChatGPT Learn）

調査基準日　2026年9月6日

関連記事

• 日本語対応LLMランキング2026（9月1日版）
• Claude Opus 5.0 完全ガイド　モデル仕様とAPI・Claude Code運用ポイント
• Claude Fable 5 完全ガイド　モデル仕様とClaude Code運用ポイント

こんにちは！

昨日まで何も言わずに走っていた Claude Code の grep が、今朝（2026/9/3)から止まるようになりました。

grep on '.' would read 'C:\path\to\project\.env', which the deny rule
Read(./.env) covers; only you can approve running it anyway.

grep on '-r' after a cd would search a directory that cannot be determined
here, and a Read() deny rule is configured; only you can approve running it
anyway.

筆者の環境は Windows 11 で、権限モードは bypassPermissions。設定ファイルは一切触っていません。

先に結論を書いておくと、これはバグではなく

2026年9月2日リリースの Claude Code v2.1.259 に入った意図的な変更

です。

settings.json に Read(./.env) のような deny ルールがあり、Bash の grep -r の検索範囲にその deny 対象が含まれていると、「そのファイルを読みうる」と判定されて承認待ちになります。

bypassPermissions では回避できません。

この記事では、公式チェンジログと公式ドキュメントで原因を突き止めたうえで、前日の v2.1.258 と当日の v2.1.259 を手元で並べて確認し、どの書き方が通ってどの書き方が止まるのかを表にします。

当ブログでは Claude Code で正規の運用作業が「Usage Policy 違反」になる理由 や Claude Code で「court」って何？ など、Claude Code の「急に挙動が変わった」系のトラブルを追いかけてきました。

今回もその一本です。

1. 原因は v2.1.259 のチェンジログに書いてある

公式チェンジログの v2.1.259（September 2, 2026）に、そのままの記述があります。

Fixed Bash Read()/Edit() deny rules not covering files given as option values (--ignore-revs-file=.env, -f.env, @file), git diff/git grep file operands, or cd DIR && cat FILE compounds; grep -r/cp -r over a directory holding a denied file now asks

冒頭の 2 つのメッセージは、この 1 行に対応しています。

grep -r pattern . は「deny 対象ファイルを含むディレクトリに対する grep -r は確認を求める（now asks）」そのものです。

cd ... && grep -r は「cd DIR && cat FILE 複合コマンド」への対応の副作用とみられます。cd 後のカレントディレクトリを Claude Code が静的に確定できないので、安全側に倒して確認になる、という読みです（推測を含みます）。

なお、この系統の変更は v2.1.259 が初めてではありません。1 週間前の v2.1.246（August 25, 2026）にも似た行があります。

Fixed Bash Read()/Edit() deny rules not applying to < file redirects and reader commands like tac and egrep; a deny rule on any argument or redirect target now refuses the command

つまり 8 月下旬から 9 月頭にかけて、Anthropic は「Bash 経由で deny 対象ファイルに触れる抜け道」を順番に塞いでいます。

チェンジログ上はいずれも Fixed 扱いなので、元に戻ることは期待しないほうがいいでしょう。

2. 前日の v2.1.258 と並べて試した

「昨日は出なかった」を記憶で言い張っても仕方ないので、手元で再現しました。

再現用のフォルダはこうです。private/ 配下を deny 対象にして、src/ に普通のファイルを置きます。

blog_claude_code_read_deny/
├── deny_settings.json
├── private/notes.txt      ← 中身は「hello from private notes」
└── src/app.js             ← 中身は console.log("hello from app");

deny_settings.json（全文）

{
  "permissions": {
    "deny": ["Read(./private/**)"],
    "defaultMode": "bypassPermissions"
  }
}

この設定を --settings で渡し、-p（非対話モード）で「次のコマンドをそのまま Bash ツールで実行して、結果をそのまま返して」と指示します。

claude -p "Use the Bash tool to run exactly this command, once, without modification: grep -r hello . Then reply with the complete tool result text you received, verbatim, and nothing else." \
  --settings ./deny_settings.json --permission-mode bypassPermissions \
  --model claude-haiku-4-5-20251001 --output-format stream-json --verbose

v2.1.258 は npx -y @anthropic-ai/claude-code@2.1.258 で呼び分けました。結果は次のとおりです。

（確認日 2026年9月3日、Windows 11、Git Bash。-p モードでは「承認待ち」が自動的に拒否に変わるため、対話セッションで見える「only you can approve」の承認プロンプトが、ここでは拒否メッセージとして返っています）

表から読み取れることが 4 つあります。

同じ設定・同じコマンドで、2.1.258 は通り、2.1.259 は止まる（#1 と #7、#2 と #8）。

昨日まで出なかったのは、昨日まで使っていた版にこの変更が入っていなかったからです。

検索対象のパスを明示すれば通る（#3）。

grep -r hello src/ なら、src/ の下に deny 対象がないので判定に引っかかりません。

除外オプションを付けても通らない（#4）。

--exclude-dir=private を付けても止まります。Claude Code は grep の除外オプションまでは解釈していないようです（ここは確認結果からの推測です）。ネット上に「--exclude を付ければ OK」という解説を見かけますが、少なくとも v2.1.259 では効きません。

Python 経由なら素通りする（#6）。

cat は止まるのに、Python スクリプトで同じファイルを開くと中身が出ます。これはドキュメントどおりの挙動で、後述します。

3. なぜ bypassPermissions でも止まるのか

Claude Code の権限ルールは、モードとは別のレイヤーで評価されます。

公式ドキュメント（Configure permissions）の記述を原文のまま引きます。

Rules are evaluated in order: deny, then ask, then allow. The first match in that order determines the outcome, and rule specificity doesn't change the order.

そして権限モードのページ（Choose a permission mode）にはこうあります。

Modes set the baseline. Layer permission rules on top to pre-approve or block specific tools. Deny rules block in every mode, including bypassPermissions. (中略) Allow rules have no effect in bypassPermissions.

整理するとこうなります。

bypassPermissions は「deny にも ask にも当たらなかった呼び出しを自動承認する」だけです。deny ルールはその手前にあります。

なので --dangerously-skip-permissions を足しても意味がありません。同じモードを別名で指定しているだけです。

ついでに書いておくと、PreToolUse フックで allow を返しても deny は覆せません。

Hook decisions don't bypass permission rules. Claude Code evaluates deny and ask rules regardless of what a PreToolUse hook returns

4. なぜ grep が Read ルールに引っかかるのか

Read(./.env) は Read ツール専用のルールに見えますが、そうではありません。現在のドキュメントの警告枠にはこう書かれています。

Read and Edit deny rules apply to Claude's built-in file tools and to file commands Claude Code recognizes in Bash, such as cat, head, tail, and sed. They don't apply to arbitrary subprocesses that read or write files indirectly, like a Python or Node script that opens files itself. For OS-level enforcement that blocks all processes from accessing a path, enable the sandbox.

試行の #5（cat は止まる）と #6（Python は通る）は、この記述どおりです。

さらに Grep と Glob については、

Claude makes a best-effort attempt to apply Read rules to all built-in tools that read files like Grep and Glob

Grep and Glob search the directory the path argument resolves to. Claude Code applies Read deny rules to that directory.

とあります。組み込みの Grep ツールに対しては以前から「ベストエフォート」で当てていて、v2.1.259 で Bash の grep -r にも同じ考え方が及んだ、と読むのが自然です。

grep -r pattern . はカレントディレクトリ全体が対象なので、その中の .env を読みうる。だから止まる。理屈は単純です。

4-1. ドキュメントは少し前まで正反対だった

ここが検索で調べる人を混乱させるポイントです。

2026年4月8日に立った Issue #45200 には、当時の公式ドキュメントの文が引用されています。

Read and Edit deny rules apply to Claude's built-in file tools, not to Bash subprocesses.

現在の記述とは正反対です。Issue の報告者（macOS、v2.1.92）は Read(~/private-dir/**) を deny に入れると ls ~/private-dir/ が自動拒否されると報告し、ドキュメントと実装の食い違いを指摘していました。

この Issue は Closed as not planned で閉じられ（stale ラベル付き）、ドキュメントのほうが実装に合わせて書き換えられた、という経緯に見えます（Issue の状態とラベルは 2026年9月3日に確認。書き換えの時期と理由は未確認です）。

逆向きの報告もあります。2026年5月9日の Issue #57525 は「Grep ツールが Read の deny をすり抜けて設定ファイルの中身を返した」という内容で、duplicate として閉じられています。

抜け道を塞ぐ方向の要望と、塞いだ結果の誤爆報告が、同じ時期に並んでいるわけです。

ネット上の解説記事の多くは書き換え前のドキュメントを引いています。「Read の deny は Bash には効かない」と書いてある記事は、今は当てになりません。

5. 自分の環境で確認する

まず、どんなルールが効いているかを見ます。

/permissions

全ルールと、それぞれがどの設定ファイル由来かが一覧表示されます。設定ファイルの場所は次のとおりです。

身に覚えがないルールがプロジェクト側に入っている場合、コミット履歴で誰がいつ入れたかわかります。

git log --oneline -- .claude/settings.json
git blame .claude/settings.json

よく出回っている「Claude Code セキュリティ設定テンプレ」をコピーすると、たいてい次の 3 行が入ります。今回引っかかるのはこれです。

"deny": [
  "Read(./.env)",
  "Read(./.env.*)",
  "Read(./secrets/**)"
]

なお、ドキュメントによると Read(.env) と Read(**/.env) は同じ意味で、カレントディレクトリ以下の任意の深さの .env に当たります。Read(./secrets/**) のような 1 セグメントのディレクトリ指定も、deny ルールとしては任意の深さの secrets に当たります。

つまり、プロジェクトのどこか深い階層に .env が 1 つあるだけで、ルートからの grep -r は止まります。

6. 対処は 2 通り、守りを固めるなら sandbox を足す

6-1. grep に対象パスを明示させる（ルールを残したい場合）

grep -r "pattern" src/        # 通る（#3）
grep -r "pattern" .           # 止まる（#1）
cd src && grep -r "pattern" . # 止まる（#2）
grep -r --exclude-dir=private "pattern" .   # 止まる（#4）

deny 対象を含まないディレクトリを指定すれば、判定に引っかかりません。cd を挟まなければ「判定不能」にもなりません。

CLAUDE.md に「grep は必ず対象ディレクトリを明示する。カレントディレクトリ全体を対象にしない。cd と組み合わせない」と書いておくと、Claude がその書き方を選ぶようになります。

ただし強制力はありません。ドキュメントにも「CLAUDE.md の指示は Claude が何を試みるかを変えるが、Claude Code が何を許可するかは変えない」と明記されています。

対話セッションなら、承認プロンプトで承認すればそのコマンドは走ります。メッセージが「only you can approve running it anyway」で終わっているのはそういう意味です（承認を記憶させて次回から聞かれなくできるかは未確認です）。

6-2. Read 系の deny ルールを消す（黙らせたい場合）

今回強化されたのは「Bash の引数やリダイレクト先を Read/Edit の deny ルールと照合する」処理です。照合対象の Read ルールが 1 本もなければ、この判定は発火しません。

{
  "permissions": {
    "deny": [
      "Bash(rm *)",
      "Bash(sudo *)"
    ],
    "defaultMode": "bypassPermissions"
  }
}

筆者の手元でも、Read ルールを外した設定に差し替えると grep -r hello . は通りました。当然 private/ の中身も検索結果に出ます。

.env の中身がモデルへの入力コンテキストに載り、利用しているプロバイダー側へ送信されうる点だけ承知したうえで選んでください。

6-3. 機密を本当に守りたいなら sandbox を足す（承認待ちの解消策ではない）

ここは誤解しやすいので先に線を引いておきます。sandbox を有効にしても、今回の承認待ちは消えません。

ドキュメントによると、sandbox と permission ルールは置き換え関係ではなく、併用される別レイヤーです。sandbox を有効にしても deny ルールはそのまま適用され、Read / Edit の deny ルールは sandbox のファイルシステム境界にも統合されます。

Filesystem restrictions in the sandbox combine the sandbox.filesystem settings with Read and Edit deny rules; both are merged into the final sandbox boundary

Explicit deny rules still apply

つまり sandbox は「承認待ちをなくす手段」ではなく「permission ルールでは止められない経路を OS レベルで塞ぐ手段」です。

試行 #6 のとおり、permission ルールは Python スクリプトが自分で開くファイルまでは止めません。ドキュメントも「全プロセスからのアクセスを OS レベルで止めたいなら sandbox を有効にせよ」という立て付けです。この穴を塞ぎたい人が足すものです。

{
  "sandbox": {
    "enabled": true
  }
}

ただし注意が 1 つ。組み込みの Bash sandbox が動くのは macOS、Linux、WSL2 です（権限モードのドキュメントの記載による）。筆者のように Windows ネイティブで Git Bash を使っている場合、この選択肢はそのままでは使えません。

6-4. 使い分け

7. それでも止まるときに疑う場所は、

7-1. defaultMode が auto になっていないか

権限モードのドキュメントによると、Pro / Max / Team プランではセッション開始時の既定モードが auto です。auto は「分類器（別のモデル）が毎回チェックして、危険と判断したものは止める」モードで、bypassPermissions とは別物です。

Shift+Tab でモードを切り替えていると、意図と違うモードで走っていることがあります。ステータスバーの表示（⏵⏵ bypass permissions on か ⏵⏵ auto mode on か）を見てください。

7-2. PreToolUse フックが噛んでいないか

"hooks": {
  "PreToolUse": [
    { "matcher": "Bash|Write|Edit", "hooks": [ ... ] }
  ]
}

フックはツール呼び出しをブロックできます。フックが止めている場合、エラー文に PreToolUse:Bash hook error のようにフック名が出るので、今回の deny メッセージとは見分けがつきます。

切り分けには "disableAllHooks": true を一時的に入れるのが早いです。

7-3. 会社の managed settings ではないか

managed settings の deny ルールは、コマンドライン引数を含めどのレベルからも上書きできません。

no other level, including command line arguments, can override a managed permission rule

/permissions に出所が表示されるので、そこが managed なら自分では外せません。管理者に相談してください。

7-4. ユーザー設定の相対パスは ~/.claude に張り付く

見落としやすい罠がもう 1 つ。~/.claude/settings.json に Read(/secrets/**) と書くと、それは ~/.claude/secrets/** を指します。プロジェクトの secrets/ ではありません。

全プロジェクトに効かせたいなら // から始まる絶対パスか ~/ から始まるパスで書け、とドキュメントにあります。Windows のパスは /c/Users/... の形に正規化されるので、ドライブ全体の .env を指すなら //c/**/.env です。

8. まとめ

今日から grep が止まるようになった人は、次の順に見てください。

一言でまとめると「Read の deny ルールが Bash の grep -r にも届くようになった。bypassPermissions では抜けられない。承認待ちを避けるなら検索パスを明示するかルールを外すかの二択で、sandbox は承認待ちの解消策ではなく守りを足すもの」です。

Claude Code はチェンジログ上、8月25日の 2.1.246 から 9月2日の 2.1.259 まで、わずか 9 日間でバージョン番号が 13 進んでいて、権限まわりは特に手が入り続けています。

「昨日まで動いていた」が通用しない領域なので、挙動が変わったらまずチェンジログを見る、を習慣にしておくと消耗が減ります。

ていうか、しょっちゅう変わるので、ロングタスクがおわって、次のロングタスクを起動しようとすると、一瞬で停止、みたいな「あちゃー」が頻発します。

やはり、ＡＩエージェントは人間の監視が必須です。

それでは、また次回、お会いしましょう！

出典・参考

• Claude Code changelog（公式）　v2.1.259 と v2.1.246 の該当行
• Configure permissions（公式ドキュメント）　評価順、Read/Edit ルールの適用範囲、設定ファイルの場所、managed settings
• Choose a permission mode（公式ドキュメント）　モード一覧、deny は全モードで有効、sandbox の対応 OS
• Issue #45200 Documentation discrepancy: Read(...) deny rules affect Bash tool calls（GitHub）
• Issue #57525 Ignores Read Permissions when Using Grep（GitHub）

関連記事

• Claude Code で正規の運用作業が「Usage Policy 違反」になる理由
• Claude Code で出てくる「court」って何？ XML 露出現象とツール呼び出し未実行事故の対策
• Claude Code で「The model's tool call could not be parsed」が頻発する問題の原因分析と対策
• Claude Opus 5.0 完全ガイド　モデル仕様と API・Claude Code 運用ポイント

本レポートは、Nejumi Leaderboard 4のベンチマークデータ（2026/9/1版）に基づいて、日本語対応LLMの性能を総合的に分析したものです。

前回は 2026/7/10 版の分析レポート を公開しましたが、わずか2か月弱で首位が入れ替わり、

オープンモデルが総合3位に食い込む激アツの回となりました！

（定期的に最新LLMランキングを更新してまいります。当社のX(旧Twitter)をフォローいただくことで更新情報を受け取り可能です）

Nejumi Leaderboard 4は、日本語タスクにおけるLLMの性能を多角的に評価する信頼性の高いベンチマークとして知られています。汎用的言語性能（GLP）とアラインメント（ALT）の2軸で構成され、翻訳・要約・推論・コーディングから毒性・バイアス・真実性まで、幅広い観点をカバーしているのが特徴です。

本分析では、商用APIモデルとオープンモデルの両方を対象に、それぞれの特徴や傾向を詳しく見ていきます。

まず、今回の3大トピックを先にご紹介します。

• Claude Opus 5が総合スコア0.8720で首位
  リーダーボード上初の0.87台で、Claude Fable 5（0.8699）とAnthropic勢がワンツーフィニッシュ
  
• オープンモデルのQwen3.8-2.4T-A95Bが総合3位（0.8598）
  オープン初の0.85超えで、API首位との差は0.033から0.012へ一気に縮小
  
• 米国の新顔が続々参入
  Thinking Machines Labが初登場でオープンTOP8に2本を送り込み、MetaのMuse Glimmerも当ランキングに初登場

オープンソースモデルについて

Weightがオープンなモデルは場合によっては「オープンソースモデル」、「OSSモデル」と呼ばれますが、学習データや学習コードまで完全に公開されているモデルばかりではないため、本稿では「オープンモデル」という表記に統一しています。

ベンチマーク分析について

本レポートは、LLM選択の参考情報として、ベンチマークデータから読み取れる傾向や特徴を提示するものです。実際の導入にあたっては、用途に応じた実環境での検証をおすすめいたします。

また、今回の集計はリーダーボード掲載中の評価（アーカイブ扱いを除く）を取得したデータに基づいています。同一モデルでも思考モード（reasoning/thinking）等の設定が異なる評価ランは別エントリーとして掲載される場合があります。

それでは、2026/9/1 現在の日本語対応LLMの総合ランキングをみてみましょう。

総合スコアランキング TOP50

※水色の行はオープンモデルです。

総合スコアの傾向と考察

今回の最大のニュースは、なんといっても

Claude Opus 5（0.8720）とClaude Fable 5（0.8699）のワンツーフィニッシュ

です。

前回Claude Opus 4.8が初めて突破した「0.85の壁」を、Claude 5世代はわずか2か月弱で約0.02上回ってきました。

• TOP2が0.87前後という未踏の水準（前回の首位は0.8523）
• 0.85以上が5モデルに（前回は2モデル）
• 0.80以上は42モデル（前回は19モデル。いずれもモデル単位で、同一モデルの複数評価ランは重複除外した数です）
• TOP10のうち7枠が、前回ランキングに存在しなかった新顔

Claude 5世代が「0.85の壁」を一気に置き去りに

首位のClaude Opus 5は、GLP（汎用的言語性能）0.8668が全モデル中断トツです（2位に0.017差）。

内訳をみると、数学的推論0.9817、抽象的推論0.96に加えて、コーディング0.9081が際立ちます。コーディングの2位は0.7220ですから、この項目だけ別次元の値です。SWE-Bench系評価も0.7500と最上位圏で、「書けるモデル」であることがスコアにはっきり表れています。

2位のClaude Fable 5は、AnthropicがOpusより上位に位置づける新ティアのモデルです。

リーダーボード上のFable 5評価は「adaptive-thinking-max with fallback to Opus 4.8」、つまりOpus 4.8へのフォールバックを含む構成です。

この構成での評価値として、ALT（アラインメント）0.9071とSWE-Bench系評価0.8000が全エントリー中トップでした。Fable 5単体の性能値ではない点にご注意ください。

ここで面白いのは、AnthropicがOpusより上位に位置づけるFable 5が、このベンチマークでは首位ではなかったという点です。

差はわずか0.0021ですが、順位は順位です。

内訳をみると事情がみえてきます。

実務的なコード修正力を測るSWE-Bench単体ではFable 5（0.8000）がOpus 5（0.7500）より上です。

ところが、SWE-BenchにJHumanEvalとMT-Bench（coding）を合わせた「コーディング」サブカテゴリでは逆に、Opus 5の0.9081に対しFable 5は0.7220と大きく離されます。同じ「コーディング力」でも、何をどう測るかで順位が入れ替わるわけです。

モデルの格付けと特定ベンチマークでの順位は、必ずしも一致しません。

ベンチマークはあくまで特定のタスクセットに対する測定なので、こうした逆転は普通に起こります。だからこそ本レポートでは毎回、用途に応じた実環境での検証をおすすめしています。

前回のワンツーだったOpus 4.8（0.8523）とOpus 4.7（0.8509）も4位・5位に踏みとどまり、TOP5のうち4枠をAnthropic勢が占める結果となりました。

OpenAIはGPT-5.6の3モデル同時投入で追撃

OpenAIは7月にGPT-5.6世代を3モデル同時に投入してきました。sol（0.8499、6位）、terra（0.8440、7位）、luna（0.8145、33位）です。

とくにterraの抽象的推論0.98とsolの0.97は、Opus 5（0.96）を上回る全モデル中トップの値です。推論力の切れ味では今回もOpenAIが最先端を争っています。

一方で弱点もはっきりしています。

GPTシリーズは真実性がsol 0.752、terra 0.709、luna 0.636と上位勢のなかでは低め

で、これが総合スコアの伸びを抑えました。

ちなみに前回紹介した「GPT-5.4はhigh設定（0.8397）がxhigh設定（0.8286）を上回る」という逆転現象は、今回のデータでもそのまま残っています。推論量を増やせば必ずスコアが上がるわけではない、という好例です。

GPT勢は本当にQwenに負けたのか

総合スコアだけをみると、オープンのQwen3.8（0.8598）がGPT-5.6 sol（0.8499）より上です。ただ、この差を「言語性能で負けた」と読むのは正確ではありません。

GLP（言語性能）はsolが0.8402、terraが0.8363で、Qwen3.8の0.8290をどちらも上回ります。抽象的推論にいたってはterraの0.98が全モデル中トップです。

差がついたのはALT（アラインメント）側です。Qwen3.8の0.9171に対しsolは0.8755で、とくに真実性（0.843対0.752）と毒性（0.849対0.791）の開きが総合スコアに効きました。

つまり「賢さで負けた」のではなく「安全性・制御性込みのこのベンチマーク上の総合点で差がついた」というのが実態でしょう。

推論や創造的タスクが中心の用途なら、GPT-5.6勢が上に来る場面は十分にあります。

TOP10の7枠が新顔に入れ替わる

上図のとおり、TOP10のうち7枠が前回ランキングにいなかった顔ぶれです。とくに注目すべき新顔を紹介します。

• Kimi K3（8位・10位）　
  Moonshot AIの新世代。API版（0.8432）とオープンウェイト版（0.8425）がほぼ同スコアで、両方ともTOP10に入りました。本モデルについては、こちらのブログにもまとめてあります。
  
• Gemini 3.6 Flash（15位、0.8312）　
  軽量Flashクラスで0.83台に到達。ただし真実性0.607は上位勢で突出して低く、事実性が重要な用途では別途検証をおすすめします
  
• Tencent Hy4（14位、0.8344）　
  Tencentのオープンモデルが総合TOP15に初登場（オープンモデルの章で詳しく紹介します）

この結果、前回3位のGemini 3.1 Pro（0.8430）は9位、前回4位のGPT-5.5（0.8411）は11位へ後退しました。スコアが下がったのではなく、上が増えたことによる押し出しです。

GLP×ALTの勢力図　今回の教訓は「真実性」

上の散布図は、GLP（言語性能）とALT（アラインメント）の2軸で主要モデルを配置したものです。

総合上位モデルはすべて右上、つまり「賢さ」と「安全性・制御性」を両立しています。

今回目立ったのは、速度・コスト重視系モデルの真実性の低さです。Gemini 3.6 Flashが0.607、GPT-5.6 lunaが0.636、grok-4.5が0.665と、いずれも総合スコアを大きく削られました。

前回のgrok-4.20（毒性0.566で総合40位）ほど極端な例はありませんでしたが、

「言語性能は高いのにアラインメント側で沈む」

という構造は今回もありました。

高速・低価格モデルを採用する際は、この軸の確認をおすすめします。

ベンチマーク結果の解釈について

本レポートで紹介するスコアは、あくまでもベンチマークテストにおける評価結果です。ベンチマークは、LLMの性能を客観的に比較する有用なツールですが、以下の点にご注意ください。

• ベンチマークは特定のタスクセットに基づいて評価されるため、そのタスク構成に適したモデルほど高いスコアを獲得する傾向があります
• 実際の業務での使用感や、特定の用途における有用性は、ベンチマークスコアだけでは完全には測れません
• モデルによっては、ベンチマークで測定されていない独自の強みや特徴を持っている場合があります

次は、オープンモデルに限定して実力をみていきましょう。今回はここが主戦場です。

オープンモデル 総合スコアランキング TOP20

※順位はモデル単位（同一モデルの複数評価ランはベストスコアのみ採用）です。

オープンモデル総合スコアの傾向と考察

Qwen3.8がオープン初の0.85超え　API首位との差は0.012まで縮小

前回「API勢がオープンを突き放した」とお伝えしましたが、2か月でまた形勢が変わりました。

AlibabaのQwen3.8-2.4T-A95B（0.8598）が、オープンモデルとして初めて総合0.85を突破し、総合でも3位に食い込みました。API首位との差は前回の約0.033から約0.012へ縮小し、本シリーズの分析上、過去最小です。

総2.4兆（2.4T）・アクティブ95BのMoEで、これまでAPI専用だったQwen Maxクラスをオープンウェイト公開した、Alibabaの本気の一手です。ALT 0.9171はオープン勢トップで、Claude勢に匹敵するアラインメントの高さも備えます。

ひとつ注意点があります。ライセンスはApache 2.0ではなく独自の「Qwen3.8-Maxライセンス」です。商用利用の際は条件の確認をおすすめします。

層の厚みも別次元になりました。0.80超えのオープンモデルは前回の4本から19本へ増えています。

中国勢の物量攻勢　Kimi K3、Tencent、GLM-5.3、DeepSeek V4

中国発オープンモデルの新顔ラッシュは今回も続いています。

• Kimi K3（0.8425）　Moonshot AIの総2.8T・アクティブ104B MoE。視覚入力対応のネイティブマルチモーダルで、コンテキストは100万トークン。オープン2位につけました（独自ライセンス）
• Tencent Hy4-preview（0.8344）　総770B・アクティブ49BのMoEをApache 2.0で公開。7月のHy3（0.8200、総295B・A21B）に続く矢継ぎ早の投入です
• GLM-5.3（0.8287）／GLM-5.3-Flash（0.8260）　Z.aiの最新世代。FlashはGLM-5シリーズ初のネイティブマルチモーダルで、MITライセンスの総320B・アクティブ18B。ベンダー公称では「GLM-5.2を上回る性能を10分の1の価格で」を掲げる構成です
• DeepSeek-V4-Flash（0.8169）　本体は総284B・アクティブ13BのMoE（今回評価の0731版は投機的デコード用モジュール込みの構成）。総1.6T・アクティブ49BのV4-Pro（0.8067）を上回っており、効率化世代の完成度がうかがえます
• MiniMax-M3（0.8061）　総428B・アクティブ23BのネイティブマルチモーダルMoEです

新興ラボの参入　Thinking MachinesとOrnith

今回のオープン部門でもうひとつ目を引いたのが、中国勢でもGoogleでもない新顔の登場です。

Inkling（0.8244）とInkling-Small（0.8222）は、米国の新興ラボThinking Machines Labが公開したモデルです。総975B・アクティブ41Bと総276B・アクティブ12BのMoEで、テキスト・画像・音声入力対応。Apache 2.0という太っ腹な公開形態で、初参戦でオープンTOP8に2本を送り込みました。

Ornith-1.5-397B（0.8161）はDeepReinforceチームによるMITライセンスのモデルです。Qwen3.5やGemma 4を土台に、タスク生成から学習までを自動化した自己改善型の強化学習で鍛えたと説明されています（ベンダー説明）。ゼロからの独自基盤ではありませんが、RLでここまで積み上がる点は興味深いところです。

この2社は素性もなかなか興味深いので、企業情報を表にまとめておきます。

※企業情報は各社公式サイト・公開報道に基づく2026年9月1日時点のものです。

国産オープンモデルと近隣の動き

日本発では、国立情報学研究所（NII）のllm-jp-4-33b-thinking（0.6760）が新たに登場しました。総33Bのdenseモデルで、11.7兆トークンの事前学習にSFTとDPOを重ねた拡張推論版です。Apache 2.0で、日本語対応を明示する数少ないモデルのひとつです。

既存勢では、東京科学大学SwallowチームのGPT-OSS-Swallow-120B-RL-v0.1（0.6914）が引き続き国産系トップ級です。

近隣では、韓国SK TelecomのA.X-K2（0.7041）が登場しました。総688B・アクティブ33BのMoEをスクラッチから学習したもので、トークナイザと学習データは英・韓・中・日・西の5言語を対象とし、日本語も含まれます（Apache 2.0）。ただし学習データの中心は英語と韓国語で、日本語の学習比率は約1%、品質検証も限定的とモデルカードに明記されています。LG AIのK-EXAONE-236B-A23B（0.7186）と合わせ、日本語を学習対象に含む韓国発オープンモデルの選択肢が広がっています。

さて、次は中規模10B～30B程度のモデルをみてみましょう。中規模モデルのうれしいところは、個人レベルでも比較的入手しやすいGPUでも実行できるところではないでしょうか。

中規模モデル（10B-30B）総合スコアランキング

※リーダーボード掲載中の評価ランに基づくため、前回掲載モデルの一部はアーカイブ化により今回の集計対象外です。中規模・小規模の区分（Qwen3.5-9BがMedium扱いである点など）もリーダーボードのサイズ区分に従っています。

中規模モデル総合スコアの傾向と考察

中規模カテゴリに、ついに0.80超えが誕生しました。Qwen3.8-27B（0.8091）です。

27Bのdenseモデルで、画像・動画入力にも対応するマルチモーダル構成。Apache 2.0で公開されています。前回王者のQwen3.5-27B（0.8049）を上回り、「30B級ローカルLLMの本命」がQwen内で世代交代した形です。

量子化を併用すれば単一GPU構成も視野に入るサイズで総合0.80超えという水準は、1年前のフロンティアAPI級に相当します（必要VRAMは精度やコンテキスト長で変わります）。オンプレ・機密データ用途の現実解が、また一段強くなりました。

もうひとつの注目は5位のMuse-Glimmer-30B（0.7754）です。

MetaがMeta Superintelligence Lab名義で公開した30Bのdenseモデルで、上位モデルMuse Sparkからの蒸留により、コンシューマ級ハードウェアでのエージェント動作を狙った設計です。Apache 2.0で、Metaの新シリーズが日本語ランキングに姿を見せたのは今回が初めてです。

さて、最後に小規模モデルもみてみましょう。こうした小型モデルは比較的安価なコンシューマ向けGPUでも動作しますので、エッジ・オンプレ用途の本命です。

小規模モデル（10B未満）総合スコアランキング

小規模モデル総合スコアの傾向と考察

小規模モデルは前回に引き続きQwen3.5-4B（0.7352）が首位です。わずか4Bで0.73超えという水準は、1年前なら30B級に相当するもので、小型化の進展を象徴しています。

2位のNVIDIA Nemotron Nano 9B v2 Japanese（0.7111）も引き続き健在です。日本語向けに追加学習された小規模モデルとしては現状ベストの選択肢でしょう。

新顔は3位のOrnith-1.5-9B（0.6909）です。オープンの章で紹介したOrnith-1.5シリーズの9B dense版で、MITライセンス。シングルGPU運用を想定した軽量版です。

Gemma 4のオンデバイス版E4B（0.6692）とE2B（0.6564）、東京科学大学SwallowチームのQwen3-Swallow-8B-RL-v0.2（0.6552）も、引き続き小規模の定番として並んでいます。

まとめ、本格導入に向けての道しるべ

今回もNejumi Leaderboard 4のベンチマークデータを分析いたしました。今回の分析でみえたポイントをまとめます。

「オープン0.85時代」の幕開け

今回の最大のポイントは2つあります。Claude Opus 5がリーダーボード上初の0.87台に到達したこと、そしてオープンモデルが初めて0.85を超え、API首位との差が0.012まで縮んだことです。

「最高峰はAPI、オープンは一段下」という前提は、この2か月で崩れはじめました。

0.80超えがモデル単位で42まで増えたいま、0.80は「上位グループへの入場券」ですらなくなりつつあります。

• 商用API勢　Anthropic（Opus 5／Fable 5）が頭ひとつ抜け、OpenAI（GPT-5.6系）、Google、Moonshot（Kimi K3）が追う構図へ
• オープン勢　Qwen3.8がAPI勢に肉薄。中国勢の物量に加え、Thinking Machines・Ornith・Metaなど米国系の新顔も参入
• 国産勢　llm-jp-4のthinking版が登場。Swallow RL版、Nemotron日本語版と、日本語特化の選択肢は着実に拡大

モデルサイズ別の特徴

LLMの本格導入にむけて　用途別の最適なモデル選択

今回は総合スコアを軸に各モデルの位置づけを見てきましたが、実際の導入判断はそれほど単純ではありません。

ベンチマークは有力な参考情報である一方、実務では精度だけでなく、推論コスト、応答速度、機密データの扱い、既存システムとの統合性など、多面的な評価が必要です。とくに今回のように選択肢が急拡大した状況では、「最もスコアの高いモデルを一つ選ぶ」というより、「用途ごとに複数のモデルを適切に使い分けられる状態をどう作るか」が、導入の現場ではより重要になります。

当社では、こうした複数モデル運用の実務に対応する選択肢として、複数のLLMを1つのプラットフォームで利用できる統合AIプラットフォーム Bestllam を提供しています。モデルの選定から、業務フローへの組み込み、AIエージェント活用を前提とした運用設計まで含めてご支援可能です。

また、単なるツール提供にとどまらず、貴社業務のAI化を見据えたBPRコンサルティングもあわせてご提供しており、業務分析からBPR計画策定、成功指標の設計、導入支援まで伴走いたします。

まずはお気軽にご相談くださいませ
https://qualiteg.com/contact?inquiry=consulting

こんにちは！

今回は、「AI × CAD・設計情報」シリーズ全7回の第2回目です！

見積もりのたびに、図面を開いて穴を数える。

φ6が4つ、φ8の止まりが3つ、ザグリはこれとこれ。

数えた結果をExcelに転記して、拾い忘れたザグリの深さを後から電話で確認する。3Dデータはとっくに手元にあるのに、拾い出しだけは今日も目視です。

解析曲面として出力されたSTEPでは、穴・ザグリ・皿ザグリ・フィレットを構成する曲面の寸法が数値として記録されています。

円筒面の半径、円錐面の開き角、面の向き。人が数えているものは、機械が読めるものです。

第1回ではSTEPをブラウザで開いて見る・測る・切る・渡すところまでを扱いました。今回は一段深く潜って、当社が無料公開している3D CADビューワー兼AI解析ツール「CADAS」に積んだフィーチャ認識、つまり穴・ザグリ・皿ザグリ・フィレットをSTEPのB-Repから自動で拾って表にする機能の中身を、実装した側の目線で書きます。数値はすべて実測値です。

まずは実物からどうぞ↓

下の穴種プレートは、厳密解析まで済ませた状態で埋め込んであります。右の表の行をクリックすると、その穴が3Dで光ります。ドラッグで回転、ホイールで拡大。ザグリ穴は赤、皿ザグリ穴は青、止まり穴は黄で塗り分けてあります。

この埋め込み自体もCADASの機能です。解析結果とマーキングを付けたままの状態を、iframeでWebサイトやブログに貼れます。仕組みはこのあと順に書きます。

穴種プレートを開くと、12個の穴が5行の表になる

CADASのサンプルギャラリーに「穴種プレート」というモデルを入れてあります。100×70×12mmの板に、通し穴・止まり穴・ザグリ穴・皿ザグリ穴・ボス上の止まり穴を配置したもので、当社がcadqueryで自前生成したものなので正解の寸法が分かっています。

読み込むと右ペインに「穴テーブル」タブが出ます。筆者環境（Windows＋Chrome）で、ギャラリーの決定ボタンを押してから表が出るまで2.8秒でした。

通し穴が4つ、止まり穴が3つ、皿ザグリが2つ、ザグリが2つ、ボスの止まり穴が1つ。種別と個数は設計どおりですが、直径の欄をよく見ると φ5.96、φ7.95、φ6.56 と、少しずつずれています。設計値は φ6、φ8、φ6.6 です。

このずれには理由があります。

ブラウザ内の解析は「三角形から円を推定」している

ブラウザに読み込んだ直後のCADASが持っているのは、STEPをパースして得た三角形メッシュと、その三角形がB-Repのどの面に属するかの対応表です。ここから穴を見つけるには、面ごとに三角形の法線の分布を調べて「これは円筒面らしい」「これは円錐面らしい」と統計的に判定し、円をあてはめて半径を推定します。

三角形の頂点は円周上に乗っていますが、三角形の重心は円周の少し内側に落ちます。φ6の穴に対して φ5.96 が出るのはそのためで、この重心ベースの推定法では避けられない近似です。種別の判定と個数の集計にはこれで十分ですが、

見積もりに書く数字としては、もう一歩ほしい。

そこでCADASは二段構えにしました。

穴テーブルの下にある「高度な分析（厳密解析）」を押すと、確認のダイアログが出ます。

同意して送ると、サーバー側でSTEPの本文から解析曲面のエンティティを直接読み取り、その結果だけを返します。穴種プレート（109KB）で往復0.82秒。1.03MBの減速ギアユニットでも同じ0.82秒でした。

φ6.000、φ8.000、皿 φ10.400 の90°、ザグリ φ11.000 の深さ4.000。設計値と小数第3位まで一致しました。メッシュ推定と厳密解析を並べると、こうなります。

種別と個数はどちらの経路でも全問正解、寸法は厳密解析でSTEPに記録された値そのもの（このサンプルでは設計値と一致）。この使い分けが、CADASのフィーチャ認識の骨格です。機密のファイルはブラウザ内の推定だけで数えて、寸法の正確さが要るときにサーバーへ送るかどうかを自分で決められます。

STEPのB-Repには何が書いてあるのか

ここからは中身の話です。

STEP（ISO 10303）のAP203/AP214/AP242では、ソリッド形状をB-Rep（境界表現）で表現でき、一般的な機械CADのSTEP交換ではこの表現が広く使われています。ソリッドは閉じた面の集合で、各面は「どの曲面の上にあるか」と「どの辺で区切られているか」で定義されます。この曲面の部分が肝心で、解析曲面として出力されている場合、円筒なら CYLINDRICAL_SURFACE に軸の位置・方向・半径が、円錐なら CONICAL_SURFACE に半頂角が、トーラス面なら TOROIDAL_SURFACE に大半径と小半径が、そのまま数値で書かれています。

穴種プレートのSTEPを数えると、円筒面19・円錐面2・トーラス面1・平面13、面の総数35でした。内訳は、通し穴4・止まり穴3・ザグリ穴の下穴とザグリで4・皿ザグリの下穴2・ボスの止まり穴1・ボスの外周1・四隅のR6が4で、円筒面が19。皿ザグリの皿が円錐面2、ボス根元のR2がトーラス面1、という対応です。

厳密解析のサーバー側がやっているのは、STEPの本文をレコードに分割して、

ソリッド→シェル→面→曲面

と参照を辿り、この数値を取り出すことです。

面がどちらを向いているかは、ADVANCED_FACE の same_sense フラグ（面の向きが曲面の法線と同じか逆かを表す）と、曲面の法線の向きを組み合わせて求めます。まあこれはふつうの3Dグラフィックでもやるポリゴン平面の向きの計算といっしょですね。で、これで穴の内壁とボスの外周を区別できます。境界の頂点を軸に投影すれば、その円筒がどの高さからどの高さまで続いているか（つまり穴の深さ）も出ます。

取り出した曲面を、穴に組み立てるのが分類器です。ルールは次のとおりです。

「同じ軸線上」の判定は軸間距離0.3mm以内、「同じ径」は直径差0.06mm以内としています。分類器はメッシュ推定の曲面にも厳密解析の曲面にも同じものを使います。

貫通判定で一度失敗した話

最初の実装では、貫通かどうかを「穴の高さレンジが局所の板厚をほぼ覆っているか」で決めていました。板厚は、穴の周囲にある頂点の高さの幅から推定します。

これが止まり穴で外れました。穴の周囲に頂点が少ないと板厚が過小に推定され、深さ6の止まり穴が「板厚をほぼ覆っている＝貫通」と判定されたのです。テッセレーションの粗さに依存するやり方は、こういう形で裏切られます。

今は、穴の両端で軸線を少しだけ延ばし、そこに三角形（穴の底面）があるかどうかを直接検査しています。底があれば止まり、両端とも無ければ貫通。テッセレーションの粗さに左右されにくい判定にしてから、穴種プレート・減速ギアユニット・24部品の時計ムーブメントの3サンプルで全問正解になりました。

もう一つ、平面が巨大なトーラス面に誤判定される件と、軸の向きが反転した円錐で皿の大径側と小径側を取り違える件も、この段階で潰しています。フィーチャ認識は、ルールを書くこと自体より、正解の分かっているモデルで外れ方を見ることに時間がかかります。

行をクリックすると、その穴が光る

表の数字だけでは、どの穴の話か分かりません。

行をクリックすると、3D表示でその種別の穴がすべてハイライトされます。

厳密解析の後は面の対応表を持たないので、穴の位置と径から軸方向に透過のマーカーを立てる方式にしています。壁の向こうにある穴も見えるので、板の裏から入る穴でも見失いません。

フィレットも同じ仕組みで拾える

「フィレット」タブには、トーラス帯と部分円筒帯をR値でまとめた一覧が出ます。穴種プレートでは、ボス根元のR2（トーラス帯・凹のすみ肉）が1箇所、プレート四隅のR6（円筒帯・凸の丸み）が4箇所でした。こちらも厳密解析で R2.000、R6.000 です。

最小Rが1mmを切ると、一覧の上に警告が出ます。工具径や応力集中の目安として、小さすぎるRを一覧の先頭で知らせる仕組みです。

アセンブリでも、部品をまたいで数えられる

単品の板だけでは実務に足りません。減速ギアユニット（5部品）で試します。

厳密解析の結果は、ザグリ穴 φ5.5（ザグリφ9×深さ3）が4個、φ10の通し穴が2個、φ10.2の通し穴が2個。φ10は歯車2枚のボア、φ10.2はベースプレートの軸穴で、歯車とプレートは別部品です。部品ごとの寸法が一つの表に集まっています。

こちらも実物を埋め込んでおきます。「ザグリ穴」の行をクリックしてみてください。ベースプレート四隅の4箇所が光ります。

アセンブリのSTEPでは、各部品は自分のローカル座標で定義され、配置関係と座標変換が別のエンティティ群で表現されています。厳密解析ではこの変換を親から順に再帰的に合成して、穴の位置をワールド座標に直しています。四隅のザグリが (±45, ±22) の位置に出ることを回帰テストで固定してあり、部品を動かしてもハイライトがずれません。

数えた先で、表をどう使うか

穴テーブルは「CSVに書き出し」でそのまま落とせます。穴種プレートの実物はこうです。

"種別","φ (mm)","深さ (mm)","個数","詳細","部品"
"通し穴","6","12","4","貫通","hole-plate"
"止まり穴","8","6","3","止まり","hole-plate"
"皿ザグリ穴","5.5","12","2","皿 φ10.4・90°","hole-plate"
"ザグリ穴","6.6","12","2","ザグリ φ11 × 深さ 4","hole-plate"
"止まり穴","5","10","1","止まり","hole-plate"

見積もりの拾い出しなら、この5行を単価表と突き合わせるだけです。

転記も、数え直しもありません。

もう一つ、行の右端にある「タグ」ボタンを押すと、その種別の穴の面がまとめて面マーキングに登録されます。減速ギアユニットでザグリ穴の行をタグ付けすると、4箇所×2面の8面、合計6.83cm²が「要確認」タグに入りました。

この状態を第1回で紹介した共有パッケージ（.cadas）にして渡せば、受け取った側は穴テーブルとマーキングが入った状態でモデルを開けます。「このザグリ、全部同じ深さでいいですか」を、穴に色が付いた3Dを見ながら聞けるわけです。

ファイルを渡す代わりに、この分析済みの状態をそのままWebページに埋め込む手もあります。この記事の冒頭と、減速ギアユニットの節に貼ってあるのがその実物で、「ファイル > 埋め込み・共有リンクを発行」から発行したiframeタグを貼っただけです。社内ポータルに貼れば、CADを持たない部門が穴テーブルを見ながら3Dを回せます。閲覧者を限定したいときは、発行時にユーザー名とパスワードを付けられます。

正解の分かるモデルで検証している

フィーチャ認識は、それらしい表が出るだけでは信用できません。

私たちは次の形で検証しています。

題材は自前生成のモデルだけにしました。

穴種プレートも減速ギアユニットもcadqueryのスクリプトから作っていて、φ6.6のザグリが (−20, 22) と (10, 22) にある、といった設計値がスクリプトに書いてあります。回帰テストはこの設計値と突き合わせ、メッシュ推定は近似許容、厳密解析は0.001mm以内の一致を要求します。

そのうえで、テストが本当に欠陥を捕まえるかも確かめました。貫通判定のキャップ検査を無効にする、円錐の端半径の入れ替えを外す、アセンブリの変換合成を止める、という3種類の欠陥をわざと注入し、それぞれでテストが落ちることを確認してから採用しています。

通るテストより、落ちるべきときに落ちるテストのほうが大事ですね。

まとめ

解析曲面として出力されたSTEPでは、穴・ザグリ・皿ザグリ・フィレットを構成する曲面の寸法が数値として記録されています。CADASはそれをブラウザ内のメッシュ推定で数え、必要なときだけサーバーの厳密解析で、STEPの解析曲面に記録された正確な幾何値に置き換えます。

今回の自前サンプルでは、その値が設計値と小数第3位まで一致しました。穴種プレートの12個の穴は5行の表になり、CSVに落ち、面に色が付き、共有パッケージで渡せます。

目視で数えていた拾い出しが、読み込んで一回クリックする作業になります。

次回の第3回は、金型の話です。

「この形、抜けません」

を設計中に知るための、抜き勾配・アンダーカット・肉厚の自動チェックを、正解の分かる樹脂ケースで実走します。

まずは穴種プレートを開いてみてください

CADASは無料・登録不要です。「ファイル > サンプルギャラリー」から穴種プレートを選び、右ペインの「穴テーブル」タブを開いてください。手元のSTEPを読ませる場合は、そのままブラウザ内の推定で数えられます。

CADAS（無料・登録不要）をブラウザで開く

当社コンサル部門では、ソースコードから3D CADデータまで、AI/ITを活用した設計現場のイノベーションを課題調査からソリューション導入まで一気通貫のご支援を提供しています。もしご興味あれば、 AI × CAD・設計情報コンサルティング（無料相談） まで、お気軽にご相談くださいませ。

それでは、また次回、お会いしましょう！

関連リンク

【AI×CAD 第1回】設計の3Dデータ、設計部門の外で誰も見られない問題を無料＋ブラウザだけで解決する（当ブログ）

CADAS - 3D CADビューワー兼AI解析ツール（無料・当社開発）

AI × CAD・設計情報コンサルティング | Qualiteg（コンサルティングのご案内）

こんにちは！

3Dデータはあるのに、それを見たい人にCADライセンスがない。設計部門には当たり前にある3Dモデルが、調達や営業、品質保証の手元には届かず、

「すみません、スクショを貼ってもらえますか」

というお願いが今日も飛び交う。多くの製造業で、これが日常になっています。

この記事は当社が無料公開している3D CADデータのビューワーおよび解析機能をそなえたブラウザだけで使えるWebアプリケーション「CADAS」を公開したので、何ができるか、どんな場面で効くかを、実際の画面や使用例でご紹介いたします。

インストール不要、登録不要、無料、外部送信なしでURLを開けばその場で使えます。

まずは以下をぐりぐりしてみてください。ドラッグで回転、ホイールで拡大です。これがブラウザだけで動きます。

CADAS - STEPファイル 3Dビューワー | Qualiteg

CADAS は STEP ファイル（.step/.stp）をブラウザ上で 3D 表示・計測・断面表示できるビューワーです。ファイルはブラウザ内で処理され、外部に送信されません。

CADASQualiteg Inc.

今回は「AI × CAD・設計情報」シリーズ全7回の第1回です。

第2回以降で、穴やザグリを自動で拾うフィーチャ認識、金型の抜き勾配チェック、AIによる設計レビューと、だんだん深いところへ潜っていきます。まず今回は、いちばん手前の「見る・測る・切る・渡す」を扱います。

「スクショを貼ってもらえますか」が生まれる構造

3D CADのライセンスは高価です。設計者の人数分そろえるだけでも大きな投資なので、「3Dを見たいだけ」の部門にまで配ることは、ふつうしません。

その結果、何が起きるか。

見積もり担当は、形状を確認したいだけなのに設計者の手が空くのを待つことになります。取引先との打ち合わせは2D図面とメールの往復になり、「ここの形、実際はどうなっていますか」という確認だけで数日かかります。

そして認識のズレは、モノができてから発覚します。

3Dデータそのものは、とっくに社内にあるのにです。

当社はコンサルティングの現場で、CADデータをはじめとする設計情報のAI活用についてご相談をいただく機会が増えています。

話を聞くと、AI活用のような先進的なテーマの手前で、この

「そもそも3D CADデータを開ける人が少ない」

という問題が横たわっていることが多いのです。

ブラウザでSTEPファイルを開く

CADASの使い方は、cadas-ai.com を開いて、STEPファイル（.step / .stp）をドラッグ&ドロップする。これだけです。

無料でお使いいただけます。

手元にSTEPファイルがなくても試せるように、サンプルギャラリーを内蔵しています。メニューの「ファイル > サンプルギャラリー」から、減速ギアユニット・アナログ時計ムーブメント・穴種プレート・樹脂ケースの4つのモデルを選べます。

減速ギアユニットを開いてみます。1.03MBのSTEPファイルで、ソリッド5個・三角形5,908枚。読み込み時間を実測すると、筆者環境（Windows＋Chrome）でファイルの取得から3D表示まで約2.4秒でした。

マウスでぐりぐり回せて、右のパネルにはファイル名・ソリッド数・寸法（このモデルは 110.00 × 64.00 × 44.00 mm）が出ます。STEPヘッダに記録された作成者や出力元CADの情報、アセンブリ構造のツリーもタブで見られます。

ここまでに必要だったものは、ブラウザだけです。

見るだけでなく、測れて、切れる

「見られる」だけだと、打ち合わせではもう一歩足りません。

会話の中でよく出てくるのが「ここの長さいくつ？」と「中はどうなってるの？」だからです。

計測ツールでは、モデル上の2点をクリックすると距離が出ます。試しに大歯車の歯先から歯先までを測ると 70.20 mm でした。

断面ツールでは、X/Y/Z軸を選んでスライダーを動かすだけで、モデルをその位置でスパッと切った状態を見られます。中の構造がどうなっているか、部品同士がどう組み合わさっているかを確認するのに使えます。

2D図面とメールで数日かかっていた「ここの形どうなってますか」の確認が、同じ画面を見ながらその場で終わる。CADASが狙っているのは、まさにこういうシーンです。

主要なCADなら、STEPを経由して開けます

CADASが読むのはSTEP（ISO 10303）形式です。

STEPはCAD業界の標準交換フォーマットで、主要な3D CADの多くがSTEP出力に対応しています。

※対応するAPや必要なライセンス・モジュール構成は、製品・バージョン・契約内容によって異なります。詳しくは各CADのマニュアルをご確認ください。

CADASが読めるSTEPのアプリケーションプロトコル（AP）は AP203 / AP214 / AP242 です。設計部門でSTEPに書き出して共有フォルダに置いておけば、受け取った側はブラウザで開くだけ。相手が同じCADを持っていなくても、形状を共有しやすくなります。

機密のCADデータを、外に出さずに扱える

ここが、社内で使うときにいちばん大事なところです。

設計データは会社の機密そのものです。便利だからといって、素性の分からない外部サービスにCADデータをアップロードするわけにはいきません。

この理由で「便利なWebツールは全部NG」になっている会社も多いはずです。

CADASでは、

表示・計測・断面といった基本機能の処理はすべてブラウザの中で完結し、STEPファイルは外部へ送信されません。

機密データを扱う前提で、解析をブラウザ内処理だけに限定して使える設計です。

なお、一部の高度なＣＡＤデータ分析やAI所見機能に限り、画面上の確認にユーザーが明示的に同意した場合だけSTEPファイルを当社サーバーへ送信します
（ダイアログで明示的に同意しなければ送信されません）。

図1のとおり、設計部門がSTEPで書き出して社内の共有フォルダに置き、CADASのURLを案内すれば、CADライセンスのない部門も同じ3Dを見て話せるようになります。

取引先へは、STEPファイルを普段お使いの安全な受け渡し手段で渡せば、相手はブラウザで開くだけです。CADASがファイルを預かるわけではないので、データの置き場所は自社の管理下のままです。

渡す側の「ここを見てほしい」も、一緒に渡せる

STEPファイルを渡せば、相手はブラウザで開けます。

ただ、実際のやりとりでは、渡す側に「ここを見てほしい」があるものです。この穴の公差、この面の仕上げ、この逃げの要否。それをメールの文章で書くと、今度は「どこの話ですか」の往復が始まります。

CADASでは、モデルの上に付箋を貼れます。部品をクリックして「歯面の仕上げはこの面粗度で足りますか？」のようなコメントを残すと、貼った瞬間の視点も一緒に記録されます。

付箋は引き出し線でその場所につながっていて、ビューを回しても線が追従するので、どこに貼った付箋かが一目で分かります。付箋をクリックすると、貼った人が見ていたのと同じ画角に切り替わります。「どこの話か」の説明が、ほとんど要らなくなります。

面に意味を載せることもできます。「要確認」「加工指示」のようなタグを選んで面を塗り分けると、この面とこの面は同じ工程、ここは要検討、が3Dのまま伝わります。タグごとの面数と合計面積は自動で集計され、CSVに書き出せます。

そして「ファイル > 共有パッケージを書き出し」を選ぶと、STEPファイル・付箋・視点・マーキング・断面などの表示状態が、1つの .cadas ファイルにまとまります。受け取った人はそれをCADASにドラッグ&ドロップするだけ。付箋が貼られ、視点が仕込まれた状態がそのまま開きます。このパッケージもお使いの端末内で作られ、外部へは送信されません。

渡すときには「閲覧モード」を選べます。受け取った側の画面は表示・計測・断面・付箋の確認だけに絞られるので、CADを触ったことのない人にもそのまま渡せます。付箋の書き足しだけを許可して、指摘への返信をもらう使い方もできます。

この共有パッケージも実物を埋め込んでおきます。付箋とマーキングがどう見えるか、回して確かめてみてください。

「見る」の先に、解析とAIがあります

実はCADASは、ただのビューワーではありません。

幾何カーネルがSTEPのB-Rep構造（形状の数学的定義）を直接解析するエンジンを積んでいて、

穴・ザグリ・皿ザグリの自動分類、
フィレットの集計、
金型の抜き勾配チェック、
歯車のかみ合いを実測して連動回転させる機構推定、

そして解析した実測値をもとにAIが設計所見を生成する機能まで搭載しています。

このあたりの中身は、シリーズの第2回以降で1つずつ書いていきます。

第2回は「穴とザグリを自動で拾う」フィーチャ認識の話です。見積もりのたびに穴を目視で数えている方には、ぜひ見ていただきたい内容です。

まずはサンプルギャラリーを触ってみてください

CADASは無料で公開しています。

登録も不要です。手元にSTEPファイルがある方はドラッグ&ドロップで、ない方は「ファイル > サンプルギャラリー」からどうぞ。

CADAS（無料・登録不要）をブラウザで開く

CADデータをはじめとした設計情報の管理やAIを活用した設計知の活用と伝承といったテーマのご相談が増えてきており、AI × CAD・設計情報コンサルティング（無料相談）の窓口を開設して課題調査からソリューション提案まで皆様からのご相談を受け付けています。

また、本稿でご紹介したCADASについても、貴社イントラネット内での安全な導入活用や、CADデータ解析機能の拡張など、お気軽にご相談ください。

それでは、また次回、お会いしましょう！

関連リンク

• CADAS - STEPファイル 3Dビューワー（無料・当社開発）
• AI × CAD・設計情報コンサルティング | Qualiteg（コンサルティングのご案内）

こんにちは、Qualiteg研究部です。

私たちは PII-FI という、個人識別情報や機密情報の検出とマスキングを行うツールを開発・提供しています。

あるとき、いくつかのGitHubのリポジトリをPII検査したところ、製品名や識別子に含まれる短い技術語を、組織名や社内用語として拾う誤検出が見つかりました。

数件の除外語を足せば、その画面だけは直せます。

しかし未知のリポジトリでは、別の技術語、issue番号、バージョン番号、識別子の断片へ誤検出先が移ります。

PII-FIのパイプライン処理の一部でNER（固有表現認識）を使用しているのですが、今回はNERの継続学習に関する技術記事となります。

当社では、これまで数年間をかけて構築した大規模コーパスを使い学習した強力なNERを扱っていますが、これを便宜上「強NER」と呼ぶことにして、本記事を執筆してまいりたいとおもいます。

さて、冒頭ご説明した誤検出について、私たちは、辞書による例外処理ではなく、強NERそのものを継続学習で直しました。

今回正式採用までに作成したNERモデルは100を超えます。目的の誤検出を0にできた候補は途中にもありましたが、既存文書の再現率や別の固有表現の種類を少しでも悪化させた候補は採用しませんでした。

本記事では、こうした　ポロポロ　とでてくる誤検出にたいして、学習済モデルをどのように進化させていくか、という点について私たちの実験で得られた知見を共有させていただければとおもいます。

結論から言うと、勝ち筋は「大きな学習を一度当てる」ことではありませんでした。
現行モデル自身から難しい負例（ハードネガティブ）を採掘し、未知表現の多様性と既存モデルが失いやすい弱い正例境界を別々に守り、残った数件だけを最小限の学習で修復し、最後に種類別の未正規化スコア（ロジット）を必要な幅だけ補正する。
この順序が、誤検出をなくしながら既存性能も上げる交点を作りました。

この記事では、モデル名、顧客データ、内部の学習文書そのものは公開せず、再利用できる学習設計、数式、失敗の読み方、採用ゲートを紹介します。

1. 最初に「合格」を数式で固定する

改善を始める前に、採用条件を固定しました。

全体F1が上がればよい、ではありません。

固有表現の種類を \(c\)、現行モデルを \(\mathrm{base}\)、新候補を \(\mathrm{new}\) とすると、製品評価では少なくとも次を満たすことを条件にしました。

$$\begin{aligned} \mathrm{TP}_{\mathrm{new}}(c) &\ge \mathrm{TP}_{\mathrm{base}}(c) \\ \mathrm{FP}_{\mathrm{new}}(c) &\le \mathrm{FP}_{\mathrm{base}}(c) \\ \mathrm{FN}_{\mathrm{new}}(c) &\le \mathrm{FN}_{\mathrm{base}}(c) \qquad \forall c \end{aligned}$$

ひとつの型でも正解を失えば不採用です。

目的の技術語で誤検出が0でも、別分野の人名を1件落とした候補は不採用にしました。この基準を後から緩めないことが重要です。

候補を長く追い込むほど、「ここまで良くなったのだから採用したい」という心理が働くからです。
（とくに１０回、２０回と学習を重ねると、なんかの値が多少さがっていても、他の値が圧倒的にのびていれば、「もーこれでいいじゃん」という悪魔のささやきに完全にまけそうになります）

適合率（Precision）、再現率（Recall）、F1も確認します。

$$\begin{aligned} P &= \frac{\mathrm{TP}}{\mathrm{TP}+\mathrm{FP}} \\ R &= \frac{\mathrm{TP}}{\mathrm{TP}+\mathrm{FN}} \\ F_1 &= \frac{2PR}{P+R} \end{aligned}$$

ただし、これらの集計値は最後の要約です。採否を決めるのは、種類別のTP、FP、FNと、実際に増減した検出範囲です。

図1　誤検出の発見から正式採用までの改善ループ

2. データを4区画に分け、見た評価は検証用と呼ぶ

最初に、実PIIを含まない合成技術文を用意しました。重要なのは件数より分離方法です。

重複を避ける対象は文書全文だけではありません。語彙、識別子の構成部品、接頭辞・接尾辞、文型テンプレートも分離しました。たとえば同じ語を別のテンプレートへ入れただけでは、語を暗記したモデルでも合格してしまいます。逆に単語を変えても識別子の部品や文型が同じなら、未知性を過大評価します。

各集合は件数とハッシュを固定しました。再生成のたびに内容が変わる評価では、候補間の差を学習効果として説明できません。

ここで大切なのは呼び方です。

追加検証用の結果を見て学習条件を変えた時点で、その集合は独立した最終テストではなく検証用です。固定回帰用も、最初の有望候補で開くまでは未開封でしたが、その後は複数候補の非劣化確認へ再利用しました。したがって、この記事では「最後まで未使用のテストで性能を保証した」とは書きません。100回超の適応的な探索で見た集合は、正直に開発・回帰用として扱います。

3. 選んだ単語ではなく、モデル自身の誤検出を採掘する

最初は、誤検出した技術語を負例として教えました。しかし、その単語を抑えると、同じ文のissue番号やバージョン番号、隣接する短い断片へ誤検出が移りました。

そこで、現行モデルを学習側に固定した合成技術文へ通し、対象の定義上は固有表現でないと生成規則または注釈で確認できた位置のうち、モデルが実際に固有表現と判定した検出範囲を採掘しました。開発用、追加検証用、固定回帰用の本文は採掘へ使っていません。難しい負例は、人が「難しそう」と選んだ語ではなく、現在の判定境界が実際に負けた位置です。

対象種類の未正規化スコアを \(z_e\)、固有表現ではないOのスコアを \(z_O\)、必要な余裕幅を \(m\) とすると、負例位置では次のような二者間のマージン損失を使えます。

$$\mathcal{L}_{\mathrm{neg}}=\max\!\left(0,\,m+z_e-z_O\right)$$

すでに \(z_O\) が十分高い負例には勾配を掛けず、誤検出している境界だけを必要な幅まで押し戻します。文書全体をOとして学習するより、変更範囲を狭くできます。

4. GitHub文書を丸ごとOにすると、正しい固有表現まで壊れる

大きな失敗のひとつは、技術文書の未注釈単位（token）をすべてOとして学習したことでした。学習内のスコアは高くなり、未知技術語の誤検出も大幅に減りました。しかし、別分野の実文書では、本来拾うべき社内固有語の再現率が落ちました。

理由はtoken数の偏りです。ひとつの文書には少数の訂正対象と大量の背景tokenがあります。背景をすべてOとして交差エントロピー損失へ入れると、今回直す必要のない位置までO方向へ押します。本件は新しい固有表現クラスを順に増やすclass-incremental NERそのものではありません。ただし、未注釈の固有表現までOとして学習すると既存の識別能力を壊し得る、という構造は継続NERの既往研究と共通しています。

訂正対象tokenの集合を \(M\) とすると、訂正箇所に限定した交差エントロピー損失は次のように書けます。

$$\mathcal{L}_{\mathrm{focused}} =-\frac{1}{|M|}\sum_{t\in M}\log p_{\theta}(y_t\mid x)$$

\(M\) 以外は単純なO正解として扱いません。損失計算から除外するか、旧モデルを教師モデルとして、その出力を保護します。

主要な失敗系統を比較する

5. 正例は「強くする」のではなく、2種類に分けて守る

負例だけを学習すると、本物の固有表現まで弱くなります。では正例を大量に反復すればよいかというと、これも失敗しました。正例の交差エントロピー損失を強くすると、未知の一般語まで固有表現側へ寄り、適合率が下がりました。

最終的に必要だった正例は、役割の違う2種類でした。

多様な合成正例だけでは、既存製品にある弱い境界を守れません。弱い境界だけでは、その文脈を覚えて未知表現へ広がりません。この2軸を同じ学習単位（バッチ）で負例と競合させたとき、未知正例と既存TPを同時に保てる候補が初めて現れました。

図2　負例修正と3種類の保護を釣り合わせる

6. 旧モデルは正解ラベルではなく、動かさない基準として使う

既存能力を守るため、現行モデルを教師モデルとして使いました。訂正対象以外のtoken集合を \(U\)、教師モデルと生徒モデルの未正規化スコアをそれぞれ \(z_t^T\)、\(z_t^S\) とすると、文脈安定化損失は次の形です。

$$\mathcal{L}_{\mathrm{KD}} =\frac{1}{|U|}\sum_{t\in U}\left\lVert z_t^S-z_t^T\right\rVert_2^2$$

または温度付きソフトマックスに対するKLダイバージェンスを使えます。重要なのは、分類器の既存行を凍結しただけでは既存種類を守れないことです。

LoRAでエンコーダーが変われば、固定した分類器へ入る表現も変わり、最終的な未正規化スコアは動きます。分類器の凍結と出力蒸留は別の保護です。

今回の全体損失は、概念的には次の組み合わせになりました。

$$\mathcal{L} =\mathcal{L}_{\mathrm{neg}} +\alpha\mathcal{L}_{\mathrm{pos}} +\beta\mathcal{L}_{\mathrm{KD}} +\gamma\mathcal{L}_{\mathrm{preserve}}$$

\(\mathcal{L}_{\mathrm{neg}}\)は誤検出境界の修正、\(\mathcal{L}_{\mathrm{pos}}\)は多様な合成正例と弱い正例境界に対する教師あり損失、\(\mathcal{L}_{\mathrm{KD}}\)は訂正箇所以外の出力維持、\(\mathcal{L}_{\mathrm{preserve}}\)は既存分野から固定したラベル付き保持データに対する教師あり損失です。

係数は大きいほど安全なのではありません。正例保護が強すぎれば誤検出が戻り、負例修正が強すぎれば再現率が落ちます。各損失値の桁は目安として確認し、最終的には開発用データのFP、FN、検出範囲の差分を見て、一方の目的だけが改善する設定を除外しました。

7. 一度に完成させず、残差だけを局所修復する

広い学習で誤検出を数件まで減らした後は、同じ規模の学習を繰り返しませんでした。

残った誤検出範囲と、新候補が失った正解範囲を差分で特定し、そのトークナイザーから見える文脈窓だけを使って小さく修復しました。

修復へ戻した本文は、学習用データと正式な学習源から再生成した開発用回帰窓に限定しました。固定回帰用データで見つかった本文を、そのまま学習へ戻してはいません。

ここでは「差し引きで改善している」だけでは足りません。種類ごとに改善と悪化を分けます。ある種類でTPが差し引き同数でも、別の正解を1件失い、新しい正解を1件得ている可能性があります。失った検出範囲を特定できれば、その1件だけを正例窓として残差負例と同時に学習できます。

学習率、学習ステップ数、正例損失の重みは小刻みに比較しました。残る誤検出の信頼度と検出範囲の長さも追います。誤検出が2文字から1文字へ縮み、Oとの余裕幅が0へ近づいているなら、改善方向へ動いている兆候とみなし、追加の小さな学習を試す材料にしました。逆に件数が同じでも信頼度が上がっていれば、その系統は打ち切れます。

最終候補へ近づいた局面では、数回の学習ステップの差、正例重みの小さな差が、未知正例の維持と最後の誤検出0を分けました。

100回超の探索で得たのは、大規模なハイパーパラメータ探索ではなく、
失敗差分を次の小実験へ変換する方法です。

8. 評価は軽い門から重い門へ進める

全候補へ製品全体の評価を実行すると、時間を浪費します。

前の門を通った候補だけ次へ進める漏斗にしました。

1. 目的の誤検出集合
   ↓
2. 学習と分離した追加検証用の未知正例
   ↓
3. 基本的な技術負例
   ↓
4. 大規模な負例耐性試験
   ↓
5. 開封後は再利用する固定回帰用データ
   ↓
6. 製品文書の型別TP・FP・FN
   ↓
7. 異分野の適合率・再現率
   ↓
8. 実際のランタイム契約
   ↓
9. 正式基準一式

目的集合で1件でも残る候補を重い評価へ進めません。

未知正例が基準未達なら負例耐性試験を回しません。製品評価では全体F1だけでなく種類別の検出範囲の差分まで保存します。ここに並べた門は、いずれも最終候補を選ぶための開発・回帰用です。不合格理由を次の学習データまたは損失設計へ戻したため、独立した最終テストとは区別します。

図3　候補を正式採用まで絞り込む評価漏斗

9. 最後は全種類一律ではなく、種類別スコアを最小幅だけ補正する

学習後の有望候補は、目的の技術誤検出と製品評価を通りましたが、別分野の適合率が合格線へわずかに届きませんでした。

Oの未正規化スコアを全種類に対して一律に上げると適合率は改善します。しかし、本物の未知固有表現までまとめて消えました。

そこで、誤検出が集中した2種類だけへ負方向のバイアスを加え、該当種類の未正規化スコアをわずかに下げました。

$$z'_c=z_c+b_c,\qquad b_c<0$$

これは特定単語の除外語リストではありません。同じ種類の全候補に作用します。

また、確率と正答率を合わせる通常の意味での「校正」ではなく、種類別のロジット補正です。補正幅は開発用の異分野評価で比較し、合格線を越える最小値を採用しました。その後、未知正例、固定回帰、製品の全種類、正式基準をすべて再実行しました。それ以上強い補正は、適合率が上がっても本物を余計に落とすため捨てました。

10. 最終結果と、成功の決め手

正式候補は、固定したGitHub技術語評価、追加検証用の未知正例、基本負例、大規模な負例耐性試験、固定回帰用データを通過しました。

製品評価でも、旧モデルに対して正解が増え、同一の固定製品回帰データ上で誤検出が約400件減り、見逃しも減りました。

主要な固有表現の種類を含め、種類別TP・FP・FNの悪化は0でした。

ここでいう誤検出0は、固定した評価集合上の実測値であり、あらゆる未知リポジトリで誤検出が起きないという意味ではありません。

成功をひとつの手法へ要約するなら、LoRAでも蒸留でもマージン損失でもありません。

次の組み合わせです。

1. モデル自身の誤検出を難しい負例にする
2. 未注釈tokenを安易にOへ落とさない
3. 未知表現の多様性と、既存の弱い正例境界を別々に守る
4. 旧モデルを教師モデルとして訂正箇所以外の出力を固定する
5. 残差だけを最小限の学習で修復する
6. 最後は誤差が集中した種類だけを最小幅で補正する
7. 全体F1ではなく全型のTP・FP・FNで採用する

今回、強NERの主要な改善は100回超の学習を経て実現し、新しいモデル成果物として正式採用しました。

まとめ

最後に、学習を成功させるための重要な論点を質問形式でまとめて書いておきます

• 学習用、開発用、追加検証用、固定回帰用の役割を分けたか
• 語彙だけでなく識別子部品と文型も分離したか
• モデル自身の誤検出範囲を採掘したか
• 未注釈tokenを全部Oとして学習していないか
• 正例の多様性と弱い境界を両方保護したか
• 分類器を凍結しただけで旧型を守ったつもりになっていないか
• 候補ごとの改善と悪化を検出範囲単位で保存したか
• 軽い門を通った候補だけ重い製品評価へ進めたか
• 全体F1の改善で型別劣化を隠していないか
• 種類別スコア補正は合格線を越える最小幅で止めたか

NERの継続学習では、目的データのスコアを上げることより、どの能力を動かさないかを測れることのほうが難しいものです。

100回超の失敗を候補名の列で終わらせず、誤検出の移動、信頼度の変化、失った検出範囲、種類別の改善と悪化を次の小実験へ変換する。

そこまで設計して、初めて改善作業が再現可能になるということが、実体験を経て理解できました。

以前の記事「モデルを「壊さずに」ドメインを広げる　XLM-RoBERTa継続学習の設計ノート」では、追加学習で動かす範囲を限定する考え方を紹介しました。

今回は、その限定学習でも一度では合格できなかったとき、データと評価をどう組み直したかという続編です。

それでは、また次回お会いしましょう！

出典・参考

• Continual Named Entity Recognition without Catastrophic Forgetting（EMNLP 2023）
• Learning “O” Helps for Learning More: Handling the Unlabeled Entity Problem for Class-incremental NER（ACL 2023）

関連記事

• モデルを「壊さずに」ドメインを広げる　XLM-RoBERTa継続学習の設計ノート
• PII非識別化の設計原則

こんにちは！

「TensorRT 10 × Blackwell 移行ガイド」シリーズもいよいよ最終回です。前編では TensorRT 化の基本と「5D（volumetric）の grid_sample はビルドが拒否される」という壁を、中編では「ビルドが通っても正しいとは限らない」沈黙劣化の数々を扱いました。

後編は、前編で保留にした最大の宿題に挑みます。TensorRT がネイティブに対応していない 5D grid_sample を、カスタムプラグインで通す話です。ゴールは明確で、前編でこのエラーを出したのと同じモデル・同じ入力から export した ONNX を、5D の GridSample ノードだけプラグイン用ノードへ置き換えて、最後までビルド・実行することです。

INetworkDefinition::addGridSample: Error Code 3: API Usage Error
(Parameter check failed, condition: input.getDimensions().nbDims == 4. ...)

先に結論を言うと、通りました。PyTorch の F.grid_sample（5D）と最大絶対誤差 7.2e-07 で一致するエンジンができています。ただしそこまでの道には、Blackwell 世代ならではの壁がいくつも立っています。本記事ではその壁と越え方を、実機ログつきで順に共有します。

この記事の対象環境 WSL2 Ubuntu 24.04 ／ NVIDIA RTX PRO 4000 Blackwell・GeForce RTX 5060 Ti（ともに Compute Capability 12.0 = sm_120）／ PyTorch 2.11.0 + cu128 ／ TensorRT 10.16.1.11 ／ システム nvcc は CUDA 12.0（あえて古いまま使います。理由は本文で）。 題材のプラグインは OSS の grid-sample3d-trt-plugin（Apache License 2.0）です。リポジトリに正式リリースは無いため、本記事で使用したコミット（f964750）を明記しておきます。改変版のソースや .so を再配布する場合は、同ライセンスの条件（ライセンス文・著作権表示の同梱など）に従ってください。本記事のコード・ログ・数値はすべて実機の実測です。

第1部: プラグインという仕組み — TensorRT は「知らない op」をどう扱うか

前編で見たとおり、TensorRT の ONNX parser は、GridSample ノードの入力が 5 次元だとその場でビルドを拒否します。ネイティブ実装が存在しないからです。

こういうときのための正式な拡張機構がカスタムプラグインです。仕組みはこうなっています。

1. 演算の CUDA カーネルと、TensorRT へのアダプタ（プラグインクラス）を C++ で書き、共有ライブラリ（.so）にする
2. プロセス起動時にその .so をロードすると、プラグインが TensorRT の plugin registry に登録される
3. ONNX parser は、知らない op_type に出会うと plugin registry を検索し、同名のプラグインが見つかればそれをレイヤとして組み込む

つまりやることは 2 つです。(a) 5D grid_sample のプラグインを Blackwell で動く形にビルドする。(b) ONNX の GridSample ノードを、プラグインの op 名に張り替える。

幸い、(a) のカーネルをゼロから書く必要はありません。TensorRT 8 の時代から使われてきた OSS 実装 grid-sample3d-trt-plugin があり、5D grid_sample の CUDA カーネルとプラグインクラスが揃っています。問題は、これを TensorRT 10 × Blackwell の環境でビルドし直すところに集中しています。

第2部: ビルドの壁 3 連発

まず、プラグイン本体を本記事と同じソースで取得しておきます。

git clone https://github.com/SeanWangJS/grid-sample3d-trt-plugin.git
cd grid-sample3d-trt-plugin
git checkout f964750

壁その 1: pip で入れた TensorRT には、開発用ヘッダが入っていない

プラグインのビルドには TensorRT の C++ ヘッダ（NvInfer.h など）とリンク用の libnvinfer.so が必要です。ところが、pip の tensorrt-cu12 パッケージに入っているのは実行用の .so だけで、ヘッダは一切含まれていません。

NVIDIA が案内する正規の方法は、tar / Debian / RPM などヘッダを含む配布形態を使うことです。以下は「pip 環境を二重化したくない」場合に当社環境で実証した回避策、という位置づけで読んでください。NVIDIA/TensorRT の OSS リポジトリから、pip 版とバージョンの合う公開ヘッダだけを取ってくる方法です。

# ヘッダ: OSS リポの対応タグ（v10.16）を blob:none で軽量 clone
git clone --depth 1 --branch v10.16 --filter=blob:none \
    https://github.com/NVIDIA/TensorRT.git ~/trt_headers
# → 使うのは ~/trt_headers/include/ だけ

# リンク用 lib: pip が入れた実行用 .so へ symlink を張る
#（リンカは -lnvinfer で libnvinfer.so を探すので、バージョン付きの実体へ繋ぐ）
# .so の場所は環境ごとに違うので、Python に聞くのが確実
TRT_LIB_DIR="$(python -c "import pathlib, tensorrt_libs; print(pathlib.Path(tensorrt_libs.__file__).parent)")"
mkdir -p ~/trt_link
ln -sf "$TRT_LIB_DIR/libnvinfer.so.10" ~/trt_link/libnvinfer.so

TensorRT の公開 API・ABI はセマンティックバージョニングに従うため、v10.16 タグのヘッダと pip の 10.16.1.11 という近接した組み合わせは理にかなっており、実機でビルド・動作を確認しました（異なる minor 系列を混ぜる場合、特に新しいヘッダの API を古いライブラリへリンクする向きは成立しない可能性があるので、実際の組み合わせで確認してください）。

もうひとつ、元リポジトリの CMakeLists.txt は、この 2 つの場所をそのままでは参照してくれません。次の変更を入れて、外から渡せるようにします（CUDA_ARCHITECTURES の行は次の壁で説明します）。

# 追加: 外部から渡した TensorRT のヘッダ・lib を使う
target_include_directories(${PROJECT_NAME} PRIVATE
    "./src" ${CUDAToolkit_INCLUDE_DIRS} ${TensorRT_INCLUDE_DIR})
target_link_directories(${PROJECT_NAME} PRIVATE ${TensorRT_LIB_DIR})
target_link_libraries(${PROJECT_NAME} PRIVATE nvinfer CUDA::cudart)

ビルドコマンドはこうです。

mkdir build && cd build
cmake .. -DCMAKE_BUILD_TYPE=Release \
  -DTensorRT_INCLUDE_DIR="$HOME/trt_headers/include" \
  -DTensorRT_LIB_DIR="$HOME/trt_link"
cmake --build . --parallel

壁その 2: 手元の nvcc が Blackwell を知らない

次の壁が本記事の山場です。プラグインの CUDA カーネルをコンパイルしようとすると、こういう状況に直面します。

• Blackwell（sm_120）向けのネイティブコードを吐けるのは CUDA 12.8 以降の nvcc
• ところが手元のシステム nvcc は CUDA 12.0（nvcc --list-gpu-arch の上限が compute_90）
• CUDA toolkit を入れ替えれば解決するが、既存環境への影響が大きい

ここで効くのが、PTX の forward compatibility（前方互換） です。CUDA のコンパイルには 2 段階あります。nvcc がソースを PTX（仮想アーキテクチャ向けの中間表現）へ落とす段階と、PTX を実 GPU 向けのネイティブコード（SASS）へ落とす段階です。後者は GPU ドライバが実行時に JIT コンパイルすることもできます。

つまり、「nvcc では compute_90 の PTX までを作り、sm_120 への最終変換は Blackwell 対応済みのドライバに任せる」という分担にすれば、古い nvcc のままでもビルドできます。CMake ではこう書きます。

# compute_90 の PTX のみを埋め込む（"90" だと SASS も作ろうとして失敗する）。
# 実行時に driver が PTX → sm_120 へ JIT コンパイルする
set_target_properties(${PROJECT_NAME} PROPERTIES CUDA_ARCHITECTURES "90-virtual")

ビルドした .so に本当に PTX しか入っていないことは、cuobjdump で確認できます。

$ cuobjdump libgrid_sample_3d_plugin.so | grep -E "arch|Fatbin" | sort | uniq -c
      1 Fatbin ptx code:
      1 arch = sm_90

ネイティブコード（Fatbin elf code）の行がなく、PTX が 1 本だけ。この状態で sm_120 の GPU にロードすると、ドライバが JIT コンパイルして動きます（後述の数値照合が通っていることが、JIT が正しく機能した証明になります）。初回実行時には PTX の JIT コンパイル時間が発生します（本記事ではその時間は計測していません）。

余談ですが、JIT の検証手段として CUDA_FORCE_PTX_JIT=1（全カーネルを PTX からの JIT に強制する環境変数）も知られています。ただし当環境で試したところ、プロセス全体に効くため、SASS しか持たないカーネルを含む PyTorch 側が no kernel image is available で先に落ちました。PyTorch と同居するスクリプトでは使えないので、プラグイン単体の確認は上記の cuobjdump と数値照合で行うのが実務的です。

壁その 3: deprecated 警告の山

ビルドログには、IPluginV2DynamicExt 系 API への deprecated 警告が並びます。この API は TensorRT 10.0 で deprecated になっており、新規実装には V3 系が推奨されています。本記事の TensorRT 10.16.1.11 では警告止まりで、実際にビルド・実行できました。ただし TensorRT 11 では V2 系プラグイン API 自体が削除されているため、このプラグインをそのまま 11 系へ持っていくことはできません。今回は OSS 実装を無改変で活かす方針なので、警告は許容して先へ進みます（新規にプラグインを書き起こすなら V3 系 API を使ってください）。

ここまでの 3 つの壁を整理すると、次のとおりです。

第3部: ONNX ノードを張り替えて、ビルドを通す

プラグインができたら、次は (b) の張り替えです。前編で使った 5D のダミーモデル VolumetricWarp を、まったく同じように export します。

class VolumetricWarp(nn.Module):
    """5D（volumetric）grid_sample を含む最小モジュール（前編と同じ）"""
    def forward(self, vol, grid):
        return F.grid_sample(vol, grid, align_corners=False)

torch.manual_seed(0)
vol = torch.randn(1, 32, 16, 64, 64, device="cuda")
grid = torch.rand(1, 16, 64, 64, 3, device="cuda") * 2 - 1
model = VolumetricWarp().eval().cuda()

torch.onnx.export(model, (vol, grid), "vol_warp.onnx",
                  input_names=["vol", "grid"], output_names=["y"],
                  opset_version=20, dynamo=True)

この ONNX の GridSample ノードを、プラグインの op 名 GridSample3D へ張り替えます。属性もプラグインが期待する形式（int 型 3 つ）に置き換えます。

import onnx
from onnx import helper

def swap_gridsample(src_onnx, dst_onnx):
    """ONNX の GridSample(5D) ノードをプラグイン op『GridSample3D』へ張り替える"""
    m = onnx.load(src_onnx, load_external_data=False)
    n = 0
    for node in m.graph.node:
        if node.op_type != "GridSample":
            continue
        ins, outs, name = list(node.input), list(node.output), node.name
        del node.attribute[:]
        node.op_type = "GridSample3D"
        node.domain = ""      # 非標準 op → parser が plugin registry を検索しにいく
        node.attribute.extend([
            helper.make_attribute("interpolation_mode", 0),   # 0 = linear
            helper.make_attribute("padding_mode", 0),         # 0 = zeros
            helper.make_attribute("align_corners", 0),        # 0 = False
        ])
        del node.input[:]
        node.input.extend(ins)
        del node.output[:]
        node.output.extend(outs)
        node.name = name
        n += 1
    onnx.save(m, dst_onnx)
    return n

なお、この swap_gridsample はグラフ内のすべての GridSample を無条件に置き換えます。本記事のダミーは「5D の GridSample が 1 個だけ」という前提なので、それを検査してから使います（4D と 5D が混在する実モデルで使う場合は、shape 推論で入力の次元数を確認するか、対象ノード名を指定できるようにしてください）。

count = swap_gridsample("vol_warp.onnx", "vol_warp_plugin.onnx")
if count != 1:
    raise RuntimeError(f"expected exactly one GridSample node, found {count}")

もうひとつ、プラグインのロードには重要な注意があります。本記事の構成では、プラグインの共有ライブラリを plan へシリアライズしていないため（TensorRT には version-compatible engine へプラグインを同梱する仕組みもありますが、今回は使っていません）、.so のロードはビルド時だけでなく、保存済みエンジンを別プロセスで deserialize する前にも必要です。共通のロード関数を作っておきます。

import ctypes
from pathlib import Path

_PLUGIN_HANDLES = []   # GC でアンロードされないよう、プロセス中は参照を保持する

def load_grid_sample_plugin(plugin_path):
    # プラグイン .so を RTLD_GLOBAL でロードする。ロードの副作用（ライブラリ内の
    # 登録処理）で、プラグインが TensorRT の plugin registry に登録される。
    # ビルド前と deserialize 前の両方で呼ぶこと
    handle = ctypes.CDLL(str(Path(plugin_path).resolve()), mode=ctypes.RTLD_GLOBAL)
    _PLUGIN_HANDLES.append(handle)

ビルド側はこうなります。GridSample3D を registry に登録しているのは上のロード処理で、init_libnvinfer_plugins は NVIDIA 標準プラグイン群の初期化 API です（今回のカスタムプラグインの登録主体ではありません）。

import tensorrt as trt

def build_engine_with_plugin(onnx_path, engine_path, fp16=False):
    load_grid_sample_plugin("./libgrid_sample_3d_plugin.so")
    trt.init_libnvinfer_plugins(TRT_LOGGER, "")   # NVIDIA 標準プラグインの初期化（念のため）

    builder = trt.Builder(TRT_LOGGER)
    network = builder.create_network(1 << int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH))
    parser = trt.OnnxParser(network, TRT_LOGGER)
    if not parser.parse_from_file(onnx_path):
        errs = [str(parser.get_error(i)) for i in range(parser.num_errors)]
        raise RuntimeError("ONNX parse failed:\n" + "\n".join(errs))
    config = builder.create_builder_config()
    config.set_memory_pool_limit(trt.MemoryPoolType.WORKSPACE, 2 << 30)
    if fp16:
        config.set_flag(trt.BuilderFlag.FP16)
    plan = builder.build_serialized_network(network, config)
    if plan is None:
        raise RuntimeError("build failed")
    with open(engine_path, "wb") as f:
        f.write(plan)
    return engine_path

関数を定義したら、張り替え済みの ONNX からエンジンを作ります。

build_engine_with_plugin("vol_warp_plugin.onnx", "vol_warp_plugin.plan", fp16=False)

実行側（保存済みエンジンを使うプロセス）では、deserialize の前にロードします。

load_grid_sample_plugin("./libgrid_sample_3d_plugin.so")
runner = TRTRunner("vol_warp_plugin.plan")   # deserialize はロードの後

そして——前編で拒否されたのと同じ計算グラフ（プラグインノードへの置き換えのみ）のビルドが通ります。実行して、PyTorch の F.grid_sample（5D）と突き合わせた結果がこちらです（照合の作法は前編・中編のとおり、export に使った同じモデル・同じ入力・fp32 基準です）。

計測条件: GeForce RTX 5060 Ti ／ 固定形状 [1,32,16,64,64]・batch=1 ／ 両者とも fp32 ／ ウォームアップ 30 回・計測 200 回・CUDA Event の median ／ TensorRT 側は入出力バッファを事前確保し enqueue 区間のみ ／ 1 回のビルドでの結果です。約 15% の差はモデルや GPU で容易に変わるので、「当環境のこの単体演算ではこうだった」として読んでください。

fp32 基準に対して非常に小さい誤差に収まりました。compute_90 の PTX を Blackwell のドライバが JIT した結果としてこの数値が出ている、というのが本記事の要点です。速度は単体ではわずかに速い程度ですが、本当の価値は「これまで PyTorch に残すしかなかった 5D grid_sample 入りのモジュールを、まるごと 1 個の TensorRT エンジンにできる」ことにあります。torch と TensorRT の境界そのものが消えるからです。

第4部: 中編の教訓をここでも — fp16 を受理する構成を検証する

さて、ここで終わると中編の教訓が泣きます。「ビルドが通っても、正しいとは限らない」 —— プラグインにも同じ検証を通します。

この OSS プラグインは fp16 カーネルも実装しており、supportsFormatCombination（TensorRT に「この精度・形式を受け入れるか」を答えるメソッド）は fp32 と fp16 の両方を受理する実装になっています。そこで、fp16 を受理する元実装のままの .so を別にビルドし、FP16 tactic を許可してエンジンを作って実測しました（プラグイン内部で実際に fp16 経路が選ばれたことのログ確認まではしていないため、正確には「fp16 を受理する構成のエンジン」の結果です）。

fp16 を受理する構成では、fp32 比で誤差が 5 桁悪化しました。nRMSE 2.1% は単一演算の fp16 丸め単位より大幅に大きく、少なくとも本用途では許容できない水準です（補間では座標の量子化・重み計算・積和などで誤差が増幅し得ますが、どの処理で増幅しているかまでは特定していません）。さらに私たちが実務モデルの内部で fp16 を受理する構成を使った際には、出力が数百のオーダーでずれる完全な数値破綻も経験しています（入力の分布次第で被害は大きく変わります。これも「乱数入力の結果を信用するな」の一例です）。

対処 — プラグイン側で fp16 を「受理しない」

対処はシンプルで、プラグインの supportsFormatCombination から fp16 の受理を外し、fp32 専用にすることです。

bool GridSample3DPlugin::supportsFormatCombination(int32_t pos,
                                                   PluginTensorDesc const* inOut,
                                                   int32_t nbInputs,
                                                   int32_t nbOutputs) noexcept {
    assert(nbInputs == 2 && nbOutputs == 1 && pos < (nbInputs + nbOutputs));
    bool condition = inOut[pos].format == TensorFormat::kLINEAR;
    // fp32-only: fp16 を受理する構成で許容できない誤差を観測したため kHALF を受理しない。
    // FP16 tactic を許可したエンジン内でも、TensorRT が本レイヤの前後に
    // reformat（型変換）を自動挿入し、この演算だけ fp32 で実行してくれる
    condition &= inOut[pos].type == DataType::kFLOAT;
    condition &= inOut[pos].type == inOut[0].type;
    return condition;
}

ここが面白いところで、こうしてもエンジン全体を fp32 にする必要はありません。FP16 tactic を許可してビルドすると、TensorRT はプラグインの申告を見て、このレイヤの前後にだけ型変換（reformat）を自動で挿入できます。結果として「grid_sample は fp32、周辺のレイヤは fp16 候補から選択」という構成が 1 個のエンジンの中で成立し得ます。ただし reformat のコストや、実際に選ばれた精度・エンジン全体の数値は、完成したエンジンで改めて検証してください（前編・中編で書いたとおり、「許可した」と「実際に使われた」は別物です）。

まだ確かめていないこと

• fp16 を受理する構成での誤差の根本原因 — プラグイン内部で実際に fp16 経路が選ばれたことのログ確認、および誤差がどの処理で増幅しているかの特定はしていません（本記事は「検証して、危なければ受理しない」という運用側の対処に留めています）
• JIT コンパイルの初回コスト — 初回ロード時の JIT 時間は計測していません。デプロイ形態によっては起動時間に効く可能性があります
• 新世代プラグイン API（V3 系）への移行 — 本記事は旧 API（IPluginV2DynamicExt）のまま動かしています。TensorRT の将来のメジャーバージョンでは旧 API が削除される可能性があります
• 可変形状（dynamic shape）での動作 — 本記事の検証はすべて固定形状です

まとめ — シリーズを締めて

後編の要点です。

1. TensorRT が知らない演算は、カスタムプラグイン + ONNX ノードの張り替えで通せる
2. pip の TensorRT にはヘッダが無い → OSS リポの対応タグから include を取り、lib は pip の .so へ symlink
3. nvcc が新しい GPU を知らなくても、PTX（仮想アーキテクチャ）でビルドして driver の JIT に任せる手がある（CUDA_ARCHITECTURES "90-virtual"）
4. プラグインにも中編の検証をそのまま適用する。許容できない誤差が出る型は supportsFormatCombination で受理対象から外す。TensorRT が reformat を自動挿入できるので、周辺は fp16 候補を残したまま該当演算だけ守れる（実際に選ばれた精度と数値は完成エンジンで確認する）

シリーズ 3 本を通して伝えたかったことを一言でまとめると、「TensorRT 化は『変換して速くなったら終わり』ではなく、export・ビルド・実行・数値のすべてを実測で確かめて初めて完成する」ということです。Blackwell という新しい世代はその検証の重要性を一段引き上げましたが、本シリーズの手順とチェックリストがそのまま皆さまの移行作業の地図になれば幸いです。

それでは、また次回、お会いしましょう！

参考資料（一次情報・主要ソース）

• SeanWangJS/grid-sample3d-trt-plugin（5D grid_sample プラグインの OSS 実装・Apache-2.0。使用コミット f964750）
• NVIDIA/TensorRT（OSS リポジトリ・公開ヘッダの取得元）
• NVIDIA TensorRT ドキュメント（プラグイン / Developer Guide）
• CUDA C++ Programming Guide: PTX と JIT コンパイル（forward compatibility）
• NVIDIA/TensorRT issue #3890: 5D GridSample のネイティブ対応要望
• 当社関連記事: 前編 / 中編 / 2026年 NVIDIA GPU 一発検索ツール

こんにちは！
Qualitegプロダクト開発部です！

本日はLuckfox Pico Mという4000円弱の小さなLinuxボードをインターネット越しに操作できるようにしてみました。NAT越えの仕組みは無料プランのWireCanalを使いました。

先日、秋葉原の千石電商さんでLuckfox Pico M を税込3,750円で入手しました。

Raspberry Pi Picoとほぼ同じ大きさで、ピンヘッダ実装済み、CPUはRockchip RV1103（ARM Cortex-A7 1.2GHz）、メモリは64MB、起動はmicroSDカードからです。

Linuxが動くのに、この値段とこの大きさです。

これを外出先（インターネット越しに）から使えるようにしていきます。

ボードにはRJ45のコネクタ（いわゆるLAN端子）もWi-Fiもなく、あるのはUSB-Cのポートだけ。

それでもインターネット側から届く形にして、スマホから叩いてみます。
さて、できるのでしょうか？

先に結果を言うと、できました。

ボード側にWeb公開用の受信ポートを追加せず、WireCanalの無料プラン（0円）だけで、公開URLからLuckfox上のWebサーバーがそのまま見えるところまで行けました。

さらに今回は、ボードに挿したLED 1本を、公開ページのボタンでインターネット越しに点けたり消したりできるようにしました。

再起動しても、実測33秒で公開URLが自動で復活します。

ただし、Pico M自身にはWi-FiもRJ45もないため、今回はUSB接続したWindows PCをインターネットへのゲートウェイとして使います。
（今後はイーサつきLuckFoxでの実験記事も投稿予定です！）

なので、今回は、外出先からアクセスするときも、このPCは起動している必要があります。

この記事では、SDカードへのイメージ書き込みから、起動、ネットワーク、LEDの配線、WireCanalでの公開、再起動しても復活する常駐設定まで、実際にやった手順と実測値を最初から最後まで書きます。

対象はLuckfox Pico M（無印Luckfox Picoのピンヘッダ実装版）と公式のBuildrootイメージ、作業PCはWindows 11です。WireCanalは当社が開発・運営している自社サービスで、記事中の数値は2026年8月19日時点の実測値です。

Luckfox Pico Mとはどんなボードか

LuckfoxはRockchipのビジョン向けSoC（RV1103／RV1106）を載せた小型Linuxボードのシリーズで、Pico Mはその入門機です。今回の実機で確認した中身は次のとおりでした。

Raspberry Piと違って、有線LANもWi-Fiも「そのままでは」使えません。

そこで今回は、PCとUSB-Cで繋いで仮想的なネットワークアダプタ（RNDIS）を生やして、PCとボードの間だけの小さなネットワークができるというしかけで使います。

MagJackとよばれるトランス入りのRJ45ジャック（いわゆるLAN端子）を自分で結線すればLANケーブルをつなぐことができますが少々手間がかかります。

また、そもそもRJ45ジャックつきのLuckFox製品もありますので直接LANケーブルでつなぎたい場合はそちらを使うこともできます（別記事として投稿予定です）

さて、今回はPCのインターネットをもらいにいく方法で実験しますので、外に出るにはPC側でひと工夫が要ります（手順3）。

もうひとつの特徴は、メモリの小ささです。

Linuxから見えるのは33MB。

ここにWireCanalの常駐エージェントを載せて実用になるのか、というのが今回の見どころのひとつです。

材料

WireCanalの無料プランは、canal（公開URLと転送先の組）が1本、公開アドレスはおまかせのランダムなサブドメインです。

作ったcanalはAgentを使っている限り消えず、Agentの最終接続から72時間で失効します。今回のように常駐で動かし続けるならURLは維持されます。

手順1: microSDカードにBuildrootイメージを書き込む

まず、必要なファイルとツールを集めます。入手先はすべて公式で、Luckfox Wikiの書き込み手順ページ（Flash Image）に、ツールとイメージへのリンクがまとまっています。ダウンロードするのは次の3つです。

OSイメージのzipを展開すると、次のファイルが出てきます。

env.img  idblock.img  uboot.img  boot.img  oem.img  userdata.img  rootfs.img
update.img  download.bin  sd_update.txt  tftp_update.txt

最初にSD Card Formatterでカードをフォーマットします。インストールして起動すると、カードのドライブが「カードの選択」に出るので、それが本当にSDカードか（容量・ドライブレター）を確認して、クイックフォーマットのまま「フォーマット」を押します。別のUSBドライブを挿している人は、ここの選び間違いにだけ注意してください。

次にSocToolKitです。zipを展開し、SocToolKit.exeを右クリックから「管理者として実行」で起動します（管理者で起動しないとSDカードを認識しないことがある、と公式手順にも書かれています）。最初にChip Selectionダイアログが出るので、RV1103を選んでOKを押します。

公式手順ではRV1106を選択するよう案内されていますが、今回は実機のSoCに合わせてRV1103を選択しました。この選択のまま、7つのイメージの書き込み完了（Create sdcard OK）からPico Mの実機起動まで確認しています。

「SDTool」タブに切り替えると、Usb Disk欄に挿したカード（今回は59.5G）が出ています。モードは「SD Boot」を選びます。

「Boot Files...」を押すとファイル選択ダイアログが開くので、さっき展開したフォルダから7つの.img（env.img・idblock.img・uboot.img・boot.img・oem.img・userdata.img・rootfs.img）をまとめて選びます。update.imgは含めません。読み込まれると一覧に7ファイルが並びます。

「Create SD」を押すと、書き込み先デバイスの最終確認ダイアログが出ます。デバイス名と容量をもう一度確認してYesを押すと書き込みが始まり、右側のログに各イメージの「Write disk from file (100%)...OK」が流れていきます。今回は1〜2分で「Create sdcard OK」まで到達しました。これで書き込みは完了です。

ここで面白いのは、同梱の sd_update.txt にSDカード上の配置がセクタ単位で書いてあることです。抜粋するとこうなっています。

#env.img 0x0:0x0 0x40:0x8000 0x40:0x8000
#idblock.img 0x40:0x8000 0x400:0x80000 0x170:0x2E000
#uboot.img 0x440:0x88000 0x400:0x80000 0x200:0x40000
#boot.img 0x840:0x108000 0x10000:0x2000000 0x1899:0x313200
#oem.img 0x10840:0x2108000 0x100000:0x20000000 0x17C78:0x2F8F000
#userdata.img 0x110840:0x22108000 0x80000:0x10000000 0x4C4A:0x989400
#rootfs.img 0x190840:0x32108000 0xC00000:0x180000000 0x4CD80:0x99B0000

各行は「名前 開始セクタ:開始バイト 領域サイズ 実体サイズ」です。つまりSocToolKitがやっているのは、Rockchip/Luckfox側で定められたこのオフセットへ各イメージをそのまま置くことです。

MBR/GPTのパーティションテーブルを自分で作る必要はありません。RockchipのブートROMはSDカードのセクタ64（0x8000バイト目）にある idblock.img を読みに来て起動が始まります（ブート時のパーティション構成はU-Boot環境側にも保持されています）。

Linux機で書きたい人は、この表のとおりに各イメージを所定オフセットへ直接書けば同じものが作れます。

ですので、実際にわたしもPythonつかって自分で各イメージを書き込んでみたところ、うまく起動しました。（このとき使ったスクリプトもリポジトリに sdwrite.py として置いてあります。既定は書き込みなしのdry-runで、--writeを付けたときだけ書き込みます）

ただ、その場合、書き込み先のディスクを間違えると別のドライブを消すので、そこだけは慎重にしましょう。

手順2: 起動して、SSHで入る

書き込んだmicroSDをPico Mに挿し、USB-CでPCに繋ぎます。これが給電になり、そのまま起動します。10秒ほどで、Windows側にネットワークアダプタ「Remote NDIS based Internet Sharing Device」が現れました。追加ドライバは不要でした（Windows 11標準のRNDISドライバで認識）。

ボード側のIPアドレスは 172.32.0.93 に固定されています。ちなみにLuckfox既定のこの 172.32.0.0/16 は、RFC 1918のプライベートアドレス範囲（172.16.0.0〜172.31.255.255）の外なので、同じ範囲への経路がある環境では競合に注意してください。

PC側のRNDISアダプタに、同じネットワークのIPアドレスを手で付けます。管理者権限のPowerShellで、アダプタのifIndexを確認してから設定します。

# RNDIS アダプタの ifIndex を確認（InterfaceDescription が Remote NDIS ... の行）
Get-NetAdapter | Where-Object InterfaceDescription -match 'NDIS'

# その ifIndex に固定 IP を付ける（例: ifIndex 41）。自動で付いた 169.254.x.x は先に外す
Remove-NetIPAddress -InterfaceIndex 41 -AddressFamily IPv4 -Confirm:$false -ErrorAction SilentlyContinue
New-NetIPAddress -InterfaceIndex 41 -IPAddress 172.32.0.100 -PrefixLength 16

これで ping 172.32.0.93 が返り、SSHで入れます。ユーザーは root、初期パスワードは luckfox です。

$ ssh root@172.32.0.93
# uname -a
Linux luckfox 5.10.160 #22 Wed Jun 11 18:43:57 CST 2025 armv7l GNU/Linux
# free -m
              total        used        free      shared  buff/cache   available
Mem:             33          10           4           0          19          20
# df -h | head -2
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 5.8G     79.1M      5.6G   1% /

メモリの合計が33MB。ここに公開の仕組みを載せていきます。

手順3: ボードをインターネットに出す（PC経由）

ここが、Raspberry Piにはなかった一手間です。（しかもあまり本質的ではない・・・）

Pico MはPCとしか繋がっていないので、PCをルーター役にしてボードのパケットを外へ出します。Windowsには WinNAT という仕組みがあり、管理者権限のPowerShellで作れます。まず既存のNATがないか確認してください。

# 既存の NAT を確認（何か表示されたら注意。下の注記を参照）
Get-NetNat

WinNATの利用は、Microsoftの公式手順ではHyper-Vが有効になっていることが前提です（本記事のPCはWindows 11 Proで、WSL 2でも使われるHyper-Vの仮想化基盤が有効な状態で実測しています）。

また、WinNATは1台のPCにつき内部NATのサブネットプレフィックスを1つしかサポートしません。DockerやHyper-Vの仮想ネットワークなどが既にNATを作っているPCでは、次のコマンドが通らないことがあります。その場合、既存のNATは他の仕組みが使っているので削除せず、構成への影響を確認してから進めてください。

確認できたら、NATを作ってフォワーディングを有効にします。

New-NetNat -Name LuckfoxNAT -InternalIPInterfaceAddressPrefix 172.32.0.0/16
Set-NetIPInterface -InterfaceIndex 41 -Forwarding Enabled

ボード側には、デフォルトゲートウェイ（PCのアドレス）とDNSを教えます。

ip route add default via 172.32.0.100 dev usb0
printf 'nameserver 1.1.1.1\nnameserver 8.8.8.8\n' > /etc/resolv.conf

これで ping 1.1.1.1 が通り、名前も引けます。ただ、HTTPSはまだ通りません。ここで踏んだのが次の2つでした。

ひとつめは、証明書のルート集（CAバンドル）がイメージに入っていないこと。TLSの相手を検証できないので、Pythonでもエージェントでも certificate verify failed になります。Git for Windowsに同梱されているMozillaのバンドルをそのまま置きました。

# 実機側: 置き場所を作る
mkdir -p /etc/ssl/certs

# Windows 側（PowerShell）: PC から実機へコピー（PuTTY 付属の pscp）
pscp -pw luckfox "C:\Program Files\Git\mingw64\etc\ssl\certs\ca-bundle.crt" root@172.32.0.93:/etc/ssl/certs/ca-certificates.crt

# 実機側: 権限と、python が既定で見に行くパスへのリンク
chmod 644 /etc/ssl/certs/ca-certificates.crt
ln -sf /etc/ssl/certs/ca-certificates.crt /etc/ssl/cert.pem

ふたつめは、時計です。起動直後の実機は1970年1月1日から始まっていて、この状態では証明書の有効期間の外なので、これもTLSが失敗します。ntpdは入っているのですが、経路ができる前に起動しているので、いったん手で合わせました。

# 現在の日時（UTC）に置き換えて実行してください
date -s '2026-08-18 08:45:51'

この2つを入れたところで、実機からHTTPSが通るようになりました。

# python3 -c 'import urllib.request;print(urllib.request.urlopen("https://download.wirecanal.com/latest/VERSION").read())'
b'0.18.3\n'

経路・DNS・時刻は再起動で消えるので、手順6の起動スクリプトにまとめて入れ直します。

配線: LEDを1本つなぐ

公開の前に、今回のデモの主役であるLEDをつないでおきます。使うのは物理ピン4（GPIO1_C7）と、その隣の物理ピン3（GND）です。

ピン配置は公式のGPIOドキュメントに図があります。

USB-Cコネクタを上にしてボードを見て、左の列の上から3番目がGND、4番目がGPIO1_C7です。

ブレッドボード上で

ピン4 → 抵抗（1KΩ）→ LEDアノード(長い足)＞LEDカソード(短い足)→ ピン3（GND）

とつないであります。

出力とGNDが隣同士のピンなので配線は最短で済みます。

なお、物理ピン1・2はデバッグ用のシリアルコンソール（UART2）に割り当てられているので、LED用途には使わないでおきます。

つないだら、SSHから点くかどうかを先に確かめておきます。LinuxのGPIOはsysfsからそのまま操作できます。

echo 55 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio55/direction
echo 1 > /sys/class/gpio/gpio55/value   # 点灯
echo 0 > /sys/class/gpio/gpio55/value   # 消灯

55という番号は「GPIO番号 = bank×32 ＋（groupをA=0〜D=3として）group×8 ＋ 番号」の式から来ています。

GPIO1_C7なら 1×32＋2×8＋7 = 55 です。echo 1 でブレッドボードのLEDが点けば、配線は合っています。

手順4: WireCanalでcanalを作る

ここからはRaspberry Pi 5の記事と同じ流れです。ダッシュボードの「新しい canal を作成」から、4ステップのウィザードで作ります。今回はアカウントを無料プランのままにして、そのままの条件で進めます。

転送先には localhost:18080 を入れます。Luckfoxの中でこれから立てるWebサーバーのポートです。

作成すると、canal詳細画面に接続ファイル（wirecanal.json）とセットアップ手順が出ます。Linuxタブの手順は「ワンライナーでAgentを入れる → wirecanal.jsonを置く → 起動する」の3つです。

手順5: AgentをLuckfoxに入れて、公開する

WireCanalのAgentは、CPUの種類ごとに1個の静的バイナリです。Luckfox Pico Mは32bit ARM（uname -m で armv7l）なので、wirecanal-linux-arm を使います。ワンライナーの install.sh は uname -m で自動判定して同じファイルを取りに行くのですが、今回のBuildrootイメージには curl が入っていません。なのでPC側でダウンロードして、実機へコピーしました。

# Windows 側（PowerShell）
curl.exe -fsSL https://download.wirecanal.com/latest/wirecanal-linux-arm -o wirecanal
pscp -pw luckfox wirecanal root@172.32.0.93:/root/wirecanal_demo/wirecanal
pscp -pw luckfox wirecanal.json root@172.32.0.93:/root/wirecanal_demo/wirecanal.json   # canal 詳細からダウンロードした接続ファイル

実機側で実行権限を付けて、バージョンを確認します。

# cd /root/wirecanal_demo && chmod +x wirecanal && chmod 600 wirecanal.json
# ./wirecanal --version
wirecanal v.0.18.3 powered by Qualiteg Inc. https://qualiteg.com

公開する中身は、ブラウザからLEDを点け消しできる小さなWebサーバーにしました。ONボタンを押すと、さっき配線したLEDが実際に光り、OFFで消えます。押されている側のボタンに色が付くので、いまどちらの状態かも画面で分かります。イメージにpython3が入っているので、標準ライブラリだけで書いています。127.0.0.1の18080番で待ち、GET /led で現在の状態を返し、POST /led/on・/led/off で切り替えます。LEDの操作は、配線の節で試したのと同じ /sys/class/gpio への書き込みです。

今回のコード一式（demo_server.py・S99wirecanal・settime.py・補足の sdwrite.py）は、GitHubの qualiteg/luckfox-pico-wirecanal-demo（記事執筆時点のコミット） に置いてあります。git cloneしてそのまま使えます。

demo_server.py（実機に置いたもの・全文）

# LED control page for the Luckfox Pico M
# Served on 127.0.0.1:18080 and published to the internet through a WireCanal tunnel.
# The ON/OFF buttons drive GPIO1_C7 (sysfs number 55, physical pin 4) where an LED is wired.
import http.server, subprocess, socket, html, os

GPIO = "55"
GPIO_DIR = "/sys/class/gpio/gpio" + GPIO

def gpio_init():
    if not os.path.isdir(GPIO_DIR):
        with open("/sys/class/gpio/export", "w") as f:
            f.write(GPIO)
    with open(GPIO_DIR + "/direction", "w") as f:
        f.write("out")

def gpio_set(v):
    with open(GPIO_DIR + "/value", "w") as f:
        f.write("1" if v else "0")

def gpio_get():
    with open(GPIO_DIR + "/value") as f:
        return f.read().strip() == "1"

def sh(c):
    try: return subprocess.run(c, shell=True, capture_output=True, text=True, timeout=5).stdout.strip()
    except Exception as e: return str(e)

PAGE = """<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width,initial-scale=1">
<title>Luckfox Pico M LED control</title>
<style>body{font-family:system-ui,-apple-system,Segoe UI,Roboto,sans-serif;margin:0;background:#f7fafd;color:#15222b}
.wrap{max-width:720px;margin:40px auto;padding:0 20px}.card{background:#fff;border:1px solid #dde5ee;border-radius:16px;padding:28px 32px;box-shadow:0 2px 12px rgba(0,0,0,.05)}
h1{font-size:1.5rem;margin:0 0 6px}.sub{color:#5f6b78;margin:0 0 20px}table{border-collapse:collapse;width:100%%}td{padding:8px 6px;border-bottom:1px solid #eef2f6;vertical-align:top}
td:first-child{color:#5f6b78;width:150px}code{background:#f1f5f9;padding:2px 6px;border-radius:6px}
.led{display:flex;align-items:center;gap:16px;margin:18px 0 22px}
.dot{width:26px;height:26px;border-radius:50%%;background:#cfd8e3;transition:all .15s}
.dot.on{background:#e5484d;box-shadow:0 0 14px 3px rgba(229,72,77,.55)}
button{font-size:1rem;font-weight:600;border-radius:10px;border:1px solid #cdd7e1;background:#fff;color:#15222b;padding:10px 26px;cursor:pointer;transition:all .15s}
button.active{background:#1f7ae0;border-color:#1f7ae0;color:#fff}
#btnOn.active{background:#e5484d;border-color:#e5484d}
.state{font-weight:700;min-width:44px}
.foot{color:#8b96a4;font-size:.85rem;margin-top:16px}</style></head><body><div class="wrap"><div class="card">
<h1>Luckfox Pico M &mdash; LED control</h1>
<p class="sub">The buttons below drive a real LED wired to GPIO1_C7 (physical pin 4) on the board, through a WireCanal tunnel. No inbound port is exposed directly to the internet.</p>
<div class="led"><div id="dot" class="dot"></div><span id="state" class="state">...</span>
<button id="btnOn" onclick="setLed(1)">ON</button><button id="btnOff" onclick="setLed(0)">OFF</button></div>
<table>
<tr><td>Board</td><td>Luckfox Pico M (Rockchip RV1103, ARM Cortex-A7, 64 MB DDR2)</td></tr>
<tr><td>Hostname</td><td><code>%(host)s</code></td></tr>
<tr><td>Kernel</td><td><code>%(uname)s</code></td></tr>
<tr><td>Uptime</td><td>%(uptime)s</td></tr>
<tr><td>LED pin</td><td><code>GPIO1_C7</code> = sysfs gpio%(gpio)s, physical pin 4 (GND on pin 3)</td></tr>
</table>
<p class="foot">Agent: WireCanal (linux/arm) &middot; Powered by Qualiteg</p>
</div></div>
<script>
async function refresh(){const r=await fetch('/led');const j=await r.json();
document.getElementById('dot').className='dot'+(j.on?' on':'');
document.getElementById('state').textContent=j.on?'ON':'OFF';
document.getElementById('btnOn').className=j.on?'active':'';
document.getElementById('btnOff').className=j.on?'':'active';}
async function setLed(v){await fetch('/led/'+(v?'on':'off'),{method:'POST'});refresh();}
refresh();setInterval(refresh,3000);
</script></body></html>"""

class H(http.server.BaseHTTPRequestHandler):
    def _send(self, code, body, ctype="text/html; charset=utf-8"):
        data = body.encode("utf-8")
        self.send_response(code)
        self.send_header("Content-Type", ctype)
        self.send_header("Content-Length", str(len(data)))
        self.end_headers()
        self.wfile.write(data)
    def do_GET(self):
        if self.path == "/led":
            return self._send(200, '{"on": %s}' % ("true" if gpio_get() else "false"), "application/json")
        body = PAGE % {
            "host": html.escape(socket.gethostname()),
            "uname": html.escape(sh("uname -srm")),
            "uptime": html.escape(sh("uptime")),
            "gpio": GPIO,
        }
        self._send(200, body)
    def do_POST(self):
        if self.path == "/led/on":
            gpio_set(True)
        elif self.path == "/led/off":
            gpio_set(False)
        else:
            return self._send(404, '{"error":"not found"}', "application/json")
        self._send(200, '{"on": %s}' % ("true" if gpio_get() else "false"), "application/json")
    def log_message(self, *a): pass

gpio_init()
http.server.HTTPServer(("127.0.0.1", 18080), H).serve_forever()

ひとつだけ注意点があります。今回のBuildroot環境では python3 -m http.server をそのまま起動するとIPv6側のソケットを開こうとして Address family not supported で落ちました（このイメージのカーネルにはIPv6がありません）。上のコードのように 127.0.0.1 を明示して待ち受ければ問題ありません。

Webサーバーを裏で起動し、続けてAgentを起動します。

cd /root/wirecanal_demo
(setsid nohup python3 demo_server.py >/dev/null 2>&1 &)
./wirecanal -config wirecanal.json

wirecanal v.0.18.3 powered by Qualiteg Inc. https://qualiteg.com
wirecanal: warning: mode=http かつ http ルール未設定のため、全パスを転送先へ通します。特定のパス・メソッドに絞る場合は http.default: deny ＋ http.rules を設定してください
wirecanal: 自動更新が有効です（無効化は wirecanal.json に "auto_update": false）
wirecanal: canal urym: https://fxsu8b0c.ja000.wirecanal.com へのアクセスをローカルの転送先 localhost:18080 に届けます
wirecanal: 設定は https://app.wirecanal.com/canals/urym をご確認ください
wirecanal 0.18.3: connecting tenant=urym mode=http forward_target=localhost:18080

この時点で、ダッシュボードの接続状態が「● 接続中」に変わります。

インターネット側から見てみる

公開URLをブラウザで開きます。

「Linux 5.10.160 armv7l」というカーネルも稼働時間も、さっきSSHで見た実機の生きた値がそのままインターネット越しに出ています。そしてONボタンを押すと、手元のブレッドボードの上でLEDが実際に光ります。ブラウザは公開URLを叩いているだけで、その先で実物が動く。スマホでも同じURLをそのまま開けます。

curlでの実測はこうでした。ページを経由せず、APIを直接叩いてLEDを操作することもできます。

$ curl -s -o /dev/null -w "HTTP %{http_code} / %{time_total}s" https://fxsu8b0c.ja000.wirecanal.com/
HTTP 200 / 0.232s
$ curl -s -X POST https://fxsu8b0c.ja000.wirecanal.com/led/on
{"on": true}
$ curl -s -X POST https://fxsu8b0c.ja000.wirecanal.com/led/off
{"on": false}

このときインターネット側からPico Mへ直接到達できる受信ポートは、ひとつもありません。18080番は 127.0.0.1 だけで待っていて、PCのNATにも受信（ポートフォワード）の設定は何も入れていません。公開は、Agentの外向き接続だけで成立しています。SSH（22番）はRNDIS側で待受していますが、これはPCとボードの間だけの閉じたネットワークで、インターネット側からは届きません。

なお、今回は認証を付けていないため、URLを知っている人はページの閲覧もLEDのON/OFF操作もできます。今回は抵抗を介したLED 1本だけのデモなのでそのまま公開していますが、リレー・モーター・鍵・電源制御など実物に影響するGPIOを公開する場合は、canalのアクセス保護（IP制限・認証）やHTTPルールで、操作できる相手・パス・メソッドを必ず絞ってください。

手順6: 常駐させて、電源を抜いても戻ってくるようにする

手順5の起動はターミナルを閉じると止まりますし、経路・DNS・時刻は再起動で消えます。Raspberry Pi OSならsystemdの雛形を置くだけでしたが、Buildrootのinitはbusyboxの /etc/init.d/S??name 方式なので、起動スクリプトを1本書きます。

その前に、スワップを用意しておきます。Linuxから見えるメモリが33MBで、Agentは自動更新のための常駐ウォッチドッグ（wirecanal-safeguard）と組で動くので、そのぶんの余裕を持たせるためです。SDカード上に128MBのファイルを切って有効にしました。

dd if=/dev/zero of=/swapfile bs=1M count=128
chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile

起動スクリプトは次のとおりです。やっていることは、スワップを有効化し、USB側のネットワーク（usb0）にアドレスが付くのを待ち、経路とDNSを入れ、ntpを起動し直して時計が合うのを待ってから、Webサーバーとエージェントを起動する、という順番です。エージェントは終了したら5秒後に立ち上げ直すループにしています。systemdの Restart=always の代わりです。監視ループのPIDをファイルに控えて、二重起動の防止と、stop で監視ループごと全部止まるようにしてあります（監視ループを残したままエージェントだけkillすると、5秒後に勝手に復活してしまいます）。

/etc/init.d/S99wirecanal（実機に置いたもの・全文）

#!/bin/sh
# WireCanal Agent (Luckfox Pico M / Buildroot busybox init)
WD=/root/wirecanal_demo
SUPERVISOR_PID=/var/run/wirecanal-supervisor.pid
case "$1" in
  start)
    # 二重起動防止（前回の監視ループが生きていれば何もしない）
    if [ -f "$SUPERVISOR_PID" ] && kill -0 "$(cat $SUPERVISOR_PID)" 2>/dev/null; then
      echo "wirecanal supervisor already running (pid $(cat $SUPERVISOR_PID))"
      exit 0
    fi
    (
      [ -f /swapfile ] && swapon /swapfile 2>/dev/null
      i=0; while ! ip -4 addr show usb0 2>/dev/null | grep -q inet && [ $i -lt 60 ]; do sleep 2; i=$((i+1)); done
      ip route | grep -q '^default' || ip route add default via 172.32.0.100 dev usb0
      grep -q nameserver /etc/resolv.conf 2>/dev/null || printf 'nameserver 1.1.1.1\nnameserver 8.8.8.8\n' > /etc/resolv.conf
      /etc/init.d/S49ntp restart >/dev/null 2>&1
      i=0; while [ "$(date +%Y)" -lt 2025 ] && [ $i -lt 20 ]; do sleep 3; i=$((i+1)); done
      [ "$(date +%Y)" -lt 2025 ] && python3 $WD/settime.py >/dev/null 2>&1
      cd $WD && (setsid nohup python3 demo_server.py >/dev/null 2>&1 &)
      # Agent が終了したら 5 秒後に立ち上げ直す（systemd の Restart=always の代わり）
      cd $WD && while true; do ./wirecanal -config wirecanal.json >> agent.log 2>&1; sleep 5; done
    ) >/dev/null 2>&1 &
    echo $! > $SUPERVISOR_PID
    ;;
  stop)
    # 監視ループ → Agent/ウォッチドッグ → Web サーバーの順にすべて止める
    if [ -f "$SUPERVISOR_PID" ]; then
      kill "$(cat $SUPERVISOR_PID)" 2>/dev/null
      rm -f $SUPERVISOR_PID
    fi
    for p in $(ps | grep -E '[w]irecanal -config|[w]irecanal-safeguard|[d]emo_server' | awk '{print $1}'); do
      kill "$p" 2>/dev/null
    done
    ;;
  restart) "$0" stop; sleep 1; "$0" start ;;
esac
exit 0

途中で呼んでいる settime.py は、ntpが間に合わなかったときの保険で、HTTPの応答ヘッダにある日付で時計を合わせるだけの数行のスクリプトです。これはTLSを使える時刻まで戻すためのデモ用フォールバックで、通常の時刻同期はNTPに任せます。

settime.py（全文）

import urllib.request, urllib.error, email.utils, subprocess
try:
    r = urllib.request.urlopen('http://download.wirecanal.com/', timeout=10)
except urllib.error.HTTPError as e:
    r = e
t = email.utils.parsedate_to_datetime(r.headers.get('Date'))
subprocess.run(['date', '-u', '-s', t.strftime('%Y-%m-%d %H:%M:%S')])

ここで一度ハマった話を書いておきます。busyboxの ip route show default は「default」の指定を無視して全経路を返します。最初はこれで「経路がある」と誤判定して、再起動後に外へ出られませんでした。上のスクリプトのように ip route | grep '^default' で見るのが確実です。もうひとつはPIDの控え方で、サブシェルの中で $$ を書くと、BusyBoxのshでは親のPIDが記録されてしまい、二重起動ガードが効きません。上のスクリプトのように、サブシェルをバックグラウンドにした直後に親側で $! を書き出すのが確実です（これも実測で気づきました）。

実行権限を付けて sync したら、いよいよ再起動です。

chmod +x /etc/init.d/S99wirecanal && sync && reboot

再起動しても、公開は自動で復活するか

再起動をかけた瞬間から時間を測り、公開URLが200を返すまでを実測しました。

# uptime
 10:31:08 up 0 min,  load average: 5.00, 1.25, 0.41
# free -m
              total        used        free      shared  buff/cache   available
Mem:             33          17           1           0          14          13
Swap:           128           9         119
# ps | grep -E 'wirecanal|demo_server'
  793 root     python3 demo_server.py
  794 root     ./wirecanal -config wirecanal.json
  808 root     /root/wirecanal_demo/wirecanal-safeguard -config wirecanal.json -exec /root/wirecanal_demo/wirecanal -state-dir .wirecanal-state

復帰直後に公開URLを開くと、ページの稼働時間が「up 0 min」でした。再起動したばかりの実物が、そのままインターネット側から見えている証拠です。USB-Cを物理的に抜き差ししたときも同じで、挿し直すだけで何もせずに公開URLが復活しました。

3,750円のボードでも、外から届くサーバーになった

Luckfox Pico Mは、Linuxから見えるメモリが33MB、有線もWi-Fiもない、USB-Cが1本だけのボードです。それでも、SDカードへの書き込みからインターネット側で公開URLが返るまで、必要だったのは、この記事に書いた手順だけでした。Web公開のための受信ポートは最後まで追加していませんし、WireCanalは無料プランのままです。

Raspberry Pi 5のときと違ったのは、ネットワークをPC経由にする一手間と、Buildrootならではの下ごしらえ（CAバンドル・時刻・busybox init）です。逆に言うと、そこさえ越えれば、Agentのやること自体は同じでした。wirecanal-linux-arm のバイナリを置いて、wirecanal.jsonを隣に置いて、起動する。それだけです。

今回はLED 1本でしたが、この小さなボードには、これからセンサーやカメラを載せて、外出先から見られるものを増やしていきたいとおもいます！

それでは、また次回お会いしましょう！

出典・参考

• Luckfox Wiki（Luckfox Pico RV1103 シリーズの公式ドキュメント・イメージ配布・SDカード書き込み手順）
• サンプルコード一式（GitHub: qualiteg/luckfox-pico-wirecanal-demo・記事執筆時点のコミット）
• WireCanal IoTデバイス対応ページ（対応チップ＋Linuxの組み合わせと、対応チップを搭載したデバイスの例）
• WireCanal Linuxセットアップガイド（Agentの配布ファイル名と常駐手順）
• Luckfox Wiki: Flash Image（SDカード書き込みの公式手順。SocToolKitとOSイメージの配布リンクもこのページ）
• Luckfox Wiki: GPIO（ピン配置図と /sys/class/gpio でのGPIO操作）
• SD Card Formatter（SDアソシエーション公式のフォーマットツール）
• New-NetNat（Microsoft Learn・WinNAT のコマンドリファレンス）

関連記事

• Raspberry Pi 5のWebサーバーをインターネットに公開する。ポートは開けない、WireCanalのトンネルで
• Raspberry Pi 5をモニターなしでセットアップする。Windows PCだけでOS書き込みからSSH接続まで
• Raspberry Pi 5を堅牢化する。SSH鍵認証・UFW・fail2banと、再起動でIPv6が復活する罠
• 自宅PCのローカルLLMを外出先のスマホから使う。Ollama＋Open WebUI+WireCanal

こんにちは！Qualitegプロダクト開発部です！

Raspberry Pi 5の連載も3回目です。

第1話でモニターなしのセットアップ、第2話で堅牢化をやりました。第2話ではUFWで受信を原則拒否し、自宅LANからのSSHだけを明示的に許可しました。

ラズパイの上ではWebサーバーが動いているのに、外からはもちろん、LAN内からすら8080には繋がらない状態です。

今回はこのラズパイのWebサーバーを、インターネット側から使えるようにします。ただし、

Web公開のために受信ポートを追加で開くことはしません。ルーターのポート開放もしません。使うのは、当社のトンネルサービスWireCanalです.今回の用途なら無料です。

先に結果を言うと、Agentのインストールから公開URLで表示できるところまで実測およそ5分、systemdでの常駐化まで含めて約10分でした。

この記事では、その手順を実際の画面と実測値つきで最初から最後まで書きます。再起動しても公開が自動で復活するところまで検収します。

対象はRaspberry Pi OS（64-bit・Debian 13 trixieベース）です。WireCanalは当社が開発・運営している自社サービスで、クレジットカード登録なしのフリープラン（0円）から使えます。記事中の数値は2026年8月14日時点の実測値です。

ポートを開けずに、どうやって公開するのか

普通、自宅のサーバーを公開しようとすると、ルーターのポート開放（ポートフォワーディング）が要ります。ただ、これは外からの入口を自宅に作る行為なので、第2話でせっかく受信を固めたのに、今度はルーターに穴を開けるのかという話になります。さらに、グローバルIPが変動する環境で同じ名前から継続的にアクセスしたいなら、DDNSなどの仕組みも必要になります。集合住宅の回線だと、そもそもポート開放ができないこともあります。

トンネル方式は逆向きです。ラズパイの中のAgentが、WireCanalの中継サーバーへ外向きに接続します。外からのアクセスは中継サーバーが受け、その確立済みの接続を通ってラズパイに届きます。自宅側に入口を作らないので、ポート開放もルーター設定も要りません。UFWの「受信は原則拒否」もそのままです。

第2話の「受信を原則拒否する」と今回の「Web公開用の受信ポートを追加しない」は、この仕組みで両立します。

材料

ラズパイ側は前回までの状態そのままです。状態表示の小さなWebサーバー（Python標準ライブラリ製・ポート8080）がsystemdで常駐しています。

WireCanal側はアカウントだけ用意してください。フリープラン（0円・カード登録不要）で今回の手順はすべて試せます。なお、フリーは転送量が月10GB目安で、超過後は減速する場合があります。もうひとつ、フリープランのおまかせサブドメインは、Agentを使っている限り有効ですが、Agentの最終接続から72時間で失効します。長期間止めても同じURLを維持したい場合は、永続URLのあるライト以上が対象です。今回のように常駐で動かし続けるなら、フリーでもURLは維持されます。

手順1: ラズパイにAgentをインストールする

SSHでラズパイに入り、置きたいディレクトリでワンライナーを実行します。

mkdir -p ~/wirecanal && cd ~/wirecanal
curl -fsSL https://download.wirecanal.com/install.sh | sh

実行結果がこれです。CPUアーキテクチャ（ラズパイ5はarm64）は自動判定されます。

WireCanal Agent v.0.18.1 をダウンロードしています...
wirecanal v.0.18.1 powered by Qualiteg Inc. https://qualiteg.com

インストール完了: /home/pi/wirecanal/wirecanal
次の手順:
  1. ダッシュボード（https://app.wirecanal.com）の canal 詳細から wirecanal.json を
     ダウンロードして、wirecanal と同じフォルダに置く
  2. 起動: ./wirecanal -config wirecanal.json

バージョン表示まで自動で確認されて終わります。Agentは単一バイナリで、これ以外に入れるものはありません。

手順2: canalを作る（4ステップのウィザード）

WireCanalでは、公開URLと転送先の組をcanalと呼びます。ダッシュボードの「新しい canal を作成」から、ウィザードで作ります。種類は「HTTP」を選びます。Webサーバーを HTTPS で公開するモードです。

公開アドレスは「おまかせサブドメイン」にしました。ランダムな名前で今すぐ発行され、全プランで使えます。次の設定画面で、転送先に localhost:8080 を入れます。ラズパイの中でWebサーバーが待っているポートです。メモは任意ですが、あとで一覧を見たときに分かるように書いておくのがおすすめです。

確認画面で「作成する」を押すと、公開URLと接続キー（access_key）が発行されます。今回発行されたのは https://5m0kjyxw.ja100.wirecanal.com でした。

手順3: wirecanal.jsonを置いて起動する

canal詳細画面に、接続ファイル（wirecanal.json）が表示されます。ダウンロードして、ラズパイのAgentと同じフォルダに置きます。画面にはセットアップ手順もLinux用のタブでそのまま出ています。

この連載はWindowsからのヘッドレス操作なので、ダウンロードしたファイルはscpでラズパイへ送ります（第2話で仕込んだSSH鍵がそのまま使えます）。

# Windows側（PowerShell）
scp "$env:USERPROFILE\Downloads\wirecanal.json" pi@192.168.12.17:/home/pi/wirecanal/

wirecanal.jsonにはcanal専用の接続キー（access_key）が入っています。ラズパイ側で権限を絞ってから起動します。

cd ~/wirecanal
chmod 600 wirecanal.json
./wirecanal -config wirecanal.json

wirecanal v.0.18.1 powered by Qualiteg Inc. https://qualiteg.com
wirecanal: canal t5zd: https://5m0kjyxw.ja100.wirecanal.com へのアクセスをローカルの転送先 localhost:8080 に届けます
wirecanal 0.18.1: connecting tenant=t5zd mode=http forward_target=localhost:8080

この時点でダッシュボードの接続状態が「● 接続中」に変わり、トンネルが開通しています。

手順4: systemdで常駐させる

手順3の起動は、ターミナルを閉じると止まります。サーバーとして使うので、Webサーバーと同じくsystemdで常駐させます。Linuxセットアップガイドの常駐手順の雛形どおり、/opt/wirecanal に置いて専用ユーザーで動かします。

sudo mkdir -p /opt/wirecanal
sudo cp ~/wirecanal/wirecanal ~/wirecanal/wirecanal.json /opt/wirecanal/

sudo tee /etc/systemd/system/wirecanal.service > /dev/null <<'EOF'
[Unit]
Description=WireCanal Agent
After=network-online.target
Wants=network-online.target

[Service]
User=wirecanal
WorkingDirectory=/opt/wirecanal
ExecStart=/opt/wirecanal/wirecanal -config /opt/wirecanal/wirecanal.json
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target
EOF

sudo useradd --system --home /opt/wirecanal --shell /usr/sbin/nologin wirecanal
sudo chown -R wirecanal: /opt/wirecanal
sudo chmod 600 /opt/wirecanal/wirecanal.json
sudo systemctl daemon-reload
sudo systemctl enable --now wirecanal
systemctl status wirecanal --no-pager

Restart=always なので、Agentのプロセスが終了した場合は5秒後に自動で再起動します（systemctl stop のような明示的な停止は除きます）。ログは journalctl -u wirecanal -f で追えます。

インターネット側から見てみる

公開URLをブラウザで開きます。

ラズパイの状態表示ページが、そのまま出ました。CPU温度も稼働時間も生きた値です。curlでの実測はこうでした。

$ curl -s -o /dev/null -w "HTTP %{http_code} / %{time_total}s" https://5m0kjyxw.ja100.wirecanal.com/
HTTP 200 / 0.18s

このときラズパイ側の受信ポートは、第2話のUFW設定（受信は原則拒否・SSHのみLAN限定許可）のままです。8080は外からもLANからも閉じたままで、公開はAgentの外向き接続だけで成立しています。

なお、URLを知っている人は誰でも見られる状態なので、見せたい相手を絞る場合はcanalのアクセス保護（IP制限・認証など）を設定してください。今回は無害な状態表示ページなので、そのまま公開しています。

再起動しても、公開は自動で復活するか

第2話で「設定を入れて確認しただけでは、永続性は保証されない」という教訓を得ました。今回も実際に再起動して検収します。

面白かったのは、再起動直後に公開URLへアクセスしたら、ページの稼働時間表示が「0時間0分」だったことです。再起動したばかりの実物が、そのままインターネット側から見えている証拠になりました。

まとめ

3話かけて、ヘッドレスセットアップから堅牢化、そしてWeb公開まで到達しました。ラズパイは、Web公開用の受信ポートを1つも開けないまま、インターネット側から使えるサーバーになりました！

インターネットから使えるということはスマホからも使えますし、ラズパイですので、スマホで外出先から、家庭内機器を操作したり。もちろんＬＥＤチカチカさせたり、カメラをつけて、みたり、とできることは無限大ではないでしょうか。

ということで、このラズパイはこれから、家の中の小さな常設サーバーとして育てていきます。

載せるものが増えたら、また記事にしたいとおもいます。

それでは、また次回お楽しみに！

出典・参考

• WireCanal 公式サイト
• WireCanal Linuxセットアップガイド（常駐手順の雛形はここ）
• Raspberry Pi Documentation（公式ドキュメント）

関連記事

• Raspberry Pi 5をモニターなしでセットアップする。Windows PCだけでOS書き込みからSSH接続まで（第1話）
• Raspberry Pi 5を堅牢化する。SSH鍵認証・UFW・fail2banと、再起動でIPv6が復活する罠（第2話）
• 自宅PCのローカルLLMを外出先のスマホから使う。Ollama＋Open WebUI+WireCanal
• ngrokとWireCanalは何が違う？開発元が料金・運用・MCP設計を比較

こんにちは！
Qualitegプロダクト開発部です！

前回の記事で、モニターなしのRaspberry Pi 5をWindows PCだけでセットアップし、SDカード挿入から約3分でSSH接続まで到達しました。

このラズパイ、ゆくゆくは小さなWebサーバーを載せてインターネット側から使えるようにする予定です。

ただ、その前にやることがあります。

セットアップ直後のRaspberry Pi OSは、実測してみると思った以上に無防備

でした。

前回の検証用セットアップで設定した簡易なパスワードでパスワード認証が有効なまま、ファイアウォールなし、更新可能なパッケージが172件たまり、そして意図していないのにIPv6のグローバルアドレスまで付いていました。

この記事では、

SSHの鍵認証化・UFW・fail2ban・更新の自動適用・IPv6無効化までを実コマンドでやり切り、実際に再起動して設定が生き残ることまで検収します

先にことわっておくと、この検収で1回つまずきました。

sysctlで無効化したはずのIPv6が、再起動したら復活していたのです。

原因はNetworkManagerの接続プロファイルでした。

この顛末は後半で詳しく書きます。

この記事の対象はRaspberry Pi OS（64-bit・Debian 13 trixieベース）です。

作業はすべてWindows PCからSSH越しに行い、ラズパイにモニターは最後まで繋ぎません。記事中の数値は2026年8月14日時点の実測値です。

初期状態を実測したら、ここまで無防備だった

手を入れる前に、まず現状を実測しました。「たぶん危ない」ではなく、どこがどう開いているかを確かめてから塞ぎます。

IPv6は意外に思うかもしれません。LAN内運用のつもりでも、ルーター広告（RA）を受けて 2409: で始まるグローバルIPv6アドレスが自動で付いていました。

IPv6のグローバルアドレスはNATを前提としないため、IPv4とは露出の考え方が異なります。

本記事ではIPv6を運用対象にしない方針なので、使わない経路を残さないために明示的に無効化します。

方針。ポートは開けない、公開はトンネルで

堅牢化の方針はこう決めました。

SSHは鍵認証のみにして、接続元も自宅LANに限定します。それ以外の受信ポートは、Webサーバー用の8080を含めて一切開けません。

「外から使えるようにしたいのにポートを開けない」のは矛盾に見えますが、公開は次回、WireCanalのトンネル経由で行います。トンネル方式ならラズパイ側は外向きの接続だけで済むので、受信ポートを開ける必要も、ルーターのポート開放も要りません。

つまり今回の堅牢化は「全部閉じる」、
次回の公開は「閉じたまま外に出す」という分担です。

手順1: SSH鍵を仕込む（締め出さない順序がすべて）

最初に鍵を仕込みます。ここで鉄則がひとつあります。鍵ログインの成功を実測してから、パスワード認証を止める。順序を誤ると、自分がSSHで入れなくなります。モニターなし運用のラズパイでは、ヘッドレスのままの復旧がかなり面倒になるので、この順序だけは崩せません。

SSH鍵をまだ持っていない場合は、先にWindows側で ssh-keygen -t ed25519 を実行して作っておきます。

途中で訊かれるパスフレーズは設定しておくのがおすすめです（鍵ファイルが漏れたときの保険になります）。公開鍵は %USERPROFILE%\.ssh\id_ed25519.pub にできます。

まず、ラズパイ側に公開鍵を置きます。

# ラズパイ側（piユーザーで実行）
D=/home/pi/.ssh
mkdir -p "$D"; chmod 700 "$D"
cat > "$D/authorized_keys" <<'EOF'
ssh-ed25519 AAAA...（あなたの公開鍵）
EOF
chmod 600 "$D/authorized_keys"; chown -R pi:pi "$D"

なお、cat > は既存の authorized_keys を丸ごと上書きします。今回は新規構築直後なのでこの書き方にしていますが、既に鍵を登録してある環境では追記（>>）にしてください。

GitHubを使っている方は、https://github.com/<アカウント名>.keys で自分の公開鍵一覧を取得できるので、そこからコピーするのが手早いです。

置いたら、Windows側から鍵だけでログインできることを確認します。

ssh -o PasswordAuthentication=no pi@192.168.12.17

これが通ってから次へ進みます。

手順2: パスワード変更・IPv6無効化・SSHを鍵のみにする

ここからはroot権限での作業です（sudo -i で入るか、各コマンドに sudo を付けてください）。まずパスワードの変更です。前回の検証用の簡易なパスワードから、きちんとしたものに変えます。鍵のみ化した後もsudoでパスワードは使うので、ここで整えておきます。

passwd pi

次に、OS側でIPv6を無効化します。

cat > /etc/sysctl.d/99-disable-ipv6.conf <<'EOF'
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
EOF
sysctl --system

そしてSSHを固めます。設定は本体ファイルを書き換えず、drop-inで追加します。

cat > /etc/ssh/sshd_config.d/00-hardening.conf <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AddressFamily inet
EOF
sshd -t && systemctl restart ssh

AddressFamily inet はIPv4のみで待ち受ける指定です。UbuntuだとsshdがソケットActivation（ssh.socket）経由のことがあり、socket側にもdrop-inが要るのですが、今回の実機では ssh は service 直起動（ssh.socket は disabled）だったので、sshd_config の指定だけで [::]:22 が消えました（実測）。

ここで一度、別のターミナルからパスワード認証を試しておきます。拒否されれば成功です。既存の鍵ログインが生きていることも忘れずに確認します。

手順3: 保留172件の更新と、fail2ban・自動更新

export DEBIAN_FRONTEND=noninteractive
apt-get update -q
apt-get -y -q full-upgrade          # 保留172件を全適用
apt-get -y -q install ufw fail2ban unattended-upgrades

fail2banはSSHへの試行失敗を数えて自動でBANしてくれる番人です。ひとつ押さえておきたいのは、今回のRaspberry Pi OS trixie実機にはrsyslogが入っておらず /var/log/auth.log も存在しないことです。

sshdのログはjournaldから読むことになります。Debianのfail2banパッケージにはsshd向けにjournaldを見る設定（sshd_backend = systemd）が入っていますが、古い解説記事はauth.logを前提にしていることが多いので、今回はjail設定でもbackendを明示しました。

cat > /etc/fail2ban/jail.d/sshd.local <<'EOF'
[sshd]
enabled = true
backend = systemd
maxretry = 5
bantime = 1h
EOF
systemctl enable --now fail2ban

更新の自動適用（unattended-upgrades）も入れます。

夜中に勝手に再起動されると困るので、自動再起動だけは切っておきます。なお定期実行の実体はAPT側のタイマー（apt-daily.timer / apt-daily-upgrade.timer）なので、検収ではタイマーが有効なことまで確認します。

cat > /etc/apt/apt.conf.d/20auto-upgrades <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF
cat > /etc/apt/apt.conf.d/52unattended-upgrades-local <<'EOF'
Unattended-Upgrade::Automatic-Reboot "false";
EOF
systemctl enable --now unattended-upgrades

ひとつ、full-upgradeの副作用で面白い発見がありました。

今回の実機では、初期状態に /etc/sudoers.d/010_pi-nopasswd があってsudoがパスワードなしで通っていたのですが、

full-upgrade後にこのファイルが消えて、sudoがパスワード必須に変わりました
（今回の環境での実測で、一般の仕様変更として確認したものではありません）。堅牢化としては望ましい方向なので、そのまま採用しています。

手順4: UFWは「許可を先に入れてから」有効化する

ファイアウォールで怖いのは自分の締め出しです。UFWはインストール直後は無効（disabled）なので、既定ポリシーを設定した瞬間に遮断が始まるわけではありません。

危険なのは、SSHの許可ルールを入れないまま ufw enable することです。

だから許可ルールを先に入れてから有効化します。

ufw default deny incoming
ufw default allow outgoing
ufw allow from 192.168.12.0/24 to any port 22 proto tcp   # 自宅LANのセグメントに合わせる
ufw --force enable

新規の受信は原則拒否し、ユーザー定義の許可ルールは自宅LANからのSSH(22)だけにします。検証用に動かしているWebサーバーの8080も、あえて許可しません（次回、ここをトンネルで公開します）。有効化したら、いまのSSHセッションは閉じずに、別のターミナルから新しくSSH接続できることを確認してください。

検収。全項目を実測で通す

設定を書き終わったら検収です。「設定ファイルにそう書いたから大丈夫」ではなく、実際の挙動を外形から確かめます。

ここまでは順調でした。問題は次です。

再起動したら、IPv6が復活していた

設定の永続性は、実際に再起動しないと分かりません。1回目の再起動検収では、再起動をかけてから約21秒でSSHが復帰し、UFWもfail2banも自動起動していました。ところが。

ip -6 addr show scope global
# → 2409:xx:xxxx:... が、いる

消したはずのIPv6グローバルアドレスが、復活していました。

原因はNetworkManagerでした。接続プロファイル側でIPv6が有効なままだったため、sysctlの disable_ipv6 を適用していても、

Wi-Fi接続が確立するタイミングでインターフェース単位の disable_ipv6 が0に書き戻されていました（今回の環境での観測）。

適用直後の確認では ip -6 addr が空になるので成功に見える。しかし再起動してWi-Fiが繋ぎ直されると、設定が巻き戻る。この動きは1回目の再起動検収で初めて表面化しました。

恒久化するには、NetworkManagerの接続プロファイル側でIPv6を無効にします。

# プロファイル名を確認（今回の実機では preconfigured という名前でした）
nmcli connection show --active

# プロファイル側でIPv6を無効化
nmcli connection modify "<上で確認した接続名>" ipv6.method "disabled"

これを入れて2回目の再起動検収を実施し、今度は再起動後もグローバルアドレス0件を維持できました。

この件の教訓は、IPv6の設定方法そのものより、こちらだと思っています。

「設定を入れて、その場で確認した」だけでは、永続性は保証されない。再起動まで含めて検収して、初めて完了になる。

検収で1項目でも落ちたら全体を未完として扱い、直してから再検収する。この運用にしていたおかげで、「無効化したつもりの設定が、再起動後には元に戻っていた」状態を公開前に見つけられました。

今回のtrixie実機で確認した、古い手順との違い

Debian 13 trixieベースになって、昔からある手順の前提と違っていた箇所がいくつかありました。

今回の実機で確認できた範囲で整理しておきます。

まとめ

セットアップ直後のRaspberry Pi 5は、検証用の簡易なパスワードでパスワード認証が有効・ファイアウォールなし・更新可能パッケージ172件・意図しないIPv6アドレス保持、という状態でした。

今回の作業で、SSHは鍵のみ・接続元LAN限定になり、UFWは受信を原則拒否してSSHだけを自宅LANから明示的に許可する構成になり、unattended-upgradesの対象となる更新は自動適用されるようになりました。

作業はすべてSSH越しで、モニターは一度も繋いでいません。

いちばんの収穫は、sysctlのIPv6無効化がNetworkManagerの接続プロファイルに書き戻される現象を、実再起動の検収で捕まえられたことです。設定直後の確認だけで完了にしていたら、この巻き戻りには公開後まで気づけないところでした。

次回はいよいよ、このラズパイの上のWebサーバーを、受信ポートを一切開けないままWireCanalでインターネット側から使えるようにします。

それでは、また次回をお楽しみに！

出典・参考

• Raspberry Pi Documentation | Configuration（公式ドキュメント）
• fail2ban 公式リポジトリ（GitHub）
• UFW - Community Help Wiki（Ubuntu公式Wiki）
• NetworkManager 公式ドキュメント（freedesktop.org）

関連記事

• Raspberry Pi 5をモニターなしでセットアップする。Windows PCだけでOS書き込みからSSH接続まで
• 自宅PCのローカルLLMを外出先のスマホから使う。Ollama＋Open WebUI+WireCanal
• ngrokとWireCanalは何が違う？開発元が料金・運用・MCP設計を比較

こんにちは！

Qualitegプロダクト開発部です！

本稿はRaspberry Pi(ラズベリーパイ、通称ラズパイ）をインターネット越しにコントロール方法についてシリーズでお伝えいたします。

シリーズですが以下の図のように、①ヘッドレスセットアップ（今回）をやったあと、インターネット公開にむけてセキュリティ対策として②Rasberry Pi の堅牢化を行い、③インターネット側から直接Rasberry Pi内に起動したWebサーバーにアクセスできるようにします

第1回の今回は、ラズパイの入手から初期セットアップ手順に関する内容です。

Windows 11のPCだけでOSの書き込みからSSH接続までを完了させた手順を、実測値つきでご紹介します。SDカードを挿して電源を入れてから、SSHでログインできるまでは約3分でした。

用意するもの

• Raspberry Pi 5本体・・・本稿では4GBモデルを使います。
• microSDカード・・・今回は64GB。初回起動時に全容量まで自動拡張されます
• Rasberry Pi5用のヒートシンク・・・熱対策用
• USBカードリーダー・・・SDカードにラズパイイメージを書き込みます
• Windows 11のPC
• USB-C電源（Raspberry Pi 5は5V/5A給電が推奨で、公式のRaspberry Pi 27W USB-C Power Supplyなどが該当します。5V/3A級の充電器でも構成によっては起動できますが、電力不足による制限や不安定動作が起きる可能性があります）

実機のセットアップ

組み立て

では、さっそくラズパイを組み立てていきましょう！

これがラズパイです。

まず、熱対策としてヒートシンクをつけていきます。

ヒートシンクをつけるまえに、CPUチップなど発熱するパーツに付属のシリコンゴムっぽい素材を貼り付けていきます。これはサーマルパッド（熱伝導パッド）というやつですね。

はい、すっかりサーマルパッドをはりつけましたので、次にヒートシンク本体を取り付けましょう。

絶縁プラスチックでできたネジでこんなふうに裏側からヒートシンクをとめてできあがり。

ヒートシンク本体がとりつけられました。

ファン用電源コネクタがラズパイ基盤上部にあるので、そこにヒートシンク側から出た電源ケーブル差し込みます。

ちなみに、SDカードはまだ挿しません。何もはいっていないので挿しても何もできません。

さて、ここまで数分で終わると思います。

次に、ソフトウェアをやっていきましょう。

モニターなしでラズパイをセットアップしていく

さっそくソフトウェアをセットアップしていきましょう。
今回はCLIのみでセットアップしていきます。つまりヘッドレスセットアップですね。

動作確認した環境は、

・書き込みソフト：Raspberry Pi Imager 2.0.8
・書き込んだOS：Raspberry Pi OS 64-bit（Debian 13 trixieベース、カーネル6.18）
・作業PC：Windows 11 Proです。

手順1: 書き込み先の物理ディスク番号を確認する

まずラズパイに差し込むSDカードを作る作業からです。

そのためには、専用の書き込みソフト「Raspberry Pi Imager 2.0.8」をつかいます。

SDカードへの書き込みは物理ディスク単位で行うため、最初にディスク番号を確認します。

Raspberry Pi Imager 2.0.8には、内蔵ドライブなど書き込み対象外のデバイスへの書き込みを拒否する安全機構がありますが、それでも、別のUSBストレージを取り違えればデータを消してしまうため、ディスク番号・容量・BusTypeの確認は必ず行ってください。

SDカードをカードリーダーでPCにつなぎ、PowerShellで次を実行します。

Get-Disk

Number FriendlyName           BusType SizeGB
------ ------------           ------- ------
     0 CT4000P3PSSD8          NVMe      3726
     1 Generic- SD/MMC/MS PRO USB       59.5

今回の環境では、内蔵SSDがディスク0、USBカードリーダー経由のSDカードがディスク1と表示されました。容量（59.5GB）とBusTypeがUSBであることからSDカードだと判断できますね。

以降の手順では書き込み先を \\.\PhysicalDrive1 と指定します。ディスク番号はお使いの環境で必ず読み替えてください。

手順2: Raspberry Pi ImagerとOSイメージを用意する

Raspberry Pi Imagerはwingetで入ります。

winget install --id RaspberryPiFoundation.RaspberryPiImager --silent --accept-package-agreements --accept-source-agreements

インストール先は C:\Program Files\Raspberry Pi Ltd\Imager\ です。GUIで使うのと同じ実行ファイルがCLIモードを持っていて、スクリプト用のラッパー rpi-imager-cli.cmd も同梱されています。

OSイメージは公式のダウンロードサイトから取得します。
raspios_arm64_latest というURLは常に最新の64-bit版（デスクトップあり）へリダイレクトされるので、覚えておくと便利です。

curl.exe -L --fail -o C:\qualiteg_examples\raspi\raspios.img.xz https://downloads.raspberrypi.com/raspios_arm64_latest

サイズは約1.3GBでした。xz圧縮のまま書き込みに使えるので、自分で展開する必要はありません。

手順3: 初回起動スクリプトfirstrun.shを作る

ここがヘッドレスセットアップの心臓部です。

Raspberry Pi OSに標準で入っているヘルパー imager_custom と userconf を呼び出して、ホスト名、SSH、ユーザー、Wi-Fi、キーボード配列、タイムゾーンをまとめて設定します。ファイル名は firstrun.sh とし、置き場所はどこでも構いません（次の手順で書き込み時にパスを渡します）。

#!/bin/bash
# set +e は途中のコマンドが失敗しても最後の後始末まで進めるための指定。
# 設定が反映されないときは、各コマンドの成否を個別に確認すること
set +e

/usr/lib/raspberrypi-sys-mods/imager_custom set_hostname raspberrypi
/usr/lib/raspberrypi-sys-mods/imager_custom enable_ssh
/usr/lib/userconf-pi/userconf 'pi' '$6$…（openssl passwd -6 で生成したハッシュ）'
/usr/lib/raspberrypi-sys-mods/imager_custom set_wlan 'your-ssid' 'your-wifi-password' 'JP'
/usr/lib/raspberrypi-sys-mods/imager_custom set_keymap 'jp'
/usr/lib/raspberrypi-sys-mods/imager_custom set_timezone 'Asia/Tokyo'

rm -f /boot/firstrun.sh /boot/firmware/firstrun.sh
sed -i 's| systemd.run.*||g' /boot/cmdline.txt /boot/firmware/cmdline.txt 2>/dev/null
exit 0

SSIDとWi-Fiパスワード（上記スクリプトの'your-ssid' 'your-wifi-password'の部分）はご自身のものに置き換えてください。

ーザーのパスワードは平文ではなくSHA-512ハッシュで渡します。ハッシュはGit Bashなどで次のように作れます。

openssl passwd -6 '設定したいパスワード'

末尾の2行は、スクリプトが自分自身を削除して通常起動に戻すための後始末です。Imagerが起動設定（cmdline.txt）に仕込むエントリを外しています。

ひとつだけ重要な注意があります。

このファイルの改行コードは必ずLFにしてください。

Windowsのエディタで作るとCRLFになりがちで、CRLFのままだと初回起動時にスクリプトが失敗します。SSHは有効にならず、Wi-Fiにもつながらず、モニターがないので失敗の様子も見えないという、なかなかつらい状態になります。

セキュリティ上の注意もひとつ。firstrun.sh にはWi-Fiパスワードが平文で入ります。Gitへのコミットや共有フォルダへの配置は避け、Windows側に残った作業用ファイルも不要になったら削除してください。

手順4: CLIでSDカードに書き込む

物理ディスクへの書き込みには管理者権限が必要なので、PowerShellから昇格つきで実行します。UACのダイアログが出たら許可してください。

$imgr = 'C:\Program Files\Raspberry Pi Ltd\Imager\rpi-imager.exe'
$opts = @('--cli', '--debug', '--disable-eject',
          '--first-run-script', 'C:\qualiteg_examples\raspi\firstrun.sh',
          '--log-file',         'C:\qualiteg_examples\raspi\flash-log.txt',
          'C:\qualiteg_examples\raspi\raspios.img.xz',
          '\\.\PhysicalDrive1')
Start-Process -FilePath $imgr -ArgumentList $opts -Verb RunAs -Wait

使っているオプションの意味です。

書き込み後の読み戻し検証（ベリファイ）はデフォルトで有効です。実測では、1.3GBのxzイメージの展開に53秒、書き込みと検証を合わせて5分ほどで完了しました。書き込みの遅いSDカードだとログに書き込みレイテンシの警告が出ますが、Imagerが自動でバッファ量を調整して続行するので、そのまま待てば大丈夫です。

進捗表示について補足します。今回のように Start-Process -Verb RunAs で昇格して起動した構成では、元のPowerShell側では進捗を確認できませんでした。そのため --log-file を指定し、ログファイルで進捗と結果を確認しています。ログの最後に succeeded と出ていれば成功です。

手順5: 電源を入れて3分待ち、SSHで接続する

書き込みが終わったSDカードをラズパイ5に挿しましょう。

そして、USB-C電源をつなぐだけで起動します。

Raspberry Pi 5には電源ボタンもありますが、通常の初回起動ではボタン操作は不要です。初回はファイルシステムの自動拡張、firstrun.sh の実行、再起動が順に走るので、2〜3分待ちます。基板の緑のLEDが点滅していれば起動処理中です。

待ったら、WindowsのターミナルからSSHで接続します。

ssh pi@raspberrypi.local

raspberrypi.local という名前はmDNSという仕組みで解決されます。Windows 11は標準で対応しているので、追加のソフトは要りません。今回の実測では、SDカードを挿して電源を入れてから約3分でSSHポートが開き、初期設定したユーザーでログインできました。

ログイン後の状態も確認しました。uname -a、vcgencmd measure_temp、df -h の出力の抜粋です。

Linux raspberrypi 6.18.34+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.18.34-1+rpt1 (2026-06-09) aarch64 GNU/Linux
temp=34.0'C
/dev/mmcblk0p2   58G  6.6G   49G  12% /

64GBカードの全域がルートファイルシステムに拡張済みで、CPU温度は34.0度、Wi-Fi経由でIPv4アドレスも取得できていました。

ここまでくれば、あとは普通のLinuxマシンとして使えます。

ハマりどころと回避策

今回の作業で実際に踏んだ罠を表にまとめます。

最後のplinkの罠は、SSH接続までスクリプトで自動化したい人向けの補足です。手でsshコマンドを打つ分には遭遇しません。

まとめ

モニターなしのRaspberry Pi 5セットアップは、次の5点を押さえれば安全に完走できます。

• 書き込み前に Get-Disk で物理ディスク番号を確認する（最重要）
• OSイメージは raspios_arm64_latest から取得し、xzのまま書き込む
• firstrun.sh にWi-Fi、SSH、ユーザー設定を仕込む。改行コードはLF
• 書き込みは管理者権限で実行し、結果は --log-file のログで確認する
• 初回起動は3分待ってから ssh pi@raspberrypi.local

ログインできたら、次の一手として最初にパスワードの変更とパッケージ更新をおすすめします。

passwd
sudo apt update && sudo apt full-upgrade -y

デスクトップ画面を使いたくなったら、sudo raspi-config でVNCを有効にすると、Windowsからリモートデスクトップのように操作できます。

このあたりは別の記事で紹介する予定です。

それでは、また次回お楽しみに！

参考リンク

• Raspberry Pi Imager（公式ダウンロードページ）
• Raspberry Pi OS イメージ一覧（公式ダウンロードサイト）
• Cloud-init on Raspberry Pi OS（公式ブログ。firstrun.sh方式からcloud-initへの移行について）
• PuTTY 公式サイト（plink のダウンロード）

こんにちは！

LINE Botを作ろうとして最初にぶつかる壁は、コードではなくWebhookです。

LINEのMessaging APIは、ユーザーがBotに送ったメッセージを、LINEのサーバーからこちらのサーバーへHTTPSのPOSTで通知してきます。

この受け口（Webhook URL）にはインターネットから届くHTTPSのURLしか指定できず、開発中の http://localhost:5000 をそのまま書くことはできません。

トンネルツールで一時URLを発行して回避する方法が定番ですが、今度は別の問題が待っています。トンネルの方式によっては、起動のたびにランダムなURLが発行されます。その場合、開発を再開するたびにLINE Developersコンソールを開いてWebhook URLを書き換えることになります。コードを直すたび、翌日再開するたび、まずURLの貼り直しから。これが地味に堪えます。

結論から言うと、

ローカルPCの開発サーバーに「変わらない公開URL」を1本付けてしまえば、Webhook URLの設定は最初の1回だけで終わります。

この記事では、LINE公式アカウントの開設からMessaging APIの設定、PythonでのWebhook受信サーバーの実装、固定URLでの公開、スマホの実機でBotが返事するところまでを、最初から最後まで書きます。

手順・コマンド・画面はすべて筆者が実際に動かして確認したものです
（確認日は2026年8月11日。LINE側の画面は変わることがあります）。

なお、Botの中身は受け取ったメッセージをそのまま返す最小構成にしてあります。この記事のゴールは「LINEからのWebhookがローカルのPythonに届き、返事がスマホに出る」までの経路を作りきることです。

手順1: LINE公式アカウントを作る（2026年8月の現行手順）

まず知っておきたいのは、

Messaging APIチャネルはLINE Developersコンソールから直接作れなくなった

現在この画面には
「LINE公式アカウントを作成した後、LINE Official Account Manager上でMessaging APIの利用を有効にしてください」
と案内が出ます。

現行の流れはこうなります。

1. LINEビジネスID（LINEヤフーBusiness ID）を作る。メールアドレスだけで作成でき、LINEアプリのアカウントは不要です
2. LINE Developersコンソールに開発者登録し、プロバイダーを作る
3. LINE公式アカウントを作る。作成時にビジネスマネージャー組織との接続を求められるので、組織がなければその場で作成します（組織名は空欄ならアカウント名と同じになります）
4. LINE Official Account ManagerでMessaging APIを有効にする

プロバイダーは、このBotを提供する個人・企業・団体を表す単位です。LINEログインなどと組み合わせた場合には同意画面にも表示されるため、会社名やサービス名など、利用者が提供元を判断できる名前にしておくのが無難です
（筆者は「Qualiteg」で作りました）。

公式アカウントの作成フォームでは、アカウント名（友だちリストとトーク画面に表示されるBotの名前）、会社・事業者名、業種などを入力します。ここでひとつ注意があります。公式アカウントの新規作成には、電話番号認証（SMSまたは通話）が必要です。画面の案内によれば、認証に使った電話番号が友だちに公開されることはありません。

アカウントの種別は「未認証アカウント」のままで大丈夫です。認証済アカウント（緑色の認証バッジ）はLINE内の検索対象になるなどのメリットがありますが、開発用のBotには必要ありません。

手順2: Messaging APIを有効にして、鍵を3つ手に入れる

公式アカウントができたら、LINE Official Account Manager（管理画面）を開き、設定の「Messaging API」から「Messaging APIを利用する」を押します。ここでプロバイダーを選びますが、一度ひもづけたプロバイダーはあとから変更できません。手順1で作ったプロバイダーを選んでください。

有効になると、この画面にChannel IDとChannel secretが表示されます。

Botの開発に必要な「鍵」は3つあります。

チャネルアクセストークンだけはDevelopersコンソール側での発行操作が必要です。発行したトークンとChannel secretは、コードに直書きせず環境変数で渡します（次の手順で使います）。

手順3: Webhookを受ける最小のBotを書く

サーバーはPythonで書きます。公式SDK（line-bot-sdk）とFlaskを入れます。

pip install line-bot-sdk flask

筆者環境ではline-bot-sdk 3.25.0とflask 3.1.3が入りました（Python 3.11）。

app.py（全文）

import os

from flask import Flask, request, abort
from linebot.v3 import WebhookHandler
from linebot.v3.exceptions import InvalidSignatureError
from linebot.v3.messaging import (
    ApiClient,
    Configuration,
    MessagingApi,
    ReplyMessageRequest,
    TextMessage,
)
from linebot.v3.webhooks import MessageEvent, TextMessageContent

app = Flask(__name__)

configuration = Configuration(access_token=os.environ["LINE_CHANNEL_ACCESS_TOKEN"])
handler = WebhookHandler(os.environ["LINE_CHANNEL_SECRET"])


@app.route("/health", methods=["GET"])
def health():
    return "OK"


@app.route("/callback", methods=["POST"])
def callback():
    signature = request.headers.get("X-Line-Signature", "")
    body = request.get_data(as_text=True)
    try:
        handler.handle(body, signature)
    except InvalidSignatureError:
        abort(400)
    return "OK"


@handler.add(MessageEvent, message=TextMessageContent)
def handle_message(event):
    reply = f"「{event.message.text}」を受け取りました！"
    with ApiClient(configuration) as api_client:
        MessagingApi(api_client).reply_message(
            ReplyMessageRequest(
                reply_token=event.reply_token,
                messages=[TextMessage(text=reply)],
            )
        )


if __name__ == "__main__":
    app.run(host="127.0.0.1", port=5000)

やっていることは3つだけです。/callback でLINEからのPOSTを受け、X-Line-Signature ヘッダーをChannel secretで検証し（この検証がSDKに入っているので、自前実装は不要です）、テキストメッセージが来たら「「◯◯」を受け取りました！」と返します。

なお、このコードはローカル開発用の最小例です。本番運用では、Webhookへの応答（200）を速やかに返し、イベントの処理は非同期にする構成がLINE公式ドキュメントで推奨されています。

手順2の鍵を環境変数に入れて起動します。

$env:LINE_CHANNEL_SECRET = '（Channel secret）'
$env:LINE_CHANNEL_ACCESS_TOKEN = '（チャネルアクセストークン）'
python app.py

http://localhost:5000/health が OK を返せば起動しています。この時点ではまだlocalhostの中の話で、LINEからは届きません。

手順4: ローカルに「変わらない公開URL」を付ける

ここが本題です。localhost:5000に、再起動しても変わらないHTTPSのURLを付けます。

この記事では、当社が開発・運営しているWireCanalで進めます（自社サービスなので、そこは割り引いて読んでください）。

なお、固定のURLを使うこと自体はWireCanal固有の話ではなく、他のトンネルサービスの固定ドメイン機能でも同じ考え方で実現できます。

ダッシュボードでcanal（トンネルの公開口）を作ります。種類はHTTP、転送先に localhost:5000 を指定すると、公開URLが1本発行されます。

このURLはランダムな文字列で発行されますが、起動のたびに変わることはありません。 PCを再起動しても、エージェントを止めて翌日つなぎ直しても、同じURLで受けられます。プランによる違いだけ正確に書いておくと、無料プランの公開URLは「使っている限り有効」（エージェントの最終接続から72時間で失効）で、毎日開発する分には同じURLのままです。3日以上止めても失効しない永続URLにしたい場合はライトプラン以上になります（筆者はライトプランで検証しました。スクリーンショットの「予約（永続）」はその表示です）。

次に、PCへエージェントを入れて起動します。セットアップガイド（wirecanal.com）のとおり、PowerShellで1行です。

irm https://download.wirecanal.com/install.ps1 | iex

ダッシュボードから接続設定ファイル（wirecanal.json）をダウンロードしてエージェントと同じフォルダに置き、起動します。

.\wirecanal.exe -config wirecanal.json

ダッシュボードに「接続されました！」と出れば、公開URLへのアクセスがlocalhost:5000へ届く状態です。

外から確認してみます。

> curl https://7pqvyoih.ja100.wirecanal.com/health
OK

手順3のFlaskが、インターネット越しに応答しました。受信ポートの開放もVPNも使っていません（エージェントは外向きの接続だけで通信します）。

手順5: Webhook URLを設定して検証する

LINE Developersコンソールに戻り、チャネルの「Messaging API設定」タブでWebhook URLを設定します。公開URLに、app.pyで受けているパス /callback を付けたものです。

https://（あなたの公開URL）/callback

設定したら、その下の「Webhookの利用」を必ずオンにします。URLを入れただけではWebhookは届きません。

「検証」ボタンを押すと、LINEのサーバーからこのURLへ実際にテスト接続が飛びます。「成功」が出れば、LINE→トンネル→ローカルのFlaskまでの経路が通っています。

つまずきポイント: 返事が二重に届く

これで動くはずなのですが、実際にスマホからメッセージを送ると、筆者の環境では奇妙なことが起きました。Botの返事の前に、身に覚えのない定型文が届くのです。

メッセージありがとうございます！申し訳ありませんが、このアカウントでは個別のお問い合わせを受け付けておりません。

正体は、公式アカウントに最初から入っている応答メッセージ（自動応答）です。筆者が新規作成したアカウントでは「Default」という一律応答が有効になっており、Webhookとは別枠で動くため、Botの返事と定型文の両方がユーザーに届いていました。

二重返信が起きたら、Official Account Managerで応答メッセージの状態を確認します。止め方は2つあり、応答メッセージ一覧で個別のメッセージを利用停止にするか、「設定」→「応答設定」で機能全体の「応答メッセージ」をオフにします。いま実際に送られる状態かどうかは、応答メッセージ一覧の上部にある「現在のステータス」で確認できます（「利用中。応答メッセージは送信されています」と出ていたら、まだ送られます）。筆者はここのステータスが「利用中」のままなのに気づかず、1回むだにテストしました。

スマホから使ってみる

友だち追加用のQRコード（Official Account Managerの「友だち追加ガイド」にあります）をスマホのLINEで読み取り、Botを友だち追加してメッセージを送ります。

「こんにちは」と送ると、即座に「「こんにちは」を受け取りました！」が返ってきます。サーバー側のログにも、LINEからのPOSTが記録されています。

127.0.0.1 - - [11/Aug/2026 00:24:32] "POST /callback HTTP/1.1" 200 -

ここまでで、スマホのLINE→LINEプラットフォーム→固定の公開URL→ローカルPCのFlask→返信、という経路が全部つながりました。

まとめ: URLを書き換える作業は、もう発生しない

この構成のいちばんの利点は、翌日の開発再開が「エージェントとapp.pyを起動するだけ」になることです。公開URLが変わらないので、LINE Developersコンソールを開き直してWebhook URLを貼り替える作業がそもそも発生しません。コードを直したらapp.pyを再起動するだけで、同じURLのまま試せます。

最後に、今回の構成の勘所を置いておきます。

それでは、また次回、お会いしましょう！

出典・参考

• Messaging APIを始めよう（LINE Developers公式ドキュメント）
• Messaging APIの概要（LINE Developers公式ドキュメント）
• line-bot-sdk-python（LINE公式SDK・GitHub）
• WireCanal 料金プラン
• WireCanal セットアップガイド（Windows）

関連記事

• ngrokとWireCanalは何が違う？開発元が料金・運用・MCP設計を比較
• 自宅PCのローカルLLMを外出先のスマホから使う。Ollama＋Open WebUI+WireCanal