rex0220 印刷屋プラグイン - AI(Claude Desktop)にQRコード付きの資産ラベルを作らせる

Last updated at 2026-10-11Posted at 2026-10-11

前回の記事では、組織図の帳票を先に設計してから、それに合わせて kintone アプリを作りました。今回も同じ順で、市販のラベル用紙（A4 12 面）に貼る、QR コード付きの資産管理ラベルを作ります。

下は、備品台帳アプリの一覧画面から出したラベルです（14 件で、1 ページ目に 12 面、2 ページ目に 2 面）。QR コードをスマホで読むと、その備品の kintone の詳細画面が開きます。

今回は、シリーズでまだ扱っていない次の 3 つを使います。

一覧帳票: 一覧画面のレコードをまとめて 1 つの PDF にする（これまでは詳細画面の 1 レコードだけ）
QR コード: #{&q(文字列)} で、文字列を QR コードの画像にする
mm 単位の面付け: ラベル用紙の枠に、1 面ずつ位置を合わせる

途中で、1 ページ目だけが白紙になる、寸法が 0.64 倍に縮む、という 2 つのつまずきがありました。どちらも拡張機能の試し出力では気付けず、印刷屋の PDF で初めて分かったものです。その切り分けの過程も紹介します。

#	頼んだこと	結果
1	`資産管理ラベル（QR コード付き）の面付け`	AI が 3 つ聞き返し、固定データ 14 件の試作ができた
2	`１ページ目が空`（PDF のパス）	1 ページ目が白紙。切り分けのボタンを 3 つ作った
3	（切り分けの PDF 3 つ）	原因をしぼり、さらに切り分けのボタンを 2 つ作った
4	（切り分けの PDF 2 つ）	原因が分かり、ページを 1 から数える形で作り直した
5	（試作の PDF）	白紙は直ったが、寸法が 0.64 倍に縮んでいた。96dpi にした
6	（試作の PDF）	寸法と QR を確かめた
7	`Go`	備品台帳アプリとテストデータ、一覧帳票の設定ができた
8	（一覧帳票の PDF）	寸法・QR・値を確かめた

2 回目以降は、ほとんど PDF を貼るだけです。AI が PDF を画像にして、寸法を測り、QR コードを読み取って確かめています。CSS や計算式は、今回も 1 行も書いていません。かかった時間は、頼んでから、一覧帳票の PDF を確かめるまで約 20 分でした。PDF を見て確かめる時間も含みます。

区切り	時刻	かかった時間
試作（聞き返し → 最初の試作の PDF）	21:53〜21:57	約 4 分
つまずきの切り分けと直し（白紙、寸法）	21:57〜22:09	約 12 分
アプリの作成 → 一覧帳票の PDF	22:09〜22:13	約 4 分
合計	21:53〜22:13	約 20 分

時刻は、頼んだ時刻と、PDF の作成日時、kintone のアプリの作成日時・更新日時から取りました。つまずきを 2 つ切り分けて直した約 12 分のあいだに、AI は切り分けの PDF 5 つと試作の PDF 3 つを読み、寸法を測り、QR を読み取って確かめています（一覧帳票の PDF を含め、読み取った QR は延べ 34 個）。

拡張機能（印刷屋設定オーサリング）の入れ方と、帳票を最初に作る手順は最初の記事を見てください。アプリを作る手順では、kintone MCP サーバーも使います。

1. 頼み方と、AI が聞き返したこと

頼んだのは、これだけです。

資産管理ラベル（QR コード付き）の面付け

AI は、拡張機能の資料で QR コードと一覧帳票の書き方を確かめてから、決められないことを 3 つ、選択肢で聞いてきました。

聞かれたこと	選んだもの
ラベル用紙（型番があれば教えてほしい）	A4 12 面（2 列 × 6 段）
QR コードに入れる内容	レコードの URL（読むと詳細画面が開く）
備品台帳のアプリ	試作の後に新しく作る

QR コードの中身について、AI は資料の注意（「レコードの値を直接つなぐと ) や ' で壊れる」）を読み、記号を含まない値（レコード番号から作る URL） を勧めていました。

用紙の型番は決めていなかったので、AI は A4 12 面でよく使われる寸法を仮の値として使いました。特定の用紙の仕様に合わせたものではありません。

	寸法
1 面	86.4 × 42.3mm（すき間なし）
余白	上下 21.5mm、左右 18.6mm
確かめ	横 18.6 × 2 + 86.4 × 2 = 210mm、縦 21.5 × 2 + 42.3 × 6 = 296.8mm（A4 の 297mm との差 0.2mm は、下の余白が少し広くなるだけ）

組織図と同じく、まずはアプリを作らずに、既存のアプリ（見積書アプリ 3740）の詳細画面のボタンとして、固定データ 14 件（12 面 + 2 ページ目に 2 面）で試作しました。

2. ラベルの組み立て

ページの余白と面付け

印刷屋は、1 ページ（rex0220-pcraft-page）に既定の余白を付けます。ラベル用紙の余白に合わせて、帳票の CSS で上書きします。

.rex0220-pcraft-page {
  padding: 21.5mm 18.6mm !important;
}
.lb-sheet {
  display: flex;
  flex-wrap: wrap;
  width: 172.8mm;         /* 86.4mm × 2 列 */
}
.lb {
  box-sizing: border-box;
  width: 86.4mm;
  height: 42.3mm;
  border: 0.2mm dashed #c8c8c8;   /* 位置合わせ用。本番では消す */
}

最初は位置合わせの点線を outline で書いていましたが、PDF に出なかったので border に変えています。

QR コード

QR コードは、<img> の src に #{&q(文字列)} を書くと、PDF を作るときに画像に置き換わります。文字列（レコードの URL）は計算式で組み立てます。

VTAG("img", ATTR("class", "lb-qr",
  "src", "#{&q(" & APP_URL("/k/4286/show#record=" & DIC_ITEM(vL, "id")) & ")}"))

APP_URL は、kintone の環境の URL を付けた文字列を返します。URL の形は固定で、変わるのは数字のレコード番号だけです。利用者が自由に入力した文字列（品名など）を QR の文字列に入れていないので、) や ' で #{&q(…)} が壊れることを避けられます。URL に含まれる # も、#{&q(…)} を壊しませんでした。

検査では、formula.attr（属性に式を入れている）の警告が出ます。資料では QR の文字列は計算式で作るように書かれていて、入れているのも固定の URL の形と数字のレコード番号だけなので、AI はこの警告を消さずに伝え、そのまま残しました。

3. 1 ページ目だけが白紙になる

試作を印刷屋で PDF にすると、1 ページ目が、文字も QR もない白紙でした。2 ページ目の 2 面は正しく出ています。

PDF のパスを貼って伝えました。

１ページ目が空/Users/…/Downloads/資産ラベル-試作-20261011.pdf

AI はダウンロードのフォルダーへのアクセスを求めて PDF を読み、1 ページ目と 2 ページ目の違いは「QR が 12 個か 2 個か」だけだと見て、条件を 1 つずつ変えた切り分けのボタンを 3 つ作りました。

ボタン	QR	解像度	1 ページの面数	結果
A	なし	150dpi	12	1 ページ目が白紙
B	あり	96dpi	12	1 ページ目が白紙
C	あり	150dpi	6	1 ページ目が白紙（2・3 ページ目は正しい）

3 つとも 1 ページ目だけが白紙だったので、QR の数・解像度・面数は原因ではないと分かりました。残るのは、「ページの番号が 0 のページだけ、ラベルを選ぶ式が何も返していない」か、「最初のページが描画されていない」かです。

そこで AI は、各ページの先頭にページの番号と、選んだ件数を表示するボタン（D）と、ページを 1 から数えるボタン（E）を作りました。

D の 1 ページ目は「vP = （空）、件数 = 0」、2 ページ目は「vP = 1、件数 = 2」でした。E では、1 ページ目に 1〜12 面が正しく出ました。

ページは、次の形で組み立てていました。

ARRAY_MAP(ARRAY_FOR(2, vI, vI), vP,      // ページの番号 vP = 0, 1
  PAGE_HTML(…
    ARRAY_FIL(…, vA, vIx, vIx >= vP * 12 && vIx < (vP + 1) * 12)   // そのページの 12 件
  …))

ARRAY_FOR(n, idx, idx) の idx はループ変数で、0 から始まります（n が 0 なら、ループせずに空の配列になります）。条件の式そのものは、vP = 0 なら 0〜11 番目を選ぶ正しい形です。それでも今回は、この 0 をページの番号として ARRAY_MAP の変数で受け、計算や比較に使ったところ、1 ページ目のラベルが選ばれませんでした。内部でなぜそうなるかまでは調べていません。この設定では、ページの番号も面の番号も 1 から数えることで解決しました。

ARRAY_MAP(ARRAY_FOR(ROUNDUP(n / 12, 0), vI, vI + 1), vP,          // ページ 1, 2, …
  PAGE_HTML(…
    ARRAY_MAP(ARRAY_FIL(ARRAY_FOR(n, vJ, vJ + 1), vS,
                        ROUNDUP(vS / 12, 0) = vP), vS2,           // 面の番号 1〜n
      LET(vL, ARRAY_GET(items, vS2 - 1), …ラベル 1 面…))
  …))

1 ページ目が白紙でも、拡張機能の試し出力では式のエラーは 0 件で、ページ数も正しく 2 と出ていました。式のエラーにならない食い違いは、印刷屋の PDF でしか分かりません。

4. 寸法が 0.64 倍に縮む

1 から数える形で作り直すと、白紙は直りました。ところが、ラベル 1 面が約 55 × 27mm で、狙いの 86.4 × 42.3mm より小さくなっていました。

AI は PDF を画像にして寸法を測り、縮んだ割合が 0.64（= 96 ÷ 150） であることから、原因を解像度の設定にしぼりました。

印刷屋は、用紙の大きさと dpi の設定から、ページの大きさを px で決めている（資料では px = mm × dpi ÷ 25.4。A4 縦は 96dpi で 794 × 1123px、150dpi で 1240 × 1754px）
一方、CSS の mm は dpi の設定にかかわらず「1mm = 96 ÷ 25.4 = 約 3.78px」で計算される
そのため 150dpi では、mm で書いた中身が、ページに対して 96/150（約 0.64）の大きさになる

これは印刷屋の仕様どおりの動きです。150dpi はページの px が増える分、細い文字や QR がきれいになりますが、mm で寸法を合わせる帳票は 96dpi にすると、CSS の mm がそのまま実寸になります。150dpi のまま使いたいときは、寸法を mm でなく、px = mm × 150 ÷ 25.4 で計算した px で書きます。組織図は 96dpi で px を使っていたので、この問題は出ていませんでした。

96dpi にした PDF を、AI が 300dpi の画像にして測った結果です。

	目標	PDF の実測
12 面全体の左端〜右端	18.6〜191.4mm	18.5〜191.3mm
12 面全体の上端〜下端	21.5〜275.3mm	21.2〜275.1mm

QR コードも 12 個すべてを読み取り、中身が …/k/3740/show#record=1〜12 で、ラベルの順と合っていることを確かめています。96dpi でも QR の読み取りに問題はありませんでした。

5. 備品台帳アプリを作り、一覧帳票にする

試作で見た目と寸法が決まったので、アプリを作ります。

Go

AI は kintone MCP サーバーで、組織図と同じスペースに「備品台帳(印刷屋)」を作りました。ラベルに載せた項目に、台帳として必要な項目を足しています。

項目	型	ラベルに載せるか
レコード番号	レコード番号	QR の URL に使う
資産番号	文字列（1行・必須・重複不可）	載せる
品名	文字列（1行・必須）	載せる
区分	ドロップダウン（PC、モニターなど 9 種）	—
状態	ラジオボタン（使用中 / 保管中 / 修理中 / 廃棄済み）	—
設置場所・管理部署	文字列（1行）	載せる
取得日	日付	載せる
取得価格	数値（円）	—
備考	文字列（複数行）	—

新しいアプリには「レコード番号」が最初から入っています。AI が同じ項目を足そうとして kintone にエラーで断られ、外して足し直す場面がありました。

テストデータは、試作と同じ 14 件です。

印刷屋の設定は、試作の詳細画面のボタンを一覧帳票（list: true）に変えたものです。違うのは、データの集め方だけです。

RECS_MAP(DIC(                      // 一覧のレコードを、表示順に辞書の配列に
  "id", レコード番号,
  "no", ESC_HTML(資産番号),
  "name", ESC_HTML(品名),
  "place", ESC_HTML(設置場所),
  "dept", ESC_HTML(管理部署),
  "date", IF(取得日 = "", "", DATE_FORMAT(取得日, "YYYY/MM/DD"))
))

ほかに、AI は次のようにしていました。

一覧で「選択したレコードのみ」を使えるよう、menuInfo.recselect を有効にした
新しいアプリなので、取り込みは「全置換」にするよう伝えた（「追加」や「一部置換」では、recselect などの共通の設定がファイルの値にならない）
QR の URL のアプリ番号（4286）を式に直接書いた。資料に「自分のアプリの番号」を返す関数が見つからなかったため。本番の環境では書き換えが要る

取り込んだ後の一覧画面です。上に「資産ラベル」のボタンと、「選択したレコードのみ一括処理」のチェックが出ます。チェックを付けてレコードを選ぶと、選んだレコードだけがラベルになります。

一覧帳票は、拡張機能の試し出力（レコード 1 件）の対象外です。そのため、確かめは印刷屋の PDF だけで行いました。AI が PDF を測り、寸法が試作と同じこと、QR 14 個がすべて読めて …/k/4286/show#record=番号 がラベルの資産番号と合っていることを確かめています。一覧で数件を選んで実行したときに選んだレコードだけが並ぶこと、スマホで QR を読むと詳細画面が開くことは、人が確かめました。

ラベルは、一覧画面の表示順（既定ではレコード番号の大きい順）に並びます。資産番号の順に貼りたいときは、並び順を設定した一覧から実行します。

つまずきを切り分けるコツ

条件を 1 つずつ変えたボタンを並べる

白紙の原因の候補（QR の数・解像度・面数）を、1 つずつ変えた 3 つのボタンにすると、1 回の取り込みで比べられます。PDF を貼るだけで、AI が結果を見比べて次の候補をしぼります。

帳票の中に、式の途中の値を出す

計算式の途中の値（ページの番号、選んだ件数）を見出しとして PDF に出すと、どこで食い違っているかが一目で分かります。式のエラーにならない食い違いを探すときに効きます。

PDF を AI に測らせる

ラベルのように寸法が大事な帳票は、見た目では分かりにくい差があります。PDF を貼ると、AI が画像にして mm 単位で測り、QR を読み取って中身まで確かめます。

気を付ける点

印刷は倍率 100%（実際のサイズ）で: 「用紙に合わせる」で印刷すると縮みます。プリンターによっては、印刷できない縁の分だけずれることもあるので、最初は普通紙に印刷してラベル用紙と重ねて確かめます
用紙の型番に合わせる: 今回の寸法は、型番の無い一般的な A4 12 面の値です。使う用紙の型番を伝えて、寸法を合わせてもらいます
位置合わせの点線を消す: 本番では .lb の border を外します
mm で寸法を合わせるなら 96dpi にする: 印刷屋は用紙と dpi からページの px を決めるので、150dpi では mm で書いた寸法が約 0.64 倍になります
ページや面の番号は 1 から数える: 今回の計算式では、ARRAY_FOR のループ変数（0 から）をページの番号として使うと 1 ページ目が空になり、1 から数えると正しく出ました
QR を読むにはログインと閲覧権限が要る: QR に入っているのは kintone のレコードの URL です。詳細画面を開くには、その環境にログインし、レコードを見る権限が必要です
アプリ番号を書き換える: QR の URL にアプリ番号を直接書いているので、別の環境のアプリでは書き換えます
一覧帳票は試し出力の対象外: 見た目は印刷屋の PDF で確かめます。資料では、一覧帳票が扱う一覧画面のレコードは最大 100 件です

まとめ

ラベル用紙の寸法と QR を、固定データの試作で先に確かめてから、アプリを作り、一覧帳票にした
1 ページ目が白紙になった件は、条件を 1 つずつ変えたボタンと、式の途中の値を PDF に出す方法で切り分け、ページを 1 から数えて解決した
mm で寸法を合わせる帳票は 96dpi にする（印刷屋は用紙と dpi からページの px を決め、CSS の mm は 96dpi 基準のため）。QR コードは #{&q(…)} に、固定の URL の形と数字のレコード番号から組み立てた値を入れる

シリーズ「rex0220 印刷屋プラグイン - AI(Claude Desktop)に〜」: