メインコンテンツへスキップ
AMPL
半年やって、本当に大事だった3つ
レッスン 15 / 15|18分で読めます

半年やって、本当に大事だった3つ

言語化の質、動くと正しいは別物、身近な不便だけ作る。連載のすべてが、ここに集約される。

連載の最終回です。

ここまで14回、Vibe Codingの全体像と、最初の1本を作って公開するまでを通しでお伝えしてきました。

最終回は、振り返りです。 半年で20本以上アプリを作って、私が「本当に大事だった」と思う3つだけ、お渡しします。

それに加えて、これからどう学び続けるか、何を作り続けるかの道筋も。

ㅤ

大事だった1つ目　「言語化の質」が、すべて

最初に痛感したのは、これでした。

AIへの指示が曖昧だと、返ってくるものも曖昧。 指示が具体的だと、返ってくるものも具体的。

それだけ。

「いい感じに作って」が、なぜダメか。 情報量が、ゼロだからです。

20本作ってみて気づいたのは、Vibe Codingの上達は、AIの使い方の上達ではなく、自分の言語化能力の上達と完全に重なる、ということでした。

具体的な指示を書く練習になる。 書きながら、自分の頭の中も整理されていく。 これは、コードに限らず、仕事の依頼や、家族との会話にも、なぜか効きます。

「Vibe Codingは、言語化の練習である」。 半年やって出した、いちばんの発見です。

情報量ゼロ「いい感じに」と情報量たっぷり「具体的指示」の比較。出力の質に直結する図
言語化の質が、そのまま出力の質になります。

ㅤ

大事だった2つ目　「動かす」と「正しい」は別物

これも、何度も自分に言い聞かせている話です。

AIが書いてくれたコードは、動きます。 動くと、正しく見えます。 でも、動くことと、医学的に・法的に・社会的に正しいことは、別物です。

ここを混同すると、事故が起きます。

私は医療の人間なので、特に薬の量や疾患の説明に関しては、AIの出力をそのまま使いません。 必ず、添付文書や最新ガイドラインに当て直します。 法律やお金の話も、同じです。

3つだけ、絶対のルールにしています。

1. 出力された数字は、一次情報で確認する

薬の量、税率、利率、計算式。 すべて、AIの「自信満々」を、自分で当て直す癖をつけます。

2. 個人情報は、AIに渡さない

氏名、住所、電話番号、生年月日、ID、写真、診療情報。 これらは、AIに見せる前に必ず削るかダミーに置き換えます。

3. 著作権のあるものは、丸投げしない

他人が書いた記事や論文をまるごと放り込んで、要約や記事化を頼まない。 必要な部分だけ、引用と出典を明記して使う。

この3つを徹底するだけで、9割以上の事故が避けられます。

動くアプリの周りに3つのリスク（医療事故・法的事故・著作権事故）が矢印で示され、3つの絶対ルールが守りとして配置された図
動くこと ≠ 正しいこと。3つのルールで、9割の事故は防げます。

ㅤ

大事だった3つ目　続けるコツは「身近な不便」だけ作ること

これは、最後にいちばん伝えたいことです。

学習教材としてのアプリ作りは、続きません。 「役に立ちそうだから」で作ったものは、自分でも使いません。

続いている人を見ると、共通点がひとつあります。 全員、自分の身近な不便を、自分のために潰している。

私の場合、外来で「あったらいいな」と思ったものを、その日のうちに作ることが多いです。

  • 体重から薬の量を出すツール
  • よく使う注射薬の希釈計算ツール
  • 患者さんの家の地図を、住所からすぐ表示するツール
賢が外来で実運用している3アプリ（解熱薬計算・希釈計算・住所→地図）のミニカード集
毎日使うものだから、改良も続きます。

この3つは、毎日使っています。 だから、改良も続きます。

医療現場には、職種ごとに「ちょっと不便」が散らばっています。 私の周りの方々が実際に作って使っている例も、少しだけ。

  • 看護師：申し送りのテンプレを症例に合わせて生成するツール、シフト調整の補助
  • 薬剤師：服薬指導の記録を整理するフォーマット、相互作用の早見ツール
  • リハ職：評価シートをワンクリックで生成、患者さんの目標達成度の見える化
  • 検査技師：検査値の経時変化を一枚にまとめるツール
  • 医療事務：よくある問い合わせの定型回答テンプレ
6職種（医師・看護師・薬剤師・リハ職・検査技師・医療事務）それぞれのツール例を6セルグリッドで示した図
どの職種にも、絶対に「身近な不便」があります。

逆に、「いつか使うかも」で作ったものは、ほぼ全部触らなくなりました。

「身近な不便」だけ作る。 これが、続く人の唯一の共通点です。

ㅤ

ここから、何を学ぶか

最後に、もう一段先に進みたい人向けの道筋を置いておきます。

A. 道具を増やす

  • Cursor（カーソル）：AIが組み込まれた専用エディタ。Claude Codeと併用すると速い
  • GitHub Copilot：既存のIDEに後付けできるAIアシスタント
  • Bolt.new、Lovable：ブラウザだけでフロントエンド開発ができるサービス

ここで「フロントエンド」というのは、ユーザーが直接見て触る部分のこと。 Webページの見た目や、ボタンの動きの部分です。 私のイメージは、店舗の看板と売り場、お客さんに見える側の全部です。

B. つなぐ先を増やす（MCP）

第14回で触れたMCPの世界です。 PubMed、国土交通省、Notion、Slack、Googleカレンダー。 身の回りのサービスをAIにつなぐ、という方向の進化です。

C. 仲間を作る

ひとりで続けるより、誰かと続ける方が、圧倒的に楽です。

  • X（旧Twitter）で「#VibeCoding」「#バイブコーディング」を追う
  • もくもく会、Vibe Coding系のオンラインコミュニティに顔を出す
  • 同僚や家族を、まず1人巻き込む
連載卒業後の3方向ロードマップ（A.道具を増やす／B.MCPでつなぐ／C.仲間を作る）の航海図
ここから、どこへでも進めます。

ㅤ

連載を終えるにあたって

この連載は、私自身が半年でやってきたことを、できるだけ最短で誰かに渡すために書きました。

私は医師ですが、ここに書いたことは、ほとんど医師の経験に依存しません。 医療現場で働くすべての職種で、「身近な不便を、自分の手で潰す」体験は、誰にでも開かれています。

これからも、Vibe Codingの世界はものすごい速度で進みます。 今日の内容が古くなる日も近いです。 でも、最初の3つ、

  • 言語化の質
  • 動くと正しいは別物
  • 身近な不便だけ作る

これは、何が出てきても変わらない、と思っています。

ㅤ

全15回の振り返り

全15回の登山道完成版。6段の道のり（全体像→最初の1本→道具→育てる→世に出す→振り返る）の旗マーカーが全部チェック済みで、最後に「今ここ」のスター
お疲れさまでした。歩いた道のりが、地図になりました。

最後に、目次を置いておきます。 迷ったら、戻ってきてください。

第1段　全体像をつかむ

  • 01　そもそもVibe Codingってなに？
  • 02　「俺もアプリ作れるんじゃね」を体験する
  • 03　知っておきたい7つの言葉（前半：LLM〜IDE）
  • 04　知っておきたい7つの言葉（後半：Git〜デプロイ）

第2段　最初の1本を作る

  • 05　ChatGPTで最初の1本
  • 06　直しを話しかけるコツ
  • 07　コラム　詰まったときの抜け方

第3段　道具を増やす

  • 08　Claude Codeを準備する
  • 09　ターミナルって怖くない
  • 10　Claude Codeで実際に作る

第4段　育てる

  • 11　アプリを育てる①　機能を足す
  • 12　アプリを育てる②　ファイルを分ける

第5段　世に出す

  • 13　GitHubに上げる
  • 14　Vercelで世界に出す

第6段　振り返る

  • 15　半年やって、本当に大事だった3つ（いまここ）

連載のすべてを読んでくださって、ありがとうございました。 読んでくださった方が、今日のうちに1本目のアプリを作り始めるきっかけになれていたら、嬉しいです。

ㅤ

学ぶより、作る。 完璧より、使える。 未来より、今日の1本。

ㅤ

連載は終わりですが、メルマガ「おかもんだより」では、続編やTipsを引き続き配信します。 よかったら登録してお待ちください。

ㅤ

演習：30分の宿題（最終回）

連載最後の宿題は、シンプルで本気の1つだけ。

「自分が3か月続けて使うアプリ」を1つ決めて、24時間以内に最初のバージョンを完成させる

ここまで14回、いろいろな道具と作法を扱ってきました。 最終回は、実装より決断の回です。

「3ヶ月続けて使うアプリ、何を作るか」だけ、決めてください。

候補が多くて選べないなら、こう考えます：

  1. 自分の業務で、毎日／毎週繰り返している作業を3つ書き出す
  2. その中で、5分以上時間を取られているものに丸を付ける
  3. その中で、自分が直したいと思った瞬間の感情が新しいものを選ぶ

そして、24時間以内に最初のバージョンを完成させる。 完成度70%でいい。動けばOK。

3ヶ月後、その1本が毎日使われているかどうか、振り返ってください。 使われていれば、Vibe Coding は生活の道具として定着しています。 使われていなければ、別の題材で再挑戦すればいい。

「身近な不便だけ作る」が成立する条件は、これだけです。

医療職別 実例ギャラリー：連載読者の作品（架空・募集中）

連載読者の作品も、これから集めていきたいです。

架空例1：救急医・小児トリアージ判定ツール

主訴と年齢を入れると、緊急度（赤・黄・緑）と推奨検査が出るツール。 夜間救急で使うことを想定。判断が速くなり、研修医の教育にも使える。

架空例2：薬剤師・服薬コンプライアンスチェック

患者さんの服薬日記を入力すると、飲み忘れパターンを分析して家族向けレポートを生成するアプリ。 高齢者の服薬指導で活用。

架空例3：医療事務・問い合わせ振り分けボット

電話問い合わせの内容を入力すると、該当部署と回答テンプレが出るアプリ。 新人事務スタッフの研修コストを大幅削減。

これらの実例を、メルマガ「おかもんだより」で随時紹介していきます。 あなたの作品も、ぜひ送ってください。

もっと深く：「身近な不便を作る」が成立する条件（gstack ETHOSとの接続）

「身近な不便だけ作る」という思想は、私の独創ではありません。

シリコンバレーの著名VC、Garry Tan が立ち上げた gstack というプロジェクトの ETHOS に、こう書いてあります。

Build for Yourself Solve your own real problems, not hypothetical ones.

「自分の実問題を解決する。仮想的なニーズではなく」。

この原則が成り立つ条件は、3つあります：

  1. 使う人=作る人：自分が使い続ける限り、改良の動機が枯れない
  2. 問題が具体的：抽象的な「便利そうな機能」ではなく、自分が今日困った具体的瞬間
  3. 完成度70%でも価値：自分が使うなら、完璧さは要らない

医療職にとって、この3条件はすべて揃っています：

  • 自分の業務で毎日同じ作業を繰り返している（使う人=作る人）
  • 何が不便か、明確に言語化できる（問題が具体的）
  • 自分用なら動けばOK（完成度70%）

つまり、医療職は Vibe Coding と相性が極めて良い。 半年やった私の実感です。

動画で見る

連載のすべてを読んでくださって、本当にありがとうございました。

ㅤ

参考・出典