Goodpatch事例 200人全社導入の論理
このレッスンが終わる頃には、
- Goodpatch社が全社展開を決断した論理の構造を言語化できる
- 「打ち上げ花火→業務定着」の2フェーズ設計を自院に翻訳できる
- 医療組織で同じことをやる際の条件と修正点を3つ挙げられる
ㅤ
事件は祝日の午前中に起きた
2026年2月の祝日。
デザイン会社Goodpatchの土屋社長は、たまたま空いた1日を使って、ずっと気になっていたClaude Codeを開いた。
目をつけていたのは、社内で年額300万円ほど払って使っているSaaSのひとつ。「これ、自分で作れるんじゃないか」という直感があったという。
朝一で指示を送り始めて、夕方には動いた。
完全な代替ではない。でも、日常業務で使う分には遜色ない。年額300万円のプロダクトが、1日でできてしまった。
土屋社長はこう表現した。「終わったな、と正直思いました」。
その1日から2ヶ月間、彼は取り憑かれたように毎日Claude Codeを触り続ける。2ヶ月で40アプリケーション。自分のスケジュール管理、資料作成のワークフロー、社内の情報収集。できると思っていなかったことが、次々とできた。
そして3月頭、全社会議の冒頭でこう宣言した。「全員、3月中に1本、デプロイまでやること」。
ㅤ
なぜトップダウンでやったのか
土屋社長が確信していたのは、2点だった。
1点目。やるまでのハードルが高すぎて、放置すると自発的にはやらない。
全社展開を決めた時点で、Claude Codeを触っていたのは全体の10%未満だった。それも、もともとテクノロジーに前向きなメンバーだけ。残り90%は、ChatGPTを使ってはいるが、その先には行けていない状態だった。
「危機感があったから」と土屋社長は言う。ただし、それは焦りではなく確信だった。インターネットとスマートフォンに続く、3回目の大きな変化がきている。今始めないと、取り残される、ではなく、今始めることで、自分たちの仕事の設計が根本から変わる、という感覚。
2点目。やってしまえば、それほど時間はかからない。
非エンジニアでも、セットアップからデプロイまで1〜2時間あれば通り抜けられる。ハードルが高いのは事実だが、越えてしまえば低い。このギャップを埋めるには、強制的に越えさせる仕組みしかない。
ㅤ
組織設計の中身
「全員やること」を成立させるために、Goodpatchが用意したのは4つだ。
①ルール設計
セキュリティに関して明確なラインを引いた。
- 顧客情報・社内機密データとAPIを接続しない
- ログイン・認証機能（Okta連携）は一旦切り離す
- 作るのは、個人の課題解決アプリから始める
上場企業として守るべき線を先に決め、その範囲の中で自由にやる、という設計だ。
②インフラ
ツールはClaude Codeのチームプランに統一。デプロイ環境はVercelとSupabaseの無料枠。「Claudeに聞けばセットアップできる」状態を作った。
③観測と追跡
土屋社長が自分でClaude Codeを使って作ったのが、社員全員の投稿状況を追跡するスプレッドシートだ。社内ドキュメントツールへの投稿を自動で集計し、誰が書いていて誰がまだかを毎日確認した。「なんとなく分かってるよ」という無言のメッセージを発信し続けることで、最後の1週間でも大半が動いた。
④レクチャーパッケージ
月末にまだ手をつけていない人が半数以上いることが分かり、Zoom講座を複数回開いた。「この1〜2時間に参加すれば、セットアップからデプロイまで終わる」という保証付きで。
結果。エンジニア経験ゼロの60名のうち、90%がデプロイまで到達した。
ㅤ
打ち上げ花火の次が大事
3月に「全員1本」を達成した後、4月からはフェーズ2に入った。
業務プロセスの自動化を、各自で設計する。
ツールをひとつ作った体験は、「何ができるか」の解像度を上げる。その次のステップは、「自分の仕事のどこにこれを使うか」の発見だ。
4月以降、各部署からAI活用事例が野良で増え始めた。それを取りまとめ、車輪の再発明が起きないよう経営会議で共有する仕組みを立ち上げた。
打ち上げ花火で全員に火をつけ、そこからは自燃させる。これが2フェーズの構造だ。
ㅤ
医療組織への翻訳：3つの修正点
Goodpatch事例をそのまま医療機関に持ち込もうとすると、3つの壁がある。
壁① ヒエラルキーの重さ
Goodpatchは比較的フラットな組織だ。医療機関では、部長・医長・スタッフ・研修医という縦構造がある。トップダウンで動くには、まず診療科長・看護部長・事務部長を個別に口説く工程が必要になる。
土屋社長が自分で触って確信を持ったように、まず管理職自身が1本作る体験を持たなければ、説得力が生まれない。
壁② 患者情報という絶対線
Goodpatchは「顧客情報とAPIを接続しない」と決めた。医療機関では、この線がはるかに太い。患者識別情報・診療情報は、そもそもAIサービスに入力してはならない。この線の引き方は第3回で詳しく扱う。
壁③ JCI・病院機能評価への耐性
上場企業のガバナンスと、医療機関の第三者評価は、チェックリストが異なる。「院内でAIを使っていることを、どう記録するか」「トレーニングの記録をどう残すか」の設計が別途必要になる。
ㅤ
実践：医療版「打ち上げ花火」設計シート
以下の項目を埋めることで、自院向けの第1フェーズが設計できる。
対象と期限
- 対象職種・対象範囲:（例：内科病棟のスタッフ医師8名）
- 期限:（例：◯月末までに全員1本完成）
ルール（必ず事前に決める）
- 使ってよい情報の範囲:（例：公開資料・院内勉強会のスライド・医学文献）
- 接続してはならない情報:（例：電子カルテ・患者氏名・ID番号）
- 承認が必要な作業:（例：外部公開するURLを作る場合は情報システム部に事前申告）
インフラ
- 使うAIツール:（例：Claude.ai Professional）
- デプロイ先:（例：今は不問、ローカルHTMLのみ）
- コスト負担:（例：診療科の研修費から月◯円）
観測
- 進捗を確認する方法:（例：Slackの専用チャンネルに完成スクリーンショットを投稿）
- 完了の定義:（例：自分の外来・病棟で実際に使えるものを1本）
レクチャー
- 詰まった人向けの勉強会:（例：月◯日◯時、Zoom30分、誰でも参加可）
ㅤ
今日のまとめ
Goodpatch事例の核心は、トップの確信と組織設計の両輪だ。
確信だけでは人は動かない。仕組みがなければ確信は熱で終わる。 この2つを同時に設計する。それが管理職の仕事だ。
医療版への翻訳で外せない3点：
- 管理職自身が先に1本作る
- 患者情報の絶対線を事前に文書化する
- 打ち上げ花火の後のフェーズ2を同時に設計しておく
次回は、組織全体を貫くガバナンスポリシーの作り方を扱います。
ㅤ
参考
- Goodpatch土屋社長×いけともch インタビュー（2026年4月）
- 「200人にClaude Code全社導入の裏側」いけともch YouTube