Security · Design Principles
約束ではなく、構造で。
セキュリティ製品の信頼は、できることの誇張ではなく、設計の一貫性とできないことの明示から生まれる——Hoko はそう考えて作られています。
enforced by design
4つの設計原則
接続しない
機密ルームのネットワークには、外向きの経路そのものがありません。「不審な通信を検知して止める」のではなく、送る経路を持たない構造です。判定の誤りが入り込む余地を作りません。
配らない
本物のAPIキーは箱の側だけが持ち、社員にも部屋にも配りません。鍵が散在しなければ、漏えい点も棚卸しの対象も増えません。
混ぜない
機密データとクラウドAIへの接続が、同じ部屋に同居しません。機密ストアは機密ルームにだけ接続され、通常ルームからは構造的に到達できません。
記録する
利用・実行・AIセッションの3層を箱の側に記録し、横断検索できます。記録は利用者の作業環境の外側にあり、「誰が・どの部屋で・何をしたか」に監査で答えるための土台になります。
共通するのは、主要な統制が利用者の都度判断に依存しないことです。エージェントや利用者の設定とは別の層で効くため、「守られているはず」ではなく「構造として効いている」と説明しやすくなります。
honest limits
できないことを、先に言います。
導入判断に必要なのは、効能の一覧と同じだけの「効かない場面」の一覧です。Hoko の限界を明示します。
- —物理アクセス・画面の撮影・記憶など、AIワークスペースの外側にある経路は守れません。入退室管理・端末管理・教育など組織側の対策の領分です。
- —機密ルームの頭脳はローカルLLMです。最新のクラウドAIほど賢くありません。賢さより「出ない」ことを優先する設計です。
- —AIの出力（コードの品質・回答の正しさ）は保証しません。統制するのは実行環境であって、生成内容ではありません。
- —許可された範囲内での誤用（権限のある人が正規の手続きで持ち出す等）は、環境だけでは止められません。持ち出し審査などの運用設計が対になります。
- —組織学習の育成ループ（RAG・評価・ファインチューン）は設計のみで、まだ動きません。実装済みなのは可視化と知識の蓄積・共有までです。
- —単体構成では箱が単一障害点です。冗長化は第2筐体ミラーリング構成で対応します。
さらに詳しい「向かない場合」はHoko が向かないケースに整理しています。当てはまる場合は、別の選択肢を先にご検討ください。
disclosure policy
実装詳細は、本サイトでは公開しません。
基盤の構成・採用モデル・認証方式などの実装詳細は、安全上の理由から公開の場には載せず、商談・検証の段階に応じて開示しています。
本サイトで公開
- 設計原則・統制の考え方（本ページ）
- 部屋・クラス・記録という構成の概念
- できないこと・向かないケース
商談時に開示
- 構成・認証方式・運用の詳細資料
- セキュリティ質問票への回答
- 検証環境での実機確認
セキュリティに関わる詳細確認は、お問い合わせからご相談ください。検討段階に応じて開示します。