Notionでレシピ管理と献立を回す｜ChatGPTとCodexでブラウザ保存を作った話

料理サイトやSNSで気になるレシピを見つけても、保存先がばらばらになり、献立を考えるときには結局見返さない。私はこの状態を何とかしたくて、ChatGPTと相談しながらNotionの構成を考え、Codexにブラウザから保存する仕組みを作ってもらいました。

完成したのは、URLを集めるだけのレシピ帳ではありません。レシピ、家にあるもの、実際に作った履歴を分けて持ち、曜日や所要時間で候補を減らし、作った記録を次の献立へ返す仕組みです。ここまで形にするまでには、データベースの項目を考え、役割を分け、日々の使い方を決め、CodexとNotionの接続権限を確認する作業が必要でした。この記事では、その過程を省かずにまとめます。

掲載している画面は、実際にChatGPTやCodexへ相談していたときに残していたものです。これから同じような仕組みを作る人が、自分のNotionで再現できるように、データベースの項目、リレーションとロールアップの考え方、日々の運用、Codexへ頼む内容まで順番に説明します。

この記事で分かること

• レシピを保存しても献立が楽にならなかった理由
• 在庫DB レシピDB 作った記録DBを分けた考え方
• 曜日 所要時間 作った回数 最後に作った日を献立へ使う方法
• ブラウザのURLをNotionへ入れるローカル画面とChrome拡張の役割
• 同じ仕組みを小さく作り始める具体的な手順

レシピを保存しても献立は楽にならなかった

私は毎日料理をします。料理サイトやSNSを見ていると、作ってみたいレシピは次々に見つかります。そのたびにブラウザのタブを残したり、ブックマークへ入れたり、画面をスクリーンショットで保存したりしていました。保存した瞬間は安心しますが、数日たつと、どこへ入れたか分からなくなります。

献立を考える時間になると、保存したレシピを一つずつ探すのが面倒です。結局、頭に残っている料理や、いつも作っている料理を選びます。レシピの数は増えているのに、料理を決める負担はあまり減りませんでした。

ここで気付いたのは、私に足りなかったのはレシピの数ではなく、選ぶための情報だということです。平日に短時間で作れるか、魚を食べたい日に候補になるか、最近作っていないか、家にある材料で作れそうか。献立を決めるときに知りたいのは、こうした条件でした。URLだけをためても、この判断には使えません。

そこで目標を、レシピをたくさん保存することから、今日作る料理を決めやすくすることへ変えました。この変更が、その後のデータベース設計やCodexへ依頼する内容の基準になりました。

最初に決めたのは使う場面

いきなりNotionの項目を増やすと、きれいな一覧は作れても使わなくなる可能性があります。先に、いつ開き、何を見て、何をするのかを整理しました。私が必要としていた場面は、レシピを見つけたとき、献立を考えるとき、買い物をするとき、料理を作ったあとです。

使う場面	見たい情報	その場で行うこと
レシピ発見時	料理名 URL サイト名 所要時間	あとで探せる形で保存する
献立を決める時	曜日 カテゴリー 所要時間 在庫 履歴	候補を絞って一つ選ぶ
買い物時	切らしている物 買う店	店別の一覧を見て購入する
料理の後	作った日 感想 注意点	作った記録を一件残す

この整理をしておくと、必要な項目と不要な項目を分けやすくなります。たとえば、料理を探すときに所要時間は役立ちますが、保存した時刻を秒単位で持つ必要はありません。作った回数は役立ちますが、毎回レシピ一覧へ手入力すると続きません。使う場面から逆算することで、何を自動化し、何を人が確認するかも決めやすくなりました。

ChatGPTとCodexとNotionの役割を分けた

今回の作業では、ChatGPT、Codex、Notionを同じものとして扱いませんでした。それぞれが得意な部分を分けています。ChatGPTでは、困っていることを言葉にし、必要な項目や運用を相談しました。Notionは、レシピや在庫、履歴を保存して関連付ける場所です。Codexには、ブラウザからNotionへ入れる手間を減らすためのコードを書いてもらいました。

道具	今回任せた役割	実際に行ったこと
ChatGPT	考えの整理と設計相談	困りごとの言語化 項目の検討 画面を見ながら修正方針を相談
Notion	情報の保存と関連付け	3つのDB リレーション ロールアップ 曜日別や店別のビュー
Codex	実装と修正	URL入力用のローカル画面 Chrome拡張 Notionとの接続確認

この分け方にした理由は、相談と実装を混ぜないためです。ChatGPTとの会話では、まだ曖昧な状態でも、何が面倒なのかを話しながら整理できます。一方、実際に動く画面や拡張機能を作る段階では、ファイルを作り、コードを直し、動作を確認する作業が必要です。そこをCodexに任せました。

Codex側には専用の作業フォルダとして notion-recipe-project を作りました。レシピ管理に関するファイルを一つの場所にまとめておくと、あとで修正を頼むときにも対象を伝えやすくなります。

この画面の下には 233項目をアップロード中 と表示されています。ただし、これはレシピを233件登録したという意味ではありません。iCloudへ送られていたプロジェクトフォルダ内の項目数です。画面に数字があると成果の件数に見えますが、記事では意味を取り違えないように区別しました。

3つのデータベースに分けた理由

最初はレシピ一覧が一つあればよいと思っていました。しかし、実際の料理では、レシピそのもの、家にある材料、いつ作ったかという履歴は別々に変化します。これを一つの表へ詰め込むと、項目が増え、更新の意味が曖昧になります。

たとえば 最後に作った日 はレシピ自体の特徴ではありません。料理を作ったという出来事から生まれる情報です。在庫も同じで、鶏肉を使うレシピが変わらなくても、家に鶏肉があるかどうかは日々変わります。そこで情報の性質に合わせて、在庫DB、レシピDB、作った記録DBへ分けました。

データベース	保存する情報	料理の中での役割
在庫DB	食材や日用品 在庫チェック 買う店	何を持っているかと何を買うかを確認する
レシピDB	料理名 URL 分類 所要時間 曜日 材料	今日作る候補を探して選ぶ
作った記録DB	作った日 メモ レシピとの関連	履歴を残して回数と最終日を集計する

3つに分けても、ばらばらに置くわけではありません。Notionのリレーションでつなぎます。レシピから必要な材料を見られるようにし、作った記録から対象のレシピへ戻れるようにします。分けることで入力先は明確になり、つなぐことで献立を考えるときに必要な情報を一緒に見られます。

在庫DBは正確な棚卸し表にしなかった

在庫DBを作ると、冷蔵庫の中身を毎日すべて数えたくなります。しかし、その運用は私には重すぎます。記録が面倒になれば、買い物の前に開かなくなります。そこで、在庫数を厳密に管理するのではなく、切らしている物を買い物リストへ出すために使いました。

基本の動きは単純です。食材や日用品を使い切ったらチェックを外し、買ったらチェックを戻します。チェックが外れている物だけが買い物リストに出るようにします。毎日全部を確認する必要はなく、減ったときと買ったときだけ触ります。

在庫DBに用意する項目

同じ仕組みを再現するなら、最初は次の項目で十分です。名称は自分が分かりやすいものに変えて構いません。

項目	Notionの種類の例	用途
品名	タイトル	食材や日用品の名前を一つずつ登録する
在庫あり	チェックボックス	使い切ったら外し 買ったら戻す
買う店	セレクト	ゲンキー ビッグベリー エルパなどを分ける
関連レシピ	リレーション	その材料を使うレシピとつなぐ
メモ	テキスト	容量やメーカーなど必要な情報だけ残す

店ごとの買い物ページを作る

買い物ページは一つにまとめず、普段行く店ごとに分けました。ゲンキーのページには 買う店がゲンキー かつ 在庫ありがオフ の物だけを表示します。ビッグベリーとエルパも同じです。Notionでは、同じ在庫DBのリンクドビューを各ページへ置き、店名とチェック状態でフィルターを設定すれば作れます。

1. 買い物用のページを店ごとに作る
2. 在庫DBのリンクドビューをページへ追加する
3. 買う店がその店と一致する条件を設定する
4. 在庫ありがオフになっている条件を追加する
5. 買った物はチェックを戻して一覧から消す

在庫DBを分けたことで、材料名の表記もそろえやすくなりました。レシピごとに 鶏もも肉 鶏もも 鶏肉 と別々に書くと検索しにくくなります。在庫DBの同じ項目へつなげれば、どのレシピで使う材料なのかをまとめて見られます。

レシピDBを保存箱ではなく選ぶ場所にした

レシピDBは、この仕組みの中心です。ただし、情報を増やせば便利になるわけではありません。献立を選ぶときに使う項目を優先しました。実際に持たせた項目を、これから再現するときのNotionの種類と一緒に整理すると次のようになります。

項目	種類の例	持たせた理由
料理名	タイトル	一覧で料理を識別する
URL	URL	元のレシピページへ戻る
サイト名	セレクト	クラシル DELISH KITCHEN Cookpadなどを区別する
カテゴリー	セレクトまたは複数選択	主菜 副菜 スープ 丼 麺などから探す
所要時間	数値	15分以内など時間で絞る
画像URL	URL	一覧で料理を見分けやすくする
本文取得済み	チェックボックス	どこまで情報を取得できたか確認する
保存日	日付	いつ追加したレシピか分かるようにする
メモ	テキスト	作るときの注意や食べた感想を残す
曜日	複数選択	平日の候補を先に絞る
在庫	在庫DBとのリレーション	使う材料とつなげる
作った記録	作った記録DBとのリレーション	料理の履歴とつなげる
履歴の最後に作った日	ロールアップ	記録DBの日付から最新日を表示する
作った回数	ロールアップ	記録DBに何件あるかを数える
最後に作った日	日付	必要に応じて手動の日付も補助的に持たせる

サイト名を分けたのは、どこで見つけたレシピかを知るためだけではありません。特定のサイトだけ情報がうまく取れないときに、原因を切り分けやすくなります。本文取得済みのチェックも同じで、自動登録が途中までできたのか、人が確認する必要があるのかを見分けるために置きました。

カテゴリーは、きれいに分類するためではなく、献立の入口として使います。今日は主菜が決まっていて副菜だけ探したい、時間がないので15分以内に絞りたい、といった場面で役立ちます。保存する項目を決めるときは、あとでどんな条件で探すかを先に考えると無駄が減ります。

作った記録DBを別にした理由

作った回数や最後に作った日は、レシピDBへ直接入力する方法もあります。しかし、料理を作るたびに回数を一つ増やし、日付を書き換える運用は間違えやすく、過去の履歴も残りません。そこで 作った という出来事を一件ずつ残すDBを別にしました。

項目	種類の例	用途
記録名	タイトル	料理名と日付など分かりやすい名前を付ける
作った日	日付	実際に料理した日を残す
レシピ	レシピDBとのリレーション	どの料理を作った記録かをつなぐ
メモ	テキスト	家族の反応 次回の調整 作り方の注意を残す

リレーションとロールアップを設定する

Notionで再現するときは、作った記録DBの レシピ をレシピDBへつなぎます。次にレシピDB側へロールアップを二つ追加します。日付の最新値を表示する項目が 履歴の最後に作った日、関連する記録の件数を数える項目が 作った回数 です。

1. 作った記録DBへレシピDBとのリレーションを追加する
2. 作った記録を一件作り 対象のレシピと日付を入れる
3. レシピDBへロールアップを追加し 作った記録の日付の最新値を表示する
4. もう一つロールアップを追加し 関連する記録の件数を数える
5. レシピ一覧で最後に作った日と作った回数が更新されるか確認する

この形なら、一回料理するたびに記録を一件足すだけです。いつ作ったかという履歴は残り、レシピ一覧では回数と最新日だけをすぐ確認できます。記録と集計を分けたことで、あとから家族の反応や改善点を振り返ることもできます。

曜日は献立の正解ではなく入口にした

献立がしんどい理由の一つは、候補が少ないことではなく、選択肢が広すぎることです。レシピDBへ多く保存するほど、この問題は大きくなります。そこで、各レシピへ曜日の目安を付けました。

曜日は、その日に必ず作るという予定表ではありません。生活の負担感に合わせて、最初に見る範囲を狭めるためのタグです。今の分け方と、その理由は次のとおりです。

曜日	料理の目安	そう決めた理由
月曜日	時短 簡単 15分前後	週の始まりは調理の負担を軽くしたい
火曜日	魚 缶詰 少し軽めの主菜	週の前半に魚を選ぶ入口を作る
水曜日	肉を中心にした主菜	週の中日にしっかりした主菜を選ぶ
木曜日	丼 麺 カレー パスタなど一皿もの	疲れが出やすい日に工程と洗い物を減らす
金曜日	副菜 スープ 冷蔵庫整理	週末前に残っている物を使いやすくする

木曜日なら一皿ものから見る、と決められるだけで、毎回すべてのレシピを見ずに済みます。曜日の分類は栄養だけでなく、その日にどれだけ手間をかけられるかを反映しています。私にとっては、今日は何を作ろう とゼロから考えるより、今日の負担の中で何を選ぶか と考える方が現実的でした。

保存したレシピを埋もれさせないビュー

レシピは登録しただけでは使われません。数が増えると、目立つ料理やいつもの料理ばかりを選び、前に保存したものが下へ埋もれます。そこで、見る目的ごとにNotionのビューを分けました。

ビュー	設定の例	使う場面
曜日別	曜日に月曜や木曜などを含む	その日の候補を先に減らす
時短	所要時間が15分以内	時間をかけられない日に探す
最近作っていない	作った回数を少ない順 最終日を古い順	保存したまま忘れていた料理を出す
カテゴリー別	主菜 副菜 スープなどで絞る	不足している一品だけ探す

最近作っていないビューでは、作った回数を昇順にし、その次に履歴の最後に作った日を古い順へ並べます。一度も作っていない料理は日付が空欄になるため、Notionの並び方を見ながら上に出るよう調整します。狙いは変わった料理を無理に作ることではなく、保存した候補を循環させることです。

ブラウザから保存する手間をCodexで減らした

DBの構成を整えても、レシピを見つけるたびにNotionを開き、料理名やURLを手入力する必要があれば続きません。保存する入口を簡単にするため、Codexに二つの仕組みを作ってもらいました。

• レシピのURLを貼るとNotionへ追加する 自分のパソコンで動くローカル画面
• ブラウザで開いているレシピをワンクリックで保存するChrome拡張

ローカル画面は、ブラウザで見つけたURLを貼って登録するための入口です。Chrome拡張は、いま見ているページから保存操作を始めるための入口です。どちらも保存先は同じレシピDBなので、あとからNotion側でカテゴリー、所要時間、曜日を確認できます。

保存から記録までの流れ

1. 料理サイトやSNSから開いたレシピページで気になる料理を見つける
2. URLをローカル画面へ貼るか Chrome拡張から保存する
3. NotionのレシピDBを開き 料理名 URL サイト名が入っているか確認する
4. カテゴリー 所要時間 曜日 材料を整える
5. 料理を作ったら作った記録DBへ日付とレシピを一件追加する

自動取得した情報をそのまま信用するのではなく、最後に人が確認する形にしました。サイトによってページの作りが違い、料理名や時間の取り方が同じとは限りません。入力の面倒は減らしつつ、献立を選ぶために重要なカテゴリーや曜日は自分で確かめます。

Codexへ頼むときの伝え方

同じものを作りたい場合、いきなり 料理管理アプリを作って と頼むより、保存先、入力、最低限ほしい項目、確認方法を具体的に伝えた方が進みやすくなります。たとえば、次のような依頼から始められます。

NotionにレシピDBがあります。ブラウザで見つけたレシピのURLを貼ると、料理名、URL、サイト名、保存日をレシピDBへ追加する、自分のパソコン内で動く簡単な入力画面を作りたいです。最初はURLの登録を確実に行い、取得できない項目は空欄のままにしてください。設定情報はコードへ直接書かず、別の設定ファイルで管理してください。動作確認の手順も初心者向けに説明してください。

入力画面が動いてから、Chrome拡張、カテゴリー候補、画像URLなどを追加する方が、どこで問題が起きたか分かりやすくなります。最初からすべてを自動化するより、URLが一件確実にNotionへ入るところまで小さく作る方が修正しやすいです。これは、今回の作業を振り返って、これから再現する人にすすめたい進め方です。

毎日の運用は保存 選択 買い物 記録の4段階

仕組みを作ったあとに大切なのは、どのタイミングで何を更新するかを決めることです。私の運用では、保存、選択、買い物、記録の四つに分けると迷いにくくなりました。

保存するとき

気になるレシピを見つけたら、その場でURLを入れます。保存時点で全部の項目を完璧に埋めようとすると止まりやすいため、まず入口を作ります。料理名とURLが確認できたら、必要に応じてカテゴリー、所要時間、曜日を整えます。

献立を選ぶとき

最初に曜日のビューを開きます。時間がなければ時短ビュー、同じ料理が続いていれば最近作っていないビューも見ます。候補を数件に減らしてから在庫を確認します。すべてのレシピから探し始めないことがポイントです。

買い物をするとき

在庫DBのチェックが外れている物を店別のページで見ます。ゲンキーへ行くならゲンキーの一覧だけを開きます。買った物はチェックを戻し、一覧から消します。在庫数を合わせるのではなく、買い忘れを減らす程度の軽い運用にしています。

料理を作ったあと

作った記録DBへ一件追加します。日付とレシピの関連だけでも、回数と最後に作った日は更新されます。余裕があれば、家族の反応、味の調整、次に減らしたい工程などをメモします。この一件が次の献立を選ぶ情報になります。

たとえば木曜日なら、一皿もののビューから丼や麺を探します。候補が決まったら在庫との関連を見て、足りない材料を店別の買い物ページで確認します。作ったあとは記録を一件追加します。ここまでつながることで、保存したレシピが実際の食卓へ回り始めます。

Notionとの接続はページの権限まで確認した

CodexからNotionを扱うには接続設定が必要です。ただし、Notionを接続先へ追加しただけで、ワークスペース内のすべてのページが自動的に見えるわけではありません。後日、別のページをCodexから扱おうとしたときに、この点を確認しました。

Notionにはレシピ以外のページもあります。パスワードなどの重要な情報があるため、Codexへ何でも見せたいわけではありませんでした。接続名 レシピ自動化 のページアクセスを確認し、必要なページだけが選ばれているかを見ました。

この画面では レシピ と 在庫 が選ばれています。別のページをCodexから使いたい場合は、そのページも接続先へ追加する必要があります。逆に、触れてほしくないページは選ばないようにします。ページが見つからないときは、接続が切れていると決めつける前に、ページアクセスの範囲を確認した方がよいと分かりました。

権限を確認するときの手順

1. Codex側の設定でNotionが接続先に表示されているか確認する
2. Notion側で利用しているコネクトを開く
3. ページアクセスを管理する画面を開く
4. レシピDBと在庫DBを含む必要なページだけを選ぶ
5. Codexへ対象ページ名を伝え 検索または読み取りを試す

ここは便利さと安心の両方に関わります。接続できたかだけで終わらず、どのページへアクセスできる状態なのかまで確認する必要があります。

作るときに確認したい点

起きること	確認する場所	対応
Codexからページが見つからない	Notionのページアクセス	対象ページがコネクトに追加されているか確認する
保存後に一部の項目が空欄	レシピDBと元サイト	まずURLを残し 必要な項目だけ人が補う
登録が面倒で使わなくなる	保存時の入力項目	最初は料理名とURLを中心にして項目を増やしすぎない
在庫情報が古くなる	在庫DBの運用	完全な棚卸しをやめ 減ったら外し 買ったら戻す
保存したレシピが埋もれる	レシピDBのビュー	曜日 時短 作った回数 最終日で候補を出し直す
画面の233をレシピ数と誤解する	Finder画面下の表示	iCloudへ送信中のプロジェクト項目数として区別する

Notionでレシピ管理と献立を始める最小構成

ここまでの内容を、これから作る人向けの順番に直すと次のようになります。最初から今回の全項目をそろえる必要はありません。まずNotionだけで流れを試し、使い続けたいと分かってからCodexで保存部分を自動化します。

1 3つのDBを最小項目で作る

• レシピDB 料理名 URL カテゴリー 所要時間 曜日
• 在庫DB 品名 在庫あり 買う店
• 作った記録DB 記録名 作った日 レシピ

この段階では見た目を作り込みません。レシピを数件登録し、実際に一週間使ってみます。使わない項目は増やさず、献立を決めるときに足りなかった情報だけを追加します。

2 DB同士をリレーションでつなぐ

レシピDBと在庫DB、レシピDBと作った記録DBをつなぎます。まず一つのレシピへ材料を数件関連付け、作った記録を一件追加します。関連するページを相互に開けることを確認します。

3 作った回数と最終日をロールアップする

レシピDBへ二つのロールアップを追加します。作った記録の件数を数え、日付の最新値を表示します。ここまでできると、履歴が献立選びへ返ってくる形になります。

4 曜日 時短 店別のビューを作る

曜日ごとのビュー、所要時間15分以内のビュー、最近作っていない順のビューを作ります。在庫DBには店別のビューを作り、在庫ありがオフの物だけを出します。一度に多く作らず、普段よく使うビューから追加します。

5 手作業で一週間回してみる

ブラウザからURLを手で一件入れ、曜日ビューから料理を選び、買い物ページを見て、作ったあとに記録を追加します。どこが面倒だったかをメモします。自動化する場所は、この実際に面倒だった部分です。

6 Codexへ保存部分を依頼する

最初はURLを一件登録するローカル画面から始めます。動いたら、サイト名や料理名の取得、Chrome拡張の順に増やします。途中の画面やエラーをChatGPTやCodexへ見せながら修正します。

7 Notionのページ権限を確認する

コネクトがアクセスできるページを確認し、必要な範囲だけ許可します。実際にレシピDBへ一件追加できることを確かめてから、普段の保存へ使います。

最初から完全自動を目指さなかった理由

今回作ってみて、すべてを自動化すれば使いやすくなるわけではないと感じました。カテゴリーや曜日は、自分の生活やその日の負担に合わせて決める情報です。作ったあとの感想も、自分や家族がどう感じたかを残すものです。ここまで機械に任せるより、入力が面倒な部分だけを減らし、最後は自分で確認する方が合っていました。

Codexに任せたのは、URLを転記する、画面を作る、拡張機能から保存する、といった繰り返し作業です。何を食べたいか、どの曜日に回すか、また作りたいかは人が決めます。自動化する範囲を絞ったことで、仕組みが間違って動いても気付きやすく、Notionの中身も自分で理解したまま使えます。

時間がかかったのは自分の使い方を決める部分

この仕組みは、Codexへ一度頼んで完成したものではありません。保存したレシピがなぜ使われないのかを考え、どの情報があれば選べるかを整理し、3つのDBへ分け、曜日の意味を決め、在庫管理をどこまで軽くするかを考えました。そのうえで、ブラウザから入れる方法を作り、Notionの権限も確認しました。

振り返ると、コードを書くことより、自分が料理や買い物のどこで迷っているのかを見つける方に時間がかかっています。月曜日は負担を軽くしたい、木曜日は一皿で済ませたい、在庫を毎日数えるのは続かない、保存したレシピを忘れたくない。こうした小さな事情を一つずつ仕組みへ入れたことで、一般的なレシピ帳ではなく、自分の生活に合わせた形になりました。

ChatGPTとの相談が役立ったのは、この曖昧な不満を順番に言葉にできたことです。Codexが役立ったのは、言葉にした面倒を、実際に押せるボタンや保存画面へ変えられたことです。どちらか一つだけではなく、相談して決める作業と、動くものを作る作業を行き来したことが、今回の進め方でした。

まとめ

今回作ったのは、ブラウザで見つけたレシピをNotionへ保存し、在庫と履歴をつなぎ、曜日や所要時間から献立を選ぶ仕組みです。在庫DBは厳密な棚卸しではなく店別の買い物リストとして使い、作った記録DBから回数と最後に作った日をレシピDBへ返します。

レシピDBへ多く保存すること自体は、最終目的ではありません。月曜日に短時間の料理を探す、木曜日に一皿ものから選ぶ、しばらく作っていない料理を思い出す。こうした日々の判断が少し軽くなって、初めて保存した情報が役立ちます。

同じ仕組みを作るなら、まずNotionへ3つの小さなDBを作り、手作業で一週間回してみるのがよいと思います。その中で本当に面倒だった入力を見つけてから、Codexへローカル画面やChrome拡張を頼みます。私の場合は、その順番で考えたことで、レシピを集める場所から、毎日の献立を決めるための場所へ変えられました。

関連記事

ChatGPTとCodexだけで、WordPressブログを作って公開した。実際の流れとつまずいた点