集患診断（SEO / MEO / AIO / 表示速度）
1〜2週自社監査ツール / GSC / GA4
よくある状態
「何から手を付けるべきか分からない。業者の提案が妥当かも判断できない。」
やること
- 自社開発の監査ツールで、検索・地図・AI検索・表示速度を一括評価
- 競合クリニックとの差分を、直せる粒度まで分解して提示
- 「やらなくていいこと」も同じ重みで報告
IIServices
入口を増やす。中を軽くする。
武器を作る。
集患の会社、業務改善の会社、開発の会社。ばらばらに発注すると、境目に落ちた仕事が誰のものでもなくなります。 アマクラスは3領域を同じチームで持ちます。だから「集患したのに院内が回らない」が起きません。
- 契約
- 月額フィー型／診断は固定見積もり
- 最短
- 3週間で本稼働
- 相談
- 無料・1院から可
01Clinic Growth
集患を、仕組みで伸ばす
症状名で検索する人、地図で近くを探す人、AIに聞く人。入口ごとに設計を変えないと、いい医療をしていても見つけてもらえません。現状の監査から記事・LP・予約導線の実装、週次の計測までを一続きで担当します。
広告費を積む前に、まだ拾えていない検索がある。
検索流入の設計と記事運用
12週〜（継続）Next.js / microCMS / JSON-LD
よくある状態
「ブログを書いているが順位も問い合わせも動かない。」
やること
- 症状 → 不安 → 受診判断の3層で検索意図を分解し、ネタ帳を作る
- 既存ページとのカニバリを確認してから書く運用に切り替え
- 医療広告ガイドラインを踏まえた表現でレビュー
MEO・Googleビジネスプロフィール整備
4〜8週GBP / LocalBusiness JSON-LD
よくある状態
「地図には出るが、そこから予約に進んでいない。」
やること
- NAP をサイト・構造化データ・プロフィールで完全一致させる
- 診療時間・アクセス・予約導線を構造化データに反映
- 写真と口コミ返信の運用を院内で回る形にする
AIO（AI検索）対応
6週〜llms.txt / JSON-LD / 監査ツール
よくある状態
「ChatGPT や AI 回答で、他院ばかりが引用されている。」
やること
- AIクローラーの受け入れ・llms.txt・構造化データを整備
- 引用されやすい「質問形の見出し＋短い断定＋根拠」に本文を組み直す
- 固有名・数値・期間を必ず添える文体へ移行
サイト・LP・予約導線の実装
4〜10週Next.js / Vercel / 予約システム連携
よくある状態
「流入は増えたのに、予約ボタンまで進んでもらえない。」
やること
- 初診の不安（費用・時間・持ち物・その後）を先回りして書く構成に
- 表示速度と Core Web Vitals を実装レベルで詰める
- Web予約・Web問診・LINE を導線としてつなぐ
02Clinic Operations
院内の手を、空ける
受付・会計・レセプト・書類作成。時間を食っているのはたいてい「転記」と「突合」です。現場に入って手順をそのまま書き出し、判断が要るところだけ人に残す形に組み替えます。
人を増やす前に、減らせる仕事がある。
書類・帳票の自動化
2〜4週TypeScript / GAS / RPA
よくある状態
「紙と Excel に散らばった集計を、毎月人が手で作っている。」
やること
- 実際の手順を現場で書き出し、工程ごとに自動化の可否を判定
- 転記・整形・出力を自動化し、例外だけ人に回す
- 運用開始後も並走して例外パターンを潰す
電子カルテ連携ツール
3〜6週Node.js / API / CSV
よくある状態
「カルテからの書き出しと突合に、毎月まとまった時間を取られている。」
やること
- 公開API・CSV書き出しの両方を検証し、現実的な方式を選ぶ
- 突合ロジックを実装し、差分レビューだけを人の作業に残す
- 締め作業のタイミングに合わせてリリースし、初回は横で回す
予約・受付・Web問診の統合
3〜6週Next.js / Stripe / LINE
よくある状態
「予約と問診と受付が別々で、そのつなぎ目を人が埋めている。」
やること
- Web予約・Web問診・受付を一本の流れにつなぐ
- 当日キャンセルと再来の導線を分けて設計
- 院内スタッフの操作画面まで含めて設計する
業務フロー診断とツール選定
4〜12週Notion / Slack / 自動化
よくある状態
「ツールは入れたが、結局使われていない。」
やること
- 訪問とオンラインで実際のオペレーションを観察
- 導入済みツールの棚卸しと、やめる判断まで含めた提案
- 教育・引き継ぎドキュメントまで作って引き渡す
03AI & Product
AIとアプリを、出し切る
医療AIの実装から、iOS / Android アプリ、オンライン診療、データ基盤まで。自社で2本のアプリをストアに出して運用し、いま医師・医療者向けの診察記録支援アプリ「カルっとな！」を開発中です。「出したあとに何が起きるか」込みで設計できます。
PoC は誰でも作れる。運用に乗せるところに差が出る。
診療記録の自動要約・下書き生成
2〜4週Claude / RAG / 匿名化
よくある状態
「記録作成が診療後の時間を圧迫している。PoC は動くが運用に乗らない。」
やること
- 個人識別情報を匿名化・仮名化してから処理するデータフローに設計
- 出力は下書き扱いとし、医師が直す前提のUIにする
- データ保持ポリシーとコスト上限を先に決めてから実装
院内ナレッジ検索・患者対応AI
3〜6週RAG / pgvector / LINE / Slack
よくある状態
「同じ質問への回答に、スタッフの時間が繰り返し使われている。」
やること
- 院内文書・診療プロトコルを横断検索する RAG を構築
- 一次問い合わせ・予約案内・FAQ を AI に寄せる
- 答えられない質問を人に渡す境界を先に決める
iOS / Android アプリ開発
8〜16週Swift / SwiftUI / Expo / Supabase
よくある状態
「院内向け・患者向けのアプリを出したいが、審査も運用も未知数。」
やること
- 企画・設計・実装から、ストア審査対応・課金実装・アップデート運用まで
- ネイティブ（Swift）とクロスプラットフォーム（Expo）を要件で選び分け
- プライバシー表示・権限設計を最初から設計に入れる
- 端末内で完結させる構成（オンデバイス処理・暗号化保存）にも対応
オンライン診療・医療データ基盤
4〜12週Next.js / WebRTC / BigQuery
よくある状態
「診療・予約・決済がばらばらで、データも見られる形になっていない。」
やること
- セキュアな診療体験（動画・予約・決済）を統合して構築
- 匿名化と権限制御を前提にした分析基盤を設計
- 3省2ガイドラインを踏まえた構成で設計する
04Engagement
どこから始めても、地続きです。
集患から入って院内DXに広がることも、書類の自動化から入ってAIに進むこともあります。 最初のスコープは小さく切り、動くものを見てから次を決める。この順番を守っています。