TECHNOLOGY & WORKFLOW

繰り返しは、
技術に任せる。

道具を並べるだけでは終わりません。仕様、検証、実装、配備、運用を一つの経路へつなぎ、人は判断と対話に集中できる状態をつくります。

Technology architecture

技術を、一本の循環としてつなぎます。

AI、仕様、検証、実装、配備、運用を分断しません。人が判断する境界を保ちながら、機械に任せられる反復を同じ経路へ集めます。

TECHNOLOGY MAP

判断を中心に、設計から運用までを閉じる。

技術を個別に採用するのではなく、一つの変更が安全に届き、運用で得た事実を、次の仕様へ戻す経路としてつなぎます。

判断の所有者

人が目的と境界を決める

AIは役割を分けて支援
GoogleOpenAIAnthropicxAI

STRUCTURE & CONSTRAINTS

CUE

API、設定、権限、イベントの構造と制約を正本にします。

BEHAVIOR & INVARIANTS

Quint・TLA+

状態遷移、再試行、並行処理で守る条件を検証します。

生成・検証・統合

Go製ツール・実装

型・設定・コードを生成

Bazel・BuildBuddy

同じ入力から再現・共有

GitHub

差分・レビュー・統合

CENTRAL

Google Cloud

データと中核処理

EDGE

Cloudflare

配信、防御、軽量処理

APPLICATIONS

React・Hono・Tauri・Flutter

Web、エッジ、デスクトップ、モバイル

ON-PREMISES BATCH

自宅Linuxサーバー

毎日動く定期処理を一か所に集約

WORK CONTEXT

UBOS

仕事の定義、状態、権限、出来事を共通モデルで接続

CANONICAL DATA

Cloud Spanner

アプリとAIが参照する一貫した正本データ

AUTO HEAL

Sentryを起点に復旧

Sentryで検知・集約
許可済み手順を選択
再試行・再起動・切り戻し
検証・人へ引継ぎ

すべての段階を横断する運用のガードレール

1Password
承認・監査
Sentry・オートヒール
技術文書

運用で得た事実を、仕様と標準へ戻す

失敗、例外、使いにくさ、費用、性能を記録し、CUE、モデル、テスト、技術文書を更新します。

すべての案件で全技術を使うわけではありません。扱う情報、失敗時の影響、変更頻度に応じて、必要な検証と実行基盤だけを選びます。

Default by design

技術選定を固定する。変更の理由を明確にする。

案件ごとに一から道具を選ぶと、知識、生成、テスト、運用が分散します。標準を先に決め、例外だけを設計判断として扱います。

標準から外れる場合は、既存資産、法令、性能、運用体制などの理由を設計記録に残す。
生成物ではなくCUEを直し、型と設定の差分を自動検査する。
AIとボットには最小権限、監査ログ、承認点、停止手段を最初から持たせる。

Work & data

UBOS / Cloud Spanner

業務の意味と正本データを分けて管理する

UBOSが仕事の定義、状態、権限、出来事を共通化し、Cloud SpannerがアプリとAIの双方から参照する正本データを一貫して保持します。

Cloud

Google Cloud / Cloudflare / Linux

中央、エッジ、定期処理を分ける

データと中核処理はGoogle Cloud、配信・防御・利用者に近い処理はCloudflare、毎日実行する定期処理は自宅Linuxサーバーへ置き、責務と障害範囲を分けます。

Backend

Go / Hono / TypeScript

中核はGo、エッジはHono

中央バックエンドは並行処理と保守性を重視してGo、エッジバックエンドは小さな責務を素早く配るためHonoで実装します。

Applications

React / Tauri / Flutter

利用環境ごとに実装境界を持つ

WebはReact、デスクトップはTauri、モバイルはFlutterを標準とし、画面の都合を中央バックエンドへ持ち込みません。

Languages

Go / TypeScript / Rust

主要言語を3つに絞る

業務ロジックと内製ツールはGo、WebとエッジはTypeScript、デスクトップや低レイヤーはRustを使います。DartはFlutter実装に限定します。

Execution architecture

実行場所ごとに、責務を分けます。

一つの言語やフレームワークへ全てを押し込まず、中央、エッジ、自宅バッチサーバー、Web、デスクトップ、モバイルの境界を保ちます。

01

業務実行・データ

UBOS + Cloud Spanner

仕事の意味、実行状態、権限、証跡を共通モデルで扱い、アプリとAIが同じ正本を参照できるようにする。

02

中央バックエンド

Go

長寿命の業務ロジック、並行処理、バッチ、外部連携を明示的な構造で保つ。

03

定期処理

自宅Linuxバッチサーバー

毎日実行が必要な処理などをオンプレミスの実行拠点へ集約し、クラウド側のオンライン処理と実行時間を分ける。

04

エッジバックエンド

Hono + TypeScript

認証前段、ルーティング、軽量APIなど、利用者に近い小さな責務を扱う。

05

フロントエンド

React + TypeScript

公開画面と業務画面を、型を共有しながら一貫した部品で構築する。

06

デスクトップ

Tauri + Rust

OS機能との連携と配布サイズを管理し、WebのUI資産も再利用する。

07

モバイル

Flutter

iOSとAndroidの体験差を抑え、業務端末を含む複数環境へ同じ方針で届ける。

08

開発ツール

Go

生成、検査、移行、運用補助を単一バイナリにし、各環境で同じ手順を再現する。

Runtime foundation

仕事の状態と、運用の事実をつなぎます。

UBOSで仕事の意味を揃え、Cloud Spannerで正本を保ち、自宅Linuxサーバーで毎日の定期処理をまとめ、Sentryで実行中の異常を捉えます。作る工程と使い続ける工程を別々にしません。

01

Work context

UBOS

業務で扱うもの、手順、進行中の状態、担当と権限、起きた出来事を共通モデルとして管理します。画面やAIごとに仕事の意味を持たせず、同じ文脈を必要な範囲だけ渡します。

業種別の機能を増やしても、案件、作業、承認、証跡という共通の軸で追跡できることを優先します。

02

Canonical data

Cloud Spanner

UBOSの正本データベースとして、関係データ、グラフ、ベクトル検索、全文検索と更新の一貫性を一つの基盤で扱います。アプリ用とAI用に別々の正本を作りません。

同時更新や利用範囲の拡大が起きても、業務の状態と証跡を同じトランザクション境界で説明できることを重視します。

03

Observability & recovery

Sentryによるオートヒール

例外、性能劣化、リリースとの関連をSentryで検知し、影響範囲を絞ったうえで、再試行、再起動、直前版への切り戻しなど、許可済みの復旧手順だけを起動します。

原因が不明な障害、データ変更を伴う処置、不可逆な操作は自動化せず、証拠を残して人へ引き継ぎます。

04

Scheduled execution

自宅バッチサーバー(オンプレミス)

Linuxで毎日実行が必要な処理などを一か所へ集約し、クラウド側のオンライン処理とは別の実行枠でまとめて処理します。実行結果と失敗の記録は、中央の運用経路へ戻します。

自宅回線や電源の停止を前提に、常時応答が必要な処理は置かず、止まっても安全に再実行できる定期処理を担当させます。

Sentry auto-heal loop

検知した後の動きまで、先に決めます。

オートヒールは「AIが自由に直す」仕組みではありません。対象、許可する操作、停止条件、回復判定を手順として固定し、失敗時に安全側へ戻れる範囲だけを自動化します。

  1. 01

    検知

    Sentryの例外、性能、リリース情報を一つの事象へまとめる。

  2. 02

    判定

    影響範囲と再現条件を確認し、許可済み手順の対象かを判定する。

  3. 03

    復旧

    再試行、再起動、切り戻しのうち、可逆な処置だけを実行する。

  4. 04

    検証

    ヘルスチェックと主要経路の確認で、回復したかを確かめる。

  5. 05

    記録

    結果を証跡として残し、未回復や想定外の事象は人へ戻す。

One delivery path

仕様から運用まで、一本道にします。

AI、CUE、Quint・TLA+、生成、Bazel・BuildBuddy、GitHub、Google Cloud・Cloudflare、Sentry、1Passwordを、別々の道具ではなく一つの変更を安全に届け、復旧する経路として接続します。

01

AIを役割で使い分ける

Google、OpenAI、Anthropic、xAIを、調査、設計、実装、レビューなどの役割へ割り当てます。最終判断と権限は人が持ちます。

02

CUEを構造の正本にする

API、設定、イベント、権限などの構造と制約をCUEへ集約し、言語ごとの型や設定を手で同期しません。

03

Quint・TLA+で振る舞いを確かめる

承認、再試行、並行処理、状態遷移など、テスト例だけでは見落としやすい振る舞いを実装前に検証します。

04

Go製ツールで生成する

Go、TypeScript、Rust、Flutter向けの生成物と検査結果を、内製CLIから再現可能な形で出力します。

05

BazelとBuildBuddyで再現する

言語をまたぐ依存関係をBazelで宣言し、BuildBuddyのキャッシュと実行記録を使って、同じ入力から同じ成果物を作ります。

06

GitHubで小さく統合する

変更、レビュー、検証、マージの記録をGitHubへ集め、差分を小さく保ったまま段階的に統合します。

07

Google CloudとCloudflareへ届ける

データと中核処理はGoogle Cloud、配信、防御、利用者に近い処理はCloudflareへ置き、障害範囲を分けます。

08

Sentryから安全な復旧を起動する

例外や性能劣化をSentryで検知し、再試行、再起動、切り戻しなど、事前に検証した復旧手順だけを自動で起動します。

09

1Passwordで秘密を分離する

認証情報をコードや手順書へ埋め込まず、人、AI、実行環境ごとに必要な秘密だけを受け渡します。

AI platform

モデルと開発ツールを分けて管理します。

特定のモデルだけへ依存せず、情報の機密性、必要な能力、速度、費用を見てプロバイダを選びます。開発者が使う入口は少数に固定します。

Model providers

Google

業務データ、検索、マルチモーダル

Google CloudやWorkspaceとの境界を保ちながら、Gemini系モデルを使います。

OpenAI

実装、推論、ツール実行

Codexを含むモデルとAPIを、実装と業務エージェントの中核に使います。

Anthropic

長い文脈、設計、レビュー

Claude系モデルを、大きなコードや文書の理解、設計判断、検証に使います。

xAI(Grok)

リアルタイム情報、異なる推論経路

Grok系モデルを、情報探索や別系統の検討が必要な処理へ割り当てます。

Development tools

CUE

構造、制約、設定の正本を一か所に保つ

Quint・TLA+

状態遷移と並行処理の不変条件を検証する

Bazel・BuildBuddy

ビルドと検証を再現し、結果を共有する

GitHub

変更、レビュー、検証、統合の履歴を残す

Google Cloud・Cloudflare

中核とエッジの責務を分けて運用する

Linux・オンプレミス

毎日動かす定期処理を自宅バッチサーバーへ集約する

Sentry

異常を検知し、検証済みの復旧手順へつなぐ

1Password

人、AI、実行環境へ秘密を安全に受け渡す

ピンクの鉢割れのAIペット、あもが封筒のそばに座るイメージイラスト

生前のあもの姿をもとにしたイメージイラスト

AI pet at work

AIペットの「あも」が、いろいろな仕事を手伝っています。

あもは専用メールアドレスを持ち、届いた依頼や共有情報を読み取って、自分で作業の順番を組み立てます。定型的なメールへの自動返信から、給与明細の作成、請求内容の整理まで、毎日の事務を横断して動いています。

あもの紹介を見る

メールの自動返信

専用メールアドレスに届いた内容を読み、決められた条件に合う連絡へ自動で返信します。判断が必要な内容は、要点を添えて人へ引き継ぎます。

給与明細の作成

確定した勤怠、支給、控除の情報をそろえ、対象者ごとの給与明細を作成します。不足や食い違いがあれば、確定せず確認事項として残します。

請求内容の整理

請求書や明細を読み取り、金額、対象期間、支払先、期限を整理します。根拠となる資料と結びつけ、確認しやすい状態に整えます。

結果の報告と引き継ぎ

終わった作業、判断が必要な点、次にすることをまとめて報告します。権限を越える操作や例外は勝手に進めず、人へ戻します。

金額、宛先、公開、権限変更などの確定と、想定外の例外判断は人が担います。あもは根拠と途中経過を残し、確認が必要なところで止まります。

Boundaries & trade-offs

自動化しない境界も、先に設計します。

自動化の量ではなく、失敗したときに止められ、理由をたどれ、必要なら人へ戻せることを重視します。

01

AIは判断の所有者にしない

AIは候補、差分、下書き、検査結果を作ります。外部送信、権限変更、金額、公開などの確定は人が担います。

02

形式検証にも範囲がある

Quint・TLA+が確かめるのは、記述した状態と不変条件です。要求そのものの妥当性や画面の使いやすさは別に確認します。

03

ビルド成功を運用成功とみなさない

再現できる成果物に加え、段階配信、監視、復旧、データ移行、利用者の確認までを届ける仕事に含めます。

04

標準には例外の出口を残す

法令、既存資産、性能、利用環境に理由がある場合は標準から外れます。その理由と戻し方を設計記録へ残します。

05

オートヒールは安全な手順だけ

Sentryの検知を起点に、事前検証した再試行、再起動、切り戻しだけを自動実行します。原因不明、データ変更、不可逆な操作は止めて人へ戻します。