はじめに

個人開発に使える時間は、平日の夜に少しと、週末くらいです。

それなのに、作りたいものはどんどん増えていきました。ブログのツール、公開データをまとめたページ、ブラウザゲーム、Robloxのゲーム、ショート動画……。一つずつAIに手伝ってもらっても、指示を出してレビューするだけで夜が終わってしまいます。

そこで試しに、AI（Claude）に「部署」を持たせて、自分は決めるだけにしてみました。

しばらく続けてみて、思っていたよりいい感じに動いたので、どんな形にしたか、実際どう動いたか、やってみて決めたルールを書いておきます。

なぜ「部署」にしたのか

最初は、1つのチャットに何でも頼んでいました。

でも、ゲームのバグを直してもらった直後に、データページの検索対策を頼むと、前の話の前提が混ざります。話が長くなるほど、最初に決めたルールも忘れられていきます。

人の会社でも、1人に全部を頼むことはしません。企画する人、作る人、テストする人がいて、窓口になる人がいます。それならAIも同じように分けてみよう、というのが始まりです。

会社のつくり

Claudeの「プロジェクト」機能を使っています。プロジェクトの中に、仕事ごとにスレッドを立てる形です。

スレッド名のルール

スレッドの名前は、必ず先頭に部署名を付けます。たとえば「【ブログ部】ブログの検索流入を増やす」のような形です。

スレッドが増えてくると、名前だけで誰の仕事か分かることがとても大事になります。

窓口がいちばん大事

いちばん効いたのは、窓口を1つにしたことです。

部署が増えると、あちこちのスレッドから「確認してください」が飛んできます。これを全部自分で拾うのは無理です。

そこで、「自分がやらないといけないことは、窓口が1つのリストにまとめて送る」というルールにしました。同じものを2つの部署が触っているときも、窓口が1つの報告にまとめます。

1日の流れ

朝の報告は文字だけでなく、ゲージやグラフの入ったページになっています。スマホで眺めるだけで、どこが止まっているか分かります。

仕事の流れ：企画→開発→QA→公開

ポイントは、細かい仕様の判断は企画の部署に聞く、というルールです。「ボタンの文言はどっちがいい？」のような質問がこちらに来なくなりました。

逆に、取り消しにくいこと（本番からの削除や、外部への送信）や、アカウント・規約が絡むことだけは、必ずこちらに聞いてもらいます。

実例1：「訪問が減った」の一言から20分

ある夜、ブログの検索からの訪問が急に減っていたので、ブログの部署に一言だけ送りました。実際のやり取りを少し短くしたものです。

原因を調べてくる

ブログの部署は、まずサイトが壊れていないかを確かめました。ページが正しく返ってくるか、検索エンジン向けの設定（robots.txt やサイトマップ、正規URL）がおかしくないか、計測のタグが入っているか。

そのうえで手元の検索データを見直して、都営住宅の募集の時期と訪問の増減がぴったり重なっていることを見つけてきました。

作ってテストして、公開できる状態に

選んだ直後に、「募集回ごとの倍率結果ページ」ができました。平均倍率、申込が募集戸数より少なかった団地、倍率が低かった団地・高かった団地、区ごとの平均、前の年の同じ月との比較が載ったページです。新しい回の倍率表が公開された夜には、そのページも自動でできるようにしてあります。

自分がしたのは、最初の一言と「2、3で」と返したことだけでした。

実例2：この記事を書ける仕組みも作ってもらった

このブログの記事は、もともとNotionで書いて、Notion APIから読み込んで表示していました。

「Notion以外の記事も足したい。見た目はNotionの記事と区別がつかないように」と頼んだところ、リポジトリに置いたファイルを、Notion APIと同じ形のデータに変換して、同じ表示部品に流し込む作りにしてくれました。

// 記事ファイル → Notion API と同じ形（page + blocks）に変換して、Notion の記事と混ぜて並べる
const { posts, local } = await fetchAllPosts(databaseId);
const blocks = local.get(slug) ?? (await fetchBlocks(page.id));

表示の部品を別にもう1つ作るのではなく、データの形をそろえる方を選んだのが良かったところです。これなら、あとで見た目を変えたときも、Notionの記事とこちらの記事が一緒に変わります。

ついでに、Notionの囲み・引用・番号付きリスト・表も表示できるようにしてもらいました。この記事の図や吹き出しは、その仕組みで書いています。

QA部のテストの中身

QA部には、毎回だいたい同じことをしてもらっています。実例1の倍率結果ページでは、こんな内容でした。

モンキーテストは、あとから足したルールです。人が考えるテストは、どうしても「正しい使い方」に寄ります。ランダムに押してみると、「開封画面のまま閉じたらデータが消える」のような、思いつかない壊れ方が見つかりました。

もう一つ大事なのは、直さなくてもいいことも「メモ」として書いてもらうことです。合格・不合格だけだと、次に何を気にすればいいかが残りません。

やってみて決めたルール

仕組みよりも、こちらのほうが大事だと感じています。どれも、一度つまずいてから決めたものです。

つまずいたこと

ビルドの回数

このブログは無料のホスティングで動かしていて、月500回のビルド上限があります。

AIは小さな修正をすぐに出したがるので、放っておくと上限に近づきます。プルリクエストのプレビュービルドも回数に入ります。今は、QAに通ったものをまとめて1回で公開するようにしています。

本番だけで落ちるビルド

一度、検索エンジン向けの修正を入れたところ、本番のビルドだけが失敗しました。原因は import の並び順で、ESLint のエラーが本番ビルドを止めていました。

プルリクエストのプレビュービルドはいつも失敗していたので、気づくのが遅れました。今は、公開前に手元の環境で ESLint を通すようにしています。

正規URLがNotionを向いていた

調べていく中で、ブログ記事の正規URL（canonical）が、このサイトではなくNotionのページを向いていたことも見つかりました。

<!-- before: 記事の正規URLが Notion を向いていた -->
<link rel="canonical" href="https://www.notion.so/..." />
<!-- after: このサイトのURLにする -->
<link rel="canonical" href="https://nosuke-blog.site/blog/..." />

記事が検索に出にくかった原因の一つだと思います。自分では何年も気づかなかったので、「まずサイトが壊れていないか確かめる」を最初にやってくれるのはありがたかったです。

同じものを2つのスレッドが触る

ゲームの開発スレッドとQA部が、同じ画面を同時に操作して、ぶつかったことがありました。今は「この画面を触るのは同時に1つのスレッドだけ」と決めています。

任せきれないこと

もちろん、全部を任せられるわけではありません。

アカウントの作成や本人確認

外部サービスの規約の判断

取り消しにくい操作の最終判断

「何を作りたいか」という方向そのもの

特に最後の一つは、任せないほうがいいと感じています。企画の部署はいくらでも案を出してくれますが、どれをやるかを決めるのは自分です。そこを手放すと、自分のサイトではなくなってしまう気がします。

まとめ

AIに「作業」を一つずつ頼むのではなく、「部署」として任せて、自分は決めることに集中する。

試してみた結果、夜の少しの時間でも、かなりの量が進むようになりました。そして、やってみて分かったのは、仕組みよりも「ルール」のほうが大事だということです。ルールは、つまずくたびに1行ずつ増えていきます。

次は、部署ごとの指示の書き方や、QA部のテストのやり方を、もう少し詳しく書いてみようと思います。