100 DAYS / 100 APPS

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

23 / 100公開済み

X@haranishi_ikki GITHUBharanishi/hundred-days
公開アプリ23本
制作時間（記録分）22時間18分記録済み 12/23 日
制作日数19日

TAGS

つくったアプリ

新しい順

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 020・新しいタブで開く）
Day 019外部で公開

そのままコード

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

  • chrome-extension
  • qr-code
  • privacy
紹介ページを開く（Day 019・新しいタブで開く）
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投稿（Day 002・新しいタブで開く）
制作メモ
AIに任せた
要件定義と実装
自分でやった
作るもの・機能範囲の判断
Day 001公開中

集中タイマー

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

  • timer
  • vanilla-js
  • no-dependencies

所要時間10分

アプリを開くX投稿（Day 001・新しいタブで開く）
制作メモ
AIに任せた
要件整理と実装
自分でやった
作るものと機能範囲の判断
失敗と修正
Cloudflareキャッシュ混入 → 公開前に除外

ABOUT

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

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

実際に操作しているところを録画したデモです