AIの出力は、毎回変わる
精度の問題ではない。同じプロンプトでも結果は揺れる。その揺れを受け止める設計がなければ、利用者が増えるほどシステムは不安定になる。
設計判断LLMの出力は「信用しない」が前提。検証を通ったものだけが、システムの内側に入る。
経営で言うと同じ質問に違う答えを返す窓口を、顧客の前に置かないということ。
demiruDemiru / 共通技術基盤tenant isolation/authz/audit log/ai boundary
AIは、信頼できる設計の上で動く
AIは、動き続けてからが本番だ。
01 / なぜ崩れるのか
崩れる理由は、
設計にある。
AIサービスが本番で崩れるとき、原因は精度ではない。 データの境界・権限の判断・変更への耐性—— これらは、最初の設計で決まる。
そして、それが今の問題になった。モデルの世代交代が半年周期になり、 作り直しの費用が毎年発生するようになった。 PoCから本番運用へ移ったことで、求められるものが精度から継続稼働へ変わった。
データの境界は、意図しないと消える
複数の顧客データを一つのDBで管理するとき、クエリの書き方一つで他社のデータが返る。「たぶん大丈夫」は、設計ではない。
設計判断データの境界は、アプリの注意力ではなくDB層で強制する。書き忘れが、事故にならない構造。
経営で言うと他社の情報が見えた、という事故が起きない構造にするということ。
権限の判断は、散らばると壊れる
機能が増えるたびに「ここでも権限チェック」を書き足していくと、条件が矛盾し、抜け穴が生まれる。誰が何をできるかは、一箇所で決めるべきだ。
設計判断「誰が・何に・何をできるか」の判断は、実行直前の一点に集約する。散らばった条件は、いつか矛盾する。
経営で言うとアルバイトが経理を操作できてしまう、が起こらないということ。
AIモデルの進化が、システムを壊す
モデルを差し替えるたびに呼び出し元が壊れる。それはAIの問題ではなく、AIとビジネスロジックが直結している設計の問題だ。
設計判断AIとビジネスロジックは直結させない。間に契約を挟めば、モデルは自由に進化できる。
経営で言うと新しいAIが出るたびに作り直す費用が、発生しないということ。
Demiruの答え
これらはすべて、設計で解決できる問題だ。 機能を積む前に、テナント分離の経路・認可の評価点・変更の契約・AI出力の境界を定義する。 Demiruはその設計を、複数のサービスで共有できる実装として提供する。
02 / 実際に動いているサービス
同じ基盤が、
4つのサービスで動く。
業種が違っても、データ境界と権限管理の実装は同じコードが動いている。 これが、設計の信頼性の証明だ。
LINE Marketing
musubica
LINEを使ったマーケティング基盤とミニアプリの構築・運用。
Clinic Management
shinq
整体師・鍼灸師・個人院向けの予約システムと運用サポート。
Facility Operations
golf
シミュレーションゴルフ施設の予約・決済・運用管理。
Personal App
gym
個人向けトレーニング日誌アプリ。日々の記録と継続をサポート。
次のサービスへ
土台は一つ。業種を問わず広がる。
自社開発 4 サービス稼働中—受託・パートナー向けに展開中
なぜ広がり続けられるのか
守るべき実装を一度だけ正しく書く。 それが次のサービスの速度になる。
90%+
基盤コード共有率
4つのサービスで、コードの9割が同じ。認証・認可・テナント分離・監査ログ——これらは一度だけ正しく作った。デザインも例外ではない。Webサービスの画面パターンは有限だから、業種を跨いで共通化できる。各サービスが書くのは、その事業にしかないロジックだけ。
例：クリニック管理 shinq — テナント分離・監査ログは基盤側の実装をそのまま利用
3日〜
新サービス立ち上げ
毎回ゼロから作らないから速い。速いだけでなく、同じ基盤を使うから同じ品質が保証される。AIモデルの差し替えも、ビジネスロジックへの影響は0行。速さと安全は、トレードオフではない。
例：簡単な構成なら数日。フル構成のゴルフ施設運営 golf でも、基盤接続から公開まで3週間
4業種
同一基盤で稼働中
LINE・クリニック・ゴルフ施設・個人アプリ。業種が変わっても、テナント分離と認可のコードは一行も書き分けていない。
例：マーケティング／医療／施設運営／パーソナル——全て同一の認可コード
この基盤の上で、次のサービスを動かす。導入相談・パートナー提携・詳細資料。初回のご相談は無料で、営業のご連絡はしません。
相談してみる03 / 信頼の構造
信頼の根拠は、
構造にある。
「信頼できる」とは、何かが起きたときに証明できることだ。 データの境界・権限の判断・実行の記録—— これらを構造として持つことが、信頼の根拠になる。
全レイヤーにテスト変更のたびに自動検証。壊れたら即検知
モデル差し替え：影響0行AIを常に最新に。最適なモデルとトークン量で、利用コストも最小にOpenAIClaudeGemini
操作の記録は改変不可「あのとき何が起きたか」に常に答えられる
データ境界
誰のデータかを、保存・取得・表示のすべての経路で評価する。アプリが壊れても、DBレイヤーで境界が守られる。「たぶん大丈夫」を設計に持ち込まない。
認証と権限
誰が何をできるかを、実行直前の一点で決める。機能が増えても、権限の判断は散らばらない。抜け穴は、分散から生まれる。
実行記録
何が起きたかを、後から証明できる形で残す。AIが関与した操作は、モデル版と入出力のハッシュを記録する。本文そのものは持たないので、証明はできても情報は増えない。「たぶんこうだった」では、信頼は成立しない。
常に最新のAI
OpenAI、Anthropic、Google——最適なモデルは半年で変わる。Demiruの基盤はAIをアダプター経由で接続しているため、ビジネスロジックに触れずにモデルを差し替えられる。さらに処理ごとに最適なモデルとトークン量を選ぶため、AIの利用コストは常に最小に保たれる。
AI境界
LLMの出力は、そのままビジネスロジックに渡せない。検証・型変換・フォールバックを挟む境界層が、AIの非決定性をシステムの外側に閉じ込める。
テスト
基盤のすべての層にテストが書かれている。認可ルール・テナント分離・AI境界・監査ログ——変更を加えるたびに自動で検証が走り、壊れたら即座に検知する。「たぶん動いている」ではなく「証明できる」状態を維持し続ける。
04 / Stack
技術選定の根拠
「なんとなく使っている」技術はない。各選定には、テナント分離・認可・AI境界という設計原則に対する明確な理由がある。
TypeScript型安全な境界契約
PostgreSQLRLSによるDB層テナント分離
Row Level Securityクエリ単位のデータ境界
JWT / JWKSステートレス認証・鍵ローテーション
ZodLLM出力のスキーマ検証
Reactサーバー描画と再利用を同じ型で通せる
tRPC型安全なAPI契約
Drizzle ORM型付きクエリとマイグレーション管理
Cloudflare WorkersHyperdrive経由の接続。テナント設定はトランザクション内のSET LOCALで、プールを跨がせない
OpenAI / Anthropicアダプター層経由で差し替え可能
05 / Architecture
共通基盤の構造
各サービスはPort（インターフェース契約）を通じて基盤に接続する。実装の詳細を隠蔽し、モデルの差し替え・機能追加を自由にしながら、安定を保つ。
06 / For Business
経営の言葉に、
翻訳すると。
ここまでの設計の話は、経営では3つの数字になる。 かからない費用・待たない時間・負わないリスク。
コスト
作り直しの費用が、消える。
AIシステムの本当のコストは初期開発ではなく、崩れたときの作り直しにある。認証・権限・データ境界を基盤側で持つため、機能追加やモデル更新のたびにゼロから作り直す費用が発生しない。AIの呼び出しも処理ごとに最適なモデルとトークン量を選ぶため、ランニングコストまで安い。
基盤コード共有率 90%+
スピード
アイデアから稼働まで、最短数日。
土台が完成しているから、作るのは事業固有のロジックだけ。新規事業の検証も、既存業務へのAI導入も、市場の変化を待たせないスピードで形になる。
新サービス立ち上げ 最短3日
リスク
「何かあったとき」に、答えられる。
情報漏洩・誤動作・説明責任——AI導入の経営リスクは「起きたときに証明できないこと」だ。すべての操作が改変不可の記録として残るため、顧客にも監査にも、事実で答えられる。
アプリ経路からの記録改変：不可
07 / Process
頼むと、何が起きるか。
相談から稼働まで、進め方はシンプルだ。費用と期間は設計の段階で確定し、以降のサプライズはない。
- 01
相談
無料いまの課題・やりたいことを伺う。AIが適さない場合は、適さないとはっきり伝える。売るための提案はしない。
- 02
設計
数日〜2週間何を守り、何を自動化するかを定義し、データ境界・権限・AI境界を含む設計書を提示する。この時点で費用と期間が確定する。
- 03
構築
3日〜実証済みの基盤の上に、事業固有のロジックだけを実装する。進捗は随時共有し、動くものを見ながら調整する。
- 04
稼働・改善
継続公開して終わりではない。モデルの更新・機能の追加・運用の改善を、基盤の安定性を保ったまま続ける。
関わり方は、3つ。
新規サービス開発
アイデアを、基盤の上で最短距離で形にする。POCから本番運用まで一気通貫。
新規事業を立ち上げたい経営者向け
既存業務へのAI導入
いまの業務システムに、安全なAI機能を組み込む。データ境界と記録は基盤側が保証する。
社内DX・業務効率化を進めたい企業向け
技術パートナーシップ
継続的な開発体制として並走する。設計判断から運用まで、技術側の意思決定を担う。
技術責任者が不在・不足している組織向け
費用は「設計」の段階で、範囲と期間とともに確定額を提示する。 月額の保守契約を前提とした囲い込みはしない。基盤が安定しているから、それが可能だ。
08 / Demiruについて
動き続けるAIは、
偶然では生まれない。
Demiruがつくるのは、AI機能のカタログではない。 データの境界・権限の判断・実行の記録—— これらを構造として持つ共通基盤だ。
機能を積む前に、何を守り、どう証明するかを決める。 テナント分離の経路、認可の評価点、監査ログの構造、AI境界。 設計書の上ではなく、実装として。
派手な機能より、崩れない構造を選んだ。信頼は、後から追加できない。だから最初に設計する。
Demiruの共通基盤は、AIサービスを支える「共通の実装」を提供します。認証・認可・テナント分離・監査ログ・AI境界——一度だけ正しく実装したコードを複数のサービスで共有することで、新しいサービスの立ち上げを最短3日まで短縮しながら、同じ品質を保証します。
AIを活用したサービスの共同開発、既存事業へのAI機能の組み込み、基盤技術の提供など、事業の形に応じたご相談を受け付けています。まずは課題をお聞かせください。
Demiruのエンジニアが向き合うのは、機能の実装ではなく構造の設計です。RLSによるデータ境界、一点集約の認可評価、不変の監査ログ、LLMの非決定性を閉じ込める境界層——複数のサービスが依存する基盤を、TypeScript / PostgreSQL / tRPC / Cloudflare Workersで設計・実装します。
自分の書いたコードが複数のサービスの信頼性を支える。その責任と面白さに惹かれる方と、お話ししたいと考えています。
Demiruの強みは、基盤の再利用によるスケールです。コードの9割が共通基盤に乗るため、サービスを増やすほど1件あたりの開発コストが下がり、品質は落ちません。顧客を月額で囲い込むのではなく、作るたびに安く速くなる構造で伸ばします。すでに4業種の自社サービスが同一基盤で稼働しており、この構造の再現性を検証しています。
事業計画・技術デューデリジェンスに必要な資料をご用意しています。面談のご希望はお問い合わせフォーム、またはメールでご連絡ください。