Google スプレッドシートをデータベースにして、半日でラベル運用を一通り構築する

すでに手元にあるデータソースから始める

ラベルのプロジェクトが止まる原因は、たいていプリンターでもデザインでもありません。止まるのはデータです。誰かが商品リストを管理しなければならず、「ERP をつなげばいい」という話は 6 週間かかるチケットに変わります。

ですから、まずは Google スプレッドシートから始めます。これは立派なデータソースであり、オフィスの全員が編集でき、そこから印刷されたラベルまでの距離が短いからです。ERP 連携がいずれ整っても、ラベルと印刷経路は変わりません。変わるのは行データの出どころだけです。

以下が最初から最後までの流れのすべてです。

1 - プリンターをネットワークにつないで接続する

開梱して用紙をセットし、電源を入れ、ネットワークにつなぎます。そのうえで Weblink のワンライナーまたは CLI エージェントで zplCloud に接続し、用紙に合わせて濃度と速度が合うようにプリンタープロファイルを適用します。手順はスピードランの記事で 1 つずつ説明しています。所要時間は 10 分ほどを見込んでください。

2 - ラベルをデザインする

デザイナーでテンプレートまたは白紙から始め、ラベルごとに変わる項目を追加します。品番、名称、数量、宛先などです。バインディングの名前はスプレッドシートの列見出しとまったく同じにしてください。この 1 つの判断で、後のマッピング作業がすべて不要になります。

プレビューは PNG、PDF、SVG で確認できます。ZPL を生成するのと同じエンジンがサーバー側で描画するため、近似表示ではありません。

デザイン ID を控えておきます。形式は <name>.<id> で、たとえば shipping-label.42 です。API で必要になります。

3 - スプレッドシート

1 行が 1 枚のラベル、1 列が 1 つのバインディングです。

方法 A: コードなし。 行をデザイナーの テストデータ タブまたはバッチジョブに貼り付けて印刷します。週に一度の印刷ならこれで十分で、準備は一切要りません。

方法 B: Apps Script。 シート自体がトリガーになります。API キーを使って公開 API 経由でレンダリングします。

// Extensions → Apps Script. Renders the active row and returns ZPL.
const API_KEY   = 'sk_zplcloud_…';               // API tab in the platform
const DESIGN_ID = 'shipping-label.42';           // "<name>.<id>"

function renderActiveRow() {
  const sheet  = SpreadsheetApp.getActiveSheet();
  const header = sheet.getRange(1, 1, 1, sheet.getLastColumn()).getValues()[0];
  const row    = sheet.getRange(sheet.getActiveCell().getRow(), 1, 1, sheet.getLastColumn()).getValues()[0];

  // The body is an array of records: keys must match the design's bindings.
  const record = {};
  header.forEach((col, i) => record[col] = row[i]);

  const res = UrlFetchApp.fetch(
    'https://api.zplcloud.com/v1/zpl/render/design/' + DESIGN_ID,
    {
      method: 'post',
      contentType: 'application/json',
      headers: { 'X-API-Key': API_KEY },
      payload: JSON.stringify([record]),
      muteHttpExceptions: true          // otherwise a 4xx throws before you can read the message
    });

  if (res.getResponseCode() !== 200) throw new Error(res.getContentText());
  return res.getContentText();          // the ZPL
}

API 側で強制される制限が 2 つあり、これを前提に設計します。

• 1 リクエストあたり 500 レコード。これより大きい処理は分割してください。
• リクエストボディは 1 MB。通常のラベルデータなら数千行に相当するため、先にレコード数の上限に当たります。

カスタムメニュー（onOpen → SpreadsheetApp.getUi().createMenu(...)）を追加すれば、同僚はスプレッドシート自身のメニューバーから Print を選べるようになります。

4 - ZPL をプリンターへ届ける

レンダリングと印刷を 2 段階に分けているのは意図的です。今レンダリングして後で印刷することも、一度レンダリングして 3 拠点で印刷することもできます。

• プラットフォームから: デザインをワンクリックで Weblink プリンターまたはエージェントのプリンターに印刷できます。スクリプトは関係しません。
• 自前のコードから: ZPL をエージェント経由の TCP 9100 でプリンターに送るか、作業者の PC 上の CloudToBrowserPrint に渡します。
• 人が操作する場合: スクリプトは使わず、プリントビューを渡します（次の手順）。

5 - 実際に印刷する人のためのプリントビュー

デザインからプリントビューを作成し、menge と ziel を編集可能に、artikel_nr をロックし、ビューにスプレッドシートのデータまたは検索を紐付けます。URL を共有するか、QR コードを印刷してプリンターの横に貼っておきます。

作業者はスマートフォンでリンクを開き、商品バーコードを項目にスキャンし、ライブプレビューを確認して印刷をタップします。アプリも研修も要りません。

全体の流れ

スプレッドシートが十分に擁護できる選択である理由

これは言い訳の必要な妥協ではありません。シートにはバージョン管理、コメント、ユーザーごとのアクセス権、監査証跡が最初から備わっており、使い方を教える必要もありません。実際の限界は同時編集と参照整合性です。同じ行を 2 人が同じシフト中に編集する場合や、商品リストを ERP と完全に一致させる必要がある場合が、データハブに移行して SQL Server や MongoDB を直接照会する合図になります。

移行の影響範囲は限定的です。デザインもバインディングもプリントビューもそのままで、変わるのはデータソースだけです。

関連

• 自動化: API、Webhook、バッチ、ストリーミング
• 印刷: プリントビュー、バッチ、キュー
• 料金