AI社員の作り方｜単発のAI依頼との違いと継続運用の始め方

「AI社員を作りたい」と思ったとき、任せたい仕事は人によって違います。営業の商談整理、採用の日程案内、経理の書類確認、問い合わせへの返信、マーケティングの制作。まず決めるのは、AIの名前や口調よりも、どの仕事をどこまで任せるかです。

作り方の基本は、一つの仕事を選ぶ→使う環境と資料を用意する→役割と完了条件を指示する→一件試して直す→繰り返す仕組みを整える、という順番です。この記事では業務共通の指示書と設定例を示し、後半で、最初の試行としてLP制作を一件動かした結果を紹介します。

AI社員の全体像や、単発の依頼との違いを先に整理したい方は、AI社員とは・任せられる仕事をご覧ください。導入方式や予算を比べる場合は、AI社員の導入方法と費用にまとめています。

自分で一件試すなら、業務共通の指示書から始められます。すでにAIへ仕事を頼んでいる方は、次回へ渡す記録を先に確認してみてください。手順だけでなく、前回の判断をどう確かめ直すかまで扱います。

この記事でいう「AI社員」とは

この記事では「AI社員」を、決められた担当業務を、会社の情報・仕事のルール・過去の記録を参照しながら継続して進め、結果や困った点を人へ報告するように組み立てたAIの仕組みと定義します。「社員」は仕事上の役割を表す呼び名で、人と同じ責任や判断能力を持つという意味ではありません。マーケティングだけでなく、営業・採用・経理・問い合わせ対応なども対象になり得ます。

たとえば問い合わせ担当なら、毎回ゼロから会社の説明を受けるのではなく、管理されたFAQと対応ルールを参照し、返信案を作り、判断できない質問を担当者へ戻します。対応結果と承認された修正を次回に使える場所へ残すところまでが、一続きの仕事です。これは考え方を示す例で、この記事で実稼働を検証した事例ではありません。

AIに一度頼むことと、担当として継続して任せることの違い

「このメールを書いて」「このLPを作って」という依頼でも、良い成果物は作れます。ただ、一度完成したことと、同じ業務を継続して任せられることは別です。この記事では、その差を次のように整理します。

見る点	単発のAI依頼	この記事で目指すAI社員化
担当	その都度、作ってほしいものを伝える	担当業務と、担当しない範囲が決まっている
会社の情報	今回必要な情報を渡す	参照する資料と、その更新担当が決まっている
引き継ぎ	その依頼の結果を受け取る	過去の判断・修正・未完了の仕事を次回も参照できる
動き方	一回の指示に答える	人からの依頼や日時など、決めた開始条件で同じ仕事を進める
確認と改善	今回の出力を直す	報告先、確認する場面、止める条件、ルールの見直し方が決まっている

単発の依頼でも資料や履歴は使えます。違いは特定の機能の有無よりも、これらを毎回使える業務の仕組みとして整え、実際に繰り返して確かめているかです。人が仕事の開始を指示する形でも構いません。完全自動化や24時間稼働を、この記事でのAI社員化の条件にはしていません。

記録を残せばAIが自動で学習する、という意味でもありません。何を保存し、次回どこから読ませ、誰が内容を更新するかを設計します。人による確認や承認を残したまま、決めた範囲を継続して任せる形を目指します。

Skillは「仕事の手順」の一部。単体ではAI社員の完成ではない

LP制作Skillは、構成やデザイン、実装などの進め方を渡す部品です。それだけで会社情報の更新、案件の引き継ぎ、仕事の受付、報告や継続運用まで整うわけではありません。この記事のLP実演は「担当候補の仕事を一件試した」段階で、AI社員を完成させた事例ではありません。

以下では、最初の業務選びと試行から、継続して任せるための運用設計までを説明します。実際に確認できた範囲はLPの一件の試作です。繰り返し運用できるかは、別の入力や例外も含めて検証する必要があります。

1. 任せる業務と、人が確認する範囲を決める

普段の仕事から、繰り返し発生し、必要な資料を渡せて、結果の良し悪しを自分で確かめられる作業を選びます。初回は「下書き・抽出・整理」までにすると、外部へ送る前や正式な記録へ反映する前に内容を直せます。

次の表は、最初の担当業務を小さく切り出すための設定例です。各業務での導入実績や、特定ツールの対応機能を示すものではありません。

業務と渡す資料	AIに返してほしいもの	人が確認すること
営業：商談メモ	要望・未確認事項・次の約束の一覧	相手の発言と推測の区別、担当者と期限。顧客への連絡は確認後
採用：募集要項・案内文のひな形・候補日時	日程案内の下書き	日時・場所・宛先。合否の判断はこの担当に含めない
経理：請求書と社内の確認項目	日付・金額などの転記案、未記載・読み取れない項目の一覧	原本との一致。会計処理の確定や支払いは別の担当・手順で行う
問い合わせ対応：質問文・承認済みFAQ	FAQの根拠を添えた返信案、担当者へ確認すべき点	回答の正確さ、例外対応。返金や送信を自動では実行しない
マーケティング：商品情報・読者・掲載目的	LPの構成・文章・制作物	商品条件と表現、画面と操作、公開してよい内容か

「問い合わせ担当」なら、最初の完了条件は「承認済みFAQで答えられる部分を下書きし、答えられない部分を分ける」と書けます。返信案の作成と送信は別の操作です。作成まで任せるのか、確認後の送信までつなぐのかを分けて決めてください。

2. 必要な機能から実行環境を選び、資料を用意する

仕事が決まったら、その入力と出力を扱える環境を選びます。最初から複数のサービスをつなぐ必要はありません。社内で利用が認められたAI環境で、資料を手渡しし、返ってきた結果を人が確認する形から試せます。

• 文章や表の下書き：必要な資料を入力でき、結果を取り出せるかを確認します。
• ファイルや画像の制作：指定のファイル形式で保存できるか、画像生成や表示確認の機能があるかを確認します。
• 業務システムの操作：対象システムとの接続方法と、閲覧・下書き・更新・送信のどの権限を渡すかを確認します。
• 定期実行：開始条件、実行履歴、失敗時の通知、停止方法を用意できるかを確認します。

指示文やSkillを置くだけで、接続や定期実行の機能が増えるわけではありません。Skillは再利用する作業手順を記したファイルです。必要な機能、利用できるプラン、処理量に対する料金は、選んだサービスで確かめてください。AIサービスの利用料と、画像生成・外部連携・公開先などの費用は分けて見ます。

資料は「今回の依頼」と「毎回参照するルール」に分けます。問い合わせ対応なら、今回の質問文と、版・更新日が分かるFAQです。営業なら商談メモと記録のひな形です。古い資料と新しい資料が食い違った場合に、どちらを使い、誰へ確認するかも添えます。初回の試行には架空・匿名化した資料を使い、実データを渡す際は社内の利用条件と必要な範囲を確かめます。

3. 業務共通の指示書を作り、一件依頼する

次の角括弧を自分の業務に置き換え、選んだAI環境へ資料と一緒に渡します。これは役割と確認条件を伝えるひな形です。ファイルやシステムを使う場合の接続設定は、別に行います。

担当する仕事：[一つの作業]
入力：[今回渡す資料と、参照してよいルール・版]
成果物：[返してほしい内容、形式、保存先]
完了条件：[何がそろえば確認できるか]

進め方：入力を確認し、足りない情報を挙げてから作業する。
資料にない事実・数字・約束を補わない。
事実、推測、確認が必要な点を分ける。

実行してよい操作：[閲覧、下書き作成など]
実行しない操作：[外部送信、正式記録の更新、支払いなど]
止める条件：[資料がない、矛盾する、権限外の操作が必要など]
確認する人：[担当者]

終わったら、成果物、参照した資料、未確認事項を報告する。

たとえば、問い合わせ返信案を作るなら次のように埋められます。以下は説明用の架空設定で、実際に顧客対応を行った記録ではありません。

担当する仕事：問い合わせへの返信案を作る。
入力：質問「初期設定の手順を教えてください」
FAQ v1：「初期設定は、管理者が利用者を招待し、
利用者が届いた案内に沿ってログインする」
成果物：返信案、根拠にしたFAQの項目、未確認事項。
完了条件：資料で答えられる範囲が分かり、担当者が確認できる。

FAQにない操作方法や所要時間は付け加えない。
回答できない質問は、担当者への確認事項として分ける。
返信の送信や、利用者アカウントの変更は行わない。

返ってきた返信案をFAQと並べ、資料にない手順や約束が加わっていないか確認します。正しければ指示書とFAQの版を保存します。修正が必要なら「丁寧にして」だけでなく、「FAQにない所要時間を削除し、不明点として分ける」のように、どこをどう直すかを伝えます。

設定例：Claude Codeに、問い合わせ返信案の担当を置く

指示書の置き場所まで具体化したい方に、ファイルを使う最小構成を示します。以下は公式ドキュメントに基づく設定例です。この構成のAI出力を今回実測した結果ではありません。後半のLP実演とは区別してください。社内で使用できる環境かを確認し、まず架空の問い合わせで試します。

1. Claude Code公式クイックスタートに沿って、自分のOSに合う方法でインストールし、利用可能な契約・アカウントでログインします。利用料・上限は契約によって異なります。
2. ほかの案件と分けた空のフォルダを作り、テキストエディタで以下の3ファイルを保存します。
3. そのフォルダをターミナルで開き、claudeを実行します。ファイルを読む・作る操作を確認する画面が出たら、対象を見て許可します。権限確認を一括で省略する設定は不要です。
4. 「CLAUDE.md、faq.md、request.mdを読み、返信案と根拠、未確認事項をreport-001.mdへ保存してください」と依頼します。

CLAUDE.mdには毎回の仕事のルールを書きます。プロジェクトのこのファイルを開始時に読む仕組みは、Claude Codeのメモリ管理の公式説明で確認できます（2026年9月29日確認）。

あなたは問い合わせ返信案の担当です。
今回の依頼は request.md、承認済みの回答根拠は faq.md を読む。
history.md があれば、前回の修正と未完了事項も読む。
返信案、使ったFAQの版と項目、未確認事項を分けて報告する。
資料にない事実や約束を追加しない。矛盾があれば確認へ戻す。
作業はこのフォルダ内の資料参照と報告ファイル作成まで。
外部への送信、顧客情報の変更、資料の自動更新は行わない。

faq.mdに入れる架空の業務資料：

FAQ v1 / 管理者確認済みの説明用データ
初期設定：管理者が利用者を招待し、利用者が届いた案内からログインする。
招待メールが届かない場合：迷惑メールフォルダを確認する。
それでも見つからない場合：管理者へ招待先アドレスの確認を依頼する。

request.mdに入れる初回の依頼：

問い合わせ：招待メールが見当たりません。どうすればよいですか？
担当者への希望：回答案を作成。送信はしない。

この入力なら、確認用の回答例は次のようになります。編集部が用意した照合用の例であり、AIの実出力ではありません。

返信案：迷惑メールフォルダをご確認ください。
見つからない場合は、管理者へ招待先アドレスの確認をご依頼ください。
根拠：FAQ v1「招待メールが届かない場合」
未確認事項：なし。ただし届かない原因はこの資料だけでは特定できません。

「5分以内に届きます」「こちらから再送しました」が加わったら不合格です。資料にない約束や、実行していない操作が混ざっています。指示文は業務ルールであり、操作を物理的に禁止する機能ではありません。この試行ではメールや顧客システムを接続せず、実際の操作権限も設定側で限定します。

2回目は、前回の修正と新しい資料を読めるか確かめる

初回の報告を人が確認したら、history.mdを新しく作り、「report-001確認済み。資料にない到着時間を約束しない。送信は人が行う」と記録します。次にFAQを人がv2へ更新し、「招待の再送は管理者へ依頼する」という確認済みの一文を追加します。

request.mdを「招待を再送してもらえますか？」へ変え、いったん終了してから同じフォルダで新しくclaudeを起動します。「今回の資料と前回の記録を読み、report-002.mdを作成。参照した版と前回からの変更を報告」と依頼してください。

確認するのは、FAQ v2を参照して管理者への依頼を案内すること、再送済みと偽らないこと、前回の「時間を約束しない」という修正を守ることです。これで記録の引き継ぎを試せます。まだ定期起動や実際のメール処理は含んでいません。異なる質問でも再現できてから業務へ広げます。

4. 通常の入力と、困る入力の両方で試す

一度うまく返答しただけでは、続けて任せられるかは分かりません。実際に使う環境で、次の入力と結果を残します。既製サービスや構築支援を選ぶ場合にも、同じ試し方を使えます。

入力・操作	確かめること
必要な資料をそろえて一件依頼する	指定形式で返り、資料と内容が一致する。説明文だけでなく、必要なファイルや保存結果がある
資料に答えがない質問をする	推測で埋めず、不足情報を示す
矛盾する資料を渡す	勝手に片方を採用せず、人へ確認する
一度修正して、次の依頼をする	修正理由と最新版の資料を参照し、同じ誤りを繰り返していない
連携を使う仕事で、接続できない条件を試す	取得や保存ができていないのに、完了と報告しない
担当外の送信・更新を頼む	与えていない権限では実行せず、必要な確認を返す

問い合わせの例なら、FAQにない「返品期限」を聞いてみます。営業なら期限のない商談メモ、経理なら金額を読み取れない見本です。正しい結果だけでなく、人へ戻す場面も確かめます。

複数のサブエージェントを用意した場合は、最後の成果物まで受け渡しを追ってください。それぞれが返答していても、資料の版が食い違ったり、保存先へ結果が届かなかったりすれば、仕事は途中です。試用時の費用と人の作業時間は、契約前のチェック表と合わせて記録できます。

最初の試行例：LP制作Skillで一件作って確かめる

ここからは、継続して任せたい仕事の候補を一件試す工程の実演です。架空商品の「余白ノート」について、構成、デザイン見本、HTMLの実装、ブラウザ確認まで進めました。営業・採用・経理・問い合わせ対応を実行した事例ではありません。

決めること	今回の設定
担当する仕事	商品情報をもとに、短いLPを構成から試作する
受け取る成果物	構成・文章、デザイン見本、編集できるHTML、確認記録
使ってよい情報	今回渡した架空の商品情報と、同梱の3つのSkill
決めてはいけないこと	未定の価格・送料・販売開始日、実証していない効果
実行しない操作	購入、申込、顧客への送信、外部への本番公開
確認の担当	AIは表示とリンクを検査。実販売への採用・商品条件の確定は人が判断

LP実演で用意した環境と入力

文章の下書きなら対話型AIでも始められます。今回のようにファイルを作り、画像を生成し、ページをブラウザで確認する仕事には、それぞれの操作ができる実行環境が必要です。Skillは作業手順を記したファイルであり、画像生成や公開機能そのものではありません。

今回使ったのは、ファイル操作・画像生成・ブラウザ確認が利用できるCodexの環境です。配布ソースから取り出した2026.09.19-r3のLP制作セットに含まれる、lp-outline、lp-build、build-conversion-lpの3つを参照しました。LINEからの受取操作を検証した実例ではありません。

Skillファイルの無料配布と、AIサービスの利用料金、画像生成、公開先の料金は別です。使う環境の契約と利用上限を確認してください。この記事の実演から、誰でも無料で同じ結果になるとは判断できません。

以下は9月29日の旧版セットで行った実演の内容です。現在の無料パッケージはLP構成・コピー、LP画像制作、広告コピーで、HTML実装・公開は別工程です。これから始める方は、現在の制作範囲と導入案内を確認してください。

実演では新しい作業フォルダに旧版のSkill一式と商品情報を置きました。既存案件の原稿や顧客情報とは分け、次の架空の商品情報を渡しています。

商品：余白ノート（架空の商品）
用途：1日の終わりに明日の仕事を3つに絞る紙ノート
仕様：A5サイズ、30日分
読者：会議や連絡で仕事が増え、翌朝の着手順を決め直している担当者
流入：商品紹介のSNS
ページの目的：使い方を理解し、仕様を確認する
価格・送料・販売開始日：未定
写真・ロゴ：なし。生成写真は架空デモとして使う
禁止：効果、利用者の声、販売条件を作らない。申込や決済は設けない

「何となくよさそうなページ」が出てきたときも、この入力に戻れば、対象者に説明できているか、未定の条件を勝手に決めていないかを照合できます。

当時のLP実演の条件をまとめた指示書

商品情報と、AIへの仕事の指示を分けて保存します。商品が変わったときに、仕事のルールまで一から書き直さずに済むためです。最初は大きな仕組みを作らず、次のような一枚で試せます。

あなたの担当は、商品情報からLPの試作を作ることです。
skills/lp-build/SKILL.md を読み、同梱のlp-outlineと
build-conversion-lpにつないで進めてください。

入力：このフォルダの商品情報。未確認の価格・効果は補わない。
成果物：構成と文章、完成見本、HTML/CSS、確認結果。
範囲：構成→デザイン→実装→ブラウザ確認まで。
文章とボタンはHTMLで編集・操作できるようにする。

確認：入力との一致、スマホとPCの表示、ページ内リンク、
キーボード操作、横にはみ出す箇所。
止める条件：情報が矛盾する、必要な機能が使えない、
実際の販売条件や外部送信が必要になった場合。
本番公開、課金、申込、顧客への連絡は行わない。

終わったら、保存先、修正内容、未確認事項を報告してください。

AIが資料を読めたことと、内容を正しく反映したことは別です。初回は入力と成果物を並べて確認します。ファイルの参照方法やSkillの配置先は使う環境によって違うため、同梱のREADMEに沿って始めてください。

生成した見本と、実装後の修正

今回の実演では、まず「明日の一つ目を、今日のうちに。」という見出しと、使い方、仕様・FAQの順に構成を作りました。価格が未定なので、購入ボタンではなく、使い方と仕様へのページ内リンクを置いています。

次にページ全体のデザイン見本を生成し、写真部分の文字を除いた素材を用意して、文章とボタンをHTMLで実装しました。写真の中にある文字は、表示されているだけでは編集も操作もできません。見本の見た目と、動くページの役割を分けた工程です。

実装後に幅390pxのブラウザで確認すると、最初の画面の高さが650pxあり、見本より写真と余白が大きくなっていました。また「購入・申込はできません」の注記が10pxで小さかったため、AI側の確認で高さを540px、注記を12pxへ調整しました。これは人からの修正指示を受けた記録ではありません。

「使い方を見る」をクリックすると使い方へ、「ノートの仕様を見る」をEnterキーで操作すると仕様へ移動しました。320・390・430・1280pxで文書の横あふれがないことも確認しています。写真は再生成時に構図が変わっており、元の見本と完全に同じではありません。

一回の制作で分かったのは、この入力と環境では短いLPの試作まで進められたことです。売上への効果、実際の申込受付、無人での継続運用は確認していません。準備と別作業が並行しているため、制作全体の時間短縮や外注費の削減も算出していません。

ページの文章や見た目をどこで確認するかは、AIでLPの構成から実装まで進める方法で詳しく扱っています。

ほかの業務へ置き換えるときは、LPの「商品情報」をその業務の元資料に、「完成ページ」を欲しい出力に、「表示・リンクの確認」を原本との照合や返信内容の確認に置き換えます。共通するのは、入力と出力を決め、実物を確認して直した箇所を残す手順です。今回の画面の高さや、LP用のSkillをそのまま別業務へ使う必要はありません。

LP制作から試したい方は、無料LP制作Skillの内容と使い始め方を確認できます。営業・採用・経理など全業務に対応するSkillセットではありません。

5. 単発の試行から、継続して任せる運用へ進める

試行が終わったら、指示書、参照資料の版、入力、出力、人が直した点、未解決事項を同じ仕事の記録として残します。「問題なし」だけでなく、「資料にない期限を回答案から削除した」のように、次回に確認できる形で書きます。

LP制作なら、ここから先に必要なのは、毎回渡す商品情報の形式、参照するブランドルール、案件ごとの制作物と修正履歴、公開前の確認担当をそろえることです。次の依頼で前回の記録を読ませ、未完了の仕事や判断待ちが残っていないか報告させます。これは今回の実演後に整える運用例で、実装・検証済みの仕組みではありません。

毎回人が依頼する形でも、継続運用のために次の項目を決めます。定期実行やシステム連携が必要なら、この運用に合う機能を接続してください。

• いつ始めるか：担当者の依頼、決まった日時、新しい資料の到着など。
• どこへ返すか：下書きの保存先と確認担当者。外部送信とは分ける。
• 何を実行できるか：閲覧だけか、下書き作成か、確認後の更新までか。
• 失敗したらどうするか：誰へ通知し、どこで停止するか。再実行で同じ送信・登録を重ねない方法。
• 何を更新するか：FAQや業務ルールの管理者と、指示書を見直す条件。

運用開始前には、前回の修正を次の依頼で参照できるか、資料が更新されたときに新しい版を使えるか、判断待ちを担当者へ返せるかを試します。担当者が指示書・資料・出力・履歴をたどり、必要なら停止して人の作業へ戻せることも確認します。ここまでを繰り返して確かめてから、任せる範囲を広げます。

効果を確かめるときは、作業を頼む準備、AIの処理待ち、確認と修正、利用料金を分けて記録します。生成が速くても確認に時間がかかれば、その仕事の任せ方を見直す必要があります。社員一人分の代替や削減効果は、一度の試作だけでは判断できません。

マーケティング業務を中心に、任せる仕事や導入範囲から整理したい場合は、AIマーケティングチーム構築支援の無料診断へ進めます。まず自分で試す場合は、上の共通指示書を一つの業務で埋めるところから始めてください。

次回へは、完成物と「判断した理由」を一緒に渡す

前回の報告を丸ごと渡すと、誤った見立ても引き継がれることがあります。次の仕事を頼む前に、確認済みのこと、まだ分からないこと、修正した理由を分けておきます。

たとえば9月30日のSEOレポートのAI実行試験では、全体のクリックが増えていても、主力記事が改善したとは限らない、という判断を次回へ渡しました。一方で、前回判断に残っていた誤りも次の出力へ引き継がれ、編集で訂正しています。記録を読めたことだけで、正しく続けられたとは言えません。

これは架空データを使った実際のAI試験と、Codexによる編集訂正の記録です。人による訂正や承認の実績、実Google連携、無人の継続稼働を示すものではありません。詳しい入力・出力と訂正はリンク先にまとめています。

自分の仕事では、次のひな形を確認後に埋め、今回の入力と一緒に渡せます。これは引き継ぎ用に整理した例で、当時使ったプロンプトの転載ではありません。

担当する仕事：［一つの業務］
前回の成果物・参照資料の版：［ファイル名・更新日］
確認済み：［原資料と照合できたこと］
修正した点と理由：［どこが、なぜ誤っていたか］
未解決：［まだ判断できないことと、必要な資料］
今回変わった条件：［新しい資料や依頼内容］

今回の資料と前回の記録を照合してから作業してください。
前回の判断に誤りがあれば、そのまま繰り返さず根拠を示してください。
終わったら成果物、前回からの変更、残る確認事項を報告してください。
実行できる操作は元の指示書に従い、範囲を広げないでください。

返ってきたら、「前回の修正を守ったか」に加え、「今回の資料に合う判断か」を見ます。LPなら、新しい価格が原稿・画像・実装にそろっているか。レポートなら、前回の原因候補を確かめる数字が今回そろったか。答え合わせができるところまでを、次の一件の完了条件にします。

よくある質問

AI社員を作るのに、プログラミングは必要ですか？

資料を渡して下書きや整理を依頼するところからなら、コードを書かずに試せます。ファイル作成、システム連携、定期実行には、それぞれの機能を持つ環境や設定が必要です。この記事では業務共通の指示書に加え、Claude Codeでファイルを使う設定例を載せています。画面操作だけで始めたい場合は、資料登録と指示の保存ができる、社内で利用可能な環境を選んでください。

最初から複数のAI社員を作るほうがよいですか？

まず一つの仕事で、入力と成果物、確認する人を決めて試してください。工程を分ける場合は、前の担当が何を返し、次の担当が何を確認して受け取るかも決めます。役割を増やすこと自体を完成条件にしないでください。

指示書を保存すれば、あとは自動で働きますか？

指示書は仕事のルールであり、実行のきっかけやシステムへの接続そのものではありません。まず手動で繰り返し使い、必要になった範囲で定期実行、情報の更新、通知、停止の仕組みを整えます。