はじめに：「困っている。でも、どこに相談すればいい？」
「忘れ物が多い」「予定が変わると切り替えが難しい」「音や光が気になる」。
そんな日常の体験を調べて、発達特性に関する説明にたどり着いたとします。そこで次に知りたくなるのは、名前や分類だけではなく、 「自分の地域では、どこに相談すればいいのか」 ではないでしょうか。
今回作りたかったのは、この一歩をつなぐアプリです。
Trait Compassは、日常の体験を振り返り、年齢・地域・相談したいことに応じて支援情報を探し、相談時に伝えるメモを作るWebアプリです。東京都・区市町村のオープンデータと、公式情報を確認して整理したデータを使っています。
ただ、相談先を一覧にするだけでは足りません。扱う入力は人に知られたくない内容かもしれませんし、案内する窓口の情報が古ければ、せっかくの一歩を止めてしまいます。
そこで本記事では、画面の使い方に加えて、 「入力をどこで処理するか」「AIに何を渡すか」「案内するデータをどう更新するか」 をまとめます。
TL;DR
- 診断するのではなく、相談につなぐアプリです。 セルフチェックを受けずに、相談先検索から始めることもできます。
- 回答・スコア計算・結果表示はブラウザ内で完結します。 検索や任意のAI機能では必要な情報を送信し、通常閲覧時には回答を含まない画面到達数の集計通信があります。
- 公開データはバッチで取り込み、出典と取得・確認時点を扱います。 coverageはアプリへの登録状況であり、地域にある支援の総数や利用可能性を保証するものではありません。
Part 1：解決したいのは「検索した、その先」の問題
相談先を探すとき、最初から制度名や窓口名を知っているとは限りません。
たとえば知りたいのは「学校での困りごとを相談したい」なのに、検索に必要なのは制度の正式名称だったりする。候補が見つかっても、自分の年齢や住んでいる地域が対象なのかを確認しなければならない。連絡する段階では、今度は「何から説明すればいいんだろう」となる。
Trait Compassでは、この流れを 「整理する → 探す → 準備する」 の3つに分けました。
| やりたいこと | アプリでできること |
|---|---|
| 日常の体験を整理する | 質問に答え、領域ごとの回答傾向を確認する |
| 自分に関係する情報を探す | 年齢・地域・相談したいことから、窓口や支援情報を探す |
| 相談に向けて準備する | 伝えたい内容を相談準備メモにまとめる |
ポイントは、セルフチェックをサービスのゴールにしなかったことです。結果を見て終わるのではなく、そこから行動に移るための道筋を作っています。
設計の全体像はプロジェクトのREADMEにもまとめています。
Part 2：画面では、どう進めるのか
1. まずは、2つの入口から選ぶ
トップ画面では、日常の困りごとチェックを始めるか、相談先・支援情報を直接探すかを選べます。
相談先を知りたい人に、質問への回答を必須にしない。 ここは大事にしたところです。自分のためだけでなく、お子さんや家族の相談先を探す場合にも、検索から入れます。
2. 質問に答えて、体験を振り返る
チェックは30問で、1画面に1問ずつ表示します。「よくある」「ときどきある」「ほとんどない」から、日常の体験に近いものを選びます。
途中経過はそのブラウザに保存され、残っていれば続きから再開できます。アカウント登録は不要ですが、別の端末やブラウザへの自動引き継ぎはありません。
3. 結果を見て、次にすることを選ぶ
結果画面では、レーダーチャートなどで領域ごとの回答傾向を確認できます。「段取り・実行」「感覚」といった領域から、自分がどのような体験を多く回答したかを振り返るための表示です。
そこから、地域の相談先を探したり、相談時に渡すメモを作ったりできます。AIによる解説は任意で、使わずに先へ進めます。
4. 年齢・地域・相談したいことから探す
相談先検索では、年齢の区分、区市町村、相談したいことを選びます。チェック結果から移動した場合は、関連する相談分野があらかじめ選ばれた状態で始まります。
検索結果は「相談窓口」「学校情報」「福祉ガイド」などに分かれています。窓口名だけでなく出典や情報の時点も確認し、利用前には公式情報に進めるようにしています。
5. 相談時に渡すメモを作る
結果画面の「相談時に渡すメモを作る」から、伝えたい内容を整理できます。選択式で組み立てる方法と、自由記述をAIに整理してもらう方法があります。
目指したのは、立派な文章を自動生成することではありません。「これを見ながらなら、相談を始められそう」と思える材料を手元に残すことです。
操作の詳細は使い方ページ、画面上の案内の実装はこちらで確認できます。
Part 3：「自己診断」ではなく「相談への橋渡し」にした理由
結果に数値やグラフがあると、どうしても「高いほど診断に近い」と読めてしまいます。しかし、このアプリのスコアは、質問で尋ねた体験の頻度を整理したもので、診断確率や重症度ではありません。
設問はアプリ独自のもので、臨床的な妥当性が検証された診断尺度ではありません。そのため、スコアから病名を判定したり、支援の必要性や利用資格を決めたりする設計にはしていません。
自分が答えた体験を振り返ることと、医学的に判断することは分ける。そのうえで、気になることを相談するための材料と窓口を提示する、という位置づけです。
AIにも同じ境界を設けています。要約や補足説明は任せても、施設名・住所・連絡先といった事実情報は、登録データから表示します。AIに窓口の情報を作らせて、そのまま案内する仕組みにはしていません。
AIは説明を助ける役であって、診断や窓口情報の正しさを決める役ではない。 この分担を、画面だけでなくデータの流れにも反映しています。
Part 4：プライバシーは「保存しません」の一文で終わらせない
ブラウザ内で済むことは、ブラウザ内で済ませる
回答・スコア計算・結果表示は、ブラウザ内で処理します。そもそも「診断結果」は作らず、回答やスコアをサービス側のデータベースへ送って保管する構成にもしていません。
一方で、相談先検索にはサーバーが必要ですし、外部AIを使うなら通信も発生します。ここをまとめて「全部ローカル」とは説明しないようにしています。
| 情報・操作 | どこで扱うか |
|---|---|
| チェックの回答・スコア計算・結果表示 | ブラウザ内で処理。回答の配列やスコア数値は送信しない |
| チェックの途中経過・保存した履歴 | その端末のブラウザ内。履歴の保存は初期状態では無効 |
| 通常の相談先検索 | 選択した年齢区分・区市町村・相談分野をサービス側で処理 |
| 任意のAI機能 | 送信前に確認したカテゴリ名や自由記述など、機能に応じた内容を送信 |
| 利用状況の計測 | 回答を含めず、「日付 × 画面」の到達回数を集計 |
保存したブラウザ内の情報は、設定画面から削除できます。ただし、「サーバーに回答を保存しない」ことと「共用端末でも誰にも見られない」ことは別です。ブラウザに残る情報の扱いも、利用者が選べるようにしています。
外部AIへ送るもの・送らないもの
AIの補助機能は、利用者が選んで実行するものです。実行前には、送信内容を確認する画面を挟みます。
たとえば結果の解説ではカテゴリ名を、困りごとの整理では自由記述などを扱います。おすすめ検索では、検索文や相談分野などを使います。質問ごとの回答やスコア数値を渡さなくても、カテゴリ名や自由記述には、その人の状況に関する情報が含まれます。 だからこそ、送信しない項目だけでなく、送信する項目も見せる必要があります。
文章生成はCloudflare AI Gatewayを経由してGoogle Vertex AIへ送ります。また、おすすめ検索では、検索文を検索用の数値表現に変換する処理にWorkers AIを使う経路があります。「外部AI」を文章生成だけに限定せず、検索のための処理も含めて捉えています。
氏名・住所・電話番号など、個人を特定できる情報は自由記述に入力しないよう案内しています。入力内容を自動で完全に匿名化できる、という前提にはしていません。
ログにも、回答や相談内容を残さない
アプリ側では、AIへの送信内容や応答本文を保存しない方針です。中継するAI Gatewayにもログ収集を無効にする指定を入れています。ただし、送信先事業者の取り扱いまでアプリだけで保証できるわけではなく、外部サービスの条件とは区別しています。
利用状況は、個人の行動履歴ではなく「どの画面に何回到達したか」を日ごとに集計します。Cookieによる追跡や、回答・スコア・自由記述の収集は行わず、Do Not Trackが有効な場合はこの集計通信を行いません。
不正な連続送信への対策では、IPアドレスをそのまま保存せず、時間ごとに変わるハッシュを短期間保持します。これはアプリ側の設計であり、ホスティング基盤に通信情報が一切届かない、という意味ではありません。
大事にしたのは、「取らないデータ」を先に決め、必要な通信を機能ごとに説明できることです。
根拠：プライバシー表示の実装／カテゴリ解説のAPI／おすすめ検索のAPI／AI Gatewayへの送信実装
Part 5：自治体データは、利用者の検索とは別に取り込む
データの入口は、自動取込と人による確認
自治体データは、利用者が検索するたびに公式サイトを巡回するのではなく、あらかじめ取り込んで検索できる形に整えます。
アプリ本体はNext.jsをCloudflare Workersで動かし、検索用データはD1に保存します。データ更新は別の取込用Workerや投入スクリプトに分けています。画面からの検索と、データを集め直す処理を切り離した構成です。
大きく分けると、東京都オープンデータカタログなどから取り込む経路と、自治体の公式情報を人が確認して整理する経路があります。前者には週次の定期取込用Workerを用意し、後者は確認したデータを手動で投入します。すべての情報が自動で更新されるわけではありません。
バッチの流れは「取得して、そのまま表示」ではない
オープンデータの取込では、まず出典や利用条件を確認し、取込対象のデータについて原本をR2に保存します。その後、CSVやExcelなどの形式を整え、検索に必要な項目に変換してD1へ反映します。
人が確認したデータも、決めた形式に整理し、項目や出典を検証してから投入します。公開可能な状態が確認できていないデータは、掲載対象に含めないようにしています。
ここでのポイントは、「Webで見られるから全部取り込む」のではなく、利用条件を確認してから掲載することです。利用条件の細かな分類は本記事では扱いませんが、検索機能の外側にある、この入口の設計も欠かせません。
バッチは情報を運ぶ仕組みです。動いたことだけで、元データの内容まで正しいと確認できたことにはなりません。そのため、次の「いつの情報か」「どこまで登録しているか」も画面に出しています。
Part 6：確認日とcoverageで「分からない範囲」も伝える
取得日と、内容が変わった日は同じではない
データを今日取り込めても、窓口情報そのものが今日更新されたとは限りません。
Trait Compassでは、取得・調査した時点を保持し、検索結果に情報の時点を表示します。また、取得から時間が経ちすぎている場合や取得に問題がある場合には、案内を制限し、広域窓口の案内へ切り替える仕組みがあります。
これは「この日付なら絶対に正しい」という保証ではありません。利用者が公式情報を確認するための手がかりです。変更や誤りを見つけた場合には、掲載情報の訂正を報告する入口も用意しています。
coverageは「地域の支援の多さランキング」ではない
データカバレッジページでは、自治体ごとの登録件数や分類の分布を確認できます。データソースのページでは、掲載データの出所を確認できます。
ここで示しているのは、あくまでTrait Compassに登録されているデータの範囲です。自治体に実在する支援先の総数ではありませんし、件数が多いほど相談しやすいと判断できる指標でもありません。
逆に、0件だからその地域に支援がない、とも言えません。未収集、利用条件の確認待ち、対象外の分類など、アプリ側の理由で表示できていない可能性があります。
検索結果だけでは、利用者は「見つからなかった理由」を判断できません。だから、見つかった情報と同時に、サービスが把握している範囲も見せる設計にしました。
Part 7：現在の限界と、これから確かめたいこと
現時点では、地域や情報の種類によってデータの厚みに差があります。掲載した窓口についても、現在の受付状況や個別の利用条件まで、アプリだけで確定できるわけではありません。AIの補足説明にも誤りの可能性があります。
そして、画面を作れたことと、実際に相談の助けになったことは別です。
今後は小規模な実証で、 「次に何をすればよいか分かったか」「相談準備メモが説明の助けになったか」 を確かめたいと考えています。実証の成果が出ている、という話ではなく、これから検証する課題です。
画面到達数だけで相談への到達を証明することはできません。利用者の負担を増やさず、必要以上の個人情報も集めずに、役立った場面とつまずいた場面を把握する。そこまで含めて、改善を続けていくつもりです。
まとめ：「何を判定するか」より、「次に進めるか」
Trait Compassで作りたかったのは、病名を当てる仕組みではなく、日常の体験の整理から相談先探しまでをつなぐ道具です。
そのために、画面ではチェック・検索・相談準備をつなぎ、入力は必要な範囲だけ送信し、掲載データは出典と更新の流れを持たせました。AIを使うことよりも、AIに任せない部分を決めることが、このサービスの設計では重要でした。
「自分のことを少し整理できた。次はここに相談してみよう」。 その一歩を作れるサービスにしていきたいと思っています。
デモ・ソースコード
参考資料・関連リンク