はじめに：「作ったこと」と「示せたこと」は、別だった
都知事杯オープンデータ・ハッカソン2026に、相談先探しを支援する「Trait Compass」で参加しました。結果は、First Stageで落選でした。
「何が足りなかったのだろう」。
この問いを、機能の数だけで考えると難しくなります。困りごとの整理、相談先検索、相談準備メモ。データの取り込みやプライバシーへの配慮も含めて、作ったものはあります。
ただ、資料を見直して気になったのは、別のことでした。
何を作ったかは説明している。でも、それによって誰の行動がどう変わるのかを、どこまで示せていたのか。
そこで、公式の5つの審査軸に沿って振り返りました。「こうすれば通過できた」という攻略法ではなく、次に何を確かめるべきかを整理するための記録です。
TL;DR
- セルフチェックと支援情報の橋渡しで、説明の主役が分かれていました。 今なら、自治体ごとに分散した情報から「次の相談先を探せること」を先に伝えます。
- データ件数や技術名より、利用者にとっての意味を示す必要がありました。 情報の根拠・鮮度・地域差と、AIを使う必要性や検索の精度を結び付けて説明します。
- 掲載実績と利用者の成果は別でした。 次は「どれだけ掲載したか」に加えて、「使った人が次の行動を決められたか」を確かめます。
Part 1：何を作り、2分で何を伝えたのか
Trait Compassは、発達特性に関連する日常の困りごとを整理し、年齢・地域・相談したいことから公的な支援情報を探し、相談の準備につなげるWebアプリです。医学的な診断をするものではありません。設計の全体像はプロジェクトのREADMEにまとめています。
First Stageは、公式の案内では2分間のプレゼン動画等による審査です。当時の資料は、次の6枚で構成していました。
表紙 → 課題 → セルフチェックから相談先を探すデモ → データ活用 → プライバシー → 社会実装
参照したのは2026年8月29日時点のスライドとスピーカーノートです。現在のアプリにある機能を、当時すでに伝えられていた実績として扱わないようにしました。
並べてみると、流れ自体がばらばらだったわけではありません。ただ、このサービスの中心である「行政の支援情報を、次の行動に変える仕組み」は4枚目に置いていました。
ここから、5つの軸で見直していきます。
Part 2：5つの審査軸で見直す
公式の審査基準は、「データ活用」「アイデア力」「技術力」「ソーシャルインパクト」「サービスデザイン」です。以下の表は、その基準を自分のサービスへの問いに置き換えたものです。
| 審査軸 | 今回、自分に問い直したこと |
|---|---|
| データ活用 | 件数だけでなく、根拠・鮮度・地域差が相談先探しにどう役立つかを示せたか |
| アイデア力 | 誰が、どんな場面で使い、何を得られるかを一言で伝えられたか |
| 技術力 | RAGやクラウドを使ったことではなく、必要性と精度を説明できたか |
| ソーシャルインパクト | 課題の大きさだけでなく、利用者の声や行動の変化を示せたか |
| サービスデザイン | チェック結果を見たあと、またはチェックをせずに、次の行動へ進めるか |
1. データ活用：集めた量より、探せる状態に変えた意味
自治体ごとに、支援情報の形式や分類は異なります。Trait Compassでは、CSV・PDF・Webページに分散した情報を共通形式に整理し、地域・ライフステージ・相談分野から探せるようにしました。
当時のデータ活用スライドにも、この流れや、出典・ライセンス・最終取得日を公開する方針は載せています。つまり、「説明していなかった」という反省ではありません。
足りなかったと感じるのは、その整備によって、利用者の何が楽になるのかを前に出すことです。
たとえば、「多くの窓口を掲載した」だけでなく、「自治体ごとの分類を読み解かなくても、自分の条件から候補を探せる」と説明する。取得日を表示することも、単なる管理項目ではなく、「利用前に情報の時点と公式の根拠を確かめられる」と伝える。
また、掲載数が少ない地域を、支援そのものが少ない地域と混同させてはいけません。データの未整備と、現実の支援の有無は別です。
今なら、データの価値をこう説明します。
自治体ごとに分散した支援情報を、根拠と情報の時点を確認しながら、困りごとから探せる形に整えました。
2. アイデア力：セルフチェックが主役なのか、相談への橋渡しが主役なのか
Trait Compassには、2つの価値があります。
日常の困りごとを整理すること。そして、整理した困りごとから公的な相談先を探すことです。
当時のデモは、30問のセルフチェックから始めました。これは操作の説明としては自然ですが、今読み返すと、セルフチェックそのものの印象が強くなる構成です。
本当に解決したかったのは、 「困っていることには気づいた。でも、どこに相談すればいいのか分からない」 という場面でした。
たとえば、「子どもの学校生活で気になることがあり、住んでいる自治体の相談先を初めて探す保護者」。今なら、このような一つの利用場面を最初に置きます。これは説明用の場面であり、利用者ヒアリングの実例ではありません。
対象年齢を広く設計したことを、取り消す必要はないと思っています。サービスが扱う範囲と、2分で最初に見せる場面は、同じ広さでなくてよかった。 ここが反省点です。
3. 技術力：RAGを使った。その先を説明できたか
当時の資料には、Cloudflare Workers・D1・R2などの構成や、個別回答を端末内で処理する設計を載せました。
ただ、技術名を並べても、それだけでは「なぜこの課題に必要なのか」までは伝わりません。ここは、RAGのように検索と生成AIを組み合わせる仕組みでも同じです。
相談先を探すサービスなら、説明したいのは「AIを使っている」ことより、年齢や地域が対象外の候補を出さず、根拠のある情報へ案内できるかです。
今なら、「困りごとの表現の揺れを検索でどう扱うか」「条件が合わない候補をどう除くか」「候補がないときに、無理に答えを作らないか」を、代表的なケースで示します。そのうえで、条件検索だけの場合と比べ、RAGを使う意味があるのかを確かめたいです。
現在のREADMEのAI・RAG品質評価には評価の仕組みも整理しています。ただし、評価の仕組みがあることと、提出時点で精度や改善効果を示せていたことは別です。
反省は「もっと高度なAIを入れるべきだった」ではありません。技術を選んだ理由と、うまく働く範囲を、確認できる形で示すべきでした。
4. ソーシャルインパクト：54自治体に掲載した。その先は？
当時の最後のスライドでは、東京都の62区市町村のうち54区市町村で支援情報を掲載していることを示しました。これは当時の掲載範囲であり、各自治体の情報をすべて網羅したという意味ではありません。
データを集めて公開し、動く形にしたことは、確かに一つの実績です。
でも、「54自治体に掲載した」は、作り手が用意したものの量です。「使った人が次の相談先を決められた」は、利用者に起きた変化です。
今回の資料では、後者を利用者の声や実証結果として示せていませんでした。課題の大きさを説明することと、自分のサービスが役立ったと示すことを、十分に分けられていなかったと思います。
次は、保護者や支援者に試してもらい、「次に連絡する候補を選べたか」「探す途中でどこに迷ったか」を確かめたいです。
主要な指標にしたいのは、試した人のうち、適切な次の行動を見つけられた人の割合です。単に「見つかった気がする」だけではなく、選んだ窓口の対象地域や年齢も確認します。これは今後の検証方針で、測定済みの成果ではありません。
5. サービスデザイン：30問に答えないと、使えないように見えていなかったか
Trait Compassは、セルフチェックをしなくても支援情報を探せます。当時のデモ資料にも注記し、スピーカーノートでも触れています。
ただ、画面の大きな流れは「30問のセルフチェック → 相談分野 → 相談先」でした。
相談したいことが決まっている人にとっては、まず窓口を探せる方が自然です。今なら、「困りごとを整理したい人」と「相談先をすぐ探したい人」の2つの入口を、最初から同じくらい分かりやすく見せます。
そして、相談先の一覧が出たところで説明を終えない。候補の公式情報を確認し、必要なら相談準備メモを作るところまで、一つの場面として見せたいです。
回答を端末内で処理することや、AI利用を任意にすることも、残したい設計です。ただし、その説明を短くすることと、実装上の配慮を減らすことは別です。
迷わず進めることと、安心して使えること。その両方が、次の行動につながっているか。 画面が用意できたかではなく、実際の使われ方で確かめたいと思います。
Part 3：今なら、何を変えるか
振り返って変わったのは、「あと何を実装するか」より先に考えることでした。
| 提出時に前へ出していたこと | 今なら先に確かめ、伝えたいこと |
|---|---|
| セルフチェックから始まる操作の流れ | 誰が、どの場面で、次の相談先を探せるのか |
| 使った技術や整備したデータ | なぜ必要で、どこまで正しく案内できるのか |
| 対応する自治体の数 | 利用者が次の行動を決められたか |
ここから先は、まだ完了した改善実績ではなく、次に取り組む方針です。
最初の一文を変える
今なら、サービス紹介はこう始めます。
自治体ごとに分散した支援情報を整理し、日常の困りごとから、自分の地域の相談先を探せるようにしました。
セルフチェックは、この説明のあとに「困りごとを整理する入口の一つ」として紹介します。
一つの利用場面で、最後まで試す
最初からすべての年齢・目的を検証しようとせず、一つの場面で、探し始めてから次の行動を選ぶまでを観察します。
候補が出たかだけでなく、対象条件を理解できたか、公式情報を確認できたか、相談する内容を整理できたか。そこで止まるところを見つけて直します。
スライドより先に、成果の材料を増やす
資料の順序を変えるだけなら、すぐにできます。でも、それで利用者の成果が生まれるわけではありません。
次は、実際に試してもらった人数、迷った箇所、改善した内容を残す。結果が良くなかったケースも含めて、何を変えたかを説明できるようにしたいです。
「伝え方が悪かった」で終わらせず、「伝えられる根拠が足りなかった」ことも引き受ける。 今回の振り返りで、ここは外したくないと思いました。
まとめ：「足りなかった機能」より、「確かめられていなかった価値」
5つの軸で振り返っても、落選理由を確定することはできません。説明を変えれば通過できた、とも言えません。
それでも、次にやることは見えました。
データを集めたなら、探しやすさにつながったか。AIを使うなら、使わない場合と比べて意味があるか。画面を作ったなら、そこで止まらず次の行動に進めるか。
Trait Compassで作りたかったのは、セルフチェックの結果を出すことではなく、困っている人と相談先のあいだをつなぐことです。
次は、「ここまで作りました」の続きを、「使った人に、こういう変化がありました」で示せるようにする。 そのための検証を進めていきたいと思います。
参考資料・関連リンク