Otter Beam Workspace でのデータの流れ

Otter Digital Pte. Ltd. · 2026年10月17日更新

Otter Beam Workspace は、Sales & CRM、調達・購買、プロジェクト管理を、会社自身のコンピュータ上の 1 つの会社データベースにまとめます。あるモジュールで起きたことを別のモジュールが知る必要があるとき、Otter Beam が自動で引き継ぎます。これをハンドオフと呼びます。このページでは、すべてのハンドオフについて、何が起点になるか、何を作成・変更するか、何もしないのはどんなときか、完了できないときはどうなるかを説明します。

すべてのハンドオフの動作

同じ瞬間に、同じデータベースで。ハンドオフは、それを起こした操作と同じデータベーストランザクションの中で実行されます。両方とも保存されるか、どちらも保存されないかのどちらかで、中途半端な状態が見えることはありません。
あなたの操作は必ず反映されます。ハンドオフ自体が完了できない場合（たとえば仕入先が保留中）でも、それを起こした操作は保存されます。見積書の承認は、後続の処理が失敗しても承認のままです。失敗したハンドオフだけが単独で取り消され、報告されます。
記録者は "Otter Beam" です。ハンドオフが作成・変更するレコードは、人でもエージェントでもなくシステムが書き込み、すべての変更は変更前／変更後の値とハンドオフ番号（F1～F8）をメモとして監査ログに残ります。
Data health で確認できます。実行のたびに、OK、Skipped（やることなし）、Failed のいずれかが正確な理由とともに記録されます。Failed の場合はエラーも作成されます。原因を直したあとは Data health から再試行でき、再試行では未完了の部分だけが実行されます。エラーは解決済みにできます。
連鎖には上限があります。1 つのハンドオフが次のハンドオフを起こすことがあります（承認された見積書が受注を作り、受注がプロジェクトを作る、など）。連鎖は 4 ステップで止まるため、設定ミスで無限ループになることはありません。
再入力は不要です。作成された明細はすべて元の明細にひも付いているので、見積書から最後の入金まで、数量・価格・進捗をたどれます。

販売の流れ

#	起点	動作内容	何もしないとき	失敗するとき
F1	リードが転換された	リードに顧客がなければ顧客（法人または個人）を作成し、リードに担当者の記載があれば主担当者を作成し、その両方に紐づく商談を作成します。リードは「転換済み」になります。	—	レコードを作成できません（理由は Data health に表示されます）。
F2	見積書が承認された	次の受注番号で確定済みの受注を作成し、見積書の全明細と現場の住所をコピーします。見積書は転換済み、商談は受注（成約）になります。変更の見積書の場合は、元の受注に明細を追加して合計を更新します。	—	受注を作成できません。見積書は承認済みのままです。
F3	受注が確定された（F2 によるものを含む）	注文にプロジェクトを起こす品目があれば、プロジェクト（予算はその明細の小計）と、プロジェクトテンプレートに基づくタスクを作成します。日付は順番に並び、タスク間は完了後開始の依存関係になります。	注文にプロジェクトの対象品目がない、またはすでにプロジェクトがある場合。	使えるプロジェクトテンプレートがありません。受注は確定のままです。
F8	入金が確定・割り当て・取消された、または請求書が発行・取消された	影響を受けるすべての請求書と仕入先請求書の支払済み・未払いの金額を再計算し、一部支払済み／支払済みに更新します。受注の "Invoiced x% · Paid y%" と発注書の支払ステータスも更新されます。確定した支払いだけが対象です。	この入金は、まだどこにも割り当てられていません。	—
—	明細のない受注から請求書が作成された	内容をあらかじめ入力します。通常の請求書は未請求の数量をコピーし、前受金・出来高の請求書は合意した割合の明細を 1 行追加して、過去の請求分を差し引きます。	—	—

調達の流れ

#	起点	動作内容	何もしないとき	失敗するとき
F4	プロジェクトに対して購買依頼が作成された	依頼をプロジェクトに紐づけます。価格なしで追加された明細には、優先仕入先の前回価格（優先仕入先がない場合は把握している最安値）が入ります。	—	—
F5	購買依頼が確定された	依頼を仕入先ごとに 1 件の発注書（下書き）へ分割し、価格は各仕入先の前回購入価格を使います。すべての明細が発注書に入ると、依頼は「発注済み」になります。	—	仕入先が保留またはブロックされている、または明細に仕入先がない場合（"Vendor Tampines Paint & Coatings is on hold."）。ほかの仕入先の発注書は作成され、"Retry later" では不足分だけが作成されます。
F6	入荷が登録された	受け取った数量を発注書の明細に加算し、発注書を一部入荷／入荷済みに更新します（"Received 90%"）。	—	—
F7	発注書から仕入先請求書が作成された、その明細が変わった、または確定された	発注書から仕入先請求書の内容をあらかじめ入力し、請求された数量と単価を受け取った内容と照合します（3点照合）。結果は、一致、数量の不一致（"Qty mismatch: billed 40, received 38"）、単価の不一致、未入荷のいずれかです。確定すると、請求済みの内容を発注書に記録します。	—	—

プロジェクト

起点	動作内容
タスクが開始された	依存するタスクがまだ終わっていない間は実行されません（"Waits for: Site survey"）。
依存関係が追加された	ループが発生する場合は実行されません。
タスク、割り当て、見積り、記録した工数のいずれかが変わった、または F3 がタスクを作成した	影響を受ける各メンバーの今後数週間分の週次負荷を再計算し、Workload ビューでは割り当て過多が赤で表示されます。

AI エージェントにできること、できないこと

エージェントがデータベースに直接書き込むことはありません。人と同じルール（同じ検証、同じハンドオフ、同じ監査ログ）を通る構造化されたリクエストを送るだけです。作成した下書きは、承認されるまで業務に影響しません。会社として確定する操作（確定、送信、支払い）は承認カードで待機し、オーナーが、たいていはスマホから承認または却下します。エージェントの読み取りは、構造化された読み取り専用のクエリに限られます。個人情報（担当者やスタッフの氏名、メールアドレス、電話番号）を含む回答にはその印が付き、エージェントには目の前の作業にだけ使うよう指示されています。