Archyl Cloudのデータセキュリティ：何を、どう守り、何を主張しないのか

ベンダー向けセキュリティ質問票のどこかに、「顧客データは保存時に暗号化されていますか？ はい／いいえ」という行があるはずです。Archyl Cloudについての正確な答えは、「はい。対象のフィールドは正確にはこれです」です。アーキテクチャのテキスト（名前、説明、ADR、ドキュメント）と認証情報は、データベースに届く前に私たちのアプリケーションが暗号化します。アップロードされたファイルはストレージプロバイダーが暗号化します。識別子、タイムスタンプ、ダイアグラム上の位置、アカウントのメールアドレスは平文のままです。データベースがそれらをインデックス化し、joinする必要があるためです。どれがどちらなのかを示さずに「はい」にチェックを入れるベンダーは、質問票の残りを信じてくれと頼んでいるのと同じです。

この記事はその長い答えです。何をどう暗号化しているか、データがどう流れるか、誰が何にアクセスできるか、AIプロバイダーが何を受け取るか、どうテストしているか、そしてGDPRのもとで何ができるかを扱います。また、まだ到達していない点もはっきり書きます。Archylは現時点でセキュリティ認証を一つも取得していません。

ここに書いた内容はすべて、Security Whitepaper（v3.0）およびデータ処理契約（DPA）と整合しています。どちらも2026年9月27日に更新され、どちらもトラストセンターからリンクされています。もしこの記事の一文とそちらの一文が食い違うことがあれば、ぜひ知らせてください。どちらかが間違っているということだからです。

要約版

いままさにフォームに記入している方のために：

この記事の残りは、各行の背後にある詳細です。

保存時の暗号化：フィールドごとに

Archylは、データベースに書き込まれる前に、アプリケーション内でフィールドを暗号化します。顧客のコンテンツを保持するすべてのモデルには保存フックがあり、書き込み時にテキストフィールドをAES-256-GCMで暗号化し、対応するフックが読み出し時に復号します。暗号化のたびに新しいランダムなnonceを使うため、同じ値を2回保存しても2つの異なる暗号文になります。

対象はシークレットだけではなく、アーキテクチャのコンテンツにも及びます：

• C4モデル： システム、コンテナ、コンポーネント、コード要素（名前、説明、タグ）、リレーションシップ（説明、タグ）
• Architecture Decision Records： タイトル、コンテキスト、決定、結果、タグ
• ドキュメント： タイトル、内容、ファイルパス、タグ、およびそれに対するコメント
• APIコントラクト： 名前、説明、内容、エンドポイント、バージョン
• フローとホワイトボード： 名前、説明、技術ラベル
• その他： オーバーレイ、イベントチャネル、インサイト、リリース、適合性ルール、変更履歴、スナップショット

そして、Archylが保存するすべての認証情報とシークレット：

• GitHub、GitLab、BitbucketのOAuthトークン
• APIキー
• MFAシークレットとリカバリーコード
• インテグレーションとマーケットプレイスの認証情報
• リポジトリのアクセストークン
• クラウド接続の設定

これは常に有効です。暗号鍵は設定されたシークレットからArgon2idで導出され、そのシークレットが存在しないか32文字未満の場合、サーバーは起動時に終了します。Archylが稼働しながらこれらのフィールドを平文で書き込むような構成は存在しません。

実際的な帰結として、データベースのコピーだけでは、データの形はわかっても、その言葉はわかりません。サービスの名前、ADRに書かれた理由づけ、ドキュメントの本文、GitHubトークン、MFAシークレットは、いずれも鍵がなければ読めません。

さらに、認証情報がAPIから再び取り出されることはありません。インテグレーション設定は読み取りのたびに伏せ字化されます。一度Archylにキーを貼り付けると、キーが保存されていることはインターフェースで確認できますが、それを再表示することはできず、組織内のほかの誰かにAPI呼び出しでそれが返されることもありません。

これがカバーしないもの

データベースは行を検索し、並べ替え、joinできなければならず、暗号文ではそれができません。そのため、一部のフィールドは平文のままです：

• 識別子と要素間のリンク。 データベースは、要素AがコンテナBに属し、要素Cとリレーションシップを持つことは知っています。それぞれが何という名前かは知りません。
• タイムスタンプとダイアグラム上の位置。
• アカウントのメールアドレスと姓名。 メールアドレスにはユニークインデックスがあり、2つのアカウントが同じアドレスを使うことはできません。

これらのフィールドは、後述のアクセス制御と、転送中のTLSによって保護されています。この記事は、データベースのディスクレベル暗号化については、あるともないとも主張していません。

アップロードされたファイル

ドキュメントに添付したファイル（画像、PDF、その他の文書）はデータベースには置かれません。Google Cloud Storageに保存され、次のように扱われます：

• バケットはプライベートです。 中身は一切、公開で読み取ることも一覧表示することもできません。
• ファイルは保存時にAES-256で暗号化されます。 暗号化はGoogle Cloud Storageが行い、鍵はプロバイダー管理です。
• ファイルは有効期間の短い署名付きURL経由でのみ配信されます。 各リンクは1つのファイルへのアクセスだけを許可し、生成後まもなく期限切れになります。チケットやチャットにコピーされたリンクは、恒久的な公開URLになるのではなく、使えなくなります。
• デフォルトのリージョンはEUです：ベルギー、europe-west1。

転送中の暗号化

ブラウザ、各種ツール、Archyl Cloudの間の通信にはTLS 1.3を使用します。アプリケーションからPostgreSQLデータベースへの接続にはSSLが必須なので、アプリケーションが平文でデータベースと通信することはありません。

誰が入れるのか

人

• 多要素認証はTOTP、つまり認証アプリが表示する6桁のコードを使います。各MFAチャレンジは1回しか使えず、リカバリーコードはbcryptハッシュとして保存されるため、照合はできても読み戻すことはできません。
• シングルサインオンはSAML 2.0とOpenID Connectに対応しています。サインインは常にArchyl側から始まり（SP-initiatedのみ）、IDプロバイダーの応答をそのリクエストに結びつけるstateは、リクエストを開始したブラウザに紐づけられ、1回だけ有効です。設定方法はSSOの記事で説明しています。
• OAuthによるサインインはGitHub、GitLab、Bitbucketで利用できます。
• パスワードの変更やMFAの解除を行うと、それ以前のすべてのセッションが失効します。 パスワードが漏洩したと思ったら、変更すれば、それを使っていたほかのすべてのデバイスがサインアウトされます。
• パスワードリセットは、アカウントが存在するかどうかを明かしません。 また、リセットリンクは一度使うと無効になります。
• ログイン、MFA、パスワードリセットにはレート制限があります。 制限は多層になっており、単一のIP、単一のアカウント、単一のチャレンジのそれぞれについて、試行できる回数が限られています。

マシン：APIキーとAIエージェント

• APIキーはデフォルトで読み取り専用です。 書き込みアクセスは明示的に付与する必要があり、キーを特定のプロジェクトに限定することもできます。1つのプロジェクトのモデルを読むだけのCIジョブに渡したキーは、まさにそれだけができます。
• MCPサーバーは、AIエージェントがアーキテクチャを読み取り・更新するために使うもので、OAuthと必須のPKCEで認証します。すべての変更操作には書き込みスコープが必要です。アーキテクチャに関する質問に答えさせるために接続したエージェントは、書き込みアクセスを付与しない限り、アーキテクチャを変更できません。

テナント分離

マルチテナント製品が必ず設計段階で防がなければならない失敗は、説明するのは簡単です。サーバーは、あなたがログインしていてどこかの組織に属していることを確認し、そのあとはリクエストに含まれる識別子を何であれ信用してしまう。URLのIDを変えれば、他人のデータが読めてしまいます。

Archylは、すべてのリクエストを、それがアクセスするリソースに対して認可します。ダイアグラム、ドキュメント、キーを要求するということは、単にサインインしているかどうかではなく、その特定のリソースを所有するプロジェクトまたは組織に、あなたがアクセス権を持っているかを確認することを意味します。同じルールがHTTP APIにもMCPサーバーにも適用されます。

これを長期にわたって維持するための性質が2つあります：

• 認可はフェイルクローズ（fail closed）です。 リソースの所有者を特定できない場合、答えは「拒否」です。
• 自動化されたテナンシーテストがCIで実行されます。 認可チェックが削除されるとビルドが失敗し、誰かが気づくのを待つことはありません。

AIが見るもの

Archyl CloudのAI機能はOpenAIを使用し、組織が独自のキーを設定しない限り、ほかのAIプロバイダーは使いません。

リポジトリを読み込んでC4モデルを提案するアーキテクチャ発見では、ソースコードではなくコードシグネチャを送信します。リポジトリに置かれているそのままのファイルを示します：

package billing

import (
	"context"
	"github.com/stripe/stripe-go/v82"
)

type InvoiceService struct {
	Repo InvoiceRepository
}

func (s *InvoiceService) Finalize(ctx context.Context, id string) error {
	inv, err := s.Repo.Get(ctx, id)
	if err != nil {
		return err
	}
	if inv.Total > approvalThreshold {
		return ErrNeedsApproval
	}
	return s.Repo.MarkFinal(ctx, id)
}

そして、アーキテクチャ発見がこのファイルから組み立てるセクションが次のとおりで、これがプロンプトに入る内容です：

--- internal/billing/service.go [go] ---
Imports: context, github.com/stripe/stripe-go/v82
Types: struct InvoiceService,   InvoiceService.Repo InvoiceRepository
Functions: func (s *InvoiceService) Finalize(ctx context.Context, id string) error

承認ルール、しきい値、Finalizeの本体は含まれません。含まれるのは、リポジトリ名、ファイルとディレクトリの構造、そしてこれらのシグネチャ（import、型と関数の宣言、エクスポートされた定数）です。これだけあれば、請求（billing）コンポーネントがStripeと通信していることは読み取れます。とはいえ、無視できる情報ではありません。関数名や型名はあなたのシステムを説明するものなので、共有するデータとして扱ってください。

この説明を実際以上に広く読まれないよう、2つの限定を付けておきます：

• これはアーキテクチャ発見によるソースコードの扱いを説明したものです。 アーキテクチャ発見がリポジトリ内でMarkdownで書かれたArchitecture Decision Recordsを見つけた場合、構造化された決定に変換するためにそのテキストを送信します。また、ドキュメントファイルにタイトルを付けるために、その冒頭の数行を送信します。
• ほかのAI機能は、それぞれのタスクに必要なものを送信します。 たとえばコーディングエージェントは、変更対象のファイルを扱うので、それらのファイルを見ます。

コードは契約を結んだプロバイダーにしか送ってはならない、というポリシーがある場合、組織は独自のAIキーを持ち込むことができます。その場合、AIリクエストはそのプロバイダーに、あなたの契約のもとで送られます。ネットワークの外に一切何も出してはならない場合は、セルフホスト版Archylで、自社のハードウェア上でOllamaを使ってモデルを実行できます。

テストの方法

パイプラインで

CIパイプラインでは4つのセキュリティスキャナーを実行しています：

• govulncheck：実際に呼び出しているGo依存関係の既知の脆弱性
• CodeQL：自社コードの静的解析
• gitleaks：誤ってコミットされたシークレット
• Trivy：コンテナイメージとインフラ構成の脆弱性

プラットフォームで

• 外向きのリクエストはチェックされます。 ユーザーが指定したURLを呼び出すすべてのインテグレーション（セルフホストのGitサーバー、webhook、AIエンドポイント）はサーバーサイドリクエストフォージェリ（SSRF）から保護されており、そのURLを使ってArchylに自身の内部ネットワークへアクセスさせることはできません。
• ブラウザは私たちが配信したスクリプトだけを実行します。 厳格なContent-Security-Policyがすべてのインラインスクリプトをハッシュで列挙し、CDNから読み込むスクリプトにはSubresource Integrityハッシュが付いているため、改変されたコピーは拒否されます。
• コンテナはロックダウンされています。 非rootユーザーとして、読み取り専用のファイルシステム上で、Linux capabilitiesを削除した状態で動作します。
• セキュリティイベントは記録されます。 ログイン失敗、MFAの失敗、拒否されたトークンなどが含まれます。

ペネトレーションテスト

2026年7月から9月にかけて、社内でペネトレーションテストを10ラウンド実施しました。すべての指摘事項は修正され、回帰テストでカバーされているため、同じ問題が再発すれば検出されます。

「社内」とは文字どおりの意味です。これらのテストは私たち自身が実施したもので、独立した第三者企業は関与していません。独立したペネトレーションテストは、SOC 2監査の一環として計画しています。

GDPRに基づくあなたの権利

• エクスポート。 データはJSONでエクスポートできます。
• 削除。 アカウントを削除すると、そのアカウントに属するすべてのものが削除されます。削除はデータ全体にカスケードし、オブジェクトストレージにアップロードされた添付ファイルも含まれます。
• すべての顧客にDPAを。 データ処理契約はすべての顧客が利用できます。
• 侵害の通知は72時間以内。
• サブプロセッサーを変更する際は30日前に通知します。 変更が行われる前に異議を申し立てることができます。

現在のサブプロセッサーは次のとおりです：

DPAには、それぞれの所在地と法的保護措置が記載されています。

まだ主張しないこと

強みだけを並べたセキュリティページは、欠けている部分を読み手自身に探させることになります。ここに挙げておきます：

• 認証はありません。 ArchylはSOC 2認証もISO 27001認証も取得していません。SOC 2 Type Iについては、準備状況評価（readiness assessment）は完了しており、独立監査は未実施（pending）です。ISO 27001は計画中です。監査報告書ができた時点でトラストセンターにそう記載します。それまでは、私たちが公開するどの情報も、それ以外のことをほのめかすべきではありません。
• 独立したペネトレーションテストはまだです。 上で述べた10ラウンドは社内で実施したものです。独立したテストはSOC 2監査とともに行います。
• すべてのカラムが暗号化されているわけではありません。 上で説明したとおり、識別子、タイムスタンプ、ダイアグラム上の位置、メールアドレス、氏名は平文のままです。

あなたのプロセスが、Archylがまだ持っていない認証を要求しているなら、それは現実の制約です。調達レビューの6週目になってから知るより、いま知っていただくほうがよいと考えています。

次に見るべきもの

• トラストセンターには、関連文書が一か所にまとまっています。
• Security Whitepaperは、レート制限や記録しているセキュリティイベントを含め、各コントロールをさらに詳しく説明しています。
• データ処理契約は、上記のGDPRのセクションを契約として定めたものです。
• データ保護に関する質問や、この記事で答えていない質問票の項目については、privacy@archyl.com までご連絡ください。
• 脆弱性を報告する場合は、security@archyl.com までご連絡ください。24時間以内に受領をお知らせします。

あなたがArchylの承認を下す立場の方なら、大半の質問に自信たっぷりの答えがあるよりも、すべての質問に正確な答えがあるほうを望みます。ここに書かれた内容が、あなたのレビューにとって十分に正確でない箇所があれば、ぜひ質問してください。正確なものにします。