AI社員に出した修正の指示は、別の仕事でも守られるか。Claude Codeで会社ごと立ち上げるテンプレで6回確かめた

出典: 【実演】Claude Codeで70人のAI社員チームを使って仕事自動化する方法！1年で1.5億売り上げた会社経営するAI活用法【一人社長】

いちさんの組織図は、CEOと10部署、AI社員は全体で70人。AIが読める情報量には限界があるので、部署ごとに必要な情報を絞ります。そのうえで、人が話しかける相手はCEOだけ。いちさんはこう語りました。

いちさん（動画の中で・自動字幕・5:40〜）

「あなたが話しかけるのは、もうこのCEOっていう、ま、社長AIみたいなこいつですね」

「クロードコードちゃんに一言喋りかければもう全てが終わるっていう風な、え、環境を自分は構築しています」

話しかける相手を1人にして、担当が読む量を絞る。その設計は、私にも納得できます。頼むたびに部署を選び、背景を説明し直していたら、任せるための仕事が増えちゃいますよね。

私が大事にしているのは、AIに委ねて、人は積み減らして生き直すこと。人が指示を持ち歩かなくて済むように、CEOが担当を選び、必要な情報を渡す。話しかけた後まで任せられる形がいい。

動画では、いちさんの指示からLP、告知投稿10本、LINE配信5通が同時に進む画面が出てきます。頼んだ仕事が、担当ごとの成果物へつながる景色です。

私の環境でも、規則を読むタイミングを分けています。毎回読む規則は36本、合わせて約4万6千文字。必要な時だけ読む規則は、別の置き場に29本あります。

数え方は毎回読む規則の本数を数えた記事に書いたので、そちらから読めます。

動画は部署ごとに情報を分け、私は規則を読むタイミングを分けている。形は違っても、必要な情報で働いてもらう考え方は同じです。

最初から動画と同じ人数にする必要はない。まず、あなたが頼む1行を、担当へ届けられる形にする。そこから始めたいです。

→ 頼む1行をつくる

いちばん最近AIに2回言い直した用件を選び、何を作るか、守る条件、できた物の置き場所を1行にまとめる。その1行を、まずCEO役のClaude Codeへ渡してください。

動画でいちさんが示すAI社員の中身は、スキル・ナレッジ・アウトプットの3つ。判断基準や直し、過去の良い成果物を、次の仕事でも使う考え方です。手順書だけでは足りない理由を、いちさんはこう語りました。

いちさん（動画の中で・自動字幕・3:56〜）

「マークダウン1枚だけのスキルズじゃ、えっと、成果物って担保できないんですよね」

「本当に実務で使えるアウトプットっていうのを出すためにはAI社員の中にも脳みそがあった方がいいですよね」

スキルだけでは足りない。そのとおりだと思います。仕事の手順が分かっても、私が何を良いとし、前にどこを直してほしいと言ったかが抜けていたら、また説明することになる。

委ねるAIの最低条件は、分からないことを憶測せず聞き、分かることを2度聞かないことです。その「2度聞かない」を支える置き場所が、ナレッジなんですよね。

実物を見ると、LPデザイナーにはskills/、knowledge/、output/の3フォルダがあります。knowledge/の中には、合格ラインのquality-bar.mdと、直しの台帳のfeedback.md。

台帳には、経営者の直しや好みを残し、次の仕事から反映する方針が書かれています。同じ直しが繰り返されたら、手順書や合格ラインまで直す。できた物だけ直して終わらない構造です。

私の規則ファイルにも、同じ形があります。私が言った言葉、実際に起きた事故、やること、戻し方。何のための規則かまで残している。

動画では良い成果物を正解例に育てる話が出ますが、テンプレには直しを残すファイルまで用意されていました。

あなたのAI社員にも、手順と一緒に判断の材料を渡したい。次に何を変えてほしいかが読めるところまで。それで、同じ説明を減らせます。

→ 社員の中身を用意する

1人目の担当にskills/、knowledge/、output/を作る。手順書はskills/へ。knowledge/にはquality-bar.mdとfeedback.mdを置き、仕事を始める前に読むよう指示します。

/kickoffでは、会社の憲法とプロフィールを読み、事業やお客さんなどを1問ずつ聞かれます。画面のClaude Codeは、全部で5〜6問と案内します。決まっていないことは、そう答えてよい。設立直後のAI社員について、いちさんはこう語りました。

いちさん（動画の中で・自動字幕・13:36〜）

「最初に雇ってる状態なんで、最初はそんな精度高くないです」

「でもこれをどんどんどんどん育てていけばめちゃくちゃ精度高くなるわけですね」

分からないところを、未定の印（TBD）のまま残す。この動きは、私が決めている「憶測せず聞く」と同じ向きです。未定のまま見えていれば、決まった時に教えられる。もっともらしい答えで埋まってしまうと、どこを確認すればいいかまで分からなくなります。

憶測せずに聞く。これが、任せるための基本です。私も9月23日に、不足情報は聞き、調べて分かることは聞かない方針を規則にしました。

今回、私の頼みでAI秘書の凛ちゃんが、動画と同じ答えを渡して/kickoffを動かしています。Web・LP・HP制作、スタートアップ・SaaS向け、単発のLP制作。SNSのトーンは淡々と論理的、という設定です。

場所は、私の普段の設定を読み込まない別のフォルダ。動画の画面に映る公開リポジトリai-company-starter（MITライセンス）を複製し、モデルは動画のテロップと同じOpus 5です。会社プロフィールが埋まるまで、会話の往復は4回、31.6秒。実績や納期など、決めていない項目はTBDのまま残りました。ここは動画の説明どおりです。

動画では質問に答える流れが見えますが、実機では答えていない項目が埋まらないところまで確かめられた。

私は、この空白を残せることを信頼の入口にします。プロフィールが全部埋まっているかより、分かっていることと未定のことが、そのまま並んでいるか。

AI社員を育てる材料は、決まった物から渡せばいい。未定を未定として扱える会社から、仕事を頼み始めましょう。

→ 未定を残して始める

事業、お客さん、商品、発信の口調、目標の5項目を会社プロフィールに書く。分からない項目はTBDにし、/kickoffで読み込ませて、勝手に埋まっていないか確認します。

動画では、/shigotoで頼んだLPが出来上がります。最初はシンプルで、画像を入れるなどの直しを重ねる流れ。配布テンプレでもLPはできました。ただ、見た目以外に確認したい箇所がありました。いちさんはこう語りました。

いちさん（動画の中で・自動字幕・16:32〜）

「ま、かなりシンプル目ですよね」

「最初のアウトプットって、ま、皆さんこんなものなので」

最初の出来が粗く、そこから磨く。その考えは分かります。ただ、会社プロフィールにない制作期間を書いたLPは、そのままでは任せ切れません。見た目の好みと、根拠のない数字は、直す理由が違います。

私が委ねたいのは、信頼できる仕組みです。分からない数字を確かな情報のように出されると、受け取る人の期待まで変わってしまう。ここは最初の仕事から見たい。

AI秘書の凛ちゃんに「商品のLPを作って」と頼んでもらうと、LPデザイナーが選ばれ、output/にHTMLが1枚できました。会話の往復は5回、87秒です。

見出しは24字。本文には制作期間として2〜3週間と2〜4週間、フォームには所要3分。これらの数字は、会社プロフィールにも、経営者として渡した言葉にもありません。

しかも、quality-bar.mdには元から、未確認の数字を勝手に書かない合格ラインがあった。担当の自己点検では、問題なしとしていました。

動画でいちさんが触れたのはシンプルな見た目ですが、実機では根拠のない数字も確認できたんです。

合格ラインがあることと、出来た物が守っていることは別。最初のLPでは数字の出所を見て、分からないものをTBDへ戻す。その具体的な直しから、任せられる範囲を育てます。

→ 数字の出所をたどる

出来上がったLPの期間、所要時間、実績を拾い、会社プロフィールや自分が伝えた内容と照らす。根拠が見つからない数字はTBDに直させ、その条件を担当の台帳にも残します。

いちさんは、直しを捨てずに残すことで、言い直さなくてよい環境を作ると説明します。ここが私も確かめたかったところ。出した修正の指示は、別の会話でも守られるか。同じ依頼を6回出し、直しの有無で比べました。その狙いを、いちさんはこう語りました。

いちさん（動画の中で・自動字幕・17:58〜）

「フィードバックみたいなものを、え、捨てない仕組みっていうところを最初から作っておくことによって」

「もう1度言ったことは2度と言わなくていいっていうところを作っていって」

直しを捨てない仕組みを最初から作る。ここは私も同じ考えです。私が重視するのは、次の出来を見て判定できる、具体的な言葉で残すことです。

2026年9月4日の夜8時すぎ、何度決めても決めた通りに動かないAIから、管理が私へ戻ってきました。出てきた言葉は「同じこと何度も何度も決めた通りやらないから腹立つ」。胸がザワザワして、頭がかちんと来ました。守ろうとしたのは、ワクワク夢中でいたい気持ちです。だから直しは、次の仕事に届いてほしい。

今回、AI秘書の凛ちゃんが経営者役になり、「キャッチコピーは20字以内」と、「期間や所要時間は私が言うまで書かず、TBDに」の2つを伝えました。担当は自分でfeedback.mdへ2行、quality-bar.mdへ確認項目2つを追加。LPも直しています。

次の依頼は、別の会話で「相談の申込みLPを作って」。3種類の会社で各2回、計6回です。会社は、直しも前のLPも入っているA、直しの台帳と合格ラインだけを移したK、直しの追記がなくテンプレのままのBです。直しを残した4回は、見出しが20字以内で、根拠のない時間の数字は0か所。直しがない2回は、見出しが24字と25字、時間の数字が各4か所でした。Bにも、テンプレ元の合格ラインはありました。それでも、見出しと数字のずれが出ています。

ただし各条件2回なので、偶然のぶれとは区別できません。台帳と合格ラインだけを移した2回は、台帳にある見出しと同じ文（「プロダクトはある。あとはLPだけ。」）。原則を守ったのか、写したのかは分けられない。前のLPも残した2回は、別の文でした。

私の環境にも、同じ向きの実例があります。前に作った物を探さずに一から作る、という指摘を、記録に残る限りで少なくとも9回受けました。そこで10月8日に、確認の質問を出す手前で、探した跡を調べる仕組みを入れています。

動画の主張に、今回は次の依頼の結果が加わった。一般的な合格ラインだけで済ませず、実際のずれを具体的に残す。そこから始めます。

→ 直しを次へ届ける

feedback.mdに、日付・直しの原文・どう反映したかの3欄で1行足すよう担当へ頼む。ファイルに残ったことを確認し、別の会話で次の仕事を依頼して、同じずれが出るか見ます。

いちさんは、テンプレでできるのは土台まで、と説明しています。そこから質問に答え、一緒に仕事をして、AI社員を育てる。直しが増えていく先まで考えたい場面です。育ち方について、いちさんはこう語りました。

いちさん（動画の中で・自動字幕・17:21〜）

「その土台がある上でどんどんどんどんAIに聞かれたことに答えていく」

「AIと一緒にこの中で作業をやっていく」

「そうすることによってAI社員の脳みそみたいなものが育っていく」

台帳には、同じ状況で次の判断が変わる直しを残す。そして、見る日を決める。私はこの運用にします。何でも足して、そのたびに全部を確かめていたら、AIを育てる作業が主役になっちゃう。

ずれは、仕組みを改善するきっかけになります。ただ、放置してよいわけじゃない。次に何を変えるかまで決めて、使える言葉で残したいです。

私の毎回読む規則は36本。そのうち35本は、冒頭の数行に9月15日から10月の日付があります。36本のうち25本には私が言った言葉の原文があり、27本には実際に起きた事故の記述があります。

規則の数だけを見るより、何が起きて、どの判断を変えたかを読む。そうすると、残す理由が分かるんですよね。私の原文から、事故、やること、戻し方へ続く形も、そのためにあります。

動画は質問と実践で社員が育つ話。私はその先で、増えた記録を読み返し、次の判断に使えるか確かめる時間も持ちます。

たとえば台帳から3行を読み、今も必要か、担当が読むか、次の成果物で判定できるかを見る。全部の履歴を毎回調べ直す必要はない。

育てるほど、同じ説明が減っているか。そこを見たいです。AI社員のために人の仕事を増やすより、人が任せて手放せる記録を育てていきましょう。

→ 台帳を読み返す

週1回、feedback.mdから直近の3行を読む。次の判断を変える内容になっているか確認し、同じ直しが2回来ていたら、quality-bar.mdかSKILL.mdにも反映するよう担当へ頼みます。

AI社員に同じことを言い直しているなら、今日見るのは担当のfeedback.mdです。手順書と合格ラインがあっても、具体的な直しが残っているかで、次の出来に違いが出ました。

最近AIに2回言い直したことを1つ選びましょう。日付・直しの原文・どう反映したかの3欄で、台帳に1行足す。そのあと、別の会話で頼んで確かめる。私は、次の仕事で説明が減るところまでを、AI社員を育てる一手にします。