パーソナルOSを作り始めた頃は、AIにどこまで任せられるかを考えていました。
記事の下書き、調査、ファイル整理、WordPressへの反映準備。できることが増えるほど、AIに渡せる仕事も増えていきます。
ただ、AIを増やせば人間が楽になるわけではありませんでした。
別サイトを開く。別の記事を読んでしまう。古い本文と公開済みの本文が混ざる。確認していない体験が、もっともらしい文章として入る。正本とバックアップの区別も必要になる。
仕事を任せるための管理仕事が増えると、本末転倒です。
最近は「AIに全部任せる」よりも、仕事の重さ、失敗した時の影響、変更する権限に合わせて担当を分ける方へ考え方が変わってきました。
今の役割分担
ここで使っている呼び方は、私の中で分かりやすくするためのものです。
GPTは助手席のナビ
GPTには、最初の壁打ちを頼みます。何をしたいのか。どこまでやるのか。どこで止まるのか。作業が大きくなりすぎていないか。
答えを決める人というより、目的と安全線を一緒に整理する助手席のナビです。
母艦Codexは店長・現場監督
母艦Codexには、実物の確認と現場の進行を任せています。対象サイト、投稿ID、現在の本文、公開状態を確認する。必要な材料だけを限定担当へ渡す。返ってきた内容を原文と照合する。承認された変更だけをWordPressへ反映する。
大事なのは、正本やWordPressを触る担当を増やさないことです。今は母艦Codexだけが触り、人間は最後の更新ボタンを押す前に確認します。
バイト君は限定された担当
初見読者バイト君、リライト候補作成バイト君のように、仕事を限定した担当も使い始めました。
ただし、バイト君は正本を変えません。WordPressも開きません。渡された本文を読み、指摘や候補を返して止まります。
管理人は、最後まで残る人間の仕事を持つ
管理人が持つのは、本人にしか出せない体験、違和感、採用判断、そしてHuman Last Clickです。
公開、送信、削除、設定変更のように戻しにくい操作は、人間が最後に押す。この役割はAIに渡さない前提で試しています。
独自用語と一般的に近い用語
AI分野の呼び方は、製品や会社によって異なります。ここでは、私の呼び方に役割が近い一般用語を並べています。完全に同じ意味というより、自分が担当を間違えないための対応表です。
| 僕の呼び方 | 一般的に近い用語 | この運用での役割 |
|---|---|---|
| 助手席のナビ | 対話型AI・コパイロット | 壁打ち、目的整理、作業範囲、停止位置 |
| 母艦Codex | オーケストレーター・監督／実行エージェント | 実物確認、仕事の配布、原文照合、WordPress反映 |
| バイト君 | サブエージェント・ワーカーエージェント | 初見読者、限定調査、候補作成 |
| 管理人 | Human in the Loop・人間の承認者 | 体験、違和感、採用判断、最終責任 |
| Human Last Click | 承認ゲート・人間による最終承認 | 公開、更新、削除などの最後を人間が行う |
| 正本 | SSOT・canonical sourceに近い考え方 | 信頼する最新版を一つに固定する |
| 直列運用 | Sequential multi-agent workflow | 結果を確認してから次の担当へ渡す |
僕が「正本」と呼んでいるものは、一般的な設計用語ではSSOTやcanonical sourceに近い考え方です。完全に同じ正式用語として使っているわけではありません。
実際に3本の記事で試した
投稿ID127
「トイレがない100万円住宅」の記事は、通常リライトとして扱いました。初見読者に読みにくい箇所を見てもらい、管理人にしか答えられない体験を確認し、リライト候補を作りました。母艦Codexが原文と照合してから反映準備を行い、管理人が更新を承認しました。
ここでは、AIだけでは出せない体験が記事の中心になりました。
投稿ID42
DIYの記事は、軽微修正として扱いました。初見読者の確認は使いましたが、リライト候補作成担当は呼びませんでした。母艦Codexが、冒頭から煙突の失敗談へつなぐ部分などを1〜3か所だけ整える候補を作りました。
軽い修正に、重い工程を全部使わないための試行です。
投稿ID232
「仕事中の思いつきをAI仕様書に変える仕組み」の記事は、通常リライト候補から軽微修正へ縮小しました。初見読者の確認と管理人への事実確認を行い、リライト候補作成担当は省略しました。本文の修正に加え、アイキャッチと本文用の流れ図を追加しました。
同じリライトでも、毎回同じ人数や工程が必要とは限りません。
軽い仕事と重い仕事を分ける
今は、軽微修正、通常リライト、大幅改稿の三つを暫定的に使い分けています。
軽微修正は、接続や重複の整理、短い言い換えのような1〜3か所の変更です。母艦中心で進め、必要な時だけ初見読者を使います。
通常リライトは、複数段落の流れを整えたり、本人の体験を追加したりする作業です。初見読者、事実確認、候補作成、母艦照合を必要に応じて直列で使います。
大幅改稿は、タイトルや見出し、構成から考え直す作業です。いきなり本文を書かず、まず残すものを決める必要があります。
SEOはこの三つと並ぶ作業規模ではなく、「SEO目的あり」という別の目的タグとして考えています。まだ正式なルールではありません。
正本と直列運用
本文、バックアップ、公開ページ、下書きが複数あると、どれを基準にするかが曖昧になります。だから、確認した原文を母艦が持ち、限定担当へ直接渡し、結果を戻して照合する形を試しています。
複数担当を同時に動かさず、原則として一人ずつ使います。前の結果を確認してから次へ進むので、別記事や別の版が混ざりにくいと考えています。
正本やWordPressを触る担当を増やさないことも、今の安全線です。
まだ評価していない
EXP-019には、物件確認と投稿ID127、42、232の作業事実を記録しています。ただし、直列運用が本当に良かったのか、軽くなったのか、正式な方法にするのかは、まだ判断していません。
Claudeと作業手順を見返し、足す工程、減らす工程、第5件をその後に判断する予定です。現時点では完成した運用ではありません。
役割の名前や担当を増やすことが目的ではありません。母艦だけで済むなら母艦だけで進め、必要な時だけバイト君を呼ぶ。今はそのくらいの軽さで試しています。
今のところ言えるのは、AIに全部任せる形ではなく、軽い仕事は軽く、影響の大きい仕事だけ慎重に進める方が、自分には合っていそうだということです。
コメント