1. はじめに
スナックミーというおやつの会社でCTOをしている三好 (@miyoshihayato) です
今年の2月下旬から、オペレーション全体を自分が見ることになりました。製造・出荷・在庫・シフト管理、エンジニアとして関わってきた期間も長かったけど、「全体を回す」立場になったのは初めてで、かなり新鮮でした。
そのタイミングで、ずっとやりたかった「AIを社内に本格インストールする」という取り組みを始めることにしました。Devinでの非エンジニアの活用は昨年から始めていました。だが、痒いところに手が届いていない感じがあり、世の中のさまざまな動きからまずはオペレーション領域でClaude Codeを試してみることに。
この記事は、ここ1ヶ月でやってきたことの記録です。技術的な話というより、「エンジニアが現場に入ってみて気づいたこと」「AIを現場に入れるときに本当に大事なこと」を中心に書きます。
年末に書いたブログを読むとここの内容がもっと解像度上がります
2. スナックミーのオペレーションって何してる？
スナックミーは、おやつの定期便サービスを運営している会社です。毎月、ユーザーの好みや苦手なものに合わせてパーソナライズされたおやつBOXをお届けしています。
オペレーションとして何をしているかというと、一言でいうとおやつの物流。
まず、キッチンがある。焼き菓子を手作りしていて、クッキーやバーなどを社内のキッチンで製造しています。それを袋に詰め、ラベルを貼り、BOXに梱包して出荷する、という流れがほぼ毎日動いています。
毎日の作業は大きく「製造」と「出荷」に分かれていて、それぞれに優先順位とルールがある。定期便・ストア・オフィス向けと複数のチャネルがあり、シフトに入るパートさんたちと一緒に回しています。
デジタルとリアル(おやつ)が混在しているのが、このオペレーションの面白さでもあります。システムで管理している情報もあれば、現場の感覚でしか持っていない情報もある。その混在をどう整理するか、が今回の取り組みの出発点でもありました。
3. エンジニアと現場のすれ違いを肌で感じた
エンジニアとして関わっていたころから、「EngとOPの目線が違う」と言うことに感じていました。でも、それを肌感覚で理解できたのは、実際に現場に入ってみてからです。
一言で表すなら、エンジニアは森を見て、現場は木を見ている。
エンジニアは「システムを通して運用してほしい」と思っています。なぜなら、データが蓄積されれば分析できるし、のちの効率化につながるから。長期的な最適化に向けた投資として捉えている。
一方、現場のスタッフは「今日、正しく動けること」が最優先です。少し回り道になる動線や、慣れない操作を求められると、どうしても前向きになりにくい。今日の出荷が滞れば、お客さんに迷惑がかかる。それが大事。
どちらも正しい。でも、歩み寄れるポイントを見つけにくかった。
今回この両方の立場を行き来するようになって、気づいたことがあります。現場スタッフの技量は、想像以上に高いということ。
パートさんたちは、小さな商品の違和感に気づいたり、運用の改善案を自主的に共有してくれたりします。スピードも正確性も、エンジニアが「なんとなく早そう」と思っていた以上のものがある。
だとすれば、「現場と一緒にツール」を作れれば、むしろ早く広がる可能性がある。そこに可能性を感じました。
4. まず「本質」と向き合うことから始まった
Claude Codeを使い始めた最初の1週間、正直なところスキルやエージェントをとにかく作りまくっていた。現状の棚卸された業務について一つずつ「これも自動化できそう」「あれもAIに任せたい」という気持ちで。
でも途中でふと気づいた。何のために作っているのか、ちゃんと言えるか？
闇雲に自動化しても、現場の動きと噛み合わなければ意味がない。むしろノイズになる。そこで一度立ち止まり、「オペレーションの本質って何だっけ」という問いに向き合うことにした。
オペレーションの仕事は、突き詰めると「今日、正しくおやつを届けること」 に尽きる。製造・出荷・在庫・シフト、それぞれが複雑に見えるけど、すべてはその一点に向かっている。
そう整理すると、AIに何をやらせるべきかが自然と見えてきた。
- 毎日変わるデータ（出荷件数、製造進捗、シフト状況）を集めて判断材料を作る
- 現場スタッフが「次に何をすべきか」を迷わずわかる状態にする
- ルールや例外をスタッフの頭の外に出す（ドキュメント化ではなく、聞けば答えてくれる形に）
本質がわかれば、作るものが絞れる。これがすべての出発点だったと思う。
5. Claude Codeをオペレーションに入れてみた
Claude Codeは、CLIで動くAIエージェントツールだ。コードを書くだけじゃなく、「スキル」と呼ばれる業務知識のかたまりを持たせることができる。
今回作ったのは大きく2種類。
① 毎朝のオペレーション確定レポート
製造・出荷・シフトの状況を各データソースから集めるSkillsを作り、「今日何をやるか」を1枚にまとめるエージェント。
毎朝手作業で確認していた「定期便の残件数は？」「製造の在庫は足りてる？」「今日のシフトは何人？」といった問いに、Claudeが自動で答えてくれる形にした。最初は「本当に信頼できるか？」と半信半疑で人力でダブルチェックしていたけど、1ヶ月経った今は精度が上がり、そのまま現場に共有できるレベルになってきた。
② 現場スタッフが使うスキル群
- 出荷指示書の自動生成（定期便・ストア・オフィス向けそれぞれ）
- 棚卸しリストのPDF出力
- 製造指示書の作成（定期便用、clr bar、ストア）
- 賞味期限管理リスト
これらはパートさんが直接Claudeに話しかけて使う想定で設計した。「コマンドを覚える」ではなく、「今日の作業を教えて」という感覚で動かせるように。
ここで少し立ち止まって考えたことがある。
エンジニアがGitHubでコードを管理するのは、「細かい仕様をすべて頭に入れておく」ためじゃない。コードを読めば逆算できる状態にしておくことで、誰でも理解できる・引き継げる・改善できる状態を保つためだ。
オペレーションも同じ構造にできるはずだ。ただし、コードで表現できるのは「仕様」であって、「なぜそうなったか」という意思決定のプロセスや現場の文脈はコードに落ちない。
ここをスキルやサブエージェントで持つことで、「なぜ月曜は定期便を最優先にするのか」「なぜこのタイミングで在庫を確認するのか」という判断の根拠ごと管理できるようになる。これが属人化を崩す鍵だと思っている。
6. スプレッドシート ≒ データベース、という発想の転換
オペレーション現場では、スプレッドシートがすべての情報の中心にある。商品の梱包方法、必要な資材、製造の賞味期限、依頼ごとのメモ。
エンジニア視点だと「スプレッドシートはデータベースじゃない」とつい思ってしまう。でも、現場にとってスプレッドシートは歴とした「記録と参照の場所」だ。
今回やったのは、この2つを≒（ほぼ等しい）と捉え直すこと。
スプレッドシートの情報はデータベースでも管理しているが、実運用には信頼性が低かった。だが、その連携をチーム間で認識レベルを統一させることで「この商品の梱包資材は？」「製造期限はいつまで？」という問いに、Claudeが即答できるようになる。
ただ、データベースには限界がある。ルールは持ちにくいのだ。
例えば「定期便の出荷は優先順位1位だが、月曜は件数が多いのでシフトを厚くする」、これはデータじゃなく、現場の文脈から生まれた判断ルールだ。データでも判断できるようにすることは可能だが、前段階では一定のルールベースがスムーズにことを運べるようになる。
ここをカバーするのがスキルとエージェント。データベースに「事実」を持たせ、スキルに「判断ルール」を持たせる。この役割分担が決まってから、設計がぐっとシンプルになった。
データベース → 事実（在庫数、件数、シフト人数） スキル/エージェント → 判断ルール（優先順位、例外ケース、文脈）
複雑に見えたオペレーションが、実は事実 × ルールのかけ合わせでできていた。本質はシンプルだった。
7. パートさんまで使い始めた
最初は自分とチームで使い始めたスキル群ですが、今はパートさんにも使ってもらっています。
たとえば出荷指示書の作成。以前は担当者が手作業でスプレッドシートを確認しながら作っていたものが、Claudeに頼むだけで出てくるようになった。棚卸しリストも同様。
「AIを現場スタッフに使ってもらう」と聞くと、ハードルが高そうに思えるかもしれない。でも実際は意外とスムーズでした。
理由は2つあると思っています。1つは設計の問題。コマンドや難しい操作を覚えてもらうのではなく、「いつもの言葉でClaude に話しかける」だけで動くように作ったこと。
もう1つはスタッフの能力の高さ。前述の通り、現場スタッフは新しいやり方への適応力が高い。「これ便利だね」と言いながら使い始めてくれる人が多かった。
まだ全員が日常的に使っている段階ではないけれど、「ツールが現場に根ざしていく」手応えは感じています。
8. 1ヶ月やってみてわかったこと
やってみて感じた、正直なところをまとめます。
良かったこと
- 「なぜこれをやっているのか」「どのページを見ればいいのか」「何に気をつけるべきか」、こうした情報が必要なものだけに絞られ、現場がシンプルになってきた
- 属人的にしれっと対応されていた部分が表面化した。隠れていた複雑さが見えるようになると、整理できる
- 毎日のレポートが、自分で手を動かすのと同じ内容になってきた。信頼度が上がっている
まだ途中なこと
- スキルやエージェントはまだ増やしている最中。「本質から作る」を意識しつつも、まずは触ってみないとわからないことも多い
- 現場全体への浸透はこれから。使い方の定着には時間がかかるが遠い話ではない
一番の学び
スキルやエージェントを使い始めると、「自分やチームの仕事の本質って何か」と向き合わざるを得なくなる。これが一番大きかった。
闇雲にスキルを追加し続けると、最終的には崩壊する。使われないスキルが増え、何が動いているかわからなくなり、誰も信頼しなくなる。エンジニアリングでもよくある、「技術負債」に近い状態だ。
だからこそ、アウトカムから設計する必要がある。「このスキルを作ることで、誰の何が変わるのか」、これに答えられないものは作らない。技術を先行させずに、課題から設計する。エンジニアリングと同じ原則が、オペレーション×AIにもそのまま当てはまった。
9. おわりに
「おやつの会社でAI」と聞くと、少し意外に思うかもしれません。でも、毎日の製造・出荷・在庫管理・シフト調整、こういうオペレーションこそ、AIが入り込む余地が大きい領域だと感じています。
しかも、扱っているのはリアルなおやつ。キッチンで焼いて、手で詰めて、届ける。デジタルだけで完結しない面白さがスナックミーにはあります。
AIは魔法じゃないし、入れれば勝手に現場が変わるわけでもない。でも、「本質に向き合う」ことを促してくれる。
自分の仕事の本質って何だろう、そこから始めると、AIの使い方が自然と見えてきます。
まだまだ途中ですが、またアップデートを書きます。
