AWSが主催するグローバルAIハッカソン、「10,000 AIdeas Competition」に参加しました。
結果ファイナリストの50人に選ばれました。海外ハッカソンの参加は去年初参加して今回が2回目の参加になります。
作ったものはVetVoiceというwebアプリになります。
ざっくりいうと畜産（牛）を診る獣医師が対象に現場で録音した音声メモを、診療記録の下書きに変換する仕組みです。
詳しい内容は以下の投稿をみてください。グローバルハッカソンなので英語で書いてます。
「AIdeas finalist: VetVoice — Turning Field Voice Memos into Clinical Record Drafts」
なお日本ではもう一方ファイナリストに選ばれています。
「AIdeas Finalist: Vibe Matching — Fix the First 5 Minutes of Human Connection」
こちらも素敵な内容なので読んでよいと思ったらいいねを押してもらえるとうれしいです。
今日はどうやって作ったかの話を書きます。
でも実際の私はAIの専門家ではありません。大学で少し画像処理を勉強したことがあるくらいで、普段から最先端モデルを追い続けているタイプでもありません。英語も得意ではなく、プログラミングも特別速い方ではありません。正規表現は空でかけないのでいつもリファレンスみて四苦八苦してます。年齢も40代後半です
それでも、私は去年に続いて今年も海外ハッカソンに参加し、2回目の挑戦だった今回、運よくファイナリストに選ばれました。
では、なぜそこまでたどり着けたのか。
その理由は単純で、AIによって、人間でもできるけれど、だるくて時間がかかる作業がかなり圧縮されるようになったからです。
翻訳、英語表現の調整、構成の叩き台、実装の下書き、変換処理、比較、整理、ログの洗い出し。
こういう作業は人間でもできます。でも全部を自分でやると重いし本質ではない作業も多いです。
AIを「全部考えてくれる何か」としてではなくて、大量に手を動かしてくれる作業者として使います。
その代わりに人間が課題設定、評価基準、方向修正、ドメイン判断を持ってプロダクトをまわす。
今回うまくいったのはこの分担がうまくいったからだと個人的には考えています。
今日の話の結論は以下になります。
- 海外ハッカソンに出るハードルは、思ったより低くなっている
- 英語や実装の壁は、AIでかなり補える
- AIは「人間にもできるが、だるくて重い作業」をかなり圧縮してくれる
- 評価基準と方向修正は人間が持たないと破綻する
- 初期POCでは最初からMCPやSkillsを用意しなくても問題なく前に進める
作ったものについて
開発したのは、牛を診る大動物獣医向けに、音声メモから診療記録の下書きを作る支援ツールです。
現場で短い音声メモを録音し、それをそのままテキスト化して終わりにするのではなく以下の過程を踏んでレビュー可能な下書きを出力します。
■音声認識
■用語の正規化・辞書補正
■ 臨床情報の構造化と記録形式への整形
ここで大事なのはいきなりLLM一発で全文生成にしなかったことです。
実際には専門的な用語の略語、同音異義語、言い直しがあったりするので、
そのまま一度の変換で整った記録にするのは安定しませんでした。
なので、大きく次のような流れにしました。
音声入力
↓
書き起こし
↓
辞書・ルールによる補正
↓
LLMで必要情報を抽出
↓
LLMで記録形式に整形
この「段階を分ける」構成にすることで、あとで評価しやすく修正しやすいという形にしたのが今回の実装の肝です。
技術構成について
技術構成は以下となります
- インフラ: AWS Amplify Gen 2 (TypeScript-based CDK)
- リージョン: us-east-1 (N. Virginia)
- フロントエンド: React 18 + TypeScript + Vite
- バックエンド: AppSync (GraphQL) + Lambda + DynamoDB
- 認証: Amplify Auth (Cognito)
- ストレージ: Amplify Storage (S3)
- AI: Amazon Bedrock (Nova / Haiku), Amazon Transcribe
そのほか、辞書ファイル、評価用データ、ログ確認用の整形スクリプトや、モデル比較のためのスクリプトも作りました。
今回開発しながら優先したのは、次の順番です。
- まずは録音から結果表示まで、最低限止まらないようにする
- 特に、録音データはS3に保存して再利用できるようにする
- エラー時に、どこでおかしくなっているか見えるようにする
- テストコードとログを整備する
- その後で精度を上げる
この順番で開発をすすめることで手戻りが少なく実装できました。
技術的に一番効いたのは、モデルよりも「段階分割」と「辞書」
今回のハッカソンはAWS側から200ドル分のクレジットでやりくりするというのが条件でした。
そのため、Claude Opusといった精度がよいが料金が高いモデルをシステムに組み込むことはNGでした。
また、診療に関わる領域なので、過度な推論を利かせるよりも、必ず辞書を参照し、分からないことは「不明」と返せるようにしました。
なので強いモデル1つをいれて全部をまわすよりも安いモデルを複数使用して以下の処理をしてます
- 一回ですべて処理を行わず段階分割する
- 辞書や正規化ルールを入れる
- 評価しやすい単位に分ける
現場音声には、略語や業界特有の言い回しが含まれます。たとえば次のようなものです。
- 静脈注射 → 「静注」と発音
- AI → 「人工知能（ artificial intelligence）」ではなく「人工授精 （Artificial Insemination）」
- 「けいかん」 → 「景観」、「警官」ではなく、「経観（経過観察）」
こういうものは一般的な音声認識や一般知識だけでは安定しません。
そこで辞書やルールによる補正をLLMが参照できるようにしてます。
実質的には、この辞書とルールをどれだけ用意できるかが、精度向上に最も効きす。
そのため、人間が簡単に追加・更新できるよう早い段階で補助スクリプトを用意したのが大きかったです。
最初のゴールは「精度が高いこと」ではなく「最後まで流れること」
最初から完璧なゴールを目指さないのも重要だと考えています。
初期段階のゴールは、もっと低いところに置いていました。
- 録音できる
- 処理が通る
- エラーで止まりにくい
- 最後まで結果が返る
つまり、録音して処理が最後まで流れることを最初のゴールにしていました。
これは一見地味ですがかなり大事です。
ここが不安定なまま精度の議論をしても意味がありません。
特に今回は牛を診療する大動物の獣医師のかたに実際に診療の録音を依頼しました。
移動が多くて忙しい職業なので診療の合間をぬって音声入力したので録音できなかったとなると信頼が低下します。なので最低限録音できることを徹底しました。
AIで圧縮できたのは「人間でもできるが重い仕事」
AIで圧縮できたのは主にこういう仕事です。
- ハッカソンの概要や規約の翻訳
- UI文言の英語化
- グローバルハッカソンなので英語のUIのほうが有利
- コーデイング
- テストコード
- ログの読み解き補助
- 辞書データの変換
- 診療行為や薬品リストのPDFや表データのJSON化
- 投稿文や説明文の案出し
- 英文の自然さの確認
- 文章構成の叩き台
どれも人間にできないわけではありません。がんばればできると思います。
でも、だるいし重くて積み上がるとかなり時間がかかります。そのわりにプロダクトの価値の核とは少し距離がある作業も多いです。
個人開発ではこの「本質ではないけれど重い作業」が積み上がるだけでかなり消耗します。
そこをAIを使うことで人間がそこまで介在しなくてもできることができました。
なので今回の感覚としては、AIで「すごい開発」をしたというより、重くて手数のかかる作業をAIにうまく任せられたことが大きかったと思っています。
その結果、人間は判断や改善に時間を多く使用できました。
人間がするべき仕事
AIをかなり使いましたが人間の仕事はなくなりません。
曖昧な部分を決める仕事は最後まで人間に残ります。
具体的には以下になります。
- 作りたいものを考える
- ざっくりしたアーキテクチャの叩き台を持つ
- どこまでできれば「今回は良し」とするか決める
- ドメイン特有の言葉の意味を判断する
- 危ない推論をさせない線引きをする
- 結果を見て、どこを直すか決める
- LLMが同じ失敗を繰り返し始めた時に止めて方向性を変える
- 人間の関与ラインをどこに置くか決める
一番大きかったのは、受け入れ基準を決めることでした。
たとえば音声処理なら、まずは入力された音声を人間が文字起こしを行います。
そのうえで
- 単語として合っているか
- 文として合っているか
- 専門用語の意味が崩れていないか
- 人がレビュー可能な下書きとして使えるか
のように、評価軸をある程度持たないと改善できません。
AIはこちらが質問すれば候補や方法をたくさん出してきます。
でも、「どの方法を試すか」「その結果を何をもって有効と判断するか」を決めるのは人間の仕事です。
人間の関与ラインを早い段階で仮置きすること
AI活用で最初に考えるべきなのは、モデル名やプロンプトよりも人間がどこで関与するかだったということです。
早い段階でAIが自律して作業できる範囲を増やせるかが重要です。
AI活用では、人間の関与度を段階的に考える整理があります。
- 人間が毎回判断する工程
- AIにある程度任せて、人間が監督する工程
- 低リスクなので自動化しやすい工程
の3つに分けて考えました。
今回の開発では、最初からこの線引きが明確だったわけではありません。
最初はともかく人間が短いプロンプトやPlanを書く。AIに短く作業させる。
その結果を見ながら試作を進める。
その過程で、「この工程は毎回人が見るべきか」「ここは監視だけでよいか」「ここは自動化してよいか」を少しずつ切り分け、AIに長く作業させられる範囲を広げていきました。
- 人間が毎回判断する工程
- ドメイン辞書の意味判断
- 同音異義語の正解決定と辞書の追加、修正
- 最終的な品質判断
- AIにある程度任せて、人間は監督する工程
- ログ整理や原因切り分けの補助
- 複数モデルや複数案の比較
- 実装案や改善案のたたき台作成
- 辞書整形のたたき台作成
- 低リスクなので自動化しやすい工程
- 定型変換
- JSON整形
- 既知ルールに基づく単純整形
- フォーマット変換
一番大きかったのは、改善ループを回せるようにすること、つまりゴールが明確な状態をいかに作るかだったと思います。
そのうえで人間の仕事はコードを全部自分で書くことではなく、評価軸と方向を持つことだと考えています。
AIが強いのは、
- 実装
- 試行回数の確保
- 比較整理
- 変換文書化
のような大量に手を動かす仕事です。
一方人間が強いのは以下になります。
- 課題設定
- 受け入れ基準
- ドメイン判断
- 特に日本の大動物の診療という行為はWebでは十分に得ることができない＝AIが持てない情報なのでいかに人間が会得するかが重要
- 優先順位づけ
- 最終意思決定
AIによって圧縮されるのは、しばしば人間でもできるけれど、だるくて重い仕事でした。
この圧縮は大きいです。個人開発ではそこにかなりの体力が持っていかれるからです。
繰り返しになりますが今回のハッカソンは以下を徹底したのが個人的には良かった点だと考えています。
- 最初から完璧を目指さない
- まず動くところまで持っていく
- 評価可能な形を作る
- ボトルネックを見てから改善点を考えて対策する
- 人間は判断と評価に集中する
- AIには、手数の多い重い作業を圧縮させる
まとめ
海外ハッカソンというと、少し遠いものに見えるかもしれません。
でも実際には、英語の翻訳、資料づくり、入力といった項目はAIによってかなりハードルが下がったと考えています。
その理由は、AIが魔法の杖のように何でもやってくれるからではなく、人間でもできるけれどだるくて重い作業をかなり圧縮できるようになったからだと思います。
その代わりに残るのは、
- 何を作るのか
- 何を正解とするのか
- どこで人間が関与するのか
- どこで止めて考え直すのか
そこを持てるなら、年齢や肩書きや専門の深さだけで最初から諦める必要はなく、AIを使いながら自分が良いと思うものを作っていけるのではないかと思っています。
補足：前回の海外ハッカソンで得た知見はPyCon mini Shizuoka 2026
で以下の内容で発表しています。
AI主導でFastAPIのWebサービスを作るときに 人間が構造化すべき境界線
4/29 続きで記事を書きました