CookScale開発記録

11/7(土) 20:00〜つくったちゃんのライブ配信

YouTubeで見る

CookScale開発記録 | Tsukutta

4人分のレシピを2人分で作りたい。ただそれだけなのに、材料ひとつひとつを割り算して、しかも「大さじ1.5」のような計量しにくい数字とにらめっこするのが、料理中は想像以上に面倒でした。

作ったのは、レシピの材料と分量をテキストで貼り付けるだけで、指定した人数分に一括換算してくれるブラウザ完結のWebツール「料理分量らくらく計算（CookScale）」です。

https://zero-dev.jp/recipe-quantity-calculator/

外部通信は一切なく、計算はすべてブラウザの中で完結します。この記事では、機能の紹介よりも、開発の中で実際に詰まったことと、AI開発の品質工程で見つかった問題を中心に書きます。

設計で最初に決めたこと

ロジックは3つのモジュールに分ける

中核の処理は、最初から単一責任で3つに分けました。

parser.ts：テキストを解析し、数量と単位を取り出す
calculator.ts：人数の倍率で分量を計算する
formatter.ts：小数を処理し、大さじ・小さじの組み合わせなど「計量しやすい形」に整形する

分けておいたおかげで、後述するレビュー指摘の修正が「どのモジュールの話か」ですぐ切り分けられました。AIに実装を任せる開発では、この切り分けのしやすさがそのまま修正速度になります。

「換算しない」という判断も仕様

このツールは、カップをグラムに直すような単位そのものの変換はしません。各単位のまま、人数倍率だけを計算します。守備範囲を広げれば便利にはなりますが、食材ごとに密度が違う換算まで正確にやるのは別のツールです。

もうひとつ、「少々」「適量」は計算せず、そのまま保持します。範囲表記の「100〜150g」も、誤って換算するくらいなら元の表記を残して注意表示を出す。料理の分量計算は、間違った数字を自信満々に表示されるのが一番困るので、「計算しない判断」を仕様として明示しました。

実装で詰まったのは「表記の揺れ」だった

計算式自体は単純です。難しかったのは、日本語のレシピ表記が想像以上に揺れていることでした。

分数表記：「1/2」「1と1/2」「½」が混在する
全角表記：全角数字、全角スペース、「ｇ」「ｃｃ」のような全角単位
1行に複数材料：「鶏肉300g 醤油大さじ2」のように、スペースや読点で区切って書かれる
助数詞：「2個」「3本」「1枚」は分数表示せず、数値＋助数詞で丸めるのが自然

これらは深層コードレビューでも指摘され（分数パース、全角正規化）、テストケースを追加しながら潰していきました。地味ですが、実在のレシピを扱うツールでは、ここが本体です。

計量スプーンの「繰り上がり」

もうひとつ、レビューで拾ったのが丸め処理の不整合です。丸めた結果、小さじの端数が3以上になると「小さじ3」という表示が残ってしまう。これを「大さじ1」に繰り上げる処理を追加しました。

大さじ・小さじの組み合わせ表示（例：大さじ1＋小さじ1.5）も含め、「計算結果が合っているか」ではなく「そのまま計量できる形か」がこのツールの品質基準です。数字の正しさと使いやすさは、別の問題でした。

AI開発の品質工程で見つかったこと

開発はAIに実装を任せ、人間が手順と検証で管理する形で進めました。その過程で、監査とレビューを何段階もかけています。

品質監査：localStorage 操作を try-catch で保護する（プライベートブラウズ環境でのクラッシュ防止）、人数の空欄・不正入力時のフォールバック強化など、通常の動作確認では出てこない問題が検出されました
深層コードレビュー：分数・全角・繰り上がりの指摘に加え、お気に入り一覧のコンポーネント分離など構造面の指摘もあり、全件修正してテストで固定しました
公開品質チェック：初回は「条件付き」でした。タイトルが初期値の temp-app のまま、画面の必須表記（著作権・ライセンス・免責）の不足、CSPメタタグ未設定など、「動くかどうか」ではなく「公開物として整っているか」の指摘です。修正後の再確認で合格になりました

テストは初期の10件から、エッジケースの追加を繰り返して拡充しました。レビューで見つかった問題は、直して終わりではなく、テストケースにして再発を防ぐ、という運用です。

公開後に見つかった問題のほうが実務的だった

Zero Dev に掲載した後、実機確認でレイアウトの表示崩れ（スマホ・PCで縦並びにならない）が見つかり、コンテナの指定を修正しました。全角単位やスペース混じりの入力で材料分割がうまくいかないケースも、公開後の確認で改善しています。

いちばん考えさせられたのは、計算の不具合ではなく**「説明と実装の不一致」**でした。「入力データは localStorage に保存される」という趣旨の記述が残っていたのですが、実際に保存されるのはお気に入りに登録したレシピだけで、入力中のレシピや人数は保存されません。README、記事、詳細ページの計4か所を訂正しました。公開品質チェックで「説明と動作の一致」を重大項目として見ている理由が、身をもって分かりました。

また、配布用の起動バッチが file:// でページを開くため白画面になる問題もあり、ローカルサーバー経由で開く方式に変更しました。逆に、画面検査ツールが「要素の重なり」として大量に警告した件は、検証の結果、sr-only ラベル（1px要素）などによる検査側の誤検知と切り分け、検査ツールの判定方法を直しました。警告を全部「実装のせい」にしない切り分けも、検証工程の一部です。

やらなかったこと

配布形態として、BOOTH で Windows 向け ZIP を配る案も作りましたが、最終的にはやめました。料理中の利用はキッチンでスマートフォンからが中心で、PC版 ZIP は主たる使い方に合わないと判断し、無料の Web 版に導線を一本化しています。「作ったから配る」ではなく、使われ方に合わせて配布形態を決める、という当たり前の結論です。

まとめ

計算ロジックより、日本語の表記の揺れへの対応が本体だった
「計算しない判断」（少々・適量の保持、範囲表記の維持、単位変換をしない）も仕様として設計した
AI開発では、監査・深層レビュー・公開品質チェックの多段化と、指摘をテストで固定する運用が品質を支えた
公開後の問題は、機能よりも「説明と実装の一致」のような地味な部分から出た

ツールはこちらで公開しています。ブラウザだけで動くので、よければ触ってみてください。