# プラットフォーム 方法論の製品化からアプリ接続、契約・開通、継続運営まで。統一 ID、ライフサイクル、商用利用権、許可された接続で独立 SaaS の運営全体を支える仕組みをご紹介します。 > Runlume はプラットフォーム機能、独立業務アプリ、専門サービスを必要に応じて組み合わせて提供します。機能、上限、納品範囲は選択したプランや合意条件に従います。公式アプリは個別に選べ、横断連携は接続設定と許可境界を守ります。 元のページ: https://runlume.app/ja/platform ## システムは独立し、責任は明確に。 役割の模式図です。基盤は共通機能を接続し、各システムが業務とデータを担います。同じ DB への集約は接続条件ではありません。 ### 業務システム 業務フロー、業務権限、独立 DB。計画に応じて PC や指定クラウドで稼働できます。 ### Runlume プラットフォーム 統一 ID・組織、契約利用権、開通、明示許可、稼働記録。 ### 導入・運用担当 通信、バックアップ・復旧、監視、安全更新、障害対応の責任を確認します。 ## 画面で見る、共通の管理基盤。 組織ディレクトリと許可設定は別の役割です。組織関係だけで業務データのアクセス権は付与されません。 ### 組織構造 本部、部門、職務、所属の模式図です。架空のメンバーを使用し、個人情報は含みません。 ### 機能の許可 機能とアクセス範囲の例であり、許可済み・実行済みを示しません。 ## 環境はお客様が選び、データは許可に沿って流れる。 計画に応じ、要件を満たす PC、自社サーバー、指定クラウドに独立 DB とともに配置できます。接続してもデータの帰属は変わらず、共通接続で ID、組織、契約利用権、連携機能を使えます。 ### 企業の導入環境 システムと DB は合意した企業環境で稼働します。手法、顧客資料、業務記録は各システムで維持し、場所、管理者権限、保存期間を計画に明記します。 ### Runlume プラットフォーム 統一 ID、接続、契約利用権、制御された連携を担当します。業務 DB の統合は求めず、必要な ID 対応、状態、使用量、呼び出し記録を処理します。 ### エージェントと外部機能 許可済み API でタスクを処理し、外部モデルやサービスは選択した計画でのみ接続します。項目、受領者、用途を明確にし、接続を全データの開放と解釈しません。 ### 機能をつなぎ、データ境界を保つ 例えば CRM と注文は許可 API で必要な顧客参照と注文情報を交換し、それぞれ DB と権限を維持します。要求と応答は呼び出し経路を流れるため、データ範囲・ネットワークアクセスのレビュー対象です。 ### データ保護を、アクセスと納品の各段階に。 #### データの帰属と自主的な管理 お客様の業務データの帰属は、配置場所やプラットフォームへの接続によって移転しません。合意に従って保存、バックアップ、エクスポート、削除を管理し、外部アクセスの許可範囲を決定します。システム移行やサービス終了時は、納品に関する合意に従ってデータを処理し、アクセス権限を取り消します。個人情報や第三者データについては、対応する権利と利用制限も遵守する必要があります。 #### テナント分離と最小権限 アカウント、インスタンス、役割で検証し、システムを明示的に紐付け、タスクに必要な範囲のみ公開します。専門家、開発者、FDE、利用者にも職務に合う権限を付与します。 #### AI 呼び出しも制御対象 タスクを組み立てられても管理者権限は得られません。テナント、機能、データの許可を守り、重要変更をレビューします。外部 AI 利用前に送信内容、規約、処理範囲を確認します。 #### 安全な運用と処理の追跡 重要操作・呼び出し記録で経過を追い、通常ログにキーや機密ペイロードを露出させません。導入ではアクセス、転送保護、認証管理、復旧、更新責任を定めて検証します。 #### プライベート納品と License 管理 License の発行、照会、導入登録、取消しを提供し、版、環境、導入数・業務インスタンス数、期限を明確にします。検証部品を組み込んだ業務システムが公開鍵で署名と条件をローカル検証します。導入許可は契約利用権やデータ権限を代替せず、オフライン時の状態更新と納品範囲は契約で定めます。 ### FDE が導入と安全要件を納品に組み込む。 業務整理から機密データ、役割、外部呼び出しを特定し、企業 IT、専門家、開発者と構成、許可リスト、検収例を確認します。公開はアクセス可能なだけでなく、運用引き継ぎ、復旧、継続支援範囲も含みます。 ### ローカル導入ならデータは一切外に出ませんか？ そうとは限りません。業務データをローカル保存しても、統一 ID、連携、通知、外部 AI は必要情報を処理する場合があります。導入前に経路と用途を列挙し、機密データの送信項目と受領者を制限します。 ### ローカル導入後は完全オフラインで使えますか？ 独立デプロイは全機能のオフライン対応ではありません。基盤認証、利用権確認、外部機能には接続が必要です。社内アクセス、通信要件、オフライン機能は選定・導入時に個別確認します。 ### ローカルシステムのデータ保護は誰が担いますか？ 企業は基盤環境と許可人員、提供者はアプリ権限と保守、納品チームは設定・検証・引き継ぎを契約に従って担当します。Runlume は基盤側を管理しますが、ローカル環境にも継続した安全運用が必要です。 ## 企業の方法論を製品化 Runlume は専門家、エンジニア、業務ユーザーをつなぎ、企業の手法、知見、規則を動くソフトウェアにします。FDE が現場で要件を共同確認した仕様にまとめ、構築・検証・導入を推進。プラットフォームが接続、許可された連携、継続運営を担い、一度の納品を育ち続ける資産へ変えます。 ### 例えば、顧客フォローの手法をチームのシステムへ。 営業専門家がリード分類、対応間隔、注文引き継ぎを定め、FDE と現場利用者が実情を確認して仕様・検収例を作成。エンジニアが CRM、注文、エージェントを接続して画面、フロー、許可済み呼び出しを実装します。日常の例外をもとに FDE が規則の調整とバージョン更新を促し、個人の知見をチームで再利用できる手法へ育てます。 ### 業務を知る人、技術を知る人、使う人が、ひとつの場で協働。 FDE は単なる伝言役ではなく、実業務に寄り添い、専門家の手法、実装、利用者の声を同じ仕様と納品目標に揃えます。Runlume が構築から運営まで共通基盤を提供します。 #### 分野の専門家 なぜこの業務をこう進めるのか？ 業界知識、経営経験、判断基準を明確にし、フロー、規則、例外を定め、手法の正しさを確認します。 蓄積するもの：業務手法、規則、検収基準 #### ソフトウェアエンジニア どうすれば手法が確実に動くのか？ 仕様をシステム、API、自動フローに変え、品質、テスト、デプロイ、保守性を担います。AI を開発効率向上に活用します。 蓄積するもの：システム、API、テスト、バージョン #### 業務ユーザー 実際の仕事で役立つか？ 実際のタスク、環境、制約を共有し、試用と検収に参加。日々の声と業務結果で課題を解決できているか確認します。 蓄積するもの：実例、利用者の声、結果 #### FDE が業務理解から実装まで伴走 要件確認、試作検証、導入接続、公開後の振り返りまで三者を調整し、課題、仕様、実装、意見の対応を保ちます。実装にも参加できますが、専門家の判断や利用者の検収を代替しません。 ### Runlume が FDE に適している理由 #### 業務手法を共通仕様に 目標、フロー、データ、権限、検収条件で三者をつなぎ、説明と実装のずれを減らします。手法も版を重ねて改善できます。 #### 機能を再利用し、業務固有の価値に集中 ID、ライフサイクル、契約利用権、共通機能はプラットフォームが担います。FDE と開発者は業界ルールと重要フローに集中し、運営基盤の重複構築を減らせます。 #### 独立した環境でも連携できる 独立稼働・プライベート導入に対応し、統一接続と明示許可で機能とデータをつなぎます。エージェントは許可範囲で横断タスクを実行します。再利用するのは機能であり、無制限のデータ共有ではありません。 #### 納品後も、運営を続けられる 検収、バージョン、開通、サービス利用権をつなぎ、利用者の声を規則と仕様へ戻します。許可された手法、システム、機能の再利用から製品を育て、適合する業務を広げます。 経営の手法を、自社のソフトウェア資産に。 ### 1. 経営手法を整理 専門家が手法と判断根拠を示し、利用者が実際のフローと例外を補い、FDE が目標と優先順位を揃えて暗黙知を議論できる業務定義にします。 目標、フロー、ルール ### 2. 構造化仕様を作成 FDE が専門家・エンジニアと Blueprint / Spec に整理し、データ、権限、入出力、検収条件を明確にして、業務判断と実装の共通根拠を作ります。 Blueprint / Spec ### 3. 業務システムを構築 エンジニアが AI を活用して画面、フロー、API を実装し、FDE が業務上の意味を継続確認します。既存アプリと基盤機能を再利用して重複開発を減らします。 システムと変更セット ### 4. 検証してバージョンを公開 業務サンプル、権限境界、検収条件で結果を検証し、変更をレビューしてバージョンと公開記録を残します。 検収とバージョン ### 5. 接続して継続運営 ID、アプリ開通、契約利用権、許可された連携を接続し、社内利用を支え、製品化サービスの納品範囲も明確にします。 アプリとサービス ### 6. 結果から手法を改善 利用者の声、業務成果、例外をルールと仕様へ戻し、納品で終わらず次の改善につなぎます。 フィードバックと次の版 業務責任者が手法と検収基準を確認し、AI が構築・実行を支援します。重要変更はレビューを経て、呼び出しはテナント、データ、許可の境界を守ります。 方法、コード、データ、成果物の帰属と利用範囲は合意で確認します。業務データは各許可境界内に留まり、顧客を跨ぐ再利用はデータや専有知識の複製を認めるものではありません。 ## [Runlume エージェント · 統合アシスタント](https://runlume.app/ja/apps/agent) Runlume エージェントは、プラットフォーム公式の統合アシスタントです。テナントの許可範囲内で、保有するシステムの機能とデータを利用し、業務の背景を理解して自らタスクを処理し、実行結果まで継続して確認します。 ## システムは独立し、通信とデータは共通仕様で。 入口の接続だけでなく、認証、API、データ記述、イベント伝達を規定します。公開標準に基づく契約で異なる技術スタックをつなぎ、個別接続での重複説明・変換を減らします。 ### 標準化された通信・イベント契約 HTTP/JSON で呼び出し、OpenAPI で要求と応答、OIDC/OAuth 2.0 で認証とサービス許可、CloudEvents でイベントを統一形式にします。統一とは通信仕様の共有であり、同じ開発言語への変更ではありません。 - バージョン管理された API で入力、出力、エラー、互換要件を明確にします。 - イベント ID、出所、種別、業務ペイロードで変化を記述し、配信記録と冪等処理で連携を追跡します。 - 呼び出しとイベント購読はいずれもアカウント、インスタンス、機能許可に従い、標準プロトコルでも権限検証を省きません。 接続には API 対応、版の検証、許可設定が必要です。標準化は任意システムの無改修接続や、イベントの一度限り・即時配信を保証しません。 ### データ形式を整え、分析を支援 JSON Schema で交換項目、型、検証ルールを記述し、API・イベント契約で版、出所、文脈を明確にします。一貫した入力で変換・整理を減らし、許可された集約、ビッグデータ分析、横断指標比較の基盤にします。 - 統一するのは交換形式と記述ルールで、各システムは固有モデルと独立 DB を維持します。 - 分析前に意味、期間、単位、指標定義を揃え、構造の一致と業務上の意味の一致を区別します。 - 許可用途に必要な項目を選び、品質、保存期限、必要な匿名化処理を実施します。 標準で顧客データを集約したり、テナントのデータを統合したり、データウェアハウスを自動構築したりするものではありません。ツール、範囲、計算は個別設定し、結果は品質と手法に依存します。 ## 独立システムから、事業として運営できる SaaS へ。 技術接続、商取引、アプリ稼働を別々にせずつなぎ、各段階に対応する ID、状態、責任を明確にします。 ### 1. 定義と接続 システムを独立してデプロイし、アプリ情報、API、イベント、必要権限を宣言して、プラットフォームが理解できる接続契約を作ります。 アプリ契約 ### 2. 検証と公開 ID、分離、ライフサイクル、API 互換性を検証・審査し、公開とバージョンを明確に対応させます。 バージョンと審査 ### 3. 商品とプランを構成 製品機能をプラン、機能利用権、リソース枠に整理し、購入・利用範囲を明確にします。 サービス範囲 ### 4. 契約と開通 選択した契約に基づき利用権とインスタンスを作り、顧客アカウント、業務スペース、アプリ入口を接続します。 サブスクリプションとインスタンス ### 5. 許可と連携 接続するシステムと機能を選択。エージェントもシステム間連携も、テナント、インスタンス、利用権、許可の境界内で実行します。 許可された接続 ### 6. 運営と改善 使用量、呼び出し、稼働状況、業務の声をもとに、更新契約、問題対応、次の版の改善を支えます。 稼働とフィードバック これは製品運営の流れであり、コードの自動生成やホスティングの流れではありません。接続、公開、商取引は公開機能とサービス合意に従います。 [関連記事：Vibe Coding から製品運営へ](https://runlume.app/ja/developers#vibe-to-business) ## 業務を支えるプラットフォーム機能 手法の実装から継続稼働までには共通基盤が必要です。Runlume は ID・組織、ライフサイクル、契約、接続、共通機能、安全管理をつなぎ、各システムの独立した発展と秩序ある協働を支えます。 ### 統一された ID と組織構造 一度のログインで、利用できるアプリを明確に。 統一 ID は全員への同権限付与ではなく、アカウント、チーム、アクセス関係の共通の起点です。初回ログインで自動的にアカウントを作成でき、別の登録入口は不要です。 - 共通窓口で認証し、許可された業務アプリへ進みます。 - 会社、部門、チーム、メンバーの所属を一元管理します。組織ディレクトリを採用したシステムは、許可に従い組織関係と変更を読み取って重複管理を減らせます。組織関係は業務権限の検証を代替しません。 - プラットフォームのログインアカウント、所属アカウント、インスタンスを区別し、ひとつの ID を全業務スペースの権限とみなしません。 - プラットフォームがアプリアクセスを管理し、顧客・注文などの閲覧範囲は業務アプリが検証します。 #### 業務シーン CRM と注文アプリには同じ ID で入れますが、特定顧客の閲覧や注文変更は各アプリの業務権限で決まります。 #### 機能の範囲 ログイン成功は全アプリの開通や全データ権限の保有を意味しません。 ### アプリの開通とライフサイクル 開通から終了まで、各アプリの状態を明確に。 単なるリンクではなく、インスタンスを軸に継続利用を管理します。開通、停止、再開、終了を合意した API で業務システムに実行させ、状態を記録します。 - アカウントのアプリインスタンスと各システムのワークスペースを対応付けます。 - 状態に基づいてアクセスを制御し、利用可、処理中、停止中を明確にします。 - 時間のかかる操作や失敗の状態と後処理の根拠を残し、要求送信を完了と誤認しません。 #### 業務シーン CRM 開通時はプラットフォームがインスタンスを作り、CRM が業務スペースを作成して結果を返します。結果が条件を満たしてから利用可能になります。 #### 機能の範囲 開通は開発者のコードホスティングやサーバー構築の代行ではありません。終了時のデータ処理はアプリとサービスの合意に従います。 ### サブスクリプション課金と利用権 購入内容と、使える範囲をつなぐ。 プラン説明、契約状態、機能権限、リソース枠を揃えます。商用ルールをインスタンスに反映し、現在有効な権利に基づく提供を支えます。 - 製品、プラン、契約で購入関係を管理し、公式5アプリを標準で一括販売しません。 - 機能の利用可否とリソース量を区別し、機能スイッチと消費枠を混同しません。 - 有効な権利、実使用量、請求記録を結び、更新、上限管理、利用確認の根拠にします。 #### 業務シーン 契約にはアプリ機能と一定のリソース枠を含められます。アプリが業務を実行し、基盤が付与範囲と使用量根拠を管理します。価格と枠は正式プランで決まります。 #### 機能の範囲 登録だけで全アプリが無料になるわけではありません。プラン、枠、課金、返金は正式な公表内容に従います。 ### アプリ連携と機能の共有 業務はつなぎ、データはそれぞれに。 システムは許可された接続で直接機能・データを交換でき、毎回エージェントを経由する必要はありません。エージェントも同じ機能契約で連携します。基盤は誰が誰のどの機能を、どのテナント・権限で呼べるか管理します。 - 接続側が API・イベントを宣言し、呼び出し側は許可された機能のみ使います。 - 同一アカウント内に明示的なアプリ紐付けを作り、API 追加や権限拡大で許可が自動拡張されることはありません。 - 制御された呼び出しとイベント配信で連携を記録し、各システムが自身のデータと重複要求を処理します。 #### 業務シーン CRM と注文は公開・許可済み機能で連携できます。CRM が顧客参照を渡し、注文システムが注文規則と履行データを担います。フローは公開 API によります。 #### 機能の範囲 業務 DB の共有、アカウント間の既定共有は行わず、横断トランザクションや全フロー即時同期も約束しません。 ### AI と共通機能 共通の技術機能を、アプリごとに作り直す必要はありません。 ID と契約に加え、AI、通知、ファイルなども必要です。基盤が接続と利用ルールを提供し、業務アプリが具体的な活用方法を決めます。 - モデル接続、利用範囲、枠、呼び出し記録を一元管理し、アプリはプラットフォームのモデルキーを保有する必要がありません。 - 通知は宛先と配信状態で管理し、発火時点と受信者は業務システムが決めます。 - ファイル等はインスタンスと許可範囲で接続し、利用可能な機能は公開カタログに従います。 #### 業務シーン コンテンツアプリは許可範囲で AI を制作支援に使い、自身のフローで審査・公開できます。AI は責任や公開権限を代替しません。 #### 機能の範囲 基盤 AI とアプリ独自 AI は課金経路が異なります。共通機能があっても AI が許可を迂回して全業務データを読むことはできません。 ### セキュリティと運用統制 アクセス、許可、変更のすべてに境界を。 アプリが増えるほど一貫した統制が必要です。アカウント、インスタンス、権限、状態、記録を関連付けますが、各システムのデータ保護責任は代替しません。 - アカウントとインスタンスで分離し、ID と呼び出し文脈は検証済み認証情報に基づきます。 - 許可、契約利用権、状態で実行可否を決め、ログイン ID は全 API への通行証ではありません。 - 重要操作と呼び出しを記録して経過を確認できます。秘密の認証情報や業務ペイロードは通常ログに出力すべきではありません。 - プライベート納品では License で版、環境、数量、期限を定め、導入許可、契約利用権、業務アクセス許可を別々に管理します。 #### 業務シーン 停止や接続取消し後のアクセス・呼び出しには再び制約を満たす必要があります。問題は操作・呼び出し記録をたどって調査できます。 #### 機能の範囲 統一管理はゼロリスクや認証取得を意味しません。各アプリはローカル権限、データ分離、保存規則を実施する必要があります。 ## プラットフォームとアプリの役割 ### ID とアクセス - Runlume: 共通認証、メンバー関係、アプリ入口 - 業務アプリ: ローカルユーザー対応、業務役割、データ権限 ### 開通と運営 - Runlume: 契約利用権、インスタンス状態、操作追跡 - 業務アプリ: 業務スペース作成、個別機能、サービス納品 ### データと連携 - Runlume: 機能契約、明示的許可、交換記録 - 業務アプリ: 独立データベース、ドメイン規則、データ品質 ## プラットフォーム接続とデータを、さらに詳しく。 ### 統一ログインですべてのアプリとデータにアクセスできますか？ いいえ。共通のログイン窓口を提供しますが、アプリ利用には所属アカウント、開通済みインスタンス、許可が必要です。アプリ内の顧客・注文データは各システムが業務権限を検証します。 ### 通信プロトコルの統一には同じ技術スタックが必要ですか？ いいえ。HTTP、OIDC、OpenAPI、JSON Schema、CloudEvents などの契約で ID、API、イベントを交換します。各システムは言語、フレームワーク、データベース、デプロイを維持し、接続範囲に応じて対応できます。 ### データ形式の統一はシステム横断分析にどう役立ちますか？ 項目の説明、型、検証ルールを揃えることで変換や整理を減らせます。ただし分析前に意味、単位、期間、指標定義を揃え、用途に応じた許可を得る必要があります。形式の統一は自動集約や分析結果の保証を意味しません。 ### 交換形式を統一するとデータベースも共有する必要がありますか？ 不要です。統一するのは API の交換・記述ルールで、各システムは固有のドメインモデルと独立データベースを維持します。許可済み API で必要情報を交換し、共通 DB や横断クエリで接続契約を代替しません。 ### プライベート導入の License とサブスクリプションの利用権はどう違いますか？ License はソフトウェアをその環境で利用する資格を検証し、製品、バージョン、環境、デプロイ ID、数量、期限を制約できます。サブスクリプションは購入機能とリソースを決めます。どちらもログイン ID、インスタンス権限、システム間接続許可を代替せず、License があっても全業務データにはアクセスできません。 ### ソフトウェア更新や License の期限切れにはどう対応しますか？ 更新前に対象バージョン、環境、規模が許可範囲か確認し、必要なら延長や再発行を行います。失効の影響、更新手順、保守は納品条件で定めます。SDK は公開鍵でローカル検証できますが、オフライン検証は外部サービスのオフライン動作や、切断環境への即時失効通知を意味しません。 ## 関連ページ - [公式アプリ](https://runlume.app/ja/apps) - [開発者](https://runlume.app/ja/developers) - [Runlume について](https://runlume.app/ja/about)