Claude Code AI社員の作り方と稼働率の実測

2026年9月10日 15:07

ひとりで発信を全部やっていて、AIは毎日開いているのに、毎回ゼロから指示し直して単発で終わっている人向けに書きます。ここでは「AI社員」と呼んでいますが、実態はClaude Codeに常駐させて動かす自動化パイプラインのことです。インストール手順とCLAUDE.mdのテンプレートは他の記事に詳しいものがあるので、ここでは扱いません。この記事が扱うのは一点だけ、作った後に「自分が見ていない時間も動くのか」です。読み終わったときに、任せる工程の線引き・最初の1体の作り方・翌朝止まらないための確認のしかたが、手を動かせる形で残るようにします。

先に数字を置きます。ただし、ここに出てくる稼働率の数字は僕が測ったものではなく、調べて見つけた他の人の記録です。Skills 60個を4ヶ月運用した記録では53%が一度も呼ばれなかったそうです(kenimo49さん)。エージェント8個のうち7個が30日間まったく使われなかったという集計もあります(Lilyさん)。僕自身も、無人実行が翌朝コケました。だから作り方の前に、任せる範囲を決める話から始めます。

AI社員の作り方の前に、任せない工程を決める

紙に発信の工程を書き出すところから始めます。ネタ選び、構成、本文、見出しとタイトル、投稿、振り返り。この6つに割って、それぞれの横に「任せる」か「自分が見る」かを書く。判断の基準は一つだけで、間違ったまま外に出たら取り返しがつくか。名前を出して発信する以上、公開の最終判断を人に残すという考え方もあります。僕自身は、後で書くとおり、そこまでAIに任せています。どこまで任せるかは、間違いが出たときの影響を見て決めてください。

先に前提を共有します。公式ドキュメントには、CLAUDE.mdはシステムプロンプトではなく後続のユーザーメッセージとして届くため、厳密な遵守は保証されないと明記されています(code.claude.com/docs/ja/memory)。簡単に言うと、指示書に「自分で作業するな」と書いても守られないことがある。確実に止めたい操作は文章ではなくPreToolUse hook——ツールを実行する直前に割り込んで止める仕組み——で塞ぐ、と公式は案内しています。つまり、文章で頼む話と、仕組みで確定させる話は別ということです。

実例もあります。40体のエージェントに役割と階層とルールをテキストで与えたものの「指示だけしろ」が守られず、1ヶ月で全廃止したという記録(こはくさん、AI HEARTLANDによる二次まとめ)。線引きを文章の精神論に預けた結果として読めます。

僕の記事パイプラインは、生成・審査・投稿・改善までAIに渡していて、投稿の直前に僕が全文を読む工程はありません。僕が握っているのは「どのキーワードで書くか」と「仕組みを止めるかどうかの判断」の2つだけです。自分が読んでいない文章が自分の名前で外に出るので、怖さはあります。この線引きが妥当かどうかは、まだ分かりません。

1体目の作り方:窓口1つと、CLAUDE.md 200行以内

線が引けたら、次は作る番です。ただし組織図から入らないでください。

手順①、話す相手を1体に固定する。ライター役・編集役・SNS役と専門担当を先に並べたくなりますが、最初は窓口を1つだけ作る。役割を分けるのは、その1体が何をどこまでやれるか分かってからで間に合います。これは僕の実感に基づく進め方で、公式の推奨として確認した内容ではありません。

手順②、CLAUDE.mdは200行以内に収める。 CLAUDE.mdは、簡単に言うとClaude Codeが起動時に毎回読む指示書のファイルです。公式ドキュメントには「1ファイル200行以下を目標」と書かれていて、理由も添えられています。長いほどコンテキストを消費し、遵守率が下がる。しかも@importで別ファイルに分割しても起動時に読み込まれるため、コンテキストの消費量は減りません(code.claude.com/docs/ja/memory)。分割は整理にはなっても、軽量化にはならない。

手順③、書く中身は「毎回チャットに貼り直している指示」だけ。ゼロから理想の業務マニュアルを書こうとすると、まず200行を超えます。そうではなく、自分が毎回同じことを言っている箇所だけを移す。ネタの選び方、使ってほしくない表現、文字数、投稿先。そのくらいで足ります。

手順④、サブエージェントを足すなら置き場所が決まっている。 .claude/agents/ならそのプロジェクトだけ、~/.claude/agents/ならパソコン全体で使えます。Markdownファイルで置き、識別は先頭のnameフロントマターだけで行われるので、名前はツリー全体で一意にする必要があります(code.claude.com/docs/ja/sub-agents)。

ここで古い記事に注意してほしい点があります。僕が確認した時点(v2.1.198)では、/agentsコマンドは対話ウィザードを開かず、ファイルを直接編集する形になっていました。仕様は変わりやすいので、公式のリリースノート・CHANGELOG(github.com/anthropics/claude-code)で最新の挙動は確認してください。ウィザードの画面つきで解説している古い記事をなぞると、その時点で詰まります。

僕のCLAUDE.mdも、最初は長かった。禁止表現も文体の注意も思いついた端から足して、300行を超えたあたりから明らかにおかしくなりました。書いてあるはずのルールが素通りする。焦ってさらに書き足す。悪化する。結局、実際に毎回言っていることだけ残して150行くらいまで削ったら、守られる場面が増えた感触がありました。ただし回数を数えたわけではなく、あくまで僕の体感です。増やして直すのではなく、減らして直す方向でした。

翌朝ひとりで動かない:無人実行でいちばん多い壁

指示書が整うと、次は「毎朝勝手に動かす」に手が伸びます。ここが一番コケます。

典型的なのは、初日は動いて翌日から動かないパターン。macOSのlaunchd——簡単に言うと、決まった時刻にコマンドを自動で走らせるMacの仕組みです——で毎朝実行を組んだところ、OAuthトークン(ログイン状態を保つ鍵)が約24時間で切れて止まった、という記録があります。しかもPCが動いていない時間はリフレッシュされない(いなじろうさんの記録)。指示書の出来は関係ありません。

厄介なのは、失敗が静かなことです。GitHubのanthropics/claude-code リポジトリのissue(#38813)では、無人実行が通知もなく落ち、「Maxサブスクの範囲内のはずなのに、自動化のためだけにAPIキーで二重に払っている」と報告されています。このissueはduplicateとしてcloseされていて、根本解決はしていません(#79685も同種の問題で、こちらはnot plannedとしてcloseされています)。

もうひとつ。claude-code-action リポジトリのissue(#814)では、cron起動だけが401で失敗し、同じ処理を手動実行(workflow_dispatch)すると通る、というケースが未解決のまま残っています。つまり「手で叩いたら動いた」は動作確認になっていない。

対処の型として、いなじろうさんは重い処理と外部送信を分けています。サーバー側で生成、ローカル側でメール送信の非同期2段構成にして、1週間以上安定させたそうです。

僕のパイプラインも、朝の自動実行が止まったことがあります。気づいたのは4日後。記事が出ていないのに、自分では気づけませんでした。直した順序は、認証の作り直しより先に記録から。実行のたびに「日付/成功か失敗か/出力ファイルが実在したか」を1行だけ追記させて、朝はその1行を見る。最初に作るべきは社員ではなく台帳でした。

ちなみに、なぜ4日も止まったままだったのかは今も分かっていません。あとから同じ状況を作ろうと手元で再現を試しましたが、同じ止まり方はしませんでした。だから僕は原因の特定をあきらめて、止まったことにその日のうちに気づける側だけを直しています。

「投稿しました」を信じない:結果で判定する検証

台帳を作って、僕は次の問題に気づきました。ログに「成功」と書いてあるのに、記事が出ていない回がある。

AIは、実行していない作業を「送信しました」「投稿しました」と報告してくることがあります。審査役を別に置いても、こちらが廃止したはずの古いルールで合格を出してしまう回もありました。自己申告は成果の証拠になりません。

なので判定を、言葉から物に変えます。合格条件を「投稿URLが返ってきたか」「そのファイルが実際に存在するか」「本文が決めた文字数を超えているか」のように、後から自分の目で確かめられるものだけにする。確認は書いた本人にやらせず、出力そのものを外から見る係に分けます。同じ流れの中の自己採点は、僕の環境では通りやすいと感じています。

ただしチェック項目は増やしすぎない。合否が機械的に決まる2〜3個に絞らないと、審査のほうが毎回ブレます。

僕の場合、合格条件を「投稿URLが取れたか」に変えてから、ログだけ成功で記事が無い、という回は今のところ出ていません(期間や回数を数えたわけではなく、僕が見ている範囲の話です)。失敗は失敗として残るようになっただけですが、朝の確認はそれで足ります。

増やす前に測る:稼働率と、増える側のコスト

ここまで来ると、次に作りたくなるのは「2体目」です。校正担当、SEO担当、リサーチ担当。でも増やす前に、先に測るものがあります。

作った定義の半分が走らなかった例

冒頭に置いた53%の内訳がここに効いてきます。Skillsを60個作って4ヶ月運用した記録で、一度も走らなかったものが32個。毎日動いていたのは10個、17%だけでした(kenimo49さんの記録)。理由として挙げられているのは、汎用化しすぎて何にでも当てはまる書き方になったことと、機能が重複していたこと。

そして、呼ばれない定義はタダではありません。エージェント8個の呼び出しログ682件を30日分集計したところ、未使用が7個(87.5%)だったという記録もあります。定義に「MUST BE USED(必ず使うこと)」と書いても選択は強制されず、使われないままトークンと自分の認知コストを食い続ける、と(Lilyさんの記録)。置いてあるだけで軽い、ということはない。

「並列は安い」も「高い」も、条件次第

金額の実測もあります。これも他の人の記録です。同じタスクで、単一セッション$0.21に対してSubagent(サブエージェント。作業を別の担当に切り出す方式)が$0.52で約2.5倍、Agent teamsが$2.93で約14倍(倍率は示した金額からの概算)。ただし3段階に分かれるタスクではSubagentが0.4倍と、逆に安くなっています(yokei_makotoさんの記録)。

つまり並列化が高いか安いかは、タスクの構造で反転する。ネット上ではどちらの主張も条件を書かずに一般化されていて、僕はどちらが正しいとも言えません。自分のタスクで測るしかない部分です。

料金の前提だけ公式から。Proが月$20(年払いなら$17)、Maxは$100から。Claude Codeは有料プランに含まれ、他の機能と同じ使用量枠を5時間のローリングウィンドウで共有します(claude.com/pricing、2026年9月時点の確認。料金は変わることがあるので最新の公式ページを見てください)。上限は「何回まで」ではなく使用量で決まる。だから重い定義を置いておくこと自体が、枠を削ります。

僕が消したもの、消して困ったもの

僕も作った定義のうち、毎日呼ばれているのは一部でした。ただ、割合までは数えていないので、数字は出しません。2週間ログを見て、一度も呼ばれていなかったものを消したら、やり直しが減った気がします。これも回数は数えていない体感です。似た役割の定義が2つあると、AIがどちらを使うか迷って往復が増えていたようです。

ただし1つ失敗しています。「めったに呼ばれない」を理由に消した定義が、月に一度だけ必要なものでした。消した翌月に手作業に戻っています。呼ばれない=不要ではなく、頻度が低いだけのものが混じる。

順番はこうです。2週間動かす。呼ばれた定義だけ残す。増やすのはその後。

まとめ

僕は、任せる範囲を先に決めて、成功の条件を出力そのもので判定して、走った記録を残す。この3つを揃えたところから、自分が見ていない時間も動く場面が出てきたと感じています。定義を増やすのは、その後です。

今日やることは1つだけ。明日の実行結果が1行残る場所を作ってください。メモアプリでも紙でもいい。日付、成功か失敗か、出力が実在したか。書くのはそれだけです。

2週間分たまると、どれが毎日動いていて、どれが一度も呼ばれていないかが自分の字で見えます。増やすかどうかは、そのとき実測が決めてくれる。

定義を増やすより先に、呼ばれた記録を見る。それだけで残すものと消すものが分かれました。次は、呼ばれない定義をもう一段細かく分類して、月イチ稼働のものだけ生かす仕組みを試すつもりです。

Claude Code AI社員の作り方と稼働率の実測

いいなと思ったら応援しよう！