【こんな人に読んでほしい！】
- AIエージェントを「育てる」ってどういうことか気になっている人
- SWELLのブロック機能をもっと活かしたいと思っている人
- 自分らしいブログデザインって何だろう、と考えたことがある人
Claude Codeの記事作成ワークフローにデザイン担当を加えて、育てていく話で、こんなことを書きました。
「仕組みは、使いながら育てていくもの。」
Claude Codeを使って、デザインエージェントをワークフローに加えた回です。
記事の下書きに対して、どのブロックをどこに使うかを提案してもらう役割を持たせました。
そのときデザインエージェントが提案できるブロックは、STEPブロック・ポイントボックス・引用ブロック・「こんな人に読んでほしい！」ボックスの4種類。
記事の文章を渡すと、「ここはSTEPブロックにしましょう」「この箇所はポイントボックスが合います」と提案を返してくれました。
でも、ふと興味が出てきました。
デザインエージェントに、もっと知識を学習させたら、提案の幅や精度はどう変わるんだろう？
「学習させると、何が変わるんだろう。」
知識を入れれば、提案の幅が広がるのか。
SWELL公式の情報を読み込ませたら、どんな変化が出るのか。
好きなブログの情報を学ばせたら、また違う変化があるのか。
この記事は、その問いに答えるために実験した記録です。
結果は、想定通りの部分と、想定外の部分がありました。
そして実験を通じて、「育てる」ということの意味が、自分の中で変わりました。
比較実験：デザインエージェントに、SWELL・参考ブログの知識を学ばせた時の提案変化
(1) 実験の目的
デザインエージェントに知識を学習させると、ブロック提案の幅や精度はどう変わるのか。
その変化を確かめることが、今回の実験の目的です。
(2) 実験の条件
比較は3段階で行いました。
- 現状のデザインエージェント：Claude Codeの記事作成ワークフローにデザイン担当を加えて、育てていく話時点のdesign_agent.md（元の状態）
- Case1（SWELL機能の知識を追加）：SWELL公式の機能紹介記事を15本読み込ませた後
- Case2（参考ブログの情報も追加）：さらにSWELLテーマで参考にしたいデザインブログの記事を読み込ませた後
テスト素材には、SEO初心者がClaudeに聞いたら、まず土台から整えろと言われた話の下書きを使いました。
「SEOの土台を整えた話」です。
STEP形式の手順、Claudeとの会話の引用、つまずきの記録、まとめのリスト——ブロックの使いどころが問われる要素が一通り揃っていました。
ひとつ工夫したのは、下書きからブロック指定の文言を除いて渡したことです。
【POINT】とか【こんな人に読んでほしい！】といった指示を外した状態で渡すことで、エージェント自身の「判断力」が測れると思ったからです。
(3) 結果
Case1 SWELL公式の機能情報を読み込ませた
まず、SWELL公式サイト（swell-theme.com）の機能紹介カテゴリーを調べました。
全50本の記事URLを抽出して、デザイン診断に関係する15本を選んで読み込みました。
読み込んだのは、こんな内容の記事です。
- STEPブロックの使い方
- ボックス装飾の種類一覧（9種類）
- ふきだしブロックの使い方
- カラムブロック・テキスト装飾・リスト装飾
読み込んだ内容は、「どの場面にどのブロックが向いているか」という使い分けの知識に変換して、design_agent.mdに追記しました。
現状のデザインエージェント → Case1（SWELL機能の知識を追加） で何が変わったか
変化は、はっきりしていました。
| 観点 | 現状のデザインエージェント | Case1（SWELL機能の知識を追加） |
|---|---|---|
| 提案できるブロックの種類 | 4種 | 8種 |
| STEPブロックの提案 | 「使ってください」のみ | スタイル（ビッグ/スモール）まで指定 |
| ふきだしブロック | 提案なし | Claudeの発言に適用を提案 |
| Badボックス | 提案なし | つまずき箇所に提案 |
| メモボックス | 提案なし | 用語説明3箇所に統一して提案 |
ひとことで言うと、引き出しが増えたという感覚でした。
特に印象的だったのは、ふきだしブロックの提案です。
現状のエージェントでは、Claudeの発言には「引用ブロック」を提案していました。
Case1では、こんな理由つきでふきだしブロックを提案してきました。
「このブログはAIとのやり取りが軸なので、ふきだし形式の方がブログの世界観に合います」
知識を入れると、その分だけ選択肢が広がる。
最初の実験で、それははっきり確認できました。
Case2 Case1＋参考デザインブログの記事を読み込ませた
次に、SWELLテーマで参考にしているデザインブログのデザインカテゴリーを読み込ませました。
デザインカテゴリーには30本ほどの記事がありました。
その中から、デザインの考え方・判断基準・哲学が読み取れる5本を選んで読み込みました。
引き算の考え方・デザインの優先順位・読者への見せ方——そういった考え方です。
Case1（SWELL機能の知識を追加） → Case2（参考ブログの情報も追加） で何が変わったか
ここからが、想定外でした。
Case1との比較表を作ると、こうなります。
| 観点 | Case1（SWELL機能の知識を追加） | Case2（参考ブログの情報も追加） |
|---|---|---|
| 提案ブロックの種類 | 9種 | 9種（変わらず） |
| 提案の数 | 11箇所 | 10箇所（むしろ減った） |
| 優先度の整理 | なし | 高・中・低で分類 |
| 見出し構成チェック | なし | H2/H3の階層を確認して報告 |
| 「提案しすぎない」判断 | なし | あり |
ブロックの種類は変わっていません。
でも、提案の「質」が変わりました。
一番驚いたのは、「提案しすぎない」という判断が生まれたことです。
知識が増えれば提案も増えるはずです。
なのに、逆に提案を絞るようになった。
出力を見ると、こんなことが書いてありました。
「今すぐWordPressのブロック操作でできることを優先する。
CSSやJavaScriptが必要なカスタマイズは『将来的な検討項目』として分けて提案する。」
「今の運営フェーズに合った提案をする」という判断が、自然に生まれていました。
参考にしているデザインブログの設計思想が、そのまま反映されていました。
(4) 考察・結論
実験を通して、気づいたことと、改めて考えさせられたことがありました。
提案の幅について
Case1で引き出しは確実に広がりました。
ブロックの提案できる種類が4種から8種に倍増し、STEPブロックはスタイルの指定まで対応。
ふきだしブロック・Badボックス・メモボックスといった新しい提案も生まれました。
知識を入れると、その分だけ選択肢が広がる。
これは想定通りでした。
提案の精度について
提案の幅が広がることと、精度が上がることは、別のことでした。
Case1の段階では、提案の種類は増えたものの、優先度の整理や見出し構成のチェックはありませんでした。
提案の数も11箇所と、引き出しにある手段をそのまま並べている状態でした。
Case2では、ブロックの種類は変わらず、むしろ提案を絞るようになりました。
優先度が高・中・低で整理され、見出し構成のチェックも加わりました。
「今の運営フェーズに合った提案をする」という判断が、自然に生まれていました。
精度は上がった。でも、それは借り物の判断基準による精度でした。
借り物の判断基準で記事を作っても、自分らしいブログにはならない。
それに気づいたとき、少し考えさせられました。
AIが発達して、知識を効率よく取り込んだり、技術を適切に適用したりすることは、どんどん簡単になっていく。
デザインエージェントがそれを改めて示してくれました。
でも、「このブログらしさ」「アイビー（私）らしさ」は、知識の量では生まれません。
何を選んで、何を選ばなかったか。なぜそう感じたか。
その積み重ねの中にしか、オリジナリティは宿らないのかもしれない。
AIが育つほど、むしろ「その人自身の感性」の価値が際立ってくる。
そんなことを、この実験は教えてくれました。
そこから気づいたこと
「じゃあ、自分の判断基準って何だろう。」
今の私には、オリジナリティとなるべきデザインの判断基準が、まだ明確ではありません。
でも、ブログを始めてみて気づいたことがあります。
どうすれば読者にわかりやすく伝えられるか、デザイン的により良い表現ができるか——
その問いを持ちながら、Claude Codeと一緒に楽しく学んでいく。
それ自体が、判断基準を育てていくプロセスなんだと思っています。
次の一手：判断基準を育てる仕組みを作った
そこで、design_agent.mdに新しいセクションを追加しました。
名前は「アイビー（私）のデザイン判断基準を育てる」です。
仕組みはこうです。
診断の中で選択肢が複数あるとき、具体的な選択肢として並べてもらいます。
選んだら「なぜそれを選んだか」を一言だけ聞かれます。
言葉にした理由を、デザインエージェントが記録として蓄積していきます。
診断のたびに、自分のデザインに対しての選択・嗜好が積み重なっていく。
記事が増えていくたびに、その判断基準をデザインエージェントに学習してもらう。
それがこの仕組みのアイデアです。
やがて、アイビー（私）のブログらしいデザインの輪郭が見えてくるはずです。
これは、記事作成ワークフロー全体の考え方と同じです。
「使いながら育てる。記録しながら磨く。」
Claude Codeの記事作成ワークフローにデザイン担当を加えて、育てていく話で思い描いていたことを、一歩形にしてみました。
今日のまとめ・次回予告
今回やったこと：
- デザインエージェントにSWELL公式15本の知識を追加した
- さらにSWELLテーマで参考にしているデザインブログのデザイン記事を読み込ませた
- 現状のデザインエージェント・Case1・Case2の3段階で診断結果を比較した
- 「自分のデザイン判断基準を育てる」仕組みをdesign_agent.mdに追加した
実験を通じて、いちばん大切なことに気づきました。
知識を入れれば、引き出しは増える。でも、知識は借り物です。
「自分がどう感じるか」「このブログにとって何が合っているか」——それは、自分の中にしかない。
だから、選んで、言葉にして、積み重ねていく。
エージェントを育てているようで、実は自分の感覚を育てていく作業なのかもしれません。
次回は、ブログで手が止まらなくなった仕組みの話をします。”今日やること”を決めてくれる編集長AIを作った記録と、そのプロンプトをそのまま公開します。
よかったら読んでいただけたら嬉しいです。
