つくみセミナー用ドラフトに SVG スライド 17 枚を埋め、既存記事にも比較用 SVG を追加した日
朝のお題は「つくみのセミナーをバックオフィス向けに作り直す」
つくみのセミナーは元々「地域事業者向けの生成AIホームページ体験会」として枠を取ったつもりでいた。先方から返ってきた要件を読み直すと、業種を問わずバックオフィス担当者向けの業務効率改善で、会計・税務スペシャリストの視点でAIを含めて話してほしい、とトーンが変わっていた。手元のアイデアが空っぽだったので、ひとまず Unpublished のドラフト記事を立てて、書きながら考える方針に振った。
apps/web/content/2026-06/2026-06-30/tsukumi-backoffice-ai-seminar-draft.md を unpublished: true で作らせて、骨子を Claude Code に任せた。中身を眺めて、自分の中でひっかかる箇所だけ手で書き直していく構成。
ai-position-map の結論を引っ張ってきて骨組みにする
ゼロから書かせると総花的な「AI で効率化しましょう」になりがちだったので、先に /ai-position-map を読み込ませた。インセンティブ設計の話と、経営者起点で AI を入れろという結論を、そのままセミナーの背骨にあてた。
デモ枠は Claude Code / Codex / Claude-in-Chrome の3本に絞った。聴衆がバックオフィス担当者と、それを束ねる経営層の両方になりそうだったので、「下に降ろせる道具」と「経営者が自分で触れる道具」を並べる構図にした。
ついでに Google Workspace CLI（gws）を渡していく道具箱としてセミナーに組み込みたかったので、gws-cli-setup-guide.md の方は公開記事として別に切り出し、公式リポジトリのセットアップ手順を確認させてから書かせた。Claude Code に渡したのは「セミナードラフトに gws を道具箱として組み込め」「セットアップ手順は別記事に分離して公開扱い」の 2 つだけで、ディレクトリ構成・frontmatter・本文の章立てまで一気に書かせた。
「スライドっぽくして」指示で SVG 14 枚に埋め直す
ドラフトが文章ベースで一通り立ち上がったところで、「スライドっぽくしておいて、全部」と指示を出した。svg-diagram スキルを噛ませて記事内に SVG を直接埋め込む方針。720 幅・グレースケール＋マゼンタアクセント・塗りのみ・スライド番号付きの共通トンマナで 13 枚作らせ、デモ枠を「3本」→「4本」に拡張する判断を途中で挟んだので、書籍→スキル化のフロー図を 1 枚追加して計 14 枚にした。
タイムテーブルと description も「デモ4本」に揃えて貼り直した。ここまでで一旦見れる状態になり、ローカルで開いてざっと流した。
「10 時間で返すソリューションじゃない」と差し戻された
スライドを見返したユーザー（筆者）の中で違和感が立ち上がった。スライドの構図が「業務時間が短くなる」話に寄りすぎていて、自分が言いたかったことと噛み合っていなかった。
言いたいのは、7 時間あるルーチン業務のうち、入力・集計・転記といった 2 時間分を非同期で Claude Code に移譲して、人間はその空いた時間を別のことに振る、という話だった。「半分の時間で終わらせる」ではなく「2 時間分を AI に移譲する」が正しいフレーミング。
過去に「経営者が人を下に束ねる組織から、人が AI エージェントを束ねる組織に変わる。だから少数精鋭がいい」という記事を書いた覚えがあったので、Claude Code に「人がAIエージェントを束ねる」キーワードで過去記事を当てさせた。引用元として記事の URL を控え、新規 SVG スライドを 3 枚追加（5b、11b、11c）して本文を書き直す方針に切り替えた。
スライド 11b で「フロントで具体的に何をするか」の例を 1 枚足し、結論を「AI 投資の本命はフロント、バックオフィスは外注」に書き換えた。タイムテーブル・description・TODO・§12 のクロージングまで連動して直して、ようやく自分が話したい筋に近づいた。
ついでに ai-era-dismantle-division-of-labor.md にも比較用 SVG を入れた
セミナードラフトの構図と地続きの記事として、/ai-era-dismantle-division-of-labor（分業をやめて一人の守備範囲を広げる話）を思い出した。この記事は mermaid 図しか入っておらず、svg-diagram スキルを通していなかった。
既存の mermaid をいきなり置き換えると、生成された SVG が見るに堪えなかった場合の戻し作業が痛い。なので「mermaid はそのまま残し、各図の直下に svg-diagram スキル準拠の SVG を 1 枚追加して比較できるようにする」運用に振った。Claude Code に 6 枚作らせて、各 mermaid の直後に挿入させた。updatedAt も忘れず書き換えさせた。
矢印が崩れていたのに、目視確認をサボっていた
挿入直後にユーザー（筆者）がブラウザで開いて、矢印が崩れていることに気づいた。polygon と rect の重ね方を間違えていて、左向きの三角形に横棒がぶら下がる謎の形になっていた。
「矢印を描こうとせず、▶ の三角印だけでいい」とフィードバックして、Claude Code に grep で全 SVG を引かせた。ここで「スクショで目視確認はしましたか？」と問うと、Claude Code から「していませんでした」と返ってきた。svg-diagram スキル §6.6 に「スクリーンショット目視確認 — 必須」と明記されているのに、XML パースエラーチェックだけで通したことになる。
スキルに書いてあるチェックを飛ばすと、こうして他人（自分）の目で初めて発見される。Claude Code を責めても仕方がないが、自分がレビュー側に立つ前提で運用するなら、目視チェック工程を明示的に発火させる仕掛けがいる、と頭に書き留めた。
Python スクリプトで polygon + rect を ▶ だけに統一する
Claude Code に Python スクリプトを書かせ、polygon + rect(height=4) のペアをまとめて削り、右尖りの三角形 polygon だけに置換した。1 回目は元 SVG が持っていたミスの向きをそのまま継承してしまい、左尖りのままになる図が残った。スクリプトを「向きを ▶（右尖り）と ▼（下尖り）のどちらかに強制統一する」ロジックに書き直して再実行。
ここで一度躓いた。1 本目のスクリプトを叩いた直後、rect は全部消えていたのに、残った polygon の向きが揃っていなかった。理由は単純で、元 SVG が「左向き polygon ＋ 右側に rect」で矢印を表現していたパターンが混じっていて、rect だけ取ると polygon の左向きが裸で残っていた。「向きを判定して回す」のではなく「全 polygon を強制で ▶ 形状の頂点座標に書き換える」第 2 のスクリプトを別ファイルで書かせて、ようやく揃った。
矢印を一掃したあと、Claude Code に書かせた XML パースチェックで構文だけ確認し、今度は自分でブラウザを開いて 6 枚全部目視した。これが本来やるべきだった工程。
figure-02 は縦フローなので ▼ に統一する
▶ で一括統一したものの、figure-02 は BEFORE 上 → AFTER 下の縦方向フローだった。横向き矢印がフローの向きとズレていて、見ている側がどっちに目を動かせばいいか分からなくなる。縦フローの図だけは矢印を ▼ に差し替えて、横一律 ▶ ルールを破る判断を入れた。
figure-01 の「差し戻し」テキストの直後の矢印も、ラベルから離れて宙に浮いていたので、テキスト末尾の直後に近づけて配置を詰めさせた。
Y 軸の「低い生産性 / 高い生産性」が象限と逆だった
その次にユーザー（筆者）の目で拾ったのが、Y 軸ラベルの上下逆転だった。「上が低い生産性、下が高い生産性」と書かれていて、象限の中身（上が好ましい状態、下が好ましくない状態）と矛盾していた。上を「↑ 高い生産性」、下を「↓ 低い生産性」に直して整合性を戻した。
ラベルの上下は SVG を流し読みすると見落とす。Claude Code に「軸の意味と象限の中身が一致しているかチェックして」と明示しないと、機械的に座標値だけ見て通してしまう、というのも目視チェックの一環として頭に入れた。
figure-05 を「中途半端に横→縦」から「最初から縦一列」に作り直す
最後に拾ったのが figure-05 のレイアウト崩れ。横並びで始めて、入りきらなくなった最後の 1 ノードだけ下に折り返す、という中途半端な構図になっていた。
横→縦の途中切り替えは、見ている側に「最初から縦にしてほしかった」と思わせる典型パターン。「中途半端に横にする制約あったっけ？」と問い直したら、特に技術的制約はなくて単に Claude Code が「横並びにできるだけ詰める」を優先しただけだった。「入りきらないなら最初から縦一列でいい」と方針を伝えて、figure-05-three-person.svg を縦一列レイアウトで Claude Code に作り直させた。
縦一列にすると、横並びでは隠れていた「3 人の役割が直列に積み上がる」構図がそのまま読めるようになった。横並びを諦めるのは負けではなく、図の意味が立ち上がる選択だった、と気づき直した。これでようやく 6 枚並べて違和感がなくなった。
今日の学び
- スライドっぽい SVG を 17 枚（14 + 3）と、別記事の比較用 SVG 6 枚を 1 日で記事に埋めた。やってもらった量は多いが、自分がやったのは「ここがおかしい」と画面を見て指差すことだけ
- svg-diagram スキル §6.6 の「スクリーンショット目視確認 — 必須」を、Claude Code 側がサボっても自分側で発火させる仕掛けがいる。XML パースエラーがゼロでも、矢印が崩れている SVG は普通に出来上がる
- 「10 時間で返す」と「2 時間を AI に移譲する」は似ているようで全然違うフレーミング。前者は人間のスケジュールが空く話、後者は経営の組織設計が変わる話で、聞き手の動き方が変わる。スライドを作りながら言葉の選択でメッセージがブレることを実感した
- 横並びを途中で諦めて縦に折る図は、最初から縦一列にした方が読み手の目線が迷わない。図の制約は最初に決めておく
明日以降
- セミナー本番までに、ドラフト記事のスライドを Chrome DevTools MCP で全枚スクショ → 自分の目で 1 枚ずつレビューする工程を入れる
- svg-diagram スキルを使うフローに、「Claude Code 側で目視確認させたあと、自分側でも 1 枚はランダムスクショして見る」を運用ルールとして固定するか検討
- ai-era-dismantle-division-of-labor は SVG 比較を残したままだが、最終的には mermaid を消して SVG だけにするか、両方残すかを決める