この記事について

生成AIを活用してブログ運営を始めたい方、日常業務でも生成AIを使いたい方に向けて書いています。

このブログは、記事執筆の大半をClaude(Claude Code)に任せる戦略で運営しています。ただしインプットにするのは自分の実体験のみで、一般論だけの記事は書かせません。この記事では、実際に運用する中で見えてきたルールの作り方と、便利さの裏にあるリスクについて書いておきます。

使っているのはClaude Code、料金はClaude Pro

使っているのはAnthropicのターミナル型エージェント「Claude Code」です。契約しているのはClaude Proプラン(月額$20、年払いなら月あたり$17)で、今のところこのプランで十分満足して使えています。

今回このブログの構成上、Claudeにコードも書かせたかった(記事のMarkdownだけでなく、サイトのレイアウトや機能の実装まで任せたかった)ので、有償プランを選んでいます。文章を書かせるだけであれば無料プランでも試せますが、コーディングを含むエージェント的な使い方をするなら、有償プランを検討する価値はあると思います。

良かった点: 役割分担がはっきりした

一番良かったのは、「Claudeに依頼すること」と「自分が確認すること」がはっきり分かれたことです。記事の構成・執筆・ビルド確認・ブランチ作成・PR作成まではClaudeに任せ、自分は依頼シートを埋めることと、出てきた記事の内容を確認することに集中できています。

記事を一人で一から書いていた頃と比べると、公開までのスピードは体感で7割は削減できていると言っても過言ではありません。もちろんこれは「実体験メモを渡せば、それをベースに記事化してくれる」という前提があってこそで、メモがない状態で丸投げしているわけではありません。

悪かった点: 実際にやらかした話

正直に書くと、時々やらかします。

このブログでは本来、「記事執筆を依頼する → Claudeがプルリクエストを作成する → 自分が確認する → 公開ルーティンを実行する」というルールで運用していました。ところがある時、記事の修正作業を別の修正(デザインや設定の変更)と同じブランチにまとめて作業してしまい、レビュー前の記事が公開希望日より前にそのまま公開されてしまったことがありました。

原因は、記事用の変更とそれ以外の変更を同じ作業ブランチに混在させていたことでした。ここから、「何か作業をする前には必ずブランチを分けよう」というルールを追加することになりました。地味な話ですが、こういう実際に起きた失敗をルールとして反映していくプロセス自体が、運用の肝だと感じています。

結局、md類を固めることがすべて

ここまでの話を通して行き着いた結論は、「md(指示書)類を固めることが一番大事」ということです。

Claude Codeとのやり取りはセッション単位で進みますが、話が長くなるとセッションが肥大化し、新しいセッションを作り直すことがあります。そのとき、過去のやり取りの記憶は引き継がれず、リポジトリに置いてあるmdファイル(このブログではCLAUDE.md)が唯一の引き継ぎ資料になります。何か作業をさせた後は、「このmdに追記すべきことはないか」を都度確認し、アップデートするようにしています。

md作成時に意識している7つのこと

指示書を書くときに、自分が意識していることをまとめておきます。

1. mustよりも禁止事項を書く 「〜すること」より、「〜しないこと」の方が判断がブレにくいです。例えば「事実に基づかない内容は書かないこと」のように書きます。

2. 曖昧な判断基準がブレることは書かない 「品質高く仕上げること」のような曖昧な基準はNGです。「修正後にビルドエラーが発生しないこと、それが今回の『品質高い』状態である」というように、判定可能な条件に落とし込みます。

3. 優先順位を明記する 規約(md)とチャットでの依頼が矛盾するケースは普通に起こります。「規約とチャットでの依頼が矛盾する場合は規約を優先する」と決めておけば、人間側のうっかりミスにも対応できます。

4. 「いつ」の条件を明記する 「記事が完成したときは以下を実施する」のように、条件とセットでタスクを書きます。

記事が完成したときは以下を実施すること:
- タイトルと本文の文字数をチェックすること
  (ただし文字数が規定より少ない場合は、実体験メモが
   希薄な可能性があるためユーザーに確認する)
- ビルドが通ることを確認すること
- ブランチを切り、プッシュ&プルリクエストを起票すること

5. 出力結果を明確にする 何がどう出力されるべきかを具体的に指定します。

6. NG例を記載する 実際にやってしまった失敗を、反省として書いてもらうようにしています。前述のブランチ混在の件も、実際にこの形でmdに残しました。

7. 判断基準を書く 優先順位に近いですが、複数の答えがあり得る場面での判断軸です。例えば「依頼に対してどのアクションを取るべきか悩む際は、修正行数が少ない方を選ぶ、新しいファイルを増やさない、既存パターンを優先する、の順で判断する」というように書いています。

ここに加えて、必要であればブログのキャラクター付けの指示を足すこともあります。

一番大事なのは、成果物へのレビューの目を持つこと

ここまでmdの話を書いてきましたが、個人的に一番大事だと思っているのは、成果物に対してしっかりレビューの目を持つことです。

生成AIは昔に比べてどんどん賢くなっているのは事実ですが、あくまで確率的に答えを導き出しているものだ、ということは常に意識しておくべきだと思っています。mdはその出力結果を意図的にブラさないための手段ではありますが、書いていても内容を見落としたり、Claude自身が忘れたりして、悪影響が出ることは普通に起こり得ます。

昨今では、生成AIに頼り切ったコーディングによって、APIキーなどの秘匿情報がそのまま公開されてしまうケースが度々報告されています。便利であることは間違いない一方で、使う側にもある程度のリテラシーが必要だと思っており、メリットとリスクは常にセットで意識した方がいいです。

まとめ

記事執筆の大半をClaude Codeに任せつつ、実体験メモというインプットと、最終的なレビューの目は自分が持つ。これが今のところ落ち着いている運用スタイルです。

  • mdに禁止事項・判断基準・NG例を積み重ねていくことで、運用はどんどん安定していく
  • それでも失敗はゼロにはならないので、実際に起きたことをその都度ルール化する
  • 便利さに頼り切らず、生成AIは確率的に答えを出しているものだという前提でレビューする

今後も運用しながら、mdをアップデートし続けていくつもりです。