はじめに
こんにちは。NTTデータの奥村です。
最近、Amazon KiroをはじめとしたAIエージェントを用いたアプリケーション開発手法に注目が集まっています。
実は以前からなんとなくこんなアプリケーションがあるといいなというアイデアを思いつくことはあったのですが、実装するととんでもなく時間かかるからな……としり込みしていることが多くありました。
ただもしかして今の時代なら、そうした便利ツールを利用することで、仕事の間のスキマ時間でもアプリケーションの実装ができるかも……！と、一念発起して作ってみることにしました。
作ったアプリケーション（Webサイト）
Med-Finder | 不安な時に、治療への『目途』が見つかる病院検索
以前旅行先のホテルで深夜に急な頭痛に悩まされたときに、「救急車を呼ぶほどではないけど、脳神経外科の先生がいて、今開いている病院で診てもらいたい……！」と感じた経験をもとに作ったWebサイトです。
Google Mapなどでも現在地を基に営業中の病院を検索できますが、特定の診療科で絞り込んだり、その科が現在の時間に診察可能かを確認したりするのは手間がかかります。Med-Finderでは、その点を解決することを目指しました。
既存サービスとの主な違いは以下の通りです。
- 指定した診療科で、かつ現在診察している病院をすぐに検索できる
- 病院ごとに対応可能な診療科が一覧表示でき、条件として指定できる
（前述の過去の経験をもとに「こんな機能あったらいいのに」と感じた機能を盛り込んでいます）
サービス名はMedicalと治療の目途をかけて、Med-Finderとしました。
アーキテクチャ
Med-Finderは、厚生労働省が提供する医療情報ネットのオープンデータをユーザーが利用しやすい形で提供するWebサイトです。その構成は、大きく以下の2つのコンポーネントに分けられます。
- データの取得/変換/格納を行うバックエンド
- Webサイトとしてのインターフェースとなるフロントエンド
それぞれについて生成AIをどのように活用したかを説明したいと思います。
生成AIの活用方法
まず前提として私自身のスキルセットですが、以下の通りです。
- Amazon Web Services（AWS）をはじめとしたインフラ面では10年選手
- アプリケーション開発は.NETやJavaを少しかじった程度
- 運用業務で利用する簡易なスクリプト（Python/Node.js/Goなど）の実装経験はあり
- フロントエンドアプリケーションの開発経験はほぼなし
開発アプローチと利用ツール
バックエンドの経験はあったものの、モダンなフロントエンド開発は未経験という状態からのスタートでした。
そこで、いきなり全体を作ることはせず、自身の理解度が高いバックエンドのAPI開発から着手することにしました。
開発に当たって特別なAIエージェントは利用せず、ChatGPTとGoogle AI Studio(Gemini)という、いわば「王道」の生成AIチャットのみを活用しました。ChatGPTではo3 Proのモデルを主に利用し、Google AI StudioではGemini Pro 2.5のモデルを主に利用しました。
バックエンド開発編：AIとの対話で1日で完成
バックエンド開発は、主に次のような流れで進めました。
- アイデアの相談: 旅行先での実体験を基にした悩みをAIに伝え、解決策となるWebサイトのアイデアを相談。
- 技術選定: AIが二次利用可能なデータとして「医療情報ネット」を提案。アーキテクチャもほぼ完成形で提示してくれたため、即採用。
- 実装: AWS CDK（Python）による実装を提案され、トライ＆エラーを繰り返しながらAPIを構築。
このプロセスは非常にスムーズで、バックエンドは1日もかからず、ほぼ完成しました。
一方で、AIの提案には注意点もありました。例えばCORS対応など、こちらから指示しない限りセキュリティ対策が考慮されないことがありました。「ただ動くだけ」のシステムにしないためには、開発者側の知識が不可欠だと痛感した点です。
フロントエンド開発編：未経験領域での挑戦と苦労
続いて、知見がほとんどないフロントエンドの開発です。こちらはバックエンドより時間がかかり、約3日を要しました。
- AIへの指示: 「現在地から検索したい」「病院までの経路も知りたい」といった要件を伝えると、AIはGoogle Maps Platformを利用したNext.jsアプリを提案してくれました。
- 開発の工夫: 言葉だけではイメージが伝わりきらないため、画面キャプチャを交えて指示を出すことで、開発スピードを上げることができました。
- 苦労した点: 最も時間がかかったのは、エラー発生時のトラブルシューティングです。知見がない領域だったため、原因特定に手間取りました。
ここでもAIの注意点が見つかりました。オープンデータの利用規約の表示や、情報の精度に関する注意喚起など、Webサイトとして一般的に必要な情報が抜け落ちてしまうのです。こうした一般常識レベルの項目も、開発者側でしっかりチェックする必要がありました。
今回の開発から得られた「生成AI活用の教訓」
今回のアプリケーション開発を通じて得られた、生成AIをうまく活用するための教訓をまとめます。
- 得意なことと不得意なこと: アプリケーションの大枠を作るのは非常に速いです。しかし、ユーザーインターフェースの微調整など、細かな作業では前提知識の有無が開発速度に大きく影響します。
- 行き詰まった時の対処法: 同じコンテキストウィンドウで会話を続けると、堂々巡りでエラーが解消しないことがあります。その際は、思い切って新しいチャットで聞き直したり、別のAIに相談したりするのが有効な解決策でした。
Webサイトの技術的なポイントと業務的なポイント
せっかくですので今回開発したWebサイトについて、実装に当たっての技術的なポイントと業務的なポイントを紹介したいと思います。
データの取得/変換/格納を行うバックエンド
今回のMed-Finderで利用した医療情報ネットのオープンデータは下記4種類です。病床数によって病院とクリニックに分かれていますが、実質的には施設票と診療科・診療時間票の2種類の情報を取り扱っています。病院とクリニックのオープンデータの中身に重複があるかがわからなかったため、両方のデータを取り込み、付与されているIDをもとに重複を排除したデータを取り扱っています。
- 病院（施設票）
- 病院（診療科・診療時間票）
- クリニック（施設票）
- クリニック（診療科・診療時間票）
- 施設票：病院名称、住所、ホームページなどの情報
- 診療科・診療時間票：病院の専門である診療科や曜日に応じた診療時間などの情報
施設票と診療科・診療時間票の内容は下記画像のようになっています。
施設票の一部
診療科・診療時間票の一部
技術的なポイント
前述のアーキテクチャ図の通り、今回は医療情報ネットのオープンデータを、最終的にDynamoDBに格納するアーキテクチャとしました。Med-Finderの売りは、診療科目を指定したうえで、今開いている近くの病院を簡単に検索できるところですので、この要件を満たすためのDynamoDBでのキー設計が重要となります。
そのためにパーティションキーとして病院の緯度経度から求めたジオハッシュ、ソートキーとして診療科目+曜日+診療開始時間+診療終了時間+医療情報ネットでのIDというキーを設計しました。
| パーティションキーの具体値 | ソートキーの具体値 |
|---|---|
| xp5yf | 内科#3#1240#1340#0220220000444 |
| wynmw | 小児科#1#1500#1800#3422340352470 |
ソートキーは 診療科目#曜日コード#開始時間#終了時間#ID という形式です。例えば 内科#3#1240#1340#... は、「水曜日（曜日コード3）の12:40から13:40まで診察する内科」を意味します。
パーティションキーによって現在地から近い病院を絞り込むことができます。さらに、ソートキーが「診療科目」から始まる構造になっているため、これを利用して特定の診療科を持つ病院だけを効率的に検索できます。今回のユースケースに最適化したキー構造にすることで、パフォーマンスを維持しつつ、スキャン数を減らし、コストも下げるように設計しました。
5桁のジオハッシュで検索をしているため、1セルの大きさはおおよそ南北に5km、東西に4kmとなります。セルの境界付近に位置する病院を取りこぼさないため、現在地を中心に隣接した8つのセルを検索対象にしておりますので、よほど人口がまばらな場所でなければ、なんらかの検索結果が返ることになるように設計しています。
業務的なポイント
医療情報ネットのオープンデータをシステムで利用するにあたり、下記のような課題がありました。
- 緯度経度の情報が欠落していることがある
- 診療科目の表記揺れがある
緯度経度の情報が欠落していることがある
前述の画像でご覧いただいた通り、一部の病院データは緯度経度の情報がなく、マップで場所を表示させることが難しい状況がありました。この解決策として、住所をもとにAmazon Location Serviceに問い合わせを行い、緯度経度を取得する対策を行いました。
診療科目の表記揺れがある
「耳鼻咽喉科」や「耳鼻いんこう科」など同一の診療科目と思われるが文字列としては異なる値が入っているケースがあり、単純に文字列としての重複を排除すると500を超える診療科目となっていました。画面で選択できる数ではありませんので、何らかの形でグルーピングをする必要がありました。厚生労働省によって、医療機関の診療科区分が定義されており、この情報は医療情報ネットのオープンデータにも含まれていたので、診療科区分に応じて検索ができるようにしました。ただし診療科区分も63種類があり、これでも数が多すぎたので、実データをもとに利用が多かった診療科をリストアップしました。選択肢が多すぎるとかえって利用しづらくなると考え、ユーザーが一覧で見て直感的に選択しやすい数として主要な29科に絞り、それ以外を『その他』としてまとめて、合計30項目から探せるように整理しました。
Webサイトとしてのインターフェースとなるフロントエンド
フロントエンドに関する専門家ではないため、技術的なポイントではなく、利用者目線での工夫したところについて紹介したいと思います。
「現在地に近い指定した診療科で今開いているところを素早く見つけたい」という課題を解決するために作ったものですので、入力項目は非常に少なくしています。
診療科目を選択して、検索ボタンをクリックするだけで、条件を満たす病院が表示され、そこへのルートも確認できるようにしています。
また画面サイズが小さいスマートフォンでも適切に表示できるように、検索結果の表示場所や最小化機能なども作り込みました。
まとめ
本記事では、一個人の「こんなものがあったら便利なのに」というアイデアを、生成AIを活用して形にするまでの過程やそのシステムの裏側について紹介しました。かつては何ヶ月もかかったであろうアプリケーション開発が、仕事の合間のわずかな時間で実現できてしまうスピード感は、まさに驚異的でした。
本記事が皆様のお役に立てば幸いです。
仲間募集中です！
NTTデータ クラウド&データセンタ事業部では、以下の職種を募集しています。
- プライベートクラウドコンサル/エンジニア
- デジタルワークスペース構築／新規ソリューション開発におけるプロジェクトリーダー
- IT基盤(パブリッククラウド、プライベートクラウド)エンジニア
- パブリッククラウド/プライベートクラウドを用いた大規模プロジェクトをリードするインフラエンジニア
ソリューション紹介
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。