「1日1スキルを、30日間、公開で作る」と宣言して始めたkurashi-skillが、2026-10-05にv1.0.0になった。最終回は、数字を並べて、ちゃんと動いているか自分で疑う回にする。
起: 宣言と、最初の数字
始めたのは2026-09-09。日本の暮らしに関わる公開データ(天気、祝日、郵便番号、法令、国会の議事録)を、AIエージェントから引けるスキルにして、毎日1本ずつ記事にする。ログインも課金もいらない、公式の公開データだけ。
折り返しのDay 15では、18スキル、37コミット、GitHubの星は2つだった。Day 22では24スキル、56コミット。地味に積んでいた。
承: 30日後の数字
2026-10-10に数え直した。
- スキル27本。補助スクリプト
lookup.pyを持つのが10本 - コミット66、タグはv0.1.0 / v0.2.0 / v0.3.0 / v1.0.0
- 単体テスト67件(10スキル)、固定データのスモークテスト18件
- GitHubの星4、フォーク2
27本を分けると、天気・防災・環境が10本(気象庁の予報・アメダス・雨雲、防災情報、火山、避難所、大気、暑さ指数など)、暦・計算・手続きが8本(祝日、和暦、六曜、ふるさと納税、源泉徴収、郵便料金、ごみ収集日、公用文の校閲)、場所・図書・法令・統計が9本(郵便番号、住所、国土地理院、図書館と国会図書館、青空文庫、国会議事録、e-Gov法令、e-Stat)になる。
派手ではない。でも、2週間前にはなかったものが、毎日1つ増えていた。作らなかったスキルもある。鉄道の odpt-transit は、無料キーの登録に氏名・住所・電話番号が必要で、承認まで最大2営業日かかる(2026-09-30確認)ので保留した。河川水位の river-level は、公式のデータ提供が有償だったので不採用にした(2026-09-20)。
転: 監査したら、穴だらけだった
v1.0.0の前に、自分のリポジトリを監査した。2026-10-03に出てきた話が一番痛かった。スキルごとの単体テストを書いていたのに、CIはそれを1本も走らせていなかった。緑のバッジは、スモークテストとURL検査の緑でしかなかった。単体テストの配線を足して、固定データのテストが無かった6スキルにテストを足した。
v1.0.0の点検日(10/5)にも、2回やらかした。CHANGELOGに書いたURL検査のOK件数が、実際は112件なのに114件になっていた(出力の集計行を数えていた)。リリースを切った直後に気づいて、タグとReleaseを消して、直して、打ち直した。もうひとつ、Day 25の記事の下書きとSKILL.mdに書いていた、「北海道 青森」の検索件数「24件」。再実測したら3,867件で、24件は再現できなかった。記事は発行前に、SKILL.mdはその日のうちに直した。
CIの緑も、自分の記録も、古い数字も、見た目がきれいなだけでは信用できない。30日の最後に残った教訓はそれだった。
結: 3つのことが言える
- 毎日出すと、「出すこと」が目的になる。 29日目まで、CIが何を走らせているかを確かめなかった。点検の日を、予定に入れておく。
-
「データなし」は、だいたい200で返ってくる。 空配列、404、
-----、空の{}。30日で形を変えて何度も出た。ステータスコードではなく、中身を見る。 - 数字には日付を付けて、自分の数字も疑う。 114件も24件も、書いたのは自分だ。日付があったから、再実測して直せた。
これから
30日は終わるけれど、リポジトリはここで止めない。次の候補はROADMAPのバックログにある。国土交通省の不動産情報ライブラリ(reinfolib-prices、APIキーの審査待ち)、ハザード情報(hazard-map、タイル配信の利用規約を確認してから)、data.go.jpの横断検索(dataportal-search)。保留している odpt-transit は、登録の条件がクリアできたら再開する。足りないものも分かっている。テストが無い koyobun-check にテストを足すこと。そして、URL検査の待ち時間が20秒だと、遅いだけのAPI(Day 29のそらまめくん)を壊れ扱いにしてしまうこと。採用するかどうかは、これまでと同じやり方で決める。実際に叩いて、動いたものだけ入れる。
読んでくれた人、スターをくれた人、PRを送ってくれた人に感謝を。リポジトリはここ → https://github.com/tahodev/kurashi-skill
数字はすべて2026-10-10の実測で、日が変われば増える。