セミナー草稿を Web スライドに統合、断層と噛み合わせ・決定論とAIの切り分けを1本のストーリーに

開発mdx-playground

記事版をスライドに畳み直した経緯

つくみBackofficeAIセミナー用に書いていた草稿記事は、章立てが膨らんで11章相当まで積み上がっていた。読み返すと同じ主張が別の角度で3回登場していたり、後半で挟んだ図と冒頭の§0.5の図が同じ壁を別語彙で説明していたりした。文章を並べるほど論点が分散していく感触が残った。

途中で方針を切り替え、記事側は「重複を削って章の順序を組み直す」、スライド側は「1つのストーリーとして最初から最後まで話し切れる形」に分ける決めをした。スライドは新しい Nuxt page apps/web/app/pages/tsukumi-slides.vue を切って、キーボードの左右キーとハッシュルーティングでスライド番号を移動できる形に組んだ。記事の冒頭にはスライドページへの遷移リンクを1本だけ張り、記事本文とスライドを独立したメディアとして扱う構成にした。

再構成は doc-communication スキルの「解・動・早／問題解決／スタンドアローン」を軸にして、11章の骨格を一度紙に落とし直してから書き直した。フレームワーク語彙（So What? / Why So? など）は読者向けには出さず、章の順序と接続詞だけで論理が通るように詰めた。

3つの断層と噛み合わせる3つの手

草稿を組み直す中で、労働者と経営者の間の3つの断層と、その断層に噛み合わせる3つの手が、きれいに1対1で対応していることに気づいた。

  • 時間と価値の断層 — 労働時間と生み出す価値が一致しない → 成果に対して報酬を払う
  • 情報の非対称性と要求水準の見せ損 — 節約した時間を吸い上げられる不信 → 見える化して、節約分は自由時間として本人に返す
  • 残余請求権の断層 — 増えた利益を分配する仕組みがない → 業務委託化して、上振れを本人に流す

最初は pair という新しい kind をスライドに追加して、左右2カラムの対応表として1枚に描いた。しかし通しで見返すと、対応表そのものが読み手の頭を止めていた。「対応関係を眺める」ではなく「なぜその手を打つのか」を読ませたかったので、pair 表は最終的に外し、断層の説明と噛み合わせる手のスライドを直列に並べる構成に戻した。対応表は自分の頭の整理用として残し、読者には各断層の直後に対応する手を見せて自然に対応関係が浮かぶ順序にした。

AIはソフトウェアエンジニアリングを増幅する道具

通しで並べたスライドを眺めていて、コアメッセージが抜けていることに気づいた。「AIってあくまでソフトウェアエンジニアリングの技術を増幅するためのツールなので、ソフトウェアエンジニアリングをよく知っておくことが何より重要」というメッセージを、フッター帯として3層構造で挟み込んだ。

  • グレー帯（典型フロー）: 「AIに1回だけ探索 → 決定論を .py / .ts に固める → 次からはAIを介さず再現」
  • 青帯: AIは増幅ツール、増幅させる本体（ソフトウェアエンジニアリングの技術）を知らないと出力は薄い
  • 黒帯: 道具そのものも AI に書かせて増やす（Chrome拡張・Python・Node スクリプト）

このメッセージが1回通ると、後段のデモスライドが「AIが全部やってくれる話」ではなく「決定論を積み上げる話」として読める。順番の効き目が大きかった。

決定論的処理と非構造化データ処理を切り分ける

コーディングエージェントを使うとき、AI に全部やらせると同じ入力から同じ出力が返ってこない。切り分けが要る。この話を1枚のスライドとして §6.5 に追加した。骨格は次の通り。

  • 決定論的処理（同じ入力なら同じ出力を返してほしいもの） → Python スクリプト、TypeScript の Node スクリプト、SQL、シェルに固める
  • 非構造化データを扱う処理（自然言語の解釈、画像からの抽出、意図の推定） → AI に渡す
  • 設計判断: どこを AI に渡し、どこをコードに固めるかを最初に切る

続くスライドで、実例として /make-diary コマンドの入れ子チェーン構造を1枚にした。/make-diary は決定論スクリプト（ログの分割、日付整形、SQLite への upsert）と AI 判断（要約、カテゴリ分け、記事化）が交互に走り、途中で /make-tweet や /review-yesterday-tweets など別のスラッシュコマンドをチェーン呼び出しする。全体を1枚の縦フローに落として、各ノードに「決定論 or 非構造化」のラベルを付けた。フッターには「Chrome拡張・Python・Node スクリプト — 決定論を担う道具そのものを Claude Code に書かせて増やす」という黒帯を入れた。

このスライドを追加してから、「AIエージェントの導入」がふわっとした標語ではなく「どこを固めてどこを AI に渡すかの設計問題」として読める形になった。

エグゼクティブサマリーをピラミッド構造で

29枚まで積んだ段階で、冒頭にエグゼクティブサマリーを1枚追加した。狙いは「各スライドのメッセージラインを縦につないだ時、そのままエグゼクティブサマリーの文章になっているか」を自分で検証すること。

構造はピラミッドにした。頂点に主メッセージ、その下に3つの柱（診断・転換点・打ち手）、さらにその下に各3つの根拠を並べ、上→下は「なぜそう言えるのか」、下→上は「だから何が言えるのか」の矢印を明示した。最初は So What? / Why So? のフレームワーク用語をラベルで表示していたが、通しで見た時にメタ言語がノイズになったので削除した。因果矢印と主メッセージ・3柱・結論バーだけが残る形にした。

作ってみるとロジックの穴が2つ見えた。3柱のうち「転換点」の根拠が弱く、後段のスライドで補強が必要だったこと、結論バーの文言が長くてフッターが右端で切れたこと。前者は根拠スライドを2枚差し込んで補い、後者は文言を短縮して1行に収めた。

content kind の SVG 化と改行問題

もともと Vue 側でテキスト直書きしていた content kind スライドが12枚あり、他の SVG image スライドとトンマナが合わなかった。全て SVG に落として image kind に置換する方針で、Python スクリプトから量産的に生成した。

生成後にブラウザで開くと、テキストが半分程度で改行され、右側にごっそりスペースが空いていた。原因は Python 側の折り返しロジックで、1行あたりの視覚幅を半角20〜25文字にケチっていたこと。実際の本文領域幅は 556px あり、日本語なら39文字分入る。split_by_visual の per_line を LINE_VISUAL に統一して再生成した後、Chrome DevTools MCP で11枚を1枚ずつスクショして目視確認した。改行崩れは残らなかった。

生成 SVG が全部同じ轍を踏んでいた理由は、テンプレートを共通化した副作用で「1箇所間違えると全部壊れる」構造だったから。逆に言えば「1箇所直せば全部治る」ので、修正の当たり所は明確だった。テンプレート量産の副作用としては、想定内の範囲に収まった。

副次的なつまずき

  • デプロイ検証スクリプト verify-unpublished-excluded.mjs が、非公開記事のパスを画像パス経由で誤検知した。content.includes(canonicalPath) の単純部分文字列マッチが /images/<slug>/figure-01.svg の一部を拾っていた。パス境界を見るように直した
  • スライド末尾のクロージングスライドに非公開記事の URL 文字列を書いていたのを外した
  • Chrome DevTools MCP でスライドを走査する際、Vue transition が hash 遷移とズレて記録された。transition を無効化して再計測すると綺麗に取れた

明日以降

  • 記事本文とスライドで主張が一致していることを、章タイトルとスライドタイトルの対応表で1度だけ機械的に確認する
  • エグゼクティブサマリー1枚の主メッセージを、記事の冒頭リード文にも反映する
  • Codex から出た指摘5件は反映済みだが、通し読みで再点検する