100 DAYS / 100 APPS

1日1個、Webアプリを作って公開する実験と記録

52 / 100公開済み

X@haranishi_ikki GITHUBharanishi/hundred-days

公開アプリ52本

制作時間（記録分）95時間22分記録済み 31/52 日

制作日数48日

つくったアプリ

新しい順

Day 052公開中

湯けむり日本地図

日本地図の県庁所在地に都道府県ごとの柱を立て、源泉の数・温泉地の数・湧き出る量・銭湯の数を比べる。県を押すと、OpenStreetMapに登録された温泉・銭湯の点が出て、Googleマップで開ける。行ったお風呂には印を付けられ、記録は端末に残る。

onsen
map
open-data

所要時間3時間55分

アプリを開く

制作メモ

AIに任せた: 着手前に国の統計3つとOpenStreetMapを測った。源泉の数は大分県5,094か所が全国の約18%で飛び抜けること、銭湯は東京都429軒・青森県261軒・山形県0軒で、全国では4年で501軒減ったことを確かめてから設計に入った／環境省の都道府県別の表（PDF）と、厚生労働省の衛生行政報告例の第9表（CSV）・概況（PDF）から県ごとの数を読み取る変換ツールを作った。県の和が原本の計・全国と合わなければ止まる。銭湯は一般公衆浴場だけを数え、個室付浴場などを含む総数は使わない／OpenStreetMapの公衆浴場を47都道府県ごとに取り、重複・私用・閉業を除いたうえで、同じ県・同じ名前で100m以内の二重登録（点と建物の輪郭）をまとめた5,208件を、地図データの記載→名前→判断できずの順で5つの種類に分けた。名前が「〇〇湯」なだけでは銭湯と決めない／ユーザーストーリー8本とUX5階層。ここで実装が7件変わった（既定を源泉の数に・見出しに1位の県と数を文で出す・種類の登録なしを独立の色に・銭湯は一般公衆浴場だけ・地図が出ない端末では順位の表を主画面に・営業時間は地図データの記載と断る・0軒の県は柱を立てない）／MapLibreの柱（fill-extrusion）をfeature-stateで地面から伸ばし、傾けた地図に全国や県のお風呂が収まるカメラを、点を実際に画面へ投影して決めるようにした。全国の構図は、3つの画面幅で向きと傾きの組み合わせを投影して比べ、主な4島がいちばん大きく入り、北海道と九州が切れないものを選んだ／UI採点を2周。別の担当がスクショだけを見て採点し、12/20から18/20で合格した。県を押せる合図・県の画面の見出し・順位の棒の縮尺・点の配色（Okabe-Ito）などを直した／実装、ユニットテスト81件とE2E 42件
自分でやった: 温泉と銭湯のマップ・可視化・全国という方向の指定
失敗と修正: 全国の地図が引きすぎて（390px幅でズーム2.95）、柱が細い針のようにしか見えなかった。MapLibreの範囲合わせ（cameraForBounds）は地図の傾きを考えないので、奥が縮み手前が膨らむ分を見込めていなかった → 傾けた状態で県庁所在地と列島の端を画面へ投影し、枠に収まるいちばん大きいズームを二分探索で決めるようにした（390px幅で3.42）。県に寄るときも同じ方法でお風呂の点を収める
設計メモの「5,697件（重複6・私用10・閉業2を除いて5,685件）」は引き算が合わなかった（5,697−18＝5,679） → 取得した応答から数え直し、47県の応答の計は5,703件で、5,697件は重複6件を除いたあとの数だと確かめた。出典の文書にはこの順で書いた
「日本の外」を四角1つで判定していたので、ソウル・釜山・ウラジオストクも日本の中と判定されていた → 列島を7つの四角の和で持つ形にし、近くの都市が外、離島（対馬・八丈島・与那国島・南鳥島など）が中になることをテストで固定した
スマホの見出しで題名が「湯けむり日…」と切れ、PCの幅400pxのパネルでも「湯けむり…」と切れていた → 狭い画面ではDAY番号を省き、PCでは題名の上の小さな行に回した
傾けた全国の地図で、スマホの細い柱（約5px）のまわりを押すと、押した所より下で止まっている手前の青森県の柱が選ばれた。柱の根元より上なら横のずれだけで比べていて、柱の頭の高さを見ていなかった → 柱の画面上の形（根元から頭までの帯と、柱の太さ）を当たり判定で求め、押した位置から形までの距離がいちばん近い柱を選ぶようにした
日本の範囲を表す四角のあいだに隙間があり、九州の南端の佐多岬（北緯30.99度）が「日本の外」と判定されていた。主な4島の外形の点を足したテストで見つかった → 九州の四角の南端を南西諸島の四角とつなげ、佐多岬をテストの「日本の中」に加えた
傾きを弱めると、画面の端の柱がかえって大きく斜めに倒れて見えた。柱の倒れは透視（視野角36.87°）で起き、傾きが小さいほど強まる → 傾きは40°に抑えたうえで地図の視野角を15°に狭めた。端の柱の倒れ角は、390px幅で11.2°から7.4°、PC 1440×900 で31.4°から10.7°になった
左下に置いた「沖縄県 ↙」の案内が、鹿児島県の柱の根元の文字に重なった。地図の中の帰属表示の（i）も24pxで、押せる大きさ44pxに届いていなかった → 全国の構図の下に60pxの余白を取り、案内と根元の文字の分を空けた。（i）は44pxにして、押せる大きさのテストに加えた
同じお風呂が点と建物の輪郭で二重に登録され、一覧に同じ名前が2行並んでいた → 同じ県・同じ名前で100m以内を1件にまとめた（477件）
開いた直後、地図のタイルが届く前に柱が伸びきっていて、日本の形が出る前に動きが終わっていた。デモの1コマ目を切り出していて気づいた。最初に待った idle は全国の構図へ移る前のもので、データが届き始めた合図で確かめると、新しい範囲のタイルをまだ頼んでいない瞬間に「未着なし」と判定された → 全国の構図へ移ったあとの idle で、映している範囲のタイルが全部届いたことを確かめてから伸ばす。遅いときは2.5秒で待つのをやめる

Day 051外部で公開

ハコニワ — 全国3Dミニチュアマップ

全国1,741市区町村・309,253施設から、気になる街と行き先を探す地図。施設の種類を自作の3Dミニチュアで表示します。実物の建物を精密に再現したものではありません。

地図
3D
旅行

紹介ページを開く

制作メモ

AIに任せた: 全国施設データの整備、地図・3D表示・地域検索の実装、出典整備と動作検証
自分でやった: 全国への拡充方針、上部表示を全国に統一する指定、Day51としての公開判断
失敗と修正: 代表的な観光地だけでは全国の市区町村を十分に探せなかった → 公開データから自治体別カタログを作り、公開対象を309,253施設へ拡充。収録数が少ない地域も実数を表示
公開に必要な出典表示とデータ・ソフトウェアの利用条件が不足していた → 常時表示のクレジット、出典ページ、加工済みデータのダウンロード、ライセンス原文を追加

Day 050公開中

名画の、その先。

名画の一部から作品を当てる、5問の小さな美術館。実際の作品画像と3D展示を楽しみ、答えの後には制作背景や表現の意図を出典つきで読めます。

アート
クイズ
3D

アプリを開く

制作メモ

AIに任せた: 所蔵館の資料・素材の確認、30作品のゲームと3D展示の実装、検証／実画面を使ったプロモーション動画・合成BGM・X投稿案の制作
自分でやった: 名画クイズの選択、実作品・3D素材と制作背景の解説を入れる方針／作品数の増補、プロモーション動画とX投稿案、PR作成・マージの依頼
失敗と修正: 所蔵館の画像配信が403で取得できなかった → 作品ID・所蔵番号・権利を照合したWikimedia Commonsの公開画像を同梱
タブレットで額縁が切れ、スマホの共有欄がはみ出した → 展示カメラと平面表示のサイズ、共有欄の最小幅を調整し3画面幅で再検証

Day 049公開中

ぱたにゃん

タップで猫が前足をぱたぱたさせて羽ばたき、爪とぎポールのすき間をくぐるワンタップゲーム。すき間の魚を集めると、新しい柄の猫が仲間になる。日付で全員同じ「きょうのコース」と、毎回違う「いつでもモード」。ぶつかっても猫はずっこけて目を回すだけ。広告・登録・外部通信なし。

ゲーム
ワンタップ
canvas

所要時間3時間39分

アプリを開く

制作メモ

AIに任せた: 競合11本・遊び手の声・名前の衝突の調査（スタートアップスキル2本）と、要件定義・UX5階層／物理・当たり判定・コース・難しさの曲線・画面の流れ・保存・共有文を、画面に触れない部品として実装し、単体テスト80件で固定／猫6柄・爪とぎポール・時間帯で変わる空・結果カード・OGP画像を、画像素材を使わず Canvas の図形だけで描いた／体験の評価を4周（17→13→16→19/20）と見た目の採点（18/20）。評価役がブラウザを動かせない周は、操作ログとスクショを証拠にして採点させた／Day 049 への組み込み（公開URL、100日チャレンジ共通の共有欄、E2E をこのリポジトリの形へ移す、デモ動画）
自分でやった: 題材の指定（羽ばたいてすき間をくぐるゲームを猫で）と、スタートアップスキルで市場を調べてから機能と UI/UX を決める進め方／評価ループを回して体験の点を上げる指示／Day 049 として公開する指示
失敗と修正: 縦長のスマホで、猫が空の途中の見えない天井で止まって見えた。端末で難しさを揃えるため、すき間を置く帯の高さを固定していたのが原因 → すき間を置く帯はそのままにして、猫が止まる天井だけを画面の上端（耳の先が残る位置）に分けた
評価で「20回連打しても19回しか羽ばたかない」とされ、不合格になった → 1タップずつ記録し直すと、飛行中の取りこぼしは0だった。天井に張り付いた猫がポールに当たって墜落し、墜落中のタップが無視されていただけで、測り方の穴だった。連打の検査はポールが来る前に行う形にした
当たった所に出る星が猫の顔に重なり、目と鼻が隠れた → ポールの星を接点から猫と反対側へ離し、猫より後ろに描くようにした
30本を過ぎると難しさが変わらず、失敗の理由も次に目指す本数も画面に出ていなかった（体験の評価で1点が4項目） → すき間を60本目まで狭め続け、失敗の原因を一言で出し、近い目標と10本ごとに変わる空を足した（体験16→19/20）
テストに日付の決め打ちがあり、日付が変わった9/25に E2E が2件落ちた → テストではブラウザの日付だけを 2026-09-24 に固定した。ゲームの時間は別の時計で進むので影響しない

Day 048公開中

いま食べたいもの、当てます

占い師の質問に答えると、水晶玉があなたの心にある料理を当てる。答えるほど読みの輪が満ち、100%で答えが見える。まだ決めていない人には、いま食べたいものを1つに。外れたら教えると、その端末の中だけで賢くなる。

ゲーム
占い
推理

所要時間4時間46分

アプリを開く

制作メモ

AIに任せた: 料理154品×質問76問のデータと、確率で推理するエンジン（質問の選び方・推測の判断・決め手・読みの輪）の実装／全154品の当てシミュレーションを含む単体テストと、推理をわざと壊してテストが落ちるかの確認／料理154品の3D画像をAIの画像生成で作り、9品ずつのタイルから区切り線を画素で探して切り分けた／占い師と水晶玉のSVG、画面、キーボード操作、端末の中だけの学習、E2E／体験評価2周（15/20→19/20）とUI採点（18/20）を別セッションで実施し、指摘を推理と画面に反映／プロモ動画の描画ツールと、3/4拍子のワルツのBGM（2案）の合成
自分でやった: 題材の方向（占いのゲーム、もしくは質問で当てるゲーム）の指定と、3案からの選択／Day 047 は別の作品で決まっているので Day 048 として出すという指定／ローカルで触ったうえで、答えるほど近づき100%で答えが出る形、遠ざかるのも見える形、料理の絵を質の高い3Dにすることの指示／採点して実装に戻すループを回す指示
失敗と修正: つけ麺・エビフライ・カキフライは、当たるまで25問かかった。似た料理を見分ける質問が無かった → 「エビを使う？」「つゆにつける？」「具をはさむ？」などを足し、正直に答えれば全154品が最長13問で当たるようにした
まだ料理を決めていない人（気分が2品のあいだで揺れる人）への最初の推測が、シミュレーションで中央値24問目だった → 10問を過ぎたら推測に踏み切る基準を1問ごとに下げ、中央値16問目にした。「たぶん」が多い人には提案として早めに出す
一覧に無い料理を思い浮かべた人に、はっきり答えたことと食い違う料理を推測していた（「カレー味？」にいいえと答えたのにグリーンカレー。156回中103回） → 答えと食い違う料理は推測せず、推測できる料理が残らなければ25問を待たずに「参りました」と言うようにした（0回に）。引き換えに、明らかな事実を何度も言い間違える人の成功率は下がる
触ってみると、答えるたびにどれだけ近づいているのかが分からなかった → 水晶玉のまわりに読みの輪（推測の瞬間にだけ100%）を足し、答えるたびの上下の差分と、1問ごとの読みの軌跡を出した
料理の絵がOSの絵文字で、たこ焼きがタコの絵になるなど、出てくる料理の質が低かった → 154品の3D画像をAIの画像生成で作って差し替えた。読めないときは絵文字に戻す
スマホで押した答えの跡が次の質問に残り、2連続タップで見ていない質問に答えが入った → ホバーの見た目をマウス操作の端末に限り、新しい質問が出てから350ms（1問目は400ms）は答えを受け付けないようにした
ファイルに書いたエスケープ表記が実際の文字に変わり、正規表現に行区切り文字が入って読み込みごと失敗した → 文字コードから組み立てて書き直し、ソースに見えない文字が無いことをテストで固定した

Day 047公開中

ねこ、光になる

画面を上下にこすると猫が加速する3Dゲーム。道の先の物を弾き飛ばし、20の速さを追い越して、光速の壁で時間の遅れを体験する。

ゲーム
3D
物理

アプリを開く

制作メモ

AIに任せた: 改善計画・採点表・3周の採点を別のAIが担当（序盤の加速・1画面の構成・世界の象徴・読める衝突・光の猫の5本柱）／加速曲線、斜め後ろ上から追うカメラ、6世界の背景、的と衝突、光の猫、二つの時計、結果の写真の実装／受け入れテスト（単体・E2E）の作成と、実ブラウザでの撮影・計測
自分でやった: 題材・指定速度・演出・操作方式（指を送った量で加速）・衝突の追加の指定／猫の3Dモデルと録音素材の提供、品質の判断（v2を「品質が低すぎる」と差し戻し）
失敗と修正: 押し続けても8秒で0.9km/h、街に着くまで約24秒かかり、序盤の変化が遅かった → 最大推力での到達時刻を先に決める加速曲線に置き換え、最初の通過0.8秒・街9秒・完走49秒にした
縦長の画面では猫の進む先がすぐ画面外で、弾く物が鼻先に突然現れていた → カメラを斜め後ろ上へ回して道の先を画面の奥へ伸ばし、的が3〜5個先まで見えるようにした
光の尾がカメラ側へ伸び、灰色の筒に見えた → カメラに面を向ける柔らかい帯に作り替え、幅と長さの両方で透明へ落とした
速度の桁が増えると上部の欄が横に伸び、画面が一瞬空になった → 欄の幅と高さを固定し、大きさが変わった直後に描き直すようにした
街で通りの奥まで家が見えるようになり、三角形数が上限を超えた → 重い家を2種×3棟に絞り、間を軽い手続き形状の家で埋めた
指をゆっくり小さく動かすと推力がたまらず、猫がまったく進まなかった → 送った距離の蓄えに、直近の指の速さに比例する推力を足し、ゆっくりこすればゆっくり進むようにした
指定されたゾウガメ1.4km/hの計測資料を確認できなかった → 指定値を維持し、出典欄と制作記録に未確認の残件として明記した

Day 046公開中

泣ぐ子は、いねがぁ

大晦日の夜、なまはげが山から里へ。移動とジャンプだけで家々の戸口を巡る20面のドット絵アクション。敵を踏み、餅で大きくなり、能力を拾って上の棚を狙う。

ゲーム
アクション
canvas

所要時間5時間4分

アプリを開く

制作メモ

AIに任せた: 要件定義とユーザーストーリー・UX5階層の作成／ゲーム本体（固定1/120秒の物理・敵と動く床・保存・Web Audioの合成音・Canvas描画）の実装／主人公の原画を画像生成で作り、それを下敷きにドット絵を1マスずつ置いた。新しい敵・アイテム・足場の絵8点も同じ方法／初版が退屈だったので、別モデルに設計書（敵3種・能力3種・仕掛け・3お札・10項目の採点表）を書かせ、物理担当と画面担当に分けて2周実装した／雪うさぎ（止まって跳ぶ）・雪かきイノシシ（予告→突進）、風呂敷（滑空）・駆け鈴（加速）、雪台・崩れる枝、面ごとの3お札と得点の巻戻し／20面の手作業の再配置と、跳べる距離（滞空0.667秒×110px/s＝73px）から逆算した数値の決定／観測ログと自動操作（safe/collect）で、20面の到達・全回収・固定再生の全tick一致・能力なし主路を単体テストに固定（154件）。E2E 9件／実ブラウザでの目視、スマホ幅のHUD調整、デモ動画とスクリーンショットの撮影
自分でやった: ジャンル（ドット絵のアクション）・面数・進化という遊びの骨格の指定／キャラクターを画像生成で作る方針と、主人公をなまはげにする選択／初版を遊んで「つまらない」と判断し、敵と能力を足す方向と、設計・実装・採点の役割分担を指定／旧Day046を差し替えてこの作品をDay046として出す判断、マージの指示
失敗と修正: 20面を自動生成に任せたら「平らな床に穴と小物」だけになり、到達性のテストは全部通るのに遊びにならなかった → 生成をやめて20面を手で引き直した。1面につき新しい仕掛けは1つ
3マスの穴を跳び越せなかった。滞空0.6秒×88px/sで52.8pxしか進まないのに、体の幅を足すと60px必要 → 最高速110px/s・ジャンプ初速-300（滞空0.667秒＝73px）に変え、数値を1か所にまとめた
戸口の当たり判定が1マスぶんしかなく、跳んだまま通り過ぎると面の右端で詰んだ → 当たり判定を縦いっぱいの柱にし、絵だけ1マス描く
原画を自動縮小したら10×14では顔がつぶれて赤い塊になった → 原画は色と輪郭の下敷きにして、ドットは1マスずつ置いた。原画はタイトル画面に出した
初版を本人が遊んで「つまらない」。敵が20面で14体、上段を取りに行く理由もなかった → 別モデルに設計書と採点表を書かせ、敵4種・能力2種・雪台と崩れる枝・3お札を2周で入れた。敵は54体、全回収できる報酬路を20面に用意
採点1周目は1/20。半分以上が「証拠が足りず未確認」で、証拠の取り方が採点表と違っていた → 固定入力の再生と全tick比較、能力なし主路、能力の前後比較、4死因×3のミス再現を機械で取る形に作り直した（2周目10/20）
公開前チェックをパイプに通したせいで終了コードが消え、NGのままコミットしてしまった → 出力にNGがあれば止める書き方に変え、契約ファイルからローカルの絶対パスを消した

Day 045公開中

その撃ち方、読まれてる

自動連射で敵艦隊を撃ち落とし、アイテムとウェーブ突破でレベルアップするシューティング。動いて撃ち癖を分散し、敵の裏をかこう。

ゲーム
シューティング
canvas

所要時間4時間21分

アプリを開く

制作メモ

AIに任せた: 仕様に沿ったCanvasゲーム、撃ち癖と居場所癖の学習ロジックの実装／キーボード・ポインタ操作、端末保存、Web Audio合成、画像欠損時の図形描画の実装／単体テスト76件とE2E20件、デモ・プロモ動画ツールの作成／読み取り専用の独立レビューと指摘の修正／体験評価2周（12/20→18/20）とUI採点（17/20）を別セッションで実施し、指摘を反映／熱の帯を輝度の階調へ作り直し、波ごとの難度・▽の初回ヒント・読まれ度の色分け・結果画面の共有を追加／自動連射への作り替え（撃つ入力の廃止・熱を発数でなく居た時間で積む方式への変更）／アイテムとLV1〜30の強化表、上限後のアイテムを得点に変える仕組みの実装／上手いプレイヤーを模した決定的なシミュレーション（tools/tune.mjs）を作り、敵側の定数を測りながら詰めた／実ブラウザで遊ばせてスクショを撮り、画面の読みにくさを見つけて直した
自分でやった: 題材の選択と制作の依頼／画像生成をAIに任せる方針の指定／自動連射とレベルアップという方針の指示／強化の決まり方（拾った順に固定で伸びる）とレベルの持続範囲（1プレイ内のみ）の選択
失敗と修正: 居場所の標本が浮動小数の誤差で200msの境界から遅れていた → 境界比較に誤差の許容を加え、1秒で5標本になることをテストした
小画面ではCanvasの文字が14px未満に縮小された → 描画倍率に応じて文字サイズを補正した
読まれ度が1発撃っただけで100に振り切れ、学習が伝わらなかった → 同じレーン6発で最大になる正規化熱と、標本15件で立ち上がる居場所の集中に分け、0.6対0.4で合成した
短い画面ではキャンバスが伸びて自機と防衛線が画面の外へ出ていた → キャンバス幅の上限をビューポートの高さから決め、開始と再挑戦のたびにHUDの上端までスクロールするようにした。ツールバーが3px切れる問題は上限を (100svh - 220px) × 0.75 に詰めて解消した
自弾1発・8列40隻ではウェーブ1が終わらず、体験評価が12/20で落ちた → 自弾を2発に増やし、艦隊を7列28隻（2波以降35隻）へ減らし、開幕3秒の猶予と敵弾のばらつきを足した
ウェーブ通過の表示と得点ポップが同じ高さで重なって読めなかった → 全滅の瞬間に浮き文字を消してから通過の文字を1件だけ置き、WAVE表示と高さを分けた
熱の帯を半透明の赤で描いていたため、暗い背景では熱の差が見分けられなかった（実戦域で背景比1.5〜2.0:1） → 不透明度ではなく輝度の階調に変え、熱0.3で3:1、熱1.0で8:1を超える色にした。上限の熱には白い線も足した
熱が上限を超えて溜まり続け、長く止まった人ほど逃げても読まれ度が下がらなくなった（20秒止まると離れて4秒経っても振り切れたまま） → 生の熱を上限6で頭打ちにし、減衰の時定数を5秒から3秒に縮めた。止まっていた時間に関係なく同じ速さで冷めることを単体テストで固定した
難易度の自動調整が「所要時間」だけを見て、敵弾を2,572px/s（画面を249msで横断）まで速くした。見てから避けられない → 弾速に上限620px/sを設け、到達まで0.45秒を確保した。圧は弾数と撃つ間隔で作り直した
次の調整では艦隊の行進が通常の30倍になり、死因が「撃たれて」から「押し潰されて」に変わった。調整用ボットが超人的に避けるため、それを殺せる設定が人には理不尽になっていた → 所要時間を目標にするのをやめ、行進速度の上限4倍・同時敵弾30発・弾速620px/sという人が遊べる条件を先に固定して、数値は設計判断で決めた
常時30発以上の自弾が画面上端の「撃ち癖の熱」の帯を横切り、中核の指標が読めなくなった → 自弾を帯の下端（y=56）で消すようにした。艦隊の最上段には届くことをテストで確かめた
デモの自動操縦が落ちてくるアイテムの真下で3秒止まり、見せたくない「止まって読まれる」動きを実演していた → アイテム追従をやめ、画面幅を往復し続けて迫る弾だけ避ける動きにした。自動操縦の読まれ度の平均が45未満であることをテストで固定した

Day 044公開中

Tokyo Railscape — 東京の電車を、眺める。

東京の5路線をイメージした3Dミニチュア。架空の48編成を追いかけ、前方の風景を眺められます。実際の運行・ダイヤとは連動しません。

交通
3D
Three.js

アプリを開く

制作メモ

AIに任せた: 設計と実装、検証
自分でやった: 電車位置の可視化というテーマと制作の依頼
失敗と修正: 最初の案を2Dの乗車案内と解釈した。 → 補足を受け、街・線路・車両を主役にした3Dビューへ変更。

Day 043公開中

退去費用、相談の準備

退去費用の請求内容・気になる点・手元の資料を整理して、相談に持っていけるメモを作る。わからない項目は空欄のままでよく、コピー・テキスト保存・印刷に対応。請求の妥当性や支払義務は判断しない。

暮らし
相談準備
プライバシー

アプリを開く

制作メモ

AIに任せた: 国民生活センターと消費者庁の相談案内の確認／ユーザーストーリーとUX5階層の整理、3段階の入力と相談メモの実装／任意の端末保存、コピー・テキスト保存・印刷の実装／単体・ブラウザテスト、独立レビューに基づく修正／一覧画像と実画面の紹介動画の作成
自分でやった: テーマの選択と制作の依頼
失敗と修正: 端末保存が拒否されると、画面の入力の全消去まで止めていた → 画面の消去と端末の保存データの削除を分け、削除失敗時は残存と次回復元の可能性を知らせるようにした
スマホで相談メモの本文が小さかった → 画面用の本文を14px、資料を13pxへ拡大し、印刷用の文字サイズと分けた

Day 042公開中

台風、うちに来る？

市区町村をひとつ決めると、その地域が台風の暴風域に入る確率を、気象庁の発表そのままに1行で答える。気象庁はこの確率を地域ごとに出しているのに、地方→都道府県→地域とたどる必要があって、市の名前からは直接引けない。3時間ごとの帯で「何時が山か」を、地図で予報円との位置関係を見られる。台風が無い日は「いま、台風はありません」と答えて空白で終わらせない。

typhoon
disaster
jma

所要時間3時間11分

アプリを開く

制作メモ

AIに任せた: 着手前のデータ実測。第三者記事にあった気象庁のURLは2本とも使えず（404と、5月の台風のまま止まった索引）、台風ページのHTMLに埋め込まれたJSから実際の4本のJSONを見つけた。防災情報XML（1.85MB）と突き合わせて、値が1件も違わないこと、CORSが「*」でブラウザから直接読めることを確かめた／要件を実データで決めた。確率の地域は一次細分区域（142）ではなく「市町村等をまとめた地域」（375）で、市区町村1805件すべてに親があること。時刻は3時間区間の終わりを指すので、画面では「9時〜12時」と区間で書くこと／実装、ユニットとE2E、コードレビュー、スクショでのUI採点と修正、デモとプロモ動画
自分でやった: 4案からの選択／実機での確認とX投稿
失敗と修正: 公開前チェックに当たった英名を消すため、市区町村の対応表（area.json）をJSONとして読み直して保存した。先頭が0でないコードだけが前に並び替わり、生成した1805件の並びが「群馬が先頭、鹿児島が末尾」になった。自分たちが調査メモに書いた Object.keys() の罠を、フィクスチャ側で踏んだ → コードレビューが「秋田は東京より北」のユニットが赤いことで気づいた。並びの手がかりに残っていた生成済みデータの順で対応表を書き戻し、英名の除去は文字列置換だけで行い、再生成した結果が元と一致することを確かめた
投影の式で、経度を度・緯度をラジアンで計算していて、地図の縦横比が π/180 だけ潰れていた → 実装の途中でテストから見つけ、両方を度に揃えた。この比をテストで固定した
「5%を超えるのは21日0時〜3時から」と書いていたが、その区間の発表値はちょうど5%だった。発表値の言い換えとして事実と食い違う → コードレビューの指摘で、判定はそのまま文言を「5%以上になるのは」に直した
現在地から市区町村を当てる方法を「代表点にいちばん近い市区町村」にすると、東京駅は中央区（1.66km）が千代田区（1.72km）より近くなり、駅がある区と食い違う → 気象庁が配っている市区町村の外接矩形を同梱し、矩形に入るものの中で矩形の中心が近いものにした（千代田区1.13km・中央区1.34km）
curl でCORSの有無を判定しようとして「無し」と読み違えかけた。Origin ヘッダを付けずに叩くと同じURLでも access-control-allow-origin が返らないことがある（応答が Vary: Origin を持ち、CDNがオリジン無しの版を返す） → Origin を付けて叩き直して「*」を確認した。CORSの可否は素の curl で判定しないことをメモに残した

Day 041公開中

この道、誰がケガしてる？

場所をひとつ決めると、その周りで2019〜2024年に実際に起きた人身事故を地図に出し、誰が巻き込まれたかを件数で答える。警察庁は全国の人身事故を1件残らず緯度経度つきで公開しているのに、1年ぶんが56〜70MBのShift_JIS、座標は度分秒を潰した整数という形なので、普通の人には開けない。手元で数えられる形にした。件数は交通量で割っていないので、危険度の判定はしない

traffic-safety
open-data
npa

所要時間1時間54分

アプリを開く

制作メモ

AIに任せた: 着手前の実測。6年ぶん375MBのCSVを全件解析し、190万件すべての座標が読めること、列の数が年で違うこと（2019〜2021年は58列、2022〜2024年は68列）を先に確かめた／要件を実データで削った。年齢は6年とも階級値で、いちばん若い区分が0〜24歳だったため、目玉にするつもりだった「子どもで絞る」を落とした／データ変換の設計と実装。1件6バイトに詰め、地域メッシュで371ファイルに割って、1回の通信を索引5KB＋12〜160KBに収めた／実装、ユニット51とE2E 10、UI採点ループ、デモとプロモ動画
自分でやった: 4案からの選択／実機での確認とX投稿
失敗と修正: ファイル名の年を、事故が起きた年だと思い込んで変換していた。警察庁のファイルは事故が確定した「統計年」で分かれていて、honhyo_2024.csv には2023年の事故が8,477件、2018年以前のものまで入っている → テスト用に切り出した2行の発生年が2023年だったことで気づいた。発生年の列から取るように直し、2019年より前に起きた10,460件は端数なので落とした。重複していないことは、全190万件を都道府県・警察署・本票番号・日時・座標で突き合わせて確かめた（重複0件）
その修正で、行を飛ばすつもりの continue を return と書いた。読み込み中のファイルごと打ち切られ、190万件あるはずが51万件になった → 変換スクリプトが最後に件数を検算していたので、その場で分かった。年別の内訳を出力に足して、2019年のファイルが0件になっていることも見えるようにした
変換スクリプトが読み込まれただけで走り出す書き方になっていて、中の関数をテストから呼べなかった。実装を任せた側から指摘された → 直接呼ばれたときだけ動くようにし、度分秒の変換と列の読み取りにテストを足した。テストが門番になっているかは、年をファイル名から取る変異と交差点コードを1つ落とす変異を入れて、どちらも落ちることで確かめた
公開前チェックが、同梱した371本のバイナリを文字として読んでいた。目視が要る扱いにもなっていなかった → 拡張子を目視対象に足し、同じフォルダに10本を超えるときはフォルダ単位でまとめて出すようにした。検査自体は緩めていない
プロモ動画の字幕に書こうとした高知駅の数字（129件・自転車63件）が、画面に出る値と違っていた。自分が座標を小数4桁に丸めて数えた結果で、アプリが住所検索で掴む座標とは別の点だった → プロモを作らせた側が突き合わせの関門で気づいて止めた。画面の値（132件・自転車61件・歩行者12件）に直し、X投稿文の同じ数字も直した。Day 040 でも同じ種類の食い違いを同じ関門が止めている
main へマージしたあとのデプロイが cancelled で終わった。CIのジョブに15分の制限があり、ブラウザテストがそこに当たっていた（Day 040 で15分1秒、Day 041 で15分13秒） → 上限超過は run の結果が cancelled になるだけで理由が出ず、連続マージによるキャンセルと見分けがつかない。テストのジョブを40分、配信のジョブを20分に伸ばした。100日到達時の見込みは35分前後

Day 040公開中

その避難場所、洪水でも？

場所と災害の種類を決めると、そのとき使える指定緊急避難場所を近い順に出す。もっと近いのに、その災害では使えない場所も名指しで出す。国土地理院が配信する指定緊急避難場所データは災害の種類ごとに8つに分かれていて、同じ公園が地震では使えて洪水では使えない、ということが起きる。避難の判断はせず、指定されている事実だけを出す

evacuation
disaster-prevention
gsi

所要時間1時間49分

アプリを開く

制作メモ

AIに任せた: 着手前の実測。「世の中のためになる」切り口で候補5案のデータ元をすべて叩き、避難場所タイルはCORS可・ズーム10だけ・該当が無い種類はタイルごと404、という前提を先に確かめた／駅5か所（秋田・東京・仙台・高知・名古屋）で「近い5か所のうち洪水で使える数」を数え、近い順と使える順が別物であることを数字で確かめてから設計に入った／ユーザーストーリー10本とUX5階層。ここで実装が6件変わった（近い順と使える順を分ける・2行目に「それより近くに◯か所」・名前は原文のまま・通信量を絞る取り方・0件を説明つきの答えに・ピンは形で分ける）／実装、ユニット21とE2E 11、UI採点ループ、デモとプロモ動画
自分でやった: 5案からの選択／実機での確認とX投稿
失敗と修正: デモ録画で地図が出ないまま止まった。録画スクリプトはページを file:// で開くので、ESモジュールと fetch を使うこのアプリは動かない（Day 008 で踏んだ罠と同じ） → 振り付けの中でミニHTTPサーバーを立てて開き直す形にした。Day 039 の書き方をそのまま持ち込んだ
プロモ動画の字幕で「480m先の小学校」と書いたが、画面の答えは「470m」だった。下調べで出した距離475mを手で四捨五入していて、アプリの丸め方と食い違っていた → 書き出す前に画面の文字と字幕を突き合わせる関門（Day 038 から入れているもの）が止めてくれた。字幕を画面の470mに合わせた
「国土地理院へ送るのは約30km四方の区画の番号だけ」と書いた説明文が、地図タイルの要求を勘定に入れていなかった。結果が出ると地図が寄るので、拡大したタイルの番号も相手に届く → 実装側の指摘で「避難場所データの区画の番号と、地図を描くためのタイルの番号」に書き換えた
デモ動画の頭を6.8秒で切ったら、1コマ目が止まった画面になっていた（スクロールが思ったより早く終わっていた） → 0.2秒刻みでコマの差分を測り、3コマ続けて動いている最初の時刻（5.9秒）から切り出すようにした。1コマ目と0.4秒後の差分で動いていることを確かめた

Day 039公開中

足もとを掘る

場所を選ぶと、その近くで実際に掘り出された化石の記録が、地質年代ごとの柱になって積み上がる。いちばん近い産地から「そこが何年前、どんな場所だったか」を1行で出す。層の色は国際層序委員会の公式カラーをそのまま使うので、地質図と同じ色で読める。真下を推定するものではないので、産地までの距離を必ず添える

fossils
paleobiology-database
geologic-time

所要時間1時間14分

アプリを開く

制作メモ

AIに任せた: 着手前の実測。候補4案のAPIをすべて叩いてCORSと応答を確かめ、CORSヘッダの無いもの（航空機）と、日本の商品がほとんど登録されていないもの（食品成分）をその場で落とした／全国1,741市区町村の代表点から最寄り産地までの距離を計算し、「半径で切ると離島で空振りする」ことを数字で確かめてから設計に入った／ユーザーストーリー10本とUX5階層。ここで実装が7件変わった（半径→近い順・0件を答えに変える・環境は記録が根拠・色はICS公式・層の高さは等間隔＋隔たりを数字で、など）／実装、日本語対応表3つ（年代56語・分類群106語・堆積環境46語）、ユニット19とE2E 9、デモとプロモ動画
自分でやった: 4案からの選択／実機での確認とX投稿
失敗と修正: 着手前に書いた要件では「近い順12件」で柱を組む設計だった。実装前に実データで試したところ、東京は12件のうち8件が同じ更新世で、柱が2層にしかならなかった。地域ごとの違いが出ない → 40件に増やし、産地1件ずつではなく「世」でまとめる方式へ変えた。東京4層・秋田3層・名古屋5層・札幌6層・高知9層になった。80件に増やしても層は増えないので40で止めた
層の色が地の色に溶けるかどうかを測るコントラスト比の式で、sRGBの逆ガンマの指数を2.4ではなく2で書いていた。ペルム紀の赤（#F04028）が4.41と出て「文字が読めない色」と判定され、その層だけ白地に置き換わっていた。正しくは4.68で、色を保てる → 指数を2.4に直した。56ある年代区分のうち色を保てるものが2つから54に増えた。全区間のコントラスト比をユニットテストで固定した
層の中身を固定の高さの箱に入れていたので、産地が多い層では堆積環境と生きものの列挙が箱をはみ出し、中でスクロールしないと読めない状態になっていた。逆に産地が1か所の層は下半分が空いた → 環境と生きものの列挙を「代表1つほか◯種類」に畳み、箱の高さをいちばん中身が多い層に合わせた。どの層も切れず、中でスクロールしなくなった
地図の帰属表示が1画面に3回出ていた。地図の中（MapLibreの常設表示）、地図のすぐ下、画面下の出典欄 → 提供元が求める文言を地図の上と出典欄の2か所に整理した。地図の上の常設表示は消さない
プロモ動画で場所を東京から高知へ変えるとき、現在地の座標を差し替えて「現在地から探す」を押し直したが、アプリが前の位置を60秒キャッシュする設定だったため東京のままだった。字幕は高知の数字を言っているのに画面は東京、という食い違いが起きかけた → 地図を押して場所を変える形にした。あわせて、書き出す前に画面の文字と字幕の数字を突き合わせて、違っていたら止まる関門を入れた

Day 038公開中

昔の1000円、いまいくら

年を選ぶと、そのころの1,000円がいまのいくらにあたるかが出る。逆に、いまの1,000円が当時いくらだったかも同じ画面に出す。丸の面積で買えるものの量を比べ、折れ線でその年が物価の歴史のどこかを示す。世界銀行が配る日本の消費者物価指数で計算し、賃金も為替も混ぜない。確定した最新年より先の予想はしない

cpi
inflation
world-bank

所要時間1時間56分

アプリを開く

制作メモ

AIに任せた: 着手前の実測。候補4案のAPIをすべて叩いてCORSと応答を確かめ、取得を禁じているもの（国土交通省の川の防災情報・青空文庫の非公式API）をその場で落とした／データの素性と規約の確認。世界銀行のデータセットが CC BY 4.0 であること、この指標の原データが IMF の International Financial Statistics であること、帰属と「加工した」表示が要ることを確認し、設計の制約に落とした／ユーザーストーリー10本とUX5階層。ここで実装が9件変わった（答えを操作より上に置く・丸の大きさを面積比にする・逆向きの換算を同じ画面に入れる、など）／実装、ユニットとE2E、デモとプロモ動画、スクリーンショット採点
自分でやった: 4案からの選択／実機での確認とX投稿
失敗と修正: 「この数字が言っていないこと」に書いた『物価が1.17倍でも、収入も1.17倍になったという話ではありません』の倍率が、画面に直接書き込んだ固定の数字だった。1960年を選ぶと答えは6.22倍に変わるのに、この行だけ1.17倍のまま残り、同じ画面の中で数字が食い違っていた → いま出している倍率をそのまま入れるようにした。年を変えたときに答えと注意書きが食い違わないことを、E2Eで1960年・1995年・最新年の3点に固定した
「物価がほとんど動かなかった年」を数える閾値（前年比±0.5%未満）が、浮動小数の誤差で上下非対称になっていた。100→100.5 は 0.49999999999998934 になって『未満』に入り、100→99.5 は 0.50000000000000044 で入らない。同じ0.5%なのに、上がった年だけ数に入る → 比を小数第3位で丸めてから閾値と比べるようにした。上下どちらのちょうど0.5%も数えないことをユニットテストで固定した
丸の大きさ比べで、金額を丸の中に書いていた。1960年を選ぶと『いまの1,000円』の丸が51pxまで縮み、中の数字が消える。左の丸だけ数字があって右には無い、という非対称な画面になっていた → 数字は丸の中ではなく必ず外（キャプション）に出すことにした。丸は大きさだけを伝える図形になり、どんな倍率でも左右が同じ形で読める
通信に失敗したとき、失敗の知らせが画面の700px下に出て、上半分は空のままだった。さらに『年を選ぶ』のスライダーは残るのに金額の候補ボタンだけ消えていた（候補は取得に成功したときにしか組み立てていなかった） → 失敗の知らせを、結果が出るはずだった最上部へ移した。指数が無いと何も計算できないので、押しても反応しない『年を選ぶ』『金額を変える』は失敗中は出さないようにした
上のカードは最新年（2025年）まで、国際比較の行は2国そろう年（2024年）までで計算していたため、同じ『日本の物価の倍率』が1.17倍と1.13倍で並び、どちらが正しいのか分からない画面になっていた → 国際比較の行に、どの年までで比べたのかと、なぜその年なのか（アメリカの指数が2024年までしか出ていない）を書いた

Day 037公開中

バイトの法律、原文はこう

バイトで気になることを10個の札から選ぶと、根拠になる条文の原文がそのまま出る。読めない理由は漢数字と主語なので、漢数字に算用数字のルビを重ね、「使用者」と「労働者」を色で分ける。本文の文字列は1字も変えない。いつ時点の条文かと原典へのリンクを必ず添え、判断はしない。困っている人には無料の相談窓口を案内する

law
e-gov
labor-standards-act

所要時間1時間50分

アプリを開く

制作メモ

AIに任せた: 着手前の実測。候補4案のAPIをすべて叩いてCORSを確かめ、Wayback Machine（CORSヘッダ0・429）を落とした／法律面と規約の確認。著作権法13条1号（法令は権利の目的とならない）、e-Govの公共データ利用規約PDL1.0（出典・加工の明示・国が作ったように見せない）、弁護士法72条（報酬を得る目的での個別鑑定）を原文で確認し、設計の制約に落とした／ユーザーストーリー8本とUX5階層。ここで実装が8件変わった（入力欄を作らない・ルビと色分けを主役にする・localStorageを使わない、など）／実装、ユニットとE2E、デモとプロモ動画、スクリーンショット採点。採点は画面しか見ない評価者に2周まわし、12点から16点（合格）へ上げた。1周目はタイポグラフィが0点で、真因は組版ではなく条文の表をデータとして壊していたことだった
自分でやった: 4案からの選択／実機での確認とX投稿
失敗と修正: 労働基準法39条2項にある「勤続年数→もらえる日数」の表を、APIの木から段落本文へ流し込んでいた。画面には「継続勤務年数労働日一年一労働日二年二労働日三年四労働日…」という読めない塊が出ていた。有給は10枚の札でいちばん押される札なので、最初のクリックで「原文がそのまま読める」という約束が崩れていた → TableStruct > Table > TableRow > TableColumn を行と列のまま取り出し、表として組み直した。表の中の漢数字にもルビが乗る（一年→1年、十労働日→10労働日）。本文に連結が残っていないことをユニットとE2Eの両方で固定した
e-Gov の原典リンクのアンカーを条番号から組み立てて `#Mp-At_39` にしていたが、実際のページにそのidは無い。リンク切れのまま公開するところだった → 3法令のページをブラウザで開いて実際のidを読み取ったら、章番号が入る形だった（労基法39条は `Mp-Ch_4-At_39`、民法627条は `Mp-Pa_3-Ch_2-Se_8-At_627`）。条番号から組み立てるのをやめ、10件ぶんを topics.js に持たせて、アンカーの末尾が条番号と一致することをテストで固定した
ルビを本文から離すために rt へ transform: translateY を当てたが、まったく効いていなかった → CSSの transform は非置換のインライン要素には適用されない。position: relative と top で逃がして、隙間を実測0.5pxから2.0pxにした

Day 036公開中

一画ずつ

名前や言葉を入れると、その字が筆順どおりに一画ずつ書かれていく。入りで細く、送りで太く、終わりは画の種別に合わせて払い・止め・跳ねを書き分ける。速さは3段、これから書く画は薄い下書きで、書き始めには番号が出る。まだ何も書いていないときは「たとえば」の3語が出て、押すとそのまま書ける。書き終わったものは動画とPNGで保存できる。筆順データは同梱していて、入れた言葉は端末の外に出ない

kanji
stroke-order
kanjivg

所要時間1時間55分

アプリを開く

制作メモ

AIに任せた: 着手前の実測。候補にした4案のデータを先に叩いた。Google Fontsは日本語でもtextサブセットが効くこと（4字で1.7KB）、地理院の標高APIにCORSヘッダが無いこと、kanjiapi.devの学年別リストが1006字で現行の配当表より20字古いこと、KanjiVGが取得できてCC BY-SA 3.0であることを確かめた／要件定義（ユーザーストーリー8本＋UX5階層を通して実装が10件決まった）、実装、ユニットとE2E／筆順データの加工。KanjiVGの配布XMLから画の種別とパスだけを取り出し、座標を小数1桁へ丸めて94ファイルに分けた。相対座標なので丸めの端数を次の座標へ繰り越し、元のパスと曲線を突き合わせてずれを検査する仕組みを入れた／筆づかいの設計。画の種別（㇐㇑㇒㇏など）から終わり方を払い・止め・跳ね・捺に振り分け、道のりの位置ごとに太さを変えた輪郭を多角形として組む／デモの振り付け、プロモ動画、スクリーンショット採点。採点は画面しか見ない評価者に2周まわし、11点から17点（合格は16点）へ上げた。1周目の「番号に縁取りを付けろ」という指摘は、縁取りが元からあったのでそのままでは直せず、真因（画と番号を1画ずつ交互に描いていて、あとの画が前の番号を塗りつぶしていた）をコードで突き止めてから直した
自分でやった: 4案からの選択／実機での確認とX投稿
失敗と修正: 座標を小数1桁に丸める処理を正規表現の置換で書いたら、パスが壊れた。-0.02 が 0 になったときに数値の区切りだった負号ごと消え、3.6 と 0 がくっついて 3.60 という別の数になった → 置換をやめてコマンドと数値に分けて読み直し、区切りを組み立て直す形にした。あわせて、丸めたパスと元のパスを曲線上の点で突き合わせて、ずれが0.25単位を超えたら生成を失敗させる検査を入れた（79,907画の実測で最大0.188）
書き終わった字の番号が、黒い画に重なって読めなかった。番号には紙の色の縁取りを前から付けてあったのに効いていなかった → 真因は縁の太さではなく描く順番で、1画ずつ「画を描く→その番号を描く」を繰り返していたため、あとの画が前の番号を塗りつぶしていた（秋の9画目が4・5・6を消していた）。1マスぶんの画を全部描いてから番号をまとめて描く2パスに変え、縁も2.4から3.2へ太くした
広い画面で1字だけ書くと、1マスが画面の丈を超える大きさに広がり、入れる欄と「書く」が画面の外へ落ちていた。何も書いていないときは空の枠だけが画面を埋めていた → マスの実寸に上限（300px）を置いて盤面を中央へ寄せ、まだ何も書いていないときは「たとえば」の3語を出して押すだけで書けるようにした
プロモ動画の録画設定をDay 035から複製すると、アニメーションが1コマも撮れないところだった。Day 035は reducedMotion: 'reduce' で録っていたが、このアプリは「動きを減らす」設定のとき完成形だけを出す → 録画のコンテキストを 'no-preference' にし、その理由を render-promo.mjs と tools/promo/README.md の先頭に書いた

Day 035公開中

きょうの一面

読んだ記事のリンクを貼ると、その見出し・リード文が縦書きの新聞の一面に組み上がる。題字の下は漢数字の日付、本文は禁則処理と縦中横つきの縦組み。3本まで足すと二番手・三番手として紙面が埋まる。できた紙面はPNGで保存して共有できる。取るのはOGPだけで、記事の本文は取らない。写真は各媒体のものなので取得も保存もせず、画面に表示するだけで、保存するPNGには入れない

newspaper
ogp
canvas

所要時間3時間45分

アプリを開く

制作メモ

AIに任せた: 着手前の実測。NHK・朝日・ITmedia・note・Zenn の5サイトでOGPが取れること、og:image のCORSは4件中2件しか無いこと（＝写真も中継しないとPNG書き出しが落ちる）を確かめた。候補に挙げた鉄道遅延のAPIはホストがNXDOMAINで消えており、日本語版Wikipediaの『今日は何の日』は中身が0件だったので落とした／要件定義（ユーザーストーリー7本＋UX5階層を通して実装が10件決まった）、実装、ユニット97件とE2E 13件／縦書きの組版。約物の回転・句読点の位置・縦中横・禁則処理の追い出しを純関数に切り出した／写真の網点化（45度の格子・暗いほど大きな点）と、中継のSSRF対策（数値ホストの拒否・リダイレクトの毎回検証）／デモの振り付け、プロモ動画、スクリーンショット採点（別セッションのAIが10項目・20点満点）
自分でやった: 題材の提案（AIの4案を採らず『リンクを貼ると新聞になる』を出した）／紙面に載せる情報量の選択（見出し＋本文＋写真1枚）／実機での確認とX投稿
失敗と修正: 候補に挙げたAPIが2つとも使えなかった。鉄道遅延情報のjsonはホストがNXDOMAINで消えており、食品バーコードのOpen Food Factsは日本の商品を6件試して6件とも product not found だった → 提案の前に全部叩いて落とした。残った案のうち、本人が『リンクを貼ると新聞になる』という別の像を出したので題材ごと組み直した
記事1本の紙面が、列組みだけでは左半分が白いまま残った。リードは2文（最大120字）しかないので、広い紙面に対して文字が足りない → 1本のときだけレイアウトを分けた。上の帯に見出しと本文、下の帯に写真を全幅で置く。あわせて見出しと本文の大きさを字数から決めるようにした（固定サイズだと短い日に白く残り、長い日にあふれる）
倒したラテン文字の送りを全角の0.55倍にしたら、明朝の m が隣の c と重なった → 送りを0.72倍に広げ、字の大きさも0.8倍に落とした。1桁の数字は縦中横で半分にすると本文の中で沈むので、正立に戻した
写真をブロックの右上に置いたら、本文が尽きたあとの左下が大きく空いた → 写真を左下に接地させ、本文は右から流れて最後に写真の上を通る形にした。縦書きは右から読むので、この順のほうが自然に埋まる
プロモ動画で、透明なエンド画面（inset: 0）がクリックを奪って #submit が押せず、描画が30秒で止まった → 差し込む要素に pointer-events: none を付けた
公開したあとで、記事が1本も無い状態でも「画像を保存」が押せることに気づいた。押すと白紙のPNGが落ちる。別セッションのAIにUIを採点させるまで見つけられなかった（13/20） → app.css の .actions{display:flex} が、ブラウザ既定の [hidden]{display:none} に勝っていた。状態の切り替え自体は正しく動いていたので、テストも通っていた。[hidden]{display:none!important} で押さえ、E2Eに「空のときは保存ボタンが出ない」を足した。ready で見えることしか確かめていなかったのが抜けの原因
本番で note.com を貼ったら、見出しが「―つくる、つながる、とどける。」と区切り記号で始まった → og:title「note ――つくる、つながる、とどける。」から媒体名を落としたあと、ダッシュをそのまま残していた。落とした端の区切り記号を掃除するようにした

Day 034公開中

潮、いまどっち？

いまの潮は満ちているのか、引いているのか。地点を決めると、気象庁の潮位表から「いま、満ち潮」「次の満潮は 16:57（201cm）・あと1時間57分」と答える。きょうの潮位カーブに「いま」の印、潮名（大潮・小潮など）、干満差、きょうとあすの満潮・干潮の表も出す。現在地からは同梱した239地点の中で最寄りの潮位表地点を端末の中で選ぶ

tide
jma
sea

所要時間3時間50分

アプリを開く

制作メモ

AIに任せた: 着手前の実測。気象庁の潮位表テキストをブラウザから直接読めること（CORS）、10分キャッシュ、1行136桁固定の書式、全239地点に2025〜2027年のファイルがあることを確かめた。候補に挙げた飛行機のAPI（OpenSky・adsb.lol）はCORS不可だったので落とした／地点データの作成。気象庁の「潮位表掲載地点一覧表」239地点を解析し、都道府県が無いので市区町村の代表点から最寄りの県を付けた／要件定義（ユーザーストーリー7本＋UX5階層を通して実装が10件決まった）、実装、ユニット59件とE2E 26件、デモの振り付け、プロモ動画ツール／潮名の方式の調査。旧暦方式と黄経差方式があり、Day 026の天文計算を流用して黄経差方式（気象庁方式の区分）で機械的に付けた／スクリーンショット採点（別セッションのAIが10項目・20点満点で採点）を3周まわした
自分でやった: 題材の選定（4案から潮を選んだ）／会社のCodexが止まったあと「Codexも使って」と個人アカウントへの切り替えを指示／実機での確認とX投稿
失敗と修正: 会社アカウントのCodexが修正1周目の直前にクレジット切れになり、続きを任せたOpusもセッション上限で途中停止した → 同じ自己完結の指示書を渡し直して完走させた。Opusの停止時点で編集は終わっていたので、E2Eは本体側で回した。以後は本人の指示で個人アカウントのCodexを使う
採点1回目は12/20。答えのカードに地点名が無く「いま、満ち潮」がどこの潮か分からなかった。副文の「201cm」だけが孤立して折り返し、エラー画面は「地点を選んで」と書きながら一番上のボタンが再読み込みだった → カードの上段に「東京 · 15:00 現在」を置き、副文を「次の満潮は 16:57（201cm）」と「あと1時間57分」のチップに分けた。エラーは地点名入りの見出しにし、「地点を変える」を主ボタンにした
採点2回目は14/20。「あと1時間57分」と「大潮」が同じ白い枠で同格に見え、干潮の時刻ラベルが曲線に重なり、ボタンの強さが4段階あった → 残り時間を濃紺の塗り、潮名を枠なしのタグにした。干潮のラベルは点の下に固定し、ボタンを塗り／枠／リンクの3段階、角丸をカード12pxとボタン丸型の2値に固定した
潮名の境目。デモに使う予定だった2026-09-10 14:00は黄経差347.97°で「中潮」、1時間後の15:00は348.51°で「大潮」だった → デモとE2Eの固定時刻を15:00にした。同じ日の干満差171cmは東京の1年では大きい方で、実データとも合う
テスト用ブラウザでは文節単位の折り返し（word-break: auto-phrase）が効くが、語の途中で切る overflow-wrap: anywhere が残っていて「潮位表基準面から」が途中で折れた → anywhere は見出しだけに残し、本文と注記は auto-phrase にした

Day 033公開中

揺れた？

いまの揺れは地震だったのか。ボタンを押すと気象庁の発表を確かめ、「揺れました。7分前、あなたの街は震度4」か「15分以内の発表はありません」と1行で答える。場所を選ばなくても全国の答えが出て、市区町村を選ぶとその街の震度に切り替わる。きょう日本で震度1以上の地震が何回あったかと、過去24時間の帯も一緒に見られる

earthquake
jma
seismic-intensity

所要時間1時間40分

アプリを開く

制作メモ

AIに任せた: 着手前の規約チェック。気象庁ホームページの利用規約（公共データ利用規約第1.0版＝出典の記載と、編集・加工したことの明示が条件）と、担当者の「仕様の継続を約束しないという意味でAPIではないが、政府標準利用規約に準拠して利用できる」という公開説明を原文で確認した／地震情報一覧JSONの実測。ブラウザから直接読めること（CORS）、60秒キャッシュ、一覧だけで市区町村別の震度が入っていること、政令市の区コード117種が同梱データに無いことを確かめ、20市へ寄せる規則にした／要件定義（ユーザーストーリー＋UX5階層を通して実装が9件決まった）、実装、ユニット42件とE2E 24件、デモの振り付け、プロモ動画ツール／スクリーンショット採点（別セッションのAIが10項目・20点満点で採点）を3周まわして12→14→16点で合格。答えを画面で最大の文字にし、場所が未設定のときは主ボタンを「市区町村から選ぶ」に入れ替え、帯は色の棒と数字を分け、答えのカードは高さをそろえた
自分でやった: 題材の選定（4案から地震を選んだ）／実機での確認とX投稿
失敗と修正: 候補出しで「スマホの時計は何秒ずれてる？」案を検討したが、NICTのネット時刻配信サービスが終了していて成立しなかった → 候補のAPIは提案する前に実際に叩いて、応答とブラウザから読めるか（CORS）を確かめる手順にした
採点1回目は12/20。答えの「揺れました」（25px）より「きょう◯回」の数字（39px）が大きく、主役が3番目になっていた → 答えを30〜40pxの最大の文字にし、回数は28pxへ落とした。バッジ「あなたの街は震度◯」は20pxにした
場所が未設定でも主ボタンが「いま揺れた？」で、押しても自分の街の震度は出なかった → 未設定のあいだは「市区町村から選ぶ」を主ボタンに入れ替え、見出しの下に「あなたの街は未設定。場所を選ぶと震度が出ます」を出す
24コマの帯で「5弱」が12px幅のコマの中で潰れ、凡例の「6弱」は文字の対比が4.13:1しかなかった。白文字に変えると3.8:1でさらに悪くなる計算だった → コマを「色の棒＋数字」の2段にし、凡例は色の四角と文字を分けて、文字は白地に置いた
押し直すたびに画面が「読み込み中」に切り替わり、出ていた答えが消えていた → 読み込み中の画面は初回だけにし、押し直しはボタンの文字を「確かめています…」に変えるだけにした
ダイアログの select に焦点があるとき Escape がダイアログまで届かず、E2Eが不安定に落ちた → ダイアログ側で keydown を拾って閉じるようにし、テストはボタンに焦点を置いてから Escape を押す形にした

Day 032公開中

いま干していい？

洗濯物をいま外に干したら、どれくらいの勢いで乾くかを出す。気温・湿度・風・日射を1つにまとめた「大気の乾かす力」で、洗濯物が持っている水の量を割って時間にする。将来の天気は予想せず、いまの値だけを使うので、出すのは「◯時に乾く」ではなく「この勢いなら約何時間ぶん」

weather
laundry
open-meteo

所要時間1時間45分

アプリを開く

制作メモ

AIに任せた: 着手前の規約チェック。Open-Meteo の利用条件（無料は非商用のみ・広告や課金のないアプリは該当・1日1万回まで）とデータのライセンス（CC BY 4.0・表示は『Weather data by Open-Meteo.com』）を原文で確認した／乾きの計算を組んだ。ET0（FAO-56 基準蒸発散量）で洗濯物の水の量を割る式にし、係数は『真夏の薄手は1時間ちょっと』『冬は晴れても厚手は1日では乾かない』などの体感3つに合わせて決めた。実測ではないことを画面とREADMEに明記した／地名から座標を引く外部サービスを使わずに済むよう、Day 015 の代表点から1,741市区町村の一覧を作って同梱した（解禁されているAPIは1個なので天気に使い切る）／時刻を『日本時間の壁掛け時計の文字列』で持つようにした。Date に入れて比べると動かす環境のタイムゾーンで結果が変わる（CIはUTC）／ユニットテストとE2Eを書いた
自分でやった: 題材の選定（4案から「洗濯物の乾き予測」を選んだ）／実機での確認とX投稿
失敗と修正: 場所を選んだあと画面が切り替わらず、E2Eが17件中15件落ちた。取得したあとに描画は呼んでいたが、状態を ready にする呼び出しが抜けていた → 取得の直後に setState('ready') を入れた。状態と描画を別々に呼ぶ形は抜けやすいので、読み込みの成功経路を1か所にまとめた
24時間の帯から雨の時間が消えていた。雨のコマも「乾く速さ」に比例した高さで塗っていたが、雨の日の乾く速さは0なので高さも0になっていた → 雨はコマ全体を塗るようにした。速さは「乾いていく」ことの量であって、雨は状態なので、同じ尺度で描いてはいけなかった
「厚手」「日かげ・軒下」のボタンで、説明の文字が単語の途中で折り返して読めなかった（ジーンズ・パーカ／ー） → 説明をボタンの外へ出し、選ばれているものだけ1行で下に書くようにした。ボタン自体は折り返さない
本番の実機で「いちばん早く乾くのは明日の10:00に干したとき」と「明日9時に干すなら7時間14分で乾きます」が並んで出て、ほぼ同じことを2回言っていた → 前者が明日を指しているときは後者を出さないようにした。E2Eを1件足した
秘密情報スキャンが誤検知しやすい書き方が入っていた（KEY = '文字列'・const key = …）。Day 025・026・031 で実際に落ちている → コミット前に STORAGE_NAME・cacheId へ改名した。この形は毎回踏むので、書いた直後に自分で探すことにした

Day 031公開中

この形、どこ？

都道府県や市区町村のシルエットを見て、4つの地名から正しいものを選ぶ10問クイズ。形は行政区域データを単純化して同梱してあるので通信なしで遊べて、正解した瞬間だけWikipediaの要約1行と写真が付く。縮尺も周りの県も出さないので、頼れるのは形だけ

quiz
game
japan

所要時間5時間50分

アプリを開く

制作メモ

AIに任せた: 着手前の規約チェック。国土数値情報（行政区域データ）の使用許諾（CC BY 4.0）と、原典が国土地理院の測量成果であることから、国土地理院の利用手続（デザイン等は申請不要・出典記載）を原文で確認し、同梱データから緯度経度と縮尺を落として「地図として使えない絵柄」にする方針を決めた／47都道府県ぶんのGeoJSON（計380MB）を、mapshaperで融合・単純化したあと、投影・正規化・整数化して同梱JSON（2.9MB）へ変換する道具を作った。政令市の区は市に融合し、所属未定地と北方領土は外し、1,741市区町村で検算した。同じ入力から同じ出力になることも確かめた／離島の扱いを2段階の規則にした（近い島は面積1%以上、少し離れた島は面積10%以上のときだけ残す）。都道府県の輪郭は伊豆大島が残ると本土が潰れるため距離のしきい値を別にした。旧町境に沿ったスリバー状の穴は等周比で判定して落とした／出題の設計。誤答候補は同じ県（または同じ地方）から出し、1問目は形に特徴のある県・県内で大きい町から出す。全国モードは10県を重複なく引く。ヒントは市区町村では県内の位置、都道府県では2択に絞る形にし、どちらも配点を半分にした／Day 31から解禁の外部API1個として Wikipedia REST API（page/summary）を使った。同名の町は「美郷町 (秋田県)」のように県名付きで引き直し、Api-User-Agent を付け、4秒で諦め、失敗しても枠の高さを変えずに1行で知らせる。写真の配信元が thumb.wikimedia.org であることを実測してCSPに反映した／ユニットテストとE2Eを書いた（出題の重複なし・4択の整合・得点・保存・記事名の候補・正規化の範囲・島の規則・「次へ」が動かないこと・4状態・遅延応答の破棄・44px・3画面幅）／体験評価（別セッションのOpusが実プレイ・PC 16/20・SP 16/20）とコードレビュー（読み取り専用）の指摘を、コードで裏を取ってから反映した。要約の到着で「次へ」が動く問題は枠の高さを先に確保して解いた／UI採点ループ（別セッションのOpusがスクショだけで採点）を回し、出題中に何も動かない配置、結果一覧の色の使い方、最初の画面の主役づくりを直した／縦型プロモ動画（36秒・1080×1920・BGM付き）の道具を tools/promo/ に用意した。出題は種で固定し、Wikipedia は固定応答にして CC BY-SA の写真を動画に焼き込まない
自分でやった: 題材の選定（2026-09-05に4案から「この形、どこ？」を選び、Day 030がカメラ地図になったのでDay 031へ）／Lv.2の初日に外部APIを1個入れる方針の承認／実機での確認とX投稿
失敗と修正: 要件定義で想定した行政区域データの属性が実データと違った。政令市名は郡の列に入っておらず、所属未定地はコードが null ではなく末尾000、政令市のコードを「先頭3桁+00」にすると川崎市など5市が同じ県の1市目と衝突して消えた → 実データで属性を確かめてから規則を作り直した。政令市は区コードの最小値から市コードを求め、除外は末尾000で判定し、総数が1,741（792市・743町・183村・23区）になることで検算した
東京都の輪郭に伊豆大島が残り、本土が枠の高さの17%まで潰れて都道府県クイズとして読めなかった → 都道府県の輪郭だけ離島の距離しきい値を対角線の1.0倍にした。佐渡・隠岐・淡路島・種子島・屋久島は残る
多度津町や佐世保市のように小さな離島を持つ町で、本体が枠の隅に寄って小島だけが目立った → 対角線の1.0〜1.5倍にある部分は面積が最大部分の10%以上のときだけ残す規則にした。上島町や日高町のように離れた部分こそが形になる町は変わらない
廿日市市や木津川市の中に白い筋が出た。融合で残った旧町境のスリバー状の穴だった。佐世保市の白線も同じだと思ったが、こちらは実在する狭い海峡（早岐瀬戸）で穴ではなかった → 穴リングの等周比と面積で判定してスリバーだけ落とした（9個・5町）。佐世保市は地理として正しいので残した
Wikipedia の要約が届いた瞬間に「次へ」が109〜153px下へ動き、押した場所が解説本文になって空タップになった（体験評価で発見） → 解説の枠を最初から表示して高さを先に確保し、読み込み中・本文・取れなかったときの3状態を同じ高さで出すようにした。E2Eで「次へ」のy座標が届く前後で同じことを固定した
全国モードの画面には「毎問ちがう県から」と書いてあるのに、要件定義では県の重複を許していて、茨城県が3問続いた → 10県を重複なく引くように直し、画面の文言に合わせた
写真の無い記事では、解説の枠が2列のままで「Wikipedia で読む」と帰属表示が右端からはみ出した（プロモ動画の担当が発見） → 写真があるときだけ2列にし、リンクと帰属は本文の下に全幅で並べた
Codexの会社アカウントが朝から上限切れで、さらに13時までOpusも上限に当たり、体験評価とプロモ動画の担当が途中で止まった → 上限が明けてから同じエージェントを再開して続きから進めた。PCの採点まで済んでいたのでSPの採点から再開できた

Day 030公開中

せかいのまど

世界中の公開ライブカメラを1枚の地図に。地点をタップすると、その場所の映像や最新の静止画と、国・運営者・向き・現地時刻の推定・昼夜が出る。位置とURLはOpenStreetMapの登録から、映像は各提供元から直接読む

map
webcam
openstreetmap

所要時間8時間10分

アプリを開く

制作メモ

AIに任せた: 規約の一次情報を先に確認し、使い方を決めたこと。OpenStreetMap（ODbL・帰属表示）、YouTube の Developer Policies と Required Minimum Functionality（プレーヤーを遮らない・200×200以上・自動再生は操作後だけ・同時に1つ）、Windy Webcams API の無料枠（帰属表示・画像URLは10分で失効し保存不可・広告を遮らない）、OpenFreeMap（帰属表示）を読み、実装の制約表に落とした／OpenStreetMap の contact:webcam 9,631件を Overpass から1回だけ取得し、全URLの種別をビルド時に実測したこと（HEAD→GET、YouTube は oEmbed、ホストごとに直列・300ms間隔・24並列で約45分）。到達できない464件と、クエリに鍵らしき値を含むURL等16件を除き、映像141・画像2,665・HLS 84・リンク6,261の9,151地点を同梱した。実行時に Overpass は叩かない（2026-09-13に提供元の利用条件を調べ、埋め込みを許していない4ホスト579件をリンクのみへ落とした。地点数9,151は変わらず、内訳は画像2,086・リンク6,840になった）／国名を Natural Earth 1:50m の点内多角形判定でビルド時に付けたこと（沿岸の点は0.5度の範囲で最近傍の国へ）。日本語国名と大陸も同梱／地図（MapLibre・クラスタ）、種別チップ、検索、「どこかの窓を開く」、詳細パネル（国・運営者・向き・区分・現地時刻の推定・昼夜・座標・Googleマップ・OSM・提供元）、ビューア4種（YouTube 埋め込み・静止画60秒更新・HLS・リンク）、深いリンク、Windy 層（鍵があるときだけ）を実装した／Windy Webcams API v3 の中継（Cloudflare Pages Functions）を実装した。鍵は環境変数、bbox を格子に丸めてエッジキャッシュ、画像URLは保存しない、429は叩き直さない。ユニットテストで上流を差し替えて検証／ユニット38件（URL種別・YouTube ID・方位・太陽高度と昼夜・現地時刻・国判定・同梱形式・検索・乱択・中継）と E2E（地図とパネル・ビューア4種・チップ・検索・深いリンク・フォーカス・Windy・通信先・3幅・44px・reduced motion）を作成した／体験評価（別セッションのOpusが実操作・PC 12/18・スマホ 10/20）の指摘を反映した。スマホの展開シートが閉じられない、初見の一覧がリンクのみ、クラスタが1段しか寄らない、YouTube プレーヤーが右25%欠ける、HLS が無言で止まる、深いリンクで無操作の自動再生（規約違反）を直した／UI採点ループを3周回した（採点は別セッションのOpusがスクショだけで採点、実装はOpus。12→13→16/20で合格）。チップの押下状態、選択中カメラをパネルの外へ寄せる、固定ヘッダー、件数の整理、ピンのアイコン化、検索候補の一致理由、ライトテーマの調整を直した／縦型プロモ動画（36秒・1080×1920・BGM付き）の道具を Day 028 方式で用意した。場面の切替はアプリを本当に読み直し、地図とカメラ画像の読み込みを待ってから撮る。hash だけの遷移では load が来ず永久に待つ／前回の地図位置が残って世界図の準備待ちが失敗する、の2点を直した
自分でやった: 「世界中のライブカメラが見れるマップ」の発案と、規約を確認しながら進める方針の指定／実機での確認とX投稿
失敗と修正: E2E が全件落ちた。差し替え用の空スタイルで glyphs を空文字にしていたため、MapLibre 5 が「{fontstack}を含むURLでない」と検証で落とし、スタイルが永久に読み込み中になっていた（クラスタの件数ラベルが文字を使う） → glyphs を {fontstack}/{range} 付きのURLにし、フォントの要求は空のPBFで返すようにした
クラスタの件数ラベルが、指定していないフォント（Open Sans）を地図配信元へ要求して404の警告を13件出していた → 両スタイルに共通する Noto Sans Regular を text-font に指定した
公開前チェックの個人NGワードに、米国の通り名を含むカメラURLが一致した → IDで個別に外す exclude-ids.txt を生成ツールに足し、その1件だけ除外した
Windy 未設定の判定に hidden 属性を使っていたが、チップの display がそれに勝って表示されていた → [hidden] { display:none !important } を置いた
Chromium は HLS の canPlayType に 'maybe' を返すため <video> が作られ、error イベントも来ず黒い箱のままだった → loadedmetadata を5秒待って来なければ案内文に切り替えるようにした
公開の CI（gitleaks）が、同梱データの中の `?token=` 付き配信URL（提供元が公開しているもの）を秘密情報と判定して落ちた → 生成ツールでクエリに token・key・secret 等を含むURLを除外し（13件）、コミットを作り直した

Day 029公開中

ちかくのWi-Fi

現在地か地名を中心に、同梱した自治体公式・OpenStreetMap登録・チェーン推定の3層から近いWi-Fi候補を距離順で表示。無料区分や推定条件、出典を文字で示し、Googleマップで開ける。検索は端末内で完結し、地名検索時だけ中継へ通信する。

wifi
map
geolocation

所要時間12時間30分

アプリを開く

制作メモ

AIに任せた: 自治体公式・OSM登録・チェーン推定の3層を別データのまま読み、端末内で半径抽出・距離順表示・層別集計を行う構成へ変更した／実行時のOverpass中継を廃止し、生成ツールで座標と項目を削減したOSMデータを同梱する方式に変更した／各社公式サイトで確認した提供範囲・条件・確認日を推定表示へ反映し、店舗ごとの利用可否を断定しない文言にした／OSM、OpenFreeMap、Nominatim、自治体11件のライセンスとクレジット要件を画面・README・第三者通知へ反映した／体験評価（別セッションが実操作で採点・12/20）の指摘を反映した。失敗と読み込みの文言を押した場所の近くに出す、地名検索で掴んだ場所の名前と候補を表示する、0件の理由を層・絞り込み・半径で出し分ける、100件と地図ピン60か所の上限を明示する、方角を距離に添える、失敗時に直前の結果を残す／Nominatimが「仙台駅」を岡山県の店に解くことを実測し、中継で「◯◯駅」を「◯◯ 駅」に変えて問い合わせ、国内に絞る対応を入れた／3層フィルター、地名候補、0件理由、上限表示、方角のユニットテスト68件と決定的なE2E 24件を作成した／縦型プロモ動画（36秒・BGM付き）の生成ツールをDay 028方式で流用し、地図タイルの読み込み待ちとピンの出現演出を加えた
自分でやった: 題材の発案と、試作後の公開判断（Day 29として出す決定と、Nominatim利用方針を読んで採用した記録・2026-09-05）／実機での確認
失敗と修正: 最初の実装では、リスト用に100件へ切った配列をそのまま地図にも渡しており、「リストは最大100件、地図はすべて描く」という要件を満たしていなかった → 絞り込み後の全件とリスト表示用の先頭100件を分け、要約と地図には全件、リストにだけ上限を適用した
秋田市の施設名と住所に「西武秋田店セイブアキタテン」のように読みが連結していた。配布XLSXをCSVへ変換したときにふりがな（ルビ）の文字列が値に混ざり、ヘッダも「設置者セッチシャ」になっていた → openpyxlの値のみ読みで再変換し、列名を素の名前に直して同梱データを再生成した。変わった行は秋田市の13件だけで、他の出典と総数5,855点は変わらない
地名検索で「仙台駅」を入れると、Nominatimが岡山県倉敷市の飲食店を返し、アプリは掴んだ場所の名前を表示せずに「前回: 仙台駅」とだけ出していた → 中継で末尾の「駅」の前に空白を挟んで問い合わせ、国内に絞る。アプリ側は掴んだ場所の名前を常に表示し、候補が複数なら選べるようにした
説明文が「現在地は約110mに丸めて中継サーバーへ送る」となっていたが、コードでは現在地はどこにも送っていなかった → 実装どおり「現在地はどこにも送らない。端末に残すのは丸めた前回地点と絞り込みだけ。地名検索で送るのは入力した地名だけ」に直した
公開前チェックの個人NGワードが、沖縄県西原町・浦添市西原・熊本市東区西原・広島市安佐南区西原の施設名と住所（自治体オープンデータの地名）47か所に反応して公開を止めた → 人名の文脈は検出したまま、直前が市・区・郡・町・村、直後が町・村・店・シティ・数字・丁目などの地名の文脈だけ通すパターンに書き換え、ローカルとCIの両方を同じ内容にした

Day 028公開中

ひとしずくの木

開くと鉢植えの木がいて、「水をあげる」を1日1回押すとその日のぶんだけ育つ。木の形は端末ごとの種から決まり、忘れた日はしおれるが枯れない。成長を再生し、1080×1080のPNGで保存できる。残すのは種の番号と水をあげた日付だけで、通信はしない

plant
canvas
procedural

アプリを開く

制作メモ

AIに任せた: 現地日付の判定、日数差、1日1回の水やり可否、しおれ具合、日数帯と節目（7・14・30・50・100日）ごとの文言を求める純関数を実装した／種とステップごとの乱数から決定的に枝・葉・花を増やす木の生成処理を実装した。同じ種と回数なら同じ木になり、前日までの形は変わらない（prefix性）／木の見た目を、年齢別ギャラリー画像を見ながら作り直した（幹・横枝・小枝の3種に分け、樹冠を楕円に収め、花は4日に1つ上限30、幹は子孫の数で太くする）／鉢・枝葉・花・しおれ・しずく・波紋をCanvas 2Dで描く処理と、水をあげた瞬間の1.4秒の演出、成長の再生とスキップ、木の高さに合わせて上へ伸びる表示枠を実装した／種の番号と水をあげた日付だけを検証してlocalStorageへ保存する処理と、日付・URL入りの1080×1080 PNG書き出しを実装した／ユニット28件（日付・判定・木の決定性とprefix性・座標範囲・保存）とE2E約30件（1日1回・翌日・再読込・しおれ・時計逆行・壊れたデータ・保存不可・やり直し・再生・PNG寸法・reduced motion・3幅・44px・通信ゼロ）を作成した／体験評価（別セッションのOpusが実際に操作して採点・12/20）の指摘から、毎日同じ文をやめる・空の表示枠を切り詰める・再生中の表示とスキップ・保存画像の日付とURL・不在時の文言を直した／UI採点ループを3周回した（実装はCodex、採点は別セッションのOpusがスクショだけで採点）。1周目16/20→2周目17/20→3周目18/20。済み状態のボタンのコントラスト（2.35:1→6.24:1）、無効ラベル、デスクトップの空白、折返し、ボタン寸法、伝言の位置を直した／縦型プロモ動画（36秒・1080×1920・BGM付き）を作る道具を tools/promo/ に用意した。日付を固定し、木の描画をアプリ本体の純関数で合成側に上書きすることで、途中の秒から描いても同じ画になる
自分でやった: 題材の選定（4案から「毎日開くと育つ植物」を選んだ）／実機での確認とX投稿
失敗と修正: 画像保存用Canvasに背景を塗った後、共通の木描画が先頭で描画領域を消去し、PNGの木の周囲が透明になっていた → 木描画に消去の有無を渡せるようにし、画面では消去、保存画像では生成り色の背景を残して描くようにした
樹形の検算で、上端まで達した先端から伸ばす枝が範囲内への縮小で長さ0になる種が見つかった → 上端付近では左右の空いている方向へ水平に伸ばし、範囲と決定性を保ったまま必ず見える長さを持たせた
最初の木は細い棒に小さな粒が付いた見た目で、60日を超えると花だらけになった。要件の数値どおりでも絵として貧弱だった → 年齢別のギャラリー画像を見ながら、幹・横枝・小枝の規則と葉の大きさ、花の頻度と上限を作り直した。決定性・prefix性・座標範囲のテストは変えずに通した
種の段階では正方形の表示枠の85%が空白で、読み込み中に見えた。小さい画面では「水をあげる」が初画面に入らなかった → 枠の高さを木の高さから決めて、育つほど上へ伸びる作りにした（種は幅の4割程度、大きい木で正方形）
共有ボタンの枠のコントラスト検査で、地色を黒として測られて落ちた。bodyの背景がグラデーションだけで、単色の層が無かった → 背景の最後の層に生成り色を足した（検査はグラデーションの色停止点を拾うため、transparentが黒として扱われていた）
済み状態のボタンの色を検証するE2Eが、読み込み直後の180msのtransitionの途中の色を拾って落ちた → 自動で待つ toHaveCSS に変えた

Day 027公開中

スクショに額縁を

スクショを貼るか落とすか選ぶと、余白・角丸・影・背景を付けた1枚をその場で作り、PNGで保存かクリップボードへコピーできる。背景10種と比率6種、ウィンドウ風の枠。画像はブラウザの中だけで処理して外に送らず、ページを閉じれば消える。保存するのは設定だけ

screenshot
image
canvas

アプリを開く

制作メモ

AIに任せた: 出力寸法・余白・角丸・影・固定比率・4096px上限を計算する純関数を実装した／背景10種とウィンドウ風の枠、影、透明背景をCanvasへ描く処理を実装した／ファイル選択・貼り付け・ドロップ・Clipboard API・サンプルの5経路を同じ読込処理へ接続した／背景・比率・余白・角丸・影・枠だけを検証して端末内へ保存する処理を実装した（画像は保存しない）／レスポンシブ画面、着地演出、reduced motion、PNG保存と画像コピーを実装した／レイアウト・背景・保存・ファイル名のユニット16件と、貼り付け・ドロップ・保存PNGの寸法・4096縮小・再読込・44px・通信ゼロを見るE2E 20件を作成した／UI採点ループを3周回した（実装はCodex、採点は別セッションのOpusがスクショだけで採点）。1周目16/20で、見出しと説明文を左寄せの1ブロックに、空状態のヒント文の1文字だけの折返しをなくし、比率チップを3列×2行に、HOW TOを左カラムの下へ、メッセージ欄を重ねる表示に直して2周目16/20。実在した4点（文中の半角スペース・320pxの見出し行・320pxのプレビュー枠の余り・設定カードの追従）を直して3周目18/20で合格／縦型デモ動画（16秒）の振り付けと、録画の頭を切って1コマ目を画像が着地する途中にする道具を用意した／公開前レビュー（Opus）の指摘3件（roundRect非対応で読み込み中のまま止まる／スライダー操作後の⌘Vが無反応／toBlobがnullのとき無言）とフォーカス管理を直し、E2Eを4件足した（計24件）／縦型プロモ動画（36秒・1080×1920・BGM付き）を作る道具を tools/promo/ に用意した。Day 026 の方式を流用し、素のスクショに額縁が付くフック→貼り付け→背景10種→比率→ウィンドウ風の枠→保存の順で、アプリ本体をスマホ枠の iframe で実際に動かして撮る。BGMは明るい音列に差し替えてコード合成
自分でやった: 題材の選定（作る前に候補を出させ、4案から「スクショに額縁を」を選んだ）／実機での確認とX投稿
失敗と修正: コードレビューで、画像を表示中に画像でないファイルを落とすと、エラー画面に切り替わって前の画像まで消える作りになっていた → 画像が既にあるときは表示を保ち、理由だけをメッセージに出すようにした。E2Eに1件追加
コピーがBlobをawaitしてからClipboardItemに渡す書き方で、Safariではユーザー操作の有効期限が切れて失敗しやすかった → ClipboardItemにPromiseのまま渡す書き方にした
公開前レビューで、Canvasの roundRect が無いブラウザ（Safari 16.4未満など）では描画が例外になり、「読み込み中…」のまま無言で止まることが分かった → roundRect が無ければ arcTo で同じ角丸を描くようにし、描画の失敗は理由を出すエラー画面に落とすようにした。roundRect を消したE2Eを追加
スライダーを触った直後に ⌘V / Ctrl+V が無反応だった。貼り付けの横取り防止が input 要素を丸ごと除外していて、range にフォーカスが残ると画像を捨てていた → 除外をテキスト入力欄（range・checkbox・file 以外の input、textarea、contenteditable）だけに絞った。スライダーにフォーカスを置いたまま貼るE2Eを追加
1:1で長辺4096pxになるとiOS SafariのCanvas面積上限に当たり、toBlob が null を返して保存もコピーも無言で終わっていた → null のときは「この画像は書き出せませんでした。比率や余白を小さくしてください」を出すようにした。あわせて状態が切り替わるたびにフォーカスが body へ落ちていたのを、プレビュー・「画像を選ぶ」・「別の画像」へ移すようにした

Day 026公開中

今夜の月

今夜の月を輝面比からCanvasに描き、月齢と呼び名、自分の場所での月の出・月の入りと方位、日の入り、中秋の名月までの日数を表示する。前後30日の月をなぞれ、実際に見た月は端末内の帳へ最大60件残せる。位置は約1kmに丸め、計算も保存も外部通信なしで完結する

moon
astronomy
canvas

アプリを開く

制作メモ

AIに任せた: 国立天文台暦計算室から朔弦望12件・東京の出入り4件・中秋の名月の表（2024〜2032）を一次情報として取り、ユニットテストの正解に固定した／Jean Meeus『Astronomical Algorithms』第2版の太陽・月位置、位相、朔弦望と、2分走査・二分法による出入り計算を依存なしで実装した／UTC+9固定の暦、2024〜2032年の中秋の名月、旧暦日の呼び名、現在地を小数2桁に丸める端末内保存を実装した／輝面比からターミネーターを描くCanvas、固定シードの月面模様、1.4秒の月の出とreduced motion対応を実装した／天文値・保存を検証するユニット82件と、操作・3幅のレスポンシブ・位置情報・reduced motionを扱うE2E 19件を作成した／UI採点ループ2周（実装はCodex・採点は別セッションのOpusがスクショだけで採点）。14→17/20で合格。デスクトップはヒーローを2行ぶち抜きにした2列、月の暗部を空に沈めて星が透けないように、時刻カードに方位チップと翌日の「翌」バッジ、モバイルは月→時刻→名月→日付→帳の順にした／縦型プロモ動画（36秒・1080×1920・BGM付き）を作る道具を tools/promo/ に実装した。1コマを時刻の純関数として描くHTML合成ページをPlaywrightで連番撮影しffmpegで動画化、BGMもコードで合成。アプリ本体をスマホ枠のiframeで実際に動かして撮るので他のDayへ流用できる
自分でやった: 題材の選定（4案から「今夜の月」を選んだ）／実機での確認とX投稿
失敗と修正: 朔から次の朔までを29.53日±0.1日とした初期テストが、2026年8月から9月の実値29.4099日を不正に落とした → 朔望月には変動があるため計算値は変えず、テストを約29.5日±0.2日に直した
Meeusの本にある月の出没基準（上辺・0.7275π−34′）で計算すると、東京9/2の月の入りが国立天文台の暦より約2分遅く、月の出は1分早かった → JPL Horizonsの見かけの高度で照合し、暦の時刻が「月の中心が地平線に来る瞬間」と一致することを確認。基準を大気差35′8″・太陽は上辺・月は中心に改めて、4件とも暦と分単位で一致（秒差30秒以内）。ユニットテストの許容も3分から1分に締めた

Day 025公開中

ちかくの駐車場

現在地か地名から、近くの駐車場を地図と距離順のリストで同時に出す。並べる軸は有料・無料・料金不明の3値で、金額での比較はしない。OpenStreetMapに金額が書かれているのは実測で0〜0.5%しかないため

map
geolocation
openstreetmap

アプリを開く

制作メモ

AIに任せた: OpenStreetMapの駐車場タグの埋まり率を先に実測して設計を決めたこと。秋田駅の400m圏81件のうちfeeタグは12件（15%）でしかも全部yes、charge（金額）は0件、opening_hoursも0件（800m圏まで広げると225件）。東京駅はfeeが74%。この差から「金額での比較はやらない」「料金は3値だけ」「営業時間はあるときだけ出す」を設計原則にした／検索の待ち時間の原因を実測で切り分けたこと。半径400mで4.8秒、3200mで1.9秒と、広いほうが速いことがあった。所要時間は半径ではなくOverpassの順番待ちで決まっていたので、400→800→1600→3200と段階的に広げる作りは往復回数を増やすだけで何も買っていなかった。800→3200の2段に減らした／「2系統フェイルオーバー」が実は1台だったことをDNSで見つけたこと。overpass-api.deは162.55.144.139と65.109.112.52の2台に振り分けられ、lz4.overpass-api.deは後者だけを指す。素のホスト名を1系統目にすると同じマシンを2回叩きうる。z.（前者）とlz4.（後者）を名指しして別マシンにした。同じ日に両方が別々のタイミングで落ちるのを観測している／Overpassのスロット超過が429で返ること（406も同じ扱い）を、同じクエリ4本同時で再現して特定したこと。それまでは他の失敗と同じに扱って1.5秒後に叩き直しており、詰まっているサーバーに追い打ちをかけていた／公開するにあたって利用方針に反することを、一次情報を読んで止めたこと。Overpassは「アプリの利用は全利用者の合計で数える」「常設なら1日100クエリ・10MB未満」「アプリを識別できるUser-Agentを付ける」「キャッシュとレート制限をする」と定めていて、ブラウザから直接叩く形では満たせない。Nominatimも識別可能なUser-Agentとキャッシュを要求する。Cloudflare Functionsの中継（functions/api/day-025/）に寄せ、座標を約110m四方に丸めてエッジで7日キャッシュする形にした／MapLibreをCDNから読むのをやめて同梱したこと。このリポジトリのCSPはscript-src 'self'で、外部スクリプトを読むアプリが1つも無い。CDNを許可するとCSPを緩める初めてのDayになるため、BSD-3-Clauseのビルドをvendor/へ置いた／地図の描画とロジックを分けて、DOMに触らない純関数（クエリ組み立て・タグ正規化・距離計算・半径拡大・表示上限）だけをNodeからテストできるようにしたこと
自分でやった: 「近くの駐車場を出すアプリ」という題材の発案／検索が遅いという指摘と、速くする案のうち「タイムアウト短縮」「段階拡大の廃止」を採り、「2系統へ同時投げ」は不採用にする判断（ボランティア運営のサーバーへの負荷が2倍になるため）／公開にあたって、実行時にAPIを叩き続ける形ではなく中継API方式を選ぶ判断／デモ動画を音ありのプロモーション型にする指定
失敗と修正: 表示を近い順50件で打ち切るようにしたのに、見出しは「50件」のままだった。上限に当たった数字なのか実数なのか区別できず、このアプリが掲げている「分からないものは分からないと出す」に反していた → 切る前の該当件数を別に数え、上限に当たったときだけ「204件中50件」と出すようにした
Overpassの取得上限を200件にしていたが、Overpassの件数上限は距離順ではなく内部のID順で切る。秋田駅の800m圏は実測225件あり、200で切ると落ちた25件に最寄りが混ざりうる状態だった → 上限を500件に上げ、距離順に並べてから表示側で50件に切るようにした。中継側で画面が使うタグだけに削っているので、返る量はむしろ減った
Node（undici）からOverpassを叩く通し確認が、再現性なく406やAbortErrorで失敗した。同じクエリをcurlと実ブラウザに投げると200が2.7秒で返る。これを見て一度「タイムアウト8秒は短すぎたか」と判断しかけた → 実ブラウザ（Playwright）で通すようにした。あわせて、遅さを測る前にOverpassの/api/statusで空きスロットを確認する手順にした。自分のテスト実行で2枠を使い切ると、その後の計測が全部遅く見える
デモ動画の尺がOverpassの混み具合で2〜15秒動いた → 候補を選んだ直後から結果が出る直前まで（両側ともスケルトン表示でつなぎ目が見えない区間）を自動で切るようにした
合成しただけのデモ音声が-29.9 LUFSで、SNSのタイムラインでは実質無音だった → loudnorm で-16 LUFS / トゥルーピーク-1.5 dBTPに合わせた

Day 024公開中

読めない地名が、向かってくる

全国の地名が奥から迫ってくる。読みは伏せてあり、ローマ字で打ち切ると弾ける。近づくにつれて読みが1文字ずつ開くので待てば誰でも打てるが、開くほど点は減り、打ち間違えるほどその地名で入る点も下がる。問われているのは打鍵の速さではなく、読めるかどうか。難読度は外部の漢字辞典を使わず、全国12万件の地名だけから連立方程式で解いて決めている

game
typing
place-names

アプリを開く

制作メモ

AIに任せた: Day018のローマ字判定エンジン（lib/romaji.js・204行）をそのまま流用する判断。かな汎用で isSupported() による足切りまで入っていたので、書き直しは一切していない。新しく書いたのは難読度の計算・ヒントの段階開示・奥行きの描画・地方ブロック・ライフ制の進行／『読みを隠す』と決めた時点で、読めない人が1文字も打てずに終わる問題が確定することの指摘。Day018で実測した『遅い人ほど消える寸前の皿に縛られ続ける死のループ』と同じ構造なので、同じ性質の手当て（ヒントの段階開示＋降参）を実装前に入れた／得点を『開いた文字数が少ないほど高い』に置いた設計。速さで点を付けると、読みを隠した意味がなくなり Day018 と同じゲームになる／打ち間違いの減点を『総スコアから引く』ではなく『その地名の持ち点に0.85を掛ける（複利・下限は満点の2割）』に置いた設計。読みを伏せている以上プレイヤーは当てずっぽうで打つので、総額を削ると「読めないなら手を出すな」というゲームになって伏せた意味と引っ張り合う。持ち点だけを削れば、迷って連打するほど静かに損をするだけで済む。ミスの回数はプレイ中には出さない（出すと答えの手がかりになる）／開き切っても2割は点が入るようにした判断。0点にすると、開き切ったあとに打つ理由が消えて『見ているだけ』になる／打ち間違えたときに『押してほしかったキー』を返さない実装。Day018はミスの瞬間にそれを出していたが、読みを伏せている最中に出すと答えが漏れる。記録だけ残して結果画面で使う。テストで固定した／難読度を外部の漢字辞典なしで出す2段構えの設計。第1段は『かなの総数＝各漢字のかな数の和』という式を全国12万件ぶん立てて、漢字約2,250種の期待かな長を最小二乗（Jacobi反復）で解く。第2段はその期待長を使って漢字とかなを動的計画法で対応づけ、漢字ごとの読み出現頻度を数える。難読度は珍しさ（−log 出現確率）の平均＋かな長の意外さ／対応づけを2周まわして精度を上げたこと（1周目は長さだけ、2周目は1周目の頻度表を費用に足して切り直す）／ユニットテスト24本（開示の単調性、接近が速い回でも着弾前に開き切ること、得点の単調減少、ライフの減り方、正解を見せてから次に進むこと、降参した地名の再出題、在庫を使い切ったあとの巡回、答えを漏らさないこと）／出題の難易度を式ではなく実測で決めたこと。全件から等間隔に採ると1問目が「板山＝いたやま」級で退屈だったので、東北の在庫を順位ごとに並べて中身を目で確かめ、全国上位20%かつ「少なくとも1文字は珍しい当て方をしている」を条件にした／E2Eを7本追加したこと。とくに『打ち間違えても押してほしかったキーを画面に出さない』は、破れると遊びが成立しなくなるので固定した／画面幅320〜1280pxで地名のはみ出しを実測する検査を書き、字の大きさを「どの文字数でも枠幅の約8割」になる式に直したこと／音を『見えていないものだけ』に絞った設計。打鍵そのものには音を付けていない——プレイヤーの目は漢字と伏せ字に釘付けなので、見えているものに音を重ねても情報は増えない。鳴らすのは①読みが1文字開いた（開くほど音が下がる＝持ち点が減っている）②着弾が近い（心拍が速くなる）③打ち間違い④弾けた（上行・伏せたまま残せたぶんだけ高い）⑤失敗（下行）の5つだけ。Day018のlib/sound.jsと同じく、決める部分（純関数）と鳴らす部分（AudioContext）に割ってユニットテスト6本を当てた／デモ動画の音を『別の効果音を被せる』のではなく『アプリが実際に鳴らした音を控えて組み立て直す』方式にしたこと（?sound=log → tools/render-demo-audio.mjs）。位置合わせは動画の末尾から逆算するので、頭を切ったあとでも合う
自分でやった: 『難しい地名が近づいてきて、打てたらはじけて次に行く』というゲームの指定と、参照作（漢字でGO!）の提示／読めないときの逃げ道を『ヒント段階開示＋降参』にする選択／出題の舞台を地方ブロック（東北・関東など）で選べるようにする指定／郵便番号データのダウンロード実行（Claude側は許可が下りず実行できなかった）
失敗と修正: 郵便番号データのダウンロードURLが間違っていた。WebFetchが返した絶対URL（/zipcode/dl/utf/zip/utf_ken_all.zip）をそのまま使ったが、これは移転前のパスで404を返す。しかも落ちてきた72KBのHTMLを zip だと思い込んだまま本人に実行を頼み、本人の環境でも同じHTMLが落ちた → 配布ページのリンクが相対パス（utf/zip/utf_ken_all.zip）で書かれていることを確認し、基準ディレクトリと結合して正しい絶対URLを組み立てた。あわせて、外部から取ったファイルは file かサイズで中身を確かめてから次に進む手順にした。72KBという明らかに小さいサイズが最初から出ていたのに見ていなかった
難読度の上位に『御幸町（みゆき）』のような地名が混ざった。漢字3文字に対して読みが3かなしかなく、読まれない『町』にも1かなが割り当てられて、実在しない読みが珍しい読みとして数えられていた。実在の難読ではなく対応づけの失敗 → 『町』『村』『島』で終わるのに読みがそれを含まない地名を除外した。除外後の上位は上八（こうじょう）・石原（いさ）・東風平（こちんだ）・大豆谷（まめざく）・月出里（すだち）と、実在の難読地名だけが並ぶようになった
地方ごとの読めなさを『上位200件の平均』で比べていたが、これは母数が大きい地方ほど有利になる統計だった。中部（母数25,083）が1位、四国（4,070）と北海道（4,815）が下位という、母数の順とほぼ同じ並びが出ていた → 母数に対する割合（上位1%）と中央値で比べるようにした。並びは入れ替わり、九州・沖縄が1位、北海道が最下位になった。統計の取り方を変えると順位が変わることそのものを、画面に出す予定
実機で打鍵が1つも入らなかった。盤面のどこかを押すと入力欄へフォーカスを戻す作りにしていたが、押した既定の動作でフォーカスが盤面側へ移り、直後に入力欄から外れていた → pointerdown で preventDefault してから focus するようにした。あわせて、それでも外れたときのために、打ち始めた時点で入力欄へ戻す受け皿を document 側に置いた
4文字の地名（南外若林）が画面幅を超えた。字の大きさを固定にしていたため。文字数で割る式に変えたら今度は幅が文字数によらず一定になり、枠の半分（179px / 356px）しか使わず小さくなった → 上限3つの min() にした。①1〜2文字が大きくなりすぎない上限 ②横幅640pxで頭打ちになる枠に合わせた上限 ③それより狭い画面のための実測幅に合わせた上限。320〜1280pxのどの幅でも枠幅の約78%を占め、はみ出さないことを測って確認した
一覧用スクショが、地名が弾けている最中を写していた。burst の演出は字を2.1倍に拡大するので、枠で切れて何の画面か分からなくなっていた。振り付けの待ち条件が「読みに伏せ字でない文字がある」だけで、打ち切った直後の全開示にも当たっていた → 「向かってきている最中（incoming）」かつ「半分まで近づいた」かつ「読みが一部だけ開いている」の3つを待つようにした
npm run precheck が NG を1件出した。出題データに、非公開にしている語と偶然一致する実在の地名が含まれていた。全国12万件もあれば当たる → ビルド時に .precheck-ng.txt を読んで、都道府県・市区町村・町域名のどれかが当たる地名を除外するようにした（48件）。NGリストはgitignoreされているので、手元に無い環境では素通しになり、そのときは precheck 側が止める
meta.json に screenshot を書き忘れ、shared-share の『リンクを貼ったときに中身が出る（OGPとcanonical）』が落ちた。og:image はビルドが meta.json から入れるので、ファイルを置くだけでは足りない → screenshot: screenshot.webp を足した。ビルドの出力が『スクショ 18』のままだったのが手がかりだった
E2Eを1本ずつ流すと通るのに、全体（306件）で流したときだけ『読みを打ち切ると弾けて点が入る』が落ちた。テスト側が盤面の開始後に出題データ465KBを取りに行っており、混んでいるときはその間に地名が手前まで来てしまう。次の地名に変わったあとで古い読みを打っていたので、点が入らなかった → 出題データとローマ字変換を開始前に読み込んでおき、盤面が出てからは通信なしで引くだけにした。1本あたり5.2秒→0.2秒になり、3回繰り返しても落ちない。アプリ側の不具合ではなくテストの競合だった
テストの競合をもう1つ踏んだ。盤面が見えた時点で地名を読み取っていたが、地名が入るのは最初の描画（rAF）が回ったあと。混んでいると読み取りのほうが先に来て、出題データの引き当てが空になり、そこから先が全部おかしくなっていた → 盤面が出るのを待つだけでなく、地名が入るまで待つようにした。引き当てが空だったときはその場で落ちるようにもした（空のまま進むと、原因から遠いところで落ちて読み解けない）。5回繰り返しても通る
公開後、本人の実機で「打っても反応しないし、打つところもない」。原因は2つあった。①打鍵を受ける入力欄を1px・opacity:0 の隠し要素にしていたため、盤面を触っても入力欄に当たらず、スマホで仮想キーボードが出なかった。さらに盤面のpointerdownでpreventDefault()してからfocus()していたのが致命傷で、iOS/Androidは入力欄への直接の操作でしか仮想キーボードを開かないため、既定の動作を止めると二度と出ない。このpreventDefault()は制作中に踏んだデスクトップのフォーカス外れを直すために入れたもので、直した先で別の端末を壊していた。②日本語入力がONのとき、compositionend（確定した瞬間）でしか警告を出しておらず、確定せずに打ち続ける人には完全な無反応に見えた → Day018（同じタイピングゲーム）の作りをそのまま移植した。入力欄（#keys）を盤面と読みの全面に広げ、盤面を触れば入力欄に当たるようにした（親の .play-area を position:relative にして、#keys を inset:0 で敷く）。font-sizeは16px（iOSの自動ズーム防止）。preventDefault()は入力欄の外を触ったときだけに限定。タッチ端末には「ここをタップしてキーボードを出す」を1打も受け取れていないあいだ出す（focus()を呼んでも仮想キーボードを開かない端末があるので、フォーカスの有無だけでは消さない）。日本語入力はcompositionstartで即座に知らせる
この不具合をE2E 369件が1件も捕まえていなかった。Playwrightはキーイベントを直接注入するので、仮想キーボードが出ているかもフォーカスがどこにあるかも関係なく打ててしまう。テストは全部緑なのに、実機では遊べない状態で公開していた → 回帰テストを「打てたか」ではなく『実機でキーボードが出るための条件』に向けた。入力欄が盤面の全面を覆っているか・font-sizeが16px以上か・タップでフォーカスが入るか・変換開始で警告が出るか、の4本。壊すと落ちることをミューテーションで確認した
デモの音を最初に書き出したら −50 LUFS（ピーク0.034）で、Xでは何も聞こえない大きさだった。ブラウザ側のマスター音量（lib/sound.js の 0.22）まで再現に掛けていたのが原因。アプリはスピーカー側の音量で補われるが、動画にはそれが無い → マスター音量は掛けず、音符のgainをそのまま頂点として書き出し、全体を1つの係数でピーク0.7へ持ち上げるようにした。係数が1つなので音どうしの大小の関係は変わらない。−23.7 LUFS になり、既存の音付きDay（−19.5〜−22.2）と同じ帯に入った。day-012も同じくマスターを掛けていない

Day 023公開中

MAGTRACE

気になる言葉を題名に含む雑誌記事を、国立国会図書館サーチの雑誌記事索引から30年分集計し、年別推移・転機・原典リンクを表示します。最近調べた言葉は端末内だけに保存します。

magazine
ndl
trend

アプリを開く

制作メモ

AIに任せた: NDLサーチAPIの実測と方式決定。ブラウザから直接呼べない（CORS無し）のでPages Functionで中継。SRUのdcndlスキーマだけに発行年が入ること、SRUでは期間の絞り込みとmaximumRecords=0が使えないこと、0件がdiagnosticsで返ることを確かめ、500件以下はSRU 1本で全件取得・500件超はOpenSearchで年別件数30本（同時5本）に分けた／実装前にユーザーストーリー5本とUX5階層を書き、そこから11件の実装を決めた（発見の一文を最上部に／転機は機械的な規則で決めて断定しない／代表記事は3年×3件で選定基準を明記／記事タイトル一致に限定／検索語を持たない人向けの入口／0件と障害を同じ型で／?q=のURL共有／表表示／今年は集計途中扱い／24時間キャッシュ／Webフォント不使用）／実装はCodex（3周目はクレジット切れでOpusに切替）、UI採点は別セッションのOpus（スクショのみ・コードは見せない）。1周目10/20（390px幅のグラフ文字と見出しの折返しが0点）→2周目11/20→3周目15/20（0点なし。合格ライン16に1点届かず、上限3周で本人判断へ）／転機の規則を本物のデータで検証して直したこと。「前年比の倍率が最大の年」は小さい数字の揺れを拾い（サウナ: 2003年 1→6件を転機と判定。実際は2022年 9→36件）、「前年からの増加数が最大の年」に変えた／ユニット32件（XML解析・年別集計・分析文・クエリ正規化・グラフ座標と注記の位置・履歴）とE2E 16件（読込・0件・障害・保存済みの4状態、?q=のURL、履歴、表表示、3幅で横はみ出し無し、シェア）
自分でやった: 題材の選定（設計済みのMAGTRACEをDay 23にすると決めた）／「実装はしていい、まだGitには出さない」の判断／実機での確認とX投稿、データ提供元への継続利用の連絡
失敗と修正: 転機の判定を「前年比の倍率が最大の年」にしたら、サウナで2003年（1件→6件）を転機にした。件数が小さい年ほど倍率が跳ねる → 「前年からの増加数が最大の年」に変え、倍率が1.5倍未満のときは見出しを「前年からいちばん増えた（○件→○件）」にした。推し活は2024年（18→45件）、サウナは2022年（9→36件）になった
グラフのSVGを固定サイズ（760×330）で描いてCSSで縮めていたため、390px幅では軸の文字が実寸4pxで読めなかった（採点で0点） → コンテナの幅を測って1単位＝1CSSピクセルで描き直し、幅が変わったら再描画する。狭い幅ではX軸のラベルを4本に間引いた
E2Eで意図的に502を返すテストが、ブラウザの「Failed to load resource」のコンソールエラーで「エラー0件」の検査に引っかかった → そのテストだけ、意図した502のログを除外した
採点者が「読込中の表示が無い」「結果表示後にヘッダーが画面外へ飛ぶ」「390pxでグラフの線がピークまで届かない」と指摘した（3件とも0点や減点の根拠になった） → コードと実機で裏を取ると、NDL側のキャッシュで応答が0.6秒になり撮影時に結果が出ていたこと、撮影スクリプトがスムーズスクロールの途中で撮っていたこと、折れ線の描画アニメーション（0.9秒）の途中で撮っていたことが原因だった。アプリは直さず、撮影スクリプトを「結果が出て2秒待つ」「即時スクロール」に直した

Day 022公開中

その備蓄、何日もつ？

いま家にある飲料水・食料・簡易トイレの量と人数を入れると、この家が何日もつかを1つの数字で出し、いちばん先に尽きるものと、3日／7日にするために足りない量を「2Lペットボトルあと何本」の形で示す。乳幼児・ペット・薬などは1日の量を自分で決める追加の行で日数にできる。入力は端末内にだけ保存し、どこにも送らない

bousai
stockpile
localstorage

アプリを開く

制作メモ

AIに任せた: 数字の出典を一次資料で確認したこと。飲料水1人1日3Lと3日分・1週間分は首相官邸のページ、食品の最低3日〜1週間分は農林水産省のストックガイド、簡易トイレの1人1日5回は内閣府「避難所におけるトイレの確保・管理ガイドライン」のPDFを開いて「1日当たり必要な便袋の枚数＝人数×5回」の記述を確かめた／実装前にユーザーストーリー5本とUX5階層を書き、そこから10件の実装を決めたこと（全体の日数は各行の最小値・不足量は2Lペットボトル本数で併記・公式の目安が無いものは自分で1日の量を決める追加の行・年齢係数を作らない・期限は行ごとに1つ・保存できない環境でも計算は動くなど）／UI採点ループ3周（実装Codex・採点は別セッションのOpus・スクショのみで採点）。14→16→最終採点は制作記録参照。要約バーの主役化、人数ステッパーの一塊化、追加の行カードの3列グリッド、ボトルネックのバッジと導線、買い足しリストのコピーを入れた／採点の指摘のうち「日付入力が英語表記」「Webフォント3系統」は撮影ブラウザとフォント指定の事情による偽陽性と判断して直さなかったこと／ユニット41件（計算・期限・保存の純ロジック）とE2E 19件（空状態・計算・不足量・目標切替・追加の行・不正入力・再読込で復元・2回押しで消去・期限バッジ・localStorage不可・3幅で横はみ出し無し・コピー）
自分でやった: 題材の選定（防災備蓄・会議コスト・有給の連休・在庫の公開の4案からA案を選んだ）／実機での確認とX投稿
失敗と修正: 要約バーの「あと1.5日」が本文と同じ大きさで、カード内の「2.0日」のほうが大きい主従逆転になっていた。固定バーも117pxあり、スクロールで入力欄を覆ってE2Eのクリックまで失敗した → 日数を34px以上の太字にして、先に尽きるもの・不足量・期限切れを短いチップに分けた。チップは該当カードへのアンカーにし、scroll-padding-topで固定バーが対象を覆わないようにした
空状態だけに出すはずの「まず飲料水の量を入れる」リンクが、在庫を入れた後も残っていた。hidden属性を付けていたが、CSSのdisplay指定がブラウザ既定の[hidden]より強く効いていた → [hidden]{display:none !important}を全体ルールにして、在庫あり状態でリンクが消えることをE2Eで固定した

Day 021公開中

ちかくのラジオ

現在地や選んだ街の近くにあるネットラジオ局を距離順に並べ、ワンタップで流すプレイヤー。近くに局が無ければ半径が25→1000kmまで自動で広がり、鳴らない局は自動でスキップして次へ。radikoは規約上対象外なので、Radio Browserに登録された局（コミュニティFMや海外局）が相手になる。旅モード「どこかの街」で世界の街の近くにも飛べる

radio
geolocation
external-api

アプリを開く

制作メモ

AIに任せた: 実装前にユーザーストーリー5本とUX5階層を書き、そこから7件の実装を決めたこと（0件時の半径自動拡大／位置拒否時の都道府県フォールバック／エラー局の自動スキップ／固定プレイヤーのザッピング動線／クリック起点の再生／旅モード／座標送信の明示）／規約チェック。Radio Browser APIは有償/無償ソフトでの利用可と明記された完全オープンなAPIで、運営のお願い（クリック報告）も実装した。radikoは公式APIがなく非公式利用が規約NGのため対象外にした／距離順をAPIのorderに頼らず、クライアント側でhaversineを計算して並べ直す設計。lib/はfetchを注入できる純関数にして、ユニットテスト14件で固定した／再生失敗の扱い。4秒でcanplayしない局も失敗とみなし、NGマークを付けて距離順の次の局へ自動で進む。全滅したときは「範囲を広げる」「再試行」の導線を出す／APIミラー3つ（de1→nl1→at1）のfallback。5xxは次のミラーへ、4xxはリクエスト自体の問題なので繰り返さない／公開ゲートの適用。公開ページはHTTPSでhttp配信局は混在コンテンツとして止められるため、APIの段階でis_https=trueに絞り、整形時にもhttpsだけ通すようにした。ローカル検証用に残っていた「URLにerrorを含む局を失敗扱いにする」テストフックも、本番コードから外してテスト側のスタブに移した
自分でやった: 「近くのネットラジオを距離順に、ワンタップで」という発案と、Day 021としての公開判断（当初はローカル専用の指定だった）／実機での聴取確認
失敗と修正: 日本の在庫が想定よりずっと薄かった。Radio Browserの日本の局は登録213・動作127局で、座標を持つのは1桁。東京ですら25km圏で2局、秋田は300km圏で0局 → アプリ側で埋められる問題ではないので、0件時の半径自動拡大（25→100→300→1000km）と旅モードで「どこかは必ず鳴る」体験に振った。公開後に追加できる合法なデータ源も調べたが、radikoは規約NG、JCBAサイマルラジオは許諾制（非許諾アプリへの供給を実際に止めた実績あり）、NHKらじる★らじるも公式アプリ前提で、日本のラジオはオープンAPI側に局がいない構造だった
仕上げ中に実装担当のエージェントがクレジット切れで途中死した。編集が終わっているのか中断なのか、出力からは分からない → 現状のファイルを直接確認すると編集自体は完了しており、E2Eの再実行だけで完全性を確認できた。作業のやり直しは不要だった

Day 020外部で公開

モザイカー

YouTubeコメント欄の誹謗中傷を端末内で判定し、読む前にモザイクで隠すChrome拡張。クリックで開示でき、外部通信なし・アカウント不要・無料。紹介ページを公開中（ストア提出はこれから）

chrome-extension
youtube
privacy

紹介ページを開く

Day 019外部で公開

そのままコード

開いているページを1クリックで二次元コードに変えるChrome拡張。中身は生のURL全文で、短縮もリダイレクトも外部通信もしない。権限はactiveTabのみ・アカウント不要・無料。Chromeウェブストアで公開中

chrome-extension
qr-code
privacy

紹介ページを開く

Day 018公開中

秋田の飯は、打てた分だけ

流れてくる秋田の郷土料理をローマ字で打つと、その料理を食べたことになる。60秒でコース料金の元が取れたかを会計で判定する。判定はIMEと同じ寛容さで、しはshiでもsiでも、んはnでもnnでも通る。走行中の皿には先頭キー1文字の札が出ていて、その1打目を押すとどの皿から始めるかを選べる——左端の消えかけを拾うか、奥の高い皿へ手を伸ばすかを時間で賭ける。打ち始めた皿は取り上げないので、遅い人でも打った分だけ食べられる。音は音源ファイルを持たずWeb Audioで生成している

typing
game
akita

所要時間9時間20分

アプリを開く

制作メモ

AIに任せた: ローマ字判定エンジンの設計。かなを1〜2文字のチャンクに切り、チャンクごとに通る書き方の集合を持たせる方式。1つの正解と文字列比較する実装を却下したのは、しょっつるなべが shottsurunabe でも syotturunabe でも通らないと実用にならないため／んの扱い。n単独で確定してよいかは次のかなで変わる（とんぶり＝tonburiは通すが、こんやく＝konyakuは通してはいけない）。次チャンクの先頭が母音・n・yのときだけn単独を候補から外す実装にした／nを打った瞬間に確定させない保留の仕組み。完全一致してもより長い候補が生きているうちは確定を待ち、次のキーがどの候補にも当たらなかったときに初めて確定して打ち直す。これが無いとnnと打つ癖の人が全員弾かれる／っを次のチャンクと合体させる実装。がっこのっこは kko で1チャンク（かな2文字ぶん）として生成する／値段を打鍵数で決める判断。かなの文字数だとはたはた（4かな8打）がじゅんさい（5かな6打）より安くなり、打つ手間と釣り合わなくなる／ユニットテスト36本（別表記の受理、語尾のん、っの重ね、づとずの区別、押してほしかったキーの通知、皿の投入と取りこぼし、会計、つまずき集計）／ベルトの設計。走行時間を固定値にしていたら、速い人がレーンを空にして1〜2秒なにも打てない時間が生まれた。走行時間＝投入間隔×4枚に組み直し、コースが速くなってもベルトの詰まり方は変わらず速さだけが変わる形にした。4枚なのは幅375pxの画面でも皿が重ならない上限だから／?duration= で回を短くしたときにコース料金も同じ比率で按分する判断。60秒ぶんの料金のままだと15秒の回は必ず足が出る＝結果画面が嘘になる／体験評価ハーネスを2周まわしたこと（別セッションのOpusがコードを見ずに実際に遊んで10項目で採点）。1周目12/20点で不合格、改善を入れて2周目18/20点で合格／1周目の指摘で自分の難易度計算が間違っていたと分かったこと。式では0.8打/秒で元が取れるはずが実測1.9打/秒必要だった。式に「的が常に左端＝残り時間が最短の皿に固定される」という構造が入っておらず、遅い人ほど打ちかけの皿を取り上げられ続けていた／根本対策として「1打でも入れた皿は取り上げない（左端で止まって待つ）」を入れたこと。速度と収穫を切り離す設計で、これによりお手軽は1打/秒でも元が取れるようになった／難易度を式ではなく実際にゲームを1分間回して測るテストに置き換えたこと。ミス率10〜30%の初心者も再現する。式ベースのテストは実測と2倍ずれたので削除した／料理20品ぶんの絵と開始画面のキービジュアルを生成したこと（別のCLIに委譲）。20枚で様式を揃えるため、真俯瞰・器1つ・無地の淡いベージュ背景・やわらかい自然光・文字なし、という共通の作法を1つ書いて4本に分けて並列で回した。合計82KBに落としてある／【v2】レビュー→裏取り→計画→実装の3役ループを3周まわしたこと。1周目は表層UI・設定/入力/a11y・音・ゲーム設計の4観点で並列にレビューし、57件の指摘のうちコードで裏を取って実在した54件だけを計画に流した／【v2】走行中の皿に先頭キー1文字の札を出し、語の1打目でどの皿から打ち始めるか選べるようにした設計。それまで的は常に自動で左端に固定され、得点が打鍵速度のほぼ線形関数だった（おすすめ・seed7で 0.8打/秒→¥930 ／ 2.5→¥3,460 ／ 5.5→¥6,430）／【v2】乗り換えを語の1打目だけに限る判断。語中でも許すと打ち間違いと選択が区別できず、隣接キー誤打を10%混ぜた実プレイで誤打19回のうち3回（16%）が乗り換えとして発火し、打ちかけの語が無言で全部消えた／【v2】音をWeb Audio APIで生成する設計（音源ファイルを持てないため）。鳴らすのは5つで打鍵音は鳴らさない——見えているものに音を重ねても情報が増えないので、視線が打鍵行に釘付けの間に見えていないもの（金額・残り時間・逃した皿）だけを耳へ運ぶ。BGMはループ素材を持たずseedから拍ごとに組み立て、都節音階は既存の和風BGMに寄るため使わない／【v2】打鍵行をレーン直下へ上げたこと。「レーンのすぐ下」のはずが実測283px離れており、1皿に1度しか見ない絵・豆知識・よみが、1文字ごとに見る行を画面外へ押し出していた。よみは20品中13品が名前と完全に同一だったので行ごと捨て、漢字を含む5品だけrubyにした／【v2】明るいレーンの上では明るい色が合図にならないという指摘への対応（琥珀1.6:1・赤2:1）。合図を濃い茶の縁を軸に作り直した（皿の縁で約16:1）／【v2】始める前の「ためし打ち」。既定のおすすめは2.5打/秒が要り、遅い人はそこで必ず負けていた。結果画面の助言は負けた60秒のあとにしか出せないので、始める前に測れる場所を作った
自分でやった: 既存のタイピングゲームの形式を借りて秋田版を作る、という題材の指定／提示した4つの舞台（郷土料理の食べ放題／パラソルアイス／難読地名／ハタハタ漁）からの選択
失敗と修正: ゲームの進行テストが5件まとめて落ちた。原因は開始時刻に0を渡していたこと。startedAt が 0 だと if (!startedAt) が真になり、始まっているのに「まだ始まっていない」と判定される。テスト側の値の問題ではなく、実装が0を扱えていない → running という真偽値を別に持たせ、時刻の値で開始判定をしないようにした。ブラウザでも rAF の時刻がページ読み込み直後は0近辺なので、同じ踏み方をしうる形だった
「っは次の子音を重ねる」テストが1件落ちたが、実装ではなくテストの打鍵文字列が間違っていた。しょっつるなべのっつを ttu で打つなら「す」は入らないのに、shottusurunabe（tsuとtuを混ぜた形）を期待値にしていた → shotturunabe に直した。ローマ字の別表記を並べるテストは、期待値そのものを間違えやすい
皿の投入テストが、料理名を決め打ちして 'gibasa' と打っていた。皿は山を切って配るので1枚目が何になるかは決まっておらず、別の料理が来ると全打鍵がミスになり、それでも「皿が減っていない」ことは満たすので通ってしまう。落ちて初めて決め打ちに気付いた → いま出ている皿のよみから primaryRomaji でローマ字を組み立てて打つヘルパーに置き換えた。通っていた別のテストも同じ書き方だったので直した
一覧用スクショの1枚目が、レーンに皿が1枚も無い瞬間だった。振り付けが2皿食べたあと250ミリ秒しか待っておらず、次の投入（2秒間隔）より早く撮っていた → 皿が4枚並ぶまで待つヘルパーを足した。ただしこれは撮り方の問題に見えて、実際には「速い人はレーンを空にする」という設計の穴が写っていた
デモ動画でもレーンが空のまま進む時間が目立った。原因は録画スクリプトの打鍵間隔を85ミリ秒＝毎秒12打にしていたこと。人が出せない速さで、供給が追いつかないのは当たり前だった → 195ミリ秒（毎秒5打前後）に落とした。あわせてベルトの設計自体も走行時間＝投入間隔×4枚に組み直した。速すぎるボットが、本物の設計の穴を先に見つけてくれた形
?duration=15 で短い回を録画したら、コース料金が60秒ぶんの¥3,000のまま残り、どれだけ打っても足が出る結果になった。結果画面が実力ではなく設定の都合で決まってしまう → コース料金を回の長さで按分するようにした（15秒なら¥750）。50円単位に丸めて読みやすくしている
難易度を机上の式で設計したら、実測と2倍以上ずれた。式では「1皿あたり60秒÷必要皿数の時間が使える」と仮定していたが、実際の的は常に左端＝残り時間が最も短い皿に固定される。遅い人が打ち始めると数秒で皿が消えて進捗が没収され、次の的もまた消えかけの皿になる。1打/秒でお手軽を遊ぶと18皿中1皿しか食べられず¥900の損だった（体験評価1周目・4シードで再現） → 1打でも入れた皿は取り上げない形にした。左端に着いたらそこで止まり、打ち終わるまで的から外れない。1打も入れていない皿は今までどおり流れて逃すので、時間の緊張は残る。あわせて難易度のテストを、式ではなく実際にゲームを1分間回して測る形に作り直した
「打ち切った瞬間に金額が増えるのが気持ちいい」がこのアプリの狙いなのに、その瞬間の演出を1つも作っていなかった。体験評価1周目で、完成直後175ms分の連続スクショ10枚が1バイトも違わないと指摘された → 皿が上に弾けて消える／金額の右に「+¥350」が浮く／金額そのものが跳ねる、の3つを足した。2周目で「視線は中央の料理名にあるのに演出は左上の金額だけ」と再指摘されたので、中央の表示も緑にフラッシュするようにした
初心者の想定をミス0で置いていた。体験評価2周目で「1打/秒でも正確率79.7%だと¥80の負け」と実測された。実際の初心者は必ず打ち間違える → シミュレーションにミス率を入れて測り直し、お手軽の目標を¥1,000→¥700にした。ミス率30%（正確率70%）でも元が取れる水準。テストもミス率10/20/30%で回している
打ちかけの皿を左端に留めたら、後ろの皿が真下に潜り込んで文字が重なり「ぎじゅばんさい」のように読めなくなった。半透明にしても文字同士は重なるので解決しない → つかんでいる皿はレーンから消し、レーン左端の帯と、下の大きな表示に付けた「つかみ中 — 打ち終わるまで待ちます」で伝える形にした
ローマ字の案内が打鍵の途中で書き換わった。`kiritanpo` の n を打った瞬間に `kiritannpo` へ変わり、押す必要のない2つ目の n を指していた。残りを毎回その場で組み立て直していたのが原因 → 語の頭で決めた綴りを持ち回る方式にした。別表記（si / jyu など）に分岐したときだけ組み直す。案内が最後まで動かないことをテストで固定した
「つかみ中」バッジが、まだ1文字も打っていないのに出たままになった。CSSで `.held-badge { display: inline-block }` と書いたため、ブラウザ既定の `[hidden] { display: none }` を上書きしていた。作者スタイルはUA既定に勝つ → `.held-badge[hidden] { display: none }` を足した。あわせて hidden 属性を使う全要素に display 指定が無いかを機械的に確認した（他には無し）
スマホで1文字も打てなかった。keydown だけを見ており、Androidのソフトキーボードが返す keyCode 229 を「IMEで変換中」とみなして捨てていた。実際には変換していなくても229が来る → beforeinput からも1文字ずつ拾う経路を足し、keyCode 229 の判定をやめた（変換中の判定は isComposing と compositionstart に任せる）。物理キーは preventDefault しているので二重に数えない。両方をE2Eで固定した
生成した料理の絵をそのまま円く切り抜いたら、画像の背景（淡いベージュ）が円の外周に輪として残り、中央の大きな表示が「皿の上に皿が乗っている」ように見えた → 中央を切り詰めて器が円いっぱいになるようにした。1254pxの元画像を消したあとに気付いたので、224pxのWebPから172pxへ切り直している。次に作るときは、縮小する前に切り詰める
【v2】難易度テストの擬似誤打が z/q 固定で、20品の先頭キー {a,b,d,g,h,i,j,k,m,s,t} に一度も当たらなかった。そのため「皿の乗り換え」の経路がテストの中で構造的に一度も発火せず、実プレイで起きていた事故（打ちかけの語が無言で消える）を1件も捕まえないまま、難易度の梯子が1行も変わらずに通っていた → 擬似誤打を「押すはずのキーの隣」に替えて測り直した。お手軽・1打/秒・ミス率30% は旧仕様 3/5勝（平均¥734・目標¥700）に対し、乗り換えを1打目に限った後は 5/5勝（平均¥792）。「初心者が3割ミスしても元が取れる」という約束が実プレイでは破れていたのに、テストは緑のまま通っていた。この誤打表は元に戻さないこと
【v2】デモ動画の1コマ目が、レーンに皿が1枚しか無く画面の大半が空の瞬間だった。v2で打鍵行を上へ寄せたぶん収録の頭出し位置がずれ、切り落とす秒数（3.3秒）が合わなくなっていた → 5.0秒に変更し、レーンに3皿が並んで札が見え、奥の皿を選んだ直後の瞬間を1コマ目にした（15.3秒）。あわせてdemo-scenario.mjsに「奥の皿の札を押す」振り付けを足し、v2の目玉が動画に写るようにした
【v2】apps/ に meta.json の無いフォルダが1つあるだけで、tests/e2e/shared-share.spec.mjs がモジュール読み込み時にENOENTで落ち、E2Eスイート全体が0件になる。終了コードは0なので、テストが全部消えたことに気づけない → 暫定でdraftのmeta.jsonを置いて回避した。恒久対策はspec側で「meta.jsonがあるディレクトリだけを見る」ようにすること（未実施）

Day 017公開中

AIの読みが見えるリバーシ

リバーシで対局しながら、AIが今どのマスを何点と見ているかが盤面に重なって見える。しかも1手先から4手先へ読みを深めるたびに数字が書き換わり、最善手が入れ替わる過程がそのまま見える。演出の待ち時間ではなく反復深化で本当に探索し直している。各手には「角を取れる」「相手の打てる場所を5→2に減らせる」のような日本語の理由が付く

reversi
game
ai

所要時間43分

アプリを開く

制作メモ

AIに任せた: 着手前の法務確認（「オセロ」＝メガハウスの登録商標／ルール自体は19世紀末のリバーシで特許・実用新案なし／8×8緑盤の意匠権は1993年失効／釣りゲータウン2事件でゲームのルールはアイデアとして著作権の保護外と確定）を一次情報に当たって整理し、名称と配色の判断に落としたこと／UX5階層を実装前に通し、設計を4か所変更したこと。最大の変更は「AIに演出用の待ち時間を入れて思考中に見せる」案を却下し、反復深化に置き換えたこと。前者は嘘の演出になるが、後者は本当に読み直しているので最善手が実際に入れ替わる／評価関数を3要素（位置の価値・着手可能数・石数）だけに絞ったこと。要素を増やすと強くはなるが、盤に出る数字の理由を日本語で説明できなくなるため、説明可能性を優先して意図的に絞った／根の各手のスコアだけαβの窓を開き直す実装。通常のαβは2番手以降が上界・下界にしかならず正確な値が出ないが、このアプリは全候補手の点数を画面に出すので丸めると嘘になる。速度より表示の正確さを優先した／ルール・探索・説明文のユニットテスト30本（合法手の生成、複数方向の裏返し、パス、終局、角の優先、反復深化の段階、深さ4の実行時間）
自分でやった: 「ボードゲームを作って公開していいのか」という問いの提起と、オセロ・UNO・トランプ・ソリティアという具体的な検討対象の指定／提示した4案からの選択（思考が見えるリバーシ）
失敗と修正: ユニットテストが2件落ちたが、どちらも実装ではなくテストの書き方の誤りだった。1件目は「複数方向を同時に裏返す」テストで、使わない盤を2つ作ったうえに『d4からは黒石に届かない』という誤った前提を置いていた（実際は右方向で挟めるので裏返る） → 余分な盤を消し、b2に打つと右と下の2方向が返る最小の形だけにした。あわせて『相手の石の先が空きなら裏返らない』を別テストとして独立させた
「評価は符号が反転する」テストが 0 と -0 の比較で落ちた。初期配置は左右対称なので評価値が 0 になり、その符号反転が -0 になる。assert.equal は Object.is 相当なので 0 と -0 を別物として扱う → +0 を足して正規化したうえで、対称でない盤（黒がd3に打った局面）でも反転することを確かめる検証を足した。対称な盤だけで符号の性質を確かめていたのが元々の弱さだった
E2Eで「最善手の枠はちょうど1つ」が落ちた。実際には4つ付いていた。原因は仕様の考え違いで、リバーシの初手は盤が左右対称なので4手とも同じ48点になる。同点である以上、最善手は1つに決まらない → 表示を1つに絞るのではなく、同点は同点のまま4つとも枠を付ける方を選んだ。1つに絞ると『同点なのに1つだけ最善に見せる』嘘になる。あわせて画面の説明を『同点なら複数に付きます（初手は盤が対称なので4つとも同点です）』に直し、E2Eも4つを期待する形にした
録画した動画で石が縦長の楕円になっていた。盤を grid で組んだとき grid-template-columns しか指定しておらず、行の高さが中身なりに決まっていた。列は8等分されるが行はされないので、マスが正方形にならない → grid-template-rows: repeat(8, 1fr) を足した。aspect-ratio を親に付けただけでは行は等分されない
デモ動画の1コマ目が、盤ではなく遊び方の説明画面になっていた。振り付けの冒頭で対局開始を押しているのに、録画の開始がページ読み込み時点なので間に合っていない。1コマ目はそのままXのサムネになるため、文字画面から始めてはいけないというルールに反する → 冒頭0.35秒を切り落とした。0.5秒時点では既に盤と評価値が出ていることをコマ送りで確認してから切る位置を決めた。尺は16.3秒で目標の15〜20秒に収まっている

Day 016公開中

回線の犯人さがし

ボタン1つで下り・上り・待機中の反応・通信中の反応を測り、その数字から「遅さの原因が家の中にあるのか外にあるのか」を日本語で判定する。速度の数字を出して終わりにしない。各指標にはA+〜Fの目安と「その速さで何ができるか」が付き、測るたび履歴が貯まって3回めからは夜だけ遅いのか・いつも遅いのかまで分かれる

speedtest
network
bufferbloat

所要時間1時間25分

アプリを開く

制作メモ

AIに任せた: 着手前の実現可能性の確認（speed.cloudflare.com が Access-Control-Allow-Origin: * と timing-allow-origin: * を返すことを実際に叩いて確認。後者が無いとブラウザから正確な時間が取れない）／ブラウザでは原理的にできないことの切り分け（Wi-Fiの電波強度・チャンネルはOS APIのみ、IPv4/IPv6の指定はHappy Eyeballsで不可、定期自動測定はタブを閉じると止まる）を要件から先に外す判断／測定エンジンの自作（@cloudflare/speedtest は結果をCloudflareへ送信する仕様で「どこにも送信しない」という画面の記述と食い違うため不採用にした）／診断ロジック8分岐の設計と、実回線なしで全分岐を固定入力で検証するユニットテスト46本／スタブだけで作り切らず、最後に本物のエンドポイントへ実際に繋いで通すところまでやったこと（そこで初めて見つかった不具合が1件ある）／指標の目安（A+〜F）のしきい値を、感覚ではなく実際の用途が要求する値から引いたこと（Netflixの推奨速度・Zoomの送信量・ITU-T G.114・ゲームのping・通話が崩れる30ms）。遅延は往復時間で測っているのに対しG.114は片道の規定なので、片道150ms＝往復300msへ換算して使っている
自分でやった: 題材の指定（自宅回線の診断経験をアプリにする）と、アプリ名・通信量の初期値の決定／作る前に「今使っているルーターと買い替え候補どちらが良いか」という実際の困りごとを持ち込んだこと／公開後に「指標があるならどこかに書いておいてほしい。A〜Fのクラスとクラスごとの目安があるとよい」と発案（Day010・014・015と同じ流れ）
失敗と修正: 上りが62Mbpsしか出ず、狙って作った「下りだけ遅い回線」の判定が出なかった。原因は本体のバグで、転送しながら往復時間も測る組み立てのまま「往復時間の測定が終わるまで待ってから」経過時間を取っていた＝遅延の測定にかかった時間が帯域の分母に混ざっていた → 転送が終わった時点で経過時間を取り、往復時間の結果はそのあとで受け取るように直した。転送が終わったら往復時間の測定も止める。1本200msの測定を6本仕込むと25Mbpsが13Mbpsまで落ちることを固定入力で再現する回帰テストを足した
画面にはグレードBと出ているのに、保存された履歴のグレードが空（—）のままだった。採点を表示のときだけ行い、保存には採点前の値を渡していた。スタブのテストは全部通っていて気付けず、本物の回線で1回動かして初めて分かった → 採点まで済ませた1件を先に作り、保存・表示・診断のすべてがそれを使うようにした。画面のグレードと保存されたグレードが一致することを見るE2Eを足した
E2Eで、接続がIPv6かどうかの表示だけが落ちた。スタブがヘッダを返しているのにブラウザから読めなかった → 別オリジンのJSがレスポンスヘッダを読むには Access-Control-Expose-Headers での公開が要る。本物はこれを返しているので、スタブ側を本物の応答に合わせた。スタブが現実より甘いと、本番だけ動かない作りを通してしまう
ローカルでE2E228本が全部通ったのにCIで1本だけ落ちた。「下りだけが遅い」判定のE2Eが、実際に測った速さで分岐する作りになっていて、上りが下りの3倍を超える必要があった。ローカルでは余裕1.2倍程度で通っていたが、CIの機械では上りが伸びずに条件を満たさなかった → 節約モードで運ぶ量を1/10にし、下りを遅らせる時間を1.2秒から3秒に増やして、条件の余裕を18.8倍に広げた（下り2.6Mbpsに対し上りは7.8Mbps出れば足りるところ146.8Mbps）。実測値で分岐するE2Eは機械の速さで結果が変わるので、余裕を数値で確かめてから置くようにした

Day 015公開中

あなたの街のステータス

指標を選ぶと、1,741市区町村を順位で塗ったヒートマップの日本地図が出る。海岸線は描かず、人口でならした代表点だけで日本の形になる。点を押すとその街の人口・年齢・世帯のステータスカード（全国順位・中央値つき）。2つの街の比較も。良い悪いは言わない設計

e-stat
gsi
open-data

所要時間3時間35分

アプリを開く

制作メモ

AIに任せた: 着手前の法務・規約調査（e-Statの利用規約はCC BY 4.0互換で商用可・数値データは著作権の対象外・地理院タイルはリアルタイム読込なら申請不要、をすべて一次情報の原文で確認）／国勢調査のExcelをZIPから自前で解いて1,741市区町村を取り出し、国土地理院の面積調CSVと結合する変換ツール（検算つき）／順位（同値は競技方式）・全国中央値・検索の純関数と、先に書いた受け入れテストで生成物を検収する進め方／「ワースト」などの価値判断語が画面に出たら落ちるE2Eを含む、4状態対応のテスト（ユニット23＋データ検算6＋E2E10）／実装の下書きをローカルLLM（Gemma3 27B・Ollama）に出させ、検収→指摘リストつき差し戻しで回す実験の運転／公開後の本人発案「ランキングごとのヒートマップ地図」の追加＝境界データ（e-Stat統計GIS）の小地域重心を人口で重み付けした1,741点の代表点計算と、順位で塗る地図（海岸線なし・単一色相・方向つき凡例・タップでカードへ）
自分でやった: 題材の指定（e-Stat × 国土地理院の地域ランキング）と「規約違反や炎上をしない作り方で」という方針の指示／実装をローカルLLM（Gemma3 27B）に任せる実験の発案／公開後に「地図にしてほしい。ランキングごとにヒートマップ化」と作り直しを発案（Day 010・014と同じ流れ）
失敗と修正: Gemma3 27Bにデータ変換ツールを2周書かせたが、ZIPの解凍手順や存在しないAPIを毎回作話して悪化した（1周目は検収指摘13件、2周目は指摘を渡した上で別の作話） → 「同じ失敗2回で人に返す」ルールどおり、バイナリ解析だけ検収側が実装。テキスト寄りのstats.jsは1周＋修正3か所で合格、HTMLはほぼそのまま使えた＝ローカル27Bは得意分野の見極めが要る
画面の配線(app.js)も存在しないライブラリ(select2)を前提に書いてきた（作話系2件目） → 検収側が書き直し。受け入れテスト（E2E10本）を先に書いてあったので、書き直しの正しさはテストで確認できた
「全町で人口>0」の検算が双葉町(07546)で落ちた。2020年国勢調査の双葉町は全町避難で、元の表でも人口が「-」 → 0に書き換えず「—」のまま表示する設計にし、「人口が欠けるのは双葉町だけ」を検証で固定。順位の母数からも正直に外れる（総人口だけ1,740）
データ読込中に検索し始めると、読み込みが終わっても候補が出ないままになる（E2Eのスイート実行だけで顕在化するタイミング差） → 読込完了時に、検索箱にフォーカスがあれば候補を出し直す。最初の直し方だと復元した街名から候補が勝手に開く副作用があり、フォーカス条件を足して解消

Day 014公開中

いま、日本でいちばん暑い場所

気象庁アメダスの実測気温を10分ごとに受け取り、観測所そのものを点として置いた日本地図に色で描く。点をさわるとその土地へ寄って、気温と全国順位が出る。予報ではなく、いま測られている値だけを扱う

amedas
jma
open-data

所要時間3時間20分

アプリを開く

制作メモ

AIに任せた: 気象庁の配信仕様と利用規約の実測（気温を測っているのは1,286地点中916地点だけ・CORSが開いている・加工したときは出典とは別にその旨を書く義務がある）／地点番号の上2桁から都道府県を引く対応表の作成と、県庁所在地47地点＋全国の著名地点45地点での照合／観測所の緯度経度だけで日本地図を描く実装（海岸線データを持たない）と、寄る・探す・押すの操作／要件定義と実装、テスト42件（計算26件・ブラウザ16件）／本番でだけ止まる不具合の切り分けと、同じ止まり方を次から機械で捕まえるテストの追加
自分でやった: 3案と軽い保険1案から、作るものを選ぶ判断／公開したあとに「実際にその地域に行けるようにしたい。日本地図で探して、検索すれば自分の地域があるか見られる」と作り直しを発案
失敗と修正: 「秋田」で探すと秋田県の全地点が並んだ。地点名と都道府県名を同じ土俵で照合していたため、県名でもある地名を打った人が自分の街を選べなくなっていた → 地点名で当たったものが1つでもあれば、県名だけで当たったものは落とす。さらに地点名そのものを打たれたときは、それだけを返すようにした
それでも「秋田」で雄和が出た。気象庁の読みの欄には「ユウワ：秋田空港」のように別名が入っていることがあり、そこに引っかかっていた → 完全一致を優先して1件に絞り、同名の地点を選ばせるときは別名も画面に出すようにした（別名で探せること自体は残した）
棒グラフが伸びている途中で地点を選ぶと、選んだ位置を指す印が消えた。走り続けている古いコマが、印を描いた上に重ね書きしていた → 描画に世代番号を持たせ、新しい描画が始まったら古いコマは降りるようにした。直す前のコードでテストが落ちることも確認した
同じ気温の地点の並び順を漢字の照合順で決めていたため、秋田より横手が先に来た → 読み（片仮名）の順に並べた
散らばりの図で、左端の目盛りが枠の外に切れていた。富士山だけが入る1本も線にすらならず、注記で名指ししているのに画面から消えていた → 余白を広げ、0地点でない本には最低の高さを与えた
公開前の権利チェックで、気象庁の公共データ利用規約（第1.0版）が、出典の記載だけでなく『編集・加工した場合は、出典とは別にその旨を記載すること』『国が作成したかのような態様で公表しないこと』まで求めていることが分かった。順位も気温差も都道府県名もこちらの計算なのに、出典しか書いていなかった → 画面の末尾に、順位・気温差・都道府県名はこのページが計算したもので、気象庁が発表しているものではないと明記した
本番へ出したら、画面が『気象庁から受け取っています』のまま止まった。ローカルのブラウザテストは上流を差し替えて動かすのでCSPに触れず、最後まで気付けなかった。CSPのconnect-srcは既定で同一オリジンだけなので、気象庁への接続がブラウザ側で黙って止められていた → そのDayの接続先をCSPへ足した。あわせて、コードの中で変数に入れているURLとfetchに直接渡しているURLを集めて、そのDayのCSPで許されているかを突き合わせるテストを足した（この網が無いと次のDayでも同じ止まり方をする）。外した状態でテストが落ちることも確認した
地図の南西諸島を別枠に固定で置いたら、画面が縦長のときに九州の点の上に重なった → 描くたびに、本土の点がいちばん少ない隅を選んで置くようにした
地名を「拡大率」で出していたので、南西諸島のように広くて点が少ない場所では名前が出なかった → 画面に見えている点の数で判断するようにした。少なければ寄らなくても名前が読める
南西諸島を別枠のままにすると、そこだけ「行けない場所」の絵になってしまう → 全体を見ているときだけ別枠に出し、寄ったら本物の緯度経度に切り替えるようにした。海を越えて沖縄まで行ける

Day 013公開中

政府はこう答えてきた

テーマを入れると、国会会議録から政府側の答弁だけを抜き出して、いつ・どの省庁が・何と答えてきたかを年表にする。質問した議員と民間の参考人の発言は除いてある

kokkai-api
open-data
government

所要時間40分

アプリを開く

制作メモ

AIに任せた: 企画が成立するかを実装前に実測（CORS・認証・遡及範囲・公開の遅れ）。当初案の「今日言われた言葉」は会議録が3〜4週間遅れて公開されるため作れないと分かり、企画を作り直した／著作権法40条1項の「同一の著作者のものを編集して利用する場合を除き」という除外規定が、一人の議員の発言を集める設計に直撃することの指摘／政府答弁の見分け方を実データで確定。府省庁名と政府役職のホワイトリスト方式／実装前にユーザーストーリーとUX5階層を書き、そこから設計判断を5個変えた／ロジックのユニット15項目とE2Eの実装、4状態の作り分け
自分でやった: 国会APIで議員の人物像と矛盾をまとめる、という発案／著作権を確認してほしいという指示／対象を『政府側の答弁だけ』に絞る判断／提案は誰のためのアプリか（ユーザー・行動・解決）まで踏み込め、という指摘
失敗と修正: 「今日、国会で言われた言葉」を作るつもりだったが、会議録は速記録なので公開が3〜4週間遅れる。今日の分のデータは存在しなかった（8月20日時点で最新は7月27日） → APIの本当の強みが「今」ではなく「1947年からの推移」だと分かったので、年表を見せるアプリに作り直した
政府答弁を役職欄の有無だけで見分けようとしていた。実データを見たら「株式会社◯◯上席研究員」「日本放送協会理事」など民間の参考人にも肩書が入っていて、政府として数えると誤情報になるところだった → 府省庁名と政府役職のホワイトリストに変えた。実データ63種で検証し、除外された5種がすべて正しく非政府であることを確認した
「環境副大臣」の所管が引けていなかった。「環境副大臣」という文字列は「環境大臣」を含まないため、全省庁の副大臣と政務官が所管不明に落ちていた → 正規表現で副大臣・大臣政務官も拾うようにした。テストを1本足して固定した
省庁別のバーが件数に関係なく全部同じ長さだった。span が display:inline のままで幅指定が無視され、実寸0pxになっていた。見えていたのは背景だけで、「どの省庁も同じだけ答弁している」と誤読させる状態だった → display:block を指定した。見た目の粗ではなく誤情報なので優先して直した
並び替えが壊れているように見えたが、検索の完了を待たずに測っていただけだった → 完了を待ってから測り直したら正常だった。バグと決めつける前にコードで裏を取る

Day 012公開中

海賊船の打ち返し係

敵船が撃つ音を聞いて、飛んでくる砲弾を拍で打ち返す1ボタンのリズムゲーム。曲も効果音も海も船も砲弾も、すべてこのページのコードが組み立てている。画像も音源も1つも読み込まず、3Dはライブラリを使わない自前の透視投影で描いている

rhythm-game
web-audio
3d

アプリを開く

制作メモ

AIに任せた: 音の時計を正本にする実装。拍の位置は必ず AudioContext.currentTime から逆算し、音の予約は25msごとに100ms先まで入れる。押した時刻は getOutputTimestamp() で音の時計へ直すので、機器の出力遅れが自動で吸収される／曲と効果音を発振器だけで作った。ニ短調・4小節進行の低音と和音とふし、カウントイン、砲弾・二連弾・カモメの3種類の合図音、打った音、船に当たる音、空を切る音。音源ファイルは1つも使っていない／3Dを自前で書いた。透視投影・霧・面の並べ替え・簡易な陰影と、砲弾（八面体を分割した32面の球）・カモメ・敵船・自分の船首・櫂のモデル。頂点はすべてコードで置いている／譜面を拍だけで持つ設計。発射だけを並べて打点は飛行時間から計算する。飛行時間を変えても書き直しが要らない／判定・拍の変換・譜面の妥当性・投影・補正値の読み取りをユニット40件で固定した。隣り合う打点が判定の届く範囲より離れていることも、実時間に直して検査している／E2E 12件。4状態が実際に通ること、キーボードだけで通せること、外部への通信が0本であること、そして画素が実際に描かれていること／権利の線引きの調査と反映。ゲームのルールや仕組みはアイデアなので著作権では保護されないが、名称・キャラクター・曲・効果音・画面構成という表現は保護される。過去には、既存のリズムゲームを再現するツールが権利者の申し立てでGitHubから削除された例（forkを含めて250件以上）もある。そこで、素材を1つも借りず全部その場で作り、公開物に既存作品の固有名を書かない方針にした／敵船が段階的に壊れる演出。ドンピシャで打ち返した弾が「実際に船へ届いた瞬間」に段が進む。帆が裂ける→上の帆が落ちる→マストが折れる→帆をすべて失う→船体が傾く→大破の7段で、遠い小さなシルエットでも輪郭が変わるように壊す順を決めた／おしいの弾は失速して海へ落とし、ドンピシャの弾だけが船へ届くようにした。判定の差を点数ではなく絵で見せるため／体験評価ハーネスを回した。別セッションの評価者が実際にブラウザで遊んで10項目を採点し、返ってきた改善指示を、実装前にコードと実測で1件ずつ裏取りしてから直した／体験評価ハーネスを3周回した（別セッションの評価者が実際にブラウザで遊んで10項目を採点。13→15→16点で合格）。返ってきた指摘は、実装前に必ずコードと実測で裏を取ってから直した／デモ動画に音を付ける道具（tools/render-demo-audio.mjs）。Playwrightは音を録らないので、アプリと同じ音符データ（伴奏・発射・打点）から同じ波形と包絡線でWAVを組み立て直し、ffmpegで重ねている。映像と音のズレが30ms以内であることを、音の立ち上がりと譜面の時刻を突き合わせて実測した
自分でやった: 作るものの指定と、途中での方針転換（海賊船のシミュレーション → 音ゲー）／遊びの型・題材・公開の枠の3点を、提示した選択肢から選ぶ判断／「必要ならネットから商用利用可の素材を拾ってよい。足りない3Dモデルは自作せよ」という素材方針の指定／リサーチを厚くしてよいという指示／「ドンピシャだったら船が崩れていく。打ち返せば打ち返すほど崩れる」という演出の指定／体験評価ハーネスを回すという進め方の指示
失敗と修正: テストが全部通っているのに、画面には何も描かれていなかった。スクショを撮って初めて気づいた。原因は、遊んでいない間は海の画面が display:none で大きさが0になること。起動時に1回だけ測って終わりにしていたので、遊び始めても描画用の大きさが 1×1 のままで、その1画素が引き伸ばされて単色の四角になっていた → ResizeObserver で大きさを見張るようにし、0のときは測り直さないようにした。あわせて『画素が実際に描かれていること』を見るE2Eを足した（描画用の大きさが実寸か・単色で塗りつぶされていないか）。状態だけ見るテストは、真っ白な画面を素通りさせる
打ち返した砲弾が跳ね返らず、当てても外してもそのまま自分に向かって飛び続けていた。手応えがまったく無い → 物体から打点の番号を引けるようにして、当たった弾は打点から元来た方へ戻すようにした。外した弾はそのまま飛んできて船を通り過ぎる
砲弾が水平線と敵船にぴったり重なって、どこにいるのか読めなかった。打点の高さを目線とほぼ同じ（1.32m／目線1.6m）にしていたため、飛んでいる間ずっと遠くの船と同じ高さにいた → 打点を0.85mまで下げ、飛び方を山なりにして空を背負わせた。近くに来るほど水平線から離れて、船首の上に降りてくる
奥行きをまっすぐ割っていたので、飛行時間のほとんどで砲弾が点にしか見えず、最後の数%で急に膨らんだ。見かけの大きさは奥行きの逆数なので、等速で近づけると等速には見えない → 同じ割合ずつ近づく形（幾何級数）にして、見かけの大きさが一定の速さで大きくなるようにした
船首が横に広すぎて、海を隠す茶色い箱に見えていた → 幅を半分以下にし、甲板と舷（ふなべり）と舳先を分けて、輪郭で船だと分かる形にした
ランクの判定で、から振りを1回するだけで最上位から2段落ちる作りになっていた。拍と関係ない入力は減点でよいが、砲弾を通してしまうことより重く扱うのはおかしい → 『通してしまった数』を主に見て、から振りは2回まで大目に見るようにした。ユニットテストを書いていて食い違いに気づいた
E2Eが3件落ちて、原因を実装のせいだと読み違えた。実際には dist/ を配って検査する作りなのに、直したあと再ビルドせずに走らせていたので、テストは古いコードを見ていた → ビルドしてから走らせ直した。画面の状態と音の時計を1秒ごとに書き出す小さな検査を先に回して、『短い譜面のはずが本編の31打点になっている』と分かったのが決め手だった
drawObjects の閉じ括弧が1つ落ちていたのに、node --check は「構文OK」と答えた。ページは丸ごと読み込みに失敗していて、その状態でビルドまで通った → E2Eが13件中11件落ちて気づいた。ブラウザのコンソールを見て『Unexpected end of input』を確認し、括弧を補った。構文検査を通ったことは、ブラウザで動くことの証明にならない
押した時刻を音の時計へ直す仕組みが、最初の1回だけ「遅れ0ms」を返していた。実測すると2回目以降は33msで安定するので、1発目だけ判定が33msぶんずれる → 遅れは物理的に正の値にしかならないので、0以下を返してきたら信用せず outputLatency で補うようにした。体験評価者が『+60ms遅らせて押すと1発目だけ判定が違う』と報告してきたのが発端で、実測で裏を取ってから直した
体験評価1周目が13/20点で不合格。当てたときの返り（船が崩れる・連打が通用しない）は既に強いが、入口と自己把握が落ちていた。①遊べる状態になってから初弾まで0.9秒しかなく、1回も成功しないまま本編が始まる ②早いのか遅いのかを一度も教えない ③21/31当てた回と、でたらめ連打の回が同じ見出し・同じ助言 ④HUDの「のこり NN」が残り秒数に読める（実際は残りの砲弾数） ⑤結果の「もう一度」が1200×943で画面の下端で切れて押せない → ①カウントインを4拍から8拍に伸ばし、前半で『練習の1発』を撃つようにした（点にもランクにも入らない）。カウントは画面外の小さな文字ではなく海の上に大きく描く ②判定の真下に「はやい／おそい」を出し、結果に平均のズレと補正の目安値を出す ③ランクを4段から6段にし、助言文も段ごとに変えた ④「砲弾のこり NN発」に変え、画面上端に時間の進捗バーを足した ⑤結果では海を小さくし、結果パネルを画面内へスクロールする。⑤は1200×943で下端967pxと実測してから直した
体験評価2周目（15/20・不合格）で、順位の物差しそのものが違っていたと分かった。敵船を大破させた回（ドンピシャ29）と、1発も届かなかった回（ドンピシャ0・おしい29）が、同じ「操舵手」・同じ助言で返っていた。おしいをドンピシャと同じに数えていたため。画面には「届くのはドンピシャで返した弾だけ」と書いてあるのに、順位だけがその宣言を裏切っていた。1周目に『刻みが少ない』と指摘されて段を増やしたが、それは症状で、原因は物差しだった → 順位を「敵船に届いた弾の数（ドンピシャ）」だけで決めるように作り直した。おしいは順位を上げない。から振りは順位に混ぜない（から振り1回でキャプテンから落ちる段差もやめた）。評価者が挙げた実例そのものを単体テストに固定した。あわせて助言文を全段書き直し（『一発も船に当てていない』は、敵船に当てていないと読めてしまう）、連続数もドンピシャ限定にした
曲が終わってもループが回り続け、finish() が毎フレーム呼ばれていた。結果の中身を毎フレーム作り直していたうえ、結果画面から補正画面へ移ろうとしても次のフレームで結果へ引き戻され、遷移できなかった → 結果と補正の状態では finish() を素通りさせた。体験評価2周目の『結果から音のズレを直す画面へ行けない』を直そうとして、ボタンを足しても動かず、そこで初めて気づいた
モバイルの余白を直したつもりが、海が伸びていなかった。枠（.stage）は694pxまで広がっていたのに、canvas は178pxのままだった。高さが flex で決まる親に対して height:100% は解決できず、canvas 自身の width/height 属性に落ちる。その属性は resize() が測った値なので、小さいまま固まって二度と戻らない → canvas を絶対配置にして、親の高さの決まり方に関係なく埋めるようにした。390×844で海が224px→692px、余白は画面の61%→6%になった。あわせて『海が画面を埋めているか』『canvasが枠を埋めているか』を見るE2Eを足した
上の修正でループを止めたら、今度は結果画面のcanvasが真っ黒になった。結果に移ると海の枠が縮み、ResizeObserverがcanvasの大きさを入れ直す＝中身が消える。描き直す者がいないので、50秒かけて沈めた敵船という一番の見せ場が空の箱になっていた（体験評価3周目が発見） → ループは止めず、二重に結果を作らない番だけを残した。止まっている時に大きさが変わった場合に備えて、resize() 側でも描き直すようにした。E2Eで『結果画面のcanvasが単色で塗りつぶされていないこと』を固定した
CSSのセレクタを `[data-state="playing"] .page` と書いていた。data-state を持っているのは .page 自身なので、子孫セレクタでは当たらない。モバイルの余白が半分残ったまま、直ったつもりでいた → `.page[data-state="playing"]` に直した。他の `[data-state] .stage` 等は .stage が子孫なので正しく効いていた。同じ書き方に見えて、当たるものと当たらないものが混ざっていた

Day 011公開中

この写真、まだ場所を覚えている

写真に残っている撮影地の座標・カメラ本体のシリアル番号・編集前の埋め込みサムネイルを危険度の高い順に見せ、JPEGの区画だけを外して画質を1バイトも変えずに保存する。写真はブラウザの中だけで処理し、外部へは通信を1本も出さない

exif
jpeg
privacy

アプリを開く

制作メモ

AIに任せた: JPEGのセグメント分解・分類・除去の実装。SOS（0xFFDA）から末尾までを1バイトも変えずに写し、除去後のバイト列が元と完全一致することをユニットテストで固定した／規格を読んで分かっていた落とし穴の実装。ExifとXMPはどちらもAPP1なのでマーカー番号ではなく署名文字列で見分け、64KB超で分割された同種の区画を全部消す（最初の1つで打ち切らない）／TIFF/IFDの解析。IIとMMの両方のバイトオーダー、GPSの度分秒、IFD1のサムネイル切り出し、壊れたオフセットや異常なエントリ数で例外を投げずに失敗を返す作り／4状態（空・読込中・エラー・不正入力）＋結果＋対象外の切り替えと、通った順を data-state-log に残す仕組み／サンプル写真の自作（表札の住所が写った絵を描き、それを切り落とした本体に、切り落とす前の絵をIFD1のサムネイルとして差し込む）／ユニット73件・E2E42件のテスト。同一オリジン以外への通信が0本であることもE2Eで固定した／保存したバイト列をアプリ自身でもう一度読み直し、区画ごとの結果（Exifなし／ICCは残しています／画素は元のまま）を画面に出す検算。免責の文章より、その場で確かめられることのほうが効くという調査結果から足した／権利表示（Copyright / Artist）を「あなたにつながるもの」から切り離して第4のカテゴリにする組み替えと、XMPの権利表示（dc:rights・xmpRights:UsageTerms など）を文字列一致だけで拾う判定／個人情報保護法・著作権法（権利管理情報）・製造物責任法・消費者契約法・電気通信事業法の一次情報にあたる調査と、同種の日本語ツール7件の実地調査。そこから「免責文言より画面設計が効く」「権利表示は利用者の利益の向きが逆なので別カテゴリにする」「権利表示だけを消す機能は作らない」を設計へ反映した
自分でやった: 実装に入る前に要件（REQUIREMENTS.md）と設計（DESIGN.md：ユーザーストーリー＋UX5階層）を書き切ってから実装へ渡す、という進め方の指定／免責・注意書き・警告の文言は法務レビューの結果であとで差し替えるので、1か所（lib/copy.js）にまとめておくという指示／この日の成果物をローカルに留め、gitの操作をしないという判断／法的リスクを調べたうえで作る、という進め方の指示。調査そのものはAIが行い、その結果をどう設計へ反映するかを決めた／画面・README・meta.json に、侵害を促す表現と法的評価の断定を書かないという線引き
失敗と修正: 実装に入る前に公開前チェック（npm run precheck）を走らせたら、いきなり落ちた。要件定義に書いていたサンプル写真のメーカー名に実在の名前を使っていたため。このリポジトリは公開なので、そのまま作っていたらサンプルのExifにもドキュメントにも残った → メーカー名を架空のもの（SAMPLE OPTICS）に変え、要件定義側にも変更理由を書き足した。サンプルに実在の名前は使わない
meta.json を draft にすると、ビルドがそのDayを dist/ へコピーしない。E2Eは配信された dist/ を見るので、そのまま書いていたらテストが全部404で落ちるところだった → spec の中に、アプリのフォルダだけを配る小さなサーバーを立てた。公開に切り替えたら通常の baseURL に寄せられる
向き1件だけのExifを組み立てる関数が、文字列の '6' も受け付けていた。中で Number() に通していたため、数でない値が黙って通っていた → 型そのものを見るようにした。ユニットテストが先に捕まえた
壊れたJPEGのテストで、期待した「区切りが壊れている」ではなく「JPEGではない」が返った → 実装ではなくテストの題材が誤っていた（先頭3バイトがJPEGでないバイト列を使っていたので、区切りを読む前に弾かれていた）。テスト側を直した
Exifの中身が壊れたJPEGを、まとめて「読めません」のエラー画面へ送っていた。区画を落とすこと自体はExifの解析結果に関係なくできるので、いちばん消したい写真だけが消せない状態だった。しかも文言のほうには「区画そのものは取り除けます」と書いてあり、画面が文言の約束を果たしていなかった → エラーは「JPEGとして最後まで読めない」場合だけに絞り、中身が読めないだけの写真は結果の画面で扱って保存ボタンを出すようにした。見出しも「見つかりませんでした」と混ざらないよう別の文にした
著作権表示と撮影者名を「あなたにつながるもの」に入れていた。GPSやシリアル番号と同じ束に入ると、利用者には「全部消すのが正解」に見える。他人が撮った写真の権利表示を、何も考えずに消す導線になっていた → 利用者にとっての利益の向きが逆（消したい情報ではなく残したい情報）なので、第4のカテゴリとして切り離した。警告は除去ボタンの真上に出したままにし、検出した値をコピーして控えられるようにした
XMPから拾った権利表示の並び順が、ファイルの中でどのセグメントが先に来るかで変わっていた。強い警告になるもの（利用条件・権利者の連絡先）が後ろに回ることがあった → 見つけた名前を集めてから、こちらが決めた順（強いものが先）に並べ直すようにした。ユニットテストが先に捕まえた
画面に本体の写真を出していないのに、サムネイルの説明だけが「本体の写真と見比べてください」と言っていた。見比べる相手が画面に無いので、このアプリ最大の見せ場（切り落としたはずの表札がサムネイルにだけ残っている）が伝わらない。しかも同じ説明文が、サムネイルの行とカードの下で二重に出ていた → 本体の写真と埋め込みサムネイルを並べて出し、それぞれに「いま見えている写真」「埋め込まれたサムネイル」のラベルを付けた（本体も blob URL で出すので、通信は増えていない）。説明文はカード側で1回だけにした。行側の文言を固定していたユニットテストは、『同じ説明を2か所で言わない』を見る形に書き換えた
「メタデータを消して保存」が390pxで上から3,093px＝全長の68%の位置にあり、主要な行動に届くまで約4.5画面ぶんスクロールが要った → 判定カードの直下へ動かした（390pxで1,125px＝全長の26%）。ただし権利表示の警告は保存ボタンの直上・常時表示のまま（著作権法まわりの要件）、免責は「完全には消せない」「見つからない＝無いではない」の2点だけを上に残し、全文は保存ボタンより下へ移した。画面下に固定バーを出す案は採らなかった。保存ボタンだけを固定バーへ移すと、警告をその直上に置くという条件が満たせなくなるため
「いちばん目立たない文字でもAAを満たす」というE2Eがあったのに、共通シェアの注記が3.2:1しかない状態を素通りさせていた。テストが color の指定値だけを読んでいて、opacity で薄まった後の見た目を見ていなかった（原因は shared/share.css の .share__note { opacity: 0.7 }） → 先祖にかかっている opacity を掛け合わせ、背景と混ぜた色で測るようにテストを書き直した。わざと opacity: 0.7 に戻して落ちること（3.18）を確かめてから、正本の shared/share.css で opacity をやめ、11アプリへ同期した。共通部品なので、この1か所の直しが全アプリに効く
「開く」の行を押しやすくしたことを固定するE2Eが、最初の実行で落ちた。座標で押す前に要素を画面内へスクロールしていなかったので、390pxでは対象が画面の外にあり、クリックが別の場所に当たっていた → 測る前に scrollIntoViewIfNeeded し、開いたあとも位置を測り直してから押すようにした。行の高さは25px→45pxにしてある（.group__head に上下の余白が無く、押せる高さが足りていなかった）
権利表示の警告は、面積では今も保存ボタンより大きい（390pxで警告336px対ボタン54px）。採点では「警告のほうが面積で勝っていて階層が逆転している」と指摘された点 → 文面は法務の調査結果そのもので削れないので、余白・枠の太さ・文字の大きさを落として視覚的に静かにし、常時表示は保ったまま、保存ボタンの側を大きく（横いっぱい・高さ54px・濃い青）した。面積の逆転そのものは解消できていない
共通シェアのボタンの枠が地色に対して1.7:1しかなく、面も1.1:1で「押せるもの」に見えていなかった。前回opacityの穴を塞いだコントラストのE2Eは、文字の色しか見ておらず枠の色を一度も測っていなかった → 枠を currentColor の32%から90%へ上げ、11アプリぶんの枠と地色の比を測るE2Eを足した。濃さは勘ではなく実測で決めた：いちばん条件が厳しいDay007はシェア欄の文字色そのものが地に対して3.9〜5.1:1しかなく、75%では2.6:1で3:1に届かなかった
その新しいE2Eが、最初は嘘の合格を出していた。color-mix() の計算結果を Chromium は color(srgb 0.93 0.94 0.96 / 0.75) の形で返す（成分が0〜1）のに、rgb() と同じ0〜255として読んでいたため、明るい枠を真っ黒として測って19:1と報告していた → color( で始まる値は255倍してから測るようにした。文字側の古いコントラストのE2Eにも同じ読み方が残っていたので、そちらも直した。テスト自身が壊れていると、直したつもりで何も守れていない状態になる
同じE2Eが、Day009だけ1.12:1という桁違いの低さを出した。背景をグラデーションで塗っているアプリでは backgroundColor がどの先祖でも透明のままで、白い紙の上として測っていた（実際は暗い画面） → 先祖を遡るときに background-image のグラデーションも見て、色の停止点を全部拾い、いちばん条件の悪い停止点で判定するようにした。あわせて「枠と面の比」の判定は外した。塗りのあるボタン（--primary）は面そのものが地との境目になるので、そこまで求めると塗りを濃くできなくなる
本体写真と埋め込みサムネイルを狭い画面でも横に並べたら、ラベルの長さが左右で違うせいで（「埋め込まれたサムネイル」だけが2行）、2枚の画像の上端が55pxずれた。このカードは見比べるためにあるのに、見比べにくいまま並べ替えただけになっていた → ラベルの行と画像の行を2枚で共有する行（subgrid）にそろえ、画像の上端を一致させた。subgridが無い環境では宣言が無効になり、以前と同じ挙動に戻るだけで壊れない。E2Eも「2枚が横に並んでいること」だけでなく「画像の上端がそろっていること」を見るようにした
カードの幅を本文の折り返し幅に合わせて詰めたら、今度は「どこにも送られていません。」の最後の1文字だけが2行目に落ちた。1つ直すと別の場所に出るたぐいの崩れ → 行長を32rem→33remに広げ、この行の文字を0.92rem→0.9rem（カード内の本文と同じ大きさ）にそろえた。そのうえで text-wrap: pretty を本文に掛け、最終行に1〜2文字だけ残る折り返しを全体で減らした（残っているのは3文字以上のものだけ）
権利表示の警告を保存ボタンと同じカードに入れていたので、「メタデータを消して保存」が琥珀色の箱の内側にあるように見え、警告に対するボタンだと読めていた → 警告を独立したカードにして、保存ボタンのカードと分けた（間は30px）。警告を除去ボタンの直上に常時出すという要件は、隣り合うカードとして満たしている。ただし面積の逆転（390pxで警告359px対ボタン54px）は、文面が法務の調査結果そのもので削れないため今回も解消していない
保存ボタンを上げすぎて、検出内容を見ないまま保存できる順序になっていた。採点の「CTAが68%地点」を額面どおり受け取り、判定カードの直下へ動かした結果、検出内容（分類カード）と本体写真・サムネイルの見比べが保存ボタンより下に落ちた。このアプリは「何が入っていたかを確かめてから消す」ためのものなので、いちばん見せたい中身を飛ばして主要な行動に到達できる並びは、それ自体が不具合だった。深い位置にあったのが問題だったのではなく、上にあったのが説明文ばかりで中身が無かったのが問題だったと読み違えていた → 並びを「判定 → 検出内容 → 写真の見比べ → 付随情報 → 限界の要点 → 権利表示の警告 → 保存 → 詳細」に直した。保存ボタンは390pxで判定から2,527px下・ページ全長の68%地点に戻ったが、上にあるのは利用者が見たい中身そのものなので、この深さは意図どおり。法務由来の2条件（追記2 G-2 の限界の要点／追記3 K-3 の警告の直上表示）はどちらも保存ボタンより上のまま維持している。結果カードの直下の子要素の並びをそのままE2Eで固定し、説明の壁を保存ボタンの前に積み直せないようにした
本体写真とサムネイルの見比べで、画像の上端だけをそろえて済ませていた。実際には表札（ラベル）の行数が左右で違うせいで「8.4KB」が約25px下にずれ、2枚の画像の下端も約29pxずれていた。見比べるための機能なのに、上端以外に共通の基準線が無かった → 表札・大きさ・画像の3行を2枚で共有する行にそろえ、表札には2行ぶんの高さを最初から与えて行数を固定した（subgridが無い環境でもずれない）。画像は共通の 4:3 の枠に object-fit: contain で収め、上端と下端の両方を一致させた。E2Eは上端だけでなく、下端・表札の高さ・大きさの表示の位置も測るようにした（いずれも実測0px差）

Day 010公開中

いま、誰かが書き直している

世界中のウィキペディアで、いまこの瞬間に書き換えられている記事の「場所」が世界地図に立つ。いちばん書き換わっている国を名指しし、日本語版の編集は記事名まで読める

server-sent-events
wikipedia
world-map

アプリを開く

制作メモ

AIに任せた: 実装前にユーザーストーリーとUX5階層を書き、そこから設計を決めた（本人指示でこの工程をハーネスに恒久追加）／候補3案のデータ源が本当に生きているか（認証不要・CORS許可・応答200）を提案前に実測／「編集者の場所は原理的に出せない（IPが要る＝方針違反）」ことと「記事そのものの座標なら出せる」ことを実測で切り分け／編集の18%しか座標を持たないことを実測し、地図が生きる頻度（毎秒約1本）を見積もった／Natural Earthの国境を間引いて63KBに収める道具、正距円筒の投影、点と国の判定、問い合わせを絞る仕組み、ユニット49項目とE2E18項目の実装
自分でやった: 3候補から作るものを選ぶ判断／水面版を世界地図版へ作り直す発案と、その日のうちに公開まで進める判断／ウィキペディアのAPIへ継続的に問い合わせることを、範囲を絞ったうえで許容する判断／UI・UXを作るときは毎回ユーザーストーリーとUX5階層を先に書く、というルールの制定
失敗と修正: 「世界のウィキペディアは毎秒30件書き換わっている」と説明にも投稿文にも書いていた。実測30秒間の916件をそのまま割った数字だったが、中身はカテゴリ操作287件とログ227件を含んでいて、このアプリが「編集」として数えているものではなかった → 内訳を数え直した。編集と新規作成だけなら毎秒13.4件で、別の時間帯の再実測でも13.6〜14.1件で一致した
ピンの位置を画面の座標で持っていたので、ウィンドウの幅を変えると既に立っているピンが全部ずれた場所に残った。スマホ幅のスクリーンショットで、アフリカ沖の海の上にピンが並んで初めて気づいた → ピンは緯度経度だけを持ち、画面の座標は描くたびに計算するようにした。4都市に立てて3つの画面幅で位置が変わらないことをE2Eで固定した
経度360度・緯度142度を枠いっぱいに引き伸ばして描いていたので、アフリカと南米が縦長に潰れていた → 縦横の比を保った矩形を枠の中に置き、余りを余白にした。枠からはみ出す南極も切り取るようにした
地図に立つピンと「世界の編集数」が一桁違って見えた。座標を持つ記事は全体の2割弱しかないのに、その説明がどこにも無かった → 「場所を持たない記事の編集◯件は地図に出せません」を常に出すようにした。UX5階層の構造層を書いている段階で気づいた
点の薄れ方を (1-t)^2 で書いていたので、立った直後がいちばん速く薄れて、直近のピンほど目立たなくなっていた → 1-t^2 に変えて、最初はほとんど薄れず終わりぎわで消えるようにした。ユニットテストが先に捕まえた

Day 009公開中

秋田バスライブ

いま秋田県を走っているバスの実測GPS位置を、自前の3Dマップの上で走らせる。路線網は県内17事業者のGTFS-JPから作り、実測位置はGTFS-RTを20秒ごとに中継する

gtfs-realtime
canvas
3d

アプリを開く

制作メモ

AIに任せた: GTFS-RTのProtocol Buffersを外部ライブラリなしで読む中継API（Cloudflare Pages Functions）の実装／緯度経度→平面→カメラ回転→透視投影の自前3Dパイプラインと、20秒ごとの位置を補間して走らせる処理／17事業者のGTFS-JPから路線網を抽出するツールと、ユニットテスト・E2E・スクリーンショット撮影の整備
自分でやった: 外部APIとサーバー処理を解禁する判断と、実測位置が2事業者しかない現実を隠さずに見せる方針の決定
失敗と修正: 秋田市のフィードは数十秒ごとに作り直されているのに、中の車両の位置送信時刻が9時間41分前で止まったままだった。そのまま描くと動かないバスが夜通し『走行中』に見える → 中継APIで10分以上古い位置を除外し、除外した台数を画面に出すようにした
上の10分ルールを入れた数時間後、同じ秋田市のフィードが『座標はビット単位で12時間以上まったく同じまま、送信時刻だけを現在時刻に更新する』挙動に変わり、除外をすり抜けた。公開直後の本番で深夜に『1台が走行中です』と表示していた → 時刻の新しさだけを信用するのをやめ、同梱した時刻表の運行時間帯と突き合わせて、その事業者の運行時間外に届く車両は走行中に数えないようにした。除外の理由を2種類に分けて画面に出している
17事業者のうち12事業者は道なりの路線形状を公開しておらず、停留所を直線で結んだ角ばった線にしかならない → 実形状と近似を線の太さと破線で描き分け、17事業者中5事業者しか形状を公開していないことを画面に明記した

Day 008公開中

じはんきレーダー

近くの自動販売機を方角と距離のレーダーで示す。OpenStreetMap収録の全国データを同梱し、位置情報は端末の中だけで処理する

geolocation
canvas
web-audio

アプリを開く

制作メモ

AIに任せた: OpenStreetMapの自販機データ取得・日本クリップ・軽量化パイプラインの実装／レーダー描画・8方位と距離の計算・ソナー音合成・テストの実装
自分でやった: 近くの自販機を探すアプリという題材の発案と、収録データが実際の約1.3%しかない前提で進める判断
失敗と修正: Overpass APIが混雑していて、全国データの取得が最初は何度もタイムアウトした → メインとミラーを順に切り替えて再試行する取得スクリプトにして、日本全域の絞り込みクエリで取り切った
デモ動画の収録ツールがページをfile://で開くため、ESモジュールとfetchを使うこのアプリは録画中に動かなかった → 振り付けスクリプト内で小さなローカルHTTPサーバーを立て、そこから開き直して収録した

Day 007公開中

ひといきピアノ

クリック、タッチ、PCキーで演奏できる25鍵のWebピアノ。和音、サステイン、音量変更に対応し、音はWeb Audio APIで端末内合成する

music
web-audio
vanilla-js

アプリを開く

制作メモ

AIに任せた: Web Audio APIによる音声合成、25鍵のUI、和音・サステイン・音量・全停止の実装／PC・スマートフォン相当の画面で操作確認し、X投稿用のデモ動画と投稿文を作成
自分でやった: Webで弾けるピアノを今日のアプリに選び、動画とX投稿素材も作る判断
失敗と修正: 100日チャレンジ本体ではなく、別アカウントの単独リポジトリにPRを作ったため一覧へ反映されなかった → 本人の指摘を受けて正しい個人用リポジトリを確認し、Day 007として移植した

Day 006公開中

構造化データ、いま出るやつだけ

ページの種類と情報を入れると、貼れる形のJSON-LDが出る。ただし2026年8月時点でGoogleがサポートしているタイプだけ。廃止済みのFAQとHowToは生成せず、廃止された日と理由を出す

seo
json-ld
vanilla-js

所要時間1時間10分

アプリを開く

制作メモ

AIに任せた: Google検索セントラルで現行の対応タイプ一覧と、LocalBusiness・Article・BreadcrumbListの必須／推奨プロパティを確認／FAQとHowToのリッチリザルトが廃止された日付を一次情報で特定（FAQ=2026-05-07、HowTo=2023-09-13）／index.html・style.css・script.jsの実装（Codexサブエージェントに委任）／Playwrightで47項目の出力検証スクリプトを書いて実行／公開前にUXを実測（コントラスト比・タップ領域・支援技術への伝達）し、見つかった課題4件を修正してアクセシビリティ23項目で再検証
自分でやった: 4候補（帰省スマホ設定チェックリスト／定例会議の年間コスト計算機／睡眠負債の可視化／構造化データ生成）から作るものを選ぶ判断／公開まで進める判断。コミット・PR作成・デプロイはClaudeに任せ、mainへのマージだけは自分の手で行う運用を維持した
失敗と修正: HowToの廃止時期を「2023年8月の変更で縮小され、その後サポート対象から外れた」と曖昧なまま実装に渡してしまった。廃止日を主題にするアプリなのに、肝心の日付が無かった → 一次情報を当たり直し、2023年8月にモバイルでの表示が終わってデスクトップ限定になり、その1か月後の2023年9月13日にデスクトップからも消えた、と確定させた。ただし実装を委任した後で要件を直したため、返ってきたコードは古い記述のままだった（実装側は「要件から外した点はない」と報告してきたが、見ていた要件そのものが古い）。委任中に要件を書き換えたのが原因で、渡す前に凍結するべきだった
廃止を告げる見出しで「これは2026年5月7」「日に廃止されました」と日付の途中で改行し、このアプリの主題である日付が読めなくなっていた。デモ動画を撮って初めて気づいた → 見出しを1つの文字列で持つのをやめ、日付だけを nowrap のspanで包む形に変えた。文字サイズや画面幅が変わっても日付が割れない
公開前にUXを実測したら、このアプリの主張である「廃止」が打ち消し線と灰色だけで表現されていた。読み上げでは現行のタイプと区別がつかず、色覚特性のある人にも弱い。あわせてライトモードの小さい文字が4箇所でコントラスト比3.36〜3.68:1しかなく、WCAG AAの4.5:1に届いていなかった（ダークモードは全部合格していた） → 廃止の2ボタンに「廃止」の文字バッジを足して、線と色だけに頼るのをやめた。灰色は #788983 から #5F726C に濃くして、紙の上で4.66:1・カードの上で5.11:1にした。ついでにコピーボタンの高さを36pxから44pxにし、種類の5択を role=radiogroup にして矢印キーだけで選べるようにした。営業時間の平日一括入力は機能追加なので今回は入れていない

Day 005公開中

その写真、何色でできてる？

画像をドロップすると主要な6色を取り出して、カラーコードをタップでコピーできる。処理はすべてブラウザの中だけで、画像はどこにも送信されない

canvas
design-tool
vanilla-js

所要時間40分

アプリを開く

制作メモ

AIに任せた: メディアンカット法の選定と実装／サンプル画像3種を実行時にcanvasへ手続き描画するコード（画像ファイルを同梱しないための設計）／要件定義の下書きと実装
自分でやった: 4候補（帰省スマホ設定／会議コスト計算機／カラーパレット抽出／構造化データ生成）から作るものを選ぶ判断
失敗と修正: サンプル「夜の街」の初版は、細い窓のネオンが120pxへの縮小で壁の色と混ざり、パレットが紺系ばかりになった。ピンクもシアンも1色も出ない → ビル1棟の窓を同系色に寄せ、壁いっぱいの大型ビジョンと路面の反射を面で入れて、縮小後もピンク・シアン・アンバーが残る構図に描き直した
べた塗り3色の画像で、同じHEXのスウォッチが2枚並んだ。メディアンカットは画素数で箱を割るので、純色だけの箱と純色＋境界画素の箱が同じ平均色になることがある → 平均色が同一HEXになった箱は1つにまとめて画素数を合算した。まとめた分だけ色数は6より減るので、コピーのボタン表示も実際の色数に追従させた

Day 004公開中

奨学金、何歳まで返す？

奨学金の返還年数は自分で選べず、借りた総額で自動的に決まる。JASSOの算出表どおりに計算して、返し終わる年齢と毎月の返還額を出す

calculator
vanilla-js
no-dependencies

所要時間30分

アプリを開く

制作メモ

AIに任せた: JASSOの返還年数算出表と返還例の調査／第二種の計算式を公式返還例60件から逆算し、6モデルを比較して決定／要件定義と実装／公式返還例70件との突き合わせ検証
自分でやった: 3案（会議コスト計算機／奨学金返還シミュレータ／構造化データ生成）から作るものを選ぶ判断
失敗と修正: 最初の提案時、返還年数をユーザーが自由に選べる前提で画面を描き、利率も0.9%という古い値を使っていた。実際のJASSOは返還年数を貸与総額から自動決定し、利率も大幅に上がっていた → 公式の算出表を取得して実装し直した。第一種は公式返還例10件と完全一致することを確認。利率は変動するため断定表示をやめ、公式返還例と同じ0.5/1/2/3%を選択肢にした
第二種を単純な元利均等で計算すると、公式の返還例より最大1.2%低く出た → 据置期間の扱いが違う6つのモデルを公式60件に当てて比較し、誤差が最小（総額+0.03%以内）の「据置6か月分の利息を別途上乗せ」を採用した
ブラウザで確認したら、第一種を選んでも利率欄が消えなかった。DOMではhidden=trueなのに表示されていた → 自作の .field { display:flex } が、ブラウザ標準の [hidden]{display:none} に勝っていた。[hidden]{display:none !important} で打ち消した
公開前のファクトチェックで、第一種の貸与月額から50,000円（私立・自宅外）が抜けていることが分かった。私立大学で自宅外通学の学生が自分の額を選べない状態だった → JASSOの月額表を4区分すべて取得し直し、和集合の8段に修正。実際に選べない額が混じることはREADMEと画面に明記した
リーガル確認で、JASSO公式ツールとの誤認を防ぐ表示と、損害についての免責が無いことが分かった → ヘッダーに非公式である旨を常時表示し、末尾に免責を追加。JASSOのサイトポリシーでリンクは自由と明記されていることも確認した
JASSOのサイトポリシーに「許諾を受けていない無断転用は禁止」とあり、算出表16行を画面に再現している点が先方の掲示に反する可能性があった（著作権法上のリスクは低いと判断したものの） → 本人判断で表の全体再現をやめ、該当する1区分と実際の割り算だけを見せる形に変更。数字の羅列ではなく年数が決まる手順そのものが読めるようになり、結果的に主題は強まった
デモ動画を撮って気づいた。第一種から第二種へ切り替えると、月額が64,000円から90,000円へ勝手に飛んでいた。内部でスライダーのインデックスだけを共有していたのが原因 → 状態をインデックスではなく金額そのもので持ち、切り替え先に同じ額が無ければ最も近い額に寄せるようにした（64,000→60,000）

Day 003公開中

タップ花火

夜空をタップした場所に花火が打ち上がるおもちゃ。合成音つき・長押しで連発・放置でも自動で上がる

canvas
animation
vanilla-js

所要時間30分

アプリを開く

制作メモ

AIに任せた: 要件定義と実装
自分でやった: 作るもの・機能範囲の判断／1作目を不採用にする判断
失敗と修正: 1作目のスクショ整形が微妙 → 夜に花火へ作り直し

Day 002公開中

ドット絵メーカー

画像をドロップするとドット絵に変換してPNG保存できるツール

image
canvas
vanilla-js

所要時間15分

アプリを開く X投稿

制作メモ

AIに任せた: 要件定義と実装
自分でやった: 作るもの・機能範囲の判断

Day 001公開中

集中タイマー

時間をセットして開始・一時停止・リセットできる集中用カウントダウンタイマー

timer
vanilla-js
no-dependencies

所要時間10分

アプリを開く X投稿

制作メモ

AIに任せた: 要件整理と実装
自分でやった: 作るものと機能範囲の判断
失敗と修正: Cloudflareキャッシュ混入 → 公開前に除外

ABOUT

大学生。毎日1個Webアプリを作って公開しています。
アカウント登録なし・課金なし・個人を特定できるデータは扱わない。作れるものの幅はDayが進むほど解禁していきます。

GitHub README でルールと記録を見る →