こんにちは。今回、AI HACK 2026ハッカソンに出場したteamKです。

私たちは今回のハッカソンで、「ツマヅキ」というデモサービスを皆さんにご紹介したいと思います。

私たちのプロダクトを一言で表現すると、以下のようになります。

演技ではなく、制約を。
「使いにくい」を、数字で。
AIペルソナで行動テストのプラットフォーム。

AIペルソナを使って、主に公共ウェブサイトの「使いにくさ」を発見し、改善点を提示することが、私たちのプロダクトの大きな特徴です。

まずは、私たちがこのプロダクトを考えるに至ったきっかけと、開発の過程についてご説明します。

その画面、本当に「誰にでも」使えていますか

自治体のサイトは、作る側は必ず一度は通してみます。
ところが作った人はもう答えを知っているので、たいてい通れてしまいます。

では、答えを知らない人はどうか。
カタカナ語が読みにくい人、日本語を勉強中の人、片手でスマホを見ながら急いでいる人。
その人たちがどこで手を止めるのかは、実際にその人たちに使ってもらわないと分かりません。

でもそれは、時間もお金も、そして協力してくれる人への負担もかかります。
だから多くの現場で、この確認は「やったほうがいいけど、やれていないこと」になっています。

じゃあAIに代わりにやってもらえばいいのでは？ ……と考えて、すぐ壁にぶつかりました。

今のブラウザ操作AIは、うますぎるのです。

ページを読み、リンクを見つけ、迷わずたどり着く。
私たちが知りたいのは「AIが通れるか」ではなく「人が通りにくい場所はどこか」なのに、
そのままでは全部すいすい通ってしまって、何も見えません。

「演じさせる」のではなく、「本当に制約をかける」

いちばん簡単な方法は、こうお願いすることです。

「あなたは70代の高齢者です。カタカナ語が読めないふりをしてください」

これはやらないことにしました。

理由は単純で、演技なら、いくらでも上手にできてしまうからです。
モデルは「高齢者らしい失敗」を演じることもできるし、演技を忘れてうっかり成功することもできる。
どちらも起きるなら、出てきた数字が何を測ったものなのか、誰にも説明できません。

そこで発想を逆にしました。

お願いするのをやめて、AIに届く情報そのものを減らせばいいのでは？

読めない語は、頼まなくても最初から消しておく。
画面が狭いなら、本当に狭くする。
検索が使えない設定なら、選択肢から取り除く。

そうすればAIは演技をする必要がありません。
「読めないふりをした結果」ではなく、「本当に読めない状態での結果」が出てきます。

これが ツマヅキ の出発点です。

作り方：引き算は「観測層」でやる

制約はプロンプトに書きません。ページを見てからモデルに渡すまでの間でかけます。

observe() — 今この画面に何があるか。押せるもの、見えている範囲、横にはみ出していないか
shield() — 外部サイトのテキストをそのままモデルに渡すので、危ない文字列をここで落とす
constrain() — ★ここが本体。理解率の低い語を消し、画面を狭め、使えない道具を選択肢から外す
そして OrcaRouter を通ってモデルへ

constrain() を通らないバイトはモデルに届きません。
抜け道を1つでも作った瞬間「演技するAI」に逆戻りするので、ここだけは例外なしにしています。

開発中、いちばん大きなツマヅキは自分たちのコードでした

正直に書くと、最初の105実行は全部捨てています。

「ある区は離脱率94%」という、いちばん強い数字を持っていました。
ところが原因を掘ったら、エージェントが特殊な形式のリンクを踏もうとして、
自分たちのガードが止めていた回数が112回。しかもその区に78回集中していました。

つまりあの94%は、サイトではなく自分たちのコードを測った値でした。

計測器を作るとき、いちばん怖いのは計測器自身のバグです。

ペルソナは「性格」ではなく「仕様」

ペルソナといっても、性格や口調は一切書いていません。
書いてあるのは数字と真偽値だけです。記事の一番上のYoutube動画でテストした高齢者のプロフィールsenior-70s v1.0は、以下のとおりです。

制約	値	根拠
語を消す基準	60歳以上の理解率 30%未満	国立国語研究所「外来語定着度調査」
調査に載っていない語	消さない（通す）	根拠がないものは触らない
表示倍率	200%	＝実効的に画面が狭くなる
サイト内検索	使えない
ページ内検索	使えない
「戻る」	3回まで
打ち切り	15クリック / 8分

また、ツマヅキには現在、5種類のペルソナが用意されています。

プロファイル	画面	いちばん効いている制約	打ち切り
`control`（対照群）	1280×800	制約なし。検索も戻るも自由	30クリック / 15分
`senior-70s`	1280×800 の200%	理解率30%未満の語が消える	15クリック / 8分
`resident-n3`	スマホ相当	行政の難しい漢語が消える^※1	20クリック / 10分
`smartphone-novice`	スマホ相当の150%	文字情報を渡さない（画面だけ）	12クリック / 5分
`busy-worker`	スマホ相当	語の制約はなし。とにかく短い	8クリック / 2分

※1 『やさしい日本語書き換え例』（出入国在留管理庁・文化庁 2020）の指定134語。これは理解度調査ではないため、この語には理解率の%を出しません。

ブラウザ操作は Playwright ですが、システムにインストールされたChromeを動かしています。
Playwright同梱のブラウザは指紋が違ってボット判定に引っかかりやすく、それだと「サイトが難しくて失敗した」のか「弾かれただけ」なのか区別できなくなるからです。

📷 図1：/request の条件入力画面
ペルソナを選ぶと、どんな制約がかかるのかが同じ画面に並んで表示されるところ。
「高齢者を再現しました」ではなく「この条件で動かしました」だと、画面の中で言い切るためです。

動かしてみる

URLとペルソナと用事を選ぶと、その場で1手ずつ動きはじめます。右側のログに、どこを押し、どこをスクロールしたのかが流れていきます。

そして途中で出てくるのが「この画面で消した語」です。

今回の実行（港区・転入届・senior-70s v1.0）で消えたのは、たった2語でした。

語	60歳以上の理解率	調査時点	消した回数
リンク	10.4%	2004年1月	6回
サイト	7.8%	2003年9月	3回

*出典：国立国語研究所「外来語定着度調査」（n=2115）

しかも「サイト」の3回は、すべて押せるものの名前そのものに掛かっていました。
本文が難しかったのではなく、押すべきものの名前が読めなかったのです。

消えた語はモデルに届く前に消えます。モデルはその文字を一度も見ていません。

📷 図2：実行中の画面

結果

	対照群（左）	高齢者 `senior-70s v1.0`（右）
結果	たどり着けた	クリック予算を使い切った
クリック	4回	15回
時間	43秒	2分27秒
画面に入っていた要素	92個中 26個	78個中 9個
消えた語	0語	2語（延べ9回）
このAIの利用料	$0.023	$0.040

たった2語です。それで結果が分かれました。また、結果画面には、見つかったツマヅキをもとにした改善案まで出ます。「どこで詰まったか」だけでは、受け取った担当者が動けないからです。

「それ、制約を強くしすぎただけでは？」

ここは自分たちが真っ先に疑ったところです。

そして重要なのは、対照群を出すだけではこの反論に答えられないということでした。対照群のクリック上限は30回、高齢者は15回。予算が2倍の側が成功しているので、「単に予算が足りなかっただけ」を否定できていません。

なので、制約はそのままに、クリック上限だけ対照群と同じ30回に上げたプロファイルを作りました。
senior-70s-patient v1.0-exp です。新宿区での3実行がこちらです。

	クリック上限	実際に押した数	時間	手数	結果
対照群	30	5	121秒	5手	たどり着けた
高齢者	15	15	354秒	17手	予算切れ
高齢者（上限を30に）	30	30	705秒	34手	それでもたどり着けなかった

予算の問題ではありませんでした。

そしてこの実験は、主張を正確にしてくれました。「見つけられない」ではなく、**「見つけるのに、これだけ余計にかかる」**です。

1回では言えない。だから125回

ここまでは1回の実行の話です。1回では何も断定できません。

そこで同じ用事（転入届）で、5つの自治体 × 5つのプロファイル、有効125実行を回しました。

自治体	対照群	制約側	離脱率
渋谷区	4/6	23/24	4%
群馬県大泉町	5/5	15/22	32%
浜松市	4/4	9/19	53%
新宿区	4/4	6/17	65%
港区	4/4	1/20	95%

港区を見てください。**制約なしなら4回中4回とも終わります。**通れないサイトではないのです。
それでも制約側は20回のうち1回しか着かない。

そして渋谷区の4%が存在することが、どんなサイトでも悪く出る装置ではない証拠になります。
片方だけなら装置を疑うべきですが、両方が同じ装置から出ています。

OrcaRouter：飾りではなく、企画の成立条件でした

ここは強調させてください。OrcaRouterがなければ、この企画は成立していません。

1回の実行で数十回、125実行なら数千回のLLM呼び出しが発生します。
2人チームで、これを全部フロンティアモデルで回す予算はありません。

OrcaRouter は、APIキー1本で162モデルに同じ書き方で投げられるサービスです。
使ってみて、想像していたより効いたのは次の4点でした。

① モデル比較が「実験」ではなく「日常作業」になった

モデルを変えるのが文字列1つの書き換えで済みます。
アカウント作成もSDK差し替えも課金窓口の追加もいりません。

おかげで、全く同じ入力（新宿区の住民異動届ページの断片を分類させる）を8モデルに投げて、
実測で選ぶということが半日でできました。

モデル	判定	実費	応答時間
google/gemini-3.1-flash-lite	✅ 正	$0.000075	1.0秒
google/gemini-2.5-flash-lite	❌ 不一致	$0.000029	1.2秒
qwen/qwen3.7-flash	❌ 形式無視	$0.000112	—
openai/gpt-5-mini	✅ 正	$0.000507	3.5秒
google/gemini-3.6-flash	✅ 正	$0.002354	3.0秒
anthropic/claude-sonnet-5	✅ 正	$0.002384	3.5秒
anthropic/claude-opus-5	✅ 正	$0.005960	5.6秒
anthropic/claude-haiku-4.5	✅ 正	$0.006910	6.6秒

（2026-08-11 実測）

② 「定価表だけ見て選ぶと間違える」ことが分かった

上の表の最下段を見てください。haiku-4.5 が opus-5 より高いのです。

理由は、指定した出力形式をプロンプトに展開する方式がベンダーごとに違うためでした。
同じ依頼なのに、入力トークンが opus/sonnet の 947 に対して haiku は 6620 に膨らんでいました。

これは定価表を眺めていても絶対に気づけません。
OrcaRouterが返してくるレスポンスにその呼び出しの実費が入っているから見つかりました。

③ 実費が返ってくるので、「推定」ではなく「実測」で原価を書ける

私たちは「推定値を実測と呼ばない」を絶対ルールにしています。
OrcaRouterのおかげで、1呼び出しずつ実費を cost_source: "api" として台帳に残せました。
レポートに載っている金額は、全部その積み上げです。

④ そのうえで、自分たちで振り分けた

orcarouter/auto に任せる道もありましたが、それだと削減したのはOrcaRouterであって
私たちではありません。なので役割ごとに自分で指定しました。

基準は価格ではなく「間違えたとき何が壊れるか」です。

役割	選んだモデル	なぜ
画面を読む	gemini-3.1-flash-lite	後続の全手がこれを食べる。最安帯で唯一フロンティアと判定が一致した
次の一手を決める	gpt-5-mini	形式を守るのが安定。判断の下限として置く
たどり着いたか判定	gemini-3.6-flash	ここを誤ると実験結果自体が嘘になる。sonnet級の精度でより速い
なぜ詰まったか説明	gpt-5-mini	★下記

最後の1つが面白い発見でした。
当初は説明文の生成をフロンティアモデルに任せていました。レポート本文だから良い方がいいはず、と。

実測したら、1実行 $0.072 のうち $0.037 が説明1回でした。半分です。
同じ入力を gpt-5-mini に振り直したら $0.0055、しかも文章はむしろ具体的になりました
（ページ名や配置場所まで指摘してくる）。

「高いモデルのほうが良い文章を書く」は、この作業では成り立ちませんでした。
入力がすでに実測された事実として整理されているので、残っている仕事が文章を整えるだけだったからだと思います。

結果

	金額
実支払い（125実行）	$4.2314
全部フロンティアモデルで回した場合	$39.9803
差	89.4% 削減

$40は2人チームには重い金額ですが、$4.2なら回せます。
やれる回数が10倍になるというのは、検証の質そのものが変わるということでした。
125実行という数字は、OrcaRouterがあったから出せた数字です。

主張すること / しないこと

ここは慎重に線を引いています。

しない主張	する主張
実際の高齢者はこう行動する	このプロファイル v1.0 の実行結果である
この数字が世の中を代表する	n=◯ の制約プロファイル実行結果である
AIが人間の代わりになる	人に聞く前に、当たりをつけられる

レポートに出る数字には、必ずプロファイルの id + version が付きます。
切り離した瞬間、検証できない主張になってしまうからです。

私たちが言いたいのは、これだけです。

「使いにくい」は、これまで感想でした。それを、出典の付いた数字にできます。

数字になれば、直す順番が決められます。

限界

正直に3つ書いておきます。

語彙データは2003〜2004年の調査です。当時の60歳以上と今の60歳以上は同じ人たちではありません。それでも使っているのは、これが出典を示せるデータだからです。
**同じ条件でも結果は揺れます。**モデルの出力にばらつきがあるためで、だから1マス単位の断定はせず、必ず回数で見ています。
**消す語は、常に少なめに倒しています。**調査に載っていない語は消しません。「これは控えめな見積もりです」と言えることを、安全側の設計にしています。

それでも、ここから先がある

限界の3つは、どれも構造の問題ではなく、データと回数の問題です。

新しい理解度調査を足せば、語彙の精度はそのまま上がります。実行回数を増やせば、揺れは平均に収束します。モデルの推論が安定していけば、同じ制約でも結果はもっと再現するようになります。

そして何より、画像を読めるモデルが安く速くなれば、さきほど「設計どおりに動いていない」と書いた smartphone-novice が本来の姿で動きます。「文字は見えているのに、小さくて読めない」という、今はまだ測れていないツマヅキが測れるようになる。

ここがいちばん楽しみにしているところです。

つまりこれは、時間が味方をしてくれる種類のプロダクトです。仕組みはもう動いていて、あとは足していくだけ。そこが作っていていちばん楽しいところでした。

誰かが諦めた場所を、感想ではなく数字で見つけられるように。そこまで持っていきたいと思っています。

長い文章を最後まで読んでいただき、ありがとうございました。

技術構成


ブラウザ操作	Playwright（システムインストールのChrome）
LLM	すべて OrcaRouter 経由（役割ごとに4モデルへ振り分け）
画面	Next.js（`/` → `/report` → `/report/detail`）
ランタイム	Node.js（型ストリップでビルドステップなし）
語彙データ	国立国語研究所「外来語定着度調査」／出入国在留管理庁・文化庁『やさしい日本語書き換え例』

リポジトリ：https://github.com/pys573/AI_HACK2026

AI HACK 2026 応募作品です。