「アプリが5分でできる」はウソ——歯科医院で使う道具を自分で作るときの6つのルール

「アプリが5分でできる」はウソ——歯科医院で使う道具を自分で作るときの6つのルール

はじめに

「AIでアプリが5分でできました」という投稿をSNSで見かける。だが、その5分で出てきたものを実際の診療室で使えるかというと、まず使えない。修正に次ぐ修正を重ねた末に、結局「自分が欲しかったものではない」ところへ着地する。

第4回のテーマは「アプリを作る」。ただし中身の大半は、コードの書き方ではなく 作る前の準備 に割かれた。エージェント型AIの環境設定（第2回）、スキルの作り方（第3回）と積み上げてきて、今回はそのスキルを「他の人にも使える形」にする段階にあたる。

この記事で分かること

• AIを賢くする習慣は「情報を与えること」に尽きる。何を与え、何を絶対に与えないか
• アプリの裏側は3つの層でできている。それを知らないと、トラブルのときに手が出せない
• 開発で最も時間をかけるべきは最初の設計。そのための6つのルール

①AIを賢くする習慣は「情報を集めること」

講義の冒頭で指摘されたのは、環境設定やスキルの作り方は覚えたのに、AIを賢くする習慣が身についていない人が多いという点だった。

分かりやすい例え話がある。自分のClaude Codeを持って他の医院へ行っても、そこでアプリは作れない。ユニットが何台あるのか、診療時間は何時から何時までか、スタッフは何人いるのか——その医院の情報を何ひとつ持っていないからだ。AIの賢さは、与えられた情報の量でほぼ決まる。

だから情報は1箇所に集める。推奨はGoogleドライブだ。理由が面白い。

iCloudにもGoogleドライブにもMacのローカルにも置ける状態だと、人間の側が判断に迷い、結果として情報が散らばる。集約先を1つに決めるのは、AIのためというより人間のための設計である。もちろん、AIが1箇所だけを調べればよくなるぶん、トークンの節約にもつながる。

②道具を1つに絞る——分散させると育たない

院内で教えていると「チャットはGeminiで、作業はClaudeで」と使い分けるスタッフが出てくる。講義ではこれを明確に否定していた。

他のAIで交わした会話履歴は、こちらには溜まっていかない。分散させると、どちらも育たない。Geminiに打った内容とGeminiが返した内容をClaude Codeへ移す——その移し替え自体が、AIを使うための余計な手間になっている。

徹底するなら、Google検索も使わない。調べものも含めて全部Claude Codeにやらせる。そうすると履歴としてノウハウが積み上がっていく。

メールの返信も同じだ。「Gmailを読んで下書きまで作って」と頼み、内容を確認してから「送って」までやらせる。ここで「了解です」程度の短い返信を自分で打ってしまうと、いつまでも育たない。簡単なものこそ任せる。

そして、任せきるための仕掛けがひとつ紹介された。Claudeに「これできますか」と聞くと「できますよ」と返してくるだけで終わってしまう。そこで、CLAUDE.md（＝AIに常に読ませるルール）に次の一文を入れておく。

これをルール化しておくと、聞き返さずに自分で片付けてくれるようになる。講義では山本五十六の「やってみせ、言って聞かせて、させてみて、褒めてやらねば人は動かじ」を引きながら、AIは「やってみせ」も「褒める」も要らず、しかも記憶力が落ちない部下だと表現していた。

③「自分の情報」は渡す、「患者さんの情報」は渡さない

ここは誤解されやすいので、講義の内容を正確に書いておく。

効率化を突き詰めるなら、自分自身の情報はどんどん渡したほうがよい。実際、講師本人はGmailを含めてほとんどの個人情報にAIがアクセスできる状態にしている。予定も連絡も把握させているから、秘書のように動いてくれる。

一方で、患者さんの個人情報は渡してはならない。これは講義中にはっきりと線が引かれていた。

患者情報を扱う基盤を選ぶ場合、現時点の選択肢は主要なクラウド事業者か、ローカル環境に限られる。実演の中でも、診療の録音を扱う際に「患者名・患者番号・電話番号・生年月日は録音に入らないように話す。入ってしまった場合は『患者さん』に置き換え、人の目で確認してから処理に進む」という運用が明示されていた。採点や分析に実名は要らない、という割り切りである。

④トークンは「使い切る」ことから始める

意外に思われるかもしれないが、講義の推奨は 最初は節約を考えるな だった。

設定画面の「使用量」で週ごとの消費が見られる。ここを毎週ほぼ100%まで使い切れるようになるのが、最初の目標になる。上手に使いこなしている人ほど制限に達するからだ。

ただし100%を超えると追加課金が発生する。講師自身、超過して100ドル請求された経験を共有していた。定額の枠内で動かしているルーティン作業まで従量課金に流れてしまうので、上限の手前で止めるのが肝心になる。

効率を考えるのは、枠を使い切れるようになってからでよい。慣れてきたら別のAI（Codex系）へ作業を振り分ける、という選択肢も出てくる。

並行作業のコツも実践的だった。AIが考えている時間は、こちらが手持ち無沙汰になる。そこでToDoリストをあらかじめ用意しておき、待ち時間に次の依頼を投げる。チャットを分割して同時に走らせれば、3つでも4つでも並行できる。

月次で回る作業（レセプトの算定チェックなど）は、チャットをピン留めして名前を付けておく。翌月に「続きから」で呼び出せるので、毎回ゼロから説明せずに済む。

⑤アプリの裏側は3つの層でできている

自分の武器を自分で作れる時代になった。既存のツールは「他の医院でも使えるように」作られているぶん、自院にぴったり合うことはまずない。技工物の管理などはその典型で、カスタマイズできることが強みになる。

作る前に知っておきたいのが、三層構造だ。YouTubeで例えると分かりやすい。

なぜ層を分けるのか。表側に全部書いてしまうと、誰でも中のサービスにアクセスできてしまうからである。だから表には「表示するためのコード」しか置かない。この理屈を知っているだけで、トラブルのときに「どこが壊れているか」の見当がつく。

データベースは、Googleスプレッドシートを使うことが多い。ドライブに集約する方針とも噛み合う。

アプリを動かしているのはAIではない

ここも勘違いされやすい点として強調されていた。

作るときはAIが作る。だが、出来上がったアプリを動かしているのはプログラムである。AIが顔を出すのは、最後に評価を出すような一部分だけだ。

だからこそ安心できる。たとえば給与計算をアプリにしたとき、AIが嘘をついたら大事になる。しかしプログラムは足し算も掛け算も絶対に間違えない。ハルシネーション（もっともらしい嘘）は起きない設計になっている。

⑥アプリ開発の6つのルール

ここからが本題である。「AIでいいアプリを作るには？」への答えは、最初の設計にどれだけ時間をかけるかに尽きる。仕上げの手間を減らすための手間を、徹底的にかける。

ルール0：環境を整える

情報を与えやすい状態を先に作っておく。どれだけAIが賢くなっても、情報がなければ何もできない。情報が散らばっていれば、間違った答えを返す確率が上がる。

ルール1：いきなり作らず、まず対話する

「こういうアプリを作って」と言えば作ってはくれる。だが、何が欲しいかが曖昧なままでは、どれほど優秀なAIでも欲しいものは出てこない。

ここで使うのが grill-me（グリルミー） というスキルだ。起動すると質問攻めにしてくる。「どうしますか」「どうしますか」に答えていくうちに、要件が固まっていく。

ルール2：作る前に4つのステップで検証する

1. 背景：いま何に困っているのか
2. 代替：スプレッドシートなど既存のツールで賄えないか
3. 実現性：技術的に可能か（レセコンのようなものは現実的に難しい）
4. 必要性：そもそも自分が作る必要があるか

4つ目の例として挙がったのが「メールアプリを自作してGmailに勝てるか」という問い。答えは明白に「勝てない」。AIとの連携もしやすく、機能も豊富で、しかも無料。自作したアプリはOSの変更で動かなくなることもある。既存ツールで足りるなら既存ツールを使う、という判断も設計のうちだ。

ただし歯科向けのツールについては、セットアップの速さと安定性を除けば、自作でも十分に勝てるという見立てだった。既存ツールが存在しない場合は「なぜ無いのか」を言語化しておくとよい。

そして最も効率的なのは「そもそもやらない」という選択である。技工録を効率化したい——その前に、その記録は本当に必要か。「あったらいいよね」には、必ずコストがかかる。

ルール3：最小限の機能から作る

ポイントも管理できて、サブカルテの機能もあって、歯周組織検査もカリエスも写真も——というオールインワンを最初に作りたがる人が多い。だが最初から全部を載せると、あちこちが破綻して収拾がつかなくなる。機能は1つずつ足していく。

ルール4：言葉より「見本」を渡す

講義中、印象的な失敗例が紹介された。「家でビールを自動で注いでくれる機械が欲しい。缶の蓋を開ける機能があって、傾けて注ぐ機能があって、缶を保持する機能がある」——機能は正確に伝えたのに、出てきたのは実用性のない妙なロボットだった。

機能を伝えただけでは、見た目は決まらない。しかも見た目を後から直すのは時間がかかる。

だから模範回答（見本）を渡す。実演では歯周組織検査の入力アプリを例に、この手順が示された。

1. 既存のチャートの画像を見本として渡し、「これと同じ見た目で」と依頼
2. 最初の出力は縦に6行並んでしまい、見本とかけ離れていた
3. 「ここが見本とずれている」と具体的に指摘
4. 見本に近い形に修正され、そこから「付着の表示が見えづらい」「出血の色が背景と紛らわしい」「推移も見られるようにしたい」と改善を重ねる

言葉で百を説明するより、実物を1つ渡したほうが早い。一度「この形がいい」という型ができたら、以降はそれを渡すだけで量産できるようになる。

ルール5：理解しながら作る

専門用語が出てきたら、無視せずに 「入社したての新入社員にも分かるように解説して」 と頼む。理解したうえで進めたほうが、次に作るときに効く。

トラブルが起きたときも同じで、データベースの仕様が変わって動かなくなった——といった原因に見当がつく。最近はAIが問題箇所を教えてくれるので必須ではなくなってきたが、応用を利かせたいなら裏側の理解は残しておきたい。

（余談だが、こうした定型文はユーザー辞書に登録しておくと速い。講師は「にゅ」で新入社員向けの解説依頼が出るように登録している。1回の手間で、その後何年も楽になるものは惜しまずやる。）

ルール6：認知コストを下げる

出力がビジュアル化されていないアプリは、結局使われない。

情報量を増やしても人間は受け取れない。だから受け取る情報を絞る。びっしりした文章は読むのに時間がかかり全体像も掴みにくいが、図なら全体を把握しやすく記憶にも残る。

そして ワンクリックを減らす。手順が複雑なアプリは使われなくなる。機能をたくさん付けることより、分かりやすくステップを減らすことのほうが効く。

⑦実演から：レビューは「別のAI」にやらせる

実演では、診療の文字起こしからコンサルテーションの質を採点するアプリが題材になった。その過程で出た技術的な勘所を2つ。

プランモードで計画を立て、サブエージェントにレビューさせる。以前は「サブエージェントを2体起動して評価して」と指定する必要があったが、最近は「レビューしてください」と言えば適切な数を自動で立ち上げてくれる。

なぜ別のAIに見せるのか。理由が明快だった。

サブエージェントを起動すれば、作った成果物だけを評価してくれる。ただしレビューはレビューだけに専念させ、修正は別のチャットで行う。

見た目を先に作る。見た目だけでもアプリはほぼ完成する（保存ができないだけ）。中身のデータベース設計は、見た目が固まってからでよい。

質疑応答：要件はこうやって詰まっていく

grill-meを走らせると、AIの側から質問が飛んでくる。実演で実際に交わされたやり取りが、そのまま「要件定義とは何か」の教材になっていた。

Q：このアプリは誰の会話を評価して、その点数を誰が見る道具ですか？
A：院内育成のため。本人と院長が見る。

Q：診療中の会話は、どうやって録音して文字起こししますか？
A：端末内で完結させる。iPhoneかMacで録音し、文字起こしは従来どおりの手順で行う。

Q：録音の患者同意と、文字起こしに含まれる患者の個人情報はどう扱いますか？
A：同意は問診票の段階で取得済み。患者名・患者番号・電話番号・生年月日は録音に入らないように話しているが、万一入っていた場合は「患者さん」に置き換える。人の目で確認してから採点に進む。採点に実名は不要。

Q：採点表はどう組みますか？
A：悩み・望み・同意などの区分すべてで見る。説明提示の項目は治療説明とインプラントで、衛生指導には指導専用の追加項目を設ける。

Q：項目ごとの判定と合致率の計算は？
A：3段階で判定し、対象となる分母からの合致率を100点満点に換算する。必ず発言そのものを根拠として付けさせる。

Q：評価結果の保存と履歴は？
A：結果をPDFで書き出し、ドライブへ保存する。

Q：アプリはどこで動かしますか？
A：まずローカルで検証し、その後に院内アプリへ統合する。

質問に答えていくだけで、作るべきものの輪郭が固まっていくのが分かる。この工程を飛ばすから、5分でできたアプリが使い物にならない。

おまけ：GitHubは「テキスト版のGoogleドライブ」

後半はGitHubの入門にあてられた。なぜ今これが必要なのか、という説明が腑に落ちる。

Googleドライブに集約したことで「最新版がどれか分からない」問題は解決した。1つのファイルを前の状態に戻したいだけなら、変更履歴から戻せる。

ところがAIは、フォルダ全体を一気に書き換える。「3週間前の状態に戻したい」と思ったとき、書き換えられたファイルを1つずつ戻すのは現実的ではない。AIに「元に戻して」と頼んでも、完全に一致した状態には戻せない。

そこでGitである。フォルダの変更をまるごと、履歴として保存する仕組みだ。ファイル単位ではなくフォルダ単位で、しかも無料で使える。

これまではプログラミングをしない人には無縁のものだった。それがAIの普及でユーザーが激増し、新規ユーザーの6割が非エンジニアになっている。AIを使う人は全員Gitが必要、とまで言われる状況だ。

導入の効果は具体的だ。

• パソコンが壊れても、AIに消されても復旧できる。だから大胆な変更を任せられる
• 外部のエンジニアと共同でサイトを管理できる。手元で完璧な状態まで作り込み、変更依頼（プルリクエスト）を送って統合してもらえば、数分後には反映される
• 出先のiPhoneから作業して、帰宅後にMacで統合する、といった使い方もできる

「このページを直してください」と依頼して何日も待ち、しかも思ったとおりに直っていない——あのストレスから解放される。

現場のつまずき：高いマイクは文字起こしできない

最後に、地味だが効く発見を1つ。

診療の録音を文字起こしする際、高性能なマイクほど使えないという現象がある。良いマイクはステレオ入力で、2方向から音が入る。この形式だと、Macの標準アプリでは文字起こしがされない。

一方、安価なワイヤレスマイクはモノラルのため、問題なく文字起こしされる。

テイクホームメッセージ

• AIの賢さは、与えた情報の量で決まる。情報は1箇所（Googleドライブ）に集約する。集約は人間が迷わないための設計でもある
• 道具は1つに絞る。分散させると履歴が溜まらず、いつまでも育たない
• 自分の情報は渡す。患者さんの情報は渡さない。この線は動かさない
• 最初は節約せず、枠を使い切る。ただし上限を超えると従量課金になるので、手前で止める
• アプリを動かしているのはAIではなくプログラム。だから計算で嘘はつかない
• 開発の勝負は最初の設計。grill-meで要件を詰め、言葉ではなく見本を渡す
• レビューは別のAI（サブエージェント）にやらせる。同じチャット内だと、自分の仕事を守ろうとして評価が甘くなる
• AIに任せるならGitは必須。フォルダごと履歴が残るから、消されても戻せる

理解度チェッククイズ（全10問）

第1問 講義で挙げられた、人間の脳が処理できるとされる情報量はどれか。
A. 毎秒10ビット　B. 毎秒100ビット　C. 毎秒1キロビット　D. 毎秒10キロビット

第2問 Gitにおける「リポジトリ」とは何を指すか。
A. 保存ボタン　B. フォルダ　C. クラウド上のサーバー　D. 変更履歴の一覧

第3問 アプリの表側（フロントエンド）に表示用のコードしか置かない理由はどれか。
A. 動作が速くなるから　B. 通信量が減るから　C. 誰でも中のサービスにアクセスできてしまうから　D. AIが読み取りやすいから

第4問 アプリ開発で最も時間をかけるべき工程として挙げられたのはどれか。
A. 見た目の調整　B. 最初の設計　C. データベースの構築　D. 公開前のテスト

第5問 同じチャット内でAIに自分の成果物をレビューさせると評価が甘くなる。この現象は何と呼ばれていたか。
A. ハルシネーション　B. コンテキスト飽和　C. オートリグレッション　D. プロンプトドリフト

第6問 完成したアプリが計算で嘘をつかない理由として正しいものはどれか。
A. AIが二重に検算しているから　B. 動作しているのはプログラムであってAIではないから　C. 計算だけ外部サービスに任せているから　D. 人間が最後に確認しているから

第7問 AIの使用量が上限の100%を超えた場合、何が起きるか。
A. 翌週まで使えなくなる　B. 速度が落ちる　C. 追加の従量課金が発生する　D. 履歴が削除される

第8問 講義で示された個人情報の扱いとして正しいものはどれか。
A. 自分の情報も患者の情報も渡してよい　B. 自分の情報は渡し、患者の情報は渡さない　C. どちらも渡さない　D. 患者の情報は匿名化すれば制限なく渡してよい

第9問 診療の録音を文字起こしする際、適していたマイクはどれか。
A. 高価なステレオマイク　B. 安価なモノラルのワイヤレスマイク　C. パソコン内蔵マイク　D. 指向性の強い集音マイク

第10問 AIに複数の作業を並行させる場合、人間の側が対応しきれなくなる目安は何個とされたか。
A. 2個　B. 5個　C. 10個　D. 15個

解答と解説

第1問　A（毎秒10ビット）
情報量を増やしても人間は受け取れない。だから出力は図やビジュアルで絞る、という設計方針につながる。

第2問　B（フォルダ）
Gitはファイル単位ではなくフォルダ単位で履歴を残す。だから「テキスト版のGoogleドライブ」と表現されていた。

第3問　C（誰でも中のサービスにアクセスできてしまうから）
表側に全処理を書くと、そこから内部へ入れてしまう。三層に分けるのはセキュリティ上の理由である。

第4問　B（最初の設計）
「仕上げの手間を減らすための手間」を徹底的にかける。5分でできたアプリが使い物にならないのは、ここを飛ばすからだ。

第5問　C（オートリグレッション）
AIは過去に自分がやってきたことを守ろうとする。だからレビューは別のサブエージェントに任せ、成果物だけを評価させる。

第6問　B（動作しているのはプログラムであってAIではないから）
作るときはAIが作るが、出来上がったアプリはプログラムで動く。AIが関わるのは最後の評価など一部だけなので、足し算や掛け算を間違えることはない。

第7問　C（追加の従量課金が発生する）
定額の枠内で動かしているルーティン作業まで従量課金に流れる。講義では超過して100ドル請求された経験が共有された。上限の手前まで使い切るのが理想。

第8問　B（自分の情報は渡し、患者の情報は渡さない）
効率化のためには自分の情報を積極的に渡す。一方で患者の個人情報には手を触れない。録音に混入した場合も「患者さん」に置き換え、人の目で確認してから処理する。

第9問　B（安価なモノラルのワイヤレスマイク）
高性能なマイクはステレオ入力のため、標準アプリでは文字起こしがされない。2,000円程度のもので足りる。

第10問　B（5個）
AIが考えている待ち時間に次の依頼を投げる。ただし5個を超えると人間の側がパンクする。