kugi's notebook

やったこと、思ったことなどつらつらと書きます

kugi4koma - 「Googleドライブから4コマ漫画用データを作る」編

はじめに

前回の記事では、Codexと相談しながら4コマ漫画のコマ検出スクリプトとビューワーの試作版を作るところまでを書きました。

kugi-masa.hatenablog.com

今回は「Googleドライブから4コマ漫画用データを作る」編になります。

ChatGPT Proのサブスクリプションが切れたので 今回はClaude CodeのProプランに切り替えました。

前回のおさらい

前回までの構成はこうでした。

スキャン画像をローカルフォルダに置く
  ↓ 
コマ検出スクリプトでコマを切り出す
  ↓ 
出力された画像とJSONをサイトのフォルダーにコピーする
  ↓
GitHubへコミットしてCloudflareへデプロイする

手作業での画像切り取りはスクリプト化できたので、だいぶ楽になりそうです。

ただ、1話追加する度にスクリプト実行して、整形した画像データをアップロード、サイトの更新、といった工程を毎回行うのはさすがに面倒です。

また前回から、スキャンデータをUSB管理からGoogleドライブへ直接アップロードする方法に変更したので、こちらも有効活用したいです。

ゆる～く描くのがモットーなので、公開の手間はできるだけゼロに近づけたいところです。

今回やったこと

そこで今回はこうしました。

プリンターでスキャン
  ↓ (プリンターのクラウド連携)
Google ドライブ
  ↓ (GitHub Actionsを手動実行)
コマ検出・WebP化
  ↓
Cloudflare R2 (画像 + カタログJSON)
  ↓
サイトが実行時に読み込む

プリンターでのスキャンが完了したら、 作品公開用のパイプラインをGitHub Actionsで実行することで、画像切り取りスクリプトの実行からサイトへの公開まで行ってくれます。

Google ドライブのkugi4koma用フォルダにスキャン原稿が追加されたら自動でGitHub Actionsを実行するフローにできれば一番楽ではありますが、変更検知用の通知チャンネルが最大7日で失効して自動更新されないなど、対応が複雑になっていきそうだったので、パイプライン実行は今回手動としました。

Googleドライブから差分だけ取ってくる

Google Drive APIを叩くために、読み取り専用のサービスアカウントを作り、

Google Drive API の概要  |  Google for Developers

対象フォルダーをそのアカウントに共有する形にしました。

メタデータだけ見て差分を判定し、更新データに対して整形を行い、Cloudflare R2へアップロードします。

実際に1本追加して回したときのログがこちらです。

Found 9 episodes on Drive (8 unchanged, 1 to publish).
Downloaded 1 source images (0 non-image files ignored).
Normalized 1 episodes into 6 WebP files.
Uploaded 6 objects to R2 bucket ***.
Published catalog with 9 comics (5 objects).

差分の1話だけ処理し、無事に公開まで行われました。

GitHub Actionsで実行

先程の流れをGitHub Actionsのworkflow_dispatch（手動実行）で動くようにしました。

publish-comics.yml

# Google Driveの原稿フォルダを差分公開するワークフロー。
#
# 必要なリポジトリ設定:
#   Secrets:
#     GOOGLE_SERVICE_ACCOUNT_JSON  Drive読み取り専用サービスアカウントの鍵JSON
#     R2_ACCOUNT_ID                CloudflareアカウントID
#     R2_ACCESS_KEY_ID             R2 APIトークンのアクセスキー
#     R2_SECRET_ACCESS_KEY         R2 APIトークンのシークレット
#     R2_BUCKET                    アップロード先バケット名
#     DRIVE_FOLDER_ID              既定のGoogle DriveフォルダID(入力省略時に使用)
#
# DRIVE_FOLDER_IDもSecretsに置く。リポジトリを公開した場合にActionsログや
# 設定画面からフォルダIDが見えないようにするため(Secretsはログで自動マスクされる)。
#
# 画像とカタログのR2への公開はこのジョブ内で完結する。サイトはカタログを実行時に
# 読み込むため、リポジトリへのコミットもサイトの再デプロイも発生しない。
name: Publish comics

on:
  workflow_dispatch:
    inputs:
      drive_folder:
        description: "Google DriveフォルダIDまたはURL(省略時はDRIVE_FOLDER_ID Secret)"
        required: false
        type: string
      dry_run:
        description: "確認のみ(R2アップロード・PR作成なし)"
        required: false
        type: boolean
        default: false
      force:
        description: "publisher stateを無視して全作品を再公開する"
        required: false
        type: boolean
        default: false

concurrency:
  group: publish-comics
  cancel-in-progress: false

permissions:
  contents: read

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - name: Check out preview branch
        uses: actions/checkout@v4
        with:
          ref: preview

      - name: Resolve Drive folder
        env:
          INPUT_FOLDER: ${{ inputs.drive_folder }}
          DEFAULT_FOLDER: ${{ secrets.DRIVE_FOLDER_ID }}
        run: |
          folder="${INPUT_FOLDER:-$DEFAULT_FOLDER}"
          if [ -z "$folder" ]; then
            echo "drive_folder input is empty and the DRIVE_FOLDER_ID secret is not set." >&2
            exit 1
          fi
          echo "DRIVE_FOLDER=$folder" >> "$GITHUB_ENV"

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"
          cache: pip
          cache-dependency-path: scripts/requirements-publish.txt

      - name: Install publish dependencies
        run: python -m pip install -r scripts/requirements-publish.txt

      - name: Write Google service account credentials
        env:
          GOOGLE_SERVICE_ACCOUNT_JSON: ${{ secrets.GOOGLE_SERVICE_ACCOUNT_JSON }}
        run: |
          if [ -z "$GOOGLE_SERVICE_ACCOUNT_JSON" ]; then
            echo "GOOGLE_SERVICE_ACCOUNT_JSON secret is not set." >&2
            exit 1
          fi
          credentials="$RUNNER_TEMP/google-credentials.json"
          printf '%s' "$GOOGLE_SERVICE_ACCOUNT_JSON" > "$credentials"
          echo "GOOGLE_APPLICATION_CREDENTIALS=$credentials" >> "$GITHUB_ENV"

      # 終了コード2は「一部の原稿が処理できなかったが、残りは公開済み」を表す。
      # 成果物の保存とPR作成は続行し、ジョブ全体は最後のステップで失敗させる。
      - name: Publish changed episodes
        id: publish
        env:
          R2_ACCOUNT_ID: ${{ secrets.R2_ACCOUNT_ID }}
          R2_ACCESS_KEY_ID: ${{ secrets.R2_ACCESS_KEY_ID }}
          R2_SECRET_ACCESS_KEY: ${{ secrets.R2_SECRET_ACCESS_KEY }}
          R2_BUCKET: ${{ secrets.R2_BUCKET }}
        run: |
          flags=()
          if [ "${{ inputs.dry_run }}" = "true" ]; then
            flags+=(--dry-run)
          fi
          if [ "${{ inputs.force }}" = "true" ]; then
            flags+=(--force)
          fi
          set +e
          python scripts/publish_comics.py "$DRIVE_FOLDER" \
            --output ProcessedData "${flags[@]}"
          status=$?
          set -e
          echo "status=$status" >> "$GITHUB_OUTPUT"
          if [ "$status" -ne 0 ] && [ "$status" -ne 2 ]; then
            exit "$status"
          fi

      - name: Upload processing manifest for audit
        uses: actions/upload-artifact@v4
        with:
          name: processing-manifest-${{ github.run_id }}
          path: ProcessedData/manifest.json
          retention-days: 30
          if-no-files-found: ignore

      - name: Fail if any episode was skipped
        if: ${{ steps.publish.outputs.status == '2' }}
        run: |
          echo "::error::一部の原稿を処理できませんでした。上の Publish changed episodes のログを確認してください。処理できた作品は公開済みで、失敗した作品は次回実行時に再試行されます。"
          exit 1

スマホからも実行できます。

枠線の誤検出

テスト実行している際に、誤検出したケースがあったのでその話もしようと思います。

Expected 8 horizontal frame lines, detected 9

4コマ漫画のページには横罫線が8本あるはずなのに、9本検出されたというエラーです。 原因の作品は20241104_鯛me_fliesでした。

見てみると、2コマ目に描いた看板の横線がコマ幅いっぱいに伸びていて、 これがコマ枠の9本目として検出されていました。

ありがとう、ｸﾛｰﾄﾞ

まとめ

今回は「Googleドライブから4コマ漫画用データを作る」編ということで、 スキャンした原稿がGoogle ドライブに上がってから、サイトに公開されるまでを自動化しました。

これで、スキャンしてGitHub Actionsからパイプライン実行するだけで新作が公開できるようになりました。GitHub Mobileでスマホからも実行できるので通勤中にも公開できますね！

kugi4koma自体は体裁を整えたらそろそろ公開できそうなのですが、今回準備を進めるなかで初めてカスタムドメインを取得して、せっかくなのでこのブログも移行しようかなという気持ちになってきました。

どうせなら個人サイトにブログやら、4コマ漫画やらがぶら下がっているような感じにしたいなーと思っています。

なので『kugi4koma - 「公開」編』の前に、 『ブログ移行しました』になりそうです。

kugi4koma - 「4コマ漫画ビューワーの準備」 編

はじめに

このお盆休み期間でCodexと相談しながら、これまで描いてきた4コマ漫画をまとめて読める「kugi4koma」というサイトを作り始めました。

今回の記事は「4コマ漫画ビューワーの準備」編になります。

経緯

「kugi日記」のはじまり

これまでの年越し振り返り記事などでも触れてきましたが、 私は上京して社会人になったタイミングで不定期で日常の4コマ漫画を描くようになりました。

きっかけは新生活の準備のために無印良品へ行った際に見かけた4コマノートです。

www.muji.com

それまでお絵描きをしたことはなかったものの、自分で何か描いてみたいという気持ちはずっとあり、 ちょうど新生活が始まるタイミングでもあったので、ゆる～く描いてみようと思い、 日常の出来事を書き始めました。

更新頻度は年々落ちているのですが、ネタ帳には題材を書き溜めつつ、 「描きたいときに描く」をモットーにゆる～く描いています。

そんなこんなで5年半が過ぎ、先日4コマノートの折り返し地点まで来ました。

公開までの準備

描いた漫画は

などいろいろな場所で公開しているのですが、アナログで書いた原稿を公開するまでの準備が何気に大変です。

まずは画像化したいので、最初の頃はスマホのカメラやMicrosoft Lens (旧 Office Lens)などで撮影し、色調補正など微調整をした画像を使っていました。

Microsoft Lens の廃止 | Microsoft Learn (Microsoft Lensアプリは廃止されたみたいです...)

そこからプリンターでスキャンするようになり、スキャンしたデータをUSB経由でPCに取り込み、 コマごとに切り取りをしたうえで各SNSで公開するような流れを取っていました。

大学生協で買ったプリンターは今でも現役

そもそも、ゆる～く描くことがモットーなのに、公開の準備に手間がかかってしまうのは本意ではありません。

スキャンしたデータをコマ割りを検出して、画像化して投稿の準備までしてくれたら楽なのに...

と何度も頭をよぎるのですが、如何せん4コマを描くペースも年々落ちているので、 何も考えずに画像の切り取りもアナログでやり過ごしていました。

ただ、いつか役に立つかも？という気持ちでスキャンついでにデータ整理はしていました。

コマごとの画像と全体画像

Codexで試す夏

ちょうど先月とある場所でChatGPT Proの1か月無料コードをいただいたのにあまり使えていなかったのと、 お盆休みで時間もあったのでCodexでいろいろ試してみることにしました。

それに合わせ、プリンターのデータ取り込みもUSBではなく、GoogleDrive連携に切り替えました。

【インクジェット/レーザー プリンター・スキャナー】クラウド接続機能の設定方法｜ブラザー

(なぜ今までクラウド接続できると気づかなかったのか...)

方針の壁打ち

まずは状況と実装方針の整理もかねて壁打ちします。

元々の達成したかったことはスキャンした原稿を投稿用に自動整形でしたが、 ついでに「kugi日記」専用のビューワーサイトを作ってみたくなりました。

モデルには Sol5.6 を使いました

  • データの準備
    • 原稿画像の取り込み
    • Web用に画像の軽量化
    • キーワードなどの情報付与
  • 4コマ漫画ビューワー
    • 各話の一覧表示
    • 1コマずつ順番に読む機能
    • タイトルや公開年、キーワードでの検索

に分けて考えられそうです。

原稿画像のコマ検出と自動切り取り

元々手作業でやっていた作業の自動化です。

スキャンついでに画像データのフォルダ整理や命名もルール化していたのがここで役に立ちました！

  1. YYYYMMDD_Title形式の作品フォルダーを探す
  2. フォルダーと同名の全体画像を読み込む
  3. EXIF情報に従って画像の向きを補正する
  4. 画像をグレースケール化し、横方向の枠線を8本検出する
  5. 2本ずつ組み合わせて4つのコマ領域を求める
  6. 各コマを1200 × 800 pxへ整形する
  7. サムネイル、全体表示画像、manifest.jsonを生成する

上記を行うPythonスクリプトを用意してもらいました。

normalize_images.py

"""Create web-ready four-panel comic assets from one complete-page scan."""

from __future__ import annotations

import argparse
import json
import re
from dataclasses import dataclass
from datetime import datetime
from pathlib import Path

import numpy as np
from PIL import Image, ImageOps


EPISODE_PATTERN = re.compile(r"^(?P<date>\d{8})_(?P<title>.+)$")
IMAGE_SUFFIXES = {".jpg", ".jpeg", ".png", ".webp"}
PANEL_SIZE = (1200, 800)
PANEL_MARGIN = 24
FULL_SIZE = (PANEL_SIZE[0], PANEL_SIZE[1] * 4)
THUMBNAIL_SIZE = (600, 400)
BACKGROUND = (255, 255, 255)

# Frame detection tolerates slightly slanted, faint, or JPEG-compressed ink lines.
DARK_THRESHOLD = 160
LINE_WINDOW = 17
MIN_FRAME_LINE_WIDTH_RATIO = 0.72
SOURCE_FRAME_PADDING = 6


@dataclass(frozen=True)
class EpisodeSource:
    directory: Path
    episode_id: str
    published_at: str
    title: str
    full: Path


@dataclass(frozen=True)
class DetectedLine:
    y: int
    start_x: int
    end_x: int


def image_files(directory: Path) -> list[Path]:
    return sorted(
        path
        for path in directory.iterdir()
        if path.is_file() and path.suffix.lower() in IMAGE_SUFFIXES
    )


def discover_episodes(source_root: Path) -> list[EpisodeSource]:
    """Discover episodes using only the image whose name matches its folder."""
    episodes: list[EpisodeSource] = []
    errors: list[str] = []

    for directory in sorted(path for path in source_root.rglob("*") if path.is_dir()):
        match = EPISODE_PATTERN.fullmatch(directory.name)
        if not match:
            continue

        # Files named 1, 2, 3, and 4 are deliberately ignored.
        full_candidates = [
            path for path in image_files(directory) if path.stem == directory.name
        ]
        if len(full_candidates) != 1:
            errors.append(
                f"{directory}: full image must match the folder name "
                f"(found {len(full_candidates)})"
            )
            continue

        date_text = match.group("date")
        published_at = datetime.strptime(date_text, "%Y%m%d").date().isoformat()
        episodes.append(
            EpisodeSource(
                directory=directory,
                episode_id=directory.name,
                published_at=published_at,
                title=match.group("title"),
                full=full_candidates[0],
            )
        )

    if errors:
        raise ValueError("Invalid episode folders:\n- " + "\n- ".join(errors))
    if not episodes:
        raise ValueError(f"No episode folders found under {source_root}")
    return episodes


def open_rgb(path: Path) -> Image.Image:
    with Image.open(path) as image:
        oriented = ImageOps.exif_transpose(image)
        if oriented.mode in {"RGBA", "LA"}:
            rgba = oriented.convert("RGBA")
            background = Image.new("RGBA", rgba.size, (*BACKGROUND, 255))
            background.alpha_composite(rgba)
            return background.convert("RGB")
        return oriented.convert("RGB")


def longest_true_run(mask: np.ndarray) -> tuple[int, int]:
    """Return the start and exclusive end of the longest True run."""
    padded = np.pad(mask.astype(np.int8), (1, 1))
    transitions = np.diff(padded)
    starts = np.flatnonzero(transitions == 1)
    ends = np.flatnonzero(transitions == -1)
    if starts.size == 0:
        return (0, 0)
    widths = ends - starts
    index = int(np.argmax(widths))
    return (int(starts[index]), int(ends[index]))


def detect_horizontal_frame_lines(image: Image.Image) -> list[DetectedLine]:
    grayscale = np.asarray(ImageOps.grayscale(image))
    dark = grayscale < DARK_THRESHOLD
    height, width = dark.shape
    half_window = LINE_WINDOW // 2
    candidates: list[tuple[int, int, int]] = []

    for y in range(half_window, height - half_window):
        # A short vertical window follows slightly slanted horizontal frame lines.
        horizontal_mask = dark[
            y - half_window : y + half_window + 1
        ].any(axis=0)
        start_x, end_x = longest_true_run(horizontal_mask)
        if end_x - start_x >= width * MIN_FRAME_LINE_WIDTH_RATIO:
            candidates.append((y, start_x, end_x))

    clusters: list[list[tuple[int, int, int]]] = []
    for candidate in candidates:
        if not clusters or candidate[0] > clusters[-1][-1][0] + 3:
            clusters.append([candidate])
        else:
            clusters[-1].append(candidate)

    if len(clusters) != 8:
        raise ValueError(
            f"Expected 8 horizontal frame lines, detected {len(clusters)}"
        )

    lines: list[DetectedLine] = []
    for cluster in clusters:
        strongest = max(cluster, key=lambda item: item[2] - item[1])
        center_y = (cluster[0][0] + cluster[-1][0]) // 2
        lines.append(
            DetectedLine(
                y=center_y,
                start_x=strongest[1],
                end_x=strongest[2],
            )
        )
    return lines


def detect_panel_boxes(image: Image.Image) -> list[tuple[int, int, int, int]]:
    lines = detect_horizontal_frame_lines(image)
    boxes: list[tuple[int, int, int, int]] = []

    for index in range(0, 8, 2):
        top_line = lines[index]
        bottom_line = lines[index + 1]
        left = min(top_line.start_x, bottom_line.start_x)
        right = max(top_line.end_x, bottom_line.end_x)
        top = top_line.y
        bottom = bottom_line.y + 1

        box = (
            max(0, left - SOURCE_FRAME_PADDING),
            max(0, top - SOURCE_FRAME_PADDING),
            min(image.width, right + SOURCE_FRAME_PADDING),
            min(image.height, bottom + SOURCE_FRAME_PADDING),
        )
        if box[2] <= box[0] or box[3] <= box[1]:
            raise ValueError(f"Invalid detected panel box: {box}")
        boxes.append(box)
    return boxes


def normalize_panel(image: Image.Image) -> Image.Image:
    content_size = (
        PANEL_SIZE[0] - PANEL_MARGIN * 2,
        PANEL_SIZE[1] - PANEL_MARGIN * 2,
    )
    scale = min(content_size[0] / image.width, content_size[1] / image.height)
    resized_size = (
        max(1, round(image.width * scale)),
        max(1, round(image.height * scale)),
    )
    resized = image.resize(resized_size, Image.Resampling.LANCZOS)
    canvas = Image.new("RGB", PANEL_SIZE, BACKGROUND)
    offset = (
        (PANEL_SIZE[0] - resized.width) // 2,
        (PANEL_SIZE[1] - resized.height) // 2,
    )
    canvas.paste(resized, offset)
    return canvas


def assemble_full_image(panels: list[Image.Image]) -> Image.Image:
    if len(panels) != 4:
        raise ValueError(f"Expected 4 normalized panels, found {len(panels)}")
    full = Image.new("RGB", FULL_SIZE, BACKGROUND)
    for index, panel in enumerate(panels):
        full.paste(panel, (0, index * PANEL_SIZE[1]))
    return full


def save_webp(image: Image.Image, destination: Path, quality: int) -> None:
    destination.parent.mkdir(parents=True, exist_ok=True)
    image.save(destination, "WEBP", quality=quality, method=6)


def process_episode(
    episode: EpisodeSource, source_root: Path, output_root: Path
) -> dict[str, object]:
    year = episode.published_at[:4]
    episode_output = output_root / year / episode.episode_id
    source_image = open_rgb(episode.full)

    try:
        panel_boxes = detect_panel_boxes(source_image)
    except ValueError as error:
        raise ValueError(f"{episode.full}: {error}") from error

    normalized_panels: list[Image.Image] = []
    panel_paths: list[str] = []
    for index, box in enumerate(panel_boxes, start=1):
        panel = normalize_panel(source_image.crop(box))
        normalized_panels.append(panel)
        destination = episode_output / f"panel-{index}.webp"
        save_webp(panel, destination, quality=90)
        panel_paths.append(destination.relative_to(output_root).as_posix())

    thumbnail = normalized_panels[0].resize(
        THUMBNAIL_SIZE, Image.Resampling.LANCZOS
    )
    thumbnail_destination = episode_output / "thumbnail.webp"
    save_webp(thumbnail, thumbnail_destination, quality=84)

    full_destination = episode_output / "full.webp"
    save_webp(
        assemble_full_image(normalized_panels), full_destination, quality=90
    )

    return {
        "id": episode.episode_id,
        "title": episode.title,
        "publishedAt": episode.published_at,
        "year": year,
        "thumbnail": thumbnail_destination.relative_to(output_root).as_posix(),
        "panels": panel_paths,
        "fullImage": full_destination.relative_to(output_root).as_posix(),
        "sourceFolder": episode.directory.relative_to(source_root).as_posix(),
        "sourceImage": episode.full.name,
        "sourceDimensions": [source_image.width, source_image.height],
        "detectedPanelBoxes": [list(box) for box in panel_boxes],
    }


def main() -> None:
    parser = argparse.ArgumentParser(
        description="Detect and normalize four panels from complete-page scans."
    )
    parser.add_argument("source", type=Path, help="Root folder containing year folders")
    parser.add_argument("output", type=Path, help="Folder for generated assets")
    args = parser.parse_args()

    source_root = args.source.resolve()
    output_root = args.output.resolve()
    if source_root == output_root or source_root in output_root.parents:
        raise ValueError("Output must be outside the source folder")

    episodes = discover_episodes(source_root)
    manifest = [
        process_episode(episode, source_root, output_root) for episode in episodes
    ]
    output_root.mkdir(parents=True, exist_ok=True)
    (output_root / "manifest.json").write_text(
        json.dumps(manifest, ensure_ascii=False, indent=2) + "\n", encoding="utf-8"
    )
    print(f"Processed {len(manifest)} episodes into {output_root}")


if __name__ == "__main__":
    main()

テスト用に7話(2025年と2026年分)をSampleDataに格納し、WebP形式で整形されたデータをProcessedDataへ配置します。

python normalize_images.py SampleData ProcessedData

できてる！

ひとまずこれまで手動でやっていたことはスクリプトに置き換えられそうです。

4コマ漫画ビューワーの試作

画像を用意できるようになったので、次は7作品を使ってビューワーサイトを作りました。

試作段階では、整形した画像と作品情報のJSONファイルをサイト内に置くシンプルな構成にしています。

「手描きの4コマを、1コマずつ。」

それっぽいけど...

サイトのタイトルや記載する文面はこちらで特に指示しなかったので、哀愁(AI臭)漂う文面になってしまいました。

「4コマ帖」(そもそも「帖」何て読むんだ...?)

見た目や文章は追々整えていくとして、ビューワーについても想定したものが出来上がってきました。

はじめはCodexがChatGPT Sitesを勧めてきたので、そちらでページを公開していましたが 後からCloudflare Workersへホスティングする構成へ変更しました。

今のところはまだ公開サイトにはしていません。

Codexとの付き合い方

kugi日記用のプロジェクトを作成し、作業ごとにWorkを分けるようにしてみました。

  • 4コマ漫画サイトの方針策定
    • 最初のWork
    • ChatGPT Sitesで先ほどのビューワーの動作確認ができるところまで
  • ページのホスティング手段を検討
    • ChatGPT SitesからCloudflareへ移行した際のWork
    • GitHubリポジトリはこのタイミングで作成した
  • CloudflareとGitHubの連携
    • CloudflareとGitHubリポジトリの連携した際のWork
    • いくつか見た目の修正をしてもらい、Push時にPreview環境をビルドするように
  • kugi's notebook - ブログ原稿
    • 今書いているブログ記事の原稿を相談するWork
    • 後述する作業レポートを見てもらいつつ原稿を書いてもらった
    • 結局ほとんど自分で書いている
      • 次の記事でこの記事を参考にしてもらったらもっとうまくいくかも？
  • 雑メモ
    • 後述する雑メモやタスクを投げて記録してもらうWork

作業レポート

それぞれ作業内容を記録しておくために、そのセッションのレポートをMarkdown形式でまとめてもらうSkillsを作りました。

write-session-report/SKILL.md

---
name: write-session-report
description: Create or update a Markdown work report that records the decisions, implementation changes, validation results, current state, and next steps from a completed Codex session. Use when the user asks to wrap up, close, hand off, summarize, or document a work session; requests a dated report such as YYYYMMDD_REPORT.md; or wants a project-local session record under docs or a similar documentation folder.
---

# Write Session Report

Create a durable, evidence-based record of the session for a future reader who does not have the conversation history.

## Workflow

1. Determine the report location and date.
   - Follow an explicit path or filename from the user.
   - Otherwise inspect existing project reports and use their directory, naming convention, language, and level of detail.
   - If no convention exists, use `docs/YYYYMMDD_REPORT.md` with the user's local date.
   - Create a new report by default. Update an existing same-day report only when it clearly covers the same work session.

2. Gather evidence before writing.
   - Review the current conversation, completed plans, tool results, and user confirmations.
   - Inspect relevant existing reports and project documentation.
   - For a Git repository, inspect status, recent commits, tracked files, ignore rules, and remote state when relevant.
   - Inspect configuration or source files when exact current values matter.
   - Distinguish completed work, verified results, user decisions, remaining work, and suggested next steps.

3. Protect sensitive and excluded information.
   - Do not include secrets, tokens, credentials, private personal data, or unnecessary account identifiers.
   - Do not assume that writing an ignored report authorizes changing ignore rules, committing, pushing, deploying, or publishing.
   - Preserve the project's existing exclusions and privacy decisions.

4. Write for continuity.
   - Start with the project, report date, purpose, and important destinations or environments.
   - Record decisions and operating rules that future work must preserve.
   - Summarize material changes by area or commit, using exact identifiers only when verified.
   - Record validation commands conceptually and their results; include useful measurements when known.
   - Add a compact current-state table when several environments or milestones differ.
   - State unresolved risks, limitations, and next steps in priority order.
   - Call out easily confused states explicitly, such as Preview versus production, local versus pushed, or prepared versus deployed.
   - Match the user's language and the style of existing reports.

5. Verify the artifact.
   - Re-read the complete report for internal consistency.
   - Confirm dates, paths, URLs, branch names, commit IDs, counts, and environment states against available evidence.
   - Label anything not directly verified as an inference, estimate, or proposed next step.
   - Confirm the file exists at the requested location.
   - Check repository status afterward and report whether the new file is tracked, ignored, or untracked.

6. Hand off concisely.
   - Link the created report using its absolute local path.
   - Summarize its main coverage and Git tracking state.
   - State explicitly that no commit, push, deployment, or publication occurred unless it actually did.

## Recommended Sections

Adapt the sections to the work; omit empty sections and add domain-specific sections when useful.

- Purpose
- Decisions and operating policy
- Work completed
- Commits or changed files
- Environment, hosting, or deployment state
- Validation results
- Current state
- Remaining work and next steps
- Cautions and exclusions

## Quality Rules

- Prefer verified facts over a chronological chat transcript.
- Keep enough detail to resume work without reopening the full session.
- Do not claim success from an attempted command; require a successful result or user confirmation.
- Do not silently convert plans into completed work.
- Do not expose credentials or paste verbose logs.
- Avoid duplicating a prior report wholesale; focus on changes and decisions from the current session while preserving necessary context.

雑メモ

ふと思ったことや改善したいことなどを作業中のWorkとは別の場所で投げておくWorkを用意しました。 SCRAP_MEMO.mdに書き残してくれます。

落ち着いたタイミングで現状と照らし合わせてリストにチェックをつけてもらうようにしています。

SCRAP_MEMO.md

# 雑メモ

雑なメモを書き溜めておくファイルです。
定期的にプロジェクトの状況と照らし合わせ棚卸しを行います。

## UI・表示

- コマ数表示がコマと被っているため、配置を見直す。
- 「1コマずつ読む」の記載は冗長なので、「読む」に変更する。
- 「作品一覧」を押しても何も遷移しないため、リンク先・画面遷移を確認する。

## 共有

- Xへポストするボタンを追加する。
- 他のSNSへの共有リンクも追加する。

## サイト情報

- サイトのタイトルを「kugi4koma」に変更する。
- 作者についてのページを追加する。

## データ整形

- データ整形時にコマの色味を調整できるようにする。
- comicのデータやリソースが`site/public`以下に配置されている。GitHubへのコミットや今後の管理を考慮し、配置・保管方法の代替案を検討する。
- 作品追加時に多言語対応するワークフローを検討する。

## 文言・コンテンツ

- 「手描きの時間を、画面の向こうへ。」「手描きの4コマを、1コマずつ。日々の出来事や思いつきを描いた4コマ漫画をまとめています。気になる作品を選んで、ゆっくりお楽しみください。」など、本人の言葉ではない文言を修正する。
- 上記以外にも、意図せず追加された文言がないか確認する。

## 権利・ライセンス

- 4コマ漫画の権利表記を追加する。
- サイト実装に用いたOSSなどのライセンス表記を追加する。

## 運用・公開

- Cloudflareでデプロイする。
- [x] GitHubでプロジェクトを管理する。完了: 2026-08-16
- [x] Cloudflareでの本番デプロイとPreviewの違いを確認する。完了: 2026-08-16
- カスタムドメインを取得する。
- ChatGPT Sitesの残骸（`.openai`など）を確認し、不要なものを削除する。
- GitHubへのコミット・プッシュ手順とブランチ戦略を整理する。

## ドキュメント・記録

- セッション後の作業レポートをObsidianに登録できるようにする。

完全にメモ代わりとして使っている。

なので「雑メモ」

まとめ

今回は、「4コマ漫画ビューワーの準備」編ということで、 「kugi日記」の公開準備の一部自動化とビューワーの試作版をCodexと共に作りました。

まだ7作品だけの試作版ですが、全体スキャン画像から公開用画像を作り、作品一覧と1コマずつ表示するところまでは一通りつながりました。

普段からWeb開発しているわけでもないので勉強にもなりました。

実際のサイト公開まではもう少しやることがあるので続編でお会いしましょう。

それでは！(ﾐｰﾝﾐﾝﾐﾝﾐﾝ)

2025→2026

1年の振り返り

はじめに

2025年、みなさんはどんな1年だったでしょうか？

私の2025年の目標は「Plus Ultra」でした。

今年も振り返りを書きながら年を越そうと思います。

それではいってみましょう！

2025年振り返り

お仕事

詳しいことは書けませんが、まずはお仕事から。

今年は転機となる出来事がたくさんあり、 本当にたくさんの方々に助けていただきました。

来年も粛々と、技術を突き詰め、頑張っていきたいと思います。

クライミング

今年は同僚やUnityゲーム開発者ギルドの方々など一緒に登る方が増えた年でした。

御岳にも初めていきました!

ホームジムのKaChillの皆さんには今年もお世話になりました。

退勤後にKaChillで登るとなると、都内から辻堂まで電車で向かいジムに着くのは21時過ぎになるのですが、 常連さんや店長とクローズの時間まで一緒にまぶし壁でセッションをすることが多かったです。

今年はグレードを追い求めるというよりは、他の人と一緒に登ったり、セッションの時間をただひたすらに楽しむことで、クライミングの楽しさを改めて実感することができました。

KaChillではポッドキャストラジオもあるので是非聞いてみてください!

open.spotify.com

自作PC

今年は念願の自作PCを組みました!!

これまで個人PCはMacユーザで、いつかは自作PCを組んでみたいと思っていました。

モチベーションを高めるため、秋葉原へ同期とパーツ物色に行った際にこちらのPCケースに一目惚れしてしまいました。

kakaku.com

早速PCケースだけ買ってしまおう!!と思ったのですが、 ちょうど品切れになっていてその日は退散しました。

1ヶ月間通販サイトをチェックし続け、ようやく手に入れることができました!

他のパーツ構成は下記の通りです。

  • MONTECH SKY TWO [Blue]
  • MSI X670E GAMING PLUS WIFI
  • AMD Ryzen 9 9950X3D
  • MSI GeForce RTX 5070 Ti 16G GAMING TRIO OC WHITE
  • SAMSUNG 990 EVO Plus MZ-V9ST0B-IT
  • Crucial DDR5 PC5-48000 32GBx2 (CP2K32G60C40U5W)
  • CORSAIR RM1200e (CP-9020258-JP)
  • MSI MAG CORELIQUID A13 360 WHITE

マザボは台湾で買いました。

ﾁｮｯﾄ安くなりました。(多分)

バンド練

昨年から始めたベースですが、今年はゲーム開発仲間のnattuhanさん、nattuhanさんの同級生、私の3人で月1ペースでゆるくスタジオに入りました。

nattuhanさんの振り返り記事でも言及いただいています。

note.com

曲としては

を練習していました。

他にはずとまよの秒針を噛むのスラップフレーズが弾きたくてスラップの練習もしていたりしました。

まだまだへたっぴですが、スタジオに入る度に人と合わせて弾くのは楽しいなと感じます。

もっと練習して上手くならなくては...

来年は練習曲を一新する予定です。

気持ち新たに1曲1曲に向きあって上達していきたいなと思います。

4コママンガ「kugi日記」

今年は5話描いていたようです。

note.com

7月以降パタリと更新が止まっていますね...笑

途中まで描いている話はあるので次回の更新をお楽しみに

:chill_magao:

SF6

会社の同期にEVO Japanに誘われ昨年始めたスト6ですが、今年はEVO Japanに参加してきました!

緊張で手汗びっしょりでしたが2勝できました...!

会場の活気や雰囲気にも圧倒されました。

ディージェイのランクの方ですが、今は「ダイヤ３」です。

年内にマスターに到達したかったのですが、道のりは長いですね...

来年こそは...! マスター目指して頑張ります。

unity1week

今年はunity1weekに2回作品を投稿しました。

お題「あい」では「あい×2」というサル同士でジャンケンをしてスコアを集めるゲームを投稿しました。

共有会にも久しぶりに参加させていただきました。

お題「ひく」では「PigUp」というしゃっくりで飛ぶブタをゴールまで飛ばすゲームを投稿しました。

1年ぶりにゲームジャムに参加しましたが、やはり楽しいですね!

会社の同期や親戚など身近な人に遊んでもらったり、感想を聞いたりできとても嬉しかったです。

レイトレ合宿11

今年のレイトレ合宿では久しぶりに「蛍光」のレンダリングに挑戦しました。

kugi-masa.hatenablog.com

今年は昨年実装したDXRレンダラーをベースに実装し、ある程度GPUレンダラーの土台となるようなものができてきました。

来年はマテリアルの実装などをさらに充実させていきたいです。

(早めに実装を再整理せねば...)

SESSIONS

12月には前々から気になっていたSESSIONSに参加してきました。

ライブコーディングや各種投稿作品、DJ/VJイベントなど刺激を受けまくりの2日間でした。

同じ趣味を持った人たちが一堂に会し盛り上がれる最高のイベントでした。

熱の冷めやらぬうちに、以前Unityで遊びで書いたシェーダーをもとにShadertoyに作品を投稿してみました。

https://www.shadertoy.com/view/wfdBDn

投稿してすぐに歓迎とアドバイスコメントをいただき、なんて暖かいコミュニティなんだ!!と思いました。

来年は私もSESSIONSに何か作品を投稿してみたいです!

2025→2026

こう改めて1年を振り返ってみると今年もいろいろと挑戦できたなと思います。

2025年の目標として「Plus Ultra」を掲げましたが、「あともう一歩踏ん張ろう!」、「ここが頑張りどき」といった場面で自分を奮い立たせる言葉になっていた気がします。

具体的な目標というわけではなかったので、目標に向かって、というよりは、目標に助けられたな、と感じる一年だったかもしれません。

さて、2026年の目標ですが、「導き、深める」にしたいと思います。

『導く』に関しては、「人を」導く、「成功に」導く、いろんな捉え方があると思いますが、自身も関わる人も良い道へと『導いて』いけたらなと思います。 『深める』に関しては、仕事も趣味も今持っているものをさらに突き詰めるという意味合いをこめて掲げてみました。

まとめ

今年も大変お世話になりました！

2026年もどうぞよろしくお願いいたします！

レイトレ合宿11参加レポート

Computer Graphics

はじめに

11月14日(金)から11月16日(日)の期間で高尾山の麓で開催されたレイトレ合宿11に参加してきました！

レイトレ合宿

レイトレ合宿はオフラインレンダリングのオフライン集会で、各々合宿当日までにレンダラを提出します。 合宿当日はレンダラのお披露目会である本戦やセミナー、またアクティビティなどが行われます。

今年のレイトレ合宿は高尾山口駅から歩いてすぐのタカオネで開催されました。

初日にバーベキューや

焚火をしたり

突如コーネルボックスが現れたり

二日目には高尾山を登ったりと自然も満喫しました。

本戦

本戦では制限時間内にAWSのインスタンス上で描画された成果物とレンダラの説明を元に参加者全員でお互いの作品を10点満点で評価します。

詳しいルールについては下記に記載されています。

ルール・実行環境・提出物仕様

提出されたレンダラ

今年はエキシビション含め23個のレンダラが提出されました！

今年は、

薄レンズの重点的サンプリング手法を実装されたものや

Physically Based Shading in Theory and Practiceで発表されていた Strandベースのファーレンダリングなど

SIGGRAPH2025で発表された最新手法の実装や、

OpenUSDに対応し、BlenderやHoudiniで自作レンダラを呼び出すためのHydraプラグイン実装、

ライトが動き、固定端反射を行うシーンでの2次元のTransient Renderingなど、

皆さんの個性が詰まった多種多様なレンダラの発表がありました。

1位を取られたのは、Path Cutsという手法をベースにフォトントレーシングも活用してCausticsを描画された、うしおさんのPalzillaでした！

圧巻です...！

ここで紹介させていただいたレンダラだけでも半分には満たず、どれも素晴らしい作品ばかりです。 是非皆さんの作品をリザルトサイトの方でご覧ください！

sites.google.com

FluoTracer

さて、私の作品はというと、今年は蛍光を改めてレンダリングしました。

speakerdeck.com

github.com

今回の目標

これまでの変遷として、

という流れで参加してきました。

昨年のレイトレ合宿10でハードウェアレイトレーシングの土台ができたので、初心に帰って私の好きな光学現象である蛍光のレンダリングを今回の目標にし、昨年のレンダラーを拡張する形で実装を始めました。

Fluorescence in RGB

蛍光現象は蛍光分子がある特定の波長の光を吸収し、別の波長の光を放出する現象です。

そのため、レンダリングを行う際は光の波長までを考慮する必要があり、一般的なRGBレンダラでは物理的に正しい蛍光が表現できません。 また、スペクトラルレンダリングの中でも入射光と出射光で波長が変化するため、波長のサンプリングを行う際は波長の変化を考慮する必要があります。

レイトレ合宿8で実装したFluorSwitchの蛍光では、380 ~ 780nm区間で5nmごとの81サンプルからなるフルスペクトラムを用いて描画していました。

speakerdeck.com

今回改めて蛍光に挑戦するということで、蛍光ハンターである私は昨年EGSR2024で発表されたNon-Orthogonal Reduction for Rendering Fluorescent Materials in Non-Spectral Enginesを思い出しました。

提案手法では、RGBレンダリングも、等色関数によってRGB(XYZ)からスペクトラムへのダウンサンプリングやアップサンプリングが含まれるスペクトラルレンダリングだと捉えることでRGBレンダリング内で蛍光現象を表現しています。

詳しくは今年のセミナー資料でも記載しています。

speakerdeck.com

少し蛍光からは逸れますが、よこたさんやyumcyawizさんとのお話の中で、共著者の一人のBelcourさんがSIGGRAPH2017で発表された、 A Practical Extension to Microfacet Theory for the Modeling of Varying Iridescenceでも同じような考えでIridescenceをRGBで表現していると教えていただきました。

Iridescenceの方に関しては、UnityのHDRPでのIridescenceマテリアルや後述するOpenPBRのThin-film iridescenceでも推奨モデルとなっているようです。

また、今年のSIGGRAPH 2025のCourseではBelcourさんご本人が2024年の手法と発展として蛍光材質のパラメータを編集可能にした発展手法(A Fluorescent Material Model for Non-Spectral Editing & Rendering)について発表されていました。

今回私が提出したFluorTracerではあらかじめ事前計算でリダクションされたRe-radiation Matrixを用いてRGBレンダラーで蛍光の描画をしています。

蛍光材質としては論文でも利用されていたTEXTYELLというものを利用しています。 リダクションの計算などが含まれたJupyterNoteBook公開されていたため、計算済みの3x3の行列を今回は利用しました。

GitHub - afichet/fluorescence-rgb: Sample code for the paper Non-Orthogonal Reduction for Rendering Fluorescent Materials in Non-Spectral Engines

蛍光マテリアルのClosestHitシェーダーで、NEEによる光源サンプルで光源と接続できた場合に以下のような流れで寄与計算しています。

  1. サンプルされた光源をRGB → XYZ に変換
  2. 変換されたXYZ値をリダクションされたRe-radiation Matrix(事前計算された3×3行列)とかける
  3. 蛍光の計算後、XYZ → RGBに変換して寄与に加える

シーン中央に蛍光マテリアルを割り当てた板を設置して、後半の方で正面のライトの色を青に変化させることで蛍光を際立たせています。 蛍光マテリアルとしては『レイトレ合宿11』と書かれたマスクテクスチャを割り当てており、白の部分は蛍光面、黒の部分は拡散反射面にしています。

拡散反射面の部分のアルベドカラーについてはレイトレ合宿の文字が隠れるように色を調整しています。

拡散反射面でのアルベドを黄色に設定することで蛍光面が見えないようにしている

アルベドを黒にした場合

SIGGRAPH 2025のCourseでも言及されているのですが、パストレーシングにおいてはペイロードをスカラー値ではなく、3×3の行列として扱う必要があります。

Spectral Rendering in a Non-Spectral Renderer: How Can we Author and Render Fluorescence in RGB? [SIGGRAPH2025] p.15

今回の実装ではNEEでの光源接続時と限定的に実装を行ったため、ペイロードはスカラー値のままで計算しており、 本来の見た目よりも若干弱めの蛍光になっていそうなのですが、黄色い板から急に文字が浮かび上がってくるという演出としては都合が良かったです。

OpenPBR

蛍光以外の材質について、今回はOpenPBRの導入にも挑戦してみました。

これまでのマテリアルについては蛍光を除くとベーシックな拡散反射面(Lambert Diffuse)のみでスペキュラーな反射については実装してきませんでした。 GGXなどを導入してGlossyな面に対して蛍光が映り込む様子にも今回は挑戦してみたいなと思っていたところ、またまたSIGGRAPH2025のCourseでOpenPBRについての資料が上がっていることに気づきました。

OpenPBRはPBRマテリアルの共通規格とすべく、AutodeskとAdobeが協力し、Academy Software Foundationが2024年6月にバージョン1.1を策定した規格で、 Slabという材質の表面のBSDFと均質な媒質からなる構造をレイヤーとして積み上げたり、割合に応じてブレンドさせることで表現されるマテリアルです。

OpenPBR Surface | 3. Model

元々はDisneyのPrincipled BRDFに挑戦しようと思っていたのですが、新しい規格でもあり、長いものに巻かれてみようという気持ちでOpenPBRの実装に取り組みました。

WebGLベースではありますが、パストレーシングを行っているビューアーがOpenPBRの公式リポジトリでも紹介されていたので、今回はこちらを参考に実装しています。

GitHub - portsmouth/OpenPBR-viewer: An example implementation of OpenPBR in a WebGL pathtracer

とはいえ、今回の本題は蛍光だったので、いきなりすべてを導入するのではなく、Diffuse面とMetal面のBRDFのみの簡素な実装になっています。

DiffuseとMetalのBRDFのみ

また、OpenPBRではDiffuse面でのBRDFをエネルギー保存を考慮したモデルであるEON ("energy-perserving Oren-Nayar")をオプションとして提示していますが、今回はLambertDiffuseを用いています。

(EONについてもSIGGRAPH2025のCourseで発表がありました)

Metal面ではマイクロファセットBRDFとフレネル反射としてはF82-Tintモデルを導入しています。

余談ですが、Unreal Engineの5.7からデフォルトで有効になった新しいマテリアルであるSubstrateも同じようにSlabを基本構造として持っており、マテリアル共通化の流れをこちらでも感じることができます。

GitHub Actionsによる自動ビルド

レンダラそのものとは若干ずれますが、今回はGitHub Actionsによる自動ビルドも導入しました。

PushをトリガーにWindowsのDebug版とRelease版をビルドしていました。

Release版でのアセットパス周りのバグに事前に気づけたりと早めに導入してよかったです。

意気込み賞

今回は本戦、セミナーの他に「意気込み賞」もありました。

優勝はkinankomotiさんの"raytracing-kenkyu.org"！

raytracing-kenkyu.org

SUGEEEEE----!!!

え？私の意気込みですか？

はい。

蛍光全然関係なくない?!

そうなんです、この異常に長い意気込み、私でした...

今年のレイトレ合宿のお誘いがあったのがちょうどCEDECの直後で、 Pocolさんのメッシュレット描画の講演を聞き、メッシュレット描画への興味がわいていたタイミングでノリと勢いで意気込みを投下してしまいました。

speakerdeck.com

メッシュレット描画したうえでライティング時にレイトレをすることを今年の目標にするか？と一瞬悩んだりもしたのですが、 やはり蛍光に挑戦したいという思いもあり、このズレた意気込みが出来上がってしまいました...

めちゃくちゃ恥ずかしいな...と思いながら合宿に参加していたのですが、 最終日にお昼をご一緒したeclmistさん、てらさん、ゆういちろうさん、sketchさんと意気込み賞の話になり、 「実はあれ実は自分なんです...」と明かしたところ、「めちゃくちゃ笑いました！」と言っていただけたので救われました...

感謝🙏

まとめ

レイトレ合宿11について振り返りました。

今年は初参加の３年前から再び蛍光の実装に取り組むことができました。

ただ、今回の蛍光はシーンに依存した実装や材質についても固定だったので、 まずはリファレンスのためにRGBレンダラをスペクトラルレンダラに拡張したいです。 また、OpenPBRについても実装が道半ばなのでほかのBSDFについても実装を進めたいです。

参加するたびに皆さんから刺激をもらい、自分も頑張ろうと思える良い機会です。 参加者の皆さんとの議論も非常に楽しかったです。

運営の皆さん、参加者の皆さんありがとうございました！

unity1week「ひく」振り返り ~ ClaudeCodeと参加するゲームジャム ~

Unity

はじめに

Unity1週間ゲームジャム - お題「ひく」で「PigUp」という、しゃっくりで飛ぶブタのゲームを作りました！

プレイしてくださった方、評価してくださった方ありがとうございます！ まだの方は下のリンクからプレイできるのでよかったら遊んでみてください。 unityroom.com

今回は「PigUp」の振り返り記事になります。

ClaudeCodeと参加するゲームジャム

実は今回参加を決めたのは開発期間終盤の8/8(金)の夜でした。

というのも、開発期間前半は親戚が遊びに来ており、評価期間中は夏季休暇ではありましたが、旅行など予定が詰まっていたため「今回は参加が厳しいかな～」と参加を見送るつもりでいました。

金曜日の夜、「そういえばunity1weekか、お題何だったっけな～」とunity1weekのことを考えながら眠りにつこうとしていたところ...

『 「ひく」 → 「Hiccup」→「Pig ... Up ...」→「PigUp ... !?」 』とブタがしゃっくりをしながら空を飛んでいる絵が思い浮かびました。

開発時間はあまり取れそうではなかったのですが、「ブタを飛ばしたい！」という気持ちと、 最近話題のClaudeCodeを使ってみたかったこともあり、 「逆にこの時間が取れない状況でClaudeCodeでどれだけ時短になるかを試してみる良いタイミングかも？」 と考えとりあえず参加してみることにしました。

世のものもすなる『ゔぁいゔこーでぃんぐ』といふものを、kugiもしてみむとて、するなり

Claude Codeセットアップ

ということで、早速

npm install -g @anthropic-ai/claude-code

しました。

docs.anthropic.com

課金形態

課金形態はAPIの従量課金で、まずはお試しで5ドル課金しました。 後々追加で30ドル課金しました。

公開までにかかったトークン費用としてはおおよそ15ドルでした。

プラグイン

Riderのプラグインもあったので試しに入れてみました。

Claude Code [Beta] - IntelliJ IDEs Plugin | Marketplace

Claude Code [Beta] Rider Plugin

日本語入力が不便な問題は依然として残りますが、いちいちターミナルを起動してclaudeコマンドを入力しなくても良くなります。 また、Shift + Enterで改行できるようでした。

Claude Codeとのやりとり

Claude Codeにコードを書いてもらう前に、PLAN MODE で計画した後に書いてもらった方が良いと聞いていたので、 最初の指示文をClaude Codeに渡す前にGeminiにプロンプトの相談をしつつ、ゲームアイディアを整理してみました。

- 豚をひっぱり、しゃっくりさせながら、どこまで高く到達できたかでスコアが決まるゲーム
- 豚をひっぱるにはエネルギー(スタミナ)が必要
- スタミナがなくなったらゲーム終了

また指示文も英語で渡すようにしてみました。

# 📝 実際に最初に渡した指示プロンプト
I'm making a 2D game for a gamejam. These are the details of the game.

- A 2D Platforming game where player controls a character(pig) by pulling and releasing the character so that the character can jump.
- The objective is to climb as high as possible.
- The character has a stamina gauge and the player will use the gauge to do the pulling action.
- When the stamina gauge is empty the game will finish and move to results by showing how high the character reached in the end.
- There will be some items in the stage during the climb
    - Health Item (Soda) : The character recovers some stamina
    - Boost Item (Balloon) : When the character gains 3 Balloons, the character will have a speed up boost for a specific duration.
    - Damage Item (Water) : The character lose some stamina

PLAN MODEで何度か内容の確認をしたうえで、実際にコードを書いてもらいました。

Shift + Tab でモード切替

数分待っているとUnity側でのセットアップガイドとともに、実装コードが出来上がっていました。

Unity側でセットアップガイド

いざUnityを起動してみるとエラーが出てSafeModeで起動することになりましたが、 エラーの該当箇所を修正し、セットアップガイド通りにひとまずシーンのセットアップをしてみて、 シーンの実行までたどり着きました。

開発中の修正依頼

初日に実装コードを提供してもらってから、途中でゲームの終了判定やブタ挙動、スタミナなどの仕様修正が出てきました。 途中の修正依頼についても軽く紹介します。

ブタのしゃっくりジャンプ時の方向表示依頼など

  • しゃっくりジャンプの際の方向表示
  • 豚落下中にカメラがカクツク問題の調査
  • Rキーでリトライする処理

📝指示プロンプト

Now I want to brush up my game.

- The hopping direction is not clear for the Player so I want to show the directin by a trajectory line.
You can reuse the trajectoryLine in the PigController if it's suitable.
Only show the hopping direction when the Pig is in the air.
- If the player inputs the key [R], I want to restart the game by calling the GameManager.Restart().

If your done with that, I also want you to check why the view has stuttering when the pig falls.

細かな追加修正

  • ブタの反転と飛ぶ方向に応じて向きを変える
  • 設定表示中はゲームを停止する
  • はじめてクリックしてからタイマー開始

📝指示プロンプト

Hi! I'm almost done making this game!
I'm doing a final brush up so I want you to help.
Please consider the following tasks.

- I want to make the Pig's sprite flip according to the direction the Pig is flying.
    - Also I want the top of the sprite to face the direction the Pig is flying.
    - The Pig's implementation is @Assets/Scripts/Core/PigController.cs
- I want to Pause the game(the game time, the Pig's rigid body simulation) when the user presses the [S] key
    - The InputAction is already implemented (Please use "settingsAction")
- I want the GameTimer to start on the First release pull action. (On the initial PigJump)

概ね意図通りの追加実装や修正をしてくれました。

また、私が追加で実装した箇所(おそらくコピペ実装のままになっていた部分)の修正まで合わせて行ってくれました...。

私の実装ミスを合わせて修正してくれた

Claude Codeを使ってみて

実際に使ってみて、序盤の走り出しのスピード感がかなり早く、 まず「動くもの」が欲しくなるような、プロトタイプの制作やゲームジャムのような場面と、相性がとても良いと感じました。

ただ、ずっとClaudeCodeに書いてもらっていたかというとそういうわけでもなく、 ClaudeCodeにコードを書いてもらったのは主に序盤の2日で、 後半の演出実装や細かな調整は自分で実装していました。

また、実装コードについては[SerializeField]が一切使われていなかったり、冗長なコードがあったりなど、こちらの意図を汲み切れていない部分がありました。 命名規則なども含め、プロジェクト構成やコーディング規約についてはコードを書いてもらう前段階で CLAUDE.mdで指示したうえで着手してもらう方が良いんだろうなと感じました。

(「ものごとを簡潔に伝える力」が必要になっていきますね...)

今回はコードのみの部分で助けてもらいましたが、どこかのタイミングでMCPも試してみたいです。

まとめ

今回は、妻のNaTsuもボイス、イラストで手伝ってくれ、久々に夫婦で共同開発ができたのも良かったです。 妻は子供の頃にDoodleJumpをかなりやっていたようで、縦スクロールで登っていくというアイディアを最初に伝えたときに「絶対作って！」と熱く語ってくれました。

もともと、参加する予定のなかった今回のunity1weekですが、評価期間ギリギリにはなりましたが、ClaudeCodeのおかげもありしゃっくりでブタを飛ばすことができました。 今後も活用の仕方を模索していきたいです。それでは！

技術書典18の戦利品

はじめに

技術書典18のオフライン会場に行ってきました！

こちらの記事では今回購入した戦利品たちについて記載します。

戦利品

\ 戦利品 //

会場を回り、購入した順で記載していきます。

技術季報 Vol.18 [技術書典運営事務局]

オフライン会場に行った際は記念で必ず購入している気がします。

今回のエッセイでは「参考文献」の話やオフライン会場の新企画であった「技術書典で開催する技術書店」の裏話があり面白かったです。

帰りの電車で読んでいたのですが、お祭りの余韻に浸れました。

techbookfest.org

GROVE対応シリーズで始めるUnity電子工作入門 [みんなのラボ]

入場して少し進んだあたりで、センサーや入力デバイスで電子工作されたデモが展示されたブースが気になり、吸い込まれていきました。このような予期せぬ技術との出会いも技術書典の醍醐味ですよね！

みんなのらぼ さんのブース

ブースの方とお話しして、ジョイスティックやジャイロセンサーで操作できるUnityデモの紹介やGROOVE対応ボードについて色々教えていただきました。

技術書だけでなくハードも販売されていて、私は下記3点を購入しました。

techbookfest.org

techbookfest.org

techbookfest.org

入力デバイスから着想を得たゲームなど作ってみたいですね！

ワンキーキーボードは、はんだ付けやファームウェアの書き込みは不要で、ピンを差し替えることで指定したキーマトリクス内のキーに割り当てを切り替えることができるようになっていました。

DirectX12 Mastery Vol.2 [techbito]

お目当てだったtechbitoさんのDX12の新刊を購入しました。 今回はテクスチャ操作とDirectStorageについての内容のようです。 読むのがとても楽しみです！

techbito さんのブース

techbookfest.org

Rust Graphics Fundamentals Vol.1, Vol.2 [techbito]

また、techbitoさんのRust Graphics本についても2冊購入しました。 気になる言語ではあったのですが、これまで触れたことがなかったのでこれを気に学んでみたいです！

techbookfest.org techbookfest.org

エンジニアニメ Anthology Tech Book 1st Season [アニメから得た学びを執筆会]

学生の頃ハッカソンやLT会を通して交流のあった方が何名か所属されている アニメから得た学びを執筆会 さんのブースへ行きました。

アニメから得た学びを執筆会 さんのブース

以前からアニメから技術者として得た気づきや学びを発表する勉強会を開催されていたのは知っていたのですが、実際に参加したことはなかったので、今回こうして書籍化されたものを読むのが楽しみです。

techbookfest.org

まとめ

過去に何度か技術書典に参加したことはあったのですが、 技術書典に行った日は刺激をたくさん受けてモチベーションが上がるのですが、 気づいたら積読として本棚に鎮座してしまうことが多いので、今回は「読むぞ〜！」という意味も込めて、 初めて戦利品をまとめる記事を書いてみました。

参加する度に新しい技術書との出会いがあり、お祭りのような楽しさがありますよね！ (気づいたらお財布の紐が緩くなっているのですが...) 今回はリアルでお話ししたことがなかったTLの方々にも何人かご挨拶できてよかったです。

オンラインマーケットの方は6月15日(日)まで開催しているようなので、追加で購入したものがあれば追記するかもしれません。

techbookfest.org

2024→2025

1年の振り返り

はじめに

2024年ももうすぐで年明けです。

今年も2024年の振り返りを書きながら2025年を迎えたいと思います。

2024年振り返り

NOA's Project

2024年もNOA's Projectの出展から始まりました。

Unity1Weekをきっかけにnattuhanさん、つっちーさん、妻のNaTsuと共に開発を行なっているNOA's Projectも4年目に突入、今年は「東京ゲームダンジョン4」に二日間出展しました。

７月ごろまでは週１でDiscordに集まり、もくもく会と称して２時間程度作業を続けていましたが各々本職や新しい趣味ができ忙しくなり、2024年は休眠期間となりました。

ノアプロへの2024年の最終コミット

来年はまた開発を再開して完成に向けて頑張りたい!! と言いたいところですが、私はお互いに強制力のない、ゆるゆるとしたノアプロチームの雰囲気での開発が好きなので流れに身を任せたいと思います。

年明けに久々にメンバーで集まる飲み会が2025年最初の楽しみです。

クライミング

今年も昨年の10月ごろから通っているホームジムのKaChillでたくさん登りました。 KaChill民の皆さんとはムーンボードやまぶし壁でセッションさせていただいたり、外岩リードにもご一緒させていただきました。

周遊コンペのYGCに参加したり、会社の同僚と退勤後渋谷のノボロックで登ったりと昨年よりは登る機会が増えました。

来年は久しぶりにTNFCにも参加したいです。

HAMSTAR MC BATTLE

昨年のUnity1Weekで妻と妹と私の3人で作ったハムスターたちがラップバトルをするゲーム「HAMSTAR MC BATTLE」をオクトレインさんに取り上げていただいたことにより、いろんな方の目に留まり、昨年のUnity1Week期間以上にプレイいただけました。

(バズトレインさんありがとうございます！)

また、配信者ののばまんさんにもプレイいただけたことも驚きました。

youtu.be

バージョンアップ版ないしは続編を作りたいねと妻、妹と話しているので、 来年は何かの形でアウトプットしたいです。

unityroom.com

4コマ

今年は4コマを1話だけ描きました。

4コマを描き始めた当初はコツコツ描いていきたいなと思っていたのですが、 徐々に「描かなきゃ...」 と自分の中で義務感のような感じてしまうことがあり、 昨年ごろからゆる〜〜く描いていこうというスタンスに変えました。

note.com

ネタ帳には描きたい内容がたくさん増えていくばかりですが、 描きたいなと思ったときに描くという精神で、 ゆる〜〜〜く描きたいと思います。

レイトレ合宿10

今年もレイトレ合宿に参加しました。 今年はDXRでハードウェアレイトレーシングに入門しました。

振り返り記事も書きました。

kugi-masa.hatenablog.com

SIGGRAPH Asia 2024で聴講したテンセントさんの講演が興味深かったので来年は、微分可能レンダリングに挑戦したいです。

Optimizing Game Assets Using Differentiable Rendering

(CEDEC2024でも同様のセッションがあったようです。

微分可能レンダリングを使用したレンダリングパフォーマンスの向上 / Boosting Rendering Performance Using Differentiable Rendering)

ベース

7月にベースを買いました。

元々楽器をしてみたいという憧れのようなものはあったのですが、ノアプロメンバーのnattuhanさんがバンドに誘ってくれたこともあり、 このタイミングで購入を決意しました。

私の妹も実はベースを弾いていて、教えてもらえるかな？と思ったのもベースにしたきっかけです。

まだまだ初心者ですが、引き続き練習していきたいです。

SF6

「あなたの2024年のゲームは何？」と聞かれたら「ストリートファイター6」と答えます。

きっかけはRushboxと会社の同期です。

格ゲーに関しても若干の憧れのようなものはあったのですが、なかなか始める機会がありませんでした。

私が自作キーボードを始めるきっかけとなったゆかり𓂙さんが制作されているレバーレスコントローラーのRushboxを見て、 レバーレスの存在を知り、会社の同期からEVO Japanに誘われて(2024年は結局出れませんでしたが)、RushboxでSF6を始めました。

キャラはGROOVEに惹かれ、DEE JAYを使っています。 コンボを覚えて出来なかった技が増えたり、ランクという自分の適性レベル帯で模索する過程がボルダリングにも似ていてのめり込んでいく1年でした。 マスターの方々にご指導ご鞭撻をいただきながら、毎日仕事の昼休みに修行をしています。

まだまだ程遠いですが、来年こそはマスターDEE JAYになりたいです。🕶️🪇

お仕事

4年目になり、環境が目まぐるしく変わる1年でした。 関わる人が増え、いろんな方々にお世話になりました。 来年も頑張るぞい💪

2025年の目標

さて、2024年の目標は

「憧れをもっと身近に」

でした。

仕事でも趣味でもこれまで憧れを抱いていたものには挑戦できた年だったと思います。

(とにかく趣味が増えた年でした笑)

2025年の目標は「Plus Ultra」でいこうと思います！

まとめ

今年も多くの方にお世話になりました。

来年も頑張るぞ！

さらに向こうへ！Plus Ultra！