非エンジニアがClaude Codeで「AI社員5人の会社」を建てた全記録 — 実ファイル9本・全文コピペ可

はじめに — この記事が約束すること/絶対に約束しないこと

先に、いちばん大事なことを書きます。

この記事で紹介する仕組みで、私はまだ1円も売れていません。

2026年9月19日に1本目の商品をTipsで公開しました。価格は500円。 2026年9月20日現在、販売数は0件です。公開した翌日なので、当然といえば当然です。

普通なら隠します。「AIで自動化したら売れました」と書いたほうが、この記事は売れるでしょう。 でも隠しません。理由は2つあります。

1つ目。この記事が売っているのは売上の再現ではなく、仕組みの再現だからです。 「AIに企画を立てさせ、書かせ、校閲させ、販売文まで作らせて、出荷する」という工場は、 実際に建って、実際に動いて、実際に1本出荷しました。その工場の設計図を、ファイル全文でお渡しします。 売れるかどうかは、工場の性能ではなく、そこに入れる原料(あなたの経験)と、あなたが押す公開ボタンで決まります。

2つ目。売れる前の記録は、売れた後には二度と書けないからです。 うまくいった人の記事は世の中に大量にあります。でもそこには「作っている途中に何が壊れたか」が残っていません。 私はいま、壊れた場所を全部覚えています。AIが嘘を書いた話も、AIがそれを見つけた話も、同じAIが同じ嘘を2回書いた話も、全部そのまま載せます。

この記事が約束すること

この記事が絶対に約束しないこと

誰のための記事か

逆に、すでにAIエージェントを自分で組めるエンジニアの方には不要です。 この記事の価値は、技術の高度さではなく「コードを書けない人間が、実際に建てて、実際に出荷した」という一点にあります。

第1章 私は、1行もコードを書いていません

自己紹介をします。

私はキャンプ場で働いています。場内カフェの運営と、法人向けの食事提供を担当しています。 その前はプリンスホテルでサービス業務、スターバックスでの勤務。 派遣会社の社員として、フォークリフトに乗り、水道管を直し、アスファルトを舗装し、ゴーカートのサーキット場を作っていました。

エンジニアではありません。IT企業に勤めたこともありません。

私がやっている「AI寄り」の仕事は2つだけです。 ひとつは、職場の店頭POPをAI画像生成(Midjourney / ChatGPT)で作っていること。 もうひとつは、AIを使って一人当たりの提供数量を算出し、フードロス率をほぼゼロにしたことです。 どちらも「現場の道具としてAIを使っている」だけで、作る側の知識はありません。

この記事でやったこと=日本語のファイルを置いただけ

これから紹介する「会社」は、プログラムではありません。中身は全部、日本語で書かれたテキストファイル(Markdown)です。

やったことを正確に書くと、こうです。

以上です。書いたのは日本語の文章だけで、プログラムは1文字もありません。 .md というのはメモ帳で書けるテキストファイルの拡張子で、中身は見出しと箇条書きと表だけです。

なぜこれで動くのか。Claude Codeは、開いたフォルダの中にある CLAUDE.md を毎回自動で読むようにできています。 つまり CLAUDE.md は「出社したら必ず読む社内規程」です。ここに「あなたは会社の一員です」「公開は社長の承認が要ります」と日本語で書いておくと、そのとおりに振る舞います。

同じ理屈で、.claude/agents/ に置いたファイルは「その部門の社員の職務記述書」、 .claude/skills/ に置いたファイルは「定型業務の手順書」になります。

難しいのは技術ではなく、「自分の会社のルールを、人に伝わる日本語で書けるかどうか」です。 そしてそれは、現場で新人に仕事を教えたことがある人なら、たいてい書けます。私も現場では、教えたり教わったりしながら働いてきました。

第2章 「AI社員を雇う」の正体は、3種類のテキストファイルです

もう少しだけ、仕組みの話をします。ここを理解しておくと、第4章以降のファイルが「なぜこう書いてあるのか」まで分かります。

会社イケピは、3階建てです。

1階:憲法(CLAUDE.md)— 全員が必ず読むもの

会社の名前、事業内容、組織図、業務フロー、そして「鉄の掟」を書いたファイル。 Claude Codeはこのフォルダで動くとき、毎回これを読んでから仕事を始めます。

ここに書くべきは、やることよりも「絶対にやってはいけないこと」です。 私の会社の鉄の掟は4つですが、いちばん重要なのは1行目です。

社長の承認なしに外部公開(記事公開・SNS投稿)をしない。下書きまでは自律で進めてよい

これは「AIを信用していないから」ではありません。自律の範囲を明確にするためです。 「どこまで勝手にやっていいか」が決まっていないと、AIは遠慮して何もしないか、行き過ぎるかのどちらかになります。 「下書きまでは勝手にやっていい。公開ボタンだけは人間」と線を引くと、安心して全力で任せられます。

2階:社員(.claude/agents/ の5ファイル)— 呼ぶと出てくる専門家

Claude Codeには「サブエージェント」という仕組みがあります。 .claude/agents/ にファイルを置くと、それ専用の人格・ツール・禁止事項を持った担当者が作れます。

会社イケピの5人はこうです。

そして、あなたが普段話している画面(メインのセッション)は編集長です。 編集長が全体を見て、「これはリサーチ部の仕事だな」と判断して各部門に振ります。

ここが最大のポイントなのですが、部門を分ける意味は「頭が5個になる」ことではありません。 利害を分けることです。

書いた本人に校閲させると、どうしても甘くなります。 だから品質管理部の定義ファイルには、わざわざこう書いてあります。

## 禁止事項
- 本文を勝手に書き換えること(修正はwriterまたは社長が行う。あなたは指摘に徹する)
- 忖度した甘い評価

この2行があるかないかで、返ってくるレビューの厳しさが変わります。実際、この品質管理部は自社の商品を2回突き返してきました(第8章)。

3階:業務マニュアル(.claude/skills/ の3ファイル)— 手順の固定

毎回同じことを説明するのが面倒な定型業務を、手順書として置いておく仕組みです。 チャットで /スキル名 と打つか、普通の日本語で頼むだけで発動します。

エージェント(社員)とスキル(手順書)の違いは、「誰が」と「どうやって」の違いです。 社員だけだと毎回やり方がブレます。手順書だけだと担当者の専門性が出ません。両方要ります。

第3章 会社の見取り図 — 中核は9ファイルです

いま実際に動いている会社の構造を、そのまま出します。

goodbetter-ai-lab/                     ← 会社(ただのフォルダ)
├── CLAUDE.md                          ← ① 憲法(全員が毎回読む)
├── .claude/
│   ├── agents/                        ← ② 社員(サブエージェント)
│   │   ├── researcher.md                  リサーチ部
│   │   ├── writer.md                      コンテンツ制作部
│   │   ├── marketer.md                    マーケティング部
│   │   ├── reviewer.md                    品質管理部
│   │   └── analyst.md                     売上分析部
│   └── skills/                        ← ③ 業務マニュアル
│       ├── new-product/SKILL.md           新商品開発パイプライン
│       ├── tips-publish/SKILL.md          公開ワークフロー
│       └── weekly-report/SKILL.md         週次売上レポート
└── docs/                              ← 会社の資産(成果物の置き場)
    ├── company/                           運用マニュアル・接続手順
    └── content/
        ├── research/                      調査結果 + 素材メモ
        ├── drafts/                        下書き
        ├── marketing/                     タイトル案・販売文
        ├── reviews/                       校閲結果
        └── sales/                         販売履歴・売上レポート

会社の本体は、上の9ファイルです。docs/ は社員が働いた結果が溜まっていく倉庫なので、最初は空のフォルダでかまいません。

この構造で大事なのは「置き場所を先に決めてある」こと

見落とされがちですが、ここが効きます。

各部門の定義ファイルには、成果物の保存先が書き込んであります。 リサーチ部は docs/content/research/ に、制作部は docs/content/drafts/ に、というふうに。

これをやっておくと、何が起きるか。調べた結果・書いた下書き・受けたダメ出しが、全部ファイルとして残ります。 そして次に仕事を頼んだとき、社員は過去のファイルを読んでから始めます。

つまり、会社に記憶が溜まります。

会話は消えますが、ファイルは消えません。 私が「素材メモ」というファイルに自分の職歴と実績を書いておいたおかげで、 リサーチ部は「社長の実体験で書けない企画は提案しない」という判断ができるようになり、 品質管理部は「これは素材メモに書いていないから捏造だ」と指摘できるようになりました(第8章)。

AI社員の賢さは、モデルの性能より「何を読ませてあるか」で決まります。

ここまでが無料部分です

ここから先は、実際に動いているファイルを全文そのまま載せます。 コピーして、自分の仕事に合わせて名前と業種を書き換えれば、あなたの会社になります。

あわせて、うまくいかなかった3つの出来事も、社内の実物(レビュー結果・調査結果)を引用しながら書きます。 正直なところ、有料部分の本当の価値は失敗のほうだと思っています。ファイルは形をコピーできますが、失敗は先に知っておかないと必ず自分で踏むからです。