Claude Code でエージェント型のコンテンツ制作システムを構築する

あるエンジニアが書いたこの記事では、彼のチームが Claude Code の .claude フォルダをどのように使っているかが説明されています。このフォルダは隠しディレクトリで、コンテキストファイル、振る舞いのルール、自動化されたワークフローを保存しておくことで、特定のプロジェクトで Claude がどう動けばよいかを理解できるようにするものです。彼はコーディング規約、ツールの設定、CI との連携を設定していました。実にエンジニアらしい発想です。ツールの名前が Claude Code なのですから、それも当然でしょう。

私が率いているのは Web とコンテンツのチームです。ブログ記事、チュートリアル、技術ガイドを書くのが仕事です。想定ユーザーではありません。

それでも、.claude フォルダのことが頭から離れませんでした。構造的に見ると、これはコンテンツ運用の課題を解決してくれるものだったからです。ボイス、プロセス、チーム体制、品質基準を、一度だけファイルに定義しておく。Claude は毎回のセッションの前にフォルダを読み込みます。前回伝えたことを覚えているのは、それを書き留めておいたからです。これはエンジニアリングの小技ではありません。組織の記憶です。どのコンテンツチームも持っているふりをしていて、実際には3人の頭の中と2022年の Google ドキュメントにしまい込んでいるものです。

そこで、私たちはこれを取り入れることにしました。この記事では、私たちが構築したもの、つまり Content Workflow Manager という共有の Claude Code プロジェクトを紹介します。メンバーは5人、コンテンツ機能は1つで、制作から公開、配信までを担います。このシステムはまだ初期段階なので、どこが未完成なのかも正直にお伝えします。では、フォルダの中身を見ていきましょう。

マーケティングチーム向けの .claude フォルダに入れるものは、エンジニアリングチーム向けと同じです。コンテキスト、ルール、ワークフローを、コードではなくコンテンツ制作に合わせて定義します。私たちのフォルダでは、ボイスとトーン、4段階のレビュープロセス、チーム内の振り分け、そして呼び出して使える6つのスキルワークフローを定義しています。Claude は毎回のセッションの前にこれを読み込みます。あとはシステムがやってくれます。

コンテンツチームの Claude Code システムでできること

Content Workflow Manager は、ブログ記事、チュートリアル、技術ガイド、Web サイトのコピー、ランディングページ、ニュースレターの制作サイクル全体を担っています。要件の整理、下書き、構造化されたレビュー、Contentful での公開準備、公開後の配信用コピーまでです。Linear での課題管理のワークフローも担っており、受信箱のトリアージ、スプリント計画、リーダー向けの週次サマリーを行います。

私たちのスタックは Claude Code、Cursor、Linear です。Claude Code はエージェントとして動くレイヤーで、.claude フォルダが置かれ、システムが実行される場所です。Cursor は、日々の作業に使いたいというメンバーがいるツールです。Linear は、チーム全体の作業をすべて把握するために私が使っているツールです。私たちが作成し、トリアージし、計画し、クローズするすべての課題が Linear を通るので、どのレーンに属する作業であっても、すべてを1か所で確認できます。

システムを使っているのは5人です。下書きを作成するコンテンツマネージャーが2人。公開前に必ず公開チェックリストを確認するプロダクションマネージャー。スタンドアップの進行とチーム間の調整を担う Web プロデューサー。そして、戦略とシステムそのものに関わることすべてを担当する私です。

作業は4つのレーンに分かれています。新しい SEO・GEO 記事には、要件定義から公開までの制作ワークフロー全体が適用されます。チュートリアルの更新は Linear のタスク概要をもとに進み、独自のペースで動いています。このレーンはまだ構築中です。システムのレーンでは、ワークフローマネージャー自体の改善を扱います。そして、それ以外のすべてを扱う汎用のレーンがあります。

最も興味深いものになったのは、この最後のレーンでした。チームのメンバーは誰でも Content Workflow Manager でセッションを開き、ブログ記事かどうかに関係なく、あらゆる種類のタスクに取り組めます。しかも、ボイスのルール、レビュープロセス、チーム内の振り分けなど、システムのコンテキスト全体が作業を始める前に読み込まれた状態で使えます。いわばコンテキストの泡です。その中に入れば、チームの働き方、誰が何を担当しているか、品質基準がどのようなものかを、Claude はすでに把握しています。これはブログ記事の下書きだけでなく、ステークホルダーへの報告を書くときや、プロジェクトの範囲を決めるときにも同じように役立ちます。

.claude フォルダの解説

各コンポーネントを順に紹介し、それぞれがなぜ存在するのかを説明します。この「なぜ」こそ、もっと多くの人に公開してほしいと私が思っている部分です。

CLAUDE.md

最も重要なファイルです。Claude は毎回のセッションの開始時にこのファイルを読み込みます。システムの目的、誰が何をするのか、4つのレーンがどのように機能するのか、どのナレッジファイルとスキルを読み込むのかを定義しています。このプロジェクトで Claude がどう振る舞うかについての、唯一の信頼できる情報源です。

システムに変更があれば、このファイルを更新します。CLAUDE.md に書かれていないことは、Claude にはわかりません。当たり前に聞こえますが、「なぜ新しいレビューステージのことを知らないんだろう」というセッションを何度か経験して、ようやく身にしみました。

.claude/agents/

ペルソナのファイルです。特定のタスクのために Claude がまとう振る舞いのプロファイルです。ある条件が満たされると（レビューステージが始まる、戦略のセッションが開かれるなど）、Claude は該当するファイルを読み込み、そのタスクの間はそのペルソナとして作業します。

ペルソナは7つあります。それぞれに、性格、偏り、仕事のスタイルが文書化されています。3つは制作ワークフローの外で働き、4つはレビューステージを順番に担当します。

The Architect は戦略アドバイザーです。前提を明らかにし、トレードオフを含めた選択肢を示し、解決策を提案する前に問題を整理します。私はキャンペーンの計画やシステムに関する意思決定に使っています。次に何をすべきか迷ったときに相談する相手で、それは人前で認めたくないくらい頻繁にあります。

The Librarian はリサーチ担当のエージェントです。競合分析、GEO のリサーチ、主張の検証を行います。中核となる制約は、認識に対する誠実さです。不確かなことは不確かだとはっきり述べ、推測で穴を埋めることは決してしません。検証できないことがあれば、そう伝えます。システムにあるどのルールよりも、この1つの制約が多くの問題を防いでいます。

The Mouthpiece は、言葉の調子に細心の注意が必要なコミュニケーションを担当します。ステークホルダーへの報告、経営層向けのブリーフィングなど、最初の一回でトーンを的確に伝えなければならないものです。一貫していて落ち着きのある、思いやりのある文体で書き、読み手が誰で、組織のどの立場にいるかに応じて丁寧さを調整します。これを作ったのは、VP への報告で適切なトーンを出すことと、事実を正しく伝えることは別の問題であり、前者に特化したペルソナがほしかったからです。

残りの4つは、レビューステージを担当します。書いたものすべてに同意するレビュープロセスはレビュープロセスとは言えないので、それぞれにあえて具体的な厳しさを持たせています。

The Corrector はステージ1を担当します。技術的な正確さとして、コードの正しさ、バージョン番号、存在しない製品機能（ハルシネーション）、出典のない主張をチェックします。私が書いた指示書には「すれた Hacker News 住人のノリ」とあります。疑わしきを好意的に解釈してくれることはありません。

Webcrawler はステージ2を担当します。SEO と GEO の最適化として、キーワード密度、答えを先に示す構成、内部リンク、AI による検索・取得のパターンをチェックします。検索で上位に表示されるコンテンツと、インターネット上にただ存在しているだけのコンテンツの違いを理解しています。

The Censor はステージ3です。ブランドボイスの徹底として、禁止フレーズ、AI が生成したような文章のパターン、能動態、インクルーシブな表現をチェックします。私たちが禁止したパターンのリストを管理しており、そのリストは増え続けています。最初の犠牲者は「急速に進化する今日の環境において」でした。それが最後ではありませんでした。

The Focus Group はステージ4を担当します。ターゲット読者の代わりとなり、その記事が実際に読者の行動につながるかどうかを評価します。スコアカードと具体的なフィードバックを出し、一般論は言いません。どの段落で読者が離れたのかを指摘できなければ、レビューは終わっていません。

.claude/rules/

セッションを通じて Claude がコンテキストとして読み込むナレッジファイルです。プロンプトではなく、参考資料です。新入社員が社内ドキュメントを参照するのと同じように、Claude はこれらを参照します。何かをでっち上げた後ではなく、行動する前にです。

ファイルは11個あります。すべてを紹介するつもりはありませんが、取り上げる価値のあるものからは、このシステムの考え方がわかります。

ブランドボイスのファイルでは、トーンの原則、禁止フレーズ、コンテンツの品質チェックリストを扱っています。チェックリストをここに置いているのは、誰かの頭の中にあると省略されてしまうからです。共有ドキュメントにあっても、少し丁寧に省略されるだけです。

レビュープロセスのファイルでは、4段階の順序、スコアカードの形式、合否の基準、変更提案のプロトコルを定義しています。このプロトコルは具体的です。レビュアーは変更を1つずつ提案し、変更前と変更後のテキストを示し、実施する前に確認を取ります。これを明文化したのは、「提案を箇条書きで残す」というやり方では、使える修正ではなくノイズしか生まれなかったからです。

クロスコンテンツ戦略のファイルは、私たちの内部リンクのフレームワークです。最初に言及したときに特定の URL へリンクしなければならない Tier 1 のキーワード、文脈に応じてリンクを検討する Tier 2 のキーワード、1,000語あたりのリンク密度のルールを定めています。こうした知識は、通常は1人の頭の中にあり、適用のされ方もまちまちです。参考資料として書き出しておくことで、Claude はいちいち言われなくても、毎回のセッションでそれを徹底します。

パイプラインのファイルでは、4つのレーンを、ステージの担当者と振り分けのロジックとあわせて定義しています。どの種類の作業を誰が担当するのか、どのレビュー階層が適用されるのか、課題が Linear のステータスをどう移っていくのか、です。これが存在するのは、振り分けが曖昧だと物事が抜け落ちていくからであり、5人のチームでは誰が何に責任を持っているのかを見失う余裕はありません。

CircleCI の原則のファイルには、会社の5つの指針と、マネージャーに求められる7つの行動を記録しています。The Architect は、戦略的な意思決定を評価する際に、これらをレビューの観点として使います。これは意図的な設計上の選択でした。会社の価値観は、たいてい壁に貼られているか、オンボーディング資料に載っているだけです。エージェントが助言をする前に実際に読み込む参考資料として組み込むことで、それが機能するものに変わります。

スケジュールのファイルでは、1週間の勤務日、週末の日付を防ぐガード、期限のルールを定義しています。これが存在するのは、私たちが土曜日を期限に設定し続けていたからです。些細なことに聞こえるのはわかっています。実際、些細なことでした。それでも、機械に止めさせるまでは毎週欠かさず起きていました。

.claude/skills/

スキルは、呼び出して使えるワークフローです。特定のフレーズで呼び出されたときに Claude が実行する、構造化されたプロンプトです。各スキルのフォルダには、モード、順序、振る舞いを定義した SKILL.md があります。

スキルは6つです。

seo-geo-post は、新しいコンテンツのための制作ワークフロー全体です。要件、アウトライン、下書き、4段階のレビュー、公開準備、配信用コピーまでを扱います。最も長く、最もよくテストされているスキルです。コンテキストを失うおそれのある長いセッションに備えて、再開用の構造化されたブロックを書き出すチェックポイントコマンドがあります。これを作ったのは、セッションのタイムアウトでレビュー1回分をまるごと失ってからです。そういうことは一度経験すれば十分です。

tutorial-update は、古くなった箇所のフラグと概要を付けた、範囲を絞った更新タスクを Linear に作成します。このスキルはコンテンツを作成しません。制作を始めるためのタスクを作成します。この違いが重要なのは、このスキルが作業のやり方だけでなく、作業についての考え方まで体系化しているということだからです。

publish-prep は Contentful 用のチェックリストです。CMS に入力する前に、メタデータの確認、内部リンクの検証、制作上の要件のチェックを行います。公開の前には毎回実行します。

promote は、公開後の配信用コピーを生成します。ニュースレターの紹介文、LinkedIn の投稿、短いソーシャル投稿です。記事が公開された後に呼び出します。

the-guild は運用の背骨です。もともとはコンテンツ作業のための課題管理レイヤーとして始まりましたが、それよりも大きなものになりました。受信箱のトリアージ、チームミーティング後のフォローアップ、計画、バックログのレビュー、完了処理、週次サマリーという6つのモードがあります。チームが作成し、処理し、計画し、クローズするすべての課題は、4つのレーンすべてにわたって、このスキルを通ります。汎用のレーンには他の制作スキルが紐付いていないため、すべて THE GUILD を通して進みます。チームの誰かがプロジェクトの範囲を決めたり、提案書を作成したり、部門をまたぐ取り組みを計画したりする必要があれば、セッションを開くだけで、THE GUILD が課題のライフサイクルを処理し、システムの残りの部分がコンテキストを提供します。

私のお気に入りは週次サマリーです。今は、前の週に完了した作業から、リーダー向けにそのまま使えるまとまった文章を1つ生成しています。将来的には、これを2つのモードに分けたいと考えています。1つは月曜日版で、何が準備できていて、何が期限を過ぎていて、何の範囲を決める必要があるのかを洗い出し、週次のバックログミーティングに向けてチームの準備を整えます。もう1つは金曜日版で、VP に送るレポートのために成果と進捗をまとめます。元になるデータは同じで、切り口と読み手が異なります。

この名前は『ディスクワールド』から取っています。アンク・モルポークでは、すべての職業にギルドがあります。錬金術師ギルド、盗賊ギルド、道化師ギルド（そこではピエロは笑いごとではありません）。それぞれが自分たちのことを自分たちで管理し、独自の基準を定めています。自治するシステムのための、自治組織です。コンテンツチームにはギルドが必要でした。だから作ったのです。

workflow-skill-check は環境の検証です。想定されるファイルがすべて揃っていること、Linear MCP の接続が有効であることを確認します。クローンした後や更新を取り込んだ後に実行します。地味なスキルですが、だからこそ、朝9時に何かが動かず原因もわからないときに、最もありがたみを感じるスキルになるはずです。

現在の状況

このシステムはまだ初期段階です。それが正直なところです。レビューのワークフローは安定していて、課題管理のレイヤーも必要なことをこなしています。スキルによって成熟度に差があり、チュートリアルのレーンはまだ調整中です。それでも中核の部分は機能していて、私たちは毎日使っています。

驚いたのは、このシステムがあっという間にコンテンツの枠を超えたことです。ブログ記事とチュートリアルのために作ったものでしたが、汎用のレーンと THE GUILD によって、チームの誰もがあらゆる種類の作業に使えるものになりました。それによって、今後の方向性についての私の考え方も変わりました。

私たちは、CircleCI の1つのコンテンツチームに所属する5人です。これを作ったのは、毎週同じ作業を手作業で繰り返すことにうんざりして、それを機械が読める形で書き留めようと決めたからです。その機械が Claude で、形式が隠しディレクトリだというのは、実装の詳細にすぎません。実際に決めたのは、「プロセスを覚えているふりをするのはやめて、プロセス自身に覚えてもらおう」ということでした。

次に巻き込みたいのは Growth チームです。その後はマーケティング全体に広げ、それぞれが独自の CLAUDE.md を持ちながら、同じフォルダ構成と、意味のある範囲で共通のパターンを使う形にしたいと考えています。今は、何が汎用的に使えて、何が私たち5人の働き方に特有のものなのかを学んでいるところです。

チームのためにこうしたものを作ろうとしているなら、出発点は .claude フォルダです。その中に何を入れるかは、あなた次第です。