Acompanyセキュアコード
CONFIDENTIAL AI SUITE

機密ソースコードを漏洩させずに、
AI コーディング支援を実現する。

Trusted Execution Environment (TEE) と専用ハーネスにより、生成 AI の利用に強い制限がかかる組織でも、機密コードを守ったまま開発を加速する。

securecode
Code review · Sign up
$“What is the tech stack of this project?”
BuildQwen3.6securecode
tab agents    ctrl+p commands
Tip Create a plugin to prevent agent from reading sensitive files
~/project/billing◯ 3 MCP/statusAcompany
SCROLL
01 / 課題

機密コードを外に出せない組織にも、AI を。

Claude Code や Cursor の登場以降、AI コーディングはスタンダードになりつつある。 しかし、機密ソースコードを抱える組織はその波に乗れずにいる。

INFRA

インフラ事業者を信頼するしかない

生成 AI への問い合わせは、推論を提供するインフラ事業者を経由する。データの取り扱いは規約に基づくが、最終的には事業者の運用と特権アクセス管理を信頼することが前提になる。

PROVIDER

学習に使われない保証は契約だけ

デフォルトの API では入力が学習に使われるリスクがあり、オプトアウトしても運用ログとしての保管は残る。結局のところ「モデル提供者を信頼する」契約で縛っているに過ぎない。

AGENT

AI に強い権限を与えることのリスク

コーディングエージェントが行うことはファイル編集・シェル実行・外部通信など多岐にわたる。AI に権限を渡すことが開発効率化には不可欠だが、その分だけインシデントリスクも増加していく。

Acompanyセキュアコードは、この壁を3つのレイヤで壊す。

02 / 価値 1 · TEE 保護TRUSTED EXECUTION ENVIRONMENT

AI 推論を、TEE で物理的に隔離する。
だから、誰も中を覗けない。

Trusted Execution Environment (TEE) は CPU 内に物理的に隔離された 実行領域。推論中の平文がメモリ上に展開されても、インフラ事業者を含む 第三者からは参照できない。

  1. STEP 01

    01. リモートアテステーション

    接続先サーバーが本当に TEE 上で動いており、想定通りのコードを実行していることを CPU 製造元の署名付きレポートで検証する。想定外のコードや設定が動いている環境には鍵を渡さない。

  2. STEP 02

    02. 暗号化して送信

    TEE と DH 鍵交換で共有した共通鍵でプロンプトとソースコードを暗号化して送出し、TEE 内で復号する。平文は TEE の外に一切露出しない。

  3. STEP 03

    03. TEE 内で LLM 推論

    復号した入力で LLM 推論を実行。Acompany を含む第三者からは、処理中のコードも生成結果も見えない。

  4. STEP 04

    04. 暗号化して返信

    戻り値も同じ共通鍵で暗号化し、開発者の手元で復号。平文は最後まで TEE の外に出ない。

03 / 価値 2 · ハーネス

AI に自由を、
運用に統制 を。

機密コードを丸ごと AI に渡してよい設計だからこそ、AI が出す操作・通信を 組織側から縛れることが要になる。Acompanyセキュアコードは AI 自身が 改変できない設定ファイルと管理者アカウントによって、AI とエンドユーザーの 双方を信頼することなく安全性を担保する。

SHIPPEDPOLICY · 権限ゲート

危険な操作は、
必ず人間で止める

  • shell・write・edit・patch 系 tool に粒度別の許可ポリシー
  • プロジェクトごとに allow / ask / deny を上書き
  • 監査ログに残るので 誰が何を承認したか後追いできる
permission · bash
tool requested: bash
$ rm -rf /var/lib/secrets/*
policy: ask · matched pattern: destructive_rm
approve? [y/n]
✕ denied by user — agent will continue without this tool result.
/etc/securecode/policy.toml · 読み取り専用 (AI 不可触)
# 編集可能パス (これ以外は read-only)
[fs.writable]
allow = [
  "{project}/src/**",
  "{project}/tests/**",
]
deny = [
  "{project}/.env*",
  "{project}/secrets/**",
]

# 外部通信先 (これ以外は禁止)
[net.outbound]
allow = [
  "https://api.github.com/*",
  "https://registry.npmjs.org/*",
]
deny_all_others = true
✕ AI からの書き込み試行 → policy.toml により拒否
PLANNEDGUARDRAIL · ファイル / ネットワーク

編集可能パスと
外部通信先を、外から縛る

  • セキュアコードのプロセス外、AI が触れない場所に置く設定ファイル
  • 「書き換えてよいパス」「到達してよいネットワーク先」をホワイトリスト化
  • AI も開発者も信頼せずに、運用責任者の意図を機械的に強制
PLANNEDGOVERNANCE · 管理者統制

連携 MCP・接続 URL は
管理者が一元管理

  • 開発者が勝手に MCP サーバーを追加できない。管理者が承認したものだけが選べる
  • 接続可能な外部 URL のホワイトリストを管理者アカウントから配信
  • ポリシー変更は監査ログ付き。誰が何を許可したかを追跡できる
Admin Console · MCP allowlist (org: acompany)
githubリポジトリ閲覧 / Issue / PRAPPROVED
confluence-internal社内 Wiki 検索APPROVED
postgres-readonlyステージング DB 参照APPROVED
slack-mcp承認待ち · 申請者: dev-aPENDING
random-3rd-party未承認ベンダーBLOCKED
開発者の設定ファイルはこの一覧の subset でしか書けない
04 / 価値 3 · AI 開発

ターミナル完結の UI による、
開発速度の圧倒的向上

ターミナル中心のワークフローを崩さず、コード生成・レビュー・リファクタ・バグ修正・テスト生成までを ひとつのセッションでこなす。

securecode · /private/tmp/billing
Qwen3.6
BillingService の月額利用料計算に、年契約割引を 15% で追加して。テストも合わせて書いて。
Reading the project layout to find the existing pricing module…
readsrc/billing/pricing.ts (172 lines)
grepannual / yearly / discount — 4 matches in 2 files
既存の DiscountRule に annual バリアントを追加し、計算側を 1 箇所だけ拡張するのが最小変更。
editsrc/billing/pricing.ts — +14 −2
+ annual: { kind: 'annual', rate: 0.15 } as const,
monthly: { kind: 'monthly', rate: 0 } as const,
- return base * (1 - rule.rate)
+ if (rule.kind === 'annual') return base * 12 * (1 - rule.rate)
+ return base * (1 - rule.rate)
writetest/billing/pricing.test.ts (new)
bash$ bun test packages/billing — 8 pass, 0 fail (412ms)ok
年契約割引 15% を DiscountRule.annual として追加し、適用箇所は applyDiscount() の 1 行のみ拡張しました。月額側の挙動は不変、テストは 8 件すべて緑です。
$Ask anything...
/private/tmp/billing◯ 3 MCP/statusAcompany

SELECT MODEL

securecode
  • Qwen3.6high
  • GPT-OSS-120Bfast
  • GPT-OSS-20Blite
ctrl+a connect provider · ctrl+f favorite

THIS SESSION

tool calls
6
edited files
2
masked secrets
0
permission asks
1
tokens (in / out)
9.1k / 1.4k
latency p50
820 ms
05 / 安全性の比較

「信頼」で守るのか、
「仕組み」で守るのか。

一般的なコーディングエージェントの安全性は、最終的に運用元への信頼に依存している。 Acompanyセキュアコードは、同じ観点を信頼ではなく物理的な隔離と組織側のポリシーで担保する。

観点一般的なコーディングエージェントAcompanyセキュアコード
入力が社外に漏洩しない
規約・契約で担保
TEE で物理的に隔離して担保
実行環境を検証できる
リモートアテステーションで担保
外部アクセス先の制限
個別設定に依存
管理者ポリシーで一元強制
操作ごとの柔軟な権限設定
個別設定に依存
管理者ポリシーで一元強制
人 (規約・契約・個別運用) を信頼することで担保 仕組み (TEE・設定ファイル・管理者統制) で機械的に担保 非対応・対象外

Acompanyセキュアコード について
詳しく聞いてみる。

下記フォームよりお問い合わせください。担当よりご連絡いたします。

Acompanyセキュアコードは Confidential AI Suite の一角を担う製品です。 社内向けチャット製品の Acompanyセキュアチャット もぜひご覧ください。

* 必須項目