- なぜAIに書かせると記事が薄くなるのか
- 「書き方」より「素材へのアクセス」が問題だった
- 3案を比較して、ユーザーが10秒で選んだ
- 設計の詰め——保存範囲と保存先
- architectへの委任で設計書を起票
- COO直接で5ファイル実装
- .gitignoreというブロック障害
- .gitignoreの例外設定で解決
- 設計議論そのものが最初の保存対象になった
- この記事のテーマを深掘りした本
この記事の実施記録（2026年5月6日）: Claude Codeのエージェント組織で「記事が薄い」問題の原因を特定し、対話アーカイブシステムを設計から実装まで1セッションで構築した。COOが直接実装したファイルは5本。スクリプトなし。外部ツール不要。
なぜAIに書かせると記事が薄くなるのか
AIに記事を書かせてみたが、なんとなく薄い——この感触を持ったことがある人は少なくないはずだ。
プロンプトを工夫する。レビューのループを増やす。それでも改善しない。
私もその一人だった。Claude Codeでエージェント組織を組み、Writerエージェントに記事を任せていた。出来上がるものは正確で、構造は整っている。ただ、読んでいて「生きていない」。言い回しが教科書的で、対話の中で生まれたはずの葛藤や判断の迷いが消えている。
あるセッションで、私はその原因を言語化した。
「別の話題だけれど、Writerが執筆するときに、私やCOOの実際の過去の発言が参照できていない。このことで記事の厚みがでないので、何とかしたい。」
問題は書き方ではなく、素材の構造にあった。
「書き方」より「素材へのアクセス」が問題だった
Writerエージェントが参照できるのは content/writing/netacho/（ネタ帳）だけだ。設計議論で交わした発言、ユーザーが瞬時に下した判断、「なぜこの選択をしたか」の根拠——これらはネタ帳に転写されない限り消える。
対話ログはセッションが終わると失われる。Writerは存在しない素材から「生々しい記事」を書くことができない。当然だ。
つまり解決策は「もっとうまく書かせること」ではなく、対話の生発言をWriterが参照できる場所に保存することだ。
この気づきから、設計を詰めることにした。
3案を比較して、ユーザーが10秒で選んだ
アプローチは主に3つ考えられた。
- 入口で拾う案: ネタ採掘時に対話の生引用ブロックをネタ帳に必ず転載する（運用ルール強化）
- 物理保存案: セッションの発言を構造化して保存し、Writerがgrepできる引用素材データベースを作る
- 執筆時参照案: Writerプロンプトに「対話引用を最低N件含める」を必須化する
私は2案を選んだ。
「２，私が保存してといったときだけでいい」
この一言が設計の方向を決めた。自動保存ではなくユーザートリガー型——「私が必要と思った対話だけ保存する」という制約が、システムをシンプルに保つ根拠になった。
「大掛かりなシステムを作る気になれない」と思った読者もいるかもしれない。この判断がある限り、不要な自動化は入らない。
設計の詰め——保存範囲と保存先
次に2つの設計判断が必要だった。
保存範囲の選択肢: - (a) 直前のユーザー発言1つだけ - (b) 直近の話題塊（文脈判断でターン群を拾う） - (c) 範囲指定型（都度指示）
保存先・単位の選択肢:
- (a) 日付単位ファイル: knowledge/dialogue/2026-05-06.md
- (b) テーマ単位ファイル: knowledge/dialogue/<slug>.md
- (c) ネタ帳に直接素材引用として混ぜる
COOの推奨は「話題塊×テーマ単位ファイル」だった。理由はシンプルで、Writerが「あの話どこだっけ」と探すとき、テーマで束ねてあるほうがgrepで引きやすい。
「推奨通り」
ユーザーの承認はこの3文字だった。
architectへの委任で設計書を起票
設計の方向が固まったので、architectエージェントに設計書の作成を委任した。
出来上がった ops/playbooks/dialogue-archive.md の要点はこうだ:
- 保存先:
knowledge/dialogue/<slug>.md（独立ディレクトリを新設） - トリガーパターン: 「保存して」「対話保存して」「これ保存して」「アーカイブして」「この会話保存しておいて」
- slug決定: COO提案→ユーザー承認
- 追記運用: 同テーマは
## YYYY-MM-DDセクションで末尾追加 - 発話形式:
User:/COO:を使い、要約せず発話そのまま写す
要約せずそのまま写す——ここが肝心だ。要約すると「生の言葉」が失われる。引用は一字一句の精度が素材の価値を決める。
COO直接で5ファイル実装
設計書が完成した後、実装をどう進めるかという判断があった。
「5も COOで」
skilldevへの委任ではなく、COOが直接実装する。実際に作成・変更したのは5ファイルだ。
knowledge/dialogue/README.md（ディレクトリ説明・grep例）ops/playbooks/INDEX.md（ネタ採掘セクションへの1行追加）ops/playbooks/coo-trigger-list.md（対話アーカイブセクション追加）.claude/agents/writer.md（担当業務・参照Playbook追記）ops/playbooks/dialogue-archive.md（architectが作成したPlaybook本体）
スクリプトはない。既存のファイル構造に5箇所書き加えるだけだ。「自分にはこんなシステムは作れない」という懸念があるとすれば、この事実が反論になる。architectエージェントがいない環境でも、この5ファイルはCOO（またはあなた自身）が直接実装できる。
.gitignoreというブロック障害
実装後にgit statusを確認したところ、問題が浮上した。/knowledge/ が .gitignore でブロックされていた。
Zettelkasten系のノートをローカル運用にするための設計だったが、対話アーカイブまで除外されてしまっていた。つまりこのままでは、保存した対話ログがgitの管理外になり、消失リスクが残る。
選択肢は2つ。
- A:
knowledge/dialogue/をgitignoreの例外にする - B: 現状維持（ローカル運用のまま）
COOの推奨はA。理由は「対話の歴史的記録として価値が時間とともに増す性質があり、消失リスクを避けたい」から。
「A」
.gitignoreの例外設定で解決
技術的な変更は小さかった。
.gitignore の記述を /knowledge/ から /knowledge/* に変え、!/knowledge/dialogue/ を追加する。これで inbox-evernote などの既存ignoreは維持しつつ、dialogue/ だけをgit管理下に置ける。
この2行の変更が設計の思想を体現している——対話は消えてはいけない、という選択だ。
設計議論そのものが最初の保存対象になった
実装が完了したところで、COOが動作確認を提案した。
「動作確認として『保存して』と発言いただければ、本セッションの直近対話塊からテストできます。今回の対話アーカイブ設計議論そのものを最初の保存対象にすると POC スタートになります。」
私はそのまま言った。
「この対話を保存して」
slug dialogue-archive-design で承認し、knowledge/dialogue/dialogue-archive-design.md に保存された。
対話アーカイブシステムの設計議論が、そのシステムで保存された最初の記録になった。設計が稼働した瞬間の記録が、設計の記録そのものだというメタな構造——これは計算したわけではなく、自然にそうなった。
そして、これで話は終わらない。
このシステムが本当に機能したかどうかは、「保存した素材が実際に記事で使われたか」で測るしかない。はてなで公開した記事「"候補を上げて"の一言から50分で12スキル完成——Claude Codeが自ら設計・実装・pushした実録」の本文には、対話アーカイブを出典として明記した箇所がある。保存したから引けた、引けたから記事に使えた——というサイクルが実際に回った。
この対話自体も、後の記事で「メタ実演構造」の実例として引用されることになる。保存したから引けた——この記事を書きながらそれを実感している。素材の価値は、保存した瞬間ではなく、引いた瞬間に生まれる。
対話アーカイブを設計・実装できるようになると、次の問いが出てくる——そもそも、architectエージェントやWriterエージェントをどう組み合わせた組織を作るのか、そしてCOOが直接実装してよいラインと委任すべきラインをどう判断しているのか。
私はその設計判断の背景を『AIチームを作るまで』にまとめた。エージェント組織の初期設計から役割分担の思想まで、序章と第1部は無料で読める。
AIチームを作るまで——Claude Codeでマルチエージェント組織を立ち上げた記録（序章・第1部無料）
この記事のテーマを深掘りした本
コードを書けない私がClaude Codeで「AIチーム」と書き続けるまで ネタの自動収集から公開まで、書き続ける仕組みの育て方（序章無料）
シリーズ全6冊: Vol.1 作るまで ／ Vol.2 回すまで ／ Vol.3 書き続けるまで ／ Vol.4 仕組みを渡すまで ／ Vol.5 仕事を任せるまで ／ Vol.6 1人エージェントチーム
