Doa

小〜中規模のWebアプリをSvelteKit + Bun + SQLiteに寄せてみた

Fri, 04 Sep 2026 00:00:00 GMT

久しぶりにウェブ寄りのネタです。
ここ1年ほど個人で作っているWebアプリは全部SvelteKit + Bun + SQLiteの構成にしているのですが、なぜそうなったのかを一度まとめておこうと思います。

概要#

現状動かしているものは下記の通りです。

	何をするもの	公開
worklog	SlackやGitHubのログから稼働表を作るやつ	サービスのみ
𝕏ool	𝕏の1日分の成績を通信簿として自動ポストするやつ	ソース
mogiri	QRを使った入場受付と、事前購入・セルフレジ	ソース
denpa	テレビの番組表、予約、録画、配信	ソース
tamasagashi	公的データから作った車両マスター(型式 → 通称名・諸元)の閲覧	サービスのみ

5つともpackage.jsonの中身がほぼ同じで、SvelteKit 2 + Svelte 5、adapter-node、Blades(Pico CSSの後継)、bun:sqlite、TypeScript 7、起動はbun build/index.jsという構成になっています。
別に最初から揃えようと思っていたわけではなく、1個書き直したら楽だったので以降全部そうなった、というのが正直なところです。

書き直しに至った経緯#

mogiri(旧 Smart QR Payment)は元々Django REST Frameworkのバックエンドと、Nuxt(Vuetify)のフロントエンドの2本立てで2024年頃に作ったものでした。
その後しばらく触っていなかったのですが、触っていなくてもRenovateのPRだけは来続けます。2026年7月の履歴を見ると下記の様な感じで、依存を上げてはそれを動く状態に運ぶだけのコミットが挟まっています。

1
2026-07-28  Update dependency Django to v3.2.25
2
2026-07-28  Update dependency @nuxt/eslint-config to ^0.7.0
3
2026-07-29  Carry the dependency bumps through to a working app

言語が2つ、ランタイムが2つ、コンテナが2つ。この規模のアプリでそれぞれの更新に付き合うのは割に合わないと感じました。
小規模なアプリケーションでバックエンドを分けるのは過剰で、単一コンテナにしたほうがいいだろうということで、2026年8月に丸ごと書き直しました。APIと画面は1つのSvelteKitアプリに統合、コンテナは1つ、k3s上ではPVC1つの単一Podです。

Svelteにした理由#

元々Vueだったので普通に考えればReactかそのままNuxtなのですが、Svelteに行きました。

理由は単純で書く量が少なく、生成されるコードも読みやすいからです。Svelte 5のrunesは状態の扱いが素直で、後述しますが実装の多くをAIに書かせているので、出てきたコードを自分が読んで直せるかどうかが結構効いてきます。
ReactもtsxはReact CompilerのおかげでuseMemoの管理を意識しなくてよくなったとはいえ、Svelteほど記述が楽になったわけではないと思います。加えてReactの生態系の速さと重さについていく気が個人的にありません。Next.jsはVercel専用の機能が多く、自分のk3sに載せる場合その辺が邪魔になります。

Nuxtを辞めたのは破壊的変更が多い割に、上に挙げたメリットが薄かったからです。

SvelteKitにするとAPIと画面が1つになります。Nextでもできることではあるのですが、SvelteKitのほうが素直に組めて、adapter-nodeで普通のNodeサーバとして吐き出せるので置き場所を選びません。

SQLiteに関して#

bun:sqliteがBunに標準で入っていて速い、ドライバも別プロセスも要らない、DBはファイル1つ。k3sではPVCを1つ持たせれば完結し、バックアップはファイルのコピーで済みます。

限界は分かったうえで使っています。書き込みは単一ライターで水平スケールはできません。denpaは1本のSQLiteにスケジューラも番組表の取得も書きに行くので、レプリカは1つでstrategy: Recreateにしてあります。
それでもSQLiteにしたのは小規模のアプリでPostgreSQLを立てると余計な管理コストのほうが大きいためです。最近は中規模のアプリでもSQLiteの採用が増えていますし、CloudflareのD1のように本番前提のサービスも出てきているので、プロダクションで使う分には十分耐えられると判断しました。規模が大きくなったらPostgreSQLにする、と決めたうえでの選択です。

起動時に入れているのは下記だけです。

1
export const db = new Database(url, { create: true });
2
db.exec('PRAGMA journal_mode = WAL;');
3
db.exec('PRAGMA foreign_keys = ON;');
4
ensureSchema(db);

索引に関して#

SQLiteでも索引をちゃんと張れば検索は十分速い、という例がtamasagashiです。国交省の燃費一覧や官報の型式指定、リコール届出といった公的データをJSONLにしたものを、ビルド時にSQLiteへ取り込んでイメージに焼き込み、実行時は読み取り専用で開いています。書き込みが無いので単一ライターの制約は最初から関係ありません。
検索のキーになる型式と通称名はひらがな・カタカナ・全角半角・空白・ハイフンの違いを無視したいのですが、これをクエリ側で毎回やると索引が効かなくなるので、取り込み時に正規化したcode_norm・name_normという列を別に持たせ、そこに索引を張ってLIKEで引いています。取り込み時と検索時で同じ正規化関数を通すのが要点で、表記揺れの吸収は取り込みの段階で終わらせておく形です。
その他にも複合主キーだけで引く表はWITHOUT ROWIDにする、取り込み中はPRAGMA synchronous = OFFで流し込んで最後にwal_checkpoint(TRUNCATE)とVACUUMで固めてから配る、といった辺りは全部SQLiteの標準機能で済んでいます。この規模で「SQLiteだから遅い」と感じたことは今のところありません。

ORMに関して#

書き直しの初版ではDrizzle ORMを入れていたのですが、この規模だとORMが吸収してくれる差分が特になく、SQLを直接書いたほうが読めるし直せるのでその日のうちに外しました。いまはddl.tsにスキーマ、repo.tsに生のSQLを書いた薄い層だけになっています。

NOTE
SQLiteらしい使い方として、denpaでは録画のstateを生成列にしています。書き込もうとするとSQLite側が拒むので、事実と状態が食い違いようがありません。文字列で別に持っていた頃はここがずれてバグの温床になっていました。

Bunに関して#

bun:sqliteとBun.password(argon2id)が同梱されていて、ネイティブ依存を入れずにDBとパスワードハッシュが済むこと。TypeScriptをそのまま実行できて起動も速いこと。この2つです。

副産物として本番のnode_modulesが消えました。adapter-nodeはdevDependenciesをサーバのビルドに束ねてdependenciesだけを外に残す仕様なので、実行時に本当に必要なものをdevDependenciesに寄せるとdependenciesが空になり、Bunとビルド出力だけで動きます。Dockerfileの最終ステージからinstallが消えました。

Bunで引っかかった点#

良いことばかり書いても仕方がないので、実際に引っかかったところも書いておきます。

Nodeでは起動できない
bun:sqliteを使った時点でそのアプリはBunでしか動きません。READMEに「必ずBunで起動してください」と書く羽目になります。乗り換えの逃げ道は自分で塞いでいます。
ローカルのBunとコンテナのBunでバージョンが違うと事故る
一度踏んでから開発は全部コンテナ内に寄せました。リポジトリ直下でbun installすると下記のpreinstallが止めます。
```
1
"preinstall": "test \"$PWD\" = /usr/src/app || { echo 'ローカルで install しないでください'; exit 1; }"
```
ViteをBunで走らせるにはbunx --bun viteと書く必要がある
素のviteだとNodeで立ち上がります。
TypeScript 7とsvelte-checkの併存
svelte-checkをTypeScript 7のネイティブ版(tsgo)で走らせるには、typescript@~6と@typescript/nativeのエイリアスを両方入れておく必要があります。速くはなりますが依存の並びは少し気持ち悪いです。
Biomeは.svelteの<script>しか見ない
テンプレート側で使っている変数を未使用と判定するので、.svelteでは未使用チェックを切っています。
adapter-nodeはSIGTERMを受けた瞬間にlistenを閉じる
これはBunというよりSvelteKitを長時間走るプロセスとしてk3sに置くときの話です。denpaは録画中にデプロイが来ても録り終わるまで居座る設計なのですが、adapter-nodeの既定の後始末が先に走って、プロセスは生きているのにポートだけ閉じている状態になりました。止まれの合図を自前で受け取って後始末を外す、しかも登録タイミングの都合で2回やる必要がありました。詳細はdenpaのarchitecture.mdに書いてあります。

BiomeとCSSに関して#

Biomeを選んだのは、自分がきれい好きでライブラリが分散するのを嫌った面が大きいです。ライブラリは少ないにこしたことはないでしょう。mogiriの書き直し直後はESLint + Prettierだったのですが、lintとformatで別々のライブラリと設定ファイルを持って、しかもお互いの相性まで見るのが嫌だったのでbiome.json1つとbiome check --write1コマンドに寄せました。Rust製で速いのでcheckのスクリプトに型チェックと並べて入れても気になりません。
難点は先に書いた通り.svelteの<script>しか見ないことで、テンプレート側で使っている変数を未使用と判定するので、そこだけルールを切って使っています。

CSSは長らくTailwind + daisyUIでした。立ち上げの段階では決め打ちでUIを作るのが楽で、カスタマイズしたくなったときはTailwindでそのまま手を入れやすい。最初はclass="btn btn-primary"で済ませておいて、気に入らないところだけclass="btn btn-primary rounded-full px-8"とユーティリティを足す、という使い方をしていました。

ただ全アプリを一通り作り終えてから見直すと、実際に出てくる部品は表・フォーム・注意書き・札くらいしかありませんでした。その程度のものに3,000行のコンポーネントCSSを読み込んで、マークアップ側はclass="card bg-base-100 border-base-300 flex flex-col gap-3 p-4 shadow-sm"のようにクラスを10個並べる形になっていて、半年後の自分が読んで何をしているのか分からない。utility classは書くのは速いのですが、読むときには全部のクラス名を頭の中でCSSに戻す作業が要ります。

なので一度Pico CSSに全部移しました。素の<button>や<table>にそのまま見た目が付くクラスレスのCSSです。

NOTE
2026年10月追記その後Pico CSS本体はやめて、Picoを引き継いでメンテナンスされているBlades(@anyblades/blades)に全アプリ切り替えました。素のCSSで配られているのでSassが要らなくなり、sass-embeddedとVite側の設定を外せました。以下はBladesに移ったあとの形で書いています。

1
@import "@anyblades/blades/pico" layer(pico);

Bladesはpicoという名前の層(@layer)に入れて読み込みます。層に入れていないこちらの規則は詳細度に関係なく必ず層の中の規則に勝つので、Picoの強いセレクタに合わせて同じ強さで書き直す、という張り合いが要りません。

そのうえで、アプリ共通で使うものだけapp.cssに.panel(白い箱)・.note(注意書き)・.tag(札)・.field(ラベル+入力欄)といった名前を10個ほど置いて、画面固有の調整はSvelteの<style>(scoped)に閉じ込める、という形にしました。結果として先ほどのマークアップはclass="panel body"の2語になり、画面ごとの事情はその画面のファイルの中だけに書かれるようになります。

色も基本はBladesの既定のまま使っています。自前のトークンはPicoの--pico-*変数から引くだけにしておくと、明暗の切り替えがBlades側に勝手に追従してくれるので、アプリ側でダークテーマの面倒を見る必要がなくなりました。

ドロップダウンやダイアログのようにキーボード操作とフォーカスの面倒を見ないといけない部品だけはBits UIを足しています。見た目を持たないヘッドレスなものなので、CSSはこちらで書く方針と喧嘩しません。

SvelteKitで済ませないもの#

全部これで済ませているわけではなく、大規模な計算や、キューを持って長時間回し続けるような処理が必要になった場合は.NETを使うようにしています。
denpaのチューナーエージェントがそれで、電波を掴んで素のTSを流すだけの部品なのですが、最初bunで書いていたものを実機で測ったうえで.NETに書き直しました(Native AOTなので実行ファイル1個で依存もありません)。
bunのままだと何が困ったかというと、まずチューナーを取り上げられた等で失敗したときは受け取る側に正常終了として届かないよう接続ごと壊さないといけないのですが、bun版はこれができず尻切れの録画が「録れた」ことになっていました。それとカーネル側のdvrのリングバッファが既定で1.8MB、地上波の18Mbit/秒だと0.9秒分しかないので、読む側がGC等で一瞬止まるだけで溢れます。この辺りは実機で溢れた回数を数えながら詰めていったのですが、結局ioctlを直に叩けるのも.NET版だけだったのでそちらに落ち着いた、という流れです。測った数字はagent.mdにそのまま書いてあるので興味があれば見てみてください。
画面とAPIはSvelteKit、機材に近いところやリアルタイム性が要るところ、重い計算は.NETで書く、という程度の分け方で今のところ困っていません。

AIに関して#

正直に書くとmogiriの書き直しはほぼClaudeに書かせています。Django + Nuxtを読んで同じ画面フローをSvelteKitで作り直す、という作業です。人間がやったのは上に書いた判断と、出てきたものを触って直すことでした。

1言語1プロセスで生成コードが読みやすい、という選択はこの前提があるから効いています。読めないものを大量に生成されても困るので、書く量が少なく構造が素直なSvelteを選んだのはAIに任せる範囲を広げるための判断でもあります。
この辺りの実感はSlackの記事の後半に書いています。

まとめ#

小〜中規模ならバックエンドを分けない。SvelteKit一本でコンテナ1つ
Svelteは書く量と読みやすさで選んだ。Reactの生態系に付き合う気はない
SQLiteは限界を分かって使う。PVC1つで完結し、大きくなったらPostgreSQL
Bunは同梱物の多さで選んだ。代わりにNodeへの逃げ道は塞がる
重い計算やキューが要るところは.NETに切り出す

5つ作って全部同じ形に収まったので、次に何か作るときもたぶんこのまま始めると思います。この構成で困っている方や、ここはこうしたほうがいいというのがあればコメント頂けると助かります。

Slackで「自分の全投稿を取得するアプリ」は配布できない

Fri, 31 Jul 2026 00:00:00 GMT

Slackで自分の全投稿を横断して取得するアプリを作ろうとしたところ、Slack Marketplaceに掲載できないことが分かりました。必要になるsearch:readがガイドラインで拒否スコープとして名指しされているためです。
迂回路もひととおり潰れていて、結局ユーザー自身に内部アプリを作ってもらう以外の方法がありませんでした。同じことを調べる人がまた1日溶かさないように、引用と出典を付けて残しておきます。

やりたかったこと#

Slackの投稿時刻から稼働表(勤務時間の一覧)を自動生成したい、という話です。
必要なのは時刻だけで本文は要りません。誰がいつ発言したかが分かれば、活動の塊から稼働の開始・終了・休憩を推定できます。

これを実現するAPIはsearch.messagesです。from:<@USER_ID> after:2026-06-01 before:2026-07-01のようなクエリで自分の投稿だけを期間指定で引けます。必要なスコープはsearch:readひとつ。
権限としてはむしろ小さいほうだと思います。チャンネルの履歴を丸ごと読むわけではなく、自分の投稿しか返らないからです。

search:readの扱い#

ガイドラインにそのまま書かれています。

legacy/restricted scopes or methods, scopes that provide extensive access to workspace data without a clear use case that requires them, or coded workflow scopes (e.g. admin.*, identity.*, search:read, workflow.steps:execute, triggers:*) 参考: Slack Marketplace app guidelines and requirements

スコープのリファレンス側でもlegacy扱いです。

This is a legacy scope 参考: search:read scope

IMPORTANT
廃止されたわけではありません。user tokenであればsearch.messagesは現役で動きます。掲載できないだけです。ここを混同すると「もう使えない」と誤解するので注意してください。

*:historyでの迂回に関して#

検索がダメならチャンネル履歴を読めばいいのでは、と考えるところですが、同じページがやってはいけないこととして挙げています。

Request user token *:history and files:read scopes for the collection of message and file data

しかも2025年5月にレート制限が変わり、この経路は実質的に死んでいます。

The conversations.history API method rate limit for commercially distributed apps created after May 29, 2025 … will be limited to 1 request per minute … These methods will have a new rate limit of 15 messages per request. 参考: Rate limit changes for non-Marketplace apps

1分に1リクエスト、1リクエストあたり15件です。1か月分を遡って集計する用途では話になりません。
そもそも履歴の取得はチャンネル内の全員のメッセージを読むことになります。自分の投稿だけ欲しいのに要求する権限は検索より遥かに広くなるわけで、摩擦を減らそうとしてより侵襲的になるという交換なので筋が悪いです。

Real-time Search APIに関して#

2026年2月にSlackはsearch:readの代替としてReal-time Search APIを出しています。assistant.search.contextと、粒度を細かくしたsearch:read.public / .private / .imなどです。

参考: Announcing the Slack MCP server and Real-time Search API

こちらは掲載できます。ただし利用条件が4つあり、用途によっては全部刺さります。

条件	内容
データ保存の禁止	”You must not store or copy any of the data retrieved from this API.”
ゲスト利用不可	”Workspace guests are not permitted to access apps using platform AI features”
プラン制限	semantic searchはBusiness+ / Enterprise+
AI features限定	”exclusively in your app using AI features”

参考: Using the Real-time Search API

自分の用途では2番目が致命的でした。客先常駐や業務委託の人は常駐先のワークスペースにゲストとして参加していることが多いので、狙っている利用者層をそのまま除外する条件になっています。
1リクエストあたり最大20件、ユーザーあたり毎分10リクエストという上限もあります。

ワークスペース側のアプリ承認設定#

ここが一番の収穫でした。内部アプリなんてどうせ管理者に止められるのではと思っていたのですが、調べてみると前提が逆でした。

By default, members can install apps without approval from a Workspace Owner. 参考: Manage app approval for your workspace

デフォルトは承認不要です。そのうえで設定を厳しくした場合の挙動が下記の通りです。

ワークスペースの設定	Marketplace掲載アプリ	自作の内部アプリ
制限なし(デフォルト)	通る	通る
Marketplaceのアプリのみ許可	通る	通る
全アプリ承認必須	承認待ち	承認待ち

2行目についてはSlackが明言しています。

Workspace Owners can set a permission to “Only allow apps from the Slack Marketplace” … This will not prevent members from creating and installing internal apps. 参考: Add apps to your Slack workspace

つまり「Marketplace限定」の設定は内部アプリを止めません。名前から受ける印象と逆です。
3行目の「全アプリ承認必須」ではMarketplace掲載アプリも同じく承認待ちになるので、内部アプリが不利になる設定は存在しないことになります。

さらに先ほどのレート制限の変更にはこう書かれています。

Internal customer-built apps will not notice any changes.

内部アプリは制限強化の対象外です。
結果として内部アプリ方式は掲載できないので仕方なく選ぶ次善策ではなく、この用途で唯一まともに動く選択肢でした。

実際の配布方法#

ユーザー自身にアプリを作ってもらう形にしました。手間を減らすためApp ManifestをURLに載せて渡します。

1
https://api.slack.com/apps?new_app=1&manifest_yaml=<URL エンコードした manifest>

参考: Configuring apps with app manifests

これでアプリ名・説明・スコープが入力済みの状態から始められます。要求するのはsearch:readひとつだけなので同意画面も軽いです。
ドキュメント上は「リンクを踏む → Create → Install → トークンをコピー」で終わるように読めるのですが、実際にやると罠が2つありました。

作成時に出る赤いエラー#

Step 2のCreate and Installを押すと白いポップアップが一瞬開いて閉じ、下記の様に表示されます。

1
Installation was not completed. Click Create and Install to try again.

アプリ自体は作成できています。一覧を再読み込みすれば出てきます。
原因はおそらくこのアプリがbotスコープを1つも持っていないことです。作成とインストールを一度に行う導線なのにインストールするbotが存在しないので空振りしている。botスコープを足せば消えると思われますが、そのために要求権限を増やすのは本末転倒なのでそのままにしています。
初回オンボーディングの一歩目で赤いエラーが出るのは説明が無ければ確実に離脱するので、「これは正常です」と手順に書くしかありませんでした。

token rotationに関して#

OAuth & Permissionsのページ上部に下記の様に書かれた項目があります。

Recommended for developers building on or for security-minded organizations

Recommendedと書いてある以上押したくなりますが、押すとトークンが短時間で失効するようになり、リフレッシュの仕組みを持っていないアプリは繋がらなくなります。
生成するmanifestではtoken_rotation_enabled: falseにしていますが、後から画面で有効にできてしまうので、こちらも手順に「有効にしないでください」と明記しています。

AIに関して#

正直に書いておくと、コードはほぼAI(Claude Code)に書かせています。人間側がやったのは何を作るか・何を作らないかの判断です。
これは楽な仕事ではありませんでした。AIは指示すれば動くものを作りますが、指示が間違っていれば間違ったものが完成度高く出来上がります。

具体例を挙げると、無料プランの線引きを最初は「Slack連携だけ無料、他のサービスは有料」に設計していました。Slackが主力のデータ源なので一見もっともらしい線です。実装も料金ページも決定記録もその前提で書かれ、テストも通っていました。
間違いに気づいたのは自分で触ったときです。GitHubしか繋いでいない人は無料プランでは何も生成できず、サインアップして連携して空の稼働表を見て帰るだけになります。無料で価値を見せ切るのが目的だったのに、その目的を壊す線を引いていたわけです。
線を「サービスの種類は問わず、連携1つまで」に変えました。同時にコミット時刻だけで稼働表を作ると1か月の実働が9時間にしかならないことも実データで分かり、そちらは推定モデルの調整に繋がりました。

AIに任せられるのは作る作業で、何を作るかを間違えないことは任せられない、というのが今のところの実感です。動くかどうかはテストが教えてくれますが、正しいかどうかは教えてくれません。

まとめ#

search.messagesを使うアプリを配布したい人向けにまとめると下記の通りです。

Marketplaceには掲載できません。search:readが拒否スコープに名指しされています
*:historyでの迂回も潰れています。ガイドラインで禁止され、レート制限も1req/分・15件
Real-time Search APIは掲載できますが、データ保存禁止・ゲスト利用不可・プラン制限があります
内部アプリ方式は現役です。ワークスペースの「Marketplaceのみ許可」設定でも止まりませんし、レート制限強化の対象外です

作ったものはこれです。SlackやGitHubの活動ログから日別の稼働開始・終了・休憩・実働を推定して稼働表の下書きを出します。常駐先に監視エージェントを入れられない環境でも使えて、過去の月にも遡って生成できます。

https://w.doany.io

サイトをAstro + k3sで作り直した話

Wed, 29 Jul 2026 00:00:00 GMT

このサイトは元々HUGOで作り、その後Next.js(tailwind-nextjs-starter-blog)で運用していましたが、このたびAstro製のテーマFuwariに全面移行しました。
せっかくなので現在の構成を最初から最後まで書いておきます。

saicaca

fuwari

✨A static blog template built with Astro.

全体像#

1
記事 (Markdown)
2
  ↓ pnpm build
3
Astro → dist/ + Pagefind の検索インデックス
4
  ↓ docker build (multi-stage)
5
node:24-slim でビルド → caddy:2-alpine に dist/ だけ載せる
6
  ↓ GitHub Actions
7
ghcr.io へ push → k3s のマニフェストを自動で書き換えてコミット
8
  ↓ ArgoCD が Git を監視して同期
9
k3s + Traefik（Let's Encrypt / DNS-01）→ Cloudflare → 読者

サーバーサイドのアプリケーションは一切動いておらず、配信されているのは完全に静的なファイルだけです。

NOTE
2026年10月追記その後パッケージマネージャをpnpmからBunに替えたので、ビルドはbun run build、ビルド用のイメージはnode:24-slimではなくoven/bunになっています。ページ遷移もSwupからAstro標準のClientRouterに置き換えました。それ以外の流れは変わっていません。最新の構成はリポジトリを見てください。

ビルド#

Astroなので出力は静的HTMLです。ページ遷移はSwupが担当していてフルリロードなしで切り替わります。

全文検索にはPagefindを使っています。ビルド時にdist/を走査してインデックスを作る方式で、検索用のサーバーが要りません。日本語もちゃんと引っかかります。

NOTE
Pagefindは日本語のステミングには対応していないので語形変化をまたいだ一致はしませんが、個人ブログの検索としては十分実用的だと思います。

配信はCaddy#

イメージは2段構成にしています。ビルド用にnode:24-slim、配信用にcaddy:2-alpine。最終的なイメージにはdist/とCaddyfileしか入っていません。

nginxではなくCaddyを選んだのには理由があります。
AstroはtrailingSlash: "always"なので、/posts/fooへのアクセスに対して/posts/foo/へリダイレクトが常時発生します。nginxはこのリダイレクトURLを$schemeから組み立てるため、TLSを前段のプロキシで終端しているとhttp://へ301してしまうという古典的な罠があります。absolute_redirect off;を書けば回避できますが、知らないと必ず踏みます。
Caddyは相対リダイレクトを返すのでこの問題が最初から存在しません。実際に確認すると下記の通りです。

1
$ curl -sI https://doany.io/posts/truck | grep -i location
2
location: https://doany.io/posts/truck/

ついでにencode zstd gzipの1行でzstd圧縮まで効きます。nginxでzstdを使おうとするとモジュールのビルドが必要なのでこの手軽さはかなり大きいです。トップページで97,465バイト → 16,264バイトまで落ちています。

旧URLからのリダイレクトもCaddyに集約しました。

1
@blogPost path_regexp blogPost ^/blog/(.+?)/?$
2
redir @blogPost /posts/{re.blogPost.1}/ permanent

/blog/* /tags/* /projects /feed.xmlあたりが旧構成のURLなので、全部301で新しい場所へ飛ばしています。

デプロイはGitOps#

ここが個人的に一番気に入っているところで、手元からkubectl applyを叩くことは一切ありません。

mainにpushするとまずGitHub Actionsがイメージをビルドしてghcr.ioへpushします。そのあと同じジョブがdeploy/deployment.yamlのイメージタグをコミットSHAに書き換えてリポジトリにコミットし返します。

1
- name: Update deployment image tag
2
  run: |
3
    sed -i "s#image: ${REGISTRY}/${IMAGE_NAME}:.*#image: ${REGISTRY}/${IMAGE_NAME}:${GITHUB_SHA}#" deploy/deployment.yaml

そしてk3s側にはArgoCDが常駐していてこのリポジトリを監視しています。マニフェストの変更を検知すると自動で同期し、新しいイメージのPodに入れ替わります。
つまりGitがそのままクラスタの状態になっていて、リポジトリを見ればいま何が動いているか分かります。ロールバックしたければgit revertするだけです。

ArgoCD自体もk3sのHelmChart CRDでマニフェストとして宣言してあるので、クラスタを作り直しても同じ手順で戻せます。ログインはEntra IDのOIDCに寄せてローカルのadminアカウントは無効化してあります。
証明書はTraefikがLet’s EncryptからDNS-01チャレンジで取得しています。前段にはCloudflareを挟んでいます。

シークレットの扱い#

コメントシステムの署名鍵やOIDCのクライアントシークレットといった秘密情報は、Gitには置いていません。自前でホストしているInfisicalに入れておき、k3s側の純正operatorがそれを読んでSecretにします。マニフェストには「Infisicalのどのフォルダを見るか」だけが書いてあります。

1
secretsScope:
2
  projectSlug: doa
3
  envSlug: prod
4
  secretsPath: /yosegaki/yosegaki-secrets

以前はSealed Secretsで暗号化したものをコミットしていましたが、値を差し替えるたびに封入し直すのが面倒で、Infisicalの画面で書き換えれば数秒でPodが入れ替わる今の形に寄せました。Gitに全部あるという状態は崩れましたが、参照だけはGitにあるので、何がどこにあるかは追えます。

コメントは自作した#

ここは二転三転したので経緯ごと書いておきます。最終的には自分で書いたものを動かしています。

giscusに関して#

移行の直後はgiscus(GitHub Discussionsを使うやつ)を入れていたのですが、コメントするのにGitHubアカウントが要るのがどうしても引っかかりました。

remark42に関して#

そこでremark42に載せ替えました。Goの単一バイナリでストレージもBoltDBのファイルなので別途データベースが要りません。AUTH_ANON=trueを入れるとアカウントなしで投稿できます。

読者は匿名のままでいい一方、荒らされたときに消す人間は要ります。そこで管理者だけEntra IDでログインする構成にしました。ArgoCDや他の内部サービスと同じアプリ登録を使い回しています。
ここで少しハマりました。アプリ登録がシングルテナントだと既定の/commonエンドポイントは使えません。

1
AADSTS50194: Application is not configured as a multi-tenant application.
2
Usage of the /common endpoint is not supported for such applications.

テナントを明示するオプションが必要なのですが、これはremark42 v1.16以降でしか使えませんでした。アプリ登録をマルチテナント化すれば通るものの、その登録は他のサービスも共有しているので認証範囲を広げるのは避けたい。結局remark42を上げて解決しました。

しばらく使って引っかかったのが見た目です。サイトはTailwindで組んでいるのにコメント欄だけ明らかに別物の顔をしている。
直そうとして分かったのですが、remark42はiframeで埋め込まれます。ホストページのCSSが中に届かないので外から手を入れる余地がなく、公開されている調整点はtheme: light | darkだけです。つまり見た目が気に入らないなら乗り換えるしかありません。

候補の比較#

匿名コメントに対応していて、かつ見た目に手が届くものを並べました。

	実装 / DB	描画	スタイル	管理者認証
Artalk	Go単一バイナリ / SQLite	ホストDOM	CSS変数・ダークモード	パスワード
Isso	Python / SQLite	ホストDOM	完全に自由	パスワード
Comentario	Go / SQLite	Web Component	全切り・差し替え可	OIDC可
Waline	Node.js / 各種	ホストDOM	CSS変数	パスワード
remark42	Go単一バイナリ / BoltDB	iframe	light/darkのみ	OIDC可

Cusdisはアーカイブ済み、Commentoは2022年で放置(Comentarioが後継)、utterancesとgiscusはGitHubアカウント必須なので落としました。

Issoは古いと決めつけていたのですが、これは間違いでした。Issoはdata-isso-css="false"で既定のスタイルシートを丸ごと切れる、自分でCSSを書く前提の作りです。素の見た目が地味なだけで寄せようと思えばどこまでも寄せられます。

数字も見ました。starはIssoが5,293で最多ですがこれは14年分の累積です。実運用に近いDockerのプル数ではArtalkが63.9万、Issoは非公式イメージに分散して合計36万程度でした。Comentarioは3桁で、機能は良いのに前例がほぼありません。

Artalkに関して#

決め手はremark42と運用の形が同じことでした。Goの単一バイナリにSQLiteなので、PVC1つに単一Podという構成がそのまま使い回せます。マニフェストはホスト名とイメージを差し替えるだけで済みました。
iframeではなくホストページのDOMに描画するのでCSSを当てる道が残っていて、実際にCSS変数をサイトの配色に繋いで、それなりに馴染む見た目にはなりました。

代償もありました。ArtalkにはOIDCがないので、せっかく組んだEntra IDでの管理者ログインは失いました。管理画面は共有パスワード1個です。管理者は自分ひとりでやることは荒らしの削除だけなので、そこは飲みました。

使い込むうちに別のところが引っかかってきました。日本語の翻訳が怪しい箇所がいくつかあり、通知センターはiframeで別のCSSが当たるので中国語向けのフォント指定がそのまま出ます。本家にPRは出しましたが、フォントも文言も自分の手の届かないところで決まっているのは変わりません。
スタイルも、変数で寄せられる範囲は寄せたものの、ページ遷移で消えるスタイルシートを入れ直したり、並び替えメニューの隙間を塞いだりと、こまごました上書きが積み上がっていきました。コメント欄の見た目はサイト側で決めたいのに、コメントシステムが自前のCSSを持っているせいで喧嘩している、という構図です。

yosegakiに関して#

それなら自分で書いたほうが早い、となって作ったのがyosegakiです。SvelteKit + Bun + SQLiteで、構成は別の記事に書いた通りいつものやつです。

DAnything

yosegaki

寄せ書き。SvelteKit + Bun + SQLite のコメントサーバ。管理画面なし、どのコメント欄からでもサイト全体の新着と自分宛ての返信が見える

AGPL-3.0

TypeScript

方針は下記の通りです。

スタイルを持たない。同梱のCSSは色を決めず、埋め込み先の文字色を薄めて罫線や背景にするだけなので、ライトとダークにも勝手に追従します。data-css="false"で丸ごと捨てて自分で書くこともできます
管理画面を作らない。管理はコメント欄の中で済ませます。通知パネルからサイト全体の新着と承認待ちが見えて、その場で承認や削除、横断検索ができます。読者にこの入口は見せず、記事のURLに#yosegaki-adminを付けて開いたときだけログインボタンが出ます
管理者の認証はOIDCだけ。パスワード認証は自前で持つと追従が辛いので最初から作っていません。Entra IDのアプリ登録はArgoCDと同じものを使い回し、adminsグループに入っている人だけ通します。remark42で組んでArtalkで失ったものが、ここで戻ってきました
承認なしで即公開。botはCloudflare Turnstileとハニーポットで止めます。Turnstileは必要なときだけ出るので普段は何も見えません

APIはJSONだけを返す作りで、埋め込みスクリプトはその一利用者に過ぎません。画面を作り直したくなってもAPIはそのまま使えます。

1
<div id="yosegaki"></div>
2
<script src="https://yk.doany.io/embed.js"></script>

デプロイはHelmチャートにして、CIがghcr.ioにOCIで押し込んだものを、このブログのdeploy/からHelmChartとして参照しています。SQLiteのファイルをPVCに1つ持つだけなので、運用の形はArtalkのときと変わっていません。
なお乗り換えを決めた時点でコメントは0件でした。移行コストが実質ゼロだったので何度も踏み切れた、という面は正直あります。

購読と支援#

サイドバーに置いてあるやつです。

Ko-fiは公式ウィジェットが外部スクリプトを読み込むのでただのリンクとして実装しました。表示速度に影響せず、テーマのライト/ダークにもそのまま追従します。

NewsletterはButtondownを使っています。当初はRSSフィードを監視して自動配信してくれる機能を使うつもりだったのですが、これが月$9のアドオンでした。年に数本しか書かないブログには少し重い。
一方でAPIは無料プランでも叩けます。やりたいことは記事が増えたらメールを作るだけなので、それなら自分で書けます。そこで記事をpushしたときに動くワークフローを足しました。

1
- name: Collect newly added posts
2
  run: |
3
    # 追加 (A) されたファイルのみ。既存記事の修正では配信しない。
4
    FILES=$(git diff --name-only --diff-filter=A "$BEFORE" "$SHA" \
5
      -- 'src/content/posts/**.md' | tr '\n' ' ')

--diff-filter=Aで新規追加されたファイルだけに絞っているのが要点です。これがないと誤字を直すたびに購読者へメールが飛びます。
作られるのは下書きまでで、送信はButtondown側で内容を確認してから手動で押しています。慣れたら自動送信に切り替えるつもりですが、メールは取り消しが効かないので当面はこのままにします。

上流への追従#

Fuwariはテーマとして使わせてもらっているので本家の更新を取り込みたい。とはいえ毎回手で確認するのは続きません。
そこで月に一度上流を自動でチェックしてPRを出すワークフローを入れました。マージが衝突なく通ればPR、衝突したらPRは作らずIssueで知らせるという挙動にしてあります。

これを成立させるためにGitの履歴も細工しています。このリポジトリとFuwariには元々共通の祖先が1つもなかったので、そのままではgit merge upstream/mainが”refusing to merge unrelated histories”で弾かれます。そこで移行時にFuwariの全コミットの上に自分の変更を1コミット載せる形へ履歴を作り直しました。

1
$ git log --oneline -3
2
xxxxxxx feat: Next.js 版ブログの内容を Fuwari の上に移行
3
6d39b0d chore(deps): bump the patch-updates group ... (#681)
4
415fb97 chore(deps): bump the patch-updates group ... (#648)

GitHub上のフォーク表示にはなりませんが、フォークにしたかった目的(上流追従)はこれで達成できています。

まとめ#

静的サイトなので落ちる要素がほとんどなく、記事を書いてpushするだけで公開されます。コメントだけは自前で面倒を見ることになりましたが、そのぶん読者はアカウントなしで書き込めるようになりました。
ソースコードは全部GitHubで公開しています。構成に関して気になる点などあればコメント頂けると助かります。

DAnything

blog

doany.io のソース — Fuwari ベースの Astro 製静的ブログ

MIT

Astro

ステーションワゴンを貨物登録して税金を安くしてみた

Wed, 06 Aug 2025 00:00:00 GMT

久しぶりの投稿ですが、最近はウェブ関係とはうって変わって車ばかりに現を抜かしております。
その関係で先日スバルレガシィ(3ナンバー)を貨物登録(1ナンバー)してきましたので、その方法等を書いていこうと思います。

NOTE
2026年9月追記この記事に書いた手順を自分でも毎回なぞるのが面倒になったので、仕入れから販売までを工程にした台帳を作りました。トドロクといいます。最大積載量を決めるときに使っていた重量分布計算のexcelもウェブに置いたので、後述の重量分布計算書から使えます。

貨物登録とは#

まず貨物登録とはなんぞやという話ですが、自動車検査証(車検証)に用途という項目があります。ここの項目を乗用から貨物に変更して適用される税区分を変更しようというものです。
詳細な税制度に関してはここでの説明は省きますが、今回貨物登録した車両では下記の通り税金が変わります。(2026年10月3日現在。旧の重量税, 自賠責は24ヶ月分を2で割っています。自賠責は2026年11月1日始期の契約からの基準料率です。)

	旧	新
自動車税	51,750	8,800
重量税	22,800	8,200
自賠責	9,280	17,930
合計	83,830	34,930
差額	0	-48,900

上記の通りかなり安くなりますが、いくつかデメリットもあります。
大きなものだとETCの利用料金区分が普通から中型になり、料金があがります。どれくらい乗ると差額の元が取れなくなるか、新東名(普通区間)で計算してみます。NEXCOの料金は(ターミナルチャージ150円＋24.6円×距離)×車種の比率×1.1(消費税)で、中型は普通の1.2倍、100kmを超える分は長距離逓減で安くなります。上の差額48,900円を1kmあたりの差で割ったものが、元が取れなくなる年間の高速の走行距離です。

1回の距離	普通車	中型車	差	1kmあたりの差	元が取れなくなる年間距離
50km	1,518円	1,822円	304円	約6.1円	約8,100km
100km	2,871円	3,445円	574円	約5.7円	約8,500km
200km	4,900円	5,881円	980円	約4.9円	約10,000km
300km	6,795円	8,154円	1,359円	約4.5円	約10,800km

1回の距離が長いほど逓減が効いて差が縮みます。年間8,000km以上高速を走るような使い方でなければ問題はありません。
ただし休日割引(3割引)は普通車と軽だけで中型は対象外なので、土日祝に乗ることが多いと差が広がります(深夜割引は中型も対象です)。

1回の距離	普通車(休日割引)	中型車	差	1kmあたりの差	元が取れなくなる年間距離
50km	1,063円	1,822円	759円	約15.2円	約3,200km
100km	2,010円	3,445円	1,436円	約14.4円	約3,400km
200km	3,430円	5,881円	2,450円	約12.3円	約4,000km
300km	4,756円	8,154円	3,397円	約11.3円	約4,300km

もう一つが、車検が一年に一度になることです。こちらは年に一回検査手数料を払う費用が増えますが、たかだか2,600円程度です(2026年4月改定後の普通車の持込検査の手数料)。車検をディーラーやショップに預けている方もいるとおもいますが、日本車でしたらほとんどメンテナンスなんてしなくても車検はとおります。そもそもこの記事を読みに来ている時点で維持費を節約したい方だと思うので、維持費を抑えたいなら自分で整備道具を買ってネットで検索して車を維持するための最低限のメンテナンス方法ぐらいはぐぐりましょうそれができないならおとなしくディーラーの言いなりでお金を払いましょう。そのためのサービス料です。

貨物登録の流れ#

車庫証明の取得#

こちらは貨物登録には関係ないのですが、車両の名義を変更するのに必要です。
今回の場合下記書類を私が借りている駐車場の場所の管轄の警察署に提出しました。管轄警察署等は各県警によってホームページなどで公開されています。無い場合は直接電話して聞きましょう。

自働車保管場所証明申請書(2通(キャッシュレス等で印紙が無い場合は1通))
保管場所の所在図・配置図

上記2種類の書類は下記のページ内のXLSXファイルをパソコンで編集して提出しています。手書きである必要はありません。
保管場所証明申請手続

保管場所使用承諾証明書

こちらに関しては要件(貸主、借主、契約日、契約満了日など)を満たしていれば駐車場の賃貸契約書等で可能な場合があります。
自分はいつも駐車場の賃貸契約書のコピーで申請しています。自分の契約書が使えるかどうかの確認は警察署に問い合わせてみるといいでしょう。

参考: 保管場所（車庫）の要件と使用権原書面

仮ナンバーの取得#

今回通した車ですが、購入時にすでに一時抹消されていたため仮ナンバーを借りにいきました。こちらがないと車両を車検や車検整備のために回送することができません。
仮ナンバーを借りるためには自賠責保険の加入が必要なのですが、今回購入した車がすでに自賠責が切れていたため商品自動車の契約で5日間だけ加入しました。
以前は抹消した状態の車種で1か月で自賠責が発行できたのですが、自賠責保険規制強化があったらしく現在は仮ナンバーを借りるという用途の場合商品自動車という形で5日間の契約しかできないようです。
また、自賠責代理店によっては商品自動車の契約の取り扱いが無い場合があります。陸運局事務所の敷地内や近くにある行政書士法人や、保険会社の支社などであれば確実に契約できます。カー用品店等では取り扱いがありませんでした。
自賠責に加入したら最寄りの市役所や仮ナンバーの貸し出しを行っている支所等に向かい仮ナンバーの貸し出し申請を行います。このとき最大貸し出し期間が5日なので上記の車庫証明の発行と後ほど記載する事前審査が完了してから借りに行くのをおすすめします。自分も順番を間違えて5日が切れかけたことがあるので、トドロクの工程にはこの順番と各窓口の持ち物、現金がいる箇所を入れてあります。

貨物登録の為の改造#

貨物として認定される基準#

まず自動車等はどのようにして用途ごとの検査基準を設けているかというと、国土交通省からの政令によって決められています。
道路運送車両法で定められているんじゃないのという疑問を持つ方がいるかと思いますが、道路運送車両法には大まかな内容しか書かれておらず、その内容の解釈などを別途政令で定めています。
時代によって自動車の技術などの入れ替わりは激しいのでこのような形態を取っているというのが建前ですが、結局は関係各所とよろしくやるための制度だと思います。
貨物自動車として検査に通すための基準は下記の様な内容になります。政令から抜粋して平易な表現に書き換えています。

積載設備の床面積が1m2以上あること
乗車設備の床面積より積載設備の床面積が大きいこと
乗車設備の乗員重量より積載重量のほうが大きいこと
物品を積み下ろしする開口部が縦横800mm*800mm以上かつ投影面積が0.64m2以上であること
乗員と積載設備との保護仕切りがあること

NOTE
乗車設備とは2列目以降のことです運転席がある一列目は含みません

参考: 自動車の用途等の区分について（依命通達）

この政令に書かれていることの他NALTECが別途審査委事務規定というものを定めており、政令に書かれていない箇所に関してどう扱うかを明記しています。
国でも無い機関が勝手に法律、政令を解釈していいのかという疑問をいだきますが、節約のために飲み込みましょう。
下記が貨物登録するにあたって追加の条件となる規定です。不要な部分はカットしています。

第 4 章自動車の検査等に係る審査の実施方法
4-17 貨物自動車の審査
4-17-1 用途の判定
（2）乗用自動車（車体の形状が箱型、幌型又はステーションワゴンのものに限る。）として認証を受けた四輪以上の指定自動車等及びこれらの自動車に対し「指定自動車等と関連」に区分される並行輸入自動車の乗車人員の携帯品の積載箇所は、用途区分通達における物品積載設備とは判断しない。
ただし、車体の形状がステーションワゴンのもの（ステーションワゴン以外の自動車であるが別添 3「並行輸入自動車審査要領」6.2.7.を準用した場合にステーションワゴンと分類できるもの又は幌型の自動車であって座席後方の幌が車両の最後尾附近まであるものを含む。）に限り、後部座席等の取外し（座席定員の設定が複数ある状態で認証等を受けたものについて、後部座席等の取外しを行った状態のものと同様な状態で認証等を受けたものを含む。）又は床面への格納固定を行い、これによってできた床面及び当該床面と連続した乗車人員の携帯品の積載箇所については物品積載設備とするものとする。参照: 第4章自動車の検査等に係る審査の実施方法

上記を要約すると下記の様になります。

箱型、幌型、ステーションワゴンの最初からついてる荷物置き場は用途区分通達における物品積載設備とは判定しません。
ステーションワゴンもしくは並行輸入自動車審査要領6.2.7.を準用してステーションワゴンと分類できるものは座席の取り外しや収納などをしてできたスペースと最初からあった荷物置き場を合計して物品積載設備とみなす。

実際の改造箇所#

上記要件を満たすために今回行った改造を書いていきます。

物品を積み下ろしする開口部が縦横800mm*800mm以上かつ投影面積が0.64m2以上であること

こちらに関してはメジャー等で計って800mm以上あれば概ね問題ありません。この時荷室の高さではなく開口部の高さなのに注意してください。

積載設備の床面積が1m2以上あること
乗車設備の床面積より積載設備の床面積が大きいこと
乗車設備の乗員重量より積載重量のほうが大きいこと

今回は2列目シートの右側を倒した状態で固定(NALTEC事務要領に格納固定とあるので固定が必要です)し荷室面積を増やすことにしました。
固定の方法ですが、ヘッドレスト用の穴にボルトをいれチェーンを繋ぎ座席の下にある座面を固定するストライカーとそのチェーンをつなげて固定しました。外すのが容易ですが、一般的にはこの状態でも固定と言えると思います。
また、検査員によっては平床であることを言ってくる検査員が居ますが法律、政令上平床である必要はありません。
先ほど参考にも記載した自動車の用途等の区分について（依命通達）の注2(2)にタイヤえぐり、蓄電池箱等の占める面積は、物品の積載に支障がない限り物品積載設備の床面積に含めるものとする。という記載があります。
こちらを読み解くとタイヤえぐり等の湾曲部が存在する箇所であっても物品の積載に支障が無い限り積載面積とするという風に書かれています。物品というのがここでは定義が記されていなく砂利などの可能性もあるため平床にしなくても問題ないと解するのが妥当だと思います。

乗員と積載設備との保護仕切りがあること

100均などで売っている棚に使うような金網を買ってきて90度曲げて倒した座席の下に差し込みました。
検査を通す際検査官にボルトなどで固定していないと指摘されたのですが、その際自分はボルトで固定されていてもボルトを回せば外れるので構造的に優位な差はありませんよね？と返したところその検査官はブツブツと言いながらどこかに消え検査が無事通りました。
またそもそも保護仕切りに具体的にどういった固定方法が必要かなどは指定されてないので一般的なバンなどに付いているつっかえ棒のようなものでもいいはずです。
このようにNALTECが行う保安基準適合検査とは、検査官の恣意的な判断が多く検査当日は、実際の政令や理論をしっかり理解し検査官を言い負かせる様になっておいた方が良いです。
そもそもNALTECの職員は道路運送車両法にある通り基準適合性審査結果を書面をもって国土交通省に通知することとなっています。つまり道路運送車両と国土交通省政令に沿って作成された事務要領などに反する内容を審査結果に記載した場合虚偽有印公文書作成に当たる可能性があります事実過去に起訴猶予になりましたが、摘発事例があります。
そういった話をしても埒が開かない場合、検査処分に関しては行政行為の一部だと思いますので、審査請求等も手だと思います。

最大積載量に関して#

貨物登録するにあたって下記のような規定があります。また前記の部分で乗車設備の乗員重量より積載重量のほうが大きいこととあったと思います。
また、乗車設備とは前席を除く箇所と政令に規定がありさらには積載量は50kg単位での計算とするNALTECの規定があります。
総合すると100kg以上で同一類別区分中の最大の車両総重量を超えない範囲となります。
今回の場合座席を格納固定しただけなため同一類別区分中の最大の車両総重量(これはメーカーかNALTECに問い合わせればわかります)を超えてしまう場合があります。
そのためスペアタイヤなどの取り外しが必要になります。それでも足りなければ車載工具やラゲッジボード、カーナビ類内装等外してみてください。

オ指定自動車等のうち、車両総重量及び軸重の許容限度が明確でないものにあっては、同一型式の類別区分中の最大の車両総重量を超えない範囲内で指定する。カアからオまでに規定する自動車以外の自動車にあっては、取外した乗車設備分の定員数に55kgを乗じた重量を超えない範囲内で指定する。参照: 7-124、8-124 最大積載量

今度は下記規定を見てみてください産出される物品の積載量のうち最大のものとするこちらの記載を根拠に積載量を総重量のうち最大で取るようにNALTECから言われます。
ここで問題になるのは積載を最大に取った結果車両総重量が2トンを超えてしまうことがあるということです。2トンを超えると重量税が高くなるためなるべく軽くなるように収めたほうが良いと思います。
例として仕様上の最大車両総重量が2040kgで測定結果車両重量が1895kg+100kg=1995kgの場合と1890kg+150kg=2040kgの場合を例に出すとわかりやすいでしょうか。
この場合軽くしすぎてしまうと重量税が増えてしまうため微妙な調整が必要です対外はラゲッジボードの有無や内装部品の有無で調整できます。
この辺の計算は自分用に作っていたexcelをウェブに置いたので重量分布計算書を使ってください。前後の軸重、ホイールベース、残す座席の位置、積載量、タイヤのLIを入れると車両総重量と類別から取れる積載量の上限(50kg単位)が出ます。ついでに積載時の前輪荷重割合(20%を切ると通りません)とタイヤの負荷率も見ています。判定まではログインしなくても見れます。
まだ実現可能か未検証ですが、最大車両総重量が2090kg等どう頑張っても2トンを超えてしまう車両は一回2トン超えで登録し、座席の完全な撤去や内装部品の取り外しで重量を軽くした場合総重量2トン以下にできるのではないかと考えています。

（1）自動車の最大積載量は、本章の規定に適合して安全な運行を確保し、及び公害を防止できる範囲内において積載することができるものとして、（2）から（11）までの基準に基づき算出される物品の積載量のうち最大のものとする。

事前審査#

2025年4月時点で規定が改正され、一部構造変更などで事前審査が不要になる旨が明確化されました。
今までの規定でも読み方によってはステーションワゴン->バンなどの場合は事前審査が不要な様に読めますが、おそらく各地域のNALTEC事務所ごとに解釈の違いがあり、問題になるのを避けるための改正だと思われます。
そのためこの章は不要になりますが、また今後書類審査が必要になる可能性も0ではないため残しておきます。
審査事務規程の一部改正について（第63次改正）

2024年10月28日より書類提出がオンラインでできるようになりました。ただし一部書類はこちらで用意してからアップロードする方式なので書類を一式用意してから申請を行うことになります。
審査の回答まで提出してから最大で15日かかります。ですので車庫証明などを発行してしまった場合早めに提出したほうがいいです。(車庫証明の有効期限は1か月程度)また自分の場合は書類提出した際に事前に車庫証明の有効期限が近いことを伝えると早く処理していただけました。

提出手順#

こちらのサイトでアカウントを作るログイン->アカウント登録で作れる
アカウントを作りログインしたら新規検査届出をクリック
届出の作成をクリック
下記の通り選択、記入し次へをクリック
1. 届出方法選択: 個別届出
2. 附則: 技術基準等の審査を要する自動車、自動車予備検査証の交付を受けた自動車又は使用の過程にある自動車若しくは特定の大型特殊自動車
3. 区分: 3.2.（1）技術基準等の審査を要する自動車
4. 届出先: 検査を受ける検査事務所を選択してください
5. 車名、型式、車体番号: 車検証の通り記入してください
新規検査等届出書（第１号様式）（その１）は下記の通り記入する
1. 類別区分番号又は車両仕様記号: 類別区分番号を選択入力欄に車検証に記載のある類別区分番号を入れる
2. 当該型式・類別区分番号の指定自動車等に対して変更している自動車の構造・装置
  1. 構造・装置の変更有無: 有を選択
  2. オプション: （記入欄のとおり）を選択
  3. 記入欄: 下記の通り入力(現在の仕様に合わせて適宜書き換えてください)
```
1
乗車定員の変更（5人→3人）2列目右側座席固定
2
用途変更（乗用→貨物）
3
車体形状の変更（ステーションワゴン→バン）
```
  1. 騒音防止装置に係る構造・装置の変更有無: 無
  2. 騒音防止装置に係る過回転防止装置の有無: 無
新規検査等届出書（第１号様式）（その２）にアップロードする書類はNALTECが配布するwindowsアプリケーションで作成できます。下記リンクからzipファイルをダウンロードしbinフォルダ内のInitPreEntry.exeを実行すると起動します。
- 新規検査届出書第一号様式2
- 入力する内容は実際に車両を測定するかメーカーに問い合わせて諸元表をもらえばできます。
- 計算が要る部分に関しては、NALTECの事務所で重量分布計算書というものがもらえる場合がありますが、場所によって対応が異なるようです。前述の重量分布計算書で出した数値をそのまま転記してください。
自動車を特定する書面は登録識別情報等通知書のスキャンデータをアップロードする
諸元表又は車両諸元要目表はメーカーに問い合わせた諸元と外観四面図をアップロードする
技術基準等への適合性を証する書面は「保安基準各条項の技術的要件の適合性に関する書面」をアップロードしてください。内容は自分の車に合った計算をして記載してください。
- ※2026年10月追記以前ここで配布していたサンプル入力済みのwordファイルは公開を終了しました。今はトドロクの構造等変更の画面で、台帳に入れた車両の値からこの書面と外観四面図を作れます。
その他書面には下記をアップロードしてください
- 横からの画像に車両全長を記載
- 前方からの画像に全幅を記載
- 後方からの画像に全高と荷室の全高と開口部の高さ
- 座面を固定および荷室との仕切り壁がわかる画像

キャッシュレスの登録#

2023年1月より検査登録に必要な支払いをキャッシュレスで行えるようになりました。
下記より支払い情報の登録が行えます。
くるまの保有関係手続お支払い情報登録サービス

支払い情報登録の際手続きの種類を中古新規にしてください。そうしないと後で手続きの種類を変更することができないので、車検証発行の段階で現金で払うことになります。
車検が残っており一時抹消などで税の還付を受けない場合は構造変更を選択してください。
自賠責だけは別になるので自賠責分だけ現金を用意する必要があります。カー用品店等ではカードで自賠責が買えるためそちらで発行するのも手です。
また、ナンバーセンターでのナンバープレート発行費用及び記念所蔵時の穴あけ料についても現金になります。

検査当日#

検査当日までに下記サイトから予約が必要です。予約時検査種別は一時抹消済みであっても構造等変更検査になります。
ただし、場所によっては予約が非常に取りにくいことがあります。
その理由として、一部の事業者が複数台分の予約枠を確保し、当日来なかった車両分だけをキャンセルするという運用をしているケースがあるためです。こうした行為には特にペナルティがないため、予約枠が埋まってしまうことがあります。
また、上記のような運用している事業者は当日予約をキャンセルすることが多いため当日に予約が空くこともあるので当日早朝及び第一ラウンド検査中などに見てみるのも手だと思います。
自動車検査インターネット予約システム

当日の流れですが、大まかには下記のようになります。細かいところは陸運局ごとに違うと思いますので、省略させていただきます。
またキャッシュレスの登録をしなかった場合当日書く書類が2,3枚増えますのでできるだけキャッシュレスでの手続きをおすすめします。下記手順では現金の場合の手続きを省いています。

検査受付書類を印刷するPCが登録事務所の検査受付窓口の近くに在るので、車検証のQRをスキャンして受付書類を出す
通常の継続検査レーンで検査を受ける
審査書類を提出した検査小屋で審査書類をうけとる※事前審査をしてない場合は不要
新規検査用のレーンで車重などを量る
普通貨物で自賠責を加入する
中古新規および構造変更どちらの場合でも一号様式に記入し登録窓口に提出する
税申告書を記入し税申告窓口に行き書類を提出する
ナンバプレート窓口でナンバープレートを受け取る(元々のナンバーが付いている場合は外してから)
ナンバープレートを取り付けし封印をしてもらう

まとめ#

行政手続きや政治、法律のプロではないのでブログの内容や私の考えに間違いなどあるかもしれませんが、その辺りどしどしコメント頂けると助かります。冒頭にも書きましたが、この記事の流れに前後の仕入れと販売を足した8工程をトドロクの台帳にしてあります。次に通す人は台帳から始めると、持ち物と現金の要る箇所、かかった費用が一か所に残るので楽だと思います。今回節税するために貨物登録を行いましたが、そもそも現在の税制はあまり受益者負担になっていなのではないかと言うような疑問やNALTECや警察組織の思惑ばかりで本当に安全な交通社会に寄与できるような規制になっていないのではないかなどの疑問が私の場合は残りますが、その辺り皆さんはどう思われますでしょうか。

Mercedes NTG ATAロック解除メモ

Sat, 25 May 2024 00:00:00 GMT

下記で紹介されているxboxhdmを使う有名な方法があるがxboxhdm v1.9はsata接続に対応していないため4.5のsata接続以降では利用できない
NTG4.5 / 4.7 HDD imaging project
fujtoolを利用する方法等が紹介されているがそもそもwindows用のsmart編集ツールなどで解除できないか調べた
windowsで利用できるusb, sataなどに対応したsmart編集用ツールとしてsmartctlがある、またxboxhdmの最新版v.2.3においてはunlockhdコマンドにsmartctlが利用されている

ならば上記フォーラムに記載のパスワード生成手順と合わせ下記のようなコマンドでロックが解除できるのではないかと予想している

1
./smartctl.exe -s security-unlock,"longUserPasswordFromMelcoCalculator" /dev/sdb
2
./smartctl.exe -s security-disable,"longUserPasswordFromMelcoCalculator" /dev/sdb

OSSで移転登録してみた

Mon, 01 Jan 2024 00:00:00 GMT

前回に引き続き車ネタです。

NOTE
2026年9月追記この記事のあと中古車店を始めて、自分が申請者になる移転登録は今もOSSでやっています。仕入れから販売までの手続きを台帳にしたトドロクを作りました。この記事に関係するのは2つで、車検証のQRをスマホで読むと後述の車検証情報取込みファイルを出せること、車庫証明を同時申請するときの所在図・配置図を地図の上で描けることです。該当の箇所に追記しています。あわせて2026年9月時点で手順を見直し、変わったところ(保管場所標章の廃止、動作環境、リンク先)も追記しました。

OSSとは#

OSSとはワンストップサービスの略で国土交通省が提供しているインターネット上で移転登録などの自動車に関する登録事務手続きができるサービスです。

通常の手続きとの違い#

最近では自動車ディーラー等が手続きを簡素化したりするために導入しています。通常の手続きと下記のような違いがありますが、個人が使う範囲ではあまりメリットはありません。

車庫証明も同時申請できるため警察署に行く回数が少なく済む
手数料がPay-easy, クレジットカード等で納付可能なため手続きを管轄している陸運局がキャッシュレス決済に対応していなくても現金以外で支払いできる。
電子証明で申請する場合、自分の印鑑証明が不要なため印鑑証明代が節約できる
紙の書類を書かなくていい(譲渡証明書、委任状を除く)
電子車検証を用いて車両情報の記入時間を減らせる

実際の流れ#

OSSを導入しているディーラーで購入した場合譲渡証明書等が電子登録されている場合がありますが、希有なケースな為今回は紙の委任状と譲渡証明書を受け取った場合で話をすすめます。

事前準備#

OSSブラウザアドオン#

OSSを使うためのブラウザアドオンのインストールが必要です。
下記からアドオンとchrome用の拡張機能をインストールしてください。
自分の場合microsoft edgeを使用しましたが、edgeでも変わりません。
OSSブラウザアドオン
 chrome用拡張機能

NOTE
2026年9月追記動作保証はWindows 11(24H2・25H2)のEdgeかChromeだけになっています。Windows 10は対象外です。動作環境

マイナンバー関連#

一部の申請には、マイナンバーカードの電子署名機能が必要です。PCにカードリーダーを接続してマイナンバーカードを読み取る場合は利用者クライアントソフトをスマホで読み取る場合はマイナポータルアプリをインストールしてください。
今回はPCの場合で話を進めます。

利用者クライアントソフトは下記からインストールできます。利用者クライアントソフトのダウンロードからダウンロードしてください。ブラウザ利用版のインストールは不要です。
公的個人認証サービスポータルサイト

マイナポータルアプリは下記から。
android
iOS

キャッシュレス決済登録#

クレジットカード等のキャッシュレス決済を利用したい場合、下記から登録を行う必要があります。
お支払い情報登録サービス

電子車検証読み取り#

電子車検証を利用して入力を省略できます。
車検証閲覧アプリ

NOTE
2026年9月追記 iPhone・Android版も出ていて、スマホでも車検証情報取込みファイルを出せるようになりました。閲覧アプリの案内

2026年9月追記閲覧アプリで出せる車検証情報取込みファイルは、トドロクでも出せます。車検証のQRをスマホで読んで1台登録すると、車両情報の画面から同じ形式のJSONが落とせます。車検証を車に戻してしまったあとでも作れます。

受任者情報ファイルの作成#

電子で委任状を作成するのですが、その前に受任者情報ファイルという自分の情報を作成する必要があります。

受任者情報ファイル作成
上記ページの申請開始をクリック
ICカードを選択
カードリーダーを利用を選択
電子署名用パスワードを入力してマイナンバーカードを読み取る
自動車の車台番号をご存知ですか。の項目でいいえを選択(ここでいいえを選択すると申請する車に制限なく申請に使えるようになります)
受任者情報ファイルの保存

委任状の作成#

紙の委任状を受け取っていると思いますが、電子でも作成する必要があります。
下記リンクから作成できます。
委任状作成

相手方電話番号がわからない際自分の電話番号を入れましたが、問題ありませんでした。
受任者情報ファイルのところには先ほど作成したファイルを指定してください。
こちらでは車体番号を入れる必要があります。
所有者・使用者の別は旧所有者を選択してください。(ここを正しく選択しないと申請できません。)

移転登録#

下記から移転登録の申請をします。
移転登録(※2026年9月追記ページの場所が変わっていたのでリンクを直しました)

譲渡証明書の種類は紙を選択してください。
すでに取得済みの保管場所証明書を利用した申請ですか。の欄でいいえを選択すれば車庫証明も同時に申請できます。
- ※2026年9月追記同時申請には所在図・配置図の画像添付が要ります。手書きをスキャンしてもいいですが、トドロクなら住所から航空写真を出して駐車枠と道路の幅を描き、OSSの条件(JPEG、1024×768まで、100KB程度)に合わせた画像で落とせます。審査で見られる点(使用の本拠から2km以内、車が枠に収まるか)は車庫証明を自分で申請する方法にまとめました。
委任状のところでは先ほど作成したものを選択してください。

書類の提出#

電子で申請すると言っても委任状と譲渡証明書は紙の原本の提出が必要です。
OSSでの申請完了後陸運局に行って提出する必要があります。
陸運局によって違うと思いますが、自分の行った習志野の場合はOSS専用の受付窓口がありそちらで提出しました。

手数料の納付#

ステータスが更新されるたびにメールが来ます。メールが来たらすぐ確認しましょう。
書類の提出後申請のステータスが更新され保管場所証明手数料納付待ちになりますので、メールに記載のURLから申請が面にログインできるので申請時に決めたパスワードでログインしてPay-easyか対応している金融機関から支払いを行います。
納付後警察内管理番号が発行されますが、そちらを管轄の警察署に電話で伝え保管場所標章を郵送でお願いすることもできるようです。

その後2,3日経つと保管場所標章手数料納付待ちになりますので、同じように納付します。
納付した翌日、検査登録手数料納付待ちになりますので、こちらも同じように納付しますが、納付先が違う関係で対応している金融機関が異なります。Pay-easyはこちらも使えます。

NOTE
2026年9月追記保管場所標章(車庫のステッカー)は2025年4月1日に廃止されたので、標章の手数料の納付は無くなりました。いまは保管場所証明手数料、検査登録手数料、該当すれば自動車税の順です。保管場所証明の手数料は都道府県で額が違います。

保管場所標章と自動車検査証の受け取り#

検査登録手数料を納付した段階で保管場所標章の発行は完了しているので管轄の警察署に受け取りに行きます。

NOTE
2026年9月追記標章が廃止されたので、警察署に受け取りに行く工程は無くなりました。車庫証明の結果はOSSの中で運輸支局に渡るので、受け取りに行くのは陸運局だけです。

その後、陸運局に行き自動車検査証を受け取りに行きます。移転登録の際管轄する陸運局が変更になる場合ナンバープレートの変更が必要なので、車を持って行ってください。
上記の順番はどちらでもいいです先に自動車検査証を受け取りに行っても大丈夫です。

まとめ#

上記が大まかな流れです。紙の書類に関しては陸運局に提出しなければならないため、あまりインターネットを用いてるメリットはないです。更には申請画面の選択項目も煩雑なため手続きにある程度詳しくないと使用するのは難しいと思います。既存の方法をそのままデジタル化しているためこのような仕様なのだと思いますが、個人的には辞めてほしいです。

NOTE
2026年9月追記店として車を売る側になる場合は事情が変わります。2026年1月施行の改正行政書士法で、買主の申請書類を店が作るのは名目を問わず違反になりました。OSSの代理申請も同じです。どこまで店がやれるかは改正行政書士法で中古車販売店ができること・できないことに書きました。

アウディコーディングメモ

Wed, 08 Jul 2020 00:00:00 GMT

CAUTION
以下内容を実行した際車両の破損や車検不適合が発生した際当方は一切の責任を負いません
あくまでも自己責任でお願いいたします。

アウディにてVCDSを用いて電装系の動作のカスタマイズ(俗にコーディングというらしい)を行ったので、手順やカスタマイズできる内容などを紹介していく。

1. VCDSケーブルの準備#

ヤフオクや楽天などでVCDSと検索すればケーブルが出てきますのでそちらを購入すれば問題ありません。

バージョンなどが記載されていますが商品詳細ページに対応車種、年代などが書かれています大体新しめのものを買っておけば問題ありません。

2. PCの準備#

大体ディスクが付属していますのでディスク内にある内容など読んで適宜セットアップしてください。

VCDSのアプリケーションが起動できたら先にAuto-Scanからマップデータを取得して保存しておきます。復元用に利用できます。

3. 設定リスト#

各種カスタマイズするには、車両側OBD2とPC側にケーブルを指してSelect Control ModuleのSelectをクリックします。下記メニュー内での番号になります。車種によっては該当の項目が存在しない場合がありますその場合は別の項目にあるか対応していない可能性があります。
A5B8用です

1
- MMI再起動方法
2
前期 SETUP+ジョイコンの真ん中+右上のボタン同時押し
3
後期 MENU+ジョイコンの真ん中+右上のボタン同時押し
4
長押しはいらないです同時押しがちゃんと認識されてれば話した瞬間再起動します。
5
- グリーンメニュー有効化
11 collapsed lines
6
MMI 2gの場合
7
[07-Bed.Paneel/Display]
8
[Aanpassen-10]
9
[Kanaal 08]  '1'を入力
10
前期: SETUP+CAR同時押し
11
後期: CAR+MENU同時押し
12
MMI 3gの場合
13
[5F-Informatie Electr.]
14
[Aanpassen-10]
15
[Kanaal 06]  '1'を入力
16
メニュー起動方法は同一
17
- クルコンの距離調整画面表示
4 collapsed lines
18
[13-Afstandsregeling]
19
[Aanpassen-10]
20
[Kanaal 07]  値を'1'に
21
MMIにてCAR->ACC内に表示されると思います。
22
- パーキングアシスト解除速度設定
4 collapsed lines
23
[10-Parkeerhulp]
24
[Aanpassen-10]
25
前期  [Kanaal 23]  最大20km/h
26
後期  [Kanaal 233]  最大20km/h
27
- 停車中に内気循環切り替え(外付けではないがパーキングエアコンというらしい)
5 collapsed lines
28
[08-Airco/Verwarming]
29
[Hercoderen-07] longcoding
30
[Byte 01]  [Bit 4]  有効化
31
グリーンメニュー表示->'Car'->'cardevicelist'->'Auxillary heating' 有効化
32
グリーンメニュー表示->'Car'->'carmenuoperations'->'Auxillary heating'この項目を5に
33
- キーアンサーバック有効化&MMI設定表示有効化(盗難防止装置付き車両のみ)
6 collapsed lines
34
[46-Comfortsysteem]
35
[Hercoderen-07] longcoding
36
[Byte 01]  [Bit 2]  有効化
37
[46-Comfortsysteem]
38
[Aanpassen-10]
39
[Kanaal 63]  初期値 40; 44で有効化
40
- 内部監視機能付き警報装置有効化(日本版だと標準装備ではないが後付けした場合)
8 collapsed lines
41
[46-Comfortsysteem]
42
[Hercoderen-07] longcoding
43
[Byte 01]  [Bit 1]  盗難防止装置有効化
44
[Byte 01]  [Bit 2]  ホーンでのアラーム有効化
45
[Byte 01]  [Bit 3]  傾斜計有効化
46
[Byte 01]  [Bit 4]  内部モニタ有効化
47
[Byte 01]  [Bit 5]  リアウィンドウセンサ有効化
48
[Byte 01]  [Bit 6]  アンチロッドモニタリング無線接点有効化
49
- アウトバーンライト有効化
6 collapsed lines
50
130km/hで点灯します日本での車検適合未確認
51
[09-Boordnet]
52
[Hercoderen-07] longcoding
53
上のプルダウンから下記の様な表示のやつを選ぶ
54
'2 -- xxx -- RLS' (Rain and Light Sensor)
55
[Byte 00]  [Bit 0]  有効化

RDS+ECSで定期的にダンプをS3に保存してみる

Thu, 31 Oct 2019 00:00:00 GMT

概要#

AWS にて RDS の定期ダンプを取得したかったので ECS にある cron 的な機能を使ってダンプを定期取得する設定をしてみた
ECS で動かす定期実行用のコンテナのイメージやタスクも管理を自動化してみた
今回 postgres が対象です mysql 等は適宜 dockerfile を変更してください

前提条件#

AWS のアカウント取得済み
RDS 構築済み
bitbucket のアカウント取得済み

準備#

IAM ユーザーの作成#

今回 bitbucket pipeline からのデプロイとダンプデータ S3 へのアップロード用にユーザーを作成する。
通常はデプロイと S3 でユーザーを分けた方がいいのだが今回は管理コストの面で一つで作成します。

IAM を開き左メニューにあるユーザーを開くその後ユーザーの追加を開くと下記の様な画面になる
ユーザー名を適宜入力,アクセスの種類をプログラムによるアクセスに制限

AmazonECS_FullAccess, AmazonEC2ContainerRegistryFullAccess, AmazonS3FullAccessを選択(今回 CLI で同一ユーザーを使いたかったので広に権限取ってあります。わかる人は適宜絞ってください。)

その後特に設定項目はないのでユーザーの作成まで進む
最後にこのような画面が表示されるのでアクセスキー ID とシークレットアクセスキーをメモしておいてください。シークレットアクセスキーに関しては追加発行できますが二度と再表示できないので絶対にメモしておいてください。

IAM ロールの作成#

タスクを実行するためのロールだが自動で作られるものではあるのだが ECS を全く使っていない場合は作成されていないので手動で作成する。
(ecsTaskExecutionRoleと最後に付くロールが既にある場合はその ARN をメモしておいてください)
IAM を開き左メニューにあるロールを開くその後ロールの作成を開くと下記の様な画面になる
Elastic Container Serviceを選択次にElastic Container Service Taskを選択次へ

AmazonECSTaskExecutionRolePolicyを選択その後特に設定項目はないのでロールの作成まで進む

作成が完了したら元の画面に戻ってくるので先ほど作成したロールを開く下記画面のロール ARNをメモしておいてください。

バケットの作成#

特別設定する項目はありません。適宜設定の上作成しておいてください。
その際作成した名前をメモしておいてください。

ECR リポジトリの作成#

こちらも特別設定する項目はありませんが、パイプラインでタグを上書きする関係上タグのイミュータビリティは無効化しておいてください(デフォルトで無効)
作成した後 URI のカラムにある URL みたいなものをメモしておいてください。

bitbucket でリポジトリの作成#

いつも通りリポジトリを作成してください。
ローカルで下記の通りファイルを作成してください。

1
~/
2
 ├ .pgpass
3
 ├ bitbucket-pipelines.yml
4
 ├ Dockerfile
5
 └ docker-entrypoint.sh

.pgpass は postgres にパスワードを省略してアクセスするためのパスワードファイルですダ下記の通り記述してください。

1
hostname:port:database:username:password

bitbucket-pipelines.yml は bitbucket のパイプラインの定義を記述するファイルです下記の通り記述してください。
execution-role-arn のところに先ほどメモしたロール ARNを記入してください。

1
# enable Docker for your repository
2
options:
3
  docker: true
4

5
pipelines:
6
  default:
7
    - step:
8
        name: build-push
9
        image: atlassian/pipelines-awscli:latest
10
        deployment: test
11
        caches:
12
          - docker
13
        script:
14
          # aws login
15
          - aws ecr get-login-password --region ${AWS_DEFAULT_REGION} | docker login --username AWS --password-stdin ${AWS_REGISTRY_URL%%/*}
16
          # docker
17
          - export BUILD_ID=$BITBUCKET_BRANCH_$BITBUCKET_COMMIT_$BITBUCKET_BUILD_NUMBER
18
          - docker build -t ${AWS_REGISTRY_URL}:$BUILD_ID -t ${AWS_REGISTRY_URL}:development .
19
          - docker push ${AWS_REGISTRY_URL}
20

21
    - step:
22
        name: deploy
23
        image: atlassian/pipelines-awscli:latest
24
        deployment: production
25
        script:
9 collapsed lines
26
          - export BUILD_ID=$BITBUCKET_BRANCH_$BITBUCKET_COMMIT_$BITBUCKET_BUILD_NUMBER
27
          - export IMAGE_NAME="${AWS_REGISTRY_URL}:$BUILD_ID"
28
          # ECS variables
29
          - export ECS_CLUSTER_NAME="${BITBUCKET_REPO_OWNER}"
30
          - export ECS_SERVICE_NAME="${BITBUCKET_REPO_SLUG}"
31
          - export ECS_TASK_NAME="${BITBUCKET_REPO_SLUG}"
32
          # Create ECS cluster, task, service
33
          - aws ecs list-clusters | grep "${ECS_CLUSTER_NAME}" || aws ecs create-cluster --cluster-name "${ECS_CLUSTER_NAME}"
34
          # Updating the existing cluster, task, service
35
          - export TASK_VERSION=$(aws ecs register-task-definition
36
            --family "${ECS_TASK_NAME}"
37
            --execution-role-arn ""
7 collapsed lines
38
            --network-mode "awsvpc"
39
            --requires-compatibilities "FARGATE"
40
            --cpu "256"
41
            --memory "512"
42
            --container-definitions "[{\"name\":\"${ECS_TASK_NAME}\",\"image\":\"${IMAGE_NAME}\",\"logConfiguration\":{\"logDriver\":\"awslogs\",\"options\":{\"awslogs-group\":\"/ecs\",\"awslogs-region\":\"${AWS_DEFAULT_REGION}\",\"awslogs-stream-prefix\":\"${ECS_TASK_NAME}\"}}}]"
43
            | jq --raw-output '.taskDefinition.revision')
44
          - echo "Registered ECS Task Definition:" "${TASK_VERSION}"

NOTE
2026年10月追記ログインに使っていたaws ecr get-loginはAWS CLI v2で削除されたので、aws ecr get-login-passwordをdocker loginに渡す形に書き換えました(v1でも1.17.10以降なら動きます)。AWS CLI v2の変更点
またatlassian/pipelines-awscliイメージは非推奨になっていて、amazon/aws-cliへの移行が案内されています。Docker Hub

Dockerfile は ECS でデプロイする用のコンテナ定義です下記の通り記述してください。
補足がある箇所は先ほどメモしたものから適宜いれてください。

1
FROM alpine
2

3
RUN apk --no-cache add postgresql-client aws-cli
4
ENV AWS_DEFAULT_REGION ap-northeast-1
5
ENV AWS_ACCESS_KEY_ID {アクセスキーID}
6
ENV AWS_SECRET_ACCESS_KEY {シークレットアクセスキー}
7
RUN mkdir dump
8
WORKDIR /root/dump
9
ADD .pgpass /root/.pgpass
10
RUN chmod 0600 /root/.pgpass
11
ADD docker-entrypoint.sh /root/docker-entrypoint.sh
12
RUN chmod +x /root/docker-entrypoint.sh
13

14
CMD ["/root/docker-entrypoint.sh"]

NOTE
2026年10月追記最近のAlpineではpip3 installでシステムのPythonにパッケージを入れられない(externally-managed-environment で止まる)ので、AWS CLIはAlpineのパッケージ(aws-cli)から入れる形に直しました。

docker-entrypoint.sh は docker 起動時に実行するコマンド群ですいわゆる cron の中身です。
補足がある箇所は先ほどメモしたものから適宜いれてください。
保存構成的には最初のプレフィックスが削除周期次に DB 名最後にファイルの接頭辞が今回はダンプの周期を入れています。

1
#!/bin/sh
2

3
mkdir -p yearly/{DB名}
4
pg_dump -Fc -h {DBのホスト} -U {ユーザー} {DB名} > yearly/{DB名}/weekly-`date "+%Y%m%d_%H%M%S"`.custom
5
aws s3 sync . s3://{S3のバケット}

準備が完了したらいつもの通り先ほど作成したリポジトリにプッシュしてください。

bitbucket での pipeline の準備#

先ほどプッシュしたリポジトリを bitbucket で開く
設定->PIPELINES->Settings に進みEnable Pipelinesを有効にする

次にRepository variablesを開く
下記の通り先ほどメモしたものから設定をする。

デプロイと cron の設定#

デプロイの実行#

引き続き bitbucket の画面で再度メニューからPipelinesを開く次にRun pipelineをクリックし下記の通り選択してRunをクリック

完了すると下記の様になるのでパイプラインが完了するのを待つ

次回以降ブランチに変更が入る度自動で実行されます。

AWS でスケジュールの作成#

AWS ECS 上でリポジトリオーナー名でクラスタが作成されているのでそのクラスタを開く(クラスタ名が書かれているところをクリックすると開きます)。

タスクのスケジューリングのタブを開き作成をクリック

NOTE
2026年10月追記現在のECSコンソールでは画面が変わっています。定期実行はAmazon EventBridge Schedulerでスケジュールを作り、ターゲットにECSのRunTaskを選ぶ形が案内されています。cron式もEventBridge Schedulerのものを使います。Using Amazon EventBridge Scheduler to schedule Amazon ECS tasks

実行間隔等を設定しターゲットの部分は今回FARGATE用にタスクを作成したので起動タイプをFARGATEを選択タスク定義のファミリーはリポジトリ名と同名のタスクがあるのでそれを選択する。VPC とセキュリティグループは適宜設定してください。

NOTE
Cron 式を選択したときに躓いたのだが busybox cron 等の cron 式とは違う模様下記を参考にいたしました。
AWS_Cron 式のワイルドカード

GUIを入れたubuntuでネットワークが繋がらない

Fri, 11 Jan 2019 00:00:00 GMT

ubuntu等のlinuxにnetplanでipを固定設定をしていてその後にubuntu-desktopやnetworkmanager等のGUIを入れた際NetworkManagerの管理外となりネットワークが繋がらなかったりGUIから設定できなくなることがあるその際は/etc/netplan/にyamlファイルを作成しNetworkManagerがnetplanを利用できるように設定を書き足せば良い下記の通り設定すれば動くと思われる。

1
network:
2
  version: 2
3
  renderer: NetworkManager

hls.jsのレベル変更で躓いた件

Tue, 18 Dec 2018 00:00:00 GMT

概要#

すごく稚拙の理由だがhls.jsでレベル変更機能(m3u8ファイルの切り替え)で躓いた。

躓いたとこ#

hls.jsにはhls.currentLevelというapiが用意されていてこちらの値を変更することでレベルの変更ができるようになっているのだがこちらにslectを変更した際にoptionの値を導入するという仕様で作成を試みたのだが-1を与えてると再生が止まる状況に陥ってしまった。

1
$('.res>select').on('change', function() {
2
    hls.currentLevel = $(this).val();
3
});

解決方法#

optionのvalueをNumberでキャストすれば治ります。

1
$('.res>select').on('change', function() {
2
    hls.currentLevel = Number($(this).val());
3
});

原因#

val()で取得した値は非明示的に文字になったり数字になったりする-がついた際に文字にキャストされさらにはhls.jsが内部で値チェック等を行っていなかったためエラーなどもでず再生できなくなったと思われる。

まとめ#

かなりレベルの低い内容だったが筆者のレベルが低いのか解決になかなか時間がかかったりする。日本語でこういった情報が溢れていてくれるとありがたい。

磁気ストライプの検証

Sun, 26 Aug 2018 00:00:00 GMT

磁気ストライプカードとは#

磁気ストライプカードとはwikipediaによると磁気ストライプカード（じきストライプカード、英: magnetic stripe card）は、磁性体の帯があるカードで、その中の鉄をベースとした小さな磁性粒子の磁性を変化させることでデータを格納できるもの。とありますが簡単に説明するとみなさんが持っているポイントカードやクレジットカードなどの磁性体を持ったカードのことを言います。

概要#

今回は磁気ストライプの基本的な仕様等の説明、簡単に仕様特定等に行った検証を掲載していく。

仕様#

磁気ストライプ内データ#

まず磁気ストライプ内のデータだがMSR705と付属のソフトウェアを使用し内部データを読み取りネット上の情報等を参考にまとめた。ネット上の情報に関してはこちらを参考にした。

上記が読み取ったデータであるサンプルにはアクティベートを行っていないおさいふポンタを使用した。クレジットカードはTrack1, Track2, Track3がありそれが縦に並ぶような形で配置されています。(※国内で発行されている殆どのクレジットカードはTrack3はありません)磁気ストライプ内の番号に関して上記を例に簡単に解説をつけると下記の通りです。
Track1
B(開始符号)3574001005472095(カード番号)^(区切り符号)MEMBER/OSAIFUPONTA(氏名)
^(区切り符号)2110(有効期限)121(サービスコード)679(cvc1)

Track2
3574001005472095(カード番号)=(区切り符号)2110(有効期限)121(サービスコード)679(cvc1)

サービスコードについて#

先ほどの磁気ストライプ内のデータにあったサービスコードについて解説していくこのサービスコードとは決済端末側に要求しうる動作を決める為のもので数字によって下記の様な意味を持つ。
1桁目
1:国際ブランド
2:国際ブランド&ICチップ搭載
5:国内ブランド
6:国内ブランド&ICチップ搭載
7:プライベート用
9:テスト用

2桁目
0:決済機側で判断
2:イシュアーに問い合わせる
4:二国間協定を除いてイシュアーに問い合わせる

3桁目 0:制限なし&PIN入力要求
1:制限なし
2:物品とサービスのみ
3:ATMのみ&PIN入力要求
4:キャッシングのみ
5:商品とサービスのみ&PIN入力要求
6:制限なし&可能な場合はPIN入力要求
7:物品とサービスのみ&可能な場合はPIN入力要求

検証#

カードの偽造可否や偽造カードの使用可否等の検証を行った。

カードの偽造#

まず結論から言うと偽造は可能であるしかしカード番号や有効期限、CVC2を知っていても偽造は不可能である理由として先ほど説明したCVC1が不明であるためである実はクレジットカードは通常裏面等に記載があるものはCVC2でありこちらはEC決済等に用いられるが磁気ストライプ内のものは店頭決済用のCVC1となっておりこちらは乱数で推測が不可能であるため偽造は不可能である。ではどうやって偽造が可能かと言うと有名な手口ではあるが決済機等に付けるスキミング装置を用いる方法やまた悪意のある加盟店に直接磁気ストライプ内データが盗まれたりした際に偽造カードの作成は可能になってしまう磁気ストライプには書き換え不能な固有データ等が存在しないため磁気ストライプ内のデータを直接抑えられたら終わりなのである。
対策等は近年日本でも増えてきているが決済操作のセルフ化と決済端末等を目視確認することだ。

偽造カードの使用#

こちらも結論から言うと使用可能であるしかし近年のIC対応で使用が難しくなっているのも事実であり理由としては先ほど説明したサービスコードだがこちらの1桁目が2か6である場合ICが要求されてしまい(要求しない決済機もあり)決済ができないまたこちらのサービスコードを書き換えて検証を行ったところ現在のクレジットカードインフラではイシュア側で少しでも違う番号等があると決済できない仕様となっており決済が不能だった。ここで余談だが本検証で分かったことなのだがTrack1にデータがない場合(磁気等を取り去った状態)決済できないがTrack1になんらかのカード情報があった場合決済できたのだがTrack1に如何なるカード情報を入れてもTrack2のカード情報により決済が行われた、また先ほどのサービスコードもTrack2のものが使用される仕様となっていた。
対策としてはカードのIC搭載、決済機のIC対応だ。

まとめ#

以上の通り割と簡単に不正利用ができてしまうことが判明した特に日本国内の決済事情的にはかなり早急な対応が必要な状態だと思われる。

NOTE
2026年10月追記この記事の直前、2018年6月1日に改正割賦販売法が施行され、クレジットカードを取り扱う加盟店にはICカードで決済できる端末の設置が義務付けられています。磁気ストライプをスワイプするだけの端末は置き換えの対象です。割賦販売法の改正に関するお知らせ|JCB

クレジットカード番号の検証

Fri, 27 Jul 2018 00:00:00 GMT

はじめに#

普段目にしているクレジットカードの番号ですがこれにも様々なルールやセキュリティ対策がなされています。今回はそれについて説明していきます。

番号の概要#

まずクレジットカード番号がどのように構成されているかですがクレジットカード番号はISO/IEC 7812にて策定されており、6桁のBIN（Bank Identification Number, 銀行識別番号）もしくはIIN（Issuer Identification Number, 発行者識別番号）+残りの番号はイシュアによって決定されます。

NOTE
2026年10月追記 ISO/IEC 7812-1:2017の改訂でIINは8桁に拡張され、国際ブランドは2022年4月以降、新規には8桁のBINしか割り当てていません(既存の6桁のBINも引き続き使われています)。以下は6桁を前提にした話なので、8桁のBINが特定できる場合は未知の桁が2桁減る点に注意してください。ISO/IEC 7812

BIN、IINについて#

BIN、IINもまた複数要素で構成されており最初の1桁はMII（Major industry identifier, 主要産業識別子）と呼ばれており、カードを使用する業界を示し対応表を下記のとおりです。

MII値	産業
0	ISO予約値
1	航空
2	航空 / その他将来発生する産業
3	旅行・娯楽/銀行・金融
4	銀行・金融
5	銀行・金融
6	運送 / 銀行・金融
7	石油 / その他将来発生する産業
8	ヘルスケア / 医療 / 通信 / その他将来発生する産業
9	国毎に割り当て可能

また以下は主な過去に存在していた若しくは現在存在するBINのリストです。

カードの種別	プレフィックス	番号長	検証
American Express	34, 37	15	Luhnアルゴリズム
中国銀聯 (China UnionPay)	622126-622925, 624-626, 6282-6288	16	なし
Diners Club International	300-303574, 3095, 36, 38-39	14	Luhnアルゴリズム
Discover Card	60110, 60112-60114, 601174-601179, 601186-601199, 644-649, 65	16	Luhnアルゴリズム
JCB	3528-3589	16	Luhnアルゴリズム
MasterCard	510000 - 559999, 222100 - 272099	16	Luhnアルゴリズム
UATP	1	15	不明
Visa	4	13, 16	Luhnアルゴリズム

チェックディジットに関して#

クレジットカード番号にはLuhnアルゴリズムが使用されており、主な目的として連番での発行をさせず、入力ミス等で他人のカードが決済されるのを防ぐためだと推測される。但しこれは計算可能な為悪意のある決済を防ぐ為のものではない。

セキュリティ面での検証#

以上のルールを踏まえ当方が検証した内容を記述する。

検証概要#

近年ではApple Pay等でクレジットカード番号の下4桁が管理用に表示され尚且つApple Payの場合クレジットカードデザインからある程度イシュアが特定可能な為そこからクレジットカード番号が推測できないか検証してみた。

BIN,IINの特定#

まずカードデザインよりBINを特定してみる、BIN等は公にはされていないが以下サイト等で調べることができるがカード会社によっては途方もないBINの登録がありこの時点でカード番号を特定できるイシュアーが限られてくるが続きはBINが特定されたものとして進めていくBIN search

カード番号の特定#

BINが特定されたものとして話を進めていきます。この時点で6桁のBIN+下4桁が判明していることになります。ここで全てのLuhnアルゴリズムに当てはまる数字を算出してみました(今回は16桁で)下記サイトでチェックしましたがゆうに100件を超えており特定が不可能でした。credit card number generator

まとめ#

以上の通りスクリーンショットやレシート画像等から番号特定は現実的にはほぼ不可能という結果になりましたまた近年ではセキュリティコードの必須化や3D secure導入等が進んでおり仮に割れたところで現実的には決済できる加盟店は存在しないでしょう。

NOTE
2026年10月追記クレジットカード・セキュリティガイドライン【5.0版】で、2025年3月末までに原則すべてのEC加盟店にEMV 3-Dセキュアの導入が求められることになりました。カード決済時の本人認証サービス(EMV 3-Dセキュア)導入のご案内|JCB