ainは、AIを「支援機能」ではなくヒューマン従業員と同列の運用主体（AI従業員）として扱うAI Employee SaaSです。 自社サービス（Looma／Musvi／Formula／Facetなど）および外部SaaSと連携し、業務フローの自動化とAI従業員の運用を一体で提供します。

ainの目的は、AIに文章を作らせることではなく、業務を標準化フローとして資産化し、ワークスペース上で「会話 → 決定（合意） → タスク → データ」へ確定反映させることです。これにより、業務の引継ぎ単位を「作業」から「ポジション（職務）」へ引き上げます。

AI従業員が「人員」として成立する4条件

1. コンテキスト：組織／タスク／データ／登録済みナレッジを正として参照できる
2. 権限：許可された範囲で行動できる（ヒューマン権限の継承）
3. 確定反映：成果が運用オブジェクトとして確定・追跡できる
4. 統制：承認を組み込み、安全に運用できる

本マニュアルの構成

• 主体・権限の管理（CommonAuth）
• プラン・契約・課金（Hub）と運用導線（Portal）
• 組織・プロジェクト・タスク（Looma／Formula）と会話・合意（Musvi）
• ワークスペースとAI従業員（Ain）、成果物・ファイル基盤（Facet）
• AI Employee Marketplace（職務テンプレ流通／計画）

ainは CommonAuth で認証・主体同定を行い、 AI従業員を例外化せずヒューマンと同じ主体モデルで扱います。これにより、AI専用の権限体系を増設せず、 組織が慣れているヒューマン向け権限設計をそのままAI従業員へ適用できます。

主体の種別

• ヒューマン：従業員、契約者、ゲスト等
• AI従業員：Ain が管理する実行主体（職務テンプレ・実行ポリシー付き）

権限の階層（業務側の認可）

1. 契約単位（Hub）：契約者、コラボレーター、ゲスト
2. 組織・役割（Looma）：オーナー、管理者、メンバー、職務（ジョブ）と責任範囲
3. プロジェクト／タスク（Formula）：管理者、アサイニー、レビュアー
4. 成果物・ファイル（Facet）：閲覧／編集／削除権限、機密区分
5. ナレッジ（Knowledge Base／計画）：閲覧権限とAI利用可否を分離して管理

運用上のポイント

• AI従業員の許可範囲も既存の認可・permission checkの上で評価される
• 承認や監査ログは「ドラフト→承認→確定反映」の標準動作に統合
• 未登録のファイルや Wiki ページは、正式なAIの参照対象から構造的に除外される

プラン・契約・課金のSSOTは Hub が担います。 ainの課金は「席課金」「AIクレジット」「アドオン（定額／従量）」の三層で構成し、各サービスの利用量を Metering Exporter で集約し、Stripe決済に反映します。

プラン体系（案）

• Standard：個人事業主／小規模（〜10名）。ドラフト生成＋承認後確定反映（制限あり）。コア機能。
• Business：小〜中堅（10〜100名）。承認後確定反映＋運用強化。権限・組織運用。
• Enterprise（将来）：大企業。SSO／統制／拡張アドオン。個別見積。

価格前提（初期案）

• 席単価：¥1,980／席・月（税別）
• 平均席数：5席／契約（初期想定）
• AIクレジットARPA：¥1,000／契約・月（Phase 4以降に増加見込み）
• アドオン：外部連携パック、追加容量、自動承認枠（審査あり）等
• トライアル：N日間、AIクレジット限定枠、トライアル中はプラン変更・アドオン購入を制限

プラン作成・運用の流れ（Backoffice）

1. Hub Backoffice の「プラン管理」を開く
2. 「新規プラン作成」または既存プランを選択
3. 課金方式（席／クレジット／アドオン）、トライアル、利用可能機能を設定
4. 保存すると即時有効化（非アクティブ状態での保存も可能）

メータリング対象（例）

• AI：推論回数、トークン消費、エージェント同時実行、ジョブ数
• 連携：コネクタ利用、APIコール、転送量、同期頻度
• ストレージ：容量、保持期間（Facet）
• ナレッジ／RAG：Embedding、索引更新、権限付き検索クエリ

契約・請求・入金管理は Hub と Stripe を一体で運用します。継続バッチによりプラン契約の延長・終了処理を 実行し、利用量集計と請求を整合させます。

契約ライフサイクル

1. プランを選択（Standard／Business）
2. 契約期間・更新方式（自動／手動）を指定
3. 申込・承認フロー（自動／手動承認）を経て契約成立
4. Portal からアプリ起動・メンバー招待を実施し、運用開始
5. 継続バッチで契約延長／終了を判定

決済失敗時の運用

• 督促 → 一定期間後の利用制限 → 入金後復旧を標準化
• 未回収リスクを抑制し、キャッシュフローの安定を確保

返金・解約条件

• 料金ページと約款で返金・解約条件を明示
• 即時解約／期日指定解約／猶予期間付き解約に対応
• 解約後のデータ保持期間は事前確認のうえ運用

よくあるミス

• トライアル設定漏れによる即時課金
• アドオンの上限制御未設定による粗利圧迫
• Metering Exporter 連携漏れによる請求不整合

ainの業務運用は Looma（組織・役割・承認）、Formula（プロジェクト・タスク・ワークスペース）、Musvi（会話・合意）の3サービスで構成されます。AI従業員はそれぞれの「正」を参照し、 職務単位で業務を進めます。

Looma：組織・役割・承認のSSOT

• 組織ツリー、職務（ジョブ）、責任範囲、承認ルールを正として保持
• 人事ERP領域（任用・異動・評価、勤怠・労務、給与の前提情報）の母体
• AI従業員に「どの役割として、どの責任範囲で働くか」を提供

Formula：プロジェクト／タスク／ワークスペース

• タスクを運用オブジェクトとして正規化（担当・期限・完了条件を必須化）
• タスクに紐づくワークスペースで成果物（文書／表／CSV等）を作成・更新
• アサイニーは ヒューマン または AI従業員 から選択

Musvi：会話・合意の着地点

• 会話を決定事項（合意）として固定化し、後続のタスク／データへリンク
• AIの提案が「決定」として残り、追跡可能な状態になる

標準化フローの運用

1. 業務を標準化フローとして登録（手順・完了条件・成果物形式・承認・権限を型化）
2. 案件／プロジェクトを立ち上げ、標準化フローからタスクを生成
3. タスクをAI従業員またはヒューマンに割り当て
4. ワークスペースで成果物を作成・更新
5. 承認を経て成果物とタスク状態を確定（Musviで合意を固定化）
6. 実行履歴を蓄積し、同型業務へ再利用

Formulaのワークスペースは、タスクに紐づく作業空間です。AI従業員は Ain の管理下で実行ポリシー・ 利用可能ツール・承認要否を持ち、ワークスペース上でドラフト作成や更新提案を行います。承認後に 成果物とタスク状態が確定反映されます。

ワークスペースの構成要素

• 参照コンテキスト：組織（Looma）／タスク（Formula）／合意（Musvi）／データ（Facet）／登録済みナレッジ（KB）
• 成果物：文書／表／CSV／設計メモ等。フォーマットと完了条件（DoD）を定義
• 実行主体：ヒューマン または AI従業員
• 承認：ドラフト → 承認 → 確定反映の標準動作
• 履歴：実行履歴・会話履歴・成果物バージョン

AI従業員の運用

• Ain が AI従業員・ツール・実行ポリシーを管理
• ain起点のオーケストレーションで Musvi／Formula／Facet／Wiki／KB／ERPモジュールを横断利用
• 権限・承認・監査ログは横断的に統制
• 共通LLM（common-llm）経由で推論・Embedding・与信を整合

コンテキスト参照の原則

• AIはすべてを読まず、タスクキー（組織ID／プロジェクトID／タスクID／ラベル／機密区分）に基づき必要分のみ参照
• 未登録のファイル／Wikiページは正式なRAG入力にならない（ドラフトとの混線を防止）

ainは「保管・執筆できているのにAIが参照できない／参照できすぎる」状態を避けるため、ファイル・Wiki・ ナレッジを同一の権限境界で扱いつつ、責務を分離します。

Facet：オブジェクト／データ統合基盤

• 業務・アップロード由来のオブジェクトストレージ（Intake／Object・ブローカ経由のread/write/list）と台帳
• 分析向けレイヤ（Data Product／DWH／カタログ等）へ接続するデータプラットフォーム
• Musviの添付、Formulaワークスペースの成果ファイルなどを同一ポリシーで扱う

Wiki（計画）：構造化ページ

• スペース・ページとして、手順・仕様・議事録・運用ノウハウを構造化して執筆・閲覧
• KBへの登録導線とFacetファイル・権限モデルと整合

Knowledge Base（計画）：登録・索引・RAG

• ファイル・Wikiページを Candidate／Document として登録
• メタデータ・機密区分・AI利用可否・状態（レビュー／承認）を管理
• 権限フィルタ付きの検索／RAG API を提供
• 未登録コンテンツは業務ナレッジおよび正式なエージェントRAGの対象外

外部連携

• 外部ストレージ（Google Drive、SharePoint 等）
• 外部DB／DWH（Snowflake、BigQuery、MySQL 等）
• 連携は ain 起点で呼び出し、AI従業員による遂行とヒューマンによる統制を中心に設計

AI Employee Marketplace は、AI従業員（役割・ワークフロー・権限プリセット）を流通させるための基盤です。 「AI従業員で構成される会社」を再現可能な型として展開し、標準化フロー自体を社外へ提供・流通させることを 目的としています。リリースは 2027/2 を予定（マーケットプレイス開始フェーズ）。

流通対象

• 職務テンプレ（AI従業員）：役割・責任範囲・許可ツール
• ワークフロー（標準化フロー）：手順・完了条件・成果物形式・承認
• 権限プリセット：ヒューマン権限をそのまま継承する設定群

公開範囲

• 非公開（自組織内のみ）
• 限定公開（特定組織・パートナー契約）
• 完全公開（誰でも利用可能）

運用

• Marketplace手数料（流通額 × 手数料率）として収益化
• 改訂配信・バージョン管理に対応
• 利用状況・評価をダッシュボードで確認

よくある質問

• Q: 小規模（2〜10名）でも効果がありますか？
  A: はい。Phase 1の主戦場として想定し、標準化フローとワークスペース、ドラフト→承認→確定反映の流れを 最短で価値到達できるように設計しています。
• Q: AI従業員専用の権限設計は必要ですか？
  A: 不要です。CommonAuth で主体を同定し、Loomaの権限体系をそのままAI従業員へ適用します。
• Q: 既存のERP／PM／RPAと競合しませんか？
  A: ainは標準化フローとAI従業員運用、確定反映を中核に据え、外部システムとは統合レイヤ経由で連携します。 ain起点で呼び出し、AI従業員が業務を遂行、ヒューマンが統制する設計です。
• Q: AIがアクセスして良い情報の範囲は？
  A: 既存の認可・permission checkを共有し、未登録のファイル／Wikiページは正式なAI参照対象から 構造的に除外されます。Knowledge Base 経由で登録・承認・AI利用可否を統制します。
• Q: 提供開始時期は？
  A: 2026年Q2に MVP（コア認証 + Hub/Portal 最小セット）を提供開始。Looma、Facet、ain（AI従業員）、 データ基盤、AI Employee Marketplace（2027/2）まで段階リリースを予定しています。

運用のコツ

• 導入初期は標準化フローのテンプレを活用し、カスタマイズは段階的に行う
• AI従業員の参照コンテキストはタスクキーで限定し、情報過多による誤判断を抑える
• 成果物フォーマットと完了条件（DoD）を早期に固定し、レビュー効率を高める
• 高リスク操作には承認を強制し、低リスク領域から段階的に自律度を上げる
• クレジットとアドオンの上限制御を設定し、粗利と推論コストを管理する