2026 年 9 月 23 日、100 本目のプロジェクトを始めました。
仕事の中で思いついたことを、AI エージェントと一緒に形にする。小さく試し、必要なものに手を入れ、その経験を次のプロジェクトへつなぐ。そうして始めたプロジェクトが 100 本になりました。
この特集では、その広がりと、開発を続けるために整えてきた指示書や仕組みを、記録と振り返りから紹介します。記録から分かることと、私の解釈とは分けて書きます。
この特集は 8 回で、毎週 1 本ずつ出します。対象は最初の 100 本です（数字は 9 月 25 日時点。そのあとに始めたものは含めません）。各回の最後には、振り返り（こうすればよかったこと、一般的なやり方と比べて、次に試すこと）を置きます。
第 0 回の今回は全体の地図です。何を「1 本」と数えたのか。どう増えたのか。いくつが動いていて、いくつを公開しているのか。
図の44本と6本は、100本をそれぞれ「更新」「公開」の切り口で見た数字です。足し合わせる内訳ではありません。また、分類上の「自社サービス12本」と「このLabの公開実演6本」は別の集計です。更新の有無は実稼働を示すものではなく、詳しい定義は以下で説明します。
1 本の数え方
作業フォルダの直下にあるフォルダ 1 つを、1 本と数えています。
中身はさまざまです。
- 半日で終わった下見
- 支援先と一緒に回している実証
- 社内の経理や勤怠の道具
- 個人・ファミリー向けのもの
大きさはそろっていません。それでも、「新しく始めるときにフォルダを 1 つ作る」という習慣だけは 8 か月変わっていません。この数え方がいちばん実態に近いと考えています。
GitHub のリポジトリ数で数えない理由もあります。100 本のうち 46 本は、リポジトリを作っていないフォルダです（試作や資料づくりなど）。GitHub で数えると、規模を半分近く小さく見せてしまいます。
増え方
最初の 2 本は 2025 年の秋に始めています。本格的に増えたのは 2026 年 2 月からです。
| 月 | 始めた数 | 累計 |
|---|---|---|
| 2025 年 10〜11 月 | 2 | 2 |
| 2026 年 2 月 | 13 | 15 |
| 3 月 | 17 | 32 |
| 4 月 | 16 | 48 |
| 5 月 | 15 | 63 |
| 6 月 | 13 | 76 |
| 7 月 | 12 | 88 |
| 8 月 | 7 | 95 |
| 9 月（23 日まで） | 5 | 100 |
2026 年に入ってからの 98 本は、およそ 2.7 日に 1 本のペースです。多い週は 1 週間に 8 本を始めました（3 月の第 1 週）。1 日で 4 本始めた日もあります（4 月 10 日）。曜日で見ると水曜日が 25 本でいちばん多く、火曜日は 7 本でいちばん少ない。理由はまだわかりません。
いま動いている数
「始めた数」だけでは、作っては放り出しているのか、回し続けているのかがわかりません。そこで、最後に手を入れた日も数えました。最後のコミットか、ファイルを最後に更新した日のうち、新しいほうです。
| 最後に手を入れた日 | 本数 |
|---|---|
| この 7 日以内 | 15 |
| この 30 日以内 | 44 |
| この 90 日以内 | 59 |
| 90 日以上前 | 41 |
直近 30 日に更新を確認できたのは 44 本、100 本の半分近くでした。ここで数えているのは「ファイルやコミットの更新があったか」です。使われているかどうか（実際に動いているか）は、この数字からは分かりません。更新のない道具でも毎日使われているものはありますし、更新があっても試作の段階のものもあります。
3 分の 1 は、3 日以内に更新が収まっている
始めた日から最後に手を入れた日までの長さも見ました。
- 作成から最終更新までが 3 日以内のもの: 34 本（全体の約 3 分の 1）
- 90 日を超えて続いているもの: 29 本。そのうち 25 本は、この 30 日にも手が入っている
- 150 日を超えて続いているもの: 18 本
34 本を形で見ると、14 本が資料・設計のフォルダ、10 本が Python の短い処理でした。短い期間に作業が集まり、そのあと更新がない、ということまでは記録から分かります。それぞれが何を確かめ、なぜそこで手を止めたのかは、記録には残っていません（これは振り返りで取り上げます）。
短い期間で終わるものが多くあり、長く手を入れ続けるものが一部にある。数えてみると、この形は思っていたよりはっきり出ていました。
「始める」から「育てる」へ
月ごとに並べると、この夏に形が変わっています。
| 月 | 始めた数 | コミット数 |
|---|---|---|
| 2026 年 2 月 | 13 | 28 |
| 3 月 | 17 | 132 |
| 4 月 | 16 | 290 |
| 5 月 | 15 | 508 |
| 6 月 | 13 | 496 |
| 7 月 | 12 | 507 |
| 8 月 | 7 | 756 |
| 9 月（25 日まで） | 5 | 900 |
※ コミット数は git で管理している 54 本の合計（9 月 25 日まで）
新しく始める数は 8 月から半分になりました。一方で、コミットは 8 月に 756、9 月は 25 日の時点で 900 まで増えています。始める数を減らし、すでにあるものに手を入れる量を増やしている、と読めます。
コミットの約 8 割（3,618 のうち 2,961）は、Claude との共同作業として記録されています。この数字の意味は、第 6 回で Claude 自身に書いてもらいます。
何を作ってきたか
100 本を、ざっくり 6 つに分けました（ひとつのフォルダが複数にまたがるときは、主な目的で分けています）。
| 分類 | 本数 | たとえば |
|---|---|---|
| 支援先との実証 | 35 | 業務の見える化、顧客管理、研修の課題づくり |
| 社内の業務・経営 | 25 | 秘書ダッシュボード、経費・給与、収支の見える化 |
| 公開している自社サービス | 12 | この Lab、まちスコア、カンパニー・ユニバース |
| 道具・基盤・下見 | 11 | 開発環境の整備、通信の設定、技術の下見 |
| 個人・ファミリー向け | 10 | 子ども向けの学習ゲーム、家庭向けの記録アプリ |
| 学び・研修 | 7 | 社員のラーニングハブ、研修の運営 |
いちばん多いのは、支援先と一緒に回している実証です。その次が、自分たちの会社の仕事を置き換える道具です。「AI で何か新しいものを作る」よりも、「いまある仕事を 1 つずつ置き換える」ほうに数が寄っています。この傾向は第 2 回で詳しく見ます。
公開しているのは 6 本
この Lab で実演として公開しているのは 6 本です。100 本の 6%にあたります。
少ないのには理由があります。
- 支援先との実証は、相手の業務やデータがそのまま入っているので、そのままでは出せない
- 社内の道具は、社員の情報を扱っている
- 個人・ファミリー向けのものは、利用者の生活に関わる情報を扱っている
- 短い期間で終えた試作は、公開するための形には整えていない
それでも数を隠さずに出すのは、公開している 6 本だけを見ると、実際のやり方を読み違えるからです。1 本の完成度を上げることよりも、たくさんの小さな試みを同時に回し続けることのほうが、ここでの仕事の大部分です。
AI エージェントだから、100 本を始められた
100 本という数は、私ひとりの手では始められませんでした。AI エージェントと仕事をして、変わったと思うことがあります。
まず、始めるのが軽くなりました。「こういう道具があったら」と思った日に、フォルダを作ってエージェントに頼めば、その日のうちに最初の形ができます。100 本という数は、この始めやすさがあって生まれました。
それから、並行して回せるようになりました。エージェントとの作業は、プロジェクトごとに別の会話（セッション）として進みます。1 つの会話がテストを走らせているあいだに、別の会話で別のプロジェクトの相談ができます。直近 30 日にも 44 本で更新があったのは、この進め方によるものです。
そして、私の仕事の中身が変わりました。コードを書く量は減り、代わりに、何を作るか、どこまでで止めるか、できたものが正しいかを確かめる時間が、仕事の大部分になりました。
始めるのが速くなるほど、何を確かめ、どこで手を止めたのかを残しておくことが大事になります。これが次の振り返りにつながります。
振り返り
こうすればよかった
いちばんは、始めるときに「確かめたいこと」と「区切りの条件」を書いておけばよかった、ということです。短い期間で終えた 34 本が何を確かめたのかは、記録に残っていません。最初に 3 行書いておけば、その学びを次の 1 本に渡せました。
下見の段階から、変更の履歴も残しておけばよかったと思います。今回の集計では、履歴のない試作は、フォルダの日付から時期を読み取りました。
それから、区切りがついたものに、区切りの印をつけておけばよかった。90 日以上手を入れていない 41 本が、確かめ終えたものなのか、また使う日を待っているものなのか。1 行残しておけば、次に活かしやすくなります。
一般的なやり方と比べて
| 一般的なやり方 | 私たちのやり方 | これから |
|---|---|---|
| 実験は、仮説と終わりの条件を先に決めてから始める | まず動くものを作り、その場で確かめる（速さを優先） | 始めるときに 3 行だけ書く |
| 作ったものは、変更履歴を残す | 続けるものは履歴つき。1 日で区切る試作には履歴のないものもある | 下見でも最初から残す |
| 手持ちの案件は、定期的に棚卸しする | 毎月、始めた数と動いている数を集計している | 集計に「続けるか、区切るか」の判断を足す |
私たちは、始める速さを優先してきました。これからは、その速さを保ったまま、学びを残す仕組みを足していきます。
次に試すこと（候補）
今後の運用の中で試し、続けるかどうかを決めます。
1. 新しいフォルダを作るときは、最初に 3 行だけ書く（確かめたいこと、区切りの条件、いつまでに確かめるか）。エージェントに頼むときも、この 3 行から渡す
2. 始めたら、すぐに変更履歴を残す。1 日で区切る下見でも、最初に git で管理を始める
3. 月初の集計で、しばらく動いていないものを並べ、続けるか区切るかを決める。区切ったものは、何が分かったかと一緒に 1 行で記録する
第 7 回で、この 3 つを試したかどうかと、その結果をまとめます。
次回
次回は、AI エージェントに渡している指示書（CLAUDE.md と AGENTS.md）を取り上げます。45 本の指示書から見えてきた 4 つの書き方と、次の開発へ引き継ぎたい決まりを、実物で見ていきます。
この記事の数字について
作業フォルダを数えるスクリプト（pnpm lab:scan）の集計です。対象は最初の 100 本で、2026-09-25 時点（日本時間）の値です。「始めた日」はフォルダの作成日と最初のコミット日の早いほう、「最後に手を入れた日」は最後のコミット日とファイルの最終更新日の新しいほうで、どちらも近い値です（フォルダの移動や、自動で作られるファイルの更新で前後することがあります）。コミット数は git で管理している 54 本の合計で、9 月 25 日で締めています。フォルダ名は顧客名を含むことがあるので、記事にもサイトにも出していません。トップページの「実験の規模」も同じ集計を使い、月に 1 回更新しているので、この記事より新しい数字になっていることがあります。