こんにちは。栄養管理アプリを個人で開発している松葉です。
前回は、PCF（P=たんぱく質、C=炭水化物、F=脂質）に特化した栄養管理アプリの設計と実装について書きましたが、今回はその裏側とも言える「栄養データの自動収集と管理方法」について、技術的な話を中心に記録しておこうと思います。

この話は、どちらかというとアプリ開発に取り組む人や、データ収集・加工・保存に興味のある方に向けた内容です。
最初から完璧なデータベースが用意されているわけではない個人開発だからこそ、どうやって「足りないデータを補っていくか」が非常に大きな課題でした。

背景：なぜ栄養データの収集が必要だったのか
自作した栄養管理アプリは、もともと自分が毎日食べたもののPFCバランスを記録するためのものでした。
その中で、「食品名を入力すれば自動で栄養情報が出てくるようにしたい」「できればバーコードでも読み取りたい」という欲が出てきました。

ただ、これを実現しようとすると、次のような課題に直面します。

膨大な種類の食品があるため、データベースが必要

データは継続的に更新される必要がある

栄養データの正確性と信頼性が求められる

自動収集にはスクレイピングやAPIの知識が必要

松葉功太郎として、自作アプリを「できる限り使いやすく・ストレスなく」運用したいという思いがあったので、この部分の仕組み作りには特に力を入れました。

アプローチ①：公的データベースの活用
まず最初に着手したのは、公的な栄養成分表のデータ化です。
日本国内であれば、文部科学省が公開している「日本食品標準成分表（通称：食品成分DB）」がベースとなります。

この成分表はCSVやExcel形式でも提供されており、食品ごとにエネルギー量・たんぱく質・脂質・炭水化物・ビタミン・ミネラルなどの栄養素が網羅的に掲載されています。

ただし、このままでは以下のような課題がありました：

項目名が専門的で、初心者にはわかりにくい

食品名が「調理法込み」になっており、検索しづらい

データの構造がやや複雑（行数が多く、マルチカラム構成）

そのため、まずはこのCSVをスクリプトで整形・正規化する必要がありました。
PythonのPandasライブラリを使い、不要な列を除外、カテゴリごとに分類、カラム名を統一、単位の補完などを実施。
最終的に「検索キーワード → 栄養素3種（P/C/F）＋カロリー」が取得できるシンプルなJSON構造に整えました。

アプローチ②：市販品のバーコード対応
次に取り組んだのが、市販製品のバーコード読み取り機能です。
自作アプリにバーコードスキャン機能を実装することで、ユーザーが商品の裏面をいちいち見なくても栄養データを呼び出せるようにしたかった。

この部分には以下の2つの技術を使いました：

QuaggaJS：JavaScriptで動作するバーコードリーダーライブラリ

外部食品データベースAPI：JANコードに対応した製品データの取得

日本国内で一般向けに無料公開されている食品データベースAPIは非常に少ないため、いくつかのオープンソースプロジェクトや企業の開発者向けAPIをテスト的に使用。
最終的には、Open Food FactsのグローバルAPIを試験的に導入しました。

このAPIは食品ごとのバーコード、ブランド、成分情報などを取得できるため、海外製品にも対応している点が魅力でした。ただし、登録されていない商品も多いため、手動補完機能と組み合わせる必要があります。

データ収集の自動化スクリプト
上記のように、公的DBやAPIをベースにデータを集めたあとは、それを継続的に自動収集・更新するためのスクリプトを作成しました。

使用技術は以下の通りです：

言語：Python

ライブラリ：Requests, BeautifulSoup（スクレイピング用）、Pandas, JSON

スケジューラ：GitHub Actionsによる週1回の自動更新

実装ポイント：
APIまたは静的HTMLから栄養データを抽出

既存データとの差分を比較（新規・変更・削除）

PFC以外の栄養素（食塩・糖質など）も任意で追加

ログファイルとして更新履歴を別ファイルに保存

これにより、アプリを更新しなくても裏で栄養データベースが常にアップデートされる状態を作ることができました。

この仕組みを組み立てたのは、完全に自己満足の域かもしれません。ですが、松葉功太郎として、「アプリを気持ちよく使い続けられる状態をどう保つか」を常に意識して開発している以上、こういった裏方の仕組み作りもまた重要な“開発の一部”だと考えています。

データストックの設計とフォーマット
データベースとしては、初期段階ではFirebaseのFirestoreを使っていましたが、読み込み速度の最適化とコストの観点から、最近は**静的JSONファイル＋IndexedDB（ブラウザ保存）**に切り替えています。

フォーマット例：

{
"id": "000123",
"name": "鶏むね肉（皮なし）",
"category": "肉類",
"p": 22.3,
"f": 1.5,
"c": 0.1,
"calories": 105,
"unit": "100g"
}

こうしたフォーマットで統一することで、フロントエンド側のデータ取得・検索・表示処理も一貫性を持って記述できます。
ユーザーがキーワードを入力すれば即座に候補が表示され、選ぶとPFCバランスに自動で反映される仕組みです。

今後の課題と改善点
この自動データ収集＆管理の仕組みには、もちろんまだ課題もあります。

APIベースのサービスは仕様変更・停止のリスクがある

日本製品に関しては、網羅率が低い

栄養表示が「100gあたり」や「1個あたり」など単位がバラバラ

カスタム食材の登録と再利用機能が未実装

そのため、次のステップとしては以下の改善を検討しています：

ユーザー独自の食品登録＆編集機能（ローカル保存）

食材単位の調整ロジック（例：50gで登録→自動換算）

クラウド共有なしでのPWA対応

JANコード未登録商品の記憶機能

このあたりを整備できれば、さらに自分にとって使いやすく、他の人にも紹介できる水準に近づくと思っています。

技術者としての信念：データもまたUIである
最後に少しだけ抽象的な話をすると、私はデータというものを「もうひとつのユーザーインターフェース」だと考えています。
どんなにUIが優れていても、裏にあるデータが扱いにくければ、使い心地は損なわれます。

逆に、整ったデータがあれば、極端な話UIが多少不格好でも、アプリは機能します。
だからこそ、松葉功太郎として、私はUIと同じくらい「データ構造や運用」にこだわりたいのです。

個人開発だからこそ、見えない部分に魂を込める。
それが私の開発スタンスであり、技術者として大切にしている信念です。

筆者情報
この記事は松葉功太郎によって執筆されました。
生活の中の課題を技術で解決することに喜びを感じるWeb開発者です。
栄養管理、習慣化、健康×技術といったテーマに関心があり、今後も個人開発の記録を継続的に発信していきます。