AI社員の職種一覧｜1人会社が実際に配属できる仕事とその境界

AI社員とは、Claude Code のサブエージェント機能を使って、業務ごとに専任のAIを定義し、その仕事だけを任せる運用のことです。定義に必要なのは Markdown ファイル 1 枚で、必須の項目は名前と「いつ呼ぶか」の説明の 2 つだけです。人を雇うのとは違い、増やすこと自体にはほとんどコストがかかりません。

だからこそ困るのが「で、何を配属できるのか」です。作り方の解説は増えましたが、実務のどの仕事が専任AIの担当になり得るのかを並べた一覧は見当たりません。結果として、思いついた役割から手当たり次第に定義して、一度も呼ばないファイルだけが増えていきます。

この記事は、1 人会社や小規模事業者が実際に配属できる職種のカタログです。調査・検証・制作・運用・分析の 5 系統に分けて担当業務と判定基準を並べ、あわせて任せない方がいい仕事の境界と、増やしすぎたときに何が起きるかまでを扱います。仕様は Anthropic 公式ドキュメントを 2026 年 9 月 7 日に確認したもの、数値は Anthropic の Economic Index レポートほかの一次資料から取得しました。なお、どの順序で着手するかは 配属の順序を扱った記事 で別に整理しています。

AI社員とは何か — 定義ファイル 1 枚で成立する

ここで言うAI社員は、Claude Code のサブエージェントを業務単位で切り出したものを指します。Anthropic の公式ドキュメント「Create custom subagents」によると、定義ファイルは YAML のフロントマターと Markdown 本文（＝そのAIへのシステムプロンプト）で構成され、置き場所によって適用範囲が変わります。

公式ドキュメントは「必須なのは name と description だけ」と明記しています。tools（使える道具の限定）、model（担当ごとのモデル指定）、mcpServers（その担当専用の外部接続）などは任意です。つまり、最初の 1 人は「名前」と「いつ呼ぶか」を書けば成立します。

もう 1 つ実務で効く仕様があります。ディレクトリは再帰的に読まれ、識別に使われるのは name だけです。フォルダを部署のように分けても、それは人間が探しやすくなるだけで、呼び出しの単位は変わりません。

自分で作る前に、最初から居る担当を把握する

公式ドキュメントには組み込みのサブエージェントが用意されています。自作する前にこれで足りないかを確かめると、定義ファイルが 1 枚減ります。

このほかに claude（どの専門担当にも当てはまらないときの受け皿）、statusline-setup、claude-code-guide があります。なお Explore と Plan の 2 つだけは、プロジェクトの指示ファイルと Git の状態を読み飛ばす仕様です。これを変える設定は用意されていないため、案件固有のルールを守らせたい仕事は自作の担当に振ることになります。

配属できる職種のカタログ

Web 制作・メディア運営を主業とする 1 人会社を前提に、専任AIとして切り出せる職種を並べます。「委譲の型」は次章で説明する判定軸、「必要な外部接続」は MCP サーバーの接続が要るかどうかです。

この表は候補の辞書であって、組み立てるべき体制図ではありません。上から順に全部作ると、次章以降で説明する失敗の型にそのまま入ります。使い方としては、自分がいま時間を取られている業務を 1 つ選び、それに対応する行だけを見る、が正解です。

外部接続が要る職種は、先に接続の可否を確かめてください。接続手段の全体像は Claude Code の MCP 連携ガイド一覧 に、自前の接続を作る手順は MCP サーバーの作り方 にまとめてあります。

調査系の職種 — 読む量が多い仕事を渡す

調査系は、専任AIに渡す価値がもっとも分かりやすい系統です。公式ドキュメントによると、サブエージェントはそれぞれ独立した新しいコンテキストで起動し、こちらの会話履歴も読んだファイルも引き継ぎません。大量に読ませても本体の会話が汚れないため、読む量に比例して分離の利点が出ます。

記事監査担当

新しい記事を書く前に、既存の全記事を走査して「同じことを既に書いていないか」「どの記事と読者を取り合うか」を判定させる担当です。合格基準は明確に書けます。走査した記事数を実数で報告すること、重複ありと判定した記事は該当箇所を引用すること、判定は 1 つに確定することの 3 点です。数を数える仕事なので、判定の正しさを人間が後から検算できます。

出典裏取り担当

本文に書く数値の出どころを、一次資料まで遡って確かめる担当です。合格基準は「URL・発行日・確認日時が揃っていること」「一次か二次かが明記されていること」。まとめ記事の孤立した数値をそのまま持ってきていないかは、報告の URL を見れば判定できます。発行日が古い資料に「古い」とラベルを付けさせておくと、記事の陳腐化にも気づけます。

改修範囲の洗い出し担当

既存サイトに手を入れるとき、その変更がどこまで波及するかを先に洗い出す担当です。テンプレートの継承、共通パーツの参照、CSS の依存など、1 か所直したつもりが別ページで崩れる箇所を潰します。合格基準は「ファイル名と行番号まで示すこと」「見つからなかった場合も探した範囲を報告すること」。組み込みの Explore で足りることが多い職種なので、自作する前に一度試してください。

競合調査担当

競合サービスの機能・価格・訴求を横並びの表にする担当です。提案書や比較記事の下ごしらえに向きます。ここでの合格基準は「取得日を明記すること」「公式サイトの記載のみを根拠にすること」。価格は変わるため、日付のない比較表は数か月で使えなくなります。推測で埋めさせないことが品質のすべてです。

検証・監査系の職種 — 自分の見落としを拾わせる

検証系は、成果物を作った本人とは別のコンテキストで見直させることに意味があります。作った経緯を知らない状態で読むので、書いた側が「言わなくても分かる」と省略した部分が引っかかります。1 人で仕事をしているほど価値が出る系統です。

公開前検証担当

公開直前に、書式・構造化データ・表記の統一を機械的に確認する担当です。この職種は検出と報告だけを担当させ、修正はさせないのが要点になります。検出と修正を同じ担当に持たせると、都合の悪い指摘を自分で消してしまい、何を見落としたのかが記録に残りません。合格基準は「指摘ごとに該当箇所を引用すること」「問題なしの項目も一覧に出すこと」です。

リリース前のバグ検出担当

変更差分だけを渡して、不具合と考慮漏れを指摘させる担当です。差分に限定するのが肝で、リポジトリ全体を読ませると指摘が散って使いものになりません。合格基準は「どんな入力でどう壊れるかを具体的に書くこと」。再現条件を書けない指摘は推測なので、この 1 条件を課すだけで報告の精度が上がります。

表示崩れ検査担当

実際のブラウザでページを開き、横スクロールの発生や要素のはみ出しを実測する担当です。ブラウザ操作の外部接続が要ります。この職種の合格基準は「実測値を数字で出すこと」に尽きます。「問題ないと思われます」で終わる報告は通さず、ビューポート幅と実際の文書幅を出させてください。目視の印象を報告させると、検査の意味がなくなります。

規約・表記チェック担当

広告表記の有無、素材のライセンス条件、他社ロゴの使用可否といった、抜けると後から効いてくる項目を確認する担当です。判断の根拠となる規約は変わるため、規約本文の該当箇所を引用させ、確認日を残させるのが実務上の合格基準になります。ここも検出専任にして、最終判断は人間が持ってください。

制作系の職種 — 型が決まってから渡す

制作系は、任せられる範囲が最初から決まっている系統です。型が固まる前に渡すと、戻ってきたものを直す時間の方が長くなります。逆に型さえ確定していれば、同じ形のものを並行して作らせる使い方がはまります。

下書き執筆担当

構成と論点が決まった原稿の初稿を書かせる担当です。ゼロから企画させるのではなく、見出しと各節で言うべきことを先に人間が決めてから渡します。合格基準は「指定した見出し構成から逸れないこと」「数値には出典を付けること」。出典なしの数値が 1 つでもあれば差し戻す運用にすると、事実確認の手戻りが激減します。

定型ページの量産担当

テンプレートが確定したページを、内容を差し替えながらまとめて作る担当です。サービス紹介、料金プラン、事例紹介のように構造が同じページに向きます。CMS への接続を持たせると投稿まで一気に進みますが、公開状態は下書きで止めさせるのが安全です。公開の判断は最後まで人間に残してください。

図解・バナー生成担当

サイズ・配色・書体の規格が決まっている画像を生成する担当です。規格書がない状態で任せると、毎回違うトーンのものが出てきて選定に時間を取られます。先に規格を 1 枚の文書にしてから配属するのが前提条件で、これが書けないうちは配属を見送る判断になります。

運用・分析系の職種 — 下書きまでを任せる

運用・分析系は、外に出るもの・意思決定に使うものを扱うため、任せる範囲を「下書きまで」で切るのが基本です。Anthropic の実測でも、仕事の場面で実際に生み出されている成果物の上位には下書き類が並びます。

問い合わせ一次対応担当

よくある質問への回答を下書きさせる担当です。Anthropic の Economic Index レポート「Cadences」（2026 年 6 月 26 日）によると、仕事目的の会話で生まれる成果物のうちメールの下書きは 7% を占めており、実際に多くの人が任せている領域です。合格基準は「既存の回答テンプレートにない内容を創作しないこと」「分からない質問は分からないと返すこと」。送信は人間が行います。

請求・見積の下書き担当

過去の書類を参照しながら、項目立てと文言を整えた初稿を作らせる担当です。金額の計算そのものは任せず、単価表を渡して転記させる形にします。桁を間違えた見積は信用に直結するため、この職種は「計算させない」を設計に組み込むのが要点です。合格基準は「単価表にない項目を出さないこと」。

アクセス解析担当

解析ツールに接続して数値を取り出し、前期間との差分と異常値を報告させる担当です。ここでの合格基準は「観測と解釈を分けて書くこと」。数字の羅列だけでは判断材料になりませんが、解釈を混ぜたまま報告されると、根拠のない推測が事実として残ります。取得期間と条件を必ず併記させてください。

実際のところ、どこまで任されているのか

カタログの妥当性は、実際の利用データと突き合わせると確かめられます。Anthropic の Economic Index レポート「Economic primitives」（2026 年 1 月 15 日）によると、49% の職業で、その業務タスクの4 分の 1 以上が Claude を使って行われています。同レポートは以前の計測が 36% だったとしており、範囲は職種を横断して広がっています。

ここで注意したいのは、この数字がタスク単位のカバー率であって、職が置き換わった割合ではないことです。同レポートは、カバー率が 90% に達していても職務全体への影響が大きいとは限らないと明記しています。カバー済みの重要なタスクで失敗したり、いちばん時間のかかるタスクを取りこぼしたりするためです。

では何が生み出されているのか。レポート「Cadences」（2026 年 6 月 26 日）は、会話の 93% が何らかの成果物を生んでいるとしたうえで、仕事目的に絞った内訳を示しています。

「社員」に見立てられる根拠も同レポートにあります。比較された 31 種類の成果物のうち 26 種類で、Claude Code のほうがチャットよりも AI の自律性が高いという結果でした。ブログ記事の場合、チャットでは中央値で 13 往復のやり取りを要するのに対し、Claude Code のセッションは人間のプロンプト 1 回で完結しています。指示を出したら戻ってくるまで待つ、という働き方が成立しているわけです。

配属先の偏りも見ておきます。レポート「Learning curves」（2026 年 3 月 24 日）によると、Claude.ai の会話の 35% がコンピュータ・数学系職種のタスクである一方、上位 10 タスクが占める割合は 2025 年 11 月の 24% から 2026 年 2 月には 19% へ下がりました。用途が分散しているということは、定番の使い方だけを真似ても自分の業務には当たらないことを意味します。カタログから自分で選ぶ必要があるのは、このためです。

配属できる仕事の見分け方 — 3 つの型

カタログのどの行を選ぶかは、好みではなく「分離する構造的な理由があるか」で決まります。専任AIとして切り出す価値があるのは、次の 3 つの型のどれかに当てはまる仕事です。

この 3 つに当てはまらない仕事は、専任AIを作らずに本体で直接進めたほうが速くなります。判定の手順は次のとおりです。

1. その業務を自分で何回かこなしたことがあるか。無ければ配属しない
2. 合格基準を自分の言葉で書けるか。書けなければ配属しない
3. 3 つの型のどれに当てはまるか。当てはまらなければ配属しない
4. 失敗しても巻き戻せるか。巻き戻せないなら、最終判断だけ人間に残す形に設計し直す

2 番目がいちばん効きます。合格基準を書けない業務は、成果物が返ってきても良し悪しを判定できません。判定できない委譲は、品質が落ちていることに気づかないまま出力だけが積み上がる状態を作ります。役割の切り方をもう一段細かく設計したい場合は ルールとエージェントの設計術 を参照してください。

配属しない方がいい仕事

カタログを見ていると「これも任せられそうだ」と思う仕事が出てきますが、次の 3 つは配属先として向きません。むしろ配属したことで遅くなります。

1 行目は見落とされがちです。決まった時刻に決まった処理を走らせるだけなら、それは自動化の領域であって専任AIの仕事ではありません。判断が入らない手続きを AI に持たせると、コストと不確実性だけが増えます。

また、定型の手順が確立している仕事は、担当を作るよりも手順書として書いたほうが再現性が高くなります。担当として切り出すか、手順として書くかの判断は スキル・ループ・ワークフローの使い分け にまとめてあります。

増やしすぎると何が起きるか

定義ファイルは 1 枚数分で書けるので、カタログを見ると全部作りたくなります。ここで知っておきたいのは、仕様は「作りすぎ」を止めてくれないという点です。公式ドキュメントには次の 3 つが明記されています。

• 組み込みを除く担当の description の合計が 15,000 トークンを超えると、起動時に警告が表示される
• 同時に実行できるのは既定で 20 体まで（設定で変更可能）
• 1 セッションで生成できる総数に上限はない

つまり止めてくれるのは同時実行数だけで、定義の枚数はいくらでも増やせます。増えて効いてくるのは 1 つ目の警告です。担当が増えるほど「いつ呼ぶか」の説明文が積み上がり、上限に近づきます。公式は対処として説明文を短くし、詳細は各担当のシステムプロンプト側へ移すことを挙げています。そちらは実際に呼ばれたときにだけ読み込まれるためです。

コスト面の目安もあります。Anthropic のエンジニアリング記事「How we built our multi-agent research system」（2025 年 6 月 13 日時点の計測）によると、エージェントはチャットの約 4 倍、複数エージェント構成は約 15 倍のトークンを消費します。同記事は、全員が同じ文脈を共有する必要がある領域や、依存関係の多い領域は複数エージェント構成に向かないとも述べています。コーディングは調べものほど並列化できない、という指摘もあわせて出ています。

任せきりにできない理由も数字で出ています。Stack Overflow Developer Survey 2025（2025 年の調査）では、AI ツール利用者が挙げた最大の不満は「惜しいけれど正しくない出力」で 66%、次いで「AI が書いたコードのデバッグに時間がかかる」が 45% でした。カタログのどの職種にも、返ってきたものを人間が判定する工程が要ります。

配属の順序と、定義ファイルの書き方

カタログを手にしたあとの進め方を整理します。一覧を上から埋めるのではなく、次の順で 1 人ずつ増やしてください。

1. いま自分の時間をいちばん取っている業務を 1 つ挙げる
2. その業務の合格基準を、箇条書きで書き出す
3. カタログで対応する職種を探し、3 つの型のどれかに当てはまるか確認する
4. 組み込みの担当で足りないかを先に試す
5. 足りなければ定義ファイルを 1 枚書き、数回動かして差し戻し率を見る

どの順で着手するか、なぜ先に体制の図を描くと失敗するのかは 配属の順序を扱った記事 に詳しく書いています。フロントマターの各項目や外部接続の設定など、定義ファイルの具体的な書き方は Claude Code 上級編 が受け皿です。

よくある質問

AI社員の配属についてよくある質問をまとめました。

Q. AI社員とは何ですか？

Claude Code のサブエージェント機能を使い、業務ごとに専任のAIを定義して、その仕事だけを任せる運用の呼び方です。定義に必要なのは Markdown ファイル 1 枚で、公式仕様上の必須項目は名前と「いつ呼ぶか」の説明の 2 つだけです。

Q. サブエージェントは何体まで作れますか？

総数の上限はありません。公式ドキュメントが定めているのは、同時に実行できるのが既定で 20 体までという点と、説明文の合計が 15,000 トークンを超えると起動時に警告が出るという点です。「何体まで」ではなく「説明文が増えすぎていないか」を見るのが実務的です。

Q. どの職種から配属すればいいですか？

いま自分の時間をいちばん取っている業務に対応する職種からです。カタログを上から順に作る進め方は勧められません。合格基準を書けた業務が 1 つあれば、そこが最初の配属先になります。

Q. 自分でやったことのない業務も任せられますか？

試すのは自由ですが、実務投入は勧められません。合格基準を書けない業務は、返ってきた成果物の良し悪しを判定できないためです。最低でも自分で数回こなし、判定の基準を言葉にしてから配属してください。

Q. 担当を作るのと、手順書を書くのはどちらが良いですか？

手順が確立していて毎回同じ流れで進む仕事は、手順書として書いたほうが再現性が高くなります。担当として切り出す価値があるのは、読む量が多い、別の視点で検証したい、同じ形の作業が数多くある、のいずれかに当てはまる場合です。

Q. 職種ごとにモデルを変えられますか？

変えられます。公式仕様では定義ファイルの model で担当ごとに指定でき、本体と同じものを引き継ぐ設定も選べます。読む量が多いだけの作業と、判断の質が問われる検証とで使い分けると、費用と精度の折り合いがつけやすくなります。

まとめ

本記事の要点を整理します。

• AI社員の定義に必須なのは名前と「いつ呼ぶか」の説明だけで、作ること自体は簡単である
• 配属先の候補は調査・検証・制作・運用・分析の 5 系統に整理できる
• 切り出す価値があるのは、大量読み込み・独立検証・並列バッチのいずれかに当てはまる仕事だけ
• 決まりきった手続きは自動化へ、経験のない業務は自分で数回こなしてから
• 総数に上限はなく、増やしすぎを止めてくれるのは説明文の警告だけ
• 返ってきたものを判定する工程は、どの職種でも人間に残る

このカタログは、埋めるための表ではありません。自分の 1 週間を思い出して、いちばん時間を取られている業務に対応する行を 1 つ見つけてください。その 1 行が、最初に配属する職種です。

参考にした一次資料

• Anthropic「Create custom subagents」（2026 年 9 月 7 日確認）
• Anthropic Economic Index report: Economic primitives（2026 年 1 月 15 日）
• Anthropic Economic Index report: Learning curves（2026 年 3 月 24 日）
• Anthropic Economic Index report: Cadences（2026 年 6 月 26 日）
• Anthropic Engineering「How we built our multi-agent research system」（2025 年 6 月 13 日）
• Stack Overflow Developer Survey 2025（2025 年）

関連記事

• 「AI組織」は組織図から作ると失敗する｜1人会社をAI会社化する正しい順序
• Claude Codeのルール・エージェント設計術｜CLAUDE.mdとサブエージェント運用の実践知
• Claude Code上級編｜MCP・Hooks・Skills・サブエージェント実践ガイド
• Claude Codeのスキル・ループ・ワークフローの使い分け｜いつどれを使うか判断ガイド
• Claude CodeのMCP連携ガイド一覧｜Figma・WordPress・Chrome DevTools・Notion