ここには、AI で作っているものを書き留めています。毎日動いているものもあれば、まだ自分と議論中のスケッチもあります。どちらかは、それぞれのカードに書いてあります。
シミュレーターはすぐ下です。さあ、壊せるものなら壊してみてください。
試してみる · 稼働中
注文を作り、配送方法と支払条件を選んで、注文がどこへ行き、いつ出荷され、いつ請求書が出るかを見てください。BrandHub （新しいタブで開きます） の注文ルールで動いています。壊せるものなら壊してみてください。
これまで
作るより読むほうが時間のかかる月次レポート。
やり方
BrandHub （新しいタブで開きます） 自身のサーバーで動くローカルの Llama モデル。データベースを丸ごと渡すのではなく、PostgreSQL に問い合わせるツールと、どのテーブルに何があるかの知識を渡します。だから、ふつうの言葉で答えられます。
私の役割
開発中です。使えるツール、読めるテーブル、回答のチェックを作っています。
「先月ナプキンを注文したテナントは？」
→ まず商品を探す
→ 次にテナント、それから注文
これまで
スプリントの準備に約 20 時間、毎週同じ雑務。
やり方
自分の仕事の遅い部分のために作った Claude スキルと、つながったエージェントたち。競合調査、git とデータモデルへの影響、クライアント資料の整理、Jira ストーリーの下書き。Atlassian Rovo が各ストーリーの抜けをチェックします。あなたの 1 週間にもこんな部分や、もっとシンプルにできるポータルのフローがあるなら、それはまさに私の得意分野です。
スプリントの準備が約 20 時間から約 6 時間に。
私の役割
私が作り、毎スプリント使っています。
スプリント準備 ... 20時間 → 約6時間
これまで
いまは営業担当が電話に 10〜15 分かけ、メモを取り、カタログを探して、注文を手で作っています。
やり方
BrandHub （新しいタブで開きます） のために作りました。AI が注文の電話を記録し、注文明細の下書きを作ります。電話は英語かオランダ語。営業担当から事務作業を取り除くもので、営業担当の代わりではありません。
私の役割
BrandHub （新しいタブで開きます） 向けにフローを設計し、仕様を書きました。
「ナプキンを 500 枚ください」
→ 商品：ナプキン、数量：500
→ 該当するナプキン 50 種を、営業担当が選びやすい順に。
目標 ........ 5〜6分
これまで
新しい顧客は、何千もの商品が載ったカタログを知りません。
やり方
アシスタントが、どんな事業か、どこで、何のために、いくつ必要かを聞いてから、商品を提案します。
私の役割
私のコンセプト。いまはまだ紙の上です。
レストランを開く人には、エプロン、ナプキン、ユニフォーム、テーブル用品がひとつのリストで届きます。
これまで
印刷機は少し多めに刷ることがよくあります。1,000 個注文して 1,050 個届き、サプライヤーは 1,050 個分を請求します。
やり方
1 回なら問題ありません。倉庫ではすべての箱をスキャンするので、システムはパターンに気づけます。同じサプライヤー、同じ商品で +7%、+8%、+6%。そこで商品管理に知らせ、標準の数量や許容範囲、サプライヤーとの話し方を変えてもらいます。
私の役割
私のコンセプト。いまはまだ紙の上です。
サプライヤー X · 商品 Y
注文 1 ........... +7%
注文 2 ........... +8%
注文 3 ........... +6%
→「過剰納品が 3 回。確認しますか？」
これまで
1 日約 30 件の報告。その大半はバグではなく質問でした。
やり方
ファイル 03 の障害対応アシスタントです。LLM が報告を 1 件ずつ、システムのデータモデルや git のコードと照らし合わせ、答えられる質問、本物のバグ、バックログ行きのアイデアに振り分けます。
私の役割
仕様を決め、プロンプトと出力ルールを書き、ローンチを主導しました。
これまで
チームは本来のシステムとは別に、Teamleader や Moneybird のような請求ツールを掛け持ちしています。
やり方
手作業の請求書もシステムが作る請求書も、ひとつのプラットフォームで最初から最後まで。
私の役割
担当する 4 つのプロダクトのひとつとして、OKR を決め、バックログの優先順位をつけています。
開発中 · 2026
これまで
作るより読むほうが時間のかかる月次レポート。
やり方
BrandHub （新しいタブで開きます） 自身のサーバーで動くローカルの Llama モデル。データベースを丸ごと渡すのではなく、PostgreSQL に問い合わせるツールと、どのテーブルに何があるかの知識を渡します。だから、ふつうの言葉で答えられます。
私の役割
開発中です。使えるツール、読めるテーブル、回答のチェックを作っています。
「先月ナプキンを注文したテナントは？」
→ まず商品を探す
→ 次にテナント、それから注文
これまで
スプリントの準備に約 20 時間、毎週同じ雑務。
やり方
自分の仕事の遅い部分のために作った Claude スキルと、つながったエージェントたち。競合調査、git とデータモデルへの影響、クライアント資料の整理、Jira ストーリーの下書き。Atlassian Rovo が各ストーリーの抜けをチェックします。あなたの 1 週間にもこんな部分や、もっとシンプルにできるポータルのフローがあるなら、それはまさに私の得意分野です。
スプリントの準備が約 20 時間から約 6 時間に。
私の役割
私が作り、毎スプリント使っています。
スプリント準備 ... 20時間 → 約6時間
これまで
いまは営業担当が電話に 10〜15 分かけ、メモを取り、カタログを探して、注文を手で作っています。
やり方
BrandHub （新しいタブで開きます） のために作りました。AI が注文の電話を記録し、注文明細の下書きを作ります。電話は英語かオランダ語。営業担当から事務作業を取り除くもので、営業担当の代わりではありません。
私の役割
BrandHub （新しいタブで開きます） 向けにフローを設計し、仕様を書きました。
「ナプキンを 500 枚ください」
→ 商品：ナプキン、数量：500
→ 該当するナプキン 50 種を、営業担当が選びやすい順に。
目標 ........ 5〜6分
これまで
新しい顧客は、何千もの商品が載ったカタログを知りません。
やり方
アシスタントが、どんな事業か、どこで、何のために、いくつ必要かを聞いてから、商品を提案します。
私の役割
私のコンセプト。いまはまだ紙の上です。
レストランを開く人には、エプロン、ナプキン、ユニフォーム、テーブル用品がひとつのリストで届きます。
これまで
印刷機は少し多めに刷ることがよくあります。1,000 個注文して 1,050 個届き、サプライヤーは 1,050 個分を請求します。
やり方
1 回なら問題ありません。倉庫ではすべての箱をスキャンするので、システムはパターンに気づけます。同じサプライヤー、同じ商品で +7%、+8%、+6%。そこで商品管理に知らせ、標準の数量や許容範囲、サプライヤーとの話し方を変えてもらいます。
私の役割
私のコンセプト。いまはまだ紙の上です。
サプライヤー X · 商品 Y
注文 1 ........... +7%
注文 2 ........... +8%
注文 3 ........... +6%
→「過剰納品が 3 回。確認しますか？」
これまで
1 日約 30 件の報告。その大半はバグではなく質問でした。
やり方
ファイル 03 の障害対応アシスタントです。LLM が報告を 1 件ずつ、システムのデータモデルや git のコードと照らし合わせ、答えられる質問、本物のバグ、バックログ行きのアイデアに振り分けます。
私の役割
仕様を決め、プロンプトと出力ルールを書き、ローンチを主導しました。
これまで
チームは本来のシステムとは別に、Teamleader や Moneybird のような請求ツールを掛け持ちしています。
やり方
手作業の請求書もシステムが作る請求書も、ひとつのプラットフォームで最初から最後まで。
私の役割
担当する 4 つのプロダクトのひとつとして、OKR を決め、バックログの優先順位をつけています。
開発中 · 2026
要件、デザイン、データモデル、ボード、ドキュメント、チャットをひとつの場所に。これでチームは Jira、Figma、Confluence、Teams を行き来しなくて済みます。何かが変わると、ほかにどこへ影響するかを AI が見つけ、更新を手伝います。
私の役割
私のアイデアです。デザインも開発もしています。
プラグマティズムの父にちなんだ名前です。私たちもその考え方で作っています。
peirce.app →要件、デザイン、データモデル、ボード、ドキュメント、チャットをひとつの場所に。これでチームは Jira、Figma、Confluence、Teams を行き来しなくて済みます。何かが変わると、ほかにどこへ影響するかを AI が見つけ、更新を手伝います。
私の役割
私のアイデアです。デザインも開発もしています。
プラグマティズムの父にちなんだ名前です。私たちもその考え方で作っています。
peirce.app →
tan.ai に聞く