この記事の実施記録（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） 序章無料
この記事は はてなブログ からのクロスポストです。