kintone プラグインの修正を出す前の最後の確かめは、実際の kintone の画面です。プラグインの zip を入れ替えて、テスト用のアプリを作り、設定を入れて、レコードを開いてボタンを押す……。手順は決まっていても、毎回それなりに時間がかかります。
今回は、Claude Code（VS Code の拡張機能）と Claude in Chrome（Chrome の拡張機能） に、この実機テストをまとめて任せてみました。頼んだのは、kintone のスペースの URL を添えた 1 行だけです。
下記スペースにテスト用アプリを作成して、ブラウザー操作でチェックして
https://（サブドメイン）.cybozu.com/k/#/space/（番号）/thread/（番号）
Claude は、プラグインの入れ替え、テスト用アプリの作成、プラグインの設定の取り込み、詳細画面・プレビュー・モバイルでの確認までを済ませ、結果を表にして報告しました。本記事では、その流れと、どこでつまずいたかを紹介します。
確かめたかったこと
リリース前の 印刷屋プラグイン Ver.9 と 計算式プラグイン Ver.102 は、同じ計算式エンジンを使います。このエンジンに、次の直しを入れました。
| 直したこと | 直す前 | 直した後 |
|---|---|---|
& でつないだ関数の結果が ( で始まる・関数名の字面を含む・真偽値 |
"<td>" & ESC_HTML("(株)山田") & "</td>" がエラー、"[" & TRIM("見積 ROUND(1.5) 件") & "]" が [見積 2 件]
|
値のまま |
| 式全体や関数の引数を括弧で包む |
IF((数値 > 5), "A", "B") がエラー、("test") が項目 test の値 |
中の値のまま |
| LET の変数名が項目のフィールドコードと同じ |
LET() variable name (0) is already defined.（(0) は引数の位置） |
LET() variable name (数値) is already defined. |
直しは、Node で動かす確かめで済ませてありました。
- 回帰の確かめ 170 件
- 関数の説明文の使用例 1,218 件
- 手元の帳票の設定 620 行（直す前のエンジンと、出力・エラー・評価回数が同じか）
残っていたのが実機です。印刷屋のボタンの表示条件・プレビュー・PDF の保存・更新項目と、計算式プラグインのデスクトップ・モバイルの計算を、kintone の画面で見ておきたいところでした。
仕組みの構成
- Claude in Chrome は、利用者がふだん使っている Chrome で動きます。kintone にログインしたままなので、Claude にパスワードや API トークンを渡す必要はありません
- Claude は、ページを開く、クリックする、入力する、スクリーンショットを撮る、ページで JavaScript を動かす、ページのファイルの入力欄に手元のファイルを渡す、ができます
- ページで動かす JavaScript から kintone の REST API を呼ぶと、ログインしている利用者の権限で動きます。今回の利用者は、開発環境のシステム管理の権限を持っています（プラグインの入れ替えに要ります）
1. 入っているプラグインの版を見る
Claude は、スペースのページを開いたあと、まず開発環境に入っている印刷屋と計算式プラグインの版を調べました。ページの JavaScript から REST API（GET /k/v1/plugins.json）を呼んでいます。
結果は、印刷屋が版 9、計算式が版 102。どちらも今回の直しの前のビルドです。確かめるには、作り直した zip に入れ替える必要があると判断しました。
計算式プラグインの zip はまだ作っていなかったので、Claude が作りました。このとき、手元の dist/ に置いてあった未追跡の zip を上書きしないように、git に入らないフォルダーに別の名前で作っています。
2. プラグインを入れ替える
これまで、プラグインの入れ替えは自作のスクリプト（npm run upload-*）で行っていました。スクリプトは Node から REST API（/k/v1/file.json と /k/v1/plugin.json）を呼びます。認証は、環境変数に置いた kintone のユーザー名とパスワードです。
今回は、Claude が Chrome の操作で入れ替えました。呼ぶ REST API は同じ 2 つですが、ログイン中の Chrome のページから呼ぶので、パスワードを使いません。
| これまで（スクリプト） | 今回（Chrome の操作） | |
|---|---|---|
| 動かす所 | 手元の Node | ログイン中の Chrome のページ（Claude in Chrome） |
| 呼ぶ API |
POST /k/v1/file.json → PUT /k/v1/plugin.json
|
同じ |
| 認証 | 環境変数のユーザー名とパスワード | ブラウザーのログイン（パスワードは使わない） |
| zip の渡し方 | ファイルのパスを指定 | ページのファイルの入力欄に渡す |
Claude は、ページで次の順に処理しました。
- ページに見えないファイルの入力欄を 1 つ作る
- その入力欄に、手元の zip を Claude in Chrome の機能で渡す（ファイル選択の画面は開かない）
- 入力欄のファイルの SHA-256 をページで計算し、手元の zip の値と同じかを確かめる
- ファイルを kintone に上げて（
POST /k/v1/file.json）、プラグインを更新する（PUT /k/v1/plugin.json）
const token = kintone.getRequestToken();
const f = document.getElementById('claude-upload').files[0];
const fd = new FormData();
fd.append('__REQUEST_TOKEN__', token);
fd.append('file', f, f.name);
const { fileKey } = await (await fetch('/k/v1/file.json', {
method: 'POST', headers: { 'X-Requested-With': 'XMLHttpRequest' }, body: fd,
})).json();
await fetch('/k/v1/plugin.json', {
method: 'PUT',
headers: { 'X-Requested-With': 'XMLHttpRequest', 'Content-Type': 'application/json' },
body: JSON.stringify({ id: '（プラグイン ID）', fileKey, __REQUEST_TOKEN__: token }),
});
印刷屋、計算式の順に入れ替え、どちらも 200 で返りました。
プラグインの入れ替えは、その環境でプラグインを使っているすべてのアプリに効きます。今回は開発環境で、前の zip を入れ直せば戻せるので、Claude は確認を求めずに進めました。本番の環境なら、入れ替えの前に止めて聞くように頼むところです。
3. テスト用アプリを作る
アプリも、ページの JavaScript から REST API で作りました。画面でアプリを作り、項目を 1 つずつ置くより速く、項目コードを間違えません。
- アプリを作る（
POST /k/v1/preview/app.jsonにspaceとthreadを付けると、そのスペースのスレッドのアプリになる） - 項目を足す（
POST /k/v1/preview/app/form/fields.json） - アプリに印刷屋と計算式プラグインを入れる（
POST /k/v1/preview/app/plugins.json） - 運用環境に反映して、終わるのを待つ（
/k/v1/preview/app/deploy.json） - テスト用のレコードを 1 件作る（会社名「(株)山田」、数値 1200）
| 項目コード | 型 | 使い道 |
|---|---|---|
| 会社名 | 文字列（1 行） |
(株) で始まる値 |
| 数値 | 数値 | 括弧で包んだ条件 |
| 結果_連結 / 結果_括弧 / 結果_括弧文字 / 結果_真偽 | 文字列（1 行） | 計算式プラグインの結果 |
| 備考 / 区分 | 文字列（1 行） | 印刷屋の更新項目の書き込み先 |
| 帳票 | 添付ファイル | 印刷屋の PDF の保存先 |
「帳票」は、あとから足した項目です。印刷屋は、保存先の添付ファイル項目を決めないと PDF をダウンロードします。Claude はファイルのダウンロードを、利用者の許可を取ってからにする決まりで動いているため、PDF をレコードに保存する形にして、ダウンロードを避けました。
4. プラグインの設定を作って取り込む
印刷屋
印刷屋の設定は、設定づくりの tools（@rex0220/print-craft-authoring-tools）で作りました。ボタンは 4 つです。
| ボタン | 表示条件 | 確かめること |
|---|---|---|
| 確認A（出る） | IF((数値 > 5), 1, 0) |
本文の ${}、ファイル名、PDF の保存、更新項目 |
| 確認B（出ない） | "[" & TRIM(会社名) & "]" = "x" |
直す前のエンジンなら、表示条件のエラーで「真」として扱われて出ていたボタン |
| 確認C（出ない） | IF((数値 > 99999), 1, 0) |
括弧で包んだ条件が偽になる |
| 確認D（エラー） | 1 |
${LET(数値, 5, 数値 * 2)} のエラーの表示 |
確認A の本文には、直した形の式を並べました。
<div class="rex0220-pcraft-page">
<h2>Ver.102 エンジン確認</h2>
<p>T1 連結: [${"<b>" & ESC_HTML(会社名) & "</b>"}]</p>
<p>T2 括弧の条件: [${IF((数値 > 5), "大", "小")}]</p>
<p>T3 括弧の文字列: [${("test")}]</p>
<p>T4 関数名の字面: ${"[" & TRIM("見積 ROUND(1.5) 件") & "]"}</p>
<p>T5 真偽: [${IF(1, 1=1, 0) & ""}]</p>
<p>T6 空白の削り: ${"[" & IF(1=1, " a ", "") & "]"}</p>
<p>T7 括弧で包む: ${"[" & (IF(1=1, " a ", "")) & "]"}</p>
</div>
更新項目は、更新条件 "[" & TRIM(会社名) & "]" = "[(株)山田]"、備考 "<" & TRIM(会社名) & ">"、区分 IF((数値 > 1000), "大", "小") です。ファイル名は TRIM(会社名) & "_見積"、「ボタンを押したとき」は「プレビューを表示」にしました（PDF を作る前に本文を読めます）。
tools の normalize で検査すると、エラー 0、警告 2 でした。警告は「${} が文字列をエスケープせずに差し込んでいる」で、テストのためにわざとそう書いた所です。
できた設定のファイルを、Claude は印刷屋の設定画面の「設定のアップロード」の入力欄に渡し、取り込み方「全置換」→「取り込む」→「運用環境に反映」にチェック →「保存する」と操作しました。
計算式プラグイン
計算式プラグインの設定も tools で検査しようとしたところ、tools が zip を読みませんでした。
authoring API のプラグインの版 101 が zip の manifest の版 102 と違う（組み替えられた zip）
調べると、設定画面が tools に渡す API のファイルが、版を 102 に上げる前に作ったままでした。リリースの手順に作り直しがあり、その手前の段階だったためです。実機テストのついでに、リリースの前にしておくことを 1 つ見つけたことになります。
この確かめには tools を使わず、設定の元のファイル（項目ごとに項目コードと計算式を並べたもの）を、計算式プラグインの設定画面で直接取り込みました。設定画面が既定値を補い、検査します。
| 項目 | 計算式 |
|---|---|
| 結果_連結 | "<" & TRIM(会社名) & ">" |
| 結果_括弧 | IF((数値 > 5), "大", "小") |
| 結果_括弧文字 | ("test") |
| 結果_真偽 | IF(1, 1=1, 0) & "" |
5. 画面で確かめる
印刷屋
レコードの詳細画面を開くと、出たボタンは「確認A（出る）」と「確認D（エラー）」の 2 つでした。確認B と確認C は出ません。
確認A を押して開いたプレビューの文字は、Claude がページの JavaScript で読みました。スクリーンショットを目で読むより確実です。
| 行 | プレビュー | 直す前のエンジン |
|---|---|---|
| T1 連結 |
[(株)山田]（太字） |
エラー |
| T2 括弧の条件 | [大] |
エラー |
| T3 括弧の文字列 | [test] |
エラー（項目 test を探す） |
| T4 関数名の字面 | [見積 ROUND(1.5) 件] |
[見積 2 件] |
| T5 真偽 | [true] |
エラー |
| T6 空白の削り | [a] |
[a]（今回は変えていない） |
| T7 括弧で包む | [ a ] |
[ a ] |
プレビューの「確認A（出る）」を押して PDF を作ると、添付ファイル項目に (株)山田_見積.pdf が保存され、備考が <(株)山田>、区分が 大 になりました。Claude は、この 3 つの値を画面だけでなく REST API（GET /k/v1/record.json）でも読み、文字まで確かめています。直す前のエンジンなら、ファイル名は既定の名前、更新項目は空になっていたところです。
確認D を押すと、印刷屋のエラーのダイアログに LET() variable name (数値) is already defined. と、変数名が出ました。
ダイアログの下には、エラーの経路（プラグインのファイルの URL）も出ます。URL に開発環境のホスト名が入るので、画像はその上までにしてあります。
計算式プラグイン
デスクトップでレコードを編集画面で開くと、4 つの結果の項目に <(株)山田>、大、test、true が入っていました。保存して、REST API でも同じ値を確かめました。
モバイルは、モバイル版の URL（/k/m/（アプリ番号）/edit?record=1）で開きました。数値を 3 に変えると、結果_括弧が「小」に変わり、そのまま保存できました。
この画像は、記事のために数値を 1200 に戻す前（モバイルで保存した直後）に撮りました。PC の詳細画面の画像は、数値を 1200 に戻してから撮っています。
同じアプリに印刷屋と計算式プラグインの両方を入れているので、2 つのプラグインが同じ画面で動くことも、あわせて確かめられました。
結果の報告
Claude の報告は、確かめた項目と結果の表に、「確かめていないこと」を添えた形でした。
- 帳票例のアプリ（重い帳票）の実機の確かめは、していない。ボタンによっては、すぐに PDF を作ってダウンロードするため（Node の確かめでは 620 行が同じ）
- 計算式プラグインの zip は、リリース用ではなく試しのビルド（リリースの前に、設定画面の API を作り直す）
確かめていないことを、確かめたように書かないのは、ここでも同じでした。結果は、作業の記録（計画の文書）にも書き足してあります。開発環境のホスト名は、記録では伏せています。
記事の画像も Claude が撮った
本記事の 6 枚の画像も、Claude が Claude in Chrome で撮ったものです。記事の原稿ができた後に、「画像を追加して」と頼みました。
| 順 | Claude がしたこと |
|---|---|
| 1 | テスト用アプリを開き直し、記事の章ごとに要る画面（設定のアップロード、計算式の設定画面、詳細画面、プレビュー、エラーのダイアログ、モバイル）を決める |
| 2 | 画面全体を撮って切り取るのでなく、範囲を指定して拡大して撮る（文字が粗くならない） |
| 3 | 撮る前に、マウスのカーソルを画面の端へ動かす（最初の 1 枚に写ったので撮り直した） |
| 4 | ログイン名が出る上の帯、設定画面の下の「更新者」、エラーのダイアログの下の経路（開発環境のホスト名入りの URL）を、範囲から外す |
| 5 | 記事の本文と同じ状態にするため、モバイルで 3 にした数値を、PC の編集画面で 1200 に戻す（計算式プラグインが結果を計算し直す）。モバイルの画像は、戻す前に撮る |
| 6 | 設定のアップロードのダイアログは、同じ設定のファイルをもう一度入力欄に渡して出し、撮った後に「キャンセル」で閉じる（設定は変えない） |
| 7 | モバイル版は PC の Chrome では横に広がるので、項目名と値が入る左側の範囲で撮る |
| 8 | 画像を git に入れない場所（~/Projects/claude_out/）に、記事の順の番号付きの名前で置き、原稿の該当の場所に入れる |
Qiita への画像のアップロードは、前の記事 と同じく人が行いました。6 枚を上げて「画像アドレスを一括コピー」した Markdown を Claude Code に貼ると、Claude がファイル名で突き合わせて、原稿の画像を Qiita の URL に差し替えました。
テストのために作ったアプリを、そのまま記事の画像にも使えるので、テストと記事を続けて頼むと手間が少なく済みます。
指示していない手順は、Claude ができる範囲で組み立てた
頼んだのは「テスト用アプリを作成して、ブラウザー操作でチェックして」の 1 行だけです。プラグインの入れ替え方や設定の作り方は指示していません。振り返ると、指示していない手順は、Claude が自分で実行できる範囲で組み立てていました。
| 場面 | Claude が選んだ手順 | 選んだわけ（Claude ができる範囲・決まり） |
|---|---|---|
| プラグインの入れ替え | ログイン中の Chrome のページから REST API | いつものスクリプトは環境変数のパスワードで動き、プロジェクトの規則（CLAUDE.md）では、kintone へのアップロードを伴うスクリプトは指示がない限り動かさない。Chrome ならログインのまま、同じ API を呼べる |
| 計算式プラグインの zip | git に入らないフォルダーに、別の名前で作る | 手元の dist/ にある未追跡の zip を上書きしない |
| テスト用アプリと項目 | ページの JavaScript から REST API | 画面のクリックより速く、項目コードを間違えない |
| 項目定義のファイル | ブラウザーの REST API で取り、tools が読む形のファイルを自分で書く | tools に kintone の接続が設定されていなかった。接続のファイルは利用者のもので、Claude は読まない・書かない決まり |
| 印刷屋の設定 | 設定づくりの MCP でなく、tools の CLI | MCP は作業フォルダーとして登録したフォルダーでしか動かない |
| 計算式プラグインの設定 | tools でなく、設定画面で直接取り込む | tools が zip を読まなかった（4 章） |
| 印刷屋の PDF | 添付ファイル項目に保存し、まずプレビューで止める | ファイルのダウンロードは、利用者の許可を取ってからの決まり |
| 記事の画像 | ログイン名やホスト名が写らない範囲を選んで撮り直す | 開発環境のホスト名を記録に書かない、と Claude Code のメモリに残してある |
使える道具（Chrome の操作、手元のシェルとファイル）と、プロジェクトの規則・メモリ、Claude 自身の決まり（パスワードを扱わない、ダウンロードは許可を取る）の内側で手順を選ぶので、頼む側が細かい手順まで書かなくても進みます。
ただし、選んだ手順が人の想定と同じとは限りません。プラグインの入れ替えは、筆者はいつもスクリプトで行っています。Claude は報告に手順を書くので、それを読んで、違えば伝えるのが人の役目です。
つまずいたところ
| つまずき | 起きたこと | どうしたか |
|---|---|---|
| 設定づくりの MCP が使えない | Claude Code を起動したフォルダーが、MCP の作業フォルダーとして登録されていなかった | 同じことができる tools の CLI を使った |
| tools の書き出し先 |
normalize の書き出し先は決まったフォルダーだけ |
決まったフォルダーに書いてから、git に入らないフォルダーに移した |
| tools が zip を読まない | 計算式プラグインの API の版が古いまま（4 章） | 設定画面で直接取り込んだ。リリースの前の作業として記録した |
| JavaScript の結果が長い | 項目定義をまるごと返すと、途中で切れた | 項目コード・型・レイアウトだけに絞って返した |
| モバイルの案内 | モバイル版を初めて開くと、案内の吹き出しが重なった | 吹き出しを閉じてから入力した |
| ダウンロードを避ける | 印刷屋の PDF は、保存先が無いとダウンロードになる | 添付ファイル項目を足して保存先にし、「ボタンを押したとき」をプレビューにした |
| 開発環境のホスト名 | URL や記録に入る。印刷屋のエラーのダイアログの下のエラーの経路にも、ホスト名入りの URL が出る | 記事と記録の URL は伏せた。エラーのダイアログの画像は、経路の上までにした |
| 画像にカーソルが写る | 記事用の画像を撮ったら、マウスのカーソルが入った | 撮る前にカーソルを画面の端へ動かして撮り直した |
人がすること、任せられること
| 任せられたこと | 人がしたこと |
|---|---|
| 入っているプラグインの版を調べる | テストに使うスペースを決めて、URL を渡す |
| zip を作って、Chrome の操作でプラグインを入れ替える（ファイルの照合も） | テスト用のスペース（開発環境）を用意する |
| テスト用アプリと項目、レコードを作る | 何を確かめるか（直したこと）を決める |
| プラグインの設定を作り、検査して、設定画面で取り込む | 重い帳票のアプリの確かめ（ダウンロードを伴う）をするかを決める |
| ボタンを押す、プレビューの文字を読む、REST API で値を確かめる | コミットとリリース |
| モバイル版で編集して保存する | Qiita への画像のアップロードと公開 |
| 結果を表にまとめ、記録に書く | |
| 記事の画像を撮る（範囲、カーソル、写してはいけない所）、Qiita の URL への差し替え |
実機テストで手間なのは、確かめる操作そのものより、その前の準備（zip の入れ替え、アプリと項目、設定の取り込み）です。準備から確認まで続けて任せられたのが、一番の収穫でした。設定画面で取り込むところは画面を操作し、アプリや項目を作るところは REST API を使う、という使い分けも Claude が決めています。
まとめ
- Claude Code に kintone のスペースの URL を渡して頼むと、ログイン済みの Chrome で、プラグインの入れ替えからテスト用アプリの作成、画面での確認までできる
- プラグインの入れ替えは、これまでのスクリプト（Node から REST API。パスワードで認証）と同じ API を、ログイン中の Chrome のページから呼んで済ませた。パスワードを使わない
- アプリや項目は、ページの JavaScript から REST API で作ると速く、項目コードを間違えない（ログインしている利用者の権限で動く）
- プラグインの zip や設定のファイルは、ページの入力欄に渡せる。SHA-256 で手元のファイルと照らすと安心
- ダウンロードを避けるため、PDF の保存先を添付ファイル項目にするなど、テストの形も Claude が考える
- 結果は REST API でも読むので、画面の見た目だけに頼らない
- 実機テストの途中で、リリースの前の作業（API の作り直し）の漏れも見つかった
- 指示していない手順は、Claude が使える道具と、規則・メモリ・自身の決まりの内側で組み立てる。報告の手順を読み、想定と違えば伝える
- 記事の画像も、テスト用アプリを開き直して Claude が撮る。ログイン名やホスト名が写る所は範囲から外す