Claude Codeで業務を効率化してきた中で、
「効率化が効く記事」と「効率化が効かない記事」の差がはっきり見えてきました。
このノートでは、シリーズの締めとして、うまくいかなかった部分を実体験をもとに整理します。
このシリーズ（#01 導入の全体像 → #02 記事構成 → #03 本文執筆・リライト → #04 入稿・整形・公開）
を通じて言えることは、「どこまで任せられるか」の判断は、最終的に人間が持ち続けるということです。
このノートでは、「どこまで使えるか」ではなく、「どこで使わないかも含めて判断できる状態」をゴールにしています。
この記事の目的は「Claude Codeの限界を知ること」ではありません。
「効率化が効かない領域を自分で判断できるようになること」です。
記事の性質で、工数がまったく変わる
Claude Codeで業務の効率化を進めた今でも、テーマによって手直しの量がまったく違います。
ほぼそのまま使える記事もあれば、ほとんどを確認・修正することになる記事もあります。
この差を生んでいるのは、記事の性質です。
実体験ベースの記事は、ワークフローが変わる
Claude Codeは実体験を書けません。
指示を出すと「それらしい内容」を生成しますが、実際に起きたこととズレた内容が出てきます。
この記事自体がその例です。
初稿では、
「セッションが変わるたびにトンマナを毎回説明していた」
「記事全体を一括出力させると後半で軸がブレる」
など、実際にはなかったことが複数書かれていました。
一つひとつ確認と修正が必要になり、時間がかかりました。
実体験ベースの記事で機能するワークフローは、「一括で生成させる」ではありません。
構成を確定させた後、実際に起きた体験をまとめて読み込ませ、Claude Codeが整理・構造化する流れのほうが現実的です。
ルールを保存しても、適用されないことがある
ブロック要素指定、CTA、関連記事の配置、文体のルール、事実でない内容を書かないこと
など、CLAUDE.mdには複数のルールが記載されています。
それでも今回、初稿では複数の項目が抜けていたり、実際にはなかった体験が書かれていたりしました。
ルールを保存しておくことで防げるミスはあります。
ただし、ルールの存在と、ルールが毎回ちゃんと適用されることは別問題です。
「保存してあるから大丈夫」ではなく、「保存してある内容が適用されているか」を確認することが必要です。この確認工程は、今の段階では省けません。
人間とClaude Codeの確認ループが、現実的な使い方
実体験ベースの記事では、一回の生成で完結しません。
現実的な流れは次のようになります。
Claude Codeが出力する → 人間が読んで事実と違う箇所を指摘する → Claude Codeが確認・質問する → 実際の体験を共有する → Claude Codeが修正する → また確認する
このループに時間がかかります。
ただし、このやりとりを通じて、最終的な精度が上がっていきます。
＼ 自分でやる時間がない方へ。まるっとブログ記事運用代行します／
お気軽にご相談ください。
Claude Codeで業務の効率化を進めた今も、人間が担っている作業
実体験・事実を提供する
Claude Codeは実体験を生成することはできます。
ただし、生成された内容は実際に起きたこととは異なる内容になります。
それで良しとする場合もありますが、事実を正直に書くスタイルを採用しているこのメディアでは、そのまま使うことはできません。
実体験の素材を提供するのは、常に人間の役割です。
出力内容が事実かどうかを確認する
生成された内容が、実際に起きたことと合っているかを確認する作業は省けません。
この確認を省略すると、事実と異なる内容が記事に残ります。
確認して指摘し、Claude Codeが質問して内容をすり合わせていくやりとりが、精度を担保する工程です。
最終的な品質を判断する
内容が事実か・読者に伝わるか・メディアのトンマナに合っているか。
これらの判断は、ルールを整備していても最終的には人が確認します。
過程がどうあれ、クオリティの最終判断は人間が持ち続けます。
Claude Codeが安定して動く条件
うまくいく記事には共通点があります。
・処理の骨格（構造）がある
・変換のルールが言語化できる
この2点が揃っているとき、Claude Codeは高い再現性で動きます。
管理ファイルの更新・チェックリストの実行・整形といった作業は、この条件を満たしやすいため安定して任せられます。
一方、実体験・事実・判断が核になる記事は、この条件が揃いにくいため確認工数が増えます。
「Claude Codeを使えば全体の工数が減る」ではなく、「骨格と変換ルールが揃う部分の工数は減るが、人間が担う部分の工数はテーマの性質によって変わる」が正確な表現です。
どこに使うかを判断するのも人間の役割で、この判断基準を持っておくことで、記事ごとに工数を見積もれるようになります。
ここまで整理すると、「どこで使うか」だけでなく、「どこで使わないか」も判断できるようになります。
すべてをClaude Codeに任せるのではなく、使う部分と使わない部分を切り分けることが重要です。
この「使わない判断」も、業務設計の一部です。
このシリーズ（全5回）で言語化できた業務構造
記事構成・本文執筆・入稿・公開・そして効率化できなかった部分まで、ライター業務を一通り検証しました。
AIができる部分・人間の部分の境界線
Claude Codeに任せられる部分
人間がやる部分
・骨格（H1〜H3の構造）の整理
・文章のリライト / 表現の変換
・整形 / 装飾 / ファイル管理
・実体験 / 事実の提供
・出力内容の事実確認
・最終品質の判断
業務を回すには、この境界線を設計する必要がある
この分担は、最初から意図して設計したものではありません。
うまくいかなかった経験を通じて、自然に固まってきた境界線です。
「Claude Codeに任せれば動く」のではなく、「何を任せて、何を人間が持つかを設計することで動く」が正確です。
この設計自体に時間と経験が必要で、記事を重ねながら精度が上がっていきます。
この構造は、自分の業務でも使える判断基準になる
「骨格があるか」「変換ルールを言語化できるか」という問いは、ライター業務に限りません。
自分の業務に当てはめたとき、任せられる部分と人間が担う部分が見えてくれば、どこから効率化を始めるかの判断ができるようになります。
このシリーズではライター業務を例にしましたが、この構造は他の業務にもそのまま応用できます。
設計と確認のループを回せる状態を作ることが、業務としてClaude Codeを使いこなす出発点です。
その上で、「どこまで使うか」「どこで使わないか」を自分で判断できることが、このシリーズの到達点です。
現在はこの型をベースに、業務ごとの最適な使い方を整理しています。
＼ 自分でやる時間がない方へ。まるっとブログ記事運用代行します／
お気軽にご相談ください。
