非エンジニアがClaude Codeで自社サイト運用を回した実測記録──書く作業より確認する作業の方が多かった

筆者はエンジニアではない。コードを書く仕事をしたことはなく、このサイト(AI時短ラボ)の記事や動画の制作も、Claude Codeというターミナルで動くAIエージェントに指示を出しながら回している。この記事は「Claude Codeで何ができるか」という機能紹介ではなく、実際にサイト運用でどう使い、どこに時間を取られているかを、手元の作業ログから数字を拾って書く。

3行まとめ

• 記事を「書かせる」作業より、書かせたものを一次ソースと突き合わせて「直す」作業の方が時間を食う。ある1日の点検作業だけで、事実確認のために開いた一次ソースのURLは136件にのぼった
• 公開前に検証工程を挟むかどうかで、修正が必要な記事の割合は81%(検証なし・21本中17本)から0%(検証あり・8本中0本)まで変わった実測がある
• Anthropic公式データによれば、Claude Codeの手動確認プロンプトは97%が承認されており「反射的なクリック」になりやすいと分析されている。人間の毎回チェックが形骸化しやすいという構造は、本記事の実測とも重なる

「記事を書かせる」より「書かせたものを検証する」時間の方が長い

Claude Codeにサイトの記事を書かせること自体は難しくない。タイトルと狙うキーワード、参考にする一次ソースのURLを渡せば、下書きは数分で出てくる。時間がかかるのはその後だ。

2026年8月27日、サイトの記事群を点検する作業を1日回した際の記録では、事実確認のために一次ソースのURLをcurlで開いた回数が、記事クラスタひとつぶんの調査だけで136件になっていた。公式ページの料金表、ドキュメントの仕様、他サイトの一次発表──それぞれを実際に開いて、記事に書こうとしている数字や仕様と一致するか確認する作業だ。

非エンジニアがClaude Codeを使う場合、コードを書かせる場面より、こうした「大量の情報を集めて、事実と照合し、矛盾を潰す」作業の比重が大きくなりやすい。これはコーディング能力というより、テキストを大量に読んで裏取りする作業を代行させている状態に近い。

実際にやらせた作業の中身

「サイト運用」と一言で書いても中身は雑多だ。ある日の点検作業でClaude Codeに実際にやらせた作業を具体的に書くと、次のようなものだった。

• リンク切れの修正: サイト内から別チャンネルへのリンクが6記事分だけ古いURLのままで404を返していた。正しいURLに差し替え、curlで200が返ることを確認した
• 記事の分類の付け替え: 本来は時期を問わず読まれる「常緑記事」に分類すべきものが86本、速報ニュースの扱いのまま残っていた。記事の性質を1本ずつ判定し、分類を付け直した
• サムネイル画像の補完: 画像指定が抜けていた記事が23本あり、既存の生成スクリプトを走らせて埋めた

どれもコードを新しく書く作業ではなく、既にあるサイトの状態を機械的に点検し、ずれている箇所を直す作業だった。非エンジニアがClaude Codeに任せて成果が出やすいのは、こうした「大量の対象を同じ基準で点検し直す」タイプの作業だという実感がある。

検証工程の有無で公開前の修正率が変わった

同じClaude Codeを使っていても、公開前に検証の工程を挟むかどうかで結果が大きく変わったことがある。2026年8月14日、同じモデルに記事を書かせた上で、片方は検証なしでそのまま公開し、もう片方は書き手とは別の視点で内容を突き合わせてから公開した。

出てきた不備は、公式ドキュメントに存在しない文言を引用として書いていた、一次資料にない数値を勝手に算出して出典の値のように見せていた、といったものだった。書く工程で誤りが混ざること自体は珍しくない。問題は、検証を挟まないとその誤りがそのまま公開されるという点だ。

この分岐は、Claude Codeというツールの性能差ではなく、運用のどこに検証のチェックポイントを置くかという設計の問題だった。非エンジニアが自分でコードやコンテンツの正しさを判定できない領域ほど、この検証工程の有無が結果を左右する。

Auto Modeの数字が裏付ける「クリックは信用できない」

なぜ検証工程を別立てにする必要があるのか。この点について、Anthropic公式ブログ「Auto mode is now the default in Claude Code for Pro, Max, and Team plans」（2026年8月7日付、8月14日から適用開始）が示すデータが参考になる。同ブログによれば、Claude Codeのユーザーは手動確認プロンプトの97%を承認しているという。ブログはこの数字について「多くのユーザーが、毎回内容を吟味するのではなく、反射的にクリックしている可能性を示唆している」と分析している。

これは筆者自身の実感とも一致する。「書かせたものを人間が毎回チェックする」という建前の運用は、対象が増えるほど承認作業が形骸化しやすい。Anthropicが1,053人の有料テスターによる比較調査・内部レッドチーム・第三者レッドチーム・プロンプトインジェクション評価を重ねた結果、Auto Mode（分類器が破壊的・不可逆・環境外への操作をブロックし、通常のプロンプト確認を挟まない方式）は「全ての評価項目で手動レビューと同等かそれ以上」だったとしている。Auto Modeを導入したチーム・Enterprise利用者では、PRの出荷数が約25%増えたというデータも紹介されている。

裏を返せば、「人間が毎回確認する」という前提そのものが形骸化しやすいという指摘であり、本記事が実測した「検証あり8本・検証なし21本」の差も、個々のチェック担当者の注意力ではなく、検証を独立した工程として構造的に分離できているかどうかの差だと捉えるほうが妥当だろう。

CLAUDE.md・Skill・Hookのどれに任せるかの判断基準

上記の点検作業を繰り返すうちに、同じ指示を毎回チャットで打ち込むのではなく、CLAUDE.mdやSkillに落とし込む場面が増えてきた。この使い分けについて、Claude Code公式ドキュメント「Claude Code を拡張する」は、機能ごとに「どんな兆候が出たら追加すべきか」を具体的な表で整理している。

この表の基準は、本記事で紹介した点検作業の実感と近い。「一次ソースをcurlで開いて突き合わせる」という同じ手順を何度も繰り返すようになった時点で、それをSkill化するというのが、ドキュメントが推奨する自然な流れだ。公式ブログ「Steering Claude Code」はこの判断基準をさらに詳しく解説しているが、本記事ではドキュメント側の要約表の範囲にとどめている。

同じ日に大量公開すると後で直す作業が増える

サイト全体を後から点検した際、同じ日にまとめて公開した記事の集中が問題になったこともある。ある月には、1日で100本の記事が同時公開されていた日があった。これは検索エンジン側から見て不自然な公開パターンとして扱われうるため、後日、日付を複数日に分散し直す作業が発生した。ただし本文中に日付を明記している記事は動かせないため、分散しきれずに残った分もある。

なお、Google Search Central公式ドキュメントの「Spam policies for Google Search」を確認すると、「Scaled content abuse（スケールしたコンテンツの悪用）」という項目で問題視されているのは、あくまで「生成AI等のツールを使って、ユーザーに価値を提供しないページを大量に生成すること」であり、公開日時の集中そのものをペナルティの条件として明記しているわけではない。したがって「同じ日に100本公開すると不自然に見える」という本記事の懸念は、Googleの公式文書が直接そう述べているわけではなく、当サイト側の運用上の警戒にとどまる。ただし同ドキュメントが繰り返し強調しているのは「どれだけの分量を、どれだけの速さで作ったか」ではなく「1本1本がユーザーにとって価値を持つか」という基準であり、検証工程を挟まずに大量公開すること自体が、この基準に抵触するリスクを高める運用であるとは言えそうだ。

これも「Claude Codeが大量に記事を書けること」自体が問題だったのではなく、書けるからといって同じ日に出し切ってしまう運用設計が問題だった。書ける本数と、検証しきれる本数、公開して不自然に見えない本数は、それぞれ別の上限として管理する必要がある。

向いていた作業と、人が最後まで見た方がいい作業

ここまでの記録から、Claude Codeに任せて成果が出ていた作業と、任せきると事故につながりやすい作業を分けて書いておく。

• 向いていた: 大量のURLを開いて一次ソースの内容を拾う作業、既存記事との重複確認(grepでの照合)、frontmatterのような定型フォーマットの生成
• 向いていなかった: 複数の作業を並行して走らせている最中の変更範囲の管理。実際に起きた事故の内容は非エンジニアがAIコーディングで事故った話に書いた

公開前に何を基準に見るかは、非エンジニアがAI生成コードを本番に出す前に見る判断基準で改めて整理した。Claude Code自体のエラーで作業が止まった具体的な切り分け手順は、Claude Codeがエラーで動かない時の切り分け手順にまとめてある。

この記事の数字が「いつもの1日」ではない理由

正直に書いておくと、ここで挙げた136件・81%といった数字は、いずれもサイト全体の点検作業をまとめて行った特定の日のものであり、毎日の作業量ではない。普段は数記事の追記・修正だけで終わる日もあれば、こうした点検作業をまとめて行う日もある。「非エンジニアがClaude Codeを使うと平均してこの程度の作業量になる」という一般化はできない。あくまで、ある特定の日に実際に起きた作業量の記録として読んでほしい。

本文の数字の出どころ

本文中の数字は、記事公開時点の作業ログ(一次ソースの取得ファイル一覧、検証工程の前後比較記録)を執筆時に数え直したものであり、記憶で書いたものではない。Claude Code自体の機能に関する記述は、公式ドキュメント・公式ブログの該当ページ(いずれも実際にcurlで取得して確認)にもとづく。

• Auto Modeの「97%承認」「25%多くPRを出荷」という数字はAnthropic自身の調査によるもので、当サイトの運用ログとの直接の対応関係(当サイトの検証工程がAuto Modeの分類器と同じ仕組みで動いているかどうか)までは確認していない。両者は「人間の毎回チェックは形骸化しやすい」という同じ問題意識を指すものとして並べたにとどまる
• 「同じ日の大量公開が検索エンジンから不自然に見える」という懸念は当サイト側の運用判断であり、Google公式文書がこの運用パターン自体を名指しで問題視している記述は見つけられなかった。この点は本文中でも明記した
• CLAUDE.md・Skill・Hookの使い分け表は公式ドキュメントの要約であり、公式ブログ「Steering Claude Code」の本文全体までは精読していない