System × Design × AI

自社でSaaSをつくる
会社が、つくります。

We Build Our Own.
Then We Build Yours.

Toysmithは東京のシステム開発会社です。
大手のSEチームが引くべき設計を、小さなチームで、短期間で。
既製品に業務を合わせるのではなく、「こうしたい」をそのまま作ります。
自社でSaaSを5本。その設計と基盤を、そのまま持ち込みます。

Toysmith is a system development studio in Tokyo.
The architecture you'd normally hire a large SI firm for — delivered by a small team, fast.
We don't bend your work to fit off-the-shelf software; we build what you actually want.
Five SaaS products of our own — and the foundations behind them come with us.

相談するGet in Touch 開発実績を見るSee Our Work
パステルカラーの遊園地のような風景。Toysmithのメインビジュアル
PROBLEM

頼む先が、
どこにもない。

Nowhere
To Turn.

大手に見積もりを取ると、数千万円・数ヶ月。小さい案件はそもそも受けてもらえない。
予算に合う相手に出すと、動くものは来る。ただし設計がなく、2年後に作り直しになる。
だから多くの業務が、今もエクセルと手作業のまま残っています。

Ask a large SI firm: tens of millions of yen, several months — and small projects get declined outright.
Go with whoever fits the budget: you get something that runs, but with no architecture. Two years later you rebuild.
So the work stays where it is — in spreadsheets, done by hand.

LARGE SI
大手
Too Big
数千万円
数ヶ月
小案件は断られる
Tens of millions
Several months
Small jobs declined
?
ここが空いている
The Gap
NO VENDOR HERE
BUDGET SHOP
予算優先
No Design
動くものは来る
設計がない
2年で作り直し
It runs
No architecture
Rebuild in 2 years
SOLUTION

その谷を、
埋めます。

We Fill
That Gap.

本来なら大手のSEチームと組んで作るべき設計を、小規模・短期で成立させます。

安いから雑、ではありません。理由があります。
Toysmithは自社でSaaSを5本立ち上げており、そこで作った設計と基盤を、そのまま案件に持ち込んでいます。計算ロジックや権限設計、印刷まわりの実装は、毎回ゼロから書いていません。だから小さく速いのに、設計が崩れないんです。

We deliver the architecture you'd normally need a large SI team for — at small scale, in a short timeframe.

Not cheap-and-rough. There's a reason.
We've launched five SaaS products of our own, and we bring that design and those foundations straight into client work. Calculation logic, permission models, print output — we don't write them from scratch every time. That's why it stays small and fast without the architecture falling apart.

01

欲しい形を、そのまま

Exactly What You Want

既製のパッケージやSaaSに業務を合わせるのではなく、「こうしたい」をそのまま形にします。使わない機能にお金を払う必要も、業務のほうを曲げる必要もありません。

Instead of bending your work to fit a package, we build the thing you actually described. No paying for features you never use, no reshaping the job around the tool.

02

設計から引きます

We Start at the Architecture

「何を作るか」が決まっていない段階から入ります。要件が固まっていないことは、依頼を断る理由になりません。

We come in before the spec exists. An unfinished requirement is not a reason for us to decline.

03

2年後に作り直さない

Built Not to Be Rebuilt

その場で動くものではなく、業務が変わっても直せる形で作ります。

Not something that merely runs today — something you can change when the business changes.

WORKS

自社でSaaSを
5本。

Five SaaS Products.
All Ours.

受託案件の実績ではなく、自社で企画から運用まで手がけたプロダクトです。設計の判断をすべて自分たちで引いているので、そのまま設計力の証明になります。

Not client project credits — products we planned, built, and operate ourselves. Every architectural decision is ours, which makes them direct evidence of what we can design.

Official Release iOS / Web / Android (Internal)
LINQS

アーカイブはいらない。会話はナマモノだ。

No Archives. Conversation is Live.

過去の記録ではなく「今この瞬間」の熱量を語る、立場表明型のSNS。承認欲求とAIによるノイズを削ぎ落として、トピックそのものと向き合う対話空間をつくりました。

A stance-based SNS built around present-moment intensity rather than archived history. We stripped out social validation and AI noise to leave a space where the topic itself is the point.

AIによる議論鋳造
AI-Forged Debates
Geminiがニュースを2択の論点へ変換
Gemini turns news into binary debate topics
爆速無限フィード
Blazing Infinite Feed
100枚を瞬時に描画する超軽量設計
Ultra-light rendering: 100 cards, instantly
ARCHITECTURE
3プラットフォーム同時展開。ネイティブ2種とWebで同じデータモデルを共有しています。
Three platforms at once — two native clients and web, sharing one data model.
SwiftUI / Kotlin Compose / React 19 (Vite) / Firebase / Gemini 2.0 Flash
linqs.jp →
LINQS のアプリ画面
Official Release Web / SaaS
Chrona

日程調整の往復を、なくす。

No More Scheduling Ping-Pong.

「候補日を出す → 返事を待つ → もう埋まっていた」をなくす日程調整サービス。全員一致・予約受付・出欠確認・予定出しという性質のちがう4つの調整を1つのツールにまとめ、使い分けのために別のサービスを契約しなくて済む形にしました。

A scheduling service that removes the "here are some times / let me check / that one's gone now" loop. Four different kinds of coordination — consensus, bookings, attendance, and proposals — in one tool, so you don't subscribe to three.

相手の負担はゼロ
Zero Effort to Reply
登録もアプリも不要。URLを開くだけ
No account, no app — just open the link
カレンダーはそのまま
Keep Your Calendar
Google/Outlook と連携。乗り換え不要
Works with Google and Outlook as-is
ARCHITECTURE
Google OAuth の審査を通した本番連携。他人のカレンダーを預かる前提で、取得する権限を最小限に絞って設計しています。
A production Google OAuth integration, reviewed and approved — scoped to the minimum, because we hold other people's calendars.
React / FullCalendar / Firebase / Google Calendar API (OAuth) / Outlook
chrona.jp →
4 WAYS, ONE TOOL
全員一致
Consensus
全員の空きが重なる日を出す
Find the slot everyone shares
予約受付
Bookings
前後の移動時間まで押さえる
Holds travel time around it
出欠確認
Attendance
来る/来ないを集計する
Tally who's coming
予定出し
Proposals
こちらの空きを書き出して渡す
Hand over your open times
Official Release
Cartful

受注から発送まで、ひとつの流れに。

From Order to Shipment, One Flow.

screen capture
cartful.tokyo

デジタル無線機レンタル事業の、受発注・在庫・発送を回す業務システム。決済(Square)、配送伝票(ヤマトB2)、帳票PDF、QRコードでの機材管理までを1本に繋ぎ、手作業で受け渡していた工程をなくしました。

The operational backbone for a digital radio rental business — orders, inventory, and shipping. Payments (Square), shipping labels (Yamato B2), PDF documents, and QR-based equipment tracking all connect into one flow, removing the hand-offs that used to be manual.

外部サービス3系統との連携と、在庫の整合性を同時に成立させる設計。まさに大手のSEチームが引く領域です。
Three external integrations and inventory consistency, held together at once — exactly the territory a large SI team would own.
Firebase / Square / ヤマトB2 / PDF帳票 / QR / Excel出力
cartful.tokyo →
In Development NDAにより詳細非公開 Details under NDA
Cuesheet

現場の進行表を、紙とスマホと会場に同時に。

One Run Sheet — On Paper, On Phones, On Screens.

abstract diagram
one sheet → A3 print / phone / signage
no screenshots (NDA)

イベントの動静表(進行スケジュール)をWeb上で複数人が同時編集し、そのままA3縦の紙・現場のスマホ・会場サイネージへ出力するシステム。複数の会社が同じ案件に入る前提で、会社をまたいだ権限とデータの見え方を設計しています。

A run-sheet system for events: multiple people edit the schedule together on the web, and it outputs straight to A3 print, on-site phones, and venue signage. Built for projects where several companies work side by side, with permissions and visibility designed across company boundaries.

会社をまたいだ権限境界の設計。招待された側は無料で全機能を使える課金モデルも、この境界設計の上に成り立っています。
Permission boundaries that cross company lines — including a pricing model where invited collaborators use everything for free.
Firebase / Web (collaborative editing) / Print CSS
In Development 販売権利保有 Sales Rights Held NDAにより詳細非公開 Details under NDA
Rigdeck

見積を、プロダクトにする。

Turning Quotes Into a Product.

structure diagram
quote-domain core → internal app + SaaS
no screenshots (NDA)

イベントテクニカル業界向けの、見積作成と案件管理のプラットフォーム。計算エンジンと型定義を独立したパッケージとして切り出し、社内向けアプリと販売用SaaSの両方から同じ核を使う構成にしています。

A quoting and project-management platform for the event technical industry. The calculation engine and type definitions are split out as a standalone package, shared by both an internal application and a multi-tenant SaaS.

計算ロジックを独立パッケージに切り出しているため、1箇所直せば両方に反映されます。この「核の切り出し」が、Toysmithが小規模案件でも設計を落とさない理由そのものです。
Because the calculation logic lives in its own package, one fix lands in both products. This extraction of a shared core is exactly why we can keep architecture intact on small projects.
Monorepo / TypeScript / Firebase
5
自社プロダクト
Our Own Products
3
公開・運用中
Live in Production
3
対応プラットフォーム(iOS / Android / Web)
Platforms Shipped
2024
設立
Founded
AI INFRASTRUCTURE

AIが働ける状態に、
社内を整える。

Make the Company
Legible to AI.

AIが使えるかどうかは、AIの性能では決まりません。
AIが読める場所に、正しい形で情報があるかどうかで決まります。

同じ数字がスプレッドシートとチャットとメールに散らばっていれば、AIは毎回ちがう答えを返します。だから私たちは、まず「どれが正しいのか」を1つに決めるところから入ります。

Whether AI works for you is not decided by the model.
It is decided by whether your information sits somewhere AI can read, in a shape it can use.

When the same number lives in a spreadsheet, a chat thread, and an inbox, AI gives you a different answer every time. So we start by deciding which one is true.

01
正を1つに決める
One Source of Truth
台帳・案件・履歴の置き場所をデータベース1箇所に集約します。二重管理をやめないと、AIは何を信じればいいのか判断できません。
Ledgers, projects, and history collapse into one database. Until the duplicates are gone, AI cannot know what to trust.
02
見せる範囲を設計する
Decide What AI Sees
全部を渡すわけではありません。AIに見せるもの、見せないものを分け、誰がどこまで触れるかを権限として切ります。ここが最初に決まっていないと、あとから直せません。
Not everything gets handed over. We split what AI may read from what it may not, and cut permissions to match. Decide this late and you cannot fix it.
03
業務ルールをAI側に持たせる
Put the Rules in AI's Hands
「この案件はこう進める」「この判断はここを見る」を、AIが毎回読み込める形で置きます。人が毎回説明し直す必要をなくすところがゴールです。
"This is how this project runs," "this is what that decision looks at" — written where AI reloads it every session, so nobody re-explains it.
04
人が使う画面も渡す
Humans Get a UI Too
AI専用にはしません。同じデータを人がそのまま見て直せる管理画面まで含めて納品します。AIが止まった日に業務も止まる、という作りにはしません。
We don't build AI-only. The same data comes with a screen people can read and fix — so the day AI stalls, the business doesn't.
CASE — OUR OWN
まず自社でやりました。
We Did It to Ourselves First.

グループ会社の業務では、案件ルールや作業履歴が Google Drive のファイルとデータベースに二重に存在し、どちらが正しいのか分からない状態でした。AIに聞くたびに答えが変わる原因はそこにありました。

Firestore を唯一の正に決め、管理画面・対話型AI・Slack・メール巡回のすべてが同じデータベースを読む形に統合。ファイルでの二重管理を廃止しました。

In our group's own operations, project rules and work history existed twice — once in Google Drive files, once in a database — and nobody could say which was right. That was why AI kept changing its answer.

We made Firestore the single source of truth, and pointed everything at it: the admin UI, the conversational AI, Slack, and the mail patrol. The duplicate files are gone.

SINGLE SOURCE OF TRUTH
tasks
projects
companies
contacts
work_logs
emails
READ / WRITE BY
管理画面 / 対話型AI / Slack / メール巡回
Admin UI / Conversational AI / Slack / Mail patrol
TRUTH

AIは忘れるし、
あなたを超えない。

AI Forgets.
And Never Exceeds You.

昨日教えたことを、今日は全部忘れています。極めて優秀なのに、記憶がゼロ。だからAIには、渡すための「設計」が要ります。

そして、自分ができることを任せるのは速い。できないことを丸投げすると破綻します。「AIでHPを作って」では止まり、「FTPの転送設定を教えて」なら進む。差は、業務を知っているかどうかだけです。

Everything you taught it yesterday is gone today. Brilliant, with zero memory — which is why AI needs architecture handed to it.

And handing AI what you already know how to do is fast; handing over what you don't breaks. "AI, build me a website" stalls. "Show me the FTP settings" ships. The difference is knowing the work.

SESSION MEMORY
RULES.md
案件ルール
Project rules
TREE
フォルダ構成
Folder structure
LOG
作業履歴
Work history
POLICY
判断基準
Decision criteria
→ 全部消えました。だから設計が必要なんです。
→ All gone. That's why architecture matters.
SOLUTION

だから、
設計から引きます。

So We Start
With Architecture.

AIは忘れる。AIは使う人を超えない。
つまり、AIをどれだけ使っても「設計できる人間」の代わりにはならないということです。

AI forgets. AI never exceeds the person using it.
However much you use it, it will not replace someone who can design.

Toysmithがやっているのは、そこです。
何を作るかを決め、どう壊れないようにするかを決め、そのうえでAIを組み込んで作る。
自社プロダクト5本で、全部その順番でやってきました。

That's the part we do.
Decide what to build, decide how to keep it from breaking, then build it with AI designed in.
All five of our own products were built in exactly that order.

SERVICE

できること

What We Do

事業は2つです。システム開発と、AIでの社内環境整備。どちらも、既製品に業務を合わせるのではなく、御社の形に合わせて作ります。

Two lines of work: system development and getting your company ready for AI. Both shaped to how you work, not the other way round.

01
SYSTEM DEVELOPMENT

システム開発

System Development

欲しいものを、そのまま作る。
Built to Your Shape.

エクセルと手作業で回している業務を、そのまま置き換えられます。要件が固まっていない段階からご相談ください。権限設計・帳票出力・外部サービス連携まで含めて引き受けます。

A direct replacement for the work you run on spreadsheets and hand-offs. Bring it to us before the spec exists — permissions, printed documents, and third-party integrations included.

業務システムBusiness systems SaaS・自社プロダクトSaaS products モバイルアプリMobile apps 既存システムの作り直しRebuilds
受発注・在庫・案件管理・見積のような業務の中心を、外部連携やマルチテナントまで含めて設計します。
Order flow, inventory, project and quote management — designed through to integrations and multi-tenancy.
02
AI INFRASTRUCTURE

AIでの社内環境整備

AI Infrastructure

AIが働ける状態に、整える。
Make the Company Legible.

AIが使えるかどうかは、AIの性能ではなく、情報がAIの読める場所に正しい形であるかで決まります。正を1つに決め、見せる範囲を設計し、業務ルールをAIが読める形にするところまでを引き受けます。

Whether AI works for you is decided by your information, not the model. One source of truth, a decided boundary for what AI may read, and your working rules written where AI can load them.

情報の一元化One source of truth 公開範囲と権限の設計Access boundaries 業務ルールの実装Rules as data 人が使う管理画面Admin UI 製品へのAI組み込みAI in your product
製品へのAI組み込みも同じ考え方で。プロンプト設計・コスト設計・失敗時の代替動作まで設計します。
Product-side AI follows the same rule — prompt design, cost design, and fallback when it fails.
くわしく見る →See how →
PROCESS

相談から、
納品まで。

From First Call
To Delivery.

要件が固まっていない状態で構いません。むしろ、その段階からのほうが良いものになります。

You don't need a finished spec. Honestly, earlier is better.

01
相談
Talk
困っていることを聞かせてください。要件書は不要です。
Tell us what's not working. No spec document needed.
02
設計
Design
何を作るか、どこまでやるかを一緒に決めます。ここで見積もりが出ます。
We decide together what to build and how far to go. The quote lands here.
03
開発
Build
動くものを早めに出して、触りながら直します。
Something that runs, early — then we fix it while you use it.
04
運用
Operate
納品後も直せる形で渡します。運用も引き受けられます。
Delivered in a form you can keep changing. We can run it for you too.
COMPANY

会社概要

Company

Toysmith株式会社は、業務システムとSaaSをつくる会社です。自社プロダクトを5本立ち上げ、そのうち3本を公開・運用しています。設計の判断を外に出さず、企画から運用まで自分たちで引いているのが特徴です。

Toysmith Inc. builds business systems and SaaS products. We've launched five products of our own; three are live and in operation. We keep architectural decisions in-house — from concept through operation.

about visual
about-1.png
会社名Name
Toysmith株式会社
所在地Address
〒140-0013
東京都品川区南大井2-7-9 アミューズKビル2階
事業内容Business
システム開発(業務システム・SaaS・アプリ)/AIでの社内環境整備System development (business systems, SaaS, apps) / AI infrastructure
設立Founded
2024年2024
自社プロダクトProducts
LINQS/Chrona/Cartful/Cuesheet/Rigdeck
CONTACT

お問い合わせ

Contact Us

システム開発のご相談、お見積もりのご依頼など、お気軽にお問い合わせください。要件が固まっていない段階でも構いません。

For development inquiries, quotes, or anything else. An unfinished spec is fine.

  =