「AIを雇う」という設計　Kuuki Design AIエージェントチームの全貌（AI社員編）

AIを使っている人は多い。AIを雇っている人は少ない。

ここでいう「雇う」は比喩じゃない。役割を定義する。担当範囲を決める。「この仕事はこのAI、これは別のAI」と明文化する。それだけで、同じAIから出てくるアウトプットの質が変わる。

多くの人がAIを「賢い検索エンジン」か「なんでも屋のバイト」として使っている。毎回同じチャット窓に、その日違うことを頼む。結果として得られるのは「まあ使えなくはない」レベルの答えだ。

問題はAIの能力じゃない。役割設計の問題だ。

なぜ私はAIチームを作ったか

2026年4月、17年間のBig Tech（Amazon・Google・Cisco・スタートアップ）のキャリアを経て、独立した。

現在やっていること：YouTubeでのデザインキャリア教育コンテンツ制作（登録者数28,000人超）、デザインコンサルティング、個人開発プロジェクトの複数本を並行。これを全部一人で回している。

一人でできることに上限があるのは、みんな知っている。でも「組織設計をAIでやる」という発想は、まだ多くの人が試していない。一人でも、役割が明確な組織を持てる。その実装がこの記事で紹介するAIエージェントチームだ。

先日公開した動画では、組織の全体像を解説した。この記事はその補足として、各AI社員の役割と連携の仕組みを深掘りする。

AI社員とは何か

「ツール」と「社員」の違いを一言で言うなら、役割定義の有無だ。

ツールは使い方を知っていれば動く。ChatGPTに「これ要約して」と頼めば要約する。翌日に「これ翻訳して」と頼めば翻訳もする。その次の日には「ビジネスプラン書いて」と頼んでも答える。これが「ツールとして使う」状態だ。

社員には役割がある。「ブランドボイスのレビューをする」と定義された社員は、原稿を書き直さない。指摘して、本人に直させる。それが「その人の仕事」だから。

AIも同じだ。システムプロンプトで役割を明示したAIは、その役割の範囲内に集中する。役割が明確だと、「何をしないか」も明確になる。その境界線が品質を作る。

この記事が扱うのは「AI社員」
役割と担当範囲が定義されたエージェントたちだ。全チームをつなぐ調整層（Obsidian Context EngineとAIRFLOWタスクボード）は別号で扱う。

組織図：全体像

4つのチームがある。コンテンツ、エンジニアリング、ビジネス、インフラ運用。それぞれが異なる場所で動き（Claude Cowork、Claude Code、ローカルAIなど）、異なる専門性を持つ。全チームが共通のタスクボードとObsidian vaultを読み書きすることで連携する。

AI社員の雇い方：4つのステップ

抽象的な話を先にする。私の実装はその後だ。

Step 1：自分の仕事を「役割」に分解する

最初は「コンテンツ制作をやるAI」という粒度で役割を作った。粗すぎた。「コンテンツ制作」の中に「企画」「構成レビュー」「ファクトチェック」「Bロール素材設計」「配信パッケージ作成」という全く異なる役割がある。役割の粒度は細かいほど専門性が上がる。まず自分の仕事の中にいくつの役割があるかを書き出す。

Step 2：各役割の「インプット/アウトプット」を定義する

最初のシステムプロンプトに「フィードバックを返す」とだけ書いたら、AIは原稿を書き直して返してきた。「指摘のみ、書き直しは含まない」と明示した瞬間に挙動が安定した。アウトプットの定義は「何をしないか」まで書いて初めて完成する。「ブランドボイスレビュアー」なら、インプット：脚本草稿。アウトプット：ボイスから外れた箇所のフラグと指摘（書き直しは含まない）。

Step 3：システムプロンプトで役割を明示する

「なんでもできる賢いアシスタントとして動いてください」で始めると、何でも答えようとして品質がブレる。役割名から書く。例：「あなたはKuuki Designのブランドボイスレビュアーです。提出された原稿を読み、私の通常の話し方から外れている箇所を指摘してください。原稿を書き直すことはしません。指摘のみを行います。」起動時の一行が、AIの行動範囲を決める。

Step 4：AI社員間のハンドオフを設計する

「誰が何を受け取り、何を次に渡すか」を決める。この流れを決めないと、AI社員がいても「毎回私に戻ってくる」状態になる。ハンドオフを設計することが、組織を組織にする。

この先は、各チームの構成、各社員の責任範囲などを事細かく解説する。

また巻末には私が使っているClaude Codeオーケストレイターのskill.mdの概要を記載するので、参考にして欲しい。