OSS 審査が聞くことに、
そのまま答える。

どこで動き、何が外に出るか

ochakai は SaaS ではない。あなた自身の Google Cloud プロジェクトに Go バイナリ一つと Postgres をデプロイするもので、データが届く「ベンダー側」がそもそも存在しない。接続先はあなたのプロジェクト内の Google Cloud API だけで、テレメトリは無い — どこにも何も送信せず、送信しない設定というものも無い(送信するものが無いからである)。

保存先はあなたのプロジェクトの Cloud SQL(Postgres)と、ファイルは同じくあなたの GCS バケットである。ochakai は独自のストレージを持たないので、リージョン・暗号化・バックアップの方針は、あなたの既存の GCP 設定がそのまま効く。そしてナレッジは人質にならない: ベース全体が OKF v0.2 バンドル — git に置ける素の markdown と YAML — として丸ごと出て、求めれば消える (条件 C1)。

秘密情報ゼロと、認可の代わりにあるもの

API キーもパスワードもトークンも、発行するものが一つも無い。到達を決めるのは Cloud Run IAM、データベース認証は Cloud SQL IAM、チーム向け Web UI は IAP の背後に置く。これは設計記録を持つ決定であり (0003・0065)、本番が Google Cloud のみである理由でもある — 欠落ではなく決定である。

同じく意図して、concept 単位の認可は持たない: デプロイに到達できる者は読み書きでき、identity は権限として検査されるのではなく provenance として記録される。分離はデプロイ単位で行う — テナント・チーム・機密度ごとに別のインスタンスを立てる。一つ月約 $10 なので、これは現実的な答えである。concept 単位の権限がどうしても要るなら、ポジショニングのページがはっきり言っている: それは間違った道具である。

監査証跡

すべての書き込みに provenance が付く — 誰が書いたかは、認証された呼び出し元からの観測であって、呼び出し元が名乗った自称ではない。検証と却下は、actor と時刻を伴う台帳への追記であり、 concept への全変更はリビジョンとして残り、却下はその理由を保つ。到達そのものの記録はあなたの側にある — Cloud Run があなたのプロジェクトの Cloud Logging に残す。何を読み、何にアラートを張るかは運用ガイドが持っている。

サプライチェーン

イメージは SBOM と SLSA provenance をマニフェストに付けて ghcr.io/na0fu3y/ochakai に公開される。CI の workflow アクションはコミット SHA で固定され、バイナリは distroless/static 上の静的で trimmed-path な Go ビルドであり、govulncheck が CI で回る。デプロイしようとしているものは検証できる:

gh attestation verify oci://ghcr.io/na0fu3y/ochakai:<tag> -R na0fu3y/ochakai
# リリースアーカイブ: gh attestation verify <file> -R na0fu3y/ochakai

CLI のリリースアーカイブも同じ attestation に加えて checksums.txt を運び、Binary Authorization はこのチェックをデプロイ時に強制できる — 手順は運用ガイドのサプライチェーン節とハードニング節にある。

脆弱性と修正、そしてサポートポリシー

脆弱性は GitHub Security Advisories 経由で非公開に報告する (SECURITY.md)。応答は数日以内。修正は次のリリースで届く。そしてポリシーは、後で気づかれるのではなく、先に正面から書いてある: サポートされるのは最新リリースのみである。サポートウィンドウは無く、バックポートも無い (docs/compatibility.md)。

それでも本番で運用できる理由は、同じ文書に書かれている。REST は /api/v1 で凍結されており、凍結からのズレは CI が落とす。まだ不安定な面(MCP・CLI・保存形)への破壊的変更はすべて changelog に BREAKING として、運用者が何をすべきかの手順付きで記される。デプロイガイドはイメージタグを固定するのでアップグレードは毎回意思決定であり、そして ochakai export がどの瞬間もバックアップと出口を兼ねる。

継続性 — メンテナが一人であることについて

ochakai のメンテナは一人であり、このサイトのどのページもそれを隠していない (SUPPORT.md は最初の一文でそう言っている)。継続性への答えはメンテナについての約束ではない。あなたのデプロイのうち、メンテナが握っているものが何一つ無いことが答えである: コードは MIT、ナレッジは OKF で丸ごと出て、ワイヤ契約は凍結された OpenAPI 文書であり、製品を形作ったすべての決定 — 何を断ったか、なぜかも含めて — が番号付きの不変な設計記録として公開されている。引き継ぐことになったチームは、コードだけでなく理由ごと相続する。

チェックシート(記入済み)

セキュリティ審査票がたいてい聞く行を、根拠へのリンク付きで。

ライセンス

MIT(LICENSE、著作権者 Naofumi Yamada)。

提供形態

あなた自身の Google Cloud プロジェクトにセルフホストする OSS。SaaS 提供は無く、商用サポート契約も存在しない(SUPPORT.md)。

データの保存先

あなたのプロジェクトの Cloud SQL(Postgres)と GCS。プロジェクトの外に出るデータは無く、テレメトリも無い。

第三者認証(ISO 27001 / SOC 2)

ソフトウェア自体には該当しない: ochakai はあなたのデータを預かるサービスではなく、監査対象はそれが動くあなたの Google Cloud プロジェクト側になる。

認証

Cloud Run IAM(Google の identity)。チーム向け Web UI は IAP。漏れうる API キー・トークン・パスワードが存在しない(設計記録 0003・0065)。

認可

持たない(記録された決定)。到達できることがアクセスモデルであり、分離はデプロイ単位(テナント・チームごとに月約 $10 のインスタンス)。concept 単位の権限が要件なら→間違った道具。

監査ログ

全書き込みに provenance(認証された呼び出し元からの観測)、検証/却下の台帳、全リビジョン、却下は理由を保つ。到達の記録はあなたの Cloud Run のログ。

脆弱性報告窓口

非公開の GitHub Security Advisories。応答は数日以内(SECURITY.md)。

依存の脆弱性検査

govulncheck が CI で毎 push 実行される(ci.yaml)。ローカルでは scripts/check vuln。

SBOM・ビルド証明

イメージのマニフェストが SBOM と SLSA provenance を運び、gh attestation verify で検証できる。workflow アクションはコミット SHA 固定、バイナリは distroless 上の静的 Go ビルド。

サポートされるバージョン

最新リリースのみ — バックポート無し。方針として docs/compatibility.md に明記。REST は /api/v1 で凍結、それ以外の破壊的変更は changelog に BREAKING として記される。

バックアップと出口

Cloud SQL の自動バックアップに加えて ochakai export — 論理バックアップと出口を兼ねる OKF バンドル(運用ガイド)。

想定スケール

キュレーションされたベース — 数百万ではなく数千 concept。一つ残らず人を通るからである(ポジショニング)。

事業継続性

メンテナ一人であることを正直に明記。MIT ライセンス + ベース全体の OKF export + 凍結されたワイヤ契約 + 公開された不変の設計記録が、どの瞬間も出口を開けている。

このページに無い問いは、たいてい FAQ か ポジショニングに ある。それ以外は Discussions へ。