この記事の実施記録（2026年5〜6月）: Claude Code との対話セッション中に「いま起きていること自体が、書こうとしている記事の主張の証拠になっている」という構造（メタ実演構造）を3本の既存記事で確認した。本記事は4本目の実例として、本記事自身もメタ実演構造で書くことを試みている（当時のネタ帳の「特記」欄にも、ネタ帳育成の過程自体がメタ実演になっている旨を一度、記録している）。

Claude Codeとの対話から『メタ実演構造』に気づいた

Claude Code に記事を書かせていると、ときどきこういうことが起きる——いま話している内容が、そのまま今書こうとしている記事の実例になる。2026年5月14日、そんな瞬間に立ち会った。

シリーズ「Claude Code を思考のパートナーにする」の第3弾ネタ帳を育てている最中、COO（オーケストレーター役のエージェント）が「他にも切り口がありそうですよ」と7つの候補を表で並べてくれた。それを見て、私はこう返した。

[ユーザー発言]「壁打ち、鏡、ブレストと、ブレストが3つ目にならない？」

この一言で、書きかけだったシリーズの構造が確定した。第1弾「壁打ち」、第2弾「鏡」、そして第3弾は「ブレスト」——3部作として並べた瞬間、それぞれの役割の違いが立ち上がった。

注目してほしいのはここだ。この発言自体が、第3弾で書こうとしていた記事の主張そのものを実演していた。第3弾の主張は「AIブレストは漠然問いから始まり、選択肢を並べてもらうことで構造が立ち上がる」というもの。私がやったのは、まさにその通りのことだった。「他に切り口あるかな？」という漠然問いを投げ、Claude Code が提示した候補を眺めながら「あ、3つ目だ」と構造を掴んだ。

このとき気づいた。「記事の主張を、記事を書いている対話そのもので実演してしまう」という現象が、私の執筆プロセスの中で繰り返し起きている、と。

本記事の主題はこれだ。私はこの現象をメタ実演構造と呼んでいる（公式用語ではなく、私が個人的に使っている呼称）。

メタ実演構造とは何か——記事の説得力を上げる書き方

通常のブログ記事と、メタ実演構造を持つ記事の違いを整理する。

観点	通常構造	メタ実演構造
説得の流れ	主張 → 例 → 信じてもらう	起きた事件 → 構造化 → 主張の証明完了
説得力の根拠	著者の論理	記事内で実際に起きたこと
読者の体験	理論を理解する	現場を目撃する
再現性の伝え方	「あなたもできる」と著者が説明する	読者が「自分でもできそう」と自然に感じる

通常の構造は「主張」を先に置き、「例」で補強する。読者は理論を学び、自分で試すかどうか判断する。

メタ実演構造はこれを反転させる。記事自身が、主張の証拠になっている。冒頭で「現場で何が起きたか」を見せ、そのあとで「いま見せたものが、これから語る主張の実例です」と種明かしする。読者は理論を読む前に、その理論が動いている現場を目撃した状態になる。

技術的な要点はひとつだけだ——「いま自分がやっていること」と「記事で主張しようとしていること」が同じ文で説明できる状態を見つけ、それを冒頭引用に使う。

既存記事3本での実例

抽象論ではなく、過去に書いた3本の記事で実際に起きた事例で示す。読みながら、自分が最近書いた記事の執筆メモや対話ログにも、似た瞬間がなかったか思い出してみてほしい。

実例1: 第3弾「AIブレストのパートナー」記事

何が起きたか: 冒頭で紹介した「ブレストが3つ目にならない？」発言が、そのまま記事の主張を実演する素材になった。記事の主張は「漠然問いに対してAIが選択肢を並べると、人間側で構造が立ち上がる」。記事冒頭でこの発言の前後を再現することで、読者は「あ、これがブレストってことか」を読みながら追体験できる。

どう記事に活かしたか: 記事冒頭で対話ログを引用 →「いま見せたやり取りが本記事で扱う『AIブレスト』そのものです」と種明かし → 本論で「漠然問い」「選択肢提示」「構造化」の3工程を解説、という流れに組んだ。読者が主張を読むときには、すでにその主張が動いた現場を見ている。

該当記事: Claude Codeとのブレストは『漠然問い』から始まる——選択肢を並べると構造化が起きる

実例2: 第1弾「対話アーカイブ設計」記事

何が起きたか: 「Claude Code との対話を保存しておけば後で記事素材として引ける」という主張で書いた記事だ。設計議論を進めて .gitignore の修正で実装完了した直後、こんなやり取りがあった。

[COO発言]「動作確認として『保存して』と発言いただければ、本セッションの直近対話塊からテストできます。今回の対話アーカイブ設計議論そのものを最初の保存対象にすると POC スタートになります。」

[ユーザー発言]「この対話を保存して」

対話アーカイブシステムの設計議論が、そのシステムで保存された最初の記録になった。

どう記事に活かしたか: 記事の締めをこのエピソードに充てた。「設計が稼働した瞬間の記録が、設計そのものの記録になった」というメタな結びによって、システムの価値（=保存したものが後で価値を持つ）を、記事内で完結する形で示せた。記事を読み終わった読者は「なるほど、確かに保存しておけば後で引ける」を体験として理解する。

該当記事: Claude Codeの記事が薄くなる理由——AIエージェントに設計議論が届いていなかった

実例3: 「型に飽和した」記事

何が起きたか: 雑談でClaudeに「最近、新しいネタがあんまり拾えなくなってきた」と漏らしたところ、「事象が枯れているのではなく、書き方の型が固まってしまっているのではないか？」と問い返された。確かめるためにリサーチ担当エージェントに直近1ヶ月・21本のはてな記事を分析させると、導入・主張・結論の型が偏って飽和していることが判明した。

問題はここからだ。この診断結果をどう記事にするかを考えたとき、いつもの「失敗→構造化→教訓」の型で書けば、まさに今回診断した飽和型に自分から着地することになる。そこで、21本中ゼロだった「成功から入って、違和感で終わる」という型をあえて選んで書いた。

どう記事に活かしたか: 診断結果をそのまま実験台にした。「型の飽和」というテーマを、いつもの型を避けて書くことで自己言及的に実演した。一方で、診断そのものは「数字を出して構造化する」という飽和した型を使っており、著者自身も記事内で「私は飽和した型でしか、自分の飽和を語る方法を持っていない」とその矛盾を明記している。読者は記事を読み進めながら、著者が自分の分析方法の限界に自覚的であることに気づく。

該当記事: 組織が完璧に回り始めた日に、書くことがなくなった

3本に共通しているのは、メタ実演を狙って設計したわけではないということだ。執筆プロセスの中で「あ、いまこれそのものをやっている」と気づき、その気づきを記事構造に組み込んだ。だからセンスや構成力の話に見える。

ここで多くの人がブレーキを踏む——「気づける人が元々持っている才能でしょ」と。

「自分には無理では？」への答え——メタ実演構造は3段階で後天的に習得できる

この疑問への答えは「センスではなく、3段階で後天的に身につく」だ。

段階	何が起きるか	役割分担
1. 数本書いた後	Claude Code が「この対話自体が実演になっていますね」と指摘してくれる	検出はAI
2. パターンが見えてきたら	セッション終わりに「あ、これそうだったかも」と後から気づく	検出は人間（事後）
3. 習慣化してから	リアルタイムで気づく	検出は人間（同時）

最初の段階で必要なのは、自分で気づく能力ではなく、Claude Code に気づかせる材料を貯める習慣だ。

具体的に何が起きたかを書く。メタ実演が偶発的に起きていた記事を3本書いたあと、第4本目（=本記事）のネタ帳を育てている過程で、Claude Code から「このネタ帳育成のやり取り自体も、メタ実演構造の実例になっていますね」という趣旨の指摘を一度受けた。当時のネタ帳の「特記」欄にも、この気づきをそのまま記録している。特定のタイミングを狙って依頼したわけではない。過去のセッション履歴やネタ帳を参照できる状態にしておくと、こうした指摘が返ってくることがある——これが私の実感だ。

特殊な機能を使っているわけではない。会話履歴と過去の成果物（ネタ帳・記事・対話アーカイブ）を Claude Code が参照できる状態にしておくと、こうした検出が起きやすくなる、というのが私の運用経験からの実感だ。私側にセンスがあったわけではなく、検出するための材料を蓄積し続けたことが起点になっている、という順序だ。

「参照できる状態」とは、ネタ帳ファイルや対話アーカイブを同じリポジトリ内に置き、Claude Code のセッションで読み込める場所に保存しておくことだ。特別なツールは不要で、テキストファイルが同じディレクトリにあれば Claude Code は自動的に参照する。

最小3ステップ

センスがなくても今日から始められる手順:

普通に1本書く。メタ実演を意識せず、いつも通り書く
書き終わったあとに1行だけ問う——「この記事の執筆過程、テーマを実演していなかった？」と Claude Code に聞く
「実演していました」と返ってきたら、該当する対話ログを次の記事の冒頭引用に使う

最初の2〜3本は何も検出されないかもしれない。それでもいい。検出材料（過去ログ・ネタ帳）が蓄積されることが重要で、ある時点から急に検出されるようになる。私の場合は3本目あたりからだった。月1〜2本のペースでも進め方は変わらない。1本書き終えるたびに1行問うだけなので、頻度が低くても負担は増えず、蓄積が進むタイミングが後ろにずれるだけだ。

メタ実演は「気づく人だけが気づける現象」ではなく、「材料を貯めた人が後から気づける現象」だ。順序が逆なだけで、誰でも入れる。

シリーズ「対話を記事に変える技術」全2弾——第1弾「対話アーカイブ」と第2弾「メタ実演構造」

本記事は「対話を記事に変える技術」という2部作の第2弾だ。第1弾では、対話ログを保存する仕組み（対話アーカイブ）を作った。

第1弾: Claude Codeの記事が薄くなる理由——AIエージェントに設計議論が届いていなかった — 対話を素材として保存する仕組みを作った話
第2弾: 本記事 — 保存した素材を記事構造に取り込む方法

第1弾で「対話アーカイブ」という保存箱を作り、第2弾で「メタ実演」という取り出し方を示した。第1弾の締めには「この対話自体も、後の記事で『メタ実演構造』の実例として引用されることになる」と書いてある。実際そうなった——本記事の実例2がそれだ。第1弾が予告したことが、第2弾で実演されている。

ここまで書いて、ひとつ気になっていることがある。本記事は「メタ実演構造で書かれた記事についての記事」だ。読者がこれを読んで自分のブログでメタ実演を試したとき、その執筆過程は何の実演になるのだろう。

答えはまだ分からない。ただ、今日からできることははっきりしている。次に1本書き終えたら、Claude Code に「この記事の執筆過程、テーマを実演していなかった？」と1行だけ聞いてみてほしい。何も返ってこなくてもいい。その1行を習慣にすることが、検出材料を貯める最初の一歩になる。

対話ログをメタ実演の材料として使い始めると、次の問いが出てくる——そもそも対話ログを記事の素材として保存・活用する仕組み全体を、自分の運用にどう組み込めばいいか。

その設計と自動化の全体像は『コードを書けない私がClaude Codeで「AIチーム」と書き続けるまで（Vol.3）』にまとめてある。序章は無料で読める。

コードを書けない私がClaude Codeで「AIチーム」と書き続けるまで（Vol.3）　序章無料

この記事ははてなブログからのクロスポストです。