AIに仕事を任せる仕組みを作ったのに、朝、何から始めればいいか分からない。記事を書くより仕組みを直している。AIエージェントを増やしている人には、そんな状態が起きるかもしれません。
僕のMac miniも、そうなっていました。2026年10月20日にやったのは、新しいAIの追加ではなく、動いている仕組みの棚卸しと、見る場所の整理です。作業カードの管理画面と同期を止め、今の状態を読む入口と、成果を選ぶ場所を絞りました。その日に判断待ちの原稿を4本読み、1本を採用して公開しました。
ここでいう「軽くした」は、管理する仕組みと判断までの道筋を減らしたことです。Macの処理速度を測って改善した、という話ではありません。
同じように行き詰まったら、棚卸し、止めるものの選定、入口の整理、成果の置き場、完了の決め方。この順で見直すのを勧めます。
約10日で、成果と一緒に管理の仕事も増えた
僕はMac miniで3つのサイトを運営しています。10月9日ごろから、AIのチームで記事制作を回す仕組みを作り始めました。
Codexを本部役にして、Hermesには編集長や執筆、レビューなど12の役割。作業カードを管理するPaperclip、スマホ用のDashboardも使い、Grok、Gemini、Sparkなども組み合わせていました。
約10日後、Codexの会話フォルダは30個、25GB。ファイルは約23万個あり、そのうち確認用のJSON形式の記録が約8,700個。Markdownの文書は1,622個で、最初に読む手順書だけでも56KBありました。
成果も出ていました。同じ期間に「15万ライフ」へ12回の公開をしています。ただ、次に何をすればいいかが見えにくくなり、AIは「確認待ち」「できない」で止まる。仕組みの修理や確認に時間を使い、記事に力を回せなくなっていました。
本番の仕組みが、AIの使い捨ての作業フォルダの上で動いている問題もありました。日々使い続けるものと、一時的な作業場所の区別も整理が必要でした。
いちばん困っていたのは、AIは作業をやっていると言っているのに、僕には進んでいるように思えないことでした。
まず棚卸しする。この段階では何も変えない
10月20日は、Claudeをまとめ役にして、僕が判断しながら整理しました。最初にしたのは、何が動いていて、何が使われていないかを一覧にすることです。この段階では、まだ何も変えませんでした。
自分の環境で試すなら、まず一つの成果が届くまでをたどると整理しやすくなります。記事なら「依頼する」「書く」「読む」「採否を決める」「公開する」という流れです。その途中で、どのAI、管理画面、保存場所を通るのかを書き出します。
棚卸しの記入例は、こんな形です。
- 原稿を書くAI：何を受け取り、どこへ本文を保存するか。
- 進捗を見る画面：誰が見て、何を決めるために使うか。
- 自動同期：どことどこをつなぎ、止まると何が届かなくなるか。
- 確認用の記録：後で誰が読み、どんな判断に使うか。
名前を全部集めるより、「これを使って自分は何を決めているか」を一緒に書くのがポイントです。用途を説明できないものが、次に止める候補になります。
何のために動いているか分からないものは、止め方を探す前に、受け取る側を確認します。原稿の唯一の保存先なのか、別の場所にある情報を映しているだけなのか。この違いが分かると、残すものを選べます。
次に、判断に使っていない管理と同期を止める
棚卸しの後、僕はPaperclipの管理画面と同期を止めました。
道具を増やすたびに、道具同士のつなぎ目も増えていました。原稿を作る処理が動いていても、管理画面へ状態を渡す部分で止まれば、また修理が必要になります。
安全のために重ねたルールも、ほとんどの作業を確認待ちにしていました。人が見ていない自動実行では、承認が要る操作がすべて「できない」で終わる。その結果を後から読んで対応する仕事まで増えていたのです。
読者の環境なら、最初に止める候補は、成果そのものよりも、同じ状態を別の場所へ写すための仕組みです。管理画面を開かずに原稿を読めるか、同期を止めても成果の保存先が残るかを見ます。
承認については、原稿を作るところまで任せるのか、外へ出す直前に人が決めるのかを分けておくと、止まった理由を判断できます。判断が必要な操作は、その内容と選択肢を人へ届けるところまでを仕事にします。
僕は保存物も整理しました。Codexの会話フォルダを30個から10個にし、使っていない143フォルダ、約4.5GBをアーカイブへ移しました。削除はせず、普段使う場所から分けて残しています。
入口は、今の状態が分かる1枚にする
毎回、長い手順書を読むところから始めるのも負担になっていました。そこで入口を「今.md」と「ルール.md」の2枚にしました。整理した時点で、それぞれ36行と48行です。
このうち、作業を始める入口は「今.md」。今の状態だけを置き、共通して守ることは「ルール.md」へ分けました。今日何をするかを知るために、過去の経緯を全部読み直す形から変えたのです。
自分で作るなら、最初の1枚には次の内容を置くのがお勧めです。
- 今、進めている仕事。
- 成果がある場所。
- 自分が決めること。
- 次に動く人と、その一手。
記入例なら、「原稿が届いている。本文を読んで採用か見送りを決める。採用後は公開担当へ渡す」と書きます。これなら、開いた人は次の行動を選べます。
過去の説明が必要なら、その資料へ案内を付けます。入口自体に経緯を足し続けると、また長い手順書に戻ってしまいます。更新するときは、終わった仕事を今の状態から外し、残っている仕事を読めるようにします。
成果を見る場所は、スマホで開くフォルダ一つにする
次は、AIが作ったものを僕が読む場所です。スマホで成果を見る場所を、Google Driveの「判断待ち」フォルダ一つにしました。原稿1本につき1ドキュメントで、冒頭には変更点と選択肢を置きます。
たとえば、原稿を見るために管理画面を開き、作業カードから会話を探し、さらに保存先へ移る。そうした経路を残すと、読む前の探索が必要になります。成果を選ぶ場所から、そのまま全文へ進める形にします。
原稿を届けるときの記入例は、次のようなものです。
「変更点：冒頭に結論を置き、手順を整理しました。 選択肢：採用する／修正して続ける／見送る。 修正する場合に決めてほしいこと：具体例を残すかどうか。 本文：以下に全文」
これは届け方の例です。読んだ人が何を判断すればいいか分かり、本文まで同じ場所で読めることを優先します。AIが作業したという報告だけでは、原稿の採否は決められません。
僕はこの日、判断待ちの4本を読み、1本を採用、3本を見送りにしました。採用した1本は、その日のうちに公開しました。
スマホでDriveを開いて選ぶ今の形は、最初に思い描いていた形とは違います。まあ、やりたかったことじゃないけど、とりあえず回したい。まず回すことを優先しました。
最後に、「完了」を二つに絞る
新しい決まりでは、完了を「判断できる形で届いた」と「公開された」の二つにしました。確認のための記録は増やしません。
原稿を書くAIから見れば、本文を保存した時点で一区切りかもしれません。でも、僕がどこにあるか分からず、何を決めるべきかも見えなければ、記事は先へ進みません。最初の完了は、人が開いて選べる形で届くところです。
次の完了は公開です。原稿が届いたことと、採用して公開されたことを分ければ、どこで止まっているかも見えます。判断待ちなら僕が読む。採用後なら公開へ進める。それぞれ次の一手につながります。
これから仕組みを整理する人も、まず「誰が何を見られたら受け渡しが終わるか」を決めてみてください。記事以外でも、提案書なら選択肢と全文、調査なら結論と根拠など、受け取る人が次の行動を選べる形を考えます。
今回、1日で手を付けたのは、AIの能力を上げることより、僕が読むまでの道筋でした。仕組みを直す仕事に追われているなら、今日進めたい成果を一つ選び、それがどこを通って自分へ届くかを書き出す。そこから、使っていない画面や重複した同期を止める候補を選ぶのが、最初の一手です。