顧客から届くセキュリティ質問書に、一度答えるだけで済むように。
顧客データを扱う企業はみな、同じ依頼を繰り返し受ける。セキュリティ質問書、プライバシー評価、ベンダーリスク審査、調達デューデリジェンス、エビデンス要求だ。ほとんどの組織は手作業で回答している——顧客から届いたスプレッドシート、ポリシーのフォルダ、メールのスレッド、そして前回何と回答したかという誰かの記憶に頼って。
CAOSはこれをシステム・オブ・レコードに変える。質問書は構造化された回答可能な作業になる。完成した回答とコンプライアンス文書は、検索可能で引用可能なコーパスになる。次の質問書は、あなたがすでに述べた内容から始まる。すべての主張は、その出どころである文書または過去の回答にトレースできる。
セルフホスト型である。あなたのポリシー、回答、顧客の質問書は、すべて自社のインフラ上に留まる。
ステータス: v0。 CAOSは本番環境で稼働しているが、このリポジトリは公開されたばかりだ。インターフェース、スキーマ、設定はまだ流動的である。外部からのコントリビューションはまだ受け付けていない——コントリビューションを参照。
推測せずに質問書を読み取る。 顧客のXLSXをアップロードすると、CAOSはそれを忠実に描画する——シート、行、セル、非表示列、入力規則のドロップダウンまで。次に、どの行が回答可能でどのセルを埋めるかを、1つずつではなく範囲単位でマークする。顧客ごとのパーサーは存在しない。標準がないからだ。太字の行が質問であることも、空白の列が回答先であることもある。あるワークブックでは正しく機能するヒューリスティックも、別のワークブックでは自信満々に間違える。
完了済みの作業からコーパスを構築する。 質問書をクローズすると、その回答済みの行が再利用可能なQ&Aとして公開される。アップロードしたポリシー、認証、レポートは、引用可能なパッセージになる。どちらも不変にバージョン管理される。そのため、前四半期に送信した回答は、当時最新だった文書に照らして説明が成立する。
正しい過去の回答を見つける。 検索は、語彙検索と意味検索を同時に実行し、ランキングを融合して、上位候補を再ランク付けする。コンプライアンスの言語には両方が必要だ。埋め込みがぼやかしてしまう「SOC 2 Type II」のような正確なトークンと、キーワード検索では完全に見逃される言い換え表現の両方が。
根拠付けされた回答を下書きする。 任意機能。モデルは、境界が設定され許可リスト化されたツールを通じてコーパスを検索し、引用付きの回答を下書きする。さらに、その根拠の出所を示すラベルを付ける：Knowledge grounded、Mixed、General guidance、Based on current answer。General guidanceの回答は、自社について何ら主張せず、その旨を明記する。
Google Chatで回答する。 /cisoスラッシュコマンドは、同じ根拠付けされたコーパスにアクセスし、Webアプリ内の永続的な会話へのリンクを返す。
顧客自身のワークブックに書き出して返す。 回答は、元のファイル構造の中の、マッピングしたセルに書き込まれる——CAOS流に整形した近似物ではない。
すべてを記録する。 追記専用の監査ログは、データベースで強制される不変性を持ち、回答値の正確な変更前・変更後を保持する。
CAOSは9つのドメインモジュールで構成されている。そのうちの3つ——Evidence、Knowledge、Tasks——はグローバルだ。プロジェクトに所有されるものではなく、その価値はエンゲージメントを横断することにあるからだ。
| モジュール | 所有 | ドキュメント |
|---|---|---|
| Identity | 認証モード、セッション、ロール、ユーザー、外部サブジェクトのバインド | ドキュメント |
| Projects | エンゲージメントのコンテナ; クローズカスケード | ドキュメント |
| Questionnaires | ワークブック読み取り、行マッピング、回答ワークスペース、エクスポート | ドキュメント |
| Evidence | 再利用可能なコンプライアンス成果物のグローバルリポジトリ | ドキュメント |
| Knowledge | ソース、パッセージ、埋め込み、検索、除外、引用 | ドキュメント |
| AI | CISO会話、生成、根拠付けラベル | ドキュメント |
| Chat | Google Chat検証、アイデンティティバインド、配信 | ドキュメント |
| Tasks | モジュール横断で要求される人手の作業 | ドキュメント |
| Audit | 追記専用のイベントログ | ドキュメント |
Internet
│
┌─────┴─────┐
│ nginx │ TLS · static frontend · /api proxy
└─────┬─────┘
┌──────────────┼──────────────┐
│ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴──────┐
│ Frontend │ │ API │ │ Taskiq │
│ React │ │ FastAPI │ │ workers │
│ static │ │ :18800 │ │ │
└───────────┘ └─────┬─────┘ └─────┬──────┘
│ │
┌─────┴──────────────┴─────┐
│ │
┌─────┴──────┐ ┌──────┴─────┐
│ PostgreSQL │ │ Redis │
│ pgvector │ │ queue+cache│
└────────────┘ └────────────┘
│
┌─────┴─────┐
│ Providers │ Bedrock · local models · Google Chat
└───────────┘
バックエンド — Python 3.12+、FastAPI、SQLAlchemy 2 async、pgvector付きPostgreSQL、Redis、Taskiqワーカー。各モジュールはdomain → application → infrastructure → presentationに分割され、一方向の依存関係を持つ。domainは何にも依存しない。
フロントエンド — React 19、TypeScript、Vite、Tailwind v4、shadcn/ui、Zustand。アプリ全体のセッションとシェル状態はsrc/appに、フィーチャーとサーバーキャッシュの状態はフィーチャーストアに、長時間実行されるページのワークフローはフィーチャーコントローラーに置く。
両方の検索チャネルはPostgreSQL上にある。 独立したベクターデータベースはない——ストアが1つであることは、トランザクション境界が1つであり、バックアップも1つであることを意味する。
外部ベンダーは距離を置いて接続される。 すべての統合は、Platform Protocol（CAOSが製品言語で期待するもの）、Adapter Protocol、Vendor Implementation——SDKをインポートする唯一のレイヤー——に分離される。これが、埋め込みと再ランク付けが固定されたローカルモデルまたはBedrock上で実行され、どちらを使用しているかをアプリケーションコードが認識しない理由だ。
文書が検索可能になる。 アップロード → 不変バージョン → 永続的な取り込みジョブ → コミット → ワーカーへのディスパッチ → 各1,500文字以内のパッセージを抽出（それぞれが引用ロケーターを保持：PDFページ、DOCX段落、XLSXシート/行/セル）→ 埋め込みを生成 → 検索可能。ジョブはディスパッチ前にコミットされるため、キュー障害は、見えない保留行ではなく、目に見える再試行可能な状態になる。
質問書が回答作業になる。 アップロード → 忠実な行ビュー → 行と回答先をマッピング → 回答可能な行ごとに1つのワークスペース項目（それぞれが正確なソースセルを指す）→ ドラフトの自動保存 → 期待リビジョンとのcompare-and-setによる明示的な完了。これにより、古くなったタブは、同僚の成果を上書きせずに409を受け取る。
完了した作業がKnowledgeになる。 質問書をクローズすると（または、それらすべてをクローズするプロジェクト）、回答済みの行が再利用可能なQ&Aとして公開される。未回答の行は何も公開しない。生のワークブックは決して取り込まれない——それは運用上の作業であり、根拠付けの材料ではない。
質問が根拠付けされた回答になる。 語彙検索と意味検索が並行実行される → Reciprocal Rank Fusionがそれらのランクを統合する → タグブースト → 除外フィルター → 上限50候補のウィンドウを再ランク付け → モデルが固定予算内で検索・調査・再検索を行う → 不変のソースバージョンを指す引用付きのドラフトと根拠付けラベル。
どの段階も、より弱いが正直なモードへと劣化する。再ランク付けが停止すれば融合順序のままで信頼度チップなし。埋め込みが停止すれば語彙検索へのフォールバックとなり、その旨が報告される。
詳細: データフロー
前提条件: Docker（Compose付き）。フロントエンド作業にはNode.js >=22.22.0とpnpm 11.9.0。バックエンド開発ではuvも使用する。
AWSアカウントもLLMプロバイダーも不要——生成はデフォルトでオフになっており、以下はすべてそれがなくても動作する。
git clone https://github.com/DigiCred-OSS/caos-os.git
cd caos-os/backend
cp .env.example .env
backend/.env内のBACKEND_USERS_SECRETプレースホルダーを、少なくとも32バイトのランダムな値で置き換える：
python3 -c 'import secrets; print(secrets.token_urlsafe(48))'
PostgreSQL、Redis、API、ワーカーを起動する。マイグレーションはmigratorサービスによって自動的に実行される：
cd backend && docker compose up --build
初回実行時には、固定されたモデルアーティファクト約500MBをダウンロードする。その後、APIはhttp://localhost:18800で、Swaggerは/api/docsで、PostgreSQLはホストポート15432で利用できる。
CAOSにサインアップページはない——ホストから最初の管理者を作成する：
./caos-cli user create-superadmin --email [email protected]
cd frontend && pnpm install && pnpm dev
http://localhost:5173を開く。
フロントエンドとAPIの両方で一貫して
localhostを使用すること。セッションCookieはホストスコープなので、localhostと127.0.0.1を混在させると、セッションが静かに失われる——最も一般的なローカルセットアップの落とし穴だ。
次へ: はじめにチュートリアルが、ここから回答・エクスポート済みの質問書に到達するまでを解説する。
localがデフォルト（固定されたNomicとMiniLMクロスエンコーダーをイメージに組み込み）。本番環境ではAWS Bedrockがデフォルト。実行時にモデルをダウンロードすることはない。BACKEND_KNOWLEDGE_GENERATION_PROVIDERと_MODELの両方を設定すると有効になる。すべての設定はbackend/.env.exampleにインラインで文書化され、設定リファレンスにまとめられている。
cd backend && uv sync --locked
uv run ruff check caos
uv run mypy caos
cd frontend && pnpm install && pnpm lint && pnpm build
公開されているこのディストリビューションには、CAOSの内部テストスイートは含まれない。ここでの検証ゲートは、lint、型チェック、クリーンビルドだ。
マイグレーション作業は、Alembicを直接呼び出さず、すべて./caos-cliを使用する——正しい環境、コンテナ、データベースを選択してくれる。