---
title: "4コママンガ『ハコブくん』を縦長4枚でめくる形に ― 次はショートと同時に出す"
slug: hakobu-4koma-swipe-format
date: 2026-10-31
day: 413
meta_description: "4コママンガ『ハコブくん』は、縦長（4:5）の4コマを横にスワイプしてめくる形に変え、29話を pixelstomotors.com に載せた。1コマずつ別の絵なので、サイト・ショート・SNSに同じ絵を使える。"
tags: [4コママンガ, ハコブくん, 縦長マンガ, 画像生成AI, Gemini, Claude, サイト制作, AI活用]
ai_consult: true
series: "ひとり研究所の裏側"
---

**4コママンガ『ハコブくん』は、縦長（縦横比 4:5）の4コマを横にスワイプしてめくって読む形に変え、第73〜133話の29話を pixelstomotors.com に載せました。** 1コマが1枚の絵なので、サイトのページ・YouTube ショート・SNS の画像に、同じ絵をそのまま使えます。

『ハコブくん』は、病院で薬を運ぶロボット・ハコブくんと、看護師さんたちの4コママンガです。ロボットが現場に入ったときに起きるすれ違いを、毎話1つ描いています。これまでは4つのコマを1枚のページに組んでいました。前の記録（LOG408）で、1コマを縦長の1枚ずつで描けば YouTube ショートにそのまま使えることを確かめ、まずはショートだけで試していました。

今回は、その縦長の4コマを、サイトでもそのまま読める形にしました。スマホでは指で横にめくり、PC ではコマの左右のボタンでめくります。コマの下には、毎話の設計の解説（デザインノート：その話で起きたことが、現実のロボットの設計のどこにつながるかを3段で書いた文）を置き、ページの最後に前の話・次の話へのカードを付けました。

作る途中で、いちばん手こずったのは絵の間違いです。**キャラの大きさが設定とずれる問題は毎回起きていて、原因は「絵を描く AI が数字の大きさを守らず、コマを埋める大きさで描く」ことでした。** 大きさは目で見るだけでなく測って選ぶようにし、マンガを見せる前に3回確かめる流れと、間違いを書きためる台帳を作りました。それでも公開後に、腕が3本・脚がない・眼鏡がない、といった間違いが見つかり、そのたびに台帳に足しています。

やったことの全体は次のとおりです。

| やったこと | なぜ | 結果 |
|---|---|---|
| 未着手のプロットから30話を縦長の4コマで描いた | 新しい形で話をためる | 120コマ。描き直しを含めて約500枚を描いた |
| 見せる前に3回確かめる流れと、間違いの台帳を作った | 細かい間違いが見落とされていた | 120コマを見直して21コマを描き直した |
| キャラの大きさがずれる原因を調べ、測る仕組みを足した | 大きさのずれが毎回起きていた | 原因を6つに分け、高さの比を数字で出せるようにした |
| サイトに、横にスワイプして読むページを作った | 縦長の4枚を1画面ずつ読ませたい | 3話で試してから29話を公開した |
| めくるボタンの場所と形を直した | ボタンを押すとコマが切れた・黒いボタンが目立ちすぎた | コマとボタンが1画面に収まり、ボタンは黒い縁にした |
| 表紙と、前の話・次の話のカードを足した | 一覧で話の中身が分かる顔にしたい | 29話の表紙を作り、全話に前後のカードを付けた |
| 29話の SNS の投稿を予約した | 新しい話を知らせる | 11/2〜11/27 の朝7:30 を中心に、X と LinkedIn を予約した |
| 次の50話のプロットを、現場の調査から作った | 実際に起きている問題を描きたい | 100件を調べ、50話を作り、codex の検証を受けて直した |

ここから下は作業ログです。使ったコード・決まり・検証の結果は、あとで同じ手順を追えるように全文を載せています。効果の欄は、数字があるものは測った値、ないものは見込みです。


## 作業ログ ― 縦長の4コマ30話を描いて確かめた

### 30話は、スプレッドシートの未着手のプロットから新しい順に選んだ

『ハコブくん』のプロット（話の筋）は、Google のスプレッドシート「薬剤搬送ロボットハコブくん 進捗管理表」に1話1行でためています。列は、話の番号・対応の進み具合・タイトル・テーマ・登場人物・1〜4コマ目の中身・デザインノートの元になる一文です。このうち「未着手」の行を、番号の新しい順に30話選びました。第133〜123話・121話・118〜113話・111話・109話・101話・100話・99話・97〜93話・76話・73話です。

第121話は、前の横長の形でサイトに出ていたので、今回は縦長の版を描いただけで、サイトには入れていません。残りの29話を公開し、30話ともスプレッドシートの進み具合を「完了」にしました。

### Gemini の API で、1コマずつ描いた

[Gemini](https://ai.google.dev/gemini-api/docs) は Google の生成 AI です。文章と参考の画像を渡すと絵を描きます。API（プログラムから頼む窓口）で使うと、決まった指示を毎回同じ形で渡せて、1コマずつまとめて描けます。使った分だけ料金がかかります。**この30話のために Google AI Studio で払ったのは8,400円で、描いた絵1枚あたりでは約10円でした**（内訳は下の「Gemini の API にかかったお金」）。

| この記事で使う言葉 | 意味 |
|---|---|
| vbuild.py | Gemini に渡す指示を組み立て、描かせ、仕上げる自作のスクリプト（LOG410 で作った） |
| spec.py | 1話ごとの設定。コマごとの登場人物・構図・吹き出しの文を書く |
| 緑の背景 | 描くときは背景を緑一色にして、仕上げで白に置き換える。人や物の形を取り出しやすくするため |
| 候補 | 同じコマを何枚か描かせたもの。いちばん良いものを選ぶ |

キャラクターは、三面図（正面・横・後ろの絵）と、主要キャラの身長を並べた図を参考の画像として毎回渡します。ハコブくんは115cm、遠隔で操縦する人型ロボットのピカリくんは150cm、看護師の大城さんは165cm、という設定です。

### Gemini の API にかかったお金：払ったのは8,400円、1枚あたり約10円

Gemini の API の料金は、[Google AI Studio](https://aistudio.google.com/) で先にクレジット（前払いの残高）を買い、使った分がそこから引かれる形です。クレジットは Gemini の API にだけ使えます。最初の2回は手で買い、そのあと「残高が800円を下回ったら800円を足す（1か月の上限5,000円）」というオートチャージを入れました。Google から届いた支払いのメールを並べると、次のとおりです。

| メールが届いた日時（日本時間） | 払った額 | 払い方 |
|---|---|---|
| 2026-10-30 14:28 | 3,200円 | 前払い |
| 2026-10-30 21:23 | 2,000円 | 前払い |
| 2026-10-31 06:33 | 800円 | オートチャージ |
| 2026-10-31 06:49 | 800円 | オートチャージ |
| 2026-10-31 07:07 | 800円 | オートチャージ |
| 2026-10-31 07:31 | 800円 | オートチャージ |
| 合計 | 8,400円 | |

払った額は、使った額とは少し違います。オートチャージが残高を800円前後に保つので、最後に買った分の一部は残っています。

使った額は、vbuild.py が API を呼ぶたびに残している記録（返ってきた答えの JSON。使ったトークン数が入っている）から計算できます。トークンは、AI が文章や画像を数えるときの単位です。記録が残っているのは10月30日〜31日の633回で、そのうち629回が gemini-3.1-flash-image への依頼でした。記録を残さずに呼んだ分があれば、使った額はこの計算より少し多くなります。

| 種類 | トークン数 | 単価（100万トークンあたり） | 金額 |
|---|---|---|---|
| 渡したもの（指示の文章・参考の画像） | 1,658,853 | 0.50ドル | 0.83ドル |
| 返ってきた文章（考えた過程を含む） | 300,182 | 3ドル | 0.90ドル |
| 返ってきた画像 | 665,280 | 60ドル | 39.92ドル |
| 合計 | 2,624,315 | | 41.65ドル（1ドル150円で約6,250円） |

単価は [Gemini API の料金のページ](https://ai.google.dev/pricing) の有料の枠の値です（2026-10-31 に確認）。画像1枚は約1,060トークンで、料金のページにある「1K の画像1枚0.067ドル」とほぼ同じです。

| 数え方 | 枚数 | 1枚あたり |
|---|---|---|
| 描かせた絵（候補・描き直し・表紙の編集を含む） | 629枚 | 約0.066ドル（約10円） |
| サイトに載せたコマ（29話×4コマ） | 116コマ | 約0.36ドル（約54円） |

載せた1コマのために、平均で約5.4枚を描かせたことになります。候補を3〜5枚描いて選ぶ流れと、確かめで見つけた間違いの描き直しが、この差です。

- ねらい：描き直しと候補の数が、どれだけお金になっているかを見える形にする
- 変わったこと：支払いのメールと API の記録から、払った額・使った額・1枚あたりを出した
- 見込める効果：次の50話を描く前に、1話あたり約220円（4コマ×約5.4枚×約10円）、50話で約1万1,000円と見積もれる。候補の数を減らしたときに、どれだけ下がるかも同じ式で確かめられる

### 見せる前に3回確かめる流れにした

最初に30話を描き終えたとき、そのまま声と動画まで作って見せてしまいました。見てもらうと、腕が3本ある人・脚のない人・大きさがばらばらのハコブくんが次々に見つかりました。描いた本人（Claude）が見ても、同じ所を見落とします。そこで、マンガを見せる前に確かめる時間を、流れの中に固定しました。

1. 描く
2. チェック①：描いたのとは別のエージェントが、1コマずつ決まった項目で見る
3. 直す（直したコマはもう一度チェック①）
4. チェック②：全部のコマを並べてエイイチに見せ、OK をもらう。OK の前に声や動画を作らない
5. ショートにする
6. チェック③：書き出した動画を並べて、字幕や吹き出しの切れを見る

あわせて、間違いを書きためる台帳「チェック項目と過去の間違い.md」を作りました。見つかった間違いを1行ずつ足し、直し方が決まったものは確かめる項目にも足します。次に描くときは、この台帳を最初に読みます。

- ねらい：同じ間違いを、次の話で繰り返さない
- 変わったこと：120コマをチェック①で見直し、21コマを描き直した。ここで見つかったのは、余計な吹き出し・台本にない記号・絵の中の英字・大きさのずれなど
- 見込める効果：見せてから直す回数が減る。ただし公開後にも4件見つかった（下の「公開後に見つかった絵の間違い」）。台帳は今も増えている

### キャラの大きさが設定とずれる6つの原因

大きさのずれは、どの話でも起きていました。特にピカリくんは、話ごとに大きくなったり小さくなったりしました。調べると、原因は6つに分けられました。

| 原因 | 何が起きるか |
|---|---|
| 絵の AI は数字の大きさを守らない | 「150cm」「1.3倍」は文字として読むだけで、実際はコマを埋めるように大きさを決める。主役は大きく、脇のロボットは吹き出しの横などの余った所に入る大きさに縮む |
| 参考の三面図は、どれも画面いっぱいに描かれている | 1人ずつの絵には「ほかのキャラと比べた大きさ」が入っていない。身長を並べた図は、何枚もある参考の1枚にすぎない |
| 背景が緑一色で、床の線がない | 少し奥や手前に置かれただけで見た目の大きさが変わり、遠近で縮んだのか設定より小さいのか分からない |
| 座る人・しゃがむ人の頭を、立っている人の目の高さに描く | 座った人が、立っているロボットより大きくなる |
| 大きさの指示が何本も積み重なり、食い違っていた | 古い指示の文と新しい指示、「細身」の一語などがぶつかると、AI は構図のほうを取る |
| 「ひざ上」「腰上」の指定を無視して全身で描く | 全身を入れるために全体を縮め、2人の縮み方がそろわない |

これを受けて、大きさの指示は1か所（頭のてっぺんと足もとの位置、薄い緑の枠を描いた下地の画像）にまとめ、並ぶ2人はカメラから同じ距離・同じ床に立たせることにしました。それでも1枚で決めずに、候補を3〜5枚描き、大きさを測っていちばん近いものを選びます。

測る仕組みは、vbuild.py に `measure` という命令として足しました。緑の背景の上で、床まで届いているかたまり（立っている人やロボット）を探し、頭のてっぺんと足もとの位置から高さの比を出します。例えば第117話の4コマ目は、ピカリくん（150cm）と千夏さん（164cm）が並ぶコマで、比は 150÷164＝0.91 が正解です。

- ねらい：大きさを目で見て決めない
- 変わったこと：候補ごとに高さの比が数字で出る。第117話4コマ目は、指示を強めても 0.70〜0.85 にしかならず、吹き出しの字が正しい中でいちばん近い 0.85 を選んだ
- 見込める効果：「並び図の比から ±0.08 を超えたら描き直す」と決められる。ただし AI が設定どおりの大きさで描くようになるわけではない

第117話4コマ目の候補を測った結果は次のとおりです。かっこの中は、左右の位置・頭のてっぺん・足もと・高さ（どれも画像の高さに対する%）です。

```
第117話_P4_20261030_222457.jpg [(26, 18, 97, 80), (71, 29, 95, 66)] 高さの比 0.82
第117話_P4_20261030_222458.jpg [(19, 5, 97, 92), (83, 21, 97, 76)] 高さの比 0.83
第117話_P4_20261030_222459.jpg [(19, 5, 97, 92), (71, 26, 97, 71)] 高さの比 0.77
第117話_P4_20261030_222504.jpg [(19, 10, 97, 87), (73, 29, 97, 67)] 高さの比 0.77
第117話_P4_20261030_222506.jpg [(20, 5, 97, 92), (76, 26, 97, 71)] 高さの比 0.77
（指示に「2人は同じ床・同じ距離・ピカリくんは千夏さんの目の高さまで」を足して6枚）
第117話_P4_20261030_223829.jpg [(19, 9, 98, 89), (67, 27, 96, 70)] 高さの比 0.79
第117話_P4_20261030_223858.jpg [(19, 5, 97, 92), (67, 23, 97, 74)] 高さの比 0.80
第117話_P4_20261030_223859.jpg [(19, 5, 97, 92), (75, 32, 97, 64)] 高さの比 0.70
第117話_P4_20261030_223902.jpg [(21, 18, 97, 79), (69, 30, 97, 67)] 高さの比 0.85
第117話_P4_20261030_223907.jpg [(28, 1, 98, 96), (69, 18, 93, 74)] 高さの比 0.77
第117話_P4_20261030_223911.jpg [(19, 5, 97, 92), (68, 26, 96, 70)] 高さの比 0.76
```

0.82 の候補は、吹き出しの「もうこっち向いていいよ」の「い」が1字抜けていたので選びませんでした。大きさと字は、別々に確かめる必要があります。

### vbuild.py の measure と finish

`finish` は、選んだ候補の緑を白に置き換え、1080×1350 に整えて「仕上げ」のフォルダに書き出します。あとから余計なふりがなや崩れた名札を白で消せるように、話ごとの設定に `PATCH`（白で塗る四角）を書けるようにしました。

```python
def measure(src):
    """緑の上の人・ロボットの大きさを測る（2026-10-31）。床に立つかたまり（下半分まで届く）を左から順に (中心x%, 頭頂y%, 足もとy%, 高さ%) で返す。
    手をつないでいる・重なっている2人は1つに数える。吹き出しは床に届かないので数えない"""
    from scipy import ndimage
    a = np.asarray(Image.open(src).convert("RGB")).astype(np.float64)
    H, W, _ = a.shape
    green = (a[..., 1] - (a[..., 0] + a[..., 2]) / 2) > 40
    lab, n = ndimage.label(ndimage.binary_opening(~green, iterations=2))
    out = []
    for k, sl in enumerate(ndimage.find_objects(lab), 1):
        ys, xs = sl
        if ys.stop < H * 0.6 or (ys.stop - ys.start) < H * 0.15 or (xs.stop - xs.start) < W * 0.05: continue
        out.append((round((xs.start + xs.stop) / 2 / W * 100), round(ys.start / H * 100), round(ys.stop / H * 100), round((ys.stop - ys.start) / H * 100)))
    return sorted(out)

def finish(ep, m):
    d = epdir(ep); os.makedirs(d + "/仕上げ", exist_ok=True)
    pick = getattr(m, "PICK", {})
    for i, p in enumerate(m.PANELS, 1):
        src = pick.get(i); src = d + "/生成/" + src if src else latest(d, "第%d話_P%d" % (ep, i))
        if not src: print("P%d 絵なし" % i); continue
        img = fit(degreen(src, getattr(m, "FIX", {}).get(i)), 1080, 1350)
        if i in getattr(m, "WINDOWS", {}):
            ws = pick.get("W%d" % i); ws = d + "/生成/" + ws if ws else latest(d, "第%d話_P%d小窓" % (ep, i))
            if ws:
                x0, y0, x1, y1 = p["inset_area"]
                bw = round((x1 - x0) * 1080); bh = round((y1 - y0) * 1350); side = min(bw, bh)
                win = fit(degreen(ws), side, side)
                X = round(x0 * 1080 + (bw - side) / 2); Y = round(y0 * 1350 + (bh - side) / 2)
                img.paste(win, (X, Y))
                dr = ImageDraw.Draw(img); dr.rectangle((X, Y, X + side - 1, Y + side - 1), outline=(0, 0, 0), width=6)
        for box in getattr(m, "PATCH", {}).get(i, []):   # 仕上げの座標（1080×1350）を白で塗る：余計な字・崩れた名札（2026-10-31）
            ImageDraw.Draw(img).rectangle(box, fill=(255, 255, 255))
        img.save(d + "/仕上げ/第%d話_P%d_1080x1350.png" % (ep, i))
        print("P%d" % i, os.path.basename(src))

# ---- コマンドの部分（measure）----
    elif cmd == "measure":       # python3 vbuild.py NN measure 4 [本数]：最新の候補の大きさを測る
        pn = rest[0]; k = int(rest[1]) if len(rest) > 1 else 5
        fs = sorted(glob.glob(d + "/生成/第%d話_P%s_2*.jpg" % (ep, pn)) + glob.glob(d + "/生成/第%d話_P%s_2*.png" % (ep, pn)))[-k:]
        for f in fs:
            ms = measure(f)
            hs = [h for _, _, _, h in ms]
            print(os.path.basename(f), ms, "高さの比 %.2f" % (min(hs) / max(hs)) if len(hs) >= 2 else "")
```

### チェック項目と過去の間違い.md

台帳の全文です。上が確かめる項目、下が見つかった間違いの記録（新しいものが上）です。

```markdown
# 縦長4コマ・マンガショートの チェック項目と過去の間違い

このファイルは、4コママンガを描くとき・ショートにするときに**毎回最初に読む**。
間違いが見つかったら、下の「過去の間違い」に1行足し、直し方がプロンプトの決まりになったら「チェック項目」にも足す。
置き場所: iCloud `ハコブくん/4コママンガ作成データ/指示/チェック項目と過去の間違い.md`（正）。vbuild.py の `check` がこのファイルを読んで確認の手順を出す。

---

## 進め方（チェックの時間を必ず入れる）

1. **描く** — `python3 vbuild.py NN prompts && python3 vbuild.py NN gen && python3 vbuild.py NN finish`
2. **チェック①（Claude・1枚ずつ）** — `python3 vbuild.py NN measure コマ` で大きさの比を測り、`python3 vbuild.py NN check` で1コマずつの確認用の絵を作り、下の「チェック項目」をすべて見る。まとめて何話も描いたときは、描いた本人とは別のエージェントに1コマずつ見てもらう（同じ目で見ると見落とす）
3. **直す** — 要修正のコマは spec を直して描き直す。描き直したコマは、もう一度チェック①を通す
4. **チェック②（エイイチ）** — 全部のコマを並べた確認用の絵を見せて、OK をもらう。**ここで止まる**。OK の前に声・動画を作らない
5. **ショートにする** — 声 → 冒頭の動き（話ごとに違う動き）→ 書き出し
6. **チェック③（Claude）** — 書き出した動画のコマを並べて、字幕・吹き出しの切れ・はみ出し・30秒以内を見てから渡す

---

## チェック項目（チェック①で1コマずつ全部見る）

### A. 体（いちばん見落としやすい）
- [ ] 人は**腕2本・手2つ・脚2本**。数える。余分な腕・誰のものでもない手・胴が2つ・同じ人が2人、がない
- [ ] 奥にいる人が、机や台の後ろで**上半身だけになっていない**（脚まであるか）
- [ ] 全身が入るコマで、**脚が切れていない**（下の端で切れて白い帯になっていない）。頭が大きすぎない（8頭身）
- [ ] 松葉杖・バッグ・道具は、その人の手で持っている。杖の本数が合っている
- [ ] 座っている人・しゃがんでいる人が、立っている人やロボットより**大きく描かれていない**

### B. 大きさ（並び図 `キャラ/並び図_主要キャラ.png` が正）
- [ ] ハコブくん 115cm・ピカリくん 150cm・高杉 155・寺島 160・白石 160・アバターさん 160・大城 165・小芝 167・槙原 172・中村拓也 175・田中 180・岩田 181・森田茂 163・森田久美子 152・林 158・中村千夏 164
- [ ] 同じ床に立つとき、ハコブくんの上端は大城さんのみぞおち（約70%）。胸や肩・あごまで来ていたら大きすぎ、腰までなら小さすぎ
- [ ] ピカリくんはハコブくんの約1.3倍（ハコブくんの上端＝ピカリくんの肩）。大人の女性と並ぶと頭頂が鼻〜目の高さ
- [ ] **吹き出しや小窓を入れるために、キャラの大きさを変えていない**（話ごとにピカリくんの大きさがバラバラになった原因）
- [ ] 同じ話の4コマで、同じキャラの大きさがそろっている
- [ ] **測って確かめる**: `python3 vbuild.py NN measure コマ番号 [本数]` で、床に立つ人・ロボットの高さの比を出す。並び図の比（例 ピカリくん150÷千夏164＝0.91、ハコブくん115÷大城165＝0.70）から ±0.08 を超えたら描き直すか別の候補を選ぶ。目で見るだけで決めない

#### 大きさが並び図と変わる原因（2026-10-31 に特定。いつも起きる前提で作る）
1. **絵のモデルは数字の大きさを守らない。** 「150cm」「1.3倍」は文字として読むだけで、実際は「コマを埋める・構図が収まる」ように大きさを決める。主役は大きく、ロボットや脇役は余った場所（吹き出しの帯・小窓の横）に入る大きさに縮む
2. **参照の絵（キャラ表）は、どれも画像いっぱいに描かれている。** 1人ずつの絵には「ほかのキャラと比べた大きさ」が入っていない。並び図は何枚もある参照の1枚にすぎず、重みが弱い
3. **背景が緑一色で床の線がない。** 奥行きの手がかりがないので、少し奥・手前に置かれただけで見た目の大きさが変わる（遠近で縮んだのか、設定より小さいのか区別できない）
4. **座る・しゃがむ人の頭を、立っている人の目の高さに描く。** 座った人が立ったロボットより大きくなる
5. **spec に大きさの指示が何本も積み重なり、食い違っていた。** 古い hscale/pscale の文と新しい yline、「slim」の一語など。食い違うとモデルは構図のほうを取る
6. **「ひざ上」「腰上」の指定を無視して全身で描く。** 全身を入れるために全体を縮め、2人の縮み方がそろわない

#### だから作り方で決めること
- 大きさの指示は1か所だけ（yline の頭頂・足もとの位置＋薄緑の枠の下地）。spec に別の大きさの文を足さない。古い文は消す
- 並ぶ2人は**カメラから同じ距離・同じ床**に立たせる。片方を奥・手前にする構図は、大きさを比べるコマでは使わない
- 立つ人と座る人を並べて比べない。座らせるなら、ひざをつく・腰上で切るなど、比べなくてよい構図にする
- 吹き出し・小窓の場所は、キャラの立つ場所と重ならない上の帯にとる。キャラの横に空き地を作らない
- 1コマにつき候補を3〜5枚描き、`measure` で比を出していちばん近いものを選ぶ（1枚で決めない）

### C. ロボットの形
- [ ] ハコブくん: **腕・手・脚がない**。体に文字がない。顔は白い縦長の楕円の目2つと小さい口（目は形を変えない・ウインクなし）。側面の輪は**平らで真ん中に穴・点・同心円がない**。画面の頭が胴の上に乗る（低い箱・電子レンジ形にならない）
- [ ] ピカリくん: **ずんぐり**（頭が大きい・胴が幅広・脚が短く太い）。細身・小さい・子どもサイズにしない。黒いガラスに文字なし・白い縁なし
- [ ] ハコブくんとピカリくんの体が**混ざっていない**（ハコブくんに人型の腕や脚が生える、2体がくっつく）
- [ ] ツカムくん: 作業台の上。顔は台座の正面（白い丸目・口なし）

### D. キャラの見分け
- [ ] 大城=お団子／高杉=あご丈ボブ・眼鏡なし／寺島=丸眼鏡／白石=眼鏡・ポニーテール・エンジニアの上着／槙原=黒縁の眼鏡
- [ ] 同じ話の中で服が変わっていない（夜の寝間着が次のコマで私服になる、など）
- [ ] 名札は白紙（字が崩れて出る）
- [ ] アバターさんの顔は見えない

### E. 文字
- [ ] 吹き出しの字を**1字ずつ**台本と見比べる。抜け・重複・カタカナがひらがなに変わる（リ→り、ッ→っ）
- [ ] 台本にない『』「」が付いていない。台本にない吹き出し・意味のない字の吹き出し・空の吹き出し・英字（GROPING など）がない
- [ ] 吹き出しのしっぽが話す人を向いている。吹き出しが切れていない
- [ ] 縦書きは軽微（できれば横書き）

### F. 話と絵
- [ ] プロットの場面になっている（誰が・何をしている・小道具）。めくる前のコマでオチを見せていない
- [ ] 小道具が変でない（頭の上に扉が浮く、など。扉は床から立つ）
- [ ] ガイドの白い枠や名前の札が絵に写り込んでいない

### G. ショート（書き出したあと）
- [ ] 冒頭の動くハコブくんは話ごとに違う動き（同じ動きを並べない）
- [ ] 声の読み・抑揚が変でない（怪しい語は --try で聞き比べる）
- [ ] 30秒以内・字幕は1行14字・2行まで

---

## 過去の間違い（新しいものを上に足す）

| 日付 | 話・コマ | 間違い | 見つけた人 | 直し方（プロンプト・作り方） |
|---|---|---|---|---|
| 2026-10-31 | 第131話 P3 | 眼鏡を足すために描き直したら、大城さんの向き（横向き→正面）まで変わった | エイイチ（公開後） | 小物や顔の一部だけ直すときは描き直さない。元の絵を Gemini の edit に渡し「ここだけ変える・ほかは同じ」で直す |
| 2026-10-31 | 第130話 P3 | 奥の白石さんがテーブルの後ろで上半身だけになり、下半身がない | エイイチ（公開後） | 奥の人は「テーブルの横に全身で立つ」と書く。人をテーブルの真後ろに置かない |
| 2026-10-31 | 第131話 P3 | 槙原くんの眼鏡がない | エイイチ（公開後） | vbuild の人物表に「黒縁の眼鏡をいつもかけている」を足した。眼鏡のキャラは毎コマ眼鏡を確かめる |
| 2026-10-31 | 第101話 P3 | 大城さんの頭身が変（頭が小さく体が長い） | エイイチ（公開後） | 「大人の女性・約7.5頭身・頭を小さくしない」を足して描き直し |
| 2026-10-31 | 第117話 P4 | ピカリくんが千夏さんより小さく描かれ続けた（5枚中0枚→再度5枚） | 別のエージェント | 原因の1〜6を特定。`measure` で比を出して選ぶ（0.83 を採用。目標0.91）・字の抜け（「向いていよ」）も同時に見る |
| 2026-10-31 | 第93話 | 声「出した方がいいと思う？」の抑揚が変 | エイイチ | 読みを --try で聞き比べて差し替える |
| 2026-10-31 | 第101話 P4 | 大城さん・小芝先生の脚が切れて下が白い帯、頭身が変 | エイイチ | 全身で描く（full と CAMERA OVERRIDE）・下の端で切らない |
| 2026-10-31 | 第109・111・114・115・117・118話 | ピカリくんの大きさがコマごとにバラバラ（吹き出し・小窓に合わせて縮んだ） | エイイチ | 並び図の身長から画像上の頭頂・足もとの位置を決める（vbuild の yline）＋枠を描いた下地を添える |
| 2026-10-31 | 第116話 P1・P4 | ハコブくんに人型の腕・脚が生える、2体が混ざる | エイイチ | 「2体は別の機械・間に隙間・ハコブくんに腕脚なし」の独立セクション（SEP） |
| 2026-10-31 | 第121話 P3 | 高杉さんの腕が3本 | エイイチ | ANATOMY CHECK（腕2本・数える）を人が出る全コマに |
| 2026-10-31 | 第121話 P4 | ハコブくんの形が違う（細長い） | エイイチ | 三面図どおり・全身で描く |
| 2026-10-31 | 第125話 P2 | 扉がハコブくんの頭の上に浮いた板になった | エイイチ | 扉は床から立つ・左の端に蝶番・閉まる途中でハコブくんの頭の角に当たる、と構造で書く |
| 2026-10-31 | 第127話 P4・第94話・第99話ほか | ハコブくんが大きすぎ／小さすぎ（話ごとにバラバラ） | エイイチ | 並び図どおり（yline）。人とハコブくんが並ぶコマは全身で描く |
| 2026-10-31 | 第76話 P4 | 岩田さんの体が崩れる（胴が2つ・松葉杖3本） | エイイチ | 「1人を1回だけ・松葉杖2本・脇の下」の独立セクション |
| 2026-10-31 | 第131話 P3 | 大城さんの腕が3本 | エイイチ | ANATOMY CHECK |
| 2026-10-31 | 第114話 P2 | 絵の中に英字「GROPING」 | 別のエージェント | 場面の英文に動詞をそのまま書かない・「文字なし」 |
| 2026-10-31 | 第130話 P2・第131話 P3 | 同じ吹き出しが2つ・意味のない字の吹き出し | 別のエージェント | 「吹き出しはこの1つだけ」 |
| 2026-10-31 | 第121話 P4・第132話 P1 | 台本にない『』が付く | 別のエージェント | プロンプトに『』の禁止を書くと逆に付くことがある。付いたら描き直して選ぶ |
| 2026-10-30 | 30話すべて | ハコブくんの側面の輪の真ん中に穴 | エイイチ | HAKOBUKUN SIDE RING — FLAT, NO HOLE（毎コマ）。描いた絵は edit で直せる（字や目が変わるので見比べる） |
| 2026-10-30 | ピカリくんの9話 | ピカリくんが細く小さい | エイイチ | 指示の「slim」を削除。PIKARIKUN BUILD — STOUT（頭は全高の1/4・胴幅広・脚短く太い） |
| 2026-10-30 | 30本すべて | 冒頭の動くハコブくんが全部同じ動き | エイイチ | video_rules 9-0b「話ごとに違う動き」。op30.py で作りためた動きを1話1つ |
| 2026-10-30 | 30本 | マンガを確かめずに動画まで作った | エイイチ | チェック②（エイイチの OK）の前に声・動画を作らない |
```


## 作業ログ ― サイトに、横にスワイプして読むページを作った

### 1コマずつ、横にめくって読む

ページのいちばん上に縦長のコマを1枚ずつ出し、スマホでは指で横にめくります。PC では、コマの左右のボタンかキーボードの矢印でめくります。コマの下に「3 / 4」と何コマ目かを出します。

4枚の絵は、ページを開いたときに全部 HTML に入れています。JavaScript が動かなくても横にスクロールすれば読めて、AI や検索エンジンがページを読んだときにも4コマ分の絵があると分かります。

【画像】LOG413_01_pc_viewer.png PCで見た第133話のページ。縦長の1コマ目が中央にあり、左右に丸いボタン、下に「1 / 4」が出ている

【画像】LOG413_02_sp_viewer.png スマホで見た第131話のページ。3コマ目を表示していて、コマのすぐ下に左右のボタンと「3 / 4」、その下にタイトルとデザインノートが続く

【図解】LOG413_swipe_format.html

めくる向きは、Instagram と同じく、指を右から左へ動かすと次のコマにしました。日本のマンガの読む向き（右から左のページ）とは逆ですが、スマホで横にめくる画像に慣れた向きを選びました。

### 3話だけ先に出して見てもらう、はずだった

エイイチの指示は「まず3ページほど作って共有して」でした。ところが、その指示が届く前に29話すべてを公開していました。気づいてすぐに26話を外し、第133・117・73話の3話だけを残しました。29話が出ていたのは数分でした。3話を見てもらい、めくるボタンを2回直してから、残りの26話を戻しました。

### めくるボタンを押すと、コマが画面から切れていた

最初は、ボタンをコマの下に置いていました。PC の画面では、コマ（幅620px・高さ775px）とボタンが1画面に収まらず、ボタンを押そうとするとコマの上が切れていました。

- ねらい：コマを見たまま、めくれるようにする
- 変わったこと：コマの幅を画面の高さから決めるようにした（縦長4:5なので、画面の高さから230pxを引いた分に0.8を掛けた幅）。PC ではボタンをコマの左右の外に、スマホではコマのすぐ下の左右に置いた。ボタンを押したときにコマが切れていたら、コマ全体が見える位置まで自動で動く
- 見込める効果：1280×800 の画面でも、コマ・ボタン・何コマ目かが1画面に収まる（画面で確かめた）。スマホ 390×844 でも同じ

続けて、エイイチから「黒ボタンだと目立ちすぎてデザインノートが目に入らない」と言われ、黒く塗ったボタンを、白地に黒い縁のボタンに変えました。押せないとき（1コマ目の「←」など）は、縁と矢印を薄いグレーにしています。

### 前の話・次の話のカード

記事のページの最後にある「前の記事・次の記事」のカードと同じ形で、マンガのページにも前の話・次の話のカードを付けました。順番は話の番号順です（公開日の順ではない）。英語版のページにも同じカードが付きます。

【画像】LOG413_03_pager.png 第133話のページの最後。デザインノートの下に区切りの線があり、左に「← 前の話 第132話」のカードが出ている

### MangaSwipe.astro（スワイプで読む部品）

サイトは [Astro](https://astro.build/) で作っていて、ページの部品を `.astro` のファイルに書きます。

```astro
---
// 縦長の4コマ（1コマ＝縦長1枚 1080×1350）を、横にスワイプして1コマずつ読むビューワー（2026-10-31 第73〜133話から）。
// 4枚とも HTML に出す（JavaScript がなくても横にスクロールして読める・AI や検索にも4枚が見える）。
// JavaScript は「いま何コマ目か」の表示と、前後のボタン・矢印キーだけを受け持つ。
import { media } from '../lib/media';
interface Props { panels: string[]; alts?: string[]; title: string }
const { panels, alts = [], title } = Astro.props;
const n = panels.length;
---
<div class="msw" data-n={n}>
  <div class="msw-track" tabindex="0" role="region" aria-roledescription="carousel" aria-label={`${title}（${n}コマ・横にスワイプして読む）`}>
    {panels.map((p, i) => (
      <figure class="msw-slide" aria-roledescription="slide" aria-label={`${i + 1} / ${n}`}>
        <img src={media(p)} alt={alts[i] || `${title}（${i + 1}コマ目）`} width="1080" height="1350"
          loading={i === 0 ? 'eager' : 'lazy'} decoding="async" draggable="false" />
      </figure>
    ))}
  </div>
  <button class="msw-btn msw-prev" type="button" aria-label="前のコマ" disabled><i class="ms" aria-hidden="true">arrow_back</i></button>
  <button class="msw-btn msw-next" type="button" aria-label="次のコマ"><i class="ms" aria-hidden="true">arrow_forward</i></button>
  <div class="msw-bar"><p class="msw-count" aria-live="polite"><b class="msw-now">1</b><span>/ {n}</span></p></div>
</div>
<script>
  for (const box of document.querySelectorAll<HTMLElement>('.msw')) {
    const track = box.querySelector<HTMLElement>('.msw-track')!;
    const prev = box.querySelector<HTMLButtonElement>('.msw-prev')!;
    const next = box.querySelector<HTMLButtonElement>('.msw-next')!;
    const now = box.querySelector<HTMLElement>('.msw-now')!;
    const n = Number(box.dataset.n) || 1;
    const at = () => Math.round(track.scrollLeft / track.clientWidth);
    // ボタンで送るとき、コマが画面の上下で切れていたら、コマ全体が見える位置まで動かす
    const fit = () => {
      const r = track.getBoundingClientRect();
      const head = 96;
      if (r.top < head || r.bottom > innerHeight) scrollBy({ top: r.top - Math.max(head, (innerHeight - r.height - 64) / 2), behavior: 'smooth' });
    };
    const go = (i: number) => track.scrollTo({ left: Math.max(0, Math.min(n - 1, i)) * track.clientWidth, behavior: 'smooth' });
    const show = () => {
      const i = at();
      now.textContent = String(i + 1);
      prev.disabled = i <= 0;
      next.disabled = i >= n - 1;
    };
    let t = 0;
    track.addEventListener('scroll', () => { cancelAnimationFrame(t); t = requestAnimationFrame(show); }, { passive: true });
    prev.addEventListener('click', () => { fit(); go(at() - 1); });
    next.addEventListener('click', () => { fit(); go(at() + 1); });
    track.addEventListener('keydown', (e) => {
      if (e.key === 'ArrowRight') { e.preventDefault(); go(at() + 1); }
      if (e.key === 'ArrowLeft') { e.preventDefault(); go(at() - 1); }
    });
    show();
  }
</script>
<style>
  /* コマとページャーが1画面に収まる幅にする（縦長 4:5 なので、画面の高さから幅を決める） */
  .msw { position: relative; width: min(100%, calc((100svh - 230px) * 0.8)); min-width: min(100%, 320px); margin: 0 auto; }
  .msw-track {
    display: flex; overflow-x: auto; overflow-y: hidden;
    scroll-snap-type: x mandatory; overscroll-behavior-x: contain;
    scrollbar-width: none; background: #fff;
  }
  .msw-track::-webkit-scrollbar { display: none; }
  .msw-track:focus-visible { outline: 2px solid var(--dark); outline-offset: 2px; }
  .msw-slide { flex: 0 0 100%; margin: 0; scroll-snap-align: start; scroll-snap-stop: always; }
  .msw-slide img { display: block; width: 100%; height: auto; aspect-ratio: 4 / 5; user-select: none; -webkit-user-drag: none; }
  .msw-bar { height: 64px; display: flex; align-items: center; justify-content: center; }
  .msw-count { margin: 0; display: flex; align-items: baseline; gap: 6px; color: var(--ink); }
  .msw-now { font: 600 28px/1 var(--sans); }
  .msw-count span { font: 400 14px/1 var(--sans); color: var(--ink-3); }
  /* ボタン：PC はコマの左右の外（コマの縦の真ん中）、スマホはコマの下の左右 */
  .msw-btn {
    position: absolute; width: 48px; height: 48px; border: 2px solid var(--dark); border-radius: 50%;
    background: #fff; color: var(--dark); cursor: pointer;
    display: inline-flex; align-items: center; justify-content: center;
    top: 0; bottom: 64px; margin: auto 0;
  }
  .msw-prev { left: -80px; }
  .msw-next { right: -80px; }
  .msw-btn .ms { font-size: 24px; }
  .msw-btn:disabled { border-color: #d6d6d6; color: #c4c4c4; cursor: default; }
  @media (max-width: 799px) {
    .msw-btn { top: auto; bottom: 8px; margin: 0; }
    .msw-prev { left: 0; }
    .msw-next { right: 0; }
  }
</style>
```

### MangaPage.astro（マンガのページ）

データに `panels`（4枚の絵）があるときはスワイプの部品で、ないとき（前の横長の話）は今までどおり表紙と本編の2枚で出します。

```astro
---
// 4コマのページ（日本語・英語版で共通）。下に関連する記録（Studio と同じく HRI の新しい6件＋Load more）
import Base from '../layouts/Base.astro';
import RecordCard from './RecordCard.astro';
import LoadMore from './LoadMore.astro';
import MangaSwipe from './MangaSwipe.astro';
import { ymd } from '../lib/format';
import { media, mediaHtml } from '../lib/media';
import { seriesCards, allManga, allEnglish } from '../lib/records';
import { textOf, abs, AUTHOR, PUBLISHER, SITE, SITE_NAME } from '../lib/seo';
interface Props { m: any; path: string }
const { m, path } = Astro.props;
const related = await seriesCards('HRI');
// 英語版は本文が英語なので、説明文も英語の本文から作る（Studio から移した説明文は日本語のままのため）
const isEn = path.startsWith('/english-4-koma');
const description = (isEn ? textOf(m.body, 150) : m.description) || textOf(m.body, 120);
const pairList = isEn ? allManga : allEnglish;
const alternates = pairList.some((x) => x.slug === m.slug)
  ? [{ lang: isEn ? 'ja' : 'en', path: `${isEn ? '/manga' : '/english-4-koma'}/${m.slug}` }] : [];
// 前の話・次の話（話の番号の順。記事の「前の記事・次の記事」と同じカード。2026-10-31）
const epNo = (x: any) => Number((x.slug.match(/^ep(\d+)$/) || [])[1]);
const seq = (isEn ? allEnglish : allManga).filter((x: any) => !Number.isNaN(epNo(x))).sort((a: any, b: any) => epNo(a) - epNo(b));
const at = seq.findIndex((x: any) => x.slug === m.slug);
const prevEp = at > 0 ? seq[at - 1] : null;
const nextEp = at >= 0 && at < seq.length - 1 ? seq[at + 1] : null;
const base = isEn ? '/english-4-koma' : '/manga';
const epLabel = (x: any) => isEn ? `Episode ${epNo(x)}` : `第${epNo(x)}話`;
const title = isEn ? `${m.title} | 4-Koma Manga | ${SITE_NAME}` : `${m.title} | 4コママンガ | ${SITE_NAME}`;
const jsonLd = {
  '@context': 'https://schema.org', '@type': 'Article',
  headline: m.title, description, url: SITE + path, mainEntityOfPage: SITE + path,
  inLanguage: isEn ? 'en' : 'ja', datePublished: m.published, dateModified: m.published,
  image: (m.panels ? m.panels.map((p: string) => abs(media(p))) : [abs(media(m.comic)), abs(media(m.cover))]).filter(Boolean),
  genre: isEn ? '4-panel comic' : '4コママンガ', author: AUTHOR, publisher: PUBLISHER,
};
---
<Base title={title} description={description} ogImage={media(m.cover) || undefined} path={path}
  lang={isEn ? 'en' : 'ja'} ogType="article" published={m.published} alternates={alternates} jsonLd={jsonLd}>
  <article class="manga">
    <div class="mmeta"><span class="mlabel">{m.label}</span><span class="tag">{m.character}</span><span class="date">{ymd(m.published)}</span></div>
    {m.panels ? <MangaSwipe panels={m.panels} alts={m.panel_alts} title={m.title} /> : m.cover && <img class="mcover" src={media(m.cover)} alt={m.cover_alt || `${m.title}（${m.label} 表紙）`} width="1080" height="1350" />}
    {!m.panels && m.comic && <img class="mcomic" src={media(m.comic)} alt={m.comic_alt || `${m.title}（${m.label} 本編）`} width="1080" height="1350" loading="lazy" />}
    <h1 class="mtitle">{m.title}</h1>
    <div class="mbody" set:html={mediaHtml(m.body)} />
    {(prevEp || nextEp) && (
      <nav class="pager" aria-label={isEn ? 'Previous and next episodes' : '前後の話'}>
        {prevEp ? <a class="pg pg-prev" href={`${base}/${prevEp.slug}`}><span class="pg-k">{isEn ? '← Previous' : '← 前の話'}　{epLabel(prevEp)}</span><span class="pg-t">{prevEp.title}</span></a> : <span />}
        {nextEp ? <a class="pg pg-next" href={`${base}/${nextEp.slug}`}><span class="pg-k">{isEn ? 'Next' : '次の話'}　{epLabel(nextEp)} →</span><span class="pg-t">{nextEp.title}</span></a> : <span />}
      </nav>
    )}
  </article>
  <section class="related">
    <div class="panel">
      <h2 class="sec-h">マンガの背景にある記録 | Related Records</h2>
      <LoadMore limit={6} total={related.length}>{related.map((c) => <RecordCard item={c} />)}</LoadMore>
    </div>
  </section>
</Base>
<style>
  .manga { width: 620px; max-width: calc(100% - 48px); margin: 0 auto; padding: 104px 0 80px; }
  .mmeta { display: flex; align-items: center; gap: 12px; margin-bottom: 16px; }
  .mlabel { font: 400 28px/28px var(--sans); }
  .mcover, .mcomic { width: 100%; height: auto; }
  .mtitle { margin: 24px 0 12px; font: 600 20px/30px var(--sans); }
  .mbody :global(p) { font: 400 16px/2 'Noto Sans JP', sans-serif; margin: 0 0 16px; color: #333; }
  /* 前の話・次の話：記事ページ（record/[slug].astro）の .pager と同じ形 */
  .pager { display: grid; grid-template-columns: 1fr 1fr; gap: 16px; margin: 64px 0 0; padding-top: 32px; border-top: 1px solid #ddd; }
  .pg { display: flex; flex-direction: column; gap: 8px; padding: 16px; border-radius: 8px; background: #fff; box-shadow: 0 8px 16px rgba(0,0,0,.08); }
  .pg:hover .pg-t { text-decoration: underline; }
  .pg-next .pg-k { text-align: right; }
  .pg-k { font: 400 12px/18px var(--sans); color: var(--ink-3); }
  .pg-t { font: 600 14px/1.6 var(--sans); color: var(--ink); overflow-wrap: anywhere; }
  @media (max-width: 599px) { .pager { grid-template-columns: 1fr; } .pg-next .pg-k { text-align: left; } }
</style>
```

### 1話ぶんのデータ（第133話）

絵は Cloudflare の [R2](https://developers.cloudflare.com/r2/)（画像や動画を置く倉庫のようなサービス）に `manga_ep{番号}_p{1〜4}.webp` の名前で入れ、データには住所だけを書きます。デザインノートは、その話の吹き出しとプロットをもとに、別のエージェントが今までの話と同じ3段の形で書きました。

```json
{"slug": "ep133", "title": "ハンコがそろうまでの2か月", "label": "MANGA EP133", "character": "ハコブくん", "published": "2026-10-31T01:00:00.000Z", "cover": "/media/manga_ep133_cover_v2.webp", "comic": "", "format": "vertical", "panels": ["/media/manga_ep133_p1.webp", "/media/manga_ep133_p2.webp", "/media/manga_ep133_p3.webp", "/media/manga_ep133_p4.webp"], "panel_alts": ["…", "…", "…", "…"], "description": "…", "body": "<p>■ …</p>"}
```


## 作業ログ ― 一覧の顔になる表紙を作った

### 印象に残るコマから吹き出しを消し、タイトルを載せた

縦長の話は、最初は一覧のカードに1コマ目を出していました。エイイチから「今までの表紙と同じように吹き出しを削除して、印象に残るコマを表紙にして」と言われ、今までの表紙と同じ形に作り直しました。

- 話ごとに、印象に残るコマを1つ選ぶ（1コマ目とは限らない。例：第131話は非常停止ボタンを「バチン」と叩く3コマ目）
- 吹き出しと台詞を Gemini の画像の編集で消す。「バチン」「カラン」のように絵に直接描いた音の字は残す。吹き出しのないコマ（7話）はそのまま使う
- 上にスプレッドシートのタイトルで「第N話 タイトル」を載せる。長いときは「第N話」とタイトルの2行にする

最初は字が今までの表紙より細く見えると言われました。前の表紙の字を測ると、線の太さは約13.4px、字の色は灰色の #242424 でした。同じ大きさで並べて比べ、Noto Sans CJK JP の Black・96px が同じ太さだったので、それに合わせました（はじめに使った Bold・92px は約10.2px）。

【画像】LOG413_05_covers.jpg 第133〜124話の表紙10枚。どれも上に「第N話 タイトル」があり、下に吹き出しを消したコマがある

【画像】LOG413_04_archive_covers.png 4コマの一覧のページ。新しい表紙のカードが3列に並んでいる

### cover_edit.py（吹き出しを消す）

```python
"""縦長4コマの表紙用：選んだコマから吹き出しと字を消す（Gemini の API・2026-10-31）"""
import sys, os, concurrent.futures
sys.path.insert(0, os.path.expanduser('~/mnt/PixelstoMotors/ハコブくん/4コママンガ作成データ/道具'))
import vbuild as V
PICK = {130:3,131:3}
NOEDIT = {133,128,116,111,101,99,76}
PROMPT = """Edit this manga panel. Remove EVERY speech bubble and thought bubble completely, including their tails and all the text inside them (ALSO the speech bubble inside the small square inset window in the corner: erase that bubble entirely so the inset shows only the person in the room). Where a bubble was, redraw what would be behind it: plain white background, or the continuation of the wall, hair, body or object that the bubble covered. Keep sound-effect lettering drawn directly on the art (like バチン, カラン, ジリリリ) as it is. Keep EVERYTHING else exactly the same: same characters, faces, eyes, poses, sizes, positions, clothes, robots, screentone, line style, black-and-white manga look, white background, 4:5 framing. Do not add any new text, bubble, border, inset window, portrait or object. Where the bubble was, leave plain white background (and continue the thin vertical line if it passed behind the bubble)."""
here = os.path.dirname(os.path.abspath(__file__))
open(here + '/cover_edit/_prompt.txt', 'w', encoding='utf-8').write(PROMPT)
eps = [int(a) for a in sys.argv[1:]] or [e for e in PICK if e not in NOEDIT]
def job(e):
    src = os.path.expanduser(f'~/mnt/PixelstoMotors/ハコブくん/4コママンガ作成データ/縦長/第{e}話/仕上げ/第{e}話_P{PICK[e]}_1080x1350.png')
    return V.gen_one(here + '/cover_edit/_prompt.txt', here + f'/cover_edit/ep{e}_P{PICK[e]}', [("the manga panel to edit", src)], "4:5")
with concurrent.futures.ThreadPoolExecutor(6) as ex:
    for r in ex.map(job, eps): print(r)
```

### make_covers.py（表紙を組む）

```python
"""縦長4コマの表紙（2026-10-31）：上に「第N話 タイトル」（スプレッドシートのタイトル）、下に吹き出しを消したコマ"""
from PIL import Image, ImageDraw, ImageFont
import numpy as np, glob, json
FB='/usr/share/fonts/opentype/noto/NotoSansCJK-Black.ttc'
U='/mnt/user-data/uploads/PixelstoMotors/ハコブくん/_サイト掲載_20261031/'
T=json.load(open('/home/claude/manga_notes/_bubbles.json'))
PICK={133:2,132:2,131:3,130:3,129:2,128:2,127:1,126:3,125:3,124:2,123:2,118:3,117:3,116:3,115:2,114:3,113:2,111:2,109:1,101:1,100:1,99:2,97:3,96:3,95:3,94:3,93:3,76:2,73:2}
W,H=1080,1350; X0=56; MAXW=W-2*X0
font=ImageFont.truetype(FB,96,index=0)
for e,k in PICK.items():
    ed=glob.glob(U+f'cover_edit/ep{e}_P{k}_*.jpg')
    src=sorted(ed)[-1] if ed else U+f'media/manga_ep{e}_p{k}.webp'
    p=Image.open(src).convert('RGB').resize((W,H),Image.LANCZOS)
    a=np.asarray(p).astype(np.int16); a[a.min(2)>232]=255; p=Image.fromarray(a.astype(np.uint8))
    head=f'第{e}話'; t=T[str(e)]['title']; one=f'{head} {t}'
    lines=[one] if font.getlength(one)<=MAXW else [head,t]
    c=Image.new('RGB',(W,H),'white'); d=ImageDraw.Draw(c); y=62
    for ln in lines:
        f=font
        while f.getlength(ln)>MAXW: f=ImageFont.truetype(FB,f.size-4,index=0)
        d.text((X0,y),ln,font=f,fill=(36,36,36)); y+=f.size+18
    top=y+40; A=H-top
    g=np.asarray(p.convert('L'))<235; ys=np.where(g.any(1))[0]; xs=np.where(g.any(0))[0]
    cy0,cy1,cx0,cx1=ys.min(),ys.max(),xs.min(),xs.max(); ch=cy1-cy0
    s=min(A*0.94/ch,1.45) if ch<A else A/ch
    q=p.resize((round(W*s),round(H*s)),Image.LANCZOS)
    mx=(cx0+cx1)/2*s; my=(cy0+cy1)/2*s
    if s>=1:
        L=int(min(max(mx-W/2,0),q.width-W)); Tp=int(min(max(my-A/2,0),q.height-A))
        b=Image.new('RGB',(W,A),'white'); b.paste(q.crop((L,Tp,min(q.width,L+W),min(q.height,Tp+A))),(0,0)); c.paste(b,(0,top))
    else:
        t0=int(cy0*s); b=Image.new('RGB',(q.width,A),'white'); b.paste(q.crop((0,t0,q.width,min(q.height,t0+A))),(0,0)); c.paste(b,((W-q.width)//2,top))
    c.save(f'manga_ep{e}_cover_v2.webp','WEBP',quality=88,method=6)
    c.resize((360,450)).save(f'_s{e}.jpg')
eps=list(PICK)
for gi in range(0,29,10):
    S=Image.new('RGB',(5*370,2*460),'#888')
    for i,e in enumerate(eps[gi:gi+10]): S.paste(Image.open(f'_s{e}.jpg'),((i%5)*370,(i//5)*460))
    S.save(f'_grid{gi//10}.jpg',quality=85)
```


## 作業ログ ― 公開後に見つかった絵の間違いを直した

公開してから、エイイチがスマホで見て4か所を見つけました。

| 話・コマ | 間違い | 直し方 |
|---|---|---|
| 第130話 3コマ目 | 奥の白石さんが、作業台の後ろで上半身だけになっていた | 白石さんを作業台の横に、頭から足まで描いた |
| 第131話 3コマ目 | 槙原くんの眼鏡がない | 人物の設定に「黒縁の眼鏡をいつもかけている」を足した |
| 第101話 3コマ目 | 大城さんの頭が小さく体が長い | 「大人の女性・約7.5頭身」を足して描き直した |
| 第131話 3コマ目（直したあと） | 眼鏡を足すために描き直したら、大城さんの向きまで横向きから正面に変わった | 元の絵を Gemini の編集に渡し、眼鏡だけを足した |

【画像】LOG413_06_ep131_fix.png 第131話3コマ目の3つの版。左が元の絵（槙原くんに眼鏡がない）、中が描き直した版（大城さんが正面を向いた）、右が元の絵に眼鏡だけを足した版

最後の1件から、決まりを1つ足しました。**顔や小物だけを直すときは、コマを描き直さず、元の絵を部分的に直す。** 描き直すと、直したい所以外の構図まで変わります。

直した絵は、前と同じ名前では R2 に上書きできないので、`manga_ep131_p3_v3.webp` のように新しい名前で入れ、データの住所を替えました。表紙に使っていたコマは、表紙も作り直しました。


## 作業ログ ― 29話の SNS の投稿を予約した

29話ぶんの X・LinkedIn・Facebook の文を作りました。マンガの投稿はタグを付けず、エイイチの話し方（〜だよ・〜だね）で書く決まりです。X と LinkedIn は、11/2（月）の第133話から番号の大きい順に、毎朝7:30 を中心に1話ずつ予約しました。最後は 11/27（金）19:30 の第73話です。Facebook は自動では出さないので、ファイルに入れておき、エイイチが手で出します。

第100話の文には、AI が「ついに100話目」「100話まで続いた」と書いていました。サイトには前から120話台の話があるので、事実と合わないため外しました。

第133話の投稿文のファイル（MANGA_ep133_sns_posts.json）です。

```json
{
 "meta": {
  "episode": 133,
  "date": "2026-10-31",
  "title": "第133話 6つのハンコ",
  "url": "https://pixelstomotors.com/manga/ep133"
 },
 "posts": {
  "x": "「ロボットの準備は、もう終わってます！」\nなのに走り出せるまで2か月以上。足りなかったのは、6つの部署のハンコだった。\n\n導入の時間って、ほとんど人の了承をそろえる時間なんだよね。4コマ『ハコブくん』第133話\nhttps://pixelstomotors.com/manga/ep133",
  "linkedin": "新しい病棟にロボットを入れる打ち合わせ。ホワイトボードには6つの欄が並ぶ。薬剤部、看護部、施設、情報システム、防火、医療安全。技術担当の槙原さんは「ロボットの準備は、もう終わってます！」。でもハンコは少しずつしか増えず、2か月たっても1つの欄だけが空いたまま。病院で物を運ぶロボット、ハコブくんの4コママンガ（フィクション）の第133話だよ。\n\nロボットの準備は、導入の準備の一部でしかないんだよね。薬剤部は運ばない薬を、施設は充電の場所を、防火は止まってはいけない場所を決める。これまでの回で描いてきたことが、全部ここに集まってくる感じ。どれもロボットの性能では片づかないし、どの部署にも、もっともな待ったの理由がある。だから一つ後回しになると、全体が止まってしまう。\n\n最後のハンコが押されて、看護師の大城さんが「ロボットを運ぶ前に、みんなの都合を運んでたのね」。これ、描いてて自分でもうまいこと言うなと思った（笑）白石さんは、次の病棟では6つの欄を最初の日に配ると決める。何をどの部署が決めるのかを先に見せれば、みんな同時に考え始められる。導入を速くするのは、ロボットの準備より、了承をそろえる段取りなんだと思う。\n\n皆さんの職場で新しい仕組みを入れたとき、一番時間がかかったのはどこでしたか？\n\nhttps://pixelstomotors.com/manga/ep133",
  "facebook": "この回は、ここしばらく描いてきた話のまとめみたいな回。\n\n運ばない薬、止まってよい場所、非常ベル、エレベーター、電波。一つずつ描いてきたら、気づいたんだよね。これ全部、別々の部署が決めることだって。ロボットがいくら準備万端でも、それぞれの部署が「うちはこれでいい」と言ってくれないと走り出せない。\n\nそれで、ホワイトボードの6つの欄に、ハンコが少しずつ増えていく回にしてみた。その間ずっと「ワタシハ、イツデモ走レマス」と待っているハコブくんが、ちょっと切ない。\n\n大城さんの「ロボットを運ぶ前に、みんなの都合を運んでたのね」は、自分でもお気に入りのセリフ。最後の「出発シマス」で、やっと走り出せてよかったね、という気持ちで描き終えたよ。\n\nhttps://pixelstomotors.com/manga/ep133"
 }
}
```


## 作業ログ ― 次の50話のプロットを、現場の調査から作った

### 病院とロボットの現場で起きている問題を100件集めた

次の50話（第134〜183話）は、作り話の思いつきではなく、実際の現場で起きている問題から作ることにしました。病院の搬送ロボット・消毒ロボット・薬剤や検体の自動化・遠隔操作のロボットなどについて、論文・病院の報告・県の実証の報告書・ニュースから100件を集めました。出典で確かめられたものが95件、推測が5件です。すでに描いた133話と同じ論点は外しました。

例えば、海外の病院の調査では、ゆっくり走るロボットを狭い廊下で追い越せず、職員の仕事が遅れていました（第134話「オ先ニドウゾ」）。神奈川県の病院の実証では、受付の前に置いた案内ロボットが、案内板だと思われていました（第157話「ただの案内板」）。

### codex に、プロットを論破するつもりで見てもらった

[codex](https://openai.com/codex/) は OpenAI の AI で、Mac の「codex 係」が依頼文を自動で渡します。ウェブで出典を開いて確かめながら、文の見落としを探してもらいました。観点は5つです。デザインノートの事実、日本の病院で起こりえるか、解決策が危ないことを教えていないか、今までの話との重なり、キャラの決まり。

1回目の判定は「このまま載せるのは不可」で、50話のうちそのままでよいのは13話、直す34話、場面の差し替え3話でした。危ないと言われたのは、採血管の血をロボットの都合で別の管に移す話や、動いている爪に紙を差し込んで試す話などです。

エイイチからは「あくまでマンガだから面白さは必要。codex は厳しすぎるきらいがあるから注意して」と言われました。そこで、取り入れる指摘を4つに絞りました。現実に危ないことを教える結末、日本の病院の職種に合わない役割、キャラの設定違い、出典を超えた言い切り。話をつまらなくするだけの指摘は採らず、41話を直してから、スプレッドシートの134〜183行目に「未着手」で入れました。

- ねらい：現場で本当に起きていることを、笑える形で描く
- 変わったこと：例えば第181話は、ロボットアームのツカムくんを台車に載せて走らせる話だったが、「ツカムくんは作業台の上のアーム」という設定に反する。そこで、ハコブくんに肩車させる図面の話にし、ツカムくんは作業台から動かさないまま「マダ ココデイイ」と言わせた
- 見込める効果：デザインノートが出典の範囲に収まり、読む人が現実の話として誤解しにくくなる。面白さが残ったかは、描いてから確かめる

### codex の検証結果（1回目）

```markdown
# codex 敵対的検証 結果 1回目（ハコブくん_新プロット_20261031）

- 日時: 2026-10-31 09:28（JST）
- 依頼文: codex_敵対的検証依頼_ハコブくん_新プロット_20261031.md（md5 51854f6c71d9fb6bc3df1dc8d6088d89・97,143 バイト）
- 題（依頼文の1行目）: # codex 敵対的検証依頼：ハコブくん_新プロット_20261031
- codex: codex-cli 0.164.0-alpha.11.1
- モデル: gpt-6.1-sol
- 考える深さ: high
- ウェブ検索: あり（検索した回数 100）
- かかった時間: 12分57秒
- 使ったトークン: 282,507
- 指摘の数: 0（うち出典のリンクが付いたもの 0）
- 出典の URL: 42件（別々・文の中に張られた回数 9）

---
**このまま完成稿としてスプレッドシートに載せるのは不可です。50話中、OKは13話、直す34話、場面の差し替え3話です。**

research.md と指定出典を照合しました。「開けなかった」は「内容が誤り」とは区別しています。ただし、裏付けを確認できない記述は、公開前に解消する必要があります。

観点は、①事実、②現実味、③教訓・安全、④重複、⑤作品の決まり。「差し替え」はテーマの廃案ではなく、現在の場面設定を残しにくいという判定です。重複については、既存話の全文ではなく、提示された一覧との比較です。

**1．話ごとの判定**

| No. | 判定 | 観点 | 理由（出典との食い違い・問題点） | 最小の直し案 |
|---|---|---|---|---|
| 134 | OK | ①③④ | 低速のロボットを追い越せず職員が遅れる記述を確認。待避場所の用意は、そこから導く設計案として妥当。135とは「走行中の追い越し」に限定すれば区別できる。[S1] | — |
| 135 | 直す | ①③④ | 出典は再計算による足止めを報告しているが、「迷っても進む」という解決を裏付けない。位置や進路の安全が不確かなまま進む教訓になる。[S3] | 4コマ目とNote末尾を「狭い区間に入る前に経路を確かめる。安全を確認できないときは停止する」に。134との差は「計画する時機」に置く。 |
| 136 | OK | ①③ | 歩行者等と重量車両のレーン分け、ロボットの所属の不明確さを確認。施設と決めたレーンを地図に反映する解決は成立する。[S2] | — |
| 137 | OK | ①② | シフト交代時の廊下での立ち往生と、重大な技術的問題はないという担当者の説明を確認。[S6] | — |
| 138 | OK | ①③ | 受付前の混雑、開始位置の変更、タブレットからの遠隔開始を確認。解決が出典と対応する。[S14] | — |
| 139 | OK | ①③ | 扉の向こうを近接センサーで先読みできず、天井カメラとサーバーで進入判断を補う構成を確認。[S13] | — |
| 140 | 直す | ①③ | 紙くずの逸話には検索で補強が得られたが、指定NBC本文は取得できなかった。「軽い紙・ビニールなら踏む」は、巻き込みや付着、誤分類を無視した一般化。[S8] | 4コマ目を「停止距離や回り込み幅を見直す。正体不明の物は止まって知らせる」に。紙・ビニールを一律に無視する設定は削除。 |
| 141 | 直す | ③ | 隅に閉じ込められたという証言は確認できる。ただし「扉のそばに止まる」だけでは出口をふさぐ問題が残る。[S11] | 4コマ目を「人の出入りの空間を残して停止する。残せないときは同乗しない」に。 |
| 142 | OK | ①③④ | 衝突したという看護師の証言と、国内実証でのガラス壁付近の走行禁止設定を確認。既存63とは「地図の古さ」でなく「センサーが認識しにくい材質」で区別できる。[S5][S14] | — |
| 143 | OK | ①③④ | 進路に入った人へ直進し、手前で停止した描写と、威圧感を述べる記事を確認。既存38に近いが、「止まる性能」と「進路の意図が読めること」の違いとして成立する。[S5] | — |
| 144 | 直す | ③⑤ | マナーへの不満は原論文で確認。一方、2コマ目は大城さんが譲った相手が曖昧で、3コマ目の抗議とつながらない。3コマ目は吹き出し3つ。また、寄って止まった人を常に先にすると譲り合いの停止が起こり得る。[S4原論文] | 2コマ目を「車いすを通す場所を確かめようと大城さんが止まる」に。3コマ目の森田さんの台詞を削除。4コマ目は「狭い区間では患者側を先に通す」と限定。 |
| 145 | 直す | ①③⑤ | 原論文で強い言葉を発したのは**病棟事務職**。看護師とする取り違えがある。3コマ目は吹き出し3つ。「電話中なら無期限に黙る」は急ぎの薬では不適切。[S4原論文] | Noteを「電話中の病棟職員」に。電話の声は田中先生と明記し、ロボットの再通知を画面表示にする。4コマ目に「通常便は静かに通知。至急便は担当端末へ」を追加。 |
| 146 | 直す | ①③ | 原論文には蹴った・損傷させたいと述べた職員がいるが、「蹴ろうと思った職員の方が多い」という数量比較は確認できない。衝撃をすべて「邪魔だった証拠」と断定できない。[S4原論文] | Noteを「蹴った、または損傷させたいと話す職員がいた。不満や運用負担を調べる手掛かりになる」に。3コマ目で故障の有無も点検する。 |
| 147 | 直す | ②③ | 気送管との役割比較とメーカーの反論は確認。「同じ検体で競争」は実検体を不要な比較試験に使う描写になる。また、小さいという理由だけで気送管へ振り分けられない。[S11] | 2コマ目を「同じ重さの模擬検体で比較」に。4コマ目を「検体の種類・容器・搬送条件で使い分ける」に。 |
| 148 | 直す | ① | 指定解説は取得不可。原論文では、使用済みリネン回収の積載作業が病棟側へ移り、担当者が別業務で対応できず回収待ちになったことを確認。引用文そのものの確認とは分けるべき。[S4原論文][S4b] | 出典を原論文に変更し、Noteの引用を「積み込む人が別業務で手を離せず、回収待ちのリネンが残った」に。 |
| 149 | 直す | ① | 16人中8人は確認できる。しかし、職員は調査で不信を説明しており、「苦情を言わずに戻った」ことまで調べた資料ではない。[S2] | Noteを「頼れないと感じ、ロボットに任せるはずの作業を自分で行う職員がいた。苦情だけでなく利用状況も見る」に。 |
| 150 | 直す | ① | 7段階→28段階は確認。ただし28にはロボットの停止・待機・再調整、周囲の人とのやり取りも含まれる。「増えた21個＝人が黙って支えた手作業」ではない。[S3] | Noteを「停止や待機、周囲との調整まで含めると28段階あった」に。4コマ目の「増えた21個」を「増えた工程」にする。 |
| 151 | OK | ①③ | 看護師・薬剤師への到着通知を、試作と反復試験で改良した記述を確認。端末通知は本作の具体化として妥当。[S12] | — |
| 152 | 直す | ①②③④ | 出典は「遅れて使えなくなることを**懸念して**任せなかった」という証言。実際に破棄・再採血が発生したという報告ではない。「一度崩れると信頼は戻らない」も裏付けがない。一般的な荷物の分類は既存107に強く近い。[S11] | Noteを「検体の使用可能時間に間に合わないことを懸念し、任せなかった」に。3コマ目は「検査部が使用可否を確認」。4コマ目は検体別の搬送条件・到着時間の検証に限定する。 |
| 153 | OK | ①③④ | 道がふさがれて停止した記述を確認。位置・理由を依頼者へ返す部分は本作の設計案。既存47・121とは「配送依頼と停止情報の紐付け」に限定して区別できる。[S12] | — |
| 154 | 直す | ①⑤ | 付き添いへの疑問は証言と対応するが、「付き添いなしになるまで効果を名乗らない」は強すぎる。付き添い込みでも正味の効果は評価できる。3コマ目は吹き出し3つ。[S11] | Note末尾を「付き添い時間を含めて効果を報告する」に。3コマ目の「また付き添い？」を削除。 |
| 155 | 直す | ① | 2分10秒→2分56秒は確認できた。ただし本文抽出では、その数値を「本館1階だけ」と結び付けられなかった。近くの本館1階等の表示は案内先内訳の図にも使われている。[S14] | Noteから「本館1階での」を外す。区分を残すなら元図の対応を再確認する。 |
| 156 | OK | ①④⑤ | 「利用を遠慮する職員がいた」というコメントを確認。理由の具体化は劇中の設定として成立。既存48の空き表示に近いが、利用可能な物・依頼権限を示す点が異なる。吹き出し数は上限内。[S14] | — |
| 157 | 直す | ① | 案内板と思われたことは確認。ただし報告書は、人が接近する**まで**録音音声を再生する運用であり、「近づいたら再生した」とは異なる。[S16] | Noteを「話しかけを促す録音音声を再生する対策をとった」にし、起動条件の説明を削除。 |
| 158 | 直す | ① | 指定本文は取得不可。テープ上の固定経路を走ることから、あらゆる機種で迂回不能とまでは言えない。「迷わない」も保証できない。[S8] | 1コマ目を「走る経路を固定できます」に。Noteを「線外へ迂回しない運用では、その道を空けておく手間も生じる」に限定。 |
| 159 | 差し替え | ①③ | 報告書の「常に画面を気にする」の主語は、**別の場所で対応する遠隔対応者**。現場の隣の職員に置き換わっている。改善課題は患者接近の通知であり、ロボットが手に負えない時だけ呼ぶことではない。[S16] | 画面を気にして書類作業を中断する役をアバターさんへ移す。4コマ目は「患者の接近を操縦席へ通知。通信断は現場にも通知」に差し替える。 |
| 160 | 直す | ②③ | 受取側が検査室を出る負担と、アームによる受渡しの必要性は出典と対応。ただし槙原さんが実検体の検査作業を通常担当する設定がなく、受渡し口での挟まれも未解決。[S17] | 冒頭に「模擬検体による工程試験」と付記。4コマ目は「挟まれ防止を備えた受渡し口で、停止中のハコブくんから密閉容器を受け取る」に。 |
| 161 | OK | ①③④ | 録音音声に訪問者が反応し、前に出たり返事したりする記述を確認。既存65の想定外利用者とは、録音が対話と受け取られる問題に限定すれば区別できる。[S7] | — |
| 162 | 直す | ① | 男性の声を望む傾向はメーカー担当者の発言として確認できるが、理由は分からないとされている。「女性の声が病棟の声にまぎれる」は調査結果ではない。[S7] | 2コマ目を「この声だと、ほかの声にまぎれちゃう」に。Note冒頭を「米国のメーカー担当者は、男性の声を望む看護師がいると話している」に。 |
| 163 | 直す | ③④ | 家族の負担感は確認。現状は既存10の「押し付け」と強く重なる。また、病室入口で待ち続ける解決は出入りを妨げ得る。[S30] | 4コマ目を「断られたら、その面会中は再び勧めない。呼ばれるまで所定の待機場所に戻る」にし、「断りを保持する」点へ絞る。 |
| 164 | 直す | ①②③④ | 診察室侵入は二次紹介の検索本文で確認した範囲。扉が開いていたことが原因とは確認できない。診察中の開放を換気目的で当然視する描写も避けたい。地図の進入禁止だけでは既存74に近い。[S22] | 1コマ目を「扉を閉める途中」に。Noteは「米国の事例を紹介する二次記事では」と明記。4コマ目を「届け先でも、入室許可がなければ手前で待つ」に。 |
| 165 | OK | ①③④ | 充電場所がふさがれると回ったという証言と、病院による充電場所等の障害物除去の呼びかけを確認。既存125の避難経路とは、充電設備へのアクセスで区別できる。[S11][S9] | — |
| 166 | 直す | ①③ | 出典で追加学習したのは主に**天井カメラ画像を処理する認識系**。ロボットが対象の前を往復するだけで自力学習した事例ではない。また「よそで覚えた見分け方は効かない」は言い切りすぎ。[S13] | Noteを「病院固有の形には追加データが必要になることがある」に。4コマ目を「カメラ映像を集め、二人が認識器を学習・評価する」に。 |
| 167 | 直す | ①③④ | 事前確認後にも通信不調があったことは確認。しかし昼・混雑・受信電波の低下が原因という記述はない。電波強度が高くても映像通信が安定するとは限らない。[S15] | 朝／昼を「事前確認／実運用」に変更。「電波の数字」を「映像の途切れ・遅延」に。4コマ目は実運用中の通信品質を測り、利用可能区域を確認する。 |
| 168 | 直す | ①③ | 電源切れと露出したRFIDカードの問題は確認。ただし出典は建物への直接接続も施設の防犯方針に反し得ると述べており、「本番では必ず建物とつなぐ」は過剰。[S17] | Note末尾を「施設の防犯方針に合う、継続運用できる連携方法を選ぶ」に。4コマ目は施設側と恒久対策を決める場面にする。 |
| 169 | 直す | ②③ | 電源がなく毎日移動した事実は確認。150cmのロボットを看護師一人で台車へ載せる描写は、指定された取扱方法がなく危険。立ったままの充電も機種の仕様次第。[S16] | 3コマ目を「電池を残して、指定の移動手順で充電場所へ」に。4コマ目は「メーカー指定の姿勢・方法で充電できる位置へ移す」とする。 |
| 170 | 直す | ①③⑤ | 2022年の脆弱性であり、修正が提供された事例。役割別表示だけでは認証・権限検査の欠陥を直せない。ゲストへ院内位置を無条件で公開する必要もない。[S21補足] | Noteに「2022年に公表され、修正された」を追加。4コマ目は「修正を適用し、ゲストには認証を要求」に。映像の患者は既存人物に指定する。 |
| 171 | 差し替え | ①②③ | 指定NBC本文を取得できず、250／500mgの詳細は未確認。加えて、看護師が病棟で裸錠を補充・分包し、エンジニアが配薬前監査をする場面は、現在の職種設定では成立しない。バーコードは薬剤師の確認責任の代わりにならない。[S23][D1] | 場所を「試験室」、薬を「模擬錠剤」に差し替える。4コマ目は「瓶と補充先を照合する試験」。Noteの実例の規格数値は、原典確認まで保留する。 |
| 172 | 直す | ①②③④ | 組合の主張という帰属は正しい。ただし、日本で予備棚と紙表だけを残すと、変更後の指示や既払出し分との食い違いが起こる。「病棟ごと止まる」も出典を超える。[S24] | 3コマ目の「昨日の袋」を「最新の投薬指示」に。4コマ目は「薬剤部と決めた患者別予備薬・最新指示・払出し済み記録」で継続する。既存120との差も薬の照合に絞る。 |
| 173 | 直す | ②③ | 検体を人が探す問題は確認。ただし槙原さんが追加検査を通常受け付ける役割が不明。氏名だけで管を選ぶ解決も不十分。国内の追加検査手順には、オーダーと検査可能条件の確認がある。[S25][D3] | 「模擬検体で検索機能を試験中」と明記。4コマ目は氏名入力でなく「検体IDで検索し、管のIDも照合」に。 |
| 174 | 直す | ①②③ | 出典は規格外サイズの検体を分注する負担を述べている。採血管は添加剤・採血量等で使い分けるため、アームに合わせて一種類へ統一してはいけない。エンジニアが採血管の血液を移し替える描写も危険。[S25][D2] | 3コマ目は分注負担の説明図に変更。4コマ目を「必要な採血管を維持し、太さに対応できるホルダーやつかみ方を選び直す」に。 |
| 175 | OK | ①③ | 手による清掃・消毒をUV-Cで代替できないことと、清掃が粗略になる懸念を確認。補助として手順に位置付ける解決は妥当。[S27][S28] | — |
| 176 | 直す | ①③ | 進入を防ぎ切れなかった研究と、扉の動きを検知して停止する製品説明を確認。扉センサーで分かるのは扉の動きであり、在室人数ではない。曝露中に「目を閉じて」と叫ぶより照射停止を先に描く必要がある。[S28][S29] | 3コマ目で白石さんが外から非常停止。4コマ目の台詞を「扉ガ開イタノデ、止メマシタ」にし、再開は無人確認後とする。 |
| 177 | 直す | ②③ | 使用後清掃の追加時間は介護資料で確認。ただし、感染対策個室から通常区域へ戻ってから清拭する流れを、標準手順のように描くのは避けるべき。[S30] | 1コマ目を「個室入口で受け渡した後、感染対策で決めた清拭場所で拭く」に。清拭後に通常区域へ戻す。 |
| 178 | 直す | ①③ | 誤変換・打ち直し・利用の少なさは確認。ただし、修正時間が入力時間を超えたという測定結果ではない。数字だけ＋うなずきでは、患者・測定項目・時刻の取り違えを解決できない。[S30] | Noteを「修正負担が利用を妨げることがある」に。4コマ目で患者ID・体温・数値を表示し、看護師が確認操作して記録を確定する。 |
| 179 | 直す | ①③ | 先端工具の危険確認は出典と対応。ただし資料は法的要求そのものではなく、安全確認用のチェックリスト。動く爪へ手持ちの紙を差し込む試験は、既存131にも反する。[S31] | Noteを「豪州の機関が公開する安全チェックリストでは」に。紙は停止中に固定し、人が可動範囲の外へ退いてから試験する。 |
| 180 | 直す | ①③ | モードの識別は確認項目だが、表示灯は安全防護の代わりにならない。腕が顔の前を通ってから低速化する問題は、ノックと灯りだけでは解消しない。[S31] | 4コマ目を「扉を開ける前に保護停止し、停止確認後に入室できる仕組み」に。緑は単なる低速でなく「入室可能な停止状態」を示す。 |
| 181 | 差し替え | ①⑤ | 移動台車上のアームには広いリスク評価が必要、という出典は正しい。しかしツカムくんを搬送台へ載せて走らせる前提が「作業台の上のロボットアーム」という固定設定に反する。[S31] | 1コマ目を「移動台車化の図面を見せる」に。4コマ目も図面上に制限を書き込み、ツカムくん自身は作業台に置いたままにする。 |
| 182 | 直す | ①②③⑤ | HCAI資料は大容量で本文取得不可。床の耐荷重は、単純な総重量だけで判定できず、輪荷重等も施設側へ確認する必要がある。「荷台」は引き出しで運ぶ設定ともずれる。[S33] | 「荷台」を「引き出し」に変更。3コマ目を「施設側へ確認すると、この積み方では許容条件を超える」に。4コマ目も確認された条件に基づく積載量とする。 |
| 183 | 直す | ①③ | 2〜3日、約1週間という記述は確認。ただし「1週間でトラブルが出そろう」という保証ではない。資料には約2週間後に全看護師へ操作説明した記述もある。[S15] | 「最初の1週間だけ」を「最初の1週間は毎日」に。Noteは「よく起きるトラブルが1週間程度で現れた」にし、その後も相談先を残す。 |

**2．全体の判定**

修正管理用の一覧として載せることはできますが、**完成稿としての掲載は見送り**です。

必ず修正・確認を解消する話は次の37話です。

**135、140、141、144、145、146、147、148、149、150、152、154、155、157、158、159、160、162、163、164、166、167、168、169、170、171、172、173、174、176、177、178、179、180、181、182、183**

特に先に直すべきなのは、危険な解決を示す **135・140・174・179・180**、職種と業務が合わない **171**、固定設定に反する **181** です。

重複の強い組合せは、**152と既存107、163と既存10、172と既存120**。上表のように、それぞれ「検体搬送の事前検証」「断りの保持」「最新指示と払出し記録の照合」に絞れば、元の題材を保ったまま区別できます。

50話内では、148・150・154・158・160・177がすべて「見えない人手を数える」で終わりがちです。積載担当、工程の観察、付き添い、経路維持、受取動線、清拭という**具体的な対象をNoteの結論にも残す**必要があります。

作品の決まりについて、吹き出し超過は **144話3コマ目・145話3コマ目・154話3コマ目**。ピカリくんの顔への文字表示、操縦者の顔出し、ツカムくんの口の描写は、提示文にはありませんでした。背景の群衆は、独立した役や台詞を持つ新キャラクターとして描かない前提です。

**3．確かめた出典の一覧**

出典番号は research.md に合わせています。「取得不可」は今回の確認環境での結果で、リンク切れと断定するものではありません。

| 出典 | URL・取得状況 | 確認できた内容／確認できなかった範囲 |
|---|---|---|
| S1 | [指定URL](https://www.en.plan.aau.dk/robots-in-hospitals-may-create-more-work-for-staff-n109619)は取得不可。[同大学の掲載先][S1]は本文確認 | デンマークの病院調査。低速ロボットを追い越せないこと、職員の付き添い等。 |
| S2 | [論文PDF][S2]：本文確認 | レーンの不明確さ、厨房職員16人中8人が作業を自分で行ったこと。 |
| S3 | [ACM記事](https://interactions.acm.org/archive/view/march-april-2025/the-invisible-work-of-human-robot-collaboration-when-streamlined-processes-meet-the-complexity-of-real-world-practices)は403。[大学所蔵PDF][S3]で本文確認 | 図1・2の7段階／28段階。追加分には停止・待機・再調整・周囲との相互作用を含む。 |
| S4 | [研究紹介ページ][S4]、[著者公開の原論文][S4原論文]：確認。[二次要約](https://bakadesuyo.com/?p=18751)は取得不可 | 原論文で電話中の病棟事務職の発言、蹴った等の報告、マナーへの不満、積載負担を確認。 |
| S4b | [解説記事][S4b]：取得不可 | 当該記事の引用文は未確認。積載負担自体はS4原論文で確認。 |
| S5 | [KQED][S5]：本文確認。[PBS](https://www.pbs.org/newshour/health/meet-the-r2d2-of-hospital-technology)は403。[Marketplace](https://marketplace.org/2016/02/23/orderly-zipping-around-hospital-may-be-robot)は取得不可 | 看護師による衝突の証言、直進して手前で停止した場面。同系統の記事を独立した複数証拠とは数えていない。 |
| S6 | [Hospital Goes Robotic][S6]：本文確認 | シフト交代時の立ち往生。重大な技術的問題がないという担当者の説明。 |
| S7 | [Computerworld][S7]：本文確認 | 訪問者が録音音声に反応する記述。男性の声を望む傾向についてのメーカー担当者の発言。理由は特定されていない。 |
| S8 | [NBC News][S8]：取得不可。[同じ逸話を含む記事](https://iol.co.za/technology/2004-07-07-hospitals-turn-to-robot-couriers/)は検索本文のみ確認 | 紙くず2枚を避けた逸話は補強できたが、指定記事全文は未確認。紙を踏んでよいことや、安全な無視条件は確認できない。 |
| S9 | [UNC Health][S9]：本文確認 | 充電場所・受渡し場所を物品でふさがないという院内向け案内。 |
| S11 | [Proof News][S11]：本文確認 | 付き添い、充電場所閉塞時の旋回、エレベーター内の閉じ込め、検体搬送への懸念、気送管との比較とメーカーの反論。 |
| S12 | [Changi General Hospital][S12]：本文確認 | シンガポールの救急外来。経路閉塞、看護師・薬剤師への到着通知の反復改良。 |
| S13 | [トヨタ開発記事][S13]：本文確認 | 扉の先を天井カメラで確認する構成、病院固有の台車・ベッド画像の収集、サーバー側の認識処理。 |
| S14 | [神奈川県・院内誘導PDF][S14]：本文確認 | 開始位置変更、ガラス付近の走行禁止、利用を遠慮した職員のコメント、移動時間2分10秒→2分56秒。図版画像は取得できず、「本館1階」と数値の対応は未確定。 |
| S15 | [指定URL](https://www.pref.kanagawa.jp/documents/97808/robohon3-iryou-nyuitaiin.pdf)は取得不可。[別配置の同名PDF][S15]で確認 | 事前の通信確認と実運用時の不調。操作習得2〜3日、頻発トラブル約1週間、約2週間後の全員説明。昼の混雑による電波低下は未記載。 |
| S16 | [神奈川県・フロア案内PDF][S16]：本文確認 | 案内板と認識されたこと、接近までの録音再生、遠隔対応者の画面監視負担、患者接近通知の不足、電源確保のための移動。 |
| S17 | [Frontiers論文PDF][S17]：本文確認 | エストニアの病院試験。検体受取時の退出負担、後付け扉装置の電源・防犯問題。恒久的な直接接続も施設方針との調整が必要と記載。 |
| S21 | [TechCrunch][S21]：本文確認。[発見者の開示報告書][S21補足]も確認 | 2022年の権限・認証問題と修正。現在も未修正の一般仕様であるかのようには書けない。 |
| S22 | [Slashdot][S22]：直接取得不可、検索本文のみ確認 | UCSFの診察室侵入を紹介する二次記事。SF Chronicle原記事と、侵入原因は未確認。 |
| S23 | [NBC Washington][S23]：403等で取得不可 | 250／500mgの補充ミスの詳細は今回独立確認できなかった。 |
| S24 | [MaltaToday][S24]：本文確認 | マルタの看護師組合が述べた頻繁な停止、隣接病棟からの借用、機械の仕事を再確認する負担。組合の主張としての報道。 |
| S25 | [旧URL](https://www.westgard.com/anguish-automation.htm)は取得不可。[現在の掲載先][S25]で本文確認 | 検体探索担当者、管サイズの制限に伴う分注負担。採血管の添加剤まで統一してよいという意味ではない。 |
| S27 | [Infection Control Today][S27]：本文確認 | UV-Cは手作業による清掃・消毒の補助。機械への過信で清掃が粗略になる懸念。 |
| S28 | [UV-C実地研究][S28]：本文確認 | オーストリアの病院研究。区域を閉鎖しても人が出入りしたこと、清掃・消毒への追加手段としての位置付け。 |
| S29 | [OhmniLabs][S29]：本文確認 | 入口に設置する機器の動体検知による停止、遠隔開始、無人確認の手順。メーカーによる特定製品の説明。 |
| S30 | [厚生労働省PDF][S30]：本文確認 | p.17の職員調査に誤変換・打ち直し・追加清掃時間、p.18の家族調査に接近への負担感。日本の病院搬送ロボットの調査ではない。 |
| S31 | [SafeWork NSW掲載PDF][S31]：本文確認 | 工具の挟まれ・鋭利部、モード切替の識別、移動台車化のリスク評価。冒頭で、法令・規格を置き換える資料ではなく、作成者の見解が当局方針と一致するとは限らないと明示。 |
| S33 | [HCAI資料][S33]：本文取得不可。[公式一覧](https://hcai.ca.gov/facilities/building-safety/resources/building-safety-construction-webinars/)は確認 | 公式リンクの存在は確認。約30MBの資料取得が制限され、耐荷重に関する具体文は未確認。 |
| D1・追加確認 | [厚労省「調剤業務のあり方について」][D1]：本文確認 | 薬剤師の最終責任、非薬剤師に行わせる作業の条件、薬剤師自身による最終確認。171の運用確認に使用。 |
| D2・追加確認 | [神戸大学病院・検体取扱研修資料][D2]：本文確認 | 採血管は添加薬剤が異なり、採取した血液を別の採取容器へ移さないよう明記。174の確認に使用。 |
| D3・追加確認 | [神戸大学病院・検査の手引き][D3]：本文確認 | 検体ID・本人照合、追加検査のオーダーと可否確認、項目別の搬送・保存条件。152・173の確認に使用。 |

[S1]: https://www.aau.dk/robots-in-hospitals-may-create-more-work-for-staff-n109619
[S2]: https://vbn.aau.dk/ws/files/461098840/SHTI_286_SHTI210639.pdf
[S3]: https://vbn.aau.dk/ws/portalfiles/portal/770994090/3711940.pdf
[S4]: https://peopleandrobots.wisc.edu/publications/robots-in-organizations-the-role-of-workflow-social-and-environmental-factors-in-human-robot-interaction-inproceedings/
[S4原論文]: https://pages.cs.wisc.edu/~bilge/pubs/2008/HRI08-Mutlu.pdf
[S4b]: https://www.hinnovic.org/post/a-robot-as-a-co-worker
[S5]: https://www.kqed.org/futureofyou/121043/hospital-uses-robots-instead-of-people-to-cart-things-around
[S6]: https://www.hcinnovationgroup.com/home/article/13013240/hospital-goes-robotic
[S7]: https://www.computerworld.com/article/1563100/robots-to-the-nurses-station-stat.html
[S8]: https://www.nbcnews.com/health/health-news/robots-gaining-traction-hospitals-flna1c9475445
[S9]: https://news.unchealthcare.org/2018/01/the-tug-robots-are-coming/
[S11]: https://www.proofnews.org/moxi/
[S12]: https://www.cgh.com.sg/about-cgh/overview/cgh90thanniversary/care-grows-here/engineering-care-together
[S13]: https://global.toyota/jp/mobility/frontier-research/40390261.html
[S14]: https://www.pref.kanagawa.jp/documents/71550/robohon3-iryou-innaiyuudou.pdf
[S15]: https://www.pref.kanagawa.jp/documents/71550/robohon3-iryou-nyuitaiin.pdf
[S16]: https://www.pref.kanagawa.jp/documents/71550/robohon3-iryou-huroaannai.pdf
[S17]: https://www.frontiersin.org/journals/robotics-and-ai/articles/10.3389/frobt.2022.922835/pdf
[S21]: https://techcrunch.com/2022/04/12/aethon-robots-hospitals-hijacks/
[S21補足]: https://assets.website-files.com/5d2ad783e06f4c19469d363a/625551dd440d0b187fa96d38_JekyllBot-5-Vulnerability-Disclosure-Report.pdf
[S22]: https://hardware.slashdot.org/story/05/06/17/227249/pharm-bot-goes-on-rampage
[S23]: https://www.nbcwashington.com/news/local/prescription-for-error-pharmacy-robots/2090275/
[S24]: https://www.maltatoday.com.mt/news/national/111610/medicine_dispensing_robot_worthless_total_failure_nurses_union_claims
[S25]: https://westgard.com/essays/trends/anguish-automation.html
[S27]: https://www.infectioncontroltoday.com/view/robot-does-not-replace-evs-why-uv-c-must-remain-adjunct-cleaning
[S28]: https://link.springer.com/article/10.1186/s13756-021-00945-4
[S29]: https://ohmnilabs.com/content/how-to-safely-disinfect-with-a-uv-robot/
[S30]: https://www.mhlw.go.jp/content/12300000/001091713.pdf
[S31]: https://www.safework.nsw.gov.au/__data/assets/pdf_file/0011/1364366/Guidelines-for-safe-collaborative-robot-design-and-implementation-cobot-workplace-safety-checklist.pdf
[S33]: https://hcai.ca.gov/document/bsu-webinar-handout-robots-robotics-in-hospitals/
[D1]: https://www.mhlw.go.jp/content/000498352.pdf
[D2]: https://www.hosp.kobe-u.ac.jp/kenshu/wp-content/im/data_file/html_file/training-kensabu.pdf
[D3]: https://www.hosp.kobe-u.ac.jp/kensa/guidance_kensa.html
```


## 作業ログ ― まだやっていないこと

- 30本のショート（YouTube に出す30秒の動画）を、描き直したコマで作り直す。第93話は「出した方がいいと思う？」の声の抑揚が変なので、読み方を聞き比べて直す
- 英語版のページと英語の投稿文
- 次の50話を描く。描く前に、台帳を読み、大きさは測って選ぶ
