小さな喫茶店で作る、ドリップバッグ印刷データ生成ツール——AIエージェントのワークフローをゼロから組み立てる

喫茶店を営む友人が、私が作ったドリップバッグの表紙生成ツールを見て、ひと言メッセージを送ってきた。

「これ、私にも必要な気がする。」

豆は一バッチごとに、名前、産地、焙煎度、風味、焙煎日が変わる。豆を変えるたびに、表紙も組み直さなければならない。お客さんが会社用、結婚式用、イベント用にカスタマイズしたいと言えば、またレイアウト、校正、サイズ合わせ、印刷という一連の作業が待っている。

小さな店にデザイン部なんてない。

レイアウトをする人は、たいてい豆を焙煎している本人で、メッセージの返信も、発送も、帳簿づけも全部同じ人がやっている。

この記事は彼のために、そして同じ悩みを抱えるすべての小さな喫茶店のために書いた。あのドリップバッグ印刷データ生成ツールを例に、ツールのインストールから始めて、自分だけのAIエージェントのワークフローをどう組み立てるか、一歩ずつ説明していく。記事の最後には、そのままエージェントに貼り付けられる段階別プロンプトを用意した。この通りに進めれば、あなた自身のブランドの生成ツールが作れる。

01完成品を見る：大杯居（Wide Living Cup）のドリップバッグ表紙生成ツール

まず完成形を見たほうが、どこまで作ればいいのかイメージしやすい。

これは大杯居が実際に使っている生成ツール。豆のバッチごとに入力するのは5項目だけ——豆名、焙煎度、風味キーワード、一言二言の説明、焙煎日。

入力し終わると、右側のプレビューがすぐに切り替わる。表面はブランドと豆名、裏面は風味、説明、賞味期限、法規表示の欄。

デザイン上、いくつか意図的に決めたことがある。

• ブランドと法規表示の欄は固定。ブランドの文言、法規表示の小さな文字、QRコードはすべてプログラム内の定数として書き込まれていて、フォームを入力する人が変更することはできない。誰かがうっかりブランドの文言を書き換えてしまう心配がない。
• 変わりうるデータだけを入力可能にする。豆名、焙煎度、風味、説明、日付はバッチごとに違うので、そこだけ入力できるようにした。
• 日付は自動計算。焙煎日を入力するだけで、賞味期限と有効期限はプログラムが自動で算出する。
• 風味が模様を決める。最初の風味キーワードが型染めの模様の一群に対応していて、豆を変えると表紙の柄も変わる。
• 文字は大きく、読みやすく。袋を読むのは年配の方も含まれるので、豆名、焙煎度、日付は一番大きな文字サイズで組んでいる。

書き出しボタンを押すと、表と裏それぞれにPDF、AI、SVG、PNGの4種類の形式が生成され、ひとつのZIPにまとめられる。PDFは印刷用、AIはIllustratorに慣れている人向け、SVGとPNGはほかのソフトやウェブ用。

この生成ツールは完全な静的ウェブページで、レイアウトはすべてブラウザの中で完結する。サーバーは不要で、入力したデータがどこかに送信されることもない。

表紙に写っている2種類の豆は、どちらも大杯居が今実際に販売しているもの。

大杯居のコーヒー豆とドリップバッグを見てみる

02まず仕組みを理解する：あなた、ルール、エージェント、ツール

手を動かす前に、5分だけ使って全体の仕組みを理解しておこう。この章さえ分かれば、この先のステップはぐっと理解しやすくなる。

チャットAIとエージェントの違いは「手があるかどうか」

多くの人がAIを使うときは、ウェブやスマホでチャットする形だ。質問すると、答えが返ってくる。でもその答えを実際の成果物にするには、結局自分でコピー＆ペーストしたり、ソフトを開いたりしなければならない。

エージェントはあなたのパソコンの中で作業する。フォルダ内のファイルを開いて中身を書き換えたり、ターミナルでコマンドを打ったり、プログラムを実行したりできる。実行結果がおかしいと気づけば、自分で修正して、もう一度実行し直す。

だからエージェントに渡すのは目標——どんな状態にしたいか、何をもって完成とするか。手順を組み立てるのはエージェントの仕事で、あなたは出来上がりを確認する係。

4層構造

この4層のうち、一番入れ替わりやすいのはモデルで、数か月おきに新しいバージョンが出る。ルールと記憶はあなた自身のフォルダに残るので、モデルやツールを変えても、そのまま引き継げる。

時間をかけて育てる価値があるのは、この2層目だ。

03Claude CodeとCodexの役割

Claude CodeはAnthropicのエージェントで、CodexはOpenAIのエージェント。どちらもターミナルの中で動作し、できることはよく似ている。どちらか一つを選んで始めればいい。

私自身の役割分担はこうなっている。

• Claude Codeがメイン：要件の相談、計画、実装、検収、デプロイ、ほとんどをここで完結させる。複数のサブエージェントを同時に派遣して手分けさせることもできるし、手を動かす前に計画全体を私に見せて承認を求めることもできる。
• Codexはもう一人の同僚：作画を担当（この記事の挿絵もClaude CodeがCodexに描かせたもの）。Claude Codeの利用枠を使い切ったときの引き継ぎ役でもある。

この2つのツールが読むルールファイルの名前は違うが、同じ内容を読ませることができる。

04インストール：作業環境を整える

用意するもの。

ステップ1：ターミナルを開く

ステップ2：Node.jsとGitをインストールする

xcode-select --install

winget install --id Git.Git -e --source winget

インストールが終わったら、ターミナルを一度閉じて開き直し、次の3行を入力する。どの行もバージョン番号が表示されれば成功だ。

node -v
npm -v
git --version

ステップ3：エージェントをインストールする

どちらか一つを選ぶ。両方インストールしてもかまわない。

curl -fsSL https://claude.ai/install.sh | bash

irm https://claude.ai/install.ps1 | iex

curl -fsSL https://chatgpt.com/codex/install.sh | sh

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

ステップ4：GitHubとCloudflareに登録する

この2つのアカウントは、自分でブラウザから登録・ログインする。この後エージェントがデプロイの際にログインコマンドを実行すると、ブラウザに認可ページが表示されるので、本人が「同意」を押す。パスワードは最初から最後までエージェントを経由しない。

ステップ5：エージェントにチェックしてもらう

エージェントを開いて、この文章を貼り付ける。

読み取り専用のコマンドだけを使って、このパソコンの開発環境を確認してください。何もインストールしたり変更したりしないでください。
1. OSとそのバージョン
2. node -v、npm -v、git --version の結果
3. 現在いるフォルダのパス
結果を表にまとめてください。足りないものがあれば、公式ダウンロードページのURLを教えてください。インストールは私自身が行います。

05ワークフローの骨組みを作る

ツールが揃ったら、次はエージェントのために「引き継がれる頭脳」を用意する。中身はすべてフォルダとテキストファイルだ。

06実践：エージェントでドリップバッグ生成ツールを作る

先にきちんと聞かれてから、仕様を書く

私がエージェントに投げた最初のひと言はシンプルだった。「ドリップバッグの表紙を作る生成ツールを作って。豆のバッチごとに情報を差し替えて、あとのレイアウトは固定で。」

すぐには書き始めなかった。まず一つずつグループに分けて聞いてきた。袋の実際のサイズは？印刷にはどんな機械を使い、どんなファイル形式を受け付ける？法規表示にはどの欄が必要？バッチごとに変わるデータは何？あえてやらないことは何か。

聞き終わると、答えを一つの仕様にまとめた。目標、やること、やらないこと、何をもって完成とするか、間違えたときにどう元に戻すか。私が目を通して承認と言ってから、ようやく手を動かし始めた。

手戻りが一番多いのは、たいてい最初にきちんと詰めていなかった部分だ。きちんと聞かれるあの10分が、後の何時間もの手戻りを防いでくれることが多い。

開発過程での3回の裏取り

開発の過程で、エージェントがどう働くべきかを特によく表している出来事が3つあった。

段階別プロンプト集

以下は7段階に分かれていて、一度に一段ずつ貼り付ける。その段が終わって自分で問題ないと確認してから、次の段を貼る。どの段も、まずエージェントに計画を見せてもらい、承認してから動いてもらう形にしている。

あなたは私のAIワークフロー構築アシスタントです。この段階ではヒアリングだけを行ってください。ファイルの作成・変更・削除は行わず、何もインストールしないでください。

私の背景：小さな喫茶店を経営していて、自分で豆を焙煎しています。「ドリップバッグ表紙印刷データ生成ツール」を作りたいと思っています。バッチごとにデータを入力するだけで、そのまま印刷に出せる表と裏の表紙データが生成でき、ブランドと法規表示の欄は固定されているものです。

次の方法で私にヒアリングしてください。
1. 一度に1グループの質問（2〜4問）だけを聞いてください。各質問には2〜4個の選択肢を付け、おすすめの選択肢があれば一番上に置いて理由を説明してください。
2. 読み取り専用のコマンドで自分で調べられること（OS、インストール済みのツールとバージョンなど）は、どのコマンドを実行するか先に説明してから自分で調べてください。私には聞かないでください。
3. 確認すべきこと：
   - ブランド素材：ロゴファイルの形式、ブランド名とキャッチコピー、指定フォントと配色
   - 袋：仕上がりサイズ（ミリ単位）、表と裏、綴じ代と安全マージン
   - バッチごとに変わるデータ：豆名、産地、精製方法、焙煎度、風味、説明、焙煎日、ほかにあるか
   - 固定のデータ：法規表示の欄、連絡先情報、QRコードのリンク先
   - 印刷：自分のプリンターで印刷するか印刷所に出すか、必要なファイル形式、裁ち落としとトンボが必要か
   - 誰がこの生成ツールを使うか、パソコンかスマホか
   - あえてやらないこと
4. ヒアリングが終わったら、「要件サマリー」（箇条書き、500字以内）にまとめて私に確認を取ってください。私が確認と言うまで、次のステップには進まないでください。

現在のフォルダにワークフローの骨組みを作ってください。まず作成するファイルの一覧と、各ファイルの内容の下書き全文を先に見せてください。私が「承認」と言ってから作成してください。

1. AGENTS.md（すべてのエージェントが共有するルールの正本）、最低限次を含める。
   - 常に日本語で返答すること。
   - ファイルの変更、ソフトのインストール、ファイルの削除の前には、何をするか、どのファイルに影響するか、失敗したときにどう元に戻すかを説明し、私の承認を待つこと。
   - 価格、仕様、法規、ソフトの機能は必ず公式の情報源で確認し、URLと確認日を添えること。見つからなければ「見つからない」と正直に言うこと。
   - コマンド、ファイル、公式ドキュメントで完結できることは、画面を見てボタンをクリックする方法に置き換えないこと。
   - パスワード、APIキー、ログイン用トークンはどのファイルにも書き込まず、会話に貼るよう求めないこと。
   - 本番へのデプロイ、誰かへのメッセージ送信、データの削除は、最後の一手を私自身が実行するか、明確に承認すること。
   - 一つの作業が終わったら、実際に検証してから（テストを実行する、ファイルを開く、サイズを測るなど）、何を検証したかをはっきり報告すること。
   - 見つかった問題と解決策はmemory/に書き、memory/MEMORY.mdの索引を更新すること。
   - 作業を途中で止めるときは、records/に引き継ぎ記録を書くこと。
2. CLAUDE.md：内容は@AGENTS.mdの一行だけ。
3. memory/MEMORY.mdを作成し、前段の要件サマリーをmemory/requirements.mdとして保存する。
4. records/README.md：引き継ぎ記録のフォーマット（目的、進捗、次の一手、触れたファイル、決定とその理由）。
5. .agents/skills/の空フォルダ。
6. gitを初期化し、.gitignore（node_modules、出力ファイル、あらゆる.envと鍵ファイルを除外）を作成して、最初のコミットを行う。
完了したらフォルダ構成を一覧表示し、CLAUDE.mdがその一行だけであることを確認してください。

memory/requirements.mdを読んで、docs/spec.mdという仕様書を書いてください。この段階では文書だけを書き、コードは書かないでください。

仕様には次を含めてください。
1. レイアウト：表面と裏面それぞれのレイアウト図解（文字と座標での説明でよい）。単位は必ずミリメートルとし、仕上がりサイズ、裁ち落とし、安全マージン、各要素の位置と最小フォントサイズを示すこと。
2. 項目表：各項目が「固定」か「バッチごとに入力」か、文字数の上限、上限を超えたときの処理（フォントサイズを縮める、改行する、または利用者に短縮を促す）。
3. 法規表示：私が販売する商品に合わせて、「食品安全衛生管理法」第22条と衛生福利部食品薬物管理署の公式説明を調べ、パッケージに表示が必要な項目を挙げ、それぞれに公式URLと確認日を添えること。適用されるか不明な項目は「要人力確認」と明記し、自己判断しないこと。
4. 出力形式：PDF（印刷用、文字をアウトライン化し、正しいサイズで埋め込む）、AI（現在の.aiとPDFの関係を公式情報源とともに説明する）、SVG、PNG（300dpi）、それとZIPにまとめるときのファイル名の規則。
5. 技術選定：完全な静的ウェブページ（HTML、CSS、JavaScript。レイアウトはブラウザ内で完結させ、サーバーは不要、データはアップロードしない）。使用するライブラリとそのライセンス（フォントもライセンスが埋め込みと商用利用を許可しているか確認すること）。
6. 検収条件：実際にチェックできる条件を5〜8個挙げること。例えば「一番長い豆名が収まる」「PDFのサイズを測ると正しい」「QRコードがスマホで読み取れる」など。
7. あえてやらないこと。
書き終わったら見せてください。私が承認するまでコードは書き始めないでください。

docs/spec.mdに沿って、印刷できる最初のバージョンを作ってください。範囲は次までとします。
1. ウェブフォーム：バッチごとに入力する項目を用意し、入力すると表面と裏面がリアルタイムでプレビューされる。
2. 「PDFをダウンロード」：表と裏それぞれ1ページ、サイズはspec通り、文字はアウトライン化する。
3. 固定項目（ブランド、法規表示の小さな文字）はプログラム内の定数として書き、フォームからは変更できないようにする。
4. 自動テストを書く：最低限「項目の上限文字数の最長ケースが収まるか、収まらなければ警告が出るか」「PDFのページサイズが正しいか」をテストする。

完了したら：
- テストを実行して結果を貼ってください。
- ローカルプレビューで開いて、サンプルデータを入力した画面のスクリーンショットを見せてください。
- PDFのサンプルを1部生成し、ファイルの場所を教えてください。私が自分で開いて確認し、1枚試し刷りします。
- gitのコミットを1回行ってください。
私がサンプルに問題がないと確認するまで、次の段階には進まないでください。

確認済みの最小バージョンの上に、一度に一つずつ機能を追加してください。一つ追加するたびにテストを実行し、サンプルを見せて、gitのコミットを1回行ってください。
1. 模様：最初の風味キーワードに対応する装飾模様の一群を用意する（対照表は独立した設定ファイルにして、後から追加しやすくする）。模様がラスター画像の場合はベクター化し、変換後にノード数が急増していないか確認する。
2. QRコード：specで指定したURLにリンクさせ、印刷後にスマホで実際にスキャンして確認する。
3. 日付の自動計算：焙煎日だけを入力すれば、ほかの日付はspecのルールに沿って自動的に算出する。
4. 複数形式での書き出し：AI、SVG、PNG（300dpi）を、PDFと同じレイアウト結果を共有する形で出力し、一つずつ開いて内容が一致しているか確認する。
5. ZIPへのパッケージ化：表と裏のすべての形式を一度にダウンロードできるようにし、ファイル名はspecのルールに従う。
6. レイアウトの負荷テスト：今ある全部の豆のデータ（一覧を渡します）を一つずつ流してみて、収まらない項目や調整が必要な項目を挙げてください。
エラーに遭遇したときは、まず公式ドキュメント、パッケージのソースコード、issueを調べて原因を特定し、原因と解決策をmemory/に書いてください。当てずっぽうで回避しないでください。

生成ツールを一つのURLとしてデプロイし、店のスタッフ全員が使えるようにしてください。先に計画を見せて、承認してから実行してください。

1. GitHubにプライベートリポジトリを作成し、プロジェクトをプッシュする（ログインが必要なときは、私自身がブラウザで認可を完了します）。
2. Cloudflare Workersの静的アセット（static assets）でデプロイする。Cloudflareの公式ドキュメントを調べて、ウェブページに必要なファイルだけをアップロードするようwrangler設定ファイルを構成してください。
3. wrangler loginを実行するときは、私自身がブラウザで認可します。wrangler deployの前に、アップロードするファイル一覧を見せてください。私が「デプロイ」と言ってから実行してください。
4. デプロイ後、curlまたはブラウザで実際にURLを開き、ページ、フォント、ダウンロード機能が正常か確認し、スマホでも一度テストしてください。
5. 私が自分のドメインを持っている場合は、公式ドキュメントでカスタムドメインの紐付け方法を調べ、一歩ずつ案内してください。
6. デプロイの方法と注意点をmemory/deploy.mdに書いてください。

1. 「新しい豆の表紙を出す」という作業をskillにしてください：.agents/skills/drip-label/SKILL.md。冒頭のYAML frontmatterにはnameとdescriptionを入れ、descriptionには「いつ使うか」を、私が言いそうな言葉（例えば「新しい豆の表紙を出して」「ドリップバッグの印刷データを作って」）を含めて、はっきり書いてください。本文には手順、検収方法、よくある問題を書いてください。先に下書きを見せてください。
   あなたがClaude Codeの場合：さらに.claude/skills/drip-labelに正本を指すリンクを作成してください。リンクが作成できない場合はコピーを1部作り、1行目に正本の場所を明記してください。
2. （両方のエージェントがインストールされているときだけ行う）もう一方のエージェントに読み取り専用のレビューを依頼してください。
   - あなたがClaude Codeの場合：codex execで依頼する。あなたがCodexの場合：claude -pで依頼する。
   - 依頼内容：「docs/spec.md、.agents/skills/drip-label/SKILL.md、およびコードを読んでください。読むだけで変更はしないでください。次を確認してください。検収条件すべてに対応するテストがあるか、法規表示の欄すべてに公式情報源が付いているか、パスワードや鍵がファイルに書き込まれていないか。問題を箇条書きにし、ファイル中の該当する文をそのまま添えてください。」
   - 実行前に完全な指示文を私に見せてください。報告を受け取ったら、どれが妥当か判断し、修正案を挙げてください。私が承認してから修正してください。

07デプロイ：生成ツールをネットに公開する

生成ツールは完全な静的ウェブページで、HTML、CSS、JavaScriptとフォント、模様といったファイルしかない。すべての処理は利用者のブラウザの中で完結する。このタイプのページをCloudflare Workersの静的アセットサービスに置けば、無料プランで十分足りる。

08Webコーディングの核心：結果重視、学び続ける、出典を追う

AIは「ハルシネーション」を起こし、存在しないことを大真面目に語る。印刷データのように実際に刷って出すものを作るときは、これの代償が特に大きい。

これに対処するために、私は3つのことをしている。

1. 結果重視。エージェントに渡す目標は、必ずチェックできる結果にする。印刷できる、サイズが正しい、QRコードが読み取れる、法規表示が正しい、スマホでレイアウトが崩れない。どんなに立派な説明でも、動かなければ未完成だ。
2. 行き詰まったら調べる。分からないことに出会ったら、エージェントに公式ドキュメント、パッケージのソースコード、法規の原文をめくらせる。先ほどのフォントが歪む問題も、ソースコードまで遡ってようやく解決した。学んだことは記憶に書き込む。
3. 出典を追う。すべての価格、すべての規定、すべてのツールにできることには、情報源と確認日を添える。見つからないものは、正直に見つからないと言う。

この3つを重ねても、AIはやはり間違えることがある。ただ、間違えたものは検収を通らない。

09エージェントにコマンドラインで仕事を振り合わせる

Claude Codeのclaude -pとCodexのcodex execは、どちらもターミナルで1行のコマンドを打つだけで、一つの仕事を任せて、終わったらそれで完結する。

つまり、一つのエージェントがもう一つのエージェントに仕事をさせられるということだ。

• 作画：この記事の最初のカードの小獅妹の挿絵は、Claude Codeが画面の要件、キャラクターの外見の説明、除外すべき間違った特徴をプロンプトファイルにまとめ、codex execでCodexに渡して描かせたもの。描き終わるとフォルダに保存され、Claude Codeがそれを開いて項目ごとにキャラクターを見比べる。
• 相互レビュー：一方が書いた仕様やコードを、もう一方に読み取り専用でチェックしてもらう。2社が学習させたモデルの死角は必ずしも同じではないので、安上がりな二重チェックになる。

10効率面でのいくつかの発見

• 高いモデルはここぞという場面だけに使う。一番強くて高いモデルは計画と検収を担当し、量が多く仕様がはっきりしている作業は、もう少し安いモデルに振って同時にやらせる。
• 長い会話で一番お金がかかるのは読み直し。エージェントは一言返すたびに、それまでの会話全体を読み直す。読み直す部分にはキャッシュの割引があるとはいえ、会話が長くなるほど1回のやり取りはどんどん高くなり、後半になるほど前の細部も忘れやすくなる。一つの作業が終わったら引き継ぎ記録を書いて、新しい会話を開く。
• コマンドで済むなら画面は見ない。エージェントはブラウザを操作してボタンをクリックすることもできるが、それは一番遅く、一番間違えやすいやり方だ。コマンド、API、URLパラメータでできることは、必ずそちらを先に使う。
• 自己チェックはあてにならない。あるとき、サブエージェントに大量のスクリーンショットへのモザイク処理を頼んだところ、全部完了したと報告してきた。1枚ずつ開いて確認すると、4枚に処理漏れがあった。それ以来、ルールに一条を加えた。検収は必ず自分の目でやること。個人情報、金額、外部に送るものが関わる場合は、抜き打ちではなく全部見ること。

11安全の境界線

• パスワード、APIキー、ログイン用トークン：会話に貼らない、どのファイルにも書かない、GitHubにプッシュしない。ログインは必ず本人がブラウザで行う。
• 外の世界に触れる動作（サイトの公開、お客さんへのメッセージ送信、データの削除）：エージェントが準備してプレビューを見せ、最後の一歩はあなたが実行するか明確に承認する。
• お客さんの氏名、電話番号、住所：ルール、記憶、引き継ぎ記録には書き込まない。
• 大きな変更をする前には必ずgitでコミットし、失敗しても元に戻せるようにする。

12費用

どちらも月額サブスクリプションで、利用上限は「5時間ごと」と「週ごと」の枠で計算され、プランによって異なる。

デプロイ側：GitHubのプライベートリポジトリは無料。Cloudflare Workersの静的ファイルへのリクエストは無料で回数制限もない。GitHubと連携した自動ビルドの無料枠は月3,000分。

13Q&A

ハードル

費用とツール

印刷

安全と保守

14最後に

この記事を書きながら、ずっと想像していた。あの友人の店のある朝、新しいバッチの豆が焙煎機から出てきたばかりで、彼は生成ツールを開き、豆名と焙煎日を入力してクリックする。それだけで表紙が組み上がる。浮いた1時間で、彼は新しい豆を試し焙煎するもよし、ただゆっくりコーヒーを一杯飲むもよし。

ツールは、時間を人に返すためにある。

表紙に写っているあの2種類の豆を飲んでみたいと思ったら、ぜひ大杯居に遊びに来てほしい。

大杯居で豆を選ぶ

Awei 記す 2026年9月