全社へのClaude Code大号令 — 1ヶ月で200個のアプリと300件のナレッジから見えたこと
実は3月の頭にグッドパッチの事業部所属のメンバー全員にClaude Codeを使って1アプリケーションを作ってデプロイまでやりなさいという大号令を出しました。
この時はグッドパッチの社員達は僕がどこまで本気かは、捉え方はそれぞれでしたが、後に社内ではClaude Code大号令＃CC令とハッシュタグが付き、グッドパッチ過去最大のムーブメントとなりました。
なぜこんな大号令を出したのか
それは2月上旬に僕自身がClaude Codeで昔会社で使っていた年間300万払っていたSaaSのクローンをたった1日で作れてしまった所からスタートしました。
昨日ClaudeCodeを使って昔、会社で年間300万のコストを払ってたSaasとほぼ同等機能のWebサービスがものの6~7時間で出来上がってしまった。自分自身でコードは全く書いていない。ちょっと認識のレベルをかなりアップデートする必要がある https://t.co/SzZuJoeQSY
— 土屋尚史 / Goodpatch (@tsuchinao83) February 11, 2026
この時に僕が作ったサービスは現在グッドパッチのほぼ全ての社員が登録し、毎日使われるツールになりました。未だに僕が1人で開発し、この2か月で120コミットし、常に機能追加されています。
ここからClaude Codeにハマり、1か月で20個以上のアプリケーションを作り、僕自身は自ら作ったパーソナルAIエージェント「Roger」と共に楽しいClaude Codeライフを送っています。
この一連の体験の中で、確実にゲームが変わることを確信しました。
今までのソフトウェアプロダクトの作り方とは、大きく状況が変わることが見えたので、なるべく早いタイミングで全社員に理解させないといけないと思いました。
でも、Claude Codeは始めるまでのハードルが高い
Claude Codeは本当にすごいツールですが、始めるまでのハードルがまあまあ高いのです。
ターミナルを開く。VS Codeをインストールする。GitHubアカウントを作る。Supabaseのプロジェクトを立ち上げる。Vercelにデプロイする。etc..
デザイナーや営業などの非エンジニアにとっては、かなりハードル高いです。
「興味はあるけど、なかなか手が動かない」状態の社員が大半でした。自然に広がるのを待っていたら、一部のアーリーアダプターだけが使って終わる。
だから、今回はトップダウンで大号令を出すことにしました。僕は普段はトップダウンはあまりやらないのですが、今回は流石に危機感もあったので絶対にやり切る覚悟で意思決定しました。
3月中という期限でしたが、やはりすぐにやる人やらない人も分かれるので、Claude Codeで毎日自動更新のesa（社内のイントラ記事）を作り、書いたメンバーの記事を自動収集し、誰が日時で書いたか書いていないかを自動チェックし、全員が書くまでマネージャーに追いかけてもらうまでやりました。
結果
結果：ナレッジ295記事。作った人185名。アプリケーション217個。
子会社とバックオフィス系メンバーを除く事業部社員のほぼ全員が、アプリを作り、esaに記事を書くところまで到達しました。アプリ開発記事に限れば約87%がデプロイまで到達しています（ノウハウ共有や分析記事など、デプロイを伴わない記事を含めると78%）。
たった1か月で約300件のClaude Code関連のナレッジの投稿が増えた事になります。
記事の97%に振り返りの記述があり、59%が失敗や苦労を正直に書いていました。単なる「やりました」報告ではなく、「やってみて何を感じたか」が185人分、生のデータとして残りました。
以下はClaudeCodeで分析したデータと気付きの一部です。
どんな職種が、どんなアプリを作ったか
職種の内訳
業務効率化が最多ですが、面白いのはその中身です。
「献立を考えるのがつらい」から作った献立管理アプリ。1歳の娘のアレルギー負荷試験を2タップで記録するツール。推しのニュースとイベントを一覧化するダッシュボード。冷蔵庫の食材から作れる料理を教えてくれるアプリ。コメダ珈琲で一緒にポモドーロタイマーを回せるリアルタイム同席アプリ。
壮大なものではなく、自分の生活の「小さな不便」を解決するものが圧倒的に多かったです。 これは後で触れます。
驚いたこと①：コード経験ゼロの86%がデプロイまで到達した
最も衝撃的だったデータがこれです。
コーディング経験が全くない57人のうち49人が、動くアプリをインターネット上に公開するところまで到達しています。
「コードは1行も自分で書いていません。やったことは3つだけ：作りたいことを言葉で伝える、画面を見てフィードバックする、エラーメッセージをコピペする」— デザイナー
「ここまでできるとは思っていなかった。コードを一行も書かずにWebアプリができてしまった。すごい」— 営業
「6分後、60品目のサンプルデータ付きアプリが完成しました」— 営業
「0→1が、こんなに簡単にできていいんでしょうか。これ困ってるからググる時代から、自分で作る時代へ」— デザイナー
今までデプロイ経験のなかった非エンジニアがたった数時間でアプリを作ってデプロイできる。もちろん社内エンジニアのレクチャーもありますが、それでも少し前では考えられませんでした。
グッドパッチはクライアントのデジタルプロダクトを一緒に作る会社です。その社員の大多数が「自分で動くものを出荷する体験」を持ったことの意味は大きな変化です。
驚いたこと②：半数が「ただ作れること自体には価値がない」と気づいた
295記事をAIで構造化分析し、10のテーマに分類しました。
最も多かったテーマは「自分の負から始めると強い」（52%）。半数以上が、自分自身の困りごとを起点にアプリを作っていました。先ほどの献立やアレルギー管理がまさにそれです。
そして僕が最も注目しているのが2番目、「何を作るかが問われる」に49%が到達していること。
ほぼ半数が、「作れるかどうか」ではなく「何を作るか」が勝負だと気づいたのです。
これは頭で理解するのと、体験して腹落ちするのでは全く重みが違います。自分でアプリを作り、デプロイし、「あ、本当に作れてしまうな」と実感した後にしか到達できない認識です。
「作ろうと思えばなんだって作れるこの時代ですが、逆を返せば私が作ろうと思わなければ何も生み出されることはない」— 営業
「『作ること』の価値ではなく『使われること』『成果につながること』をどうデザインするか」— デザイナー
「AIは"作る"を民主化するが、"選ばれる理由"までは生成しない」— PM
デザイン会社にとって、この気づきは非常に重い。デザイン会社は「作ること」を売ってきた会社です。その「作ること」の価値が下がるとしたら、自分たちは何を売るのか。まず、この施策を自分の手でやらないと実感出来ない問いだと思います。
驚いたこと③：AIが「職業的アイデンティティの鏡」になった
185人が同じツール、同じ期間、同じ会社で体験したのに、職種によって得た気づきが驚くほど違いました。
デザイナー — 「誇りと苦闘」が同時に生まれた
デザイナーは最も感情的に複雑な体験をしていました。「誇りと苦闘」が32%の記事で同時に出現しています。
AIが出してくるものに対して「なんとなく違う」への感度が高い。でもそれを言葉にしてAIに伝えられない。このもどかしさがfrustration 39%（全職種最高）として表れている。
しかし同時に「デザイナーの価値はむしろ上がる」が44%。この矛盾が面白い。苦しんだからこそ、「自分にしかできないこと」が逆照射的に明確になった。
「バイブコーディングをしたいけど、バイブスだけではものづくりができないなと気づきました」— デザイナー
「『これでいいか』ではなく『これがいい』を追求できるのは、人間がやる仕事だと改めて感じた」— デザイナー
エンジニア — 「自分が作ること」ではなく「全員が作れる仕組み」に目が向いた
エンジニアの反応は他の職種と根本的に違いました。fear 0%。surprise 6%。感情的な動揺がほぼない。
代わりに「仕組み化・Skill化」が68%で、他職種の2〜3倍。そして60%が「チームのため」にアプリやツールを作っていました。自分用ではなく、組織のための基盤。
「ハーネスエンジニアリングは『良い開発プロセスをコードとドキュメントで表現する技術』。結果的に人間にとっても分かりやすいリポジトリになる」— エンジニア
エンジニアは「全員が作れるようになった世界」を驚きではなく所与の前提として受け止め、その世界で自分は何をすべきかを即座に考え始めていた。
営業 — 「自分の業務課題」を起点に、素直に驚いた
営業の96%が「自分の困りごと」を起点にアプリを作っていました。これは全職種で断トツの数字です。そして43%が「自分のため」のアプリを作った。
提案書のタスク整理ツール、商談分析、スカウトリスト管理。明確な業務課題を持っていて、それを解決するものを素直に作り、素直に驚いていた。
「凝ったものを作らないといけないという思い込みから、まずやってみるへの転換」— 営業
「作れる能力よりも何を作りたいかの明確性が勝負を決める」— 営業
一方で「仕組み化」への言及は5%、「使い倒す≠思考を委ねる」は0%。体験の衝撃がまだ新鮮で、深い内省の段階には至っていない。だからこそ、次のフェーズで最も伸びしろが大きい職種でもあります。
PM — 「言語化の精度」が全てだと最初に見抜いた
「言語化力がボトルネック」54%。全職種で最高。
PMは要件定義が本業です。「曖昧な指示からは曖昧なアウトプットしか出ない」ことを日常的に体験している。だからこそ、AIへの指示精度の重要性を最初に見抜いた。
「バイブコーディングは『作れるか』を解く道具。本質は『何を作るか』を定義する人間のプロセスにある」— PM
humor（ユーモア）も61%で最高。苦労を笑いに変えながら、本質を言い当てるPMらしさ。
人事 — ドメイン知識がそのままプロダクトになった
「業務への実践応用」36%。全職種で最高。pride（誇り）93%。
面談対策Skill、プリミティブジョブの自動化、オンボーディング支援ツール。人事は自分のドメイン知識をそのままプロダクトに変換していた。 技術的な挑戦より、「自分の専門領域の課題を自分で解決できた」ことへの誇りが強い。
「アプリ開発よりも日々の作業自動化の方が組織的インパクトが大きい」— 人事
なぜ職種で景色が違ったのか
面白いのは、全員が同じ体験をしたのに、それぞれが「自分の職業にとって最も大事なもの」を再発見していること。
デザイナーは「審美眼と意図」
エンジニアは「仕組みと品質基準」
営業は「自分の課題への解像度」
PMは「言語化力」
人事は「ドメイン知識の実践力」
AIは全員に同じ能力を与えました。でもそこから何を見出すかは、その人が何を大切にしてきたかで決まる。AIが「職業的アイデンティティの鏡」として機能したと言えます。
「作れる」の価値が消えた世界で、デザイナーとエンジニアはどう価値を出すのか
49%が「作れること自体に価値がない」と気づいた。45%が「言語化力がボトルネック」にぶつかった。この2つのデータが示しているのは、「作る」から「判断する」への価値のシフトです。
デザイナーの価値
110人のデザイナーの44%が「デザイナーの価値はむしろ上がる」と結論づけています。ただし、価値の中身が変わる。
AIが出してくるものに対して「ここが違う」と指摘できるのは、積み重ねた審美眼を持つ人だけです。
「残念なデザインをみて『残念だ』と気づける人はまだ多くありません。わたしみたいに『わぁ、素敵なものができた！』ってなっちゃう人がたくさんいます」
「デザインとは『自分の確かさをいったん失う』ことから始まる。これは、学習データの延長線上で答えを出すAIには不可能な人間だけのプロセス」
「『これでいいか』ではなく『これがいい』を追求できるのは、人間がやる仕事だと改めて感じた」
デザイナーの役割は「作る人」から「何を作るか決め、品質を見極める人」に変わりつつある。AIは優秀な実行者ですが、「何を美しいと感じるか」「どんな体験を届けたいか」は人間にしか持てない。
エンジニアの価値
エンジニアの68%が「仕組み化」に言及しています。これは他職種の2〜3倍。
全員がアプリを作れるようになった世界で、エンジニアの価値は「自分が作ること」ではなくなる。代わりに、「全員が安全に、品質高く作れる環境を設計すること」に移っている。
「ハーネスエンジニアリングは『AIを管理する技術』というより『良い開発プロセスをコードとドキュメントで表現する技術』。結果的に人間にとっても分かりやすいリポジトリになる」
CLAUDE.md（AIの行動規範を定めるファイル）、Skill（再利用可能な指示セット）、セキュリティ設計、ハーネスエンジニアリング。これらは非エンジニアには設計できない。
共通するのは「言語化力」
デザイナーもエンジニアも、共通して問われているのは言語化力です。45%がボトルネックとして挙げたこの能力は、AIへの指示精度だけの話ではありません。
「整理されていないものは、AIにも伝えられない。自分の仕事が整理されていないから、AIに伝えられないのが本質」
自分が何を作りたいのか、なぜそう作るのか、ここが違うと感じるのはなぜか。これを言葉にできる精度が、AIとの協働の品質を決める。
グッドパッチがクライアントワークでやってきたことは、まさにこれです。「ユーザーが本当に求めているものは何か」を言語化し、形にするプロセス。AIとの協働で問われる力と、デザインプロセスで鍛えられてきた力が、同じものだったのです。
この施策はどんな意味があったのか
185人が全員で同じ体験をしたことで、組織に3つの変化が起きています。
1. ドメイン知識を持つ人が自分で解決策を実装できる
アプリを作れる人 = エンジニアだけ、ではなくなった。営業のデプロイ率96%、人事86%、マーケター91%。デザイナーも81%。「作る」が特定の職種の専門行為ではなくなりました。営業が営業用のツールを作り、リサーチャーがリサーチ用のAI分析ツールを作り、人事が面談対策Skillを作っている。「エンジニアに作ってもらう」のではなく、ドメイン知識を持つ人が自分で解決策を実装することができるようになりました。
2. 「何を作るか」に全員の意識がシフトした
49%が「作れること自体に価値がない」と気づいた。「デザインの力で良いものを作る」会社が、全員で「作れるの先にある価値」を考え始めている。これはグッドパッチにとって、ビジネスモデルの再定義に直結する認識変化です。
3. 共通言語と学び合いの文化が生まれた
「バイブコーディング」「CLAUDE.md」「Skill」「デプロイ」「ハーネスエンジニアリング」。職種を超えた共通言語が1ヶ月で組織に浸透し、esa投稿数はたった1か月で300件に。45%が言語化ボトルネックを体験したことで、「曖昧な指示では良いものが出ない」が共通認識になった。これはAIへの指示だけでなく、クライアントワークの要件定義、チーム内のフィードバック、すべてに波及しています。
AI時代でも良いモノづくりができる人とは
最後に僕の意見です。
今回、グッドパッチの事業部メンバーほぼ全員がClaude Codeでアプリを作ってみた結果、分かったことがあります。デザイナーでも、「ん？」というモノしか出てこない人もいれば、営業でもこれは切り口が良いし、課題を捉えていてアプリもセンスを感じるという人もいました。
いくつかの共通点はあると思っていて、3つほど挙げると
1. 課題を捉える力が高く、「何を作るべきか」が明確な人
これは、AI時代関係なくという感じですが、普段からどういう視点で物事を見ているかというのが大事だなと思いました。課題や価値を正しく知覚できている人、課題を解決する方法が解像度高くイメージが湧く人、こういう人は「作れる力」が渡された時に、非常に精度の高いモノが出てきます。
現状、作る側の職種にいなくても、こういう時に本質的にPdMやデザイナーに向いているなと思える人材が見えます。
2. AIのポン出しに満足せず、クオリティに粘れる人
やはり、AIがある程度のクオリティのモノを出して来てしまいますが、そこで満足する人材と、そこから更に粘ってクオリティを上げていける人材に分かれます。
今後、AIポン出し系のプロダクトが世の中に溢れた時に、人の琴線に触れるモノづくりができる人というのは、他の人より圧倒的にこだわれる、粘れる人だと思います。
1と2はいわゆる審美眼ですね。
3. 選ばれる「自分だけの文脈とストーリー」を持っている人
これからの時代、AIによって魂の入っていないプロダクトが溢れます。人がモノを選ぶ時に、作った人が人間かどうか、どんな想いやストーリーでそれを作って来たか、歴史や文脈の積み重ねが大事になります。
先日noteに書いた記事で、Claude Codeで誰でもプロダクトを作れる時代の構造が呪術廻戦の死滅回游と似ている、という記事の中に近い話を書いています。
「AIで何でも作れる」は嘘です。正確には「AIで何でも"動くもの"は作れるが、価値があるものを作るには、自分だけの文脈が要る」。あなたの業界知識、日々感じている不満、特殊なドメイン経験——それが「術式」です。AIはそれを実装に変換する道具にすぎません。
いやー俺も自分の術式を理解せねば https://t.co/ck7Jf8vdNc pic.twitter.com/8I5E75bPRP
— 土屋尚史 / Goodpatch (@tsuchinao83) April 6, 2026
noteにも転載しておきました
（ここまで読んでくれた人ありがとうございます！）
全社員がAIでアプリを作る。言葉にすると簡単ですが、やってみると組織に想像以上の変化が起きます。
問われているのは「AIで何ができるか」ではなく、「何を作るか、なぜ作るか」を決められる組織かどうか。
まだまだ、ここからも大きな変化があると思っていますが、グッドパッチは常に変化の最前線にいようとメンバーに伝えています。今回の施策を実施した事で、今社会で起こっている変化に実感値を持って体験できたと思いますし、危機感も希望も同時に感じたのではないかなと思います。
これはClaude Codeを触らないと絶対に分からない感覚なので、これを組織全体に体験してもらったのは良かったです。
グッドパッチは今後AIによるエージェンティックな体験設計、Agentic UXの支援をより強化していきます。
もし、組織へのClaude Code導入やAIを使ったプロダクト開発などを考えている企業があればご相談乗ります。
いいなと思ったら応援しよう！
記事を読んでいただきありがとうございます！これからも頑張ります！
