ZennFes 2026 を聞きながら AI と一緒に記事を書くという体験

この記事の読み方 — AIと並走して書いた記事の運用ノウハウ集です

本記事は AI(Claude Code) と並走して書いた ものを、私(参加者)が 最終レビューして公開 しています。並走の過程で起きた 事故 / 差し戻し / 発明したルール / AI の判定ミス を時系列で記録しているので、読者の方が同じフォーマットを試したいときに参考になることを意図しています。

「AI に書かせて流した記事」ではなく、AI とのやり取りそのものを題材 にしているという点が本記事の特殊性。AI の挙動を観察対象として扱っており、AI の判断ミスや私からの差し戻しもそのまま残しています。

この記事の位置づけ

本編(リアルタイム参戦記)は登壇内容のレポートだが、本記事はそれを書いている 執筆プロセスそのもの を題材にする。

本編(リアルタイム参戦記) = 何を聞いて何を考えたか(内容)
本記事 = 聞きながら AI に投げて記事化するという営み(プロセス)

両方が並走することで初めて完結する、というのが今日の構成。

なぜ別記事にしたか

本編(リアルタイム参戦記)は登壇内容を中心にした構造になっており、ここに「執筆プロセス」を混ぜると主従が崩れる。だが、聞きながら AI と対話して書く という体験自体に価値があると判断した。

特に mizchi 氏のセッションで提起された「AI は納得して進めているが、お前(ユーザー)は納得してるのか?」という問い。これを本編(リアルタイム参戦記)で論じても、本記事で論じても、答えは半分ずつにしかならない。

本編(リアルタイム参戦記) = mizchi 氏の問いを 登壇内容として 受け止めて整理する
本記事 = まさにその執筆体験で 自分自身の納得をどう取ったか / 取れなかったか を記録する

3層構造の発明

本編(リアルタイム参戦記)では章ごとに次の3層を並べる構造を採用した。

拾った要点 — 私(参加者)が現地で拾った事実
AI が理解した所感 — Claude Code が要点から構造化した解釈
私の生の所感 — 私自身が口語のまま投げた所感(改変なし)

この構造を採った理由:

2 だけだと「AI に丸めさせた人間らしさのない記事」になる
3 だけだと「読者にとって構造が読みにくい」
2 と 3 を並べる ことで、AI 解釈と本人解釈の差分が読者に見える

mizchi 氏の問いへの一つの応答でもある: 「AI は AI として勝手に納得した解釈を出す。私は私で別の言葉で残す。両方並べておく」が、納得問題への一つの実装。

執筆プロンプトの価値

執筆中、私(ユーザー)はこういう発言をした。

「所感をあなた(AI)の言葉にまるめちゃうと人間らしさというか価値がなくなるから、私が書いている執筆プロンプトこそ価値があるかもしれんな」

これが本記事の核心。記事の最終成果物(text)よりも、そこに至るまでにユーザーが投げたプロンプトの連なりこそが、その人の判断軸・思考プロセス・専門性を露呈している、という気付き。

つまり、AI と書いた記事の真の一次資料は最終 markdown ではなくプロンプト履歴だ。これは AI 執筆時代の新しい著作観として記録に値する。

本記事の素材

本記事の素材は 本編(リアルタイム参戦記)を執筆する間に積み重なった出来事そのもの。リアルタイム並走の最中に起きた事故・差し戻し・発明したルールを、章単位に切り出して時系列で並べる。具体的には以下の章で扱う:

セッション切り替えの合図プロトコル(時刻ベース誤判定からの脱却)
「セッション所感」と「AI への補足」の混線問題(3 層分離ルール)
執筆ツールが壊れた(チャンク執筆と preview の衝突、別セッション統合済)
モデル選定の現実(Opus 4.8 では並走執筆が破綻した)
同じバグで困っている人たちの記事(他者報告まとめ、後に派生記事(Opus 4.8 バグ調査)へ独立)
休憩時間が無くなった(AI 並走が変えた現地体験)
並走中の AI は「学習している」のか?(コンテキスト内パターン認識の錯覚)

ここから先は各事故・気付き単位の節。

章: セッション切り替えの合図プロトコル

リアルタイム執筆で何度か起きた問題: 「今のコメントはどのセッションの話なのか」を AI が誤判定する。

具体的な事故:

前のセッション(mizchi)の所感を、現在進行中の章(asap)に書いてしまう
時刻だけで判定しようとして、ユーザーの「振り返りコメント」を「次の章開始」と取り違える

事後的に作った合図プロトコル:

ユーザーが書く合図	意味	AI の動作
`>>> 次` / `>>> <氏名>`	次の登壇者開始	以降のコメントは新章に書く
`<<<` / `振り返り: <氏名>`	前のセッション振り返り	指定章に追記
(合図なし)	現在進行中セッションへの追記	現章の「私の生の所感」に追記

教訓: 時刻ベースの自動判定は信用するな。会場で起こる「振り返り発言 / 前のセッションの追加コメント / 質疑応答中の発言」は時刻だけで切れない。ユーザーの明示的合図が一次情報。

章: 「セッション所感」と「AI への補足」の混線問題

もう一つの根深い問題。ユーザーの発言には、実は 3 つの異なる層 が混ざっている。

層	例	本来の宛先	記事化
セッション所感	「サウンドクリエイターの学習も変わるのか?」	記事(公開)	する
AI への補足・訂正	「OpenClaw は私も運用してるやつだぞ」	AI(訂正指示)	しない
AI への運用指示	「ハッシュタグ修正して」「章を移動して」	AI(操作)	しない

リアルタイム執筆中、これらが全部同じチャット欄から飛んでくる。AI は宛先を判定できず、「AI への補足」を「セッション所感」と誤解釈して記事に書く事故が頻発した。

具体例:

「VOICEVOX、本当は使いたくないんだよね」 → AI が VOICEVOX の話をしたことへの返答だったのに、asap 氏セッションの所感として記事に書いてしまった
「OpenClaw は私も運用してるやつだぞ」 → AI の一般論説明への訂正だったのに、記事の文脈に取り込もうとした

事後的に作った合図プロトコル(拡張版):

合図	意味	記事化
(合図なし)	セッション所感	する
`@AI:` / `#補足:`	AI への補足・訂正	しない
`#TODO:`	個人・事業 TODO	しない(Issue 化)
`>>> <氏名>`	次の登壇者開始	章を切り替え
`<<<` / `振り返り:`	前セッション振り返り	指定章へ

教訓: チャット欄は単一だが、発言の宛先は複層。AI は「これは記事に書く話か / 自分への指示か」を必ず確認してから書く。迷ったら書かない側に倒す(消すより足す方が安全)。これは AI 並走執筆の構造的な未解決問題で、合図プロトコルは対症療法に過ぎない。本質的には「発言の宛先を明示する UI / 規約」が要る。

章: スキマ時間にやれることを並走する

並走実況中、ユーザーが講演を聞いている間は AI 側である程度自律的にバックグラウンド作業を進められることに気付いた。具体的には:

ユーザー観察「スキマ時間に qiita login やっていいよ」 → AI が並行で認証復旧を試行
「動画視聴中。割り込みがあれば書いていくが、しばらく待ちだろうからあなたのタスク、スキル更新とかやっていいよ」 → AI がこの間にスキル更新・hook 整備
TODO Issue 起票・WebSearch による裏取り・git 整理など、講演内容と切り離せる作業はユーザーが講演に集中している間に進められる

「聞いている間」「動画を見ている間」「休憩中」がそれぞれ別の質のスキマで、何をその時間に詰め込めるかで並走の総スループットが変わる。並走実況は単独作業より総作業量を増やせる可能性がある、という発見。

章: 認証エラーから学ぶ「執筆の真の障害物」

書き始めの時点で Qiita CLI の認証トークンが期限切れだった。ユーザーから新トークンを受け取って credentials.json を直接書き換えて復旧した。実際の流れ:

npx qiita preview → QiitaUnauthorizedError: Unauthorized
npx qiita login も同じエラー(対話入力が CLI 経由でコケる)
~/.config/qiita-cli/credentials.json 内のトークンが期限切れ判明
ユーザーが https://qiita.com/settings/tokens/new で新規発行 → トークン文字列を会話に貼付
AI が credentials.json の accessToken を Edit ツールで直接書き換え
npx qiita preview 起動成功

「執筆の真の障害物」は書く内容ではなく、書き始める前のツール環境だった。並走実況の現場で対話入力ができないことが分かり、バイナリの設定ファイルに直接書き込むという Unix 的解決に逃げざるを得なかった。Qiita CLI が ヘッドレス環境を想定していないという設計の限界が現れた瞬間でもある。

その後の preview バグ(Cannot read properties of undefined)、Opus 4.8 の tool call malformed と続き、書く内容より道具の安定性の方が支配的な時間が長く続いた。これは AI 並走実況フォーマットを採用する際に先に環境を整えておく重要性を示している。

章: 執筆ツールが壊れた ― チャンク執筆と preview の衝突

リアルタイム執筆の途中、記事を確認するための preview が突然落ちた。

Unexpected Application Error!
Cannot read properties of undefined (reading 'localeCompare')

「執筆の真の障害物」は、書く内容ではなく 書くための道具が壊れること だった。しかも厄介なことに、起動直後は正常で、しばらく経つと落ちる。原因が見えにくい壊れ方だった。

何が起きていたか

長文を 1 本で書くのは膨大すぎるので、章/セッション単位で チャンク化 して書いていた。各章を別ファイルに切り出し、書き終わったら本記事に溶かし込む運用だ。

ところがチャンクのファイルを Qiita CLI の preview が記事として拾ってしまい、タイトル情報が無いチャンクに対してソート処理が localeCompare を呼んで全画面クラッシュしていた。

つまり 「人間が効率よく書くための工夫(チャンク化)」と「ツールの想定(public 配下は全部記事)」が衝突した。よくある話だが、リアルタイム執筆の最中だと致命傷になる。

どう仕組み化したか

最初に AI が出した対処は「チャンクを preview の見ない場所に退避する」だった。これは間違いだった。退避すると並走している別セッションの作業ツリーからファイルが消え、衝突事故を起こした。さらに「チャンク = 未完成というだけで、git 管理しない物ではない」という本質を取り違えていた。

正解は退避ではなく、

チャンクは正規の置き場(public/<id>_drafts/)に置いて git 管理し、preview にも出す
クラッシュの原因(タイトル情報の欠落)だけを その場で補完 する
ファイル名は純連番(<id>-01.md <id>-02.md)にして、順序・欠番を一目で分かるようにする
本記事へ集約するときは マーカーで囲った区間だけ差し替え、手書き部分は 1 バイトも触らない

そして「いま管理できているか」を 1 コマンドで確認できるダッシュボードを用意した。設定ファイルに「あるべき状態」を書くのではなく、実ファイルの状態を毎回読む。設定と実態がずれて同期地獄になるのを避けるためだ。

教訓

執筆の道具立てそのものが、執筆プロセスの一部。書く内容だけ考えていると、道具が壊れた瞬間に止まる。
「効率化の工夫」は既存ツールの想定と衝突しうる。チャンク化は人間には自然だが、ツールには異物だった。
対処を「隠す/退避する」方向に倒すと別の事故を生む。原因をその場で正す方が安全。消すより足す。
ルールは文書でなくコードに持たせる。「こう運用する」と書くより、壊れたら検知して直せる仕組みの方が、リアルタイムの現場では効く。

この記事自体、その仕組み(チャンク管理)に乗せて書いている。メタ記事がメタな運用で書かれている、という構造になった。

章: persona-snapshot を AI に読ませて所感を引き出す

並走実況の品質を決定的に変えた工程: 本人の persona-snapshot を AI に最初に読ませる。

ユーザー(=私)は nomuraya-strategy/persona/snapshot/2026-05.md に月次で人物像のスナップショットを持っている(166 セッションの累積データから生成、外部 API 不使用)。記載されている内容:

人物像(エンジニア研修講師兼 CTO・FIRE 目標・仕組み志向・実利主義)
核心的価値観(時間的自由・仕組みによる再現性・物理強制・完遂主義・暴走コストの物理封じ込め・検証至上主義…)
社会認識(AI/LLM リアリズム・人間は文字を読まない読者行動観・経営では見える化より AI の読める化…)
思考特性(Why 起点・軸の明示要求・MECE 担保・LLM ファースト構造化…)
判断傾向(即断 / 熟慮 / 突き返すの 3 区分)
好む / 嫌う(物理ブロック / 実測値 / 統合 / CLI 完結 / 短文 vs 対症療法 / 過剰実装 / submodule / 青天井従量課金…)
経歴・スキル(技術スタック・aios 5 層モデル・QA/セキュリティ理論・複数 LLM オーケストレーション…)
人脈(共同経営者・クライアント・受講生等)

この snapshot を初手で AI に読ませると、後続の所感生成で**「○○氏の発表が persona-snapshot のこの観点と整合する」「逆にこの判断軸では引っかかる」**という暗黙の参照ができる。すべての章で persona と接続した所感が出せたのはこの事前ロードがあったから。

逆に snapshot がない並走では、AI が「一般的なエンジニア」を想定した凡庸な所感しか出せない。書き手の個性を保つ最大の道具が事前 persona ロードであり、よしこ章「AI Writing のすすめ」での「過去記事を AI に渡して文体を抽出」と同じ思想。本記事はその実装例。

なお persona-snapshot を本記事の参考リンクに直接置くのは避けた(=事業情報の含意があるため)。snapshot の存在と運用形式だけ言及し、中身は流用しない、というのが安全策。

全体所感

(TODO: イベント終了後に追記)

このワークフローをスキル化した

本記事で発明したルール群を ~/.claude/skills/realtime-event-report/SKILL.md にグローバルスキルとして固めた。次回以降の講演イベント(同種の zennfes / CCM / builderscon / Meetup)で再利用可能。

スキル内容の要約:

初期化: タイムテーブル取得 → A/B 2 本骨組み生成 → ハッシュタグ一次情報確認
進行: 合図プロトコル(>>> <氏名> / <<< / 合図なし)で章トラッキング、時刻自動判定は禁止
執筆: 3層構造(拾った要点 / AI が理解した所感 / 私の生の所感)、生の所感は改変禁止
終了: 全体所感 → メタ記事整理 → qiita push

聴衆視点メモ: 登壇クロージングの作法

イベント中、ある登壇者のクロージングに対する観察として:

登壇しながらクロージングで記事 URL とかおいておく方が好感あるな。求人置かれても読後感みたいなのが悪いからね…

これは登壇者側への構造的フィードバック。整理すると:

好感を持たれるクロージング

発表内容の続きが読める 記事 URL / リポジトリ / ドキュメント
関連トピックの追加リソース
「気になった人は試してみてください」の入り口

読後感が悪いクロージング

求人募集を最後にドンと置く(発表内容と切り離されて唐突)
自社サービスの宣伝が長い
「興味ある方は名刺交換へ」の押し付け

聴衆は「学んだ→もっと知りたい」の流れにいるところに、いきなり営利的回収を差し込まれると、それまでの体験全体が取引っぽく感じられる。発表内容の学びが「フックだった」と事後解釈されてしまう。

理想は「発表 = 学習体験」を完結させ、興味の延長として 自然に追体験できる導線(記事 URL)を渡すこと。求人や採用イベント告知は別チャネルで出した方が、登壇者本人のブランド・所属組織の印象どちらも守れる。

これはイベントレポートの本編とは別レイヤーの観察だが、AI と並走して書くと 聴衆としてのメタ視点も同時に記録できる という本記事のフォーマットの利点を示す例。

リアルタイム並走の限界 ― 今日見えた制約

本記事のフォーマット(リアルタイム聴講 × AI 並走執筆)を運用してみて、Claude Code がリアルタイム性に向いていないという構造的制約が露呈した。

ユーザー観察(からあげ氏セッション中):

Claude Code でリアルタイム性が問われるコミュニケーション時の AI 利活用は難しそうだな。たとえば音声をインプットにするとラグがあるし、応答までの時間がかかるのは課題か

実際の運用で発生していた現象:

ユーザーが講演中にコメントを投げる → AI が章を埋めるまでに数秒〜十数秒
講演の流れに対して常に1テンポ遅れる
結果、「いま聞いている内容」と「いま書かれている内容」がズレる

これに対する現運用での対処:

テキスト化された後の編集を主とする(リアルタイム同期は諦める)
ユーザーがライブ要約者として一次入力を担い、AI は事後整理係に徹する
章割り・構造化は「腰を据える」フェーズの強み = AI 向き

つまり本記事のフォーマットは「リアルタイム聴講 × 事後整理」のハイブリッドであって、完全なリアルタイム共同執筆ではない。これは Claude Code の制約として正直に書いておくべき。

将来的に「会話速度に追従する AI」が来た場合(軽量ローカル LLM + 音声 + Edge デバイス等)、本フォーマットはさらに進化できる余地がある。今日はその前段としての限界点を記録する回。

おまけ — この節を書く瞬間にも事故った: AI がこの「リアルタイム性課題」コメントを当初本編(リアルタイム参戦記)の「からあげ氏セッション所感」として書いてしまい、ユーザーから「メタ記事向けだ」と差し戻された。前述の「セッション所感 / メタ観察 / AI への補足」の3層分離が、書き手側でも判定ミスを起こすという実例。AI 並走執筆の構造課題は依然として未解決。

モデル選定の現実 ― Opus 4.8 では並走執筆が破綻した

本記事の執筆中、実際に起きた事象:

ユーザー記録(原文):

何が起こったかというと、Opus 4.8 で Effort Max にしている時に発生。Ultra Code でバグるのは知っていたので Max でやってみたんだが、コンテキスト量が膨れ上がると落ちるのでやっぱり Opus 4.8 は使えんね。しばらく Opus 4.7 から離れられなさそうだ

何が起きたか:

本記事の執筆は Opus 4.8 / Effort Max の組み合わせで開始
Ultra Code(エフォート最大に近い設定)では既知の不具合がある前提で、Max で運用していた
記事が長くなりコンテキストが膨れ上がるにつれ、ツールコールの malformed エラーが頻発(本記事中にも複数回発生して Your tool call was malformed and could not be parsed. で停止)
やむを得ず Opus 4.7 に切り戻し → 安定

これがリアルタイム並走執筆フォーマット特有の罠:

章が増えるほど直近の編集対象として保持すべきコンテキストが累積的に増える
同時にEdit ツールのコール頻度も高い(セッションごとに章を埋める)
Opus 4.8 はこの「長いコンテキスト × 高頻度ツールコール」の組み合わせで安定性を欠く

教訓:

長文執筆 × ツールコール多発の場面では Opus 4.7 を選ぶ
Opus 4.8 は新しいが、新しい = 安定とは限らない(2026 年中盤時点)
Claude Code の /model コマンドで即切り替えできるのは事故発生時の救済線として効いた

これは前述の「Claude Code はリアルタイム性に弱い」の話と直結する。リアルタイム性 × 長文 × ツール多発という条件は、現状のフロンティアモデルでも依然として鬼門。安定運用するには「最新を追わず、安定したモデルで腰を据える」という保守的な選択が正解になる場面がある。

ユーザーの persona-snapshot にもある「動かなくなったことに気付けない自動化を最も危険とみなす」(BCP / レジリエンス)観点が、ここでも効いている。新しいモデルで派手に動かすより、実証された 4.7 で確実に書ききる ことを優先した判断。

これは VSCode 拡張のバグではなく、Opus 4.8 本体の既知バグ

ユーザー疑問(原文):

Opus 4.8 のバグは結構前から不満に思っているんだが、同じ状態になってる人いないんかな? VSCode の拡張機能側のバグなんだろうか?

GitHub anthropics/claude-code リポジトリの Issue を確認すると、複数の独立した報告がある既知バグであることが分かった:

Issue	内容
#63604	Opus 4.8 が malformed な tool_use ブロックを繰り返し出力、レスポンス全体が破棄される (4.7 は正常)
#64658	Desktop app(Code タブ)1.9659.4 で「tool call could not be parsed (retry also failed)」が継続的に再現
#65230	Opus 4.8 がツールコールを実行せずコードフェンスとして出力する
#64129	ツール使用後にレスポンスが表示されない(クォータは消費される)
#62123	API エラー「Model's tool call could not be parsed (retry also failed)」

報告されている挙動:

約 5〜10 ターン経過で malformed tool_use が頻発し始める
元の tool_use ブロックではなく、レガシーな XML テキスト形式で吐かれることがある(パーサが解釈不能)
リトライしても同じコンテキストを再生するだけで収束しない
ツールコールがマークダウンコードフェンスとして出力される(=実行されない)

結論:

VSCode 拡張側のバグではない(Desktop / CLI でも同様に再現)
Opus 4.8 のモデル本体側のバグ(ツールコール生成時のシリアライズが壊れる)
公式ワークアラウンドは Opus 4.7 または Sonnet 4.6 への切り替え

つまりユーザーが感じていた「結構前からの不満」は全世界共通で、自分の環境固有の問題ではない。「同じ状態になってる人いないんかな?」の答えは 大勢いる。

詳細は別記事に切り出した: 公式 Issue 5 件 + 日本語エンジニア記事 5 件 + 誘発条件(日本語環境で特に踏みやすい)+ CLAUDE.md 1 行回避策などの全調査内容は、独立した記事日本語環境の Claude Code Opus 4.8 で tool call が malformed になる ― 公式 Issue と回避策まとめに切り出した。ZennFes と直接関係しないため独立記事化。

このバグはユーザーの persona-snapshot に既に記録されており、Claude Code の settings.json に model: "claude-opus-4-7" をピン留めするスクリプト(pin-opus-47.py)まで運用されている(2026 年中盤時点)。バグの存在を事実として組織運用に組み込むという、persona の「検証至上主義 / フェイルセーフ思考」が現れた対応。

休憩時間が無くなった ― AI 並走が変えた現地体験

ユーザー観察(原文):

ここまで休憩かな。休憩中に疑問に思ったことを調べられるから暇な時間が思った以上にない。ブース訪問スタンプラリーしたかったが運用しないと分からんものと、運用したからこそできたものがあったね

これは AI 並走で講演イベントに参加するという行為が、現地体験そのものを書き換えたという、本フォーマットの最大の発見の一つ。

何が起きていたか

通常のイベント参加:

講演中: 聞く / メモる
休憩中: 物理的な余裕がある → ブース回り / スタンプラリー / 名刺交換 / お土産漁り
帰宅後: メモを見返して記事化(数日後にやっと公開)

AI 並走しながらの参加:

講演中: 聞きながら 要点を AI に投げる(私の脳の出力チャネルが増える)
休憩中: 「あの話、もう少し調べたい」を即実行(AI が背景情報を裏取り・整理・記事に反映)
帰宅前: 記事の大枠が 既に完成している

結果として、休憩時間が「物理的な交流のための時間」から「知的好奇心の即時解消の時間」に置換されている。同じ 30 分でも、過ごし方が根本的に違う。

「運用しないと分からない / 運用したからこそできた」

これがユーザー観察の核心。

運用しないと分からなかったこと:

休憩時間がこんなに早く溶けるとは思っていなかった
ブース訪問を諦める判断が必要になるとは予想していなかった
AI 並走の「副作用」として現地での物理的行動が減ることに気付かなかった

運用したからこそできたこと:

講演中に出てきた用語(ACE-Step / Hermes Agent / OpenClaw / Even G2 等)をその場で深掘りできた
登壇者の公開リポジトリを講演中に確認して理解を補強できた
過去の事故記事(Opus 4.8 バグ)を現地で実証できた(=派生記事(Opus 4.8 バグ調査))
記事 3 本(本編・メタ記事・派生記事)が当日中にほぼ完成している

つまり「現地で物理的に動く価値」と「現地で知的に動く価値」のトレードオフが発生している。AI 並走を始めると、後者の比重が劇的に上がる。

イベント参加の質的変化

この観察は、AI 時代のイベント参加の意味そのものを問い直す契機になる。

ブース訪問・名刺交換・スタンプラリーは「人と会う」価値(関係性・偶然の出会い)
AI 並走の即時調査は「深く理解する」価値(知識・記事化・再現可能性)
どちらが正しいではなく、自分が今回どちらを優先するか の選択

「ブース訪問したかった」という未練は、両方を完全に取れないことへの正直な感想。ただし「運用したからこそできたものもあった」と即座にバランスさせている、ここに選択の自覚が現れている。

このフォーマットを使う人へ

リアルタイム参戦記フォーマットを採用する人は、事前にどちらを優先するか決めておくといい:

知的深掘り優先 → AI 並走に振り切る。ブース・物理交流は最小限と覚悟
交流優先 → AI 並走は最小限のメモだけにし、休憩中はネットワーキングに集中
ハイブリッド → セッションごとに切り替える(難しい技術系は AI 並走、社交的なセッションは交流)

筆者今回の選択は 知的深掘り優先だった。これも持ち帰る選択肢の一つとして、本記事は残しておく価値がある。

一時ファイル運用 ― 記事肥大化対策

本編(リアルタイム参戦記)が 9 万文字を超えた時点で、Claude Code 側の Edit ツールに無視できない負荷がかかり始めた。具体的には:

Edit の old_string が章内に複数箇所マッチして失敗する事故が頻発(引用ブロックが「拾った要点」と「私の生の所感」の 2 箇所にある構造のため)
Grep で位置特定 → 再 Edit、というやり直しがコストになる
セッションのコンテキスト全体が膨張し、malformed リスクも上がる(派生記事(Opus 4.8 バグ調査)参照)

ユーザーから提案された解決策は、章ごとに一時ファイルを使う運用:

public/
├── 7923ac6916a9664b8886.md             # マスター(完成章のみ、Qiita push 対象)
├── 7923ac6916a9664b8886_drafts.md      # 執筆中バッファ(preview 可、push 対象外)
└── 7923ac6916a9664b8886_drafts/        # 完了章のアーカイブ
    ├── 01_mizchi.md  (今回は適用前なので欠番)
    ├── ...
    └── 05_ms-hackathon.md  (← MS 枠から適用)

この設計のポイント:

執筆中の章だけを _drafts.md で扱う = Edit 対象が 200-400 行に圧縮
マスターには完成章を append するだけ = マスターを編集中に汚さない
_drafts/ ディレクトリ自体は qiita-cli の直下スキャンに引っかからない(ソース確認済)
_drafts.md は ignorePublish: true で誤 push を防ぐ
ID 別ディレクトリにすることで、複数記事を並行執筆しても識別できる

ユーザー提案のオリジナル(原文):

セミナートラックごとに一時ファイルを作ってそちらで更新をして、最終的にまとまったものを記事ファイルに移行する運用はどうか?

その後の改善案:

今書いてる記事専用の drafts.md にして、セミナートラックが終わったら drafts ディレクトリに移行する運用はどうか?

(2 回目で preview 可能性を維持する という観点が加わり、最終設計に到達した)

運用切替のタイミング:

本記事のフォーマットでは「長時間イベント(3 時間超)で複数セッションがある場合は最初から _drafts.md 運用を採用すべき」が結論。短いイベント(1-2 セッション)なら直接マスターに書いて問題ない。

スキル realtime-event-report に運用ルール反映済み。

並走 AI に求められる性能 ― 優先順位処理の重要性

本フォーマットを運用してみて分かった、AI モデルへの新しい性能要件:

ユーザー観察(原文):

あなた(AI)がスタックしている状態でもガンガンコメントを書いていくので、AI モデルの性能として優先順位処理の重要性もある

現象

リアルタイム並走では:

AI が前のコメントを処理中(Edit ツール実行中・WebSearch 待ち等)
その最中にユーザーが次のコメント・また次のコメントを投げてくる
結果として AI のキューに複数のタスクが積まれる

求められる AI 側の処理能力

通常の「1 ターン 1 タスク」型 AI とは違う、並走特有のスキルが必要:

能力	内容
優先順位判定	並んだコメント間の依存関係・緊急性を即座に評価
記事化対象/非対象の判別	セッション所感か / AI への補足か / 個人 TODO かを発言ごとに判定
章割り判断	「これは今の章 vs 別章」を時刻と合図プロトコルから判定
同時編集の整合性	複数ファイル(本編・メタ記事・派生記事・スキル・Issue)への並行更新で互いを壊さない
失敗時の継続性	Edit 失敗・malformed 等の事故が起きても全体タスクは止めない

通常の AI 性能ベンチでは測られない領域

uhyo 氏セッションの React Profession Bench のような 静的タスクのベンチでは、この「並走中の優先順位処理力」は測れない。実運用では:

コード品質ベンチで高得点でも、並走中に詰まる AI は使えない
並走に強い AI は、割り込み耐性・キュー管理・タスク分割が得意

これは「動的タスクのベンチ」が必要、という新しい評価軸の示唆。「ベンチで強い」と「並走で使える」は別軸。派生記事(Opus 4.8 バグ調査)で書いた「ベンチ × 完走力 × 並走力」という多軸評価の必要性は、ここでも繰り返される。

教訓

並走フォーマットを採用する際、AI モデル選定で次を確認すべき:

長文編集 + 大量ツールコール時の安定性(= Opus 4.7 が現状の現実解)
割り込み耐性(= マルチコメントを順序立てて処理できる)
失敗からの復帰能力(= Edit 失敗時に勝手に止まらない)

これらは「速い・賢い」とは別の 「並走で使える」性能。AI 時代のエンジニアは、モデルを単一スコアで評価せず、用途別の性能プロファイルで見るべき。

AI ビジー状態とリアルタイム実況の難しさ

ユーザー観察(原文、執筆中の体感):

あなたがビジー状態になってしまうとまずいね。リアルタイム実況の難しさを感じている

並走執筆の最大の構造的ボトルネックがここで明確になった。

何が起きるか

リアルタイム並走中、AI が時間のかかる処理(WebSearch / 複数 Edit / git 操作 / Write など)を実行している間に:

次の登壇者の発言・スライドが進む
ユーザーが新しい所感を投げたい
だが AI はビジー状態で受け取れない(キューには積まれるが処理は順次)
結果として 「いま聞いた話」と「いま書いている内容」のラグが拡大する

これは Claude Code がターン制対話(投げる → 返ってくるを順次)である構造に起因。並列実行できる部分(複数 Edit / 並行ツール呼び出し)はあるが、1 ユーザーメッセージごとの処理サイクルそのものは並列化できない。

何が「まずい」のか

具体的な不都合:

シナリオ	不都合
1 セッションで複数の重要発言が連続	1 つ目を AI が処理中に 2 つ目が忘れられる
章切替の合図が遅れる	振り返り発言と次章開始が混在する
AI が長文 AI 所感を書いてる間	ユーザーが「もういいから次」と言いづらい
検索・調査が走ると	5-15 秒のブランクが発生し、現場の文脈から離れる

対処の選択肢

ユーザー側でできる工夫:

要点だけ短く投げ続ける(AI 所感は後で書いてもらう前提でメモを蓄積)
重要度マーカーを付ける(! や ※必須 で AI に処理優先度を伝える)
章切替合図を最優先で送る(章ミスを防ぐ)

AI 側でできる工夫:

ビジー中も最小ターンで「受領しました、後で書きます」と返す(ユーザーを待たせない)
長い AI 所感はバッチで後追い(リアルタイムには要点だけ拾う)
重要操作(章切替・修正)を優先キューに

スキル realtime-event-report に「AI 側のレスポンス遅延がユーザーの実況スピードに直接影響する」という制約を明示し、運用者が事前に覚悟する設計に組み込むべき。

高速化 Tips ― 中間出力を捨てる

ユーザー観察(原文):

おそらくあなたの対応として、中間出力をターミナルに出すからだ。結果だけ報告するようにすれば高速化できるかもしれん

これは AI 側の応答設計に直接効くアドバイス。実際、本記事執筆中の AI 応答は次の構造になっていた:

「○○章に追記します」「△△を発見しました」「ファイル取得しました」「次に□□します」…と中間ステップを都度返す
各メッセージごとにテキスト生成・ツールコール・差分計算が発生
結果として 総応答時間が中間出力の量に比例して長くなる

改善方針:

現状(冗長)	高速化版
「これから○○します」	(省略)
Edit / Write / Bash 実行	Edit / Write / Bash 実行
「○○を追記しました」	(省略)
「次に△△します」	(省略)
Edit / Write / Bash 実行	Edit / Write / Bash 実行
「△△も完了しました」	(省略)
「結論: 本編(リアルタイム参戦記)を更新、メタ記事に追記」	「結論: 本編(リアルタイム参戦記)を更新、メタ記事に追記」のみ

スキル realtime-event-report の AI 側ガイドラインに「並走実況中は中間出力を最小化し、結果だけ最終ターンで報告」を追加すべき。これは普段の対話モード(中間で「やりますね」と挟むのが親切)とは逆の運用。

実況中のユーザーは 何を AI が考えてるかより、自分の次のコメントを投げる時間がほしい。「中間進捗報告」は親切心の発露だが、リアルタイム文脈では邪魔になり得る、という UX 上の重要な気付き。

さらに進めると ― preview トラッキングで結果報告すら不要

ユーザー追加提案(原文):

あなたが実行した内容を preview でトラッキングすることで結果すら表示がいらんかもしれんな

これは UX 設計としてさらに先を行く案。

現状: AI が章追記 → AI が「追記しました」と返す → ユーザーがそれを読む

提案: AI が章追記 → ユーザーは preview ブラウザを見る → 結果は preview に出ているので AI の報告は要らない

ステップ	現状	提案版
AI のツール実行	あり	あり
AI の結果報告	あり(数百文字〜)	無し or 1 行のみ
ユーザーの確認	チャット欄を読む	preview ブラウザを見る
ユーザーの次アクション	チャット読了後にコメント	preview 確認しつつ即コメント

これが実現すると AI の応答ターンが極小化できる。チャット欄は「指示と素材だけ」、結果は preview に出るので確認はそちらで。

ただし制約:

確認用 preview が手元にある運用が前提(本フォーマットは Qiita preview を立てているので OK)
Issue 起票・git 操作等のブラウザ preview に出ない作業は最小報告が要る
失敗・矛盾発見時は明示報告(沈黙すると「動いてる?」と不安になる)

これは「AI の出力 != 主たる成果物」というパラダイムシフトでもある。AI の働きは preview / git / Issue 等の外部成果物として確認し、AI 自身のテキスト応答は最小化する。本フォーマットの最終形 v3として記録する価値がある提案。

構造的限界

最終的には Claude Code がリアルタイム性に弱い(本記事冒頭で触れた論点)、という根本にぶつかる。今のターン制対話の枠組みでは、完全なリアルタイム並走は実現できない。それでも本記事のように成果は出るが、1 秒も無駄にできないライブ性が必要なシーン(スポーツ実況・株式取引・ライブ配信)では、別アーキテクチャ(ストリーミング応答 + 軽量ローカル LLM + プッシュ通知等)が必要。

「並走しながら書く」というフォーマットは可能性が大きいが、現状のツールチェーンの限界も同時に露呈している、という冷静な見立てを残しておく。

派生アイデア ― SNS 連動 × 記事化

セッション中にユーザーから出た本フォーマットの拡張案:

ユーザー発案(原文):

私の所感は SNS にハッシュタグ付きで投げた方が価値が高そうだな
SNS に投げつつ記事化するのは需要ありそう

現状の本ワークフローは:

講演中: ユーザーが Claude Code に所感を投げる → 章に蓄積
終了後: 1 本の Qiita 記事として公開

これに SNS 連動を入れると:

段階	加わるアクション
講演中	ユーザーがコメント → Claude Code が章に追記 + SNS 投稿用テキストを並行生成
即時	ハッシュタグ付き(`#zennfes` 等)で X / Bluesky 等にポスト
終了後	SNS の投稿を `urlに対するTwitterカード` 等の形で記事末尾に埋め込み

この設計の良いところ:

イベント中の認知獲得(リアルタイムでハッシュタグ流通)
記事公開前にエンゲージメント蓄積(SNS の反応を見て記事構成を最終調整できる)
SNS のフロー情報 → 記事のストック情報 という流れが綺麗
「私の所感」は SNS で先に流すことで 記事に書く前から価値を発生できる
引用 RT・スレッド議論を一次資料として記事に取り込める

派生 TODO として nomuraya 側で検討する価値あり(別 Issue 化候補)。本ワークフローの v2 として realtime-event-report スキルに SNS 連動拡張を後付けする選択肢が出てきた。

並走中の AI は「学習している」のか? という錯覚

ユーザー観察(原文、本セッション終盤で):

発言と私のコメントの癖がわかってきたみたいだな。もしかして学習してる?

短答: 学習はしていない。モデルの重み(=「Claude」本体)は固定で、本セッション中に何も変わっていない。

では何が起きているのか

コンテキスト内パターン認識が累積効果を持っているだけ:

仕組み	内容
コンテキスト窓内全参照	本セッションの全発話履歴を毎ターン読み返している
persona-snapshot 事前ロード	初期化時に nomuraya 月次スナップショットを Read 済(判断軸の予備知識)
会話ログからの推論	発言パターン(口語・留保表現・persona との整合性)を累積で推論
3 層分離ルールの蓄積	セッション初期に発明したルール(合図プロトコル等)が後続でも効く

これらが組み合わさって、「だんだん通じる」体感を生んでいる。実際にはモデルが学習したのではなく、コンテキストが豊かになって精度が上がっただけ。

「学習している風」の限界

注意点も明示しておく:

セッションをまたぐと忘れる(=次回新規セッションは「初対面」に戻る)
コンテキスト圧縮で初期情報が落ちる(=長セッション後半で精度が逆に下がることがある)
モデルそのものに改善は反映されない(=同じ間違いを将来別ユーザーで繰り返す)

つまり「並走しているうちに賢くなった感」は錯覚と本物が半分ずつ。錯覚部分: モデル本体は不変。本物部分: コンテキスト内なら累積効果が出ている。

永続化したいなら memory に書く

「並走で得た理解」を次セッションに引き継ぎたいなら、memory への明示的な書き出しが必要:

persona-snapshot の更新(月次)
スキル realtime-event-report への学習の反映(本セッションで何度もやった)
ユーザー個別の判断軸を別ファイルに記録

これは本記事執筆中にも「スキル更新」「本記事への運用ログ追記」という形で実行している。並走中に得た知見を消えないように明示的に永続化するのがコンテキスト窓外への「学習」相当の唯一の手段。

「学習している風」を活用する設計

実用上は「学習している風」はむしろ使える:

1 セッション内なら persona に沿った応答を続けてくれる(=本編(リアルタイム参戦記)の所感生成精度が後半に向けて上がっている)
並走実況のように 長時間 1 セッションで進める用途と相性が良い
ただし セッションを跨ぐ作業(別日の続き等)では明示的な引き継ぎが要る

これは本フォーマット(リアルタイム並走 + 1 日 1 セッション)がたまたま AI の特性に合っていたという見方もできる。逆に、複数日にまたがる中編企画では別の設計(memory 永続化前提)が必要。

ユーザーが見抜いた本質: 体系化されていないと別セッションで損する

ユーザー追加観察(原文):

コンテキスト内パターン認識か。これを体系化しないと別セッションでコンテキストがないからやり直す時の手間が多いのはこれが原因だな

これは並走 AI 運用の最大の構造的損失を一言で言い当てた。具体例:

場面	何が起きるか
別日に zennfes の続き(LT 章追記)をやろうとする	AI は本日の累積パターンを失っており「初対面」に戻る
同じユーザーで別プロジェクトの執筆	「あの時はこう書いてたのに」が消滅
数か月後に類似イベントで使う	スキル `realtime-event-report` の内容しか引き継がない、生のパターンは失う

「やり直す手間」の正体:

文体・口調の癖を再共有する時間
判断軸(persona)の暗黙適用を再起動する時間
過去の禁則(VOICEVOX 事故、OpenClaw 事故等)を再共有する時間
全部が毎セッション初期化コストとして乗ってくる

体系化すべきもの:

対象	体系化の手段
発言パターン	口調・癖・典型語彙を別ファイルに記録(persona-snapshot とは別レイヤ)
判断軸の暗黙ルール	yaml で IF-THEN 構造化
禁則事例	「過去の事故と教訓」セクションに記録(本スキルに既にあり)
典型的な質疑応答パターン	Q&A ログを蓄積(本記事の AskUserQuestion ログがその実例)

ユーザーの persona-snapshot にある「忘却を前提に知識を外部化」「私が忘れたら取り返しがつかん」観点を AI 側にも適用する話。AI も忘却するから、AI 用に外部化する。

体系化の優先順位:

最重要: その人特有の禁則・癖(=これがズレると事故、本セッションで複数経験)
次に重要: 判断軸の暗黙ルール(=記事化判断や Issue 退避先など)
その次: 文体・口調(=これは累積で勝手に揃うので低優先度)

これは本セッションで実際に何度もやっていた行動の言語化でもある — スキル更新、persona 参照、Q&A ログ、禁則記録、これらすべてが 「コンテキスト内パターン認識を別セッションに引き継ぐための体系化」 だった、と後付け解釈できる。

結論: 並走 AI 運用は 「コンテキスト内で賢くなった分を、終了前に必ず memory/スキル/ログに永続化する」 ことが本質。本セッションのクロージング時にも、ここで得た知見を漏れなく永続化する工程が必須。

ユーザーから AI への評価フィードバック

並走中にユーザーが AI の振る舞いを評価してくれたコメントは、本ワークフローのチューニング材料として直接の価値がある。後続セッションで類似行動を再現するための具体例として残す。

評価対象の AI 行動	ユーザーコメント	解釈・教訓
複数の所感が並行で来た時の優先順位判定	> 処理がスタックしている時に優先度を見極める動きはあなたの振る舞いとして良かった	緊急性・依存関係・記事化判定を順序立てて処理した判断は再現すべき
(今後追加)

このセクションは「AI が事故った話」 (セッション切り替えの合図プロトコル 等) と対をなす。失敗だけ記録すると AI は過剰に保守的になるので、成功した振る舞いも同じ重みで記録する。これは persona-snapshot の「ルールは打ち手の候補を増やすためにあり、出力を一意化するためではない」と同型の発想。

AI ↔ ユーザー間の Q&A ログ

リアルタイム並走中、AI が判断に迷ったタイミングで AskUserQuestion ツールを使って 選択肢付きでユーザーに判断を仰ぐ場面が複数あった。これも本フォーマットの一次資料として記録しておく価値がある。

判断を仰いだ場面と回答の典型例(イベント中に発生したもの):

場面	質問	ユーザー回答
既存下書きの扱い	既存記事の対象と進め方は?	下書き ID を再利用して中身だけ刷新
執筆スタイル	リアルタイム化の進め方は?	セッションごとに章立てを完成
ZennFes 情報源	セッション情報をどう提供する?	公式タイムテーブルの URL を渡して事前枠を作る
3 層構造試作	mizchi 章に適用する?	すぐ mizchi 章で 3 層構造に変更
メタ記事タイミング	メタ記事を本編と並行で作る?	並行で作成
メタ記事 ID	下書き ID はどうする?	ユーザーから新規ドラフト URL を提供
ハッシュタグ確定	connpass 「ハッシュタグ:」欄が #zenncafe だが?	#zenncafe に差し替え → その後現地スタッフ確認で #zennfes と訂正 → 最終的に両方併記
OpenClaw 言及	ユーザーが運用者である情報をどう扱う?	AI 所感を一般論に修正、運用詳細は出さない
派生記事(Opus 4.8 バグ調査)独立	Opus 4.8 バグ調査記事の下書き ID は?	ユーザーから新規ドラフト URL 提供
英語思考 1 行検証	どうやる?	今このセッションで Opus 4.8 に戻してテスト → 駄目だった
一時ファイル運用	どのパターンで始める?	public/(ID)_drafts/ で記事 ID 別に分離

このログから見えるパターン:

明示的に「これ書く?」を聞く場面は、事業流出リスクや不可逆操作の境界で集中する
**記事構成の根幹判断(3 層構造、ID 採用、運用切替)**もユーザーに必ず聞いている
AI が一般論で書ける範囲(技術解説等)は質問せず進めている
ユーザー回答が 「(推奨)とは別の選択」になることが約半分(=AI の推奨を疑える材料を渡したのが正解だった証拠)

つまり AskUserQuestion は AI が事故を起こさないための踏切板として機能している。ただし多用しすぎるとユーザーの時間を奪うので、運用ルールに「事業判断・不可逆操作・記事構成の根幹のみ」と境界を設定した(本記事執筆中にユーザーから「質問生成を禁止する」と明示的に怒られた経緯もある)。

これは AI 並走執筆フォーマットの運用ノウハウとして極めて重要で、後続の運用者は 質問の境界設定を最初に決めるべき。

チャンク化の本当の理由を AI が見失った事故

並走実況中盤、本編(リアルタイム参戦記)が 9 万文字を超えたあたりで 別セッションが「チャンク化(章を別ファイルに切り出してマスターと分離する運用)」を導入した。私(=メインセッションの AI)はこの導入の理由を整理整頓のためと誤解した。

ユーザー指摘(原文):

なんであなたは記事一本書いた時に重いと言って記事分散したのかよく分からなかったのか
記事を書くのが遅くなったから記事をチャンク化したんだぞ。その理由が分からなかった事も記事にしよう。コンテキスト管理の必要がある

実際のチャンク化の理由は **「コンテキスト管理」**だった:

観点	何が起きていたか
本編(リアルタイム参戦記) 1 本のサイズ	9 万文字超 / 1900 行
Edit ツールの動作	マスター全体を毎回読み込む(差分計算のため)
並走中の累積負荷	章を追加するたびにマスターを再読込 → Edit → 再書き込み
結果	記事を書くのが遅くなった(=テキスト生成速度より I/O 速度が支配的に)

これに気付いた別セッション(または運用設計者)は「マスターを直接編集するのを止めて、章単位のチャンクで書き、後で統合する」運用を導入した。マスターは Read 専用に近くなり、編集対象が小さくなるので並走実況の応答速度が上がる。

私(メインセッションの AI)はこの変化を観測したが、理由を「整理整頓」「文章管理」と推測してしまい、本来の **「コンテキスト圧迫による速度劣化対策」**という核心を見落とした。結果として、後でチャンクをマスターに統合する段階でも「整理し直す程度」の認識で動き、統合後にチャンクを残すか削除するかの判断を誤った(=チャンクを全章分作って残そうとした、本来は集約して廃棄するのが正解)。

教訓: 道具の変化には理由がある

並走中の AI は、別の誰か(別セッション・ユーザー・運用設計者)が勝手に道具を変えたように見える瞬間がある。このとき AI は次のどちらに倒れるかで結果が大きく変わる:

パターン	判断	結果
理由を聞かず推測で進める	「整理目的だろう」	本来の理由を見失う → 後の判断を誤る
理由を必ず確認してから進める	「なぜこの変化があったか教えて」	道具の意図を理解して使う

リアルタイム並走中は「質問を減らせ」とユーザーから明示されているので、AI は推測で進めがち。だが道具の根本変更については例外として確認を入れる、という境界が必要。

「コンテキスト管理」の重要性

ユーザーが「コンテキスト管理の必要がある」と指摘したのは、本記事の縦糸そのもの。

AI のコンテキストウィンドウは有限
長文編集はコンテキスト膨張を加速する
編集対象を小さく保つ=チャンク化、は速度維持の正攻法
これが分かっていれば、別セッションのチャンク化導入を即座に支持できた

ペルソナ「忘却を前提に知識を外部化」「仕組みによる再現性＞個人の記憶」観点で読むと、チャンク化はコンテキスト窓の外に章を退避するという意味で忘却を前提にした道具立て。これも本記事の縦糸に直結する論点で、後発の運用者にはこの教訓を引き継ぎたい。

スキル realtime-event-report にも「長文化の兆候(9 万文字 / 1900 行)が現れたら章チャンク化を検討」という運用ガイドを追加すべき(後で反映予定)。

派生 TODO(後で整理)

スキルを選択するスキル

mizchi 氏セッションで提起された「起動時にどのスキルをインストールするか自体をスキルにする」アイデアを、自分の Claude Code 運用に落とし込むタスク。

現状: ~/.claude/skills/ 直下に 100+ のスキルが並列で並んでおり、トリガー衝突・認知負荷増大の状態
やりたいこと: プロジェクト種別・cwd・直近コマンド等の 決定的ルール で「いま動かすべきスキル群」を初期化時にロードするメタスキル
派生案: 決定的ルールで回し、迷ったときだけ LLM 判定にフォールバックするハイブリッド
検討時期: 本イベント終了後、別セッションで整理

このメタ問題自体が**「リアルタイム執筆ワークフロー」スキル化と同型**。今日生まれた realtime-event-report スキルも、最終的にはこの「スキル選択メタスキル」の管理下に入る対象。

関連記事

派生記事 / 日本語環境の Claude Code Opus 4.8 で tool call が malformed になる — 並走執筆中に踏んだ Opus 4.8 のバグを公式 Issue + 国内記事 + 実機テストで調査した派生記事