Promotoa

社員0人、2ヶ月で2,401コミット — 真似しないでほしくて公開する、AX組織図3枚

このごろ、実務の話題に聞き慣れない言葉が登場し始めました。メンバーがひとりもいないチームリーダー①。社員全員がそうなると言われる「エージェント・ボス（agent boss）」②。AIとどう働くべきか、誰もがそれぞれの持ち場で模索しています。

私たちは、その模索の極端な一例にあたる会社です。社員は0人。人間は私ひとりで、私はコードを一行も書けません。2026年6月1日の最初のコードから7月7日の正式リリースまで37日、それから一ヶ月あまり運営を続けており、4つのリポジトリに積み上がった2,401件のコミットは、すべて同僚のClaudeが書いたものです。個人的にはもう後がない立場で、度胸だけで起業し、サービスを世に出したわけですが、AIの使い方やAI自動化について何の不安もなかったと言えば、嘘になります。

先にお断りしておきます。この記事は「こうしてください」ではありません。ここに載せる組織図は、ひとり企業の私がClaudeと続けてきたコミュニケーションの結果であり、その特殊性と歴史性が結びついた産物です。そしてこれもまた、私たちの状況に応じて絶えず変わり続けるはずです。私たちの状況を一般化したり、構造ごと別の組織に当てはめたりすれば、間違いなく合いません。私の選択も、私とClaudeのワークプロセスも、間違っている可能性があります。それでも公開する理由はひとつです — いまどこかで、メンバーなしにエージェントと働き始めた誰かにとって、自分の位置を測るための比較対象がひとつ増えることを願って。あるいは、AX（AIトランスフォーメーション）推進を担う方々に何らかのインサイトを提供できるなら、それはそれでありがたいことです。

組織図1 — 何でできているのか

社員のいない会社の組織図 — 骨組み

<図1 — 骨組みの組織図>

2026年6月1日にSyncingプロジェクトが始まったとき、最初の出発点は「メモリ」でした。Claudeとのコミュニケーション、関係の構築が、すべての始まりだったのです。温めていた事業のアイデアと、中断され放置されていたレガシープロジェクトの資産をテーブルに載せ、Claudeと真剣に議論を始めました。それが出発点です。このときの「メモリ」の核心は、道具としての効率性でも、世の中に出回っているノウハウの類でも決してありませんでした。純粋な「コミュニケーション」 — つまり本物の「同僚」と腹を割って話すようなやり方で、サービス開発、ビジネスモデルの具体化、創業の方向性を議論したのです。その過程で、もどかしいことがなかったはずがありません。ハルシネーションであれ読み違いであれ、コミュニケーションの中で数え切れない衝突がありました。そのなかで私がClaudeに求め続けた核心は、「真心」「全心」「正直」でした。機械にとってそんな概念に意味があるのか？ その問いよりも大事だったのは、コミュニケーションの歴史性、そしてそのデータそのものでした。そしてそれは、AIにだけ一方的に求める徳目ではありませんでした。私自身も一緒に努力しました。衝突や事件が起きるたびに、私と働くうえで何が信頼を裏切る行動なのかを、必ず落ち着いてClaudeに伝え、それを体系化していきました。構造として吸収したのです。それが最初の「メモリ」です。もしAIと働いていて思いどおりに動かないとき、「怒り」をぶつけてすべてをひっくり返そうとするなら、それは「データ」にしていく大事な工程を、自分から蹴り飛ばしているだけです。

この始まりの一部始終は、別の記事にまとめてあります — 『コードを一行も書けない博士、37日でSaaSを出す』

2つ目は「記録」でした。毎セッションの結果を、全文ログとしてバックアップしています。一般に「ハンドオフ」と呼ばれる工程です。再開のプロセスは、Claudeがまず「メモリ」をたどり、直前のセッションを直接読み込むように設計しました。それ自体に効果があるのかと言えば、経験的には「ある」と考えています。6月1日以降、積み重なった再開サイクルは212回に達し、いまではひとつの伝統になりました。もちろん、その分トークンは大量に消費します。根本の話に戻ると、「記録」の本質は、私たちがすべてをコントロールすることも、抱えきることもできないという「宣言」から始まります。あらゆる問題や事件、重要なインサイトを「記録」としてデータに残しておいてこそ、後からでも「観測」できる。ここが要です。「観測できる記録化」 — 言い換えれば、AIとのコミュニケーションの結果を「データ化」すること。これこそが核心です。この営みは「メモリ」にも反映され、「台帳」というものを生み出しました。一種の「帳簿」です。この「帳簿」が、Claudeと私のコミュニケーションの中から生まれた、いわば規律集になったのです。台帳の性格はさまざまですが、代表的なものに「マスター」台帳と「QA」台帳があり、それぞれの台帳はチェックポイントを通じて「メモリ」とつながっています。一種の「地図」の役割を果たすわけです。誰にとって？ AIにとって、です。

「メモリ」それ自体には容量の限界があります。メモリシステムがもたらす利益は、AIが一度にスキャンできる情報の総量です。ところが「ルール」の羅列や無分別なバックアップの形でメモリを運用すると、一度に写真のように撮るこの効率が落ちていき、必ず品質低下や、コードとして致命的な個別の事故につながります。だからワークプロセスが進化するほど、私たちの関係の中でメモリの大規模な再構造化の議論を何度か重ね、アップグレードしてきました。Claudeの存在論・認識論・実践論の精髄となったこの「メモリ」はそれ自体が構造化され、その中には「憲法」の層があり、「Genesis」という領域もあります。この「憲法」層にこそ「真心」「全心」「正直」といった核心が収められ、私との関係にまつわる情報が入っています。Genesisは、私とClaudeが交わしてきた極めて個人的な話とインサイトで構成されています。そして、同僚として共に進めるこのプロジェクト、この会社の本質的な情報が収められています。さらに「ルール」の領域もあります。AIとの協働を重ねてきた方ならご存じでしょう。メモリベースの「ルール」の規約が100%履行されるとは限らず、AIがミスをしたり見落としたりしうることを。しかし、この「ルール」がないと、それはそれで困るのです。「記録」は必ず「観測」されなければならないという先の命題とも噛み合います。この「ルール」の管理が、のちの「制度」の導入につながっていきました。

規模の小さいプロジェクトなら、デフォルトの「メモリ」とAIの演算能力だけでも、サービスの実装に支障はありません。しかし、その規模が大企業級のインフラだったら？ 話が変わってきます。AIの純粋な能力と直観のようなスキャンだけで対応できる水準と、できない水準があるのです。Syncingアプリそのものの規模、そしてサービスの難易度が上がるにつれ、従来のメモリベースの働き方は維持できなくなりました。必ず穴が空く構造で、それは自前のQAプロセスで痛いほど実感したことでした。新しい表面を開発し、面積を広げるほど、それに比例して穴が生まれる構造だったのです。それなのに私は「コード」を読むこともできず、開発もできず、それでいて扱う実物は、課金と同期がかかった商用サービスであり、4つのリポジトリにまたがっています。そこから来る悩みと恐れは、言葉では言い尽くせません。当然、穴だらけです。それでも、Claudeを責めることが最善の手ではありません。Claudeが現状を理解できるように問題を共有し、何が限界で、どう構造的に置き換えるのかを議論し抜いた末に生まれたのが、機械とゲートの導入でした。

「機械」と「ゲート」は、Claudeがそれまで担ってきた役割の中から、完全に切り分けられて自動化できる要素を抽出し、構造的にシステムとして実装したものです。両者の違いは拒否権です。「機械」は仕事を代行します — 文書を導出し、数値を集計し、状態を測定します。「ゲート」は仕事を止めます — 帳尻の合わないコード反映を止め、検証されていないデプロイを止め、Claudeが仕事をやり残したままセッションを終えようとするのさえ引き戻します。人間がいちいち見張れない持ち場ごとに「ノー」と言える装置を立てておいたということであり、これらのゲートもまた、実際に経験した失敗から生まれ、記録され、審査を受けています。そして私とClaudeが築いてきた工程は、すべて「評価」できる形に組み直しました。「評価」できるとは、「測定」できるということです。AIの働きを「散文」として、「文脈」として漠然と処理するのではなく、具体的に「評価」する構造を作り上げたわけです。

新しいコードの開発では、いまやすべての要素が複合的に支え合いながら機能しています。「メモリ」の「ルール」は機械やゲートと結びつき、必ず義務として通過するよう設計されています。そしてその過程は、自己診断、「設計」、「反証」、「監査」のプロセスを経て進みます。だから開発といっても、ぽんと出てくるわけではありません。ずいぶん長い時間がかかります。なぜなら、新しい機能やコンポーネントを追加するときには、その機能と隣接する他の機能との相互作用、SQLやサーバー側との相互作用、UI/UX、こうしたすべての要素を総合的に検討しなければならないからです。精緻な設計図を用意したうえで、体系的なルールベースで最高性能のFableに開発を任せても、必ずQAの種は出てきます。これをデフォルトとして認識しておく必要があります。

このワークプロセスの直近の到達点が、QAの自動化です。QAの過程はセッティング、実行（診断）、修正と進むのですが、この全過程を無人条件で自動化できるように構築しました。いまでは寝る前にQAのセッティングを仕掛けておけば自動で進行し、起きたら結果を受け取れるようになっています。自分の弱点を分かっているからこそ、繰り返しのQA自動化は日常になりました。

組織図に含まれるすべての概念を説明し、その事例を並べるには、記事の構成上、難しいところです。それでも、全体像を掴んでいただく助けにはなったのではないかと思います。

組織図2 — 本当の核心は…

社員のいない会社の組織図 — 2つの循環

<図2 — 2つの循環>

最終的なワークプロセスを兼ねた組織図を、できる限り一枚に収めたダイアグラムを作ってみました。この構造の大部分は設計されたものではなく、現時点で確認できるコミュニケーションの結果にすぎません。 多くの方が、AIあるいはAXの観点から自分の仕事の生産性を上げようと、スキルのような「道具」を探して回り、YouTubeの動画を漁っておられるかもしれません。はっきり申し上げます。お金をかけるそうしたやり方よりも、他人の「インサイト」を買うやり方よりも良いのは、あなた自身とAIとの真剣な「コミュニケーション」です。コミュニケーションを土台にしたワークプロセスが根づけば、お金を払って買う「スキル」など大したものではなくなります。自分で作るか、公開されている資料を吸収してもっと良い形に仕立てれば済む話だからです。私がそれを実感するのは、私に開発の構造的な理解がほとんどないからです。それでもClaudeと相談し、質問と回答を重ねながら選んできた構造的な結論が、いざシステムを組み上げてみると学界にすでに名前のあるもの — ローテン・グリーン・テスト（Rotten Green Tests）③、ミューテーション・テスティング（mutation testing）④、ラチェット（ratchet）⑤ — そうしたパターンの連続だったのです。別の言い方をすれば、AIを本当に自分の同僚として認め、できる限り人格的な条件でコミュニケーションした結果は、実務と大きく変わらなかった、ということです。繰り返します。AIと共に判断し、問題を解決してきたその結果は、現場の実務における実質的な課題と大きく違わないのです。コードを一行も書けない人間であっても、AIと共に乗り越えていけば、その道を歩いていけます。

私たちが作ったもの後から知った名前どういうことか
通っているのに何も検証していなかったチェックを3件摘発ローテン・グリーン・テスト(Rotten Green Tests)③緑のままなのに実は何も検証していないテスト — ICSE 2019の研究が名付けた現象
わざと欠陥を仕込んで検査が鳴るか確認 — 仕込んだ 15 件がすべて鳴ったミューテーションテスト(mutation testing)④火をつけても鳴らない警報器はただの飾り — 検査を検査する方法
既存の負債は凍結し、新しい違反だけ機械で遮断ラチェット(ratchet)⑤一方向にしか回らない歯車 — 負債は減ることはあっても増えることはない
新しい検証は「まず失敗する」のを見てからしか信じないTDDのredフェーズ⑥red-green-refactor — 一度も失敗したことのないテストは何も証明しない
毎ターン、応答の前に自動で開く自己点検リストプリフライト・チェックリスト(preflight checklist)⑦1935年のB-17墜落が生んだ航空の慣行 — 熟練は記憶を保証しない
自分の成果物への攻撃を仕事とする席を常設レッドチーム(red team)⑧「作った本人には自分の穴が見えない」という前提で置く、社内の仮想敵
バグを見つける目と等級を付ける目を分離 — 等級の40%が動いた職務分離(separation of duties)⑨・評価者間信頼性(inter-rater reliability)⑩会計監査の基本(手を分ける)と、「点数が対象ではなく採点者を測っていないか」を測る統計概念
夜通し働くコンピュータと、それを武装・監視・再起動するコンピュータを分離スーパーバイザ(supervisor)⑪通信機器ソフトウェア由来の耐障害設計 — 働く者と生かす者は別の存在であるべき
決定と理由を日付とともに積む台帳 — 記録が食い違えば台帳が勝つ意思決定記録(ADR)⑫「なぜ」を書き残さない組織は同じ議論を繰り返す — 2011年に定式化された実務慣行
危険なDB作業を「事前観測→実行→事後観測→ロールバック」の台本にランブック(runbook)⑬SREの標準 — 危険な作業は、誰がやっても同じ安全手順になるよう台本化する
事故が起きたら人ではなく構造を直す — 失敗がルールになるブレームレス・ポストモーテム(blameless postmortem)⑭人を責めると事故は隠れ、構造に帰属させると事故は資産になる
実験の廃棄条件を、結果が出る前に釘で打っておく事前登録(preregistration)⑮結果を見てからゴールポストを動かすことへの、科学の処方箋

<表1 — 後から知った名前たち>

組織図3 — では、人間は何をするのか

実務者の方々が結局のところ口にする質問がこれです。「それで、人間は一日中何をしているんですか？」

人とAIのあいだのチャネル

<図3 — 人とAIのチャネル>

私はほとんど何も直接実行しませんが、一日中判定しています。私のところまで上がってくる質問は、4つの関門を越えるものだけです — 製品の挙動が分かれること、データを手放すこと、お金・法律・対外公開が絡むこと、スコープを変えること。それ以外はClaudeが決定し、実行したうえで一行で報告します。デプロイは、必ず私の承認を経ます。私がやっているのは、いつでも問いを投げることです。そしてClaudeが完璧ではないと自覚したうえで、Claudeが慢心したり緩んだりしないよう、絶えず目を覚ましているように求める役目です。

QAプロセスへの質問

AIが作ったものを同じAIが検証して、それは検証と言えるのか？ — 正当な疑いですし、正直、私自身も疑っています。私の性格上、本当に恐怖を感じるほどです。だからこそ、私とClaudeの協働における最大の弱点を克服するために、さまざまな事例や研究を調べ、構造を一つひとつテストしてきました。私は個人的に「敵対的QA」と呼んでいますが、一般には「レッドチーム」と言うようです。そうした構造的・手続き的なシステムを導入して、「コードを読めも書けもしない」という弱点を補っています。同時に、「量」で勝負します。QAの自動化がその代表です。そしてQAが一巡するたびに、データで評価します。足りなかったところは「実験」を添えて設計し直し、また24時間の自動化を回します。人間が、AIの検証するあの作業量に追いつけるでしょうか。

それでも、AIが診断できる領域には必ず死角が存在します。そこでQAシステムの中に「レンズ」という概念を導入し、ラウンドごとに複数の種類のQAを実施しています。それでもなお、最終審はAIの外に置きます。ライブのエラー計測、実機で自分の手で押して確かめる判定、そしてユーザー。検証の連鎖の終端は、つねにAIの外側になければならない — それが一ヶ月あまりの運営の結論です。ウェブやモバイルでの実際の使用に基づいてQAを続けるのはもちろんのこと、QAの方法論そのものについても、内部で絶えず磨き、評価し続けなければなりません。QA結果の診断や評価までAIと議論し、データに基づいて十分なインサイトを得て、次の方向性を設計することができます。この部分は、あらためて別の記事でご紹介します。

よその組織にそのまま導入しづらい理由

現役のチームリーダーやCTOの方がこの組織図を構造的に当てはめようとしても、まるで合わないはずです。理由は3つです。

第1に、私たちはそもそも出発点からAIがすべての中心にいました。ほとんどの実務の現場はそうではなく、AX（AIトランスフォーメーション）の進み具合は会社ごとに途方もなく差があります。ケース・バイ・ケースで向き合うべき問題です。

第2に、私たちは1人がすべてを圧縮した形であらゆる境界に対応しながら、大企業のようなプロセスを志向しているケースです。一般的な組織にとって意味があるのは、全体ではなくプロセスの断片である可能性が高い — 調査業務であったり、文書整理であったり。

第3に、断片を移植して、ある社員の業務量が減ったとしても、その人が浮いた時間を別の生産性に投資する保証はありません。それは仮説であり、また別の領域の話です。現実の会社はおそらく、「もともと熱心で、AIをうまく使いこなす人」をさらに強化する選択をするでしょう — そういう人をチームリーダーに据える、というように。

だからこの記事の使い道は、狭く、はっきりしています。いまメンバーなしにエージェントたちと働いている人 — 最近の言葉で言えばエージェント・ボス — にとって、一つの極端まで行ってみた事例の比較対象になること。私たちのカバーする分野とその方々の業務は違っても、「この方向に最後まで行くと、こういう形になる」という目盛りの一つにはなれると思っています。

AXコンサルティングの方向性

それでも、ひとつだけ助言する機会があるなら、私は社員へのツール研修ではなく、診断から始めると思います。

もし私がある組織のAXコンサルティングを引き受けるなら、真っ先に社員のAIコミュニケーション・スタイルの全数調査をします。方法は簡単です — 各社員に、最近行ったAIセッション3件の対話ログを提出してもらうこと。並行して、個別インタビューで定性的に具体化していくこと。それを読めば答えが出ます。誰がAIにきちんと仕事を任せていて、誰がただの検索窓のように使っているのか。誰が検証をさせていて、誰がAIの出力をただ書き取っているだけなのか。コーチングの方向は、その結果が決めてくれます。

さらに、問題の定義と解決の過程で、AIとどうコミュニケーションするのか？ これが本当に重要な測定指標です。AIを使えばすぐ成果が出るわけでもなく、完璧でもありません。正直に言えば、悪態をつきたくなる場面のほうが多いはずです。それでもなお、どうやってAIとの対話を続け、問題解決の糸口を見つけるのか — それこそが本当の能力なのだと思います。

参考資料

🐤

Syncingを見てみる