WorkTypes の私は、AI（Claude Code）に秘書・マーケティング・開発といった「部署」の役割を持たせ、自分は判断と確認に回る形で、ガジェットとAIのブログ（WorkTypesLab）、note、SNS（X・Threads・Instagram）を運用しています。
この記事は、その2026年7月の運用を振り返る記録です。材料は7月の社内記録（日次ログ・TODO・決裁メモ・週次レポート）だけで、書いているのは10月です。記録にないことは書かず、数字は記録から数えたものだけを載せます。
この記事の要点
- 7月は、ブログの読まれ方を12週かけて伸ばす計画を立て、手順書16本にまとめてから、毎週の制作を回した月でした。
- うまくいったのは「前提が違ったら止まる関門」と「公開前の調べ直し」です。主力記事を消しかけた作業を、手順書の関門が止めました。
- つまずいたのは「黙って失敗する自動化」です。SNSの予約が0件なのに正常終了したり、週1回の計測が約3週間止まっていたりしました。
- 直し方は、AIの報告を信じる前に、AIを使わずに「数を数える」検査を足すことでした。
7月の全体像：計画を立て、毎週の制作を回した
7月は、12週の計画を立てて手順書にまとめ、そのうえで毎週の制作を決まった型で回した月でした。月末には、8月最初の週の分を前倒しで予約しています。
12週の計画と、手順書16本
7月2日の夜、私はAIに「ブログの読まれ方を伸ばす計画を、全方位で作ってほしい」と頼みました。AIは検索の実績、アクセス解析、公開中の196記事、社内の決めごとを分析し、12週・3段階の計画を出してきました。翌3日に承認しています。
計画は、実行する別のAIが迷わないように手順書へ落としました。実行の約束事、14本の手順書、抜け漏れの点検の計16本です。
ここで最初のつまずきがありました。手順書を29体のAIに並行で書かせたところ、利用上限に2回当たって止まり、書き上がったのは4本だけでした。残りは本体のAIが直接書いて仕上げています。
大きな並行作業は上限を食い潰す、というのがこの日の学びです。
毎週の制作の型
毎週の制作は、週のはじめに予定表を作り、次の型で回しました。
- ブログの新規記事：3本（7月5日〜11日の週だけは、大型セールに合わせて4本）
- リライト：2〜3本
- noteの無料記事：5本
- SNS：1日6本前後を予約で自動投稿
7月22日には、noteのメンバーシップに初めての会員が1人加わり、会員向けに連載の第8章と会員限定の記事を書くことにしました。
月末は、8月1日〜3日に私が作業できない予定だったため、8月最初の週の分（ブログ3本・note 5本・SNS 42本）を、7月中に予約まで終える前倒しをしました。
部署の分担
次の表は、AIに持たせた部署ごとの分担を、おおむねまとめたものです。
| 部署 | 7月にしたこと |
|---|---|
| 秘書 | 毎朝の確認（予定、SNSへの返信の要否、前日からの繰り越し）と、作業ログ・TODOの記録 |
| マーケティング | 週の予定表、ブログ・note・SNSの原稿、図解 |
| 開発 | ブログへ投稿するための変換ツールや、自動投稿の仕組みの手入れ |
| 下請けのAI（サブエージェント） | ファクトチェックや画像づくりを並行で担当。結果は本体のAIが確かめる |
| 別のAI（Codex） | noteの下書き保存（任せた週があった） |
うまくいったこと：止まる関門と、公開前の調べ直し
うまくいったのは、前提が違ったら止まる関門と、書いたあとの調べ直しです。作業できない8月1日〜3日に向けた前倒しも、数を数えて確かめながら進めました。
前提が違ったら止まる関門
手順書の冒頭には「作業を始める前に、前提を実物で確かめる。食い違ったら止まって報告する」という約束を置きました。
7月3日、これが効きました。計画では「表示されないページ（404）なので、別の記事へ転送（301）する」となっていた記事が、実際には正常に表示され、よく読まれている主力記事でした。そのまま転送していたら、主力を消すところでした。
AIは手を止めて報告し、私は転送を保留にしました。12日後の7月15日、データを見直したうえで、内容が重なっている側の記事を主力の記事へまとめる形で統合しています。
計画は机の上で作るので、実物とずれることがあります。ずれたときに止まれるかどうかを、手順書の最初に書いておく。7月の記録で、はっきり事故を防いだ決めごとです。
書いたあとに、もう一度調べる
7月2日、記事は「書く前に調べ、書いたあとにもう一度調べる」を標準の手順にしました。7月の記録では、この二度目の調べ直しで、公開前に誤りが何度も見つかっています。
次の表は、二度目の調べ直しで見つかったことを日付順に並べたものです。
| 日付 | 調べ直した記事 | 見つかったこと・直したこと |
|---|---|---|
| 7月2日 | 大型セールの記事 | 発売時期の誤りなど4件を、公開前に修正 |
| 7月11日 | インボイス制度の記事 | 経過措置の割合が古いルールのまま。国税庁の一次情報で確かめて修正 |
| 7月25日 | 翌週分の8本（ブログとnote） | 8体のAIで並行して点検し、4本に修正が入った |
| 7月28日 | 記事の初稿 | 7月中旬の価格改定より前の値段を載せていた。全面的に差し替え |
7月28日は、根拠が二次情報1件だけだった価格も、販売店の公式データで実売価格と照らし合わせました。同じ日に、公開前の調べ直しを改めて決まりとして記録しています。
作業できない日の分は、先に本文まで確定する
SNSの予約は普段、「前夜にAIが翌日分の本文を作って予約する」方式です。ただ8月1日〜3日は、失敗しても誰も直せません。
そこで7月29日、8月最初の週の42本は、すべて本文を先に確定して予約に埋め込みました。登録が42件あること、日時の食い違いが0件であることを数えて確かめています。この検査で、目視では見逃していた韓国語1文字の混入も見つかりました。
同じ考え方で、7月31日分の6本も前夜に本文を確定しました。当日は6本すべてが投稿されています。
つまずいたことと、どう直したか：黙って失敗する自動化
7月のつまずきは、失敗が表に出ないまま進む「黙って失敗する」形が中心でした。直し方は、報告を信じる前に、実物や数で確かめる段を足すことです。
次の表は、7月のつまずきを、直す前と直した後で並べたものです。SNSの予約、完了の報告、週1回の計測は、このあと順に詳しく書きます。
| つまずき | 直す前 | 直した後 |
|---|---|---|
| SNSの予約（7月21日） | 予約0件なのに「正常終了」 | 予約の数を数える検査を、後ろに一段足した |
| 完了の報告（7月22日・25日・26日） | 「済み」の報告と、実物が食い違う | 本体のAIが実物を開いて確かめ、その場で直す |
| 週1回の計測（7月4日から） | 失敗が続き、約3週間ぶんの記録がない | Macのアクセス権を与えて復旧（7月31日） |
| Xへの投稿（7月8日） | Xが数える文字数が301（上限280）で弾かれた | 短くした版を翌朝に投稿。自動予約の手順に「280以内」を追記 |
| 商品リンクの部品（7月2日） | ブログのエディタで保存すると設定が黙って消えた。部品が決まった形式に合っていなかった | 記事を作るツールの側を直した |
SNSの予約が0件なのに「正常終了」
7月21日の夜、翌日分のSNSを予約する自動処理が、正常終了したのに予約を1件も作っていませんでした。この夜はAIを起動したまま発火を待たせていたので気づき、6本をすぐに補充できました。
最初は、ログに出ていた権限の警告が原因だと見立てました。ところが翌日に切り分けると、同じ警告は予約に成功した日にも出ていて、無関係でした。本当の問題は、AIが13分ほど動いたあと何も作らずに正常終了する「沈黙の失敗」と、それを成功と伝える通知でした。
直し方は、AIを使わない短いスクリプトを、後ろにもう一段足すことです。
- 23時58分：翌日分の予約の数を数える
- 朝6時30分：当日分の予約の数を数える
- 4件に満たなければ：至急の通知を出す
初めて動いた7月23日は、夜も朝も「6件、OK」でした。なお7月30日には、この検査そのものの誤検知が見つかり、実行時刻をずらしています。検査も、確かめる対象の一つでした。
「終わりました」と、実物が食い違う
7月19日の決裁メモで「完了の報告は、事実を確かめてから受け取る」と決めていました。それでも7月は、報告と実物の食い違いが何度か記録されています。
- 7月22日：自動実行の担当AIが「TODOを更新した」と報告したのに、実体は変わっていなかった
- 7月25日：引き継ぎメモで「まだ投稿していない」とされた記事が、実は7月20日に公開済みで、しかもその日の午前に直した内容が入っていない古い版のままだった。気づいたのは、サイトを見た私でした
- 7月26日：「修正済み」と思っていたSNSの予定表が、確かめると直っていなかった
どれも、本体のAIが実物（公開ページ、予約の一覧、ファイルの中身）を開いて確かめ直し、その場で直しています。完了かどうかは、報告ではなく実物で決める。7月はこれを何度も繰り返しました。
週1回の計測が、約3週間止まっていた
7月27日の夜、締めの点検をしていて、毎週土曜に施策の効果を記録する自動の計測が、7月4日からずっと失敗していたことに気づきました。出力は空のままで、約3週間ぶんの記録が残っていませんでした。
原因はスクリプトではなく、Macの権限でした。定時に動く処理から、クラウドドライブ上のフォルダへ書き込む許可がなかったのです。7月31日、私がMacの設定でアクセス権を与えて復旧し、たまっていた3週間ぶんの測定も取り戻しました。
ただし、復旧した処理が、表の備考欄に手で書いていたメモを上書きして消す、という副作用も見つかりました。消えた172字は、自動更新が触らない場所へ書き写しています。
OSの更新でアクセス権が外れることもあるため、外れたら記録の置き場所を移す、という次の手も決めました。
数えられたことと、8月に持ち越したこと
7月に数えられたのは、ブログの新規記事15本、noteの無料記事の原稿25本、手順書16本などです。8月へは、相談の受け口の立ち上げなどを持ち越しました。
数えられたこと
次の表は、7月の社内記録から数えた件数です。どのファイルのどの行から数えたかは、社内の根拠一覧に残しています。
| 項目 | 数 | 期間・補足 |
|---|---|---|
| ブログ（WorkTypesLab）の新規記事 | 15本を公開 | 7月1日〜31日 |
| noteの無料記事の原稿 | 25本 | 5本×5週分。8月最初の週の分を含む |
| noteのほかの原稿 | 差し替え1本、会員向け2本 | 会員向けは連載の第8章と会員限定記事 |
| 12週の計画を実行するための手順書 | 16本 | 実行の約束事、14本の手順書、抜け漏れの点検 |
| 公開前の点検 | 8本中4本に修正 | 7月25日 |
| 8月最初の週のSNS | 42本の本文を確定 | 7月29日。登録42件・食い違い0件 |
| SNS予約の検査 | 0件 → 6件でOK | 7月21日は0件。検査を足したあとの7月23日は6件 |
| 止まっていた計測 | 約3週間 | 7月4日から。7月31日に復旧 |
8月に持ち越したこと
次の表は、8月へ持ち越したことと、その状態をまとめたものです。
| 持ち越したこと | 状態・次にすること |
|---|---|
| 相談の受け口（サービス案内のページなど） | 8月2週目から立ち上げる（7月27日に決定） |
| 8月最初の週のnote 5本に入れる図解49枚 | 私の手作業に。noteへの取り込み方が変わり、これまでの自動の手順が使えなかった |
| 単独では読まれ方が落ちていると測定で分かった予測記事 | 後継の記事へ統合するかどうかを判断する |
| 会員限定記事 | 公開日を決める |
| 計測のアクセス権が外れたとき | 記録の置き場所を移す準備 |
次の一歩
7月の記録を読み返すと、つまずきの多くは「任せること」ではなく「任せた結果を確かめること」のところで起きていました。7月は、その確かめ方を少しずつ仕組みにした月です。
